Debian Patches
Status for libgnupg-interface-perl/1.04-6
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| test_reset_version_on_call_change | Using 'call' method doesn't reset gpg version GnuPG::Interface allows the use of the 'call' method to change the program to be used. Test that this works. |
Andrew Ruthven <andrew@etc.gen.nz> | yes | upstream | 2021-01-28 | |
| test-gnupg1 | Test against GnuPG v1 The test cases only test "gpg" which for Debian is v2. As the module also supports v1 which we ship, we should test against it. |
Andrew Ruthven <andrew@etc.gen.nz> | not-needed | 2020-07-18 | ||
| test-allow-interface-to-fail | Allow setting the call program to fail This test is checking that the old setter/getter interface works. My fix to resetting the version causes this test to fail on Debian as we have no binary called 'gnupg'. Since the test is testing the setter/getter we don't care if loading the version fails. |
Andrew Ruthven <andrew@etc.gen.nz> | yes | upstream | 2020-07-19 | |
| test-dummy-binaries | Ensure that we have some dummy "binaries" around for testing. The test scripts require that gpg1, gpg and gnupg all exist and are executable, otherwise warnings will be thrown. This patch provides those "binaries", but they actually only print the a version number that matches the binary. It is still necessary to have at least one real GnuPG binary installed for the test suite to pass. For Debian, but gpg and gpg1 need to be present. The patch to t/update_version.t isn't required on Debian, but is included as this patch set has been forwarded upstream, and may be required elsewhere. This is also why dummy scripts for gpg, gpg1 and gnupg are provided. |
Andrew Ruthven <andrew@etc.gen.nz> | yes | upstream | 2020-07-23 | |
| hardcode-path | Hardcode path to /usr/bin/gpg | Dominic Hargreaves <dom@earth.li> | not-needed | debian | 2023-09-17 | |
| version-stdin.patch | Add stdin handler to _version sub | gregor herrmann <gregoa@debian.org> | yes | debian upstream | vendor | 2023-09-17 |
| 0007-Handle-versions-of-GnuPG-2.2.x-that-report-the-RENC-.patch | Handle versions of GnuPG 2.{2,3,4}.x, that misreport the RENC key usage flag Some versions of GnuPG 2.2, 2.3, and 2.4 printed an apparently bogus RENC key usage flag. Avoid failing the test suite just because those versions are in use. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | yes | 2024-05-24 | ||
| 0008-Accept-or-or-as-validity-for-expired-invalid-sigs-see-T7547.patch | Accept ? or ! or % as validity for expired/invalid sigs (see T7547) https://dev.gnupg.org/T7547 contains discussion about shifting expectations for the validity field for expired signatures. In 2.4, which considers these expired signatures using SHA1 as too weak, it emits '%' for the validity field. For flexibility, accept all three variants, in accordance with GnuPG upstream wishes. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | yes | 2025-03-13 | ||
| 0009-t-list_secret_keys.t-handle-new-human-readable-outpu.patch | t/list_secret_keys.t: handle new human-readable output from 2.4 2.4 includes a mention of the "Revocable" line, so make sure we don't fail a test because of it. |
Daniel Kahn Gillmor <dkg@fifthhorseman.net> | no | 2025-03-13 |