F38 proposal: LXQt image for aarch64 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LXQt_image_for_aarch64
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 ==
Generate LXQt image (both iso and disk image) for aarch64 architecture.
== Owner ==
* Name: [[User:Zsun|Zamir SUN]]
* Email: zsun#AT#fedoraproject.org
== Detailed Description ==
LXQt has moved out of 0.x version and is now 1.1.0, so I consider it
to be a pretty stable desktop environment. Recently, 64bit ARM
architecture is becoming more and more popular in laptops and
workstations. By generating a LXQt image for aarch64 will offer
aarch64 another easier option to evaluate and use Fedora.
== Benefit to Fedora ==
Offers users of 64bit ARM architecture another desktop option that
works out-of-the-box.
== Scope ==
* Proposal owners: Nothing. The LXQt packages are already in the
distribution. And the kickstart for generating LXQt image on x86_64
can be directly used.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/11086 11086]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Install using the ISO or the disk image on aarch64 system. The system
should work as it should be by manually installing on top of any
existing aarch64 system.
== User Experience ==
Users of aarch64 systems should be able to directly install from LXQt
ISO or disk image if they want to use LXQt.
== Dependencies ==
We need to ask release engineering team to generate the image.
== Contingency Plan ==
* Contingency mechanism: Just do not ship the newly generated image.
* Contingency deadline: Fedora 38 Beta Freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 7 months
Fedora CoreOS Meeting Minutes 2022-10-26
by Dusty Mabe
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_core...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_core...
Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_core...
========================================
#fedora-meeting-1: fedora_coreos_meeting
========================================
Meeting started by dustymabe at 16:30:38 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_core...
.
Meeting summary
---------------
* roll call (dustymabe, 16:30:44)
* Action items from last meeting (dustymabe, 16:35:19)
* ACTION: bgilbert will follow up on
https://github.com/coreos/fedora-coreos-tracker/issues/567 re.
VMware (dustymabe, 16:36:05)
* 20221101: CRITICAL OpenSSL vulnerability (dustymabe, 16:36:27)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1329
(dustymabe, 16:36:46)
* LINK:
https://developers.redhat.com/blog/2019/06/24/go-and-fips-140-2-on-red-ha...
(travier, 16:49:25)
* LINK:
https://developers.redhat.com/articles/2022/05/31/your-go-application-fip...
(travier, 16:50:08)
* LINK:
https://developers.redhat.com/articles/2022/05/31/your-go-application-fip...
> this one seems to confirm that this is not the case on Fedora so
we should be good for ignition (travier, 16:51:54)
* we will meet again tomorrow once Fedora decides if F37 will ship
next week to discuss the scenarios here. (dustymabe, 17:17:42)
* including audit in Fedora CoreOS (dustymabe, 17:21:34)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/461
(dustymabe, 17:21:40)
* open floor (dustymabe, 17:22:27)
Meeting ended at 17:32:19 UTC.
Action Items
------------
* bgilbert will follow up on
https://github.com/coreos/fedora-coreos-tracker/issues/567 re. VMware
Action Items, by person
-----------------------
* bgilbert
* bgilbert will follow up on
https://github.com/coreos/fedora-coreos-tracker/issues/567 re.
VMware
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dustymabe (99)
* bgilbert (82)
* travier (56)
* zodbot (24)
* jlebon (11)
* lucab (7)
* adamw (5)
* fifofonix (3)
* mnguyen (1)
* gursewak (1)
* jbrooks (1)
* aaradhak (1)
* Nemric (1)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
1 year, 7 months
python-rdflib updated to 6.2.0 without advance notification
by Sandro
Dear rdflib maintainers,
A friendly reminder for the future to please notify the devel list and
maintainers of dependent packages (see below) *a week in advance* before
pushing major updates entailing ABI/API changes to rawhide [1].
The update has also made it into F37 without notification. As a result
python-odml is FTBFS [2]. This is because python-odml has not yet moved
to rdflib 6.x and still depends on 5.x. Upstream is still working on
adapting to rdfllib 6.x.
There was also some fallout along the way related to the inclusion of
jsonld in rdflib >= 6. [3]
Quick dependency check:
$ dnf -q --repo=rawhide repoquery --whatrequires python3-rdflib \
--alldeps
lv2-devel-0:1.18.8-4.fc38.i686
lv2-devel-0:1.18.8-4.fc38.x86_64
python3-biopython-0:1.79-4.fc37.x86_64
python3-odml-0:1.5.1-4.fc37.noarch
python3-owl_rl-0:6.0.2-3.fc38.noarch
python3-prov-0:1.5.2-16.fc37.noarch
python3-pynlpl-0:1.2.7-14.fc37.noarch
python3-rdflib-jsonld-0:0.6.0-6.fc38.noarch
python3-selenium-0:3.141.0-1.fc38.noarch
[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2113639
[3]
https://lists.fedoraproject.org/archives/list/neurofedora@lists.fedorapro...
Best regards,
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
1 year, 7 months
Fedora 37 compose report: 20221027.n.0 changes
by Fedora Rawhide Report
OLD: Fedora-37-20221026.n.0
NEW: Fedora-37-20221027.n.0
===== SUMMARY =====
Added images: 0
Dropped images: 9
Added packages: 0
Dropped packages: 0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages: 0 B
Size of upgraded packages: 0 B
Size of downgraded packages: 0 B
Size change of upgraded packages: 0 B
Size change of downgraded packages: 0 B
===== ADDED IMAGES =====
===== DROPPED IMAGES =====
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-37-20221026.n.0.iso
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-37-20221026.n.0.s390x.tar.xz
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-37-20221026.n.0.s390x.qcow2
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-37-20221026.n.0.s390x.raw.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-37-20221026.n.0.s390x.qcow2
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-37-20221026.n.0.iso
Image: Container_Minimal_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Minimal-Base-37-20221026.n.0.s390x.tar.xz
Image: Container_Base docker aarch64
Path: Container/aarch64/images/Fedora-Container-Base-37-20221026.n.0.aarch64.tar.xz
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-37-20221026.n.0.iso
===== ADDED PACKAGES =====
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
===== DOWNGRADED PACKAGES =====
1 year, 7 months
Mailman3 on Fedora 36
by Sjoerd Mullender
I have created RPMs for mailman3 on Fedora 36. The current (in the
repos) version cannot be installed, but my version, based on mailman
3.3.5 can. Also, I have RPMs for postorius and hyperkitty.
These RPMs are based on the Fedora 26 source RPMs, but updated to later
versions. Also, a whole bunch of other packages had to be updated. A
full list is at the bottom.
My question is, how do I proceed? Who can take this in order to push
this (or something similar) to the repositories?
I have not (yet?) been able to do this for Fedora 37 since the mailman
suite doesn't yet play nice with Python 3.11.
Here is the list of RPMs. Source RPMs are of course available.
hyperkitty-1.3.5.9-1.fc36.noarch.rpm
hyperkitty-doc-1.3.5.9-1.fc36.noarch.rpm
mailman3-3.3.5-0.2.fc36.noarch.rpm
postorius-1.3.6.9-1.fc36.noarch.rpm
python3-django-compressor-4.1-0.fc36.noarch.rpm
python3-django-haystack-3.2.1-0.fc36.noarch.rpm
python3-django-mailman3-1.3.7.9-1.fc36.noarch.rpm
python3-flufl-bounce-4.0-0.fc36.noarch.rpm
python3-flufl-i18n-3.2-0.fc36.noarch.rpm
python3-flufl-lock-5.1-0.1.fc36.noarch.rpm
python3-mailmanclient-3.3.3-4.fc36.noarch.rpm
python3-mailman-hyperkitty-1.2.1-0.1.fc36.noarch.rpm
python3-mistune-2.0.4-0.fc36.noarch.rpm
python3-rcssmin-1.1.0-0.fc36.x86_64.rpm
python3-rjsmin-1.2.0-0.fc36.x86_64.rpm
python-django-haystack-docs-3.2.1-0.fc36.noarch.rpm
python-rjsmin-docs-1.2.0-0.fc36.x86_64.rpm
--
Sjoerd Mullender
1 year, 7 months
[side tags] Undesired automatic side-tag removal happened - how to
deal with it in the future?
by Zdenek Dohnal
Hi all,
I maintain qpdf in Fedora, which recently got a new major release
version, which breaks compatibility with other packages, so I created a
side tag for other maintainers to use for building, and then releasing
it altogether in rawhide.
However the side tag:
f38-build-side-58658
got automatically deleted, even when it had builds connected to it
already. Documentation [1] does not mention any automatic side-tags
cleanup and its deadlines.
Although packagers can create a new side tag easily, I found it
inconvenient for maintainers, because the synchronization among the
maintainers can take weeks to finish the rebuild and release the update
and automatic removal without notice (do excuse me if I missed a
notification email about this - I have many filters and it could end up
somewhere where I wasn't able to find it) prolongs this process.
What I would like to propose are the following options:
A) don't do side-tag cleanups after a specific time frame, but only when
the specific event happens - branching, GA, EOL - it can be consuming to
our resources, but maintainer are still able to remove the side tags
manually in case it contains a big set of packages and AFAIK the process
itself is not such spread in usage...
or
B) do a side-tags cleanup and mention it in the documentation together
with specification what the removal's time frame is, so maintainers can
act accordingly
or
C) (my preferred) Koji or releng (depends on whether the cleanup
happened automatically or manually) will send an email to a side tag
creator with 'Hi, your side tag is going to expire - do you need it?' Or
with automaton - 'use this command to prolong it.' And if there is no
response or if the creator approves, remove the side tag.
WDYT?
Zdenek
[1] https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/
--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
1 year, 7 months
F39 proposal: Python 3.12 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Python3.12
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 ==
Update the Python stack in Fedora from Python 3.11 to Python 3.12, the
newest major release of the Python programming language.
== Owner ==
* Name: [[User:Thrnciar|Tomáš Hrnčiar]]
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: python-maint(a)redhat.com
== Detailed Description ==
We would like to upgrade Python to 3.12 in Fedora 39 thus we are
proposing this plan early.
See the upstream notes at
[https://peps.python.org/pep-0693/#features-for-3-12 Features for
3.12] and [https://docs.python.org/3.12/whatsnew/3.12.html What's new
in 3.12].
=== Important dates and plan ===
* 2022-05-08: Python 3.12 development begins
* 2022-10-24: Python 3.12.0 alpha 1
** Package it as {{package|python3.12}} for testing purposes
** Start the bootstrap procedure in Copr
** Do a mass rebuild against every future release in Copr
* 2022-11-14: Python 3.12.0 alpha 2
* 2022-12-05: Python 3.12.0 alpha 3
* 2023-01-09: Python 3.12.0 alpha 4
* 2023-02-06: Python 3.12.0 alpha 5
* 2023-02-07: Branch Fedora 38, Rawhide becomes future Fedora 39
** The earliest point when we can start rebuilding in Koji side-tag
* 2023-03-06: Python 3.12.0 alpha 6
* 2023-04-03: Python 3.12.0 alpha 7
* 2023-05-08: Python 3.12.0 beta 1
** No new features beyond this point
* 2023-05-29: Python 3.12.0 beta 2
** The ideal point when we can start rebuilding in Koji
* 2023-06-05: Expected side tag-merge (optimistic)
* 2023-06-19: Python 3.12.0 beta 3
* 2023-06-26: Expected side tag-merge (realistic)
* 2023-07-10: Python 3.12.0 beta 4
* 2023-07-17: Expected side tag-merge (pessimistic)
* 2023-07-19: Fedora 39 Mass Rebuild
** The mass rebuild happens with the fourth beta. We might need to
rebuild Python packages later in exceptional case.
** If the Koji side-tag is not merged yet at this point, we defer the
change to Fedora 38.
* 2023-07-31: Python 3.12.0 candidate 1
** This serves as "final" for our purposes.
* 2023-08-08: Branch Fedora 39, Rawhide becomes future Fedora 40
* 2023-08-08: Fedora 39 Change Checkpoint: Completion deadline (testable)
* 2023-08-22: Fedora Beta Freeze
** If rebuild with 3.12.0rc1 is needed, we should strive to do it
before the freeze - there is a window of 3 weeks.
* 2023-09-04: Python 3.12.0 candidate 2
* 2023-09-12: Fedora 39 Beta Release (Preferred Target)
** Beta will likely be released with 3.12.0rc2.
* 2023-09-19: Fedora 39 Beta Target date #1
* 2023-10-02: Python 3.12.0 final
* 2023-10-03: Fedora 39 Final Freeze
** We'll update to 3.12.0 final using a freeze exception.
* 2023-10-17: Fedora 39 Preferred Final Target date
* 2023-10-24: Fedora 39 Final Target date #1
(From [https://peps.python.org/pep-0693/#release-schedule Python 3.12
Release Schedule] and
[https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
Fedora 39 Release Schedule].)
The schedule might appear somewhat tight for Fedora 39, but Python's
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
annual release cycle was adapted for Fedora] and this worked fine
since Python 3.9 and Fedora 33. It is now common that Python is
upgraded on a similar schedule in every odd-numbered Fedora release.
Note that upstream's "release candidates" are frozen except for
blocker bugs. Since we can and will backport blocker fixes between
Fedora and upstream, we essentially treat the Release Candidate as the
final release.
=== Notes from the previous upgrade ===
There are notes from the previous upgrade available, so this upgrade
may go smoother: [[SIGs/Python/UpgradingPython]]
== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open-source software -
we should have the most recent release of Python 3. Packages in Fedora
can use the new features from 3.12.
There's also a benefit to the larger Python ecosystem: by building
Fedora's packages against 3.12 while it's still in development, we can
catch critical bugs before the final 3.12.0 release.
== Scope ==
We will coordinate the work in a side tag and merge when ready.
* Proposal owners:
*# Introduce {{package|python3.12}} for all Fedoras
*# Prepare stuff in Copr as explained in description.
*# Update {{package|python-rpm-macros}} so {{package|python3.12}}
builds {{package|python3}}
*# Build {{package|python3.12}} as the main Python
*# Mass rebuild all the packages that runtime require `python(abi) =
3.11` and/or `libpython3.11.so.1.0` (~3900 known packages in October
2022)
*# Build {{package|python3.12}} as a non-main Python
* Other developers: Maintainers of packages that fail to rebuild
during the rebuilds will be asked, using e-mail and bugzilla, to fix
or remove their packages from the distribution. If any issues appear,
they should be solvable either by communicating with the respective
upstreams first and/or applying downstream patches. Also, the package
maintainers should have a look at:
[https://docs.python.org/3.12/whatsnew/3.12.html#porting-to-python-3-12
Porting to Python 3.12]. The python-maint team will be available to
help with fixing issues.
* Release engineering: [TBD]
* Policies and guidelines: nope
* Trademark approval: nope
== Upgrade/compatibility impact ==
All the packages that depend on Python 3 must be rebuilt. User written
Python 3 scripts/applications may require a small amount of porting,
but mostly Python 3.11 is forward compatible with Python 3.12.
=== The Python standard library distutils module will be removed ===
For many years distutils module was providing support for building and
installing additional modules into a Python installation.
Since Python 3.10 distutils package is deprecated, and will be removed
in Python 3.12. Its functionality for specifying package builds has
already been completely replaced by third-party packages setuptools
and packaging, and most other commonly used APIs are available
elsewhere in the standard library (such as platform, shutil,
subprocess or sysconfig).
Affected packages will be failing with `ModuleNotFoundError: No module
named 'distutils'`.
The python3-setutpools package provides a distutils module, so
sometimes "simply" adding BuildRequires: python3-setuptools might
workaround the problem. Unfortunately, it is not 100 % compatible with
the removed standard library one distutils:
https://github.com/pypa/setuptools/issues/3532
Fedora packagers can check if their packages build without distutils
by removing it form Python 3.11:
# `fedpkg clone <package name> && cd <package name>`
# `mock -r fedora-rawhide-x86_64 init`
# `mock -r fedora-rawhide-x86_64 install python3-devel`
# `sudo rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/python3.11/distutils/`
# `fedpkg mockbuild -N`
Later, when [https://copr.fedorainfracloud.org/coprs/g/python/python3.12/
Python 3.12 COPR] is available, you can use it for testing.
See https://lists.fedoraproject.org/archives/list/python-devel@lists.fedorapr...
for known Fedora packages that'll need changes.
== How To Test ==
Interested testers do not need special hardware. If you have a
favourite Python 3 script, module, or application, please test it with
Python 3.12 and verify that it still works as you would expect. If the
application you are testing does not require any other modules, you
can test it using {{package|python3.12}} even before this change is
implemented, in Fedora 36, 37 or 38.
In case your application requires other modules, or if you are testing
an rpm package, it is necessary to install the 3.12 version of the
python3 rpm. Right now that rpm is available in copr, along with all
other python packages that build successfully with python 3.12. See
https://copr.fedorainfracloud.org/coprs/g/python/python3.12/ for
detailed instructions on how to enable Python 3.12 copr for mock.
Once the change is in place, test if your favourite Python apps are
working as they were before. File bugs if they don't.
== User Experience ==
Regular distro users shouldn't notice any change in system behaviour
other than the Python 3 interpreter will be in version 3.12.
== Dependencies ==
4000+ packages depend on Python 3 and ~3900 packages need rebuilding
when Python is upgraded. See scope section.
== Contingency Plan ==
* Contingency mechanism: Do not merge the side tag with rawhide. If
the side tag has been merged and issues arise, that will justify a
downgrade, then use an epoch tag to revert to 3.11 version (never
needed before) * Contingency deadline: TBD
* Blocks release? Yes, we'd like to block Fedora 39 release on at
least 3.12.0rc1
* Blocks product? See above
== Documentation ==
[https://peps.python.org/pep-0693/ Python 3.12 Release Schedule]
[https://peps.python.org/pep-0693/#features-for-3-12 Features for 3.12]
[https://docs.python.org/3.12/whatsnew/3.12.html What's new in 3.12]
[https://docs.python.org/3.12/whatsnew/3.12.html#porting-to-python-3-12
Porting to Python 3.12]
== Release Notes ==
* Migrating user installed packages -
https://pagure.io/fedora-docs/release-notes/issue/503
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 7 months