FPM в официальном SVN
Antony Dovgal
Я добавил FPM в официальный SVN-репозиторий PHP в виде отдельного SAPI.
Специально для этого был создан новый бранч - PHP_5_3_FPM, который базируется на PHP_5_3.
Забрать из SVN можно следующим образом:
svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm
Собирать следующим образом:
./configure --enable-fpm
Если libevent стоит где-то в нестандартном пути, то добавьте:
--with-libevent-dir=<libevent prefix>
Остально всё как обычно.
Пока оно находится на стадии "собирается и запускается без ошибок", особого тестирования не было.
Поэтому большая просьба к вам - погоняйте и скажите что не так, я исправлю.
Цель всего этого - довести FPM до полностью рабочего состояния и где-то в районе
5.3.3/5.3.4 включить в официальную поставку.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
Konstantin Belov
Khazret Sapenov
sta...@newmail.ru
хм, это что означает что группа азработчиков признала этот патч?
Alexey A. Rybak
>
> Здравствуйте.
>
> хм, это что означает что группа азработчиков признала этот патч?
у ситуации вокруг проекта есть несколько возможных продолжений и то,
что делает тони - похоже, самый лучший для комьюнити и для проекта в
целом. дримкет в курсе и уже прислал обновления для этого бранча.
те, кто в танке могут перечитать письмо дримкэта на этот лист, которое
было отправлено примерно 10 дней назад, где он пишет, что вы, де,
русские, сплошь сишники, давайте становитесь мейнтенерами, а то у нас
совсем тут голяк.
--
wbr,
fisher
sta...@newmail.ru
Видел я то письмо.
Просто непонятно как то, патч попадает в оф репозиторий и в то же
время ведется разработка сторонними разработчиками.
Честно говоря удивило что он туда вообще попал. Но, с другой строны и
порадовало - может доработают наконец до чего то стабильного и
удобного.
Я увы не сишник. Так что мне остается только наблюдать.
Alexey Romanenko
2009/12/3 <sta...@newmail.ru>:
--
------
Wbr, Alexey
Alexey A. Rybak
>
> Здравствуйте.
>
> Видел я то письмо.
> Просто непонятно как то, патч попадает в оф репозиторий и в то же
> время ведется разработка сторонними разработчиками.
она почти не ведется
--
wbr,
fisher
Antony Dovgal
> Спасибо, Антоний!
> Обязательно попробуем.
> Отзывы, как я понял, можно кидать в эту ветку?
Конечно.
Как говорится, "комменты читаю".
Antony Dovgal
> Здравствуйте.
>
> хм, это что означает что группа азработчиков признала этот патч?
Вы о какой группе разработчиков говорите?
FPM? PHP?
Antony Dovgal
> Здравствуйте.
>
> Видел я то письмо.
> Просто непонятно как то, патч попадает в оф репозиторий и в то же
> время ведется разработка сторонними разработчиками.
Как только что-то принимается в офиц. репозиторий, разработчики
автоматически перестают быть сторонними =)
si
> порадовало - может доработают наконец до чего то стабильного и
sta...@newmail.ru
почему то при большом количестве fopen пул виснет
выяснять что там не так увы времени нету
sta...@newmail.ru
признала о официальной
разрабатывает о неофициальной
может я конечно чего то не знаю но в оф репу с улицы же не пустят
Kayo Ayanami
--
-------------------------------------------------------------
Kayo Ayanami
jabber: ka...@jabber.ru
gtalk-xmpp: kayo....@gmail.com
ya-xmpp: kayo-...@ya.ru
sourceforge: phoe...@users.sf.net
luaforge: phoe...@users.luaforge.net
Antony Dovgal
> Здравствуйте.
>
> признала о официальной
> разрабатывает о неофициальной
> может я конечно чего то не знаю но в оф репу с улицы же не пустят
Проблема в том, что разработчиков как таковых нет.
Андрею больше не интересно, dreamcat4 сказал, что "он свою работу закончил" (с),
больше никого из разработчиков я не знаю.
Поэтому некая "неофициальная группа разработчиков" - это на данный момент я,
как это не прискорбно.
А меня пускать в офиц. репозиторий не надо, я там и так есть =)
Alexey A. Rybak
> как это не прискорбно.
> А меня пускать в офиц. репозиторий не надо, я там и так есть =)
давай чтобы не создавать ложной паники поясним
- дримкет действительно собирается прекратить работу над проектом. но
он никуда не пропадает, щас помогает, по-моему, вот обновления к сапи
прислал.
- в сентябре майкл с дримкетом сделали попытку предложить пхп-тим
заняться фпм, типа вот у нас такой есть фпм, он уже сапи, не хотите ли
его себе. вообще предложение было довольно странное по форме по-моему,
ну и пхп тим как-то вяло отреагировал, типа ну можно подумать. да и их
можно понять - народ занятой и вряд ли кто станет мейнтернером и будет
заниматься интеграцией и всем гемором с поддержкой
- это была не первая попытка - но раньше пхп-тим просто офигевал от
закидонов фпм типа bundled libevent - щас ничего этого нет, ничего
начать интеграцию не мешает, и в этом огромная заслуга дримкета.
- сейчас самое лучшее время добавить фпм в официальный дистрибутив -
со временем уйдут все грабли со сборкой, отдельными пакетами. тони -
член пхп-тим уже черт значит скока лет.
- что будет с проектом дальше - покажет время. но по-моему будет
лучше, если в момент "безотцовщины" он окажется в репозитории пхп.
--
wbr,
fisher
sta...@newmail.ru
> А меня пускать в офиц. репозиторий не надо, я там и так есть
т.е. теоретически ты можешь туда положить любой софт?
предполагаю, что такое право тебе не за красивые глаза дали
sta...@newmail.ru
мм я давно не слежу за командой пхп
но как помню там давно ушел идейный вдохновитель всего и вся в пыхе
был бы он может и фпм уже был в оф составе
все таки возможность выноса обработчика на отедльный сервер - это много стоит
кстати, Алексей надеюсь и блитц таким станет)
а вообще все что делается - к лучшему, и в нынешнем виде фпм хорошая
штука.
Antony Dovgal
> Здравствуйте.
>
> мм я давно не слежу за командой пхп
> но как помню там давно ушел идейный вдохновитель всего и вся в пыхе
Что-то вы путаете.
> был бы он может и фпм уже был в оф составе
Причем тут Расмус?
sta...@newmail.ru
я давно не слежу за командой пхп
может что то и путаю
si
> почему то при большом количестве fopen пул виснет
> выяснять что там не так увы времени нету
sta...@newmail.ru
>> почему то при большом количестве fopen пул виснет
>> выяснять что там не так увы времени нету
> за вас никто ваши проблемы решать не будет
ошибки которые возникали при этом в логе появлялись не только у меня
значит есть еще что то, в любом случае я там отключил фпм и
перевел на fcgi
так что эта тема уже закрыта, сейчас мне это уже не интересно
Alex Samorukov
Если бы был повторяемый багрепорт я бы мог попытаться разобраться.
sta...@newmail.ru
ничего странного
эта ситуация проявилась у одного пула из ста
ввести фпм в продакшен была моя идея, я же могу и отказаться
к томуже у людей есть динамическая возможность прыгать с фмп на фцги и
обратно, что и было сделано
а разбираться мне пока некогда, есть другие задачи боле важные
Alex Samorukov
> Здравствуйте.
>
> ничего странного
> эта ситуация проявилась у одного пула из ста
> ввести фпм в продакшен была моя идея, я же могу и отказаться
> к томуже у людей есть динамическая возможность прыгать с фмп на фцги и
> обратно, что и было сделано
>
> а разбираться мне пока некогда, есть другие задачи боле важные
>
OpenSource. Я стараюсь как минимум оставить баг репорт для
разработчиков, с максимумом полезной информации. А так - баг никогда и
не будет пофикшен.
jahson
> Привет!
>
> Я добавил FPM в официальный SVN-репозиторий PHP в виде отдельного SAPI.
> Специально для этого был создан новый бранч - PHP_5_3_FPM, который базируется на PHP_5_3.
>
> Забрать из SVN можно следующим образом:
> svn cohttp://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPMphp_5_3_fpm
>
> Собирать следующим образом:
> ./configure --enable-fpm
>
> Если libevent стоит где-то в нестандартном пути, то добавьте:
> --with-libevent-dir=<libevent prefix>
>
> Остально всё как обычно.
>
> Пока оно находится на стадии "собирается и запускается без ошибок", особого тестирования не было.
> Поэтому большая просьба к вам - погоняйте и скажите что не так, я исправлю.
>
> Цель всего этого - довести FPM до полностью рабочего состояния и где-то в районе
> 5.3.3/5.3.4 включить в официальную поставку.
Собрал на osx 10.5.8, всё работает, но основной лог стал со скоростью
света наполняться повторяющимися наборами записей вида
Dec 05 21:49:02.526089 [NOTICE] fpm_php_trace(), line 170: finished
trace of 859
Dec 05 21:49:02.526130 [NOTICE] fpm_children_bury(), line 209: child
858 stopped for tracing
Dec 05 21:49:02.526139 [NOTICE] fpm_php_trace(), line 142: about to
trace 858
Dec 05 21:49:02.526441 [NOTICE] fpm_php_trace(), line 170: finished
trace of 858
Dec 05 21:49:02.526481 [NOTICE] fpm_children_bury(), line 209: child
856 stopped for tracing
Dec 05 21:49:02.526490 [NOTICE] fpm_php_trace(), line 142: about to
trace 856
Dec 05 21:49:02.526796 [NOTICE] fpm_php_trace(), line 170: finished
trace of 856
Dec 05 21:49:02.526906 [NOTICE] fpm_got_signal(), line 48: received
SIGCHLD
Dec 05 21:49:02.526942 [NOTICE] fpm_got_signal(), line 48: received
SIGCHLD
Dec 05 21:48:40.111291 [WARNING] fpm_request_check_timed_out(), line
135: child 870, script '/Users/jahson/www/project/branch/new/web/
index.php' (pool default) executing too slow (2803.190743 sec),
logging
Dec 05 21:48:40.111637 [WARNING] fpm_request_check_timed_out(), line
135: child 859, script '/Users/jahson/www/project/branch/new/web/
info.php' (pool default) executing too slow (2803.190743 sec), logging
index.php - индекс symfony (он ещё на что-то ругается в slowlog - в
виде бэктрейса, видимо из-за нового пхп), а info.php - просто phpinfo
(). В дальнейшем использовал только info.php.
Ясно, что 2803 секунды (порядка 45 минут) никто не выполняется - всё
достаточно быстро бегает. slowlog забивается записями вида
Dec 05 21:53:46.119609 pid 860 (pool default)
script_filename =·
Dec 05 21:53:46.119944 pid 859 (pool default)
script_filename =·
Dec 05 21:53:46.120249 pid 858 (pool default)
script_filename =·
Dec 05 21:53:46.120673 pid 856 (pool default)
script_filename =·
Покопался, сколько мог и вот что выкопал - основное действо происходит
в ветке, которая начинается со 128 строки файла fpm_request.c. При
этом ветка, начинающаяся со 112 строки не выполняется - это я проверил
для того, чтобы быть уверенным в данных лога. Дальше я добавил
135 zlog(ZLOG_STUFF, ZLOG_WARNING, "child-
>slow_logged: %d.%06d", (int) child->slow_logged.tv_sec, (int) child-
>slow_logged.tv_usec);
136 zlog(ZLOG_STUFF, ZLOG_WARNING, "child-
>slow_logged.tv_sec: %d", (int) child->slow_logged.tv_sec);
137 zlog(ZLOG_STUFF, ZLOG_WARNING, "child-
>slow_logged.tv_usec: %06d", (int) child->slow_logged.tv_usec);
138
139 zlog(ZLOG_STUFF, ZLOG_WARNING, "slot_c.accepted:
%d.%06d", (int) slot_c.accepted.tv_sec, (int)
slot_c.accepted.tv_usec);
140 zlog(ZLOG_STUFF, ZLOG_WARNING,
"slot_c.accepted.tv_sec: %d", (int) slot_c.accepted.tv_sec);
141 zlog(ZLOG_STUFF, ZLOG_WARNING,
"slot_c.accepted.tv_usec: %06d", (int) slot_c.accepted.tv_usec);
142
143 zlog(ZLOG_STUFF, ZLOG_WARNING, "tv: %d.%06d",
(int) tv.tv_sec, (int) tv.tv_usec);
144 zlog(ZLOG_STUFF, ZLOG_WARNING, "tv.tv_sec: %d",
(int) tv.tv_sec);
145 zlog(ZLOG_STUFF, ZLOG_WARNING, "tv.tv_usec: %06d",
(int) tv.tv_usec);
и они начали мне писать
23 Dec 05 22:58:49.765229 [WARNING] fpm_request_check_timed_out
(), line 135: child->slow_logged: 0.000000
24 Dec 05 22:58:49.765256 [WARNING] fpm_request_check_timed_out
(), line 136: child->slow_logged.tv_sec: 0
25 Dec 05 22:58:49.765265 [WARNING] fpm_request_check_timed_out
(), line 137: child->slow_logged.tv_usec: 000000
26 Dec 05 22:58:49.765273 [WARNING] fpm_request_check_timed_out
(), line 139: slot_c.accepted: 0.000000
27 Dec 05 22:58:49.765281 [WARNING] fpm_request_check_timed_out
(), line 140: slot_c.accepted.tv_sec: 0
28 Dec 05 22:58:49.765288 [WARNING] fpm_request_check_timed_out
(), line 141: slot_c.accepted.tv_usec: 000000
29 Dec 05 22:58:49.765296 [WARNING] fpm_request_check_timed_out
(), line 143: tv: 7012.775979
30 Dec 05 22:58:49.765304 [WARNING] fpm_request_check_timed_out
(), line 144: tv.tv_sec: 7012
31 Dec 05 22:58:49.765312 [WARNING] fpm_request_check_timed_out
(), line 145: tv.tv_usec: 775979
Хотя я и живу в России, мой навык в C оставляет желать лучшего :),
поэтому выводов сделать не могу - кроме одного: откуда-то берётся
неправильное время. Отдебажить как-то иначе пока тоже не получилось -
c gdb только учусь обращаться - и поставив брейкпоинт на вызов
fpm_request_check_timed_out у фэйлящего чайлда, я к сожалению ничего
не получил в ответ (но в данном случае я склонен обвинять руки).
Если отключить slowlog - то никто не ругается, ваш КО.
Да, заметил только во время очередной пересборки - "Installing PHP FPM
config: NONE/etc/"
[22:56:52] /Users/jahson/repositories/svn/php_5_3_fpm $ sudo make -j
install
Installing PEAR environment: /usr/local/lib/php/
Installing helper programs: /usr/local/bin/
program: phpize
Installing PDO headers: /usr/local/include/php/ext/pdo/
program: php-config
Installing man pages: /usr/local/man/man1/
page: phpize.1
[PEAR] Archive_Tar - already installed: 1.3.3
Installing PHP SAPI module: fpm
[PEAR] Console_Getopt - already installed: 1.2.3
Installing PHP CLI binary: /usr/local/bin/
Installing PHP FPM binary: /usr/local/bin/
/Users/jahson/repositories/svn/php_5_3_fpm/build/shtool install -c ext/
phar/phar.phar /usr/local/bin
page: php-config.1
[PEAR] Structures_Graph- already installed: 1.0.3
[PEAR] XML_Util - already installed: 1.2.1
ln -s -f /usr/local/bin/phar.phar /usr/local/bin/phar
Installing PHP CLI man page: /usr/local/man/man1/
[PEAR] PEAR - already installed: 1.9.0
Warning! a PEAR user config file already exists from a previous PEAR
installation at '/Users/jahson/.pearrc'. You may probably want to
remove it.
Wrote PEAR system config file at: /usr/local/etc/pear.conf
You may want to add: /usr/local/lib/php to your php.ini include_path
Installing PHP FPM config: NONE/etc/
Installing PHP FPM man page: /usr/local/man/man1/
Installing build environment: /usr/local/lib/php/build/
Installing header files: /usr/local/include/php/
fixxxer
> On 2 дек, 23:13, Antony Dovgal <t...@daylessday.org> wrote:
> Собрал на osx 10.5.8, всё работает, но основной лог стал со скоростью
> света наполняться повторяющимися наборами записей вида
> Dec 05 21:49:02.526089 [NOTICE] fpm_php_trace(), line 170: finished
> trace of 859
Оххх, как, оказывается, все запущено в этом 0.6.
Патч: http://symbi.org/misc/php_5_3_fpm_lost_request_phases.patch
С сингалами - я не воткнул, в каких случаях таки надо делать
безусловный exit по sigterm - так что пускай пока делает всегда...
лучше, чем игнорировать, по крайней мере, а дальше надо смотреть. Ну и
еще конечно реакция на sighup неадекватная (кстати, оно так и было,
или это тоже нововведение?).
Я, короче, не понимаю, о каких там портах и пакетах шли в -en
рассуждения все это время. Оно тупо не работает, какие пакеты :)
P.S. vodka, balalaika, perestroika, C language!
fixxxer
> Оххх, как, оказывается, все запущено в этом 0.6.
>
> Патч:http://symbi.org/misc/php_5_3_fpm_lost_request_phases.patch
>
> С сингалами - я не воткнул, в каких случаях таки надо делать
> безусловный exit по sigterm - так что пускай пока делает всегда...
> лучше, чем игнорировать, по крайней мере, а дальше надо смотреть. Ну и
> еще конечно реакция на sighup неадекватная (кстати, оно так и было,
> или это тоже нововведение?).
И, да, весь этот прыг-скок из fastcgi.c в fpm_* с выделением в
отдельный sapi как то совсем неактуален. Отрефакторить бы это дело,
заодно и разобраться, как работает.
В общем, если из настоящих сварщиков совсем некому, я попробую, но
ничего не обещаю =)
Еще конфиг бы переделать, я видел не одного и не двух админов, которым
резко плохеет от xml-я =) Может, libconfuse? Хотя, лишняя
зависимость...
jahson
> Оххх, как, оказывается, все запущено в этом 0.6.
>
> Патч:http://symbi.org/misc/php_5_3_fpm_lost_request_phases.patch
>
> С сингалами - я не воткнул, в каких случаях таки надо делать
> безусловный exit по sigterm - так что пускай пока делает всегда...
> лучше, чем игнорировать, по крайней мере, а дальше надо смотреть. Ну и
> еще конечно реакция на sighup неадекватная (кстати, оно так и было,
> или это тоже нововведение?).
>
> Я, короче, не понимаю, о каких там портах и пакетах шли в -en
> рассуждения все это время. Оно тупо не работает, какие пакеты :)
>
> P.S. vodka, balalaika, perestroika, C language!
Как я понял, он предлагает завершить приём запросов, но при этом
обработать уже принятые - и только потом выходить.
Sergey Kobzar
> И, да, весь этот прыг-скок из fastcgi.c в fpm_* с выделением в
> отдельный sapi как то совсем неактуален. Отрефакторить бы это дело,
> заодно и разобраться, как работает.
:)
> В общем, если из настоящих сварщиков совсем некому, я попробую, но
> ничего не обещаю =)
> Еще конфиг бы переделать, я видел не одного и не двух админов, которым
> резко плохеет от xml-я =) Может, libconfuse? Хотя, лишняя
> зависимость...
Не то, чтобы совсем плохеет, но немного неудобно.
Естественно хочется иметь конфиги c-style более свойственные
unix-системам.
--
Sergey
sta...@newmail.ru
лог я приводил
а дебажить я не умею
так что все что мог я дал
Antony Dovgal
> И, да, весь этот прыг-скок из fastcgi.c в fpm_* с выделением в
> отдельный sapi как то совсем неактуален. Отрефакторить бы это дело,
> заодно и разобраться, как работает.
You're always welcome.
> В общем, если из настоящих сварщиков совсем некому, я попробую, но
> ничего не обещаю =)
Некому, некому.
У меня не 6 рук.
> Еще конфиг бы переделать, я видел не одного и не двух админов, которым
> резко плохеет от xml-я =) Может, libconfuse? Хотя, лишняя
> зависимость...
Это последняя проблема, которая должна вас сейчас волновать.
Эта часть кода работает нормально, никаких проблем там нет, поэтому трогать её не надо.
Религиозные чувства и персональные предпочтения можно отложить на время.
Antony Dovgal
> Оххх, как, оказывается, все запущено в этом 0.6.
Здесь надо учитывать, что в 0.6 изначально cgi_main.c и fastcgi.c шли аж из 4-ки.
Поэтому я ручками проапдейтил их до более-менее свежей версии.
Ну и по пути, конечно, сломал всё =) Так что, это не 0.6, эт всё я.
> Патч: http://symbi.org/misc/php_5_3_fpm_lost_request_phases.patch
Спасибо, Фиксер.
Приложил патч, кроме первой его части.
> С сингалами - я не воткнул, в каких случаях таки надо делать
> безусловный exit по sigterm - так что пускай пока делает всегда...
> лучше, чем игнорировать, по крайней мере, а дальше надо смотреть.
Я бы пока не спешил с такими патчами.
Там есть еще куча кода на libevent, которая тоже занимается обработкой сигналов,
и у меня есть впечатоление, что код в fastcgi.c просто мертвый и его надо дропнуть.
> Ну и
> еще конечно реакция на sighup неадекватная (кстати, оно так и было,
> или это тоже нововведение?).
А? См. выше.
Antony Dovgal
> Собрал на osx 10.5.8
Вы только там можете протестировать?
> , всё работает, но основной лог стал со скоростью
> света наполняться повторяющимися наборами записей вида
> Dec 05 21:49:02.526089 [NOTICE] fpm_php_trace(), line 170: finished
> trace of 859
Возможно, вам стоит сделать log_level не notice, а warning?
Так, конечно, вы видите все возможные нотисы.
> index.php - индекс symfony (он ещё на что-то ругается в slowlog - в
> виде бэктрейса, видимо из-за нового пхп), а info.php - просто phpinfo
> (). В дальнейшем использовал только info.php.
>
> Ясно, что 2803 секунды (порядка 45 минут) никто не выполняется - всё
> достаточно быстро бегает. slowlog забивается записями вида
> Dec 05 21:53:46.119609 pid 860 (pool default)
> script_filename =·
Окей, принял к сведению.
> и вот что выкопал - основное действо происходит
> в ветке, которая начинается со 128 строки файла fpm_request.c.
Сделайте svn up, плз, что-то я полностью запутался в номерах строк.
> Если отключить slowlog - то никто не ругается, ваш КО.
Понял, до туда я еще не дошел.
Включу и посмотрю, спасибо.
> Да, заметил только во время очередной пересборки - "Installing PHP FPM
> config: NONE/etc/"
Ага, я как раз это долго правил, всё должно исправиться с помощью `svn up && rm configure && ./buildconf && ./config.nice && make`
fixxxer
С сигналами это первый пришедший в голову workaround, щас уже вижу,
что многий код из fastcgi.c не нужен, и надо вернуть все старые патчи
и почикать мертвое. Попробую разгрести, там, похоже, из оригинального
cgi/fcgi sapi надо и не так много.
Antony Dovgal
> Ага, понял. :)
>
> С сигналами это первый пришедший в голову workaround, щас уже вижу,
> что многий код из fastcgi.c не нужен, и надо вернуть все старые патчи
> и почикать мертвое. Попробую разгрести, там, похоже, из оригинального
> cgi/fcgi sapi надо и не так много.
Вот-вот.
Поэтому оно просто напрашивается на чистку.
fixxxer
> > и почикать мертвое. Попробую разгрести, там, похоже, из оригинального
> > cgi/fcgi sapi надо и не так много.
>
> Вот-вот.
> Поэтому оно просто напрашивается на чистку.
Вот такое бы потестить:
http://symbi.org/misc/php_5_3_fpm_sapi_cleanup.patch
(Патч кумулятивный, предыдущее в себя включает).
Зачистил более-менее, починил обработку сигналов (и добавил для
мастера HUP = USR2, ибо, ятд, негоже по sighup-у тупо вываливаться).
Заодно ужаснулся и не смог не переписать init_request_info() - так что
надо особенно потестить, что я ничего не сломал. (Заведомо совсем
кривые конфигурации "сломал", конечно, но на таком вряд ли fpm
запускают). В комментариях там пояснил свою позицию =)
fixxxer
> http://symbi.org/misc/php_5_3_fpm_sapi_cleanup.patch
> (Патч кумулятивный, предыдущее в себя включает).
Обновил. Патч на ревизию 291811:
fixxxer
>
> > Да, заметил только во время очередной пересборки - "Installing PHP FPM
> > config: NONE/etc/"
>
> Ага, я как раз это долго правил, всё должно исправиться с помощью `svn up && rm configure && ./buildconf && ./config.nice && make`
Не-а, так и осталось. Проверил на FreeBSD и Linux.
И еще phpize в итоге странно сломался - любой сгенеренный им configure
обламывается на таком:
checking for ld used by gcc... ./configure: s%\\%/%g: not found
no
configure: error: no acceptable ld found in $PATH
jahson
> On 05.12.2009 18:28, jahson wrote:
>
> > Собрал на osx 10.5.8
>
> Вы только там можете протестировать?
Это просто то, что всё время под рукой. В принципе могу проверить на
линуксе или фре - но Фиксер уже успел это сделать )
> > , всё работает, но основной лог стал со скоростью
> > света наполняться повторяющимися наборами записей вида
> > Dec 05 21:49:02.526089 [NOTICE] fpm_php_trace(), line 170: finished
> > trace of 859
>
> Возможно, вам стоит сделать log_level не notice, а warning?
> Так, конечно, вы видите все возможные нотисы.
Основной смысл, конечно, был не в нотисах, а в скорости наполнения.
> > и вот что выкопал - основное действо происходит
> > в ветке, которая начинается со 128 строки файла fpm_request.c.
>
> Сделайте svn up, плз, что-то я полностью запутался в номерах строк.
Ну от svn up номера строк там не изменились - только в итоге проблема
не там, насколько я понимаю.
> > Да, заметил только во время очередной пересборки - "Installing PHP FPM
> > config: NONE/etc/"
>
> Ага, я как раз это долго правил, всё должно исправиться с помощью `svn up && rm configure && ./buildconf && ./config.nice && make`
Всё так же и осталось.
Antony Dovgal
>> Ага, я как раз это долго правил, всё должно исправиться с помощью `svn up && rm configure && ./buildconf && ./config.nice && make`
>
> Не-а, так и осталось. Проверил на FreeBSD и Linux.
И еще раз пробуй, плз.
Должно исправиться.
> И еще phpize в итоге странно сломался - любой сгенеренный им configure
> обламывается на таком:
>
> checking for ld used by gcc... ./configure: s%\\%/%g: not found
> no
> configure: error: no acceptable ld found in $PATH
# phpize
Configuring for:
PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626
Работает. По крайней мере, после моих сегодняшних апдейтов у меня на Линуксе.
jahson
Antony Dovgal
> После недавнего апдейта NONE исчезло, спасибо.
Отлично, спасибо.
А массовые нотисы и слоулог исправились после патча Фиксера?
Antony Dovgal
Фикс, тут речи ведутся о том, что добавить поддержку Win32 в FPM должно быть не очень сложно (учитывая, что libevent работает на винде).
Поэтому я бы не стал радикально удалять из кода всё, что касается винды. По крайней мере, сейчас.
Мне, конечно, сложно представить кому и зачем оно может быть нужно,
но мало ли - может, найдётся какой-нить доброволец, который займется этим.
Andrei Nigmatulin
Уже были успешные попытки -
http://www.softwareprojects.com/resources/programming/t-how-to-install-nginx-php-php-fpm-and-mysql-under-1616.html
--
Andrei Nigmatulin
GPG PUB KEY 6449830D
Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take
Александр Лозовюк
--
C уважением, Александр Лозовюк
Alpha-Beta-Release Blog
http://abrdev.com
jahson
> А массовые нотисы и слоулог исправились после патча Фиксера?
Включил слоулог - он молчит на тех же файлах. Для проверки сделал в
info.php sleep(6); (<value name="request_slowlog_timeout">5s</value>)
- отрапортовало нормально.
fixxxer
> On 08.12.2009 06:03, fixxxer wrote:
>
> > On 8 дек, 05:57, fixxxer <fixxxe...@gmail.com> wrote:
> >>http://symbi.org/misc/php_5_3_fpm_sapi_cleanup.patch
> >> (Патч кумулятивный, предыдущее в себя включает).
>
> > Обновил. Патч на ревизию 291811:
>
> >http://symbi.org/misc/php_5_3_fpm_sapi_cleanup_UPD.patch
>
> Фикс, тут речи ведутся о том, что добавить поддержку Win32 в FPM должно быть не очень сложно (учитывая, что libevent работает на винде).
> Поэтому я бы не стал радикально удалять из кода всё, что касается винды. По крайней мере, сейчас.
>
Честно говоря, win32 код резал просто потому, что без него исходники
сразу понятнее в сто раз =)
Тут надо понимать цель fpm - это sapi для высоконагруженных систем.
Протестировать что-либо под виндой можно и обычным php-cgi -b, а
запускать что-то в производстве на cygwin или виндовом кастрате
селекта - это в лучшем случае баловство. О какой то производительности
и надежности тут даже заикаться смешно.
Производительное же решение для Win32 должно делаться на тредах и i/o
completion ports. Попытки добавить i/o c.p. в libevent были <http://
www.mail-archive.com/libeven...@monkey.org/msg01160.html>, но я не
очень понимаю, чем это все закончилось - и, если честно, вообще это
себе с трудом представляю - уж шибко архитектурные подходы разные. Но
если кто-то с виндой может проверить и убедиться, что либевент с вот
теми вот патчами работает в достаточных для fpm объемах - то почему бы
и нет.
Antony Dovgal
> Это надо для разворачивания тестового сервера на машинах разработчиков.
Не понял. Вы о чем?
fixxxer
wrote:
>
> Уже были успешные попытки -http://www.softwareprojects.com/resources/programming/t-how-to-instal...
>
Дык то cygwin. Там куски с #idfef win32 и не нужны.
Oleg Roschupkin
checking for ld used by gcc... ./configure: line 2601: s%\\%/%g: No
such file or directory
no
configure: error: no acceptable ld found in $PATH
--
Yours, Oleg Roschupkin
jja...@gmail.com
Oleg Roschupkin
Antony Dovgal
> phpize работает так же, как и у Фиксера:
>
> checking for ld used by gcc... ./configure: line 2601: s%\\%/%g: No
> such file or directory
> no
> configure: error: no acceptable ld found in $PATH
>
autoconf какой версии?
А без FPM всё точно так же? (снапшоты тут: http://snaps.php.net/)
Antony Dovgal
Супер.
Спасибо Фиксеру за патч и вам за тесты =)
Antony Dovgal
> Тут надо понимать цель fpm - это sapi для высоконагруженных систем.
> Протестировать что-либо под виндой можно и обычным php-cgi -b, а
> запускать что-то в производстве на cygwin или виндовом кастрате
> селекта - это в лучшем случае баловство. О какой то производительности
> и надежности тут даже заикаться смешно.
Я с тобой совершенно согласен.
Oleg Roschupkin
> On 08.12.2009 16:29, Oleg Roschupkin wrote:
>> phpize работает так же, как и у Фиксера:
>>
>> checking for ld used by gcc... ./configure: line 2601: s%\\%/%g: No
>> such file or directory
>> no
>> configure: error: no acceptable ld found in $PATH
>>
>
> FreeBSD?
Я понял почему вопрос, сейчас объясню - я раньше писал через
интерфейс, потому назывался jahson )
На деле у меня недофря - osx.
> autoconf какой версии?
autoconf проверял 2.13 - через export PHP_AUTOCONF='autoconf213'; от
2.65 всё сразу сходит с ума.
> А без FPM всё точно так же? (снапшоты тут: http://snaps.php.net/)
Попробую попробовать.
fixxxer
> phpize работает так же, как и у Фиксера:
>
> checking for ld used by gcc... ./configure: line 2601: s%\\%/%g: No
> such file or directory
> no
> configure: error: no acceptable ld found in $PATH
Есть суровое подозрение, что это проявляется только на 32 битах:
Linux debian 2.6.26-2-amd64
FreeBSD 8.0-RELEASE amd64
тут все нормально;
FreeBSD 7.2-RELEASE i386
Darwin Kernel Version 9.8.0 i386
тут получаем
phpize && ./configure
checking for ld used by gcc... ./configure: s%\\%/%g: not found
no
configure: error: no acceptable ld found in $PATH
Если попытаться схитрить и запустить LD='ld' ./configure - облом
следует дальше
checking command to parse nm output from gcc object... ./configure: s/^
[ABCDGIRSTW][ABCDGIRSTW]* \(.*\) \(.*\)$/ {"\2", (lt_ptr_t) \&\2},/:
not found
но по крайней мере собирается =) Проверял на APC.
Да. Обновил патч (я там перестарался с зачисткой):
http://symbi.org/misc/php_5_3_fpm_sapi_cleanup_UPD2.patch
Накладывать на 291870.
Antony Dovgal
> Я понял почему вопрос, сейчас объясню - я раньше писал через
> интерфейс, потому назывался jahson )
> На деле у меня недофря - osx.
А, понял =)
>> autoconf какой версии?
>
> autoconf проверял 2.13 - через export PHP_AUTOCONF='autoconf213'; от
> 2.65 всё сразу сходит с ума.
>
>> А без FPM всё точно так же? (снапшоты тут: http://snaps.php.net/)
>
> Попробую попробовать.
Попробуйте только сначала ./vcsclean && ./buildconf && ./config.nice && make install
make install важно, т.к. phpize работает на основе уже установленных файлов.
Вообще, судя по всему, у вас $SED не определена и FPM тут никаким боком..
Antony Dovgal
> Есть суровое подозрение, что это проявляется только на 32 битах:
Вряд ли.
Ошибка ваша вылазит из build/libtool.m4:2267
Там вот такая строка:
ac_prog=`echo $ac_prog| $SED 's%\\\\%/%g'`
Что ты видишь, когда запускаешь `./config.nice | grep sed` ?
> Да. Обновил патч (я там перестарался с зачисткой):
> http://symbi.org/misc/php_5_3_fpm_sapi_cleanup_UPD2.patch
> Накладывать на 291870.
Ок, гляну.
Oleg Roschupkin
Опередил )
Я тогда покажу всю историю ругани конфигуре
loading cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for egrep... grep -E
checking for a sed that does not truncate output...
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for icc... no
checking for suncc... no
checking whether gcc and cc understand -c and -o together... yes
checking for system library directory... lib
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking host system type... i386-apple-darwin9.8.0
checking target system type... i386-apple-darwin9.8.0
./configure: line 1556: s/.*>//: No such file or directory
checking for PHP prefix... /usr/local
checking for PHP includes... -I/usr/local/include/php -I/usr/local/
include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/
php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/
date/lib
checking for PHP extension directory... /usr/local/lib/php/extensions/
no-debug-non-zts-20090626
checking for PHP installed headers prefix... /usr/local/include/php
checking if debug is enabled... no
checking if zts is enabled... no
checking for re2c... no
configure: warning: You will need re2c 0.13.4 or later if you want to
regenerate PHP parsers.
checking for gawk... gawk
checking for cURL support... yes, shared
checking if we should use cURL for url streams... no
checking for cURL in default path... found in /usr
checking for cURL 7.10.5 or greater... libcurl 7.16.3
checking for SSL support in libcurl... yes
checking how to run the C preprocessor... gcc -E
checking for openssl support in libcurl... no
checking for gnutls support in libcurl... no
checking for curl_easy_perform in -lcurl... yes
checking for curl_version_info in -lcurl... yes
checking for curl_easy_strerror in -lcurl... yes
checking for curl_multi_strerror in -lcurl... yes
checking build system type... i386-apple-darwin9.8.0
checking for ld used by gcc... ./configure: line 3474: s%\\%/%g: No
such file or directory
ld
checking if the linker (ld) is GNU ld... no
checking for ld option to reload object files... -r
checking for BSD-compatible nm... nm
checking whether ln -s works... yes
checking how to recognize dependent libraries... pass_all
checking for object suffix... o
checking for executable suffix... rm: conftest.dSYM: is a directory
.dSYM
checking for dlfcn.h... yes
checking the maximum length of command line arguments... 196608
checking command to parse nm output from gcc object... ./configure:
line 4414: s/^[BCDEGRST][BCDEGRST]* \(.*\) \(.*\)$/ {"\2", (lt_ptr_t)
\&\2},/: No such file or directory
ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (ld) supports shared libraries... yes
checking dynamic linker characteristics... sed: first RE may not be
empty
darwin9.8.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
creating libtool
appending configuration tag "CXX" to libtool
updating cache ./config.cache
creating ./config.status
creating config.h
fixxxer
> On 08.12.2009 18:20, fixxxer wrote:
>
> > Есть суровое подозрение, что это проявляется только на 32 битах:
>
> Вряд ли.
> Ошибка ваша вылазит из build/libtool.m4:2267
> Там вот такая строка:
> ac_prog=`echo $ac_prog| $SED 's%\\\\%/%g'`
>
> Что ты видишь, когда запускаешь `./config.nice | grep sed` ?
>
$ ./config.nice | grep sed
checking for a sed that does not truncate output... (cached) /usr/bin/
sed
Oleg Roschupkin
Antony Dovgal
> checking for a sed that does not truncate output...
Макрос не находит нормальный sed. Этот макрос не менялся уже множество лет.
У меня мыслей нет, кроме предположения, что в вашей системе кривой sed (что не редкость).
Antony Dovgal
> $ ./config.nice | grep sed
> checking for a sed that does not truncate output... (cached) /usr/bin/
> sed
На чистом снапшоте работает или нет?
fixxxer
> На чистом снапшоте работает или нет?
Проверил - на снэпшоте работает.
Oleg Roschupkin
> On 08.12.2009 18:39, fixxxer wrote:
>> $ ./config.nice | grep sed
>> checking for a sed that does not truncate output... (cached) /usr/
>> bin/
>> sed
>
> On 08.12.2009 18:27, Oleg Roschupkin wrote:
>> checking for a sed that does not truncate output...
>
> Ну вы определитесь уже.
Для полной точности - у Фиксера данные из ./config.nice самого пхп,
как я понимаю. У меня же - из ./configure из ext/curl. Я не думаю, что
они должны различаться, но видимо они думают иначе.
Если я погрепаю вывод ./config.nice - будет то же самое, что и у
Фиксера
[00:01:18] /Users/jahson/repositories/svn/php_5_3_fpm $ ./config.nice
--enable-fpm --enable-exif --with-libxml-dir=/opt --with-zlib-dir=/opt
--with-mcrypt=/opt/local --with-xsl=/opt --with-tidy=/opt/local --with-
curl=/opt/local --with-iconv=/opt/local --with-mysql=mysqlnd --with-
mysqli=mysqlnd --with-pdo-mysql=mysqlnd|grep sed
checking for a sed that does not truncate output... (cached) /usr/bin/
sed
> На чистом снапшоте работает или нет?
Сейчас проверяю.
Oleg Roschupkin
> On 8 дек, 18:57, Antony Dovgal <t...@daylessday.org> wrote:
>> На чистом снапшоте работает или нет?
>
> Проверил - на снэпшоте работает.
Подтверждаю, работает. Трогал всё тот же ext/curl. Можно увидеть, что
вывод несколько отличается от прошлого раза.
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for egrep... grep -E
checking for a sed that does not truncate output... /usr/bin/sed
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for icc... no
checking for suncc... no
checking whether gcc and cc understand -c and -o together... yes
checking for system library directory... lib
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking host system type... i386-apple-darwin9.8.0
checking target system type... i386-apple-darwin9.8.0
checking for ld used by gcc... /usr/libexec/gcc/i686-apple-
darwin9/4.0.1/ld
checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld)
is GNU ld... no
checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to
reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -p
checking whether ln -s works... yes
checking how to recognize dependent libraries... pass_all
checking for object suffix... o
checking for executable suffix... rm: conftest.dSYM: is a directory
.dSYM
checking for dlfcn.h... yes
checking the maximum length of command line arguments... 196608
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/libexec/gcc/i686-apple-
darwin9/4.0.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin9.8.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
creating libtool
appending configuration tag "CXX" to libtool
updating cache ./config.cache
creating ./config.status
creating config.h
--
Yours, Oleg Roschupkin
jja...@gmail.com
fixxxer
> > Ну вы определитесь уже.
>
> Для полной точности - у Фиксера данные из ./config.nice самого пхп,
> как я понимаю. У меня же - из ./configure из ext/curl.
Ага. Я идиот. :)
~/APC-3.1.3p1$ ./config.nice | grep sed
checking for a sed that does not truncate output...
./configure: s/.*>//: not found
Oleg Roschupkin
Ну почему же ) Ты сделал, как просили
> Что ты видишь, когда запускаешь `./config.nice | grep sed` ?
Это я создал путаницу, выложив портянку от конфигуре курла.
fixxxer
Уточнение: на снэпшоте раобтает как на дистрибутивном configure, так и
на перегенеренном
Oleg Roschupkin
> On 08.12.2009 18:27, Oleg Roschupkin wrote:
>> checking for a sed that does not truncate output...
>
> Макрос не находит нормальный sed. Этот макрос не менялся уже
> множество лет.
> У меня мыслей нет, кроме предположения, что в вашей системе кривой
> sed (что не редкость).
Ну и чтобы совсем подытожить - я ведь до этого как-то собирал php с
этим sed'ом :)
Oleg Roschupkin
Antony Dovgal
> On 08.12.2009 18:39, fixxxer wrote:
>> $ ./config.nice | grep sed
>> checking for a sed that does not truncate output... (cached) /usr/bin/
>> sed
>
> On 08.12.2009 18:27, Oleg Roschupkin wrote:
>> checking for a sed that does not truncate output...
>
> Ну вы определитесь уже.
>
> На чистом снапшоте работает или нет?
В смысле, взять снапшот, сконфигурить, поставить и использовать phpize из него.
И точно так же из бранча PHP_5_3_FPM.
Jani говорит, что он исправлял похожую проблему на *BSD, но было это минимум пару недель назад,
соотв-но фикс уже должен быть в PHP_5_3_FPM, а проблемы могут быть от остатков старых установок.
Antony Dovgal
Вот снэпшот не должен никак отличаться от PHP_5_3_FPM.
Antony Dovgal
> Для полной точности - у Фиксера данные из ./config.nice самого пхп,
> как я понимаю. У меня же - из ./configure из ext/curl.
phpize - он откуда?
Antony Dovgal
svn up && ./vcsclean && ./buildconf && ./config.nice && make install
Сейчас должно работать.
20:08 <@gwynne> tony2001: It's long since fixed... the divert(1001) instead of divert(1) at the top of phpize.m4 inexplicably caused the resulting
configure script to be unable to find sed, which in turn caused a bunch of shell errors later on as it tried to execute empty commands and
sed expressions.
20:08 <@tony2001> AHA!..
fixxxer
> cd php_5_3_fpm
> svn up && ./vcsclean && ./buildconf && ./config.nice && make install
>
> Сейчас должно работать.
>
> 20:08 <@gwynne> tony2001: It's long since fixed... the divert(1001) instead of divert(1) at the top of phpize.m4 inexplicably caused the resulting
> configure script to be unable to find sed, which in turn caused a bunch of shell errors later on as it tried to execute empty commands and
> sed expressions.
> 20:08 <@tony2001> AHA!..
Работает, ага. Спасибо. Теперь понятно, почему не работало выборочно -
дело в версиях autoconf.
P.S. прочитал про divert() - офигеть, уличная магия какая-то. :)
Alexey A. Rybak
> Это надо для разворачивания тестового сервера на машинах разработчиков.
что ж это за тестовый сервер такой который на другой операцинке
>
> 8 декабря 2009 г. 15:39 пользователь Antony Dovgal <to...@daylessday.org>
> написал:
>>
>> On 08.12.2009 06:03, fixxxer wrote:
>> > On 8 дек, 05:57, fixxxer <fixxxe...@gmail.com> wrote:
>> >> http://symbi.org/misc/php_5_3_fpm_sapi_cleanup.patch
>> >> (Патч кумулятивный, предыдущее в себя включает).
>> >
>> > Обновил. Патч на ревизию 291811:
>> >
>> > http://symbi.org/misc/php_5_3_fpm_sapi_cleanup_UPD.patch
>>
>> Фикс, тут речи ведутся о том, что добавить поддержку Win32 в FPM должно
>> быть не очень сложно (учитывая, что libevent работает на винде).
>> Поэтому я бы не стал радикально удалять из кода всё, что касается винды.
>> По крайней мере, сейчас.
>>
>> Мне, конечно, сложно представить кому и зачем оно может быть нужно,
>> но мало ли - может, найдётся какой-нить доброволец, который займется этим.
>>
>> --
>> Wbr,
>> Antony Dovgal
>> ---
>> http://pinba.org - realtime statistics for PHP
>
>
>
> --
> C уважением, Александр Лозовюк
> Alpha-Beta-Release Blog
> http://abrdev.com
>
--
wbr,
fisher
fixxxer
> http://symbi.org/misc/php_5_3_fpm_sapi_cleanup_UPD2.patch
>
> Накладывать на 291870.
Еще чутка обновил. Залил поверх.
Oleg Roschupkin
> On 08.12.2009 19:30, Oleg Roschupkin wrote:
>> Для полной точности - у Фиксера данные из ./config.nice самого пхп,
>> как я понимаю. У меня же - из ./configure из ext/curl.
>
> phpize - он откуда?
Всё время использовал системный phpize.
ps. Я ведь уже написал, что после апа с фиксом divert всё заработало? )
Antony Dovgal
>> phpize - он откуда?
>
>
> Всё время использовал системный phpize.
>
> ps. Я ведь уже написал, что после апа с фиксом divert всё заработало? )
Да, да..
Это то ли gmail тупит, то ли Найт модерит каждое мое сообщение отдельно вместо того, чтобы пометить меня как "Allow always".
В общем, письма от меня в лист доходят беспорядочно и через полчаса после отправления.
PHP Club
тут вопрос в мантейнере скорей всего.
On 3 дек, 18:40, "Alexey A. Rybak" <alexey.ry...@gmail.com> wrote:
> > Поэтому некая "неофициальная группа разработчиков" - это на данный момент я,
> > как это не прискорбно.
> > А меня пускать в офиц. репозиторий не надо, я там и так есть =)
>
> давай чтобы не создавать ложной паники поясним
> - дримкет действительно собирается прекратить работу над проектом. но
> он никуда не пропадает, щас помогает, по-моему, вот обновления к сапи
> прислал.
> - в сентябре майкл с дримкетом сделали попытку предложить пхп-тим
> заняться фпм, типа вот у нас такой есть фпм, он уже сапи, не хотите ли
> его себе. вообще предложение было довольно странное по форме по-моему,
> ну и пхп тим как-то вяло отреагировал, типа ну можно подумать. да и их
> можно понять - народ занятой и вряд ли кто станет мейнтернером и будет
> заниматься интеграцией и всем гемором с поддержкой
> - это была не первая попытка - но раньше пхп-тим просто офигевал от
> закидонов фпм типа bundled libevent - щас ничего этого нет, ничего
> начать интеграцию не мешает, и в этом огромная заслуга дримкета.
> - сейчас самое лучшее время добавить фпм в официальный дистрибутив -
> со временем уйдут все грабли со сборкой, отдельными пакетами. тони -
> член пхп-тим уже черт значит скока лет.
> - что будет с проектом дальше - покажет время. но по-моему будет
> лучше, если в момент "безотцовщины" он окажется в репозитории пхп.
>
> --
>
> wbr,
> fisher