[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ‘staging’ and GNOME updates
From: |
Efraim Flashner |
Subject: |
Re: ‘staging’ and GNOME updates |
Date: |
Mon, 1 Apr 2019 20:16:52 +0300 |
User-agent: |
Mutt/1.11.4 (2019-03-13) |
On Sun, Mar 31, 2019 at 10:52:49PM +0200, Ludovic Courtès wrote:
> Hi!
>
> Ricardo Wurmus <address@hidden> skribis:
>
> > Ludovic Courtès <address@hidden> writes:
> >
> >>> I don't think we should release 1.0 until at least
> >>> <https://bugs.gnu.org/34454> and <https://bugs.gnu.org/34528> are
> >>> fixed. Trying a new distribution only to find your favourite programs
> >>> are crashing would be a _terrible_ first impression.
> >>
> >> Do we have any leads on this IceCat issue? I use IceCat daily and never
> >> have any problems of this sort, FWIW.
> >
> > I’ve seen something like this before, but *only* on i686 machines. I
> > never managed to figure out why.
>
> It looks like Mark fixed this in
> bc91562939ee002e84c95d13c907482b6d1e9339. \o/
>
> > One of the GNOME update branches (for 2.28?) has already been merged
> > into staging. There are rumours of crashes, though, so this will
> > require testing by more people.
>
> OK, so I guess we should first focus on getting ‘staging’ tested and
> merged.
>
> x86_64 substitutes on ci.guix.info cover 60% of the packages right now.
> The main issue is that libdrm has one test failure (see
> <https://ci.guix.info/log/n3hrfx0yvz6g3xm0zkixahn227lispim-libdrm-2.4.97>):
>
> --8<---------------cut here---------------start------------->8---
> starting phase `check'
> [0/1] Running all tests.
> 1/16 kms-symbol-check OK 0.12 s
> 2/16 gen4-3d.batch OK 0.04 s
> 3/16 gen45-3d.batch OK 0.04 s
> 4/16 gen5-3d.batch OK 0.04 s
> 5/16 gen6-3d.batch OK 0.04 s
> 6/16 gen7-3d.batch OK 0.04 s
> 7/16 gen7-2d-copy.batch OK 0.02 s
> 8/16 intel-symbol-check OK 0.67 s
> 9/16 nouveau-symbol-check OK 0.32 s
> 10/16 radeon-symbol-check OK 0.37 s
> 11/16 amdgpu-symbol-check OK 0.52 s
> 12/16 threaded SKIP 0.01 s
> 13/16 random TIMEOUT 240.01 s
> 14/16 hash OK 0.02 s
> 15/16 drmsl OK 1.23 s
> 16/16 drmdevice SKIP 0.01 s
>
> Ok: 13
> Expected Fail: 0
> Fail: 1
> Unexpected Pass: 0
> Skipped: 2
> Timeout: 1
>
>
> The output from the failed tests:
>
> 13/16 random TIMEOUT 240.01 s
> --8<---------------cut here---------------end--------------->8---
>
> > The other GNOME upgrade that I worked on months ago still awaits a
> > rebase onto staging. I’ll try to get it into good shape to have the
> > build farm build it out, so that more people can test it and provide
> > fixes where needed.
>
> Perhaps we can first merge ‘staging’ in its current form, then make this
> branch the new ‘staging’ and aim for a merge as is (with only fixes
> committed there.) How does that sound?
>
> Ludo’.
>
This libdrm test suite timeout looks a lot like the error I was having
in the past on armhf. For armhf it's fixed on staging in fe7c6f91dda,
but it can easily be extended to other/all architectures.
--
Efraim Flashner <address@hidden> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
- Re: ‘staging’ and GNOME updates,
Efraim Flashner <=