IRC channel logs
2025-08-09.log
back to list of logs
<gabber>maybe the lowest Lovelace Index (LI)...? <ekaitz>gabber: if you are smart enough you can use git for some of those insights <ekaitz>i'm not smart enough, i tried and failed <gabber>we often have more than 100 commits in a day <ekaitz>gabber: okay try `git shortlog -s -n` <ekaitz>that would require some cleaning as some people appear several times <gabber>more than 1000 contributors!? nice! <identity>it is also a question of which builds are reproducible <bavier>I think the data service has stats one the portion of guix packages that are reproducible. <bavier>and if "in progress" means "not 100%", then that's just no very precise. <gabber>it's all just "No" and "in progress" except for tails. without further explanation what the category actually means <gabber>things that are not reproducible in Guix are considered a bug, right? <gabber>so i think we could just paint that particular spot in the table green <bavier>besides packages, reproducing e.g. development environments, system and home configurations, aren't usually in scope for many other distros but are something Guix excels at. <gabber>ACTION just fixed the wiki table <Octorine>I'm trying to install Guix on a new laptop, and the installer doesn't recognize any keyboard input. Anyone ever seen anything like that? <dv>How is this for a series of guix install commands on a foreign distro?: apt update && apt install nscd -y; wget -O guix-install.sh https://guix.gnu.org/install.sh; chmod +x guix-install.sh; yes | ./guix-install.sh; guix pull; su --login --command 'guix install glibc-locales'; systemctl restart guix-daemon.service; su --login some-user --command 'guix pull'; su --login some-user --command 'guix install' <dv>(there being issued as root user) <podiki>is it possible to guix pull directly a pull request ref/branch? <csantosb>Good morning Guix ! This is just me, or forges reviews (files changes tab) becomes useless after v2 patch ? <ColdSideOfPillow>The hardest thing about contributing packages/services is actually deciding which file the definition should go to... <apteryx>it's supposed to reflect the latest revision <csantosb>And it does ... which makes the review appear at the wrong place <apteryx>gabber: the front page of https://repology.org/ says we're currently #5 in terms of package count, but that's going ot drop after the new rust way of working lands, with most rust packages moved out of the main repository <hugohugo>Hmm.. I already broke my newly setup guix system. 'guix system reconfigure' gives me "guix system: error: while setting up the child process: in phase mountIntoChroot: getting attributes of path `/gnu/store/12qr64qvjf8kc3srpmihwqjla6k9llc3-bashrc.d': No such file or directory" <hugohugo>And indeed that directory does not exist. But there is /gnu/store/58pcfx7q3d16ilni026nvkwmwhwsj4c9-bashrc.d.drv that should derive it. Can I somehow explicitly evaluate that driver to (re)create the missing package? <hugohugo>"Derivations paths can be passed to the build-derivations procedure to perform the build actions they prescribe", let's see <hugohugo>"guix gc --verify" noticed that that bashrc.d package has disappeared and removed it from the database. Not sure what caused it to disappear (it wasn't me, at least not directly). Now reconfigure works too. Thanks; couldn't have done it without you! <hugohugo>For a bit more context (in case anyone cares), before that missing bashrc.d package, I had several .drv files in the store that were 0 bytes (plenty of space). So I `guix gc --delete`d all of those. So clearly something went wrong <Deltafire>0 byte files in the store seems to be a reoccurring theme <hugohugo>Ah, thanks. I'm running btrfs. Maybe I should just not do that then <identity>“doctor, it hurts when i do this” “then stop doing that” “okay” <hugohugo>Yeah exactly. I'm not using any of the btrfs features; I thought it would be interesting to learn those, but not if it causes these problems <identity>one day we will have a reliable copy-on-write file system on linux, but this day is not today <sham1>If only zfs didn't have CDDL as its license... if only <Rutherther>identity: you usually wouldn't even need that as most of those errors would be fixed by syncing the store folders after they are built <hugohugo>I recall doing a failed "reboot --kexec" earlier. Got a black screen, rebooted manually, but don't recall how. So at least once I did not shut down nicely, maybe that corrupted the files <Rutherther>yes it probably did, but they wouldn't be corrupted if guix synced <hugohugo>So the files are first create empty, synced, then rewritten with their proper contents, not synced, unclean reboot, and then the files are in their zero-byte state? <Rutherther>hugohugo: no, they aren't created empty. The information about those files existing has been written to the disk, while the contents haven't been written yet, only kept in memory <Rutherther>s/no, they aren't created empty/no, I don't think it is because of them being empty in the first place <hugohugo>OK, my mental model of filesystems is probably wrong. I was assuming that a journalling file system would ensure that the files are either created properly, or not created at all. Hence my thought that they might have been created empty first. <hugohugo>Thanks for the correction. I should have checked that <hugohugo>Manually calling 'sync' should work as well right? I'll try to do that after every reconfigure and before every reboot. (It feels a bit like 'park' from the old days...) <Rutherther>Yes, I believe that should work, but really this should ideally be handled by Guix, not manually by users. And ideally at the time of the write so that the possibility of corruption is minimized even on power outages <apteryx>how do I merge two issues in codeberg? <apteryx>no merge of issues in codeberg. It's pretty spartan! <untrusem>btw, this would need to be a forgejo feature for codeberg to have it <apteryx>I'll just something like 'Closing in favor of #1836.' for now, closing the duplicates. <untrusem>btw what is your keyring setup in guix folks, I am trying to setup up <Rutherther>apteryx: I am a bit confused, are you trying to implement that issue exactly, or fhs-compatible builds, based on the name of the branch? <apteryx>it's both, but the fhs stuff is blocked by the later messy wip, which touches the whole compilers collection <untrusem>mostly for applications like fractal and gajim <apteryx>it's unlocked by default as of recently <apteryx>Rutherther: and the messy wip is motivated by my inability to build gcc-for-fhs when I swap binutils with binutils-for-fhs (include ordering hell errors break loose then) <apteryx>so I thought attempting to make this a bit more robust first would help. <dariqq>apteryx: i had a similar error before. The problem is "checking how to run the C preprocessor... /lib/cpp" . It should be gcc -E . In my case configure skipped that because it could not find the linux headers i.e when C_INCLUDE_PATH is unset (youd find more info the log file) <apteryx>I think in the config.log it failed to find stdio.h, which doesn't make immediate sense as the glibc headers are in C_INCLUDE_PATH <apteryx>but don't currently integrate it with applications <untrusem>ohh I have gnome-keyring-service-type in my system, I don't thinks Its working, when I open an gnome application it gives the keyring error, I am not using gnome de though, I also have keepass :) <apteryx>if you don't use GNOME you need to add the PAM setup yourself, I think it's briefly covered in the manual. <apteryx>hm, maybe it's just adding the service as you dd. I don't see other documentation. <apteryx>Yeah, that's what I remembered: "Note that there is no need to use this service when using ‘gnome-desktop-service-type’, which includes it.", so if you include it it should work? <untrusem>I don't wanna include whole gnome de for this 😂 <apteryx>ah, but the default value is gdm-password <apteryx>you'd have to configure pam-services for your different desktop manager if so <apteryx>so maybe it needs 'greetd-password' instead of 'gdm-password' configured the pam-services, but I haven't checked for the exact, correct naming there. <dariqq>apteryx: Btw a similar issue with gcc messing with other headers exist when trying to build gdc-14 (#1460). Since gcc-12 one needs a gdc to build gdc but trying to add gdc-11 as input to gdc-14 downgrades c++ headers to libstd-11 <apteryx>dariqq: I'm a bit struggling to find the corresponding error in config.log; this one is about the C preprocessor, but it looks like the nonexisting header test is intended: https://paste.debian.net/1390558/ <apteryx>dariqq: I think if we manage to make the --with-specs idea that is supposed to fix using the libstdc++ from GCC instead of passing it around from a libstdc++-headers package in CPLUS_INCLUDE_PATH that'd probably help. <Rutherther>apteryx: so what's the error with confdefs.h in the log? <apteryx>there are lots of them, and some are false positive I think. Hard to know which one is fatal. <apteryx>I have a config.h but no confdefs.h, in the build/ output (it's an #:out-of-source? #t build). <Rutherther>yes, I am asking about config.log, specifically when it evaluates confdefs.h as that is the failing one <apteryx>let me paste the whole thing somewhere <dariqq>apteryx: the first gcc -E seems to succeed. trying to find where AC_PROG_CPP is defined again to see what it is supposed to do <apteryx>ACTION signs off, but I'll check any messages tomorrow, and keep going at it ^^ <dariqq>the posted config.log seems different than the one that generated the lib/cpp preprocessor. In the github gist it determines that gcc -E works (it continues with "checking for grep that handles long lines and -e" <dariqq>sneek later tell apteryx: The failing config.log is gcc-14.3.0/32/build/config.log with error "glibc-2.41/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory" <mra>howdy! trying to build guix locally, and running into an error with ./configure: "error: module (git) does not export graph-descendant?". i'm using version 0.9.0 of guile-git, since that's the latest version on nixpkgs stable. do i need to be using a newer version? the docs say that version 0.5.0 or later should suffice <untrusem>not fully related to your error, but mra, nix have a guix service i believe <mra>untrusem: i've tried it and not had much luck, i'm afraid. hoping to just switch to guix system eventually lol <untrusem>I think, guix provide a install script for foreign distro <mra>they do, yeah, i just don't want to bother at the moment. i'm trying to build it locally because i'm working on some changes to push. i'm not trying to build it to install <hugohugo>I was browsing around out of curiosity and found this commit from two months ago: "guix/git.scm (commit-relation, commit-descendant?): Remove code for <mra>ah, the docs need to be updated then. i'll make a pr <untrusem>hugohugo, what did you exactly search for in the issues? `Guile-git' ? <hugohugo>No I did an 'rg graph-descendant' (because it sounded interesting) and then did a git blame on guix/git.scm <hugohugo>Hmm, but could be that I misinterpret the commit, because the ";remove when Guile-Git 0.10.0 is widespread" comment is still there at that moment, but in the current version it is not. <hugohugo>Apparently "widespread" does not include nixpkgs stable :) <hugohugo>Why I was interested is that I would love to be able to create a graph with all (my) packages that depend on a certain package in my store or profile. Sort of a 'graph of descendats' if you wish, so the "graph-descendant" name triggered me. <hugohugo>for example, with this earlier discussion of empty files, I now have only 2 empty packages in my store: /gnu/store/10vvmw4rs15w4nw32yd0555fblakzj6j-empty and /gnu/store/vngpzzx5ak932v3dzrc3vw1rqy16lg5q-client.conf . Now I'm curious why they are there; and I wonder what other packages depends on those, recursively. <valorzard>hey is there a way to make the build output from guix build -f guix.scm spit out somewhere else? <hugohugo>But that function is probably totally unrelated since it is about git descendants, not guix package dependants, but still <valorzard>I'm using CMake and ExternalProject to build a Guix package, but it keeps sending the binary to /gnu/store, which is not what i want <valorzard>I'm trying to link the binary to my c executable using cmake, but i'm running into weird issues (probably because guix doesn't expect to be used like this) <Rutherther>valorzard: no, that's how guix works, it builds stuff to the immutable gnu store <mra>there we go, made a pr to update the docs <valorzard>Rutherther is there a way to break that somehow? <Rutherther>valorzard: no, that is the point of guix that all outputs go to the store and refer to other outputs in the store, like to libraries <valorzard>okay, so if i want to build guile from source as a library i can distribute, i will not be able to use guix <Rutherther>valorzard: the best kind of distribution is where you can ensure the software works - properly distribute all the deps rather than relying on what the users have available and that is exactly what guix gives you, and what you're trying to give up with the way you're trying to build the software <luca>the alternative is static building (to some extend). But I don't think guix really does that <tux0r>I.M.O. that would be a good feature. static linking exists for a reason. <valorzard>slowly going insane from trying to get this to work haha <untrusem>btw guix also shoud have a wiki like arch where all users can add stuff, arch linux wiki is very helpful even if you don't use arch <tux0r>most FAQ about guix are answered rather thoroughly in its manual <identity>untrusem: yeah but then when you stray from the path of “absolutely everybody uses this on arch” there is a high chance of outdated, or otherwise directly conflicting with upstream documentation, information <luca>guix is already pretty far from upstream, where everything is done in guile instead of config files <hugohugo>The manual is really quite good. I sometimes just ask a question on stackoverflow, not because I expect an answer, but if I can answer it myself, then the answer is at least somewhere I would have been able to find it. And most of the time the answer is a compilation of information from the manual <mra>yeah, the manual is excellent. it's one of the best parts of guix imo <mra>i genuinely think that the manual is one of guix's main advantages over nix <cluelessguixer>How can I figure out what the default rules are for (iptables-service-type)? I have a suspicion it's blocking spice graphical console for my VM. Doesn't look like the iptables command is made available with the service enabled. <Deltafire>hugohugo: the guix gc command can be used to find dependants <ieure>cluelessguixer, Services can reference packages for things they need, but it doesn't put those packages in your profile.