IRC channel logs

<GNUtoo>hi, has guix time-machine been broken recently? I've a strange situation: In guix time-machine --branch=master --commit=<commit long hash> -- <pack|system image|build> [...], guix doesn't seem to take into account the commit hash

<GNUtoo>And is there a specific format that --commit= accepts?

<GNUtoo>If I do v0.1 is it supposed to work too?

<GNUtoo>For instance if I switch to an older commit revision, and build hello, I've the same /gnu/store/... path than more recent revisions

<nckx>--branch=master and --commit=<commit long hash> are contradictory; only one of those makes sense at at time. Guix should probably warn though. --commit=TAG is supported, but v0.1 is way too old to support the time-machine.

<GNUtoo>ohh ok

<GNUtoo>thanks a lot

<GNUtoo>ACTION messed up in a release of a tool but I'll probably be able to reconstruct it since I've used --save-provenance

<nckx>I'm trying to test how --branch/--commit interact in practice but in fact nothing works here, any time-machine invocation dies with ‘You found a bug’…

<nckx>Seems to be libgit2.

<GNUtoo>ok

<nckx>…so take that part with an untested grain of salt, but it fits what you describe.

<GNUtoo>Here's an example: guix time-machine --branch=master --commit=31b707cf5d179eb664df26b72f0f2976ef28f41d -- build hello

<GNUtoo>/gnu/store/s5pd3rnzymliafb4la5sca63j86xs0y0-hello-2.12.1

<GNUtoo>It also gives that with 'guix build hello'

<nckx>But does removing ‘--branch=master’ make a difference?

<GNUtoo>hmmm no

<GNUtoo>'guix time-machine --commit=31b707cf5d179eb664df26b72f0f2976ef28f41d -- build hello' produces the same store path...

<GNUtoo>guix describe shows: branch: master, commit: 28bd26b6b8245c71bc474237b24498caa832cc25

<banana-split> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=28bd26b6b8245c71bc474237b24498caa832cc25

<nckx>I'll try to reproduce it on my laptop, which is slow{er,}.

<nckx>Which store item do both ‘build hello’s return?

<GNUtoo>/gnu/store/s5pd3rnzymliafb4la5sca63j86xs0y0-hello-2.12.1

<GNUtoo>Maye something is wrong in my setup somehow though

<nckx>That's what I get for 31b707c. Testing 28bd26 now.

<GNUtoo>ACTION also tries on a second computer with a cleaner setup (guix system, no GUIX_PACKAGE_PATH)

<nckx>Let me put it differently: ‘guix time-machine --commit=31b707’ builds the exact same hello as ‘guix pull --commit=31b707’ (verified with ‘guix describe’).

<nckx>(Why) are you certain they must differ?

<GNUtoo>ahh maybe there are things that I didn't understand then

<nckx>Or I got lost in my rather unreasonable matrix of terminals :) I've got 8 open, with 8 slightly different commands, that's too much…

<GNUtoo>Right if things didn't change for hello, the hash should be the same

<GNUtoo>It's probably me that was confused because of more than one issue at the time (--commit= vs --branch=)

<nckx>ACTION waits for them all to finish and not do anything clever.

<GNUtoo>With --commit=v1.0.0 Guix starts doing stuff instead of just giving me the hash, so --commit= doesn't seems broken

<GNUtoo>It's just me that didn't think enough (it's late here)

<nckx>It shouldn't be, as long as you use a commit/tag that supports time-machining.

<GNUtoo>ok

<GNUtoo>Is the first supported commit/tag documented in the manual?

<nckx>OK, I can confirm that here, 31b707c and 28bd26 build the same hello, so the premise was flawed. But I don't blame you for the confusion.

<nckx>Good question. I don't know.

<nckx>…I guess not.

<GNUtoo>If I use older *releases* it seems to change hash, so it looks like it works

<GNUtoo>Since there were full rebuilds that's the expected situation

<nckx>ACTION tried f81ac34 on a whim but I think it's too old. I get guile-2.0-related errors.

<nckx>Oh it's implausibly old. I think the time machine only goes back a few years.

<GNUtoo>ok, so the response for that is "when the time-machine was introduced in guix's git?

<GNUtoo>s/"//

<nckx>I think so.

<GNUtoo>ok, I assumed that the guix binary and packages were somehow separate as there was somehow a way to run an older guix binary documented somewhere in the manual, but all that is fuzzy in my memory

<GNUtoo>The use case was to mix packages from different Guix versions

<nckx>No, they are quite the opposite (for some value of ‘binary’, it's not a single file).

<nckx>So, quite entangled.

<GNUtoo>Ah maybe it's indeed the opposite because it actually required an old guix to install the old package, good point

<nckx>ACTION tries travelling to f675f8dec7 resp. f675f8dec7^…

<GNUtoo>f675f8dec7 Add 'guix time-machine'.

<nckx>I thought you were the bot for a sec.

<GNUtoo>lol

<GNUtoo>So it should be in v1.1.0

<nckx>(So… I saw that, but then noticed the manual uses v1.2.0 as example. I'm probably just too cynical, but… why not use the more impressive older example? Was it broken?)

<GNUtoo>ACTION tries

<apteryx>what does this error mean: Action org.spice-space.lowlevelusbaccess is not registered

<apteryx>that action is under /etc/polkit.d/actions

<apteryx>do I need to reboot?

<GNUtoo>It seems to be related to spice and USB

<nckx>GNUtoo: Both failed with a ghostscript build error due to a source hash mismatch. You might get luckier and fetch a substitute, but be warned that the ‘past’ is filled with annoyances like this. There's still much room for improvement to preserve it.

<GNUtoo>Spice is used in libvirt for instance

<GNUtoo>ok

<apteryx>right. I'm working on unlocking USB redirection in GNOME boxes

<apteryx>so I've added polkit support to spice-gtk, added spice-gtk to the gnome-polkit-settings, reconfigured... and then I see the above,

<apteryx>when attempting to redirect something USB in GNOME Boxes

<GNUtoo>ACTION only configured polkit once and long time ago

<GNUtoo>nckx: ok, I'm mainly interested in guix time-machine for longer term reproducibility, for instance I release a tool (repo) and hope that it's somehow still reproducible in one year for instance. Another use is bisecting commits

<GNUtoo>/gnu/store/kg9mirg6xbvzcp0a98v7326n1nvvwgsj-hello-2.10

<GNUtoo>$ guix time-machine --commit=v1.1.0 -- build hello

<GNUtoo>That seem to work for me though

<GNUtoo>Computer: x86_64 with a host distro (Parabola)

<nckx>GNUtoo: Then you probably got a substitute for that ghostscript, or its source, which is how it's supposed to work. 👍

<nckx>(Or even for whatever needed ghostscript here in the first place.)

<nckx>As long as we never GC the substitute servers, and we hope never to do so, that should keep working.

<GNUtoo>One thing that could be done (and that could help with offline mirrors) could be to somehow be able to mirror only the releases

<GNUtoo>like keep v1.4.0 and enable people to mirror that somehow

<GNUtoo>This way we'd at least continue to have that over time

<GNUtoo>Sadly some distros remove older releases, so kind of loose the history

<nckx>That should be doable with a bit of (mostly local) work: anyone can pull Guix v1.4.0, compute all derivations (and hence substitute file names), then download/serve only those.

<GNUtoo>ok

<nckx>(This goes for any commit, not just 1.4.0.)

<GNUtoo>So you don't need to build everything?

<nckx>To what, exactly?

<GNUtoo>For instance if you want to mirror v1.4.0 from the bordeaux builder without rebuilding everything, you need to write some program to list all available packages at v1.4.0 and somehow compute the derivation, and then somehow you have the URLs to download the files?

<nckx>Yes.

<GNUtoo>ok nice

<GNUtoo>And with guix size you'd also be able to know how much spaces all that takes beforehand I guess

<nckx>Some URLs might 404 for older releases, because we didn't have the luxury of 100TB storage in the past, but 1.4.0 substitute coverage should be as complete as it was when released.

<nckx>Maybe we can start rebuilding old releases some day, as a test/for fun/to fill up the history :)

<GNUtoo>Can you also get the files hash beforehand?

<nckx>Well, ‘guix size’ works off substitute info (or your local store), there is no separate size database.

<GNUtoo>ah ok

<GNUtoo>So you'd need to querry gds and that will probably complicate the script too much

<GNUtoo>+ gds is recent

<GNUtoo>(guix data service)

<nckx>You've lost me a bit here. I don't see the GDS requirement. This would be closer to what ‘guix weather’ does. Actually it would be most of ‘guix weather’ + an HTTP GET at the end, to populate your mirror.

<GNUtoo>GDS stores packages sizes, right?

<GNUtoo>Or was it just a plan?

<nckx>Yes, but if you're querying the GDS, you could just as well send an HTTP HEAD to the substitute server you're planning to mirror from, no?

<nckx>Or does the GDS have a more efficient mass query API?

<GNUtoo>It's just that I didn't know you could easily get the size with HTTP HEAD

<GNUtoo>Though tools like wget report the size before indeed

<GNUtoo>ACTION should probalby go to sleep

<nckx>Or actually, you'd just download the narinfo, since you'd need to mirror that as well. That has size and much more.

<nckx>Well, a bit more.

<nckx>ACTION too.

<GNUtoo>ok

<nckx>ACTION takes GNUtoo's advice and → 😴💤

<apteryx>o/

<wdkrnls>Dear Guix, doesn't anyone have any examples of containerized window manager configurations?

<wdkrnls>Is that possible?

<wdkrnls>I have seen examples where containerized web browsers are able to use X11.

<wdkrnls>I feel like X11 is not the thing which will ever break with a window manager. It's updates to the window manager which can be an issue.

<wdkrnls>Maybe this is just what guix home is for.

<wdkrnls>I guess, what I'm wondering then is why everyone is installing window managers at the Guix system level?

<lechner>wdkrnls / hi, i am not and many others here aren't either. it's just that guix is so complicated we tend to give new users a gnome install with GDM so they don't get too scared off the bat

<lechner>also starting X by yourself requires a command line along the lines of xinit -- $HOME/.guix-profile/bin/Xorg :0 vt1 -keeptty -configdir $HOME/.guix-profile/share/X11/xorg.conf.d -modulepath $HOME/.guix-profile/lib/xorg/modules

<lechner>so that's not for everyone

<apteryx>mirai_: that is new also: guix system: warning: the following accounts appear more than once: maxim; is the mpd service now creating the account?

<apteryx>looks like it! perhaps I should not be running it as my user

<wdkrnls>lechner: thanks, that is interesting

<wdkrnls>I think I found getting GDM a bit limiting because I didn't really learn how to think about Guix.

<wdkrnls>If that command was wrapped up into a provided set of scripts, I think many users would be excited for a fresh approach.

<apteryx>the nss test suite is so ridiculously long

<apteryx>to answer my previous question about if polkit needed to be kicked to reload its action files: yes

<apteryx>pgrep polkitd -> kill it, then it'll restart and 'pkaction' will list the new definitions

<lechner>are you pulling an all-nighter?

<abrenon>hey guix

<Lumine>o/

<BitPuffin`>sup

<Hasnep[m]>henlo!

<user_oreloznog>hello guix!

<abrenon>o/

<PurpleSym>jlicht: I wanted to try your npm-binary-importer branch, but it fails to import `vue`: `Wrong type to apply: #<syntax-transformer semver?>`

<PurpleSym>Any changes since wip-node-14?

<jpoiret>PurpleSym: errors like "wrong type to apply #<syntax-transformer semver?>" step from partial recompilation of your tree

<jpoiret>either delete all .go files that contain "semver?", or just make clean-go

<jpoiret>stem * not step

<PurpleSym>jpoiret: It’s a fresh checkout.

<jpoiret>then it's very very weird

<jpoiret>anywhere i could check out the source of that branch?

<PurpleSym>It’s this one: https://git.sr.ht/~jlicht/guix/tree/local/npm-binary-importer

<banana-split>"~jlicht/guix: / - sourcehut git" https://git.sr.ht/~jlicht/guix/tree/local/npm-binary-importer

<PurpleSym>I’m trying wip-node-importer right now, which should be same/similar.

<jpoiret>ohhhh, right. Maybe there was a change to guile-semver that made semver? into a macro

<jpoiret>but here, semver? is being autoloaded, but since it's a macro that causes problems

<jpoiret>i'm not sure what the answer could be here, since i don't think autoloads would work well with macros, but you could surround the autoload call with (eval-when (compile expand eval) ...)

<jpoiret>that way the macro is also autoloaded at compile time (but again not sure that autoloads work with macros)

<PurpleSym>Well, wip-node-importer works, so I’ll stay clear of opening yet another side-quest.

<mekeor[m]>@lars:6xq.net: there is also a thread in the mailing list from zamzofex who managed to leverage esbuild to build npm packages. the code is here: https://gist.github.com/zamfofex/eac93bc0e00477a8b79f5ca4dc1a34ff

<banana-split>"npm importer for Guix · GitHub" https://gist.github.com/zamfofex/eac93bc0e00477a8b79f5ca4dc1a34ff

<PurpleSym>mekeor: Yeah, we need to do something about the whole JavaScript ecosystem, but it’s not always that easy (compare https://git.savannah.gnu.org/cgit/guix.git/commit/?id=44e1300994b783a758de7b3cf84287811ece5e80 which I packaged years ago)

<banana-split>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=44e1300994b783a758de7b3cf84287811ece5e80

<mekeor[m]>wow, that looks like a lot of code for a little package :/

<mekeor[m]>could banana-split stop re-posting the same url again?

<andreas-e>apteryx: I share your feelings about nss. It has been doing its checks forever yesterday.

<PurpleSym>Yeah, banana-split does not add any information right now.

<jlicht>PurpleSym: not quite sure how you ran that one; you just put it in your channels.scm file?

<jlicht>but thanks for your report! I think I'll be removing the last 2 issues I found, and then sending it in for review

<jlicht>I guess last 3 issues now, thanks :)!

<PurpleSym>jlicht: Just ran it from a built checkout.

<jlicht>did you run it in a `guix shell -D guix guile-semver`?

<PurpleSym>Yes, within guix shell -D guix guile-semver.

<PurpleSym>Something must’ve changed between wip-node-importer and your branch on sourcehut.

<jlicht>I'm rebuilding it in a fresh worktree right now, but fwiw, `semver?` is just an autoloadable procedure for me on a guile repl

<jlicht>PurpleSym: I just imported vue (with one manual intervention due to one of those existing issues I talked about to resolve a circular dependency), and it seems to work: `const vue = require('vue');` does things :-)

<elevenkb>hello there, I have a manifest file which works with `guix shell -m` but doesn't work in geiser.

<elevenkb>hang on there, i should probably run `guix pull` to see if that fixes stuff first.

<elevenkb>pls ignore me for now.

<PurpleSym>jlicht: Hm, I can’t get past vue-server-renderer, which depends on vue which depends on vue-server-renderer.

<mirai>apteryx: the mpd service always created an account

<mirai>but the old definition had a bug that ignored the user configuration field since it hardcoded the name and group to "mpd"

<mirai>don't use that service definition with your user account, it's not adequate

<mirai>it should get its own home shepherd service

<mirai>it can work with user-accounts but it has some pitfalls (read commit message 637a9c3b264fe8eb76b6ed9f104b635d95632be6)

<wdkrnls>Dear Guix, I am trying to submit a patch using `git send-email'. I got the following error.

<wdkrnls>DEBUG: .../IO/Socket/SSL.pm:1177: global error: Undefined SSL object

<lechner>wdkrnls / can you show your exact invocation, please?

<wdkrnls>Am I missing some important configuration in my .git/config?

<wdkrnls>git send-email 0001-gnu-Add-r-gpg.patch --to=guix-patches@debbugs.gnu.org

<lechner>i have always used a number, like -1, to designate the number of commits from the top. not sure the command takes a patch file

<wdkrnls>The man page suggests send-email "Takes the patches given on the command line and emails them out."

<wdkrnls>However, obviously something I'm doing is not right :p

<lechner>please try -1 on the branch

<lechner>also, you are blameless. our patch acceptance process is kind of narrow

<wdkrnls>no worries, I appreciate your guidance.

<wdkrnls>I ran `git send-email -1 --to=guix-patches@debbugs.gnu.org' and got the same error. The only difference was that the patch was stored under /tmp instead of being in the directory.

<gabber>wdkrnls: are you sure you are in a profile where the `nss-certs` package is available?

<gabber>without that your system is unable to establish TLS secured connections

<wdkrnls><guix-patches@debbugs.gnu.org>: host debbugs.gnu.org[209.51.188.43] said: 550

<wdkrnls>gabber: I am running in a profile where I can send other emails.

<wdkrnls>However, I usually send emails through mu4e.

<wdkrnls>This is the first time in a while I'm trying to send emails through git.

<gabber>i'm not sure that works the same way... can you fetch a https: site (through curl or wget)? (i am not a regular `git send-mail` user, though)

<wdkrnls>guix package --list-installed says that nss-certs is there :)

<gabber>good! more often than not with SSL (or TLS) errors it's that package that is missing (or a far-off clock)

<wdkrnls>I was successfully able to wget some guix artwork :)

<wdkrnls>I figure the issue must lay with git send-email

<lechner>did you get a subcode to the 550?

<gabber>another thing (since you `guix pull`ed to fix stuff earlier): guix pull only updates guix itself, not installed packages. you might want to `guix package -u` instead

<wdkrnls>I don't know precisely how to parse your question. This is the message under the line with 550 at the end of it: "Unrouteable address"

<wdkrnls>Is that what you are looking for?

<lechner>yeah

<lechner>i think i get that too (but in my own relay logs). it's for the CC. can you please post the patch header

<lechner>my submissions usually go through though

<wdkrnls>Subject: [PATCH] gnu: Add r-gpg.

<lechner>no cc?

<wdkrnls>No CC as far as I can see.

<lechner>is your sendmail program working, or do can you use your local port 25? swaks may be your friend

<apteryx>mirai: I've reported my mpd findings yesterday so we don't forget about it

<lechner>what's the From?

<wdkrnls>It's from me at the right email address.

<wdkrnls>I don't really know if sendmail is working. I have never used it on this machine.

<lechner>well, it looks like debbugs responded :)

<wdkrnls>However emacs sends mail works. That's all I know :)

<lechner>i am sorry you have to go through this. i personally find it an extreme burden to use git-send-email

<lechner>is this your first submission?

<wdkrnls>I appreciate your empathy :)

<wdkrnls>Its not my first submission. I have made a few before, but never really followed the rules :/.

<wdkrnls>I'm trying to make an effort to be better at that.

<wdkrnls>I feel like Guix is in a position to make the setup easier since it can define the needed software environment exactly.

<lechner>that's exactly what's happening

<lechner>too narrow

<nckx>gabber: This ‘550 unroutable address’ seems to be a (rare) thing that happens lately. There's nothing you can or need to do about it, it's not a problem or misconfiguration at your end. Just wait a while & a second attempt usually succeeds.

<lechner>wdkrnls / i am nobody around here, but i think you should just send the patch as an attachment, or perhaps try to paste it the way git-send-email does. there are too many other thing that get people discouraged about Guix, and about contributing

<nckx>I'll poke the GNU folk about it, but don't get any hopes up. Up hopes are ill-advised.

<wdkrnls>Networking seems like an inherently unreproducible voodoo art.

<gabber>nckx: thanks for the explanation! you might want to tell wdkrnls though ;)

<nckx>I think someone pinged them.

<lechner>it's probably the proprietary routers along the way!

<nckx>if (strstr(body, "GNU General")) drop_odds++;

<jlicht>the 550 stuff also happens if you add the debbugs.gnu.org domain

<jlicht>instead of guix-patches@gnu.org

<jlicht>(so yes, that was wrong in our manual for years, and still is on the non-development manual that one finds online in our git send-email example

<jlicht>I ran into this last week because I use a printed older version of our manual for reference, but it seems the online version also still has this issue

<nckx>Lord.

<lechner>on my relay, it's only for copies to the originator. the submission itself always goes through for me

<lechner>Hi, would it be fair to say that, in Guix, virtually every executable should be "wrapped" in its own prerequisite environment?

<nckx>I totally missed the wrong address above.

<nckx>jlicht: Thank you.

<lechner>wdkrnls ^

<nckx>ACTION orders new glasses.

<lechner>jlicht / thansk

<jlicht>I'm not quite sure where the address is still listed wrong right now

<nckx>It's not, but the fix might postdate 1.4.0.

<jlicht> https://guix.gnu.org/manual/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1 yes, here

<banana-split>"Sending a Patch Series (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1

<nckx>jlicht: https://guix.gnu.org/en/manual/devel/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1

<banana-split>"Sending a Patch Series (GNU Guix Reference Manual)" https://guix.gnu.org/en/manual/devel/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1

<nckx>Note the /devel/.

<nckx>I don't think I ever got consensus for dropping that strange old distinction. I'll try again.

<wdkrnls>jlicht: that may be a separate issue in my case. I definitely was sending it to the debbugs version since I read that in the manual. However, I just tried again with the @gnu.org version and still had the same error.

<singpolyma>lechner: somewhat, yes. The ideal is that they end up patched somehow to use references, but setting an environment that uses references is second best

<wdkrnls>I had no problem sending an email with the path as an attachment to the @gnu.org address though.

<nckx>wdkrnls: Can you paste.d.n the full output of the failing (but correctly-addressed) git-send-email output?

<lechner>singpolyma / is there any way to get patching to work with Guile scripts? There are -L and -C. Can they be used together with the "meta switch" to avoid the shell wrapper? https://www.gnu.org/software/guile/manual/html_node/Command_002dline-Options.html

<banana-split>"Command-line Options (Guile Reference Manual)" https://www.gnu.org/software/guile/manual/html_node/Command_002dline-Options.html

<lechner>wdkrnls / or you can push the repo somewhere, and i can mail it in for you

<wdkrnls> https://paste.debian.net/1271089/

<banana-split>"debian Pastezone" https://paste.debian.net/1271089

<singpolyma>lechner: I expect there is some way to set load path programmatically in guile? So you could insert lines to do that rather than use env vars. That's not quite using references in the full way but guile imports are never by path so it may be the best one can easily do

<gabber>wdkrnls: did it work now?

<lechner>250 means it went through, didn't it?

<gabber>and it says "OK." (line 4)

<nckx>Yeah.

<nckx>250 is good.

<gabber>\o/

<bjc>guile uses the ‘%load-path’ variable for module lookups

<nckx>wdkrnls: So to recap, first @gnu.org attempt failed (550), second (identical?) @gnu.org attempt succeeded?

<nckx>Is that correct?

<jlicht>I got an answer with "Undelivered Mail Returned to Sender" later, send-email always 'worked'

<jlicht>(so the 550 for me only happened later)

<wdkrnls>I guess the 550 was what I got in my email inbox.

<nckx>I still thinks that part's non-deterministic.

<nckx>wdkrnls: From whom? (Which server?)

<lechner>i get it every time, for the cc

<jlicht>I receive it from my smtp server: https://paste.debian.net/1271090/

<banana-split>"debian Pastezone" https://paste.debian.net/1271090

<wdkrnls>from my email provider: posteo

<wdkrnls>the last send I did must have gone through.

<nckx>jlicht: Thanks, but I'm going to disregard @debbugs. failures here.

<jlicht>is this banana-split the issue bot under yet another name? I think it can safely ignore pastebins :)

<nckx>I'm interested in ‘correct’ @gnu.org failures.

<nckx>wdkrnls: Could you share it? It contains nothing *I* wouldn't mind sharing publicly, but if you're more concerned about such things and want to mail it to me privately I'd be much obliged.

<nckx>Especially if it contains the original undeliverable patch as an attachment, so we can see exactly what git sent.

<nckx>ACTION away a bit.

<wdkrnls> https://paste.debian.net/hidden/f57a037d/

<banana-split>"Debian Pastezone" https://paste.debian.net/hidden/f57a037d

<wdkrnls>hopefully that doesn't have keys to my bank account in it :p

<lechner>wdkrnls / did you get that message for your otherwise successful submission?

<nckx>wdkrnls: Thanks. This message is still about guix-patches@debbugs.gnu.org, so I think it just arrived later than you expected & confused matters.

<nckx>If you didn't get any such messages about @gnu.org, I think you're good.

<nckx>And considering you opened two bugs, I think we are 😉

<lechner>you do not need new glasses. i do

<nckx>I happen to have a pair for sale, very good price.

<nckx>ACTION merges the bugs.

<gabber>magic glasses?

<wdkrnls>nckx: no, I don't believe so. I only got it twice.

<nckx>X-ray spex. See right through those pesky bugs.

<wdkrnls>jlicht might have been right, after all. It could just have been the debbugs@gnu.org.

<nikita>hi. with reagrds to patches, if I take some of yours to address issues in pkgsrc. since there are no names other than in the log, how would you prefer to get attribution, if at all? just 'taken from GNU Guix'?

<nckx>I'll conveniently assume that was the only problem, since it's less spooky & less work :)

<nckx>Hi nikita, long time no see! It's not legally required, but a nice gesture. Most of our patches are themselves taken from elsewhere, though. I try to add the source when I do so but it's not common.

<nikita>ok, thanks :) yeah. same, I don't always remember it, but when I do I think credit where credit is due, even if it's just the source where I found it

<nckx>In short, a nod to Guix would get you a smile but don't feel obligated.

<nikita>some parts of python (pypi i think) started to not ignore source_date_epoch anymore, and now a little bit more reproducibility has moved up in my todo list. trying to remember how other sys pms do the whole 1980 instead of 1970..

<nikita>i hope to get pkgsrc to some more level of reproducibility in the next years, but it's a long project, and life and work happens.

<nckx>1980 instead of 1970?

<nckx>Is that a new ‘standard’?

<jlicht>PurpleSym: Yeah, the handling of peerDependencies is one of the bugs still left. The other 'issue' is dealing with npm scopes. @vue/server-renderer is impacted by both :-)

<nikita>the whole 'zip file have to have this date' issue in pypi before 3.8.. I wsa confused that it appeared in 3.10 (unless I looked at the wrong build log) with just source_epoch_date set

<nckx>OK, zips… yes, now this rings a bell.

<jlicht>PurpleSym: https://paste.debian.net/1271092/ in case you need it right now

<banana-split>"debian Pastezone" https://paste.debian.net/1271092

<nckx>lechner: What's with these random nicks? They don't seem to appear in the code. Are they, er, permanent?

<lechner>no, they are evolving. and they are not truly random. the bot is finding itself.

<mirai>apteryx: strange, does mixer none really not work?

<mirai>afaik, null and none are different mixers

<mirai>per mpd docs, "mixer_type hardware|software|null|none"

<lechner>nckx / i am hoping to brighten someone's day (and to evade any attempts to ban the poor fellow)

<nckx>:)

<nckx>Has the latter happened?

<lechner>no, but i still have hopes about the former

<lechner>local desserts or sandwiches would be welcome suggestions

<nckx>‘smos-hesp’ just doesn't have the same ring to it.

<lechner>i'd prefer Oliebollen or so

<nckx>We are not as cultured as our Northern friends.

<jlicht>ACTION agrees

<jlicht>;)

<nckx>Shut up, oliebol.

<lechner>i was worried that it was from the other region

<nckx>(☺)

<florhizome[m]>hey guix

<florhizome[m]>i heard core-updates is due soon, so i wanted to check it out... i jave been waiting for some updates for pretty long now... but guix pull fails with clisp. the build log says the tests are failing.

<nckx>Perfect, now's the time to fix or report such bugs. There's a <https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00106.html> megathread.

<banana-split>"Merging core-updates?" https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00106.html

<gabber>what does "due soon" mean wrt core-updates?

<lechner>this is for the statue of liberty #55555

<mille-feuille>"28.1; Tramp prompting for password even with an existing .authinfo.gpg file" https://issues.guix.gnu.org/55555

<florhizome[m]>also i discovered a discontinuity or idk how to say: if channels.scm gives a guix branch as well as a commit, and the branch doesnt contain the commit, this is ignored and guix just pulls from the commit. as a user when i clarify a branch i expect guix to at least try to pull from there

<nckx>gabber: Mainly that florhizome[m] is an optimist. There is no schedule, just an intention to fix failures (currently in the bootstrap area AFAIK) and get things merged.

<nckx>With some luck, it will be several weeks, but there's no timeline.

<florhizome[m]>i am just copying what i read on fedi

<gabber>do i understand right that we patch (big) stuff on core-updates and when we're done we flop it onto devel/master and we restart the cycle?

<florhizome[m]>but yeah i am keen on some updates, mostly concerning graphics

<nckx>florhizome[m]: What do you mean by ‘clarify a branch’? That doesn't make sense to me.

<nckx>I discussed this with GNUtoo yesterday, but it was in the other direction, i.e., a suspicion that a valid ‘--branch’ could override an explicit ‘--commit’. I haven't tested further though, it's expensive here.

<AwesomeAdam54321>Has anyone ever had problems with pre-inst-env? It fails for me

<nckx>Are you in a ‘guix shell -D guix’?

<florhizome[m]>when i give a branch specification

<florhizome[m]>nope

<florhizome[m]>i havent tested it on the cli

<nckx>A commit is more specific than a branch. I did suggest warning when both branch & commit are given though, since the combination is never sensible (at best redundant).

<AwesomeAdam54321>nckx: yes, but it reports that the package isn't found

<nckx>‘The package’?

<AwesomeAdam54321>nckx: A package I added to my local copy of guix

<nckx>florhizome[m]: I.e., more explicitly enforce the documented ‘or’ rather than silently picking one.

<florhizome[m]>nckx can we test if branch and commit match?

<nckx>That sounds expensive and dubious to me?

<nckx>Why would we?

<nckx>AwesomeAdam54321: What does ‘guix shell -D guix -- ./pre-inst-env guix describe’ print?

<nckx>florhizome[m]: Stepping back: what is a use case for specifying both branch & commit?

<florhizome[m]>i think just letting guix pull run with a potentially wrong assumption is more expensive

<AwesomeAdam54321>nckx: The guix-android 86afb98 channel and guix fd7f845 (my local copy) are used

<florhizome[m]>honestly i think its a rare usecase so it wouldnt need to be checked most of the time

<nckx>florhizome[m]: I agree in the sense that it should warn (maybe even error out?) when both are given, but don't understand when ‘--branch=A --commit=B’ is ever useful compared to just ‘--commit=B’.

<nckx>I.e., I don't see the use case at all, rare or otherwise.

<florhizome[m]>basically i just got the commit value in because i copied from the output of guix describe

<nckx>There's no such thing as ‘user: give me commit B’ ‘git: OK, but which commit B do you mean? the one from branch A?’

<nckx>AwesomeAdam54321: That doesn't sound right.

<nckx>AwesomeAdam54321: What's ‘guix shell -D guix -- ./pre-inst-env which guix’?

<florhizome[m]>well what would we need to do?

<florhizome[m]>can we check if the user specified both fields?

<nckx>That's my suggestion. To warn if they do. ‘warning: You specified both a branch & a commit; branch will be ignored’ or so.

<florhizome[m]>everything else would be optional

<AwesomeAdam54321>nckx: /home/adam/guix/scripts/guix

<nckx>Bah.

<nckx>AwesomeAdam54321: Could you share (paste.debian.net) the actual ‘describe’ output above?

<nckx>florhizome[m]: I'm not sure what that last message means.

<florhizome[m]>maybe its debatable if guix describe -f channel needs to contain commit, too

<nckx>Do you mean branch?

<nckx>Commit is essential to its purpose.

<florhizome[m]>no

<florhizome[m]>whats the purpose

<florhizome[m]>for scripting it might be unnecessary

<florhizome[m]>i guess debugging

<nckx>To give an unambiguous specification of all channels in use.

<AwesomeAdam54321>nckx: https://paste.debian.net/1271098

<mille-feuille>"debian Pastezone" https://paste.debian.net/1271098

<nckx>Thanks.

<florhizome[m]>i think there could be guix describe --verbose and not verbose

<florhizome[m]>but idk

<nckx>If you're feeding the output of ‘guix describe’ into a script, that's fine, but it's your responsibility to remove fields that break your script/use case.

<nckx>Not Guix's.

<florhizome[m]>back to topic: if there is a "low cost for everyday use" way of letting guix fail when branch and commit don't match" i think its preferable but your suggestion is better then the status quo

<nckx>AwesomeAdam54321: The reason I'm confused (‘Bah.’) is that your env'd guix should not print other channels at all: https://paste.debian.net/plainh/0751c50e

<mirai>any idea on how to stop a herd service from another? <https://paste.centos.org/view/d10f12a8>

<mille-feuille>"Untitled - Pastebin Service" https://paste.centos.org/view/d10f12a8

<nckx>florhizome[m]: I don't know what ‘branch and commit matching’ means, sorry.

<florhizome[m]>if a commit is on the specified branch

<AwesomeAdam54321>I wrote a file ~/.config/guix/channels.scm with the guix-android introduction, could that be the problem?

<andreas-e>florizhome[m]: I just built clisp on the core-updates branch and did not see a problem.

<florhizome[m]>tbh this might just be a case of guile-git being a bit unrefined

<florhizome[m]>andreas-e well for me it failed when guix pulling

<nckx>That's the same effect as ignoring branch. So you're computing ancestry only to trigger or skip a fatal error, and I think that's too confusing.

<nckx>For no change in behaviour from my suggestion.

<nckx>AwesomeAdam54321: I don't think so, but you could try moving it out of the way to test.

<nckx>AwesomeAdam54321: I don't really know what's going on. Is fd7f8452f82176b2c717c217e6df050f228fd579 the tip of your /home/adam/guix?

<mille-feuille> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fd7f8452f82176b2c717c217e6df050f228fd579

<nckx>…no.

<AwesomeAdam54321>nckx: Yes, it's the tip

<florhizome[m]>nckx: not sure if we need to compute ancestry

<nckx>So the commit returned by ‘guix described’ contains the package that this very same guix is claiming not to see when you ‘guix build’?

<lfam>Sorry to barge in, but when pre-inst-env doesn't reflect your changes, it usually means that the checkout is no longer configured properly. For example, you might have configured and built the checkout, and then garbage collected the dependencies. Make sure you re-configure and re-build the checkout

<nckx>This has happened to me, but Guix always warned.

<parsnip>#emacs expects users to be able to test emacs with no configuration via `emacs -Q`

<parsnip>but apparently packages are available in emacs -Q, on guix

<parsnip>it seems guix is breaking a contract

<AwesomeAdam54321>nckx: The package I'm working on isn't committed, but I expected ./pre-inst-env to reflect the changes

<nckx>Yes, it still should.

<parsnip>this is exacerbated by how difficult it would be to test someone's guix setup without installing it on metal

<florhizome[m]>the question would be if guile-git is capable of giving me the branch information of a given commit

<florhizome[m]>gits cli can

<apteryx>parsnip: I don't think Guix packages are supposed to be available without -Q ? At least they are not autoloadeded.

<apteryx>*autoloaded

<apteryx>*with -Q

<parsnip>okay, pkal is clarifying on #emacs, maybe, that `emacs -Q` on guix, would be similar to as on debian

<apteryx>parsnip: welcome, by the way :-)

<jlicht>florhizome[m]: a commit has very little to do with a branch. You can even have commits that are not part of any branch :-)

<AwesomeAdam54321>lfam: I'll try that, before this I did that without doing `make clean` beforehand

<lfam>Okay. Also, make sure you use a pure environment / shell

<lfam>When configuring and building, that is

<lfam>You don't need to `make clean` for this

<lfam>Finally, it could help if you shared your code changes. It's possible they are malformed

<apteryx>jjjjjxiiiej.bxbydtbu.cpc.xencbcibhcuxctujgtc

<nckx>Access granted.

<apteryx>bah. my daily rubbish post.

<lechner>nice password

<rekado>apteryx: IIRC you can disable the OTP feature

<rekado>I never used it other than to spam #guix

<apteryx>oh? I'd be interested knowing how

<rekado>gotta go now, but I think there was a yubikey personalization tool that can be used to enable GPG support and — IIRC — disable the OTP thing

<rekado>(I never actually managed to finish setting up my yubikey…)

<apteryx>there's now a cookbook entry for it

<apteryx>the basics are easy

<apteryx>just a package providing udev rules for mine

<florhizome[m]>jlicht maybe but here we deal with repositorys, is that distinction still practical?

<jlicht>florhizome[m]: I mean, what does it _mean_ to ask for a commit + branch?

<lfam>To git, it's incoherent. From a human point of view, I'd take it as a kind of sanity check. "Use this commit, on this branch, and error out it that's not possible"

<lfam>But, we have to decide if we want to add this kind of layer on top of Git

<jlicht>ACTION has been Stockholmed to much by git

<jlicht>s/to/too

<lfam>Heh, whether it's good or bad, it's what we've got

<nckx>Since this is a ‘fact about the world’ that we'd have to compute at each run, I'd rather just warn [or error out if someone feels strongly] when a branch + commit are given, that branch is ignored, and do so consistently.

<mirai>rekado: what's this OTP used for

<lfam>Well I certainly don't feel strongly about it

<nckx>jlicht: I've been to Stockholm, it's cosy! Or is that—oh no.

<lfam>Lol

<andreas-e>Would it not be easier to drop the --branch parameter, and to allow a branch name after --commit? Assuming it would mean the commit at the current tip of the branch.

<andreas-e>More understandable, I mean by easier.

<lfam>That would be more Git-like. Rather than commits and branches, it's all just references

<AwesomeAdam54321>andreas-e: Is there a risk that a branch name is the same as a shortened commit ID?

<andreas-e>That would be the same situation as with "git checkout", then, so we can claim it is not our problem ;-)

<lfam>I was about to say the same

<florhizome[m]>basically i think: if branch is specified, prefer branch information to determine the commit, if commit is also specified, check if its the same as the one returned by the above operation

<lfam>We might be getting too deep here

<mirai>and has anyone gotten yubikey to work for SSH behind a SSH session? (that is, USB plugged to host1, host1 SSH to host2, host2 SSH to host3, host3 also wants to use the sk-ed25519... from the yubikey in host1)

<lechner>is that not a bit like adding the country name to an ISO 8601 timestamp

<nckx>andreas-e: What prompted this [today, not yesterday] was the Scheme interface and ‘guix describe -f channels’, not the CLI.

<andreas-e>Yes, lfam, I am also for simplification.

<nckx>Is this more accurately called a ‘ref’ then?

<andreas-e>git is all black magic to me, so I would not know. But it is good to have consistent black magic :-)

<florhizome[m]><andreas-e> "florizhome[m]: I just built..." <- how can i test this better? guix shell -D guix -- guix pull --allow-downgrades?

<andreas-e>florizhome[m]: I did a git clone, git checkout core-updates, build, then ./pre-inst-env guix build clisp.

<lfam> https://git-scm.com/book/en/v2/Git-Internals-Git-References

<mille-feuille>"Git - Git References" https://git-scm.com/book/en/v2/Git-Internals-Git-References

<nckx>andreas-e: Right, that's why I'm hesitant to call it ‘commit’ in our CLI. But I like your underlying idea.

<nckx>(thing "master") ; ship it

<florhizome[m]>i am just asking myself if commits are actually bidirectionally distributed over whatever git is using as storage references (i guess some hash)

<florhizome[m]>so there is a unique commit to each object in a repository

<jlicht>object ids (oid) are hashes, indeed

<jlicht>and commits reference a tree, and a tree references these oids :-)

<AwesomeAdam54321>I solved the problem I was having

<AwesomeAdam54321>Running make should fix it, but fails when building the translations/documentation

<AwesomeAdam54321>so instead I have to call the targets manually: make make-go && make guile && make scripts/guix

<nckx>I've had to manually touch(1) some translated files to make the build succeed (empty files are fine, apparently) but it's been a while.

<nckx>Pity it's still a thing.

<AwesomeAdam54321>nckx: Can you review this patch? https://issues.guix.gnu.org/59355

<mille-feuille>"[PATCH] gnu: Add dataparksearch." https://issues.guix.gnu.org/59355

<nckx>OK.

<nckx>It looks like it's pushable with a few smol modifications, if so I'll do so.

<andreas-e>What is the idea behind the pâtisserie robot?

<andreas-e>(Except for making us hungry, of course. I am almost through my Belgian chocolates.)

<nckx>ACTION giggles, evilly.

<nckx>ACTION opens another box.

<mirai>I think the naming is cool

<Lumine>Sadly I wanted to get chocolate today, but I'm settling for coffee

<nckx>lfam: I just saw your mail. Have you been able to access any useful info that isn't behind a loginwall?

<lfam>About NSS?

<nckx>Yes, sorry.

<lfam>I'm hoping to crowdsource this one

<lfam>Debian claims to have fixed it with 3.87.1

<lfam> https://security-tracker.debian.org/tracker/CVE-2023-0767

<mille-feuille>"CVE-2023-0767" https://security-tracker.debian.org/tracker/CVE-2023-0767

<nckx>So if my glasses work now, 3.88 is still vulnerable, so no point in updating to that.

<unmatched-paren>hello guix :)

<mirai>when can a 'define' happen within a #~(begin ...) ?

<unmatched-paren>mirai: anywhere, really

<unmatched-paren>same as in a regular (begin ...)

<unmatched-paren>i'd think

<mirai>huh

<mirai>??

<mirai>strange

<mirai>I swear I used to get some funky error

<unmatched-paren>#~(begin (define foo 32) (do-stuff-with foo)) should work

<unmatched-paren>if you put a define at the end you'll probably end up with a gexp returning #<undefined> or something, but still

<mirai>strange, I can't remember the exact error name but it had to do with some illegal form or syntax

<mirai>but you're right, it's working in a repl now

<mmarshall540>I prepared a patch to add a package (mairix), but I'm getting hung up on building for another architecture, as described at Step 6 on this page: https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html. The build succeeds for x86_64-linux, i686-linux and aarch64-linux. But when I try building for armhf-linux, the "check" phase fails. I'm not sure if it's crucial that it work on armhf, but Debian apparently has an a

<mmarshall540>for this package. So I feel like it *should* work. Just not sure what my next step should be.

<mille-feuille>"Submitting Patches (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

<lfam>Interesting. I've gotten phishing spam about my subscription to guix-commits. Weird that it might be known if I subscribe to it or not

<nckx>I don't mean to worry you more, but I haven't.

<nckx>ACTION is testing the NSS graft.

<apteryx>yay! USB device redirection working as my user with GNOME Boxes

<apteryx>nckx: 3.88.1 fixes it

<apteryx>I could apply the nss-next patch I have in the https://issues.guix.gnu.org/32026#49, but that won't fix the main nss package

<mille-feuille>"IceCat locales are missing?" https://issues.guix.gnu.org/32026#49

<nckx>Hence the need to graft?

<apteryx>lfam, nckx either 3.79.4, 3.87.1 or 3.88.1 have the CVE-2023-0767 fixed (see: https://bugzil.la/1815980 or https://bugzil.la/1815979 or https://bugzil.la/1815978)

<apteryx>but our nss is at 3.81, which is not one of the above... hm

<apteryx>so we probably need to backport the patch

<apteryx>(and graft)

<nckx>Yes.

<nckx>So you want me to try grafting an updated nss-next instead?

<nckx>I can try that. Mozilla says it should work, I was just being cautious.

<apteryx>no, sorry for jumping in out of context, I'm just delivering what I know about that CVE

<apteryx>grafting a different version sounds risky, no?

<nckx> https://firefox-source-docs.mozilla.org/security/nss/releases/nss_3_88.html#mozilla-projects-nss-nss-3-88-release-notes

<nckx>‘Compatibility’

<nckx>It's always risky.

<nckx>I'm just saying that Mozilla considers it supported. We won't know until people run things.

<nckx>apteryx: Context is I'm grafting a patched version of our current core nss package. I didn't update anything. Well, now I did, to 3.88.1 since that's what you seemed to prefer.

<apteryx>well, if it works with graft of nss-next, that may be the best option to squash all CVE we may have missed

<apteryx>but I'm far from a graft expert so don't take my advice seriously

<nckx>Yes, applying a single patch always makes me nervous, especially since they're being a bit coy about it being a CVE fix.

<nckx>But then so does grafting a large version bump, so it's 50/50.

<lfam>That really depends on the project and carefully they manage their ABI

<lfam>How carefully

<nckx>It depends on your trust of Mozilla is what I'm saying.

<nckx>I think mine is higher than average around here.

<Kabouik>I think I have DNS server problems when I am at work, where things are not as dynamic as on my home connection. Where should I look in Guix to check if the nameservers are correct? I do see the work DNS listed in /etc/resolv.conf but I honestly don't know where they come from and whether they are taken into account by Guix, since I didn't specify anything dns-related in my config.scm.

<nckx>If you use a network manager (like, er, NetworkManager) it will manage your resolv.conf and other settings based on what the current network tells it (DHCP, including DNS servers).

<nckx>I think some DHCP clients do this too.

<Kabouik>Ok, so that's probably what populated /etc/resolv.conf accordingly when I'm on the local network here. But somehow I still have an issue resolving sites when here: most sites take 5 to 15 sec to resolve, and some just don't (I was next to someone in the office, he could reach a local Synology application that I cannot reach; no IP filtering in place).

<Kabouik>(I can reach it when I use the domain.tld:port while he could join it with domain.tld/chat.

<nckx>That :port difference just looks like caching, no?

<Kabouik>Could be indeed, let me try with a private browser window.

<nckx>DNS doesn't deal with ports at all (as you probably know, but…)

<nckx>The nss test suite is interminable…

<Kabouik>(I was not sure, but thanks!)

<Kabouik>Well weirdly /chat still doesn't work in a private window, but you kind of reassured me that the issue might not be config.scm-related.

<nckx>I'm not saying there's no issue, just that the :port & /chat difference looks like a red herring, both happening (far) above the DNS layer.

<nckx>If you use ‘drill @RESOLVER-IP domain.tld’, does it return something sensible, immediately?

<nckx>That's in ldns:drill by the way.

<nckx>If you already have dig, same thing.

<mirai> https://test-ipv6.com/

<mirai>the delays might be caused by broken ipv6 connectivity

<nckx>…this is going to be the best-tested nss ever… \o/

<Kabouik>That big red 0/10 is being a bit harsh on me. https://0x0.st/Hr7U.png

<nckx>That's only a problem if something thinks you do/should have IPv6 and tries it anyway.

<Kabouik>I think we are sitting on a huge ipv4 block here that we could sell a fortune to buy me a villa by the seaside, we probably only use v4

<nckx>I'll post your e-mail address on legitimate-marketing.ru, someone will be in touch shortly.

<apteryx>GNOME Boxes users may be interested in trying/reviewing #61576

<nckx>When you say ‘most sites take 5 to 15 sec to resolve’, what's that based on?

<nckx>Specifically that it's the resolution that's to blame for the delay?

<Kabouik>Unfortunately I'm not in the IT team nckx, can't smuggle any ipv4 block with a special discount to the folks at legitimate-marketing.ru.

<nckx>ACTION badly underestimated how long nss would take to build, needs to AFK a bit.

<Kabouik>It's hard to tell nckx, I haven't found the pattern yet. Also I usually just hibernate at the end of the day and resume the next morning, and sometimes the resolving times look fine (I don't notice any), sometimes they don't look fine, without me rebooting.

<apteryx>nckx: do you want me to push "gnu: nss-next: Update to 3.88.1 [fixes CVE-2023-0767]" to master already?

<apteryx>I've already tested building it

<Kabouik>It could be that the delay is not due to resolution indeed, that's just me cutting corners here actually.

<mirai>Kabouik: have you tried troubleshooting the "real issue

<Kabouik>All I know is colleagues don't experience that, and I don't experience that with the same machine at home.

<mirai>that is, proper ipv6 connectivity

<Kabouik>I haven't. Is that something I should do on my machine? I thought it just had to do with the work network and the way the people in charge of it set it up.

<nckx>[mobile] apteryx: You already had a fix? What am I doing here then?

<apteryx>I'm just adding nss-next, it's not a proper fix

<apteryx>rather, updating nss-next

<apteryx>I'm not touching grafting 'nss' itself

<nckx>Well, that's about 50% of my patch, with the whole cherry-picked patch approach dropped.

<apteryx>that's the harder/riskier 50%

<nckx>(I did both at once, update + graft, since that falls under the 'no broken intermediate state' in my head, but that's a pretty quirky interpretation.)

<apteryx>OK! Sounds like you've got it covered then, nevermind :-)

<nckx>[back] I'm starting to wonder if this test suite run is stuck in some strange loop. Output is sus.

<apteryx>it takes a silly amount of time (hours?)

<nckx>Oh no it's just a hug matrix of every single parameter you can imagine. Currently testing DES 👍

<nckx>apteryx: Oh jeez.

<nckx>*huge matrix

<nckx>I need a hug matrix now.

<nckx>‘Password encryption with MD5 and DES-CBC’ I'm not a cryptographer but all 3 of those are terrible words.

<nckx>apteryx: Feel free to push, it's frustrating but you got there first. This is a different derivation (version "3.88" to allow grafting) so I'll still have to wait for it to finish.

<rdrg109_>attempt no. 14 of installing guix in my laptop: "Operating system not found" still being shown when booting even after getting to the successful installation message at the end.

<rdrg109_>I've tried different options during the installation process that I've come to think this have to do with my laptop instead of an issue with the installer

<nckx>That's not even GRUB.

<nckx>Yeah, or at least some assumption made during the installation (by you or by the installer) that isn't right.

<nckx>My first guess is: this is not a UEFI boot?

<apteryx>nckx: pushed with a humorous git tag

<nckx>\o/

<nckx>Thanks.

<nckx>(I'll read it later :)

<rdrg109_>I've been using the guided graphical instlalation so far (i.e. haven't tried the manual installation yet). I guess I'll play with the options of the manual installation until I hit the nail.

<nckx>rdrg109_: Honestly what I'd recommend, if only to get some insight into what's happening.

<rdrg109_>nckx: In the BIOS configuration options of my laptop, it shows "Boot Mode: UEFI", so I guess that's a "yes" to the question: "Is this a UEFI boot?". Am I right?

<nckx>Hmm, it should be :)

<nckx>It could still be falling back to ‘BIOS’ (‘CSM’) mode.

<nckx>Do you have any idea what the partition layout generated by the installer looked like?

<rdrg109_>nckx: I can check it. I'll boot using the shell-based alternative, execute "lsblk" and share the output with you. Give me some minutes please.

<nckx>apteryx: ♥

<nckx>rdrg109_: Thank you! Take all the time you need. This is a very frustrating thing to debug over a text network connection. I'll try to be as systematic and clear as my addled brain is capable of.

<nckx>What appears to be happening so far is that your firmware, whatever mode it's in, is not even finding the boot loader (GRUB). Which is… rare, to say the least.

<nckx>The message is too vague to tell us more. A quick Web search implied it was a BIOS-mode message, but that might just as well be people calling everything early ‘BIOS’.

<rdrg109_>nckx: output of "lsblk": http://0x0.st/Hrhs.txt

<rdrg109_>Tell me which other command I'd need to execute. I already sshd into my laptop, so executing command and sharing them through 0x0.st is now faster.

<lechner>rdrg109_ / what kind of laptop do you have?

<lechner>also, did you install Guix while in EFI mode?

<nckx>rdrg109_: ‘fdisk -l /dev/sda’, then, if it's that easy, and whether ‘/sys/firmware/efi’ exists :)

<rdrg109_>lechner: Sony Vaio SVS15152PLB

<lechner>i think we can get this booted

<nckx>So you're currently SSH'd into the Guix installer? Or something else?

<rdrg109_>nckx: Yes, I've SSH'd into the GUIX installer.

<nckx>Nice.

<lechner>did you partition with gdisk or fdisk?

<rdrg109_>lechner: I partition the disk using the terminal graphical installation with default options.

<rdrg109_>nckx: ok, I'll execute those commands.

<rdrg109_>lechner: Pardon my ignorance, I don't know what is "EFI mode". I just plugged the USB and followed the steps in the graphical installation.

<lechner>you can boot the USB two ways

<nckx>rdrg109_: Also, when done, could you mount your root partition (I'm guessing that's /dev/sda3) and share its /etc/config.scm, which I really bloody hope exists.

<lechner>do we have a problem in our installer?

<nckx>Which ‘way’ you've booted can be tested by the presence or absence of ‘/sys/firmware/efi’.

<nckx>lechner: I'm starting to feel that way recently.

<lechner>we should really create both an EFI and a BIOS boot partition each time

<nckx>If my memory were better I'd be sure but something fishy happened a few weeks ago IIRC.

<lechner>maybe we are missing an error from group-install\

<bjc>aren't there possible issues with gpt disks with bios?

<lechner>not in linux

<bjc>it's a bios thing

<lechner>nckx / you and i are thinking about the same case, but it was a different kind of laptop

<bjc>linux doesn't figure

<lechner>winblows does

<mirai>I believe we're one step closer to solving the problems with 'networking shepherd service... but this looks absolutely horrendous <https://paste.centos.org/view/4904ded5>

<bjc>iirc, older bioses can't read gpt disks, while efi requires gpt, so there are at least some configurations where they can't coexist

<nckx>bjc: Right, except that was the line 20 years ago (I'm not exaggerating).

<nckx>‘Some ancient BIOSen…!!!’

<nckx>If they were ancient then…

<lechner>maybe 15 years

<mirai>bjc: how prevalent are these 'old systems'

<bjc>efi barely existed 20 years ago

<mirai>will they even power up?

<lechner>i have one

<rdrg109_>nckx: output of "fdisk -l /dev/sda" and check /sys/firmware/efi: http://0x0.st/Hrh8.org

<mirai>are they expected to be used or is this an academic exercise

<nckx>Eh, you're right, 1.5 decades, not 2.

<lechner>let's mount the EFI partition

<nckx>OK, so you're booted in UEFI mode (good), and you have an ESP (good). That's two bad possibilities eliminated.

<nckx>And the installer chose GPT which is also sane.

<nckx>I'm going to place my bets on nvram now.

<lechner>we should give everyone rEFInd, too

<rdrg109_>nckx: output of cat /mnt/etc/config.scm (located in /dev/sda3): http://0x0.st/HrhP.org

<nckx>rdrg109_: If you mount your ESP (/dev/sda1), you should find EFI/grub/grubx64.efi or so. I forget the exact name, but very similar.

<rdrg109_>nckx: Let me check

<nckx>It might be EFI/guix, I don't have a system to check.

<bjc>it'd be /boot/efi/EFI/Guix/grubx64.efi

<lechner>it's EFI/Guix/grubx64.efi

<bjc>the stuff in /boot/grub is for after grub has loaded

<rdrg109_>nckx: output of "$ find" in /dev/sda1: http://0x0.st/HrhZ.txt

<GNUtoo>Can SeaBIOS read GPT and use ef02 partitions?

<nckx>rdrg109_: Perfect. Now, mkdir

<nckx>Grr.

<nckx>* mkdir /mnt-sda1/EFI/BOOT

<lechner>the removable media path

<nckx>and cp /mnt-sda1/EFI/Guix/grubx64.efi /mnt-sda1/EFI/BOOT/BOOTX64.EFI

<rdrg109_>nckx: Done, this is what it looks like: http://0x0.st/HrhN.txt

<nckx>bjc: That stuff won't be on the ESP anyway, so won't get in the way here.

<GNUtoo>ACTION also wonders if there are x86 computers where people can't disable UEFI "secure-boot"

<lechner>GNUtoo / the partition type should be ef00

<bjc>i have that on my esp. how else is grub supposed to read its grub.cfg?

<nckx>Magic.

<bjc>my esp also lacks BOOT, which i find weird

<nckx>rdrg109_: If everyone agrees that looks correct, let's gracefully unmount all sda partitions and reboot. (Not from the installer this time.)

<GNUtoo>Since there is no more MBR, ef02 is a partition to be able to embed RAW GRUB inside a partition

<rdrg109_>nckx: Ok, I'll try that

<GNUtoo>I'll try to find the name of that

<nckx>bjc: It's the normal state with Guix and AFAIR most other distros, although I'm a bit less sure about the latter for obvious reasons :)

<nckx>It doesn't clobber \boot but also doesn't create it if it's not there.

<lechner>GNUtoo / ef02 is only for Bios boot, as far as i understand

<GNUtoo>yes

<GNUtoo> https://en.wikipedia.org/wiki/BIOS_boot_partition

<lechner>i am not sure it applies here

<GNUtoo>Though maybe I should just try to see if that works

<nckx>GNUtoo: ‘ef02’ is a tool-specific name (gdisk?), not universal.

<GNUtoo>Yes, I was more asking for my use case, because I use SeaBIOS

<nckx>The BIOS doesn't read it or care about it.

<lechner>it still uses the MBR

<rdrg109_>nckx: It booted. Thanks! :) Now I'm wondering if this is a bug in the installer so that it gets fixed. I wish I had known this 6 months ago. It was the only reason that stopped me from using Guix at that time.

<GNUtoo>I tested it under an UEFI laptop (X230) with a nonfree UEFI and CSM and it worked

<nckx>rdrg109_: No, it's not that simple.

<lechner>rdrg109_ / your setup is not done yet. you should fix your EFI variables

<rdrg109_>I can give as much details as possible (even trying the installation again) in order to get this issue fixed.

<rdrg109_>ah ok

<nckx>The new name is a work-around, it's not ‘more correct’ or ‘a fix’.

<nckx>It's just the default name that your firmware will look for. You *should* (this is the standard) be able to tell your firmware to load anything, though, and Guix does this.

<nckx>It call efibootmgr to add a boot entry to the nvram.

<nckx>Clearly this failed, and the installer should definitely catch that.

<lechner>is it still called efibootmgr ?

<nckx>ACTION shrugs, dunno.

<nckx>rdrg109_: But why it failed is the real bug here, and we don't know yet :)

<lechner>the efivars module changed to efivarfs recentlu, i think

<nckx>Poss.

<lechner>extra f

<rdrg109_>lechner: what do you mean with "you should fix your efi vaariables"? Is there a page/info node that documents this?

<bjc>does the installer not install the grub directory in the esp? i'm wondering if it broke halfway through or something

<lechner>you are currently using the "removable media path"

<nckx>Now, Guix triggers efibootmgr [substitute whatever new name there might be, although I don't see why efivarfs would be related] failures a lot more than other distroes. The reason could be simple: we call it a lot, at every reconfigure by default, so more chance to run into errors or firmware bugs. But it could be something more insidious, or both.

<nckx>rdrg109_: To make this workaround somewhat permanent, you can replace ‘grub-efi-bootloader’ in your system configuration with ‘grub-efi-removable-bootloader’.

<nckx>That should keep you bootin'.

<lechner>ACTION just discovered https://bugs.debian.org/746662

<nckx>If you enjoy booting as much as I do, this will be important to you.

<rdrg109_>nckx: Is there a log of the installation that might show relevant information on why that bug happened? I could open a thread in the mailing list describing the issue I had and how I fixed and share that log.

<nckx>lechner: No milkshake-duck response?

<nckx>I've never really used the installer myself, I'm afraid.

<nckx>I fear the answer might be no, though, at least after reboot.

<nckx>tarte-tatin: Welcome back.

<lechner>ACTION just discovered https://bugs.debian.org/746662

<nckx>That's our ‘grub-efi-removable-bootloader’ by the way.

<lechner>the bot has https://codeberg.org/lechner/guix-helper-bot/issues/2

<tarte-tatin>"#2 - Decoding of HTML titles is defective - guix-helper-bot - Codeberg.org" https://codeberg.org/lechner/guix-helper-bot/issues/2

<rdrg109_>rdrg109_: Ok, I just wanted to be helpful to the community. I'll just open a thread in the mailing list, describe the issue I had and shared the relevant chat log of this chat and how I finally solved it.

<lechner>ACTION just discovered https://bugs.debian.org/746662

<bjc>ACTION peers at lechner

<nckx>rdrg109_: A bug report would still be valuable though: ‘the Guix System installer(?) ignores grub-install/efibootmgr errors that leave the system unbootable’ is bad enough on its own.

<nckx>rdrg109_: Thank you!

<nckx>That is very helpful.

<nckx>Just in case you're wondering: we can't reasonably default to the -removable- variant (\BOOT\BOOTX64.EFI) because that's, to say the least, extremely impolite towards other operating systems.

<lechner>rdrg109_ / you can do guix install efibootmgr and then we can fix your variables. otherwise you can boot nothing else

<nckx>In practice there's one operating system that would suffer the most, and I don't care, but it would still be very unpleasant for users suddenly unable to experience Windows.

<lechner>ACTION consulted juix.org

<lechner>windoze used to behave like that towards others

<nckx>It's not Windows I'm concerned about :)

<nckx>It's Windows users.

<nckx>The first taste of purported ‘freedom’ is going to taste pretty bitter when it slams the door shut behind you, even accidentally.

<lechner>you are too kind a soul, sir

<nckx>It's my only flaw.

<nckx>That and my modesty.

<lechner>i say, take no prisoners

<unmatched-paren>lechner: Au contrare, make them ALL prisoners.

<unmatched-paren>s/contrare/contraire/

<nckx>Pretty sure we're supposed to turn evil and into the thing we hate *after* world domination, not before.

<nckx>ACTION checks the handbook.

<nckx>Yep.

<unmatched-paren>Ah, I was reading it upside down. Oops.

<lechner>ACTION recently searched "Guix" on LWN.net, and it was pretty sparse

<lechner>how about a marketing team?

<unmatched-paren>That's something you're supposed to introduce halfway through Chapter 5, "Transitioning to the Evil Phase".

<lechner>we could use some more drum rolls

<unmatched-paren>Subtitle "(Without Anyone Noticing)".

<lechner>i think that's happening to vscode

<unmatched-paren>Also includes: opt-in telemetry (to be silently switched to opt-out at a later stage), creating a company entitled "${PROJECT} Labs Ltd" to manage the project, and releasing a paid Enterprise(TM) version.

<bjc>apparently golang is adding opt-out telemetry to the build tools

<bjc>as if the proxy problem wasn't bad enough

<unmatched-paren>ACTION entirely unsurprised

<bjc>but we neeeeeeeeeeed it

<lechner>bummer, i was just going to ask you to send me maps of your /gnu/store folders

<nckx>Their reasoning for rejecting opt-in was ‘not enough people would opt in’. That is it. That is the koan. Tech has eaten its tail.

<bjc>yep. that's everyone's reason

<unmatched-paren>We should make Guix install all packages by default, because users are too stupid to install them themselves. Duh.

<bjc>the "our tools are super useful and necessary, which is why no one would use them if we told them about it"

<nckx>nss is currently testing ‘40 Bit RC4’.

<lechner>what?

<rdrg109_>lechner: Ok, I executed that command. What are the required steps to fix my EFI variables? (I don't want to be a burden, so if there's documentation on how to do this, you could also share it with me)

<rdrg109_>The command I refer to: "$ guix install efibootmgr".

<nckx>lechner: Sorry, little relevance. I needed to share my pain that the test suite was still running after hours and currently testing the cryptographic equivalent of rot14.

<lechner>rdrg109_ / let's do it together. can you paste the output, please?

<lechner>somewhere

<nckx>ACTION goes to do ‘fun stuff’, which notably does not involve computers. o/

<lechner>ah, those teddy bears

<rdrg109_>lechner: output of $ guix install efibootmgr: http://0x0.st/HrhE.txt

<lechner>rdrg109_ / the output of efibootmgr please?

<lechner>nckx / sorry, that was a bit mean

<rdrg109_>lechner: $ efibootmgr shows "command not found". Am I doing something wrong? I'm sorry I'm a newbie Guix user.

<rdrg109_>iirc programs are launched with "guix"

<lechner>please source the profile as described in your paste

<rdrg109_>lechner: done: http://0x0.st/HrhG.txt

<oenone>I'm currently writing a package definition... how can I force a rebuild after it was built successfully using `guix build`?

<lechner>--check maybe ?

<lechner>rdrg109_ / there is the bug. no entry for Guix!

<lechner>here is mine http://paste.debian.net/1271117

<tarte-tatin>"debian Pastezone" http://paste.debian.net/1271117

<rdrg109_>lechner: Are these values supposed to be set by the graphical installation or should be manually set?

<lechner>i am not sure. mine are very old, as you can tell. i never ran W*ndoze on this donated equipment

<rdrg109_>Second question: Pardon my ignorance, why is it relevant for GUIX to appear in the output of that command? Booting my laptop already starts Guix, so what would be the added benefit?

<lechner>your UEFI bios always looks at the removable media path first. it's kind of a catchall, but should be an emergency measure

<lechner>my guix installer created that entry for me. i have to look up for you how to do it by hand

<lechner>rdrg109_ / i think you want efibootmgr -c -d /dev/sda -p 1 -L Guix -l \EFI\Guix\grubx64.efi

<lechner>per https://www.linuxbabe.com/command-line/how-to-use-linux-efibootmgr-examples

<tarte-tatin>"Use Linux efibootmgr Command to Manage UEFI Boot Menu - LinuxBabe" https://www.linuxbabe.com/command-line/how-to-use-linux-efibootmgr-examples

<lechner>also, did you file a bug already. the output from your efibootmgr may belong into it

<rdrg109_>lechner: I think I understand it now. You are making me execute that command since that would make the file /sda1/EFI/Guix/grubx64.efi to be read by my firmware, so it would have the same effect than the command that nckx initially shared with me (cp /mnt-sda1/EFI/Guix/grubx64.efi /mnt-sda1/EFI/BOOT/BOOTX64.EFI) Am I right?

<rdrg109_>lechner: Not yet, but I'll do it.

<lechner>yes, you are 100% right

<lechner>except it makes the boot partition selectable

<rdrg109_>lechner: Ok, now I get it. When I try another shell based installation on another laptop to replace Windows, I'll definitively use that command.

<lechner>it's more flexible. also, you may benefit from having this around (although not in position one) http://www.rodsbooks.com/refind/

<lechner>in a pinch, rEFInd can boot the EFI kernel stub https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html

<lechner>rdrg109_ / did you already file a bug? did you use 1.4.0?

<rdrg109_>Not yet, but when you say 1.4.0 what are you referring to?

<lechner>the Guix installer

<lechner>installation media

<nckx>oenone, lechner: ‘guix build --check --no-grafts …’, yes.

<florhizome[m]>so now guix pull fails with an error about guile-git

<florhizome[m]>i think i had this before and the solution included using guix gc

<oenone>nckx, lechner: thanks!

<rdrg109_>[Q] Is it necessary to subscribe to the bug-guix mailing list to report a bug? This is not necessary in some mailing lists, but it is in others mailing lists.

<mirai>no need to subscribe

<johnabs[m]>Anybody using Pijul VCS per chance? I see Guix has the library as a package, but not the tool itself for some reason, is this intentional? It seems like the last bit of work done on it was in 2021.

<lechner>johnabs[m] / i'd like to but have found the nest somewhat less than cozy

<johnabs[m]>lechner: Yeah, I've noticed, but I don't like git branching either so I'm willing to give it a shot lol. I WOULD use darcs, if it weren't so slow q.q

<lechner>johnabs[m] / is the nest still closed-source?

<johnabs[m]>Also, I kinda want a nice hybrid approach like sapling but with the patch version control, but git compatible...that would be great, since git "won" but it leaves a lot to be desired. Though I suspect trying to interchange between these two fundamentally different management systems would be a giant pain.

<johnabs[m]>And I yeah, it is :(

<johnabs[m]>I'd love to spin up my own instance

<lechner>yeah, good luck with that. NFF - not for felix

<johnabs[m]>I'm not sure what that means, lol

<johnabs[m]>who is felix?

<apteryx>lechner is felix

<johnabs[m]>Oh, lmao, sorry xD

<lechner>a friend of mine once told me that during a heartbreak, and i still like using it from time to time

<johnabs[m]>Ah, good to know :)

<lechner>sorry about that. i could fall in love with pijul, maybe

<lechner>i also find their cryptography kind of weird, though

<johnabs[m]>Yeah, maybe one day...q.q Have you seen sapling from...Meta? 🤢 xD

<rdrg109_>lechner: I mounted /dev/sda1, deleted the directory /mnt/EFI/BOOT/ and executed $ efibootmgr -c -d /dev/sda -p 1 -L Guix -l \EFI\Guix\grubx64.efi , but got "Operating System not Found" again.

<barbaneigro>awesome, php 8.2 :)

<johnabs[m]>I like pijul because of the theory behind it, and the speed. But network effects are brutal :/

<rdrg109_>I wonder if I did something wrong. perhaps I should use / instead of \ in \EFI\Guix\grubx64.efi

<lechner>rdrg109_ / what happened? i think the backslashes are UEFI standard

<lechner>johnabs[m] / you know, i grew really tired of Git a few years back and looked at alternatives. in fact, i don't really like git. then i started using Magit in Emacs and, hey presto, my affection was back (although it can be slow)

<lechner>thanks for the pointer to sapling. that may not be revolutionary enough for me to learn another bag of tricks

<rdrg109_>lechner: I thought that by executing the command that you recommended me ==> efibootmgr -c -d /dev/sda -p 1 -L Guix -l \EFI\Guix\grubx64.efi <== the file I had created with ==> cp /mnt/EFI/Guix/grubx64.efi /mnt/EFI/BOOT/BOOTX64.EFI <== was unnecessary so I executed the command you mentioned, executed ==> sudo rm -rf /mnt/EFI/BOOT <== and restarted my laptop and I got "Operating System Not Found"

<lechner>i like you. you are an optimist

<johnabs[m]>lechner: I've actually been using magit myself, and it's nice, but maybe I'm just bad at it. I'll have to give it another look with the hope I don't run into any more walls (can't recall what the issue was, but it took forever for me to fix)

<lechner>johnabs[m] / magit is unbelievable. no more git add -i just highlight it and go. it was a total game changer for me

<johnabs[m]>lechner: And of course, I hope it proves useful! We just need a guix package for it xD (Also, not sure who's the optimist, but if it's me, thanks :3 If not, ignore me lmao)

<lechner>rdrg109_ / did you have a chance to take a look at the output of efibootmgr ?

<lechner>rdrg109_ / on the postive side, we may be narrowing in on the bug

<lechner>the installer probably thought like you

<apteryx>I was wondering if x0vncserver could be run as a service to expose the X11 session of a particular user?

<apteryx>I know that if it was a home service, it'd expose the user current session, but I'm wondering if it can be used as a system service

<lechner>why not get a thin client on eBay for $10 and set up netboot?

<lechner>johnabs[m] / the optimist is another user who is stuck but sticks with us

<apteryx>lechner: different use case

<johnabs[m]>lechner: Ah, gotcha, well I like 'em too! Optimism is great, just like optimization! 😂

<graywolf>Hello, I have a question, how does te dependencies field for filesystem and swap-devices work? I originally had (dependencies mapped-devices), but that seemed wasteful, so I trimmed it down to just the device that is required (so the lvm one). And the system stopped booting. 1. What should be in dependencies for it to work? 2. Is there a reason *not* to have all (mapped-devices) there? Like, do I

<graywolf>save on boot time if I filter it or something? Let's assume I have 10 luks + lvm devices, but only two of those are for / (and therefore /boot).

<graywolf>Also, the "boot into older configuration" feature possible via grub is simply amazing.

<lechner>graywolf / i think all lvm2 should require (mepped-devices)

<lechner>all lvm2 volumes

<rdrg109_>lechner: I executed the command that you recommended me => efibootmgr -c -d /dev/sda -p 1 -L Guix -l \EFI\Guix\grubx64.efi <=, executed ==> $ efibootmgr <== to make sure that Guix was added to the list, it was added. Rebooted my laptop, log-in again, executed ==> $ efibootmgr <== , but I noticed that GUix is not shown in the list as it happened before rebooting. It seems that the problem here is that

<rdrg109_>the change is not persistent.

<lechner>rdrg109_ / the FBI will arrive at your place in five minutes

<rdrg109_>Ok, I'll invite them coffee

<lechner>rdrg109_ / how old is this equipment?

<graywolf>lechner: I've tried putting the mapped device of type lvm-device-mapping into the dependencies, and that did not boot. Do I need to add both lvm-device-mapping and luks-device-mapping mapped devices in there? So basically full path instead of the final leaf?

<nckx>Ello again. Fun was had, good clean teddy-bearless fun, I have no idea what you meant lechner but I assure you the rumours are almost entirely baseless.

<graywolf>Or using just lvm-device-mapping should work and I just did something wrong?

<nckx>Oh, so the firmware happily accepts your variables, then throws them in the bin first chance it gets? Nice.

<lechner>nckx / that could be the bug

<nckx>It absolves us of ignoring an error which was never reported, at least.

<mirai>graywolf: have you inspected the system using shepherd-graph

<lechner>i.e. something in the transition to efivarFS is causing changes not to persist

<mirai>and extension graph

<nckx>lechner: Oh, does this machine work with older kernels? I haven't read the full backlog.

<lechner>we do not know

<graywolf>mirai: I have no idea what that is, so no, will google it :) Thx

<lechner>graywolf / here is what i use https://codeberg.org/lechner/system-config/src/commit/73d16ed3294536df3aaf6299ff7191f762af3ca9/host/lechner-desktop/operating-system.scm#L98-L148

<rdrg109_>lechner: The model is Sony Vaio SVS15125PLB . Manual with the earliest publication date is 2012 in the official website https://www.sony-latin.com/es/electronics/support/laptop-pc-svs-series/svs15125plb

<tarte-tatin>"system-config/operating-system.scm at 73d16ed3294536df3aaf6299ff7191f762af3ca9 - system-config - Codeberg.org" https://codeberg.org/lechner/system-config/src/commit/73d16ed3294536df3aaf6299ff7191f762af3ca9/host/lechner-desktop/operating-system.scm#L98-L148

<rdrg109_>lechner: I found https://superuser.com/questions/1166398 same problem reported: "EFI settings set via efibootmgr are ignored after reboot". Now that I've found others with the same issue, I think I can go on my own on this. Thanks for thelp!

<graywolf>lechner: Thanks, I see that you just have (dependencies mapped-devices), so I'll go with that as well for now and revisit that later if it turn out to be a problem.

<lechner>graywolf / smart move, i think. purity has its cost

<johnabs[m]>Oh! I almost forgot, does anyone know of an easy way to get ssh-agent running when I log in so I only need to run ssh-add once?

<lechner>rdrg109_ / we can always set up up with MBR + GPT. that's what i do one one piece of equipment that is of about similar vintage. it requires that BIOS Boot partition of 1 MB we mentioned earlier

<johnabs[m]>I tried using a canned solution from an old computer, and a suggestion online, but the former failed, and the latter made it impossible for me to login until I bypassed the display manager lol

<graywolf>johnabs[m]: I have `eval $(keychain --agents gpg,ssh --eval --quiet -Q ...' in my ~/.profile

<graywolf>Where ... are files/keys to unlock

<johnabs[m]>graywolf: Okay, give me just a sec with that, I think that's the one that made me unable to login xD

<johnabs[m]>I used to just be able to put "eval $(ssh-agent)" in my .xinitrc, if I recall correctly

<johnabs[m]>Are you using the gpg-agent per chance? I'm not sure what keychain is doing in there

<lechner>neither was i

<graywolf>johnabs[m]: The `--agents gpg,ssh' seem to start both ssh-agent and gpg-agent (based on quick read of man page). And I do see both in ps output.

<johnabs[m]><graywolf> "johnabs: I have `eval $(keychain..." <- Also, can I pop this solution in my xmonad config as an eval-once rather than .profile?

<johnabs[m]>graywolf: Good to know, I think I found a thing, give me just a sec lol

<graywolf>No idea about the xmonad, but probably not. It requres the output of the keychain command to be eval-ed by POSIX compatible shell and then passed to subprocesses (Xorg in my case).

<wdkrnls>Dear Guix, I am feeling pretty thick.

<wdkrnls>How do I go about using an older version of python with the python-build-system?

<wdkrnls>Certainly I don't have to use an inferior for this, right?

<wdkrnls>My imported PyPI package only works up to Python 3.6.

<wdkrnls>However, it certainly wasn't in guix at that time.

<wdkrnls>And I want to use it with a bunch of things in the present.

<graywolf>lechner: I have question about your config you posted. It seems you are using multiple files shared between the system, but how is this managed? The repository does not seem to be a channel. Do you always use guix deploy, even for local machine?

<lechner>yes, it has some security drawbacks but is my only way to "reconfigure" because my home is on a FUSE based file system (which does not allow root, or sudo, to access my local copy of Guix)

<graywolf>Ah, got it, thx

<johnabs[m]><graywolf> "No idea about the xmonad, but..." <- So I tried using keychain and it works; however, it doesn't seem to work with emacs, whereas it did on arch for some reason. would you happen to have any pointers?

<jpoiret>johnabs[m]: you can't put env variable exporting inside of your WM config

<mirai>lechner: thought you might be interested, here are the first steps towards NFS support (#61587)

<graywolf>johnabs[m]: wild guess but would you maybe be starting emacs daemon before running the keychain (or from different process hierarchy)?

<graywolf>gotta go, sorry :/

<johnabs[m]>I think I got it!

<johnabs[m]>Thanks for your help!

<lechner>#61587

<tarte-tatin>"[PATCH 0/8] networking services refactoring" https://issues.guix.gnu.org/61587

IRC channel logs

2023-02-17.log