IRC channel logs

<sepeth>Hey Guix, when I run `guix package --list-profiles`, I get /home/sepeth/.config/guix/current \n /var/guix/profiles/per-user/sepeth/guix-profile, however when I install something with guix install, it gets installed to the second one. Shouldn't it be the first one?

<nckx>The first one is only for guix itself, populated by ‘guix pull’. The second one is where your ‘guix install’ed packages go.

<amano>I guess that I don't need extra-initrd for storing a keyfile for other non-boot LVM devices.

<amano>I mean the root filesystem can have a keyfile for other non-boot LUKS devices.

<amano>grub unlocks the root btrfs filesystem with a password.

<sepeth>nckx, oh okay, thanks. Another question if I may, which one should GUIX_PROFILE env point to? The second one then, right?

<sepeth>s/env/envvar

<nckx>I wouldn't set it at all.

<nckx>It doesn't do anything.

<sepeth>Hmm, sometimes guix install complains about that, and I think that's generally my source of confusion.

<nckx>It doesn't, you're reading too much into that message.

<nckx>~ λ echo $GUIX_PROFILE

<nckx>

<nckx>~ λ

<nckx>Some people think that variable is (1) used by Guix (2) to do stuff. Both are false :) It's ‘used’ by <a guix profile>/etc/profile to refer to the active profile, but these files fall back to their own profile if it's not set, and that's almost always correct.

<sepeth>Ok, thanks. One more question, are you using fish shell perhaps? If I don't do anything, I see some bin dirs in my PATH, but /var/.../guix-profile is not in there. It is easy to fix this with `guix package --search-paths -p` but then I can't su or sudo. Only I can do that if which su/sudo points to the ones under /run/privileged/bin.

<nckx>guix suggests setting it before sourcing (‘.’) …/etc/profile when it thinks something has changed, but it's not a general recommendation to set & keep it set.

<nckx>sepeth: Nope, basic bash user here.

<amano>I finally understood root btrfs on one LUKS device.

<sepeth>Ok thanks anyways, that clarifies things a lot. I think I need to use fish-foreign-env, but first I need to figure out how.

<nckx>I was typing something like that. Guix depends heavily on all these …/etc/profiles being sourced somehow, and you need a sh-compatible shell (or emulator) to do so.

<nckx>I can't help with the fish specifics but that name sounds like what you want.

<sepeth>If I understand correctly, fish-foreign-env allows you to source .../etc/profile via something like fenv source .../etc/profile.

<amano>Fish is kind of okay, but I wonder what's better...

<sepeth>amano, I like fish, I used to be a long time bash user, zsh bit me multiple times after short usage, so I swore an oath not to use it again :P I am not using fish for many things, but I like completion stuff and it remembers things.

<amano>I hate zsh due to its cimplexity.

<nckx>sepeth: On Guix System, I think sourcing /etc/profile will set up everything you need. IWBN if it set up fish and other non-sh shells for you, but that's a to-do.

<amano>By the way, if I use fish, what happens to /etc/profile? Perhaps, that's taken care of by another shell?

<sepeth>nckx: thanks, that's why I am thinking fish-foreign-env.

<nckx>Oh, I know, I was just rambling.

<sepeth>amano, normally fish wouldn't use it, but there's that project I mentioned, which I allows you to do fenv source /etc/profile.

<amano>I think /etc/profile is usually sourced by the login manager.

<amano>Thus, by the way you launch fish, /etc/profile is already taken care of.

<amano>The login manager uses another shell to source /etc/profile.

<amano>By the way, how does guix handle $PATH for shells?

<sepeth>Oh okay, I wonder eval `guix package --search-paths` in my fish config is the culprit that eats /run/privileged/bin then, because that path is added to PATH in /etc/profile.

<sepeth>Ok, I think I solved both my issues by removing guix package --search-paths and just adding /var/.../guix-profile/bin to PATH. Now I can su/sudo and run user installed programs at the same time.

<sepeth>Thanks folks ^-^

<amano>It seems fish requires a bit of manual configuration.

<nckx>What's a login manager?

<amano>Something like GDM and lightdm is a login manager.

<freakingpenguin>nckx: Synonym for display manager. The screen you see before signing in.

<amano>I mean display manager.

<nckx>Thanks.

<nckx>Not really something we can depend on (I don't use those, nor do servers).

<amano>I guess simplicity is best.

<amano>Let's imagine that I have efi partition and a btrfs LUKS root partition.

<amano>I want to type a password only once during boot. Does extra-initrd require entering the same password again?

<nckx>ACTION not ignoring you; doesn't know.

<amano>Or, does extra-initrd

<amano>My guess is that extra-initrd is read along with kernel and initrd with just one password input.

<amano>extra-initrd contains the keyfile, and the keyfile unlocks the root filesystem without a password.

<amano>The keyfile can also unlock all other non-boot LUKS devices.

<amano>Thus, one password boot can be made possible.

<nckx>I've been told that's how other distroes do it.

<vagrantc>you can generally append a cpio archive to the initrd as long as it uses the same compression type (e.g. gzip or zstd or xz or whatever)

<vagrantc>of course, then whatever extra-initrd or appended initrd bits need to be outside of /gnu/store, which is world-readable

<vagrantc>suspect it might need split /boot partition support: https://issues.guix.gnu.org/48172 ... or at least similar stuff

<amano>Is there a way to send a keyfile over ssh to a remote machine that has LUKS devices?

<amano>I wish zfs or bcachefs supports multiple key slots. Then, I can make encrypted backups without opening file systems.

<amano>But, btrfs is essentially dead....

<amano>btrfs was killed.

<amano>btrfs will not get native encryption because it is dead.

<graywolf``>Wut? BTRFS seems alive enough to me?

<amano>I think btrfs was forced to enter maintenance mode.

<amano>It stopped moving..

<amano>btrfs will never fix RAID5/6. It will never get native encryption.

<amano>Linus torvalds is unreasonable with forcing patches to be less than 100 lines.

<amano>If a large 1000+ lines patch is proposed by the author who claims the patch was tested thoroughly, he should accept patches.

<graywolf``>I personally do not care much about native encryption, LUKS works well enough.

<amano>If somebody proposes a large patch written by someone else, then reject it.

<amano>graywolf``: LUKS ruins encrypted backup without opening file systems.

<graywolf``>raid 5/6 would be nice, I agree

<amano>If you want to back up btrfs or zfs on LUKS, you have to open LUKS devices on the backup machine, too.

<graywolf``>I just backup the whole partition as it is

<amano>You want to use incremental backup machanisms provided by btrfs or zfs.

<amano>That's not an incremental backup.

<graywolf``>It is not, but you did not mention incremental backups

<amano>I want to make incremental encrypted backups. That requires native encryption.

<graywolf``>Where I need incremental backups, the filesystems to be backed up are mounted and opened anyway (since serving traffic)

<amano>LUKS forces incremental unencrypted backups.

<graywolf``>Why? I just have LUKS on the backup drive as well

<amano>I want to be able to back up to a remote untrusted machine.

<amano>I want somebody to provide untrusted storage over the internet.

<amano>Encrypted incremental backup is the only sane way to do that.

<graywolf``>You *can* do that on BTRFS

<amano>How?

<amano>BTRFS doesn't have native encryption.

<graywolf``>btrfs-send combined with gpg

<amano>Hmm????

<graywolf``>voila, incremental encrypted backup

<amano>I just don't get that....

<Hamled>are you preferring to back up complete filesystems bit-for-bit (just curious)

<graywolf``>For my laptop, yes, I just mirror the drive bit-to-bit to external hdd (with second copy in safety deposit box)

<amano>Does the btrfs send gpg solution support incremental backup?

<graywolf``>amano: Well you can use btrfs-send with output to file to get a stream of changes from last backup. Then you can just encrypt that file and upload it to you "untrusted" storage.

<graywolf``>Fundamentally that should work I believe.

<amano>But, I want to be able to delete old snapshots....

<graywolf``>So you just from time to time do full snaphost

<amano>That method will require the oldest snapshot...

<graywolf``>In the same way key-frames in video codecs work

<amano>That's why I said I want native encryption.

<amano>With native encryption, you can automate encrypted incremental backups.

<amano>You can also automate deletion of old snapshots.

<amano>I want automation.

<graywolf``>I am not sure this is related to native encryption. What I described above can be automated as well. And I am somewhat skeptical I can just take ZFS or whatever and have magical encrypted incremental backups in S3 with automatic pruning of old snapshots.

<graywolf``>I fail to understand how that would work.

<amano>I want incremental backups only.

<amano>Full backups will be too costly.

<amano>My backup program prunes old snapshots.

<amano>That means ZFS.....

<amano>If ZFS or bcachefs supported multiple key slots, I would use them.

<graywolf``>Out of curiosity how does that work? If backups as incremental, how are you able to prune old ones without rebuilding some kind of initial version?

<amano>graywolf``: ZFS somehow handles it.

<weary-traveler>handles what exactly? i.e., what does it mean for it to be "incremental". incremental from what?

<amano>ZFS can delete old encrypted snapshots without requiring a full backup again.

<graywolf``>I am skeptical that can work if the other end is "untrusted" as you described it. From quick reading it just removes snapshots from the pool. But for that the pool has to be somehow accessible no?

<amano>You can do that without unlocking zpool.

<amano>You don't have to unlock zpool in order to delete old encrypted snapshots.

<amano>That's the beauty of native encryption. You can do remote incremental backups and prune old snapthos without ever decrypting the snapshots.

<graywolf``>I fail to see how it can possibly figure out what to actually delete when it does not know the content (since it is encrypted).

<amano>ZFS can somehow do it.

<amano> https://www.reddit.com/r/zfs/comments/kyaatu/comment/gjfe1ro/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

<amano>This is it.

<amano>Learn to love native encryption without fear.

<amano>bcachefs multiple key slots will be the way.

<amano>But, LUKS is fine for trusted machines....

<amano>Trusted machines in my house.

<graywolf``>Out of curiosity, the thing you described with ZFS and deleting old snapshots without descripting, did you actually test it (including the recovery part)?

<graywolf``>It is interesting idea, so I am reading up on it, and the sources do not seem to confirm that.

<graywolf``>> This works for either full replication (moving every single block across the wire) or asynchronous incremental replication (*beginning from a commonly held snapshot and only moving the blocks that have changed since that snapshot*).

<graywolf``>Emphasis mine.

<graywolf``>So I am curious whether you actually works the way you described it.

<graywolf``>it*

<amano>graywolf``: I think I actually works, but I haven't done it, yet.

<weary-traveler>i get the feeling it's not been tested.

<amano>Other people say I works.

<amano>I think they have done it.

<graywolf``>Well the backuping part sure. But all articles I found seem to imply that work recovery you need all snapshots (since last full).

<weary-traveler>ACTION is a tad more skeptical of claims online especially in the day of LLMs

<graywolf``>And none describe that I could just delete random snapshots and it would still work fine

<amano>ZFS probably deals with encrypted filesystem blocks.

<amano>It is going to leak metadata that way.

<amano>It doesn't encrypt metadata.

<amano>It encrypts the file contents and the folder structure.

<graywolf``>So if snapshot A creates a new file with content "foo", snapshot B add "bar" and C "baz", B and C are incremental. And you just drop B. *How* will it know that when restoring the content should be "foobarbaz"?

<amano>metadata.

<graywolf``>Yeah I tap out, this does not go anywhere. Back to watching anime.

<graywolf``>Have a great night everyone.

<amano>I don't have details, but I think it's metadata.

<amano>I don't have a tech fetish. I don't have details.

<amano>If you still doubt, you can ask ZFS developers.

<weary-traveler>or you can come back and share the wisdom once you do try it

<amano>So, you refuse to believe it?

<amano>At least, you should be open-minded about it.

<weary-traveler>i believe there are claims. beyond that i do not know. and, seemingly, neither do you.

<weary-traveler>however, once you do try, you will know more so i encourage you to come back and share

<graywolf``>It either leaks enough metadata to be able to do it, and in that case it sucks as an encryption, or it does not, and then what you describe is not possible.

<graywolf``>I personally believe the latter to be the case, but I encourage you to give it a try. If it would actually work, it would be great.

<nckx>Maybe don't imply that people who don't take odd claims at face value are ‘closed minded’. It's up to you to back up your claims or drop the subject, not up to them to do your research.

<amano>graywolf``: Everyone says it's possible.

<amano>So, I assume it is possible.

<weary-traveler>ACTION is saddened that he isn't counted in everyone

<nckx>Yeah, it's quite rude and jims my jimmies.

<graywolf``>ACTION thinks he should print some "I am not everyone" stickers

<weary-traveler>heh

<graywolf``>Well I am off to bed, have fun everyone :)

<amano>nckx: It's not an odd claim. It sounds perfectly possible to me since ZFS native encryption is intimately integrated with ZFS.

<amano>I can already imagine ways to do it without going too technical.

<amano>Plus, people claim with confidence that it can be done.

<nckx>That means nothing.

<nckx>You'd think that getting Rust to statically link something would be easy. Instead, it tells me to use -fPIE. Talk about missing the point.

<amano>It would be an odd claim if everyone else claims zfs can't prune random encrypted snapshots.

<amano>But, I haven't read any claim that it can't be done.

<weary-traveler>i look forward to hearing from you once you've tried it

<amano>You can even scrub encrypted zfs file systems without decrypting them.

<amano>ZFS saves blocks, not files.

<weary-traveler>amano: i believe #zfs might be better suited to this discussion

<nckx>Oh OK this is great news to read during this exact task: <https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/>.

<weary-traveler>yeah, debian gave up

<nckx>I feel great sympathy for Debian.

<weary-traveler>nckx: you're working on bcachefs-tools?

<nckx>Yah.

<weary-traveler>trying to update, and running into dependency issues?

<nckx>No. Getting it to build post-Rust was fine, meh, tedious and frustrating, but that's Rust.

<weary-traveler>yep

<nckx>Getting it to compile statically is the current rub.

<weary-traveler>ah right. -fPIE

<nckx>(bcachefs-{tools-,}static)

<nckx>(we needs it for our initrdses.)

<weary-traveler>ah

<nckx>Mind you, I was surprised at the lack of dependency hell, and fear that I might've just got lucky this time.

<nckx>error: cannot produce proc-macro for `clap_derive v4.5.4` as the target `x86_64-unknown-linux-gnu` does not support these crate types

<nckx>This is not going in the right direction.

<nckx>I may punt.

<PotentialUser67>are there any people familiar with julia packaging online? I'm trying to package a pretty simple package but am getting non matching output when testing my package with multiple build rounds

<PotentialUser67>I'm unsure how to debug this. At first I thought it might be the test cases being non-deterministic, but even after disabling tests I still see this behavior

<nckx>PotentialUser67: I can't help you with Julia, but I can mention diffoscope as a tool that's often useful to inspect two mismatching builds. It can even disassemble binaries if you install the right packages.

<nckx>Also, don't let a irreproducible build stop you from submitting patches. You might even find help on the patch tracker.

<PotentialUser67>nckx: thanks, if I can't figure it out I'll go ahead and submit the patch and see if any reviewers have any ideas

<amano>weary-traveler: nckx : I just tested deleting random encrypted zfs snapshots without decrypting them, and the latest snapshot could be decrypted and mounted without any data loss.

<nckx>\o/

<amano>So, you were just playing me?

<amano>I backed up raw encrypted zfs snapshots, deleted random encrypted zfs snapshot backups, and mounted the latest encrypted zfs snapshot backup.

<amano>When everyone says something is possible, it's usually possible. There is no reason to doubt them.

<apteryx>amano: nckx is a very tongue-in-cheek type of guix :-)

<nckx>ACTION doesn't play.

<amano>I hate people who are skeptical for just fun or for no reason.

<nckx>I didn't see anybody in the original discussion doing that.

<amano>I hate academics because they are skeptical with everything they haven't heard of.

<amano>Rigid and close-minded.

<amano>Can't think outside the box.

<amano>No imagination.

<nckx>This doesn't seem relevant.

<Kolev>Hi all.

<nckx>It's also untrue.

<nckx>Hi Kolev.

<Kolev>I'm drunk and watching _M*A*S*H_. 😛

<Kabouik>I'm an academic currently working at 3.15 am on something I'm not skeptical about, you made me sad amano.

<nckx>Welcome to #guix late night.

<Kolev>Oh, and the _M*A*S*H_ is served by Jellyfin running Guix System.

<nckx>Kolev: Now I have the theme stuck in my head. Relevant, because dealing with Rust.

<Kolev>Rust and Guix are difficult.

<nckx>And not painless at all.

<amano>When many people say something with confidence, assume that they are lying willfully or saying truth. If they have no reason to lie, then they are probably telling truth.

<nckx>I wish that were true. Maybe it once was, in the early days of the 'net. It's not now. Trust, but verify. Which you did, and we thank you for it.

<amano>If people can't gain power or money from saying something, then they are at least speaking their truths.

<amano>You can't verify everything. That's the kicker.

<nckx>If that were true, there would be a lot less nonsense on the Internet. Nor is confidence an indicator of truth.

<nckx>(Replying to your previous message.)

<amano>nckx: That's why you have to follow money.

<amano>If you see a trail of money, then someone is probaably lying for money.

<amano>Some people are misled by disinfo agents. Like flat earthers.

<nckx>Yes, all the ‘Linux blogs’ with nonsense machine-generated articles telling you that you can run Sway in your initrd are doing so for money, just marginal amounts.

<amano>There are certainly misled people, but people usually aren't misled about technologies.

<nckx>(You can in fact run Sway in your initrd, poor example on my part.)

<amano>You perhaps can, but that's an abuse of initrd.

<nckx>My initrd actually runs weston.

<nckx>If you think I'm joking, I envy you.

<nckx>It's not my daily driver.

<amano>If you run sway in initrd, you are not my friend.

<PotentialUser67>so I'm seeing nonmatching builds on multiple julia packages I'm working on, I must just be doing something wrong

<PotentialUser67>I'll go ahead and send in one of these patches and hopefully someone else understands what I'm doing wrong

<amano>That's as nonsensical as frying eggs on top of mount everest. It can be done, but nonsensical.

<amano>You can just fry eggs in your house.

<nckx>PotentialUser67: Lots of toolchains, build systems, and upstreams do non-deterministic stuff. It's not necessarily your fault, and in this case not even likely.

<nckx>‘You wouldn't fry eggs in an initrd.’

<amano>Kabouik: The real test of open-mindedness is to at least entertain and research new ideas you are strongly skeptical about until you figure them out.

<amano>For example, I didn't reject flat earth until I did some research.

<amano>But, shape of the earth doesn't really matter because that doesn't change what we do daily.

<nckx>‘Going outside and looking’ is not a reasonable thing to expect of flat earthers. It's like asking #guixers to chat on-topic. Can't be done.

<nckx>Believe it or not, this is what progress looks like: http://paste.debian.net/plainh/66c6662a

<amano>That's not progress.

<amano>Not everything moves forward or upward over time.

<amano>Do modern apartments look as good as alexandria of egypt 2000 years ago? Traditional buildings that had been built until world war 1 looked much better than modern apartments.

<apteryx>hm, the OVH vps KVM web screen to the machine doesn't register shifted inputs... defeats GRUB rescue

<nckx>No, but my random ‘cargo build’ arguments are converging on something, and I call that progress.

<apteryx>ACTION falls back to 'guix system init' scheme proposed by nckx yesterday

<mirai>and people say AI is going to replace programmers and staff 😂

<amano>In many ways, the world is regressing backwards...

<nckx>So far I'm at -C target-feature=+crt-static -C relocation-model=static --target x86_64-unknown-linux-gnu (remember you need the --target, even though you're not cross-compiling, because Rust is the future) and at least now the errors have changed their mind from ‘you're trying to link statically, stop that, add -fPIE’ to ‘you're trying to link statically, stop it, I'll tell your mother’.

<nckx>amano: On that much, we agree.

<nckx>But if Rust is feeling threatened, I'm happy.

<amano>Is it impossible to statically compile bcachefs-tools on guix?

<nckx>Nothing is impossible, plus I have a full week-end.

<nckx>And I see no reason to suspect that this is Guix-specific.

<nckx>Re: Debian noping out yesterday.

<nckx>For the record, the bcachefs-tools version currently in Guix works just fine, both dynamically & statically. It's the new Rust releases that pose problems.

<amano>Is there an easy way to execute a few commands to unlock zfs or bcachefs with a password in initrd?

<amano>Then, it's a rust issue.

<nckx>I thought my frequent use of the word ‘Rust’ above implied as much.

<weary-traveler>amano: were the encrypted snapshots you deleted ones created from incremental backups? if so, that's both surprising (to me) and great news

<amano>weary-traveler: I created incremental backups only.

<amano>after the first full backup.

<weary-traveler>amano: and just to be clear, it's not the first full backup you deleted?

<amano>I didn't delete the first backup.

<amano>I created 1 full backup and 3 incremental backups. I deleted the first two incremental backups.

<weary-traveler>i see. so that answers the question i had asked previously. incremental to what? the first backup

<amano>Incremental to the first backup.

<weary-traveler>and given that that wasn't deleted, this is not surprising. thank you, regardless, for verifying

<amano>The lesson is that when people say something is possible with a widely available technology, it's usually possible.

<vagrantc>i thought there was no such thing as incremental with COW tree-based filesystems ... each generation includes everything necessary to complete it...

<amano>Anyone can reproduce the steps easily, and if someone is wrong, there will be objections.

<weary-traveler>i don't believe that's the lesson here. in fact, you doing the experiment allowed you to communicate an essential detail, one that was unstated in the previous exchange. the assumption that a first full backup is to be retained

<nckx>amano: Thanks for taking the time to prove your claims. That was the real lesson, after all.

<vagrantc>ACTION still uses a sorted pile of rocks for my /gnu/store

<nckx>Not ‘believe people when they type stuff’. Don't do that.

<weary-traveler>vagrantc: it does. but since you get diffs for free, you can send those diffs. e.g. btrfs-send

<vagrantc>weary-traveler: right, but the concept of a "full backup" is somewhat ... not the right metaphor?

<vagrantc>nckx: i can take a picture of my rockpile as proof! :)

<nckx>Perhaps that is your true quarrel with academics. When you say ‘I can fly!’ they say ‘Cool! Show me.’

<nckx>vagrantc: I call photoshop.

<amano>Do I have to show you that airplanes can fly, too?

<nckx>Now if the rocks are arranged in the shape of a face on Mars, I'll believe you, because I read on a forum that aliens.

<vagrantc>my rocks are larger than mars. i can barely see mars.

<nckx>amano: I'm going to say yes, because that would be amusing.

<amano>Amusing to make someone bend backwards...

<vagrantc>nckx: feels like good old times having you here. :)

<weary-traveler>vagrantc: agreed. it's probably more accurate to call it an "initial snapshot". and given an initial snapshot that's retained, other incremental encrypted backups can be pruned at will without decryption. which is plausible (and not what i understood from the premises in previous discussion)

<amano>The proof is in the sky. You see airplanes in the sky.

<nckx>(I… thought that was implied, yes.)

<nckx>I live under an approach route. I know.

<weary-traveler>chemtrails. better be ware.

<amano>I don't have to rent a private jet and drag it to your house just to prove to you that airplanes can fly.

<weary-traveler>i read about them online as well.

<nckx>Not sure what this has to do with ZFS but if I see ZFS fly over I'll call the cops.

<vagrantc>amano: dragging it does not bode well for proof of flight.

<amano>Do not doubt native encryption again.

<weary-traveler>heh

<nckx>amano: Ekskuse moi, I use bcachefs, I'll doubt native encryption as much as I please!

<nckx>vagrantc: :3

<nckx>Sorry for intruding upon your diffoscope.

<vagrantc>nckx: it's already gone stale. I submitted an update! :)

<nckx>That's the nice thing about diffoscope. Even when you updated it, no you didn't.

<weary-traveler>amano: i don't believe anyone was doubting native encryption. your statement of premises previously and presently have a material distinction. perhaps not to you, but certainly to others not privy to your thoughts. it wasn't clear that you were okay and were assuming an initial snapshot that's retained forever

<amano>Will guix support encrypted bcachefs filesystems during boot?

<vagrantc>ACTION is one of the preeminent members of the reproducible team, primary responsibility being diffoscope

<vagrantc>s,one of,,g

<amano>weary-traveler: If the initial snapshot is gone, the blocks referenced by other snapshots will still be retained.

<amano>Garbage collection.

<nckx>amano: Good question! …yes, but. I've not actually tried booting off of one. And I'm not sure anyone else uses Guix System on bcachefs yet.

<amano>Guix maintainers failed to merge ZFS support in time.

<vagrantc>does bcachefs still require a custom-built kernel?

<nckx>amano: As previously explained, Guix maintainers don't merge anything. Patches welcome.

<amano>vagrantc: bcachefs is mainlined, but linus torvalds regrets mainlining bcachefs because bcachefs developer wants to push large patches....

<vagrantc>amano: i daresay that may be one of principles

<nckx>Also, resenting the implication that Guix maintainers do anything on time.

<amano>Linus torvalds wants patches smaller than 100 lines, and bcachefs developer wants to push patches that have more than 1000 lines.

<vagrantc>amano: there are complicated licensing questions around ZFS

<amano>You just have to avoid distributing zfs substitutes.

<nckx>amano: I'd say it's pretty clear that it's an attitude problem more than a line count problem. Even I'm getting fed up with Kent's tone towards subsystem maintainers.

<vagrantc>amano: that is a technical workaround

<amano>That's the correct solution.

<amano>When will bcachefs gain multiple key slots? When will guix support booting off encrypted bcachefs file system?

<nckx>Why are we here? What does rizz even mean?

<nckx>So many unknowable questions.

<amano>Ubuntu just provides zfs kernel modules, and it has been fine. God favors courageous people.

<weary-traveler>amano: i get the feeling like there's another implicit assumption in your statement. for instance if a block $foo is introduced in $1, unmodified in $2, modified in $3. and now $1 and $3 are deleted without decryption, either $2 contains the contents of $foo, or deleting the encrypted snapshots didn't free space, or $foo is gone

<weary-traveler>$1 is the initial snapshot/full backup in this case

<amano>weary-traveler: Don't worry. ZFS will not lose your data.

<amano>ZFS is known for not losing your data.

<weary-traveler>ah, then who needs backups

<vagrantc>amano: countless entities violate the GPL too ... but that does not make it right.

<amano>I mean deleting snapshots won't lead to unexpected data loss....

<amano>vagrantc: Right and wrong are objective. Under god's objective definition of right and wrong, GPL is not right.

<weary-traveler>i believe that. i also believe there's something unstated in what you said above. in any case, probably more on topic for #zfs

<vagrantc>amano: who am i to argue with god. can't even find them.

<amano>God is hiding...

<nckx>I think you scared Him.

<nckx>Were I god, the last thing I'd want is to be called upon to arbitrate alleged GPL violations.

<vagrantc>and yet...

<nckx>More to the point, god has no authority here, so let's leave such arguments aside.

<amano>God's law is clear, but God allows people to violate his law. However, the penalty for violating god's law is going into deeper levels of slavery.

<vagrantc>and deeper levels of off-topic

<nckx>Yeah, this seems to cross a new line. Let's leave god's irrelevant opinions out of this.

<vagrantc>well, irc might be a barrier to entry...

<nckx>They can nickserv register like anyone else!

<vagrantc>settled.

<nckx>(Unless they use Tor.)

<amano>nckx: God's law is clear on this. God rejects GPL. But, I won't go deeper into explanation of god's law because I have already gone off-topic enough.

<nckx>Amen.

<vagrantc>yeah, lets stick to things like sharing and helping our neighbors by reviewing patches submitted to guix :)

<nckx>Seriously: early bcachefs decryption testing welcome, patches (if needed) doubly so.

<vagrantc>i nudged for so long to get the privledged-programs and now that i have it i forgot to hang on to the cargo-culted bit to enable it in my system config ...

<nckx>It's just not a use case I have.

<nckx>I'd just not lose my laptop. It would be easy for me.

<vagrantc>i might just have to read the documentation that came with it

<nckx>vagrantc: Can I help?

<vagrantc>nckx: oooh... on-line documentation, literally!

<nckx>You're assuming I remember anything about the 2-year old patch series I pushed. I like your rizz.

<vagrantc>nckx: i will actually try first, though. so far it is just as far as "i should actually test that again or something"

<nckx>Okily.

<vagrantc>nckx: i did not assume it was good on-line documentation.

<vagrantc>but definitely fun.

<vagrantc>ACTION found config-capabilities.scm laying around and rejoices.

<amano>If bcachefs gains key files and multiple key slots and grub supports encrypted bcachefs filesystem, then I can put a keyfile in extra-initrd and mount every file system with a key file.

<amano>For now, only LUKS has multiple key slots.

<nckx>vagrantc: If of any use, here's mine: http://paste.debian.net/plain/1328015 The helpers seem excessive now. I used to have more users.

<nckx>amano: That sounds right. I haven't kept abreast of GRUB development lately; I wouldn't hold my breath for *encrypted* bcachefs support :-/

<vagrantc>nckx: thanks for sharing!

<nckx>For anyone wondering what the difference is between +pe and +ep: it's which page I cargo-copied them from.

<amano>Has anyone found a way to conveniently make incremental encrypted backups to a remote untrusted machine with btrfs on LUKS?

<apteryx>nckx: I've split the 20GB drive into 15GB and 5GB, bind mounted the 5GB on /gnu in the rescue, and reattempting 'guix system init' :-)

<apteryx>with vagrantc's provided 'guix' apt package (thanks!)

<vagrantc>apteryx: yay!

<vagrantc>apteryx: although, from the sounds of it ... mostly ... eeeyk!

<nckx>May your /var/guix/db remain slim! It should…

<vagrantc>and yay:

<vagrantc>getcap /run/privileged/bin/lcsync

<vagrantc>/run/privileged/bin/lcsync cap_net_raw=eip

<vagrantc>hah. and i even have my evil setuid "true" in there too.

<amano>I think I figured out a way to unlock any number of zfs/bcachefs file systems with one password during boot.

<vagrantc>maybe should remove that... just in case.

<amano>Unlock bcachefs filesystem in #premount function passed to base-initrd.

<amano>Put bcachefs-tools in initrd as well.

<vagrantc>may you have all the parens you need.

<vagrantc>PotentialUser67: oh, i had a peek at julia reproducibility issues a while back, but don't think i came up with much.

<amano>Damn, I have to use raw-initrd instead of base-initrd if I want to use #premount function.

<vagrantc>PotentialUser67: looks like i ran diffoscope on it back in march, and ended up with a zstd-compressed diffoscope output of ... ~140MB

<vagrantc>amano: it is very DIY.

<amano>At least, guix allows me to customize initrd with raw-initrd and base-initrd.

<PotentialUser67>vagrantc: I'm glad to know at least I'm not the only one who has encountered issues

<vagrantc>i thought it rang a bell ...

<nckx>amano: Your initrd should already have bcachefs in it if you declare a bcachefs file-system.

<vagrantc>dangerously close to two bcachefs guix users...

<nckx>Unless you're really building your own from scratch.

<vagrantc>:)

<amano>I think I can use zfs on guix if I write some services and use raw-initrd.

<amano>It seems to me that base-initrd should accept #premount.

<amano>?Then, it becomes easier.

<amano>What #premount does: zpool import -a -N -> Prompt for password -> pass password to zfs load-key zpool

<amano>I think I can already unlock multiple bcachefs filesystems with one password through raw-initrd.

<PuercoPop>if I change the commit the a package's source points to, but not the version it seems that guix is not trying to rebuild the package. Is there a way to force the rebuild in those scenarios?

<nckx>PuercoPop: Which package?

<nckx>The hash is what identifies the source, along with the file name. Usually the file name incorporates the version, though.

<vagrantc>if the hash already exists in the store it may re-use the existing hash

<nckx>True, but I fear that wording it that way might confuse people.

<PuercoPop>nckx: sisyphus, from my personal channel. I don't really use versions as its still in flux. I have it set to 0.0.1. https://git.sr.ht/~puercopop/glue/tree/9a949e1549a21eae4a71a5f8503b7acaee50684a/item/glue/packages/sisyphus.scm#L21

<vagrantc>nckx: agreed! i like your words better.

<nckx>Then they start looking for a ‘clear cache’ option or a ‘really force rebuild’ option which is missing the point that they are actually asking Guix to build the same old thing.

<nckx>They just don't know it yet.

<vagrantc>going to head out before i sow more confusion!

<vagrantc>ACTION waves

<PuercoPop>But if the URL changed, I would expect guix to download the asset again and then see it changed (it doesn't have the same sha) and then rebuild it

<nckx>No.

<PuercoPop>What seems to happen is that guix says, same package and same version and decides not to rebuild

<nckx>That's the incorrect expectation. Some systems may work this way.

<nckx>No, it's not looking at package or version.

<PuercoPop>(the store path seems to be $package-name-$version)

<nckx>If Guix worked as you describe, it would have to redownload each source file every time to check whether it changed hash, or use an (error-prone, irreproducible) caching system with an arbitrary TTL. It does neither.

<vagrantc>that's for the humans ... the computer doesn't care what it's called :)

<PuercoPop>Ok, so if I don't update the hash from the package, if it already knows about the hash it re-uses the derivation previously built?

<nckx>Guix sources are content-addressed. That means that the *hash* identifies the source.

<nckx>You previously asked Guix to build sysiphus from source ‘luczwjra’. Later, you change some stuff above the hash, but you're still asking Guix to build sysiphus from source ‘luczwjra’. Guix sez: I already did.

<nckx>Now, there's a bit of a catch, in that if you did use the version as part of the file name, Guix would simply not find a file at the old /gnu/store location, and it would redownload the source, and it would throw an error that it doesn't match hash ‘luczwjra’.

<nckx>So ‘I don't really use versions’ is risky.

<PuercoPop>nckx: No, it could track the provenance of each derivation as well as the hash. But I guess it makes sense as the fetcher is a layer above the store, the store doesn't know about fetchers

<PuercoPop>In nix when I updated the URL and rebuild it complained about wrong hash, gave me the correct one so I could updated. I was using the same flow.

<nckx>But we don't want Guix to redownload stuff just because the URL changed, or because we added another URL to a list.

<nckx>The URL is a locator. It is not an identifier.

<nckx>See it as a hint of where Guix can find something by this hash, but if you don't change the hash, you're explicitly (if not deliberately) saying any existing copy is identical.

<nckx>What I want to know is: how do you get a nix-base32 starting with ‘l’?

<PuercoPop>that is not a nix-base32

<PuercoPop>I called guix download -f base32 --commit .... to get it

<nckx>I don't think that will work.

<PuercoPop>ok, so I leave the format as the default

<nckx>But then I haven't tried using (sha256 (base32 "…")) with ‘real’ base32, I think ever.

<PuercoPop>Because the symbol says base32, I assumed it was base32 when I read the man page for guix-download

<nckx>I'm suprised you even got Guix to accept that.

<PuercoPop>nckx: question, why did changing the verison did trigger a rebuild? Although it didn't trigger a warning about wrong hash so I now assumed it built the previous commit

<nckx>Anyway, what I usually do (and why I ask) is negate the first character of the ‘nix-base32’ hash, which is always ‘0’ or ‘1’. So it's easy to flip.

<nckx>PuercoPop: It triggered a rebuild but not a re-download.

<nckx>The source is a separate derivation from the surrounding package.

<PuercoPop>I didn't run that locally. I left the hash as it, updated the version but not the hash. When I saw guix build work I assumed (wrongly) it was working. I was surprised it didn't compain about the wrong hash.

<PuercoPop>so I used guix download to obtain the new hash

<PuercoPop>Now that you pointed out it is the wrong format, I updated the hash again

<nckx>Your package depends on the version, but your source doesn't. You can make the source depend on the version by using something like (file-name (string-append …something… version …something…)).

<nckx>PuercoPop: I just meant that I expected Guix to reject that hash at a very early stage, long before it ‘did’ anything.

<PuercoPop>Question, if I updated the commit and leave the hash empty guix doesn't try to download the asset and error out due to a hash mismatch right?

<nckx>But if you mean you never ran that code, then I understand.

<PuercoPop>if I update the hash but not the package version, will guix rebuild the package if its mentioned in my home-configuration?

<nckx>PuercoPop: (base32 "") isn't a valid hash so that won't work, it'll simply fail to parse. You could use the hash of nothing (0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73) but really any bogus hash will do.

<nckx>Since the hash is the only thing truly identifying the source, it has to be there. Guix could provide some mechanism for it to be missing, but doesn't.

<PuercoPop>nckx: yes, that is my experience. It might be worth it to treat the symbol 'bogus-hash as a special case meant to tell the user which hash it should fill in

<nckx>Maybe, although simply setting a variable to the empty hash seems less convoluted (we could move & export the one already in (tests lint)).

<nckx>Personally I'm a bit hesitant to facilitate these kinds of workflows.

<weary-traveler>is there a way to transform a package $foo to remove one of its inputs $bar? currently, i use a "$bar=$qu" with-input transformation where $qu is a void/nop package definition

<weary-traveler>*is there a better way

<nckx>There is modify-inputs…delete for Scheme code but I'm not aware of a CLI equivalent.

<nckx>--without-inputs? :)

<nckx>ACTION 😴💤

<Noisytoot>If I have multiple packages in the same profile both installing the same file (like go and gccgo both installing the "go" binary), how can I specify which one is installed in my profile?

<weary-traveler>yes, a --without-input is effectively what i'm looking for

<pabs3>amano: what do you mean by "generic OS images"? (re ARM/RISC-V not having them)

<amano>pabs3: You haven't used linux on ARM boards?

<pabs3>I have yes

<amano>For now, bootloader and linux must be compiled differently for each ARM board.

<amano>An arbitrary linux distribution can't be installed on an ARM board.

<amano>a generic OS image, if it exists, can be installed on any ARM board.

<amano>A linux distro installer is an OS image.

<PuercoPop>nckx: another alternative would be to allow refresh to work on commits and not only tags. My first approach was to try guix refresh. Although it would be tricky as for some reason the commit attribute accept tags

<pabs3>hmm, I thought with modern Linux and modern standards-compliant ARM, its just preinstalled UEFI/ACPI booting GRUB/Linux like on x86. there are plenty of non-UEFI things though

<amano>pabs3: There is no ARM board that supports UEFI and ACPI properly out of the box.

<pabs3>hmm, I thought those ARM Thinkpads were doing it that way

<amano>What about ARM desktops?

<pabs3>I'm not aware of any yet

<pabs3>for the non-standards-compliant SBCs, the distro provided u-boot binaries are available for most boards that got upstreamed, and u-boot can provide UEFI too

<amano>I don't want to board-specific OS images.

<amano>That's why I don't buy ARM boards.

<pabs3>at least for Debian, they aren't full OS images. you first write the u-boot for your board, then add the OS image after that

<amano>I haven't found an easy way to install u-boot for any board I like.

<amano>And, mainline linux doesn't support many ARM boards.

<amano>I just want computing to be simple.

<pabs3>hmm, I'm counting 2648 .dts files in arch/arm*/boot/dts/ so a lot of boards have at least some support

<amano>I still don't have an easy way to install u-boot for any board I like.

<pabs3>Debian has a tool for that, here is the list of boards: https://salsa.debian.org/installer-team/flash-kernel/-/raw/master/db/all.db

<u0_a280>anyone using emacs on their pocket snitch (android, unrooted)? care to share any config/notes/*.el/advice?

<wizard>oh i do u0_a280

<u0_a280>oops wrong channel, sorry for offtopic spam

<u0_a280>:D

<wizard>i run emacs through termux

<wizard>sync with syncthing

<wizard>sync notes* with syncthing

<wizard>works really well

<wizard>my config is normally managed by guix

<wizard>but since that doesn't work on android (easily), i have a (unless guixp ...) form to load elpaca on those systems

<wizard>it all works very well!

<wizard>i've got termux configured to load into emacs automatically, i use it for recording dreams and stuff in the morning

<wizard>uhhh, unexpected keyboard is what i'd recommend you use if you don't already

<wizard>it has a control button and everything

<wizard>u0_a280: https://codeberg.org/wloxyz/guix-configs/src/branch/main/home/config/emacs/init.el

<wizard>my config is here if you wanna see it, i did very little to make it work on mobile and it tends to Just Work

<u0_a280>thank you very much wizard !

<wizard>o7

<apteryx>nckx: ovh vps, continued; mystery, the drive is not found while booting. perhaps it's exposed via some fancy mechanism and I need to add something to the initrd

<apteryx>in the cookbook there's a linode config that mentions virtio_scsi is needed in initrd-modules to "find the disk"

<apteryx>perhaps that

<amano>I found two formulas for fully encrypted systems.

<amano>1. btrfs root system on one LUKS device. btrfs raid10 on multiple LUKS devices.

<amano>2. btrfs root system on one LUKS device. encrypted bcachefs raid10 or encrypted zfs raid10 on multiple devices. bcachefs, zfs, and btrfs can be unlocked together with one password in #premount function of raw-initrd.

<amano>In both cases, root system is not backed up because it doesn't contain any valuable data. The encrypted non-root file systems are incrementally backed up.

<apteryx>I'm trying to reconfigure a 'guix system' that has *never* booted successfully (but it 'guix system init'd OK). It seems /etc hasn't yet been populated, and hence it won't connect to the network; ping gives me e.g.: ping: unknown protocol icmp.

<amano>encrypted non-root btrfs filesystem should be backed up by other btrfs filesystems on LUKS devices. LUKS keyfile can be sent remotely from the main machine through luksrku, or I can type the password manually.

<amano>bcachefs and zfs don't require unlocking for backing up.

<amano>If you use bcachefs or zfs, you can make encrypted backups on untrusted VPS instances...

<amano>LUKS requires trusted machines for incremental backups.

<amano>apteryx: You can use a usb stick live guix system for that.

<apteryx>I'm debugging a VPS; no usb stick for me, but I have a rescue which is a minimal debian and I can 'apt install guix'

<apteryx>I've managed to get GRUB to try to boot Guix, and the Guix initrd currently doesn't find the partition, although I've double checked the UUID

<apteryx>I'm not re-initing with the virtio_scsi module added to the initrd-modules

<apteryx>I'm now*

<Rutherther>apteryx if guix is able to start the boot, the partition uuid has to be correct, at least if it's the disk with /gnu/store, and I guess you didn't really go for multi-partition setup on a vps

<Rutherther>if the uuid was incorrect, GRUB would fail in failing the kernel or initrd

<Rutherther>s/failing/finding

<apteryx>Rutherther, nckx success!

<apteryx>the virtio_scsi initrd module was key

<Rutherther>great!

<apteryx>otherwise it's the barebone config with (kernel-arguments (list "console=ttyS0 console=tty0"))

<apteryx>plain grub

<civodul>o/

<sneek>civodul, you have 1 message!

<sneek>civodul, rekado says: oh, good to know that libcamara (aarch64) built on the build farm. Perhaps these two test failures are due to me building via the binfmt qemu thing.

<civodul>cbaines: hi! https://qa.guix.gnu.org/branch/core-updates is looking good IMO

<amano>Does unlocking a bcachefs filesystem count as device mapping?

<civodul>ACTION has never used bcachefs

<amano>I guess not.

<cbaines>civodul, it's not bad, but it's significantly worse than master

<cbaines>I'm not against merging, this core-updates cycle has been terrible and it would be nice to get it over with, but ideally we'd have more things built

<nckx>amano: Nah.

<civodul>right, but there’s always the risk that if we wait, we’ll lack behind again

<civodul>because more build power will go to things on ‘master’, and then rebases, etc.

<nckx>apteryx: Thanks for keeping me informed! I was wondering.

<cbaines>well, if things go to the right branches and changes don't skip ahead of core-updates, that shouldn't happen

<cbaines>obviously that's been happening so much over the last few months, which is mostly why the substitute availability has kept dropping

<cbaines>(and why some rebases have been so difficult)

<civodul>yes, though if we apply a patch with 200 rebuilds on master (which is legit), then we’ll have that same amount on core-updates

<civodul>that’s unavoidable i guess

<cbaines>indeed, and changes of that size hopefully shouldn't take too long to catch up with, even if there are a few of them

<civodul>on some architectures it does take a lot of time

<civodul>only 2 arm builders left at ci.guix :-)

<civodul>anyway, how about waiting for a few more hours before merging?

<civodul>actually, do you want to be the one pressing the red button?

<cbaines>things aren't currently building, at least on bordeaux as there's a bug in QA

<civodul>ok

<cbaines>so there's no value in waiting, but I don't want to be the one to push

<civodul>alright

<civodul>i can take that responsibility

<civodul>i’ll be the one to blame!

<ngz>This chan is more intense than a soap opera! ;)

<civodul>nckx: perfect :-)

<jakef>exciting times

<civodul>ngz: you can feel a tension, will it be merged or will it not? check out the next episode!

<nckx>I'll be helping a friend move, so I'll be missing all the popcorn.

<civodul>oh, we’ll make sure not to spoil when you’re back

<ngz>heh

<civodul>in other news, “guix deploy -L modules deploy-node-129.scm” fails with: canonicalize-path: No such file or directory: "/home/ludo/src/maintenance/hydra/nginx/html/hydra-guix-129"

<civodul>does that ring a bell to anyone?

<civodul>(that node is running an old cuirass-remote-worker)

<cbaines>every time I've reconfigured that machine, I've done it from the machine without guix deploy

<cbaines>I think there's something in the header about guix deploy not working

<pjals>Is #:make-flags '("CC=gcc") really required? This seems like it would backfire, what if some user wants to replace gcc with clang for their entire system? (woah, evil! definitely not me!)

<Rutherther>you should use "=(cc-for-target)", no "=gcc"

<pjals>Neat.

<pjals>Wait, huh? '(#:make-flags `(,(string-append "CC=" (cc-for-target))) ...) just yells at me..

<pjals>Ok so that's in (guix utils). Forgot to use that.

<nckx>If my mobile eyes don't deceive me, you're quasiquoting the wrong level. CC-FOR-TARGET is supposed to be called on the host side. You're calling it at build time, because the outer ' trumps all. No?

<nckx>Might be worth jumping to gexps at this time, IMO they are slightly more clear in such cases. (arguments #~(let's go, do #$host stuff)) boom.

<pjals>Yea I fixed that part too ;)

<pjals>I just searched the error, found something referencing the lua package, and copied how lua does it.

<pjals>Though, I'm fully in support of transitioning to gexps, for newer Guix users it just causes confusion for that not to use gexps (why did I learn them anyway?!)

<nckx>Agreement. So did fixing the quotation fix your error, or is CC-FOR-TARGET still yelling at you? (I don't see why it would…)

<pjals>It did fix the error.

<nckx>Oh good.

<pjals>So I have a problem. I'm building a compiler and the compiler seems to require having a build cache for it to build anything. However when building itself it tries to build its own documentation (which is written in the language) and therefore tries to make /homeless-shelter/.cache/hare. I'm not entirely sure where I should be storing the build cache though..

<pjals>Should I just dump it in /tmp ? That seems like a good idea.

<pjals>And gotta love not having proper time namespaces in the guix build namespaces so some tests fail ;)

<nckx>s/guix build/Linux/ AFAIK, but point taken.

<nckx>Yes, just setenv HOME to /tmp.

<nckx>Or (getcwd).

<nckx>It doesn't really matter, just put it wherever you feel least dirty.

<pjals>Seems like hare's cache system is well-behaved so it uses XDG_CACHE_HOME, I set that to /tmp.

<pjals>Anyway yay, I have built the entire hare toolchain including bootstrapping in just 100 lines!! (including comments and license!)

<nckx>Wow. Impressive work.

<pjals>Of course, it can't find the standard library because apparently PREFIX=out isn't enough to convince it, though that should be a pretty simple fix that should actually *save* lines..

<pjals>There we go, Hare and it's standard library fully bootstrapped in 101 lines. (not quite 100 though ;)

<pjals>Guess I should send a patch instead of hoarding the packages (like I do way too much in my dotfiles..)

<pjals>Should I create a seperate module in case we might want to package more hare things like hare-json? Or should I just dump it in (gnu packages language)?

<nckx>I would err on the side of a new module (or even hare.scm for the core/bootstrap + hare-xyz.scm for random ecostuff).

<nckx>Those 101 lines are unlikely to shrink.

<nckx>And inodes are cheap. *laughs in ext4*

<pjals>Authenticating commits 9edb3f6 to d531237 (80,617 new commits)...

<pjals>oh boy..

<dariqq>inodes are only cheap if you dont use papirus icons

<amano>I finally solved disk encryption problem.

<amano>There are two ways to solve this.

<pjals>Is it full-disk?

<amano>Nearly.

<pjals>Nearly meaning /boot remains plain?

<amano>1. /boot on EFI partition for grub config and EFI images. root filesystem is btrfs on one LUKS device. non-root filesystems are distributed among LUKS devices. grub prompts a password for reading a LUKS keyfile from btrfs root filesystem on LUKS. After getting the keyfile, everything is unlocked.... without another password prompt.

<pjals>Also, should I do ecostuff as a seperate patchset? It might be a bit overwhelming to include it in the patchset that adds Hare.

<pjals>I wonder if you could protect EFI images from tamper with secure boot, that would be interesting on Guix.

<amano>2. /boot on EFI partition for grub config and EFI image. /gnu/store is in a separate unencrypted partition for passwordless access to kernel and initial ram disk. initial ram disk is consturcted by raw-initrd where #premount prompts a single psssword for unlocking encrypted zfs file systems and encrypted bcachefs file systems.

<amano>pjals: The better solution is to run a boot service that checks integrity of /boot files.

<pjals>Aw, unencrypted /gnu/store? That makes it so easy to tamper with the system!

<pjals>amano: Doesn't LUKS run really early? We would be checking when its already too late

<amano>However, the second option grants you the ability to make incremental encrypted backups on untrusted VPS instances.

<amano>You can send raw encrypted zfs snapshots to untrusted VPS instances.

<pjals>I do want to make a (enroll-keys-service-type) someday.

<jpoiret>unencrypted /gnu/store is a dealbreaker imo

<amano>It is not if your threat model is theft or confistication rather than evil maid.

<amano>/gnu/store doesn't contain any sensitive information like pirated movies.

<pjals>It would be nice to roll everything needed to load Guix without the store into a single EFI image and then sign it.

<amano>And, you are able to send raw incremental encryptd backups to untrusted VPS instances if /gnu/store is unencrypted.

<amano>Just send encrypted zfs snapshots to VPS instances, and police officers can't open it without knowing the password or having the key file.

<amano>This is a solid off-site backup solution.

<amano>If you use LUKS only, then you can't send sensitive backups to VPS.

<pjals>amano: The /gnu/store can contain config files and if there's sloppy code, might contain secrets. (even though it shouldn't, Guix should account for a multi-user system)

<amano>Config files aren't really sensitive.... if they exist in /gnu/store at all.

<amano>People share their config files on the internet.

<amano>And, you should have to go out of your way to put secrets in /gnu/store.

<amano>The ability to make incremental encrypted backups is a huge advantage in my opinion.

<amano>If you choose LUKS for encryption, you are limited to trusted machines for backups.

<insomniac>This again? Did you actually try it since last time?

<amano>Sometimes, I solve puzzles in my head...

<amano>I went through various options in my mind, and came up with two ways.

<amano>One way is btrfs + LUKS only which limits you to trusted backup machines. Another way is unencrypted /gnu/store + encrypted zfs/bcachefs file systems which allows you to make incremental encrypted backups on untrusted VPS instances.

<amano>Other ways are either impossible or require entering the same password multiple times.

<amano>Or not possible, yet.

<insomniac>I am skeptical of "solving puzzle in your head" when you yourself acknowledged that you do not know how it works, so there even is no certainty that it will work

<amano>I read codebase, and I think I know how it works....

<amano>I already understand how initrd is configured in guix at some level.

<insomniac>I meant the incremental encrypted backups

<amano>I understand incremental encrypted backups.

<amano>I have used zfs native encryption for years.

<amano>Sanoid automatically take zfs snapshots.

<amano>I have used incremental backups in tiny zfs pools.

<amano>I tested tiny zfs pools.

<jpoiret>so is it merge day?

<amano>merge what?

<insomniac>Well last time you claimed that you did not yourself test the recovery from snapshots send with --raw when you delete old ones

<amano>There is nothing to merge. I have found two ways to work with the current version of gnu guix.

<insomniac>jpoiret I think so :)

<amano>insomniac: Other people claimed that it works, and I trusted them because I could easily imagine how it would work with pointers.

<insomniac>Someone above posted that many new commits are being checked, maybe it merged already? Did not check git yet

<insomniac>Ok sure whatever. You do you and enjoy the data loss down the line.

<jpoiret>not yet, I just git pull'd

<amano>insomniac: I have put more time in data integrity than you have.

<jpoiret>rebasing all of it takes time tbh :)

<amano>That's why I can make seemingly convoluted moves.

<amano>I haven't lost a file in my memory.

<insomniac>ACTION has somewhat hard time adhering to CoC...

<jpoiret>no need to continue the discussion further if that's how you feel :)

<amano>I feel frustrated by people who question every little thing.

<insomniac>I am looking forward to the merge, kept today empty to update all my machines :D

<insomniac>And I feel frustrated by people who buy any random snake oil they can get their hands on

<insomniac>¯\_(ツ)_/¯

<amano>insomniac: Are you claiming that I am buying snake oil?

<jpoiret>yeah I was about to do something else but I remembered and wanted to be there for the merge at least since I kinda disappeared halfway this c-u cycle

<amano>Are you just trying to feel superior to other?

<amano>There is no explanation or logic behind your claims. I have explained a lot of things.

<insomniac>That is fine, everyone if volunteering :) I really should ask for commit bit and do my part

<jpoiret>insomniac, amano: it'd be probably better to at least keep the discussion to technical claims at least

<insomniac>Do not worry I am done from here on :)

<nckx>amano: <There is nothing to merge.> FYI, today is the core-updates merge. This chat is not just for you. Please be more respectful towards other participants. It's becoming a distraction

<pjals>Oh, I didn't know there was a schedule for these sorts of things, thats nice.

<amano>A simple way to implement incremental encrypted backups on gnu guix is a big discovery.

<pjals>By the way, what should I do when there's nothing more to explain in the description than the synopsis? Do I just use the same for both?

<wizard>normally when i want incremental updates, i run restic, which is packaged in guix already

<wizard>the benefit of a declarative distro is that you only really need to worry about backing data up instead of the full snapshot

<amano>But, you can't declare contents of movies in gnu guix.

<wizard>if the os blows up you can just redeploy and fetch your data back on top of that

<amano>That's why you need snapshots.

<pjals>(yet ;)

<pjals>Who says we aren't getting a (@ (gnu packages movies) big-buck-bunny)?!

<wizard>the substitues would hate that lmao

<wizard>i'd download it :)

<pjals>I think there's a construct to make a nonsubstitutable package though..

<wizard>oh shoot is there? that's cool

<jpoiret>wizard: restic seems to be a few versions behind in guix though

<jpoiret>like quite a few

<wizard>oh darn

<wizard>i can't imagine it'd be hard to bump it to the latest version...

<pjals>I wonder if we could do a sort of blender-build-system for this. (of course this is silly, just download the darn movie!)

<wizard>maybe tomorrow is the day i learn how to become a contributor

<wizard>blender-build-system LOL

<wizard>the funny part i could almost even see myself using that one haha

<pjals>Oh how I wish build arguments would be alists, that would make hacking together packages so much easier!

<jpoiret>wizard: it's in Go iirc so probably very annoying to bump it

<jpoiret>as in it started requiring 10k other packages that aren't at the right version in guix

<wizard>ohhhhhhh darn

<wizard>i thought it was rust

<amano>To be able to unlock all encrypted file systems with /gnu/store in one of them, you would need multiple key slots and keyfile support in bcachefs and guix will need to support unlocking bcachefs filesystems with password or keyfile.

<amano>I mean being able to do so with only one password prompt.

<insomniac>I dream about go importer, that would stuff the dependencies into separate file which you could just drop and regenerate from scratch on update

<insomniac>Only the packages you care about would be user-visible and in permanent files

<pjals>re #f label from yesterday: I've gotten the main sysadmin to wake up and seems like even from the bootloader we cannot boot older generations, when we boot into any generation it boots into 16 (the broken one) instead for some reason.

<jpoiret>insomniac: that doesn't really scale for upstreaming though

<amano>pjals: Have you done backups with btrfs on LUKS? How was it?

<pjals>No

<pjals>I daily-drive btrfs but I have never done a single backup

<insomniac>jpoiret So how about just having all the dependencies in native-inputs as origins?

<jpoiret>insomniac: that's antithetical to the idea of a distribution imo

<jpoiret>ie. a coherent set of packages

<insomniac>Hm, I guess. Just thinking what the solution could be here. There is reason I do not send patches for golang packages, except those that are vebndored and provide a makfile...

<jpoiret>are those vendored dependencies accepted?

<insomniac>podman, buildah, etc

<insomniac>all of those have /vendor directory by upstream

<Rutherther>pjals that's curios. What is in your /boot/grub/grub.cfg?

<pjals>So it doesn't even contain the booted generation, which is really strange. The "gnu.system" parameter doesn't even lead to the booted generation.

<pjals>I'm actually really confused right now.

<Rutherther>so it leads to correct generations in grub.cfg, but gen16 is loaded anyway?

<pjals>yea

<pjals>Is my system just haunted?

<jmes>wizard: re: blender-build-system - that might be interesting to distribute animations or screensaver thingies that can be personalized with package transformations or something

<Rutherther>pjals btw are you sure the earlier generation actually booted and did not just error on something, and caused another reboot?

<pjals>jmes: Oh darn, we're gonna do blender-build-system seriously? Nothing against it though ;)

<jmes>Haha, not serious, just musing (for now)

<pjals>Rutherther: xmoo can answer that, but I don't think so.

<xmoo>The previous generation did boot, it's just that the broken generation can't be removed, guix gc says it's still alive.

<pjals>(also guix system list-generations says current)

<pjals>Interestingly, /run/current-system/ does point to the previous generation.

<Rutherther>oh. Okay, then I think it's correct. Botting to older generation shouldn't change 'current' generation

<apteryx>amano: backup with btrfs, yes (LUKS is irrelevant)

<xmoo>Hm, so only switch-generation can actually change the (current) generation.

<apteryx>I use btrbk; snapshots every hour my home and data dirs, backups to external storage every night

<amano>apteryx: I think retrieving LUKS keyfile over the network in raw-initrd should be doable.

<Rutherther>have you tried guix system roll-back now that you are in older generation?

<amano>#premount of raw-initrd can execute anything.

<pjals>Wouldn't that still include the broken generation in the bootloader? Can try though

<pjals>Yea, it's still trying to include the broken generation.

<amano>apteryx: Or, do you just manually type password for unlocking each encrypted machine manually?

<pjals>Also seems like --no-bootloader cannot help, that only applies to 'init'.

<pjals>I'm gonna check the code if I can somehow force guix to delete the current generation.

<pjals>Huh, I could just time-machine to a more naive version of delete-generations.

<apteryx>amano: I was using a RAID 10 with 5 drives and had to enter password five times at GRUB :-D

<apteryx>was on my mind to find a way to use key files or some way to retry the password

<amano>apteryx: There's a better way. Put btrfs root filesystem on one LUKS device. Put a keyfile in extra-initrd for grub bootloader on root filesystem. GRUB will ask you a password for reading kernel, initrd, and extra-initrd from btrfs on LUKS. After keyfile is obtained, every LUKS device can be unlocked with the same keyfile.

<Rutherther>apteryx I don't know if this can break something. But maybe you could try manually removing the generation in /var/guix/profiles/, and then potentially also changing the symlink "/var/guix/profiles/system" to your older generation.

<apteryx>Rutherther: did you mean to reply to xmoo perhaps?

<Rutherther>I meant to reply to pjals, sorry

<amano>guix supports opening LUKS devices with a keyfile.

<Rutherther>I've tried on my system removing one generation from there and list-generations doesn't include it anymore and reconfigure works. So it seems to me guix looks for generations in that folder only. So then your new gen wouldn't contain bootloader to that one

<amano>The keyfile can be a second key slot in your LUKS devices.

<pjals>Rutherther (also xmoo): yea, i'll try that if time-machine (tbh coolest feature of guix ever) doesn't work.

<amano>Make sure the LUKS device for root filesystem can be opened with the key file.

<Rutherther>pjals time-machine doesn't have anything to do with this since it just changes channels

<apteryx>amano: this means you can't have your root on a RAID though; which could be nice for performance

<pjals>Earlier Guix versions didn't check if delete-generations affected the current generation (atleast it looks like that)

<amano>apteryx: RAID1 is nice for high availability, but you are going to need to rely on #premount of raw-initrd for opening two LUKS devices for root filesystem with one password.

<amano>If you are okay with fiddling a bit with #premount, RAID1.

<amano>DAmn, grub is going to prompt you for a password twice if you use btrfs raid1 on two LUKS devices? Maybe not?

<apteryx>I've never attempted it, I'd be curious to see your working config if it's shareable

<apteryx>amano: yes, GRUB does that

<apteryx>worst, if one drive fails, it won't let you boot

<apteryx>I had documented that on the tracker once

<amano>apteryx: You mean GRUB asks for a password twice?

<apteryx>in my case, it was 5 times because my btrfs raid 10 was made of 5 drives

<amano>apteryx: If you can't boot anyway when one drive fails, RAID1 isn't really useful for root filesystem.

<apteryx>you can if you assemble it from a booted gnu/linux rescue system

<amano>Your root filesystem is RAID10 of 5 disks?

<apteryx>was until recently yes

<amano>How does RAID10 work over 5 disks?

<apteryx>it's Btrfs RAID10 ;-)

<apteryx>not sure of the details, must be in their doc

<amano>I think it's similar to bcachefs raid10.

<pjals>btw, it would be nice if Guix would check if there's a valid label before installing anything to prevent this fiasco

<amano>apteryx: RAID only increases avaiability, and root filesystem can be constructed again from config saved in other file systems.

<amano>If you want only one password prompt, root filesystem shouldn't use RAID.

<apteryx>it can also improve performance (although Btrfs RAID performance is not yet optimal)

<apteryx>I think its stripping (RAID0) performance is as expected, and RAID1 is so so (because it only shuffles the reads based on PID oddness, which is crude)

<amano>apteryx: I found a way...

<amano> https://github.com/NixOS/nixpkgs/issues/24386 explains that you can insert a keyfile in a LUKS image file which goes into extra-initrd. You can unlock this with #premount?

<amano>No...

<amano>That's not it.

<amano>apteryx: Why don't you put root filesystem on one LUKS device?

<amano>It would be easier.

<civodul>merged!

<apteryx>amano I'll think about it; thanks for sharing ideas!

<apteryx>I do like RAID perf improvement on /gnu/store; useful for 'guix gc' for example.

<insomniac>civodul: congratulations Gonna try update right away.

<graywolf```>Before rebaseing my patches and resending them (intented for core-updates), I should way untile the branch is recreated right? :)

<civodul>the branch will *never* be recreated

<civodul>not in my lifetime anyway :-)

<civodul>graywolf```: did we miss fixed that you had sent?

<Rutherther>so what's the plan for packages that cause a lot of rebuilds? I thought core-updates was for that, or not?

<graywolf```>civodul afaik the fix for unicode symbols in program-file and such was not merge

<graywolf```>So I wanted to resend it for new core-updates

<amano>apteryx: I think btrfs raid10 can only lose one disk. If you lose more than one disk, btrfs raid10 guarantees data loss.

<amano>mdraid10 can lose anywhere between 1 disk and half the disks before data loss...

<amano>With btrfs on luks on mdraid1 or mdraid10, grub may require only one password for unlocking the root filesystem.

<apteryx>amano: yes, I think that's true, although you can put the metadata on a raid1c3 to give it some extra resiliency against corruption

<amano>Does mdraid support raid1c3 for metadata?

<amano>Or, btrfs does?

<apteryx>mdraid1 is slow to rebuild an array though. with Btrfs, it may have to sync a few blocks sometimes, it's not something you think about.

<apteryx>raid1c3 is a btrfs thing, which means 3 copies

<apteryx>normal raid1 would have as many copies as there are disks

<apteryx>I think we are drifting a bit off topic; if you'd like to continue discussing btrfs they have a fine channel for it :-) (#btrfs)

<civodul>graywolf```: oh yes; i’m still not convinced about that one, but we need to discuss it for sure

<graywolf```>I mean (program-file "utf8" #~((λ _ (display "?\n")))) should either work or error out. I obviously would prefer the former, but latter is also acceptable. But current state of silent corruption sucks a bit :)

<graywolf```>And *some* gexp forms already handle it, so it feel weird the it works in, let us say mixed-text-file but not in program-file

<jpoiret>civodul: congrats!

<jpoiret>and thanks for taking care of it

<civodul>argh, Emacs crash

<apteryx>:-/

<jakef>it begins :)

<civodul>i should say it’s a pre-core-updates Emacs

<civodul>it might even be sddm or elogind, i don’t get what’s going on

<civodul>i’ve experienced it a few times after a 1+ week uptime

<pjals>I don't understand why people want high uptime on the desktop. Are boot times really that slow?

<pjals>(if i'm reading the correct IRC log :)

<graywolf```>pjals: My firefox nukes session data on shutdown, and restoring all emacs buffers is pita :D I reboot once every week I guess?

<pranav>pjals: Rebooting resets the entire state of a system. That could be undesirable.

<pjals>pravnav: The system should be smart enough to restore the state though, and graywolf```: I'm surprised there isn't an Emacs package for that ;)

<graywolf```>Some of those buffers are Guile REPLs though

<pjals>If only there would be a procedure to save the full state of the REPL (wait, is there? lemme go on a hunt for undocumented procedures)

<graywolf```>Not sure how to sensible restore those

<graywolf```>I doubt it. REPL state includes ports, and if you reboot, the file descriptors are gone. Maybe some CRIU magic could work

<graywolf```>Maybe?

<pjals>CRIU?

<graywolf```> https://en.wikipedia.org/wiki/CRIU

<pjals>Ooo, but wait, doing this is just hibernation with extra steps :/

<graywolf```>:)

<graywolf```>ACTION really needs to find time to bug report emacs-yaml taking about half of eternity to build...

<jlicht>graywolf```: I thought it was just me! I've been working around it using a custom package https://paste.debian.net/1328055/

<graywolf```>jlicht: Oh thanks for the tip! It definitely is not just you, last time I had to add --max-silent-time=7200 (or whatever is the arguiemt called). default 3600 timed out

<graywolf```>And this is on 5.5 GHz machine on SSDs

<jlicht>graywolf```: I only get hit by the issue if I use package-input-rewriting to replace emacs-minimal though. `guix build emacs-yaml` runs fast enough on my (boring) laptop

<jlicht>In which case I get a plain 'ol "phase `build' succeeded after 11.4 seconds"

<graywolf```>I assumed that would be the case, nice to have that confirmed

<lilyp>we got some weird linker woes reported in the XMPP room, where it appeas as though glibc 2.39 gets resolved to glibc 2.35 – anyone know what could be the cause of that?

<amano>I tried really hard to use btrfs, but I came back to zfs because only zfs combines real raid10 and encryption with any performance. I guess I will just use one ZFS disk for root filesystem and an even-number of zfs raid10 disks for data. I will also use #premount of raw-initrd for unlocking zfs file systems before mounting them through file-systems of operating-system.

<Rutherther>what would be an idiomatic way to run shepherd-service as a user different from root and give it a capability to bind privileged ports?

<amano>Rutherther: You need to run sysctl if you want unprivileged port access below port 1024.

<amano>sysctl

<amano>The concept of privileged ports is nonsensical.

<nckx>Congratulations on the core-updates merge! 🦸

<lilyp>🎉🥳🎉

<mitchell>hello guix. I am trying to follow along with the "dissecting guix" blog series but my builds keep failing when it tries to display strings `In procedure display: Wrong type argument in position 2: #<closed: string 7f371a09ea80>'. Any insights?

<Rutherther>can you send your code for display?

<Rutherther>you probably wanted to pass #f as first argument to display

<mitchell>It's not my code. It's the code where it's trying to say ` (display "building path(s) `/gnu/store/891d1v3nv3rlpch8lhq40r3spshjxls2-testing-1-2-3'\n" #<closed: string 7f371a09ea80>)'

<Rutherther>oh, noo sorry that's for format, my bad

<Rutherther>oh, okay. And how does your code look like then?

<mitchell> https://paste.debian.net/1328057/

<mitchell>The build process should be putting a port as the last argument when it's giving build statuses but it looks like it's passing a #<closed: string> object somehow

<Rutherther>display without a port is going to stdout, no need to pass port as last argument

<Rutherther>the code you sent works fine for me in repl, after adding few missing modules

<mitchell>are those modules anything other than (guix gexp) and (guix store) ?

<Rutherther>guix derivations as well. But without any of those I just get an error that variable is unbound, so it doesn't even start building

<graywolf```>ACTION is up and running on current master; thanks everyone for pushing the core-updates through :)

<Rutherther>if it doesn't work for you please share more information about how you are using the code, it's obvious from it you haven't used just this, since the modules were missing. Also it might be worth to share guix commit you are using (guix describe -f channels) though I would expect problems like this only on some very old versions and I wouldn't expect you to be on old version

<mitchell>I am running guile from emacs geiser with the guix source 842a11f1ca in the %load-path

<nckx>graywolf``` needs moar quasdquotes.

<nckx>"i

<nckx>lol

<mitchell>running it from `guix repl' works so it must be something weird with geiser

<mitchell>Running it with `guix shell -D guix -- guile -L guix -s test-drv.scm' gives me even different errors... guix/gexp.scm:1183:34: In procedure gexp->derivation: Wrong type to apply: #<syntax-transformer set-grafting>

<kitaleth>has anyone managed to get Guix the package manager to install on an immutable distro, such as silverblue

<jlicht>Does `guix build texlive-xmltexconfig` not work for anyone else since the CU merge?

<kitaleth>Apologies, missed https://lists.gnu.org/archive/html/help-guix/2024-06/msg00101.html

<Rutherther>mitchell your command works fine for me

<dariqq>I am getting a build error for ffmpeg@4 (and 3 and 5) for i686 :(

<amano>Rutherther: Use ZFS.

<Rutherther>@amano ?

<amano>ZFS seems better than btrfs.

<Rutherther>okay? I use neither

<amano>What do you use?

<Rutherther>ext4

<amano>How do you get error correction, raid, and encryption?

<Rutherther>I don't, I don't, and LUKS

<Noisytoot>btrfs is better than ZFS

<Noisytoot>ZFS's license (CDDL) is GPL-incompatible

<nikolar>it's not really

<nikolar>at all

<nikolar>btrfs being a better system is not license dependant

<Noisytoot>zfs can't have substitutes because of it

<nikolar>why not

<Noisytoot>it's not legal to distribute zfs binaries

<Noisytoot>see https://www.fsf.org/licensing/zfs-and-linux and https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

<Franciman>does zfs support something that btrfs doesn't?

<nikolar>working raid for a start

<nikolar>Noisytoot: to be fair, not having zfs substitutes isn't a big deal

<nikolar>it compiles in like a minute

<graywolf`>Is there a way to go from store path back to the package? Or rather, something I could put into "a package field" of a configuration?

<Noisytoot>nikolar: a minute? I decided to try compiling it and see how long it takes. It took over 5 minutes to just get to the build phase (most of it was spent on really-configure)

<nikolar>what hardware are you running

<nikolar>it's very quick for me on a frequency limited middle end laptop

<Noisytoot>ThinkPad X200 (Core 2 Duo P8700)

<nikolar>that would do it

<nikolar>still, i think 5 minutes once in forever is acceptable

<h4>I've found a neat command that permitted to follow a package life through generations, update, installation, removal. But I can't retreive that command now

<h4>Why `guix package --list` only list packages installed through `guix install` and not `guix shell` or `guix syste

<h4>m reconfigure`?

<kitaleth>What is the equivalent of builtins.readFile (from nixLang) in Guile?

<Rutherther>it's made for listing packages from profiles. As for why it doesn't show from system, that's because you don't really install packages to system profile, it's just the system derivation that depends on other packages

<jaft_r>h4: if you want to see which packages were installed to your system, =guix system describe --list-installed= will do that for you.

<h4>Rutherther: I don't totally get it. I can picture that majority of packages are dependencies that traduces into derivation. But there is a good portion that was explicitely asked. I can figure why `shell`ed ones aren't written on the profile, but what about the `reconfigure`d ones?

<h4>jaft_r: In fact I wanted to `guix package --list-generations`, not describe

<jaft_r>Ah; =guix system list-generations= would do that, then. Tack on "--list-installed", again, if you want to see the installed packages of each generation.

<h4>jaft_r: No, `guix system list-generations` only list generations metadata, nothing to see with packages

<Rutherther>"guix system list-generations --list-installed"

<h4>But yeah it's more or less what was needed with the `--list-installed`

<h4>I'm so lost with Guix that I've lost what I wanted to do with that information

<Rutherther>h4 sorry, I was wrong about the system. As the system builds a profile itself as well, so you can actually even get its manifest through guix package and get the installed packages. It would be possible by using "guix package -p /run/current-system/profile --list-installed". It's basically what "guix system list-generations --list-installed" does. But keep in mind it lists only the ones added to the profile itself. If a package was used for a...

<Rutherther>... service, but not put to profile, you won't find it like that

<Noisytoot>nikolar: That's just to reach the build phase. The whole thing took over 22 minutes.

<nikolar>Well I guess you probably don't want to use it on a Thinkpad anyway

<Rutherther>the reason this works is that profiles keep a manifest file in them that describes this. If you want to keep track of this for other stuff, you would probably have to do it somehow yourself. Though now that I am thinking about it, if you listed stuff in /gnu/store that is named profile, you would find all stuff you got through "guix shell", and since those are profiles, you could get a manifest. Would this help you in getting your "explicitly asked...

<Rutherther>... for" packages maybe?

<Rutherther>h4 "for profile in $(ls /gnu/store | grep profile$); do; echo "A profile $profile:"; guix package -p "/gnu/store/$profile" --list-installed; done"

<h4>`do` don't take a `;`

<h4>This loop only list like 7 profiles

<Rutherther>sorry, I am using zsh where this works. I see now it doesn't work in bash

<h4>And I used `guix shell`... Well, too much to count in my life

<h4>Oh, I was used to work on zsh and here too I never did `do;`

<h4>It seems wrong lol

<Rutherther>ah, okay, you are right, it works even without it. Though it doesn't mind it being there

<h4>And more importantly. It lists profiles and nothing after the semicolon, the package command seems to output nothing

<h4>This loop only list like 7 profiles, And I used `guix shell`... Well, too much to count in my life, And more importantly. It lists profiles and nothing after the semicolon, the package command seems to output nothing

<Rutherther>it doesn't work with bash, sorry about that. With zsh it works perfectly. With bash I also got just a few

<h4>Very curious indeed

<h4>Because it seems right as is

<h4>But yeah ls /gnu/store | grep profile$ only list few

<h4>ls /gnu/store | grep profile list much more

<Rutherther>I see the issue. bash ls output contains / at the end, whereas in zsh for me it doesn't

<Rutherther>"for profile in $(ls /gnu/store | grep "profile/"); do echo "A profile $profile:"; guix package -p "/gnu/store/$profile" --list-installed; done" so this shoud be fine

<h4>Oh yeah, much more prolific

<h4>There is too much to compare but it produce something similar to guix system list-generations --list-installed

<Rutherther>and the issue is not actually bash/zsh related, but it's related to guix home putting ls as alias for ls -p in bash :)

<Rutherther>h4 yeah, it is, but you've used a lot of shells :D I am not saying it's a good way to parse it like that, just that the info is actually there, so you could parse it somehow. Of course there is no info about the channels by default, so you won't actually link it to your system generations or something like that. I think that if you will want information like this in the future it would be better for you to use some kind of a wrapper around guix shell...

<Rutherther>... that would give you the information you need in the future

<janneke>kitaleth: (with-input-from-file "file-name" read-string)

<janneke>(probably, /me doesn't speak nix)

<kitaleth>janneke: thanks! (do not see it mentioned in the manual, oddly enough)

<h4>Rutherther: I never understood why distributions made aliases for commands. It should serve them vanilla and then we install community configurations like OMZ to get enhanced experience

<h4>Yeah or maybe just drop shell and starting to fixate my packages, because it's a very temporary thing per default. It's just so convenient to get and run a package by one command only

<h4>But even then, that profile thing is so curious, default commands list only one package where I have like 30 packages in config.scm, here it's it's bogus

<h4>Even if I were to never use shell the result would have been as cryptic

<Rutherther>h4 the trick is that every shell creates a profile out of the packages you request

<h4>Oh yeah I remember! To figure out in what generation was InkScape so I can run it with something like guix time-machine generation/hash shell inkscape

<h4>Rutherther: Yeah that seems logical, a whole new environment to work isolated. Problem is that I don't use as a developper, like one environment per project, but more like one environment per program that I want, worse, per application mix I want

<jaft_r>It looks like Guile commands from the (guix scripts …) set of modules outputs to stdout rather than returning anything. Is there a way to capture the output for these functions (outside of writing some Guile code to capture from stdout)?

<h4>guix time-machine $(guix locate-commit-hash $(guix locate-generation-of-package inkscape)) shell inkscape

<Rutherther>How/where did you get this locate-commit-hash and locate-generation-of-package?

<h4>Rutherther: That's the part that takes an afternoon to figure out with experts and weeks alone. Basically I need to know from what channel $package comes from. Then need to determine in which generation $package was available (shell/reconfigure/install...)

<h4>then determine the commit hash of the channel of last generation where it was available

<h4>Then use guix time-machine to cofigure the channel and its commit to shell to the $package that is available locally

<Rutherther>the only two ways to do that are either 1. save it when you actually obtain it, like what guix system does, keeping channels.scm in the system, or 2. by trying all possible combinations of the channels to see which one has the package with this hash.

<Rutherther>the possible combinations for you could be what you have in /var/guix/profiles/system-xyz-link/channels.scm, if you always used only those channels for obtaining the shells that is

<h4>"Save it when you actually obtain it", you mean write down the package commit channel association when doing shell to later re use that combination in time-machine?

<Rutherther>yeah, and that could be part of your guix shell wrapper

<h4>I don't have that much channels to talk about brute forcing, only 4, it's fine. But even then, with the channel, you still need to figure out the concerned generations

<Rutherther>by channels, I meant including commits, and that's what is actually stored at the paths I provided

<h4>Oh yeah I never used channels on the fly with shell. Shell was always using locally configured channels, so it's fine. though, I added and deleted channels through generations

<h4>To figure out the commit I have to figure out the generation concerned then simply do a describe to look at the commit involved at those generations and grab it and give it to time-machine

<Rutherther>using describe is going to prove more work, just use the channels.scm file directly

<h4>1. Channel of the package\n2. Generations of the package\n3. Commit of channel of last generation\n4. time-machine

<h4>Rutherther: channels.scm wasn't commit locked, so no commit writen into it

<Rutherther>file /var/guix/profiles/system-xyz-link/channels.scm has commits in it...

<h4>And retrieving commit hash from describe is by far the easiest part. The hardest is to figure generations concerned

<h4>You right, it's commit locked over there, though it's not me that did it lol. I locked sometimes but most of the time not

<Rutherther>it's what the system build does, it puts the commits there. That's where describe obtains it, it's not anywhere else

<h4>So okay, linking channel-generation to hash is even easier now, but that doesn't make easier the package-generation part lol

<Rutherther>why would you need this "package-generation"?

<h4>Because to avoid retreive online that package, I need to figure out in which generation it was installed, to get the right commit hash, the hash that was derivated locally, not any hash randomly

<h4>For example if the package was retreived in generation 2 and 14 but not any other, like it wasn't available at all otherwise, specifying another generation-commit-hash will make an online retreival

<Rutherther>the hash is based on the package declaration. You get all possible package declarations by looking at all possible channel combinations (with the commits, assuming you've used just those) of your generations. No package-generation involved...

<h4>So you need to figure out that it was available in generation 2 and 14 and then choosing which generation version you prefer then take the commit-hash of the channel of that generation then time-machine

<kitaleth>I think I might be having an XY problem. What is the canonical way to concatenate an existing file with configuration data generated from a function?

<Rutherther>that's backwards. You will get to know if the hash matches by the channels used, by evaluating the derivation there. Generation that was obtained for those channels doesn't matter. But honestly this whole thing seems pointless. If you know you have an inkscape in your store, from somewhere, just find a folder that has inkscape in name and run /gnu/store/...-inkscape-.../bin/inkscape

<h4>Rutherther: I need the hash-commit that the generation used because it was that commit that got the package. I don't talk about the commit of the repository of the package but the commit of the guix channel

<Rutherther>I am also talking about commit of the channels, not of the package...

<h4>Yeah that was what I was doing until now, pretty dirty, to directly launch the binary outside of container context, but I wanted to try that time machine command as it seemed to be the clean solution

<h4>But the guix way is not always the simplest one, and who knows, sometimes not even the right one, maybe sometimes the gnu/posix/linux way is right

<Rutherther>finding what channels a package was built from by brute-force does not seem clean at all

<h4>The method to configure time-machine here seems dirty yeah, but the time-machine command in itself seemed cleaner than running a binary alone

<Rutherther>using guix shell just adds the correct stuff to your env vars, so in the end you also just run the binary, taken out of the path

<h4>So `$ sudo find / -iwholename \*/bin/\*package\*` it is. Yeah I know that command is dirty and too broad but I always use it and love it

<h4>Yeah you just run the binary, but in a contained environment that you configure in shell options

<h4>you can --pure or --container or somehing else

<Rutherther>you can of course run the binary in a container if you wanted

<h4>At least it's not totally dirty, you still have the script generated by guix that you can run instead of .package-real

<h4>Rutherther: Yeah so it would be guix shell all the way down

<Rutherther>kitaleth it depends where you use it. If in configuration options, have you taken a look at "mixed-text-file"?

<Rutherther>h4 why are you running the .real file? you should use the wrapper executable

<h4>Rutherther: I don't

<kitaleth>On a somewhat related note, has anyone successfully managed to install Guix on read-only root/immutable distros?

<kitaleth>(not necessarily just Silverblue)

<Rutherther>kitaleth: https://termbin.com/z8ln though it might be too complicated conceptually.

<Rutherther>(for example home zsh service does something like this in the files used there)

<kitaleth>Rutherther: why a field-text-config as opposed to a string?

<Rutherther>you could use a string. But then, I think, you will have to read the file on eval time

<kitaleth>that seems fine (this is for an operating-sysem config)

<Rutherther>if you really want to then just use "(with-input-file "the file" read-string)", and append the string to that

<kitaleth>as opposd to mixed-text-file?

<kitaleth>I'm not sure what the difference is between the two (apart from with-input-file not being documented)

<Rutherther>call-with-input-file is documented

<Rutherther>mixed-text-file is a thing to create files out of "mixed" text, meaning you can put in either plain strings or stuff like paths to nix store derivations

<kitaleth>ohhh

<Rutherther>call-with-input-file opens a file, and gives you a port. Then it closes that file. read-string will use that port to read it into a string

<kitaleth>but with-input-file is not?

<Rutherther>sorry, I meant call-with-input-file, not with-input-file, that doesn't exist

<kitaleth>Oh, in the *Guile* manual

<PotentialUser-58>Hello. guix home reconfigure fails on aarch64 while doing make check on the guix binary after core-updates.

<PotentialUser-58>Same config on x64 does well

<Rutherther>what is the error, and do you know what part of the config is causing this?

<Rutherther>oh they left already

<PotentialUser-58>Rutherther It is independent of the config. The error occurs on the make check phase when building the guix binary itself. There might be confusion about armhf and aarch64 during some of the make check tests

<PotentialUser-58>I am on my phone. Sorry

<Rutherther>so it doesn't have to do anything with home reconfigure? when running home reconfigure you should already have the guix binary

<Rutherther>oh, "same config on x64 does well" means that it's okay, I thought you wanted to say it's not okay as well. Okay :D

<dariqq>ugh something is causing a gtk4 build failure on master right now

<podiki>i see it failed a test on the CI, a zink failure. i thought we had fixed something like that before (not sure if for gtk or some other)

<dariqq>fa70c141552c76cf4dc9666f577bf6b471fa0d50 is still fine, not sure why it is being rebuild anyway

<peanuts>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fa70c141552c76cf4dc9666f577bf6b471fa0d50

<PotentialUser-78>Rutherther: https://pastebin.com/utHWs3M0

<podiki>meanwhile for another channel i get In procedure alist-cons-after:

<podiki>Throw to key "match-error' with args "("match" "no matching pattern" ())'.

<podiki>which looks like this old bug that was fixed, and i'm not offloading here anyway https://issues.guix.gnu.org/59447

<PotentialUser-78>Rutherther: Here you can see the process. I am on Asahi Linux, but it seems to be a general problem on aarch64

<podiki>i wonder if i need to reconfigure and such, seeing as the big changes like glibc from the merge

<PotentialUser-78>Rutherther It builds the guix-1.4.0-24.9a2ddcc.drv derivation but fails in the make check phase afterwards

<Octorine>Hey everyone

<dariqq>So the rebuild occurs becasue lv2 > gst-plugins-bad->gtk and lv2 got a search patch added. Can't see why that would cause an issue for gtk though

<Octorine>I've written a package that contains a search-paths clause, and when I install the package, the env variable isn't being set. Would anyone be willing to take a look and tell me what I'm doing wrong?

<Rutherther>Octorine did you source your profile after installing it?

<Octorine>Not sure. I'll try installing again right now and see if that does the trick.

<podiki>dariqq: i'm building locally, maybe it is transient or sometimes tests fail due to what hardware is on the build machines

<podiki>Octorine: a search path needs both a package that uses it and something that populates that path, both to be installed in the same profile

<dariqq>podiki: i tried locally with 2 different machines on multiple tries

<Octorine>It sounds like I don't understand how search-paths work.

<podiki>dariqq: hrm. still working through the tests now, just for a triple check...

<dariqq>ACTION tries again

<podiki>Octorine: yeah they are tricky. let's say you have package A that looks for plugins, you define a search path in that package, but it is only "activated" if there is another package that puts something in that path

<podiki>so if B puts plugins in that path, "guix shell A B" will have that search path in the env; if only A or B, no path in env is set

<Octorine>That seems to match what I'm doing. I have a propagated-input that puts something in the share directory of my profile

<Octorine>The package can be found at https://github.com/octorine/guix-channel, by the way.

<podiki>i guess i'm unsure when it is a propagated-input that is populating that path

<podiki>but that should work since it is added to the profile

<podiki>and "miscfiles" has /gnu/store/<hash>-miscfiles-<version>/share with some files?

<podiki>dariqq: same Zink failure on the tests here too

<Octorine>Yep.

<podiki>can you try with explicitly having that package in the profile? eg. guix shell rust-countdown miscfiles and checking the env?

<Rutherther>Octorine I get DICTIONARY var when putting your package to a shell. So I really think you just didn't source the profile. When you install a package that adds a search path, it won't be sourced automatically. So either relog or source it yourself in a shell to have it there temporarily

<podiki>or, try in guix shell since that will have its own env

<dariqq>Octorine: I used guix shell -f countdown.scm and it works

<podiki>dariqq: really unclear why the notify test is failing for gtk-4 now

<Octorine>Just noticed I lost my connection, so I may have missed some messages. The last think I saw was podiki suggesting a guix shell

<podiki>Octorine: https://logs.guix.gnu.org/guix/2024-08-31.log at the bottom

<podiki>ACTION tries to update gtk-4 and build...

<Octorine>podiki thanks!

<Octorine>if I run "guix shell -f countdown.scm" It creates the environment, and i can run the program, but I'll get an error if I try to do a letters game, because that's the part that needs the env variable.

<Rutherther>so you didn't get the env var?

<podiki>interestingly gtk website lists the wrong current version (doesn't exist yet on their server)

<Octorine>Nope. I don't see it --search-paths, and if I echo $DICTIONARY after installing or creating a shell, it isn't set.

<Octorine>Don't see it IN --search--paths, I meant to say

<podiki>try just guix shell --check

<Rutherther> https://paste.debian.net/1328074/

<Octorine>guix shell --check tells me all is good.

<Rutherther>it doesn't really matter what check says if you don't get it in --search-paths

<Octorine>When I run guix shell with --search-paths, I get the PATH, but not the DICTIONARY.

<Rutherther>but I don't really understand why you don't get it in a searchpath, whereas dariqq and me do. Are you sure you are running the same code from the repo?

<podiki>that's what i was going to say, if you are using the same version file, or if you are from a channel and didn't guix pull to current version

<Octorine>That was it.

<Octorine>At some point trying to get it to work, I added (separator #f) to the search paths spec and changed it from native-search-paths to just search-paths.

<Octorine>Thanks everyone!

<podiki>dariqq: newer version of gtk-4 built and tested fine locally. i guess since it is broken anyway i'll just push the update

<podiki>still no idea why it started failing

<dariqq>podiki: thanks

<podiki>i wonder if that will affect anything else, but i guess won't be worse than now (i see now pending for gnome-team updates, but this is a minor version update at least)

<podiki>lilyp: if you are around, gtk@4 fails on master post core-updates. taking the current version (from gnome-updates) builds and passes tests so i cherry picked it. i will push to master but if that makes trouble for you, we can revert and just disable the failing test. (i tried the update before i realized pending on gnome team)

<decfed>kitaleth: i run guix atop silverblue. You need to disable SElinux and bind mount /gnu/store from somewhere in /var after each reboot. Have that in a script, so its not so bad.

<lilyp>if cherry-picking stuff from gnome-team resolves issues on master, that's good, but do be careful about rebuilds and signatures

<podiki>yeah it is 100-200 rebuilds (not bad)

<podiki>by signatures you mean on the commit? it will be you author, my sign off, and my signature

<podiki>and gtk currently doesn't build on master (though did on core-updates and master prior to merge)

<lilyp>yeah, last time i checked you can bork your guix if you're not careful with cherry-picks

<lilyp>as for why it sometimes builds and sometimes doesn't, that might well be a flaky test that still exists in the new version – try multiple rounds before signing this off

<podiki>hrm. any details you remember? i use magit and it did prompt for my signing key (hardware)

<podiki>someone here built it a few times, the CI did, and i did locally, always fails. the "notify" test with a mesa/zink error (???)

<podiki>i'll build new version again locally though, good idea

<podiki>(doubled checked the git log signature and guix authenticate; but am building locally a few more times to make sure build is fine)

<lilyp>if guix authenticate runs fine, that's well – IIRC there have been mishaps in the past where that wasn't configured correctly

<podiki>thanks for the headsup, i'm always worried about such things too! (especially since i did bork that on another channel on my first commit, issue with keys/subkeys)

<podiki>anyone familiar with the changes from core-updates to build systems? get a match error for a package where it seems it didn't like to delete a phase then add one after the deleted one; and adding after a phase that doesn't seem to exist

<podiki>while that worked before

<lilyp>is that package wine64 by chance?

<lilyp>if not: reordering the way those are laid out should do the trick

<podiki>it is in another channel. but things like (add-after 'install-binaries 'post-install used to work

<podiki>though "install-binaries" doesn't seem to be a standard-phase