<Grimpper>Installing subprojects/registrar/appmenu-registrar to /gnu/store/...-xfce-appmenu-gtk-module-0.7.6/libexec/vala-panel Installing applets/libappmenu-xfce.so to /gnu/store/...-xfce4-panel-4.18.3/lib/xfce4/panel/plugins FAILED: meson-install
<Grimpper>For context this is the derivation: paste.debian.net/1278736
<smmm>hey, quick one - I have built a package and have added `iptables` as a propagated-input... when i run the package inside `guix shell -C...`, I can find iptables in the $PATH, but the daemon I am packaing cannot find it - is there a good way to perhaps check if the PATH is being properly read / maybe strace and see what's going on?
<AwesomeAdam54321>smmm: I think the simplest way is to check the package's source code to see how it calls iptables, using grep
<abrenon>anyone has an idea what package (from %base-packages I presume ?) lets one use UTF-8 characters ? I noticed that when I enter a --pure environment I can no longer type a 'é' or any other UTF-8 character in my shell
<abrenon>and also some haskell process I wrote which filters text now chokes on an input having UTF-8 (but importantly, not on ASCII-only inputs)
<jpoiret>you need some utf8 glibc locales i would say
<abrenon>yeah but how would I put that into my --pure shell or container ? I tried the ol' export LANG=fr_FR.UTF-8 trick to no avail
<jpoiret>you would also need to set LOCPATH. I don't think there's a minimalist glibc utf8 locales package
<civodul>looks like issues.guix.gnu.org search now ignores submitter: and author: contraints
<mfg[m]>does gnome-terminal depend on systemd? i'm running sway and alacritty doesn't launch anymore so i wanted to use gnome-terminal and it errors out saying "org.gnome.Terminal was not provided by any .service files"
<abrenon>mfg[m]: nope, we don't have systemd in Guix System
<mfg[m]>i know that systemd isn't part of guix system, but i only know .service files from systemd. So i don't get why gnome-terminal would error out like this
<jpoiret>if you're running sway, I would recommend some lighter and simpler terminals
<jpoiret>foot would be a good one (disclaimer: that's what i use)
<mfg[m]>Yeah that would have been my next question :D
<mfg[m]>I've seen bjc (?) was trying to update and/or fix the alacritty package, but as it is written in rust that seems to be a frustrating experience. Maybe i should switch permanently to something else 🤔
<bjc>efraim has fixed alacritty, i think. but i've also switched to foot as i no longer trust anything written in rust, particularly alacritty
<apteryx>I think the GNOME terminal spawns a user 'daemon' via d-bus, by using the d-bus autostart mechanism. and teh issue is that we have a hard coded list of places d-bus consults to find its service definitions, such as /etc/dbus-1 or ~/.guix-profile/etc/dbus-1, rather than in arbitrary places such as a 'guix shell' profile
<jpoiret>also, I think we could add "format.forceinbodyfrom=true" by default, so that people whose From: header gets rewritten by debbugs/mailman still have the proper attributions by default
<civodul>platform-testers is very much about testing things on AIX, HP-UX, NetBSD on alpha, things like that
<jpoiret>I got the reason from the mailman team, it's because of DKIM: since debbugs rewrites the To: headers, which are signed by DKIM, it needs to alter the sender to still pass DKIM by resigning everything itself
<jpoiret>and some of our contributors don't really control their provider's DKIM policy, so this option seems like the best mitigation
<efraim>anyway, I built from the git tag on the second try on aarch64, had a test failure the first time around. testing armhf-linux and riscv64-linux ATM. If I find a spare outlet I can test powerpc-linux too
<jpoiret>I can't seem to get past the debbugs dance, always running into the timeout
<apteryx>unmatched-paren: mumi current 63082 && mumi send-email -a mpd-v1, where mpd-v1 was produced with 'git format-patch --cover-letter -ompd-v1 74e41b16a7..' and the cover-letter.patch edited there
<sime>hi, what do i need to install in order to watch videos on youtube with epiphany? when i click on any video it says "No compatible source was found for this media." i tried to install gstreamer and gst-plugins-good but that didn't help
<bjc>patched[m]: ah, yeah, i don't see it either. puzzling
<apoorv569[m]>Just installed Guix on a different machine with encrypted btrfs file system. Installation went without any errors, but rebooting into installed system shows error, "refusing to check /dev/mapper/cryptroot file system already mount at /" and just stuck here..
<civodul>note that you can already pass arguments to 'start'
<civodul>efraim: i managed to reproduce a test failure on aarch64-linux so... i have more work to do now :-)
<patched[m]><jpoiret> "patched: guix shell -e "(list (@..." <- Thanks, now it appears in the environment!
<jpoiret>i'll be rebooting with shepherd 10 first :)
<apoorv569[m]>"Some bootloaders, for example GRUB, only mount a Btrfs partition at its top level during the early boot, and rely on their configuration to refer to the correct subvolume path within that top level. The bootloaders operating in this way typically produce their configuration on a running system where the Btrfs partitions are already mounted and where the subvolume information is readily available. As an example, grub-mkconfig, the
<apoorv569[m]>configuration generator command shipped with GRUB, reads /proc/self/mountinfo to determine the top-level path of a subvolume. "
<bjc>iirc, systemd allows you to do this by having the ability to set systemd's environment itself. so your wm can start, tell systemd that DISPLAY=:1, then you can start services normally from that point
<jpoiret>yes, dbus as well, but it is ugly: the environment variables are not scoped, you modify the whole starting environment with it.
<bjc>i'm not, personally, thrilled by the idea of arbitrary message passing in shepherd, but i agree this is a problem
<jpoiret>with proper message passing, you could scope the variables (and other info) to exactly the services that need them
<jpoiret>by message passing, I mean that one service could say in its definition "oh my start action takes an additional argument which is what service Y's value is"
<jpoiret>I'm not proposing dbus or anything like this :)
<apteryx>it's sad we can't use source-properties in define-configuration
<spiderbit>ok maybe more guix specific question, with home service can you not just dump a file into the config file and then it get's copied and symlinked? I want a "ec" file that does open emacsclient -c <files> loaded
<apteryx>I'm getting a confusing error on 'guix pull'; guix-package-cache.drv fails, suggests it is caused by a channel I use. The derivation fails because the channel uses 'python-pycrypto', which no longer exist. But since the channel is pinned to use an inferior at 9ed65e6af77893b658a7159b091b5002892c2f95 which still has such package, why should it fail this way?
<spiderbit>Wrong type to apply: (("ec" #<<local-file> file: "ec" absolute: #<promise #<procedure 7f64903ad888 at /home/black/src/guix-config/home-configuration.scm:41:16 ()>> name: "ec" recursive?: #f select?: #<procedure true (file stat)>>))
<mirai>apteryx: huh, I'm surprised at some of the patches
<unmatched-paren>spiderbit: home-emacsclient-script-service has to be a procedure that takes the configuration (so that its return value can change based on what's in the config)
<unmatched-paren>(program-file "ec" #~(system* #$(file-append emacs "/bin/emacsclient") #| maybe add some new args here idk |#))
<unmatched-paren>that way you don't have to have a separate file or use the clumsy LOCAL-FILE
<spiderbit>I think I am over it, it's not worth the effort and not reproducable... if I have to do something similar in 1 month I have forgotten all that either there is some documentation or it's not reproducable
<nutcase[m]>bjc: yes, I think that this is the way to go, the upstream should be fixed.
<civodul>jpoiret: no retry delay when starting, indeed
<jpoiret>did you try to make clean-go and make just to see if there are any compile-time error? not that it would catch all of them
<bjc>nutcase[m]: i don't have time to look at the error right now, but i've fixed it a few times in other places already, so i'm reasonably confident about it. if you can't fix it yourself, can you file a bug report and send me the number so i can get to it later?
<jpoiret>let me try to add a dependency on elogind, we'll see
<unmatched-paren>jpoiret: it should be possible to check whether the record type is from DEFINE-RECORD-TYPE* with the MAP-FIELDS machinery
<unmatched-paren>only raise the warning if (TYPE map-fields ...) doesn't throw a syntax error
<jpoiret>unmatched-paren: right. Seems plausible, but still more technical
<jpoiret>you'd probably have to locally bind map-fields to avoid it raising an error and handle that case yes
<jpoiret>I wonder why syntax-parametrize wasn't used for map-fields
<jpoiret>civodul, bjc: that was it, seems like I needed a dependency on elogind
<jpoiret>now, I don't know how we could encode this properly, ie. add a dependency on elogind if the service is going to be using pam.
<jpoiret>on the flipside though, start-up is extremely fast
<jpoiret>I think we're starting to stretch the current service machinery. Maybe it could be time to re-examine it with the experience we have now, and look for some new mechanisms? (and also change the name :p)
<bjc>jpoiret: i don't have that dependency in /etc/pam.d/greetd
<bjc>there's no reference to elogind in any of the files in thet directory
<bjc>i think i'm up-to-date with master from a couple days ago, too, so it shouldn't have changed
<bjc>jpoiret: are you using %desktop-services or %base-services in your system config?
<civodul>jpoiret: ah sure, we could reexamine it; glad you found a solution!
<nutcase[m]>I created my first patch, but I'm not sure, if this solves my problem of not being able to update Apache Maven. If someone with more knowledge than I have has the time to have a look at https://issues.guix.gnu.org/63068 and maybe comment on it, that would be great.
<civodul>nutcase[m]: hi! i pushed patches minutes ago fixing a number of Maven packages
<nutcase[m]>civodul: great! but you are still testing with Maven 3.8.6, right? I have a rather profane issue that I'd like to use a newer version of Maven. Using guix shell --with-version says that it can't find the version upstream. I hoped that my proposed patch will fix it. Unfortunately I don't have a suitable environment yet, to check with my local git working copy of guix.
<bjc>it'd be unfortunate to hard-code a shepherd dependency, imho, since you can use greetd without it
<civodul>nutcase[m]: oh, i can't look at it right now; could you add details about what you were trying do do in the issue above?
<civodul>like the command you used and what it produced
<civodul>bjc: you mean you can use greetd without elogind, right?
<nutcase[m]>civodul: I also tried to build the package from a modified git working copy, but failed in doing so
<zacchae[m]>Alright, I needed gcc-toolchain, but even then, I had to add LIBRARY_PATH=/run/current-system/profile/lib. I'm guessing this is on purpose, though I can't imagine why. Anyone know why */profile/lib (system, home, package) aren't added to LIBRARY_PATH (or GUIX_LIBRARY_PATH?) by default?