<davexunit>I want to change the syntax of 'guix environment' to be more like 'sudo', or 'strace'. <davexunit>so that the specified command can be run via 'execlp' instead of 'system' <davexunit>but I'm not sure how to make that happen given the current way of doing things where one can specify many package names like 'guix environment guile emacs gcc' <codemac>davexunit: +1. does the guix cli have the concept of '--' ? it coud be 'guix environment --pure <pkg> -- <cmd>'. though, to me it's really separate command like 'guix shell -e '(expr)' / -p 'pkg' <cmd>' <davexunit>it wouldn't be a separate command. it's just an alternate way of saying the same things we're saying now. <davexunit>I think I can kill 2 birds with 1 stone here by also making the various options compose better. <davexunit>for example, I've found myself running something like 'guix environment guile' to get all of guile's inputs <davexunit>but then I want to also add another package in an ad-hoc manner <davexunit>so I spawn *another* shell: 'guix environment --ad-hoc strace' <davexunit>I'd like to be able to compose all of these options together in a single command <davexunit>it's trivial to make such a combination with guix, but it's non-trivial to make a CLI syntax that isn't extremely awkward for t. <davexunit>I think the results of such work would be worth it, because there's all sorts of option combinations that I wish I was able to do without having to spawn multiple nested shells. <davexunit>guix environment --ad-hoc python -- python -m SimpleHTTPServer <davexunit>the above command is really awesome, too: one command to fetch python and launch an http server for the $PWD <codemac>it'll just be a bit long of a line sometimes <davexunit>I guess that's the patch I'll propose first and see what people think <davexunit>the issue of command composition can come later. <davexunit>guix environment guile emacs --ad-hoc strace -- strace guile -c '(do-some-stuff)' <yenda>congrat codemac you seem to be pretty close to a working go package (for me it works fine with a simple hello world) <codemac>yenda: I have all tests passing, but I have the most roundabout frickin' package ever. <codemac>just don't weep. know that I intend to change a lot of it <davexunit>codemac: you can get rid of that huge substitute call starting on line 60 by using the gnu build system <codemac>ALL TESTS PASSED << the best thing ever <codemac>davexunit: yeah, I need to switch to gnu-build system, I just wanted to manually construct what was missing <codemac>because lots of the unit tests go runs frickin' reset the env variables so you can't just set PATH and forget <yenda>you should write a post about your journey codemac <codemac>let's assume this code isn't really code review ready - it was the banhammer of paren-town until I got tests passing <yenda>that kind of stuff would be great to have for future references <codemac>ok I gotta run. i'll be posting a "real" package soon. thanks for all the help #guix (esp. mark_weaver davexunit yenda) <daviid>davexunit: really nice indeed! and this will really help guile to grow, which for us is really cool! <sir123>Afternoon fellow Guix :) So I've had an idea for a while, in doing some study of the Guix system, and comparing with other libre distributions, along with some thoughts on how a good distro is put together, I have a few questions about the Guix system. <sir123>First of all, as someone who cares about free software, I know I value the ability to control my own computing. A natural extension to this is compiling your own packages. GNU Guix offers a chance to understand the makeup of the packages I use, and have greater control over my system. <sir123>So, I wanted to ask this: to what extent does Guix isolate the building of packages, allowing reproducible builds? <sir123>i.e. when I build a package, what does the system do to isolate the build from the rest of the functional system? <mechanical>Build processes are carried out by the guix-daemon program under one of many potential users, as specified by the --build-users-group in a chroot environment, run the program is able to be run as root. <mechanical>I made some typos there, but I don't think it affects readability much. <sir123>Thank you, mechanical. That occurs when the user does a guix build <packag-name>, right? <amz3>or guix package -i <package-name> <amz3>(if there is no substitunes or ask the build explicitly) <amz3>s/substitunes/substitutes <sir123>So, if I want to build a package (from source), where is the build system it uses? I want to be able to trust the build system, correct? <amz3>do you think about the directory where the build happens? <amz3>a *build* is always from source <sir123>Does the system reuse a GNU/Python/etc build system when it is asked to build? <amz3>"build system" in guix is another concept e.g. the gnu-build-system (a scheme variable name) is the build system for gnu-like package that autotools <sir123>So, my question is that as a user, how can I trust my gnu-build-system? That is grabbed automatically from the package repos, or am I wrong? <amz3>basically, it extracts the sources to a directory, then "populate" it with the correct library dependency environment and chroot then inside the chroot in does ./configure/make/make install <mechanical>You want to know how you can trust the build system? <mechanical>If I recall correctly, the initial tools are distributed as binaries with Guix itself. Guix checks everything it downloads with checksums and whatnot. <sir123>I'm curious as to the method of bootstrapping a user could do. It would be very powerful for distributed use, for example. <mechanical>Guix already provides the ability to distribute the compilation of packages across machines. <mechanical>Well, you can offload it to another machine, that is. <amz3>download over gnunet (P2P) of binary package is a gsoc project <sir123>For instance, the tools that exist on other distros are complicated to use. If I wanted to bootstrap my own operating system (for security, etc), could I do it in Guix? <sir123>That means build my own trusted tools, like gcc+binutils+glibc, and use it to build my own trusted set of packages. <sir123>It's not a regular use case, but I'm curious. <amz3>there is bootstrap procedure, I'm not familiar with it <amz3>that said, building you won OS is massively more easy with guix <amz3>the bootstrap procedure includes guile the language in which guix is written <sir123>If the build system could be controlled, that is, I could set Guix to use my own trusted build system, I could have far better control over my own computing. <sir123>I believe Guix could potentially provide that granular control. <amz3>e.g. building a gentoo from scratch is not documented at all. Guix has a way to build everything from scratch provided you have guix on a machine <amz3>(gentoo is always built via livecd. Bootrasping is only done for new architecture is only done for new architecture so it's not documented...) <amz3>I think this area is better documented that in other distributions <sir123>This is my concern. If a user did not trust the set packages, Guix provides a way to build programs and the system to still be aware of it than forcing the users to accept binaries, as is done in other distributions. <sir123>The user can have complete control over his/her computing. <amz3>(regarding build systems, yes you can change the build system, remove the upstream build system and write you own. Or create custom bootstrap binaries and build you own OS with it) <amz3>sir123: yes, maintainer are aware of those. You never have to trust upstream binaries and can build things on your own <amz3>s/those/those concernes/ <sir123>amz: That's why I love Guix. It's freedom to a greater extent. <amz3>really guixsd is a source distribution <amz3>ACTION looking at documentation regarding the topic of bootstraping <amz3>it's great freedom with great software, documentation and team <sir123>I've read this page a few times, I can't wrap my head around it :( <amz3>which specific part, maybe I can help <sir123>This whole bootstrapping process requires what exactly, a pre-running Guix system? <sir123>This bootstrapping is for a system with a store, so Nix or Guix, I imagine <amz3>mind the fact that guix is different from guixsd. guixsd is the distribution, guix is the package manager that powers guixsd <amz3>sir123: the answer is yes <amz3>there is chicken egg problem <sir123>True. So the idea is that the user, say running Ubuntu GNU/Linux, installs a Guix system - the package manager system - and then starts building bootstrap packages? <sir123>mechanical: I'd like to get to know more about how that would work. I'm trying to understand how the system works :) <mechanical>Unfortunately, I'm going afk too. Try reading the relevant parts of the manual. <sir123>Ok. Thank you so much for your help. <mechanical>Before I go, I would advise you to come back to this channel in 12 hours or so. It's rather dead right now. <amz3>sir123: around 10:00 AM GMT at least davexunit will be here, he is more knowledgeable than me <yenda>that's wierd I was trying to update python2.7.9, it built, then I tried building ansible, a test from passlib failed, I tried building again 2 times and both worked <mark_weaver>yenda: many packages have test suites that non-deterministically fail and will succeed if retried. it is quite unfortunate, and we should work to fix those problems when we have time. <mark_weaver>this happens quite a lot on our build farm, hydra.gnu.org. <mark_weaver>amz3, mechanical: it's good that you recommended that sir123 come back when someone more knowledgeable is here. even if you avoid binary substitutes, guix always starts from a set of "bootstrap binaries" that we provide, avoiding the host system entirely except for its kernel. so far, we have always cross-built those bootstrap binaries using guix itself (although the initial x86_64 bootstrap was originally done from NixOS), but it <mark_weaver>could in principle be done from an arbitrary system using its libraries. <mark_weaver>gnu/packages/bootstrap/*/* contains a few statically-linked executables for each supported architecture, which are used within the isolated build container to download and unpack the rest of the bootstrap binaries from alpha.gnu.org, and then the process proceeds from there. <mark_weaver>we have an easy, automated way to build all of those bootstrap binaries from within guix. see the "porting" section of the manual. <mark_weaver>e.g., I created the initial bootstrap binaries for mips64el-linux and armhf-linux by cross-compiling them, using guix on x86_64-linux <mark_weaver>and then I used the resulting guix system to *natively* compile a better set of bootstrap binaries which are the ones we actually use on mips and armhf now. <mark_weaver>(cross-compilation is not as reliable, mainly because the autoconf scripts must make guesses about the target system) <amz3>is it possible to use distcc to compile the bootstrap binaries compiled on the native system? <mark_weaver>we don't currently support distcc, and I don't see how it could be done without sacrificing the reliability of the isolated build container. <mark_weaver>our build containers deliberately isolate the build processes accessing the network. <mark_weaver>(except for the so-called "fixed output" derivations where the sha256 hash of the build outputs are known in advance) <mark_weaver>fixed output derivations are used for downloading the source code of packages, e.g. for our 'origin' forms where a sha256 is included <mark_weaver>the system is designed to ensure that the only things build processes have access to are the declared build inputs (and the things they depend on). <mark_weaver>to support distcc, we would have to extend that to include network accesses to uncontrolled build environments. <mark_weaver>unable to access or communicate with anything that is not a controlled environment <mark_weaver>however, it is already not quite as isolated as I'd like. for example, it still uses the kernel from the host environment, which in practice introduces "impurities" in the build, and can affect the results. <mark_weaver>this is not just theoretical. some of the test suites for our core packages pass on some kernels and fail on others, because they end up testing detailed behavior of the kernel which changes from version to version. <mark_weaver>and some packages have build systems that try running bits of assembly code to test for features in the processor itself, and then create binaries optimized for that processor. <amz3>(by secure I understand that the compilation output has no backdoors introduced by the host which might be compromised) <mark_weaver>and then of course there are things like the real-time clock. many test suites include very tight timeouts that fail on slower machines (like MIPS) or even on powerful machines that are heavily loaded. <mark_weaver>amz3: understood. we try our best to avoid that. the only thing we actually use from the host system is the kernel itself. <mark_weaver>(and everything below it, e.g. the "Management Engine" that is in all newer Intel-based systems) <mark_weaver>also, if you build guix from source code starting from an arbitrary distro, then the guix-daemon (as well as guix itself) is built with the toolchain and libraries from the host distro, and guix uses the guile from the host distro. <mark_weaver>however, when actually building packages, the guix-daemon ensures that nothing from the host environment ends up in the isolated build environment. <mark_weaver>I worry about computer security a lot, and would like to work toward better solutions, but it's a hard problem. there is huge amount of complexity, proprietary systems we cannot yet avoid, etc, that could compromise the security of the system. <mark_weaver>for example, we don't have any bootstrap method that doesn't involve starting from megabytes of existing binaries, whose ultimate source goes back in an unbroken line to the earliest computers. <mark_weaver>to compile anything from source code, you must start with a working computer system, which at least must include a kernel, compiler, linker, and some other basic tools, and that's quite a lot of stuff. <mark_weaver>not to mention the processor with all of its microcode that we can't even see the source code for. <mark_weaver>and all of the code within the dozens of other processors all over modern computers, e.g. in the hard drive, network devices, etc. <mark_weaver>so there's a completely independent processor, running a complete OS, in modern intel systems that lives within the northbridge. <mark_weaver>it has complete dominion over the "main" CPU and memory, and direct access to the network. <mark_weaver>specially formatted incoming network packets are sent to this independent processor before they are even seen by the main processor at all. <mark_weaver>and it's accessible even when the machine is turned off, as long as there is power to the system (e.g. the battery is present) <mark_weaver>the newest machine we've managed to get working without this Management Engine is the Libreboot X200, which is what I use. <mark_weaver>in newer machines, it seems to be more integral to the working of the system. there are some newer systems that we've *almost* managed to get working, but 30 minutes after boot the system shuts down, for lack of an intel-signed binary running in the management engine. <mark_weaver>the folks on #libreboot can tell you more about these things. <mark_weaver>the Purism Librem machines will include this Management Engine, because no one knows how to get such machines working without the Management <francis7>If someone asks about the librem, just give them that link. <sir123> Hi mechanical, amz3, and fellow guix :) <sneek>Welcome back sir123, you have 1 message. <sir123>Thanks sneek, I don't know if i can botsnack you, or if you recognize this :) <sir123>Thanks mark_weaver for the info :) <mark_weaver>I have no special privileges with sneek, anyone can interact with him the same way I do <sir123>I'm wondering how we could tighten that initial bootstrap, so we could recommend it to users <mark_weaver>sir123: it's a crazy project of mine, but at some point I'd like to create a bootstrap that starts with a tiny interpreter supporting a subset of scheme, as a coreboot payload, and from there build to a compiler capable of bootstrapping <sir123>i.e. if we could build a secure environment (what that means is a problem in and of itself) on the host distro, then get the user to trust a set of initial tools, then build out from inside that <mark_weaver>well, I don't know why you would trust some other random distro more than this one. <mark_weaver>but for purposes of implementing David A. Wheeler's answer to the "trusting trust" problem, I would like to support bootstrapping from a diverse set of starting points and comparing the results. <sir123>mark_weaver: it's a crazy dream of mine to be able to build a trusted gcc buildchain on one system, then move it into another distro to form a 'system' toolchain that can be used for compilation, having it isolated and controlled, 'trusted' <sir123>i'm reading through your link now, interesting <mark_weaver>I'm not sure I understand your "crazy dream", but in any case I would like to provide a documented way to create a set of bootstrap binaries capable of bootstrapping guix from a diverse set of starting systems. <mark_weaver>see gnu/packages/make-bootstrap.scm contains the code that cross-builds the bootstrap binaries for an arbitrary platform from an existing guix system. <sir123>So the basic concept is to have a compiler, that may or may not be trusted, then build the untrusted compiler out of a trusted compiler (GCC, for example), and compare bit-for-bit with the untrusted compiler? <mark_weaver>note that there are some patches that need to be applied to some of the bootstrap programs, e.g. guile. <mark_weaver>you should be able to follow the same approach from an arbitrary system, manually. <sir123>I recognise that Guix could be the first system to liberate users from the developers, if you get what I mean. <mark_weaver>sir123: the idea is to build the same version of GCC from a diverse set of starting environments, and then use those GCCs to compile itself one more time. <sir123>In the case of mismatches, do you throw the whole load out? <mark_weaver>mismatches suggest that a thompson virus is present somewhere, so you investigate <mark_weaver>if at least one of the systems you started with is free of the thompson virus, then the GCC built from that one should be free of a thompson virus. <mark_weaver>and if any of the others have a thompson virus, then there will be a mismatch <sir123>So how could we implement this for the benefits of GuixSD users? <mark_weaver>we could document a way to cross-build our bootstrap binaries from some arbitrary starting system. <sir123>So we could run the tests ourselves, and give the end user a hash of a true <package>, and when their system builds, we compare hashes? <mark_weaver>well, in addition, we need to eliminate all sources of non-determinism in our packages, which will draw heavily from the reproducible debian project. <mark_weaver>so we need to finish the job of making sure that guix package builds produce bit-for-bit identical outputs every time on every system. <mark_weaver>and then anyone can independently verify the binaries produced by hydra.gnu.org, our build farm. <sir123>What's standing in the way of reproducible builds? <mark_weaver>and then the hope is that some people will go to great lengths to bootstrap guix in a secure way, and then compare with our build farm. <mark_weaver>nothing is standing in the way, it's just a job that needs to get done. <mark_weaver>guix is designed from the ground up to support this, we just need to dot the "i"s and cross the "t"s, so to speak. <sir123>The documentation, at least for me, didn't really help me to understand that. <mark_weaver>most of our contributors are focused on adding packages, which is indeed important. <mark_weaver>I'm *very* interested in this, but my time is quite limited and at present it's a big job just keeping up with patching security flaws in important packages as they are publicized. <sir123>I'm willing to work on documentation, if that is alright with you and civodul. <sir123>Means I need to get my PC working with Guix again. I broke it trying to get grub to accept my resolution :( <sir123>and guix system reconfigure is causing all kinds of weird issues. <sir123>well, the cpio package is failing to build. The test suite freezes the computer. <mark_weaver>hmm, I don't remember having issues with that package <sir123>tbh, i think i broke my build system :( <mark_weaver>on my Lemote YeeLoong, which I used to bootstrap our mips64el port, I have never accepted any binary substitutes. <mark_weaver>it's a slow machine, so bootstrapping Guix takes a very long time, but I do it periodically. <sir123>Well, I also haven't figured out how to use guix environment properly, so joke's on me <mark_weaver>this time around, the test suites for glib and libsigsegv failed. <sir123>What i'd like to do is be able to boot into the USB image, then build all the required stuff from source. <mark_weaver>I guess that should be doable, although I haven't tried. <mark_weaver>you'll definitely need to start the cow-store service <sir123>If I get better at programming, that's the way I'd like the guix-installer to work :) <mark_weaver>the other thing though is that /tmp will have to be fairly big for some of the packages. that's where the builds take place. <mark_weaver>the USB installer environment is mostly a ram disk, so probably not big enough to do all the builds. <sir123>The idea is to boot up into a graphical environment, then try and run builders immediately, if the user is okay with that, of course <mark_weaver>the thing is, if you don't trust our build farm (which is a reasonable position), then you shouldn't trust our USB installer either. <mark_weaver>so I'm not sure what you gain from doing things this way. <sir123>Which is why I suggest a system for the user to build a USB image themselves before they boot up <sir123>From a simple set of tools they can verify easily <sir123>that's why it's a crazy dream :) <mark_weaver>well, that's where my crazy bootstrapping idea comes in, starting with a minimal subset-of-scheme interpreter running on the bare metal and going from there. <sir123>It would revolutionize GNU/Linux distros <sir123>if the big distros cared. they probably wouldn't <mark_weaver>but any distro that can be bootstrapped from a minimal core could benefit from this. <mark_weaver>almost all distros have no bootstrapping method from a small set of binaries <sir123>I've been looking at other distros. openSUSE (not FSF approved, though) relies on an online build system, it's SaaSS <mark_weaver>our set of bootstrapping binaries is much larger than I'd like, but it's vastly smaller than other systems I know. <mark_weaver>so, right now I'm focusing on making Guix a viable system for people to use, with the eventual plan to work more on improving the bootstrap method to provide better security <sir123>therefore packages take higher priority. <mark_weaver>I think it makes sense to work from the top down, because if no one uses the system it doesn't matter how secure it is. <sir123>Fully libre GNU/Linux distros aren't very popular anyway, that's the way I look at it <mark_weaver>so I'd like to get GNOME 3 into Guix, and working well. <mark_weaver>btw, since you obviously care about security, you had read that wikipedia article on Intel Active Management Technology carefully, and then get yourself a Libreboot system. <sir123>I'd love a libreboot, living in australia the exchange rate is rediculous <mark_weaver>because otherwise, assuming you are running a non-ancient Intel system, your system has a huge backdoor in it. <sir123>I've been looking at machines on ebay, (running MS crapware), that could be librebooted <mark_weaver>sure, that's a good option, though beware that not all of those work with Libreboot, iirc. <francis7>If you think something else needs adding there, let me know and I'll add it. <sir123>Wait, you're THE Francis? Francis Rowe?? <mark_weaver>sir123: francis7 is the principal Libreboot developer. He's the best person to ask on these matter. <francis7>I wouldn't say that I'm *the* Francis Rowe, because there are other Francis Rowe's out there according to Google. <mark_weaver>and there are some other very knowledgeable people on #libreboot as well. a good channel to hang out on. <sir123>holy crap, i'm surrounded by free software celebrities as far as I'm concerned... <francis7><francis7> Who knows if I'm the real one <sir123>I commend you, francis7, for your work in the free software community. <francis7>based on the eminem song "Will the real slim shady stand up" <francis7>the video shows a bunch of crazy people who all think they are the same person <sir123>I always hate myself for having to open up a web browser to the video, then have to copy the link into youtube-dl to grab the video. Irritates me. <sir123>Feel like I'm telling Google everything I watch :( <sir123>I actually dl'd the javascript they use, after prettifying it I was horrified at the DRM they use <sir123>they build profiles out of you depending on what you watch, who gets to see that I don't want to know. Estimated gender, race, etc. <sir123>anyway, my laptop is booted (not libreboot... cry), I'm going to reconfigure this thing. <mark_weaver>sir123: the modern web browser in Guix is GNU IceCat, which comes pre-installed with the "HTML5 Video Everywhere!" extension. <mark_weaver>that extension allows you to visit YouTube normally, without running any of their javascript code at all. <sir123>i know you can search in youtube-dl, that's nice if you know what you're looking for <mark_weaver>because then I have the video on my disk and it's typically a higher quality one than I get from HTML5 Video Everywhere. <mark_weaver>sir123: you can avoid telling Google everything you watch by using Tor :) <mark_weaver>(in combination with these other methods that avoid running their Javascript) <sir123>I guess. I'm not very familiar with Tor, I like Jacob Appelbaum (probably messed up his name)'s discussions on it and the privacy concerns he has revealed <mark_weaver>well, I confess that I haven't looked into what's needed to ensure that all youtube-dl traffic goes through Tor. <sir123>alright, my cpio build has failed on 4: symlink-bad-length <mark_weaver>sir123: so, in general, the thing to do is to build it with the --keep-failed (-K) option, so that the build directory is left in /tmp <mark_weaver>and then from there, you can look at the more detailed test logs, re-run the tests manually in strace or gdb, etc. <mark_weaver>inside the /tmp/nix-build-* directory there is an 'environment-variables' file that contains the environment variables present during the build, which is important because e.g. the PATH contains the /gnu/store directories for the tools used in the build. <sir123>i like the HOME variable: "/homeless-shelter" <mark_weaver>so, to re-run some things in that environment (albeit not isolated now), I will typically do "env -i $(which bash)" to spawn a new shell with an empty environment, and then source the environment-variables file to load those settings, and then work from there. <mark_weaver>also, if the things you want to re-run need to have write access to the build directory, then you'll need to "chown -R" the /tmp/nix-build-* directory to your user. <sir123>ok, i'm staring at the environment-variables file in nano, can you guide me through this? sorry in advance for being a n00b <mark_weaver>I would normally start by looking at the test-suite.log or equivalent. <mark_weaver>(I often do "ls -ltr /var/log/guix/drvs/*/* which shows the build logs in chronological order) ***hopses is now known as hospes
<mark_weaver>actually, now that I look, hydra.gnu.org did once see the same test failure you're reporting. <mark_weaver>and I saved that failed build log before restarting the build, as I often do. <mark_weaver>I guess that restarting it fixed the problem, and I haven't had time to investigate further. <mark_weaver>well, cpio doesn't get built very often, so that's actually quite recent. <mark_weaver>whatever problem caused that non-deterministic failure is probably still there <sir123>if i do a guix build, will it automatically go into a new environment and build it? <mark_weaver>sir123: did you run "guix pull" before building this stuff? <mark_weaver>sir123: are you using the 0.8.3 USB installer? (not 0.8.2) <mark_weaver>well, i guess it's not needed. guix pull will do the job <mark_weaver>but in generally it's better to start from the newest system, since the older one will have unpatched security flaws. <sir123>the substituter has grabbed a pre-built package anyway. trying to 'guix system reconfigure --keep-failed' <sir123>Am I going to have to reinstall the whole thing from a USB again? the build keeps failing from 'guix system reconfigure' <mark_weaver>sir123: no, if you already have GuixSD installed, you don't need to use USB again. <mark_weaver>sir123: are you running from a GuixSD system on your hard disk? <sir123>i should just have to clean the store, that'll force it to get a new set, right? <mark_weaver>sir123: you don't need to clean the store, and it's important to *never* manually delete anything from the store. <mark_weaver>you can use guix gc, but I'm not sure how that would help here. <sir123>haha, I learned that the hard way when I first installed GuixSD. <sir123>It should clear the incompleted cpio source package, right? <sir123>yeah, i am, but 'guix system reconfigure' wants to build it from source <sir123>and it's stuck on this bad cpio build <mark_weaver>sir123: here's my guess: you ran 'guix pull' as your normal user, which is the right thing to do, but your root user still has the old recipes. <mark_weaver>'guix pull' compiles the latest guix from our git repo master branch, builds it, and then sets ~/.config/guix/latest to point to it. and the 'guix' command uses that symlink if it exists. <DusXMT>I think re-running guix pull as root is overkill, one can just # ln -fs $(readlink /home/user/.config/guix/latest) /root/.config/guix/latest <mark_weaver>the thing is, since you must run "guix system reconfigure" as root, it doesn't use the ~/.config/guix/latest symlink from your normal user account. <mark_weaver>DusXMT: sure, and it ends up being the same thing anyway. <DusXMT>mark_weaver: but with ~20 minutes less waiting <mark_weaver>DusXMT: well, 'guix pull' does a guix build like any other build, and so if the build has already been done, it won't be rebuild. <mark_weaver>however, it is true that if our git 'master' branch has been updated since the last time you run "guix pull" as your normal user, then it will have to rebuild again. <mark_weaver>although I confess that these statements are not from experience, since I *never* use "guix pull". I run guix directly out of a git checkout instead. <mark_weaver>the git method is much more flexible and also vastly faster to update, but it takes a bit more work to get started. <mark_weaver>so in my case, both ~/.config/guix/latest and /root/.config/guix/latest are pointing to my git checkout <mark_weaver>previously, I had a script in ~/bin/guix that did the ./pre-inst-env thing <sir123>what's the plan for when guix supports thousands of packages and guix pull will take a long time? <sir123>if i'm going to work on documentation, where can i find requests for changes? <mark_weaver>sir123: I think the plan is to use git and do incremental recompilation. <mark_weaver>the main blocker there is that occasionally a "make clean-go" is needed <mark_weaver>sir123: requests for changes? I don't know what that is. <sir123>what problems have you had with the manual? <mark_weaver>I'm sorry, we don't have that documented. the time would be better spent just fixing the manual rather than documenting how the manual needs to be fixed. <sir123>there, guix system reconfigure is working well now. <sir123>i don't know if that was a joke, but i smiled anyway. <mark_weaver>heh, well, it was serious, but I can also see how it might be funny. <sir123>yeah, 'lets make a system to document the documentation' <mark_weaver>when you first mentioned helping with the documentation, it was in the context of your statement "<sir123> The documentation, at least for me, didn't really help me to understand that.", so I assumed you had an idea of what you wanted to work on. <davexunit>mark_weaver: quick guile question. I have a file descriptor for the master side of a pty, when I call (fdopen master "r+"), it returns a port object for the slave side. do you know how to open the master fd such that it is the master side of the pty? <sir123>mark_weaver: yeah, i have a few ideas. <sir123>Starting with a breakdown of the GuixSD file system layout would be nice <mark_weaver>davexunit: that sounds surprising to me, although I've never written code to create ptys before. <PaulePanter>Hi. In FreeType bug tracker there is a bug reported for Guix and the FreeType developer is asking for help to fix it. <mark_weaver>I'd have to research the issue quite a bit, so I can't really be much help without just doing the job myself :) <PaulePanter>mark_weaver: How to adapt FreeType’s configure script so that it builds under Guix. <mark_weaver>PaulePanter: can I talk to the developer directly, to make this communication more efficient? <PaulePanter>mark_weaver: Not sure if I fully understood your last question. <sir123>mark_weaver: good luck, i'm going off <sir123>PaulePanter: hope you get your bug fixed. happy hacking :) <mark_weaver>PaulePanter: I'm not sure why he needs to build it within Guix to fix that bug. Looking at our current workaround, I guess the issue is that unlike most configure scripts, with freetype it's not sufficient to merely pass CONFIG_SHELL=... to the configure script. instead, we set it as an environment variable before running ./configure <mark_weaver>Guix automatically passes CONFIG_SHELL=... to configure scripts by default, but that didn't work for freetype <mark_weaver>PaulePanter: but if the freetype developer has a question, maybe he should post his question as a comment in the bug tracker, and we can take it from there? <PaulePanter>mark_weaver: Sounds good. I just skimmed the bug tracker for a different bug and saw that he asked for help and that there was no reply. <mark_weaver>to be clear, setting the CONFIG_SHELL environment variable is a workaround that we use for the freetype package <PaulePanter>mark_weaver: I guess, that not all developers are that fluent in autoconf(?) or writing good build scripts. So he asked if you somebody else could provide a patch. <PaulePanter>Sorry for the delay. Could you provide a patch that makes it work in your environment? <mark_weaver>oh, I see. LibreJS is blocking that for some reason. bah <PaulePanter>mark_weaver: Ah. Good. I just made a screenshot. ;-) <mark_weaver>hmm, well, I don't know when we'll have time to work on that. our plates are rather full as it is. <mark_weaver>but I appreciate you bringing it to our attention anyway :) <davexunit>and still need to wrap other low-level interfaces to turn off echoing for the pty so input isn't printed twice <davexunit>well, the 'make' segfault wasn't exactly related to needing to create a new pty, but rather needing to bind mount the host's current controlling terminal as /dev/console within the container <davexunit>now this works!: ./pre-inst-env guix environment --container guix -E make <davexunit>(with a hack that bind-mounts the host /bin/sh into the container) <davexunit>now building a clean checkout of guix in a container. going well so far. <davexunit>ah, running 'make' downloads bootstrap binaries. never realized that. <davexunit>so, a container to build guix need network access. I should add a flag to 'guix environment' that doesn't unshare the network namespace. <mark_weaver>davexunit: hmm, I wonder how that's dealt with in our existing 'guix' recipe. <mark_weaver>certainly, the environment to build our 'guix' package does not have network access, because it is not a fixed-output derivation. <mark_weaver>anyway, I'm very excited by the work you are doing. great stuff!! <paroneayea>davexunit: cool, excited to hear container stuff continue to advance <yenda>"With IceCat I can't connect to OVH manager v5 it's so wierd <davexunit>is there a way to set an environment variable to be used for the entire test suite? <davexunit>now that I can easily run the guix test suite within a container, I can see that tests/containers.cm is failing because there's no $TMPDIR set. <davexunit>well, since each test file is run in its own process, I can just setenv as needed and not worry about affecting tests run later. <yenda>I'm not sure I understand what the 2 patches applied on python2.6 package definition are for. I'm testing an update to 2.7.10 and it makes the build fail (whereas it works fine without them) <yenda>they all fail because of an OSError exception <yenda>can I use local sources in package definition for debugging ? <amz3>here is an exemple I use <amz3> (source "/home/amz3/src/c/dwm") <amz3> (build-system gnu-build-system) <amz3>source points to the git repository of dwm with applied patches and custom config.h... <mark_weaver>yenda: how does the build fail when applying the patches? <mark_weaver>davexunit: that's strange, I don't think $TMPDIR is normally set when I run "make check" or in the 'guix' package build. <mark_weaver>davexunit: if tests/containers.scm fails when TMPDIR is not yet, I think that's a bug in that file, and I wonder why it's not more widely noticed. <mark_weaver>yenda: what is OVH manager? it might be because of LibreJS or one of the other extensions that's enabled by default <amz3>OVH manager is the the web gui of OVH hosting/vps provider (I think it use angularjs <yenda>amz3: this^ but I disabled all plugins and it didn't work either, I always get a 401 unauthorized error, but with conkeror for isntance no problem <mark_weaver>yenda: python-libffi-mips-n32-fix.patch is a fix to the bundled copy of libffi in python. that patch was accepted in upstream libffi and is in the latest libffi release, so there's a good chance that the newest version of python-2 has picked it up. <mark_weaver>but please verify that the change made in the patch is already in the python sources before removing that patch. <mark_weaver>the sqlite-3.8.4-test-fix patch might have been picked up also. iirc, it came from upstream python anyway. <yenda>mark_weaver: yes, both patches have been picked up, at least in 2.7.10 <davexunit>mark_weaver: yes, that's true. it seems to be a problem with my container only. <davexunit>since what I do is obviously not the same as build.cc. <davexunit>yeah, build.cc sets TEMPDIR to the temporary build dir <davexunit>I think I'll create a /tmp in 'guix environment --container' and set TMPDIR accordingly. <yenda>I'm trying to understand why so many fail tests <mark_weaver>yenda: if you could get the test suite working, that would be very helpful! <yenda>is there a way to rerun the test suite without rebuilding ? <mark_weaver>network tests are expected to fail, but there should be a way to get the others working. <davexunit>yenda: you should use 'guix build -K' to keep the failed build around in /tmp <mark_weaver>yenda: if you build with 'guix build -K' to keep the failed build directory, then you can re-run the tests from that failed directory, manually. <mark_weaver>the failed build directory will be in /tmp/nix-build-* <mark_weaver>in there will be a 'environment-variables' file with the environment variable settings used during the build. <mark_weaver>then you can "env -i $(which bash)" to spawn a shell with an empty environment, then source that file to get the environment variable settings, and then go from there. <mark_weaver>it is not quite the same as the build environment, since it is not in a chroot and not isolated from the network, but still often useful <davexunit>'guix environment --container' will help us close that gap soon enough :) <davexunit>it still won't be *exactly* the same, but it will be much more like what the nix daemon environment is.