IRC channel logs
2025-08-25.log
back to list of logs
<AidenIsik>Hi, I'm trying to install Guix System on an ARM server by hijacking a Debian install, but I'm getting an error running guix system init <AidenIsik>It's complaining about /gnu/store being a read only filesystem <AidenIsik>Should I pass --keep-going or can I remount it are R/W or something? <AidenIsik>It's the same disk as the Debian install btw I'm installing over the top if that's relevant <AidenIsik>guix system: warning: initializing the current root file system <AidenIsik>error: failed to evaluate directive: (directory "/gnu/store" 0 0 1021) <AidenIsik>guix system: error: chmod: Read-only file system <jnms>Iirc `guix system init` works by copying large parts of its `/gnu/store` to the `$target/gnu/store`. In your case those are the same directory... <AidenIsik>Interesting, there's an example on this page of installing to the same disk, as if that's a thing that's supported <AidenIsik>I'll try --keep-going, hopefully nothing breaks but it's a clean Debian install so no big deal if it does <AidenIsik>I'll see if I can re-mount it as read-write? <AidenIsik>Failing that I'll probably have to look into how to create an installer image <AidenIsik>Because the only persistent storage device my server has is the main disk, only other thing is a virtual DVD drive and I don't think I'd be able to install guix on that <jnms>What will work is `guix system init /newroot`, but idk how to go from there. <AidenIsik>I could possibly do that, unmount the store, and copy everything over to / <jnms>You might have some conflicts in /var and /etc, but aside from that everything should be in /gnu/store, which even grub.cfg refers to <AidenIsik>And it's specified as vfat in the config, is there a special thing I need to do for an ESP? <AidenIsik>I don't think so actually, this is the same as my laptop config <AidenIsik>Fixed that, it seems to have been a disagreement between how debian and guix handle their boot directory <AidenIsik>Or something, re-mounting the ESP at /boot seems to have allowed it to succeed :shrug: <AidenIsik>Yeah no doesn't boot, guess I'll go learn how to make an installer image. I thought that would be easier but apparently not. Thanks for the help. <robin>untrusem, ty for the nftables pointer, i remembered something "replaced" iptables but forgot the details <simendsjo>guix pull fails on my machines now. guix-system-tests fails with a backtrace. I cannot find anything in the help or bug mailinglists. Has anyone else experienced and diagnosted this? <adanska>simendsjo, yes, I've sent an email to the committer. For now, just guix pull to the commit before the most recent commit batch. <apoorv569>it updates redkite and geonkick, as redkite is not building ATM on latest pull.. <jlicht>apoorv569: just had a quick peek on my phone; shouldn't the home-page(s) also be updated? <jlicht>apoorv569: sorry, that came out wrong; shouldn't the updated home-pages be listed in the commit log? <adanska>jlicht, yes thats right. home-page is one of those fields that you should put in the changelog. apoorv569 <jlicht>apoorv569: one of the fields of the package-record you updated in your commit :-) <simendsjo>adanska: Thanks. I see new commits coming in though, but I guess the entire repo is "broken" until the tests are fixed? I'm using the commit prior to the new tests for now. <apoorv569>jlicht: Ah! Alright, can I combine all changes in line or new line for thing I changed? <jlicht>apoorv569: not on my pc, but you should be able to find existing logs that describe a similar change :) <apoorv569>I wanna submit a bunch of music related packages, can I sumbit all in 1 PR with individual commits? or do I create new branch and/or PR for each package? <simendsjo>apoorv569: My guess is one PR is ok as it's a fast-forward merge rather than a merge commit. <apoorv569>simendsjo: I see. Ok I'll submit one commit then. <apoorv569>I am trying to fix the WDL package as it won't build ATM. The patch it uses is wrong for latest commit, do I manually edit that patch? like copy my diff to that file or what? <PotentialUser-64>`xbacklight` nedds superuser permissions to run. I wish to call it, with specific arguments, through keybindings from my window manager, but if `sudo` nedds a password, it won't work. `suid` bash scripts don't work either. Does anyone here have an idea? <noe>IIRC, there are other ways to change the backlight that don’t need root <ieure>Why would xbacklight need root? It says it uses RandR to control it, you don't need root for that. <noe>I think it only uses RandR to find the displays but it needs root to change the backlight <PotentialUser-64>I think that xbacklight also controls system LEDs. Maybe those may cause problem if a user misbehaves? Or because it controls the brightness through changing the power sent to the screen and not by changing the gamma values? I am just guessing. But it is inconvenient, yes. <ieure>PotentialUser-64, Maybe it needs udev rules to give you permission to write the backlight control file in sysfs? I added some to emacs-blight, you could steal from there or just set up a udev rules service with emacs-blight and see if that makes it work. <Rutherther>In Linux, all devices are manageable only by root by default and you need to do something so that they are manageable by a user. In case of devices, it is usually a udev rule that changes the owner or permission mode so that users have access to the device. This is completely normal and expected behavior. If you want your user to be able to change brightness, you need to add udev rule to chown/chmod the brightness control file. <Rutherther>the udev file in emacs-blight has support only for brightness and not leds. So if you also want to control leds, different udev file has to be used. For example package brightnessctl has udev rules for both backlight and leds <PotentialUser-64>Rutherther I only need the screen for now. I find the default, after booting, too bright. But some times I need to raise it a bit. <Rutherther>then both emacs-blight and brightnessctl udev rules will work and you can for example use service returned by udev-rules-service to get the udev rules in your system services. <PotentialUser-64>udev rules seem to be quite useful. I still need to learn about them. But emacs-blight seems to be very close to what I seek (sadly, I don't live in Emacs). Thank you, Rutherther, ieure and noe. I will look into it. <Rutherther>the udev rules are for devices, not for specific packages. Using udev rules emacs-blight will work even with xbacklight... <Rutherther>any declarative changes to system are made through your operating-system config, that probably lives at that place for you, yes <dstolfa>civodul: that's a pretty old abseil, considering they recommend staying at the head of the main branch <civodul>dstolfa: yup; i was referring to the third ‘guix pull’ breakage of that past 12h or so <andreas-e>civodul, dstolfa: I have found an easier way of finding unresolved variables than doing a "guix pull": "./pre-inst-env guix package -A whatever". <andreas-e>The irony is that this old abseil-cpp is only used for packages that do not build, and that I had actually already scheduled for removal. But we are still in the one month waiting period. <civodul>andreas-e: heh, ok (i usually just ‘git grep’ for this) <andreas-e>civodul: Well, "git grep" is a good point. I am only just learning that "guix refresh -l" does not suffice. <andreas-e>But "guix package -A" apparently traverses the packages and shows if there is a problem with "undefined" packages. <podiki>(and there is no long version of -A?) <podiki>i mean --list-available not in the manual <podiki>oh wait, i'm looking at guix build specifically... <maerggie>Hey there. I'm trying to update a GUIX system, which I set up 1.5 years ago. Fact is I couldn't and still cannot boot it directly from the disk. I'm using GRUB from a Ubuntu live-USB and open the configfile that was created by GUIX. Then I choose linux 6.15 which I updated already and everything else seems to work. <maerggie>Now when reconfiguring the system there are problems installing grub: it says: /gnu/store/003vigxd47z66n6kpsyrx4pr5mnwv2cg-grub-efi-2.12/sbin/grub-install: error: /gnu/store/003vigxd47z66n6kpsyrx4pr5mnwv2cg-grub-efi-2.12/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory. <identity>maerggie: is there anything in ‘/gnu/store/…-grub-efi-2.12/lib/grub/i386-pc/’? <maerggie>When I run grub-install manually adding "--target x86_64-efi" grub gets installed but then another error happens and no new system generation is created. <maerggie>No i386-pc seems to not exist, however x86_64 has everything.