DevHeads.net

Postings by Florian Weimer

%{valgrind_arches}

I had occasion to look at the valgrind use in spec files because we
might have an architecture regression downstream. I noticed that a lot
of packages have hard-coded lists of architectures on which valgrind is
available.

glibc 2.28 rebase has landed in rawhide

rawhide has been updated to glibc 2.28.

I do not expect any issues because we have been importing development
snapshots during the past six months, but if there any, please let us
know ASAP.

Thanks,
Florian

Guideline change: glibc malloc as the C/C++/Rust allocator

I would like to request a change of the Packaging Guidelines, advising
packagers not to interpose malloc.

The reasons are:

* We have resources to support glibc malloc, but not for other mallocs.
* Other mallocs do not follow ABI and provide insufficient alignment.
* Choosing a malloc is workload-dependent and forcing a non-default
malloc takes options away from system administrators.

This does not concern other allocators, such as Boehm GC or APR, only
the standard malloc interfaces.

Comments?

Thanks,
Florian

glibc license updates

I updated the License tag in the RPM file to match reality more closely:

# In general, GPLv2+ is used by programs, LGPLv2+ is used for
# libraries.
#
# LGPLv2+ with exceptions is used for things that are linked directly
# into dynamically linked programs and shared libraries (e.g. crt
# files, lib*_nonshared.a).

Running “telinit u” on glibc update

In Fedora, for historic reasons, we run “/sbin/telinit u” after
installing a new glibc RPM package version.

Does this still make sense? Should we remove the code which invokes
telinit from the glibc package?

Thanks,
Florian

armhfp builder instability

Lately, I've seen quite a few spurious build failures.

Fedora 27 kernel updates make system unbootable (sort of)

I'm trying to pin down what exposed this bug:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1569970" title="https://bugzilla.redhat.com/show_bug.cgi?id=1569970">https://bugzilla.redhat.com/show_bug.cgi?id=1569970</a>

The immediate trigger seems to be that all shutdowns on my system leave
the XFS root file system in an unclean state, so that GRUB cannot read
recently written files under /boot (assuming that /boot is on the same
file system).

Since GRUB does not deal with the XFS journal, the effect is that the
system is unbootable until you mount / and trigger journal recovery,
after which everything is fine again (because the files in /boot are
only written to rarely).

Any ideas what could cause t

Recommended way to pass CFLAGS/LDFLAGS through libtool

Is there a recommend way to get libtool to pass through all flags
specified in CFLAGS and LDFLAGS unchanged, and have the GCC compiler
driver sort out which flags to pass to the compiler/assembler/linker?

Thanks,
Florian

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

I'm trying this, on a relatively up-to-date Fedora 27 machine
(mock-1.4.9-1.fc27.noarch):

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
@buildsys-build
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?

Thanks,
Florian

-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="https://src.fedoraproject.org/rpms/glibc/pull-request/5" title="https://src.fedoraproject.org/rpms/glibc/pull-request/5">https://src.fedoraproject.org/rpms/glibc/pull-request/5</a>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1380878" title="https://bugzilla.redhat.com/show_bug.cgi?id=1380878">https://bugzilla.redhat.com/show_bug.cgi?id=1380878</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.

3.

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
versions.

Are cross-architecture Obsoletes: supported in any way?

src.fedoraproject.org pull request merging

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

<a href="https://src.fedoraproject.org/rpms/glibc/pull-request/3" title="https://src.fedoraproject.org/rpms/glibc/pull-request/3">https://src.fedoraproject.org/rpms/glibc/pull-request/3</a>

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


Waiting

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

Your task is currently PENDING

Thanks,
Florian

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
paravirtualization..

Is this still needed? Can we drop it?

Thanks,
Florian

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.

Thanks,
Florian

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="https://kojipkgs.fedoraproject.org//packages/highlight/3.39/1.fc27/x86_64/highlight-3.39-1.fc27.x86_64.rpm" title="https://kojipkgs.fedoraproject.org//packages/highlight/3.39/1.fc27/x86_64/highlight-3.39-1.fc27.x86_64.rpm">https://kojipkgs.fedoraproject.org//packages/highlight/3.39/1.fc27/x86_6...</a>
/bin/lua
config(highlight) = 3.39-1.fc27
libc.so.6()(64bit)

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
packages.

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="https://koji.fedoraproject.org/koji/getfile?taskID=20584916&amp;volume=DEFAULT&amp;name=build.log&amp;offset=-4000" title="https://koji.fedoraproject.org/koji/getfile?taskID=20584916&amp;volume=DEFAULT&amp;name=build.log&amp;offset=-4000">https://koji.fedoraproject.org/koji/getfile?taskID=20584916&amp;volume=DEFAU...</a>
(stuck at wcsmbs)

<a href="https://koji.fedoraproject.org/koji/getfile?taskID=20592419&amp;volume=DEFAULT&amp;name=build.log&amp;offset=-4000" title="https://koji.fedoraproject.org/koji/getfile?taskID=20592419&amp;volume=DEFAULT&amp;name=build.log&amp;offset=-4000">https://koji.fedoraproject.org/koji/getfile?taskID=20592419&amp;volume=DEFAU...</a>
(stuck at symlink.list)

<a href="https://koji.fedoraproject.org/koji/getfile?taskID=20592419&amp;volume=DEFAULT&amp;name=build.log&amp;offset=-4000" title="https://koji.fedoraproject.org/koji/getfile?taskID=20592419&amp;volume=DEFAULT&amp;name=build.log&amp;offset=-4000">https://koji.fedoraproject.org/koji/getfile?taskID=20592419&amp;volume=DEFAU...</a>
(stuck at PluginFrame_test)

<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=20583725" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=20583725">https://koji.fedoraproject.org/koji/taskinfo?taskID=20583725</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="https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels" title="https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels">https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels</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
redhat-rpm-config.

Thanks,
Florian

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
warning:
/var/lib/mock/fedora-25-x86_64/root/var/cache/dnf/updates-87ad44ec2dc11249/packages/util-linux-2.28.2-2.fc25.x86_64.rpm:
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.

Comments?

Thanks,
Florian