Re: [bug#67512] [PATCH v7 0/3] Add LibreWolf

[Clément Lassieur]

On Sat, Apr 27 2024, Ian Eure wrote:

>> The version in Guix is the latest available.  I’ll send in a patch
>> when the next release happens; I’m waiting on upstream for that.
>>
>
> Okay, I see that I’m incorrect about this -- LibreWolf is moving onto
> Codeberg, but I was looking at their GitLab project, which doesn’t have the
> recent releases.  I’ll get this updated.

Great, thank you Ian!

Re: bug#67512: [PATCH v7 0/3] Add LibreWolf

[Ian Eure]

Ian Eure  writes:


Clément Lassieur  writes:


On Fri, Apr 12 2024, Andrew Tropin via Guix-patches via wrote:


On 2024-04-06 08:04, Ian Eure wrote:

Moves nss update to nss-3.98 / nss-certs-3.98 to avoid 
rebuilding

thousands of packages.

Rebases.

Ian Eure (3):
  gnu: Add nss-3.98.
  gnu: Add nss-certs-3.98.
  gnu: Add librewolf.

 gnu/packages/certs.scm |  16 +
 gnu/packages/librewolf.scm | 621
+
 gnu/packages/nss.scm   |  45 +++
 3 files changed, 682 insertions(+)
 create mode 100644 gnu/packages/librewolf.scm


base-commit: ade6845da6cec99f3bca46faac9b2bad6877817e


Hi Ian,

tested those patches, didn't notice any issues.

Added pipewire to LD_LIBRARY_PATH to make screensharing on 
wayland

to
work.

Added librewolf.scm to gnu/local.mk.

Pushed as
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3dc26b4eae

Thank you very much for you work!


Thank you Andrew for reviewing.

Now that this is pushed, is there anyone maintaining this
"librewolf"
package?  This is serious work, with security updates quite 
often.




Hi Clement,

I’m planning to continue sending patches for updates and the
like. Getting a working updater is close to the top of my list.



Right now the package is subject to

CVE-2024-3852 (high)
CVE-2024-3853 (high)
CVE-2024-3854 (high)
CVE-2024-3855 (high)
CVE-2024-3856 (high)
CVE-2024-3857 (high)
CVE-2024-3858 (high)
CVE-2024-3859 (moderate)
CVE-2024-3860 (moderate)
CVE-2024-3861 (moderate)
CVE-2024-3862 (moderate)
CVE-2024-3302 (low)
CVE-2024-3864 (high)
CVE-2024-3865 (high)



The version in Guix is the latest available.  I’ll send in a 
patch

when the next release happens; I’m waiting on upstream for that.



Okay, I see that I’m incorrect about this -- LibreWolf is moving 
onto Codeberg, but I was looking at their GitLab project, which 
doesn’t have the recent releases.  I’ll get this updated.


Thanks,

 — Ian

Re: bug#67512: [PATCH v7 0/3] Add LibreWolf

[Ian Eure]

Clément Lassieur  writes:


On Fri, Apr 12 2024, Andrew Tropin via Guix-patches via wrote:


On 2024-04-06 08:04, Ian Eure wrote:

Moves nss update to nss-3.98 / nss-certs-3.98 to avoid 
rebuilding thousands of packages.


Rebases.

Ian Eure (3):
  gnu: Add nss-3.98.
  gnu: Add nss-certs-3.98.
  gnu: Add librewolf.

 gnu/packages/certs.scm |  16 +
 gnu/packages/librewolf.scm | 621 
 +

 gnu/packages/nss.scm   |  45 +++
 3 files changed, 682 insertions(+)
 create mode 100644 gnu/packages/librewolf.scm


base-commit: ade6845da6cec99f3bca46faac9b2bad6877817e


Hi Ian,

tested those patches, didn't notice any issues.

Added pipewire to LD_LIBRARY_PATH to make screensharing on 
wayland to

work.

Added librewolf.scm to gnu/local.mk.

Pushed as
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3dc26b4eae

Thank you very much for you work!


Thank you Andrew for reviewing.

Now that this is pushed, is there anyone maintaining this 
"librewolf"
package?  This is serious work, with security updates quite 
often.




Hi Clement,

I’m planning to continue sending patches for updates and the like. 
Getting a working updater is close to the top of my list.




Right now the package is subject to

CVE-2024-3852 (high)
CVE-2024-3853 (high)
CVE-2024-3854 (high)
CVE-2024-3855 (high)
CVE-2024-3856 (high)
CVE-2024-3857 (high)
CVE-2024-3858 (high)
CVE-2024-3859 (moderate)
CVE-2024-3860 (moderate)
CVE-2024-3861 (moderate)
CVE-2024-3862 (moderate)
CVE-2024-3302 (low)
CVE-2024-3864 (high)
CVE-2024-3865 (high)



The version in Guix is the latest available.  I’ll send in a patch 
when the next release happens; I’m waiting on upstream for that.


Thanks,

 — Ian

Re: bug#67512: [PATCH v7 0/3] Add LibreWolf

[Clément Lassieur]

On Fri, Apr 12 2024, Andrew Tropin via Guix-patches via wrote:

> On 2024-04-06 08:04, Ian Eure wrote:
>
>> Moves nss update to nss-3.98 / nss-certs-3.98 to avoid rebuilding thousands 
>> of packages.
>>
>> Rebases.
>>
>> Ian Eure (3):
>>   gnu: Add nss-3.98.
>>   gnu: Add nss-certs-3.98.
>>   gnu: Add librewolf.
>>
>>  gnu/packages/certs.scm |  16 +
>>  gnu/packages/librewolf.scm | 621 +
>>  gnu/packages/nss.scm   |  45 +++
>>  3 files changed, 682 insertions(+)
>>  create mode 100644 gnu/packages/librewolf.scm
>>
>>
>> base-commit: ade6845da6cec99f3bca46faac9b2bad6877817e
>
> Hi Ian,
>
> tested those patches, didn't notice any issues.
>
> Added pipewire to LD_LIBRARY_PATH to make screensharing on wayland to
> work.
>
> Added librewolf.scm to gnu/local.mk.
>
> Pushed as
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3dc26b4eae
>
> Thank you very much for you work!

Thank you Andrew for reviewing.

Now that this is pushed, is there anyone maintaining this "librewolf"
package?  This is serious work, with security updates quite often.

Right now the package is subject to

CVE-2024-3852 (high)
CVE-2024-3853 (high)
CVE-2024-3854 (high)
CVE-2024-3855 (high)
CVE-2024-3856 (high)
CVE-2024-3857 (high)
CVE-2024-3858 (high)
CVE-2024-3859 (moderate)
CVE-2024-3860 (moderate)
CVE-2024-3861 (moderate)
CVE-2024-3862 (moderate)
CVE-2024-3302 (low)
CVE-2024-3864 (high)
CVE-2024-3865 (high)

Thanks,
Clément

Re: Value in adding Shepherd requirements to file-systems entries?

[Attila Lendvai]

> P.S. The code above should read (requirements ...) in the plural.

inside shepherd there's a bit of anomaly, but it's called requirement in the 
public API, and also in the guix side of the config; i.e. it's not plural.


-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Moderation in temper is always a virtue; but moderation in principle is always 
a vice.”
— Thomas Paine (1737–1809)

[PATCH 6/6] WIP: nss: Attempting to resolve FIPS regression.

[Christina O'Donnell]

There are 51 new test failures which all appear to be related to FIPS.

For example:

modutil -dbdir 
/tmp/guix-build-nss-3.99.drv-0/nss-3.99/tests_results/security/localhost.1/fips 
-fips true

WARNING: Performing this operation while the browser is running could cause
corruption of your security databases. If the browser is currently running,
you should exit browser before continuing this operation. Type
'q ' to abort, or  to continue:
A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has 
occurred with the token or slot.
ERROR: Unable to switch FIPS modes.
cert.sh: #291: Enable FIPS mode on database for FIPS PUB 140 Test Certificate 
(11)  - FAILED
cert.sh ERROR: Enable FIPS mode on database for FIPS PUB 140 Test Certificate 
failed 11

Change-Id: If0d57bb9e129eb862fae1a28d9779c6100e0a23d
---
 gnu/packages/nss.scm | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm
index 80667d8affe..a8fb6965c2c 100644
--- a/gnu/packages/nss.scm
+++ b/gnu/packages/nss.scm
@@ -134,6 +134,10 @@ (define-public nss
   (delete-file-recursively "nss/lib/sqlite")
 (build-system gnu-build-system)
 (outputs '("out" "bin"))
+;; (search-paths
+;;  (list (search-path-specification
+;; (variable "LD_LIBRARY_PATH")
+;; (files '("lib")
 (arguments
  (list
   #:make-flags
@@ -161,12 +165,15 @@ (define-public nss
 #$@(if (%current-target-system)
#~("CROSS_COMPILE=1")
#~())
+(string-append "NSS_FORCE_FIPS=1")
+(string-append "NSPR_LIB_DIR="
+   (string-append #$nspr "/lib"))
 (string-append "NSPR_INCLUDE_DIR="
(search-input-directory %build-inputs
"include/nspr"))
 ;; Add $out/lib/nss to RPATH.
 (string-append "RPATH=" rpath)
-(string-append "LDFLAGS=" rpath)))
+(string-append "LDFLAGS=" rpath " -L" #$nspr "/lib")))
   #:modules '((guix build gnu-build-system)
   (guix build utils)
   (ice-9 ftw)
@@ -203,6 +210,8 @@ (define-public nss
 (setenv "DOMSUF" "localdomain")
 (setenv "USE_IP" "TRUE")
 (setenv "IP_ADDRESS" "127.0.0.1")
+;; (setenv "LD_LIBRARY_PATH"
+;; (string-append (getenv "LD_LIBRARY_PATH")))
 
 ;; The "PayPalEE.cert" certificate expires every six 
months,
 ;; leading to test failures:
-- 
2.41.0

[PATCH 1/6] gnu: nss: Fix cross-compilation.

[Christina O'Donnell]

From: Zheng Junjie 

* gnu/packages/nss.scm (nss)[arguments]<#:make-flags>: When
cross-compilation, Add CROSS_COMPILE=1.
<#:phases>: When cross-compilation, Set env NATIVE_CC to gcc.

Change-Id: I5c9559a4b8cecf2cfc6c47d136d69c01a335faaf
Signed-off-by: Zheng Junjie 
---
 gnu/packages/nss.scm | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm
index 7e9ed49ead8..459e53bc1cf 100644
--- a/gnu/packages/nss.scm
+++ b/gnu/packages/nss.scm
@@ -154,6 +154,9 @@ (define-public nss
 (#$(target-linux?) "linux")
 (else ""
#~())
+#$@(if (%current-target-system)
+   #~("CROSS_COMPILE=1")
+   #~())
 (string-append "NSPR_INCLUDE_DIR="
(search-input-directory %build-inputs
"include/nspr"))
@@ -175,6 +178,10 @@ (define-public nss
 (lambda _
   (setenv "CC" #$(cc-for-target))
   (setenv "CCC" #$(cxx-for-target))
+  ;; TODO: Set this unconditionally
+  #$@(if (%current-target-system)
+ #~((setenv "NATIVE_CC" "gcc"))
+ #~())
   ;; No VSX on powerpc-linux.
   #$@(if (target-ppc32?)
  #~((setenv "NSS_DISABLE_CRYPTO_VSX" "1"))
-- 
2.41.0

[PATCH 0/6] WIP: nss: Update to 3.99

[Christina O'Donnell]

Hi,

I've got as far as making nss 3.98 reproducible, however updating it to 3.99
results in 51 test failures. These are regressions, and worked correctly for
3.98. I'm not entirely sure what the issue is, but I've run out of time to
debug it this week, so I'm sending this patch up as is.

Up to patch 3 build correctly. Patch 4 is the first one that fails.

The issue specifically seems to all be related to FIPS:

A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has
occurred with the token or slot.

If someone could take a look at this and see if there's anything I've missded
then I'd appreciate that. Otherwise I'm free to pick it back up again on
Tuesday.

Let me know if you have any questions.

Kind regards,
Christina

Christina O'Donnell (4):
  gnu: nss: Make reproducible.
  gnu: nss: Update to 3.99.
  gnu: nss-certs: Update to 3.99.
  WIP: nss: Attempting to resolve FIPS regression.

Zheng Junjie (2):
  gnu: nss: Fix cross-compilation.
  gnu: nspr: Fix cross-compilation.

 gnu/packages/certs.scm| 24 +--
 gnu/packages/nss.scm  | 30 +++--
 .../patches/nss-Disable-library-signing.patch | 67 +++
 3 files changed, 111 insertions(+), 10 deletions(-)
 create mode 100644 gnu/packages/patches/nss-Disable-library-signing.patch


base-commit: 9a47ef6182b6a36354699efbdbedca17f24cd9b8
-- 
2.41.0

[PATCH 2/6] gnu: nspr: Fix cross-compilation.

[Christina O'Donnell]

From: Zheng Junjie 

* gnu/packages/nss.scm (nspr)[arguments]<#:configure-flags>: When
cross-compilation, Add HOST_CC=gcc.

Change-Id: I337f217f153f8cc3a713906643d6fab9115056e9
Signed-off-by: Zheng Junjie 
---
 gnu/packages/nss.scm | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm
index 459e53bc1cf..0baafe2f373 100644
--- a/gnu/packages/nss.scm
+++ b/gnu/packages/nss.scm
@@ -71,7 +71,10 @@ (define-public nspr
   #~(list "--disable-static"
   "--enable-64bit"
   (string-append "LDFLAGS=-Wl,-rpath="
- (assoc-ref %outputs "out") "/lib"))
+ (assoc-ref %outputs "out") "/lib")
+  #$@(if (%current-target-system)
+ #~("HOST_CC=gcc")
+ #~()))
   ;; Use fixed timestamps for reproducibility.
   #:make-flags #~'("SH_DATE='1970-01-01 00:00:01'"
;; This is epoch 1 in microseconds.
-- 
2.41.0

[PATCH 4/6] gnu: nss: Update to 3.99.

[Christina O'Donnell]

gnu/packages/nss.scm (nss): Update to 3.99.

Change-Id: Iba6c9dc2956cc0febb62a1c471add899250fa489
---
 gnu/packages/nss.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm
index b608a995577..80667d8affe 100644
--- a/gnu/packages/nss.scm
+++ b/gnu/packages/nss.scm
@@ -109,7 +109,7 @@ (define-public nss
 ;; IMPORTANT: Also update and test the nss-certs package, which duplicates
 ;; version and source to avoid a top-level variable reference & module
 ;; cycle.
-(version "3.88.1")
+(version "3.99")
 (source (origin
   (method url-fetch)
   (uri (let ((version-with-underscores
@@ -120,7 +120,7 @@ (define-public nss
   "nss-" version ".tar.gz")))
   (sha256
(base32
-"15il9fsmixa1r4446zq1wl627sg0hz9h67w6kjxz273xz3nl7li7"))
+"1g89ig40gfi1sp02gybvl2z818lawcnrqjzsws36cdva834c5maw"))
   ;; Create nss.pc and nss-config.
   (patches (search-patches "nss-3.56-pkgconfig.patch"
"nss-getcwd-nonnull.patch"
-- 
2.41.0

[PATCH 3/6] gnu: nss: Make reproducible.

[Christina O'Donnell]

gnu/packages/patches/nss-Disable-library-signing.patch: Disable library
signing to make the build reproducible.
gnu/packages/nss.scm (nss): Apply this new patch.

Change-Id: I7860bae219ecc4a79423a590c27a1097ae2e7874
---
 gnu/packages/nss.scm  |  3 +-
 .../patches/nss-Disable-library-signing.patch | 67 +++
 2 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/nss-Disable-library-signing.patch

diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm
index 0baafe2f373..b608a995577 100644
--- a/gnu/packages/nss.scm
+++ b/gnu/packages/nss.scm
@@ -124,7 +124,8 @@ (define-public nss
   ;; Create nss.pc and nss-config.
   (patches (search-patches "nss-3.56-pkgconfig.patch"
"nss-getcwd-nonnull.patch"
-   "nss-increase-test-timeout.patch"))
+   "nss-increase-test-timeout.patch"
+   "nss-Disable-library-signing.patch"))
   (modules '((guix build utils)))
   (snippet
'(begin
diff --git a/gnu/packages/patches/nss-Disable-library-signing.patch 
b/gnu/packages/patches/nss-Disable-library-signing.patch
new file mode 100644
index 000..b488d29dcad
--- /dev/null
+++ b/gnu/packages/patches/nss-Disable-library-signing.patch
@@ -0,0 +1,67 @@
+From 4734b834755822f962af29e9395daa7338084e21 Mon Sep 17 00:00:00 2001
+Message-ID: 
<4734b834755822f962af29e9395daa7338084e21.1714059680.git@mutix.org>
+From: Christina O'Donnell 
+Date: Thu, 25 Apr 2024 16:35:50 +0100
+Subject: [PATCH] nss: Disable library signing.
+
+---
+ nss/cmd/shlibsign/Makefile | 32 +---
+ 1 file changed, 1 insertion(+), 31 deletions(-)
+
+diff --git a/nss/cmd/shlibsign/Makefile b/nss/cmd/shlibsign/Makefile
+index a119205..7a85c1d 100644
+--- a/nss/cmd/shlibsign/Makefile
 b/nss/cmd/shlibsign/Makefile
+@@ -43,22 +43,9 @@ EXTRA_SHARED_LIBS += \
+ 
+ endif
+ 
+-
+-# sign any and all shared libraries that contain the word freebl
+-ifeq ($(NSS_BUILD_WITHOUT_SOFTOKEN),1)
++# Disable library signing as it's non-deterministic
+ CHECKLIBS =
+ CHECKLOC =
+-else
+-CHECKLIBS = $(DIST)/lib/$(DLL_PREFIX)softokn3.$(DLL_SUFFIX)
+-CHECKLIBS += $(wildcard $(DIST)/lib/$(DLL_PREFIX)freebl*3.$(DLL_SUFFIX))
+-ifndef NSS_DISABLE_DBM
+-CHECKLIBS += $(DIST)/lib/$(DLL_PREFIX)nssdbm3.$(DLL_SUFFIX)
+-endif
+-CHECKLOC = $(CHECKLIBS:.$(DLL_SUFFIX)=.chk)
+-
+-MD_LIB_RELEASE_FILES = $(CHECKLOC)
+-ALL_TRASH += $(CHECKLOC)
+-endif
+ 
+ ###
+ # (5) Execute "global" rules. (OPTIONAL)  #
+@@ -78,23 +65,6 @@ include $(CORE_DEPTH)/coreconf/rules.mk
+ 
+ include ../platrules.mk
+ 
+-SRCDIR = $(call core_abspath,.)
+-
+-%.chk: %.$(DLL_SUFFIX) 
+-ifeq ($(OS_TARGET), OS2)
+-  cd $(OBJDIR) ; cmd.exe /c $(SRCDIR)/sign.cmd $(DIST) \
+-  $(call core_abspath,$(OBJDIR)) $(OS_TARGET) \
+-  $(call core_abspath,$(NSPR_LIB_DIR)) $(call core_abspath,$<)
+-else
+-ifeq ($(CROSS_COMPILE),1)
+-  # do nothing
+-else
+-  cd $(OBJDIR) ; sh $(SRCDIR)/sign.sh $(call core_abspath,$(DIST)) \
+-  $(call core_abspath,$(OBJDIR)) $(OS_TARGET) \
+-  $(call core_abspath,$(NSPR_LIB_DIR)) $(call core_abspath,$<)
+-endif
+-endif
+-
+ libs: install
+ ifdef CHECKLOC
+   $(MAKE) $(CHECKLOC)
+
+base-commit: 2951778f8e8855bed24754a57ecc43f02a2843dd
+-- 
+2.41.0
+
-- 
2.41.0

[PATCH 5/6] gnu: nss-certs: Update to 3.99.

[Christina O'Donnell]

gnu/packages/certs.scm (nss-certs-3.88.1): New variable.
(nss-certs-3.98): Update and rename to nss-certs-3.99.
(nss-certs): Update to 3.99.

Change-Id: I2f5f737d44d08497d4f5e0e07557be36d2f1f070
---
 gnu/packages/certs.scm | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/certs.scm b/gnu/packages/certs.scm
index 7078c7c8d11..7aa96493fbe 100644
--- a/gnu/packages/certs.scm
+++ b/gnu/packages/certs.scm
@@ -125,7 +125,7 @@ (define-public certdata2pem
 that was originally contributed to Debian.")
   (license license:isc
 
-(define-public nss-certs
+(define-public nss-certs-3.88.1
   (package
 (name "nss-certs")
 ;; XXX We used to refer to the nss package here, but that eventually caused
@@ -188,10 +188,10 @@ (define-public nss-certs
 (home-page "https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS;)
 (license license:mpl2.0)))
 
-(define-public nss-certs-3.98
+(define-public nss-certs-3.99
   (package
-(inherit nss-certs)
-(version "3.98")
+(inherit nss-certs-3.88.1)
+(version "3.99")
 (source (origin
   (method url-fetch)
   (uri (let ((version-with-underscores
@@ -202,7 +202,21 @@ (define-public nss-certs-3.98
   "nss-" version ".tar.gz")))
   (sha256
(base32
-"1kh98amfklrq6915n4mlbrcqghc3srm7rkzs9dkh21jwscrwqjgm"))
+"15il9fsmixa1r4446zq1wl627sg0hz9h67w6kjxz273xz3nl7li7"))
+  ;; Create nss.pc and nss-config.
+  (patches (search-patches "nss-3.56-pkgconfig.patch"
+   "nss-getcwd-nonnull.patch"
+   "nss-increase-test-timeout.patch"
+   "nss-Disable-library-signing.patch"))
+  (modules '((guix build utils)))
+  (snippet
+   '(begin
+  ;; Delete the bundled copy of these libraries.
+  (delete-file-recursively "nss/lib/zlib")
+  (delete-file-recursively "nss/lib/sqlite")))
+
+(define-public nss-certs
+  nss-certs-3.99)
 
 (define-public le-certs
   (package
-- 
2.41.0

Re: Value in adding Shepherd requirements to file-systems entries?

[Development of GNU Guix and the GNU System distribution.]

Hi Richard,

On Tue, Apr 23 2024, Richard Sent wrote:

> I submitted a patch [..] at https://issues.guix.gnu.org/70542. If this
> winds up merged I believe your code could be rewritten [as]
>
> --8<---cut here---start->8---
> (file-system
>(device "wallace-server.local:/acct")
>(mount-point "/acct")
>(type "nfs")
>(requirement '(avahi-daemon)) ;resolve .local
>;; (flags '(no-atime no-dev no-exec read-only))
>;; (options "proto=tcp6,timeo=300,nolock")
>(check? #f)
>(mount-may-fail? #t)
>(create-mount-point? #t))
> --8<---cut here---end--->8---

Wow, that works!

Since this short form is optional and I can always switch back to the
previous version, v2 of that patch should be merged without further
delay.

Thank you for your most valuable contribution!

Kind regards,
Felix

P.S. The code above should read (requirements ...) in the plural.

Re: "Error: Could not set character size"

[Attila Lendvai]

seems like a `guix pull` and a `guix home reconfigure` resolved it.

sorry for the noise.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“If you wind up with a boring, miserable life because you listened to your mom, 
your dad, your teacher, your priest, or some guy on TV telling you how to do 
your shit, then YOU DESERVE IT.”
— Frank Zappa (1940–1993), 'The Real Frank Zappa Book' (1989)

Re: API for rewriting package fields ?

[Efraim Flashner]

On Fri, Apr 26, 2024 at 05:25:47PM +0200, Ricardo Wurmus wrote:
> Nicolas Graves via "Development of GNU Guix and the GNU System distribution." 
>  writes:
> 
> > Is there an interface to rewrite / update a field from a series of
> > packages easily?
> 
> We have "update-package-inputs" in (guix upstream), which defines a
> local procedure "update-field".  Perhaps you can use that?
> 
> What it cannot do yet is *create* a field, e.g. add a native-inputs
> field to add an input when the package currently doesn't have a
> native-inputs field.

There's also the package property updater-extra-{native-,propagated-,}inputs
to add a package even if it's not shown as required by the importer.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Managing patches and branches, retrospective and futher changes?

[Efraim Flashner]

On Wed, Apr 24, 2024 at 02:21:56PM +0100, Christopher Baines wrote:
> Hey!
> 
> Almost a year ago, the branching strategy was changed [1][2].
> 
> 1: https://issues.guix.gnu.org/63459
> 2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html
> 
> I think these changes have gone OK, we've had ~27 [3] branches merged in
> this manor and I think looking back these changes have been
> helpful. Coordination and visibility has improved, and we've been able
> to build and test more prior to merging.

I'd like to just say that this (without checking the numbers) is almost
10x the number of merges we had previously with just the
core-updates/staging branch strategy.

> 3: https://issues.guix.gnu.org/search?query=%22Request+for+merging%22
> 
> There's still room for more improvement though. The current guidance is
> here [4], and I've sent a patch for improvements here [5].
> 
> 4: 
> https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html
> 5: https://issues.guix.gnu.org/70549
> 
> Let me know if you have any thoughts or questions!
> 
> Thanks,
> 
> Chris



-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Core updates status

[Efraim Flashner]

On Fri, Apr 26, 2024 at 01:56:12PM +0100, Steve George wrote:
> Hi,
> 
> On 25 Apr, Kaelyn wrote:
> > Hi,
> > 
> > On Tuesday, April 23rd, 2024 at 11:08 PM, Steve George  
> > wrote:
> (...)
> > > - guile-rsvg failing
> > > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70537
> > > - I'm able to build librsvg@2.56.4 but not guile-rsvg
> > > - guile-rsvg@2.18.1 / guile2.2-rsvg
> > > - guile-rsvg builds on master - connected?
> > 
> > I've started looking at this build failure this morning, and my initial 
> > impressions are that a propagated-input is missing. I tried building 
> > guile-rsvg from core-updates and the build failed with three missing pango 
> > libraries (ld could not find -lpangocairo-1.0, -lpangoft2-1.0, and 
> > -lpango-1.0). I tried moving pango from the inputs to the propagated-inputs 
> > for librsvg, and that fixed the build of guile-rsvg. I'm just not sure if 
> > that is the right place to propagate it; I haven't yet traced where the 
> > pango libraries are being added to the linking command, as I've checked the 
> > pkgconfig files for librsvg, cairo, and a couple of other packages and not 
> > seen references to pango (which is what makes me think the pango 
> > propagated-input is needed elsewhere, and not actually in librsvg--but I 
> > also don't know Rust or what dependencies the rust code in librsvg has).
> 
> That's great, thanks for taking a look. Efraim mentioned that there would be 
> Rust changes for it.

Seeing that librsvg has rust-pango (and some others) in cargo-inputs,
and therefore needs pango to build, I think it's safe to move pango (and
others as needed) to propagated inputs. Make sure to make the necessary
changes to librsvg-2.40 also.

I haven't had any problems building the rust based librsvg on
core-updates, so I'd suggest leaving that alone for now.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: API for rewriting package fields ?

[Ricardo Wurmus]

Nicolas Graves via "Development of GNU Guix and the GNU System distribution." 
 writes:

> Is there an interface to rewrite / update a field from a series of
> packages easily?

We have "update-package-inputs" in (guix upstream), which defines a
local procedure "update-field".  Perhaps you can use that?

What it cannot do yet is *create* a field, e.g. add a native-inputs
field to add an input when the package currently doesn't have a
native-inputs field.

-- 
Ricardo

Re: Core updates status

[Steve George]

Hi,

On 25 Apr, Kaelyn wrote:
> Hi,
> 
> On Tuesday, April 23rd, 2024 at 11:08 PM, Steve George  
> wrote:
(...)
> > - guile-rsvg failing
> > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70537
> > - I'm able to build librsvg@2.56.4 but not guile-rsvg
> > - guile-rsvg@2.18.1 / guile2.2-rsvg
> > - guile-rsvg builds on master - connected?
> 
> I've started looking at this build failure this morning, and my initial 
> impressions are that a propagated-input is missing. I tried building 
> guile-rsvg from core-updates and the build failed with three missing pango 
> libraries (ld could not find -lpangocairo-1.0, -lpangoft2-1.0, and 
> -lpango-1.0). I tried moving pango from the inputs to the propagated-inputs 
> for librsvg, and that fixed the build of guile-rsvg. I'm just not sure if 
> that is the right place to propagate it; I haven't yet traced where the pango 
> libraries are being added to the linking command, as I've checked the 
> pkgconfig files for librsvg, cairo, and a couple of other packages and not 
> seen references to pango (which is what makes me think the pango 
> propagated-input is needed elsewhere, and not actually in librsvg--but I also 
> don't know Rust or what dependencies the rust code in librsvg has).

That's great, thanks for taking a look. Efraim mentioned that there would be 
Rust changes for it.

Steve / Futurile

"Error: Could not set character size"

[Attila Lendvai]

...when trying to build a guix checkout.

to reproduce:

$ make doc/images/service-graph.png
  DOT  doc/images/service-graph.png
Error: Could not set character size
[error message repeated 12 more times]

this seems to be an error coming from graphviz. this is all i could find 
online, which is not very useful:

https://gitlab.com/graphviz/graphviz/-/issues/863

maybe this commit a few days ago changed something? looks innocent, though:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4099b12f9f4561d0494c7765b484b53d9073b394

any hints?

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“You cannot transmit wisdom and insight to another person. The seed is already 
there. A good teacher touches the seed, allowing it to wake up, to sprout, and 
to grow.”
— Thich Nhat Hanh (1926–)

API for rewriting package fields ?

[Development of GNU Guix and the GNU System distribution.]

Is there an interface to rewrite / update a field from a series of
packages easily?

What I get from the change in python-team last change for the
pyproject-build-system is that we need to add python-setuptools or
python-wheel to all packages that will complain about it, when trying to
build. The errors are very easy to diagnose (a string match in stderr: 
ModuleNotFoundError: No module named 'setuptools'
or
error: invalid command 'bdist_wheel'
is enough to know what's wrong).

The logical thing to do here IMO would be to have a script running,
reading stderr when it fails and programmatically replacing where it's
needed, since it's done for 2-3k packages basically.

I know some work has been done with the guix refresh command to rewrite
based on package field location, but I'm not sure it provides a
convenient-enough API to simply say in guile "add this package to
native-inputs of this package in place".

Would love some counselling here, thanks!

-- 
Best regards,
Nicolas Graves

Re: Should we include nss-certs out of the box?

[Clément Lassieur]

Hello!

On Thu, Apr 25 2024, Maxim Cournoyer wrote:

> Clément Lassieur  writes:
>
>> On Wed, Apr 03 2024, Maxim Cournoyer wrote:
>>
>>> It's been Guix policy to let people choose whether to install or not TLS
>>> root certificates and which one to their machine.  While I applaud the
>>> idea to have the users make a conscious decision about it, in practice I
>>> suppose very few of us choose to *not* install any as that basically
>>> breaks using web browsers, especially ones like IceCat which (by
>>> default) ensures HTTPS is used on every page.
>>
>> I'd be surprised Icecat breaks from this as it uses its own cert
>> database and allows HTTP when HTTPS doesn't work.
>
> I didn't know Icecat had its own cert database.
>
> About allowing HTTP, it can access pages using it, but not without going
> through a "Continue despite security risks" dialog, and perhaps turning
> off the HTTPS everywhere add-on for the page, which is installed by
> default.

Indeed!  (Well it's not an add-on anymore, but a Firefox native mode
called HTTPS-only.)

https://support.mozilla.org/en-US/kb/https-only-prefs

Cheers,
Clément

Re: Core updates status

[Kaelyn]

Hi,

On Tuesday, April 23rd, 2024 at 11:08 PM, Steve George  
wrote:

> 
> 
> Hi,
> 
> We're trying to stabilise and merge core-updates, help definitely wanted!
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70456
> 
> So far the main blockers are:
> 
> - guile-rsvg failing
> - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70537
> - I'm able to build librsvg@2.56.4 but not guile-rsvg
> - guile-rsvg@2.18.1 / guile2.2-rsvg
> - guile-rsvg builds on master - connected?

I've started looking at this build failure this morning, and my initial 
impressions are that a propagated-input is missing. I tried building guile-rsvg 
from core-updates and the build failed with three missing pango libraries (ld 
could not find -lpangocairo-1.0, -lpangoft2-1.0, and -lpango-1.0). I tried 
moving pango from the inputs to the propagated-inputs for librsvg, and that 
fixed the build of guile-rsvg. I'm just not sure if that is the right place to 
propagate it; I haven't yet traced where the pango libraries are being added to 
the linking command, as I've checked the pkgconfig files for librsvg, cairo, 
and a couple of other packages and not seen references to pango (which is what 
makes me think the pango propagated-input is needed elsewhere, and not actually 
in librsvg--but I also don't know Rust or what dependencies the rust code in 
librsvg has).

Cheers,
Kaelyn
> This blocks further progress
> 
> What builds so far:
> 
> - gcc-toolchain and all the dependents from commencement.scm
> ./pre-inst-env guix build --no-substitutes gcc-toolchain
> 
> - bunch of the basic - but blocked on guile-rsvg
> ./pre-inst-env guix system --no-substitutes vm 
> gnu/system/examples/bare-bones.tmpl
> 
> Other potential issues:
> 
> - 45885 libpng non-deterministic build
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45885
> won't build due to block on pango -
> 
> - 58719 [core-updates]: build failure for file on i686
> https://ci.guix.gnu.org/build/4057809/details
> 
> - 40316 [core-updates] Nss not reproducible
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316
> confirmed
> 
> - 68270 libstdc++-boot0.x86_64 is broken
> - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68270
> 
> - 39415 [core-updates] Removing SSL patches in CMake and Kodi - help wanted
> - check if they are there and remove?
> - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39415
> 
> 
> This is building from 4a0e6e3895cefe7c2999c22e56fe9b3dbca97f55 which includes 
> the last merge from master.
> 
> Thanks,
> 
> Steve

Re: Managing patches and branches, retrospective and futher changes?

[Christopher Baines]

Steve George  writes:

> I think we should strongly recommend against long-running unmerged branches.
>
> Perhaps there could be a recommendation to merge every 3 months.

My hope is that with these process changes, we won't end up with
long-running branches.

Maybe we could add a recommendation, but I'm not really sure if that
would help. We still want to merge these changes when they and related
things are ready, so it's not really something that can be willed or
commanded to happen.

> Could we add any automation to remind people if:
>
> 1. a branch has been unmerged for more than 3 months

We can have QA highlight how long the issues have been open for, that's
quite easy to do.

> 2. an odd merge takes places (e.g. the core-updates merges)

I'm not quite sure what you mean here?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: nss not reproducible

[Christina O'Donnell]

Hi,

I believe I have a fix for this, I'm just waiting on my machine to hurry 
up and confirm it, might end up running over night, then I'll send my 
patch up.


I'm doing two native builds and two cross-builds.

I've also updated to 3.99.

Kind regards,

Christina

On 25/04/2024 15:06, Christina O'Donnell wrote:

Hi Steve,


It would be good to confirm this one:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316


Still fails to reproduce with those changes applied.

The culprit is in nss/cmd/shlibsign/shlibsign.c:

shlibSignHMAC generates a new key-pair each time it's run:

    /* Generate a DSA key pair */
    logIt("Generate an HMAC key ... \n");
    crv = pFunctionList->C_GenerateKey(hRwSession, ,
   hmacKeyTemplate,
PR_ARRAY_SIZE(hmacKeyTemplate),
   );

Three options:
 1. Disable library signing entirely.
 2. Seed the generation to be deterministic.
 3. Drop in a HMAC key-pair and patch the code to use that instead of 
generating.


2 and 3 defeat the point of the cryptographically secure supply chain 
as the private key can be obtained deterministically, so my vote would 
be simply  to not sign the libraries (1), which would be easier to 
maintain. We're not the primary distributor and users can verify our 
distribution of nss by running `guix challenge` anyway.


It looks like Zhen Junjie applied two patches to fix NSS 
cross-compilation on Master [0]


Building everything cross-compiled to ARM now.

Kind regards,

Christina

Re: Python's native-inputs

[Development of GNU Guix and the GNU System distribution.]

Hi Guix,

Just to let you know, I just added a working patch series that does this
job on (guix build, guix import pypi, guix lint). This is not the full
patch series, which I have rebased on python-team, but it should be good
enough
1) to test it
2) to review it for a v2 that would be more guixy

It's in 70570.

Cheers,
Nicolas 

On 2024-04-22 16:40, Ricardo Wurmus wrote:

>>  TL;DR :
>>  - patch series in big progress, not done yet because I don't really
>>  know where to stop and massive rebuilds.
>
> Please take a look at the python-team branch, which contains changes to
> the build system.

-- 
Best regards,
Nicolas Graves

Re: Should we include nss-certs out of the box?

[Maxim Cournoyer]

Hello!

Clément Lassieur  writes:

> On Wed, Apr 03 2024, Maxim Cournoyer wrote:
>
>> It's been Guix policy to let people choose whether to install or not TLS
>> root certificates and which one to their machine.  While I applaud the
>> idea to have the users make a conscious decision about it, in practice I
>> suppose very few of us choose to *not* install any as that basically
>> breaks using web browsers, especially ones like IceCat which (by
>> default) ensures HTTPS is used on every page.
>
> I'd be surprised Icecat breaks from this as it uses its own cert
> database and allows HTTP when HTTPS doesn't work.

I didn't know Icecat had its own cert database.

About allowing HTTP, it can access pages using it, but not without going
through a "Continue despite security risks" dialog, and perhaps turning
off the HTTPS everywhere add-on for the page, which is installed by
default.

-- 
Thanks,
Maxim

Re: Core updates status

[Christina O'Donnell]

Hi Steve,


It would be good to confirm this one:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316


Still fails to reproduce with those changes applied.

The culprit is in nss/cmd/shlibsign/shlibsign.c:

shlibSignHMAC generates a new key-pair each time it's run:

    /* Generate a DSA key pair */
    logIt("Generate an HMAC key ... \n");
    crv = pFunctionList->C_GenerateKey(hRwSession, ,
   hmacKeyTemplate,
PR_ARRAY_SIZE(hmacKeyTemplate),
   );

Three options:
 1. Disable library signing entirely.
 2. Seed the generation to be deterministic.
 3. Drop in a HMAC key-pair and patch the code to use that instead of 
generating.


2 and 3 defeat the point of the cryptographically secure supply chain as 
the private key can be obtained deterministically, so my vote would be 
simply  to not sign the libraries (1), which would be easier to 
maintain. We're not the primary distributor and users can verify our 
distribution of nss by running `guix challenge` anyway.



It looks like Zhen Junjie applied two patches to fix NSS cross-compilation on 
Master [0]


Building everything cross-compiled to ARM now.

Kind regards,

Christina

Re: Managing patches and branches, retrospective and futher changes?

[Steve George]

Hi,

I think we should strongly recommend against long-running unmerged branches.

Perhaps there could be a recommendation to merge every 3 months.

Could we add any automation to remind people if:

1. a branch has been unmerged for more than 3 months
2. an odd merge takes places (e.g. the core-updates merges)

Thanks,

Steve

On 24 Apr, Christopher Baines wrote:
> Hey!
> 
> Almost a year ago, the branching strategy was changed [1][2].
> 
> 1: https://issues.guix.gnu.org/63459
> 2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html
> 
> I think these changes have gone OK, we've had ~27 [3] branches merged in
> this manor and I think looking back these changes have been
> helpful. Coordination and visibility has improved, and we've been able
> to build and test more prior to merging.
> 
> 3: https://issues.guix.gnu.org/search?query=%22Request+for+merging%22
> 
> There's still room for more improvement though. The current guidance is
> here [4], and I've sent a patch for improvements here [5].
> 
> 4: 
> https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html
> 5: https://issues.guix.gnu.org/70549
> 
> Let me know if you have any thoughts or questions!
> 
> Thanks,
> 
> Chris

Potential security issue with make authenticate and mitigation

[John Kehayias]

Hi Guix-ers,

Please see the below message (and attached report for further details)
of a potential security issue and mitigation in Guix, from Skyler
Ferris. The very short version: 'make authenticate' is a potential
attack vector, which can be mitigated by using 'guix git authenticate'
in a development workflow.

This was raised to guix-security some months ago, but unfortunately
went through various stalls and got lost for a bit. My apologies to
Skyler and thanks for their patience. At least one other person on
guix-security also recommended we open this up for public comment,
which I agree would be good as we can discuss the potential workflow
and documentation changes quickly and transparently.

Please also see the proposed changes to make 'guix git authenticate'
easier to use, which could also help make easier to use in the Guix
workflow: 

(As an aside, some new members for guix-security would be helpful. I'm
happy to continue but will be away for about a month soon.)

>From Skyler, lightly edited for formatting:

In 2020, the "guix git authenticate" tool was added in order to secure
updates (1). This protection is still intact! The tool also had the
secondary effect of protecting developers against malicious commits
while we are developing. In fact, the manual currently recommends that
all developers run "make authenticate" after every pull for this
purpose (2).

Unfortunately, it turns out that "make authenticate" can itself be
used as an attack vector. The core of the problem is that "make
authenticate" uses the Makefile before the commits have been
authenticated, allowing an attacker to replace the Makefile with a
malicious version. The attacker would need the ability to inject the
malicious commit into the data you pull: for example, by compromising
the Savannah server or poisoning a DNS cache. The attached report
contains full details and a proof of concept.

Fortunately, preventing this problem is fairly straightforward:
instead of running "make authenticate", run "guix git authenticate"
manually. This will detect the malicious commit before the Makefile is
used, alerting you to the problem. As a first step towards a long-term
solution we can stop recommending the use of "make authenticate" in
the manual. We would like to remove the "authenticate" target entirely
because it is easy to misuse. However, this could break existing
workflows. Hopefully this is trivial to solve by running the tool
manually as mentioned above but maybe there are some situations we
have not considered - let us know! We are also aware that the
post-push hook installed by Guix runs "make authenticate". However,
this is only done as a reminder to the developer to avoid breaking
"guix pull"; it is not done for the developer's security. The
post-push hook can be changed to use "guix git authenticate" instead
of "make authenticate" in the same set of patches to avoid breaking
anything.

(1) 

(2) 

Thanks everyone!
John

(Apologies is this went through to some people, but I only realized
days later it wasn't sent to the correct guix-devel address.)


security-report.md
Description: Binary data

Re: rust-team branch merged

[Efraim Flashner]

On Wed, Apr 24, 2024 at 11:58:22AM -0400, Jason Conroy wrote:
> 
> Efraim Flashner  writes:
> > On the other hand, by generating it during the build of each package we
> > make sure to pull in all the crates which exist in the build, so we
> > could add into a profile/manifest just the crates listed in a Cargo.toml
> > and then each crate would pull in its own dependencies, and then the
> > profile hook could combine them all together.
> 
> Thanks. Just to make sure I understand: it sounds like you're saying that by
> creating the JSON index files up front, we'd be preserving some knowledge
> about a package's dependency graph that isn't easily recovered later by
> recursively walking through inputs and cargo-inputs for the package specs in
> a manifest/profile?

If we create it upfront it may be easier to keep track of the
cargo-dependencies, but I suppose it would mostly depend on the
implementation.  I'm not sure that'd actually be the case, so don't
worry about it too much.  Whatever we end up with will be better than
what we have now, and we can always make it better later if it needs to
change.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: rust-team branch merged

[Jason Conroy]

Efraim Flashner  writes:
On the other hand, by generating it during the build of each 
package we
make sure to pull in all the crates which exist in the build, so 
we
could add into a profile/manifest just the crates listed in a 
Cargo.toml
and then each crate would pull in its own dependencies, and then 
the

profile hook could combine them all together.


Thanks. Just to make sure I understand: it sounds like you're 
saying that by creating the JSON index files up front, we'd be 
preserving some knowledge about a package's dependency graph that 
isn't easily recovered later by recursively walking through inputs 
and cargo-inputs for the package specs in a manifest/profile?


Jason

Re: rust-team branch merged

[Efraim Flashner]

On Thu, Apr 18, 2024 at 12:54:02PM -0400, Jason Conroy wrote:
> 
> Efraim Flashner  writes:
> 
> > Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 then
> > you'd have both rand-0.*.crate files in the registry but only one of
> > them would be listed in share/cargo/registry/index/ra/nd/rand. I need to
> > adjust the generation of that file to combine multiple sources if they
> > exist, and sort them (I'm not sure it's necessary, but wouldn't be
> > surprised if we hit undefined behaviour if they were listed multiple
> > times or out of order).
> 
> Hi Efraim,
> 
> I'm currently investigating this limitation of your proposed patch.
> 
> Did you have a strategy in mind for how to fix it? I see that the index
> files are currently generated during a phase of cargo-build-system, rather
> than as a profile hook. So, to build an index that properly reflects the
> contents of a profile, it would seem that the two simplest options are: a)
> keep your existing index-generation logic during the build, and merge these
> per-package index files when building the profile; or b) move your patch's
> index-generating code out of the build phase and into a profile hook, so
> that we build each index file in a single pass (for all versions of a
> package) rather than merging the files from each package output.
> 
> On the surface option (b) seems cleaner, but maybe you had a reason for
> generating the index contents during the build?

I like the idea of moving the code into a profile hook much better than
what I have now.  What's there was more of a proof-of-concept of how it
might work.

On the other hand, by generating it during the build of each package we
make sure to pull in all the crates which exist in the build, so we
could add into a profile/manifest just the crates listed in a Cargo.toml
and then each crate would pull in its own dependencies, and then the
profile hook could combine them all together.  The down side is we'd
have to have the logic to combine the overlapping rand-0.7/rand-0.8
paths both in the build system and in the profile.  Overall it doesn't
seem that bad though, since we could then add packages either as a
regular input or as a cargo-input.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Core updates status

[Christina O'Donnell]

Okay, I'll let you know as soon as I know.

On 24/04/2024 14:17, Steve George wrote:

Hi,

You just need to checkout core-updates and then 'start building'!

It would be good to confirm this one:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316

It looks like Zhen Junjie applied two patches to fix NSS cross-compilation on 
Master [0]

Maybe master and core-updates have diverged - I haven't had time to look.

To check for reproducibility do a normal build, and if that's successful do the 
same build with `--check`

Thanks,

Steve

[0] 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fb86bf658a9374d41b05c5e586bfc6a3150cc3cb
  and 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=452e7673bfeb0a14cecb8e760dda2c436aa69047


On 24 Apr, Christina O'Donnell wrote:

Hi Steve,

On 24/04/2024 07:08, Steve George wrote:

Hi,

We're trying to stabilise and merge core-updates, help definitely wanted!

I'd love to help! Any of these issues novice-friendly?

Will there be a point release after core-updates is merged?

Kind regards,

Christina

Managing patches and branches, retrospective and futher changes?

[Christopher Baines]

Hey!

Almost a year ago, the branching strategy was changed [1][2].

1: https://issues.guix.gnu.org/63459
2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html

I think these changes have gone OK, we've had ~27 [3] branches merged in
this manor and I think looking back these changes have been
helpful. Coordination and visibility has improved, and we've been able
to build and test more prior to merging.

3: https://issues.guix.gnu.org/search?query=%22Request+for+merging%22

There's still room for more improvement though. The current guidance is
here [4], and I've sent a patch for improvements here [5].

4: 
https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html
5: https://issues.guix.gnu.org/70549

Let me know if you have any thoughts or questions!

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Core updates status

[Steve George]

Hi,

You just need to checkout core-updates and then 'start building'!

It would be good to confirm this one:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316

It looks like Zhen Junjie applied two patches to fix NSS cross-compilation on 
Master [0]

Maybe master and core-updates have diverged - I haven't had time to look.

To check for reproducibility do a normal build, and if that's successful do the 
same build with `--check`

Thanks,

Steve 

[0] 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fb86bf658a9374d41b05c5e586bfc6a3150cc3cb
 and 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=452e7673bfeb0a14cecb8e760dda2c436aa69047


On 24 Apr, Christina O'Donnell wrote:
> Hi Steve,
> 
> On 24/04/2024 07:08, Steve George wrote:
> > Hi,
> > 
> > We're trying to stabilise and merge core-updates, help definitely wanted!
> 
> I'd love to help! Any of these issues novice-friendly?
> 
> Will there be a point release after core-updates is merged?
> 
> Kind regards,
> 
> Christina
> 
> 

Re: Core updates status

[Christina O'Donnell]

Hi Steve,

On 24/04/2024 07:08, Steve George wrote:

Hi,

We're trying to stabilise and merge core-updates, help definitely wanted!


I'd love to help! Any of these issues novice-friendly?

Will there be a point release after core-updates is merged?

Kind regards,

Christina

Core updates status

[Steve George]

Hi,

We're trying to stabilise and merge core-updates, help definitely wanted!

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70456

So far the main blockers are:

- guile-rsvg failing
  - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70537
  - I'm able to build librsvg@2.56.4 but not guile-rsvg
  - guile-rsvg@2.18.1 / guile2.2-rsvg
  - guile-rsvg builds on master - connected?

This blocks further progress 

What builds so far: 

  - gcc-toolchain and all the dependents from commencement.scm
  ./pre-inst-env guix build --no-substitutes gcc-toolchain

  - bunch of the basic - but blocked on guile-rsvg
  ./pre-inst-env guix system --no-substitutes vm 
gnu/system/examples/bare-bones.tmpl

Other potential issues:

- 45885  libpng non-deterministic build
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45885
  won't build due to block on pango - 

- 58719 [core-updates]: build failure for file on i686
  https://ci.guix.gnu.org/build/4057809/details

- 40316 [core-updates] Nss not reproducible
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316
  confirmed 

- 68270  libstdc++-boot0.x86_64 is broken
  - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68270

- 39415  [core-updates] Removing SSL patches in CMake and Kodi - help wanted
- check if they are there and remove?
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39415


This is building from  4a0e6e3895cefe7c2999c22e56fe9b3dbca97f55 which includes 
the last merge from master.

Thanks,

Steve

Re: Value in adding Shepherd requirements to file-systems entries?

[Richard Sent]

Hi Felix,

> Someone once gave me this service [1] to mount a file-system declared
> with (mount? #f). [2] It's been working ever since.

Thanks! I know custom services can be made that can work on a
case-by-case basis. I was curious about the value of encapsulating that
logic within an operating-system file-systems field and reusing the
existing code of file-system-shepherd-service in (gnu services base) and
mount-file-system in (gnu build file-system).

My comment on NFS support is more about how mount-file-system supports
mounting NFS file-system records, but the existing code that actually
uses mount-file-system tries mounting all file systems before networking
has begun. Ergo, the fact that mount-file-system supports NFS seems a
bit extraneous at present, at least insofar as I can decipher.

I submitted a patch for what I'm thinking at
https://issues.guix.gnu.org/70542. If this winds up merged I believe
your code could be rewritten to remove [1] and replace [2] with

--8<---cut here---start->8---
(file-system
   (device "wallace-server.local:/acct")
   (mount-point "/acct")
   (type "nfs")
   (requirement '(avahi-daemon)) ;resolve .local
   ;; (flags '(no-atime no-dev no-exec read-only))
   ;; (options "proto=tcp6,timeo=300,nolock")
   (check? #f)
   (mount-may-fail? #t)
   (create-mount-point? #t))
--8<---cut here---end--->8---

(I don't have an NFS system on my LAN to test so no promises)

Hopefully that shows what I'm thinking. If anyone has thoughts I'd love
to hear it, either here or in the patch depending on what's appropriate.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

Re: Python's native-inputs

[Development of GNU Guix and the GNU System distribution.]

On 2024-04-22 16:40, Ricardo Wurmus wrote:

>>  TL;DR :
>>  - patch series in big progress, not done yet because I don't really
>>  know where to stop and massive rebuilds.
>
> Please take a look at the python-team branch, which contains changes to
> the build system.

I'll rebase on it, thanks.

-- 
Best regards,
Nicolas Graves

Re: A capture-stdout wrapper procedure in (guix build utils)?

[Fabio Natali]

On 2024-04-21, 08:35 -0700, Felix Lechner  wrote:
> It may be better, however, to finally fix Guile's 'system' and
> 'system*' to work with 'with-output-to-string'. [2]

Hi Felix,

Thanks for getting back to me.

Great point re potentially fixing this further up in the "chain",
i.e. in Guile. I'll try and raise this on the Guile IRC channel and/or
ML and update this thread with my findings.

Thanks, best wishes, Fabio.


-- 
Fabio Natali
https://fabionatali.com

Re: Is git the best tool for pulling packages?

[Ricardo Wurmus]

Adam  writes:

> As I see, first guix pull running too long for a lot of people.

Note that this is not due to download speeds but often due to
compilation.  When updating Guix you are not just fetching new data, but
a new version of Guix itself (which happens to come with a library
encoding package relationships).  That new version may need to be
compiled locally, which is slow.  We aim to provide pre-built components
that Guix can download instead, but computing what needs to be fetched
in the first place *also* takes a decent amount of time.

The problem would be the same if the transport mechanism was a
compressed archive instead of an update to a git repository.

> Probably there are ways to cache all of this.

We are caching things in ~/.cache/guix.

-- 
Ricardo

Re: Should we include nss-certs out of the box?

[Clément Lassieur]

On Wed, Apr 03 2024, Maxim Cournoyer wrote:

> It's been Guix policy to let people choose whether to install or not TLS
> root certificates and which one to their machine.  While I applaud the
> idea to have the users make a conscious decision about it, in practice I
> suppose very few of us choose to *not* install any as that basically
> breaks using web browsers, especially ones like IceCat which (by
> default) ensures HTTPS is used on every page.

I'd be surprised Icecat breaks from this as it uses its own cert
database and allows HTTP when HTTPS doesn't work.

Kind regards,
Clément

Re: Is git the best tool for pulling packages?

[Leo Famulari]

>From a computational perspective, downloading tarballs is much simpler than 
>fetching from Git.

But Git offers so many advantages, and computing has become so inexpensive, 
that it's become very common to use Git instead.

Recent Git implementations have optimized serving of specific Git commits, as 
compared to fetching the entire Git history. That means that you can fetch a 
single revision of a huge repo, using a small amount of bandwidth.

For the specific case of `guix pull`, the Git server is hosted at Savannah, 
which does not use one of these optimized Git implementations, so it is 
relatively slow and expensive to fetch.

Additionally, Guix's authentication mechanism requires fetching many Git 
revisions in order to verify the chain of trusted revisions (Git commits).

This requirement to fetch many Git revisions, combined with the unoptimized Got 
server on Savannah, means that `guix pull` may be slower than comparable 
actions on other distros, especially the first time, and if you haven't pulled 
in a while 

On Sun, Apr 21, 2024, at 18:31, Adam wrote:
> Hi guix!
> Recently I used nixos on one of my machines. And I noticed people there use 
> tar balls for fetching package definitions. And It worked much faster for me.
> That was surprising and I decided to write this letter.
> Is git the right tool for getting new package definitions? What if git 
> commits history will become enormous? 
> As I see, first guix pull running too long for a lot of people.
> Probably there are ways to cache all of this.
> Anyway,  I'm just curious about it. If there are already answers for my 
> question, I would like to read them.

Re: Fallout from recent nss-certs changes

[pelzflorian (Florian Pelz)]

Ian Eure  writes:
> The change is mentioned in the channel news, but it says nothing about
> needing to remove that part of the config.

You are right; I have added more explicit instructions as commit
e5c0ea22e68cc8d6f99957295bc9198afb8455df.

Users should see it when they guix pull again.

Regards,
Florian

Re: Should we include nss-certs out of the box?

[pelzflorian (Florian Pelz)]

Fabio Natali  writes:
> For what it's worth, I put together a micro-patch and sent it over as a
> follow-up to #70451.

Pushed as 67a3a83170c038d2eb084d3f53a7ea7b033aea74.

Thank you!

Regards,
Florian

Change logs: usage of square brackets

[Nigko Yerden]

Hello Guix!

I wonder what is the proper usage of square brackets in change logs. 
According to 
https://www.gnu.org/prep/standards/standards.html#Change-Logs square 
brackets are used for conditional changes, the name of the condition is 
specified inside '[ ]'.  However looking over the commit history I 
mostly see another usage of '[ ]' for specifying the name of a record 
field which content is being changed.


Is it fine to use the name of a record field inside square brackets for 
changes that are only affected if the content of the record field is #t, 
like in https://issues.guix.gnu.org/70341#2 ?


Best Regards,
Nigko Yerden

Re: Guix bios installation: Grub error: unknown filesystem

[Ada Stevenson]

Hi Attila,

On 4/22/24 9:04 PM, Attila Lendvai wrote:

This should allow grub to recognise your filesystem during the
installation process. I think using a later version of grub would fix
this, but that hasn't happened yet. I think there's a patch to upgrade
it in `core-updates` somewhere, but I'm not sure.



grub seems to be still v2.06 there:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootloaders.scm?h=core-updates#n103



Maybe it would be a good idea to upgrade it then. This incompatibility 
has probably deterred many potential Guixers- it almost deterred me. 
Having this hacky workaround is just not good UX.


I'm not sure what upgrading GRUB would involve; maybe someone else on 
the mailing list has an idea on where to start? :)


Warmly,
Ada

Re: Value in adding Shepherd requirements to file-systems entries?

[Development of GNU Guix and the GNU System distribution.]

Hi Richard,

On Mon, Apr 22 2024, Richard Sent wrote:

> NFS is allegedly supported

Someone once gave me this service [1] to mount a file-system declared
with (mount? #f). [2] It's been working ever since.

Kind regards
Felix

[1] 
https://codeberg.org/lechner/system-config/src/commit/0131082ff0eb3f1262544f7799d291324ba08282/host/lechner-desktop/operating-system.scm#L209-L222
[2] 
https://codeberg.org/lechner/system-config/src/commit/0131082ff0eb3f1262544f7799d291324ba08282/host/lechner-desktop/operating-system.scm#L130-L139

Re: Sustainability fund application ongoing

[John Kehayias]

Hi Maxim, Ludo’, and everyone,

On Mon, Apr 22, 2024 at 01:52 PM, Maxim Cournoyer wrote:

> Hi Ludovic,
>
> Ludovic Courtès  writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer  skribis:
>>
>>> It was pointed to us that the "Free and Open Source Software
>>> Sustainability Fund" [0] is currently receiving applications.  The fund
>>> aim to sponsors free software projects for their
>>> maintenance/organisational activities.
>>
>> Nice!  You forgot the link but I guess it’s
>> .
>> Deadline is May 17th.
>
> Indeed, thanks for pointing it out.
>

Thanks Maxim for sending this out, this looks like a great opportunity
(I'm sure quite competitive though)!

>>> I'm tempted to apply myself, but I thought I'd share it here: the more
>>> submissions they get the more likely Guix is to receive support.
>>
>> Agreed, it’s great to have people apply there (even better if it works,
>> of course).
>>

I'm still looking into the details of this group and their process,
but would it make sense to have small teams in applying (or in mind as
part of a proposal)? I'm thinking in terms of some input and
responsibility, for instance, in a proposal that wants to improve
things like new contributions, community, and related infrastructure
(Cuirass, Mumi, interfacing with debbugs more generally). I guess one
person applies, but in trying to figure out scope and who might be
involved should a proposal get funded it could be good to have some
people in mind.

>> Maybe we should provide a contact point for people who want to
>> coordinate when applying for Guix-related funding, to avoid overlapping
>> or competing applications?
>
> I guess we can use guix-devel for that purpose; the traffic would not justify 
> a new
> mailing list I guess (and we already have too many to keep track of :-)).

I am very interested in this and would love to discuss with some
people for needed information, input, things like scope and what would
have the most impact for Guix. So, I may be soliciting some help on
IRC, here, and reach out individually, but would love to put in a
strong proposal. (I'm at a time where I'm contemplating a career
shift, so this could fit in particularly nicely should I be so lucky.)

Thanks again Maxim for sending this!
John

Value in adding Shepherd requirements to file-systems entries?

[Richard Sent]

Hi Guix!

I wanted to ask the Guix community for their thoughts on improving the
support for adding networked file systems to an operating-system
declaration.

For some context, I started tackling adding CIFS support to file-system
declarations, but I've hit a snag. CIFS is a networked file system, but
Guix mounts all file systems specified in
(operating-system-file-systems) either when booting the system from the
initrd or as shepherd services after boot that depend on
'root-file-system and 'udev.

Either way, these run before any networking service has been
initialized. Ergo, a samba share like //192.168.1.102/share won't be
found. (At least, not on a wireless network. Perhaps the timing is
different for wired ones.)

Obviously, adding shepherd requirements to needed-at-boot? file systems
isn't possible. However, I think it should be possible to add shepherd
services to other file system entries.

(And yet, NFS is allegedly supported, although I can't figure out the
mechanism for that and don't have one set up on my LAN for testing.)

Before hacking away at this myself, I'd like to get other people's
thoughts on the best way to proceed. Do others agree that (file-system)
entries should support networked devices? Should this be transparent
depending on the type, or require explicit configuration?

e.g.

--8<---cut here---start->8---
(file-system
  (device "//192.168.1.102/share")
  (options "guest")
  (mount-point "/mnt/share")
  (type "cifs")
  ;; Should we explicitly require network, or implicitly add it from
  ;; the type? If the latter, what to do about Avahi?
  (requirement 'networking)
  (mount-may-fail? #t)
  (create-mount-point? #t))
--8<---cut here---end--->8---

I could see this being challenging since it's not immediately clear to
me what particular file-system-* service, if any, is provisioning
'file-systems, which other shepherd requirements the user may specify
can depend on. I imagine adding a requirement to the wrong file-system
could easily cause a deadlock.

I know a custom shepherd service could be used to run, say, mount.cifs
from userspace after networking is provisioned, but in my opinion it
would be cleaner to encapsulate within the existing file-system block of
the operating system.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

extlinux and a bootloader system rewrite

[Lilah Tascheter]

heyall!

I've been working on a large bootloader subsystem rewrite to get
everything working together nicer and support future bootloaders
better. however, extlinux is being a bit of an issue.

extlinux installs its second stage (ldlinux.sys) by copying it into the
root (or boot) filesystem, and then copying the on-disk block offset
into the bootblock first-stage. this relies on the now-heavily
discouraged practice of assuming files just stay in the same physical
spot. it requires special treatment with btrfs, will break if anything
rearranges the file-system, and will most likely never work on disk
images.

it hasn't been updated since 2014 and kinda shows.

a possible solution would be re-implementing its installer and instead
installing ldlinux.sys to a separate partition, or maybe see if it
could re-use GRUB's method of installing in the partition gap or even
editing the disk image installer to work in an losetup'd container or
some shit. but, honestly, I don't know if that would actually help
anyone.

does anyone use extlinux on guix still? would anyone mind if I just nix
it (guix it?) entirely in the patch series? grub supports every case
extlinux would support anyway.

thanks!
leila

Re: [PATCH] Fix typo (Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Pushed as b8ccbc942e0ec7baf695d383e575991289c6e033.

Thank you for trudging on through the list.

Regards,
Florian

Re: Guix bios installation: Grub error: unknown filesystem

[Attila Lendvai]

> This should allow grub to recognise your filesystem during the
> installation process. I think using a later version of grub would fix
> this, but that hasn't happened yet. I think there's a patch to upgrade
> it in `core-updates` somewhere, but I'm not sure.


grub seems to be still v2.06 there:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootloaders.scm?h=core-updates#n103

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“In a democracy, mass opinion creates power. Power diverts funds to the 
manufacturers of opinion, who manufacture more, etc. […] This feedback loop 
generates a playing field on which the most competitive ideas are not those 
which best correspond to reality, but those which produce the strongest 
feedback.”
— Mencius Moldbug

[PATCH] Fix typo (Re: Feedback of the GNU Guix manual)

[Matt]

We're working through a list of feedback one item at a time:
https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00117.html

We have completed the first four items.

The next item reported is:

#+begin_quote
3.8 Installing Guix in a Virtual Machine

L25 in an vm should be in a vm
#+end_quote

This is a nice, easy fix, good for me to practice getting the commit formatting 
correct :)


0001-doc-Fix-typo.patch
Description: Binary data

Re: Sustainability fund application ongoing

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> It was pointed to us that the "Free and Open Source Software
>> Sustainability Fund" [0] is currently receiving applications.  The fund
>> aim to sponsors free software projects for their
>> maintenance/organisational activities.
>
> Nice!  You forgot the link but I guess it’s
> .
> Deadline is May 17th.

Indeed, thanks for pointing it out.

>> I'm tempted to apply myself, but I thought I'd share it here: the more
>> submissions they get the more likely Guix is to receive support.
>
> Agreed, it’s great to have people apply there (even better if it works,
> of course).
>
> Maybe we should provide a contact point for people who want to
> coordinate when applying for Guix-related funding, to avoid overlapping
> or competing applications?

I guess we can use guix-devel for that purpose; the traffic would not justify a 
new
mailing list I guess (and we already have too many to keep track of :-)).

-- 
Thanks,
Maxim

Re: No default OpenJDK version?

[Maxim Cournoyer]

Hi,

Markku Korkeala  writes:

> On Tue, Apr 16, 2024 at 10:37:30PM +0200, Julien Lepiller wrote:
>> Currently, most java packages use the implicit jdk from the build
>> system (ant- or maven-build-system), which is… icedtea@8. We still
>> have quite a lot of old packages that don't build with openjdk9, so
>> I'm not sure when we can update the default jdk…
>
> Hi,
>
> is there effort to update the default jdk at some point? I could help with
> it. I'm not familiar with the guix java build systems, but have long
> experience as a Java developer. I also maintain few java packages in Fedora
> and saw the transition to to jdk11 [1], jdk17 [2] and now to jdk21 [3]. The
> pages have documented common issues and workarounds, which might help.

I'm not aware of such effort in Guix currently, so feel free to
spearhead it!  It'd be beneficial, although I supposed difficult to
achieve due to bootstrap reasons, perhaps.

-- 
Thanks,
Maxim

Re: Python's native-inputs

[Maxim Cournoyer]

Hi Nicolas,

Nicolas Graves  writes:

[...]

>  TL;DR :
>  - patch series in big progress, not done yet because I don't really
>  know where to stop and massive rebuilds.
>  - WDYT about tweaking the build-system for pytest?
>  - not done : tweaking the pypi import to ignore those packages. I've
>  done it in the juliahub import code, but I haven't delved into that
>  though.
>  - not done : adding those packages to guix lint - trivial. We should
>  probably add a variable in pypi import that is exported and added into
>  guix lint.
>
>  Acting on the three (guix import, guix lint, guix build) can make it
>  quite easy on maintainers in the end IMO.

You're bringing good arguments.  If you can pull it off in the way
outlined above, I agree it's be valuable to have.

-- 
Thanks,
Maxim

is git the right tool for getting package definitions?

[Adam]

(original message was formatted in rich text, so I decided to resend
it in plain text)
Hi guix!
Recently I used nixos on one of my machines. And I noticed people
there use tar balls for fetching package definitions. And It worked
much faster for me.
That was surprising and I decided to write this letter.
Is git the right tool for getting new package definitions? What if git
commits history will become enormous?
As I see, the first guix pull is running too long for a lot of people.
Probably, there are ways to cache all of this.
Anyway, I'm just curious about it. If there are already answers for my
question, I would like to read them.

Is git the best tool for pulling packages?

[Adam]

Hi guix!
Recently I used nixos on one of my machines. And I noticed people there use
tar balls for fetching package definitions. And It worked much faster for
me.
That was surprising and I decided to write this letter.
Is git the right tool for getting new package definitions? What if git
commits history will become enormous?
As I see, first guix pull running too long for a lot of people.
Probably there are ways to cache all of this.
Anyway,  I'm just curious about it. If there are already answers for my
question, I would like to read them.

Re: Status of ‘core-updates’

[Efraim Flashner]

On Wed, Apr 17, 2024 at 01:47:49PM -0400, Maxim Cournoyer wrote:
> Hello,
> 
> Ludovic Courtès  writes:
> 
> > Hi Steve,
> >
> > Steve George  skribis:
> >
> >> On 10 Apr, Ludovic Courtès wrote:
> >
> > [...]
> >
> >>> To be clear (but I guess it’s crystal clear to anyone who’s been around
> >>> long enough :-)), what we need most is someone to keep track of changes,
> >>> coordinate efforts, decide what goes in the branch and what’s postponed
> >>> or moved to a separate branch, and send periodic (weekly) status updates
> >>> over the course of a couple of months.  This can (and probably should)
> >>> be done without doing any actual hacking on the branch.
> >> (...)
> >>
> >> This sounds like something I can do:
> >>
> >> - track changes (in branch)
> >> - co-ordinate blocking issues (in bug system)
> >> - co-ordinate with people doing the actual work :-P
> >> - send (periodic) weekly emails
> >> - encourage shipping by minimising scope creep ;-)
> >
> > Awesome, thanks for volunteering!
> >
> >> Sounds like there's already agreement to revert the 'pkgconf' change
> >> and push a new branch without them which becomes
> >> 'core-updates'. Josselin on IRC I had the impression you were
> >> working on that?
> >
> > I’m not sure what the situation is (I see Maxim just pushed changes on
> > top of current ‘core-updates’, so maybe it’s OK?).
> 
> Since branches were merged in, I believe the problem we are facing at
> the moment is librsvg failing its test suite with a segfault (!).  Could
> be the glibc upgrade, or rust itself, I'm not sure.  I was trying to
> upgrade librsvg, which needs an update anyway, but it pulls many rust
> crates updates.  I'll get there eventually, if nobody beats me to it.

I personally think getting librsvg updated will be easier on the
rust-team branch than on the core-updates branch, since there have been
many commits to the rust-team branch that haven't yet been merged into
master.

Assuming that now that the cairo upgrade to 1.18 was what was holding
back the librsvg upgrade, I can get librsvg up to a newer version and
then submit it for a merge.  Overall the branch should be in fairly good
shape.

> > Josselin, Maxim: could you explain what problems there are around
> > pkgconf and what you would recommend?
> 
> Nothing in particular to point at the moment, but remaining problems
> would manifest in the form of missing inputs, due to transitive libtool
> dependencies causing overlinking and the new pkgconf being smart enough
> to optimize away some previously captured link directives that would be
> baked in the RUNPATH and sastify libtool overlinking needs.
> 
> The solution is to hunt the libtool .la files from the transitive
> dependencies causing the problem and removing them. See commit
> b6540bd285cbe5920ad379ddfc6256359ee7204c for an example.
> 
> -- 
> Thanks,
> Maxim
> 

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Python's native-inputs

[Ricardo Wurmus]

>  TL;DR :
>  - patch series in big progress, not done yet because I don't really
>  know where to stop and massive rebuilds.

Please take a look at the python-team branch, which contains changes to
the build system.

-- 
Ricardo

Re: Python's native-inputs

[Development of GNU Guix and the GNU System distribution.]

Answer in two different emails.

 On 2024-04-18 22:07, Maxim Cournoyer wrote:

> Hi Nicolas,
>
> Nicolas Graves via "Development of GNU Guix and the GNU System
> distribution."  writes:
>
>> Hi Guix,
>>
>> On some languages, there are a lot of unused native-inputs that are
>> development & linting dependencies much more than packages that are
>> actually used to build or test a package (I'm thinking at least Python
>> and Rust). These fall in the category of tools "useful" at run time, but
>> unecessary at build time.
>
> Indeed.

One more argument: it's important for user experience using python to
have these packages up-to-date, because users will want to have an
up-to-date lsp client and utilities.

>
>> Is there a clear policy about their removal? I've seen the case of
>> pre-commit in Python, and I've commited a series yesterday regarding
>> pylint, but there are a whole lot of them in Python, at least :
>
> [...]
>
>> These packages make a lot of sense when considering things like
>> `guix shell -D` but they are hampering some progress on Python packages
>> since they are everywhere and a small update in their inputs rebuilds
>> the whole python world (even though it has NO influence on the
>> functionality of any other package).
>>
>> What are the guidelines in this case?
>
> There aren't really any guidelines.  It's easy to avoid the linters, it
> makes sense to avoid them, but sometimes upstream makes it difficult to
> avoid running a linter as part of there test suite, in which case I
> think it's acceptable to keep them as native-inputs rather than come up
> with more patches to maintain.
>
>> I can propose a huge patch series (currently ~300 patches, and not
>> finished), to remove them, lint against them and remove them from the
>> importer as a default, but that's a big decision to make. IMO we should
>> have a dev-inputs field to handle these cases, but that's even more work.
>
> The situation is similar as for other test inputs such as pytest; it has
> an enormous amounts of dependents and thus cannot be easily upgraded on
> the master branch.  At least more up-to-date variants can be added since
> these are not in the transitive closure of any packages.

 That's true for some very essential packages (setuptools, pytest...)
 which would make the case to only update these packages once we want to
 update the whole python chain, i.e. when we update python. But IMO it
 shouldn't be the case for a package like black, isort or flake8.

>
> I don't think we should go out of our way to address annoyances that
> upstream have caused -- that'd be too much work to maintain in the long
> run.

 I think it depends on the case. For a package like python-dateutil,
 having pytest-cov as a native-input is bad, because it causes a rebuild
 of the whole chain (guix refresh -l python-pytest-cov went from ~2500
 to ~15 packages with the whole series, but in particular that was a big
 part of dependency removal). Now for small leaf packages, having
 pytest-cov as a native-input is not a big issue indeed, I agree in
 those cases we would better ignore it than fix it in the meantime.

 While making the patches, I realized it's not often that we need a
 convoluted patch. Most of the time, adding "-c" "/dev/null" to
 test-flags will do the trick to remove python-pytest-cov and it's even
 less annoyance for black, flake8 or mypy, if not other cases are often
 handled with a simple removal of the native-input in pyproject.toml, or
 setup.py. What's annoying is when packages are flagged as required when
 they're not.

 It could possibly even be handled in the build-system in the case of
 pytest, to avoid these "-c" "/dev/null". This is untested, but I think
 it'll work.
 
;; Add a pytest plugin for the pyproject-build-system to filter out some
;; arguments we want to be able to ignore.
;; (define (pytest-ignore-options group-options-alist)
;;   "This function converts an alist of (group . options) in a string that can
;; be instantiated as a python pytest plugin."
;;   (string-join
;;(cons*
;; "import pytest"
;; (map
;;  (match-lambda
;;((group . options)
;; (string-append
;;  (format #f "def pytest_addoption(parser):
;; group = parser.getgroup(~s,'Guix ignored options')
;; options = [~{~s, ~}]
;; for option in options:
;; group.addoption(option, action='count')"
;;  group
;;  options
;;  group-options-alist))
;;"\n\n"))

;; (let ((cov-alist
;;'(("cov" . ("--cov" "--cov-reset" "--cov-report" "--cov-config"
;;"--no-cov-on-fail" "--no-cov" "--cov-fail-under"
;;"--cov-append" "--cov-branch" "--cov-context")
;;   (display (pytest-ignore-options cov-alist)))

;; TODO Instantiate this file, add it to the check phase through the 
;; PYTEST_PLUGINS environment variable (possibly also PYTHONPATH or 
GUIX_PYTHONPATH ?)
;; reference: 

Re: Adding plumbing subcommand 'derivation'?

[Simon Tournier]

Hi,

On ven., 19 avril 2024 at 16:02, Ludovic Courtès  wrote:

> We should see how that fits into the set of tools we already have, in
> particular the (guix derivations) interface and the REPL meta-commands.
>
> My gut feeling, with a Schemer bias, is that we’d rather enrich the
> Scheme API and/or REPL than add more commands (this is not Nix :-)).
>
> But I don’t know, maybe we can have both?

Yes, I think that’s orthogonal and a good idea.

Maybe a new plumbing generic subcommand, as “guix inspect” or “guix
store”, where showing the fields of a derivation would be a
sub-subcommand.  For instance, diffing two derivations from the
command-line seems helpful when  debugging – I often do that with Emacs
exploiting buffer facilities. :-)

In addition, it could be helpful to improve the readability for the
pretty-printer.  Other said, somehow redesign this:

--8<---cut here---start->8---
(set-record-type-printer! 
  (lambda (drv port)
(format port "# ~a ~a>"
(derivation-file-name drv)
(string-join
 (map (match-lambda
   ((_ . output)
(derivation-output-path output)))
  (derivation-outputs drv)))
(number->string (object-address drv) 16
--8<---cut here---end--->8---

It looks like a plan. ;-)

Cheers,
simon

Re: 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

Re: Shepherd timers

[Development of GNU Guix and the GNU System distribution.]

Hi Ludo'

On Fri, Apr 19 2024, Ludovic Courtès wrote:

> that’s already possible with the #:user argument of ‘command’.

While 'command' works and was in your initial example, I had trouble
tracking down the documentation for it.  Is it a record entry destined
for 'shepherd-command'?

Spoiled by Guix's seamless Guile integration, I don't shell out much
anymore.  Will 'command' accept a thunk?

Kind regards
Felix

Re: Should we include nss-certs out of the box?

[Fabio Natali]

On 2024-04-20, 11:06 +0100, Fabio Natali  wrote:
> I'll send an update here.

Hi Maxim,

There's a couple of mentions of 'nss-certs' in the manual that might be
rephrased to reflect '65e8472a4b6fc6f66871ba0dad518b7d4c63595e'.

For what it's worth, I put together a micro-patch and sent it over as a
follow-up to #70451.

https://issues.guix.gnu.org/70451#4

Thanks, cheers, Fabio.


-- 
Fabio Natali
https://fabionatali.com

Re: System can no longer be reconfigured

[John Kehayias]

Dear Felix et al,

On Sun, Apr 21, 2024 at 08:54 AM, Felix Lechner via \"Development of GNU Guix 
and the GNU System distribution.\" wrote:

> Hi Ludo'
>
> On Fri, Apr 19 2024, Ludovic Courtès wrote:
>
>> Is it not hanging during Shepherd service upgrade?
>
> Yes, thank you!  It was hanging during the Shepherd system upgrade due
> to an invalid calendar-event specification.  In a service that uses both
> #:days-of-month as well as #:days-of-week, I got confused because the
> count starts with one in one, and with zero in the other. [1]
>
> Thank you for your kind pointer in another forum! The issue is now
> solved.
>
> On this occasion, please allow me to mention for everyone's benefit that
> your support level for the Shepherd is very generous---especially when
> the complaints involve repeated user errors by the people bothering you.
>
>> If that is the case, (1) that is not preventing upgrade from happening
>> since that’s the very last step (it just means you’ll have to reboot),
>
> Yes, but 'reboot' and 'halt' also stop working, which meant that I
> issued 'sync' a few times and then, crossing my fingers, pressed the
> reset button a few hundreds of a second later.  I wish there were a way
> to force a reboot.
>

Not sure if this is what you did, but for anyone else that didn't know
this (like me, for many years!) there is the Magic SysRq Key to talk
directly to the kernel:


I always remember "BUSIER" backwards as the sequence to push to safely
stop everything, sync disks, and reboot, without needing to use the
power button. Or the mnemonics: "raising elephants is so utterly
boring" or "reboot even if system utterly broken." Hopefully rarely
needed, but really handy when it is.

(I wrote a whole basic guide to killing things and these last keys:
)

>> (2) it’s a shepherd-related bug for which perhaps there are clues in
>> /var/log/messages?
>
> Thank you for that pointer, too.  I'm still learning about where to look
> for error messages, whose destination is not always obvious to me.
>
> Kind regards
> Felix
>
> [1]
> 

Re: No public interface for shepherd-package

[Development of GNU Guix and the GNU System distribution.]

On Fri, Apr 19 2024, Ludovic Courtès wrote:

> Is ‘shepherd’ among your channels?

Sorry, it works fine.

My message was borne from a terrible desperation after one of my most
important machines refused to reconfigure for a week.  As so often with
technical systems, it was an operator error. [1]

Kind regards
Felix

[1] https://mail.gnu.org/archive/html/guix-devel/2024-04/msg00210.html

Re: Fallout from recent nss-certs changes

[Ian Eure]

No, this is not a bug.  specification->package always returns the latest 
version of a package and has no way of knowing what variable(s) that package 
object is bound to.

On April 21, 2024 8:02:50 AM PDT, Felix Lechner  
wrote:
>Hi,
>
>On Sat, Apr 20 2024, Ian Eure wrote:
>
>> If an operating-system’s packages includes `(specification->package
>> "nss-certs")', this causes breakage, because that form selects version
>> 3.98, but %base-packages includes 3.88.1, which causes an error on the
>> next `guix system reconfigure' due to conflicting package versions in
>> the profile.
>
>Why does the unversioned stringy selector (specification->package
>"nss-certs") resolve to a version different from the unversioned
>variable nss-certs?  Is that a bug?
>
>Kind regards
>Felix
>
>P.S. I hoped to use the word "reified" but did not know how it fit in.

Thanks,

  — Ian

Re: Fallout from recent nss-certs changes

[Ian Eure]

The change is mentioned in the channel news, but it says nothing about needing 
to remove that part of the config.


On April 21, 2024 1:32:38 AM PDT, "pelzflorian (Florian Pelz)" 
 wrote:
>Hello Ian.  My understanding of the nss-certs etc/news.scm item had been
>that we should remove (specification->package "nss-certs"), which became
>unnecessary and clutters config.scm.  From what you write, this was
>actually not intended, but it is still not a bug IMHO.
>
>(I’m not involved with the change, though.)
>
>Regards,
>Florian

Thanks,

  — Ian

Re: System can no longer be reconfigured

[Development of GNU Guix and the GNU System distribution.]

Hi Ludo'

On Fri, Apr 19 2024, Ludovic Courtès wrote:

> Is it not hanging during Shepherd service upgrade?

Yes, thank you!  It was hanging during the Shepherd system upgrade due
to an invalid calendar-event specification.  In a service that uses both
#:days-of-month as well as #:days-of-week, I got confused because the
count starts with one in one, and with zero in the other. [1]

Thank you for your kind pointer in another forum! The issue is now
solved.

On this occasion, please allow me to mention for everyone's benefit that
your support level for the Shepherd is very generous---especially when
the complaints involve repeated user errors by the people bothering you.

> If that is the case, (1) that is not preventing upgrade from happening
> since that’s the very last step (it just means you’ll have to reboot),

Yes, but 'reboot' and 'halt' also stop working, which meant that I
issued 'sync' a few times and then, crossing my fingers, pressed the
reset button a few hundreds of a second later.  I wish there were a way
to force a reboot.

> (2) it’s a shepherd-related bug for which perhaps there are clues in
> /var/log/messages?

Thank you for that pointer, too.  I'm still learning about where to look
for error messages, whose destination is not always obvious to me.

Kind regards
Felix

[1] 
https://codeberg.org/lechner/system-config/commit/8639339dbd3ad4c51ceba239bf4aadc56223fb4a

Re: A capture-stdout wrapper procedure in (guix build utils)?

[Development of GNU Guix and the GNU System distribution.]

Hi Fabio,

On Sat, Apr 20 2024, Fabio Natali wrote:

> do you think it might be worth to add it (or a variation thereof) to
> '(guix build utils)'?

I use this [1] which gives the caller access to the exit status and is
also slightly shorter:

(define (command-with-output-to-string/status* command)
  (let* ((input-pipe (apply open-pipe* OPEN_READ command))
 (output (get-string-all input-pipe))
 (exit-val (status:exit-val (close-pipe input-pipe
(values output exit-val)))

It may be better, however, to finally fix Guile's 'system' and 'system*'
to work with 'with-output-to-string'. [2]

Kind regards
Felix

[1] 
https://codeberg.org/lechner/preambled-exec/src/commit/c5c498c3890f22cda070fe35b314f01982ebc885/test/simple-variable.scm#L28-L32
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43364

Re: Fallout from recent nss-certs changes

[Development of GNU Guix and the GNU System distribution.]

Hi,

On Sat, Apr 20 2024, Ian Eure wrote:

> If an operating-system’s packages includes `(specification->package
> "nss-certs")', this causes breakage, because that form selects version
> 3.98, but %base-packages includes 3.88.1, which causes an error on the
> next `guix system reconfigure' due to conflicting package versions in
> the profile.

Why does the unversioned stringy selector (specification->package
"nss-certs") resolve to a version different from the unversioned
variable nss-certs?  Is that a bug?

Kind regards
Felix

P.S. I hoped to use the word "reified" but did not know how it fit in.

Re: Guix bios installation: Grub error: unknown filesystem

[Franz Geffke]

Hi Ada,

I very much appreciate your detailed response.

For a moment I thought my email hadn't made it to this list, both because it 
didn't show up, and the lack of acknowledgment. After a day or so, I filed a bug 
report instead [1] - which produced the expected acknowledgement... Still learning.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866603

> Basically, there is a compatibility issue regarding the ext4 filesystem 
features that GRUB 2.06 supports and the features that `e2fsprogs@1.47.0` 
enables by default when creating your ext4 filesystem.


So this broke on 26th of March, with commit 
ce78f9cb668971954add5473c8549ebb00424f66.


> To fix this, you will need to make sure you create your ext4 filesystem with 
the following features: `mkfs.ext4 /dev/you-partition-here -O 
has_journal,ext_attr,resize_inode,dir_index,filetype,needs_recovery,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize`


I didn't realize mkfs.ext4 would accept these directly, thank you.

Certainly hope the latest version of GRUB will be merged asap, so it doesn't 
affect more users. Not a great experience when the initial install requires an 
undocumented workaround - but then again, it does (still) work on the guix ISO 
from the homepage.


Have a great day!

Best,
Franz

Re: hello from a new commiter

[Janneke Nieuwenhuizen]

Zheng Junjie writes:

Hi Junjie,

> I have been granted commit access.

Yay!

> You might know me, Past few years I fix some error on riscv64, fix some
> cross-compilation, Add plasma-desktop, etc. I'm using this access to
> better improve these.

Welcome and keep up the good work!

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: hello from a new commiter

[宋文武]

Zheng Junjie  writes:

> hello! 
>
> I have been granted commit access.
>
> You might know me, Past few years I fix some error on riscv64, fix some
> cross-compilation, Add plasma-desktop, etc. I'm using this access to
> better improve these.

That's great, thank you for the work and looking forward for future
improvements!

Re: Fallout from recent nss-certs changes

[pelzflorian (Florian Pelz)]

Hello Ian.  My understanding of the nss-certs etc/news.scm item had been
that we should remove (specification->package "nss-certs"), which became
unnecessary and clutters config.scm.  From what you write, this was
actually not intended, but it is still not a bug IMHO.

(I’m not involved with the change, though.)

Regards,
Florian

hello from a new commiter

[Zheng Junjie]

hello! 

I have been granted commit access.

You might know me, Past few years I fix some error on riscv64, fix some
cross-compilation, Add plasma-desktop, etc. I'm using this access to
better improve these.

Here is my account:
https://savannah.gnu.org/users/Z572
https://mastodon.social/@Z572
https://github.com/Z572/
https://gitlab.com/Z572/

email:
zhengjun...@iscas.ac.cn
873216...@qq.com
zhengjun...@yandex.com

Here is my key

fingerprint: "7EBE A494 60CE 5E2C 0875  7FDB 3B5A A993 E1A2 DFF0"

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGHVJjQBEADAhulsJzo70F1CaLPqTyii/VpXKMDTQUAoguc+kHZ22kxZrJkv
fAd8muru6FCKEH1S2341xnt+0MmyL/OmByKgsuSJ9XUilb05JnsAGhSovYjqGrR0
NPHNKEMHzXaIVR3MOwhpHTxxOVzh+AMhTtmc+wZ2QxSsW0tZMTUU/YCOSsWimYwq
N8mztRcmg/qC5HXTnO+hOFRNC+bBc64UN99MS8KSGCtf+piVEVdnOiFiZ/ErUs2a
kW+9bc/uDXes1ZzVrAZMzdf9rq6gFLpTfgMZ/eUi8ykOAKRj+rutzTQ6ExvV1g/D
iM/jwTfZg1SO/rTe/IQqYNFBTxAm4yODOUadrAHVOp3J0qm4HM5l/0px5tb0R8N8
BJKY+6T5yXgEQlT7KgMwcmMsG3IfsTtcsnpK8LwQjjOfNnNpyKVngKV94vaR1jPj
4wq5aVpv92YvrbW4brN7CdVGCBKnwwfGewuC5xW7XiDZMSYdLi0US1/bcVEbjhju
qPsd9KGAYvhgKlARb89WyICdxkyPtBWMuNFqa0tt8EccfRfqz0QDqkVg4Sc/yu5p
6C/XwmZu0CLWNAz6efAZltGfDPAtzAicrgmM31VrnYdyREuVdLEr6tsj+YM5REmw
FONfuVhIeg3LbqUp0pCZqZRAltLodg4uiCIr6zYpTduMN5y7rY8sevW4CQARAQAB
tBhaLTU3MiA8WjU3MkB6NTcyLm9ubGluZT6JAkkEEwEIADMWIQR+vqSUYM5eLAh1
f9s7WqmT4aLf8AUCYdUmNAIbAwMLCQgFFQoJCAsCFgACHgECF4AACgkQO1qpk+Gi
3/CnGxAAhqWLQEzw5FDYECdNgh/i+nH/ibJ7I9e/axmvWGo4cvqfDrqErbNgo7xj
zNIwWzp9jJlu4lC6UxQw/mbkrjkdPktlxMjZRA6hZ0iN2iIXxW3SgDqvo0kX+cGI
3OMLOcUqndGNvp4WIc0tyk+Ghpwac3NwNpX8IxMu+1j7K6gvPDmFGBRgzc5hrq4l
nq7WvHK8yjNKbfmODQXcUlLY1eeX8D1Bl/eb35iPIDCyyc9LxqH+Rmy2Jed4iXDC
fZQPeUmFL+ZqUrS81fzO+6z9T9dMG7jprXMNHfL1O+Kt5mQ/t0vuF23fQhfR/fFI
2Mjj+d13lKrxZCu1fXlPk5Kjpjb9i8STpJloQV0MONwbw98lz/CKMp9zu1co6pHL
8lDW7gce6fPU/zGCLDgr4+GuRrNNFRHZP3gDNbI0q5YTp0gbf/pjkph+fhGIa+H1
izs5KDlUu9BKf9Uj7+I7i3JQ65UCHTboTcGw5bcB4zakJcwW9KpnYyKNPm+FhB2U
fkIVzktGxkJnQ0CcLS1/YCsbxU1mZu19y6lt4DKypQ5rReMkkp3AfVIj6pjHTESj
gnXlzRveOiB9+VYzrMJVt2IDqlxElv4fJ0z1fU3/r8ZrTH1tiuZ1NDIVJ0iLH+hb
yzmDmj0gjezhFSYiq9iARWi4AB/eQx80dcosZNS1lEp+AleXzNK0H1poZW5nIEp1
bmppZSA8ODczMjE2MDcxQHFxLmNvbT6JAkkEEwEIADMWIQR+vqSUYM5eLAh1f9s7
WqmT4aLf8AUCZON60gIbAwMLCQgFFQoJCAsCFgACHgECF4AACgkQO1qpk+Gi3/Ac
4A/+IqTqvGaGEr+9L+/oU9TjMkEzDAqqeB7UU4LC1Wv8ZDa5+2TMCHhGgFmu0TL1
bW9SE7YtUm0kbp26x6neD5m+HPgCvib6x+r+RdhqhR8BM/KTa2j7ULHHquLC8xZk
9SFax9NnStjYp6oTD0EnFEPt197MbZcpmRgyHAraFsA5Od9xUhU4hmMKfeVYMuzW
91ieQEi41J+DPOBYdjcwOvHO90EdXh6mLraM1eViKX8FtUGkUiBOyhbO9OIIBIUo
jZMT1VXw4gHOHfFGHpFwetKKGprfoSOWnjpGrqSpnQiVJnMsFq+/r1unFxuT8k2j
VczFOGvRINx2/Or6eLtr7cSr52gue01Wl39uUFJ8Vge7/PuJm4QQI2Q5TkSqn8Kh
/SqvuOT1GU5KLxNOTeTFBEOtG52UkiZggEQbomMWoCYuzNagLb1XRFnz99PF/Qwu
BMM4Lne8mTFndCIIj2ffyX4Ja+hdR0wk18a5ePzYIVw3bYNsEZ3QvjFukTT9HD4b
nDXp3FTf738FMMJN06oZdYwm5rq5lOjzKshGTpyg6w3S0RTtuTeoNlOmxooGcPMF
LKrDK4gXlWVTrfM8gJpBP1hMNBb7+wNR4Oo6LQoXx3JvgybnIC0gGd8jWgTKz3al
VTnrnyM3RxESxDso7KWFfvlQMYnk+f4MMieapHlEeK6j7P65Ag0EYdUmNAEQALkL
bFjnwSbc3hFbqy+ZoroIk2hvO6MDbtTQ707d6p3ZnkIumcQauipp791e6BLOoZ/7
GZDewRdJWmM4V0imGZUvgdELRMkIdW6BubH2t5Kkek7n7OeCIC4Fxf/hzP5rshJc
Fsp3i0coWajpMuyNcf/bzx5bKY8NG3RBW6ehmi0xfxCbYBCOf1t+GP8ftDwD5FlQ
BbgQPzaQcu9cThH8uQ8TI7/YM/2J566wqrJfgrkxeTCO4t7gZLvhVLJvu3uNmBxa
iVmg+7bxcTmIeua/slEPcXMyYNnw13VQv0VLnSQDhazEyKlrYBou8uQSnrSJVWON
64ssgfkID4fSp0DrJqBJ5iWulmEYHSEVp3iKPj8ElB7d7XjNnZcFIKuFaOIHsIeq
wIoFv2fWLbXAQ+4O3gF0MKwrwXSwpVE0ui+ugSVed5p1Ql4vBmY05aQtVBUd0WLb
KS22dFhFMwTXkVrD7Ai+23Lh1joMPf9PQuJupjHJZEnu1Y/gYc5dOnTXTUJnkv9B
eFwpJMtPXsJLo8CO27tceKxLZpyojxReJcOZXxXy9Oxe0aAAkWDtHhYVpT1AeOC8
O1of1aP5W4jdQkGGJJg69Ztyri4GUfo08VSFKTTfu+1N+N3gmu1hpaJDQoiyhzZl
/52tvQjh9LvW2toEotNS+OnupgS47ur9+BrMmfMHABEBAAGJAjYEGAEIACAWIQR+
vqSUYM5eLAh1f9s7WqmT4aLf8AUCYdUmNAIbDAAKCRA7WqmT4aLf8E8YEACOx9M7
STsDp5S06GNH+2neOAqWDAkKuz+Qp7B045h94JLzK8a1VT1mg6dTkWKqaVW2932N
o8xVJGiw7atra9exy6mrjLR6RYFLan4WO0fS99SUyAG1dCSSkLkXUGg7Zvjs1n5g
4cHtlAxApUirVPyUC0UAwCy3evOH7H8/WqEx6/+QsvTKEQMKxCV3RWcPR6UAvY5r
8hBHyHUBq7fZLIEOg1vWqAhV+K+wTxEycO1qJal/RyUE5PPzeWULLtH/nvmkFZG1
Od8fWghe0KVhsL8Dk9DyNGeqo0mb5rvXRhKIwEqyDm8Pijl0zRXJGdjOzV6hpgP5
Wp/+FcqYrrJZOQucOpOpuU6AbQ9eJaQIE/Q0B3QEsVIs6UMv6+VAVNyWXcUiIAFd
trEZmKkaULEaQ0Mfp1+M8gzrF33nUJK3IYzLyuZWn7sb+RxGblwSZqJ384nzFfce
oztKmA9IGcLTOTzNa02aSz7FnB3toMQfXcTpBS5WvvMKUgQpwwwmwkFiXX6eN/Sl
uw3efkEG0hFMi7CMqFpwR4+7CN7Juo0MyiZdQmfWFKysliRDOdCpLWEZvZlX1wkv
M/WKtO6hNgiravkPzllh8ag1DzPw31S3HhqLUHCOk1/JPMk2InGvQn6jlznVvI3I
yhZIsifB12dtWFIcPTEynfb7XLq7nVr6Ni4FUA==
=zD7D
-END PGP PUBLIC KEY BLOCK-


signature.asc
Description: PGP signature

Re: Guix bios installation: Grub error: unknown filesystem

[Ada Stevenson]

Hi Franz,

On 4/19/24 2:24 PM, Franz Geffke wrote:

I'm having trouble installing guix in qemu, using a "fresh" guix ISO.

```
building 
/gnu/store/byjlc85abyjc3fjj9z982677skmda7ib-module-import-compiled.drv...
building 
/gnu/store/psw8xn9qpsjjnrqmjrfv0v3jj9fphq5m-module-import-compiled.drv...
building 
/gnu/store/a1zcrrcdwhb4wb2g4r0ph8mqclq7f5xn-install-bootloader.scm.drv...
guix system: error: 
'/gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install 
--no-floppy --target=i386-pc --boot-directory /mnt/boot /dev/sda' exited with 
status 1; output follows:

   Installing for i386-pc platform.
   /gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install: 
error: unknown filesystem.
```

Here's what I've tried so far:
1. The ISO from 2022 
https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso: 
Success
2. Generated a new ISO today: Failure

These are the channels, on the booted ISO:

```
guix describe
   guix 65e8472
 repository URL: https://git.savannah.gnu.org/git/guix.git
 branch: master
 commit: 65e8472a4b6fc6f66871ba0dad518b7d4c63595e
```

Steps I used to install (1) and (2):

```
parted -s /dev/sda -- mklabel msdos mkpart primary ext4 1MiB 100%
parted /dev/sda set 1 boot on
mkfs.ext4 -L my-root /dev/sda1
mount LABEL=my-root /mnt
cp /etc/configuration/lightweight-desktop.scm /mnt/etc/config.scm
# adjust disk, bootloader
herd start cow-store /mnt
guix system init /mnt/etc/config.scm /mnt
```

Findings:

I didn't really dig too deeply yet; Only noticed that this command produces a 
different result, depending on whether the install succeeds, or not `grub-probe 
--target=fs --device /dev/sda`

- Success: `ext2`
- Failure: `grub-probe: error: unknown filesystem.`

I also tried using GPT instead of MBR, but it makes no difference.



I've encountered this problem too, and managed to solve it. I'm 85% sure 
you're experiencing the same problem as me, and I've been meaning to 
document it somewhere - its a super obtuse error and it is a showstopper 
when it comes to installing guix.


Basically, there is a compatibility issue regarding the ext4 filesystem 
features that GRUB 2.06 supports and the features that 
`e2fsprogs@1.47.0` enables by default when creating your ext4 
filesystem. When these features are enabled, it changes the structure of 
the filesystem enough that GRUB can't recognise it properly and it fails.


To fix this, you will need to make sure you create your ext4 filesystem 
with the following features:
`mkfs.ext4 /dev/you-partition-here -O 
has_journal,ext_attr,resize_inode,dir_index,filetype,needs_recovery,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize`


These are the features that worked for me. I had to do a lot of trial 
and error, and I used `tune2fs -l` to see what features weren't 
supported. The ones I can remember are the metadata_csum features, and 
some other ones (they showed up as FEATURE_X when running `tune2fs` on 
my Guix installation image, so I used a Gparted Live CD to get rid of 
the features that weren't recognised by tune2fs).


This should allow grub to recognise your filesystem during the 
installation process. I think using a later version of grub would fix 
this, but that hasn't happened yet. I think there's a patch to upgrade 
it in `core-updates` somewhere, but I'm not sure.


Anyway, hope this helps!

Warmly,
Ada

Re: No default OpenJDK version?

[Julien Lepiller]

I think the first step would be to target openjdk 9, since it already 
introduces quite a lot of changes compared to java 8. To do it, I would suggest 
to change the default jdk in the ant-build-system and maven-build-system, and 
see what is broken, if it can simply be updated without breaking dependents, or 
if it (and its dependencies) needs to be built with an older jdk.

Some packages are bootstrap packages that are quite old and will never support 
a newer jdk. For some of them, we can simply specify a source/target level (not 
sure it's supported by the build-system yet), but I remember trying and a few 
need java 5, which is no longer a supported level.

I have already added support for java modules in the ant-build-system, and I 
just pushed a few updates to some packages that could not previously be built 
with java 9.

Le 20 avril 2024 19:19:37 GMT+02:00, Markku Korkeala  a 
écrit :
>On Tue, Apr 16, 2024 at 10:37:30PM +0200, Julien Lepiller wrote:
>> Currently, most java packages use the implicit jdk from the build system 
>> (ant- or maven-build-system), which is… icedtea@8. We still have quite a lot 
>> of old packages that don't build with openjdk9, so I'm not sure when we can 
>> update the default jdk…
>
>Hi,
>
>is there effort to update the default jdk at some point? I could help with
>it. I'm not familiar with the guix java build systems, but have long
>experience as a Java developer. I also maintain few java packages in Fedora
>and saw the transition to to jdk11 [1], jdk17 [2] and now to jdk21 [3]. The
>pages have documented common issues and workarounds, which might help.
>
>[1]: https://fedoraproject.org/wiki/Changes/Java11
>[2]: https://fedoraproject.org/wiki/Changes/Java17
>[3]: https://fedoraproject.org/wiki/Changes/Java21
>
>Best wishes,
>Markku
>
>> Le 16 avril 2024 22:25:33 GMT+02:00, Vagrant Cascadian 
>>  a écrit :
>> >When recently taking a look at diffoscope, I was reminded that there is
>> >effectively no default openjdk version, you have to pick a specific
>> >version for each package definition...
>> >
>> >At some time in diffoscope's history, that was openjdk@12.
>> >
>> >But there are quite a few versions to choose from:
>> >
>> >  guix package -A openjdk | sort -V
>> >  openjdk 9.181   out,jdk,doc gnu/packages/java.scm:869:2
>> >  openjdk 10.46   out,jdk,doc gnu/packages/java.scm:1140:2
>> >  openjdk 11.0.22 out,jdk,doc gnu/packages/java.scm:1218:2
>> >  openjdk 12.33   out,jdk,doc gnu/packages/java.scm:1536:2
>> >  openjdk 13.0.14 out,jdk,doc gnu/packages/java.scm:1576:2
>> >  openjdk 14.0.2  out,jdk,doc gnu/packages/java.scm:1583:2
>> >  openjdk 15.0.10 out,jdk,doc gnu/packages/java.scm:1598:2
>> >  openjdk 16.0.2  out,jdk,doc gnu/packages/java.scm:1617:2
>> >  openjdk 17.0.10 out,jdk,doc gnu/packages/java.scm:1625:2
>> >  openjdk 18.0.2.1out,jdk,doc gnu/packages/java.scm:1642:2
>> >  openjdk 19.0.2  out,jdk,doc gnu/packages/java.scm:1646:2
>> >  openjdk 20.0.2  out,jdk,doc gnu/packages/java.scm:1663:2
>> >  openjdk 21.0.2  out,jdk,doc gnu/packages/java.scm:1667:2
>> >
>> >Some packages may only work with a specific era of openjdk, but I
>> >suspect many of the packages in guix just picked whatever version
>> >happened to be present when it was added to guix.
>> >
>> >Which makes it hard to know when to update the openjdk dependency...
>> >
>> >In the diffoscope case, it seems to have work fine with openjdk@21, with
>> >the only result being that some openjdk-version-specific tests pass and
>> >some are skipped as a one-for-one trade compared to the old openjdk@12.
>> >
>> >Alternately, I would be tempted to switch to openjdk@17, which is the
>> >current default in Debian, so has a little more testing behind it...
>> >
>> >Though there is a bit of a perverse incentive to stick with the oldest
>> >version that still works, due to openjdk having a very long bootstrap
>> >chain of itself...
>> >
>> >And then the question gets to be of diffoscope's dependencies, what
>> >versions of openjdk do they pull in (notably enjarify, which uses
>> >openjdk@12, although that also seems to work ok with openjdk@21)?
>> >
>> >
>> >Would it make sense to have an openjdk "default" version, so packages
>> >could instead depend on that, and only need to specify a version if
>> >needed for some particular reason? Or is compatibility across openjdk
>> >versions troublesome enough that it really always needs to be handled on
>> >a case-by-case basis?
>> >
>> >
>> >live well,
>> >  vagrant
>> 

Re: Welcome to Zheng (z572) as a new committer!

[Zhu Zihao]

Congratulations!

Maxim Cournoyer  writes:

> Hi comrades,
>
> Zheng has joined the committers to help improving cross-compilation,
> riscv64, and KDE, among others.
>
> Let's wish them a warm welcome!
>
> Happy hacking!


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

A capture-stdout wrapper procedure in (guix build utils)?

[Fabio Natali]

Hallo,

I noticed this capture-stdout wrapper procedure while reviewing Tomas'
patch 68289⁰:

,
| (define (capture-stdout . prog+args)
|   (let* ((port (apply open-pipe* OPEN_READ prog+args))
|  (data (get-string-all port)))
| (if (= 0 (status:exit-val (close-pipe port)))
| (string-trim-right data #\newline)
| (error "command failed"
`

Since this seems to be a somewhat general and useful pattern, do you
think it might be worth to add it (or a variation thereof) to '(guix
build utils)'?

Thanks, best wishes, Fabio.


⁰ https://issues.guix.gnu.org/issue/68289/#0-lineno93


-- 
Fabio Natali
https://fabionatali.com

Re: Status of ‘core-updates’

[Maxim Cournoyer]

Hi Christopher,

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> What’s the status of ‘core-updates’?  What are the areas where help is
>> needed?
>>
>> I know a lot has happened since the last update¹, which is roughly when
>> I dropped the ball due to other commitments, but I’m not sure where we
>> are now.
>
> I haven't really been following core-updates, but I have had a look
> since there's a request to merge it now [1].
>
> I'm really concerned by the commits on the branch though, assuming I'm
> using Git right, there are 6351 commits on the branch:
>
>   git log --pretty=oneline core-updates ^master | wc -l
>
> Somehow, I think there's been a couple of pushes of commits to
> core-updates that have partially duplicated lots of commits from master,
> I put some more details in:
>
>   https://issues.guix.gnu.org/70456#3
>
> I think keeping the Git commit history clean and representative is
> really important, so to me at least this means core-updates can't be
> merged to master in it's current form, even if the changes overall from
> these 6351 commits are reasonable.
>
> I'm really not sure how to move forward though, I had a go at trying to
> rebuild the branch without introducing the thousands of duplicate
> commits and that produced a branch with 765 commits over master, which
> still seems a lot, but a big improvement over 6351:
>
>   https://git.cbaines.net/guix/log/?h=chris-core-updates-no-duplicates-attempt
>
> That was really hard going though, as there's plenty of merge conflicts
> along the way, and I'm pretty sure I solved some of them
> incorrectly. The resulting branch also differs from core-updates.

I also think Git commit history is important, but in this case I weigh
the value of removing ~5000 duplicated rust commits against the risks of
resolving merge conflicts wrong or forgetting commits upon attempting to
recreate the branch from scratch lower than the benefit.

> Maybe someone with more time, care and attention could do a better job,
> but it might be more worthwhile just starting fresh and rather than
> trying to produce a like for like branch just without the thousands of
> duplicate commits, effectively manually rebase the branch (without the
> duplicate commits) on master and try to get the commits in to a usable
> state.

Given the little attention core-updates is currently receiving, I doubt
someone is willing to put the effort to recreate the branch from scratch
to clean its git history; at least speaking for myself I'd rather spend
the little hack time I have to work on it toward getting it finalized.

I believe how these duplicates came to exist was probably two separate
master -> core-updates merge commits, with one of them ending up being
rebased on top of the other, probably so that it could be pushed.
Perhaps we could capture in our contribution guidelines that rebasing a
merge commit should never be done to keep the history clean, and that in
a situation where:

1. a merge has been prepared locally (with conflicts resolved and all)
2. a new commit has appeared on the remote branch

the solution should be to merge the remote branch into the local one
instead of rebasing the local one on the remote one (as is usually
done).  Disclaimer: I haven't actually tried this suggested approach,
which should be done before documenting it, if there's a consensus to do
so.

In other words, I suggest we document what *not* to do to avoid
repeating the same mistake in the future, and move on.

-- 
Thanks,
Maxim

Re: Concerns/questions around Software Heritage Archive

[Ian Eure]

Hello,

I’m following up on this since discussion since it’s been a month 
and I haven’t heard any updates.


Summarizing the situation:

- SHF has an opaque, difficult, and undocumented process for 
 handling name changes.  I’s like to stress again that this is 
 *not* strictly a transgender issue (though it likely affects 
 them more, or in worse/different ways) -- it is a human respect 
 issue.  Many, many more cisgender people change their name than 
 transgender people.


- SHF gave their archive to HuggingFace, an "AI" company which is 
 generating derived works with no attribution or provenance, in 
 ways which violate the both licenses of the projects used to 
 train their model, and the SHF principles for LLMs.


- HuggingFace wasn’t respecting requests to opt-out of their 
 model.



On the first point, it sounds like SHF has made concrete progress 
to improve[1], which is very good to hear.  If SHF continues on 
this course, I think the concern is resolved.


On the third point, HuggingFace has begun honoring opt-out 
requests, but is still very far behind.  Also, they don’t remove 
code from the older versions of their model -- it remains there 
forever.  This is progress, but still, not great.


On the second point, I have not seen any public statements 
indicating that either SHF or HuggingFace even acknowledges the 
problem.  SHF’s most recent newsletter[2], published in April 2024 
(after these concerns came to light), continues to tout that 
StarCoder2 is "the first AI model aligned with our principles," 
which appears to be false.  StarCoder2 includes both licensed and 
unlicensed code, and HuggingFace’s own StarChat2 playground 
produces works derivative of this code, with no attribution or 
licensing information.  There is also no statement or position on 
the SHF news blog.  Nor hsa HuggingFace either fixed their tools, 
or made a statement.  This is still very much a live concern.


I have a few questions:

- Has Guix reached out to SHF to express these concerns / get a 
 response?
- Whether a public or private response, what would Guix consider 
 to be an acceptable response?  An unacceptable respoinse?

- How long is Guix willing to wait for a response?

Thanks,

 — Ian

[1]: 
https://cohost.org/arborelia/post/5273879-they-are-fixing-some
[2]: 
https://www.softwareheritage.org/wp-content/uploads/2024/04/Software-Heritage-2024-Vision-Milestones-Newsletter.pdf


Ian Eure  writes:


Hi Guixy people,

I’d never heard of SWH before I started hacking on Guix last 
fall, and
it struck me as rather a good idea.  However, I’ve seen some 
things

lately which have soured me on them.

They appear to be using the archive to build LLMs:
https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/

I was also distressed to see how poorly they treated a developer 
who

wished to update their name:
https://cohost.org/arborelia/post/4968198-the-software-heritag
https://cohost.org/arborelia/post/5052044-the-software-heritag

GPL’d software I’ve created has been packaged for Guix, which I 
assume
means it’s been included in SWH.  While I’m dealing with their 
(IMO:
unethical) opt-out process, I likely also need to stop new 
copies from

being uploaded again in the future.

Is there a way to indicate, in a Guix package, that it should 
*never*

be included in SWH?

Is there a way to tell Guix to never download source from SWH?

I want absolutely nothing to do with them.

Thanks,

 — Ian

Fallout from recent nss-certs changes

[Ian Eure]

Some recent nss-certs changes have a negative side effects which 
needs to be fixed.


A patch of mine was pushed recently (commit 
0920693381d9f6b7923e69fe00be5de8621ddb6f), which adds nss-certs 
3.98 to (gnu packages certs), under the nss-certs-3.98 variable.


Then, commit fdfd7667c66cf9ce746330f39bcd366e124460e1 was pushed, 
which adds nss-certs to %base-packages-networking.  This 
references the nss-certs variable, which is version 3.88.1.


If an operating-system’s packages includes 
`(specification->package "nss-certs")', this causes breakage, 
because that form selects version 3.98, but %base-packages 
includes 3.88.1, which causes an error on the next `guix system 
reconfigure' due to conflicting package versions in the profile. 
Prior to commit 65e8472a4b6fc6f66871ba0dad518b7d4c63595e, the 
graphical installer would ask users if they wanted to install 
nss-certs, and put this form into the operating-system’s packages, 
so there are likely many users affected -- it bit me, and I’ve 
seen a couple in IRC as well.


I think the options to fix this are:

1. Removing (specification->package "nss-certs") from one’s 
operating-system.

2. Grafting nss-certs 3.98 onto nss-certs 3.88.1.
3. Replacing nss-certs 3.88.1 with 3.98.

The most expedient option is 1, as it can be applied by users -- 
but there’s probably not a good way to communicate that this needs 
to happen.


There was some talk in IRC about grafting nss/nss-certs, but it 
looks like this didn’t happen.  An upgrade is the best path, but 
would probably need to happen in core-updates, since this rebuilds 
a large number of packages.


Thoughts on this?

Thanks,

 — Ian

Re: rust-team branch merged

[Jason Conroy]

Efraim Flashner  writes:

Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 
then
you'd have both rand-0.*.crate files in the registry but only 
one of
them would be listed in share/cargo/registry/index/ra/nd/rand. I 
need to
adjust the generation of that file to combine multiple sources 
if they
exist, and sort them (I'm not sure it's necessary, but wouldn't 
be
surprised if we hit undefined behaviour if they were listed 
multiple

times or out of order).


Hi Efraim,

I'm currently investigating this limitation of your proposed 
patch.


Did you have a strategy in mind for how to fix it? I see that the 
index files are currently generated during a phase of 
cargo-build-system, rather than as a profile hook. So, to build an 
index that properly reflects the contents of a profile, it would 
seem that the two simplest options are: a) keep your existing 
index-generation logic during the build, and merge these 
per-package index files when building the profile; or b) move your 
patch's index-generating code out of the build phase and into a 
profile hook, so that we build each index file in a single pass 
(for all versions of a package) rather than merging the files from 
each package output.


On the surface option (b) seems cleaner, but maybe you had a 
reason for generating the index contents during the build?


Jason

Guix bios installation: Grub error: unknown filesystem

[Franz Geffke]

I'm having trouble installing guix in qemu, using a "fresh" guix ISO.

```
building 
/gnu/store/byjlc85abyjc3fjj9z982677skmda7ib-module-import-compiled.drv...
building 
/gnu/store/psw8xn9qpsjjnrqmjrfv0v3jj9fphq5m-module-import-compiled.drv...
building 
/gnu/store/a1zcrrcdwhb4wb2g4r0ph8mqclq7f5xn-install-bootloader.scm.drv...
guix system: error: 
'/gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install 
--no-floppy --target=i386-pc --boot-directory /mnt/boot /dev/sda' exited with 
status 1; output follows:

  Installing for i386-pc platform.
  /gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install: 
error: unknown filesystem.
```

Here's what I've tried so far:
1. The ISO from 2022 
https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso: 
Success
2. Generated a new ISO today: Failure

These are the channels, on the booted ISO:

```
guix describe
  guix 65e8472
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 65e8472a4b6fc6f66871ba0dad518b7d4c63595e
```

Steps I used to install (1) and (2):

```
parted -s /dev/sda -- mklabel msdos mkpart primary ext4 1MiB 100%
parted /dev/sda set 1 boot on
mkfs.ext4 -L my-root /dev/sda1
mount LABEL=my-root /mnt
cp /etc/configuration/lightweight-desktop.scm /mnt/etc/config.scm 
# adjust disk, bootloader
herd start cow-store /mnt
guix system init /mnt/etc/config.scm /mnt
```

Findings:

I didn't really dig too deeply yet; Only noticed that this command produces a 
different result, depending on whether the install succeeds, or not `grub-probe 
--target=fs --device /dev/sda`

- Success: `ext2` 
- Failure: `grub-probe: error: unknown filesystem.`

I also tried using GPT instead of MBR, but it makes no difference.

Re: No default OpenJDK version?

[Markku Korkeala]

On Tue, Apr 16, 2024 at 10:37:30PM +0200, Julien Lepiller wrote:
> Currently, most java packages use the implicit jdk from the build system 
> (ant- or maven-build-system), which is… icedtea@8. We still have quite a lot 
> of old packages that don't build with openjdk9, so I'm not sure when we can 
> update the default jdk…

Hi,

is there effort to update the default jdk at some point? I could help with
it. I'm not familiar with the guix java build systems, but have long
experience as a Java developer. I also maintain few java packages in Fedora
and saw the transition to to jdk11 [1], jdk17 [2] and now to jdk21 [3]. The
pages have documented common issues and workarounds, which might help.

[1]: https://fedoraproject.org/wiki/Changes/Java11
[2]: https://fedoraproject.org/wiki/Changes/Java17
[3]: https://fedoraproject.org/wiki/Changes/Java21

Best wishes,
Markku

> Le 16 avril 2024 22:25:33 GMT+02:00, Vagrant Cascadian 
>  a écrit :
> >When recently taking a look at diffoscope, I was reminded that there is
> >effectively no default openjdk version, you have to pick a specific
> >version for each package definition...
> >
> >At some time in diffoscope's history, that was openjdk@12.
> >
> >But there are quite a few versions to choose from:
> >
> >  guix package -A openjdk | sort -V
> >  openjdk 9.181   out,jdk,doc gnu/packages/java.scm:869:2
> >  openjdk 10.46   out,jdk,doc gnu/packages/java.scm:1140:2
> >  openjdk 11.0.22 out,jdk,doc gnu/packages/java.scm:1218:2
> >  openjdk 12.33   out,jdk,doc gnu/packages/java.scm:1536:2
> >  openjdk 13.0.14 out,jdk,doc gnu/packages/java.scm:1576:2
> >  openjdk 14.0.2  out,jdk,doc gnu/packages/java.scm:1583:2
> >  openjdk 15.0.10 out,jdk,doc gnu/packages/java.scm:1598:2
> >  openjdk 16.0.2  out,jdk,doc gnu/packages/java.scm:1617:2
> >  openjdk 17.0.10 out,jdk,doc gnu/packages/java.scm:1625:2
> >  openjdk 18.0.2.1out,jdk,doc gnu/packages/java.scm:1642:2
> >  openjdk 19.0.2  out,jdk,doc gnu/packages/java.scm:1646:2
> >  openjdk 20.0.2  out,jdk,doc gnu/packages/java.scm:1663:2
> >  openjdk 21.0.2  out,jdk,doc gnu/packages/java.scm:1667:2
> >
> >Some packages may only work with a specific era of openjdk, but I
> >suspect many of the packages in guix just picked whatever version
> >happened to be present when it was added to guix.
> >
> >Which makes it hard to know when to update the openjdk dependency...
> >
> >In the diffoscope case, it seems to have work fine with openjdk@21, with
> >the only result being that some openjdk-version-specific tests pass and
> >some are skipped as a one-for-one trade compared to the old openjdk@12.
> >
> >Alternately, I would be tempted to switch to openjdk@17, which is the
> >current default in Debian, so has a little more testing behind it...
> >
> >Though there is a bit of a perverse incentive to stick with the oldest
> >version that still works, due to openjdk having a very long bootstrap
> >chain of itself...
> >
> >And then the question gets to be of diffoscope's dependencies, what
> >versions of openjdk do they pull in (notably enjarify, which uses
> >openjdk@12, although that also seems to work ok with openjdk@21)?
> >
> >
> >Would it make sense to have an openjdk "default" version, so packages
> >could instead depend on that, and only need to specify a version if
> >needed for some particular reason? Or is compatibility across openjdk
> >versions troublesome enough that it really always needs to be handled on
> >a case-by-case basis?
> >
> >
> >live well,
> >  vagrant
> 

Welcome to Zheng (z572) as a new committer!

[Maxim Cournoyer]

Hi comrades,

Zheng has joined the committers to help improving cross-compilation,
riscv64, and KDE, among others.

Let's wish them a warm welcome!

Happy hacking!

-- 
Thanks,
Maxim

Re: Status of ‘core-updates’

[Christopher Baines]

Ludovic Courtès  writes:

> What’s the status of ‘core-updates’?  What are the areas where help is
> needed?
>
> I know a lot has happened since the last update¹, which is roughly when
> I dropped the ball due to other commitments, but I’m not sure where we
> are now.

I haven't really been following core-updates, but I have had a look
since there's a request to merge it now [1].

I'm really concerned by the commits on the branch though, assuming I'm
using Git right, there are 6351 commits on the branch:

  git log --pretty=oneline core-updates ^master | wc -l

Somehow, I think there's been a couple of pushes of commits to
core-updates that have partially duplicated lots of commits from master,
I put some more details in:

  https://issues.guix.gnu.org/70456#3

I think keeping the Git commit history clean and representative is
really important, so to me at least this means core-updates can't be
merged to master in it's current form, even if the changes overall from
these 6351 commits are reasonable.

I'm really not sure how to move forward though, I had a go at trying to
rebuild the branch without introducing the thousands of duplicate
commits and that produced a branch with 765 commits over master, which
still seems a lot, but a big improvement over 6351:

  https://git.cbaines.net/guix/log/?h=chris-core-updates-no-duplicates-attempt

That was really hard going though, as there's plenty of merge conflicts
along the way, and I'm pretty sure I solved some of them
incorrectly. The resulting branch also differs from core-updates.

Maybe someone with more time, care and attention could do a better job,
but it might be more worthwhile just starting fresh and rather than
trying to produce a like for like branch just without the thousands of
duplicate commits, effectively manually rebase the branch (without the
duplicate commits) on master and try to get the commits in to a usable
state.

Any ideas?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Should we include nss-certs out of the box?

[Fabio Natali]

On 2024-04-19, 11:25 -0400, Maxim Cournoyer  wrote:
> Could you please take a look at
> '65e8472a4b6fc6f66871ba0dad518b7d4c63595e', which I hope didn't leave
> no longer useful 'nss-certs' doc/examples behind ?

Hi Maxim, absolutely, I should be able to give a look today or
tomorrow. I'll send an update here.

Thanks, best wishes, Fabio.

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[Matt]

  On Fri, 19 Apr 2024 22:56:13 +0200  pelzflorian (Florian Pelz)  wrote --- 
 > Hello Matt, pushed as 86fb0e039bf30cf85e2066401f9a384427c47ea8.
 > 
 > I was bold enough to retain the xref change in (Setting Up the Daemon)
 > prompted by Ludo, because starting a sentence with @xref is recommended
 > in the Texinfo manual and its examples, while @pxref at the start of a
 > phrase is not preferrable, according to the “info "(texinfo)@pxref"”.
 > 
 > Again, Texinfo cross-references are complicated.
 > 
 > (In the German translations, I always wrote only @ref, but only because
 > @xref is not properly translated; Emacs in particular is not
 > internationalized at all.)
 
Sounds good, thank you!

Re: Creating a documentation team?

[Matt]

  On Fri, 19 Apr 2024 16:09:53 +0200  Ludovic Courtès  wrote --- 
 > Hi Florian and all,
 > 
 > I figure you’ve been doing a lot of review and writing of the manual.
 > Should we create a documentation team, of which you could be a honorary
 > member?  :-)
 > 
 > I feel like ensuring doc consistency, be it regarding the content,
 > terminology, typography, or use of markup, is a job in its own that
 > could be best reviewed by people familiar with and interested in those
 > issues.
 
I'm in favor of this and would enjoy continuing to help with the docs.

Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file

[Stefan Monnier]

> The systemd documentation contains code to implement sd_notify without
> using libsystemd at
> https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes
>
> Lennart Poettering said on Mastodon that the notify protocol is stable
> and is independent of libsystemd.
>
> https://mastodon.social/@pid_eins/112202687764571433
> https://mastodon.social/@pid_eins/112202696589971319

Looks quite promising.


Stefan

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Hello Matt, pushed as 86fb0e039bf30cf85e2066401f9a384427c47ea8.

I was bold enough to retain the xref change in (Setting Up the Daemon)
prompted by Ludo, because starting a sentence with @xref is recommended
in the Texinfo manual and its examples, while @pxref at the start of a
phrase is not preferrable, according to the “info "(texinfo)@pxref"”.

Again, Texinfo cross-references are complicated.

(In the German translations, I always wrote only @ref, but only because
@xref is not properly translated; Emacs in particular is not
internationalized at all.)

Regards,
Florian

Re: Sustainability fund application ongoing

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> It was pointed to us that the "Free and Open Source Software
> Sustainability Fund" [0] is currently receiving applications.  The fund
> aim to sponsors free software projects for their
> maintenance/organisational activities.

Nice!  You forgot the link but I guess it’s
.
Deadline is May 17th.

> I'm tempted to apply myself, but I thought I'd share it here: the more
> submissions they get the more likely Guix is to receive support.

Agreed, it’s great to have people apply there (even better if it works,
of course).

Maybe we should provide a contact point for people who want to
coordinate when applying for Guix-related funding, to avoid overlapping
or competing applications?

Ludo’.

Re: Distributed GNU Shepherd NLNet Grant

[Ludovic Courtès]

Hey Juliana,

Juliana Sims  skribis:

> As some of you already know, in December I submitted an application
> for an NLNet grant to fund porting our beloved Shepherd to Spritely
> Goblins [1]. This work would represent a radical evolution in the
> capabilities of not just Guix's system layer, but of GNU/Linux system
> layers in general; and would also be the biggest real-world test to
> date of the Goblins library and its capabilities (pun not
> intended). Materially, it would allow Shepherd dæmons running on
> different machines to securely communicate and interact with each
> other, going so far as to control one machine's dæmons from another
> machine.
>
> I am happy to announce that this grant application was approved! [2]

Yay, congrats!! 

This is exciting; I’m glad Ricardo has already offered another nice use
case.  :-)

It’s great to have you on board, and it’s great to have you be the first
person bridging the inspiring work happening in Goblins and the cool
stuff in Shepherd and Guix.

Cheers,
Ludo’.

Re: System can no longer be reconfigured

[Ludovic Courtès]

Hi,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  skribis:

> I can no longer reconfigure a system with any of these methods:
>
> 1. "guix deploy" which I use almost exclusively
> 2. "guix system reconfigure" after a recent pull
> 3. "./pre-inst-env guix system reconfigure" with a recent Git checkout.
>
> Guix hangs during the system activation step.  Any ideas?

Is it not hanging during Shepherd service upgrade?  (I think you
mentioned that elsewhere.)

If that is the case, (1) that is not preventing upgrade from happening
since that’s the very last step (it just means you’ll have to reboot),
and (2) it’s a shepherd-related bug for which perhaps there are clues in
/var/log/messages?

HTH!

Ludo’.

Re: No public interface for shepherd-package

[Ludovic Courtès]

Hi Felix,

Felix Lechner  skribis:

> Following podiki's and jab's kind advice on IRC yesterday, I recompiled
> Guix locally.  I also provided all channels locally via -L.
>
> That 'system reconfigure' failed too, however.  The error message was:
>
> Module named (shepherd-package) has no public interface.

Is ‘shepherd’ among your channels?

I do something similar to what Attila described, and I have:

--8<---cut here---start->8---
$ guix describe
Generation 299  Apr 08 2024 00:55:02(current)
  shepherd d8d96fc
repository URL: https://git.savannah.gnu.org/git/shepherd.git
branch: devel
commit: d8d96fc28c49c624323b2f9f5cb01c4fc18a4afd
  guile db7efa5
repository URL: https://git.savannah.gnu.org/git/guile.git
branch: main
commit: db7efa5d204b2e46ce9eb82f417d8c12d394858d
  guix 49f82fc
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 49f82fca4130ffcfb16aa0cf89750ab56fb99ad7
--8<---cut here---end--->8---

Ludo’.