IRC channel logs

2025-04-09.log

back to list of logs

<zilti>I have an issue trying to run fwupdmgr. I always get "Failed to open polkit agent: missing executable pkttyagent in PATH".
<zilti>I doublechecked and made sure that the elogind and polkit services are enabled and running, and I installed polkit-qt6.
<Ingarrr>I was wondering what the recommended approach is for specifying inputs to build phases: Do I use (lambda* (#:key inputs #:allow-other-keys) ... OR do I use #$input1 and #$input2 ?
<Ingarrr>I was wondering what the recommended approach is for specifying inputs to build phases: Do I use (lambda* (#:key inputs #:allow-other-keys) ... OR do I use #$input1 and #$input2 ?
<Ingarrr>The reason I ask is because I thought it was #$input1 etc, but I think that if you do this, (modify-inputs) doesn't work on those anymore?
<graywolf>Ingarrr: I have seen (this-package-input "sed") and (search-input-file inputs "/bin/sed")
<sneek>Welcome back graywolf, you have 3 messages!
<sneek>graywolf, daviid says: i asked in #introspection, and the main dev answered: 'Not with GTK. If you're using X11, you can use XWarpPointer() It's pretty terrible UX.'
<sneek>graywolf, daviid says: if you want to learn to dev a modern app, you should learn from examples of modern app, the g-golf adwaita-1-demo and gtk4 examples would be a good start, my 2c
<sneek>graywolf, mwette says: maybe look into uinput (see also xdotool and it's refs)
<look>Hi, does anyone know if its possible to have a guix record directly inside a guix record?
<look>By that I mean (foo (bar (x 1) (y 2))) where foo and bar are guix records
<look>But bar is also a field of foo
<graywolf>I... do not think the syntax you envision is possible. You could have (foo (bar (bar (x 1) (y 2)))
<Ingarrr>graywolf: Thanks! (this-package-input) seems promising! I searched also the codebase for some counterexamples, like "emacs-haskel-mode" has emacs-minimal as an input and uses #$emacs-minimal, but I guess this makes it impossible to replace this input
<Ingarrr>I think this should be a bug report, if I'm correct?
<look>Yeah... I don't think so too. I believe services configurations could become a lot cleaner with that syntax
<look>I'll see if I can modify the define-record-type* to accept such fields with some field marker, how hard could it be *laughs in despair*
<lechner>look / yeah, I'm not sure that's possible, either
<nomike_>I want to package https://github.com/lenbok/scad-dbus. It has no releases, no tags, there is no license specified. Can I even package this properly and contribute it to guix?
<jA_cOp_>nomike: I don't know, but maybe try getting in touch with the author to get a license? they probably just forgot (I've been there myself)
<nomike>jA_cOp_, that's what I'm already doing right now ;-).
<jA_cOp_>nice :) hope you can get in touch
<vagrantc>nomike: the license is the only problematic part
<nomike>Makes sense. What should I put as a version number then? The HEAD commit ID?
<nomike>No, that won't work, as it's non-continuous
<vagrantc>right
<vagrantc>0-commitid or short commitid or something ...
<vagrantc>rummage around for examples in guix.git ... there are a few
<vagrantc>i like to use git describe output, but that still requires a tag
<vagrantc>good luck!
<vagrantc>ACTION waves
<eikcaz>Is there an easy way to inherit a package and just add to the existing configure flags?
<eikcaz>At this point I'm just coping the entire package def, so inherit isn't buying me much
<eikcaz>I know I can do (pakgae-arguments inherited-package) to get the original arguments list, but I don't know a good way to extract an argument type like #:configure-flags without a mess of car cddr cdar etc.
<Wurt>eikcaz, maybe can you use `substitute-keyword-arguments' (guix utils)?
<meaty>Is there any particular reason why amost no emacs ts-modes are packaged?
<eikcaz>Wurt, That is extremely helpful, thanks
<Wurt>eikcaz, you are welcome!
<eikcaz>meaty, I see a bunch of ts-modes are included in base emacs. Maybe the one you're looking for is there?
<divya>ACTION got ghc 9.4.8 to be bootstrapped from 9.2. Will soon go for 9.6.
<lfam>I just sent v3 of the linux-libre 6.14 patch: https://issues.guix.gnu.org/77297>
<sneek>lfam, you have 1 message!
<sneek>lfam, nigko says: Your solution to 'urandom-seed' service bug hinted me that 'tlp' service has exactly the same problem https://issues.guix.gnu.org/77629! Thanks!
<lfam>Nice nigko!
<lfam>v3 of the linux-libre 6.14 patch should be built by CI shortly: <https:/>/ci.guix.gnu.org/eval/2052225
<lfam>Urgh
<lfam> <https://ci.guix.gnu.org/eval/2052225>
<adanska>hi guix, whats up with the `tlp` build faliure on ci?
<adanska>it says that https://ci.guix.gnu.org/build/9910779/details was cancelled
<apteryx>is there a man page documenting the roff fomat? (man page)
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, lechner says: / The test suite in #64211 uses Python. Do you really think it makes sense to declare Python as a prerequisite for building WASI? Isn't our package graph complicated enough?
<peanuts>"[PATCH] gnu: Add wasi-libc." https://issues.guix.gnu.org/64211
<apteryx>lechner: hi! I don't really think that, or haven't had a chance yet :-) What I wrote in my review was that when #:tests? #f is used, an explanatory comment is needed.
<apteryx>now to your question above: since not much depends on WASI, I think the trade is worth it here (test suites are a relatively cheap way to improve the quality of our packages).
<jA_cOp_>Are self-hosted compilers allowed in Guix? I've packaged Factor, and the source tarball includes a small binary bootstrap image, which is used in the package process together with the VM (compiled from C++) to generate the main image
<jA_cOp_>My impression is that no one is currently maintaining a full bootstrap path for Factor (which would involve going back some 20 years)
<apteryx>packaging a bootstrap binary wouldn't be proper for Guix, no.
<apteryx>jA_cOp_: do they release often?
<apteryx>rust is a pain because it's moving so fast, but if factor is mostly done and static these days (rarely releasing), perhaps there's value in attempting the crazy bootstrap path for it.
<jA_cOp_>Once a year maybe? https://github.com/factor/factor/releases
<apteryx>I think one such example is Mono, recently reintroduced in Guix with a bootstrap
<jA_cOp_>IIRC bootstrapping Factor would involve resurrecting a Java implementation called JFactor from 20+ years ago
<jA_cOp_>Ah yeah, I should re-read the blog post about Mono
<ronqui>Something up with the online guix situation?
<futurile>ronqui: ?
<ronqui>looking packages up using my browser was giving me 504 timeouts
<futurile>ah, yeah that service seems to have problems sometimes.
<Kabouik>Rutherther: I decided to submit a minor PR with your comments but got this answer: https://github.com/nbfc-linux/nbfc-linux/pull/192
<Kabouik>Would you by any chance know which would be the best implementation to use in a Guix package definition, from what the dev suggested?
<Kabouik>I opted for: https://0x0.st/8_nW.txt
<Kabouik>Is there any reason why `guix pull` would pull a commit that is not the latest in my private channel? This is the first time it happens to me, it throws no error, just pulls a commit that is a month old despite new ones available on the upstream repo.
<Kabouik>Oh well. Somehow I had mistakenly replaced my production channels.scm with a guix describe channels.scm. ._.
<lee-thomp>At the risk of sounding needy or entitled, is there a reasonable time frame to expect that a patch sent in has been missed or buried among others instead of maintainers just being busy? OTOH I think I'd probably try to bump my patches on the mailing list if any hit a month without reply; luckily none are there yet, but I was still wondering anyway
<cbaines>lee-thomp, personally I want to see patches being reviewed which anyone can do, it's not limited to maintainers
<cbaines>according to QA at least, there's only one patch series that's been reviewed and looks good and hasn't been merged https://qa.guix.gnu.org/patches so there's not a backlog in that sense
<andreas-e>Shoutout to fellow committers, there are quite a few green badges on QA: https://qa.guix.gnu.org/patches
<cbaines>I don't think it's feasible to rely on people with commit access, let alone maintainers to be the only ones reviewing patches
<andreas-e>The easier ones are gone now :) Well, new ones arrive all the time. But there are also some that I do not feel competent enough for.
<andreas-e>Indeed, if a second person reviews these patches (licenses are important to verify, which is easy, but always takes a bit of additional time); or just confirms that a service change is working as expected; that will be super helpful.
<apteryx>is it possible to use sudo in an activation snippet?
<apteryx>I want to check if a file is readable for the service user
<lilyp>I think the more appropriate question is: what user are activation snippets run as?
<apteryx>root
<lilyp>IIUC it's root anyway ;P
<apteryx>the service I'm coding up (pounce-service-type) will run as its own unprivileged user (pounce)
<pounce>owo
<apteryx>eh
<lilyp>iiuc root should be able to read uid/gid of the files to check, no?
<apteryx>is that enough of a check? the file may be owned by a different user but still allow read access
<apteryx>wouldn't be a very good thing for a private tls key, but for a cert it could be a thing
<csantosb>cbaines: I see more qa processing than ever in my patches, thanks ! This is really helpful.
<apteryx>I guess I could also check the permissions and compute whether access is supposed to be available
<lilyp>you could also fork and use setuid/setgid to run guile code as pounce
<csantosb>cbainer: however, is there a reason for older patches with a "qa unknown" status ? anything I can/have to do related to this ?
<lilyp>IIUC that's what shepherd does
<cbaines>csantosb, because of resource limitations, QA only looks at the most recent patches. If you resend some old patches, then it should pick them up again
<cbaines>plus, review the patches that QA is currently working on, that'll help get more things merged!
<lilyp>btw. I figured out my glib cycle, so I'm hoping to get work on gnome 48 started soon™
<csantosb>cbaines: by resending a patch, you mean sending a v2 or closing the bug and starting a new one ?
<cbaines>sending a v2 (although you don't even need to change the version, but doing so does help people when looking at the patches)
<csantosb>I see, thanks !
<lee-thomp>cbaines: ohh okay I had no idea about this all, I'm used to projects where only maintainers with commit access can check and apply patches —so do you mean to say I can just review others' patches on the mailing list?
<Rutherther>lee-thomp: definitely. Anyone can review and that way you help maintainers to speed up the process
<cbaines>lee-thomp, yep, obviously the valuable bit is spotting problems or things to improve and sending that feedback, and if you do review a patch series that you don't see any major issues with, you can mark that as reviewed and looking good (QA has some guidance on how to do this)
<cbaines>that'll highlight it to someone with commit access who can quickly double check it's all good and hopefully merge it
<cbaines>if you click on any of the patch series on https://qa.guix.gnu.org/patches you should find the form to mark a patch series as reviewed
<apteryx>lilyp: forking, true. Good news for GNOME 48!
<apteryx>I think we should implement the simple parser turning https://gitlab.gnome.org/GNOME/releng/-/blob/master/tools/versions-stable#L13 into a manifest
<apteryx>that file looks easy enough to parse
<lilyp>I'm typically referring to https://gitlab.gnome.org/GNOME/gnome-build-meta/-/tree/master/elements
<lilyp>contains a bunch of yaml files, listing dependencies as well
<PotentialUser-31>Hi, how can I use substitutes from data.qa.guix.gnu.org?
<PotentialUser-31>if, say, i want "guix build whatever" to fetch substitutes from a wip patch from there
<cbaines>PotentialUser-31, you can find the key here https://data.qa.guix.gnu.org/substitutes
<PotentialUser-31>oh nice, I just add it to /etc/guix/machines ?
<cbaines>you'll only find substitutes for the derivations though, if the bordeaux build farm has built the packages associated with the patch, you'll get those from bordeaux.guix.gnu.org
<PotentialUser-31>oh, so substitutes for packages that arrive on issues.guix.gnu.org get available on bordeaux.guix.gnu.org before they are applied, right?
<PotentialUser-31>I mean before they are pushed
<andreas-e>Yes.
<andreas-e>But they are not very numerous. They should correspond to the green badges at https://qa.guix.gnu.org/patches , which usually get committed relatively quickly.
<PotentialUser-31>why are they not numerous, i thought (from a year ago) that there were tons of patches in waiting
<andreas-e>Yes, but they have also not been built by QA yet, only the green ones are built.
<PotentialUser-31>so QA goes from most recent ones to olders I guess
<PotentialUser-31>or it's because older patches cant be applied easily
<cbaines>QA is resource limited, so it just looks at the recent patches
<PotentialUser-31>got it, thankx
<cbaines>but if those are reviewed and merge it will start to look at older ones, and older patches can always be bumped
<PotentialUser-31>great
<PotentialUser-31>are they applied to their local parent or to the current main ?
<andreas-e>I think it is the current main. On https://qa.guix.gnu.org/patches you see a number of patches (dark red badge with a cross) that fail to apply; it would be helpful if submitters sent an updated version.
<PotentialUser-31>ok, yeah
<ajarara>I'm trying to package a build system, but one of the dependencies of the build system uses the build system to.. build. go-github-com-thought-machine-please -> go-github-com-peterebden-go-cli-init -> please (the binary)
<lilyp>in other words, you need to bootstrap your build system?
<ajarara>it certainly does that itself, please has a bootstrap that depends on go to build a more featureful version of itself
<ajarara>would creating a wrapper for this minimal version and using that to build dependencies by fruitful? would that be upstreamable?
<ajarara>be fruitful*
<ajarara>or another route might be to find a previous version of please that has no please dependencies?
<ajarara>please-enabled dependencies*
<lilyp>whether that's upstreamable is a question for upstream
<lilyp>if please can bootstrap from an earlier version of itself, that's likely going to be the "simpler" road
<lilyp>that's a big "if" I know: just look at scala for a counterexample
<ajarara>I'll post on the mailing list and ask the maintainers of please. xplat build systems: a pleasure to use or trivial to package, pick maximum one
<ajarara>thanks!
<lilyp>meson is a nice middle ground, particularly given that alternative implementations exist
<lilyp>just wish it had guile support :)
<ajarara>I did look at Meson (after giving up on cmake) because I wanted an easy to extend rule set for arbitrary build systems (like Android). Buck2 is close, but it depends on rust-nightly.
<ajarara>Guix itself might be able to fill this space. I remember reading some discussion on packaging guile and how guix was really the best option, despite how general it is.
<ajarara>Definitely awkward for very slim modules though.
<ajarara>really the best option because of how often it is glued with C, that is
<lilyp>well, the guile-build-system in Guix is rather simplistic
<lilyp>there are others like the venerable autotools and hall
<lilyp>(the latter outputs autotools last i remember)
<ajarara>thinking about it only the second option is long term maintainable: the plz maintainers would have to be careful about keeping the bootstrap seed minimal, and if they release a version that includes a please-dependent dependency, then we cannot update to it, and what's worse is we'd only really find out after they cut a version.
<lilyp>Welp, I guess GNOME 48 is a nice reminder that we still need to bootstrap Vala
<lilyp>Current efforts are at https://gitlab.gnome.org/lilyp/vala-bootstrap
<cancername>Hi #guix, how can I reactivate a Cuirass specification I deactivated in the web interface? it seems like that's kept as state in the db which I can't access. I haven't found anything about that in the manual
<trannus_aran>just installed guix with the official script on fedora, but it says /gnu/store is mounted as read-only, blocking any package installation? Supposedly an SELinux thing, but I've never found a solution other than just turning off SELinux, which isn't great. Any solutions?
<dariqq>trannus_aran: See https://guix.gnu.org/manual/devel/en/html_node/SELinux-Support.html . The selinux policy from guix is not perfect but mostly works.
<dariqq>trannus_aran: also if you just installed the policy file is probably not the latest one so youd need to redo the steps once you have updated roots guix
<trannus_aran>so as far as I can tell, the fedora/RHEL-specific instructions are:
<trannus_aran>1. run the install script as root in /tmp
<trannus_aran>2. semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil
<trannus_aran>3. mount -o remount,rw /gnu/store && restorecon -R /gnu /var/guix
<trannus_aran>4. Restart guix-daemon.service
<trannus_aran>5. ???
<trannus_aran>dariqq: ah, yeah, I saw some rumblings about that in an issue just now
<trannus_aran>so do I want to guix pull then install glibc-locales and export GUIX_LOCPATH, or the other way around? Or do I want to update guix itself with the sudo -i guix pull && hash guix && guix describe?
<trannus_aran>I take it all these things need to happen on a foreign distro, I'm just unclear on the order of operations
<trannus_aran>alright, I'm going with install locales, export GUIX_LOCPATH and sudo -i guix pull, wish me luck lol
<Rutherther>doing sudo guix pull and then hash guix has no effect, your user's guix is not going to change when you update root's guix
<Rutherther>updating root's guix is only for updating the guix-daemon service
<Rutherther>if you want to, instead, just update the guix you're using as your user to install out of, pull without sudo
<Rutherther>if you want to, instead, just update the guix you're using as your user to install out of, pull without sudo
<dariqq>It also updates /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil which is the policy file the manual suggests to install. Ofc you can get the updated policy through other means but I was trying not to overcomplicate things
<cancername>Hey all, I'm running cuirass, and I've deactivated a specification. How can I activate it again? I checked the manual and tried to connect to th db with psql, which fails with "Peer authentication failed".
<PotentialUser-48>Hi. Can I modify rust package inputs in inherited package?
<ieure>PotentialUser-48, Yes.
<PotentialUser-48>Sorry, I meant the package's cargo inputs
<ieure>Oh, I don't know.
<Rutherther>PotentialUser-48: sure, see substitute-keyword-arguments
<Rutherther>it's just an argument, so you just append to it / replace inside of it. I don't know about a tools that would make it easy (some sort of modify-cargo-onputs), but it's certainly possible, it's just an alist that you can modify
<PotentialUser-48>Okay thanks.
<cancername>I was able to activate the jobset using `/admin/specifications/activate/NAME`, this should probably be documented somewhere
<PotentialUser-31>Hi, if I add a patch to a bug (bug-guix@gnu.org), would the patch go on QA as patches in (guix-patches@gnu.org) ?
<hanker>Is there someone working on packaging a more recent version of the OCaml compiler?
<trannus_aran>Rutherther: ah, fantastic, thanks!
<trannus_aran>just waiting waiting waiting for that `indexing objects` task to complete -.-
<Tadhgmister>when I try to do `guix build shepherd` on arm the check fails saying `unshare` is not a command, is there an officially supported way around this? I am currently running shepherd that was cross compiled so I assume it is supported just the tests aren't necessarily?
<futurile>PotentialUser-31: you have to send the first patch to guix-patches@gnu.org I think, for QA to pick it up. If you're sending to an existing bug (that had patches) then I think the tag will mean that QA will pick up the new patch - specifically it definititely picks up v2/v3 etc where you're respinning a patch series
<PotentialUser-31>ok thx!
<hanker>Hmm, it seems `guix shell ocaml --with-version=ocaml=5.3.0` just works
<jA_cOp_>Does anyone have a minimal system configuration for use with `guix system vm` I can look at? I'm wondering what to put for bootloader and file-systems in particular, if anything. I want to use it for a minimal testing environment for stuff in my Guix channel
<futurile>jA_cOp_: there's minimal definitions in the guix archive
<Rutherther>jA_cOp_: it doesn't matter, those fields get replaced. Or at least bootloader is, I am not completely sure if all filesystems are deleted, and I cant check now
<Tadhgmister>jA_cOp_ https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/vm.scm#n180 yeah the `guix system vm` straight up overrides the bootloader and filesystems
<jA_cOp_>Thanks - I've used the minimal configuration from the installation guide now, I was just a bit confused because if I remove the bootloader and file-systems fields, I get an error. What's the guix archive, though? First time I hear of it