IRC channel logs
2025-04-22.log
back to list of logs
<mrh57>ieure: update: I changed the location of ppcre.lisp to the src dir and the error changed to the more typical: 'Error opening #P"/gnu/store/j6jhr04j26937ddrf92nw6ykgg652596-sbcl-optima-1.0-1.373b245/lib/common-lisp/sbcl/optima/src/ppcre-tmpGHU3ALSV.fasl": Read-only file system' <wickedshimmy>Hi folks. I am lost in the wilderness. guix on a foreign distro (Fedora). guix is segfaulting during most operations; core dump points to scm_iprlist from libguile (3.0.9, but I have no debugging symbols). Guile seems to run okay, and if I assemble something that looks like guix-command removing the guix-module-union/.../site-ccache line from %load_compiled_path I can limp past that crash, but unfortunately I haven't been able <wickedshimmy> to successfully `guix pull` my way out of this mess that way (substitute dies unexpectedly, or else with --no-substitutes compute-derivation failure). Is there another/better way to either rebuild/remove the compiled modules or otherwise debug what's going on here? <apteryx>wickedshimmy: hi! I'm not sure what could cause Guix/Guile to segfault like this; perhaps the glibc on has a backward incompatibility? (that'd be surprising, but perhaps a bug). Is this using Guix 1.4.0. as installed by the guix-install.sh script, for example? <wickedshimmy>apteryx: --version currently says "ef84004..." I regret to say that this installation was so long ago I do not recall the details (and suspect it was more manual than guix-install.sh). We had many happy times together before this started though! <apteryx>wickedshimmy: my simple recommendation would be to bring your guix to at least 1.4.0 via the guix-install.sh installer as a hopefully a quick way to get you past this <apteryx>1.4.0 still has annoying problems such as the guix-daemon aborting on TLS push errors, but it should at least (hopefully not segfault on your system <apteryx>so after installing this 1.4.0, you should try to 'guix pull' (you may need a couple tries to overcome the possible tls errors). <wickedshimmy>apteryx: heard. does a guix-install.sh over the top of whatever the hell I have going on a reasonable thing to do, or do you think I should be trying to excise the old daemon and store first? <apteryx>wickedshimmy: if there's nothing valuable with your current installation, you can try uninstalling it with './guix-install --uninstall' then './guix-install' <apteryx>there's also a hidden GUIX_ALLOW_OVERWRITE environment variable you can set to overwrite pre-existing locations such as /gnu and /var/guix instead of aborting, although uninstalling first may be cleaner. <lechner>Hi, what does this mean, please? %exception #<inferior-object #<&action-exception-error service: root action: eval key: unbound-variable args: (#f "Unbound variable: ~S" (%unset-marker%) #f)>> <meaty>is the 'guix graph' tool really iffy for anyone else? <meaty>'herd graph | xdot -" works fine, but "guix graph beets | xdot -" causes xdot to hang <podiki>i haven't tried to view a graph in a long time, often just too huge for what i'm looking for <ieure>meaty, Yeah, it doesn't work very well in my experience. It's not really the fault of `guix graph', it's that the graphs it outputs are enormous and xdot can't cope. <podiki>i tend to use refs/referrers and path options <meaty>ieure: is there a way to limit the depth? <podiki>i mean i want to know how some package depends on another, so i use the path option to just give me the package path between them <podiki>or, want to know what refers to a package <podiki>i think best to know what you want to get from it or else if it is not some very base level package (and even then) the graph tends to get large <meaty>I'm trying to break beets up into outputs (specifically, the enclosure of the "chroma" plugin's dependencies is nearly 1 GB) and I've done so by moving "chroma.py" and "chroma.pyc" to a different output after the 'check phase. These are the only ones that call "import acoustid" so therefore when I run 'guix size beets' acoustid should not be listed, right? but it is and I'm trying to figure out why <meaty>acoustid is the huge dependency that makes the "chroma" plugin so large <meaty>alas I can't figure out how to do something like 'guix graph beets:chroma' to verify whether guix can figure out that acoustid is a dependency of it (and only it) <ieure>meaty, I'm not sure if `guix size' only looks at out or all outputs. <meaty>ieure: is there a way to verify that the separate outputs have their separate dependencies then? <ieure>meaty, I believe you want to look for store references in the package's output. <meaty>ieure: as in, grep for store paths? <ieure>`grep -r gnu/store /gnu/store/*-beets-*' <ieure>The closure size is, I believe, the size of all store items referenced within the build output. <ieure>I could be wrong, but that's what I believe. <meaty>ieure: I see, although I moved chroma to another output, the acoustid store path is referenced in the wrapper script for the executable. In fact, that's the only place it's full store path is mentioned. Would that be what's causing guix to think it's a dependency? if so is there a "normal" way to "wrap" non-executable python "libraries" so that acoustid is only added to the pythonpath when chroma.py is used <ieure>meaty, Yes, if the main output references acoustid, that will be included in its closure size. <ieure>meaty, You can't conditionally wrap like you're thinking, because a) all that stuff is going to run way earlier than you can determine if you need the plugin and b) you have to have the store path of the plugin in the code for the case when it would get added, which means it would be part of the closure all the time anyway. <ieure>meaty, I think the only way to do what you want is to create a separate package for the chroma plugin. <meaty>ieure: thank you for filling me in <adanska>Hi Guix, is anyone having issues with guix pull? im getting a "builder for `/gnu/store/zclpanjyp59nr2c4b25bak6j2zq5vyp0-guix-system-tests.drv' failed with exit code 1" error. this is building from commit b105018. <ieure>adanska, I can reproduce your problem. <ieure>I pulled earlier today, 7a4193ec4a09fecc68dc726c1e0bbb5ad03d404a is a good commit. <adanska>ieure, Great. Obvious suspicion is the recent changes to the system tests in 2c7c059e0b8f086979af070fe9c61fa793bb0e3f. <apteryx>lechner: %unset-marker% is an unset variable. <ieure>adanska, That's before the commit we know is good. <apteryx>I think that's used as the unset value for maybe configuration options <apteryx>perhaps the gexp you expound is underquoted <adanska>ieure, Oh... interesting. perhaps 367d071bbac1dd7a4a44cffcbf557c00515ec051 then? maybe its a hurd test failing... <ieure>adanska, Yeah, that's the only thing that looks suspect to me. <ieure>Actually aab89b3d934b8b17956d9402d35586c944bddd78 is the only commit that looks like it touches tests. <adanska>ieure, Oh yeah, i see that. That is probably the culprit <ieure>apteryx, Looks like your pounce service tests are breaking `guix pull'. <ieure>I was able to reproduce with `guix time-machine --commit=aab89b3d934b8b17956d9402d35586c944bddd78' <apteryx>perhaps this commit I thought innocuous: 367d071bbac <apteryx>ACTION tries 'make as-derivation' to see where it fails <ieure>apteryx, The problem commit is aab89b3d934b8b17956d9402d35586c944bddd78. <apteryx>ieure: ah ok, just reverting that one resolves the problem? <ieure>apteryx, I haven't reverted, but I can time-machine to 367d071bbac and not aab89b3d934b8b17956d9402d35586c944bddd78. <apteryx>ieure: so far 'make check-system TESTS=pounce' succeeds, so I'm a bit at a loss <ieure>apteryx, Did you try the time-machine invocation? <apteryx>I can make it fail with 'make as-derivation', so I have something to investigate. <adanska>apteryx, that's curious. i suppose though it's not the test thats failing, but rather building the derivation for system-tests.. <apteryx>my suspicion would be on the use of `specifications->packages' in %pounce-os, as that's the only different thing compared to %ngircd-os, which is otherwise very similar <apteryx>I guess it would need (gnu packages) added to something like *core-package-modules* <adanska>apteryx, how peculiar... glad you found it though! <apteryx>which may be useful, as packages are sometimes moved around the tree <apteryx>adanska, ieure: fix pushed with c6ee7b0f796 <apteryx>thanks to pounce I could easily catch your irc messages, ah <adanska>hahahaha cool! how do you use pounce on your system? does your irc client connect to it? im curious... <wickedshimmy>apteryx: that uninstall was harrowing stuff, but I think I'm in better shape now. thanks for the advice! <apteryx>adanska: pretty much like in the examples of the manual ^^ <apteryx>I have a vps at ovh that currently costs something like 1.5$ per month (still in the first year), on which I managed to have Guix System running, and have two instances of pounce running on it. I keep a wireguard tunnel opened to it at all times from my home workstation and point my local IRC client to it (ERC). <apteryx>(you need one pounce instance per IRC server you want bounced, in my case Libera.Chat and OFTC). <sham1>Under 2 euros a month for a VPS on OVH sounds extremely cheap. What configuration is that? <apteryx>after the initial year the price becomes 5$ per month, about. <apteryx>it's not the kind of machine I'd use to build packages (or even run 'guix pul) on but for hosting light services it's perfect. I use 'guix deploy' to manage it. <adanska>Hi Guix! Despite having my timezone set in my Guix config, the $TZ envvar is empty on my system. I belive this is leading tools like gnome-calendar to not detect my timezone and display incorrect times. Does anyone else have this issue? <ArneBab>When updating via manifest, I’m getting the info "guix package: error: python-pyblake2: unknown package" — had something like this a few times in the past months; are packages deleted too easily right now? <adanska>ArneBab: looking at the commit message (b9cfda4fa418aa354be57a067800b2a1aa0eff8d if you want to read) it was removed because it no longer built with python 3.11, and its funtionality is now largely included in python since 3.6 with a compatible API, so it was chosen to be removed. it might be an idea to provide a pinned channels file with your manifest so your manifest can be reproduced reliably :) <ArneBab>adanska: do we have a mechanism for making a package a NOOP so manifests don’t break? <ArneBab>Just to get rid of something that can block updates. <futurile>ArneBab: if you care about it a lot you could put it in the guix-past channel <adanska>ArneBab: there is a package deprecation function but thats more for definitions. Anyway, for your case i think its a good thing that the definition broke. The package wouldn't have built anyway. being aware that something is wrong is better than silently failing in most cases... if you want to keep using that exact manifest you will have to pin your channels anyway since there's no chance of it working with python 3.11. <ArneBab>futurile: what’s the guix past channel? <ArneBab>adanska: since there’s a compatible API, I don’t need it. I’d just need a package that does nothing but prevents the manifest from breaking. <adanska>guix past wont work since the package is built with an older python version. you will have to use an older python version for all your python packages for you to selectively use the broken package. <futurile>seems like it has python2 in it already, won't it work in a time-machine setup then. Oh well just an idea <allana>Hi guix! Switching guix-service-type configuration to unprivileged on my guix system yesterday evening was problematic for me. It rendered my wifi devices unusable for some reason. I have both an intel proprietary device and a libre atheros wifi chipset. Both could not work after setting privileged? to #f. Rolling back to previous generations did not help either. Performing a guix system reconfigure with privileged? set to #t brought me <allana>back, with all wifi devices working again. Just thought I'd share an experience report here. Thanks for the great work and I look forward to trying the unprivileged guix service configuration again in the future :-) <ruther`>allana: does the log show any errors? if so, can you send it? <allana>ruther`: I was in a panic to start my workday, so I did not collect any logs. I do know from the gnome desktop network manager that I could not do anything with wifi settings, and there were not any obvious errors in /var/log/messages. My devices were found in iwconfig <meaty>what's going on with rust-team? i hear all the crates-* modules and version numbered package defs are going away? <ruther`>allana: and do you know if it was just wifi that didnt work or even ethernet? <allana>Question about packaging and inheritance. Say that I want to create a package that inherits from another package. The main point of this is basically a package transformation, where I want to add a build phase. The package that I am inheriting from modifies %standard-phases. How do I modify the phases of the package that I inherit from in the new package, and not %standard-phases? I would prefer to not maintain a copy of the parent <ruther`>allana: see substitute-keyword-arguments <allana>ruther`: sorry, I can't say about ethernet. It's also not something that I know how to test since my laptop does not have an ethernet port <adanska>Oh! I had to solve this problem a little while ago allana. in the arguments field, use `(substitute-keyword-arguments (package-arguments $$parent-package$$) ((#:phases phases #~%standard-phases) #~(modify-phases #$phases ...$$your-standard-phase-changes$$...))` <ruther`>allana: you can have ethernet via usb-c, but no worries. I was just thinking what it could be and I can imagine why both wouldnt work, but just one seems strange. And even for both, I am expecting it is just some kind of a security check by NetworkManager <allana>ruther`: thanks for substitute-keyword-arguments! (also adanska) <allana>ruther`: I may be available to help test some thigns if need be <allana>I am in the middle of my workday but I may be able to help diagnose the problem if you point me in the right direction <ruther`>allana: I will try it in a vm first with ethernet, and will see how it goes. But I am not sure if I will get to it today <azval>is it expected that `guix home` symlink its own config ? it didnt do it before but now it seems it does <csantosb>Hi Guix ! Issues with mumi ? I feel like it is outdated since this morning. <azval>well I changed something in my config and now it doesnt symlink it...weird xD <ruther`>Is there a publicly hosted Matrix channel that is bridged here to #guix IRC? <futurile>nikolar: the GNU infra is struggling again from what I can see <ieure>orahcio, Likely broken by the python-team branch that merged recently. <orahcio>ieure: Thanks for the information, I need just to wait to use it again, correct? <ruther`>orahcio: Guix-hpc will need to fix it on their side <ieure>orahcio, Yes, someone needs to fix the packages in the guix-hpc channel. <meaty>what's going on with rust-team? i hear all the crates-* modules and version numbered package defs are going away? <untrusem_>folks, whats you workflow of running appimages in guix if needed <lechner>ieure / Hi, thanks or working on Librewolf! How may I stay logged in on sites like Codeberg, please? I keep cookies on logout and exempted codeberg.org from the cookie ban, but still have to login from time to time <ieure>lechner, Thank you for saying! If you stay logged in most of the time, but occasionally get logged out, that's probably an issue on the codeberg site, they might be setting an expiration on the cookie. <ieure>lechner, You can right-click the page, select Inspect, click the Storage tab, and select Cookies from the left panel. That'll let you see what cookies are getting set and when they expire.