Bug#939893: lime-forensics: autopkgtest regression
Hi Eriberto, On 12-09-2019 15:51, Eriberto wrote: > Don't worry. As already reverted it as I said here[1]. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939893#15 As I wasn't CC-ed, that message never reached me. (Bug submitters aren't automatically subscribed to a bug by the BTS, although I wish they were (opt-in)). Paul signature.asc Description: OpenPGP digital signature
Bug#939893: lime-forensics: autopkgtest regression
Hi, On 12-09-2019 16:02, Paul Gevers wrote: > Hi Eriberto, > > On 12-09-2019 15:51, Eriberto wrote: >> Don't worry. As already reverted it as I said here[1]. >> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939893#15 > > As I wasn't CC-ed, that message never reached me. (Bug submitters aren't > automatically subscribed to a bug by the BTS, although I wish they were > (opt-in)). Too fast. Obviously it did reach me as I submitted the bug and I got notified of the closure. But due to the way the automatic closure message is formatted, I often fail to see the closure message, as happened in this case. Personally I got into the habit of sending the submitter directly the message I send to -done, to avoid that problem. Paul signature.asc Description: OpenPGP digital signature
Bug#939893: lime-forensics: autopkgtest regression
Em qui, 12 de set de 2019 às 04:50, Paul Gevers escreveu: > > Hi Eriberto, > > On 11-09-2019 04:26, Eriberto Mota wrote: > > Thanks a lot Paul. As a temporary workaround, I uploaded a new package > > to 1-day/delay queue, with the changes shown here[1]. > > > > [1] > > https://salsa.debian.org/pkg-security-team/lime-forensics/commit/0ca063ea176c51b2c4dbe0005f275443f9f0c458 > > Please revert this. The package already migrated, because I added a hint > as I told you in my message. > Hi Paul, Don't worry. As already reverted it as I said here[1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939893#15 Thanks for your help. Regards, Eriberto
Bug#939893: lime-forensics: autopkgtest regression
Hi Eriberto, On 11-09-2019 04:26, Eriberto Mota wrote: > Thanks a lot Paul. As a temporary workaround, I uploaded a new package > to 1-day/delay queue, with the changes shown here[1]. > > [1] > https://salsa.debian.org/pkg-security-team/lime-forensics/commit/0ca063ea176c51b2c4dbe0005f275443f9f0c458 Please revert this. The package already migrated, because I added a hint as I told you in my message. Paul signature.asc Description: OpenPGP digital signature
Bug#939893: lime-forensics: autopkgtest regression
Em seg, 9 de set de 2019 às 17:23, Paul Gevers escreveu: > > Source: lime-forensics > Version: 1.8.1-2 > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainers, > > With a recent upload of lime-forensics the autopkgtest of lime-forensics > fails in testing when that autopkgtest is run with the binary packages > of lime-forensics from unstable. It passes when run with only packages > from testing. In tabular form: >passfail > lime-forensics from testing1.8.1-2 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. Is your test > broken with a stretch host kernel? If your need isolation-machine, > please specify that restriction in your autopkgtest declaration: > """ > > isolation-machine > The test wants to interact with the kernel, reboot the machine, or > other things which fail in a simple schroot and even a container. > Those tests need to be run in their own machine/VM (e. g. > autopkgtest-virt-qemu or autopkgtest-virt-null). When running the > test in a virtualization server which does not provide this it will > be skipped. > """ > > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the situation and fix it? If needed, please > change the bug's severity. > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=lime-forensics > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/lime-forensics/2914894/log.gz > > Setting up lime-forensics-dkms (1.8.1-2) ... > Loading new lime-forensics-1.8.1-2 DKMS files... > It is likely that 4.9.0-8-amd64 belongs to a chroot's host > Building for > Setting up autopkgtest-satdep (0) ... > Processing triggers for systemd (242-5) ... > Processing triggers for libc-bin (2.28-10) ... > (Reading database ... 12759 files and directories currently installed.) > Removing autopkgtest-satdep (0) ... > autopkgtest [22:18:11]: test command1: /usr/lib/dkms/dkms-autopkgtest > autopkgtest [22:18:11]: test command1: [--- > dpkg: dependency problems prevent removal of dkms: > lime-forensics-dkms depends on dkms (>= 2.1.0.0). > > dpkg: error processing package dkms (--remove): > dependency problems - not removing > Errors were encountered while processing: > dkms > I: Installing binary package lime-forensics-dkms > Reading package lists... > Building dependency tree... > Reading state information... > lime-forensics-dkms is already the newest version (1.8.1-2). > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > tar: Cowardly refusing to create an empty archive > Try 'tar --help' or 'tar --usage' for more information. > autopkgtest [22:18:13]: test command1: ---] > >From #939982: - Hi Eriberto, Thanks for talking about the issues you have, I could not have guessed. On 10-09-2019 17:53, Eriberto Mota wrote: > I was using a test over a DKMS package (lime-forensics). I removed > all tests[1] because Debian wasn't process it (adding a Neutral tag) > and to close the bug #935543. Now I have a regression in my > package[2][3]. However, I no longer maintain a test. I think it is a > bug in debci. How to proceed to avoid a regression after removing all > tests? This is not an issue with debci, as that just runs tests on behalf of other entities. The culprit here is britney, the migration software of the release team, hence filing a bug against it. The problem is that the migration software *seems* (I haven't checked properly yet) to trigger even in the case that all tests are removed. Because autopkgtest (the software) is by default configured to try and call autodep8 if no tests are found, you package was tested with tests from autodep8, while in your case that is inappropriate as they fail. You have no way of telling the infrastructure that. As britney considering neutral-to-fail a regression your package is flagged as such. I see that's nothing you can solve so I'll ignore the failure. > [1] > https://salsa.debian.org/pkg-security-team/lime-forensics/commit/d7d4c79ae7ea55c5d64cc6103d3745e199056284 > [2] https://ci.debian.net/packages/l/lime-forensics/ > [3]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939893 Paul - Thanks a lot Paul. As a temporary workaround, I uploaded a new package to 1-day/delay queue, with the changes shown here[1]. [1] https://salsa.debian.org/pkg-security-team/lime-forensics/commit/0ca063ea176c51b2c4dbe0005f275443f9f0c458 Cheers, Eriberto
Bug#939893: lime-forensics: autopkgtest regression
Source: lime-forensics Version: 1.8.1-2 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of lime-forensics the autopkgtest of lime-forensics fails in testing when that autopkgtest is run with the binary packages of lime-forensics from unstable. It passes when run with only packages from testing. In tabular form: passfail lime-forensics from testing1.8.1-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Is your test broken with a stretch host kernel? If your need isolation-machine, please specify that restriction in your autopkgtest declaration: """ isolation-machine The test wants to interact with the kernel, reboot the machine, or other things which fail in a simple schroot and even a container. Those tests need to be run in their own machine/VM (e. g. autopkgtest-virt-qemu or autopkgtest-virt-null). When running the test in a virtualization server which does not provide this it will be skipped. """ Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=lime-forensics https://ci.debian.net/data/autopkgtest/testing/amd64/l/lime-forensics/2914894/log.gz Setting up lime-forensics-dkms (1.8.1-2) ... Loading new lime-forensics-1.8.1-2 DKMS files... It is likely that 4.9.0-8-amd64 belongs to a chroot's host Building for Setting up autopkgtest-satdep (0) ... Processing triggers for systemd (242-5) ... Processing triggers for libc-bin (2.28-10) ... (Reading database ... 12759 files and directories currently installed.) Removing autopkgtest-satdep (0) ... autopkgtest [22:18:11]: test command1: /usr/lib/dkms/dkms-autopkgtest autopkgtest [22:18:11]: test command1: [--- dpkg: dependency problems prevent removal of dkms: lime-forensics-dkms depends on dkms (>= 2.1.0.0). dpkg: error processing package dkms (--remove): dependency problems - not removing Errors were encountered while processing: dkms I: Installing binary package lime-forensics-dkms Reading package lists... Building dependency tree... Reading state information... lime-forensics-dkms is already the newest version (1.8.1-2). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. tar: Cowardly refusing to create an empty archive Try 'tar --help' or 'tar --usage' for more information. autopkgtest [22:18:13]: test command1: ---] signature.asc Description: OpenPGP digital signature
