Description of problem: When trying to do fedpkg update receive the following message: Could not execute update: This system has bodhi v5, which is unsupported. Version-Release number of selected component (if applicable): fedpkg-1.37-9.fc31.noarch Additional info: I checked kodi.. this is the lastest version of fedpkg... what gives?
What version of bodhi-client do you have? 'rpm -q bodhi-client'
rpm -qa | grep bodhi-client bodhi-client-5.1.1-1.fc31.noarch python3-bodhi-client-5.1.1-1.fc31.noarch
Looks like this is being caused by someone pushing something to updates-testing that doesn't work with the current systems. Either it needs to be immediately fixed or rolled back. Changing component to bodhi from fedpkg.
can you expand on "someone pushing something to updates-testing" ? Did you find that downgrading bodhi-client made it work? To what version?
(In reply to Kevin Fenzi from comment #4) > can you expand on "someone pushing something to updates-testing" ? Yeah, specifically: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fe8a66f4ed The someone being: https://bodhi.fedoraproject.org/users/nphilipp > > Did you find that downgrading bodhi-client made it work? To what version? Backout to the previous version using dnf downgrade bodhi-client, which provides: bodhi-client-4.1.0-3.fc31.noarch python3-bodhi-4.1.0-3.fc31.noarch python3-bodhi-client-4.1.0-3.fc31.noarch
That "someone" being me, let me attempt to shed some light on the situation: - The update in question is still in testing, which is the stage to find out these types of issues. And it worked! - The message in question is displayed not because of an actual incompatibility between fedpkg and the Bodhi client bindings >= 5.0, but because of a hard-coded version check in fedpkg. Why this isn't reflected in a corresponding package conflict, no idea. - I'm doing some tests and if they work out, I'll bump the version to let fedpkg accept the current version of the Bodhi client bindings, and add it to this update. Resetting priority and severity to appropriate levels.
Hi I am looking at it. I will update fedpkg to be able to work with the new bodhi-client.
(In reply to Nils Philippsen from comment #6) > That "someone" being me, let me attempt to shed some light on the situation: > > - The update in question is still in testing, which is the stage to find out > these types of issues. And it worked! To an extent, but you're not suppose to push something without ANY testing - and fedpkg is an important dependency - and this issue is exposed quite easily. In fact, this issue was first reported 3 days ago - almost immediately after the change was pushed. > - The message in question is displayed not because of an actual > incompatibility between fedpkg and the Bodhi client bindings >= 5.0, but > because of a hard-coded version check in fedpkg. Why this isn't reflected in > a corresponding package conflict, no idea. > - I'm doing some tests and if they work out, I'll bump the version to let > fedpkg accept the current version of the Bodhi client bindings, and add it > to this update. > > Resetting priority and severity to appropriate levels. The priority was set to urgent because this was affecting production components and I had no idea what was causing it. I then had to go on a treasure hunt to find out what was causing the issue, which turned out to be your change. As mentioned above, this issue was reported almost immediately after the change was pushed - so it was having high impact - yet no response. If you don't want to respond to messages over the weekend, then you should push your changes on a Monday, not right before a weekend.
(In reply to Gerald Cox from comment #8) > (In reply to Nils Philippsen from comment #6) > > That "someone" being me, let me attempt to shed some light on the situation: > > > > - The update in question is still in testing, which is the stage to find out > > these types of issues. And it worked! > > > > To an extent, but you're not suppose to push something without ANY testing - > and fedpkg is an important dependency - and this issue is exposed quite > easily. > In fact, this issue was first reported 3 days ago - almost immediately after > the change was pushed. Good thing I didn't push things "without ANY testing" then. Admittedly, that fedpkg includes a hardcoded check for the version of the Bodhi client bindings caught me flat-footed. It didn't help that fedpkg doesn't conflict with a "too high" Bodhi version on the package level, otherwise I'd probably have caught it myself. Again, this is what the testing stage of an update is for: there purposefully aren't any promises about the quality of the updates in testing, or guaranteed response times. We strive to submit high-quality content as updates, don't get me wrong, but this is the place to find issues that neither the maintainer found in their own tests, nor were caught by automated testing. > > Resetting priority and severity to appropriate levels. > > The priority was set to urgent because this was affecting production > components and I had no idea > what was causing it. My comment wasn't to criticize you, only to document the change. The priority and severity levels have defined meanings, if you want to look them up, their labels above link to the relevant docs. > I then had to go on a treasure hunt to find out what > was causing the issue, > which turned out to be your change. As mentioned above, this issue was > reported almost > immediately after the change was pushed - so it was having high impact - yet > no response. If you > don't want to respond to messages over the weekend, then you should push > your changes on a Monday, not > right before a weekend. When I created it, I set the corresponding update so that it won't be automatically pushed to stable, neither by way of positive karma nor elapsed time, precisely to give this the testing exposure it needs. I've made notes about a couple things here, not only about taking fedpkg into consideration when next releasing a major version upgrade of Bodhi into Fedora, but there also are conversations we need to have between fedpkg and Bodhi about how helpful this version check is or if there are better alternatives, because the check doesn't cover the server-side API at all which has been at 5.x for quite some time. It doesn't help you if fedpkg is tied to a particular maximum version of the Bodhi client bindings, when the compatibility of that with the backend isn't guaranteed.
Fixed in Rawhide with fedpkg-1.37-13.fc32, updates for F30, F31 will follow suit.