bug#50349: [PATCH] packages: Add 'define-package' syntax.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

All,

To keep a link with previous ‘define-package’ discussion, I've 
merged this bug with #15284.  It was never resolved IMO and things 
have changed since 2013 with the label-less input style.


Maxime Devos 写道：
This could be even shorter in the special case that the variable 
name

and package name are the same (modulo types):

(define-package "my-favorite-package"
  (version ...)
  ...)


(define-anything STRING ...) is just too weird to ack.  Are there 
any package names that aren't currently valid symbols?  Is there a 
good reason for them?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#50371: guix system init fail with "In procedure map: Wrong type argument"

[Sven Oliver Severini]

root@gnu /mnt/rootfs/boot# guix system init /mnt/rootfs/etc/config.scm 
/mnt/rootfs/
Backtrace:
In guix/ui.scm:
   2185:7 19 (run-guix . _)
  2148:10 18 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
820:3 16 (_)
800:4 15 (call-with-status-report _ _)
In guix/scripts/system.scm:
   1228:4 14 (_)
In ice-9/boot-9.scm:
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   658:37 12 (thunk)
   1320:8 11 (call-with-build-handler # 
\ufffd)
  2108:24 10 (run-with-store # \ufffd)
In guix/scripts/system.scm:
  1252:15  9 (_ _)
807:9  8 (perform-action init #< name: #f format: disk-i\ufffd> 
\ufffd)
In gnu/system.scm:
  1327:26  7 (operating-system-bootcfg #< kernel:\ufffd> 
\ufffd)
   579:14  6 (operating-system-bootloader-crypto-devices #<)
In unknown file:
   5 (filter # 
\ufffd)
In gnu/system.scm:
   557:26  4 (_ _)
   533:17  3 (mapped-device-users #< source: #< 
\ufffd)
In srfi/srfi-1.scm:
241:2  2 (map _ _)
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:
In procedure map: Wrong type argument: "rootfs"

bug#50349: [PATCH] packages: Add 'define-package' syntax.

[Taylan Kammer]

On 04.09.2021 12:09, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote:
> All,
> 
> To keep a link with previous ‘define-package’ discussion, I've merged this 
> bug with #15284.  It was never resolved IMO and things have changed since 
> 2013 with the label-less input style.
> 
> Maxime Devos 写道：
>> This could be even shorter in the special case that the variable name
>> and package name are the same (modulo types):
>>
>> (define-package "my-favorite-package"
>>   (version ...)
>>   ...)
> 
> (define-anything STRING ...) is just too weird to ack.  Are there any package 
> names that aren't currently valid symbols?  Is there a good reason for them?
> 
> Kind regards,
> 
> T G-R

To me the most obvious thing to do seems

  (define-package foo ...)  ;no explicit name needed

to bind the variable 'foo' and use symbol->string for the name of the
package, with the possibility to override the name like

  (define-package foo (name "foobar") ...)

which would bind the variable 'foo' to a package named "foobar".

Here's a syntax-case definition:

  (define-syntax define-package
(lambda (stx)
  (syntax-case stx ()
((_ 
   (  ...)
   ...)
 (if (memq 'name (map syntax->datum #'( ...)))
 #'(define-public 
 (package
   (  ...)
   ...))
 #`(define-public 
 (package
   (name #,(symbol->string (syntax->datum #')))
   (  ...)
   ...)))

-- 
Taylan

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Ludovic Courtès]

Hi Sarah,

Sarah Morgensen  skribis:

> Gentoo's tracker for this issue [2] also has some more info.  I manually
> searched Cuirass build logs and found 28 packages failing on x86_64 with
> this error:
>
> arcan-sdl@0.5.5.2-1.b4dd1fb
> aris@2.2
> blastem@0.6.2
> chocolate-doom@3.0.1
> crispy-doom@5.8.0
> geeqie@1.5
> glabels@3.4.1
> gmtp@1.3.11
> gpredict@2.2.1
> gtksheet@4.3.5
> jumpnbump@1.61
> lablgtk@2.18.10
> libappindicator@12.10.0
> libopenshot@0.2.5
> libsrtp@2.3.0
> linsmith@0.99.31
> megaglest@3.13.0
> mupen64plus-core@2.5
> ocaml4.07-lablgtk@1.18.10
> ocl-icd@2.2.12
> opencpn@5.0.0
> pcsxr@1.9.95
> pipewire@0.2.7
> transcode@1.1.7
> transmission-remote-gtk@1.4.1
> uget@2.2.1
> uim-gtk@1.8.8
> uim-qt@1.8.8
>
> I submitted an issue upstream for transmission-remote-gtk [3], but I
> haven't taken a look at the others.  Any takers?

Great that you built a list of affected packages.

I guess there are several options:

  1. Build with ‘-fcommon’, effectively restoring pre-GCC-10 behavior;

  2. Build with GCC 8.x or so, for example by adding it to
 ‘native-inputs’;

  3. Upgrade packages and hope for the best;

  4. Add the missing ‘extern’ keyword in declarations, assuming that
 really is the problem.

I suppose we’ll have to see on a case-by-cases basis which approach is
the easiest.  Since we have a list, let’s parallelize work and
synchronize on IRC and in this issue!

Thanks,
Ludo’.

bug#50349: [PATCH] packages: Add 'define-package' syntax.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Taylan Kammer 写道：

To me the most obvious thing to do seems

  (define-package foo ...)  ;no explicit name needed

to bind the variable 'foo' and use symbol->string for the name 
of the

package, with the possibility to override the name like

  (define-package foo (name "foobar") ...)

which would bind the variable 'foo' to a package named "foobar".


Right, that's what I meant, and it's how I read bug #15284, and it 
looks remarkably like the form I use in my personal channels (and 
I'm sure I'm not the first! :-).


You're much better at the language/implementation side of things 
than I am, Taylan.  Would this negatively affect performance 
(including ‘guix pull’ compilation)?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#50264: ca-certificate-bundle fails to build

[Ludovic Courtès]

Hi,

Lars-Dominik Braun  skribis:

> Hi,
>
> I’ve seen this multiple times now, most recently with commit
> 8ef38cd1bf7ec17b8d1bc1c0bcb42ac30ac30406 on a foreign system: Some
> operation, here a `guix pack` tries to build ca-certificate-bundle and
> it fails the first time, but rerunning the same operation succeeds:
>
> ---snip---
> -builder for 
> `/gnu/store/iqm2zwq8jrr9gaw5jp4vs42j887aglmk-ca-certificate-bundle.drv' 
> failed with exit code 1
> Erstellung von 
> /gnu/store/iqm2zwq8jrr9gaw5jp4vs42j887aglmk-ca-certificate-bundle.drv 
> fehlgeschlagen
> Das Erstellungsprotokoll kann unter 
> „/var/log/guix/drvs/iq/m2zwq8jrr9gaw5jp4vs42j887aglmk-ca-certificate-bundle.drv.bz2“
>  eingesehen werden.
> cannot build derivation 
> `/gnu/store/riw7sfkl8a5rapyvf6vvh07cwv3nrwil-profile.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/l8zdf69zk0pg599gifcyxbd80h676yp1-python-jupyterlab-bash-coreutils-docker-pack.tar.zst.drv':
>  1 dependencies couldn't be built
> guix pack: Fehler: build of 
> `/gnu/store/l8zdf69zk0pg599gifcyxbd80h676yp1-python-jupyterlab-bash-coreutils-docker-pack.tar.zst.drv'
>  failed
> ---snap---
>
> The backtrace looks like this:
>
> ---snip---
> Backtrace:
>2 (primitive-load "/gnu/store/74i539y9b0bvslk3bk0kc27q76p?")
> In ice-9/eval.scm:
> 619:8  1 (_ #f)
> In unknown file:
>0 (setlocale 6 "en_US.utf8")
>
> ERROR: In procedure setlocale:
> In procedure setlocale: Invalid argument
> ---snap---

Is this the backtrace found in the build log (under /var/log/guix/drvs)?

I tried and failed to reproduce it like this:

--8<---cut here---start->8---
$ guix environment --ad-hoc nss-certs -n
La jena derivo estus konstruata:
   /gnu/store/i5s8jqzl52j38qmwqghjyp0v8p7dnlgd-profile.drv

$ guix gc -R /gnu/store/i5s8jqzl52j38qmwqghjyp0v8p7dnlgd-profile.drv |grep 
certificate
/gnu/store/n63a6h3dfhwnaas9pg35zk78qjhxbas9-cmake-curl-certificates.patch
/gnu/store/c8czsp9prfd73wvnyh595h0riqcllfqp-ca-certificate-bundle-builder
/gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
$ guix build --rounds=10 
/gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
The following profile hook will be built:
   /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
building CA certificate bundle...
building CA certificate bundle...
building CA certificate bundle...
building CA certificate bundle...
building CA certificate bundle...
building CA certificate bundle...
building CA certificate bundle...
building CA certificate bundle...
building CA certificate bundle...
building CA certificate bundle...
successfully built 
/gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
The following builds are still in progress:
  /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
  /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
  /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
  /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
  /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
  /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
  /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
  /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv
  /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv

/gnu/store/gwgja3hnmlajwxy6rqayf8yd937d8yi5-ca-certificate-bundle
--8<---cut here---end--->8---

Could you find a way to reproduce the issue?

Also, could you run ‘guix build glibc-utf8-locales --check’, so make
sure that store item is not corrupt?

I have:

--8<---cut here---start->8---
$ guix build glibc-utf8-locales 
/gnu/store/rgydar9dfvflqqz2irgh7njj34amaxc6-glibc-utf8-locales-2.31
$ guix hash -r $(guix build glibc-utf8-locales)
012a1vcvmhbrqr5kjbmf7qlgpbw2zv36rgj7rxh400dh8wlj97pi
$ wget -qO - https://ci.guix.gnu.org/rgydar9dfvflqqz2irgh7njj34amaxc6.narinfo 
|grep NarHash
NarHash: sha256:012a1vcvmhbrqr5kjbmf7qlgpbw2zv36rgj7rxh400dh8wlj97pi
--8<---cut here---end--->8---

TIA,
Ludo’.

bug#50349: [PATCH] packages: Add 'define-package' syntax.

[Taylan Kammer]

On 04.09.2021 16:44, Tobias Geerinckx-Rice wrote:
> Taylan Kammer 写道：
>> To me the most obvious thing to do seems
>>
>>   (define-package foo ...)  ;no explicit name needed
>>
>> to bind the variable 'foo' and use symbol->string for the name of the
>> package, with the possibility to override the name like
>>
>>   (define-package foo (name "foobar") ...)
>>
>> which would bind the variable 'foo' to a package named "foobar".
> 
> Right, that's what I meant, and it's how I read bug #15284, and it looks 
> remarkably like the form I use in my personal channels (and I'm sure I'm not 
> the first! :-).
> 
> You're much better at the language/implementation side of things than I am, 
> Taylan.  Would this negatively affect performance (including ‘guix pull’ 
> compilation)?
> 
> Kind regards,
> 
> T G-R

I'm flattered, but don't really know the answer, so I decided to attempt
some sort of benchmark. :-P

test1.scm uses the syntax-case macro, test2.scm just define-public.

I don't actually import the Guix modules, so the (package ...) form isn't
macro-expanded, regardless of whether it's used directly or results from
expanding define-package.

This way, the impact of define-package should dominate the time difference.

The results are... interesting.  I started out with 256 definitions in the
files, and the define-package one would take about 4.2s to compile while
the regular one about 3.9s.  There was some jitter in the results though
after running it several times so I thought, let's increase the number of
packages to reduce noise.

With 512 packages, the one using regular define-public takes a whole
minute to compile, whereas the define-package one just ~14 seconds!

So no idea what's going on there, and how the use of this macro in the
actual (gnu packages ...) modules would affect performance. :-)

-- 
Taylan
(define-module (test1))

(define-syntax define-package
  (lambda (stx)
(syntax-case stx ()
  ((_ 
  (  ...)
  ...)
   (if (memq 'name (map syntax->datum #'( ...)))
   #'(define-public 
   (package
(  ...)
...))
   #`(define-public 
   (package
(name #,(symbol->string (syntax->datum #')))
(  ...)
...)))

(define-package p0
  (foo x)
  (bar y)
  (baz z))

(define-package p1
  (foo x)
  (bar y)
  (baz z))

(define-package p2
  (foo x)
  (bar y)
  (baz z))

(define-package p3
  (foo x)
  (bar y)
  (baz z))

(define-package p4
  (foo x)
  (bar y)
  (baz z))

(define-package p5
  (foo x)
  (bar y)
  (baz z))

(define-package p6
  (foo x)
  (bar y)
  (baz z))

(define-package p7
  (foo x)
  (bar y)
  (baz z))

(define-package p8
  (foo x)
  (bar y)
  (baz z))

(define-package p9
  (foo x)
  (bar y)
  (baz z))

(define-package p10
  (foo x)
  (bar y)
  (baz z))

(define-package p11
  (foo x)
  (bar y)
  (baz z))

(define-package p12
  (foo x)
  (bar y)
  (baz z))

(define-package p13
  (foo x)
  (bar y)
  (baz z))

(define-package p14
  (foo x)
  (bar y)
  (baz z))

(define-package p15
  (foo x)
  (bar y)
  (baz z))

(define-package p16
  (foo x)
  (bar y)
  (baz z))

(define-package p17
  (foo x)
  (bar y)
  (baz z))

(define-package p18
  (foo x)
  (bar y)
  (baz z))

(define-package p19
  (foo x)
  (bar y)
  (baz z))

(define-package p20
  (foo x)
  (bar y)
  (baz z))

(define-package p21
  (foo x)
  (bar y)
  (baz z))

(define-package p22
  (foo x)
  (bar y)
  (baz z))

(define-package p23
  (foo x)
  (bar y)
  (baz z))

(define-package p24
  (foo x)
  (bar y)
  (baz z))

(define-package p25
  (foo x)
  (bar y)
  (baz z))

(define-package p26
  (foo x)
  (bar y)
  (baz z))

(define-package p27
  (foo x)
  (bar y)
  (baz z))

(define-package p28
  (foo x)
  (bar y)
  (baz z))

(define-package p29
  (foo x)
  (bar y)
  (baz z))

(define-package p30
  (foo x)
  (bar y)
  (baz z))

(define-package p31
  (foo x)
  (bar y)
  (baz z))

(define-package p32
  (foo x)
  (bar y)
  (baz z))

(define-package p33
  (foo x)
  (bar y)
  (baz z))

(define-package p34
  (foo x)
  (bar y)
  (baz z))

(define-package p35
  (foo x)
  (bar y)
  (baz z))

(define-package p36
  (foo x)
  (bar y)
  (baz z))

(define-package p37
  (foo x)
  (bar y)
  (baz z))

(define-package p38
  (foo x)
  (bar y)
  (baz z))

(define-package p39
  (foo x)
  (bar y)
  (baz z))

(define-package p40
  (foo x)
  (bar y)
  (baz z))

(define-package p41
  (foo x)
  (bar y)
  (baz z))

(define-package p42
  (foo x)
  (bar y)
  (baz z))

(define-package p43
  (foo x)
  (bar y)
  (baz z))

(define-package p44
  (foo x)
  (bar y)
  (baz z))

(define-package p45
  (foo x)
  (bar y)
  (baz z))

(define-package p46
  (foo x)
  (bar y)
  (baz z))

(define-package p47
  (foo x)
  (bar y)
  (baz z))

(define-package p48
  (foo x)
  (bar y)
  (baz z))

(define-package p49
  (foo x)
  (bar y)
  (baz z))

(define-package p50
  (foo x)
  (bar y)
  (baz z))

(define-package p51
  (foo x)
  (bar y)
  (baz z))

(define-p

bug#50349: [PATCH] packages: Add 'define-package' syntax.

[Sarah Morgensen]

Hi Taylan,

Taylan Kammer  writes:

> On 04.09.2021 16:44, Tobias Geerinckx-Rice wrote:
>> Taylan Kammer 写道：
>>> To me the most obvious thing to do seems
>>>
>>>   (define-package foo ...)  ;no explicit name needed
>>>
>>> to bind the variable 'foo' and use symbol->string for the name of the
>>> package, with the possibility to override the name like
>>>
>>>   (define-package foo (name "foobar") ...)
>>>
>>> which would bind the variable 'foo' to a package named "foobar".
>> 
>> Right, that's what I meant, and it's how I read bug #15284, and it looks 
>> remarkably like the form I use in my personal channels (and I'm sure I'm not 
>> the first! :-).
>> 
>> You're much better at the language/implementation side of things than I am, 
>> Taylan.  Would this negatively affect performance (including ‘guix pull’ 
>> compilation)?
>> 
>> Kind regards,
>> 
>> T G-R

I agree; if we added that magic, that's definitely how it should be.

>
> I'm flattered, but don't really know the answer, so I decided to attempt
> some sort of benchmark. :-P
>
> test1.scm uses the syntax-case macro, test2.scm just define-public.
>
> I don't actually import the Guix modules, so the (package ...) form isn't
> macro-expanded, regardless of whether it's used directly or results from
> expanding define-package.
>
> This way, the impact of define-package should dominate the time difference.
>
> The results are... interesting.  I started out with 256 definitions in the
> files, and the define-package one would take about 4.2s to compile while
> the regular one about 3.9s.  There was some jitter in the results though
> after running it several times so I thought, let's increase the number of
> packages to reduce noise.
>
> With 512 packages, the one using regular define-public takes a whole
> minute to compile, whereas the define-package one just ~14 seconds!
>
> So no idea what's going on there, and how the use of this macro in the
> actual (gnu packages ...) modules would affect performance. :-)

Thanks for running some benchmarks. Were both those latter runs with a
warm cache?

If so, is it possible that due to a compilation optimization, many of
the global symbol lookups only happen once with the define-package
macro?

If you were really interested, I suppose you could test with compilation
optimization off, but I'd be more interested in the performance impact
with (guix packages) imported.

--
Sarah

bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64

[Simon South]

Simon South  writes:
> But this additional call _is_ expected on Guix systems, so the test
> cases ought to be modified to match.

Perhaps, but having looked into this it's complicated because

- The expected output from the tests is not contained in the source
  bundle in a separate, easy-to-patch file but is actually generated by
  the C code under test as it runs;

- Even if that weren't true, only one test must be patched for both to
  succeed, and the choice depends on the target architecture so there
  wouldn't be a single patch that could work in all cases; and

- The additional output that needs to be generated by the C code
  actually embeds part of a store path, meaning this would need to be
  determined by the code at runtime (possibly yielding even more
  "readlink" calls that would need to be accounted for) in addition to
  truncating and formatting the output to match what strace itself
  produces...

It's too much.  I'm going to follow up with a patch that basically
applies the diff above in a tidy manner, and I think that will be the
best solution.  It is a very limited change that does not alter the
purpose of the tests; does not allow them to pass where they would
normally fail; and will work equally well on all systems, even if a
completely different glibc package is introduced.  Certainly it is an
improvement over simply disabling both tests.

-- 
Simon South
si...@simonsouth.net

bug#50346: [PATCH core-updates-frozen] gnu: strace: Allow readlink, readlinkat tests to pass.

[Simon South]

Modify the invocation of strace's "readlink" and "readlinkat" tests to prevent
them from failing due to an additional system call made by Guix's patched
version of glibc.

* gnu/packages/linux.scm (strace)[source]: Add patch.
[arguments]<#:phases>: Do not disable the "readlink" test now that it can
succeed.
* gnu/packages/patches/strace-fix-readlink-readlinkat-tests.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
---
 gnu/local.mk  |  1 +
 gnu/packages/linux.scm|  8 ++--
 ...strace-fix-readlink-readlinkat-tests.patch | 46 +++
 3 files changed, 50 insertions(+), 5 deletions(-)
 create mode 100644 
gnu/packages/patches/strace-fix-readlink-readlinkat-tests.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index bb22e29caa..f9c8956568 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1547,6 +1547,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/sdl-pango-sans-serif.patch  \
   %D%/packages/patches/smalltalk-multiplication-overflow.patch \
   %D%/packages/patches/sqlite-hurd.patch   \
+  %D%/packages/patches/strace-fix-readlink-readlinkat-tests.patch  \
   %D%/packages/patches/sunxi-tools-remove-sys-io.patch \
   %D%/packages/patches/patchutils-test-perms.patch \
   %D%/packages/patches/patch-hurd-path-max.patch   \
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 63f0e4108c..99b7ce7066 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -2240,7 +2240,9 @@ Zerofree requires the file system to be unmounted or 
mounted read-only.")
  "/strace-" version ".tar.xz"))
  (sha256
   (base32
-   "0mmns22bjjvakxj29si0x4dcylcgy26llpcimkb0llcxif439k2s"
+   "0mmns22bjjvakxj29si0x4dcylcgy26llpcimkb0llcxif439k2s"))
+ (patches
+  (search-patches "strace-fix-readlink-readlinkat-tests.patch"
 (build-system gnu-build-system)
 (arguments
  '(#:phases
@@ -2253,10 +2255,6 @@ Zerofree requires the file system to be unmounted or 
mounted read-only.")
  (add-after 'unpack 'disable-failing-tests
(lambda _
  (substitute* "tests/Makefile.in"
-   ;; XXX: This test fails because an extra readlink call is made
-   ;; by the glibc when using the ld.so cache.
-   (("readlink.gen.test[^:]") " ")
-
;; XXX: These hang forever even if the test time-out is
;; extended.
(("^\tstrace-DD?D?\\.test .*") "")
diff --git a/gnu/packages/patches/strace-fix-readlink-readlinkat-tests.patch 
b/gnu/packages/patches/strace-fix-readlink-readlinkat-tests.patch
new file mode 100644
index 00..dd5ee98703
--- /dev/null
+++ b/gnu/packages/patches/strace-fix-readlink-readlinkat-tests.patch
@@ -0,0 +1,46 @@
+Prevent strace's "readlink" and "readlinkat" tests from failing due to the
+additional system call made by glibc with the patch "glibc-dl-cache.patch"
+applied (introduced in commit 52564e9).
+
+These changes cause strace to report during these tests only system calls on
+files contained in the test directory, effectively filtering out the
+additional readlink/readlinkat call on "/proc/self/exe" and allowing the tests
+to complete as normal.
+
+diff --git a/tests/gen_tests.in b/tests/gen_tests.in
+index 8b4e2e9..cc3ca63 100644
+--- a/tests/gen_tests.in
 b/tests/gen_tests.in
+@@ -623,8 +623,8 @@ quotactl-xfs-v -v -e trace=quotactl
+ read-write-a15 -eread=0,5 -ewrite=1,4 -e trace=read,write -P 
read-write-tmpfile -P /dev/zero -P /dev/null
+ readahead -a1
+ readdir   -a16
+-readlink  -xx
+-readlinkat-xx
++readlink  -xx --trace-path=test.readlink.link
++readlinkat-xx --trace-path=test.readlinkat.link
+ reboot-s 256
+ recv-MSG_TRUNC-a26 -e trace=recv
+ recvfrom  -a35
+diff --git a/tests/readlink.gen.test b/tests/readlink.gen.test
+index 4263234..418691b 100755
+--- a/tests/readlink.gen.test
 b/tests/readlink.gen.test
+@@ -1,4 +1,4 @@
+ #!/bin/sh -efu
+-# Generated by ./tests/gen_tests.sh from ./tests/gen_tests.in (readlink -xx 
); do not edit.
++# Generated by ./tests/gen_tests.sh from ./tests/gen_tests.in (readlink -xx 
--trace-path=test.readlink.link); do not edit.
+ . "${srcdir=.}/init.sh"
+-run_strace_match_diff -xx 
++run_strace_match_diff -xx --trace-path=test.readlink.link
+diff --git a/tests/readlinkat.gen.test b/tests/readlinkat.gen.test
+index d7de993..a48d590 100755
+--- a/tests/readlinkat.gen.test
 b/tests/readlinkat.gen.test
+@@ -1,4 +1,4 @@
+ #!/bin/sh -efu
+-# Generated by ./tests/gen_tests.sh from ./tests/gen_tests.in (readlinkat -xx 
); do not edit.
++# Generated by ./tests/gen_tests.sh from ./tests/gen_tests.in (readlinkat -xx 
--trace-path=test.readlinkat.link); do not edit.
+ . "${srcdir=.}/init.sh"
+-run_strace_match_diff 

bug#50349: [PATCH] packages: Add 'define-package' syntax.

[Sarah Morgensen]

Hi all,

Thanks for your comments.  I'm replying specifically to this message but
these thoughts apply to the issue as a whole.

Maxime Devos  writes:

> Sarah Morgensen schreef op do 02-09-2021 om 21:06 [-0700]:
>> Hello Guix,
>> 
>> This patch adds a shorthand for "(define-public name (package ...))":
>> 
>> (define-package my-favorite-package
>>   (name "my-favorite-package")
>>   ...)
>
> This could be even shorter in the special case that the variable name
> and package name are the same (modulo types):
>
> (define-package "my-favorite-package"
>   (version ...)
>   ...)
>
> 'datum->syntax' and 'string->symbol' can be used to turn "my-favorite-package"
> into an identifier.
>
> A 'define-unexported-package' might be required in some places.

Sure, or perhaps 'define-private-package'.  I think this is pretty rare,
though?  And often in those cases other forms are used which may be
incompatible with the macro, so they'll have to use the original syntax
anyway.  Either way is fine IMO.

There are also about 150 packages which use 'package/inherit'.  Should
we introduce special syntax for them?  What about 'hidden-package'
(about 60 packages)?  (And 11 use both!)

About the only form I can think of that wouldn't break the composability
of these kinds of things is something like

  (define-package* hello (hidden)
(name "hello")
...)

or

  (define-package* hello (hidden inherit-replacements)
(name "hello")
...)

Where 'hidden', 'inherit-replacements', and so on would be procs to
apply (in the same order as compose?) that each transform the package.
Or we could even have them transform the package syntax directly.

But that's even more magic; it would take a fair amount of work, and be
hard to get right.  (How well would it hold up to syntax errors?)

>
> [...]
> This looks nice to me.  IIUC, the define-package is intended to be clearer
> to newcomers, so you might want to ask for feedback on the new syntax on
> help-g...@gnu.org.

Thanks for the suggestion, I definitely will.

With an eye toward newcomers, I think one "gotcha" of the "optional
name" version is inheritance.  If I have

(define-package rust-actix-0.10
  (name "rust-actix")
  ...)

and then I write

(define-package rust-actix-0.20
  (inherit rust-actix-0.10)
  ...)

At best, I would be unsure about whether this package would inherit the
name.  At worst, I would assume the name is inherited, and I would be
wrong.  If I have to write the name, there is no ambiguity.

For the automatic naming (because of gotchas like that), and for
possible extensions discussed above, I think right now I'm tempted to
agree with Ludo's comment when this last came around (thanks to Tobias
for pointing out the conversation)[0]:

l...@gnu.org (Ludovic Courtès) writes:

> However, I prefer treating packages just like any other Scheme object,
> and to avoid introducing “magic” with macros like this.

I could be convinced with an elegant enough implementation though! ;)

[0] https://lists.gnu.org/archive/html/bug-guix/2013-09/msg5.html
--
Sarah

bug#44898: [wishlist] Make the GRUB installation procedure smarter

[muradm]

First I was using Guix on Lenovo Carbon X1 in parallel with Arch. 
Few times I experiences "NVRAM full" or similar problem, I don't 
recall now. Solution was to reset NVRAM by some procedure. Half a 
year now, I moved to System76 Lemur Pro, where I have only Guix 
alone. Here I have another problem, sometimes it simply does not 
boot, then I have to plug USB, and run grub-install manually to 
recover.


As per discussion on IRC today, I would suggest the folowing 
regarding grub efi, I'm not using other bootloaders, but I suppose 
same logic may apply.


There are two things about grub:

1) /boot/efi/EFI/Guix/grubx64.efi & NVRAM - these are changing 
very very rarely, only when grub version change, boot partition 
change.


2) /boot/grub/* - these are changing only when grub version change 
or new guix generation is created, then grub.cfg is getting 
updated.


Currently, as far as I understand, both of them are getting 
installed with one script from this derivation:

/gnu/store/...-install-bootloader.scm.drv

It could be split into two, one which runs grub-install, i.e. #1 
above, the other which covers #2 above, let's say 
bootloader-phase-1-install and bootloader-phase-2-install 
respectively.


Then, each script can be executed only when derivation is 
changing. With the following exceptions:

- must be executed anyway on "guix system init ..."
- must be executed only if "guix system reconfigure 
 --force-bootloader ..."


Scripts them selves store grub version (via absolute path), thus 
if grub updated, derivations will change.


If for some reason, grub and/or nvram getting broken on boot, user 
has to boot with some kind recovery media anyway.

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Sarah Morgensen]

Hi Ludo,

>> lablgtk@2.18.10
>> libsrtp@2.3.0
>> ocaml4.07-lablgtk@1.18.10

I've sent patches [0] [1] to fix these by updating them.  Together they
have 79 dependents.

[0] https://issues.guix.gnu.org/50388
[1] https://issues.guix.gnu.org/50389

--
Sarah

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Sarah Morgensen]

Hi again,

>> libappindicator@12.10.0
>> pipewire@0.2.7

I've sent patches for these [0][1], with a total of 22 dependents.

The remaining packages have a total of 19 dependents, 7 of which belong
to ocl-icd@2.2.12.  As soon as ocl-icd's website is back online, updating
it to 2.2.13 should fix the build.

[0] https://issues.guix.gnu.org/50392
[1] https://issues.guix.gnu.org/50396

--
Sarah