<apteryx>sneek: later tell tibbe do you have an idea of how --check should be changed to make it more natural to use? One idea: if the package isn't in the store yet, fetch it as a substitutes or build it once, then proceed to build it a second time to validate the result.
<dannym>On guix pull in there, it's downloading a lot of X related stuff and latex and whatever else, though. That's not really a bug I guess--but it was unexpected. (see post on guix-devel about that)
<sneek>zimoun, apteryx says: I can't reproduce your problem with: 'guix build --check --no-grafts -K git'. Perhaps it is triggered only when the --check failed?
*rekado reads “Surviving the TeX font encoding mess” presented at EuroTeX 99 in an attempt to understand what might be wrong with our modular TeX Live packages
<dannym>There are already bug reports in Docker about COPY not preserving timestamps--and they don't care
<dannym>If timestamps are not preserved, then it copies in a random order, which for me meant guile thought that all guix scm files were newer than the go files and thus didn't use the go files .... veeery slow!
<mfg>rekado: thank you for fighting with TeXlive :-)
<zimoun>apteryx: yes, it is triggered only when it fails. However, I am not convinced that all the outputs are checked… Not easy to find a package with 2 unreproducible outputs. Maybe ’sbcl’ fits.
<dannym>civodul: An easy way to "fix" this is by just also releasing an official Docker image whenever we release guix. The question is whether we want that--people will expect this to work pretty well then
<dannym>And I don't think we need a general docker registry where all the derivations are available (at least that's not my goal), but just a place to get guix
<dannym>That means we can just install static files and no web services
<dannym>For example install a static file /v2/_catalog with some fixed JSON content, install static file /v2/<name>/tags/list with one entry and provide /v2/guix/manifests/<reference> as a static file and so on
<dannym>And basically give the user a docker registry with one image on there, guix; which updates from time to time
<dannym>I mean it would totally be possible to swap out guix-daemon for docker as the backend that is doing our actual derivations--but that should be a non-goal for now ;)
<zimoun>dannym: Maybe that’s the road. I do not know.
<dannym>That said, there's nothing wrong with gitlab doing the hard work (building Guix from source, publishing it to their registry, hosting the registry for user)--I'm pretty satisfied with how guix-on-docker is now, and it really doesn't have to be part of Guix proper.
<dannym>But like it is now, users that pull guix-on-docker from gitlab using docker have to trust gitlab, and also trust savannah. More required trust that would be nice :)
<dannym>It would be nice if the user didn't need to trust both
<zimoun>What could be nice on this path should be able to generate a Docker image from a manifest; the image only hosted a coupled of hours/days. Not necessary being part of Guix proper. The –save-provenance is a killer feature that many scientists dream (as any dream, they are not really aware yet ;-))
<zimoun>I agree that guix-on-docker looks nice. I will try it soon.
<PurpleSym>zimoun: I have a guix integration for GitHub’s CI which works quite well. It’s just slow, because I need to run `guix pull` every time.
<dannym>PurpleSym: I wonder why the cache doesn't work, though. (I didn't try putting /gnu/store on a shared volume on gitlab yet, so I don't know whether there are the same problems there)
<dannym>civodul: As for Heads: I'm talking to the founder of Insurgo regularily. I can suggest other approaches to him.
<dannym>civodul: Right now, they are building Heads on two different CIs on github, and also on gitlab
<dannym>civodul: In order to find reproducibility problems. Which they did find.
<dannym>civodul: That's why they approached me. They had heard about Guix on FOSDEM
<dannym>civodul: It's clear to me that first they have to be convinced that Guix is better than what they have now (no containerization of packages, and Makefiles)
<dannym>civodul: Basically their previous way of getting reproducibility started not working anymore--because they forgot to refer to some dependencies in their Makefiles that they were using
<dannym>civodul: So it picked up the host library :P
<dannym>civodul: By now, I've got them ready to try Guix
<efraim>I use btrfs for /gnu, I can look up how much it saves when I get back to my computer
<dannym>civodul: But in the end getting Heads to work on Guix is a lot of work (I had tried before--it's not easy) because they are targeting flash chips--so they are using musl, sometimes static linking and generally disabling a lot of features
<dannym>civodul: Right now, they are using musl-cross-make as toolchain
<zimoun>dannym: just to understand the discussion. What is Heads?
<dannym>civodul: If they wanted to use Guix, I could package musl-cross-make (I've packaged musl-cross (that's what they had used previously) before, and it worked for a while)
<PurpleSym>zimoun: Yeah, I was thinking about presenting our overall Guix setup (not just guix-science) there.
<jonsger>zimoun: heads is a distro with a key feature running every application in its own VM, AFAIK
<dannym>lfam: With an imminent Guix release (if you want this to be in there), I would recommend disabling this kernel config option for the time being (... disabling it will totally come back to haunt us later with something else, though).
<lfam>Yes, as a heavy user of tmpfs I would like to enable it eventually, but we can disable it for now. I haven't been paying attention to the release discussion and I don't think it matters much if 5.9 is part of it
<dannym>lfam: In an ideal world, I would recommend fixing bug# 43513 and not have any other weird workarounds. But that's gonna take time, rebuild the world, and also right now core-updates has other problems, so I can't even do it.
<lfam>We have 5.4 which will be supported for 5 more years, and that is good enough for a release
<mfg>is it possible to only show failed builds in the guix data service?
<dannym>lfam: Ok, if it doesn't go to master (yet), I would enable it. I'd suggest to enable it on core-updates then (that's where we'll fix bug# 43513, eventually, too). Or where does this go then?
<lfam>dannym: Typically kernel updates go to master. Major updates go through a 'kernel-updates' branch but it is supposed to have a short timeline
<lfam>Should I make a followup commit on core-updates to enable the option?
<cbaines>mfg, in which bit of the Guix Data Service?
<efraim>there's no TTY available in the build environment, right?
<Zambonifofex>rekado: I’m sorry to pester you, but I was hoping to be able to wonder whether you have ended up updating the `netdde` package for Hurd. If you’d like, I could try more thoroughly once again by myself, if you think it’d be helpful.
<efraim>no, there is. I see it in nix/libstore/build.cc
<divoplade>There's something really frustrating while writing guile code: I want to write some data to a file, and it's always the same thing. First, call with-output-to-file. If it fails, parse the file name, remove the base name, and try to make the chain of directories, and then re-try the write (but not recursively, stop if there's an exception this time).
<divoplade>I wished there was a with-output-to-file* that did all that.
<sneek>niko, nckx says: Ideally, you *don't* install P's dependencies alongside P. On Guix, ‘installed’ (the package is available in the current profile/environment, its binaries can be invoked from $PATH, &c.) and simply ‘present on the system’ (not in your profile/environment but still in /gnu/store, from where packages that depend on it will load it directly) are different things.
<sneek>niko, nckx says: Your package should load its exact build-time dependencies from /gnu/store/<hash>-…, not even noticing whichever random versions the user has installed at any time. Most build systems take care of this for you.
<leoprikler>and yet there's no POSIX-mandated mkdir_p function as far as I'm aware.
<divoplade>Well, guile has a lot more functions that what posix mandates ^^
<leoprikler>Sure, but mkdir is specifically part of the POSIX stuff ;)
<divoplade>I doubt the file tree walk procedure are part of posix
<divoplade>I have an implementation of mkdir-p in each of my non-trivial projects, and now guix too, but we can't really use the same version because that would be unreasonable dependencies. Should we go full NPM-style and have mkdir-p as a separate package, or maybe guile could provide it?
<civodul>Gash-Utils could become the library of shell-style functions that everyone uses
<leoprikler>+ 2 more, because guile-gi and g-golf provide bindings to g_mkdir_with_parents ;)
<leoprikler>civodul: only for GPL'd libraries, but yeah, that's probably an option
<divoplade>gash-utils is already more reasonable to link against than guix :) That being said, I doubt any of the projects have a use for most of the other functions. Look at that beautiful function "rmdir-p" in gash (shell-utils). The doc string looks very promising!
<divoplade>"Remove directory DIR and all its ancestors."
<divoplade>(well, in fact it removes all ancestors until ".")