IRC channel logs
2024-05-27.log
back to list of logs
<gues37832>does anyone know why zathura can find plugins when running in `guix shell' but not when installed in the normal profile <freakingpenguin>jpoiret: So it looks like stumpwm is grafted twice differently depending on if it's from guix build stumpwm vs. guix build sbcl-stumpwm-cpu and the path to the grafted stumpwm is what's put in 50-stumpwm.conf. <freakingpenguin>is mappings reflective of old-outputs? i.e. mappings = paths found by scanning the entries in old outputs <freakingpenguin>I'd guess that's because stumpwm-contrib only depends on stumpwm's lib output, but this feels odd. Are other packages that depend on, say, A:lib grafting their own copy of A:lib that's distinct from grafting A:out and A:lib? <efraim>fun times, my fix for building gccgo@12 on powerpc broke building gccgo@12 on riscv64 :/ <efraim>it looks like it still works for gccgo@13, might just be best to change the gccgo used for bootstrapping and expand the note <taeaad>After I do, "guix import pypi numpy", do I need to do "guix install <x>"? What is x? <taeaad>I suppose the answer is "guix install python-<x>"? <taeaad>The import part is just to make sure it exists as "python-numpy"? <ayatsfer>is there any reason why --with-configure-flag is not mentioned in the manual? <efraim>ayatsfer: perhaps in package transformations? <efraim>I know I chose gccgo@12 since it built on riscv64 but it doesn't seem to now, wasn't too thrilled to see I broke it myself <efraim>before I push a fix I'll need to see which other architectures actually use gccgo to bootstrap go and which ones use gccgo instead of go and see what builds and what doesn't <jpoiret>freakingpenguin: looking at your email, there's another possible solution (although probably more complicated): fixing grafts :) <jpoiret>anyway know how I can use `guix git authenticate` along with worktrees? i'm getting the following: guix git: warning: could not record introduction and keyring configuration (Guile-Git too old?) <jpoiret>guix git: warning: cannot determine where to install hooks (Guile-Git too old?) <jpoiret>janneke: are you still having the function not implemented issue? <janneke>jpoiret: yes; i haven't looked where it may come from <mgd>I'm running an installation on another machine and it's stopped at the "this may take time..." screen for about 40mins. The last 2 log messages are about Bluetooth (I assume drivers?) failing to be loaded and read. The machine is a ThinkCentre M920s <mgd>I think I've fixed it. had to disable UEFI boot. <jpoiret>janneke: does that happen just in `./pre-inst-env` or also in `guix shell -D guix -- ./pre-inst-env`? <ngz>What would be the Bash meaning for: if test ${some_variable+y}, in particular the "+y" part, which doesn't seem to be part of the variable name? <ngz>I guess this is some fancy Makefile stuff in the package <FireFly>ngz: evaluates to y if $some_variable is null (empty), otherwise $some_variable <ngz>FireFly: Thank you for enlightening me. <FireFly>so in this case I guess the test would basically check whether the variable is set <ngz>Indeed. I get that part now. <Guest68>Did the font named 'NotoMono' get removed from the package `font-google-noto`? <Guest68>In fc-list, I can see NotoSerif and NotoSans, but not NotoMono. <Guest68>My apps started throwing "Font not found" for NotoMono. If I switch the name to NotoSans, no errors. <freakingpenguin>jpoiret: True enough! I can't figure out how that could be done without reverting 482fda2729 and breaking #24886. I guess if each output graft was a unique derivation that would be a solution. <Googulator>Is this a known issue with recent i386 (32-bit) installer images? "ice-9/boot-9.scm:1685:16: In procedure raise-exception: Unbound variable: ptional" (sic) <Googulator>This appears when booting the ISO, and is followed by a kernel panic <Googulator>Happens with both the image I've just built, and the one downloaded from CI <efraim>looks like 'optional' without the leading o. that's not going to be fun to track down <jpoiret>a simple [^o]ptional didn't find it :( <Googulator>I did "grep -Ir ptional . | grep -vi optional | grep -vi exceptional | grep -vi transcriptional" on the Guix source - no results <Googulator>I'm guessing it's somewhere else (Shepherd maybe?) <Googulator>interestingly, x86-64 ISOs from CI work just fine <Googulator>(can't yet build x86-64 ISOs myself in the bootstrap environment, because we use a 32-bit kernel currently) <efraim>was that while building the installer image? <Googulator>No, the image builds fine, but when I boot it in a VM or on actual hardware, it throws this error <FireFly>maybe it isn't a verbatim 'ptional' but rather somewhere that cuts it off by extracting a substring <FireFly>which would indeed make it "fun" to debug <Googulator>(btw, yes, that's a 32-bit installer image successfully built in a live-bootstrap bare metal environment, meaning that the underlying Linux kernel is also bootstrapped) <efraim>I wonder if it could be related to the e2fsprogs vs grub ext4 features mismatch we had for a little <efraim>anyway, I'm running the %test-iso-image-installer test to see if that shows anything <pkill9>is it possible for guix to be much faster? Or does it's non-lazy-loading cement the sluggishness? <meaty>did the epic5 package work for anyone else? I think it's broken <erikeah>I think the problem is very simple to solve but I'm not so proficient on guix gexp and guile to solve it <erikeah>But I spent almost all the weekend on this 5 lines and I've not more ideas. <graywolf>Hello :) Any idea how to use guile 3 in the tests/gexp.scm? <graywolf>All the tests are using %bootstrap-guile, which is version 2, but I need version 3 to test behavior I care about. <Kolev>raghavgururajan: welcome, Guique! <tty9-mm>I am trying to rsync into a machine running Guix System (from MacOS) but I get "rsync: command not found". rsync is available to the user on the target machine with `guix install rsync` and also prefixing the install with `sudo -i`. I assume I'm messing something up with profiles but I'm not sure what? <tty9-mm>It works if I rsync from the same client into another Guix System machine that I use rsync with a lot. rsync isn't in system.scm on that machine so I'm not sure how I've gotten rsync into the correct profile there. <tty9-mm>Fixed. My custom .bashrc didn't source /etc/profile for non-interactive shells. See /etc/skel/.bashrc <cbaines>civodul, I've had a look at the problematic Cuirass query and sent what I think is a faster version <cbaines>... before you partition the database <cbaines>73G is nothing, data.guix.gnu.org is a 800G database and the build coordinator on bayfront is a 55G SQLite database on hard drives <cbaines>civodul, and only 160G is lzipped derivation source files <brendn>Hello I have messed up my home some how. Every time I run guix home reconfigure I get an error: error parsing derivation `/gnu/store/xxxxx.drv': expected string `Derive(['. I have tried rolling back home and system and it still persists. I've run guix pull and guix system reconfigure which runs fine but does not fix the problem. I ran sudo guix gc --verify=contents,repair and a lot of the packages in the store have been modified and <brendn>cannot be repaired. Does anyone know how I can fix this? <cbaines>brendn, what about /gnu/store/xxxxx.drv does the contents start with Derive([ ? <brendn>cbaines, no it appears to be empty. A lot of the hashes I saw from the guix gc command were the same so I'm assuming most of the store files are empty. I have no idea why this happened but I'm not sure how to force all the packages to rebuild <cbaines>brendn, I'd try running guix gc (without arguments) <cbaines>that might remove the derivation file so that it can be recreated