bug#63156: guix package -u failure on pyopengl-accelerate-3.1.5

[Lars-Dominik Braun]

Hi,

I discovered this issue independently and fixed it in commit 
3d05d549184d5399d2949535cf5cad8b92b263dd.

Cheers,
Lars

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

[Josselin Poiret via Bug reports for GNU Guix]

Hi Nathan,

Nathan Dehnel  writes:

> Gtk:ERROR:gtkiconhelper.c:494:
> ensure_surface_for_gicon: assertion
> failed (error == NULL): Failed to load
> /run/current-system/profile/share/icons/Adwaita/16x16/status/image-missing.png:
> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
> Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon:
> assertion failed (error == NULL): Failed to load
> /run/current-system/profile/share/icons/Adwaita/16x16/status/image-missing.png:
> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>
> This is breaking various apps like viewnior, xfce4-power-manager,
> causing firefox to crash when opening the file picker, making app
> icons not appear, etc.

So, GDK Pixbuf has a dynamic loader mechanism, where additional formats
can be added via additional loaders, which are usually all installed in
the same directory.  In Guix, this means that we need to point GDK
Pixbuf to a list of loaders to use that is dependent on what is
installed (there's no easy way to record this per-package, embed it
inside of it and then use that only there like with the ld cache).  For
that, we use the environment variable GDK_PIXBUF_MODULE_FILE, which is a
search-path for the package gdk-pixbuf, meaning that it is set only if
gdk-pixbuf is installed in your profile.

Now, if we had packaged everything properly, all the applications you
mention should *propagate* gdk-pixbuf and not just list it as an input,
so that it always gets installed to the profile as well, but that's not
the case!  The reason it doesn't happen for other users is because they
have some applications which pull in gdk-pixbuf inside the profile!  So
we should fix this and propagate gdk-pixbuf everywhere (something which
I'm not too much a fan of, but alas).

In the meantime, you can manually install gdk-pixbuf to your profile,
log-out and log-in and it should hopefully work.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#60657: Rethinking how service extensions work

[Ludovic Courtès]

Hi Bruno,

Bruno Victal  skribis:

> On 2023-02-25 17:46, Ludovic Courtès wrote:

[...]

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

OK.  Cosmetic considerations: how about adding a ‘pre-start’ field in
?  That would allow us to keep the “setup” bit
visually separate from the actual ‘start’ method, even if under the hood
they get “merged” together:

  (shepherd-service
;; …
(pre-start #~(mkdir-p "/whatever"))
(start #~(make-forkexec-constructor …)))

> There's one issue I'm somewhat concerned about, consider the following 
> snippet:
>
>
> (define log-directory "/var/log")
> (define username "notroot")
>
> (start
>  #~(lambda _
> (mkdir-p/perms #$log-directory (getpw #$username) #o750)
> ...))
>
> 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?

We ensure /var/log exists before anything else—see ‘directives’ in (gnu
build install).

If we want an extra safety, we can add a real activation snippet that
does (mkdir-p "/var/log"), with the understanding that it would notably
run at boot time before shepherd is started.

> In either case, with or without refactoring this issue is already present 
> (but in activation-service extensions)
> so it's no worse than the status quo.

Right.

>> Note that this should prolly be declared as a ‘file-system’ rather than
>> as a custom service.  That way, it would get a “standard” Shepherd
>> service.
>> 
>> There are cases where we add explicit dependencies on
>> ‘file-system-/media/foo’ or similar.   has a ‘dependencies’
>> field specifically for this purpose (info "(guix) File Systems").
>> 
>> Would that work for you?
>
> Unfortunately OverlayFS is filtered out from fstab by Guix (reported #60246) 
> and the dependencies field IMO is too restrictive,
> there should be a (sane) way to pass shepherd service symbols too. (for cases 
> where a file system depends on 'networking or
> depends on a particular interface e.g. NFS mount that uses a IPv6 link-local 
> address)

Sure, we could make these changes.  Let’s discuss it separately?

Thanks,
Ludo’.

bug#63331: Guile-GnuTLS/Git circular dependency

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> That sort of makes sense, although I don't know why this wasn't failing
> in the same way in the past. Build logs are available though, so maybe
> this makes sense to someone.

Turns out that’s because ‘gnutls-cross.patch’ was inadvertently
dismissed in 5e1e67442188ccca8db8c1dd092efbc6fc2c33dc.

I’ll re-apply it (probably upstream as well) unless someone has already
come up with a different solution (Josselin was looking into it).

Thanks,
Ludo’.

bug#63443: download retry bug; mkdir: File exists

[Attila Lendvai]

maybe this commit has a bug?

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8bd4126917f59f4af9a4323c3d5699201862dca2

i get a "mkdir: File exists" error:

1,198.1 MB will be downloaded
substitute: updating substitutes from 'https://substitutes.nonguix.org'... 
100.0%
substitute: updating substitutes from 'https://substitutes.nonguix.org'... 
100.0%
locale-2.33 1.9MiB 567KiB/s 00:04 ▕██▏ 100.0%
dtc-1.6.1 96KiB 106KiB/s 00:01 ▕██▏ 100.0%
linux-firmware-20230404 267.8MiB 119KiB/s 04:57 ▕██▎ ▏ 12.8%retrying download 
of '/gnu/store/i5cjfma5k2fz0h278ypqbdzhl4pjdzjf-linux-firmware-20230404' with 
other substitute URLs...
linux-firmware-20230404 267.8MiB 226KiB/s 00:01 ▕ ▏ 0.0%guix substitute: error: 
mkdir: File exists: 
"/gnu/store/i5cjfma5k2fz0h278ypqbdzhl4pjdzjf-linux-firmware-20230404"
substitution of 
/gnu/store/i5cjfma5k2fz0h278ypqbdzhl4pjdzjf-linux-firmware-20230404 failed
guix system: error: corrupt input while restoring archive from #

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The world is not to be narrowed till it will go into the understanding… but 
the understanding to be expanded and opened till it can take in the image of 
the world as it is in fact.”
— Sir Francis Bacon (1561–1626)

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

[pelzflorian (Florian Pelz)]

Hi all.

Josselin Poiret via Bug reports for GNU Guix  writes:
> For
> that, we use the environment variable GDK_PIXBUF_MODULE_FILE, which is a
> search-path for the package gdk-pixbuf, meaning that it is set only if
> gdk-pixbuf is installed in your profile.  […] So
> we should fix this and propagate gdk-pixbuf everywhere (something which
> I'm not too much a fan of, but alas).

The cambalache package does the right thing by wrapping the program to
setenv GDK_PIXBUF_MODULE_FILE to the value it has while building the
package.  glib-or-gtk build system sets GDK_PIXBUF_MODULE_FILE while
building the package.  Note that gdkpixbuf and perhaps
librsvg-for-system must be in inputs.

Regards,
Florian

bug#63378: [PATCH] teams: Fix script to produce a single X-Debbugs-Cc header.

[Arun Isaac]

Hi Maxim,

Thank you for the updated patch! :-) It LGTM. Please push.

> OK!  I opted for simplicity and double-quoted all the names.

Fair enough. Though a check is only one condition away! ;-)

(if (string-contains? (person-name member) ",")
(string-append "\"" (person-name member) "\"")
(person-name member))

Regards,
Arun

bug#63009: /profile/bin missing from PATH for ssh commands

[Ludovic Courtès]

Hi,

This patch had fallen through the cracks…

Janneke Nieuwenhuizen  skribis:

>>From 2ac41477dad5699b748acfc72d4e91e0e14fa16a Mon Sep 17 00:00:00 2001
> From: Janneke Nieuwenhuizen 
> Date: Sat, 22 Apr 2023 09:58:48 +0200
> Subject: [PATCH] gnu: system: Cater for Guix Home in PATH.
>
> * gnu/system.scm (operating-system-etc-service): Also add a user's
> /profile/bin directory to PATH, before /bin.

LGTM, thanks!

Ludo’.

bug#63445: guix-build-coordinator guile-gnutls segfault

[Christopher Baines]

I've seen the build coordinator on bayfront crash a couple of times, and
it seems to be segfaulting, maybe in gnutls?

May 11 14:31:39 localhost vmunix: [15795370.287670] build-submitted[6013]: 
segfault at 0 ip 7f1e2e796415 sp 7f1b86ffd640 error 4 in 
guile-gnutls-v-2.so.0.0.0[7f1e2e79+17000]
May 11 14:31:39 localhost vmunix: [15795370.287692] Code: 01 00 41 0f b7 14 24 
48 3b 10 0f 85 85 00 00 00 49 8b 6c 24 08 48 89 f3 48 89 ef e8 d5 9d ff ff 4c 
8b 68 08 41 f6 c5 06 75 0d <49> 8b 45 00 83 e0 7f 48 83 f8 7d 74 3a 31 f6 bf 10 
00 00 00 e8 c2


May 11 14:47:31 localhost vmunix: [15796321.750945] build-submitted[697]: 
segfault at 0 ip 7f2194716415 sp 7f1ee3ffe5f0 error 4 in 
guile-gnutls-v-2.so.0.0.0[7f219471+17000]
May 11 14:47:31 localhost vmunix: [15796321.750968] Code: 01 00 41 0f b7 14 24 
48 3b 10 0f 85 85 00 00 00 49 8b 6c 24 08 48 89 f3 48 89 ef e8 d5 9d ff ff 4c 
8b 68 08 41 f6 c5 06 75 0d <49> 8b 45 00 83 e0 7f 48 83 f8 7d 74 3a 31 f6 bf 10 
00 00 00 e8 c2


signature.asc
Description: PGP signature

bug#63430: python-pyside-2-5.15.8

[Guillaume Le Vaillant]

"bdju" via Bug reports for GNU Guix  skribis:

> guix (GNU Guix) e0c35d1578c10a8fe27c8372f3a8bb5dd88b01b8
> guix system
> python-pyside-2-5.15.8 build log attached
>
> [3. text/plain; guix-build-failure_python-pyside-2-5.15.8.txt]...

Hi,
There a fix for this in Guix at e2eb43f945fd467e9b55a4b3c91cd186cf32e268
or later.
Closing.


signature.asc
Description: PGP signature

bug#63378: [PATCH] teams: Fix script to produce a single X-Debbugs-Cc header.

[Maxim Cournoyer]

Hi Arun,

Arun Isaac  writes:

> Hi Maxim,
>
> Thank you for the updated patch! :-) It LGTM. Please push.
>
>> OK!  I opted for simplicity and double-quoted all the names.
>
> Fair enough. Though a check is only one condition away! ;-)
>
> (if (string-contains? (person-name member) ",")
> (string-append "\"" (person-name member) "\"")
> (person-name member))

It's string-contains without ?, apparently.  Let's try this (and save a
few bytes per submission :-)):

--8<---cut here---start->8---
modified   etc/teams.scm.in
@@ -618,7 +618,11 @@ (define (sort-members members)

 (define (member->string member)
   "Return the 'email ' string representation of MEMBER."
-  (format #false "\"~a\" <~a>" (person-name member) (person-email member)))
+  (let* ((name (person-name member))
+ (quoted-name/maybe (if (string-contains name ",")
+(string-append "\"" name "\"")
+name)))
+(format #false "~a <~a>" quoted-name/maybe (person-email member

 (define* (list-members team #:optional port (prefix ""))
   "Print the members of the given TEAM."
--8<---cut here---end--->8---

The change is now installed; thanks for the review!

-- 
Thanks,
Maxim

bug#63414: Evaluation comparison on cuirass

[Christopher Baines]

Josselin Poiret via Bug reports for GNU Guix  writes:

> Hi Andreas,
>
> Andreas Enge  writes:
>
>> When working on a branch and deciding whether to merge it, we need a way
>> of comparing its status with that of the master branch. As far as I can see,
>> there is currently no way in cuirass to compare arbitrary evaluations and
>> get a list (or a dashboard) of builds that fail in one, but not the other.
>>
>> Andreas
>
> I guess that this is one of the features that the Build Coordinator was
> built for (and it is pretty damn good at this).  Maybe we could start
> considering whether it makes sense to duplicate effort on Cuirass and
> the Build Coordinator?  I don't know how "production-ready" the build
> coordinator is, compared to Cuirass?  Maybe we could target getting the
> Build Coordinator up to feature parity with Cuirass so that it may be
> used on a wider scale?  If this is something we want to focus on, we
> could create a team around it and set clear goals, which would probably
> lessen the burden that's on Chris currently.
>
> I understand that Cuirass is general enough to support much more than
> Guix, but the coordinator is a wonderful piece of software and our
> workflows might be outgrowing it.

There's some pedantic bits here to bring up. The build coordinator
doesn't have anything to do with comparing revisions (it doesn't even
really know what builds correspond to which revisions), it's just for
performing builds potentially across many machines, and doing something
useful with the results.

The data service however is meant for comparing revisions. There's a
circular relationship between the two as well, since the data service
can provide substitutes for derivations, which enables the build
coordinator to easily build them, and then report the results of those
builds back to the data service. This information about builds is
important since that can then factor in to comparisons between
revisions.

On the bit about "feature parity with Cuirass" though, this is a bit
misleading as the build coordinator exists because I wanted something
with very different design decisions to Cuirass. In terms of core
features, the build coordinator was complete back in late 2020
[1]. There's obviously lots that Cuirass does that the build coordinator
does not, but adding features without looking at the bigger picture can
be detrimental in the long term.

1: https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00417.html

This is not to say there aren't things to work on in the build
coordinator. There are some ideas in the README and I'm more than happy
to try and help people get more involved.


signature.asc
Description: PGP signature

bug#63426: hikari 2.3.3 build failure

[Simon Tournier]

Hi,

On mer., 10 mai 2023 at 21:23, Josselin Poiret via Bug reports for GNU Guix 
 wrote:

> I tried to look into it before the core-updates merge, but it seems that
> hikari is not maintained anymore, so I don't expect it to work with
> newer wlroots.

In that case, do we plan to remove this package hikari?

Cheers,
simon

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#63427: gdk-pixbuf unable to recognize image formats (JPG, PNG, etc.)

[Nathan Dehnel]

Installing gdk-pixbuf and rebooting didn't fix the issue:

viewnior 
'/home/nathan/Downloads/from-phone/Pictures/Screenshots/Screenshot_20230509-183317_F-Droid.png'

(viewnior:2482): Gtk-WARNING **: 16:14:57.820: Unable to locate theme
engine in module_path: "adwaita",

(viewnior:2482): Gtk-WARNING **: 16:14:57.822: Unable to locate theme
engine in module_path: "adwaita",
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6:
version `GLIBC_2.34' not found (required by
/gnu/store/yr4lbvdyc4dgs76yij1dw2w2z8s84af8-gnutls-3.7.7/lib/libgnutls.so.30)
Failed to load module:
/home/nathan/.guix-profile/lib/gio/modules/libgiognutls.so
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6:
version `GLIBC_2.34' not found (required by
/gnu/store/8sfnwc672lswqgkf9g5qv7r5247jyipp-libproxy-0.4.17/lib/libproxy.so.1)
Failed to load module:
/home/nathan/.guix-profile/lib/gio/modules/libgiolibproxy.so

** (viewnior:2482): WARNING **: 16:14:57.853: Pixbuf theme: Cannot
load pixmap file
/run/current-system/profile/share/themes/Adwaita-dark/gtk-2.0/assets/line.png:
Couldn’t recognize the image file format for file
“/run/current-system/profile/share/themes/Adwaita-dark/gtk-2.0/assets/line.png”


(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

** (viewnior:2482): WARNING **: 16:14:57.853: Invalid borders
specified for theme pixmap:

/run/current-system/profile/share/themes/Adwaita-dark/gtk-2.0/assets/line.png,
borders don't fit within the image

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)'
failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)'
failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)'
failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)'
failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)'
failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)'
failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)'
failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)'
failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viewnior:2482): GdkPixbuf-CRITICAL **: 16:14:57.853:
gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)'
failed

(viewnior:2482): GdkPixbuf-CRITICAL 

bug#63050: "guix pull" requires graphical libraries

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On ven., 05 mai 2023 at 15:21, Csepp  wrote:
>
>> Or just move it to a separate output or package?  That should really be
>> something done for all packages automatically tbh.  Alpine gets this right.
>
> Well, I do not think a separate output would be possible and we are not
> talking about the package named ’guix’ but about what is implemented by
> the module (guix self).
>
> Somehow, I agree that one direction would to make optional some
> features.  The current proposal for tackling this issue is the reduction
> of the closure by removing lix11 and libxrender as discussed in [1].
>
> 1: https://issues.guix.gnu.org/msgid/874jot19fd.fsf...@gnu.org
>
>
> Cheers,
> simon

It should be made possible IMHO.  It's nice that our packages come with
docs, including Guix, but they are often unnecessary.  If an output
won't work because guix-self is special, then maybe it could be moved to
a separate package.

bug#63378: [PATCH] teams: Fix script to produce a single X-Debbugs-Cc header.

[Arun Isaac]

> It's string-contains without ?, apparently.

Ah, yes. That one always trips me up.

> The change is now installed; thanks for the review!

Thank you! :-)

bug#63456: mesa build failure at guix package -u

[Andy Tai]

When I do guix package -u from the current guix repo,

mesa build fails at  mesa,

key parts of build log:

mesa-23.0.3/subprojects/expat.wrap
mesa-23.0.3/subprojects/perfetto.wrap
mesa-23.0.3/subprojects/zlib.wrap
patching file meson.build
Hunk #1 FAILED at 1479.
1 out of 1 hunk FAILED -- saving rejects to file meson.build.rej
source is at 'mesa-23.0.3'
applying 
'/gnu/store/r0ipng37a0bvfbczhy791ayg4kx1wkld-mesa-opencl-all-targets.patch'...
Backtrace:
   5 (primitive-load "/gnu/store/jz07f808827d1r0wn3rppv2i4lj…")
In ice-9/eval.scm:
619:8  4 (_ #(#(# "mes…") #))
In ice-9/boot-9.scm:
142:2  3 (dynamic-wind # …)
In ice-9/eval.scm:
619:8  2 (_ #(#(#)))
In srfi/srfi-1.scm:
634:9  1 (for-each # ("/gnu/store/r0…"))
In guix/build/utils.scm:
812:6  0 (invoke "/gnu/store/210yfax18r2g2inxrml9435ikhfcca6m-p…" …)

guix/build/utils.scm:812:6: In procedure invoke:
ERROR:
  1. &invoke-error:
  program: 
"/gnu/store/210yfax18r2g2inxrml9435ikhfcca6m-patch-2.7.6/bin/patch"
  arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input"
"/gnu/store/r0ipng37a0bvfbczhy791ayg4kx1wkld-mesa-opencl-all-targets.patch")
  exit-status: 1
  term-signal: #f
  stop-signal: #f

bug#63456: Acknowledgement (mesa build failure at guix package -u)

[Andy Tai]

the actual package failing to build is mesa-opencl, not mesa itself

bug#63456: [PATCH] gnu: mesa-opencl: Remove reference to patch

[Andy Tai]

Fixes .

* gnu/packages/patches/mesa-opencl-all-targets.patch: Removed

* gnu/local.mk: Remove reference to mesa-opencl-all-targets.patch

* gnu/packages/gl.scm (mesa-opencl)[source]::Remove patch application of
mesa-opencl-all-targets.patch
---
 gnu/local.mk  |  1 -
 gnu/packages/gl.scm   |  4 +--
 .../patches/mesa-opencl-all-targets.patch | 25 ---
 3 files changed, 1 insertion(+), 29 deletions(-)
 delete mode 100644 gnu/packages/patches/mesa-opencl-all-targets.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 73db48f720..73180be88a 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1561,7 +1561,6 @@ dist_patch_DATA = 
\
   %D%/packages/patches/memtest86+-build-reproducibly.patch \
   %D%/packages/patches/mercurial-hg-extension-path.patch   \
   %D%/packages/patches/mercurial-openssl-compat.patch  \
-  %D%/packages/patches/mesa-opencl-all-targets.patch   \
   %D%/packages/patches/mhash-keygen-test-segfault.patch\
   %D%/packages/patches/mia-fix-boost-headers.patch \
   %D%/packages/patches/mia-vtk9.patch  \
diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index 235b386dad..030c828e5b 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -530,9 +530,7 @@ (define-public mesa-opencl
   (package/inherit mesa
 (name "mesa-opencl")
 (source (origin
-  (inherit (package-source mesa))
-  (patches (cons (search-patch "mesa-opencl-all-targets.patch")
- (origin-patches (package-source mesa))
+  (inherit (package-source mesa
 (arguments
  (substitute-keyword-arguments (package-arguments mesa)
((#:configure-flags flags)
diff --git a/gnu/packages/patches/mesa-opencl-all-targets.patch 
b/gnu/packages/patches/mesa-opencl-all-targets.patch
deleted file mode 100644
index 99d4abcea4..00
--- a/gnu/packages/patches/mesa-opencl-all-targets.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-This patch restores LLVM targets needed for OpenCL, *reverting* this
-upstream commit:
-
-  From 80817b6e344258ac9b955f824ebf9019a0fc1610 Mon Sep 17 00:00:00 2001
-  From: Jesse Natalie 
-  Date: Wed, 18 Nov 2020 18:30:30 -0800
-  Subject: [PATCH] meson: Adjust Clover's required LLVM modules
-
-diff --git a/meson.build b/meson.build
-index 6d1607c35a3..f828eb80faa 100644
 b/meson.build
-+++ a/meson.build
-@@ -1479,10 +1479,9 @@
- endif
- if with_gallium_opencl
-   llvm_modules += [
--'linker', 'coverage', 'instrumentation', 'ipo', 'irreader',
--'lto', 'option', 'objcarcopts', 'profiledata'
-+'all-targets', 'linker', 'coverage', 'instrumentation', 'ipo', 'irreader',
-+'lto', 'option', 'objcarcopts', 'profiledata',
-   ]
--  llvm_optional_modules += ['frontendopenmp']
- endif
- if with_microsoft_clc
-   llvm_modules += ['target', 'linker', 'irreader', 'option', 'libdriver']

base-commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
-- 
2.39.2