[request-tracker-maintainers] RT 5.0

[Andrew Ruthven]

Oh, and because I used dh-make-perl --pkg-perl they're all setup
with autopkgtest-pkg-perl in debian/control - I'm not sure if that is
appropriate or not.

On Thu, 2020-11-19 at 23:59 +1300, Andrew Ruthven wrote:
> On Sun, 2020-08-09 at 20:56 +0100, Dominic Hargreaves wrote:
> > On Wed, Jul 01, 2020 at 10:53:23AM +1200, Andrew Ruthven wrote:
> > 
> > I don't think merging the changelogs is necessary - sometimes the
> > context for prior development can be helpful. It's necessary to
> > supply
> > -v to dpkg-buildpackage in such a case. But if we're making other
> > changes
> > too, I agree it's worth considering. Equally you could bump the
> > initial
> > upload to Debian to -2 (as long as we include -sa).
> 
> Looking at the changelogs I already have, meh, I can drop them.
> 
> > I had a look at these packages, and I have some general feedback as
> > well as specific ones.
> > 
> > General
> > - please switch to source format 3 so it's easier to add packages
> > in
> > the
> >   future if needed
> > - please switch to team maintenance
> >   Maintainer: Debian Request Tracker Group <
> > pkg-request-tracker-maintainers at lists.alioth.debian.org>
> 
> Sure thing.
> 
> > rt-extension-resetpassword
> > 
> > - upstream is from git, and the tree does not match the released   
> >   tarball on CPAN. It looks like 1.06 hasn't actually been
> > released?
> >   Certainly as far as RT and perl module packaging goes, we don't 
> >   import the upstream git repo directly but use git-import-orig or 
> >   equivalent. Please can you repackage using 1.05 (and/or if there 
> >   are important things needed from git, add them as patches,
> > perhaps
> >   using git-dpm, or persuade upstream to release 1.06).
> 
> Ack. Rebuilt from the dist tarball, using 1.05. I don't think we need
> 1.06 for RT4, but we will for RT5. I have asked them to cut a
> release.
> 
> I have force pushed my changes to Salsa.
> 
> For my own packaging I have had a preference to use the upstream git
> repo to allow me to see full history, but happy to switch to dist
> tarballs for RT packaging.
> 
> > rt-extension-rest2
> > 
> > - as above, upstream is from git and MANIFEST doesn't match
> 
> Ack. Rebuilt from the dist tarball. I can't force push these changes
> as
> I'm not a Maintainer on the salsa project.
> 
> > rt-extension-mergeusers
> > 
> > - as above, upstream is from git and MANIFEST doesn't match
> > - this is hidden by debian/source/format, but I don't believe this
> > is
> >   an intended use of this option. Our source tree should match the
> >   upstream release tarballs in preference to upstream git.
> > - 1.06 is now available
> 
> Ack. Rebuilt from the 1.06 dist tarball. I can't force push these
> changes as I'm not a Maintainer on the salsa project.
> 
> > rt-extension-commandbymail
> > 
> > - (as you pointed out it's already been uploaded - as librt-
> >   extension-commandbymail-perl)
> > - ah, and also has a non-standard (from our point of view) package
> >   naming, that's unfortunate. We should reach out, certainly at the
> >   point we're transitioning extensions to RT5, with an offer to
> > bring
> >   it into team maintenance, but in the meantime, are you okay for
> > me
> >   to remove rt-extension-commandbymail.git from the team
> > salsa      
> > project, to avoid confusion?
> 
> I'm happy to talk to the maintainer of the existing package and
> prepare
> a transition package. Yes, happy for you to remove the repo from the
> team salsa. I have a local copy if I need it.
> 
> > rt-extension-assetautoname
> > 
> > - I see you've prepared this for use with RT5. I wonder if it
> > might  
> >   be a good opportunity to test building both rt4* and rt5*
> > packages?
> > - otherwise looks basically, but there are some lintian
> > errors/warnings
> >   to fix (possible-missing-colon-in-closes and
> >   missing-license-paragraph-in-dep5-copyright)
> 
> I actually used the upstream git repo here as well, so I've rebuilt
> it
> using the dist tarballs. ;) Force pushed to salsa.
> 
> It now builds rt4* and rt5* packages.
> 
> I have fixed those lintian warnings, but lintian is upset that both
> the
> rt4* and rt5* packages install the same man page. Has this already
> been
> handled for transitions in the past? Do we need to create another
> package for the man page?
> 
> > rt-extension-elapsedbusinesstime
> > 
> > - I renamed the path for this so it now appears at
> >   git at salsa.debian.org:request-tracker-team/rt-extension-
> > elapsedbusinesstime.git
> >   (it turns out that renaming a project doesn't rename its path (!)
> > - rt-extension-elapsedbusinesstime/Changes is missing from the
> > tarball but
> >   added in git.
> >   - maybe fixed in new upstream release?
> 
> I've given the upstream maintainer a sound telling off about
> forgetting
> to add the Changes file to the MANIFEST file and he assures me it has
> now been added. (Spoiler; I'm upstream, but I won't make a new
> release
> just to include the Changes file).
> 
> Thank you for fixing the path, yeah, a bit confusing.
> 
> I actually used the upstream git repo here as well, so I've rebuilt
> it
> using the dist tarballs. ;) Force pushed to salsa.
> 
> I have also extended the packaging to build rt4* and rt5* packages
> the
> same as rt-extension-assetautoname. Same problem with lintian and the
> manpage.
> 
> > Sorry again for the slow review. I'll try and do much better at
> > subsequent reviews - just ping me by email or IRC (Dom on OFTC) as
> > and
> > when you make progress.
> 
> No worries, my slowness this time round. ;)
> 
> I will look at modifying the rest of them to build both rt4 and rt5
> packages, but it is almost midnight now, so time to step away from a
> screen.
> 
-- 
Andrew Ruthven, Wellington, New Zealand
andrew at etc.gen.nz              |
Catalyst Cloud:                | This space intentionally left blank
   https://catalystcloud.nz    |