4:34 p.m.
Two weeks ago we had:
* 23029 spec files in Fedora
* 29405 license tags in all spec files
* 22401 tags have not been converted to SPDX yet
* 8795 tags can be trivially converted using `license-fedora2spdx`
Today we have:
* 23060 spec files in Fedora
* 29449license tags in all spec files
* 21194 tags have not been converted to SPDX yet [*]
* 8439 tags can be trivially converted using `license-fedora2spdx`
[*] I have got some reports of packages that have been converted, but does not have
spec/git changelog and I hope I will
edit my scripts to work with some filter list.
The list of packages needed to be converted is again here:
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
List by package maintainers is here
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
New version of fedora-license-data has been released.
Legal docs and especially
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/
has been updated too.
I updated the progress in this spreadsheet:
https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE80...
You converted 1207 license tags in 14 days. Amazing!
New projection when we will be finished is 2024-06-04. Pure linear approximation.
Did you know?: rpmlint checks if you have correct license. It uses
`rpmlint-fedora-license-data` which is a subpackage
of `fedora-license-data`. So anytime a new version of `fedora-license-data` is released,
rpmlint uses the new data.
Why University of Constantinople? Because on today's day in a year 425 a.d. was found
University of Constantinople. It
lacked the structure of later universities so generally, it is missing in the top of
oldest universities, but it was the
beggining.
https://en.wikipedia.org/wiki/University_of_Constantinople
Do you hesitate how to proceed with the migration? Please follow
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/
or attend SPDX office hours (see different thread in this mailing list)
Miroslav
4:41 p.m.
On Mon, Feb 27, 2023 at 3:35 PM Miroslav Suchý <msuchy(a)redhat.com> wrote:
List by package maintainers is here
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
That shows some packages under my name, such as gap-pkg-ace, where I
pushed git commits mentioning SPDX a couple of weeks ago. Did I do it
incorrectly?
--
Jerry James
http://www.jamezone.org/
5:23 p.m.
Dne 27. 02. 23 v 23:41 Jerry James napsal(a):
On Mon, Feb 27, 2023 at 3:35 PM Miroslav
Suchý<msuchy(a)redhat.com> wrote:
> List by package maintainers is here
>
>
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
That shows some packages under my name, such as gap-pkg-ace, where I
pushed git commits mentioning SPDX a couple of weeks ago. Did I do it
incorrectly?
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
say:
|gap-pkg-ace warning: valid as old and new and no changelong entry, please check When I
check
https://src.fedoraproject.org/rpms/gap-pkg-ace/blob/rawhide/f/gap-pkg-ace... I see no
mention in spec %changelog and
when I check the git-log https://src.fedoraproject.org/rpms/gap-pkg-ace/commits/rawhide I
see no mention of spdx
neither. Is it possible that you forgot to git-push? Miroslav |
5:26 p.m.
On Mon, Feb 27, 2023 at 4:23 PM Miroslav Suchý <msuchy(a)redhat.com> wrote:
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
say:
gap-pkg-ace warning: valid as old and new and no changelong entry, please check
When I check
https://src.fedoraproject.org/rpms/gap-pkg-ace/blob/rawhide/f/gap-pkg-ace...
I see no mention in spec %changelog
and when I check the git-log
https://src.fedoraproject.org/rpms/gap-pkg-ace/commits/rawhide
I see no mention of spdx neither.
Is it possible that you forgot to git-push?
No, the commit is here:
https://src.fedoraproject.org/rpms/gap-pkg-ace/c/298f6b5dce052408a6a82eac...
So I guess the script only checks the first line of the git commit
message, right? I guess I'll have to add a changelog entry, then.
--
Jerry James
http://www.jamezone.org/
12:37 p.m.
On 28. 02. 23 0:40, Miroslav Suchý wrote:
Dne 28. 02. 23 v 0:26 Jerry James napsal(a):
> So I guess the script only checks the first line of the git commit
> message, right?
Right. I thought that checking whole commit message may bring more false
positives.
On one hand, I think the script should consider commits like this:
"""
Modernize packaging
Remove deprecated macros
Verify license is SPDX
Drop Fedora 28 conditionals
"""
On the other hand, I consider putting "Verified that License tag is valid
SPDX." into a commit with "Use the %gap_arches macro." in the subject
chaotic evil.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:40 p.m.
On Tue, Feb 28, 2023 at 11:37 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On one hand, I think the script should consider commits like this:
"""
Modernize packaging
Remove deprecated macros
Verify license is SPDX
Drop Fedora 28 conditionals
"""
On the other hand, I consider putting "Verified that License tag is valid
SPDX." into a commit with "Use the %gap_arches macro." in the subject
chaotic evil.
I don't see how the example above is qualitatively different from the
example I posted. Mine was also changing an obsolete usage to a
modern one and verifying the license is SPDX. Why do you think the
two are different?
In any case, as a precaution, I will refrain from playing paladin
characters until this issue is resolved.
--
Jerry "Insert evil cackle here" James
http://www.jamezone.org/
5:33 p.m.
On 28. 02. 23 21:40, Jerry James wrote:
On Tue, Feb 28, 2023 at 11:37 AM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
> On one hand, I think the script should consider commits like this:
>
> """
> Modernize packaging
>
> Remove deprecated macros
> Verify license is SPDX
> Drop Fedora 28 conditionals
> """
>
> On the other hand, I consider putting "Verified that License tag is valid
> SPDX." into a commit with "Use the %gap_arches macro." in the subject
chaotic evil.
I don't see how the example above is qualitatively different from the
example I posted. Mine was also changing an obsolete usage to a
modern one and verifying the license is SPDX. Why do you think the
two are different?
The example I posted is:
"""
Subject line describing a general thing/goal
A specific thing, part of the same specified goal
A specific thing, part of the same specified goal
A specific thing, part of the same specified goal
"""
The other example is:
"""
Subject line describing a specific thing
Another specific thing, possibly part of the same unspecified goal
"""
Generally, I don't like mixing unrelated changes together in one commit, but I
understand that sometimes a single "cleanup" commit gets the job done better
than 12 individual 1-line-diff commits.
When a (pseudo) diff of a commit is:
-foo
+bar
...
-Whatever.(trailing space)
+Whatever.(no trailing space)
And the commit message is:
"""
Change foo to bar for reasons
"""
...I cringe.
If the message is:
"""
Change foo to bar for reasons
While at it, remove the trailing space elsewhere because my editor deleted it.
"""
...I cringe but I am thankful for at least documenting the unrelated change.
However, in both cases at least I notice the unrelated change in the diff. In
my worldview, both are chaotic (read: they violate my imaginary commit-purity
O.C.D. rules), but they are not evil (nothing is "hidden"). In the MIT SPDX
license case, the "mixed in" change is a no-change, so when looking at the diff
we don't notice it, hence I called it "evil".
Hope that makes sense. No judgement intended, I know people have different
expectations and habits when it comes to commits (and dist-git commits in
particular).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4:34 p.m.
On Tue, Feb 28, 2023 at 4:33 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
However, in both cases at least I notice the unrelated change in the
diff. In
my worldview, both are chaotic (read: they violate my imaginary commit-purity
O.C.D. rules), but they are not evil (nothing is "hidden"). In the MIT SPDX
license case, the "mixed in" change is a no-change, so when looking at the
diff
we don't notice it, hence I called it "evil".
Hope that makes sense. No judgement intended, I know people have different
expectations and habits when it comes to commits (and dist-git commits in
particular).
I get your point. However, I think what I did is clearly chaotic
good. Chaotic neutral would be releasing a new version of a software
package that contains both security fixes and new features. Chaotic
evil would be releasing a new version of a software package that
claims to contain both security fixes and new features, but in fact
contains changes that make security worse, and all of the new features
are either broken or break old features. :-)
Have a good week. Regards,
--
Jerry James
http://www.jamezone.org/
9:13 p.m.
Hi,
Miroslav Suchý <msuchy(a)redhat.com> writes:
The list of packages needed to be converted is again here:
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
List by package maintainers is here
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
One package that I care about (`dotnet7.0`) was added to Fedora after
the Let's-move-Fedora-to-SPDX decision was finalized. So the package has
been using SPDX identifiers since the original package review.
How do I make sure such a package is recognized as converted-to-SPDX?
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
7:18 a.m.
Omair Majid kirjoitti 1.3.2023 klo 5.13:
Hi,
Miroslav Suchý <msuchy(a)redhat.com> writes:
> The list of packages needed to be converted is again here:
>
>
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
>
> List by package maintainers is here
>
>
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
One package that I care about (`dotnet7.0`) was added to Fedora after
the Let's-move-Fedora-to-SPDX decision was finalized. So the package has
been using SPDX identifiers since the original package review.
How do I make sure such a package is recognized as converted-to-SPDX?
I have the same issue with iir1, also it has been SPDX from the birth,
but now flagged as needing conversion.
I think Miroslav and company are doing an amazing job with the follow up
and trying to ensure that everything gets converted eventually. However,
please try to avoid creating busy work for packagers. We also have
actual packaging tasks to handle.
The solution for new packages should be such that packagers do not need
to do anything special. Could you just check package age and exclude
anything added after SPDX went live? Any problems in such packages are
just regular guidelines violations. They are important to fix of course,
but strictly speaking not related to the migration effort.
1:57 p.m.
Dne 01. 03. 23 v 4:13 Omair Majid napsal(a):
One package that I care about (`dotnet7.0`) was added to Fedora
after
the Let's-move-Fedora-to-SPDX decision was finalized. So the package has
been using SPDX identifiers since the original package review.
How do I make sure such a package is recognized as converted-to-SPDX?
Hmm, there will be more such packages. I should somehow automate this. Give me few days
please. I will try to do something.
Miroslav
2:08 p.m.
On Wed Mar 1, 2023 at 20:57 +0100, Miroslav Suchý wrote:
Dne 01. 03. 23 v 4:13 Omair Majid napsal(a):
> One package that I care about (`dotnet7.0`) was added to Fedora after
> the Let's-move-Fedora-to-SPDX decision was finalized. So the package has
> been using SPDX identifiers since the original package review.
>
> How do I make sure such a package is recognized as converted-to-SPDX?
Hmm, there will be more such packages. I should somehow automate this. Give me few days
please. I will try to do something.
If you don't want to clone every distgit repository and use the git log,
you can query the rawhide-source repositories and find the date of the
first changelog entry for each package. I don't think you'll be able to
use the repoquery CLI here, but take a look at the reproducer code in
[1] for inspiration on how to use the dnf API for this.
[1] https://github.com/rpm-software-management/dnf5/issues/320
--
Maxwell G (@gotmax23)
Pronouns: He/They
2:49 p.m.
>>>> Maxwell G <maxwell(a)gtmx.me> writes:
If you don't want to clone every distgit repository and use the
git
log, [...]
Even if you did, there is full copy of the git data tarred up nightly at
https://src.fedoraproject.org/repo/git-seed-latest.tar.xz which would
probably save a big load of time.
- J<
457
days inactive
459
days old
13 comments
7 participants
participants (7)
-
Jason Tibbitts -
Jerry James -
Maxwell G -
Miro Hrončok -
Miroslav Suchý -
Omair Majid -
Otto Liljalaakso