Hi Paul, Debian CI team, and Denis, Paul and Debian CI team, do you know if a dummy alsa driver (and dummy sequencer driver) can be enabled on DebCI systems? 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. Paul Gevers <elbrus@debian.org> writes: > Source: hydrogen > Version: 1.1.1-1 > X-Debbugs-CC: debian-ci@lists.debian.org > Severity: serious > User: debian-ci@lists.debian.org > Usertags: regression > > Dear maintainer(s), > > With a recent upload of hydrogen the autopkgtest of hydrogen fails in > testing when that autopkgtest is run with the binary packages of > hydrogen from unstable on arm64 and ppc64el. It passes when run with > only packages from testing. In tabular form: > > pass fail > hydrogen from testing 1.1.1-1 > all others from testing from testing > > I copied some of the output at the bottom of this report. I note that on > amd64 the test also failed for a couple of days due to a segfault before > it passed yesterday. I suspect you're missing a *versioned* dependency > which migrated to testing apparently somewhere yesterday. > 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. 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 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. 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. Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature