Hi Nicholas, Thanks for reaching out. On 24-02-2022 06:13, Nicholas D Steeves wrote:
Paul and Debian CI team, do you know if a dummy alsa driver (and dummy sequencer driver) can be enabled on DebCI systems?
You are in control of your testbed, can't you do this in your test? Or can you only do this in isolation-machine testbeds (not sure how this driver thing works)? And why would only arm64 need it?
This would make the testbed more comparable to a real system and increase the value of the tests for multimedia packages. If not, please feel free to skip to the bottom of this email.
To be honest, I don't really like tweaking the hosts, as other autopkgtest instances outside our control would need to learn to do this too.
When I run autopkgtests locally they now error due to missing audio hardware where previously they passed, and this wasn't the case when the package was uploaded.
The test on ppc64el now passed after several failure due to segmentation faults. Not sure if this is now a highly flaky test, or just that the issue has been fixed in the mean time on ppc64el
It looks to me like "allow-stderr" is no longer sufficient to allow the export-to-wav functional test to pass, eg: (E) JackAudioDriver::init Unknown status with JACK server. (E) ::H2Core::AudioOutput* H2Core::createDriver(const QString&) Error starting audio driver [audioDriver::init()] (E) AlsaAudioDriver::connect ALSA: cannot open audio device hw:0:No such file or directory (E) AlsaAudioDriver::connect ALSA: cannot open audio device default:No such file or directory (E) ::void H2Core::audioEngine_startAudioDrivers() Error starting audio driver [audioDriver::connect()] (E) ::void H2Core::audioEngine_startAudioDrivers() Using the NULL output audio driver (E) ::void* H2Core::alsaMidiDriver_thread(void*) Error opening ALSA sequencer: No such file or directory
But this text is also there on passing tests. So either that's no problem, or the test doesn't fail while it should.
The available solutions appear to be 1) Enable a dummy sound card. 2) Ask upstream to support running utility functions such as this wav file export without attempting to bind to hardware. 3) Remove the autopkgtest. 4) Something else.
Again, why only arm64?
My first instinct is to choose option #3, because it doesn't depend on other people; however, obviously we all value CI and want to work towards enhancing its value rather than removing tests. So that leaves options #1, #2, and #4 (yet undefined). I guess there's always "foo || true", but I hope everyone reading this will agree that that is bad style that reduces the value of CI. I would prefer option #1, because it increases the real-world value of these tests, and because I don't know how to justify #2 to upstream.
Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature