IRC channel logs
2025-07-21.log
back to list of logs
<jnms>I started using guix recently, soon followed by emacs. After using scheme I though wow, elisp kinda sucks. rkazak: I tried guile-emacs at the time but also hit some error. <squid64>is guix package -u and guix upgrade the same thing? <nomike>I just deleted the /docs folder and recovered it´s contents from git. `make clean && ./configure && make` and things work now. <robin>rkazak, are you using the upstream guix package? what kind of problems are you running into? <nikolar>is it possible to use herd to start up services on boot on a foreign distro <Kolev>Can Guix System do Distrobox yet? <Kolev>That is, can I run a Debian container in an emergency, if I can't do things the Guix way? <Kolev>robin, so it does work, but it's finnicky? <robin>Kolev, i don't know :) it sounds like fredrik got podman working but not distrobox (in 2023), i got the same errors testing it out-of-the-box (no container-registries.conf, no policy.conf) and haven't tried to fix it yet <Kolev>robin, I see. I'd use Guix on my server if I could get a Debian container. <robin>Kolev, i wonder if podman or docker might be easier? i'll let you know if i get it working, i'll have to install debian on my laptop or something for software testing otherwise <robin>(i usually use throwaway VMs but they're painfully slow, maybe due to btrfs) <apteryx>robin: VMs are zippy for me, but I keep them on a -C (nocow) chattr'd btrfs file system <apteryx>also if you use something like GNOME the opengl acceleration is a must <apteryx>anyone has a recipe to concatenate multiple manifests that are in the same directory? <apteryx>I need some relative path trickery I think, like inferring the directory the main manifests is in <apteryx>in python that'd be something like dirname(__FILE__) <meaty>Has anyone here deployed an oci-container-service-type (docker container) service to a 'guix deploy'-managed server or know of any resources on the topic? <meaty>I'm trying to deploy the freshRSS docker image to a VPS, but I can't get it to work in 'guix system container' because of wierd network access issues with docker <meaty>despite an nginx server running in the same os definition successfully serving a website <meaty>also, the docker service demands that a couple of other services be installed to accomodate it (containerd, dbus, elogind, syslog). Isn't this kind of thing normally organized "automatically" in the background by guix? <getstate>Is anyone else having issues building ffmpeg@6.1.1? One dependency, `frei0r-plugins` has a hash mismatch. <getstate>it doesn't look like it was updated/changed recently... <meaty>getstate: guix build --check frei0r-plugins succeeds for me. unless you mean something else? <getstate>meaty: I do mean frei0r-plugins, I get a hash mismatch <getstate>guix build frei0r-plugins --no-substitutes fails. <meaty>getstate: "works on my machine" (guix 9b044b7 Jun 26 2025), what architecture are you on? <meaty>6.1.1 is available on my commit <meaty>if it works then, the issue can be bisected <robin>(discussing build issues with rkazak in #guile-emacs) <robin>apteryx, good to know, i don't know for sure that it's i/o making it slow, just that people complain about it :) (i do have nocow set). i really only use virt-manager these days for a windows-only scanner, so not much need to debug it <getstate>meaty: still get a hash mismatch on the commit <meaty>getstate: did you `guix gc --delete` the old outputs (including ones that were grafted) before trying? <meaty>maybe it's just a corrupt store item somewhere <getstate>I ran guix gc and tried again, same thing <meaty>well, i am stumped then. this is exactly what guix isn't supposed to do <meaty>it's a hash mismatch of the binary output, right? <meaty>not the sources downloaded at the start <getstate>Ah should have been specific, it is the sources (thought it was a supply chain attack) <getstate>hence why I was asking around for people to build it, but if it builds for you then I have no idea what's going on. <ekaitz>how long is this going to happen? <nikolar>can i use guix to start up services on a foreign distro <attila_lendvai>nikolar, shepherd can be run as non-root. the answer is probably yes. <attila_lendvai>well, the point is not non-root, but that shepherd doesn't need to be PID 1 <nikolar>attila_lendvai: yeah i know that part <nikolar>i just don't know if there's a guixy way to make a non-root herd run services specified in a scm file or something <identity>nikolar: you probably want (info "(guix) Home Services") <nikolar>i don't want a home service though, i want the services to start on boot, not on login <csantosb>I noticed that "guix shell -C --preserve='^XAUTHORITY$' --expose="${XAUTHORITY}" --preserve='^DISPLAY$' librewolf -- librewolf" complaints about a missing statfs <nutcase>csantosb: ${XAUTHORITY} is empty. maybe? <z572>Not sure what you mean, I opened PRs for all the ones that can be directly merged into master. The rest of them must be rebuild many packages. <andreas-e>Well, I was a bit afraid that with all the changes from core-packages-team, they would be lots of complicated merge conflicts. <andreas-e>I am taking out the last commit on obs, as I think that there should be some discussion between the two patches on codeberg. Actually, this one also has a PR for master! <andreas-e>Then I am going to build it and reopen the merge request. <cbaines>I'm going to stop the guix gc to allow bordeaux build farm builds to be submitted <cbaines>I'm also going to clean up the multiple nginx instances running <noe>cbaines, did you figure out the empty derivation inputs problem you had? <cbaines>noe, I think I've cleaned up the broken derivations in the database, but I'm still not confident the problem is gone <andreas-e>cbaines: Strange! I have just reconfigured the other day, and that was it. There was some discussion of changing the nginx service, from the surface of it the arguments souded convincing. <andreas-e>It would be nice if you could apply at least my armhf patch to qa-frontpage (assuming that I did not overlook anything in the code), so that build submissions from branches will be enabled. <andreas-e>Apart from that I indeed had the impression that some builds for master were also queueing up; we had lots of commits and little activity on the build farm. <andreas-e>On the positive side, the two data service instances are quietly moving on! <cbaines>due to the garbage collection on bayfront, there haven't been any builds submitted today, but hopefully some will be submitted now <noe>cbaines, spooky! Thanks for your work on QA :) <andreas-e>cbaines: Thanks, will push, and then update the qa-frontpage snapshot in Guix, and reconfigure bayfront. <hwpplayer1>Does GNU Guix hackers help to GNUnet development ? <vntsuyo>I have successfully installed my Guix config on a laptop today <vntsuyo>I noticed that several packages were failing to build though, I had to disable some of them to reconfigure <andreas-e>hwpplayer1: No, unless there is some overlap between developers; but we package it. <andreas-e>vntsuyo: You have arrived at an unlucky moment, we had a big merge on Friday and are still recovering. Some packages are broken. <vntsuyo>the ffmpeg bug seems to have been fixed. i'm uncertain about mit-scheme, ruby-solargraph and easyeffects <vntsuyo>why don't we let members who have access to one of the substitute servers see what failed to build and compose a list of it? <andreas-e>Repairing takes a lot of work... And we have some outdated software, or software that some day someone has added and maybe nobody uses any more. So I prefer to work on software someone actually cares about. <identity>vntsuyo: the problem is not that we do not know what fails to build, it is that we do not know what we should fix! <identity>if you use stuff that fails to build because of gcc14 strictness, the fix is usually as simple as adding "-Wno-error=insert-warning-here" to flags passed to gcc <vntsuyo>the build errors kinda reminds me of nixos <dariqq>i havesuccessfully reconfigured my i686 machine now. It is now only in a slightly more broken state compared to last week. Thanks a lot andreas-e and lilyp for the help. <andreas-e>dariqq: Excellent, congratulations! And thanks to you for your help in getting things going. <z572`>ACTION Preparing Qt 6.9.1 update <fnat>My first time pushing something to Codeberg, I guess there's no point in creating a patch? I suppose I need to fork the repository to my own Codeberg account, push there, then create a pull request? <fnat>Sorry, this is pretty lazy of me to even ask... I can simply give it a try... :) <identity>fnat: you can create PRs from your local clone, though i am definitely not the one you should ask about that <umanwizard>andreas-e: Good news, google-highway latest version builds fine for me even without any patch. <umanwizard>I will make sure its direct deps still build and then submit a PR. <andreas-e>umanwizard: Nice! The dependents will indeed be the moment of truth. <umanwizard>it's incredible how slow building C++ is, how nobody has fixed this in 40 years of the language's existence is a mystery. <andreas-e>Indeed, compared to C! It is just more complex as a language. <umanwizard>AFAIK the biggest problem is that using templates forces you to write implementations in header files. So every .cpp file has to recompile every templated type it uses (which includes the standard vector, string, hashmap, etc.) <andreas-e>Hello neox! Thanks for all your issue filings on codeberg. Do you think you could propose pull requests for some of them? Sometimes the easiest fix could be an upgrade. <fnat>If any gentle soul wanted to give a look, hehe. :) <identity>umanwizard: it would not be that much of a problem if C++ did not inherit the header-ache that are headers (ha!) from C, simply expanding the #includes takes A Moment <andreas-e>fnat: Congratulations! From a cursory look, it should be good; I am compiling something else right now and will give it a try later. <fnat>Thanks so much Andreas, sure, whenever you can, no hurry. <neox>andreas-e, I'm still in the process of testing each of my package and retrieving logs to open other issues... <neox>I'm not a C++ expert, and I don't know the code base of many of these packages. If I can contribute with opening PR, I'll do it for sure, but that's not what I can do right now <old>I see that gcc-15 is now packaged <old>and it is why half the package I used can not be build without fixing :O <neox>old, yeah, core-package team merge. This is why I open an issue for each package I use that breaks, in the hope it can help fixing them <old>I note the following: emacs-denote, kitty <old>don't think emacs denote is actually a gcc related thing <identity>old: kitty should be fixed on latest master i think <old>I did pull this morning but maybe it was fixed during the day <andreas-e>old: The distribution is now built with gcc@14. This is independent of the user facing gcc-toolchain, which has been @15 for a while now. <old>identity: confirmed fixed for kitty <andreas-e>neox: Sure, no problem! I am just trying to onboard more people :) <andreas-e>old: emacs-denote has already been reported. <umanwizard>no pressure :) I figured out how to `guix pull` from my local checkout now, so no longer blocked on you reviewing before I can try to reconfigure again. <andreas-e>umanwizard: This one is a bit frightening. Only two direct dependents and hundreds after that; I hope everything will go through. <umanwizard>BTW, the instructions in the PR template are slightly wrong: guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master --disable-authentication <umanwizard>That pulls from the master branch of your checkout, not whatever branch is currently checked out <umanwizard>Well, maybe "wrong" is too strong, but at least, the instructions are incomplete. <andreas-e>I noticed that "git fetch pulls --prune" prunes nothing; do all the pull requests live forever on codeberg? There is no point in keeping the closed ones locally. <andreas-e>umanwizard: I never do this, so far I have reconfigured with ./pre-inst-env from time to time. <umanwizard>we discussed that a few days back; I could never get it to work. Not sure why. <umanwizard>ah yes, it's because it can't find stuff from my personal channels <umanwizard>guix system: error: failed to load '/home/brennan/guix-home/config-desktop.scm': <umanwizard>ice-9/boot-9.scm:3330:6: In procedure resolve-interface: <umanwizard>if you don't use any non-default channels maybe it does work <andreas-e>We are too GNU! I type "hurd restart ..." and wonder why auto-completion does not work... <andreas-e>neox: For packages that fail quickly currently, I think you do not need to add a build log. It is most probably a gcc-14 issue that is easy to reproduce... <nomike>Or do I just wait for someone to pick it up? In other words: Is this a poll or an interrupt process? <andreas-e>nomike: Both can work :) Sorry, I just do not have the time right now, and before I push, I always look at the commits myself as well. <umanwizard>I'm able to get a lot further in my config after applying the google-highway fix. Now I am failing in qtbase@6.8.2 <Kabouik>emacs-org-ref seems to depend on `kpsewhich` for some things but I don't think that binary gets installed with it, and I am not sure which Guix package provides it. `guix locate kpsewhich` returns nothing for me. <Kabouik>Maybe texlive-bin, I'll try to guix shell that. <Kabouik>Yeah that's it. Maybe it should be a propagated input? <umanwizard>andreas-e: I imagine qtbase is depended on enough that we'd rather just disable the failing test on aarch64, rather than trying to upgrade it? <andreas-e>umanwizard: There are efforts for upgrading it in the qt-team branch (but only qt5), and then z572 announced earlier that they would like to upgrade to 6.9. In the meantime, disabling a test sounds okay. <Kabouik>csantosb: texlive-bin for me, I think texlive-libkpathsea mentions the keyword in its description but I'm not sure it's the one providing the binary <podiki>anyone know anything about landlock? <podiki>gcc-14 is default now right? do we prefer when fixing packages that e.g. had gcc-12 specified before to remove so it uses default or stick to explicit (change to gcc-14 in native-inputs)? <andreas-e>There is no reason to make it explicit, removing it would be better. Then it will move on to gcc@15 and so on. <podiki>that was my thought, but did see some comits doing the latter <podiki>perhaps some cases where we expect to keep some explicit version or match with something else which may not be default <podiki>but probably mentioned libraries use default gcc as well <andreas-e>Okay. I see packages that specified gcc-14 before the move, probably just to enforce a minimum, like hypridle. <podiki>yeah all the hypr* packages needed gcc-14 before <podiki>(and are due for an update now actually) <podiki>so i think can just remove the explicit gcc-14 for all of those <fnat>Thanks for merging #1464 andreas-e! <podiki>still hitting issue with darktable, now "sorry, unimplemented: Graphite loop optimizations cannot be used (isl is not available)" <podiki>something about gcc and graphite...what's new for guix moving to gcc-14 here?