IRC channel logs

2018-08-24.log

back to list of logs

<RetardedOnion>i suspect that its not opterons with libreboot
<lfam>nckx: https://guix.info/donate/
<nckx>Heh, whoops. I link to that page from my own subs server but did I read it recently? Nope. Thanks lfam.
<lfam>I find myself wondering who runs the guix.info domain
<nckx>Although I only see ‘build farm with 25 build nodes for x86_64-linux and i686-linux, and dedicated storage’ which is very nice and cool, but I was hoping for more.
<nckx>And ‘build farm’ still links to hydra everywhere.
<ecbrown>huh wow
<lfam>Yeah, rekado can probably give more details
<ecbrown>guix.info looks just like the home page... scary
<lfam>It's part of the berlin cluster: https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=22e8c739322b5c7a280a4ab3b49111a403fd8c5a
<nckx>guix.info is rekado, yes. Nothing scary. :-)
<lfam>I'm not sure if berlin is queried by default. IIUC, the daemon is configured at build-time to use it only if building for aarch64.
<lfam>But, (guix build download-nar) lists it
<lfam>And if you use the guix-install.sh script, then the key is authorized
<nckx>lfam: The current manual sez: ‘Note: Similarly, the 'berlin.guixsd.org.pub' file contains the public key for the project's new build farm, reachable at 'https://berlin.guixsd.org'.’
<nckx>‘As of this writing 'berlin.guixsd.org' is being upgraded so it can better scale up, but you might want to give it a try. It is backed by 20 x86_64/i686 build nodes and may be able to provide substitutes more quickly than 'mirror.hydra.gnu.org'.’
<nckx>So I guess it depends on how attentively you're reading.
<nckx>And if you understand the importance of good substitution at that point, which is often not the case.
<lfam>Yeah, I think the topic is obscure for beginners
<ecbrown>like me, i wonder if each commit triggers a re-build of all dependents, and how long to wait until they might be usable
<ecbrown>i think there's a "weather" command
<lfam>The terminology is different from other systems, and the functional model is also not well-known
<nckx>Nice to see that we've gone from 20 to 25 nodes in that time :-)
<lfam>ecbrown: Looking at berlin's list of build jobs, I *think* it builds each Git push, but not each commit: https://berlin.guixsd.org/jobset/guix-master
<nckx>ecbrown: Not each commit, I think there's a pull resolution of n (5? 10?) minutes, so 2 subsequent commits that modify the same package should only result in one rebuild.
<lfam>IMO that's good enough
<lfam>Ah
<nckx>^ what lfam said in the meantime
<lfam>Based on my brief observations, it could be per-push or on a timer like nckx says
<nckx>I thought it polled with a fixed delay but I'm not an expert, certainly not now with Cuirass.
<lfam>The answer lies in the configuration code, which is kept here: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra
*nckx looks forward to replacing their horrible shell-script based CI server with Cuirass.
<nckx>Probably in the back of some room during FOSDEM :-)
<lfam>It would be a cool workshop to present and explain a "turnkey" Cuirass CI based on a config.scm
<ecbrown>wonder why tap-to-click on macbook touchpad works under xfce, but not under gnome
<ecbrown>i had to blacklist usbmouse to get mouse to move other than up and down
<ecbrown>also i can't two-finger "right click" in gnome, but i can in xfce
<lfam>Amazingly, I often get the answer to complicated questions like that from Google
<nckx>ecbrown: I've never used a MacIntosh in my life, but I had to do some ‘xinput --set-prop’ hackery in my .xsession to get tap-to-click and sane (‘natural’?) scrolling to work on my Elantech PS/2 Touchpad.
<ecbrown>no such luck, to date. the usbmouse trick came from my attempt
<nckx>™
<nckx>* Other fine search engines are also available.
<nckx>lfam: re: CI: agreed.
*nckx hopes to meet Clément at FOSDEM. And then to magically have social skills.
<Formbi>what is going on with offload?
<Formbi>it blocks my guix
<ecbrown>--no-build-hook if you are desperate
<ecbrown>assuming you are talking about the thing configured by /etc/machines.scm
<Formbi>dunno
<Formbi>I have guix as an additional manager on Arch
<ecbrown>/etc/guix/machines.scm
<ecbrown>i think if you move that file out of the way there shouldn't be any "offload"
<ecbrown>don't know why it would be there by default, though
<Formbi>well, I don't have that file
<mange>Formbi: What command are you running that's blocking?
<Formbi>but with --no-build-hook it works fine
<Formbi>guix package -i, guix pull
<ecbrown>curious observation: install guixsd 0.15, then reboot. make a small change to config.scm, blacklisting a module, and guix system reconfigure /etc/config.scm, and it downloads all the pacakges again
<ecbrown>fine, then i reboot, and make another small change to the same place, and now it even has to download and recompile perl
<ecbrown>now its recompiling the kernel!
<ecbrown>fwiw, the blacklist was in the original config.scm, and the guix system init didn't seem to need to recompile the kernel
***apteryx is now known as Guest65523
***Jackneill is now known as Guest78765
<rekado>lfam, ecbrown, nckx I bought the guix.info domain and put a pre 0.15 version of the website there. I did not know it would become popular.
<rekado>I’ll try to remember to make time to update the website there regularly.
<jonsger>rekado: could it be down by a cronjob?
<rekado>jonsger: probably.
<rekado>to answer that I’d need to make time ;)
<wleslie>*** No rule to make target 'time'. Stop.
<civodul>Hello Guix!
<civodul>what's up?
<civodul>it's quiet here!
*rekado rolls across the floor like tumbleweed
<civodul>:-)
<jonsger>oh nice. 2 days Guix/Guile days :)
<civodul>that can be very fruitful!
<jonsger>and gives one more time to see all this other interesting stuff on the fosdem itself :)
<janneke>civodul: i have added started integrating the wip-boostrap branch here: http://gitlab.com/janneke/guix
<janneke>removed binutils, glibc, gcc from i686-linux %bootstrap-binaries; and added %mes-seeds
<civodul>janneke: great! i'll take a look
<janneke>and packaged in commencement: mes-boot00, tcc-boot00, tcc-boot01, binutils-boot00, gcc-core-boot00, glibc-boot00 -- but there i'm getting stuck
<civodul>oh, how so?
<janneke>civodul: great...there's prolly some dependency that i cannot see
<civodul>BTW, "00", really? :-)
<roptat>hi guix!
<civodul>howdy roptat!
<janneke>how so: see this snippet from commencement.scm: http://paste.debian.net/1039113/
<janneke>civodul: and yeah...the naming is crappy; i need some inspiration here
<janneke>the extra `0' is to distinguish between the guix bootstrap names, and the mes bootstrap names
<civodul>hmm, not sure this is necessary
<civodul>regarding the snippet, how do things break?
<civodul>well maybe i should just give it a try rather than bother you
<janneke>civodul: i hope we can drop a "level" of packages; either the "wrappers" i added to commencement.scm, or the bootstrap packages in mes.scm...
<janneke>civodul: ./pre-inst-env guix build --system=i686-linux glibc-boot00 or ./pre-inst-env guix build --system=i686-linux gcc-boot00 fail when adding the dependencies that are commented-out
<janneke>would be nice indeed if you could have a look -- i think (hope) that my work in make-bootstrap.scm and bootstrap.scm makes some sense -- very unsure about the extra packages added to in commencement.scm
<civodul>janneke: will do
<civodul> https://libreplanet.org/wiki/Group:Guix/FOSDEM2019
<civodul>add your name to https://libreplanet.org/wiki/Group:Guix/FOSDEM2019#GNU_Guix_Days if you'd like to attend!
<janneke>civodul: thanks...and please bother me about any details --
<jonsger>done
<Formbi>does someone know hot to disable offload?
<rekado>Formbi: you can pass “--no-build-hook” (?)
<Formbi>yeah, but permanently
<roptat>same but for guix-daemon maybe?
<civodul>rekado: good point about childcare; i've added it to the wiki page
<roptat>I remember there was some work on getting guix on the hurd. is it usable?
<jonsger>roptat: https://www.gnu.org/software/guix/blog/tags/gnuhurd/ dont think so
<civodul>roptat: you should be able to cross-compile: guix build --target=i586-pc-gnu PKG
<civodul>and then native compilation on GNU/Hurd was also supported, but it may have bitrotted
<jonsger>but in theory it should be simpler due to better upstream Hurd support in glibc
<roptat>I see... I may be able to install a debian gnu/hurd on an old laptop, so I'll try it then
<roptat>I hope the drivers were updated, cause last time I tried, my ethernet wasn't supported (despite being advertised as supported)
<roptat>it was a few years ago though
<grafoo>hej! i'm trying to build the linux-rdma perftest stuff.
<grafoo>guix build yields that /usr/include/netinet/ip.h cannot be found.
<grafoo>i'm already using glibc as an input.
<grafoo>what am i doing wrong here?
<roptat>is it a package we have, or is it something you're trying to make a package definition for?
<grafoo>roptat: i'm creating a new definition
<roptat>can you share?
<roptat>(on a paste or something)
<roptat>this issue means the build system of your package tries to find a library in /usr, but that doesn't exist in guix. The usual fix is to add a configure option, define an environment variable or fix the Makefile
<roptat>you'll have to run ./configure --help to find if you can set the path to the library
<roptat>or grep for "/usr/include" to try and find how it's used in the Makefile and how you can change that
<roptat>hope that helps :)
<grafoo> https://pastebin.com/MButK93H
<roptat>I see AC_PREFIX_DEFAULT("/usr") in configure.ac, so you probably lack a configure option
<roptat>nevermind, gnu-build-system should take care of that
<roptat>grafoo: this is the culprit: https://github.com/linux-rdma/perftest/blob/master/src/raw_ethernet_resources.c
<roptat>line 48: #include </usr/include/netinet/ip.h>
<roptat>you'll have to substitute* that, and probably report that issue on their github
<roptat>I guess it should be #include <netinet/ip.h>
<amz3>sneek: botsnack
<sneek>:)
<rekado>civodul: I would like to dedicate one node of ci.guix.info to building packages for the hurd.
<rekado>is it enough to mark the machine as a build node for i586-pc-gnu then?
<civodul>rekado: yes, and it also needs to run GNU/Hurd
<civodul>it could be a VM
<rekado>oh
<rekado>I guess I could take a ready-made VM image from the Hurd folks.
<jonsger>rekado: https://www.gnu.org/software/hurd/hurd/running/qemu.html
<samplet>The GHC package dependencies are getting complicated. I sent <https://debbugs.gnu.org/32517> to fix git-annex, but the patches don’t play well with Arun’s darcs updates.
<samplet>They updated ghc-base-compat, which means that ghc-aeson needs to be updated, which means that ghc-text needs to be updated, and it has 300 dependencies!
<rekado>samplet: with Haskell packages you need to be careful.
<rekado>I have an unfinished GHC update (from 8.0 to 8.4.3) that I’m stuck on.
<rekado>once that’s done we can update the rest of the packages to the latest LTS versions.
<rekado>I did this about a year ago already, and it needs to be done again.
<samplet>That would be cool, but a lot of work.
<samplet>Do you have any scripts?
<rekado>it’s not so bad
<rekado>we have an updater
<rekado>guix refresh -t stackage -u (?)
<rekado>that would update package definitions in place
<rekado>last time it was a matter of maybe 3 days
<rekado>including building packages and fixing problems.
<rekado>much less work than the GNOME upgrade
<samplet>That’s great! Maybe I will look at GHC itself then. I don’t know what I am able to do, but who knows?
<samplet>Because until things settle down, I imagine git-annex will be broken.
<rekado>samplet: http://lists.gnu.org/archive/html/guix-devel/2018-08/msg00079.html
<rekado>that’s my GHC upgrade patch
<rekado>it suffers from a linker problem, which I haven’t figured out yet.
<rekado>(and I haven’t tried again since sending that email)
<rekado>help is very welcome here!
<civodul>hey samplet
<civodul>rekado: BTW i'm surprised ld-wrapper's handling of reponse files is still insufficient
<civodul>*response files
<samplet>Hi civodul
<civodul>hi vagrantc
<civodul>vagrantc: i watched your DebConf talk and i really enjoyed it
<civodul>i like that you mentioned "volunteer-driven orgs", it certainly has an effect on the spirit of the projects
<vagrantc>civodul: glad to hear!
<civodul>the Guix issues you mention towards the end of the talk are interesting topics
*vagrantc is meaning to write a follow-up post with some example demos too
<civodul>cool
<civodul>i'm not entirely sure about the per-user profiles vs. security updates issue
<civodul>in that the sysadmin can easily check whether a given profile includes a security-riddled package
<vagrantc>sure, you can write tools to check for such things, but out of the box it's a very different workflow than a typical system
<civodul>right, definitely
<vagrantc>(excepting the fact that users can install their own softwhere anywhere they can write to, typically)
<civodul>yeah
<civodul>but it's true that sysadmins have to be prepared to this special workflow
<vagrantc>though with guix it's more built-in that end-users will install software without the sysadmin knowin
<civodul>yeah
<vagrantc>it wasn't, per se, a deal breaker, just something i figured was worth mentioning
<civodul>sure, i agree
<civodul>the other issues you mentioned, well, we need to work on them :-)
<vagrantc>heh
<vagrantc>i read a thread about guix 1.0 suggesting they were definitely on the roadmap
<civodul>mostly
<vagrantc>regarding the trust-path to the git repository ... i thought about writing a script that basically goes git pull, and iterates through the top commits until it finds one in a trusted keyring ...
<civodul>the upgrade-that-takes-forever issue is hard to fix "once and for all", though
<vagrantc>and then calls guix pull with that commit
<civodul>yes, that's roughly what should be done
<civodul>problem is, we also need a way for consumers to know the list of authorized committers at any given point
<vagrantc>it would be over my head to write it in scheme, but i could probably write up something in shell to do it :)
<civodul>heh, sure :-)
<vagrantc>oh, in other news, i *finally* successfully built qtwebkit ... with 8GB of ram, 10GB of swap, and passing --cores=3 and 18GB of disk space... it actually completed
<vagrantc>not sure how close to those limits it actually went
***Piece_Maker is now known as Acou_Bass
<vagrantc>definitely saw it using 8GB+ of disk space
<vagrantc>not sure how much higher it went
<civodul>ouch! that's a lot of resources
<vagrantc>it definitely out-of-memory with 8GB of ram and no swap
<civodul>was it built with -g0? it makes a big difference in terms of disk space for C++ code
<rekado>it’s just for one of the tests, though, isn’t it?
<vagrantc>civodul: didn't look into it ... just kept trying to build it various ways
<vagrantc>first with --cores=1 just to see if the ram usage was due to too many parallel processes ... which seemed like it might have actually been the case - i got an out of disk space issue there
<civodul>heh
<vagrantc>so, pretty much added more resources till it worked... :/
<efraim>rekado: once Haskell is updated there are upstream armhf and aarch64 GHC binaries
<RetardedOnion>are you guys at fosdem?
<mbakke>RetardedOnion: Yes! Will you join us? :-)
<mbakke>civodul: I've made good progress on glibc 2.28, hopefully done today!
<RetardedOnion>mbakke: probably. i am not a dev but i wanted to go there since 2016. i guess next year i will go. even though i have to get there. which is really expensive.
<civodul>hey mbakke, awesome!
<rekado>efraim: we will keep the existing bootstrap binaries for GHC 7.
<rekado>efraim: I’m not throwing out GHC 8.0, but I use it to build GHC 8.4.3.
<grafoo>roptat: thx! i'll look into it.
<rekado>urgh, I dropped my laptop. Outside. Concrete + gravel. Still works, but now totally looks like it would be my laptop.
<rekado>what a day
*rekado goes home to think about the life choices that led to this point
<database>how to install pciutils-devel libraries
<mbakke>database: The 'pciutils' package should suffice.
<database>mbakke i installed it but make can't find it
<amz3>database: i love your nickname! tx!
<mbakke>database: What error are you getting?
<database>amz3: thanks but why ?
<amz3>database: I like databases :-)
<mbakke>database: You could try running it within a `guix environment --ad-hoc pciutils`. That will make sure the required environment variables are set up.
<mbakke>I mean `guix environment --ad-hoc pciutils gcc-toolchain`.
<database>it says that make can't find pciutils and install pciutils-devel
<database>amz3: any particular reason for this ?
<amz3>database: well, outside the fact that databases are one kind of expert system, one that is related to data persistence, I code databases in guile and I am the maintainer of guile-wiredtiger
<amz3>database: the reason I like database is because they are an important well identified problem when dealing with information systems.. guix is another kind of expert system.
<database>amz3: cool
<database>amz3: private msg
<ecbrown>i have a luks disk, which is at /dev/mapper/my-root. on a guixsd 0.15 install, i was able to use (device (file-system-mapper "my-root")) and things work great. having used the system for a while, probably some guix pull's and whatnot, now i can not guix system reconfigure using the same file, as it complains about "file-system-label: unbound variable"
<ecbrown>(fwiw i am running a custom 4.17.x kernel)
<ecbrown>not sure which module i need to add: i tried (gnu system file-systems)
<lfam>ecbrown: In the context where you tried to reconfigure, what is `guix --version`? Make sure the context is the same regarding invocations of sudo or any other way you became root
<lfam>file-system-label is relatively new
<lfam>And the next question is, can you share the config.scm you are using on <https://paste.debian.net>?
<ecbrown>one sec on the pastebin
<ecbrown>i use su, and i get guix --version ==> 0.14.something
<ecbrown>but guix --version on guix pull'd user "brown" looks like a sha
<ecbrown>maybe i need to guix pull as root?
<lfam>Yes, `guix pull` is per-user so make sure to do it as root and then try reconfiguring again
<ecbrown>or perhaps better to sudo -E guix system reconfigure?
<lfam>Sure, if you trust that environment with root
<lfam>I don't think the paste will be necessary
<ecbrown>ok, thanks for the suggestions. need to pull/compile, brb
<lfam>ecbrown: Did it work?
<ecbrown>still recompiling.... cairo, git, yada yada
<ecbrown>(and lots of tests...)
<apteryx>hello guix! Is it possible to launch multiple, independent instances of icecat? I think there is a --profile option, but I'm not sure if concurrent use is OK
<rekado>apteryx: icecat --help tells me that you can use “--new-instance” to start a separate instance.
<rekado>ecbrown: are you compiling things from source on purpose?
<ecbrown>nope
<rekado>ecbrown: have you authorized substitutes from both berlin.guixsd.org and hydra.gnu.org?
<ecbrown>i don't think i've explicitly authorized berlin
<ecbrown>it just goes to mirror.
<lfam>I think Berlin is implicitly authorized on GuixSD, but not queried by default
<ecbrown>"guix: system: command not found" upon guix system reconfigure...
<ecbrown>hmm maybe guix environment guix first?
<rekado>ecbrown: that’s a bug! But there’s a way around it.
<rekado>this is down to guile-sqlite3 missing IIRC
<vagrantc>i've had to both authorize berlin.guixsd.org and add it to the default substitute servers on both an old guixsd and 0.15 one
<rekado>it has already been fixed, but I think you’re using a rather old version.
<rekado>ecbrown: to get around this I think it’s sufficient to do guix environment --ad-hoc guile guile-sqlite3
*rekado could be wrong
<ecbrown>ok let me see.
<lfam>Berlin is authorized by the default guix-configuration on GuixSD ((gnu services base) %default-authorized-guix-keys). But I don't think it's queried by default based on the code
<ecbrown>rekado: that got me through the wicket, thank you!!!!
<ecbrown>did guix archive --authorize < berlin...pub will see if this speeds things up
<lfam>The key is already authorized...
*ecbrown collapses in a heap
<ecbrown>i guess i need to add it as a default substitute-url or something...
<lfam>You need to have the daemon query it, like this: https://paste.debian.net/1039192/
<lfam>You can also do it per-command. The Guix "common build options" include the --substitute-url argument, which can be passed to any command that builds things
<rekado>ecbrown: as lfam says you can also add this to the command: --substitute-urls="https://berlin.guixsd.org https://mirror.hydra.gnu.org"
<lfam>It's a bit opaque since the keys don't have any metadata like a name, but you can check which keys are authorized by viewing '/etc/guix/acl'. You'll have to look up which key corresponds to which server, however
<vagrantc>what installes /etc/guix/acl? my most recent 0.15.x install as of a few weeks ago still only included hydra's keys.
<ecbrown>lfam: will try that. i have %desktop-services, hopefully not a major problem
<lfam>Oh, interesting. I guess the code I read doesn't have the effect I thought
<Formbi>a new substitute server? nice…
<ecbrown>rekado: thanks
<lfam>ecbrown: Yeah, just try (modify-services %desktop-services (guix-service-type ...))
<rekado>Formbi: “new” since maybe a year or so :)
<ecbrown>ok one sec. all my machines are cranking on something
<ecbrown>guix system reconfigure problem solved, i think
<lfam>Indeed, guix-activation only installs Hydra's key
*ecbrown wonders how a build server could ever catch up. like, ever
<lfam>More and faster cores, faster storage
<ecbrown>iiuc, even one change of something important triggers a recompile of whoppers like webkit, qt, libreoffice...
<lfam>I think it would be possible to get the latency down to <30 minutes
<lfam>Maybe there are a few applications like Chromium that would take longer, but I'm not sure
<ecbrown>someone asked if i am purposefully compiling, and no i am not. if i update to HEAD, then i am necessarily going to have to comile stuff because they won't be on the build server yet
<ecbrown>i wonder if i should run "a day" behind
<lfam>If you use the Berlin substitute server, that should do the trick. Hydra may be farther behind
<rekado>ecbrown: we try avoid really big updates on the master branch.
<rekado>ecbrown: for big updates we use the staging branch or core-updates.
<lfam>Yeah, but even single things with "small" impacts like webkitgtk might be unavailable for many hours if using Hydra
<rekado>but still we sometimes do have a couple of changes to big leaf packages on master.
<rekado>I’d like to fix this by auto-merging branches, but this needs some more thought.
<rekado>people could push a new branch where a big package is updated, the build farm builds it and merges the branch into master upon success.
<rekado>exactly how this automatic merge should be performed is not clear to me yet.
<lfam>I think we can get pretty close to our goal of not making people build things by improving the default build farm
<rekado>maybe this can be done manually by sending emails on success and asking for a manual merge.
<lfam>I wonder if Berlin should be added to the defaults in the next release?
<rekado>yes
*vagrantc was surprised it wasn't added on 0.15
<vagrantc>since i started actually using guix around 0.13/0.14 and the entire time one of the first recommendations is to enable berlin.guixsd.org
<rekado>I’m not sure if it was intentional to leave it out of 0.15.
<lfam>Poking around, it looks like there are a few different mechanisms where we can select substitute servers
<lfam>In the daemon build-time configuration, in (gnu services base), etc
*lfam tests new OpenSSH release
<ecbrown>i'd like to flesh out the openssh configuration... i started by adding whatever is needed for tunneling
<lfam>Here's a change that we should make sure doesn't break anything: * ssh(1): prefer the ssh binary pointed to via argv[0] to $PATH when re-executing ssh for ProxyJump. bz#2831
<lfam>I guess since that's for `ssh` and not `sshd` it wouldn't be handled by the current GuixSD service code
<rekado>lfam: isn’t this change what we would want, though? Or do you mean it might break shell wrappers?
<lfam>rekado: Since Guix uses environment variables for so many things, I was concerned this could affect service restart or reloading if we implemented it for a related use-case
<lfam>But I don't think we use or handle `ssh` for anything, so we should be good
<lfam>But I can imagine a similar change breaking, for example, nginx reloading upon nginx updates
<OriansJ>hmmm, I wonder if there is a way to assign all guix packages a build cost in terms of memory and processor resources, that way all build servers could build packages in the order which corresponded to the build server's administrators preference. EG. build bulky desktop packages like webkit last and tiny applications like mescc-tools first
<samplet>rekado: It looks like the stage2 GHC is not using ld-wrapper because the “--with-ld” is not getting propagated all the way down.
<samplet>I have to go now, but I bet I can fix this later tonight.
<OriansJ>Or possibly a way to make repo servers fully independent from build servers and thus allow multiple build servers to get build instructions from the commonly shared repo server that provides the binaries to be used in builds.
<rekado>samplet: awesome!
<rekado>thanks for taking a look!
<rekado>OriansJ: this is already the way it is, no?
<rekado>the build farms are like any other user of Guix
<rekado>they fetch Guix from git and then build packages.
<rekado>we do have multiple build servers and they all take the package descriptions from the shared git repository.
<rekado>to optimize the build order these build servers are managed by a node that runs Cuirass, which schedules evaluations and follows changes to the git repository.
<rekado>that head node offloads builds to the build nodes.
<OriansJ>rekado: I guess I missed that info in the documentation
<OriansJ>Since setting that up seems like something we want to encourage, that way more people can efficiently keep our binaries honest
<rekado>yes
<rekado>people can already run “guix publish” to share the contents of their store.
<rekado>that’s exactly the same thing berlin.guixsd.org does.
<rekado>(hydra.gnu.org still runs hydra, which is … special)
<OriansJ>rekado: but guix publish isn't the Cuirass build farm sort of setup, so much as a home build server for smaller environments
<rekado>on berlin we actually do run “guix publish”.
<civodul>rekado: hydra also runs 'guix publish' actually
<lfam>I think publish and Cuirass are orthogonal. The former distributes subsitutes, the latter is a CI system
<rekado>OriansJ: the setup on berlin consists of “guix publish” + Cuirass to schedule builds.
<rekado>you don’t *need* cuirass to build things, but it helps keeping track of builds when you do this continuously upon changes to the repository.
<lfam>I wonder about the slowness of 'registering closures' with `guix system vm-image` and similiar commands. I don't remember this taking so long in the past
<OriansJ>rekado: My view is the more pieces that are well documented about how things are done, allows others to see what useful pieces we have available and make maximuim use of them.
<lfam>Could it be a consequence of the Meltdown / Spectre mitigations?
<lfam>Or perhaps the addition of #reset-timestamps?
<civodul>lfam: it could be due to the switch to the guile-sqlite3-based Scheme code
<civodul>i didn't notice it was slower, but i didn't pay measure either
<lfam>Created a bare-bones VM takes ~90 minutes for me recently
<lfam>s/Created/Creating
<civodul>with vm-image?
<lfam>Yes
<civodul>and with KVM?
<lfam>Yes, on an SSD, ~5 year old i5 processor
<lfam>Used to be much faster
<civodul>indeed, i don't remember it taking so long (except when you have to build packages, of course)
<lfam>Right, this is just the 'registering closures' step
<civodul>ouch
<lfam>I can poke around and try to isolate the cause
<civodul>is this a big system closure?
<lfam>No, it's just the bare-bones template
<civodul>oh
*civodul tries
<OriansJ>well, the first guix pull on a RaspberryPI 3 can take a couple days; even though it has 4 cores at 1.2Ghz with 1GB of Ram and a 90MB microSD card
<OriansJ>90MB/s
<civodul>OriansJ: is it 'guix pull' from 0.15?
<OriansJ>correct
<civodul>did you enable substitutes from mirror.hydra.gnu.org?
<civodul>rekado: BTW, i see that "ci.guix.info" is set up, cool!
<OriansJ>civodul: no, I don't do substitutes
<civodul>ok
<civodul>lfam: it's been "registering closures" for 10 minutes already
<lfam>Seems long to me...
<OriansJ>but pulling really shouldn't be that insanely heavy weight anyway; I mean even if one needed to build a 1GB object in memory shouldn't take that long
<civodul>lfam: yes, me too
<lfam>I turned off #:reset-timestamps? and am trying again
<civodul>when i prepared the 0.15 release i don't think it took this long
<civodul>your turned it off where?
<lfam>In root-partition-initializer
<lfam>It's just a guess. I'm looking at changes to what I think is the relevant code within the last few months
*rekado –> zzZZ
<OriansJ>A 10K node dependency graph with under 1M links; really really shouldn't have this short of compute requirement
<pkill9>does nayone have an example iPXE script for creating a system based on a configuration?
<pkill9>anyone*
<civodul>OriansJ: Guile 2.2's compiler is way too resource-hungry--no argument here
<civodul>OriansJ: now, 'guix pull' might also need to build lots of things, basically all the dependencies of the target Guix
<civodul>that could be a lot of stuff
<OriansJ>civodul: wait, Guile's compiler is trying to optimize a data object?
<civodul>Guile's compiler is used to build all the Guile code in Guix
<civodul>(not sure what you mean by "optimize a data object")
<OriansJ>civodul: at its core the entire package list with dependnencies is just a data object
<OriansJ>Which is then used to lookup the values of binary blobs that need downloading via substitutes or the sources that need to be built and their dependencies for building.
<civodul>the connection between packages and binaries is not this direct
<civodul>from the point of view of Guile, all this is just code that needs to be optimized :-)
<OriansJ>civodul: granted
<OriansJ>well we could tell guile not to optimize things that run only once or rarely
<OriansJ>or possibly never needed to be compiled in the first place
<lfam>With #:reset-timestamps #f, I cancelled the task after 10 minutes of 'registering closures'
<civodul>lfam: hmm!
<civodul>maybe we should check whether that was indeed faster at v0.15.0
<lfam>Yeah, I can try it
<lfam>And send a bug report with my findings
<lfam>It was definitely faster at some point in the past
<civodul>that'd be great, thank you
<civodul>yeah that's my impression, even after the switch to (guix store database) and all