I'd like to ask for a blanket package review exception for Golang packages that I would need to create to update our current stack of Go packages. As I'm mostly alone doing this in the Go-SIG and doing the review request process, I'd like to not being stopped by several weeks of stalled reviews. There is close to 1,300 Golang packages that needs checking, and if updating incurs new dependencies, I'd like to be able to tackle them swiftly.
All the packages will be autogenerated with go2rpm. Licenses are autodetected, all failing tests are documented.
Best regards,
Robert-André
+1 from me.
May I ask this to be added to the meeting agenda?
Metadata Update from @ignatenkobrain: - Issue tagged with: meeting
Not sure if meeting helps, going by the last few months :)
But if you make sure that you don't package any non-free / license-problematic stuff, then I'm +1 to some granting review exception to automatigally generated new packages.
No chance that I package non-free stuff, some I have encountered was package with no license but in that case I try to cut out that dependency if upstream is dead.
Could you please post the packages for a mass review instead of asking for a blanket exception?
A mass review? I've never heard of this. The issue is I don't know in advance what package will need what new dependencies so I can't prepare a list in advance. I have 1,650 Go packages to check for an update (a lot don't work with Anitya because they have no release, only a git commit), at the end of this day I hope to have checked around 100. I have 6 new packages among this 100 for the time being, I can post them:
https://eclipseo.fedorapeople.org/for-review/golang-github-zclconf-cty.spec https://eclipseo.fedorapeople.org/for-review/golang-github-shurcool-githubv4.spec https://eclipseo.fedorapeople.org/for-review/golang-github-apparentlymart-textseg.spec https://eclipseo.fedorapeople.org/for-review/golang-github-apparentlymart-dump.spec https://eclipseo.fedorapeople.org/for-review/golang-github-xlzd-gotp.spec https://eclipseo.fedorapeople.org/for-review/golang-github-agext-levenshtein.spec
As you can see they all follow the same template, there are no surprise.
A mass review? I've never heard of this.
Well, that's not an official concept, just my idea of: "here are 500 specfiles, please exempt them from review"
So you won't generate all the package at once, but add them gradually?
A mass review? I've never heard of this. Well, that's not an official concept, just my idea of: "here are 500 specfiles, please exempt them from review" So you won't generate all the package at once, but add them gradually?
Well, that's not an official concept, just my idea of: "here are 500 specfiles, please exempt them from review" So you won't generate all the package at once, but add them gradually?
Yes, I don't have an automated process. I check a package for update, find out if there are new dependencies and then create new SPECs with go2rpm. Dependencies chains may be pretty long, I have to iterate over each new ones.
We talked about this in this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-07-23/fpc.2020-07-23-16.01.txt):
So i have mostly finished the updates I needed to do, I now have 114 new Go packages to import. All are working in this COPR: https://copr.fedorainfracloud.org/coprs/eclipseo/gotests2/builds/
SPEC and SRPM are here: https://eclipseo.fedorapeople.org/golang3/
I've looked at a few of the .spec files, and other than a few small issues, they look fine:
Name: %{goname}
I've looked at a few of the .spec files, and other than a few small issues, they look fine: make sure that Name: %{goname} actually expands to %{name}.spec (or don't use %goname :)) make sure to drop :tm: and :registered: symbols from package summaries and descriptions
I have not found any occurrences of either.
@eclipseo here's one: https://eclipseo.fedorapeople.org/golang3/golang-github-360entsecgroup-skylar-excelize/golang-github-360entsecgroup-skylar-excelize.spec
ha I searched for \:tm\: and \:registered\:
It should be okay now: I've checked for © ® ™ and eliminated the occurrences in Summary and description. I've rsynced the fixes.
Is it possible to have ananswer soonish, I have prepared the updates and all the Golang FTBFS, I now just need to do make it effective.
Thanks!
@eclipseo sorry, I forgot to bring this up during today's meeting. But we actually have 9 active members again, so I hope we can collect some votes in ticket so you can proceed with requesting and building packages soon.
From my point of view the packaging looks fine. I can't claim to have looked at all of them (because I haven't), but the ones I looked at were fine.
@churchyard there's now also a list of packages with .spec files.
FPC people, please vote :)
I'm good with it... +1
+1
Note that I did ask the legal list, but got a confusing mess of responses which didn't really clarify matters: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/W3VDT6ECUIC7RM4YJK5UQYRYQS2QPSQ5/
At this point I don't know; I don't like pointless bureaucracy so as long as someone is looking after the license stuff properly then I say go with it. I can't recall any hard requirement that licenses be checked by two different people.
I have to admit I'm a little biased as I'm not very fond of packaging libs for languages which have their own distro-agnostic packaging system. That aside, if you do it in batches (100-200 packages?) and initially put aside packages which look suspicious (for instance, from a licensing perspective) , you have my
+1.
We talked about this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-09-03/fpc.2020-09-03-16.00.txt):
Metadata Update from @james: - Issue close_status updated to: accepted - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.