IRC channel logs
2025-03-23.log
back to list of logs
<ulfvonbelow>%virtual-build-machine-operating-system in (gnu services virtualization) is throwing exceptions when its services field is evaluated because it's using modify-services to try to modify syslog-service-type, which is no longer in %base-services <gabber>what is wrong with this channel? i can build the definitions locally (guix build -L path/to/that) but pulling fails with "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (channel)) (value #f))" <gabber>do i need a .guix-channel meta-data file? <gabber>well, this is a channels.scm file (for the time-machine) <podiki>the error is saying you have "channel" as an undefined variable somewhere <podiki>i don't see that in your online repo, assuming that is up to date <podiki>i guess something else wrong but it is showing the wrong variable? <gabber>well, or unbinding? is that even possible in Guile? <podiki>so i profess my ignorance of guile/guix here, but perhaps something different as a list rather than a cons directly? <gabber>messing that up immediately fails with "guix time-machine: error: 'channels.scm' did not return a list of channels" <gabber>so the list/cons* part seems to be right <gabber>there must be some sort of difference between pulling that repo as a Guix channel and using the modules as imported with -L <podiki>oh you do have channel, in system.scm (branch trunk, i was on wrong branch) <podiki>missing (gnu services base) in that file maybe? <gabber>is there a --allow-downgrades option for deploy? <gabber>nvm. i think there is no such option. fixed my git history and got it to work <podiki>welcome! that was a subtle one, glad i could help <meaty>is there a way to let guix know the association between certain feature flags and certain dependencies? <meaty>That way a user that chooses to build with certain flags turned off can get a smaller derivation <meaty>Nix seems to have the feature <ieure>meaty, You can write a Scheme function that returns a package object. <ieure>There's not really a "feature" because it's a behavior of how things already work. <piethesailor>Hello all! Is there anyone that packages discord? Is there another place to ask that if this nongnu question isn't "kosher"? <ieure>piethesailor, I don't see any packages for it in any channels I know about. Presumably it's just an Electron thing anyway, use the website? <ieure>There are some bridges packaged for ex. Bitlbee. <piethesailor>but I have been using it. looking for the same with mullvad vpn.. <ieure>Does the normal Wireguard stuff not work? <meaty>piethesailor: You may have to package them yourself. nonguix has a 'binary-build-system' iiuc, which you can use to "cheat" in binary builds <meaty>or you can use a flatpak perhaps? <piethesailor>I'd like to stick to only using the guix package manager if possible <piethesailor>I am kind of suprised no one has tried to package discord. On one hand its very commonly used. on the other its not free software <piethesailor>meaty: Is there an example of a package definition for a tar.gz file? <ieure>piethesailor, It's presumably non-free, and I'd say there's not a ton of overlap between Guix packagers and Discord users. <piethesailor>I think the only thing I am missing is how to get the checksum, and then get it as base32 <meaty>piethesailor: the first time you try to build, it will likely fail and tell you the checksum you get <ieure>piethesailor, If it's a tarball, you can `guix download THE-URL' and it'll give you the SHA. Doesn't work got Git repos, though. <ieure>Or any other kind of SCM, at least, as far as I know. <piethesailor>interesting. I got mullvad, but all commands Error: Management RPC server or client error <piethesailor>while I am here meaty.. is that binary-build-system something you repace the (build-system gnu-build-system) wiht? <piethesailor>I dont even see binary-build-system on the guix build systems web page <ieure>piethesailor, It's in nonguix. Everything in Guix has to build from source. <piethesailor>gotcha.. (use-modules ... (nonguix build binary-build-system)) doesnt want to work. <piethesailor> binary-build-system: unbound variable hint: Did you forget a `use-modules' form? <ieure>piethesailor, You need to take this to #nonguix <apteryx>hm, spice-vdagent stopped working for some reason <untrusem>Rutherther: so I have to remove /mnt/store and /var guix while out of chroot? <untrusem>I was in chroot and removed /gnu/store, then the rm is not found. It is to be expected. <untrusem>which config should I use for my sytem init? <untrusem>can i use substitutes in guix system init? <untrusem>Rutherther: So, I already started a guix damon in the chroot shell, now that I have removed gnu stare , so how will I like stop it, for unmounting the /mnt because without that it won't <Rutherther>untrusem: I don't know how you even could remove the store when the daemon has been running out of it. Anyway I don't know why it matters, just look through the running processes and kill it <Rutherther>untrusem: better to get the full one - ,bt #:full? #t <Rutherther>I hoped the path is going to be there fully, but apparently not, okay <Rutherther>my guess is that it's special file service / last activation step and that somehow you ended up with either /usr/bin/env.new or /run/current-system.new file and if that's the case, you will have to remove those manually. I think the services don't check for those .new file <Rutherther>it will probably be easiest to first look what that /gnu/store/vfl8g0664f6 ... store path is pointing to <untrusem>you mean booting into live distro again? <Rutherther>probably, or at least I don't know how to use the repl to check files <Rutherther>so after you mount your root partition, check what the file I pointed out is (the hash should be enough to point out just one store path) <Rutherther>I was trying out my hypothesis in a vm and I get the same error, but slightly more specific backtrace which throws me off the track a bit <untrusem>acl acl.bak signing-key.pub signing-key.asc <Rutherther>this is definitely a bug, it shouldn't happen that this symlink fails. And by looking at the code I don't actually see the condition that would lead to this state, as it tries to move the acl file out of the way / remove it completely... <Rutherther>anyway I really hope you won't be encountering any more file corruptions <Rutherther>there's the bug-guix e-mail for reporting bugs, and it always is good to leave as much context, like 1. the error you see with backtrace (on the photo you sent), 2. what you did before (reinit the system after removing the store and /var/guix), 3. what you did to fix it (remove acl files) <Rutherther>the issue is that your acl file was pointing to a location that doesn't exist, so file-exists? returned #f on it even though the link itself does exist <Rutherther>if you're going to report it, I am going to send a fix to your thread, if not, I will send the fix myself directly without bug report <untrusem>because currently I don't have the machine <Rutherther>(also btw don't forget to run guix pull before reconfiguring & sourcing the profile or relogging the first time you run it, as you lost your user guix profile) <df>what is the policy for restarting (or not) herd services after a system reconfigure? <df>I see to end up with a few in the state: Replacement pending (restart to upgrade). <df>but I only notice that if I check the individual services <Rutherther>df: I think that no running services are restarted <df>is there any way to get a list of services that have been modified and need resstarting? <csantosb>Trying a `mumi current 76686 && mumi am', but no patches are found, any idea ? <msavoritias>Is there any tutorial on how to add your own sepherd timers to the system config? I am adding the updatedb example from the sepherd manual but it fails with source expression failed to match any pattern <msavoritias>the shepherd docs say how to run it with herd trigger or add it to a specific directory for the less-priviledged shepherd, but it does not say anything about system timers <msavoritias>my usecase is specifically to replace the mcron functions i have to shepherd timers. and while doing that I also got stuck in how do we actually add custom services to the system config <futurile>msavoritias: generally, there's not a lot of tutorials about Shepherd that I've seen. No other service in guix does this then? (to crib an answer from). If you can't find anything I would ask on guix-help as someone might have an example <lilyp>rngd-service-type from (gnu services base) is about as small a shepherd service example as you can get in Guix source <msavoritias>my next plan was to look through the guix source code yeah. I was just looking if there any timers in any config somebody has, or also custom services (since as I understand shepherd timers are shepherd services which are services) <msavoritias>docs or some existing config would be easier to read than guix source code. but if that is the only way I can always go there <lilyp>shepherd timers are quite new, so few are making extensive use of them yet <untrusem`>hello, I deleted the gdm service type and but still see that after I rebooted <futurile>did you actually reconfigure? Look in /run to see what version of the config you're using in /run/current-system/ <lilyp>easy mistake: set-xorg-configuration pulls in gdm-service-type <lilyp>you can change the service type it pulls in, but the cleaner way is to write (your-xorg-service … (xorg-configuration <the-configuration>)) <untrusem`>yep futurile my current config is there in /run/current-system <untrusem`>lilyp I see, any config snippets you can link to? to get an idea from <lilyp>I'm gonna quote my own config.scm here – it uses gdm still, but illustrates the point <apteryx>is 'udevadm monitor' currently broken in Guix System? <apteryx>I'm trying to detect CDROM events and it's dead silent <apteryx>perhaps related to bug#63508, though it'll take some rebuilds to verify that right now <Rutherther>apteryx: works fine for me I am on a commit from like 2 days ago <lilyp>what you'd write is the delete as previously, but you'd also add e.g. (service slim-service-type (slim-configuration (xorg-configuration (xorg-configuration …)))) <Rutherther>untrusem: what service do you actually want to use for starting xorg instead of gdm? <noe`>Is there a command to know which package is the source for a specific store item? <Rutherther>noe: for that you can usually infer it from the name of the store path. But generally there is guix locate, mainly meant for searching files that you don't have path for. It will print the package as well <untrusem`>Rutherther: I would like to switch to wayland and use shell login <Rutherther>then why did you have set-xorg-configuration in the first place if you don't want xorg? <untrusem`>I just went with the default config and build up upon that when I figure things out later <noe`>Rutherther: good idea, thanks! <noe`>Well, this is getting complicated. I want to get debug symbols for glib in /gnu/store/fx3… but all I can find are glib’s with different hashes. Any ideas on how to get a hold of it? <Rutherther>noe`: try guix gc --referrers <path of glib you're using here> | grep debug <Rutherther>or of course if you know the guix that produced it, it's as simple as guix shell glib:debug <noe`>I’m on the guix that produced it, but guix build glib doesn’t give me the same hash and I suspect it was substituted so I don’t have the debug in my store to be found by --referrers. <noe`>What puzzles me the most: guix build gnome-music == gnome-music in --refferers, but guix build glib != the glib i’m looking for. So the glib I’m looking for must be a hidden package somewhere, just need to find out which <Rutherther>noe: have you tried: guix build --expression="(@ (gnu packages glib) glib)" <noe`>Still the wrong hash ;( also with glib-minimal and glib-with-documentation. I have to be on the wrong guix or something like that, I won’t take more of your time thanks for your help <lilyp>you could try `guix challenge glib` <lilyp>maybe it is a reproducibility bug <civodul>podiki: you mentioned mbsync & mu4e yesterday; is your config online? <civodul>i’m considering a change in my email setup, the first in 20 years or so :-) <apteryx>civodul: hi! I haven't gotten your reply by email no. I've heard gmail is quite strict with the dkim stuff <Rutherther>lilyp: would guix challenge be able to do anything if this was that serious of a reproducibility bug? because guix challenge would be able of detecting output hash mismatch, not input hash (the one in the output path name), or am I mistaken? <apteryx>I've been considering a change in my email setup too ;-) <lilyp>Rutherther: it would be able to tell you that this is a reproducibility bug rather than something else <apteryx>civodul: I'm not sure I can still reproduce it. I think I saw a shehperd update come through in between my tests. I'll retry later and close if it's no longer reproducible. Perhaps we could also reboot berlin with the new shepherd and rerun the mcron schedule action <apteryx>it was specific with my config though, the basic desktop template was OK IIRC <apteryx>ACTION managed to update localed to 257.4 <podiki>civodul: some of it is online, not all because i haven't figured out how to cache mbsync passwords (i have to authenticate via pass) but i do have a gmail set up that works <podiki>the only wrinkle is sometimes last year something went off with archive/trashing (as in archiving will trash instead), though might just be where one needs to sync something read first and then sync after moving <podiki>also i have to use a oauth token to send mail through my institution, that is a separate bit (you can see that in the sending mail section for one) <apteryx>hm, samba@4.18.1 : probablement vulnérable à CVE-2023-3347, CVE-2023-34966, CVE-2023-34967, CVE-2023-34968, CVE-2023-3961, CVE-2023-4091, CVE-2023-4154, CVE-2023-42669, CVE-2023-42670, CVE-2023-5568, CVE-2022-1615, CVE-2022-2127, CVE-2022-32743 <JodiJodington>hi, was wondering if anyone else was getting an error every time they ran `guix pull`? Just want to know if it's a known issue before I submit a bug report <Rutherther>definitely not a known issue. What error are you getting? <JodiJodington>"Computing Guix derivation for 'x86_64-linux'... \ice-9/read.scm:126:4: In procedure read-string: <JodiJodington>gnu/packages/music.scm:2732:1: invalid character in escape sequence: #\return" <JodiJodington>I even removed my channels.scm and it gives me the same error so im not sure what's going on <Rutherther>it could be a file corruption, have you tried "guix gc --verify=contents"? <ulfvonbelow>cups (not cups-minimal but cups) is missing libxcrypt, the build fails because of it <JodiJodington>Rutherther: ran the command and there doesn't seem to be any problems (no output after "checking hashes...") <JodiJodington>and just for a sanity check, running `guix gc` followed by `guix pull` also doesn't work <JodiJodington>`guix pull` doesn't get influenced by anything other than the user's `channels.scm` right? <Rutherther>interesting. Then my only other idea is that the checkouts somehow got damaged, they're in ~/.cache/guix/checkouts, you can safely remove it (the only 'bad' thing will be that your guix pull can take lonber time). That error you're getting definitely isn't an issue in guix channel itself, I just tried guix pull to make sure and it is fine. So it has to be something on your side and those two are the only ideas I have now (corrupt store / checkouts) <Rutherther>the thing is that there has been a bug recently that caused the root files system to not unmount properly, so there was increased amount of file corruptions, mainly in the store, but I don't see why it couldn't happen in the checkouts folder <JodiJodington>just deleted the checkouts cache, ill let you know if guix pull works <Rutherther>JodiJodington: it gets 'influenced' by those files/folders: channels.scm, guix store, local checkouts, I don't think anything else. And you usually don't have to care at all about the store nor the checkouts <Rutherther>JodiJodington: it gets 'influenced' by those files/folders: channels.scm, guix store, local checkouts, I don't think anything else. And you usually don't have to care at all about the store nor the checkouts <JodiJodington>so it was caused by shepherd's reboot service? kinda crazy the linux kernel itself doesn't ensure drives are unmounted before shutting down <ngz>csantosb, lilyp: Thanks for #77209, that was fast! <lilyp>I'm almost done with my backlog (sans emacs-team branch) <lilyp>now looking at some mail that was inadvertently flagged as spam (I hate it when that happens) <JodiJodington>Rutherther: same issue but for a different file now, but I think I know the issue lol. I messed with git's global settings for how it handles carriage return/line feed characters, that's why it keeps failing at "invalid character in escape sequence #\return" <Rutherther>JodiJodington: oooooooooh I see. Yeah, but I would say guix should override the checkouts settings with what it needs to, not use the user's global settings :D <JodiJodington>yeah, maybe it could even bypass the git executable directly and use guile-git + libgit2 <JodiJodington>huh, is `.gitconfig` used by libgit then? I assumed that was only for the git executable <lechner>Rutherther / hi, did you close the bugs from Friday? <umanwizard>Hi all. After a recent guix pull / guix home reconfigure / guix system reconfigure, it seems display scaling is no longer being applied to emacs, while it is still being applied to gnome-console and other builtin gnome software. That is, I have 200% scaling applied in gnome settings, but my font is tiny in emacs as though I were using 1x scaling. I don't know for sure but my suspicion is it's related to the fact that emacs is running <umanwizard>via XWayland rather than being a native wayland app. <umanwizard>Anyone seen this before / have any tips for debugging? <ngz>umanwizard: Maybe using emacs-pgtk would help. <umanwizard>maybe, but I suspect this is just a bug, since it worked fine relatively recently. <JodiJodington>Rutherther: would you be okay with me thanking you in the bug report? <Rutherther>lechner: I can't close them, I am not a maintainer. But as far as I can tell for now they should be resolved, probably thanks to shepherd 1.0.3 release or something that happened in guix repo in the meantime. But I would really like someone who was experiencing the bug first hand to confirm it (like ieure or rekado) <redacted>Is python-tox actually ever used by python package? It's a dependency of several, but, as far as I can tell, it's a virtual-environment builder that can't use the globally available python packages as dependencies, making it useless to build Guix packages. <lilyp>redacted: not sure if I'm misremembering, but tox is used as a test tool in some packages <lilyp>I assume the virtual environment thingy is downplayed there <piethesailor>What are people using for VPN? I have mullvad but that is nongnu. <piethesailor>Perhaps there is a way to use wireguard to connect to a node in <not usa>? <lechner>Rutherther / anyone can close bugs by sending mail to XXX-done@debbugs.gnu.org with a message explaining why it's appropriate <piethesailor>guix search foxyproxy returns nothing. perhaps it is by another name? <piethesailor>ah. so it is not a system wide? I'd like to hide my qbittorent networking activities <Rutherther>lechner: I don't think that is true, you can close your own bugs, but not someone else's <ulfvonbelow>while the selection probably isn't the same, you could also try i2p torrents <piethesailor>perhaps there is a way to install torrents through browser then <freakingpenguin>Was the <issue>/patch-set/<revision> endpoint in mumi changed sometime recently? Some old code I used to apply patches now tries applying the 0/X commentary message as a commit when it didn't before. <piethesailor>is openvpn just a way to set up a local vpn you can connect to from afar? or does it have proper nodes you can connect to? <lechner>Rutherther / that is definitely and totally incorrect <lechner>Rutherther / we don't even use the owner field in Debbugs in Guix, I don't think <lechner>Rutherther / but even that is only a restriction by custom <Rutherther>I know from someone they couldn't close something because they accidentally used different e-mail than they used to create the issue 🤔but okay let me try <lechner>in fact, most of the time bugs are closed by someone other than the filer, namely the maintainer <Rutherther>lechner: okay, I've sent email to close #76959, so let's see what will happen <Rutherther>lechner: not sure about closing the other issue, I would rather wait for ieure confirming they don't see the issue anymore after updating to newer guix version. I am still not 100% convinced I reproduced the same issue, especially because ieure has said it happens for them even without reconfigure, but I was not able to reproduce that, only with reconfigures <lechner>Rutherther / that's totally reasonable. i agree with you. <lechner>Rutherther / thanks for closing that bug. maybe your hesitation explains, in part, why we have so many "open" bugs in Guix <Rutherther>lechner: I don't think I've hesistated closing it, I didn't even know I can close it. I thought only author or maintainers can do that <Rutherther>lechner: okay, I received an e-mail that the issue has been closed. Btw isn't this a bit concerning that someone could come and close an important issue? <Rutherther>(I am not used to that, I know mostly the various forges where only maintainers or authors can close issues or PRs) <lechner>Rutherther / no, it is not concerning. it is, however, inline with democratic principles and often the only way for folks with aspirations to become a maintainer to establish a track record in the responsible dealing with user complaints. in debain, it is the primary way people get promoted (as opposed to accepted commits in Guix). also, the experience in Debian shows a nearly zero abuse rate over more than a million bugs <lechner>Rutherther / finally, Guix is about to throw away tens of thousands of bugs by switching to Codeberg. we could close them all right now, and it wouldn't make a difference <Rutherther>lechner: that's great that there is such a low abuse rate. Can a closed issue be reopened? <lechner>Rutherther / absolutely! but you have to explicity "reopen" via mail to control@debbugs.gnu.org (followed by "thanks"). that is so that people unhappy with the solution can comment on the action taken. for bugs that have a been closed for a while, and in GNU Debbugs I believe that's a month, you have to first "unarchive" a bug. that's an ancient anti-spam measure nowadays controversial among maintainers. there was recent traffic on <lechner>the help-debbugs mailing list. i personally would like to get rid of it <lechner>Rutherther / please feel free to reopen the bug you just closed (and then close it again). your experimentation will annoy no one, except for a few lines of text here <lechner>Rutherther / except the original filer, that is, but you can just send unhappy customers to me <Rutherther>I like the simplicity of this all. That makes me even more sad about the switch to codeberg :( (if it will happen but according to the GCD discussion it seems to me more people are in favor of codeberg) <lechner>Rutherther / it definitely will, but unfortunately for the wrong reasons <tomenzgg>Dunno if anyone else has already asked this but anyone using XFCE and find that the appearance settings no longer affect any GTK applications? =gtk-3.0/settings.ini= and =gtk-4.0/settings.ini= seem to have no effect; not sure where the programs are getting their theme cues, anymore. <Rutherther>the_tubular: the mumi instance is refreshing only each x minutes so it can happen you won't see new issues right away although they are sent here <lechner>yeah, the debbugs bot syncs every five minutes, but the times may differ from Mumi. i could provide links to my own Mumi clone (like https://patchwise.org/77219) but did not want to confuse people by promoting it here <lilyp>to be fair, I would seriously like more mail compatibility on the Codeberg thing myself <lilyp>(I did already bring that up, though, and there's not that much that I can do alone to effect rewordings) <ekaitz>lilyp: hey, it's not cool if you got messages in bad faith. I know I've been sharing a strong opinion but I don't support that <ieure>lilyp, Is there a list of Emacs packages that still need tests updated? 
