bug#74204: [bug#74112] Guix is not reproducible

[Simon Tournier]

Hi,

On Tue, 05 Nov 2024 at 23:25, Hilton Chain via Bug reports for GNU Guix 
 wrote:

>> I can confirm the reproducibility issue.
>>
>> I have two x86_64-linux machines building guix to verify the fix, I'll apply
>> your patch once they produce matching outputs.
>
> Took me quite a while to build 5 rounds. :)
>
> --8<---cut here---start->8---
> $ guix hash --serializer=nar 
> /gnu/store/fs7x07jfn7igpkwv3alrs9by21q70y13-guix-1.4.0-26.5ab3c4c
> 0kh87wb4qn97kwzrf4igal71cjvv143j6jr2y3dwfzcy1madj1ll
> --8<---cut here---end--->8---
>
> Applied #74112 as 4c56d0cccdc44e12484b26332715f54768738c5f, thanks!

Maybe I am missing something.  To my knowledge, .go files produced by
Guile are not always reproducible, see bug#20272 [1].  And, from my
understanding, Guix cannot be reproducible until this bug had been
fixed.  Therefore, I am not convinced that this patch is worth under
this frame considering the build-time penalty it brings.

That’s said, maybe it’s better than nothing and the package ’guix’ is
barely built after all.  I do not know.

What people think?

Cheers,
simon

1: https://issues.guix.gnu.org/issue/20272

bug#35085: Emacs is not reproducible

[Simon Tournier]

Hi,

On Tue, 05 Nov 2024 at 12:34, Cayetano Santos via Bug reports for GNU Guix 
 wrote:

> Follow up as for today on emacs 29.4.

The good news:

https://emacsconf.org/2024/talks/repro/

Let see if there is an upstream willing to tackle this. :-)

Cheers,
simon

bug#73602: bug#73601: failed to compute the derivation for Guix

[Simon Tournier]

Hi Fabrice,

On Tue, 05 Nov 2024 at 15:00, Fabrice Tudoret  
wrote:

> The storm is over and users no longer complain.

Cool!  Good news. :-)

Closing?

Cheers,
simon

bug#73601: bug#73602: bug#73601: failed to compute the derivation for Guix

[Simon Tournier]

Hi,

Sorry for the late reply.

On Mon, 14 Oct 2024 at 14:03, Fabrice Tudoret  
wrote:

>> c) Display the both derivations, as root and as regular user
>>
>># guix build -e '(@@ (gnu packages commencement) python-boot0)' -S -d
>
> [root@cluster24 ~]# guix build -e '(@@ (gnu packages commencement) 
> python-boot0)' -S -d
> /gnu/store/mbnrrqjizy3dvma9i3l8g5yvzi2p04ys-Python-3.5.9.tar.xz.drv
>
>>
>>$ guix build -e '(@@ (gnu packages commencement) python-boot0)' -S -d
>
> [fmenna@cluster24 ~]$  guix build -e '(@@ (gnu packages commencement) 
> python-boot0)' -S -d
> user with UID 255759 not found
> /gnu/store/mbnrrqjizy3dvma9i3l8g5yvzi2p04ys-Python-3.5.9.tar.xz.drv
>
> I hope the message "user with UID 255759 not found" has nothing to do 
> with the issue.

Well, this message comes from the Guix daemon (see nix-daemon.cc file):

/* Open the store. */
store = std::shared_ptr(new LocalStore(reserveSpace));

if (userId != (uid_t) -1) {
/* Create the user profile.  */
struct passwd *pw = getpwuid(userId);
if (pw != NULL && pw->pw_name != NULL)
store->createUser(pw->pw_name, userId);
else
printMsg(lvlInfo, format("user with UID %1% not found") % 
userId);
}


Hum, that’s not clear for me.  The daemon is a beast… Maybe this has an
impact.  For sure, aside Guix, I think it would be better to fix it. :-)

Well, I do not know why but this other message:

> When I create the user home dir manually, the "guix pull" work's fine. 
> So the trouble could come from a disorder with the automatic home dir 
> creation.

> I wish it's the right track. I keep digging.

spots the light on UID. :-)

Cheers,
simon

bug#74015: 'guix shell --export-manifest' fails for some transformations

[Simon Tournier]

Hi,

I notice this:

--8<---cut here---start->8---
$ cat manifest.scm
(use-modules (guix transformations) (guix packages)
 (guix download) (guix build-system r))

(define r-knitr
  (specification->package "r-knitr"))

(define r-knitr-other
  (package
(inherit r-knitr)
(version "1.47")
(source (origin
  (method url-fetch)
  (uri (cran-uri "knitr" version))
  (sha256
   (base32
"1kx6g8ddbigwx3bmq771gwi3din3fxjn59l801904kjaz6dq9pgs"))

(define r-ggplot2
  (package
(inherit
 ((package-input-rewriting `((,r-knitr . ,r-knitr-other)))
  (specification->package "r-ggplot2")))
(name "my-ggplot")))

(define transform
  (options->transformation
'((with-c-toolchain . "r-minimal=gcc-toolchain@12")
  (with-c-toolchain . "r=gcc-toolchain@12"

(packages->manifest
 (append
  (map specification->package
   (list "python" "python-numpy"))
  (map transform
   (list (specification->package "r")
 r-ggplot2

$ guix shell -m manifest.scm --export-manifest
guix shell: warning: transformation 'with-c-toolchain' had no effect on 
my-ggplot@3.5.1.
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.

(use-modules (guix transformations))

(define transform1
  (options->transformation
'((with-c-toolchain . "r-minimal=gcc-toolchain@12")
  (with-c-toolchain . "r=gcc-toolchain@12"

(packages->manifest
  (list (specification->package "python")
(specification->package "python-numpy")
(transform1 (specification->package "r"))
(transform1 (specification->package "my-ggplot"
--8<---cut here---end--->8---

Well, this is incorrect.  While I understand the approximation when
dealing with profiles built over time in the imperative way, here I am
missing why the transformation of ’r-ggplot2’ is skipped.  And even the
export manifest is broken.

It’s skipped because:

--8<---cut here---start->8---
$ guix shell -m manifest.scm
$ grep ggplot $GUIX_ENVIRONMENT/manifest
 ("my-ggplot"
  "/gnu/store/x0jbmvg0nbl7lyk8zd938rq2c7c9qkn4-my-ggplot-3.5.1"
--8<---cut here---end--->8---

Please note that if the symbol ’r-ggplot2’ is not named “my-ggplot” but
kept as ’r-ggplot2“:

(define r-ggplot2
  ((package-input-rewriting `((,r-knitr . ,r-knitr-other)))
  (specification->package "r-ggplot2")))

then the bug is maybe worse because the exported manifest “works” but
without the transformation… which can be misleading and hard to detect.

Well, I understand it’s hard to capture this kind of transformation.
Still, it appears to me as an half-baked feature. :-)

That’s annoying in some context as “guix pack --save-provenance” [1].
Even, it defeats the idea of a self-contained reproducible binary
container. ;-)

Maybe, aside the profile ’manifest’ file, we could store all the
manifests provided by the command line.  Something as:

/gnu/store/-profile/manifest
/gnu/store/-profile/manifest.orig1
/gnu/store/-profile/manifest.orig2
…

where manifest.orig1 and manifest.orig2 are the copy of files ’foo.scm’
and ’bar.scm’ from:

-m foo.scm -m bar.scm

This way, the option --export-manifest could be improved.

WDYT?

Cheers,
simon

1: https://hpc.guix.info/blog/2021/10/when-docker-images-become-fixed-point

bug#73602: bug#73601: failed to compute the derivation for Guix

[Simon Tournier]

trap-binaries-0.drv
/gnu/store/ff107pg13nkarix7k9hgxxwx9cnn4602-module-import-compiled.drv

Well, please note that the hash of these derivations might vary but not
their output.  For instance,

# sed 's/]/\n]/g' \
   /gnu/store/38951a2gcwb4jyrwlzg634jfwkdih7m2-bootstrap-binaries-0.drv \   
  | head -1

Derive([("out","/gnu/store/az8fi8xzgvkqw9aynxks98h29afal6i2-bootstrap-binaries-0","","")

Here the hash ’3895…’ might be different but not ’az8fi8…’.  The same
derivation produces the same store item though.

Ok, let consider each.  I know that piping with “sed” is not handy and
an extension [2] ]is still pending… Anyway, please pipe the derivations
in order to extract the relevant information.


1. /gnu/store/…-guile-bootstrap: it only depends on fixed-outputs so the
only source of variation comes from the script builder: in my case,

/gnu/store/nmxl6qyj16bv4rx4irhg23r66gn752kd-build-bootstrap-guile.sh

I expect you have the same.  As root, you have because it’s the same
derivation, namely
/gnu/store/g08l2msvnivyi6x5nw52ak8n17sw9lzr-guile-bootstrap-2.0.drv.

What about the regular user?


2. /gnu/store/…-bootstrap-binaries: the inputs reads,

/gnu/store/ff107pg13nkarix7k9hgxxwx9cnn4602-module-import-compiled.drv
/gnu/store/g08l2msvnivyi6x5nw52ak8n17sw9lzr-guile-bootstrap-2.0.drv
/gnu/store/nf9h1l2apgjq1gjdv1ynpgqrmaj1bawb-static-binaries.tar.xz.drv
/gnu/store/sik0rp63q7hz4wry27v3ynljdmqvg194-xz.drv
/gnu/store/zn60yim3km5qx8d0vzvf9izfxzfdy4x0-tar.drv

Assuming #1 (identical guile-bootstrap) and the only non fixed-output is
module-import-compiled.  Or the script builder.

Do you have the same script builder, namely

  /gnu/store/kv2vjnp7f75wnq8rp579ihz96knqp0sl-bootstrap-binaries-0-builder

?  I guess you have the same.  Therefore, I guess the issue is from
module-import-compiled.


3. /gnu/store/…-module-import-compiled: On my machine, it reads:

--8<---cut here---start->8---
Derive
([("out","/gnu/store/j2r95mqfir1q6hsavm0r22k8z49nbvk1-module-import-compiled","","")]
 
,[("/gnu/store/g08l2msvnivyi6x5nw52ak8n17sw9lzr-guile-bootstrap-2.0.drv",["out"])]
 
,["/gnu/store/jsxgc979x79h81kzqz9n6cpf5pk4z262-module-import","/gnu/store/l36kgiw25r2a4vllwad18jg8jnkvmzda-build-utils.scm","/gnu/store/rn7b0dq6iqfmmqyqzamix2mjmfygn31n-compile-modules"]
 
,"x86_64-linux","/gnu/store/lgi9x15a0w35mcpd7g1kb9274r6wy4pv-guile-bootstrap-2.0/bin/guile",["--no-auto-compile","/gnu/store/rn7b0dq6iqfmmqyqzamix2mjmfygn31n-compile-modules"]
 ,[("GUILE_WARN_DEPRECATED","no")
   ,("extensions","")
   ,("module count","1")
   ,("modules","/gnu/store/jsxgc979x79h81kzqz9n6cpf5pk4z262-module-import")
   ,("optimization level","1")
   ,("out","/gnu/store/j2r95mqfir1q6hsavm0r22k8z49nbvk1-module-import-compiled")
   ,("preferLocalBuild","1")])
--8<---cut here---end--->8---

I guess you also have the same build-utils.scm.  Don’t you?

Therefore, I guess the difference is either an environment variable (the
list starting with GUILE_WARN_DEPRECATED) or the file
/gnu/store/…-qcompile-modules.  Hum, it would be weird that it comes
from compile-modules…


Ah my train is at destination.  To be continued… Let me know!

Cheers,
simon


1: Re: Derivations differ between computers?
zimoun 
Fri, 26 Nov 2021 01:49:00 +0100
id:86lf1bspvn@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2021-11
https://yhetil.org/guix/86lf1bspvn@gmail.cmo

2: Guix extension to display derivation (and rewrite fixed-output)
Simon Tournier 
Fri, 12 Apr 2024 20:28:11 +0200
id:87ttk6phac@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2024-04
https://yhetil.org/guix/87ttk6phac@gmail.com

bug#73602: failed to compute the derivation for Guix

[Simon Tournier]

Hi Fabrice,

> Unfortunately my GUIX is still in a bad mood or worst, since I have
> troubles with all users now.

Oh!  It means something is incorrectly configured for sure. :-(


> The issue is not limited to the "pull", I have also a problem with the
> command "guix package -i hello":

Yes, that’s expected.  Because you have a tiny difference really deep in
the graph of dependencies, and that difference triggers a complete world
rebuild.

> / 'build' phasebuilder for 
> `/gnu/store/3cc3xp9p4xdm1hkbxshcmwvk49vqg7jq-patch-mesboot-2.5.9.drv' failed 
> with exit code 1

Well, the fact MES (bootstrap) does not build for you is another
problem.  Somehow, it is known that the full-bootstrap [1] is sensible
to parameters as hardware for example.  If correctly configured, you
should not build from the start but just download substitutes.

> I will continue to dig in a little, but I wonder if a complete
> re-install could be an option ?

IMHO, for digging a bit, I would try to catch the difference.  We have
two tools at hand: derivation and builder script.

For instance, let go back to the previous email.  If I read correctly,
you get:

  /gnu/store/jc3vgcsplqsim3na80b0n2iilna5j6gx-Python-3.5.9.tar.xz.drv

but I cannot scrutinize it since I am not able to locally reproduce
it. :-)  Could you please share:

  cat 
/gnu/store/jc3vgcsplqsim3na80b0n2iilna5j6gx-Python-3-Python-3.5.9.tar.xz.drv \
  | sed 's/)/)\n/g'

?  This will list all the inputs.  The first thing is to check the
fixed-output: you must have,

  /gnu/store/lb5b7svdmfj1ijnzrripsjcv0bhqzpwb-Python-3.5.9.tar.xz.drv

If not, ouch!  Then you should have 3 inputs:

/gnu/store/38951a2gcwb4jyrwlzg634jfwkdih7m2-bootstrap-binaries-0.drv
/gnu/store/ff107pg13nkarix7k9hgxxwx9cnn4602-module-import-compiled.drv
/gnu/store/g08l2msvnivyi6x5nw52ak8n17sw9lzr-guile-bootstrap-2.0.drv

Which one is different?  None?  One?  More?  Based on that we can
restrict the space of research.

The other part is the script builder.  For me, it reads:

   /gnu/store/ykqckrxcmifvxz0nb58lv2drgd14l377-Python-3.5.9.tar.xz-builder

Is it the same?  If yes, we will focus on above.  If no, could you
attach the file?

Cheers,
simon

PS: Hum, I do not know why your reply is not visible by Debbugs… Anyway!
For the record and maybe the ease for referencing, here some information
I extract from my own inbox since I had been CC.

Message-ID: <8e618239-551a-4c1c-91b4-91a0fca98...@univ-rennes1.fr>
Date: Mon, 7 Oct 2024 15:49:36 +0200
References: 
In-Reply-To: <87y135ql8w@gmail.com>

1: https://simon.tournier.info/posts/2023-10-01-bootstrapping.html

bug#73601: failed to compute the derivation for Guix

[Simon Tournier]

Hi,

On mer., 02 oct. 2024 at 16:27, Fabrice Tudoret 
 wrote:

> [hjebbari@cluster24 ~]$ guix pull
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to a47d7af (2 new commits)...

Well, it’s confusing.  First the authentication reads from:

9edb3f66fd807b096b48283debdcddccfea34bad
AuthorDate: Tue May 26 22:30:51 2020 +0200
CommitDate: Tue May 26 22:30:51 2020 +0200
to:
a47d7af2273c2dbb5376e776b34e78a9146abbfe
AuthorDate: Sun Sep 29 02:00:00 2024 +0200
CommitDate: Sun Sep 29 02:00:00 2024 +0200

and there is more than 2 commits between them. ;-)  Therefore, something
is probably twisted under ~/.cache/guix

Second, based on this message, 

--8<---cut here---start->8---
guix pull: error: You found a bug: the program 
'/gnu/store/38agwh7x3v43jhl06ginx2080zc8isfj-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"a47d7af2273c2dbb5376e776b34e78a9146abbfe"; system: "x86_64-linux";
host version: "a8353e9d6b34fd8d42d2e8f14ce844849fe9c293"; pull-version: 1).
Please report the COMPLETE output above by email to.
--8<---cut here---end--->8---

The host revision seems:

a8353e9d6b34fd8d42d2e8f14ce844849fe9c293
AuthorDate: Sat Apr 6 09:32:09 2024 +0300
CommitDate: Mon Apr 15 12:32:42 2024 +0200

Hum?! this

  guix \
 time-machine -q --commit=a8353e9d6b34fd8d42d2e8f14ce844849fe9c293 \
  -- time-machine -q --commit=a47d7af2273c2dbb5376e776b34e78a9146abbfe \
  -- describe

works for me.


Third, 

> Building from this channel:
>guixhttps://git.savannah.gnu.org/git/guix.git  a47d7af

[...]

> building 
> /gnu/store/21c7pjahkh20mmzq2ivki57zwwvp6nwn-bootstrap-binaries-0.drv...
> building /gnu/store/ih5923dvfg64nlpibc4qfa22jkyqykrm-bootar-1b.drv...
> building 
> /gnu/store/jc3vgcsplqsim3na80b0n2iilna5j6gx-Python-3.5.9.tar.xz.drv...

[...]

> View build log at 
> '/var/log/guix/drvs/3c/c3xp9p4xdm1hkbxshcmwvk49vqg7jq-patch-mesboot-2.5.9.drv.gz'.

[...]

> Backtrace:
>    14 (primitive-load 
> "/gnu/store/38agwh7x3v43jhl06ginx2080zc8isfj-compute-guix-derivation")
> In ice-9/eval.scm:
>      155:9 13 (_ _)
>      159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) 
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
> In ice-9/boot-9.scm:
>      152:2 11 (with-fluid* _ _ _)
>      152:2 10 (with-fluid* _ _ _)
> In ./guix/store.scm:
>    2210:24  9 (run-with-store # 
> # ?)
>     2038:8  8 (_ #)
> In ./guix/gexp.scm:
>     300:22  7 (_ #)
>     1218:2  6 (_ #)
>     1085:2  5 (_ #)
>      926:4  4 (_ #)
> In ./guix/store.scm:
>    2095:12  3 (_ #)
>     1433:5  2 (map/accumulate-builds # 
> # ?)
>    1449:15  1 (_ # 
> ("/gnu/store/i9y8962w382ivw7n66i6vdj2dxg3qi7r-guix-daem?" ?) ?)
>    1449:15  0 (loop #f)
>
> ./guix/store.scm:1449:15: In procedure loop:
> ERROR:
>    1. &store-protocol-error:
>    message: "build of 
> `/gnu/store/r7qvm0ad2qxdm000mlfbr8c8wxw2jfvf-git-minimal-2.46.0.drv' failed"
>    status: 100

Ouch! Something seems twisted because all is rebuilt from bootstrap
although the substitutes are allowed, I guess.  In other words,
something is probably modified that modifies then the derivations.

For instance, I get:

$ guix \
 time-machine -q --commit=a8353e9d6b34fd8d42d2e8f14ce844849fe9c293
  -- time-machine -q --commit=a47d7af2273c2dbb5376e776b34e78a9146abbfe \
  -- build -e '(@@ (gnu packages commencement) python-boot0)' -S -d

/gnu/store/mbnrrqjizy3dvma9i3l8g5yvzi2p04ys-Python-3.5.9.tar.xz.drv

And not:

/gnu/store/jc3vgcsplqsim3na80b0n2iilna5j6gx-Python-3.5.9.tar.xz.drv


Well, if we give a look to the derivation, it reads:

--8<---cut here---start->8---
$ cat /gnu/store/mbnrrqjizy3dvma9i3l8g5yvzi2p04ys-Python-3.5.9.tar.xz.drv | sed 
's/)/)\n/g'

Derive([("out","/gnu/store/jl82wnklrfhjgnml3s3w0l4m4mjwpazb-Python-3.5.9.tar.xz","","")
],[("/gnu/store/38951a2gcwb4jyrwlzg634jfwkdih7m2-bootstrap-binaries-0.drv",["out"])
,("/gnu/store/ff107pg13nkarix7k9hgxxwx9cnn4602-module-import-compiled.drv",["out"])
,("/gnu/store/g08l2msvnivyi6x5nw52ak8n17sw9lzr-guile-bootstrap-2.0.drv",["out"])
,("/gnu/store/lb5b7svdmfj1ijnzrripsjcv0bhqzpwb-Python-3.5.9.tar.xz.drv",["out"])
],["/gnu/store/jsxgc979x79h81kzqz9n6cpf5pk4z262-module-import","/gnu/store/ykqckrxcmifvxz0nb58lv2drgd14l377-Python-3.5.9.tar.xz-builder"],"x86_64-linux","/gnu/store/lgi9x15a0w35mcpd7g1kb9274r6wy4pv-guile-bootstrap-2.0/bin/guile",["--no-auto-compile","-L","/gnu/store/jsxgc979x79h81kzqz9n6cpf5pk4z262-module-import","-C","/gnu/store/j2r95mqfir1q6hsavm0r22k8z49nbvk1-module-import-compiled","/gnu/store/ykqckrxcmifvxz0nb58lv2drgd14l377-Python-3.5.9.tar.xz-builder"],[("guix
 properties","((type . origin)
 (patches . 0)
)
")
,("out","/gnu/store/jl82wnklrfhjgnml3s3w0l4m4mjwpazb-Python-3.5.9.tar.xz")
])
--8<--

bug#55032: Bug from guix pull

[Simon Tournier]

Hi,

On mer., 11 sept. 2024 at 06:31, "Yuxuan 'fishy' Wang"  wrote:

>> Well, I am in favor to close this report.  And if you have the problem
>> again, you could open another issue.  WDYT?
>
> Sounds good to me. Feel free to close this report. Thanks for the reply!

Closed.

Thanks,
simon

bug#58838: Bug report

[Simon Tournier]

Hi,

On mar., 10 sept. 2024 at 12:14, EricR Rasmussen  
wrote:
> On Tue, Sep 10, 2024, 11:19 AM Simon Tournier  
> wrote:
>
> Yeah, this issue is resolved. LOL. Thanks.

Thanks for your reply.

>> Well, I am in favor to close this report.  WDYT?

Closing.

Thanks,
simon

bug#69550: smithforth: missing source (?)

[Simon Tournier]

Hi,

On mar., 10 sept. 2024 at 09:37, Christopher Howard 
 wrote:
> Simon Tournier  writes:
>
>> Therefore, you can run:
>>
>> $ guix build smithforth --sources=all
>> /gnu/store/4w4v7zv4vif2k55g9srmv57fg5icpl94-SForth220711dmp.txt
>> /gnu/store/lvrkhx3yzjk58ma99vyp0blvr2whbvpr-system220711fs.txt
>>
>> However, this does not work as-is yet; you need
>> <https://issues.guix.gnu.org/73073>.
>>
>> Well, I think that’s not a bug.  WDYT?  Closing?

Since it’s not a bug, closing.


> My first thought would be to merge this bug into 73073, if that is
> possible, so folks looking at 73073 can see the connection to this
> report. 

I would prefer to not add to the already long thread. :-)

For future cross-reference, here details:

[bug#73073] [PATCH 0/6] Allow origin with label as inputs.
Simon Tournier 
Fri, 06 Sep 2024 17:51:14 +0200
id:cover.1725636992.git.zimon.touto...@gmail.com
https://issues.guix.gnu.org/73073

https://issues.guix.gnu.org/msgid/cover.1725636992.git.zimon.touto...@gmail.com
https://yhetil.org/guix/cover.1725636992.git.zimon.touto...@gmail.com

Cheers,
simon

bug#73314: PyPI importer gives null at home-page for some packages

[Simon Tournier]

Hi,

On mar., 17 sept. 2024 at 14:23, Evgeny Pisemsky  wrote:
> For example, this command:
>
> guix import pypi snitun@0.35.0

That’s probably because the JSON file metadata stored in PyPI does not
have the information.

Well, do you prefer #false in order to be consistent with the rest, as
license for instance?

Cheers,
simon

bug#59196: `guix pull` fails on A20-OLinuXino-LIME2-eMMC

[Simon Tournier]

Hi Tanguy,

On jeu., 12 sept. 2024 at 08:33, Tanguy LE CARROUR  wrote:

>> What is the status of this bug report?
>
> As I mentioned: "I think I'll redirect my energy to other tasks for the time 
> being…"
> That’s exactly what I did!… and forgot to close the bug! 😅
> Should I just do that?

Closed.

Thanks,
simon

bug#55554: A bug of guix in the MX/Distro

[Simon Tournier]

Hi,

On Tue, 10 Sept 2024 at 18:19, Simon Tournier  wrote:

> Well, I am in favor to close it.  WDYT?

In agreement with Victor's private message, closing.

Cheers,
simon

bug#67979: guix pull failed with error

[Simon Tournier]

Hi,

On dim., 15 sept. 2024 at 15:08, Wensheng Xie  wrote:
> On 二, 2024-09-10 at 16:04 +0200, Simon Tournier wrote:

>> What happens if you run:

[...]

> Thank you for looking into this bug.
>
> After I changed my channel to the official guix channel (slower), the
> problem is solved.

Thanks for your reply.  Closing.

Cheers,
simon

bug#73292: “guix shell --pure“ displays twice the same warning

[Simon Tournier]

Hi,

--8<---cut here---start->8---
$ guix shell --pure
guix shell: warning: no packages specified; creating an empty environment
guix shell: warning: no packages specified; creating an empty environment
--8<---cut here---end--->8---

That’s because: one is from ’auto-detect-manifest’ in (guix scripts
shell):

  (if (or (not interactive?)
  disallow-implicit-load?
  (options-contain-payload? opts))
  opts
  (match (find-file-in-parent-directories '("manifest.scm" "guix.scm"))
(#f
 (warning (G_ "no packages specified; creating an empty environment~%"))
 opts)

called by ’parse-args’ called by the entry-point command ’guix-sell’.

And another one is from ’guix-environment*’ in (guix scripts
environment):

(when (null? (manifest-entries manifest))
  (warning (G_ "no packages specified; creating an empty 
environment~%")))

called by the entry-point command ’guix-shell’.

Well, since ‘guix environment’ is deprecated, I would suggest to remove
the warning in ’guix-environment*’.  It would improve the “polish”.

Cheers,
simon

Reported by @lynn...@tech.lgbt from Mastodon. :-)

bug#70689: guix search doesn't weigh word matches higher than subword matches

[Simon Tournier]

Hi,

On Tue, 30 Apr 2024 at 22:18, Richard Sent  wrote:

>> Inetutils is a collection of common network programs, such as an ftp
>> client and server, a telnet client and server, an rsh client and
>> server, and hostname.
>
> Most likely, this is what the user is interested in. However, inetutils
> does not show up until roughly the ~75th result with a relevance of 2
> (the lowest possible relevance).

Using Guix 056910e, I get:

$ guix search rsh | recsel -CP name | grep -n inetutils
76:inetutils

Then using the proposed v2 patch#73220 [1], I get:

$ ./pre-inst-env guix search rsh | recsel -CP name | grep -n inetutils
34:inetutils

Well, that’s not perfect but a bit better.


> Almost every search result beforehand contains the string "rsh" as a
> component of another word, such as "marshaling", "powershell", and
> "hershey". However, these match multiple times and are weighted
> significantly higher.

Well, if we consider the current implementation, the relevance scoring
reads for the highest:

  4 * 0   name
+ 2 * 0   upstream-name
+ 1 * 0   outputs
+ 3 * 2 * 1   synopsis
+ 2 * 4 * 1   description
+ 1 * 0   file-name
= 14

where it means: field-weigh * match * weight-match

Compared to inetutils:

  4 * 0   name
+ 2 * 0   upstream-name
+ 1 * 0   outputs
+ 3 * 0   synopsis
+ 2 * 1 * 1   description
+ 1 * 0   file-name
= 2

Well, this case cannot be improved much.  First, the field-weights are
almost optimal [2]. Second the number of occurrences depends on the
description; maybe it could be improved, I have not checked yet.

And v2 of #73220 replace the value of weight-match: the term ’rsh’ in
“an rsh client” should have an higher score than in “uses `json.Marshal'
and `json.Unmarshal'”.

In other words, it reads:

  4 * 0   name
+ 2 * 0   upstream-name
+ 1 * 0   outputs
+ 3 * 0   synopsis
+ 2 * 1 * 3   description
+ 1 * 0   file-name
= 6

I think this address your suggestion, I guess.


> Ideally, guix search should rate inetutils higher because the string
> "rsh" occurs as its own word, not as a component of another, unrelated
> word. (Very, very people would search "rsh" looking for matches with
> "hershey", even if "hershey" occurs multiple times.)

Again, considering the case at hand: If instead of 3 randomly picked in
v2 of #73220, we would pick 7, then inetutils is ranked first.

Yeah, maybe 3 isn’t enough… And maybe 7 is a good choice.

Do you have other examples than ’rsh’?


> Another example of where this can happen is with "dig", part of the bind
> package. Searching for "dig" returns garbage because "dig" is a common
> subword. Bind is scored with a relevance of 2, even though bind's
> description emphasises that dig is part of it.

Please note that using v2 of #73220 with the weight of 7, the package is
returned “third“: a relevance of 14 (behind 24 and 20).

However, it appears 8th in the list because the appearance for packages
having the same relevance scoring is arbitrary.  It just depends on how
the modules are walked.  Therefore, we cannot do much, IMHO.


Cheers,
simon


1: https://issues.guix.gnu.org/73220#1

2: Re: Search improvements (Was: Opposition to new single-letter package name 
"t")
zimoun 
Tue, 09 Mar 2021 19:37:23 +0100
id:CAJ3okZ3+hn0nJP98OhnZYLWJvhLGpdTUK+jB0hoM5JArQxO=z...@mail.gmail.com
https://lists.gnu.org/archive/html/guix-devel/2021-03
https://yhetil.org/guix/CAJ3okZ3+hn0nJP98OhnZYLWJvhLGpdTUK+jB0hoM5JArQxO=z...@mail.gmail.com

bug#56836: guix pull: error: You found a bug: the program...

[Simon Tournier]

Hi,

On Fri, 29 Jul 2022 at 17:52, DDC  wrote:

> guix pull: error: You found a bug: the program
> '/gnu/store/5xv3aac4lkfvvgyhs65l7a3r809h6iaj-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "d1c6b8db5a30f9e428d018156dadb12927c485f8"; system: "x86_64-linux";
> host version: "212ca81895b2baa819ea11a308ad21880b84a546"; pull-version: 1).
> Please report the COMPLETE output above by email to .

Well, this error is probably transient.  Is it?

If yes, I’m in favor to close.  WDYT?

Cheers,
simon

bug#64963: guix pull bug

[Simon Tournier]

Hi,

On Sun, 30 Jul 2023 at 23:07, Jordan Russell  
wrote:

> One bit of context about this bug is I was running dnf update at the
> same time as this ocurred. re-running guix pull later failed to
> repdroduce the bug.

Sadly, most of the time, errors happening with “guix pull” are transient
and hard to reproduce.

Therefore, closing.  Thanks for the report.

Cheers,
simon

bug#69070: ‘guix lint -c archival python-scikit-learn’ crashes

[Simon Tournier]

Hi Ludo,

On Mon, 12 Feb 2024 at 11:11, Ludovic Courtès  wrote:

> (Note that this problem may vanish once
>  has been merged.)

This had been merged.  Now, it does not crash.  Is the problem hidden or
vanished?

Cheers,
simon

bug#63830: guix pull error

[Simon Tournier]

Hi,

Sorry for the late reply.

On Fri, 02 Jun 2023 at 14:22, Aaron Ash  wrote:

> guix pull: error: You found a bug: the program
> '/gnu/store/9l6gwizqlnnrm6yhw5ff7nk5ngfqbyc2-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "b4382b294e6cd475e9476610d98fdd0bdaec4c84"; system: "x86_64-linux";
> host version: "22d44f87763f86a05e9679d9ad2c99e17f4c79be"; pull-version: 1).
> Please report the COMPLETE output above by email to .

Most of the time, it’s transient.  If you run again:

guix pull --commit=b4382b294e6cd475e9476610d98fdd0bdaec4c8

then it should pass.  Is it ok?

Cheers,
simon

bug#61542: emacs-next doesn't load .eln files

[Simon Tournier]

Hi,

On Thu, 16 Feb 2023 at 02:11, "ytc"  wrote:

> Hello.  I've noticed that when I install Emacs packages with
> `--with-input=emacs-minimal=emacs-next' transformation option, Emacs
> cannot load native compiled files.  The reason might be that the
> byte-compiled files of those packages couldn't be found.  Could you
> please look into this problem?

Please note that ’emacs’ supports native compilation.

That’s said, you cannot build an Emacs package using one Emacs version
and use the result using another Emacs version.  In other words, the
Emacs package must be native compiled with the same Emacs version that
will load it.

And AFAIK, the Emacs packages are not yet native compiled at build time,
only bytecompiled.  See [1] for patches allowing that.

Well, I am in favor to close this report since the wish is tracked by
patch submission #72406 [1].  WDYt?

Cheers,
simon


1: [bug#72406] [PATCH emacs-team WIP 0/4] Simplify creation of emacs package 
variants
Liliana Marie Prikler 
Wed, 31 Jul 2024 21:58:49 +0200
id:cover.1722455929.git.liliana.prik...@gmail.com
https://issues.guix.gnu.org/72406
https://issues.guix.gnu.org/msgid/cover.1722455929.git.liliana.prik...@gmail.com
https://yhetil.org/guix/cover.1722455929.git.liliana.prik...@gmail.com

bug#55554: A bug of guix in the MX/Distro

[Simon Tournier]

Hi,

Sorry for the late reply and thank you for the report.

On Fri, 20 May 2022 at 22:31, Victor H  wrote:
> HI:
> I get a bug while doing "guix pull"
> I hope the output in the file I send could be useful.

More than often, this error is transient coming from network
(substitutes side, your side, or both sides) and running again “guix
pull”, even targeting the same revision, makes it pass.

Well, I am in favor to close it.  WDYT?

Cheers,
simon

bug#58013: Can't use guix pull

[Simon Tournier]

Hi,

On Sun, 25 Sep 2022 at 13:23, zimoun  wrote:

> Hum, was the initial report done using the root account?
>
> Because it appears more than weird that Guix fails with the sequence
>
> guix describe -f channels > channels.scm
> guix time-machine -C channels.scm -- help
>
> which is what you are reporting.

What is the status of this bug report?

Cheers,
simon

bug#56681: Guix error report

[Simon Tournier]

Hi,

Sorry for the very late reply.  Thanks for the report.

On Thu, 21 Jul 2022 at 17:21, Kevin Morris  wrote:

> guix pull: error: You found a bug: the program 
> '/gnu/store/lm4i0rd29gxfahw904gndpwpii7q2qj7-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "3f171587bc6a47bb056f3e699e17e05f5832aea5"; system: "x86_64-linux";
> host version: "1.3.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

More than often, this error is transient.  I guess “guix pull” passed
when you ran it again, right?

Somehow, after the failure, running:

  guix pull --commit=3f171587bc6a47bb056f3e699e17e05f5832aea5

makes it pass, most of the time.

Well, I’m in favor to close it.  WDYT?

Cheers,
simon

bug#59876: Bug.

[Simon Tournier]

Hi,

Sorry for the late reply.

On Thu, 08 Dec 2022 at 01:38, Ping Pong  wrote:

> That is as much as I can remember.

Ah, so it’d be near to impossible to tackle this. :-)

I’m closing.  Feel free to reopen or raise your hand if I am missing
something.

Cheers,
simon

bug#55032: Bug from guix pull

[Simon Tournier]

Hi,

Thank you for the report and sorry for the very late reply.

On Tue, 19 Apr 2022 at 22:04, Yuxuan 'fishy' Wang  wrote:

> guix pull: error: You found a bug: the program 
> '/gnu/store/zgzaz6c723pjkykiqnpnqr9rmylf69dq-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "ffb616b69dced25b840f2e5178062072d89623eb"; system: "x86_64-linux";
> host version: "6b677f4299f38ea70e1852388086ee95c2c48622"; pull-version: 1).
> Please report the COMPLETE output above by email to .

More than often, the error is transient and running again “guix pull”
makes it pass.  We are aware of various sources that lead to such error
(network, memory, etc.).

Well, I am in favor to close this report.  And if you have the problem
again, you could open another issue.  WDYT?

Cheers,
simon

bug#55884: I have a problem wıth my computer

[Simon Tournier]

Hi User Googlov,

Sorry for the vert late reply.

On Fri, 10 Jun 2022 at 17:39, Maxime Devos  wrote:

> User Googlov schreef op do 09-06-2022 om 20:26 [-0800]:
>> Hello, I can't update my computer. The site https://guix.gnu.org/ is
>> not available in my country. I don't know if IP address or domain
>> name is blocked.
>
> See
> 
> for information and a work-around.
> Alternatively, you can do "guix pull --no-substitutes", at cost of
> having to compile more locally.

Does the message sent to help-guix mailing list helps you to work around
some internet blocker?

Cheers,
simon

bug#60547: guix pull: Error in procedure 'get-bytevector-n*'

[Simon Tournier]

Hi,

Sorry for the late reply.

On Wed, 04 Jan 2023 at 15:12, "Artyom V. Poptsov"  
wrote:

> guix pull: error: You found a bug: the program 
> '/gnu/store/w1286dmwlhha7gp09s50w8fpx9rs1qi4-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "d62c65d5ad49d3bf7ae24b31743d96241170faca"; system: "x86_64-linux";
> host version: "9cb42f725a2a652bb41e38988d03d7020ccf2aa1"; pull-version: 1).
> Please report the COMPLETE output above by email to .

Are you able to reproduce it?  If not, I think it’s transient and the
bug is not actionable, thus closing?

Cheers,
simon

bug#58838: Bug report

[Simon Tournier]

Hi,

Sorry for the very late reply.  Thanks for the report.

On Thu, 27 Oct 2022 at 18:18, EricR Rasmussen  
wrote:

> guix pull: error: You found a bug: the program 
> '/gnu/store/kiiasri3ygd4c6k3r9ljyf0m2mcnidhs-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "d520fdec3c7a11bc70ab83d0ebc6372389992d04"; system: "x86_64-linux";
> host version: "3734857fc55df2c599c2fe5cc4ae49f5d47879fc"; pull-version: 1).
> Please report the COMPLETE output above by email to .

More than often, it’s a transient error.  Well, I guess that years
later, it does not matter much. :-)

Well, in case.  Most of the time, when you run again, e.g.,

  guix pull --commit=d520fdec3c7a11bc70ab83d0ebc6372389992d04

then it passes.

Well, I am in favor to close this report.  WDYT?

Cheers,
simon

bug#55933: Fails download of quix 1.3 virtual machine

[Simon Tournier]

Hi,

Very late… Well hunting old bugs. :-)

On Sun, 12 Jun 2022 at 23:14, Tobias Geerinckx-Rice  wrote:

> Thanks for the report.  I'm CC'ing  as documented here[0] to get
> their opinion.

[...]

> However, there does seem to be an inconsistency with the GNU FTP server:
>
> ~ λ curl -LI
> https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.x86_64-linux.iso |
>grep Content-Type
> X-Content-Type-Options: nosniff
> Content-Type: application/x-iso9660-image
>
> ~ λ curl -LI
> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2 |
>grep Content-Type
> X-Content-Type-Options: nosniff
>
> The QCOW2 response is missing a Content-Type, whilst asking browsers not to
> sniff it for themselves.  Apparently your browser is making an exceptionally
> bad call.

I get:

--8<---cut here---start->8---
$ curl -LI  
https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.x86_64-linux.qcow2 | 
grep Content-Type
Content-Type: text/html; charset=iso-8859-1
--8<---cut here---end--->8---

Does it mean the issue is gone?

Cheers,
simon

bug#59196: `guix pull` fails on A20-OLinuXino-LIME2-eMMC

[Simon Tournier]

Hi Tanguy,

On Fri, 11 Nov 2022 at 18:53, Tanguy LE CARROUR  wrote:

> /guix pull: error: You found a bug: the program 
> '/gnu/store/mbs3lc77zy30nr82lnn2s135i2rvq095-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "ba8679fb2452f4466a98a99edf050ea7452c83f4"; system: "armhf-linux";
> host version: "1.2.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

What is the status of this bug report?

Cheers,
simon

bug#64090: Cannot compute a file with a G-exp

[Simon Tournier]

Hi,

On Sat, 17 Jun 2023 at 17:27, "("  wrote:
> Robby Zambito  writes:
>> Strangely with-extensions doesn't seem to be including the whole
>> dependency tree for me. Should it?
>
> No, I don't think it should. It *would* be possible to traverse the
> package inputs and add all the GUILE-BUILD-SYSTEM-using packages, but
> then you get the problem that not all Guile packages have their
> dependencies specified in the INPUTS list (for some reason, IIRC, you
> need the Guile dependencies to be in both INPUTS *and* NATIVE-INPUTS,
> but some have them only in NATIVE-INPUTS).
>
> The problem there is that if you have a dependency that's only in
> NATIVE-INPUTS, it's difficult to tell if it's actually used by the
> application or by, say, a build script.

Reading the thread and from my understanding, there is no bug.  Closing?

Else, could you provide more information about the bug?

Cheers,
simon

bug#72495: `guix --version` not really helpful

[Simon Tournier]

Hi,

On Tue, 06 Aug 2024 at 12:14, Stéfane Fermigier  wrote:
> When I type:
>
> guix --version
>
> I get:
>
> guix (GNU Guix) 6689a96ce86497299bd29f183b744116fd2d6e32
>
> That's not really helpful (i.e. it doesn't tell how old / up to date my 
> system is). A proper version number (e.g. "x.y.z-devel", etc.) and/or a date
> would be nice.

Maybe what you want is “guix describe”.  For instance, it outputs:

$ guix describe
Generation 8Sep 09 2024 15:14:29(current)
  guix 056910e
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 056910ec864cb7cf3225a0c27679d94405db7dcd

It does not tell how old or up-to-date your system is but it informs you
about your last “guix pull”.  It seems a good starts.

About a proper version number, I am not convinced it suits well some
rolling-release.  Troll inside. ;-)

Cheers,
simon

bug#56580: 1.3.0 internet connectivity bug

[Simon Tournier]

Hi Peter,

Sorry for the very late reply.

On Fri, 15 Jul 2022 at 15:59, Peter  wrote:

> For some bizarre reason, even though it worked last night, today the
> 1.3.0 usb could no longer establish an internet connection on the
> intel wired ethernet. Just a red screen saying no connectivity.
>
> The issue is specific to 1.3.0. The other OSes could use the lan fine,
> and the GUIX snapshot image was able to establish an internet
> connection fine.

Well, I am not sure to understand.  Could you provide more information
or is it too late? :-)

Cheers,
simon

bug#60648: guix pull command fails

[Simon Tournier]

Hi,

Sorry for the late reply.

On Sun, 08 Jan 2023 at 07:18, Girish M  wrote:

> guix pull: error: You found a bug: the program
> '/gnu/store/x2lwzisrlg1w6s4giayjzgfy9rzhly5b-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "17a672524e44ec11847ec166c51731c7ada7ce99"; system: "x86_64-linux";
> host version: "35b176daf1a466f136f0b77c03de78f482a30702"; pull-version: 1).

Is the bug reproducible?  If not, I think it’s transient and the bug is
not actionable, thus closing?

Cheers,
simon

bug#55932: error report

[Simon Tournier]

Hi,

Sorry for the very late reply and thank you for the report.

On Sun, 12 Jun 2022 at 19:45, Anedroid  wrote:

> ERROR:
>   1. &http-get-error:
>   uri: #< scheme: https userinfo: #f host: "ci.guix.gnu.org"
> port: #f path: "/nar/lzip/gkjna040y14xvk4y5mcccvjkkmdcvmnv-font-dejavu-
> 2.37" query: #f fragment: #f>
>   code: 502
>   reason: "Bad Gateway"
>   headers: ((server . "nginx") (date . # 5 minute: 23 hour: 17 day: 12 month: 6 year: 2022 zone-offset: 0>)
> (content-type text/html) (content-length . 150) (connection keep-
> alive))
>   2. &message: "
> https://ci.guix.gnu.org/nar/lzip/gkjna040y14xvk4y5mcccvjkkmdcvmnv-font-dejavu-2.37
> : HTTP download failed: 502 (\"Bad Gateway\")"

Well, I guess the error had been transient.  Closing.

Feel free to reopen or raise a voice if I miss something.

Cheers,
simon

bug#69550: smithforth: missing source (?)

[Simon Tournier]

Hi,

On Mon, 04 Mar 2024 at 10:07, Christopher Howard  
wrote:

> ``` guix build -S smithforth
> /gnu/store/4w4v7zv4vif2k55g9srmv57fg5icpl94-SForth220711dmp.txt
> ```
>
> ...I only get the annotated header/opcode file. However, the forth system 
> provided in the binary includes also the words defined here:
>
> {https://dacvs.neocities.org/SF/system220711fs.txt}
>
> It seems to me that `guix build -S' should return both these files in some 
> form. Maybe in a tar file...?

No, “guix build -S” returns the ’source’ of the package, i.e., only one
’origin’.  Here it reads:

(source
  (origin
(method url-fetch)
(uri (string-append "https://dacvs.neocities.org/SF/SForth";
version "dmp.txt"))
(sha256
  (base32 "0a39pv7529llsa3f48fmvwvlcp3f9v8qkn5ziw2l6kxf0qvli3lm"

The other is listed as inputs:

(native-inputs (list xxd
 (origin
   (method url-fetch)
   (uri (string-append
 "https://dacvs.neocities.org/SF/system";
 version "fs.txt"))
   (sha256
(base32
 
"17v1pp64s6n8q8w3kg48nd7zdcx2208y4svr5fpfms5lkyzg7z1m")

Therefore, you can run:

--8<---cut here---start->8---
$ guix build smithforth --sources=all
/gnu/store/4w4v7zv4vif2k55g9srmv57fg5icpl94-SForth220711dmp.txt
/gnu/store/lvrkhx3yzjk58ma99vyp0blvr2whbvpr-system220711fs.txt
--8<---cut here---end--->8---

However, this does not work as-is yet; you need
.

Well, I think that’s not a bug.  WDYT?  Closing?

Cheers,
simon

bug#64059: Sudden unexplained error during guix pull: "channel dependency has an invalid introduction field"

[Simon Tournier]

Hi,

On Fri, 23 Jun 2023 at 01:37, "N. Y."  wrote:

>>  I've purposefully added this new error to warn users that their
>>  .guix-channel's introduction forms were erroneous.  Previously, they
>>  were silently being dropped.  The formats in a channels.scm file and in
>>  the .guix-channel file are *not* the same!  Please see "(guix) Declaring
>>  Channel Dependencies" for an example of the format.

[...]

> Thank you so much for your help! Indeed, the .channels.scm files of my
> custom channels had invalid introduction fields. That's on me --- I
> should've read the error message more carefully!

Therefore closing.

Feel free to reopen if I have misunderstood.

Cheers,
simon

bug#67979: guix pull failed with error

[Simon Tournier]

Hi,

On Sat, 23 Dec 2023 at 08:46, Wensheng Xie  wrote:
> Here is the information from terminal:
>
> guix pull: compressing cached Git repository at 
> '/home/wxie/.cache/guix/checkouts/vkjy73mbbefpvcinhoaz3khygyu6zo4yxnr3orf75523s3fldlvq'...
> guix pull: Fehler: 
> '/gnu/store/xg500s4zygcgl94188bi15n8qhm54q9y-git-minimal-2.41.0/bin/git -C 
> /home/wxie/.cache/guix/checkouts/vkjy73mbbefpvcinhoaz3khygyu6zo4yxnr3orf75523s3fldlvq
>  gc' exited with status 128; output follows:

What happens if you run:

--8<---cut here---start->8---
$ guix shell git
   \
  -- git
   \
  -C 
/home/wxie/.cache/guix/checkouts/vkjy73mbbefpvcinhoaz3khygyu6zo4yxnr3orf75523s3fldlvq
 \
  gc
--8<---cut here---end--->8---

Cheers,
simon

bug#71625: build of /gnu/store/5mzanz9linxs05ypxf1fil639gs2nard-guix-package-cache.drv failed

[Simon Tournier]

Hi,

Sorry for the late reply.

On Mon, 17 Jun 2024 at 23:41, dan...@tutanota.com wrote:

> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value 
> (linux-libre-headers-6.8)) (value #f))

It means you have one channel that does not define this
’linux-libre-headers-6.8’ symbol (one package I guess).

Well, if you are still able to reproduce the bug, could you provide the
information:

 1. Do you have only the main Guix channel?  Or do you have extra
channels?

 2. Could you provide the revision you are targetting?


Cheers,
simon

bug#72984: Acknowledgement (wine64 fails to build: guix/build/utils.scm:761:4: In procedure alist-cons-after: Throw to key `match-error' with args `("match" "no matching pattern" ())'.)

[Simon Tournier]

Hi,

On Mon, 02 Sep 2024 at 21:26, "Dr. Arne Babenhauserheide" via Bug reports for 
GNU Guix  wrote:

> Fixed by https://issues.guix.gnu.org/72922

Therefore, closing?

Cheers,
simon

bug#72872: Learning Debbugs - documentation unclear - test

[Simon Tournier]

Hi jgart,

On Thu, 29 Aug 2024 at 12:36, jgart via Bug reports for GNU Guix 
 wrote:

> I recommend to use mumi instead of debbugs. Debbugs is confusing.

You cannot avoid Debbugs. ;-)  Debbugs is the name of the issue tracker
system [1].  And Mumi is one front-end.

Other front-ends are: plain emails, debbugs.el, issues.guix.gnu.org, or
BTS (debian-devscripts-bts), etc.

Mumi rocks! BTW.

Cheers,
simon

1: https://en.wikipedia.org/wiki/Debbugs

bug#73030: bug#73076: Inputs for git:send-email

[Simon Tournier]

Hi Andreas,

On Fri, 06 Sep 2024 at 18:15, Andreas Enge  wrote:

> I think this may be a consequence of the recent core-updates merge.

Duplicate of .

Fixed by acba6223b5268ece0c6cb4b1ce346f5dc5e8affc.

Closing.

Cheers,
simon

bug#73030: git send-email missing perl packages [partially FIXED]

[Simon Tournier]

Hi,

For the fixes see <https://issues.guix.gnu.org/73034>.

Explanation below.

On Wed, 04 Sep 2024 at 20:57, Simon Tournier  wrote:

> --8<---cut here---start->8---
> Not using SSL_VERIFY_PEER due to out-of-date IO::Socket::SSL.
> To use SSL please install IO::Socket::SSL with version>=2.007 at 
> /gnu/store/v6bivyjbg6bj07s8iqfzdm6hpvypc0p1-perl-5.36.0/lib/perl5/5.36.0/Net/SMTP.pm
>  line 268.
> --8<---cut here---end--->8---

It is a regression introduced in core-updates, recently merged,

f2886044: gnu: git: Remove labels and use gexps.

Well, it was not straightforward to spot the bug. :-) Especially when
’git bisect’ is useless.  Therefore, I locally reverted all the 8
suspicious commits modifying packages as git or git-minimal and then
investigated one by one.

Once the culprit had been identified, it was easier to spot the
unexpected part.  Roughly, this snippet:

   ;; Tell 'git-send-email' where perl modules are.
   (wrap-program git-se*
 `("PERL5LIB" ":" prefix
   ,(map (lambda (o) (string-append o "/lib/perl5/site_perl"))
 (list
  ,@(transitive-input-references
 'inputs
 (map (lambda (l)
(assoc l (package-inputs this-package)))
  '("perl-authen-sasl"
"perl-net-smtp-ssl"
"perl-io-socket-ssl")))

had been translated into:

;; Tell 'git-send-email' where perl modules are.
(wrap-program git-se*
  `("PERL5LIB" ":" prefix
,(search-path-as-list
  '("lib/perl5/site_perl")
  '#$(delete-duplicates
  (append-map
   (compose last package-transitive-propagated-inputs)
   (list (this-package-input "perl-authen-sasl")
 (this-package-input "perl-net-smtp-ssl")
 (this-package-input "perl-io-socket-ssl")))

The former essentially reads:

--8<---cut here---start->8---
scheme@(guix-user)> ,use(gnu packages version-control)
scheme@(guix-user)> (define this-package git)
scheme@(guix-user)> ,pp (transitive-input-references
 'inputs
 (map (lambda (l)
(assoc l (package-inputs this-package)))
  '("perl-authen-sasl"
"perl-net-smtp-ssl"
"perl-io-socket-ssl")))
$1 = ((assoc-ref inputs "perl-authen-sasl")
 (assoc-ref inputs "perl-net-smtp-ssl")
 (assoc-ref inputs "perl-io-socket-ssl")
 (assoc-ref inputs "perl-gssapi")
 (assoc-ref inputs "perl-digest-hmac")
 (assoc-ref inputs "perl-uri")
 (assoc-ref inputs "perl-net-ssleay"))
--8<---cut here---end--->8---

and the last essentially reads:

--8<---cut here---start->8---
scheme@(guix-user)> ,use(srfi srfi-1)
scheme@(guix-user)> (define (this-package-input name) (or (lookup-package-input 
this-package name) (lookup-package-native-input this-package name)))
scheme@(guix-user)> ,pp (append-map
   (compose last package-transitive-propagated-inputs)
   (list (this-package-input "perl-authen-sasl")
 (this-package-input "perl-net-smtp-ssl")
 (this-package-input "perl-io-socket-ssl")))
$2 = ("perl-gssapi"
 #
 "perl-net-ssleay"
 #
 "perl-uri"
 #)
--8<---cut here---end--->8---

Because ’last’ is applied before ’append-map’, it keeps only the last
elements of all the propagated-inputs for each of the 3.  For instance:

--8<---cut here---start->8---
scheme@(guix-user)> (package-transitive-propagated-inputs (this-package-input 
"perl-authen-sasl"))
$3 = (("perl-digest-hmac" #) ("perl-gssapi" #))
--8<---cut here---end--->8---

When what is needed is all the package objects.  Therefore, it’s not
possible to compose.

--8<---cut here---start->8---
scheme@(guix-user)> 

bug#73030: git send-email missing perl packages

[Simon Tournier]

Hi,

Using the fix , I get this error:

--8<---cut here---start->8---
Need MIME::Base64 and Authen::SASL todo auth at 
/gnu/store/imnyk8h2s6qfwd602n5vqxax8h33j2k5-git-2.45.2-send-email/libexec/git-core/.git-send-email-real
 line 1655.
--8<---cut here---end--->8---

My bad!

The issue is that ’package-transitive-propagated-inputs’ does not return
the package itself but only the dependent ones.  Hence the explicit
dependents packages themselves are therefore missing.

Here, the snippet that fixes.

--8<---cut here---start->8---
scheme@(guix-user)> ,pp (delete-duplicates
(let ((these-inputs
   (list (this-package-input "perl-authen-sasl")
 (this-package-input 
"perl-net-smtp-ssl")
 (this-package-input 
"perl-io-socket-ssl"
  (append
   these-inputs
   (map last
(append-map
 package-transitive-propagated-inputs
 these-inputs)
$4 = (#
 #
 #
 #
 #
 #
 #)
--8<---cut here---end--->8---

compared to:

(assoc-ref inputs "perl-authen-sasl")
(assoc-ref inputs "perl-net-smtp-ssl")
(assoc-ref inputs "perl-io-socket-ssl")
(assoc-ref inputs "perl-gssapi")
(assoc-ref inputs "perl-digest-hmac")
(assoc-ref inputs "perl-uri")
(assoc-ref inputs "perl-net-ssleay")

Therefore, see v2.

Cheers,
simon

bug#73030: git send-email missing perl packages

[Simon Tournier]

Hi,

Using Guix 7fa9df4, I get the error:

--8<---cut here---start->8---
Not using SSL_VERIFY_PEER due to out-of-date IO::Socket::SSL.
To use SSL please install IO::Socket::SSL with version>=2.007 at 
/gnu/store/v6bivyjbg6bj07s8iqfzdm6hpvypc0p1-perl-5.36.0/lib/perl5/5.36.0/Net/SMTP.pm
 line 268.
--8<---cut here---end--->8---

when running “git send-email”.  I have not investigated yet why it
fails.  I notice this:

--8<---cut here---start->8---
$ guix gc --references $(readlink -f 
~/.guix-profile/libexec/git-core/git-send-email)
/gnu/store/0yavjaj47a0g3lyw33q2m9whgl588ww7-perl-net-ssleay-1.92
/gnu/store/9wx8rvz984cizp3cq4ng2n1qlk2f1kkh-git-2.45.2
/gnu/store/h2vmf9krw1xmhdd5m52wqs0d7m2ryhxv-perl-gssapi-0.28
/gnu/store/pkd5amfn4wcqrd85x49035nhq8kxy906-perl-uri-5.05
/gnu/store/v6bivyjbg6bj07s8iqfzdm6hpvypc0p1-perl-5.36.0
/gnu/store/x47i4yafqxdav838aykda9c2hhhn9sa4-bash-minimal-5.1.16
/gnu/store/z542qwhy7nnzq7iyjpfxpib2vcx04j0r-git-2.45.2-send-email
--8<---cut here---end--->8---

which the package perl-io-socket-ssl seems missing.

To be precise, using my previous generation, I get:

bash-minimal-5.1.16
git-2.41.0
git-2.41.0-send-email
perl-5.36.0
perl-authen-sasl-2.16
perl-digest-hmac-1.04
perl-gssapi-0.28
perl-io-socket-ssl-2.081
perl-net-smtp-ssl-1.04
perl-net-ssleay-1.92
perl-uri-5.05

and now, I get:

bash-minimal-5.1.16
git-2.45.2
git-2.45.2-send-email
perl-5.36.0
perl-gssapi-0.28
perl-net-ssleay-1.92
perl-uri-5.05

So the difference reads:

perl-authen-sasl-2.16
perl-digest-hmac-1.04
perl-io-socket-ssl-2.081
perl-net-smtp-ssl-1.04

Other said, if I run:

guix shell git git:send-email \
 perl \
  perl-authen-sasl perl-digest-hmac perl-io-socket-ssl perl-net-smtp-ssl

then the error is gone.


Cheers,
simon

bug#73002: Julia packages are not reproducible

[Simon Tournier]

Hi Ludo,

On Tue, 03 Sep 2024 at 13:56, Ludovic Courtès  wrote:

> Currently Julia packages, as built with Julia 1.8.3, are not
> reproducible.  Here’s a small sample:

Duplicate with:

bug#47354: (build-system julia) not reproducible
zimoun 
Wed, 24 Mar 2021 01:37:07 +0100
id:86o8f9idzg@gmail.com
https://issues.guix.gnu.org/47354
https://issues.guix.gnu.org/msgid/86o8f9idzg@gmail.com
https://yhetil.org/guix/86o8f9idzg@gmail.com

Please also consider:

bug#22304: Build for Julia is not reproducible
Ricardo Wurmus 
Mon, 04 Jan 2016 17:28:42 +0100
id:idj1t9xia11@bimsb-sys02.mdc-berlin.net
https://issues.guix.gnu.org/22304

https://issues.guix.gnu.org/msgid/idj1t9xia11@bimsb-sys02.mdc-berlin.net
https://yhetil.org/guix/idj1t9xia11@bimsb-sys02.mdc-berlin.net

Well, IIRC, upstream was not receptive about tackling that problem, see
upstream issue#34753.

https://github.com/JuliaLang/julia/issues/34753

Somehow, it’s seem the same kind of situation as Guile and
non-reproducible .go. ;-) Tackling the problem implies a deep-dive into
the compiler’s internals that requires a lot of efforts without the help
of core upstream.

Please note that Julia had been removed from Debian on 2022 [1], thus it
does not seem under the radar of ReproducibleBuilds.

Cheers,
simon

1: https://tracker.debian.org/pkg/julia

bug#72333: [PATCH] gnu: emacs-minimal: Do not native-compile lisp/transient.el.

[Simon Tournier]

On Tue, 3 Sept 2024 at 21:47, Liliana Marie Prikler
 wrote:

> > Should we do this in a snippet instead?  Otherwise LGTM.
>
> I left it as a phase, so that Emacsen with modified source also
> benefit.

I think it's better as a phase because of what you wrote and also
because "guix build -S emacs" returns a non (or less) Guix specific
source.

Thanks for quick review and push.  Now it's free my mind and I am
fully able to enjoy Magit v4.0. ;-)

Cheers,
simon

bug#72340: guix should not ask me to report a bug if it fails due to running out of memory

[Simon Tournier]

Hi,

On Tue, 03 Sep 2024 at 11:30, "Zack Weinberg"  wrote:

> I reconfigured my Guix system to avoid the bug, so I cannot easily
> trigger it anymore.  However, this is not a bug that would go away by
> accident.

Yes for sure, that’s not what I meant. :-)

This can happen if a cycle is introduced, i.e., package foo depending on
package foo.  Or it can happen for other reasons, as it seems the case here.

Well, this bug seems an instance of bug#47543 [1].

1: bug#47543: “Repeated allocation of very large block” during ‘guix pull’
Ludovic Courtès 
Thu, 01 Apr 2021 16:00:06 +0200
id:87v9966r6h@inria.fr
https://issues.guix.gnu.org/47543
https://issues.guix.gnu.org/msgid/87v9966r6h@inria.fr
https://yhetil.org/guix/87v9966r6h@inria.fr


> Also, I don't know what "guix time-machine" does but I would not
> expect "guix describe" to use substantial amounts of memory.  You need
> to run a command that computes a large derivation, such as "guix pull"
> or "guix system reconfigure".

“guix time-machine” runs “guix pull”, other said:

 guix time-machine -q --commit=e4aabf42b33346849cb565199cfafc49d4f0aeff \
   -- time-machine -q --commit=46a64c7fdd057283063aae6df058579bb07c4b6a \
   -- describe

is more or less equivalent to:

guix pull --commit=e4aabf42b33346849cb565199cfafc49d4f0aeff -p /tmp/host
/tmp/host/bin/guix pull --commit=46a64c7fdd057283063aae6df058579bb07c4b6a

which minimicks what you ran.  Indeed, I’ve run it on my machine and not
inside some VM with constrained memory.  However, considering bug#47543
[1], I am not convinced the crash comes from this constrained memory.

Hum, maybe it’s worth merging with bug#47543 [1].  WDYT?

Cheers,
simon

bug#72333: builtin native-compiled is loaded instead of emacs-packages

[Simon Tournier]

Hi Liliana,

On Mon, 02 Sep 2024 at 21:22, Liliana Marie Prikler  
wrote:

> It is a bug unique to our handling in Guix

Well, waiting a proper fix and a better story for Emacs package native
compilation, I propose to turn off the native-compilation for
lisp/transient.el only; see [1].  This fixes the bug at hand so it
removes the annoyance with a broken Magit.

And it lets the time to discuss a better long-term solution.

1: https://issues.guix.gnu.org/72333#12

Cheers,
simon

bug#72340: guix should not ask me to report a bug if it fails due to running out of memory

[Simon Tournier]

Hi,

On Sun, 28 Jul 2024 at 16:02, "Zack Weinberg" via Bug reports for GNU Guix 
 wrote:

> Computing Guix derivation for 'x86_64-linux'... \
> GC Warning: Failed to expand heap by 8388608 bytes
> [previous line repeats 79 more times]
> GC Warning: Failed to expand heap by 69632 bytes
> GC Warning: Out of Memory! Heap size: 402 MiB. Returning NULL!
> Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
> guix pull: error: You found a bug: the program
> '/gnu/store/6pckga173mjbpfz7a2bl93h4gimd8fp5-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "46a64c7fdd057283063aae6df058579bb07c4b6a"; system: "x86_64-linux";
> host version: "e4aabf42b33346849cb565199cfafc49d4f0aeff";

I guess this bug had been fixed since then.  Do you still have it?

Aside, I am not able to reproduce it:

guix time-machine -q --commit=e4aabf42b33346849cb565199cfafc49d4f0aeff \
  -- time-machine -q --commit=46a64c7fdd057283063aae6df058579bb07c4b6a \
  -- describe

This passes for me.

Cheers,
simon

bug#72333: [PATCH] gnu: emacs-minimal: Do not native-compile lisp/transient.el.

[Simon Tournier]

Fixes .
Reported by daniel szmulewicz .

* gnu/packages/emacs.scm (emacs-minimal)[arguments]: Turn off
native-compilation for the file lisp/transient.el.

Change-Id: I27c9d660cbad46be66df641816e4596346969dfc
---
 gnu/packages/emacs.scm | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index f1ea4fe061..c555ca09f7 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -233,6 +233,16 @@ (define-public emacs-minimal
 (("\\(tramp-compat-process-running-p \"(.*)\"\\)" all process)
  (format #f "(or ~a (tramp-compat-process-running-p ~s))"
  all (string-append "." process "-real"))
+  (add-after 'unpack 'do-not-native-compile
+(lambda _
+  ;; Fixes .  Temporary
+  ;; workaround for native-compilation bug of transient.el.
+  ;; Please remove once the native-compilation for Emacs packages
+  ;; is fully supported.
+  (substitute* "lisp/transient.el"
+((";; End:")
+ ";; no-native-compile: t
+;; End:"
   (add-before 'configure 'fix-/bin/pwd
 (lambda _
   ;; Use `pwd', not `/bin/pwd'.

base-commit: 1569b861f504178263b73b4b48563bf3937d01bf
-- 
2.41.0

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Simon Tournier]

Hi Konrad,

On Mon, 02 Sep 2024 at 17:31, Konrad Hinsen  wrote:

> The "channels.scm" attached to my last message describes Guix at the
> time "guix time-machine" was launched. It's not the channels file used
> in the time machine command! That one is quite short:

In your previous message, you wrote:

--8<---cut here---start->8---
He gets an error when running an example from one of our exercises:

   guix time-machine --channels=channels.scm -- shell --container --network 
--manifest=manifest.scm -- jupyter lab
   guix-science/build-system/node.scm:119:2: error: #{ 
%make-build-system-procedure/abi-check}#: unbound variable
   hint: Did you forget a `use-modules' form?
--8<---cut here---end--->8---

So IIUC, the channels.scm file you provided is not the same channels.scm
file here.  You provided all the revisions to get this Guix and from
this Guix you tries to reach another revision (named channels.scm in the
above but just reads 7b0863f07a113caef26fea13909bd97d250b629e).

Right?

Again IIUC, the picture looks like:

The hypothetical commit introducing the potential breakage:

records: Do not inline the constructor.
c14b8636fbac9826115f4524d500536d54c15625
CommitDate: Sat May 4 19:14:24 2024 +0200 
Change-Id: Ifd7b4e884e9fbf21c43fb4c3ad963126ef5cb476

The Guix revision (newer than the record modification):

guix: 325fed4c1514bffd084355455710fcc3f1c8da2c
CommitDate: Tue Jul 16 10:28:05 2024 -0500

guix-science: 12eba5aa0c5cbf357c476ef7872e0d562d054eff
CommitDate: Wed May 22 17:40:02 2024 +0200

And the revision time-machine going in the past:

guix: 7b0863f07a113caef26fea13909bd97d250b629e
CommitDate: Wed Jan 3 16:38:57 2024 -0500


>> Is the current failing Guix running a revision older than May?
>
> It's the one defined in channels.scm, meaning commit
> 325fed4c1514bffd084355455710fcc3f1c8da2c, from July 16th 2024. So, no,
> not older than May.

On my machine, it passes too:

--8<---cut here---start->8---
$ guix time-machine -C channels.scm \
-- time-machine --commit=7b0863f07a113caef26fea13909bd97d250b629e \
-- describe
  guix 7b0863f
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 7b0863f07a113caef26fea13909bd97d250b629e
--8<---cut here---end--->8---

Well, I do not know how to debug that. :-) Especially without an access
to the machine and considering the person, from the MOOC, is probably
new to Guix.

Assuming ’guix describe’ returns all the channels as mentioned earlier,
this is how to check that the current Guix contains the variable.

--8<---cut here---start->8---
$ thisguix=$(type -P guix)
$ realguix=$(readlink -f $thisguix)
$ themodules=$(guix gc --references $realguix | grep guix-module-union)

$ find -L $themodules -type f -name "*.scm" -exec grep -l 'procedure/abi-check' 
{} \;
/gnu/store/ljgzk92h0hd09bli5iccg8yfp3gf1hb4-guix-module-union/share/guile/site/3.0/guix/records.scm
--8<---cut here---end--->8---

If nothing is returned, then it would mean that something had been
twisted when compiling (pulling) this current Guix.  In that case, what
would be the output of:

$realguix describe
guix gc --references $realguix
guix gc --references $themodules

?

Else, if the file is returned, it means the error is from elsewhere,
e.g., how the Guile modules are loaded or other.  In that case, it would
require to investigate the derivations.


Well, the hash ljgzk92h0hd09bli5iccg8yfp3gf1hb4 can be different, I
guess.


Cheers,
simon

bug#72333: builtin native-compiled is loaded instead of emacs-packages

[Simon Tournier]

Oups, missing some edits, as usual. :-)

> However, it should be an issue since emacs-transient is correctly
> updated and correctly contains the requirements.

it should *NOT* be an issue

bug#72333: builtin native-compiled is loaded instead of emacs-packages

[Simon Tournier]

Hi,

Alvin Hsu

Once bisecting, the first occurrence appears with:

7a2fc32ba2cec79b087932f30d77751f9133d740
CommitDate: Sun Jul 21 13:32:27 2024 +0200
Parent: bb1aea46e6 gnu: emacs-gnosis: Update to 0.3.2.

gnu: emacs-magit: Update to 3.3.0-8.538cb2f

* gnu/packages/emacs-xyz.scm (emacs-magit): Update to 3.3.0-8.538cb2f.

A.o. it contains the fix for https://github.com/magit/magit/issues/4940 
which is a showstopper.

Change-Id: Id83a237d38c03a97f9f1043db4b8ba594521a2f7


This update of emacs-magit depends on transient-prefix-object, i.e., it
depends on a new version of transient.

--8<---cut here---start->8---
$ ag transient-prefix-object \
 $(guix time-machine -q --commit=7a2fc32ba2cec79b087932f30d77751f9133d740 
-- build emacs-magit -S)
/gnu/store/fgcz4a4adhnrcxa541kdkn30f0hgn6c5-emacs-magit-3.3.0-8.538cb2f-checkout/lisp/magit-branch.el
213:  (oref (transient-prefix-object) scope)))
217: (propertize (oref (transient-prefix-object) scope)
866: (propertize (oref (transient-prefix-object) scope)
910:  (when-let* ((branch (oref (transient-prefix-object) scope))
918:(magit-read-upstream-branch (oref (transient-prefix-object) scope)
922:  (magit-set-upstream-branch (oref (transient-prefix-object) scope) refname)
924:(and-let* ((branch (oref (transient-prefix-object) scope))
931:  (let ((branch (oref (transient-prefix-object) scope)))

/gnu/store/fgcz4a4adhnrcxa541kdkn30f0hgn6c5-emacs-magit-3.3.0-8.538cb2f-checkout/lisp/magit-remote.el
73:  (oref (transient-prefix-object) scope)))
318: (propertize (oref (transient-prefix-object) scope)
--8<---cut here---end--->8---

When the commit parent does not:

$ ag transient-prefix-object \
$(guix time-machine -q --commit=bb1aea46e6 -- build emacs-magit -S)


However, it should be an issue since emacs-transient is correctly
updated and correctly contains the requirements.

--8<---cut here---start->8---
$ ag transient-prefix-object \
 $(guix time-machine -q --commit=bb1aea46e6 -- build emacs-transient)
/gnu/store/8zwwwprv93shxjjfcc4a406gs9qgk58i-emacs-transient-0.7.2/share/emacs/site-lisp/transient-0.7.2/transient.el
1605:(defun transient-prefix-object ()
3044:   (format "levels > %s" (oref (transient-prefix-object) 
level))
3058:  (transient-set-value (transient-prefix-object)))
3066:  (transient-save-value (transient-prefix-object)))
3074:  (transient-reset-value (transient-prefix-object)))
3607:  (oref (transient-prefix-object) scope))
--8<---cut here---end--->8---

Therefore, the issue…

On Fri, 30 Aug 2024 at 18:33, Simon Tournier  wrote:

> Why is emacs-transient not loaded?

…is something about loading Emacs Lisp code.

--8<---cut here---start->8---
$ guix time-machine -q --commit=bb1aea46e6 \
   -- shell emacs emacs-transient \
   -- emacs --batch --eval "(progn (require 'transient) 
(transient-prefix-object) (print \"done\"))"
 
Error: void-function (transient-prefix-object)
  mapbacktrace(#f(compiled-function (evald func args flags) #))
  debug-early-backtrace()
  debug-early(error (void-function transient-prefix-object))
  (transient-prefix-object)
  (progn (require 'transient) (transient-prefix-object) (print "done"))
  command-line-1(("--eval" "(progn (require 'transient) 
(transient-prefix-object) (print \"done\"))"))
  command-line()
  normal-top-level()
Symbol’s function definition is void: transient-prefix-object
--8<---cut here---end--->8---

Compared to:

--8<---cut here---start->8---
$ guix time-machine -q --commit=bb1aea46e6 \
   -- shell emacs emacs-transient \
   -- emacs --batch --eval "(progn (load (locate-library \"transient\")) 
(transient-prefix-object) (print \"done\"))"

Loading 
/gnu/store/8zwwwprv93shxjjfcc4a406gs9qgk58i-emacs-transient-0.7.2/share/emacs/site-lisp/transient-0.7.2/transient.elc...

"done"
--8<---cut here---end--->8---

Now, if native compilation is not able to find .eln files then all work
as expected.

--8<---cut here---start->8---
$ guix time-machine -q --commit=bb1aea46e6 \
   -- shell emacs emacs-transient \
   -- emacs --batch --eval "(progn (setq native-comp-eln-load-path nil) 
(require 'transient) (transient-prefix-object) (print \"done\"))"
 
"done"
--8<---cut here---end--->8---


Other said, the bug is not about Magit or Transient but the bug is about
a

bug#72332: bug report

[Simon Tournier]

Hi,

On Sun, 28 Jul 2024 at 06:17, Sarah Schaffer via Bug reports for GNU Guix 
 wrote:
> ERROR:
> 1. &store-protocol-error:
> message: "`/gnu/store/5kj8lyybjrdl7xd0fx9g9vzkz8sklqsy-guix-1.4.0/bin/guix 
> substitute' died unexpectedly"
> status: 1
> guix pull: error: You found a bug: the program 
> '/gnu/store/4dd7paz7b8x4xy7yn36hjnmlhpzx0h8c-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "46a64c7fdd057283063aae6df058579bb07c4b6a"; system: "x86_64-linux";
> host version: "1.4.0"; pull-version: 1).

Thanks for your report.

I guess it comes from a fresh install, right?  If yes, does it come from
“guix pull” run as root?  Or run as a regular user?

Cheers,
simon

bug#72832: duplicate downloads when running “guix pull”

[Simon Tournier]

Hi,

On Thu, 22 Aug 2024 at 20:32, Simon Tournier  wrote:

>  2. remaining derivation about boot or mesboot.

Well, from my understanding, this leads to concrete problem as bug#72774
[1].


Cheers,
simon


1: bug#72774: guix pull fails (findutils-boot0 check phase) on riscv64
Daniel K 
Fri, 23 Aug 2024 16:05:58 +
id:mwhpr02mb3342b5715383310d0498042596...@mwhpr02mb3342.namprd02.prod.outlook.com
https://issues.guix.gnu.org/72774
https://issues.guix.gnu.org/msgid/mwhpr02mb3342b5715383310d0498042596...@mwhpr02mb3342.namprd02.prod.outlook.com
https://yhetil.org/guix/mwhpr02mb3342b5715383310d0498042596...@mwhpr02mb3342.namprd02.prod.outlook.com

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Simon Tournier]

Hi Konrad,

CC: Ludo, do you think it comes from the commit c14b8636fb: “records: Do
not inline the constructor.”?


On Wed, 24 Jul 2024 at 21:35, Konrad Hinsen  wrote:

>> Could you share the channels.scm file?
>
> Attached.

Thanks.  Do you know what the current Guix revision?  It should have no
effect but who knows. :-)

I mean, guix-daemon had been updated.  Has the Guix command launching
“guix time-machine” been updated too?


>> Because the mention of ’guix-science’ means third-party channels, I
>> guess.  And maybe there is something tricky when mixing different
>> specific pinned channels.
>
> I thought about that as well, but the behavior should still be the same
> on every machine, right? For me, the attached channels.scm works fine.

Yes.  But there is a "Computing Guix derivation“ in the middle. :-)

If I read correctly, this error message:

> guix time-machine --channels=channels.scm -- …
> guix-science/build-system/node.scm:119:2: error: #{ 
> %make-build-system-procedure/abi-check}#: unbound variable
> hint: Did you forget a `use-modules' form?

comes from the macro ’define-record-type*’; see module (guix records).

 (symbol-append (string->symbol " %")
(syntax->datum #'ctor)
'-procedure/abi-check)))

That’s weird, because all seems correctly included, i.e., the variable
should be bounded.  Well, the revisions from the channels.scm file
reads:

guix-science: 12eba5aa0c5cbf357c476ef7872e0d562d054eff
CommitDate: Wed May 22 17:40:02 2024 +0200

guix: 325fed4c1514bffd084355455710fcc3f1c8da2c
CommitDate: Tue Jul 16 10:28:05 2024 -0500

And the file guix/records.scm had been modified by:

records: Do not inline the constructor.
c14b8636fbac9826115f4524d500536d54c15625
CommitDate: Sat May 4 19:14:24 2024 +0200 
Change-Id: Ifd7b4e884e9fbf21c43fb4c3ad963126ef5cb476

Is the current failing Guix running a revision older than May?


Cheers,
simon

bug#72832: duplicate downloads when running “guix pull”

[Simon Tournier]

Hi,

Well, I notice several similar downloads when running “guix pull” or
“guix time-machine”; see complete log below.

This reports and investigates 2 different origins for these duplicates:

 1. graft with multiple outputs;
 2. remaining derivation about boot or mesboot.


For instance, when pulling it reads:

 bash-minimal-5.1.16  568KiB  165KiB/s 00:03 ▕██▏ 100.0%
 bash-minimal-5.1.16  569KiB  163KiB/s 00:03 ▕██▏ 100.0%

 bzip2-1.0.8  55KiB   224KiB/s 00:00 ▕██▏ 100.0%
 bzip2-1.0.8  55KiB   246KiB/s 00:00 ▕██▏ 100.0%
 bzip2-1.0.8  55KiB   308KiB/s 00:00 ▕██▏ 100.0%

 gcc-11.3.0-lib  4.8MiB   128KiB/s 00:38 ▕██▏ 100.0%
 gcc-11.3.0-lib  4.8MiB   140KiB/s 00:35 ▕██▏ 100.0%

 guile-3.0.9  7.0MiB  181KiB/s 00:40 ▕██▏ 100.0%
 guile-3.0.9  7.0MiB  193KiB/s 00:37 ▕██▏ 100.0%

 gzip-1.12  81KiB  43KiB/s 00:02 ▕██▏ 100.0%
 gzip-1.12  81KiB 343KiB/s 00:00 ▕██▏ 100.0%

 xz-5.2.8  366KiB  85KiB/s 00:04 ▕██▏ 100.0%
 xz-5.2.8  366KiB 193KiB/s 00:02 ▕██▏ 100.0%
 xz-5.2.8  366KiB 203KiB/s 00:02 ▕██▏ 100.0%


Based on the information below, it’s straightforward to extract the
profile and then trace it.  Else, I guess this should reproduce:

guix pull --commit=4c194859f7c5956b03a4ccaa1c9ad22576c80c59 -p /tmp/this


Indeed, the profile refers to 2 bash-minimal, 3 bzip2, etc.

--8<---cut here---start->8---
$ guix gc -R $(readlink -f /tmp/this) | grep bash-minimal
/gnu/store/9lhcyibqxfxni0n9z3x33bs66691bxrj-bash-minimal-5.1.16
/gnu/store/fl3l5wx8qynjrvx5lilz6c38hb77cf36-bash-minimal-5.1.16

$ guix gc -R $(readlink -f /tmp/this) | grep bzip2-1
/gnu/store/al9hskxmgzq0b1ff463djdjrdk7ypffj-bzip2-1.0.8
/gnu/store/bzcfrvhd8n8fnyi5gpfmsjmqwrgnpbp9-bzip2-1.0.8
/gnu/store/m0c98mlg3fv3096p6xc7arcw9v6zcxi9-bzip2-1.0.8

$ guix gc -R $(readlink -f /tmp/this) | grep gcc
/gnu/store/3sw5s4qlp8lka77y2jps8pvs4ldawdrs-gcc-11.3.0-lib
/gnu/store/ixwl0vnvm9zrrg89nxh62llh3li701dw-gcc-11.3.0-lib

$ guix gc -R $(readlink -f /tmp/this) | grep guile-3
/gnu/store/sg5kqvv9is29xh60innp13rlvc03yvr0-guile-3.0.9
/gnu/store/93jzwshnwlsijjf97ssdpw3w516cd6ja-guile-3.0.9

$ guix gc -R $(readlink -f /tmp/this) | grep xz-5
/gnu/store/cpmq6yl1ls1qnv2knzfh56bpbs2wss1q-xz-5.2.8
/gnu/store/8gxdqg8azmlwbdg5l9pnwab4pib9mwr4-xz-5.2.8
/gnu/store/d8y2fpk9d3ajmg6rpmn0rnb0dcmbk82w-xz-5.2.8
--8<---cut here---end--->8---

That’s consistent with the download. :-)  The duplicates can be verified
with:

guix gc -R $(readlink -f /tmp/this) | cut -f2- -d'-' | sort | uniq -c | 
sort -n


Let give a look to the derivations producing these bzip2 outputs.  The 3
derivations are derivations for grafting.


The difference for one compared to the two others is the ’static’
output.

   /gnu/store/zmgwf3wa5zbal6zckrl187rlyh64yl8k-bzip2-1.0.8.drv
 ->
   /gnu/store/m0c98mlg3fv3096p6xc7arcw9v6zcxi9-bzip2-1.0.8
   /gnu/store/ha8hvl9215d6s5gb1rxiiai0rv6zi23w-bzip2-1.0.8-static

Obviously, the builder contains a reference to an old-output ’static’,
thus its content-address is different.  Well, that’s annoying… at least
that appears to me as a bug.  It’s similar for the case of ’xz’.

For information, the derivation that is grafted here reads:

/gnu/store/slv5z1nqd2i6kd90c78z6kfjgb3llnpi-bzip2-1.0.8.drv


Now, let give a look to:

/gnu/store/bzcfrvhd8n8fnyi5gpfmsjmqwrgnpbp9-bzip2-1.0.8

produced by:

/gnu/store/1fc3cl93512p61khr7grnd9zpvzywv83-bzip2-1.0.8.drv

Well, this derivation also grafts this other derivation:

/gnu/store/slv5z1nqd2i6kd90c78z6kfjgb3llnpi-bzip2-1.0.8.drv

Other said, the same as above.  In summary, the same identical binaries
but differently content-addressed are downloaded twice.

--8<---cut here---start->8---
$ diff -r --no-dereference \
> /gnu/store/m0c98mlg3fv3096p6xc7arcw9v6zcxi9-bzip2-1.0.8 \
> /gnu/store/bzcfrvhd8n8fnyi5gpfmsjmqwrgnpbp9-bzip2-1.0.8 
Symbolic links 
/gnu/store/m0c98mlg3fv3096p6xc7arcw9v6zcxi9-bzip2-1.0.8/bin/bzcmp and 
/gnu/store/bzcfrvhd8n8fnyi5gpfmsjmqwrgnpbp9-bzip2-1.0.8/bin/bzcmp differ
Symbolic links 
/gnu/store/m0c98mlg3fv3096p6xc7arcw9v6zcxi9-bzip2-1.0.8/bin/bzegrep and 
/gnu/store/bzcfrvhd8n8fnyi5gpfmsjmqwrgnpbp9-bzip2-1.0.8/bin/bzegrep differ
Symbolic links 
/gnu/store/m0c98mlg3fv3096p6xc7arcw9v6zcxi9-bzip2-1.0.8/bin/bzfgrep and 
/gnu/store/bzcfrvhd8n8fnyi5gpfmsjmqwrgnpbp9-bzip2-1.0.8/bin/bzfgrep differ
Symbolic links 
/gnu/store/m0c98mlg3fv3096p6xc7arcw9v6zcxi9-bzip2-1.0.8/bin/bzless and 
/gnu/store/bzcfrvhd8n8fnyi5gpfmsjmqwrgnpbp9-bzip2-1.0.8/bin/bzless differ
--8<---

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Simon Tournier]

Hi Konrad,

On Wed, 24 Jul 2024 at 10:05, Konrad Hinsen  wrote:

>guix time-machine --channels=channels.scm -- shell --container --network 
> --manifest=manifest.scm -- jupyter lab
>guix-science/build-system/node.scm:119:2: error: #{ 
> %make-build-system-procedure/abi-check}#: unbound variable
>hint: Did you forget a `use-modules' form?
>

[...]

> Are there any diagnostics we can do to explore this issue?

Could you share the channels.scm file?

Because the mention of ’guix-science’ means third-party channels, I
guess.  And maybe there is something tricky when mixing different
specific pinned channels.


Cheers,
simon

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

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#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#72174: guix download does not support Mercurial

[Simon Tournier]

Hi,

On Mon, 22 Jul 2024 at 09:11, Ludovic Courtès  wrote:

>> I studied `guix download -h` which shows that `guix download` only
>> supports Git repositories. Since there is `hg-download`, it would
>> make sense that the command `guix download` support Mercurial. 
>
> Indeed, only Git is supported at this point.  Supporting Mercurial and
> other VCSes would be nice though there’s no plan to do so at this point
> (Git support was a low-hanging fruit since Git is already tightly
> integrated).

Somehow, “guix download” does not rely on the module ’(guix
git-download)’ that provides ’git-fetch’ but it relies on the module
’(guix git)’.  Therefore, “hg-download” is not helpful here and somehow
a brick seems lacking. :-)

Maybe I misread, my understanding in short is that “git-download” or
“hg-download” works with fixed-output derivations, hence the hash must
be known beforehand; source code is fetched via a derivation that the
guix-daemon processes.

Instead, “guix download” fetches using code from user side and not from
guix-daemon side and the source is fetched inside some user’s cache that
is then copied to the store.  This way there is no hash check.

The code behind “guix download” supporting Git is implemented with
guile-libgit2 – tightly integrated ;-); see latest-repository-commit
calling update-cached-checkout from (guix git).  It would be possible to
implement the equivalent for Mercurial or redesign “guix download”; in
both cases, todo. :-)

HTH

Cheers,
simon

bug#72135: Debian ‘guix’ package lacks zstd support

[Simon Tournier]

Hi,

On Thu, 18 Jul 2024 at 09:21, Ludovic Courtès  wrote:

>> That said, after “apt install guix”, does the guix-daemon update work?
>> Somehow if “guix pull” as root fails after a fresh install via APT, then
>> it’s a bug on Guix side, else it’s a bug on Debian side tracked by
>> 1072918. :-)
>
> Upgrading guix-daemon when it was originally installed with apt is
> tricky: you need to modify /etc/systemd/system/guix-daemon.service so
> that it refers to the one in /var/guix/….  So I think few people upgrade
> the daemon on Debian.

Indeed.  Even, let note that the default configuration provided by Guix
seems patched by Debian [1].

So yeah the only way is to modify
/etc/systemd/system/guix-daemon.service  and restart the service.

> I’m not sure how to improve on that; we could document it under
> “Upgrading Guix” at least.

Well, yes the documentation on our side is a good start. :-)

Then, I do not know either how to improve on that.  I mean a typical
Debian cycle is 3-5 years for a release – oldstable Debian (Bulleye)
provides guix-daemon version 1.2.0 – then it would mean we must support
backward compatibility for substitutes to this all range; as Vagrant
warned in [2]. :-)

Well, patches could be accepted for fixing security in guix-daemon but I
am not convinced patches for some new/deprecated features would be
accepted.

Maybe we could provide some patches for oldstable Debian that modify
guix-daemon.service and friends.  Vagrant wrote [3]:

It is of course possible to configure to use an updated guix-daemon from
a user's profile (e.g. as recommended with guix-binary installation on a
foreign distro), but out-of-the-box it uses the guix-daemon shipped in
the package, which, at least with my Debian hat on, is how it should be.

So I do not know what would be the best here. :-)


Cheers,
simon


1: 
https://salsa.debian.org/debian/guix/-/blob/b1d0628cbedea22f175a463f4c4935d02601bf93/debian/patches/guix-services-from-usr-bin

2: Re: Are gzip-compressed substitutes still used?
Vagrant Cascadian 
Wed, 17 Mar 2021 11:08:38 -0700
id:87o8fhwt3t.fsf@yucca
https://lists.gnu.org/archive/html/guix-devel/2021-03
https://yhetil.org/guix/87o8fhwt3t.fsf@yucca

3: Re: Are gzip-compressed substitutes still used?
Vagrant Cascadian 
Thu, 18 Mar 2021 09:00:20 -0700
id:87eegcwiy3.fsf@yucca
https://lists.gnu.org/archive/html/guix-devel/2021-03
https://yhetil.org/guix/87eegcwiy3.fsf@yucca

bug#72135: Debian ‘guix’ package lacks zstd support

[Simon Tournier]

Hi Ludo,

On Tue, 16 Jul 2024 at 10:41, Ludovic Courtès  wrote:

> (I know this should be a Debian bug report, but I’m sorta acting as a
> proxy.  :-))

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072918

Reported by: Marvin Krause 
Date: Mon, 10 Jun 2024 10:45:01 UTC
Severity: important
Found in version guix/1.4.0-3+deb12u1


>  However, it currently lacks zstd support (with
> guile-zstd):
>
>   https://packages.debian.org/bullseye/guix

Well, I am not an expert on the Debian releases, but I guess it is not
possible to backport all the stuff for this ’oldstable’ Debian release.

Hum, I do not remember all the details but I remember discussing this
sort of issue in [1].

That said, after “apt install guix”, does the guix-daemon update work?
Somehow if “guix pull” as root fails after a fresh install via APT, then
it’s a bug on Guix side, else it’s a bug on Debian side tracked by
1072918. :-)


And as reported above, the issue is still in ’stable’ Debian release.


1: Re: Are gzip-compressed substitutes still used?
Vagrant Cascadian 
Wed, 17 Mar 2021 11:08:38 -0700
id:87o8fhwt3t.fsf@yucca
https://lists.gnu.org/archive/html/guix-devel/2021-03
https://yhetil.org/guix/87o8fhwt3t.fsf@yucca

Cheers,
simon

bug#72161: doc: 'Sending a Patch Series' inconsistent with 'Building from Git'

[Simon Tournier]

Hi,

As reported in [1], because of a change in ’guix git authenticate’ then
’git send-email’ needs more configuration than expected.

>From ’(guix) Sending a Patch Series’ [2], it reads:

Assuming you have already configured Git according to ’Configuring
Git’, you can simply use:

 $ git send-email --annotate -1

Where ’(guix) Configuring Git’ [3] reads:

Other important Git configuration will automatically be configured
when building the project (*note ’Building from Git’).

and ’(guix) Building from Git’ [4] suggests the sequence of commands:

 git clone https://git.savannah.gnu.org/git/guix.git
 git fetch origin keyring:keyring
(1)  guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad \
   "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
 guix shell -D guix -CPW
 ./bootstrap
 ./configure
(2)  make
 make check

But the issue is that step (1) modifies the file ’.git/config’ and then
Makefile rule:

--8<---cut here---start->8---
.git/config: etc/git/gitconfig
$(AM_V_at)if command -v git >/dev/null && test -d .git; then \
git config --fixed-value --replace-all include.path \
  ../etc/git/gitconfig ../etc/git/gitconfig; \
fi
--8<---cut here---end--->8---

does not apply because the file ’.git/config’ is newer than the file
’etc/git/gitconfig’.  Therefore, the recommended Git configuration is
never locally installed.  And the section ’Sending a Patch Series’ does
not work out of the box.


Well, from my point of view, the easiest seems to run ’touch
etc/git/gitconfig’ when running ’./bootstrap’.  WDYT?


Cheers,
simon

1: Re: Did something with format-patch or send-email break?
Tomas Volf <~@wolfsden.cz>
Sun, 09 Jun 2024 12:51:44 +0200
id:ZmWJQLwXrPFtGlvu@ws
https://lists.gnu.org/archive/html/guix-devel/2024-06
https://yhetil.org/guix/ZmWJQLwXrPFtGlvu@ws

2: https://guix.gnu.org/manual/devel/en/guix.html#Sending-a-Patch-Series
3: https://guix.gnu.org/manual/devel/en/guix.html#Configuring-Git
4: https://guix.gnu.org/manual/devel/en/guix.html#Building-from-Git

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Simon Tournier]

Hi Ludo,

Thank you for the pedestrian report; I have learnt new stuff! :-)


On Thu, 11 Jul 2024 at 17:33, Ludovic Courtès  wrote:

> Presumably whether ‘builtin:git-download’ is used changes the DAG
> traversal order, which could explain this discrepancy.
>
> It does mean that all the users running an old guix-daemon find
> themselves having no substitutes for ‘guix pull’.  Ouch.

Is it not only for grafts?


Well, in addition, some input derivations are not the same:

--8<---cut here---start->8---
2 candidates:
./fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv:3: 
,[("/gnu/store/0q4nrqmh6ymhs4hmg9vmxa8zqx1y3d2z-dbus-1.14.0.drv",["out"])
./fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv:18:   
,("/gnu/store/fflyi1qg7j9kz0b062p6xf0904rc8xkm-dbus-1.14.0.drv",["out"])
--8<---cut here---end--->8---

compared to:

--8<---cut here---start->8---
2 candidates:
./vhj8f01bwddshnc75ar5z62ndcij4pgy-avahi-0.8.drv:9:   
,("/gnu/store/6p17vdziv9vcp8l4c8v0xqj855gf257g-dbus-1.14.0.drv",["out"])
./vhj8f01bwddshnc75ar5z62ndcij4pgy-avahi-0.8.drv:17:   
,("/gnu/store/j6g0pchbj39pbg9b9bh7wafsd8kysvv3-dbus-1.14.0.drv",["out"])
--8<---cut here---end--->8---

Although the two derivations:

/gnu/store/0q4nrqmh6ymhs4hmg9vmxa8zqx1y3d2z-dbus-1.14.0.drv
/gnu/store/6p17vdziv9vcp8l4c8v0xqj855gf257g-dbus-1.14.0.drv

builds: /gnu/store/hjc4rdifbl890j03xy2gsa7y2sqcg0mi-dbus-1.14.0.

And similarly for the two others ’dbus’ derivations; they build the same
outputs.

Please also note that the two derivations do not have the same order for
the builder part:

--8<---cut here---start->8---
,["/gnu/store/32kpijl743qn7v337i19dd1hph1rd6x7-avahi-0.8-builder","/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import"]
,["/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import","/gnu/store/z1kanbslzb2lrr1hj922a50zkxl9jz28-avahi-0.8-builder"]
--8<---cut here---end--->8---

And the two builder scripts are not the same because the item
"/gnu/store/36my0g0j72b3vbz0gj1l8f0lmmgfkv3w-glib-2.72.3" is line 26 for
one and line 30 for the other.


Cheers,
simon

bug#28510: crash: guix build -S foo --with-source=bla

[Simon Tournier]

Hi Vincent,

On Sat, 22 Jun 2024 at 16:54, Vincent Legoll  wrote:

> Looking at the comments in this issue, and the commenters list,
> I propose to remove the "easy" tag, if the issue is still there.

I removed the tag easy.  Well, I still think it’s an easy fix because to
me the issue is not the failure of “guix build --source foo
--with-source=bar” but the poor error handling.  However, if the aim to
be able to pass such command-line, then indeed that’s not easy because
it’s about some guarantee that the transformation is sound and that’s
hard for the generic case, IMHO.

Cheers,
simon

bug#28510: crash: guix build -S foo --with-source=bla

[Simon Tournier]

tags 28510 - easy
quit

bug#71952: documentation inaccuracy?

[Simon Tournier]

Hi,

>> $ guix home switch-generation -- -1
>> guix home: error: -1: extraneous command

Indeed, the command-line parser seems incorrect and inconsistent with
the documentation.

The culprit seems the procedure ’parse-args’ from ’guix-home’ command
inside the module (guix scripts home).

Hum, I guess something as the attached patch should fix the issue.

diff --git a/guix/scripts/home.scm b/guix/scripts/home.scm
index b4c82d275f..5c39e83983 100644
--- a/guix/scripts/home.scm
+++ b/guix/scripts/home.scm
@@ -682,6 +682,8 @@ (define-command (guix-home . args)
   (match rest
 (() opts)
 (("--") opts)
+(("--" n)
+ (alist-cons 'argument n opts))
 (("--" command ...)
  (match (assoc-ref opts 'action)
('container

WDYT?

Cheers,
simon

bug#71700: The Archiving functionality of guix lint should be opt-in and Documented more prominently

[Simon Tournier]

Hi Richard,

On Sat, 22 Jun 2024 at 09:21, Richard Sent  wrote:

> I think there is a good reason to support disabling archival at the
> channel level. Simon, do you think your patch can/will manage that?

Yeah it could be helpful.  However, my patch does not address at this
level.

I agree it could be an other complementary direction.  But the design at
channel needs to be thought a bit, IMHO.

Cheers,
simon

bug#71700: The Archiving functionality of guix lint should be opt-in and Documented more prominently

[Simon Tournier]

Hi,

On Fri, 21 Jun 2024 at 19:45, MSavoritias  wrote:

> I would like to propose to make that linter off by default.

Somehow I disagree with this.  And I propose the generic approach that
allows to exclude any checkers from the package definition using the
field properties.

See .

Cheers,
simon

bug#71151: time machine breaking

[Simon Tournier]

Hi,

On Wed, 5 Jun 2024 at 19:30, Alexandre Hannud Abdo  wrote:

> I no longer have easy access to the other machine, it belonged to a 
> colleague...

So closing?

Cheers,
simon

bug#70201: Bug Report

[Simon Tournier]

Hi,

Thanks for the report.

On Thu, 04 Apr 2024 at 12:53, Charles MacDonald via Bug reports for GNU Guix 
 wrote:

>> guix substitute: warning: while fetching 
>> https://ci.guix.gnu.org/nar/lzip/21wnzvrrvn100w3q0bb5c894hqyn5b5d-guile-lzma-0.1.1:
>>  
>> server is somewhat slow
>> guix substitute: warning: try `--no-substitutes' if the problem persists
>> Backtrace:

[...]

>> In guix/scripts/substitute.scm:
>>     467:7  8 (download-nar #< path: "/gnu/store/21wnzvrrvn?> ?)

[...]

>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> ERROR:
>>   1. &http-get-error:
>>   uri: #< scheme: https userinfo: #f host: "ci.guix.gnu.org" 
>> port: #f path: 
>> "/nar/lzip/21wnzvrrvn100w3q0bb5c894hqyn5b5d-guile-lzma-0.1.1" query: 
>> #f fragment: #f>
>>   code: 504
>>   reason: "Gateway Time-out"
>>   headers: ((server . "nginx") (date . #> second: 59 minute: 12 hour: 11 day: 4 month: 4 year: 2024 zone-offset: 
>> 0>) (content-type text/html) (content-length . 160) (connection 
>> keep-alive))
>>   2. &message: 
>> "https://ci.guix.gnu.org/nar/lzip/21wnzvrrvn100w3q0bb5c894hqyn5b5d-guile-lzma-0.1.1:
>>  
>> HTTP download failed: 504 (\"Gateway Time-out\")"

I guess the issue is a transient network failure.  On your side or on
substitute servers side.

Are you still hitting this?

Cheers,
simon

bug#70200: Guix pull bug found

[Simon Tournier]

Hi,

Thanks for the report.

On Thu, 04 Apr 2024 at 11:37, casket_imagery.01--- via Bug reports for GNU Guix 
 wrote:

> I was trying to update Gix package manager on a fresh Debian instance
> in ProxMox, and as I was doing so, I got the below error. As requested
> by the script, I am sending you the output. 

[...]

> \guix pull: error: You found a bug: the program 
> '/gnu/store/8bmy58hg8h8mkd8vymgib4kpwl6wxv3f-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "2931967720848082769002351d2a18c7ad43e811"; system: "x86_64-linux";
> host version: "1.4.0"; pull-version: 1).

Do you have enough RAM?

Cheers,
simon

bug#70243: The substitute authorization warning is displayed when it shouldn't be

[Simon Tournier]

Hi,

On Sat, 25 May 2024 at 11:31, Ludovic Courtès  wrote:

>> But, I do have the given key in my '/etc/guix/acl', and this works:
>
> Are /etc/guix/acl and /etc/guix world-readable?

I had been bitten by this recently.  And I have not found any mention
about that in the manual.  Maybe it could helpful to add:

diff --git a/doc/guix.texi b/doc/guix.texi
index 5e1173b8c6..3b97674733 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -3792,7 +3792,8 @@ Getting Substitutes from Other Servers
 @end example
 
 Again this assumes @file{key.pub} contains the public key that
-@code{guix.example.org} uses to sign substitutes.
+@code{guix.example.org} uses to sign substitutes.  Make sure
+@file{/etc/guix/acl} is world-readable.
 @end enumerate
 
 Now you're all set!  Substitutes will be preferably taken from


In addition, I had to be read a comment in source code to know what
another issue was: the daemon’s too old.  Hence, I would suggest:

diff --git a/guix/scripts/weather.scm b/guix/scripts/weather.scm
index 08a1b22a74..98a09f9e9a 100644
--- a/guix/scripts/weather.scm
+++ b/guix/scripts/weather.scm
@@ -643,7 +643,7 @@ (define-command (guix-weather . args)
  ;; substitute URLs, presumably because it's too
  ;; old.
  (warning (G_ "using default \
-substitute URLs~%"))
+substitute URLs; maybe the daemon's too old~%"))
  %default-substitute-urls)))
  (systems  (match (filter-map (match-lambda
 (('system . system) system)

Both would ease the debugging session of substitute authorization, IMHO.

Cheers,
simon

bug#70064: Error when loading r-sf and other spatial packages (gdal related)

[Simon Tournier]

Hi,

On Thu, 04 Apr 2024 at 18:04, Javier Vaquero Martínez  wrote:

> So I managed to solve this. It turns out that some environment variables 
> where making this error to happen. Running in an isolated environment 
> with `guix shell -C r r-sf -- r` solves the problem.

Thanks for letting us know.  Therefore, can we close?

Cheers,
simon

bug#47144: security patching of 'patch' package

[Simon Tournier]

Hi,

On Wed, 05 Jun 2024 at 18:04, Ludovic Courtès  wrote:

> What about renaming ‘patch’ to ‘patch/pinned’ and having ‘patch’ point
> to the new version?
>
> Internally, we’d refer to ‘patch/pinned’ in (guix packages), but user
> code etc. would refer to ‘patch’ and thus get the latest version.

I agree; it appears to me “safer” than the graft.

However, the cost is to identify which package needs ’patch/pinned’ and
which needs new ’patch’.  Then once upstream Patch upgrades, there is
also the question to unpin all the packages.

Somehow, your previous suggestion ’patch-latest’ for this new package
appears to me the best solution.  Because it does not require any update
here and there, and since the source field follows the Git upstream
latest instead of the released tarball, this solution of ’patch-latest’
seems appropriated.

Cheers,
simon

bug#71151: time machine breaking

[Simon Tournier]

Hi Alexandre,

On Wed, 05 Jun 2024 at 02:05, Alexandre Hannud Abdo  wrote:

>> Using 6ba29e0, it works for me.
>
> I saw the issue on two different machines, one with GuixSD another a
> Debian with Guix freshly installed.

Is it the same ’guix describe’ for the two machines?  And the same
revision of guix-daemon?

Could you run:

guix build /gnu/store/mh01bp841xvcvv8mv6car7l92h6h19rk-curl-7.84.0.drv

?  And then,

guix build /gnu/store/mh01bp841xvcvv8mv6car7l92h6h19rk-curl-7.84.0.drv 
--check


Well, my hypothesis is the issue comes from the lack of some substitutes
when you ran it.  And now, this substitutes is there.  Maybe, the test
suite of curl – the one mentioned by the backtrace but no specific
reason that the one :-) – does not pass on your hardware.

Cheers,
simon

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

[Simon Tournier]

Hi,

CC: core team

On Wed, 24 Apr 2024 at 16:43, Simon Tournier  wrote:

> Out of any network, I get this error:
>
> --8<---cut here---start->8---
> $ guix time-machine --commit=1971d11d -- describe
> guix time-machine: error: failed to load 
> '/home/simon/.config//guix/channels.scm':
> guix/build/download.scm:399:8: In procedure open-socket-for-uri:
> In procedure getaddrinfo: Name or service not known
> --8<---cut here---end--->8---
>
> And that’s annoying.  It comes from:
>
> $ cat /home/simon/.config//guix/channels.scm
> (use-modules (guix ci))
>
> (list (channel-with-substitutes-available
>%default-guix-channel
>"https://ci.guix.gnu.org";))
>
> as documented by section “Channels with Substitutes” [1].
>
> Specifically, the error is raised by the procedure ’load*’ called by
> ’channel-list’ inside ’load-channels’.  Other said, ’load*’ runs the
> procedure ’channel-with-substitutes-available’ which asks network via
> the procedure ’find-latest-commit-with-substitutes’.
>
> I think this is incorrect; the correct behaviour seems trying to do as
> most as possible.  With the attached patch, I get:
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix time-machine --commit=1971d11d -- describe
> guix time-machine: warning: could not find available substitutes at 
> https://ci.guix.gnu.org
>   guix 1971d11
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 1971d11db9ed9683d5036cd4c62deb564842e1f6
> --8<---cut here---end--->8---
>
> Obviously, the option ’-q’ allows to bypass the problem. :-)  However,
> it’s annoying because the default file channels.scm can be complex and
> it still should work without any tweak, IMHO.
>
> Well, the proposed fix is here to catch the error; maybe it could be
> finer than #t.
>
> WDYT?
>
> Cheers,
> simon
>
>
> 1: https://guix.gnu.org/manual/devel/en/guix.html#Channels-with-Substitutes
>
> From 5955a4c3f913d1aa77ec3a27d6430f3dcf22aab6 Mon Sep 17 00:00:00 2001
> Message-ID: 
> <5955a4c3f913d1aa77ec3a27d6430f3dcf22aab6.1713969693.git.zimon.touto...@gmail.com>
> From: Simon Tournier 
> Date: Wed, 24 Apr 2024 16:39:10 +0200
> Subject: [PATCH] ci: Catch error for channel with substitutes.
>
> * guix/ci.scm (channel-with-substitutes-available): Catch all error when
> running 'find-latest-commit-with-substitutes'.  Move the warning when failing.
>
> Change-Id: I352e07f14417f77c7ebf0f40a01c6a2e58b15d78
> ---
>  guix/ci.scm | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/guix/ci.scm b/guix/ci.scm
> index 5d16ee69d0..b2077448b0 100644
> --- a/guix/ci.scm
> +++ b/guix/ci.scm
> @@ -336,10 +336,13 @@ (define (channel-with-substitutes-available chan url)
>  
>  If no commit with available substitutes were found, the commit field is set 
> to
>  false and a warning message is printed."
> -  (let ((commit (find-latest-commit-with-substitutes url)))
> -(unless commit
> -  (warning (G_ "could not find available substitutes at ~a~%")
> -   url))
> +  (let ((commit (catch #t
> +  (lambda ()
> +(find-latest-commit-with-substitutes url))
> +  (lambda _
> +(warning (G_ "could not find available substitutes at 
> ~a~%")
> + url)
> +#false
>  (channel
>   (inherit chan)
>   (commit commit
>
> base-commit: 10d0e2d3110e4be2bc6cfecb9a3abb83d8e1ddd6
> -- 
> 2.41.0

Friendly ping for this patch?


Cheers,
simon

bug#71151: time machine breaking

[Simon Tournier]

Hi Ale,

On Thu, 23 May 2024 at 19:31, Alexandre Hannud Abdo  wrote:

> https://gitlab.inria.fr/guix-hpc/open-science-days-tutorial/

Ouch, that’s unfortunate!

Using 6ba29e0, it works for me.

> $ guix time-machine --commit=b94724e8b2102be0fe9d19e9dfe44d6f7101bd4b -- 
> shell -CN --no-cwd python

[...]

> building 
> /gnu/store/vh6xam2bsqsm055sh7lhc8x7dh4wnw68-compute-guix-derivation.drv...
> Computing Guix derivation for 'x86_64-linux'... /Backtrace:
>    14 (primitive-load 
> "/gnu/store/pa74lqbhmq8xmvnjg98p1z6jq5xvr23w-compute-guix-derivation")

[...]

>    1419:15  1 (_ # 
> ("/gnu/store/mh01bp841xvcvv8mv6car7l92h6h19rk-curl-7.84?" ?) ?)
>    1419:15  0 (loop #f)
>
> ./guix/store.scm:1419:15: In procedure loop:
> ERROR:
>    1. &store-protocol-error:
>    message: 
> "`/gnu/store/bq54ayj2n661xqaiwj93f8nq4jvhcjs7-guix-1.4.0-19.7ca9809/bin/guix 
> substitute' died unexpectedly"
>    status: 1
> guix time-machine: error: You found a bug: the program 
> '/gnu/store/pa74lqbhmq8xmvnjg98p1z6jq5xvr23w-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "b94724e8b2102be0fe9d19e9dfe44d6f7101bd4b"; system: "x86_64-linux";
> host version: "aeba4849b42b4d3ac75341ac4b61843c1fe48181"; pull-version: 1).
> Please report the COMPLETE output above by email to .

And,

  guix time-machine --commit=aeba4849b42b4d3ac75341ac4b61843c1fe48181 \
-- time-machine --commit=b94724e8b2102be0fe9d19e9dfe44d6f7101bd4b \
-- shell -CN --no-cwd python

also works for me.  And I am able to build
/gnu/store/mh01bp841xvcvv8mv6car7l92h6h19rk-curl-7.84.0.drv, even it
appears that the substitute is available.

All in all, I have no idea where the issue could come from.  Any issue
on your side, e.g., disk space, network, daemon, etc.?

Cheers,
simon

bug#71286: Acknowledgement (build of /gnu/store/xjfs44qvk7rry6nbrbrd18irxdiycs2f-python-matplotlib-3.8.2.drv failed)

[Simon Tournier]

Hi,

On Sat, 01 Jun 2024 at 12:15, francismb via Bug reports for GNU Guix 
 wrote:

> the failure is gone (same hash, flaky test(s)?).

Well, I do not where the issue could come from.  I am not able to
reproduce.

Closing?

Cheers,
simon

bug#47144: [PATCH 3/3] gnu: patch: Graft to latest commit [security fixes].

[Simon Tournier]

Hi Maxim,

On Fri, 31 May 2024 at 21:49, Maxim Cournoyer  wrote:

> I preferred inheritance to avoid having to manually sync things in the
> long run... (hopefully the graft gets ungrafted before 'patch' amasses
> new phatces, but we never know...)

What would be the long run? ;-)

Well, from my perspective, there is nothing to manually sync in the
future.

I mean, the only patch applied to release “2.7.6” will be still required
for patch/fixed; hence one will need to do what I am proposing if
’patch’ is removed.  Else if ’patch’ receives some security fixes, then
it seems expected to assume that the fix will be included in the latest
patch (here ’patch/fixed’).  Last, please note that ’patch’ is barely
modified.

--8<---cut here---start->8---
$ git log --format="%cd %s" -- gnu/packages/base.scm | grep 'gnu: patch'
Thu May 30 11:35:13 2024 -0400 gnu: patch: Fix indentation.
Sun Apr 22 22:40:48 2018 +0200 gnu: patch: Work around a cross-compilation 
issue.
Wed Mar 14 22:11:34 2018 +0100 gnu: patch: Update to 2.7.6.
Fri Jun 12 15:46:25 2015 +0300 gnu: patch: Set PATH_MAX for Hurd systems.
Mon Mar 9 22:56:50 2015 -0400 gnu: patch: Update to 2.7.5.
Sat Mar 7 20:34:50 2015 -0500 Revert "gnu: patch: Update to 2.7.5."
Sun Mar 8 00:32:11 2015 +0100 gnu: patch: Update to 2.7.5.
Wed Feb 11 11:23:46 2015 +0100 gnu: patch: Update to 2.7.4.
Fri Feb 6 13:53:28 2015 +0100 gnu: patch: Add 2.7.4 and make it a replacement 
for the default one.
Sat Apr 27 00:23:19 2013 +0200 gnu: patch: Update to 2.7.1.
--8<---cut here---end--->8---

I still think that it eases to have the patch close to the source
instead of coming from inheritance. Anyway. :-)

Cheers,
simon

bug#59579: installing zbar prevents gdm to start on Ubuntu 22.04 foreign distro

[Simon Tournier]

Hi Maxim,

On Wed, 22 May 2024 at 12:14, Maxim Cournoyer  wrote:

> That'd be a welcome improvement!  It'd be nice before if you could
> confirm/infirm whether this was truly the issue, if you still have
> access to the VM.

Sadly, I do not have access anymore to this configuration.  I just
remember that I tweaked more than once some XDG_* variables.  They
introduced conflicts… I remember one specifically where I was unable to
login under X.

If I am able to replay some scenario, I will propose a paragraph. :-)

Let keep it open for some next weeks and close then since there is not
known issue with the current default provide by guix-install.sh.

Cheers,
simon

bug#47144: [PATCH 3/3] gnu: patch: Graft to latest commit [security fixes].

[Simon Tournier]

Hi Maxim,

On Thu, 30 May 2024 at 22:59, Maxim Cournoyer  wrote:

> +  (source (origin
> +(inherit (package-source patch))
> +(method git-fetch)
> +(uri (git-reference
> +  (url "https://git.savannah.gnu.org/git/patch.git";)
> +  (commit commit)))
> +(file-name (git-file-name name version))
> +(sha256
> + (base32
> +  "1bk38169c0xh01b0q0zmnrjqz8k9byz3arp4q7q66sn6xwf94nvz"

If I read correctly, (package-source patch) reads:

--8<---cut here---start->8---
(source (origin
  (method url-fetch)
  (uri (string-append "mirror://gnu/patch/patch-"
  version ".tar.xz"))
  (sha256
   (base32
"1zfqy4rdcy279vwn2z1kbv19dcfw25d2aqy9nzvdkq5bjzd0nqdc"))
  (patches (search-patches "patch-hurd-path-max.patch"
--8<---cut here---end--->8---

Therefore the only thing that is copied is the ’patches’ field.  Right?

I think it would easy the readability to avoid ’inherit’ and plainly
write ’patches’.


Cheers,
simon

bug#28084: lilypond, fontforge are not reproducible

[Simon Tournier]

Hi,

On ven., 10 mai 2024 at 14:17, Nicolas Graves  wrote:

> `guix challenge lilypond` now seems to pass, and "Created by FontForge
> ..." strings in emmentaler-*.svg files indeed indicate 1st Jan 1970.
>
> I guess we can close the issue @Zimoun?

Indeed, using Guix 6ba29e0, I do not see any reproducibility issue.  So
closing!

Thanks for the follow-up.

Cheers,
simon

bug#59579: installing zbar prevents gdm to start on Ubuntu 22.04 foreign distro

[Simon Tournier]

Hi Maxim,

On ven., 17 mai 2024 at 23:10, Maxim Cournoyer  
wrote:

> Just to be sure, do you have default XDG_* environment variables as
> configured by guix-install.sh:

Hum, no I did not have all these default.  It had been introduced after
my install of Guix, I guess. :-)

> --8<---cut here---start->8---
> export XCURSOR_PATH="${XCURSOR_PATH:-/usr/local/share/icons:/usr/share/icons}"
> export XDG_DATA_HOME="${XDG_DATA_HOME:-$HOME/.local/share}"
> export XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}"
> export XDG_STATE_HOME="${XDG_STATE_HOME:-$HOME/.local/state}"
> export XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"
> export XDG_CONFIG_DIRS="${XDG_CONFIG_DIRS:-/etc/xdg}"
> export XDG_CACHE_HOME="${XDG_CACHE_HOME:-$HOME/.cache}",
> --8<---cut here---end--->8---
>
> I think their absence used to cause this sort of behavior, since Guix
> setting it to something would wholly override the distribution-provided
> files.

Maybe we could add a short paragraph/section about that XDG_* variables
under (guix) Application Setup [1].  Although etc/guix-install.sh
already does the correct thing, it could be helpful if people tweak
stuff, I mean, always good to shortly document typical annoyances. :-)

1: https://guix.gnu.org/manual/devel/en/guix.html#Application-Setup

Cheers,
simon

bug#70838: guix pull fails

[Simon Tournier]

Hi,

On mer., 15 mai 2024 at 01:09, jerem...@pdp10.guru wrote:
>> As pointed by Chris [1], this report seems a duplicate of #70663.  Now,
>> it should be fixed.  Could you try again “guix pull” with a recent
>> revision?
>
> yes that guix pull was successful

Closing?  Since the issue is already tracked by #70663.

Cheers,
simon

bug#70838: guix pull fails

[Simon Tournier]

Hi Jeremiah,

On lun., 13 mai 2024 at 21:05, jerem...@pdp10.guru wrote:
>> That’s said, could you confirm (guix describe) that you are currently
>> pulling from 0f68306268773f0eaa4327e1f6fdcb39442e4a34?
> yes guix describe does display that checksum.
>
>> I think ’nss’ is substitutable, so I guess you are rebuilding from
>> source, right?
> exclusively.

As pointed by Chris [1], this report seems a duplicate of #70663.  Now,
it should be fixed.  Could you try again “guix pull” with a recent
revision?

1: bug#70838: guix pull fails
Christopher Baines 
Mon, 13 May 2024 18:45:46 +0100
id:87eda538s5@cbaines.net
https://issues.guix.gnu.org/70838
https://issues.guix.gnu.org/msgid/87eda538s5@cbaines.net
https://yhetil.org/guix/87eda538s5@cbaines.net

Cheers,
simon

bug#70838: guix pull fails

[Simon Tournier]

Hi Chris,

On lun., 13 mai 2024 at 18:45, Christopher Baines  wrote:

>> Hum, I do not know what could be the origin of the failure.  Maybe on
>> your side (free space).  Or maybe hardware specific?
>
> See https://issues.guix.gnu.org/70663 , that nss derivation is really
> hard to build so it's not surprising it failed.

Well, the reported failure just builds on my laptop in less than several
hours; IIRC, it took half hour to complete.

Maybe aside what is explained in #70663, one part of the issue is about
hardware.

Anyway, indeed this issue seems a duplicate of #70663.  Thanks for
the pointer.

Cheers,
simon

bug#70838: guix pull fails

[Simon Tournier]

Hi,

On mer., 08 mai 2024 at 22:09, jerem...@pdp10.guru wrote:
> ──⚙ guix pull 
>   
> [4/559]
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to 7b7f299 (1,287 new 
> commits)...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   7b7f299

[...]

> building /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv...
> \ 'check' phasebuild-log 30161 101
> [   OK ] Pkcs11ModuleTest.ListSlots (1 ms)
> [ RUN  ] Pkcs11ModuleTest.PublicCertificatesToken
> - 'check' phasebuild-log 30161 121
> [   OK ] Pkcs11ModuleTest.PublicCertificatesToken (1 ms)
> [ RUN  ] Pkcs11ModuleTest.PublicCertificatesTokenLookup
> \ 'check' phaseBacktrace:

[...]

> failed to compute the derivation for Guix (version: 
> "7b7f299bb493e485c5534b8c554e51d4f3a8c026"; system: "x86_64-linux";
> host version: "0f68306268773f0eaa4327e1f6fdcb39442e4a34"; pull-version: 1).
> Please report the COMPLETE output above by email to .

Well, first the authenticating message is weird because:

9edb3f66fd807b096b48283debdcddccfea34bad
AuthorDate: Tue May 26 22:30:51 2020 +0200
CommitDate: Tue May 26 22:30:51 2020 +0200

and

7b7f299bb493e485c5534b8c554e51d4f3a8c026
AuthorDate: Wed May 8 15:51:45 2024 +0200
CommitDate: Wed May 8 15:51:45 2024 +0200

Therefore, something seems unexpected here.  I am doubtful that the
message is accurate.

Second, the error message seems more accurate,

0f68306268773f0eaa4327e1f6fdcb39442e4a34
AuthorDate: Tue Apr 2 18:54:06 2024 +0200
CommitDate: Sat Apr 20 10:35:35 2024 +0200

I.e., with the 1,287 new commits.

That’s said, could you confirm (guix describe) that you are currently
pulling from 0f68306268773f0eaa4327e1f6fdcb39442e4a34?

I think ’nss’ is substitutable, so I guess you are rebuilding from
source, right?

Well, the build of ’nss’ works for me.

--8<---cut here---start->8---
$ guix build /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv --check

[...]

successfully built /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv
guix build: error: derivation 
`/gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv' may not be 
deterministic: output `/gnu/store/wkdc0z86av7jfkig7g4xphp6k52y82am-nss-3.99.0' 
differs
--8<---cut here---end--->8---

Hum, I do not know what could be the origin of the failure.  Maybe on
your side (free space).  Or maybe hardware specific?

Cheers,
simon

bug#70678: guix pull failed on commit 43a4215cad8c6da357f895569c0cedf5e854cee0

[Simon Tournier]

Hi,

Hum, initially I was inclined to close this bug as a transient error
from network.  However,

> ERROR:
>1. &http-get-error:
>uri: #< scheme: https userinfo: #f host: "ci.guix.gnu.org"
> port: #f path: "/nar/lzip/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash" query:
> #f fragment: #f>
>code: 504
>reason: "Gateway Time-out"
>2. &message:
> "https://ci.guix.gnu.org/nar/lzip/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash:
> HTTP download failed: 504 (\"Gateway Time-out\")"
> substitution of /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash failed
> Backtrace:

should not raise this ugly backtrace.  Well, I do not know if it is a
bug or a wishlist. ;-)  It could be nice to handle that.

Cheers,
simon

PS: Since the tracker has already some concrete bug, I am also fine to
close this wishlist. :-)

bug#70215: Documentation about uninstalling

[Simon Tournier]

Hi,

I mark this bug as done since the documentation already contains how to
uninstall.

On sam., 13 avril 2024 at 08:25, Bengt Richter  wrote:

>> Nevertheless, `./guix-install.sh --dry-run --uninstall` would be nice.

Well, it would be easy to write a Bash function wrapping ’rm’ and
displaying the files instead of removing them.

Who wants to give a try? ;-)

>> However the script is over 800 lines long. In bash! :-(
>> IMO before increasing script complexity with a new feature, we should
>> rewrite it to some reasonable language, preferably Guile Scheme. Or at
>> least Python.

The maintenance burden Bash vs Python is an opinion. :-)

Well, a rewrite in Scheme/Guile would require to have Guile already
installed to run such script.  And that’s not an assumption I would
do. ;-)


> Well, guix pack is already scheme, right? Why couldn't it invoke uninstall 
> after
> safely having completed packing the uninstall-victim-files ?

Well, it’s appears to me an heavy hammer.  The best seems to have an
option displaying the files that need to be removed for uninstalling.

Let’s discuss that on guix-devel.  Because it’s not related to a
bug. :-)


Cheers,
simon

bug#70611: outputs are baked in gexps, cannot be removed in derived packages

[Simon Tournier]

Hi,

On sam., 27 avril 2024 at 12:55, Maxim Cournoyer  
wrote:

> --8<---cut here---start->8---
> builder for 
> `/gnu/store/f2pdg9m5q3bxrlahjvlrdgw41x6kp3zd-llvm-cling-18-20240227-01.drv' 
> failed to produce output path 
> `/gnu/store/m1z5257hj5vwc2rl47wkpf0wmr6x0bq2-llvm-cling-18-20240227-01-opt-viewer'
> --8<---cut here---end--->8---

Yeah something is unexpected.

--8<---cut here---start->8---
$ ./pre-inst-env guix build llvm-cling -d --no-grafts \
| xargs guix drv-show | recsel -p outputs
outputs: 
+ 
/gnu/store/m1z5257hj5vwc2rl47wkpf0wmr6x0bq2-llvm-cling-18-20240227-01-opt-viewer
   [opt-viewer]
+ /gnu/store/bg3xs25xyllpzw322sqcc8ipw9q8lph6-llvm-cling-18-20240227-01 
 [out]
--8<---cut here---end--->8---

But from ’guix repl’

--8<---cut here---start->8---
scheme@(guix-user)> ,pp (package-outputs llvm-cling-2)
$6 = ("out")
--8<---cut here---end--->8---

And the package arguments reads:

--8<---cut here---start->8---
scheme@(guix-user)> ,pp (package-arguments llvm-cling-2)
$5 = (#:configure-flags
 #
 #:build-type
 "Release"
 #:phases
 # "/share")))
 (mkdir-p opt-viewer-share)
 (rename-file (string-append # 
"/share/opt-viewer") opt-viewer-share)
  gnu/packages/llvm.scm:612:6 7f6a06421090>:out>
  (delete (quote install-opt-viewer)))
 gnu/packages/llvm.scm:2443:10 7f6a06421060>)
--8<---cut here---end--->8---

Concretely,
/gnu/store/rhb3lmkbp5d92c0x0sxkmfwbpbs4b4hp-llvm-cling-18-20240227-01-builder
reads,

--8<---cut here---start->8---
(define %outputs
  (list
   (cons "out"
 ((@
   (guile)
   getenv)
  "out"
(define %output
  (assoc-ref %outputs "out"))
(cmake-build
[...]

 #:phases
 (modify-phases
 (modify-phases %standard-phases
   (add-after
   (quote unpack)
   (quote change-directory)
 (lambda _
   (chdir "llvm")))
   (add-after
   (quote install)
   (quote install-opt-viewer)
 (lambda*
 (#:key outputs #:allow-other-keys)
   (let*
   ((opt-viewer-share
 (string-append
  ((@
(guile)
getenv)
   "opt-viewer")
  "/share")))
 (mkdir-p opt-viewer-share)
 (rename-file
  (string-append
   ((@
 (guile)
 getenv)
"out")
   "/share/opt-viewer")
  opt-viewer-share)
   (delete
(quote install-opt-viewer)))
--8<---cut here---end--->8---

Therefore, the bug comes from an incorrect derivation (drv) file.  It
contains an output that it should not.

Well, I have not investigated further… Probably an issue with code
staging (what is evaluated when).


Cheers,
simon

bug#70588: hash mismatch error and stop fallback

[Simon Tournier]

Hi,

On lun., 02 oct. 2017 at 17:09, l...@gnu.org (Ludovic Courtès) wrote:

> The problem is that the hash check is performed by guix-daemon itself,
> not by “guix perform-download”.  So when guix-daemon diagnoses a hash
> mismatch, it’s too late and we cannot try again and use the
> content-addressed mirror.

This quote from [1].  Well, why not run a sequence of “guix download”
then “guix build”?  Ah the store item would be hashed twice.  Let try to
avoid this sub-optimized behaviour.

The only way to avoid hashing twice is to extend the protocol of
guix-daemon.  Because currently it reads,

/* Check the hash. */
Hash h2 = recursive ? hashPath(ht, actualPath).first : hashFile(ht, 
actualPath);
if (h != h2) {
if (settings.printBuildTrace)
printMsg(lvlError, format("@ hash-mismatch %1% %2% %3% %4%")
 % path % i->second.hashAlgo
 % printHash16or32(h) % printHash16or32(h2));
throw BuildError(format("hash mismatch for store item '%1%'") % 
path);
}

with the call under error catch:

/* Compute the FS closure of the outputs and register them as
   being valid. */
registerOutputs();

[...]

} catch (BuildError & e) {


Thus the number of solutions is very limited. :-)

Well, from my understanding, moving elsewhere in guix-daemon the check
of the hash appears to me too cumbersome.  Therefore, the only way is to
replace this ’BuildError’ by something that is not an error and do not
register the item.

Easier to say than to implement.  Again from my understanding, each
strategy for downloading is seen by the daemon as an element of a list
of independent builds and these elements are tried in sequence.
Therefore, we need to special case in order to be able to distinguish
different kind of failures.

All in all, this bug (missing feature):

Other said, hash mismatch should be raised and obviously the content
must be discarded; then the hash mismatch should be considered as “not
found” so let try the next strategy for downloading the content.

is not straightforward to fix. :-)  Need for more thought…


Cheers,
simon


1: bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes 
fail
l...@gnu.org (Ludovic Courtès)
Mon, 02 Oct 2017 17:09:39 +0200
id:87o9ppoabw@gnu.org
https://issues.guix.gnu.org/28659
https://issues.guix.gnu.org/msgid/87o9ppoabw@gnu.org
https://yhetil.org/guix/87o9ppoabw@gnu.org

bug#70588: hash mismatch error and stop fallback

[Simon Tournier]

Hi,

Considering something from the past – well to my knowledge it is still
an issue with the current implementation and such it will be a issue for
the future. ;-)

For instance, the R package MASS from 2019 (Guix revision 711cec):
because the CRAN project did some in-place replacements, we have a hash
mismatch and all the process stops.

--8<---cut here---start->8---
$ guix build 
/gnu/store/wfq2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivation will be built:
  /gnu/store/wfq2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv
building /gnu/store/wfq2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv...

Starting download of 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
>From http://cran.r-project.org/src/contrib/MASS_7.3-51.4.tar.gz...
download failed "http://cran.r-project.org/src/contrib/MASS_7.3-51.4.tar.gz"; 
404 "Not Found"

Starting download of 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
>From http://cran.rstudio.com/src/contrib/MASS_7.3-51.4.tar.gz...
download failed "http://cran.rstudio.com/src/contrib/MASS_7.3-51.4.tar.gz"; 404 
"Not Found"

Starting download of 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
>From http://cran.univ-lyon1.fr/src/contrib/MASS_7.3-51.4.tar.gz...
following redirection to 
`https://pbil.univ-lyon1.fr/CRAN/src/contrib/MASS_7.3-51.4.tar.gz'...
download failed 
"https://pbil.univ-lyon1.fr/CRAN/src/contrib/MASS_7.3-51.4.tar.gz"; 404 "Not 
Found"

Starting download of 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
>From http://cran.ism.ac.jp/src/contrib/MASS_7.3-51.4.tar.gz...
download failed "http://cran.ism.ac.jp/src/contrib/MASS_7.3-51.4.tar.gz"; 404 
"Not Found"

Starting download of 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
>From http://cran.stat.auckland.ac.nz/src/contrib/MASS_7.3-51.4.tar.gz...
download failed 
"http://cran.stat.auckland.ac.nz/src/contrib/MASS_7.3-51.4.tar.gz"; 404 "Not 
Found"

Starting download of 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
>From http://cran.mirror.ac.za/src/contrib/MASS_7.3-51.4.tar.gz...
download failed "http://cran.mirror.ac.za/src/contrib/MASS_7.3-51.4.tar.gz"; 404 
"Not Found"

Starting download of 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
>From http://cran.csie.ntu.edu.tw/src/contrib/MASS_7.3-51.4.tar.gz...
download failed "http://cran.csie.ntu.edu.tw/src/contrib/MASS_7.3-51.4.tar.gz"; 
404 "Not Found"

Starting download of 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
>From http://cran.r-project.org/src/contrib/Archive/MASS/MASS_7.3-51.4.tar.gz...
downloading from 
http://cran.r-project.org/src/contrib/Archive/MASS/MASS_7.3-51.4.tar.gz ...
 MASS_7.3-51.4.tar.gz  476KiB 2.1MiB/s 00:00 ▕██▏ 100.0%
sha256 hash mismatch for 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz:
  expected hash: 0x1ckf51y851g0kvbhsgdxb26vfpmbw3xdbcnh3ck7fjm13da4cr
  actual hash:   1swfd4jnqhsb2imznib629bywrxah7b63yqxhwhd9bhyaji70hl4
hash mismatch for store item 
'/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz'
build of /gnu/store/wfq2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv 
failed
View build log at 
'/var/log/guix/drvs/wf/q2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv.gz'.
guix build: error: build of 
`/gnu/store/wfq2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv' failed
--8<---cut here---end--->8---


When the source is correctly available in SWH:

--8<---cut here---start->8---
$ guix build 
/gnu/store/wfq2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv
The following derivation will be built:
  /gnu/store/wfq2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv
building /gnu/store/wfq2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv...

[...]

Starting download of 
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
>From 
>https://archive.softwareheritage.org/api/1/content/sha256:9911d546a8d29dc906b46cb53ef8aad76d23566f4fc3b52778a1201f8a9b2c74/raw/...
downloading from 
https://archive.softwareheritage.org/api/1/content/sha256:9911d546a8d29dc906b46cb53ef8aad76d23566f4fc3b52778a1201f8a9b2c74/raw/
 ...
 raw/  476KiB 9.9MiB/s 00:00 ▕██▏ 100.0%
successfully built 
/gnu/store/wfq2ji5x9awgyk680i1vv95hq75nx3vv-MASS_7.3-51.4.tar.gz.drv
/gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz

$ guix hash /gnu/store/gxbam95zqjaxdd6303j97z4djr907yzn-MASS_7.3-51.4.tar.gz
0x1ckf51y851g0kvbhsgdxb26vfpmbw3xdbcnh3ck7fjm13da4cr
--8<---cut here---end--->8---

Therefore, the bug is to not consider a hash mismatch a

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

[Simon Tournier]

Hi,

Out of any network, I get this error:

--8<---cut here---start->8---
$ guix time-machine --commit=1971d11d -- describe
guix time-machine: error: failed to load 
'/home/simon/.config//guix/channels.scm':
guix/build/download.scm:399:8: In procedure open-socket-for-uri:
In procedure getaddrinfo: Name or service not known
--8<---cut here---end--->8---

And that’s annoying.  It comes from:

$ cat /home/simon/.config//guix/channels.scm
(use-modules (guix ci))

(list (channel-with-substitutes-available
   %default-guix-channel
   "https://ci.guix.gnu.org";))

as documented by section “Channels with Substitutes” [1].

Specifically, the error is raised by the procedure ’load*’ called by
’channel-list’ inside ’load-channels’.  Other said, ’load*’ runs the
procedure ’channel-with-substitutes-available’ which asks network via
the procedure ’find-latest-commit-with-substitutes’.

I think this is incorrect; the correct behaviour seems trying to do as
most as possible.  With the attached patch, I get:

--8<---cut here---start->8---
$ ./pre-inst-env guix time-machine --commit=1971d11d -- describe
guix time-machine: warning: could not find available substitutes at 
https://ci.guix.gnu.org
  guix 1971d11
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 1971d11db9ed9683d5036cd4c62deb564842e1f6
--8<---cut here---end--->8---

Obviously, the option ’-q’ allows to bypass the problem. :-)  However,
it’s annoying because the default file channels.scm can be complex and
it still should work without any tweak, IMHO.

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

WDYT?

Cheers,
simon


1: https://guix.gnu.org/manual/devel/en/guix.html#Channels-with-Substitutes

>From 5955a4c3f913d1aa77ec3a27d6430f3dcf22aab6 Mon Sep 17 00:00:00 2001
Message-ID: <5955a4c3f913d1aa77ec3a27d6430f3dcf22aab6.1713969693.git.zimon.touto...@gmail.com>
From: Simon Tournier 
Date: Wed, 24 Apr 2024 16:39:10 +0200
Subject: [PATCH] ci: Catch error for channel with substitutes.

* guix/ci.scm (channel-with-substitutes-available): Catch all error when
running 'find-latest-commit-with-substitutes'.  Move the warning when failing.

Change-Id: I352e07f14417f77c7ebf0f40a01c6a2e58b15d78
---
 guix/ci.scm | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/guix/ci.scm b/guix/ci.scm
index 5d16ee69d0..b2077448b0 100644
--- a/guix/ci.scm
+++ b/guix/ci.scm
@@ -336,10 +336,13 @@ (define (channel-with-substitutes-available chan url)
 
 If no commit with available substitutes were found, the commit field is set to
 false and a warning message is printed."
-  (let ((commit (find-latest-commit-with-substitutes url)))
-(unless commit
-  (warning (G_ "could not find available substitutes at ~a~%")
-   url))
+  (let ((commit (catch #t
+  (lambda ()
+(find-latest-commit-with-substitutes url))
+  (lambda _
+(warning (G_ "could not find available substitutes at ~a~%")
+ url)
+#false
 (channel
  (inherit chan)
  (commit commit

base-commit: 10d0e2d3110e4be2bc6cfecb9a3abb83d8e1ddd6
-- 
2.41.0

bug#63267: gcc-toolchain is missing libstdc++.so

[Simon Tournier]

Hi,

On mer., 17 avril 2024 at 05:21, John Kehayias via Bug reports for GNU Guix 
 wrote:

> I've just pushed, as b47ae1ecc43baaf726701ab2d2f810ecfaa75428,

Cool!  Thank you for crossing the finish line.

Cheers,
simon