IRC channel logs
2026-03-04.log
back to list of logs
<scv>hey, does anyone know how i can see the source code of a service i found in "herd status"? <apteryx>the guix daemon normalizes file permissions, right? <apteryx>as in, you can't have a directory with a 'writable' permission there, right? <apteryx>scv: you'll need a guix checkout to follow the location, but you can try: guix system search jami | recsel -p location <apteryx>changing jami for whatever service you are interested in <apteryx>robin: one PR from my point of view, two commits since nothing is more broken than currently is after each commit gets applied. <apteryx>being in a same PR makes it easier to follow the "story" of what you're trying to achieve/fix. <scv>apteryx: interesting, thanks! <jakef>'guix build -P1' doesn't pick up packages that package/inherit it? <acidbong>apteryx: you mean permissions in the store? if so, it's readonly <acidbong>(i wonder if it's also bind-mounted as readonly, like Nix store) <apteryx>acidbong: yeah, the file permissions (metadata) are sanitized to 0555 or 0444 by the daemon itself post-installation <coopi>i tried adding `(service file-database-service-type (file-database-configuration (package plocate)))` to my `services' field but it fails with `error: plocate: invalid field specifier` <pinoaffe>I vaguely recall an email/writeup about someone setting up their graphical session such that exwm is launched as a user-shepherd-service - anyone know where to find that? <pinoaffe>I'm interested because currently, GDM appears to launch the exwm (and thus the emacs) that is in the system profile, whereas all my emacs libraries are in my user profile - if there's a version mismatch, this causes a crash (at least, that's my current preliminary diagnosis <Rutherther>coopi: you need to return a list of services in the services field. Ie use append, cons* and so on to merge multiple services together. Presumably you have put this value as standalone value rather than inside the list you have already. <Rutherther>coopi: but this it all just guess work as you did not provide the config. Which is quite crucial for syntax errors <untrusem>I am proposing adding a `guix' tag in lobsters, I wrote it by heart. It might contain some mistake.. <coopi>Rutherther: Apologies, I intended to provide it but forgot midway 😅. Anyways, here is my configuration: https://bpa.st/Y53A <coopi>Curiously, if I remove the file-database configuration (i.e. use GNU Findutils) the error disappears and I am able to build my system. <folaht>I'm trying to do a guix home reconfigure, but it fails on some kind of package that it wants to construct. <folaht>Why does guix even want to construct a package that I'm not using? <mange>Which package is it failing on? <folaht>chromium, and I just realized that that's in the home-configuration manifest. <mange>I think ungoogled-chromium is failing to build at the moment, from memory. Let's see what CI says. <Rutherther>coopi: I think you are missing (gnu services admin) module <Rutherther>coopi: Not really sure why it works without the confoguration though <coopi>huh, i'd simply assumed the existence of the module based on the fact that it was working without the service configuration... <mange>So, I've been added to teams.scm, but that doesn't seem to have changed anything with my Codeberg account. Is that just because nobody has run the sync script yet? Or do I need to do something else to make that work? <lilyp>I think you should notice a difference once an MR targeting said teams is made (with you now being a member of those teams), though it's quite possible that syncs take time <mange>Yeah, I'm asking because I saw a PR for the team, but I wasn't notified about it. Non-committers are still notified about team stuff, right? I can't commit to the repo. <Rutherther>mange: yes. But a script has to run as you said. If that is done manually or periodically automatically I am not sure <lilyp>mange: fair enough, just wanted you to know there's no really other way of knowing your association in the Codeberg interface (at least that I know of) <andreas-e>I think that team members only get notified when something like "@guix/xxx" appears in the text; it does not seem to happen when something is labelled as "team-xxx". Is there even a connection between the labels and the teams? <Rutherther>mange: no, thats not it. It is because you are not in a team yet. You will see it <Rutherther>All members see their Teams. It doesnt matter if you are committer or not <mange>Okay, fair enough. I'll just wait longer, then. <Rutherther>If it takes too long try hitting an email to guix-sysadmin. I wouldnt expect it should také longer than a day or two. <andreas-e>Rutherther: I see, then team members should indeed be notified via the script that creates review requests by teams. <Rutherther>andreas-e: yes. Unfortunately that is only for PRs and I am not sure what a good way for issues would be. If the bot should send tags or something like that <jakef>did we end up making substitute* error if there wasn't a match? <futurile>jakef: no, it always returns #t even if there's no match <sunless>how soon is there going to be an "emacs-ewm" package, i think that project looks relatively stable and i'm interested in purely living in emacs on wayland <futurile>sunless: I don't know what that is, but you could try searching codeberg/guix to see if there's a PR for it <futurile>sunless: if there's not you could have a go at packaging it <sunless>futurile: it's an emacs window manager like niri, gnome, kde ... <sunless>idk how to package ... yet, but that sound something i'll take schedule to learn :) <sunless>futurile: the link isn't working ... just hoping someone is thinking about it <sunless>csantosb: exactly, i'm hyped the project is now relatively stable, i just don't know how to install it in guix <futurile>there are 500 PRs to be merged; each one takes me 30-45 mins to do; sigh <sunless>good luck there, i'll just patiently wait :) <futurile>we just have too many packages for the number of committers we have <futurile>we have more packages than Debian on 1/10th the number of committers <futurile>and I reckon the vast majority aren't used - ArchLinux or Ubuntu core are so much smaller <gabber>and probably streamline pushing to master a tad, i guess the bottleneck lies there <futurile>have a user repo like AUR and be done with it <futurile>it's not the push that is problematic - I have to review each package; check the hash is correct and do 30 other checks according to the manual - that just simply takes time <gabber>yes, that's what makes pushing so work intensive <gabber>it's not running "git push" alone, but having to check (usually already checked) PRs commit-by-commit <cbaines>I see the problem as the lack of tooling and automation, rather than the lack of people <futurile>well neither is changing in the short-term <futurile>and it's a big reason we lose people - it's just a sisphyean task <futurile>and some of the ecosystems are getting worse - I've been working in Rust/Cargo for 4 days and honestly I could kick a small furry animal at this point heh <futurile>meanwhile we're shipping a Perl that isn't even maintained <sunless>damn, i guess i should have plans of learning and becoming some kind of "maintainer" rather than just being a regular user :) <gabber>sunless: it's not *that* hard to become committer, but takes at least 6 months time (: <theesm>futurile: the rust ecosystem is pretty awful dependency-wise though... regarding perl iirc someone was working on upgrading it <theesm>wanted to find open perl PR/Issues either way to label them properly now that we have a perl-team with me being the sole member of it rn <gabber>futurile, cbaines: we should definitively start designing solutions that enable our (continuous) growth. especially now that we lowered the bar for new contributers (codeberg). we can't go on putting our valuable expertise into sisyphean tasks. this is not healthy for us as individuals and will prevent the project from blossoming in the colors, shapes and sizes it should <futurile>theesm: it's stuck with some of the things that were being worked on for core-packages; yeah I don't want to join a perl-team but if it gets unstuck I will work on updating the perl libs as we're falling behind <gabber>unfortunately i don't have the slightest idea how to solve this problem <cbaines>gabber, this is something I've been trying to work on for a while... <gabber>i'm all ears/eyes (on whatever channel you prefer to share your thoughts with me) <sunless>gabber: let's see, i'm also learning programming in general (i've made the poor life choice of focusing on rust as the first language), so lemme add another 2 months there ... prepare for more technical questions and contributions from November :) <theesm>futurile: sounds good, i wanted to start with updating most of raku/perl6 though as that seems to be less of an impossible task than keeping other perl things fresh atm <futurile>do less, better imho. Nix/ homebrew/ arch / ubuntu - all split the repos and apply different quality levels / control to them <futurile>that way we can focus on the packages that matter for the vast majority of use-cases; without 'blocking' users from having packaes they care about <gabber>sunless: learing Scheme is (IMHO) the more rewarding, insightful and sustainable way to learn computer-taming (: also it's kinda easy and fun <futurile>theesm: yup; I was trying to figure out the perl libs we absolutely depend on within the dependency graph. <futurile>theesm: becaues the risk is when the jumps are very big we land-up struggling to move the graph forward <theesm>ACTION should probably consider applying for commit access at some point as well <theesm>futurile: i am somewhat in the picture of what perl packages i would consider critical, maybe i should create a codeberg issue to track them or sth <futurile>theesm: you should definitely apply for commit access - I'm sure I emailed you about it! <gabber>theesm: you DON'T have commit acces? <futurile>theesm: yeah it would be good to have a tracker/project - until we can update Perl we're kinda blocked <gabber>theesm: please do, we need you! i'll gladly vouch for you! <sunless>gabber: i'm already trying wrapping my head around lifetimes and preparing to move to web dev with leptos (i hear web dev is still the meta, so i want to secure my career first), the Sunk Cost Fallacy is real, i'm scared of splitting my focus ... but lemme see if i can squeeze it in my free time <gabber>sunless: you do you. IMO web development is (too often) a rabit race, where you are always chasing technology that is *teh shit* but also always out of date.... but i'm not really in a position to give career advice <identity>Scheme is a good first language because there are only so much constructs you need to learn, so you are less ‹learning Scheme› and more ‹learning programming› <gabber>identity: arguably: brainfuck does not fit the bill at all <theesm>futurile: yes, i remember! iirc it was last year, right? (had a large period of inactivity for most of 2025 as many things got in the way so i wasn't able to follow up on it) <futurile>theesm: ack, I remember you saying - well if you've changed your mind ... <sunless>gabber: i don't mind, i'm open for insight from people obviously have better experience in the tech space in general <gabber>i am currently packaging EDA software into Guix as a part time gig and refactoring a huge PHP codebase :( so i guess learning web dev certainly can help you earn some money at one point or another <sunless>identity: lesser constructs, interesting, that's sound like a good motivation to finally checkout it out, thanks :) <mange>I wouldn't recommend learning web dev via Rust. <futurile>securing your career always makes sense. As an aside generally packaging doesn't require as much programming experience as people think. You spend more time wrangling build systems than writing functions. <mange>The web platform is already plenty complicated, and a lot of the hard stuff is on the client side. Using Rust is just making the server side of it hard for no reason, IMO. <efraim>agreed. most of my programming comes from my intro programming classes and patching packages, mostly while packaging <sunless>gabber: yes, as long as i can make some cash, i'll now start caring about interests and focusing on foss <theesm>re php: i've been working with php (mostly, perl and c being the other constants) for most of my career, it's pretty boring, consistent (i see both as a good thing) and pays okayish <identity>sunless: ‹Structure and Interpretation of Computer Programs› is a classic Scheme book (you should find lecture recordings from the course online), but there are other good ones like The Little Schemer series; ask around in #scheme and #guile if you are interested <gabber>+1 for SICP. it's free, available online and there are even some really cool, very vintage videos where you see the two authors write scheme on blackboards and overhead projectors. i would not have missed that (: <sunless>mange: the propaganda about rust being fast and secure was too sweet, and i knew a little bit of springboot to see how complex it is compared to axum ... so with little oversight and interest for the "best", i've made that questionable decision <sunless>mange: oh well, lemme prepare for the worst then <futurile>One of the things that really helps to know when learning is what sort of learner you are. Then follow that style - I've spent many years not really understanding that and trying to learn in a style that didn't suit me <mange>If you're looking at webdev I'd really suggest Django, Rails, or Laravel as the places to start. <sunless>identity: i've seen the books, it's kinda concerning about how old it, i'll use them as my rails for learning scheme, thanks for the recommendation :) <sunless>theesm: nice, this will speed things up and i won't have to commit more crimes to get the books <futurile>stuff like Rust is just masochism for a new programmer. Django, Rails, or like theesm says PHP are things where you'll get more done than working on learning Rust - if the goal is learning WebDev. But it's the "PR" and this sort of perverse "I want it to be _hard_" in tech. <theesm>sunless: imho SICP focusses more on concepts than specific implementations, which is what makes them so good and timeless and have them stand out as most programming books tend to rather focus on specific implementations <sunless>futurile: i think i got a good understanding of how i'm able to learn, i don't want to go back to that philosophical rabbit hole about optimizing learning about learning or something like that <sunless>mange: i've already gotten some basics to try a todo list, and the dangling carrot of leptos offering cross-platform applications where i can also make android apps and desktop apps ... naaa <sunless>theesm: nice, can't wait to check it out, i'll share my experience :) <futurile>sunless: great, then you'll know what works for you =-) <andreas-e>theesm: I have meant to contact you, definitely you should apply for becoming a committer, I would be happy to sponsor you. <theesm>andreas-e: thanks! think i'll reach out at the end of this week <PotentialUser-69>It has been long since I last had to use TeX/LaTeX/TeTeX. I am facing the following error when I run pdflatex: "I can't find the format file `pdflatex.fmt'!" <PotentialUser-69>I think this used to work on an old computer that no longer works and used Arch Linux. <PotentialUser-69>It is possible that the missing file is available on one of the packages for TeTeX that Guix offers. How could I check that without having to install the really large one? <ieure>PotentialUser-69, Guix does not have a good solution for searching package contents like that, unfortunately. <ieure>PotentialUser-69, Ask someone here who already has the package installed if it has a file. <janneke>PotentialUser-69: pdflatex.fmt is in texlive-latex-bin <PotentialUser-69>I installed only `texlive-scheme-basic`, thinking it would be sufficient. I'll try and add that package also. Thank you, janneke <janneke>PotentialUser-69: be sure to add both to the same profile/shell invocation <identity>PotentialUser-69: there is guix locate, but it only looks for stuff in the store <janneke>PotentialUser-69: that's in texlive-wrapfig <identity>PotentialUser-69: there is (info "(guix) Invoking guix locate") <PotentialUser-69>janneke Many thanks. It seems that yet another file is needed (`wrapfig.sty`). And, I suspect, another file after that one. <PotentialUser-69>Would I get these files if I replaced my `texlive-scheme` package with a larger one? <PotentialUser-69>You have been very helpful, but don't want to abuse your kindness (and your time). <identity>as in, using a larger scheme (or however you say that) should work <identity>PotentialUser-69: i use the Emacs interface and the online one i remember is isearch-forward on Ctrl-s <identity>i guess there is i for searching through the index <PotentialUser-69>Helpful keys are for following links, moving between links, going back on history... <PotentialUser-69>I can look them up, but after a few days without using them, they vanish from memory. <identity>follow cross-links in info manuals? i just press RET or <mouse-2> <folaht>I have an issue with a package that includes a symbolically linked command and an application that wants to run it. The latter can't find the former. <ieure>folaht, Terminals have no problem resolving symlinks. <ieure>folaht, You likely need to log out/back in; or source your profile to refresh $PATH. <ieure>folaht, I seem to recall that you're mixing an imperative user profile and Guix Home? <folaht>ieure, I'm not even sure what that means. But I'm playing around with ~/src/guix-config/home-configuration.scm <ieure>In your forum message, you write: "cc is created by symbolic link in /usr/bin/ ..." -- this is not correct. <folaht>lrwxrwxrwx 1 root root 59 fév 25 11:58 cc -> /gnu/store/1i11d1h8rc45iv4h7s6n8zgmz8l6v7yn-profile/bin/gcc <ieure>How exactly did you install it? <folaht>I just did guix package -i gcc-toolchain <folaht>I might have created the symbolic link manually a week ago. <folaht>cc shouldn't be present in /usr/bin? <ieure>Guix doesn't work like that at all, it doesn't follow the FHS. <folaht>Okay. That must have been something I created manually then. <folaht>The question then remains, how does guix recognize the 'cc' command? <podiki>civodul: did you (or anyone else) do a glibc ungraft anywhere? i don't see it on core-packages-team, wondering if i should take it on mesa-updates that i want to get building finally <untrusem>you can do CC=gcc, that's what I usually do when manually testing building a package <ieure>folaht, Nearly everything on a Guix machine is in /gnu/store. Package operations create new profile generations. A profile generation has a thin directory structure full of symlinks into the contents of /gnu/store. Activating the profile sets $PATH to point into the generation's directory structure. <ieure>folaht, Do you have any programming experience? This works like heap allocation, if that's something you understand. <folaht>I have some programming experience yes. Not with lisp though <untrusem>/usr/bin just have an @env file which is a symbolic link to `env` in /gnu/store <ieure>Right; and that's created by the system generation, installing packages as users cannot affect /usr/bin or any system stuff. <untrusem>go can do get a fhs like environment using guix shell's `--container` flag <ieure>Yes, though not sure that's helpful here. <ieure>folaht, If you have, say, a C struct with a bunch of pointer fields in it, you might populate them by malloc'ing space on the heap, then sticking a pointer to that in the struct. The store works the same way; /gnu/store is the heap, a profile is akin to a struct with pointers into that. <ieure> /gnu/store has every package anyone has ever asked for, but what's in a particular profile generation is based on its local needs; it points to some subset of the store. <identity>the store is more like a garbage-collected heap, with user profiles being the garbage collection roots <ieure>Correct, didn't want to get into the GC stuff though. <identity>yeah, now that i think of it, how many users of languages that do garbage collection actually know how GC works under the hood? <ieure>folaht, Anyhow; `guix package --list-generations' will print all the generations of your user profile. Run that, run `guix package -i some-package', then run it again. <ieure>folaht, There should be a "file name" field in each generation, compare `ls $SOME_GENERATION/usr/bin' to `ls $SOME_OTHER_GENERATION/usr/bin'. <ieure>folaht, Your shell's $PATH needs to point into whatever the current generation is in order to see any of the packages in it. <folaht>ieure, shall I just post my current $PATH? I'm not sure what you mean by "file name" filed in each generation <ieure>folaht, No, the value of your $PATH is not helpful to anyone here. <ieure>folaht, Did you run the command I gave you? Its output should contain the text "file name:" <folaht>You mean 'guix package --list-generations'? <folaht>Well it outputs a list of generations <folaht>I'm at generation 122 right now. <ieure>Okay, I am incorrect about how that works because I don't manage packages that way. <ieure>folaht, Look in /var/guix/profiles/per-user/$USER <folaht>Do you mean to tell me that I should look up the folder path gcc-toolchain? I do that through 'guix package -I gcc-toolchain' <ieure>folaht, No, I'm just trying to help you understand how things work. <folaht>Ahhh... okay, well then I'm looking. I see a lot of profile folders. <folaht>And root has 2 of them due to installing with sudo by mistake. <ieure>folaht, Yep. So when you run `guix package -i' etc, this is the thing it's actually doing. Creating a profile generation, linking it to your per-user profile directory, etc. <folaht>So for my issue, the solution is to just run the command I want to run with 'CC=gcc' in front of it? <ieure>That should solve your issue. <identity>if the stuff you are trying to do hard codes ‹cc›, then you would need to do something like ‹sed --in-place 's/cc/gcc/' hard-coded.txt› <folaht>identity, thanks. I'm trying to install a cargo package however. I'd never hard code <cc> in my code. <podiki>sneek: later ask civodul did you (or anyone else) do a glibc ungraft anywhere? i don't see it on core-packages-team, wondering if i should take it on mesa-updates that i want to get building finally <untrusem>sneek: later tell nemis: jj 0.39 is released :) <untrusem>sneek: later tell nemin: jj 0.39 is released :) <yelninei>sneek later tell bjc guix pull/ guile-git currently segfaults when the progress bar callback gets gced by the guile gc. on 64bit Hurd the crash server (crash-dump-core) currently hangs <janneke>yelninei: o, the hurd-team branch's vm image boots! <janneke>will report it on codeberg once that's up <yelninei>i guess some patches where not as independant as I thought and i missed an important one <yelninei>janneke: Really enjoyed the blog post. i think the package statistics are a bit conservative, a lot more things built and work but no one is trying it. <simendsjo>Codeberg looks completely down to me. Is it a problem on my end? <janneke>yelninei: thanks; well, i ran guix weather, honestly! <simendsjo>janneke: Ouch. Probably AI scrapers as always :( <yelninei>janneke: also i am deep in python hell right now but i almost have mesa and the xorg-server building <janneke>hopefully after the bootstrap-binary update, and *cough* childhurd reconfigure, numbers start getting up again? <janneke>yelninei: ooh, that's pretty good -- not the "hell" bit ;) <simendsjo>"..performance degregation due to heavy traffic.." <- what a nice way to put it. <umanwizard>codeberg is down, anyone know a mirror that's currently working? <yelninei>janneke: i think ci.g.g.o is only building the manifest which is guix + dependencies + a few extra things, but not the world beyond <janneke>yelninei: ah, yes of course -- thill the percentages should be a bit higher? <yelninei>what is 100%, the manifest or all of guix? <janneke>before it made little sense to build a larger manifest, wasting cpu on failing builds... <janneke>...but if xorg builds, that would be something! <yelninei>mesa currently has the clang/llvm problem with ED errno but maybe we can skip clang in mesa for now. The hell are test failures in the million python dependencies <yelninei>my favourite one from last week was expecting an exact python error string with ENOENT == 2 <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, podiki says: did you (or anyone else) do a glibc ungraft anywhere? i don't see it on core-packages-team, wondering if i should take it on mesa-updates that i want to get building finally <civodul>podiki: i was planning to take it on core-packages-team, but that branch is far from ready <yelninei>civodul: I built my branch with a local gash tarball successfully, i think from my side everything is good to go <yelninei>but i am still not sure about the workarounds to build coreutils-mesboot (but that is not a problem with gash/configure) <rkazak>Hi all, is the guix repo at codeberg unreachable? <mange>Yeah, looks like Codeberg's HTTP stuff is down, but SSH still seems to be working? <rkazak>ok, thanks for that. Does "guix pull" have a fallback setup with SSH access? <umanwizard>(it was pretty slow to fetch the repo, but in the end it did work) <podiki>civodul: i saw there's at least some other glibc stuff on core-packages too, not sure for those commits, but could just have all glibc stuff on mesa-updates if that is helpful (since want that ungraft asap) <civodul>yelninei: alright, i will (finally) tag; and we can have another release if needed <podiki>sadly i just missed seeing what agit branch i wanted to fetch before it went down :( <civodul>podiki: let’s keep glibc changes for core-packages-team, that’s one of the main things we want to test on the branch <graywolf>Is there some mirror for codeberg I could use to follow up on patches and bugs? Working through the mail inbox, and since people mostly post links to codeberg these days, I am curious whether we have some backup/mirror <podiki>civodul: including the ungraft (adding the new patch to the glibc patches variable)? <futurile>graywolf: nope, this is the trade-off there's no way to do PRs in a distributed fashion, if you're forge is down ... <umanwizard>hmmm, why am I having to rebuild huge numbers of go/python packages after `guix pull`, did something fundamental merge recently? <jlicht>hey guix! could it be that grafts are corrupting our rustc's sysroot's Cargo.lock files? <jlicht>the better question: what /should/ the approach be when grafts break things via unpatched checksums? <podiki>(codeberg is down due to ddos they say) <podiki>(and seems to be coming back up) <dajole>It looks like the documentation is outdated and the link for the signatures to verify the iso is stale. How and where do I find the up-to-date ones? <folaht>How do I deal with scripts that call #!/usr/bin/python when /usr/bin is empty except for env? <mange>Is this on your system generally, or in a build? Usually changing the shebang to #!/usr/bin/env python or whatever should work. <folaht>It's in several script files that I have gathered from my previous OS. <folaht>But the issue is also that it can't find python in general, because there's only python3 <folaht>At least from the package I installed. <mange>You can rewrite the shebang to be #!/usr/bin/env python3 then.