devel-announce December 2021

devel-announce@lists.fedoraproject.org

4 participants
21 discussions

F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
by Ben Cotton 29 Dec '21

29 Dec '21

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

1 0

F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
by Ben Cotton 29 Dec '21

29 Dec '21

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

1 0

F36 Change: Default To Noto Fonts (System-Wide Change proposal)
by Ben Cotton 29 Dec '21

29 Dec '21

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

1 0

Upcoming downtime for Fedora Discussion (~ Dec 27-Jan 1)
by Matthew Miller 23 Dec '21

23 Dec '21

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-reorganization… [follow along with my task-list]: https://ask.fedoraproject.org/t/task-list-for-fedora-discussion-reorganizat… [overall effort to keep Fedora relevant and growing]: https://discussion.fedoraproject.org/t/fedora-in-2025-what-do-we-want-and-h… [HyperKitty]: https://lists.fedoraproject.org/archives/ [discussion and broad community consensus]: https://ask.fedoraproject.org/t/considering-a-merge-into-discussion-fedorap… -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

1 0

Orphaned packages looking for new maintainers
by Miro Hrončok 21 Dec '21

21 Dec '21

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

1 0

F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)
by Ben Cotton 20 Dec '21

20 Dec '21

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/a39741… 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

1 0

F36 Change: Ruby 3.1 (System-Wide Change proposal)
by Ben Cotton 20 Dec '21

20 Dec '21

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

1 0

F36 Change: LLVM 14 (System-Wide Change proposal)
by Ben Cotton 20 Dec '21

20 Dec '21

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

1 0

F36 Change: DIGLIM (System-Wide Change proposal)
by Ben Cotton 16 Dec '21

16 Dec '21

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

1 0

F36 Change: Golang 1.18 (System-Wide Change proposal)
by Ben Cotton 16 Dec '21

16 Dec '21

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce December 2021