Description of problem: See subject. Version-Release number of selected component (if applicable): 1.1.1-2.1.fc14
Don't know how high the priority on this should be, but this is actively blocking customers from installing RHN Proxy through the webui. This package is required to create the ssl tarball that the web installer requires.
Oh, didn't notice that this is a fedora bug, I will clone for RHEL 5.
This was discussed during the 2010-10-01 blocker review meeting. We conditionally accept it as a blocker on the basis of a proposed new criterion which requires there to be no unresolved dependencies or unintentional conflicts in any package (not just packages on the media) for Final release. See http://lists.fedoraproject.org/pipermail/test/2010-October/094302.html .
seems like the dep is stuck in review: https://bugzilla.redhat.com/show_bug.cgi?id=612581
Yes, and the review is taking too much long and will need a lot of work. ETA is probably few months. I would suggest to delete the F14 and F15 build and revert to spacewalk-certs-tools-0.7.2-1, which does not have this dependency. Once I pass through the review with spacewalk-backend, I will update spacewalk-certs-tools. I'm not sure what is correct process for this? File rel-eng ticket to delete those builds from koji?
'unmaking' builds like this is frowned upon as it's impolite to those who've already installed the newer packages. The usual way to do this is to push a higher-numbered build which simply reverts the changes. If you need to revert to an older upstream version, you'd have to add an Epoch. If this build were only in -testing we might consider it cleaner to unpush the build than to add an Epoch, but since it went to -stable, I rather think we'd prefer you to push a 0.7.2-2 with an Epoch. Bill, WDYT?
Yeah, an epoch is probably best. Or a new build that has the Requires: removed, although the implication is that a build of that sort would be non-functional?
> it's impolite to those who've already installed the newer packages They could not install it. Not using yum. Only possibility is rpm --nodeps, which is not standard work flow. > although the implication is that a build of that sort would be non-functional Which will does not matter since this is part of Spacewalk server and we have not all part in Fedora yet. So unless you have external repo, you will probably have not much use for this package.
I revert to 0.7.2 and bumped up epoch, although I do not like it. http://koji.fedoraproject.org/koji/taskinfo?taskID=2520150
spacewalk-certs-tools-0.7.2-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/spacewalk-certs-tools-0.7.2-1.fc14
spacewalk-certs-tools-0.7.2-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update spacewalk-certs-tools'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/spacewalk-certs-tools-0.7.2-1.fc14
Dependency and conflict issues are automatically accepted as nice-to-have.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I confirm that spacewalk-certs-tools-0.7.2-1.fc14, i.e. 1:0.7.2-1 fixes this issue.
spacewalk-certs-tools-0.7.2-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.