[request-tracker-maintainers] RT command-by-mail

[Matthew Johnson]

On Tue, Mar 27, 2007 at 12:00:28AM +0300, Niko Tyni wrote:
> On Thu, Mar 22, 2007 at 10:02:25PM +0000, Matthew Johnson wrote:
> 
> > This unpacks into the directory RT-Extension-CommandByMail-0.05, rather
> > than librt-extension-commandbymail-perl-0.05, which is what I would
> > expect from the deb. Is it correct to untar, mv the directory to the
> > correct name and then retar (which I have done in the current draft); or
> > is this not neccessary?
> 
> It's not necessary. There's magic in dpkg-source for this. See
> the Developer's Reference:
> 
>  http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz

Ah, it's more cunning than I had anticipated then. I'll re-roll the
packages like that then.

> > New (renamed and now signed) packages are at
> > http://mjj29.matthew.ath.cx/debian-upload/librt-extension-commandbymail-perl/
> 
> Great, it looks good to me now.
> 
> I'm not sure if it's optimal to depend on request-tracker3.4 |
> request-tracker3.6 . This rules out people with non-packaged RT
> installations, which is probably quite common. (Well, they could use
> equivs or something, but they probably don't.)  Maybe 
> 
>  Enhances: request-tracker3.4 (>= 3.4.6), request-tracker3.6 (>= 3.6.1)

Since the package is useless without RT installed I thought policy
mandated that it depended on everything required for it to be useful,
including having a real package as the first in a list of alternates so
that it can be installed if nothing else is already. The argument about
non-packaged dependencies could apply to anything else (should I depend
on perl? they might have non-packaged perl) and is somewhat specious.

However, given that the preferred RT is now 3.6 I should probably depend
on that first.

> 
> The comments at the end of debian/copyright look like leftovers from
> a template.

oops! good catch, I'd missed that (although I was going to have a final
look through everything before actually declaring it OK).

> There's an empty /usr/lib/perl5 directory in the .deb, which is a bit
> ugly. The customary way around this is
> 
>     rmdir --ignore-fail-on-non-empty --parents $(TMP)/usr/lib/perl5
> 
> See eg. http://pkg-perl.alioth.debian.org/rules-template-noxs
> 
> An arguably cleaner way to remove Makefile.old is 'make distclean'.

Thanks

> Good luck finding a sponsor. If you want to join the Request Tracker
> group and put it in the maintainer field, I'm happy with that,
> but (obviously) I can't speak for Toni about uploading the package.

I think I'll probably put the RT group as maintainer with myself as
uploader, unless anyone has any big objections.

I do actually need to do some more testing before releasing this though.
It's currently disabled in our RT because it seems to fail on creating
new tickets. There is a line which does if ($args{'Ticket'}->id) to
check if the ticket already exists, but this throws an error when it
doesn't, as it can't access ->id. I need to spend some time deciding how
best to fix that; I've emailed upstream, but with no response yet. Since
it's a live RT I've just disabled it at the moment. There's also an
issue with it reopening tickets which you close using the commands.

What I'll probably do is upgrade to 3.6 once we migrate to etch and then
try again with that. I might depend just on 3.6 in that case as this
won't be in stable until Lenny, by which time everyone should be on 3.6
anyway.

Matt

--
Matthew Johnson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-request-tracker-maintainers/attachments/20070327/55102dba/attachment.pgp