<civodul>roptat: it's looking for "/tmp/guix-build-ant-bootstrap-1.8.4.drv-0/apache-ant-1.8.4/build/classes/org/apache/tools/ant/version.txt", which doesn't exist (yet?) <roptat>I pulled the new version, and trying to build ant-bootstrap, but I'm missing some substitutes, and my internet connection is not very reliable... <the_tubular>Damn, docker is going paid ... I wish podman would be available on guix :/ <dstolfa>the_tubular: it won't affect personal and educational use, only enterprise use. podman is great, but i think it depends on systemd? <dstolfa>guix, for scheme reasons, uses shepherd <dstolfa>the_tubular: what was managing the cgroups? <dstolfa>well, finding that out is probably the first step in getting it packaged for guix :P <the_tubular>I'm unfamiliar with cgroups, but that is a flag you can use <dstolfa>the_tubular: seems like it could be packaged pretty easily (for some values of "easily") <apteryx>yay! successfully built /gnu/store/422clla29k4kk0jbgiv7f2fa14iny2dl-rust-1.39.0.drv <apteryx>took a while, at 1h40m per iteration <the_tubular>That would be cool. I'm still not familiar enough with guile to try my hand at this. <the_tubular>There's an issue about cgroupfs saying it's broken on the latest update though, you might have to wait a week or 2 <dstolfa>the_tubular: i can just take the previous version <the_tubular>Also, I understand docker is only payed for entreprise, but that must be against the GPL somehow right ? <dstolfa>nah, you can charge money for GPL'd software <dstolfa>free software (roughly) means that whoever you sell the software to needs to also have access to the source code and be able to modify and redistribute that particular version <dstolfa>it doesn't mean that it needs to be gratis and that you can't be restricted from newer versions of software <dstolfa>that's how redhat operates for the most part <dstolfa>the_tubular: it's less likely than docker though, podman is a redhat project but it's also got community contributors <dstolfa>well, it didn't affect people all that much in the end. arguably the redhat ecosystem today is in a better state because of the dumb move that redhat did (ironically) <dstolfa>we got almalinux and rocky linux out of it (one which is pretty much on par with RHEL, and one which is heavily invested in HPCs on top of RHEL-like systems) <dstolfa>short of redhat killing their product, i don't see binary-compatible distros going away <dstolfa>they did, but it didn't really matter. it's script run away <dstolfa>i've migrated complicated servers and it all went smoothly <the_tubular>True, still that left a sour taste in plenty of people's mouth <dstolfa>yep, but i'd argue we're in a better spot because of it now <flatwhatson>dstolfa: the_tubular: i have a working LXD package sitting on the mailing list <dstolfa>honestly, the more of these we have the better in case things go south <flatwhatson>getting systemd images running just needed a phony systemd cgroup added <flatwhatson>i think getting podman running might be pretty straightforward <dstolfa>i think so too, it seems like the only thing needed is cgroupfs as a default and syslogd <the_tubular>Buildah and Skopeo should be straight foward after that corect ? <dstolfa>i feel like buildah should work without any special treatment <dstolfa>the main thing that might require some work is how /etc/containers/... usually looks in normal distros <dstolfa>we might need some way to configure the service <apteryx>sneek later tell civodul re the git cache update when doing 'guix pull -l'; OK, thank you for explaining, so it is expected in some situations! <EdLin>raghavgururajan: for what it's worth, dejavu looks a bit better probably. (I haven't tried gnu freefont) <EdLin>at least it isn't using the Google fonts by default, or Red Hat's, though as far as I know the licensing for those is OK. *Aurora_v_kosmose just noticed <EdLin>is guix multicore aware? Generating an image from a non-native guix packager seems to be taking a long time when it gets to kernel compilation, not something I'm used to on a Threadripper. <roelj>It seems that "guix pull" no longer updates for me. It seems to be stuck at 2d31eeecf since June 9. Has something changed that I need to be aware of? <roelj>Oh.. nevermind. I had it pinned in my channels.scm. <EdLin>that sounds like it'd do it. ;) <maximed>EdLin: see "--cores" and "--max-jobs" arguments to "guix build" <sneek>maximed, you have 1 message! <sneek>maximed, iskarian says: The implementation goes over my head, but the overall approach seems sound. I still think the (let (...) (package ...) idiom feels clunky and should be replaced with something else, though. Also, I think https://issues.guix.gnu.org/50274 might have the git-fetch updater effort in mind? :) <EdLin>maximed: how do I do those in guix image? <maximed>EdLin: do you mean "guix system ...."? <maximed>I'd assume "guix system" supports --cores and --max-jobs as well <maximed>If you don't want to repeat "--cores" and "--max-jobs" for every command, apparently you can pass them as options to "guix-daemon" <EdLin>maximed: I'm not familiar with guix's init system, how would I do that? <maximed>EdLin: Is this on Guix System or a foreign distro? <EdLin>maximed: I'm creating the image on a foreign distro, and will be using it to install guix native here. <maximed>If you're using guix on a foreign distro, you need to look at the init system there <EdLin>the guix native method for this would be more relevant, for the foreign distro, I can always just pass the arguments <EdLin>maximed: I'm doing both actually, will be switching to guix as soon as I have an iso that works to work with. <maximed>Do you want information for (a) setting a default for --max-jobs on a foreign distro, or (b) on Guix System, or (c) both? <maximed>For (b), see 'guix-configuration' in the manual <EdLin>the manual is on the website, right? <EdLin>do I need both cores and max-jobs? <maximed>and available as an info manual (type the shell command "info guix") if guix is installed <EdLin>I have 16 cores, 32 threads here... <maximed>max-jobs: how many derivations (approx. equal to packages) may be build at the sam time <maximed>cores: how many things may the derivation builder do in parallel (think of the -j argument to 'make') <EdLin>I have 64GB of RAM, what would you say would be the recommended values for this? <maximed>EdLin: I only have 4GB and 4 cores (or 4 threads, dunno) <maximed>possibly guix has reasonable defaults <EdLin>maximed: the kernel compilation took a bit unusually long. I was complaining about it several minutes in, and it took an aditional 5 minutes instead of the usual two and a half or so <maximed>dunno, maybe "--cores=15", and don't set --max-jobs? <EdLin>hm, OK. If it crashes and burns with that, I'll adjust it further. <EdLin>should work fine though if it's like say gentoo. <maximed>EdLin: building linux only takes 8 minutes or so for you? <EdLin>maximed: is there a way to tell it to use a different build drive? I have a small optane drive I could use to speed things up a bit <maximed>I haven't really measured it myself, but for me it's usually, dunno, half an hour to three hours or so? <EdLin>wow, is that a laptop or something? <maximed>EdLin: I don't know what a ‘build drive’ is, and what an ‘optane drive’ is <EdLin>maximed: a fast drive that's small, and I could tell guix to build the derivations on it? <EdLin>oh, that explains it, no SSD <maximed>EdLin: maybe you could mount the fast drive at "/tmp" <EdLin>maximed: I admire you for running it on modest hardware, must help a lot with optimizing development if you're a GUIX developer. <maximed>FWIW, Guix (or lowercase guix sometimes) seems to be the standard capitalisation <EdLin>maximed: is that where the derivations are built? Usually that's a ramdisk on most distros.... <maximed>A benefit of this ‘modest laptop’ is a ridiculous amount of disk space (932G) <EdLin>maximed: that's the size of the SSD I'm running this distro on too.... that isn't a large SSD currently, it's medium sized (it'd be a small HD) <maximed>The sizes of SSD has increased apparently <EdLin>biggest is 4gb or 8gb or so I think, but those are QLC nand usually <EdLin>tlc nand is more like 2tb as the biggest. <maximed>I have some ‘more modern’ hardware lying around (a laptop with about 100G or 200G SSD). I considered that a quite respectable size for a ‘mere consumer’ <EdLin>maximed: it wouldn't be if it ran Windows. *maximed checks the disk size <EdLin>my laptop has a 512GB SSD, and it gets fairly full regularly, I plan to upgrade it late this or some time next week to a 1tb, and move the 512gb into my desktop <EdLin>to be fair, I do content creation on it. <EdLin>so not normie consumer stuff I guess. <EdLin>256GB if all you do is the OS and a browser and maybe office programs, is enough..... <EdLin>even less if it's Linux, thankfully. <EdLin>I haven't seen laptops sold with less than 256GB for quite a while, Windows 10 and Office 365 and so on are disk hogs. <EdLin>but those are closed source programs and hence off-topic. :) <EdLin>a 512GB SSD is about $60 now <EdLin>so 256GB, if one can find one, is even less than $50. <EdLin>(they're included as the smallest size by some OEMs but aren't in all models of SSDs sold seperately) <EdLin>anyhow, enough hardware talk.... <EdLin>does that final line about /gnu/store tell me where the disk image is? <roelj>If I deploy my Guile program with the guile-3.0-latest package, how can I get the gnutls module to work with Guile 3.0.7? <maximed>roelj: Maybe it just works? There is some backwards compatibility between 3.0.2 and 3.0.7 I think <roelj>maximed: Well, I get "no code for module (gnutls)". <maximed>roelj: guix environment --ad-hoc gnutls guile@3.0.7 -- #guile -c '(use-modules (gnutls))' works for me <maximed>* guix environment --ad-hoc gnutls guile@3.0.7 -- guile -c '(use-modules (gnutls))' works for me <roelj>maximed: Right. So I put gnutls in the "inputs" field of my package, created a pack, unpacked it on a remote machine, run my application, and it produces "no code for module (gnutls)". <roelj>Do I have to put something on %load-path? <maximed>Does your package have 'guile-3.0' or 'guile-3.0-latest' in its inputs? <maximed>If this is an application, it presumably has some kind of binary <roelj>What's a good paste website? Then I'll share the details <maximed>the binary needs to be wrapped to set "GUILE_LOAD_PATH" and "GUILE_LOAD_COMPILED_PATH" appropriately <maximed>(or the Guile code needs to set %load-path and the like) <roelj>(oh, I see I already commented out the guile-3.0-latest, but I deployed a pack where I used guile-3.0-latest) <maximed>roelj: maybe verify if GNUTLS_GUILE_CCACHE and GNUTLS_GUILE_LOAD_PATH are set appropriately <maximed>In the directory $GNUTLS_GUILE_LOAD_PATH, there should be a file "gnutls.scm" for example <maximed>roelj: (not relevant to this problem) YOu shouldn't be hardcoding the name "pkg-config" in the configure.ac <maximed>when cross-compiling, something like aarch64-linux-gnu-pkg-config may be needed instead <maximed>(the plain pkg-config wouldn't even exist) <roelj>If you have a suggestion to how else I can achieve it, I'm happy to adapt it :) <maximed>roelj: How did checking GNUTLS_GUILE_CCACHE go? <Noclip[m]>Is source code access to proprietary firmware kernels needed in order to upgrade a device to newer kernel versions? <maximed>Noclip: What is a ‘propietary firmware kernel’? <maximed>The Linux kernel and the Hurd are free software, and not firmware <maximed>You don't need propietary firmware to upgrade (in the sense of guix pull && guix system reconfigure ...) <maximed>* guix pull && sudo guix system reconfigure ... <roelj>maximed: I strace'd the program, and it searches in '/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/share/guile/site/3.0' which contains gnutls.scm. So that seems fine. <roelj>maximed: But that's not the CCACHE. <Noclip[m]>maximed: The question isn't related to guix. I just assume that in this room are a lot of people who know the answer to my question. <maximed>however, some people need propietary firmware for the wifi. In that case, no wifi, can't get source code or substitutes, no upgrade <maximed>If device=laptop here: my laptop updates to newer kernels without trouble <maximed>and updating a kernel (typically?) doesn't require updating the firmware as well <Noclip[m]>maximed: The article seems to mainly referr to arm boards like the raspberry pi. <Noclip[m]>"and updating a kernel (typically?) doesn't require updating the firmware as well" <Noclip[m]>-> I thought that too and that is why the article confused me a bit. I'm now trying to bring light in the dark and understand things better. <maximed>I don't know much about the raspberry pi, Noclip <Noclip[m]>maximed: It's a similar situation as with most other arm computers including smartphones. <laanwj>*generally* kernel builds do not need any proprietary firmware as it is loaded from /lib/firmware when required, not embedded in the kernel, it is forbidden to do so for upstream kernels, some vendor-specific kernels (for boards that aren't supported by upstream) deviate from this <Noclip[m]>laanwj: In the article it sounds as if only the raspberry pi foundation could port new kernel versions over to the raspberry pi because only they have access to the source code of the binary blob. Does this make sense? <laanwj>Noclip[m]: yes-for how some vendor-specific (like in this case, rpi-specific) kernels are structured this makes sense, they contain board-specific drivers (sometimes even -ew- binary .o files directly linked in) that would never be accepted in Linus' kernel due to this, and work to support such boards in upstream will have to avoid binary blobs completely by clean-room reverse engineering, or if that <laanwj>is not possible, use the kernel firmware loading mechanism <laanwj>in any case this can be really annoying, often vendors don't upgrade their kernels anymore after a year or so, i personally tend to only use embedded boards that have upstream support like i.MX series <Noclip[m]>laanwj: Ah thanks. As far as I know pine64 takes foss fairly serious. <Noclip[m]>laanwj: Looks like I found the answer: "Currently the majority of Linux distributions for the PINE A64-LTS are using mainline Linux" <bsturmfels>I'm making progress on my `guix deploy` setup! I'm a bit unclear about how the certbot service works. I've deployed a config with a (service certbot-service-type ...), but don't see a certbot service in `herd status`. <mothacehe>bsturmfels: hey! certbot is triggered by mcron, you can run "herd schedule mcron" as root to find it. <bsturmfels>mothacehe: thanks! yes, support got back to me with a solution. Turns out if you choose an image type other than "BYO ISO" when provisioning, it uses a more automatic resizing method which seems to choke on the multi-partition Guix image. <bsturmfels>mothacehe: their resizing is actually pretty advanced compared to anything else I've seen eg. AWS/Linode. On say a Debian image, you can increase *or decrease* storage with a single button in the control panel, fully automated. <bsturmfels>as in, it increases the storage quota, resizes the partition and the filesystem either up or down accordingly <mothacehe>oh i see, we would need to work on providing bootable images with a single partition then. <bsturmfels>for this special case it would help, but probably not a high priority for others <mothacehe>yup, i'll keep that in mind. We could even file a bug report about it. <bsturmfels>I did also discover that if I `guix deploy` with the root filesystem device still set as /dev/vda1 as in the base image config, it won't reboot, since the EFI partition is actually /dev/vda1 and root is really /dev/vda2 <mothacehe>yeah, made that mistake while trying to test a few resizing commands on my own blog yesterday <bsturmfels>that might be the biggest win for a single partition - just easier to figure out <mothacehe>I think I'll create a new "raw" image-type, so that you can just type: "guix system -t raw your-os.scm" if itt works for you. <mothacehe>Grub is installed in the MBR-gap though, I hope it won't confuse their resizing tool <bsturmfels>they also confirmed they don't support QCOW2, but I can live with that now I know how to resize <bsturmfels>yay, your single partition base image boots fine, and resizes no problem on the non-automated "BYO ISO" operating system choice. On the "Debian" os choice the auto-resize increases the storage allocation and resizes the partition, but shows an error on the dashboard but all I have to do is "resize2fs /dev/vda1" and it's sorted <bsturmfels>mothacehe: my resizing issues may have been lesser than I realised all along - I had assumed that the failed booting after `guix deploy` was related, but now know that it wasn't. Two small solveable issues, rather than one big problem. (thanks to your help) :) <bsturmfels>mothacehe: actually, just double-checked the the previous multi-partition image on their auto-resizing "Debian" os config and it's properly broken and can't be worked around manually (without re-provisioning as BYO ISO). Your single partition image is a significant improvement in that respect. <muradm>in Nix there is "default.nix" file which can be put into some folder <muradm>is there anything similar for guix? <efraim>there's a convention to use guix.scm but nothing specifially looks for it <sneek>efraim, iskarian says: so what's your solution to building all source packages? I believe avoiding that that was part of the reason for putting inputs in cargo-inputs in the first place <mothacehe>bsturmfels: ok, we slowly progress :) If you can find the sources of their resizing tool we can maybe understand why it doesn't work on our image. <efraim>sneek: later tell iskarian building and testing them is good to make sure everything works. If it does turn out to be too much we could keep using #:skip-build? #t and it should still copy the sources into the output for the next package build and we keep our nice dependency chain <muradm>efraim: could you point to 1-2 example for inspiration? <muradm>btw, core-updates-frozen merged master? <muradm>guix from git manual suggests --localstatedir option to be specified at ./configure phase <muradm>why just dont specify --prefix and --exec-prefix ? <muradm>like ./configure --prefix=/ --exec-prefix=/ maybe <muradm>so that ./pre-inst-env guix system reconfigre ... would work properly? <roptat>muradm, I think it will work, but have never tested it <roptat>--prefix to / is not what you want in general though, if you want to install the result <muradm>then in order to run "./pre-inst-env guix system reconfigure ..." for my local system, i have to specify "--localstatedir=/var --sysconfdir=/etc" two options? anything else? *attila_lendvai wrote a detailed response for the go packaging discussion on the mailing list <attila_lendvai>i was also tripped up by the docs not mentioning the necessary args for ./configure and in some situation it was not erroring either <maximed>attila_lendvai: There was some discussion in the past about adding --localstatedir=/var by default <maximed>The option is documented under ‘2.2 Requirements’ <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: re the git cache update when doing 'guix pull -l'; OK, thank you for explaining, so it is expected in some situations! <zimoun>“guix environment –ad-hoc texlive-tiny texlive-beamer – pdflatex talk.tex” tells me than beamer.cls is not found. What do I miss? <zimoun>civodul: about python2-, I think the plan is: keep them while it works. :-) Morever, python2-markdown is removed by the patch but “guix refresh -l python2-markdown” returns python2-cheetah which is not removed. Therefore, the patch will breaks unrelated packages <zimoun>rekado_: maybe you have an idea about my previous question about beamer. :-) <bsturmfels>civodul: oh, I've misunderstood how the "package-with-python2" function works. My claims of these packages being unused are likely to be all wrong <apteryx>civodul: I'd say go ahead if they're not used by anything else of value (especially, since itsdangerous!) <zimoun>bsturmfels: note that I provided in the patch submission some python2- which are removable. ;-) <bsturmfels>zimoun, civodul: would you suggest I close that bug and reopen with just the *actual* leaf packages, or forget it all and stick with "keep it while it works"? <cage>Hi! This time i have no questions or problems to submit, instead i would just say thanks to all the channel for all the support the person here gave me in this last months each time i needed some help! :) <bsturmfels>zimoun: is there any way to mark packages as pending removal? so that they show a warning when you install them? <zimoun>bsturmfels: Nothing I am aware. Maybe deprecated-package could used. I do not know. <civodul>zimoun, bsturmfels: oh i see; maybe bsturmfels can send a v2 that only removes the subset of these packages that are leaves? <zacchae[m]>I tried building linux-libre for aarch64, and it crashed saying I ran out of disk space. I checked after and both my host machine and the drive I am trying to install to have > 15G of free space. Am I really running out of space (and the used space is just clearing after crashing) or should I make a bug report? <nckx>zacchae[m]: In /tmp though? <zacchae[m]>why would /tmp be different though? I have a pretty simple setup. /tmp is on the same filesystem as everything else <nckx>Because it frequently is. <nckx>(See pastebin in topic.) <zacchae[m]>I'm building from a foriegn distro because I don't have an arm device with GuixSD <zacchae[m]>building /gnu/store/piwz7glbxagnnhmsg9x78krm8r7cngb2-linux-libre-5.13.12.drv... <zacchae[m]>- 'build' phasenote: build failure may have been caused by lack of free disk space <zacchae[m]>builder for `/gnu/store/piwz7glbxagnnhmsg9x78krm8r7cngb2-linux-libre-5.13.12.drv' failed with exit code 1 <nckx>If the ENOSPC happens during build, yes. <nckx>That's just a hint, it doesn't mean you ran out of disk space... <nckx>Check the log file it should mention. <nckx>If not, guix build --log-file <the above .drv file>. <zacchae[m]>I looked at the log and every error says "can't write ... no space on disk" or "cant close ... no space on disk" <nckx>That's why I don't like all this paraphrasing ☺ <nckx>My tmpfs is 15G and I've never had a build failure due to that, but maybe things are different there. Is anything building in parallel? Have you tried keeping an eye on ‘watch df -h’ during the build? <nckx>Actually, as far as low-tech approaches go ‘while sleep 1; do df -h /gnu /tmp; done’ is probably better; watch won't log history. *nckx still warming up from a long rainy run. <zacchae[m]>You say 'building in parallel'. It is using all four cores to compile linux-libre, but I am not running any guix commands but 'guix system init' <nckx>Right, I meant other packages specifically. I doubt building linux-libre with -j4 alone has a measurable effect. <zacchae[m]>IIRC, I had this problem trying to cross-compile this from an x86 computer (for aarch64), and I came across a similar error, but I assumed it had something to do with guix system image not estimating image size correctly, so I switched to what I'm doing now because it seemed more robust: guix system init from guix running on foreign distro running aarch64 linux kernel (archlinuxarm) <nckx>That code could easily print *which* (/gnu or /tmp) is low on space but doesn't :-/ <nckx>Yeah, that's a totally different guessing mechanism. ☺ <nckx>You said it wasn't its own file system above 😛 <nckx>No problem, but 4G being little is at least plausible. *nckx happens to be building Linux too; will keep an eye on /tmp; now -> ☕ <nckx>It finished, and /tmp usage spiked to 1.5G for the last few seconds. But this is not the default Guix kernel configuration; it's not implausible that a distro kernel that includes modules for every thrift-shop MIDI keyboard ever made might push 4G. <sneek>Welcome back iskarian, you have 1 message! <sneek>iskarian, efraim says: building and testing them is good to make sure everything works. If it does turn out to be too much we could keep using #:skip-build? #t and it should still copy the sources into the output for the next package build and we keep our nice dependency chain <roptat>civodul, it looks like the change on jboolean doesn't modify isFile at all, according to objdump, it's exactly the same <roptat>and I tried to reproduce the issue with something smaller, but I can't even with the same function (checked the assembly is the same, except for some addresses) <ss2>How do I select a package that has an identical name from my own channel? <ss2>I copied the definition, but kept the package name the same. Is that a good idea? <ss2>Or would I best modify the package name. That also means that dependencies in that channel have to be renamed as such that they all find each other? <roptat>you can select different versions with foo@1 or foo@2, foo@1.5.2, etc <iskarian>Heh, I didn't expect (but am glad for) the spirited discussion re: unversioned packages on the ML <roptat>but if it's the same version, you can't select the channel it comes from, and guix will select an arbitrary package <ss2>The versions aren't even different, well they are actually. So there is no way to specifically select a package from a channel? <ss2>okay, then I'll rename it. <roptat>you can use something like -e '(@ (my channel) foo)' <ss2>yeah, and it might not be obvious in the profile from where the package is coming from. <roptat>civodul, in fact it's so much not different that it has no effect for me, ant-bootstrap still fails saying build is a file <roptat>civodul, looks like your initial patch does the trick, but we can't remove the workaround for isDirectory <civodul>roptat: re jboolean, i guess i only observed that ant-bootstrap failed in the same way and thought that it had the same effect as the initial patch <roptat>civodul, ant-bootstrap still fails not finding version.txt <roptat>but the changes to isFile are enough to make it pass if we keep the previous workaround for isDirectory <roptat>and the same workaround for isFile doesn't work, so I think the problem is different *civodul tries the patch above, without the remove-call-to-free phase <civodul>i wondered whether there was stack-mashing happening around the call to (*env)->..., but that didn't seem to be the case <civodul>roptat: still version.txt/CLASSPATH problem with this patch <roptat>yes, that's what I'm telling you, we can't get rid of the isDirectory workaround <civodul>this whole situation is unsatisfying <roptat>that's what's causing the issue with version.txt <civodul>did you try tweaking Test.java to test isDirectory specifically? <civodul>yesterday i got somewhat useful info running it in gdb <civodul>i'm glad these things don't take much time to build <civodul>roptat: isDirectory behaves correctly with the patch above <zacchae[m]>Is it normal for one guix system init run to build multiple linux-libre versions? (all have linux-libre-5.10.61-guix, but they have different hashes in front) ***LispyLights is now known as Aurora_v_kosmose
<civodul>zacchae[m]: that looks fishy; maybe it can happen when building something like zfs-on-linux though <zacchae[m]>civodul: I'm using a pretty minimal system config on an ext4 filesystem. My understanding is that for a given architecture and code version, the hash should be uniquely determined, no? Here is what I'm seeing: <zacchae[m]>building /gnu/store/1kw6c6jp6xq6r3jgac6rxhmi3vb9cgf4-linux-libre-5.10.61-guix.tar.xz.drv... <zacchae[m]>building /gnu/store/w4svqapdkgvpjfn0lgs9qnpskydz3n89-linux-libre-5.10.61-guix.tar.xz.drv... <zacchae[m]>I'm installing GuixSD from a foreign distro, all on aarch64 for those interested <civodul>zacchae[m]: oh, it may be that some substitutes are lacking for aarch64 <civodul>so you end up rebuilding the kernel (and its "cleaned up" source) locally, which can take ages <nckx>Both are available on ci.guix. <civodul>"guix weather linux-libre -s aarch64-linux" on a recentish Guix (f91ae9425bb385b60396a544afe27933896b8fa3) tells ci.guix doesn't have it but bordeaux.guix does <nckx>zacchae[m]: Note that both of those are source tarballs, not the binary Linux kernel. <nckx>I would have guessed -guix to be the librefied version, but, well, they're both -guix so I don't really know. <nckx>civodul: You're right; I misread. <civodul>cbaines: hello! are you aware of uses of the "System" field in narinfos, for example in the Data Service? <civodul>i was suggesting to no longer emit it in narinfos produced by 'guix publish' <roptat>civodul, but ant-bootstrap still fails <civodul>we'd need to step through the code that walks the class path <civodul>to find out what makes it stop too early <civodul>but i have no idea whether that happens <civodul>this miscompilation issue is really weird, too <cbaines>I'm not even quite sure what it means, is it just the system of the derivation <civodul>so it's redundant if you have the .drv <roptat>civodul, well, it must be in classpath, if changing it solves the problem, no? <civodul>zacchae[m]: both are now included by default, starting from a month ago or so <zacchae[m]>civodul: if the repo comes up in guix weather, does that mean it's already added? <zacchae[m]>because if so, then my guix should be finding it already...