IRC channel logs


back to list of logs

<civodul>Hello Guix!
<ewemoa>regarding -- 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>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) =>
<civodul>iyzsong: yeah if you want, but no big deal!
<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: "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 importer, but then I realized that only hosts pre-built gems and can't help us at all to get the corresponding source.
<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>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?
<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" <>
<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
<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: 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 that mark_weaver mentions
<efraim>civodul: thanks
<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>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>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,
<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>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.