IRC channel logs
2026-02-15.log
back to list of logs
<mange>Is there a way to run a Cuirass remote worker which will run builds with --cores set? I haven't looked hard, but I didn't find anything obvious in the Guix configuration options. <roptat>do you know how I can "touch" a file in guile? <roptat>I want to reset the modification date, not change the content <identity>(system* "touch" filename) is definitely one way to go about it <roptat>ah, when looking with the correct keywords, the manual gives "utime" <ekaitz>make-mesboot0's build is frozen in riscv64 <ekaitz>basically: suspended shell linux <janneke>ekaitz: is that a regression of some sort? <ekaitz>janneke: i've seen that happen before, but it happened earlier in the bootstrapping chain <ekaitz>but that produces a circular dependency and it's problematic <ekaitz>locally i can use it, but we need to sort that out in order to merge the riscv bootstrap <janneke>ekaitz: hmm, is there a bug report @ codeberg about this? <coopi>Finally managed to to fix a longstanding bug within my system!! <coopi>I couldn't figure out why my audio was broken <coopi>turns out the culprit was (the lack of) sof-firmware <janneke>coopi: yeah, bah; even sound needs non-free code (or a non-free signature on otherwise free code to load?) <janneke>ekaitz: is there a bug report @ codeberg on this? <coopi>janneke: ive kinda just given up on the "free-ness" of modern hardware :') <coopi>right now im just ecstatic to fix an issue which was personally one of the most annoying one i'd faced <ekaitz>janneke: not yet. I'm building it in my laptop, virtualized, trying to reproduce <janneke>coopi: well, what i mean is that it would be good to know about these "hidden" problems <janneke>ekaitz: yeah, a reproducer would be great <ekaitz>janneke: it reproduces in a visionfive2, but a virtualized reproducer is key here <janneke>yelninei: i believe i only looked at the cross-build for fibers, yes <yelninei>janneke: yes the hurd glibc does not support the feature that fibers uses for scheduling interrupts (clock_nanosleep with a clock from pthread-getcpuclockid) <yelninei>This is not a problem for shepherd because it disables preemption, but causes the fibers test to hang because the expected interrupt never happens <janneke>yelninei: that sounds as if it warrants a bug report for fibers? <yelninei>janneke: I'll forward the issue to fibers. Should the test be skipped in the meantime? <janneke>yelninei: lovely, thanks! and sure; let's skip the test in the mean time <janneke>you can add a comment referencing the issue(s) in the code skpping the test <yelninei>there is another test failing afterwards because the heap grows 4x instead of the "allowed" 2x <janneke>maybe use same recipe, i.e., another fibers bug mentioning this? <janneke>yelninei: without having looked at the details, if the test demands memory usage to be less, and it isn't, something is wrong :) <janneke>the fiber developers may well defer this bug to guile again, but i don't see that a as a problem <yelninei>janneke: well there are the "Repeated allocations of very large Block warnings" from libgc again so this might be related. On x86_64-gnu it almost makes it with only a factor of 2.3 <janneke>yelninei: yes, it could even be a libgc bug...and then there's the guile-4.0 move to whippet <janneke>but it's still something that's been bugging guile on hurd for quite some time now <yelninei>janneke: At least it seems to also happen on debian judging by the buildlogs for guile packages and is somewhat related to setting LC_ALL (to a utf8 locale) <folaht>I have a question. When I installed a flatpak application in.. let's say Arch, said application would show up in the application menu. <ekaitz>janneke: mescc: failed: M1 --little-endian --architecture riscv64 -f ../lib/riscv64-mes/riscv64.M1 -f lib-stdlib-puts.s -o lib-stdlib-puts.o <folaht>Is there a reason that it doesn't on guix? <ekaitz>janneke: guix build ... --system=riscv64-linux <janneke>ACTION hasn't had much if any success with a qemu > 7 riscv vm <ekaitz>me neither but i don't know why that is <Rutherther>folaht: on Guix System? Did you add flatpak's exports/share dir to xdg data dirs? <ekaitz>janneke: i'm stuck here then, i cannot reproduce this here <ekaitz>I don't have the inferior configured <folaht>Rutherther, do the flatpak's share dirs need to be added to xdg data dirs manually? <Rutherther>folaht: uhh, what do you mean by 'manually'? What are you using for management of your dotfiles? <folaht>Rutherther, I think it's probably a good idea for me to actually start learning guix instead of doing web searches. <Rutherther>folaht: easiest is just to add the flatpak package to etc-profile-d-service-type if you're installing flatpak system wide already <folaht>Rutherther, thanks. I'll keep that in mind. <Rutherther>installed packages cannot arbitrarily affect your environment like on other distros when you install them. Installing a package via "packages" in your system just means to add its files to /run/current-sytem/profile and potentially expose environment variables that point to that profile as well. You cannot expect packages to add services or /etc/profile.d files like installing packages does on other distros with FHS package managers. <Rutherther>For actually taking the desired effect other services has to be used, such as the etc-profile-d-service-type that will put the packages files to /etc/profile.d <Rutherther>...that is if the package already provides them, flatpak does <ekaitz>janneke: opened an issue in gash, it's very vague but that's all I have <ekaitz>janneke: if you want to try it I can give you access to a riscv machine <ekaitz>in the meantime I'm compiling qemu 7 <janneke>ekaitz: i'm trying qemu once more, right now <janneke>"someone" will have to bisect the config.status run... <ekaitz>i'll run it again in the visionfive2 and let it fail <janneke>yeah, /me had it so easy with only x86 :-P <ekaitz>that's what worries me from germ <futurile>folaht: how's your exploration of Guix System going? I just saw you asked some questions on System Crafters as well <yelninei>i forgot how pleasabt it is to compile things with more than 1 core <yarl>janneke, futurile: you've got mail! <janneke>ekaitz: sure, i get that; but to me germ is mostly "mes mindshare", with possibly an even bigger focus on a fully scheme bootstrap and on cleanliness (what you're also working on) <futurile>yelninei: wow, nice - I'm definitely going to give it a try <futurile>yelninei: I wonder if anyone else doesn't anything similar <yelninei>futurile: I don't understand what you mean by that <yelninei>note to self, it takes about 1.5h to rebuild a hurd image completely <yelninei>the most expensive builds are guile and guix itself <janneke>yelninei: you found another thing that's not the problem... <roptat_>alright, I've rebuilt maven after setting openjdk9 as the default java (instead of java 8) <roptat_>there's still some work to do, but we're getting closer :) <yelninei>i dont actually need to build guix for just testing that it works maybe i can safe some time by removing it <rbcj>hello, where is the proper place to find information on how to add self-signed certificates authority in GUIX? Basically I want to get the same when one execute update-ca-certificates in other distros. <Rutherther>rbcj: on Guix System you mean? I am not sure there is a guide, but it's fairly simple. Make a package that outputs the certificate as etc/ssl/certs/<cert>.pem, presumably using copy-build-system to just copy the file. Then install that package to your system, putting it to the "packages" field. <yelninei>maybe its the mig alignment patch? but adding a patch to mig introduces a circular dependency <yelninei>savannah not cooperating does not help either <rbcj>Rutherther, thank you, I'll give it a try. <janneke>yelninei: you updated the issue with this info, very nice! <yelninei>i had that patch originally but because I could not add the patch i dropped it again <yelninei>i guess we could update to the commit directly? debian libc has a compatibilty patch "until everything is rebuild against the fixed mig" but I dont think we care about this as updating mig will automatically rebuild everything? <janneke>usually we update (twice a year?) to new tags, but i don't see a reason not to update to this commit <yelninei>janneke: I'll try to see if it fixes the other issues as well, there also seems to be a new mach tag, not sure about other things like more libc patches <yelninei>also thanks for nerdsniping me back into this :) <roptat_>almost got java-jmh (which uses the maven-build-system), so I built all plugins, but some of the pom files are not working anymore <yelninei>mhh the cgit snapshots from the savannah cgit that are used in commencement.scm seem to be no longer available? <yelninei>janneke: savannah does not seem to serve the tar.gz snapshots anymore that are used with git-fetch-from-tarball <yelninei>janneke: this might also allow us to remove some of the target-hurd64 guards simplifying everything <old>is there a manual for using mumi ? <janneke>yelninei: eh, but we don't have git yet there, do we? <janneke>if savannah no longer serves snapshots, we'll have to create and serve tarballs ourselves? <janneke>this is getting more and more ridiculous <janneke>yelninei: /me tries asking over at #savannah <yelninei>IIRC It was not a problem for me before because i had a wrong hash there once and it just used git-fetch, but I dont quite understand how git-fetch-from-tarball works <ekaitz>janneke: qemu 7 installed. Cross fingers for me <ekaitz>janneke: any idea why qemu >7 fails? <janneke>that was in the qemu-8 era, we're not at qemu-10, which i'm trying <janneke>guile: warning: failed to install locale <janneke>guile: warning: failed to install locale <janneke>guile: warning: failed to install locale <janneke>guile: warning: failed to install locale <ekaitz>janneke: hey! i tried the same with qemu-10 and gave me the mescc error! <janneke>yelninei: well, snapshots were just disabled on savannah because, AI, and "nobody needs them anyway" <ekaitz>still in qemu 7: mescc: failed: M1 --little-endian --architecture riscv64 -f ../lib/riscv64-mes/riscv64.M1 -f lib-mes-write.s -o lib-mes-write.o <ekaitz>this happens in *every single* file <ekaitz>it happened with 10, that's why i tried with 7 <yelninei>janneke: Another minor problem is that on a system built with the new mig the bootstrap guile (and i guess everything else) no longer works at all. <janneke>yelninei: nothing works...that sounds bad <yelninei>janneke: i guess thats the "until everything is rebuild against the fixed mig" part <ekaitz>janneke: no way to make this thing say anything else than the "mescc: failed" <janneke>ekaitz: which thing? -- you said there was a problem with config.status? <janneke>and you also know all about MES_DEBUG=N mescc ..., right? <ekaitz>janneke: just building mes fails with all that mescc: fail <ekaitz>if I do in the visionfive2, it does build <ekaitz>i mean, as is, the bootstrap-team branch does not build mes for me <ekaitz>the mes build process does not stop when one mescc fails, so it tries to do every single file <janneke>so mescc just exits 0, while also failing? <ekaitz>yeah i guess that's what it's doing <ekaitz>i'll show you the log, but it will take time <ekaitz>meanwhile, in your machine it does build? <janneke>hard to tell until it's finished, tho <ekaitz>but you don't see any mescc: failed: ... in between! <ekaitz>you just did ./pre-inst-env guix build -e '(@@ (gnu packages commencement) mes-boot0)' right? <janneke>ekaitz: although...i'm offloading to a server that runs qemu-9.1.3 <janneke>not all that intentional, you asked what i was doing and i checked, just happened to be the case <ekaitz>10 fails for me, i tried 7 (I think) and also failed <janneke>ekaitz: oh, and also, i'm still at 53733436015 <janneke>there's 9 more commits on bootstrap-team that i'm not using... <janneke>so this has prolly been a waste of time... <ekaitz>oh that's an important point though <ekaitz>janneke: it feels like the commit you use works because mes and stage0-posix were not updated at that time <ekaitz>and probably they fail because they are not in sync