[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] ProbABEL packaging



Hi,

On Mon, Dec 09, 2013 at 02:49:38PM +0100, L.C. Karssen wrote:
> > 
> >          git push --tags
> > 
> > since no tags are set yet and at least the upstream version should be
> > tagged.
> 
> So I need to tag the whole probabel directory (source + debian/ dir)
> with the upstream version number?
> 
> Like this?
>  git tag -a v0.4.1 -m "Tag of source version v0.4.1 of ProbABEL"

Most probably not.  If you imported via

   git import-orig --pristine-tar

than the tag was just set.  What do you get when you do `git tag` ?
 
> > Regarding your packaging:  In any case you should run
> > 
> >    lintian probabel_0.4.1-1_amd64.changes
> > 
> > and I also recommend using "-I" to get info level warnings.  If you
> > specify "-i" option you get verbose information about every warning
> > type.
> > 
> 
> Thanks, I didn't know about the -i option. Very useful.
> 
> Do I need to fix all warnings, or only errors? Or can I add overrides?

Strictly speaking you only need to fix errors for a successful upload.
But we do not only want to do successful uploads but we try to get high
quality packages and so warnings should vanish as well except if we have
good reasons for an override.  From my first view non of the warnings
were worth an override - we should rather fix all the issues.

> And what do I do with the Info items?

These are worth fixing as well.  We can work down this step by step.
 
> Questions about some of the warnings:
> 1) W: probabel: script-with-language-extension usr/bin/extIDS.pl
> 	Do I need to fix this? Users are used to add the .pl extension
> (especially for the main wrapper script propbabel.pl).

This is subject of several threads here on the list and the opinion of
different team members is different.  The last time this issue was
discussed is here:

   https://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-November/023454.html

and I would like to invite you to read the two links I mentioned there
which give explicite reasoning why there should be no language
extensions.  Since you are working together with upstream I would really
love if you could take over the work to teach upstream that there should
not be any language extension (and the links providing you with
information why not).  If you (and upstream) might totally disagree with
the arguing and you insist that this needs to be that way for good
reasons and none of the workarounds I proposed seems acceptable we might
leave it as is.  Please note:  My mentoring job is not about putting my
personal opinions on you.  If you have good reasons to diverge from it
that's OK.

> 2) W: probabel: package-contains-upstream-install-documentation
> usr/share/doc/probabel/INSTALL.gz
> 	What is the best way to deal with this? Remove the INSTALL file in
> debian/rules? Or simply remove it from the directory structure?

Remove it in debian/rules.  It is just part of the upstream tarball and
there is no point in fiddling around with this.

> > I guess you might be astonished about
> > 
> >     changelog-should-mention-nmu
> > 
> > which is basically because you did neither adapted changelog nor
> > d/control to your user ID.  The easiest way to get this in changelog
> > is to do
> > 
> >     dch -i
> > 
> > but make sure you do not create a new changelog entry since you have the
> > target release "unstable" dch assumes the package was just released.  I
> > took this as motivation to change the package_template and injected
> > UNRELEASED there (which you should do as well as long we do not release.
> > Please add the same user ID as it is in changelog into debian/control as
> > Uploaders.  For the moment I do not see any reason to leave me there but
> > it is OK if my ID is in a comma separated list with yours.
> > 
> 
> OK, I've changed that (still have you in uploaders list, at least for
> now). I haven't committed this yet, I'll do so together with some of the
> lintian fixes after I've got the tagging done right.

OK.
 
> > I think you can remove debian/get-orig-source since it seems there is no
> > need for repackaging (and thus you can also remove the get-orig-source
> > target from debian/rules).
> 
> Done.
> 
> > 
> > I think for the moment this is enough advise.  Just let me know if you
> > have some problems to understand and solve the lintian issues.
> > 
> > Kind regards and thanks for your work on this
> 
> 
> Thanks a lot for the help!

That's the sense of MoM.  We should iterate through all these issues until
we have a high quality package.

Kind regards

      Andreas.

-- 
http://fam-tille.de


Reply to: