devel February 2021

devel@lists.stg.fedoraproject.org

226 participants
377 discussions

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

Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
by Ben Cotton 31 Aug '21

31 Aug '21

https://fedoraproject.org/wiki/Changes/Autoconf_271 == Summary == Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora. == Owner == * Name: [[User:odubaj| Ondrej Dubaj]] * Email: odubaj(a)redhat.com == Detailed Description == Upgrading autoconf from version 2.69 to version 2.71 according to new upstream release. Version 2.70 is skipped due to multiple ABI incompatibilities, where some of them were fixed in version 2.71. Years of development differ these two releases, so problems are expected. This change might easily cause fails during builds of multiple packages, as some of them still require autoconf-2.69. This step must be properly discussed with maintainers of dependent packages, which should forward this change proposal to their upstream projects. == Benefit to Fedora == Brings a stable and up-to-date version of autoconf according to upsteam release. It is expected, that in the future many upstream development teams will use autoconf-2.71 as their default builder, so Fedora will be prepared for such a step. == Scope == * Proposal owners: **Prepare autoconf-2.71 as RPM package for Fedora Rawhide **Check software that requires `autoconf` or `autoconf-2.69` and rebuild it with autoconf-2.71 **Build autoconf-2.71 to Rawhide in a side-tag (https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag) **Rebuild depended packages with autoconf-2.71 in the side-tag **Merge the side-tag to Rawhide * Other developers: **Check if their packages can be build with autoconf-2.71 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == Problems during build can appear in multiple packages what can lead to build failure, as multiple packages require autoconf-2.69 as their upstream dependency. These problems have to be resolved before adding autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages are having problems during build, which could be caused by a problem with same pattern. == How To Test == Rebuilding your packages with autoconf-2.71 dependency in copr (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/) Mass rebuild of dependent packages in a side tag. == User Experience == Users will be able to use the newer version (2.71) of autoconf, and building packages with autoconf-2.69 won't be available, as it won't be present on the specific fedora version. This can affect 3rd partly packages, which are not part of Fedora. == Dependencies == Hundreds of packages have build dependency on autoconf, therefore it is a huge step forward for Fedora, what should be properly discussed and tested. List of dependent packages with their ability to be built with autoconf-2.71 can be found in the given copr project (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/) We should also look at dependent packages of `libtool` and `automake` (other critical autotools packages), as there might be some incompatibilities with the new autoconf version. == Contingency Plan == * Contingency mechanism: moving this change to Fedora 36, if not successfully finished until Fedora 35 branching from Rawhide * Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10) * Blocks release? No == Documentation == Latest autoconf documentation: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/in… == Release Notes == Release notes for autoconf-2.70: https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg00001.html Release notes for autoconf-2.71: https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg00000.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

24 82

Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
by Ben Cotton 12 Aug '21

12 Aug '21

https://fedoraproject.org/wiki/Changes/LTOBuildImprovements == Summary == Currently all packages that are not opted out of LTO include -ffat-lto-objects in their build flags. This proposal would remove -ffat-lto-objects from the default LTO flags and only use it for packages that actually need it. == Owner == * Name: [[User:law | Jeff Law]] * Email: law(a)redhat.com == Detailed Description == -ffat-lto-objects was added to the default LTO flags to ensure that any installed .o/.a files included actual compiled code rather than just LTO bytecodes (which are stripped after the install phase). However, that is wasteful from a compile-time standpoint as few packages actually install any .o/.a files. This proposal would remove -ffat-lto-objects from the default LTO flags and packages that actually need the option would have to opt-in via an RPM macro in their .spec file. This should significantly improve build times for most packages in Fedora. To ensure that we can identify packages that need the opt-in now and in the future, the plan is to pass to brp-strip-lto a flag indicating whether or not the package has opted into -ffat-lto-objects. If brp-strip-lto finds .o/.a files, but the package has not opted into -ffat-lto-objects, then brp-strip-lto would signal an error. == Benefit to Fedora == The key benefit to Fedora is improved package build times and lower load on the builders. == Scope == * Proposal owners: The feature owner (Jeff Law) will need to settle on a suitable RPM macro to indicate an opt-in to -ffat-lto-objects, implement the necessary tests in brp-strip-lto and opt-in the initial set of packages. This will be accomplished by doing the prototype implementation locally, building all the Fedora packages to generate the opt-in set. Committing the necessary opt-ins, then committing the necessary changes to the RPM macros. * Other developers: There should be minimal work for other developers. The most likely scenarios where other developers will need to get involved would include: # Packages which are excluded from x86_64 builds and which need the opt-in will need the appropriate package owners to add the opt-in. # Packages which are FTBFS when the builds are run to find the set of packages that need to opt-in and which need to opt-in will need packager attention. # It is possible that the faster builds may trigger build failures in packages that have missing dependencies in their Makefiles. We saw a few of these during the initial LTO work and those packages were either fixed or -j parallelism removed. This work may expose more of these problems. I expect these all to be relatively rare occurences, but with 9000+ packages in Fedora I wouldn't be surprised if we see a few of each of these issues. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) This should have no release engineering impacts. * Policies and guidelines: The packaging guidelines will need to be updated to document the new macro. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: This proposal does not align with any current Fedora Objectives. == Upgrade/compatibility impact == This change should have zero impact on upgrade/compatibility. In fact, the change should have no user visible impacts. == How To Test == No special testing is needed. Any issues with this proposal will show up as FTBFS issues. == User Experience == Users should see no changes to the user experience. == Dependencies == Packages which need to opt-in to -ffat-lto-objects will need their .spec files updated to include the new macro. == Contingency Plan == If this can not be completed by final development freeze, then the RPM macro changes would not be installed and the change could defer to Fedora 35. * Contingency mechanism: Proposal owner will only commit the RPM macro changes once the opt-in package set has been identified and opt-ins added to those package's spec files. So no special contingency mechanism should be needed * Contingency deadline: It is most beneficial to have this completed before the mass rebuild; however, the drop dead date should be beta freeze. * Blocks release? No * Blocks product? No == Documentation == No upstream documentation. Packaging guidelines will need a minor update. == Release Notes == I do not expect this change to require any release notes. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

8 16

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

How to easily automate test builds in a COPR project
by Richard Shaw 29 Jul '21

29 Jul '21

I maintain a suite of ham radio related packages. The developer is very active and often creates test versions adding and incrementing the "tweak" part of the version which is removed for the full releases and the patch level incremented. Currently I'm just trying to keep up with them by hand using pagure forks of the official repos so I don't accidentally pollute SCM with the changes and build them in COPR. Things I need to manage automagically: 1. Monitor the test URLs to look for new versions. I could write a bash script for this and add a cron or systemd timer but I was hoping for something that took less time as I don't have a lot of that :) Would it be permissible to create a <package>-testing entry in release-monitoring.org? 2. Trigger a "fedpkg clone" and add a tweak version. This could probably be managed with macros easy enough, %{?tweak}, or something like that. And then use a script to substitute into "%global tweak ..." 3. I need to download the files from a different location. %if %{?tweak} ... use difference Source0? 4. Build the packages in COPR. Easy enough using a bash script but is there a better way? Thanks, Richard

6 7

The future of legacy BIOS support in Fedora.
by Jóhann B. Guðmundsson 07 Jul '21

07 Jul '21

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. Now in 2017 Intel's technical marketing engineer Brian Richardson revealed in a presentation that the company will require UEFI Class 3 and above as in it would remove legacy BIOS support from its client and datacenter platforms by 2020 and one might expect AMD to follow Intel in this regard. So Intel platforms produced this year presumably will be unable to run 32-bit operating systems, unable to use related software (at least natively), and unable to use older hardware, such as RAID HBAs (and therefore older hard drives that are connected to those HBAs), network cards, and even graphics cards that lack UEFI-compatible vBIOS (launched before 2012 – 2013) etc. This post is just to gather feed back why Fedora should still continue to support legacy BIOS boot as opposed to stop supporting it and potentially drop grub2 and use sd-boot instead. Share your thoughts and comments on how such move might affect you so feedback can be collected for the future on why such a change might be bad, how it might affect the distribution and scope of such change can be determined for potential system wide proposal. Regards Jóhann B. 1. https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration

78 316

Sundials-5.7.0
by Antonio T. sagitter 17 May '21

17 May '21

Hi all. 'sundials-5.7.0' is coming in Rawhide branch. Is reasonable pushing it in f34 too? Release notes: https://computing.llnl.gov/projects/sundials/release-history -- --- Antonio Trande Fedora Project mailto: sagitter(a)fedoraproject.org GPG key: 0x29FBC85D7A51CC2F GPG key server: https://keys.gnupg.net/

3 6

plocate?
by Zbigniew Jędrzejewski-Szmek 13 May '21

13 May '21

Debian is apparently switching to plocate as the the default locate/mlocate provider [0], a bit faster and more disk-efficient. Would it make sense to do the same in Fedora? I prepared a package [1, 2]. The code seems nice and clean enough. I'd be happy to take it through review, but I'm not particular keen on long-term maintenance… [0] https://lwn.net/Articles/846405/ [1] http://in.waw.pl/~zbyszek/fedora/plocate.spec [2] https://copr.fedorainfracloud.org/coprs/zbyszek/plocate Zbyszek

6 8

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

Thoughts about packaging a standalone python-PyQt5-sip?
by Michel Alexandre Salim 27 Apr '21

27 Apr '21

Hi all, Neal and I are looking at getting ButterManager packaged, and it depends on sip and PyQt5-sip: https://github.com/egara/buttermanager/blob/master/requirements.txt Now, this is where things get a bit odd: - the current sip (4.19.24) does not have autogenerated Python provides, but sip5 does: $ sudo dnf repoquery --provides sip Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53 PM PST. sip = 4.19.24-1.fc33 sip(x86-64) = 4.19.24-1.fc33 sip-macros = 4.19.24-1.fc33 $ sudo dnf repoquery --provides sip5 Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53 PM PST. python-sip5 = 5.5.0-1.fc33 python3-sip5 = 5.5.0-1.fc33 python3.9-sip5 = 5.5.0-1.fc33 python3.9dist(sip) = 5.5 python3dist(sip) = 5.5 sip5 = 5.5.0-1.fc33 sip5(x86-64) = 5.5.0-1.fc33 - sip ships PyQt5 bindings with matching version, but sip 5 seems to no longer do so $ sudo dnf info python3-pyqt5-sip Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53 PM PST. Installed Packages Name : python3-pyqt5-sip Version : 4.19.24 Release : 1.fc33 Architecture : x86_64 Size : 244 k Source : sip-4.19.24-1.fc33.src.rpm Repository : @System From repo : fedora Summary : SIP - Python 3/C++ Bindings Generator for pyqt5 URL : https://riverbankcomputing.com/software/sip/intro License : GPLv2 or GPLv3 and (GPLv3+ with exceptions) Description : This is the Python 3 build of pyqt5-SIP. - https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in Fedora (available since last month) - there's a lot of packages that depend on python3-pyqt5-sip (though none use the canonical python3dist(pyqt5-sip) unfortunately) $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires 'python3dist(pyqt5-sip)' Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020 04:28:29 PM PST. $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires python3-pyqt5-sip Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020 04:28:29 PM PST. calibre-0:4.23.0-3.fc34.x86_64 krita-0:4.4.1-1.fc34.i686 krita-0:4.4.1-1.fc34.x86_64 libarcus-0:4.8.0-1.fc34.src mingw-python-qt5-0:5.15.0-4.fc34.src pyqtwebengine-0:5.15.0-2.fc33.src python-pyface-0:7.1.0-1.fc34.src python-pynest2d-0:4.8.0-1.fc34.src python-qt5-0:5.15.0-5.fc34.src python3-arcus-0:4.8.0-1.fc34.x86_64 python3-arcus-lulzbot-0:3.6.21-8.fc34.x86_64 python3-poppler-qt5-0:0.75.0-6.fc33.x86_64 python3-pyqtchart-0:5.15.2-1.fc34.i686 python3-pyqtchart-0:5.15.2-1.fc34.x86_64 python3-qgis-0:3.16.1-2.fc34.i686 python3-qgis-0:3.16.1-2.fc34.x86_64 python3-qscintilla-qt5-0:2.11.5-1.fc34.x86_64 python3-qt5-base-0:5.15.0-5.fc34.i686 python3-qt5-base-0:5.15.0-5.fc34.x86_64 qhexedit2-0:0.8.9-2.fc33.src scidavis-0:2.3.0-2.fc33.src veusz-0:3.3.1-1.fc34.src veusz-0:3.3.1-1.fc34.x86_64 Any idea what's the best way to handle this? and/or why PyQt5-sip's versioning get so far ahead of sip? Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

4 16

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