devel September 2019

devel@lists.stg.fedoraproject.org

258 participants
419 discussions

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

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

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

python-pep8 is orphaned
by iliana weller 03 May '20

03 May '20

Hello, 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 future release. I unfortunately don't have time to proceed with the full retirement process myself. If somebody would like to pick it up: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#C… $ dnf repoquery --whatrequires python2-pep8 python2-autopep8-0:1.2.4-9.fc29.noarch python2-pytest-pep8-0:1.0.6-15.fc29.noarch python2-spyder-0:3.3.1-3.fc29.noarch $ dnf repoquery --whatrequires python3-pep8 python3-autopep8-0:1.2.4-9.fc29.noarch python3-hacking-0:1.1.0-3.fc29.noarch python3-pytest-pep8-0:1.0.6-15.fc29.noarch python3-spyder-0:3.3.1-3.fc29.noarch See also https://bugzilla.redhat.com/show_bug.cgi?id=1667200's dependent bugs. (Please CC me on replies that need my attention.) -- iliana weller <ilianaw(a)buttslol.net>

7 9

orphaning bleachbit
by Mukundan Ragavan 02 May '20

02 May '20

I intend to orphan bleachbit soon. If anyone is interested please let me know and I will transfer the package. https://src.fedoraproject.org/rpms/bleachbit Mukundan.

15 30

Schedule for Thursday's FPC Meeting (2019-08-15 16:00 UTC)
by James Antill 09 Apr '20

09 Apr '20

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-08-15 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2019-08-15 09:00 PDT US/Pacific 2019-08-15 12:00 EDT --> US/Eastern <-- 2019-08-15 16:00 UTC UTC 2019-08-15 17:00 BST Europe/London 2019-08-15 18:00 CEST Europe/Berlin 2019-08-15 18:00 CEST Europe/Paris 2019-08-15 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2019-08-16 00:00 HKT Asia/Hong_Kong 2019-08-16 00:00 +08 Asia/Singapore 2019-08-16 01:00 JST Asia/Tokyo 2019-08-16 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #902 Cleanup & enhance spec files .fpc 902 https://pagure.io/packaging-committee/issue/902 #topic #904 Caret versioning .fpc 904 https://pagure.io/packaging-committee/issue/904 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #914 Automatic R runtime dependencies .fpc 914 https://pagure.io/packaging-committee/issue/914 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

2 1

Release rpkg-1.58 fedpkg-1.37
by Ondrej Nosek 17 Mar '20

17 Mar '20

Hi all, a new version rpkg-1.58 and fedpkg-1.37 is released. Currently, Fedora 30 packages are in the stable repository, feel free to try other waiting distributions in Bodhi. Numerous features and improvements (as well as bugfixes) includes: (For "rpkg") - Improvements for scratch module builds - Allow passing arguments to “mbs-manager build_module_locally” - Remove the ability to parse a module’s branch - Permit setting arbitrary rpm macros during build - Ignore specific files in a cloned repository - Pass specific arguments to “mock” - Added “depth” argument to "git clone" - Watch multiple module builds - Show module build links in output from command module-build - Add the ability to configure multiple regex expressions - Add “retire” command supporting both packages and modules - Import srpm without uploading sources - Ignore any specified profile when finding the Flatpak build target - Added update-docs script - And other fixes and small improvements (For "fedpkg") - Ignore files in a cloned repository - Enable shell completion for module scratch builds - Show hint when Pagure token expires - Include possible distprefix in “–define dist” for Forge-based packages - Other small fixes More specific changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.58.html https://docs.pagure.org/fedpkg/releases/1.37.html Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.58-1.el6&builds=rpkg… Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 rpkg is available from PyPI. Thanks to all contributors. Regards

2 2

fedora-gpg-keys not updated yet again
by Zbigniew Jędrzejewski-Szmek 19 Feb '20

19 Feb '20

This seems to repeat every 6 months: rawhide mock is broken on stable Fedora, people are scrambling to install the right gpg keys, dnf reports unsigned packages. Looking at https://bodhi.fedoraproject.org/updates/?packages=fedora-repos, there is still no F30 package with the right keys. Can we *please* send out the FN+1 and FN+2 keys a month before branching, to *all* releases of Fedora, so we can avoid this pointless scramble? Zbyszek

14 27

Fedora 32 System-Wide Change proposal: Firewalld Default to nftables
by Ben Cotton 06 Jan '20

06 Jan '20

https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables == Summary == This change will toggle the default firewalld backend from iptables to nftables. All of firewalld's primitives will use nftables while direct rules continue to use iptables/ebtables. == Owner == * Name: [[User:erig0| Eric Garver]] * Email: egarver(a)redhat.com == Detailed Description == Firewalld upstream has used nftables as the default backend for the past two minor releases. It is also the default in other distributions (e.g. RHEL-8). This change will bring Fedora in line with upstream. Using nftables bring many advantages. See firewalld's upstream [https://firewalld.org/2018/07/nftables-backend blog post]. It also highlights a few behavioral changes. == Benefit to Fedora == * Fewer firewall rules (rule consolidation) All of firewalld's primitives will use the same underlying firewall (nftables) instead of duplicating rules both in iptables and ip6tables. In nftables rules can match both IPv4 and IPv6 packets. This reduces the number of firewall rules by half. * firewalld's rules are namespaced With nftables firewalld's rules are isolated to a "firewalld" table. A separate firewall (or user) can create its own independent ruleset and firewalld will never touch it. * Netfilter upstream is focusing on nftables, not iptables == Scope == * Proposal owners: firewalld (erig0, Eric Garver) Currently the firewalld package has a Fedora downstream patch to hide the nftables backend. The only firewalld change required is to remove that patch from the package and rebuild. * Other developers: libvirt, podman, docker ** libvirt *** libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify. ** podman *** libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify. ** docker *** Docker currently does not cooperate with the nftables backend. It currently side-steps firewalld by injecting its own rules in iptables ahead of firewalld's rules. However, with the nftables backend firewalld's rule will still be evaluated. Netfilter in the kernel will call iptables, then nftables for the same packet. This means firewalld/nftables is likely to drop the packet even if docker has iptables rules to ACCEPT. *** Proposed fix 1: Docker package should provide a firewalld zone definition that includes the docker interfaces (e.g. docker0). The zone should use the "ACCEPT" policy (firewalld --set-target). This will allow docker's traffic to pass through firewalld/nftables. **** Issue 1: If a user has configured a different docker bridge name, then they'll have to manually add the bridge to the docker zone (or firewalld's trusted zone). *** Proposed fix 2: Just like "Proposed fix 1", but instead of adding the zone definition to docker we created a "docker-firewalld" (or firewalld-docker?) package that has the zone definition. This could be installed by default when docker is installed. * Policies and guidelines: No updated needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == When users are upgraded to firewalld with nftables enabled (f32) all their firewall rules will exist in nftables instead of iptables. All of firewalld's primitives (zones, services, ports, rich rules, etc.) are 100% compatible between backends. Users of direct rules may need to consider the [https://firewalld.org/2018/07/nftables-backend behavioral changes] that were announced upstream. Some are also highlighted here: * direct rules execute before _all_ firewalld rules ** This has been requested by users * packets dropped in iptables (or direct rules) will never be seen by firewalld * packets accepted in iptables (or direct rules) are still subject to firewalld's rules == How To Test == Testing should mostly be integration based. Firewalld upstream has a fairly comprehensive testsuite that covers functional testing. The following are packages known to integrate with firewalld. They should be tested with the nftables backend. * libvirt ** verify VMs with different network types (bridged, routed) have working network access ** newer version of libvirt should create and use a "libvirt" firewalld zone. Interfaces should be dynamically added to the zone. * podman ** verify podman adds container bridge interface to the "trusted" zone ** verify container still has network access * docker ** known to not work with the firewalld nftables backend out of the box ** verify new package docker-firewalld installs firewalld docker zone and has "docker0" interface added ** verify container still has network access * fail2ban-firewalld ** verify the direct rules added to firewalld by fail2ban still block traffic == User Experience == In general users shouldn't notice the change. Occasional a user will look at the iptables rule that firewalld generates. They'll now have to look at nftables instead. == Dependencies == * libvirt >= 5.1.0 * CNI >= 0.8.0 (used by podman) * docker-firewalld (new package) == Contingency Plan == * Contingency mechanism: firewalld maintainer (erig0) will reinstate the current patch to default to the iptables backend. * Contingency deadline: beta freeze == Documentation == * [https://firewalld.org/2018/07/nftables-backend Firewalld blog post] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

5 5

Orphaning pykka
by Jonathan Dieter 05 Jan '20

05 Jan '20

I've just orphaned pykka (https://admin.fedoraproject.org/pkgdb/package /rpms/pykka/) as I'm no longer using it. Jonathan

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2019