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

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

bug#65665: [PATCH] Really get all the implicit inputs.

[Ulf Herrman]

Ulf Herrman  writes:

> Anyway, I've since forgotten exactly what happened and why (I didn't
> actually write the commit message until quite some time later), but I
> do know that this patch fixed it.
>
> I might try to rediscover what the problem was later, but thought it
> would be good to make you aware of this so as to hopefully consolidate
> world rebuilds.

I've since done some more checking to recall what the problem actually
was, and it indeed manifested as a combination of an icecat and mesa
problem: the wrap-program phase of icecat-minimal uses
`this-package-input' to get the mesa to point LD_LIBRARY_PATH to.
However, it then stuffs the resulting package inside a 
object, which we don't currently recurse through, so it ends up
compiling with one mesa and using another at runtime, which somehow
causes a segmentation fault.

Having looked at it again, I'm not sure that rebinding `this-package' is
the best solution - it's certainly not a general solution, since any old
package could be shoved into a  object (or really any
declarative file-like object) and thereby be hidden from
transformations.  My understanding is that packaging guidelines already
discourage directly substituting top-level package references,
preferring instead tools like `this-package-input' so as to work nicely
with transformations.  If those guidelines are adhered to, the
aforementioned patch should fix issues of this nature.  I'm not sure
what the best way of handling objects like  and such is,
but as long as package references go through `this-package', it should
only matter for implicit inputs, and I don't think any of them use
declarative file-like objects other than .

After thinking about it some more, I think it would be good if we had a
way of testing to make sure that every package is "transformable": that
is, if you apply a deep transformation to it, and lower the result to a
derivation, at no point within the dynamic extent of that lowering is a
derivation from an untransformed package introduced.  This would allow
for testing for transformability en masse, and could be added to 'guix
lint'.

- Ulf


signature.asc
Description: PGP signature

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#66304: exim vulnearable to CVE-2023-42115 et al

[John Kehayias via Bug reports for GNU Guix]

Hello,

On Thu, Oct 05, 2023 at 05:25 PM, Wilko Meyer wrote:

> * gnu/packages/mail.scm (exim): Update to 4.96.1.
> ---
>  gnu/packages/mail.scm | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
> index 72d971eb77..e6923627f4 100644
> --- a/gnu/packages/mail.scm
> +++ b/gnu/packages/mail.scm
> @@ -52,6 +52,7 @@
>  ;;; Copyright © 2022 jgart 
>  ;;; Copyright © 2022 ( 
>  ;;; Copyright © 2023 Timo Wilken 
> +;;; Copyright © 2023 Wilko Meyer 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -1895,7 +1896,7 @@ (define-public msmtp
>  (define-public exim
>(package
>  (name "exim")
> -(version "4.96")
> +(version "4.96.1")
>  (source
>   (origin
> (method url-fetch)
> @@ -1909,7 +1910,7 @@ (define-public exim
>  (string-append "https://ftp.exim.org/pub/exim/exim4/old/;
> file-name
> (sha256
> -(base32 "18ziihkpa23lybm7m2l9wp2farxw0bd5ng7xm9ylgcrfgf95d6i9"
> +(base32 "0g83cxkq3znh5b3r2a3990qxysw7d2l71jwcxaxzvq8pqdahgb4k"
>  (build-system gnu-build-system)
>  (arguments
>   (list #:phases
>
> base-commit: ad5e4fe54a66c725dc03dedebf8e5c65723ccb74
> prerequisite-patch-id: 5bde835de1e0f7e9cd752986da0585463713d745
> prerequisite-patch-id: cda50d13de497f5c74c87b2def4ae6a7d5807305
> prerequisite-patch-id: 7024afc52961b5947429f925c55265f29607c801
> prerequisite-patch-id: 10a4f92340880065a5210c983cc878c98c075855
> prerequisite-patch-id: e6610085f98fb881bada0bb27b59def23c3d7cc3

Thanks for the patch and quickly noticing the security issues!

Pushed as add2a22ad7bcca2521432e3f486460138401d5a5 with some added
detail to the commit message. I tested that exim and a dependent builds.

John

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

[Vivien Kraus via Bug reports for GNU Guix]

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?

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")
+   (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
-- 
2.41.0

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#66339: [PATCH gnome-team v3] gnu: dbus-service: make the session available under /run/dbus

[Vivien Kraus via Bug reports for GNU Guix]

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.

Best regards,

Vivien

 gnu/services/dbus.scm | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
index 5a0c634393..206a7bb491 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,24 @@ (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
+   (readlink "/run/dbus")))
+  (unless (equal? existing-name "/var/run/dbus")
+(error "the symlink /run/dbus exists and does not point to 
/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 +227,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
-- 
2.41.0

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#64981: GTK4 applications broken (missing libGLESv2)

[John Kehayias via Bug reports for GNU Guix]

Hi everyone,

Not sure if people saw this patch, has anyone tested if it fixes the
problem for them? I can include it in an upcoming mesa-updates branch
with other related updates/rebuilds.



Hope I got everyone from the original bug thread (seems many replies
didn't go directly to everyone) and cc'ed the patch number as well.

Thanks!
John

On Sat, Aug 19, 2023 at 10:59 AM, iyzs...@envs.net wrote:

> From: 宋文武 
>
> Fixes .
>
> * gnu/packages/gl.scm (libepoxy)[arguments]<#:phases>:
> Hardcode paths to libGLESv1_CM.so.1 and libGLESv2.so.2.
> ---
>  gnu/packages/gl.scm | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
> index b53b42a9ba..f662f0f7da 100644
> --- a/gnu/packages/gl.scm
> +++ b/gnu/packages/gl.scm
> @@ -742,10 +742,14 @@ (define-public libepoxy
>#~(modify-phases %standard-phases
>(add-before 'configure 'patch-paths
>  (lambda* (#:key inputs #:allow-other-keys)
> -  (let ((mesa (dirname (search-input-file inputs 
> "lib/libGL.so"
> +  (let ((mesa-lib
> + (lambda (file)
> +   (search-input-file inputs (string-append "lib/" 
> file)
>  (substitute* (find-files "." "\\.[ch]$")
> -  (("libGL.so.1") (string-append mesa "/libGL.so.1"))
> -  (("libEGL.so.1") (string-append mesa 
> "/libEGL.so.1")
> +  (("libGL.so.1") (mesa-lib "libGL.so.1"))
> +  (("libEGL.so.1") (mesa-lib "libEGL.so.1"))
> +  (("libGLESv1_CM.so.1") (mesa-lib "libGLESv1_CM.so.1"))
> +  (("libGLESv2.so.2") (mesa-lib "libGLESv2.so.2")
>  (build-system meson-build-system)
>  (native-inputs
>   (list pkg-config python))
>
> base-commit: 597af70fd24eb85a85fa8c45008c9cfa241f4d0b

bug#59364: gnome clocks does not start due to missing libGLES.so

[John Kehayias via Bug reports for GNU Guix]

Hi all,

On Wed, Nov 30, 2022 at 09:47 PM, Simon Streit wrote:

> Csepp  writes:
>> It does work with LIBGL_ALWAYS_SOFTWARE=1, but it would be pretty messed
>> up if that had to be enabled globally.
>
> Thanks for that tip!
>
> I fired up a recent Fedora live image to see that these applications do
> work in wayland on this old machine.  Which they do.
>
> Gnome in Ferdora is already at 43.

Is this the same issue as in ? With
potential fix ? I'm looking to
include this on the next mesa-updates round coming up soon.

Thanks!
John

bug#66319: Incorrect code snippet in manual

[John Kehayias via Bug reports for GNU Guix]

Hi Gabriel,

On Mon, Oct 02, 2023 at 06:38 PM, Gabriel Hondet wrote:

> Hello,
>
> The code snippets of the page 'Sending a patch series' look incorrect to
> me: the snippets mention the email address
> "guix-patc...@debbugs.gnu.org" but the text mentions
> "guix-patc...@gnu.org".
>

It is possible that one is an alias for the other (I'm not sure), but as
far as I know I always use the guix-patc...@gnu.org address to start a
patch submission. After the initial email, as noted in the manual, you
get a bug number @debbugs.gnu.org to use.

> For instance,
>> We can now send just the cover letter to the guix-patc...@gnu.org
>> address, which will create an issue that we can send the rest of the
>> patches to.
>>
>> > $ git send-email outgoing/-cover-letter.patch -a \
>> >   --to=guix-patc...@debbugs.gnu.org \
>> >   $(etc/teams.scm cc-members ...)
>> > $ rm outgoing/-cover-letter.patch # we don't want to resend it!
>
> The documentation I'm looking at is the one accessible at
> https://guix.gnu.org/manual/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches
> on the Monday, 2nd of October at 6pm (CEST) (a.k.a. 2023-10-02T18+02:00
> if you prefer ISO dates).
>

Ah, so this is the "1.4.0" manual rather than the current one:
.
This is a long standing confusion that needs to be sorted out, but in
short I would say the 1.4.0 manual is just to match the 1.4.0 installer,
but once installed and updated you should always use the manual that
matches your guix version. You can use "info guix" for instance, or the
web "devel" manual for the latest version.

So, yes, this is a potential error in the 1.4.0 manual but is corrected
in the current version. I don't think we can easily correct the old
version (it is already tagged and released) but we do have to clarify
the manual online for what version is what. This has been reported
before and there are some proposals, not sure why it hasn't been done
yet. Sorry about that!

> Cheers,
> Gabriel

Hope that is helpful! I'm going to close this in light of the above, but
feel free (or someone else) to reopen if needed.

Thanks for the close reading, doc errors and suggestions always welcome!

John

bug#66227: 'emacs-next' is almost unusable

[Ricardo Wurmus]

> 'emacs-next' doesn't work.  Because native-compilation doesn't work and
> it breaks everything else.

What exactly doesn’t work?

It would be better to actually fix whatever problem there might be than
just disabling native compilation.

-- 
Ricardo

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

[Simon Tournier]

Hi,

On Wed, 04 Oct 2023 at 23:41, Maxim Cournoyer  wrote:

>> I think we should add coreutils-minimal and sed (or gash-utils?) to the
>> ‘git-submodule’ wrapper that already exists.
>
> That should work for the use case at hand, but we should scan the source
> for occurrences of the tools to see if other git commands need to be
> wrapped as well.  This doesn't also cover 'uname' from my report, which
> should be looked into as well (when is it needed? is it a fatal error if
> it's missing? etc.)

Well, ’git-submodule’ is just a shell script.  It depends on:

  + basename
  + sed
  + git-sh-setup which depends on:
 + basename
 + sed
 + uname

And all these other subcommands match ’git-sh-setup’:

Binary:

 + bin/git
 + bin/scalar
 + libexec/git-core/git
 + libexec/git-core/scalar

Scripts:

 + libexec/git-core/git-filter-branch
 + libexec/git-core/git-merge-octopus
 + libexec/git-core/git-merge-one-file
 + libexec/git-core/git-merge-resolve
 + libexec/git-core/git-mergetool
 + libexec/git-core/git-quiltimport
 + libexec/git-core/git-submodule
 + libexec/git-core/git-web--browse
 + libexec/git-core/git-web--browse

For instance, libexec/git-core/git-mergetools/emerge or
libexec/git-core/git-mergetools/tortoisemerge depends on ’basename’.

This ’git-sh-setup’ is dragged into the picture by the file
’command-list.h’ which basically provides some help.  See below.

Last, I think ’git-sh-setup’ fails if ’uname’ is missing.


Cheers,
simon

--8<---cut here---start->8---
# From Git checkout

$ cat git-submodule | grep -n -E '(basename|sed|uname)'
7:dashless=$(basename "$0" | sed -e 's/-/ /')
569:# parsed here as well, for backward compatibility.
613:"cmd_$(echo $command | sed -e s/-/_/g)" "$@"

$ cat git-sh-setup | grep -n -E '(basename|sed|uname)'
77: dashless=$(basename -- "$0" | sed -e 's/-/ /')
181:die "$(eval_gettext "fatal: \$program_name cannot be used 
without a working tree.")"
188:die "$(eval_gettext "fatal: \$program_name cannot be used 
without a working tree.")"
230:# Generate a sed script to parse identities from a commit.
264:# Create a pick-script as above and feed it to sed. Stdout is suitable for
267:LANG=C LC_ALL=C sed -ne "$(pick_ident_script "$@")"
292:case $(uname -s) in

$ find $(guix build git-minimal --no-grafts) -type f -exec grep -nH 
git-sh-setup {} \; | sort
grep: /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/git: 
binary file matches
grep: 
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/scalar: 
binary file matches
grep: 
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git:
 binary file matches
grep: 
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/scalar:
 binary file matches
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-filter-branch:109:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-merge-octopus:8:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-merge-one-file:26:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-merge-resolve:8:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-mergetool:17:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-quiltimport:14:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-submodule:22:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-web--browse:22:#
 the vanilla git-sh-setup should not be used.
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-web--browse:24:.
 git-sh-setup

$ find . -type f -name "*.[ch]" -exec grep -nH git-sh-setup {} \;
./command-list.h:171:   { "git-sh-setup", N_("Common Git shell script setup 
code"), 0 | CAT_purehelpers },

$ find . -type f -name "*.o" -exec grep -nH git-sh-setup {} \;
grep: ./help.o: binary file matches

$ grep git-sh-setup git
grep: git: binary file matches

$ grep -B 5 -A 10 -n uname $(guix build git-minimal 
--no-grafts)/libexec/git-core/git-sh-setup
287-expr $sz0 \< $sz1 \* 2 >/dev/null || : >"$1"
288-}
289-
290-
291-# Platform specific tweaks to work around some commands
292:case $(uname -s) in
293-*MINGW*)
294-# Windows has its own (incompatible) sort and find
295-sort () {
296-/usr/bin/sort "$@"
297-}
298-find () {
299-/usr/bin/find "$@"
300-}
301-# git sees Windows-style pwd
302-pwd () {
--8<---cut here---end--->8---

bug#65665: [PATCH] Really get all the implicit inputs.

[Ulf Herrman]

I've also been using this patch, which rebinds `this-package' within
package variants to refer instead to the variant rather than the
original.  When I tried applying a deep transformation to icecat, it
failed to reach icecat-minimal or something like that.  Or maybe it was
some input of icecat - might have been my local version of mesa that had
breakage.  Anyway, I've since forgotten exactly what happened and why (I
didn't actually write the commit message until quite some time later),
but I do know that this patch fixed it.

I might try to rediscover what the problem was later, but thought it
would be good to make you aware of this so as to hopefully consolidate
world rebuilds.

- Ulf

From 06245c37fc0ee21144279682223dff01f3e6dbf4 Mon Sep 17 00:00:00 2001
Message-Id: <06245c37fc0ee21144279682223dff01f3e6dbf4.1696574074.git.strin...@tilde.club>
From: Ulf Herrman 
Date: Wed, 4 Oct 2023 03:17:25 -0500
Subject: [PATCH] guix: packages: rebind `this-package' for package variants.

Background: there is a `this-package' identifier that can be used within any
of the thunked fields of .  This is implemented by passing the
package in question as an argument to the "thunk" that is called to get the
field value.  `this-package' is used to implement macros like
`this-package-input'.  Consequently, there is a subtle difference between a
package that inherits another package's thunked field and one that wraps it:
in the former, the `this-package' of the thunked field will refer to the
inheriting package, while in the latter case it will refer to the original
package.

Use of `this-package' tends to cause lots of subtle and hard-to-debug breakage
when package transformations are used.  In `package-mapping', it makes more
sense to have `this-package' refer to the transformed package (that is, the
package after being transformed by the user-provided procedure and having all
of its applicable inputs transformed, recursively), since otherwise
untransformed inputs may be reintroduced via `this-package'.

There's still one place where `this-package' can cause problems, though, and
that's in the user-specified transformation procedure itself.  Whether it's
appropriate to have the thunks of the original refer to the original package
or the transformed package is only really known by the author of the
transformation.  We therefore expose procedures for invoking the field thunks
with arbitrary packages.

In my experience, this has led to far more consistent and predictable
package-transforming.

If we really need the ability to refer to the lexically enclosing package
instead of "whichever package ends up using this field definition" - which
seems to be unnecessary at present, since the overwhelming majority of uses of
'this-package' are in the context of 'this-package-input', etc - we could
introduce a 'this-literal-package' identifier.  Or we could rename all current
uses of 'this-package' to use 'this-package-variant' or something like that,
though that sounds like more work.

* guix/packages.scm (package-inputs-with-package,
  package-native-inputs-with-package, package-propagated-inputs-with-package,
  package-arguments-with-package):
  new procedures.
  (package-mapping): use them.
---
 guix/packages.scm | 61 ---
 1 file changed, 47 insertions(+), 14 deletions(-)

diff --git a/guix/packages.scm b/guix/packages.scm
index 1334def142..288867b911 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -138,6 +138,11 @@ (define-module (guix packages)
 package-transitive-propagated-inputs
 package-transitive-native-search-paths
 package-transitive-supported-systems
+package-inputs-with-package
+package-native-inputs-with-package
+package-propagated-inputs-with-package
+package-arguments-with-package
+
 package-mapping
 package-input-rewriting
 package-input-rewriting/spec
@@ -1451,6 +1456,31 @@ (define (build-system-with-package-mapping bs rewrite-input rewrite-argument)
 (inherit bs)
 (lower lower*)))
 
+(define (package-inputs-with-package p0 p)
+  (match p0
+(($  _ _ _ _ args-proc
+   inputs-proc
+   propagated-inputs-proc
+   native-inputs-proc)
+ (inputs-proc p
+
+(define (package-native-inputs-with-package p0 p)
+  (match p0
+(($  _ _ _ _ _ _ _
+   native-inputs-proc)
+ (native-inputs-proc p
+
+(define (package-propagated-inputs-with-package p0 p)
+  (match p0
+(($  _ _ _ _ _ _
+   propagated-inputs-proc)
+ (propagated-inputs-proc p
+
+(define (package-arguments-with-package p0 p)
+  (match p0
+(($  _ _ _ _ arguments-proc)
+ (arguments-proc p
+
 (define* (package-mapping proc #:optional (cut? (const #f))
   #:key deep?)
   "Return a procedure that, given a package, applies PROC to all the packages
@@