[php-maint] php 5.3.1 in experimental

[Ondřej Surý]

On Tue, Jan 12, 2010 at 08:11, Raphael Geissert <geissert at debian.org> wrote:
> 2010/1/11 Ondřej Surý <ondrej at debian.org>:
>>
>> I am all for it. We just need to cherry-pick all changes made to 5.2.x
>> (debian-sid) branch meanwhile, so we don't have regressions.
>>
>
> Ok, since nobody has raised any objection, let's do it.
>
> TODO:
>
> * Merge latest .12 commits into -experimental branch
>
> -> Done on my local repository.

Already done that and 5.3.1-2 contains all relevant changes since we
split the branch. I did some serious cherry picking yesterday. Sorry,
if this breaks your local repository.

> * Shall we enable Enchant?
>
> -> I'd say yes. I've already done it on my local repository, as a
> separate package because it pulls in libenchant, libaspell,
> libhunspell, libvoikko, libdbus, glib, etc.

Yes, separate package.

> * Shall we enable intl?
>
> -> I'd say yes, but am not sure whether it should be done as a
> separate package or not.
> Things to take into consideration: it adds a dependency on, at least,
> libidna, Conflicts (either at dpkg or extensions manager level -- I'd
> prefer to handle it at the latter level) php5-idn. Should probably be
> packaged separately.

Agree, we should not put too many eggs in one basket. We should rather
expect huge amount of bug reports, if they will not come...better for
us.

> * Send "bits from..." mail
>
> -> To mention:
> - Migration to 5.3
> - Deprecation of # comments
> - short_open_tags (see below)
> - switch to extensions manager
> - Invite new contributors? help with the BTS would be a good start.
> - What else? (I'm surely forgetting something)

Switch to automake (>= 1.11)? It can affect packages using php5-dev.

> * Add lintian check for deprecated style of comments in .ini files
>
> -> I can do that.
>
> * Switch to the extensions manager
>
> -> Status:
> - It basically needs a rewrite as the shell scripts are rather fragile.
> - Ship dh_php5ext in php5-dev
> - Announce the switch
>
> * What to do with short_open_tags?
>
> -> Status:
> - The default value in the code is On, but both the development and
> production php.inis default to Off.
> - Many php apps in Debian still use short_open_tags.
>  + But it can now be enabled at runtime, but still requires reporting
> it to the apps that use it.

I think we should enable it back. Correct way would be to report
"deprecated" warning (DEBUG level) to errorlog and disable it only
after some time.

What we can do is to add this to NEWS.Debian/README.Debian for squeezy
and disable short open tags for squeezy+1.

> * Regression test suite-based bug hunting
>
> -> It is a shame that a lot of tests are failing and we are not doing
> much about it. In some cases the tests are broken and need to be
> fixed, but that's not usually the rule. What needs to be done:
> + Go grab the test-results.txt of every supported architecture
> + Get the list of tests that don't fail in all architectures and check
> those first
> + Later check all the remaining failures

That's a nice plan, but we need a fresh meat for that.

> We should additionally start adding extra tests for bugs we encounter
> and upstream didn't add a test for (usually security issues, but not
> exclusively).

Same here.

> * Hardening?
>
> -> I would like to use the hardening-wrapper and enable:
> + DEB_BUILD_HARDENING_STACKPROTECTOR
> + DEB_BUILD_HARDENING_RELRO
> + DEB_BUILD_HARDENING_BINDNOW
> + DEB_BUILD_HARDENING_FORTIFY
> + DEB_BUILD_HARDENING_FORMAT
>
> None of them should cause any trouble and STACKPROTECTOR complements
> suhosin (which works at the Zend memory manager level, not libc's).
> Only the stack protector and bind now options introduce a minor
> performance penalty. The latter should not be a issue as it only
> affects the start of php, and the former is not big deal as suhosin is
> the one introducing the major performance penalty.

Ack.


Ondrej
-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/