IRC channel logs
2025-06-06.log
back to list of logs
<apteryx>is there a way to change mount flags inside a 'guix system vm' ? <apteryx>sneek later tell civodul, apparently the nars atime is already guarded from changing by the fact that the /var/guix/publish location is exposed as a read-only mount point in the container. <PotentialUser-15>is there a straightforward way to modify packages to not install docs, manpages, localized strings, etc? my team is exporting guix environments to docker with guix pack and the images are ending up pretty bloated because of all of the extraneous documentation files that are installed alongside the software packages <PotentialUser-15>could a package transformation be applied after the install step to delete /share/man/? or would that likely break something? <ieure>PotentialUser-15, No, that's the right track. <ieure>PotentialUser-15, You want a package transformer that deletes /share/doc and /share/man from the outputs after the 'install phase, then use `package-mapping' to apply it to everything. <ieure>PotentialUser-15, A consequence of this is that you'll build *everything* from source, because you're creating new derivations that aren't on any substitute server. <PotentialUser-15>That's fine with me, the main concern is the ballooning sizes of some of these docker images. <PotentialUser-15>is there an example somewhere of how to use that? the docs seem kinda vague <PotentialUser-15>Maybe I'm using it wrong but I keep getting a wrong type argument. I think I'm confused about what is being returned by remove-documentation. Is it a package, a specification, or something else? <mange>remove-documentation is a function which takes a package, and returns a package. <PotentialUser-15>I wasn't giving packages->manifest a list, I was just giving it a singular package <PotentialUser-15>Or maybe not, it seems I can only call it once and then I get an error about an unrecgonized keyword #:phases <PotentialUser-15>i tried changing it to take a list of packages use map and compose instead of manually calling remove-documentation each time and it's closer to working, it gives that same error on any python package. <mange>I think that error is caused by a package with a different build system that doesn't support #:phases. I had the same issue when I tried adding #:deep? #t to the mapping. <mange>Presumably you could only do the transformation if the package is using an appropriate build system, but I'm not exactly sure how to express the condition. <PotentialUser-15>I'm looking at the python-black package for example, I can see in the official definition maintained by guix that it uses #:phases, but it doesn't seem to work if I use it with remove-documentation <mange>I think the python one breaks due to python-minimal-wrapper (which uses the trivial-build-system). <mange>The bash/coreutils ones seem to work fine for me. <mange>It just hard-codes "if it uses the trivial build system, then don't do anything". <mange>I'm sure this is not sufficient in general, but it's enough for python-black. <PotentialUser-15>I'll have to play with this more and see if I can figure something out. The bulk of our packages we're installing are python <mange>Try with the version in that paste. It should work for most Python packages. <PotentialUser-15>I threw a few python packages at it and it seems to be working, but if it's not removing the docs then it hasn't really solved the original issue. <mange>It should be removing the docs. There's a single (hidden) dependency where it won't, which I expect won't have docs. <mange>It will still process all of the other packages, I expect it's just ignoring a wrapper script (making the "python" command call "python3", I think?), which has no documentation. <PotentialUser-15>I think I'm misunderstanding then. If we're saying don't do anything if it uses the trivial build system then won't all python packages do nothing? Or are you saying that only some python packages use the trivial build system? <mange>Python packages use the python-build-system or the pyproject-build-system, I believe. But in their dependency graph there is a single package which uses the trivial build system. <mange>Thus, when the transformation tried to remove docs for python-black and all its dependencies, it failed because it didn't properly handle that one dependency. <mange>I have fixed the function to not fail, so now that one dependency is left unchanged, and everything else is transformed as expected. <PotentialUser-15>Oh so you're saying that this remove-documentation function applies recursively? <mange>Yes, to all declared dependencies (but not to build-time dependencies). <PotentialUser-15>Is there an equivalent of build-system-name for the package's name? I've found a couple more that are throwing an error so there's probably some other build system at play <PotentialUser-15>For now I'm planning to just skip those packages entirely since I'm not sure how involved it will be to track down the build system <mange>I just used (pk (package-name pkg) (build-system-name (package-build-system pkg))) to print them as they were processed, and then looked through the list to see if anything looked sus. <mange>A look at the current source makes me think the only build systems that won't work are channel, mozilla, and trivial. <mange>If you replace the bypass condition with (member (build-system-name (package-build-system pkg)) '(channel mozilla trivial)) that should take care of them. <PotentialUser-15>I'll try printing them all out as they're processed. It's not any of those build systems. <PotentialUser-15>The package is python-scikit-learn, which I'm sure has complex enough dependencies my first inclination was to just try skipping it entirely <mange>Yeah, nice. Add it to the exclusion list. :P <PotentialUser-15>And the build seems to be running fine now. This will probably be awhile to build all of these from source but it's looking promising <mange>Great! Let us know how it goes when it finishes. <sturm>does `notify-send "Hello, World!"` work for anyone else under Gnome? I have a script that uses it that's not working. It's giving "GDBus.Error:org.freedesktop.DBus.Error.NoReply". <PotentialUser-15>I seem to have run into an issue building openssl-1.1.1l. It appears this is a known issue with certs expiring. Should I use a package transformation to disable those tests? <mange>Since you're rebuilding it yourself, I think it's reasonable to disable tests. (I would actually do so for everything, to speed up the build - as long as the tests are passing in Guix you should be fine.) <mange>That's probably the simplest thing to do, for now. There would be more sophisticated ways to do it (like, you can inspect #$phases to decide whether to call modify-phases or not), but the most straightforward option would be to just hard-code specific packages. <PotentialUser--1>Sounds good. I hardcoded gzip-mesboot and it's running fine for now. I'll just keep hardcoding those as they come up and will later try to come up with a better way to do this. It'd be a good guile/guix learning experience for me. <despair>Hi, I am getting the following when running 'guix pull', is this a known issue? <despair>guix pull: error: aborting update of channel 'guix' to commit 60e332adae600e230efb76e4027b764e3ae2c7dc, which is not a descendant of ad8cb7af8fc572bb3d11cd0344bd2bed3b9d653f <despair>hint: This could indicate that the channel has been tampered with and is trying to force a roll-back, preventing you from getting the latest updates. If you think this is not the case, explicitly allow non-forward updates. <despair>Nevermind, fixed it by doing a guix pull --rollback and then a new guix pull <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: apparently the nars atime is already guarded from changing by the fact that the /var/guix/publish location is exposed as a read-only mount point in the container. <oskarw>Hi, do you know if version 1.5 of guix will be released? <oskarw>csantosb: Good to know, I will wait for this release. Thank you for your hard work <ruther`>releases are only for installation. there is no point in waiting <ruther`>you should pull to newest commit either way. releases are just tags, you dont get security updates <oskarw>ruther`: I want to install guix :) <ruther`>I know. What I am saying is that the releases dont matter, because you stop using them right after you install. that is the reason why committers are not prioritizing it. <ruther`>so the gain from new release is minimal for users that install the official way. unless your hw has not been supported by kernel used in 1.4.0 <despair>Anyone else experiencing issues with icecat since a week or 2? It seems stuck indefinitely on loading pages at some point (and thus becomes unusable). Restarting it sometimes helps temporarily. Didn't find anything on the issues page yet. <oskarw>ruther`: I will check it out this weekend <oskarw>* I will then check guix out this weekend <futurile>I think this convesation (oskarw) is a great example of exactly _why_ having regular releases does matter for the project. Not for a technical reason - but if you're a new potential user and you don't see a "new release" of Guix then it's odd. Users expect regular releases (even if we only actually release new release artefacts) <futurile>Ironically, just doing emails to try and get feedback on the proposal for gcd005 heh heh - great timing <Guest82>hi got a problem since 2-3 days. > guix pull <Guest82>guix pull: error: aborting update of channel 'guix' to commit 60e332adae600e230efb76e4027b764e3ae2c7dc, which is not a descendant of ad8cb7af8fc572bb3d11cd0344bd2bed3b9d653f <Guest82>hint: This could indicate that the channel has been tampered with and is trying to force a roll-back, <Guest82>preventing you from getting the latest updates. If you think this is not the case, explicitly allow <ruther>Guest82: yes, there has been a mistake pushing wrong commits to savannah. Just allow downgrades and it will be fine <cbaines>I can no longer reconfigure on x86_64-linux as clisp fails to build :/ <civodul>cbaines: uh; there are substitutes though, at least as of 6b50daa9bd3eb521c2d4f0f38f2dc3e42202a112 <civodul>cbaines: clisp substitutes are also available on bordeaux.guix according to âguix weatherâ <cbaines>civodul, I did trigger another 3 builds, so maybe one of them has succeeded <cbaines>unfortunately bayfront can't seem to connect to data.guix.gnu.org at the moment (even ping fails), so the data there is out of date <ruther>how can the tests be passing sometimes and sometimes not? <cbaines>that's a good question, unfortunately there are lots of reasons why this might happen and while it's possible to test for it, we're not doing that systematically at the moment <ruther>cbaines: where can I find configuration of the server where the build succeeded? <adanska>cbaines, there was a failing test that i have fixed in PR #416, once thats merged clisp should build again. <ArneBab>Iâm getting minted errors when trying to export with code snippets from org mode. Does anyone see the same? "Package minted Error: Cannot highlight code (minted executable is unavailable or disabled); attempting to typeset without highlighting." (in buffer *Org PDF LaTeX Output*) <civodul>abbe__: oops, thanks for the heads-up <mra>civodul: sorry to bug you, but could you take a look at #127 if you have a sec? it just needs an LGTM from you to merge <mra>leaving on a trip soon so won't be able to keep on top of it <civodul>i can do that but iâll take it as an opportunity to mention that there are 40ish committers :-) <mra>yeah, but you requested changes on the pr and haven't approved them. i guess i should have asked if it was possible to merge over that <mra>but i assumed that all requested changes needed to be approved before a pr could be merged <civodul>right, since i requested changes, it makes sense to ping me <civodul>sorry for being unnecessarily grumpy! <civodul>i canât commit it right now but it LGTM <civodul>(iâll push it later if nobody else did) <mra>all good! sorry for the trouble and thank you! <jakef>if any committers have a minute, PR #366 has a couple of LGTMs :) <kkremitzki>Severe bug*. Essentially I have two Thinkpads running Guix System which are pretty much identical except for perhaps differences in the Coreboot build. Both using full disk encryption. Both accept the password the first time. One goes on to prompt a second time, but the other appears to hang on showing the GRUB wallpaper, but is actually waiting for the password again, and will proceed normally if it's entered. People who run into this though can't <kkremitzki>So, weird bug, readily reproducible... any diagnostic or debugging suggestions? Obviously this is a bit much for IRC and I'll also send this to the mailing list <ieure>kkremitzki, Everyone in the linked bug was able to fix it by changing their CSM settings -- does that not work for your case? Have you compared BIOS settings between your two machines? <ieure>I'm not sure there's much Guix can do if the behavior is dependent on BIOS settings. <kkremitzki>I'm using Coreboot with the SeaBIOS payload so there's no CSM setting; all the BIOS settings themselves are identical, the only variance I can think of is that I put Coreboot on each at different times, so possibly different version/flags. I'll check that possibility now <kkremitzki>Still, if that fixes it, it would be nice to diagnose what's actually happen and prevent people from running into the issue somehow <ieure>Is there something wrong with substitute servers or the build farm? Reconfigure wants to build a ton of stuff. <ieure>ex `guix weather linux-libre' shows no substitutes available. This is with a pull from just now. <yelninei>ieure: linux-libre depends on clisp (linux-libre-source -> patch -> gnulib -> clisp) <yelninei>so updating clisp triggers a rebuild of every kernel deblobbing and then a rebuild of every kernel <yelninei>and all of this is invisible to guix refresh and other tools because patch #+ includes gnulib directly to not cause a circular dependency. <civodul>yelninei: dâoh! i was wondering why there were no substitutes for linux-libre <yelninei>civodul: is there an actual issue or is ci just catching up? <yelninei>i guess the main issue is the flaky clisp testsuite <civodul>yelninei: i suppose CI is working on it: building the deblobbed tarball takes hours <yelninei>civodul: the annoying thing is that guix refresh -l doesn't detect this so it looks like a only a rebuild of a lot of lisp packages (i think via sbcl) <civodul>yelninei: thatâs the bit that i think should be reported as an issue <yelninei>civodul: there is the "bad" patch and patch/pinned which is also used for %final-inputs and does not depend on gnulib. Maybe changing to that for deblobbing during the next kernel updates could be worthwile? <yelninei>but i dont uderstand why (canonical-package patch) in make-linux-libre-source does not resolve to the %final-inputs one <Tadhgmister>a process that has chroot-ed to a subfolder can't read symlinks to stuff in the guix store right? <Tadhgmister>ehh not that much, I just have to tell my program to not chroot which is not too bafd <ieure>civodul, CI is doing the same thing where evaluations are failing again... <ieure>uncaught throw to %exception: (#<&store-protocol-error message: "reading file `/gnu/store/xlbwy8p3s2wkpqhzfb197ki90cs0pcyn-svkbd-0.4.1.tar.gz.drv': No such file or directory" status: 1>) <dajole>In my `operating-system` configuration I get the error "error: gdm-service-type: unbound variable". Aside from fixing it, how do I figure out what module that variable is usually defined in? <ieure>civodul, I wonder what's causing this? <ruther>dajole: generally by grepping the source. But you can also use guix system search for system services, guix search for packages <abbe__>ieure: how ? i just got it on a VM :/ <abbe__>with my .zhistory being corrupt :( <dajole>I'm not sure what you mean by that <ruther>dajole: what part don't you understand? <ieure>abbe__, Are you on a current Guix? The problem was that e2fsck was buggy and not repairing the FS, so would rerun every time. <civodul>ieure: previously since there had been hard reboots, load issues, etc. i thought it could be some bad-luck corruption <dajole>ruther: I know what grep is, but what do you mean by grepping the source? `guix system search gdm-service-type` doesn't return any results. <ruther>civodul: and you've checked if all files in the database exist when you were deleting the records from database? <abbe__>I get it with xfs, btrfs, ext4, ..., and all on latest guix HEAD :/ <ruther>dajole: I mean that you go to guix source, ie. git clone it, and then do grep there <ruther>dajole: guix system search works on name of the service, that is just gdm, not gdm-service-type, so it would be `guix system search gdm` <civodul>ruther: yes, itâs always the same pattern: theyâre registered in the database but are not on disk <ruther>dajole: for grepping the source, it will depend if you are grepping symbol, function etc., but generally grepping for `define.*<name>` should match it (regex), but might give you quite a lot of results <ieure>abbe__, Sounds like an issue with your VM? Are you running `sudo halt' in the virtualized Guix to shut it down? <abbe__>well, "sudo shutdown", and on both VMs and desktop, and laptop. <ieure>abbe__, Are you seeing this in the VMs, the host, or both? <abbe__>both. VMs are hosted on hetzner, and netcup. <abbe__>in VMs, i use linux-libre, and on desktop/laptop, linux-xanmod <abbe__>I'm the last poster in that bug report <PotentialUser-15>Does anyone know how to fix "'compress-documentation' phaseoutput (`/gnu/store/ff9i7x1kyi220iyv8ma8gzvdq7jmp2sz-glibc-2.39') is not allowed to refer to path `/gnu/store/6kpyn7z5jgkv5n9qjk6j7w09m7zcqfnk-bash-static-5.1.16'"? <PotentialUser-15>I'm getting this when I try to build some packages using a package transformation. I've explicitly exempted both glibc and bash-static from the transformation but still receive this error. <ieure>PotentialUser-15, I think that means the glibc build is referring to a store path not in its inputs. Are you doing some tomfoolery with bash in that transformation? <ieure>PotentialUser-15, Just double-checking (the PotentialUser-nnn nicks can rotate), you're who was asking about deleting all the documentation from outputs yesterday? <ieure>PotentialUser-15, Okay, best guess is the compress-documentation phase is confused because the docs have already been deleted. If you have no docs, there's nothing to compress. I'd delete that phase from anything that has it. <PotentialUser-15>I'll go ahead and delete that phase from glibc for now. I thought that exempting bash-static and glibc from the transformation would be sufficient, but perhaps there's some other weirdness with this. <ieure>PotentialUser-15, Well, the issue is in the glibc package, not bash-minimal. <PotentialUser-15>I still don't fully understand why glibc is trying to access a different store path, but I'm assuming that the reason exempting bash-static and glibc didn't help is because the documentation in question was removed from bash-minimal (which I now see bash-static inherits from) <ieure>PotentialUser-15, I don't think the glibc build should be doing anything with any of the bash docs. <Tadhgmister>how do you go from a derivation to a built package again? like when I do `guix build hello --derivations` it spits out a path to a .drv file, how do I then take that, build it if it isn't already and then print the path to the default output? <ieure>PotentialUser-15, Don't see anything obviously wrong. I'd use the REPL to see what the transformation is doing -- you can directly transform glibc that way, then poke at it. <Tadhgmister>(read-derivation-from-file file) and then build it once it is a derivation object, figured it out :D <PotentialUser-15>Is there a way to use specification->package in a repl? I can't seem to figure out what module I need to load to be able to use it <ieure>PotentialUser-15, Yes, though IMO there's not much point, since you can use the module the package is in and refer to its symbol directly. <ieure>I don't remember what module it's in, probably easiest to grep the source for it. <PotentialUser-15>That worked, but it doesn't look like it did anything? I ran (remove-documentation glibc) and got back immediately $1 = #<package glibc@2.33 7f05b04cb420> <ieure>PotentialUser-15, You'll have to look at the inner stuff to see what's going on, ex `(package-arguments $1)', `(cdr (assoc #:phases (package-arguments $1)))' etc <ieure>PotentialUser-15, For what, specifically? <PotentialUser-15>Anything about debugging this really. I don't feel like the repl or package variant docs have a whole lot of information about any of this. What I'm seeing now is that when I run (package-arguments $1) after running the original remove-documentation function I can see that the remove-documentation phase is added appropriately. When I change it to <PotentialUser-15>instead delete the compress-documentation phase it doesn't delete it. This confirms the behavior I was already seeing, but I don't know how to proceed beyond that. <civodul>â,phasesâ may be handy for things like that