<NieDzejkob>mbakke: I located your commit for updating to GCC 7 and noticed that you also update gcc-objc and gcc-objc++. Should these get bumped in unison too? If so, it might be a problem that gcc-objc only goes up to 8, likewise for gcc-objc++
<mbakke>NieDzejkob: oh, were they removed? probably should set them to GCC 8 then
<NieDzejkob>mbakke: haven't investigated why they aren't there, assumed that they just weren't created like with gfortran
<NieDzejkob>pkill9: I don't think it's about hidden packages, it's just that some dependencies (those inserted by the build-system, to be exact) are implicit. you can see them with guix graph -t bag
<NieDzejkob>jcob: it's just scheme code, so you could also define a package in your system configuration file if you really wanted to (something like (define my-pkg (package ...)), and then use it in the (packages) field or pass it as an argument to some service...), but workflow-wise, channels are a better answer most of the time
<NieDzejkob>(also, if your package is generally applicable (i.e. not something like "dwm but with my custom compile-time options"), we'd really appreciate if you submitted it for inclusion into Guix - that way, others will be able to easily benefit from your work :D)
<procra>I am installing guix on a machine with linuxMX however the first time that i do a "guix pull" it give me an hash mismatch with the icu4c source code. I don't know if i should edit the expected hash (and how to do it) or if i should download the source code somewhere else
<GuixNewbie8128>Q: When creating a Guix environment, running 'guix describe -p $GUIX_ENVIRONMENT -f channels' prints an empty list. Why is this so?
<apteryx>procra: that's annoying. Let me see if I can reproduce the problem
<apteryx>procra: perhaps you could get around this situation by using substitutes, if you don't mind using these.
<NieDzejkob>procra: Could you paste the full error message? (paste.debian.net or similar) The hash for firstname.lastname@example.org matches for me
<apteryx>for me as well, using a slightly dated master (~3 days)
<apteryx>I got this message running 'guix build -S icu4c --check': warning: rewriting hashes in `/gnu/store/zmwl3q4gwn6fwqgi6x3389w28g540lsi-icu4c-67_1-src.tgz'; cross fingers
<apteryx>not sure what it's about, git grep tells me it happens in the daemon.
<NieDzejkob>GuixNewbie8128: the channels format is the machine-readable version of what's shown for an argument-less call to 'guix describe'. In other words, it only works for profiles managed by 'guix pull', such as ~/.config/guix/current
<NieDzejkob>is this just a curious question, or are you trying to accomplish something?
<jonsger>jboy: `guix edit` is missleading, it should be name `guix view` as you can look at the read-only package definitions on your system. To actually add package definitions you need to check out the git repo and work on that...
<stikonas>I'm trying to use "guix pack --relocatable --relocatable gcc-toolchain gnupg" and it doesn't work because of collision, gcc-toolchain has executable (not a folder!) called sbin which causes collision. Any ideas how I can install both of them together?
<bdju>I think I'm just gonna remove next browser from my system so I can go back to applying manifests. bug #42018 in case anyone has time to take a look. wasn't my main browser anyway so I'll live without it.
<mbakke>NieDzejkob: maybe something fishy with CROSS_LIBRARY_PATH? dunno
<mbakke>NieDzejkob: can you paste the build log somewhere?
<mbakke>NieDzejkob: did you try --target=aarch64-linux-gnu?
<mbakke>mothacehe: could it be that the substitutes haven't been "baked" yet? if you are the first unlucky person to request them, you'll get a 404 while guix-publish creates the NARs in the background
<mbakke>I've been wondering whether we should hack Cuirass to automatically request a substitute for built items
<mothacehe>mbakke: oh, forget about that, could be! But looking to the sqlite database, the recent hurd builds are (-2) scheduled.
<mothacehe>I suspect cuirass, once restarted, fails or chokes resuming old builds
<lfam>It's likely there's no technical barrier but I'm not very familiar with the issues. Usually it's more that work needs to be done adding support and communicating why the work is important and how the proposed solution is correct
<lfam>The communication part can be harder sometimes
<zimoun>mbakke, NieDzejkob: about #42132, I remember #38436 and then #38636. Well, the packages have been hidden by a7c75b8dbf and removing them could be another option at the time. So I will be interested to know the rationale. :-) If it discussed here, could you please report back in #42132? :-)