On 11-09-2022 17:08, Samuel Thibault wrote:
We could for instance:
- Add an Architecture-FTBFS field to debian/control
- Add an environment variable to debian/rules so that on these archs dh
fails with a different exit code that buildds would notice.
- Add a Architecture-FTBFS field in the wb database that DDs can set
- color packages that "never" had a successful built on an architecture different. That information is already available because that's what marks the package as "uncompiled" vs "out-of-date".
Paul Gevers, le dim. 11 sept. 2022 21:16:08 +0200, a ecrit:
- color packages that "never" had a successful built on an architecture different. That information is already available because that's what marks the package as "uncompiled" vs "out-of-date"....
That doesn't cover the case when a package stopped building on an arch, though.
Samuel
...
The issue we see is that some DDs end up setting a hardcoded list in
the "Architecture" field, rather than just letting builds keep failing
on these archs (and then possibly succeeding after some time whenever somebody contributes a fix upstream that gets propagated to Debian).
...
Samuel
On Sun, Sep 11, 2022 at 05:08:57PM +0200, Samuel Thibault wrote:
...I'd say it is the best solution when a package needs non-trivial architecture-specific porting for every architecture it supports.
The issue we see is that some DDs end up setting a hardcoded list in
the "Architecture" field, rather than just letting builds keep failing
on these archs (and then possibly succeeding after some time whenever
somebody contributes a fix upstream that gets propagated to Debian).
...
With "non-trivial" I mean not just adding a new architecture to a few #ifdefs, but serious upstream porting efforts. E.g. valgrind does not
support riscv64, and if it would ever gain the support in a new upstream version I'd expect the maintainer to add that to the Architecture field
when upstream announces support for a new architecture.
Architecture lists containing all 64bit ports or all little endian
ports create much extra work for anyone adding support for a new
64bit little endian architecture.
On Sun, Sep 11, 2022 at 05:08:57PM +0200, Samuel Thibault wrote:
...
The issue we see is that some DDs end up setting a hardcoded list in
the "Architecture" field, rather than just letting builds keep failing
on these archs (and then possibly succeeding after some time whenever somebody contributes a fix upstream that gets propagated to Debian).
...
I'd say it is the best solution when a package needs non-trivial architecture-specific porting for every architecture it supports.
With "non-trivial" I mean not just adding a new architecture to a few #ifdefs, but serious upstream porting efforts. E.g. valgrind does not
support riscv64, and if it would ever gain the support in a new upstream version I'd expect the maintainer to add that to the Architecture field
when upstream announces support for a new architecture.
But Architecture lists for expressing e.g. "64bit" or "little endian"
are a real pain for everyone working on bringup of a new port.
Which happens far more often than most people realize.
There is not only riscv64 (64bit, little endian).
Ports is about to start building for arc (32bit, little endian).
There are people working on ports like arm64be (64bit, big endian), loongarch64 (64bit, little endian) and many other ports that might
never end up being built in the Debian infrastructure (but some of
them might get built by derivatives).
Architecture lists containing all 64bit ports or all little endian
ports create much extra work for anyone adding support for a new 64bit
little endian architecture.
Samuel
cu
Adrian
The problem is that if you want to exclude an arch explicitly, you have to list all archs you want to build it on. IOW, I'm missing an easy way to say "not on THIS architecture", somthing like "[!armel]"
There are a few packages I take care of which make trouble on some archs or simply do not make much sense to run on those low-end archs.
I was spending siginifant time in the past weeks on such a package, to fix autopkgtests issues specific to that arch -- unsuccessfully, I disabled the tests in the end --,
Hello,
Tobias Frost, le lun. 12 sept. 2022 16:08:08 +0200, a ecrit:
The problem is that if you want to exclude an arch explicitly, you have to list all archs you want to build it on. IOW, I'm missing an easy way to say
"not on THIS architecture", somthing like "[!armel]"
Yes, but see below.
There are a few packages I take care of which make trouble on some archs or simply do not make much sense to run on those low-end archs.
If they make trouble, I would say just let the package FTBFS there.
I was spending siginifant time in the past weeks on such a package, to fix autopkgtests issues specific to that arch -- unsuccessfully, I disabled the tests in the end --,
Is it possible to get the same test be performed during package build
time? That way, it will be just not built, not shipped, and the state
will be clear on the buildd status page, and you can move on to more
useful work. For instance in my pocketsphinx package case:
On Mon, Sep 12, 2022 at 05:11:46PM +0200, Samuel Thibault wrote:
Tobias Frost, le lun. 12 sept. 2022 16:08:08 +0200, a ecrit:
The problem is that if you want to exclude an arch explicitly, you have to
list all archs you want to build it on. IOW, I'm missing an easy way to say
"not on THIS architecture", somthing like "[!armel]"
Yes, but see below.
There are a few packages I take care of which make trouble on some archs or
simply do not make much sense to run on those low-end archs.
If they make trouble, I would say just let the package FTBFS there.
Well, it compiles there… Of course I could fail it artifically, but that isn't something I would say it would be appropiate.
I was spending siginifant time in the past weeks on such a package, to fix
autopkgtests issues specific to that arch -- unsuccessfully, I disabled the
tests in the end --,
Is it possible to get the same test be performed during package build
time? That way, it will be just not built, not shipped, and the state
will be clear on the buildd status page, and you can move on to more
useful work. For instance in my pocketsphinx package case:
Would do that if it would be possible; The tests won't run properly without the
data installed properly.
...
The problem is that if you want to exclude an arch explicitly, you have to list all archs you want to build it on. IOW, I'm missing an easy way to say "not on THIS architecture", somthing like "[!armel]"
...
I don't actually believe people are using them on that arch, because if they would, I would get bug reports about them… Upstream agrees with that: Although
off-topic, I would be eager to know if there is anybody using $PACKAGE on an s390/System Z?"
The issue we see is that some DDs end up setting a hardcoded list in
the "Architecture" field, rather than just letting builds keep failing
on these archs (and then possibly succeeding after some time whenever somebody contributes a fix upstream that gets propagated to Debian).
That said, I guess DDs would still set a manual Arch list so as to get
the red flags away from their sight on the buildd page status, e.g. from https://buildd.debian.org/status/package.php?p=sthibault%40debian.org&comaint=yes&compact=compact
so that they can easily notice which build failures are actually not expected, to be able to efficiently work on those.
So perhaps what is missing is a way to express that an FTBFS is
expected, so that the buildd page status represents it differently, e.g.
in orange rather than red? The idea would be that it should be really
easy to set (as easy as setting an Architecture list) so that we can
easily recommend it.
We could for instance:
- Add an Architecture-FTBFS field to debian/control
- Add an environment variable to debian/rules so that on these archs dh
fails with a different exit code that buildds would notice.
- Add a Architecture-FTBFS field in the wb database that DDs can set
The tricky part I see is that AIUI the buildd status page doesn't
have direct access to debian/control, only to the wb database, so the
first solution is not immediate to implement. The third option would
be the most obvious from the buildd point of view, but that's not very convenient for DDs. Possibly such field could be automatically set
according to the Packages entry when a newer upload is done?
Something else to consider is that, for packages that make sense
porting, deny-listing them from building means we do not have build
failure logs, so deciding what to port or trying to check for patterns becomes more costly for humans,
of course at the cost of potentially throwing at it buildd resources.
we already had something similar with the Packages-arch-specific file,
but my understanding is that we are moving away from it?
...
[ Mostly to summarize the status re dpkg. ]
...
* Lack of bits/endianness arch "aliases" (#962848). The main problem
with this one is that we cannot simply add such aliases, as then
those would silently be considered as regular arches, and they do
not map into the current naming convention at all. These would need
to be added with a breaking syntax (say with some non-accepted
char, such as % or whatever) so that they do not introduce silent
breakage. This would then need to be supported by anything
handling arch restrictions (field and dependencies) which can be a
rather large surface. Then there is the problem that architectures
are evaluated as ORed lists, and the bits/endianness might require
to be treated as ANDed lists some times (of course the latter
could be handled by combining them into single aliases, but meh).
Thanks,
Guillem
If we limit the problem to avoiding build failures in cases that
upstream does not support, there would be the trivial solution of
having a package ship Provides like:
- architecture-is-64bit
- architecture-is-32bit
- architecture-is-little-endian
- architecture-is-big-endian
- architecture-has-64bit-timet
-...
Build-Depends: architecture-is-64bit, architecture-is-little-endian,... would be a package that only supports 64bit little endian architectures,
and that would never be attempted to build on 32bit or big endian architectures.
The buildd page would then show for i386:
mypackage build-depends on missing:
- architecture-is-64bit
Not building a source package on one specific architecture could already today be achieved with:
Build-Depends: package-is-broken-on-ppc64el [ppc64el],...
This might not be the most elegant solution, but it should be sufficient
to solve the problem in this thread and it does not require any tool
changes.
If we limit the problem to avoiding build failures in cases that
upstream does not support, there would be the trivial solution of
having a package ship Provides like:
- architecture-is-64bit
- architecture-is-32bit
- architecture-is-little-endian
- architecture-is-big-endian
- architecture-has-64bit-timet
Build-Depends: architecture-is-64bit, architecture-is-little-endian,... would be a package that only supports 64bit little endian architectures,
and that would never be attempted to build on 32bit or big endian architectures.
The buildd page would then show for i386:
mypackage build-depends on missing:
- architecture-is-64bit
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:03:22 |
| Calls: | 10,391 |
| Calls today: | 2 |
| Files: | 14,064 |
| Messages: | 6,417,105 |