Postings by Adrian Reber

Orphaning jabberd

I just orphaned jabberd on all branches as I just stopped my last
instance of jabberd and upstream seems to have stopped development.


libcdio soname bump in rawhide

libcdio upstream released the 2.0 version a few weeks ago and I will
updated rawhide to the latest libcdio version. It comes with a new
soname and I will also rebuild all dependencies.


CentOS HPC SIG first meeting (2017-10-19)

Now that the HPC SIG exists for a few months I would like to hold our
first meeting. My main goal is to give an overview of what has happened
in the last months and what will/should happen next.

Time/Date: 1500 UTC - Thursday (2017-10-19) (date -d "1500 UTC")
Where: IRC- Freenode - #centos-devel

* overview
* current status
* packages and build system
* CI integration
* future plans
* architectures
* CI plans
* open floor


libcdio soname bump in rawhide

Recently libcdio upstream released a new version of libcdio. I will
update rawhide to this latest libcdio version and rebuild all


Switching bogofilter from db4 to db5

A bug was opened against bogofilter asking why it still uses db4 instead
of db5:

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

I never changed the BRs because it works and I was never sure how the
upgrade from db4 to db5 would impact the database format of the
bogofilter wordlist.

I just tried to build bogofilter locally against db5 and it still just
works. I can read and write the bogofilter wordlist with both binaries
without a problem. So it seems the on-disk-format of db4 and db5 is the
same or at least compatible.


I am planning to orphan the IRC client ninja. One of the reasons to
orphan it is that there is a build system[1] which has the same name.
In Fedora the ninja build system is called ninja-build which makes it
incompatible with most other Linux distributions[2]. In addition the
current release is from 2002 and upstream does not exist anymore.
Most of the other Linux distributions do not even ship it, although
there are other packages which are called ninja.

libcdio updated to 0.93

libcdio has been updated to 0.93 in rawhide. As always this includes a
new soname. All dependencies have been rebuilt.


libcdio 0.90 update in rawhide

Some weeks ago libcdio 0.90 has been released. In addition to the
libcdio-0.90 release there have been parts split off into a separate
package called libcdio-paranoia. libcdio-paranoia has been imported and
I will now also update libcdio to 0.90 in rawhide. I will rebuild all
dependencies over the next few days and adjust the depending packages to
require both libraries where necessary.


gforth and gcc 4.7

Trying to build gforth with gcc 4.7 fails currently. The forth engine is
build but it fails its included tests. The problem is that every newline
the forth engine writes is replaced with 0x00 as seen in following diff:

0000010: 6566 696e 6564 2047 4458 2020 594f 5520 efined GDX YOU
0000020: 5348 4f55 4c44 2053 4545 2054 4845 2053 SHOULD SEE THE S
0000030: 5441 4e44 4152 4420 4752 4150 4849 4320 TANDARD GRAPHIC
-0000040: 4348 4152 4143 5445 5253 3a00 2021 2223 CHARACTERS:.

strange koji behaviour

I just tried to rebuild kover and it failed during build with a strange

<a href=";name=build.log&amp;offset=-4000" title=";name=build.log&amp;offset=-4000">;name=build.log...</a>

The reason for this error is, however, a broken dependency.

<a href=";name=root.log&amp;offset=-4000" title=";name=root.log&amp;offset=-4000">;name=root.log&amp;...</a>

I thought if something failed during setup of the buildroot it shouldn't
even start to build the package. This seems to be broken right now.

libcdio update coming to rawhide

I will soon update libcdio to 0.83 in rawhide which requires a rebuild
of following the packages:


I will rebuild these packages if the corresponding maintainers do not


something changed with provides/requires (probably new rpm???)

I was comparing a build of bind (bind-libs-lite). An older version
contains the files and the correct provides.

rpmbuild: Bad Requireflags: qualifiers: Requires(posttrans)

I was trying to do a scratch build an got following error:

error: line 78: Bad Requireflags: qualifiers: Requires(posttrans): /sbin/service

Is Requires(posttrans) deprecated with the newest RPM or is that a bug?

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


wordpress needs a new (co-)maintainer

After FESCO's decision that the wordpress package needs to unbundle the
included libraries nothing happened for over three months. The hope that
somebody would step up and claim wordpress in the FESCO ticket [1] did
not fulfill itself and therefore I am asking here for help or a new maintainer
for wordpress. As there have been no known security bugs I have not
updated wordpress since I opened the FESCO ticket and now wordpress
3.0 has been released.

libcdio update

I would like to update libcdio to the latest version (0.82). This
requires a rebuild of its dependencies:


If the maintainers of the above packages do not object I would do all
the necessary rebuilds.


Exception request from FESCo for bundled libaries

I was informed that wordpress uses bundled libraries and would like to
request an exception from FESCo.

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


id3lib stack smashing

There is ubuntu bug report against id3lib "libid3 crashes (stack
smashing) when reading VBR MP3 file"[1]. I am able to reproduce this on
ubuntu but not on Fedora and I do not understand why. The patch[2] looks
like it is doing the right thing but there is not stack smashing detected
using the Fedora version (even on ubuntu). I have looked at the ubuntu
build logs[3] and it uses completely different compiler flags.

Strange multilib conflict

Maybe somebody from this list can see the problem in this bug report,
because I am out of ideas:

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

A user is installing libcdio on rawhide and gets a file conflict on the
man pages when installing the x86_64 and i386 version at the same time.

I fixed it on my F8 test system and verified it by installing the libcdio
version from rawhide on that F8 system.

On the system of the bug reporter it still fails with the same error
message about a file conflict.

I think I have verified that the man pages in the x86_64 and i386
version of the package