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
8 hours, 13 minutes
Orphaning the cura-lulzbot package set
by Tom Callaway
This fork of cura has basically been abandoned by upstream, and the new
company that acquired Lulzbot has gone out of compliance with the source
code for the firmware. They have made it very clear that they have no real
interest in working with the community to improve this situation, and I no
longer have any motivation to maintain these packages.
Accordingly, I've orphaned the following packages:
* cura-lulzbot
* lulzbot-marlin-firmware
* CuraEngine-lulzbot
* python-uranium-lulzbot
~spot
P.S. I opened an upstream pull request to add support for the Lulzbot TAZ
Pro and the Mini 2 in the main Cura codebase (still actively maintained). I
would highly recommend that anyone considering reviving these packages
devote their efforts in that direction instead.
2 days, 3 hours
ELN composes on mirrors
by Davide Cavalca
I had filed https://github.com/fedora-eln/eln/issues/33 a while ago to
track documentation improvements around how to consume ELN composes.
I'd like to take a step back and propose adding them to the mirror
network, akin to what we already do for Rawhide. This would make it
trivial to consume or mirror them locally (e.g. via rsync), without
having to hit ODCS directly. The only downside I can think of is that
it'd consume a bit more storage on the mirrors themselves. Thoughts?
Cheers
Davide
5 days, 2 hours
Fedora's GPG key in DNS(SEC)
by Miroslav Suchý
All Fedora's GPG key - starting with Fedora 27 - are now stored in fedoraproject.org DNS record and can be verified
using DNSSEC.
Why? How it can be used? That is long story and you can read about it in my blog entry:
http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_sign...
Few last minutes notes here:
- there are still some gotchas which should be fixed. But enough code is already in production - you can play with it
now. Relevant issues are linked in the blog post.
- the DNF team is migrating their code to libdnf, I do not have any guarantee when this piece of code will be
migrating - so we are far from enabling this by default.
Comments are welcomed.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
6 days, 6 hours
F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RPM-4.17
== Summary ==
Update RPM to the [https://rpm.org/wiki/Releases/4.17.0 4.17] release.
== Owner ==
* Name: [[User:pmatilai|Panu Matilainen]]
* Email: [pmatilai(a)redhat.com]
== Detailed Description ==
RPM 4.17 contains numerous improvements over previous versions
* More robust install failure handling
* Many macro improvements, in particular much improved Lua integration
* Strict checking for unpackaged content in builds
* Libraries no longer need executable permission for dependency
generation and is automatically removed for non-executable libraries
* Long needed transaction APIs enhancements
* Improved documentation
* Tentative (planned but not committed as of this writing)
** Split debugedit to its own project and package
** Split language-specific packaging aids to separate projects
(Python, Perl, Ocaml...)
** Dynamic spec generation
The plan is to get 4.17-alpha into rawhide as early as possible
(during April) to sort out any initial rough edges long before the
general feature deadline rush. Final version is expected to be
released well in time before F35 beta.
== Benefit to Fedora ==
See description for overall benefits, but in particular:
* All users benefit from the more robust installation
* Packaging sanity wrt libraries
* Macro authors will have a much saner experience creating complex macros in Lua
* DNF for the enhanced transaction APIs
== Scope ==
* Proposal owners:
** Rebase RPM
** Assist with dealing with incompatibilities
* Other developers:
** Test new release, report issues and bugs
** Adjust packaging to adhere to the strict buildroot content checking
* Release engineering: [https://pagure.io/releng/issue/10072 #10072]
* Policies and guidelines:
** Guidelines have nothing on unpackaged contents in buildroot, so
don't necessarily need updating. Many packages will fail to build
because of the stricter checking though: with rpm >= 4.17 unpackaged
content is not permitted in the buildroot at all.
** Libraries no longer need to be executable for dependency
generation, and executable bit will in fact be removed if invalidly
set on a library. Guidelines only have a vague "executable if
appropriate" mention so it does not *need* changing but could now be
clarified/tightened if desired.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: no relation to current objectives
== Upgrade/compatibility impact ==
* Many existing packages will fail to build due to the stricter
buildroot content checking. Fixing this in the packaging is always
backwards compatible. We could temporarily set
`%_unpackaged_files_terminate_build 0` in rawhide to alleviate initial
impact if necessary.
* Rpm no longer implicitly creates databases on read-only access, this
may require changes to existing scripts/tooling. Ensuring mock/dnf
works is a pre-requisite to landing this change into rawhide, and will
be handled, one way or the other, by the rpm maintainers.
== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.
== User Experience ==
The user-experience remains largely as-is, but install failures are
handled more gracefully.
== Dependencies ==
* dnf and/or mock will likely need some adjusting for the lack of
implicit database creation. If necessary, rpm maintainers will provide
patches prior to landing this change.
* soname bump is not expected so rebuilds should not be required
== Contingency Plan ==
* Contingency mechanism: Revert back to RPM 4.16, but the risk of
having to do should be negligible
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
Work-in-progress release notes at https://rpm.org/wiki/Releases/4.17.0
and reference manual at
https://github.com/rpm-software-management/rpm/blob/master/doc/manual/ind...
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
6 days, 10 hours
thinking journal retention timelimits
by Matthew Miller
As we start a new year, I'm thinking about data retention in general. :)
In my experience, it's pretty rare on an end-user laptop or desktop system for
logs from much more than the previous boot to be interesting. Maybe I
occasionally want to look back a little while to see if a problem just
started. It's exceedingly rare that I need (or want) to look back more than
a month.
Right now, we don't set MaxRetentionSec, so journal expiry on Workstation is
entirely based on disk usage.
Logs can accidentally contain sensitive data, and it's just plain faster to
work with them when there's less. I propose we set this to something like
six months by default.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 days, 22 hours
Donate 1 minute of your time to test upgrades from F33 to F34
by Miroslav Suchý
Do you want to make Fedora 34 better? Please spend 1 minute of your time and try to run:
# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'
sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \
--enablerepo=updates-testing --enablerepo=updates-testing-modular \
distro-sync
This command does not replace `dnf system-upgrade`, but it will reveal potential problems. You may also run `dnf
upgrade` before running this command.
If you have have rdma-core.i686 installed you have to pass `--allowerasing`.
https://bugzilla.redhat.com/show_bug.cgi?id=1919864
If you get this prompt:
...
Total download size: XXX M
Is this ok [y/N]:
you can answer N and nothing happens, no need to test the actual upgrade.
But very likely you get some dependency problem now. In that case, please report it against the appropriate package. Or
against fedora-obsolete-packages if that package should be removed in Fedora 34. Please check existing reports against
fedora-obsolete-packages first:
https://red.ht/2kuBDPu
and also there is already bunch of "Fails to install" reports:
https://bugzilla.redhat.com/show_bug.cgi?id=F34FailsToInstall
Thank you
P.S. sent from workstation successfully upgraded to F34 :)
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
1 week
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
1 week
Multiple snapshots and versioning
by Artur Frenszek-Iwicki
I'm looking to package some GTK themes. Those themes come in several colour
variants. The author decided on a workflow where, instead of keeping variants
alongside each other in the tree, each variant has its own git branch.
When working with git snapshots, the packaging guidelines [1] say to put
the snapshot data in the Release: field. This is simple enough when working
with a single "main" source, but what when there's multiple sources?
A solution could be to put each colour variant into a subpackage,
and make the "main" package a file-less package that just Requires:
all the colour variants. This way, each subpackage can have a different
Release: tag. However, doing this messes with rpmdev-bumpspec, which
gets confused and slaps ".1" at the end of each subpackage's Release: tag,
which in turn makes the Requires: unsatisfiable.
I could, alternatively, put the snapshot data in each subpackage's
Version: tag, but this goes against the Guidelines.
I could also just pretend that there's only one source, ship everything as one
package, and only use the snapshot info for the "main" branch. Though
this is a rather inelegant approach.
So, I guess my question is: what would be the preferred approach?
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_sn...
1 week, 3 days
Depict: package dependency visualizer
by Jerry James
Hello all,
There is no reason anybody should remember, but last summer I
mentioned 3 tools that I really wanted to help me deal with packaging
issues. The first was opam2rpm, which I started work on last fall.
It isn't done by a long shot, but it is useful enough that I started
working on tool #2.
Introducing "depict", a Python tool to visualize package dependencies:
https://pagure.io/depict
The name is supposed to suggest "DEpendency PICTure", unless somebody
can come up with a better expansion. :-) I wanted this tool to help
me see package dependency cycles, and find ways of breaking them.
Depict comes with the ability to detect cycles and suggest low-cost
ways of breaking them (for a user-defined notion of "cost"). It's
still alpha quality, but I think it has reached a point where some of
you may find it useful. I welcome suggestions for improvement, and
pull requests are even better.
Depict can currently read dependency information from a local RPM
database, from opam (a collection of OCaml packages), and from a
specialized JSON format. I would like to eventually add a "dnf
repoquery" style front end, as well as one for Maven Central.
Here are some excessively complex examples:
Example 1:
python3 -m depict \
--input=json examples/rpm.js \
--input=rpm --stop dbus-broker:dconf:glibc:gcc:libgcc:systemd-udev \
--exclude alternatives:bash:ca-certificates:coreutils:crypto-policies:crypto-policies-scripts:device-mapper:dracut:fedora-release-common:fedora-release-workstation:fedora-repos:filesystem:fonts-filesystem:gawk:gdk-pixbuf2-modules:grep:grubby:gtk-update-icon-cache:hwdata:mkpasswd:nss-util:nss-sysinit:os-prober:pam:pcre2-syntax:python-unversioned-command:python3:python3-setuptools:rpm-libs:sed:setup:shadow-utils:shared-mime-info:systemd:tzdata
\
firefox --graph=dag --solver=ppl --output=dot firefox.dot
That says to:
1. read the JSON file examples/rpm.js, which contains some visual styling;
2. read from the RPM database:
a. If any of the packages dbus-broker, dconf, etc. are encountered, add them
to the dependency graph, but don't follow their dependencies any further.
b. If any of the packages alternatives, bash, etc. are encountered, do not
add them to the dependency graph.
c. Add the package firefox and its dependencies to the graph, subject to
(a) and (b).
3. compute a Directed Acyclic Graph (DAG) from the original dependency graph
a. use the PPL solver to find low-cost dependencies to remove
4. write the DAG in dot format to firefox.dot. The dot tool, from the graphviz
package, can then convert it into a variety of formats; e.g.,
dot -Tpdf firefox.dot > firefox.pdf
Example 2:
python3 -m depict --up --input=json examples/rpm.js --input=rpm flint
--output=dot flint.dot
That says to compute "up" dependencies instead of the default "down"
dependencies. "Up" means to find the packages that depend on those
listed on the command line. "Down" means to find packages that are
depended upon by the packages listed on the command line. So this
example finds every package installed on my machine that depends on
flint, directly or indirectly.
Example 3:
python3 -m depict --input=json examples/opam.js \
--input=opam --exclude mirage-xen:mirage-xen-ocaml --stop ocaml \
--omit-edges 'spawn,ppx_expect:bisect_ppx,ocamlformat:functoria-runtime,dune'\
--repository ~/src/opam-repository ocaml:4.12.0 \
async ANSITerminal apron atdgen base64 cmdliner core conf-autoconf conf-gmp \
conf-mpfr conf-sqlite3 conf-zlib ctypes dune elina javalib mlgmpidl mtime \
ocamlfind ocamlgraph ounit parmap ppx_deriving ppx_fields_conv ppx_let \
sawja sqlite3 utop xmlm yojson zarith \
--graph=dag --output=dot infer.dot --output=layered -
That says to:
1. read the JSON file examples/opam.js, which contains some visual styling;
2. read from opam:
a. If the packages mirage-xen or mirage-xen-ocaml are encountered, do not
add them to the dependency graph.
b. If the package ocaml is encountered, do not add any of its dependencies
to the graph.
c. If any opam file tries to add a dependency from spawn to ppx_expect,
from bisect_ppx to ocamlformat, etc. do not add those dependencies to the
graph. I omitted these because they represent dependencies on old
versions.
d. Use a local checkout of opam-repository rather than making HTTP requests
to github. You really, really do NOT want to make HTTP requests to
github to read opam information. That method is sloooooooooooow.
e. Add the packages ocaml, async, etc. and their dependencies to the graph,
subject to (a), (b), and (c). In addition, specify that we want version
4.12.0 of the ocaml package. These are the direct dependencies of
Facebook's Infer tool, in case you are wondering.
3. compute a Directed Acyclic Graph (DAG) from the original dependency graph
4. write the DAG in dot format to infer.dot.
5. write a "layered" description of the package dependencies to standard out.
Layer 0 consists of packages with no dependencies in the graph. Layer 1
contains packages whose dependencies all lie in layer 0, and so on.
The documentation is a horrible mess, and the tests are nearly
nonexistent, which is why I have marked this as alpha quality. The
RPM front end is actually in quite good shape. The opam front end is
coming along, but needs some more work.
Feel free to make pull requests against the TODO file if you see some
way depict can be improved that isn't already listed there.
Regards.
--
Jerry James
http://www.jamezone.org/
1 week, 4 days