<podiki[m]>that looks like it should work, not sure why the error is for passwd...it is the version of the config file you linked to? <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. <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)? <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]>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]>the manual example looks like a typo to me, but I haven't tried it <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]>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]>gotta run, feel free to file the bug/patch, if not I can take care of it later <Kolev>podiki[m]: Thanks. Good night. <podiki[m]>now you will forever doubt the manual.... :) ***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? <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]>I read that this is usually a question of missing libraries, but ldd looks happy <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 <vivien>the_tubular, you need to be a bit more specific. What is the password or private key for? <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 <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) <vivien>guix deploy recently added an option to run a command on the machine <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 <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 <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`? <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. <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>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 <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 ? <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. <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 <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!) <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 <sneek>I last saw roptat in #guix one day and 14 hours ago, saying: yw :). <xelxebar>`curl https://gnu.org' 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>oh i get certificate issues with debbugs.gnu.org just now <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 <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. <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 <jpoiret>you can try killing it again and launching it in the console directly with `gpg-agent` <jpoiret>you can try to run gpg-agent with -v (and more v if you can't notice anything wrong) <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 <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? <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. ***roptat is now known as Guest2562
<nckx>Good morning [is apparently an NFT shibboleth now smh] Guix. <nckx>Imma always spell it out now. *nckx watches some prerecorded talks. <jpoiret>it might be the one video that hasn't been submitted yet <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. <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>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 <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 <stfnbms>I have the following in my system.scm: ***ChanServ sets mode: +o nckx
<nckx>stfnbms: Please use a pastebin. <acrow>leinad: I mis-spoke; but I suspect networking could also trigger your problem. <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”. <nckx>We recommend the one in the topic since e.g. pastebin.com (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' <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) <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, 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 <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. <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>i think it should be made more obvious in the manual; i made that mistake myself once <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? <civodul>apteryx: it's at line 202, says Geiser :-) <apteryx>my Geiser says nothing like that :-( <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) ? <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? <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 <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/'..." ***lukedashjr is now known as luke-jr
<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 <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>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? <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)) <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>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) ♪ <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 <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 <Lembrun>jpoiret: Okok thanks for the explanation <civodul>lfam: so if i were loading firmware for that chip, it wouldn't hang? <lfam>I mean, thinkpads are a very common kernel development machine. I assume tons of kernel developers are using iwlwifi <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? <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>and his colleague Madalin too, though they're not on IRC AFAIK <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) <apteryx>it weighs 2.7 GiB instead of 14 TiB and should allow our 'guix gc' to complete timely. <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 <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 <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 <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 :-/ <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? <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.) <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? <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_>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_>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_>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) <rekado_>we also need /etc/rsyncd.conf, unless we’ve found a better way to run the rsync daemon for mirroring <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_>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_>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_>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... <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