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----- > > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295795153.31308.44.camel@sirius
