[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1005912: hydrogen: autopkgtest regression on arm64 and ppc64el: H2Core::Instrument::dequeue(): Assertion `__queued > 0' failed.

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.


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply to: