IRC channel 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?

<apteryx>guix-daemon*

<Jindam>warning: daemon is running as root, so using `--build-users-group' is highly recommended

<apteryx>how did you install guix? the install script (guix-install.sh) 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_ https://www.gnu.org/software/guix/blog/2018/guix-on-android/

<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

<mothacehe>*operates

<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 https://ci.guix.gnu.org/ . 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 foo.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: <https://qa.guix.gnu.org/branch/master>.

<nutcase>hako: Thanks, I wasn't aware that the jobset correspond to branches. https://qa.guix.gnu.org/branch/master 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. http://data.qa.guix.gnu.org/repository/2/branch/master/latest-processed-revision/package-derivation-outputs

<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? https://logs.guix.gnu.org/guix/2023-10-19.log#125107

<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: https://paste.debian.net/1295658/

<nutcase>weather tells me 100% for the packages guix wants to build

<nutcase>but it does not trust ci.guix.gnu.org, right?

<nckhexen>OK, so the issue isn't availability but trust.

<nckhexen>Right.

<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: https://paste.debian.net/1295659/

<nckhexen>What does your /etc/guix/acl look like?

<nutcase>1 entry only, ecc starting with #BCB

<nckhexen>I don't recognise that.

<nutcase> https://paste.debian.net/1295661/

<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.

<nckhexen>*?

<nutcase>nothing. File is not recreated

<nckhexen>‘guix authorize’ it what should create/amend /etc/guix/acl, that or your operating-system.

<nckhexen>Narf.

<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>right

<nutcase>should I 770 it?

<nckhexen>Yes.

<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>nutcase:

<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

<nutcase>/usr/local/etc/guix

<snape>this is not normal

<nutcase>my guix was installed in february

<nutcase>ok

<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)

<nutcase>/home/flake/.config/guix/current/bin/guix

<snape>with sudo

<snape>I mean maybe the one sudo uses is not the same

<nutcase>same

<nutcase>sry

<nutcase>❯ sudo which sudo guix

<nutcase>/run/setuid-programs/sudo

<nutcase>/home/flake/.config/guix/current/bin/guix

<nutcase>sudo which guix gives only the one in my home

<snape>echo $GUIX_CONFIGURATION_DIRECTORY

<nutcase>❯ sudo which guix

<nutcase>/home/flake/.config/guix/current/bin/guix

<snape>does this return something?

<nutcase>empty

<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"?

<nutcase>:D

<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.

<nckhexen>No?

<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?

<snape>y

<snape>yes

<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 https://termbin.com/rz83 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?

<nckhexen>Huh.

<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>Yes.

<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>unless...

<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"

<nutcase>scheme@(guix-user)>

<nutcase>afk

<nckhexen>Nuts.

<nutcase>case

<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)

<tux1c> https://paste.rs/AbzSx

<nckhexen>tux1c: Guix's network-manager already provides libnm-device-plugin-wifi.so, 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 "https://bordeaux.guix.gnu.org")

<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 https://futurile.net/archives.html, 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 paste.debian.net or the bot'll get ya.

<PotentialUser-70>(substitute-urls (append (list "https://bordeaux.guix.gnu.org") %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 debbugs.gnu.org?

<PotentialUser-70>nckhexen: http://paste.debian.net/1295672/

<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" https://issues.guix.gnu.org/5555

<nckhexen> https://lists.gnu.org/archive/mbox/bug-guix/ 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? https://bpa.st/BSTQ

<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.

<nckhexen>Wise.

<lechner->Hi, is this the right way to declare a simple-service, please? https://bpa.st/JLIA

<lechner->here is the service https://bpa.st/BSTQ

<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 paste.debian.net 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> http://ci.guix.gnu.org/build/1397072/log/raw <- same error

<snape>I've no idea why though. maybe you can send an email to bug-guix@gnu.org 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 crates.io index

<pastor>warning: spurious network error (2 tries remaining): failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12)

<pastor>So looking at the messon.build that causes this I guess there are many unmmet dependencies that it's downloading from crates.io 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: https://ci.guix.gnu.org/jobset/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 https://ci.guix.gnu.org/eval/862040/log/raw

<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: https://paste.debian.net/1295691/

<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 https://guix.gnu.org/en/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/ , 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 https://issues.guix.gnu.org/66653

<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? https://bpa.st/TDAQ

<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?

<lechner->yes

<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.

<Rovanion> http://paste.debian.net/1295713/

<lechner->mirai / thanks for that hint! it stays on for exactly five seconds. https://bpa.st/PKRA

<lechner->mirai / alas, the logging facility is not implemented in krb5-configuration. i like separate files. do we, as a project, prefer syslog? "Destinations" https://manpages.debian.org/testing/heimdal-dev/krb5_openlog.3.en.html

<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` (https://issues.guix.gnu.org/56534#3), 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 libasound_module_conf_pulse.so. 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

IRC channel logs

2023-10-20.log