IRC channel logs


back to list of logs

*janneke -> zZzz
<vagrantc>ok, successfully built qtwebkit with 15GB of free space, and it peaked at a little over 10GB of ram+swap running with --cores=5 ... the lowest the disk went during the build was about 800MB free, and when the build finished bumped back up to 15GB free ... so probably requires a little over 14GB
<apteryx>What is the best demo/presentation to give a team of developers about the best features of Guix? I know some myself, but the crowd will be pretty non-acedemic, get-things-done oriented, so stuff like bit-reproducibility might not score much points. I'll probably end up focusing on the system agnostic part that allows deploying to any recent GNU/Linux.
<apteryx>They also use Python with the PyCharm IDE, which has virtualenv integration; guix environment will not mark much points there as well I'm afraid.
<apteryx>any ideas welcome :)
<mange>I'm going to be doing something like that soon! I haven't really thought about it much yet, though. I think reproducible development environments and reproducible deployments are actually quite a selling point (even if they don't care about bit-reproducibility).
<mange>I was also planning on talking about trust, and how guix can help us to trust the binaries that we run, although I don't know how interesting that will be to everyone.
<apteryx>mange: trust in as interesting idea in this age of dockerize everything.
<atw>I may be giving a similar presentation at my workplace. I'm going to be talking about how Guix and Maven challenge assumptions 2 and 4, respectively, of
<atw>what will be a little interesting is that work apparently used to use Nix, before I joined. Dunno what that was like or how they moved away from it
<atw>My talk is less the "Guix pitch" and more "some things I know about dependencies"
<mange>My talk is technically about "functional package management", so I'll be talking generally and using Guix for my examples.
<atw>apteryx: maybe Guix or Guix ideas could assist deployment, if it isn't a huge advantage over what developers already have? Oh, or integration testing: "imagine virtualenv, but including several services, a database, etc"
<apteryx>atw: yes, the integration tests (or actual deployment of the whole stack) can be a good sale point of GuixSD
<ecbrown>apteryx: guix allows every language to have virtualenv
<ecbrown>so why pick python if that's the reason
<ecbrown>i use it all the time for R environments
<ecbrown>GNU R, ehem
<ecbrown>and guix itself is a wonderful cement upon which to build all those f*cking python modules
<ecbrown>on some system that someone decided was "super stable" like CentOS that does not compile all the new cool stuff, and even some of the old stuff.
<ecbrown>so for me, guix has replaced pkgsrc
<ecbrown>i'd 10x rather write scheme than figure out what's wrong in a complicated makefile
<apteryx>I agree
<ecbrown>(also, this new channels could be totally radical for deployment, "guix pull")
<ecbrown>people always talking about making jar deployment faster, e.g. not using uberjars. well, technically guix is install just what has been changed
<ecbrown>i never want docker. i always want either bare metal with custom environment, or just gimme a vm
<ecbrown>i guess guix supports all three
*ecbrown ends rant
<rekado_>Oh, sorry about the “r-graph” error!
***rekado_ is now known as rekado
<rekado>sorry about the broken commit. It’s fixed in d53aeeafc.
<apteryx>was there any Guix reveal-js based presentation that I could bootstrap mine from?
<civodul>Hello Guix!
<rekado>civodul: Hello!
<civodul>how's everything?
<rekado>civodul: sorry about breaking master. I fixed it a couple of hours ago.
<civodul>great that you found out, no worries!
<rekado>I’m playing around with the hurd bootstrap
<rekado>I’m having some problems building glibc, but I’ll figure it out
<rekado>took the rest of the week off :)
<civodul>nice :-)
<civodul>you're probably among the very first people cross-compiling glibc 2.28 to GNU/Hurd :-)
<rekado>yeah, feels good :)
<civodul>terrible: emacs-org was never updated because its previous version number, 20180226, was greater than the current 9.1.13
<civodul>$ guix package -A |wc -l
<rekado>hmm, doing the hurd fixes on core-updates is tricky, because I don’t know if I’m building the world because it’s on core-updates or because I made a change by mistake…
<rekado>I think I shouldn’t have to build automake and libtool from source, so I think I made a mistake :)
<civodul>could be :-)
<civodul>a simple check is "guix build coreutils" or similar
<civodul>it shouldn't be rebuilt
<rekado>well, coreutils is built from source even without my changes.
<rekado>maybe that’s related to merging master into core-updates
*rekado goes afk for a few hours
<civodul>alternately, you could check the .drv before and after the change
<civodul>as returned by "guix build coreutils -d"
<civodul>cbaines: i'm thinking of moving tailon-service-type to web.scm, so that web.scm can use admin.scm
*ecbrown contemplates sacrificing GuixSD box to Debian Hurd + Guix
<ecbrown>though for some reason the debian installer doesn't like my cdrom
<nly>How do I use guix-emacs to list all pckages
<nly>It shows an error in my scheme repl
<nly>Unbound variable: package/output-sexps
<nly>I used M-x guix-all-packages
<ng0>hey, I won't send a patch right now, but I've successfully build procmail without exim as an input. I saw this while moving the exim package definition and was just confused how procmail would depend on this. No references are kept in the store to it (exim) and the package builds just fine without it
<ng0>I'll do this tonight.
<jonsger>civodul: wouldn't it been an idea to have hpcguix-web on
<ecbrown>nly: that should work. i think emacs-guix is currently broken or i would recommend updating it
<ecbrown>i use it with guix versions of emacs, emacs-guix, and spacemacs
<ecbrown>i think elpa has been down, too. who knows if this is a problem
<nly>Oh, alright. I'll try that
<nly>Maybe I missed something too, I'll read some manuals
<ecbrown>(of course spacemacs is not yet a guix package... ;-)
<rekado>ecbrown: you wouldn’t have much fun with Debian Hurd + Guix at this point.
<rekado>for one: the glibc build is currently broken.
<rekado>we also don’t have a build server for the Hurd yet. (I’m working on it.)
<ecbrown>rekado: ok, you've got a willing "participant"
<ecbrown>my main use of this machine would be getting out to spacemacs in tmux
<ecbrown>but i wanna run it on hardware, can't even get the damned installer past a "cdrom detection" problem
<roptat>I'm also willing to try guix/hurd :)
<civodul>jonsger: yes, though hosting is complicated
<ecbrown>it is the shangri-la
<rekado>ecbrown: Debian GNU/Hurd runs on old i686 machines (e.g. the X60 Thinkpad), but it runs much better in qemu (due to disk caching).
<jonsger>civodul: oke so maybe on
<rekado>yes, it would work on
<roptat>rekado: you think building packages on that kind of hardware would be slower than with qemu?
<ecbrown>rekado: i don't have that hardware, so i can try to run qemu on guixsd.
<rekado>jonsger: it would need some style adjustments to avoid having it look out of place.
<ecbrown>don't think less of me
<roptat>rekado: is Forbidden
<rekado>roptat: building packages requires writing a lot of data to disk and reading from disks, so I’d expect the hurd on actual hardware to be slower.
<rekado>roptat: yes, it’s{en,fr}, I think
<roptat>it's linked from
<rekado>I know
<rekado>that’s the same website we use for, but on I wanted to list all versions of the manual directly.
<rekado>the website code needs some adjustments.
<rekado>I only made a handful of changes locally before moving on to other things.
<rekado>I’d be happy for patches to the website code, though!
<roptat>I'm trying to build an environment with --system=i686-linux but it doesn't seem to do anything for ad-hoc packages
<roptat>actually, it doesn't build dependencies for i686-linux, that's the issue I have
<emacsomancer>I'm having some trouble packaging, getting this error: .
<emacsomancer> I know I need to substitute 'ncursesw/curses.h' with 'ncurses.h' in `include/hstr_curses.h`, but I'm not sure which point in the build I need to do this at (the relevant file is created at some point in make I think).
<bavier`>emacsomancer: before the 'build' phase would be a good bet
<emacsomancer>bavier`: yes, that seems to have worked. doing "add-before" didn't work though (it seems to try to do the substitution before the relevant files are created); I had to actually replace the build function
<bavier`>emacsomancer: cool. perhaps the configuration system provides another way to specify the location of curses headers?
<jabranham>just submitted my second patch to guix-patches 🎆
<emacsomancer>bavier`: i dunno. the point is that the patching needs delaying until a certain point in the derivation. the perhaps brute-force approach of replacing build works at least.
<bavier`>emacsomancer: sure. I just thought, if the header is being generated, that maybe the value being inserted could be influenced in some way, which might be easier
<emacsomancer>bavier`: right. I'm still getting to grips with building guix packages.
<_tibbe>Hi, emacs-guix crashes for me with any command for the last few days. Are there any known problems with it?
<rekado>_tibbe: yes. It needs to be updated to use guile-gcrypt.
<OriansJ>anyone know how to do the equivelent of: ; specifically the setting of FILES=/crypto_keyfile.bin in mkinitcpio.conf
<_tibbe>rekado: thank you. I will wait for the patch to go upstream.
<rekado>hmm, I really don’t know what I’m doing wrt cross-building the Hurd.
<rekado>why do we have *four* different derivations for “glibc-cross-i586-pc-gnu-2.28”?
<roptat>rekado: do you think I can install debian/hurd from a usb stick?
<roptat>because my old pc has a cd reader, but I don't think I have a CD I could burn
<rekado>I don’t think it has USB storage drivers.
<rekado>AFAIK you need to install from CD.
<a_e>Hello Guix!
<bavier`>hi a_e
<lfam>Hello a_e!
<georges-duperon>Hi! If I run `guix system vm-image config.scm` twice, it spends a lot of time rebuilding a separate VM image.
<georges-duperon>Is there a way to ensure that it always returns the same VM image (same hash in the store)?
<civodul>georges-duperon: it always returns the same thing
<civodul>unless something has changed (for instance you run "guix pull" in the meantime and packages have been upgraded)
<civodul>now there's a bug that makes it very slow currently
<georges-duperon>civodul: Ah, yes, I've seen that it spends a while "registering closures". But it also spends a lot of time copying files from /guix/store to /fs/guix/store before that.
<georges-duperon>civodul: f() { guix system vm-image config.scm --derivation; }; f; f # this prints /gnu/store/dy349ihhdw34hb2imjva5qkdglyaky6k-qemu-image.drv and /gnu/store/fggax64phn0mmncflpr1c4549r1hh476-qemu-image.drv
<civodul>that's fishy, but note that it's the derivation, not the output
<civodul>these two .drv might map to the same output
<civodul>you'd have to open them and look for "out"
<lfam>civodul: I checked, they have different values for "out". I'm inspecting them for other differences now
<rekado>since the Hurd only supports 32 bit systems, does this mean that I really should do “guix build --system=i686-linux --target=i586-pc-gnu bootstrap-tarballs” when trying to build the bootstrap tarballs on an x86_64 system?
<rekado>I’ve been trying without “--system” today, but configure always aborts and tells me to pass “--host” if I actually want to cross-build.
<civodul>lfam: that's a bug, then
<lfam>Yeah, I'm still digging in, but several of the inputs are different
<civodul>rekado: --target=i586-pc-gnu alone should work
<civodul>do you have a configure log that you could copy?
<rekado>what fails is, for example, “guix build --target=i586-pc-gnu mig”
<georges-duperon>lfam, civodul: if I diff the derivations, I see they use different hashes for these inputs: grub.cfg.drv, linux-vm-loader.drv, system.drv, qemu-image-builder, system, grub.cfg and qemu-image.
<georges-duperon>(and the order of the inputs is not always the same, it seems. Not sure if that matters?)
<rekado>I see in the build output that neither “--target” nor “--host” are passed to configure.
<rekado>(I had to change gnumach-headers to avoid the configure phase completely; I just copy the headers directly, because of a similar problem.)
<civodul>rekado: MIG itself must not be cross-compiled IIRC
<civodul>georges-duperon, lfam: apparently it's the UUID for the root partition that's not deterministic
<civodul>4 bytes differ
<lfam>How did you figure that out so quickly? :)
<civodul>i opened the .drv in emacs and then kept following the links
<georges-duperon>civodul: Ahah! I actually was working on reproducible builds for a toy operating system just last week, and had issues with the partition UUIDs :)
<civodul>that led me to the "builder-in-linux-vm-builder" scripts
<civodul>which i then diffed with ediff-regions-wordwise
<civodul>georges-duperon: heheh :-)
<civodul>this one is generated in a supposedly deterministic way
<civodul>well, now we know :-)
<lfam>It's faster to follow the links in Emacs than in Vim ;)
<civodul>maybe ;-)
<civodul>alezost implemented a nice drv pretty-printer in emacs-guix
<civodul>that helps
<lfam>I have wished for that!
<civodul>note that there's a vim hacker showing up on the mailing list lately
<civodul>you should make them suggestions :-)
<civodul>anyway, i think the culprit is: (hash (operating-system-services os) (- (expt 2 32) 1))
<rekado>I’m starting close to the beginning now: “guix build -e '(@@ (gnu packages commencement) mig-boot0)'” — this fails with “configure: error: cannot run C compiled programs.”; it suggests “If you meant to cross compile, use `--host'.”
<georges-duperon>lfam, civodul: thanks a lot for the help :) . Night time here, I'll catch up tomorrow on the IRC logs or
<civodul>thanks for reporting the issue
<civodul>rekado: are you building natively on GNU/Hurd?
<rekado>I’m trying to get the bootstrap tarballs.
<civodul>ok, in that case you cannot build mig-boot0
<civodul>what does something like "guix build --target=i586-pc-gnu sed" give?
<rekado>should I be able to cross-build mig, though?
<civodul>not sure
<civodul>lemme see
<rekado>building sed fails because apparently I first need to cross-build mig.
<civodul>oh, right
<rekado>I need mig to build glibc-cross for i586-gnu
<rekado>what I find concerning is that configure seems to be called only with "--build=x86_64-unknown-linux-gnu"
<rekado>I see no --target, no --host
<rekado>is this expected?
<civodul>we do have cross-mig in cross-base.scm
<civodul>could be, depending on where it happens in the graph
<rekado>hmm, ok.
<rekado>I need to map this all out tomorrow.
<civodul>so we don't cross-compile mig, but we compile a cross-mig
<civodul>ok :-)
<civodul>dunno what happened to phantomas
<rekado>one more thing: I see both i586-pc-gnu and i586-gnu in gnu/packages; there’s even an i686-gnu in the ld mapping.
<rekado>I’ll ignore those that are not i586-pc-gnu
<rekado>hope that’s right and the others are just unused alternatives (ISTR that the goal was to build for i686-gnu, but there was a problem that could be avoided by using i586-*)
<rekado>anyway, I’ll stumble through this tomorrow.
<rekado>thanks for helping!
*rekado –> zzzZ
<civodul>note that "i586-pc-gnu" is the triplet while "i586-gnu" is the system type
<civodul>as for 586 vs 686, i vaguely remember that i686 was broken like you write