Hi.
Le dimanche 05 septembre 2010 à 07:22 +0800, Thomas Goirand a écrit :
> Olivier Berger wrote:
> > It's apparently not a problem most users will be facing AFAICT.
> > Maybe another app's particular environment sets more strict
> > error reporting and is to be changed for stable deployment ?
> >
> > Can you try and explain in which conditions the problem occurs ?
> >
> > What's the content of ini_get('error_reporting'); in your script
>
> I run my cron job with error_reporting(E_ALL); as I don't like hiding
> issues, but care about fixing them.
Fine and perfectly good when it comes to do some testing on packages.
But I fear your requiring too strict reporting for production. After
all, it's just warnings about *future* deprecations [0] !
> It's my (developer) choice to do so,
> and I don't want to change it.
>
OK, but you are supposed to take into consideration that we ultimately
care for regular users of Debian, and not users of a modified version of
Debian ;) If we have to adapt to all kind of choices of many admins,
we're screwed :-(
> > OK, but is this a use case that is standard for most users, or
> > your own problem ?
> > Remember that we have to take into account all users of the
> > package, and
> > some strong annoyances for some are not always applying to most. That
> > said... it may be possible to execute your job with less talkative PHP
> > options, i.e. something like error_reporting = E_ALL & ~E_DEPRECATED
> > for the particular jobs that annoys you.
> >
> > Again, it's a warning, and I'm not sure it's safe to keep deprecation
> > warnings activated by default in stable releases anyway, so
> > your warning
> > may as well go away.
>
> I am not going to continue fighting with you about whether or not this
> issue is serious. Please trust me, it's annoying me, and I don't want to
> have to change the error_reporting. This is a warning about a deprecated
> function of PHP, and should be fixed. Please understand that some
> package that I maintain *are affected* and would produce a mail to root
> each 10 minutes. The issue *is not* in these packages, but in yours.
I agree it's annoying, but I doubt it is reasonable to blame me for your
own choice of changing the Debian reporting defaults in order to produce
more logs, for something that *works* after all (the new is done).
This is an old "dispute" archetype between users and maintainers, so I'm
just arguing although it's quite void...
>
> So I will make it simple, because we have no time to spare before
> Squeeze is released. Either you tell me that you are willing to fix it,
> I can sponsor an upload of the corrected package and ask for a freeze
> exception, either you refuse it and I'll do an NMU to fix this trivial
> one character fix. I have no problems either way, but I got to know.
> More over, I insist that the release manager *will* accept such a
> trivial fix.
>
I'd prefer the second option, you doing an NMU.
BUT first, I have a security bug fix that MUST (that one IS RC for sure)
that should go to unstable for sure (#595248 for which I currently have
a pending request to one member of teh security team for sponsoring my
upload...)
I guess we may arrange to have the two migrate to squeeze altogether.
I'll contact you privately to try and sychronize.
> Thanks to let me know your intentions so that I know what to do.
>
> Thomas
[0] http://www.php.net/manual/en/errorfunc.constants.php
Best regards,
--
Olivier BERGER <olivier.ber...@it-sudparis.eu>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
