Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 2016713 - qatzip 1.0.6 update missing from Fedora 35
Summary: qatzip 1.0.6 update missing from Fedora 35
Alias: None
Product: Fedora
Classification: Fedora
Component: qatzip
Version: 35
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: zm627
QA Contact:
: 2019122 (view as bug list)
Depends On:
Blocks: F35FailsToInstall
TreeView+ depends on / blocked
Reported: 2021-10-22 21:02 UTC by Fabio Valentini
Modified: 2021-11-06 01:26 UTC (History)
4 users (show)

Fixed In Version: qatzip-1.0.6-1.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-11-06 01:26:34 UTC
Type: Bug

Attachments (Terms of Use)

Description Fabio Valentini 2021-10-22 21:02:24 UTC
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.

Comment 1 Ben Beasley 2021-10-22 21:16:00 UTC
Thanks for noticing this. I’m the assignee’s sponsor.

The update was originally needed due to an unannounced soname change in qatlib; see 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,, and I think it should have required a FESCo exception. If that was granted, it should have been done via a side tag ( 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, 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 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.

Comment 2 zm627 2021-10-25 05:14:28 UTC
Thanks Fabio and Ben for helping with this!

> The best path forward is indeed to create a buildroot override (via, 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 (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.


Comment 3 Ben Beasley 2021-10-25 12:12:25 UTC
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.

Comment 4 zm627 2021-10-28 12:47:10 UTC
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]

May I close the ticket, Fabio and Ben?


Comment 5 Ben Beasley 2021-10-28 13:47:22 UTC
It looks like you still need to create a Bodhi update for Fedora 35, the same way you previously did for Fedora 34. See 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 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 ( This works even for Rawhide, where Bodhi creates updates automatically whenever a build completes.

Comment 6 Ben Beasley 2021-10-28 13:51:20 UTC
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

Comment 7 Fedora Update System 2021-10-29 05:18:28 UTC
FEDORA-2021-b629cff622 has been submitted as an update to Fedora 35.

Comment 8 zm627 2021-10-29 05:19:17 UTC
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.


Comment 9 Ben Beasley 2021-10-29 18:35:14 UTC
Looks like everything worked! Thanks. This bug should be closed automatically when the update reaches stable.

Comment 10 Fedora Update System 2021-10-29 21:17:18 UTC
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:

See also for more information on how to test updates.

Comment 11 Ben Beasley 2021-11-01 17:19:26 UTC
*** Bug 2019122 has been marked as a duplicate of this bug. ***

Comment 12 zm627 2021-11-02 01:42:12 UTC
Thanks Ben for your help!


Comment 13 Fedora Update System 2021-11-06 01:26:34 UTC
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.

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