IRC channel logs

2024-07-26.log

back to list of logs

<ekaitz>madage: thank you! i'll take a look into that
<KindlyRepeat>Hi guys, I'm having this strange issue where a service will start properly when I reboot my computer but fail to start after a reconfigure. After a reboot I can start/stop it without problem. Its type is oci-container-service-type. Might be related too: if I kill the container using "docker rm -f <container>" instead of herd stop <service>, it also
<KindlyRepeat>gets in a state where I cannot restart it anymore. Did someone ever experience something similar ?
<KindlyRepeat>So it would seem that my service is disabled after a reconfigure, not sure why. I can enable it and start it again
<adanska>anyone whos familar with asdf-build-system, i have a problem. I'm trying to package `trivial-utf-8`, but the build system uses `hyphen-separated-name->name+version` to get the system name. this snips off the `-8`, and the build system cant find the system anymore, since the system is called `trivial-utf-8`. is there any way to work around this?
<avalenn>Is there any way to configure "guix style" for formatting code ?
<avalenn>I see the doc says that .dir-locals.el defines special indentation rules, but I do not know how "guix style" uses those rules.
<fnat>I'm working on a ReadyMedia/MiniDLNA service. Anyone has the time to have a look at this early and naive attempt, just to check whether I'm generally going in a good direction? https://paste.debian.net/1324410/
<fnat>I'd like the service to be in a least-authority-wrapper, but I'm a bit confused on how to mount/share the (media) folders as indicated in the ReadyMedia configuration file.
<fnat>I suppose one reads the list of media dirs from the configuration file and then uses them as mappings with least-authority-wrapper...
<fnat>I'm fixing the most obvious flaws while trying to build an example system definition that includes the service.
<fnat>I should be able to post a minimally refined version soon.
<macfag>How do i hand config options (eg. versions_accepted) to the wesnothd service?
<macfag>Am i supposed to specify a derivation of the package and patch the default config?
<b0ttymacb0tface>woops, next device.
<b0ttymacb0tface> How do i specify config options for the wesnothd service (e.g. versions accepted)?
<weary-traveler>in guix, when specifying a channel that exists in a local directory, is the location specified as '(url "path/to/dir")' or something else? related, how could i have figured out the answer myself?
<bigbookofbug>(on my channel at least) i've managed to successfully package an updated version of qtile that outputs the wayland version alongside the x11 one.
<weary-traveler>ah. it needs to be something git understands
<bigbookofbug>i want to upstream this after refining it a bit more, but wanted to know best practices here. it required me to build a half-dozen or so dependencies as well (such as pywlroots) across various package files. would i update python.scm, wm.scm, etc all in one go and submit the diff like that, or separate patches for each new package?
<bigbookofbug>weary-traveler: if it's a local channel, you would use '(url (string-append "file://" ...' i believe
<bigbookofbug> https://guix.gnu.org/cookbook/en/html_node/Channels.html
<weary-traveler>bigbookofbug: thanks for the cookbook link, i should've looked there in addition to the reference manual. once added, can modules from that channel be imported in the manifest file, or are additional steps needed?
<futurile>bigbookofbug: have you seen this part of the manual: https://guix.gnu.org/dev/manual/en/html_node/Contributing.html - bottom line you'd create a series of patches
<bigbookofbug>weary-traveler: you'd guix-pull, and it should be available like any other channel
<weary-traveler>ah. specifying it in channels.scm isn't sufficient. thanks
<bigbookofbug>futurile: thanks for the link! i see there's a subsection on python modules so i'll read through that since this is my first go at packaging anything python-related
<bigbookofbug>weary-traveler: correct, anytime channels are added you'll likely want to run guix pull
<bigbookofbug>you can also use guix describe to see the current channels you're pulling from
<lfam>I see that python-urwid fails its tests on core-updates, like this: <https://paste.debian.net/1324430/>
<lfam>This version is supposed to have some fix for locales handling but I guess it's broken again with all the other updates on that branch
<lfam>There's also several major updates to urwid, but it's not trivial to figure out how to build it. It seems to have changed significantly
<lfam>I'm trying to update it now
<lfam>For Python packages, does anyone know how the version string used in the "egg" file name is created? While trying to build different urwid versions on core-updates, this version string is erroneously created as 0.0.0, which breaks applications that use urwid
<lfam>For example, this file name is created when building urwid: /gnu/store/4c41pcx9qwfw657466m3ix58izqbxf2s-python-urwid-2.4.6/lib/python3.10/site-packages/urwid-0.0.0-py3.10.egg-info
<bigbookofbug>lfam: i believe its based on the version in the setuptools file, but i could be incorrect
<lfam>bigbookofbug: I'm poking around in the urwid source code. The setup.py file, if that's what you mean, doesn't contain a version string
<rekado>lfam: some need setuptools-scm for the version to be detected
<lfam>Thanks rekado
<lfam>My kingdom for autotools ./configure
<rekado>example commit: 4d65083bf8aca80aa5f90903f764a7ffe01e15d0
<lfam>Looks like urwid was overhauled after the version that we package. So some changes will be required
<lfam>Alright, I'm trying to update urwid to the latest, 2.6.15. That's what Debian sid is using, Nix too
<lfam>Alright, I got the latest version built and working with an application (khal / ikhal). The urwid test suite does fail to find its dependency tornado>=5, although of course it is available in the build environment
<weary-traveler>lilyp: when i create a docker image via guix pack containing emacs, the image contains libgccjit. is that intentional? i was surprised to find it since i believe we only support native-comp in aot mode
<lilyp>libgccjit is not propagated, it's used for AoT as well
<lilyp>you need a comp-enabled emacs to load natively-compiled libraries – it's an upstream issue if you will
<weary-traveler>i see. i suppose i'll live with an excess 130meg for now
<weary-traveler>unless there's some straightforward way to do a package transformation to remove it post build
<bdju>I have the wfetch package installed but I keep getting command not found when trying to run it. I'm looking at the github page and it should just be "wfetch", nothing crazy. perhaps a broken package
<bdju>I'm running find in my /gnu/store and I see many hits for .wfetch.py-real so that's probably the executable and the shortcut thing isn't being made properly
<lfam>bdju: What shell do you use? Bash, zsh, fish, etc?
<bdju>zsh
<lfam>For debugging, please do `zsh --login` and then `echo $PATH`
<lfam>What's the value of $PATH ?
<bdju>/home/brad/bin:/home/brad/.local/bin:/run/setuid-programs:/home/brad/.config/guix/current/bin:/home/brad/.guix-profile/bin:/home/brad/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin:/home/brad/.local/bin/fzf/.fzf/bin
<lfam>Look in '/home/brad/.guix-profile/bin'
<bdju>I see /home/brad/.guix-profile/bin/.wfetch.py-real
<lfam>Do you also see wfetch.py ?
<lfam>wfetch.py is the file that should be executed to run the program
<lfam>I think the confusion stems from it being named wfetch.py instead of wfetch
<bdju>oh if I do an ls | grep I see that. it wasn't showing up in my find search for .*wfetch.* for some reason
<bdju>oh so I have to run wfetch.py
<bdju>and then it works
<bdju>is that intended? as far as guix is concerned I mean. the github command examples seem to just show "wfetch"
<lfam>Our package has a custom installation procedure: <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python-xyz.scm?id=72e586fcae78e467d01e2add09c1db26be6bfa93#n16096>
<lfam>Maybe if were able to use the install.sh script that upstream provides, it would install the program as 'wfetch'
<lfam>Room for improvement in our package?
<lfam>Indeed, the upstream script renames the file when installing it
<lfam> https://github.com/rainbow-sh/Wfetch/blob/master/install.sh
<bdju>interesting. thanks for looking into that
<lfam>Should we change it?
<bdju>probably
<lfam>Are you interested in sending a patch?
<bdju>not particularly, no... sorry.
<bdju>I'll probably just make a shell alias while I wait or something
<lfam>I'll change it
<bdju>awesome. thank you very much.
<lfam>bdju: Is it easy to get an API key? I'd like to try this
<bdju>this is my first time actually using it, but seems you just make an account on openweathermap.org and you get a key for free
<bdju>I haven't gotten it to actually work yet, it says my key is invalid or if I just added it to wait a few minutes. I also had to "activate" the key in the website settings, clicking a little toggle button.
<lfam>Alright then I'll pass :)
<zjabbar>Hey #guix! I have a system configuration that I can build but not reconfigure. When I try to reconfigure I get a Git error: object not found. Trying to set `on-error=debug` does nothing. I have tried many iterations of `switch-generation` and `gc` but no luck. Any tips?
<zjabbar>Actually, I should mention. I can reconfigure if I use a GUIX installation image, chroot into my system, and running guix system reconfigure using the chrooted guix-daemon.
<lfam>bdju: I pushed the fix: <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=862a9b5b25966845f71d218ad8c0c5655ffc479a>
<dariqq>lfam: regarding the 32bit kernels: they seem to be building mostly fine on kernel updates (though 5.10 is failing with the cannot allocate memory problem, i dont know why 6.1 is failing)
<lfam>zjabbar: Reconfiguring the system does some extra work that building does not do. So it's possible for a bug to only manifest during reconfigure
<lfam>dariqq: Sometimes they succeed, sometimes they fail
<lfam>I'm pushing for people to support this stuff if they are using it
<lfam>dariqq: Looks like something goes wrong configuring the build of 6.1 on i686. It restarts the configuration (not what we want) and then it crashes
<intract>How do people run encrypted boot partitions? Enrolling decryption keys onto their machines? I like the idea of being able to swallow my boot partition and keys if I want to
<zjabbar>@lfam Thanks for the heads up. You're likely right on the reason why this is happening. The bug seems to occur during a procedure call to `update-cached-checkout`. I don't see a way to skip this.
<lfam>And then the deblobbing crashes too dariqq
<intract>Am I missing something that an encrypted boot setup can do, instead of me just using a custom /boot on a flash drive/sd card that then decrypts the rest on boot?
<lfam>Or rather, the deblobbing is performed incorrectly and causes the build to crash. Something is very wrong
<lfam>zjabbar: Not having looked at that before, it sounds like something goes wrong fetching from a Git repo?
<lfam>It can't find the requested object in the Git repo
<dariqq>is that a problem with the package or maybe just the 16 cores we thow at the problem?
<lfam>The 16 cores is probably related to running out of memory. Not sure about these other failures. Weird stuff
<dariqq>in the 6.1 log i just found: virtual memory exhausted: Cannot allocate memory
<zjabbar>@lfam Guix pull and guix install `xyz` works. Some files associated with that commit are empty and alive in the store making it hard to gc them. I'll do some further debugging.
<lfam>Ah dariqq. If that's on i686, it's a classic
<dariqq>yeah i686. Is there a way to tell the deamon building 32 bit packages to build with not all available cores?
<lfam>dariqq: I forgot to cherry-pick the update of dwarves to this new 'kernel-updates' branch, which is probably causing the failiure of 6.10 for x86_64
<lfam>dariqq: Yeah, there is, but I gotta refresh my memory on the right way to do it. However, we generally don't like to "bake in" to the package definitions the limitations of the build farm
<lfam>But maybe for i686... it just doesn't matter. I can't imagine there's more than a handful of users and they'd all have this problem
<lfam>Maybe one single user
<lfam>zjabbar: There's probably no need to gc anything here. In Guix, that rarely helps debug things, unless the thing that is being debugged is the rare case of non-determinism
<lfam>If you can figure out which Git repo it's trying to fetch from, you'll probably make progress
<lfam>dariqq: I pushed an updated 'kernel-updates' branch in the hopes of fixing the build of 6.10: <https://ci.guix.gnu.org/eval/1518931>
<zjabbar>@lfam Understood. I'll get on that. Thank you for the help!
<dariqq>lfam: i was more thinking of telling cuirass to limit cores for 32 bit packages rather than adding arbitrary limits in the pacakge definition itself (though i dont know if this is possible)
<lfam>Yeah, it's also possible in cuirass. Something would need to be amended in maintenance.git,where the build farms are configured: <https://git.savannah.gnu.org/cgit/guix/maintenance.git>
<dariqq>thanks hopefully the 6.10 kernel builds now