IRC channel logs

<civodul>podiki: i don’t think so; the message we see here comes from sudo (in Guix there are no “setuid wrappers”, unlike on NixOS)

<oriansj>well there is the setuid-programs bit

<oriansj>which you can add: (file-append sudo "/bin/sudo") in the map file-like->setuid-program block

<oriansj>just a thought but imagine a package is in the default guix package repo and a different package with an identical name exists in a channel; how would a user specify which one to use?

<jaeme>oriansj: guix would pick on your behalf the more latest version if you don't specify explicitly a version with '@'

<jaeme>What are the benefits of using guix for emacs packages over something like Elpaca or straight.el?

<jaeme>I know that elpaca can't use prebuilt substitutes like Guix can, but elpaca also has access to virtually any emacs package.

<jaeme>Elpaca is also portable in the sense that it can be replicated on any Emacs >= 27.1

<jaeme>I've been testing out guix for emacs after my latest dot emacs d bankruptcy but I'm not just feeling it.

<lilyp>haven't heard about elpaca, but does it do extensions and other stuff that requires compiling C code?

<efraim>hello guix!

<sneek>Welcome back efraim, you have 2 messages!

<sneek>efraim, podiki says: saw your recent cross compile commits, so I take it we can close https://issues.guix.gnu.org/66424

<sneek>efraim, podiki says: and note in discussion there what was changed on core-updates, maybe you'd want to push the same changes there to avoid a merge conflict or it getting lost?

<efraim>sneek: botsnack

<sneek>:)

<efraim>podiki: thanks for the heads-up, I've cherrypicked the commits to core-updates and now seeing if I can clean them up a bit

<civodul>Hello Guix!

<Lumine>o/

<efraim>o/

<cbaines>morning o/

<kitty1>yo

<kitty1>hows yall goin ? :3

<sneek>Yey! podiki is back!!

<mothacehe>civodul: Hey, 100% coverage on the "images" specification. It looks like your fix works! That's great :)

<sneek>mothacehe, you have 1 message!

<sneek>mothacehe, civodul says: commit 373ec2cf8ce97d5f89191c3d9211ee3a5c2067dc lacks the actual pack.scm change no?

<yaslam>Hi everyone, I am trying to replace the GDM display manager with LightDM in my system config file, but I get this error: lightdm-service-type: unbound variable . This is the full file: http://ix.io/4J7V . Thanks

<efraim>libstdc++-boot0 is broken on core-updates, for at least x86_64-linux

<Jevra>Does guix use system libraries? Like say you patched GTK3 and a GTK3 package was available for guix, would it be like flatpak where guix uses its own GTK3 instead of the patched system one?

<cbaines>generally Guix packages use things that they're built to use Jevra

<Jevra>What do you mean by that because it doesn't answer my question.

<cbaines>I don't really understand your question

<Jevra>Let me try asking like this, is guix like flatpak where each app is isolated and expected to bundle its dependencies together. So if package foo was a GTK3 program, would it only be able to use its own internal bundled GTK3 or can you allow guix to use the system installed GTK3?

<cbaines>Guix doesn't bundle dependencies together

<cbaines>rather packages use the things they're built to use, so some package using GTK3 would reference that in the store

<cbaines>I use the sonata app for example, which uses GTK3

<cbaines>currently the sonata package builds as /gnu/store/1vlrgs3f14i77lizs30ka43nqia1mr3d-sonata-1.7.0 for the particular revision of Guix I'm on

<cbaines>and the following command shows all the dependencies (references): guix size /gnu/store/1vlrgs3f14i77lizs30ka43nqia1mr3d-sonata-1.7.0

<cbaines>including /gnu/store/ivqwlszdaf8xn8qkc7p2lz7p6pl95l1g-gtk+-3.24.37

<cbaines>going back to my original point, this is the gtk that sonata is built with

<cbaines>(ignoring grafts)

<Jevra>Can I patch the gtk3 build to use patches I want?

<cbaines>of course, and there are a number of different approaches to do this

<cbaines>a simple one is to use the --with-patch= package transformation

<cbaines>so you'd do something like: guix build sonata --with-patch=gtk+=...

<kitty1>Is there a way to look at previous guix pull --news --details? I was doing some troubledshooting and hadn't guix pulled in a good while and forgor to look at the news on the first one lmao

<civodul>kitty1: “guix pull -l” does that (but it’s a bit slow)

<kitty1>oh wow thanks civodul!

<cbaines>yaslam, do you know what module exports lightdm-service-type, and if you're importing it?

<yaslam>cbaines, I think it's the xorg module which is here: https://guix.gnu.org/manual/en/html_node/X-Window.html but I thought I already imported it.

<cbaines>yaslam, looks like the xorg module exports slim and gdm, but not lightdm https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/xorg.scm#n71

<cbaines>that seems to have it's own module https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/lightdm.scm

<yaslam>cbaines, thank you, it has found it after importing the LightDM module.

<indigo-oce>I'm running into errors with many gtk programs (libreoffice, pavucontrol) and they're crashing on startup.

<indigo-oce>trying to update everything with to see if it fixes stuff...

<indigo-oce>nope, still breaks... I'll try a newer guix commit and see then.

<efraim>I don't think qa.guix.gnu.org sees my request-to-merge email

<efraim>or I sent it wrong

<cbaines>QA is rather particular about the title format efraim, which is given in the docs https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html

<cbaines>it also says the bug should be for guix-patches rather than guix, but that doesn't make a difference currently

<cbaines>indigo-oce, could this be something in the environment rather than a Guix bug? You can check if something like this works for example: guix shell --pure pavucontrol -- pavucontrol

<indigo-oce>cbaines just tried that, looks like pavucontrol is working now... but libreoffice still breaks using that command (because it's missing dependencies, but with those it still breaks)

<cbaines>indigo-oce, are you using Guix on a foreign distro?

<indigo-oce>no

<cbaines>interesting

<cbaines>can you share any errors you see when launching pavucontrol (without guix shell)

<indigo-oce>cbaines https://paste.debian.net/1295199/ here is libreoffice breaking (which I need atm), pavucontrol seems to work after reinstall

<indigo-oce>what do you do when updating guix? does your channels.scm config specify the commit? do you manually update it? that's what I've been doing, it's a bit of a hassle but I've had stuff break just going to the most recent, so I try find a commit right after the package I need an updated version of

<cbaines>I'm not sure what's missing for libreoffice to work in a pure environment

<cbaines>what error do you get when launching it normally?

<indigo-oce>looks like a different error: https://paste.debian.net/1295200/

<geoduck>I'm trying to create packages for a few neuroimaging projects (ANTs, AFNI) that use cmake. They use git at config time to fetch (and option tweak) dependencies (niftilib, insight-toolkit). I'm hoping there's a way add multiple repo's to (package (origin ...)) but haven't found any examples [packages in the games channel uses (input `(origin ...)), but i'm not sure that'd work]

<cbaines>indigo-oce, this stands out "Locale not supported by C library"

<indigo-oce>yeah, something else broke due to something similar, nautlius... looks like it's working now, but gets the same error (Locale not supported...), doesn't break it tho

<indigo-oce>probably the last line that breaks it then, 'symbol lookup error'

<indigo-oce>my guess is some dependency version conflict

<cbaines>indigo-oce, try and work out what glibc version libreoffice is using. If you can find the store item, you can use guix size STOREITEM | grep glibc

<cbaines>then check what's in /run/current-system/locale

<indigo-oce>thanks

<futurile>Q: I'm working on a package (rust-libmdns v0.7.5), and it depends on a new version of rust-if-addrs (v0.7.0). How do I check whether other packages depend on rust-if-addrs? I was expecting ./pre-inst-env guix refresh --list-dependent rust-if-addrs to show rust-libmdns, or ./pre-ist-env guix graph --type=reverse-package rust-if-addrs. But neither is showing my updated package (rust-libmdns@0.7.5) as

<futurile>needing rust-if-addrs - waht am I doing wrong?

<podiki>efraim: great, thanks!

<jaeme>futurile: rust crates don't show dependencies with the cargo build system's arguments field if you use #:cargo-inputs keyword

<jaeme>They don't show cargo dependencies*

<jaeme>If you want to check crate dependencies, Ive just been grepping manually.

<jaeme>If you do ´guix show rust-reqwest´ you can see that it only picks up openssl and pkg-config as inputs

<jaeme>What's the licensing issue with nerd fonts in Guix?

<jaeme>Context: I use the nerd fonts package for emacs

<futurile>jaeme: ah! thank-you - cargo build system's foibles get me again =-)

<apteryx>efraim: oh! any log?

<apteryx>i'll merge the qt-team branch; I think i've waited long enough

<civodul>apteryx: sounds good; i re-restarted the qtbase build recently as it was in “missing .drv” state

<civodul>it’ll be built, sooner or later

<apteryx>yeah, it seems the aarch64 builders were too busy to process it in 36 hours

<civodul>i think they tried, but the .drv had been GC’d

<civodul>i noticed earlier today

<apteryx>fun, I found where a mis-sent commit was by using its Change-Id: https://issues.guix.gnu.org/search?query=I0d7274af400d9d24046ac6ab0466482c2690f2e5

<mirai>Any harm in setting the <origin> 'modules' field to have default value '((guix build utils)) ?

<mirai>I've been noticing that most of the times 'snippet' is used it involves using (guix build utils)

<civodul>mirai: we’d have to check the stats but it’s probably a good idea

<civodul>ACTION tries to make sense of https://lwn.net/SubscriberLink/946526/a1c7bb28c62c9667/

<civodul>“Image-Based Linux” isn’t something appealing to me at first

<apteryx>mirai: an alternative is to turn the 'modules' and 'imported-modules' fields as 'extend' rather than 'override'

<mirai>apteryx: oh, my question was for the <origin> record, it's unrelated to the ongoing %default-… series

<mirai>but turning it into extend does sound like a good idea

<civodul>apteryx: i would recommend against that; it’s something i avoided everywhere

<mirai>though it has to account for substitute-keyword-arguments

<apteryx>civodul: you mean the usage of 'extend' vs 'explicit' ?

<civodul>yes

<civodul>i think it’s much more convenient/cleaner if we give access to the whole thing, generally speaking

<apteryx>OK; any reason for preferring this way? I understand it provides the most control (and explicit is often better than explicit), but looking at the code base, it seems mostly a hindrance

<civodul>plus publish %default-… so that users can use the default

<civodul>we can look at the places where it’s a hindrance, but overall i think going the “extend” way is hard to revert and risks becoming a limitation

<apteryx>civodul: when using #:modules or #:imported-modules, I always want to extend the default module set, not override them. And it leads to things like fixed in https://issues.guix.gnu.org/65924#18

<apteryx>(posted to the wrong bug ID, apologies again for that)

<civodul>ACTION looks

<mirai>apteryx: tbh you could certainly want tp override in some rare cases

<mirai>say you want to try your own spin of (guix build utils) to test some changes

<civodul>(i think the term “cargo cult” is best avoided, for its colonial connotation)

<mirai>you might want to override it with something like (guix build utils-plus)

<mirai>civodul: only if you squint really hard? personally I don't think its the first thing that comes to the mind (the intention of the author seems clear to me)

<civodul>apteryx: i need to think more about it, but looking at https://issues.guix.gnu.org/65924#18, i’m not fully convinced

<civodul>it’s true that the list of imported modules was being used as the list of modules in scope

<civodul>fixing it is a good thing

<civodul>but it wasn’t incorrect either

<civodul>did you open a new issue for it where one can comment?

<civodul>or should we comment on that one?

<apteryx>for the simple fix and exporting %default-* bindings for the gnu-build-system, it's at bug#66426

<civodul>actually, #:imported-modules is a pre-gexp relic

<mirai>actually, I don't think there's any colonial aspect to it, it's more of a civilization vs (uncontacted?) indigenous societies in some islands across the pacific but don't quote me on that

<civodul>we should deprecate it

<apteryx>otherwise, no, it's just an idea that was floated here before and now

<apteryx>oh, does with-imported-modules work with the gexp arguments?

<civodul>yes

<apteryx>I thought I had tried before and was surprised to hit some issues. Probably pebcak if that should be supported.

<civodul>it’s interesting because some of these design decisions, like gexps, input labels, etc. lead to multi-year transitions

<civodul>even if we try to make it short (with ‘guix style’ & co.)

<apteryx>indeed!

<mirai>#:imported-modules and #:modules contain different things though, is it really a relic?

<apteryx>#:modules is not obsolete, IIUc

<apteryx>just #:imported-modules

<mirai>There's the tangentially related #66525

<apteryx>civodul: re unified kernel images (UKI), is this about turning distro upgrades to a mechanism similar to what Docker uses?

<graywolf>Hi Guix :) Is it possible that (this-operating-system) combined with (inherit ...) leads to an infinite recursion? 32GB of RAM at least does not seem to be enough.

<nathan-web>Hi. When I shutdown/reboot my computer gets stuck waiting for some processes to end. How can I find out what it is waiting for?

<apteryx>maybe strace -f -p 1

<apteryx>one known cause of a hang are NFS clients

<futurile>oh bloody hell - every time I try and send patches I fail to get it to thread them - even though when I send to myself it works - grr

<nathan-web>I haven't configured NFS. I just tried running strace in the background before shutting down. A lot scrolls by so it is hard to catch everything, but the last screen full seems mostly related to /etc/localtime. I get a lot of `epoll_wait(13, [], 8, 0) = 0`

<apteryx>futurile: the git config of Guix uses 'thread = shallow'

<nathan-web>I also see `write(20, "shepherd[1]: Service syslogd stop"..., 38) = -1 ECONNREFUSED (Connection refused)` and `connect(17, {sa_family=AF_NIX, sun_path="/dev/log"}, 10) = -1 ENOENT (No Such file or directory)`

<nathan-web>If I Do `Alt+SysReq+R, E` I see a lot of `shepherd[1]: waiting for process termination (processes left: (1 481))`

<graywolf>nathan-web: Try to figure out what is that process.

<graywolf>I have similar issue, and for me it is wifi driver.

<graywolf>You can just ps aux into a file, reboot, note down the number and look it up after that.

<efraim>apteryx: er, any log of what? I've been a little over eager touching many pieces the past week or so

<Franciman>hi, is guix system rolling release?

<jaeme>Franciman: yes

<jaeme>Though you can pin packages if you require older versions. Guix does not have a stable/unstable release channel format like Nix to my knowledge.

<Franciman>nice

<Franciman>thanks

<nathan-web>graywolf: Haha, ps into a file is such a simple solution. I've been sitting here trying to figure out how I can get Alt+SysRq+T to show me the process without being able to scroll in a framebuffer.

<jaeme> https://issues.guix.gnu.org/57149 the nerd-fonts licensing dystopia

<nathan-web>graywolf: does seem wifi related. Did you find a solution for it?

<jaeme>What a shame that some fonts are nonfree and whatnot

<graywolf>nathan-web: yeah, modprobe -r MODULE before shutting the system down, though I still have to write a service for that.

<graywolf>Alternative is to just wait, the system does not "hang", it just takes bloody forever to shut down. But it eventually will.

<graywolf>I have a question, can I use etc-service-type to create a files in a subdirectories? I am getting `system-error "symlink" "~A" ("File exists") (17)' when I try. But I am unsure why.

<graywolf>I mean, the directory (/etc/guix) does exist, but I am unsure why that is a problem since I am trying to create /etc/guix/channels.scm.

<nathan-web>graywolf: That makes sense. Thanks.

<graywolf>np :)

<Franciman>how much does it take for you to do a guix pull?

<Franciman>seems kinda slow today

<graywolf>Hm, ok, so it seems that guix puts all the files under /etc/static and symlinks them from there. So when I tell it to etc-service-type the /etc/guix/channels.scm, it actually does /etc/static/guix/channel.scm and symlinks /etc/static/guix into /etc/guix.

<graywolf>And that symlink fails. Sure, that makes sense.

<graywolf>I guess my question changes to "how can I symlink the actual file?" since I need to mix guix-managed and non-guix-managed files in one directory...

<snape>hi,

<snape>1. is there some sort of --no-color option to run guix commands in a compile buffer without ascii weird stuff?

<snape>2. how can I pass --keep-failed to the scheme `build-package` procedure?

<efraim>substitute* fails when the file is missing, right?

<efraim>still curious if anyone remembers, not actually relevant to what I'm solving ATM

<snape>reply to my first question: set NO_COLOR env

<jbnote>ls

<jbnote>snape: thanks for the NO_COLOR trick

<jaeme-->When do core-updates usually get merged in Guix? Is there a set interval?

<snape>yw!

<apteryx>i'm pretty sure there's an issue with 'mumi send-email' when sending series, if 'mumi current' was previously set to someth6g

<apteryx>it'll send the first message to the new issue created, and send the rest to the old one

<apteryx>maybe answering 'a' to git send-email when it asks for 'all messages' or similar has something to do with it

<apteryx>i'd be curious to have confirmation or infirmation of this before opening an actual bug report

<VesselWave>Hello! Is it possible to autostart user-level shepherd without Guix Home disrupting installed packages or autostaring from a window manager?

<jackhill>jaeme: no, I don't think there's a schedule, just when it's ready. I beleive that this is also the firt cycle of slimmed down core-updates. Other big things like GNOME have moved to their own branch and cycle.

IRC channel logs

2023-10-16.log