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
In the weekly Fedora program update that I publish on
communityblog.fedoraproject.org, I have started to include a count of the
open package review requests. As of this moment, there are ~1300 open
review requests. Some of these were opened in 2006.
The usual Bugzilla housekeeping (branching, EOL closure, etc) explicitly
excludes review request bugs. Having a large number of open, ancient review
requests isn't exactly harmful, but it's not very helpful either.
Before I make a proposal to FPC, I thought I'd open a conversation here.
What does a reasonable cleanup of review requests look like?
My initial thought is to close all review requests that were opened >2
years ago, to be performed at the EOL closure for each release.
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
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?
I am not sure if this deserves a Fedora Change proposal, so I'd like to
hear any opinions first before proceeding with the process.
NSS (the crypto library used by Firefox) historically supports 2
database formats: SQLite and DBM. The latter is considered legacy and
we switched the default database format to SQLite in F28. Since then
I presume most of the applications have switched to the new format.
Therefore we are planning to phase out the support of DBM, targetting
Please let me know if there is any concern.
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
== Summary ==
Change format of the RPM database from Berkeley DB to a new Sqlite format.
== Owner ==
* Name: [[User:pmatilai| Panu Matilainen]] [[User:ffesti|Florian Festi]]
* Email: pmatilai(a)redhat.com ffesti(a)redhat.com
== Detailed Description ==
The current rpm database implementation is based on Berkeley DB 5.x, a
version which is unmaintained upstream for several years now. Berkeley
DB 6.x is license incompatible so moving to that is not an option. In
addition, the existing rpmdb implementation is notoriously unreliable
as it's not transactional and has no other means to detect
Changing to a more sustainable database implementation is long
overdue. We propose to change the default rpmdb format to the new
sqlite based implementation. Support for current BDB format will be
retained in Fedora 33, and phased out to read-only support in Fedora
== Benefit to Fedora ==
* A far more robust rpm database implementation
* Getting rid of Berkeley DB dependency in one of the core components
== Scope ==
* Proposal owners:
** Once [[Changes/RPM-4.16|RPM 4.16]] lands and passes initial
shakedown, change the default rpmdb configuration to sqlite
** Address any bugs and issues in the database backend found by wider
** Help other developers to address Berkeley DB dependencies
* Other developers:
** Test for hidden Berkeley DB dependencies in other software, address
them as found and needed
* Release engineering: [https://pagure.io/releng/issue/9308 #9308]
* Policies and guidelines: Policies and guidelines are not affected
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
=== Upgrading ===
* Ability to upgrade is not affected
* After upgrade completes, manual action (rpmdb --rebuilddb) will
probably be needed to convert to sqlite. Alternatively user can change
configuration to stay on BDB.
=== Compatibility ===
* Container/chroot use-cases will be affected: older rpm versions will
be unable to query/manipulate the rpmdb from outside the chroot
* Koji/COPR may need to override the database format (back to) BDB for
the time being
== How To Test ==
* Rpmdb gets thoroughly exercised as a matter of normal system
operation, performing installs, updates, package builds etc
* Of specific interest here is torture testing: forcibly killing rpm
in various stages of execution - database should stay consistent and
operational (other system state is out of scope)
* Test database conversions from one backend to another (rpmdb
--rebuilddb --define "_db_backend <backend>")
== User Experience ==
* In normal operation, users should see little or no change
* Behavior in error situations is much more robust: forcibly killed
transaction no longer causes database inconsistency or corruption
== Dependencies ==
* This change depends on [[Changes/RPM-4.16|RPM 4.16]], support for
sqlite rpmdb is not present in older versions
* RPM will grow a new dependency on sqlite-libs
* Technically the rpmdb format is an internal implementation detail of
RPM and the data is only accessible through the librpm API, but some
software is making assumptions both about the format and/or in
particular, file naming. These are being tracked at
* Upgrade tooling could/should perform rpmdb rebuild at end, this
would be a good thing to do regardless of this change
== Contingency Plan ==
* Contingency mechanism:
** Revert the default database back to Berkeley DB backend in the
package. Running 'rpmdb --rebuilddb' on hosts is currently required to
actually convert the database, but means to automate conversion in
specific conditions is being discussed upstream.
** The rpm-team does not expect problems with the database backend
itself, but we are aware that postponing may be needed due to
infrastructure or other tooling not being ready, primarily due to
inability to access the database from older releases.
* Contingency deadline: Beta freeze
* Blocks release? Yes
== Documentation ==
* [https://rpm.org/wiki/Releases/4.16.0 | RPM 4.16 release notes]
== Release Notes ==
* After upgrading from an older release, rpm operations will issue
warnings about database backend configuration not matching what's on
disk. Users should run 'rpmdb --rebuilddb' at earliest opportunity, or
change configuration to stay on Berkeley DB backend (eg 'echo
%_db_backend bdb > /etc/rpm/macros.db')
* The details are subject to change, the database rebuild may be done
by upgrade tooling
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Almost a week ago, I built cmpfit and fityk in side tags on F31, F32
and F33. While the builds for F33 moved directly to stable - as
expected - the other two got stuck for 4 days. I noticed that I could
push them manually to testing, which I did a little over two days ago,
but they seem to be stuck again, transitioning from pending to
testing. Updates for other packages I built around the same time and
later are already in testing. These are the updates in question: