Bug#949299: coinor-vol misses source for configure
Control: owner -1 ! On Sun, Jan 19, 2020 at 04:26:25PM +0100, Helmut Grohne wrote: > Source: coinor-vol > Version: 1.5.4-1 > Severity: severity > Justification: missing source > > coinor-vol includes a configure script generated using autoconf. The > relevant configure.ac file is included in the source. In Debian, we > generally don't require that things are built from source during package > build, but we do require that everything can be rebuilt using components > from Debian main. Unfortunately, the configure script for coinor-vol > needs to be generated using autoconf2.59 and that version of autoconf > was removed from unstable more than one year ago. I also tried > rebuilding configure with different versions of autoconf without > success. As such, I conclude that coinor-vol lacks the required source > components for regenerating the configure script. Yes, source is still missing. As there was a SONAME version change, so the package name changed and had to go through the NEW queue. I am preparing another upload so that source can be uploaded with it. -- Regards Sudip
Bug#949299: coinor-vol misses source for configure
Looks like I misread the bug report and thought it to be the same as missing source for NEW upload. I will check about the source for the configure script. -- Regards Sudip
Bug#952404: scanbd: crash on startup: kernel internal error: Oops 206 with current raspbian buster on rpi4 4g
I tried it on a qemu image for aarch64 and could not reproduce the probem, and there was no error in dmesg. root@debian-arm64:/home/sudip# lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 10 (buster) Release:10 Codename: buster root@debian-arm64:/home/sudip# lscpu | grep Arch Architecture:aarch64 root@debian-arm64:/home/sudip# uname -r 4.19.0-8-arm64 root@debian-arm64:/home/sudip# export SANE_CONFIG_DIR=/etc/scanbd root@debian-arm64:/home/sudip# /usr/sbin/scanbd -f -c /etc/scanbd/scanbd.conf /usr/sbin/scanbd: dbus match type='signal',interface='org.freedesktop.Hal.Manager' /usr/sbin/scanbd: no devices, not starting any polling thread /usr/sbin/scanbd: Not Primary Owner (2) -- Regards Sudip
Bug#952404: scanbd: crash on startup: kernel internal error: Oops 206 with current raspbian buster on rpi4 4g
Thanks for testing and debugging it. Can you please send me your dmesg which shows the trace. -- Regards Sudip
Bug#777058: dbview: please make the build reproducible
On Tue, Sep 01, 2020 at 10:58:04PM -, Chris Lamb wrote: > Chris Lamb wrote: > > > [..] > > Friendly ping on this? This is an orphan package and anyone can make a QA upload. And can you please check again if it still has the problem? d/rules has been completely rewritten with 1.0.4-2 version and so the patch will not apply anymore. -- Regards Sudip
Bug#777410: freecdb: please make the build reproducible
On Tue, Sep 01, 2020 at 10:58:07PM -, Chris Lamb wrote: > Chris Lamb wrote: > > > [..] > > Friendly ping on this? This is an orphan package and anyone can make a QA upload. And can you please check again if it still has the problem? d/rules has been completely rewritten with 0.76 version and so the patch will not apply anymore. -- Regards Sudip
Bug#969795: 2vcard: autopkgtest should be marked superficial
Source: 2vcard Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of '2vcard' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of '2vcard'. -- Sudip
Bug#969797: altermime: autopkgtest should be marked superficial
Source: altermime Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'altermime' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'altermime'. -- Sudip
Bug#969808: cfourcc: autopkgtest should be marked superficial
Source: cfourcc Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'cfourcc' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'cfourcc'. -- Sudip
Bug#969812: cldump: autopkgtest should be marked superficial
Source: cldump Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'cldump' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'cldump'. -- Sudip
Bug#969811: changetrack: autopkgtest should be marked superficial
Source: changetrack Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'changetrack' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'changetrack'. -- Sudip
Bug#969817: diffmon: autopkgtest should be marked superficial
Source: diffmon Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'diffmon' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'diffmon'. -- Sudip
Bug#969821: dpatch: autopkgtest should be marked superficial
Source: dpatch Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'dpatch' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'dpatch'. -- Sudip
Bug#969822: dyndns: autopkgtest should be marked superficial
Source: dyndns Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'dyndns' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'dyndns'. -- Sudip
Bug#969826: flpsed: autopkgtest should be marked superficial
Source: flpsed Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'flpsed' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'flpsed'. -- Sudip
Bug#969828: fwlogwatch: autopkgtest should be marked superficial
Source: fwlogwatch Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'fwlogwatch' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'fwlogwatch'. -- Sudip
Bug#969832: gox: autopkgtest should be marked superficial
Source: gox Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'gox' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'gox'. -- Sudip
Bug#969842: mailcheck: autopkgtest should be marked superficial
Source: mailcheck Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'mailcheck' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'mailcheck'. -- Sudip
Bug#969843: makebootfat: autopkgtest should be marked superficial
Source: makebootfat Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'makebootfat' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'makebootfat'. -- Sudip
Bug#969840: lxmms2: autopkgtest should be marked superficial
Source: lxmms2 Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'lxmms2' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'lxmms2'. -- Sudip
Bug#969849: ncap: autopkgtest should be marked superficial
Source: ncap Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'ncap' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'ncap'. -- Sudip
Bug#969861: rdist: autopkgtest should be marked superficial
Source: rdist Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'rdist' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'rdist'. -- Sudip
Bug#969870: tcpspy: autopkgtest should be marked superficial
Source: tcpspy Severity: serious Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Hi, The test done in the autopkgtest of 'tcpspy' does not provide significant test coverage and it should be marked with "Restrictions: superficial". Ref: https://people.debian.org/~eriberto/README.package-tests.html Examples of tests which are not significant includes (its not a complete list): 1) Executing the binary to check version Test-Command: foo -v Test-Command: foo -V Test-Command: foo --version 2) Executing the binary to check help (foo -h) Test-Command: foo -h Test-Command: foo --help 3) checking for files installed with 'ls'. Test-Command: ls -l /usr/lib/*/foo.so 4) A Python or Perl library runs import foo or require Foo; but does not attempt to use the library beyond that. Test-Command: python3 -c "import foo" Please add "Restrictions: superficial" to 'debian/tests/control' of 'tcpspy'. -- Sudip
Bug#969822: Update to severity
Control: severity -1 important -- Hi, As discussed on debian-devel, I am reducing the severity to important. Ref: https://lists.debian.org/debian-devel/2020/09/msg00266.html -- Regards Sudip
Bug#970946: apngasm: autopkgtest must be marked superficial
Source: apngasm Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in apngasm is running a trivial command that does not provide significant test coverage: -Test-Command: apngasm | grep APNG Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970945: acorn-fdisk: autopkgtest must be marked superficial
Source: acorn-fdisk Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in acorn-fdisk is running a trivial command that does not provide significant test coverage: -Test-Command: acorn-fdisk --help | grep Usage -Test-Command: acorn-fdisk --version | grep arm-fdisk Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970947: bmf: autopkgtest must be marked superficial
Source: bmf Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in bmf is running a trivial command that does not provide significant test coverage: -Test-Command: bmf -V 2>&1 | grep version -Test-Command: bmf -h 2>&1 | grep Usage Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970948: copyright-update: autopkgtest must be marked superficial
Source: copyright-update Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in copyright-update is running a trivial command that does not provide significant test coverage: -Test-Command: copyright-update --help Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970955: herisvm: autopkgtest must be marked superficial
Source: herisvm Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in herisvm is running a trivial command that does not provide significant test coverage: -Test-Command: heri-eval -h 2>&1 | grep usage -Test-Command: heri-stat -h -Test-Command: heri-split -h Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970962: procinfo: autopkgtest must be marked superficial
Source: procinfo Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in procinfo is running a trivial command that does not provide significant test coverage: -Test-Command: procinfo -h -Test-Command: procinfo -v Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970957: mmorph: autopkgtest must be marked superficial
Source: mmorph Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in mmorph is running a trivial command that does not provide significant test coverage: -Test-Command: mmorph -h -Test-Command: mmorph -v Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970956: lockout: autopkgtest must be marked superficial
Source: lockout Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in lockout is running a trivial command that does not provide significant test coverage: -Test-Command: lockout | grep -i version Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970975: vlock: autopkgtest must be marked superficial
Source: vlock Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in vlock is running a trivial command that does not provide significant test coverage: -Test-Command: vlock -h -Test-Command: vlock -v Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970974: trueprint: autopkgtest must be marked superficial
Source: trueprint Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in trueprint is running a trivial command that does not provide significant test coverage: -Test-Command: trueprint -H -Test-Command: trueprint -V Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#970968: rdist: autopkgtest must be marked superficial
Source: rdist Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in rdist is running a trivial command that does not provide significant test coverage: -Test-Command: rdist -V Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#971498: python-mplexporter: autopkgtest must be marked superficial
Source: python-mplexporter Severity: important Usertags: superficialtest X-Debbugs-CC: elb...@debian.org Dear Maintainer, It has been noticed that the autopkgtest in python-mplexporter is running a trivial command that does not provide significant test coverage: - testcommand: import mplexporter Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#974445: antigrav: autopkgtest must be marked superficial
Source: antigrav X-Debbugs-CC: elb...@debian.org Severity: important Usertags: superficialtest Dear Maintainer, It has been noticed that the autopkgtest in antigrav is running a trivial command that does not provide significant test coverage: - xvfb-run -a /usr/games/antigrav & Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#974436: aewm: autopkgtest must be marked superficial
Source: aewm X-Debbugs-CC: elb...@debian.org Severity: important Usertags: superficialtest Dear Maintainer, It has been noticed that the autopkgtest in aewm is running a trivial command that does not provide significant test coverage: - xvfb-run -a aewm & Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#974457: iroffer: autopkgtest must be marked superficial
Source: iroffer X-Debbugs-CC: elb...@debian.org Severity: important Usertags: superficialtest Dear Maintainer, It has been noticed that the autopkgtest in iroffer is running a trivial command that does not provide significant test coverage: - iroffer -v Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#974486: gramofile: autopkgtest must be marked superficial
Source: gramofile X-Debbugs-CC: elb...@debian.org Severity: important Usertags: superficialtest Dear Maintainer, It has been noticed that the autopkgtest in gramofile is running a trivial command that does not provide significant test coverage: - xvfb-run -a gramofile & Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#974510: zope.exceptions: autopkgtest must be marked superficial
Source: zope.exceptions X-Debbugs-CC: elb...@debian.org Severity: important Usertags: superficialtest Dear Maintainer, It has been noticed that the autopkgtest in zope.exceptions is running a trivial command that does not provide significant test coverage: - import zope.exceptions; print(zope.exceptions) Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. 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 with only superficial tests to have the reduced migration time to migrate from unstable to testing as that means less opportunity for testing by users compared to the package with no tests. 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]. 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", 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 -- Regards Sudip
Bug#979965: milter-greylist exits after running for a few minutes
Hi Michael,
On Tue, Jan 12, 2021 at 5:54 PM Vagrant Cascadian wrote:
>
> On 2021-01-12, Michael Grant wrote:
> > After update to 4.6.2-2, milter-greylist runs for a few minutes
> > processing greylist requests then exits. No error in the daemon.log.
> > Daemon restarts with systemd over and over.
> >
> > Starting milter-greylist by hand using strace shows this just before
> > it dies:
> >
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 1 ([{fd=3,
> > revents=POLLIN}])
> > accept(3, {sa_family=AF_UNIX}, [2]) = 10
> > fcntl(10, F_GETFD) = 0
> > fcntl(10, F_SETFD, FD_CLOEXEC) = 0
> > setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> > futex(0x7f0f22c221a4, FUTEX_WAKE_PRIVATE, 1) = 1
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000 ) = ?
> > +++ exited with 71 +++
> >
> > Previous version of milter-greylist on debian/testing was working fine
> > without this issue.
>
> Could you try running without the systemd .service file so that it falls
> back to the init script; there may be differences between how the
> .service file and the init script set up the environment to run it.
Can you also modify /lib/systemd/system/milter-greylist.service and
change the [Service] section to the following and test please..
[Service]
Type=forking
ExecStart=/usr/sbin/milter-greylist
Restart=on-failure
PrivateTmp=true
--
Regards
Sudip
Bug#979965: milter-greylist exits after running for a few minutes
On Tue, Jan 12, 2021 at 9:36 PM Michael Grant wrote: > > I have made this change: > > > > [Service] > > Type=forking > > ExecStart=/usr/sbin/milter-greylist > > Restart=on-failure > > PrivateTmp=true > > > > And it’s still restarting every few minutes: > > > > Jan 12 16:09:43 strange milter-greylist[255358]: racl 277 greylist [delay > 300] [aw 3888000] [maxpeek -1] default > > Jan 12 16:09:43 strange systemd[1]: Started Greylist Mail Filter Daemon. > > Jan 12 16:30:43 strange systemd[1]: milter-greylist.service: Main process > exited, code=exited, status=71/OSERR > > Jan 12 16:30:43 strange systemd[1]: milter-greylist.service: Failed with > result 'exit-code'. > > Jan 12 16:30:44 strange systemd[1]: milter-greylist.service: Scheduled > restart job, restart counter is at 2. > > Jan 12 16:30:44 strange systemd[1]: Stopped Greylist Mail Filter Daemon. > > Jan 12 16:30:44 strange systemd[1]: Starting Greylist Mail Filter Daemon... > > > > I just noticed it says ‘Scheduled restart job’, is that because it exits? Or > is that because some timer is killing it? I think its restarting because the service file has "Restart=on-failure". and since the main process is exiting with error systemd thinks the service has failed and so it restarts. To reproduce the error, do I just run milter-greylist with a greylist.conf and Sendmail/Postfix or do I need to have real mails to see the issue? -- Regards Sudip
Bug#979965: milter-greylist exits after running for a few minutes
On Tue, Jan 12, 2021 at 05:43:07PM -0500, Michael Grant wrote: > On Tue, Jan 12, 2021 at 10:02:19PM +0000, Sudip Mukherjee wrote: > > On Tue, Jan 12, 2021 at 9:36 PM Michael Grant wrote: > > > > > > I have made this change: > > > > > > > > > > > I could probably send you my config files. I do have a fairly large database > of grey listed hosts. I probably don't want to post that in the bug tracking > database! > > For me, it runs for a while in side sendmail as a milter, I get a few > messages, then it restarts. > > The journalctl is huge, I will forward it to you after. It doesn't seem to > have any extra info. Thanks Michael for helping to test and debug this. To summarise, the latest update has completely changed the runtime behaviour of milter-greylist. 1) milter-greylist now runs as user 'smmsp' instead of 'greylist'. 2) As a result of (1) it now fails to open, read and write the db file which can only be read and written by 'greylist'. 3) It now runs as a foregound process instead of a daemon. 4) /var/run/milter-greylist is now created as user/group 'root' instead of 'greylist' 5) /var/run/milter-greylist.pid is now created as user 'smmsp' instead of 'greylist'. The error seen by Michael was mainly for (1) and (2) as the program will exit with OSERR when it fails to open the db file. Any, new install will also see (4) and (5). imho, the severity of this bug should have been 'serious' as it made the package unusable. The changes I suggested seems to have fixed the problem, I will now create a package with the modification and send it to Michael for a final test. -- Regards Sudip
Bug#978863: milter-greylist: ftbfs with autoconf 2.70
Hi, On Thu, Dec 31, 2020 at 02:28:20PM +, Matthias Klose wrote: > Package: src:milter-greylist > Version: 4.6.2-1 > Severity: normal > Tags: sid bookworm > User: d...@debian.org > Usertags: ftbfs-ac270 > > [This bug report is not targeted to the upcoming bullseye release] > > The package fails to build in a test rebuild on at least amd64 with > autoconf 2.70, but succeeds to build with autoconf 2.69. The > severity of this report will be raised before the bookworm release, > so nothing has to be done for the bullseye release. I am not seeing the FTBFS with autoconf 2.71-2 present in unstable now. Please check https://salsa.debian.org/debian/milter-greylist/-/pipelines/281026 Can you please retest and confirm. -- Regards Sudip
Bug#992997: milter-greylist: segfault in libGeoIP
Hi Bjørn, On Thu, Aug 26, 2021 at 07:09:40AM +0100, Bjørn Mork wrote: > Package: milter-greylist > Version: 4.6.2-3 > Severity: normal > > Seeing lots of these after upgrading til bullseye: > > Aug 23 22:12:23 louie kernel: milter-greylist[192919]: segfault at 28 ip > 7fbaf22fe8d9 sp 7fbaee77c670 error 4 in > libGeoIP.so.1.6.12[7fbaf22fc000+1b000] > Aug 23 22:12:23 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 > 00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 > ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35 > Aug 24 22:45:40 louie kernel: milter-greylist[217578]: segfault at 28 ip > 7fcc2deb78d9 sp 7fcc2a335670 error 4 in > libGeoIP.so.1.6.12[7fcc2deb5000+1b000] > Aug 24 22:45:40 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 > 00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 > ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35 > Aug 25 22:10:57 louie kernel: milter-greylist[240196]: segfault at 28 ip > 7f525900a8d9 sp 7f5255c89670 error 4 in > libGeoIP.so.1.6.12[7f5259008000+1b000] > Aug 25 22:10:57 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 > 00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 > ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35 > > Doesn't look too good, given that it's probably triggered by mail contents > somehow. I just updated the package to latest 4.6.4, can you please try with that and check if you still get the same problem. If you still the same problem the a coredump or some way to reproduce the problem will be needed. -- Regards Sudip
