It is orphaned in the current system, but it is unknown to pkgdb: https://admin.fedoraproject.org/pkgdb/packages/gpxviewer%2A/
The koji history indicates that it was unretired as part of the pkgdb deprecation (f27 was created by pkgdb in August 2017)
$ koji list-history --package gpxviewer Tue Aug 4 22:33:32 2009 package list entry created: gpxviewer in dist-f10 by nobody [still active] Tue Aug 4 23:57:08 2009 package list entry created: gpxviewer in f12-alpha by nobody [still active] Tue Sep 29 19:59:59 2009 package list entry created: gpxviewer in f12-beta by nobody [still active] Thu Oct 15 21:54:43 2009 package list entry created: gpxviewer in f12-final by nobody [still active] Wed Feb 17 00:18:23 2010 package list entry created: gpxviewer in dist-f13 by nobody [still active] Fri May 25 23:05:07 2012 package list entry created: gpxviewer in f17-final by ausil [still active] Fri Sep 14 21:40:42 2012 package list entry created: gpxviewer in f18-Alpha by ausil [still active] Sun Oct 7 21:04:06 2012 package list entry created: gpxviewer in dist-f15-eol by ausil [still active] Fri Nov 23 05:59:31 2012 package list entry created: gpxviewer in f18-Beta by ausil [still active] Fri Jan 11 14:56:52 2013 package list entry created: gpxviewer in f18-final by ausil [still active] Fri Aug 11 19:00:19 2017 package list entry created: gpxviewer in f27 by pkgdb [still active] Wed Aug 16 02:06:22 2017 package list entry created: gpxviewer in f28 by mohanboddu [still active] Fri Sep 29 14:24:32 2017 package list entry created: gpxviewer in f27-Beta by mohanboddu [still active] Tue Feb 20 11:20:07 2018 package list entry created: gpxviewer in f29 by mohanboddu [still active] Thu Mar 29 21:33:37 2018 package list entry created: gpxviewer in f28-Beta by mohanboddu [still active]
It would be good to know what happened here to figure out if there are other pkgs like this that need to be cleaned up.
FYI: I cannot retire it: FATAL: W any rpms/gpxviewer till DENIED by fallthru (or you mis-spelled the reponame)
Also: https://src.fedoraproject.org/rpms/kimdaba https://src.fedoraproject.org/rpms/kile-i18n
I note there is a very similar package: https://src.fedoraproject.org/rpms/gpx-viewer perhaps this was somehow renamed without retiring the old one?
@pingou any ideas? Should we just remove these 3 packages since they don't really exist?
Metadata Update from @kevin: - Issue priority set to: Waiting on Asignee (was: Needs Review)
So for all three projects, they got the f27 branch when we branched, since all packages got the f27 branch regardless of their status (active, orphaned or retired).
Both kimdaba and kile-i18n have a dead.package file.
gpxviewer is surprising indeed. It seems to be a very old package and I'm not sure why pkgdb doesn't know it.
@till what do you suggest as way forward here? Do you have commit access to gpxviewer to retire it properly? Should we entirely delete it?
I do not have commit access there (not sure why), I tried to retire it when I found it. I guess retiring it properly would be the best way to handle this. Otherwise we would need to make sure to remove all other traces of it to not add confusion later on.
Anything I can do to help here?
@till could you ping me on IRC, I'll look at providing you commit to the repo
So I refreshed the gitolite's config for gpxviewer so the releng group gets its usual access to all packages.
Thx, I have now access to gpxviewer and retired it in dist-git. When I tried to check its retirement status I noticed that PDC does not know about it:
curl "https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/?branch=master&global_component=gpxviewer" {"count":0,"next":null,"previous":null,"results":[]}
So the journey is not over, yet. :-(
I removed the extra files for https://src.fedoraproject.org/rpms/kimdaba https://src.fedoraproject.org/rpms/kile-i18n but both seem to be unknown to PDC, too. @ralph @mprahl or @dcallagh - can you help with PDC?
Metadata Update from @ralph: - Issue assigned to ralph
We only created branches in PDC for branches known in PkgDB, so if this didn't exist in PkgDB at the time of migration, then it makes sense these entries never made it to PDC. Pagure should only mark a repo as not retired if there is a component-branch-slas entry for the master branch with active set to true. If that logic is correct, the absence of an entry should be okay. @pingou could you please confirm this?
Pagure should only mark a repo as not retired if there is a component-branch-slas entry for the master branch with active set to true.
Pagure has no knowledge of package status (retired, orphaned, active), we try to give some indication in the UI but it is all based on PDC data.
IMHO it would be great to add the proper information to PDC to make sure things get consistent and if there is a migration to some other tool at one point, the information does not get lost again.
Pagure should only mark a repo as not retired if there is a component-branch-slas entry for the master branch with active set to true. Pagure has no knowledge of package status (retired, orphaned, active), we try to give some indication in the UI but it is all based on PDC data.
But I thought its ACLs were derived from PDC data?
True the script that creates the gitolite ACLs for users queryies PDC, so only active branches are being granted commit access.
In other words, the orphan user has no access on master since master isn't active on gpxviewer. The releng group however, has access to all repos, all the time.
OK - I used the releng/scripts/pdc/create-branch.py script to create the branches in PDC for gpxviewer, kile-i18n, and kimdaba, and I set the EOL to yesterday, May 31, indicating they are retired.
releng/scripts/pdc/create-branch.py
Metadata Update from @ralph: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.