bug#55499: excessively large manifests due to propagation

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hi!
>
> Ricardo Wurmus  skribis:
>
>> A profile consisting only of four R packages (r-seurat, r-cistopic,
>> r-monocle3, and r-cicero-monocle3) results in a “manifest” file that
>> weighs 7.1MB.  At the MDC I repeatedly encountered manifest files that
>> are exceeding 24MB.
>
> Commit 93f601d97ca2d9b82c41afeb86879ee37eae39e6 provides a 12% size
> reduction on this example, and it’s backward-compatible and cheap.

Excellent!  This is a great first step.

> I’ll try and follow up with changes along the lines you describe.

Thank you!

-- 
Ricardo

bug#54786: Installation tests are failing

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hi,
>
> Mathieu Othacehe  skribis:
>
>> Thanks for the fix! The jami and jami-provisioning tests are also broken
>> because of what looks like to be the same issue:
>>
>> One does not simply initialize the client: Another daemon is detected
>> /gnu/store/01phrvxnxrg1q0gxa35g7f77q06crf6v-shepherd-marionette.scm:1:1718: 
>> ERROR:
>>   1. :
>>   service: jami
>>   action: start
>>   key: match-error
>>   args: ("match" "no matching pattern" #f)
>> Jami Daemon 11.0.0, by Savoir-faire Linux 2004-2019
>> https://jami.net/
>> [Video support enabled]
>> [Plugins support enabled]
>
> Yes, I noticed that, but I’m not sure how to apply a similar workaround.

I tried fixing that today, but so far I've only managed to understand
what seems to be going wrong, with this (not so great) workflow:

1. Add pk uses in the code.

2. $(./pre-inst-env guix system vm --no-graphic -e '(@@ (gnu tests
telephony) %jami-os)' --no-offload --no-substitutes) -m 512 -nic
user,model=virtio-net-pci,hostfwd=tcp::10022-:22

3. ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p
10022 root@localhost

and poke around with 'herd status', read /var/log/messages, experiment
with dbus-send, etc.

This allowed me to find out that (dbus-available-services) appears to be
broken.  I'm not sure why the exceptions are reported so badly by
Shepherd (are exceptions raised with 'error' not handled by Shepherd or
something? -- the with-retries loop should end up printing the caught
exception arguments -- I would also have expected to see the backtrace
somewhere.

Anyway, connecting to another machine that is running the
jami-service-type still (hasn't been reconfigured in a while), I could
see:

--8<---cut here---start->8---
scheme@(guix-user)> ,use (gnu build jami-service)
scheme@(guix-user)> (dbus-available-services)
;;; Failed to autoload fork+exec-command in (shepherd service):
;;; no code for module (fibers)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
error: fork+exec-command: unbound variable
--8<---cut here---end--->8---

Oh yes, so it now requires guile-fibers.  After installing it:

--8<---cut here---start->8---
scheme@(guix-user)> ,use (gnu build jami-service)
scheme@(guix-user)> (dbus-available-services)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
No scheduler current; call within run-fibers instead
--8<---cut here---end--->8---

So the users of fork+exec-command (a public API) needs to be adjusted.
I suspect that's the crux of the issue here.  The rest (the jami tests
using Shepherd's start-service to check the service status and causing
multiple starts) should be easy to workaround.

To be continued...

Maxim

bug#55399: guix system reconfigure fails on channel validation

[André Batista]

Hi again,

seg 23 mai 2022 às 16:18:52 (165532), l...@gnu.org enviou:
> ...
> (For now commit b6bfe9ea6a1b19159455b34f1af4ac00ef9b94ab changes
> Guile-Git in Guix to depend on libgit2 1.3 as a workaround.)

After upgrading guile-git, the attached patches disables owner
validation and reverts the above commit which made Guix's guile-git
depend on libgit2 1.3 instead of latest.

Cheers!
From f9de10676c15a65d6df7e430efbb84cebb431ac9 Mon Sep 17 00:00:00 2001
In-Reply-To: <87a6b85o37.fsf...@gnu.org>
References: <87a6b85o37.fsf...@gnu.org>
From: =?UTF-8?q?Andr=C3=A9=20Batista?= 
To: 55...@debbugs.gnu.org
Date: Tue, 24 May 2022 19:38:17 -0300
Subject: [PATCH] guix: Disable owner validation when updating cached checkout

* guix/git.scm (update-cached-checkout): Disable owner validation
checks.
---
 guix/git.scm | 4 
 1 file changed, 4 insertions(+)

diff --git a/guix/git.scm b/guix/git.scm
index 53e7219c8c..d5e12188a2 100644
--- a/guix/git.scm
+++ b/guix/git.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2021 Kyle Meyer 
 ;;; Copyright © 2021 Marius Bakke 
 ;;; Copyright © 2022 Maxime Devos 
+;;; Copyright © 2022 André Batista 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -23,6 +24,7 @@
 (define-module (guix git)
   #:use-module (git)
   #:use-module (git object)
+  #:use-module (git settings)
   #:use-module (git submodule)
   #:use-module (guix i18n)
   #:use-module (guix base32)
@@ -463,6 +465,8 @@ (define canonical-ref
   (repository(if cache-exists?
  (repository-open cache-directory)
  (clone/swh-fallback url ref cache-directory
+ ;; Disable owner validation. See .
+ (set-owner-validation! #f)
  ;; Only fetch remote if it has not been cloned just before.
  (when (and cache-exists?
 (not (reference-available? repository ref)))
--
2.36.0
From f9de10676c15a65d6df7e430efbb84cebb431ac9 Mon Sep 17 00:00:00 2001
In-Reply-To: <87a6b85o37.fsf...@gnu.org>
References: <87a6b85o37.fsf...@gnu.org>
From: =?UTF-8?q?Andr=C3=A9=20Batista?= 
To: 55...@debbugs.gnu.org
Date: Tue, 24 May 2022 19:38:18 -0300
Subject: [PATCH] gnu: guile-git: Use latest libgit2

* gnu/packages/guile.scm (guile-git) [inputs]: Use latest libgit2.
Reverts commit b6bfe9ea6a1b19159455b34f1af4ac00ef9b94ab.
---
 gnu/packages/guile.scm | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index a9e04cb476..138fb4d6bc 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -833,9 +833,7 @@ (define-public guile-git
 (native-inputs
  (list pkg-config autoconf automake texinfo guile-3.0 
guile-bytestructures))
 (inputs
- ;; libgit2@1.4.3 ‘fixed’ a git CVE it never shared, breaking Guix.  Use
- ;; 1.3 for now; see  for alternatives.
- (list guile-3.0 libgit2-1.3))
+ (list guile-3.0 libgit2))
 (propagated-inputs
  (list guile-bytestructures))
 (synopsis "Guile bindings for libgit2")


signature.asc
Description: PGP signature

bug#55583: guix-daemon doesn't cleanly error-out on case-insensitive file systems.

[Brian Cully via Bug reports for GNU Guix]

Maxime Devos  writes:

Create a file /gnu/store/case-sensitivity-test (if it doesn't 
already
exist).  Open /gnu/store/CASE-SENSITIVITY-TEST.  If it succeeds, 
you

have a case-sensitive file system.


Hah. I was so wrapped up in thinking about kernel or POSIX APIs I 
missed the obvious thing. ;)


/If/ we go this route, though, I’d suggest a small change to 
handle so-called “mixed-case” file-systems, where you can have two 
files differentiated by case, but if there’s no ambiguity, then 
one may address a file using any case:


- echo lower-case > case-sensitivity-test
- echo UPPER-CASE > CASE-SENSITIVITY-TEST
- test x$(cat CASE-SENSITIVITY-TEST) = xUPPER-CASE

-bjc

bug#55618: Allow patching from mummi issues

[Nicolas Graves via Bug reports for GNU Guix]

Hi !

I was tring to fix a local build using an online patch on mummi, this
way :

(define-public my-emacs-list-utils
  (package
(inherit emacs-list-utils)
(name "my-emacs-list-utils")
(version "0.4.6")
(source
 (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/rolandwalker/list-utils;)
 (commit (string-append "v" version
   (file-name (git-file-name name version))
   (sha256
(base32 "07hbz2md52ccy95gv4d5n6szrfmpfqf3w4kwqdg2cf54c7kgf7hw"))
   (patches
(list
 (origin
(method url-fetch)
(uri "https://issues.guix.gnu.org/issue/55498/attachment/0;)
(sha256
 (base32
  "1ysjb23g21m0jhkn63hq56snjd6skd9pl58c365g519q03hq5s87")

As it is a quick and convenient way to apply someone's work while the
patch is not upstream, I expected it to work, but it failed with the
following error during download:

Starting download of /gnu/store/v91i1m61skr42136vnxhzm4gzyidp11y-0
>From https://issues.guix.gnu.org/issue/55498/attachment/0...
Bad media-type header component: text

I don't now if the fix should come from mummi's or guix's side, but I
found it a relevant way to quickly test an existing patch for one's
needs.

Thanks if you can enable this type of patches, or get alternatives if
there are. Also thanks for all the work on guix, it's amazing.

Nicolas Graves

bug#55609: ruby-stackprof sometimes fails to build (armv7h)

[Maxime Devos]

Looks like a rather flaky test, depending on GC behaviour
and timing.  So I think for now the test could simply be
disabled, at least for arm?

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#55441: [cuirass] hang in "In progress..."; runs out of pgsql connections

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

> Fixed in Guix commit a4994d739306abcf3f36706012fb88b35a970e6b with a
> test that reproduces the issue.
>
> Commit d02b7abe24fac84ef1fb1880f51d56fc9fb6cfef updates the ‘guix’
> package so we should be able to reconfigure berlin now and hopefully
> (crossing fingers!) be done with it.

An update: Cuirass is now up-to-date on berlin.guix, built from Guix
commit adf5ae5a412ed13302186dd4ce8e2df783d4515d.

Unfortunately, while evaluations now run to completion, child processes
of ‘cuirass evaluate’ stick around at the end:

--8<---cut here---start->8---
(gdb) bt
#0  futex_wait (private=0, expected=2, futex_word=0x7f5b1d054f08) at 
../sysdeps/nptl/futex-internal.h:146
#1  __lll_lock_wait (futex=futex@entry=0x7f5b1d054f08, private=0) at 
lowlevellock.c:52
#2  0x7f5b1d873ef3 in __GI___pthread_mutex_lock 
(mutex=mutex@entry=0x7f5b1d054f08) at ../nptl/pthread_mutex_lock.c:80
#3  0x7f5b1d995303 in scm_c_weak_set_remove_x (pred=, 
closure=0x7f5b13dd8d00, raw_hash=1824276156261873434, set=#) at weak-set.c:794
#4  scm_weak_set_remove_x (obj=# 
7f5b13dd8d00>, set=#) at weak-set.c:817
#5  close_port (explicit=, port=# 7f5b13dd8d00>) at ports.c:891
#6  close_port (port=# 7f5b13dd8d00>, 
explicit=) at ports.c:874
#7  0x7f5af3a7df82 in ?? ()
#8  0x00dbd860 in ?? ()
#9  0x7f5af3a7df60 in ?? ()
#10 0x00db82b8 in ?? ()
#11 0x7f5b1d972ccc in scm_jit_enter_mcode (thread=0x7f5b157bf240, 
mcode=0xdbd86c "\034\217\003") at jit.c:6038
#12 0x7f5b1d9c7f3c in vm_regular_engine (thread=0x7f5b157bf240) at 
vm-engine.c:360
#13 0x7f5b1d9d55e9 in scm_call_n (proc=, argv=, nargs=0) at vm.c:1608
#14 0x7f5b1d939a0e in scm_call_with_unblocked_asyncs (proc=#) at async.c:406
#15 0x7f5b1d9c8336 in vm_regular_engine (thread=0x7f5b157bf240) at 
vm-engine.c:972
#16 0x7f5b1d9d55e9 in scm_call_n (proc=, argv=, nargs=0) at vm.c:1608
#17 0x7f5b1d9c4be6 in really_launch (d=0x7f5aebccac80) at threads.c:778
#18 0x7f5b1d93b85a in c_body (d=0x7f5aea691d80) at continuations.c:430
#19 0x7f5aeeb118c2 in ?? ()
#20 0x7f5b1553d7e0 in ?? ()
#21 0x7f5b138a7370 in ?? ()
#22 0x0048 in ?? ()
#23 0x7f5b1d972ccc in scm_jit_enter_mcode (thread=0x7f5b157bf240, 
mcode=0xdbc874 "\034<\003") at jit.c:6038
#24 0x7f5b1d9c7f3c in vm_regular_engine (thread=0x7f5b157bf240) at 
vm-engine.c:360
#25 0x7f5b1d9d55e9 in scm_call_n (proc=, argv=, nargs=2) at vm.c:1608
#26 0x7f5b1d93d09a in scm_call_2 (proc=, arg1=, arg2=) at eval.c:503
#27 0x7f5b1d9f3752 in scm_c_with_exception_handler.constprop.0 (type=#t, 
handler_data=handler_data@entry=0x7f5aea691d10, 
thunk_data=thunk_data@entry=0x7f5aea691d10,
thunk=, handler=) at exceptions.c:170
#28 0x7f5b1d9c588f in scm_c_catch (tag=, body=, body_data=, handler=, 
handler_data=,
pre_unwind_handler=, pre_unwind_handler_data=0x7f5b156b2040) 
at throw.c:168
#29 0x7f5b1d93de66 in scm_i_with_continuation_barrier 
(pre_unwind_handler=0x7f5b1d93db80 , 
pre_unwind_handler_data=0x7f5b156b2040, handler_data=0x7f5aea691d80,
handler=0x7f5b1d9448b0 , body_data=0x7f5aea691d80, 
body=0x7f5b1d93b850 ) at continuations.c:368
#30 scm_c_with_continuation_barrier (func=, data=) at continuations.c:464
#31 0x7f5b1d9c4b39 in with_guile (base=0x7f5aea691e08, data=0x7f5aea691e30) 
at threads.c:645
#32 0x7f5b1d89b0ba in GC_call_with_stack_base () from 
/gnu/store/2lczkxbdbzh4gk7wh91bzrqrk7h5g1dl-libgc-8.0.4/lib/libgc.so.1
#33 0x7f5b1d9bd16d in scm_i_with_guile (dynamic_state=, 
data=0x7f5aebccac80, func=0x7f5b1d9c4b70 ) at threads.c:688
#34 launch_thread (d=0x7f5aebccac80) at threads.c:787
#35 0x7f5b1d871d7e in start_thread (arg=0x7f5aea692640) at 
pthread_create.c:473
#36 0x7f5b1d46feff in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) info threads
  Id   Target Id Frame
* 1process 53801 "guile" futex_wait (private=0, expected=2, 
futex_word=0x7f5b1d054f08) at ../sysdeps/nptl/futex-internal.h:146
--8<---cut here---end--->8---

Notice there’s a single thread: it very much looks like the random
results one gets when forking a multithreaded process (in this case,
this one thread is a finalization thread, except it’s running in a
process that doesn’t actually have the other Guile threads).  The
fork+threads problem is already manifesting, after all.

I’ll try and come up with a solution to that, if nobody beats me at it.
What’s annoying is that it’s not easy to test: the problem doesn’t
manifest on my 4-core laptop, but it does on the 96-core berlin.

To be continued…

Ludo’.

bug#39117: GNOME Files: No file thumbnails

[Roman Riabenko]

Hello

There was a patch in June 2020 that added bubblewrap as input to gnome-
dektop. It was reported that the patch was enabling thumbnails in
Nautilus. So, this issue should had been resolved.
https://issues.guix.gnu.org/41756

But thumbnails are still not generated for me with Nautilus (GNOME
Files) version 41.1, gnome-desktop 40.4.

Roman

bug#55504: Test suite of emacs-deferred does not progress

[Ludovic Courtès]

Liliana Marie Prikler  skribis:

> Am Mittwoch, dem 18.05.2022 um 13:19 -0300 schrieb Jorge P. de Morais
> Neto:
>> The log file [1] is empty.
>> 
>> 1: /var/log/guix/drvs/7r/bhrk48qvqhgix5c33yh9m3nq5crzny-emacs-
>> deferred-
>> 0.5.1.drv.gz
> emacs-deferred also times out on CI [2].
>
> [2] https://ci.guix.gnu.org/build/820992/log/raw

For posterity:

--8<---cut here---start->8---
ert-runner test/deferred-test.el -l deferred.elc

deferred error : (wrong-number-of-arguments (3 . 3) 4)
Test Finished : 2022/05/15 00:12:11
Tests Fails: 0 / 13
cc:test-dataflow-simple2 : OK
cc:test-semaphore1 : OK
cc:test-signal1 : OK
cc:test-dataflow-simple1 : OK
cc:test-dataflow-parent1 : OK
cc:test-signal2 : OK
cc:test-dataflow-simple3 : OK
cc:test-dataflow-simple4 : OK
cc:test-dataflow-parent2 : OK
cc:test-dataflow-signal : OK
cc:test-semaphore2 : OK
cc:test-fib-gen : OK
cc:test-thread : OK


deferred error : (wrong-number-of-arguments (3 . 3) 4)
.

Ran 1 test in 4.637 seconds
building of 
`/gnu/store/zx0r9035x47rnvlqcfgndixvgw07x8xg-emacs-deferred-0.5.1.drv' timed 
out after 3600 seconds of silence
@ build-failed 
/gnu/store/zx0r9035x47rnvlqcfgndixvgw07x8xg-emacs-deferred-0.5.1.drv - timeout
--8<---cut here---end--->8---

Anyone familiar with the Emacs 28 changelog?  :-)

Ludo’.

bug#55616: gcc-12-strmov-store-file-names.patch is missing?

[Ludovic Courtès]

Hi,

Tim Rakowski  skribis:

> $ guix uprade
> The following packages will be upgraded:
>...
>gcc-toolchain  11.2.0 → 12.1.0
>...
> guix upgrade: error: gcc-12-strmov-store-file-names.patch: patch not found
>
> As far as I can tell,
> https://github.com/guix-mirror/guix/commit/37e29ccd332f371aacedc71388e805fbc9e947fa
> added gcc-12, which depends on gcc-12-strmov-store-file-names.patch but
> failed to add the file to
> https://github.com/guix-mirror/guix/tree/master/gnu/packages/patches, where
> the older gcc*-strmov-store-file-names.patch are located.

My bad.  This is fixed by cdb6b19b5fc6fec94d7a27062ef87dca9e4bbcee.

Thanks for the heads-up!

Ludo’.

bug#55616: gcc-12-strmov-store-file-names.patch is missing?

[Tim Rakowski]

Hi,

I'm currently observing the following problem:

$ guix describe
Generation 8May 24 2022 20:15:17(current)
  guix 01793ed
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 01793ed03e8aa0960bff7adc21fd270e1527e68e
$ guix uprade
The following packages will be upgraded:
   ...
   gcc-toolchain  11.2.0 → 12.1.0
   ...
guix upgrade: error: gcc-12-strmov-store-file-names.patch: patch not found

As far as I can tell,
https://github.com/guix-mirror/guix/commit/37e29ccd332f371aacedc71388e805fbc9e947fa
added gcc-12, which depends on gcc-12-strmov-store-file-names.patch but
failed to add the file to
https://github.com/guix-mirror/guix/tree/master/gnu/packages/patches, where
the older gcc*-strmov-store-file-names.patch are located.

Regards,
Tim Rakowski

bug#55444: elogind startup race between shepherd and dbus-daemon

[Liliana Marie Prikler]

Hi,

Am Montag, dem 16.05.2022 um 10:26 +0200 schrieb Ludovic Courtès:
> [...]
> So it would seem that the solution to this is to prevent dbus-daemon
> from starting elogind.  We can do that by changing
> org.freedesktop.login1.service so that it has “Exec=true” instead of
> “Exec=elogind --daemon”.
> 
> “Exec=true” is a bit crude because it doesn’t guarantee that elogind
> is really started; if that isn’t good enough, we could instead wait
> for the PID file or something (as of Shepherd 0.9.0, invoking ‘herd
> start elogind’ potentially leads shepherd to start a second instance
> if the first one is still being started, so we can’t really do that).
Why does shepherd race with itself here?  That sounds like a very evil
bug.  Rather than waiting for a log file, I'd suggest writing an ad-hoc
Guile script that communicates with shepherd and blocks until shepherd
signals that elogind has been started, but this script too would have
to work around shepherd racing against itself.

> Depending on what we end up with, we might also revisit whether
> xorg-server needs to explicitly depend on elogind.
At least in the case of GDM I think it does heavily depend on elogind.
For the future, I think we also should take over dbus-daemon's
autostart in the same way systemd already has.

Cheers

bug#54783: [v2 0/2] Clarify zram priority

[Josselin Poiret via Bug reports for GNU Guix]

Hello Maxim,

Thanks for looking at this.  Here's a v2.

Maxim Cournoyer  writes:
> I'm curious, what does delaying the field buys us here?  Is it to avoid
> printing the warning multiple times when the record is evaluated?

Right, and this would get worse if someone ended up inheriting from
another configuration.  It would be bad UX IMO. 

> By convention, a warning message should not be a complete sentence (no
> capitalized first letter nor last period) and be short.  To provide a
> human friendly hint/message, you could use 'display-hint' (combined with
> a more succinct warning).

Right, fixed!

> The rest LGTM.
>
> Maxim

Josselin Poiret (2):
  system: Align zram priority with swap-space spec to clarify.
  doc: Remove double copyright.

 doc/guix.texi  | 11 +--
 gnu/services/linux.scm | 29 ++---
 2 files changed, 31 insertions(+), 9 deletions(-)

-- 
2.36.0

bug#54783: [PATCH v2 1/2] system: Align zram priority with swap-space spec to clarify.

[Josselin Poiret via Bug reports for GNU Guix]

* gnu/services/linux.scm
(zram-device-configuration) [priority]: Adapt to use #f or an integer
from 0 to 32767.  Add sanitizer to warn for the change and delay the
field.
(zram-device-configuration->udev-string): Adapt as above.
* doc/guix.texi (Zram Device Service): Change priority description to
refer to the Swap Space one, and suggest not leaving the default #f on
to properly use zram.
---
 doc/guix.texi  | 10 +-
 gnu/services/linux.scm | 29 ++---
 2 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 184206bec8..5f0120a3bd 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -96,7 +96,7 @@ Copyright @copyright{} 2021 Domagoj Stolfa@*
 Copyright @copyright{} 2021 Hui Lu@*
 Copyright @copyright{} 2021 pukkamustard@*
 Copyright @copyright{} 2021 Alice Brenon@*
-Copyright @copyright{} 2021 Josselin Poiret@*
+Copyright @copyright{} 2021, 2022 Josselin Poiret@*
 Copyright @copyright{} 2021 Andrew Tropin@*
 Copyright @copyright{} 2021 Sarah Morgensen@*
 Copyright @copyright{} 2021 Josselin Poiret@*
@@ -35213,11 +35213,11 @@ that compression will be 2:1, it is possible that 
uncompressable data
 can be written to swap and this is a method to limit how much memory can
 be used.  It accepts a string and can be a number of bytes or use a
 suffix, eg.: @code{"2G"}.
-@item @code{priority} (default @code{-1})
+@item @code{priority} (default @code{#f})
 This is the priority of the swap device created from the zram device.
-@code{swapon} accepts values between -1 and 32767, with higher values
-indicating higher priority.  Higher priority swap will generally be used
-first.
+@xref{Swap Space} for a description of swap priorities.  You might want
+to set a specific priority for the zram device, otherwise it could end
+up not being used much for the reasons described there.
 @end table
 
 @end deftp
diff --git a/gnu/services/linux.scm b/gnu/services/linux.scm
index 2eb02ac5a3..c6e460597a 100644
--- a/gnu/services/linux.scm
+++ b/gnu/services/linux.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2020 Efraim Flashner 
 ;;; Copyright © 2021 raid5atemyhomework 
 ;;; Copyright © 2021 B. Wilson 
+;;; Copyright © 2022 Josselin Poiret 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -21,9 +22,12 @@
 ;;; along with GNU Guix.  If not, see .
 
 (define-module (gnu services linux)
+  #:use-module (guix diagnostics)
   #:use-module (guix gexp)
   #:use-module (guix records)
   #:use-module (guix modules)
+  #:use-module (guix i18n)
+  #:use-module (guix ui)
   #:use-module (gnu services)
   #:use-module (gnu services base)
   #:use-module (gnu services shepherd)
@@ -252,7 +256,21 @@ (define-record-type* 
   (memory-limit zram-device-configuration-memory-limit
 (default 0)); string or integer
   (priority zram-device-configuration-priority
-(default -1)))  ; integer
+(default #f); integer | #f
+(delayed) ; to avoid printing the deprecation
+  ; warning multiple times
+(sanitize warn-zram-priority-change)))
+
+(define-with-syntax-properties
+  (warn-zram-priority-change (priority properties))
+  (if (eqv? priority -1)
+  (begin
+(warning (source-properties->location properties)
+ (G_ "using -1 for zram priority is deprecated~%"))
+(display-hint (G_ "Use #f or leave as default instead (@pxref{Linux \
+Services})."))
+#f)
+  priority))
 
 (define (zram-device-configuration->udev-string config)
   "Translate a  into a string which can be
@@ -278,8 +296,13 @@ (define (zram-device-configuration->udev-string config)
  "")
"RUN+=\"/run/current-system/profile/sbin/mkswap /dev/zram0\" "
"RUN+=\"/run/current-system/profile/sbin/swapon "
-   (if (not (equal? -1 priority))
- (string-append "--priority " (number->string priority) " ")
+   ;; XXX: The field is delayed while the deprecation warning remains in
+   ;; place, so we can't use match to fetch it (it would give a promise)
+   (if (zram-device-configuration-priority config)
+   (string-append "--priority "
+  (number->string
+   (zram-device-configuration-priority config))
+  " ")
  "")
"/dev/zram0\"\n"
 
-- 
2.36.0

bug#54783: [PATCH v2 2/2] doc: Remove double copyright.

[Josselin Poiret via Bug reports for GNU Guix]

* doc/guix.texi: Remove doubled Josselin Poiret copyright line.
---
 doc/guix.texi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 5f0120a3bd..b960c546a8 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -99,7 +99,6 @@ Copyright @copyright{} 2021 Alice Brenon@*
 Copyright @copyright{} 2021, 2022 Josselin Poiret@*
 Copyright @copyright{} 2021 Andrew Tropin@*
 Copyright @copyright{} 2021 Sarah Morgensen@*
-Copyright @copyright{} 2021 Josselin Poiret@*
 Copyright @copyright{} 2022 Remco van 't Veer@*
 Copyright @copyright{} 2022 Aleksandr Vityazev@*
 Copyright @copyright{} 2022 Philip M@sup{c}Grath@*
-- 
2.36.0

bug#54783: ZRAM default priority wrong

[Maxim Cournoyer]

Hi,

Josselin Poiret  writes:

> * gnu/services/linux.scm
> (zram-device-configuration) [priority]: Adapt to use #f or an integer
> from 0 to 32767.  Add sanitizer to warn for the change and delay the
> field.
> (zram-device-configuration->udev-string): Adapt as above.
> * doc/guix.texi (Zram Device Service): Change priority description to
> refer to the Swap Space one, and suggest not leaving the default #f on
> to properly use zram.
> ---
>  doc/guix.texi  | 10 +-
>  gnu/services/linux.scm | 26 +++---
>  2 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index b7005f0ef1..31f391357d 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -96,7 +96,7 @@ Copyright @copyright{} 2021 Domagoj Stolfa@*
>  Copyright @copyright{} 2021 Hui Lu@*
>  Copyright @copyright{} 2021 pukkamustard@*
>  Copyright @copyright{} 2021 Alice Brenon@*
> -Copyright @copyright{} 2021 Josselin Poiret@*
> +Copyright @copyright{} 2021, 2022 Josselin Poiret@*
>  Copyright @copyright{} 2021 Andrew Tropin@*
>  Copyright @copyright{} 2021 Sarah Morgensen@*
>  Copyright @copyright{} 2021 Josselin Poiret@*
> @@ -34650,11 +34650,11 @@ that compression will be 2:1, it is possible that 
> uncompressable data
>  can be written to swap and this is a method to limit how much memory can
>  be used.  It accepts a string and can be a number of bytes or use a
>  suffix, eg.: @code{"2G"}.
> -@item @code{priority} (default @code{-1})
> +@item @code{priority} (default @code{#f})
>  This is the priority of the swap device created from the zram device.
> -@code{swapon} accepts values between -1 and 32767, with higher values
> -indicating higher priority.  Higher priority swap will generally be used
> -first.
> +@xref{Swap Space} for a description of swap priorities.  You might want
> +to set a specific priority for the zram device, otherwise it could end
> +up not being used much for the reasons described there.
>  @end table
>  
>  @end deftp
> diff --git a/gnu/services/linux.scm b/gnu/services/linux.scm
> index 2eb02ac5a3..9f598b2826 100644
> --- a/gnu/services/linux.scm
> +++ b/gnu/services/linux.scm
> @@ -4,6 +4,7 @@
>  ;;; Copyright © 2020 Efraim Flashner 
>  ;;; Copyright © 2021 raid5atemyhomework 
>  ;;; Copyright © 2021 B. Wilson 
> +;;; Copyright © 2022 Josselin Poiret 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -21,9 +22,11 @@
>  ;;; along with GNU Guix.  If not, see .
>  
>  (define-module (gnu services linux)
> +  #:use-module (guix diagnostics)
>#:use-module (guix gexp)
>#:use-module (guix records)
>#:use-module (guix modules)
> +  #:use-module (guix i18n)
>#:use-module (gnu services)
>#:use-module (gnu services base)
>#:use-module (gnu services shepherd)
> @@ -252,7 +255,19 @@ (define-record-type* 
>(memory-limit zram-device-configuration-memory-limit
>  (default 0)); string or integer
>(priority zram-device-configuration-priority
> -(default -1)))  ; integer
> +(default #f); integer | #f
> +(delayed)

I'm curious, what does delaying the field buys us here?  Is it to avoid
printing the warning multiple times when the record is evaluated?

> +(sanitize warn-zram-priority-change)))
> +
> +(define-with-syntax-properties
> +  (warn-zram-priority-change (priority properties))
> +  (if (eqv? priority -1)
> +  (begin
> +(warning (source-properties->location properties)
> + (G_ "Using -1 for zram priority is deprecated to align with 
> \
> +the corresponding swap-space field, please use #f from now on.~%"))
> +#f)
> +  priority))

By convention, a warning message should not be a complete sentence (no
capitalized first letter nor last period) and be short.  To provide a
human friendly hint/message, you could use 'display-hint' (combined with
a more succinct warning).

The rest LGTM.

Maxim

bug#55499: excessively large manifests due to propagation

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> A profile consisting only of four R packages (r-seurat, r-cistopic,
> r-monocle3, and r-cicero-monocle3) results in a “manifest” file that
> weighs 7.1MB.  At the MDC I repeatedly encountered manifest files that
> are exceeding 24MB.

Commit 93f601d97ca2d9b82c41afeb86879ee37eae39e6 provides a 12% size
reduction on this example, and it’s backward-compatible and cheap.

I’ll try and follow up with changes along the lines you describe.

Ludo’.

bug#55609: ruby-stackprof fails fails to build (armv7h)

[Maxime Devos]

title 55609 ruby-stackprof fails fails to build (armhf-linux)
thanks

Actually, it fails reproducibly:


$ guix build  ruby-stackprof@0.2.17 --system=armhf-linux --check --no-grafts 
--check

  1) Failure:
StackProfTest#test_gc 
[/tmp/guix-build-ruby-stackprof-0.2.17.drv-0/gem/test/test_stackprof.rb:221]:
Expected 38 to be <= 25.


The exact ‘expected ???’ can differ though, on the next run I saw

  1) Failure:
StackProfTest#test_gc [/tmp/guix-build-ruby-stackprof-0.2.17.drv-
0/gem/test/test_stackprof.rb:221]:
Expected 47 to be <= 25.

Greetings,
Maxime.



signature.asc
Description: This is a digitally signed message part

bug#55609: ruby-stackprof sometimes fails to build (armv7h)

[Maxime Devos]

To reproduce:

$ guix build ruby-stackprof@0.2.17 --system=???
# if it was substituted
$ guix build ruby-stackprof@0.2.17 --system=??? --no-grafts --check

where I don't know what the value of ??? is (maybe armhf-linux?).
Maybe it fails on other architectures too, but I cannot reproduce
it on i686-linux.

Apparently this can cause "guix pull" to fail, see
.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#55609: ruby-stackprof sometimes fails to build (armv7h)

[Maxime Devos]

Reported upstream at 


signature.asc
Description: This is a digitally signed message part

bug#55609: ruby-stackprof fails fails to build (armv7h)

[Maxime Devos]

title 55609 ruby-stackprof fails fails to build (armhf-linux)

Actually, it fails reproducibly:


$ guix build  ruby-stackprof@0.2.17 --system=armhf-linux --check --no-grafts 
--check

  1) Failure:
StackProfTest#test_gc 
[/tmp/guix-build-ruby-stackprof-0.2.17.drv-0/gem/test/test_stackprof.rb:221]:
Expected 38 to be <= 25.


The exact ‘expected ???’ can differ though, on the next run I saw

  1) Failure:
StackProfTest#test_gc [/tmp/guix-build-ruby-stackprof-0.2.17.drv-
0/gem/test/test_stackprof.rb:221]:
Expected 47 to be <= 25.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#55609: ruby-stackprof fails fails to build (armv7h)

[Maxime Devos]

retitle 55609 "ruby-stackprof fails fails to build (armhf-linux)"
thanks

Actually, it fails reproducibly:


$ guix build  ruby-stackprof@0.2.17 --system=armhf-linux --check --no-grafts 
--check

  1) Failure:
StackProfTest#test_gc 
[/tmp/guix-build-ruby-stackprof-0.2.17.drv-0/gem/test/test_stackprof.rb:221]:
Expected 38 to be <= 25.


The exact ‘expected ???’ can differ though, on the next run I saw

  1) Failure:
StackProfTest#test_gc [/tmp/guix-build-ruby-stackprof-0.2.17.drv-
0/gem/test/test_stackprof.rb:221]:
Expected 47 to be <= 25.

Greetings,
Maxime.




signature.asc
Description: This is a digitally signed message part

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Maxime Devos]

Denis 'GNUtoo' Carikli schreef op ma 23-05-2022 om 21:08 [+0200]:
> And here's the log:
> > $ bzcat  /var/log/guix/drvs/m1/iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-
> stackprof-0.2.17.drv.bz2


I've created a separate bug report for this:
.


signature.asc
Description: This is a digitally signed message part

bug#54305: disk utility fail format fat

[Roman Riabenko]

Hello

The upstream implemented the check for vfat and closed the issue.
https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/commit/15462f9c87c08c5af77a31993c1d87cb34d04861

(It is not included in Disks version 42.0, so I haven't tested it yet.)

Roman

У нд, 2022-03-13 у 18:56 +0200, Roman Riabenko пише:
> Dear Liliana
> 
> I reported it upstream as suggested. Here is the link to track the
> upstream issue:
> https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues/242
> 
> I intend to report here if I get a conclusive response.
> 
> Thank you!
> Roman
> 
> 
> У чт, 2022-03-10 у 09:00 +0100, Liliana Marie Prikler пише:
> > Hi Roman,
> > 
> > Am Mittwoch, dem 09.03.2022 um 02:27 +0200 schrieb Roman Riabenko:
> > > 2. GNOME Disks utility ignored the dosfstools package which I
> > > installed
> > > in my user profile. For comparison, this applies to ntfs-3g too.
> > > In
> > > relation to ntfs-3g with UDisks this seems to be expected
> > > behavior,
> > > but
> > > it seemed to me as a bug at first:
> > > https://guix.gnu.org/en/manual/devel/en/html_node/Desktop-Services.html#index-udisks_002dservice
> > > 
> > > I do not know what is necessary to make GNOME Disk utility
> > > recognize
> > > the tools in the user profile and I am not sure it is necessary.
> > > It
> > > just seemed against the spirit of guix that the user is forced to
> > > reconfigure the system.
> > GNOME Disks inherits UDisks' limitations, as it uses it under the
> > hood.
> > With that in mind...
> > 
> > > 1. The FAT option was not grayed out in the formatting dialog.
> > > For
> > > comparison, the NTFS option was grayed out until I added ntfs-3g
> > > to
> > > the system profile too. May be GNOME Disks expects mkfs.vfat to
> > > be
> > > present, so it does not check whether it is present like it does
> > > for
> > > other file systems. 
> > > 
> > > So, it would be great for GNOME Disks to check whether mkfs.vfat
> > > is
> > > available before proceeding like it does for other filesystems.
> > You should probably report this one upstream.  A fix would be
> > relatively simple to write, see [1] for the relevant line making
> > the
> > Windows button insensitive.  The procedure
> > "gdu_utils_is_ntfs_available" spans only a few lines of code and
> > could
> > easily be adapted to check for vfat instead.
> > 
> > Cheers
> > 
> > [1]
> > https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/blob/40.2/src/disks/gducreatefilesystempage.c#L209
>