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 failures. The first test failure is tests/syscalls.scm. It seems that Ludo's recently added mount procedure (7e9d9f2 syscalls: Add 'mounts' and the 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 ( 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. 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 # ...] In unknown file: ?: 13 [apply-smob/1 #] 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 #] 4089: 9 [#] 1734: 8 [%start-stack load-stack ...] 1739: 7 [#] 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 # ...] In guix/build/gnu-build-system.scm: 847: 2 [# #] 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. -- Chris