IRC channel logs
2024-04-19.log
back to list of logs
<sham1>Alright, the thing reconfigured and now it boots just fine. Tomorrow (well technically today, but shush), after work, a pull and then it's off to the races <JerseyJoe>Hi, I'm trying to set up an emacs daemon service using guix home and shepherd and am getting an odd error. <JerseyJoe>If I try to load all the definitions in the repl and even feed it into the home service I get no issues -- i didn´t include the entire error as well because it seems to cause guix home reconfigure to spit out basically every file path in my dotfiles directory <JerseyJoe>thanks in advance to anyone who has any ideas :) <freakingpenguin>JerseyJoe: I think make-system-constructor takes a string, not a list of 1 string. Maybe look at (xmodmap-shepherd-service) in (gnu home services desktop). <JerseyJoe>freakingpenguin it doesn't appear to make a difference. I was using make-forkexec-constructor earlier which does take a list but that was giving the same error. <freakingpenguin>JerseyJoe: Gotcha. I also think extending home-profile-service-type and home-files-service-type with the shepherd service would be a problem. <JerseyJoe>freakingpenguin thanks, removing those two extensions got rid of the error -- now im getting a "wrong type error" but I'll try to troubleshoot that myself a bit before I report back. :) <JerseyJoe>Thanks for your help it seems to be working now freakingpenguin :D <cow_2001>i have a package definition of Zipheir's texinfo version of r7rs-small. to which file in /gnu/packages/*.scm should i add it? it is not really guile-xyz as it is a standard which guile supports, and also several other scheme implementations <cow_2001>thought maybe documentation.scm, but that's for software that handles documentation, not for documentation itself <Guest61>What happens if I reconfigure my existing guix system with a change to the `type` of a `file-system` in the `operating-system` declaration? It would be some magic if that somehow reformatted and migrated all my data. Presumably that doesn't happen, and I'm tentative to give it a try. <iyzsong>Guest61: i think it would not boot (will fail to mount the fs due to wrong type in /etc/fstab), and the magic for reformat and migrate can be implement in some way but not existed now. <Guest61>iyzsong: I see, okay that's good to know. That'll be super cool if/when such magic exists :P <daviwil>I don't actually see nss-certs-3.98 being used anywhere in a package <miaomiao>Hi all, I had a question about CI support for config files. Does config.scm need to be in /etc/? If not, how can I move it and not break everything? Simple moving and guix system reconfigure? I'd like to have it all play nice with stow <iyzsong>miaomiao: yes, it can be put anywhere <daviwil>I think the problem with nss-certs in my config is that I'm using `specification->package' to pull in packages by name, "nss-certs" being one of them. Since both nss-certs packages have the same name in their package records, `specification->package' is pulling the newer version which conflicts with the `nss-certs' symbol that has now been added by default to `%base-packages' <miaomiao>iyzsong, thank you. does that work for symlinks too? so if i had a link to a file/directory made with stow in my home directory, can i point reconfigure to the link? <iyzsong>miaomiao: yes, it can. unless you have referenced (by local-file, etc.) other files in config.scm, which may need some care. <miaomiao>hmm, ok. i think i can make that work then. thank you, iyzsong. :) <fnat>What's the recommended way to add an executable to my path? Context: I have a bunch of small scripts generated from various G-exps that I add to my '.local/bin' via a 'home-files-service-type' service. <fnat>I started wondering if there might be a more direct way of doing this. <oriansj>fnat: well you can skip the generation and just do (plain-file "name" "contents") <sham1>Speaking of g-exprs, I wonder if it's possible to do something like local-file but which lets you basically do a substitution before writing to the store, so I could make my input files more like .in where stuff like executables can then just get set to their proper paths <sham1>Actually less that if it's possible and more how <fnat>oriansj: Thanks! I think my doubt is specifically on how to make the script visible to my user. My legacy home configuration copies the script to '.local/bin'. Do I need that? <bjc>sham1: ‘mixed-text-file’ might be what you're looking for <oriansj>fnat: if .local/bin is in the user's path it should show up in tab completion <fnat>'plain-file' and similar procedures will generate or save a script in the store, but then I still need to link to it somehow? <fnat>oriansj: It does, it works well. But I was wondering if this extra step of creating a link from '.local/bin/xyz' to '/gnu/store/...-xyz' is necessary? <oriansj>none of the guix-home stuff is necessary; it is just nice to have and not everyone here uses it <jpoiret>fnat: you can put those scripts in the profile instead <sham1>bjc: not really, since it requires me to put the actual text into the scheme configuration. What I'd actually do is more like the following: file has a @BASH@ special string and then substitute for that whatever, in this case the path to bash in the store, and then the resulting file after all the substitutions is put into the store. Basically like substitute* but it doesn't touch the original file <jpoiret>just create a simple file-like that outputs a store path with your script under /bin <bjc>sham1: yeah, i don't think there's a templating system like that <sham1>Another rabbit hole to fall down I guess <jpoiret>you can pass an arbitrary g-exp, and you can use #$(local-file ) inside the g-exp to refer to the input file <bjc>is ‘substitute*’ available in computed-file? <jpoiret>if it's not by default it's just a matter of using (with-imported-modules ...) <jpoiret>you can add anything you want in a g-exp <sham1>I suppose that if I was to do #$(local-file ...) and then run substitute* that it wouldn't touch the actual local-file <sham1>Because if so, then it's the solution <fnat>jpoiret: Interesting, thanks! Ok, I'm already generating the script with, say, 'program-file'. Are you saying that I should have the executable saved in the store under a '.../bin' subfolder and then it gets picked up automatically by my user? <jpoiret>yes. It's built through the guix store, the original local file will first be imported into the store <jpoiret>you'll probably first need to do (copy-file #$(local-file ...) #$output) then (substitute* #$output ...) <jpoiret>because the local file itself won't be writable <jpoiret>fnat: if it's in the user's profile, yes <jpoiret>just like any program you add to your home-prifel <fnat>Brill, thanks jpoiret, I'll give it a try! <sham1>I do feel that this sort of "take this template, substitute in values and put into store" would be common enough that it probably would deserve itself a lowerable object of its very own. Might look into that <peanuts>"oss-security - The GNU C Library security advisories update for 2024-04-17: <civodul>in all seriousness, i think getting rid of the glibc graft is important for the UX <civodul>so i would consider adding this one patch (and nothing else) a good reason for a world rebuild <cbaines>civodul, given we haven't really built any of core-updates on the build farms yet, I don't see a problem with pushing that in principle <cbaines>the main issue with core-updates remains the stuff that's been pushed over the previous 9 months <futurile>civodul, jpoiret: right now it looks like we need to stop adding things, and figure out what needs to be removed/changed to get us to state where we can merge <cbaines>I'm trying to write an email at the moment, but does anyone know why there are commits on core-updates which are signed by other people? <cbaines>like 12b15585a75062f3fba09d82861c6fae9a7743b2, which is a commit from me, but signed by Maxim <cbaines>has there been a rebase at some point? <civodul>i don’t think there’s been a rebase though? <civodul>maybe that patch was lingering and got applied on your behalf? <cbaines>civodul, I don't think so, because I pushed that commit to master <cbaines>as e2a7c227dea5b361e2ebdbba24b923d1922a79d0 <civodul>futurile: agreed, we need a clear understanding of where we are <cbaines>so we've got commits on core-updates with the same content as commits on master, but with a different commit hash and signed by different people <futurile>cbaines: so I see a commit for xfce-terminal, signed-ff by you, but committed by Maxim to core-updates - it's different on master? <cbaines>yep, this is just on core-updates 12b15585a75062f3fba09d82861c6fae9a7743b2 <cbaines>but this is the original commit on master e2a7c227dea5b361e2ebdbba24b923d1922a79d0 <cbaines>and this is concerning, because if we merge core-updates, then both commits will end up on master, which seems wrong and confusing <jpoiret>cbaines: yes, I realized that a couple of weeks ago because I wanted to rebase <jpoiret>lots of commits after the branching point are also present on master <cbaines>at least with my understanding of Git merges, I'm not sure how that could happen <cbaines>when getting confused by this, I did spot 28d14130953d868d4848540d9de8e1ae4a01a467 so I don't know if you remember anything about the rust-team merge in to master? <jpoiret>i'm not seeing it with --no-merges --first-parent <jpoiret>(yeah, --no-merges to spot a merge commit is a bit stupid sorry) <janneke>ACTION finally pushes second reproducible tarball patch series #70380 to master <janneke>'twas much more than only avoiding warnings in the end <cbaines>jpoiret, I'm not sure how that'd be due to a merge <cbaines>if you look at the Change-Id Iee31c5de29c357c822f60df4fa8ce758779eb349, a commit with that Change-Id appears on master as well <mccd>Hey! How can I access the logs of shepard services? More specifically I'd like to see errors of my mcron service running mbsync <civodul>‘guix publish’ gets slower as its heap grows… <apteryx>so restarting guix-daemon is the immediate workaround? <mccd>apteryx, do you know where it logs as a home-service? <apteryx>guix publish is at 4 GiB RES memory on berlin <apteryx>that seems a normal number from memory? <podiki>apteryx: I think your link didn't make it in your email, but yeah that could be awesome funding <podiki>I don't think I would be the person for such a job, but would love to make Guix a job (since I gladly spend whatever time I can on it already) <apteryx>civodul: I've restarted guix-publish on berlin anyway, in case <podiki>I'll take a look and see if I can help with writing up an application, though the timing will be a bit tough for me <apteryx>podiki: they also have other related funds, for new features for example <apteryx>it could be you, if you take the time to make an application <podiki>great, I'll take a look at what else they have too, thanks for finding and sending! <cbaines>apteryx, 4 GiB memory sounds like a leak, I've been chasing another issue with the nar-herder but I've got resident memory down to ~190 MiB on bayfront <apteryx>some other fund in their family of funds is focused on UX if I remember correctly, they offer experts to help on the way <apteryx>any opinions against having a fully built 'core-updates-frozen' branch on the CI to help with the task of merging core-updates back into master? <apteryx>this way core-updates would stay open for business, and the name would hopefully communicate that the frozen branch should only get "necessary" fixes <podiki>hi all: please see a message just sent to guix-devel about potential security issue (or attack vector) and mitigation <podiki>apteryx: I believe cbaines set core-updates on CI to build all packages, but seems it hasn't? or i'm confused over what has been built or not. yes in favor of building core-updates and freezing to get it done <cbaines>podiki, Cuirass tried to evaluate the latest commit but failed <podiki>log just cuts off on building boost? <cbaines>apteryx, I'm concerned about those seemingly duplicate commits already on the branch, and I don't think having a core-updates-frozen will help with that <cbaines>"core-updates would stay open for business" seems bad to me, as the current situation is bad, we don't want business as usual <podiki>so maybe this is too simple/stupid, but what we remove the core-updates branch and have a new one called "core-team"...i feel we have some institutional inertia or baggage (and in old docs) over what core-updates is used for <civodul>podiki: yes, that’s the idea we came up with i think at the Guix Days (maybe even 2023?) <civodul>now that we have a ‘core-packages’ team, it should have its own branch limited to that scope <cbaines>podiki, I think that at least would resolve the issue with the weird commits on core-updates <podiki>sounds good to me, and dropping any "core-updates" branch or mention in the manual <podiki>if someone has some big change not covered by existing team/branch, we can just spin up a limited feature branch for that <podiki>e.g. ungrafting should be done regularly <rekado>(like the wip-pandas-upgrade branch I just started) <cbaines>podiki, by increasing the threshold for QA to build patches, more changes could be handled there as well <cbaines>(it's just that QA creates the branch for you, rather than a committer) <podiki>short-lived branches that come and go would be cleaner to look at too <podiki>or maybe with some delay or notification so related patches could be tagged? to prevent QA doing extra work <cbaines>podiki, having QA create branches from a combination of patches is something I've been thinking about for a while to address the problems with persistant branches <podiki>I only count 3 mentions of "core-updates" in the manual, as examples of sending patches for branches. so at this point already is probably more the lingering knowledge of how we used to use just core-updates (and staging, but i hadn't seen that used in my years here) <podiki>cbaines: what would work well, using debbugs tags? <cbaines>I'm not sure, but debbugs tags would probably be fine <podiki>or something more sophisticated with looking at dependency/rebuild overlaps? e.g. guix refresh -l and some comparison? <johnhamelink>Hi there, I've just installed Guix for the first time on a homelab server :) I installed the OS, rebooted and I've ran guix pull and sudo guix system reconfigure /etc/config.scm as per 3.7 After System Installation, but I get a conflicting entries error when I do this for nss-certs: https://x0.at/0Xr3.txt. I'm a total newbie following the initial installation tutorial so I'm unsure what to do next to debug this. Any ideas? <apteryx>cbaines: haven`t checked what's going on with these duplicated commits, but I guess they were rewritten using 'git rebase' <apteryx>'git merge' should be preferred to avoid rewritting past history (and preserving the original committer's signature) <cbaines>apteryx, do you know if core-updates has been rebased this time around (in the last 9 months)? <cbaines>I haven't been paying attention, but I'd assumed that master had just been merged in <civodul>cbaines: i have a checkout that i’ve updated from time to time and it’s always been fast-foward <johnhamelink>fnat aha! OK, this makes me feel a little less silly :D I will read through the logs, thanks <cbaines>and I don't think a rebase explains these weird commits ending up on core-updates, since both of the ones I was looking at were pushed to master first <apteryx>which weird commits are we talking about? <apteryx>ah, one with Change-Id Iee31c5de29c357c822f60df4fa8ce758779eb349 you wrote <fnat>johnhamelink: Do you have explicit mention of 'nss-certs' in your 'config.scm'? <mccd>So I managed to get mcron + isync running, but I'm noticing it's failing because it can't find the pass cmd. My job is (string-append #$isync "/bin/mbsync -Va"). Would changing it to run bash -c mbsync -Va work or is there a better way for it to be able to reference pass? <apteryx>I see; both commits are on core-updates <johnhamelink>fnat thank you for this; removing nss-certs from the list of packages in config.scm resolved the conflict :) Yes I did - it was there by default after installing the default config from live USB <apteryx>28d14130953d868d4848540d9de8e1ae4a01a467 and f29f80c194d0c534a92354b2bc19022a9b70ecf8, which are "Merge branch 'rust-team'" <fnat>johnhamelink: Congratulations, well done! <apteryx>hm, 'gitk' depends on 'wish', not captured <johnhamelink>fnat Thanks! Looking forward to hacking on my config now :D <cbaines>apteryx, f29f80c194d0c534a92354b2bc19022a9b70ecf8 is fine, it's 28d14130953d868d4848540d9de8e1ae4a01a467 I'm concerned about <cbaines>at least my understanding of merging and rebasing in Git doesn't explain how this could ever be proper <apteryx>cbaines: 'git diff 28d14130953d868d4848540d9de8e1ae4a01a467 f29f80c194d0c534a92354b2bc19022a9b70ecf8' shows their different content <apteryx>possibly I pushed an update to 'mold' while efram was attempting to merge the rust-team branch, and had to rebase in the middle <apteryx>(and efraim had to rebase in the middle of their merge) <apteryx>(ma)git warns about this, perhaps due to this confusing history <apteryx>but I'm not sure if this is really what's at cause. if you like, I guess the folks in #git would happily look into it <cbaines>civodul, yep, I guix pulled on hydra-guix-129 and the nar-herder is broken <cbaines>I think I've figured out it's guile-lib logging related, but I'm just trying to track down what procedure is being called with the wrong number of arguments <cbaines>that shows the odd commit (28d1413095) being pushed to the branch I guess <janneke>guix system: error: service 'renew-certbot-certificates' provided more than once <jab>janneke: hmmm... no idea. <jab>I have a guix system server (via linode) that powers gnucode.me <jab>I'm having trouble updating the server...I was able to successfully compile guix from source on the server. <jab>But when I do ./pre-inst-env guix weather I get this output: <jab>then it gives me a command that I cannot seem to run as root... <jab>hmm let me try it again <janneke>ACTION has three of those and it always worked afaik <jab>janneke: its probably operator error. <janneke>ah it has changed, the documentation to the rescue <jab>ok. it's not quite working for me. <jab>let me set up a pastebin <janneke>it hasn't, i need different webroots <cbaines>not fun when your logging is broken, but the nar-herder on hydra-guix-129 is now back <jab>janneke: I tried to set up the gpg keys based on the output... <jab>but it doesn't seem to work...? <janneke>ACTION goes to bisect the "renew-certbot-certificates' provided more than once" bug <Kolev>jab: I'm sorry tweaking CSS is giving you difficulty. <fnat>I have this in my home configuration '(simple-service 'foo home-files-service-type `(("bin/foo" ,foo)))'. Am I being naive in expecting 'foo' to be made available in my path? <sham1>A little bit. You need to have $HOME/bin in your $PATH. *Then* that will work <fnat>sham1: Ha, excellent, thanks! Is that a good way of adding misc binaries to my path when using Guix Home? <fnat>Hm, ok, I see what's going on. Yes, I was being very naive. I was using the exact same construct that I wanted to try and get rid of and I was expecting a different result. <Kolev>jab: I can help when I get back. It should be easy. <fnat>I think what I want is '(simple-service 'foo home-files-service-type `((".guix-home/profile/bin/foo" ,foo)))', but is '.guix-home/profile' captured by any Guix Home variable already? <vagrantc>hrm. diffoscope seems to release faster than i can get updates into guix these days :) <fnat>Naive again, '~/.guix-home/profile/bin' is read-only and I can't have 'home-files-service-type' to save stuff there... <bjc>i don't know if there's a way to get something in the profile's bin directory w/o a package <bjc>but if that's what you want, you can make a trivial-build-system package to put something there <fnat>bjc: I have a bunch of scripts that I save to ".local/bin" and then that folder included in my Bash PATH. I was wondering if there might be a more clever way. I'll look at the build system idea. <bjc>honestly, i just put things in ~/.local/bin <fnat>bjc: Ok, that makes sense. I might leave things as they are now. Good, thanks! <fnat>I've got two 'mcron.log' files, one under '~/.local/state/log/' and one under '~/local/state/shepherd/' - is this expected? <lilyp>the xz backdoor got propagated to rust's lzma-sys <lilyp>Einmal mit Profis arbeiten :) <mark_>interesting, how did that happen, I thought it would only insert itself into the build system in very specific cases <lilyp>Well, IIUC it's not the complete backdoor, but the test files have been copied over. <lilyp>Since all the -sys packages wrap the libraries themselves in a rather weird fashion it would be possible to infect them in much the same manner (i.e. by having a maintainer blow up the bomb). That being said, I don't think it does anything if built as a rust crate. <podiki>opens up an attack avenue though, something that does nothing in the upstream source/tarball but does through the rust wrappers? <lilyp>does anyone else get errors from doc/guix.texi? <lilyp>welp, I think not, because it's in the code I'm just debugging :) <dariqq>ahh i was looking at lzma-sys (which has not been updated in a year ) and not liblzma-sys (which is the affected package) <lilyp>ahh, sorry, I didn't think I'd typosquat you by accident <dariqq>no worries :), just took me a bit too long to realize that these are different crates <podiki>we're on a streak of discovering ways to poke holes today! :) <miaomiao>i am having a problem with a screen locker (swaylock) i'm not familiar with. i have installed from the standard guix channels, and it seems that in order to unlock the screen it uses password authentication via /etc/pam.d. it wonn't ever pass the auth check even with a correct password because what's in the gnu store path appears to be missing, or not what it's looking for. has anyone encountered something like this before? <miaomiao>from what i can see it might be as simple as putting the configuration file it expects in the gnu store /etc/pam.d dir (says it wants /etc/pam.d/login which does not exist) but i am not sure <miaomiao>oh! that actually looks like xactly what i need to do. <cancername>hi #guix! thanks for all the help, quick question though, how may I change the linux-libre version to be installed? <cancername>I've searched the web, of course, and read the manual, tried specifying `linux-libre-VERSION` for operating-system's kernel field, but that did not work out <vagrantc>cancername: i have (kernel linux-libre-6.8) ... for 6.8.x <vagrantc>cancername: "did not work out" is a bit vague ... what actually goes wrong? :) <cancername>huh, interesting, I specified linux-libre-6.7.12 but that didn't work, perhaps the patch version just isn't allowed <miaomiao>dariqq: worked perfectly. thank you for pointing the way :) <vagrantc>cancername: yeah, probably just major.minor version <vagrantc>cancername: it's just not defined that way ... there is a package definition for linux-libre-6.7 which uses the most current patch version, e.g. 6.7.12 <miaomiao>i am learning a lot about this system but i feel like a babe in the woods so much lol <vagrantc>i still feel a bit uncivilized, but i manage my way around with some guix stuff :) <vagrantc>cancername: glad it was something simple :)