IRC channel logs

<orahcio>anemofilia: I could tbookmarked your repository, I will study better tomorrow, thank you very much

<vagrantc>hrm. something is pulling in rust on my aarch64 system configuration ... i was able to build with guix pull at cd26d76fedb7ab13ad91bd5dcfce119892b8e62e but at least as of f129a6cc591817c5c51770d5b8712eeb344ba4e4 it seems to start failing.

<vagrantc>i had (bootloader (bootloader-configuration (theme (grub-theme (image #f))) ... to avoid pulling in librsvg ... but presumably something else is getting all rusty now...

<vagrantc>guessing the changes with meson might have triggered it...

<wolfdog>did the cgit service get removed from the tree at some point? the documentation makes mention of it on version control services but it's nowhere to be seen in the code

<lilyp>hey folks, if someone wants to help out gnome-team a bit, please figure out how to make u-boot-tools build – that's really outside of our scope but somehow required to run `guix system vm'

<lilyp>bonus points if you do genimage too

<PuercoPop>Can a home-service define a user or only 'system' services can handle user management?

<meaty>How do I install "Java" on guix? as in, the JVM, I guess. I'm trying to play minecraft

<meaty>there seems to be a lot of libraries and tools packaged for it but not "java" itself

<COMPL_EXE>meaty: search for openjdk

<nigko>wolfdog: cgit-service-type is in the tree: 'guix system edit cgit'

<COMPL_EXE>Is it possible to edit a home service? I tried to run `guix home edit home-dotfiles` but it shows that the file is readonly.

<hako>You can run './pre-inst-env guix home edit' with in a git checkout.

<rekado>ci.guix.gnu.org seems pretty idle again, even though there are more than a thousand pending builds from r-team alone.

<lilyp>PuercoPop: A home-service is bound to the user it executes under

<ray1729>Hi, I'm struggling a bit with a Guix system I just installed and wondering if someone here can help. The on-first-login script is failing because XDG_RUNTIME_DIR=/run/user/1000 and this directory does not exist. So I'm wondering what I missed? Can I override this environment variable, or should the login process be creating that directory?

<rekado>ray1729: do you use a desktop environment?

<ray1729>no, this is a headless system that I'll access via SSH

<ray1729>If I run `sudo install -d -o ray -g users -m 0700 /run/user/1000` then the script works and starts shepherd, but that directory does not persist across reboots.

<Rutherther>ray1729: it shouldn't persist. This folder is created either by elogind on first session, or sometimes by a display/login manager for desktop gui sessions. If you don't want to use elogind, you need to ensure yourself it's created prior to the on-first-login script somehow

<ray1729>Rutherther: yeah, I've been looking at how the bash init scripts work, maybe I should remove (guix-defaults? #t) from my home configuration so I can override XDG_RUNTIME_DIR before it sources .profile. Either that, or install elogind.

<Rutherther>ray1729: why do you want to override it rather than create it?

<ray1729>Rutherther: it needs root permissions to create it. It feels like it should be created by the PAM stack.

<anemofilia>ray1729: You can also use greetd to create that directories (that's what I do, since I usa seatd instead of elogind)

<Rutherther>anemofilia: no they can't on a headless server

<anemofilia>Ah, I missed that part, sorry

<Rutherther>ray1729: hm, you are right, /run/user is owned by root and there is no write permission flag for others. I am not sure if this is correct, will have to compare against other distros later. So yeah, I suppose overriding it and creating will be easiest solution, not requiring installation of a "bloat" software

<ray1729>Rutherther: I have configured the elogind service, I don't mind a little bit of bloat if it makes life easier :-)

<x8dcc>Hello, can someone explain to me what this error means, exactly? https://bpa.st/HBEA

<noe>The mpv package adds a version of poppler to your profile, and you are installing another one (its dependencies have changed), try running guix package -u to update mpv with the new poppler so it can be the same version

<x8dcc>I thought Guix was able to use both versions at the same time. I mean, that I could upgrade a package and the old dependencies remained unchanged (since mpv just depends on another store directory or something)

<x8dcc>It's not a problem in this case, but I still want to understand

<Rutherther>x8dcc: of course guix can, but if you install them, you are trying to merge them to the same profile. You can't have two files at one place

<x8dcc>Hm... So I currently have installed poppler in my profile? I mean, even though it was installed as a dependency for mpv, and I didn't install it manually

<x8dcc>Let me explain my actual situation a bit more. I ask because `pkg-config' can't find "poppler", so I thought about installing it with the command I sent

<x8dcc>What I don't really understand, is why installing poppler needs to upgrade the old version that mpv depends on (if that makes sense)

<Rutherther>x8dcc: pkg-config where?

<Rutherther>in a shell? in guix package environment? outside of it just with what you have installed?

<Rutherther>s/guix package environment/guix build package environment

<x8dcc>I am manually compiling a program that depends on poppler. So running, for example, "pkg-config --libs poppler" says that poppler is not found

<Rutherther>x8dcc: did you read the error? the conflicting package is not poppler, it is glib

<Rutherther>so no, you don't have poppler in your profile

<x8dcc>Yeah, I read the error but I don't really understand it

<Rutherther>x8dcc: profile contains conflicting entries for glib - so what's not clear about this?

<x8dcc>I don't understand how they are conflicting if both versions are 2.78.0

<x8dcc>And I just thought it was related to poppler (rather than glib) because of what noe said

<Rutherther>x8dcc: because guix is a functional package manager. That the version is the same doesn't matter, the path is different. That means it's actually a different package. For example it can have different dependencies, if that's so, just updating your profile and then installing poppler could work

<Rutherther>x8dcc: noe is not right, the conflict is in glib, not poppler. It's just that this conflicting glib is propagated from poppler

<x8dcc>Okay, since the two paths are different, it's considered a different package. Then what's the conflict? To my understanding, if two package have glib as dependencies, both versions can coexist in different store paths

<Rutherther>x8dcc: yes they can. propagated package is installed to the profile. So now you are trying to put two different packages (both named glib), with same files, to one profile, meaning you get a conflict, since you can't have two files at one place

<x8dcc>Right, I am beginning to understand a bit better. So the problem (more or less) is that it would overwrite some files in '~/.guix-profile/...'?

<Rutherther>x8dcc: right, though at first its build to the store and only then it would be linked to ~/.guix-profile

<x8dcc>Okay, then my next question is: Why is 'glib' being installed in my guix profile? I mean, if it's a dependency for poppler, why can't just 'poppler' use the store path for the library, and 'mpv' use the other path?

<x8dcc>I mean, since I am not installing 'glib' with 'guix install glib'

<x8dcc>I think I am just not understanding something about profiles, or something

<Rutherther>x8dcc: sometimes it's easier to just propagate it and not care anymore. Of course with some tweaking it could be made not propagated, but it would probably mean more wrapping, and still might be problematic in case of glib/dbus specifically

<x8dcc>By "propagate it", you mean installing it on the current guix profile?

<Rutherther>x8dcc: no, I really mean propagate it from inputs - to put it to propagated-inputs of the package. That it's installed to the profile is just the consequence of it being propagated

<x8dcc>Ah. I read about 'propagated-inputs' recently, but I didn't remember what they did

<x8dcc>I understand better now. Thank you, Rutherther

<x8dcc>About my error, I think 'guix install poppler mpv xorg-server' seems to work (had to add 'xorg-server' because of 'libdrm')

<Rutherther>x8dcc: after you do guix pull, do you also usually upgrade your profile? (guix package -u)

<x8dcc>I have never used 'guix package -u', since I have been using Guix for about a week :^)

<x8dcc>The few times I have used 'guix pull' (normally after I updated my channel) I run 'guix home reconfigure ~/.config/guix/home.scm'

<Rutherther>x8dcc: okay, then your ~/.guix-profile is not updating, and that means you will be encountering issues like this, when propagated inputs update, as some packages in your profile will still be using the old version

<x8dcc>I understand now that I remembered what propagated inputs are

<x8dcc>Thanks again :)

<mccd>How do I actually view the log files?

<mccd>when a build fails?

<mccd>ah

<mccd>just open the file in emacs and it works haha

<mccd>Building mairix seems to fail for me, anyone here building it without issues?

<apteryx>building python-biopython appears to be a good test to smoke test the python-team branch

<apteryx>I've been working my way through it, amassed some 50 commits

<apteryx>yay, it finally built

<civodul>hey!

<civodul>anyone here would like to try ‘make dist’ from the v1.0.0rc1 tag of Shepherd?

<civodul>i’m trying to figure out the reproducibility problems but it Works for Me so far

<civodul>as reported here: https://lists.gnu.org/archive/html/guix-devel/2024-11/msg00132.html

<civodul>oh, “DIST_DEPENDS_ON_UPDATE_PO = no” looks promising

<janneke>civodul: indeed, when doing `make dist' creates new po files

<janneke>but anyway.. guix hash shepherd-1.0.0rc1.tar.gz => 1ba0ykz5mxng8ymzh1k3bmw2s9f6c7mqvjq3wiz3dadi4lxjvpg6

<civodul>janneke: yes, thanks!

<civodul>i think “DIST_DEPENDS_ON_UPDATE_PO = no” will sidestep the problem entirely

<janneke>yay for sidestepping problems

<janneke>although not creating problems in the first place would also be nice :-/

<civodul>yes, though i’m not sure what this update-po step buys us anyway

<janneke>stupid question: should the commit before a tag run po-update and commit that?

<ieure>issues.guix.gnu.org having, uh, issues? https://qa.guix.gnu.org/issue/74628

<ieure>Or is this normal to see before it's processed my patches?

<ieure>Spent a half hour yesterday hacking up some Emacs code to automagically scrape CVEs from Firefox release notes and format them to drop into these patches, pretty happy about how that turned out.

<lilyp>QA takes time to ingest issues

<noe>ieure: that does look pretty good, is there always this many CVEs?

<ieure>noe, Yes.

<ieure>Such is the nature of web browsers in the modern era.

<noe>I’m still on icecat 115 😬, I should probably move to librewolf

<ieure>I like LW a lot. It's what I wish Firefox was.

<civodul>i use both IceCat and LibreWolf these days, depending on what i’m doing

<civodul>which is kinda ridiculous but hey, habits!

<ekaitz>civodul: when which one? i'm also in icecat most of the time and then switch to firefox sometimes

<david95>Hello everyone. Please recommend VPS on which to install Guix. Thanks in advance for your recommendations.

<civodul>ekaitz: actually i’ve set up IceCat to use Privoxy as its proxy, which goes through Tor

<civodul>plus i have Searx and things like that enabled in IceCat

<civodul>so some web sites aren’t reachable with this

<civodul>and that’s when i resort to LibreWolf

<civodul>that and running wasm demo from the Hoot folks :-)

<civodul>*demos

<marmalade>so i think one of the reasons ive been running into bizzare bugs is because i was setting my guix stuff up in .zshenv and not .zshrc and .zshenv is sourced by login shells as well.

<marmalade>(i think)

<marmalade>at the very least .zshrc is specific to interactive shells

<lilyp>your guix stuff should go to zprofile most likely

<Rutherther>marmalade: if by setting up guix stuff you mean getting env vars, then .zprofile/.zshenv is the correct place, .zshrc is the wrong one. Your rc file should not modify variables, it's against posix and it's going to make --pure shell not work

<Rutherther>(oh, .zshenv is sourced every time, not just for login shells, so no, it shouldn't go there, only .zprofile)

<marmalade>oh, well that makes sense too

<ekaitz>civodul: oh i see, you go a step further than i do, but cool

<civodul>ekaitz: with shepherd you mean?

<ekaitz>civodul: icecat/librewolf and all that

<civodul>ah!

<civodul>yes

<civodul>ACTION just pushed shepherd 1.0.0rc2, go test it comrades :-)

<Deltafire>hmm.. the manual on the website is out of date - does it not follow the master branch?

<Rutherther>Deltafire: the devel manual does

<Deltafire>i just spotted that.. why have the v1.4 manual there which is now giving misleading information for certain topics>

<Deltafire>just creating extra frustration for users, especially since it usually pops up in search engine results

<ekaitz>Deltafire: I agree, but also if you are installing the v1.4 for the first time you want to find that manual instead

<ekaitz>i think the difference should be more obvious or we should guide the users better to the version they actually need

<ekaitz>s/users/PEOPLE/

<Deltafire>if someone did configure v1.4, as soon as they pull/reconfigure their config could break

<rekado>the manual is included with every installation of Guix

<Deltafire>more obvious would be good, maybe put v1.4 in the url

<rekado>Deltafire: I agree, this would help

<Deltafire>i know, but sometimes the website is more convenient than using info

<csantosb>/manual/devel/en/ and /manual/en/ is something i just discover 😯

<ekaitz>csantosb: it took me almost 5 years to realize

<ekaitz>you are not alone

<csantosb>Problem is we are used now to the read the docs format, with its versions to the bottom left, i'm afraid

<csantosb>Deltafire: absolutely, 1.4 would make things clear for beginners

IRC channel logs

2024-11-30.log