The update to qatzip version 1.0.6 was pushed to Fedora Rawhide (36) and Fedora 34, but Fedora 35 was skipped for some reason. The commit log from the f35 branch mentions something about a missing qatlib update (presumably because it's stuck due to the final freeze), but using either a buildroot override or an on-demand side tag and then creating a common bodhi update for both packages should have solved that problem.
Thanks for noticing this. I’m the assignee’s sponsor. The update was originally needed due to an unannounced soname change in qatlib; see https://bugzilla.redhat.com/show_bug.cgi?id=2002463 for details. It looks like the incompatible qatlib update was also pushed to F35 and even to F34. The update in F34 conflicted with the updates policy, https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases), and I think it should have required a FESCo exception. If that was granted, it should have been done via a side tag (https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/) to create an update that included all depenent packages. Now that the qatlib update is in F34 stable, I think it doesn’t make sense to unpush it for F35. That would just create a downgrade that would take even more work to clean up. The best path forward is indeed to create a buildroot override (via https://bodhi.fedoraproject.org/overrides/, or “fedpkg override create”) for qatlib-21.08.0-2.fc35 and use that to build the qatzip 1.0.6 update. Ideally, if permissions allow, the new qatzip build could be added to the existing qatlib update https://bodhi.fedoraproject.org/updates/FEDORA-2021-0b75ef63f1 rather than submitted as a separate update. Please let me know if anything about that is confusing after looking at the linked documentation, or if there’s anything I can help with.
Thanks Fabio and Ben for helping with this! > The best path forward is indeed to create a buildroot override (via https://bodhi.fedoraproject.org/overrides/, or “fedpkg override create”) for qatlib-21.08.0-2.fc35 and use that to build the qatzip > 1.0.6 update. Let me clarify what should I do next... #1 Create an override for qatlib-21.08.0-2.fc35 via https://bodhi.fedoraproject.org/overrides/ (However when I typed in these words the system told me no result) #2 Rebuild qatzip on branch f35 (commit the update and rebuild) Currently we're able to fetch the qatlib-21.08 on f35 and we can build the qatzip-1.0.6 on that. I'll finish the update ASAP. Zheng
Yes, that’s right. The buildroot override web interface has been extremely flaky for me lately. I often have to refresh it and type the package name several times before it works (instead of giving me no result). When it’s working, you should be able to just type “qatlib” and see qatlib-21.08.0-2.fc35 in the dropdown. It did work for me just now. Alternatively, the “fedpkg override create” command has been reliable: > usage: fedpkg override create [-h] [--duration DURATION] [--notes NOTES] [NVR] > > Create a buildroot override from build guessed from current release branch or > specified explicitly. > > Examples: > > Create a buildroot override from build guessed from release branch. Note that, > command must run inside a package repository. > > fedpkg switch-branch f28 > fedpkg override create --duration 5 > > Create for a specified build: > > fedpkg override create --duration 5 package-1.0-1.fc28 > > positional arguments: > NVR Create override from this build. If omitted, build will be guessed from current release > branch. > > optional arguments: > -h, --help show this help message and exit > --duration DURATION Number of days the override should exist. If omitted, default to 7 days. > --notes NOTES Optional notes on why this override is in place. The duration of the override just needs to be however long it will take for you to build the dependent package. ----- It usually takes a few minutes for the buildroot override to be active. You can use the command > $ koji wait-repo f35-build --build=qatlib-21.08.0-2.fc35 which will return only when the override is active. ----- Remember that mock builds use the same repositories, built in (normally daily) composes, that actual installations would use, so they are not affected by buildroot overrides. You can pass mock the option “--enablerepo=local” to change this and build using packages in the koji buildroot. Scratch builds, since they are in koji, always use the buildroot. This distinction often confuses people. ----- Thanks for fixing this. Let me know if you run into any trouble.
Thanks a lot for your help Ben! It's so kind of you to provide such detailed information :) qatzip 1.0.6 is built on branch f35. [Build link] https://koji.fedoraproject.org/koji/buildinfo?buildID=1849606 May I close the ticket, Fabio and Ben? Zheng
It looks like you still need to create a Bodhi update for Fedora 35, the same way you previously did for Fedora 34. See https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#later_branched_and_stable_releases for a reminder. ----- If you like, you can associate this bug with the update and allow Bodhi to close the bug when the update reaches stable. Both the Bodhi web interface and the Bodhi CLI allow you to do this. Comments will be automatically added as the update progresses. If you choose to do this, you probably want to disable the option to require feedback (karma) on the bug from testers, as you’ll likely never get it. See https://bugzilla.redhat.com/show_bug.cgi?id=2017405 for an example of what it looks like when updates are associated with a bug. Note that you can also associate a bug by putting certain strings, fix(es)|close(s) (fedora|epel|rh|rhbz)#BUG_ID, in the changelog message (https://bodhi.fedoraproject.org/docs/user/release_notes.html#v5-3-0). This works even for Rawhide, where Bodhi creates updates automatically whenever a build completes.
The Fedora 35 final freeze is still active, but you can still create updates. They’ll just be held up in testing until the freeze is over. See https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#final-freeze.
FEDORA-2021-b629cff622 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b629cff622
Thanks Ben! I remembered I just created update one time which is the first time I created the package. And every update was created by Vladis after that... Now I associated this ticket with the update and I'll try to put something in the changelog for an automation. Zheng
Looks like everything worked! Thanks. This bug should be closed automatically when the update reaches stable.
FEDORA-2021-b629cff622 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b629cff622` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b629cff622 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 2019122 has been marked as a duplicate of this bug. ***
Thanks Ben for your help! Zheng
FEDORA-2021-b629cff622 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.