bug#53334: Acknowledgement (qbittorrent(<=4.4.0)'s search window fails with "Python is required to use the search engine but it does not seem to be installed")

[Jacob Hrbek]

Documentation about the issue and it's workaround added in the community
wiki:
* https://guix.miraheze.org/wiki/Packages/qbittorrent

--
Jacob Hrbek, In support of ukraine sovereignty #supportUkraine



publickey - kreyren@rixotstudio.cz - 1677db82.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#53998: Guix pull always gets stuck at ~80% on fresh i686 1.3.0 install

[Ahmad Draidi]

Hello again,

On 2/23/22 19:17, Ahmad Draidi wrote:

I tested again using the same method (clean install, same VM, etc) but
with strace running this time a couple of days ago and it failed, but
just now it passed.
I'll test a couple of times again and let you know.


I tested a few more times using the same method (clean install, etc) and 
the results were like this:


- Pull seg faulted, 2nd pull worked

- Pull seg faulted, 2nd pull got stuck

- Pull finished without issues

- Pull finished without issues

- Pull seg faulted, 2nd pull worked

- Pull finished without issues

- Pull seg faulted (log attached), 2nd pull worked, system reconfigure 
worked, reboot then pull again worked



It's a bit random now, but at least it passes sometimes.

Log file attached for the last attempt.


Let me know if there's anything I can help with.


Regards,

Ahmad



qwjvr81jkv558c3va7kgrjbz4m216f-guix-packages-base.drv.bz2
Description: application/bzip

bug#54111: guile bundles (a compiled version of) UnicodeData.txt and binaries

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> Looking at 
> ,
> I noticed that Guile bundles a binary variant of UnicodeData.txt in
> srfi-14.i.c.  Seems like it should be compiled with
> the 'unidate_to_charset.pl' script instead (assuming that there are no
> bootstrapping concerns).

It would add a dependency on Perl, which is not great (I’m not sure
whether it complicates bootstrapping since Perl is already present early
on, but it’s safer to avoid it.)

We could rewrite ‘unidata_to_charset.pl’ in Scheme, but then Guile would
still need to provide a pre-compiled version of srfi-14.i.c for
bootstrapping purposes.  Or we could rewrite it in Awk, since Guile
already depends on Awk anyway.

Thoughts?

Ludo’.

bug#54077: What does "sequel" mean in the CODE-OF-CONDUCT

[Ludovic Courtès]

Hello,

Maxime Devos  skribis:

> Vagrant Cascadian schreef op zo 20-02-2022 om 12:26 [-0800]:
>>   Note: In the sequel, "project" refers to GNU Guix, and "project
>>   maintainer(s)" refers to maintainer(s) of GNU Guix.
>> 
>> What does "the sequel" refer to?
>
> ‘The following’, I think?

Per WordNet (which is about American English):

--8<---cut here---start->8---
$ guix shell wordnet -- wn sequel -over

Overview of noun sequel

The noun sequel has 2 senses (no senses from tagged texts)
   
1. sequel, subsequence -- (something that follows something else)
2. sequel, continuation -- (a part added to a book or play that continues and 
extends it)
--8<---cut here---end--->8---

>> Maybe something more like "Note: In this document, ..." ?

If that sounds clearer, let’s do that!

Cc’ing maintainers to get their approval.

Ludo’.

bug#54181: [aarch64] gnutls-dane fails tests

[Ricardo Wurmus]

I tried to build this derivation

  /gnu/store/6r4y0ni5k1b658mlzr2j5pbzy1d37rq9-gnutls-dane-3.7.2.drv

on the honeycomb aarch64 nodes repeatedly, also with --cores=1.  Every
time this build fails with at least one test failure.

There seem to be different tests that fail each time.  Here are some:

--8<---cut here---start->8---
[…]
FAIL: tls13/prf-early
FAIL: srp
FAIL: dtls-repro-20170915
FAIL: tls13-early-data
FAIL: resume-with-record-size-limit
[…]

Testsuite summary for GnuTLS 3.7.2

# TOTAL: 463
# PASS:  419
# SKIP:  39
# XFAIL: 0
# FAIL:  5
# XPASS: 0
# ERROR: 0
--8<---cut here---end--->8---

-- 
Ricardo

bug#54181: [aarch64] gnutls-dane fails tests

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> I tried to build this derivation
>
>   /gnu/store/6r4y0ni5k1b658mlzr2j5pbzy1d37rq9-gnutls-dane-3.7.2.drv
>
> on the honeycomb aarch64 nodes repeatedly, also with --cores=1.  Every
> time this build fails with at least one test failure.

It built fine on the first try on overdrive1 (10.0.0.3).

-- 
Ricardo

bug#54077: What does "sequel" mean in the CODE-OF-CONDUCT

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

Maxime Devos  skribis:

‘The following’, I think?


It's an example of the pseudo-legalese people can slip into when writing 
An Official Document.


On 2022-02-27 14:48, Ludovic Courtès wrote:

Maybe something more like "Note: In this document, ..." ?


If that sounds clearer, let’s do that!


SGTM!

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#54111: guile bundles (a compiled version of) UnicodeData.txt and binaries

[Maxime Devos]

Ludovic Courtès schreef op zo 27-02-2022 om 14:52 [+0100]:
> It would add a dependency on Perl, which is not great (I’m not sure
> whether it complicates bootstrapping since Perl is already present early
> on, but it’s safer to avoid it.)
> 
> We could rewrite ‘unidata_to_charset.pl’ in Scheme, but then Guile would
> still need to provide a pre-compiled version of srfi-14.i.c for
> bootstrapping purposes.  Or we could rewrite it in Awk, since Guile
> already depends on Awk anyway.
> 
> Thoughts?

The ‘blob’ seems relatively harmless to the compilation process, so
when there are bootstrapping problems, I think we can leave it in.

However, all this Unicode is important for some other things (e.g. some
DNS and filesystem things).  So it would be nice to validate that no
attacker with access to the Guile repo stealthily introduced some wrong
information in during an otherwise routine update of the Unicode
information.

Hence, the following proposal:

  * Make perl an optional dependency of Guile (upstream) and add an
'--with-unicode-data=[...]' configure flag or something like that.

If perl is detected by './configure' and '--with-unicode-data=...'
is set, then let one of the makefiles run 'unidata_to_charset.pl'
and compare the 'new' srfi-14.i.c against the old srfi-14.i.c.

In case of a mismatch, bail out.

When there's no perl or --with-unicode-data, then just use the
bundled srfi-14.i.c.

  * Add 'perl' (or 'perl-boot0' because that perl is probably good
enough?) to the native-inputs of guile.

Actually, the second is already done in 'guile-final'.
Optionally, this can be combined with rewriting it in Scheme
or some other language.

Greetings,
Maxime.


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

bug#54111: guile bundles (a compiled version of) UnicodeData.txt and binaries

[Maxime Devos]

Maxime Devos schreef op zo 27-02-2022 om 20:45 [+0100]:
>   * Add 'perl' (or 'perl-boot0' because that perl is probably good
>     enough?) to the native-inputs of guile.
> 
> Actually, the second is already done in 'guile-final'.

Maybe this being done in 'guile-final' and 'guile-3.0-latest' is
sufficient?  Which package exactly verifies doesn't seem important,
as long as some package does it.

Greetings,
Maxime.


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

bug#40998: Guix System's initrd doesn't honor rootflags

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> This version field exposes the (already present) version information of a boot
> parameters file.
>
> * gnu/system.scm (%boot-parameters-version): New variable.
> ()[version]: New field.
> (read-boot-parameters): Use it.
> (operating-system-boot-parameters-file): Likewise.
> * tests/boot-parameters.scm (test-read-boot-parameters): Use
> %boot-parameters-version as the default version value in the template.

[...]

>  (define-record-type* 
>boot-parameters make-boot-parameters boot-parameters?
>(labelboot-parameters-label)
> @@ -322,7 +326,9 @@ (define-record-type* 
>(kernel   boot-parameters-kernel)
>(kernel-arguments boot-parameters-kernel-arguments)
>(initrd   boot-parameters-initrd)
> -  (multiboot-modules boot-parameters-multiboot-modules))
> +  (multiboot-modules boot-parameters-multiboot-modules)
> +  (version  boot-parameters-version  ;positive integer
> +(default %boot-parameters-version)))

[...]

>(match (read port)
> -(('boot-parameters ('version 0)
> +(('boot-parameters ('version (? version? version))
> ('label label) ('root-device root)
> ('kernel kernel)
> rest ...)
>   (boot-parameters
> +  (version version)
>(label label)
>(root-device (device-sexp->device root))

There’s no need to have a ‘version’ field in live 
records: have the ‘version’ field in the serialized format (the sexp)
and make sure the deserializer correctly converts to the internal
representation.

Here, I think you can bump the version number in the serialized form,
and have ‘read-boot-parameters’ automatically augment ‘kernel-arguments’
when VERSION is 0 with “--root=XYZ”.

(It might be that you can even do that without bumping the version
number.  Bumping is clearer but the downside is that an older Guix will
abort when attempting to read ‘parameters’.  This could happen if you
roll back to an earlier generation and try to run ‘guix system
reconfigure’ or similar from there.)

Also, you could write the ‘match’ pattern like this:

  ('boot-parameters ('version (and version (or 0 1)))
('label label) …)

I hope that makes sense!

Ludo’.

bug#40998: Guix System's initrd doesn't honor rootflags

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> -(define (bootable-kernel-arguments system root-device)
> -  "Return a list of kernel arguments (gexps) to boot SYSTEM from 
> ROOT-DEVICE."
> -  (list (string-append "--root="
> +(define* (bootable-kernel-arguments system root-device version)
> +  "Return a list of kernel arguments (gexps) to boot SYSTEM from ROOT-DEVICE.
> +VERSION is the target version of the boot-parameters record."
> +  ;; If the version is newer than 0, we use the new style initrd parameter
> +  ;; names, otherwise we use the legacy ones.  This is to maintain backward
> +  ;; compatibility when producing bootloader configurations for older
> +  ;; generations.
> +  (define version>0? (> version 0))
> +  (list (string-append (if version>0? "root=" "--root=")
> ;; Note: Always use the DCE format because that's what
> -   ;; (gnu build linux-boot) expects for the '--root'
> +   ;; (gnu build linux-boot) expects for the 'root'
> ;; kernel command-line option.
> (file-system-device->string root-device
> #:uuid-type 'dce))
> -#~(string-append "--system=" #$system)
> -#~(string-append "--load=" #$system "/boot")))
> +#~(string-append (if #$version>0? "gnu.system=" "--system=") 
> #$system)
> +#~(string-append (if #$version>0? "gnu.load=" "--load=")
> + #$system "/boot")))

This is the logic I was suggesting to move to ‘read-boot-parameters’.

To do that, ‘read-boot-parameters’ would have to fill the
‘kernel-arguments’ field of  such that it already
contains --system/gnu.system and --load/gnu.load.

And then ‘read-boot-parameters-file’ would become:

  (call-with-input-file (string-append system "/parameters")
read-boot-parameters)

without the post-processing step it’s currently doing.

(And the version number doesn’t need to flow beyond
‘read-boot-parameters’.)

WDYT?

Ludo’.

bug#40998: Guix System's initrd doesn't honor rootflags

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> * gnu/build/linux-boot.scm (boot-system): Honor rootfstype and rootflags
> arguments.  Update doc.  Error out in case there is insufficient information
> with regard to the root file system.
> Restore the behavior of inferring the root device from the root file system
> from the operating system in case the root argument is not provided.
> * doc/guix.texi (Initial RAM Disk): Document the new command-line parameters.

Very nice!

[...]

> -(if root-device
> -(mount-root-file-system (canonicalize-device-spec root-device)
> -(file-system-type root-fs)
> -#:volatile-root? volatile-root?
> -#:flags (mount-flags->bit-mask
> - (file-system-flags root-fs))
> -#:options (file-system-options root-fs)
> -#:check? (check? root-fs)
> -#:skip-check-if-clean?
> -(skip-check-if-clean? root-fs)
> -#:repair (repair root-fs))
> -(mount "none" "/root" "tmpfs"))
> +;; Mount the root file system.
> +(mount-root-file-system (canonicalize-device-spec

I think the ‘if’ had (has?) a justification but I’m not sure what that
was.  It’s likely nobody will notice if we remove it anyway.  :-)

Ludo’.

bug#40998: Guix System's initrd doesn't honor rootflags

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> * gnu/build/linux-boot.scm (boot-system): Print command-line parameters to
> standard output.
> ---
>  gnu/build/linux-boot.scm | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gnu/build/linux-boot.scm b/gnu/build/linux-boot.scm
> index 2f8b114806..30442ec8f8 100644
> --- a/gnu/build/linux-boot.scm
> +++ b/gnu/build/linux-boot.scm
> @@ -542,6 +542,8 @@ (define (device-string->file-system-device device-string)
>   (root-fs*(find root-mount-point? mounts))
>   (fsck.mode (find-long-option "fsck.mode" args)))
>  
> +(format #t "initrd command-line parameters: ~a~%" args)

I’d happily avoid being too talkative by default, but maybe we could
honor a ‘gnu.verbosity’ parameter to get different levels of early-boot
logging?  :-)

Anyway, it’s a nice patch series.

Thanks,
Ludo’.

bug#53998: Guix pull always gets stuck at ~80% on fresh i686 1.3.0 install

[Ludovic Courtès]

Hi Ahmad,

Ahmad Draidi  skribis:

> I tested a few more times using the same method (clean install, etc)
> and the results were like this:
>
> - Pull seg faulted, 2nd pull worked
>
> - Pull seg faulted, 2nd pull got stuck
>
> - Pull finished without issues
>
> - Pull finished without issues
>
> - Pull seg faulted, 2nd pull worked
>
> - Pull finished without issues
>
> - Pull seg faulted (log attached), 2nd pull worked, system reconfigure
>   worked, reboot then pull again worked
>
>
> It's a bit random now, but at least it passes sometimes.

That doesn’t sound great.

How much (v)RAM does this (virtual) machine have?

Thanks for testing and reporting back,
Ludo’.

bug#54111: guile bundles (a compiled version of) UnicodeData.txt and binaries

[Bengt Richter]

Hi guix,

On +2022-02-27 20:52:38 +0100, Maxime Devos wrote:
> Maxime Devos schreef op zo 27-02-2022 om 20:45 [+0100]:
> >   * Add 'perl' (or 'perl-boot0' because that perl is probably good
> >     enough?) to the native-inputs of guile.
> > 
> > Actually, the second is already done in 'guile-final'.
> 
> Maybe this being done in 'guile-final' and 'guile-3.0-latest' is
> sufficient?  Which package exactly verifies doesn't seem important,
> as long as some package does it.
> 
> Greetings,
> Maxime.

I'm wondering how many lines of perl code
actually would have to be translated to guile
to eliminate this perl dependency.

Does the perl code upstream get changed
too often to make keeping up an acceptable chore?

(I guess I'm assuming the code is like one screenful
with a hot loop accessing a bunch of static tables.
I haven't chased it :)

-- 
Regards,
Bengt Richter

bug#54077: What does "sequel" mean in the CODE-OF-CONDUCT

[Maxim Cournoyer]

Hello,

Tobias Geerinckx-Rice  writes:

> Maxime Devos  skribis:
>> ‘The following’, I think?
>
> It's an example of the pseudo-legalese people can slip into when
> writing An Official Document.
>
> On 2022-02-27 14:48, Ludovic Courtès wrote:
 Maybe something more like "Note: In this document, ..." ?
>> If that sounds clearer, let’s do that!
>
> SGTM!

+1.

Maxim

bug#40998: [PATCH v2 4/4] initrd: Print its command-line parameters.

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

On 19 February 2022 07:01:55 UTC, Maxim Cournoyer  
wrote:
>* gnu/build/linux-boot.scm (boot-system): Print command-line parameters to
>standard output.
>---
> gnu/build/linux-boot.scm | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/gnu/build/linux-boot.scm b/gnu/build/linux-boot.scm
>index 2f8b114806..30442ec8f8 100644
>--- a/gnu/build/linux-boot.scm
>+++ b/gnu/build/linux-boot.scm
>@@ -542,6 +542,8 @@ (define (device-string->file-system-device device-string)
>  (root-fs*(find root-mount-point? mounts))
>  (fsck.mode (find-long-option "fsck.mode" args)))
> 
>+(format #t "initrd command-line parameters: ~a~%" args)
>+
> (unless (or root-fs* (and root-device rootfstype))
>   (error "no root file system or 'root' and 'rootfstype' parameters"))
> 

I suggest dropping this patch.  The kernel already does this.  It's just noise.

I've installed the others here.  Thanks!
Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.