Source: gpgme1.0 Version: 1.16.0-1.1 Severity: important In my opinion, this smells like a Policy violation, but I'm setting the severity at non-RC since it's not my judgment that matters, but that of the CI team.
Because DEP-8 tests (autopkgtests) speed up migration and have other consequences on the release process, any tests that do not exercise a significant amount of functionality must be marked with Restrictions: superficial. I was wondering whether GPGME had any autopkgtests because I was interested in writing one. The Python test only checks that the gpg module can be imported and a context obtained, but doesn't do anything with it. Only checking if a module can be imported is the go-to example of a superficial test. The checky2106 test likewise doesn't actually exercise any actual functionality from GPGME, or even include the appropriate header. If you'd like a significant autopkgtest, I'd be glad to write one, but I'd like to bring to your attention that these existing tests really ought to be marked superficial. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-1-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
signature.asc
Description: This is a digitally signed message part