devel May 2020

devel@lists.stg.fedoraproject.org

246 participants
390 discussions

[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

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

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

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

Re-Launching the Java SIG
by Fabio Valentini 15 Sep '21

15 Sep '21

This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now. What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here: - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied by an old, unused bot account) - new private mailing list: java-maint-sig (for RHBZ bugs - so, possibly, also CVEs - hence, private) - tracking project on pagure: https://pagure.io/java-maint-sig (for maintenance scripts, tracking tickets, awesome package dashboards, etc.) There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net) which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file. Major upcoming projects for the "new" Java Package Maintainers group include: - managing OpenJDK 11 / Java 11 transition for hundreds of Java packages in fedora 33 - starting to transition well-maintained Java packages from the Stewardship SIG back into Java SIG - possibly porting packages from gradle to maven to fix build issues and broken dependencies - transitioning from old java.net / JavaEE projects to the new ones now under the eclipse-ee4j umbrella I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well. So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list. Let's make this happen. Fabio

36 90

pdftk retired?
by Michael J Gruber 08 Sep '21

08 Sep '21

I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael

17 26

Assimp soname bump
by Rich Mattes 31 Jul '21

31 Jul '21

Hi, I plan to update assimp from 3.3.1 to the latest release (5.0.1) in rawhide this week. The following packages will be affected: fawkes-0:1.3.0-11.fc33.src mrpt-0:1.4.0-17.fc33.src pioneer-0:20200203-1.fc33.src vkmark-0:2017.08-0.8.20180123git68b6f23.fc32.src I will take care of the rebuilds and any fallout/updates that need to happen. Rich

2 2

Remove old GPG keys?
by Miroslav Suchý 04 May '21

04 May '21

I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remov… with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from… And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? Mirek

15 29

Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok 28 Mar '21

28 Mar '21

Recently I've reported some Big Endian related test failures to an upstream project [0]. I was asked by an upstream project maintainer, whether I know some free Continuous Integration services where they can easily run their testsuite on Big Endian. Any tips? * Upstream uses Travis CI to test on x86_64 Linux (Ubuntu) * Upstream uses AppVeyor to test on Microsoft Windows * It's a pure Python project, noarch, but some changes need to be done when loading/saving binary data (LE) with NumPy on BE system. What I've considered: * COPR (but there is no big endian arch) * (Ab)using Koji (I guess that would be considered a bad practice?) * using QUEMU on Travis CI [1] Any better tips? Thanks [0] https://github.com/mikedh/trimesh/issues/249 [1] https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

8 10

git push permission denied
by Neal Becker 10 Feb '21

10 Feb '21

I just had to setup a new machine, and new ssh keys. I visited https://admin.fedoraproject.org/accounts/user/edit/xxxx I chose my new id_rsa.pub to upload. But I get: git push --verbose Pushing to ssh://nbecker@pkgs.fedoraproject.org/mercurial Permission denied (publickey). fatal: The remote end hung up unexpectedly Hints?

4 5

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 May 2020