IRC channel logs
2025-08-05.log
back to list of logs
<jmes>Can I use something like ‘guix pack’ to pack a guile script that a program-file creates? <jmes>Essentially I want to tar whatever version of guile I'm using and the output of some program-file <sham1>You could make your guile script into a package <jmes>sham1: Okay that's a reasonable approach. I've been avoiding packaging my little scripts but it would make deployment to my guix home cleaner and allow me to use guix pack. Thanks! <mfg>good morning guix o/ <mfg>Is tehre information on how to rescue a guix system that does not get to the bootloader anymore? Is there a guide somewhere explaining what i need to do from a live guix boot to create a new system generation or to roll back? <jlicht>could be the disk corruption issue that some folks seem to run into <mfg>untrusem, thanks for the link <mfg>jlicht: what specific corruption problems are you refering to? I recently reinastalled on another machine because i had some btrfs corruption but i doubt guix caused that <mfg>untrusem, as to what broke the bootloader: On that particular machine i often get guix to hang and i believe there are some race conditions which i trigger. This is not the first time, but last time i wanted to switch to LUKS anyways so i reinstalled <mfg>instead of trying to fix anything <jakef>apteryx: you must feed it lots of snacks! <Deltafire>Wayland does't work and I'm using the integrated GPU, but hey.. I'm running Linux-Libre! <Deltafire>I wonder what percentage of Guix users are using this kernel <bdju>I'm using it on my ThinkPad T440p! Sway is working fine. <Deltafire>not sure what the issue is with Gnome/Wayland - the windows aren't drawn properly <bdju>Oh, that sounds accurate to my machine also, actually. I noticed that a few days ago that certain gtk stuff is blank now. <bdju>I think pavucontrol and transmission-gtk were the broken ones I noticed, but I just worked around it using other stuff. <Deltafire>isn't gnome native wayland? so it wouldn't be using xwayland? <bdju>xwayland is kinda always there for running stuff that doesn't have wayland support. <bdju> https://0x0.st/8haB.txt When I check with guix weather if ungoogled-chromium has a substitute yet, I notice that the top mirror says CI info is unavailable and then the second mirror times out. Is that a known issue? <bdju>I don't know about GNOME but with Sway you can use `swaymsg -t get_tree` to check if a given window is wayland or xwayland based on whether it has a class or app_id. The other trick I've heard is using xeyes since it can only see other x windows. <Deltafire>using xeyes: xterm is X, IceCat isn't and the Gnome file explorer isn't <Deltafire>IceCat renders fine, the Gnome window is borked <Deltafire>going to reboot back into non linux-libre to confirm <Deltafire>so it's either something to do with switching from the Radeon card to integrated gfx, or some recent update <Deltafire>seems unlikely that the intel integrated gfx would be an issue <Deltafire>that's kinda what my gnome windows look like <Deltafire>i'll plug the radeon card back in and retest <Deltafire>ati radeon card with standard Linux card, wayland & gnome working normally <mange>Isn't the store mounted read-only? <apteryx>it is, but if you read the report above, it appears to have rw permissions <apteryx>that would affect any grafted package <mange>But does that matter? I thought the ro mount would still reject a write. <apteryx>yeah, I guess/hope it does? I haven't verified yet. <Deltafire>how does the guix build daemon write to the ro mount? <Deltafire>also, the store isn't mounted read-only on foreign distros <Deltafire>but the directory is owned by root, so 'ordinary' users can't write to it <sham1>Deltafire: the daemon remounts it as rw in a separate mount namespace <sham1>Also god damn it, apparently my system reconfigure broke my grub. FML. Oh well, time to rescue my system <mange>On a foreign distro it should be mounted read-only, but I guess it depends. The install script installs a gnu-store.mount systemd service, at least. <Deltafire>Confirmed! touch: cannot touch 'test': Read-only file system <sham1>Hmm, one of my derivations is corrupted <sham1>Oh dear, things are even worse than I thought. Managed to fix the corrupted derivation and activate the new system, but rebooting to it now says "error: not a correct XFS inode." in Grub. I love it! <ieure>sham1, You probably need to boot a recovery image and fsck the filesystem. Sounds like there might be FS corruption happening. <sham1>I did fsck (well, xfs_repair) multiple times and at least according to it, things seemed fine <sham1>So unless the underlying LUKS partitions are corrupt, then I have no idea what's going on <sham1>Oh well, reinstalling doesn't seem too bad since I can reuse the config <vagrantc>evern on x86_64-linux there are missing substitutes for a lot of things... <vagrantc>or maybe i misread the huge log of things flying by on the screen <vagrantc>i had this wild and crazy thought ... since guix is apparently prefers "git rebase && git merge" over just simply "git merge" ... if folks could do signed tags for significant merged branches so we can track at which point a particular branch is merged? <vagrantc>then i would see it with a simple git log... <vagrantc>you can kind of infer some branches, by reading through all the commits, if you are familiar with the classes of packages being merged ... but it might be nice to have a simple mechanism <ieure>vagrantc, Another option is to squash commits when merging. <vagrantc>a tag like c++-team-NNNN (where NNNN is the merge request) <vagrantc>ieure: not sure i would like all, say, rust updates in a single commit ... makes it harder to revert if needed ... likely looses some attribution too <vagrantc>just haviung some flag at which commit was the culmination of the pull request would be nice <vagrantc>suppose this is better for the mailing list, though <Rutherther>vagrantc: or another crazy thought what if merge commits were added in case of merging team branches? really... what are merge commits for if not this, why complicate this with tags? <vagrantc>Rutherther: that is my inclination as well, but someone did demonstrate in the past merge requests which actually caused some issues that obfuscated the issue that fully rebasing would not cause <Rutherther>vagrantc: what issues and how did a merge commit cause them? <vagrantc>this was a thread some years ago that i do not remember off the top of my head, but it set the norms <Rutherther>(I would also love to be able to tell when a merge was made and also the commit before the merge, so no matter the solution I am all for, but I really would just expect merge commits to be solution forthat) <vagrantc>Rutherther: i found the email locally, but lists.gnu.org is slow-to-unresponsive ... <vagrantc>Rutherther: it was in 2022-01-17, Message-ID: id:YeXjyKWobpFe+OQ6@jasmine.lan From: Leo Famulari Subject: WARNING: Git merges are tricky. Rebasing is better? <jlicht>vagrantc: we could have rebases + non-ff merges. <vagrantc>wouldn't that break the signed commit verification model? <jlicht>(not being snarky, possibly confused though) <vagrantc>that would basically mean training people to use --allow-downgrades all the time, unless i am missing something <jlicht>I thought team branches are already (sometimes) rebased on master? <vagrantc>yes, before pushing to master, so master is always ff-merge-able <jlicht>and then ff-only merged into master (and master pushed to codeberg) <jlicht>so the only difference is that I propose merging the rebased team branch using --no-ff <jlicht>which would get git log & friends to show a nice ascii art clearly indicating the branch (and a merge commit to make it officially part of the history) <vagrantc>yeah, the mailing list thread from 2022 described why that is not a good idea <vagrantc>basically something effectively got reverted in the merge, and it was very difficult to figure out what happened, as it never got reverted in any commit <jlicht>I don't understand what that means as the merge commit should still _always_ be empty itself <jlicht>if the ML thread ever loads again for me, I'll probably understand and agree :) <vagrantc>i remember poking a it reading that thread, and was quite perplexed at what was happening <jlicht>I think that can only happen if one has non-empty merges (e.g., you don't rebase just before creating the empty merge commit). <jlicht>the relevant part of that thread: "which happened on the master branch while the version-1.4.0 branch was forked off" <vagrantc>yes, but it did happen. and could happen again in a more serious or severe case... and so we do not use merges anymore became the norm... <vagrantc>by rebasing, any mistakes will leave a trail as to which rebased commit broke it... <vagrantc>should probably mention that thread in the message i posted to the list as background... <ieure>Merge commits are IMO badly implemented in Git and cause much more trouble than they're worth. Not sure if this has improved, but at least at one time, doing things like `git bisect' across merge commits was very fraught. <ieure>A linear commit history is very easy to understand and work with. <jlicht>linear history certinaly has its merits