IRC channel logs
2023-01-17.log
back to list of logs
<mirai>and I have no idea wtf happened <lechner>sometimes, aliens eat people too. i hope mirai is alright <mirai>ACTION puts on sunglasses to make the lizard eyes less noticeable <mirai>I've no idea how to repair this system <mirai>guix gc verify doesn't complain of anything <mirai>-r-xr-xr-x 1 root root 0 Jan 1 1970 /gnu/store/fx2iy35p6hl5mfji6kmg9kh2vlf90dfg-util-linux-with-udev-2.37.2/bin/dmesg <bumble[m]>does anyone know where an example config using wireplumber to setup audio might be found? <panosalevro>bumble[m]: i have pipewire+wireplumber installed and execute it via my wm. i thought that was sufficient <bumble[m]>@panosalevro ok thanks I'll consider that approach <panosalevro>question. i have mpc installed but my terminal complains that mpc is command not found. how come? <lechner>do you use guix home, or did you source the new profile? <panosalevro>and another silly question. what's the best way to log in and out on guix? <apteryx>mirai: did you figure out your problem? <mirai>I managed to switch-back to a functioning generation <mirai>if I reconfigure again then dmesg and rsync at least get turned into 0-byte files <mirai>funnily, the system can reboot and boot even in the broken generations <mirai>so it's not completely impossible to use <mirai>the conundrum now is: do I reconfigure and lose rsync and dmesg (and who knows what else) to activate my latest config.scm or just upgrade the packages or do I remain in the last working generation <mirai>looks like that computer got hit by some kind of curse <mirai>can you do a successful pull + reconfigure and run rsync or dmesg afterwards? <gnucode>I just found out about guile-studio. That's super cool! <apteryx>mirai: perhaps your disks are dying? I'd take a backup <mirai>on the working generation, dmesg doesn't show any kind of message suggesting read errors <apteryx>OK; that should have you well covered (raid1 btrfs) toward detecting file corruption <mirai>odd that both rsync and dmesg go consistently to zero bytes <apteryx>does the same rsync run fine when booting a previous generation? <lechner>mirai / is something in your update infrastructure corruptes, such as Guix? <mirai>and guix gc verify doesn't complain <mirai>it can't be disk corruption (?) <mirai>but it also is a older "derivation" <apteryx>you can run it from the store; the exact same hash <mirai>or has a different hash (when read-linked) <mirai>yeah, the old hash will work <apteryx>this one /gnu/store/3xpf9j6cy8i7vham11c1p4zcdqadjzph-rsync-3.2.7/bin/rsync ? <mirai>apteryx: that one is broken to me (0 bytes) <apteryx>472K /gnu/store/3xpf9j6cy8i7vham11c1p4zcdqadjzph-rsync-3.2.7/bin/rsync <mirai>-r-xr-xr-x 1 root root 0 Jan 1 1970 /gnu/store/3xpf9j6cy8i7vham11c1p4zcdqadjzph-rsync-3.2.7/bin/rsync <mirai>-r-xr-xr-x 2 root root 469K Jan 1 1970 /gnu/store/72isv0hc8wp65bajhdh8jqvd3m9w0p4x-rsync-3.2.7/bin/rsync <apteryx>try deleting the system or user profile(s) that reference that rsync; then run 'guix gc -D /gnu/store/3xpf9j6cy8i7vham11c1p4zcdqadjzph-rsync-3.2.7' and try reinstalling it' <apteryx>(guix build /gnu/store/3xpf9j6cy8i7vham11c1p4zcdqadjzph-rsync-3.2.7) <apteryx>you could also try: guix build --no-grafts --check /gnu/store/3xpf9j6cy8i7vham11c1p4zcdqadjzph-rsync-3.2.7 <apteryx>to have it rebuild and compare with what's there <mirai>ok, that no-graft check worked <mirai>for some odd reasons, neither gc repair, verify or previous guix build --repair worked <mirai>or some permutation of the command <apteryx>i think 'guix gc --repair' is flawed, it was discussed recently, although I don't have experience with it <mirai>but is there some command to actually verify what's broken? since idk if it's only dmesg and rsync that got cursed <mirai>let me see if I can dig out anything coherent from my bash history <mirai>rather odd as it's the system that sees the least radical changes <mirai>I wish I could tell you exactly what caused it to crap itself but I've no clue what made these files go 0-byte <mirai>I only noticed it when I wanted to rsync a new config.scm in <mirai>so it must have been in this state for days at least <trevdev[m]>Anyone else here use ZSH and get weirdness with a --pure shell? I wrapped all of my extensions in an environment check to avoid most of the broken, but the shell still doesn't read delete properly. It inserts a space instead, even though the character before is actually deleted <bumble[m]>unmatched-paren I copied your wlgreet configuration but only get a blinking cursor. I don't want to bother you... if you are too busy to help me I understand, but if you will help me that would be awesome <unmatched-paren>bumble[m]: everybody who copies it gets that and i don't understand why :( <bumble[m]>okay its on a different machine, I'll carry it over here and power it up <bumble[m]>also, thank you for the terrific waybar configuration <unmatched-paren>it must be something stateful that's causing it to work on my machine <unmatched-paren>since there was someone who copied my entire config basically verbatim and it worked for them <bumble[m]>it shows several lines exactly the same message... <bumble[m]>error: check_children: greeter exited without creating a session <bumble[m]>the wlgreet parts are commented out and the file is a little chaotic (sorry) <bumble[m]>crazy undecipherable of a build drv file when updating the channels, possibly because my guix channel is pinned to 1.4.0 release... <ulfvonbelow>I'm thinking it might be an expiring certificate issue, since the daemon doesn't create a time namespace or anything like that <vivien>ulfvonbelow, it builds fine here <jgart[m]>lechner: I like the )( bug paren squash reference <ulfvonbelow>ah, in my repository it's 1.1.1l. I should probably rebase if there's a newer one now <cgenie[m]>Is there any reason why guix limits itself to few CRAN packages for R? What nix does here is they have a script to parse the whole CRAN repository and generate the definitions automatically. I am missing packages like plumber which I could add by hand but its a waste of time IMHO. <vivien>openssl-1.1.1s builds fine on my machine ulfvonbelow <vivien>cgenie[m], I can speculate that guix would like to check the license of the packages and unbundle dependencies <ulfvonbelow>cgenie[m]: 'guix import cran plumber' gets you 90% of the way there. I don't know how cran specifically handles these issues, but many popular language-specific packaging systems have issues with security, typo-squatting, including malware, especially in cases where anyone can upload a package with little vetting. <ulfvonbelow>I don't know if it's the official rationale, but importing only what we need and use avoids pulling in any landmines by accident. <rekado>cgenie[m]: in Guix proper we provide curated packages; the packages are known to build fine, minified Javascript is built from source, any bundled libraries are replaced, etc <rekado>for everything else there’s the mass import of the guix-cran channel <ulfvonbelow>vivien: have you tried 1.1.1l with --no-grafts? Are you on core-updates or master? <klm_>Is it possible to run AMD GPUs on Guix/Linux-Libre? I don't need 3d acceleration, just its video output connections. `xrandr --listproviders` only show my integrated Intel GPU and dmesg is (unsurprisingly) complaining about firmware blobs, but I was hoping something like noveau would exist for AMD GPUs too. <ulfvonbelow>when last I tried running with just the basic functionality on my integrated amd graphics, it would only output to a single monitor, at a low resolution IIRC <ulfvonbelow>well, only output /independently/ to a single monitor. I was able to connect a second one, but it just duplicated the output to the first. <klm_>Oh, even on integrated AMD GPU you're pretty helpless? I've got a RC480 (pretty old) <ulfvonbelow>I haven't been able to get AMD GPUs working on linux-libre all the way back to the radeon hd 6670 <klm_>Sorry, meant RX480. It's a dedicated GPU. Gosh, thanks for the info (or warning, rather) <klm_>So what I'm getting from this is: 1. never go for AMD GPUs (neither dedicated or embedded) 2. go but an old Nvidia GPU for more monitor output connections and use noveau. <klm_>Will plan 2. work? `noveau` shouldn't contain any firmware blobs I don't expect, but I've never tried it. And for old cards I'd expect it to be relatively stable too. Am I being naive? <ulfvonbelow>the freedom issues around graphics card are rather frustrating. Corporation 1 wants their proprietary code loaded into the hardware at boot time by the kernel, and corporation 2 wants their proprietary code loaded into kernel / user space. <ulfvonbelow>plan 2 will work somewhat, at least, if you research the cards in question <ulfvonbelow>I ended up getting 2 NVIDIA 8400 GS'es, but I ended up having a ton of issues with xorg freezing up <ulfvonbelow>also worth noting, those particular cards have 3 ports but only allow independent video output to 2 monitors at once <klm_>ouch ... did you have any success with any other dedicated GPUs? <klm_>is that a hw limitation, or the driver you think? <klm_>where can I find out what GPU have good noveau support? <Nathan-web>Hi. While trying to run a binary I was getting an error `No such file or directory`, which I figured out was because it linked to something in /lib64, so after some debugging I ran `guix shell -CF coreutils gcc-toolchain` and tried to run it again but now I get `error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No <ulfvonbelow>unsure. A while back, after messing with my hardware a bit, I found out my RAM was somewhat unstable at the speed I had it at. Could have been related to that. Right now I only have one of the discrete cards in and it's running smoothly, so the other one might have just been going bad. <Nathan-web>I can find the library, but is there a reasonable way of telling guix shell to put those libraries where they would be expected, or to tell the binary about the actual location? <klm_>I see. So Nvidia 8400 might be worth trying out, thanks a buch for your tips. Saved me _a lot_ of hassle. <ulfvonbelow>I'd recommend looking at whatever resources the nouveau project has <ulfvonbelow>also there's h-node, but some of the information there is wrong <ulfvonbelow>I've got 3 or 4 AMD GPUs that I can't use sitting around because of it <klm_>nice! never heard of h-node.org. <ulfvonbelow>worth noting that the intel integrated graphics might work decently <ulfvonbelow>at least the older stuff, my sandy bridge laptop works okay with linux-libre <jpoiret>though really, in general you shouldn't just expect binaries you downloaded from the web to just run on guix <jpoiret>didn't notice -F was shorthand for --emulate-fhs <Nathan-web>I'm actually using the flags I found from that page. This binary came as part of an npm package that I need. <Nathan-web>I just tried symlinking the library to /lib in the container, but it is a readonly directory :/ <jpoiret>you can try `LD_DEBUG=libs <your cmd>` <jpoiret>where is the lib if not in /lib? you mentioned you could find it <Nathan-web>In /gnu/store/1xm0kpx1q2i7dw1da4pgkd6s7raislgs-gcc-12.2.0-lib/lib/ <Nathan-web>The command you gave shows me that it is searching under various places in /gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ <cbaines>does anyone know about NTP and IPv6? It seems like 0.guix.pool.ntp.org doesn't support v6 <jpoiret>Nathan-web: you just mentioned that the lib is in the "lib" output of gcc, which isn't included in gcc-toolchain. You probably want to add gcc:lib to your shell invocation <Nathan-web>That got me on the right track though: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/gnu/store/1xm0kpx1q2i7dw1da4pgkd6s7raislgs-gcc-12.2.0-lib/lib/ allowed me to run the program. <jpoiret>if the library you want isn't included in the /lib of the profile `guix shell` built, it's probably because you haven't asked for it <Nathan-web>jpoiret: Oh, that works too. I didn't realize that it was in a different output. <ulfvonbelow>Nathan-web: note that you can make use of the --symlink option in setting up the container, e.g. guix shell --symlink=/lib=lib gcc-toolchain <jpoiret>the --emulate-fhs option already does all that <jpoiret>basically emulate-ghs is a glorified list of --symlink= options (with other tricks up its sleeve though, it's great work!) <Nathan-web>Thanks for the pointers. Using gcc:lib has definitely been the way to go. <willy-suspicious>Hi, I was wondering if anyone ever hit a segfault when adding a user to a group in guix? <civodul>willy-suspicious: hi! nope; a segfault of which command? <civodul>willy-suspicious: oh, i don't know this tool, but to add/remove users on Guix System, you should modify your config and run "guix system reconfigure" <civodul>changes made otherwise will be lost upon reboot <willy-suspicious>Thanks, I recently decided to daily drive guix. Very different to what I am used to. <nckx>mirai, lechner: Yes, and hence the full stop is part of the URL ('.png.' vs. '.png') and correct parsing gives 404. Using '<URL>.' avoids any ambiguity because '>' MUST be a separator. Whoever complained was using buggy software. That is all. <nckx>But enough about RFC 3986! <nckx>mirai: Whxcm file system was this? <bdju>is anyone working on getting QT6 working? I'm specifically wondering about qutebrowser using it but not sure if it gets upgraded for everything at once or per-package. I hear being on QT6 may help with the awful issue of getting stuck on failing cloudflare browser checks <bdju>I just mean qutebrowser isn't using it yet so I thought guix was behind <bdju>although now I'm also hearing that Qt6 isn't merged into master for qutebrowser yet anyway <nckx>IC. Well, feel safe. Cloudflare is here to protect you from terrorists by telling you which widget toolkits you may us. <bdju>I'd rather take the terrorists if I had the option <ulfvonbelow>the orwellian terminology they use drives me more insane than not being able to access the site. "Checking that the connection is secure". Ah yes, whether tls works or not really depends on whether you can push jshelter all the way to the "Extremely likely you were fingerprinted" level. I can't help but wonder whether giving a third party key material to allow them to decrypt the stream and tamper with it just *might* affect how secure <Schmoho>using guix as package manager on mint broke some of my applications that now try to look up libpthread in the gnu store?! <Schmoho>evolution: symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE <vivien>ulfvonbelow, with --no-grafts, I have 12 failed tests <ulfvonbelow>heh, that confused me for a while too. I think it's telling you that the subtest that failed was the twelfth one (apparently telling you the /name/ or anything else about it is far too sensible for it to do) <jpoiret>Schmoho: is GIO_MODULES set to something in Guix? <jpoiret>can you paste your `env` then Schmoho? <jpoiret>what specific programs run into this issue? can you launch them manually with `LD_DEBUG=libs`? <jpoiret>we've run into some sandboxing software once which was overriding the already-custom ld of guix <Schmoho>sorry for the stupid question, but how do I pipe the output in this case? `LD_DEBUG=libs evolution` cannot be redirected directly it seems <klm_>How can I disable the `amdgpu` driver? `modprobe.blacklist=amdgpu` in kernel-arguments don't seem to do the trick. <nckx>Does 2> not work for redirection? <nckx>Does unsetting GTK_PATH help? That's just a guess though. <nckx>Seems like the GIO...MODULES answer yesterday was just the easy mode. <Schmoho>I just purged all the evolution libs and reinstalled but its the same error too <nckx>Right, that should never help. <nckx>I'm clueless about where that nss/glibc reference could come from on a foreign distro. So far it was always treacherous Gio'. <vivien>klm_, try (kernel-arguments `(,@%default-kernel-arguments "modprobe.blacklist=amdgpu,radeon")) <vivien>In other words, try to blacklist both amdgpu and radeon <nckx>I don't know. You could check ld.so.conf or delete ld.so.cache but both feel pretty desperate. <nckx>There's probably some more obvious vector I'm just unaware of and I can't play around with an affected system to find it 🤷♀️ <nckx>If your disto's 'ldconfig -v' prints store file names, something's badly borked. <apteryx>I'm starting to look at 'guix pack -f rpm', and it seems I need to pass a list of files to cpio to create a cpio archive <sneek>apteryx, you have 1 message! <sneek>apteryx, antipode says: You could delay expansion by using 'local-eval', though it will get re-expanded each time, so not great for performance. <apteryx>what would the fastest way to list all the files found in a profile derivation output? <civodul>mirai: hi! yup, perfect; bonus points if you add an example ;-) <civodul>(for a profile or any other directory) <apteryx>OK! I was a bit tempted to (system "find profile | cpio -o my-archive.cpio") <civodul>(guix build utils) and (guix cpio) will serve you better i'm sure ;-) <civodul>i mean we even have a POSIX shell and a C compiler :-) <apteryx>so the rpm cpio payload should be taken care of; now to wreste with its binary metadata format <civodul>mirai: nice! perhaps either choose another IP address and call it "localhost" with no aliases though? <civodul>(there's an RFC specifying IP address ranges available for test/doc purposes) <mirai>I was thinking an example with aliases would be useful (to remind that they exist :)) <civodul>or you can have one for localhost, and one for something else :-) <apteryx>mirai: oops, I just merged your configuration->documentation bug erroneously <mirai>The default ones with the os host-name are already present so I'd prefer not to duplicate them again <mirai>or have conflicting 127.0.0.1 localhost; 192.x.x.x localhost; (<< not sure if it's even valid) <apteryx>wouldn't a change to meson build system cause lots of rebuild on master? I was looking at 34c7dd7e09 <apteryx>ah, it's only used by the meson-cross-build, so perhaps only cross-compilation would be affected, for which we'd have little substitutes <mirai>apteryx: sure it's a good idea to export the accessors for vnstatd #60788 ? <mirai>it will balloon the amount of exports <mirai>(they're directives present in vnstat.conf) <apteryx>perhaps they can be added later when someone requests to have them <apteryx>but typically we add them from the onset <mirai>I think not every service is doing this (atm) <civodul>anyone working on a blog post re FOSDEM? <mirai>you could in a rather inelegant way use (@ (gnu services ...) ....) to get access to them <apteryx>mirai: I guess leave this aside for now, or bring this into discussion to guix-devel <apteryx>in my book it should be public because otherwise users have no introspection capabilities into the records, and guix is supposed to be hackable <mirai>There's value in it though in most cases the records tend to be always crafted (not inherited from modules) <mirai>so in practice these accessors are very seldom used (I think) <apteryx>I used them when introspecting my system configuration <mirai>wrt least-authority-wrapper, how well does that interact with ifaces in other namespaces? <mirai>I'm worried that this may cause unexpected "missing counts/interfaces" in namespace using configurations <mirai>you can already imagine bug titles of the sort "why vnstat no show iface" <apteryx>the services do not run in a network namespace, per (default-namespaces) <apteryx>when using make-forkexec-constructor/container <mirai>right, but would putting it in a namespace cause interfaces that should be counted "not count"? <mirai>or at least, the expectation is that vnstat counts them all <mirai>if you get a namespace with its own iface <apteryx>if it's not in a specific network namespace, I'd expect it has access to all interfaces <apteryx>I'm not sure but I would but surprised if it didn't <mirai>I haven't used them yet so I'm not really sure what pitfalls it might have <apteryx>least-authority-wrapper uses '(cgroup mnt pid ipc uts user net) for its namespaces though, so it's more restrictive by default <apteryx>and i had found an issue with it when writing the jami service but I can't find it anymore <mirai>I'm seeing wesnothd for an example but how should I know which namespaces to delete? <mirai>(it's going to be a non-automatized slow 5 minute per attempt so combinatorial methods are not really feasible) <sneek>lechner, you have 1 message! <lechner>sneek / later ask antipode / Hi, was the openssl comment meant for ulfvonbelow instead? <mirai>lechner: patch 2/3 is doing more than it says <mirai>oh wait, nvm, the diff xfuncname was confusing <mirai>apteryx: I was thinking, isn't it technically better for the least-authority-wrapper to live outside of the service? <mirai>you could pass a wrapper with the package field instead <mirai>it makes it easier to "compose"? <apteryx>rekado: I'm impressed by how much MUMI has improved. Kudos to its contributors! <HexMachina>All, I'm trying to test out the latest version of GNU Make (4.4) using --with-latest, and getting an error validating the make-4.4-tar.gz.sig signature. Any resources for how to add a public key to guix? <HexMachina>I got as far as "guix archive --authorize" but can't figure out how to get the public key used to sign the make tarball into s-expression syntax <apteryx>rekado: if you find a fix to our Geiser issue (or open a bug about it) please keep me in CC :-) <georgezpalmer[m]>I'll help the community how earn $30k within 3 days and hours but you will reimburse me 10% of your dividend when you collect it. Note: only interested people should involve. <HexMachina>For anyone searching the logs later, I fixed my problem. I had to run `gpg --keyring $HOME/.config/guix/gpg/trustedkeys.kbx --no-default-keyring --import paulsmith.pub` to add a specific key to Guix's trusted keyring <HexMachina>at which point `guix shell --with-latest=make make` worked <HexMachina>It would be nice if the "--keyring" and "--key-server" commands supported by "guix refresh" could also be used by guix shell or anywhere else that package transformations options are accepted <vivien>The scammer has survived for too long <HexMachina>When I initially ran `guix shell --with-latest=make make`, it did ask me if I wanted to download the key DEACCAAEDB78137A for 'mirror://gnu/make/make-4.4.tar.gz', and I said yes, but then it gave me a gpg error for "keyserver receive failed: Server indicated a failure" <HexMachina>I had to manually search for the key used to sign the make release and found it at ftp://ftp.gnu.org/gnu/gnu-keyring.gpg <HexMachina>I had to manually download that keyring, export Paul Smith's key from it (one of the GNU Make maintainers), and manually add it to $HOME/.config/guix/gpg/trustedkeys.kbx to get the --with-latest transform to work <apteryx>mirai: I'm not sure what kind of composition you were thinking of <HexMachina>does this indicate a problem with how guix is validating keys for other GNU projects? Or was it expected that I needed to do something like this? <nckx>litharge: Take your speed and vitamins, please. <mirai>apteryx: I was thinking on letting the wrapper be a "opt-in" by passing it using the 'package' field <mirai>though even with my patch of "always use wrapper" doesn't work <nckx>HexMachina: Guix could at least respect the user's keyserver setting. It doesn't seem to do so, since 'my' keyserver has that key but it still doesn't work. I don't get your vague error, though... <nckx>(No, Guix doesn't check random ftp servers, even if it's GNU's. Not sure if it should.) <HexMachina>nckx: is signature verification only done for package transforms like --with-latest and --with-version? <HexMachina>Since normally a content hash is used for verification <HexMachina>nckx: is there a default keyserver that guix's gpg uses to try to download keys from? The error messages I was getting indicate maybe this is a yes but that the specific key used for the make release wasn't found there <HexMachina>or maybe there is some difference in behavior on Guix system vs using on a foreign distro (which I am doing - Ubuntu 18.04) <nckx>s/guix's // I'm sure there is. I don't know what it is nowadays. The network is in ruins. <HexMachina>nckx: Incidentally, I always appreciate how you respond to things, even if you don't always know the answer. Thanks! <nckx>I use keys.openpgp.org, which has that key, but I have no idea which one is being used here... No indication either... <HexMachina>The --with-latest is pretty cool, once I got it working :) <nckx>Well, I always intend to find the answer :-) Sometimes I even succeed. <HexMachina>I wanted to play with the new --shuffle argument in Make 4.4. It randomizes the order that parallel targets are built to flush out errors in Makefile where incorrect assumptions about target build dependencies are made <HexMachina>which seems like it would be useful for Guix as a means to find build system errors and sources for lack of reprodudibility <nckx>HexMachina: I don't think it's a distro issue. If I wasn't clear: it also fails on my Guix System, but just 'gpg' outside of 'guix ...' works. <nckx>HexMachina: Interesting! Most reproducibility hacks are costly; this one sounds very cheap. <HexMachina>yeah! Lots of makefiles have errors like that where a target will list prereqs like "mytarget: clean thing1 thing2 finalthin" and assume they are built in that order <HexMachina>which breaks when you try to run with "-j" to parallelize/speed things up <HexMachina>It's sad to see places in Guix where you have to disable parallelized building b/c of things like that <nckx>(configure:#define DIRMNGR_DEFAULT_KEYSERVER "hkps://keyserver.ubuntu.com") <nckx>Guix does not appear to override that. <apteryx>mirai: oh, so running the vnstat process in a namespaced fashion prevents it from collecting the data from the kernel? <nckx>HexMachina: Yep. I've even had to 'fix' packages (by removing -j) that were already in Guix. <nckx>So they made it through testing & review & still broke later. <apteryx>HexMachina: and keyserver.ubuntu.com is the default server used by gnupg nowadays <apteryx>perhaps you have a gnupg configuration file setting it to something else? <nckx>Pretty sure that's not it. <mirai>apteryx: yeah, though I'll send it as a separate patch (for anyone interested in trying further ideas) <HexMachina>also guix appears to consult both a $HOME/.config/guix/gpg/trustedkeys.kbx as well as $HOME/.config/guix/upstream/trustedkeys.kbx - what's the distinction? <nckx>Ah, I had to kill gpg-agent, my old nemesis. <nckx>HexMachina: Where? I don't have the latter at all. <nckx>Anyway, after killing gpg-agent all problems went away. Guix finds the right key on its own. <HexMachina>the later was just created by one of the commands I've run in the last 30 minutes but I'm not sure which one; it wasn't there the last time I opened up ~/.config/guix in dired XD <nckx>Well, I just mean it caches settings, so changing them during the run has no effect. But like apteryx says, you must (perhaps) have some forgotten setting overriding Guix defaults. <HexMachina>When I ran `guix refresh -u make` it gave me the key error and then prompted "Would you like to add this key to keyring '$HOME/.config/guix/upstream/trustedkeys.kbx'? <HexMachina>which I think then created that file when I said "yes" <nckx>Once I cleared mine AND killed the agent, that worked. <HexMachina>but then I still got "gpg: keyserver receive failed: Server indicated a failure" <nckx>No, because that's what I did too. <nckx>(Re: creating 'upstream') <nckx>Not a bad hypothesis tho'. <nckx>HexMachina: See, I never got that useless error message. It was (from memory) 'no such uid', which might be related to keys.openpgp.org design (but then why does a Web search for the FP work!?), but was at least a real error. <nckx>Could this be an error at the 's' level of hkps? Unlikely if https works for you. <nckx>But certs *are* something that could plausibly differ between our distros. <nckx>Without a real error I can but guess. <HexMachina>I've had issues with certs... I was in here a few days ago asking about how to set up a custom Root CA to get wget and git in guix to trust. I did get that figured out. I doubt that's related to my current issue though <HexMachina>I can run other commands if you are curious as to what's going on but I'm going to stop poking at it for now, since I was able to accomplish what I was trying to get done by manaully importing the key to ~/.config/guix/gpg/trustedkeys.kbx <nckx>I know enough about the bowels of Guix to tell people where to poke it over IRC. Not the case with GPG I'm afraid. <nckx>You could report a bug, but I don't blame you for wanting to get on. <HexMachina>I briefly looked at the --list-packets flag when I was trying to figure things out and I'm really glad I didn't have to try to understand that <shcv[m]>what's the preferred way to work with wifi when using emacs-exwm and guix-sd? <HexMachina>nckx: thanks. May not do this now, but there have been other issues I wanted to report in the past and never did <nckx>There's no mandatory format, the mail is read only by humans. Just empathise with them & try to provide as much useful info as possible. <HexMachina>but I gather from our convo already that you're already deeply familiar with the issue <nckx>HexMachina: So, not that, and you'll be fine. <nckx>HexMachina: Thanks! I am familiar with it, but the ways in which it can happen are sometimes very unintuitive, so all reading welcome. <sneek>Welcome back antipode, you have 1 message! <sneek>antipode, lechner says: / Hi, was the openssl comment meant for ulfvonbelow instead? <HexMachina>nckx: just ran into another issue trying to run `guix shell --with-latest=git git` <HexMachina>to try git 2.39.1, which was just released today I think and fixes several just-announced CVEs <HexMachina>and guix tries to download the source over and over from several different mirrors and keeps failing <HexMachina>for one thing, it keeps trying to download git-2.39.1.tar.gz, despite the fact that the current guix recipe for git 2.38.1 downloads a tar.xv file, and most of the mirrors are hosting the .xv version and not the .gz version <HexMachina>not sure why --with-latest would try to get a .gz when the existing recipe itself is for an .xz <HexMachina>and it actually does download the gz correctly for some mirrors that do have it, but then seems to ignore the results and keep trying from other mirrors <podiki[m]1>ieugen: I believe that is not an official channel (but probably overlap in people); note that you can use matrix to join the irc channel directly (which looks like you are doing so you know that already) <ieugen[m]>thanks podiki . Yes. Using matrix Element client. So I guess it is ok to ask a similar question here (I see more people) <nckx>HexMachina: The transformation system used here never uses the existing git package's source field. It is ignored in favour of (guix upstream) answer to ‘what is the latest version’ and ‘what is that latest version's tarball’? Note the absence of ‘…that looks the most like the old URL’ in that last bit, because there's (currently) not really a sane way to do so. <nckx>I'll be back at my laptop (♥) in <10 minutes, so I'll wait until then to see if it loops for me. <nckx>But the loop is not because Guix was supposed to look for a .tar.xz. <HexMachina>no but it seems like it downloades the .gz multiple times from multiple different mirrors but fails to process it for some reason and moves on to the next mirror <nckx>Sure, but eventually that list must end. What then? <HexMachina>I can let it go for a while and see what the eventual outcome is <nckx>I suggest you don't, for science. <nckx>ieugen[m]: This is the only ‘official’ chatzone :) Note that huge messages are not conventional on IRC like they are on Matrix. Taking up more than 3 lines or so of other people's screen is considered gauche; it's a cultural thing. The Matrix bridge turned your message into a link, which people will have to click, which will open their Web browser, to read your question. Many people will not do this. <nckx>HexMachina: Yeah, that's why I'm heading straight for the laptop :) <gnucode>nckx: Do you suppose it would be a waste of time to set up --shuffle for make by default on the guix build farms?