<reepca>civodul: regarding warn-about-old-distro, it uses %profile-directory instead of config-directory. %profile-directory only uses $USER and $LOGNAME. Perhaps it should be using config-directory instead?
<OriansJ>dongcarl: the prebuilt binaries are the results of the build servers you have selected to trust doing the very builds that are slow on your current machine. Essentially, they did the same thing you are doing only they started earlier
<OriansJ>And it is possible for one to get different results than the prebuilt binaries if the package has reproducability issues
<OriansJ>It is a way of allowing users to get binaries for the programs they need, while work is done to get those packages more reproducible if possible. Fortunately the Debian project is doing alot of heavy lift for us in that regard.
<OriansJ>It only comes up when someone runs guix challenge on a non-reproducible package which doesn't even produce the same results on their own machine over multiple rounds
<roptat>grafoo, this looks like an expat or x11 license, so yes
<wigust>tune: Probably PATH. Why do you think your PATH is wrong with ‘-E’ flag? According to ‘sudo’ man page it preserve the environment. You could compare environment with ‘diff -u <(sudo -i env) <(sudo -E env)’.
<apteryx>hello! can I add a function to (guix build utils) without having to rebuild the world? I thought if the function isn't used by the build system, I should be OK, but it seems it computes the hash for the utils module as a whole?
<atw>I am trying to install GuixSD on a https://prgmr.com/ host. My current approach is to install Debian on the host, download the GuixSD iso, then try to boot it with something like https://paste.debian.net/1061526/ at the GRUB command line, but doing that and then "boot" doesn't print anything and doesn't boot GuixSD.
<dongcarl>If I'm understanding this correctly, since bitcoin depends on qtbase, which depends on nss, and nss wasn't able to be built deterministically, the check failed
<dongcarl>I'm wondering what the easiest way is to mess around with the build files of these packages, and if, after messing with them, it makes sense for me to be doing `guix build --cores=0 --rounds=2 --check nss`
<pkill9>it doesn't even build twice for me when i run `guix build --rounds=2 --check hello`
<civodul>pkill9: right, --rounds is ignored when using --check
<civodul>dongcarl: --check cannot be used for something that has not been built yet
<civodul>in this case you caught an non-determinism issue in 'nss'
<civodul>you can ignore it by first running "guix build bitcoin-core"
<civodul>and once it's done, run "guix build bitcoin-core --check --no-grafts --keep-failed"
<civodul>that'll allow you to dismiss the nss issue
<civodul>(unless you want to fix it, which would be nice too :-))
<eubarbosa>Ofc, you can read it and debug it yourself if not that hard
<serichsen>I have a problem when trying to boot my new system (after guix system init): it hangs in the middle of booting, but I can't find any logs. /mnt/var/log/ is empty (seen from the installation boot).
<dongcarl>civodul: If I understand you correctly... `guix build bitcoin-core --check --no-grafts --keep-failed` would let me know the determinism of bitcoin-core relative to a specific state of dependencies, as in, it ignores the non-determinism of bitcoin-core's dependencies by pinning them to a specific hash/build, and builds bitcoin-core on top of those fixed dependencies several times to check that bitcoin-core itself is detemrinisti
<janneke>dongcarl: we think so too, tell your friends ;-)
<dongcarl>janneke: I've been telling my Bitcoin Core Dev friends and they really like this. Reproducibility and bootstrappability are things we take seriously, which is why we made gitian, but this is just... Much better tooling...
<vagrantc>not sure if there are drawbacks to that method
<rekado>dongcarl: that’s for installed packages. Since you don’t install the “guix” package with Guix (you use “guix pull” instead) you still need to add ~/.config/guix/current/bin as the first directory in PATH.