IRC channel logs


back to list of logs

<podiki>not sure about home reconfigure and if that means anything here
<podiki>different hash suggests something is different, but not sure what it might be in your case
<freakingpenguin>I suspect guix build catch2 is building catch2-3.5.1, but home reconfigure seems to be building 3.5.1-checkout. guix build catch2@3.5.1-checkout doesn't find that version though.
<rekado>use “guix build -S” to get the checkout
<freakingpenguin>rekado: Thanks, looks like my hypothesis is wrong. -checkout has another nonmatching checksum.
<podiki>...didn't boot. weird, seems boot partition is showing as mbr not gpt, though does seem marked as efi type... weird. guess gotta redo that partition
<apteryx>is anyone using jami on a computer that uses the nouveau driver?
<apteryx>it tears badly (video artifacts) for me, ever since it moved to Qt
<apteryx>I'm wondering if the problem affects the nouveau driver in general or my particular GPU
<loopback___>how to assemble an archive containing only the bootstrap seeds and the source code to compile a base system?
<loopback___>or can I get one somewhere?
<RavenJoad>How can I get and I currently have to resort to manually specifying the scheme variable/symbol for GCC and selecting its lib output? Why does gcc-toolchain not expose those two libraries in gcc-toolchain/lib/...?
<ulfvonbelow>at first I thought it was the crate importer messing up, but no, if you go to and look at the subtitle, it says "Minimal terminfo library". And then below it it clearly says that it's actually a diffing library, as the name would imply...
<adanska>Hi Guix! Is there any documentation regarding how you are meant to write a package with multiple outputs?
<efraim>what's the minimum I need to install to use a machine as an offload machine, just guix-daemon?
<apoorv569>None of my programs installed via guix home are showing in dmenu on both of my systems running Guix.
<apoorv569>dmenu is only showing programs installed via guix system.
<apoorv569>This started happening yesterday, I didn't change any env var or something like that.
<rekado>i686-linux is in pretty bad shape
<rekado>webkitgtk-with-libsoup2-2.42.3 fails because google-highway has failing tests
<futurile>Q: I have a <package> record, can you use `set-field` to change it's name, or do you always have to inherit it?
<futurile>(I'm just learning about records - so I might be getting the syntax wrong)
<rekado>Guix records are different.
<futurile>ah OK - I am reading Lepillers blog post about the Guix record
<adanska>what are some gexp-style packages that have non-trivial multiple outputs that i could learn from?
<rekado>adanska: mmg in (gnu packages graphics)
<civodul>i’ve renewed the certificate for
<civodul>still not sure what’s wrong with our certbot mcron job
<rekado>there are a lot of spurious failures on due to missing derivations
<rekado>e.g. kio, which takes all the KDE stuff with it
<rekado>also affected are a bunch of GHC packages
<rekado>I’ve only been able to manually restart a few of them
<efraim>zstd related failures on core-updates, for riscv64 and ppc64le
<allana>Hi #guix! I am having a little bit of trouble using inferiors from a manifest.scm. I have a local channel (file:// path) which I can build and install packages from. That works great. Now I have a manifest.scm which follows the example in the documentation (Inferiors), and it seems impossible for me to "pin" a version of my channel. I get an error when trying to use guix shell with the manifest: "Unknown # object: ("#<")" -- Any ideas?
<efraim>can you give a link to your manifest so we can see where you might have a syntax error?
<lilyp>you're probably using a gexp where they can't be used
<allana>I have tinkered in the repl and have not been able to make any meaningful progress. The procedure is (lookup-inferior-packages inferior "my-package")
<lilyp>that doesn't tell us anything
<lilyp>wherever you placed that, there's the problem
<allana>thanks, here's the manifest:
<peanuts>"debian Pastezone"
<rekado>what does that argocd-keeper-plugin package look like? Or the rest of that channel.
<peanuts>"debian Pastezone"
<allana>As for the rest of the channel, there isn't much. this is mostly for testing. I am following this blog post:
<rekado>can you show us the full error message? Which derivation is it talking about?
<allana>yes, thank you. here is the paste:
<peanuts>"debian Pastezone"
<rekado>allana: which of the mentioned “.drv” files contain “#<”?
<rekado>I’m getting 504 from ci when fetching substitutes
<rekado>e.g. guix substitute: warning: download from '' failed: 504, "Gateway Time-out"
<rekado>this only affects the zstd URLs
<allana>rekado: Not one of the ".drv" files listed in the output of the shared paste contain "#<"
<rekado>does /gnu/store/kdb66490kh18q73vzaaccyrg36qp9351-inferior-script.scm or /gnu/store/074lbwzzrlpd21ddxwl8sb7lhf96xbp6-guix-package-cache/lib/guix/package.cache contain it?
<allana>the package.cache does have that string a few times in it
<rekado>can you give an example?
<allana>I wasn't previously aware that it is a binary file. grep returns "binary file matches"
<rekado>oh, right. Ignore that then.
<allana>rekado: Thanks for your help. I'm stumped for now :-)
<cbaines>sometimes I turn to strace in these situations
<rekado>is argocd-keeper-plugin the *only* module in this channel?
<allana>yes, that's the only module. It's almost following the exact structure of shared in the blogpost that I linked previously. Except instead of the module being called guile-package it uses a different file/module name
<allana>And also it builds just fine, I can install it into a profile, I can "guix shell argocd-keeper-plugin" just fine.
<graywolf>peanuts: Where is your source?
<peanuts>graywolf: Hi, for comments please contact my maintainers at
<loopback___>I've tried filtering only .drv from guix gc -R, but I get "versions" like 1.1.1u.tar.gz when passing the store item name through package-name->name+version. Besides excluding ones with known extension like .tar.* and -checkout, are there other ways to get only the package derivation's package version? Maybe guix graph -t bag on a system derivation somehow?
<allana>so, my recent attempt at creating a custom channel, and then having a manifest.scm use inferiors to "pin" packages from a custom channel is not working for me. I know that I can achieve a similar result using time machine, but I am wondering, is there another way? Also, anyone know of any examples in the wild of people using inferiors to pin packages not just in guix, but from other channels?
<jonsger>ACTION added himself to the list of attendees for Guix Days
<jonsger>if there are still 40 places available, there are only 10 places left:
<peanuts>"Group:Guix/FOSDEM2024 - LibrePlanet"
<snape>allana: why wouldn't you just copy the package definition in your config.scm or manifest.scm?
<snape>that's what I'd do if I wanted to "pin" a package, although I'm not sure what "pin" means
<graywolf>Did anyone try to make a live usb of Guix, that would copy to ram on boot so I could take it out once the machine boots?
<graywolf>Is that possible?
<snape>maybe it means: "i want package foo when channel was at commit bar"
<allana>snape: thanks for the suggestion. Actually, I'm doing a bit of an exercise to see if it's possible. But in regards to including the package definition, that's a good idea. However there are several transitive dependencies that I also want pinned to a particular revision of guix along with the channel. Really, what I'd like to do is to have a "declarative" way to use guix time machine. It would be nice if I could get inferiors to do this
<allana>becuase it sounds like it's what they are intended to do. I think that I must be doing something wrong, but I also haven't been able to find examples.
<snape>allana: you can have a custom package in your config.scm, that inherits the official one, and changes its inputs, its version, etc
<snape>allana: there is an exemple in the docs that does something quite close to what you are talking about:
<peanuts>"Inferiors (GNU Guix Reference Manual)"
<allana>Yes, and I have almost duplicated that exactly. What I have added is a custom channel. It blows up for me when I do that.
<allana>Basically, I am combining that reference material with this guix blog entry:
<snape>so it works with the guix channel but if you replace it with another channel it doesn't work anymore?
<allana>thanks for the help. I need to step away for a bit :-)
<snape>kk well I didn't help much ;)
<allana>snape: the intention is to include guix and my custom channel
<snape>would be easier to help with a code paste
<below_turtles_>I'm guessing it's impossible to get a list of package names and versions required to a bootstrap an entire system derivation?
<cbaines>below_turtles_, what do you mean by bootstrap?
<below_turtles_>build from source, all the way down
<below_turtles_>I'm trying to get a list of packages and version so I can archive their sources for an air gapped system build
<fnat>Hi, in terms of setting up nginx+certbot, the manual would make me think that they integrate with each other seamlessly and there's no need for any manual intervention to generate the certs?
<cbaines>below_turtles_, the rigerous way to do that is to compute the derivation/derivations involved, then find all the fixed output derivations involved, and then build them
<fnat>But in reality this doesn't seem to work on my system, so I suppose it might not be completely seamless?
<fnat>This seems to point at an unresolved circular problem - although it's from some time ago, any chance there might have been any further development in the meanwhile?
<peanuts>"#46961 - Nginx and certbot cervices don't play well togther - GNU bug report logs"
<below_turtles_>cbaines: so get a list of derivations using something like ``guix gc -R $(guix gc --derivers /run/current-system)`` then find which ones are fixed outputs? And what does fixed outputs mean?
<cbaines>below_turtles_, guix build -d -S hello gives a fixed output derivation for example
<cbaines>in the outputs section of the derivation, it gives the hash of the output
<cbaines>so the derivation has a fixed output
<Kabouik>How can we work around the "guix shell: error: package `gcc-toolchain@11.3.0' lacks output `lib'" error when trying to have gcc:lib in a guix shell environment? I see gcc:lib in several places of the Guix manual but this seems obsolete, and the gcc-toolchain replacement of gcc doesn't seem to work with the same syntax.
<Kabouik> I see this should fix this, but how do people deal with the issue until this is merged?
<peanuts>"[PATCH 0/2] Fix and gcc-toolchain"
<jonsger>cbaines: congrats for the OpenUK honours list, if its you :)
<cbaines>jonsger, that is my name, but I've got no idea about OpenUK or what this is a list of
<graywolf>Is having / on LVM not supported under Guix? It seems to work, but I just want to check if there are any known issues...
<futurile>cbaines: it's essentially an industry lobby and networking group for 'open source' - people and companies: think 'Linux foundation' but on a smaller scale.
<apteryx>pkill9: not sure if you're still using jami, but I just pushed a commit that resolves video issues
<jpoiret>graywolf: it should be
<apteryx>(the ffmpeg-jami library could not read /dev/video0 in my testing due to a missing muxer)
<graywolf>jpoiret: Good to know, thx. I ran into a comment stating otherwise, so I just wanted to make sure it is no longer true.
<jpoiret>graywolf: what comment?
<jpoiret>there's the LUKS2+GRUB problem, which will be hopefully resolved by upgrading to 2.12
<graywolf>;; Since LVM support in guix currently doesn't allow root-on-LVM we use /home on LVM
<graywolf>In the file specifing system tests
<graywolf>(How do I copy current file name in emacs? :D)
<jpoiret>ah, you might have trouble in degraded mode though, Guix might refuse to boot
<jpoiret>graywolf: (kill-new buffer-file-name)
<graywolf>Ah, so: gnu/tests/install.scm
<dthompson>civodul: do you foresee any issues with bumping guile-gnutls to the latest version (4.0.0)?
<dthompson>just realizing that all the new bindings I added that I think ended up in the 3.7.13 release are still not in guix
<dthompson>the NEWS file doesn't show any groundbreaking changes
<peanuts>"NEWS ? v4.0.0 ? gnutls / Guile-GnuTLS ? GitLab"
<civodul>dthompson: i bumped it in ‘core-updates’, maybe you can just cherry-pick it
<civodul>it should be fine
<civodul>(i should have done it in master)
<dthompson>even though git-download etc. use it?
<dthompson>I'll cherry pick it then
<dthompson>thank you!
<civodul>well, run “the libreoffice test” :-)
<civodul>./pre-inst-env guix build libreoffice -n
<civodul>as long as there’s no world rebuild, we’re good
<dthompson>hahaha first I've heard of this test
<dthompson>seems like a good one
<dthompson>will try
<cdo256>Hey Guix, I'm trying to package a evhz which is a single C file, using trivial-build-system. However, whenever I import the module (gnu package commencement) (for gcc-toolchain), I get errors about unbound variables, see here
<graywolf>Speaking of libreoffice, there is this patch #68150 fixing a crash...
<peanuts>"[PATCH 0/8] Fix usage of glib-or-gtk-build-system"
<civodul>ACTION send an update on ‘core-updates’
<apteryx>jpoiret: is there a GRUB 2.12 release already?
<jpoiret>yes, in december
<jpoiret>i have to clean up my work but i'm running it
<jpoiret>trouble is I also modernized the various grub packages and so now I need to sort everything into separate commits
<apteryx>magit party time
<apteryx>it's usually better to split the work in commits as you do it to save you some work, but I understand, I've been there.
<dthompson>civodul: not that I do much around here these days but I'm a +1 to merging core-updates
<dthompson>(still gonna cherry pick the guile-gnutls update tho)
<jpoiret>I'm currently building c-u as we speak
<jpoiret>i have a couple of patches on top of it
<dthompson>civodul: looks like I need to modify the patch to avoid deleting gnutls-cross.patch since gnutls in master still uses it.
<dthompson>that okay?
<dthompson>hmm, the guile-gnutls test suite fails in master. guess we need to wait for core-updates...
<futurile>cdo256: did you follow this section of the manual:
<peanuts>"GNU Guix Reference Manual"
<dthompson>civodul: on the flip side... upgrading to 3.7.14 on master works fine. would that be okay for now until core-updates is merged?
<apteryx>dthompson: note that gnutls is grafted to 3.8.2 on master
<dthompson>yeah I think the version difference could explain the 4.0.0 incompatibility
<civodul>ah right, worth checking
<dthompson>3.7.14 builds fine
<dthompson>3.7.13 and 3.7.14 just add new bindings
<cdo256>futurile: Yes, I did. I ran ./bootstrap, ./configure --localstatedir=/var and make It compiled and ran fine on master with no changes. I then added (gnu packages commencement) to gnu/packages/xorg.scm and ran make -j15 (I also tried running make clean first) then running `./pre-inst-env guix build` on any package results in the output with the error I uploaded. I imagine it's clashing somewhere. I'm going to try putting it into a
<cdo256>different file and see if that makes a difference.
<graywolf>civodul: In the unlock by key-file review you mentioned a system test. I think they are failing even on master, bug I do have a test. Can I just put it into a separate commit on the key-file patch, or should that be a completely separate patch?
<graywolf>I am unsure how much bundling do reviewers accept...
<graywolf>do have a fix*
<graywolf>cdo256: cdo256_: You are missing --sysconfdir, I would recommend following the latest documentation:
<peanuts>"Building from Git (GNU Guix Reference Manual)"
<graywolf>(or just run: info '(guix)Building from Git' to read version for your installed guix in the info reader)
<graywolf>(it is probably unrelated to your issue)
<cdo256>Ah my bad, I'll go through these steps again. Thanks!
<dthompson>civodul: the libreoffice test passes. only shows grafts. is there any other test that you do to make sure that guile-gnutls seems to work properly?
<civodul>dthompson: if it builds with the version that’s current in master, it should be fine
<dthompson>civodul: libreoffice, you mean?
<dthompson>it builds.
<rekado>I’d like to merge wip-easyeffects-62771 soon.
<civodul>dthompson: i mean guile-gnutls itself, but i guess you checked that already :-)
<rekado>is it possible to restart many builds at once?
<rekado>lots of ghc-* packages are broken right now, because of bad builds like this:
<peanuts>"Build 3074323"
<civodul>depends, are you SQL-savvy? :-)
<rekado>I have used a search engine before, so I guess the answer is “maybe”
<civodul>this build is marked as “Submitted”
<civodul>so it’s going to be picked up eventually, no?
<civodul>(i guess it’s already been restarted?)
<rekado>yes, but also with negative time
<rekado>negative duration
<rekado>just restarted it and now duration is positive again
<rekado>this leads to lots of “dependency failed” builds
<dthompson>civodul: yeah I did
<dthompson>okay I will get ready to push this then :)
<dthompson>pushed :)
<dthompson>thanks for the help civodul
<dthompson>we might be preparing a release over at spritely hq or something ;)
<podiki>rekado: i had been doing a lot of restarting builds manually on mesa-updates in the last few weeks, no idea why. either just fails mid-log or "couldn't build missing derivation" a lot
<civodul>dthompson: ooooh!
<podiki>so my guix system init on a disk doesn't boot, but just tried the installer and it does make a bootable install
<podiki>i swear i did the ESP partition correctly (twice!)
<podiki>where is the installer's partitioning script?
<podiki>ah gnu/installer/parted.scm i'm guessing (or at least where to start)
<civodul>cbaines: just so you know: i’m using a lot of disk space on bayfront where i download hi-res copies of the videos of the event in Montpellier
<civodul>i’ll try to move them elsewhere eventually
<podiki>so the installer keeps the ESP if it exists, let me double check if it kept mine, but that would mean whatever was causing machine to not see a bootloader was not from ESP?
<podiki>are there any gotchas when installing a system from another by just "guix system init" its disk?
<podiki>looked like it installed bootloader fine
<cwebber>so, and now for something slightly different
<cwebber>I'm downloading the latest nightly build of Blender
<cwebber>just to test it
<cwebber>I wasn't sure it would work on guix but surprisingly, both in the nightly and in the latest release binary builds, I get
<cwebber>cwebber@catnip:~/programs/blender-4.1.0-alpha+main.d0359d066db9-linux.x86_64-release$ ./blender
<cwebber>bash: ./blender: No such file or directory
<cwebber>blender is right in the directory and executable
<podiki>a binary build won't work generally, it will try to use an ld loader that isn't on guix system in "usual" spot
<cwebber>I've never seen this before, where an executable is in a path but literally bash says it isn't when I try to run it
<cwebber>podiki: that makes sense
<cwebber>I figured it might not
<podiki>you can try with the fhs container guix shell -CF though needing all the packages and some set up
<cwebber>but I'm confused by the "no such file or directory" part
<cwebber>that *bash* would say it
<podiki>yeah, that message is from not finding the ld loader
<singpolyma>No such file or directory usually means it can't find an so
<cwebber>is the really confusing thing
<podiki>if you do maybe an strace you would see that
<cwebber>I didn't know that!
<cwebber>thanks podiki, singpolyma, helpful!
<civodul>hey cwebber!
<podiki> for some examples if you want to try
<civodul>‘guix shell -CF’ FTW! :-)
<cwebber>lemme give that a try...
<cwebber>I haven't tried it yet
<dthompson>gotta emulate that fhs
<podiki>note that for libstdc++ (if i remember) you need -e '(list (@@ (gnu packages commencement) gcc) "lib")' since the package is hidden currently and we haven't changed the gcc-toolchain
<civodul>great stuff by podiki
<cwebber>ty podiki!
<cwebber>ACTION throws sparkles everywhere
<dthompson>yeah nice job on that podiki
<cwebber>not glitter though, that stuff is tough to clean up ;)
<dthompson>something I hadn't considered when I wrote with call-with-container
<podiki>hey thanks everyone!
<cwebber><-4.1.0-alpha+main.d0359d066db9-linux.x86_64-release [env]$ ./blender
<cwebber>./blender: error while loading shared libraries: cannot open shared object file: No such file or directory
<cwebber>okay so is the right thing to do at this point to start adding things to the shell
<podiki> is the bug in question, I should just propose a new patch there to resolve this gcc:lib thing
<peanuts>"[PATCH 0/2] Fix and gcc-toolchain"
<cwebber>or is that not an option
<cwebber>I suppose I should read the docs ;)
<podiki>i have some tricks in that blog post to get most things working
<podiki>cwebber: essentially yeah, just adding stuff needed to the container. and setting up some environment from the host usually (for things like display)
<dthompson>having guix for 10 years I feel like I don't need to read the docs... then I realize I haven't paid as close attention as I used to and in some ways I'm a noob again
<dthompson>having used guix*
<podiki>yeah sometimes I'm like "surely i know this" and then read the docs and learn so much
<podiki>sometimes for the second or third time, but brains are tricky
<podiki>has anyone had issues running "guix system init" from a guix system to another path (e.g. disk mounted somewhere) not booting? all looks good but system doesn't see a bootloader (efi; using from known working config, shows efi copied to where it should be)
<cwebber>podiki: great, thank you!
<futurile>Q: is there any way to see if a patch has been applied to a build? My transformation builds a package, but I can't figure out how to check if the `--with-patch` was actually applied
<futurile>(can't see it in the build derivation, or in the source derivation)
<cwebber>also on that note
<cwebber>I submitted some patches to update Blender to the LTS release if anyone wants to peek at 'em ;)
<cwebber>but I'm really eager to try out the 4.X stuff. Blender is moving so fast! I'd love to figure out a guix shell configuration so I can compile the latest git stuff and track their main branch
<cwebber>so much to do!
<cwebber>what happened to gcc:lib, is there an equivalent?
<cwebber>./blender: error while loading shared libraries: cannot open shared object file: No such file or directory
<dthompson>does that lib exist in your container? do you need to LD_LIBRARY_PATH it up maybe?
<podiki>See my message above, it is hidden package now so need -e '(@@.... (Sorry on phone)
<cwebber>sorry I missed it when you said it podiki !
<cwebber>waiting on guix pull to finish while building containers which are applying grafts while leaving blender rendering in the background all day, I'm giving my computer a workout
<cwebber>hey it's running!
<cwebber>~/latest-blender-dir$ guix shell --container --network --emulate-fhs \
<cwebber> --development blender libxkbcommon libsm \
<cwebber> -e '(list (@@ (gnu packages commencement) gcc) "lib")' \
<cwebber> --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \
<cwebber> --preserve='^DBUS_' --expose=/var/run/dbus \
<cwebber> --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \
<cwebber> -- ./blender
<cwebber>that works :)
<podiki>No worries, glad it works!
<futurile>cwebber: you could also try a transformation to grab and compile the latest so from inside the shell: guix build --with-latest blender (or --with-git-url etc) - if you want to stay on the bleeding edge
<cwebber>futurile: hm, would that work? I would be surpised
<cwebber>especially because the blender 3.6 patches I sent required changing some dependencies
<cwebber>cool to know about those options though, I had never seen them
<futurile>cwebber: If you're doing something complicated with dependecies then definitely not - but if you want to to build a later version of an upstream and it's simply later source they work
<futurile>cwebber: I've been playing with them for the last week - so when you have a hammer it's the solution to every problem heh
<podiki>Transformations are the best, along with guix shell
<podiki>My faves
<rekado>FYI: select count(*) from builds where stoptime<starttime; returns 139 rows in the cuirass db.
<cwebber>futurile: :)
<cwebber>I've been out of the guix zone for a while, spritely has been so busy
<cwebber>but that's gonna change >:D
<cwebber>2024 is the year of guix + spritely >:)
<ieure>Awesome! Very excited.
<ieure>Guix in the browser JS console?
<rekado>ACTION restarted 35 builds with: update builds set status=-2,starttime=0,stoptime=0 where stoptime<starttime and status=-3;
<jess>whoa cwebber spotted
<cwebber>whoa jess spotted
<cwebber>jess: I didn't know you were into guix
<cwebber>jess: also will you be coming to fosdem?
<cwebber>would be cool to meet IRL
<jess>i dont use guix but i think it is cool, and i am still deciding on fosdem or not. i will definitely tell you if i do go
<cwebber>jess: yes pls do!
<rekado>ACTION restarted all ghc-* builds on x86_64 that are marked as dependency failed
<civodul>rekado: dependents of newly-succeeding jobs are automatically restarted, if you see what i mean
<civodul>that is, if B initially failed, has been restarted, and now succeeds
<civodul>anything that depended on B is restarted
<civodul>(there’s no A in this story)
<rekado>I’m not sure if this really works in all cases, though
<rekado>I had a package that had all its dependents fixed but it was still in “dependency failed” status
<civodul>hmm weird
<podiki>i've seen it be a bit slow to pick up the build too
<podiki>but maybe that's just when things were generally slow on berlin
<rekado>yeah, that was fixed with vacuum
<podiki>messy messy computer, leaving crumbs everywhere
<podiki>anyone know why a "guix system init" doesn't produce a bootable system? seems uefi bios doesn't find ESP to load (grub). though partition is there, guix happily wrote a bootloader...
<ieure>podiki, Sounds like similar issues to what I was having last week. I posted on help-guix, but haven't had a chance to follow up.
<ieure>I don't know what the issue is, it seems like the bootloader gets installed, but the BIOS isn't finding it.
<ieure>Unclear why.
<ieure>I get the same behavior from `guix system init' and the installer, though.
<podiki>i thought it was all the bios security stuff (got a used computer that tends to have that)
<podiki>but guix installer made a nicely bootable system on same disk just fine
<ieure>Secure Boot?
<podiki>right, different here since installer installs
<podiki>and re-used my ESP too
<podiki>so partition is correct
<ieure>Yeah. Secure Boot is disabled for me. I don't think Guix signs anything, because it can't be done without a private key held by a third party, so it'll never support Secure Boot.
<ieure>Unless you want to provision your own keypair and sign the payload yourself.
<guestinator>hi guix, how can I put a local file in the store and then get the path string immediately?
<guestinator>I need to get the contents of the file as a string like so: (call-with-input-file (local-file "../file") get-string-all)
<graywolf>Are system tests run in the CI? I am surprised some of them are just.. broken.
<guestinator>I guess I don’t really need the file to be put in the store, but I do need a relative path based on the path to the guix module rather than the current working directory when guix is executed
<podiki>secure boot is off, everything "secure" is off
<ieure>podiki, Have you compared the contents of the ESP between the two install methods to see if anything obvious jumps out?
<podiki>might need to do that next, that's an idea
<podiki>but both just have the single guix efi file if i remember
<guestinator>ok, I think I don’t need guix for this:
<guestinator>makes sense, since I ultimately want a string and not a file
<ryblade>podiki: just taking a stab in the dark here, but have you cleaned out any old UEFI boot entries? sometimes it can get full, there's a tool for managing and cleaning up those entries but i can't remember the name of it, it's been a few years.
<ieure>In my case I have none, at least, when I boot the machine, the only thing in the menu is the internal SSD itself.
<podiki>ryblade: thanks, I can check. but installer media boots _and_ makes a bootable system. but my guix system init (from a running guix machine) doesn't. so i would think i'm doing something wrong but i can't see what
<podiki>the relevant config stuff is the same other than 'fat vs 'fat32 in the boot/efi filesystem...hmm let me check
<podiki>in my (device (uuid "..." 'fat compared to (booting config) 'fat32
<podiki>but from my reading of gnu/system/uuid they should be equivalent
<rekado>ghc stuff looks much better now at
<rekado>civodul: an example is; I had just restarted r-r-methodss3 and waited for it to be completed successfully, but the build of r-r-oo-1.25.0 is not being retried automatically.
<peanuts>"Build 3068059"
<podiki>ACTION tries guix system init again...
<podiki>sneek: later ask apteryx did you have a chance to figure out anything about the check2 failure for i686?
<podiki>.... and it works
<podiki>I did nothing different! Installer maybe fixed something on esp partition? No idea
<rekado>looks like it’s just a little slow to resume resumable builds; and db-update-resumable-builds! doesn’t reset starttime and stoptime to 0, so it looks wrong.
<podiki>So it works just takes time and looks wrong?
<rekado>yes, seems so
<rekado>it checks for resumable builds every 30 seconds, but the query takes some time too
<rekado>only about 3 genuinely failing GHC packages now
<ieure>podiki, heisenboot!
<apteryx>podiki: not yet, but it's on my mind! (apologies, single thread
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, podiki says: did you have a chance to figure out anything about the check2 failure for i686?
<rekado>we’ve got a bad gexp here:
<apteryx>master branch?
<rekado>efraim: I think that’s because of
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<apteryx>rekado: must be cause llvm-9 is now using gexps
<rekado>llvm-12 uses gexps but all the packages that inherit from it don’t
<podiki>apteryx: no worries, i'm behind since i just now got my new (well used but new to me) server booting for unknown reasons
<rekado>we should have a hackathon to investigate failed builds on master
<rekado>restart bad builds, fix little bugs
<apteryx>since registering to cuirass notifications (info '(guix) Cuirass Build Notifications') I've been trying to restart all newly failed builds that failed for bad reasons (e.g. #54447)
<peanuts>"cuirass: missing derivation error"
<apteryx>or open actual guix bugs for actual failures that need investigating
<rekado>apteryx: we could likely automate this.
<rekado>get all logs for all failed builds and check the tail for certain messages
<rekado>ACTION unblocks some java builds in cuirass
<rekado>ACTION looks for a SQL query to find the most impactful build failures
<apteryx>rekado: yes!
<apteryx>better than a human bot
<apteryx>in the meantime of finding the root cause for the bug
<graywolf>is there a way to exclude a system test from `make check-system'?
<f1refly>Can I use tkinter to create guis with python on guix?
<f1refly>When I run `python3 -m tkinter` it gives me a ModuleNotFoundError "If this fails your python may not be configured to Tk"
<graywolf>f1refly: You need to install python:tk
<f1refly>ah, okay
<f1refly>that explains why I couldn't find it with guix search
<graywolf>Yeah in `guix search python' notice the `outputs' section of the python package :) np
<guestinator>turns out `current-filename` is unavailable (returns #f) when building a guix home environment. so now I am back to wondering how I can put a local file in the store and get its contents as a string
<graywolf>guestinator: What do you mean "but a local file in the store and get its content"? If you know the file, cannot you just read it? Why put it into the store>
<guestinator>graywolf: I want to refer to the file with a path relative to the guile module I reference it in, but (current-filename) returns #f when executed by guix
<guestinator>so yeah, I don’t strictly need to put it in the store, but I can’t figure out how to do this via just guile
<graywolf>I am running guix reconfigure and friends with `-L .', and then using (search-path %load-path "some/file/I/need/to/find.scm) to find the "root" of the git repository.
<graywolf>Bypassing the (current-filename)
<graywolf>Maybe you could use something similar
<graywolf>(And canonicalize-path is useful to get an absolute path),
<guestinator>this relative path goes up directories as well, so that seems error-prone if it searches the whole load-path. I can try it though
<guestinator>since it’s for a non-scheme config file I need the contents of
<guestinator>well, it does work. I should definitely figure out how to change this service element to take a file-like object instead of a string though…
<guestinator>thanks graywolf!
<graywolf>Once you have the path, you can put it into the store using (local-file the-abs-path), where to go from there depends on what you need exactly
<graywolf>sure np
<guestinator>oh well local-file works fine with relative paths
<guestinator>my issue with the gexp/store route was I couldn’t figure out how to evaluate it
<guestinator>graywolf: I tried #~#$(local-file "../../../config/userchrome.css") (gexp and ungexp lol) but that didn’t work
<guestinator>since I need the store path for the host code rather than within the gexp
<guestinator>to read the store path to a string
<guestinator>(read the store path’s file contents to a string)
<guestinator>I am very new to gexps though so I’m probably missing something
<graywolf>Sorry time for dinner, but in general I do not understand why you need it both in store and to have a string from it. You either need the content, so just read it, or you need to reference it by something, and in that case you just want to generate something that contains the path itself, no? Maybe if you have some example of what you are trying to do to share.
<apteryx>weird, origin...TAB stopped working
<guestinator>yeah, I do just need the content. I just figured putting it in the store anyway would be cleaner than searching the load path, but maybe not
<apteryx>at least inside a yasnippet expanded package...TAB
<apteryx>it works if I don't interrupt the template and TAB through until the origin form. strange
<podiki>sneek: later tell apteryx I didn't have a chance to find out more about check2, should we just disable on i686? my working local diff
<sneek>Will do.
<peanuts>"debian Pastezone"
<rekado>ACTION merged wip-easyeffects-62771
<apteryx>podiki: if it looks like an upstream problem, we could report it there, then figure out how to disable the test, ideally
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, podiki says: I didn't have a chance to find out more about check2, should we just disable on i686? my working local diff
<peanuts>"debian Pastezone"
<podiki>i only tried the simple thing of removing a test from the cmake file
<podiki>but then the total tests are different and seemed there was some baseline it is compared to? i'm not sure
<podiki>i can try again later to see
<apteryx>podiki: you could use ctest -E some-test-name
<apteryx>to exclude it by regexp
<apteryx>there are other packages overriding the check phase calling ctest directly
<podiki>actually not even sure what test actually fails now, since it is in the same group as a bunch that are expected fails but the output doesn't tell me which is expected
<podiki>have to run for now but i can try to look tomorrow
<apteryx>ok! o/
<apteryx>gnu/packages/crates-io.go takes ages to byte compile