IRC channel logs


back to list of logs

<wtheaker>anyone using guix to deploy containers in the wild?
<zacts>wtheaker: what kind of containers?
<zacts>davexunit: so I heard rumors that you are working on deterministic builds with guix?
<wtheaker>lxc, systemd, whatever
<zacts>huh.. Isn't guix using dmd?
<davexunit>wtheaker: hey there.
<davexunit>guix can't create containers... yet.
<iyzsong>it's on my wish list :)
<wtheaker>this isn't the first time I've been hoodwinked by davexunit
<davexunit>if you care, there's this mailing list thread about it
<davexunit>iyzsong and myself will be chipping away at it
<davexunit>wtheaker: I told you that Nix can do containers :)
<wtheaker>this is pretty cutting edge, no?
*wtheaker blushes
<davexunit>because it uses systemd-nspawn
<wtheaker>oh yeah
<davexunit>we need a different solution.
<davexunit>it might be that the guix daemon learns how to do it, or we use pflask or something
<davexunit>pflask looks cool, but it does not advertise itself as a robust container solution.
<davexunit>I'm not sure what the best way is yet. any new thoughts on the matter, iyzsong?
<davexunit>once we have it, 'guix system' can use it and then we'll be have the holy trinity: bare metal, vms, and containers.
<davexunit>zacts: I'm working on deterministic development environments with guix.
<davexunit>I want 'guix environment' to do what Vagrant does, but better.
<wtheaker>davexunit: do you have any sense of how long until that would be in alpha?
<wtheaker>end of the year?
<davexunit>yeah, something like that.
<wtheaker>but coreos is here already :(
<davexunit>can't win 'em all.
<davexunit>even if they are your friend.
<zacts>davexunit: yeah, that sounds way cool
<davexunit>coreos is a whole different beast, one that I do not like.
<davexunit>their system isn't functional, it just uses docker images to allow rollback and stuff.
<zacts>what do you think of docker?
<davexunit>coreos fills a particular niche, whereas guix can be used on any computer, whether it be a laptop, workstation, or server.
<davexunit>zacts: unimpressed.
<davexunit>nix/guix have the concept of the immutable store, which is far more advanced that the basic imaging system that docker has.
<davexunit>and their caching system is flawed (which lead to a security vuln recently)
<davexunit>whereas "the store" is reliable
<davexunit>I guess it's good if you want to use containers with debian or something
<davexunit>but Dockerfiles are just glorified bash scripts
<davexunit>so I just don't see the appeal.
<mark_weaver>wtheaker is fsf staff?
<mark_weaver>ah yes, i see
<davexunit>former FSF staff, but he still has the cloak.
<davexunit>he's now at the EFF.
<storge>hello. i'll be installing guixotic to a virtualbox vm later tonight (pulling down 0.8 right now). any advice or pitfalls to know of in following the usb install directions-cum-vbox vm?
<davexunit>I've talked about the virtues of nix/guix with him a lot, and he's giving them some thought (moreso Nix at this point) for a project at EFF.
<davexunit>storge: since the image isn't in ISO format, some have had trouble using it with virtualbox.
<davexunit>iirc, someone figured it out, but I don't remember what the solution was.
<storge>oh so it isn't! i see, .xz
<davexunit>well, you extract that.
<davexunit>and the resulting file is a raw disk image, not an ISO.
<storge>i see, extract, dd to dev
<storge>good, this will be interesting
<storge>thanks, download complete. time to head home. i'll return once installed. quite interested in your project.
<storge>currently running a jessie system, unpoetteringd.
<davexunit>thanks for being brave and using our alpha distro! :D
<storge>found your project listed at without-systemd.ogr
<storge>found your project listed at
<storge>686 hardware, limited options of modern projects, until i found yours which philosophically is much more aligned with me anyway.
<storge>you're welcome. i'll be using it in parallel with this install. i live hectic days, but perhaps i find a way to contribute.
<storge>first things first: installation ;)
*storge waves
<_`_>davexunit: Is the “container” solution meant to be Linux Kernel specific? solution #2 here seems like the best one, implementing something that utilizes cgroup and kernel ns to achieve os level virt. But that's very Linux Kernel specific.
<davexunit>_`_: yes, linux specific.
<_`_>good to know
***gry is now known as svetlana
***DusXMT_ is now known as DusXMT
<civodul>Hello Guix!
<atheia>Hello civodul o/
<rekado_>Yay! --> "IcedTea is served: /buildtmp/nix-build-icedtea6-1.13.5.drv-0/icedtea6-1.13.5/"
<rekado_>it's still failing tests, but it actually compiled
<bavier>rekado_: that's exciting about IcedTea
<civodul>hey, hey!
***civodul changes topic to 'GNU Guix | | 0.8.1 is in the works | This channel is logged, see <>.'
<svetlana>what did you change in the topic? 0.8.1 note?
<civodul>yep :-)
<civodul>to give people an incentive to hack ;-)
*jgrant still needs to send in that syntactic sugar hack, for use-modules.
*civodul looks at "youtube-dl --help"
<civodul>--include-ads Download advertisements as well (experimental)
<davexunit>who would want that?
<jxself>Advertisers would.
<civodul>note that it's experimental
<DusXMT>perhaps it adds to the ad watch count, some people make money by making youtube videos and having people watch them, some even do it for a living...
<civodul>in the meantime, one has to live without ads
*DusXMT wouldn't want such an unstable job, especially one that relies on people watching ads
<bavier>is ld-wrapper designed to always be used by compilers, or only by builders?
<xjgrant>DusXMT: Offtopic obviously, but that Pewdiepie or whatever they're handle is ... makes 4 million a year. If you're top dog, this system is great. For most people, it's very stressful and not worth it likely.
<xjgrant>their handle*
<civodul>bavier: it's always used in the build environment; outside, it is needed as well, so gcc-toolchain has it
<bavier>I'm having some difficulty with shared libraries not being found by executables in the check phase; am trying to figure out if it's a cmake thing, the package, or ld-wrapper
*civodul guess it's cmake :-)
<civodul>ISTR cmake has a flag to ask it to set the RUNPATH to in-build-tree libraries
<civodul>i don't remember if we add it by default, maybe not
<civodul>bavier: you seemed to know that very well: ;-)
<bavier>civodul: yeah, and that's why I'm feeling frustrated about this :/
<civodul>in master, ld-wrapper adds "-Wl,-rpath=/foo" when it encounters "-L/foo -lfoo"
<civodul>in core-updates it also adds "-Wl,-rpath=/foo" when it encounters "/foo/"
<civodul>i think cmake-generated makefiles use that form, sometimes
<bavier>ah, that last is what I might need here
<civodul>yeah, ok
<civodul>hopefully we'll merge core-updates RSN
<bavier>great, I'll give it a try