Re: RFS: snake4 (updated package)
Hi Niels,
Am Sonntag, den 23.01.2011, 11:45 +0100 schrieb Niels Thykier:
> -----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
Thanks for the hint of checking the changes file!
> [... ]
> 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
I can't find the .pc in my packages any more. I know I generated one
while I was looking for the right d/p/format content (Must NOT contain a
lf, although dpkg-source is requesting so). I will just make a fresh
package and check and upload it again. (-done)
>
> 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 still got "P: snake4 source:
direct-changes-in-diff-but-no-patch-system Makefile and 3 more", which
is correct, if you took a look into the snake4_1.0.12-13.diff.gz.
>
> 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.
I'm not sure if it's worth changing to cdbs and/or quilt right now for
only 4 small changes (I use it for an other adopted package - snacc -
right now, so it's not a question of skill).
I removed that dh_desktop line - that's o.k. for I added the #, but I
can't see the necessity of changing the other things or removing
comments. It was o.k. all the time so far and is doing no harm. I also
like to have some comments, even if they remain from the initial
conversion to a debian package.
>
> 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.
>
Why that? Even lintian was only requesting (on that mentioned snacc
package W: snacc source:
package-lacks-versioned-build-depends-on-debhelper 5) to change from >>4
to >>5. On the other hand actualised lenny is using 8.0.0~bpo50+2, so
why not change to 8, for I haven't checked against older versions and I
do NOT intend to do so?
Just to be complete : this change has to be made in the control file,
not in rules.
Last questions : Is it a MUST to make those suggested changes? And if
not, what's next now?
Kind regards
Michael
> ~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: