Postings by Florian Weimer

Debugging mock error “Failed to synchronize cache for repo 'updates'”

I'm trying this, on a relatively up-to-date Fedora 27 machine

mock -r fedora-28-x86_64 --init

and get:

Start: dnf install
Error: Failed to synchronize cache for repo 'updates'
WARNING: Machine 00b000ffcd4543ddbe52926cee6d50d5 still running. Killing...
ERROR: Command failed:
# /usr/bin/dnf --installroot /var/lib/mock/fedora-28-x86_64/root/
--releasever 28 --disableplugin=local --setopt=deltarpm=False install
Error: Failed to synchronize cache for repo 'updates'

And that's it. Adding -vv doesn't provide more information, e.g.

Improving the glibc32 situation

Some x86_64 packages need a 32-bit glibc during build time. Koji does
not provide it.

Unfortunately, there is no way to permanently block glibc32 from
entering composes. We have repeatedly asked for it. It simply does not
happen. If end users install glibc32, there system may be irrevocably
broken as a result.

A few of the current consumers are simply broken in the sense that they
really should build for i686 and get the package thorough the compose
process, instead of building a native x86_64 package.

Compile Fedora with auto-vectorization

Should we start compiling Fedora with auto-vectorization, either using
-O3 or -O2 -ftree-loop-vectorize?

Downstream experimented with that for POWER 7 (the ppc64p7 packages).
But if auto-vectorization is beneficial on POWER, it likely helps on
other CPUs as well, given that SIMD support is quite common nowadays.

I really want to avoid a package-specific flag because I don't think
discussions about per-package build policies are a good use of our time,
and dependency changes invalidate previous decisions based on package
use all the time.

Using LTO for Fedora package builds

Some packages use LTO (link-time optimization) with the GNU toolchain.

In the past, this was problematic because the generated debugging
information was not quite usable.

Change to linker flags injection (#1548397)

We currently inject “-z now” hidden behind a -specs= option for the gcc
compiler driver.

libtool and LDFLAGS build flags injection

I've seen a fair amount of LDFLAGS injection failures related to
libtool. For the most part,
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld is dropped, leading to a
lack of BIND_NOW in the resulting binary.

Is there a way we can fix this in libtool or the auto* tools? I'm also
considering moving -Wl,-z,now to the command line from the GCC specs
file, which might help here, too.

Build flag injection for qmake

I have a package which indirectly calls qmake (from Qt5). Is there a
way to inject the standard build flags using environment variables, or
do I have to patch the invocation of the qmake command itself to pass
the flags, similar to what %{qmake_qt5} does?

Would it make to add rpmbuild-qmake or something similar to
qt5-rpm-macros which get the build flags from CFLAGS/CXX/FLAGS/LDFLAGS
and pass it to qmake?


-z defs linker flag activated in Fedora rawhide

I updated redhat-rpm-config to instruct ld to reject linking shared
objects with undefined symbols. Such undefined symbols break symbol
versioning because the are not necessarily bound to the correct symbol
version at run time. (rhbz#1535422)

### Disable strict symbol checks in the link editor (ld)

By default, the link editor will refuse to link shared objects which
contain undefined symbols. In some cases (such as when a DSO is
loaded as a plugin and is expected to bind to symbols in the main
executable), undefined symbols are expected.

RPM packaging and ldconfig handling

The glibc team has received a request to change the way ldconfig
invocations during package installations and deinstallations are handled.

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

Some background: ldconfig serves several functions. Key aspects are:

1. Speed up programing loading.

2. Enable the dynamic linker to load libraries by their soname.


Enabling smoother upgrades in the face of multilib compose changes

Changes in the Fedora releng dropped glibc-headers.i686 from the x86_64
compose after the Fedora 26 release. This is not in itself a problem
(glibc-devel.i686 is fine if its dependency is matched by
glibc-headers.x86_64). However, I have received a report that an
installed glibc-headers.i686 package prevents upgrades to newer glibc

Are cross-architecture Obsoletes: supported in any way? pull request merging

How is this supposed to work? I clicked on Merge in:

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

But the task remains in the PENDING state, apparently indefinitely:


We are waiting for your task to finish. This page should be refreshed
automatically, but if not click Here

Your task is currently PENDING


F26/F27 updates-testing and multilib problems

Are there currently bugs in composes for x86-64 for F26/F27?

i386 Xen PV support still needed?

We still build a special glibc variant for Xen which avoids certain
segment-relative accesses which are difficult to emulate with

Is this still needed? Can we drop it?


debuginfo repository matching f27-build

Is there are debuginfo repository matching the contents of the f27-build
buildroot repository?

This would be extremely helpful for verifying the presence of .gdb_index
sections in separate debugging information.


RPM dependency generator picks up shbang lines in /usr/share/doc

highlight-3.36-3.fc27 suddenly has a Requires: /bin/lua:

$ rpm -qp --requires
<a href="" title=""></a>
config(highlight) = 3.39-1.fc27

I have verified that this comes from the
/usr/share/doc/highlight/examples/json/theme2json.lua file installed by
the package.

The immediate result is that highlight is uninstallable because nothing
provides /bin/lua.

f27-override tag for glibc-2.25.90-29.fc27

Would the person who tagged glibc-2.25.90-29.fc27 into f27-override be
so kind and remove that tag? I need glibc-2.25.90-30.fc27 to be able to
build curl, which is needed to fix cmake, which in turn will fix a
couple of FTBFS errors on ppc64le.

Please contact some of the toolchain folks before tagging toolchain

Recompiling/relinking dependent applications/libraries on DSO change

binutils 2.29 introduced an optimization which requires that in the
general case, applications and libraries linking against a DSO will have
to be rebuilt when the DSO change the implementation of functions (i.e.,
changes to a function body can change ABI).

Rawhide s390x builders hanging in random places

It seems that the rawhide s390x builders hang in various different
places, randomly:

<a href=";volume=DEFAULT&amp;name=build.log&amp;offset=-4000" title=";volume=DEFAULT&amp;name=build.log&amp;offset=-4000">;volume=DEFAU...</a>
(stuck at wcsmbs)

<a href=";volume=DEFAULT&amp;name=build.log&amp;offset=-4000" title=";volume=DEFAULT&amp;name=build.log&amp;offset=-4000">;volume=DEFAU...</a>
(stuck at symlink.list)

<a href=";volume=DEFAULT&amp;name=build.log&amp;offset=-4000" title=";volume=DEFAULT&amp;name=build.log&amp;offset=-4000">;volume=DEFAU...</a>
(stuck at PluginFrame_test)

<a href="" title=""></a>
(stuck who knows where)

I don't know if this is an issue with the main

No i686 kernel: Can we require SSE2 for i686?

I ran into this unannounced change:

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

If this is accepted, all x86 hardware on which Fedora can run will
support SSE2, and we should reflect that in the i686 build flags.

How likely is it that this proposal is accepted? Ideally, we would know
this before the mass rebuild so that we can change the compiler flags in


Fedora 27 mass rebuild at risk

We currently have an invalid IFUNC resolver in libgcc.a on POWER
(rhbz#1467526). glibc in rawhide recently started linking that into the
library and there are significant problems with that (rhbz#1467518).

I'll be on PTO next week, and it does not seem likely that this is going
to be resolved upstream before that.

Fedora 25 mock failure

On Fedora 25 x86-64, I get a strange mock failure:

$ mock -r fedora-25-x86_64 --scrub all
$ mock -r fedora-25-x86_64 --init
Header V3 RSA/SHA256 Signature, key ID fdb19c98: NOKEY
Importing GPG key 0x81B46521:
Userid : "Fedora (24) <fedora-24- ... at fedoraproject dot org>"
Fingerprint: 5048 BDBB A5E7 76E5 47B0 9CCC 73BD E983 81B4 6521
Key imported successfully
Import of key(s) didn't help, wrong key(s)?

Are partial upgrades expected to work in rawhide?

We received a bug report that generated RPM dependencies are too coarse
in rawhide (#1409557).

The bug report is correct at a technical level. But I assumed that it
was not a problem because partial upgrades are in rawhide are not
supported—it's always all-or-nothing.



Best practices for getting CFLAGS/LDFLAGS etc.

The final values of CFLAGS/LDFLAGS/… are set (as shell variables) by the
%configure macro. There is no other immediately obvious way to get
those definitions.

Interpreting FAF reports

Any idea what this is about?

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

To me that looks like a combination of several factors. First of all,
the backtrace generation likely used incorrect debuginfo data because
the backtrace is impossible.

Support for older kernels

Do we need to support running current Fedora releases in kernels which
are older than the initial Fedora kernel for that release?

If yes, what are the kernel baselines?

getentropy and getrandom coming to glibc in Fedora rawhide

glibc-2.24.90-23.fc26 in rawhide is the first version which adds
getentropy and getrandom. (The ppc64 build is still running, but I
assume it will complete eventually.)

The implementation resides in the new <sys/random.h> header. As this is
not a POSIX header, no feature test macros are required. getentropy is
intended for seeding a PRNG (such as RAND_bytes in OpenSSL). getrandom
is the lower-level system call wrapper.

The implementation does not have any protection against symbol
interposition because I could not get that approved upstream.

Status of microcode updates

We would like to enable hardware-assisted lock optimizations in glibc on
multiple architectures. In general, this feature works only on
production hardware with current firmware, and not on pre-production
machines some vendors provide for architecture bringup.

Are the Fedora builders using hardware with support contracts, and are
vendor firmware updates applied occasionally, so that we can rely on
what the CPU/firmware reports about CPU features?

Wiki page subscription

On the Fedora wiki, I can subscribe to certain pages. I did that, but I
did not receive any notifications when they were edited. I have added
“Wiki edits” under the “Events referring to my username” filter (which
was quite close to the default before that), and I get notifications for
my own edits, but not for page subscriptions.

Then I created a new completely filter, containing only “Wiki edits”.

Should we stop stripping static libraries?

We currently call /usr/lib/rpm/brp-strip-static-archive from
%__os_install_post. This removes debugging symbols from static (.a)

Is this really a good idea? Due to this, glibc copies libc.a to
glibc-debuginfo, so that you can get a link with debugging symbols by
specifying “-static -L/usr/lib/debug/usr/lib64“ (potentially with
unintended side effects).

Slow configure scripts

I recall some reports that configure scripts are really slow in recent
Fedora versions due to pervasive use of BIND_NOW.

Has anyone investigated this further? Is there a bug report somewhere?