Gnome dans core-updates

Gnome dans core-updates

[Andreas Enge]

Hello,

today I have compiled a maximum of inputs for gnome on berlin. Here is
what is missing:
The following derivations would be built:
  /gnu/store/1f71al4jx8pn7qnpp94642pvf6m4la5m-gnome-42.4.drv
  /gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-1.2.5.drv
  /gnu/store/pvbdfrkp0bq8n0hvnikjasccjly3vq3s-gnome-boxes-43.3.drv
  /gnu/store/0i008ksb4war4iglqcrhnypnnjiv3mgq-spice-gtk-0.42.drv
  /gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-2.8.1.drv
  /gnu/store/ry2kqxfgghknlykwjssz0xdakaiq83d5-qemu-minimal-7.2.0.drv
  /gnu/store/n6ssj7g7ha48kqb7x0vlksaxrd02q2f3-opensbi-qemu-1.1.drv
  /gnu/store/a5bk00q2m7k41fmafyqx7ndhgxn8p92p-opensbi-generic-1.1.drv
  /gnu/store/vn01aaqcd9wmxb8hc8c9wsav89mbjyxy-ipxe-qemu-1.21.1.drv
  /gnu/store/q838z0f92dbll0cr4xb4dgbzqyfdb51b-system-config-printer-1.5.16.drv
  /gnu/store/y3qcrzl8c8746z3g95jip95728xckzyv-gnome-initial-setup-42.2.drv

Substitutes for all other inputs should be available on berlin.

If someone knowledgeable with Gnome could have a look, that would be great!

Below a few more details.

Andreas


packagekit fails its installation phase (!) like so:
/gnu/store/xrn2zn2ky4jkigg2cal0g8sacpkfai9m-meson-0.63.2/bin/meson install --no-rebuild
ninja: build stopped: subcommand failed.
error: in phase 'install': uncaught exception:
%exception #<&invoke-error program: "ninja" arguments: ("install") exit-status: 1 term-signal: #f stop-signal: #f>
phase `install' failed after 0.3 seconds
command "ninja" "install" failed with status 1
builder for `/gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-1.2.5.drv' failed with exit code 1
build of /gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-1.2.5.drv failed
View build log at '/var/log/guix/drvs/4y/vabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-1.2.5.drv.gz'.


libcacard fails validate-runpath:
starting phase `validate-runpath'
validating RUNPATH of 1 binaries in "/gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacard-2.8.1/lib"...
/gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacard-2.8.1/lib/libcacard.so: error: depends on 'libnss3.so', which cannot be found in RUNPATH ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "/gnu/store/mw4l4bap7xw3s4v9j4v395qp2n4gz3x4-glib-2.72.3/lib" "/gnu/store/jxkn98nnk2pv3fy7cx2baaynkr4c63wp-nspr-4.35/lib" "/gnu/store/x22qi9rkzdb8pafcv78wb5nayph9m1d9-pcsc-lite-1.9.8/lib")
error: in phase 'validate-runpath': uncaught exception:
misc-error #f "RUNPATH validation failed" () #f
phase `validate-runpath' failed after 0.0 seconds
Backtrace:
           8 (primitive-load "/gnu/store/x2685x6mv5lcxf2l7idg1y5w7wb…")
In guix/build/gnu-build-system.scm:
    908:2  7 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
    634:9  5 (for-each #<procedure 7ffff4efc0c0 at guix/build/gnu-b…> …)
In ice-9/boot-9.scm:
  1752:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   929:23  3 (_)
   570:10  2 (validate-runpath #:validate-runpath? _ # _ #:outputs _)
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:
RUNPATH validation failed
builder for `/gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-2.8.1.drv' failed with exit code 1
build of /gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-2.8.1.drv failed
View build log at '/var/log/guix/drvs/sv/800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-2.8.1.drv.gz'.
We have
    (propagated-inputs
     (list ...
           nss
and
    (native-inputs
     (list ...
           `(,nss "bin")
It looks like we need some of nss (the "normal" output, not "bin") as a
standard input. I will give it a try.


opensbi-generic fails in the build phase:
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("-j" "4" "PLATFORM=generic" "CROSS_COMPILE=riscv64-linux-gnu-" "FW_PAYLOAD=n" "V=1") exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 3.8 seconds
command "make" "-j" "4" "PLATFORM=generic" "CROSS_COMPILE=riscv64-linux-gnu-" "FW_PAYLOAD=n" "V=1" failed with status 2
builder for `/gnu/store/a5bk00q2m7k41fmafyqx7ndhgxn8p92p-opensbi-generic-1.1.drv' failed with exit code 1
build of /gnu/store/a5bk00q2m7k41fmafyqx7ndhgxn8p92p-opensbi-generic-1.1.drv failed
View build log at '/var/log/guix/drvs/a5/bk00q2m7k41fmafyqx7ndhgxn8p92p-opensbi-generic-1.1.drv.gz'.
In the build log, there is this:
/tmp/guix-build-opensbi-generic-1.1.drv-0/source/lib/sbi/sbi_tlb.c:190: Error: unrecognized opcode `fence.i'
make: *** [Makefile:442: /tmp/guix-build-opensbi-generic-1.1.drv-0/source/build/lib/sbi/sbi_tlb.o] Error 1
That looks serious.


ipxe-qemu also fails its build phase:
In file included from tests/bigint_test.c:38:
tests/bigint_test.c: In function ‘bigint_test_exec’:
tests/bigint_test.c:232:14: error: ‘result_raw’ may be used uninitialized [-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
View build log at '/var/log/guix/drvs/vn/01aaqcd9wmxb8hc8c9wsav89mbjyxy-ipxe-qemu-1.21.1.drv.gz'.
Well, compiling everything with "-Werror" is okay when the authors want to
test their code, but maybe overkill in a release?


The others fail because they have one of the above as inputs.

Re: Gnome dans core-updates

[Andreas Enge]

Am Fri, Mar 17, 2023 at 08:40:00PM +0100 schrieb Andreas Enge:
> libcacard fails validate-runpath:
> It looks like we need some of nss (the "normal" output, not "bin") as a

This did not help, nss appears in no runpath; this is what is printed:
starting phase `shrink-runpath'
/gnu/store/clqhrdvg1jpf053dq281f86139v5afxz-libcacard-2.8.1/lib/libcacard.so: stripping RUNPATH to ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "/gnu/store/mw4l4bap7xw3s4v9j4v395qp2n4gz3x4-glib-2.72.3/lib" "/gnu/store/jxkn98nnk2pv3fy7cx2baaynkr4c63wp-nspr-4.35/lib" "/gnu/store/x22qi9rkzdb8pafcv78wb5nayph9m1d9-pcsc-lite-1.9.8/lib") (removed ("/gnu/store/clqhrdvg1jpf053dq281f86139v5afxz-libcacard-2.8.1/lib" "/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib" "/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.."))
phase `shrink-runpath' succeeded after 0.0 seconds
starting phase `validate-runpath'
validating RUNPATH of 1 binaries in "/gnu/store/clqhrdvg1jpf053dq281f86139v5afxz-libcacard-2.8.1/lib"...
/gnu/store/clqhrdvg1jpf053dq281f86139v5afxz-libcacard-2.8.1/lib/libcacard.so: error: depends on 'libnss3.so', which cannot be found in RUNPATH ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "/gnu/store/mw4l4bap7xw3s4v9j4v395qp2n4gz3x4-glib-2.72.3/lib" "/gnu/store/jxkn98nnk2pv3fy7cx2baaynkr4c63wp-nspr-4.35/lib" "/gnu/store/x22qi9rkzdb8pafcv78wb5nayph9m1d9-pcsc-lite-1.9.8/lib")

Some special behaviour of meson-build-system as opposed to libtool?
Normally if something depends on nss and we add nss as an input, it should
be added automatically to the runpath, no?

Andreas

Re: Gnome dans core-updates

[Liliana Marie Prikler]

Am Freitag, dem 17.03.2023 um 20:40 +0100 schrieb Andreas Enge:
> libcacard fails validate-runpath:
> starting phase `validate-runpath'
> validating RUNPATH of 1 binaries in
> "/gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacard-2.8.1/lib"...
> /gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacard-
> 2.8.1/lib/libcacard.so: error: depends on 'libnss3.so', which cannot
> be found in RUNPATH ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-
> glibc-2.35/lib" "/gnu/store/mw4l4bap7xw3s4v9j4v395qp2n4gz3x4-glib-
> 2.72.3/lib" "/gnu/store/jxkn98nnk2pv3fy7cx2baaynkr4c63wp-nspr-
> 4.35/lib" "/gnu/store/x22qi9rkzdb8pafcv78wb5nayph9m1d9-pcsc-lite-
> 1.9.8/lib")
> error: in phase 'validate-runpath': uncaught exception:
> misc-error #f "RUNPATH validation failed" () #f
> phase `validate-runpath' failed after 0.0 seconds
> Backtrace:
>            8 (primitive-load
> "/gnu/store/x2685x6mv5lcxf2l7idg1y5w7wb…")
> In guix/build/gnu-build-system.scm:
>     908:2  7 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases .
> #)
> In ice-9/boot-9.scm:
>   1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In srfi/srfi-1.scm:
>     634:9  5 (for-each #<procedure 7ffff4efc0c0 at guix/build/gnu-b…>
> …)
> In ice-9/boot-9.scm:
>   1752:10  4 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/build/gnu-build-system.scm:
>    929:23  3 (_)
>    570:10  2 (validate-runpath #:validate-runpath? _ # _ #:outputs _)
> 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:
> RUNPATH validation failed
> builder for `/gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-
> 2.8.1.drv' failed with exit code 1
> build of /gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-
> 2.8.1.drv failed
> View build log at
> '/var/log/guix/drvs/sv/800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-
> 2.8.1.drv.gz'.
> We have
>     (propagated-inputs
>      (list ...
>            nss
> and
>     (native-inputs
>      (list ...
>            `(,nss "bin")
> It looks like we need some of nss (the "normal" output, not "bin") as
> a standard input. I will give it a try.

> 
That doesn't change a thing when nss is already a propagated input:
Propagated inputs are also "standard" ones as far as linking is
concerned.  Also, the package definitions appear the same on master, so
there is possibly something else going on (but what?)

On a rather unrelated note, the uri
https://gitlab.freedesktop.org/spice/libcacard/uploads/13b249e695a0d9aa7cb501b1a85ebab1/libcacard-2.8.1.tar.xz
looks rather sus.  Should we perhaps replace that with a git-reference?

Re: Gnome dans core-updates

[Liliana Marie Prikler]

Am Freitag, dem 17.03.2023 um 21:46 +0100 schrieb Liliana Marie
Prikler:
> Also, the package definitions appear the same on master, so
> there is possibly something else going on (but what?)
Now that's quite embarrassing, but git worktree put my core-updates to
master...

Re: Gnome dans core-updates

[Liliana Marie Prikler]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

Am Freitag, dem 17.03.2023 um 20:40 +0100 schrieb Andreas Enge:
> packagekit fails its installation phase (!) like so:
> /gnu/store/xrn2zn2ky4jkigg2cal0g8sacpkfai9m-meson-0.63.2/bin/meson
> install --no-rebuild
> ninja: build stopped: subcommand failed.
> error: in phase 'install': uncaught exception:
> %exception #<&invoke-error program: "ninja" arguments: ("install")
> exit-status: 1 term-signal: #f stop-signal: #f>
> phase `install' failed after 0.3 seconds
> command "ninja" "install" failed with status 1
> builder for `/gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-
> 1.2.5.drv' failed with exit code 1
> build of /gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-
> 1.2.5.drv failed
> View build log at
> '/var/log/guix/drvs/4y/vabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-
> 1.2.5.drv.gz'.
This error is caused by trying to install
'/gnu/store/mxp199mvjb6dhyyg0pi4hn6c7m0xibvp-bash-completion-
2.11/share/bash-completion/completions/pkcon'.  Meson appears to have a
feature where it tries to use pkexec to gain elevated privileges. 
However, since that pkexec is actually the one pulled in for the build
system, that won't work here.

In any case, the attached patch fixes the more pressing issue of
getting the installation directory wrong.

Cheers

[-- Attachment #2: 0001-gnu-packagekit-Fix-installation-directory-for-bash-c.patch --]
[-- Type: text/x-patch, Size: 1667 bytes --]

From b7c1a259815e97beeb9f60b8991fde87c31abf64 Mon Sep 17 00:00:00 2001
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
Date: Fri, 17 Mar 2023 23:57:22 +0100
Subject: [PATCH] gnu: packagekit: Fix installation directory for bash
 completions.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Without this patch, packagekit would attempt to install bash completions
to another store directory, invoking pkexec in the process and raising
a cryptic error.

* gnu/packages/freedesktop.scm (packagekit)[#:phases]: Add
‘fix-bash-completion-dir’.
---
 gnu/packages/freedesktop.scm | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/freedesktop.scm b/gnu/packages/freedesktop.scm
index 9ba53cd044..9256dac0e0 100644
--- a/gnu/packages/freedesktop.scm
+++ b/gnu/packages/freedesktop.scm
@@ -1006,7 +1006,15 @@ (define-public packagekit
     (build-system meson-build-system)
     (arguments
      (list #:tests? #f
-           #:configure-flags #~'("-Dsystemd=false" "-Doffline_update=false")))
+           #:configure-flags #~'("-Dsystemd=false" "-Doffline_update=false")
+           #:phases
+           #~(modify-phases %standard-phases
+               (add-after 'unpack 'fix-bash-completion-dir
+                 (lambda _
+                   (substitute* "contrib/meson.build"
+                     (("bash_.*_dep\\.get_.*\\('completionsdir', .*\\)")
+                      "join_paths(get_option('prefix'), 'share',
+                                  'bash-completion', 'completions')")))))))
     (native-inputs
      (list bash-completion
            docbook-xsl
-- 
2.39.2

Re: Gnome dans core-updates

[Andreas Enge]

Am Fri, Mar 17, 2023 at 09:46:27PM +0100 schrieb Liliana Marie Prikler:
> On a rather unrelated note, the uri
> https://gitlab.freedesktop.org/spice/libcacard/uploads/13b249e695a0d9aa7cb501b1a85ebab1/libcacard-2.8.1.tar.xz
> looks rather sus.  Should we perhaps replace that with a git-reference?

There are also more reasonable looking URL such as
   https://gitlab.freedesktop.org/spice/libcacard/-/archive/v2.8.1/libcacard-v2.8.1.tar.bz2
But they may have the problem of unstable hashes sometimes encountered
with autogenerated tarballs.

I do not remember what is the state of the discussion with respect to
tarballs vs. git and am happy with any solution.

Andreas

Re: Gnome dans core-updates

[Andreas Enge]

Am Fri, Mar 17, 2023 at 08:40:00PM +0100 schrieb Andreas Enge:
> ipxe-qemu also fails its build phase:
> In file included from tests/bigint_test.c:38:
> tests/bigint_test.c: In function ‘bigint_test_exec’:
> tests/bigint_test.c:232:14: error: ‘result_raw’ may be used uninitialized [-Werror=maybe-uninitialized]
> cc1: all warnings being treated as errors
> View build log at '/var/log/guix/drvs/vn/01aaqcd9wmxb8hc8c9wsav89mbjyxy-ipxe-qemu-1.21.1.drv.gz'.
> Well, compiling everything with "-Werror" is okay when the authors want to
> test their code, but maybe overkill in a release?

This looks like
   https://github.com/ipxe/ipxe/issues/359
And has apparently been fixed following a different issue related to
ARM assembly (?!):
   https://github.com/ipxe/ipxe/pull/373

The project has had its latest release in December 2020, with more
than 400 commits since then. Difficult to assert that the release is
actually functional! Does it have to be a transitive input of gnome?
And a help-guix question: How do I retrace the part of the dependency
graph that links ipxe-qemu to gnome?

Andreas

Re: Gnome dans core-updates

[Andreas Enge]

Am Sat, Mar 18, 2023 at 11:07:08AM +0100 schrieb Andreas Enge:
> And a help-guix question: How do I retrace the part of the dependency
> graph that links ipxe-qemu to gnome?

I am still interested in the answer to this question, but here the line
is short:
ipxe-qemu -> qemu-minimal -> gnome-boxes -> gnome.

I wondered if we could not drop the dependency as somewhat alien to a
standard desktop, but it is in a list of packages labelled
"GNOME-Core-Utilities". It sounds like a stretch to have something in the
core of a desktop that "requires the @code{libvirt} and @code{virtlog}
daemons to run", but maybe there is a standard to what shall be part of
a minimal Gnome?

Andreas

Re: Gnome dans core-updates

[Andreas Enge]

Am Sat, Mar 18, 2023 at 12:00:49AM +0100 schrieb Liliana Marie Prikler:
> This error is caused by trying to install
> '/gnu/store/mxp199mvjb6dhyyg0pi4hn6c7m0xibvp-bash-completion-
> 2.11/share/bash-completion/completions/pkcon'.  Meson appears to have a
> feature where it tries to use pkexec to gain elevated privileges. 
> However, since that pkexec is actually the one pulled in for the build
> system, that won't work here.
> 
> In any case, the attached patch fixes the more pressing issue of
> getting the installation directory wrong.

Thanks for sorting this out!

Since it is a static change in a file ("lambda _"), should it not rather
go into a snippet or a patch? And since it is specific to Guix (is it?),
I think a snippet would be more appropriate.

In any case, I confirm that the package now builds.

Andreas

Re: Gnome dans core-updates

[Liliana Marie Prikler]

Am Samstag, dem 18.03.2023 um 11:36 +0100 schrieb Andreas Enge:
> Am Sat, Mar 18, 2023 at 12:00:49AM +0100 schrieb Liliana Marie
> Prikler:
> > This error is caused by trying to install
> > '/gnu/store/mxp199mvjb6dhyyg0pi4hn6c7m0xibvp-bash-completion-
> > 2.11/share/bash-completion/completions/pkcon'.  Meson appears to
> > have a
> > feature where it tries to use pkexec to gain elevated privileges. 
> > However, since that pkexec is actually the one pulled in for the
> > build
> > system, that won't work here.
> > 
> > In any case, the attached patch fixes the more pressing issue of
> > getting the installation directory wrong.
> 
> Thanks for sorting this out!
> 
> Since it is a static change in a file ("lambda _"), should it not
> rather go into a snippet or a patch? And since it is specific to Guix
> (is it?), I think a snippet would be more appropriate.
Feel free to promote it into a snippet.  I didn't, because it only
affects the build files rather than the package being built.

Cheers

Re: Gnome dans core-updates

[Andreas Enge]

Am Sat, Mar 18, 2023 at 12:15:34PM +0100 schrieb Liliana Marie Prikler:
> Feel free to promote it into a snippet.  I didn't, because it only
> affects the build files rather than the package being built.

Okay, I did and pushed, many thanks again!

Andreas

Re: Gnome dans core-updates

[Josselin Poiret]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> This looks like
>    https://github.com/ipxe/ipxe/issues/359
> And has apparently been fixed following a different issue related to
> ARM assembly (?!):
>    https://github.com/ipxe/ipxe/pull/373
>
> The project has had its latest release in December 2020, with more
> than 400 commits since then. Difficult to assert that the release is
> actually functional! Does it have to be a transitive input of gnome?
> And a help-guix question: How do I retrace the part of the dependency
> graph that links ipxe-qemu to gnome?

The project does seem functional, they just seem to not care about
making new releases, since they direct users to official builds of HEAD
[1].  Maybe we could just point there as well?

[1] https://github.com/ipxe/ipxe/discussions/679

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

Re: Gnome dans core-updates

[Andreas Enge]

Am Sun, Mar 19, 2023 at 10:20:27AM +0100 schrieb Josselin Poiret:
> The project does seem functional, they just seem to not care about
> making new releases, since they direct users to official builds of HEAD
> [1].  Maybe we could just point there as well?
> [1] https://github.com/ipxe/ipxe/discussions/679

Well, I am loath to this attitude "just take the latest master", and it is
not what we normally do. A software writer cannot expect distros (nor end
users, as they seem to prefer) to follow each and every of their commits.
And it does not reflect well on their quality assurance processes if they
are unable to single out a commit from time to time that has undergone more
thorough scrutiny.

That said, if just backporting one fix does not solve the problem, we may
have to go this route...

Andreas

Re: Gnome dans core-updates

[Josselin Poiret]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> Am Sun, Mar 19, 2023 at 10:20:27AM +0100 schrieb Josselin Poiret:
>> The project does seem functional, they just seem to not care about
>> making new releases, since they direct users to official builds of HEAD
>> [1].  Maybe we could just point there as well?
>> [1] https://github.com/ipxe/ipxe/discussions/679
>
> Well, I am loath to this attitude "just take the latest master", and it is
> not what we normally do. A software writer cannot expect distros (nor end
> users, as they seem to prefer) to follow each and every of their commits.
> And it does not reflect well on their quality assurance processes if they
> are unable to single out a commit from time to time that has undergone more
> thorough scrutiny.
>
> That said, if just backporting one fix does not solve the problem, we may
> have to go this route...

I agree with you, but given that upstream has already closed a
discussion on this topic with a clear stance, I don't really want to
re-open anything.  We could go with that solution for now?

-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

Re: Gnome dans core-updates

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

Am Sun, Mar 19, 2023 at 03:14:59PM +0100 schrieb Josselin Poiret:
> I agree with you, but given that upstream has already closed a
> discussion on this topic with a clear stance, I don't really want to
> re-open anything.  We could go with that solution for now?

If it is indeed a solution... Here is how far I got, patch attached.
I updated the source code to the latest commit. The patch to
src/util/geniso does not apply any more (in fact, the complete file
has disappeared). The build fails, relatedly:
  [GENFSIMG] bin/ipxe.iso
util/genfsimg: could not find isolinux.bin
make[2]: *** [arch/x86/Makefile.pcbios:61: bin/ipxe.iso] Error 1
...
error: in phase 'build': uncaught exception:
...
build of /gnu/store/z9fs06nl38g2q1ss9wf1vbxp60011izj-ipxe-1.21.1-0.09e8a15.drv failed
View build log at '/var/log/guix/drvs/z9/fs06nl38g2q1ss9wf1vbxp60011izj-ipxe-1.21.1-0.09e8a15.drv.gz'.

See also here:
   https://github.com/ipxe/ipxe/issues/775
isolinux.bin is supposed to be installed by syslinux, but it is not.

If you could have a more informed look, that would be great.

Andreas


[-- Attachment #2: 0001-gnu-ipex-Update-to-latest-master-commit.patch --]
[-- Type: text/plain, Size: 5151 bytes --]

From 6b4ed4a924994ee5ea12a38d91288238e34e33a2 Mon Sep 17 00:00:00 2001
From: Andreas Enge <andreas@enge.fr>
Date: Mon, 20 Mar 2023 17:42:15 +0100
Subject: [PATCH] gnu: ipex: Update to latest master commit.

* gnu/packages/bootloaders.scm (ipex): Update to latest master commit.
Remove patch.
* gnu/packages/patches/ipxe-reproducible-geniso.patch: Remove file.
* gnu/packages/bootloaders.scm (dist_patch_DATA): Unregister patch.
---
 gnu/local.mk                                  |  1 -
 gnu/packages/bootloaders.scm                  | 13 ++--
 .../patches/ipxe-reproducible-geniso.patch    | 77 -------------------
 3 files changed, 8 insertions(+), 83 deletions(-)
 delete mode 100644 gnu/packages/patches/ipxe-reproducible-geniso.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 43b7e4ceb3..4f6e100c55 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1338,7 +1338,6 @@ dist_patch_DATA =						\
   %D%/packages/patches/intel-xed-fix-nondeterminism.patch	\
   %D%/packages/patches/intltool-perl-compatibility.patch	\
   %D%/packages/patches/iputils-libcap-compat.patch		\
-  %D%/packages/patches/ipxe-reproducible-geniso.patch	        \
   %D%/packages/patches/irrlicht-use-system-libs.patch		\
   %D%/packages/patches/irrlicht-link-against-needed-libs.patch	\
   %D%/packages/patches/isl-0.11.1-aarch64-support.patch	\
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index b1276f90dd..85da7aed55 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -1706,20 +1706,23 @@ (define-public ipxe
   ;;
   ;; TODO: Bump this timestamp at each modifications of the package (not only
   ;; for updates) by running: date +%s.
-  (let ((timestamp "1671715380"))
+  (let ((timestamp "1671715380")
+        (commit "09e8a154084c57311463408e3f2e412c305a9638")
+        (revision "0"))
     (package
       (name "ipxe")
-      (version "1.21.1")
+      (version (string-append "1.21.1"
+                              "-" revision "."
+                              (string-take commit 7)))
       (source (origin
                 (method git-fetch)
                 (uri (git-reference
                       (url "https://github.com/ipxe/ipxe")
-                      (commit (string-append "v" version))))
+                      (commit commit)))
                 (file-name (git-file-name name version))
-                (patches (search-patches "ipxe-reproducible-geniso.patch"))
                 (sha256
                  (base32
-                  "1pkf1n1c0rdlzfls8fvjvi1sd9xjd9ijqlyz3wigr70ijcv6x8i9"))))
+                  "0578qnq69pyvm1j7ykcd763mly9phgnlsdyai1npsg455kf6q1m4"))))
       (build-system gnu-build-system)
       (arguments
        (list
diff --git a/gnu/packages/patches/ipxe-reproducible-geniso.patch b/gnu/packages/patches/ipxe-reproducible-geniso.patch
deleted file mode 100644
index ff6aa1da94..0000000000
--- a/gnu/packages/patches/ipxe-reproducible-geniso.patch
+++ /dev/null
@@ -1,77 +0,0 @@
-From 052d24d8217c51c572c2f6cbb4a687be2e8ba52d Mon Sep 17 00:00:00 2001
-From: Brice Waegeneire <brice@waegenei.re>
-Date: Fri, 5 Jun 2020 14:38:43 +0200
-Subject: [PATCH] [geniso] Make it reproducible
-
-Some timestamps get embedded in the generated ISO, making it
-unreproducible so we overwrite those timestamps to be at the UNIX epoch.
----
- src/util/geniso | 24 +++++++++++++++++++++---
- 1 file changed, 21 insertions(+), 3 deletions(-)
-
-diff --git a/src/util/geniso b/src/util/geniso
-index ff090d4a..e032ffb0 100755
---- a/src/util/geniso
-+++ b/src/util/geniso
-@@ -11,6 +11,13 @@ function help() {
- 	echo " -o FILE  save iso image to file"
- }
- 
-+function reset_timestamp() {
-+	for f in "$1"/*; do
-+		touch -t 197001010100 "$f"
-+	done
-+	touch -t 197001010100 "$1"
-+}
-+
- LEGACY=0
- FIRST=""
- 
-@@ -37,8 +44,9 @@ if [ -z "${OUT}" ]; then
- 	exit 1
- fi
- 
--# There should either be mkisofs or the compatible genisoimage program
--for command in genisoimage mkisofs; do
-+# There should either be mkisofs, xorriso or the compatible genisoimage
-+# program
-+for command in xorriso genisoimage mkisofs; do
- 	if ${command} --version >/dev/null 2>/dev/null; then
- 		mkisofs=(${command})
- 		break
-@@ -46,8 +54,10 @@ for command in genisoimage mkisofs; do
- done
- 
- if [ -z "${mkisofs}" ]; then
--	echo "${0}: mkisofs or genisoimage not found, please install or set PATH" >&2
-+	echo "${0}: mkisofs, xorriso or genisoimage not found, please install or set PATH" >&2
- 	exit 1
-+elif [ "$mkisofs" = "xorriso" ]; then
-+	 mkisofs+=(-as mkisofs)
- fi
- 
- dir=$(mktemp -d bin/iso.dir.XXXXXX)
-@@ -115,6 +125,8 @@ case "${LEGACY}" in
- 			exit 1
- 		fi
- 
-+		reset_timestamp "$dir"
-+
- 		# generate the iso image
- 		"${mkisofs[@]}" -b boot.img -output ${OUT} ${dir}
- 		;;
-@@ -127,6 +139,12 @@ case "${LEGACY}" in
- 			cp ${LDLINUX_C32} ${dir}
- 		fi
- 
-+		reset_timestamp "$dir"
-+
-+		if [ "${mkisofs[0]}" = "xorriso" ]; then
-+			mkisofs+=(-isohybrid-mbr "$SYSLINUX_MBR_DISK_PATH")
-+		fi
-+
- 		# generate the iso image
- 		"${mkisofs[@]}" -b isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table -output ${OUT} ${dir}
- 
--- 
-2.26.2
-- 
2.39.2

Re: Gnome dans core-updates

[Andreas Enge]

Am Mon, Mar 20, 2023 at 06:00:37PM +0100 schrieb Andreas Enge:
> If it is indeed a solution... Here is how far I got, patch attached.

Actually it was updated by Efraim in master on March 9.

Time to merge master into core-updates, I would say.

Andreas

Re: Gnome dans core-updates

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On Mon, Mar 20, 2023 at 06:11:56PM +0100, Andreas Enge wrote:
> Am Mon, Mar 20, 2023 at 06:00:37PM +0100 schrieb Andreas Enge:
> > If it is indeed a solution... Here is how far I got, patch attached.
> 
> Actually it was updated by Efraim in master on March 9.

Indeed, it was needed for qemu-minimal to build on riscv64.

> Time to merge master into core-updates, I would say.

Often a good idea :)

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Gnome dans core-updates

[Andreas Enge]

Am Mon, Mar 20, 2023 at 07:17:41PM +0200 schrieb Efraim Flashner:
> > Time to merge master into core-updates, I would say.
> Often a good idea :)

Ah, it makes me super nervous. I now did for the first time ever...
There were a few problems with openjdk, where the automatic merge took
the wrong things from core-updates, instead of from master; hopefully
I worked it out correctly. At worst, we can always revert...

Andreas

Re: Gnome dans core-updates

[Josselin Poiret]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> Ah, it makes me super nervous. I now did for the first time ever...
> There were a few problems with openjdk, where the automatic merge took
> the wrong things from core-updates, instead of from master; hopefully
> I worked it out correctly. At worst, we can always revert...

Thanks for taking care of it!  I should've also told you I ended up
fixing a couple of things locally for qemu-minimal to build (since I was
working on the Hurd and disk images).  I also fixed u-boot-tools not
building on Python 3.10 (even though it's a swig bug that is fixed in
newer releases, but updating swig would cause a world rebuild).

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

Re: Gnome dans core-updates

[Andreas Enge]

Hello Josselin,

Am Mon, Mar 20, 2023 at 08:18:41PM +0100 schrieb Josselin Poiret:
> I ended up
> fixing a couple of things locally for qemu-minimal to build (since I was
> working on the Hurd and disk images).  I also fixed u-boot-tools not
> building on Python 3.10 (even though it's a swig bug that is fixed in
> newer releases, but updating swig would cause a world rebuild).

great, I see the commits in core-updates that fix a few of the build
failures I observed, thanks!

There is still libcacard with its runpath verification failure.

Andreas

Re: Gnome dans core-updates

[Andreas Enge]

Am Thu, Mar 30, 2023 at 11:08:50AM +0200 schrieb Andreas Enge:
> There is still libcacard with its runpath verification failure.

Fixed by Efraim, thanks a lot!

Andreas

Re: Gnome dans core-updates

[Andreas Enge]

Update on gnome in core-updates: We have it!
(At least we had it yesterday, the latest commits will lead to a few
rebuilds that are not yet done.)

Congratulations to all who made it work!

Andreas