[HEADS UP] Sphinx 5 and docutils 0.18.1 coming to Rawhide on July
11th
by Karolina Surma
Hello packagers,
The new major version of the popular documentation framework Sphinx has
been recently released[0]. It brings many changes, among which there is
support of docutils 0.18.1. We aim to update both packages together in
Fedora Rawhide on **July 11th**.
As usual, an ongoing attempt to smoothly integrate the updates takes
place using Copr[1]. There are some packages impacted with the new
changes. Please take time to review an fix the package, or coordinate
with the upstream.
If your package hasn't succeeded to build with Python 3.11 yet, we can't
test whether it will work with this update.
Common issues and mitigation
- `None` is no longer accepted as value of `language` in conf.py
Solution: Use `language = 'en'` instead.
- Build/ tests fail with: `AttributeError: 'path' object has no
attribute 'text'`
Solution: use `path.read_text()` instead
Test your package locally in mock using the provided test Copr
$ mock -r fedora-rawhide-x86_64
--addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/
--no-clean <your.src.rpm>
$ mock -r fedora-rawhide-x86_64
--addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/
shell
Packages that pin Sphinx and docutils to lower versions than are about
to be introduced, and will effectively stop working after the update has
reached Rawhide:
Sphinx < 5:
python-h2-0:4.1.0-7.fc37.src
python-priority-0:2.0.0-7.fc37.src
python-sphinx-panels-0:0.6.0-3.fc37.src
python-sphinx-tabs-0:3.1.0-7.fc37.src
python3-sphinxcontrib-zopeext-0:0.3.2-3.fc37.noarch
docutils < 0.18:
python-sphinx-tabs-0:3.1.0-7.fc37.src
python3-sphinx_rtd_theme-0:1.0.0-6.fc37.noarch
Full list of known affected packages
Maintainers by package:
copr-keygen clime dturecek frostyx msuchy praiskup
coq amdunn jjames
diceware kushal
kea fjanus mosvald zdohnal
libcamera javierm
liblognorm alakatos rsroka zfridric
python-django bkabrda churchyard jdornak mrunge rdopiera salimma
sgallagh
python-graphviz eclipseo
python-h2 eclipseo
python-pikepdf qulogic zdohnal
python-priority eclipseo
python-sphinx-panels qulogic
python-sphinx-tabs hobbes1069
python-sphinx_rtd_theme jjames ksurma piotrp
python-sphinxcontrib-bibtex jjames
python-sphinxcontrib-htmlhelp churchyard cstratak
python-sphinxcontrib-jsmath churchyard cstratak
python-sphinxcontrib-qthelp churchyard cstratak
python-sphinxcontrib-zopeext jjames
Packages by maintainer:
alakatos liblognorm
amdunn coq
bkabrda python-django
churchyard python-django python-sphinxcontrib-htmlhelp
python-sphinxcontrib-jsmath python-sphinxcontrib-qthelp
clime copr-keygen
cstratak python-sphinxcontrib-htmlhelp python-sphinxcontrib-jsmath
python-sphinxcontrib-qthelp
dturecek copr-keygen
eclipseo python-graphviz python-h2 python-priority
fjanus kea
frostyx copr-keygen
hobbes1069 python-sphinx-tabs
javierm libcamera
jdornak python-django
jjames coq python-sphinx_rtd_theme python-sphinxcontrib-bibtex
python-sphinxcontrib-zopeext
ksurma python-sphinx_rtd_theme
kushal diceware
mosvald kea
mrunge python-django
msuchy copr-keygen
piotrp python-sphinx_rtd_theme
praiskup copr-keygen
qulogic python-pikepdf python-sphinx-panels
rdopiera python-django
rsroka liblognorm
salimma python-django
sgallagh python-django
zdohnal kea python-pikepdf
zfridric liblognorm
Cheers,
Karolina Surma
[0] https://www.sphinx-doc.org/en/master/changes.html
[1] https://copr.fedorainfracloud.org/coprs/ksurma/sphinx-5/
1 year, 9 months
F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
by Vipul Siddharth
https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
We are going to deprecate openssl1.1 package, stop shipping the
corresponding devel package, and stop respecting crypto policies in
openssl1.1 package itself.
== Owner ==
* Name: [[User:DmitryBelyavskiy| Dmitry Belyavskiy]]
* Email: dbelyavs(a)redhat.com
== Detailed Description ==
In Fedora 36 we switched to OpenSSL 3.0 branch. This is a brand new
version with new architecture. We left the openssl1.1 package for the
applications that were unable to switch to the new API/architecture,
3rd-party applications, etc. As openssl 1.1 has a predictable EOL, we
want to ensure that no new products relying on it will appear in
Fedora.
== Benefit to Fedora ==
This proposal ensures than no new packages in Fedora will rely on the
deprecated OpenSSL version that will cause an overall increase of
security/stability, and will reduce the amount of old packages relying
on OpenSSL 1.1 series.
It will also reduce the maintenance burden for the OpenSSL
maintainers, especially when new CVEs are published.
== Scope ==
* Proposal owners:
** Remove devel package
** eliminate crypto policy support from the main package
** provide assistance in migration to other developers
* Other developers:
** Patch their packages to work with OpenSSL 3.0
** Fedora/RHEL distributions provide some syntax sugar related to
https://fedoraproject.org/wiki/Packaging:CryptoPolicies. For the
packages still relying to openssl1.1 the syntax provided by crypto
policies will no longer be supported. The changes implemented
according to https://fedoraproject.org/wiki/Packaging:CryptoPolicies
(e.g. using "PROFILE=SYSTEM" as default TLS ciphersuites
configuration) should be removed.
* Release engineering: This feature doesn't require coordination with
release engineering.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
As Crypto Policy support is removed from openssl1.1, applications will
need to adjust the configuration files if they contain the line
"PROFILE=SYSTEM" according to
https://fedoraproject.org/wiki/Packaging:CryptoPolicies
== How To Test ==
Regular application tests should catch the regressions caught by these changes.
== Dependencies ==
No packages should depend on openssl1.1-devel packages that is eliminated.
== Contingency Plan ==
Revert the shipped configuration
Contingency deadline: TBD
== Documentation ==
TBW
== Release Notes ==
TBW
--
Vipul Siddharth
He/His/Him
FPgM team member
1 year, 9 months
F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
by Vipul Siddharth
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The flatpak remote for Flathub will have no filtering, making all the
Flathub content available in GNOME Software and via the flatpak
commandline.
== Owner ==
* Name: Workstation WG
* Email: mclasen(a)redhat.com
== Detailed Description ==
Fedora includes a flatpak repo definition for Flathub in the
fedora-flathub-remote package. So far, this remote
was filtered by an allowlist that only made a limited subset of
software from Flathub available. We've been told
that it is ok for us to remove the filtering and make all of Flathub available.
The filtering mechanism itself will still be there, and it will be
possible for us to reinstate a filter via a package
update, should the need arise in the future.
The Flathub remote is available to users who opt-in to enabling
third-party software repositories in either GNOME Initial Setup or
GNOME Software. Users who do not opt in will not see anything from
Flathub.
In case of overlaps, GNOME Software will prefer Fedora flatpaks over
Flathub flatpaks. It is always possible for the user to manually
select a different source for individual applications.
== Feedback ==
This change proposal has previously been discussed here:
https://pagure.io/fedora-workstation/issue/300
== Benefit to Fedora ==
More software will be easily available to Fedora users.
Additionally, the filtered Flathub has not been popular with users.
Users have been confused and displeased that our Flathub remote
contains only a small subset of Flathub, rather than the full Flathub.
Dropping the filter will resolve this criticism.
== Scope ==
* Proposal owners: Remove the allowlist in
/usr/share/flatpak/fedora-flathub.filter, or replace it with one that
allows everything
* Other developers: GNOME Software developers: Verify that the
priorities between repos and packaging formats work out as desired
* Release engineering: No work needed
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Existing Fedora installations with a configured Fedora Flathub remote
will pick up the new, permissive filter.
== How To Test ==
When third-party software is not enabled in GNOME Initial Setup or
GNOME Software, search results from Flathub should not appear in GNOME
Software.
When third-party software is enabled in GNOME Initial Setup or GNOME
Software, search results from Flathub should appear.
== User Experience ==
When opening GNOME Software, all the applications that are available
on Flathub will show up in search results.
== Dependencies ==
No dependencies.
== Contingency Plan ==
* Contingency mechanism: Reinstate the filtering we had in Fedora 36
* Contingency deadline: Beta
* Blocks release? No
== Documentation ==
* [https://pagure.io/fedora-third-party/blob/main/f/doc/fedora-third-party.1.md
fedora-third-party]
* [https://github.com/flathub/flathub/wiki Flathub wiki]
* [https://fedoramagazine.org/comparison-of-fedora-flatpaks-and-flathub-remo...
Comparison of Fedora Flatpaks and Flathub remotes]
== Release Notes ==
The Fedora Flathub remote now exposes all content from Flathub,
instead of only a small subset. Flathub is not enabled by default. To
enable software from Flathub, turn on third-party software in GNOME
Initial Setup or GNOME Software.
--
Vipul Siddharth
He/His/Him
FPgM team member
1 year, 9 months
F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from
f37 onwards (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
== Summary ==
java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and
java-latest-openjdk packages will no longer build i686 subpackages
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: <jvanek(a)redhat.com>
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)(which no longer exists)
=== Expected schedule ===
* during march, drop i686 builds from all jdks in fedora rawhide
== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* java-17-openjdk (LTS)
* java-latest-openjdk (STS, jdk18).
All those builds on all architectures except jdk8, where arm32 with
jit is built by different package.
Unluckily, the i686 bit builds of jdk are rotten in upstream. The
recent breakage of i686 JIT just before branching nearly killed jdk17
as system jdk feature.
The rotting have main visibility with newer GCCs. If GCC bump, and it
does, it always triggers new issues in i686 JIT, and there is less and
less people to somehow workaround them. Unluckily, there is probably
no longer anyone willing to really fix them
== Benefit to Fedora ==
The i686 builds are rotten in usptream, and to patch them localy had
become pain. We may be introducing very bugy i686 jdk. Better then to
do so, we would rather not ship that at all.
This will untie hands of both JDK and GCC developers, who will no
longer need to dive into nasty legacy code.
== Scope ==
==== Change owners ====
* we will simiply stop building i686 pkg in rawhide
==== Other developers ====
* may notice the multilib i686 java missing.
* it is up to them to drop i686 builds or to povide workaround (if possible)
==== Other ====
* Release engineering: https://pagure.io/releng/issue/10686
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* The upgrade on multilib systems will lead to autoremoval of i686 javastack
* which should be minimum - 99% of javastack is noarch
== How To Test ==
install i686 java will result to not packages found
== User Experience ==
User experience on multilib systems will be bad. Bad reasonable.
== Dependencies ==
There are is unknown number of multilib java consumers. I expect some
of them may rise voice, but that will have to handled one by one.
== Contingency Plan ==
* Contingency mechanism: return i686 packages
* Contingency date: (not provided)
== Documentation ==
Will be neded...
== Release Notes ==
None yet...
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 9 months
F37 proposal: Stratis 3.1.0 (Self-Contained change)
by Vipul Siddharth
https://fedoraproject.org/wiki/Changes/Stratis_3.1.0
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Stratis 3.1.0 includes significant improvements to the management of
the thin-provisioning layers, as well as a number of other
user-visible enhancements and bug fixes.
== Owner ==
* Name:
** [[User:dkeefe|Dennis Keefe]]
** [[User:mulhern|Anne Mulhern]]
** [[User:jbaublitz|John Baublitz]]
* Email:
** dkeefe(a)redhat.com
** amulhern(a)redhat.com
** jbaublitz(a)redhat.com
== Detailed Description ==
Stratis 3.1.0 includes significant improvements to the management of
the thin-provisioning layers, as well as a number of other
user-visible enhancements and bug fixes.
Please see this
[https://stratis-storage.github.io/thin-provisioning-redesign/ post]
for a detailed discussion of the thin-provisioning changes. To support
these changes the Stratis CLI has been enhanced to:
* allow specifying whether or not a pool may be overprovisioned on creation
* allow changing whether or not a pool may be overprovisioned while it
is running
* allow increasing the filesystem limit for a given pool
* display whether or not a pool is overprovisioned in the pool list view
Users of the Stratis CLI may also observe the following changes:
* A `debug` subcommand has been added to the `pool`, `filesystem`, and
`blockdev` subcommands. Debug commands are not fully supported and may
change or be removed at any time.
* The `--redundancy` option is no longer available when creating a
pool. This option had only one permitted value so specifying it never
had any effect.
stratisd 3.1.0 includes one additional user-visible change:
* The minimum size of a Stratis filesystem is increased to 512 MiB.
stratisd 3.1.0 also includes a number of internal improvements:
* The size of any newly created MDV is increased to 512 MiB.
* A pool's MDV is mounted in a private mount namespace and remains
mounted while the pool is in operation.
* Improved handling of udev events on device removal.
* The usual and customary improvements to log messages.
Please consult the
[https://github.com/stratis-storage/stratisd/blob/master/CHANGES.txt/
stratisd] and [https://github.com/stratis-storage/stratis-cli/blob/master/CHANGES.txt/
stratis-cli] changelogs for additional information about the 3.1.0
release.
== Benefit to Fedora ==
Users of Fedora will now benefit from Stratis 3.1.0 by:
* Change the overprovisioning mode at create time or while running
* User can increase the limit of filesystems per pool. The default is 100.
* Stratis pool list will display whether or not a pool is overprovisioned
* The MDV size is now 512MB, which allows for more filesystems to be
created per pool
* MDV is now in a private mount namespace, which decreases logging
events and user may see faster completion times for commands that
required the MDV to be mounted.
== Scope ==
* Proposal owners:
** Update existing stratis-cli package to specify new release
** Update existing stratisd package to specify new release
* Other developers: N/A
* Release engineering: Self Contained
* Policies guidelines: N/A
* Trademark approval: N/A
== How To Test ==
* To see the `overprovisioning` field, list the pools
`stratis pool list`
overprovisioned will equal `OP`, no overprovisioning will equal `~OP`
* To set the filesystem limit of a pool:
`stratis pool set-fs-limit p1 200`
* To see what the filesystem limit is
`stratis report engine_state_report`
Look for field `fs_limit` in output
== User Experience ==
Other than the changes mentioned above the user experience will be the same.
== Dependencies ==
No new dependencies
== Contingency Plan ==
* Contingency mechanism:
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
* This content can be viewed on Developer’s
[https://stratis-storage.github.io/thin-provisioning-redesign/ blog]
for Stratis 3.1
* Thin-provisioning
[https://stratis-storage.github.io/thin-provisioning-redesign/ blog]
* [https://github.com/stratis-storage/stratisd/blob/master/CHANGES.txt/
stratisd] changelog
* [https://github.com/stratis-storage/stratis-cli/blob/master/CHANGES.txt/
stratis-cli] changelog
== Release Notes ==
[https://stratis-storage.github.io/stratis-release-notes-3-1-0/
Stratis Release Notes]
--
Vipul Siddharth
He/His/Him
Fedora | CentOS CI Infrastructure Team
1 year, 9 months
About Fedora containers
by Alejandro Saez Morollon
Hi all!
TL;DR: Is there any documentation about how to properly take care of
our containers? :)
---
The Go container has been outdated for a while, and I would love to
update it[0], but I'm not familiar with the container process in
Fedora.
I checked Python3's container[1] looking for information, and I saw
that the rawhide branch is not used in the same way we use it with the
RPMs.
Also, I saw that the s2i-base image is only available until F35. No
F36 or Rawhide.
And, it looks like they are only available for x86_64 platforms.
So I guess the main big question is: is there any documentation or
proposals I should be aware of? Is the Go container relevant?
cc'ed Container SIG's mailing list; I didn't see movement in the
mailing list, just in case.
[0] https://src.fedoraproject.org/container/golang
[1] https://src.fedoraproject.org/container/python3
Thank you very much!
1 year, 9 months
Rename Airspy
by Buford T. Justice
For the regular Airspy (not HF+), why is the package called "airspyone_host"? All other distros just call it "airspy":
https://pkgs.org/search/?q=airspy
So it would be nice to simply do:
sudo dnf install airspy airspyhf
To have support in Fedora for both Airspy and Airspy HF+.
1 year, 9 months
