On Mon, Feb 6, 2012 at 12:00, Niels Thykier <ni...@thykier.net> wrote:
> On 2012-02-06 10:32, Ondřej Surý wrote:
>> Hi Niels,
>>
>> On Mon, Feb 6, 2012 at 10:20, Niels Thykier <ni...@thykier.net> wrote:
>>> On 2012-01-23 22:41, Raphael Geissert wrote:
>>>> Package: release.debian.org
>>>> Severity: normal
>>>> User: release.debian....@packages.debian.org
>>>> Usertags: transition
>>>>
>>>> Hi,
>>>>
>>>> [...]
>>>>
>>>> Cheers,
>>>
>>> Hi Raphael and Ondrej,
>>>
>>> Sorry for not getting back to you sooner. So first off, thanks for
>>> filing the bugs at [1] and getting the first half of that solved before
>>> we start. :)
>>>
>>> We have some concerns with this transition, but hopefully you got these
>>> parts covered. As you announced in [2] the changes to php5 will break
>>> packages. It is our understanding that most packages containing php are
>>> not compiled during "build". If so, we could look at potentially a lot
>>> of packages that will break on user systems.
>>>
>>> Do you have any strategies for checking the php packages in the archive
>>> for potential issues?
>>
>> I'll do a second round (and thanks to a Raphael for first one) and look for
>> potentially broken PHP code in our packages. The fact is that those features
>> were marked as obsolete in PHP 5.3 and those maintainers have been
>> warned, but still PHP code has big momentum.
>>
>
> Thanks, that is greatly appreciated.
Ok, I have checked all packages which depends on php5 and:
1. there are some binary packages which will need transition tracker:
Affected: .build-depends ~ /php5-dev/
Good: .depends ~ /phpapi-20100525/ # this will get fixed in next upload
Bad: .depends ~ /phpapi-20090626/
2. The rest either don't care or have specific code to:
a) say that the system or its parts won't work with safe_mode
b) circumvent enabled register_globals
So I would say we are pretty safe on this front. PHP scripts still could
break in every possible way, but I don't think we would be able to detect
that easily.
The next test (php lint) has showed some fatal errors (which should be
easy to fix).
>> I also have thought about adding couple of lintian checks which will test
>> if the code contains obsolete/removed PHP features.
>>
>
> A good idea, though next time please have them in Lintian before the
> transition is about to start. Even with an upload today + update of
> lintian.d.o the results are at least 3-4 days away.
After poking the PHP scripts around with grep, I have realized that
there's no sane way how to test these two (safe_mode and register_globals).
Also no sane person would use these two features on his server.
As for php lint - I think same apply for lintian - you need to have latest
php-cli installed for the test and lintian probably doesn't want to drag
that around.
Long term solution would be to incorporate such tests to pkg-php-tools.
>>> I had a look at the thread in [3] and I could not
>>> find anything (except what I suspect are now the bugs listed in [1]).
>>> If I have missed them please let me know.
>>
>> Well, we need to check if the packages like drupal, horde, etc. works
>> with PHP 5.4.
>>
>
> Okay, we are looking forward to results. :)
The results of safe_mode & register_globals grep is:
1 OK: binary package
1 OK: but broken by sqlite.so removal (already done)
1 SKIP: php-auth-pam dependency broken atm
1 SKIP: throws some errors in postinst due unreachable pgsql
34 SKIP: binary package
223 OK
The results of php5 -l (php link) is:
PHP Fatal error: Call-time pass-by-reference has been removed
dotclear
d-push
horde3
jffnms
moodle
php-horde-auth
php-kolab-filter
php-net-ldap2
php-openid
phpreports
simplesamlphp
zoph
I am mass filling bugs for these packages (this feature has been deprecated
since php 5.3 anyway).
>>> Finally, while I admit we have to improve our reply-time, we would
>>> appreciate if you would avoid "self-acking" your transitions on d-d-a.
>>
>> Sorry for that. I never know how to proceed and I really wanted to send
>> the heads-up before it's too late.
>>
>
> The heads-up was a good idea. The problem was you expressed yourself as
> if you had already received a go from us (example [1]).
Ah, I understand that you might had impression that I was going to upload
to unstable without d-r team ACK... This was not my intent, it was merely
just a way how to make people really look at the mail. (Saying "it might happen"
will only make them think - I'll check when it's ready.)
O.
--
Ondřej Surý <ond...@sury.org>
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CALjhHG8X4z=_GG7yXQA=v+m+tjur7zsfhmy-updrybprxdl...@mail.gmail.com
