Re: Release on April 18th?

[Chris Marusich]

Hi,

Vincent Legoll <vincent.legoll@gmail.com> writes:

> I rebuilt guix on core-updates with gcc-8 succesfully
> I'll now try the same above wip-ppc64le.

Awesome!  Thank you for doing this.  I'm sure there will be some bumps,
and the sooner we can fix them, the easier it will be to integrate
later.

I'm still working on getting you access to ppc64le hardware or a VM.

Andreas Enge <andreas@enge.fr> writes:

> Am Fri, Mar 12, 2021 at 12:33:18AM -0800 schrieb Chris Marusich:
>> The proc man page has this to say about column 7:
>>   (7) optional fields: zero or more fields of the form "tag[:value]"
>
> And it goes on like this:
> (8)  separator: the end of the optional fields is marked
>                    by a single hyphen.
>
> So it looks like it is enough to search for a hyphen surrounded by spaces.
> The hyphen is apparently there also when there is no optional field (7),
> as can be seen from your examples and also my own system, where both occur
> in parallel:
> 34 26 253:0 /gnu/store /gnu/store ro,noatime - ext4 /dev/mapper/cryptroot rw
> 51 26 253:0 /var/lib/docker /var/lib/docker rw,relatime shared:1 - ext4 
> /dev/mapper/cryptroot rw
>
> Alternatively, one can also count from the back to get the fields labelled
> (9) to (11) (which may be (8) to (10) in case there are no optional fields).
> (I was momentarily confused by "(12) super option*s*"; but these are
> apparently separated by commas and not whitespace.)

That's true.  How about the following patch?  It fixes the issue for me
on my systems, and I manually tried out the new match pattern with some
lines from Leo's output, and it seems to behave correctly.  If nobody
has concerns, I'd like to apply it to master directly, since the tests
are already failing there on some systems, like mine.  Here's the patch:

From 5417f68ee5892f6a587895105854cadf29eb7297 Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Thu, 11 Mar 2021 23:19:30 -0800
Subject: [PATCH] syscalls: mount: Fix a matching bug.

On some systems, the columns in /proc/self/mountinfo look like this:

23 28 0:21 / /proc rw,nosuid,nodev,noexec,relatime shared:11 - proc proc rw

Before this change, the mount procedure was written with the assumption that
the type and source could always be found in columns 8 and 9, respectively.
However, the proc(5) man page explains that there can be zero or more optional
fields starting at column 7 (e.g., "shared:11" above), so this assumption is
false in some situations.

* guix/build/syscalls.scm (mount): Update the match pattern to use ellipsis to
match zero or more optional fields followed by a single hyphen.  Remove the
trailing ellipsis, since multiple ellipses are not allowed in the same level.
The proc(5) man page indicates that there are no additional columns, so it is
probably OK to match an exact number of columns at the end like this.
---
 guix/build/syscalls.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 552343a481d..726c8e86d06 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -621,8 +621,9 @@ current process."
           (if (eof-object? line)
               (reverse result)
               (match (string-tokenize line)
+                ;; See the proc(5) man page for a description of the columns.
                 ((id parent-id major:minor root mount-point
-                     options _ type source _ ...)
+                     options _ ... "-" type source _)
                  (let ((devno (string->device-number major:minor)))
                    (loop (cons (%mount (octal-decode source)
                                        (octal-decode mount-point)
-- 
2.26.2

Efraim Flashner <efraim@flashner.co.il> writes:

>> Something about the way in which we are searching for the patch is off,
>> but I don't have time just now to investigate.  Efraim, if you can
>> figure it out, that'd be nice, but I'll look into it more tomorrow.
>> It's probably something simple and related to commit 2712703.
>
> Leo told me about it yesterday and I pushed a second commit that fixed
> it. We needed to make sure the patch file was included as an input,
> that's why it got #f instead of a string. In any case, commit
> 710cfc330a7ed06934a193583b159fbdf07bf2fe takes care of it; it's the
> combination of 2712703 and the squash commit.
>
> I'm now running make guix-binary.powerpc64le-linux.tar.xz and so far
> it's made it past the initial building stages, we're on to building the
> grafts now.

Thank you.  This fixed the patch-related problem for me, too.  I'm
currently running "make guix-binary.powerpc64le-linux.tar.xz", also, on
my Debian ppc64le machine.  We'll see how far it gets - fingers crossed!

-- 
Chris

signature.asc
Description: PGP signature