Yes, builds in [1] were built with the `f38-build-side-60497` side tag. In [1] there are two errors that were not here in time I hit the submit button (maybe I should wait a bit longer):
* `nothing provides libqgpgme.so.7 needed by kdepim-addons-22.08.3-1.fc38.i686` - this one was
caused by not building `kdepim-addons` on `i686` since missing `libphonenumber` on `i686`.
`libphonenumber` is not built for `i686` anymore due to `ExclusiveArch: %{java_arches}`. This
can be fixed by skipping building the Java binding for `i686` only.
* ```
Undeclared file conflicts:
kleopatra-*.i686 provides ... which is also provided by kleopatra-*.x86_64
...
kmail-*.i686 provides ... which is also provided by kmail-*.x86_64
...
```
These must have appeared also in the update before, but I cannot find `rpmdeplint` tests
I submitted [2] approx. 22h after [1] became stable. Have no idea why the builds from pre-[1] rawhide were picked up. However, `rpmdeplint` repoclosure failures are happening only on `i686` so maybe this is somehow connected with `kdepim-addons` not built for `i686`.
Regards and sorry for the chaos,
Jiri
On Fri, Dec 2, 2022 at 11:54 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 02. 12. 22 1:46, Adam Williamson wrote:
> On Wed, 2022-11-30 at 13:59 +0100, Jiri Kucera wrote:
>> Thanks for the reminder Petr. I will do the rebase in rawhide only then.
>
> Thanks for taking care of these dependencies and announcing the bump.
>
> For extra bonus points :D, if it's not too much trouble, it would be
> great if you could do this on a side tag in future - yes, even for
> Rawhide. Without a side tag and combined update, the openQA tests for
> the gpgme update fail:
> https://openqa.stg.fedoraproject.org/tests/overview?version=38&groupid=2&build=Update-FEDORA-2022-603eea89a3&distri=fedora
> if the gpgme bump and all dependent rebuilds were in the same update,
> the tests would pass (assuming nothing's actually broken).
>
> Right now we're not gating Rawhide updates on test failures, but I do
> check them all, so I had to make sure all the rebuilds had actually
> been done, then add comments noting the tests need to be re-run after
> the next Rawhide compose, then remember to re-run them so all that ugly
> red ink goes away :D If/when we do start gating Rawhide on openQA
> failures, this update would be blocked by gating.
Interesting. I saw
https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b where side tag
was used.
Later, there was https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
which only changed a small portion from the package.
Why would the tests fails for the second update?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
