IRC channel logs


back to list of logs

<nckhexen>(I am running 1.0.9 here, although I never encountered said segfault with older versions.)
<apteryx>can I disable gnupg verification with 'guix refresh' ?
<apteryx>I just want to do a quick test on a remote server where gpg is not configured
<apteryx>mirai: it's nice we have a 2nd implementation out tEre for srfi-64
<Jindam>is there any workaround to use in proot-distro debian. when run guix install gimp, it shows
<Jindam>"guix install: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory"
<apteryx>looks like guix-daemeon is not running
<apteryx>is it?
<Jindam>warning: daemon is running as root, so using `--build-users-group' is highly recommended
<apteryx>how did you install guix? the install script ( should install services for the daemon automatically
<apteryx>I'm not sure what is 'proot-distro' debian? what is special about it?
<saux>update shepherd plz, it will hang on when shutdown or reboot, i each shutdown by sysrq now
<mirai>apteryx: If you're planning to work on the SRFI-64 front I'd recommend you to get in contact with Taylan as he's been working in this area as well
<mirai>or chime in the threads
<mirai>it's nice to have more attention brought to these parts
<apteryx>not immediately but it's something that's been itching me for a while
<apteryx>weird, when I update coreutils on core-updates coreutils-mesboot fails to build: configure: error: could not enable timestamps after mid-January 2038.
<apteryx>that's on x86_64
<apteryx>ACTION adds the "--disable-year2038" configure flag to it
<apteryx>something to properly fix in the next 15 years
<jackhill>is setting the time part of contianer isolation, or will that break the time-machine?
<apteryx>ah, that coreutils-mesboot is built with gash
<apteryx>and gash chokes on the latest coreutils' configure script
<apteryx>ACTION punts
<lechner->Hi, is Andrew's rde now the preferred way to configure Emacs as part of Guix Home?
<jaeme`>I just installed GuixSD on a virtual machine, any helpful tips?
<janneke>apteryx: samplet suggested: how about replacing “[:space:]” in the configure script
<janneke>with “"$IFS"”? (Mind the quotes!)
<janneke>(until maybe gash may groks this)
<futurile>Morning everyone
<mekeor>hello futurile! :)
<snape>Hi.  I read in the docs that G-Expressions are automatically added as inputs of the corresponding derivation.  My question is: does this process differentiate between native inputs and inputs?
<cbaines>snape, not sure I understand your question, but there's ungexp and ungexp-native depending on if you want to reference native builds of something or not
<snape>No, my question is about native-inputs vs inputs
<snape>for tools that are used at built time, not at run time
<snape>like if I ungexp such a tool, is it going to be there at run time?
<snape>or maybe in that case I should use ungexp-native, if that's what you meant
<snape>in the docs it says "produces a reference to the native build of the object"
<cbaines>If you're using a gexp as a builder for the derivation, then you should use ungexp-native for things to be used at build time
<snape>yeah ok thx!
<Jindam>guix can be run on android with adb_
<civodul>hmm emacs is being rebuilt
<civodul>oh, tree-sitter update
<gabber`>do i understand correctly that bootloader-installer installs files on a file-system whereas bootloader-disk-image-installer writes files on devices?
<gabber`>are they mutually exclusive?
<mothacehe>gabber`: bootloader-installer operated on a live system, performing grub-install or so. bootloader-disk-image-installer operates on an image, that can be booted later on
<graywolf>Hello :) Is there a way to make guix pack produce a .zip file instead? Assuming there is not, does anyone have a neat way to convert from the .tar.gz to .zip?
<nutcase>Hi, I'm trying to understand the output on . I see that core-updates and cuirass jobs are not at 100%. Should I wait for 100% before doing a guix system reconfigure? Currently (since some days) my computer wants to build texlive, ghc, python and more on its own and I want to avoid that.
<nutcase>graywolf: tar xzf foo.tar.gz && zip $(tar tf foo.tar.gz) ?
<nutcase>+ cleanup
<nutcase>(from stackoverflow)
<graywolf>will play with that, thx
<f1refly>graywolf: you can't without extracting and repacking because there isn't really a good way to pipe both paths and contents in a way that both zip and tar understand
<f1refly>you could use a ramdisk for reduced disk wear and increased speed though if you plan on doing this a lot
<gabber`>mothacehe: aaaahh, i see, thanks! i was somewhat confused by u-boot-ts7970-q-2g-1000mhz-c-bootloader.. i guess we don't have an example of installing the bootloader into the EFI partition somewhere? i succeed to get firmware+u-boot running (which then fails to load an image through EFI) and i'm somewhat out of ideas
<graywolf>Hm maybe I should just add .zip support to the pack
<hako>nutcase: If you are on master branch and don't have changes from core-updates branch applied, you should only care about the "master" jobset. There's also a page for substitute availability on Guix QA: <>.
<nutcase>hako: Thanks, I wasn't aware that the jobset correspond to branches. is showing 94.1% for x86_64-linux . Can I see more details, e.g. on package level?
<nckhexen>nutcase: They will never reach 100%, there's always something (several somethings, in fact) that fails to build.
<nckhexen>nutcase: ‘guix weather PACKAGE’
<nckhexen>You can also use the search field on ci.guix.
<nckhexen>(By the way, ‘guix weather texlive’ tells me there's a toot, although my Guix is a day old.)
<hako>nutcase: You can use "guix system build" with the "-n / --dry-run" option to see which derivations would be built locally, and wait until the unwanted ones gone.
<cbaines>nutcase, you can use the data service to get more information on substitute availability, e.g.
<nckhexen>I still get a substitute for texlive on current master.
<gabber`>now hold up. on an aarch64 system i should expect a file called bootaa64.efi, right? so why is there only this bootx64.efi?
<gabber`>and disk image creation with --system=aarch64-linux fails (due to it not being on a aarch64-linux system)??
<nckhexen>--system=ALIEN requires transparent (binfmt) emulation.
<gabber`>neither does --target=aarch64-linux-gnu
<nckhexen>nutcase: Are you on x86_64? Because I also get substitute for all the GHCs. Every single version.
<nckhexen>From both farms.
<gabber`>may this be related to efraim's comment yesterday?
<nutcase>nckhexen: thanks, I forgot about the weather interface. Then still, my problem is related to some other issue (ACL), which I thought I already solved with your help:
<nutcase>weather tells me 100% for the packages guix wants to build
<nutcase>but it does not trust, right?
<nckhexen>OK, so the issue isn't availability but trust.
<nckhexen>(Well, presumably.)
<nckhexen>ACTION just checked and weather doesn't care about the ACL.
<nutcase>even with prior guix archive --authorize I have the ACL warning:
<nckhexen>What does your /etc/guix/acl look like?
<nutcase>1 entry only, ecc starting with #BCB
<nckhexen>I don't recognise that.
<nutcase>unfortunately, I removed all my old system generations (because I ran into disk full issues)
<lechner->a common problem
<nutcase>/etc/guix/acl does not change after guix archive --authorize
<nckhexen>ACTION doesn't have that key.
<nckhexen>Is it a regular file?
<nckhexen>If it's a symlink, you can safely rename it and try to authorise again, although it's odd that ‘guix authorize’ presumably didn't throw an error.
<nutcase>❯ sudo file /etc/guix/acl
<nutcase>/etc/guix/acl: ASCII text
<nutcase>guix archive --authorize does not create a new file
<snape>nutcase: did you restart the daemon?
<snape>well nvm, if /etc/guix/acl doesn't change that's another problem
<nckhexen>It should only create a new file if it's a symlink (in which case it will warn).
<nutcase>snape: I just restarted the daemon now, but still, no /etc/guix/acl is created
<nckhexen>It won't create it.
<nckhexen>nutcase: So: if you blow away /etc/guix/acl (or rename it if you want to be safe), then authorise both keys, what happens.
<nutcase>nothing. File is not recreated
<nckhexen>‘guix authorize’ it what should create/amend /etc/guix/acl, that or your operating-system.
<nutcase>and I get no error/warning
<nutcase>yes, narf, indeed
<nckhexen>/etc/guix is a regular directory?
<nutcase>❯ file /etc/guix
<nutcase>/etc/guix: directory
<nutcase>❯ ls -ld /etc/guix
<nutcase>dr-x--x--x 2 root root 4096 Oct 20 13:23 /etc/guix
<nutcase>13:23 is when I renamed my acl file
<lechner->interesting permissions
<nutcase>should I 770 it?
<nckhexen>Or 775.
<nutcase>btw. I have a acl.bak with three entries (from Feb)
<nutcase>no difference with 777
<nckhexen>Not related, but 777 might be a bit wide IMO.
<nutcase>I agree
<nutcase>signing-key.sec shouldn't be public
<nckhexen>I feel like there's an obvious thing we're missing, but I'm, well, missing it.
<nutcase>maybe it's my fault
<lechner->could something check for narrower permissions, as a security precaution?
<snape>nutcase: guix repl <(echo '(format #t "~a~%" (@ (guix config) %config-directory))')
<snape>what does it return?
<nutcase>as you might notice in my paste.debian, I didn't do `guix archive --authorize`, but instead I did a `sudo guix archive --authorize`. With `guix archive --authorize` I got an error: open-file: Permission denied: "/usr/local/etc/guix/acl". I created a symlink /etc/guix/acl to /usr/local/etc/guix/acl and everything is fine now (I hope).
<nutcase>sudo is correct, I know, but it didn't point me into that direction
<nutcase>trying guix archive --authorize just gave me the information, what guix archive --authorize does (without any error).
<nutcase>* ... what `sudo archive --authorize` successfully does (without any error)
<snape>maybe you forgot --sysconfdir=/etc
<snape>upon running ./configure
<nutcase>snape: with sudo guix archive --authorize?
<nutcase>snape: I didn't run ./configure
<snape>oh ok nvm then, I thought you were using a manually built guix
<nutcase>what is /etc/guix/acl supposed to be (a link or a file) and what mode (700?) is /etc/guix supposed to be?
<snape>it depends ^^
<nutcase>snape: yes, nvm and no, not manually built but installed by installation media
<nutcase>it depends on what? ^^
<snape>whether it comes from reconfigure (in this case it's probably? a symlink), if you manually run --authorize then it's a file
<snape>nutcase, can you run the command I showed?
<snape>guix repl <(echo '(format #t "~a~%" (@ (guix config) %config-directory))')
<snape>I imagine if the output is not "/etc/guix" then it's  a problem with your guix and you should try another guix?
<nutcase>well, my "old" /etc/guix/acl was from Oct, 13. (friday, 13th btw :D). And I think it was created by a (maybe failed, because of full disk) reconfigure
<snape>this is not normal
<nutcase>my guix was installed in february
<snape>guix pull
<snape>then restart session, and try again maybe?
<nutcase>I'm just reconfiguring my system, give a moment
<nutcase>I did a guix pull this morning
<snape>but is the guix you are using the one you pulled?
<snape>(which guix)
<snape>with sudo
<snape>I mean maybe the one sudo uses is not the same
<nutcase>❯ sudo which sudo guix
<nutcase>sudo which guix gives only the one in my home
<nutcase>❯ sudo which guix
<snape>does this return something?
<snape>as root?
<nckhexen>nutcase: 755 is fine for /etc/guix. Mine is 775 because it stores my configuration. You should not rely on /etc/guix restrictions to keep your signing key safe.
<snape>(sorry for the dumb questions, this was the last^^)
<nckhexen>Hey that's my job >:(
<nutcase>empty as root
<nckhexen>nutcase: …
<nckhexen>So it's a shell script that always returns true (yay Unix).
<nutcase>nckhexen: well, my disk is encrypted, but is it necessary to open that dir to "o"?
<nckhexen>I don't understand the question.
<nutcase>snape: you mean, there is no idea left?
<nckhexen>Au contraire, think you two found the culprit.
<nutcase>isn't 700 sufficient?
<nutcase>i mean: no idea left for dumb qustions?
<nutcase>well, if a symlink from /etc/guix/acl to /usr/local/etc/guix/acl is fine, than the issue is solved
<nckhexen>nutcase: 700 is sufficient if you don't use /etc/guix for anything else (like your system configuration), but I mean that your security model should not rely on it being 700.
<nutcase>or should the whole /etc/guix be linked to /usr/local/etc/guix/ ?
<nckhexen>I've never heard of /usr/local/etc/guix.
<nckhexen>Are you running Guix on FreeBSD.
<nckhexen>(Don't answer.)
<nutcase>I guess, I don't
<lechner->Hi, is HEAD in good shape?
<nckhexen>nutcase: Honestly, no, I would not make it a symlink.
<nckhexen>My only foreign Guix installation does not have /usr/local/etc.
<nutcase>then, why does guix archive --authorize the acl file in /usr/local?
<nutcase>then a native guix installation shouldn't have that neither?
<nckhexen>I missed most of that conversation but IMO it shouldn't.
<gabber`>why would this image build an x86 EFI (bootx64.efi)?
<nckhexen>nutcase: A native Guix installation shouldn't have usr, or it should have it only for the /usr/bin/env compatibility symlink.
<snape>the problem is guix's %config-directory is /usr/local/guix
<snape> /usr/local/etc/guix
<nutcase>I'm not sure, what my security model should rely on, since I don't know the purpose of /etc/guix/signing-key.sec and if it has a passphrase
<nckhexen>It doesn't.
<nckhexen>Your security model should rely on its permissions, not that of its parent.
<nckhexen>It's used to sign exports, which you might not even use.
<nutcase>nckhexen: right
<nckhexen>If this machine doesn't serve substitutes or handle offloads, you don't.
<nutcase>nckhexen: ok, understood
<nckhexen>This might have been asked before (sorry snape), but is this a Guix System?
<nutcase>yes, 1.4.0 installed in February
<nckhexen>And if so was it installed the regular way, not with a hand-built (from source) Guix?
<nutcase>by install medium
<snape>even with foreign distros it should be /etc/guix
<nckhexen>Then I too am confuzed how /etc/local slipped in at all.
<nckhexen>snape: I was thinking that some distro packager could have messed up their ./configure invocation, you never know :)
<nckhexen>But that's not relevant then.
<snape>nckhexen: nutcase ran 'guix pull' this morning, so they are using a fresh guix that shouldn't have been packaged by any other distro
<lechner->nckhexen / reasonable
<nckhexen>Desperate, more like.
<nutcase>I need to be afk for an hour. I will report what the situation looks like after system reconfigure (hopefully) suceeded
<snape>it's the daemon
<snape>who is outdated
<nutcase>my generation is from Oct, 6 and my /usr/ directory is also from Oct, 6
<snape>and should run the recently pulled guix
<nckhexen>So ‘echo '(pk (@ (guix config) %config-directory))' | sudo guix repl’ really returns "/usr/local/etc/guix"?
<nckhexen>I guess you can drop the pk, I didn't actually test.
<nutcase>;;; ("/usr/local/etc/guix")
<nutcase>$1 = "/usr/local/etc/guix"
<lechner->Hi, why does the git repo ship a manifest.scm, please? My buffer-env offers to run it
<nckhexen>lechner-: For convenient guix shelling.
<nckhexen>git clone ~/guix && cd ~/guix && guix shell && hack
<lechner->maybe buffer-env should be disabled for magit buffers
<nckhexen>ACTION can't say, doesn't use.
<nckhexen>Or al least, I use magit but haven't seen that prompt.
<efraim>cbaines: gnutls-3.8.1 should probably be hidden
<tux1c>anybody ever had trouble with nmcli reporting `plugin missing` on wifi devices? ive seen that issue on other distros and the fix was to install `network-manager-wifi` which seems to be built in to the normal `network-manager` on guix
<nckhexen>tux1c: I use NM (and wi-fi :) and have never seen that error, even in weird/minimal rescue environments. Guix's NM isn't even set up to handle plug-ins at all. Is there any specific action that causes the error?
<nckhexen>Scratch the ‘not set up’ part, it's in a patch.
<tux1c>nckhexen: i am just trying to configure wifi, the device doesn't show up in the GUI applet I have, nor am I able to connect to any networks through nmcli (funnily though, I am able to scan for networks through nmcli)
<nckhexen>tux1c: Guix's network-manager already provides, so that error isn't to be taken at face value (maybe the search path is off, maybe ‘plug-in’ is a new euphemism for proprietary firmware, …). This isn't a new (~1 week) error, is it?
<tux1c>nckhexen: I have just finished installing and setting up guix for the first time, so I wouldn't know. I'll keep looking in other directions, then. thanks :)
<nckhexen>ACTION updated NM this week, but has been running that version for 2 weeks or so without issue.
<futurile>Q: when we want to investigate a build we use '--keep-failed'and source in 'environment-variables' file. I usually do that by creating a shell first: `guix shell --container --nesting --development <package> coreutils git. The problem is I want to keep the $PATH of the shell (so I can use the coreutils commands, git etc) but when I source in `environment-variables` I lose those. At the moment I
<futurile>land-up echo'ing the shells $PATH and then cutting-n-pasting the $PATH in after sourcing `environment-variables`. Is there a clever way to *add* the environment-variables or the shells existing $PATH so I don't have to do the cut-n-paste dance?
<futurile>(too long - sorry)
<civodul>futurile: hi! you probably want ‘--no-grafts’ so the container gets the ungrafted inputs, just like the origin build environment
<civodul>(that might explain why you didn’t get Coreutils on $PATH)
<PotentialUser-70>Hi, I have a slow working ci substitute and I have to add --substitute-ursl='bordeaux...' to make it much faster every time, so I tried to make bordeaux default using manual about services configuration but nothing work out, can someone help?
<nckhexen>What did you try?
<PotentialUser-70> (modify-services %desktop-services
<PotentialUser-70>      (guix-service-type config =>
<PotentialUser-70>                        (guix-configuration
<PotentialUser-70>                          (inherit config)
<PotentialUser-70>                          (substitute-urls
<PotentialUser-70>                            (append (list "")
<PotentialUser-70>                                    %default-substitute-urls))))))
<futurile>civodul: ah OK, I'll try that (and check my understanding again)
<nckhexen>PotentialUser-70: That's correct. What's the command line of the currently running daemon?
<civodul>futurile: BTW, assuming you’re the person behind, congrats, it’s really nice!
<nckhexen>PotentialUser-70: It's not *perfect* because bordeaux is already part of %d-s-u, but it's correct in that ordering matters and adding it twice is probably inefficient but otherwise harmless.
<futurile>civodul: thank-you! Hoping it's following a 'logical' learning path - logical to me :-). About to start going through package transformation and then hoping to get to packaging basics.
<PotentialUser-70>nckhexen: the whole code block looks like this
<PotentialUser-70>(services (append (list (service gnome-desktop-service-type)
<PotentialUser-70>                         (set-xorg-configuration
<PotentialUser-70>                         (xorg-configuration (keyboard-layout keyboard-layout))))
<PotentialUser-70>                    %desktop-services)
<PotentialUser-70>   (modify-services %desktop-services
<PotentialUser-70>      (guix-service-type config =>
<PotentialUser-70>and it gives me an error /home/username/.config/guix/system.scm:31:2: error: (services (append (list (service gnome-desktop-service-type) (set-xorg-configuration (xorg-configuration (keyboard-layout keyboard-layout)))) %desktop-services) (modify-services %desktop-services (guix-service-type config => (guix-configuration (inherit config)
<nckhexen>Use or the bot'll get ya.
<PotentialUser-70>(substitute-urls (append (list "") %default-substitute-urls)))))): invalid field specifier
<PotentialUser-70>ok, sorry
<nckhexen>This doesn't address your error (sorry, on 'phone, hard to spot nesting & other errors) but you have a duplicate %d-s that will cause pain later. (modify-services %d-s ...) *replaces* the first %d-s in your first append.
<lechner->Hi, how may I get a copy of all guix-related bug messages (control not needed) please?
<nckhexen>PotentialUser-70: Could you paste your entire configuration? It *might* help me spot the error, or someone else might.
<nckhexen>Ideally already correctly indented if your editor can do so.
<lechner->would someone please share a snapshot of the rsync data from
<nckhexen>ACTION brb.
<lechner->bot test #5555
<nckhexen>PotentialUser-70: OK, you're basically doing (services one-list another-list), which won't work. Fields take a single value. Do you see that now? I hope so :-p So you need to cut the entire (modify-services %d-s ...) expression, then replace the first %d-s with it.
<nckhexen>(services (append (list with gnome and friends) (modify-services %d-s ...)))
<nckhexen>I hope that's clear.
<lechner->bot test #5555
<peanuts>"23.1.92; mail-archive-file-name not working"
<nckhexen> acceptable lechner?
<lechner->nckhexen / thanks! i did not realize that all bug reports also went out via mailing list. i'm looking at guix-patches instead. are our submissions really so low volume?
<nckhexen>Can't say, AfK...
<nckhexen>Will look again when on laptop.
<lechner->Hi, is there a way to isolate shepherd services without creating custom user or group? Is there a standard container way? What is least-authority-wrapper, please?
<PotentialUser-70>nckhexen: it didnt give me any errors but it still tries to substitute from ci first(
<lechner->Hi, what's a good way to debug shepherd services that fail to start, please?
<mirai>stare hard at screen
<mirai>use VMs and write system tests
<lechner->mirai / just something simple like this. may i see the output for the failed command anywhere?
<mirai>That'd be syslog
<lechner->cannot open '/var/log/syslog' for reading: No such file or directory
<lechner->nothing in messages
<mirai> /var/log/messages
<lechner->just "Oct 20 07:16:57 localhost shepherd[1]: Service irc-helper-bot failed to start."
<nckhexen>PotentialUser-70: Did you restart the daemon & verify that the command line has been updated?
<nckhexen>Ah, they buggered off.
<lechner->Hi, is this the right way to declare a simple-service, please?
<lechner->here is the service
<snape>Hi, Geiser doesn't seem to work with G-Expressions
<snape>is there anything special to do?
<snape>I mean, C-c C-b errors out on "Unknown # object: "#~""
<snape>(with emacs-guix installed ofc)
<snape>If I manually C-M-X the define-module block it starts working
<snape>reply to myself: echo "(use-modules (guix gexp))" > ~/.guile-geiser
<snape>fixes the issue
<Cassio>I'm trying to install Frescobaldi, and the installation fails while trying to install `python-poppler-qt5`. When I look into the log, I find out that the problem occurs in the build phase (`build_ext` command) of the  `popplerqt5` extension. The error is thus reported: POPPLER_V21_01_0 -x QTXML_AVAILABLE -c build/temp.linux-x86_64-cpython-310 -b
<Cassio>build/temp.linux-x86_64-cpython-310/poppler-qt5.sbf -I /gnu/store/cz5m3862zl889a756l1j3hqm0j5n87nn-python-pyqt-5.15.9/share/sip -n PyQt5.sip -t Qt_5_15_10 -t WS_X11 poppler-qt5.sip
<Cassio>sip: Unable to find file "QtCore/QtCoremod.sip"                         What could that be? How can I solve it?
<snape>hi Cassio, small tip: you can use to paste large things
<mirai>lechner-: put irc-helper-bot-shepherd-service within a list
<mirai>or is that already a list?
<mirai>the extensions to shepherd-root… have to be lists of shepherd-service objects
<snape>Cassio: it's actually python-poppler-qt5 that doesn't build
<snape>  <-  same error
<snape>I've no idea why though.  maybe you can send an email to to explain that
<lispmacs[work]>hi, I'm wanting my shell to go back to using .guix-profile instead of .guix-home, but I'm not sure what to put in .profile
<Cassio>snape: Yes. But the actual error is not finding the file "QtCore/QtCoremod.sip"...
<Cassio>So, all I can do is to submit a bug report?
<snape>         GUIX_PROFILE="$HOME/.guix-profile"
<snape>          . "$GUIX_PROFILE/etc/profile"
<snape>in ~/.bash_profile
<snape>lispmacs[work] ^
<snape>Cassio: you can also try to find the solution ;)
<lilyp>either that or recreate it from /etc/skel
<Cassio>snape: not by my own I can't!  ;)
<Cassio>Thanks anyway. :)
<pastor>Please, anyone here could give me some insight on meson and cargo? I'm packaging a meson+cargo application. Last time mirai and snape gave me some hints on how to fix the missing configure flag problem on the meson's configure phase. I had some time to try their suggestions and indeed I've managed to fix it. Now I'm blocked in the build phase
<pastor>so, the problem is that cargo tries to fetch dependencies from crate which triggers network access. This is the problem: Updating index
<pastor>warning: spurious network error (2 tries remaining): failed to resolve address for Temporary failure in name resolution; class=Net (12)
<pastor>So looking at the that causes this I guess there are many unmmet dependencies that it's downloading from which we don't have packaged for Guix as of now. Should I package them by hand?
<pastor>maybe with `guix import` and make a big patch to the mailing list with cover letter and all?
<lilyp>pastor: you may not like it, but that's what pckaging rust stuff boils down to, yes
<pastor>I understand. But is it okay to flood guix with many packages? Isn't it going to be a problem for maintainers?
<snape>it's already ^^
<snape>it's already a huge problem for maintainers
<lilyp>yeah, we only have a bunch of folks in the rust team, but they're aware of what to expect
<apteryx>snape: re gexps, you need to ,use (guix gexps)
<apteryx>or gexp I forget
<apteryx>without s
<snape>apteryx, yes, I think this is what I did, thx
<apteryx>efraim: I tried to add a job spec to cuirass to build the 'core' set of packages on core-updates:
<apteryx>but the evaluations appear to fail, for reasons I haven't explained yet
<pastor>I'm giving this flag: #:cargo-inputs `(("rust-autocfg" ,rust-autocfg-1))
<pastor>But I still see this line on my dev shell when meson runs `cargo build`: Downloaded autocfg v1.1.0
<pastor>Why could that be?
<apteryx>you are afraid that it fetches stuff from the net?
<apteryx>that's not possible, the build is containerized (at least on GNU/Linux)
<civodul>apteryx: looks like the evaluations are still running no?
<apteryx>the last ones yes... not sure why they need so much time
<civodul>they need to build guix before they can actually compute derivations
<pastor>Yep. It is fetching. I would expect it to not fetch if I provide it as a cargo-input
<civodul>so if you change something at the bottom, it’s gonna take a while
<civodul>better not push too frequently
<apteryx>I see
<civodul>there’s now a limit on the maximum number of concurrent evaluations, 8 by default
<civodul>we might end up with core-updates taking up all the slots
<pastor>Could It be the `CARGO_HOME` variable?
<apteryx>civodul: the last evaluation had failed because of a build failure of curl
<apteryx>ACTION builds it manually
<apteryx>hm, curl is already built on core-updates for latest commits
<apteryx>it's probably building other things now
<apteryx>funny how browsers crashes accessing
<apteryx>maybe the OOM killer
<lechner->Hi, how may I declare a list type in define-configuration, please?
<apteryx>wget -O- | zless to the rescue
<apteryx>civodul: an excerpt from the core-updates evaluation log:
<old>anyone tried chatGPT for generating package definition of Guix?
<apteryx>looks like an offload crash?
<old>Cuz I just did, and I'm amazed
<Gooberpatrol66>is it possible to change a partition's size in guix installer's guided partitioning?
<civodul>apteryx: looks like it, but we’re missing the bottom of the backtrace and exception
<mirai>Is it possible to override (set!) the record-modifier of a field?
<mirai>I'm not hitting the right incantations for struct-vtable
<lilyp>mirai: not really, but you can introspect the vtable and bind the modifier to a new variable
<lilyp>(i suppose that's what you're trying)
<mirai>I'm trying to concoct a way to redirect one field value to another (for deprecation purposes)
<lilyp>(record-modifier (record-type-descriptor record) field-name)
<mirai>e.g. have the sanitizer of foo field, which is deprecated, to set the value of bar (which is its replacement)
<mirai>the goal is to have a cleaner/better way to rename/redirect a deprecated field to another
<lilyp>mirai: why not check this where you access the bar field?
<lilyp>and simply have the foo field sanitizer print a deprecation warning?
<mirai>sure, that's one approach (the one used in mpd.scm)
<mirai>though was wondering if we could do the same by tinkering with the record directly and avoid defining interim procedures to handle deprecations
<graywolf>Hm, I am trying to follow , and I got the guix build -f guix.scm part working. However, how do I pack that? It does not seem that guix pack accepts the file in the same way guix pack does...
<mirai>Would it be bad design if `filter-configuration-fields' were to return multiple values (as S S
<mirai>(as S S') instead of that #:negate optional?
<mirai>or (S U\S) (iow, the selection and its complement)
<lucypoo>Hey there, im just bumping python to 3.12 for my own personal use, i dont know if i have the time to set up herd vm-s to test on all systems. anyone here working on this? i have a patch file which may be useful
<nckhexen>sneek: later tell graywolf I think there's no good reason not to support it
<sneek>Got it.
<nckhexen>Somebody is going to get bug 66666 soon. 🎃
<nckhexen>Please make it count.
<zamfofex>Isn’t the number non‐Guix‐specific (i.e. shared across GNU projects using debbugs)?
<nckhexen>Mostly emacs.
<nckhexen>I think Guix is the only thing that threatens/rivals its hegemony of the bug tracker.
<mirai>the subject better have the substring “check'em” in it
<sarg>is anyone working on pyqt6? qutebrowser is now supporting it fully
<mirai>lechner-: re list type, use (define list-of-foo-thing (list-of foo-thing?))
<lechner->mirai / thanks!
<lechner->Hi, what does this mean when upgrading a shepherd-root-service, please? %exception #<inferior-object #<&action-exception-error service: root action: eval key: system-error args: ("fport_write" "~A" ("Broken pipe") (32))>>
<lucypoo>i imagine that fport means a file port
<lucypoo>so perhaps file based sockets were in use for a pipe and went wrong?
<lilyp>fport just means it's backed by an fd – pipes have fds attached to them
<zamfofex>Hmm, I noticed something (whether it was ‘git send-email’ or something else, I don’t know) added some ‘prerequisite-patch-id’ to my recent patch 66654, but they aren’t actually necessary. 🤔 Is that a big issue?
<lilyp>you got a broken pipe somewhere, probably some receiving command died during the comm
<lilyp>zamfofex: they're mostly annoying but harmless, they come from having --base=auto
<lechner->lilyp / lucypoo / thanks!
<zamfofex>I wish I could know what kind of magical tools the Guix developers use to look at and accept the patches I send. 😄 Probably something that integrates with Emacs, if I had to guess. 😅
<lilyp>lechner-: actually, reading "inferior" it might be that the inferior guix ended prematurely
<lilyp>no clue where it came from tho, that might be part of your config
<lilyp>zamfofex: in my case it's wget | git
<lilyp>mumi has a frontend that's been great for collecting series
<lilyp>there's also emacs-debbugs used by some
<zamfofex>lilyp: Very neat! One day, I dream of being at least partially as proficient at computing.
<ulfvonbelow>whenever I reconfigure, my static networking service fails to start until I manually tear it down and then restart it. Is there a reason the teardown isn't happening automatically when the networking service is replaced?
<lilyp>IIUC reconfigure doesn't kill running services – that'd cause more trouble than it's worth for most of them
<lilyp>imagine reconfiguring and then being thrown out of your login, for example
<ulfvonbelow>okay, but for some reason it's trying to restart networking and everything that depends on it
<ulfvonbelow>and failing, because instead of stop --> unload --> load --> start, it's doing unload --> load --> start
<ulfvonbelow>since static networking fails to start when the addresses or routes already exist
<lechner->lilyp / thanks! i really struggle with writing services in Guix. Can you see what's wrong in this one for the Heimdal KDC?
<lechner->ulfvonbelow / is this for ipv4?
<Jevra>Why does guix packages website only list GNOME as 42? I thought the GNOME packages were up to date with the current release, which is 45.
<janneke>Jevra: see the gnome-team branch
<ulfvonbelow>lechner-: it's for both ipv4 and ipv6
<mirai>lechner-: don't see what's wrong with it
<mirai>does it not work?
<lechner->no, but there is no error message
<mirai>What happens?
<mirai>does the service file “build”? (i.e. can you ,m (the module) with a repl?)
<lechner->it's currently in my operating system declaration
<lechner->it deploys but does not start
<mirai>does it start but fail?
<futurile>Q: every time I try and use `git send-email` it's trying to run a get_maintainer script, any idea where it's getting that from?
<mirai>that's an issue with heimdal, not shepherd
<lechner->mirai / i can start it by hand
<mirai>you'll have to figure out how to get heimdal to log more
<mirai>or where is it logging
<lechner->okay, thanks
<mirai>perhaps its some environment variable missing that heimdal needs
<Rovanion>Anybody knows why cmake would find qt5-core but not qt5 in a build?
<Rovanion>Trying to refresh musescore.
<lechner->mirai / thanks for that hint! it stays on for exactly five seconds.
<lechner->mirai / alas, the logging facility is not implemented in krb5-configuration. i like separate files. do we, as a project, prefer syslog? "Destinations"
<mirai>Why not support both?
<mirai>'syslog as symbol
<mirai>and strings for paths
<VesselWave>Hey, Guix! Does anybody know how to make a system Shepherd service to auto-start something?
<philip>Is anyone familiar with how ALSA finds plugins? I'm working on packaging Racket's `#lang video` (, which is implemented using FFmpeg and PortAudio. I have it building, but trying to use it fails with errors from ALSA lib trying to find files from Apparently these are from the `alsa-plugins` package, but it's looking for them under the `alsa-lib` store output.
<redacted>It looks like nginx can be made to wait for shepherd services, but certbot isn't a shepherd service. Will I have to make a certbot shepherd service to get nginx to wait for a certificate?
<mirai>redacted: nginx x certbot is a bit complicated
<mirai>best is to run the renew-certificates once
<mirai>and start nginx manually
<mirai>afterwards it should simply work
<redacted>mirai: got it
<redacted>hmm, if I can get the path to renew-certificates, presumably I can make a one-shot shepherd service that nginx depends on
<redacted>ah, looks like the certbot directory is in a let-bound variable
<redacted>doesn't look like I can get the path I need from the config