Postings by =?UTF-8?Q?Tomasz_K=C5=82oczko?=

Using %verify and %ghost and other issues for mass cleanups


Looks like I found something to do for someone with proven packager
privileges (which allow straight modify of any Fedora package git repo
without asking package maintainer to do modification).
Submitting hundreds of separated PRs for all below cases does not make to
much sense and totally will consume few man/days and with proven packager
privs it should take minutes.

*!) (over)use %veryfy() with %ghost*

Just results of two commands:

[tkloczko@domek SPECS.fedora]$ grep %ghost * | grep %verify | awk -F:
'{print $1}' | sort | uniq | wc -l
[tkloczko@domek SPECS.fedora]$ grep %ghost *

Loopy rpm subpackages dependencies


Just found that on some minimal system it is not possible to remove some
rpm subpackages.

* Current state

# rpm -qa | grep rpm

python3-rpm is required by dnf so it is really hard to have manageable
system without that part (however in extreme cases it is still possible to
drop completely dnf).

Problem is that on minimal system rpm-sign-libs and rpm-build-libs
theoretically should be not needed, however becaus

More than 10% of all Fedora spec files are not POSIX sh compliant

Just FTR:

[tkloczko@domek SPECS.fedora]$ egrep -w "popd|pushd" * -l| wc -l

Looks like many Fedora packagers forgot that ..

[tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell

I'm not sure is it would be good to post full list of all spec files here ..


Dead packages are still in rawhide tree

SO for example few days ago mongodb has been officially removed from Fedora
and in git repo is only dead.package file:
<a href="" title=""></a>

However binary and source packages are still in public repository:
<a href="" title=""></a>

The same situation is with few hundreds of other packages.


Question about gcc test suite failures

Recently I've been trying to trace some gcc issue so I've downloaded my gcc
src.rpm to try to build my own package.
During review build log I found a lot of test suite failures.
Initially I've been thinking that something is wrong with my devel env so
I've peaked on official gcc build logs and I found that I have even less
such failures than number of such issues on rawhide builders.

Mine package:

$ grep ^FAIL: -c gcc.out


FC30 Mass Rebuild still not finished


Looks like MR which started two weeks ago still is not fully finished.
Below command has been executed in mirrored rawhide source packages tree.

[tkloczko@domek fedora]$ for i in fc{21..30}; do echo "$i $(ls -1
*/*$i.src.rpm | wc -l)"; done; echo; ls -1 ?/*|wc -l
fc21 16
fc22 15
fc23 21
fc24 80
fc25 12
fc26 61
fc27 79
fc28 223
fc29 14133
fc30 25760
[tkloczko@domek fedora]$ find .

langpacks (Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks)

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

Last dbus upgrade issues

After last dbus upgrade gdm found that is not able to start.
NM basen network configuration as well is broker because it needs dbus as
well which is not starting.
So many dependencies on dubs looks really terrible/strange/dangerous IMO.

So far found that /ust/lib/tmpfiles.d/dbus.conf does not point to /run/dbus.

Can someomeon tell what needs to be done to bring system to usable state?

Level of the verbosity messages written to system logs about what and by
what failed is close to nothing.

BTW when gdm fails console is completely blocked.

: broken fedpkg


As in is in subject

$ fedpkg
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/fedpkg/", line 84, in
AttributeError: 'Namespace' object has no attribute 'command'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/bin/fedpkg", line 11, in <module>
load_entry_point('fedpkg==1.33', 'console_scripts', 'fedpkg')()
File "/usr/lib/python3.6/site-packages/fedpkg/", line 89, in
(client.args.command.__name__, e))

dnf and deltarpm (Was: Re: Fedora rawhide compose report: 20180529.n.0 changes)

On 29 May 2018 at 15:49, Fedora Rawhide Report < ... at fedoraproject dot org>

Sliming down kernel and provide more as modules (Was: Re: Fedora28 / autofs&NFS)

On 9 April 2018 at 07:24, Peter Robinson < ... at gmail dot com> wrote:
Just checked what is in kernel configuration and seems ATA driver IS
compiled statically into the kernel =:-o

Re: Removal of BuildRoot

On 16 February 2018 at 15:50, Stephen John Smoogen < ... at gmail dot com> wrote:

Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

BTW some massively occurring errors in really big number Fedora of specs.

Looks like many people don't know that %files entry like:


does not include /some/directory into package but all files and
subdirectories which are in /some/directory.

This is in how many specs such lines are used:

[tkloczko@domek SPECS.fedora]$ grep ^%\{.*\/$ * | grep -v __ | awk -F\.
'{print $1}' | uniq| wc -l

There is

[tkloczko@domek SPECS.fedora]$ grep ^%\{.*\/$ * | grep -v __ | wc -l

such entries in all fedora spec files.

What it is causing such mistake everyone can check by execu

Re: cmake, mc unresponsive packagers

On 30 January 2018 at 21:32, Tomasz Kłoczko <kloczko. ... at gmail dot com>

One more time I'm asking for contact cmalke and mc maintainers.


gnome crashes after today upgrade


Looks like today updates are trashing gnome almost completely.
gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..

"journalctl -xe" output is in attachment.


broken terminfo database in latest ncurses?


Just applied all recent updates and seems after this now mc is not able
recognize correctly number of available colors on gnome-terminal and xterm,
and on gnome-terminal cursors are not working now.

$ rpm -q --changelog ncurses-base | head -10
* Tue Jan 30 2018 Miroslav Lichvar < ... at redhat dot com> 6.1-2.20180129
- update to 6.1-20180129
- use macro for ldconfig scriptlets

* Mon Jan 29 2018 Miroslav Lichvar < ... at redhat dot com> 6.1-1.20180127
- update to 6.1-20180127

* Thu Nov 30 2017 Miroslav Lichvar < ... at redhat dot com> 6.0-15.20171125
- update to 6.0-20171125 (CVE-2017-16879)


net-snmp, cmake, mc unresponsive packagers

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

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

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

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

In case of mc there is no contact with maintainer since my last mc updates
(May 2017)


Missing step in orphaning package process? (Re: kernel component on bugzilla and call for "old bugs hunting season" to open)

Trying to look on one of the top tickets found:

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

Looks like this ticket is about package which is no longer in Fedora.

Does it mean that current Fedora package orphaning process is not closing
all such package tickets in Bugzilla?
If yes it will be some number of the tickets which is possible to close now


kernel component on bugzilla and call for "old bugs hunting season" to pen


In last two years, I've created something between 10 to 20 tickets against
the kernel.
Today after reboot on latest rc9 I found OOPS in dmesg and as usually, my
first thought was "raise the ticket".

net-snmp unresponsive maintainer


I'm following <a href="" title=""></a>

I'm asking for any reaction on:
<a href="" title=""></a>
<a href="" title=""></a>

List of proposed changes is quite long.

* Thu Dec 28 2017 Tomasz Kłoczko < ... at fedoraproject dot org> - 1:5.7.3-29
- removed Group fields
(<a href="" title=""></a>)
- remove all legacy hacks for Fedora older than 25
- remove chkconfig, initscripts and coreutils from Requires (no longer needed)
- remove man pages .

EPEL analyse/observation, some question, PR proposals/questions and more ..

As preface some oneliner result:

[tkloczko@domek SPECS.fedora]$ for i in el4 el5 el6 el7 rhel centos epel;
do echo -n "$i "; grep '%{?'$i * | wc -l; done
el4 10
el5 243
el6 265
el7 281
rhel 5428
centos 239
epel 45

1) Shortly I'm going to create PR with mass change request to remove all
EL4 and EL5 conditional builds as EL{5,6} are no longer supported.

2) Looks like in recent months number of new/updated EPEL EL6/EL7 packages
dropped down to between few to about 20 a month with sometimes tents
thousands a month Fedora updates on master weight/cost of all EPEL %ifings
is few magnitudes higher

Things which are on collision course between Fedora and RHEL/EPEL on master branch

Just for the record list of things which are now on crash course with
EPEL/RHEL Fedora which are widely used in Fedora specs:
On EPEL/RHEL in spec must be present in spec:
- BuildRoot
- %clean
- %defattr() in %files

NO ONE adds now any %ifings around those parts of the specs (just please do
not propose start doing this

Looking for contact with Daniel Veillard libxml2 maintainer


I'm trying to follow procedure described on
<a href="" title=""></a>

Daniel seems is not responding for quite long time.
In case of the tickets which I've created it is almost 3 weeks.
However I see in git unreplied pull request for more than 3 months.
Looks like maintainer is unresponsive.


Specs coding standard (Was: Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache)

On 3 January 2018 at 22:51, Adam Williamson < ... at fedoraproject dot org> wrote:
I'm not proposing such spec style guide in native language.
This could be done by simple indentation script over which must be
filtered every spec file.
I've already posted example of such script.

Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache


I'm trying to follow procedure described on
<a href="" title=""></a>

Description of the current state

At the moment more than many spec files have %post/%postu/%postrans
scriptles in which is done updating hicolor theme cache by calling:

gtk-update-icon-cache -f %{_datadir}/icons/hicolor

All those scriptles are no longer needed because in hicolor-icon-theme
package has file triggers updating theme cache on any change in single
dnf/rpm transaction.

$ rpm -q --filetriggers hicolor-icon-theme
transfiletriggerin scriptlet (using /bin/sh)

Re: RFC: -Wl,--as-needed by default (and glibc ldconfig file trigger)

So is it any final decision about start use by default --as-needed in
linker options?

Looking again on whole discussion across this thread and on
<a href="" title=""></a> I
don't see any arguments against start use --as-needed by default so
looks like only reason why such change still is not introduced is more
physiological than technical as such change will affect majority of
the packages in Fedora.

Mass issue: /usr/bin/env dependency

There are several issues with /usr/bin/env dependencies and all those issues are related to scripts which in script preamble are using
"#!/usr/bin/env <interpreter>":

- if some scrip is using env rpm package build procedure find requires scripts are not able to recognize that script is <interpreter>

%checks framework standardisation idea proposal (Was: Static libraries in Fedora distribution)

(And yet another resend as it has been send only privately)

Wow!! :)

But besides that the testsuite from Koji was + would be too unrealiable to