Re: Inadvertent mass-rebuild triggered soname bump in libnfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2025-01-24 at 15:21 -0500, Yaakov Selkowitz wrote:
> 
> On 1/24/25 14:46, Kevin Fenzi wrote:
> > On Thu, Jan 23, 2025 at 06:57:57PM -0500, Stephen Gallagher wrote:
> > > On Thu, Jan 23, 2025 at 6:02 PM Simo Sorce <simo@xxxxxxxxxx> wrote:
> > ...snip...
> > > 
> > > Sorry, thanks. I forgot to note that ELN has a different %{dist} tag
> > > structure than Fedora. We include a "buildroot number" in the %{dist} which
> > > we bump before a mass rebuild. Thus, the ENVR differs by that buildroot
> > > number (while the rest of the ENVR remains the same). So, something like
> > > samba-4.21.3-6.eln145 vs samba-4.21.3-6.eln146
> > > 
> > > Rawhide doesn't have that buildroot number solution, but since the
> > > mass-rebuild does an rpmdev-bumpspec to increase the release number anyway,
> > > it accomplishes the same thing.
> > 
> > I am not sure I understand (and sorry, it's been a very long week).
> > 
> > Example I am thinking of:
> > 
> > - foo-1.0-1.fc42 is latest in f42
> > - maintainer pushes a commit to update to foo-2.0-1
> > - maintainer builds foo-2.0-1 in a side tag, or maintainer tries to build
> > but it breaks for whatever reason, or maintainer builds and it gets
> > stuck in gating.
> > - mass rebuild comes along, finds foo-1.0-1 latest build in f42.
> > - mass rebuild bumps spec to foo-2.0-2 and builds it.
> > - <hyjinks as dependent packages aren't yet rebuilt>
> > 
> > Or do you mean it would find the foo-1.0-1 commit in git and bump that
> > to foo-1.0-2 and just revert the foo-2.0-1 commit?
> > 
> > In the end I think if we find fixing these cases too anoying/frequent,
> > we probibly need to look at all the existing sidetags before the mass
> > rebuild and tell people to merge them or adjust git or something.
> 
> I concur.  There were several packages, some new and some existing, 
> built in side tags prior to the mass rebuild, and they caused all sorts 
> of damage to the mass rebuild which we're still cleaning up.

Note that side tags aren't the only issue. Sometimes a maintainer
commits a bump to git but doesn't build it in a side tag or rawhide,
for whatever reason. Sometimes a package is *built*, but gated from
Rawhide by automated tests, but then the mass rebuild effectively
overrides the gating (we found several cases like this). Just checking
side tags isn't gonna catch everything. I really think the appropriate
check is 'was the build most recently tagged into fXX built from the
current git commit? if not, don't rebuild this package, yell for manual
intervention'.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux