IRC channel logs

<nckx>sneek: later tell rekado Cancel that :)

<efraim>sneek: botsnack

<nckx>sneek: later tell adamnr https://logs.guix.gnu.org/guix/2023-07-31.log#100340 — it's silly.

<nckx>futurile: There's an official hack: https://guix.gnu.org/en/manual/devel/en/html_node/Channels-with-Substitutes.html

<nckx>It only checks for substitutes for ‘guix pull’ itself, though.

<nckx>Which is remarkably slow, so it's still useful.

<michal_atlas>I usually just wrote up a channels file and replaced the commits with older ones, then you can `guix pull -C channels.scm`, I bet that could be automated though, build the checkout, run `git log -1 --before ...` and then take that commit.

<michal_atlas>Would be useful for time-machine, since quite often if you time-travel you need to move all the channels, cause just moving guix usually breaks the rest.

<dgr>sorry, I'm new to this but where do I need to put the snip from https://issues.guix.gnu.org/55723 in /etc/config.scm?

<GNUtoo>nckx: with openssl-1.1 there are 6850 dependent packages, so I'm unsure what to do. If it goes in core-update it would wait for the next release, right?

<nckx>dgr: Under your module imports and before your (operating-system …) definition. Then you use (bootloader grub-efi-bootloader-luks2) in your operating-system.

<nckx>GNUtoo: We could graft it.

<GNUtoo>ok, I'll send the patch as-is then with a warning inside

<nckx>Nice, I'll wait for your patch.

<GNUtoo>For LibreSSL it's bug 64982

<nckx>For grafting, you define a new openssl-1.1/fixed variable that (inherit openssl-1.1)s, and applies any patches. You leave openssl-1.1 unchanged except for adding a (replacement openssl-1.1/fixed) field to it.

<nckx>ACTION work.

<nckx>Oh, I see there's already an openssl/fixed variant, so Guix is currently on 1.1.1t. Add any patches there. It won't cause a rebuild.

<nckx>Eh, but it's not used. That's fishy.

<nckx>Possible merge conflict? 67921f5f4f456f6a3e25eabb228748ee83684d71

<GNUtoo>hmmm

<nckx>Yeah.

<GNUtoo>Anyway I've sent the patch that I have

<GNUtoo>which is a simple update

<GNUtoo>I'll try to look for /fixed examples later on

<GNUtoo>thanks a lot for the help

<nckx>I'll be of actual help later, at my 'puter, with a grep.

<dgr>nckx: Thank you. Now I get "source expression failed to match any pattern" https://paste.debian.net/1287594/

<nckx>dgr: Move the docstring (the "Create an Grub EFI … not handle yet") under the ‘#~(lambda (bootloader efi-dir mount-point)’ line.

<chrislck>anyone knows why the package webkitgtk-with-libsoup2-2.40.2 isn't building?

<nckx>dragestil: Or just delete it since it's just a comment masquerading as a string, but comments can be helpful.

<nckx>The pattern failing to be matched was (define foo bar), since you had in effect (define foo "HELLO I AM STRING" bar).

<nckx>dragestil: Sorry, I meant dgr.

<nckx>dgr: Aside: thank you very much for including your full system configuration! It's a good habit.

<dgr>nckx: thank you, init is running and if it works, this will be my first working hw install of guix. I have a long way to go in learning guile and guix so I figured I messed up and better provide the config - not sure later if user definitions aren't default.

<reily>Does anyone know the status of issues.guix.gnu.org/58074? It looks like updated patches have been available since December. Is this ready to merge into staging/core-updates?

<sneek>reily, you have 1 message!

<sneek>reily, lilyp says: our emacs ships with some workaround to fix tramp as the receiving end but I don't have the means to debug it as sending end, sadly

<itd>nckx: thank you! :)

<chrislck>OMG after waiting 48h webkitgtk-with-libsoup2-2.40.2 is now available !?

<nckx>I built it.

<nckx>I built it because I thought you meant it was broken, but since it wasn't, there it is 😛

<chrislck>oh wow

<chrislck>it wouldn't build in my machine

<nckx>Do you have the log?

<chrislck>thank you !:-)

<nckx>No problem!

<chrislck>no idea how to look at log... my env.sh just sets up the guix shell dependencies and usually off i go

<nckx>It might have been due to running out of storage space or RAM. These webthings tend to use unreasonable amounts of both.

<chrislck>agree

<bdju>is there a way to check the uuid of a swapfile I already made? to put in my config.scm

<nckx>bdju: swaplabel(8) …but on a file? What's the point?

<nckx[m]>ACTION sneezes.

<bdju>is it not needed? I had a uuid in my old config

<nckx>If it's needed, how would that work?

<nckx>What did your previous (working) swap-space definition look like?

<bdju>(swap-devices (list (swap-space

<bdju> (target (uuid "9028f398-c894-4c6b-b046-a6b53ad73f75")))))

<bdju> (mapped-devices

<bdju>when I created the swap file it did print a uuid but I'm in the installer in a tty and lost the scrollback

<nckx>Reason I ask is because while it's very cheap to create a list of all drive & partition UUIDs, and udev does this at /dev/disk/by-*, think about how this could ever work with files. You'd have to scan the entire file system at each boot, reading each file to check for a swap signature + matching UUID.

<nckx>Feasibility aside, neither Guix nor anyone else does this.

<bdju>I'm not trying to rewrite my config, just make it work with minimal effort after reformatting this drive

<nckx>Are you sure (1) you had working swap before and (2) it was a swap file, not a partition?

<bdju>I'll comment out those lines I guess

<bdju>1: no it may not have worked, had issues before, 2: yes I much prefer swapfiles

<nckx>If you find a distribution that searches your file systems for swap files based on UUID, that is something I'd (genuinely) like to hear about. I'm the morbidly curious type.

<bdju>I never know what's going on, don't let me mislead you

<nckx>Anyway, what you *probably* want is (target "/my/cool/swap/file") .

<nckx>Hehe :)

<nckx>I'm going to assume your swap wasn't actually active on the old system, *or* there was some parallel mechanism that was actually activating your swap file.

<nckx> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm#n2453

<bdju>ughhh part of my config is invalid now

<nckx>Chuck it in the paste, if you can.

<bdju>missing field initializers (file-systems)

<bdju>uhhh hm maybe with curl I could

<bdju>no curl installed

<nckx>There's also wgetpaste but I don't know if it's installed by default.

<nckx>If you install curl, I like https://0x0.st/ myself.

<nckx>ACTION AFK to make coffee.

<bdju>nckx: https://0x0.st/H2OC.txt it's something with the drives/partitions/swap thing probably

<nckx>bdju: Extraneous ) after (target "/swapfile"))))

<nckx>So you were closing the (operating-system …) early, before (file-systems …) and the like.

<bdju>interesting. removed 2 but didn't add any

<bdju>will try removing that

<nckx>Weird. It was definitely the problem.

<bdju>I changed from the uuid thing to the other format which seemed to have fewer parens

<bdju>okay now one of my uuids is wrong for the luks thing I guess

<bdju>ah I copied the uuid_sub not uuid

<nckx>Yes, each layer will have its own UUID (drive, partition, LUKS, btrfs), it can get complicated.

<nckx>I assume you're aware of ‘cryptsetup luksUUID’ but I'll mention it anyway.

<bdju>I don't know anything

<bdju>luks is terribly complicated and I often question if it's worth it

<bdju>guessed the uuid wrong again...

<nckx[m]>Oh look, Matrix is forwarding our chat again. Hello, Matrix. Please stop dying. It distresses the kids.

<bdju>I tried that command but get no output, used /dev/mapper/whatever as arg

<nckx>bdju: What it offers is pretty solid for the price, but yeah, I stopped using it on my home machines.

<nckx>bdju: You'd run that on the outer device, e.g. /dev/sda1.

<nckx>It could be helpful and return the same thing when pointed at the ‘inner’ /dev/mapper device, but that could get confusing fast (nested containers) and encourage sloppy thinking.

<janneke[m]>nckx[m]: It's amazing

<nckx>And now it's even forwarding without delay.

<bdju>okay got that sorted, now got unexpected end of input while reading string

<nckx>Oh nope. Only Matrix → IRC. IRC → Matrix is either broken again, or very slow.

<nckx>Weird, when I removed that ) I could build the file.

<nckx>Assuming it's trivial for you now: could you share yours again?

<nckx[m]>ACTION spoke too soon, janneke :-(

<bdju> https://0x0.st/H2VP.txt

<janneke>hmm, nckx[m] something seemed to work...

<bdju>oh I see it, a missing quote I think, deleted it by accident pasting a new uuid

<bdju>okay now it's gonna download stuff finally

<nckx>Sorry, phone.

<nckx>janneke: I don't see your ‘hmm’ on Matrix, or any other recent message here. I assume the problem isn't on my end, though.

<nckx>bdju: \o/

<janneke>nckx: right, i (still) only saw your "spoke too soon", sent from [m]

<nckx>AFAICT the plan today was to change the way the Matrix bridge queues IRC messages (it was an implausably low number for the entire network, whatever you're thinking, divide it by at least 10), but that went wrong and resulted in the complete outage earlier today, so they rolled back and we're back on the old rickety bridge that loses half of all messages.

<nckx>ACTION only now realises that the people most affected by it won't see that message. 🤦

<bdju>after system init in the install is there anything else I should do before reboot?

<nckx>unmount everything (‘herd stop cow-store’ first to be safe, although that does leave mounts in place) and you should be good to go.

<nckx>By ‘everything’, I mean /mnt.

<nckx>Hm, passwords. Anyone know how those work on first boot?

<nckx>I've been restoring /etc/shadow from back-up for ages now.

<nckx>…but I don't see a DM in your service list so you can just log in as root (no password) and passwd manually.

<alphapapa[m]>Hi, I'm trying to install the recently released Emacs 29.1 with ~guix install emacs-next --with-commit=emacs-next=emacs-29.1~, and it builds and installs without error, but native compilation cails with errors that the files ~crti.o~ and ~crtbeginS.o~ can't be found. The Emacs 28.2 version of the ~emacs~ package works fine with native compilation. I can't find any bugs on the tracker about this problem in the emacs-next package for Emacs 29

<alphapapa[m]>pre-release versions, so I'm not sure what's going on. Would appreciate any pointers.

<alphapapa[m]>s/cails/fails/

<nckx[m]>ACTION tries.

<nckx[m]>It might be due to the 3 patches currently applied to 29.0.92.

<alphapapa[m]>ah, yes, maybe so

<nckx[m]>There isn't a clean way to manage those through the CLI transformation options.

<alphapapa[m]>Forgive me, but is there a way to access those patches through the shell, or do I need to look in the git repo?

<nckx[m]>I'm not aware of a way to get guix to print them, no.

<alphapapa[m]>thanks

<nckx[m]>If it builds and runs for me, I'll push it to master.

<alphapapa[m]>nckx[m]: Do you mean if it works without this patch? https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/emacs-native-comp-driver-options.patch

<bdju>off to a terrible start. grub says no such device for a uuid then unknown filesystem and threw me into rescue mode

<nckx[m]>No, I meant that I'm currently building emacs-next{,-pgtk} from my edited copy of the Guix source, rather than the CLI. If it looks good I'll commit the changes and push.

<nckx>bdju: Oh no ☹

<alphapapa[m]>Oh. What changes did you make?

<nckx[m]>alphapapa: Just the version & hash so far :)

<alphapapa[m]>Oh. That should effectively be the same as using the transformation option I passed to guix install, shouldn't it?

<nckx>bdju: Did you ‘cryptsetup luksFormat’ again?

<nckx>You probably did. Did you use --type=luks1 ?

<nckx>You probably didn't.

<bdju>I left my efi and root partitions but redid the luks and mkfs parts

<bdju>I followed the install guide

<nckx>Right. It sucks, but Guix support for LUKS2 is borkie.

<bdju>> cryptsetup luksFormat --type luks2 --pbkdf pbkdf2 /dev/sda2

<bdju>whaaaa

<bdju>really?

<nckx>Uh.

<nckx>Dear manual: I'm not sure I agree with you here, buddy.

<nckx>I think at the very least that requires a separate /boot, which isn't even documented.

<nckx[m]>alphapapa: I'm not sure if that preserves patches.

<bdju>I have /boot/efi or whatever

<nckx>That's something else.

<bdju>ah

<nckx>Ugh. I think you might've been misled here.

<nckx>I'm sorry.

<alphapapa[m]>I see. Well, I looked at those patch files, and AFAICT they shouldn't affect this problem; the one about native comp only applies to Macs, anyway. But I appreciate your help.

<bdju>ugh indeed

<alphapapa[m]>For reference, here is the full set of error messages from Emacs's ~*Warnings*~ buffer:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/e3ce2e9c022abb550b4c8cdd756b964d0559c67d>)

<bdju>I wonder which luks I had before. I think the guided install made it for me last time

<nckx>bdju: The ‘best’ solution I can think of is to reboot the installer image, then do everything exactly as you did before but be sure to pass ‘--type luks1’ to luksFormat. The alternative is to hunt down which constraints there are on using Guix System with LUKS at this time, and/or manual hacks like https://issues.guix.gnu.org/55723 .

<nckx[m]>pjals: ‘Really’ depends on your definition, I guess, but it's certainly not supported by Guix proper. You have to manually copy the ‘closure’ of grub.cfg to /boot

<alphapapa[m]>pjals_fox: AFAIK it's the responsibility of the Matrix bridge to handle that. In every other bridged channel I use, it does.

<nckx[m]>pjals: It's OK, the Matrix bridge does mostly the right thing.

<linj>alphapapa[m]: TIL

<nckx[m]> https://logs.guix.gnu.org/guix/2023-08-01.log#194443

<nckx[m]>Also, no, you're not actually bridged to IRC at the moment :-p The bridge is very broken and currently only bridging in one direction. That's why I'm responding as nckx[m].

<nckx[m]>A dumb but working bridge sounds tempting at this time.

<alphapapa[m]>pjals_fox: You don't need to repeat the pattern by also yelling at others ;)

<nckx[m]>Everyone's intentions were good, let's leave it at that.

<linj>nckx[m]: What do you mean by "one direction"? I can see messages from irc in matrix and messages from matrix in the irc log you post.

<nckx>My IRC messages making it back to Matrix is new and wasn't happening ~15mins ago. (I've got both HexChat and Quaternion open here, Matrixmoviestyle, just to keep track things. Truly the future of federated messaging…)

<nckx>And you'll note that pjal's messages are completely missing for whatever reason.

<bdju>nckx: are the pbkdf bits still fine?

<nckx>I think it's the default for luks1.

<bdju>alright

<nckx>Honestly, I'd drop it too. It's not going to add security.

<linj>yeah, his messages are missing but mine and alphapapa's are fine

<nckx>Whether this is better or worse than the completely broken state is a matter for the philosophers.

<alphapapa[m]> https://status.matrix.org/ shows that the Libera-Matrix bridge is having some issues today.

<nckx[m]>Oh, I'm sorry I lol'd, but you have no idea. It's been like this for a long time and steadily getting worse.

<alphapapa[m]>Yes. I'm sure it will be worked out eventually.

<nckx[m]> https://libera.chat/news/

<alphapapa[m]>Yes, I've been keeping up with the topic.

<nckx[m]>Oh, OK. Just know that the pretty green in that graph is meaningless.

<alphapapa[m]>I'm aware of that too. A few weeks ago there was an outage caused by the matrix.org homeserver TLS certificate, and the tracker didn't catch it. I filed https://github.com/matrix-org/matrix.org/issues/1938

<nckx[m]>I wouldn't be surprised if it just meant ‘the processes are running’.

<nckx[m]>nckx: Best. Timing. Ever.

<alphapapa[m]>(I'm a Matrix client author, so I generally keep up.)

<alphapapa[m]>nckx: FYI, I just filed https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64999 about the Emacs issue

<alphapapa[m]>ugh, I misspelled the filename in the subject

<nckx[m]>Whoops. TIL. I'm almost exclusively IRC-only, so I've seen it from this side, including Matrix's lack of communication and frustrating ‘oh it seems like the bridge might have been slightly wonky for 5 minutes this week’ understatements, implying they don't even monitor the IRC UX.

<nckx[m]>Which they don't, by the way.

<alphapapa[m]>I tend to be sympathetic, because it seems like a challenging software engineering problem, and they're doing their best, free of charge to us.

<nckx[m]>alphapapa: Thanks for the bug report!

<nckx[m]>I'm still building…

<nckx[m]>ACTION checks out ement.

<alphapapa[m]>I left the old room and it kicked me from this one :/

<nckx[m]>I think that's what happened to podiki[m], but only once. No need to idle in the old room when you're already here.

<nckx[m]>You being in the old room at all is a bug. You should have been kicked. You ALL should have been kicked.

<nckx[m]>ACTION kicks everyone, ranting incoherently.

<bdju>okay took a while but I think I'm back to where I was earlier but with luks1 now and grub worked this time

<nckx>Phew.

<bdju>oh my god

<bdju>everything is terrible again

<nckx>It was nice while it lasted.

<bdju>tried logging into a user with no password, suddenly saw a message that a reboot was happening for some reason, now I tried to decrypt and got thrown into grub rescue again

<nckx>jpoiret: Are you currently using LUKS2? And if so, how? I think the manual needs to be more clear about when --type luks2 will actually work, since it many cases, it won't.

<nckx>bdju: The hell. So it worked once, rebooted, now fails?

<bdju>maybe just a wrong password. does ctrl-u not work in the prompt? to delete all

<nckx>Have you tried a cold boot?

<nckx>bdju: I doubt that.

<nckx>You get exactly one chance in GRUB. It's annoying.

<bdju>I'll try again

<nckx>(Linux gives you 3.)

<nckx>jpoiret: And I'm pretty sure the common case is the broken one.

<bdju>okay working again now I think. man this is taking a lot out of me

<nckx>I understand. If it's any consolation (it's not), I went through all this + more 2 weeks ago.

<bdju>I'm about to lose it, it powered down right after log in again, to root this time

<nckx>🤨

<nckx>So if you leave it at the log-in prompt it happily stays running, but the second you log in it shuts down?

<nckx>That's… new.

<bdju>I think so

<bdju>it shows a message that it's going to shut down as if someone scheduled it

<nckx>This is the worst time to have what I think was a genuine deja-vu. I'm going to assume it was.

<nckx>If it's a graceful shutdown, you could use the installer to mount the drive and take a look at its /var/log/messages.

<bdju>update: it's a time thing not based on login

<bdju>sat at the prompt and it did it

<nckx>OK, so it's more likely to be a Shepherd bug now.

<nckx>I've heard of hangs at shutdown, not the opposite.

<nckx>Let's hope something was logged.

<nckx>ACTION away, sorry.

<bdju>might not be guix, saw something about a critical low battery error. I'm plugged in but maybe the ac adapter is bad. using someone else's as I forgot mine

<bdju>I took out the battery and it's working with just the ac adapter 🤔

<d00s>Get a ups for it! Same difference

<d00s> https://www.paulcbuff.com/vagabond-mini-lithium.html

<nckx>bdju: I always have to remind myself not to blame the hardware, don't blame bad RAM, … every time someone reports something weird.

<nckx>And dammit it was the hardware.

<nckx>alphapapa[m]: I'm running emacs-next-pgtk@29.1 without issue. emacs-next@29.1 also seems to run fine.

<kozo[m]>Hey all, what's a good way to find what package contains a library? I'm using guix shell and am trying to run a program and missing libstdc++.so.6

<nckx>kozo[m]: I tried the new ‘guix locate’ command, but it didn't find the answer (gcc:lib) for me. You can get it by adding ‘-e '(list (@ (gnu packages gcc) gcc) "lib")'’ to the command line.

<nckx>ACTION will stick to ls /gnu/store/*-*-*/lib/libstdc++.so.6 for now.

<nckx>Oh, you asked for a good way. Sorry!

<alphapapa[m]>nckx: Yeah the news says that only works for installed packages, but that that limitation will be lifted in the future.

<alphapapa[m]><nckx> "alphapapa: I'm running emacs-..." <- Thanks. Can you confirm that it's native-compiling Elisp libraries?

<nckx>Yeah, that's next.

<kozo[m]>nckx: Thanks =] Gives me a lead to go with

<nckx>alphapapa[m]: Which news? I looked up the ‘guix pull’ news item for precisely this reason and it specifically doesn't mention ‘installed’. That's why I'm surprised.

<nckx>It mentions ‘local information’ and ‘[not] packages that have not reached your store’. Very different.

<nckx>In my case, the difference between 735 and 24,455 packages!

<nckx>(The word ‘packages’ is also, probably, inaccurate.)

<alphapapa[m]>maybe I misunderstood what "packages that have reached your store" means

<nckx>Guix and Nix complicate the notion of ‘installed’. Where elsewhere it often means ‘it's on your drive so it's installed’, in Guix/Nix it generally means ‘it's installed in this specific profile’. Something merely existing in /gnu/store does not imply it's installed. In fact on most systems I'd say there's more in /gnu/store that *isn't* installed.

<nckx>The news item isn't wrong, but it leaves out the fact that without --method=store, you'll be searching a very tiny subset of your local files.

<nckx>Namely those installed to a small list of hard-coded profiles.

<alphapapa[m]>ah, thanks

<nckx>And once you run ‘guix locate’ without --method=store, running it with --method=store again will silently ignore it. That's probably just a bug though.

<nckx>I'll report it.

<alphapapa[m]>ok, running "guix locate --update --method=store" now

<kozo[m]>nckx: Using your ls /gnu/store~ method, I was able to locate a package on my guix install that had the lib. Thank you!

<alphapapa[m]>(Why does the user "Cat Disruptor 6000" keep reacting to random messages?)

<nckx>It's a bot, and the messages aren't quite random. Its presence in the Matrix room predates me (and even that version of the room) and its feline mysteries are lost to time.

<alphapapa[m]>I've seen it in the TWIM room, but I didn't realize it was in others too. It's a bit annoyingly...spammy/noisy...

<nckx>For example: I have 16 GiB of RAM.

<nckx>Says cat /proc/meminfo.

<nckx>What's a TWIM room?

<alphapapa[m]>(I'd vote in favor of kicking that bot, because ATM about half the vertical space in this room is its pointless CAT reactions.)

<alphapapa[m]>nckx: #thisweekinmatrix:matrix.org

<nckx>You're the first, but I'll register your vote.

<nckx>I understand why, but boy is ‘guix locate --method=store’ slow compared to a dirty ls */lib .

<nckx>But if it's clever enough to only update the diff next time it might yet win.

<lilyp>We have Emacs 29.1 already?

<alphapapa[m]>lilyp: Not exactly. The package definition hasn't been updated yet. You can try to use transformation options to build 29.1, but when I do that, native compilation doesn't work.

<nckx>How do you verify that?

<alphapapa[m]>nckx: What do you mean?

<lilyp>well, fml

<nckx>How would I know whether native compilation is broken.

<nckx>I'm weird; I use emacs to edit text, little more.

<alphapapa[m]>nckx: Maybe try "C-h f describe-function RET" and see if it says "describe-function is an interactive native-compiled Lisp function"

<nckx>‘describe-function is an autoloaded interactive native-compiled Lisp function in ‘help-fns.el’.’

<nckx>GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0)

<nckx>I can't find anything about crt.o.

<alphapapa[m]>well... I have no idea what's wrong with my installation then... works fine on "emacs@28.2" but "emacs-next@29.1" gives the errors in the report I filed

<nckx>I'll update my profile just to be sure.

<alphapapa[m]>I'm very far from being a Guix expert user

<nckx>Ditto for emacs.

<alphapapa[m]>nckx: Being a non-expert Guix user, what exactly do you mean? Should I try to do the same thing?

<nckx>No, I was talking about myself: before pushing the 29.1 update, I'll make sure it works fine in my actual user profile, rather than just a guix shell. Just in case.

<alphapapa[m]>oh I see

<alphapapa[m]>I just tried "guix shell emacs-next --with-commit=emacs-next=emacs-29.1 -- emacs-29.1" and I get the same errors at runtime. I don't know what I could be doing wrong.

<alphapapa[m]>s/"/~/, s/"/~/

<lilyp>nckx wdym by "pushing the 29.1 update"?

<alphapapa[m]>lilyp: He's testing an updated package definition that points to the released version

<lilyp>not the info i wanted

<nckx>The info you desire should arrive soon enough in an inbox near you, although it looks rather trivial.

<nckx>Done.

<alphapapa[m]>nckx: Sorry, do you mean you pushed the update to master?

<nckx>No, not yet.

<nckx>‘guix locate --method=store’ took 52 minutes.

<alphapapa[m]>yeah it was pretty slow for me too

<nckx>And --update just starts the whole process anew.

<lilyp>I have to sleep now, hopefully tomorrow I can push a clean emacs-team branch and then we can do the thing

<nckx>Good night!

<nckx>‘find /gnu/store’ takes less than a minute and a half (*and* my /gnu/store is over 50% untracked junk from a DB snafu).

<nckx>So if ‘guix locate --method=store’ is working off the DB, it should traverse less than half of what find had to.

<nckx>It's been a while since I've hawked my wares:

<nckx>Hey! You there! Yes, you! Do you like ‘the Guix’? Do you like cloaks? Do you even know what cloaks are? If so, you're in luck: both guix/user/ and guix/contributor/ cloaks are available with virtually no requirements, and nil strings attached.

<nckx>Maybe I should just thrust them upon all committers, that would teach 'em.

<samplet>For half a second I was expecting a link to a website that sells literal cloaks, for like wrapping around people to keep them warm.

<samplet>I’m not sure if I’m disappointed or not....

<nckx>I am ☹

<nckx>That would be some sweet swag.

<bjc>'() strings attached, you say?

<nckx>:() yesindeedy!

<elpogo>i'm still reading the guile reference manual nckx. i'll be a committer sooner than later, and will demand my cloak then

<nckx>Hell, I don't even check whether you know what Guix *is* before handing out /user/ cloaks, but I'll hold you to that promise.

<nckx>(The telemetry doesn't log nicknames, only legal ones.)

<nckx>Serious note: not all contributors must be committers. If you submit patches (doesn't need to be code) or help around some other way for a non-trivial time period, that counts.

<renngar[m]>Following fuse-3 being made the default and the older version being renamed fuse-2, I am getting set.id warnings and the process hangs after "bootloader successfully installed on '(/boot/efi)'.

<renngar[m]>setting up setuid programs in '/run/setuid-programs'...

<renngar[m]>warning: failed to make "/gnu/store/m9sv2bmkvkdma6l3gy2299vzqv0jm8vl-fuse-3.10.5/bin/fusermount" setuid/setgid: No such file or directory

<renngar[m]>* am getting system reconfigure set.id warnings

<nckx>Drat, I incorrectly resolved a conflict with my privileged-programs patches. Give me a minute.

<vagrantc>ACTION hands nckx a few spare minutes

<vagrantc>nckx: those patches are getting increasingly more interesting to me as lcsync has some new releases in the works, and it would greatly benefit from them :)

<bjc>nckx: what patches are these? i've got a patch to rejigger the setuid activation, and need to know if i have to update it

<vagrantc> https://issues.guix.gnu.org/61462 if i recall correctly

<bjc>danke

<bjc>this isn't pushed yet, right?

<vagrantc>basically generalizing the setuid functionality into supporting capabilities via setcap

<vagrantc>no, it was missing at least one significant patch

<nckx>Is it still? Let me rectify your situation pronto.

<vagrantc>although i think newer lcsync has some rough code to drop privileges

<nckx>bjc: Do tell.

<vagrantc>nckx: the v2 patches ... have not seen newer ones

<bjc>nckx: i moved setuid activation to shepherd, so that i can setuid/gid to non-root

<nckx>Oh, that's totally going to conflict in horrible ways. 👍

<bjc>i've been running that patch for Some Time™

<bjc>yes it is

<vagrantc> https://issues.guix.gnu.org/61462#28-lineno2

<bjc>i submitted my patch first, though, so that means you have to incorporate it into yours by the rules of i've been waiting for review so long i'm going to cry

<nckx>vagrantc: Nope, I owe you a v3, or at least one missing patch, but I'll keep things boring and send a v3.

<vagrantc>nckx: boring is great :)

<nckx>bjc: I really don't mind.

<nckx>It does mean I'm not going to noise up the tracker with a doomed v3, though.

<bjc>it's https://issues.guix.gnu.org/62726 if you want to look at it

<vagrantc>bjc: wait a minute, i am pretty sure 61462 comes before 62726

<bjc>oh damn

<bjc>well, i guess i don't want nckx to cry, so i can wait =)

<vagrantc>bjc: you can still cry if you want, but hopefully that can be avoided. :)

<bjc>having setcap would also be pretty great. but is it greater than being able to run wireshark? 🤔

<vagrantc>wouldn't setcap allow wireshark to work?

<nckx>vagrantc busting out the arithmetic skills.

<nckx>That deserves a patch set: tobias.gr/temp/vagrantc.tar.xz

<nckx>And people say mailing lists are archaic.

<bjc>possibly? i don't know enough about pcap to bang them together and make it work

<nckx>A brief end user's guide to setcap: (1) search the documentation/Web for the magic string to make the thing go workies (2) Put the magic string in setcap, or in this case, (capabilities "magic"). (3) Profit.

<nckx>You can reason about them if you like, but it's optional.

<bjc>nckx: btw, the issue i ran into with putting ‘/run’ in tmpfs is that file-system mounts happen *after* /run/current-system is activated

<nckx>Yeah, I'm not surprised.

<bjc>i was! but then i wasn't

<vagrantc>... /run really ought to be in tmpfs

<nckx>Yes it should.

<vagrantc>So many shoulds and oughts

<nckx>bjc: Did you report this at the /run feature request? Might help move it forward.

<bjc>i haven't. i keep meaning to go spelunking into activation to see if i can move stuff around to make it happen, but then i don't do it

<bjc>the lack of explicit ordering is annoying

<nckx>It's all very monolithic, so any change would probably imply (or morally compel you) to make it more modular at the same time, which would be nice.

<nckx>Hehehe.

<bjc>my take, so far, has been to just move things into the shepherd, since it has proper ordering

<nckx>That's not a bad take.

<nckx>It should be able to handle bringing up an entire system in the end.

<bjc>right. everything other than root and /gnu/store

<nckx>> implying the initrd will never run Shepherd.

<vagrantc>ACTION watches the exceptions breed

<bjc>initrd starts the shepherd now, but, iirc, it's not in the image

<nckx>Right, that's what I was alluding to.

<vagrantc>there is precious little in the initrd

<bjc>i suspect putting it on the image would be problematic

<bjc>maybe we can make it re-exec itself

<nckx>It's possible that you have given this more thought than I have. Why?

<bjc>i've tried some weird boot stuff for various reasons

<nckx>So've I, and every time I touch the initrd it bugs me how hard-coded/ordered/… everything is, and if that finally becomes untenable I'd much rather have a proper service manager than dirty ‘hooks’.

<bjc>i think 90% of stuff can just be moved into the shepherd without putting the shepherd on the initrd

<nckx>I might be in the minority here, if only because that's what systemd does, and it is therefore evil and bad and must be inverted.

<nckx>bjc: Oh, I don't doubt that (except maybe the percentage).

<bjc>possibly more. the bigger issue, for me, is that a bunch of stuff gets activated during ‘system reconfigure’ that's expected to be present at next boot (ie, it doesn't have boot activation)

<nckx>ACTION nods.

<nckx>CloudGuix would be nice.

<nckx>Or at least (More)StatelessGuix or whatever.

<nckx>It's oddly out of character.

<bjc>i have a very wip patch that uses ‘/sbin/init’ as the bootloader for containerization

<bjc>that's just the shepherd, of course, but it needs a static path so that the container system can always find it

<nckx>Yeah. FWIW I think that's a good idea.

<stevenroose>I've been trying to make LD find libboost, but without success..

<vagrantc>wow, that there are hard-coded /run/setuid-programs embedded in gnu/packages/* surprised me

<nckx>Although isn't the default /init, rather than /sbin/init?

<nckx>vagrantc: Yeah…

<stevenroose>I put the /gnu/store/xxxx-boost.../lib in LD_LIBRARY_PATH, what more cna i do?

<nckx>vagrantc: You're welcome to come up with a better solution.

<stevenroose>I point the ./configure to that same boost

<nckx>That was not meant to sound like the bad kind of challenge. It was the gooder kind.

<bjc>is it? it's been in /sbin since i first started messing with unix 30+ years ago

<nckx>In the initrd?

<nckx>Possible.

<stevenroose>I see things like /gnu/store/jsci59qmzwdd07kkkb4j7l5ba5mzayig-profile/include/boost/filesystem/path.hpp:596: undefined reference to `boost::filesystem::path::append_v3(boost::filesystem::path const&)'

<nckx>(30-year old Unix initrds? We might be talking about different things.)

<bjc>there wasn't an initrd back then, no

<bjc>but sunos, solaris, *bsd, etc. everything i ran across had it in /sbin

<nckx>Sure, on the real system.

<bjc>does linux include systemd in the initrd now?

<nckx>I'm talking about the initramfs (I usually groan at ‘it's not an initrd’ pedantry, but I'll be explicit in this case).

<nckx>I think you weren't.

<nckx>Hence my confusion.

<vagrantc>nckx: challenge declined. :)

<nckx>bjc: Many Linuxen do.

<nckx>vagrantc: Worth a shot.

<nckx>bjc: systemd serialises its running state (also the mechanism used to reload a running PID 1 I think) and hands over to the ‘final’ systemd.

<bjc>geez. that seems overly-complicated for what is probably extremely limited benifit

<bjc>but i guess that's systemd for you

<nckx>It's not terrible, and the fact that it's hairy in places is mainly because *everything* gets hairy fast on Unix, so it gets moaned about by systemdislikers.

<nckx>ACTION shrugs. I think it's nice.

<vagrantc>initramfs, the new kid

<nckx>Too long, won't write.

<bjc>i've grown to like a lot about systemd, tbh, but it's quite a monstrosity

<nckx>Oh sure.

<nckx>No contest :)

<vagrantc>monsters can be adorable ... look at all my patches that have gotten accepted into guix

<nckx>With <it's hairy in places> I meant the handover, not everything about systemd, which is often needlessly hairy.

<bjc>the unix rc system has always been awful. and until systemd happened there were countless attempts at making it rational. for all of systemd's issues, at least we're not still trying to reinvent the boot graph

<nckx>Then along came Guix.

<nckx>(Yes, yes, I know. Simplified for humour, OK.)

<bjc>i wouldn't complain if we swapped in systemd for the shepherd =)

<nckx>I'm OK with giving the Shepherd as much time as the Hurd has got…

<nckx>It has *potential*.

<bjc>it's pretty unlikely, in my mind, that guix is ever going to move from the shepherd. i just find it a little frustrating that we have to re-solve things that systemd solved a long time ago

<vagrantc>hegemony ftw?

<vagrantc>my preference is to ignore init systems and let other people quietly keep the mice motivated to keep running in their little wheels

<bjc>i'm nfs-mounting my home directory, so the shepherd's poor ability to order a shutdown is an ongoing issue for me

<bjc>and that's, like, the explainable reason for the shepherd to hang forever on ‘halt’

<vagrantc>reasons are compelling