Bug 1274974 - glibc is FTBFS on ppc64 rawhide
Summary: glibc is FTBFS on ppc64 rawhide
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Florian Weimer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PPCTracker
TreeView+ depends on / blocked
 
Reported: 2015-10-24 11:51 UTC by Peter Robinson
Modified: 2015-10-28 20:47 UTC (History)
9 users (show)

Fixed In Version: glibc-2.22.90-11.fc24
Clone Of:
Environment:
Last Closed: 2015-10-28 20:47:56 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
build log (737.26 KB, application/x-xz)
2015-10-24 11:51 UTC, Peter Robinson
no flags Details

Description Peter Robinson 2015-10-24 11:51:59 UTC
Created attachment 1086077 [details]
build log

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2826185

Lots of test failures so adding the build log, sorry for compressing it as it's 55mbbv

Comment 1 Peter Robinson 2015-10-26 10:04:51 UTC
So looking at this closer the last NVR to build was glibc-2.22.90-3.fc24

Looking at the change log there was quite a few package bits done in -4 including what looks to be the introduction of extra tests, I wonder if these were already an issue on PPC but just not actually running and hence not failing the build. Might be a starting point for investigation.

* Wed Oct 21 2015 Carlos O'Donell <carlos> - 2.22.90-9
- Sync with upstream master.
- Update new condvar implementation.

* Fri Oct  9 2015 Carlos O'Donell <carlos> - 2.22.90-8
- Remove libbsd.a (#1193168).

* Wed Sep 16 2015 Mike FABIAN <mfabian> - 2.22.90-7
- Add the C.UTF-8 locale (#902094).

* Wed Sep 16 2015 Carlos O'Donell <carlos> - 2.22.90-6
- Fix GCC 5 and -Werror related build failures.
- Fix --install-langs bug which causes SIGABRT (#1262040).

* Fri Aug 28 2015 Carlos O'Donell <carlos> - 2.22.90-5
- Auto-sync with upstream master.

* Thu Aug 27 2015 Carlos O'Donell <carlos> - 2.22.90-4
- Build require gcc-c++ for the C++ tests.
- Support --without testsuite option to disable testing after build.
- Support --without benchtests option to disable microbenchmarks.
- Update --with bootstrap to disable benchtests, valgrind, documentation,
  selinux, and nss-crypt during bootstrap.
- Support --without werror to disable building with -Werror.
- Support --without docs to disable build requirement on texinfo.
- Support --without valgrind to disable testing with valgrind.
- Remove c_stubs add-on and enable fuller support for static binaries.
- Remove librtkaio support (#1227855).

Comment 2 Florian Weimer 2015-10-26 11:44:48 UTC
*** Bug 1273103 has been marked as a duplicate of this bug. ***

Comment 3 Florian Weimer 2015-10-26 15:46:30 UTC
We have to disable the build-time check for valgrind on ppc64 again, like we already did in commit 6105e83f8867502af1519979a9fb1a7ab0eccd7a.

Comment 4 Peter Robinson 2015-10-26 20:00:11 UTC
With glibc-2.22.90-9.fc24 ppc64le builds but pcc64p7, and I suspect ppc64 still fail:

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2832238

Comment 5 Carlos O'Donell 2015-10-26 20:06:16 UTC
I had just noticed on the ppc-koji instance that the build was failing. It was a mistake to enable it again for ppc64 without double checking the results.

commit d387855c4990cd5accac769b2138d291f35f8633
Author: Carlos O'Donell <carlos>
Date:   Mon Oct 26 16:03:54 2015 -0400

    Resolves: #1274974
    
    Related: #1273103
    
    - Disable valgrind test for ppc64.

Comment 6 Carlos O'Donell 2015-10-26 20:07:17 UTC
At least one good outcome was that we filed bug 1273103 and now Mark can take a look at the valgrind issue.

Comment 7 Peter Robinson 2015-10-27 10:46:24 UTC
Still failing with -10

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2832953

Comment 8 Peter Robinson 2015-10-27 10:47:21 UTC
Still failing with -10, does this depend on a fix for valgrind first?

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2832953

Comment 9 Florian Weimer 2015-10-27 10:56:25 UTC
I think it fails because the builder sets the architecture to ppc64p7, not ppc64.  Is there a way to do this with mock?  Then I can try out a fix.

Comment 10 Carlos O'Donell 2015-10-27 13:24:19 UTC
(In reply to Florian Weimer from comment #9)
> I think it fails because the builder sets the architecture to ppc64p7, not
> ppc64.  Is there a way to do this with mock?  Then I can try out a fix.

Thanks for taking this one. I was conservative and only disabled the test for ppc64, not both that and ppc64p7. Just checkin the obvious addition of ppc64p7 to the ifarch check?

Comment 11 Florian Weimer 2015-10-27 13:43:42 UTC
(In reply to Carlos O'Donell from comment #10)
> (In reply to Florian Weimer from comment #9)
> > I think it fails because the builder sets the architecture to ppc64p7, not
> > ppc64.  Is there a way to do this with mock?  Then I can try out a fix.
> 
> Thanks for taking this one. I was conservative and only disabled the test
> for ppc64, not both that and ppc64p7. Just checkin the obvious addition of
> ppc64p7 to the ifarch check?

I believe so, %ifarch takes a list of arguments (I checked the RPM sources and tested it).

Comment 12 Peter Robinson 2015-10-28 08:43:48 UTC
> I believe so, %ifarch takes a list of arguments (I checked the RPM sources
> and tested it).

Yes, or there's a macro is you want to cover all PPC arches: %{power64}

Comment 13 Florian Weimer 2015-10-28 16:00:01 UTC
(In reply to Peter Robinson from comment #12)
> > I believe so, %ifarch takes a list of arguments (I checked the RPM sources
> > and tested it).
> 
> Yes, or there's a macro is you want to cover all PPC arches: %{power64}

ppc64le is apparently unaffected because it uses the ELFv2 ABI, so %{power64} seems incorrect.  I have added ppc64p7 to the list of architectures instead.

Comment 14 Florian Weimer 2015-10-28 20:47:56 UTC
Version glibc-2.22.90-11.fc24 builds on all POWER architectures:

  http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=352974


Note You need to log in before you can comment on or make changes to this bug.