[php-maint] php 5.3.1 in experimental

[Raphael Geissert]

Hi Sean,

On 5 February 2010 10:18, sean finney <seanius at debian.org> wrote:
> hi everyone,
>
> On Fri, Feb 05, 2010 at 09:42:33AM -0600, Raphael Geissert wrote:
>> I did that more than a week before. At the moment we must wait for the
>> RT to give us the green light before uploading to sid as it is
>> considered a transition (the phpapi was bumped and needs binNMUs) and
>> the buildds are overloaded.
>
> is there anything missing from our end on this?  otherwise i say we get
> pretty aggressive about pushing this as i absolutely do not want to get
> stuck with having 5.2.x in squeeze.

I've continuously been prodding the RT. The python transition lead to
a lot of binNMUs and there's still a second round waiting for some of
the buildds to catch up (that and mips* has a huge queue and one of
the buildds is being shut down during the weekend, plus the two ia64
buildds and one hppa buildd being shut down for data centre
maintenance.)

And no, I won't let them keep us with 5.2 in squeeze.

>
>> I was thinking maybe we should upload one more version to experimental
>> and send the "bits from" email so that people start using it. What do
>> you think?
>
> I say skip this step, as we've had 5.3 in experimental for quite a while
> already and people have had their chance to object

Yes, but at least would fix some bugs and pass the NEW trip. Given
that the experimental buildds are others, it shouldn't be a problem
for the load either.

It is also good that we have working packages instead of ones that
fail because we are pointing ucf to the old php.ini-dist
.
>
>> I also wanted to discuss, again, the changes to php.ini. At the moment
>> you added code to debian/rules to change the short_open_tag setting
>> but maybe we should not modify any of the settings for now.
>
> ideally i'd like to stick with upstream on this and have it disabled
> by default, but at this point in the release cycle i suspect this change
> would be just as disruptive (if not more) than the version/abi bump.  and
> more importantly any errors that it introduces would not be immediately
> detected and would probably take a while to trickle their way to us.
>
> debian packages and deployed apps/websites that require short_open_tag
> to be off already have the setting because otherwise they'd be broken,
> so keeping the setting as is doesn't break anything.  changing the
> setting will probably break some packages (which we could probably do
> something to find/fix) and deployed apps/sites (which we couldn't completely
> find/fix).  i'd rather have to deal with something like that at the beginning
> of a release cycle rather than just before a freeze.

Ok.

>
>> The problem is that applications need to be fixed either way, because
>> sooner or later that's going to be the default. I also noticed I
>> forgot to mention the JIT setting, which might silently break some
>> routines of a couple of applications.
>
> which setting is that.. auto_globals_jit?
>

Yes. Accessing super global variables via variable variables before
they are directly accessed doesn't work. I.e. code such as the
following won't do anything at all:

$globals = array('_GET', '_POST', '_COOKIE');
foreach ($globals as $global) {
  foreach ($$global as $k=>$v) {
    //doing something nasty with the variables...
  }
}

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net