Thanks for the excellent explanation, Adam. It makes me to understand the problem now.
Jiri
On Fri, Dec 2, 2022 at 10:03 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Fri, 2022-12-02 at 21:25 +0100, Jiri Kucera wrote:
> 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
> here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e8d23a026e
>
> 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
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b
> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
Ahhh, I see what happened!
So, the problem is this. When a Rawhide update "goes stable" in Bodhi,
all that really *means* is, it gets the release tag applied (so 'f38'
at the moment). The next time the buildroot repo is composed after that
(which happens frequently), the packages from the update will be added
to it.
However, the packages from the update will only show up in the main
'rawhide' repository after the next successful Rawhide compose, which
is an uncertain interval. One compose is run per day automatically, so
if those all succeed, you'd be sure of an update making it to 'rawhide'
no more than 24 hours after it reached 'stable'. But sometimes they
fail. When they fail, we might fix the problem and try again, or it
might magically go away with the next day's compose, or we might not
get a successful compose for a while.
Right now, we haven't had a successful compose for several days due to
various problems, so the current packages in the main 'rawhide' repo
are the ones from the last successful compose, which I think was
20221130.n.0. Nothing that's gone "stable" since then is actually in
the repo.
openQA update tests for Rawhide updates use the latest packages from
the main 'rawhide' repo, plus the packages from the update being
tested. They do *not* include packages from the buildroot repo.
So in the openQA tests, the first update - with all the builds in it -
passed the tests just fine. But the second update, which only had gpgme
in it, failed, because it didn't include the rebuilt dependent packages
from the first update, even though they were now "stable".
Overall I'd say this isn't your problem as the packager; everything you
did was totally reasonable. In theory what you "should have done" to
make the tests pass is wait till a Rawhide compose had completed before
submitting the second update, but obviously that's not a reasonable
thing to ask. It's more of a problem for me and releng to think about.
I may think about having openQA Rawhide update tests enable the
buildroot repo that includes packages from the release tag; this would
make it include packages that have gone 'stable' since the previous
Rawhide compose. I'd have to think if there are any potential drawbacks
to doing that. Ironically, Fedora CI currently does that but is
considering *not* doing it any more due to "unpleasant surprises":
https://pagure.io/fedora-ci/general/issue/376 . I'm not sure exactly
what the surprises were, I'll have to look into it.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
_______________________________________________ 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
