<bdju>Why don't I get the confirmation email when I report bugs anymore? Or see my own email with the reported bug? I would think the email wasn't getting through if not for the fact that I can see it from the web UI.
<anemofilia>(I actually can't remember exacly when it stoped working too)
<HexMachina>Did Guix recently change how commits are signed or authenticated? Running a `guix pull` fort the first time in around 2 months fails for me within git-authenticate.scm calling verify-openpgp-signature with the error "gcypt: Not supported"
<HexMachina>I ended up tracking down the error to disallowed signature types caused by my foreign system running under FIPS 140 mode. Doing a temporary `echo 0 > /proc/sys/crypto/fips_enabled` resolves the issue and my `guix pull` works
<HexMachina>Which I imagine could occur at various HPC/research institutions
<HexMachina>Oh dear, the build daemon also fails within the valid-narinfo? method when trying to download substitutes. My org's rollout of FIPS might prevent me from using Guix :\
<apteryx>HexMachina: could this be resolved by building libgcrypt with FIPS support?
<HexMachina>The problem is that it DOES support FIPS. When libgrcypt is loading (on first dlopen I think), it checks the value of `/proc/sys/crypto/fips_enabled`, and if set to 1, a bunch of algorithms are disabled
<HexMachina>This indicates that Guix's mechanism of signing/authenticating is relying on old/deprecated possibly insecure algorithms, which FIPS says you can't use
<HexMachina>If I `echo 0 > /proc/sys/crypto/fips_enabled` and then restart the guix build daemon, everything works, but this isn't going to fly with my IT department as a long-term solution
<HexMachina>Well that's not exactly right. It might be using a newer algorithm that's actually better but hasn't been FIPS-approved yet? I haven't identified with alogirithm is the culprit. FIPS also mandates things like minimum key size
<HexMachina>on my system, running with FIPS mode disables the following cipher algorithms: IDEA, CASTS, BLOWFISH, TWOFISH, CAMELLIA128, CAMELLIA192, and CAMELLIA256 - it only allows 3DES, AES, AES192, AES256. For hash algorithms, it disables RIPEMD160, and only allows SHA1, SHA256, SHA384, SHA512, and SHA224
<HexMachina>Not sure if Guix is using one of those disabled algorithms, or if it's a key size issue, or what exactly
<HexMachina>It's quite possible Guix is using a newer/better algorithm that hasn't yet been FIPS approved
<HexMachina>The algorithms can be seen running `gpg --version` with /proc/sys/crypto/fips_enabled set to 0 and 1, respectively
<chomwitt>is there a way to add 'nofail' as a mount option in config.scm ?
<efraim>theres a couple of suprise final packages that get automatically generated as dependencies
<bjc>what's the right way to add a news entry for ‘guix pull’?
<f1refly>I'm not sure if I understand the QT_PLUGIN_PATH correctly. On my system, it is set to '/run/current-system/profile/lib/qt6/plugins'. But, alas, kvantum is using qt5 and it doesn't appear to be happy with the qt6 plugin path. When I start a shell with qtwayland@5 and kvantum, it starts alright. In #57742, it is implied that the plugin path should include both qt5 and qt6, or do I read that wrong?
<f1refly>ACTION still has no idea if he is just holding the distro wrong
<distopico>Good day Guixers, I'm new in Guix and I have a question regarding if is possible in Guix define in the configuration a different linux-libre version, I upgrade yesterday and after update from Linux 5 to 6.3 Gnome and 3D with and Nvidia card
<distopico>With an Nvidia card with the last upgrade is working unstable and it freeze sometimes
<distopico>So, how can I declare in the configuration a different linux-libre version?
<janneke>distopico: use something like (kernel linux-libre-6.1), and (use-modules (gnu packages linux))
<jpoiret>bumble[m]: there was a change yesterday that each clause will only be used once, hence the (delete agetty-service-type) will only work for tty1. You can pass it multiple times to delete all of them
<jpoiret>in the end I'm not sure it was such a good idea
<Cairn>Those embedded images defined at the bottom of install.scm... Can those be built from the command line, or do I need to run a guile function directly?
<civodul>jpoiret: re delete only once, i'm not sure it was a good idea either actually
<civodul>it was an easy way to tell whether a clause had been used or not, but we could do it differently
<bjc>the patch i sent a week or so ago should do the check now, if all you're interested in is whether or not it matched
<bjc>i found deleting everything to be irritating, but only deleting one at a time is, too, honestly
<ngz>Is there, in a build system, a way to tell the transitive inputs of the package being built (i.e., those bound to stay in the store) from the native one (which could be GC'ed)? I tried `package-transitive-inputs' to no avail. I don't think (guix packages) is accessible from (guix build ...) modules.
<sneek>ngz, civodul says: how far are we from merging 'tex-team'?
<jpoiret>ngz: there's no correlation between what you're describing, what are you trying to do?
<ngz>civodul: AFAIC, "tex-team" can be merged anytime. I'm only working on "tex-team-next" these days. This branch requires at least an additional week of work (and possibly some feedback) depending on if I try to push it to updating to TeX Live 2023 or not. But it's looking good.
<patched[m]>How to locate manpages for gcc? guix shell gcc-toolchain -- man gcc says there is no manual entry for gcc...
<jpoiret>unfortunately you can't distinguish native inputs from inputs on the build side if you're building natively
<jpoiret>patched[m]: in a shell you need to add man-db for the manpage database to be generated for the profile
<ngz>It will happen at some point, like the rest of us :)
<ngz>jpoiret: Anyway, problem solved! Thanks for confirming it!
<bjc>civodul: just catching up on email; sorry about #63921! i assumed order didn't matter, and even wrote my tests to ignore it
<bjc>is the issue that the dependency graph is produced before ‘modify-services’ is called?
<bjc>or is it that order isn't strictly defined within a service-type? like you can't say that activation services for foo depend on bar already being activated?
<mirai>iirc only shepherd services have the notion of conflicting
<mirai>the service-type “name” is merely informative
<Wurt>Hi, I am a newbie that wants to send multiple patches to email@example.com using Emacs. Is there any specific tutorial for Emacs and Magit? Is there any guide to write the contents of the cover letter?
<civodul>bjc: np, i overlooked that too! order matters for some services, like the "boot" service in this case
<civodul>mirai: in 0.10, there's no notion of "conflict"; a given name maps to exactly one service (or none)
<jpoiret>Wurt: make sure to only send the cover letter first, wait for the debbugs reply and then send the rest to the bug's address
<f1refly>disregarding the qt problem for a while - i updated my system and now my system.scm won't build anymore. I tried following the devel documentation for how to set up a greetd-service-type, but it complains that "service 'term-tty2' provided more than once"
<f1refly>I deleted login-service-type and mingetty-service-type from %desktop-services
<johnabs[m]>Hey guys, I'm trying to rebuild xmonad after an update and the whole thing is wack and my computer is only 20% functional right now. Here's a paste of the error I get when trying to run xmonad --recompile, can some haskell/guix wizard take a look if you don't mind? https://pastebin.mozilla.org/dty7mHQP (Sorry, I'm mostly a Lisp/Julia guy so I'm still learning this stuff 😅)
<johnabs[m]> I can also post my config if needed, I only changed 1 line because it's now included in xmonad by default (just removing the import Data.Default line)
<ieure>johnabs[m], I'm not a Guix expert (or even regular user), but the error message indicates that the build depends on librt, which either isn't installed, or isn't on LD_LIBRARY_PATH.
<ieure>I thiiiiink LD_LIBRARY_PATH is where it'd be looking for it.
<ieure>I know it's used by the dynamic linker, but I'm not 100% sure about ld.
<jpoiret>johnabs[m]: do you use ghc installed via `guix package`?
<johnabs[m]>Okay, I'm looking on guix search, it seems there are two possible options: librttopo or librtprocess, it doesn't seem like it's either of those, or maybe it is?
<johnabs[m]>It created the env, but I'm still getting the same error, and oh okay, you see it too
<elevenkb>I managed to resolve my troubles with evaluating a derivation w/o offloading programattically.
<jpoiret>johnabs[m]: how about `guix shell -e '(list (@@ (gnu packages commencement) glibc-final) "static")' gcc-toolchain@11 ghc`
<ieure>Is there some place which explains a Guix thing I've never understood: why are channels defined per-user, but used by the system configuration? Why isn't there a notion of system channels?
<ieure>For example, if I create a channel for personal software, and have (use-modules (personal thing other-thing)) in /etc/config.scm, it only works if the `personal` channel is configured for whatever user runs `guix system reconfigure`. That seems wrong to me.
<ieure>It feels very weird to me that the an identical system configuration would work or fail depending on the configuration of the user invoking it.
<ytc>gtk theme is properly set, but application icons are missing
<ytc>application launchers also show missing icons
<ytc>on GDM, an icon is also missing at the top-right corner
<jpoiret>cbaines: hey chris, let's say I'd want to merge https://issues.guix.gnu.org/60824, but it has god knows how many dependents. Would you say the preferred procedure would be to create a topical branch for it, and instantly add a request for merge so that it gets in the queue?
<jpoiret>how should we handle keeping it up-to-date? merging periodically?
<jpoiret>using an install iso to do it is simpler though, you don't have to worry about installing another distro first but keeping space for guix, then installing guix through that and then deleting the other partition
<jpoiret>i'd suggest using something minimal like an arch iso, running the guix-install.sh script on it, guix pull'ing, making sure you're using the latest guix and finally following the system installation guide