On 2/5/19 3:36 PM, Kalev Lember wrote:
On 2/5/19 21:19, Kevin Fenzi wrote:
> Yes, thats a danger... we will have to retag those on a case by case
> basis. The script releng uses to merge side tags won't merge a build if
> there is a newer one, so those should be fine, it's just if the mass
> rebuild build was added and then also someone did another rawhide build.
>
> If you notice any cases of that, file a releng ticket and we can get it
> sorted out.
This sounds fairly bad: everything that got built today and yesterday is
going to get masked out by the older mass rebuild packages that are
being tagged "over" the newer builds as we speak.
Looks like that it was only the mass rebuild packages that got stuck in
the signing queue and other builds were processed normally (they moved
from f30-pending to f30), so they are going to be out of order when the
mass rebuild signing/tagging into f30 finishes.
Is there any chance releng could figure out the list of packages
affected once the signing/tagging is finished and fix all of them? I can
already tell that it's affecting at least 40-50 GNOME builds done in
that time frame.
Yes, there's a releng script to fix this very case... can run after
everything is finished signing/tagging.
Also, maybe next time around it would be better to tag mass rebuild
results directly into f31, skipping f31-pending (making sure everything
is signed before doing it)? It seems just painful to go through the
-pending signing queue which takes several days to process tens of
thousands of packages and can lead to out of order tagging.
The reason we tag into pending is to make sure everything is signed, but
yes, we should just make sure to try and autosign the mass rebuild as it
builds. ;(
kevin