bug#72239: libfaketime (still) broken on i686-linux

[Ludovic Courtès]

Hi!

Christopher Baines  skribis:

> When running without datefudge, the tests work and the cd in gtests.sh
> seems to fail:
>
> Running tests for gtests
> TIMESTAMP gtests BEGIN: Mon Jul 22 10:09:27 UTC 2024
> ./gtests.sh: line 25: cd: ./nss/tests: No such file or directory
> /tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/gtests
>
> But when running with datefudge, the cd seems to work, but the tests
> fail:
>
> Running tests for gtests
> TIMESTAMP gtests BEGIN: Tue Jan 23 00:00:01 UTC 2024
> /tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests

I added ‘set -x’ in ‘gtests.sh’.  With ‘datefudge’, it goes like this:

--8<---cut here---start->8---
log-Running tests for gtests
log-TIMESTAMP gtests BEGIN: Tue Jan 23 00:00:00 CET 2024
log-++ echo FO
log-FO
log-+++ dirname /tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/all.sh
log-++ cd /tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests
log-++ pwd
log-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests
log:++ SOURCE_DIR=/tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/../..
log-++ set +x
log-gtests: base_gtest certhigh_gtest certdb_gtest der_gtest pk11_gtest 
util_gtest freebl_gtest softoken_gtest sysinit_gtest smime_gtest mozpkix_gtest
log-gtests.sh: base_gtest ===
log-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/dist/Linux6.9_x86_gcc_glibc_PTH_DBG.OBJ/bin/certutil
 -N -d 
/tmp/guix-build-nss-3.99.drv-0/nss-3.99/tests_results/security/guix-hpc5.7/gtests/base_gtest
 --empty-password
log-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/dist/Linux6.9_x86_gcc_glibc_PTH_DBG.OBJ/bin/certutil
 -S -z ../tests_noise -d 
/tmp/guix-build-nss-3.99.drv-0/nss-3.99/tests_results/security/guix-hpc5.7/gtests/base_gtest
 -n dummy -s CN=dummy -t ,, -x -m 1 -w -2 -v 120 -k ec -q nistp256 -Z SHA256 -1 
-2
log-
log-
log-Generating key.  This may take a few moments...
--8<---cut here---end--->8---

*Without* ‘datefudge’:

--8<---cut here---start->8---
log.good-TIMESTAMP gtests BEGIN: Tue Jul 23 12:37:50 CEST 2024
log.good-++ echo FO
log.good-FO
log.good-+++ dirname ./nss/tests/all.sh
log.good-++ cd ./nss/tests
log.good-./gtests.sh: line 27: cd: ./nss/tests: No such file or directory
log.good-++ pwd
log.good-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/gtests
log.good:++ 
SOURCE_DIR=/tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/gtests/../..
log.good-++ set +x
log.good-gtests: base_gtest certhigh_gtest certdb_gtest der_gtest pk11_gtest 
util_gtest freebl_gtest softoken_gtest sysinit_gtest smime_gtest mozpkix_gtest
log.good-gtests.sh: base_gtest ===
log.good-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/dist/Linux6.9_x86_gcc_glibc_PTH_DBG.OBJ/bin/certutil
 -N -d 
/tmp/guix-build-nss-3.99.drv-0/nss-3.99/tests_results/security/guix-hpc5.6/gtests/base_gtest
 --empty-password
log.good-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/dist/Linux6.9_x86_gcc_glibc_PTH_DBG.OBJ/bin/certutil
 -S -z ../tests_noise -d 
/tmp/guix-build-nss-3.99.drv-0/nss-3.99/tests_results/security/guix-hpc5.6/gtests/base_gtest
 -n dummy -s CN=dummy -t ,, -x -m 1 -w -2 -v 120 -k ec -q nistp256 -Z SHA256 -1 
-2
log.good-
log.good-
log.good-Generating key.  This may take a few moments...
--8<---cut here---end--->8---

In the latter case, the scripts gets a relative file name, which makes
it fail to cd, which then makes it succeed by chance.

This script looks extremely fragile.

My suggestion would be to:

  (substitute* "nss/tests/gtests/gtests.sh"
(("SOURCE_DIR=.*")
 (string-append "SOURCE_DIR=" (getcwd) "/nss\n")))

WDYT?

(There’s a tension between getting a reasonably good understanding of
what’s happening and moving forward!)

Ludo’.

bug#72239: libfaketime (still) broken on i686-linux

[Christopher Baines]

Ludovic Courtès  writes:

> Hi!
>
> Christopher Baines  skribis:
>
>> When running without datefudge, the tests work and the cd in gtests.sh
>> seems to fail:
>>
>> Running tests for gtests
>> TIMESTAMP gtests BEGIN: Mon Jul 22 10:09:27 UTC 2024
>> ./gtests.sh: line 25: cd: ./nss/tests: No such file or directory
>> /tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/gtests
>>
>> But when running with datefudge, the cd seems to work, but the tests
>> fail:
>>
>> Running tests for gtests
>> TIMESTAMP gtests BEGIN: Tue Jan 23 00:00:01 UTC 2024
>> /tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests
>
> I added ‘set -x’ in ‘gtests.sh’.  With ‘datefudge’, it goes like this:
>
> --8<---cut here---start->8---
> log-Running tests for gtests
> log-TIMESTAMP gtests BEGIN: Tue Jan 23 00:00:00 CET 2024
> log-++ echo FO
> log-FO
> log-+++ dirname /tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/all.sh
> log-++ cd /tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests
> log-++ pwd
> log-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests
> log:++ SOURCE_DIR=/tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/../..
> log-++ set +x
> log-gtests: base_gtest certhigh_gtest certdb_gtest der_gtest pk11_gtest 
> util_gtest freebl_gtest softoken_gtest sysinit_gtest smime_gtest mozpkix_gtest
> log-gtests.sh: base_gtest ===
> log-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/dist/Linux6.9_x86_gcc_glibc_PTH_DBG.OBJ/bin/certutil
>  -N -d 
> /tmp/guix-build-nss-3.99.drv-0/nss-3.99/tests_results/security/guix-hpc5.7/gtests/base_gtest
>  --empty-password
> log-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/dist/Linux6.9_x86_gcc_glibc_PTH_DBG.OBJ/bin/certutil
>  -S -z ../tests_noise -d 
> /tmp/guix-build-nss-3.99.drv-0/nss-3.99/tests_results/security/guix-hpc5.7/gtests/base_gtest
>  -n dummy -s CN=dummy -t ,, -x -m 1 -w -2 -v 120 -k ec -q nistp256 -Z SHA256 
> -1 -2
> log-
> log-
> log-Generating key.  This may take a few moments...
> --8<---cut here---end--->8---
>
> *Without* ‘datefudge’:
>
> --8<---cut here---start->8---
> log.good-TIMESTAMP gtests BEGIN: Tue Jul 23 12:37:50 CEST 2024
> log.good-++ echo FO
> log.good-FO
> log.good-+++ dirname ./nss/tests/all.sh
> log.good-++ cd ./nss/tests
> log.good-./gtests.sh: line 27: cd: ./nss/tests: No such file or directory
> log.good-++ pwd
> log.good-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/gtests
> log.good:++ 
> SOURCE_DIR=/tmp/guix-build-nss-3.99.drv-0/nss-3.99/nss/tests/gtests/../..
> log.good-++ set +x
> log.good-gtests: base_gtest certhigh_gtest certdb_gtest der_gtest pk11_gtest 
> util_gtest freebl_gtest softoken_gtest sysinit_gtest smime_gtest mozpkix_gtest
> log.good-gtests.sh: base_gtest ===
> log.good-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/dist/Linux6.9_x86_gcc_glibc_PTH_DBG.OBJ/bin/certutil
>  -N -d 
> /tmp/guix-build-nss-3.99.drv-0/nss-3.99/tests_results/security/guix-hpc5.6/gtests/base_gtest
>  --empty-password
> log.good-/tmp/guix-build-nss-3.99.drv-0/nss-3.99/dist/Linux6.9_x86_gcc_glibc_PTH_DBG.OBJ/bin/certutil
>  -S -z ../tests_noise -d 
> /tmp/guix-build-nss-3.99.drv-0/nss-3.99/tests_results/security/guix-hpc5.6/gtests/base_gtest
>  -n dummy -s CN=dummy -t ,, -x -m 1 -w -2 -v 120 -k ec -q nistp256 -Z SHA256 
> -1 -2
> log.good-
> log.good-
> log.good-Generating key.  This may take a few moments...
> --8<---cut here---end--->8---
>
> In the latter case, the scripts gets a relative file name, which makes
> it fail to cd, which then makes it succeed by chance.
>
> This script looks extremely fragile.
>
> My suggestion would be to:
>
>   (substitute* "nss/tests/gtests/gtests.sh"
> (("SOURCE_DIR=.*")
>  (string-append "SOURCE_DIR=" (getcwd) "/nss\n")))
>
> WDYT?

That looks good to me.

In a related note, I was going to push the original patch yesterday, but
I got stuck rebasing core-updates. There's some substantial rust changes
on the branch which clash with master.


signature.asc
Description: PGP signature

bug#72257: Non-English manuals for 1.4.0 are unavailable

[Ludovic Courtès]

Hello,

Right now, non-English manuals for 1.4.0 are 404:

  https://guix.gnu.org/manual/de/html_node/
  https://guix.gnu.org/manual/es/html_node/
  https://guix.gnu.org/manual/fr/html_node/

The development version is available though:

  https://guix.gnu.org/manual/devel/de/html_node/
  https://guix.gnu.org/manual/devel/es/html_node/
  https://guix.gnu.org/manual/devel/fr/html_node/

Ludo’.

bug#70551: channel-with-substitutes-available without network

[Simon Tournier]

Hi,

On Wed, 05 Jun 2024 at 10:14, Simon Tournier  wrote:
> On Wed, 24 Apr 2024 at 16:43, Simon Tournier  wrote:
>
>> Out of any network, I get this error:

[...]

>> Well, the proposed fix is here to catch the error; maybe it could be
>> finer than #t.

[...]

> Friendly ping for this patch?

Pushed as ffdcef5f36196f5e004ca6cb96f5accc0c73fc92.

Cheers,
simon

bug#72048: [core-updates] Epiphany (GNOME Web) fails to build (mesa?)

[Leo Famulari]

Thank you Ricardo! I was totally stuck on this.

On Mon, Jul 22, 2024, at 05:29, Ricardo Wurmus wrote:
> This is now fixed in commit bdff6baca39a73b3cfc5400e117795cad0c180cf.
>
> dbus-daemon watches XDG_* directories, and it bailed out because the
> list of directories to watch is just too large.  In the above commit we
> create a union directory, so that XDG_DATA_DIRS contains just one entry.
>
> -- 
> Ricardo

bug#72257: Non-English manuals for 1.4.0 are unavailable

[Ludovic Courtès]

Hi,

(+Cc translations team.)

Ludovic Courtès  skribis:

> Right now, non-English manuals for 1.4.0 are 404:
>
>   https://guix.gnu.org/manual/de/html_node/
>   https://guix.gnu.org/manual/es/html_node/
>   https://guix.gnu.org/manual/fr/html_node/

Looks like current po4a as invoked by ‘doc/build.scm’ doesn’t work:

--8<---cut here---start->8---
$ guix build 
/gnu/store/ffb4pkrfn9s8nxdmf65nziqhs4qlla2m-texinfo-manual-source.drv --check
The following derivations will be built:
  /gnu/store/ffb4pkrfn9s8nxdmf65nziqhs4qlla2m-texinfo-manual-source.drv
  /gnu/store/j87wq7m117c3d3ja8jla2jn2wkv1lg4k-guix-translated-texinfo.drv
substitute: updating substitutes from 'http://ci.guix.gnu.org'... 100.0%
building 
/gnu/store/j87wq7m117c3d3ja8jla2jn2wkv1lg4k-guix-translated-texinfo.drv...
File /gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg does not exist.
File /gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg does not exist.
File /gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg does not exist.
File /gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg does not exist.
File /gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg does not exist.
File /gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg does not exist.
File /gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg does not exist.
File /gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg does not exist.
In thread:
uncaught throw to %exception: (#<&invoke-error program: 
"/gnu/store/wf4gkjz3pqax3ids9xlgzg9pj2il7dni-po4a-0.69/bin/po4a" arguments: 
("--no-update" "--variable" "localized=guix.fr.texi.tmp" "--variable" 
"master=guix.texi" "--variable" "po=./guix-manual.fr.po" "--variable" 
"pot=/tmp/fileNBHtSJ.pot" 
"--srcdir=/gnu/store/3fk7j3g14q1h6prb93xhy44f3f55rxbr-guix" "--destdir=." 
"/gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg") exit-status: 2 
term-signal: #f stop-signal: #f>)
In thread:
uncaught throw to %exception: (#<&invoke-error program: 
"/gnu/store/wf4gkjz3pqax3ids9xlgzg9pj2il7dni-po4a-0.69/bin/po4a" arguments: 
("--no-update" "--variable" "localized=guix.pt_BR.texi.tmp" "--variable" 
"master=guix.texi" "--variable" "po=./guix-manual.pt_BR.po" "--variable" 
"pot=/tmp/fileQkL7Re.pot" 
"--srcdir=/gnu/store/3fk7j3g14q1h6prb93xhy44f3f55rxbr-guix" "--destdir=." 
"/gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg") exit-status: 2 
term-signal: #f stop-signal: #f>)
In thread:
uncaught throw to %exception: (#<&invoke-error program: 
"/gnu/store/wf4gkjz3pqax3ids9xlgzg9pj2il7dni-po4a-0.69/bin/po4a" arguments: 
("--no-update" "--variable" "localized=guix.es.texi.tmp" "--variable" 
"master=guix.texi" "--variable" "po=./guix-manual.es.po" "--variable" 
"pot=/tmp/fileJ2khxq.pot" 
"--srcdir=/gnu/store/3fk7j3g14q1h6prb93xhy44f3f55rxbr-guix" "--destdir=." 
"/gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg") exit-status: 2 
term-signal: #f stop-signal: #f>)
In thread:
uncaught throw to %exception: (#<&invoke-error program: 
"/gnu/store/wf4gkjz3pqax3ids9xlgzg9pj2il7dni-po4a-0.69/bin/po4a" arguments: 
("--no-update" "--variable" "localized=guix.de.texi.tmp" "--variable" 
"master=guix.texi" "--variable" "po=./guix-manual.de.po" "--variable" 
"pot=/tmp/fileI2FBVS.pot" 
"--srcdir=/gnu/store/3fk7j3g14q1h6prb93xhy44f3f55rxbr-guix" "--destdir=." 
"/gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg") exit-status: 2 
term-signal: #f stop-signal: #f>)
In thread:
uncaught throw to %exception: (#<&invoke-error program: 
"/gnu/store/wf4gkjz3pqax3ids9xlgzg9pj2il7dni-po4a-0.69/bin/po4a" arguments: 
("--no-update" "--variable" "localized=guix-cookbook.sk.texi.tmp" "--variable" 
"master=guix-cookbook.texi" "--variable" "po=./guix-cookbook.sk.po" 
"--variable" "pot=/tmp/file8Dg90X.pot" 
"--srcdir=/gnu/store/3fk7j3g14q1h6prb93xhy44f3f55rxbr-guix" "--destdir=." 
"/gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg") exit-status: 2 
term-signal: #f stop-signal: #f>)
In thread:
uncaught throw to %exception: (#<&invoke-error program: 
"/gnu/store/wf4gkjz3pqax3ids9xlgzg9pj2il7dni-po4a-0.69/bin/po4a" arguments: 
("--no-update" "--variable" "localized=guix-cookbook.fr.texi.tmp" "--variable" 
"master=guix-cookbook.texi" "--variable" "po=./guix-cookbook.fr.po" 
"--variable" "pot=/tmp/file6io6rG.pot" 
"--srcdir=/gnu/store/3fk7j3g14q1h6prb93xhy44f3f55rxbr-guix" "--destdir=." 
"/gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg") exit-status: 2 
term-signal: #f stop-signal: #f>)
In thread:
uncaught throw to %exception: (#<&invoke-error program: 
"/gnu/store/wf4gkjz3pqax3ids9xlgzg9pj2il7dni-po4a-0.69/bin/po4a" arguments: 
("--no-update" "--variable" "localized=guix-cookbook.de.texi.tmp" "--variable" 
"master=guix-cookbook.texi" "--variable" "po=./guix-cookbook.de.po" 
"--variable" "pot=/tmp/filer0TSAC.pot" 
"--srcdir=/gnu/store/3fk7j3g14q1h6prb93xhy44f3f55rxbr-guix" "--destdir=." 
"/gnu/store/gh2qlibnp6zy3ish7l5fxgq2v7k8n7f8-doc/po4a.cfg") exit-status: 2 
term-signal: #f stop-signal

bug#71962: Flatpak applications fail to launch with systemd-related error

[Juliana Sims via Bug reports for GNU Guix]

This issue persists and has worsened.

After looking into similar issue reports on Flatpak's GitHub 
repository, I tried removing gvfs from my system profile.  No luck.  I 
then also removed ntfs-3g and gnome-shell-extension-appindicator (after 
noticing the GNOME dropdown control panel now alerts to applications in 
the background) since I thought they may interact with parts of the 
system that cause issues.  Now whenever I try to launch Flatpak apps, 
my GNOME session crashes.

bug#72259: guix system: "guix graph -t referrers" could be more helpful in some cases

[Zack Weinberg]

On a Guix System installation, "guix graph -t referrers" is not
helpful when the package you're investigating is brought in directly
by the operating-system declaration.  Here are two examples.

1) Packages that have been added to the 'packages' property of the
operating-system declaration, but have no connection to any other
package, are described as unconnected.

(operating-system
  (packages (cons* (specification->package "lsof") %base-packages))
  ;; etc
)

# guix graph -t referrers lsof
digraph "Guix referrers" {
  "/gnu/store/7fkgda85xj4dr2d0r8lafyvnx5b9xwzp-lsof-4.94.0"
[label = "lsof-4.94.0", shape = box, fontname = sans];
}

2) If you've excluded a %base-packages package that ships setuid
binaries (e.g. "sudo", but forgotten to exclude the actual setuid
binaries as well, the package will still be included in the
operating-system derivation, and guix graph won't tell you why:

(operating-system
  (packages
(filter
  (lambda (pkg) (not (string= (package-name pkg) "sudo")))
  %base-packages))
  ;; etc
)

# guix graph -t referrers sudo
digraph "Guix referrers" {
  "/gnu/store/gnybfg31is632dyaivd907f2h0wff80d-sudo-1.9.14p3"
[label = "sudo-1.9.14p3", shape = box, fontname = sans];
  "/gnu/store/gnybfg31is632dyaivd907f2h0wff80d-sudo-1.9.14p3" ->
  "/gnu/store/gnybfg31is632dyaivd907f2h0wff80d-sudo-1.9.14p3"
[color = darkviolet];
}

This is saying that sudo refers to _itself_ and nothing else does,
which doesn't make any sense.

In both cases I would have expected "guix graph -t referrers"
to report that the package was a direct dependency of the
operating-system derivation itself; in the latter case I would
have liked it if there was some indication that the dependency
was because of 'setuid-binaries'.

zw

bug#70826: luks-device-mapping-with-options breaks bootloader

[Tomas Volf]

On 2024-05-25 10:30:49 -0400, Tadhg McDonald-Jensen wrote:
> That unfortunately doesn't fix the problem,
> `luks-device-mapping-with-options` is a routine that returns the
> `mapped-device-kind` so it won't check by equality.
>
> A possible solution is to check whether the `mapped-device-kind-close`
> routines are the same as these are shared.

What I find interesting is that I too am using luks-device-mapping-with-options
and my system boots just fine.  So I wonder what the difference is.  Could you
share your system configuration please?  Or at least the relevant parts (I
assume at least bootloader, file-systems and mapped-devices fields)?

I would like to properly understand the problem here and why it works for me.

Thanks,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#72257: Non-English manuals for 1.4.0 are unavailable

[Maxim Cournoyer]

Hi Ludo,

I think there is a patch on our tracker to use the latest po4a; perhaps it 
could help.

Maxim

bug#72239: libfaketime (still) broken on i686-linux

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

>> My suggestion would be to:
>>
>>   (substitute* "nss/tests/gtests/gtests.sh"
>> (("SOURCE_DIR=.*")
>>  (string-append "SOURCE_DIR=" (getcwd) "/nss\n")))
>>
>> WDYT?
>
> That looks good to me.

I have tested the following patch and successfully built nss on
i686-linux with it:

diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm
index 49276817ae..4b4d907e61 100644
--- a/gnu/packages/nss.scm
+++ b/gnu/packages/nss.scm
@@ -40,7 +40,8 @@ (define-module (gnu packages nss)
   #:use-module (gnu packages crates-io)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages perl)
-  #:use-module (gnu packages sqlite))
+  #:use-module (gnu packages sqlite)
+  #:use-module (gnu packages time))
 
 (define-public nspr
   (package
@@ -211,11 +212,21 @@ (define-public nss
 (substitute* "nss/tests/dbtests/dbtests.sh"
   ((" -lt 5") " -lt 50"))
 
+#$@(if (target-64bit?)
+   '()
+   ;; The script fails to determine the source
+   ;; directory when running under 'datefudge' (see
+   ;; ).  Help it.
+   #~((substitute* "nss/tests/gtests/gtests.sh"
+(("SOURCE_DIR=.*")
+ (string-append "SOURCE_DIR=" (getcwd) "/nss\n")
+
 ;; The "PayPalEE.cert" certificate expires every six months,
 ;; leading to test failures:
 ;; .  To
 ;; work around that, set the time to roughly the release date.
-(invoke "faketime" "2024-01-23" "./nss/tests/all.sh"))
+(invoke #$(if (target-64bit?) "faketime" "datefudge")
+"2024-01-23" "./nss/tests/all.sh"))
   (format #t "test suite not run~%"
   (replace 'install
 (lambda* (#:key outputs #:allow-other-keys)
@@ -240,7 +251,9 @@ (define-public nss
 (copy-recursively (string-append obj "/lib") lib)))
 (inputs (list sqlite zlib))
 (propagated-inputs (list nspr))   ;required by nss.pc.
-(native-inputs (list perl libfaketime which)) ;for tests
+(native-inputs (list perl
+ (if (target-64bit?) libfaketime datefudge)
+ which)) ;for tests
 
 ;; The NSS test suite takes around 48 hours on Loongson 3A (MIPS) when
 ;; another build is happening concurrently on the same machine.

Go for it?

Thanks,
Ludo’.

bug#72266: this-package-input for multiple outputs package

[Simon Tournier]

Hi,

For the good or the bad, we have package with multiple outputs.  For
instance, see ’git’ with ’git:send-email’ and others.

However, it’s not always easy to work with them using the “new style”.

For a concrete example: .


A minimal example.

--8<---cut here---start->8---
$ cat /tmp/pkgs/pkgs.scm
(define-module (pkgs)
  #:use-module (guix packages)
  #:use-module (gnu packages base)
  #:use-module (gnu packages version-control))

(define-public salut
  (package
(inherit hello)
(name "bye")
(inputs
 (list git
   `(,git "send-email")
--8<---cut here---end--->8---

Then, it’s possible to add phases, e.g.,

--8<---cut here---start->8---
(wrap-program (string-append #$output "/bin/hello")
  `("STUFF" ":" prefix
(,(string-append #$(this-package-input "git") "/bin")))
--8<---cut here---end--->8---

All fine!

However, from my understanding, it does not seem possible to access
using this “new style” way to other outputs than “out”.  Because, the
inputs reads,

--8<---cut here---start->8---
$ guix repl -q -L /tmp/pkgs
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(guix packages)
scheme@(guix-user)> ,use(pkgs)
scheme@(guix-user)> ,pp (package-inputs salut)
$1 = (("git"
  #)
 ("git"
  #
  "send-email"))
--8<---cut here---end--->8---

Other said, both outputs have the same label – here “git”.

Then, the procedure ’this-package-input’ – under the hood via
lookup-package-input and then lookup-input from (guix packages) – calls:

(assoc-ref (package-inputs some-package) some-string)

Therefore, since “some-string” is the same here, bang!


A first proposal for fixing the issue.

It’s easy to tweak how ’sanitize-inputs’ works.  For instance using this
patch:

--8<---cut here---start->8---
1 file changed, 1 insertion(+), 1 deletion(-)
guix/packages.scm | 2 +-

modified   guix/packages.scm
@@ -667,7 +667,7 @@ (define (add-input-label input)
 ((? package? package)
  (list (package-name package) package))
 (((? package? package) output);XXX: ugly?
- (list (package-name package) package output))
+ (list (string-append (package-name package) ":" output) package output))
 ((? gexp-input?)   ;XXX: misplaced because 'native?' field is ignored?
  (let ((obj(gexp-input-thing input))
(output (gexp-input-output input)))
--8<---cut here---end--->8---

Now we get different labels,

--8<---cut here---start->8---
scheme@(guix-user)> ,pp (package-inputs salut)
$1 = (("git"
  #)
 ("git:send-email"
  #
  "send-email"))
--8<---cut here---end--->8---

So far, so good!  Please note that some packages then need some
adjustment; e.g., see below.


Next, let add to the package definition this snippet for more wrapping,

--8<---cut here---start->8---
(,(string-append #$(this-package-input "git:send-email") 
"/bin")))
--8<---cut here---end--->8---

Because of the procedure ’lookup-input’ from (guix packages), the
package is correctly identified but the output is still discarded.
Hence this modification:

--8<---cut here---start->8---
1 file changed, 1 insertion(+)
guix/packages.scm | 1 +

modified   guix/packages.scm
@@ -1213,6 +1213,7 @@ (define (lookup-input inputs name)
   ;; check package names.
   (match (assoc-ref inputs name)
 ((obj) obj)
+((obj (? string? out)) (cons obj out))
 ((obj _) obj)
 (#f #f)))
 --8<---cut here---end--->8---

But then it is still incorrect.  For instance, we check using
’package-arguments’ and the interesting part reads:

--8<---cut here---start->8---
(unquote (string-append # . "send-email"):out> "/bin"))
--8<---cut here---end--->8---

Ok, this is incorrect and it will error when trying to build.  Well, the
G-exp compiler needs to be updated in agreement with ’lookup-input’ as
above.  What I would expect is something like:

#:send-email>


All in all, I am a bit lost inside the module (guix gexp). :-)  To be continued…

Cheers,
simon


Some adjustments here or there:

--8<---cut here---start->8---
1 file changed, 1 insertion(+

bug#72259: guix system: "guix graph -t referrers" could be more helpful in some cases

[Simon Tournier]

Hi,

On Tue, 23 Jul 2024 at 13:24, "Zack Weinberg" via Bug reports for GNU Guix 
 wrote:

>   I would have expected "guix graph -t referrers"
> to report that the package was a direct dependency of the
> operating-system derivation itself

Hum, I do not think that “guix graph” operated on the level of
’operating-system’.  That said, indeed something seems unexpected: you
get,

> # guix graph -t referrers lsof
> digraph "Guix referrers" {
>   "/gnu/store/7fkgda85xj4dr2d0r8lafyvnx5b9xwzp-lsof-4.94.0"
> [label = "lsof-4.94.0", shape = box, fontname = sans];
> }

and the manual reads [1],

‘referrers’
 This is the graph of the “referrers” of a store item, as returned
 by ‘guix gc --referrers’ (*note Invoking guix gc::).

 This relies exclusively on local information from your store.  For
 instance, let us suppose that the current Inkscape is available in
 10 profiles on your machine; ‘guix graph -t referrers inkscape’
 will show a graph rooted at Inkscape and with those 10 profiles
 linked to it.

 It can help determine what is preventing a store item from being
 garbage collected.

--8<---cut here---start->8---
$ guix package -p /tmp/one-profile -I
lsof4.94.0  out /gnu/store/6nyp9cvksvyfww5d7j7rvm43jb46p521-lsof-4.94.0

$ guix gc --referrers /gnu/store/6nyp9cvksvyfww5d7j7rvm43jb46p521-lsof-4.94.0
/gnu/store/5wmvmlba841wvy681840cjwjcdifcjq2-profile

$ guix graph -t referrers 
/gnu/store/6nyp9cvksvyfww5d7j7rvm43jb46p521-lsof-4.94.0
digraph "Guix referrers" {
  "/gnu/store/6nyp9cvksvyfww5d7j7rvm43jb46p521-lsof-4.94.0" [label = 
"lsof-4.94.0", shape = box, fontname = sans];
  "/gnu/store/6nyp9cvksvyfww5d7j7rvm43jb46p521-lsof-4.94.0" -> 
"/gnu/store/5wmvmlba841wvy681840cjwjcdifcjq2-profile" [color = red];
  "/gnu/store/5wmvmlba841wvy681840cjwjcdifcjq2-profile" [label = "profile", 
shape = box, fontname = sans];
  "/gnu/store/5wmvmlba841wvy681840cjwjcdifcjq2-profile" -> 
"/gnu/store/5wmvmlba841wvy681840cjwjcdifcjq2-profile" [color = darkgoldenrod];

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

So far, so good!  However, indeed:

--8<---cut here---start->8---
$ guix graph -t referrers lsof
digraph "Guix referrers" {
  "/gnu/store/7fkgda85xj4dr2d0r8lafyvnx5b9xwzp-lsof-4.94.0" [label = 
"lsof-4.94.0", shape = box, fontname = sans];

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

And the reason is because grafts.

--8<---cut here---start->8---
$ guix build lsof --no-grafts
/gnu/store/7fkgda85xj4dr2d0r8lafyvnx5b9xwzp-lsof-4.94.0

$ guix package -p /tmp/another-profile -i lsof --no-grafts

$ guix graph -t referrers lsof
digraph "Guix referrers" {
  "/gnu/store/7fkgda85xj4dr2d0r8lafyvnx5b9xwzp-lsof-4.94.0" [label = 
"lsof-4.94.0", shape = box, fontname = sans];
  "/gnu/store/7fkgda85xj4dr2d0r8lafyvnx5b9xwzp-lsof-4.94.0" -> 
"/gnu/store/hjgbwa566fwzmwvrdal5ycxzlzz3al6x-profile" [color = blue];
  "/gnu/store/hjgbwa566fwzmwvrdal5ycxzlzz3al6x-profile" [label = "profile", 
shape = box, fontname = sans];
  "/gnu/store/hjgbwa566fwzmwvrdal5ycxzlzz3al6x-profile" -> 
"/gnu/store/hjgbwa566fwzmwvrdal5ycxzlzz3al6x-profile" [color = darkgoldenrod];

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

Well, the fix should be to have the grafted item by default pointing to
the non-grafted one and potentially referencing the others as describe
by the manual.

Cheers,
simon


1: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-graph