devel June 2021

devel@lists.fedoraproject.org

214 participants
357 discussions

License change and so-version bump in side tag: libinstpatch
by Benjamin Beasley 12 Nov '21

12 Nov '21

The License field for the libinstpatch 1.0.0 (a pre-release version from SVN) packaged in Fedora 32–34 has been corrected from “LGPLv2+” to “LGPLv2 and GPLv2 and Public Domain”. In Fedora 35, libinstpatch has been updated to version 1.1.6, which brings another license change, to “LGPLv2 and Public Domain”, and a so-version bump from 0 to 2. Also the directory containing the headers now ends in the so-version (%{_incdir}/libinstpatch-2), but dependent packages all use pkgconfig and do not care. I have built the update in the side tag “f35-build-side-40054”. The following PR’s cover the dependent packages: muse: https://src.fedoraproject.org/rpms/muse/pull-request/1 gsequencer: https://src.fedoraproject.org/rpms/gsequencer/pull-request/1

2 1

Bodhi critpath package updates now gated on openQA results
by Adam Williamson 11 Nov '21

11 Nov '21

Hey folks! Just wanted to flag up that, now the new Bodhi version has been deployed to production, critpath updates are gated on openQA test results. If any openQA test for your critpath update failed, the gating status will be marked as 'failed' and you will not be able to push it stable. Waivers can be issued for failed tests where appropriate: https://docs.fedoraproject.org/en-US/ci/gating/#_waive But in almost all cases a failure indicates either a genuine bug or an opportunity to improve the test, so I'd prefer to avoid use of waivers where possible. I am trying to keep an eye on all failed tests, but if you have a blocked update and you don't understand the failure and I haven't yet commented on it, please do poke me and I'll take a look. If a failure looks like some kind of transient issue, several folks have the power to rerun tests: myself, lruzicka, kparal, tflink, abokovoy (abbra / ab), pwhalen, and sumantrom. You can ask one of us to do it. There have been plans in the past to implement some sort of rerun request system in Bodhi but no-one's quite had the roundtuits to work it out yet; sorry about that. Thanks everyone, please be patient with any kinks while we see how this goes :) -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

9 27

Fedora 32 System-Wide Change proposal: iptables-nft-default
by Ben Cotton 04 Nov '21

04 Nov '21

https://fedoraproject.org/wiki/Changes/iptables-nft-default == Summary == Make iptables-nft the preferred iptables variant. == Owner == * Name: [[User:psutter| Phil Sutter]] * Email: psutter(a)redhat.com == Detailed Description == <code>iptables-nft</code> package provides alternative implementations of iptables, ip6tables, ebtables and arptables and associated save and restore commands. These use nftables internally while providing the same look'n'feel as the original tools. Users may choose between both implementations using <code>alternatives</code> tool. Upstream considers the traditional implementations legacy and therefore renamed the binaries adding '-legacy' suffix. In Fedora, same has been done to <code>arptables</code> and <code>ebtables</code> packages, namely renaming them to <code>arptables-legacy</code> and <code>ebtables-legacy</code>. Legacy <code>iptables</code> and <code>ip6tables</code> remain in <code>iptables</code> package, which in fact is the only one other packages depend upon. To change the status quo, two measures are planned: === Raise priority of nft-variants in <code>alternatives</code> === Currently, legacy variants are installed with priority 10 and nft variants with priority 5. This must be changed as otherwise installing <code>iptables-legacy</code> in a system with <code>iptables-nft</code> installed would change the active alternative (since they are in automatic mode by default). On the other hand, existing systems using legacy variants should not be changed by a system update. Therefore nft variants' priorities should be chosen to match legacy ones. === Rename <code>iptables</code> package === New name should be <code>iptables-legacy</code> which aligns with ebtables and arptables and reflects upstream status. To resolve dependencies, <code>Provides: iptables</code> statement will be added to <code>iptables-nft</code> package. This should automatically change the default variant to nft. == Benefit to Fedora == * RHEL8 ships nft-variants exclusively, make Fedora align with that by default while still providing the option to fall back to legacy tools. * New features and improvements are likely to hit nft-variants due to the possibility nftables backend allows for. Although at this point some legacy features (e.g. ebtables among match) are still missing, others are already there (like, e.g. xtables-monitor tool) or are being upstreamed right now (improved tool performance when dealing with large rulesets). == Scope == * Proposal owners: Changes are rather simple: Rename <code>iptables</code> package, add <code>Provides:</code> line to <code>iptables-nft</code> package, change priorities used when calling <code>alternatives</code>. * Other developers: N/A The changed tools may cause regressions among packages using them and it affects only new installations (or those manually switched over). So while no explicit effort is required from them, they should be made aware of the change so they take a possible regression in iptables into account, quickly test against legacy variant and file a ticket (or complain to the right person) if that fixes the problem. * Release engineering: [https://pagure.io/releng/issue/8934 #8934] * Policies and guidelines: No change required * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Due to the package rename and <code>Provides:</code> line, upgrades will pull in <code>iptables-nft</code> package. But due to the equal alternatives priorities, existing choices won't be changed and so existing installations shouldn't be harmed (apart from forced installation of <code>iptables-nft</code> package). Sadly, there are a few known issues, like e.g. missing support for ebtables broute table or among match and a few iptables targets/matches. Users depending on such features are advised to install <code>iptables-legacy</code> package and switch variants using <code>alternatives</code>. == How To Test == Any users of iptables/ebtables/arptables should switch to nft-variants using alternatives tool (if necessary) and check that everything works as before. Any issues should be reported despite the known compatibility issues described above since knowledge about who uses the missing features is valuable information for both up- and downstream. == User Experience == Ideally look'n'feel shouldn't change. Since iptables-nft does not need a lock file anymore, no problems with stale xtables-lock or parallel iptables calls in different mount namespaces are expected anymore. Given the changes currently being upstreamed, users dealing with large rulesets should see a performance increase when manipulating the ruleset (lower run-times of iptables or iptables-restore, packet processing speed should not really change). == Dependencies == Other packages depending on iptables: * NFStest * clatd * ctdb * fail2ban-server * firewalld * fwsnort * iptstate * libvirt-daemon-driver-network * libvirt-daemon-driver-nwfilter * moby-engine * nfacct * origin * podman * psad * python3-ipatests * ravada * rkt * shorewall * shorewall-init * shorewall-lite * shorewall6 * shorewall6-lite * sshuttle * sslsplit * ufw Since nft-variants are supposed to be drop-in replacements, no outside contribution is needed in order to perform this change. == Contingency Plan == * Contingency mechanism: Nothing needs to be done, the change should be atomic. * Contingency deadline: N/A * Blocks release? No == Documentation == * https://wiki.nftables.org/wiki-nftables/index.php/Legacy_xtables_tools * Man pages: ** [http://man7.org/linux/man-pages/man8/xtables-nft.8.html xtables-nft.8] ** [http://man7.org/linux/man-pages/man8/xtables-legacy.8.html xtables-legacy.8] ** [http://man7.org/linux/man-pages/man8/xtables-monitor.8.html xtables-monitor.8] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

6 10

Work getting hwcaps microchiecture package geneataion into rpm
by Reon Beon 27 Oct '21

27 Oct '21

https://hackweek.suse.com/all/projects/support-glibc-hwcaps-and-micro-archi… Comments dancermak 5 days ago by dancermak | Reply This sounds very intriguing! I have a few notes about this: you might be interested in this (sadly stalled) upstream PR: https://github.com/rpm-software-management/rpm/pull/1035 which adds better detection of the currently running microarchitecture once rpm gains the ability to automatically generate subpackages (https://github.com/rpm-software-management/rpm/pull/1485) this could be completely automated I would suggest to use actual boolean dependencies instead of packageand: Supplements: (libfoo1 and x86-64-v3) And please, please make some noise about this and coordinate it with the other rpm based distros, so that we don't end up with yet another SUSE-ism but instead lead the innovation.

3 6

Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches
by Kaleb Keithley 19 Oct '21

19 Oct '21

There is a proposal[1] in upstream GlusterFS to drop 32-bit arches. The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide. [1] https://github.com/gluster/glusterfs/issues/702 -- Kaleb

11 25

co/lead-maintainer sought: python-mailmerge (python)
by Brian (bex) Exelbierd 06 Oct '21

06 Oct '21

Hi, I added python-mailmerge to Fedora Linux as it was super important to large parts of my work as FCAIC. In my current $dayjob I use it less frequently, though I know of colleagues who still depend on it. I'd love to find a maintainer to help me with it. There is a new release pending, which I suspect will just be "build the rpm with new code; test it; ship it" level effort. I am happy to hand the whole thing off to someone or to work with you. Thank you. regards, bex -- Did this email arrive after work for you? Stop reading it and enjoy some work/life balance. Brian "bex" Exelbierd (he/him/his) Community Business Owner, RHEL Product Management @bexelbie | http://www.winglemeyer.org bexelbie(a)redhat.com

5 9

co/lead-maintainer sought: gocryptfs+dependencies (go-lang)
by Brian (bex) Exelbierd 03 Oct '21

03 Oct '21

Hi, While I still actively use gocryptfs, I am busy enough with my $dayjob that I know I am not able to put enough time into maintaining it. Right now this has been OK as they have stopped new releases while they get v2.0 out the door. However, that will ship soon. I'd love to get some help maintaining the main rpm and the 6 dependencies I have for it. I am happy to hand it all over to you or to work with you. Thank you. regards, bex -- Did this email arrive after work for you? Stop reading it and enjoy some work/life balance. Brian "bex" Exelbierd (he/him/his) Community Business Owner, RHEL Product Management @bexelbie | http://www.winglemeyer.org bexelbie(a)redhat.com

1 1

Orphaning the cura-lulzbot package set
by Tom Callaway 02 Oct '21

02 Oct '21

This fork of cura has basically been abandoned by upstream, and the new company that acquired Lulzbot has gone out of compliance with the source code for the firmware. They have made it very clear that they have no real interest in working with the community to improve this situation, and I no longer have any motivation to maintain these packages. Accordingly, I've orphaned the following packages: * cura-lulzbot * lulzbot-marlin-firmware * CuraEngine-lulzbot * python-uranium-lulzbot ~spot P.S. I opened an upstream pull request to add support for the Lulzbot TAZ Pro and the Mini 2 in the main Cura codebase (still actively maintained). I would highly recommend that anyone considering reviving these packages devote their efforts in that direction instead.

3 2

Fedora 35 Change: Add Fedora Kinoite as a variant (Self-Contained Change proposal)
by Ben Cotton 29 Sep '21

29 Sep '21

https://fedoraproject.org/wiki/Changes/Fedora_Kinoite == Summary == Introduce Fedora Kinoite as a variant of Fedora alongside Fedora Silverblue. == Owner == * Name: [[User:siosm| Timothée Ravier]] (travier AT redhat DOT com) * FESCo shepherd: [[User:Ngompa| Neal Gompa]] (ngompa13 A gmail D com) * SIG: [[SIGs/KDE|KDE SIG]] == Detailed Description == Fedora Kinoite is an immutable desktop operating system featuring the KDE Plasma desktop. It is based on the same technologies as Fedora Silverblue (rpm-ostree, Flatpak, podman). Fedora Kinoite is to the Fedora KDE Spin what Fedora Silverblue is to Fedora Workstation. We chose the Kinoite name for the following reasons: * KDE based projects traditionally start with a 'K' * Kinoite is a blue mineral (https://en.wikipedia.org/wiki/Kinoite) thus referring to both the 'silver' and 'blue' part of Silverblue and the blue color of the KDE logo. * "Kinoite" means "There is a tree" in Japanese (https://translate.google.com/?sl=auto&tl=en&text=kinoite&op=translate) thus referring to the 'tree' in 'ostree'. == Benefit to Fedora == This will make Fedora more attractive to users that are interested in immutable OSes and underlying technologies but would prefer to use the KDE desktop environment. This should also strengthen Silverblue as more effort may be put into fixing the issues in the shared technologies. == Scope == * Proposal owners: ** The KDE SIG will submit the [https://pagure.io/pungi-fedora Pungi changes] needed to add this new variant to the compose. ** The KDE SIG will submit the changes to add a new sub-package to [https://src.fedoraproject.org/rpms/fedora-release fedora-release]. ** The KDE SIG will maintain the Kinoite specific rpm-ostree config in the [https://pagure.io/workstation-ostree-config workstation-ostree-config repo]. * Other developers: N/A (not a System Wide Change) * Release engineering: Submitted as [https://pagure.io/releng/issue/9952 #9952]. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: The "Fedora Kinoite" trademark has been [https://pagure.io/Fedora-Council/tickets/issue/344 approved] * Alignment with Objectives: N/A == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == This edition has been built and made available as an unofficial preview and can be tested with the instructions from this [https://fedoramagazine.org/discover-fedora-kinoite/ Fedora Magazine article]. == User Experience == Current limitations (last updated 2021-01-18): * No rpm-ostree support in Discover (graphical package and update manager). A Season of KDE is in progress to work on that. * Partial Flatpak support in Discover. * [https://pagure.io/fedora-kde/SIG/issue/13 KDE applications are not yet available as Flatpak from the Fedora registry]. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == Report to the next release. * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? N/A == Documentation == A lot of the known issues impacting Fedora Kinoite are shared with Silverblue and their resolution is the same: https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/. It is not clear for now if Kinoite specific documentation is needed but a landing page with pointer to known issues might be good. == Release Notes == Fedora Kinoite has been introduced as a new variant of Fedora Linux featuring the KDE desktop environment and the same technologies as Silverblue (rpm-ostree, Flatpak, podman). -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

2 1

Fedora 33 network configuration (ifcfg*) migration guide available?
by Peter Boy 27 Sep '21

27 Sep '21

With Fedora 33 network configuration is by default persisted in /etc/NetworkManager/system-connections/*.nmconnection files. The old /etc/sysconfig/network-scripts/ifcfg* files are „legacy“. They are still being processed for the time being, but obviously it is time to migrate. (cf https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_if…) Is there a kind of „mapping“ ifcfg-* —> *-nmconnection. ? Most items are simple to migrate, but servers in particular sometimes have unusual configurations, e.g. - for p2p Connections: SCOPE="peer xxx.yyy.zzz.aaa" - and corresponding a lot of (ADDRESSx / NETMASKx / GATEWAYx ) entries in route-{ifname} file How do I handle that kind of config items in *.nmconnection ? The "search engine I trust" couldn't answer that for me (or I couldn’t ask the right question). Thanks Peter

7 9

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 June 2021