IRC channel logs


back to list of 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
<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
<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!
<cbaines>morning o/
<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: . 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)
<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: . Thanks
<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: but I thought I already imported it.
<cbaines>yaslam, looks like the xorg module exports slim and gdm, but not lightdm
<cbaines>that seems to have it's own module
<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 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
<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?
<cbaines>can you share any errors you see when launching pavucontrol (without guix shell)
<indigo-oce>cbaines 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:
<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
<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:
<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
<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>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
<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, 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?
<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.)
<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.
<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> 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>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>snape: thanks for the NO_COLOR trick
<jaeme-->When do core-updates usually get merged in Guix? Is there a set interval?
<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.