IRC channel logs
2026-01-20.log
back to list of logs
<noe>FuncProgLinux, sorry I have no idea how autotools work <bdunahu>Is there an obvious way to instantiate a very large hosts file (100,000+ entries) while keeping the default entries? It's very expensive to assemble all of the host records for use with host-service-type each reconfigure. <bdunahu>it seems like for this use case, I would need to read in an existing hosts file, do substitution of the system's host name, and install the result, ignoring the service. <mange>hosts-service-type just extends etc-service-type with `(("hosts" ,(plain-file ...))). It shouldn't be too hard to do the same sort of thing yourself. Just remember to remove hosts-service-type from your services as well. <acidbong>on Guix git workflow: is having gpg a requirement? i sign my commits with ssh and i wonder if that's a problem with my pre-push hook <acidbong>(the hook installed by guix git authorize) <mange>If you're just raising PRs it's fine, because the committer will sign the commit that ends up in the repo. For your own stuff, guix authorize does not support SSH signatures, as far as I know. <acidbong>1. i create a commit with `etc/committer.scm` > hook refuses to push an unsigned commit <acidbong>2. I'm running `git commit --amend --no-edit` to sign it > Guile complains about not getting some kinda response <mange>Is this in a clone of the Guix repo? <acidbong>(damn revolution can't reconnect) i hope i didn't miss anything <acidbong>i guess I'll need to run make one more time <oliverD>I force restarted gnome because it hung when i had 12 tabs open in crominum. Now when i log in it just tells me to log out. I've tried rebooting, removing the cach files from gnome, installing gnome, rolling back guix, and the error keeps happening. <oliverD>I removed ~/.config/dconf and ~/.local/share/gnome-shell <efraim>building guix on powerpc-linux stopped after 801 minutes with 'dot' missing. installing graphviz and continuing on <oliverD>I tried logging in as root and it works but I would prefer to avoid creating a new account and transferring everything over. <nckx>rebel1725: The (academic) institution hosting those servers have their own firewall and very little patience for abuse. <allana>Hi guix! I recently upgraged guix and am transitioning from hacked up rootless-podman setup to the newer rootless-podman-service type, and things no longer work. I am bangning my head against the wall at this point. It's probably something small that I have missed, maybe a remnant config somewhere that I don't know about, but I can't seem to find out why it does not work. I think my problem is permissions related. So, my question, is <allana>anyone successfully using a recent rootless-podman-service type successfully, and would anyone be willing to have a look with me? My specific problem at present is a complaint about newuidmap not being able to set up a namespace. <stfnbms>I am trying to install a shepherd timer in Guix Home, but don’t seem to be able to get the syntax right. I have: <stfnbms> 'empty-trash home-shepherd-service-type <stfnbms> (list (shepherd-timer '(empty-trash) <stfnbms> #~(calendar-event #:hours '(10) #:minutes '(11)) <stfnbms> #~(#$(file-append trash-cli "/home/stefan/.guix-profile/bin/trash-rm") <stfnbms>This installs, but does not do anything. <lilyp>stfnbms: can you inspect the generated shepherd file? <stfnbms>lilyp: Where would the generated shepherd file be? <civodul>allana: hi! re rootless-podman, ISTR there’s an open bug stating it “conflicts” with rootless guix-daemon for some reason <allana>civodul: Thanks, trying to dig a little deeper. I just now found a reference to a similar and timely error report on the guix-help mailing list. Is codeberg down? <allana>Yes, well, I think that I just found a solution/workaraound from the mailing guix-help list. It involves using the subids-service-type. I think that either guix-devel documentation is ahead of the code or there could be a mistake. I will try to point this out in the mentioned issue on codeberg when it becomes more responsive. Thanks :-) <lilyp>stfnbms: within your generated configuration, you might want to grep for the service <Kabouik>Trying to create an Emacs profile on a machine the same way I did on mine: I have a manifest, and I install things using `guix package -m manifest.scm -p ~/.guix-extra-profiles/emacs/emacs`. All packages are found correctly but it fails eventually with a "guix rename-file: is a folder" that I have never seen before. <Kabouik>Also I deleted the profile (rm -rf /path/to/profile) at some point to restart from scratch, made sure I had no emacs installed in the main Guix profile (`guix remove emacs`), then garbage-collected, and somehow KDE Plasma still lists Emacs as an available application and manages to launch it. Upon editing the shortcut, I see that it still points to a valid /gnu/store/*emacs*/ path. <flurando>gc would not clean any package in use, which is the case of your emacs, I suppose. <Kabouik>I don't think so, it was closed and we are not using an emacs daemon/emacs client system on that machine (Emacs is still unconfigured). <flurando>mmm, in use means "something in profile depends on it" <flurando>if it is not cleaned, desktop environment would refer to it according to its cache <flurando>try reboot, see if emacs could still be opened using the main profile <flurando>By the way, unless you got good reason, making a exclusive guix profile for emacs is not common. <flurando>guix remove emacs only remove emacs from the package profile, it does not interfer with system or home profile, consider this. <Kabouik>I actually have read conflicting perspectives about it and just settled with it with no strong opinion on it myself, but can't afford to change my mind on this too often. For me, however, the benefit is to avoid breaking all my generic package upgrades when I break something with emacs packages (I use the guix-emacs channel which can create conflicts), and vice versa, which can save me some headaches when I need to get something done quickly and an <Kabouik>upgrade forces me to debug things when I don't have the time. <Kabouik>We didn't reboot but we logged out and back in, does that count? <flurando>Yes, that counts. But I suggest you to check the "main profile" if emacs is included in system profile or home profile, since "guix remove/uninstall emacs" only modifies the package profile. <Kabouik>We don't use guix home, and this is Guix on a foreign distro, so there should be no system profile either I assume (there is no config.scm and no guix system reconfigure) <Kabouik>I'm hoping it's just a cache issue that would get resolved at some point, but am still very surprised that KDE still finds a (working) Emacs desktop launcher with a valid /gnu/store/path, while `emacs` in the shell or `which emacs` find no valid binary in PATH. <Kabouik>But the more important issue is this `guix package rename-file: is a folder` at the end of the compilation of packages listed in the manifest. <Kabouik>Hum, maybe I did something wrong actually. I ran `mkdir ~/.guix-extra-profiles/emacs/emacs`, I think I should have omitted the last subfolder, guix should create it when installing the manifest. <flurando>I have never used seperation in profile level, so 0 exp in creating such an emacs profile. However, it sounds alien to me that guix-emacs channel conflicts with official channels, as every channel has responsibility to make sure packages and services don't conflict with the most common official ones, by naming or equivalences. <flurando>If you must use a bleeding edge emacs that requires guix-emacs, which couldn't co-exists with main channels. I think a better way might be going guix-container-shell-shebang way or urge the channel maintainers to take care of compatibility with at least the official guix channel. <flurando>For my case, I always use prefix when #:use-module so it is unlikely two channels I use conflict. <flurando>I could see no need in your case of using a standalone profile just for emacs. And if it starts requiring your manual maintainence, I am afraid you are using Guix wrong. Guix's goal is configure once, deploy everywhere, and extra profile is for development/extremely-uncommon usage <listentolist>Is it possible to work around the "having to to type luks passphrase twice" issue by using an unencrypted /boot partition? Or are there other ways? Is there any guide how to set it up? <attila_lendvai>listentolist, if /boot is not encrypted then you only need to input the password once <attila_lendvai>listentolist, and while we are at it, IIRC there are some ways for grub to communicate the password to the linux kernel, but i don't think these are well-tested, widely used methods. it's been a while i read about this. <listentolist>So the simplest solution is unencrypted /boot. I will do that then. Thanks! <acid-bong>ight, back to `git push` with Guix auth hooks: even after running `make` (as folks in the linked thread suggested) they still don't let me push (and mailing lists are down again, smh my head) <cricri86>Hi guix! For work, I need a more recent of docker than provided by the official guix channel. What would be your recommended method to get that? My method of choice would be defining a package variant. But this part from (gnu packages docker) stops me from doing it: <cricri86>;; Note - when changing Docker versions it is important to update the versions <cricri86>;; of several associated packages (docker-libnetwork and go-sctp). <acid-bong>cricri86: see `guix refresh` manual section and `man guix-refresh` for updating deps <acid-bong> or you can also `guix refresh` multiple packages explicitly: `guix refresh docker docker-libnetwork` and so on <ieure>cricri86, I believe there are Go related things that need to be addressed to update the Docker stuff, but I'm not 100% sure. It is *very* out of date, ex. it's still using docker-compose instead of `docker compose'. I switched to rootless podman. It's okay, but much more fiddly. <Kabouik>sneek: later tell flurando The guix-emacs channel can conflict with official channels because it's a script-based channel that packages Emacs packages from MELPA, it's not really tested before every commit (except maybe some automated tests), let alone against emacs-* packages in the Guix channel. And this is what might be the issue in most cases, a mix of packages coming from this channel and from the official channel, since guix install doesn't <Kabouik>readily allow choosing the source channel when packages have the same name. Also some Emacs packages in the official channel are also modified to fit the Guix paradigm, compared to their MELPA version, and that, the guix-emacs channels fails to reproduce, so I do have to mix them. It's not optimal, I agree. But there are too many packages I need that are not officially packaged yet by a human for Guix. <acid-bong>also cricri86 note that, if a version jump is big enough, you're gonna adjust packaging as well; i'm bumping Gucharmap and had to rewrite the recipe a bit, cuz they switched from Make to Meson <Kabouik>sneek: later tell flurando By the way, the "guix package rename-file: is a folder" was indeed the issue I mentioned: I should not have created the last level subdirectory before invoking guix package -m xxx -p xxx. <acid-bong>huh, turns out i needed to `./pre-inst-env guix git authenticate` from inside a container first <FuncProgLinux>then again what can one expect from something written in python ._. <ieure>FuncProgLinux, Strange error, what's the XML file it's trying to parse? Can you add a phase to dump its contents and compare between non/working builds? <ieure>Also odd that it would be inconsistent. <FuncProgLinux>It's in the build phase but I still don't know what causes it to build when it wants to :/ <ieure>Right... figuring out what the file it's failing to parse is step one of figuring that out. <FuncProgLinux>Stupid question. Could this be caused by a missing configure flag? <acid-bong>is Guix website always down when a new commit is built and deployed? <Rutherther>Last commit to it was yesterday. Then 6 days ago <FuncProgLinux>I found out it failed "randomly" at any subdirectory for each language docs/help/ on my computer usually between the "es" and the "fy" locales. I suspect due to some of them having only a .po file and others both a .html and a .pdf file inside (plus .png figures) <FuncProgLinux>I've added explicitly the "--enable-html-manuals" and the compilation is not failing, I left 10 rounds of rebuild to check if the reproducibility issue is still there. I'll report back once it finishes <acid-bong>Rutherther: last commit to master was 30 minutes ago, and exactly around that time the website was down <acid-bong>dang, i need to download a pdf when it's back up <FuncProgLinux>acid-bong: If you are using guix system there's already a copy of the guix manuals in your profile <ieure>I believe this is the case even if you're using Guix on a foreign distro. <ieure>FuncProgLinux, I'd focus on making it work locally first. <ieure>I'm assuming this Cuirass where it's failing is CI or QA? <FuncProgLinux>ieure: I'm rebuilding locally. I failed to provide more context. My bad :/ <ieure>FuncProgLinux, Ah, well uh. I'm not sure then. *Python* is segfaulting? That's not good. <FuncProgLinux>Yesterday the bot commented my merge request with this failure: https://pulls.ci.guix.gnu.org/build/1294107/log I thought it was strange because I was getting a very different error (Type error in Python) but now that I "fixed" it I wanted to make sure by rebuilding 10 times to check for reproducibility issues <FuncProgLinux>and with this "fix" I managed to get the same error the bot got on CI <acid-bong>dang, turns out flushing DNS cache helps in bringing Guix website back <ieure>acidbong, That's strange, I don't think that can't be due to building commits. I strongly doubt we're replacing a DNS record when updating the manual. <ieure>Guix has an unfortunate reliance on nscd, which I would ordinarily never, ever run. Had many a name resolution issue caused by it. <Rutherther>acidbong: commit to master of what repository though? The website is hosted at guix/artwork <Rutherther>acidbong: or are you talking about the manual, not the website? <Rutherther>note that the period of the builds of the manual is an hour <Rutherther>ieure: it contains a lot of security fixes, so I would say master because of that <ieure>Rutherther, Alright, thank you. <ieure>Rutherther, It touches icu4c and nss-rapid, since they both needed updates. But only browsers use nss-rapid, and it uses a later icu4c than the default. <FuncProgLinux>ieure: I found the culprit, and now I'm able to reproduce up to 15 times ._. <FuncProgLinux> (invoke "rm" "-rf" "docs/help/da") not the most "elegant" solution but... <ieure>FuncProgLinux, Presumably that rm means the package has no Danish documentation? <ieure>FuncProgLinux, Look on the bright side, it's only a problem until the US conquers Greenland. <FuncProgLinux>I'm now 99.9% sure. I've updated the merge request and did 20 builds just to make sure. All 20 succeeded <ieure>(sarcasm, that whole thing is one of the most painfully idiotic shitshows I've seen in my life) <ieure>FuncProgLinux, Maybe the locale declared in the build is part of the problem? <FuncProgLinux>ieure: It dies when referencing a file from docs/help/C inside the docs/help/da/da.po file. But the files inside "C" haven´t been updated in 5 years <ieure>FuncProgLinux, Absolutely sounds like this is a locale issue. <FuncProgLinux>The last thing I expected to have reproducibility issues are the docs of something ._. <FuncProgLinux>I'm looking into other distributions to see if their maintainers have stumbled into this as well. <dariqq>FuncProgLinux: it seems to work for me with --cores=1 <dariqq>yes. Maybe its some kind of race condition <FuncProgLinux>dariqq: I find it strange that it's on that particular directory <dariqq>nervermind it seems i got lucky before. It crashed after retrying <oliverD>I uninstalled ungoogled-chromium (the app that crashed) and now my computer doesn't tell me to restart <attila_lendvai>how much effort would it take to package guix for openwrt (aarch64)? and would it be useful? <ieure>attila_lendvai, What would a package for OpenWRT do? Build the firmware to install on a router? <attila_lendvai>ieure, i'm not sure. my first idea was to set up a build worker on openwrt. and my second one was exactly that, to help porting guix to a new arm board (BPI-R4) <attila_lendvai>FuncProgLinux, is there a binary somewhere? and is it statically linked? <ieure>aarch64 is already supported by Guix. <ieure>Binary depends on what you're running. I don't think any Guix binaries are staticl <attila_lendvai>what i'm asking about is a guix binary that runs on an aarch64 openwrt install <ieure>Okay, I see, I was thinking the other way around. <ieure>You'd have to build Guix using the OpenWRT packaging infrastructure, I have no idea what that looks like. <ieure>attila_lendvai, I'm not sure Guix is a great fit for this application, honestly. It's CPU and storage intensive in ways that you generally don't want in an embedded system. <ieure>And it's not like OpenWRT is suddenly going to get Guix package support in LuCI, change its config system, etc etc. <attila_lendvai>ieure, but what about building a statically linked guix? if the daemon and the guix binary could be cross compiled, then it would be a very easy way to jump from computer to computer. it's probably much more headache, though... because of the guile dependency and whatnot. i doubt statically linking this beast is an easy feat. <ieure>FuncProgLinux, it's the web admin console for OpenWRT. <FuncProgLinux>attila_lendvai: Idk if it's possible to statically link guile <FuncProgLinux>I wanted to replicate the "portable binaries" from Janet on guile programs but that was a big no-no <ieure>attila_lendvai, Why do you care about it being statically linked or not? It's written in Guile, so the only thing linking anything is going to be Guile. Lisp VMs typically have a pretty small dynamic library footprint anyway. <attila_lendvai>ieure, hrm, right. the guix "binary" is just a script that starts guile. <attila_lendvai>so, it boils down to getting a guix daemon and guile ported/compiled. <ieure>attila_lendvai, I'm not sure if it works like that or not; at least with CL, you'd dump an executable Lisp image. And we definitely compile a ton of .go files. But not sure if those get combined into an image or Guile notices they exist and uses them in preference to recompiling, or what. <ieure>attila_lendvai, What's the goal of running Guix on OpenWRT? <ieure>To FuncProgLinux's point, though, Guix already runs on aarch64, there's no porting needed. You just have to compile/install/use it. <attila_lendvai>ieure, AFAIU guile just loads .go files instead of their .scm counterparts. and .go files are ELF files, but i think they only have bytecode, not machine code. <attila_lendvai>ieure, my ultimate goal would be to port guix to the BPI-R4. and i was thinking maybe this would help get some stuff to work before i would try to boot up guix system. <ieure>attila_lendvai, What does "port guix to the BPI-R4" mean to you? <Rutherther>what does it mean to 'port' it, it's a regular aarch64, you can just install on it like on every other aarch64 machine, ie. through the guix-install.sh script, downloading the latest release tarballs <attila_lendvai>ieure, there's a lot of headache with ARM boards and the boot process. maybe porting is not the right word here, but to create an image that the board can boot. <ieure>attila_lendvai, Aha, okay! Now we're getting somewhere. <Rutherther>so you're talking about guix system and not guix? how does that relate to openwrt then? <attila_lendvai>Rutherther, oh, the guix-install.sh works on aarch64, too? let me try... <ieure>attila_lendvai, You can do that on an x86 machine using qemu. Or install the Guix package for Debian on a Raspberry Pi. Use one of those to make the system image, then boot it on your hardware. <Rutherther>maybe openwrt won't have all the dependencies, not sure. Even if it didn't, you could install manually repeating the steps from guix-install.sh, but with the openwrt command equivalents <ieure>attila_lendvai, Looks like there's a bootloader for the bpi M2 Ultra in Guix already, as well as an example installer image. Probably a good place to start. <ieure>attila_lendvai, You can edit the shebang to have -x, or run it with `sh -x install.sh' to see what's going wrong. <ieure>OpenWRT uses busybox to save space, I'm not sure how POSIX-compliant those are (or if the install script limits itself to POSIX compliance). <ieure>I do not think running Guix under OpenWRT is the right move here.