IRC channel logs


back to list of logs

<podiki[m]>that looks like it should work, not sure why the error is for is the version of the config file you linked to?
<dongcarl>janneke: Woohoo!
<Kolev>podiki[m]: Yes.
<Kolev>podiki[m]: `git push` and "Everything is up to date."
<podiki[m]>and in the swaylock-effects package that is the write path, /bin/swaylock? (not familiar with wayland stuff)
<podiki[m]>(and just in case, you are running sudo guix system reconfigure /path/to/that/file ?)
<Kolev>podiki[m]: swaylock-effects runs as swaylock.
<Kolev>podiki[m]: sudo
<podiki[m]>sorry, stumped (and not sure why you are getting the error for something that is a default setuid)
<podiki[m]>oh, is the %setuid-programs supposed to be out one layer (eg. the append should have arguments the (list ...) %setuid-programs)?
<podiki[m]>typo in the manual then?
<Kolev>I'm a bad programmer. I don't know.
<podiki[m]>I believe so, do try (move one closing paren from after %setuid-programs to the line before)
<podiki[m]>to be fair I think you copied the manual example correctly...
<podiki[m]>I'm not sure since I don't know what %setuid-programs is, I'm assuming it is a list though
<podiki[m]>oh right it is a list. so yeah, I think the manual example has a typo
<Kolev>podiki[m]: So, add a paren and reconfigure.
<Kolev>podiki[m]: I religiously copy the manual, and it has a typo. That can't be right.
<Kolev>podiki[m]: It worked before, until I changed it to swaylock-effects.
<Kolev>Oh! It is indeed missing a paren! I did not close (list ...)!
<Kolev>…so that it would append to the %.
<podiki[m]>not add a paren, but move it
<podiki[m]>it worked with what before?
<podiki[m]>much as we wish the manual is not infallible
<Kolev>podiki[m]: But (setuid-programs ...) was alr. balanced.
<Kolev>Oh, it is not. Moving paren I will.
<podiki[m]>not following, your version I saw online was balanced in the setuid-programs sexp, but looked like the append was acting on one list, not the list and %setuid-programs
<podiki[m]>but I only have your online version I saw
<podiki[m]>the manual example looks like a typo to me, but I haven't tried it
<Kolev>podiki[m]: It is now <>.
<Kolev>It seems to be building.
<Kolev>It shouldn't be downloading gnome-shell. I removed that.
<Kolev>I can't complain; at least it's building.
<podiki[m]>gnome is in all sorts of things unforutnately
<podiki[m]>so yeah, typo in the manual
<podiki[m]>I can file a bug report or patch later, but feel free to report it
<Kolev>podiki[m]: It's incl. in `%desktop-services`, then?
<podiki[m]>gdm is which you deleted, but gnome-shell I don't know
<podiki[m]>probably anything related to gnome pulls it in
<podiki[m]>you can use guix graph to explore
<podiki[m]>gotta run, feel free to file the bug/patch, if not I can take care of it later
<Kolev>podiki[m]: Thanks. Good night.
<sneek>Yey! rekado_ is back :D
<podiki[m]>patch sent for setuid typo
<Kolev>thanks podiki[m]
<podiki[m]>thanks for finding the bug!
<podiki[m]>now you will forever doubt the manual.... :)
<daviid>sfind unless
<daviid>sorry, wrong window
***lukedashjr is now known as luke-jr
***cap2 is now known as cap
<Michal_Atlas[m]>Hello, I tried patchelfing for the first time and `ldd` now reports everything as found, yet running the binary still produces "no such file or directory", is there something else I've got to do for this to work?
<vivien>Does the binary informs you what file or directory it is looking for?
<Michal_Atlas[m]>No, the binary is not found
<efraim>hello guix!
<vivien>Michal_Atlas[m], usually when a program reports a "no such file or directory" error, it prints the name of the file or directory it is looking for
<Michal_Atlas[m]>As I'm saying, the thing it can't find is the binary
<Michal_Atlas[m]>I read that this is usually a question of missing libraries, but ldd looks happy
<asdf-uiop>hello guix
<Michal_Atlas[m]>Okay, so, the problem was that in addition to setting the rpath I had to set the dynamic linker, it all works now, thanks
<the_tubular>Is there a way to handle env variable with guix ?
<the_tubular>Specifficaly password and priv keys ?
<vivien>the_tubular, you need to be a bit more specific. What is the password or private key for?
<the_tubular>Well let's just say a user account's password
<the_tubular>Is there a good way of dealing with this other than inputing it manually ?
<vivien>Could you precise what you mean by "dealing with" the password?
<the_tubular>Of course. putting your password in clear in config.scm is not a good way of dealing with it
<the_tubular>Well adding or changing a password
<vivien>You can (and maybe should) avoid setting the password in config.scm, so that you can change it with the passwd utility
<vivien>It is stored in /etc/shadow (in an encrypted form)
<the_tubular>Yes, I know that
<the_tubular>Other than changing it with the passwd utility
<the_tubular>Let's say I want to use guix deploy
<the_tubular>On X number of machine
<vivien>guix deploy recently added an option to run a command on the machine
<the_tubular>I'd need to input the password one by one ?
<vivien>Maybe you can do something like yes "the password" | guix deploy ... -x -- passwd
<vivien>I don’t know if it will work, I never tried guix deploy
<the_tubular>I was thinking of passing the password hash in like config.scm
<vivien>Or you can scp the /etc/shadow file on each machine after the deploy
<the_tubular>But that's still not best practice
<the_tubular>Yeah, guess I could do that
<eyJhb>I seem to remember some command in Guix System, that would list various revisions of your machine + tell you how many security fixes this one has compared to the previous etc.
<eyJhb>But, I forgot the command and haven't used Guix in same time
<abrenon>hello guix !
<gnoo>how can i have a one-shot service that is ran until it returns successfully? i want to have 'mpc add /' but mpd takes some time to initialize.
<balbi>hi all, how can I remove `network-manager-service-type' and replace with `connman-service-type' on `%desktop-services' while instantiating `operating-system`?
<civodul>balbi: hi! you can use 'modify-services' as in the avahi example at
<civodul>(scroll down a bit)
<balbi>civodul: thank you :-)
<eyJhb>What would be the best/correct way to disable sudo, and use doas instead?
<sughosha>Hi all! Is it possible to remove dots from version? An app is of version 6.47, but the source filename has 647. In bash, I can ${version//.}, somethink like that in Guix would be helpful. Thanks in advance.
<abrenon>sughosha: wouldn't some regexp in guile do the job ?
<efraim> I'd use string-replace-substring, and replace "." with ""
<sughosha>@abrenon and @efraim thanks for the links! Both are very helpful. `string-replace-substring` seems easier for me. I'll read them and learn more.. Interesting..
<civodul>wingo: i came up with a workaround for read hash extensions vs. read-syntax:
<civodul>it sets up a SRFI-39 parameter so the extension knows if it's called from read or read-syntax
<civodul>and so it returns either an sexp with source properties or a syntax object
<civodul>how does that look?
<abrenon>Thanks efraim I didn't know about the string operations ! that sound much simpler (and probably faster) than having to build a regex just to perform this simple deletion
<abrenon>by the way, in the case of replacing a single character with "", wouldn't string-delete directly do the job ?
<wingo>gosh that's gross :)
<xelxebar>ARGH. Built an image, but am unable to pull inside, "guix pull: error: Git error: the SSL certificate is invalid"
<xelxebar>nss-certs is added to the operating-system packages.
<xelxebar>Even doing everything suggested in the "10.11 X.509 Certificates" section of the manual doesn't help.
<civodul>catonano has connectivity issues...
<civodul>wingo: isn't it? :-)
<civodul>oh that was meant for #guile
<wingo>civodul: i don't know of a better solution tho. i mean if needed we should expose a parameter from guile itself to indicate when we are reading for syntax, for use by read hash procedures i guess
<civodul>wingo: yeah, that and/or "converting" sexps + source properties to syntax objects on return of read-sharp
<civodul>or reinstating the source-annotation fallback mentioned at
<civodul>(haven't tried)
<wingo>would you need to traverse into structs? i guess a lot of these "unquote an arbitrary live value into the result of `read'" things fell by the wayside with the compiler
<wingo>so we can only visit like pairs and vectors and mostly handle the issue
<wingo>but, really it would be best if read-gexp could return syntax objects (as iiuc your patch does when possible?)
<wingo>or, just always use read-syntax and then use syntax-case to pick it apart :)
<civodul>right, the patch has it detect if it's called by read or read-syntax, and in the latter case it returns syntax objects
<wingo>i suppose you have a number of tools like the linter that want s-expressions
<wingo>(but the linter would have better source locations if it used read-syntax!)
<civodul>but we're not requiring 3.0.7+ yet
<wingo>sure sure
<civodul>but i agree, that's the way to go
<wingo>just thinking about what the right thing is. could be that stopgaps like your patch are sufficient and that in guile we don't have to do more. or it could be there is another stopgap in guile that would be ok too.
<wingo>or it could be we have to have a comprehensive solution somehow. hope not tho, given that the interface is quite weird and not touching it would be best :P
<civodul>seems to me some sort of special treatment for read-sharp would be good enough
<civodul>or just restoring the datum-sourcev fallback in source-annotation, maybe
<zimoun>sneek: seen roptat
<sneek>I last saw roptat in #guix one day and 14 hours ago, saying: yw :).
<xelxebar>`curl' is also reporting an ssl error. Why are these certs broken?? Just pulled and built image today, so it's not like nss-certs is really old.
<civodul>xelxebar: could you make sure that /etc/ssl/certs/ exists and is non-empty, and that that SSL_* variables are either undefined or point to /etc/ssl/certs?
<civodul>hey, just noticed the Guix Days program is online, woohoo!
<civodul>oh i get certificate issues with just now
<civodul>it was fine yesterday
<MysteriousSilve4>hello, how to change the pinentry program?
<MysteriousSilve4>running passmenu in the terminal prompts for gpg password in the terminal itself, however when i bind passmenu to a keybinding and execute it, it does not prompt for password
<MysteriousSilve4>ideally i'd want pinentry-qt to handle password input
<MysteriousSilve4>➜ cat ~/.gnupg/gpg-agent.conf
<MysteriousSilve4>pinentry-program /home/anon/.guix-profile/bin/pinentry-qt
<jpoiret>how does gpg agent start?
<jpoiret>often, you need to update its activation environment, otherwise it won't know that you have DISPLAY or WAYLAND_DISPLAY set
<xelxebar>civodul: Yes, SSL_CERT_DIR, SSL_CERT_FILE, and GIT_SSL_CAINFO all exist in the environment and point to existing directories/files.
<MysteriousSilve4><jpoiret> "how does gpg agent start?" <- not sure
<jpoiret>personally, I make sure to do `gpgconf --launch gpg-agent` inside my wayland compositor when it starts
<jpoiret>that way, I'm sure that it inherits the proper env variables
<jpoiret>if you do `gpgconf --kill gpg-agent` `gpgconf --launch gpg-agent`, does that solve your issue?
<jpoiret>also, you need to restart gpg-agent in general if you modify its configuration file
<MysteriousSilve4>how long does it take? its been a minute and there's no output yet
<jpoiret>the --launch part?
<MysteriousSilve4>no, `gpgconf --kill gpg-agent && gpgconf --launch gpg-agent`
<jpoiret>it's instantaneous for me
<jpoiret>you can try killing it again and launching it in the console directly with `gpg-agent`
<MysteriousSilve4>ok, that now runs, but the pinentry program hasn't changed
<jpoiret>you can try to run gpg-agent with -v (and more v if you can't notice anything wrong)
<civodul>howdy zimoun! do you happen to know how to fix the dead links reported in ?
<MysteriousSilve4>nope, would it be possible that the configuration file is not read :/
<rekado_>I installed anki but the display area seems rather empty
<rekado_>looks like fonts and icons are missing
<rekado_>I’ve never used anki before, so maybe I’m doing something wrong
<jpoiret>rekado_: is that not
<rekado_>jpoiret: thanks, that’s indeed the same issue
<silicius>Is anybody here using geiser with company in emacs to edit config files?
<zimoun>civodul: for one (BBB instance), it is waiting a check all is fine. For the other, I also reported it. :-) Let me read guix-days to be up to date on that. ;-)
<balbi>what is the right way to install a different output of a package when using `specification->package'? For example, I'd like `git' and `git:send-email' to be globally available. I tried `(specification->package "git:send-email")' but that doesn't work
<civodul>zimoun: do you know the missing video URL so we can fix it, since it's already public?
<civodul>the BBB link can wait a bit i guess
<balbi>oh, seems like I should use `specification->package+output'
<zimoun>civodul, AFAICT, we did not received the video. Well, I do not remember pre-watching for checking.
<civodul>ah ok
***roptat is now known as Guest2562
<acrow>It's morning here guix!
<acrow>A rainy one.
<abrenon>and it's a rainy afternoon here : )
<abrenon>good morning acrow
<nckx>Good morning [is apparently an NFT shibboleth now smh] Guix.
<abrenon>what ?!
<abrenon>(also hi nckx)
<nckx>Imma always spell it out now.
*nckx watches some prerecorded talks.
<jpoiret>nckx: ouch
<jpoiret>greetings as well
<nckx>Hi abrenon & jpoiret :)
<nckx>Is there a meaning behind the blank mystery bullet at <>?
<jpoiret>it might be the one video that hasn't been submitted yet
<abrenon>hmmm guess I'll stick to "moin" : )
<vldn>can i use guile map on alists?
<nckx>jpoiret: That's… obviously the answer. Thanks.
<nckx>I thought the deadline had passed but I've been paying less attention than I should.
<jpoiret>oh but it has :)
<nckx>vldn: ‘Yes’, but your question does imply something more? alists are just lists, your mapped procedure will receive each pair as its argument.
<leinad>Hi Guix!
<leinad>Today I was trying to track down a problem with trash-cli, as described in this thread:
<leinad>and tried to go back in time: guix time-machine --commit=33884385383dc9aa2179b08fc28a398918ac4df4 -- search trash-cli
<leinad>but this one failed with a backtrace
<leinad>In the end it says: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
<leinad>Fehler: %guix-register-program: Nicht gebundene Variable
***hollowman6 is now known as hollowman
<leinad>this seems to be a problem specific to this commit as this one worked: guix time-machine --commit=39510d5a5e4e0e38cd3d3bc944d5bf6d96242493 -- search trash-cli
<leinad>any ideas?
<acrow>abrenon, nckx: weather provided context the NFT lacks. BTW, ncks: icecat (LibreJS, et-al) hates your meme link. :)
<acrow>leinad: has guix gc limited what time machine can do for you?
<nckx>Oh, poss, I don't use LibreJS. ‘It worked in Firefox’ 🤷
<leinad>acrow: you mean: if it would help to simply go back to a previous generation?
<leinad>Unfortunately no, since I haven't used trash-cli before. Just trying to get back to the reported latest version
<leinad>*latest working version
<stfnbms>I am having trouble enabling zram.
<stfnbms>I have the following in my system.scm:
<stfnbms> (services
<stfnbms> (append
<stfnbms> (list ...
<stfnbms> (service zram-device-service-type
<stfnbms> (zram-device-configuration
<stfnbms> (size "4G")
<stfnbms> (compression-algorithm 'zstd))))
***ChanServ sets mode: +o nckx
<stfnbms> %desktop-services))
<nckx>stfnbms: Please use a pastebin.
<acrow>leinad: I mis-spoke; but I suspect networking could also trigger your problem.
<stfnbms>For more than a line?
<nckx>It's OK, it happens to many people (once ☺).
<nckx>stfnbms: For more than 2 or 3.
***ChanServ sets mode: -o nckx
<stfnbms>System reconfigure fails with “zram-device-service-type: unbound variable”.
<leinad>acrow: Networking? How?
<nckx>We recommend the one in the topic since e.g. (IIRC) does some bad thing.
<nckx>stfnbms: Did you import the (gnu services linux) module?
<nckx>guix time-machine: error: Git error: cannot locate remote-tracking branch 'origin/keyring'
<stfnbms>Like this?
<nckx>See my question above, though.
<stfnbms>nckx: I do not have that line, so maybe not.
<acrow>leinad: It is morning and I've had too much coffee. I'm afraid that I'm typing before reading and thinking. You've raised my awareness of trash-cli but I don't know what's going on there.
<nckx>If you use use-service-modules, add ‘linux’ to the list, otherwise add ‘(gnu services linux)’ to your use-modules list, stfnbms.
<stfnbms>New to GUIX System (after using GUIX on an Ubuntu foreign distro for a while).
<stfnbms>Okay, will add it to use-service-modules then. Thank you.
<leinad>acrow: I feel you :-) The problem with trash-cli is that it stopped working. Apparently after commit 39510d5a5e4e0e38cd3d3bc944d5bf6d96242493. trash-cli is a python program and it does not find its modules anymore.
<nckx>Argh, I've run ‘git checkout -t origin/keyring -b keyring’, but still get ‘Git error: cannot locate remote-tracking branch 'origin/keyring'’ for file:///home/nckx/guix when running leinad's time-machine command.
<stfnbms>Will reboot to try it out now. Ciao!
<nckx>If there was a magic incantation to make it work, I forgot it.
<leinad>With the time-machine command I wanted to confirm the last working version as reported by Jacob
<leinad>nckx: Sorry, I am not working from a local checkout. So I don't know that magic
<acrow>leinad: b5853e089 was a change to trash-cli on Feb 15. Something to look at.
<acrow>leinad: I think your issue is actively being worked under issue 53695.
<leinad>I should've `git pull' before looking through the (outdated) history of my local checkout. Thanks for the pointer!
*rekado_ starts a new wip-texlive
<vivien>Dear guix, can I get my last patches for 53402 in a new branch? I can’t put them in a separate channel, and I don’t want to recompile guix every time I want to use them.
<podiki[m]>...I'm looking forward to watching that "better patch review" talk, though unfortunately can't attend the session (time zone)
<podiki[m]> has been without response for nearly 6 weeks
<acrow>vivien: Packaging that was obviously challenging. It seems like it will inevitably be wanted after it gets reviewed. Until then would it help to maintain a local git feature branch that you could compile from? until it is able to get into master?
<stfnbms>nckx: Your suggestion worked. Thanks again!
<nckx>stfnbms: Glad to hear it!
<vivien>acrow, I’d like to try and use it in gitlab CI. This is already difficult, I don’t want to build guix from source on top of that
<acrow>vivien: I don't know anything about gitlab continuous integration but could you use guix pack to get a tarball that you could more easily leverage to your needs?
<acrow>vivien: sorry, that's probably not helpful.
<vivien>That could be a good idea, but I have nowhere to put the pack
<nckx>vivien: I don't really follow the reasoning, but why not. See wip-python-mne.
<nckx>Do you mean a CI-built branch?
<vivien>nckx, thanks!
<vivien>nckx, I don’t need Cuirass to build the branch
<nckx>vivien: You're welcome, but I'm not sure what the goal is. Now there's just a wip- branch you can't push to :)
<lfam>We could probably delete some of the wip branches on Savannah
<efraim>stfnbms: here's what I have
<stfnbms>efraim: Thank you!
<stfnbms>It would be nice if one could tell Guix to use, say, half the physical RAM (however much that is) for zram (like Ubuntu does).
<civodul>lfam: looks like there's some cleanup to be done, indeed :-)
<acrow>reviewers: thank you for your feedback on rhino and the generous sharing of wisdom. I will make another go that attempts to get things properly aligned shortly.
<falloutphil>Hi Guixers - if I have a proposed patch (enhancement not bug fix) for guix/colors.scm do I submit it to the guix-patches as the default master branch, or given that it's not a package should it go somewhere else like core-updates?
<falloutphil>Also I'm assuming I don't need any other pre-approval of the enhancement before submitting the patch (it's trivial, and I accept the patch could be rejected, of course).
<nckx>Hi falloutphil. Which branch to target depends on the number of rebuilds the change would cause. This sounds like a change for master (changing the guix package doesn't rebuild the world, thankfully). There's no pre-approval, all review happens on the patch tracker/glorified mailing list.
<nckx>Oh, and thanks! ☺
<falloutphil>Thanks nckx - yes it's a simple enough addition inside the body of an already existing procedure.  I'll submit as suggested - thanks!
<simendsjo>Somehow, my guix broke. Using a foreign distro, so I usually do `sudo -i guix pull` `systemctl restart guix-daemon` `guix pull`. After updating the root guix, any guix command for my local user is saying "WARNING: loading compiled file .. In procedure load-thunk-from-memory: incompatbile bytecode version". I see guile 3.0.8 is referenced in some paths, while I have 3.0.7. But root also has 7...
<unmatched-paren>fairly sure you're not supposed to do sudo guix pull
<unmatched-paren>only rootless guix pull
<unmatched-paren>i think it should be made more obvious in the manual; i made that mistake myself once
<unmatched-paren>it breaks your guix installation
<unmatched-paren>try doing `~/.config/guix/current/bin/guix pull`
<unmatched-paren>as the user
<simendsjo>I don't do `sudo guix pull`, I do `sudo -i guix pull`. Root has one version, my user has another version. The root version only has `guix-daemon` pretty much
<balbi_>man, having a lot of fun with `guix' heh :) reinstalled it with a nicer setup, now running stumpwm instead of sway
<simendsjo>.. that is .. I use `sudo -i guix pull` only to update `guix-daemon`, which shouldn't change very often.
<mroh>Is there a way to remove emacs-guix-mode (pcomplete/guix) from shell (or comint?) pcompletion?
<apteryx>reading (guix system system), around line 877; where is that 'install' procedure actually defined?
<apteryx>for the init action
<civodul>apteryx: it's at line 202, says Geiser :-)
<apteryx>my Geiser says nothing like that :-(
<apteryx>Symbol not found (install)
<apteryx>and the root directory of my guix checkout is in %load-path
<apteryx>I tried ',re' at the Geiser REPL, and it printed: Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (console-setup (gnu packages xorg)) #f)'
<apteryx>OK, I've pulled and ran 'make' in my tree again, now the odd error above is no more, but Geiser is still not helpeful
<lfam>simendsjo, unmatched-paren: `sudo -i` is fine for `guix pull`
<lfam>It does what you expect: Logs in as root and updates root's guix
<apteryx>civodul: just to make sure, in the (guix scripts system) buffer, with a connected Geiser at that module (C-c C-a), pressing M-. on the 'install' symbol at line 877 brings you to its definition at line 202?
<lfam>The bytecode incompatibility warnings are merely warnings and can be ignored
<lfam>I suspect it will go away after `hash guix` or re-logging in
<lfam>I don't think it will actually cause anything to stop working
<apteryx>rekado_: would tonight be a good time for the last stage of the migration (reboot on the new root file system) ?
<simendsjo>lfam: I notice that guile 3.0.7 is used when calling guix for my user, while 3.0.8 is used for root. Could this be the problem? If it's just a warning, there might be something else going on -- I get an exception when running `guix pull` as my user:
<lfam>Does the exception then cause `guix pull` to fail?
<apteryx>simendsjo: I think I've had this kind of problem in the past; it had to do with the GUILE_LOAD_PATH having items from different incompatible versions.
<lfam>The version mismatch is expected, if you are using different versions of Guix for root (i.e. guix-daemon) and your own user (i.e. `guix`). Different versions that used different versions of Guile
<lfam>We made an update like that in December
<simendsjo>lfam: Yes, that's the last thing that happened.
<lfam>Did you run `hash guix` after `guix pull`?
<lfam>Or, try logging in again?
<simendsjo>Both root and my user refers to the same `guix`, but the guile wrapper refers to different versions. I've tried rebooting and running hash guix.
<lfam>Hm, I'm not sure I understand what you mean. Both users are using the same thing, but it's different?
<lfam>You could try `guix describe` for each user, to ensure that each user is using the Guix revision you expect
<lfam>As well, you could double-check that `which guix` returns "/home/you/.config/guix/current/bin/guix"
<simendsjo>`realpath $(which guix)` refers to the same file. This uses a shebang for a "guile-wrapper". Running that wrapper shows a different version for the users. `/gnu/store/549xzhnm3q810py1v0jbv0px0prd3a21-guile-wrapper/bin/guile --version` returns 3.0.8 for root and 3.0.7 for my user.
<simendsjo>`which guix` returns "/home/simendsjo/.config/guix/current/bin/guix"
<simendsjo>`guix describe` returns different versions. The timestamp indicates that it has updates, but maybe just some of the other channels? 34e1454 for root, 373c77b for my user.
<lfam>Those two commits are minutes apart, from today
<lfam>So, Guix / Guile will be the same when based on them
<lfam>I don't really know what the wrapper does, but it's weird that it returns different versions based on who runs it
<lfam>Understand what happens there will be necessary to debug this
<simendsjo>Hmm.. But pull throws an exception, so things isn't really up to date it seems.
<simendsjo>I also find it strange that the wrapper should use a different version, but it might be to support testing using different guile versions..? I bet things will work if I manage to upgrade my local guile to 3.0.8...
<lfam>I was able to run `guix pull` successfully, and I have Guile installed as well, fyi
<lfam>I have Guile 3.0.7 installed
<simendsjo>Same as me. I might be on the wrong path then. Does the wrapper in guix give a different version?
<simendsjo>.. need to go to bed now though. Added a reddit thread to keep a more syncronized discussion (I'm not on the mailing list..)
<lfam>For both my own user and root, I ran `/gnu/store/549xzhnm3q810py1v0jbv0px0prd3a21-guile-wrapper/bin/guile --version`, and got 3.0.8
<lfam>I don't have a reddit account so I probably can't help on that page
<simendsjo>What? How come I get 3.0.7..?
<lfam>I don't know! Something isn't right
<lfam>You can check if `guix pull` actually succeeded or not by doing `guix show chromium`, and checking if it shows the Chromium version that came with commit 373c77b
<lfam>Anyways, I know you have to go
<lfam>Rather, `guix show ungoogled-chromium`
<lfam>I forget the name of the package
*apteryx stares at "initializing operating system under '/new-root/'..."
<jab>Hey guix!
<nckx>Hi jab!
***lukedashjr is now known as luke-jr
<the_tubular>Hey nckx, saw that bcachefs post ?
<the_tubular>Excited if it is upstreamed this year!
<nckx>Nein! I've been criminally AFK lately. Patreon?
<apteryx>berlin is ready to be rebooted on its new file system, should someone with access to the serial console be available in case something goes wrong
<nckx>Do share.
<the_tubular>Give me a minute
<simendsjo>lfam: `guix show ungoogled-chromium` gives another exception:
<the_tubular>"we might be ready for upstreaming sometime this year..."
<the_tubular>Do you know how hard it would be to implement bcachefs in guix ?
<Lembrun>Hej, Anyone succeeded in changing the keyboard layout for "stage 1" grub? The default is qwerty and the only reference to this issue is there , I did find this too but as I'm new to guix I haven't been able to makes this work ( something about grub not being able to find X11 rules, I installed the
<Lembrun>xkeyboard-config but I do not know how to make grub-kbdcomp aware of the rules in xkeyboard-config)
<nckx>the_tubular: Not to temper you optimism (which I still share), but this is like attempt #3 so far. The notorious ‘it's done cooking, let's get this sucker merged’ thread was in 2019.
<nckx>Lembrun: Silly question: does stage1 grub support keymaps?
<the_tubular>Yeah I remember that :(
<Lembrun>nckx: According to the second link that I posted you should be able to with a memdisk
<nckx>the_tubular: WDYM by ‘implement bcachefs in Guix’? Apart from flipping the .config switch once it gets into linux-libre, we should be ready to go for the simplest (single device) case. It ‘should not be much work 😉’ to add multi-device root support. I just don't use it myself.
<the_tubular>Umm, I though there would be some guile magic behind the config switch
<nckx>Lembrun: Gotcha. Guix doesn't do any of that, so ‘succeeding’ would consist of writing some code and adding it to Guix.
<nckx>the_tubular: I'm still not sure what you mean. Which config switch?
<the_tubular>             (mount-point "/") (device "/dev/mapper/cryptroot") (type "bcachefs") (dependencies mapped-devices))
<the_tubular>Implementing something like that
<Lembrun>nckx: Yeah I thought it was going to be something like that, but right now I unfortunately don't have time to look into the code and make a patch
<nckx>the_tubular: That should just work once the kernel supports it.
<nckx>The magic needed to boot is already there:
<nckx>Booting from multi-device file systems might need more (similar to btrfs device scan). Possible problem is that bcachefs-tools is definitely moving to Rust, and might be Rust-only by the time it's merged.
<nckx>Maybe that's not a problem at all but as the de facto bcachefs/Guix maintainer I don't look forward to maintaing anything Rust :-/
<nckx>(Aside: you've got me considering adding a linux-libre-bcachefs package again… ☺)
<lfam>simensjo: Hm, something is definitely not working! Sorry about that...
<jpoiret>Lembrun, nckx: stage1 grub does indeed support keymaps
<jpoiret>stage1 grub is very similar to grub proper, you just need to include what you want into the binary
<jpoiret>that requires manually using grub-mkimage though
<nckx>I used to know all this, >10 years ago (wow) ♪
<jgart>Hi Guixers, Is a shebang like this documented anywhere for Guix?
<civodul>apteryx: yes; either C-u . first, or C-c C-k to compile it
<lfam>civodul: I forgot to mention in my email about the kernel issue: the latest series that is unaffected in 4.19. So, you can use linux-libre-4.19 to keep your system "up to date" until the fix lands upstream
<civodul>jgart: you would do it as shown at
<Lembrun>jpoiret: Yeah it's at this stage that I'm stuck, I'm used to classic linux distros that write X11 cofnig to /etc but that does not seems to be the way it works in guix, so I created the memdisk tar on my debian machine and then sent it on the guix machine, did the grub-mkimage on the guix machine by installing grub-efi, everything seems to works but when I reboot things get little weird
<jpoiret>Lembrun: grub is installed as part of the `guix system reconfigure` process
<jpoiret>anything you do manually via grub-mkimage and grub-install will most likely not work properly
<civodul>lfam: oh just saw your message; i'll try blacklisting iwlwifi, that could well be the cause (that laptop has Intel wifi built in, which i don't use)
<jpoiret>we'd need to modify the grub bootloader in guix to use grub-mkimage and install it manually
<lfam>I'm certain that's the issue
<lfam>It also explains why it wasn't noticed upstream: it's unusual to have some wifi hardware but not use it
<civodul>true :-)
<Lembrun>jpoiret: Okok thanks for the explanation
<civodul>lfam: so if i were loading firmware for that chip, it wouldn't hang?
<lfam>I guess?
<civodul>uh, fun
<lfam>I mean, thinkpads are a very common kernel development machine. I assume tons of kernel developers are using iwlwifi
<jgart>civodul, THNX!
<lfam>They wouldn't have let it break for months
<jgart>Does anyone have a preference of where we should document the shebang line linked above by civodul? cookbook?
<jeko>Yo Guixters !!!
<kitty1>hi uwu
<nckx>jgart: I'd even say manual.
<jgart>nckx, wdym? just the manual, no cookbook?
<nckx>I mean, use it in the cookbook if it's relevant, but it seems important+obscure enough to document properly in the manual, even though it's ‘technically’ an env feature. We ‘document’ sudo -i in this way, etc.
<civodul>jgart: a few lines under "Invoking guix shell" in the manual would be nice IMO
<nckx>It's pretty neat that you found a way to avoid adding ad hoc code to guix shell, civodul.
<civodul>nckx: it's maybe more a consequence of laziness but i guess it does the job
<nckx>Laziness gets a bad rap.
<civodul>cbaines: i just noticed that bordeaux.guix has a substitute for novena-eeprom for x86_64-linux even though it's armhf-linux-only
<jgart>civodul, re: a few lines: Got it, thanks. I'll add it to my TODOs
<jgart>nckx, re: document properly in manual: sounds good to me
<apteryx>civodul: is rekado the only one with serial access to berlin?
<civodul>apteryx: i think so, yes
<civodul>and his colleague Madalin too, though they're not on IRC AFAIK
<civodul>any problems?
<apteryx>OK; I'll wait :-). I'm just eager to reboot berlin on the new root file system (can be inspected at /new-root on berlin)
<civodul>sounds like something :-)
<civodul>so these are the SSDs?
<apteryx>it weighs 2.7 GiB instead of 14 TiB and should allow our 'guix gc' to complete timely.
<civodul>woohoo! \o/
<civodul>you rock!
<civodul>it's smaller because it has fewer things or thanks to zstd compression?
<apteryx>ah, well it's brand new (guix system init) so has a fresh store; the previous store at this point has gone mostly ungarbaged collected if I understand correctly
<apteryx>(because someone always ends up killing it, out of exasperation)
<civodul>yeah, more or less, for a couple of months
<civodul>was the pgsql database migrated as well?
<thornAvery>hello! im moving from nixos to guix and just done an install. Im having trouble setting my keyboard layout, Im using /etc/configuration/desktop.scm, but with the layout line changed to `(keyboard-layout (keyboard-layout "dvorak"))` and then running `guix pull` before `sudo guix system reconfigure /etc/config.scm`
<civodul>(i wish our systems were truly stateless, it sounds surreal to even consider these things on #guix :-))
<civodul>thornAvery: hi! sounds right; what's wrong?
<thornAvery>whenever I reboot, everything is still in qwerty, for the bootloader, kernel and x session
<apteryx>civodul: no, all the database would restart from scratch; is this a problem?
<thornAvery>although Ive since removed the disk encryption, however it still happens at least for x
<apteryx>I guess it means cuirass would put the new array to the test for a couple days, furiously building things
<Lembrun>thornAvery: same problem as me : )
<Lembrun>the stage 1
<Lembrun>of grub is in qwerty be default
<civodul>apteryx: we'd lose all the Cuirass history, so that's better avoided IMO
<civodul>but i don't know what it takes to copy it over
<Lembrun>and for that to be changed you need to get your hands dirty and look into the guix code related to the bootloader, and this for reference
<thornAvery>just to balance out the vibes in the room, I will say that Im loving the guix cli interface
<apteryx>yeah, I'm not sure if just copying it into its new home would be enough (after stopping the cuirass service)
<thornAvery>I was hesitant to switch but its definitely a key point towards guix there
<Lembrun>thornAvery: the rest works for me though from grub stage 2 to X, these are correct for me
<apteryx>civodul: the previous data won't be touched though, so we can probably upon reboot 1. stop cuirass 2. issue the magic commands to re-ingest the previous DB content 3. restart the cuirass service ?
<apteryx>I don't know about 2. but I suppose it is trivial once we know it :-)
<rekado_>apteryx: hey, sorry, yes, tonight is a good chance to reboot again
*rekado_ reads backlog
<nckx>Is there a way to git-fetch a repository without deleting .git? I basically need to generate a ‘git diff’ within the origin, or something like that, I'm not entirely sure yet.
<nckx>The X problem here being I need to rebase one origin repository upon another :-/
<nckx>Madness, etc.
<rekado_>apteryx: the old config had this activation-service hook to copy over the kernel and initrd to /store
<apteryx>nckx: not with git-fetch, .git is not deterministic
<rekado_>I’m a little confused about how we’d boot into the new system
<nckx>Is this something a computed origin could hack?
<apteryx>nckx: perhaps :-)
<nckx>Bah :)
<rekado_>we use UUIDs to identify the root fs? Or the label?
<mbakke>apteryx: I think copying /var/lib/postgresql wholesale should work to preserve Cuirass state
<apteryx>the new root fs is on the Btrfs subvolume named @root
<rekado_>have you checked that the new grub menu entry is alright?
<apteryx>all the subvolume are from the same Btrfs pool identified via a UUID
<apteryx>yes, if you look under /new-root/boot/grub/grub.cfg, you'll see the subvolume name correctly prefixed in front of linux and other critical paths
<rekado_>(I’m so scared of being the one having to fix booting when it gets stuck, because I feel I’m getting dumber every minute.)
<apteryx>less /new-root/boot/grub/grub.cfg
<rekado_>so … uhm
<rekado_>I won’t be able to boot an older config if this one doesn’t work, eh?
<apteryx>it's similar to my home setup, if that gives some confidence :-)
<rekado_>can we like chainload the old grub.cfg somehow?
*rekado_ uses words
<apteryx>rekado_: thanks for metioning activate service type... I should probably remove that from the config since it won't be needed (and may cause problems)
<rekado_>I guess it would be enough to copy over the most recent “menuentry …” from the old grub.cfg, right?
<rekado_>that mentions the old disk’s uuid and all that
<rekado_>BTW: I only just finished reconfiguring the three honeycomb machines on my desk
<apteryx>it should be possible to boot from the previous drive (which currently appears as /dev/sdg) by pointing GRUB to its /boot/grub/grub.cfg I guess?
<rekado_>took forever to build all the systems because of the coreutils test failures
<rekado_>somewhere in the grub console
<rekado_>not sure how to do that, but I guess we needn’t worry about this now
<rekado_>about the dbs: should we copy this stuff *now* or after booting?
<rekado_>I’m concerned about diverging: the new cuirass would build its own new db and start working, and then we’d have a hard time integrating the existing db.
<apteryx>so two things to do before rebooting; 1. devise a strategy to migrate the pgsql database of Cuirass and 2. Redo the 'guix system init' with the 'copy-kernel+initrd-to-/store' service removed.
<rekado_>2 sounds good.
<rekado_>1 sounds like we should just copy what we have to /new-root
<apteryx>indeed, that probably would make things easy
<rekado_>so that when the new system’s cuirass starts it’ll pick up where it left off
<rekado_>not sure if the db references anything that may no longer exist in the new system
<apteryx>perhaps stop the service, run rsync -aPHAX on its /var/ location, then reboot
<rekado_>oh, another thing: we should change the config so that berlin accepts substitutes from localhost
<rekado_> just the postgres stuff, though; not all of /var, because we don’t want the old guix-daemon db
<rekado_>how about build logs?
<rekado_>may need to copy those too
<apteryx>should /etc be carefully preserved?
<apteryx>this is the edited berlin.scm so far:
<rekado_>we need to keep some of /etc, yes
<rekado_>the signing keys for guix in /etc/guix, and the letsencrypt state
<rekado_>also /etc/ssl-ca for cert-based authentication with cuirass
<rekado_>maybe also /etc/childhurd (so we don’t need to reconfigure the childhurd service)
<apteryx>I'll just copy the whole thing
<apteryx>we can prune it later
<rekado_>we also need /etc/rsyncd.conf, unless we’ve found a better way to run the rsync daemon for mirroring
<rekado_>also /etc/ssh for existing keys
<rekado_>we should copy the letsencrypt stuff before rebooting
<apteryx>the /etc content is now copied to a @etc subvolume
<apteryx>which I'll add to the file-systems list now
<rekado_>note that we can’t keep all of the contents in /etc
<rekado_>some of the files are generated and the system will refuse to boot if some files exist
<rekado_>(like /etc/group)
<apteryx>I thought it'd just nuke these
<rekado_>would have been better to keep those things separate from the outset
<apteryx>so do you feel it's better to copy just what you mentioned so far, or we copy everything and remove the problematic files?
<rekado_>not sure if this was ever changed; I just remember from when I installed the earliest build farm nodes by running “guix system init” on top of Ubuntu that the system failed to boot and I had to delete a whole bunch of files from the REPL…
<rekado_>we do both!
<rekado_>all of /etc gets stashed away somewhere safe
<rekado_>and the parts I mentioned are placed on the new root before rebooting
<rekado_>pretty sure we also need to copy /etc/wireguard
<rekado_>or else all the existing VPN nodes won’t be able to join
<apteryx>ok, stashed as /mnt/btrfs-pool/@etc.backup
<rekado_>what about /var/mumi?
<rekado_>and other state in /var?
<rekado_>I’d say /var/mumi needs to be copied and /var/log too
<apteryx>it's dinner here, then play time with the 3 year old. I guess we'll have to put this back tomorrow...
<rekado_>tomorrow is fine
<apteryx>OK; this should me enough time to adjust for the remaining bits (/etc and /var/). thank you!
<rekado_>let’s walk through the old rootfs again tomorrow and then pull the trigger
<rekado_>ideally a little earlier than today :)
<rekado_>thank you for making so much progress on this end
<GNUtoo>hi, is Danny Milosavljevic on IRC sometimes?
<rekado_>very exciting to start over so soon :)
<GNUtoo>Danny worked to package the older Raspberry PI free software bootloader, and a free software license (GPLv2) was just added to the new attempt which is based on LK
<GNUtoo>(the status is much better than rpi-open-firmware)
<nckx>sneek: seen dannym?