<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>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
<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>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.
<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)
<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
<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.
<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'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
<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)
<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
<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>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.
<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>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.
<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?