Wiki - https://fedoraproject.org/w/index.php?title=Changes/LLVM-21
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-llvm-21-system-w…
This is a proposed Change for Fedora Linux.
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 all llvm sub-projects in Fedora Linux to version 21.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: tstellar(a)redhat.com
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 21. There
will be a soname version change for the llvm libraries, and an llvm20
compat package added to ensure that packages that currently depend on
clang and llvm version 20 libraries will continue to work.
Other notable changes:
* '''Built with PGO''' The llvm package is now built with PGO
optimization, so users of its libraries and binaries should see some
performance improvements. For example, clang should be noticeably
faster compiling C and C++ files.
* '''Undoing the prefix changes from
[http://Changes/LLVM-20#Detailed_Description LLVM 20]''' This change
was made in rawhide and f42 after the f42 release, so it is already
done. See https://pagure.io/fesco/issue/3414.
=== Planned Schedule ===
Our plan is to push 21.1.0 into Fedora 43 during the Beta Freeze with
a Beta Freeze exception.
We are not planning to push earlier release candidates into rawhide
because the library ABI is not stabilized until the final 21.1.0
release.
==== Important Dates ====
* July 18: Begin building LLVM 21.1.0-rc1 in COPR.
* Jul 29: Begin building LLVM 21.1.0-rc2 in COPR.
* Aug 12: Begin building LLVM 21.1.0-rc3 in COPR.
* '''''Aug 12: Fedora f43 branches created'''''
* Aug 26: Begin building LLVM 21.1.0 in Rawhide and 43 side-tags.
* '''''Aug 26: Fedora f43 Beta Freeze'''''
* Aug 26 -> Sept 16: Request a Beta Freeze exception for LLVM.
* '''''Oct 7: Fedora f43 Final Freeze'''''
== Feedback ==
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM plus
better performance for LLVM components through PGO optimizations.
== Scope ==
* Proposal owners:
** Build and test release candidates of LLVM 21 in COPR.
** Build and test final release of LLVM 21 in koji.
* Other developers:
** Fix build issues found with LLVM-21 or switch their package to use
the llvm20 compat libs. The LLVM team will not block Bodhi updates on
dependent packages that fail to build or run with LLVM-21. There
should be around ~12 weeks between when -rc1 lands in COPR and the
Final Freeze for package maintainers to fix issues uncovered with the
LLVM-21 update.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
== Early Testing (Optional) ==
== 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
21.
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: If there are major problems with LLVM 21, the
compatibility package provide a way for other packages to continue
using LLVM 20.
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
LLVM sub-projects in Fedora have been updated to version 21:
* llvm (now includes polly, llvm-bolt, libcxx, mlir)
* flang
* libclc
* llvm-test-suite
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Wiki - https://fedoraproject.org/wiki/Changes/Free_Pascal_cross-compilers
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-free-pascal-cros…
This is a proposed Change for Fedora Linux.
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 ==
Add cross-compilation support to the Free Pascal Compiler (FPC)
offered in Fedora.
== Owner ==
* Name: [[User:suve| Artur Frenszek-Iwicki]]
* Email: <fedora(a)svgames.pl>
== Detailed Description ==
The Free Pascal Compiler supports targeting many processor
architectures and operating systems, but so far only native targets
were supported in Fedora. This Change proposes adding several new
packages to the distribution (all built from the same `fpc` source
package), which can then be used for cross-compilation.
Two groups of packages will be introduced:
* '''`fpc-cross-$CPU`''', where `$CPU` is the name of the target
processor architecture - e.g. `fpc-cross-aarch64`. These packages will
provide system-agnostic cross-compilers.
* '''`fpc-units-$CPU-$OS`''', where `$CPU` is the name of the target
processor architecture, and `$OS` is the name of the target operating
system - e.g. `fpc-units-i386-win32`. These packages will provide
system-specific pre-compiled Pascal unit files (needed to build actual
working programs).
Units for the native target were already moved to a
`fpc-units-$CPU-$OS` package as part of
[[Changes/F38-FPC-repackaging]], so this naming convention should fit
the status quo.
== Benefit to Fedora ==
Free Pascal users needing to cross-compile their programs will be able
to use distribution-provided packages, instead of having the build the
compiler on their own.
== Scope ==
* Proposal owners: Make necessary changes to `fpc.spec` and build the
package in Rawhide.
* Other developers: None. Dependent packages should not require any changes.
* Release engineering: None.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Better integration of the Free
Pascal development stack.
== Upgrade/compatibility impact ==
For regular Free Pascal users who have not dealt with
cross-compilation, nothing should change.
Users who have rolled out their own cross-compilation setup and
installed it inside `/usr/lib/fpc` or `/usr/lib64/fpc` will need to
manually solve file conflicts, should they elect to install the new
packages.
== How To Test ==
The proposed packages can be installed from a COPR repo:
`[https://copr.fedorainfracloud.org/coprs/suve/fpcross/ suve/fpcross]`
Testers can install support for a target by using `dnf install
fpc-units-$CPU-$OS`, e.g. `fpc-units-aarch64-linux` or
`fpc-units-x86_64-win64`. The units package should pull in the
appropriate `binutils-$CPU-linux-gnu` and `fpc-cross-$CPU` packages,
if necessary. Once the cross-compiler and units are installed, one can
try compiling some test programs by using `fpc -P${CPU} -T${OS}
${FILE}.pas`.
== User Experience ==
No changes should be noticeable for users consuming FPC-compiled
programs, as well as developers using FPC for building native
programs.
Developers interested in using Free Pascal cross-compilers will be
able to install those from the repository, instead of building the
compiler on their own. There may be some extra work required for
building Pascal programs using external libraries.
== Dependencies ==
Changes to `fpc` are not dependent on any other packages.
The following packages depend on a working `fpc`:
* [https://src.fedoraproject.org/rpms/ccdciel ccdciel] (CCD capture software)
* [https://src.fedoraproject.org/rpms/colorful colorful] (side-view
shooter game)
* [https://src.fedoraproject.org/rpms/cqrlog cqrlog] (amateur radio
contact logging program)
* [https://src.fedoraproject.org/rpms/diffoscope diffoscope] (in-depth
comparison of files, archives, and directories)
* [https://src.fedoraproject.org/rpms/doublecmd doublecmd] (file
manager with two panels)
* [https://src.fedoraproject.org/rpms/fpc fpc] (Free Pascal Compiler)
* [https://src.fedoraproject.org/rpms/gearhead1 gearhead1] (roguelike
mecha role-playing game)
* [https://src.fedoraproject.org/rpms/gearhead2 gearhead2] (roguelike
mecha role-playing game in space)
* [https://src.fedoraproject.org/rpms/goverlay goverlay] (graphical UI
to help manage Linux overlays)
* [https://src.fedoraproject.org/rpms/hedgewars hedgewars] (turn-based
artillery game featuring fighting Hedgehogs)
* [https://src.fedoraproject.org/rpms/indistarter indistarter] (GUI to
start, stop and control an INDI server)
* [https://src.fedoraproject.org/rpms/lazarus lazarus] (Lazarus
Component Library and IDE for Free Pascal)
* [https://src.fedoraproject.org/rpms/lazpaint lazpaint] (simple image editor)
* [https://src.fedoraproject.org/rpms/nbc nbc] (simple language and
compiler to program the LEGO NXT brick)
* [https://src.fedoraproject.org/rpms/pasdoc pasdoc] (documentation
tool for Pascal and Object Pascal source code)
* [https://src.fedoraproject.org/rpms/skychart skychart] (planetarium
software for the advanced amateur astronomer)
== Contingency Plan ==
* Contingency mechanism: Revert to last working version of `fpc.spec`
and rebuild the package.
* Contingency deadline: Before the Beta Freeze.
* Blocks release? No
== Documentation ==
Free Pascal wiki pages:
* [https://wiki.freepascal.org/Binutils Binutils]
* [https://wiki.freepascal.org/Cross_compiling Cross compiling]
* [https://wiki.freepascal.org/Free_Pascal_supported_targets Free
Pascal supported targets]
== Release Notes ==
Fedora Linux 43 ships with cross-compilation support for the Free
Pascal Compiler, through several new packages. Users interested in
cross-compiling for MS Windows should install the
`fpc-units-x86_64-win64` or `fpc-units-i386-win32` packages. For
cross-compiling for Linux to other architectures, install the
appropriate `fpc-units-$ARCH-linux`
package. Note that you may need to perform some extra steps if you
want your cross-compiled Pascal programs to link against external
libraries.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Wiki - https://fedoraproject.org/wiki/Changes/FilterFedoraFlatpaksAtomicDesktops
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-filter-fedora-fl…
This is a proposed Change for Fedora Linux.
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 ==
For the Fedora Atomic Desktops (and only those), we will keep
pre-installing a set of Fedora Flatpaks by default but filter the
Fedora Flatpak remote to a limited set of applications (the ones
pre-installed from the ISO and the runtimes).
== Owner ==
* [[User:Siosm| Timothée Ravier]], siosm(a)fedoraproject.org
== Detailed Description ==
With this change, we want to make the availability of a Fedora Flatpak
an explicit decision for the Fedora Atomic Desktops.
Fedora contributors may package any application as Fedora Flatpak, but
those Flatpaks will not be made available immediately to Atomic
Desktops users.
Users that want to have access to all Flatpaks from Fedora can remove
the filter.
=== Why not use Flathub Flatpaks instead? ===
The most popular derivatives of the Fedora Atomic Desktops (Universal
Blue, Bazzite, Bluefin, etc.) do not use Fedora Flatpaks and enable
the Flathub ones by default instead.
Moving the Fedora Atomic Desktops to using Flathub Flatpaks would
potentially require legal work and infrastructure changes.
Completely removing the Fedora Flatpak remote from the Atomic Desktops
would mean that the default installation would appear very bare bone
in terms of available applications.
This change is thus trying to reach a middle ground between those two
options, keeping Fedora Flatpaks where they are convenient and
valuable.
=== What are the problems with Fedora's Flatpaks? ===
The Fedora Flatpaks have disadvantages that are either structural, or
hard to fix:
* They see little maintenance and traction in the community, and are
generally not maintained nor desired by their upstream developers.
* There is no documentation on how to build, maintain, and update a
Fedora Flatpak.
* There are no procedure to remove or deprecate a Fedora Flatpak.
* Building a Fedora Flatpak is different from upstream Flatpak builds
and Flathub ones.
* The OCI format used to transport the Fedora Flatpak has many
downsides at the moment:
** no-deduplication during download between Fedora runtimes,
applications, across other remotes (Flathub, etc.)
** larger memory/disk/CPU overhead
** does not support extra-data (openh264 support):
https://github.com/flatpak/flatpak/issues/3790
** does not offer history / downgrade support, making it harder to
diagnose regressions (as far as the author of this change knows) (see
https://docs.flathub.org/docs/for-users/downgrading for example for
the ostree format used by Flathub)
The only advantages that the Fedora Flatpaks have are:
* Slightly stronger guarantee than Flathub that they are build
entirely from Free Software and directly from the source.
** For the details about Flathub, see
https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user
* Built using the same source as the RPMs, thus benefiting from
patches that are only available in Fedora and not yet upstream.
=== Which Flatpaks will be added to the filter? ===
The list of Fedora Flatpak enabled for the Fedora Atomic Desktops will
be maintained by the Fedora Atomic Desktop SIG, with input from the
desktops working groups (Workstation Working Group, KDE SIG, etc.) and
the Flatpak SIG. We will populate the filter with the list of
pre-installed Flatpaks (and the runtimes) as a starting point.
== Feedback ==
There has been a lot of feedback that Fedora Flatpaks are not what the
community and upstream want installed, enabled and offered by default
as this notably creates a lot of confusion for users when some
features are missing:
* https://pagure.io/fedora-workstation/issue/463
* https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/39
* and lots of threads on the discussion forum
The Workstation working group discussed the issue and landed on a
decision, which is close to what is proposed in this change:
https://pagure.io/fedora-workstation/issue/463#comment-963702
== Benefit to Fedora ==
* Less confusion for Fedora users of Atomic Desktops
* Less confusion for upstream developers when responding to bug
reports about "their" Flatpak'ed application
* Stronger focus on what makes Fedora better: upstream contribution
and collaboration with other communities
* Less work and pressure for the Flatpak maintainers in Fedora
* More focus and testing on the Flatpaks installed by default on the
Atomic Desktops
== Scope ==
* Proposal owners: Add a filter to the Fedora Flatpak remote for Atomic Desktops
* 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 the Fedora Strategy: Aligns with the goal of making
the Fedora Atomic Desktops more attractive to new users
== Upgrade/compatibility impact ==
This change is intended to apply to all Fedora Atomic Desktops users
on update. Users that are using Fedora Flatpaks may have to update the
filter to keep receiving updates or move to Flathub packages instead.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
Remove Fedora Flatpak remote, enable filtered Fedora Flatpak remote,
enable Flathub remote. Commands to be added here.
The implementation will likely look like this previous work:
* https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
* https://pagure.io/fedora-flathub-filter
Once the change is implemented, new installation ISOs for Atomic
Desktops will let users tests this more easily.
== User Experience ==
Users installing applications from the GNOME Software and Plasma
Discover store will get fully featured Flatpaks by defaults, usually
maintained directly by their own developers. We will still install a
set of core applications by default on the system as Fedora Flatpaks.
== Dependencies ==
N/A.
== Contingency Plan ==
* Contingency mechanism: Keep things as is
* Contingency deadline: Beta/Final freeze
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
We will have to document how to remove the filter for users that want
to use all Fedora Flatpaks.
== Release Notes ==
To be written.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_Drop_Support_UEFI_on_MBR
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-anaconda-drop-su…
This is a proposed Change for Fedora Linux.
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 ==
Enforce the use of GPT partition tables for all UEFI-based Fedora
installations for x86 architecture. This removes support for
installing Fedora in UEFI mode on MBR-partitioned disks on x86
systems. ARM and RISC-V remain unaffected.
== Owner ==
* Name: Anaconda team ([[User:kkoukiou|Katerina Koukiou]])
* Email: kkoukiou(a)redhat.com
== Detailed Description ==
Anaconda will no longer support installing in UEFI mode on
MBR-partitioned disks for X886. While the UEFI specification
technically permits booting from MBR (msdos) disks, in practice this
configuration is unreliable, inconsistently supported by firmware, and
not tested in Fedora.
Fedora’s GRUB2 bootloader documentation already assumes the use of a
GPT partition table for UEFI installations.
By enforcing GPT in UEFI mode, Anaconda will provide a more robust
installation experience by avoiding bootloader crashes (e.g.,
efibootmgr failures).
Support for UEFI on MBR was originally added in
[https://github.com/storaged-project/blivet/pull/764 blivet#764] to
accommodate cloud image use cases, such as AWS, which at the time did
not support UEFI booting on GPT disks. These constraints no longer
apply to modern cloud platforms, making MBR-based UEFI setups
unnecessary for current Fedora deployments.
This change only applies to x86 systems booted in UEFI mode. Other
architectures (such as ARM and RISC-V) are not affected, as their UEFI
implementations may still depend on MBR partitioning.
== Feedback ==
== Benefit to Fedora ==
* Improved reliability: Eliminating support for MBR in UEFI
installations prevents bootloader failures caused by firmware or
efibootmgr being unable to register UEFI boot entries on MBR disks.
* Reduced support burden: Dropping an untested and rarely used
configuration makes Fedora easier to test and maintain. It also avoids
misleading users into thinking MBR+UEFI is a viable long-term setup.
== Scope ==
* Proposal owners: The
[https://github.com/rhinstaller/anaconda/pull/6484 upstream PR] is
ready
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change does not affect upgrades of existing Fedora systems, as it
only impacts the Anaconda installation path in UEFI mode on
MBR-partitioned disks. Systems that were previously installed with MBR
and UEFI may continue to function and upgrade normally, but new
installations via Anaconda will require GPT.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
After [https://github.com/rhinstaller/anaconda/pull/6485 Anaconda PR
#6484] is merged, users can test this change by downloading a current
Fedora Rawhide ISO and attempting to install Fedora in UEFI mode on an
MBR-partitioned disk on a x86 system.
The installer should fail gracefully with a clear error message
indicating that GPT is required for UEFI installations.
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: 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 ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi all,
I'm excited to announce the preview availability of declarative Maven
RPM builds in Fedora 43 -- a new approach to RPM packaging for
Maven-based Java projects that focuses on simplicity, consistency, and
future automation. This functionality is already usable today, though
it is still under active development and not yet feature-complete.
The preview is intended to gather early feedback and prepare for
broader adoption.
Declarative Maven builds let you define packaging logic entirely as
structured data using BuildOption tags (available in RPM 4.20 and
later). This eliminates the need for %prep, %build, and %install
scriptlets. The build process still uses XMvn internally, but the
declarative layer eliminates the need for RPM macros or shell
scripting.
Key features:
- Declarative configuration: Build logic is expressed through
structured tags, not executable code.
- Cleaner spec files: Less boilerplate, easier to read and maintain.
- Tooling-friendly: Pure data is easier to parse, validate, and
transform, enabling better automation down the line.
- Dynamic BuildRequires: Build dependencies are inferred automatically
based on the project’s POM metadata, reducing manual maintenance and
errors.
- Interoperability: Packages built with declarative Maven builds
remain fully compatible with traditional Java packages that use
javapackages-tools. They can coexist and interoperate in the same
dependency graph.
This feature is currently in preview. So far, a single package
"plexus-cipher" has been converted to use declarative Maven builds. It
serves as a working example and proof of concept. The spec file of
plexus-cipher can be seen at
https://src.fedoraproject.org/rpms/plexus-cipher/blob/rawhide/f/plexus-ciph…
More information can be found at upstream project at
https://github.com/mizdebsk/dola
Currently supported syntax for BuildOptions (subject to change) is
documented at https://github.com/mizdebsk/dola/blob/master/SYNTAX.md
More info about declarative RPM builds in general can be found at
https://rpm-software-management.github.io/rpm/manual/buildsystem.html
--
Mikolaj Izdebski
Hi!
I'm trying to contribute to git rpms repos on src.fedoraproject.org but the
server doesn't accept the SSH key I've added to my Fedora account profile.
It's not clear if I have something misconfigured, or if contributions on
this server are limited to users that are in the "Packager" group?
Thanks for your help!
Tom
pagure.io is down because of the data center move, so it's hard to
even assemble an agenda. I don't think we have anything urgent, and
some folks are away for holidays anyway, so let's skip the meeting
today.
Zbyszek
Hot news:
- new version of SPDX license list is going to be released soon (today?)
Four weeks ago we had:
> * 24552 spec files in Fedora
>
> * 31159license tags in all spec files
>
> * 108 tags are not SPDX compliant (number from line bellow minus packages with LicenseRef-Callaway-*)
>
> * 2093tags have not been converted to SPDX yet
>
> * 8 tags can be trivially converted using `license-fedora2spdx`
>
> * Progress: 99.65% ░░░░░░░░░█100%
>
> ELN subset:
>
> 55 out of 2291 packages are not converted yet (progress 97.65%)
>
Today we have:
* 24548 spec files in Fedora
* 31159license tags in all spec files
* 104 tags are not SPDX compliant (number from line bellow minus packages with LicenseRef-Callaway-*)
* 2071tags have not been converted to SPDX yet
* 8 tags can be trivially converted using `license-fedora2spdx`
* Progress: 99.67% ░░░░░░░░░█100%
ELN subset:
54 out of 2300 packages are not converted yet (progress 97.65%)
Graph of these data with the burndown chart:
https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807r…
The list of packages needed to be converted is here:
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-f…
List by package maintainers is here
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-f…
Packages that are neither in SPDX nor in Callaway format (highest priority for now) - 27 packages:
https://pagure.io/copr/license-validate/blob/main/f/neither-nor-remaining-p…
Most of such packages has open issue in fedora-license-data. A lot of them are waiting for SPDX to approved the license
and assign ID.
I released new version of fedora-license-data with 1 new license. (I am lying, due fedora-infra outage I am unable to
build it now, so this will happen tomorrow).
9 licenses are waiting to be reviewed by SPDX.org (and then to be added to fedora-license-data)
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B…
If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license
tag matches SPDX formula, you can put your package on ignore list
https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt
Either pull-request or direct email to me is fine.
Miroslav