IRC channel logs


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>Example build commands and the two stumpwm-graft builders
<peanuts>"debian Pastezone"
<peanuts>"debian Pastezone"
<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?
<freakingpenguin>Yep, this seems to likely be the problem.
<peanuts>"Redundant library grafts leads to breakage"
<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>hello guix!
<ayatsfer>is there any reason why --with-configure-flag is not mentioned in the manual?
<efraim>ayatsfer: perhaps in package transformations?
<jpoiret>efraim: playing whack-a-bug? :)
<efraim>basically. we're doing really well on aarch64 and I was looking at riscv64 again
<peanuts>"Branch master Guix Quality Assurance"
<peanuts>"Blocking builds - Revision 0f3a25a Guix Data Service"
<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
<FireFly> it's a POSIX sh thing
<peanuts>"Shell Command Language"
<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.
<peanuts>"Grafting triggers a download of all the outputs of each derivation"
<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>that sounds like a typo
<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 :(
<FireFly>\<ptional ?
<FireFly>might be at the start of a line
<jpoiret>doubt it, there's indentation
<efraim>not #optional
<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?
<erikeah>Hi everyone!
<PurpleSym>efraim: Ah, I see you downgraded e2fsprogs. I just pushed a fix for grub:
<erikeah>I'm on a hard time with gexp, and I hope anyone here could help me :)
<peanuts>"debian Pastezone"
<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.
<raghavgururajan>Hello Guix!
<raghavgururajan>(it's been a long time)
<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, is a 800G database and the build coordinator on bayfront is a 55G SQLite database on hard drives
<civodul>cbaines: oh, thank you!
<cbaines>civodul, and only 160G is lzipped derivation source files
<cbaines>nearly 300G is indexes though
<civodul>interesting figures
<civodul>ACTION looks at the query
<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