IRC channel logs
2026-02-11.log
back to list of logs
<Tadhgmister>how do I make use of the pull_request_template.md with the agit workflow? do I do the thing about base64 encoding the pull request description? <mange>I expect so, yeah. TBH, I usually just push with agit then edit the description after the PR is created. <aliu> new to guix, fresh install (+ ran `guix pull` and ran the commands in its hint). i have trouble getting kwallet to work. the manager tells me it didn't get a response from the service, `guix system service search` tells me the service's name is kwallet, yet `herd start kwallet` says there's no such service. do i have to change my config to start the service or am i doing sth else wrong here? <mange>Are you running that "herd" command as root? <mange>And is it included in your system configuration? <mange>According to the manual kwallet-service-type is not included in the plasma-desktop-service-type, so you'll need to explicitly add it to your operating-system's services if it's not already there. <aliu>i didn't at first but now that i ran it again it's still saying the same thing. i'm using the default kde plasma config (the option in the guided installer) and it says (use-modules (gnu services desktop)). so i have to add it to my config and then i can start it manually? <aliu>(i didn't [run sudo at first]) <Tadhgmister>once you add it to your config and do `sudo guix system reconfigure` it will likely start automatically <mange>Yup, new services are started automatically. So if you add kwallet-service-type to the services field of your operating-system, then after the reconfigure command it should be started (which you can then check with "sudo herd status kwallet"). <aliu>interesting, thx. just curious, is there a way to have a service discoverable but stopped by default? <mange>Oh, wait, that might not be right. Looking at the definition, the kwallet-service-type it doesn't define a shepherd service. It just extends pam. <mange>The technical answer is "yes", but the practical answer is "not always". Shepherd services can be defined with auto-start? set to #f, but not all services expose this option further up the chain. <Tadhgmister>*practical answer is "sometimes it is annoyingly hard" - is always possible to define a shepherd service to behave how you want with auto-start? set to #f <Tadhgmister>not even sure how you'd define a programatic transformer to override the shepherd service to not autostart <mange>Yeah, there are ways to rewrite services to have the definition you want, but then that can mess up service extension in further annoying ways. <aliu>thank y'all! still want to figure out how to work kwallet tho :p <mange>I'd start by adding the kwallet-service-type to your system, and then log out/in and see what happens. I assume you're using Plasma? <mthl>Rutherther: To make the actual test I need some extra setup, I will continue tomorrow. Thanks again for your help. <Tadhgmister>ok I'm not at the point where I'm trying to do `git push -o title="blah"` it is telling me the topic-branch option is not set, what would I specify the topic as? <mange>From what I understand, the topic is just the "key" for the PR, so if you do another push (with the right "force" option) it can match it to the right PR. I thought it just used the branch name by default. <mange>Ah, right, I use the /refs/for/main/topic form, and I just put the branch name there. So "/refs/for/main/my-branch-name" or whatever. <mange>Sorry, /master/, not /main/ (I was just copying form the Forgejo documentation, which uses main). <Tadhgmister>would someone be willing to quickly look over https://codeberg.org/guix/guix/pulls/6303 and let me know if I did anything incorrect in the pull request logic, specifically if there are tags in the title I'm supposed to add or if the commit message is properly formatted <mange>Take a look at other commit messages, but there's usually a list of specific changes. Like * gnu/home/services.scm(compute-on-change-gexp)[equal-directories?]: Use and-map instead of map to avoid reporting unequal directories as equal. <Tadhgmister>oh wait, can I edit the commit message at this point? <Tadhgmister>cause I'm not making an additional change.... I think I'll just not worry about the commit message and let who ever merges it deal <hanker>Can I tell one of the certbot-service-type certificates to not create an automatic HTTP->HTTPS redirect, or do I just have to suffer and bow in submission? <anemofilia>Tadhgmister: You can edit the commit on rebase and then force-push to your fork's branch <hanker>ah, it's the `default-location` parameter it seems. <Tadhgmister>did `git commit --amend` then figured out the force push, tyvm for the assist <Tadhgmister>so the "topic" is a local identifier for your pull request? I named it "team-home" cause I thought it might be related to the labels but obviously it is not <Tadhgmister>ah I see it, so the pull request is logically stored on branch `tadhgmister/team-home`. Ok so now I know <apteryx>hm, I forgot; what's the cure for: ";;; In procedure load-thunk-from-memory: incompatible bytecode version" ? Maybe it's the guile cache that's owned by root or something. <apteryx>I think this might have helped: sudo find ~/.cache -user root -execdir rm {} + <futurile-afk>what is the purpose of "no definitive" article in descriptions, it just leads to very odd constructions. "This package provides ..." - I mean no shit "as a user" I literally ran the command to list a package, so now I'm uselessly looking at three words telling me I'm looking at a package. <csantosb>sneek: later tell civodul, rebased hpc on master, with all fixes and improvements; I'm almost tempted to upgrade spirvm-llvm-translator to llvm-20, same as ROCm and SYCL, WDYT ? <futurile>there's no rule in grammar about this that I know of - unless we're applying something from French into English maybe? <futurile>oh well hardly the most important thing - but it irritates and makes me chuckle every time <identity>futurile: i think «This package provides…» is definitely a hypercorrection, i would expect the description for coreutils to start with something like «The GNU Core Utilities are the basic […] utilities» instead of the current «GNU Coreutils package includes all of the [blah blah blah]» <identity>i bet somebody wrote «The GNU Coreutils package» first and corrected it by just removing the definite article <futurile>yeah, I think it's a over-correction due to the lint rule on the Synopis. If you use 'The', 'An' - any form of definitive article - gux lint tells you off - so then people think the same thing applies to the Description field. And honestly, why wouldn't you. <futurile>guix lint just told me: "no article allowed at the beginning of the synopsis" <futurile>so now I'm going to write "This package" instead of "The blah package does X" <ArneBab>janneke: does the guile-final pack include all the packages on the path to building? ⇒ can we run guix gc just after guile-final is ready? <ArneBab>(a docker image with only bash-mesboot is at 1.8MB) <ArneBab>general question: can I tell guix pack to run guix gc before packing? <ArneBab>this is 4.7 M: du -hs $(guix pack --format=docker --symlink=/bin=bin -e '(@@ (gnu packages bootstrap) %bootstrap-guile)') <ArneBab>but this is 39 M: du -hs $(guix pack --format=docker --symlink=/bin=bin -e '(@@ (gnu packages commencement) guile-final)') <ArneBab>I’d have expected that guile-final is roughly same size as %bootstrap-guile. <janneke>you can build a tarball: guix pack --symlink=/bin=bin -e '(@@ (gnu packages commencement) guile-final)' <janneke>it should include all dependencies needed to run guile-final <janneke>tar tzf $(guix pack --symlink=/bin=bin -e '(@@ (gnu packages commencement) guile-final)') | grep '/gnu/store/[^/]*/$' <ArneBab>you need to unpack twice -- I’m trying that right now <janneke>gives me: guile-3.0.9/ bash-static-5.2.37/ libunistring-1.3/ emacs-subdirs/ profile/ bash-minimal-5.2.37/ libffi-3.4.6/ gcc-14.3.0-lib/ pkg-config-0.29.2/ libgc-8.2.8/ info-dir/ glibc-2.41/ <ArneBab>I got the sizes of these -- does guile need gcc-14.3.0-lib to run? <meatg1rl>hi, thanks ieure, i've rebooted and now it builds! <ArneBab>and does it need both bash-minimal and bash-static? <janneke>ArneBab: i guess you need (at least) gcc-14.3.0-lib/lib/libgcc_s.so ? <futurile>identity: if you put "The" in the description field it doesn't complain, I just tried it. Anyway, my overall point is that this rule doesn't make much sense to me - maybe there's some rationale, but it's not stated - it just seems to cause very odd constructs in the fields <ArneBab>janneke: ah, yes … that’s what’s usually missing when trying to run binaries <futurile>identity: also `guix lint` doesn't know about this difference in The vs An that you pointed out heh! It complains about both in the Synopsis field. <futurile>ACTION probably needs to learn more actual grammar at some point <ArneBab>janneke: for the size of guile: that’s mostly the compile cache (ccache). All of guile is 55M and the ccache is already 47M of that. <efraim>ArneBab: %guile-bootstrap is from (gnu packages make-bootstrap), based on %guile-static-stripped, so it might be worth looking more in that direction than the dynamically linked guile used in %final-packages <ArneBab>efraim: that includes all of gcc 14.3.0 as well as two copies of glibc-2.41 -- but I guess that "build me as minimal docker image" isn’t the goal of it. <janneke>ArneBab: i'm sure other guix'ers who work with yocto or something like that would be interested in creating smaller image/pack sizes <Alavi_me>Hi dear guix! I'm just starting to use guix. here's a problem I encountered: I have gotten a Laravel project and I need to install php v7 and composer. How do I do that? current version of guix only has v8. I read about inferiors and channels but I really don't understand what's going on. any help? <janneke>Alavi_me: looking at the guix commit history, i see: "4d4fad68198 gnu: php: Update to 8.2.2." <csantosb>If you go back in time to commit 7ae4cfa5aa5b48afc454c392055231a953f5b6c4, you'll get php 7.4.30 <janneke>so you could try commit: git show 4d4fad68198~ | head -1 => c8423a5457a846e42634a9a644916abfeceab5f2 <Alavi_me>So if I want to have different versions of packages (very common for node, deno, php, etc.) I shold go search in the guix git commit history? <janneke>and do something like: guix time-machine --commit=c8423a5457a846e42634a9a644916abfeceab5f2 -- shell php <csantosb>Alavi_me: The idea is, you create a dedicated shell, based on a given commit in history, and put in there the sw available at this point in time <Alavi_me>And then when I want to use php 8 again, I again use time-machine and go to the latest commit? <janneke>or possibly contribute "important missing" packages? <janneke>Alavi_me: what you could also do, is copy the old php-7.x package definition, add it to a private channel, and rebuild it "in the present" <Alavi_me>Ok I'm confused. I'll try to do this `guix time-machine --commit=c8423a5457a846e42634a9a644916abfeceab5f2 -- shell php` and see what happens <efraim>ArneBab: I was on the other screen for a bit and didn't see you responded. It might be that it needs to build those, but the final guile will be statically linked and not pull them in with `guix pack -f docker` <efraim>I'm seeing %guile-static-stripped at 56M with du <ArneBab>efraim: no problems, I urgently need to switch for the other, too … I see that guix pack --format=docker --symlink=/bin=bin -e '(@@ (gnu packages bootstrap) %bootstrap-guile)' actually is small (4,7 M) <ArneBab>du -hs $(guix pack --format=docker --symlink=/bin=bin -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)') <ArneBab>171M /gnu/store/wvq3b2xpm9xyady8j495zh9rfxcvw408-guile-static-stripped-docker-pack.tar.gz <efraim>that might be guile@2.0.9 for x86_64 <efraim>du -sch $(guix build -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)') <efraim>56M /gnu/store/ii7l0pfqw1sdf51gjn7m8bzwxdzp2ifv-guile-static-stripped-3.0.9 <ArneBab>80% of the size of guile-static-stripped is the ccache <attila_lendvai>anyone with experience running guix on musl libc (openwrt)? when i try to install nss-certs, it errors out when it tries to symlink a non-ascii filename. setting LANG and LC_ALL doesn't seem to help. <efraim>perhaps you need something on the openwrt side to handle non-ascii filenames? <ArneBab>janneke: I tried something, but it does not work yet: https://paste.debian.net/hidden/f6e84859 ← extracting only libgcc_s.so[.1] from gcc. But it does not work yet: I get `error: <substitutable>: unbound variable` when calling guix shell --pure -D guix guix gperf texinfo gettext -- ./pre-inst-env guix build -e '(@@ (gnu packages commencement) libgcc_s)' -- so I must have a bug in the code that I fail to find. <attila_lendvai>ACTION digs into the guile sources, faces some C code, and closes the window <ArneBab>janneke: if this should work as input for a package inheriting guile-final, the size of the docker container could go down by 33 MB (but I guess that more is needed). <ArneBab>But I have to stop for now … I spent far too long struggling with it. <ArneBab>I found out why the guix pack tarball is so huge for chickadee: guile3.0-opengl pulls in mesa (131 MB) which in turn pulls in clang→gcc (264 MB), llvm-for-mesa (165 MB), and python-minimal (129 MB), and via mpg123→pulseaudio→doxygen→python (121 MB). That’s already almost half the package size. <ArneBab>That mesa pulls in 0.5 GB of dependencies also affects most guix installations. <ekaitz>anyone is experienced with latex in guix? <ekaitz>i use texlive (full) and I think we did something that killed it <ekaitz>it takes a minute to produce a simple document with xelatex <ekaitz>it was almost instataneous before <look>For anyone getting 'error: <substitutable>: unbound variable', doing a 'make clean && ./bootstrap && ./configure && make' solved it for me <ekaitz>andreas-e: when I launch xelatex it's reading my whole .guix/profile <ekaitz>no wonder why it takes minutes to run lol <ekaitz>`strace -e openat`'s log is hundreds of megabytes <ekaitz>andreas-e: i uploaded the log file to the issue, maybe I'm doing it wrong? <andreas-e>A cheating answer would be that you should not use texlive-scheme-full... It is essentially not needed, you should be able to work with a smaller package collection, starting withtexlive-collection-latex, texlive-collection-latexrecommended and texlive-collection-xetex, for instance; plus a bit of texlive-babel* and whatever else you end up needing. <ekaitz>andreas-e: yeah, sure, but i may not be able to migrate out of it right now... :S <ekaitz>i've postponed this for so long... <andreas-e>I have an environment variable GUIX_TEXMF=/home/andreas/.guix-profile/share/texmf-dist that should take care of searching; so I do not see why more of this is searched (but with the full texlive, this will be a lot already). <ekaitz>i also tried to move to the sub-package based way in the past, and it was slow, too <JohnDawson>Should a Python package that offers a command-line interface and is not a library be named `mypackage` or `python-mypackage` in Guix? <ekaitz>andreas-e: I have that too, but with that path repeated three times <andreas-e>Compared to the previous monolithic texlive distribution, the only substantial difference I see is that now there are masses of symbolic links, where before everything was files. <andreas-e>(Mine is repeated twice, probably because I set it in the wrong place such as .bashrc...) <Kabouik>It seems all issues my intern was having with Guix on a foreign distro with KDE are related to ~/etc/profile not being sourced (it's /etc/profile that sources /etc/profile.d/zzz-guix.sh as well, and the latter is where env variables are set and profiles detected). I am not familiar with such issues because I use Guix system, but would it be safe/advisable to just add a line in her ~/.bashrc or ~/.bash_profile to force sourcing /etc/profile? Also it <Kabouik>seems that GDM itself does not know about Guix either, and hence the DE, because she can't select Sway as her WM on the GDM logon screen if Sway was installed by Guix. <ekaitz>andreas-e: oh yeah, so it shouldnt iterate over the thing over and over again anyway so my first intuition was wrong <andreas-e>JohnDawson: mypackage. The idea is that is where a user would find it, and in this case the user would not be a Python programmer. <ArneBab>look: it worked! Thank you! My definition is still wrong, but now the reason is my definition ☺ <andreas-e>It is not completely explicit since the expression "Python module" is not really defined. But it has to be seen in opposition to "Python application". In a world where this opposition does not really exist... <ekaitz>andreas-e: any idea on how can I debug this further? i'm digging further and it is xelatex who opens everything, maybe I should read which env-vars it reads... <andreas-e>I do not know. You just run "xelatex" on a .tex file? <ekaitz>i captured all env vars of the process to check it <ekaitz>and yeah the log file is fing huge <andreas-e>I do not see a problem, see my comment on the issue. <vntsuyo>i've never seen this one before, does anybody know what this is? <ekaitz>andreas-e: i'll try with a minimal scheme just in case... but it's weird how it reads out of the directory... maybe some package description is wrong? <futurile>vntsuyo: is that git it's trying to build? there's a hash conflict <futurile>vntsuyo: you could try building git yourself, or check it against other substitute servers <andreas-e>ekaitz: I also find it weird and have no explanation. But that things take long is not surprising, just because the full texlive is so big - about 4500 packages. <ekaitz>andreas-e: but it was faster before, so that doesn't actually explain it <ekaitz>and I don't feel very comfortable with the fact that we made a package x10 slower without explanation <ekaitz>i hope this is only happening in my local setup <ArneBab>ekaitz: I have most of texlive installed individually and it’s not that slow. So that looks odd. <ArneBab>most -- I still stumble from time to time over missing packages that I have to add. <ArneBab>does it put all the files into a single directory or such? <ekaitz>well, it's a very simple package really so idk <yelninei>tried to see whats needed to port dmd aswell but the builder immediately segfaulted. When skipping creating threads it failed to spawn a process with ENOMEM. i guess this is somewhere where CRuntime_Glibc actually means linux and not glibc <ArneBab>(so that just listing the directory is slow) <untrusem>does using emacs package from guix have a disadvantages over managing them separately? <ArneBab>untrusem: mixing guix ones and package-install ones can get into unexpected version inconsistencies. And you can’t just M-x package-install them. I’d prefer having them all in guix, though (even though I currently don’t). <untrusem>its same for me, though I am thinking of moving off to elpaca <ekaitz>also about latex, why is basque in french? <untrusem>I remember that native compilation isn't support for guix's emacs packages, I might be wrong <untrusem>why is `guix refresh` is building a new guix like it does for `guix pull` <untrusem>I also saw this same behaviour with guix build yesterday <attila_lendvai>what do i need for `clang --target=i686-unknown-linux-gnu ...` to work on a 64 bit guix system install? is it at all possible? note that i don't need a full cross-compilation setup, just 32/64 bit on x86 (if that is different). <vntsuyo>futurile: how do I build git by myself? I'm not sure if it's trying to build Git either <vntsuyo>I also tried to not use substitute servers and no offloads but no luck <untrusem>I tried with `guix build git --no-subsitutes` It does build for mne <attila_lendvai>is it possible to specify the target system in a manifest.scm? e.g. to something like package->manifest-entry ? <futurile>vntsuyo: it's trying to build something in that location /gnu/store/71qh2xxx - you can try to see what's there. <futurile>vntsuyo: it tells you that there's a 'View build log' at '/var/log/drvs/y0.....' - so you can look in there to see what it's trying to build. <attila_lendvai>FTR, i failed to make both 32 and 64 bit work in a guix shell. this works, but requires manual switching: `guix shell --system=i686-linux` <attila_lendvai>nevertheless, guix is awesome that such things are possible with such ease <yelninei>FuncProgLinux: Hi, did you see my message from yesterday? <Kabouik>If I read https://github.com/swaywm/sway/issues/3109 correctly, GDM does not source /etc/profile because it does not start a login shell. This is not an issue if running something like Sway because Sway's exec in its config file will start a shell. But what if Sway itself was installed with Guix on a foreign distro? In that case, GDM does not even know about Sway because it did not source /etc/profile.d/zzz-guix.sh, and therefore does not even know <FuncProgLinux>yelninei: Hello, I saw the discussion on MATE about pluma not building as well on Fedora <Kabouik>I feel like there is a hole towards seamless support of Guix on foreign distros because of that. <ekaitz>ArneBab: do you use xelatex? could you please try to `strace -e openat xelatex something.latex`? <ekaitz>in my case, it produces a huge log! it's reading everything in my current system <ekaitz>it's like latex has always been slow to me when using separate packages and I thought it was for some other reason <ekaitz>OH! if I use lualatex instead it does: luaotfload | db : Font names database not found, generating new one. <postroutine>Hello. I tried to update the Guix daemon on Fedora with the command `sudo -i guix pull` then `sudo -i systemctl restart guix-daemon.service`. <postroutine>But the Guix daemon cannot restart. I get the error `/etc/profile.d/zzz-guix.sh: ligne 29: /root/.guix-profile/etc/profile: Aucun fichier ou dossier de ce nom` <postroutine>I searched on Duckduckgo and Google if someone have a similar problem, but cannot found anything. <Rutherther>postroutine: what's the line 29 in that script for you? <Rutherther>oh okay I get it now. Yes, it's an error in the script, but it's harmless. I've fixed that error few days ago <postroutine>Rutherther, the line 29 is ` . "$GUIX_PROFILE/etc/profile"` <yelninei>FuncProgLinux: There is already a commit in pluma and essentially the same one in eom that should fix. Maybe update to those commits instead of the tag? <Rutherther>postroutine: I doubt that the error you sent is an error preventing the daemon from restarting, though <postroutine>Rutherther, it is the error I can see when I execute `systemctl restart`. <postroutine>But now you say it, I get other errors in journalctl <Rutherther>postroutine: look into journal, systemctl restart does not really list errors. I doubt it's actually log from systemctl, more likely to me seems it's going to be from sudo. <ekaitz>I think I founnd what's going on with this! it's the font search! <postroutine>Rutherther, I get a permission denied for the execution of `/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon`. I guess Selinux is behind it, again. <Rutherther>postroutine: are you using privileged or unprivileged daemon? <postroutine>The default option I get with the official installation some month ago. <Rutherther>I supose. Then did you update the policy with a new one? The one in 1.4.0 is lacking a lot <postroutine>Ok, Selinux is guilty. If I run "setenforce 0", I can restart the Guix daemon. <postroutine>I didn't change anything about how Guix run. I only upgrade from my user account regularly and this afternoon I remembered that I also need to upgrade as root if I want to update the Guix daemon. <Rutherther>so you've never installed policy from newer guix than 1.4.0? <postroutine>Ah, yes, I have done it. Because at the beginning Guix didn't work with Selinux. But it was a long time ago, I don't remember everything. <Wurt>I am packaging Goal (an array language) that needs /bin/sh. Should I substitute it with (append-file bash-minimal "/bin/sh")? Perhaps a user might want to use another shell interpreter. Tests also make calls to /bin/sh, so I need access to it at build time. <Rutherther>Wurt: yes, substitute it for a full path so that it doesn't depend on the system. If users want to use another shell interpreter they might do so by transforming the given package <ekaitz>sneek: later tell andreas-e: it was the fonts!!!! <Rutherther>ArneBab: you... can't. That's the point, pack will include all necessary dependencies. You would have to make sure the output actually does not depend on these. Then they won't be included in the pack. Presumably the libgcc_s.so.1 you've copied references other store paths. So you would need to compile it in such a way, or modify it in such a way so that it doesn't need the paths you do not want. <vntsuyo>futurile: ah thanks, I wish Guix could just print out all errors to console by default lol <identity>18:40 <Rutherther> ArneBab: you... can't. That's the point, pack will include all necessary dependencies. You would have to make sure the output actually does not depend on these. Then they won't be included in the pack. Presumably the libgcc_s.so.1 you've copied references other store paths. So you would need to compile it in such a way, or modify it in such a way so that it doesn't need the paths you do not want. <ArneBab>Rutherther: How can I include only runtime dependencies but not build-time dependencies? <ArneBab>(similar to how I don’t ship the source tarballs for every library) <Rutherther>ArneBab: what does that mean... build-time dependency... it made it into the output path, so it's a runtime dependency at the moment, otherwise it wouldn't make it into the output path. Depends on why it ended as a runtime dependency there, you will need to investigate that <ArneBab>GCC builds a lot of different libraries, but I only need a small subset of these for Guile to run correctly. How can I leave out the ones that never get used? <Rutherther>by ensuring they're not referenced in the output path you produce? ... <Rutherther>I really don't understand what's not clear about it. Just make sure the path you do not want is not referenced anywhere, ie. override the references with your modified libgcc_s.so through patchelf for example... or anything else, depending on where the paths are actually referenced. Or compile it with that library from the beginning so that you do not have to do any patching <ieure>ArneBab, You'd have to make a package variant of gcc which only includes the things you need, then replace the normal one with it in every package in your pack. <ieure>ArneBab, Note that the subset of things you need for your usecase is likely much smaller than the subset needed by every store item in the pack -- so you'll have to do some iteration to figure out what the true minimal working set is. Also, you have to build nearly everything locally when you build the pack. <Rutherther>you do not have to build anything, you can just patch it, ie. with patchelf as long as we're talking about ELF binaries <ieure>Rutherther, I think the issue is that referencing one small thing in the gcc store causes the whole (large) gcc store item to be included. Patching binaries won't solve that. <ArneBab>building locally isn’t the problem. My current problem is that the executable tarball for a 12 MiB chickadee game is almost 500 MiB. <Rutherther>ieure: yes, exactly. It will solve it, you just replace the original libgcc path with your own one containing only libgcc itself <ieure>Rutherther, I see, yes, that saves the rebuild, but you still have to ensure that *nothing else* in the pack references gcc, otherwise you actually make the pack larger. <ieure>And you still have to have a store item containing only libgcc. <ArneBab>The reason is that the build process includes all of GCC, all of LLVM, all of MESA and two complete python packages. <ArneBab>And at least the compiler parts of GCC and the two python packages aren’t needed during runtime. <untrusem>I guess go static binaries works without any shenanigans <ArneBab>packaging guile-static also includes all of GCC -- I tried. <ArneBab>guix pack -e '(@@ (gnu packages make-bootstrap) %guile-static-3.0)' <Rutherther>ArneBab: right it unfortunately references glibc, it seems to me mostly in some debug messages <ieure>ArneBab, Then there's some path from gcc to %guile-static-3.0. I see that its store item references libxcrypt, libggc, libgc, bash-minimal, phg-config, glibc etc. <ArneBab>Looks like %bootstrap-guile avoids those dependencies via tarball-package … <ArneBab>Rutherther: so it’s not completely statically built? <ieure>The binary is; the store item contains more than just the binary. <Rutherther>as I am saying, the references seem to be in debugging messages, not really something functional. From quick look at least <Rutherther>likely the binary would still work if copied to a different store path and the store references to glibc were forcibly stripped out, ie. by replacing the hash by a different one or by making it upper case. That would drop the references <ArneBab>how can I check what’s referenced in the binary? <ArneBab>I tried nm but that didn’t show any symbols. <ArneBab>But my "what’s missing in library" skills are really rusty … <bdunahu->When the guix importer adds the "TODO REVIEW: Check bundled sources" comment to a rust library in the crates file, is the intention that it is audited for non-free components before the dependent package is contributed? <ArneBab>guix shell patchelf -- patchelf --print-needed /gnu/store/zv7i3jnbp9qp3xmywvc31mc7x0jvlvx7-libgcc_s-0.1/lib/libgcc_s.so ? ⇒ libc.so.6 + ld-linux-x86-64.so.2 <Rutherther>ArneBab: "strings" or just "grep --binary-files=text" as long as you're acknowledging that it can send terminal control signals that can mess up your terminal <bdunahu>Also, when/should I remove the comments added by the guix importer? <ArneBab>strings /gnu/store/…-libgcc_s-0.1/lib/libgcc_s.so | grep /store/ ⇒ /gnu/store/…-glibc-2.41/lib -- I don’t see GCC there, but maybe because it from the GCC package, so that need not be referenced? <eikcaz>Dispite being in the netdev group, I get "Insufficient privileges" when I try to add a wpa2 enterprise wifi <ArneBab>… no, seems to just be the debug symbols <ieure>ArneBab, There's a stripped variant of the static Guile package. <ieure>Defined near it in the code. Maybe that's closer to what you want. <ArneBab>That still pulls in gcc when used with guix pack: guix shell --pure -D guix guix gperf texinfo gettext -- ./pre-inst-env guix pack -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)' <ArneBab>But the references should all be gone ⇒ find $(guix shell --pure -D guix guix gperf texinfo gettext -- ./pre-inst-env guix build -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)') -type f | xargs strings | grep /store <ArneBab>(the only finds are /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-…) <eikcaz>I was able to get around my issue by un-checking the box to share connection to all users. Annoyingly criptic error message, but seems more like an upstream issue than a guix one <Rutherther>ArneBab: check with guix graph where the references are coming from <Rutherther>ArneBab: or is it still referenced by the guile static path directly? <ArneBab>those are the results from grepping in strings called on all files in the %guile-static-stripped package <ArneBab>there’s a path from guile-static-stripped over glibc to bash-static: guix graph --path -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)' bash-static <ArneBab>Path: guile-static-stripped@3.0.9 → glibc@2.41 → bash-static@5.2.37 <kestrelwx>Oh, codeberg 503 when trying to search pulls. <ieure>GitHub is making Codeberg upitme look pretty good in 2026. <ArneBab>there’s also no path from guile-static-stripped to gcc, but gcc is included in a guix pack: <ArneBab>no path to GCC: guix graph --path -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)' -e '(@@ (gnu packages gcc) gcc)' <ArneBab>but guix pack includes GCC: guix pack -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)' <Rutherther>there are multiple gcc packages, not just the one you've specified with the --path <ArneBab>guix graph -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)' | grep gcc <Rutherther>Nothing is 'excluded'. Instead, everything referenced is included. Whether it's the native-inputs that are referenced or inputs that are referenced, doesn't matter. It's true that native-inputs shouldn't be referenced, but that's what that is, they shouldn't be. Nothing is guaranteeing they aren't <Rutherther>also sorry the guix graph on the packages is wrong here, I haven't really realized you're running it on the package <Rutherther>you need to run it on the store path, with --type=references <Rutherther>that's what you're interested in, the references of the store paths <ArneBab>then I at least didn’t misunderstand the logic <ArneBab>that’s strange then: references is empty: guix graph --type=references -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)' <ArneBab>so maybe guix pack just includes more than needed? (⇒ implementation detail that can be changed without breaking the logic) <Rutherther>ArneBab: no, guix pack is fine, it includes only referenced store paths. But the profile made with the guile static has references to glibc and gcc <Rutherther>ArneBab: for some reason the guile static propagates libgc and libunistring. Those end up in the profile. libgc has references to gcc and glibc <Rutherther>ArneBab: I think better than what I suggested is to first build a profile and then check guix graph on the profile itself. I didn't really expect static guile is going to propagate anything, that's why I didn't suggest it right away <kestrelwx>lilyp: Hi! I should've created an issue tracking removal of p7zip, right? <Rutherther>ArneBab: one way of getting path to the profile is "guix shell -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)' -- bash -c 'echo $GUIX_ENVIRONMENT'" <kestrelwx>Oh, nevermind. The discussion ended with keeping an alias, which makes sense to me. <Alavi_me>I want to use and older version of PHP that isn't currently in guix channels, So as far as I understood, I had to use time-machine to the version of guix that had php7. so I run the command `guix time-machine --commit=7ae4cfa5aa5b48afc454c392055231a953f5b6c4` and I get this error https://paste.rs/BRHf7.txt <lilyp>kestrelwx: it's never to late to do so :) <simendsjo>Anyone from the lisp team here? SBCL 2.6.1 has some interesting features, but it's still on 2.5.8, and I cannot see any issues/PRs or brances with any update in progress. Any reason for the delay, or is it just because nobody opened a PR yet? <untrusem>Alavi_me, you also have to specify what command you want to use time-machine with <untrusem> guix time-machine -C channl.scm -- <shell something> <- this is a command I wanna use time machine with <Rutherther>untrusem: you don't really have to. If you won't, you will just get the path with guix <untrusem>haven't seen the paste, just their message <untrusem>Alavi_me, it builds for me I tried it on my machine <Rutherther>Alavi_me: What guix revision are you on? (guix describe) Does it happen persistently if you rerun? <theesm1>vagrantc: there's been another round of kernel updates today, i'll probably create a PR for those tonight if you're not already working on doing so <vagrantc>theesm1: hmmm... any objection to pushing the existing ones to kernel-updates so ci can build them? <vagrantc>theesm1: updates are practically weekly, so there's always a new one waiting :) <vagrantc>this round appears to have updates for every kernel branch... wheee. <theesm1>feel free to push the existing ones to kernel-updates, i've seen your comments on 6183 but didn't get around to merge your changes from 6280 to it <theesm1>so pick whatever PR is easier for you to push the changes to kernel-updates <theesm1>yup, iirc it's always a few days after a major version bump that all other kernels get updated as well (otherwise it sometimes is just a particular series, only stable etc.) <untrusem>this might have been asked before, but I have seen guix free kernel as a criticism in nix channels as it being insecure than default kernel <old>hey where can I see cuirass bot source code? <old>that's cuirass itself, not the bot <old>I'm refering to the bot that answer to pull request on Codeberg and build stuff automatically <vagrantc>theesm1: ok, updated kernel-updates with your commits and mine cherry-picked on top <vagrantc>hopfully will not have to update the mnt/reform patches with the new updates <theesm1>untrusem: imho there's some validity to that criticism in regards to things like microcode patches (but imho shipping not-really-auditable binary blobs also isn't a good practice security wise imho as it effectively means blindly trusting firmware vendors) <vagrantc>untrusem: what specifically is less secure about it? certainly more secure from network attacks, as many wifi and ethernet drivers simply cannot be used! :) <untrusem>old: I visited the bot profile and it lists this repo for issues <old>ya I saw the same. odd <theesm1>vagrantc: sounds good! i hope mnt will mainline more of their things in the long run (like DTS and out-of-tree patches) so one day we'll able to just run a generic arm64 kernel <vagrantc>theesm1: me too. overall the patchsets have mostly shrunk over time, until they go and introduce a new platform... :) <untrusem>vagrantc, I mean I will ask them the specific things I don't know about this myself <theesm1>i think their criticism mostly boils down to the spectre/meltdown microcode patches linux-libre didn't include as their blobs and possibly some other things as well <theesm1>vagrantc: yes, i mean it's good when they come up with new hardware and platforms in a wanting-mnt-to-succeed-perspective, but it *does* cause maintenance overhead^^ think i'll give todays round of updates a go, we should probably get those to the kernel-updates branch as well for substitutes availability in time <theesm1>will probably try to at least build one or two kernels before creating the PR <vagrantc>theesm1: if you could ping me with patches for 6.18 and 6.12 i can test the mnt/reform patches (or try to build them with --target=aarch64-linux-gnu) to see if the patches at least apply <ArneBab>I checked the size of the store files, and what I really didn’t expect: 793M /gnu/store/…-font-sarasa-gothic-1.0.27 ← almost a Gigabyte for a font (of which I have 20 versions on disk) <ArneBab>ACTION filled up the disk with the experiments today … <vagrantc>are all those 20 versions actually different? there is some dedupliation in the store <ArneBab>vagrantc: at least the version numbers are different; deduplication does save around 100GiB, IIRC <ArneBab>but some have different sizes, so it can’t deduplicate all copies. <Rutherther>version numbers in the store path name or inside of the store paths? <ArneBab>in the store path → /gnu/store/…-font-sarasa-gothic-1.0.27 and /gnu/store/…-font-sarasa-gothic-1.0.30 and … <Rutherther>right, but the deduplication looks at the contents, not at the store path names <Rutherther>so if they were the same, it would also deduplicate them. But I expect different versions are going to have some changes <ArneBab>wow, yes, the font is really that big: 800 MB for the compressed source archive. <lilyp>a reasonable split of sarasa into multiple outputs would likely be welcome, same goes for other big fonts <Guest22>does anyone use ungoogled-chromium on Guix? <Guest22>I had been using it, now it does not seem to install <Guest22>building /gnu/store/p222lxn6wsanmhaqbhfl9qrgf0amn0yz-ungoogled-chromium-140.0.7339.207-1.drv... <Guest22> 31% ▕██████████████████████████████████ ▏builder for `/gnu/store/p222lxn6wsanmhaqbhfl9qrgf0amn0yz-ungoogled-chromium-140.0.7339.207-1.drv' failed with exit code <Guest22>build of /gnu/store/p222lxn6wsanmhaqbhfl9qrgf0amn0yz-ungoogled-chromium-140.0.7339.207-1.drv failed <Guest22>View build log at '/var/log/guix/drvs/p2/22lxn6wsanmhaqbhfl9qrgf0amn0yz-ungoogled-chromium-140.0.7339.207-1.drv.gz'. <Guest22>cannot build derivation `/gnu/store/1b3qhhhmx9vl04bsa8sgxf7bj1yjyr6y-profile.drv': 1 dependencies couldn't be built <Guest22>../../third_party/webrtc/modules/video_capture/linux/pipewire_session.cc:158:10: error: use of undeclared identifier 'spa_pod_object_find_prop'; did you mean 'spa_pod_object_body'? <Guest22> 158 | prop = spa_pod_object_find_prop(obj, prop, SPA_FORMAT_VIDEO_framerate); <Guest22>140 is a very old version, not sure if that matters <Guest22>Release 145.0.7632.45-1 just dropped <mange>I think tje ungoogle-chromium build was broken in a recent branch merge. Maybe python? <Guest22>what worries me is how a package can be broken if the idea is that the builds are all reproducible and repeatable <Guest22>if it /used/ to build, but no longer builds? <mange>Sure, because the inputs were changed. <mange>If you want to build it you can use guix time-machine to go back to before the change in inputs. <Guest22>I guess I don't understand the whole premise then <mange>The builds are reproducible: the same inputs yield the same outputs. However, in a distribution you have a collection of packages which depend on each other. <mange>If you change an input, then the output might change. It's still reproducible, it's just different. <mange>You can even use inferiors in a manifest to tell Guix to build each package using a different commit of the Guix package definitions, so you can mix and match to get what you need. Although this can come with different costs (maintenance, lagging security updates, etc.). <futurile>Guest22: it's a bit difficult to internalise the whole premise all at once. It's quite different from the way other Linux distro's do it - other than Nix. <Guest22>Can this happen with Nix packages? I thought the idea was to specify all the inputs to a build *exactly* -- including the toolchains <Guest22>with the same inputs, one would expect the same result each time <mange>The inputs to a build are exact, but they're not inline/duplicated. They reference other package definitions in the distribution. This is the same in Nix. <Guest22>(and I guess you need a libc that matches your kernel?) <mange>So updating a definition somewhere requires rebuilding everything which (transitively) depends on that definition, and doing that might break things. <Guest22>but the reference includes (in the path) a hash of the contents of that package, no? <mange>For a given Guix commit (as reported by "guix describe") the build is the same. <mange>So if I have (package (name my-package) (inputs (list python-flask)) ...) in my package definition, it depends on the definition "python-flask". If I change that definition then my-package will also need to be rebuilt. <mange>It doesn't depend on the *contents* of python-flask, because we don't know that until we build it. It depends on the *definition* of python-flask. The instructions for how to build it. <mange>When you look in the store, you see /gnu/store/{a long string of characters}-{some human readable name}. The long string of characters is a hash of the instructions to build that thing. (You can see the instructions in .drv files in the store, too.) <Guest22>ahhh... the package definition is missing the package-lock equivalent... <mange>Yeah, basically. Rather, I'd say the package-lock is Guix-wide, rather than package-local. <Guest22>In this case it looks like an input was to the compile was the header file /gnu/store/x8yb0azpvg4favih8h2v87x8yd3i8vsi-pipewire-1.5.85/include/spa-0.2/spa/pod/pod.h <mange>Right, so Guix would consider "/gnu/store/x8yb0azpvg4favih8h2v87x8yd3i8vsi-pipewire-1.5.85" the input, and that input is a directory tree which has "include/spa-0.2/spa/pod/pod.h" in it. <Guest22>presumably the instructions to build ungoogled-chromium just asked for some version of this, and some global decision about the distro as a whole provided this particular version, which didn't compile? <mange>But that "/gnu/store/x8yb0azpvg4favih8h2v87x8yd3i8vsi-pipewire-1.5.85" is a result of a specific definition, which you can find in Guix with "guix edit pipewire" (which will open it in your editor). <mange>And a bunch of native-inputs and inputs, which themselves reference other packages. <Guest22>so the "1.5.85" part was not specified by ungoogled-chromium? it just asked for *some* version? <mange>It's all just Scheme code, so those are actually embedding <package> objects (which are specific versions), but the scheme variable resolves which package is used. <mange>I'm surprised I didn't immediately find that on the Guix website when I just checked, but Wikipedia says that Guix is a rolling release at least. :P