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

Re: time_t progress report



On Sun, 24 Mar 2024 at 18:20:30 +0100, Samuel Thibault wrote:
> - 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.

For this particular transition, since that feature doesn't currently exist
in our production infrastructure, we need to get by without it. But, for
the longer term, if someone is able to work on developing what you suggest:

Instead of applying a temporary build profile to all architectures,
ideally we'd be able to say something like "build with nocheck on armel,
armhf, hppa, m68k and powerpc, and normally everywhere else". I think
as well as being able to perform binNMUs with a specified set of build
profiles on particular architectures, this transition would have needed
a way to get the initial build (no +b suffix) to be done with specified
build profiles, because we're often seeing this pattern:

- a developer uploads foo_1.2-3.1 to rename libfoo0 to libfoo0t64
- on the 64-bit architectures plus i386, it builds fine
- on the 32-bit non-x86 architectures, it's blocked waiting for libbar1t64
  to become available
- armel is unblocked when a porter does a binary build of foo on armel
  with <pkg.foo.nobar>, which means it no longer needs libbar1t64
- and so on for the other architectures

and I don't think creating a binNMU is allowed if the sourceful upload
hasn't been built successfully yet.

Also, if this feature existed as you describe it, then we'd be moving the
bottleneck from porters to the release team / wanna-build operators, who
can schedule binNMUs (unilaterally or on request from other contributors).

If this feature existed *and* DDs could schedule binNMUs on a self-service
basis (the same way we can give back failed builds now), then yes,
that would spread out the load to all DDs. Or, if the maintainer or NMU
uploader could do a source upload with something like this in either
the .dsc, the .changes or some accompanying file:

    Use-Build-Profiles: nocheck [armel armhf hppa m68k powerpc], ...

then that would be a way to get the same result as some of the temporary
changes I've been making, but without having to write custom code in
debian/rules.

    smcv


Reply to: