I've picked up the work from Salvatore and finished getting the
packaging updated for the new upstream release. Good news, I could drop
all the Debian patches as they're all merged, or re-implemented
upstream.
If someone could please review, and ideally build and upload it, that'd
be much appreciated.
I added a couple of small commits, and I put two questions in debian/changelog, for you and others :)
I hope that Salvatore or someone else more familiar with the package
can take a look as well but in generall this looks all good to me.
I added a couple of small commits, and I put two questions in debian/changelog, for you and others :)They're good questions, I've resolved them both. The clean step was
because when the tests failed due to an old patch the blib directory
was left. I've moved it to a clean target.
Last night laying in bed I realised I hadn't checked the dependencies
on gnupg. I've now fixed those as well. ;)
On Mon, 06 Jul 2020 11:33:14 +1200, Andrew Ruthven wrote:
I have to admit that I'm still not convinced that this needed; an inconsistent state after a failed build (due to a failed test) is
nothing I would worry about, and nothing we handle in other packages.
(And maybe EUMM or M::B rm blib/ anyway?)
After your last change, which kind of "hijacks" the clean target, the
package now fails to build twice in a row:
I suggest to remove the rm from debian/rules.
(And if there should be a case to care for blib/ manually, to stick
it into debian/clean.)
(And the current override_dh_clean doesn't do anything and can be
removed).
Oh, and override_dh_auto_configure also can be removed, as
Makefile.PL does basically the same now.
I've now pushed these changes to debian/rules, please shout if you
see any problem or have any issues building!
GnuPG::Interface made a change to handle both GnuPG version 1.4 and 2.2
and it does that by tracking the version of gpg that is being used. But
it failed to clear the cached version information if you changed the
gpg binary to use after the object was instantiated.
This is exactly how Request Tracker changes the gpg binary to use with GnuPG::Interface, and caused request-tracker4 to FTBFS.
I've pushed a commit to libgnupg-interface-perl which resolves this behaviour. We also now test libgnupg-interface-perl against both
versions of GnuPG.
If someone could please review and (hopefully) upload the package,
that'd be much appreciated.
On Tue, 21 Jul 2020 19:02:12 +1200, Andrew Ruthven wrote:
I've pushed a commit to libgnupg-interface-perl which resolves this behaviour. We also now test libgnupg-interface-perl against both
versions of GnuPG.
If someone could please review and (hopefully) upload the package,
that'd be much appreciated.
Looks good to me in general.
Some thoughts:
- Does this also fix #964878?
- Could you forward the relevant patches upstream (to the CPAN RT
issue)? Then we can wait a bit and see if there are reactions
before uploading.
- The tests throw some warnings:
Can't exec "gnupg": No such file or directory at /build/libgnupg- interface-perl-1.00/blib/lib/GnuPG/Interface.pm line 343.
Use of uninitialized value $a in split at /build/libgnupg-interface- perl-1.00/blib/lib/GnuPG/Interface.pm line 829, <GEN5> line 1.
Use of uninitialized value $a in split at /build/libgnupg-interface- perl-1.00/blib/lib/GnuPG/Interface.pm line 829, <GEN5> line 1.
(So the same for gpg2 and gpg1). Is this expected/harmless/…?
- Not sure if CALL is the nicest possible name for the env var but
that's bikeshedding territory :)
We have two options here. Either
patch /usr/share/perl5/Crypt/Monkeysphere/MSVA.pm in msva-perl to use
the full path to /usr/bin/gpg when GnuPG::Interface. Or we modify GnuPG::Interface to use the full path instead of just running "gpg".
I'm leaning towards the later as otherwise we'll be playing whack-a-
mole for any other Perl programs that use Taint. Thoughts?
I'm happy to prepare that patch.
On Thu, 2020-07-23 at 23:55 +1200, Andrew Ruthven wrote:
We have two options here. Either
patch /usr/share/perl5/Crypt/Monkeysphere/MSVA.pm in msva-perl to use
the full path to /usr/bin/gpg when GnuPG::Interface. Or we modify GnuPG::Interface to use the full path instead of just running "gpg".
I'm leaning towards the later as otherwise we'll be playing whack-a-
mole for any other Perl programs that use Taint. Thoughts?
I'm happy to prepare that patch.
I've written a patch for this and pushed it. General case patch is
submitted upstream here:
https://rt.cpan.org/Ticket/Display.html?id=133041
We'll need to carry our own patch even if upstream accepts it as I've
set the default binary for gpg to be the full path so we don't need to
use $ENV{PATH} or modify any programs that use GnuPG::Interface.
On Tue, 2020-07-21 at 19:29 +0200, gregor herrmann wrote:
If someone could please review and (hopefully) upload the package,Looks good to me in general.
that'd be much appreciated.
Some thoughts:
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 72:39:07 |
Calls: | 6,489 |
Calls today: | 2 |
Files: | 12,096 |
Messages: | 5,275,731 |