Postings by David Howells

The Fedora Packaging Guidelines point at the old FHS site


The packaging guidelines pages:

<a href="" title=""></a>
<a href=";oldid=528452#Filesystem_Layout" title=";oldid=528452#Filesystem_Layout">;oldid=5...</a>

still point at the old Filesystem Hierarchy Standard (FHS) site:

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

This hasn't been updated since something like 2004.

The FHS is now maintained by the Linux Foundation:

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


How to install a mountpoint directory from an rpm?


I need to install a directory (/afs) that will be a mountpoint that a systemd
service (also installed in the rpm) will mount upon.

What's the best way to encode this in the specfile?

I did have:


but that doesn't upgrade correctly. Someone gave me another way to do it:

%systemd_post afs.mount

# Create /afs directory if it doesn't exist
if [ !

Is there an independent lib for parsing Kerberos config files?


I've made the keyutils package use the profile parsing routines from the
-lkrb5 library (the config data I need to parse is from an external source, so
the format is already set).

Debuginfo exclusion list?

Hi Mark,

Is it possible to specify from a specfile an list of files and/or directories
in the installation output that should be ignored for the purposes of
debuginfo extraction? If not, can this be added?

I maintain cross-gcc and there are some files that get
installed that must not be stripped.

How to fix 'E: hardcoded-library-path in /usr/lib/debug"' in cross-gcc?


When creating an update for cross-gcc, I see:

cross-gcc.src:388: E: hardcoded-library-path in /usr/lib/debug"

from dist.rpmlint.

cross-gcc's spec file does stuff to /usr/lib/debug because it's a compiler and
the debuginfo shouldn't be extracted from some of the compiled bits it ships
with (crt*.o files and libgcc archives, for example).

Is there a right way to do this so as not to incur the above error?

I imagine the same problem occurs in gcc also since I copied the debuginfo
extraction code from there.


Is it possible to manually insert shared library deps in an RPM?


gcc and cross-gcc currently dynamically load the isl-0.14 shared library -
which means that rpm-build doesn't automagically detect a:

but, rather, the gcc binary rpm must include a:

Requires: isl = %{isl_version}


Is it possible to instead do something like:


(though this doesn't work because it complains about an illegal char) so that
it is pegged to the major version of the library rather than the specific isl


How to obsolete a subpackage?

I need to obsolete one of the arch subpackages in the cross-binutils rpm (and
also in the cross-gcc rpm) because binutils no longer supports that arch

Just marking the appropriate subpackage as obsoleted in the specfile for the
cross-binutils-common subpackage causes dnf to complain:

warthog>sudo dnf upgrade ./noarch/cross-binutils-common-2.27-1.fc26.noarch.rpm ./x86_64/binutils-*
Last metadata expiration check: 0:20:38 ago on Wed Sep 14 15:06:27 2016.
Error: package binutils-sh64-linux-gnu-2.26.1-1.fc24.x86_64 requires cross-binutils-common = 2.26.1-1.fc24, but none of the providers

How do avoid "hardcoded-library-path in /usr/lib/debug" from rpmlint


In cross-gcc, the specfile needs to do its own debuginfo manipulation because
it has binary files that must not be stripped inside the package - and
preferably must not even be looked at by the manipulation tools because they
are likely to be for a completely different target to the system toolchain.

However, rpmlint objects to the script with:

cross-gcc.src:381: E: hardcoded-library-path in /usr/lib/debug"

how do I avoid this? This ought to affect the system gcc package also since I
copied the script from there.


rpmlint vs zero-length files


How do I prevent rpmlint from objecting to some specific zero-length files?

I'm building a bunch of cross-compilers, and the installation includes some
zero-length files that appear to have to be there, but are zero-length (and in
some cases look like they have to be empty).

gcc-h8300-linux-gnu.armv7hl: E: zero-length /usr/lib/gcc/h8300-elf/5.3.1/install-tools/macro_list
gcc-h8300-linux-gnu.i686: E: zero-length /usr/lib/gcc/h8300-elf/5.3.1/install-tools/macro_list
gcc-h8300-linux-gnu.x86_64: E: zero-length /usr/lib/gcc/h8300-elf/5.3.1/install-tools/macro_list

Installation of symlinks - should wrapper scripts be used instead?

I maintain the cross-binutils and cross-gcc packages. These produce powerpc64
subpackages with binaries in. However, since I was asked to provide support
for ppc64-linux-gnu-x in addition to powerpc64-linux-gnu-x commands, I provide
symlink rpms for the ppc64 name that link to the former name.

This, however, seems to go messily wrong if a symlink is being installed to a
filename that is already populated with a file. It appears that the symlinks
so far installed don't get cleaned up.

Would it be better to install wrapper scripts instead?


How to package python extensions that need a special preprocessor?


I'm trying to package a python module that has a C extension that has a
special preprocessor that turns protocol definition files into C.

Currently, I have a makefile that calls the rxgen program[*]:

./rxgen/ rpc-api/*

which produces four C files (afs_xg.[ch] and afs_py.[ch]) that then get
compiled and linked together with some other sources into an extension module:

from distutils.core import setup, Extension

setup(name = "kafs",
version = "0.1",
description = "AFS filesystem management scripting and commands",
author = "David Howells",

Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?

It's taken quite a long time to sort out the bugs in gcc-5 with regard to
lesser-used arches, so I've only just managed to get cross-gcc in rawhide
upgraded to gcc-5, despite the main gcc package having got there a while ago.

Is it too late in the F22 cycle now to upgrade cross-gcc there to gcc-5? I'm
not entirely sure what depends on it or how to find out?


Can rpmbuild produce a 'build logs' rpm also?

Can rpmbuild be taught to produce a 'build logs' rpm (or tarball or something)
that isn't automatically added to the installation set by koji/bodhi and that
can get generated even in the event of a build failure?

I have seen two examples of where this could be useful:

(1) gcc-5 dumps a whole chunk of tar'd, bzip'd and uuencoded testing logs to
stdout because it has nowhere else to put them.

(2) I'm seeing a config failure building cross-gcc on ARM that doesn't occur
on x86_64 or i686 - but it happens in koji where I can't get at the
config.log to see what happened.


Upgrading cloog to 0.18.1 for {,cross-}{gcc,binutils}

Would there be any problem with upgrading cloog to 0.18.1 so that binutils,
gcc, cross-binutils and cross-gcc can use it? Also, should I put isl-0.12.2
into it's own package or should it be added to cloog?

Or should I make a gcc-cloog (and gcc-isl)?


What are the ELF shared lib symbol versioning best practices?

Is there a good description of ELF shared library symbol versioning best
practices somewhere?

In particular, under what conditions do you need to create a new section in
the versioning file given to the linker's --version-script option when new
symbols are added?

And what do you do if you've done it wrong?

For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when
I should perhaps have created KEYUTILS_1.5 and added them there:

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

I have been given a patch

The xtrace package needs to be removed from Fedora


The xtrace package has been renamed to the x11trace package due to a collision
with the name of a glibc tool. The xtrace package should now be removed from

I can see a "fedpkg retire" option for removing it from Rawhide, but is it
possible to remove it now from F21 and earlier?


cross-gcc is updated to gcc-4.9.0 in updates-testing for F19+

So anyone that is using it to build their own packages, if you could check it
in the next three weeks.


Odd debugedit message: -b arg has to be either the same length as -d arg, or more than 1 char longer

I'm seeing this message:

extracting debug info from /home/dhowells/rpmbuild/BUILDROOT/cross-gcc-4.9.0-2.fc21.x86_64/usr/lib/gcc/hppa-linux-gnu/4.9.0/
/usr/lib/rpm/debugedit: -b arg has to be either the same length as -d arg, or more than 1 char longer

but only on some machines. Anyone know what it portends?

on both machines I've tried it on.


Announcing an X11 protocol tracing package

xtrace, an X11 protocol tracing package that is already available in Debian is
now also available in updates-testing for F20 and Rawhide.

xtrace-1.3.1-5.fc20 newpackage testing 2014-03-30

This is used by running a program under xtrace, eg:

xtrace xterm

The xtrace program then acts as a dummy/proxy X server to the program it runs,
setting DISPLAY appropriately. It can also be run as a standalone proxy for
processes to connect to:

xtrace -D :9

The output appears on stderr or can be dumped into a file.

Is it impossible to use the same build override twice with bodhi?

I need to update my cross-gcc package, but that depends on my cross-binutils
package which is still in updates-testing (should the build process fail, even
though it is pushed to updates-testing?).

To do this I need to add a build override with bodhi for the cross-binutils
package - however, this doesn't work, presumably because I've added it before
and the override has now expired.

If I try adding the override, I see:

warthog>bodhi -r F16 -o cross-binutils- -N "Required to build cross-gcc"
Error: buildroot override for u'cross-binutils-' already exists

How do you use fedpkg chain-build for released Fedorae?


I'm having a problem building my cross-compiler gcc package as it requires a
cross-compiler binutils package to be built first.

I managed to build the rawhide build with:

fedpkg chain-build --target=rawhide cross-binutils :

but chain-build doesn't work for F16 and F17 as far as I can tell.

Need some advice on best packaging practices for a tricky package?


I've produced a pair of specfiles that I'm aiming to get into Fedora that take
the standard Fedora binutils and gcc SRPM sources and patches and produce a
series of cross-compilation binutils and gcc RPMs for all the Linux kernel
arches that I can manage to get working.

The inclusion request BZs can be found here:

cross-binutils: <a href="" title=""></a>
cross-gcc: <a href="" title=""></a>

However, there are a number of warnings that rpmlint produces that I'd like
some advice on.

How to prevent a binary from being stripped by rpmbuild?


How do I prevent rpmbuild from attempting to strip a particular binary? The
problem is that the binary was cross-compiled and is not of the same
architecture as the normal Fedora binutils. Thus the strip program used (from
the wrong binutils) appears to corrupt the binary.


The Fedora build system and the use of %{_unitdir} in specfiles


I'm trying to build the latest cachefilesd package in the Fedora build system
for Rawhide/F17, but the build failed because I used %{_unitdir} in my specfile
and this doesn't appear to be expanded in the Fedora build system (see the
attached build.log). For reference, the build log can be found at:

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

I was attempting to use this to determine the location of the systemd service
definitions. It works fine on my F16 desktop.

Can this be fixed in the build system, please?

What's the best way to compare dotted version strings from a script?

Is there a program or script installed/installable by Fedora that can be used
to compare dotted version strings (eg. "1.5.2") from a shell script?


To Require or not to Require?


I have a package (keyutils) that produces three RPMs: keyutils (programs),
keyutils-libs and keyutils-devel.

Putting cross compilers into Fedora

Would it be worth our while putting into Fedora basic gcc and binutils rpms
for cross compilers for all the Linux arches? I keep finding the need to
compile kernels for arches other than the x86_64 boxes I normally use, and I
keep borrowing prebuilt compilers off others (usually Al Viro - thanks Al!) to
do this.

However, as the kernel advances, older compilers cease being able to compile
it, so I have to go finding new compilers again.

It would be much easier if I could just yum install them.

Any thoughts on whether it would be worthwhile?