Mass rebuild status

[Kevin Fenzi]

Greetings. 

Aside from a few stragglers, the mass rebuild is complete.

However, we ran into a number of builds that failed at the start of the
mass rebuild due to some problems with s390x builders.

Due to that and also to reduce the chance of any failed builds being
caused by builder or network issues, I am resubmitting the builds that
failed the mass rebuild again. 

There are 1477 of those.

I expect we will merge the mass rebuild side tag into rawhide tomorrow.

See
https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html
and
https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html

for detailed lists of what needs rebuilding and what failed. 

kevin

_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

[Jerry James]

On Sat, Feb 1, 2020 at 6:04 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  Aside from a few stragglers, the mass rebuild is complete. 
That's great!  Thanks for all of your work making this happen, Kevin.
I do want to point out that at least one of my packages, GAPDoc, does
not seem to have had a build started at all.  For this package, it
shouldn't matter, but I point this out in case it happened to other
packages, too.

Regards,
-- 
Jerry James
http://www.jamezone.org/

[Kevin Fenzi]

On Sun, Feb 02, 2020 at 09:04:47PM -0700, Jerry James wrote:
>  On Sat, Feb 1, 2020 at 6:04 PM Kevin Fenzi <kevin(a)scrye.com&gt;
> wrote:
>  > Aside from a few stragglers, the mass rebuild is complete.
>  
>  That's great!  Thanks for all of your work making this happen, Kevin.
>  I do want to point out that at least one of my packages, GAPDoc, does
>  not seem to have had a build started at all.  For this package, it
>  shouldn't matter, but I point this out in case it happened to other
>  packages, too. 
That needs some investigation. Can you file a releng ticket on it?

We need to sort out why it wasn't built... I do see the commit, but
oddly no build at all. 

kevin

[Peter Robinson]

>  > > Aside from a few stragglers, the mass rebuild is complete.
>  >
>  > That's great!  Thanks for all of your work making this happen, Kevin.
>  > I do want to point out that at least one of my packages, GAPDoc, does
>  > not seem to have had a build started at all.  For this package, it
>  > shouldn't matter, but I point this out in case it happened to other
>  > packages, too.
>
>  That needs some investigation. Can you file a releng ticket on it?
>
>  We need to sort out why it wasn't built... I do see the commit, but
>  oddly no build at all. 
Generally if it has issues creating the srpm, like a missing patch or
similar, you'll see that.

[Jerry James]

On Mon, Feb 3, 2020 at 9:59 AM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  That needs some investigation. Can you file a releng ticket on it?
>
>  We need to sort out why it wasn't built... I do see the commit, but
>  oddly no build at all. 
https://pagure.io/releng/issue/9220

Thanks, Kevin.
-- 
Jerry James
http://www.jamezone.org/

Possible gcc/s390x bug (was Re: Mass rebuild status)

[Adam Jackson]

On Sat, 2020-02-01 at 16:59 -0800, Kevin Fenzi wrote:

>  See
>  https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html
>  and
>  https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html
>  
>  for detailed lists of what needs rebuilding and what failed.  
libXt's failure on s390x seems to be repeatable, unique to that
architecture, and frankly hilarious:

PassivGrab.c: In function '_XtCheckServerGrabsOnWidget':
PassivGrab.c:292:35: error: array subscript 0 is outside array bounds of
'XtServerGrabRec[1]' {aka 'struct _XtServerGrabRec[1]'}
[-Werror=array-bounds]
  292 |  first.pMask = GRABEXT(pFirstGrab)->pModifiersMask;
PassivGrab.c:556:22: note: while referencing 'tempGrab'
  556 |     XtServerGrabRec  tempGrab;
      |                      ^~~~~~~~

Where GRABEXT here is just doing the standard C trick for incrementing
past the current struct and returning a (differently typed) pointer to
the data beyond:

#define GRABEXT(p) ((XtServerGrabExtPtr)((p)+1))

A scratch build, including a dump of PassivGrab.i in the build.log, can
be found here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=41355653

Any ideas?

- ajx

Possible gcc/s390x bug (was Re: Mass rebuild status)

[Marek Polacek]

On Tue, Feb 04, 2020 at 10:51:17AM -0500, Adam Jackson wrote:
>  On Sat, 2020-02-01 at 16:59 -0800, Kevin Fenzi wrote:
>  
>  > See
>  > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html
>  > and
>  > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html
>  > 
>  > for detailed lists of what needs rebuilding and what failed. 
>  
>  libXt's failure on s390x seems to be repeatable, unique to that
>  architecture, and frankly hilarious: 
Actually I can also reproduce on x86_64 with -O3:

$ ./cc1 -quiet -O3 -Werror=array-bounds ajax.i
PassivGrab.c: In function ‘_XtCheckServerGrabsOnWidget’:
PassivGrab.c:291:54: error: array subscript 0 is outside array bounds of
‘XtServerGrabRec[1]’ {aka ‘struct _XtServerGrabRec[1]’} [-Werror=array-bounds]
PassivGrab.c:546:21: note: while referencing ‘tempGrab’

>  PassivGrab.c: In function '_XtCheckServerGrabsOnWidget':
>  PassivGrab.c:292:35: error: array subscript 0 is outside array bounds of
> 'XtServerGrabRec[1]' {aka 'struct _XtServerGrabRec[1]'}
> [-Werror=array-bounds]
>    292 |  first.pMask = GRABEXT(pFirstGrab)->pModifiersMask;
>  PassivGrab.c:556:22: note: while referencing 'tempGrab'
>    556 |     XtServerGrabRec  tempGrab;
>        |                      ^~~~~~~~
>  
>  Where GRABEXT here is just doing the standard C trick for incrementing
>  past the current struct and returning a (differently typed) pointer to
>  the data beyond:
>  
>  #define GRABEXT(p) ((XtServerGrabExtPtr)((p)+1))
>  
>  A scratch build, including a dump of PassivGrab.i in the build.log, can
>  be found here:
>  
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=41355653
>  
>  Any ideas? 
Thanks, we'll take a look.

Marek

Possible gcc/s390x bug (was Re: Mass rebuild status)

[Marek Polacek]

On Tue, Feb 04, 2020 at 11:08:22AM -0500, Marek Polacek wrote:
>  On Tue, Feb 04, 2020 at 10:51:17AM -0500, Adam Jackson wrote:
>  > On Sat, 2020-02-01 at 16:59 -0800, Kevin Fenzi wrote:
>  > 
>  > > See
>  > > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html
>  > > and
>  > > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html
>  > > 
>  > > for detailed lists of what needs rebuilding and what failed. 
>  > 
>  > libXt's failure on s390x seems to be repeatable, unique to that
>  > architecture, and frankly hilarious:
>  
>  Actually I can also reproduce on x86_64 with -O3:
>  
>  $ ./cc1 -quiet -O3 -Werror=array-bounds ajax.i
>  PassivGrab.c: In function ‘_XtCheckServerGrabsOnWidget’:
>  PassivGrab.c:291:54: error: array subscript 0 is outside array bounds of
> ‘XtServerGrabRec[1]’ {aka ‘struct _XtServerGrabRec[1]’} [-Werror=array-bounds]
>  PassivGrab.c:546:21: note: while referencing ‘tempGrab’
>  
>  > PassivGrab.c: In function '_XtCheckServerGrabsOnWidget':
>  > PassivGrab.c:292:35: error: array subscript 0 is outside array bounds of
> 'XtServerGrabRec[1]' {aka 'struct _XtServerGrabRec[1]'}
> [-Werror=array-bounds]
>  >   292 |  first.pMask = GRABEXT(pFirstGrab)->pModifiersMask;
>  > PassivGrab.c:556:22: note: while referencing 'tempGrab'
>  >   556 |     XtServerGrabRec  tempGrab;
>  >       |                      ^~~~~~~~
>  > 
>  > Where GRABEXT here is just doing the standard C trick for incrementing
>  > past the current struct and returning a (differently typed) pointer to
>  > the data beyond:
>  > 
>  > #define GRABEXT(p) ((XtServerGrabExtPtr)((p)+1))
>  > 
>  > A scratch build, including a dump of PassivGrab.i in the build.log, can
>  > be found here:
>  > 
>  > https://koji.fedoraproject.org/koji/taskinfo?taskID=41355653
>  > 
>  > Any ideas?
>  
>  Thanks, we'll take a look. 
I've reduced the code and opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Possible gcc/s390x bug (was Re: Mass rebuild status)

[Dave Love]

I assume this -- currently breaking procenv, as that uses -Werror -- has
the same cause, as it shows up under the same circumstances:

  In function 'strncat',
      inlined from 'appendn' at string-util.c:111:2,
      inlined from 'appendn' at string-util.c:80:1,
      inlined from 'append' at string-util.c:32:2:
  /usr/include/bits/string_fortified.h:136:10: error: '__builtin_strncat' output
truncated before terminating nul copying as many bytes from a string as its length
[-Werror=stringop-truncation]
    136 |   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  string-util.c: In function 'append':
  string-util.c:30:8: note: length computed here
     30 |  len = strlen (src);
        |        ^~~~~~~~~~~~
  cc1: all warnings being treated as errors

Are we supposed to work around such things, or wait until gcc is fixed
at some stage?

Possible gcc/s390x bug (was Re: Mass rebuild status)

[Mamoru TASAKA]

Dave Love wrote on 2020/02/06 1:07:
>  I assume this -- currently breaking procenv, as that uses -Werror --
> has
>  the same cause, as it shows up under the same circumstances:
>  
>     In function 'strncat',
>         inlined from 'appendn' at string-util.c:111:2,
>         inlined from 'appendn' at string-util.c:80:1,
>         inlined from 'append' at string-util.c:32:2:
>     /usr/include/bits/string_fortified.h:136:10: error: '__builtin_strncat' output
> truncated before terminating nul copying as many bytes from a string as its length
> [-Werror=stringop-truncation]
>       136 |   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
>           |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     string-util.c: In function 'append':
>     string-util.c:30:8: note: length computed here
>        30 |  len = strlen (src);
>           |        ^~~~~~~~~~~~
>     cc1: all warnings being treated as errors
>  
>  Are we supposed to work around such things, or wait until gcc is fixed
>  at some stage? 
Filed: https://bugzilla.redhat.com/show_bug.cgi?id=1798636

Possible gcc/s390x bug (was Re: Mass rebuild status)

[Dave Love]

Mamoru TASAKA <mtasaka(a)fedoraproject.org&gt; writes:

>  Filed: https://bugzilla.redhat.com/show_bug.cgi?id=1798636 
For what it's worth, I'd have raised an issue if it has a different
cause, and doesn't fixed along with the original regression, lest it
looks as if I'm shirking bug reporting responsibilities.