devel March 2020

devel@lists.fedoraproject.org

235 participants
489 discussions

Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
by Hans de Goede 04 Aug '20

04 Aug '20

Hi All, Just a quick headsup for users following Fedora 29, the dbus 1.12.10-1.fc29 build is missing the systemd dbus.service file, breaking almost everything. Instead it contains a dbus-daemon.service file, but the dbus.socket file expects a matching dbus.service, not dbus-daemon.service. So either hold of on applying updates until this is fixed or exclude dbus. Regards, Hans

17 28

Ditch RPM in favor of DPKG
by Dridi Boukelmoune 19 Jul '20

19 Jul '20

Greetings packagers, 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: https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism https://bugzilla.redhat.com/show_bug.cgi?id=sbuild https://bugzilla.redhat.com/show_bug.cgi?id=apt 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 [1] (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) [2], 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. Thanks, Dridi [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig [2] I'm not against apt-rpm in the base install for example

17 44

Autoclosure of review requests?
by Ben Cotton 26 Jun '20

26 Jun '20

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. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

6 10

Default editor for LXQt spin
by Raphael Groner 25 Jun '20

25 Jun '20

Hi, 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? Regards, Raphael

3 2

swap-on-ZRAM by default
by Chris Murphy 11 Jun '20

11 Jun '20

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 soon. 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 [1] (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 [2]. 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 systemd proper. 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. [1] https://pagure.io/fedora-workstation/issue/98 https://pagure.io/fedora-workstation/issue/120 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… https://lists.fedoraproject.org/archives/list/iot@lists.fedoraproject.org/t… [2] zram-generator-0.1.2-1.fc32.x86_64 https://github.com/systemd/zram-generator https://src.fedoraproject.org/rpms/rust-zram-generator zram-0.4-1.fc31.noarch https://src.fedoraproject.org/rpms/zram Provides zram-swap.service anaconda-32.20-1.fc32.x86_64 https://github.com/rhinstaller/anaconda Provides zram.service -- Chris Murphy

15 32

Adding Obsoletes to generated -debuginfo packages ?
by Daniel P. Berrangé 04 Jun '20

04 Jun '20

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. Regards, Daniel -- |: 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 :|

7 12

Fedora 33 System-Wide Change proposal: Sqlite RpmDB
by Ben Cotton 21 May '20

21 May '20

https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb == 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 inconsistencies either. 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 34. == 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 testing base ** 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 https://bugzilla.redhat.com/show_bug.cgi?id=1766120 * 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 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

16 55

New set of questions for FESCo candidates?
by Zbigniew Jędrzejewski-Szmek 15 May '20

15 May '20

Dear all, 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 spots"? 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...). Zbyszek

13 24

Pinging spin or labs maintainers in failed composes tickets
by Mohan Boddu 12 May '20

12 May '20

Hi all, As discussed in the spins list [1], we are adding the ability to ping maintainers of spins or labs in compose failure tickets [2]. I made a list of maintainers [3] from the existing kickstart files, please create PR's to fedora-kickstarts repo [4] if any changes are needed to the list. We are hoping that it will be very helpful to all the spins, labs and any other variant maintainers to get notified if they image build failed and provides an easy way to find and debug the issue. Thanks, Mohan Boddu Fedora Release Engineering. [1] https://lists.fedoraproject.org/archives/list/spins@lists.fedoraproject.org… [2] https://pagure.io/releng/failed-composes/issues [3] https://pagure.io/fedora-kickstarts/blob/master/f/maintainers.toml [4] https://pagure.io/fedora-kickstarts/

3 9

Fedora pagure confusion wrt EPEL
by Michael Schwendt 05 May '20

05 May '20

I don't do EPEL packaging. I never signed up as an "owner" of EPEL packages. I don't want to be the new default owner of EPEL bugzilla tickets. Where may I be able to stop this mess?

8 21

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel March 2020