Handling autopkgtests for arch-all packages uninstallable on some archs

[Julian Gilbey]

Hi!

I'm a little bemused about how to handle the spyder suite of packages.

spyder (via the python3-spyder binary and Build-Depends) depends on
python3-pyqt5.qtwebengine, which is (according to rmadison) only
present on amd64, armhf, i386, mips64el. ci.debian.net now only
attempts to run the spyder autopkgtests on amd64, arm64, armhf and
i386, and it passes on all these. It doesn't even say "No tests..."
for the other archs, and I don't know how ci.debian.net learnt to
ignore the other archs.

But the two (source) packages spyder-line-profiler and
spyder-unittests depend on python3-spyder and so are only installable
on that same handful of archs. However, ci.debian.net attempts to run
the autopkgtests on all 8 archs, and so four of them fail due to
uninstallable dependencies. I could mark the autopkgtests as only
running on those four archs. Is that the best thing to do, or is
there some way to indicate to ci.debian.net that the package is not
installable on some archs and so it should not try to test the package
on them?

Best wishes,

Julian

[Paul Gevers]

Hi,

Post by Julian Gilbey
I could mark the autopkgtests as only
running on those four archs. Is that the best thing to do, or is
there some way to indicate to ci.debian.net that the package is not
installable on some archs and so it should not try to test the package
on them?

ci.d.n just runs what's requested by users of the API or self-service
and doesn't know anything about packages. It's our migration software
that knows for sources that only build arch specific binaries that
there's nothing to run, but arch:all binaries are available anywhere, so
it errs on the greedy side.

That being said, how we normally deal with these things if we're made
aware of them is to hint-ignore the problem on those architectures for
the migration to testing, as the problem is automatically ignored from
that moment on. Because it is a PITA to maintain those kind of lists in
sync with the archive. Imagine spyder being build on an architecture
where it's not available yet, you'd need to update all those lists.

I'll add the hints shortly.

Paul

[Julian Gilbey]

Hi,

Post by Julian Gilbey
I could mark the autopkgtests as only
running on those four archs. Is that the best thing to do, or is
there some way to indicate to ci.debian.net that the package is not
installable on some archs and so it should not try to test the package
on them?

ci.d.n just runs what's requested by users of the API or self-service and
doesn't know anything about packages. It's our migration software that knows
for sources that only build arch specific binaries that there's nothing to
run, but arch:all binaries are available anywhere, so it errs on the greedy
side.
That being said, how we normally deal with these things if we're made aware
of them is to hint-ignore the problem on those architectures for the
migration to testing, as the problem is automatically ignored from that
moment on. Because it is a PITA to maintain those kind of lists in sync with
the archive. Imagine spyder being build on an architecture where it's not
available yet, you'd need to update all those lists.
I'll add the hints shortly.
Paul

Thanks Paul, much appreciated! Is this the best way to let you know
about such cases in future?

Best wishes,

Julian

[Paul Gevers]

Hi,

Post by Julian Gilbey
Is this the best way to let you know
about such cases in future?

This, a bug report against the release.debian.org pseudo package or a
note on IRC (#d-release). A bug report is the best way to not get lost,
but you probably will not wait so long anyways, so (potentially multiple
in case they happen to be read away from ssh key) messages with context
on IRC are probably the fastest and most efficient way.

Paul