Announcing fmt library soversion bump
by Vitaly Zaitsev
Hello.
fmt 8.0.x update will include soversion bump from .7 to .8.
All dependent packages must be rebuilt in Rawhide.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2 years, 7 months
pdftk retired?
by Michael J Gruber
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
2 years, 7 months
perl-Data-Properties License change
by Emmanuel Seyman
Hello, folks.
Sometime over the coming week, I'm going to update the
perl-Data-Properties package from the current 0.02 to 1.05.
Among other changes, the license changes from ASL 2.0 to the Perl
license (GPL+ or Artistic).
Please holler if this creates a problem for you.
Regards,
Emmanuel
2 years, 7 months
replace memtest86+ with pcmemtest, needs maintainer
by Chris Murphy
[Bug 1988142] memtest boot entry on Fedora install media does not work
since Fedora-Rawhide-20210728.n.3
https://bugzilla.redhat.com/show_bug.cgi?id=1988142
This bug might be gcc, but also includes a note about the upstream
being kinda weak, possibly non-existent these days.
Neal Gompa mentioned pcmemtest earlier this year
https://github.com/martinwhitaker/pcmemtest
It would need a maintainer. Any takers?
Fedora doesn't have a release criterion covering the memory tester, or
really any option appearing in the install media's boot menu other
than the one that launches the installer. But I think it's better to
not ship a memory tester at all, than to ship a broken one (given the
options).
Memtest86+ is bios only, where pcmemtest can be compiled to run on
either firmware type. If we want it to work with UEFI Secure Boot
enabled, it'd need to be signed with Fedora's key (I think the same as
the one used for GRUB and/or the kernel?). This would be in scope for
Fedora 36, assuming the above bug can be easily fixed.
But if that bug is hard to fix, and pcmemtest could be a drop-in
replacement (i.e. bios only, just like now) maybe that's doable for
Fedora 35, and better than having no memory tester.
Chris Murphy
--
Chris Murphy
2 years, 7 months
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