Re: RFS: snake4 (updated package)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-01-21 12:14, michael wrote:
> Dear Mentors and hi Niels,
>
Hi again
> I did everything as requested in the mail below. I hope I took the bug
> in the right way - otherwise please tell me. I additionally checked the
> package using pbuilder against sid and squeeze and it's now lintian
> clean. mentors.debian.org is telling me so, too.
>
Great. For pbuilder you only need to use sid for normal uploads (or
experimental if you need to upload there).
About lintian; your package is clean down to informational tags. By
default lintian only shows a subset of all tags it can, you can add
additional flags (-IE --pedantic) to see all them. To get the most out
of lintian you should always run it on the changes file (e.g.
snake4_1.0.12-13_i386.changes)[1].
Note about mentors.debian.org and lintian: mentors.d.n only have the
source package available so it is unable to check for a lot of potential
issues in the binary package(s).
[1] First lintian will automatically run all packages related to the
changes file in this way. Secondly, there are a few checks on the
changes file as well. Finally lintian has a few cross package checks,
which currently requires that lintian processes the package in a certain
order.
> So what do I need to do next?
>
> Kind regards
> Michael Boegl
>
> Am Montag, den 17.01.2011, 13:15 +0100 schrieb Niels Thykier:
> On 2011-01-16 21:33, michael wrote:
>>>> Dear mentors,
>>>>
>>>> I am looking for a sponsor for the new version 1.0.12-12
>>>> of my package "snake4".
>>>>
>>>> It builds these binary packages:
>>>> snake4 - Snake game
>>>>
>>>> The upload would fix these bugs: 581387 (O: snake4 -- Snake game)
>>>>
>
> Hi
>
> Thanks for your interest in Debian and for wanting to adopt an orphaned
> package.
>
> First things first; you should officially declare your intend to adopt
> snake4. See [1] for how to do that.
>
> You should probably also remove Ola Lundqvist from Uploaders (just
> remove the entire field). If Ola was an active uploader the package
> would not be orphaned :)
>
> [...]
This looks good :)
Now, as hinted the package is mostly clean, but you have a pedantic tag
against the source package. Some pedantic tags are usually okay (e.g.
the "no upstream changelog" - if upstream does not ship one there is not
much to do about it).
$ lintian -EvI --pedantic ../snake4_1.0.12-13_i386.changes
[... ]
N: Processing source package snake4 (version 1.0.12-13) ...
P: snake4 source: direct-changes-in-diff-but-no-patch-system
.pc/.version and 9 more
However, I would like this particular tag reviewed a bit. It looks like
the at least .pc/ files appeared between your -12 and your -13 package.
It is used by quilt to figure out what patches have been applied.
However you do not ship any quilt patches as far as I can tell. I am
guessing (based on the patch name) that it comes from an incomplete
attempt to convert to 3.0 (quilt) source format.
If you convert to 3.0 (quilt) dpkg-source will automatically exclude it
when building it. It will also automatically create it when unpacking
the source package.
Alternatively, you should remove the .pc directory.
For the actual files changes, I would recommend moving these changes
into patches (a patch for each logical change). dpkg-source can
generate a patch for all changes if you convert to 3.0 (quilt) and build
the package. You can use tools like filterdiff to extract parts of the
patch into other patches.
You can also extract them directly from the diff.gz, if you prefer
that (for larger packages this can be vastly faster) :)
Regardless of what option you take here, you have to make sure the
patch(es) are applied before the package is built. If you use 3.0
(quilt) it will done at unpack time - just list the patch(es) in
debian/patches/series.
Otherwise debian/rules must be updated to apply the patches before
compiling and unapply them during the clean. Note that most build tools
always clean before building, so the "unapply" code must be able to
handle that the patches are not applied.
If you use one of the common patch systems in Debian (e.g. quilt or
dpatch) they usually have either tools or Makefile snippets that can be
used for this.
I would also like you to clean up d/rules. At least remove/merge
uninterested targets and comments. Please also either fix the "noopt"
build option or remove the code for it (fixing it probably requires
patching upstreams Makefile, since it does not react to CFLAGS).
Personally I prefer things like the debhelper "tiny rules"[2] with
override targets (or cdbs, but I have less practice with it). These
styles have the advance of hiding the "standard stuff", making the
"non-standard" parts more visible.
When you clean up the rules file, please bump debhelper to at least 7.
if you go with "tiny rules" with overrides, you will need a
Build-Depends on debhelper (>= 7.0.50~) - but the compat is still 7 in
this case.
~Niels
[2] /usr/share/doc/debhelper/examples/rules.tiny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNPAbfAAoJEAVLu599gGRCjEgP/jPM3faSzg3SAOV5jMZz0ZmX
QCexJFa/u1ILHkti1tvy8sEOzg/xRpTVJ/SACrT0JIILI6F7E7SziKYA3ueS4XMy
6qVi/Jna715gBYgLRVneJt79ptqaLLCgPdrcH17CspkdCkVSKIZRSH7D9ExQ57Zx
YTOihNaqZCNyaj1i6opKd+hETFL3YoN1peVdr5i6iHtUDki+YObHT5jVkcd4SkGT
5ufSb3HU5Uc9bNcfRoGy8cL2UH2yhZ609iUckmL8hZ4YleRNiG3jOyHTnHlqIWcW
tty+hH0ftnLzy7NaZEWUhDHgvNBnK1ucOV2PNomRchc/Sij0OJTyga+e+fpi8oFr
CW1enTCg0fWhNmQ3y7l8pzwCEMIaglMBqXdA8kYf9J1jtn6atvLDa6PeAj6n0rD8
F74j7/GKFJUuWc0U+H807L0bIrrr73j/9Z8tJikGI44HWfDUMWOM8KdB92p5HlH4
Th/c582IRRk9t0Xq6c8IdkAvuzhnk8wQpsZjSUQOGxPVFw2/6YpZFMHxDBtpJZuD
YVI1/9WV0FHpb6ZuLEFKERTXPGfOvCJzCz/GbrgTNUYuUp7Ms3pTdQpZ8m4YEILF
bCr5e4fyWzRAMIGsZkva2SFPNdsapuzTuaGslw3RfSMTJBpXayzlAavZXWSNUZmX
lcqLe3it4sBWKKDI9K60
=wfLZ
-----END PGP SIGNATURE-----
Reply to: