devel July 2021

devel@lists.fedoraproject.org

194 participants
353 discussions

Claim delve
by Alejandro Saez Morollon 29 Jun '22

29 Jun '22

Hi there, folks. Delve[0] (a Golang debugger) was retired due to the impossibility of building a new version of delve for dependencies issues. I would like to claim the package and fix the situation. I already have one of the dependencies[1] in the works. I already talked with the original maintainer (he's in cc) and he is OK with it. Thanks. [0] https://src.fedoraproject.org/rpms/delve [1] https://src.fedoraproject.org/rpms/golang-starlark

2 2

[HEADS UP] -Wl,--as-needed is added in rawhide
by Igor Gnatenko 26 Jun '22

26 Jun '22

It's in redhat-rpm-config-118-1.fc30. If it causes any problems for you - let me know. In the meantime, you can use `%undefine _ld_as_needed` to disable it. Thanks for attention! -- -Igor Gnatenko

4 4

GNOME only: KeepassXC quirks
by Germano Massullo 01 Mar '22

01 Mar '22

KeepassXC comaintainer here. There are many Fedora GNOME Wayland users experiencing quirks in using KeepassXC. Textboxes not showing text that is being written, other quirks with GNOME, etc. Upstream developers said many times that this only happen with Fedora users. Myself I do use KDE Spin and I do not experience these issues (tested on Wayland too) I don't paste bugs titles since they are misleading https://bugzilla.redhat.com/show_bug.cgi?id=1925130 https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8) https://bugzilla.redhat.com/show_bug.cgi?id=1954742 https://github.com/keepassxreboot/keepassxc/issues/5608 plus others that I cannot find again at the moment I would like to ask if you have any idea about why this happens on GNOME only (and not on other distros too) Thank you

10 30

Release criteria proposal: networking requirements
by Adam Williamson 01 Mar '22

01 Mar '22

Hi folks! So at this week's blocker review meeting, the fact that we don't have explicit networking requirements in the release criteria really started to bite us. In the past we have squeezed networking-related issues in under other criteria, but for some issues that's really difficult, notably VPN issues. So, we agreed we should draft some explicit networking criteria. This turns out to be a big area and quite hard to cover (who'd've thought!), but here is at least a first draft for us to start from. My proposal would be to add this to the Basic criteria. I have left out some wikitext stuff from the proposal for clarity; I'd add it back in on actually applying the proposed changes. It's just formatting stuff, nothing that'd change the meaning. Anyone have thoughts, complaints, alternative approaches, supplements? Thanks! === Network requirements === Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included). ==== Basic networking ==== It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing. The default network configuration tools for the console and for release-blocking desktops must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected. Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking ==== VPN connections ==== Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VNC servers with typical configurations. Footnote title "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

9 22

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 17 Jan '22

17 Jan '22

I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg

6 9

Orphaning luit
by Peter Hutterer 07 Jan '22

07 Jan '22

I've orphaned luit. The only user of it was xterm and it recently dropped support for luit so there are no users left. Whether there are *any* users left is unclear too :) The luit package we shipped is still the freedesktop.org one which has been unmaintained for about a decade now. Upstream now points to Thomas Dickey's fork at http://invisible-island.net/luit/ so if anyone wants to take this, I advise switching to that version as part of the first steps. Cheers, Peter

2 1

python-lxml license change
by Mikolaj Izdebski 07 Jan '22

07 Jan '22

License of python-lxml package was changed from "BSD" to "BSD and MIT and zlib"

1 1

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

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