bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[Maxim Cournoyer]

Hi,

Today I encountered an issue where after re-installing a Guix System, I
couldn't add a new printer anymore.  Any CUPS client (including the
trusty localhost:631 HTTP page) would loop on authenticating my user.

After consulting the logs and finding this kind of line:

--8<---cut here---start->8---
pam_authenticate() returned 7 (Authentication failure)
--8<---cut here---end--->8---

I started looking at our PAM configuration for CUPS, but we currently
have none, which is probably the issue.  Using 'cups-minimal' instead of
cups (which is built with linux-pam) solves the issue, as the 'cups'
value provided to the  record.

We should probably make cups-minimal the default, or extend our
pam-service-type with the relevant PAM entries.

Thoughts/takers?

-- 
Thanks,
Maxim

bug#63197: video acceleration/libva segfaults caused by stale mesa shader cache

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hi,
>
> After reinstalling someone's desktop which has support for VA-API,
> 'vainfo' from 'libva-utils' would consume all the memory then crash.
> Other applications relying on libva would crash as well, e.g. ffmpeg (or
> its users, such as vlc/jami).  Here's a sample output from VLC:
>
> vlc received_605209834855384.mp4 
> VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
> [0109d770] main libvlc: Lancement de vlc avec l'interface par défaut. 
> Utiliser « cvlc » pour démarrer VLC sans interface.
> libva info: VA-API version 1.17.0
> libva info: Trying to open 
> /gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri/radeonsi_drv_video.so
> libva info: Found init function __vaDriverInit_1_17
> Erreur de segmentation
>
>
> After tracing the process, I noticed that the last thing it did was
> loading its mesa shader cache, stored under:
>
> ~/.cache/mesa_shader_cache
>
> Deleting that directory resolved the issue.
>
> It seems that'd be a bug in Mesa (for failing to determine that it
> should have invalidated its cache going from version 21 to 22 post
> core-updates merge).

I've forwarded this report upstream here:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8937

-- 
Thanks,
Maxim

bug#63197: video acceleration/libva segfaults caused by stale mesa shader cache

[Maxim Cournoyer]

Hi,

After reinstalling someone's desktop which has support for VA-API,
'vainfo' from 'libva-utils' would consume all the memory then crash.
Other applications relying on libva would crash as well, e.g. ffmpeg (or
its users, such as vlc/jami).  Here's a sample output from VLC:

--8<---cut here---start->8---
vlc received_605209834855384.mp4 
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[0109d770] main libvlc: Lancement de vlc avec l'interface par défaut. 
Utiliser « cvlc » pour démarrer VLC sans interface.
libva info: VA-API version 1.17.0
libva info: Trying to open 
/gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_17
Erreur de segmentation
--8<---cut here---end--->8---

After tracing the process, I noticed that the last thing it did was
loading its mesa shader cache, stored under:

--8<---cut here---start->8---
~/.cache/mesa_shader_cache
--8<---cut here---end--->8---

Deleting that directory resolved the issue.

It seems that'd be a bug in Mesa (for failing to determine that it
should have invalidated its cache going from version 21 to 22 post
core-updates merge).

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

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

I agree looks nice "on paper", but in practice, I was confronted with
the following problem, which is enough annoying to make me want to go
back to the simpler string contract:

A  record encodes a lossy version of a  as a
string, as its 'group' field.  This way of specifying a group implies it
already exist, since it doesn't capture all the  details,
e.g.: is it a system group or not?

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

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.).  We'd probably
now need to export %users-group, %audio-group, etc. to make this API a
bit more manageable/convenient.

-- 
Thanks,
Maxim

bug#63155: bug#63159: [PATCH 1/2] gnu: slim: Fix build failure with GCC-11

[Ludovic Courtès]

Hi,

Brian Cully  skribis:

> GCC-11 sniffed out a long-standing bug where a pointer was being tested for a
> negative value, which is impossible. Instead, check for NULL, which is how the
> error result is actually returned.
>
> See https://github.com/iwamatsu/slim/issues/14 for details.
>
> * gnu/packages/display-managers.scm (slim) [fix-0-pointer-comparison]: new
> phase

[...]

> Moved to github, according to https://www.berlios.de/software/slim/.
>
> * gnu/packages/display-managers.scm (slim) [home-page]:  update URL.

Applied, thanks!

Ludo’.

bug#63043: texlive-font-maps.drv build failure when profiles lacks texlive-* packages

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

>> There were cases (like GDK pixbuf, GLib schemas, and all that) where the idea
>> was to take whichever glib/GDK we’d find in the dependency graph, and
>> pick the command we need from it.  That way, we wouldn’t introduce any
>> additional dependency.  That was the reasoning.
>>
>> Thinking about, this particular case might be easier: we can make things
>> consistent like so:

[...]

>> +(if (and texlive-base (pair? texlive-inputs))
>>  (gexp->derivation "texlive-font-maps" build
>>#:substitutable? #f
>>#:local-build? #t
>>
>>
>> That way, the hook only fire if we have ‘texlive-base’ (somewhere in the
>> graph) *and* we have texlive-* packages in the manifest.
>
> That is equivalent, but it doesn't address the core problem in my
> opinion.  There's no use to run hooks for things which aren't propagated
> at the level of the profile, I think.  If texlive-base in is the
> profile, the person wants to use tex and friends.  But if it's wrapped
> by some package deep down, we shouldn't care.
>
> I see it the same way as when using libraries and compilers in a
> profile; the compiler (consumer) needs to be present else no search path
> is created.
>
> Does it make sense?

I agree with the reasoning; I think it doesn’t apply to the GLib schemas
and GDK pixbuf caches though.

For TeX Live font maps, maybe it applies, though I’m not entirely sure
(I wouldn’t be surprised if things other than ‘texlive-base’ are
consumers of font maps).  Plus, since the patch I proposed is simple,
I’m inclined to just do that.

Thoughts?

Ludo’.

bug#63190: [Shepherd] Nested calls lead to a hang

[Bruno Victal]

Original discussion (IRC): 



Minimal example (annotated):

test-system.scm:
--8<---cut here---start->8---
(use-modules (gnu)
 (gnu tests)
 (gnu packages)
 (gnu packages base) ; coreutils/sleep
 (gnu packages admin)  ; shepherd
 (gnu services shepherd))

;; Some dummy service whose start action simply waits for some seconds,
;; about enough to check with herd status before it exits.
(define dummy-service-type
  (shepherd-service-type
   'dummy
   (lambda (cfg)
 (shepherd-service
  (documentation "Dummy action to start service.")
  (provision '(dummy-service))
  (respawn? #f); << note, this disables the service!
  (modules (cons* '(gnu services herd)
  %default-modules))
  (start #~(lambda _
 (format #t "Starting a delay on dummy service.~%")
 (fork+exec-command (list #$(file-append coreutils "/bin/sleep")
  "30"
  (stop #~(make-kill-destructor))
  (actions
   (list (shepherd-action
  (name 'my-action)
  (documentation "lorem ipsum")
  (procedure
   #~(lambda (x)
   ;; Scenario 1: using code from (gnu services herd), this 
hangs shepherd
   #;(start-service 'dummy)  ; hangs shepherd
   ;; Scenario 2: this doesn't hang shepherd but do note that 
the service has to be re-enabled either manually or automatically here
   #;(system* #$(file-append shepherd "/bin/herd") "start" 
"dummy-service")
   ;; Scenario 3: use the already imported (shepherd service) 
module, doesn't hang shepherd
   ;; Like Scenario 2, the service must be 
re-enabled since (respawn? #f) disabled this.
   ;; Comment: Won't re-enabling mean that this 
service will relaunch once it quits?
   ;;  That means the service has to 
disable itself on a successful exit, perhaps within the (stop ...) field?
   (start 'dummy-service
   #f  ; no config
   (description "lorem ipsum.")))

(operating-system
  (inherit %simple-os)
  (services
   (cons*
(service dummy-service-type)
%base-services)))

--8<---cut here---end--->8---


Required modifications to gnu/services/shepherd.scm for scenario 1:

--8<---cut here---start->8---
diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index b2601c0128..158806f421 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -282,7 +282,8 @@ (define (shepherd-service-file-name service)
 
 (define (shepherd-service-file service)
   "Return a file defining SERVICE."
   (scheme-file (shepherd-service-file-name service)
-   (with-imported-modules %default-imported-modules
+   (with-imported-modules (cons '(gnu services herd)
+%default-imported-modules)
  #~(begin
  (use-modules #$@(shepherd-service-modules service))
--8<---cut here---end--->8---

bug#63150: [PATCH 1/2] gnu: quilt: Fix build because of grep warnings.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* gnu/packages/patches/quilt-avoid-grep-warnings.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/patchutils.scm (quilt): Use it.
---
Hi everyone,

This should fix the build and also update quilt.

Best,

 gnu/local.mk  |   1 +
 .../patches/quilt-avoid-grep-warnings.patch   | 142 ++
 gnu/packages/patchutils.scm   |   3 +-
 3 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/quilt-avoid-grep-warnings.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 1a84e5b499..06e5f5aa7f 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1825,6 +1825,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/qtwayland-gcc-11.patch  \
   %D%/packages/patches/qtwayland-dont-recreate-callbacks.patch \
   %D%/packages/patches/qtwayland-cleanup-callbacks.patch   \
+  %D%/packages/patches/quilt-avoid-grep-warnings.patch \
   %D%/packages/patches/ragel-char-signedness.patch \
   %D%/packages/patches/randomjungle-disable-static-build.patch \
   %D%/packages/patches/range-v3-build-with-gcc10.patch \
diff --git a/gnu/packages/patches/quilt-avoid-grep-warnings.patch 
b/gnu/packages/patches/quilt-avoid-grep-warnings.patch
new file mode 100644
index 00..b91dc98695
--- /dev/null
+++ b/gnu/packages/patches/quilt-avoid-grep-warnings.patch
@@ -0,0 +1,142 @@
+From f73f8d7f71de2878d3f92881a5fcb8eafd78cb5f Mon Sep 17 00:00:00 2001
+From: Jean Delvare 
+Date: Fri, 9 Sep 2022 10:10:37 +0200
+Subject: Avoid warnings with grep 3.8
+
+GNU grep version 3.8 became more strict about needless quoting in
+patterns. We have one occurrence of that in quilt, where "/"
+characters are being quoted by default. There are cases where they
+indeed need to be quoted (typically when used in a sed s/// command)
+but most of the time they do not, and this results in the following
+warning:
+
+grep: warning: stray \ before /
+
+So rename quote_bre() to quote_sed_re(), and introduce
+quote_grep_re() which does not quote "/".
+
+Signed-off-by: Jean Delvare 
+---
+ quilt/diff.in |  2 +-
+ quilt/patches.in  |  2 +-
+ quilt/scripts/patchfns.in | 20 +---
+ quilt/upgrade.in  |  4 ++--
+ 4 files changed, 17 insertions(+), 11 deletions(-)
+
+diff --git a/quilt/diff.in b/quilt/diff.in
+index e90dc33..07788ff 100644
+--- a/quilt/diff.in
 b/quilt/diff.in
+@@ -255,7 +255,7 @@ then
+   # Add all files in the snapshot into the file list (they may all
+   # have changed).
+   files=( $(find $QUILT_PC/$snap_subdir -type f \
+-| sed -e "s/^$(quote_bre $QUILT_PC/$snap_subdir/)//" \
++| sed -e "s/^$(quote_sed_re $QUILT_PC/$snap_subdir/)//" \
+ | sort) )
+   printf "%s\n" "${files[@]}" >&4
+   unset files
+diff --git a/quilt/patches.in b/quilt/patches.in
+index bb17a46..eac45a9 100644
+--- a/quilt/patches.in
 b/quilt/patches.in
+@@ -60,7 +60,7 @@ scan_unapplied()
+   # Quote each file name only once
+   for file in "${opt_files[@]}"
+   do
+-  files_bre[${#files_bre[@]}]=$(quote_bre "$file")
++  files_bre[${#files_bre[@]}]=$(quote_grep_re "$file")
+   done
+ 
+   # "Or" all files in a single pattern
+diff --git a/quilt/scripts/patchfns.in b/quilt/scripts/patchfns.in
+index c2d5f9d..1bd7233 100644
+--- a/quilt/scripts/patchfns.in
 b/quilt/scripts/patchfns.in
+@@ -78,8 +78,14 @@ array_join()
+   done
+ }
+ 
+-# Quote a string for use in a basic regular expression.
+-quote_bre()
++# Quote a string for use in a regular expression for a grep pattern.
++quote_grep_re()
++{
++  echo "$1" | sed -e 's:\([][^$.*\\]\):\\\1:g'
++}
++
++# Quote a string for use in a regular expression for a sed s/// command.
++quote_sed_re()
+ {
+   echo "$1" | sed -e 's:\([][^$/.*\\]\):\\\1:g'
+ }
+@@ -215,7 +221,7 @@ patch_in_series()
+ 
+   if [ -e "$SERIES" ]
+   then
+-  grep -q "^$(quote_bre $patch)\([ \t]\|$\)" "$SERIES"
++  grep -q "^$(quote_grep_re $patch)\([ \t]\|$\)" "$SERIES"
+   else
+   return 1
+   fi
+@@ -365,7 +371,7 @@ is_applied()
+ {
+   local patch=$1
+   [ -e $DB ] || return 1
+-  grep -q "^$(quote_bre $patch)\$" $DB
++  grep -q "^$(quote_grep_re $patch)\$" $DB
+ }
+ 
+ applied_patches()
+@@ -465,7 +471,7 @@ remove_from_db()
+   local tmpfile
+   if tmpfile=$(gen_tempfile)
+   then
+-  grep -v "^$(quote_bre $patch)\$" $DB > $tmpfile
++  grep -v "^$(quote_grep_re $patch)\$" $DB > $tmpfile
+   cat $tmpfile > $DB
+   rm -f $tmpfile
+   [ -s $DB ] || rm -f $DB
+@@ -520,7 +526,7 @@ find_patch()
+   fi
+ 
+   local patch=${1#$SUBDIR_DOWN$QUILT_PATCHES/}
+-  local bre=$(quote_bre "$patch")
++  local 

bug#63150: [PATCH 2/2] gnu: quilt: Update to 0.67.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* gnu/packages/patchutils.scm (quilt): Update to 0.67.
---
 gnu/packages/patchutils.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/patchutils.scm b/gnu/packages/patchutils.scm
index 465e605010..88c2cbc907 100644
--- a/gnu/packages/patchutils.scm
+++ b/gnu/packages/patchutils.scm
@@ -110,14 +110,14 @@ (define-public patchutils
 (define-public quilt
   (package
 (name "quilt")
-(version "0.66")
+(version "0.67")
 (source
  (origin
(method url-fetch)
(uri (string-append "mirror://savannah/quilt/"
"quilt-" version ".tar.gz"))
(sha256
-(base32 "01vfvk4pqigahx82fhaaffg921ivd3k7rylz1yfvy4zbdyd32jri"))
+(base32 "1hiw05aqysbnnl15zg2n5cr11k0z7rz85fvq8qv6qap7hw4vxqrv"))
(patches (search-patches "quilt-avoid-grep-warnings.patch"
 (build-system gnu-build-system)
 (native-inputs
-- 
2.39.2

bug#63150: (no subject)

[Maze]

Guix distributes quilt version 0.66, there is a version 0.67 that quilt
released as a tarball in 2022 but this version still has the bug in its
test suite as it relates to the latest grep.

I just tried, at the time of writing the HEAD (as cloned) of the git
repo of quilt successfully goes through the check target of its Makefile.

I got it through:
git clone https://git.savannah.nongnu.org/git/quilt.git
And I completed the make check with their commit:
c1ce964f3e9312100a60f03c1e1fdd601e1911f2

I have a dire need for quilt to build in guix because I use
netcat-openbsd a lot.  For practical reasons, it would be much better
(for me) if a fix could hit the master branch quickly. Buf if
not... well, I suppose this can be worked around with a special quilt
and a special netcat-openbsd package.