[request-tracker-maintainers] Bug#839580: request-tracker4: FTBFS in testing (failed tests)

[Dominic Hargreaves]

On Tue, Oct 11, 2016 at 10:44:28PM +0200, gregor herrmann wrote:
> On Mon, 10 Oct 2016 23:10:30 +0300, Niko Tyni wrote:
> 
> > Help untangling this mess would be very welcome, as both Dominic and I
> > are rather short on time. Tagging and copying possible candidates :)
> 
> Good news: I got the package to build.
> Bad news: Only by forcing gpg1 even harder in the test suite.
> 
> For gpg2 I guess we'd need a fake pinentry and maybe also changes to
> the secret key layout etc. -- Material for dkg maybe :)
> lib/RT/Test/GnuPG.pm looks interesting for setting the gpg config,
> lib/RT/Test.pm has import_gnupg_key.
> 
> What I don't know is if RT4 in the current state now works with
> gpg2 when the test suite passes with gpg1 ...
> Maybe forcing it to gpg1 (in etc/RT_Config.pm.in and debian/control)
> would buy some time. But in general I guess we want gpg2 both at
> buildtime and runtime.
> 
> 
> Before getting that far, I had to make some other changes to reduce
> the build failures to the gpg related ones.
> 
> After the package built I also fixed some lintian errors :)
> 
> Additionally I noted that the build tried to connect to IP addresses
> beyond localhost (my DNS server and my gateway).
> 
> Attached is a patch series.

Hi gregor et al,

Thanks so much for preparing this patch series and tidying up some
non-related issues with the package while I've been unavailable! I
applied your patch series to master and will upload it shortly.

Thanks also to Daniel for looking at some of the root causes and
possible solutions. It would be great to get this all unravelled with
the gpg1 to gpg2 transition. I wonder if at this stage it's safest
to keep RT using gpg1 for stretch, although of course if it's possible
to get it working in time that'd be even better.

Cheers,
Dominic.