A Dimecres, 30 d'octubre de 2013, Andreas Tille va escriure: > Hi Leopold, > > I noticed that you tried to follow my Sponsering of Blends procedure[1] > and injected some data to the robotics tasks. That's great and it is > really welcome. I always like to teach at these examples who to do this > properly and efficiently. So let me comment your changes first: Ok, [...] > > > > +Package: ompl > > +Homepage: http://ompl.kavrakilab.org > > +License: BSD-3-clause > > +Responsible: Leopold Palomo-Avellaneda <leo@alaxarxa.net> > > +WNPP: 706133 > > +Pkg-Description: Sampling-based motion planning library > > + Consists of a set of sampling-based motion planning > > + algorithms. The content of the library is limited to these algorithms, > > + which means there is no environment specification, no collision > > + detection or visualization. The library is designed so it can be easily > > + integrated into systems that provide the additional needed components. > > + > > Comments: > > 1. You never should use the "Package" field when specifying package > dependencies in a task file. It is always Depends / Recommends / > Suggests (see [2]). > > 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. > 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. > > + > > +Package: libompl-dev > > +Homepage: http://ompl.kavrakilab.org > > +License: BSD-3-clause > > +Responsible: Leopold Palomo-Avellaneda <leo@alaxarxa.net> > > +WNPP: 706133 > > +Pkg-Description: Sampling-based motion planning library development files > > + Consists of a set of sampling-based motion planning > > + algorithms. The content of the library is limited to these algorithms, > > + which means there is no environment specification, no collision > > + detection or visualization. The library is designed so it can be easily > > + integrated into systems that provide the additional needed components. > > Comments: > > 1. Same as above - I did a s/Package/Depends/. > 2. Here you correctly used the binary package name libompl-dev that exists > in your packaging - that's fine. > 3. Same as above - I just left the WNPP bug. Ok. > 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? > debian/README.Debian: > - Please delete this file. The information is not relevant and just > contained in the metadata of debian/copyright. > > debian/README.source: > - Please delete this empty file as well. > ok, done. > debian/control: > - Please choose "Priority: extra". I guess I did mention it several > times here on this list that extra is for *-dbg packages or things > like this. ok, done. Changed for optional. > - 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. 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. > 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. > 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. Leo -- -- Linux User 152692 Catalonia
Attachment:
signature.asc
Description: This is a digitally signed message part.