bug#49515: [core-updates] mescc-tools tests fail

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello,

> Ludovic Courtès  skribis:
>
>> On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’,
>> mescc-tools fails tests, with generated binaries segfaulting:
>>
>> $ ./pre-inst-env guix build mescc-tools
>>
>> […]
>>
>> + . ./sha256.sh
>> ++ set -ex
>> ++ ./bin/get_machine
>> + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian 
>> --architecture knight-native -o test/test3/hold
>> + '[' amd64 = amd64 ']'
>> + ./test/results/test1-binary
>> + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian 
>> --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary 
>> --exec_enable
>> test/test1/hello.sh: line 37:   125 Segmentation fault  
>> ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1
>
> [...]

How weird!  I wonder what changed...

>> builder for 
>> `/gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv' failed 
>> with exit code 1
>
> I found that this upstream commit, which made it in version 1.1.0, fixes
> the segfault:
>
>   commit e633669dfdf16f503a7d740b9058e343536533b4
>   Author: nimaje 
>   Date:   Thu Oct 15 19:12:18 2020 -0400
>
>   Fix ELF headers to be more well behaved

[..]

> Should we upgrade instead?  If we do, what’s the potential for breakage?
> Should ‘mes-rb5’ be kept on an older version?

We could try that, I really can't tell if upgrading to 1.1.0 creates
a different mes binary.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#49515: [core-updates] mescc-tools tests fail

[Ludovic Courtès]

Ludovic Courtès  skribis:

> I tried backporting it (patch below) but that leads to:

And here’s the patch.

commit e633669dfdf16f503a7d740b9058e343536533b4
Author: nimaje 
Date:   Thu Oct 15 19:12:18 2020 -0400

Fix ELF headers to be more well behaved

diff --git a/elf_headers/elf32-debug.hex2 b/elf_headers/elf32-debug.hex2
index 667b032..9fe0183 100644
--- a/elf_headers/elf32-debug.hex2
+++ b/elf_headers/elf32-debug.hex2
@@ -33,7 +33,7 @@
 01 # e_ident[EI_DATA] Indicating little endianness
 01 # e_ident[EI_VERSION] Indicating original elf
 
-00 # e_ident[EI_OSABI] Set at 0 because none cares
+03 # e_ident[EI_OSABI] Set at 3 because FreeBSD is strict
 00 # e_ident[EI_ABIVERSION] See above
 
 00 00 00 00 00 00 00   # e_ident[EI_PAD]
diff --git a/elf_headers/elf32.hex2 b/elf_headers/elf32.hex2
index 45d365c..6432523 100644
--- a/elf_headers/elf32.hex2
+++ b/elf_headers/elf32.hex2
@@ -34,7 +34,7 @@
 01 # e_ident[EI_DATA] Indicating little endianness
 01 # e_ident[EI_VERSION] Indicating original elf
 
-00 # e_ident[EI_OSABI] Set at 0 because none cares
+03 # e_ident[EI_OSABI] Set at 3 because FreeBSD is strict
 00 # e_ident[EI_ABIVERSION] See above
 
 00 00 00 00 00 00 00   # e_ident[EI_PAD]
diff --git a/elf_headers/elf64.hex2 b/elf_headers/elf64.hex2
index 23d2a4a..6c10442 100644
--- a/elf_headers/elf64.hex2
+++ b/elf_headers/elf64.hex2
@@ -27,7 +27,7 @@
 01 ## e_ident[EI_DATA] Indicating little endianness
 01 ## e_ident[EI_VERSION] Indicating original elf
 
-00 ## e_ident[EI_OSABI] Set at 0 because none cares
+03 ## e_ident[EI_OSABI] Set at 3 because FreeBSD is strict
 00 ## e_ident[EI_ABIVERSION] See above
 
 00 00 00 00 00 00 00 ## e_ident[EI_PAD]
@@ -53,7 +53,7 @@
 ## Program Header
 :ELF_program_headers
 01 00 00 00 ## p_type
-06 00 00 00 ## Flags
+07 00 00 00 ## ph_flags: PF-X|PF-W|PF-R = 7
 00 00 00 00 00 00 00 00 ## p_offset
 
 _base 00 00 00 00 ## p_vaddr
diff --git a/test/test.answers b/test/test.answers
index d449db4..9b366f7 100644
--- a/test/test.answers
+++ b/test/test.answers
@@ -1,12 +1,12 @@
-b5a1dbfb4b9e42f839cd41f704b2d20d67705be5f5214d194d08026006e823a2  test/results/test0-binary
-34cd00306059776d0a1c54dff9d1a4ecb9915fa5b92746b6999c67e535f56b7c  test/results/test1-binary
-2505fa977f1eb9b8eb9cc338af6f606fb8341f1e2f341f71b249c50e7af5e0a7  test/results/test10-binary
-e27aa179b47bd21b8a43f460ef11622dcd13767cb515000ae583dc2706b89657  test/results/test11-binary
-1757e43a482f632286933a56d5da1e87d6385366adfa830df363ba6060a12784  test/results/test2-binary
+054359eb2b4e4f75aa212a41f90654b18b1efdde7ba08aac12bd9c21b1a12cf6  test/results/test0-binary
+56c3021ae5d31e1f57552f103e309603636de5ff38948f1be3e810d9ea0e670b  test/results/test1-binary
+2027e0c8d6295f041d338a430c5a3d3aae042294e5ba4ad1eb08bed16b147671  test/results/test10-binary
+ce9e76b600fdf67589e9180571bed092e9e091a3bf70dc852facd1b678d9df7b  test/results/test11-binary
+7247e7537ef3a83d4c557941bf59a591d6db0688c7a12362af7d14adac238ad4  test/results/test2-binary
 2b80849180d5fb3757bcca2471b6337808e5b5ca80b18d93fa82ddef0435b84b  test/results/test3-binary
-7db345c74d6ee13f21857f9f9419db2bb0890782923485b05dd9eb29b6436efa  test/results/test4-binary
-a7b5c22218bdad3cb8f74a7951fa1425fee5adafdf206420fd020d92b4a13b5e  test/results/test5-binary
-7123c8033949312d9325bffe02246bf599463f214eb0b281e7187c7b06818bae  test/results/test6-binary
-5992d312f114019d955195d50af25f68c3ab079b1e115ddf31f1aca2431d5dca  test/results/test7-binary
+310bea3129335b2cbda70fd591b2cf079b6f7fc19b22f12061a5379ba96dbdae  test/results/test4-binary
+1b09d2b8a3848d691d5d5927f80b6acaad57174b7653d88fe07cd1f6f4bd6f3d  test/results/test5-binary
+61d70db94077ee71b5522f44344baf3943c02559fb1c3e311cfe2fb6cb652d55  test/results/test6-binary
+5cba7bcb9de863c721613b5fafa17277e9e83336e32c8e7e59ee76d003ed5f29  test/results/test7-binary
 a71dc25bcba2a7298b9b9024a7927e215c5081a9ff90a6afa9b583be6c0a7e06  test/results/test8-binary
-b3ec35dc3ce5335ad384b8b2b8b7930aa414014e2bafa61bb6a2b7be8674b88f  test/results/test9-binary
+7fb2aa7451ea132a98f3900b140c8eb3d50751aa6adeac23fd2d766fce2635d4  test/results/test9-binary
diff --git a/test/test1/hex0.hex0 b/test/test1/hex0.hex0
index 7060a6d..611a86f 100644
--- a/test/test1/hex0.hex0
+++ b/test/test1/hex0.hex0
@@ -52,7 +52,7 @@ FB 00 60 00 00 00 00 00 ## e_entry Address of the entry point
 
 ## Program Header table
 01 00 00 00 ## p_type
-06 00 00 00 ## Flags
+07 00 00 00 ## ph_flags: PF-X|PF-W|PF-R = 7
 00 00 00 00 00 00 00 00 ## p_offset
 00 00 60 00 00 00 00 00 ## p_vaddr
 00 00 00 00 00 00 00 00 ## Undefined
diff 

bug#49515: [core-updates] mescc-tools tests fail

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’,
> mescc-tools fails tests, with generated binaries segfaulting:
>
> $ ./pre-inst-env guix build mescc-tools
>
> […]
>
> + . ./sha256.sh
> ++ set -ex
> ++ ./bin/get_machine
> + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian --architecture 
> knight-native -o test/test3/hold
> + '[' amd64 = amd64 ']'
> + ./test/results/test1-binary
> + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian 
> --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary 
> --exec_enable
> test/test1/hello.sh: line 37:   125 Segmentation fault  
> ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1

[...]

> builder for 
> `/gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv' failed 
> with exit code 1

I found that this upstream commit, which made it in version 1.1.0, fixes
the segfault:

  commit e633669dfdf16f503a7d740b9058e343536533b4
  Author: nimaje 
  Date:   Thu Oct 15 19:12:18 2020 -0400

  Fix ELF headers to be more well behaved

I tried backporting it (patch below) but that leads to:

--8<---cut here---start->8---
test/test2/hello.sh
+ ./bin/M1 -f test/test2/hex.M1 --LittleEndian --Architecture 1 -o 
test/test2/hold
+ ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian 
--Architecture 1 --BaseAddress 0x8048000 -o test/results/test2-binary 
--exec_enable
++ ./bin/get_machine
+ '[' x86_64 = x86_64 ']'
+ ./test/results/test2-binary
+ r=0
+ '[' 0 = 0 ']'
++ sha256sum -c test/test2/proof.answer
sha256sum: WARNING: 1 computed checksum did NOT match
+ out='test/test2/proof: FAILED'
+ '[' 'test/test2/proof: FAILED' = 'test/test2/proof: OK' ']'
+ exit 2
make: *** [makefile:94: test2-binary] Error 2

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("test" "-j" "1" 
"PREFIX=/gnu/store/mklrxb6k2a7f1nspm5az1w3pjgfqyx07-mescc-tools-0.5.2-0.bb062b0")
 exit-status: 2 term-signal: #f stop-signal: #f> 
phase `check' failed after 0.0 seconds
command "make" "test" "-j" "1" 
"PREFIX=/gnu/store/mklrxb6k2a7f1nspm5az1w3pjgfqyx07-mescc-tools-0.5.2-0.bb062b0"
 failed with status 2
builder for 
`/gnu/store/5pkxsjjhlirznxfblsm8g4x0dq8nlz6g-mescc-tools-0.5.2-0.bb062b0.drv' 
failed with exit code 1
build of 
/gnu/store/5pkxsjjhlirznxfblsm8g4x0dq8nlz6g-mescc-tools-0.5.2-0.bb062b0.drv 
failed
--8<---cut here---end--->8---

Should we upgrade instead?  If we do, what’s the potential for breakage?
Should ‘mes-rb5’ be kept on an older version?

WDYT, Janneke?  :-)

Thanks,
Ludo’.

bug#49516: [core-updates] glibc-2.31 patches fail to apply

[Ludovic Courtès]

Hi!

Chris Marusich  skribis:

> As an aside, when do we remove old versions of glibc?

Good question.  I’d say it’s enough to keep 3 versions in total.
Currently the main (only?) use case for these is when computing locale
data via the ‘locale-libcs’ field of operating system definitions.

Thoughts?

> From ef169adea6f9ca971e22845b839511b015cbc76c Mon Sep 17 00:00:00 2001
> From: Chris Marusich 
> Date: Sat, 10 Jul 2021 16:49:49 -0700
> Subject: [PATCH] gnu: glibc-2.31: Restore patches.
>
> Commit 87961fc965b96ac0c7a5909ac2faab2d023b5339 inadvertently modified the
> patch set for glibc-2.31.  This change restores the original patch set.
>
> Fixes: .
>
> * gnu/packages/base.scm (glibc-2.31) [source]: Use the same patches as glibc,
> but replace glibc-hurd-clock_gettime_monotonic.patch with
> glibc-2.31-hurd-clock_gettime_monotonic.patch, and add
> glibc-hurd-signal-sa-siginfo.patch.
> * gnu/packages/patches/glibc-2.31-hurd-clock_gettime_monotonic.patch: Add it.
> * gnu/packages/patches/glibc-hurd-signal-sa-siginfo.patch: Add it.
> * gnu/local.mk (dist_patch_DATA): Adjust accordingly.

LGTM, thanks!

Ludo’.

bug#49611: Despite wireless-regdb being installed in my operating-system, dmesg indicates it can't find `regulatory.db`

[Guillaume Le Vaillant]

Brice Waegeneire  skribis:

> Hello Katherine,
>
> TL;DR: “iw reg set US” correctly set the regulatory region from userland
> but Guix can't set it just from the kernel.
>
> Katherine Cox-Buday  writes:
>
>> #+BEGIN_EXAMPLE
>> [8.280462] cfg80211: Loading compiled-in X.509 certificates for
>> regulatory database
>> [8.282686] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
>> [8.284394] platform regulatory.0: Direct firmware load for
>> regulatory.db failed with error -2
>> [8.284415] cfg80211: failed to load regulatory.db
>> #+END_EXAMPLE
>
> There is three way to make the module cfg80211 load a regulatory
> database:
> 1. Baking the DB into the kernel at build time by replacing the kernel's
>   limited DB with the one from 'wireless-regdb' via the option
>   CONFIG_CFG80211_INTERNAL_REGDB¹.
> 2. Loading the DB at boot time as a signed firmware file
>   (lib/firmware/regulatory.db from 'wirerless-regdb') via the module
>   'cfg80211'.
> 3. Doing it in userland with the helper 'crda' trough the utility
>   'iwd' or its predecesor 'wpa_supplicant'.²
>
> From what I understand and what I tested, only the third method works in
> Guix System ATM.  It could be usefull to also support the first or
> second method to not depend on the userland setting the wireless
> regulatory settings.

Hi,

You could also try adding "cfg80211.ieee80211_regdom=US" to the
'kernel-arguments' field of your 'operating-system' definition.


signature.asc
Description: PGP signature

bug#49611: Despite wireless-regdb being installed in my operating-system, dmesg indicates it can't find `regulatory.db`

[Brice Waegeneire]

Hello Katherine,

TL;DR: “iw reg set US” correctly set the regulatory region from userland
but Guix can't set it just from the kernel.

Katherine Cox-Buday  writes:

> #+BEGIN_EXAMPLE
> [8.280462] cfg80211: Loading compiled-in X.509 certificates for
> regulatory database
> [8.282686] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> [8.284394] platform regulatory.0: Direct firmware load for
> regulatory.db failed with error -2
> [8.284415] cfg80211: failed to load regulatory.db
> #+END_EXAMPLE

There is three way to make the module cfg80211 load a regulatory
database:
1. Baking the DB into the kernel at build time by replacing the kernel's
  limited DB with the one from 'wireless-regdb' via the option
  CONFIG_CFG80211_INTERNAL_REGDB¹.
2. Loading the DB at boot time as a signed firmware file
  (lib/firmware/regulatory.db from 'wirerless-regdb') via the module
  'cfg80211'.
3. Doing it in userland with the helper 'crda' trough the utility
  'iwd' or its predecesor 'wpa_supplicant'.²

>From what I understand and what I tested, only the third method works in
Guix System ATM.  It could be usefull to also support the first or
second method to not depend on the userland setting the wireless
regulatory settings.

The error you are experiencing come from the second method failing to
load the signed firmware file. The issue is that Guix's 'wireless-regdb'
is build from source and not just copied as other distribution do, where
the provided binary also has a signature which the kernel accept through
a built in public key. Our build version isn't signed at all, the
commentaries in the definition for the package say Guix don't want to
maintain its own key for signing this package, which is understable and
state that Guix architecture already provide a similar level of
authenticity (I'm not so sure of that part).

So this error message should be harmless expected in some less common
context, such as having the rootfs on an NFS and using a wireless
connection to connect to the NFS server.  We could fix that without
maintaining keys by baking the DB into the kernel (first method).

> #+BEGIN_EXAMPLE
> $ find -L /run/current-system -name regulatory.db
> /run/current-system/profile/lib/firmware/regulatory.db
> #+END_EXAMPLE

We don't need the regulatory.db from 'wirelress-regdb' to be in the
system profile, instead it should be added to the operating-system's
firmware field. And the kernel will find it the directory contained in
“/sys/module/firmware_class/parameters/path”.

¹ https://cateee.net/lkddb/web-lkddb/CFG80211_INTERNAL_REGDB.html
² 
https://wireless.wiki.kernel.org/en/developers/regulatory/crda#changing_regulatory_domains

Cheers,
- Brice