Re: ‘staging’ and GNOME updates

[Efraim Flashner <efraim@flashner.co.il>]

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

On Sun, Mar 31, 2019 at 10:52:49PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Ricardo Wurmus <rekado@elephly.net> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> 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   <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

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