Junior Member
Пересмотрел все 33 страницы ветки, но так и не понял как вернуть mc обратно к нормальному виду.
Вот что имеем сейчас (mc -c, RT-N16 1.9.2.7-rtn-r4051) после перехода с ipkg на entware:
Буду рад помощи
Member
В настройках putty: Window - Translation - Remote character set - UTF-8.Originally Posted by Jogi
Буду рад помощи
В файлик "/tmp/local/root/.profile":
#!/bin/sh
export TERMINFO=/opt/share/terminfo
export PATH='/opt/sbin:/opt/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/sbin:/bin'
export TERM=xterm
export LANG='ru_RU.UTF-8'
export LC_ALL='ru_RU.UTF-8'
Junior Member
Что не хватает?
$ php-fcgi
PHP Warning: PHP Startup: Unable to load dynamic library '/opt/lib/php/http.so' - File not found in Unknown on line 0
$ ls /opt/lib/php/http.so
-rwxr-xr-x 1 admin root 313768 Mar 23 19:30 /opt/lib/php/http.so
Senior Member
А что говорит?Code:ldd /opt/lib/php/http.so
Junior Member
Пасиб.Code:checking sub-depends for 'not found' checking sub-depends for '/opt/lib/libcurl.so.4' checking sub-depends for '/opt/lib/libz.so.1' checking sub-depends for '/opt/lib/libcrypto.so.1.0.0' checking sub-depends for '/opt/lib/libssl.so.1.0.0' checking sub-depends for '/opt/lib/libgcc_s.so.1' checking sub-depends for '/opt/lib/libc.so.0' checking sub-depends for '/opt/lib/libdl.so.0' libevent-2.0.so.5 => not found (0x00000000) libcurl.so.4 => /opt/lib/libcurl.so.4 (0x00000000) libz.so.1 => /opt/lib/libz.so.1 (0x00000000) libcrypto.so.1.0.0 => /opt/lib/libcrypto.so.1.0.0 (0x00000000) libssl.so.1.0.0 => /opt/lib/libssl.so.1.0.0 (0x00000000) libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x00000000) libc.so.0 => /opt/lib/libc.so.0 (0x00000000) libdl.so.0 => /opt/lib/libdl.so.0 (0x00000000) ld-uClibc.so.0 => ld-uClibc.so.0 (0x00000000) ld-uClibc.so.0 => ld-uClibc.so.0 (0x00000000)
похоже libevent2 не хватало, поставил не ругается. Из дома только проверю работает PHP или нет.
Может где зависимости надо поставить, чтобы в следующий раз правильно ставилось.
В репозиторий добавлены SIP-серверы-близнецы OpenSIPS и Kamailio, призванные наряду с FreeSWITCH предложить альтернативу Asterisk.
Оригинальные Makefile'ы OpenSIPS/Kamailio пришлось подправить, поэтому пакеты необходимо проверить в работе.
2 lokus: жду тестов FreeSWITCH. Обязательно отпишитесь по результатам проверки.
Last edited by ryzhov_al; 06-04-2012 at 18:05.
Forum Guru
ryzhov_al, voidshah
Возможно я что-то пропустил в дискуссии - а чего не увеличиваете PKG_RELEASE при изменении пакетов?
Например, uclibc-opt_0.9.32-1_entware.ipk так до сих пор билд 1, хотя изменялась и в r465, и в r443 ...
P.S. Рекомендую взять наши последние обновления uClibc.
uclibc-пакеты не менялись, они просто по новой перепаковывались. Видишь ли, наш проект - это куча патчей к одной из последних ревизий транка OpenWRT. Для того, чтобы идти в ногу с этим транком раз-два в месяц приходится:
- забирать последний транк OpenWRT,
- актуализировать наши патчи,
- пересобирать весь мир обновлённой средой.
Мы отмечаем эти ревизии комментариями "fixup according to last openwrt trunk (rev.ХХХХХ)." При этом OpenWRT-шные пакеты libc, libgcc, libstdcpp, libpthread, librt, ldconfig, ldd - это просто упакованные в ipk-обёртку библиотеки, взятые из тулчейна. Сами библиотеки при этом не меняются ни на байт, но при перепаковке в этих ревизиях возникает бинарная разница между ipk-пакетами.
После каждого подобного обновления я обязательно проверяю работоспособность привычного набора программ на роутере полной переустановкой.
Честно? Боюсь из-за незнания. Для себя решил, что буду обновлять тулчейн не чаще раза в год. Не хочу, чтобы на каком-то этапе работа репозитория у форумчан была нарушена при обновлении ключевых библиотек. При этом, естественно, доверие к репозиторию будет подорвано.
В отношении тулчейна буду вести себя максимально консервативно. Обновлять его буду только в случае обнаружения каких-то критических ошибок или значительных обновлений, вроде перехода на uClibc 0.9.33.
Last edited by ryzhov_al; 07-04-2012 at 10:50.
Forum Guru
Твоя логика конечно не лишена смысла, но я предлагаю обратить внимание на правки только uClibc, на мои порты PR к gcc можешь забить с чистой совестью
IMHO важные:
r4052 - проверяется тесткейсом, сам проверял (с ним связан r4060), это всё с апстрима
r4053 - явная бага, проверяется глазками в arch/mips/kernel/scall32-o32.S
r4062 - явная бага, проверял сам
r4061 - можешь не брать, лично нагрузочное тестирование не проводил, доверился автору.
Именно 0.9.33 не имеет смысла, основная разница - добавлена поддержка prelink.Обновлять его буду только в случае обнаружения каких-то критических ошибок или значительных обновлений, вроде перехода на uClibc 0.9.33.
Senior Member
Все же соглашусь с Леонидом. При важных правках тулчейн необходимо обновлять и пересобирать весь репозиторий. Раз в год, имхо, очень редко. Конечно, могут возникнуть проблемы у пользователей... Но ведь они решаемы. Опять же имхо - доверие не подорвется.
RT-N16 + Entware repo
1. Глядя как часто voidshah пользуется readelf, включил в новый репозиторий binutils. В первую очередь для себя.
2. Закончил портирование из энтузасткого Optware'шного репозитория всех пакетов, которые когда-то туда привнёс (в том числе фидошные^). Оставшиеся непортированными shakespeer и mldonkey вряд ли в силу возраста представляют интерес (ага, я слышу ваш сарказм об актуальности фидошного софта ^))).
Тем более, что для DC-обмена теперь есть ncdc.
3.Не вопрос.
В силу нахождения бага в mmap64.c предлагаю "пересобрать" тулчейн наиболее ленивым способом: дождёмся, когда Леонид включит патч в свой код прошивки и просто поправим номер забираемой ревизии тулчейна в своём хозяйстве.
Кроме того, предлагаю в нашем хозяйстве упростить один момент. Сейчас у нас для создания тулчейна с энтузиасткого сайта выкачиваются две ветки разных ревизий:
- ревизия кода прошивки (сейчас r4001) для подготовки ядра перед сборкой тулчейна,
- ревизия тулчейна (сейчас r3988).
Предлагаю забирать код ядра и код тулчейна одной ревизии. Тем более, что "разнесение" этих ревизий вероятно чревато неприятными последствиями. Кроме того, предлагаю отражать номер забранной у энтузиастов ревизии в поле версии ключевых пакетов. Тем более, что сейчас они именуются явно сиротливо:
Пусть уж пакеты называются как libc_r4001-104_entware.ipk, у окружающих не будет вопросов о том, что за библиотеки включены в очередное обновление.Code:ls ./trunk/bin/entware/packages/*_-* ./trunk/bin/entware/packages/ldconfig_-104_entware.ipk ./trunk/bin/entware/packages/ldd_-104_entware.ipk ./trunk/bin/entware/packages/libc_-104_entware.ipk ./trunk/bin/entware/packages/libgcc_-104_entware.ipk ./trunk/bin/entware/packages/libpthread_-104_entware.ipk ./trunk/bin/entware/packages/librt_-104_entware.ipk ./trunk/bin/entware/packages/libstdcpp_-104_entware.ipk
Интересно, правильно ли "тупой" opkg определит что новее: libc_r4002-104_entware.ipk или libc_r4001-105_entware.ipk?
Last edited by ryzhov_al; 10-04-2012 at 07:35.
Forum Guru
IMHO, не имеет смысла, особенно если вы вдруг будете добавлять свои патчи. Просто увеличивай PKG_RELEASE, а в тексте коммита можешь указать ссылку на нашу ревизию.
Senior Member
Блин.. Тупой я тоже не могу определить - что из них новее... Ибо они кажутся одинаковыми..
The God is real, unless declared as integer
Зеркало для ipkg и старые пакеты (с 08.06.11)
Зеркало для opkg и старые пакеты (с 24.03.12)
Добавил apache вместе с htdigest, r489.
Правда, на мой взгляд, в инсталляционный пакет OpenWRT'шники на этот раз запаковали больше, чем надо. Что странно, зная их тягу к минимализму содержимого ipk-пакетов.
Ок, поправил:
По отсутствующей зависимости php5-mod-http.
Попробуем действовать синхронно с OpenWRT, создал им Ticket #11257.
Правда не могу сказать как быстро они прореагируют. После внесения правок в OpenWRT trunk пересобиру исправленную версию.
Last edited by ryzhov_al; 10-04-2012 at 11:09.
Senior Member
r493Теперь появилась возможность фиксировать trunk и feeds OpenWRT'шного репозитория. Т.е. при самостоятельной сборке будут скачитваться именно те trunk и feeds, которые указаны ryzhov_al какСейчас это ревизия r31158.Fixup according to last (r31158) OpenWRT trunk
RT-N16 + Entware repo
Posting Permissions
Reply With Quote