<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.
<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>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?
<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?
<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>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.
<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.
<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.
<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.
<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.
<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....
<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
<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>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)
<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.)
<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