Em seg, 9 de set de 2019 às 17:23, Paul Gevers <elb...@debian.org> 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: > pass fail > lime-forensics from testing 1.8.1-2 > all others from testing from 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
