Hi Paul,
Thank you once again for taking the time to reply :-)
Paul Gevers <elbrus@debian.org> writes:
> On 02-04-2022 00:13, Nicholas D Steeves wrote:
>>> On 24-02-2022 06:13, Nicholas D Steeves wrote:
[snip]
>> It's been a few months since I contacted the CI Team about
>> isolation-machines, but they're not yet ready for use either.
>
> That's still correct, and I don't expect that to change in the short
> term. We're more focused on adding other architectures to enable the
> Release Team to test all release architectures and maintaining the
> infrastructure as-is. That's already more work that I'd expected upfront.
>
That makes sense and is totally understandable. Someday some KVM and/or
possibly QEMU (foreign arch emulated) isolation machines would be really
nice.
[snip]
>> I completely understand, and the only way this request would be
>> justifiable is if it provided a meaningful boost in quality assurance
>> for audio-related packages.
>
> I'm wondering if this warrants a new autopkgtest restrictions (probably
> not): isolation-machine-or-needs-${group-of-defined-kernel-modules}. I
> have the feeling that could become a big list for all kind of use cases.
>
Agreed, and yeah, that maintaining that list doesn't seem like a good
use of time.
>> When I contacted upstream, I learned that the cause may be that the CLI
>> utilities are poorly maintained. Is this sufficient justification for
>> disabling the autopkgtests ie: that it's due diligence and not laziness?
>
> Well, if a test is truly flaky for whatever reason, ci.d.n and the
> Release Team agree that the test should either not be run or marked as
> flaky. The latter only has value if some human still regularly checks.
> The same goes for failure on a particular architecture. If you believe
> the failure is due to CI and not because the package itself is wrong,
> then just don't test there (Architecture field in d/t/control). If the
> package is broken and can't reasonably be fixed, have it removed from
> that architecture (in unstable; ftp.debian.org pseudo package) and don't
> build on that architecture anymore. In that case CI found out that the
> package is broken and that's a good thing.
>
Oh! I hadn't considered the option of dropping an architecture. Thank
you, I'll consider this option in the future :-)
>> Thank you again for having this conversation. I want to support our CI
>> team and technical excellence rather than just "unblock migration to
>> testing", but will of course defer to your recommendations.
>
> Sometimes you need to (for the time being) take a practical stance. I'm
> not saying yet that we'll not enable the snd-dummy module (I hope for
> follow-up), but in the present case, if the test can't reliably run on
> the present infrastructure, and nobody is promising a solution on the
> short term, you should not make your own live too hard and you should
> not run the tests for now. Or prepare for the isolation-machine
> situation (I think Ubuntu has that on most architectures) and hope it
> will arrive someday in Debian too.
>
Please add me to CC in the follow-up from the CI Team, wherever that
discussion is occurring :-)
It took a while, but upstream was able to identify arm64-specific bugs
(it's fortuitous that the new Apple computers use this arch); I verified that
the fix worked with an upload of a snapshot of their development branch
to our experimental suite, then asked for a backport to the 1.1.x
branch. Given that the release team appears to have prioritised removal
of this package, I am going to upload a development snapshot of this
1.1.x branch momentarily, even though it doesn't include any
documentation. At least it resolves this bug!
Regards,
Nicholas
Attachment:
signature.asc
Description: PGP signature