<adfeno>And of course, take your time. Learn when you can, and don't rush yourself. If you have to use a replacement until you learn how to use the real thing, do so. But make sure to come back learning the real thing. :D
<koz_>adfeno: Is 'systemctl enable [Absolute path]' supposed to take ages and ages?
<adfeno>This is what I like on every free software project, there's some great people :D
<OriansJ>The best part, is 90% of the assembler could be achieved with a greedy regex engine, which could have the interesting side effect that assembly comments would be preserved after the source has been converted to Hex. It'll be more of a feat to achieve that in a C Compiler but imagine, user readible comments preserved and useful when C is converted to Assembly and Assembly is converted to Hex.
<koz_>I just tried to 'guix pull'. After a lot of work, I got this:
<kmicu>GuixSD is different from NixOS. Guix has some libstore internals pretty much the same as Nix, but nowadays we could consider them as separate projects. Only technical ideas are shared. There is also Triton (fork of Nixpkgs), but for now, it’s just a cleaner (e.g. Darwin removed :) version of Nixpkgs.
<jluttine>kmicu: ok. i find that a bit sad. for instance, with parabola it's great that there is this upstream arch community. i'm not convinced that there can be enough manpower in a pure libre os community alone but i'd like be proved wrong :)
<jluttine>perhaps i'll give guixsd a try and see what happens
<civodul>efraim: thanks also for updating the SF mirror list, BTW
<lumidragon>Hi all, are there any packages for handling cgroups and namespaces with regards to guix containers system/environment? I'm wondering if it would be possible to setup network interfaces for guix containers.
<civodul>lumidragon: there's no API for cgroups, but there's call-with-container, which takes care of namespaces
<civodul>that's what 'guix environment --container' uses
<civodul>what did you have in mind wrt. network interfaces?
<lumidragon>when I do web dev, I usually run postgresql (or some dbms) in a container accesible by ip address. Then I run my my web container with environment variables telling it how to connect to that dbms.
<OriansJ>lumidragon: The only plans are the tasks we have assigned ourselves. Thus unless someone has decided to do it, the answer would be no. However we always love it when other people pitch in and fill a hole we have missed.
<lfam>I'm trying to build the latest version of weex. It fails during configure with this: checking build system type... /gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash: ./config.guess: No such file or directory
<lfam>configure: error: cannot guess build type; you must specify one
<lfam>It's interesting to see the differences between graphicsmagick and imagemagick. Imagemagick is basically not communicating at all. Even their source code repo doesn't include descriptive commit messages. Whereas graphicsmagick, which seems to be used much less, is working very publicly
<efraim>I think for iptables you could've mentioned the CVE if you wanted
<lfam>efraim: I don't think the bug (CVE-2012-2663)is fixed in that version of iptables.
<efraim>I'm adding some cpan mirrors that have some of the old perl modules, that should help with some of the "source is missing" errors
<suitsmeveryfine>Hi! I have a question regarding encrypted /home. Is it necessary to include, as I do currently, "(needed-for-boot? #t)" or could I leave that part out?
<suitsmeveryfine>My problem is that I have no working screen in GRUB only get one after I've entered the LUKS password. By encrypting just /home I had hoped to see something on the screen, but with my current configuration I don't.
<mark_weaver>lfam: I think we should assume for now that the libxml2 update is ABI compatible, and just push the update
<mark_weaver>I'm more worried about our systems getting hacked than I am about possible ABI incompatibility.
<mark_weaver>in the unlikely case that there's a problem, we have nice roll-back abilities for people to use
<mark_weaver>suitsmeveryfine: I'd be very surprised if (needed-for-boot? #t) is needed for /home.
<suitsmeveryfine>mark_weaver: what would happen if I just remove that part you think? Would I need to mount /home manually?
<mark_weaver>suitsmeveryfine: no, it should still be mounted automatically, but at a later stage
<suitsmeveryfine>I see. Well, OK I'll remove it and try. With the latest unstable version of libreboot I can see things in GNU screen if needed.