DevHeads.net

Postings by Florian Weimer

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

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="https://retrace.fedoraproject.org/faf/reports/1154372/" title="https://retrace.fedoraproject.org/faf/reports/1154372/">https://retrace.fedoraproject.org/faf/reports/1154372/</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)
libraries.

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?

Thanks,
Florian

Private Bugzilla bugs

Why does Bugzilla allow filing private Fedora bugs?

I'm not sure who has the capability (it may be tied to specific
accounts). It is not all that helpful because accounts on the Cc: list
still receive notifications and can access the bug. Recipients of the
notifications may include public mailing lists.

How to package a Git repository

I would like to build (S)RPMs directly from a Git repository (which
contains the .spec file in the top-level directory). This is for a
CI-style project, with a quick release cycle.

I have a Lua script fragment which generates a proper SRPM with the
mock-scm target in COPR, and which is also compatible with “fedpkg
srpm”.

glibc subpackage changes

To implement some Fedora 25 changes (split NSS (Name Service Switch)
subpackages, libcrypt without NSS (Mozilla Network Security Services)
library depdencies), I added additional subpackages to the glibc
packages, namely:

- libcrypt
- libcrypt-nss
- nss_db
- nss_hesiod
- nss_nis

The expectation is that libgcrypt-nss is installed by default, and
system administrators may opt to install libcrypt (with the internal
algorithm implementations instead).

First stage of glibc recvmsg/sendmsg ABI revert landed in rawhide

glibc upstream, during development of the 2.24 release, introduced new
symbol versions ... at GLIBC_2 dot 24, ... at GLIBC_2 dot 24 (and
... at GLIBC_2 dot 24, ... at GLIBC_2 dot 24 on 64-bit architectures), in
order to fix some minor POSIX compliance issue. (POSIX and the Linux
kernel disagree about the width of some fields in struct msghdr.) These
changes landed in rawhide as part of glibc-2.23.90-19.fc25.

This change caused quite a few issues (chrony stopped building, Address
Sanitizer interception of these functions was affected, probably more).

Creating updates for Fedora 24

I'd like to push a glibc update to Fedora 24. It does not matter if it
goes into the release, it is just a collection of minor security fixes
and corrections to user-reported bugs. We are currently preparing an
update for Fedora 23 with similar content, and we want to avoid that an
update to Fedora 24 introduces regressions.

Is it safe to create the update in Bodhi, request a push to stable, and
release engineering will pick it up as they see fit?

Thanks,
Florian

Removal of type union wait from glibc in rawhide

glibc-2.23.90-9.fc25 removed the type union wait from its API. This
used to be a BSD compatibility extension, but it has long since been
removed from the BSDs. It was never part of the POSIX process
interfaces, and its implementation relies on GCC extensions.

If your package is portable to anything else than GNU/Linux (which
includes Android) and has a configure check for union wait, the
configure check will fail and the package will automatically switch to
the POSIX APIs (like it does everywhere else).

If your package fails to compile, you need to replace “union wait” with
“int”.

PATH contains at build time

May packages assume that /usr/sbin is on PATH when they are built?

If you need a program which is currently only in /usr/sbin, should a
package use an absolute path, or reset PATH to include /usr/sbin?

Thanks,
Florian

%post RPM scriptlets and dependencies

When a %post scriptlet runs, is it guaranteed that the Requires:
dependencies have been unpacked? I understand that for cycle-breaking
purposes, it may not be true that the scriptlets for dependencies have
run. But are the files already there?

(I'm interested in plain Requires, not Requires(post) etc.)

Has the behavior changed since RPM 4.8?

Thanks,
Florian

Self Introduction: Florian Weimer

I recently joined the Red Hat tools team, to work on glibc with Carlos
O'Donell. As a result, I will co-maintain glibc in Fedora.

Granting a capability to a service

Let's assume I want to start a service as an ordinary user, but allow to
bind it to a privileged port. The program implementing the service does
not manipulate capabilities in any way.

I came up with with this system unit for testing purposes:

[Unit]
Description=Test unit

[Service]
Type=oneshot
ExecStart=/usr/sbin/getpcaps self
Capabilities=cap_net_bind_service+ep
SecureBits=keep-caps
User=fweimer
StandardOutput=journal

However, this does not work, the capability set remains empty.

Why -mtune=atom?

The default CFLAGS set by RPM include “-mtune-atom”.

Why? I doubt Atom CPUs are Fedora's primary target. It's not even a
documented GCC option. There is such a wide variety of CPUs under this
label that it's not even clear what it would mean.

If it's better than “-mtune=generic” or the GCC default, shouldn't GCC
be fixed?