On Thu, Dec 19, 2024 at 05:19:57PM +0100, Santiago Vila wrote:
> El 19/12/24 a las 17:05, Adrian Bunk escribió:
> > If a QA environment differs significantly from the buildds where the
> > package is usually built, then this might be considered a bug in the
> > QA environment - you are not testing whether the package would still
> > build on the buildds.
>
> We are a free software distribution. If the end user can't rebuild
> a given package without a lot of trouble, that's also a problem.
We had this discussion many times before, and I don't want to go to the
Debian Technical Committee for the same again.
Some packages will not build when a build machine differs from the
typical buildd setup.
> > If the problem is just a single package in your setup, the easiest
> > solution is to blacklist that package in your setup.
>
> No way.
>
> I want to ensure that the end user will be able to build all packages.
> This includes Lucas Nussbaum in his setup, and also mine.
We are a binary distribution.
End users are not supposed to rebuild our packages.
You were annoying everyone for years with trying to rebuild all packages
on a machine with only one core claiming this would be so important for
QA work that your bugs have to be release critical, and now we have the
same again.
> Skipping packages will not help to achieve that goal.
>
> Please stop posting to this bug, you are not helping anymore
> at this point with those kind of comments.
>
> I'll try to find a solution which works for everybody.
Add more swap to your setup.
The root cause of this bug (where you have caused an RC issue) is that
you are trying to build all packages on a build machine that significantly
differs from the buildd setup.
Why are you doing your rebuilds actually?
Most useful for Debian are rebuilds that are best at finding FTBFS on
the buildds. This is what actually matters, not trying to get the whole
archive build on whatever different setup you have at some point in time.
Keeping the archive building on all buildds is hard enough, it is not
helpful creating work to get everything building in random different
setups.
And it is really horrible when you are making statements like
The simple and effective way: Disable parallel building
This is super-painful for exactly the packages with long build times
that also use a lot of memory during the build.
In some cases people have spent a considerable amount of time for making
parallel building working.
You might not care if non-parallel building is not a problem in your
setup, but disabling parallel building for large packages is really
harmful on the Debian buildd infrastructure.
> Thanks.
cu
Adrian
