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 <adamw...@fedoraproject.org>
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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to