#5962 mass rebuild of non-noarch packages in f21 and rawhide
Closed: Fixed None Opened 9 years ago by sharkcz.

Hi,
we would like to do a mass rebuild for all non-noarch packages in f21 (and rawhide) for 2 reasons
- glibc upstream reverted the ABI change they made in 2.19, which was included in the f21 development tree earlier and today is fully integrated because the rebootstrap in fedora/s390x and the mass rebuild done in early June
- possibly wrong code generated by the gcc 4.9, fweimer should have the details


The GCC bug is [[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801|PR61801]], [[https://bugzilla.redhat.com/show_bug.cgi?id=1120473|bz1120473]] (filed against glibc, but it was fixed in gcc-4.9.1-2). This bug is known to result in miscompilation of the kernel and glibc, and other users of inline assembly are likely to be affected, too. It was present in older GCC versions, too, but it's much easier to trigger since 4.9. I'm worried that the current level of testing is insufficient to reveal remaining miscompilations in Fedora 21, hence the suggestion of a mass rebuild with the GCC fix.

for dist-git I would prefer to keep f21 and master branches merged (pointing to same HEAD) when possible

Replying to [comment:3 sharkcz]:

for dist-git I would prefer to keep f21 and master branches merged (pointing to same HEAD) when possible

At the moment the mass rebuild script doesn't support that and there's a non insignificant amount of packages that have diverged (ocaml and all dependencies are one example, kernel is another) so there would have to be some logic that goes through the dist-git trees and work out whether there's any divergences of said trees and then push a build to master, merge the change to F-21 and push the build for F-21 and if there is divergence to push the builds as two different commits.

I guess the build order should be
- new gcc
- new glibc
- the rest

Jakub, should we wait for a new gcc?

Siddhesh, how about glibc? Has the version with the s390 ABI change been already committed?

Replying to [comment:6 sharkcz]:

Siddhesh, how about glibc? Has the version with the s390 ABI change been already committed?

I haven't committed it yet, but I will do that later today.

To be specific, I'll rebase both rawhide and f21 to the latest upstream today, which has now almost slowed down to a crawl in preparation for 2.20. It should also fix at least one build failure that Jakub had reported. I'm working on another miscompilation issue, which should also hopefully be fixed with this rebuild if I am quick enough.

Replying to [comment:6 sharkcz]:

I guess the build order should be
- new gcc

Jakub, should we wait for a new gcc?

Certainly. I'm building gcc-4.9.1-6.fc{21,22} right now, but due to the extra slow arm it might take many hours to finish.
It should fix the #1126463 miscompilation on s390 (which in theory can affect all architectures, especially 32-bit ones), and contain other wrong-code fixes.

Replying to [comment:9 jakub]:

Replying to [comment:6 sharkcz]:

I guess the build order should be
- new gcc

Jakub, should we wait for a new gcc?

Certainly. I'm building gcc-4.9.1-6.fc{21,22} right now, but due to the extra slow arm it might take many hours to finish.
It should fix the #1126463 miscompilation on s390 (which in theory can affect all architectures, especially 32-bit ones), and contain other wrong-code fixes.

perfect, thanks

for the record here are the links to koji:
[http://koji.fedoraproject.org/koji/buildinfo?buildID=552585 gcc-4.9.1-6.fc21] and
[http://koji.fedoraproject.org/koji/buildinfo?buildID=552584 gcc-4.9.1-6.fc22]

I have pushed glibc changes to master and f21. I'll kick off the builds once the gcc build is tagged in (and I am awake).

Replying to [comment:12 siddhesh]:

I have pushed glibc changes to master and f21. I'll kick off the builds once the gcc build is tagged in (and I am awake).

and after the next newRepo task is run, best to check with "koji wait-repo --build gcc-4.9.1-6.fc21 f21-build" for the f21 build, similar for rawhide (s/21/22/)

Unfortunately the wrong-code http://gcc.gnu.org/PR62025 bugfix doesn't seem to be sufficient, I'll need to do another gcc build tomorrow. There are still wrong-code risks with what is in gcc-4.9.1-6.fc2{1,2}.

Replying to [comment:14 jakub]:

Unfortunately the wrong-code http://gcc.gnu.org/PR62025 bugfix doesn't seem to be sufficient, I'll need to do another gcc build tomorrow. There are still wrong-code risks with what is in gcc-4.9.1-6.fc2{1,2}.

I can confirm gcc-4.9.1-7.fc21 can build openssl on s390 - http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1488456

I staged various ghc-* version updates in git for rawhide in preparation for ghc-7.8.3,
but these should not be built/pushed to f22 until ghc-7.8.3 work is ready.
So the rawhide mass rebuild caught me off-guard.

I would like to untag the version bumps to various Haskell packages
that were built into f22-gcc-rebuild.

you can only untag builds from rawhide if they have not gone out, rawhide compose starts at 5:15 UTC you would have had to untagged before then.

Closing this ticket as the rebuilds are done and moved back to the main tags

Metadata Update from @sharkcz:
- Issue set to the milestone: Fedora 21 Alpha

7 years ago

Login to comment on this ticket.

Metadata