On Fri, Mar 12, 2021 at 12:33:18AM -0800, Chris Marusich wrote:
> Hi Efraim and Ludo,
> 
> Efraim Flashner <efraim@flashner.co.il> 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
> failures.
> 
> 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)
>                                result)))))))))))
> --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 rw,size=3923828k,nr_inodes=980957,mode=755
> ...
> --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 rw,size=15625664k,nr_inodes=244151,mode=755
> ...
> --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 rw,size=7972408k,nr_inodes=1993102,mode=755
> 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.

Ooops, I guess it was like the findutils-boot0 patch, necessary for
core-updates but not needed for master.

> The second contributing factor is this bug:
> 
> https://issues.guix.gnu.org/47018
> 
> 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---
> glibc-2.31/wctype/wctrans_l.c
> glibc-2.31/wctype/wctype.c
> glibc-2.31/wctype/wctype.h
> glibc-2.31/wctype/wctype_l.c
> phase `unpack' succeeded after 2.4 seconds
> starting phase `apply-patch'
> Backtrace:
> 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 "/gnu/store/kvwc9b9ga1sl4l6fyi3z182570rbsk2i-glibc-intermediate-2.31-guile-builder"]
> 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.
> 

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.


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