devel-announce March 2023

devel-announce@lists.fedoraproject.org

5 participants
15 discussions

F39 proposal: RPM 4.19 (System-Wide Change proposal)
by Ben Cotton 30 Mar '23

30 Mar '23

https://fedoraproject.org/wiki/Changes/RPM-4.19 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.19.0 4.19] release. == Owner == * Name: [[User:ffesti| Florian Festi]] * Email: ffesti(a)redhat.com == Detailed Description == RPM 4.19 contains various improvements over previous versions. Many of them are internal in nature such as moving from automake to cmake, improvements to the test suite, stripping copies of system functions, splitting translations into a separate project and more. There are still several user facing changes: * New rpmsort(8) utility for sorting RPM versions * x86-64 architecture levels (v2-v4) as architectures * Support for %preuntrans and %postuntrans scriptlets * Creating User and Groups from sysusers.d files including Provides and Requires or Recommends ([https://github.com/rpm-software-management/rpm/pull/2432 PR], [https://github.com/rpm-software-management/rpm/discussions/2277 Discussion]) * [https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html Dynamic Spec generation] ** find_lang now being able to generate language sub packages The 4.19 alpha release is expected in April and the final release is expected in time for the Fedora 39 release cycle as usual. == Feedback == == Benefit to Fedora == This release comes with many improvements. It opens the possibility for Fedora to adopt the new major features mentioned above. == Scope == * Proposal owners: ** Release RPM 4.19 alpha ** Rebase RPM ** Assist with dealing with incompatibilities ** Integrate new User/Group handling *** Conflicts with the current one including the Provides generation in ''systemd-rpm-macros'' * Other developers: ** Test new release, report issues and bugs * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == * %patch without arguments and options is an error * %patchN syntax is deprecated * File globbing is now more consistent == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation. == User Experience == There are no major differences in the normal user experience. == Dependencies == * Deprecated APIs are removed. This may require adjustments to software still using them. * so-name of librpm changes. Packages depending on it are expected to need a re-build * Packages running in the changes mentioned in the ''Upgrade/compatibility impact'' section might need adjusting. This should be relatively rare, though. == Contingency Plan == * Contingency mechanism: Revert back to RPM 4.18 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == Release notes at https://rpm.org/wiki/Releases/4.19.0 and reference manual at https://rpm-software-management.github.io/rpm/manual/ == Release Notes == https://rpm.org/wiki/Releases/4.19.0 (still work in progress) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Planned Outage - Server updates/reboots - 2023-03-29 21:00 UTC
by Kevin Fenzi 27 Mar '23

27 Mar '23

There will be an outage starting at 2023-03-29 21:00UTC, which will last approximately 5 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2023-03-29 21:00UTC' Reason for outage: We will be applying updates and rebooting various servers as well as re-installing some. Services may be up and down in the outage window and package maintainers are advised to avoid submitting builds. Affected Services: Most services will be affected, but only for short times in the outage window as servers are updated and rebooted. Ticket Link: https://pagure.io/fedora-infrastructure/issue/11209 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above.

1 0

F39 proposal: Register EC2 Cloud Images with uefi-preferred AMI flag (Self-Contained Change proposal)
by Ben Cotton 24 Mar '23

24 Mar '23

https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == A new feature of EC2 is to be able to register AMIs with a boot mode of `uefi-preferred` rather than picking one of `bios` or `uefi`. In EC2, aarch64 has always been UEFI, while x86-64 started out as BIOS only and some instance types have recently begun to support booting in UEFI mode. Previously, an AMI had to pick if it was UEFI or BIOS. With `uefi-preferred` it allows an AMI to launch with whatever firmware stack is available for the instance type, preferring UEFI when UEFI is an option. This proposal is to register the Fedora EC2 images with `uefi-preferred`, having the effect of switching to booting in UEFI mode on x86-64 in EC2 where available. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: trawets(a)amazon.com == Detailed Description == Some features of some EC2 instance types (such as secure boot) are only available in UEFI mode. There is also the standard set of advantages of UEFI over BIOS. All aarch64 instance types in EC2 have always been UEFI, while all x86-64 instance types were historically all BIOS. Recently, some x86-64 instance types have started to support UEFI mode. This was originally implemented as an option for instance launches and AMI registration. An AMI could state that it should be booted in UEFI mode. An AMI registered for UEFI would *not* boot on BIOS-only instance types. This meant that if you wanted to make available an OS that could boot on all instance types, you'd need a trio of AMIs: aarch64 UEFI, x86-64 BIOS, and x86-64 UEFI. With the `uefi-preferred` boot mode, one AMI registered for x86-64 will boot on UEFI where possible, but also boot BIOS if the instance type doesn't support UEFI. By registering Fedora AMIs with this boot mode, EC2 features that require UEFI (such as Secure Boot and NitroTPM) will be able to be used in Fedora, while still maintaining compatibility with BIOS only instance types. == Feedback == We have started registering Amazon Linux 2023 AMIs with this boot mode, albeit quite late in the development cycle of AL2023 due to the timing of when the `uefi-preferred` boot mode flag was added to EC2. == Benefit to Fedora == UEFI is becoming more ubiquitous amongst hardware, and operating under UEFI inside EC2 unlocks an increasing number of features such as Secure Boot and NitroTPM. The benefit for Fedora is a more uniform experience across cloud and non-cloud environments, simplifying the boot and runtime software stack. == Scope == * Proposal owners: * Modify the AMI registration call to include `uefi-preferred`, verifying that Fedora AMIs are assembled correctly for booting under UEFI. * Other developers: No changes needed by other developers * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == == How To Test == Once the AMI is registered, verify that the parameter is set, and that instances can be launched for each instance type. Normal testing should cover this. == User Experience == Users will be able to use features in EC2 that require UEFI such as Secure Boot and NitroTPM. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html * https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html == Release Notes == EC2 images are now registered with the `uefi-preferred` boot mode, thus boot in UEFI mode where possible. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F39 proposal: Changes of defaults in createrepo_c-1.0.0 (System-Wide Change proposal)
by Ben Cotton 23 Mar '23

23 Mar '23

https://fedoraproject.org/wiki/Changes/createrepo_c_1.0.0 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update createrepo_c to 1.0.0, new release will include change of default compression to zstd, no longer generating metadata in sqlite database format by default and simplified comps xml type in repodata. == Owner == * Name: [[User:Amatej | Aleš Matěj]] * Email: amatej(a)redhat.com == Detailed Description == - Switch default compression from gz to zstd. DNF is able to decompress zstd via libsolv since Fedora 30 and RHEL 8.4. It will still be possible to create gz compressed repodata by manually specifying gz compression. Further information: https://github.com/rpm-software-management/createrepo_c/issues/82, https://bugzilla.redhat.com/show_bug.cgi?id=1914876 - Stop generating metadata in sqlite database format by default. It will still be possible to create them using a --database switch or via sqliterepo_c tool. (It looks like the only user left is mdapi: https://github.com/fedora-infra/mdapi/issues/97) Further information: https://github.com/rpm-software-management/createrepo_c/issues/338 and https://pagure.io/releng/issue/10745 - When adding groups.xml to repodata createrepo_c currently adds two variants to repomd.xml. The specified file as is, uncompressed, with the type "group" and also a compressed variant with type "group_XX", where XX is compression suffix. This is atypical and unexpected. We propose to include just one variant of groups.xml using specified compression and repomd.xml type "group". This is not compatible with yum in RHEL 7. If required users will still be able to create repositories with the old layout using modifyrepo_c. Further information: https://bugzilla.redhat.com/show_bug.cgi?id=2056318 - To reflect API and overall stability increase major version above 0. == Feedback == == Benefit to Fedora == * Using zstd compression provides smaller metadata that are faster to decompress. * Generating sqlite metadata is expensive, its slowing createrepo_c runs and it takes up space on mirrors. (For F37 updates repo: primary_db: 12.8 mb, filelists_db: 22.0 mb, other_db: 4.2 mb.) * More consistent metadata, groups use the same logic as other metadata types. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1904360 == Scope == * Proposal owners: Implement specified changes, mostly changes of default. * Other developers: There are no requirements on other developers. * Release engineering: * 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 == Repodata created with createrepo_c's new defaults will not be compatible with fedora < 30 and RHEL < 8.4 (including RHEL 7, 6). This is mainly due to zstd compression but old YUM also cannot handle the changed mdtype of groups (it is compatible only with uncompressed - "group" and compressed - "group_XX" not compressed - "group"). Regarding the sqlite databases if some other users would require them they can always download the xml metadata and use sqliterepo_c to generate them locally. == How To Test == Repositories generated with updated createrepo_c have to work with dnf. Specifically we should ensure that groups are still loaded. == User Experience == The only noticeable effect should be smaller metadata thanks to zstd compression resulting in faster downloads (when zchunk is not used). The (de)compression speed up is not very noticeable. For example for F37 fedora repo: * primary.xml.gz: 18M -> primary.xml.zst: 14M * filelists.xml.gz: 52M -> filelists.xml.zst: 41M * other.xml.gz: 6.9M -> other.xml.zst: 5.4M == Dependencies == Updating createrepo_c does not require any other change requests to complete first. Metadata generated by the following tools could be affected by the described changes if they use createrepo_c's default configuration. It is hard to tell what effect will this have on the tools. If they create metadata for dnf it will work fine. In case there are any problems it is possible to manually setup the old behavior (as described above) or revert the changes. bodhi-server copr-backend libguestfs modulemd-tools prunerepo pungi retrace-server swid-tools anaconda-install-env-deps cobbler ddiskit koji-builder mock module-build perl-Fedora-Rebuild python3-dlrn python3-dnf-plugin-local python3-dnf-plugin-modulesync python3-rpmfluff retrace-server == Contingency Plan == * Contingency mechanism: If we cannot finish the changes in time there would be no action necessary. We can even ship only part of the changes as they don't depend on each other. In case there are additional unexpected issues with the changes we can revert them in createrepo_c. * Contingency deadline: 2023-08-01 * Blocks release? No == Documentation == Createrepo_c documentation will be updated accordingly. == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Orphaned packages looking for new maintainers
by Miro Hrončok 20 Mar '23

20 Mar '23

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-2023-03-20.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 ================================================================================ 7kaa orphan 1 weeks ago Pencil2D lbazan, orphan 1 weeks ago buildnumber-maven-plugin orphan 3 weeks ago coffee-script orphan, patches 4 weeks ago coolreader orphan 1 weeks ago emelfm2 orphan 4 weeks ago erlang-cache_tab bowlofeggs, erlang-maint-sig, 2 weeks ago jcline, orphan fbpanel orphan 4 weeks ago golang-github-multiformats- go-sig, orphan 1 weeks ago multihash golang-github-quay-clair-4 go-sig, orphan 3 weeks ago golang-github-quay-claircore go-sig, orphan 3 weeks ago gtrayicon orphan 4 weeks ago gxmessage orphan 4 weeks ago joni orphan 4 weeks ago libunibreak orphan 1 weeks ago lilyterm orphan 4 weeks ago megaglest orphan 1 weeks ago megaglest-data orphan 1 weeks ago nim-srpm-macros orphan 3 weeks ago nimbus orphan 4 weeks ago pluto orphan 1 weeks ago preferences-menus orphan 4 weeks ago pulseeffects atim, orphan 4 weeks ago python-freetype orphan 1 weeks ago python3-pyPEG2 orphan 4 weeks ago regexxer orphan 4 weeks ago rubygem-coffee-script jaruga, orphan, tdawson 4 weeks ago rubygem-coffee-script-source orphan, tdawson 4 weeks ago rubygem-morph-cli orphan 0 weeks ago rubygem-spring-watcher-listen orphan 4 weeks ago rubygem-uglifier orphan 5 weeks ago rust-prettytable-rs orphan, rust-sig 2 weeks ago stgit orphan 2 weeks ago taggle orphan 5 weeks ago termcolor orphan 3 weeks ago vim-nerdtree-git-plugin atim, orphan 1 weeks ago The following packages require above mentioned packages: Depending on: buildnumber-maven-plugin (1), status change: 2023-02-22 (3 weeks ago) xmpcore (maintained by: cquad, jjelen) xmpcore-5.1.2-18.fc36.src requires buildnumber-maven-plugin = 1.3-24.fc38 Depending on: coffee-script (6), status change: 2023-02-20 (4 weeks ago) nodejs-diagnostic-language-server (maintained by: asn, pfilipen) nodejs-diagnostic-language-server-1.13.0-4.fc38.src requires coffee-script = 1.10.0-20.fc38 perl-Mojolicious-Plugin-AssetPack (maintained by: eseyman) perl-Mojolicious-Plugin-AssetPack-2.14-1.fc38.src requires coffee-script = 1.10.0-20.fc38 rubygem-coffee-script-source (maintained by: orphan, tdawson) rubygem-coffee-script-source-1.10.0-15.fc38.noarch requires js-coffee-script = 1.10.0-20.fc38 rubygem-coffee-script-source-1.10.0-15.fc38.src requires js-coffee-script = 1.10.0-20.fc38 vim-syntastic (maintained by: mhjacks) vim-syntastic-coffee-3.10.0-19.fc39.noarch requires coffee-script = 1.10.0-20.fc38 openqa (maintained by: adamwill) openqa-4.6^20221123gitb93eb7f-4.fc38.noarch requires perl(Mojolicious::Plugin::AssetPack) = 2.14 openqa-4.6^20221123gitb93eb7f-4.fc38.src requires openqa-client = 4.6^20221123gitb93eb7f-4.fc38, perl(Mojolicious::Plugin::AssetPack) = 2.14 openqa-common-4.6^20221123gitb93eb7f-4.fc38.noarch requires perl(Mojolicious::Plugin::AssetPack) = 2.14 openqa-devel-4.6^20221123gitb93eb7f-4.fc38.noarch requires perl(Mojolicious::Plugin::AssetPack) = 2.14 rubygem-coffee-script (maintained by: jaruga, orphan, tdawson) rubygem-coffee-script-2.4.1-16.fc38.noarch requires rubygem(coffee-script-source) = 1.10.0 rubygem-coffee-script-2.4.1-16.fc38.src requires rubygem(coffee-script-source) = 1.10.0 Depending on: golang-github-multiformats-multihash (1), status change: 2023-03-13 (1 weeks ago) golang-github-ipfs-cid (maintained by: eclipseo, go-sig) golang-github-ipfs-cid-0.1.0-2.fc37.src requires golang(github.com/multiformats/go-multihash) = 0.1.0-4.fc37 golang-github-ipfs-cid-devel-0.1.0-2.fc37.noarch requires golang(github.com/multiformats/go-multihash) = 0.1.0-4.fc37 Depending on: golang-github-quay-claircore (1), status change: 2023-02-22 (3 weeks ago) golang-github-quay-clair-4 (maintained by: go-sig, orphan) golang-github-quay-clair-4-4.1.5-4.fc36.src requires golang(github.com/quay/claircore) = 0.5.4-3.fc36, golang(github.com/quay/claircore/libindex) = 0.5.4-3.fc36, golang(github.com/quay/claircore/libvuln) = 0.5.4-3.fc36, golang(github.com/quay/claircore/libvuln/driver) = 0.5.4-3.fc36, golang(github.com/quay/claircore/pkg/distlock) = 0.5.4-3.fc36, golang(github.com/quay/claircore/pkg/distlock/postgres) = 0.5.4-3.fc36, golang(github.com/quay/claircore/pkg/jsonerr) = 0.5.4-3.fc36, golang(github.com/quay/claircore/pkg/microbatch) = 0.5.4-3.fc36, golang(github.com/quay/claircore/test/integration) = 0.5.4-3.fc36, golang(github.com/quay/claircore/updater/defaults) = 0.5.4-3.fc36 golang-github-quay-clair-4-devel-4.1.5-4.fc36.noarch requires golang(github.com/quay/claircore) = 0.5.4-3.fc36, golang(github.com/quay/claircore/libindex) = 0.5.4-3.fc36, golang(github.com/quay/claircore/libvuln) = 0.5.4-3.fc36, golang(github.com/quay/claircore/libvuln/driver) = 0.5.4-3.fc36, golang(github.com/quay/claircore/libvuln/jsonblob) = 0.5.4-3.fc36, golang(github.com/quay/claircore/libvuln/updates) = 0.5.4-3.fc36, golang(github.com/quay/claircore/pkg/distlock) = 0.5.4-3.fc36, golang(github.com/quay/claircore/pkg/distlock/postgres) = 0.5.4-3.fc36, golang(github.com/quay/claircore/pkg/jsonerr) = 0.5.4-3.fc36, golang(github.com/quay/claircore/pkg/microbatch) = 0.5.4-3.fc36, golang(github.com/quay/claircore/test/integration) = 0.5.4-3.fc36, golang(github.com/quay/claircore/updater/defaults) = 0.5.4-3.fc36 Depending on: libunibreak (4), status change: 2023-03-07 (1 weeks ago) coolreader (maintained by: orphan) coolreader-3.2.59-4.fc38.src requires pkgconfig(libunibreak) = 4.0 coolreader-3.2.59-4.fc38.x86_64 requires libunibreak.so.3()(64bit) fbreader (maintained by: vtrefny) fbreader-0.99.4-11.fc38.src requires libunibreak-devel = 4.0-12.fc38 zlibrary-0.99.4-11.fc38.i686 requires libunibreak.so.3 zlibrary-0.99.4-11.fc38.x86_64 requires libunibreak.so.3()(64bit) naev (maintained by: jdieter) naev-0.10.2-2.fc38.src requires libunibreak-devel = 4.0-12.fc38 naev-0.10.2-2.fc38.x86_64 requires libunibreak.so.3()(64bit), naev-data = 0.10.2-2.fc38 naev-data (maintained by: jdieter) naev-data-0.10.2-2.fc38.noarch requires naev = 0.10.2-2.fc38 Depending on: megaglest-data (1), status change: 2023-03-07 (1 weeks ago) megaglest (maintained by: orphan) megaglest-3.13.0-18.fc39.x86_64 requires megaglest-data = 3.13.0-10.fc38 Depending on: python-freetype (1), status change: 2023-03-07 (1 weeks ago) python-fontname (maintained by: pnemade) python-fontname-0.2.0-28.fc38.src requires python3-freetype = 2.2.0-12.fc38 python3-fontname-0.2.0-28.fc38.noarch requires python3.11dist(freetype-py) = 2.2 Depending on: rubygem-coffee-script-source (1), status change: 2023-02-20 (4 weeks ago) rubygem-coffee-script (maintained by: jaruga, orphan, tdawson) rubygem-coffee-script-2.4.1-16.fc38.noarch requires rubygem(coffee-script-source) = 1.10.0 rubygem-coffee-script-2.4.1-16.fc38.src requires rubygem(coffee-script-source) = 1.10.0 Depending on: rust-prettytable-rs (1), status change: 2023-03-01 (2 weeks ago) rust-rpick (maintained by: bowlofeggs, rust-sig) rust-rpick-0.8.11-4.fc38.src requires crate(prettytable-rs/default) = 0.8.0 rust-rpick-devel-0.8.11-4.fc38.noarch requires crate(prettytable-rs/default) = 0.8.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): adamwill: coffee-script asn: coffee-script atim: pulseeffects, vim-nerdtree-git-plugin bowlofeggs: erlang-cache_tab, rust-prettytable-rs cquad: buildnumber-maven-plugin eclipseo: golang-github-multiformats-multihash erlang-maint-sig: erlang-cache_tab eseyman: coffee-script go-sig: golang-github-quay-claircore, golang-github-multiformats-multihash, golang-github-quay-clair-4 jaruga: rubygem-coffee-script-source, rubygem-coffee-script, coffee-script jcline: erlang-cache_tab jdieter: libunibreak jjelen: buildnumber-maven-plugin lbazan: Pencil2D mhjacks: coffee-script patches: coffee-script pfilipen: coffee-script pnemade: python-freetype rust-sig: rust-prettytable-rs tdawson: rubygem-coffee-script-source, rubygem-coffee-script, coffee-script vtrefny: libunibreak -- 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 Report finished at 2023-03-20 21:06:18 UTC

1 0

F39 proposal: Register EC2 Cloud Images with IMDSv2-only AMI flag (Self-Contained Change proposal)
by Ben Cotton 20 Mar '23

20 Mar '23

https://fedoraproject.org/wiki/Changes/CloudEC2IMDSv2Only This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == In November 2019, AWS launched IMDSv2 (Instance Meta-Data Store version 2 - see https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-rever… ) which provides "belt and suspenders" protections for four types of vulnerabilities that could be used to try to access the Instance Meta-Data Store available to EC2 instances. In that announcement, AWS recommended adopting IMDSv2 and restricting access to IMDSv2 only for added security. This can be done at instance launch time, or ([https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-su… more recently in October 2022]) by providing a flag when registering an AMI to indicate that the AMI should by default launch with IMDSv1 disabled, and thus require IMDSv2. By enabling this flag for Fedora, we provide a better security posture for Fedora users running in EC2. When an AMI is registered for IMDSv2 it is still possible to launch instances with IMDSv1 enabled by providing the right option to the RunInstances EC2 API call. The flag merely switches the default. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: trawets(a)amazon.com == Detailed Description == Attached locally to every EC2 instance, the Instance Meta-Data Service runs on a special "link local" IP address of 169.254.169.254 that means only software running on the instance can access it. For applications with access to IMDS, it makes available metadata about the instance, its network, and its storage. The IMDS also makes the AWS credentials available for any IAM role that is attached to the instance. IMDS is the primary data source for `cloud-init` on EC2, and various other utilities will also access it. The [https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-rever… IMDSv2 announcement] gives more details as to the "belt and suspenders" protections it brings for four types of vulnerabilities that could be used to try to access the IMDS. By default, registering and then launching an AMI will launch an EC2 instance where both IMDSv1 and IMDSv2 is enabled. A recent addition to the EC2 API is the ability to register an AMI with a flag that indicates that the default behavior when launching an instance should be to have IMDSv2 enabled, and disable IMDSv1. The proposal is to (starting with Fedora 39), [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-in… register EC2 AMIs with this flag set as documented in the EC2 User Guide]. == Feedback == While Amazon Linux 2023 (then called AL2022) was in Tech Preview, its AMIs have been registered with this flag the [https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-su… flag was announced in October 2022]. During this time, we have not received any negative feedback about this change. The only user of IMDSv1 calls that we have so far had to migrate to IMDSv2 calls has been some internal test cases run by a service team. == Benefit to Fedora == This change will provide Fedora users on EC2 with an enhanced security posture by default. == Scope == * Proposal owners: Modify AMI registration to include the flag. No other technical work is required. * Other developers: Any remaining code that talks to IMDS that does not use IMDSv2 will need to be adapted to continue to work by default. * Release engineering: * 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 == No impact for existing EC2 Instances. The AMI flag only affects new instance launches. == How To Test == Testing will not change from any regular Fedora EC2 AMI. The only additional check will need to be that the parameter is set correctly. == User Experience == This change should be transparent to users. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A * Contingency deadline: N/A * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F39 proposal: EC2 AMIs default to the gp3 EBS volume type (Self-Contained Change proposal)
by Ben Cotton 20 Mar '23

20 Mar '23

https://fedoraproject.org/wiki/Changes/CloudEC2gp3 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == In Amazon EC2, Elastic Block Store (EBS) volumes can be one of several types. These can be specified at volume creation time, including for the default volumes that are created on instance launch. An AMI will have default volumes and volume types configured. Fedora currently defaults to the gp2 volume type. This proposal is to switch to gp3 as the default volume type for Fedora. The gp3 volume type is both more flexible than gp2, and can be up to 20% cheaper per GB. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: trawets(a)amazon.com == Detailed Description == According to https://aws.amazon.com/ebs/general-purpose/ : : Amazon EBS gp3 volumes are the latest generation of general-purpose SSD-based EBS volumes that enable customers to provision performance independent of storage capacity, while providing up to 20% lower price per GB than existing gp2 volumes. With gp3 volumes, customers can scale IOPS (input/output operations per second) and throughput without needing to provision additional block storage capacity. This means customers only pay for the storage they need. For the default configuration of Fedora 37 AMIs, this means the price per-GB-per-month for the default root volume would be $0.08 rather than $0.10. The default number of provisioned IOPs would increase from 100 with gp2, to 3000 with gp3. For gp2 volumes less than 1TB, they can burst up to 3000 IOPs (see [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html#gp… GP2 volume performance]), while gp3 volumes provide a constant 3000 IOPs rather than only being able to burst to that number before running out of IO credits. == Feedback == Amazon Linux 2023 has switched to gp3 over the Amazon Linux 2 default of gp2, and we have not received any negative feedback on that change. == Benefit to Fedora == The benefit for Fedora users in EC2 is that of cheaper, more predictable, higher base-IOP, and more flexible IO performance by default. Fedora will also be switching to use the latest generation in general purpose EBS volume, fitting the desire of being First. == Scope == * Proposal owners: * Change gp2 to gp3 in AMI registration. * Other developers: N/A * Release engineering: * 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 == No affect on upgrades. Existing volumes remain gp2, and the volume type can be set on instance launch if gp3 is not preferred. == How To Test == No additional testing required beyond normal Fedora testing. == User Experience == This change will be largely transparent to users who take the default configuration, and do not run into IO limits on gp2 volumes today. The change for those users will be purely in reduced costs. For users who hit the burst limits of gp2, this change will improve IOP throughput to a constant 3000 IOPS. With the default volume size there is a slight throughput change when going from gp2 to gp3 (128MB/sec to 125MB/sec). == Dependencies == No dependencies == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == EC2 documentation details differences between gp2 and gp3: - https://aws.amazon.com/ebs/general-purpose/ - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F39 proposal: SPDX License Phase 2 (System-Wide Change proposal)
by Ben Cotton 16 Mar '23

16 Mar '23

https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_2 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Second phase of transition from using Fedora's short names for licenses to [https://spdx.org/licenses/ SPDX identifiers] in the License: field of Fedora package spec files. This phase addresses how to update the License: field for existing packages, including documenting more specific guidance on how to find licenses in a package. == Owner == * Name: [[User:msuchy| Miroslav Suchý]], [[User:jlovejoy| Jilayne Lovejoy]], [[User:ngompa| Neal Gompa]], [[User:dcantrell| David Cantrell]], [[User:ref| Richard Fontana]], [[User:mattdm| Matthew Miller]] * Email: msuchy(a)redhat.com, dcantrell(a)redhat.com, jlovejoy(a)redhat.com, ngompa13(a)gmail.com, rfontana(a)redhat.com == Detailed Description == This is follow-up of [[Changes/SPDX_Licenses_Phase_1|Phase 1]]. During this phase, all remaining packages should be migrated to use SPDX license identifiers in the License: field of the package spec file. So far, package maintainers have been updating their packages in accordance with the guidance provided at https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ and filing issues in the [https://gitlab.com/fedora/legal/fedora-license-data fedora-license-data repo]. Miroslav has been tracking how many packages that have been updated. Given the large number of packages in Fedora, this progress is good, but slow. We are considering options for how to more quickly migrate, in terms of how much automation can be applied as opposed to taking this as an opportunity as a more thorough license review. Automated updating of Fedora legacy abbreviations to SPDX expressions is only possible to a limited extent due to different criteria used in each system, most notably the use of [https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_updat… "category" short names in the Fedora legacy system]. Also, the [https://docs.fedoraproject.org/en-US/legal/license-field/ policy for populating the License: field] has been clarified with a view to eliminating inconsistent guidance in past documentation, which may mean that a determination made in the past would be different today. Nonetheless, automated updates for a curated set of Fedora legacy abbreviations can help speed up the migration and serve as a reminder and helping hand to package maintainers who may have not started this process. If the automatic migration is not possible (e.g., needs clarification from legal), then a Bugzilla issue has to be created. Plan: * Hold a hackfest focusing on a limited set of Fedora packages. Feedback from the hackfest can then be used to improve documentation related to updating existing packages. * Review of licenses for which there seems to be a one-to-one mapping from Fedora legacy abbreviations to SPDX identifiers to ensure reliable mapping. license-fedora2spdx will then be updated to use that curated set of mappings. * Packages using legacy license expressions will be automatically converted if the package maintainer has not already taken care of it. Packages with compound legacy license expressions will only be converted if all included identifiers can map to fedora-license-data. That is, there is no mixing of SPDX and legacy Fedora identifiers. ** The conversion will be done in waves to minimize errors in automation (e.g., 100 packages in the first week, 200 packages in another week, ...). A pull request for the package spec file will be created as part of the conversion. If the maintainer does not respond to the pull-request within 14 days, the pull request will be merged by Change owners. ** As mentioned above and at https://docs.fedoraproject.org/en-US/legal/update-existing-packages/, automatic conversion is not possible for a lot of packages and will need direct review. For example, legacy license identifiers that cannot be automatically converted: BSD, MIT, with exceptions. * Regular office hours will be held to help answer questions for package maintainers. As of 2023-03-13 the automatic conversion can be done for approximately 8096 packages. Around Fedora 39 Beta owners will file a BZ for any package that does not update the license tag. As of 2023-03-13 that would be 12206 packages. But owners expect a much lower number by that time. This Change may be followed by Phase 3 where want to provide package maintainers with a service that will notify them when it is likely that the upstream license has changed. But such service is not part of this Phase 2 Change proposal. == Feedback == See [[Changes/SPDX_Licenses_Phase_1#Feedback|feedback section of Phase 1]] Discussions on mailing list: * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… SPDX Statistics] * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… SPDX Change Update] * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… SPDX - How to handle MIT and BSD] Challenges: * license-fedora2spdx tool uses mapping of legacy Fedora short names to SPDX identifiers using the [https://gitlab.com/fedora/legal/fedora-license-data/-/tree/main|fedora-lice…] to suggest SPDX identifiers. Where there is an apparent one-to-one mapping, the package maintainer could simply update the License field: and move on. * for many packages, particularly packages that use "umbrella" legacy short names that may refer to a large set of unrelated or loosely-related licenses, further inspection will be needed. Currently, Fedora documentation provides sparse advice on how to do this inspection and thus, a range of methods are used. == Benefit to Fedora == The use of standardized identifiers for licenses will align Fedora with other distributions and facilitates efficient and reliable identification of licenses. Depending on the level of diligence done in this transition, Fedora could be positioned as a leader and contributor to better license information upstream (of Fedora). == Scope == * Prep work: ** poll package maintainers on methods and tools used for license inspection ** create additional guidance (using info from above) ** planning/brainstorming on most efficient way to update packages, especially those that do not have one-to-one identifier update and will need closer inspection * Proposal owners (things sorted by done/todo and by priorities): ** Identify all remaining packages. ** Notify owners of these packages. ** After a grace period, submit PR to a package where the transition is easy. ** Create tracking BZ for packages with unclear transition path ** Submit BZ for packages that cannot migrate in time. * Other developers: ** All packages (during the package review) should use the SPDX expression. - this is redundant as this is already approved since Phase 1, but should be reminded. ** Migrate the existing License tag from a short name to an SPDX expression. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: Licensing page will need to be altered. But almost all the work has been done in Phase 1. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == See [[Changes/SPDX_Licenses_Phase_1#How_To_Test|How to test section of Phase 1]] == User Experience == Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials. == Dependencies == No other dependencies. == Contingency Plan == * Contingency mechanism: There will be no way back. We either rollback in Phase 1. Once we will start Phase 2 we will be beyond of point with no return. * Contingency deadline: Beta freeze. But it is expected that not all packages will be converted by that time and the change will continue in the next release. * Blocks release? No. This change has no impact on runtime of any package == Documentation == [https://docs.fedoraproject.org/en-US/legal/allowed-licenses/|Allowed Licenses] [https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_proce… Update existing packages] == Release Notes == In Fedora 39, RPM packages use SPDX identifiers as a standard. Almost all packages have been migrated to SPDX identifiers. The remaining packages are tracked in this tracking Bugzilla issue. LINK TO BE ADDED -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora Linux 38 Beta Released
by Tomas Hrcka 14 Mar '23

14 Mar '23

Fedora Linux 38 Beta Released ------------------------------------------ The Fedora Project is pleased to announce the immediate availability of Fedora Linux 38 Beta, the next step towards our planned Fedora Linux 38 release at the end of April. Download the prerelease from our Get Fedora site: * Get Fedora Linux 38 Beta Workstation: https://getfedora.org/workstation/download/ * Get Fedora Linux 38 Beta Server: https://getfedora.org/server/download/ * Get Fedora Linux 38 Beta IoT: https://getfedora.org/iot/download/ * Get Fedora Linux 38 Beta CoreOS: https://getfedora.org/coreos/download/ * Get Fedora Linux 38 Beta Cloud: https://getfedora.org/cloud/download/ Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments: * Get Fedora Linux 38 Beta Spins: https://spins.fedoraproject.org/prerelease * Get Fedora Linux 38 Beta Labs: https://labs.fedoraproject.org/prerelease ## Beta Release Highlights - GNOME 44 - Enabling third-party repositories now enables an unfiltered view of applications on Flathub - Ruby 3.2, gcc 13, LLVM 16, Golang 1.20, PHP 8.2 For more details about the release, read the full announcement at * https://fedoramagazine.org/announcing-fedora-38-beta/ or look for the prerelease pages in the download sections at * https://getfedora.org/ Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the test(a)lists.fedoraproject.org mailing list or in #fedora-qa on Libera Chat or the #qa:fedoraproject.org Matrix room. Regards, Fedora Release Engineering.

1 0

Go leaves will be mass retired in one month
by Maxwell G 11 Mar '23

11 Mar '23

(Resending as it seems this didn't reach the ML the first time...) Hi Fedorians, Changes/Mass_Retire_Golang_Leaves [1] has been approved by FESCo. As part of this Change, all Go library packages that are leaves will be be mass retired and removed from the Fedora 39 repositories in approximately one month. The following maintainers/groups own co-maintain or watch at least one package that we have identified as a leaf: @deepinde-sig @go-sig @osbuild-sig agerstmayr anthr76 athoscr atim carlwgeorge dcavalca dctrud eclipseo fab fale fuller gundersanne jchaloup jdoss jjelen laiot logic mayorga mgoodwin nathans obudai pwouters qulogic rga rominf yanqiyu I will forward this message to those users separately instead of BCCing. Apparently, some people have broken filters that hide any email sent to the ML even if it's addressed to them directly. See [2] for a full list of leaves and [3] for a maintainer by maintainer breakdown. Maintainers may opt out by cloning https://pagure.io/GoSIG/go-leaves/ and pushing an `opt-out/{PKGNAME}` file with a short justification. Something like: ``` git clone ssh://git@pagure.io/GoSIG/go-leaves.git cd go-leaves echo "Dependency for foo (review bug #XXXXX)" > ./opt-out/bar git add ./opt-out/bar git commit -m "opt out bar" git push origin ``` All Go SIG members have write access to this repository. Other users can submit a pull request. You're also welcome to file an issue and I'll push the file for you. After a month has passed, we'll remove Go SIG write access from the repository and stop accepting additional opt-outs. Then, we'll preform test builds in Copr to make sure there's no false positives in the list. Finally, I'll verify the results, opt out any additional false positives, and preform the mass retirement. As usual, anybody can unretire packages without a re-review within eight weeks by filing a releng ticket. [1] https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves [2] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves [3] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves-by-maintainer Thank you for your cooperation, -- Maxwell G (@gotmax23) Pronouns: He/They

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce March 2023