For why 32bit architectures are not listed:
Many tests of the buildsystem of the upstream package fail because of Y2K38 bugs.
Upstream does not see that as a problem as running a simulation on these architectures
or simulations of just 16 years is not a goal. Fixing this in Debian would be much hard work and might not be worth it. Which is why would like to prevent it.
If the package builds on the 32bit arches then I would advise that you
let it build. We always try to build for all arches in debian and it
is very annoying if you have say an armhf machine and something is not available just because there was some test failure so upstream simply excluded builds completely. Packges should only be excluded on an arch
if they are known not to build or to be genuinely useless there.
If the package is available then maybe someone who cares will fix
it. If it isn't they probably won't even try. A note in the
Debian.README about this known issue would be helpful.
On 1/24/22 09:10, Ole Streicher wrote:
Wookey <wookey@wookware.org> writes:
If the package builds on the 32bit arches then I would advise that you
let it build. We always try to build for all arches in debian and it
is very annoying if you have say an armhf machine and something is not
available just because there was some test failure so upstream simply
excluded builds completely. Packges should only be excluded on an arch
if they are known not to build or to be genuinely useless there.
I would disagree here: If we can't support a certain package on a
platform, then we shouldn't build it there. If neither upstream nor the
Debian maintainer is going to support armhf, then it should not be built.
I'm not sure if there is a misunderstanding here.
I think every package (unless it doesn't fit to a platform like a boot loader, >or the target architecture is really not meant for that package)
should be *built*. It may fail tests, in which case it should still be built, >but the build should be marked failed and as such no *binary* package
should be produced and uploaded.
But since it was built, platform maintainers may see it, can check the
build logs and may help to fix.
The worst thing for arches is, if a package is being *excluded* from building >on certain arches just because there was a build- or test error.
That way nobody will notice and there will never someone look into it.
Wookey <wookey@wookware.org> writes:
If the package builds on the 32bit arches then I would advise that you
let it build. We always try to build for all arches in debian and it
is very annoying if you have say an armhf machine and something is not
available just because there was some test failure so upstream simply
excluded builds completely. Packges should only be excluded on an arch
if they are known not to build or to be genuinely useless there.
I would disagree here: If we can't support a certain package on a
platform, then we shouldn't build it there. If neither upstream nor the Debian maintainer is going to support armhf, then it should not be built.
For example, I have a package (iraf) that builds fine on big-endian
systems but some tests fail there. I (being both upstream and the Debian maintainer) am not going for a bug hunt since I don't see a use in it,
but I know that the existing bug may make some astronomical calculations (unnoticed) wrong. It is better not not have that package than a buggy package.
If someone needs it, they are free to fix the problems so that
we include it but unless nobody cares I will not deliver a known-buggy package by just disabling the failing tests.
If the package is available then maybe someone who cares will fix
it. If it isn't they probably won't even try. A note in the
Debian.README about this known issue would be helpful.
This is only true if the bug is noticed, which is not always the
case.
Best
Ole
On 1/24/22 09:10, Ole Streicher wrote:
Wookey <wookey@wookware.org> writes:
If the package builds on the 32bit arches then I would advise that you
let it build. We always try to build for all arches in debian and it
is very annoying if you have say an armhf machine and something is not
available just because there was some test failure so upstream simply
excluded builds completely. Packges should only be excluded on an arch
if they are known not to build or to be genuinely useless there.
I would disagree here: If we can't support a certain package on a
platform, then we shouldn't build it there. If neither upstream nor the
Debian maintainer is going to support armhf, then it should not be built.
I'm not sure if there is a misunderstanding here.
I think every package (unless it doesn't fit to a platform like a boot loader,
or the target architecture is really not meant for that package)
should be *built*. It may fail tests, in which case it should still be built, but the build should be marked failed and as such no *binary* package
should be produced and uploaded.
But since it was built, platform maintainers may see it, can check the
build logs and may help to fix.
The worst thing for arches is, if a package is being *excluded* from building on certain arches just because there was a build- or test error.
That way nobody will notice and there will never someone look into it.
Helge Deller <deller@gmx.de> writes:
On 1/24/22 09:10, Ole Streicher wrote:
Wookey <wookey@wookware.org> writes:I'm not sure if there is a misunderstanding here.
If the package builds on the 32bit arches then I would advise that you >>>> let it build. We always try to build for all arches in debian and it
is very annoying if you have say an armhf machine and something is not >>>> available just because there was some test failure so upstream simply
excluded builds completely. Packges should only be excluded on an arch >>>> if they are known not to build or to be genuinely useless there.
I would disagree here: If we can't support a certain package on a
platform, then we shouldn't build it there. If neither upstream nor the
Debian maintainer is going to support armhf, then it should not be built. >>
I think every package (unless it doesn't fit to a platform like a boot loader,
or the target architecture is really not meant for that package)
should be *built*. It may fail tests, in which case it should still be built,
but the build should be marked failed and as such no *binary* package
should be produced and uploaded.
But since it was built, platform maintainers may see it, can check the
build logs and may help to fix.
The worst thing for arches is, if a package is being *excluded* from building
on certain arches just because there was a build- or test error.
That way nobody will notice and there will never someone look into it.
Users of the platform may request the package if they need it (and they
are relevant people for us). And attempting to build the package on such
a platform is as easy as adding the architecture to d/control for the
user. And porters can also just check which packages are not built on a platform.
That's why I'm saying that you shouldn't exclude by default a *specific* architecture. The problem is often not bound to that architecture, but by
the specifics which define that architecture (endianess, 32/64-bit, ...).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 299 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 79:29:57 |
| Calls: | 6,695 |
| Files: | 12,229 |
| Messages: | 5,347,653 |