New version of java-common breaks autopkgtest of octave-io in testing

[Paul Gevers]

Dear maintainers,

As recently announced¹ Debian is now running autopkgtests in testing to
check if migration of a new source package causes regressions. It does
this with the binary packages of the new version of a source package
from unstable.

With the upload of version 0.65 of java-common the autopkgtest of
octave-io started to fail in testing². This is currently delaying the
migration of java-common version 0.65³.

This e-mail is meant to trigger direct communication between the
maintainers of the involved packages as one party has insight in what
changed and the other party insight in what is being tested. After all,
a regression in a reverse dependency can come due to one of the
following reasons (of course not complete):
* new bug in the candidate package (fix the package)
* bug in the test case that only gets triggered due to the update (fix
  the reverse dependency, but see below)
* out-of-date reference date in the test case that captures a former bug
  in the candidate package (fix the reverse dependency, but see below)
* deprecation of functionality that is used in the reverse dependency
  and/or its test case (discussion needed)

Unfortunately sometimes a regression is only intermittent. Ideally this
should be fixed, but it may be OK to just have the autopkgtest retried
(a link is available in the excuses³).

There are cases where it is required to have multiple packages migrate
together to have the test cases pass, e.g. when there was a bug in a
regressing test case of a reverse dependency and that got fixed. In that
case the test cases need to be triggered with both packages from
unstable (reply to this e-mail and/or contact the ci-team⁴) or just wait
until the aging time is over (if the fixed reverse dependency migrates
before that time, the failed test can be retriggered³).

Of course no system is perfect. In case a framework issue is suspected,
don't hesitate to raise the issue via bts or to the ci-team⁴ (reply to
me is also fine for initial cross-check).

To avoid stepping on peoples toes, this e-mail is not automatically
generating a bug in the bts, but it is highly recommended to forward
this e-mail there (psuedo-header boilerplate below⁵⁶) in case it is
clear which package should solve this regression.

Paul
PS: comments on the text of this e-mail are highly appreciated

¹ https://lists.debian.org/debian-devel-announce/2018/05/msg00001.html
² https://ci.debian.net/packages/o/octave-io/testing/amd64/
³ https://qa.debian.org/excuses.php?package=java-common
⁴ #debci on oftc or debian-ci at lists.debian.org
⁵ java-common has an issue
============
Source: java-common
Version: 0.65
Severity: normal or higher
Control: affects -1 src:octave-io
User: debian-ci at lists.debian.org
Usertags: breaks
============
⁶ octave-io has an issue
============
Source: octave-io
Version: 2.4.10-3
Severity: normal or higher
Control: affects -1 src:java-common
User: debian-ci at lists.debian.org
Usertags: needs-update
============

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20180506/cf92c345/attachment.sig>