IRC channel logs
2013-08-29.log
back to list of logs
<Steap>How can I remove older versions of my profile ? <Steap>Seems like the "old" versions are still considered "live" <civodul>currently that needs to be done by hand <civodul>that is, remove the foo-XX-link symlink <Steap>and then do I have to run guix gc ? <Steap>it removed quite a lot of stuff <Steap>Hum, what happened to doc/ ? <Steap>make fails in this directoryt <civodul>i was aiming for discuss-before-commit, but that kinda failed <civodul>anyway, comment on the list as you see fit <civodul>good, hmm, middle-of-the-night, mark_weaver :-) <mark_weaver>civodul: I've read about systemd, and it seems quite nice in a lot of ways, except for the dependence on Linux-specific features, and the fact that C code must be changed to tweak it. I wonder if it would make sense to adapt some of its ideas to dmd. WDYT? <civodul>what did you have in mind specifically? <mark_weaver>well, the socket+dbus activation is the most notable. <mark_weaver>basically, avoiding the need to explicitly declare dependencies in most cases and maximize parallelism of boot. <mark_weaver>The use of cgroups in Linux seems useful (though bad that it's a requirement), and I wonder if something similar (or better) could be done in the Hurd. <civodul>i never understood what cgroups are, actually <mark_weaver>To be honest, I'm a bit fuzzy on the details of cgroups as well, but one aspect is that it's possible to launch a daemon in a cgroup, and then specify resource constraints on not only that process, but all other processes spawned from that process, as a group. <mark_weaver>and also to be able to kill the entire group, without leaving any leftover subprocesses around. <mark_weaver>I guess something similar to systemd-nspawn could be supported quite nicely in the Hurd. <civodul>actually, initialization in the Hurd is damn simple, because almost all the configuration is handled by passive translators <Steap>CLONE_NEWIPC was introduced in 2.6.19 <Steap>which I might have used on my first Linux install ~7 years ago <Steap>I do not think we can fix that. <civodul>well, 2.6.19, no: we won't fix that :-) <Steap>in build.cc, it seems like you use clone <Steap>oh, it's in nix/libstore/build.cc <Steap>where does this file come from ? <civodul>Steap: files under nix/ come from Nix <civodul>we could submit the patch for our fellow Nix hackers, but if the intent is to support a 10-year old kernel, that doesn't seem reasonable ;-) <Steap>Fedora 8 is probably not supported any more anyway <Steap>I'll mail the guy after work ";) ;) ;) ;)" <civodul>oh i hadn't noticed you were referring to an actual report <Steap>If they release GNUnet for Linux 2.6.19, I seriously doubt anyone will use it :) <civodul>think of it as G5K for P2P experiments <Steap>And they run old RHEL/Fedora ? <civodul>BTW, didn't someone create a .deb of Guix? <Steap>I don't know how he managed the "post-install" phase <civodul>maybe we should advertise it somehow <Steap>well, maybe we should get antono to send us the .deb :) <Steap>and put it on the front page <civodul>Steap: maybe not on the front page, because we don't want to advertise other distros, especially when not endorsed by the FSF <civodul>so basically antono should "let people know" about it :-) <mark_weaver>I think the split between FSF and Debian is very sad. <civodul>any split in the free software community is sad, and the Debian community is really a striving part of that <mark_weaver>maybe the solution is to advertise a debian package for trisquel, and it just happens to work for debian as well. <Steap>Much less crazy than writing "hey, our package manager is cool, and you can try it on Debian/Fedora if you want" <mark_weaver>given the nature of the Guix package, I suspect it would be easy to make a package that works on all of the popular debian derivatives. <civodul>yeah, it could be that the .deb also works on Trisquel, in which case we can advertise it this way :-) <Steap>ok, so I'm trying to package git using Andreas' work <Steap>I decided to disable the tests, and see if the package build correctly <Steap>On my i686 machine, it builds well. <Steap>On my x86-64 machine, ld fails, but I can't reproduce the issue when running "make" in /tmp/nix-build-git... <Steap>(I did source the environment-variables script) <Steap>I ran "source environment-variables" <civodul>then, can you "strace -f" the "make" that succeeds <civodul>and check whether it's accessing files outside of the store <civodul>also, try export GUIX_LD_WRAPPER_DEBUG=yes <Steap>how could it access such files ? <civodul>well, in /tmp/nix-build-git-* you're outside of the chroot <civodul>so it could be that it uses stuff under /usr etc. <civodul>the other thing you can try is to set GUIX_LD_WRAPPER_DEBUG=yes in the recipe, then rebuild the thing this wayt <civodul>that will print out all the 'ld' command lines <civodul>so we may have more info as to which one is failing <civodul>but it does a looot of extra stuff to install the manual, the Tcl/Tk stuff, etc. <Steap>read(6, "eutils-8.21/bin/pwd',\\n\\t\\t '/usr/n"..., 8192) = 8192 <- how bad is that ? <Steap>civodul: this is not failing during the "check" phase, but during the "build" phase <civodul>the read(2) call isn't necessarily bad <Steap>so I'm wondering if they use a trick <civodul>Nixpkgs patches references to /bin/grep and /usr/bin/perl <civodul>it patches the resulting binaries, git-sh-setup, git-am, git-submodule <Steap>This does not seem related to the ld issue <civodul>another thing you can try is to run 'file' on all the libraries depended on <civodul>but i actually did that already locally <Steap>I'm trying the GUIX_LD_WRAPPER_DEBUG thing <Fulax>Why does guix's build need to download guile-2.0.7? <Steap>civodul: I added (setenv "GUIX_LD_WRAPPER_DEBUG" "yes") <Steap>and it does not print more stuff :/ <civodul>ah, there were two people writing :-) <civodul>Steap: does GUIX_LD_WRAPPER_DEBUG really show up in 'environment-variables'