[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#980088: marked as done (britney adds reference link for removed packages)

Your message dated Sun, 16 Jun 2024 16:46:37 +0200
with message-id <141a85f2-0764-4b89-9231-6c71fed228d1@debian.org>
and subject line Re: silxs autopkgtest
has caused the Debian Bug report #980088,
regarding britney adds reference link for removed packages
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
980088: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980088
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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


--- End Message ---
--- Begin Message --- 
Hi,

On Thu, 14 Jan 2021 11:53:31 +0100 Paul Gevers <elbrus@debian.org> wrote:

> 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.


I believe this has been fix earlier this year (or somewhere last year).

Paul

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


--- End Message ---
Reply to: