[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release on April 18th?

From: Chris Marusich
Subject: Re: Release on April 18th?
Date: Fri, 12 Mar 2021 00:33:18 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi Efraim and Ludo,

Efraim Flashner <> writes:

> My plan was absolutely to merge master into core-updates after and then
> integrate all the changes into their affected packages. I'd also make
> sure to bump gcc to 8 (assuming we don't go straight to 9).

Sounds good.  If we can get powerpc64le-linux working on master, I'd be
very happy.  We can simultaneously try that while still working on
wip-ppc64le (based on core-updates).

I tried out the wip-ppc64le-for-master branch.  I can build it manually
on my Debian ppc64le system, but "make check" fails.  There are two test

The first test failure is tests/syscalls.scm.  It seems that Ludo's
recently added mount procedure (7e9d9f2 syscalls: Add 'mounts' and the
<mount> record type.) does not work on my system.  In fact, it does not
work on my Debian ppc64le system, nor does it work on my x86_64 Fedora
system.  In both cases, the code makes the incorrect assumption that the
type and source are located in columns 8 and 9, like so:

--8<---------------cut here---------------start------------->8---
(define (mounts)
  "Return the list of mounts (<mount> records) visible in the namespace of the
current process."
  (define (string->device-number str)
    (match (string-split str #\:)
      (((= string->number major) (= string->number minor))
       (+ (* major 256) minor))))

  (call-with-input-file "/proc/self/mountinfo"
    (lambda (port)
      (let loop ((result '()))
        (let ((line (read-line port)))
          (if (eof-object? line)
              (reverse result)
              (match (string-tokenize line)
                ((id parent-id major:minor root mount-point
                     options _ _ type source _ ...)
                 (let ((devno (string->device-number major:minor)))
                   (loop (cons (%mount (octal-decode source)
                                       (octal-decode mount-point)
                                       devno type options)
--8<---------------cut here---------------end--------------->8---

However, on my systems, the correct columns are 9 and 10.  Here's the
first few lines of output from Fedora:

--8<---------------cut here---------------start------------->8---
$ cat /proc/self/mountinfo 
22 97 0:21 / /sys rw,nosuid,nodev,noexec,relatime shared:2 - sysfs sysfs rw
23 97 0:5 / /proc rw,nosuid,nodev,noexec,relatime shared:24 - proc proc rw
24 97 0:6 / /dev rw,nosuid shared:20 - devtmpfs devtmpfs 
--8<---------------cut here---------------end--------------->8---

And here it is from Debian:

--8<---------------cut here---------------start------------->8---
22 28 0:20 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw
23 28 0:21 / /proc rw,nosuid,nodev,noexec,relatime shared:11 - proc proc rw
24 28 0:5 / /dev rw,nosuid,noexec,relatime shared:2 - devtmpfs udev 
--8<---------------cut here---------------end--------------->8---

On these systems, the 7th column is an optional field, like "shared:7".
The proc man page has this to say about column 7:

  (7) optional fields: zero or more fields of the form "tag[:value]"

So presumably there can be even more than just one optional field.  In
any case, Leo Le Bouter kindly checked his own x86_64 system, where he
observed different output:

--8<---------------cut here---------------start------------->8---
$ cat /proc/self/mountinfo 
23 27 0:21 / /proc rw,relatime - proc none rw
24 27 0:5 / /dev rw,relatime - devtmpfs none 
25 27 0:22 / /sys rw,relatime - sysfs none rw
--8<---------------cut here---------------end--------------->8---

As you can see, in this case there is no optional column, so the mount
procedure works fine on Leo's system.  But it fails on mine.

Ludo, do you have an opinion on how to fix this?  It seems like we can't
assume the number of columns will always be the same, so I guess we'll
have to somehow ignore the optional columns more intelligently, if we
want to keep using string-tokenize to do this.

The second test failure is tests/pack.scm.  There are two contributing
factors to this test failure.

The first contributing factor was commit 8f52ea2 on
wip-ppc64le-for-master.  It fixes an issue that is not present on
master, and for that reason it actually causes a problem if it's
included.  I have removed it from the branch in Savannah; please update
your local copy.

The second contributing factor is this bug:

However, we can work around it by simply not running guix-daemon when
running the test.  When guix builds guix, it'll be done in the build
environment, so these problematic tests will probably be skipped.

Finally, I tried running make guix-binary.powerpc64le-linux.tar.xz just
to see how far it would get, anyway.  I was quickly greeted with this
failure when building glibc-intermediate:

--8<---------------cut here---------------start------------->8---
phase `unpack' succeeded after 2.4 seconds
starting phase `apply-patch'
In ice-9/boot-9.scm:
 160: 14 [catch #t #<catch-closure 7ffff0382200> ...]
In unknown file:
   ?: 13 [apply-smob/1 #<catch-closure 7ffff0382200>]
In ice-9/boot-9.scm:
  66: 12 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 11 [eval # #]
In ice-9/boot-9.scm:
2412: 10 [save-module-excursion #<procedure 7ffff03a4800 at 
ice-9/boot-9.scm:4084:3 ()>]
4089: 9 [#<procedure 7ffff03a4800 at ice-9/boot-9.scm:4084:3 ()>]
1734: 8 [%start-stack load-stack ...]
1739: 7 [#<procedure 7ffff03ba930 ()>]
In unknown file:
   ?: 6 [primitive-load 
In ice-9/eval.scm:
 387: 5 [eval # ()]
In ice-9/boot-9.scm:
 160: 4 [catch srfi-34 ...]
In srfi/srfi-1.scm:
 827: 3 [every1 #<procedure 7fffef522f20 at 
guix/build/gnu-build-system.scm:843:11 (expr)> ...]
In guix/build/gnu-build-system.scm:
 847: 2 [#<procedure 7fffef522f20 at guix/build/gnu-build-system.scm:843:11 
(expr)> #]
In guix/build/utils.scm:
 652: 1 [invoke "patch" "--force" "-p1" "-i" #f]
In unknown file:
   ?: 0 [system* "patch" "--force" "-p1" "-i" #f]

ERROR: In procedure system*:
ERROR: Wrong type (expecting string): #f
--8<---------------cut here---------------end--------------->8---

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.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]