unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Chris Marusich <cmmarusich@gmail.com>
To: "Efraim Flashner" <efraim@flashner.co.il>,
	"Ludovic Courtès" <ludo@gnu.org>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Release on April 18th?
Date: Fri, 12 Mar 2021 00:33:18 -0800	[thread overview]
Message-ID: <87h7lgzs8h.fsf@gmail.com> (raw)
In-Reply-To: <YEobbaaktDmchuaQ@3900XT> (Efraim Flashner's message of "Thu, 11 Mar 2021 15:30:21 +0200")

[-- Attachment #1: Type: text/plain, Size: 6932 bytes --]

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.

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.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2021-03-12  8:34 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 14:51 Release on April 18th? zimoun
2021-03-02 16:00 ` Julien Lepiller
2021-03-02 20:03 ` Leo Famulari
2021-03-05 14:31   ` Andreas Enge
2021-03-05 19:27     ` Leo Famulari
2021-03-05 20:20       ` zimoun
2021-03-05 20:58         ` Leo Famulari
2021-03-05 23:57           ` zimoun
2021-03-06 20:14           ` Tobias Geerinckx-Rice
2021-03-03 14:16 ` Ludovic Courtès
2021-03-03 18:51   ` Leo Famulari
2021-03-04  9:41     ` zimoun
2021-03-04 19:07       ` Leo Famulari
2021-03-04 22:18         ` zimoun
2021-03-04 22:43           ` Leo Famulari
2021-03-05 20:19     ` Leo Famulari
2021-03-05 23:58       ` zimoun
2021-03-06 18:56         ` Leo Famulari
2021-03-06 19:06     ` Leo Famulari
2021-03-06 23:22       ` Leo Famulari
2021-03-07  3:51         ` Raghav Gururajan
2021-03-07  5:39           ` Raghav Gururajan
2021-03-07 20:44             ` Leo Famulari
2021-03-07 20:56               ` Raghav Gururajan
2021-03-07 20:50             ` Leo Famulari
2021-03-08  9:38       ` zimoun
2021-03-05 20:21   ` Leo Famulari
2021-03-09 18:17 ` Chris Marusich
2021-03-09 21:32   ` Vincent Legoll
2021-03-10  8:30     ` Release on April 18th? (ppc64le support specifically) Efraim Flashner
2021-03-11  9:10     ` Release on April 18th? Chris Marusich
2021-03-12  8:02       ` Vincent Legoll
2021-03-12 18:42         ` Chris Marusich
2021-03-12 18:52           ` Chris Marusich
2021-03-14 12:31           ` Vincent Legoll
2021-03-15 16:36           ` Ludovic Courtès
2021-03-16  4:03           ` Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?) Chris Marusich
2021-03-16  7:08             ` Efraim Flashner
2021-03-16  8:10               ` Léo Le Bouter
2021-03-23 13:42             ` Let's include powerpc64le-linux in the next release Ludovic Courtès
2021-03-23 13:47               ` Léo Le Bouter
2021-03-23 14:01               ` Tobias Geerinckx-Rice
2021-03-30  8:23                 ` Ludovic Courtès
2021-03-30 22:20                   ` Vincent Legoll
2021-03-23 17:09               ` Let's include powerpc64le-linux in the next release, " Chris Marusich
2021-03-10 13:27   ` Release on April 18th? zimoun
2021-03-10 15:30     ` Efraim Flashner
2021-03-10 15:59       ` zimoun
2021-03-10 18:33         ` Efraim Flashner
2021-03-11  8:58       ` Chris Marusich
2021-03-11 13:30         ` Efraim Flashner
2021-03-12  8:33           ` Chris Marusich [this message]
2021-03-12 10:11             ` Andreas Enge
2021-03-12 13:43             ` Efraim Flashner
  -- strict thread matches above, loose matches on Subject: below --
2021-02-28  6:53 I've rebased wip-ppc64le onto core-updates Chris Marusich
2021-02-28 20:42 ` Léo Le Bouter
2021-03-01 19:14   ` Tobias Platen
2021-03-01 21:36   ` jbranso
2021-03-10 10:17 ` Ludovic Courtès
2021-03-10 10:37   ` Efraim Flashner
2021-03-11  8:24   ` Chris Marusich
2021-03-11  8:37     ` Léo Le Bouter
2021-03-15 16:25     ` Ludovic Courtès
2021-03-16  4:26       ` I've rebased wip-ppc64le onto core-updates, Re: Release on April 18th? Chris Marusich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h7lgzs8h.fsf@gmail.com \
    --to=cmmarusich@gmail.com \
    --cc=efraim@flashner.co.il \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).