<lfam>It looks like it is conservative in what it expects to use. find, grep, sed, that kind of thing
<lfam>It I was doing the work, I would try to avoid statically binding these dependencies, and instead find them at runtime
<dftxbs3e>lfam, to give an example, gnome-keyring depends on gcr at runtime for prompts, it's not in propagated-inputs of gnome-keyring, result I was stuck with a non-working gnome-keyring and has to debug obscure errors until finding out.
<sundbry>chroot *should* work fine as long as you are on a guix host os, you would want to kill the host guixbuild process and respawn it in the chroot
<sundbry>it needs the guixbuild users in /etc/passwd /etc/group, you would have to copy /etc/passwd /etc/group from the host into the chroot since there will be no /etc/ files.
<sundbry>also /etc/services /etc/hosts are necessary for guix daemon to run in the chroot (I am going off some notes I have here)
<sundbry>then run `guix-daemon --build-users-group=guixbuild &` to spawn the daemon and you can run all the `guix` commands from there
<sundbry>it is also a pain in the ass to run anything in the chroot without your profile loaded for $PATH so I recommend putting a static busybox binary in your chroot at /busybox so you can spawn a shell
<sundbry>you also have to mount /boot/efi in the chroot dont forget that.
<sundbry>really the best thing is if you can find the IP address in /var/log/messages then yo dont have to worry about any of that.
<jlicht>dftxbs3e: yeah, but preferably with tests still enabled; the issue with this package seems that running its tests is a bit difficult, so if the tests don't work anyway, it might make more sense to disable them (and provisions to run them) entirely
<jlicht>dftxbs3e: tldr: please apply the latest patch, but remove the line that says `(delete 'check)`
<dftxbs3e>jlicht, the latest patch seems to run tests but ignore return value
<PurpleSym>jlicht: I’ve tried fixing overlapping define’s from NPM’s importer by hand, but this is just not feasible with multiple packages like kind-of, which is pulled in in three different versions by ~20 packages :(
<jlicht>dftxbs3e: I derped, my email-refresh-cronjob broke, so I only read up to the one from yesterday
<jlicht>dftxbs3e: so never mind, on the entire thing. Thanks anway
<jlicht>PurpleSym: sorry to hear that. Just for later testing purposes, which command did you run?
<PurpleSym>jlicht: Same as yesterday, `./pre-inst-env guix import npm-binary -r fuse-box` and then I did some `curl -s registry.npmjs.org/is-descriptor | jq '.versions.["0.1.6"].dependencies'` to find out which is the correct version of the dependency.
<dftxbs3e>efraim, I am thinking GNU Guix packages so much stuff we can never keep up maintaining each and every of them
<dftxbs3e>I am thinking maybe it would be great separating well maintained packages vs best-effort maintained packages, so one user can choose to say "I only want well maintained packages on my system"
<dftxbs3e>cbaines, It would be great to have inside Guix Data Service information on when a package was last updated, or how often it is being updated, so one can go over the list of packages from oldest to newest and find the forgotten ones and update them.
<dftxbs3e>I believe it would require computing derivations for each and every revision of GNU Guix, which is expensive
<pkill9>I think it wouldn't be so bad if after computing which packages have been updated in a guix revision, you keep the results and delete the derivation, it would just take a while starting form the beginning
<pkill9>but once you got that information it's not going to change
<ngz>I have this package <https://paste.debian.net/1185115/> but when I try to run it, with, e.g., "wob 10", I get an error "Wayland compositor doesn't support all required protocols". Could anyone with a Wayland environment test it to check if it works properly?
<pineapples>wob? I was going to package it myself at some point
<vagrantc>hopefully i'll be able to propose some improvements for the next guix release to avoid most of that
<dongcarl>Hmm... So it's the tests that are downloading the binaries?
<vagrantc>yes, the tests will download the bootstrap binaries from the network if they are not present
<vagrantc>partly due to my request to not ship the bootstrap binaries in the tarball, as this is a violation of debian policy ... so the patch now dynamically downloads them ... through guix, of course, so if they're already in /gnu/store it won't
<dongcarl>vagrantc: Okay, so with all your patches applied, the bootstrap binaries are never downloaded, and only the tools you copied in are used?
<efraim>I haven't used gentoo, but my understanding is the bootstrap process is similar to an automated stage1 install. it has to build up to the base level and then it can start compiling everything "for real"
<vagrantc>luke-jr: other than the bootstrap binaries? as you can't build anything without them...
<narispo>efraim: there was quite fruitful discussion with them I could have
<narispo>efraim: someone just suggested we could get rid of cargo and use rustc directly, reimplementing parts of cargo within GNU Guix to fit our needs, we could even dynamically link stuff this way. What is missing is build script handling when doing that, so maybe we can rewrite build scripts in Scheme or reimplement that part as well.
<narispo>efraim: do you know where the other guy we had spoken conversation with is?
<ngz>hmmm. Silly question: how can I tell an executable to look into its own $out/lib directory when looking for a .so?
<narispo>luke-jr: what are you running? you are getting unexpected hash error?
<narispo>luke-jr: you can clone a gnu guix checkout, compile it without installing (see manual), then run ./pre-inst-env guix edit <package> - and you will see the hash there you can replace it and run your command again!
<rekado>luke-jr: not sure if that’s on purpose, but do note that using a store directory other than /gnu/store means that you cannot use any of the binaries that ci.guix.gnu.org (or anyone else) builds.