GNU bug report logs - #77570
Build failures on core packages following daemon changes

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ludovic Courtès <ludo <at> chbouib.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#77548: closed (multiple packages fail check phases due to
 read-only file system root)
Date: Tue, 15 Apr 2025 10:09:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 15 Apr 2025 12:07:44 +0200
with message-id <87cyddhh5b.fsf <at> chbouib.org>
and subject line Re: bug#77570: Build failures on core packages following daemon changes
has caused the debbugs.gnu.org bug report #77570,
regarding multiple packages fail check phases due to read-only file system root
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
77570: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77570
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: keinflue <keinflue <at> posteo.net>
To: bug-guix <at> gnu.org
Cc: Ludo <ludo <at> gnu.org>
Subject: multiple packages fail check phases due to read-only file system root
Date: Sat, 05 Apr 2025 09:41:37 +0000

Hi everyone,

probably since commit 40f69b586a several packages including shepherd, go 
(bootstrap), ruby and scons fail their check phases.

They all fail with EROFS "read-only file system" errors. The pattern 
seems to be that these packages attempt to remove non-existent files 
under /, e.g. /does-not-exist for the pid-file.sh test case in shepherd. 
They expect the unlink/unlinkat syscall to fail with ENOENT, but the 
linux kernel produces EROFS if the file system is read-only, even if the 
file doesn't exist, and glibc does not modify this behavior for the C 
library functions.

On one hand this is probably not POSIX-conforming behavior of 
linux/glibc and there was a patch rectifying this in version 3.2 (commit 
e6bc45d65d) of the kernel, but that regressed with 3.6 (commit 
c30dabfe5d) from what I can tell.

On the the other hand, I do not think that attempting to delete 
arbitrary files on the file system root with the assumption that it will 
fail in specific ways is a good idea either and that the files do not 
actually exist is not a good idea either.

Not sure what the correct approach to fixing this would be.

[Message part 3 (message/rfc822, inline)]

From: Ludovic Courtès <ludo <at> chbouib.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: keinflue <keinflue <at> posteo.net>, Ada Stevenson <adanskana <at> gmail.com>,
 Reepca Russelstein <reepca <at> russelstein.xyz>, 77570-done <at> debbugs.gnu.org
Subject: Re: bug#77570: Build failures on core packages following daemon
 changes
Date: Tue, 15 Apr 2025 12:07:44 +0200

Commit 3bedd82ac3c7c69e321d79bed6c77e7e055a2063 updated the ‘guix’
package, fixing this particular issue.

Please report any other problems you find.  It’s particularly valuable
if you’re building most things locally.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.