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
> UNRELEASED?
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 (>= 1.15.7.2~) 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
Andreas.
[1] http://blends.alioth.debian.org/science/tasks/robotics-dev#libompl-dev
--
http://fam-tille.de
Reply to: