Bug 1093867 - fedpkg retire needs to munge branch name sent to pkgdb-cli for epel branches
Summary: fedpkg retire needs to munge branch name sent to pkgdb-cli for epel branches
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: fedpkg
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dennis Gilmore
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-02 21:59 UTC by Toshio Ernie Kuratomi
Modified: 2016-05-20 20:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-20 20:38:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1107646 0 unspecified CLOSED fedpkg fails to retire a package 2021-02-22 00:41:40 UTC

Internal Links: 1107646

Description Toshio Ernie Kuratomi 2014-05-02 21:59:49 UTC
Description of problem:

Fedora branches in pkgdb are of the form fN  (ex: f20) but epel 5 and 6 (not sure about epel  7) are of the form EL-N  (ex: EL-6).  fedpkg retire is trying to use "el6" which generates an error.

Version-Release number of selected component (if applicable):

fedpkg-1.15-1.fc20.noarch

How reproducible:

Everytime

Steps to Reproduce:
1. fedpkg clone openstack-sahara 
2. cd openstack-sahara
3. fedpkg retire "epel update policy is not compatible with openstack rapid cycles"

Actual results:

$ fedpkg retire "epel update policy is not compatible with openstack rapid cycles"
rm '.gitignore'
rm 'openstack-sahara-api.init'
rm 'openstack-sahara-api.service'
rm 'openstack-sahara.spec'
rm 'sources'
rm 'sqlalchemy0.7-magic.patch'
[el6 2eaeba9] epel update policy is not compatible with openstack rapid cycles
 7 files changed, 1 insertion(+), 473 deletions(-)
 delete mode 100644 .gitignore
 create mode 100644 dead.package
 delete mode 100644 openstack-sahara-api.init
 delete mode 100644 openstack-sahara-api.service
 delete mode 100644 openstack-sahara.spec
 delete mode 100644 sources
 delete mode 100644 sqlalchemy0.7-magic.patch
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
To ssh://mimccune.org/openstack-sahara
   e945aab..2eaeba9  el6 -> el6
FAS password: 
ServerError(https://admin.fedoraproject.org/pkgdb/acls/dispatcher/set_owner, 500, Internal Server Error)
Could not retire package: Command '['pkgdb-cli', 'orphan', '--retire', 'openstack-sahara', 'el6']' returned non-zero exit status 3


Expected results:

The pkgdb-cli command would have been:

pkgdb-cli orphan --retire openstack-sahara EL-6

and then the retire command would complete successfully.

Comment 1 Gerard Ryan 2014-05-30 19:32:48 UTC
I'm seeing a potentially related issue for retiring Fedora packages at the moment with fedpkg-1.15-1.fc20.noarch

First of all, if the origin remote url ends with ".git" (I'm not sure if I originally cloned that with fedpkg command or with Eclipse plugin), I get this error:

No package found by this name
Could not retire package: Command '['pkgdb-cli', 'orphan', '--retire', 'tesla-filelock.git', 'devel']' returned non-zero exit status 8

Then when I change the remote url to remove the ".git", this happens:

No collection found by the name of devel
Could not retire package: Command '['pkgdb-cli', 'orphan', '--retire', 'tesla-filelock', 'devel']' returned non-zero exit status 8

Using pkgdb-cli afterwards with the correct parameters works fine.

Comment 2 Jaroslav Reznik 2015-03-03 15:45:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 3 Till Maas 2016-05-20 20:38:47 UTC
AFAIK this is fixed now. If there is still a problem with retirement, please re-open this bug or open a new one.


Note You need to log in before you can comment on or make changes to this bug.