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 <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 ;-). <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>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 <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>v3 of the linux-libre 6.14 patch should be built by CI shortly: <https:/>/ci.guix.gnu.org/eval/2052225 <adanska>hi guix, whats up with the `tlp` build faliure on ci? <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? <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>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. <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? <ronqui>looking packages up using my browser was giving me 504 timeouts <futurile>ah, yeah that service seems to have problems sometimes. <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>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>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>the service I'm coding up (pounce-service-type) will run as its own unprivileged user (pounce) <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) <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 <apteryx>lilyp: forking, true. Good news for GNOME 48! <apteryx>that file looks easy enough to parse <lilyp>contains a bunch of yaml files, listing dependencies as well <PotentialUser-31>if, say, i want "guix build whatever" to fetch substitutes from a wip patch from there <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>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. <cbaines>QA is resource limited, so it just looks at the recent patches <cbaines>but if those are reviewed and merge it will start to look at older ones, and older patches can always be bumped <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. <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>or another route might be to find a previous version of please that has no please 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 <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 <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: 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>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>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". <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 <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>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 <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 <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