IRC channel logs


back to list of logs

<Steap>How can I remove older versions of my profile ?
<Steap>I never remember this one.
<Steap>Seems like the "old" versions are still considered "live"
<civodul>currently that needs to be done by hand
<civodul>(which is admittedly suboptimal)
<civodul>that is, remove the foo-XX-link symlink
<Steap>and then do I have to run guix gc ?
<Steap>oh yes indeed
<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>Hello Guix!
<mark_weaver>Good morning, civodul!
<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>sure, some of the ideas are great
<civodul>so that could go into dmd
<civodul>let's steal'em ;-)
<mark_weaver>indeed :)
<civodul>what did you have in mind specifically?
<mark_weaver>well, the socket+dbus activation is the most notable.
<mark_weaver>and mount-point activation as well.
<civodul>sorta like inetd...
<civodul>sorta like "passive translators"...
<mark_weaver>basically, avoiding the need to explicitly declare dependencies in most cases and maximize parallelism of boot.
<civodul>but yes, these are nice
<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>there's also a related feature called "systemd-nspawn", which is able to create very lightweight containers that can, e.g. run a different OS from the parent OS. almost like a VM, but much more efficient.
<mark_weaver>anyway, something to think about.
<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
<civodul>systemd-nspawn looks nice
<Steap>Fedora 8 oO
<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>Steap: it's used in the daemon?
<civodul>well, 2.6.19, no: we won't fix that :-)
<Steap>in, it seems like you use clone
<Steap>let me check the code
<Steap>oh, it's in nix/libstore/
<Steap>where does this file come from ?
<civodul>Steap: files under nix/ come from Nix
<civodul>(not surprisingly)
<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>End of life : January 2009
<Steap>I'll mail the guy after work ";) ;) ;) ;)"
<civodul>oh i hadn't noticed you were referring to an actual report
<civodul>he's a GNUnet hacker
<civodul>so treat him kindly ;-)
<Steap>If they release GNUnet for Linux 2.6.19, I seriously doubt anyone will use it :)
<civodul>that's on PlanetLab
<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>antono did
<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>well, agreed
<civodul>any split in the free software community is sad, and the Debian community is really a striving part of that
<Steap>civodul: what do you mean ?
<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...
<civodul>can you paste the log?
<Steap>(I did source the environment-variables script)
<Steap>I'll email teh list
<civodul>Steap: that's fishy
<civodul>(i just replied)
<civodul>can you reproduce by hand?
<Steap>civodul: what do you mean ?
<civodul>in /tmp/nix-build-git-*
<Steap>no, I can't
<Steap>I ran "source environment-variables"
<Steap>then "make"
<Steap>and it works well
<civodul>and it passes
<Steap>which I don't understand
<civodul>then, can you "strace -f" the "make" that succeeds
<Steap>sure thing
<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>which fails in the chroot
<civodul>so that's one thing you can check
<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
<Steap>how does nixpkgs do ?
<civodul>it doesn't run tests :-)
<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
<Steap>it mentions a "/usr" though
<civodul>Nixpkgs patches references to /bin/grep and /usr/bin/perl
<Steap>in what files ?
<civodul>it patches the resulting binaries, git-sh-setup, git-am, git-submodule
<Steap>not sure I even get there
<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
<civodul>so hmm
<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 :-)
<Fulax>hehe :)
<civodul>Fulax: that's a "bootstrap binary", see
<civodul>Steap: does GUIX_LD_WRAPPER_DEBUG really show up in 'environment-variables'
*civodul -> zZz