Simon McVittie, le dim. 24 mars 2024 16:45:02 +0000, a ecrit: > On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote: > > Simon McVittie, le dim. 24 mars 2024 11:59:50 +0000, a ecrit: > > > For the specific example of pipewire, I've suggested temporarily > > > dropping that feature from pipewire on the affected architectures > > > <https://bugs.debian.org/1067558> which would get the rebuilds further > > > along (particularly if it unblocks weston, which lots of packages use > > > in their tests). There are various places where targeted changes like > > > this can unblock a whole tree of dependencies. > > > > Could we use build profiles for this? That'd avoid full uploads, and > > document for architecture bootstrapping. > > Only if a porter is willing to do a binary build with the relevant > build profile on each of the affected architectures, and upload it as > binary-only, after making a note to get it binNMU'd later. The official > buildds for release architectures always build with no build profiles, > and do not have any way (that I'm aware of) to vary this. > > The porter-binary-upload approach is necessary for the actual bootstrap > phase of the dependency stack, but doesn't seem to be scaling well in > higher layers, because the number of porters is limited. I'd prefer > to give porters the opportunity to work on more difficult issues where > their architecture-specific knowledge is actually relevant, so I'm doing > my best to unblock some of the dependency chains without having to block > on porter uploads.
I understand these, but - making sure that the Debian release eventually only contains non-profile builds should be relatively easy thanks to the buildinfo files (they currently only contain them in the DEB_BUILD_PROFILES environment variable, they could be added as proper field). We already track against packages built on non-buildd, we could track packages built with profiles. - it's indeed better to avoid loading porters with this, notably because it'll be most often the same for a set of architectures. The buildd infrastructure could have an additional build-profile parameter that can be set on a binNMU, so that such temporary-profile binNMUs can be requested easily. I'm not saying that this is trivial now, of course, but it seems to me that it's not so far, and thus something we'd want to aim for longterm-wise? Samuel
