IRC channel logs

<ieure>amano, Dependencies are expressed as lists of Scheme variables which are bound to package definitions.

<amano>So, if I create a new guile symbol that inherits B, it is essentially a new package?

<amano>Can I override an existing guile symbol?

<amano>But, you can surely define the same guile symbol again later.

<amano>But, I guess A won't pick up the new guile symbol for B.

<ieure>So, assume Guix has package A and library B. Package A builds against library B. Now you create a new package which inherits from B, which we will call B' (b-prime). This is a completely different package, and cannot change the result of having built A, which still depends on B.

<ieure>You can only change this by creating a new package A' which depends on your B'.

<amano>On gentoo linux, you can just modify B without redefining it.

<amano>One can add local modifications to B as long as you are willing to rebuild it.

<ieure>Yes, many distros allow this.

<ieure>If that's critical to your usecase, one of them may be a better fit for you.

<amano>With this, I can modify /etc/pam.d files in B.

<ieure>ex. in Debian, Python depends on libc6, and multiple versions of libc6 can satisfy that dependency at install time. Guix dependencies are resolved at runtime.

<amano>But, I think guix uses services for putting files outside /gnu/store.

<ieure>Sorry, Guix dependencies are resolved at build time.

<amano>If I just want to modify files outside /gnu/store, I guess I can write my own local service for that.

<ieure>There may be a way to express that already; I'm not sure. But other areas like this do give you a bit higher level control.

<ieure>ex. Guix packages can ship udev rules in a special location within the output, and those get combined to form all the udev rules active for the system automatically. There might be something similar for PAM stuff.

<amano>For PAM, there are services....

<amano>screen-locker-service-type creates a symlink in /etc/pam.d to a file in /etc/pam.d in a guix package.

<ieure>Do you want to modify files linked into /etc/pam.d by existing services, or add your own files there?

<amano>I may want to build on top of screen-locker-service-type by adding a few lines to symlinked files in /etc/pam.d.

<amano>I want a service that adds a file that adds a few lines to a symlink in /etc/pam.d

<amano>I don't know whether I can specify service dependencies.'

<ieure>amano, You can't readily do that, because the symlink points to a file in the store, which is immutable.

<amano>But, I can read the symlink and replace it with a plan file that adds a few lines to the content of the symlink.

<amano>a plain file

<amano>A local service that depends on screen-locker-service-type can do that?

<ieure>I would recommend against that, you probably shouldn't be messing with what other services are setting up. For this specific ask, I think the easiest course is to create your own version of whatever screen locker you're using, by inheriting the original package definition and modifying it to change the pam files. Then install that *instead of* the stock screen locker package, and reference its binary in your screen-locker-service-type

<ieure>definition.

<amano>ieure: If I specify service dependencies, service execution can be serialized.

<amano>Or, I can write a new local service that inherits from screen-locker-service-type?

<amano>Something like screen-locker-pam-gnupg-service-type

<ieure>I'm not sure if services can be inherited from.

<amano>I think service dependency is a cleaner way.

<ieure>I don't recommend it, but it's your funeral.

<amano>Service dependencies can serialize execution.

<amano>I can replace a symlink with a plain file safely.

<ieure>I understand what you're saying. Again, I do not recommend it.

<amano>It produces less redundant code than creating a chain of inherited packages.

<jmes>When I install vulkan-tools & vulkan-loader, then run vulkaninfo, it reports that the Vulkan loader is not installed/found or failed to load, but the .so is in my profile. Does anyone know how to make guix aware of the loader?

<jmes>Installation is via `guix package -i`

<minervasRefuge>It might relate to https://issues.guix.gnu.org/71109 which needs vulkan-loader in the environment.

<jmes>That looks like exactly the issue, thanks.

<minervasRefuge>so `LD_LIBRARY_PATH=$(guix build vulkan-loader)/lib vulkaninfo` will get it working.

<jmes>Yeah, that works a treat, thanks again minervasRefuge :)

<amano>What's the best way to run guix on a low-resource system without a powerful substitute-building machine?

<Isaz>the current commit de25a21 seems to give me a version of the guix command that segfaults when trying to reconfigure my system or run pull again

<Isaz>hopefully I'm not the only one? and good thing roll-backs exist

<apteryx>first guix pull on 1 core ovh vps took: 64m34s

<amano>apteryx: How do you prevent VPS from building guix packages?

<apteryx>I'll use 'guix deploy', which builds locally by default

<amano>So, you force your meager VPS to build qtwebkit?

<amano>or rust?

<apteryx>no, I build things I want to deploy on it on a local beefy machine, and send it over the network

<apteryx>(that's how it works by default)

<amano>apteryx: So, your build machine is a subtitute server for VPS?

<mange>I assume they're talking about "guix deploy". It's not a substitute server, but the machine running "guix deploy" builds everything needed to instantiate the system, then copies the results over to the target machine.

<amano>So, guix deploy spares target machines from compilation?

<amano>Does gnu guix simplify or complexify a computer system, compared to other operating systems?

<adanska>guix is now segfaulting... i think the libgit update has caused this

<adanska>segfaulting on a system reconfigure

<adanska>luckily could roll back

<amano>adanska: How stable is guix?

<AwesomeAdam54321>amano: GNU Guix generally simplifies a lot of things, but it's not the lowest resource package manager

<amano>Sure simple after going through steep learning curve. For normies, no.

<Isaz>thank you for confirming it's not my system adanska

<amano>For people who just want a GUI, gnu guix is a nightmare, and they should use windows or mac os.

<Rutherther>Also a user called nutcase was complaining about segfault like 10 hours ago. And its already in the issue tracker

<amano>Windows and mac os have managed to hide complexity behind GUI. Gnome and KDE have failed to do so.

<mange>amano: Or you could use a different distribution. Guix is exploring new ideas, so it's fairly niche at the moment. It's not trying to be all things to all people. If people want an "easier" experience, there are lots of other distributions to try.

<amano>I wish it was possible to hide guile scheme behind GUI and expose guile scheme only for people who want control.

<amano>So successful at hiding complexity behind GUI that it is as easy as mac os.

<amano>You want control? Pop open emacs, and write guile scheme. You don't want control? Just use GUI.

<amano>I haven't seen a seamless integration between GUI, CLI, and programming.

<Isaz>Thanks Rutherther, I had looked at bug guix but I don't see it there yet

<Rutherther> https://issues.guix.gnu.org/72859

<atw>I hit the segfault too

<mange>amano: The only thing preventing that is time and interest. Guix isn't just a CLI, it's a Guile Scheme library, so you can write a GUI in Guile which directly calls the same Guile interfaces that the CLI uses. Unfortunately nobody has done that yet.

<amano>mange: Hiding complexity behind GUI is a tremendous task. Gnome and KDE failed. Windows and mac os had money and people to do that.

<amano>But, the theory is that you can write a system-settings GUI application that writes a system config file. Users can write a custom config that modifies the GUI config or totally replaces it.

<mange>Did they succeed more than Gnome/KDE/anyone else? I'm not really sure they did. I think people are just more used to their particular expression of complexity.

<amano>Linux desktop environments haven't caught up with pipewire, yet.

<amano>I think they still use pulseaudio.

<amano>For gnu guix to actually reach mainstream, it will require proprietary wifi/graphics drivers in the official channel and come with a GUI system-settings application and a GUI installer.

<mange>Do we want to become mainstream?

<amano>I want something like a mixture of mac os and gnu guix.

<amano>I want my friends to be able to install gnu guix and not worry about guile scheme or text config.

<rekado>I think some of the above statements are too vague to be true or actionable.

<rekado>what's pipewire to do with anything?

<amano>proprietary drivers + GUI config + seamless integration between GUI config and text config + GUI installer = mainstream

<mange>I'm not convinced that being "mainstream" is what I want from Guix. I'd love the *ideas* of Guix to permeate the mainstream, but I'm also pretty happy with Guix staying more niche and experimental.

<amano>Mac OS users complained that linux distro developers should embrace GUI paradigm.

<amano>I agree.

<mange>It's also madness to think that being "mainstream" is just about technical competence. There are a lot of social dynamics that will "choose" what is mainstream, even against technical factors.

<amano>But, I also want text config.

<rekado>you might like https://mcclim.common-lisp.dev/

<amano>At least, the ideas mentioned above will enable gnu guix to go mainstream.

<mange>Again, I'm not convinced I *want* Guix to be mainstream.

<amano>I want linux desktop to go mainstream.

<mange>That's a completely different thing.

<rekado>ACTION agrees with mange

<amano>Functional package managers enable unattended upgrades.

<janneke>while i'm not opposed to people developing -- or even using! -- gui's, imho using a computer through a gui is a terrible mistake

<amano>GUI is for people who don't want to bother with details. Text interface is for people who want control.

<mange>Debian's "unattended upgrades" also enables unattended upgrades. I know, because I configured it on my dad's computer and whenever I go over to his house his computer is still up to date.

<amano>How does debian take care of upgrading /etc config files?

<mange>I don't know, I'm not a Debian developer. I will say, though: it works.

<amano>On arch linux and gentoo linux, you are forced to merge new /etc config files and old ones manually.

<amano>On nix and guix, you don't have to.

<mange>I will also say: Guix doesn't guarantee future compatibility for a config file. Unattended upgrades can start failing if/when the configuration format for something changes.

<amano>If all you do is enable services and install packages, unattended upgrades can work?

<amano>Perhaps, if service options change, unattended upgrade fails.

<mange>There are still ways that things can break. A simple example: recently Guix's Docker service was split so you have to add the containerd service separately to Docker. If you just had (service docker-service-type) in your config then your config broke with that commit, until you updated it to also have (service containerd-service-type).

<amano> https://wiki.debian.org/UnattendedUpgrades says the purpose of unattended-upgrades is to keep the computer current with the latest security (and other) updates automatically. That means it's not for debian version upgrades...

<amano>It's for security updates.

<mange>Sure, so on Debian Stable it will keep your machine up to date. That's the intention.

<amano>I wonder how mac os handles unattended upgrades.... Perhaps, they provide GUI migration.

<mange>Well, Mac OS doesn't manage your services for you, does it? Nor does Windows? So they just punt the issue to the service developers.

<amano>Perhaps, gnu guix channel can be versioned, and migration scripts can modify config through versions....

<amano>That may allow unattended GUI upgrades....

<rekado>there's no good reason Guix couldn't transform a system configuration automatically.

<rekado>if this sort of thing interests you, you are very welcome to play around with it and implement it.

<mange>It would work for simple cases, but it's not always possible to do so. Like, if a package was removed from Guix then there is no safe way to automatically fix that. My instinct is that you'll very quickly run into cases where the user's intent is ambiguous, and so you can't automatically transform the config.

<amano>it's only for migrating the GUI config which can be constrained.

<amano>By the way, can you keep carrying a removed package?

<amano>I thought gnu guix was built to do that?

<Rutherther>You can use any guix revision you want, so of course

<mange>Sure, but it won't get any upgrades. If we count "not upgrading" as "unattended upgrades" then this problem becomes very easy. :)

<amano>I guess unattended upgrade and seamless integration between GUI config and text config isn't meant to be solved in gnu guix. Perhaps, a future distro will do.

<mange>The issues here seem pretty fundamental. How do you handle packages that are no longer supported upstream? How do you infer intent from the current configuration when the service substantially changes?

<mange>I do wonder whether higher-level declarative configurations could get you closer (e.g. say "I want a webserver" rather than "I want nginx" or "I want apache"), but then you can only expose the common denominator of configuration, which is likely to be insufficient for many use cases.

<nutcase>Dear guix, after experiencing segfaults with "guix pull", I issued a "sudo guix system switch-generation 356". This failed with the following: https://paste.debian.net/1327821/

<nutcase>now I'm unable to use sudo (or doas). How can I fix that (without sudo, obviously)?

<amano>Apache can remain installed after being removed from the official channel....

<amano>No?

<mange>If your config file says "install apache", but apache is no longer in the upstream distribution then how does it know how to install it? Remember that in a functional distribution, the past state of the system should not be a consideration in the build of a new system.

<amano>As soon as you add manual text config, you give up unattended upgrade.

<mange>You would have to rewrite your config to reference an old apache version, but then it won't get upgrades, right? So then again we're back to "if not upgrading is a solution, this is easy".

<amano>The GUI can inform a user that services and packages need to be removed for upgrade....

<mange>That's not very unattended.

<amano>Better than nothing.

<mange>I feel like we might be talking past each other at this point.

<amano>GUI doesn't have to expose advanced options....

<nutcase>adanska: How did you perform the rollback?

<mange>As I said earlier: the only thing preventing a GUI for Guix is someone actually doing it. If someone builds it, it will exist. If nobody builds it, it won't.

<Rutherther>nutcase paste debian tells me the entry doesnt exist. About the sudo, have you tried just su or logging in as root from tty?

<amano>mange: I think gnu guix has to be forked into a new project if somebody wanted to turn gnu guix into a GUI-centric distro.

<amano>The new project will be incompatible with gnu guix.

<mange>Given Guix is *also* a library, couldn't it be built on top of it? Why must it be incompatible?

<amano>GUI-centric approach will alter the fabric of guix.

<mange>At any rate, anyone can fork it if they want. The Guix repo is self-contained and licensed to allow it.

<amano>Existing users will not like all the changes...

<mange>I would not expect a GUI-centric configuration mechanism to alter the fundamentals of how Guix builds and instantiates systems. I would expect it to just change the inputs.

<amano>And, a distro aiming for mainstream adoption must have proprietary drivers, and gnu guix maintainers won't allow that.

<mange>Sure. Again I wish to stress that I am not aiming for mainstream adoption of Guix.

<nutcase>Rutherther, thank you for checking, I solved it, by realizing that my root user did have a password set. I was able to solve it on /dev/tty2. I deleted the paste, to avoid that someone wastes time.

<nutcase>however, true. This may occur again. sudo (and doas) complained that setuid is not set

<amano>That's why it has to be a fork.

<amano>Personally, I don't intend to become a developer or a maintainer for any project. So, I'm not going to do that myself.

<mange>You'd better hope that someone else shares your vision, then. :)

<amano>That said, I think just blocking GUI upgrade if packages and services are removed is a sensible approach.

<adanska>nutcase: `guix pull --roll-back`

<Rutherther>nutcase setuid complains suggest the wrappers somehow got corrupted, or your path. Should hopefully be fixable by reboot

<amano>It turns out that there are guix-based distros that add GUI package installer and GUI installer to gnu guix.

<amano>They also have proprietary drivers and non-free softwares. They also come with subscription-based support. They are for normies.

<amano>People who want to move away from windows and mac os.

<nikolar>lol what distros are thoes

<amano>A distro designed for normies.

<amano>PantherX.

<amano>There may be more...

<jaft_r>(only tangentially related to the subject at hand but related to GUI package managers) Does anyone know how something like Gnome Software gets the images it displays for packages? I'd been wondering how you might do that for Guix when images for packages aren't provided but then realized that apt doesn't do that either (at least, I think; it's been a few years since I've used apt. Thanks, Guix!).

<mange>Immediately on their website they have a snippet of a text config file. System config page says it has a "really easy, command-line based installer". Are you sure there's a GUI package installer?

<nutcase>adanska: maybe one of the three yesterday's commits related to git are causing our issue?

<apteryx>GRUB spells file system 'filesystem'. Shocking.

<amano>mange: Perhaps, I was wrong.

<amano>mange: https://www.pantherx.org/software/ says PantherX comes with over 10,000 open source applications and plugins, most of which are available trough the Software application. Here you’ll find all your favorite apps, and discover new tools, to make your life easier.

<amano>It has software application.

<attila_lendvai>oh well: $ sudo guix system reconfigure x.scm -> Segmentation fault

<amano>Switching between desktop environments may require manual textual config, but there is GUI package installer for PantherX.

<wizard>jaft_r: i did some googling and it looks like they crowdsource it

<wizard> https://screenshots.debian.net/upload/gnome-software

<wizard>you can upload your own screenshots to the debian project and they'll manually approve them to be shown in app

<wizard> https://screenshots.debian.net/

<wizard>this is actually a really cool project in general wow

<wizard>how haven't i heard of this

<amano>I personally would use guix, but I would recommend PantherX to my friends who want to move away from windows or mac os.

<jaft_r>wizard: thanks! That's really, really helpful.

<wizard>oh actually i might be misunderstanding jaft_r, i'm actually still not sure where the screenshots in gnome-software are sourced from exactly

<jaft_r>Ah; that's fair. The hunt continues…

<mange>amano: Looks like the "Software" package is defined here, if you want to try it out: https://channels.pantherx.org/panther.git/tree/px/packages/package-management.scm

<amano>The installation is not actually as straightforward as windows, but after that is done, it can be as easy as mac os.

<amano>I think PantherX is a nice business idea for enterprise linux. The fact that it's based on guix allows pantherx to orchestrate thousands of computers easily.

<AwesomeAdam54321>GNU/Linux*

<nckx>So we've got 3 confirmed independent 'guix pull' segfaults now yeah?

<nckx>*Guix/Linux

<rhuijzer>4th here, sorry

<nckx>ACTION pulls.

<rhuijzer>zsh: segmentation fault guix pull

<nckx>Eh, just approved another one to bug-guix.

<rhuijzer>Master seems to have a fix (591972dfa14d401621cb060b6aac45989c342cd8) for this already, quick valgrind debugging seems to indeed point at the latest libgit update

<nckx>Oh, OK, great!

<nckx>Thanks.

<nckx>I assume affected users will have to roll back?

<nckx>I'm pulling to 21c6d42 to test.

<rhuijzer>I don't know. I'm building from git but that maybe a better idea

<nckx>ACTION meant guix pull --roll-back, to be clear.

<nckx>rhuijzer: Both should work.

<rhuijzer>This is offtopic offcourse, but how do you post these cursive lines nckx

<rhuijzer>"nckx meant guix pull --roll-back, to be clear." Like this one

<nckx>Just write /me does a thing.

<nckx>ACTION tends to over-use /me.

<Franciman>ACTION likes me

<rhuijzer>ACTION is gratefull for the information

<janneke>ACTION figures nckx could use /me even more often

<nckx>ACTION could.

<nckx>I'll prefix everything with '/me says' until you beg me to stop. I'll be my own shitty relay bot like all the cool channels seem to have.

<Kabouik>ACTION likes the idea of an whole IRC channel looking like a novel.

<amano>ACTION likes gnu guix derivatives.

<Franciman>ACTION in chorus with janneke asks nckx for more /me time

<Lumine>ACTION has coffee

<nckx>This is a very strange desire y'all know that.

<nckx>ACTION doesn't dance for likes.

<Lumine>ACTION wishes his middle name was Strange

<sepeth>Hi Guix, I am trying to install KDE, but libcamara fails during meson setup (configure phase): command "meson" "setup" ... failed with status 2. If I run guix build with -K (keep failed) and do the same command in the build dir manually, then meson setup succeeds. Anyone knows what might be going on?

<sepeth>FWIW, this is on aarch64 and I am running guix from guix git repo with ./pre-inst-env.

<sepeth>The only thing I modified was excluding kwin colorspaces test though, which was failing for me, that's why I am using the git repo.

<sepeth>Last few lines: https://paste.debian.net/1327829/

<sepeth>This part is dodgy: meson: error: unrecognized arguments: /tmp/guix-build-libcamera-0.3.1.drv-0/source

<rhuijzer>Did the rollback work nckx ?

<nckx>rhuijzer: It works in the sense that it doesn't segfault so users aren't stuck (or don't need to dig up random Guixen from their store), but the bug doesn't seem to be fixed on Guix master.

<nckx>I still end up with a segfault.

<rhuijzer>Hmm sucks, I haven't got the time for a deepdive (nor the needed commit rights for the fix)

<rhuijzer>Is there a bug filled yet?

<nckx>Yes.

<nckx>I saw it in the moderation queue, I don't know the #.

<rhuijzer>Can I see the modernation queue as a mere mortal?

<nckx>rhuijzer: Don't worry about rights. If you come up with a fix, send it to guix-patches@ or share it here; committers gonna commit.

<nckx>rhuijzer: No, but I mean that I approved it, so it should be up.

<rhuijzer>ah okey

<nckx> https://issues.guix.gnu.org/72859

<rhuijzer>Seems like a nice bug to dig into, i'm at work sadly

<nckx>Same!

<rhuijzer>I should subscribe to the mailing list, checking issues.guix.gnu is annoying

<pabs3>wizard: I think the screenshots in gnome-software come from the appdata XML files that ship with apps

<wizard>aha that woul dmake sense

<wizard>cc jaft_r

<wizard>who is offline darn

<nckx>sneek: later tell jaft_r https://logs.guix.gnu.org/guix/2024-08-29.log#110618

<sneek>Got it.

<nckx>sneek: botsnack

<sneek>:)

<civodul>Hello Guix!

<nckx>(The anchor will make more sense once your message scrolls to the top.)

<civodul>final hours for ‘core-updates’ if everything goes well!

<civodul>sneek: later tell jonsger icedove broke on ‘core-updates’: https://ci.guix.gnu.org/build/5510567/details

<sneek>Will do.

<nutcase>civodul: have you seen https://issues.guix.gnu.org/72859 ? (I'm sorry to welcome you with that bad news :-) )

<tschilp>Hi guix!

<nckx>o/

<tschilp>Does anyone have a tipp how to debug ~file or directory not found~ when trying to run a binary?

<Rutherther>It usually says the file in the message. If not try running with strace

<civodul>nutcase: ouch, i hadn’t seen it

<civodul>thanks for the heads-up!

<civodul>weird because CI didn’t have any problems: https://ci.guix.gnu.org/eval/1585802

<tschilp> Rutherther: thanks, strace is very silent unfortunately... http://paste.debian.net/1327833

<yelninei>tschilp: i think it cant find linux-vdso.so.1

<tschilp>yelninei: thanks, ldd has to show all of them like '=>', do I get this right?

<nckx>No, the vdso is special, that line's fine,

<yelninei>not an expert, but missing so files were the issue for me when i had a similar error

<yelninei>for a different application

<tschilp>mhm, I just read up about vdso the first time as well. I however can't get my head around why some of the binaries I compiled via docker seem to work, and others yield this result.

<Rutherther>tschilp I rhink you will need to patch the rpath's /lib64/ld-linux-x86-64.so.2 to full path

<Rutherther>No such file or directory directly on file you are executing usually means it cannot even start executing the file. That happens if dynamic linker path is wrong

<Rutherther>To check this run the file with specifying full path to the linker, and giving it the file as argument

<tschilp>Rutherther: cool, I will read up on this and try!

<Rutherther>If this proves to be the case, you can use patchelf. Keep in mind if you do this without making it a guix derivation, the linker can disappear on garbage collection when there is no longer gc root for it from other place

<nckx>On Guix System you can also symlink a linker from the glibc package into /lib using the extra-special-file service.

<nckx>A hack, but these are all hacks.

<nckx>Or an FHS guix container, which is probably the cleanest option if your binary can work inside one.

<h4>test

<sepeth>nckx: wow, thanks. I didn't know extra-special-file.

<h4>In Guix email groups lot of work seems to have be done on VNStat (service, standalone...), but on Savannah I only see a push about base program. Is it still on an experimental branch, or not pushed at all, or I don't use right Savannah? Because I want to activate VNStat herd service

<tschilp>nckx: fhs-container seems to get around this kubelet binary, but the other one needs sudo...

<nutcase>civodul: If you or CI can't reproduce the issue, please let me know, how I ("Julian" in the issue) can help to narrow down the issue / test things.

<nckx>sepeth: It extends the same service we use for the /bin/sh and /usr/bin/env compatibility links. In theory one could use it to populate an entire /lib worth of libraries, but people will look at you funny.

<nckx>nutcase, civodul: Oh it's reproducible. People are reproducing it everywhere. I wish they would stop.

<Rutherther>nckx I would look at them angry, sad, and disappointed. Or does that count as funny? :D

<rekado>I can confirm that we need something like #72838 for i686 (core-updates)

<rekado>oops, it's already been applied

<nckx>Rutherther: Like you're extra special, all right. I was thinking more 'loving, but concerned'.

<dani`>Hello everyone! I'm getting "segmentation fault" when I run guix pull and guix system reconfigure with guix --version 09fe58e08cb1ff9be93752b018c5dd55c8ef9498. Yesterday everything worked fine. I found a few errors in my /var/log/messages like this: "localhost vmunix: [ 5089.791454] guix[15087]: segfault at 7ffc0fa94090 ip 00007ffc0fa94090 sp 00007ffc0fa93f88 error 15 likely on CPU 2 (core 1, socket 0)". My config:

<dani`> https://paste.debian.net/hidden/e6a14325/.

<h4>dani`: Same

<h4>I guessed that's because I haven't restarted, but maybe not

<dani`>h4: after restarting I still get the segfault.

<rekado>dani`: sounds like this: https://issues.guix.gnu.org/72859

<h4>Often I prefer the problem to be common than individual, because I'm really unable to resolve problems by myself and I'm glad to wait for an update to simply download and install

<dani`>rekado: Thanks for the info!

<h4>I'm glad seeing a*\nbeing*\nrather than*

<Rutherther>h4 you will still probably need to revert in order to be able to receive the proper fix

<h4>Rutherther: Really? So someone literally broke all installed Guix worldwide that updated between that commit and the revert? Happened to me on Arch installation too few years back. I was reluctant to do anything for weeks, because no time. But it needed manual intervention like here

<h4>Maybe you should put the needed command to repair the system in the commit message or the revert commit. And in the news when guix pull

<h4>And maybe in homepage of guix.gnu.org, and any other place relevant. Because it's literally a breaking update

<civodul>the dreaded segfault bug is fixed: https://issues.guix.gnu.org/72859

<nutcase>civodul: \o/ Thank you!

<nckx>Heh, I recognise that nick from the Mastodons.

<nckx>itorres: The bug is fixed!

<itorres>nckx: good to know! BTW, awesome mastodon server you're in. :)

<rekado>libcamera fails to build on aarch64

<rekado>there's an obvious fix to the configure flags, but even with that fix I see two test failures.

<rekado>for those curious about the test failures: https://elephly.net/paste/1724935881.html

<civodul>rekado: yesterday i applied https://issues.guix.gnu.org/69178

<civodul>(re libcamera/aarch64)

<civodul>just created https://ci.guix.gnu.org/jobset/tests-core-updates

<tobtoht_>Searching in https://logs.guix.gnu.org/guix appears to only return results from Jan 2023 or older

<esnos>Hi, how can I install base gnome without all addidional apps and is it possible to install newer version of gnome then 44?

<apteryx>is 'guix system init /' on a live debian system a thing to turn it into Guix System?

<apteryx>err, 'guix system init /my-config.scm /'

<rekado>civodul: hmm, I just updated to the latest version of core-updates a few minutes ago.

<rekado>I'll check again

<rekado>I need this to get past the configure phase: https://elephly.net/paste/1724937962.diff.html

<Rutherther>apteryx I would be afraid that there will be some conflicts between files and that it wont be that easy

<civodul>rekado: oh, that makes sense; the empty string must be causing problems

<rekado>but even with these changes I've got two test failures, so more is needed

<apteryx>Rutherther: I guess I'll have to try :-)

<apteryx>I expect conflicting files e.g. under /etc to be overwritten/shadowed

<xelxebar>Eek. guix pull segfaulting on me now :/

<Rutherther>See channel description. Roll back and pull again

<xelxebar>Rutherther: Ah. It's right there. Cheers. Fortunately, my /run/current-system profile has a working guix, so I was able to re-pull with that.

<Rutherther>Or that, yeah. There should also be a few guix generations in ~/.config/guix

<rynn>Has anyone here used the hydroxide Protonmail bridge? It looks like it doesn't allow for encrypted emails, but all other functionality should be there?

<podiki>rynn: i use the peroxide bridge (i need to contribute it as i have it on my own messy channel)

<podiki>i'm not sure what you mean by doesn't allow for encrypted emails, as far as i know it is just like using protonmail in a browser, just locally

<aswjrisp>I am using Guix system. I have installed zathura a pdf reader. I also installed zathura-pdf-mupdf. When I run `zathura file.pdf` I get two error messages one says "could not open plugin directory" and the other says "Found no plugins".

<aswjrisp>I installed zathura-pdf-poppler, but I still get the same error messages.

<Franciman>hi, aswjrisp. Did you install them via guix install / guix home?

<Franciman>or what?

<aswjrisp>Franciman: guix system reconfigure /etc/config.scm

<Franciman>can we see your config?

<podiki>and did you restart/relogin? might be needed if there is a search path being set

<sepeth>Hey Guix, making some progress on my KDE journey. Now, during check, a single test fails for plasma-workspace. I suspect guix-daemon doesn't set any locale or something. Because there's a locale related warning just before the failure

<sepeth>QWARN : CalculatorRunnerTest::initTestCase() kf.i18n: KLocalizedString: Domain is not set for this string, translation will not work. Please see https://api.kde.org/frameworks/ki18n/html/prg_guide.html msgid: "search term" msgid_plural: "" msgctxt: ""

<sepeth>And, this is the test that fails:

<sepeth>FAIL! : CalculatorRunnerTest::testQuery(superscripted number) Compared values are not the same

<sepeth> Actual (matches.first().text()): "2'\uFFFD''\uFFFD'"

<sepeth> Expected (result) : "8"

<sepeth> Loc: [/tmp/guix-build-plasma-workspace-6.1.4.drv-0/plasma-workspace-6.1.4/runners/calculator/autotests/calculatorrunnertest.cpp(40)]

<sepeth>toLocal8Bit is called here: https://invent.kde.org/plasma/plasma-workspace/-/commit/6a1bab19af2af22a31fadfd707a5085c4bab11a9

<sepeth>My question is, is there a way to set this for guix-daemon?

<sepeth>Oh, I certainly have (operating-system (locale "en_US.utf8") ...)

<aswjrisp>Franciman: config as requested https://termbin.com/z1gy

<aswjrisp>This is the output I get when I run `zathura file.pdf` https://termbin.com/v5zq

<attila_lendvai>if i try to `sudo guix system reconfigure`, i get a segfault. if i `sudo -s`, and then `guix system reconfigure`, then i get "Git error: unexpected http status code: 502". does this ring any bells?

<attila_lendvai>it's from the guix channel, git.savannah.gnu.org (from the backtrace)

<attila_lendvai>check-forward-update is on the stack

<attila_lendvai>update-cached-checkout, too

<rynn>Thanks podiki, I'll check peroxide out

<attila_lendvai>and as usual, the backtrace is useless, it cuts off the url...

<podiki>rynn: it is a mess, but the code is here: https://gitlab.com/podiki/guix-pod and i use peroxide service every day for months. just need to clean this up and submit it here

<attila_lendvai>$ guix pull -> Updating [...] 'https://git.savannah.gnu.org/git/guix.git'... -> Segmentation fault

<attila_lendvai>according to strace, it stops for a while at a recvfrom(16, before it segfaults

<rynn>Thanks again. I was originally going to install the flatpaks for some of the stuff, but later decided I was going to try to avoid the flatpak route and go pure guix channels if possible.

<attila_lendvai>hrm... does guix pull work for others? is this only me?

<ieure>Seems like segfault on pull is happening to several people?

<ieure>Someone was in here yesterday saying that was happening, and I saw a post on the ML this morning.

<rynn>I've seen a few people encountering that issue, yeah

<attila_lendvai>oh, thanks ieure!

<attila_lendvai>a recvfrom hangs for a few seconds, returns with 5, then another recvfrom returns quick with 11427, and then segfault

<attila_lendvai>scratch that, the timing is not relevant. it dies quick now.

<ram_man>I ran the guix install script on Gentoo with openrc and it said "rc-update: service `guix-daemon' is not executable". Does anyone have any advice?

<attila_lendvai>ACTION goes to do something else, and hopes the opensource fairies will deal with the issue meanwhile

<Franciman>aswjrisp: just out of curiosity: what if you remove the packages from global config? and install them with guix install?

<Rutherther>attila_lendvai it's already been solved. roll back, or use different guix, and pull with that.

<ieure>`guix pull' on my Debian box seems to work fine. It's been a while since I've pulled on it.

<Rutherther>the affected guix versions are starting from yesterday till today, few hours ago. So if you didn't pull guix at that time, you are fine. If you did, you would be experiencing the same problem.

<whereiseveryone> https://octodon.social/@fabionatali/113024020737282584

<aswjrisp>Franciman: I just ran `guix install zathura` and `guix install zathura-pdf-mupdf`. When I run `zathura file.pdf` I get the same error messages.

<Franciman>strange

<Franciman>for me it works

<Franciman>i think the problem is that zathura is not reading the correct directory. Have you tried the previous suggestion here to restart the system?

<Rutherther>aswjrisp after the installation, did you source your profile?

<Rutherther>or to be more specific, do you have ZATHURA_PLUGINS_PATH set to folder with plugins?

<aswjrisp>Franciman: okay I will restart the system.

<Rutherther>will resolve the issue, but it suffices to source the profile / relog

<aswjrisp>Rutherther: after doing `source .bash_profile` running `env | grep ZATHURA` outputs nothing. Did you mean to source .guix-profile?

<Rutherther>yes, the guix profile, that's where it's installed to...

<Rutherther>if you are on Guix System then it would also work to source /etc/profile, since that sources the guix profile as well

<aswjrisp>I just ran `file .guix-profile` and it says it is a broken symbolic link to /var/guix/profiles/per-user/z/guix-profile

<Rutherther>~/.guix-profile? and what does "which zathura" tell you? (or whereis)

<aswjrisp>`source .guix-profile` says "No such file or directory"

<Rutherther>it would be source "~/.guix-profile/etc/profile". The profile itself is a folder containing a lot of files, you cannot source a folder

<aswjrisp>`which zathura` outputs /run/current-system/profile/bin/zathura

<Rutherther>okay, so you are not actually using the zathura you installed with guix install

<aswjrisp>It did not work so I ran guix remove and ran a system reconfigure again.

<Rutherther>so what is the content of "/var/guix/profiles/per-user/z"?

<Rutherther>oh... so you removed your profile in the meantime

<aswjrisp>I can not source ~/.guix-profile/etc/profile

<Rutherther>of course it didn't work, because for it to work you need to source the profile to get the correct search path

<aswjrisp>Okay

<aswjrisp>But /etc/profile should work?

<Rutherther>if you've removed all your packages from profile, then the profile doesn't exist anymore, so it's not surprising you cannot source it

<aswjrisp>I ran `source /etc/profile` and now `env | grep ZATHURA` is showing the environment variable.

<Rutherther>great, so zathura should show you pdfs now

<Rutherther>if you wanted to have it for your whole environment you would have to at least relog. Right now you will have it only where you sourced /etc/profile manually

<aswjrisp>It is now working. I can now open the pdf with zathura.

<Rutherther>for the next time, you can try packages from guix shell rather than guix install to prevent issues with sourcing the profile like this

<Rutherther>"guix shell zathura zathura-pdf-mupdf" would give you the env var right away

<aswjrisp>Rutherther: relog means to log in again?

<Rutherther>yeah. Because only then the /etc/profile is sourced for your whole session

<Franciman>does somebody still use profiles?

<Franciman>i mostly use guix home

<aswjrisp>I still need to read about guix sheel.

<Franciman>well profiles allow many parallel configs, that's true

<Franciman>what else do thei help with?

<Rutherther>everything in guix is based on profiles, guix home, guix system, guix shell

<Franciman>ah no ofc, i mean use them directly, Rutherther

<Franciman>guix home is a profile :)

<aswjrisp>Rutherther: Franciman: thank you for your help.

<aswjrisp>Rutherther: So is it just good practice to log in again after doing a system reconfigure?

<jaft_r>aswjrisp: not necessarily; in your particular case, the issue stemmed from two packages which needed an environment variable to know how to work with each other. If you install – say – Chromium, Chromium won't need anything like that and will likely work just fine, right after. Similar if you haven't added any new packages and are just updating the current ones. I usually don't restart after doing a system reconfigure, most of the time.

<sneek>Welcome back jaft_r, you have 1 message!

<sneek>jaft_r, nckx says: https://logs.guix.gnu.org/guix/2024-08-29.log#110618

<jaft_r>Thanks, pabs3; I'd, actually, stumbled on a forum post that said something similar but couldn't find the file (granted, cursorily looking) on another popular package's source code so I wasn't sure.

<aswjrisp>jaft_r: thanks

<robin>hmm anyone familiar with maturin as used to build python packages?

<robin>ACTION looks at the project's source code

<rhuijzer>Hi. How can I build all packages that depend on package X as an input ? So really test a update of a package that some other package depend on

<rekado>robin: python-clarabel uses maturin (awkwardly); python-gseapy avoids it; and python-cramjam uses it as intended.

<robin>great, i'll look at their packages

<robin>(this is for python-ruff which is a dependency of newer versions of gajim)

<Rutherther>rhuijzer I think guix graph with type referrers can give you packages that depend on X, so you could then feed this to guix build

<rhuijzer>Rutherther that seems to be what i'm looking for. Thanks

<csepp>heads up: https://issues.guix.gnu.org/72859#5 is giving 502

<csepp>it loads for a long time and then gives a bad gateway error, i guess the backend is overloaded or something? or just buggy?

<Rutherther>why does package made from make-gcc-arm-none-eabi-7-2018-q2-update contain native search paths? I would expect cross compilation chains to use only search-paths, the non native ones. This is what the base xgcc does. Why is gcc arm none eabi adding native ones?

<attila_lendvai>Rutherther, thanks for the info! looking at the fix, it's one of those bugs that wouldn't exist if people stopped writing http parsers in C...

<rekado>robin: isn't ruff just a linter or something like that? I think I have had a number of opportunities to avoid packaging it :)

<robin>rekado, huh, idk, if so i can probably patch it out of gajim :)

<amano>How do people make do with only 8GB RAM on guix? Guix may try to build qtwebkit, firefox, or rust.

<Franciman>amano: works perfect fine for me

<Franciman>hi robin \o

<amano>Franciman: How do you maximize substitute availability? Do you just build large packages with 8GB RAM?

<Franciman>i let guix deal with it

<Franciman>and i have to compile stuff only like 0.1% of the time

<robin>hi Franciman

<Franciman>and because of some issue on the substitutes server

<amano>Franciman: That 0.1% can get you if guix compiles qtwebkit.

<Franciman>i once compiled firefox