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

Schedule for Friday's FESCo Meeting (2018-03-09)

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 15:00UTC in #fedora-meeting on

To convert UTC to your local time, take a look at
<a href="" title=""></a>

or run:
date -d '2018-03-09 15:00 UTC'

Links to all issues below can be found at:
<a href="" title=""></a>

= Followups =

#topic #1853 F29 System Wide Change: Enable dbus-broker
.fesco 1853
<a href="" title=""></a>

#topic #1845 389-ds-base and freeipa on 32 bit arches
.fesco 1845
<a href="" title=""></a>

#topic #1820 Adju

systemd 238 and sysusers


systemd 238 has been released [1] and is building in F28 and rawhide.

This release has more bugfixes than new features, but there are some
changes that might be particularly interesting for Fedora:

- cgroups v2 is now supported much better. In particular a long-standing
conflict between cgroups v2 and systemd-run --user --scope has
been fixed.

Schedule for Friday's FESCo Meeting (2018-03-02)

Following is the list of topics that will be discussed in the FESCo
meeting Friday at 15:00 UTC in #fedora-meeting on

To convert UTC to your local time, take a look at
<a href="" title=""></a>

or run:
date -d '2018-03-02 15:00 UTC'

Links to all issues below can be found at:
<a href="" title=""></a>

= Followups =

#topic #1846 F28 approved Changes not in MODIFIED status (considered as not testable)
.fesco 1846
<a href="" title=""></a>

#topic #1845 389-ds-base and freeipa on 32 bit arches
.fesco 1845
<a href="" title=""></a>

looking for a new maintainer for closure-compiler


closure-compiler in Fedora needs an update [1], possibly with new
deps. There's also a bug which prevents it from starting in F28+ [2].
The fix is simple (and I just verified that it works), but the package
doesn't build in rawhide because of changes in deps...

It's is an interesting and extremely useful package, but I haven't
been able to give it the love it needs. I also stopped working with
java, so I'm out of the loop on maven.

Hence, $subject.

unresponsive maintainer procedure for konradm (Conrad Meyer)


If anyone knows how to contact Conrad Meyer / konradm, please do so.

Today one package owned by konradm, xchat-ruby, was retired as a result
of a FESCo ticket [1]. The remaining ones will be orphaned in two weeks
if there is no response.

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


to batch or not to batch?

Bodhi currently provides "batched updates" [1] which lump updates of
packages that are not marked urgent into a single batch, released once
per week. This means that after an update has graduated from testing,
it may be delayed up to a week before it becomes available to users.

Batching is now the default, but maintainers can push theirs updates
to stable, overriding this default, and make the update available the
next day.

Batching is liked by some maintainers, but hated by others
Unfortunately, the positive effects of batching are strongly
decreased when many packages are not batched.

unresponsive maintainer 'jamatos'

Hi José,

are you still around? You activity suddenly stops around May 28th
2017, I hope nothing serious happened.

grace package needs attention:
<a href="" title=""></a>,
<a href="" title=""></a>.


MASS CHANGE announcement: python2- prefix renaming, part 2

Dear fellow Fedora developers,

I plan to execute part 2 of the renaming. First part was announced and
discussed here [1]. Recently, Iryna Shcherbina announced [2] plans for
a follow up: changing the requirements. Before that happens I want to
finish my renaming. In this round my changes are rather small, only
~80 packages, see the lists below.

systemd 236 in rawhide


systemd 236 was released [1] and is building for rawhide.

services which are enabled by default and crash

I recently installed all rpms that provide a systemd service file in a
container. Quite a few services are enabled by default and crash badly.
I think enabling so many services by default is a bad thing, but if they
at least run OK, that's less problematic.

elasticsearch package looking for new maintainers

This is something I should have done long ago:
elasticsearch in Fedora needs an update and a lot of love.
It doesn't even work properly in F27. There's also a CVE open against lucene4
(a dependency, see <a href="" title=""></a>).
It's a great program, but my focus shifted and I don't have time for it.
If you are interested, let me know and I'll assign ACLs.


streamlining fedora-release

Hi fedora-release maintainers and fellow developers,

The fedora-release package contains stuff that is tied to each Fedora
version and changes slowly, and it also contains the preset files for
systemd units, which change fairly often (a few requests per month).

Currently fedora-release has a fairly complicated maintenance
structure, with an "upstream" project at <a href="" title=""></a>
and "downstream" at <a href="" title=""></a>.
"upstream" is only used for this single "downstream", and in fact changes
made in packaging "downstream" are sometimes lost when

plan to update F27 to systemd-235 cancelled


two weeks ago I signalled a plan to update systemd to v235 in F27.
I have now given up on this.

Reasons: there were some issues in the implementation of the
DynamicUser feature. Handling this took some time and F27 entered the
final freeze, and it seems to late to do update the version now.

I backported a bunch of patches (~80) for F27, but only simple fixes,
so any new functionality and nontrivial fixes are excluded.

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+.