Mass Rebuild for Fedora 28

Hi All,

We have now completed the automated part of the Fedora 28 mass rebuild,
The details for the scheduled mass rebuild for Fedora 28 can be found
here[1]. The failure page for the rebuilds can be found here[3] and the
full list of packages that are needing rebuilding can be found here[4].
The needs rebuild list includes packages that failed to get submitted
to koji for various reasons, things like the spec bumping failing due
to incomplete or incorrect retirement

Please quickly clean up all build failures as the schedule[5] has us
branching next Tuesday, on the 20th of February and enabling Bodhi on
the 6th of March, So expect to see a 28 branched compose in about a
week from now.

Many Thanks


[1] <a href="" title=""></a>
[2] <a href="" title=""></a>
[3] <a href="" title=""></a>
[4] <a href="" title=""></a>


Re: Mass Rebuild for Fedora 28

By =?UTF-8?Q?Parag... at 02/20/2018 - 23:16

On Tue, Feb 13, 2018 at 4:36 AM, Dennis Gilmore < ... at ausil dot us> wrote:
I think its better as releng already have above need-rebuild package
list so they can run mass-rebuild script and build all the missed
packages. Are there still any plans to use mass-rebuild script or its
upto individual maintainers to rebuild their packages for Fedora 28?


Re: Mass Rebuild for Fedora 28

By =?UTF-8?Q?Tomas... at 02/14/2018 - 09:09

On 12 February 2018 at 23:06, Dennis Gilmore < ... at ausil dot us> wrote:


Re: Mass Rebuild for Fedora 28

By =?UTF-8?Q?Tomas... at 02/16/2018 - 03:44

On 14 February 2018 at 14:09, Tomasz Kłoczko <kloczko. ... at gmail dot com>

Can someone provide some update about ETA pushing all new packages
generated during last mass rebuild?


Re: Mass Rebuild for Fedora 28

By Adam Williamson at 02/16/2018 - 14:14

On Fri, 2018-02-16 at 08:44 +0000, Tomasz Kłoczko wrote:
Packages go to the 'rawhide' repo when a compose succeeds. When the
composes are failing, the repo doesn't get updated.

The packages are "public", though - they're just not in the 'rawhide'
repo. You can configure a repo to match the Rawhide buildroot, but I
can't find the magic URL for that right now (we don't publicize it
heavily because too many people using it can cause traffic issues on
the server, and it's not multilib safe, and the packages aren't always

Re: Mass Rebuild for Fedora 28

By Thomas Moschny at 02/14/2018 - 03:30

2018-02-13 0:06 GMT+01:00 Dennis Gilmore < ... at ausil dot us>:
Among those are a lot of packages for which it seems the rebuild has
not been tried at all, for whatever reason.
Instead of asking every maintainer to go manually through his or her
packages and verify whether they have been rebuilt, would it make
sense to try to automatically rebuild those ~4.6k packages?

- Thomas

Re: Mass Rebuild for Fedora 28

By =?utf-8?q?Samue... at 02/13/2018 - 15:14

Strange error with camotics:

Problem: package cairo-devel-1.15.10-2.fc28.x86_64 requires pkgconfig(gobject-2.0), but none of the providers can be installed
- conflicting requests
- nothing provides /usr/bin//usr/bin/python3 needed by glib2-devel-2.55.2-1.fc28.x86_64

Re: Mass Rebuild for Fedora 28

By Igor Gnatenko at 02/14/2018 - 01:57

Hash: SHA256

On Tue, 2018-02-13 at 20:14 +0000, Samuel Rakitničan wrote:
Just rebuild, this bug has been fixed for quite some time already.

Re: Mass Rebuild for Fedora 28

By Dennis Gilmore at 02/13/2018 - 16:02

El mar, 13-02-2018 a las 20:14 +0000, Samuel Rakitničan escribió:
that looks like a packaging bug in glib2


clang -mcet -fcf-protection (was: Re: Mass Rebuild for Fedora 28

By Richard W.M. Jones at 02/13/2018 - 05:18

My build of american-fuzzy-lop fails because clang doesn't
understand the ‘-mcet -fcf-protection’ flags which seem to be
added by RPM.

clang -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/lib64/afl\" -DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.52b\" afl-clang-fast.c -o ../afl-clang-fast
clang-6.0: error: unknown argument: '-mcet'
clang-6.0: error: unknown argument: '-fcf-protection'

(<a href="" title=""></a>)

This suggests a bug in our RPM configuration.


Re: clang -mcet -fcf-protection

By Tom Stellard at 02/14/2018 - 14:03

On 02/13/2018 02:18 AM, Richard W.M. Jones wrote:
Is there a particular reason this packages uses clang and not gcc?


Re: clang -mcet -fcf-protection

By Richard W.M. Jones at 02/14/2018 - 14:22

On Wed, Feb 14, 2018 at 11:03:28AM -0800, Tom Stellard wrote:
It uses both. In this case it uses clang because it has to build a
clang extension (as well as a gcc extension).


Re: clang -mcet -fcf-protection

By Florian Weimer at 02/15/2018 - 02:33

On 02/14/2018 08:22 PM, Richard W.M. Jones wrote:
Isn't Clang compiled with GCC, too? (At least in the past, we didn't
bootstrap it.) Why is Clang required to build the extension?

(Clang is obviously needed to test the plug-in, but upstream probably
has very precise ideas about the compiler flags to use for that anyway.)


Re: clang -mcet -fcf-protection (was: Re: Mass Rebuild for Fedor

By Daniel P. Berrange at 02/13/2018 - 05:36

On Tue, Feb 13, 2018 at 10:18:05AM +0000, Richard W.M. Jones wrote:
Not much more info about what these flags do, but the change was recorded
here with an opaque "Intel says we need this" rationale:

<a href="" title=""></a>

redhat-rpm-config flags have usually been compatible with both gcc and
clang, so if there's no newer clang that supports this, it feels like
we've a few options

1. Have the RPM spec for apps using clang filter these flags out of
the RPM cflags.
2. Revert the change in redhat-rpm-config so we're compatible with
3. Provide a second macro in redhat-rpm-config that is the cut down
set of cflags which still work with clang, that apps can opt for.


Re: clang -mcet -fcf-protection (was: Re: Mass Rebuild for Fedor

By Igor Gnatenko at 02/14/2018 - 01:56

Hash: SHA256

On Tue, 2018-02-13 at 10:36 +0000, Daniel P. Berrangé wrote:
As long as it doesn't break builds, I don't think we need this separation. If
clang is simply ignoring flags, let it do that

Re: clang -mcet -fcf-protection

By Florian Weimer at 02/13/2018 - 08:27

On 02/13/2018 11:36 AM, Daniel P. Berrangé wrote:
You forgot:

4. Compile the package with GCC (porting it if necessary).

GCC is the Fedora system compiler, after all.


Re: clang -mcet -fcf-protection

By Richard W.M. Jones at 02/14/2018 - 16:59

On Tue, Feb 13, 2018 at 02:27:02PM +0100, Florian Weimer wrote:
This package legitimately uses clang to build a clang plugin.


Re: clang -mcet -fcf-protection

By Dominik 'Rathan... at 02/13/2018 - 08:36

On Tuesday, 13 February 2018 at 14:27, Florian Weimer wrote:
The Packaging Guidelines say this, too:
<a href="" title=""></a>


Re: clang -mcet -fcf-protection

By Tom Hughes at 02/13/2018 - 05:46

On 13/02/18 10:36, Daniel P. Berrangé wrote:
Here's how the gcc 8 documentation describes -mcet:

The '-mcet' option turns on the '-mibt' and '-mshstk' options. The
'-mibt' option enables indirect branch tracking support and the
'-mshstk' option enables shadow stack support from Intel
Control-flow Enforcement Technology (CET). The compiler also
provides a number of built-in functions for fine-grained control in
a CET-based application. See *Note x86 Built-in Functions::, for
more information.

and -fcf-protection:

Enable code instrumentation of control-flow transfers to increase
program security by checking that target addresses of control-flow
transfer instructions (such as indirect function call, function
return, indirect jump) are valid. This prevents diverting the flow
of control to an unexpected target. This is intended to protect
against such threats as Return-oriented Programming (ROP), and
similarly call/jmp-oriented programming (COP/JOP).

The value 'branch' tells the compiler to implement checking of
validity of control-flow transfer at the point of indirect branch
instructions, i.e. call/jmp instructions. The value 'return'
implements checking of validity at the point of returning from a
function. The value 'full' is an alias for specifying both
'branch' and 'return'. The value 'none' turns off instrumentation.

You can also use the 'nocf_check' attribute to identify which
functions and calls should be skipped from instrumentation (*note
Function Attributes::).

Currently the x86 GNU/Linux target provides an implementation based
on Intel Control-flow Enforcement Technology (CET). Instrumentation
for x86 is controlled by target-specific options '-mcet', '-mibt'
and '-mshstk' (*note x86 Options::).

Given that -mcet seems to turn on extra instructions is this not an
issue for compatibility with older processors? or are they sequences
which decode as no-ops on older processors?


Re: clang -mcet -fcf-protection

By Florian Weimer at 02/13/2018 - 08:25

On 02/13/2018 11:46 AM, Tom Hughes wrote:
They are NOPs on all current CPUs. They trap on some older CPUs, but we
coordinated this change with the x86 SIG to make sure that it matches
their requirements.


Re: clang -mcet -fcf-protection

By Jakub Jelinek at 02/13/2018 - 06:00

On Tue, Feb 13, 2018 at 10:46:37AM +0000, Tom Hughes wrote:
<a href="" title=""></a>
The instructions are NOPs on older CPUs.


Re: Mass Rebuild for Fedora 28

By TASAKA Mamoru at 02/12/2018 - 19:36

Dennis Gilmore wrote on 02/13/2018 08:06 AM:
f28-need-rebuild.html [4] shows that most of "need-rebuild" packages are
assigned to rel-eng, and does not seem to show the "real" owner of packages


Re: Mass Rebuild for Fedora 28

By Peter Robinson at 02/13/2018 - 04:37

About 5K packages is very high for the average mass rebuild failures
(around 25% of the total source packages), there was a dist-git outage
during the mass rebuild and I wonder if a bunch of these were affected
by that issue, any chance rel-eng could check the logs to see if there
were timeouts/503 errors against a bunch of the failures?


Re: Mass Rebuild for Fedora 28

By Adam Williamson at 02/13/2018 - 16:22

On Tue, 2018-02-13 at 09:37 +0000, Peter Robinson wrote:
Possibly related, I had a bunch of failures trying to build os-autoinst
on Friday which were not the package's fault; seemed like the s390x
build kept failing or hanging. It built fine this morning.

Re: Mass Rebuild for Fedora 28

By Vascom at 02/13/2018 - 02:16

I am see that my package libzen in need rebuild list. but I can't find
failed koji build for it to see logs.
Where I can find failed build? Or I must run it manually?

вт, 13 февр. 2018 г. в 3:37, Mamoru TASAKA < ... at fedoraproject dot org>:

Re: Mass Rebuild for Fedora 28

By Kevin Fenzi at 02/13/2018 - 11:43

On 02/12/2018 11:16 PM, Vascom wrote:
There were some packages missed because pkgs01 had a short outage.
I suspect yours is one of those, so just bump the release and do a new
build and it should disappear from the list.


Re: Mass Rebuild for Fedora 28

By Tomasz Torcz at 02/13/2018 - 09:24

On Tue, Feb 13, 2018 at 07:16:01AM +0000, Vascom wrote:
I see the same with my "maradns". GIT shows version bump in spec,
but there is no build in Koji.

Re: Mass Rebuild for Fedora 28

By Dennis Gilmore at 02/13/2018 - 11:32

On February 13, 2018 8:24:12 AM CST, "Tomasz Torcz