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

Regularly, bug reports are sent out to trigger prompt 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. Please therefore get in touch with each other with your ideas about what the causes of the problem might be, proposed patches, etc. A regression in a reverse dependency can be due to one of the following reasons (of course not complete):

Triaging tips are being collected on ContinuousIntegration/TriagingTips.

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 the automatic e-mail and/or contact the ci-team (1)) 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 (1).

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

It can be appropriate to file an RC bug against the depended-on package, if the regression amounts to an RC bug in the depending package, and to keep it open while the matter is investigated. That will prevent migration of an RC regression.

If the maintainers of the depending package don't have available effort to fix a problem, it is appropriate for the maintainers of the depended-on package to consider an NMU of the depending package. Any such an NMU should take place in accordance with the normal NMU rules.

Neither of the above steps should be seen as hostile; they are part of trying to work together to keep Debian in tip-top shape.

If you find that you are not able to agree between you about the right next steps, bug severities, etc., please try to find a neutral third party to help you mediate and/or provide a third opinion. Failing that your best bet is probably to post to debian-devel.

(1) #debci on oftc or debian-ci@lists.debian.org

(2) $trigger has an issue

Source: $trigger
Version: $ver
Severity: normal or higher
Control: affects -1 src:$broken
User: debian-ci@lists.debian.org
Usertags: breaks

(3) $broken has an issue

Source: $broken
Version: $broken_ver
Severity: normal or higher
Control: affects -1 src:$trigger
User: debian-ci@lists.debian.org
Usertags: needs-update