Dear maintainer(s),

With a recent upload of zint the autopkgtest of zbar fails in testing
when that autopkgtest is run with the binary packages of zint from
unstable. It passes when run with only packages from testing. In tabular
form:

                       pass            fail
zint                   from testing    2.10.0-1
zbar                   from testing    0.23.92-3
all others             from testing    from testing

I copied some of the output at the bottom of this report. As there isn't
much output in the log, I can't really see what's going wrong.

Currently this regression is blocking the migration of zint to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=zint

https://ci.debian.net/data/autopkgtest/testing/amd64/z/zbar/15624264/log.gz

autopkgtest [00:22:52]: test command3: echo "test" | zint --direct
--filetype=SVG -i - | zbarimg -
autopkgtest [00:22:52]: test command3: [-----------------------
ERROR: unable to open file
`/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or
directory @ error/constitute.c/ReadImage/614
autopkgtest [00:22:53]: test command3: -----------------------]

I think I've partially identified what is happening.

It turns out that the version of zint in testing, despite being passed
the --filetype=SVG flag, actually produces a PNG, which in the past has
been happily processed by zbar.

This bug in zint seems to have been fixed in the new version, so that
specifying --filetype=SVG actually produces an SVG now. And it appears
that the error is coming from zbarimg, which as a matter of fact gives
the same error in a minimal chroot trying to process any SVG.

Outside a minimal chroot, on my desktop system, zbarimg seems to
process SVGs just fine. So this may be a case of a Recommends
(somewhere) not being installed wreaking havok, but in my opinion
zbarimg should still not behave this way when a Recommends is missing.

I'll debug this more later, but for now I'm reassigning the bug to
zbar-tools, since I see this is not an issue in zint.

installed, then this cryptic error occurs. I've reported this issue
(the lack of a helpful error message) at
https://github.com/mchehab/zbar/issues/202 .

I'll leave it to the maintainer to decide what they'd like to do:
either hardcode a dependency on libmagickcore-6.q16-6-extra, or switch
zint's output format to PNG (I personally would prefer the latter).

Control: severity -1 important

I have set the bug forwarding address to
https://github.com/mchehab/zbar/issues/202 . Besides, the new zbar/0.23.92-4
upload has switched zint's output format to PNG. Downgrading severity to
important since this issue is not RC-buggy now.

Thanks,
Boyuan Yang