IRC channel logs
2024-12-16.log
back to list of logs
<jas>guix pull: error: while setting up the build environment: cannot set loopback interface flags: Operation not permitted <jas>hi! does anyone recognize that error? i'm running 'guix pull' in a debian trixie container image running under podman... <civodul>jas: hi! i don’t recognize it precisely, but i failed to come up with an OCI image that would work with GitLab-CI, FWIW <jas>civodul: hi! i am chasing down that goal too. i found the error in nix/libstore/build.cc <civodul>i think it has to do with how Docker/podman sets up its namespaces and stuff <jas>it would be nice if 'guix pull' worked in these limited containers, i wonder if that ioctl() is really required to succed? can't it fail gracefully? <weary-traveler>so guix home installs its packages in a profile that's distinct from the default profile at ~/.guix-profile. if so, which packages should be included in one vs the other? <jas>ACTION just discovered guix-daemon --disable-chroot <civodul>jas: no because i was using ‘guix pack’, not ‘guix system image’ as csantosb seems to be doing here <newbie-MBR-to-GP>Thx to all, worked. Had after MBR-to-GPT conversion to chroot as bootloader was failing. Used system-rescue cd to do so. Followed page Janneke pointed out. Conversion to GPT required shrinking of root-partition for a few blocks, luckily delete/create worked fine. afterwards resife2fs to get rid of some strange error message... <fingu>hey guys, any support on running shepherd on other distros? <apteryx>does anyone know how long it takes to run all system tests? <ashleytah>Hi, I have Guix installed as my primary package manager on a Fedora desktop. I've been trying to use Godot but software installed through Guix is only detecting the integrated graphics card, not the main graphics card. Is there something I should be doing differently to ensure software installed through Guix has access to the main graphics card? Thank you <meatus>Is there any way to set/modify the default app/filetype associations via guix? <jaft_r>meatus: I could be wrong but I think individual desktop environments tend to provide their own defaults so I'd expect you'd have to modify packages to really do that at the source, if you will. If you use Guix Home – though –, you could always make your own mimeapps.list file and have Home install it to the appropriate place (mine's under ~/.config/ but I saw someone on the internet have theirs at ~/.local/share/applications/). <meatus>jaft_r: I did find that, it was already there and in fact contained the offending issue (zathura being used as a file browser), so I was wondering if there was some Guix component generating it <meatus>otherwise, how can I "re-read" the mimeapps.list file, if I just edit it directly? <jaft_r>Fair; I don't know for certain but I'd first suspect the desktop environment. I have XFCE handling a lot of stuff for me so I use xfce4-mime-settings to update my settings; all the changes I've made via that app. have shown up in that file. Are you using any particular desktop environment? <meatus>no, just a DIY one with Hyprland as the wayland compositor <meatus>some sleuthing makes me think the mimeinfo.cache files in "/share/"applications/ is the culprit <meatus>so I just have to regenerate the cache... somehow <jaft_r>Mmm. I was (trying) looking up an answer to that and a Stack Exchange question for people running ElementaryOS said to use the command update-desktop-database but I don't have that. I do have update-mime-database, though. I'm not sure what provides it, though. <jaft_r>Looks like it's coming from a shared-mime-info package. I'd assume XFCE pulled that in, for me, but I'm not sure. If so, not particularly helpful for your case, though… <meatus>the specific file causing the issue from store item /gnu/store/...-xdg-desktop-database/share/applications/mimeinfo.cache <meatus>in more detail, I ran the command "env XDG_UTILS_DEBUG_LEVEL=10 xdg-mime query default inode/directory", which lists the files xdg-mime looks through. I removed the offending line from ~/.config/mimeapps.list, but it still showed zathura-cb as the opener, so I checked the other files that had the offending line and that was the one <meatus>wait, maybe I can just set it via the command tools? <f5mg>Is there a way to get the 'name' field of any file-like object - local-file, computed-file, etc - without knowing which of those it is? <f5mg>Ok, I think I'm a little confused. Let me back up a bit - <f5mg>Say the user does '(local-file "./file")' <f5mg>That ungexps to '/gnu/store/<some-hash>-file' <f5mg>Is there a 'proper' way to get the original name 'file' from this object, outside of just using regexps to find and trim the hash part out of the basename <f5mg>Hmm, that doesn't really make sense does it? <meatus>fixed my issue! I just had to use the 'xdg-mime default' command, which edits ~/.config/mimeapps.list and updates the cache <olafes>How would I build a package and it's dependencies with specific c toolchain? --with-c-toolchain rewrites only the package and it's dependents <homo>is an example how to build something with gcc 4.9 <olafes>homo: Yes, but hugs has 0 inputs <homo>olafes: is line "(native-inputs (list gcc-4.9))" already removed? <olafes>The package I want to build has other inputs, and these won't be built with the c toolchain I want them to <olafes>I think there's no way to do this right now with upstream guix <olafes>I may just make a quick workaround in the guix itself, pass all the packages through package-with-c-toolchain. Are there any obvious pitfalls of this approach? <Rutherther>olafes of course this is possible with upstream Guix. That is what package mapping function is for, to map all dependencies through a procedure <efraim>janneke: take a look at the configure-flags listed in gcc@4.7. gcc-4.7 needs (I think) the same CXX flags as gcc-4.8 but I couldn't add it previously because it would cause a world rebuild <janneke> `(cons "CXX=g++ -std=c++03" ,flags)) <janneke>ACTION underestimated the impact of changing gcc-4.7...instead of finding "hello" this morning, it's still chugging along in gcc-4.9 <janneke>but yeah, possibly better to change it now <homo>is there documentation how to use etc/committer.scm? <apteryx>there's only one way to use it, which is to invoke it. It doesn't understand any arguments. <efraim>it doesn't work on all changes, but it's really good when it works <efraim>IIRC it assumes a new package or an upgrade of a package <apteryx>i'd like to be able to give it a package name to tell it to only work on this <homo>I've already committed a change <efraim>I sometimes stash parts of files and then run it and then unstash the not-ready bits <apteryx>yeah, that's what I do to, but it's not super convenient <efraim>ugh, perl-boot0 says compiler error on riscv64 on wip-riscv-bootstrap <homo>running etc/committer.scm returns me backtrace <efraim>it's needed for glibc, so I probably can't drop bison for byacc, and I need flex and perl later on anyway <efraim>I might need to actually get gcc building <homo>I ran "git reset --soft", running etc/committer.scm returns "Nothing to be done.", but if I unstage files, it returns backtrace <homo>I really need documentation how to run it <homo>I added new file in gnu/packages/patches/ <rekado>homo: commiter.scm doesn't know what to do with patches <rekado>it only knows how to deal with package upgrades with optional input additions. <rekado>(I wrote the first version to help me with mass updates of CRAN packages.) <rekado>so it wasn't really made for anything else <homo>either backtrace or "Nothing to be done." <dariqq>apteryx: Thanks :). Should the problem that lightdm-gobject (used by the gtk-greeter) always uses the default lightdm config file (rather than the one passed to lightdm) reported upstream somewhere? <rekado>"nothing to be done" is expected when there is no diff (because there are no unstaged changes) <homo>but when there is any unstaged change, it just backtraces <efraim>it sounds like you'll need to do the commits by hand <rekado>correct, because it doesn't know how to deal with your diff <apteryx>is something wrong with savannah? guix pull has hung, or returned: erreur : Erreur Git : SSL error: received early EOF in my last two attempts <csantosb>I was about to say the same, clone of git.savannah.gnu.org/guix/maintenance.git is very slow <apteryx>but yes, it'd be great to have a clear report eventually fixed. I tried explaining the issue but it was still a bit muddied for me. <janneke>efraim: the build gets further using the 4.8 flags, but it still fails <janneke>ACTION goes to undo the commencement-level impact changes to gcc 4.7 <ekaitz>janneke: did you solve the problem from yesterday with the std::abort? <janneke>nope, that was what efraim's hint was also for <janneke>but i did find that on current master, ie with gcc-11, gcc-4.7 also doesn't build <janneke>so i think we're good for core-packages-team <ekaitz>yeah 4.7 doesn't build since a long time ago <efraim>ekaitz: I think I'm going to end up with an "oopsie! we're adding %boostrap-gcc just for this one package!" in order to get the bootstrap working so I can keep track of what's missing <efraim>also the gcc-4.7 -> gcc-base also might allow us to get 4.7 to build again without needing to mess with every other gcc package to undo the changes <efraim>ok, now that I've said that I have more ideas, but I really need to get a handle on the mess I've made of commencement.scm <dariqq>apteryx: Thanks I added what I think is the issue. I am amazed that the default session fallback worked in the first place (but this might be using lightdm and AccountService directly and not lightdm-gobject) <dariqq>i hope i dont encounter issues with display managers again, because debugging them is not fun <rekado>ACTION waves from deep inside the Python upgrade rabbit hole, but it's dark and nobody can see. <janneke>ACTION looks up, was that the slightest woosh of air? <rekado>ACTION ..-/.--./--./.-./.-/-../../-./--. .--./-.--/-/..../---/-. .--./.-/-.-./-.-/.-/--././.../.-.-.- ..././-./-.. ...././.-../.--./.-.-.- <janneke>rekado: as i'm waiting for my world to rebuild, is there anything/any branch i could look at -- disclaimer, i'm pretty green wrt python packaging <rekado>quite a few Python packages on the master branch are borked <rekado>some are easy to fix (by adding python-setuptools and python-wheel), but others broke due to upgrades <rekado>and so for those the easiest fix is to upgrade them <rekado>and that breaks more packages, requiring more upgrades. <rekado>perhaps it would be best to start a new python-team branch to facilitate cooperation <efraim>rekado: sharlatan was talking on mastodon about python-3.12 <efraim>and I got python-cryptography upgraded to 43 (from 42) on rust-team <efraim>I should see about getting maturin raised further, although I guess its mostly used for mixed python/rust packages <stochastic>Is there a package transformation to add a dependency? <rekado>stochastic: unfortunately, there is not. I wish it was possible to add and remove inputs via package transformations. <rekado>it's possible to do via files and inherit, of course, but sometimes doing this with files feels much more heavy handed. <efraim>janneke: I haven't been able to really test it, but it looks like if aarch64 support in mescc gets a little better we'll be able to use the riscv bootstrap path for aarch64 <ekaitz>also janneke now i remembered, i sent a proposal for NlNet to make Mes faster, idk if you remember <ekaitz>the deadline was back in october <janneke>efraim: that's great news, i was kinda hoping that <ekaitz>janneke: in their last communication in november they said they would take long <ekaitz>but this is taking maybe too long <efraim>I sent a proposal to re-bootstrap ada <efraim>ekaitz: still waiting to hear back <apteryx>has anyone ran 'make check-system' recently? I'm currently getting: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f <janneke>sneek: later tell apteryx: make check failing *again*? a test failed before the python merge, fixed that, a test failed after the python merge, fixed that... <dariqq>janneke: tests/guix-system.sh is failing to 'guix system search . > foo' since 6ec3c260a1951666bcf428de3f901753429fdfdb <michzappa>Trying to build a 'guix system image' qcow2 on an up-to-date Fedora system, fails with "fakeroot, while creating message channels: Permission denied. This may be a lack of SYSV IPC support." I have successfully built this image using the same generation of Guix on both GuixSD and an Ubuntu 24 WSL system. It seems the SYSV IPC feature is definitely <michzappa>enabled on my kernel. Has anyone seen an error like this in the past? <Rutherther>michzappa: can you build other stuff with guix on that machine? <michzappa>Yes, plenty of things. I have an inkling this could be an SELinux problem - a step in the setup of guix on Fedora is to install the needed SELinux policies for the guix-daemon, /gnu/store, etc. That's what I am going to investigte next, checking here if anyone has prior experience <michzappa>Well what would you know - that's definitely the root cause. Making SELinux run in permissive mode allows everything to build. I will try and find what policy change is needed to allow this action <weary-traveler>how are the patches in gnu/packages/patches created? given a package, are the sequence of steps to unpack the source code, modify and then generate patch fit for patches directory noted somewhere? the guix manual and cookbook seem to be light on the matter <efraim>well, mesa builds fine on riscv64 on the mesa-updates branch <weary-traveler>alternatively, if someone here knows the incantations off the top of their head and can share i'd be thankful <Rutherther>weary-traveler: the ones produced by git format-patch should work fine <efraim>the easiest is to start from a git checkout. then as you make changes you can run 'git diff -p > /path/to/guix/repo/gnu/packages/patches/my-patch.patch' and add my-patch.patch to the patches for that package