DevHeads.net

Postings by Florian Weimer

Remove sysctl function from glibc in rawhide?

I'd like to suggest to remove the sysctl function from glibc in rawhide
this week. It's been deprecated upstream, but I think it's more
convenient to us to remove it in a mid-year release cycle, separate from
the GCC rebase.

On some architectures (notable aarch64), the sysctl function is just a
stub because the kernel does not support the system call. This requires
the right magic configure checks (autoconf handles it correctly, others
do not). Some packages also have kernel (header) versions which are
quite broken (see openrdate).

Tagging commit hashes of Koji builds in dist-git

Is there a reason why we do not tag dist-git commits, using a name which
is derived from the NEVR from a Koji build?

How well does Git scale with thousands of tags?

Thanks,
Florian

Weak RPM dependencies which are not automatically re-installed on update

Is there a form of weak dependency which is installed when available,
but not automatically re-installed on each update?

If all the optional components are back after an update, that means that
it's quite hard to maintain a minimal system installation.

Thanks,
Florian

Replacing glibc langpacks

I'm investigating whether it makes sense to switch to a scheme where the
glibc locale data is built from source, during package installation,
based on the langpack configuration system. This is similar to what
Debian does.

The reason is that the compressed locale source code (without the
charmaps, which are not strictly needed once we patch localedef) is
smaller than the subset of locales of a langpack package which people
actually.

Bugzilla (?) component for Fedora cloud images

This bug

<https://bugzilla.redhat.com/show_bug.cgi?id=1691335>

is actually a documentation/configuration issue in the Fedora Cloud
images. However, I can't find a Bugzilla component for these images or
their documentation.

Bodhi updates permanently locked in PENDING

I need to make changes to these updates:

<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2018-2efb53dc71" title="https://bodhi.fedoraproject.org/updates/FEDORA-2018-2efb53dc71">https://bodhi.fedoraproject.org/updates/FEDORA-2018-2efb53dc71</a>
<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2018-0e5b278265" title="https://bodhi.fedoraproject.org/updates/FEDORA-2018-0e5b278265">https://bodhi.fedoraproject.org/updates/FEDORA-2018-0e5b278265</a>

They have been locked in the pending state for hours.

Multilib inconsistencies between fedora/updates/updates-testing composes

We have seen reports that glibc-headers.i686 comes and goes from the
x86_64 updates compose. Previously, we have seen this only for the
updates-testing compose: <https://pagure.io/releng/issue/7071>

This leads to a very bad update experience.

_performance_build and -O3 package builds

Downstream, we had a separate set of builds flags for certain packages
and used -O3 there, targeted at POWER (both ppc64 and ppc64le), for
increased use of vectorization presumably.

I don't think this was ever upstreamed to Fedora (the downstream changes
were in the redhat-rpm-config package). I don't recall seeing a
corresponding Fedora change.

Is Fedora 27 EOL?

There has been no EOL announcement, my guess for the EOL data
(2018-11-30) has not passed yet, but I get this when pushing to
src.fedoraproject.org:

remote: Running hooks for rpms/glibc
remote: Branch refs/heads/f27 is unsupported
remote: Denied push for ref 'refs/heads/f27' for user 'fweimer'
remote: All changes have been rejected

Is Fedora 27 EOL or not?

Thanks,
Florian

Commit notifications for Fedora dist-git

On src.fedoraproject.org, I selected “Watch Issues, PRs, and Commits”
for various packages and assumed that I would receive notifications for
new commits. But nothing arrives anymore, as far as I can tell.

Obviously, this is problematic if proven packages do uncoordinated
package changes.

What can we do here?

%{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?