Postings by Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?=

is anybody using fedora-loadmodules.service and fedora-readonly.service?

Two boot-time services provided by the venerable initscripts package:

– fedora-loadmodules.service: this loads kernel modules based on
configuration in /etc/rc.modules. Identical functionality is provided by
systemd-modules-load.service. (systemd-modules-load.service reads
modules-load.d directories and the kernel command line, not /etc/rc.modules).

Is anybody still using /etc/rc.modules?

plan to update F27 to systemd-235


systemd 235 was released today. A large number of issues was closed
upstream, including many bug fixes, documentation updates, and
long-standing RFEs. There are some new features, but relatively few
entirely new features or changes in behaviour that impact other
services. There also are no (intentional) breaking changes.

The update is building for rawhide. If nothing major pops up, I'd like
to release the update for F27 too.

review swap

I'm looking for a reviewer for

Bug 1478231 – Review Request: conda - Cross-platform, Python-agnostic binary package manager
<a href="" title=""></a>

I can review stuff in return.


Mass package change (python2- binary package renaming)

Hello Fedora Python package maintainers!

This is an announcement of a mass package renaming:
Python 2 binary packages will be renamed to python2-*.

This will happen soon after the F27 branching on August 15th.

Currently ~1330 source packages already generate a binary package with
the python2- prefix, and 835 remain to be updated. The spec files for
approximately 740 packages will be renamed, and 95 will be left for
fixing by maintainers or proven packagers.

At the end of this e-mail are two lists of maintainers and packages:

List 1.

Mass package change proposal


This is a continuation of the "Finalizing Fedora's Switch to Python 3"
thread on fedora-devel, using the procedure from
<a href="" title=""></a>.

I'm proposing an automated change to ~723 packages, and manual fixes
or follow-up bug filing for the remaining ~114 packages.

### Proposed changes ###

The change is to ensure that as many as possible python packages which
provide a version for python2 have a python2- subpackage as required by
the guidelines

For source packages which

/usr/bin/qemu-kvm symlink


I was told [1] that /usr/bin/qemu-kvm is obsolete, and that the right
thing is to use 'qemu-system-x86_64 -enable-kvm', and that Arch and
Gentoo and qemu upstream don't support /usr/bin/qemu-kvm. Fedora provides
/usr/bin/qemu-kvm as a shell wrapper on amd64 and i386 architectures.

My questions are:
1. do we plan to keep this wrapper indefinitely?

"no reboot, no logout" option in bodhi?

Currently bodhi offers three options on updates:
× unspecified
× reboot
× logout

For packages that provide daemons (like systemd) a third option would be
useful. The daemon is restarted in %post, so nothing needs to done.
I think this is quite common.


There's a new tiny package which provides a python traceback logging in
the journal for python processes. It's very similar to the existing
handler provided by abrt, it also installs itself as sys.excepthook
using a .pth file, but instead of communicating with abrt, it talks to
systemd-coredump directly.

The advantage is that it provides a backtrace in the journal (in
red!), which coredumpctl list/info know about. Various stuff that
systemd-coredump gathers (fdinfo, cgroups, mounts, unit, slices,
limits, uid, gid, etc) are recorded.

systemd-233 in rawhide

Hi all,

systemd-233 was released yesterday [1], and built today for F26 and rawhide.
There's a bunch of new stuff... including of particular significance
to Fedora:

- we turned "hybrid" cgroups on again. This was tried before,
unsuccessfully, with /sys/fs/cgroup/systemd using cgroups-v2, and
/sys/fs/cgroup using cgroups-v1. This time, everything is the same
as in the "legacy" setup, including /sys/fs/cgroup/systemd using
cgroups-v1, only /sys/fs/cgroup/unified is using cgroups-v2.

question about dnf builddep with some deps missing on some arches

systemd.spec file has
%ifarch %{ix86} x86_64 aarch64
BuildRequires: gnu-efi gnu-efi-devel


status of the Fedora26CFlags change


am I correct in thinking that the -Werror=implicit-{function-declaration,int}
part of this change was rescinded? The change page does not reflect this.


drop obsolete static uid/gid allocations

<a href="" title=""></a> has a list
of "soft static" uids and gids.

Currently FPC has a process for allocating new numbers on this list,
but here's a number of static uid/gid allocations from old times,
which are not necessary.

systemd-232 in rawhide

Hello everyone,

systmed-232 has been released today and is now building in koji.
With a bit of luck, it'll be available in rawhide tommorrow.
Apart from fairly significant upstream changes [1], there are some downstream
integration changes (grubby patch for kernel-install has been replaced
with /usr/lib/kernel/install.d/20-grubby.install, a new nss-systemd
module to resolve DynamicUsers has been added to /etc/nsswitch.conf,
the way that nss-resolve is configured in /etc/nsswitch.conf has been updated).

Please upgrade and report any bugs.

bootchart packagers needed


systemd-bootchart is a program which produces plots of activity
during boot, with the goal of optimizing the boot time and dependencies.
It was part of systemd until systemd-230, is now a separate project [1],
with a separate release cycle. It needs a new package, and a new
maintainer. It just made a new release a few days ago [2]. So if you
are a bootchart user, or want to involved, please submit a review

building the rawhide kernel with cgroup-v2 cpu controller patches

Unfortunately, due to the disagreements in the kernel development
community, CPU controller cgroup v2 support has not been merged and
enabling it requires applying two small out-of-tree kernel
patches. The situation is explained in the following documentation:

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

While it isn't clear what will happen with CPU controller cgroup v2
support, there are critical features which are possible only on cgroup
v2 such as buffered write control making cgroup v2 essential for a lot
of workloads.

nice reduction in systemd package size

Hi everyone,

systemd 231 was built for rawhide / F25 today, with a bunch of usability and
security features, see [1]. Please give it a test.

There have been various discussion about reducing the footprint of systemd,
this release and the previous one make some progress:


comps advice needed for systemd-{udev,container}


I'd like to move two systemd subpackages from the the @core group,
but I don't know where to move them to.

systemd-udev must be installed on "real hardware", so it must be
part of Workstation, Server, Cloud, and any spin. It should not be
installed in containers and chroots, e.g. mock.
Is @standard the right place? (Or @hardware-support?)

systemd-container should probably be installed in full Server installations.
Should I just move it to @virtualization-headless?


PS. That's be for F24+.

review swaps


I'm looking for reviewers for:

<a href="" title=""></a>
python-cma - Covariance Matrix Adaptation Evolution Strategy numerical optimizer

<a href="" title=""></a>
neurord - Stochastic reaction-diffusion simulator

I'll be happy to review stuff in return.


pacman update / libalpm so bump in F22+


old versions of pacman (the arch linux installer) will stop working
with new packages after April 23rd [1].

I'm updating pacman in all Fedora releases to the latest version. This
means that libalpm will be bumped incompatibly, but I don't expect
anyone to be linking to it.

[1] <a href="" title=""></a>


review swaps

I'm looking for reviewers for:

<a href="" title=""></a>
python-libarchive-c - Python interface to libarchive

<a href="" title=""></a>
diffoscope - In-depth comparison of files, archives, and directories

<a href="" title=""></a>
Library for building data processing pipelines for machine learning


HEADS UP: systemd package split


I finally pushed the split of the systemd package to Rawhide and F24 today
If you upgrade with dnf you should see something like this:
systemd-container x86_64 229-5.fc23 @commandline 353 k
replacing systemd.x86_64 222-13.fc23
systemd-udev x86_64 229-5.fc23 @commandline 1.2 M
replacing systemd.x86_64 222-13.fc23
systemd x86_64 229-5.fc23 @commandline 5.1 M
systemd-libs x86_64

post-release summary

In the series of interviews with candidates to FAmSCo several candidates
mentioned that ambassadors do not always know what changes were
implemented and what changes are planned for the future in Fedora.
I think this is understandable to a large extent, 'cause Fedora is a
large project, and the changes are mix of very different things like
programming, design, organizational changes, engineering processes,
etc, meaning that for any given person there are many things happening
outside of their interest zone.

aarch64 updates repo

We have a bug report [1] that 'dnf fedup download' fails on aarch64.
The error is:
Error: Failed to synchronize cache for repo 'updates' from '': Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink

and downloading the URL reveals the following comment:
# repo = updates-released-f23 arch = aarch64 error: invalid repo or arch


gpg keys of older/newer fedora versions

[In light of]

'dnf install --installroot=... --releasever=XX dnf' can be used to bootstrap
a Fedora chroot. The only snag is that --nogpg is often recommended, because
fedora-repos only provides the GPG keys for the current and next release.

It would be convenient (and safe!) to provide keys for past and future releases,
so such bootstrapping can be done without either importing the keys manually
and/or using --nogpg.

I thought I'd ask here first: is there a strong reason *not* to include those keys?


service accepting commands from the network by default

Are Fedora packages allowed to have a default configuration in which
the service accepts commands from the network in the default

The daemon is not enabled by default, so the administrator has to do a
systemctl enable/start first. This means that just installing the
package does not create a problem, and an explicit admin action is
necessary for the daemon to start listening. Nevertheless, I'm still
worried that people will start the service to try it out without
reading the fine print and will be vulnerable to attack.

is it possible to skip a noarch subpackage on certains archs (arm)


I have a package (a C++ library), which generated doxygen
documentation during build. The documentation lands in a noarch -doc
subpackage, the rest in the main package or in subpackages, all
arch-ed. The problem is that generating the documentation takes
forever (6+ hours) on arm. The arch-ed parts build fairly
quickly. Would it be possible to use %ifarch or equivalent to only
build the (slow) -doc subpackage on x86_64 or i686 archs? Would arm
then get the noarch subpackage from other archs?


fedup speed

I run fedup on a beefy desktop machine (SSD 450MB/s, 24GB ram, 12 cores),
and started wondering why is takes so much time (1.5h or thereabouts for
~4500 packages). I noticed two things:

1. installing packages used just 1 core, and actually not even not at 100%,
and about 15MB/s were written to the disk.
perf top said that time was spent mostly in lzma_decode.
Is this expected?

2. at the end, fedup creates a log by running 'journalctl -a -m',
which is --all --merge. This seems a bit excessive.

removing dependencies on systemd compat libs


a few versions ago, systemd provided libraries
libsystemd-{journal,id128,daemon,login}.so were merged into single To provide backwards compatibility, is
provided under each of the old names. This is done (*) by essentially
duplicating the code. A bunch of rpm still link to the old names, and
the time has come to move them over to the new name.

I split out systemd-compat-libs from systemd-libs today. If your
package depends on systemd-compat-libs then you should update your
linking options.

selinux issue with containers

installing Fedora in containers fails strangely (see below). It seems to be
selinux related, since booting with selinux=0 allows the installation to continue.
Strangely, just 'setenforce 0' does not work by itself.

unretiring json


according to
<a href="" title=""></a>
I'd like to announce that I want to unretire the json package [1],
which is needed it for closure-compiler [2].

According to dead.package file, "package was retired on 2012-08-06 due
to no active maintainers for the package."
Upstream is dead (incompatibly relicensed) so I don't expect much work
with updating :)

Re-review request is at <a href="" title=""></a>.