Bug#856334: libdevice-cdio-perl: FTBFS when autobuilder has a CDROM drive

gregor herrmann gregoa at debian.org
Tue Feb 28 20:23:52 UTC 2017


On Tue, 28 Feb 2017 01:05:26 +0100, Santiago Vila wrote:

> I tried to build this package in stretch with "dpkg-buildpackage -B"
> but it failed:
> 
> --------------------------------------------------------------------------------
> [...]
> 
> Test Summary Report
> -------------------
> t/05.ops.t         (Wstat: 11 Tests: 0 Failed: 0)
>   Non-zero wait status: 11
>   Parse errors: Bad plan.  You planned 6 tests but ran 0.
> t/11.dev.t         (Wstat: 11 Tests: 1 Failed: 0)
>   Non-zero wait status: 11
>   Parse errors: No plan found in TAP output
> Files=15, Tests=93,  2 wallclock secs ( 0.09 usr  0.05 sys +  1.27 cusr  0.24 csys =  1.65 CPU)
> Result: FAIL
> Failed 2/15 test programs. 0/93 subtests failed.
> dh_auto_test: perl Build test --verbose 1 returned exit code 255
> debian/rules:27: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 255
> make[1]: Leaving directory '/<<PKGBUILDDIR>>'
> debian/rules:4: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
> --------------------------------------------------------------------------------
> 
> [ This is just how the build ends ]
> 
> Apparently the build fails when (and only when) the machine has a CDROM
> (not that I'm sure about that, but it's the only explanation I found).
> 
> I attach two build logs, one which fails and another one which does not.

Thank you; interesting bug :)

There is something fishy going on, but it's not as simple as it looks
in the first place. What I can say so far is:

- The tests t/05.ops.t and t/11.dev.t are skipped if /dev/cdrom
  doesn't exist (a Debian patch); that's what we see in your
  successful build and also when I build in my usual cowbuilder
  chroot.
- They are not skipped when /dev/cdrom exists, and here it gets
  interesting, since this fails in your other log, but the tests work
  for me if I ran a plain debuild on my laptop (which has a CD-ROM
  drive in the docking station):

For comparison:

1) Your log with the failure:

t/05.ops.t ...........
1..6
# Test running miscellaneous operations
Failed 6/6 subtests

t/11.dev.t ...........
# Test running audio device operations
ok 1 - Device::Cdio::Device->new(-driver_id=>$perlcdio::DRIVER_DEVICE)
# Device->new(DRIVER_DEVICE)((i.e.:13)) found: undef
All 1 subtests passed


2) My log in the "normal" environment:

t/05.ops.t ........... 
1..6
# Test running miscellaneous operations
ok 1 - Device::Cdio::get_devices
ok 2 - Device::Cdio::get_devices_with_cap(perlcdio::FS_MATCH_ALL)
ok 3 - Device::Cdio::Device->new()
ok 4 - Device::Cdio::Device::open
ok 5 - Device::Cdio::Device::have_ATAPI
ok 6 - Device::Cdio::Device::get_media_changed
ok

t/11.dev.t ........... 
# Test running audio device operations
ok 1 - Device::Cdio::Device->new(-driver_id=>$perlcdio::DRIVER_DEVICE)
# Device->new(DRIVER_DEVICE)((i.e.:13)) found: /dev/cdrom
ok 2 - Device::Cdio::Device->get_hwinfo
# Testing /dev/cdrom MATSHITA DVD-RAM UJ8A2   
ok 3 - Device::Cdio::Device->audio_get_volume
# Volume was set to 255, 255, 0, 0
ok 4 - audio_set_volume keep values
ok 5 - audio_set_volume 2 channels
# 4 channels are not supported: 100, 100, 0, 0
ok 6 - audio_set_volume reset
ok 7 # skip 4 volume channels are not supported
1..7
ok


My CD-ROM "looks" like:

% ll /dev/cdrom
lrwxrwxrwx 1 root root 3 Feb 16 19:06 /dev/cdrom -> sr0
% ll /dev/sr0  
brw-rw---- 1 root cdrom 11, 0 Feb 16 19:06 /dev/sr0


I guess something™ is different with the CD-ROM in your build
enviroment.


Oh, and during autokpkgtest we always skip the two tests:

% cat debian/tests/pkg-perl/smoke-skip 
# fail with QEMU's /dev/cdrom
t/05.ops.t
t/11.dev.t


So it seems that those tests have proven to be problematic under
other (virtual) versions of /dev/cdrom as well before, even if they
work with real hardware.

If this is true we probably want to disable the tests completely
during build as well ...


Cheers,
gregor


-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Leonard Cohen: Diamonds In The Mine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: Digital Signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20170228/2bb9aaa0/attachment.sig>


More information about the pkg-perl-maintainers mailing list