On Sun, Jan 19, 2025 at 03:37:09PM +0000, Gary Buhrmaster wrote: > On Sat, Jan 18, 2025 at 10:44 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > > So if you see packages that *change* (either their dependencies, or > > their contents - but ignoring codegen differences with new compiler > > versions etc.) between the last build before the mass rebuild and the > > build performed during the mass rebuild, that's a sign that the update > > was not pushed "correctly" in the first place, IMO. > > I would agree. So, the question is, can > "we" change something to try to make > doing the "correct" thing easier? > > Could fedpkg push be changed to > automatically also do a build (or > perhaps better, scratch-build?) so > that any unexpected FTBFS is seen > quicker? Yes, there are cases where > you would not want that (especially > for soname bumps where you need > a side-tag so you would not want > an auto full build), but would adding > something like a "--no-auto-build" > option at least force things to being > explicit? > > FWIW (for my simple packages) I > almost always do a scratch-build > right after a push, as architecture > specific build issues is something > I am not setup to test locally. That doesn't sound useful. Most pushes to dist-git fall into two categories: 1. a significant change that is immediately followed by a normal build and a bodhi update, 2. some trivial fix that is not worth building for, so the packager pushes the commit so that it'll be built whe a change of the first type is made. When things FTBFS, this is often because the dependencies changed, but this happens over time. For example, one my packages failed in this mass rebuild with the new version of sphinx. But it built just fine 18 months ago when it was last meaningfully changed… An immediate scratch build (18 months ago) would not help in any way. Overall, the case you describe, i.e. the maintainer pushing a bigger change that breaks the build only on some architectures, _and_ without attempting a build soon after, seems to be very niche. Zbyszek -- _______________________________________________ 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
