IRC channel logs
2025-09-26.log
back to list of logs
<vagrantc>oh, there is also qimgv (which depends on opencv) <attila_lendvai>does anyone have an example of rootless-podman-service-type? i don't understand what subid-range is, or where it's coming from. <FuncProgLinux>ColdSideOfPillow: The async/await superpower. I get ya there 😅 <Gooberpatrol66>hey i'm getting this error signing into guix codeberg with github <vagrantc>i got a build failure for 0971788c0bda20cf924ae069eee6113ad38cc11d gnu: guix: Update to 679c9b0. ... building guix. <ColdSideOfPillow>welp I just did a huge refactor of my directory structure and somewhere, I managed to break a rde module <drewverlee>guix time-machine ... -- system container ... produces a container at /gnu/store/<id> is there some way to pass the guix command that name so it's easy to know after the fact or do i have to grab it at creation? <drewverlee>something like `guix container --name=joe` and it would produce ... idk /gnu/store/joe. <drewverlee>I have nearly the same problem when i run the container aka /gnu/store/<id> it outputs a message that contains the PID so i can enter the container, but what if i want to send that PID to another process so it can use it? I have to somehow extract the PID from the output message, and thats turning out to be way harder then it seems like it should be :(. <drewverlee>thanks again, yeah, I guess we might have to modify guix. As the other things im trying are starting to seem harder then that lol. <mange>As for the script: you can copy it out of the store if you want. Or make a symlink to it. I believe a successful "guix system container" prints only the script's path to stdout (and everything else to stderr), so you can do "cp $(guix system container) my/path/joe". <drewverlee>we created a symlink, that seems to work ok, the more unclear part is getting that PID. /gnu/store/id > output 2>&1 will produce the container PID in the output file, but it only does it after i kill the container... <drewverlee>there is probably some simple bash that makes this work, but i can't seem to figure it out. <mange>If you want a *really* hacky solution I can write you a sed script that you can use on the container script to modify it to write out a pidfile. :P <mange>At least until a change like that is made to Guix itself. <mange>Here you go: sed 's/(explain pid)/(explain pid) (call-with-output-file "container.pid" (lambda (port) (write pid port)))/' /gnu/store/...-run-container > run-container.sh <mange>Oh, except it's not a shell script, so it shouldn't be .sh as an extension. <mange>That will write the PID to a file called container.pid in $PWD, but obviously you can change the argument to call-with-output-file to write it wherever you want. <apteryx>bordeaux substitutes are slow again? <apteryx>is creating an NTFS file system always so slow with the ntfs-3g helper? <csantosb>(unrelated) Just discovered about ‘#+’, instead of ‘#$’ <csantosb>Which one do we privilege ? All packages are supposed to cross compile, I guess <csantosb>Hope so, I realised its existence right now ! <csantosb>I'm looking at vulkan.scm, where this is used, I ignore why <identity>i presume you use ungexp-native for the same cases you would use native-inputs <identity>though, how frequently do you want objects to be ungexp'd instead of putting them into inputs? <Rutherther>those are not mutually exclusive, you can ungexp inputs - this-package-inputs / this-package-native-inputs. With this-package-native-inputs you have to use #+. <hugohugo>There is often a sole '#t' at the end of lambda's that modify a phase. Should we (generally speaking) remove those when updating a package? Or do they serve a purpose? <cbaines>apteryx, are you seeing the slow connection message or slow downloads? <apteryx>no, it was just fetching substitutes info, and taking a long time for it <cbaines>unfortunately the nar-herder on bayfront seems to have some slow memory leak or issue, which I guess could be harming performance <cbaines>I'm unsure, I haven't got round to investigating yet <csantosb>hugohugo: This is old style, you may safely remove it <csantosb>Rutherther: We have lots of `#$(this-package-native-input "package")` <Rutherther>then those are wrong. Either they should be #+ or they should not be native inputs, but inputs <csantosb>Yes, this is what I understand when reading the doc <cbaines>luckily I managed to roll-back my laptop in to a more working state yesterday <cbaines>my fun for this morning is that the #f license of python-id is breaking the data service <cbaines>civodul, with the pulls.ci.guix.gnu.org thing setup, are you open to disabling the Forgejo integration on data.qa.guix.gnu.org? I think it's caused /var/lib/guix-data-service/.cache/guix/checkouts to grow to 54GiB, which is exasserbating the space issues on hydra-guix-130. <Rutherther>as for the disk space growth... I think that should be easily solvable by using symrefs instead of user forks. That way there will be just one repository in the checkouts <civodul>cbaines: hi! yes, definitely; i was hopeful this would be the first step of bridging qa.guix with Forgejo, but maybe that was misguided <cbaines>Rutherther, opposite regarding what? <civodul>actually the hook just needs to be removed on Codeberg, under “Settings” <civodul>sorry that this has caused troubles for nothing in return! <Rutherther>cbaines: that qa should get better forgejo support, not no support <cbaines>civodul, no worries, at least now there's maybe a clearer plan of how to approach things in the qa-frontpage, I think copying the current approach of having the qa-frontpage maintain a Git repository with all the branches it wants the data service to process provides some advantages, mainly that it provides a way for the qa-frontpage to control what gets processeed and allows the data service to remain unaware of complex things <cbaines>Rutherther, right, but as I say, that integration can sit in the qa-frontpage, rather than the data service (and I think this has some advantages) <Rutherther>definitely, I wasn't aware of that, it sounded like removing support for forgejo <cbaines>civodul, the "Remove webhook" button doesn't seem to work for me, but I think I've been able to untick the Active box <Rutherther>why does --disable-authentication disable the inferior cache? <Rutherther>I understand it would be considered unsafe to get a hit for unauthenticated inferior when you do not use it, but that should be solvable by adding the information about authentication to the inferior key, no? <sughosha>Hi Guix maintainers, I recently got commit access to Guix repository. I have my GPG key added to my Codeberg account (via Codeberg's user settings). Will merging from the web interface also sign the commits? <Rutherther>congrats. No, it can't, you've added public key to codeberg, codeberg doesn't have your private key, that's for you only. It shouldn't be shared with third parties <gabber>(how) can i aggregate multiple firmware packages to write their respective files into the same directory? the obvious attempt fails: collision between file and directories <jlicht>guix shell in the guix repo seems to run into issue with building python-u-boot-pylib (which is required by patman) <Rutherther>how does the shell run into issues? what kind of issues? <jlicht>should we consider removing all the mail-based git tooling from the manifest.scm in the guix git repo? <jlicht>Rutherther: "with building python-u-boot-pylib (which is required by patman)" <Rutherther>oh so you mean a package in manifest.scm of guix repo is not building... <jlicht>I'm not quite sure how that could've been parsed coherently in a different way, but that's indeed what I meant :-) <Rutherther>you said 'guix shell' ran into problems, not that build ran into problems, so I expected a problem in guix shell itself <fnat-xmpp>I'm experimenting with a few x11 services (e.g. unclutter) in a VM. The services fail to start with error "Authorization required, but no authorization protocol specified". I've got a MWE system definition that reproduces the error. Any idea why this might happen? <fnat-xmpp>Funny enough, I regularly use unclutter on my system with no problems, the error only shows up in the context of this minimal VM. <Rutherther>fnat-xmpp: probably don't have any polkit agent installed <fnat-xmpp>Rutherther, hm, the MWE is based on `gnome-desktop-service-type` which I assumed may include all necessary services already? <fnat-xmpp>Perhaps `gnome-desktop-service-type` is not the point, but it should be included in `%desktop-services`? <fnat-xmpp>Ok, I was able to pin it down to Gnome, as things seem to be fine if I switch to `xfce-desktop-service-type`. <fnat-xmpp>It's funny because I originally chose Gnome as I thought it was the most comprehensive, safest bet just for a quick test in a VM. <fnat-xmpp>Re the actual problem itself, I'll have a further look later, but at least this unblocks me on my primary task. <fnat-xmpp>(I.e. one layer up in the yak-shaving stack, hehe.) <dariqq>fnat-xmpp: Does the service know about XAUTHORITY. When you are in a wayland gnome session shepherd starts too early when it sets its default environment variables <gabber>i'm in a bit of a pickle. i butter-fingered and wrote a 6G image <gabber>onto the wrong disk. i tried to fsck and repair said disk but this <gabber>wouldn't work since it was being used. i unmounted (no luck) then <gabber>guessed that i had to stop the file-systems-/data service which i <gabber>expected to stop fsck. the display manager quit, i was presented <gabber>black screens with just the underscore _ blinking. <gabber>now the system doesn't reboot even when i unplug the faulty disks <Deltafire>have you tried switching it off and on again? <gabber>i unlock my drives and get past GRUB but now i just see the first lines after "Use 'gnu.repl' for an initrd REPL." ending with "init[1]: segfault at 3fff00[...]" <gabber>by doesn't reboot i mean: doesn't boot anymore <Deltafire>did you overwrite the disk with /gnu/store on it? <Deltafire>oh.. i've had a problem where boot will hang if it's unable to mount any of the disks listed in the config <gabber>my guesses go in this very direction <gabber>i see "loading '/gnu/store/<hash>-system/boot'... and "making '/gnu/store/<hash>-system' the current system.." on the next line <trev>gabber: which partition? or just the entire disk? sounds like you overwrote the EFI <Deltafire>i think.. boot from a rescue disk, recreate the damaged partition & format, then try again <gabber>it was not the disk i'm booting from <gabber>any good rescue images you could recommend? <gabber>the image fails booting: "Guix_image contains a file system with errors, check forced" and then "RUN fsck MANUALLY" <gabber>but the bournish shell does not like my `fsck' invocations? <cmack>gabber: the times I've needed to fsck my boot drive, I've edited the kernel line in the GRUB menu at boot to add the fsck parameters... sadly I have to look these up everytime <gabber>Deltafire: it was unused for quite some time <gabber>i got my system back up and running <gabber>should we consider a system rendered unbootable due to some file-system becoming unavailable a bug? <Deltafire>i think so.. at a bare minimum it should report an error message <Deltafire>i tried the (mount-may-fail? #t) option also, it doesn't seem to make a difference <Rutherther>is the file system marked as required for boot? If yes, then I don't think so. If no, then I would consider it a bug, but I would also be surprised if that was the case as those filesystems should be mounted only later, by shepherd, not by initrd. So the system should still boot <Deltafire>is required for boot on by default? I don't even have that option for "/" <Rutherther>no, it is not. root is a special one as it has the /gnu/store. Any fs that has the gnu store is implicitly needed-for-boot <gabber>thanks again to all for holding my virtual hand during this time of coming up panic <gabber>i guess i'll go home, take a bath and read a proportionate amount of "The Unix-Haters Handbook" to calm my nerves <Rutherther>anyone knows how long the nss-rapid tests go on? I think it's been running for like 3 hours :D <ieure>Rutherther, They take around 90 minutes to run on my hardware. <Rutherther>I guess I can see it's been running for 3 hours even from "Wed Feb 5 03:01:44 UTC 2025", as I suppose it starts at midnight <ieure>Rutherther, Sorry, I really prefer to merge NSS/LW stuff after substitutes have been built, but this has been difficult since the Codeberg migration. <ieure>Rutherther, I set up a job for it in CI, but it seems like it isn't picking up changes. <Rutherther>oh, I didn't even think it would be your doing. I am building on the mesa-updates branch <ieure>Rutherther, Ah, I merged a nss-rapid and LibreWolf update last night. <HystericalHatter>Hello there, I'd like some help to use Guix on top of a Debian system. I already installed Guix with apt and I managed to install some packages with Guix (niri WM for instance). But, I encounter some difficulties : my work computer goes on Internet through a corporate proxy and I don't quite understand how I can configure Guix to go through it. If <HystericalHatter>I run guix install with env vars defined on Debian's /etc/environment, it downloads some things but then hangs on substitutes downloads. It doesn't work if I pass the --no-substitutes option. I read some doc and if I understand right, I have to define the *_proxy env vars specifically for Guix, but I don't see how to do this. Can someone enlighten <ieure>Rutherther, I bought dedicated hardware for Cuirass/offloading 98% so I could build NSS/LW faster and not scorch my lap while doing so. <Rutherther>ieure: I see. Seems mesa-updates has been rebased on master since that time already <ieure>143.0 required a nss-rapid bump. <Rutherther>hmm, so I will also have to wait for the librewolf build, that also takes some time <ieure>2-3 times a year, I'll have to bump some dep because LW wants a newer version. The worst is when it wants a Rust update. <trev>can someone help a poor soul get the correct syntax for `#~(make-forkexec-constructor #~(cons* "my-command" #$args))' ? <trev>can't understand why it doesn't like that <trev>should it be (list "my-command" #$@args) ? <Rutherther>yes, that would put gexp on the build side. It doesn't make sense, you need to ungexp any gexp inside. Here the inner gexp seems unnecessary if this is the full code <trev>any example on how to send a list of args into a command then for a service? <ieure>trev, Already linked you to one. <trev>ieure: that lists out all the args though <trev>i want to send the args via my home config <Rutherther>the one you proposed with a list could be fine. With the #$args you would have to also quote it, but it's possible it will not work for some cases then, using #$@ is more general <ieure>trev, Also `grep make-forkexec-constructor' in a Guix clone (there's always one in ~/.cache/guix/checkouts/) will find you numerous examples. <Rutherther>"#~(make-forkexec-constructor (cons* "my-command" '#$args))" / "#~(make-forkexec-constructor (list "my-command" #$@args))" <old>futurile: I just subscribe to donation but did not received a mail confirmation. is this normal? <old>I need receipts for taxes deduction <DarthTRump>is cinnamon still a good desktop or will it become a systemd hell like gnome 50 <trev>is there any reason why nss-certs wouldn't be in my main profile? I thought it was now in %base-packages, which I have on my system config <Rutherther>trev: just a sanity check... you're not on 1.4.0, right? <ieure>trev, It's not in your user profile, but it's installed by the operating-system. <trev>Rutherther: i'm on a commit from a few months ago. ieure so I still need to add it to my user profile (guix-home)? <Rutherther>adding it to user profile usually serves no purpose when it's already in the system profile <trev>i did a regular guix install on my main profile and it resolved the issue i was having <trev>yeah, i didn't see it in the system profile <ieure>trev, You shouldn't need to add it to a user profile ever. Maybe on a foreign distro? <ieure>trev, It was added to %base-packages a good while ago now, last year? <Rutherther>nss-certs has been added to %base-packages in April 2024, I presume by 'few months' you didn't mean that far back. So if your system has %base-packages, I would expect nss-certs there <trev>just weird cause i have (packages (cons* git zsh %base-packages)) <ieure>trev, What issue are you having that makes you think you need it? You shouldn't ever need to care about it, maybe there's a buggy package? <trev>i get that good ol' issue where i can't curl https urls cause it's missing guix-profile/etc/ssl <trev>it's this one: Problem with the SSL CA cert (path access rights?) <trev>i resolved it with the guix install nss-certs, but it's bugging me that i had to manually install <trev>0aef9716b - my guix commit <Rutherther>trev: so there is no such thing as 'guix-profile/etc/ssl' in the error message that you mentioned earlier? <Rutherther>okay then don't worry about what I said. I thought it's in the error message. If not, I don't have a clue what the issue is. <trev>no worries. i'll keep looking. it's one of those things where it will drive me crazy for days <Rutherther>my hunch was that you installed curl in the user profile, somehow got ~/.guix-profile/etc/ssl and SSL_* vars would point to that instead of /run/current-system. And because of that the /run/current-system/etc/ssl wouldn't be picked up <trev>Rutherther: that may be close, cause i do have ssl/ in the run dir <trev>git and curl on my guix home <trev>oh man, i got it. for a foreign distro, I had SSL_CERT_DIR set to .guix-profile <Rutherther>maybe could guard that with [[ -z $SSL_CERT_DIR ]]. Or with "[[ -d ~/.guix-profile/etc/ssl ]]" <lactose>out of curiosity, is there a timeframe or prerequisite for a new iso 9660 image to be released? i noticed the 1.4.0 image was released over 2 and a half years ago... <trev>soon, i think. November i read somewhere <identity>there should be a recent development image published <ieure>lactose, The manual has instructions for making a newer installation image, it's very easy. <ieure>lactose, I spun a lightly customized one for myself recently. <aidans>Hi, I was wondering does anyone know if its possible to enable a CGO Go binary? (With substitutions for it ideally) <FuncProgLinux>Do g-expressions change how phases work? :/ I'm trying to update the Atril package on gnu/packages/mate.scm but it's giving me ERROR: In procedure stat: No such file or directory: "configure" but I didn't change the steps order at all :o <ieure>FuncProgLinux, Might be that you need autotools to generate the configure script for you? configure typically gets generated for a release tarball, but not for a Git repo -- so if you switched how you're getting the source, that could explain why it's broken now. <FuncProgLinux>ieure: I stuck to the original source for now. I'm using the original package definition. I'll propose the GitHub migration once I get the missing packages :) <ieure>FuncProgLinux, Have you built with -K and inspected the build directory? <identity>FuncProgLinux: from the store? just find the tarball/checkout and do “guix gc -D $source” <FuncProgLinux>Nope, I think it's something in my build ._. now I'm sure: Starting download of /gnu/store/can0bmxym1d9byp34k3058a5cdv3wzi4-atril-1.28.1.tar.xz <ieure>FuncProgLinux, -K doesn't change anything about how the build builds, it leaves the source in /tmp so you can inspect its state. <FuncProgLinux>It creates an empty file at /tmp/guix-build-atril-1.28.1.drv-0/configure.x7lQpw <ieure>FuncProgLinux, the source should be in a directory under /tmp/guix-build-atril-1.28.1.drv-0 <FuncProgLinux>ieure: There's no source :( only the empty file. I ran it a second time, the output is the same except it now says ".drv-1" <ieure>FuncProgLinux, Uh, that's weird. <FuncProgLinux>Would it be ok if I show you on a paste? The only thing I modified were the build-system arguments and the package version. The arguments were modified to use G-Exps & list style only <Rutherther>you're missing lambda when adding the fix-introspection-install-dir phase. So the substitute is executed prior to all the phases, namely before the unpack phase that would give you the source <FuncProgLinux>Rutherther: OH! So every phase must have either a lambda _ or lambda* procedure to be executed in order? :s <FuncProgLinux>Not complaining about that but I remember I also skipped that on a third-party mate package and it could also be the answer. <Rutherther>every phase is a function that is executed... it's not that the phase has a lambda, it *is* the lambda <FuncProgLinux>Rutherther: It seems I need to study more scheme. I've lost count of how many times I shot myself in the foot this month <Rutherther>ACTION successfully reconfigured guix system & guix home from mesa-updates after like 8 hours of compiling <aidans>identity: Sorry I was away, but yea cgo was not enabled in compilation with my version of Go installed by Guix. It requires the envvar CGO_ENABLED=1 <Rutherther>well it is mainly the branch for mesa updates, but since it is a world rebuild, it also has libxml2 ungrafting, yes <FuncProgLinux>8 hours of recompiling things though. The first things that come to my mind are the programming languages and the browsers lol <kestrelwx>I'm gonna start a 5 hour 'linux-libre' compilation real quick. <Rutherther>mainly nss-rapid & librewolf (those were updated on master) and then linux (I should probably make a customized version so that it doesn't take so long) <aidans>Not necessarily, I was able to compile Firefox in around 45 minutes on average, though not through guix <ekaitz>futurile: i've been talking to my wife about the funding email in the ML and she said she thinks you are like 25 yo <ekaitz>futurile: because that's the image she has from the FOSDEM where we met <aidan>FuncProgLinux: :c I suppose it is system dependent <aidan>Yeah I am very thankful also to everyone working on fixing libxml2 grafts <ekaitz>futurile: she's like "oh but this guy was very young? he's the president of the Guix Foundation??" <futurile>ekaitz: yeah, well I'm flattered that she's met me and things I'm 25 ;-) <futurile>ekaitz: less flattered that my writing style makes me sounds like that - but you can't win them all! <futurile>ekaitz: also, I will note that I was very surprised that there is absolutely NO presidential plane! <futurile>ekaitz: and so far, no-one has offered me any money in a brown envelope - not what I was expecting at all <futurile>ekaitz: as someone who has a partner that's had to go to various FOSS events (which I have never heard the end of!) - you are very lucky to have such a supportive person ;-) <ekaitz>futurile: if it was just for me i'd never go to fosdem, she pushed me to go! <futurile>well as you know - she was right - your presentations are a star turn! <Rutherther>jpmf: so the passwords do work in tty, but not in gdm? <Rutherther>it might be possible it will be en us right now because of a bug, even if you have other layout. Did you try looking at the password (right click show password or something like that) <ieure>Have noticed that my expected layout in Gnome is wrong recently as well. But I'm in the US, so the only thing wrong is that caps lock isn't control. <Rutherther>it's caused by the libxml2 grafting abi incompatibitity, where a library gnome is using is unable to properly read xml file with the layouts <ieure>identity, I mostly use EXWM, just noticed that Gnome was broken when I used it to test some stuff. <ieure>identity, The real control key works, my remapping of caps lock to be an additional control key doesn't. <identity>i was trying to make a joke; i too had noticed that recently, luckily i switched back to qwerty from $insert_cool_keyboard_layout recently <ieure>identity, Oh, I know. But I like to keep people on their toes, so I like to take serious things humorously, and funny things totally straight. <jpmf>I tried tty and passwords do work. But in login from GDM they dont (checked the spelling by revealing password) <Rutherther>Okay, so then I would expect the issue to be pam rules. Can you check /etc/pam.d/gdm-password, does that file exist and if so, do the contents look intact?