bug#62174: Cannot use modules with an inferior kernel.

[Robby Zambito]

Liliana Marie Prikler  writes:
> I think you should try to pin the kernel modules as well.  If that
> still doesn't work as intended (it very well might), we have a proper
> case of something that should work but doesn't.
>
> Cheers

Thanks for the suggestion. I tested with the following:

```
(define-values (rz/linux rz/linux-kernel-modules)
  (let* ((channels
  (list (channel
 (name 'guix)
 (url "https://git.savannah.gnu.org/git/guix.git";)
 (commit "d37b467631d5b0e965ea933b8bda8448993580e9"
 (inferior (inferior-for-channels channels))
 (kernel-version "6.1.15"))
(values (first (lookup-inferior-packages inferior "linux-libre" 
kernel-version))
(list (first (lookup-inferior-packages inferior 
"v4l2loopback-linux-module"))

(operating-system
  ...
  (kernel rz/linux)
  (kernel-loadable-modules rz/linux-kernel-modules)
  ...)
```

But I receive a different error now:

```
running profile hook of type 'linux-module-database'...
Backtrace:
   1 (primitive-load "/gnu/store/7ha0kn8fz8yfi26m3m8997wlc8m?")
In ice-9/boot-9.scm:
   2007:7  0 (error _ . _)

ice-9/boot-9.scm:2007:7: In procedure error:
Specified Linux kernel and Linux kernel modules are not all of the same version
```

However, if I use the most recent kernel version available in the
inferior...

```
(define-values (rz/linux rz/linux-kernel-modules)
  (let* ((channels
  (list (channel
 (name 'guix)
 (url "https://git.savannah.gnu.org/git/guix.git";)
 (commit "d37b467631d5b0e965ea933b8bda8448993580e9"
 (inferior (inferior-for-channels channels))
 (kernel-version "6.2.2"))
(values (first (lookup-inferior-packages inferior "linux-libre"))
(list (first (lookup-inferior-packages inferior 
"v4l2loopback-linux-module"))
```

It actually works! So it seems that the problem is specifically with
using kernel modules with a kernel version other than the latest
linux-libre kernel from an inferior. I also tried using a specific
kernel version without an inferior like so:

```
(operating-system
  ...
  (kernel (specification->package "linux-libre@6.1.15"))
  (kernel-loadable-modules (list 
(specification->package"v4l2loopback-linux-module")))
  ...)
```

And that works as well.

TL;DR: The issue has been narrowed down to using kernel modules with a
kernel from an inferior besides the latest kernel from that inferior.

bug#62160: Guix reference manual link from guix.gnu.org?

[Bengt Richter]

Hi,

On +2023-03-14 18:35:36 +0100, b...@bokr.com wrote:
[...]
> BUT: A nit: 
> 
> In firefox-esr, if you do "save-as ...", it will prompt with a file name
> seemingly pretty directly copying the URL characters, in this case
> "GNU Guix Reference Manual.html" -- which has spaces in it.
>
Sorry, I think it just copies whatever XXX is in the html header as
   XXX
but some sites have weird strings in their titles, so the problem
remains..

> So my nuisance work flow is:
>- copy url from browser line into clipboard,
>- switch to a terminal,
>- touch $(sanitize-clipboard-url), ;; hack also puts clean name-string 
> back in clipboard
>- switch to browser
>- delete undesired file name string from prompt by pasting in the clean 
> name string
>- click save-as
> 
> I would really like Mozilla to solve this with configurable sanitization 
> options
> for the file name. Especially if I am looking at a page with an URL that has
> weird non-ascii/utf-8 characters besides spaces.
> 
> But until Mozilla offers that, could GNU web pages have some kind of alias 
> link on them
> with a sanitized name to do save-link-as (not plain save-as) with,
> so as to get a clean name?

I would still like this option, but I'm not sure how to implement
such an alias link in a static page.
IWG no problem if the header is dynamically generated ??

--
Regards,
Bengt Richter

bug#44877: bug#62140: enable LVM in Grub

[Emmanuel Beffara]

De Michael Rohleder le 13/03/2023 à 14:56:
> Hello Emmanuel!
> 
> Thx for the report!
> 
> I think this is bug 44877, maybe we can/should merge it.
> Here [1] is a patch (and testcase).
> 
> 
> [1]  https://issues.guix.gnu.org/60442

Indeed, it seems to be the same issue.

However, the patch sets the value of `GRUB_PRELOAD_MODULES`, which afaik is
used by `grub-mkconfig` to produce `grub.cfg`, but there seems to be code in
`grub.scm` that also produces `grub.cfg`, and no call to `grub-mkconfig`
there. I'm not sure I understand how all this works anyway…

-- 
Emmanuel

bug#62174: Cannot use modules with an inferior kernel.

[Liliana Marie Prikler]

Am Montag, dem 13.03.2023 um 23:27 -0400 schrieb Robby Zambito:
> Hi,
> 
> I use an inferior to pin my kernel version, but it seems like I
> cannot
> use modules with it. The following works fine:
> 
> ```
> (use-package-modules linux)
> (operating-system
>   ...
>   (kernel linux-libre)
>   (kernel-loadable-modules (list v4l2loopback-linux-module))
>   ...)
> ```
> 
> As does the following:
> 
> ```
> (define rz/linux
>   (let* ((channels
>   (list (channel
>  (name 'guix)
>  (url "https://git.savannah.gnu.org/git/guix.git";)
>  (commit
> "c81d2d448cbd051800867fe3f4b82ef3f4380ebf"
>  (inferior (inferior-for-channels channels))
>  (kernel-version "6.1.15"))
>     (first (lookup-inferior-packages inferior "linux-libre" kernel-
> version
> 
> (operating-system
>   ...
>   (kernel rz/linux)
>   ...)
> ```
> 
> However when I combine the two (using the inferior for the kernel +
> specify modules)...
> 
> ```
> (operating-system
>   ...
>   (kernel rz/linux)
>   (kernel-loadable-modules (list v4l2loopback-linux-module))
>   ...)
> ```
> 
> I get the following error:
> 
> ```
> Backtrace:
> In guix/store.scm:
>    659:37 19 (thunk)
>    1298:8 18 (call-with-build-handler #
> …)
>   2168:25 17 (run-with-store #
> …)
> In guix/scripts/system.scm:
>     843:2 16 (_ _)
>     717:8 15 (_ #)
> In gnu/system.scm:
>   1307:19 14 (operating-system-derivation _)
> In gnu/services.scm:
>   1140:36 13 (_ _)
> In srfi/srfi-1.scm:
>    586:29 12 (map1 (#< type: #
> …))
>    586:29 11 (map1 (#< type: #
> …))
>    586:29 10 (map1 (#< type: #
> …))
>    586:29  9 (map1 (#< type: #
> …))
>    586:17  8 (map1 (#< type: # …>))
> In gnu/services.scm:
>    951:29  7 (linux-builder-configuration->system-entry _)
> In guix/profiles.scm:
>     438:4  6 (packages->manifest _)
> In srfi/srfi-1.scm:
>    586:17  5 (map1 ((#)
> …))
> In guix/inferior.scm:
>     549:2  4 (loop (#)
> …)
>     529:4  3 (inferior-package-input-field (#)
> …)
>    473:18  2 (inferior-package-field (#)
> …)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure struct-vtable: Wrong type argument in position 1
> (expecting struct): (# linux-libre@6.1.15 7ff5261088a0>)
> ```
> 
> It seems to me like this is a bug. If I am mistaken, some guidance
> would be appreciated.
I think you should try to pin the kernel modules as well.  If that
still doesn't work as intended (it very well might), we have a proper
case of something that should work but doesn't.

Cheers

bug#62176: [PATCH] Update Mesa to 22.2

[Liliana Marie Prikler]

Am Dienstag, dem 14.03.2023 um 06:31 +0100 schrieb Dr. Arne
Babenhauserheide:
> Hi,
> 
> the attached patch updates mesa to version 22.
Please do one patch per package and don't mix stylistic and functional
changes.

> The patch from core-updates is still missing. It may be a good idea
> to add that, too.
libdrm and mesa need to go through core-updates, wayland-protocols on
the other hand has few dependents and could go to master as-is.  Please
split the bugs accordingly for quicker processing.

Cheers

bug#62192: Test failures in binfmt emulated builds

[Greg Hogan]

The following emulated build using binfmt should work according to the
documentation example at
https://guix.gnu.org/manual/en/html_node/Native-Builds.html

$ uname -m
x86_64


The package was previously built on an aarch64 offload machine:

$ file $(guix build --system=aarch64-linux hello)/bin/hello
/gnu/store/s2qnbdlrwlx47h5p6rxlylny1259srmj-hello-2.12.1/bin/hello:
ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically
linked, interpreter
/gnu/store/gfjp8gfv4xxschbaxvldpigadfwqazhw-glibc-2.33/lib/ld-linux-aarch64.so.1,
for GNU/Linux 2.6.32, stripped


Successfully executed using binfmt emulation:

$ $(guix build --system=aarch64-linux hello)/bin/hello
Hello, world!


A locally emulated check build fails during the test phase:

$ guix describe
Generation 35 Mar 13 2023 13:37:24 (current)
  guix 1ed227d
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 1ed227d7952af48efe50a2f6c9537e17c356daa1

$ guix build --check --system=aarch64-linux --verbosity=1 hello
The following derivation will be built:
  /gnu/store/sg9mpl4nf7j2w8bmv5q4725gpirhi225-hello-2.12.1.drv

building /gnu/store/sg9mpl4nf7j2w8bmv5q4725gpirhi225-hello-2.12.1.drv...
| 'check' phasebuilder for
`/gnu/store/sg9mpl4nf7j2w8bmv5q4725gpirhi225-hello-2.12.1.drv' failed
with exit code 1
build of /gnu/store/sg9mpl4nf7j2w8bmv5q4725gpirhi225-hello-2.12.1.drv failed
View build log at
'/var/log/guix/drvs/sg/9mpl4nf7j2w8bmv5q4725gpirhi225-hello-2.12.1.drv.gz'.
guix build: error: build of
`/gnu/store/sg9mpl4nf7j2w8bmv5q4725gpirhi225-hello-2.12.1.drv' failed


$ zcat /var/log/guix/drvs/sg/9mpl4nf7j2w8bmv5q4725gpirhi225-hello-2.12.1.drv.gz
[...]
Test suite failed, dumping logs.

--- ./test-suite.log 


   GNU Hello 2.12.1: ./test-suite.log


# TOTAL: 7
# PASS:  4
# SKIP:  1
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/atexit-1


FAIL tests/atexit-1 (exit status: 1)

SKIP: tests/greeting-2
==

./tests/greeting-2: Skipping test: not a full moon night
SKIP tests/greeting-2 (exit status: 77)

FAIL: tests/operand-1
=

1,2c1,2
< hello: extra operand: first
< Try 'hello --help' for more information.
---
> ./hello: extra operand: first
> Try './hello --help' for more information.
FAIL tests/operand-1 (exit status: 1)


error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("check" "-j"
"2") exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 15.0 seconds
command "make" "check" "-j" "2" failed with status 2

bug#62160: Guix reference manual link from guix.gnu.org?

[bokr]

On +2023-03-14 12:29:11 +0100, Simon Tournier wrote:
> Hi Simon,
> 
> On Mon, 13 Mar 2023 at 13:11, Simon Josefsson via Bug reports for GNU Guix 
>  wrote:
> 
> > I often go to guix.gnu.org to read the (excellent!) Guix manual.  This
> > leads to this click pattern: guix.gnu.org -> Help -> GNU Guix Manual
> > 1.4.0 which leads me to a page (written in english) to chose language
> > of the manual -- https://guix.gnu.org/en/manual/ -- and when I chose
> > English I get a page to chose format of manual --
> > https://guix.gnu.org/en/manual/en/ -- and that choice takes a split
> > second cognitive load.
> 
> Well, personally I never read en/manual/ but always en/manual/devel/. :-)
> 
> And I have a short-cut (or bookmark) for opening
> .
>
[...]

> Well, I do not have an opinion since I barely read released manual but
> only the more accurate devel manual.
> 
> However, my preference is about ’entirely on one page’ an not ’with a
> separate page per node’ because ’entirely on one page’ eases Control-f
> for searching. :-)
> 

I like that too :)

To work off-line, I like to do save-as to some-name.html
with which firefox creates a directory "some-name_files"
for images and css style stuff etc.

BUT: A nit: 

In firefox-esr, if you do "save-as ...", it will prompt with a file name
seemingly pretty directly copying the URL characters, in this case
"GNU Guix Reference Manual.html" -- which has spaces in it.

So my nuisance work flow is:
   - copy url from browser line into clipboard,
   - switch to a terminal,
   - touch $(sanitize-clipboard-url), ;; hack also puts clean name-string back 
in clipboard
   - switch to browser
   - delete undesired file name string from prompt by pasting in the clean name 
string
   - click save-as

I would really like Mozilla to solve this with configurable sanitization options
for the file name. Especially if I am looking at a page with an URL that has
weird non-ascii/utf-8 characters besides spaces.

But until Mozilla offers that, could GNU web pages have some kind of alias link 
on them
with a sanitized name to do save-link-as (not plain save-as) with,
so as to get a clean name?

[...]
> 
> Well, in addition, I would like to have a page proposition the manual
> for all the languages, as we have now.  For example, these two webpages:
> 
> https://guix.gnu.org/en/manual/devel/
> https://guix.gnu.org/fr/manual/devel/
>
+1 :)
--
Regards,
Bengt Richter

bug#62177: [PATCH] [WIP] update node to version 16

[Dr. Arne Babenhauserheide]

Hi Jelle,

Jelle Licht  writes:
> Issue 59188 (https://issues.guix.gnu.org/59188) already updates node to
> the 18.X LTS series. Would that version also work for you, or do you
> have a specific need for the 16.X series? I ask because the "active" LTS
> version is 18, while the 16 "maintenance" LTS window already closes on
> 2023-09-11, which is (IMHO) pretty soon.

Version 18 is even better :-)

Thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

bug#49775: can't type in Matrix ID in Nheko

[Csepp]

Michael Rohleder  writes:

> [[PGP Signed Part:Undecided]]
> Hi Raingloom!
>
> Thx for the bug-report!
>
> Is this still reproducable?
> And if so, is this on a foreign distro?

Seems to work now.

bug#50092: The 'sqlparse<0.4.0, >=0.3.0' distribution was not found and is required by mycli

[Rostislav Svoboda]

Hello Michael, the bug doesn't come up anymore. Thanks.
Chers Bost

bug#62160: Guix reference manual link from guix.gnu.org?

[Simon Tournier]

Hi Simon,

On Mon, 13 Mar 2023 at 13:11, Simon Josefsson via Bug reports for GNU Guix 
 wrote:

> I often go to guix.gnu.org to read the (excellent!) Guix manual.  This
> leads to this click pattern: guix.gnu.org -> Help -> GNU Guix Manual
> 1.4.0 which leads me to a page (written in english) to chose language
> of the manual -- https://guix.gnu.org/en/manual/ -- and when I chose
> English I get a page to chose format of manual --
> https://guix.gnu.org/en/manual/en/ -- and that choice takes a split
> second cognitive load.

Well, personally I never read en/manual/ but always en/manual/devel/. :-)

And I have a short-cut (or bookmark) for opening
.


> How about these changes to improve user experience?
>
> 1) The link guix.gnu.org -> Help -> GNU Guix Manual 1.4.0 goes directly
> to the split-node https://guix.gnu.org/en/manual/en/html_node/

Well, I do not have an opinion since I barely read released manual but
only the more accurate devel manual.

However, my preference is about ’entirely on one page’ an not ’with a
separate page per node’ because ’entirely on one page’ eases Control-f
for searching. :-)


>   1b) The link could respect the language-choice for the web-site,
> i.e., so if I'm browsing https://guix.gnu.org/de/ it should directly
> link me to https://guix.gnu.org/de/manual/de/html_node/ instead.

With this change, where can I choose the language for the manual?

The workflow would be,

From https://guix.gnu.org/
Click top right to language and select one, say French
Then click Aide -> Manuel and it would open the manual in French.

so I would have to come back the front page to switch from one language
to the other.  Right?

Well, in addition, I would like to have a page proposition the manual
for all the languages, as we have now.  For example, these two webpages:

https://guix.gnu.org/en/manual/devel/
https://guix.gnu.org/fr/manual/devel/

serve the same choice and I would like to keep it somewhere.

> 2) Add links to the PDF variant and full-HTML variants in the top-right
> menu where different languages are shown.

Do you mean add an item to the list,

--8<---cut here---start->8---
  ,(menu-dropdown
#:label (C_ "website menu" "Help")
[...]
 (menu-item #:label "All"
[...]
 (menu-item #:label (C_ "website menu"
(string-append "GNU Guix Manual "
[...]
 (menu-item #:label "GNU Guix Manual (latest)"
[...]
 (menu-item #:label "Guix Reference Card"
[...]
 (menu-item #:label "Videos"
[...]
 (menu-item #:label "Cookbook"
[...]
 (menu-item #:label "GNU Manuals"
[...]
 (menu-item #:label "Wiki"
[...]
 (menu-item #:label "IRC Chat"
[...]
 (menu-item #:label "Mailing Lists"
--8<---cut here---end--->8---



?


Cheers,
simon

bug#62181: [PATCH 2/2] gnu: guile-gnutls: Do not expect gnulib shebangs to work.

[Vivien Kraus via Bug reports for GNU Guix]

* gnu/packages/tls.scm (guile-gnutls) [phase patch-more-shebangs]: Fix how
autogen.sh invokes gnulib-tool, and how configure.ac invokes git-version-gen,
so as not to rely on shebangs.
---
 gnu/packages/tls.scm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index 81d90c86ae..5a44fa89dc 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls.scm
@@ -417,6 +417,12 @@ (define-public guile-gnutls
   #~(modify-phases %standard-phases
   (add-after 'unpack 'patch-more-shebangs
 (lambda _
+  (substitute* "autogen.sh"
+(("\\$gnulib_tool \\$gnulib_tool_options")
+ "sh $gnulib_tool $gnulib_tool_options"))
+  (substitute* "configure.ac"
+(("build-aux/git-version-gen")
+ "sh build-aux/git-version-gen"))
   (for-each patch-shebang
 '("autopull.sh" "autogen.sh"
   (replace 'bootstrap
-- 
2.39.2

bug#62181: [PATCH 1/2] gnu: gnulib: Reset the shebangs.

[Vivien Kraus via Bug reports for GNU Guix]

* gnu/packages/build-tools.scm (gnulib) [phase reset-shebangs]: After
installation, rewrite the /gnu/store shebangs in the distributed build-aux
files.
[inputs, native-inputs]: Add bash-minimal.
[phase let-autogen-execute-gnulib-tool]: Specify a shell to execute
gnulib-tool from autogen.sh.
---
 gnu/packages/build-tools.scm | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/build-tools.scm b/gnu/packages/build-tools.scm
index 28ab77bbb4..f93a72f2f5 100644
--- a/gnu/packages/build-tools.scm
+++ b/gnu/packages/build-tools.scm
@@ -973,12 +973,32 @@ (define (find-ucd-files . names)
("NormalizationTest.txt" . "uninorm")
("auxiliary/GraphemeBreakTest.txt" . "unigbrk")
("auxiliary/WordBreakTest.txt" . "uniwbrk")))
-(delete-file "gen-uni-tables")))
-(inputs ;; Shebangs for some auxiliary build files.
- (list python perl clisp))
+(delete-file "gen-uni-tables"
+  (add-after 'install 'reset-shebangs
+(lambda _
+  (for-each
+   (lambda (file)
+ (false-if-exception
+  ;; Might fail on binary files, this is not a problem.
+  (substitute* file
+((#$(file-append (this-package-native-input "bash-minimal")
+ "/bin/sh"))
+ "/bin/sh")
+((#$(file-append (this-package-native-input "python")
+ "/bin/python3"))
+ "/usr/bin/env python3")
+((#$(file-append (this-package-native-input "perl")
+ "/bin/perl"))
+ "/usr/bin/perl")
+((#$(file-append (this-package-native-input "clisp")
+ "/bin/clisp"))
+ "/usr/bin/clisp"
+   (find-files (string-append #$output "/src/gnulib"
+(inputs ;; Shebang for gnulib-tool
+ (list bash-minimal))
 (native-inputs
  (list
-  python perl clisp
+  bash-minimal python perl clisp
   ;; Unicode data:
   ucd-next
   ;; Programs for the tests:
-- 
2.39.2

bug#62181: [PATCH 0/2] Re: bug#62181: Gnulib package keeps references to clisp, Python, Perl, and Bash

[Vivien Kraus via Bug reports for GNU Guix]

Hi!

Le mardi 14 mars 2023 à 09:34 +0100, Ludovic Courtès a écrit :
> The Gnulib package, which is meant to be source, retains references
> to
> several packages:
> 
> --8<---cut here---start->8---
> $ guix describe
> Generation 250  Mar 12 2023 23:58:03(current)
>   guix 1ed227d
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 1ed227d7952af48efe50a2f6c9537e17c356daa1
> $ guix gc --references $(guix build gnulib)
> /gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8
> /gnu/store/76p04alhjimlv4cgijl670byf2m50qh8-clisp-2.49-92
> /gnu/store/bvnzi0z7i9qk31a03y64rs8sxrckkinr-python-3.9.9
> /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0
> --8<---cut here---end--->8---
> 
> We should probably fix that and add #:allowed-references '().

These were shebangs in the build auxiliary scripts. It’s a tough problem,
because if I undo all the patch shebangs after installation, then gnulib is
not usable in the gnu-build-system bootstrap phase without a few more
tweaks. That’s not really a problem, because we can fix all our gnulib users
(guile-gnutls), but we should expect issues if gnulib bootstrap scripts call
themselves without an explicit interpreter.

In any case, #:allowed-reference is a gnu-build-system thing, so we can’t use 
that for gnulib.

Vivien

Vivien Kraus (2):
  gnu: gnulib: Reset the shebangs.
  gnu: guile-gnutls: Do not expect gnulib shebangs to work.

 gnu/packages/build-tools.scm | 28 
 gnu/packages/tls.scm |  6 ++
 2 files changed, 30 insertions(+), 4 deletions(-)


base-commit: 302680dbce784a53bfddb4ce5e6a9505cd0c477a
-- 
2.39.2

bug#62177: [PATCH] [WIP] update node to version 16

[Jelle Licht]

Hi Dr. Arne,

"Dr. Arne Babenhauserheide"  writes:

> Hi,
>
>
> this is an initial stab at getting node to version 16.
[snip]

Issue 59188 (https://issues.guix.gnu.org/59188) already updates node to
the 18.X LTS series. Would that version also work for you, or do you
have a specific need for the 16.X series? I ask because the "active" LTS
version is 18, while the 16 "maintenance" LTS window already closes on
2023-09-11, which is (IMHO) pretty soon.

- Jelle

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Jonas Møller via Bug reports for GNU Guix]

I think it's fine for Guix to use a specific version of Rust internally, and to 
be conservative about updating that.

But Guix becomes unsuitable for anyone developing software in Rust, if this 
technical detail in the package manager means that they can't use newer 
versions of the toolchain.

I think it would be best if Guix separated these concerns, by disconnecting the 
"Rust we use to build packages internally" with the "Rust that gets installed 
with `guix install rust`"

— Mvh Jonas Møller

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Simon Tournier]

Hi Jonas,

On Mon, 13 Mar 2023 at 20:59, Jonas Møller via Bug reports for GNU Guix 
 wrote:
>> Well, the issue when exporting ’rust-1.65’ is that it would possible
>> incompatible with the Rust packages provided by Guix and compiled with
>> ’rust’ (1.60).
>
> Rust has very strong stability guarantees between 1.x releases, and
> has a very extensive set of tooling/infrastructure to make sure no
> breaking changes make their way into a release (see crater [1]). Any
> Rust-based package big enough to be packaged by Guix will have had its
> test-suite confirmed to work with the new release of cargo/rustc long
> before any new release is made (and in many cases before pull-requests
> are merged.)

To test your claim, I would suggest to write a manifest using package
transformations [1] and then rebuild all Rust packages from Guix.

1: https://guix.gnu.org/manual/devel/en/guix.html#Package-Transformation-Options
2: https://guix.gnu.org/manual/devel/en/guix.html#Defining-Package-Variants

> Nevertheless, rebuilding all Rust packages on every rustc release
> isn't strictly necessary. (Improvements in optimizations do happen,
> but they are mosty minor release-to-release.)

I do not understand how this could be implemented with Guix.  Could you
be more specific?


Well, all in all, I do not think this report is a bug but a wish list.
Instead, I would suggest to discuss the actionable tasks for updating
Rust [3] in the mailing list guix-devel, WDYT?

3: https://guix.gnu.org/manual/devel/en/guix.html#Defining-Package-Variants

Cheers,
simon

bug#62181: Gnulib package keeps references to clisp, Python, Perl, and Bash

[Ludovic Courtès]

Hello,

The Gnulib package, which is meant to be source, retains references to
several packages:

--8<---cut here---start->8---
$ guix describe
Generation 250  Mar 12 2023 23:58:03(current)
  guix 1ed227d
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 1ed227d7952af48efe50a2f6c9537e17c356daa1
$ guix gc --references $(guix build gnulib)
/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8
/gnu/store/76p04alhjimlv4cgijl670byf2m50qh8-clisp-2.49-92
/gnu/store/bvnzi0z7i9qk31a03y64rs8sxrckkinr-python-3.9.9
/gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0
--8<---cut here---end--->8---

We should probably fix that and add #:allowed-references '().

WDYT, Vivien?

Thanks,
Ludo’.