F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
== Summary ==
Currently, the RPM databases is located in `/var`. Let's move it to
`/usr`. The move is already under way in rpm-ostree-based
installations, and in (open)SUSE.
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel
Alexandre Salim]], [[User:Ngompa|Neal Gompa]]
* Email: bugzilla(a)colorremedies.com, michel(a)michel-slm.name, ngompa13(a)gmail.com
== Detailed Description ==
=== Current location ===
<pre>/var/lib/rpm</pre>
=== New location ===
<pre>/usr/lib/sysimage/rpm</pre>
<code>/var/lib/rpm</code> will be a symlink pointing to
<code>/usr/lib/sysimage/rpm</code>
Changing the file system layout to accommodate a snapshot+rollback
regime is implied, but not required by this proposal. For example,
Fedora has long placed `/home` on a separate subvolume (or file
system) so it can be isolated from system root. Likewise, it makes
sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so
these locations continue to carry forward in time, even if the system
root does a rollback.
== Feedback ==
There will be no change to DNF as part of this change proposal. DNF's
history will remain in `/var` until DNF 5. Discussion continues about
the effect of a snapshot+rollback regime on DNF history.
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html
Relocate DNF history to /usr.]
Upstream RPM accept the change, but institutionally don't like the
loss or weakening of a
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html
very well known location] for the database, and
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html
anticipate complaints].
== Benefit to Fedora ==
* The RPM database primarily describes the state of `/usr`. Storing
the databases in `/usr` will more easily facilitate OS rollback,
without affecting `/var`.
* Helps align Fedora variants with each other
** rpm-ostree based systems (including CoreOS, IoT, Silverblue,
Kinoite) already use `/usr/lib/sysimage` for rpmdb.
* Consistency with another RPM-based distro, (open)SUSE has made this change
* Accounts for various snapshot+rollback regimes, i.e. it's a
beneficial change whether Btrfs or device-mapper based regimes.
== Scope ==
* Proposal owners:
** changes in rpm package
*** create the new path
*** create a symlink for the old path pointing to new path
* Other developers:
** changes in SElinux policy
* Release engineering: [https://pagure.io/releng/issue/10441 #Releng
issue 10441]
* 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 ==
Change will be applied to offline upgrades, similar to the RPM sqlite
database change. A systemd service will move the rpmdb from /var to
/usr, then create a symlink pointing to /usr from /var.
# Create `/usr/lib/sysimage/rpm` (rpm package will do this at preinst)
# Create symlinks in `/usr/lib/sysimage/rpm/` pointing to files in
`/var/lib/rpm/` (rpm package will do this at preinst)
# Change the dbpath in `/usr/lib/rpm/macros` to
`/usr/lib/sysimage/rpm` (rpm package will be patched to do this on
F36+)
# Request rpm rebuild the database (done via systemd service)
# Remove `/var/lib/rpm` and create a symlink `/var/lib/rpm` ->
`/usr/lib/sysimage/rpm` (done via systemd service)
== How To Test ==
# Perform a new clean install, or upgrade a system
# Check that `/var/lib/rpm` is a symlink to `/usr/lib/sysimage/rpm`
# Check that `/usr/lib/sysimage/rpm` is populated with at least
`rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and
`rpmdb.sqlite-wal`
# Confirm `rpm -q <package>` and/or `rpm -qa` still work
== User Experience ==
* symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm`
Otherwise, the change should be invisible to users.
== Dependencies ==
* `rpm-ostree` probably should make `/usr/share/rpm` a symlink to
`/usr/lib/sysimage/rpm`, rather than the reverse as it is currently.
* `PackageKit` might use inotify on `/var/lib/rpm` need to check if it
does and whether it should be changed or add the additional path
== Contingency Plan ==
* Contingency mechanism: Revert the change, try again the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? Yes
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 3 months
F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change
== Summary ==
Update Hunspell Dictionary system directory from /usr/share/myspell/
to /usr/share/hunspell/
== Owner ==
* Name: [[User:vishalvvr| Vishal Vijayraghavan]]
* Email: <vishalvvr(a)fedoraproject.org>
== Detailed Description ==
In most of Linux distributions the standard Hunspell dictionary path
is `/usr/share/hunspell/` but in Fedora still has
`/usr/share/myspell/`. This effort is to follow default standard to
install all Hunspell dictionary into `/usr/share/hunspell/` instead of
`/usr/share/myspell/`.
== Benefit to Fedora ==
This will future proof Fedora to use the correct current location for
hunspell spelling dictionaries.
== Scope ==
* Proposal owners:
In total there are `135` packages which is to be updated. libreoffice
& Firefox are the two main applications and rest are mostly language
dictionary packages.
* Other developers:
* 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 ==
== How To Test ==
1. Check if default installed dictionary path is
`/usr/share/hunspell/` instead of `/usr/share/myspell/`
`$ hunspell -D` or `$ ls /usr/share/hunspell/`
2. Install any language dictionary and check if it getting installed
into '/usr/share/hunspell/'
`$ dnf install hunspell-hi`
`$ hunspell -D`
== User Experience ==
User should not notice any difference: their applications should
continue to work as expected after this directory migration.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: revert release back to /usr/share/myspell
* Contingency deadline: Beta
* Blocks release? No
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 3 months
F36 Change: Default To Noto Fonts (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
== Summary ==
Changing the default fonts for various languages to Noto Fonts as much
as possible, to make consistency on the text rendering.
== Owner ==
* Name: [[User:Tagoh|Akira TAGOH]]
* Email: <tagoh(a)redhat.com>
== Detailed Description ==
For a long time we have used DejaVu fonts as the default font for
European and other language scripts. On the other hand some language
scripts are not covered by DejaVu and hence have other default fonts.
(A few languages like Chinese, Japanese and Korean, as well as
Gurmukhi, Sinhala, and emoji are already using Noto fonts by default
for some time.) This situation leads to inconsistencies in text
rendering on applications and desktops, particularly when mixing
different character sets. Further Noto fonts bring some further
advantages: the fonts are generally higher quality and support
variable fonts for most scripts, making them more compact.
This change aims to provide better experience and consistent text
rendering across more languages by replacing DejaVu with Noto as the
general system default set of fonts.
The following packages will be installed by default to replace
DejaVu's coverage:
* google-noto-sans-vf-fonts
* google-noto-serif-vf-fonts
* google-noto-sans-mono-vf-fonts
* google-noto-sans-arabic-vf-fonts
* google-noto-sans-cherokee-vf-fonts
* google-noto-sans-thaana-vf-fonts
* google-noto-sans-hebrew-vf-fonts
* google-noto-rashi-hebrew-vf-fonts
* google-noto-sans-math-vf-fonts
* google-noto-sans-armenian-vf-fonts
* google-noto-serif-armenian-vf-fonts
* google-noto-sans-canadian-aboriginal-vf-fonts
* google-noto-sans-georgian-vf-fonts
* google-noto-serif-georgian-vf-fonts
* google-noto-sans-lao-vf-fonts
* google-noto-serif-lao-vf-fonts
* google-noto-serif-gurmukhi-vf-fonts
* google-noto-serif-sinhala-vf-fonts
And you can check
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to
see what languages will be affected by this change.
== Benefit to Fedora ==
We would get better text rendering on applications and desktops. Also
this change should save about 6MB on the fresh install.
<pre>
$ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts
| awk 'BEGIN{a=0}{a+=$5}END{print a}'
10789272</pre>
<pre>
$ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts
google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts
google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts
google-noto
-sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts
google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f
onts google-noto-serif-armenian-vf-fonts
google-noto-sans-canadian-aboriginal-vf-fonts
google-noto-sans-georgian-vf-f
onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts
google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts
google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print
a}'
4753340
</pre>
== Scope ==
* Proposal owners:
** Update google-noto-fonts and dejavu-fonts to change the priority
for fontconfig config.
** Update langpacks to update the dependency.
** Update comps to make Noto fonts default.
** Update lorax templates related to DejaVu.
** Update fontconfig to change the order of fonts in the builtin config.
* Other developers:
** Packagers who owns packages implicitly expects DejaVu is installed
by default will needs to update the dependency for them.
* Release engineering: [https://pagure.io/releng/issue/10492 #10492]
* 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 ==
The migration will be done by updating langpacks. after upgrading and
rebooting, the default font will be Noto instead of DejaVu.
Since this change aims to switch non-variable fonts to variable fonts,
it may not works with legacy applications as expected such as missing
some variants. in that case, you can install non-variable fonts
packages. the package name will be similar and simply drop `-vf` from
the variable fonts packages.
== How To Test ==
* This change can be simply tested by `fc-match` command like
`fc-match sans:lang=<your langauge>`, `fc-match serif:lang=<your
language>` and `fc-match monospace:lang=<your language>`. You can
check the expected result from
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table].
* Test the text rendering in your favorite application, which use the
system default font.
== User Experience ==
Users will see the default font is changed to Noto by this change
except for some languages which has much better quality of fonts.
== Dependencies ==
Only dejavu-fonts, langpacks, and fontconfig are required to update.
Other packages which explicitly has a dependency to dejavu-fonts are
basicaly optional to update.
== Contingency Plan ==
* Contingency mechanism: Revert the relevant packages updated.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None.
== Release Notes ==
The default fonts for most languages will be Google Noto fonts instead
of DejaVu, to keep consistency on the text rendering and to provide
better quality among languages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 3 months
Upcoming downtime for Fedora Discussion (~ Dec 27-Jan 1)
by Matthew Miller
Almost three years ago, we moved the existing Ask Fedora site from an
engine which attempted to replicate Stack Exchange to a new system (the
current [Ask Fedora]) based on [Discourse], a modern open source web
forum platform. We had some frustrations with the software, and the
Stack-Exchange-like approach wasn't really working for us. This has
been a huge success, and the new Ask is incredibly popular.
At the same time, we also tried an experiment — we set up [Fedora
Discussion] as a parallel site for community and project conversations.
This goes hand-in-hand with the (soft-launch, but we're getting there)
[Matrix]-based [Fedora Chat] service — Discussion for longer-form,
long-lasting asynchronous communication, and Chat for synchronous
connections.
This experiment has gone well, and we have solid and increasing use,
with several different Fedora teams (including Fedora Council and
CommOps) making it their primary place for communication. We've had
some nice improvements over time as we've learned to use the system
(not to mention a nice new logo from Máirín Duffy and the Fedora Design
Team). But, the site's basic structure is still what we arbitrarily
came up with when we first launched it: kind of a mishmash of
categories and concepts. As we've had more requests to use the site,
it's become increasingly clear that these early decisions don't match
what we need.
So, I'm going to take the opportunity of the end-of-year break to do a
big reorganization. You can read the [background and details], and
[follow along with my task-list] if you like. The important details
are: I'm going to do most of the work behind the scenes on a temporary
staging site, but there's a lot of shuffling so I'm not sure how long
it will take. I plan to put the **current site into read-only mode on
the 27th or 28th of December, and have it back up and running by
January 1st**.
When that's done, we'll have a structure that will better handle
discussion in all the different areas and teams that comprise the whole
Fedora Project. I expect this to continue to grow in the years to come,
as part of our [overall effort to keep Fedora relevant and growing].
(Of course, [HyperKitty] is still there for more traditional mailing
lists — Discourse has a fairly decent email interaction model, but it's
definitely web-first in approach.) More about all of that when the new
site is in place and ready to show off!
(Oh, and one more thing — based on [discussion and broad community
consensus], we're actually planning to merge the two Discourse sites,
Ask and Discussion, so that we have both user and contributor
conversations close together. This reorganization will make that
easier, but we're not ready for that for a while yet.)
-- Matthew
[Ask Fedora]: https://ask.fedoraproject.org/
[Discourse]: https://www.discourse.org/
[Fedora Discussion]: https://discussion.fedoraproject.org/
[Matrix]: https://matrix.org/discover/
[Fedora Chat]: https://chat.fedoraproject.org/
[background and details]: https://discussion.fedoraproject.org/t/considering-a-general-reorganizati...
[follow along with my task-list]: https://ask.fedoraproject.org/t/task-list-for-fedora-discussion-reorganiz...
[overall effort to keep Fedora relevant and growing]: https://discussion.fedoraproject.org/t/fedora-in-2025-what-do-we-want-and...
[HyperKitty]: https://lists.fedoraproject.org/archives/
[discussion and broad community consensus]: https://ask.fedoraproject.org/t/considering-a-merge-into-discussion-fedor...
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2 years, 3 months
Orphaned packages looking for new maintainers
by Miro Hrončok
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-12-21.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
================================================================================
PyPAM orphan, tmraz 5 weeks ago
cptutils orphan 1 weeks ago
dans-gdal-scripts orphan 1 weeks ago
direvent orphan 3 weeks ago
e00compr orphan 1 weeks ago
esniper orphan 1 weeks ago
icedtea-web jvanek, omajid, orphan 2 weeks ago
js-termynal orphan 2 weeks ago
kexi kde-sig, orphan 4 weeks ago
libgda lkundrak, orphan 0 weeks ago
ocaml-atd orphan 1 weeks ago
plantuml gil, orphan 5 weeks ago
python-jenkins-job-builder ignatenkobrain, ktdreyer, 0 weeks ago
orphan, pabelanger
python-metaextract orphan 1 weeks ago
python-productivity orphan 3 weeks ago
ravada orphan 1 weeks ago
rust-biscuit orphan 1 weeks ago
rust-signature orphan 4 weeks ago
uddi4j galileo, orphan 2 weeks ago
umph orphan 5 weeks ago
wsdl4j akurtakov, mizdebsk, orphan 2 weeks ago
wsil4j galileo, orphan 2 weeks ago
xcf-pixbuf-loader orphan 1 weeks ago
The following packages require above mentioned packages:
Depending on: e00compr (1), status change: 2021-12-13 (1 weeks ago)
saga (maintained by: volter)
saga-7.6.1-10.fc36.src requires e00compr-devel = 1.0.1-25.fc35
Depending on: libgda (6), status change: 2021-12-14 (0 weeks ago)
anjuta (maintained by: gnome-sig, kalev, limb, moezroy, rakesh)
anjuta-1:3.34.0-11.fc36.src requires libgda-devel = 1:5.2.10-3.fc36
anjuta-1:3.34.0-11.fc36.x86_64 requires libgda-sqlite = 1:5.2.10-3.fc36
anjuta-libs-1:3.34.0-11.fc36.i686 requires libgda-5.0.so.4
anjuta-libs-1:3.34.0-11.fc36.x86_64 requires libgda-5.0.so.4()(64bit)
elementary-music (maintained by: decathorpe)
elementary-music-5.1.1-2.fc35.i686 requires libgda-5.0.so.4,
libgda-sqlite(x86-32) = 1:5.2.10-3.fc36
elementary-music-5.1.1-2.fc35.src requires pkgconfig(libgda-5.0) = 5.2.10
elementary-music-5.1.1-2.fc35.x86_64 requires libgda-5.0.so.4()(64bit),
libgda-sqlite(x86-64) = 1:5.2.10-3.fc36
gtranslator (maintained by: kaio, nacho)
gtranslator-40.0-2.fc35.src requires libgda-devel = 1:5.2.10-3.fc36
gtranslator-40.0-2.fc35.x86_64 requires libgda-5.0.so.4()(64bit),
libgda-sqlite(x86-64) = 1:5.2.10-3.fc36
libgdamm (maintained by: hguemar, spot)
libgdamm-4.99.11-12.fc35.i686 requires libgda-5.0.so.4
libgdamm-4.99.11-12.fc35.src requires libgda-bdb = 1:5.2.10-3.fc36,
libgda-devel = 1:5.2.10-3.fc36
libgdamm-4.99.11-12.fc35.x86_64 requires libgda-5.0.so.4()(64bit)
libgdamm-devel-4.99.11-12.fc35.i686 requires pkgconfig(libgda-5.0) = 5.2.10
libgdamm-devel-4.99.11-12.fc35.x86_64 requires pkgconfig(libgda-5.0) = 5.2.10
sequeler (maintained by: music)
sequeler-0.8.2-2.fc36.src requires pkgconfig(libgda-5.0) = 5.2.10
sequeler-0.8.2-2.fc36.x86_64 requires libgda-5.0.so.4()(64bit)
gtkpod (maintained by: chkr, limb)
gtkpod-2.1.5-18.fc35.i686 requires libanjuta-3.so.0
gtkpod-2.1.5-18.fc35.src requires anjuta-devel = 1:3.34.0-11.fc36
gtkpod-2.1.5-18.fc35.x86_64 requires libanjuta-3.so.0()(64bit)
gtkpod-devel-2.1.5-18.fc35.i686 requires pkgconfig(libanjuta-3.0) = 3.34.0
gtkpod-devel-2.1.5-18.fc35.x86_64 requires pkgconfig(libanjuta-3.0) = 3.34.0
Depending on: plantuml (1), status change: 2021-11-16 (5 weeks ago)
plantumlqeditor (maintained by: dwrobel)
plantumlqeditor-1.2-22.20170403git964d4ef.fc35.x86_64 requires plantuml =
1:1.2021.0-3.fc35
Depending on: uddi4j (1), status change: 2021-12-02 (2 weeks ago)
wsil4j (maintained by: galileo, orphan)
wsil4j-1.0-25.fc35.noarch requires mvn(org.uddi4j:uddi4j) = 2.0.5,
osgi(org.uddi4j) = 2.0.5
wsil4j-1.0-25.fc35.src requires uddi4j = 2.0.5-25.fc35
Depending on: wsdl4j (10), status change: 2021-12-02 (2 weeks ago)
tomcat (maintained by: coolsvap, csutherl, gzaronikas, huwang, van)
tomcat-1:9.0.56-1.fc36.src requires wsdl4j = 1.6.3-21.fc35
wsil4j (maintained by: galileo, orphan)
wsil4j-1.0-25.fc35.noarch requires mvn(wsdl4j:wsdl4j) = 1.6.3,
osgi(javax.wsdl) = 1.6.3
wsil4j-1.0-25.fc35.src requires wsdl4j = 1.6.3-21.fc35
dogtag-pki (maintained by: abbra, cdorney, cfu, cipherboy, ckelley, dmoluguw,
edewata, jmagne, kwright, mharmsen, vakwetu)
dogtag-pki-11.1.0-0.1.alpha2.fc36.src requires resteasy = 3.0.26-13.fc36,
tomcat = 1:9.0.56-1.fc36, tomcatjss = 8.0.0-1.fc36
dogtag-pki-server-11.1.0-0.1.alpha2.fc36.noarch requires tomcat =
1:9.0.56-1.fc36, tomcatjss = 8.0.0-1.fc36
dogtag-pki-java-11.1.0-0.1.alpha2.fc36.noarch requires resteasy-client =
3.0.26-13.fc36, resteasy-core = 3.0.26-13.fc36, resteasy-jackson2-provider =
3.0.26-13.fc36
javahelp2 (maintained by: omajid)
javahelp2-2.0.05-31.fc35.src requires tomcat-jsp-2.3-api = 1:9.0.56-1.fc36,
tomcat-servlet-4.0-api = 1:9.0.56-1.fc36
pki-core (maintained by: abbra, cdorney, cfu, cipherboy, ckelley, dmoluguw,
edewata, jmagne, kwright, mharmsen, vakwetu)
pki-core-11.0.0-0.2.alpha1.fc35.src requires resteasy = 3.0.26-13.fc36,
tomcat = 1:9.0.56-1.fc36, tomcatjss = 8.0.0-1.fc36
pki-server-11.0.0-0.2.alpha1.fc35.noarch requires tomcat = 1:9.0.56-1.fc36,
tomcatjss = 8.0.0-1.fc36
pki-base-java-11.0.0-0.2.alpha1.fc35.noarch requires resteasy-client =
3.0.26-13.fc36, resteasy-core = 3.0.26-13.fc36, resteasy-jackson2-provider =
3.0.26-13.fc36
resteasy (maintained by: cdorney, cfu, cipherboy, ckelley, dmoluguw, edewata,
jmagne, mharmsen, vakwetu)
pki-resteasy-core-3.0.26-13.fc36.noarch requires
mvn(org.apache.tomcat:tomcat-servlet-api) = 9.0.56
pki-resteasy-jackson2-provider-3.0.26-13.fc36.noarch requires
mvn(org.apache.tomcat:tomcat-servlet-api) = 9.0.56
resteasy-3.0.26-13.fc36.src requires
mvn(org.apache.tomcat:tomcat-servlet-api) = 9.0.56
portlet-2.0-api (maintained by: jjelen)
portlet-2.0-api-1.0-24.fc35.src requires
mvn(org.apache.tomcat:tomcat-servlet-api) = 9.0.56
tomcatjss (maintained by: cdorney, cfu, cipherboy, ckelley, dmoluguw, edewata,
jmagne, kwright, mharmsen, vakwetu)
tomcatjss-8.0.0-1.fc36.noarch requires tomcat = 1:9.0.56-1.fc36
tomcatjss-8.0.0-1.fc36.src requires tomcat = 1:9.0.56-1.fc36
openstack-java-sdk (maintained by: dominik, fsimonce)
openstack-java-resteasy-connector-3.2.9-7.fc34.noarch requires
mvn(org.jboss.resteasy:resteasy-jaxrs) = 3.0.26.Final
openstack-java-sdk-3.2.9-7.fc34.src requires
mvn(org.jboss.resteasy:resteasy-jaxrs) = 3.0.26.Final
apache-commons-fileupload (maintained by: jerboaa, jjelen, mizdebsk, spike)
apache-commons-fileupload-1.4-7.fc35.src requires
mvn(javax.portlet:portlet-api) = 1.0
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
abbra: wsdl4j
akurtakov: wsdl4j
cdorney: wsdl4j
cfu: wsdl4j
chkr: libgda
cipherboy: wsdl4j
ckelley: wsdl4j
coolsvap: wsdl4j
csutherl: wsdl4j
decathorpe: libgda
dmoluguw: wsdl4j
dominik: wsdl4j
dwrobel: plantuml
edewata: wsdl4j
fsimonce: wsdl4j
galileo: wsdl4j, wsil4j, uddi4j
gil: plantuml
gnome-sig: libgda
gzaronikas: wsdl4j
hguemar: libgda
huwang: wsdl4j
ignatenkobrain: python-jenkins-job-builder
jerboaa: wsdl4j
jjelen: wsdl4j
jmagne: wsdl4j
jvanek: icedtea-web
kaio: libgda
kalev: libgda
kde-sig: kexi
ktdreyer: python-jenkins-job-builder
kwright: wsdl4j
limb: libgda
lkundrak: libgda
mharmsen: wsdl4j
mizdebsk: wsdl4j
moezroy: libgda
music: libgda
nacho: libgda
omajid: wsdl4j, icedtea-web
pabelanger: python-jenkins-job-builder
rakesh: libgda
spike: wsdl4j
spot: libgda
tmraz: PyPAM
vakwetu: wsdl4j
van: wsdl4j
volter: e00compr
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
2 years, 3 months
F36 Change: %set_build_flags for %build and %check (System-Wide
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck
== Summary ==
Call %set_build_flags macro automatically at the beginning of the
%build and %check phases of RPM builds in Fedora Linux. This will
ensure that the compiler flag environment variables are set for every
RPM build.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
The %set_build_flags macro exports common environment variables used
for building packages:
* CFLAGS
* CXXFLAGS
* FFLAGS
* FCFLAGS
* LDFLAGS
* LT_SYS_LIBRARY_PATH
* CC
* CXX
These environment variables are set to the compiler flags defined in
the system RPM configuration. This macro is currently implicitly
called when packages use some of the build system helper macros, like
%configure, %cmake, and %meson. However, not all packages use these
macros and so some packages do not use the correct compiler flags as
required by the Fedora packaging guidelines[1].
This change will be implemented by updating the %__spec_build_pre and
%__speck_check_pre macros in redhat-rpm-config to include
%set_build_flags. This will set these environment variables
automatically before the %build and %check sections. See the proposed
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/a397...
implementation] for more details.
The purpose for making this change in both the %build and %check
sections is because sometimes test code gets built in the %check
sections for unit tests and this will ensure that the application code
and its tests are built with the same set of flags.
This change should have no impact on packages that already use
%set_build_flags either directly or indirectly through another macro.
It also won't impact any package that currently sets these environment
variables or modifies any of the %{build*_flags} macros in their
%build or %check sections.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
== Benefit to Fedora ==
This change will ensure that more packages are built using the correct
compiler flags, and bring them in compliance with the Fedora packaging
guidelines. It will also help improve the security of the
distribution as many of the compiler flags help defend against common
security attacks.
== Scope ==
* Proposal owners:
** Make the necessary changes to redhat-rpm-config.
** Help debug any issues uncovered by this change during the mass rebuild.
* Other developers:
** Report bugs to the proposal owner.
* Release engineering: [https://pagure.io/releng/issue/10482 #10482]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== How To Test ==
This change will be tested by rebuilding packages as part of the mass rebuild.
== User Experience ==
This change will make some packages less susceptible to security exploits.
== Contingency Plan ==
* Contingency mechanism: The proposal owner will revert the change in
redhat-rpm-config
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
None needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F36 Change: Ruby 3.1 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ruby_3.1
== Summary ==
Ruby 3.1 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 3.0 in Fedora 35 to
Ruby 3.1 in Fedora 36, Fedora becomes the superior Ruby development
platform.
== Owner ==
* Name: [[User:vondruch| Vít Ondruch]]
* Email: vondruch(a)redhat.com
== Detailed Description ==
Ruby 3.1 is upstream's new major release of Ruby. Many new features
and improvements are included.
=== YJIT: New experimental in-process JIT compiler ===
Ruby 3.1 merges YJIT, a new in-process JIT compiler developed by Shopify.
Since Ruby 2.6 introduced MJIT in 2018, its performance greatly
improved, and finally we achieved Ruby3x3 last year. But even though
Optcarrot has shown impressive speedups, the JIT hasn’t benefited real
world business applications.
Recently Shopify contributed many Ruby improvements to speed up their
Rails application. YJIT is an important contribution, and aims to
improve the performance of Rails applications.
Though MJIT is a method-based JIT compiler and uses an external C
compiler, YJIT uses Basic Block Versioning and includes JIT compiler
inside it. With Lazy Basic Block Versioning (LBBV) it first compiles
the beginning of a method, and incrementally compiles the rest when
the type of arguments and variables are dynamically determined. See
YJIT: a basic block versioning JIT compiler for CRuby for a detailed
introduction.
With this technology, YJIT achieves both fast warmup time and
performance improvements on most real-world software, up to 22% on
railsbench, 39% on liquid-render.
YJIT is still an experimental feature, and as such, it is disabled by
default. If you want to use this, specify the --yjit command-line
option to enable YJIT. It is also limited to macOS & Linux on x86-64
platforms for now.
https://bugs.ruby-lang.org/issues/18229
https://shopify.engineering/yjit-just-in-time-compiler-cruby
https://www.youtube.com/watch?v=PBVLf3yfMs8
=== debug gem: A new debugger ===
A new debugger debug.gem is bundled. debug.gem is fast debugger
implementation and it provides many features like remote debugging,
colorful REPL, IDE (VSCode) integration and more. It replaces
lib/debug.rb standard library.
=== error_highlight: Fine-grained error location in backtrace ===
A built-in gem, error_highlight, has been introduced. It includes
fine-grained error location in backtrace:
$ ruby test.rb
test.rb:1:in `<main>': undefined method `time' for 1:Integer (NoMethodError)
1.time {}
^^^^^
Did you mean? times
This gem is enabled by default. You can disable it by using a
command-line option --disable-error_highlight. See the repository in
detail.
=== Irb improvement ===
=== Other Notable New Features ===
* Language
** Values in Hash literals and keyword arguments can be omitted.
** Pin operator in pattern matching now takes an expression.
* RBS
** `rbs collection` has been introduced to manage gems’ RBSs.
** Many signatures for built-in and standard libraries have been added/updated.
** It includes many bug fixes and performance improvements too.
* TypeProf
** Experimental IDE support has been implemented.
** Many bug fixes and performance improvements.
=== Performance improvements ===
* MJIT
** For workloads like Rails, the default --jit-max-cache is changed
from 100 to 10000. The JIT compiler no longer skips compilation of
methods longer than 1000 instructions.
** To support Zeitwerk of Rails, JIT-ed code is no longer cancelled
when a TracePoint for class events is enabled.
=== Other notable changes since 3.0 ===
* One-line pattern matching, e.g., ary => [x, y, z], is no longer experimental.
* Multiple assignment evaluation order has been changed slightly.
** foo[0], bar[0] = baz, qux was evaluated in order baz, qux, foo, and
then bar in Ruby 3.0. In Ruby 3.1, it is evaluated in order foo, bar,
baz, and then qux.
* Variable Width Allocation: Strings (experimental)
* Standard libraries updates
== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.
== Scope ==
* Proposal owners:
** Finish packaging of Ruby 3.1. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/106
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).
* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 3.1 properly.
* Release engineering: [https://pagure.io/releng/issue/10478 #10478]
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.
* 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 ==
* User specific Ruby binary extensions need to be rebuild.
* Ruby packages/application dependencies might need to be adjusted if
net-* and other newly bundled gems are used.
== How To Test ==
* No special hardware is needed.
* To test, install Ruby 3.1. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 3.1.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.
== User Experience ==
The Ruby programs/scripts should behave as they were used to.
== Dependencies ==
<pre>
$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq | wc -l
130
</pre>
== Contingency Plan ==
* Contingency mechanism: We would like to get a special buildroot tag
to be able to rebuild necessary the packages with Ruby 3.1. If
anything goes wrong, the tag could be easily dropped and previous
version of Ruby 3.0 and its dependencies stays intact. The tag would
be merged into F36 after everything is rebuild.
* Contingency deadline: Mass Rebuild
* Blocks release? No
== Documentation ==
* [http://www.ruby-doc.org/ Help and documentation for the Ruby
programming language]
* [https://github.com/ruby/ruby/blob/v3_1_0_preview1/NEWS.md Ruby 3.1.0 NEWS]
* [https://www.ruby-lang.org/en/news/2021/11/09/ruby-3-1-0-preview1-released/
Ruby 3.1 release announcement]
== Release Notes ==
* The Ruby 3.1 bumps soname, therefore Ruby packages, which use binary
extensions, should be rebuilt. Nevertheless, since upstream paid great
attention to source compatibility, no changes to your code are needed.
https://github.com/ruby/ruby/blob/v3_1_0_preview1/NEWS.md
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F36 Change: LLVM 14 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LLVM-14
== Summary ==
Update all llvm sub-projects in Fedora Linux to version 14.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 14, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang13 and llvm13 will be added to ensure that
packages that currently depend on clang and llvm version 13 libraries
will continue to work.
Unlike previous releases, we will no longer be packaging release
candidate builds in Rawhide or F36. Release candidates are not
guaranteed to be ABI compatible with each other, so upgrading from one
release candidate to another (or to the final release) requires
rebuilding all the clang/LLVM library users. This has become very
difficult to coordinate given the increased number of packages using
the clang/LLVM libraries, so we decided to only package the final
release.
We do plan to build release candidate versions into a side-tag for
testing. We will also create an llvm-14 branch in dist-git, so that
we can build the release candidate versions while still being able to
fix bugs and make changes to LLVM 13 in the rawhide branch.
'''Note: we are still discussing with Release Engineering if a branch
+ side-tag will be possible [https://pagure.io/releng/issue/10414
#10414]. If it's not possible, we will use COPR instead.'''
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Request an llvm-14 branch in dist-git for each llvm sub-project.
** Request a side-tag.
** Build llvm13 and clang13 compat packages into the side-tag.
** When upstream LLVM project releases version 14.0.0-rc1 (Late
January 2021), package this using the llvm-14 branches and build it
into the side-tag.
*** Repeat process for each release candidate.
** When upstream LLVM project releases version 14.0.0-final (March
2021), package this using the rawhide and f36 branches.
* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang13 and llvm13
compatibility packages if they want to rebuild their package and it
does not work with LLVM 14 yet. The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
14 is added to Fedora. The compatibility packages will ensure that
already built packages continue to work.
* Release engineering: [https://pagure.io/releng/issue/10414 #10414]
* 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 ==
This change should not impact upgradeability.
== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
14.
== User Experience ==
Users will benefit from new features and bug-fixes in the latest
version of LLVM.
== Dependencies ==
This change can be made without updating any other packages. However,
as mention before, packages that need to use LLVM 13 will need to
update their spec file on their first rebuild after this change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?): If there are
major problems with LLVM 14, the compatibility package provide a way
for other packages to continue using LLVM 13.
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 14:
* llvm
* clang
* lld
* lldb
* compiler-rt
* libomp
* llvm-test-suite
* libcxx
* libcxxabi
* python-lit
* flang
* mlir
* polly
* libclc
* llvm-unwind
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F36 Change: DIGLIM (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DIGLIM
== Summary ==
Digest Lists Integrity Module (DIGLIM) provides a repository of file
digests from authenticated sources, such as RPM headers, to be used by
kernel services for remote attestation and/or secure boot at
application level.
== Owner ==
* Name: [[User:robertosassu| Roberto Sassu]]
* Email: roberto.sassu(a)huawei.com
== Detailed Description ==
Integrity Measurement Architecture (IMA), a kernel service for remote
attestation and secure boot at application level, has been integrated
in the kernel since a long time. However, two main barriers limited
its wide adoption. First, it extends a Platform Control Register (PCR)
of the Trusted Platform Module (TPM) in an unpredictable way (due to
parallel execution of software), making it impossible to use that PCR
for sealing policies of TPM keys. Second, it requires that a file
signature is added to the package header for each file to be
appraised.
Digest Lists Integrity Module (DIGLIM) takes a different approach. It
allows IMA to extend a PCR in a predictable way or to verify the
authenticity of files by querying an in-kernel repository of
authenticated reference values, built from information already
available in existing packages (FILEDIGESTS section of the RPM header,
with signature in the RSAHEADER section). Data source authentication
does not require additional key management. With support for PGP keys
in the kernel, the official Fedora PGP keys can be imported to the
builtin keyring of the kernel and used to verify the PGP signature of
the RPM headers.
DIGLIM is not specifically tied to IMA. Since it is based on the hash
table implementation of the kernel, it can store data of different
types or be used by other kernel subsystems. It might for example
store fsverity digests, to achieve the goal of another proposed
[//fedoraproject.org/wiki/Changes/FsVerityRPM change] with less
overhead (by adding to the RPM header digests instead of signatures).
It might also be used by other kernel services, such as
[//lore.kernel.org/linux-security-module/1634151995-16266-1-git-send-email-deven.desai(a)linux.microsoft.com/
Integrity Policy Enforcement (IPE)], a new LSM being proposed for
inclusion in the upstream kernel.
A preliminary performance evaluation showed that DIGLIM does not
introduce a significant overhead. A repository of executables and
shared libraries digests, of a Fedora 33 minimal installation,
occupies less than 800k of memory.
The new feature behaves as follows. A modified kernel with the DIGLIM
patches will expose to user space an interface to add/remove file
digests from the kernel hash table. A user space parser, executed by
the kernel during early boot, parses RPM headers found in /etc/diglim
in the initial ram disk (included with a custom dracut script) and
uploads them to the kernel. When a file is accessed, IMA calculates
the file digest and queries it with DIGLIM. If the digest is found,
measurement is skipped and appraisal is successful. If the digest is
not found, a measurement of the file is performed and appraisal fails.
When packages are installed or removed, the kernel hash table is kept
synchronized with a new rpm plugin.
== Feedback ==
DIGLIM has been proposed some time ago, and was previously known as
IMA Digest Lists.
The original implementation was found to be too invasive, as both the
management of the repository of reference values and the new
measurement and appraisal mechanisms based on the query of the
repository needed to coexist with the existing code. DIGLIM is now
implemented as a standalone module, which includes the repository
management part, and exposes a simple API so that IMA and other kernel
services can use it to implement the query part (much simpler).
At the time IMA Digest Lists was published, the proposal of adding
file signatures to the package header was deemed to be more mature and
suitable for adoption. From [//pagure.io/fesco/issue/2547 previous]
and [//lists.fedoraproject.org/archives/list/devel(a)lists.fedoraproject.org/thread/JE2HGLJMLEKUJW3YBP6MQJWP43CSTC57/
current] discussions, it seems that Linux distribution vendors are a
bit reluctant to make such change, especially due to the increased
size of the packages. DIGLIM just requires a modification of the
kernel, rpm and dracut, and could work on old distribution versions
once the modified packages are installed.
Another remote attestation-specific issue is that the approach of
measuring only unknown software reduces the amount of information
available to remote verifiers for the integrity evaluation of the
system being attested. In particular, a measurement list made with the
DIGLIM approach does not show which file have been actually accessed
and when. This tradeoff was chosen to make the PCR value extended with
software measurements predictable and to allow the usage of sealing
policies based on that PCR.
== Benefit to Fedora ==
The main benefits of DIGLIM have been elaborated
[//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu(a)huawei.com/
here].
Briefly summarizing: DIGLIM brings the benefits of kernel services for
integrity detection (measurement) and protection (appraisal) to Linux
distributions, and relieves the distributions from the burden of
managing the integrity functionality.
More specifically, it will make a system running Fedora attestable
without the need of using dedicated remote attestation protocols. In
fact, the assertion that a system is running a specific set of
software will be implicitly implied by the ability of that system to
correctly respond to the other peer in the TLS handshake protocol.
This could be achieved with widely available software such as the
Apache web server, the tpm2 openssl engine and a browser. Also
[//keylime.dev/ Keylime], a Red Hat-based solution for remote
attestation, could make use of the proposed scheme.
It will also make Fedora able to detect tampering of its components at
a more privileged level, the kernel, without the interference of user
space programs. Once tampering has been detected, the actions of the
altered component are prevented before that component gets the chance
to perform any action. Fedora could be configured to also allow the
usage of components provided by the user, if he wishes to do so
(DIGLIM has a tool to build custom digest lists).
== Scope ==
* Proposal owners:
** Maintain the following patch sets for the Linux kernel, and
possibly have them accepted in the upstream kernel:
*** [//lore.kernel.org/linux-integrity/20210409114313.4073-1-roberto.sassu(a)huawei.com/
IMA execution policies]
*** [//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu(a)huawei.com/
DIGLIM basic features]
*** [//lore.kernel.org/linux-integrity/20210915163145.1046505-1-roberto.sassu(a)huawei.com/
DIGLIM advanced features]
*** [//lore.kernel.org/linux-integrity/20210930115533.878169-1-roberto.sassu(a)huawei.com/
DIGLIM integration with IMA]
*** [//lore.kernel.org/linux-integrity/20181112102423.30415-1-roberto.sassu(a)huawei.com/
PGP keys and signatures]
*** Support for PGP appended signatures
** Port the [//gitee.com/src-openeuler/rpm/blob/master/Add-digest-list-plugin.patch
digest_list rpm plugin] from openEuler to Fedora:
** Create dracut configuration file/module for copying RPM headers to
the initial ram disk (optimization: copy only RPM headers related to
files in the initial ram disk)
** Introduce [//gitee.com/openeuler/digest-list-tools/blob/master/scripts/setup_grub2
script]to enable IMA measurement/appraisal execution policies in the
boot loader configuration:
* Other developers:
** Review the changes proposed above
* Release engineering: https://pagure.io/releng/issue/10473
** Discuss with Release engineering team about the possibility of
enabling IMA measurement and/or appraisal policies since first boot (a
checkbox in Anaconda would cause the boot loader configuration to be
updated to enable such policies)
** The feature might be enabled later by the user without any change
required for the image generation
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives: Yes
== Upgrade/compatibility impact ==
The user should ensure that software (not updated) from the old
distribution is packaged and the package header is signed, or he
should create and sign a custom digest list for the software he wishes
to use after the upgrade.
== How To Test ==
DIGLIM is already available for testing. A Fedora 34 kernel package
with DIGLIM is available in this
[//copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM/ copr project].
The installation instructions have been published to the
linux-integrity kernel mailing list
[//lore.kernel.org/linux-integrity/48cd737c504d45208377daa27d625531(a)huawei.com/
here].
== User Experience ==
Both integrity detection and protection will be transparent for the
user. For protection, the user will notice a change only if his
actions (or of a malicious software on his behalf) are not in
accordance with the integrity policy being enforced (e.g. the user
executes an unknown binary).
== Dependencies ==
* kernel
* rpm
* dracut
The feature owner will be responsible to submit all the changes
necessary and will not depend on other developers' work.
== Contingency Plan ==
* Contingency mechanism: remove provided patches from the packages
* Contingency deadline: rebuilding the packages without the new
patches can be done at any time
* Blocks release? No
== Documentation ==
A comprehensive documentation can be found
[//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu(a)huawei.com/
here].
== Release Notes ==
Release notes will be derived from the documentation.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F36 Change: Golang 1.18 (System-Wide Change proposal)
by Ben Cotton
Note that this replaces the approved Golang 1.17 Change
https://fedoraproject.org/wiki/Changes/golang1.18
== Summary ==
Rebase of Golang package to upcoming version 1.18 in Fedora 36,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka|
Jakub Čajka]]
* Email: asm(a)redhat.com, jcajka(a)redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.18 in Fedora 36. Golang
1.18 is scheduled to be released in February 2022.
Due to Go packages' current nature and state, the rebuild of dependent
packages will be required.
== Benefit to Fedora ==
Stay closely behind upstream by providing the latest release of Go,
which includes improved support of the risc-v processor architecture
and added support for aarch64 based darwin(macOS) machines, among
other bug fixes, enhancements and new features. For a complete list of
changes, see upstream change notes at
https://tip.golang.org/doc/go1.18 . Therefore Fedora will be providing
a reliable development platform for Go language and projects written
in it.
== Scope ==
* Proposal owners: Rebase Golang package in Fedora 36, help resolve
possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild.
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
None
== How To Test ==
;0.
:a) Install golang 1.18 from rawhide and use it to build your
application(s)/package(s).
:b) Scratch build against rawhide.
;1.
:Your application/package built using golang 1.18 should work as expected.
== User Experience ==
None
== Dependencies ==
<pre>
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed ~1600.
</pre>
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.16.X if
significant issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.18
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months