Re: RFS: snake4 (updated package)
Am Donnerstag, den 03.02.2011, 00:37 +0100 schrieb Niels Thykier:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 2011-01-23 16:05, michael wrote:
> > [...]
>
>
> Hey,
>
> Sorry for the late reply. I am taking the liberty of answering this one
> first.
That's o.k. although I feared I had picked some wrong phrases for
englisch is not my native language...
>
> > Last questions : Is it a MUST to make those suggested changes? And if
> > not, what's next now?
>
> None of these suggestions in my last email were a *must* on my part,
> mostly because I intend have you contact the Debian Games Team (as I
> mentioned in my first email). Due to a lack of experience with games
> packages I do not feel good about being the sponsor of game packages.
I want to do that next, but I wanted to wait until squeeze is out(this
weekend). Will a RFS mail to debian-devel-games@lists.debian.org be the
correct way to do so ?
>
> Beyond what is required by the Policies etc. (and defacto standards
> where policies are outdated) you and your sponsor decides what are
> *must*, what are *should* and such.
> Also I suspect that you have been reading Neil Williams "Sponsoring
> requirements", since you have been made a -12 and a -13 revision. It is
> entirely possible that your sponsor will want you to merge these two
> into a single -12 entry. But that entirely depends on your sponsor.
I'm sorry, but you are wrong. I just read the requirements on your hint
(thanks a lot, because that's one reason, why I want to get involved
here) and found that similar ideas lead me to the same result.
>
> Regarding the next step: well,
>
> >> >
> >> > 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.
> >
>
> I am fine with you having your own opinion on things like this. Since
> you will be working with the package the most, I would /personally/ be
> okay with keeping these particular 4 small changes directly in the diff.
> As for the unused parts of the rules file. Truly the current rules
> file is functional as it is; also I am perfectly fine with you keeping
> the comments in the file you need/want. If they help you as a
> maintainer, then by all means keep them.
>
> What I do not understand is; why do you want to keep the
> configure{,-stamp} targets? They do nothing but touching a file and
> their existence are not required by the Debian Policy. Why do you leave
> the check for whether the Makefile exist being running $(MAKE) clean?
> The makefile is not removed by its own clean target. This rules file
> look like something geared towards a package using autotools.
>
>
> Finally there is this part, which I asked you to look at:
>
> ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
> CFLAGS += -O0
> else
> CFLAGS += -O2
> endif
>
> I do not see any changes to it, nor to the upstream Makefile. Does this
> work as intended? That is, will
>
> DEB_BUILD_OPTIONS=noopt dpkg-buildpackage
>
> produce an unoptimized package? As I recall I came to the conclusion
> that it probably did not work, but feel free to correct me if I am wrong.
I must admit that make (and automake etc.) are my least familiar tools.
Actually I'm glad, if I can add necessary changes without destroying the
old parts. For I adopted that stuff not knowing what the former
maintainers thought by keeping that code I would stay on the principle
"never change a running system", but if it's a general principle to move
every unneeded thing out of rules and makefile I surely can do those
changes...
About that CFLAGS stuff I don't know, if it's ever needed for debian. I
haven't used it by now, but I think it was (is) intended to use for
debugging purpose (gdb or ddd). I have the idea to change snake4 in the
way not crashing the snake on the borders, but to leave and entering at
the opposite border. When doing this (maybe in the future) I can check,
if I get an not optimised program by setting those option.
>
>
> >> >
> >> > 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.
>
> So, starting with Lintian here. The Lintian warning you saw is about the
> package having a Build-Depends on debhelper 4, when the package said it
> used debhelper 5 features (in debian/compat). Since compat 5 is not
> strictly deprecated, Lintian will not warn about its usage.
>
> As for debhelper in lenny; lenny has 7.0.15 - the version you are seeing
> is debhelper in lenny-backports. There is a difference between the two.
> I am willing to believe that snake4 is an unlikely candidate for
> security or (old-)stable uploads.
> I see no reason why you cannot use debhelper 8 instead of 7 for snake4
> actually. I have just been accustomed to using compat 7, so the new 8
> compat went past me. :)
>
> > [...]
> >
> > Kind regards
> > Michael
> >
> >
>
> If you have any questions to the above, feel free to write back on list.
> If I do not reply within four days (like I failed to do this time), feel
> free to ping me in private as well.
> Else I would recommend you send an RFS to the Games Team. :)
Is debian-devel-games@lists.debian.org correct ? See on top part of my
mail.
Kind regards
Michael
>
> ~Niels
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBCAAGBQJNSeqtAAoJEAVLu599gGRC47IQAJuMLVmr0GRkz3Cxb14mcO3c
> QPIO/dJx0smtZ0J6vX1wteHfH0Fo3Z9avzE2ryu7QgGOtDGwPVLhD9fWq0+Ad3F/
> vus3IrSDmNRbmpRhRR/Ja8URswHt1pF4sA42343DcmUgscNP8I3JSpB4yCPeeQut
> Kfgva7UZmeOgri4gnAuCJL9Kp8XGSKsPWWSaHjI6JdlANAv4/gJuLpHYD8/8DPiA
> lYUBDe+GXB72YU9VrRai8t5MZkoOx0deJaHeJSaM/5mpfBbrraMBT2Kv1qxZ02F8
> ydUELFx/odDmQS8Nv/7zD8qvSjNIG/m1kscOwKvwounf8UBhoE33JdQAOEo1ihAB
> MPBt2YUQSQhTcGxSDWLw2WP/UFkppAvSTil3cB14qkF525wNi261RUGNmG9yPyms
> aRXErM6yGKfNKDSzJvivjeeA40WST3/tUfwoMMIy7UpgyRXwlEZlf+PCoz7mYzIx
> lqQps+gNWDvHIepFAHwx1/FJVPsRiNFV/gmitRpYHF4CTSbljeiGiGkWN5HYXVkA
> mStw6vfxRLpsDMYnKX/cBCE26gIwBV0cvFukkKOD9GeR0daPT7XhId+cIrrRVd1q
> Cae1sw5U16HhrGOudVJHnbly4V38DPKtLy0OUqC1Cpr4fetdreBEYx7atRg08p2x
> zwh2YoYd9QnFIwrFhLb3
> =hWF9
> -----END PGP SIGNATURE-----
Reply to: