bug#70926: Having default nss-certs plus nss-certs in operating-system packages causes problems

[Liliana Marie Prikler]

Am Montag, dem 13.05.2024 um 22:38 +0100 schrieb Christopher Baines:
> I've seen this when updating systems, but it seems like something is
> wrong with the handling of nss-certs.
> 
> I'm on a guix revision with nss-certs by default, and when I add
> nss-certs to my system packages (to simulate not removing it when
> upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/
> doesn't work).
I can confirm this on three machines (two of my own, one from a
relative): Having nss-certs in the packages field unexpectedly breaks
all known certificates.

> My reading of the operating-system-packages code suggests that adding
> nss-certs shouldn't have any effect, but this doesn't seem to be
> working.
It would be really nice to detect the mismatching versions if it's
based on that.  IIUC we graft nss-certs now, so that we can hot-swap
stuff like pythons certifi package.  Is this use case broken by any
chance?

Cheers

bug#70581: PHP, glibc, and CVE-2024-2961

[Liliana Marie Prikler]

Hi McSinyx,

security-relevant bugs ought to go to , see [1].
Since a patch exists for glibc all the way back to 2.30, I suppose a
graft can be used and should be performed timely. 

Cheers

[1] https://guix.gnu.org/en/security/

bug#70349: Clang fails to communicate RUNPATH?

[Liliana Marie Prikler]

Hi Guix,

I've noticed a strange error when attempting to build my software
against clang-toolchain.  I've attached a minimally breaking example,
but the gist of it is that RUNPATH validation fails as shown below.

  starting phase `validate-runpath'
  validating RUNPATH of 1 binaries in
  "/gnu/store/sd1zjjf13mi448qbqaphhcvf9ap5jxji-why-hello-0/bin"...
  /gnu/store/sd1zjjf13mi448qbqaphhcvf9ap5jxji-why-hello-0/bin/hello:
  error: depends on 'libfmt.so.9', which cannot be found in RUNPATH
  ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib")

Is this expected?  I know that the -for-system have historically
disregarded the existence of clang-toolchain and hence led to issues,
but I think this is something else…

Cheers
(use-modules (gnu packages pretty-print)
 (gnu packages pkg-config)
 (guix packages)
 (guix gexp)
 (guix transformations)
 (guix build-system meson)
 ((guix licenses) #:select (gpl3+))
 ((guix git-download) #:select (git-file-name))
 (srfi srfi-26))

(define why-hello
  (package
   (name "why-hello")
   (version "0")
   (source (file-union (git-file-name name version)
`(("hello.cpp" ,(plain-file "hello.cpp"
   "\
#include 

int
main()
{
  fmt::print (\"{}\\n\", \"Hello, world\");
  return 0;
}
"))
  ("meson.build" ,(plain-file "meson.build"
  "\
project('hello', 'cpp', default_options: ['cpp_std=c++20'])
executable('hello', files('hello.cpp'), install: true,
   dependencies: [dependency('fmt')])
")
   (build-system meson-build-system)
   (inputs (list fmt))
   (native-inputs (list pkg-config))
   (home-page (and=> (current-filename)
 (cute string-append "file://" <>)))
   (synopsis "Hello world")
   (description "This package provides a simple program that builds with
GCC/G++ normally, but fails miserably when the clang-toolchain is used.")
   (license gpl3+)))

(define why-hello-clang
  ((options->transformation
'((with-c-toolchain . "why-hello=clang-toolchain")))
   why-hello))

why-hello-clang

bug#70278: udevd[87]: specified group 'sgx' unknown

[Liliana Marie Prikler]

Am Donnerstag, dem 11.04.2024 um 09:58 +0200 schrieb Ludovic Courtès:
> Ludovic Courtès  skribis:
> 
> > Since the recent ‘gnome-team’ merge, we get this message at boot
> > time:
> > 
> >   udevd[87]: specified group 'sgx' unknown
> > 
> > Should we add ‘sgx’ to ‘%base-groups’?  (What is it for?)
> 
> Cc’ing Vivien & Liliana who might know more about this.
This seems related to Intel's Software Guard eXtensions, or, as we in
the free world like to call them Security paper Generator eXtensions. 
As far as I'm aware, these ought to be disabled anyway, and we might
want to drop the offending lines.  According to [1], there's only two
of them anyway.

Cheers

[1] https://wiki.linuxfromscratch.org/lfs/ticket/5265

bug#70165: D-Bus system service breaks reconfiguration when /var/run/dbus is present + /run and /var/run are on separate file systems.

[Liliana Marie Prikler]

Am Freitag, dem 05.04.2024 um 09:53 +0800 schrieb Hilton Chain:
> [H]ere's a reproducer:
> 
> --8<---cut here---start->8---
> test_dir="$(mktemp --directory)"
> 
> sudo mount --type tmpfs none "$test_dir"
> touch "$test_dir/test"
> 
> guile -c "(rename-file \"$test_dir/test\" \"/tmp/test\")"
> 
> sudo umount "$test_dir"
> rmdir "$test_dir"
> --8<---cut here---end--->8---
> 
> --8<---cut here---start->8---
> Backtrace:
> In ice-9/boot-9.scm:
>   1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>    5 (apply-smob/0 #)
> In ice-9/boot-9.scm:
>     724:2  4 (call-with-prompt ("prompt") #
> …)
> In ice-9/eval.scm:
>     619:8  3 (_ #(#(#)))
> In ice-9/command-line.scm:
>    185:19  2 (_ #)
> In unknown file:
>    1 (eval (rename-file "/tmp/tmp.9wyzRfQ28l/test" "/tmp/…")
> #)
>    0 (rename-file "/tmp/tmp.9wyzRfQ28l/test" "/tmp/test")
> 
> ERROR: In procedure rename-file:
> In procedure rename-file: Invalid cross-device link
> --8<---cut here---end--->8---
If I understand this reproducer correctly, there aren't even symbolic
links involved, are there?

Adding Ludo to CC, because this looks like a Guile bug to me.

Cheers

bug#70111: [PATCH] gnu: gnome-essential-extras: Propagate xdg-desktop-portal.

[Liliana Marie Prikler]

Am Mittwoch, dem 03.04.2024 um 14:11 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Dariqq  writes:
> 
> > xdg-desktop-portal (and xdg-desktop-portal-gnome) is needed for the
> > dark theme in Gnome 44 to work properly.
> > 
> > * gnu/packages/gnome.scm (gnome-essential-extras)[propagated-
> > inputs]: Add xdg-desktop-portal.
> > 
> > Change-Id: Id84626e6bc404e9607ee7f8f299ac90f24323081
> 
> Reviewed-by: Maxim Cournoyer 
> 
> Haven't tested it myself, but I trust the findings of Dariqq.
The desktop portal seems like a harmless propagation, so I trust your
trust.

Pushed.

bug#70165: D-Bus system service breaks reconfiguration when /var/run/dbus is present + /run and /var/run are on separate file systems.

[Liliana Marie Prikler]

Am Donnerstag, dem 04.04.2024 um 00:36 +0800 schrieb Hilton Chain:
> Hi,
> 
> I have /var/run and /run on separate file systems, recently I noticed
> system reconfiguration stopped with "guix system: error: rename-file:
> Invalid cross-device link":
> 
> --8<---cut here---start->8---
> newfstatat(AT_FDCWD, "/run", {st_mode=S_IFDIR|0755, st_size=440,
> ...}, AT_SYMLINK_NOFOLLOW) = 0
> newfstatat(AT_FDCWD, "/run/dbus", {st_mode=S_IFDIR|0700, st_size=40,
> ...}, AT_SYMLINK_NOFOLLOW) = 0
> mkdir("/run", 0777) = -1 EEXIST (File exists)
> mkdir("/run/dbus", 0777)    = -1 EEXIST (File exists)
> chown("/run/dbus", 988, 983)    = 0
> chmod("/run/dbus", 0755)    = 0
> symlink("/run/dbus", "/var/run/dbus")   = -1 EEXIST (File exists)
> readlink("/var/run/dbus", 0x1634730, 100) = -1 EINVAL (Invalid
> argument)
> openat(AT_FDCWD, "/var/run/dbus",
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 17
> newfstatat(17, "", {st_mode=S_IFDIR|0755, st_size=80, ...},
> AT_EMPTY_PATH) = 0
> getdents64(17, 0x16dfe10 /* 4 entries */, 32768) = 112
> rename("/var/run/dbus/system_bus_socket",
> "/run/dbus/system_bus_socket") = -1 EXDEV (Invalid cross-device link)
> close(13)   = 0
> write(2, "\33[1m\33[0mguix system: error: rena"..., 67guix
> system: error: rename-file: Invalid cross-device link
> ) = 67
> exit_group(1)   = ?
> +++ exited with 1 +++
> --8<---cut here---end--->8---
> 
> It's because /var/run/dbus was used for dbus service before, and now
> migration to /run/dbus is done with ‘rename-file’:
> 
> --8<---cut here---start->8---
> (rename-file (string-append "/var/run/dbus/" next)
>  (string-append "/run/dbus/" next))
> --8<---cut here---end--->8---
> 
> I think the logic can be improved for this case, but not sure how at
> the moment.
> What do you think?
Is there a *good* reason to have those be separate file systems? :D
What does the FHS say?

Anyhow, cross-fs symlinks and rename-file ought to work assuming that
both file-systems are already mounted.  Is one of them not needed for
boot?

Cheers

bug#70121: [PATCH] gnu: emacs-magit: Fix generation of autoloads.

[Liliana Marie Prikler]

* gnu/packages/emacs-xyz.scm (emacs-magit)[#:phases]: Replace ‘make-autoloads’
like the others.

Fixes: Magit autoloads are missing 
---
 gnu/packages/emacs-xyz.scm | 4 
 1 file changed, 4 insertions(+)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 975b26813a..f47f5fcb8a 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -1668,6 +1668,10 @@ (define-public emacs-magit
   (lambda args
 (with-directory-excursion "lisp"
   (apply (assoc-ref %standard-phases 'expand-load-path) 
args
+(replace 'make-autoloads
+  (lambda args
+(with-directory-excursion "lisp"
+  (apply (assoc-ref %standard-phases 'make-autoloads) args
 (replace 'install
   (lambda args
 (with-directory-excursion "lisp"

base-commit: 4d79a9cd6b5f0d8c5afbab0c6b70ae42740d5470
prerequisite-patch-id: c275e4e44896c8ab96e5cc9557ec5dc522d62fd0
prerequisite-patch-id: 1675bb658c90730025a744f7869a3566fb5cf41a
prerequisite-patch-id: 9c02fe03b70a5312cc982fd4b48e73e889a9afdf
-- 
2.41.0

bug#69800: [PATCH gnome-team] gnu: kcalendarcore: Disable failing test.

[Liliana Marie Prikler]

Am Samstag, dem 23.03.2024 um 11:15 +0100 schrieb Liliana Marie
Prikler:
> Am Samstag, dem 23.03.2024 um 10:07 +0100 schrieb Vivien Kraus:
> > * gnu/packages/kde-frameworks.scm (kcalendarcore) [#:phases]: Add
> > 'disable-failing-test.
> > 
> > Change-Id: Ia0a5828b032d1940f30a7d38ebd276e60929c310
> > ---
> LGTM
Also LGT cbaines on IRC, so pushed.

bug#69800: [PATCH gnome-team] gnu: kcalendarcore: Disable failing test.

[Liliana Marie Prikler]

Am Samstag, dem 23.03.2024 um 10:07 +0100 schrieb Vivien Kraus:
> * gnu/packages/kde-frameworks.scm (kcalendarcore) [#:phases]: Add
> 'disable-failing-test.
> 
> Change-Id: Ia0a5828b032d1940f30a7d38ebd276e60929c310
> ---
LGTM

bug#59489: [PATCH v3] gnu: gdm: Enable accessibility settings.

[Liliana Marie Prikler]

Am Dienstag, dem 20.02.2024 um 19:58 + schrieb Dariqq:
> gdm needs the "/share" subdirectory of these packages present in
> XDG_DATA_DIRS
> such that the accessibility settings work:
> - at-spi2-core: contains accessibility dbus service.
> - dconf: To be able to change settings.
> - gnome-control-center: icon.
> 
> * gnu/packages/gnome.scm (gdm)[inputs]: Add at-spi2-core, dconf,
> gnome-control-center.
> [phases]: Add wrap-accessibility-dependencies phase.
> 
> Change-Id: Ibfe8f1aee9c8fe0c06f895de121f0f84defe4773
> ---
I've rewritten the commit message slightly and pushed this to gnome-
team.  Thus closing.

Cheers

bug#69201: Emacs master-branch renamed comp-write-bytecode-file which emacs-utils depends on

[Liliana Marie Prikler]

Am Donnerstag, dem 15.02.2024 um 22:23 + schrieb Mekeor Melire:
> On Emacs' master-branch, the emacs-lisp function
> comp-write-bytecode-file has been renamed to comp--write-bytecode-
> file (i.e. to include a double dash) in this commit [1]:
> 
>     faa46eb8667c11a0725500a50e957eb78021c99f
>     Author: Andrea Corallo 
>     AuthorDate: Sun Feb 11 12:31:13 2024 +0100
>     Commit: Andrea Corallo 
>     CommitDate: Sun Feb 11 15:26:12 2024 +0100
> 
>     Rename a number of native compiler functions
> 
> Guix' function emacs-compile-directory from module (guix build
> emacs-utils) [2] depends on this emacs-lisp function.
> 
> Thus, when emacs-next-minimal is build from the above mentioned
> commit or later, it won't be possible to build packages that use
> emacs-build-system, when using
> --with-input=emacs-minimal=emacs-next-minimal, or in Guile code,
> argument "#:emacs emacs-next-minimal". This might be considered to be
> a minor issue as of right now.
> 
> It'll become a more general problem, when Emacs 30 is released.
Thanks for the heads-up.  Assuming the calling convention stays the
same, this should be easy to work around (using fboundp and resolving
to the right symbol).  Unfortunately, I have other work to experiment
on emacs-team right now, so if you find this pressing, I encourage you
to submit your own patch (against emacs-team, for the particular
procedure in emacs-utils).

Cheers

bug#59489: bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Liliana Marie Prikler]

Am Freitag, dem 09.02.2024 um 22:06 -0500 schrieb Maxim Cournoyer:
> Could someone confirm whether GDM is configurable when it comes to
> icons and fonts?
Without the context of Guix, it is.  Within the context of Guix, we'd
have to make gsettings functional for most (all?) changes to have an
effect.

Cheers

bug#68961: ASLR seems to be partially broken

[Liliana Marie Prikler]

Am Dienstag, dem 06.02.2024 um 23:57 +0100 schrieb Jonathan Brielmaier:
> Hi,
> 
> I found today an interesting blog post about broken ASLR (Address
> Space
> Layout Randomization) on Linux:
> https://zolutal.github.io/aslrnt/
> 
> Curious if this is also a problem on Guix System I did a quick test.
> 
> ```
> $ cat aslr.py
> from subprocess import check_output
> result = 0x0
> for _ in range(0,1000):
>  out = check_output("cat /proc/self/maps | grep libc | head -n1",
> shell=True).decode()
>  base_address = int(out.split('-')[0], 16)
>  result |= base_address
> print('libc: ' + hex(result))
> 
> resultld = 0x0
> for _ in range(0,1000):
>  out = check_output("cat /proc/self/maps | grep ld-linux | head
> -n1", shell=True).decode()
>  base_address = int(out.split('-')[0], 16)
>  resultld |= base_address
> print('ld-linux: ' + hex(resultld))
> ```
> 
> Running this on x86_64 system of mine results on two systems in:
> libc: 0x7ffa9000
> ld-linux: 0x7000
> 
> On the third system it prints:
> libc: 0x7000
> ld-linux: 0x7000
On my machine, this also prints 0x7000.  Perhaps 1000 runs are
not good enough to get truly random results with some RNGs.  Note that
we do have 51 bits of randomness here – perhaps not ideal, but afaik
the best we can do without breaking alignment.

> For 32bit it looks even worse (not sure if it's correct to test it
> like
> this):
> $ guix shell --system=i686-linux coreutils python -- python3 aslr.py
> libc: 0xf780
> ld-linux: 0xf7fff000
> 
> Not sure what we should do here. There seem to be some a kernel patch
> for Ubuntu available:
For 32 bit, try 
```
from subprocess import check_output
result = 0x
for _ in range(0,1000):
 out = check_output("cat /proc/self/maps | grep libc | head -n1",
shell=True).decode()
 base_address = int(out.split('-')[0], 16)
 result &= base_address
print('libc: ' + hex(result))

resultld = 0x
for _ in range(0,1000):
 out = check_output("cat /proc/self/maps | grep ld-linux | head -
n1", shell=True).decode()
 base_address = int(out.split('-')[0], 16)
 resultld &= base_address
print('ld-linux: ' + hex(resultld))
from subprocess import check_output
result = 0x
for _ in range(0,1000):
 out = check_output("cat /proc/self/maps | grep libc | head -n1",
shell=True).decode()
 base_address = int(out.split('-')[0], 16)
 result &= base_address
print('libc: ' + hex(result))

resultld = 0x
for _ in range(0,1000):
 out = check_output("cat /proc/self/maps | grep ld-linux | head -
n1", shell=True).decode()
 base_address = int(out.split('-')[0], 16)
 resultld &= base_address
print('ld-linux: ' + hex(resultld))
```
instead.  I get 0xf7c0 for libc and 0xf7e0 – meaning that the
first nibble is always the same, but more importantly, these are also
the addresses you'd get on each run.  So I'm pretty sure that ASLR'nt
applies to our 32 bit builds.

Since this is a known bug in the Linux kernel, I'd like to check
whether there's a fix we can backport.  We could of course also patch
our config aux-files like Ubuntu does in the meantime.

Cheers

bug#68912: Guix-home search paths shadow .config/guix/current

[Liliana Marie Prikler]

Am Samstag, dem 03.02.2024 um 13:12 + schrieb Christina O'Donnell:
> This leads to unexpected results if you have Guix inside your home 
> package list. (Which you might desire if you wanted to use Guix in a 
> home container.)
The wisdom "One does not simply 'guix install guix'" has been passed
around for ages.  Same applies to home configurations, which merely
mimic that aspect.  There are valid reasons for using Guix in temporary
shells (or home containers), but also many pathological uses.

> [T]he situation is preventable and undesirable and there's several
> possible solutions:
> 
>   1. Reorder the paths by default, keeping ~/.config/guix in front of
> ~/.guix-home
As far as I know, this requires changing the order in which files are
sourced, and it's not clearly desirable that ~/.config/guix ought to
shadow ~/.guix-home or ~/.guix-profile.  In particular, whenever you
use `guix shell` or similar, you will shadow that anyway.

>   2. Have `guix home` warn when 'guix' is included as a package
This might be fine, but what about the home container use-case then? 
I'm not sure whether having no guix in containers is preferable over
having a slightly outdated one – at the very least, my personal usage
of GWL through `guix shell' is enough reason to keep guix visible as a
package.

>   3. Have `guix pull` warn when Guix is shadowed and unable to be
> updated
This would (at least in a naive version) print a weird warning on fresh
setups, where the not yet created local ~/.config/guix is not yet on
PATH.  As far as I know, this would be doable, though, if you're smart
enough about it.

> (Incidentally, how did gzip and coreutils get in there? I didn't put
> it there.)
These might have been added by the home container for reason
unbeknownst to me.

> hint: After setting `PATH', run `hash guix' to make sure your shell 
> refers to `/home/cdo/.config/guix/current/bin/guix'.
Hint: this is the warning you're looking for.  It's phrased as a hint,
because people typically only encounter it once during setup.

Cheers

bug#68982: Ren'py 8.2.0 Crash on startup

[Liliana Marie Prikler]

Am Mittwoch, dem 07.02.2024 um 14:38 -0600 schrieb msglm:
> When starting the ren'py launcher on version Ren'Py 8.2.0.24012702,
> currently my guix channel is on commit
> 5d2302a1959d09e6d5a5f02ac199458095847a82, the program crashes with
> the following error:
> 
> Full traceback:
>   File "/gnu/store/2m851i42kc8i929rfhrn6w545w6a94lz-python-renpy-
> 8.2.0/lib/python3.10/site-packages/renpy/bootstrap.py", line 354, in
> bootstrap
>     renpy.config.logdir = renpy.__main__.path_to_logdir(basedir)
> AttributeError: module '__main__' has no attribute 'path_to_logdir'
If you have a local guix checkout, try adding the following lines to
gnu/packages/aux-file/renpy.in:

  def path_to_logdir(basedir):
  return basedir

However, it seems upstream also has a predefined_searchpath added in
8.2, and changed the semantics of path_to_saves.  I think we might want
to revert to 8.1 to deal with all those changes properly.

Cheers 

bug#59489: bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Liliana Marie Prikler]

Am Montag, dem 05.02.2024 um 16:08 + schrieb Dariqq:
> 
> On 04.02.24 20:26, Liliana Marie Prikler wrote:
> 
> > Yes, it seems Maxim and I have conflicting goals.  Maxim wants to
> > avoid "abusing" gnome-shell-assets whereas I want to avoid
> > propagation, as it pollutes profiles.  Perhaps Maxim and I can
> > agree on how to interpret gnome-shell-assets, as IIUC even with
> > packages that aren't "pure data" only the data portion of it ought
> > to be relevant, no?
> > 
> > We should do so especially because the newly propagated variables
> > are anyhow propagated by gnome-desktop-service, which could
> > constitute weird behaviour all around.
> > 
> > Cheers
> 
> What would you think of the wrap-program solution which would avoid 
> propagating pacakges?
> 
> I currently have something like
> 
> #+BEGIN_SRC scheme
> (add-after 'install 'wrap-gdm
>  (lambda* (#:key inputs outputs #:allow-other-keys)
>    (wrap-program (string-append #$output "/bin/gdm")
>  `("XDG_DATA_DIRS" ":" prefix
>    #$(map (lambda (input)
>    (file-append (this-package-input input) 
> "/share"))
>  '("at-spi2-core"
>    "dconf"
>    "gnome-control-center"))
> #+END_SRC
> 
> Also this way the assets (adwaita and cantarell) should be kept in
> the gdm-configuration as when I tested this I had a white box as a
> cursor.
That SGTM, but we do need a more descriptive phase name.  The question
is whether we should inline the gnome-shell assets this way as well or
not.

Maxim, WDYT?

bug#59489: bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Liliana Marie Prikler]

Am Sonntag, dem 04.02.2024 um 08:53 + schrieb Dariqq:
> 
> On 30.01.24 06:27, Liliana Marie Prikler wrote:
> 
> > In my opinion, adding gnome-shell and gnome-control-center to gdm-
> > configuration-gnome-shell-assets would be preferable to propagating
> > inputs.
> > 
> > WDYT?
> 
> 
> This is basically my original patch in
> https://issues.guix.gnu.org/57292#3.
> 
> If i understand it correctly Maxim wants gdm to take care of all of 
> dependencies providing functionality and handcrafting the environment
> with gdm-shepherd-service and gdm-configuration-gnome-shell-assets
> feels like a hacky workaround.
Yes, it seems Maxim and I have conflicting goals.  Maxim wants to avoid
"abusing" gnome-shell-assets whereas I want to avoid propagation, as it
pollutes profiles.  Perhaps Maxim and I can agree on how to interpret
gnome-shell-assets, as IIUC even with packages that aren't "pure data"
only the data portion of it ought to be relevant, no?

We should do so especially because the newly propagated variables are
anyhow propagated by gnome-desktop-service, which could constitute
weird behaviour all around.

Cheers

bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Liliana Marie Prikler]

Am Montag, dem 29.01.2024 um 21:31 + schrieb Dariqq:
> * gnu/packages/gnome.scm (gdm)[propagated inputs]: Add adwaita-icon-
> theme,
> dconf, font-abattis-cantarell, gnome-control-center.
> * gnu/services/xorg.scm (gdm-shepherd-service): Set XDG_DATA_DIR to
> run/current-system/profile/share.
> (gdm-profile-service): New variable.
> (gdm-service-type): Use gdm-profile-service.
> (gdm-configuration-gnome-shell-assets): Set default to gnome-shell.
> 
> Change-Id: I870206a9ee6a7481d19e6b38b6a3ee72b5801c6a
> ---
> Hi Maxim and others,
> This is not quite the explicit wrapper we talked about on IRC but
> something similiar.
> 
> The gdm package now propagates the packages from gnome-shell-assets
> and I added dconf and gnome-control-center for basic accessibility
> settings functionality + icon. Does this introduce a problem as dconf
> is already a natice input?
> Maybe also some other packages can be added like  at-spi2-core, orca,
> ... or is this something the user should add to the system profile
> themselves?
> 
> In order for the gdm-shepherd-service to find the propagated packages
> I changed the XDG_DATA_DIR of the service to the system profile and
> added a gdm-profile-service to add gdm and gnome-shell to the system
> profile. Probably the gnome-shell-assets name should now also be
> changed as is is now only the gnome-shell package.
> 
> What do you think?
In my opinion, adding gnome-shell and gnome-control-center to gdm-
configuration-gnome-shell-assets would be preferable to propagating
inputs.

WDYT?

bug#68231: Frei?

[Liliana Marie Prikler]

close 68231
thanks

Hallo, Enzo

Am Dienstag, dem 02.01.2024 um 23:11 +0100 schrieb Enzo Brandsch:
> ich bin leider aus Gründen „gezwungen“ unfreie Software auf meinem
> Laptop zu nutzen. Würde aber sehr sehr gerne Guix als daily-driver
> nutzen. [...]
> PS: Mein Problem ist ein Intel Wifi Treiber. Laptop ist ein ThinkPad
> Yoga. Ich habe bis jetzt immer Arch benutzt werde aber nun bis Guix
> meine WLAN-Karte erkennt Clear nutzen.
Es ist meines Wissens (und leider auch Erfahrung) nach möglich, einen
Laptop ohne WLAN-Karte zu betreiben.  Freilich ist das etwas
umständlicher, weil du dich dann nach herumliegenden Ethernet-Kabeln
umsehen musst, aber je nachdem wofür du diesen Laptop verwendest,
sollte es möglich sein, eine Kabelverbindung z.B. zum Betriebsnetz
aufzubauen.

Du könntest auch, so dein Laptop es zulässt, eine freie WLAN-Karte oder
einen Adapter benutzen.  Generell empfehlenswert ist RYF-zertifizierte
Hardware, z.B. [1], aber auch andere Seiten können dir helfen, in
Erfahrung zu bringen, wie gut bestimmte Komponenten mit freier Software
funktionieren. 

> Wäre es für solche Fälle möglich auch unfreie Software zuzulassen?
> Ich kenne mich etwas mit Linux aus habe mir aber noch nie Lizenzen
> angesehen und werde vermutlich in naher Zukunft auch kein Auge darauf
> werfen.
Die GNU FSDG [2], an der wir uns orientieren, ist diesbezüglich sehr
eindeutig: 
  A free system distribution must not steer users towards obtaining any
  nonfree information for practical use, or encourage them to do so.
Zu Deutsch:
  Eine freie Systemdistribution darf Nutzer·innen weder dazu verleiten,
  unfreie Information für den praktischen Gebrauch zu erhalten, noch 
  sie darin unterstützen.

Zum Punkt WLAN-Karte weiters
  Some applications and drivers require firmware to function, 
  and sometimes that firmware is distributed only in object code 
  form, under a nonfree license. [...] [N]o matter how it's encoded,
  any nonfree firmware needs to be removed from a free system.

Zu Deutsch:
  Einige Anwendungen oder Treiber benötigen „Firmware“, um   
  zu funktionieren, und diese Firmware ist manchmal nur als Objekt-Code
  unter einer nichtfreien Lizenz vorhanden.  [...] [A]ber egal, in
  welcher Form diese nichtfreie Firmware aufliegt, sie muss von einem
  freien System entfernt werden.

> Als Kompromiss könnte man ja zum installieren von unfreier Software
> mehrere Schritte hinzufügen welche sicherstellen das man unfreie
> Software installieren möchte/muss.
Dieser Kompromiss gilt tatsächlich auf Festen zur Installierung von
Linux-Distributionen [3], nicht aber (wie hier) auf zum GNU-Projekt
gehörenden öffentlichen Mailing-Listen, oder IRC-Kanälen.  Auf solchen
Plattformen sind Diskussionen über nichtfreie Software zu unterlassen.

Liebe Grüße,
Liliana

[1] https://ryf.fsf.org/categories/wireless-adapters
[2] https://www.gnu.org/distros/free-system-distribution-guidelines.html
[3] https://www.gnu.org/philosophy/install-fest-devil.html

bug#66173: Package unknown-horizons fails during build process

[Liliana Marie Prikler]

Am Samstag, dem 13.01.2024 um 10:50 -0500 schrieb Simon South:
> Liliana, 宋文武:
> 
> Are you interested in reviewing these patches?  Unfortunately I
> neglected to CC the games team when posting them.
> 
> They fix the build of Unknown Horizons in master.
> 
> https://issues.guix.gnu.org/66173
> 
> -- 
I came, saw, and pushed.

Sorry for not coming earlier.

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Liliana Marie Prikler]

Am Dienstag, dem 09.01.2024 um 12:10 +0100 schrieb Vivien Kraus:
> Dear Guix,
> 
> [...]
I know that a bunch of packages have reasons not to exist in Guix, I
simply wanted to point out that we don't have them.

> > I think we should settle on what to do with the gnome package soon
> > to not stall the branch even further.  We can already start working
> > towards GNOME 46 after the merge :)
> In my opinion, we should have atkmm:2.28.3, but I see atkmm-2.28
> being used as a propagated-inputs for gtkmm-3, and gtkmm-3 is an
> input for inkscape. That’s a world rebuild…
> 
> For Cantarell fonts, maybe we should point to the latest commit?
> That’s another world rebuild though, and for very little gain as of
> now.
> 
> I’m not sure a flatpak-only gnome software is a hard requirement. It
> would be most confusing. Gnome-tour is nice, but I think we can live
> without it until we figure out this “rust” stuff.
With "the gnome package" I mean the gnome metapackage that made you
raise this issue.

> > There is some gnome-adjacent software (particularly extensions, I
> > don't want all of them to break like they did the last time and the
> > time before) to have a look at as well before the merge
> 
> You mean, the gnome-shell-extension-* in (gnu packages gnome-xyz)? I
> don’t use them (I was told they were frequently broken so I never
> bothered to try them!) so I’m not sure I can reliably tell whether
> they work correctly.
They tend to get broken with each gnome update, but I'm here to change
that.  Testing them is actually quite simple: construct a guix system
vm with a gnome that has all the extensions, run it, then enable all of
them one by one in the GUI.  If there's a version incompatibility, you
will notice.

Cheers

bug#68243: alacritty segmentation fault

[Liliana Marie Prikler]

Am Donnerstag, dem 04.01.2024 um 15:32 + schrieb Steven Roose:
> I've been using alacritty as my default terminal for about a year 
> without much issues. I'm currently on v0.12.3 of alacritty and use it
> with i3 and Xorg. A month or two ago I noticed that upgrading GuixSD 
> broke alacritty. Since it's my main terminal and I didn't have any
> other terminals installed, I was forced to rollback my system through
> GRUB because I couldn't literally not even open a terminal to
> investigate or roll-back by CLI. I was trying another system upgrade
> now and noticed the issue is still not fixed. When running alacritty
> from an already-open alacritty only shows me "segmentation fault".
> The working and broken version is both 0.12.3, so I think it might
> not be an alacritty issue but more a linking/build issue. I'm
> basically stuck on a months-old Guix until this is fixed.
> 
> If there is any way I can be of use by providing debug/log files of
> some kind, please let me know.
I suppose this might be related to the mesa update we had some while
ago.  I myself noticed that GNOME 4 apps stopped working due to some
very, very weird behaviour of the driver that I still don't comprehend.
Anyway, switching to the cairo renderer per environment variable worked
for me.  Perhaps there's something similar you can do for alacritty (or
otherwise switch back to the older mesa with an inferior/use any other
VTE for the time being).

Cheers

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Liliana Marie Prikler]

Am Dienstag, dem 05.12.2023 um 21:55 +0100 schrieb Vivien Kraus:
> Dear guix,
> 
> On the one hand, we have this list of packages:
> https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions
For the record, we have a new 44 release:
https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.7/versions

I've summarised our TODOs below: Each commented line (preceded by #)
denotes a package that doesn't exist on the gnome-team branch yet.

core:atkmm:2.28.3:
#core:calls:44.2:
core:font-abattis-cantarell:0.303.1:
core:epiphany:44.7:
#core:gnome-logs:43.0:
#core:gnome-software:44.5:
#core:gnome-tour:44.0:

I think we should settle on what to do with the gnome package soon to
not stall the branch even further.  We can already start working
towards GNOME 46 after the merge :)

There is some gnome-adjacent software (particularly extensions, I don't
want all of them to break like they did the last time and the time
before) to have a look at as well before the merge, but it looks like a
nice road ahead.

We can do this!

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Liliana Marie Prikler]

Hi Vivien,

Am Dienstag, dem 05.12.2023 um 21:55 +0100 schrieb Vivien Kraus:
> Dear guix,
> 
> On the one hand, we have this list of packages:
> https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions
> 
> On the other hand, we have the propagated-inputs of the gnome
> package.
> 
> Should we update the latter so that it contains everything from the
> former? 
No.

> What should we do about the comments dividing the propagated-
> inputs into categories? Where do these categories come from? 
The categories are roughly inferred from a previous categorisation of
GNOME Apps.  It is a little arcane and should probably be updated to
reflect  (roughly).  Note that we'll
still be using the Core Apps from GNOME 44, which are listed in [1].
 
> Should we preserve them? How do we know which package goes to which
> category?
We should try to update them and better keep with upstream terms.  I
think it also makes sense to split the gnome meta-package into multiple
meta packages and adjust the gnome-desktop service accordingly.  For
one, we do need a gnome-shell-meta that has everything required to get
a running gnome-shell, even without any of the other core applications.
Then, gnome-core-main, gnome-core-mobile and gnome-core-tools could
hold the main, mobile and developer tools in the core apps
respectively.

> The gnome package disables eog on 32-bit machines because it depends
> on librsvg-next. It seems a bit outdated to me, as most of gnome
> won’t work on 32-bit machines, not only eog. Should we try and find
> which ones work on 32-bit systems?
Seeing how GNOME 45 deprecates eog in favour of loupe, yet another
bootstrap and build system nightmare, we should anyhow look into what's
buildable on 32-bit machines and offer suitable replacements.  I'm very
much a proponent of reducing the amount of software on our GNOME stack,
not piling yet another heap of checksums onto it and calling dependency
management done.

Cheers

[1] https://blogs.gnome.org/mcatanzaro/2023/05/10/gnome-core-apps-update/

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Liliana Marie Prikler]

Am Donnerstag, dem 09.11.2023 um 12:21 +0100 schrieb Josselin Poiret:
> Hi,
> 
> Liliana Marie Prikler  writes:
> 
> > Am Donnerstag, dem 02.11.2023 um 08:13 + schrieb Mekeor Melire:
> > > 
> > > 2023-11-01 15:16 liliana.prik...@gmail.com:
> > > 
> > > > I think Emacs might be calculating its own hash at runtime 
> > > > rather than baking in the value at build time.
> > > 
> > > Exactly. That's what I was trying to express.
> > I'm not sure whether this is reproducible.  On my system
> >   $ guix build emacs-dash --with-input=emacs-minimal=emacs
> >   /gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-2.19.1
> >   $ ls /gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-
> > 2.19.1/lib/emacs/native-site-lisp
> >   29.1-e9e5c1ce
> >   $ emacs --batch --eval='(message "%s" comp-abi-hash)'
> >   e9e5c1ce
> > Looks like everything's alright?
> 
> It's the .eln file itself that has the hash of the .el's path in its
> name.  That's computed by `comp-el-to-eln-filename`.
Does this still occur on the emacs-team branch, where we compile
everything from the build directory?

Cheers

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Liliana Marie Prikler]

Am Donnerstag, dem 02.11.2023 um 08:13 + schrieb Mekeor Melire:
> 
> 2023-11-01 15:16 liliana.prik...@gmail.com:
> 
> > I think Emacs might be calculating its own hash at runtime 
> > rather than baking in the value at build time.
> 
> Exactly. That's what I was trying to express.
I'm not sure whether this is reproducible.  On my system
  $ guix build emacs-dash --with-input=emacs-minimal=emacs
  /gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-2.19.1
  $ ls 
/gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-2.19.1/lib/emacs/native-site-lisp
  29.1-e9e5c1ce
  $ emacs --batch --eval='(message "%s" comp-abi-hash)'
  e9e5c1ce
Looks like everything's alright?

Cheers

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Liliana Marie Prikler]

Am Mittwoch, dem 01.11.2023 um 13:03 + schrieb Mekeor Melire:
> The problem is that the .el-file-path that is passed to the Emacs
> function comp-el-to-eln-filename during build [1] does not equal to
> the .el-file-path when Emacs is invoked. Personally, I do not 
> understand how grafting causes this. But I can confirm that when 
> --no-grafts is passed to "guix install emacs emacs-unfill 
> --with-input=emacs-minimal=emacs", then no eln-cache is created.
I think Emacs might be calculating its own hash at runtime rather than
baking in the value at build time.  I would need to investigate this,
however.

Cheers

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Liliana Marie Prikler]

Am Dienstag, dem 31.10.2023 um 23:49 + schrieb Mekeor Melire:
> BUG EXPLANATION
> 
> Emacs's natively-compiled .eln-files have a basename following the
> pattern "{feature-name}-{path-hash}-{content-hash}.eln". [0]
> 
> Guix' emacs-build-system is used to build Emacs-related packages. By 
>  default, it uses the "emacs-minimal" package during build, which 
>  does not support native-compilation. But if you replace the 
>  "emacs-minimal" input with "emacs-no-x", e.g. by using 
>  --with-input=emacs-minimal=emacs-no-x, then emacs-build-system 
>  will make use of emacs-no-x' support of native-compilation [1]: 
>  The build will contain .eln-files.
> 
> Hereby I'd like to report the bug that consists of mismatched path-
> hashes in the .eln-files that builds of Emacs-related packages
> contain when build with emacs-no-x (or any other Emacs that supports
> native compilation).
> 
> BUG REPRODUCTION
> 
> To reproduce this bug follow the following steps. Please note that
> guix-shell seems to leak .eln-files. (This should be reported as 
> another bug.)
What do you mean by "leaks .eln-files"?

> That why the reproduction steps avoid guix-shell.  Instead, we'll
> work with the current user profile.
> 
> Delete Emacs' eln-cache (so that we can later see if new 
> .eln-files have been generated):
> 
> rm -rf ~/.emacs.d/eln-cache
> 
> Remove all Emacs- and Emacs-related packages from Guix profile:
> 
> guix package -I | cut -f 4 | grep emacs | xargs guix remove
> 
> Install Emacs and emacs-unfill, as exemplary package, while 
> replacing input "emacs-minimal" with "emacs", so that .eln-files 
> are generated during the build:
> 
> guix install emacs emacs-unfill 
> --with-input=emacs-minimal=emacs
Just deleting the eln-cache should be enough for a MWE.  When doing an
MWE, make sure that its actually minimal :)

> Launch the freshly installed Emacs and load the "unfill" package. 
> If the .eln-files that the emacs-unfill package provides match 
> Emacs' expectations (path- and content-hash), it'll use it; 
> otherwise, Emacs will compile a new .eln-file and save it into 
> ~/.emacs.d/eln-cache/*/unfill-{path-hash}-{content-hash}.eln.
> 
> emacs -q --eval "(require 'unfill)"
> 
> Close Emacs after some seconds. Now determine the path-hash from 
> Guix' build:
> 
> basename 
> ~/.guix-profile/lib/emacs/native-site-lisp/*/unfill-*.eln \
>   | cut -d - -f 2
> 
> Determine the path-hash from Emacs' native-compilation, which 
> apparently has happened:
> 
> basename ~/.emacs.d/eln-cache/*/unfill*.eln \
>   | cut -d - -f 2
This is already the bug.  There should not be a file written to the
eln-cache (save for the trampolines that we still write there, which is
also a known bug among those who care).

> The path-hashes from the last two steps are not equal.
> 
> BUG SOLUTION HINTS
> 
> In the #guix:libera.chat IRC channel, jpoiret pointed out: "the .eln
> file hash problem is due to grafts, grafts change the 
> final output name, but they can't also update the file hashes... 
> we'd need to modify emacs' behavior for this to work".
As jpoiret points out, this has to do with the file naming choices of
Emacs, not with emacs-build-system per se.  We would need to get rid of
a lot of hashes if we wanted interoperable native-compiled Emacs
libraries.  I wonder what upstream has to say about this.

Cheers

bug#66762: emacs-ess test fails

[Liliana Marie Prikler]

Am Freitag, dem 27.10.2023 um 11:22 +0200 schrieb Simon Tournier:
> Well, I fixed the build of emacs-julia-mode.  See attached.
Pushed attached with slight rewordings.

> But emacs-ess is not passing.  I have updated ESS to the most recent
> revision, added phases for skipping the tests requiring network but
> it still fails:
> 
> [...]
> 
> To be continued…
Leaving this open for whoever wishes to continue.

Cheers

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 23:03 +0200 schrieb b...@bokr.com:
> Hi,
> 
> On +2023-10-09 20:33:38 +0200, Liliana Marie Prikler wrote:
> > I don't necessarily agree, but it's not a hard disagree either. 
> > I'll try to keep that in mind at least when reviewing your patches
> > to not cause confusion.
> > 
> > Cheers
> > 
> 
> TL;DR: Would it make sense to anticipate that LLM-bots will be used
> to automate gathering of info for reviewers?
> 
> If so, what would a style guide for english in posts (like
> a coding style guide, but for LLM-bot consumption) look like?
> Some kind of literate programming for LLM-bot and human use?
Let's not rely on large language models.  If we are going to automate
this, it ought to be through interpretable, "rule-based" systems. 
Like, imagine that on top of telling debbugs to close a bug etc., you
could tell debbugs (or some other tool) that some patch or a series
looks good to you.  We could then add an interface to allow filtering
for "looks good" series for quick patch application, the rationale
being that committers have to do less or no review of their own as they
commit to a patch or series.*

Cheers

* They should still check that the series actually looks good to enough
folks.

bug#66339: [PATCH gnome-team v6] gnu: dbus-service: make the session available under /run/dbus

[Liliana Marie Prikler]

Am Sonntag, dem 08.10.2023 um 16:53 +0200 schrieb Liliana Marie
Prikler:
> [...]
> Otherwise LGTM.  I'd commit it, but my machine is currently busy
> building half of core-updates for no reason.
No longer busy, time to commit.

Thanks

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 15:25 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> > Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
> > > Hello,
> > > 
> > > Liliana Marie Prikler  writes:
> > > 
> > > > [...]
> > > > If you need me to reduce it to four letters, yes, LGTM.
> > > 
> > > Explicit is better than implicit.  I've been thinking to document
> > > this in our contributing section; e.g. a reviewed commit must
> > > have the 'LGTM' from the reviewer.  If a series is LGTM, it needs
> > > to be implicitly mentioned with 'this series LGTM'.  That may
> > > sound silly, but I think it'd simplify reviewer/submitters
> > > interactions.
> > s/implicitly/explicitly/?
> 
> Explicit, indeed.
> 
> > I don't necessarily agree, but it's not a hard disagree either. 
> > I'll try to keep that in mind at least when reviewing your patches
> > to not cause confusion.
> 
> OK.  One place where this becomes more important is when the send-
> email cc hook includes people partially to a series. A LGTM on a
> single message in this case could be misinterpreted for the whole
> series.  It's best to document the expectations and codify these
> often used signals, in my opinion.
I personally prefer to comment to all individual patches or use the
series starter for "this series LGTM", but to recap; 1 and 2 L'd GTM
(with a small caveat for 1) already and we discussed 3 in IRC, so LGTM
for the series.

Cheers

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Liliana Marie Prikler  writes:
> 
> > [...]
> > If you need me to reduce it to four letters, yes, LGTM.
> 
> Explicit is better than implicit.  I've been thinking to document
> this in our contributing section; e.g. a reviewed commit must have
> the 'LGTM' from the reviewer.  If a series is LGTM, it needs to be
> implicitly mentioned with 'this series LGTM'.  That may sound silly,
> but I think it'd simplify reviewer/submitters interactions.
s/implicitly/explicitly/?

I don't necessarily agree, but it's not a hard disagree either.  I'll
try to keep that in mind at least when reviewing your patches to not
cause confusion.

Cheers

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 10:21 -0400 schrieb Maxim Cournoyer:
> Hi Liliana :-)
> 
> Liliana Marie Prikler  writes:
> 
> > Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
> > > It's simpler to add features on top of a minimal variant than to
> > > remove them, and helps avoiding mistakenly changing git-minimal,
> > > which has many dependents.
> > > 
> > > * gnu/packages/version-control.scm (git-minimal): Move above git
> > > and severe inheritance.  Remove input label.  Repatriate most
> > > fields from...
> > > (git): ... here.  Define as package/inherit to inherit from git-
> > > minimal.
> > > Extend minimal values instead of overriding them whole.
> > > ---
> > Having done the same to Emacs recently, I fully agree with this
> > move.
> 
> Great; does this mean a LGTM on your side for this one?  Please be
> explicit :-).
If you need me to reduce it to four letters, yes, LGTM.

bug#66339: [PATCH gnome-team v6] gnu: dbus-service: make the session available under /run/dbus

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> According to
> https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101, glib
> now searches for the session bus socket in runstatedir. The dbus
> service must thus have its socket in /run/dbus.
> 
> For interoperability with the dbus standard, /run/dbus is also
> symlinked to
> /var/run/dbus.
> 
> * gnu/services/dbus.scm (dbus-activation): Symlink /run/dbus to
> /var/run/dbus.
> (%dbus-accounts): Run dbus in /run/dbus.
> (dbus-root-service-type): Save the pid file in /run/dbus.
> ---
> 
> Hello,
> 
> I changed my mind back to a previous mind change, so: the socket
> should be
> installed in /run.  I believe that the code moves the content of the
> existing
> /var/run/dbus to /run/dbus before trying the symlink again, if
> /var/run/dbus
> exists and is not a symlink to /run/dbus.  I don’t really have a way
> to check
> the interesting case where existing files need to be moved.  However,
> the
> gnome-team-configured VM works.
> 
> Best regards,
> 
> Vivien
> 
>  gnu/services/dbus.scm | 39 ---
>  1 file changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
> index 5a0c634393..aa9ce0720c 100644
> --- a/gnu/services/dbus.scm
> +++ b/gnu/services/dbus.scm
> @@ -163,7 +163,7 @@ (define %dbus-accounts
>   (group "messagebus")
>   (system? #t)
>   (comment "D-Bus system bus user")
> - (home-directory "/var/run/dbus")
> + (home-directory "/run/dbus")
>   (shell (file-append shadow "/sbin/nologin")
>  
>  (define dbus-setuid-programs
> @@ -186,7 +186,40 @@ (define (dbus-activation config)
>  (let ((user (getpwnam "messagebus")))
>    ;; This directory contains the daemon's socket so it must
> be
>    ;; world-readable.
> -  (mkdir-p/perms "/var/run/dbus" user #o755))
> +  (mkdir-p/perms "/run/dbus" user #o755))
> +
> +    (catch 'system-error
> +  (lambda ()
> +    (symlink "/run/dbus" "/var/run/dbus"))
> +  (lambda args
> +    (let ((errno (system-error-errno args)))
> +  (cond
> +   ((= errno EEXIST)
> +    (let ((existing-name
> +   (false-if-exception
> +    (readlink "/var/run/dbus"
> +  (unless (equal? existing-name "/run/dbus")
> +    ;; Move the content of /var/run/dbus to
> /run/dbus, and
> +    ;; retry.
> +    (let ((dir (opendir "/var/run/dbus")))
> +  (let move-to-/run/dbus ((next (readdir dir)))
> +    (cond
> + ((eof-object? next)
> +  (closedir dir))
> + ((member next '("." ".."))
> +  (move-to-/run/dbus (readdir dir)))
> + (else
> +  (begin
> +    (rename-file (string-append
> "/var/run/dbus/" next)
> + (string-append "/run/dbus/"
> next))
> +    (move-to-/run/dbus (readdir dir
I'd rename "move-to-/run/dbus" to the boring but more idiomatic "loop".
This saves us some horizontal real-estate that'd allow us to squash
some lines.
> +  (rmdir "/var/run/dbus")
> +  (symlink "/run/dbus" "/var/run/dbus")))
> +   (else
> +    (format (current-error-port)
> +    "Failed to symlink /run/dbus to
> /var/run/dbus: ~s~%"
> +    (strerror errno))
> +    (error "cannot create /var/run/dbus"))
>  
>  (unless (file-exists? "/etc/machine-id")
>    (format #t "creating /etc/machine-id...~%")
> @@ -210,7 +243,7 @@ (define dbus-shepherd-service
>   '(#:environment-variables
> '("DBUS_VERBOSE=1")
>     #:log-file "/var/log/dbus-
> daemon.log")
>   '())
> -  #:pid-file "/var/run/dbus/pid"))
> +  #:pid-file "/run/dbus/pid"))
>  (stop #~(make-kill-destructor)))
>  
>  (define dbus-root-service-type
> 
> base-commit: b18b2d13488f2a92331ccad2dc8cbb54ee15582f
Otherwise LGTM.  I'd commit it, but my machine is currently busy
building half of core-updates for no reason.

Cheers

bug#65924: [PATCH core-updates 1/3] gnu: git: Remove labels and use gexps.

[Liliana Marie Prikler]

Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
> * gnu/packages/version-control.scm (git)
> [native-inputs, inputs]: Remove labels.
> [arguments]: Use gexps.  Use gexp variables input searching
> procedures where it makes sense.
> ---
Heads-up, the additional completions I'm installing in 66171 will cause
a merge conflict here (they need to go to core-updates due to git being
git and git-minimal still changes accordingly on master).  IIUC it
should be easier to apply your changes first and then mine.  IMHO,
completions shouldn't go to git-minimal, but reading 2/3 (i.e. reading
without applying) I'm not quite sure where they end up atm.

Cheers

bug#65924: [PATCH core-updates 2/3] gnu: git: Invert inheritance relationship.

[Liliana Marie Prikler]

Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
> It's simpler to add features on top of a minimal variant than to
> remove them, and helps avoiding mistakenly changing git-minimal,
> which has many dependents.
> 
> * gnu/packages/version-control.scm (git-minimal): Move above git and
> severe inheritance.  Remove input label.  Repatriate most fields
> from...
> (git): ... here.  Define as package/inherit to inherit from git-
> minimal.
> Extend minimal values instead of overriding them whole.
> ---
Having done the same to Emacs recently, I fully agree with this move.

bug#66227: [bug#66225] [PATCH v3] gnu: emacs-next-minimal: Apply Guix patches.

[Liliana Marie Prikler]

Am Samstag, dem 07.10.2023 um 09:56 +0400 schrieb Andrew Tropin:
> On 2023-10-06 17:58, Liliana Marie Prikler wrote:
> 
> > * gnu/packages/patches/emacs-next-native-comp-driver-options.patch:
> > Add file.
> > * gnu/packages/patches/emacs-next-exec-path.patch: Add file.
> > * gnu/local.mk (dist_patch_DATA): Register them here.
> > * gnu/packages/emacs.scm (emacs-next-minimal)[origin](patches):
> > Include the same patches as emacs-minimal, save for the variants
> > specific to emacs-next introduced above.
> > 
> > Co-Authored-By: Nicolas Graves 
> > Fixes: ‘emacs-next’ is almost unusable <https://bugs.gnu.org/66227>
> > […]
> 
> Hi Liliana and Nicolas, the fixes looks good to me.
Thanks for checking.  I pushed it now (perhaps a bit too hasty, but
it's been a problem for some while).

Cheers

bug#66339: [PATCH gnome-team v4] gnu: dbus-service: make the session available under /run/dbus

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> According to
> https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101, glib
> now searches for the session bus socket in runstatedir. The dbus
> service must thus have its socket in /run/dbus.
> 
> For interoperability with the dbus standard, /run/dbus is also
> symlinked to /var/run/dbus.
> 
> * gnu/services/dbus.scm (dbus-activation): Symlink /run/dbus to
> /var/run/dbus.
> (%dbus-accounts): Run dbus in /run/dbus.
> (dbus-root-service-type): Save the pid file in /run/dbus.
> ---
> 
> > Perhaps, but it's not okay to fail if it's a regular directory.  We
> > should
> > move those!
> 
> I’m not sure I understand.  What comes to my mind is:
> 
> 1. Try to make the symlink. If it fails with EEXIST:
> 2. Try to read /var/run/dbus as a symlink. If it points to /run/dbus
> already,
>    stop. Otherwise:
> 3. Move everything in /var/run/dbus to /run/dbus.
> 4. Delete the now-empty /var/run/dbus.
> 5. Symlink /run/dbus to /var/run/dbus.
> 
> Is it what you meant?
Yep, that's what I meant.

> Best regards,
> 
> Vivien
> 
>  gnu/services/dbus.scm | 38 +++---
>  1 file changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
> index 5a0c634393..44bf0c910b 100644
> --- a/gnu/services/dbus.scm
> +++ b/gnu/services/dbus.scm
> @@ -163,7 +163,7 @@ (define %dbus-accounts
>   (group "messagebus")
>   (system? #t)
>   (comment "D-Bus system bus user")
> - (home-directory "/var/run/dbus")
> + (home-directory "/run/dbus")
>   (shell (file-append shadow "/sbin/nologin")
>  
>  (define dbus-setuid-programs
> @@ -186,7 +186,39 @@ (define (dbus-activation config)
>  (let ((user (getpwnam "messagebus")))
>    ;; This directory contains the daemon's socket so it must
> be
>    ;; world-readable.
> -  (mkdir-p/perms "/var/run/dbus" user #o755))
> +  (mkdir-p/perms "/run/dbus" user #o755))
> +
> +    (catch 'system-error
> +  (lambda ()
> +    (symlink "/run/dbus" "/var/run/dbus"))
> +  (lambda args
> +    (let ((errno (system-error-errno args)))
> +  (cond
> +   ((= errno EEXIST)
> +    (let ((existing-name
> +   (false-if-exception
> +    (readlink "/var/run/dbus"
> +  (unless (equal? existing-name "/run/dbus")
> +    ;; Move the content of /var/run/dbus to
> /run/dbus, and
> +    ;; retry.
> +    (let ((dir (opendir "/var/run/dbus")))
> +  (let move-to-/run/dbus ()
> +    (let ((next (readdir dir)))
> +  (unless (or (equal? next ".")
> +  (equal? next "..")
> +  (eof-object? next))
> +    (rename-file (string-append
> "/var/run/dbus/" next)
> + (string-append "/run/dbus/"
> next)))
> +  (unless (eof-object? next)
> +    (move-to-/run/dbus
> +  (closedir dir)
> +  (rmdir "/var/run/dbus")
> +  (symlink "/run/dbus" "/var/run/dbus")
You might want to express this in terms of a function similar to copy-
recursively, or at the very least a let loop.
  (let loop ((next (readdir dir)))
(cond
  ((eof-object? next) (closedir dir))
  ((member next "." "..") (loop (readdir dir)))
  (else (rename-file …) (loop (readdir dir)
> +   (else
> +    (format (current-error-port)
> +    "Failed to symlink /run/dbus to
> /var/run/dbus: ~s~%"
> +    (strerror errno))
> +    (error "cannot create /var/run/dbus"))
>  
>  (unless (file-exists? "/etc/machine-id")
>    (format #t "creating /etc/machine-id...~%")
> @@ -210,7 +242,7 @@ (define dbus-shepherd-service
>   '(#:environment-variables
> '("DBUS_VERBOSE=1")
>     #:log-file "/var/log/dbus-
> daemon.log")
>   '())
> -  #:pid-file "/var/run/dbus/pid"))
> +  #:pid-file "/run/dbus/pid"))
>  (stop #~(make-kill-destructor)))
>  
>  (define dbus-root-service-type
> 
> base-commit: b18b2d13488f2a92331ccad2dc8cbb54ee15582f
Cheers

bug#66339: [PATCH gnome-team v3] gnu: dbus-service: make the session available under /run/dbus

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> According to
> https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101, glib
> now searches for the session bus socket in runstatedir. The dbus
> service must
> thus have its socket in /run/dbus.
> 
> For interoperability with the dbus standard, /run/dbus is also
> symlinked to
> /var/run/dbus.
> 
> * gnu/services/dbus.scm (dbus-activation): Symlink /run/dbus to
> /var/run/dbus.
> (%dbus-accounts): Run dbus in /run/dbus.
> (dbus-root-service-type): Save the pid file in /run/dbus.
> ---
> 
> Le jeudi 05 octobre 2023 à 06:41 +0200, Liliana Marie Prikler a écrit
> :
> > > I’m still concerned about doing a symlink in the activation
> > > function.
> > > What if we activate a new system from an existing one? Won’t the
> > > symlink
> > > fail? I think we should preemptively delete /var/run/dbus and
> > > make a new
> > > symlink every time. But I could be wrong, maybe this is not
> > > needed.
> > > 
> > > What do you think?
> > If we go this route, I think we should first check whether
> > /var/run/dbus is indeed a symlink to /run/dbus and move the
> > existing files if not before deleting the directory and creating
> > the symlink.  But before that, we should try to symlink, which will
> > fail with EEXIST if the file already exists, regardless of whether
> > it's a symlink – thereafter you can check the cause of this failure
> > through lstat.
> 
> I changed my mind! I now think it is OK for the system reconfigure to
> fail if a different symlink already exists.
Perhaps, but it's not okay to fail if it's a regular directory.  We
should move those!


Cheers

bug#66227: [PATCH v3] gnu: emacs-next-minimal: Apply Guix patches.

[Liliana Marie Prikler]

* gnu/packages/patches/emacs-next-native-comp-driver-options.patch: Add file.
* gnu/packages/patches/emacs-next-exec-path.patch: Add file.
* gnu/local.mk (dist_patch_DATA): Register them here.
* gnu/packages/emacs.scm (emacs-next-minimal)[origin](patches): Include the
same patches as emacs-minimal, save for the variants specific to emacs-next
introduced above.

Co-Authored-By: Nicolas Graves 
Fixes: ‘emacs-next’ is almost unusable 
---
Hi Guix,

this bug was independently discovered in two locations, so I wanted to
inform both.  A fix has already been proposed, but is not yet complete.
Here's to finally cover everything we need to have an Emacs as expected
by Guix.

Feel free to bikeshed.

Happy hacking

 gnu/local.mk   |  2 ++
 gnu/packages/emacs.scm |  7 ++-
 .../patches/emacs-next-exec-path.patch | 18 ++
 ...emacs-next-native-comp-driver-options.patch | 18 ++
 4 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/emacs-next-exec-path.patch
 create mode 100644 
gnu/packages/patches/emacs-next-native-comp-driver-options.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 65d50abc71..43a528e937 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1110,6 +1110,8 @@ dist_patch_DATA = 
\
   %D%/packages/patches/emacs-highlight-stages-add-gexp.patch   \
   %D%/packages/patches/emacs-lispy-fix-thread-last-test.patch   \
   %D%/packages/patches/emacs-native-comp-driver-options.patch   \
+  %D%/packages/patches/emacs-next-exec-path.patch   \
+  %D%/packages/patches/emacs-next-native-comp-driver-options.patch   \
   %D%/packages/patches/emacs-pasp-mode-quote-file-names.patch  \
   %D%/packages/patches/emacs-polymode-fix-lexical-variable-error.patch  \
   %D%/packages/patches/emacs-telega-path-placeholder.patch \
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 72b2c7795e..b9d9e2b891 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -498,7 +498,12 @@ (define-public emacs-next-minimal
  (commit commit)))
(file-name (git-file-name name version))
(sha256
-(base32 "00mwpq1msr3jij281w5piqmbwq968xr8dn9hqbf4r947ck754kn9")))
+(base32 "00mwpq1msr3jij281w5piqmbwq968xr8dn9hqbf4r947ck754kn9"))
+   (patches
+(search-patches "emacs-next-exec-path.patch"
+"emacs-fix-scheme-indent-function.patch"
+"emacs-next-native-comp-driver-options.patch"
+"emacs-pgtk-super-key-fix.patch")))
 
 (define* (emacs->emacs-next emacs #:optional name
 #:key (version (package-version 
emacs-next-minimal))
diff --git a/gnu/packages/patches/emacs-next-exec-path.patch 
b/gnu/packages/patches/emacs-next-exec-path.patch
new file mode 100644
index 00..6e33e25258
--- /dev/null
+++ b/gnu/packages/patches/emacs-next-exec-path.patch
@@ -0,0 +1,18 @@
+Do not capture the build-time value of $PATH in the 'emacs' executable
+since this can noticeably increase the size of the closure of Emacs
+with things like GCC being referenced.
+
+Index: emacs-next/lisp/loadup.el
+===
+--- emacs-next.orig/lisp/loadup.el
 emacs-next/lisp/loadup.el
+@@ -599,7 +599,8 @@ lost after dumping")))
+   ((equal dump-mode "dump") "emacs")
+   ((equal dump-mode "bootstrap") "emacs")
+   ((equal dump-mode "pbootstrap") 
"bootstrap-emacs.pdmp")
+-  (t (error "Unrecognized dump mode %s" dump-mode)
++  (t (error "Unrecognized dump mode %s" dump-mode
++(exec-path nil))
+ (when (and (featurep 'native-compile)
+(equal dump-mode "pdump"))
+   ;; Don't enable this before bootstrap is completed, as the
diff --git a/gnu/packages/patches/emacs-next-native-comp-driver-options.patch 
b/gnu/packages/patches/emacs-next-native-comp-driver-options.patch
new file mode 100644
index 00..e4ed5a48f1
--- /dev/null
+++ b/gnu/packages/patches/emacs-next-native-comp-driver-options.patch
@@ -0,0 +1,18 @@
+We substitute this anyway, so let's make it easier to substitute.
+
+--- a/lisp/emacs-lisp/comp.el
 b/lisp/emacs-lisp/comp.el
+@@ -203,9 +203,7 @@ and above."
+   :type '(repeat string)
+   :version "28.1")
+ 
+-(defcustom native-comp-driver-options
+-  (cond ((eq system-type 'darwin) '("-Wl,-w"))
+-((eq system-type 'cygwin) '("-Wl,-dynamicbase")))
++(defcustom native-comp-driver-options nil
+   "Options passed verbatim to the native compiler's back-end driver.
+ Note that not all options are meaningful; typically only the options
+ affecting the assembler and linker are likely to be useful.
+-- 
+2.38.0
+

base-commit: 

bug#66339: [PATCH gnome-team v2] gnu: dbus-service: make the session available under /run/dbus

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> According to
> https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101, glib
> now searches for the session bus socket in runstatedir. The dbus
> service must thus have its socket in /run/dbus.
> 
> For interoperability with the dbus standard, /run/dbus is also
> symlinked to /var/run/dbus.
> 
> * gnu/services/dbus.scm (dbus-activation): Symlink /run/dbus to
> /var/run/dbus.
> (%dbus-accounts): Run dbus in /run/dbus.
> (dbus-root-service-type): Save the pid file in /run/dbus.
> ---
> 
> Le mercredi 04 octobre 2023 à 20:30 +0200, Liliana Marie Prikler a
> écrit :
> > Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> > > * gnu/services/dbus.scm (dbus-activation): Symlink /var/run/dbus
> > > to
> > > /run/dbus.
> > > ---
> > >  gnu/services/dbus.scm | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
> > > index 5a0c634393..80968ac1a4 100644
> > > --- a/gnu/services/dbus.scm
> > > +++ b/gnu/services/dbus.scm
> > > @@ -187,6 +187,7 @@ (define (dbus-activation config)
> > >    ;; This directory contains the daemon's socket so it
> > > must
> > > be
> > >    ;; world-readable.
> > >    (mkdir-p/perms "/var/run/dbus" user #o755))
> > > +    (symlink "/var/run/dbus" "/run/dbus")
> > From [1]:
> > > As documented in the NEWS file in
> > > https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/209,
> > > it’s only valid to use /run – rather than /var/run – for D-Bus if
> > > the two paths are interoperable. i.e. /var/run should be a
> > > symlink to /run, and the D-Bus daemon should be configured to put
> > > its socket there.
> > 
> > Thus, the order of the two ought to be reversed.  Alternatively, we
> > could add '-Druntime_dir=/var/run' to glib.  WDYT?
> > 
> > [1]: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101
> 
> Thank you for finding this information. I think we should follow
> glib, and have the socket in /run/dbus, with the symlink for standard
> interoperability.
> 
> I’m still concerned about doing a symlink in the activation function.
> What if we activate a new system from an existing one? Won’t the
> symlink fail? I think we should preemptively delete /var/run/dbus and
> make a new symlink every time. But I could be wrong, maybe this is
> not needed.
> 
> What do you think?
If we go this route, I think we should first check whether
/var/run/dbus is indeed a symlink to /run/dbus and move the existing
files if not before deleting the directory and creating the symlink. 
But before that, we should try to symlink, which will fail with EEXIST
if the file already exists, regardless of whether it's a symlink –
thereafter you can check the cause of this failure through lstat.

> Best regards,
> 
> Vivien
> 
>  gnu/services/dbus.scm | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
> index 5a0c634393..53efa7adea 100644
> --- a/gnu/services/dbus.scm
> +++ b/gnu/services/dbus.scm
> @@ -163,7 +163,7 @@ (define %dbus-accounts
>   (group "messagebus")
>   (system? #t)
>   (comment "D-Bus system bus user")
> - (home-directory "/var/run/dbus")
> + (home-directory "/run/dbus")
>   (shell (file-append shadow "/sbin/nologin")
>  
>  (define dbus-setuid-programs
> @@ -186,7 +186,11 @@ (define (dbus-activation config)
>  (let ((user (getpwnam "messagebus")))
>    ;; This directory contains the daemon's socket so it must
> be
>    ;; world-readable.
> -  (mkdir-p/perms "/var/run/dbus" user #o755))
> +  (mkdir-p/perms "/run/dbus" user #o755))
> +
> +    (when (file-exists? "/var/run/dbus")
> +  (delete-file "/var/run/dbus"))
This assumes "/var/run/dbus" to be a regular file or symlink, which
it's not on reconfiguration IIUC.
> +    (symlink "/run/dbus" "/var/run/dbus")
>  
>  (unless (file-exists? "/etc/machine-id")
>    (format #t "creating /etc/machine-id...~%")
> @@ -210,7 +214,7 @@ (define dbus-shepherd-service
>   '(#:environment-variables
> '("DBUS_VERBOSE=1")
>     #:log-file "/var/log/dbus-
> daemon.log")
>   '())
> -  #:pid-file "/var/run/dbus/pid"))
> +  #:pid-file "/run/dbus/pid"))
>  (stop #~(make-kill-destructor)))
>  
>  (define dbus-root-service-type
> 
> base-commit: b18b2d13488f2a92331ccad2dc8cbb54ee15582f

Cheers

bug#66339: [WIP PATCH gnome-team] gnu: dbus-service: make the session available under /run/dbus

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> * gnu/services/dbus.scm (dbus-activation): Symlink /var/run/dbus to
> /run/dbus.
> ---
>  gnu/services/dbus.scm | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
> index 5a0c634393..80968ac1a4 100644
> --- a/gnu/services/dbus.scm
> +++ b/gnu/services/dbus.scm
> @@ -187,6 +187,7 @@ (define (dbus-activation config)
>    ;; This directory contains the daemon's socket so it must
> be
>    ;; world-readable.
>    (mkdir-p/perms "/var/run/dbus" user #o755))
> +    (symlink "/var/run/dbus" "/run/dbus")
>From [1]:
> As documented in the NEWS file in
> https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/209, it’s
> only valid to use /run – rather than /var/run – for D-Bus if the two
> paths are interoperable. i.e. /var/run should be a symlink to /run,
> and the D-Bus daemon should be configured to put its socket there.

Thus, the order of the two ought to be reversed.  Alternatively, we
could add '-Druntime_dir=/var/run' to glib.  WDYT?

[1]: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101

bug#56376: emacs-guix missing from package-activated-list

[Liliana Marie Prikler]

Am Dienstag, dem 03.10.2023 um 23:12 -0400 schrieb Maxim Cournoyer:
> Hi,
> 
> Liliana Marie Prikler  writes:
> 
> > Am Sonntag, dem 03.07.2022 um 21:33 -0400 schrieb Philip McGrath:
> > > Hi,
> > > 
> > > I've been looking into managing my Emacs packages with Guix. I
> > > found that the `emacs-guix` package doesn't seem to show up in
> > > the `package-activated-list`, even though its dependencies do,
> > > which seems like a bug.
> > This might be related to the fact that Emacs doesn't see guix as a
> > package.  I think the recipe might be missing the -pkg.el
> > autogeneration we added to emacs-build-system.
> 
> We could workaround the problem using the ensure-package-description
> of the emacs-build-system phase, but since the emacs-guix package
> uses the gnu-build-system, we'd also need to manually install the -
> pkg.el file generated by the phase.
> 
> Since we maintain the package in Savannah, it seems it'd be more
> elegant to have an emacs-guix-pkg.el file templated by the GNU build
> system and installed by it.
Indeed, maintaining a proper package description upstream is the
preferable option.

Cheers

bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016

[Liliana Marie Prikler]

Am Sonntag, dem 24.09.2023 um 10:37 +0200 schrieb Liliana Marie
Prikler:
> Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko:
> > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > Git error: object not found - no match for id
> > (4f35ff1275e05be31f5d41464ccf147e9dbfd016)
> Experiencing the same for commit
> 35fd25af9bbcce84908101a9f487ba106a8d6df7.

Am Sonntag, dem 24.09.2023 um 08:49 + schrieb Guillaume Le
Vaillant:
> I reconfigured two machines using commit
> 4f35ff1275e05be31f5d41464ccf147e9dbfd016, and it succeeded on both
> machines[.]

I now have a workaround that looks quite odd.  If you 
  $ sudo rm -rf /root/.cache/guix
guix system will rerun the indexing and thus pick up the new commits. 
I will dub this "advanced cache invalidation" since it appears as
though we are looking up commits in the wrong cache.

Cheers

bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016

[Liliana Marie Prikler]

Am Sonntag, dem 24.09.2023 um 08:49 + schrieb Guillaume Le
Vaillant:
> Liliana Marie Prikler  skribis:
> 
> > Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko:
> > > I am trying to upgrade my guix systems. I ran guix pull and now I
> > > am
> > > trying to run guix system reconfigure. It failed on two different
> > > machines with the same backtrace. Please see the full backtrace
> > > attached. The error message from it:
> > > 
> > > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > > Git error: object not found - no match for id
> > > (4f35ff1275e05be31f5d41464ccf147e9dbfd016)
> > > 
> > > 
> > > $ guix describe
> > > Generation 28   Sep 23 2023 19:30:36(current)
> > >   guix 4f35ff1
> > >     repository URL: https://git.savannah.gnu.org/git/guix.git
> > >     branch: master
> > >     commit: 4f35ff1275e05be31f5d41464ccf147e9dbfd016
> > > 
> > > Considering that I experience it on two guix machines with
> > > different
> > > system configurations, I assume that there is some bug somewhere.
> > Experiencing the same for commit
> > 35fd25af9bbcce84908101a9f487ba106a8d6df7.  I would hazard a guess
> > that it's due to them being merge commits.  Interestingly,
> > allow-downgrades does not have an effect on this message.
> > 
> > Cheers
> 
> I reconfigured two machines using commit
> 4f35ff1275e05be31f5d41464ccf147e9dbfd016, and it succeeded on both
> machines, I didn't get this "no match for id" issue.
> That's strange...
Do you have provenance tracking on your machines (the default)?

bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016

[Liliana Marie Prikler]

Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko:
> I am trying to upgrade my guix systems. I ran guix pull and now I am
> trying to run guix system reconfigure. It failed on two different
> machines with the same backtrace. Please see the full backtrace
> attached. The error message from it:
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Git error: object not found - no match for id
> (4f35ff1275e05be31f5d41464ccf147e9dbfd016)
> 
> 
> $ guix describe
> Generation 28   Sep 23 2023 19:30:36(current)
>   guix 4f35ff1
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 4f35ff1275e05be31f5d41464ccf147e9dbfd016
> 
> Considering that I experience it on two guix machines with different
> system configurations, I assume that there is some bug somewhere.
Experiencing the same for commit
35fd25af9bbcce84908101a9f487ba106a8d6df7.  I would hazard a guess that
it's due to them being merge commits.  Interestingly, allow-downgrades
does not have an effect on this message.

Cheers

bug#66015: [PATCH] gnu: python-pyxel: Update to 1.4.3-2.be75b72.

[Liliana Marie Prikler]

Am Samstag, dem 16.09.2023 um 10:46 +0200 schrieb Simon Tournier:
> Hi Liliana,
> 
> Oh, cool!  That was fast. :-)  Thank you.
> 
> On Fri, 15 Sep 2023 at 21:53, Liliana Marie Prikler
>  wrote:
> > * gnu/packages/game-development.scm (python-pyxel): Update to
> > 1.4.3-2.be75b72.
> > [version]: Use git-version even though it is a release.
> > [source]: Use commit.
> > : Adjust accordingly.
> 
> I have not tried the patch but LGTM.  If it builds fine for you, feel
> free to push… and close. :-)
I only rarely submit patches that don't at least build for myself.
Pushed and done.

> > Refering to things by commit ought to be fine since we have SWH as
> > an additional buffer.
> 
> If upstream removes Git commit
> be75b724cae9e10e56a82a5421f9dd65390f1a06
> then it is an interesting use-case for testing Guix robustness when
> fallbacking to SWH. :-)
> 
> I expect that it just works™ but I am not aware of any real world
> test about this very same use-case.  Wait and see.
Yeah, I doubt that they'll reuse it this late in the game, but you're
right that we're basically walking on dreams rn.

Cheers

bug#63687: [bug#66031] [PATCH] gnu: Patch gnome-dictionary meson configs, fixes 63687.

[Liliana Marie Prikler]

Am Samstag, dem 16.09.2023 um 14:03 +0200 schrieb raingloom:
> * gnu/packages/gnome.scm (gnome-dictionary): Apply patch.
> * gnu/packages/patches/gnome-dictionary-meson-i18n.patch: New file.
> * gnu/local.mk: Add it.
> ---
Reworded slightly and applied.

Thanks

PS: Don't worry about the semantics of the Fixes: line that I added; we
aren't parsing them yet.

bug#66015: [PATCH] gnu: python-pyxel: Update to 1.4.3-2.be75b72.

[Liliana Marie Prikler]

* gnu/packages/game-development.scm (python-pyxel): Update to 1.4.3-2.be75b72.
[version]: Use git-version even though it is a release.
[source]: Use commit.
: Adjust accordingly.
---
Hi Simon

Am Freitag, dem 15.09.2023 um 21:09 +0200 schrieb Simon Tournier:
> Upstream is managing using the worse workflow I have seen.
> 
> Here is the history of tag v1.4.3 replacement:
> 
>   v1.4.3 8bcb6f04eb184876d7807b89b34057ca0897b392  07 August 2021
>   v1.4.3 8bcb6f04eb184876d7807b89b34057ca0897b392  09 December 2021
>   v1.4.3 7d27898e218d6b4cb62779dc22b409d02860f155  27 December 2021
>   v1.4.3 be75b724cae9e10e56a82a5421f9dd65390f1a06  22 September 2022
>   v1.4.3 be75b724cae9e10e56a82a5421f9dd65390f1a06  today
>   
> And surprise surprise:
> 
> --8<---cut here---start->8---
> $ git clone https://github.com/kitao/pyxel
> 
> $ git -C pyxel show 8bcb6f04eb184876d7807b89b34057ca0897b392
> fatal: bad object 8bcb6f04eb184876d7807b89b34057ca0897b392
> 
> $ git -C pyxel show 7d27898e218d6b4cb62779dc22b409d02860f155
> fatal: bad object 7d27898e218d6b4cb62779dc22b409d02860f155
Ouch.

> I am proposing to remove the package python-pyxel.  The rationale is:
> 
>  + Broken [1] since months
>  + Update needs “some” work
>  + Two years without an update
>  + An issue about upstream source
> 
> Therefore, if someone is interested, please update it.  Else I will
> remove it.
Well, I did “some” work, but I only got to update it to the new 1.4.3.
Refering to things by commit ought to be fine since we have SWH as an
additional buffer.  As for newer versions, that requires an ugly hack
to get Rust and Python into a single build system and the last time
I tried to do something non-standard with Cargo has left deep emotional
scars.

Cheers

 gnu/packages/game-development.scm | 96 +--
 1 file changed, 52 insertions(+), 44 deletions(-)

diff --git a/gnu/packages/game-development.scm 
b/gnu/packages/game-development.scm
index c25dadb39e..215c12e2d9 100644
--- a/gnu/packages/game-development.scm
+++ b/gnu/packages/game-development.scm
@@ -1646,53 +1646,61 @@ (define-public renpy
 (license license:expat)))
 
 (define-public python-pyxel
-  (package
-(name "python-pyxel")
-(version "1.4.3")
-(source
- (origin
-   (method git-fetch)
-   (uri
-(git-reference
- (url "https://github.com/kitao/pyxel;)
- (commit (string-append "v" version
-   (file-name (git-file-name name version))
-   (sha256
-(base32
- "0bwsgb5yq5s479cnf046v379zsn5ybp5195kbfvzr9l11qbaicm9"))
-   (modules '((guix build utils)))
-   (snippet
-'(begin
-   (delete-file-recursively "pyxel/core/bin")
-(build-system python-build-system)
-(arguments
- `(#:tests? #f ; "Tests" are actually example programs that never halt.
-   #:phases
-   (modify-phases %standard-phases
- (add-after 'unpack 'patch-build-files
-   (lambda* (#:key inputs #:allow-other-keys)
- (substitute* "setup.py"
-   (("\"pyxel\\.core\\.bin\\.(.*)\"," all arch)
-(if (string=? arch "linux")
-all
-"")))
- (substitute* "pyxel/core/Makefile"
-   (("`sdl2-config")
-(string-append "`sdl2-config --prefix="
-   (assoc-ref inputs "sdl2"))
- (add-before 'build 'prebuild
-   (lambda _
- (invoke "make" "-C" "pyxel/core"))
-(inputs
- `(("gifsicle" ,gifsicle)
-   ("sdl2" ,(sdl-union (list sdl2 sdl2-image)
-(home-page "https://github.com/kitao/pyxel;)
-(synopsis "Retro game engine for Python")
-(description "Pyxel is a game engine inspired by retro gaming consoles.
+  ;; Note to updaters: Use commit and revision even if you're bumping
+  ;; to a release, as upstream is known to "reuse" tags.
+  ;; See  for more information.
+  (let ((commit "be75b724cae9e10e56a82a5421f9dd65390f1a06")
+(revision "2"))
+(package
+  (name "python-pyxel")
+  ;; This is the latest version to not require Rust…
+  (version (git-version "1.4.3" revision commit))
+  (source
+   (origin
+ (method git-fetch)
+ (uri
+  (git-reference
+   (url "https://github.com/kitao/pyxel;)
+   (commit commit)))
+ (file-name (git-file-name name version))
+ (sha256
+  (base32
+   "03ch79cmh9fxvq6c2f3zc2snzczhqi2n01f254lsigckc7d5wz08"))
+ (modules '((guix build utils)))
+ (snippet
+  #~(begin
+  (substitute* "pyxel/__init__.py"
+(("from collections import MutableSequence")
+ "from collections.abc import MutableSequence"))
+  (build-system python-build-system)
+  (arguments
+   `(#:tests? #f ; "Tests" are actually example programs that never 

bug#65846: Request to merge emacs-team branch

[Liliana Marie Prikler]

Hi Guix,

what's been promised some while ago in another thread is finally close™
to becoming reality: Emacs 29 on Guix with tree-sitter and all that
stuff.  I expect to merge the branch onto master within next week or
the week after that.  In the meantime, please use this thread to mark
bugs and patches that you would like to see applied before that.

Cheers

bug#65575: [PATCH v3 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Sonntag, dem 03.09.2023 um 21:59 +0200 schrieb Liliana Marie
Prikler:
> Am Sonntag, dem 03.09.2023 um 10:51 -0400 schrieb Maxim Cournoyer:
> > Hi Liliana,
> > 
> > Liliana Marie Prikler  writes:
> > 
> > [...]
> > 
> > > Queued locally for emacs-next and followed up
> s/emacs-next/emacs-team/
s/Queued locally/Pushed/

Cheers

bug#62784: drascula, lure, lure-de, lure-es, lure-fr, lure-it, sky: non-commercial license

[Liliana Marie Prikler]

Am Mittwoch, dem 12.04.2023 um 11:35 +0200 schrieb Liliana Marie
Prikler:
> Hi Denis,
> 
> [...] We have been aware of this for about half a year now (see the
> thread in guix-devel following [1]), but as other FSDG-abiding
> distributions still include these games (or at least did back then)
> we postponed their removal.

We now ship none of these games as well as a fully bootstrapped
scummvm-based game.  This ought to make everyone happy.

Cheers

bug#65575: [PATCH v3 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Sonntag, dem 03.09.2023 um 10:51 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> [...]
> 
> > Thanks, LGTM.  I've tested this by dropping almost all parts of
> > load-path and calling (guix-emacs-autoload-packages), it appears to
> > do what's promised.  Queued locally for emacs-next and followed up
s/emacs-next/emacs-team/

Sorry for the confusion.
> > with a patch that fixes the compilation warnings coming from the
> > docstrings.
> 
> Sounds good, thank you for testing it!
> 
> About warnings, when I byte compile guix-emacs.el, all I see is:
> 
> --8<---cut here---start->8---
> 
> Compiling file /home/maxim/src/guix/gnu/packages/aux-
> files/emacs/guix-emacs.el at Sun Sep  3 10:50:19 2023
> guix-emacs.el:83:39: Warning: reference to free variable
>     ‘treesit-extra-load-path’
> guix-emacs.el:83:39: Warning: assignment to free variable
>     ‘treesit-extra-load-path’
> --8<---cut here---end--->8---
> 
> I don't know how to fix those; they seem harmless since their use is
> enclosed in a (with-eval-after-load 'treesit ...) expression.
Yeah, I'm on Emacs 29 with tree-sitter baked in, so I see another set
of warnings (emacs-team vs master strikes again, it seems)

Cheers

bug#65306: [shepherd] ntpd throws shepherd out of the loop

[Liliana Marie Prikler]

Am Samstag, dem 02.09.2023 um 22:44 +0200 schrieb Ludovic Courtès:
> Hi,
> 
> Timotej Lazar  skribis:
> 
> > Liliana Marie Prikler  [2023-08-15
> > 07:18:02+0200]:
> > > As of recently (maybe it dates back longer, but I first
> > > experienced it two weeks ago and just now got to debugging it a
> > > little), Shepherd gets stuck at 100% CPU usage "early" on first
> > > boot.
> > 
> > I have this issue on all Guix systems without a (working) RTC. It
> > seems to be caused by a recentish update to guile-fibers:
> > 
> > https://github.com/wingo/fibers/issues/89
> 
> Yeah, that’s the one.
> 
> Liliana, Timotej: could you try the Guix patch I posted at
> <https://issues.guix.gnu.org/64966>?
Do we have a guide on how to swap out shepherd from the config.scm? 
The machine that experiences this fault isn't set up for Guix hacking.

Cheers

bug#65575: [PATCH v3 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Freitag, dem 01.09.2023 um 00:53 -0400 schrieb Maxim Cournoyer:
> This fixes a regression introduced with 79cfe30f3 ("build-system:
> emacs: Use subdirectories again.") which caused the
> 'guix-emacs-autoload-packages' to no longer be able to autoload all
> packages.
> 
> * gnu/packages/aux-files/emacs/guix-emacs.el
> (guix-emacs-autoload-packages): Reload subdirs.el files unless NO-
> RELOAD is provided.  Update doc.
> * doc/guix.texi (Application Setup): Document that
> 'guix-emacs-autoload-packages' can be invoked interactively to auto-
> reload newly installed Emacs packages.
> * gnu/packages/emacs.scm (emacs) [arguments] : Call
> guix-emacs-autoload-packages with an argument in the site-start.el
> file.
> 
> ---
> 
> Changes in v3:
> - Invert argument logic of guix-emacs-autoload-packages
> - Drop the guix-emacs-autoload-packages-called state variable
> - Adjust site-start.el file in Emacs package
> 
> Changes in v2:
> - Safely load subdirs.el files
> - Add 'reload' prefix argument as override for guix-emacs-autoload-
> packages
> 
>  doc/guix.texi  | 11 +++
>  gnu/packages/aux-files/emacs/guix-emacs.el | 15 ---
>  gnu/packages/emacs.scm |  2 +-
>  3 files changed, 20 insertions(+), 8 deletions(-)
Thanks, LGTM.  I've tested this by dropping almost all parts of load-
path and calling (guix-emacs-autoload-packages), it appears to do
what's promised.  Queued locally for emacs-next and followed up with a
patch that fixes the compilation warnings coming from the docstrings.

Cheers

bug#65575: [PATCH 3/3] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Montag, dem 28.08.2023 um 11:20 -0400 schrieb Maxim Cournoyer:
> > e.g. 
> > (defun guix-emacs-autoload-packages ( reload)
> >   "..."
> >   (interactive "P")
> >   (when reload (mapc #'load-file (guix-emacs--subdirs-files)))
> >   ...)
> > 
> > WDYT?
> 
> The reason for avoiding loading the subdirs.el files on the first
> call is just an optimization, since it would at this time duplicate
> work already done by Emacs itself when it first executes.  This
> shouldn't fail; I've now employed the same 'noerror strategy as used
> for autoloads to ensure that.
> 
> There's one edge case I've just thought though, which is if a user
> invoked emacs with the documented '--no-site-file' option disabling
> loading autoloads; this would cause guix-emacs-autoload-packages-
> called to be nil.
> 
> To balance between making things both convenient and flexible, I've
> preserved the tracking but also added the reload override you
> suggested.  Let me know what you think.
Assuming convenience equates to not needing to type C-u, we can also
achieve that without tracking:

(defun guix-emacs-autoload-packages ( noexpand)
  "Autoload Emacs packages found in EMACSLOADPATH.

'Autoload' means to load the 'autoloads' files matching 
`guix-emacs-autoloads-regexp'.  Before doing so, expand load-path by
loading subdirs.el files found in it, unless NOEXPAND is given."
  (interactive "P")
  (unless noexpand (mapc #'load-file (guix-emacs--subdirs-files)))
  ...)

In our own init code, we should simply call it as 
  (guix-emacs-autoload-packages 'noexpand)
then, since this expansion is already done earlier by Emacs.

Cheers

bug#65575: [PATCH v2 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Montag, dem 28.08.2023 um 11:16 -0400 schrieb Maxim Cournoyer:
> This fixes a regression introduced with 79cfe30f3 ("build-system:
> emacs: Use subdirectories again.") which caused the
> 'guix-emacs-autoload-packages' to no longer be able to autoload all
> packages.
> 
> * gnu/packages/aux-files/emacs/guix-emacs.el
> (guix-emacs-autoload-packages-called): New variable.
> (guix-emacs-autoload-packages): Reload subdirs.el files on all but
> the first call of this procedure, or when a prefix argument is
> provided.
What's the reason to still keep the variable?   Even if we call load-
file with 'noerror, the way in which it is set is quite weird and imho,
it would keep things simpler if we had the clear semantics of
  universal-argument → reload
  no universal-argument → no reload
or the other way round.

bug#65575: [PATCH 3/3] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Hi Maxim,

Am Montag, dem 28.08.2023 um 01:11 -0400 schrieb Maxim Cournoyer:
> This fixes a regression introduced with 79cfe30f3 ("build-system:
> emacs: Use subdirectories again.") which caused the
> 'guix-emacs-autoload-packages' to no
> longer be able to autoload all packages.
> 
> * gnu/packages/aux-files/emacs/guix-emacs.el
> (guix-emacs-autoload-packages-called): New variable.
> (guix-emacs-autoload-packages): Reload subdirs.el files an all but
> the first call of this procedure.
> * doc/guix.texi (Application Setup): Document that
> 'guix-emacs-autoload-packages' can be invoked interactively to auto-
> reload newly installed Emacs packages.
> 
> ---
Thank you for looking at this.  I agree that even if we don't want to
generally load new packages into existing Emacs processes for the
breakages they might induce, not being able to do so at all is also not
a great option.  However, I don't think that tracking is the right
solution here, see below.

>  doc/guix.texi  | 11 +++
>  gnu/packages/aux-files/emacs/guix-emacs.el | 12 
>  2 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guix.texi b/doc/guix.texi
> index f82bb99069..66da4f9cd4 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -2167,12 +2167,15 @@ Application Setup
>  Emacs through the @env{EMACSLOADPATH} environment variable, which is
>  set when installing Emacs itself.
>  
> +@cindex guix-emacs-autoload-packages, refreshing Emacs packages
>  Additionally, autoload definitions are automatically evaluated at
> the
>  initialization of Emacs, by the Guix-specific
> -@code{guix-emacs-autoload-packages} procedure.  If, for some reason,
> you
> -want to avoid auto-loading the Emacs packages installed with Guix,
> you
> -can do so by running Emacs with the @option{--no-site-file} option
> -(@pxref{Init File,,, emacs, The GNU Emacs Manual}).
> +@code{guix-emacs-autoload-packages} procedure.  This procedure can
> be
> +interactively invoked to have newly installed Emacs packages
> discovered,
> +without having to restart Emacs.  If, for some reason, you want to
> avoid
> +auto-loading the Emacs packages installed with Guix, you can do so
> by
> +running Emacs with the @option{--no-site-file} option (@pxref{Init
> +File,,, emacs, The GNU Emacs Manual}).
>  
>  @quotation Note
>  Emacs can now compile packages natively.  Under the default
> diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el
> b/gnu/packages/aux-files/emacs/guix-emacs.el
> index ed0c913163..b4a4fd1d91 100644
> --- a/gnu/packages/aux-files/emacs/guix-emacs.el
> +++ b/gnu/packages/aux-files/emacs/guix-emacs.el
> @@ -54,6 +54,9 @@ The files in the list do not have extensions (.el,
> .elc)."
>  (expand-file-name "subdirs.el" dir))
>    (guix-emacs--non-core-load-path
>  
> +(defvar guix-emacs-autoload-packages-called nil
> +  "True if `guix-emacs-autoload-packages' was already run.")
> +
>  ;;;###autoload
>  (defun guix-emacs-autoload-packages ()
>    "Autoload Emacs packages found in EMACSLOADPATH.
> @@ -61,6 +64,15 @@ The files in the list do not have extensions (.el,
> .elc)."
>  'Autoload' means to load the 'autoloads' files matching
>  `guix-emacs-autoloads-regexp'."
>    (interactive)
> +  ;; Reload the subdirs.el files such as the one generated by the
> Guix profile
> +  ;; hook, so that newly installed Emacs packages located under
> +  ;; sub-directories are put on the load-path without having to
> restart Emacs.
> +  (if guix-emacs-autoload-packages-called
> +  (progn
> +    (mapc #'load-file (guix-emacs--subdirs-files))
> +    (setq load-path (delete-dups load-path)))
> +    (setq guix-emacs-autoload-packages-called t))
> +
Rather than keeping track of whether the function was already called
(which would make debugging more tedious if you also have e.g. broken
packages from another source on your EMACSLOADPATH), I think the user
ought to signal their intent to reload the subdirs files via the
universal argument.

e.g. 
(defun guix-emacs-autoload-packages ( reload)
  "..."
  (interactive "P")
  (when reload (mapc #'load-file (guix-emacs--subdirs-files)))
  ...)

WDYT?

bug#64586: Emacs-Packages should contain native-compiled files

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 23.08.2023 um 17:37 +0200 schrieb Simon Tournier:
> Hi,
> 
> On Wed, 12 Jul 2023 at 21:36, Liliana Marie Prikler
>  wrote:
> 
> > You are correct, but unlike other language ecosystems (e.g. Python
> > or Common Lisp), we don't have a convenient "package-with-emacs" as
> > of yet.  This is basically step 3 of <
> > https://issues.guix.gnu.org/63984#0>
> > of which only step 1 has been concluded so far.  (In fact, I need
> > to merge 29.0.92 into emacs-team, but that shouldn't be as
> > difficult as the rest in there.)  If you want things to happen
> > faster, just tag your patches with emacs-team and we will review
> > them :)
> 
> Just to point that a kind of ’package-with-emacs’ had been discussed
> in #41732 [1] and my current understanding is that some corner cases
> are annoying.
The plan would have been to address those, but we were caught with our
panties down and are behind the latest Emacs release.  Oh well, guess
those nice things have to be delayed a little longer.

> Emacs packages use 3 variants for “compiling“: emacs-minimal, emacs-
> no-x and emacs; see #:emacs in arguments field.
> 
> (And I let aside emacs-no-x-toolkit. :-))
> 
> Therefore, it does not appear to me easy to have some generic
> package-with-emacs for rewriting the “compiler” of the Emacs
> packages.  Somehow, a profile containing Emacs packages has these
> packages not necessary built with the same Emacs build-system
> compiler but still work together; contrary to Python, Common Lisp,
> OCaml or others.
I don't think there'd be that many cases to consider.  You can either
adjust #:emacs (when using emacs-build-system) or you have it as
native-input (when using any other build system).  For both cases, you
can add some logic to make that emacs the one used as the argument to
the hypothetical package-with-emacs function.

> And I do not know what could be an handy way to declare Emacs package
> variants.  Any idea?
I'd have to investigate that myself.  My basic idea would have been to
copy what Common Lisp is doing and introduce consistent naming, i.e.
have emacs-minimal-org, emacs-no-x-toolkit-org, etc.  That being said,
I consider some variants to be more important than others, particularly
regular emacs-PACKAGE > emacs-any-other-variant-PACKAGE.  Which ones to
build on CI will imho be much rather a political discussion than a
technical one.

Cheers

bug#65383: [gnome-team] Nothing is reproducible anymore

[Liliana Marie Prikler]

The culprit has been found [1] and arrested [2].  It turns out that the
ungexp Bruno used at the time was "too wide", resulting in a new .drv
for shared-mime-info each time.  This wasn't caught during review,
because who has time to build things twice?

What are the lessons learned from this?
1. Closely look at when and how you use ungexp.
2. Actually build things multiple times ;)
Perhaps we can also add this to the things to check in continuous
integration, though with the fair amount of known unreproducible
packages, I'm not so sure of how great this will go.

Anyway, thanks for your attention.

Cheers

[1] http://logs.guix.gnu.org/guix/2023-08-19.log#184540
[2] 
http://git.savannah.gnu.org/cgit/guix.git/commit/?h=gnome-team=e43498b32dcbbf055d72339086213cd60c336acf

bug#65383: [gnome-team] Nothing is reproducible anymore

[Liliana Marie Prikler]

I have absolutely no idea how this came to be:

sh-5.1$ ./pre-inst-env guix build gdk-pixbuf --dry-run
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://bordeaux.guix.gnu.org“
wird aktualisiert … 100.0%
The following derivations would be built:
  /gnu/store/sn4avcl518i75r6595ns5k1w22m1h93z-gdk-pixbuf-2.42.8.drv
  /gnu/store/z359nfywzyhbfydbnv05h1cc3av2fqbc-shared-mime-info-2.2.drv
sh-5.1$ ./pre-inst-env guix build gdk-pixbuf --dry-run
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://bordeaux.guix.gnu.org“
wird aktualisiert … 100.0%
The following derivations would be built:
  /gnu/store/50pk294x08jpgzpag8z4877pa6s5bc8h-gdk-pixbuf-2.42.8.drv
  /gnu/store/5375hf13vnxab7lyrbxqg3ss7q39lxml-shared-mime-info-2.2.drv

The hash changes with each run.  What the hell is going on?

bug#65306: [shepherd] ntpd throws shepherd out of the loop

[Liliana Marie Prikler]

Hi Guix,

I have a laptop that's a little stuck in the past… more accurately
January of 2020 thanks to what I believe to be an empty CMOS battery. 
As of recently (maybe it dates back longer, but I first experienced it
two weeks ago and just now got to debugging it a little), Shepherd gets
stuck at 100% CPU usage "early" on first boot.  I can prevent this
issue by getting the system time "close enough" to the actual time
before the NTP sync, but see the first sentence.  Not having a network
connection also works, but that's somewhat unpractical.  Also, the high
CPU usage still occurs if a sync is done later.  I have yet to
encounter the bug post hibernation, but I also wish not to.  There
doesn't appear to be anything particular interesting in the logs
either.

Cheers

bug#64981: GTK4 applications broken (missing libGLESv2)

[Liliana Marie Prikler]

tags 64981 moreinfo
thanks

Am Dienstag, dem 01.08.2023 um 00:06 +0200 schrieb Csepp:
> for example:
> $ transmission-gtk
> Couldn't open libGLESv2.so.2: libGLESv2.so.2
> 
> I get the same error with Tuba.  It likely affects other
> applications.
I assume you are not using the gnome-desktop-service, are you?

Neither transmission-gtk nor GTK4 appears to actually link against
libGLES, so there's probably something arcane going on already.  Have
you tried the usual debugging tools (GDB, strace)?

Cheers 

bug#64586: Emacs-Packages should contain native-compiled files

[Liliana Marie Prikler]

Hi Mekeor,

Am Mittwoch, dem 12.07.2023 um 18:19 + schrieb Mekeor Melire:
> If I understand correctly, it is only the following Emacs-packages
> that ship with eln-files when installed with Guix, because they
> specify `#:emacs ,emacs` in the package declaration, so that native-
> compilation is available during build-time which is used if it's
> available:
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/emacs-utils.scm?h=6d0b3684628fe24555055d4a97d703a1b0b59660#n144
> 
>     emacs-auctex
>     emacs-citeproc-el
>     emacs-zig-mode
>     emacs-flycheck-grammalecte
>     emacs-sudo-edit
>     emacs-elquery
>     emacs-cov
>     emacs-pos-tip
>     emacs-posframe
>     emacs-xelb
>     emacs-exwm
>     emacs-xelb-no-x-toolkit
>     emacs-exwm-no-x-toolkit
>     emacs-exwm-x
>     emacs-jabber
>     emacs-ement
>     emacs-circe
>     emacs-esxml
>     emacs-nov-el
>     emacs-wordgen
>     emacs-picpocket
>     emacs-lsp-mode
>     emacs-jsdoc
>     emacs-tramp
>     emacs-elpher
>     emacs-telega
> 
> So, if my understanding is correct, and assuming that we want to ship
> eln-files, Emacs-packages should all be built with a package of Emacs
> that supports native-compilation.
You are correct, but unlike other language ecosystems (e.g. Python or
Common Lisp), we don't have a convenient "package-with-emacs" as of
yet.  This is basically step 3 of 
of which only step 1 has been concluded so far.  (In fact, I need to
merge 29.0.92 into emacs-team, but that shouldn't be as difficult as
the rest in there.)  If you want things to happen faster, just tag your
patches with emacs-team and we will review them :)

Cheers

bug#55449: [PATCH] gnu: recutils: Use correct bash headers.

[Liliana Marie Prikler]

Am Samstag, dem 04.06.2022 um 10:30 +0200 schrieb Liliana Marie
Prikler:
> * gnu/packages/databases.scm (recutils)[arguments]: Convert to G-
> Expressions.
> Drop gratuitous dirname.
> [native-inputs]: Drop labels.  Move bash:include...
> [inputs]: ... here.  Also add regular bash.
> ---
Hi Guix, I've pushed this now.

There's still a UX issue in that recutils doesn't put these libraries
into lib/bash, but at the very least it works as described in the
manual right now.

Cheers

bug#63920: Emacs Packages should have an output built with emacs-next(-minimal)

[Liliana Marie Prikler]

Hi Mekeor,

Am Dienstag, dem 06.06.2023 um 07:11 + schrieb Mekeor Melire:
> Hello dear Guix community,
> 
> if I understand correctly, all Emacs-packages that are packaged in 
> Guix proper, are built with Emacs version 28 (or more precisely, 
> emacs-minimal@28, emacs@28, emacs-no-x@28, emacs-no-x-toolkit@28 
> or emacs-wide-int@28 (except emacs-jsdoc which is and needs to be 
> built with emacs-next@29)). (You may grep the Guix repository for 
> ":emacs" to find out by yourself.)
Emacs packages other than emacs-minimal should be the exception rather
than the norm.  

> When using these Emacs-packages with emacs-next* (i.e. version 29 
> or 30), this can lead to misbehavior because Emacs will still 
> prefer the compiled .elc or .eln files which may depend on version 
> 28 specifics.
It should not prefer the .eln files, which get put into a unique
directory per Emacs – yes, that ought to include different versions of
the emacs package itself built with inputs that had their hashes
changed.  In any case, the version number itself (28 vs 29) is enough
to turn .eln loading away.

For .elc, the behaviour is indeed as you described, but that's rather
due to the fact that bytecode ought to be forward-compatible.  The
packages you describe below thus invoke (IIUC) undefined behaviour.

> My concrete experience is that, when using emacs-next-tree-sitter 
> and emacs-consult packages, evaluating (require 'consult-register) 
> fails because it has emacs-major-version-specific code: 
> https://github.com/minad/consult/blob/3c0f87ebd20b25f03568fb9ef8fd36b5a2a6eb84/consult-register.el#L82
>  
> (A workaround is to instead evaluate (load 
> "consult-register.el").)
> 
> I propose:
> 
> 1. Introduce a package emacs-next-minimal.
> 
> 2. For all Emacs-packages, create one output corresponding to each 
> Emacs major-version packaged in Guix proper. For example, the 
> output "emacs-next" would be built with emacs-next-minimal.
> 
> What do you think? I'd guess this should be hard to implement, 
> right?
This would unnecessarily complicate things over at emacs-build-system.
Now, emacs-next-minimal itself might be worthwhile (I don't see a
strong reason as to why, though), but since native compilation was
introduced to Guix, the recommendation was to compile packages ahead of
time rather than using the built-in JIT.  To do so, add 
  --with-input=emacs-minimal=emacs-next
or use a semantically equivalent options->transformation.  

As for a long-term solution to the problem, I do think we could make
the situation easier by providing dedicated alternatives (e.g. "emacs-
next-consult") or using parameterized packages (which is a larger TODO
than emacs-build-system, however).  As a member of the emacs-team, I do
have to sadly report that we have yet to start the most serious work
for making emacs-next the new emacs.

Cheers

bug#63787: udev-rules-service inoperable for some rules

[Liliana Marie Prikler]

Hi Felix,

Am Montag, dem 29.05.2023 um 08:25 -0700 schrieb Felix Lechner:
> Hi,
> 
> A brief thread from guix-devel about trying to use MAC-based names
> for network interfaces [1] shall be incorporated herein by reference.
> 
>   [1]
> https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00192.html
> 
> On Wed, May 17, 2023 at 6:14 PM Felix Lechner
>  wrote:
> > 
> > In a concession to Liliana's opposition, I retitled the bug to
> > sidestep the question of the MAC-based names as a default setting.
> 
> It was not enough of a concession.
Heads up, that was not a nice way of phrasing things – at least as I, a
non-native English speaker take it.  To me, "concession" implies some
backdrop of a fight between opposing forces, whereas I do see the
problem you're facing but want to find a better solution.  In other
words, we share a goal.

> In Guix, many custom rules like the following—namely those that use
> values determined by udevadm—are inoperable.
> 
> >     (udev-rules-service 'net-name-mac
> >     (udev-rule
> >  "79-net-name-mac.rules"
> >  "
> > SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\"
> > ")))
> 
> The issue is that udevadm looks in the installation folder for udev
> rules.  In standard distros, that works fine because the installation
> folder and the runtime folder are the same.  Unfortunately, that is
> not so for Guix.  The installation folder is in the store.
For the record, I'm not sure whether udevadm is the sole component at
play here.  Sure, it's a tool you may invoke at the command line, but
the big daemon thingy, that's udevd.

> The way I understand our strategy in Guix, we construct another,
> aggregate folder with links to rules in /etc/udev/rules.d. (That
> location also happens to be the installation directory for many
> traditional distros.) I proposed a local patch that causes udevadm to
> look in that folder instead. [2] It replaces one line in the source
> code.
> 
>   [2] https://issues.guix.gnu.org/63508#12
> 
> Liliana, who kindly reviewed my patch, disagreed with that solution.
> For reasons I do not fully understand, she prefers a more generalized
> solution via an environmental variable called EUDEV_RULES_DIRECTORY.
> [3] As far as I can tell, that variable is not provided by upstream.
> It was invented by a custom patch to Guix [4] and currently does not
> seem to work all the way.
> 
>   [3] https://issues.guix.gnu.org/63508#6
>   [4]
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/eudev-rules-directory.patch
Note: EUDEV_RULES_DIRECTORY was implemented by Ludo in 2014 [6, 7].  In
one year and a little bit it will celebrate ten years of being with us.
I think it is allowed to grow up.

> Liliana insists on improving the environment variable
> EUDEV_RULES_DIRECTORY, while I have several issues with that.
Just as I take issue with not using an environment variable for the
purpose it serves :)

> For starters, my substitution is simpler. 
Simpler is not always better.  One might say that overwriting files as
you install packages is simpler than worrying about setting the right
symlinks, but Guix, being a functional distribution, does the latter.

> It is also a common packaging strategy in Guix. (I furthermore cannot
> envision setting the variable to any value other than
> /etc/udev/rules.d, although maybe the flexibility comes in handy one
> day.) 
Supplying an environment where there previously was none is also a
common packaging strategy for Guix.  The fact that said environment
variable was already introduced prior to my patch should tell you as
much.

> Mainly, however, I believe that her patch goes beyond the typical
> packaging activity.
Note how said environment variable already exists prior to this patch.
It is well within typical packaging activity.

> By implementing a new feature, the patch for EUDEV_RULES_DIRECTORY
> should really be sent upstream. I do not know whether that's already
> happened, but I am not convinced upstream would accept it.
I doubt that I'd need upstream permission to modify local patches that
haven't been accepted upstream yet.  Granted, our patch could be sent
upstream, but at this point I feel like we've already diverged a little
bit from the usual scenario.

> In the latest 3.2.12 release, which does not work without further
> modifications in Guix, the upstream developers added a command-line
> option called '--root' to udevadm [5] that offers another solution to
> setting the runtime path. Unfortunately, that option does not change
> the default, which is the issue in this bug.
> 
>   [5]
> https://github.com/eudev-project/eudev/blob/2703baf55615b7554fb67c4f1c241f057f8c0a79/man/udevadm.8#L378C2-L380
You're again assuming that udevadm is the only component at play here.
I have yet to hear your reason for believing so.

> Finally, programming styles also differ. I have philosophical
> 

bug#63274: [PATCH] gnu: dia: Update to 0.97.3-4.b903dd8

[Liliana Marie Prikler]

Am Montag, dem 15.05.2023 um 16:52 +0200 schrieb Giovanni Biscuolo:
> Hello,
> 
> gentle ping (and I forgot to Cc: the gnome team)
Pushed now.

Cheers

bug#63427: gdk-pixbuf unable to recognize image formats (JPG, PNG, etc.)

[Liliana Marie Prikler]

Am Samstag, dem 13.05.2023 um 12:49 +0200 schrieb pelzflorian (Florian
Pelz):
> But then other image loaders installed by the user to support
> e.g. libexif would not be usable anymore.  We could also add libexif,
> but do we even want the attached patch?  Or should it be up to the
> user to install image loaders?
Given that $GDK_PIXBUF_MODULE_FILE is bound and not PATH-like, it would
be up to the package to declare those dependencies.  Perhaps we ought
to have a meta-package for gdk-pixbuf with all available loaders. 
Lacking that it's up to the packager to decide which formats are
important and add each one manually; though note that this practice
also allows users to override said defaults with proper modify-inputs.

Cheers

bug#63427: gdk-pixbuf unable to recognize image formats (JPG, PNG, etc.)

[Liliana Marie Prikler]

Am Donnerstag, dem 11.05.2023 um 10:05 +0200 schrieb Josselin Poiret:
> Now, if we had packaged everything properly, all the applications you
> mention should *propagate* gdk-pixbuf and not just list it as an
> input
No.  Propagated inputs are *never* the result of proper packaging. 
More often than not, they create more issues than they solve by
reducing Guix to the capabilities of a dumb package manager.  While
yes, they have been accepted as a solution to some issues (e.g. pkg-
config not finding inputs), this by no means translates to "oh,
something's not found, let's propagate an input".  However, even for
those cases where they have become accepted practice, we ought to look
for better solutions, as proliferating propagations do end up biting us
in the form of conflicts.

The only instance in which propagated inputs behave as intended is with
meta packages; there they are even slightly less clunky than their
alternative (union builds).

As for the actual problem at hand, the solution has already been
pointed out by Florian: wrapping commands to bind
GDK_PIXBUF_MODULE_FILE.  Sadly, Florian didn't point these unwanted
side effects of propagation, as contributors are often unaware of them.

Cheers

bug#60657: Rethinking how service extensions work

[Liliana Marie Prikler]

Am Dienstag, dem 09.05.2023 um 20:12 +0100 schrieb Bruno Victal:
> Hi Ludo’,
> 
> On 2023-02-25 17:46, Ludovic Courtès wrote:
> > Bruno Victal  skribis:
> > > In [1], the issue arises from using activation-service-type to
> > > create files/directories for services
> > > when these should be either (1) shepherd one-shot services or
> > > moved into the 'start' procedure of the service.
> > > 'activation-service-type' should only be used for doing things
> > > "listed on its label", that is, performing
> > > actions at boot-time or after a system reconfigure.
> > 
> > Right.
> > 
> > As we once discussed on IRC, the conclusion to me is that some of
> > the
> > code currently implemented as activation snippets should rather be
> > implemented either as part of the ‘start’ method of the
> > corresponding
> > Shepherd service, or as a one-shot Shepherd service that the main
> > service would depend on.
> 
> I think moving them into the ‘start’ method is the best course of
> action.
> I'm considering the following changes:
> * Adding (gnu build activation) to %default-imported-modules +
> %default-modules in (gnu services shepherd).
>   I expect that mkdir-p/perms is going to be used frequently enough,
> using the number of activation-service
>   extensions in use as a rough estimate.
> * Refactor the activation extensions into the ‘start’ method, where
> it makes sense to do so.
> 
> 
> There's one issue I'm somewhat concerned about, consider the
> following snippet:
> 
> --8<---cut here---start->8---
> 
> (define log-directory "/var/log")
> (define username "notroot")
> 
> (start
>  #~(lambda _
>     (mkdir-p/perms #$log-directory (getpw #$username) #o750)
>     ...))
> 
> --8<---cut here---end--->8---
> 
> This is somewhat pitfall prone since you most likely don't want to
> chown /var/log to a non-root user.
> I'm unsure what's the best course to take here, would a simple file-
> exist? check before mkdir-p/perms be sufficient?
I think this question highlights perfectly why one-shot services (or
perhaps an as-of yet unknown type of services) are the way to go: With
clearly named services for the creation of directories, you don't need
to worry about creating some file with the wrong permissions as the
owner is already predetermined.  You also don't need mkdir-p; you
simply depend on the mkdir-#$(dirname my-directory) service.


Cheers

bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Am Sonntag, dem 07.05.2023 um 21:05 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> > Hi Maxim,
> > 
> > Am Sonntag, dem 07.05.2023 um 14:12 -0400 schrieb Maxim Cournoyer:
> > > My focus on this series was making sure the configuration is
> > > easy(er)
> > > to reason with and that it works out of the box for the most
> > > part.
> > Obsoleting the group field does imho not significantly ease its
> > use.
> > It rather makes its non-ootb use harder, because you now have to
> > edit
> > two operating-system fields, without changing anything for the ootb
> > use.
> 
> If you haven't tried that already, I'd like to give you the following
> challenge: with the current MPD service, are you able to configure it
> so that it works as your user, touching the minimum amount of
> configuration switches (as you'd do if you were a new MPD service
> user getting started?).
I mean, I do have an unfair advantage at this challenge, but:

  (define* (by proc value #:optional (= equal?))
(lambda (record)
  (= (proc record) value)))

  (service mpd-service-type
   (mpd-configuration
(user (find (by user-account-name my-user-name) users))
(group (find (by user-group-name "users") %base-groups

If you want, you can also make that a match-lambda.

> With this series I opinionated on the side that less is better,
> coming from the realization that configuring a working MPD was
> already quite the challenge (less after this series, if it succeeds
> at its goal).  In my opinion, the main two use cases for configuring
> the services user/group probably are:
> 
> 1. you want to run it as an existing user
> 2. you want it to run as its own user
> 
> The defaults cover 2, while for 1 you don't have a need to configure
> a group for it, since an existing user will also already have an
> existing group (and the  captures such group).
Seeing how you write about "the main two use cases", I think either
there is a third use case not mentioned or you are underselling the
extent of the second use case.

> > > It puts the issue aside; if you can't configure a mismatched
> > > group, you can't shoot yourself in the foot.
> > No, it doesn't: Since it pulls in the groups field into "stuff you
> > need to worry about when editing your MPD service", it actually
> > exacerbates the issue.  Yes, the API is awkward, but it does help
> > making mpd-service-type self-contained.
> 
> The thing is that the 'group' field of mpd-service-type has a
> default, which is easy to forget (because it's duplicated from a
>  object and you may reasonably expect the service to
> default to the specified user-account's group).  But that's not easy
> to achieve.  I tried.
I mean, if you want to serialize the user account's group, by all means
go ahead, but the group field should stay semantically intact for the
case that user:group are provided as strings.  Well, as it turns out,
you don't need to serialize the user or the group to the config file,
so that's not even an issue holding us back.

> > 
Cheers

bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Hi Maxim,

Am Sonntag, dem 07.05.2023 um 14:12 -0400 schrieb Maxim Cournoyer:
> My focus on this series was making sure the configuration is easy(er)
> to reason with and that it works out of the box for the most part.
Obsoleting the group field does imho not significantly ease its use. 
It rather makes its non-ootb use harder, because you now have to edit
two operating-system fields, without changing anything for the ootb
use.

> > > > 
> It puts the issue aside; if you can't configure a mismatched group,
> you can't shoot yourself in the foot.
No, it doesn't: Since it pulls in the groups field into "stuff you need
to worry about when editing your MPD service", it actually exacerbates
the issue.  Yes, the API is awkward, but it does help making mpd-
service-type self-contained.

> > 
> I think it's a serious issue because the permissions configured in
> the start slot may be wrong, and the service could fail to run
> because of it.
What is "it" here: the fact that you can make a group with (system? #f)
or the error in accounts-service-type that has been demoted to a
warning?

Cheers

bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Am Samstag, dem 06.05.2023 um 22:55 -0400 schrieb Maxim Cournoyer:
> Hi!
> 
> Liliana Marie Prikler  writes:
> 
> > Am Freitag, dem 05.05.2023 um 14:29 -0400 schrieb Maxim Cournoyer:
> > Didn't we agree in v2 that we want to address this on the account-
> > service level?  Unless the rest of this series somehow depends on
> > this patch, I'd rather delay it until we have a proper solution.
> 
> I think we agreed the idea to have  support  group> objects for its group field was a good idea that should be
> implemented, but I declined doing this new work as part of this
> series :-).
Indeed, that's how I understood it.  However, I also thought that
addressing this issue in a later series means we can keep the current
behaviour until that is done.

> > > Synchronizing both is not practical, as it can easily lead to
> > > slightly different  objects conflicting, again
> > > causing problems.
> > It might not be practical to do so inside the service, but note how
> > this has already become an effort in defensive programming.  There
> > are easier ways to not make this a problem on the configuration
> > level, namely by specifying the same group for both user and group
> > fields.  As far as I see this is even the default state of being if
> > the user is supplied as a string.
> 
> I really don't like the group information being duplicated in both
> the user and a distinct field; it's an awkward API that raises more
> questions than it provides answers, in my opinion (non-intuitive).
And I agree that it's awkward, but I don't agree that this patch solves
the underlying issue.

> One of the reasons I came think this way is because a 
> can differ by being a system group or not, which would make it easy
> to introduce unexpected, subtle variants.
Is that a serious issue, though?  Yes, two configuration files, one
with (system? #t) and one without will produce different results in
that GIDs are allocated differently, but the same applies to the user
as well.  The only real issue I can think about here goes back to the
handling of duplicate accounts and groups; and again, we both agree
that those ought to be hard errors rather than warnings.

Cheers

bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Am Freitag, dem 05.05.2023 um 14:29 -0400 schrieb Maxim Cournoyer:
> Prior to this change, there was a discrepancy where a user could have
> disagreeing groups between the group and user fields (the user field
> being a  record, which includes its primary group as a
> string).  This could have caused problems because the USER's group
> was being used to set the file permissions, while the GROUP name was
> serialized to MPD's configuration, and MPD would use it to set the
> group of its running process.  
Didn't we agree in v2 that we want to address this on the account-
service level?  Unless the rest of this series somehow depends on this
patch, I'd rather delay it until we have a proper solution.

> Synchronizing both is not practical, as it can easily lead to
> slightly different  objects conflicting, again causing
> problems.
It might not be practical to do so inside the service, but note how
this has already become an effort in defensive programming.  There are
easier ways to not make this a problem on the configuration level,
namely by specifying the same group for both user and group fields.  As
far as I see this is even the default state of being if the user is
supplied as a string.


Cheers

bug#63082: [PATCH v3 04/16] services: mpd: Rename %set-user-group to set-user-group.

[Liliana Marie Prikler]

Am Freitag, dem 05.05.2023 um 14:28 -0400 schrieb Maxim Cournoyer:
> The convention to use % as a prefix is for "special" variables rather
> than procedures.
Variables are a superset of procedures in Scheme :)
That being said, I'm d'accord with the actual change.

> * gnu/services/audio.scm ((%set-user-group): Rename to...
One parenthesis too much.
> (set-user-group): ... this.
Cheers

bug#63270: d-feet: Fails to build (Function does not take positional arguments)

[Liliana Marie Prikler]

Am Donnerstag, dem 04.05.2023 um 17:13 +0200 schrieb Ivan Vilata i
Balaguer:
> Hi!  It looks like the Meson build of `d-feet` fails to complete in
> the version of Guix shown below:
> 
> ```
> $ guix describe
> Generation 56   May 02 2023 11:25:26    (current)
>   guix 3f8c489
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 3f8c4899a9a67bb509a603bd21dcfcfab88c0e8e
> ```
> 
> This is the final part of the build log:
> 
> ```
> starting phase `configure'
> The Meson build system
> Version: 1.1.0
> Source dir: /tmp/guix-build-d-feet-0.3.16.drv-0/d-feet-0.3.16
> Build dir: /tmp/guix-build-d-feet-0.3.16.drv-0/build
> Build type: native build
> Project name: d-feet
> Project version: 0.3.16
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Program python3 found: YES
> (/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-
> 3.10.7/bin/python3)
> Found pkg-config: /gnu/store/jz5dwdxq4di29cd0rjjzkw356dhkzjil-pkg-
> config-0.29.2/bin/pkg-config (0.29.2)
> Run-time dependency gtk+-3.0 found: YES 3.24.37
> Run-time dependency gobject-introspection-1.0 found: YES 1.72.0
> Run-time dependency gio-2.0 found: YES 2.72.3
> Program msgfmt found: YES
> (/gnu/store/5d0fgnmh63yx98s1kfp57rc2x05xqk1d-gettext-minimal-
> 0.21/bin/msgfmt)
> Program msginit found: YES
> (/gnu/store/5d0fgnmh63yx98s1kfp57rc2x05xqk1d-gettext-minimal-
> 0.21/bin/msginit)
> Program msgmerge found: YES
> (/gnu/store/5d0fgnmh63yx98s1kfp57rc2x05xqk1d-gettext-minimal-
> 0.21/bin/msgmerge)
> Program xgettext found: YES
> (/gnu/store/5d0fgnmh63yx98s1kfp57rc2x05xqk1d-gettext-minimal-
> 0.21/bin/xgettext)
> Configuring d-feet using configuration
> Configuring tests.py using configuration
> Program pep8 found: YES (/gnu/store/09j78kk5zw662qw8y949ndswqp23193b-
> python-pep8-1.7.0/bin/pep8)
> Configuring org.gnome.dfeet.desktop.in using configuration
> 
> ../d-feet-0.3.16/data/meson.build:15:5: ERROR: Function does not take
> positional arguments.
> 
> A full log can be found at /tmp/guix-build-d-feet-0.3.16.drv-
> 0/build/meson-logs/meson-log.txt
> error: in phase 'configure': uncaught exception:
> %exception #< program: "meson" arguments: ("setup" "--
> prefix=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16" "--
> buildtype=debugoptimized" "-Dc_link_args=-Wl,-
> rpath=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16/lib"
> "-Dcpp_link_args=-Wl,-
> rpath=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16/lib"
> "/tmp/guix-build-d-feet-0.3.16.drv-0/d-feet-0.3.16") exit-status: 1
> term-signal: #f stop-signal: #f> 
> phase `configure' failed after 0.7 seconds
> command "meson" "setup" "--
> prefix=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16" "--
> buildtype=debugoptimized" "-Dc_link_args=-Wl,-
> rpath=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16/lib"
> "-Dcpp_link_args=-Wl,-
> rpath=/gnu/store/y414lsncri13kn6wz1hzhgzy6lpbivlf-d-feet-0.3.16/lib"
> "/tmp/guix-build-d-feet-0.3.16.drv-0/d-feet-0.3.16" failed with
> status 1
> ```
> 
> Unfortunately I know nothing about Meson, so I can't suggest a way to
> go…
> 
> Thanks and have a nice day!
Looking at d-feet itself, it appears as though it has been all but
deprecated in the favour of d-spy.  Perhaps guix should simply declare
it a deprecated package instead of attempting to patch it – a patch has
already been filed upstream previously, but is not yet merged any
branch as far as I'm aware.

Cheers

bug#63082: [PATCH 04/17] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Hi Maxim,

Am Sonntag, dem 30.04.2023 um 21:07 -0400 schrieb Maxim Cournoyer:
> > In the current mpd-configuration, to use my own user, I must also
> > provide the matching group as a  record, even if
> > e.g. 'users' is something I've never created myself and don't
> > really
> > have a clue as to how it was defined without looking at the source,
> > yet it's important that it matches the original definition
> > otherwise
> > I'd have two same-named groups differing only subtly, which would
> > introduce issues probably harder to diagnose than "sorry, no such
> > group!"
The "find by name" pattern applies here as well. We could extend the
semantics of group field so that if a string is passed, %base-groups is
searched for a matching name first instead of constructing a new group.
This would allow you to more easily specify (group "users") for
example.

> > One way that seems like it'd solve it is to make the group field of
> > a
> >  accept a ; then the user object would be
> > self-contained as far as extending user-accounts goes; the API
> > becomes a bit more obtuse though, especially when you simply want
> > to
> > specify a group known to exist ('users', 'audio', 'netdev', etc.).
Not really. If the  allowed for a  group, we
could drop the group field in the MPD specification. The semantics for
string groups would remain unchanged, whereas  groups would
get added to the accounts service as though they had been specified via
the groups mechanic. We'd only have to twiddle with account service
there and the change would probably benefit every service that requires
an account:group pair.

Cheers

bug#63082: [PATCH 04/17] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Am Samstag, dem 29.04.2023 um 13:16 -0400 schrieb Maxim Cournoyer:
> This means we do not have to expose user-accounts at the
> , which is not the right place for that anyway;
> it's already exposed via the users/groups fields of the  system> record.
> 
> That's much easier to reason with, for both humans and the code, in
> my opinion.
We have the tools to make this meaningful with user-accounts already –
we've had them for some while in fact.

(operating-system
  ...
  (users (cons* alice bob mpd %base-user-accounts))
  (services (cons* (mpd-service (user (find mpd-user? users)))
   %base-services))
  ...)

is a perfectly fine configuration given concrete values for alice, bob,
and mpd with mpd-user? matching the MPD user account by name.  The
point in providing user-accounts in the MPD service is so that the
right thing is done w.r.t. account creation regardless of whether the
user exists in users or not.  In the former case, it is checked that
definitions match (using pointer identity), in the latter the user is
automatically added.  "I will assume that a user by this name exists
even if it does not" is a recipe for shooting oneself in the knee.

Cheers

bug#63082: [PATCH 04/17] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Am Samstag, dem 29.04.2023 um 08:26 +0200 schrieb Liliana Marie
Prikler:
> IIRC using supplementary groups does not suffice, because the
> service won't work then; do I actually recall that correctly?  
Reading the rest of the series it turns out that worry was unwarranted.
Supplementary groups do work as they should.

bug#63082: [PATCH 11/17] services: mpd: Warn when the MPD user is not in the "audio" group.

[Liliana Marie Prikler]

Am Freitag, dem 28.04.2023 um 10:27 -0400 schrieb Maxim Cournoyer:
> Relates to .
> 
> * gnu/services/audio.scm (%mpd-user) [group]: Add comment.
> (mpd-user-sanitizer): Warn if the MPD user is not in the audio group.
> ---
>  gnu/services/audio.scm | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/services/audio.scm b/gnu/services/audio.scm
> index 550ccc542c..9579432ea3 100644
> --- a/gnu/services/audio.scm
> +++ b/gnu/services/audio.scm
> @@ -30,6 +30,7 @@ (define-module (gnu services audio)
>    #:use-module (gnu services configuration)
>    #:use-module (gnu services shepherd)
>    #:use-module (gnu services admin)
> +  #:use-module (gnu system accounts)
>    #:use-module (gnu system shadow)
>    #:use-module (gnu packages admin)
>    #:use-module (gnu packages mpd)
> @@ -172,6 +173,8 @@ (define-maybe boolean (prefix mpd-))
>  (define %mpd-user
>    (user-account
>     (name "mpd")
> +   ;; Being in the audio group ensures that PulseAudio can access
> sound
> +   ;; devices.
>     (group "audio")
>     (system? #t)
>     (comment "Music Player Daemon (MPD) user")
> @@ -208,10 +211,17 @@ (define (mpd-serialize-port field-name value)
>  
>  (define-maybe port (prefix mpd-))
>  
> -;;; Procedures for unsupported value types, to be removed.
> -
> +;;; Sanitizer procedures.
>  (define (mpd-user-sanitizer value)
> -  (cond ((user-account? value) value)
> +  (cond ((user-account? value)
> + (match-record value 
> +   (group supplementary-groups)
> +   (unless (or (string=? "audio" group)
> +   (member "audio" supplementary-groups))
> + ;; Being in the "audio" group is necessary for access
> to the
> + ;; sound devices.
> + (warning (G_ "mpd user not member of \"audio\"
> group~%"
> + value)
>  ((string? value)
>   (warning (G_ "string value for 'user' is deprecated, use \
>  user-account instead~%"))
I think this check is "only" required when using alsa/pulseaudio for
outputs and should be a hard error then.  When configured to write to
httpd or null outputs, other checks are needed.

Cheers

bug#63082: [PATCH 04/17] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Am Freitag, dem 28.04.2023 um 10:26 -0400 schrieb Maxim Cournoyer:
> Prior to this change, there was a discrepancy where a user could have
> disagreeing groups between the group and user fields (the user field
> being a  record, which includes its primary group as a
> string).  This could have caused problems because the USER's group
> was being used to set the file permissions, while the GROUP name was
> serialized to MPD's configuration, and MPD would use it to set the
> group of its running process.  Synchronizing both is not practical,
> as it can easily lead to slightly different  objects
> conflicting, again causing problems.
> 
> The compromise is to obsolete the 'group' field.  A group can still
> be configured via the 'user' field, which accepts a 
> object, with the limitation that the group should already exist.
Most services generate both an account and a group, whereas MPD would
be the odd one out here.  Defaulting to mpd:audio also has some minor
consequences when group permissions entail semantics, as this would
allow everyone in the audio group group access to mpd's stuff, which
seems needlessly permissive.  For this reason I think it makes sense to
allow users to specify a group, though it need not necessarily be via
the group field – for instance, we could make the user-accounts visible
to allow both specification of (list user group) and user alone,
deprecating the user and group fields in the process.  (Though we could
still provide read accessors to those.)

This still leaves us with the question of how to make audio work out of
the box.  IIRC using supplementary groups does not suffice, because the
service won't work then; do I actually recall that correctly?  


Cheers

bug#63050: "guix pull" requires graphical libraries

[Liliana Marie Prikler]

Am Mittwoch, dem 26.04.2023 um 20:39 +0200 schrieb Josselin Poiret:
> Hi Andreas,
> 
> Andreas Enge  writes:
> 
> > Hello,
> > 
> > Am Wed, Apr 26, 2023 at 06:59:44PM +0200 schrieb Liliana Marie
> > Prikler:
> > > Having built glib from scratch more often than is fun, I am quite
> > > certain that the package pulling in our graphics stack is texinfo
> > > with
> > > its reference to texlive.
> > 
> > where do you see this?
> > $ guix gc --references `guix build texinfo`
> 
> This would check the store path's references, but not necessarily all
> of its inputs!  I would hope that no package with docs ever keeps
> references to texlive.
It does turn out there's no `guix graph texinfo --path-to texlive'
either, though, so I was actually mistaken.

Sorry for the noise

bug#63082: mpd defaul configuration does not work ('No database' error)

[Liliana Marie Prikler]

Hi Maxim,

Am Dienstag, dem 25.04.2023 um 23:11 -0400 schrieb Maxim Cournoyer:
> The cache-directory configuration doesn't seem to be useful so far;
> nothing was being populated under /var/cache/mpd.
> 
> in /var/log/messages, pulseaudio throws a couple errors:
> 
> --8<---cut here---start->8---
> Apr 25 23:06:52 localhost pulseaudio[10356]: [pulseaudio] module-
> jackdbus-detect.c: Unable to contact D-Bus session bus:
> org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-
> daemon without a $DISPLAY for X11
> Apr 25 23:06:52 localhost pulseaudio[10356]: [pulseaudio] module.c:
> Failed to load module "module-jackdbus-detect" (argument:
> "channels=2"): initialization failed.
> Apr 25 23:06:52 localhost pulseaudio[10356]: [pulseaudio] cli-
> command.c: stat('/gnu/store/5ahapvp7rnd2ymakyjv1pwwdav7w9wdc-
> pulseaudio-16.1/etc/pulse/default.pa.d'): No such file or directory
> Apr 25 23:06:52 localhost pulseaudio[10356]: [pulseaudio] main.c: No
> card found by this name or index.
> Apr 25 23:06:52 localhost pulseaudio[10356]: [pulseaudio] main.c:
> Source alsa_input.pci-_01_01.0.analog-mono does not exist.
> Apr 25 23:06:52 localhost pulseaudio[10356]: [pulseaudio] main.c:
> Sink alsa_output.pci-_01_01.0.analog-surround-40 does not exist.
> Apr 25 23:06:52 localhost pulseaudio[10356]: [pulseaudio] server-
> lookup.c: Unable to contact D-Bus:
> org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-
> daemon without a $DISPLAY for X11
> Apr 25 23:06:52 localhost pulseaudio[10356]: [pulseaudio] main.c:
> Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported:
> Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
> --8<---cut here---end--->8---
Configuring MPD in a vacuum meaningfully is a little difficult. 
Usually, you don't want it to spawn its own pulse, but rather to
communicate with an already existing server that has to allow network
access.  Rather than supposing this, we could make the default a null
sink or similar.

Cheers

bug#63050: "guix pull" requires graphical libraries

[Liliana Marie Prikler]

Hi folks, just dropping by real quick

Am Mittwoch, dem 26.04.2023 um 10:45 +0200 schrieb Josselin Poiret:
> No, guix graph uses its own graphviz implementation!  It is used to
> generated png files from .dot files while building the documentation.
> 
> I don't really know if we can skip graphical libraries for this
> reason.
Having built glib from scratch more often than is fun, I am quite
certain that the package pulling in our graphics stack is texinfo with
its reference to texlive.

Cheers

bug#62908: evolution-data-server@3.44.4 or above don't connect with Nextcloud online account (GNOME desktop)

[Liliana Marie Prikler]

Am Montag, dem 17.04.2023 um 15:33 + schrieb
christophe.pist...@posteo.net:
> evolution-data-server@3.44.4 or above don't connect with Nextcloud 
> online account
> 
> ## Steps to reproduce
> 
> The following steps assume you are using Guix System x86_64 with
> GNOME desktop/X11
> 
> 1. fresh install with guix-system-install-1.4.0.x86_64-linux.iso (or
> the 
> devel iso: sp7lgxn1q3d37536dwq2r5r9yd18jw50-image.iso)
> 
> 2. guix package -i evolution-data-server
>     (i.e: evolution-data-server@3.45.3 with 
> guix-system-install-1.4.0)
>     (i.e: evolution-data-server@3.46.0 with 
> sp7lgxn1q3d37536dwq2r5r9yd18jw50-image.iso)
> 
> 3. optional: guix package -i evolution
> 
> 4. go to Settings, connect to a Nexcloud account
> 
> ## Expected result
> 
> + Calendar (or Evolution) connect to the Nexcloud account and can
> manage 
> calendars and address books (display existing calendars/address
> books, 
> add new item or delete item).
> + Files connect to the Nexcloud account and display online documents.
> 
> ## Unexpected result
> 
> + Calendar (or Evolution) can't connect to the Nexcloud account and 
> display nor manage nothing (or only display the calendars list) with 
> this error:
> 
>    Address book:
>    Impossible de se connecter au carnet d’adresses « CardDAV : Sans
> nom »
>    Échec avec l’erreur HTTP 405 : Method Not Allowed
> 
>    Calendars:
>    Impossible de se connecter à l’agenda « Sur le Web : Next_Ponctuel
> »
>    Bad Request
> 
>    Impossible de se connecter à « usern...@nl.tab.digital »
>    Erreur de résolution de « usern...@nl.tab.digital » : Nom ou
> service 
> inconnu
> 
> + (side note: Files connect perfectly to the Nexcloud account and 
> display online documents)
> 
> see:
> https://lists.gnu.org/archive/html/help-guix/2023-03/msg00255.html
The currently packaged evolution also appears to suffer from other
issues (see e.g. https://issues.guix.gnu.org/62942)  You may want to
try that patch or wait for it to be upstreamed.

> ## Workaround
> 
> 1. fresh install with guix-system-install-1.3.0.x86_64-linux.iso
> 
> 2. guix package -i evolution-data-server (i.e: 
> evolution-data-server@3.34.2)
> 
> 3. optional: guix package -i evolution
> 
> 4. go to Settings connect to a Nexcloud account
> 
> Result:
> -> Calendar (and Evolution) connect to the Nexcloud account and can 
> manage calendars and address books (display existing
> calendars/address 
> books, add new item or delete item).
> -> Files connect to the Nexcloud account and display online
> documents.
As a matter of principle, don't install Guix from old ISOs.  Instead,
use `guix time-machine' or inferiors with Scheme.

> ## Additional information
> 
> + Upgrade from evolution-data-server@3.34.2 to 
> evolution-data-server@3.46.0 partially fails:
> 1. fresh install with guix-system-install-1.3.0.x86_64-linux.iso
> 2. guix package -i evolution-data-server (i.e: 
> evolution-data-server@3.34.2)
> 3. guix pull & sudo guix system reconfigure /etc/config.scm & reboot
> & 
> guix package -u
> Result:
> ->   Calendar (and Evolution) connect to the Nexcloud account and can
> manage calendars and address books (display existing
> calendars/address 
> books, add new item or delete item).
>   But: Evolution displays the same error messages as above (see:
> ## 
> Unexpected result)
>   Files connect to the Nexcloud account and display online
> documents.
> 
> + Downgrade from evolution-data-server@3.45.3 to 
> evolution-data-server@3.44.4 fails:
> 1. fresh install with >= guix-system-install-1.4.0.x86_64-linux.iso
> 2. guix package -i evolution-data-server@3.44.4
> Result:
> -> Same error: Calendar (or Evolution) can't connect to the Nexcloud 
> account and display nor manage nothing.
> 
> + Downgrade from evolution-data-server@3.45.3 to 
> evolution-data-server@3.34.2 fails:
> 1. fresh install with guix-system-install-1.4.0.x86_64-linux.iso
> 2. guix package -i evolution-data-server@3.34.2
> Result:
> -> no package found
None of this is useful.  For accurate version information, use `guix
describe'.

> + possibly related to: https://issues.guix.gnu.org/35267#3
IIUC the fix to that one is to install evolution-data-server in the
operating-system packages rather than on the user level.  Since
evolution is tied to its data-server, you'd need to have both in the
operating-system (my personal fix is to extend the gnome package so as
to include them both, but that's besides the point).  Since evolution
launches for you, this bug doesn't seem apply, however.

Cheers

bug#58813: [PATCH v2 3/5] Makefile.am: Auto-configure Git on 'make'.

[Liliana Marie Prikler]

Am Sonntag, dem 23.04.2023 um 22:29 -0400 schrieb Maxim Cournoyer:
> This means we do not need to worry anymore about manually syncing the
> pre-push git hook or the Guix-provided git configuration.
IIUC we still need to invoke 'make .git/whatever' manually, and I'd
actually like it to be that way, just with a nice phony target like
'make git-config' or 'make .git'.  WDYT?

> * etc/git/gitconfig: Augment configuration template with useful
> options to allow for auto-configuration.
> * Makefile.am (.git/hooks/pre-push, .git/config): New targets.
> (nodist_noinst_DATA): New primary variable holding the above targets.
> ---
>  Makefile.am   | 10 ++
>  etc/git/gitconfig | 15 +++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 23b939b674..7daa7d66f7 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -14,6 +14,7 @@
>  # Copyright © 2018 Oleg Pykhalov 
>  # Copyright © 2018 Alex Vong 
>  # Copyright © 2019 Efraim Flashner 
> +# Copyright © 2020, 2021, 2023 Maxim Cournoyer
> 
>  # Copyright © 2021 Chris Marusich 
>  # Copyright © 2021 Andrew Tropin 
>  #
> @@ -1109,6 +1110,15 @@ cuirass-jobs: $(GOBJECTS)
>  .PHONY: clean-go make-go as-derivation authenticate
>  .PHONY: update-guix-package update-NEWS cuirass-jobs release
>  
> +# Git auto-configuration.
> +.git/hooks/pre-push: etc/git/pre-push
> +   cp etc/git/pre-push .git/hooks/pre-push
> +
> +.git/config: etc/git/gitconfig
> +   git config include.path ../etc/git/gitconfig
> +
> +nodist_noinst_DATA = .git/hooks/pre-push .git/config
> +
>  # Downloading up-to-date PO files.
>  
>  WEBLATE_REPO = https://framagit.org/tyreunom/guix-translations
> diff --git a/etc/git/gitconfig b/etc/git/gitconfig
> index c9ebdc8fa8..0b6984a05f 100644
> --- a/etc/git/gitconfig
> +++ b/etc/git/gitconfig
> @@ -1,5 +1,20 @@
> +[commit]
> +    gpgsign = true
> +
>  [diff "scheme"]
> xfuncname = "^(\\(define.*)$"
>  
>  [diff "texinfo"]
> xfuncname = "^@node[[:space:]]+([^,]+).*$"
> +
> +[format]
> +    useAutoBase = true
> +    thread = shallow
> +
> +[pull]
> +    rebase = true
> +
> +[sendemail]
> +    to = guix-patc...@gnu.org
> +    headerCmd = etc/teams.scm cc-members-header-cmd
> +    thread = no

Otherwise LGTM.

Cheers

bug#58813: [PATCH 3/5] teams: Add a configure-git action.

[Liliana Marie Prikler]

Am Sonntag, dem 23.04.2023 um 12:04 -0400 schrieb Maxim Cournoyer:
> * etc/git/gitconfig: Augment configuration template with useful
> options to
> allow for auto-configuration.
> * etc/teams.scm.in (configure-git): New procedure.
> (main): Register it and add documentation.
I think configure-git is somewhat out of scope inside teams.scm.  We do
already tell people to set up their push hooks, so we probably ought to
solve this via documentation (or a separate dedicated script) as well.

Otherwise LGTM.

Cheers

bug#58813: [PATCH 1/5] gnu: git: Apply patch adding the --header-cmd feature.

[Liliana Marie Prikler]

Am Sonntag, dem 23.04.2023 um 12:04 -0400 schrieb Maxim Cournoyer:
> In preparation to fix .
> 
> * gnu/packages/patches/git-header-cmd.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Register it.
> * gnu/packages/version-control.scm (git) [source]: Apply patch.
> ---
Don't forget to also send this patch to git proper.  I'm sure that
other distros will have a use for it.

Cheers

bug#62784: drascula, lure, lure-de, lure-es, lure-fr, lure-it, sky: non-commercial license

[Liliana Marie Prikler]

Hi Denis,

Am Mittwoch, dem 12.04.2023 um 01:52 +0200 schrieb Denis 'GNUtoo'
Carikli:
> Hi,
> 
> The license of all these packages have that inside:
> > 3) You may not charge a fee for the game itself. This includes
> > reselling the game as an individual item.
> 
> And the FSDG has that:
> > Non-functional Data
> > ---
> > Data that isn't functional, that doesn't do a practical job, is
> > more of an adornment to the system's software than a part of it. Th
> > Thus, we don't insist on the free license criteria for non-
> > functional data.  It can be included in a free system distribution
> > as long as its license gives you permission to copy and
> > redistribute, both for commercial and non-commercial purposes. For
> > example, some game engines released under the GNU GPL have
> > accompanying game information—a fictional world map, game graphics,
> > and so on—released under such a verbatim-distribution license. This
> > kind of data can be part of a free system distribution, even though
> > its license does not qualify as free, because it is non-functional.
> 
> So unfortunately here we need to remove these games.
We have been aware of this for about half a year now (see the thread in
guix-devel following [1]), but as other FSDG-abiding distributions
still include these games (or at least did back then) we postponed
their removal.

Cheers

PS: Tobias, do you have a reply from the licensing team?

[1] <48ce733acba20030aba9eba1a45e18a805cfcf73.ca...@gmail.com>

bug#62394: [PATCH] make more packages tunable

[Liliana Marie Prikler]

reassign 62394 guix-patches
thanks

> * gnu/packages/compression.scm (zlib): add (tunable? . #t) property
Should probably be ... (zlib)[properties]: Add tunable?.
Likewise for the other packages.

> +(properties '((tunable? . #t))) ;; advantages of Clear Linux
> over Ubuntu seen + perf:
> https://www.phoronix.com/review/zen4-clear-linux/2
>  (arguments
Don't exceed the line limit even in a comment.
Properties are supposed to be the *last* field of a package.

Cheers

bug#62174: Cannot use modules with an inferior kernel.

[Liliana Marie Prikler]

Am Montag, dem 13.03.2023 um 23:27 -0400 schrieb Robby Zambito:
> Hi,
> 
> I use an inferior to pin my kernel version, but it seems like I
> cannot
> use modules with it. The following works fine:
> 
> ```
> (use-package-modules linux)
> (operating-system
>   ...
>   (kernel linux-libre)
>   (kernel-loadable-modules (list v4l2loopback-linux-module))
>   ...)
> ```
> 
> As does the following:
> 
> ```
> (define rz/linux
>   (let* ((channels
>   (list (channel
>  (name 'guix)
>  (url "https://git.savannah.gnu.org/git/guix.git;)
>  (commit
> "c81d2d448cbd051800867fe3f4b82ef3f4380ebf"
>  (inferior (inferior-for-channels channels))
>  (kernel-version "6.1.15"))
>     (first (lookup-inferior-packages inferior "linux-libre" kernel-
> version
> 
> (operating-system
>   ...
>   (kernel rz/linux)
>   ...)
> ```
> 
> However when I combine the two (using the inferior for the kernel +
> specify modules)...
> 
> ```
> (operating-system
>   ...
>   (kernel rz/linux)
>   (kernel-loadable-modules (list v4l2loopback-linux-module))
>   ...)
> ```
> 
> I get the following error:
> 
> ```
> Backtrace:
> In guix/store.scm:
>    659:37 19 (thunk)
>    1298:8 18 (call-with-build-handler #
> …)
>   2168:25 17 (run-with-store #
> …)
> In guix/scripts/system.scm:
>     843:2 16 (_ _)
>     717:8 15 (_ #)
> In gnu/system.scm:
>   1307:19 14 (operating-system-derivation _)
> In gnu/services.scm:
>   1140:36 13 (_ _)
> In srfi/srfi-1.scm:
>    586:29 12 (map1 (#< type: #
> …))
>    586:29 11 (map1 (#< type: #
> …))
>    586:29 10 (map1 (#< type: #
> …))
>    586:29  9 (map1 (#< type: #
> …))
>    586:17  8 (map1 (#< type: # …>))
> In gnu/services.scm:
>    951:29  7 (linux-builder-configuration->system-entry _)
> In guix/profiles.scm:
>     438:4  6 (packages->manifest _)
> In srfi/srfi-1.scm:
>    586:17  5 (map1 ((#)
> …))
> In guix/inferior.scm:
>     549:2  4 (loop (#)
> …)
>     529:4  3 (inferior-package-input-field (#)
> …)
>    473:18  2 (inferior-package-field (#)
> …)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure struct-vtable: Wrong type argument in position 1
> (expecting struct): (# linux-libre@6.1.15 7ff5261088a0>)
> ```
> 
> It seems to me like this is a bug. If I am mistaken, some guidance
> would be appreciated.
I think you should try to pin the kernel modules as well.  If that
still doesn't work as intended (it very well might), we have a proper
case of something that should work but doesn't.

Cheers

bug#62176: [PATCH] Update Mesa to 22.2

[Liliana Marie Prikler]

Am Dienstag, dem 14.03.2023 um 06:31 +0100 schrieb Dr. Arne
Babenhauserheide:
> Hi,
> 
> the attached patch updates mesa to version 22.
Please do one patch per package and don't mix stylistic and functional
changes.

> The patch from core-updates is still missing. It may be a good idea
> to add that, too.
libdrm and mesa need to go through core-updates, wayland-protocols on
the other hand has few dependents and could go to master as-is.  Please
split the bugs accordingly for quicker processing.

Cheers

bug#58813: [PATCH v2] doc: Document how to use Patman for patches submission.

[Liliana Marie Prikler]

Hi,

Am Dienstag, dem 07.03.2023 um 18:39 +0100 schrieb Simon Tournier:
> I still think this documentation for configuring ’patman’ about
> “Patch management” is helpful.  I think it could be part of the
> manual.  If not for reasons I am missing, at least this documentation
> should be included in the Cookbook.
There are two discussions here:
1. Should we "mandate" the use of patman?
2. Should we describe how to use patman for submitting patches to Guix?
I think most agree with the latter, but disagree with the former. 
Thus, whatever steps you add for the use with patman must be easily
enough replicated by people not using it, or else we risk low adoption
of best practices.

> And from my point of view, if we say that [1,2] fits the manual, then
> this dedicated section about “Patch management” also fits the manual.
> If this dedicated section about “Patch management” also does not fit
> the manual, then [1,2] neither. :-)
> 
> 1: 
> 2:
> 
I think [2] is distinct here in that it discusses Guix-specific quirks
when using TeX.

Cheers

bug#61570: Backward incompatible changes in mpd-service-type

[Liliana Marie Prikler]

Am Montag, dem 06.03.2023 um 20:13 -0500 schrieb Maxim Cournoyer:
> > Am Freitag, dem 17.02.2023 um 07:53 -0500 schrieb Maxim Cournoyer:
> > > Else an error rather than a warning when multiple same-name users
> > > are defined would be more appropriate, I think.
> > Guess what, it used to be a formatted message (i.e. an actual
> > error).  However, that broke some configs as reported in [1], so I
> > demoted it to a warning.
> 
> Interesting.  I didn't know we were usefully (?) abusing duplicate
> users and group.
As far as I'm aware, we aren't.  Even if such uses exist, they raise
said warning and probably cause more issues down the line, like with
your bug report.

> Perhaps we should try to isolate the most common offenders
> (services?), fix them up, and then re-introduce the check, perhaps
> gradually (e.g. "in 6 months time, duplicated users or groups will
> become a configuration error").
The only instance known to me (cups creating a duplicate lp group) was
fixed back in 2021.

Cheers

bug#58813: [PATCH] doc: Document how to use Patman for patches submission.

[Liliana Marie Prikler]

Am Freitag, dem 03.03.2023 um 10:54 +0100 schrieb Ludovic Courtès:
> Hi,
> 
> Maxim Cournoyer  skribis:
> 
> > Fixes .
> 
> It’s only tangentially related, no?
> 
> > * doc/contributing.texi (Sending a Patch Series): Mention Patman. 
> > Adjust the examples to no longer showcase broken command
> > substitutions.  Add a section about how to use Patman, with
> > examples.
> 
> I’m not convinced we’d want to advocate for yet another tool.  I feel
> like this would make patch submission guidelines even more complex,
> or at least look more complex.
I do think it'd be fine to have more options (in a "use what you find
convenient" way), but as-is this patch replaces one imperfect tool with
one where:

> [H]ow many of the ~40 committers would be able to provide guidance
> with patman?  
I'm not one of them :(

> That shouldn’t be the only criterion, but it certainly is an
> important one.
I think an important criterion should be what aspiring committers can
expect when they follow the advice as written.  Compare and contrast
'guix style', where committers often have to point out its flaws.

Cheers

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Liliana Marie Prikler]

Am Mittwoch, dem 01.03.2023 um 17:11 +0100 schrieb Csepp:
> 
> b...@bokr.com writes:
> 
> > Hi,
> > 
> > On +2023-03-01 12:16:56 +0100, Csepp wrote:
> > [...]
> > > How the hell would my paths affect what's in the bin folder? 
> > > Like, the flatpak binary is literally not present in the profile,
> > > that's why it's not showing up in $PATH.
> > 
> > Could something in one of your path directories
> > accidentally have gotten a name starting with '-' ?
> > (or full name '-')?
> > 
> > Surprising things can happen depending on how an
> > app rejects an unexpected option, or tries to use it :)
> > 
> > BTW: If you can't delete a file named '-'
> >  try emacs dirmode. IIRC emacs seems to see
> >  anything and be able to delete it.
> > 
> > Do you have any scripts that are both sourced and executed?
> > If so, are they doing return or exit respectively or
> > something trickier as intended?
> 
> So, first things first:
> % guix package -I | grep -E '(flatpak|roam)'
> emacs-org-roam  2.2.2-
> 0.74422df out /gnu/store/bxxjy8ydm62fr0bckxfrj27x
> nlvqbfmy-emacs-org-roam-2.2.2-0.74422df
> flatpak 1.14.1  out /gnu/
> store/mf0k987xvpgk79l74lmdjv9jz8gy8cdf-flatpak-1.14.1
> 
> Both are installed.
> 
> ls $(guix build flatpak)/bin/
> flatpak  flatpak-bisect  flatpak-coredumpctl
> 
> The store paths also match.
> 
> This path also exists:
> $(guix build emacs-org-roam)/share/emacs/site-lisp/org-roam-2.2.2-
> 0.74422df
You're comparing apples to oranges here.  `guix build' need not
reproduce the contents of your profile, especially if you pulled a new
version of guix in between.  Instead, try listing the contents of the
reported store paths.

As for `guix build' and `guix shell' producing different results within
a single generation, the only instance I know of which has this
requires the presence of grafts (and IIRC might already be fixed?)

> I don't know the details of how Emacs loads things, but org-roam has
> an org-roam-autoloads.el while lsp-mode (a package that does work)
> does not.
There ought to be a subdirs.el in your $GUIX_PROFILE/share/emacs/site-
lisp, which explicitly mentions the directories to add to your load
path.  These are store paths.  Thus, even in the off chance that some
symlink in your profile is gone (which I'd find highly alerting in the
first place), it should correctly see the package to add.

> Some relevant paths:
> EMACSLOADPATH=/home/raingloom/.guix-profile/share/emacs/site-lisp
> PATH=/home/raingloom/.local/bin:/run/setuid-
> programs:/home/raingloom/.config/guix/current/bin:/home/raingloom/.gu
> ix-profile/bin:/home/raingloom/.guix-profile/sbin:/run/current-
> system/profile/bin:/run/current-system/profile/sbin
> 
> The only additional item is on PATH and at worst it would shadow an
> existing flatpak binary.  But it doesn't, there is just a single
> utility
> script there that I should probably get rid of.
> 
> Also:
> guix shell --check -p .guix-profile
> This seems to hang.  Or at least it's taking an awful long time for
> something so simple.
You could try something easier like the aforementioned `guix shell
emacs-next-pgtk emacs-org-roam --pure --check'.

> I'm running Guix as my system distro and I'm not in the habit of
> adding random junk to my dotfiles, so I would be rather surprised if
> this turned out to be a path issue
Good to know.

> especially when it's obvious the packages are literally not even
> showing up in the profile they are supposed to show up in.
This was not obvious from your previous report, which see
> emacs-org-roam is installed in my default profile and all the other
> emacs packages work with the emacs-next-pgtk package in the same
> profile.
> guix shell emacs-org-roam emacs-next-pgtk does not work, guix shell
> emacs-org-roam emacs does.
Basing my response on this rather than the otherwise inconsequential
bit about flatpak, it would appear as though you are reporting a bug
specific to emacs-next-pgtk rather than emacs-org-roam.

> % ls ~/.guix-profile/share/emacs/site-lisp/
> 
> This does not print any org-roam directory.
Which leads me to believe that
$ ls /gnu/store/bxxjy8ydm62fr0bckxfrj27xnlvqbfmy-emacs-org-roam-2.2.2-
0.74422df/share/emacs/site-lisp
does not report any such directory either.

If that is indeed the case, try `guix build --repair'-ing it.

This still does not explain the different behaviour of emacs vs. emacs-
next-pgtk in your shell, which has further debugging complexities due
to the lack of isolation.

Cheers

bug#56584: vala build uses bundled bootstrap binaries

[Liliana Marie Prikler]

Am Mittwoch, dem 01.03.2023 um 05:00 + schrieb Adam Faiz:
> > Looking at the vala source code, we can bootstrap the current
> > version from 0.39.5.8, which appears to be between release cycles –
> > 0.39.6 already requires it, whereas 0.39.5 bootstraps from 0.25.1. 
> > I'm not sure how to get 0.25.1 to build from source, though.  The
> > code in vala-bootstrap does not appear helpful, it in fact reads
> > exactly like Vala-compiled Vala.
> > 
> > Cheers
> 
> > I've now hosted my own vala-bootstrap [1], which has valacompiler.c
> > and gee translated to more readable C already.  I'd be happy to
> > take in patches or transfer it to the bootstrappable project.
> > 
> > Cheers
> > 
> > [1] https://gitlab.gnome.org/lilyp/vala-bootstrap
> 
> An easier route to bootstrap Vala could be the archeological
> approach:
> 
> Oldest commit(SVN import): 68f95ffe3aef82aac0fb7bbc65d1faab19902e3c
> Last commit with only C code(except for tests written in Vala): 
> c300d9c3d0af08f628b6c260bdd32f431a47e0f2
> 
> Became self-hosting(it still bootstraps with written C code under
> valac/): 
> 29a1dec53a4661779cc819ede69732c6c1118088
> 
> Removed bootstrappability(removed valac/ directory and uses Vala-
> generated C code under ccode/):
> 35bd6909ba2b8467ba95dfe6360e7a7e227115c8
> 
> Oldest release: VALA_0_0_1
> 
> This information should make it possible to bootstrap Vala.
Provided that we find a version of yacc that doesn't choke on the
grammar files.  Also, we got an uncertain road ahead for Valas before
0.35.1, and then vala 0.39.6 did a dirty bump in which they rely on a
practically unreleased version.

So yes, the archeological approach could work, but I wouldn't
necessarily count on it being "easy".

Cheers