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
rpkg-3.rc2 built into rawhide
by clime
Hello,
I have built rpkg-3.rc2 (package sources:
https://src.fedoraproject.org/rpms/rpkg-util) into rawhide yesterday.
It should be now available for installation.
It is a complete rewrite of version 2. It aims to be a tool with
minimal deps that allows people to easily transform git repositories
containing spec files into rpm packages.
Historically, the goal of this tool was to provide a single client to
all dist-git instances (i.e Fedora, CentOS, maybe something else too).
This was the idea when I started to work on it still in RedHat under
the lead of Miroslav Suchý. We wanted to tweak the rpkg script
provided by python-rpkg lib (https://pagure.io/rpkg) for that purpose.
However, that script was soon being discontinued. There I created a
separate project (rpkg-util) which would be providing the script so
that I can continue in my goal.
Eventually, I realized that some steps rather need to be taken
server-side (https://github.com/release-engineering/dist-git) for a
generic client to exist so that I did and then it was about adoption
of the dist-git package (which provides the unified interface) by
various dist-git instances.
Meanwhile, I was thinking what to do next with rpkg while being
heavily influenced by Copr that I primarily worked on at that time and
also by discussion on devel list about automatically generating
changelog and release from git. I realized there is an opportunity to
provide a solution for this in the generic dist-git client (rpkg
executable) and that it was not a bad place for it.
This problem was then and even today solved by basically sedding spec
file with regexps which I thought is kind of hacky and that it could
be useful to have a library for common substitutions anyway so that
people can reuse it. So a simple spec templating language was born
(https://docs.pagure.org/rpkg-util/v3/spec_templates_from_scratch.html)
and also a simple library of macros
(https://docs.pagure.org/rpkg-util/v3/macro_reference.html) that use git
content and metadata to render spec file content or parts of it. It
now allows not only to generate changelog or release but also e.g. to
generate a source tarball from a git submodule placed next to the spec
file.
There is also the possibility for users to define their own macros and
therefore customize git->rpm transform in any way.
You can try this now in rawhide (`dnf install rpkg`) or also in Copr
(SCM rpkg build method) but note that in Copr, there is still v2 so
there might be some differences. You might also need to install
python3-setuptools - that package seems to be required by
python3-munch but is not being brought in automatically at the moment.
You can use rpkg tool similarly to fedpkg to work with Fedora dist-git
packages (except that `rpkg build` command builds in Copr and the
command set is mostly trimmed-down) or you can use it to work with
those git layouts that contain unpackaged sources together with spec
file (or rather spec file template) or link to the upstream sources
through a git submodule.
Best regards
clime
P.S.: the project is hosted here: https://pagure.io/rpkg-util
2 years, 7 months
OpenLDAP 2.5 - Fedora Release - Help Needed
by Simon Pichugin
Hi folks,
my name is Simon Pichugin and I am a maintainer for OpenLDAP.
Recently, OpenLDAP has released 2.5 version.
It has quite a big amount of changes -
https://www.openldap.org/software/release/announce.html
And it includes a pretty important "Upgrading from 2.4.x" section -
https://www.openldap.org/doc/admin25/guide.html#Upgrading%20from%202.4.x
Also, OpenLDAP on Fedora currently has links to a versioned library:
❯ ldconfig -p | grep libldap
libldap_r-2.4.so.2 (libc6,x86-64) => /lib64/libldap_r-2.4.so.2
libldap-2.4.so.2 (libc6,x86-64) => /lib64/libldap-2.4.so.2
This makes it harder to upgrade as a lot of packages depend on the
versioned one (and the new package has only libldap-2.5.so.2 library. (I
even filed an issue to sudo but I think it's not related to them much -
https://github.com/sudo-project/sudo/issues/105 )
I came here for advice as the upgrade can be a sensitive subject for many
users.
What I think can be done:
- Rework openldap-compat package for openldap 2.5, so it will include
libldap-2.4 libs (both with and without '_r'). I am not exactly sure what's
the proper way to do this (make a tarball with the compiled libldap-2.4
libs and place it to the repo - would be okay?)
- Openldap 2.5 package will include only libldap-2.5.so.2 library and
while testing we will tag it with some build tag so we can make sure that
everything builds with it successfully.
I am not sure how we can help openldap-servers package users. Should we
create a change proposal that will include all of the information about the
upgrade (from the OpenLDAP Upstream guide)? And hope that they will read it
before the package upgrade? Is there any other way to notify them during
'dnf update'?
Please, share any of your thoughts on this issue. I'll come to a decision
sometime soon as we need to get OpenLDAP 2.5 at least in some state to the
Fedora Rawhide so it can be properly tested.
Thank you for all of your great work on our awesome Fedora!
Sincerely,
Simon
P.S. the PR for 2.5 change was filed by a community member and we already
have some discussion there -
https://src.fedoraproject.org/rpms/openldap/pull-request/6
2 years, 7 months
F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros
== Summary ==
Introduce macros, similar to openSUSE's
[https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
memory-constraints]), for optionally limiting build parallelism for
build-time memory-bound packages
== Owner ==
* Name: [[User:salimma|Michel Alexandre Salim]]
* Email: michel AT michel-slm DOT name
== Detailed Description ==
Some source packages have a memory usage per build thread higher than
the RAM:CPU ratio available in some of our builders. Further, this
ratio can be different for different build server on different
architectures.
At the moment, such packages
([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a...
ceph], [https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367d...
chromium], [https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b0...
mcrouter]) have to implement their own logic for determining the safe
amount of parallelism, and redefine `_smp_build_ncpus`.
When this proposal is implemented, they can instead declaratively
specify the amount of RAM needed per build thread, e.g.
%limit_build -m 8192
for declaring a build thread should be allocated 8GB of RAM.
Since Koji supports
[https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-cha...
setting default values for macros], there will be a macro for the
default memory limit (name TBD) that, if set, will be used to cap
`_smp_build_ncpus` unless overridden by `%limit_build -m`.
0
I'm proposing to tentatively call the macro package
`build-constraints-rpm-macros` to allow the possibility of adding
macros for related needs e.g. [https://pagure.io/copr/copr/issue/1678
build timeouts] to the same package.
== Benefit to Fedora ==
This change simplifies maintaining specs for software that are
memory-bounded rather than CPU-bounded on our build servers
It could potentially improve build reliability for these packages, by
reducing the number of jobs failing because of OOM errors, and reduce
the need for package maintainers to debug these failures.
By keeping the user-facing API aligned with what openSUSE is using, we
open up the possibility to collaborate with them and with the upstream
RPM project to get such macros upstreamed into RPM itself (see
[https://github.com/rpm-software-management/rpm/pull/821 previous
attempt]). **note** that is not in scope for this Change.
== Scope ==
* Proposal owners:
** Introduce new macros
** Update known packages to use the new macros, replacing their custom
`_smp_build_ncpus` overrides
* Other developers:
** The proposal owners might not catch all references of such logic.
Individual package maintainers can try refactoring their packages
using these new macros
* Release engineering: [https://pagure.io/releng/issue/10188 #10188]
No mass rebuild needed. Affected packages should be rebuilt using the new macro
* Policies and guidelines: Packaging guideline can be updated to
recommend using these macros for build-time memory-bound packages
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
No impact, affects package building only. Also, the use of the new
macros are optional.
== How To Test ==
1. Install `build-constraints-rpm-macros`
2. Modify spec to set `%limit_build -n AMOUNT_IN_MB` in `%build`
3. Rebuild in koji and make sure it passes on all supported architectures
== User Experience ==
== Dependencies ==
This can optionally be added as dependencies of `redhat-rpm-config`
and `epel-rpm-macros`, depending on how many packages need this
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
Revert changed packages to their previous way of capping the number of
build jobs
* Contingency deadline: beta
* Blocks release? No
== Documentation ==
Previous discussion:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
openSUSE implementation:
https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 7 months
The Death of Java (packages)
by Fabio Valentini
Hi everybody,
Long story short, I can no longer in good conscience be the primary
maintainer of (most) Java packages in Fedora. I am not using any of
them, I don't like Java or any other languages targeting the JVM, and
don't get me started on the horrid Java ecosystem. Recently I've been
spending 40-60 hours per week at my desk, and I just don't have the
capacity to feel guilty for not taking care of those packages any
longer.
New versions and even security issues have been piling up for months
(just look at the SIG's taiga board). Other people tried to step up
for the "new" Java SIG (@java-maint-sig), but other than myself,
nobody has been triaging new bugs in Java packages. Java package
maintainers from Red Hat have been exceptionally unhelpful, and have
not substantially contributed to Java packages in Fedora in years.
Even the Modules that were heralded as "the solution" have stagnated.
On the other hand, Mat Booth and two members of the DogTag PKI team
have been really helpful, but Mat is busy fighting the Eclipse
dumpster fire most of the time, and the other two have since both left
Red Hat for greener pastures. And since I see no way for the situation
to improve, there's only one honest thing left that I can do:
I will orphan all Java packages I am the main admin of, later today.
Since this is the majority of remaining Java software in Fedora (~180
packages), I expect at a decent amount of dependent packages will be
affected. However, given the utter lack of Java package maintainers
and the pitiful state of the overall language ecosystem, I would
strongly urge affected maintainers to drop dependencies on Java, if at
all possible.
Maybe other members of the java-maint-sig will pick up the orphaned
packages, if they're still here. Or maybe it's finally time to let
Java packages die. Nobody seems to care either way.
Fabio
2 years, 8 months
Stepping down as Fedora Jam maintainer
by Erich Eickmeyer
Hello all,
A little over a year ago, I came to the Fedora project to revive and
modernize the Fedora Jam project. I have successfully done that. My
vision was that it would be a great way to help develop and test the
most recent advancements in Linux audio.
Unfortunately, or fortunately, life has a way of changing for the good
or the bad. Back in November, I was offered an opportunity that I could
not pass-up: becoming the User Experience Director for the Kubuntu
Focus brand of laptops made by MindShareManagement. Since then, I have
become an integral member of that team, directly reporting to the CTO,
CEO, and President, working directly with the PR and Sales and
Marketing directors. It has been a blast, and is a project that works
directly with Ubuntu and Debian to create, as we put it, the "Ultimate
Linux Laptop". As a MOTU for Ubuntu, this was a perfect fit.
I didn't come here to be a shill for Ubuntu or to advertise my work,
but rather, to illustrate the level of involvement. It has taken up a
majority of my time, and my work with Ubuntu Studio is directly
involved with the project as well as both Ubuntu Studio and the Kubuntu
Focus laptop have similar synergies.
Because of the amount of time involved in these projects, something has
to give. For that reason, I must step-down as Fedora Jam maintainer. My
plan is to continue to maintain certain packages within Fedora (which,
admittedly, I've been slacking on), but I am orphaning the vast
majority of my packages. Here's the list:
Add64
dssi
dssi-vst
fedora-jam-backgrounds*
fedora-jam-kde-theme*
fluidsynth
fluidsynth-dssi
freqtweak
gnome-guitar
harmony-seq
hexter-dssi
jackctlmmc
jmeters
libinstpatch
lv2-c++-tools
lv2-fabla
lv2-ll-plugins
lv2-mdaEPiano
lv2-newtonator
lv2-sorcer
lv2-swh-plugins
lv2-vocoder-plugins
meterbridge
non-daw
portmidi
radium-compressor
realTimeConfigQuickScan
whysynth-dssi
xsynth-dssi
*These packages have pagure repos which I'd be happy to hand over to
whoever takes these.
I do want to thank everyone for the opportunity, including Matthew
Miller, Ben Cotton, Neal Gompa, and many others that helped me revive
this project. I'm sad to let it go, and I'm not sure what's going to
happen to it, but I hope someone who has a passion for the latest
technologies in Linux Audio and music production can take it over.
Thanks,
Erich Eickmeyer
2 years, 8 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, 8 months
