Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
by Ben Cotton
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/...
== 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
2 years, 7 months
Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
by Ben Cotton
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
2 years, 7 months
Assimp soname bump
by Rich Mattes
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 years, 8 months
How to easily automate test builds in a COPR project
by Richard Shaw
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
2 years, 8 months
The future of legacy BIOS support in Fedora.
by Jóhann B. Guðmundsson
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
2 years, 8 months
Offering strongswan for (co)maintaining
by Petr Menšík
Hello,
strongswan and NetworkManager-strongswan packages were passed to me from
previous maintainer. I admit I have little experience with them and do
not run any service based on them. Because IPSsec is quite complex
technology, I am looking for help with its maintenance. I was always
using OpenVPN based solutions myself, so I guess I am not the best
person as main admin. I would like to transfer main admin to anyone
doing a good job, not not immediately. That is why I haven't orphaned it
already.
I would like to keep commit access for a while, but I would share at
least commit access with anyone willing to improve those packages.
Especially someone using they (almost) everyday would be ideal maintainer.
Regards,
Petr
--
Petr Menšík
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
2 years, 9 months
Thoughts about packaging a standalone python-PyQt5-sip?
by Michel Alexandre Salim
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
2 years, 11 months