Donate 1 minute of your time to test upgrades from F36 to F37
by Miroslav Suchý
Do you want to make Fedora 37 better? Please spend 1 minute of your time and try to run:
# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'
dnf --releasever=37 --setopt=module_platform_id=platform:f37 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \
--assumeno distro-sync
This command does not replace `dnf system-upgrade`, but it will reveal potential problems.
You may also run `dnf upgrade` before running this command.
The `--assumeno` will just test the transaction, but does not make the actual upgrade.
In case you hit dependency issues, please report it against the appropriate package.
Or against fedora-obsolete-packages if that package should be removed in Fedora 37. Please check existing reports against
fedora-obsolete-packages first:
https://red.ht/2kuBDPu
and also there is already bunch of "Fails to install" (F37FailsToInstall) reports:
https://bugzilla.redhat.com/buglist.cgi?bug_id=2045109&bug_id_type=anddep...
Thank you
Miroslav
1 year, 2 months
F38 proposal: Ruby 3.2 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ruby_3.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 ==
Ruby 3.2 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.1 in Fedora 37 to
Ruby 3.2 in Fedora 38, 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.
=== WASI based WebAssembly support ===
This is an initial port of WASI based WebAssembly support. This
enables a CRuby binary to be available on Web browser, Serverless Edge
environment, and other WebAssembly/WASI embedders. Currently this port
passes basic and bootstrap test suites not using Thread API.
=== Regexp timeout ===
A timeout feature for Regexp matching is introduced.
It is known that Regexp matching may take unexpectedly long. If your
code attempts to match an possibly inefficient Regexp against an
untrusted input, an attacker may exploit it for efficient Denial of
Service (so-called Regular expression DoS, or ReDoS).
The risk of DoS can be prevented or significantly mitigated by
configuring `Regexp.timeout` according to the requirements of your
Ruby application. Please try it out in your application and welcome
your feedback.
=== Other Notable New Features ===
* Language
** Anonymous rest and keyword rest arguments can now be passed as
arguments, instead of just used in method parameters.
** A proc that accepts a single positional argument and keywords will
no longer autosplat.
** Constant assignment evaluation order for constants set on explicit
objects has been made consistent with single attribute assignment
evaluation order.
** Find pattern is no longer experimental.
** Methods taking a rest parameter and wishing to delegate keyword
arguments through `foo(*args)` must now be marked with
`ruby2_keywords`
* Performance improvements
** YJIT
*** Support arm64 / aarch64 on UNIX platforms.
*** Building YJIT requires Rust 1.58.1+.
=== Other notable changes since 3.1 ===
* Hash
** Hash#shift now always returns nil if the hash is empty, instead of
returning the default value or calling the default proc.
* MatchData
** MatchData#byteoffset has been added.
* Module
** Module.used_refinements has been added.
** Module#refinements has been added.
** Module#const_added has been added.
* Proc
** Proc#dup returns an instance of subclass.
** Proc#parameters now accepts lambda keyword.
* Refinement
** Refinement#refined_class has been added.
* Set
** Set is now available as a builtin class without the need for
`require "set"`. It is currently autoloaded via the `Set` constant or
a call to `Enumerable#to_set`.
* String
** String#byteindex and String#byterindex have been added.
** Update Unicode to Version 14.0.0 and Emoji Version 14.0. (also
applies to Regexp)
** String#bytesplice has been added.
* Struct
** A Struct class can also be initialized with keyword arguments
without `keyword_init: true` on `Struct.new`
=== Compatibility issues ===
* Removed constants
** `Fixnum` and `Bignum`
** `Random::DEFAULT`
** `Struct::Group`
** `Struct::Passwd`
* Removed methods
** `Dir.exists?`
** `File.exists?`
** `Kernel#=~`
** `Kernel#taint`, `Kernel#untaint`, `Kernel#tainted?`
** `Kernel#trust`, `Kernel#untrust`, `Kernel#untrusted?`
=== C API updates ===
* Removed C APIs
** `rb_cData` variable.
** "taintedness" and "trustedness" functions.
== 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.2. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/134
** 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.2 properly.
* Release engineering: [https://pagure.io/releng/issues/11115 #11115]
** 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
newly bundled gems are used.
== How To Test ==
* No special hardware is needed.
* To test, install Ruby 3.2. The test builds are published in PR or on
Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 3.2.
* 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 ==
<!-- What other packages (RPMs) depend on this package? Are there
changes outside the developers' control on which completion of this
change depends? In other words, completion of another change owned by
someone else and might cause you to not be able to finish on time or
that you would need to coordinate? Other upstream projects like the
kernel (if this is not a kernel change)? -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<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.2. If
anything goes wrong, the tag could be easily dropped and previous
version of Ruby 3.1 and its dependencies stays intact. The tag would
be merged into F38 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/master/NEWS.md Ruby 3.2.0 NEWS]
* [https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/
Ruby 3.2 Preview 2 release announcement]
== Release Notes ==
* The Ruby 3.2 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/master/NEWS.md
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 2 months
"rescue" boot entry files are not updated on OS upgrades
by Chris Murphy
Summary----------
Most all Fedora variants (except Cloud) have a GRUB menu entry
containing the word "rescue". This kernel+initramfs pair are never
updated for the life of a Fedora installation. And they quickly become
stale as a Fedora installation ages. This kernel's modules are
eventually deleted, and if selected at boot time, the typical user
experience is a dracut shell.
Basic background-------------
(skip this section if you know how it works)
During a new installation, a single kernel version is installed. e.g.
vmlinuz-5.17.0-0.rc4.96.fc36.x86_64 which is then duplicated as e.g.
vmlinuz-0-rescue-3a86878de5d649a983916543ece7bb7e.
Each of those (identical) kernels has an initramfs file:
initramfs-5.17.0-0.rc4.96.fc36.x86_64.img
initramfs-0-rescue-3a86878de5d649a983916543ece7bb7e.img
The sole difference is the first one is a smaller host-only initramfs,
the second one is a larger no host-only initramfs created with `dracut
-N`. The bigger one just contains a bunch of extra kernel modules and
dracut scripts, ostensibly to make it more likely to boot a system
with some change in hardware that the host-only initramfs doesn't
contain. The size of this rescue initramfs is around 100 MiB, with the
common day to day "host only" initramfs being around 33 MiB. [1]
As the system is updated, additional kernel versions are installed.
dnf.conf contains installonly_limit=3, which results in a maximum of
three kernel versions being installed at a time. Once a fourth kernel
is installed, the first kernel and its modules are removed from
/usr/lib/modules. The rescue kernel+initramfs pair are never updated
or upgraded, even during system upgrades.
Observations------------
This has been discussed by the Workstation working group [2] but since
this functionality is present in all of Fedora, we're moving the
discussion for greater visibility.
There's two separate complaints, if you will: (a) that the
kernel+initramfs pair are never update or upgraded for the life of the
installation; and (b) that even during one release cycle, the user
experience when booting the rescue entry, changes, i.e. when the
matching /usr/lib/modules for the rescue entry are present early on,
you do get a full runtime behavior, you will get to a graphical
environment. But then once the version matched /usr/lib/modules are
removed, you get a completely different behavior when booting the
rescue entry.
An important note from that ticket from Justin Forbes, the Fedora
kernel maintainer: " Remember, the only real purpose of the rescue
kernel is to get your system out of something completely unusable. It
isn't meant to be a full runtime."
Questions------------
* Considering the very narrow purpose of the entry, maybe the current
behavior is adequate?
* Does the rescue entry reliably get users to a dracut prompt, rather
than indefinite hang? I don't know whether it does.
* Is there any way to improve the situation without increasing the
risk that the rescue entry becomes totally non-functional?
* The chosen kernel version needs to be based on one that is known
to boot. Currently we know the kernel+initramfs pair work because it's
the same version used to boot the installation media when doing the
initial provisioning. We don't actually know an updated replacement
"no host-only" initramfs will work until it's tried. Is it possible to
automate this? And is it worth the risk, or even figuring out how to
assess the risk?
* At Flock 2021, Zbyszek proposed "Building Initrd Images from
RPMs" to reduce the complexity of building initramfs, maybe there's a
role for it here? More: https://www.youtube.com/watch?v=GATg_bqmASc
* What happens if we accept some scope creep, and go for many
improvements that make the extra work worth it?
* What about the unsigned nature of the initramfs? Should we be
creating initramfs's in Fedora infra and signing them?
* Stuff a graphical rescue environment into the initramfs? (This
might be ten leaps too far, but it's intended to encourage thinking
with a vivid imagination.)
[1] both values from a recent Fedora 36 Workstation installation
[2] https://pagure.io/fedora-workstation/issue/259
--
Chris Murphy
1 year, 2 months
wlroots 0.16 update announcement
by Aleksei Bavshin
Greetings,
Sometime within the next week, I'll be updating wlroots in rawhide to
0.16.0[1] and sway to the latest release candidate. As usual, the update
contains API/ABI breaking changes and soname will be bumped to
libwlroots.so.11. wlroots0.15 compatibility package will be introduced
in the same side-tag.
No breakages are expected and no action is required from the maintainers
of dependent packages.
I'll send another notice with a side-tag id to unblock the updates that
already require 0.16 (currently only labwc) when it's ready.
***
I'm also planning to update wlroots in f37 once 0.16.1 is available.
There are a plenty of bug fixes and some important security features
(ext-session-lock-v1) that, I believe, should not require waiting
another 6 months for f38.
Sway will likely not be included in the initial f37 update, but may
follow later when it gets sufficient testing.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0
--
Best regards,
Aleksei Bavshin
1 year, 2 months
Orphaned X11 packages
by Adam Jackson
The following packages, previously owned by xgl-maint, are now up for grabs:
xorg-x11-xfs
xorg-sgml-doctools
xorg-x11-drv-v4l
xorg-x11-xsm
xorg-x11-twm
xorg-x11-drv-sisusb
xorg-x11-xdm
xorg-x11-docs
Upstream development on all of these is pretty much nil, so if you're
serious about picking up any of these you may also wish to take on the
module upstream:
https://gitlab.freedesktop.org/xorg
- ajax
1 year, 3 months
F38 proposal: RPM Sequoia (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RpmSequoia
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 ==
Change RPM to use [https://sequoia-pgp.org/ Sequoia] based OpenPGP
parser instead of it's own, flawed and limited implementation.
== Owner ==
* Name: [[User:pmatilai| Panu Matilainen]]
* Email: pmatilai(a)redhat.com
== Detailed Description ==
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM development. In order to improve
security and free developer resources for dealing with RPM's "core
business" instead, RPM upstream is in the process of deprecating the
internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
based solution written in Rust.
At this point the change is mostly invisible in normal daily use.
== Feedback ==
== Benefit to Fedora ==
The main, direct benefit to Fedora is improved security and
standards-compliance (RFC-4880) in one of the corner-stones of the
whole distribution. Longer term, we can expect better error messages
and other functional improvements regarding key and signature
handling.
== Scope ==
* Proposal owners:
** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499
package/review rpm-sequoia]
** Build rpm with --with-crypto=sequoia
** Watch out for the unexpected
* Other developers:
** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499
package/review rpm-sequoia]
* Release engineering: [https://pagure.io/releng/issue/11077 #11077]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Within Fedora package set, this has no impact as everything is already
using sufficiently strong crypto. Third party repositories / packages
could be signed with insecure crypto, and those may require working
around with --nosignature. However this incidentally overlaps with
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2
which has effectively the same effect on rpm.
== How To Test ==
In general, normal rpm/dnf use provides sufficient test coverage. For
more advanced testers: try signing and verifying with different keys
and their subkeys, using different algorithms etc.
== User Experience ==
For normal usage, the change is quite invisible. The notable exceptions are
- Some old, insecure (MD5/SHA1 based) signatures are rejected (this is
in line with the stronger crypto settings proposed elsewhere for F38)
- Key import may accept some previously rejected keys, in part due to
limitations of old parser etc but in particular, the old
implementation verifies self-signatures at import time whereas Sequoia
verifies them at time of use.
- Key import may reject some previously accepted keys due to better validation.
== Dependencies ==
The change introduces one new direct dependency:
[https://github.com/rpm-software-management/rpm-sequoia/ rpm-sequoia].
The rpm-sequoia package also takes over other crypto besides OpenPGP,
currently Sequoia uses nettle as its low-level crypto provider, but
work is underway to
[https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361 support
openssl in Sequoia], and the plan is to have Sequoia in Fedora use
that once it becomes available. This plan
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
has support of the crypto team].
== Contingency Plan ==
* Contingency mechanism: Revert back to the internal PGP parser
* Contingency deadline: Beta release
* Blocks release? No
== Documentation ==
There's not much in the way of documentation as there's not much to
document, except for the deprecation of the internal parser:
https://github.com/rpm-software-management/rpm/issues/1935
rpm-sequoia build instructions can be found in
https://github.com/rpm-software-management/rpm-sequoia/
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 3 months
F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
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 ==
By design, ostree does not manage bootloader updates as they can not
(yet) happen in a transactional, atomic and safe fashion. Thus bootupd
(https://github.com/coreos/bootupd) was created to solve this issue
and enable admin-lead bootloader updates. This change is about
enabling bootupd integration in Fedora Silverblue and Fedora Kinoite
to make bootloader updates easier.
== Owner ==
* [[User:Siosm| Timothée Ravier]] <siosm(a)fedoraproject.org>
* [[User:Tpopela| Tomáš Popela]] <tpopela(a)fedoraproject.org>
* [[User:Walters| Colin Walters]] <walters(a)fedoraproject.org>
== Detailed Description ==
Adding bootupd full bootupd support has two immediate benefits:
* User will be able to easily update the bootloader on their system.
This will let them apply Secure Boot dbx updates that block old
bootloaders with known vulnerabilities from loading. See:
** https://github.com/fedora-silverblue/issue-tracker/issues/355
** https://bugzilla.redhat.com/show_bug.cgi?id=2127995
* We can start planning for the removal of the ostree-grub2 package
from the images to solve the "all deployments are shown twice in GRUB"
issue. This bug comes from the fact that old GRUB versions that do not
have BLS support and we thus can not only rely on BLS support in
ostree to generate boot and have to also update the grub configuration
for every updates via the scripts in the ostree-grub2 package. This
has already (indirectly) caused a major upgrade issue on
Silverblue/Kinoite requiring manual interventions from all users. See:
** https://fedoramagazine.org/manual-action-required-to-update-fedora-silver...
** https://github.com/fedora-silverblue/issue-tracker/issues/120
Note that we can not yet enable unattended bootloader updates as even
though bootupd tries hard hard to make those updates as safe as
possible, it is currently not possible that they are safe if the
system crashes (or loses power) at the wrong time. The following
change in shim (https://github.com/rhboot/shim/pull/502) should help
with that.
Thus bootloaders updates will remain a manually user triggered
operation for now.
Also note that this change currently relies on the image being
composed via rpm-ostree in unified core, which is the subject of the
following change also proposed for Fedora 38:
https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore
== Feedback ==
None so far.
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
Fedora Silverblue and Fedora Kinoite users can easily do bootloaders
updates (that includes security fixes) and we can remove support for
legacy GRUB versions thus simplify the upgrade process and making it
more reliable.
== Scope ==
* Proposal owners: Testing of the integration and new builds. The code
changes are mostly done and the integration changes are mostly already
ready as bootupd has already been integrated in a similar fashion in
Fedora CoreOS.
* Other developers: N/A
* 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 Objectives: N/A
== Upgrade/compatibility impact ==
There should be not visible change for users when upgrading. The
change only impacts the way the images are composed on the server.
== How To Test ==
We will extend the test instructions once the unified core changes
have landed. You can follow:
https://github.com/fedora-silverblue/issue-tracker/issues/120 and
https://github.com/fedora-silverblue/issue-tracker/issues/355.
== User Experience ==
For now, users will have to update their bootloader manually via the
command line. Integration to GNOME Software and Plasma Discover might
be interesting to make that easier.
Once the fallback EFI feature is available in shim (and support
implemented in bootupd), we can consider implementing automated
updates.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert the change in the rpm-ostree
manifests. Owners will do it. Nothing to do for users.
* Contingency deadline: Can happen anytime.
* Blocks release? No
== Documentation ==
We will write docs to let users update their bootloaders manually.
They will look very similar to
https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/.
== Release Notes ==
Will have to be written.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 3 months
F38 proposal: Node.js Repackaging (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NodejsRepackaging
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
We are reworking the Node.js packaging to make Node.js versions
available as parallel-installable packages.
== Owner ==
* Name: [[User:SGallagh| Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
== Detailed Description ==
We will be creating the packages nodejs-16, nodejs-18 and (in April)
nodejs-20. These packages will be parallel-installable (with the
exception of the -devel subpackages) and provide
`/usr/bin/node-$MAJOR`. We will also take advantage of the
`alternatives` subsystem to populate `/usr/bin/node` from the default
Node.js version for that release, or if the default is not installed,
the highest currently-installed version.
Notes:
* The default in Fedora 38 will be Node.js 18. If a user was to
install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20
would provide `/usr/bin/node`
* The policy going forward will be to have the most recently-released
version of Node.js at the time of Fedora's expected Beta release date
be the default for that release throughout its lifetime.
== Feedback ==
[https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject....
Mailing list thread]
Neal Gompa raised the question of using a subpackage to own
`/usr/bin/node` instead of using the `alternatives` subsystem, citing
python as an example. My response was that the problem with this is
that I want `/usr/bin/node` to always be available so long as any
`nodejs-$MAJOR` version is installed. It also ensures that the
`node(1)` manpage always matches the `/usr/bin/node` executable.
== Benefit to Fedora ==
=== User Benefits ===
* Provides a simple way to have a different (or multiple) Node.js
interpreters on their system. No dealing with Modularity.
* Enables multiple versions of Node.js on the system (can test code
against different versions without using containers)
=== Packager Benefits ===
* No more modules to maintain.
* Availability of multiple Node.js versions in the buildroot means
that other `nodejs-*` packages can test against multiple supported
options.
== Scope ==
* Proposal owners:
The packaging work is done and can be played with at
https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/
today.
* Other developers:
There should be no need to change any dependent packages, though
packagers of Node.js software may wish to take advantage of the
testing opportunities afforded.
* Release engineering:
* Policies and guidelines: We will be updating the Node.js Packaging
Guidelines with the new best practices.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Systems using the existing nodejs RPM package will be upgraded to the
matching `nodejs-$MAJOR` version. Work is pending on how to migrate
users of Modular Node.js to the new packages.
== How To Test ==
== User Experience ==
Done correctly, this should be handled entirely without the user's
need to know about it.
== 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://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject....
== Release Notes ==
Multiple releases of Node.js may now be installed in parallel from the
Fedora repositories.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 3 months
SPDX Statistics
by Miroslav Suchý
3 weeks ago it was:
> 1.
>
> As of 2022-10-27:
>
> 1.
>
> There are 23302 spec files in Fedora
>
> 2.
>
> 264 mentions "SPDX" in the spec changelog
>
> 3.
>
> out of the remaining, 173 packages mention "SPDX" in dist-git log
>
> 4.
>
> 22865 packages need to be migrated yet.
>
> 5.
>
> 11371 package has straight answer from `license-fedora2spdx` and the migration is trivial.
>
Today we have:
* 23390 spec files in Fedora
* 29290 license tags in all spec files
* 19985 tags have not been converted to SPDX yet
I count as converted even all rubygem-* packages (509 pkgs) and all rust-* packages (2007 pkgs) - ecosystem maintainers
will hand them seperately.
That means 9305 license tags has been converted so far. That is big change from 3 weeks ago where we had only 437. Part
of this big change can be the difference in script that count it. Now I try to validate the license according the old
rule and the new rule. If the old one is invalid and the new one is valid I assume that it is new package and already
has the SPDX format.
You rocks in converting the tags. You converted almost 7k tags in just 3 weeks!
Here is the artifact from my check:
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
If your package is not listed there, then I assume it is SPDX.
If your package is listed there without any comment, then you still need to convert it, but `license-fedora2spdx` does
not give straight answer.
If your package is like:
|abcMIDI - can be trivialy converted to GPL-2.0-or-later|
|then you can easily convert your license tag to this string.|
|If your package is like:|
| abattis-cantarell-fonts warning: not valid as calaway nor as SPDX, please check
|
|then your license string is not valid using both old and new rules. But there is a lot of false negative - especially
the *-fonts because they declare the license using macro, which I am unable to process (yet).|
|Fun fact: the script with the checks runs on my notebook for 32 hours.|
|I will try to re-run the check in few weeks again and will report you on how we are going.|
|Miroslav
|
|
|
1 year, 3 months