<luke-jr>rekado: I'm not willing to run binaries compiled by someone else, on any platform
<civodul>ngz: you're confusing the package name and the module name
<luke-jr>rekado: so even if I were on x86, I would be stuck here
<civodul>the module is called (semver), regardless of whether you're using 'guile3.0-semver' or 'guile-semver'
<civodul>but guile3.0-semver should be renamed to guile-semver
<badair>Using `guix system disk-image something.scm --target=aarch64-linux` cross-compiling from amd64, I get this output on the kernel build: "phase `patch-source-shebangs' succeeded after 2.9 seconds\nstarting phase `configure'\n`ARCH' set to `x86_64'" with eventual failure to find multi_v7_defconfig. Is kernel cross-compilation supported?
*janneke does some very boring sqlite bug bisecting through creating childhurd images
<ngz>civodul: Indeed, I'm just grasping at straws here… I'm not sure why it isn't found, though.
<murmr>NieDzejkob: I had turned it off on a previous configuration, but I was sure substitutions were back on in my current configuration. This is most likely the problem though, thanks for pointing this out. Will give it another try.
<stikonas>luke-jr: that cp command looks suspicious, first of all bz2 is moved to xz
<luke-jr>stikonas: it doesn't look like guix-daemon or guix are even opening it, so :/
<stikonas>luke-jr: is this a new installation of guix on gentoo?
<stikonas>I used guix ebuild from overlay but I think that one uses guile bootstrap binaries instead of building guile
<nckx>Guix is content-addressed, you can't just copy things into the store like that. The hash won't match, but in this case Guix indeed *won't* see it because it uses a database, and your (invalid) file isn't there. You need to provide different hashes that *match* your tarballs in %bootstrap-executables in gnu/packages/bootstrap.scm.
<nckx>If I could figure it out, anyone can. Good night #guix.
<nckx>(Oh, and use ‘guix download file:///each/of/your/tar/balls’ to properly import things into the store, don't ever use cp.)
<stikonas>^^ that's definitely not true :D I'm sure not every person in the world can replace guix bootstrap tarballs
***jonsger1 is now known as jonsger
<lispmacs[work]>what section of the manual explains how to offload your store builds to another computer?
<luke-jr>stikonas: yes, I'm trying to get it setup at leqast
<luke-jr>using guix download and updating that hash didn't work :/
<stikonas>I'm not really guix expert but what is the error?
<luke-jr>guix build: error: could not find bootstrap binary 'tar' for system 'powerpc64le-linux'
<lispmacs[work]>i was thinking there was a way to authorize a guix daemon on another computer to do my builds, but I'm not sure which section of the manual that is in
*luke-jr wonders why everyone calls it arm64 when it's unrelated to arm <.<
<nckx>But yes, two utterly identical files will end up in different /gnu/store/<hash> directories if they are built even slightly differently. And that different <hash> will affect everything built with them. Even if (say) /gnu/store/aaaaa-gcc and /gnu/store/bbbbbb-gcc are recursively *identical*.
<vagrantc>long-term goal for guix is to bootstrap from an auditable hex binary...
<vagrantc>which maybe doesn't seem *so* far off...
<luke-jr>nckx: is there a reason to base the hash on more than just the content?
<nckx>The Nix literature calls this the ‘extensional store’ (/gnu/store/<hash of all the inputs, WITHOUT the contents>-foo). The alternative (/gnu/store/<content hash>-foo) would be ‘extensional’ and is, well, a pain. You basically want everything to be reproducible and we're far from that.
<nckx>luke-jr: The hash isn't based on the content at *all*, not even partially, only the inputs.
<stikonas>vagrantc: since guile binary wouldn't be available, you would need to run guix with I guess mes?
<nckx>And not on their content but on their /gnu/store/<hash>! Ad inficetera.
<nckx>(Hm, not quite true when talking about sources, but true for non-bootstrap binaries.)
<vagrantc>stikonas: some little precursors to build up to mes, yes..
<nckx>Sources (‘fixed output derivations’) promise to return content that exactly matches their store hash, so they are effectively ‘inputless’.
<nckx>TL;DR don't ask the tired insomniac to explain things, especially when they volunteer.
<luke-jr>nckx: I understand it, even if I don't like it :P
<stikonas>luke-jr: well, I guess it's the same with git, hashes depend on previous hashes, not just on content
<pkill9>what does this error mean when running guix copy????? guix copy: error: implementation cannot deal with > 32-bit integers
<nckx>luke-jr: I'd (honestly) love to hear a better suggestion. The catch is it has to work now, in the real (not-yet-reproducible) world. So far all ‘but why don't you just…’ ideas I've heard don't. Don't let that discourage you of course 🙂
<nckx>The Nix/Guix model is damned elegant and robust (double buzzword bingo) (but really: damned robust) but certainly not perfect. As you note, it can easily err on the side of caution and build far too much.
<luke-jr>nckx: accept that the hashes will vary for non-deterministic builds? :P
<nckx>luke-jr: The hash is computed, it's not simply /gnu/store/<whatever you wrote in %bootstrap-blah>-bash.
<nckx>luke-jr: It does use it; it can't build bash without bash.
<nckx>luke-jr: What's the point of hashing file contents? I don't get it. The hashes don't mean anything anymore, beyond the tautological ‘we've hashed this file, now we have this file's hash’. You can compare them. ‘This file isn't that file!’ Great. Hours of fun. Babby's first IDS. But we already have those.
*nckx really going to bed now, best of luck. It certainly sounds like Guix is using your bash, since it can't build bash without bash. Bootstrapping! Yay!
<janneke>nckx: oh...sorry for stepping over your point; in fact i much appreciated you making it as it also applies to me.
<raghavgururajan>nckx: Thanks so much for building gst-plugins-bad and its dependencies.
<sneek>Welcome back raghavgururajan, you have 3 messages!
<sneek>raghavgururajan, nckx says: Started. Thank you for giving an exact commit, it removes all uncertainty! (HEAD just means ‘the tip of a branch’, but it doesn't say which branch…)
<sneek>raghavgururajan, nckx says: I would've assumed master and been wrong.
<sneek>raghavgururajan, nckx says: I'm also going to bed. This job is rather big (full jdk bootstrap, again, for reasons I refuse to understand). Don't forget to clear (both) caches before checking for substitutes! Good luck, and good morning.
<jrobst>Hi, I'm having problems getting a NFS client mount to work at boot. I've got a filesystem definition that creates what looks correct in /etc/fstab and it works mounting by hand. But if I have it mount automatically at boot (mount? #t) my guix system doesn't boot. Changing back to (mount? #f) and it boots ok and then I can mount by hand
<jrobst>herd status shows file-system-/users as stopped and herd start file-system-/users (the nfs mount) fails with invalid argument. Any suggestions where I should look ? Thanks
<mroh>jrobst: I like autofs/automount for managing mounts
<jrobst>Yes, I might switch to that later, I'm trying to get some experience with configuring the system and thought this would be a good start
<jrobst>mroh ok after some googling it looks like filesystems can't depend on the networking yet so nfs at boot isn't going to work. I see there is an autofs package - how do I setup auto.master and the like in config.scm ? Thanks
<nckx>pkill9: They are the low-level representation/result of #:modules in build-expression->derivation. Basically: the build-side modules, in a handy store directory that can be made available in the build environment.