Package: release. User: release.debian.org@package.debian.org Severity: minor Usertag: britney Control: retitle -1 britney adds reference link for removed packages Hi Frederic-Emmanuel On 14-01-2021 09:26, PICCA Frederic-Emmanuel wrote: > I try to understand something about autopkgtest and britney migration. Good that you reach out. However, the excuses are generated by the code under the responsibility of the Release Team, hence CC-ing (via the BTS). > If you look here, > > https://tracker.debian.org/pkg/silx > > the autopkgtest on ppc64el says, regression, but If I look here > > https://ci.debian.net/packages/s/silx/testing/ppc64el/ Even more interesting, if you click on the link to the log of the ppc64el reference log you'll find that it ends with command1 FAIL badpkg command2 FAIL badpkg > it failes from the begining, so to my opinion this is not a regression. We consider it a regression if the package is new in testing (it was removed) and the "new" test fails. We declared failing autopkgtests RC-buggy, so with the migration we would *add* an RC buggy package. I agree there is a bug, britney shouldn't show the "reference run" result. > for info this test faild because the pacakge does not build on ppc64el, du to the pyopencl dependency :). For new tests in source packages that build both arch:all and arch:any packages this situation unfortunately requires either specifying the Architectures in the d/t/control file, or overruling by the Release Team. You *can* add the (recently supported) Architecture field to your package, but Graham already overruled it for now anyways. > Is there something wrong or should I mark the test not for ppc64el ? The latter gives *you* control, so that's good. On the other hand, I can understand it when you don't want to remember to keep that in sync with which archs your package builds on. Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature