Re: Mass bugs filing: autopkgtest should be marked superficial (new list)

[Antonio Terceiro]

On Sun, Sep 20, 2020 at 12:31:13AM +0100, Sudip Mukherjee wrote:
> HI Mattia,
> 
> On Sat, Sep 19, 2020 at 8:58 PM Mattia Rizzolo  wrote:
> >
> > On Sat, Sep 19, 2020 at 08:39:44PM +0100, Sudip Mukherjee wrote:
> > > After discussing with few people, I now intend to file them with
> > > "severity: important" and I will also reduce the severity of the
> > > previously open similar bugs to 'important'.
> >
> > That's good.
> >
> > But please also share your proposed text with this list (as the MBF
> > rules asks for).  Your past filings where IMHO written with a tone that
> > could be improved.  Also I would like to make sure that you include
> > stuff like your plans with the severity, references to the release team
> > decisions, etc.
> 
> Apologies for the tone. It was my first MBF and I was struggling to
> make the text more generalised so that it will work for all the
> packages in the list.
> For this new list of packages, how is the following text:
> 
> **
> 
> Subject: : autopkgtest must be marked superficial
> severity: important
> 
> Dear maintainer,
> 
> It has been noticed that the autpkgtest in  is running a
> trivial command.
>  - 
> 
> Those kind of tests are considered to not provide significant coverage
> for a package as a whole, and as such the keyword "Restrictions:
> superficial" has been defined [1]. Packages with all tests marked as
> 'superficial' are not considered for the reduced migration age from
> unstable to testing and also they will not be allowed to migrate in a
> later stage of the freeze [2].
>
> The Release Team has listed this issue in the list of Release Critical
> Issues for bullseye [3] and has mentioned that the test must be marked
> superficial if it is not testing one of its own installed binary
> packages in some way.
> 
> 
> [1]. 
> https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst
> [2]. https://release.debian.org/bullseye/freeze_policy.html
> [3]. https://release.debian.org/bullseye/rc_policy.txt

Maybe you could include something like this (the wording can be improved):

  Note, however, that such superficial tests are still somewhat useful,
  as they will be considered, for example, to block dependencies from
  breaking your package. In other words, please do not react to this bug
  report by dropping tests from your package completely. More extensive
  testing is of course better, but even superficial tests are better for
  the overal quality of Debian than no tests at all.

We want to avoid maintainers panicking and just dropping the tests as a
response do this MBF.


signature.asc
Description: PGP signature

Re: Mass bugs filing: autopkgtest should be marked superficial (new list)

[Simon McVittie]

On Mon, 21 Sep 2020 at 09:09:51 -0300, Antonio Terceiro wrote:
> Maybe you could include something like this (the wording can be improved):
> 
>   Note, however, that such superficial tests are still somewhat useful,
>   as they will be considered, for example, to block dependencies from
>   breaking your package. In other words, please do not react to this bug
>   report by dropping tests from your package completely. More extensive
>   testing is of course better, but even superficial tests are better for
>   the overal quality of Debian than no tests at all.

Perhaps a more positive way to phrase the bug report would be to lead with
this, and then go on to say why these tests should be marked superficial?
That will hopefully reduce the tendency for maintainers to remove tests in
response.

It's also really useful for the template that is discussed on -devel to
mention the usertags that are going to be used (if any), so that it's
easy to search for them in a machine-readable way. It looks as though
the bugs that have already been filed are usertagged to appear in

so let's go with that.

In cases like this where the change is so trivial to make and so similar
across multiple packages, it's probably also useful to link to examples
of a maintainer making this change correctly, like [3] and [4] below.

Maybe something like this (I'm making some assumptions here about what the
release team does and doesn't encourage, so don't actually use this wording
until someone from the RT has acknowledged it):

8<
Subject: : autopkgtest must be marked superficial

Severity: important
User: sudipm.mukher...@gmail.com
Usertags: superficialtest

It has been noticed that the autopkgtest in  is running a
trivial command that does not provide significant test coverage:

 - 

These superficial tests are a useful way to detect regressions in
dependencies and prevent them from breaking your package, and the
Release Team encourages their inclusion in packages that do not have
a more thorough test suite available.

However, it is important that we are realistic about the level of
test coverage provided by these commands: most regressions cannot be
detected in this way, so it is not appropriate for packages that only
have superficial tests to migrate to the testing distribution with less
opportunity for testing by users than if these tests had not been present.

To support this, the keyword "Restrictions: superficial" has been
defined [1]. Packages where all tests are marked with this keyword are not
considered for the reduced migration age from unstable to testing, and
will not be allowed to migrate automatically in later stages of the
freeze [2].

Please mark all superficial autopkgtests with this keyword, similar to
[3] or [4].

The Release Team has listed this issue in the list of Release Critical
Issues for bullseye [5] and has mentioned that the test must be marked
superficial if it is not testing one of its own installed binary
packages in some way. As a result, the severity of this bug report might
be increased to serious in future.

[1] 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst#defined-restrictions
[2] https://release.debian.org/bullseye/freeze_policy.html
[3] 
https://salsa.debian.org/utopia-team/dbus/-/commit/a80908df7d119b181eec5eb0542634a30c2ad468
[4] 
https://salsa.debian.org/apparmor-team/apparmor/-/commit/580667513a097088ebe579884b38ac8d8666d3b3
[5] https://release.debian.org/bullseye/rc_policy.txt
8<

Regards,
smcv

Re: Mass bugs filing: autopkgtest should be marked superficial (new list)

[Sudip Mukherjee]

On Mon, Sep 21, 2020 at 2:53 PM Simon McVittie  wrote:
>
> On Mon, 21 Sep 2020 at 09:09:51 -0300, Antonio Terceiro wrote:
> > Maybe you could include something like this (the wording can be improved):
> >
> >   Note, however, that such superficial tests are still somewhat useful,
> >   as they will be considered, for example, to block dependencies from
> >   breaking your package. In other words, please do not react to this bug
> >   report by dropping tests from your package completely. More extensive
> >   testing is of course better, but even superficial tests are better for
> >   the overal quality of Debian than no tests at all.
>
> Perhaps a more positive way to phrase the bug report would be to lead with
> this, and then go on to say why these tests should be marked superficial?
> That will hopefully reduce the tendency for maintainers to remove tests in
> response.
>
> It's also really useful for the template that is discussed on -devel to
> mention the usertags that are going to be used (if any), so that it's
> easy to search for them in a machine-readable way. It looks as though
> the bugs that have already been filed are usertagged to appear in
> 
> so let's go with that.

Those were from the first list and there was another MBF mail to debian-devel.

>
> In cases like this where the change is so trivial to make and so similar
> across multiple packages, it's probably also useful to link to examples
> of a maintainer making this change correctly, like [3] and [4] below.
>
> Maybe something like this (I'm making some assumptions here about what the
> release team does and doesn't encourage, so don't actually use this wording
> until someone from the RT has acknowledged it):

I was drafting something like the following:
*

Subject: : autopkgtest must be marked superficial

Dear Maintainer,

Your package has an autopkgtest and its executing the following command:
-  

Since executing that command is considered to be a trivial test, that
which does not provide significant coverage for a package as a whole.
All trivial tests must be marked with "Restrictions: superficial" as
defined in [1].

A package with a non-trivial autopkgtest will enjoy a reduced
migration age from unstable to testing, and also it will be allowed to
migrate in a later stage of the freeze [2].

A package having a trivial (superficial) test will not get the
migration advantage but it will have the advantage of blocking
dependencies from breaking your package.

Its always better to have more extensive testing than having
superficial testing, which again is better than having no test.

Please consider i) Adding a non-trivial test, and/or ii) Mark the
trivial test with "Restrictions: superficial".


[1]. 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst
[2]. https://release.debian.org/bullseye/freeze_policy.html


*

But yours is much better than what I drafted.


-- 
Regards
Sudip

Build failure on mips64el

[Fabian Wolff]

Hi,

today, I uploaded a new version of the z3 package, but the build
failed on mips64el with an interesting error message [0]:

  [ 56%] Building CXX object 
src/tactic/arith/CMakeFiles/arith_tactics.dir/fm_tactic.cpp.o
  [...]
  In file included from /<>/src/util/rational.h:21,
   from /<>/src/ast/ast.h:26,
   from /<>/src/tactic/goal.h:30,
   from /<>/src/tactic/tactic.h:23,
   from /<>/src/tactic/tactical.h:21,
   from /<>/src/tactic/arith/fm_tactic.cpp:25:
  /<>/src/util/mpq.h: In member function ‘void 
mpq_manager::add(const mpz&, const mpz&, mpz&)’:
  /<>/src/util/mpq.h:231:53: internal compiler error: Segmentation 
fault
231 | void add(mpz const & a, mpz const & b, mpz & c) { 
mpz_manager::add(a, b, c); }
| ^
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.
  [...]
  The bug is not reproducible, so it is likely a hardware or OS problem.


How should I proceed here, given that mips64el is a release
architecture? I don't have a mips64el machine available (and also
don't have the time right now to play around with QEMU), and the log
even says that the issue is not reproducible. Should I just request a
give-back and hope for the best? I would appreciate some advice.

Thanks!
Fabian

[0] 
https://buildd.debian.org/status/fetch.php?pkg=z3&arch=mips64el&ver=4.8.9-1&stamp=1600698127&raw=0

Re: Build failure on mips64el

[Fabian Wolff]

The problem has been solved by a give-back. Thanks to Tobias Frost for
his help!

On 9/21/20 5:09 PM, Fabian Wolff wrote:
> Hi,
> 
> today, I uploaded a new version of the z3 package, but the build
> failed on mips64el with an interesting error message [0]:
> 
>   [ 56%] Building CXX object 
> src/tactic/arith/CMakeFiles/arith_tactics.dir/fm_tactic.cpp.o
>   [...]
>   In file included from /<>/src/util/rational.h:21,
>from /<>/src/ast/ast.h:26,
>from /<>/src/tactic/goal.h:30,
>from /<>/src/tactic/tactic.h:23,
>from /<>/src/tactic/tactical.h:21,
>from /<>/src/tactic/arith/fm_tactic.cpp:25:
>   /<>/src/util/mpq.h: In member function ‘void 
> mpq_manager::add(const mpz&, const mpz&, mpz&)’:
>   /<>/src/util/mpq.h:231:53: internal compiler error: 
> Segmentation fault
> 231 | void add(mpz const & a, mpz const & b, mpz & c) { 
> mpz_manager::add(a, b, c); }
> | ^
>   Please submit a full bug report,
>   with preprocessed source if appropriate.
>   See  for instructions.
>   [...]
>   The bug is not reproducible, so it is likely a hardware or OS problem.
> 
> 
> How should I proceed here, given that mips64el is a release
> architecture? I don't have a mips64el machine available (and also
> don't have the time right now to play around with QEMU), and the log
> even says that the issue is not reproducible. Should I just request a
> give-back and hope for the best? I would appreciate some advice.
> 
> Thanks!
> Fabian
> 
> [0] 
> https://buildd.debian.org/status/fetch.php?pkg=z3&arch=mips64el&ver=4.8.9-1&stamp=1600698127&raw=0
> 

Bug#970705: ITP: go-dbus-factory -- go binding code for automatically generating DBus services

[stan clay]

Package: wnpp
Severity: wishlist
Owner: clay stan 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: go-dbus-factory
  Version : 1.8.0.22
  Upstream Author : LinuxDeepin
* URL : https://github.com/linuxdeepin/go-dbus-factory
  License : GPL-3+
  Programming Lang: Golang
  Description : go binding code for automatically generating DBus services

Convenient go binding code for automatically generating DBus services.

This package is a part of DDE (Deepin Desktop Environment).

Bug#970706: ITP: dde-api --

[stan clay]

Package: wnpp
Severity: wishlist
Owner: clay stan 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: dde-api
  Version : 5.3.0.11
  Upstream Author : LinuxDeepin
* URL : https://github.com/linuxdeepin/dde-api
  License : GPL-3+
  Programming Lang: Golang
  Description : Go-lang bingdings for dde-daemon

DDE API provides some dbus interfaces that is used for screen zone
detecting, thumbnail generating, sound playing, etc.

This package is a part of DDE (Deepin Desktop Environment).