I know how important RPM is to the Fedora Project, but it breaks
everything downstream and we'd be better off using DPKG as we should
have from day one.
I'm calling this initiative fedpkg: Fedora Embraces DPKG.
A bit of background here: I build both RPMs and DEBs for $DAYJOB and
until recently my workflow was quite painful because I needed extra steps
between git checkout and git push that involves a VM, because what we
ship as apt is in reality apt-rpm.
It finally got enough on my nerves to locally build the things I needed and
after a month I have already amortized my efforts with the time I save not
having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that
I'm now submitting for review:
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl
Monk. I tried to CC perl-sig as per the guidelines  (also tried with
the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anything
Apt is a mix of C, Perl and C++ code, so I would be reassured if I
could have a C++ co-maintainer too. I'm only a C developer so if
something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up
the procedure for that to happen. I understand that when someone sees
they should run "apt-get install foo" somewhere on the web it's
helpful for non-savvy users that this JustWorks(tm) , but apt-rpm is
dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find
help for the reviews and co-maintainership. The packaging does nothing
fancy, there are quirks here and there but overall it was rather easy
to put together. And of course I would be happy to help with reviews
too in exchange.
And thanks again to the mock developers, its design is so much better
than either sbuild or pdebuild that I barely have pain points left when it
comes to RPM packaging.
 I'm not against apt-rpm in the base install for example
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
> > I'd like to get this package reviewed please:
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> > Would anyone like to swap reviews?
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
Time zone: Europe/London
writing to general devel list intentionally. No idea if all members of lxqt-sig list can read here, too and especially @zsun.
Is there any sense why @lxqt-sig is member of packaging for featherpad? LXQt SIG decided to have enki in the spin as the default editor. Featherpad is not part of LXQt upstream.
@lupinix Could you remove lxqt-sig from the members in pagure?
Question and (pre)proposal:
Can Fedora converge on a single swap-on-ZRAM implementation, and if
so, which one? Fedora Workstation WG wants to move to swap-on-ZRAM by
default in Fedora 33, and the working group needs to pick something
I think it should be zram-generator. It's the most lightweight, can be
included by default distro wide. Without a configuration file, it
doesn't run. Thus, each edition/spin, and even the install
environment, can have their own configuration file, to setup it up
however they want, or not set it up.
I also suspect it's the only one that could be upstreamed to systemd
proper, and just included like many other generators.
Background story and references:
Fedora IoT enables swap-on-ZRAM by default for a long time, and have
no issues. Fedora Workstation WG has been evaluating it for some time,
and wants to enable it by default in Fedora 33. Prior discussions 
(Details will be in a future feature proposal.)
Swap is a basic function, and swap-on-ZRAM is an optimization of a
basic function. Basic things should be understandable by users,
without having different configuration files, and systemd units to
look for, depending on what edition/spin they use, or whether they're
booting installation media, or an installed system. It's confusing.
And they don't co-exist gracefully.
There are three implementations in Fedora . Installation media
(DVD, netinstall, Live) use Anaconda's when the install media is
booted; Live installations include it, but it's disabled. Fedora IoT
has its own variant enabled by default, similar in design and function
to Anaconda's, but differently named systemd unit, configuration file,
and bash scripts used by the systemd unit. There's nothing wrong with
these, but in my estimation they have no chance of being upstreamed to
And there's zram-generator. It works much like any other of the basic
generators for this sort of thing: the gpt-auto-generator, the
fstab-generator, and the cryptsetup-generator. I'm not sure who would
argue we need multiple implementations of these things, with separate
configuration files, in the same distribution.
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0"
line to the libvirt-daemon-driver-libxl RPM, which gives clean
upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed
though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo
RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0"
statement ? It seems impossible, meaning users with debuginfo have a
broken upgrade path. An unfortunate consequence of switching to seprate
-debuginfo per sub-RPM.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Improve compression ratio of SquashFS filesystem on the installation media.
Name: Bohdan Khomutskyi
Targeted release: I propose this change for Fedora 32
Last updated: Jan 5 2020
Pagure.io issue: https://pagure.io/releng/issue/9127
I was unable to create an article in Fedora wiki system.
As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is
compressed with default settings of mksquashfs. The standard configuration
is set to XZ algorithm with block size of 128k and BCJ filter enabled.
Those parameters can be adjusted which will lead to a better compression
ratio and/or reduction of the CPU usage at build time.
This is simple to achieve. Recently, Lorax has gotten support for
adjusting the compression options for mksquashfs via the configuration
file. The file should be altered as following:
bcj = yes
args = -b 1M -Xdict-size 1M -no-recovery
Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively.
Could be adjusted.
Benefit to Fedora
Reduction of the installation media size and the cost of storing and
Reduction of the CPU usage at build time. Depending on which compression
See a graphical detail at https://pagure.io/releng/issue/9127.
The build environment should have support for adjusting the Lorax
configuration file.. Lorax is a program that produces the
LiveOS/squashfs.img file on the installation media.
One of the way to allow for such customization, is to add a feature in
Pungi, to allow for passing -c option to Lorax.
Release engineering: #9127 <https://pagure.io/releng/issue/9127>
Policies and guidelines: N/A
Trademark approval: N/A
This change comes at a cost of higher memory usage during the
installation. Based on my personal estimations, this should not be the
issue. Since the decompression should require up to 1MiB per thread.
Increasing the block size on the current configuration with EXT4 file
system, should increase latency while accessing the EXT4 filesystem. The
exact impact is to be evaluated.
The impact of latency will be reduced, if the plain SquashFS option is
Release notes See also
Release Configuration Management engineer
the semiannual exercise is upon us. FESCo candidates must submit an
"interview" in which they answer a set of questions (but can also add whatever they want).
The question whether we should have a new set of questions needs to be answered.
Currently we have the following:
Mandatory Question #1: Describe some of the important technical issues
you foresee affecting the Fedora community. What insight do you bring
to these issues?
Mandatory Question #2: What objectives or goals should FESCo focus on
to help keep Fedora on the cutting edge of open source development?
Mandatory Question #3: What are the areas of the distribution and our
processes that, in your opinion, need improvement the most? Do you
have any ideas how FESCo would be able to help in those "trouble
Please answer with any proposals. If there is sufficient support for
change, I'll gather a list and submit this for some kind of poll
(details to be figured out...).
I've orphaned python-pep8. pep8 was renamed to pycodestyle in 2016; it
received its last release in 2017. It should be removed from Fedora in a
I unfortunately don't have time to proceed with the full retirement
process myself. If somebody would like to pick it up:
$ dnf repoquery --whatrequires python2-pep8
$ dnf repoquery --whatrequires python3-pep8
See also https://bugzilla.redhat.com/show_bug.cgi?id=1667200's dependent
(Please CC me on replies that need my attention.)
iliana weller <ilianaw(a)buttslol.net>