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

Re: Packaging and sponsoring of ompl (Was: r3898 - in /projects/science/trunk/debian-science/tasks: robotics robotics-dev)

Hi Leopold,

On Wed, Oct 30, 2013 at 03:28:15PM +0100, Leopold Palomo-Avellaneda wrote:
> >  2. The specified dependency should be a binary package name which
> >     correlates to a binary package name in your debian/control file.
> >     You specified the source package name 'ompl' - but you can not
> >     depend from a source package.  I changed this to ompl-demos and
> >     used "Suggests" (since this sounded appropriate to me - feel free
> >     to change this to "Depends").
> Yes, I'm sorry. I did a mistake here and do a cut and paste from control file 
> :-(  and not pay attention to that. I'm sorry to waste your time in this 
> stupid mistake. 

There is no need to be sorry nor did you wasted my time by a "stupid"
mistake.  This is what happens and reiterating things here on the list
might help others to get a better understanding.

> >  3. You have specified several fields in addition to the Suggests
> >     field.  This is not necessary any more if you have injected the
> >     packaging into the team VCS.  It is probably not properly
> >     documented in [2] (feel free to send a patch) but all these data
> >     are obtained automatically to safe your time in maintaining the
> >     tasks file.  To demonstrate this I removed those fields that were
> >     overriden anyway by the packaging content.  The only field I left
> >     untouched was WNPP.  The reason is a problem in your
> >     debian/changelog file (see below for the sponsoring comments).
> Ok, good to know it.

> > Now my comments to your packaging[3]
> > 
> > debian/changelog:
> >   - You are trying to close the ITP bug in an "historic" changelog
> >     paragraph (0.12.2-Source-1).  This does not work.  Bugs can only
> >     be closed in recent changelog entries (here is also the answer why
> >     this information is not parsed by the Blends tools - they are only
> >     regarding the latest changelog entry).
> >   - Moreover you are mentioning unstable as target distribution of
> >     those past entries.  However, there was never any upload to unstable
> >     at all but these are rather all "UNRELEASED".  Generally speaking:
> >     It does not make much sense to maintain a debian/changelog before
> >     the first version is really inside Debian.  The history of the
> >     packaging can be obtained from the Git log.  => Please drop old
> >     entries and leave only
> >       * Initial release (Closes: #706133)
> >     in the current entry.
> Ok, but from the packager point of view, it helps you to see how many packages 
> you have worked before. I can delete whatever you think convenient, but I 
> began to package it with one version of the library and changed it. So, I 
> tried to document it. Can I leave the entries but change it from unstable to 

If it is helpful for you there is no rule that would forbid to keep the
entries.  I just heard from ftpmaster that they might become distracted
to read irrelevant stuff and I personally like to keep their workload as
small as possible.  I'm not sure whether this opinion is valid these
days any more.  So if you really think it is helpful - this will not
stop me from sponsering in the end.
> >   - Pre-Depends: dpkg (>= 1.15.6~)
> >     What is the rationale for this?  Usually it should not be needed.
> >   - Please give
> >        cme fix dpkg-control
> >     a try.  I guess you will like the result.
> First of all, I must admit that I don't understand what are you asking me with 
> the dpkg-control. 

Well, the usage of configmodel has nothing to do with Pre-Depends or lintian.
It is just a unique formatting (that's why I used different items im my list).

> I put this field because I checked the generated packages with "lintian -EviIL 
> +pedantic". And then, I got a lintian warning like:
> N:    The package contains a preinst maintainer script that uses
> N:    dpkg-maintscript-helper but does not declare a versoned pre-dependency
> N:    on dpkg (>= that provides that script.
> so, I do that.

Well, due to the missing pristine-tar I did not yet builded the package.
I have no idea what (possible false positives) lintian is producing in
pedantic mode (and I actually do not use this lintian level).  Your
debian/ dir does not contain any preinst maintainer script and so
(without testing) I simply assume that lintian is wrong here.  The
Pre-Depends field should be *realy* rarely used and +pedantic lintian
messages are a weak reason to do so.  Please re-read the docs when
Pre-Depends should really be used.

> > pristine-tar branch is missing:
> >   - If you imoprt the orig.tar.gz please use
> >       git import-orig --pristine-tar /path/to/package_version.orig.tar.gz
> >     to make sure your sponsor / team member can easily recreate a byte
> >     identical tarball.
> Ok, the problem I found is that the official version got some problems that I 
> report to upstream and changed it in mercurial. Ti me is ok the version with 
> the commit hash, so I imported that one. But it seems I forget some step. I 
> solve it soon.

OK.  Just ping me - favourably via an entry at SoB Wiki page.  I just
verified that after my changes the package arrived at the according
tasks page[1].
> > lintian warnings:
> >   - please check `lintian -I -i` and consider to fix some lintian
> >     nitpicking issues.
> > 
> > So far for the sponsoring request.
> Thanks for your time.

You are welcome


[1] http://blends.alioth.debian.org/science/tasks/robotics-dev#libompl-dev


Reply to: