IRC channel logs

<civodul>Hello Guix!

<ewemoa>regarding https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00264.html -- it seems like the raspberry pi 2 reports armv7l via uname -m and it has 1 gb of ram, so may be it can work w/ 0.8.2?

<civodul>ewemoa: that may be the case, yes

<civodul>you could try downloading the binary tarball and check if the executables run at all

<civodul>it'd be interesting to know if it works on this machine

<civodul>iyzsong: is it normal that the variable is called "webkitgtk-2.4" but the version number is 2.8.9?

<ewemoa>civodul: another reason to order an rpi 2 :)

<civodul>heh

<civodul>the problem is that they require non-free software to boot, AIUI

<iyzsong>civodul: oops, I wrote the commit message wrong, which should be '2.4.9'. sorry

<civodul>ah ok, np!

<ewemoa>civodul: perhaps that won't be the case for the c.h.i.p.?

<iyzsong>civodul: how about mention it in my next commit? (update webkitgtk to 2.8.3) => https://gist.github.com/9d9149853426f27034b6

<civodul>iyzsong: yeah if you want, but no big deal!

<iyzsong>thanks!

<iyzsong>we have two version python-pillow in python.scm, one is 2.6.1, one is 2.7.0.

<rekado__>here's a call for papers: http://www.continuouslifecycle.de/call_en.php "The event will focus on the lifecycle of software applications with special attention paid to the processes and tools from areas such as Continuous Delivery, DevOps, and Containerization."

<rekado__>sounds vaguely related.

<rekado__>iyzsong: good catch!

<rekado__>iyzsong: the 2.6.1 package looks better

<iyzsong>ok, I'll try to merge them into one, and update to 2.8.1. later :-)

<davexunit>I started writing a rubygems.org importer, but then I realized that rubygems.org only hosts pre-built gems and can't help us at all to get the corresponding source.

<davexunit>terrible.

<iyzsong>python-pillow-2.7.0 removed, the egg is still compressed though.

<rekado__>iyzsong: thanks.

<civodul>rekado__: indeed, the conference looks nice

<civodul>maybe one of us living nearby could submit a proposal? :-)

<rekado__>"The third Continuous Lifecycle conference is to be held in Germany at the Congress Center Rosengarten in Mannheim from November 10–12, 2015"

<rekado__>Germany, eh?

<civodul>riiiight

<civodul>:-)

<civodul>otherwise davexunit could talk about 'guix deploy' but i suspect he lives a bit too far ;-)

<rekado_>reading through their conference description I get the impression that Guix isn't a natural fit for what they are propagating.

<mark_weaver>civodul: does this look okay to you? http://git.savannah.gnu.org/cgit/guix.git/commit/?h=nss-update&id=7df8762ba4ed43f560948e2ddde216fbe8dc5da9

<rekado_>a presenter there would be among docker enthusiasts; "guix deploy" hasn't yet been tested in production enough to make it easy for a speaker there. By November it'll certainly be good enough, but not in two weeks.

<davexunit>hehe, 'guix deploy' can only deploy local VMs with static IPs right now. definitely not ready for "production".

<davexunit>it could be noted as a WIP that is promising, though.

<davexunit>I have to learn to use Docker at work.

<davexunit>not excited, but it will give me more knowledge to make something better for guix.

<rekado_>maybe there's a different angle from which to approach this. One of the topics is "build tools" and "guix environment" *might* fit in there.

<rekado_>or maybe not.

<davexunit>rekado_: what is the context here?

<davexunit>'guix environment' makes it so damn easy to compile guix and my personal software projects on new machines.

<rekado_>davexunit: a call-for-papers for a conference --> "The event will focus on the lifecycle of software applications with special attention paid to the processes and tools from areas such as Continuous Delivery, DevOps, and Containerization."

<davexunit>I'm afraid we don't yet have much to offer in that area

<davexunit>but... we're working on it, and it would be good to introduce Guix to a wider audience that might want to help us.

<davexunit>if they can get over the fact that we're a GNU project.

<rekado_>well, everything looks like a nail to me now that I have this great hammer.

<davexunit>same here.

<davexunit>the build daemon and the store form an excellent foundation for a variety of system management tasks.

<davexunit>that's what impressed me most with Eelco Dolstra's work.

<davexunit>he took quite a big step back to analyze the package and configuration management problem

<davexunit>and came up with an abstraction that is better than what the popular tools today are using

<davexunit>the abstraction isn't totally new, of course.

<davexunit>but no one else can offer what Nix and Guix offer without serious compromises.

<davexunit>Docker, Project Atomic, Snappy, etc. all rave about atomic upgrades and roll backs, but they are just naively taking disk images.

<mark_weaver>speaking of Docker: "Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities" <http://www.banyanops.com/blog/analyzing-docker-hub/>

<mark_weaver>hardly surprising, given the practice of wildly proliferating copies of base libraries

<mark_weaver>this is what happens when you leave it to each individual packager to do security updates for every library they bundle.

<davexunit>mark_weaver: yes, that is terrible.

<civodul>mark_weaver: yes, LGTM, thanks for taking care of it!

<civodul>rekado_: i've noticed that people at work who get on the Docker wagon really just want "guix environment"-style functionality

<civodul>mark_weaver: interesting stats :-)

<efraim>to build armhf bootstrap tarballs it would just be `guix build -s armhf-linux bootstrap-tarballs`?

<efraim>er, it looks more like it would be `guix build --target armhf-linux-gnueabi bootstrap-tarballs`

<mark_weaver>efraim: no, you had it right the first time. guix build -s armhf-linux bootstrap-tarballs

<mark_weaver>efraim: sorry, my mistake

<efraim>mark_weaver: --target=armhf-linux-gnueabi gave me the error: checking target system type... Invalid configuration `armhf-linux-gnueabi': machine `armhf' not recognized

<efraim>-s armhf-linux gave me: guix build: error: build failed: a `armhf-linux' is required to build `/gnu/store/s7kmp5s5h34m9wahrl3d0a7ndwpvxl41-guile-bootstrap-2.0.drv', but I am a `x86_64-linux'

<mark_weaver>efraim: btw, we've already created natively-built armhf-linux bootstrap tarballs

<efraim>mark_weaver: the binary download?

<mark_weaver>efraim: natively-built tarballs are generally better than cross-built ones, so when I bootstrap a new platform I start by cross-compiling them, and then use those to natively build another set of bootstrap tarballs.

<mark_weaver>efraim: well, you will end up using our pre-built bootstrap tarballs even if you build 'guix' from source code.

<mark_weaver>on any platform we support

<efraim>I just found the bootstrap directory on http://alpha.gnu.org/gnu/guix/

<mark_weaver>when you start actually building packages using guix, even if you don't use our binary substitutes, it will start by downloading our pre-compiled bootstrap tarballs for that platform.

<mark_weaver>efraim: what are you trying to do? most users shouldn't need to concern themselves with the bootstrap tarballs manually.

<efraim>I'm trying to put together a guix image for an armhf board I have

<mark_weaver>efraim: but yes, those are the bootstrap tarballs, and there are also a few pre-compiled binaries in the guix "source" tarballs as well, in gnu/packages/bootstrap/

<mark_weaver>efraim: note that we currently lack binary substitutes for armhf-linux, so you'd have to build up the entire system, including compilers, from source code, starting from our bootstrap tarballs. so you'll need a rather powerful armhf board: at least 1 GB of RAM, and a fair amount of reasonably fast disk.

<mark_weaver>efraim: what are the specs of your armhf board?

<efraim>mark_weaver: dual core allwinner a13, 1gb ram, 8gb emmc

<mark_weaver>efraim: I'm not sure 8 GB of disk will be enough, and EMMC will be rather slow.

<mark_weaver>but it might be good enough. it will be a lot of compiling though.

<efraim>mark_weaver: http://www.marsboard.com/marsboard_rk3066_feature.html says A9 but /proc/cpuinfo says allwinner a10/a13

<mark_weaver>we are still awaiting a donation for our build farm to provide binary substitutes for armhf.

<efraim>mark_weaver: I also have a 16gb sd card and 4usb ports. also slow, and could very well kill the sd card, but should be big enough

<efraim>i saw that there are some armhf binary substitutes ready

<mark_weaver>I have a large SATA hard drive in my armhf board (Novena), which was more than enough. I don't know off-hand how much disk space is actually required to build up the system from source code. I suppose it depends on what software you want to build.

<efraim>the kernel failed to build on my laptop when my /tmp was only 1GB

<mark_weaver>efraim: we currently provide only one binary substitute for armhf: guix itself, just enough for you to run 'guix-daemon' and 'guix' itself.

<mark_weaver>efraim: when you ask that 'guix' to build anything, it will start by bootstrapping the system up from the bootstrap tarballs, using a process not wholly unlike "Cross [GNU/]Linux From Scratch".

<efraim>i think i got confused by my bootstrap effort offering to download bash,gcc,etc, but they're also listed as having to be built

<mark_weaver>efraim: there are several phases of bootstrap. the bootstrap binaries are statically-linked, minimal, and somewhat handicapped in various ways.

<efraim>mark_weaver: ok

<mark_weaver>they are used to build the toolchain and libraries that are used later to build the final system.

<mark_weaver>I have to go afk. happy hacking!

<efraim>mark_weaver: thanks!

<civodul>efraim: your best option is probably to start from the binary tarball at http://gnu.org/software/guix/download/ that mark_weaver mentions

<efraim>civodul: thanks

<davexunit> http://man7.org/linux/man-pages/man1/nsenter.1.html

<davexunit>cool

<davexunit>I just saw an article mention using "docker exec" to run things inside a container, and now I found a standalone tool that shows how to implement such a thing. :)

<davexunit>easy, it turns out.

<paroneayea> http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentralized-github/

<paroneayea>not totally #guix related, but related enough in the "ditstributing packages in a peer to peer way"

<paroneayea>though in this case, it's git over bittorrent

<davexunit>oooooh

<davexunit>very exciting

<taylanub>hm, I'm not getting a ~/.guix-profile/share/info/dir file, so Guix-installed Info pages don't appear in the (dir) node

<sirgazil>I'm courious about the cost of the machines Guix needs for its infrastructure.

<sirgazil>For example, where would you buy a armv7 machine, and how much would it cost approx.?

<mark_weaver>sirgazil: the Novena would make a nice armhf build slave for Hydra, although there may be other good options too. the Novena board costs $550, https://www.crowdsupply.com/sutajio-kosagi/novena

<sirgazil>I see thanks, mark_weaver.

<mark_weaver>the Novena is what I used to bootstrap our armhf port

<davexunit>that reminds me, I need to ping bunnie and xobs soon about the possible donation.

<sneek>davexunit, you have 1 message.

<sneek>davexunit, alezost says: Thanks for the "--ad-hoc" option! I am enjoying it!

<davexunit>:)

<davexunit>me too

<mark_weaver>davexunit: that would be great!

<davexunit>I think it's roughly about the time they asked me to ping again.

<davexunit>I'll check at some point.

<mark_weaver>taylanub: do you have any info files in that directory? we added that feature a long time ago.

<taylanub>mark_weaver: yes, they're all there. by the way I noticed guix doesn't build an ...-info-dir (or however it was named) store item anymore when making changes to my profile.

<taylanub>I would always get three things listed under "things that will be built" when making changes to my profile: the profile itself, the info-dir item, and the third I forgot. currently it only lists the profile itself when I make changes to my profile. this is since I updated, recently.

<taylanub>oh wait, it's fixed now. it must either be a bug that has been shortly present in master, or it shows up arbitrarily.

<taylanub>(I just made ~/.config/guix/latest a symlink to ~/src/guix, then installed something to test. hm, let's see if I can find the previous symlink target so I can try to reproduce.)

<taylanub>yes, I can reproduce with 84dv0z07xg8sdglargkdzwf0w2r1gxp0-guix-latest (don't know how to find which git commit that's from). this must mean it's fixed in master.

IRC channel logs

2015-05-29.log