[devel] x86_64 -- первый этап борьбы и первые проблемы

[devel] x86_64 -- первый этап борьбы и первые проблемы

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

Первая итерация полной пересборки всего сизифа почти выполнена, на текущий
момент у меня собраны (сами, без каких-либо правок) 577 пакетов (список
приоагается).

Вопрос к знатокам rpm: можно ли заставить rpm выполнять некий код сразу
после секции install? Всего лишь одна проверка + если архитектура x86_64
переименование %buildroot/usr/lib в %buildroot%_libdir и %buildroot/lib в
%buildroot%_lib позволит собраться на x86_64 где-то двум третям ныне не
пересобирающимся пакетам.

Основная масса пакетов из имеющихся у меня сейчас не собирается из-за
того, что не собирается кто-то по зависимостям (после нескольких итераций
пересборки будет заметно лучше, увы я не всегда могу поставить пересборку
на ночь).

_Очень_ большая часть не собирается либо по причине установки в
%buildroot/[usr/]lib (что часто лечится исключительно патчем Makefile и
иже с ним или простым mv, что, IMHO, проще), либо по причине использования
/usr/lib и /lib внутри spec-файла. Особенно это касается секции %files, за
такое, IMHO, надо бить sisyphus_check по голове. Что mouse@ что я устанем
давать по голове каждому мантейнеру -- пущай лучше это робот-пересборщик
делает, он железный, его не жалко.

Как ни странно, но весьма небольшая часть пакетов не собирается по причине
кривого кода.

Однако заметная часть кода _потенциально небезопасна_ хотя и собирается.

Резюме:
 - пожалуйста, подскажите куда пинать rpm, чтобы нужный мне код исполнялся
   в конце секции %install (а может просто поправить макросы вроде
   %makeinstall ?

 - можно ли добавить в sisyphus_check матюгалку на неиспользование
   %_libdir и %_lib в секциях %files ?

 - возможно ли опциями gcc приравнять Warning'и на тему преобразования из
   64-bit указателя в 32-bit целое к ошибкам? Тогда я смогу в
   автоматическом режиме сформировать список пакетов с потенциальными
   проблемами, и пнуть сначала мантейнеров, а если не отзовутся, то
   опубликовать список в листах -- авось кого заинтересуют эти проблемы.

-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] x86_64 -- первый этап борьбы и первые проблемы

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]

Hi,

On Sat, Sep 04, 2004 at 08:37:10PM +0400, Денис Смирнов wrote:
[...]
> Вопрос к знатокам rpm: можно ли заставить rpm выполнять некий код сразу
> после секции install?

Можно.
По окончании %install выполняется %__spec_install_post в следующем порядке:
%{__arch_install_post}
%{__os_install_post}
%{__spec_install_custom_post}

%__os_install_post - это /usr/lib/rpm/brp-alt
Вам, скорее всего, нужен %__arch_install_post

Только должен вас расстроить: не все скрипты, запускаемые из brp-alt,
готовы к lib64.

> Всего лишь одна проверка + если архитектура x86_64
> переименование %buildroot/usr/lib в %buildroot%_libdir и %buildroot/lib в
> %buildroot%_lib позволит собраться на x86_64 где-то двум третям ныне не
> пересобирающимся пакетам.

Если это предлагается делать по умолчанию, то надо предусмотреть способ
легкого отключения.

> Основная масса пакетов из имеющихся у меня сейчас не собирается из-за
> того, что не собирается кто-то по зависимостям (после нескольких итераций
> пересборки будет заметно лучше, увы я не всегда могу поставить пересборку
> на ночь).
> 
> _Очень_ большая часть не собирается либо по причине установки в
> %buildroot/[usr/]lib (что часто лечится исключительно патчем Makefile и
> иже с ним или простым mv, что, IMHO, проще), либо по причине использования
> /usr/lib и /lib внутри spec-файла. Особенно это касается секции %files, за
> такое, IMHO, надо бить sisyphus_check по голове.

Не надо бить sisyphus_check по голове, он не занимается анализом
spec-файлов.

> Что mouse@ что я устанем
> давать по голове каждому мантейнеру -- пущай лучше это робот-пересборщик
> делает, он железный, его не жалко.

Только робота надо запрограммировать.

> Как ни странно, но весьма небольшая часть пакетов не собирается по причине
> кривого кода.
> 
> Однако заметная часть кода _потенциально небезопасна_ хотя и собирается.
> 
> Резюме:
>  - пожалуйста, подскажите куда пинать rpm, чтобы нужный мне код исполнялся
>    в конце секции %install (а может просто поправить макросы вроде
>    %makeinstall ?

Лучше подумать об %__arch_install_post в файле /etc/rpm/%{_target_platform}/macros.

>  - можно ли добавить в sisyphus_check матюгалку на неиспользование
>    %_libdir и %_lib в секциях %files ?

Это не должен быть sisyphus_check, поскольку последний не занимается
анализом spec-файлов.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] x86_64 -- первый этап борьбы и первые проблемы

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]

On Sat, Sep 04, 2004 at 10:43:51PM +0400, Dmitry V. Levin wrote:

 DVL> Можно.
 DVL> По окончании %install выполняется %__spec_install_post в следующем порядке:
 DVL> %{__arch_install_post}
 DVL> %{__os_install_post}
 DVL> %{__spec_install_custom_post}
 DVL> %__os_install_post - это /usr/lib/rpm/brp-alt
 DVL> Вам, скорее всего, нужен %__arch_install_post

Понял, спасибо.

Как обозвать скрипты, чтобы ни с кем по именам не подраться?
Потом это лучше интегрировать в rpm, или делать отдельным пакетом?
 
 DVL> Только должен вас расстроить: не все скрипты, запускаемые из brp-alt,
 DVL> готовы к lib64.

Где уже известные грабли лежат?

 >> Всего лишь одна проверка + если архитектура x86_64
 >> переименование %buildroot/usr/lib в %buildroot%_libdir и %buildroot/lib в
 >> %buildroot%_lib позволит собраться на x86_64 где-то двум третям ныне не
 >> пересобирающимся пакетам.
 DVL> Если это предлагается делать по умолчанию, то надо предусмотреть способ
 DVL> легкого отключения.

Я очень плохо знаком с внутренностями RPM. Каким образом можно сделать
подобную ручку (наверное это ручка того же плана, что ручки для
brp-verify-elf).

 DVL> Не надо бить sisyphus_check по голове, он не занимается анализом
 DVL> spec-файлов.

Сейчас существует какая-нибудь сущность, анализирующая spec-файлы?
Может этой сущностью может быть cleanup-spec? Только видится мне что это
не так просто как кажется, особенно если не просто выдавать warning'и, а
делать автоматическую замену.

 >> Что mouse@ что я устанем
 >> давать по голове каждому мантейнеру -- пущай лучше это робот-пересборщик
 >> делает, он железный, его не жалко.
 DVL> Только робота надо запрограммировать.

Думаю вариант простой будет таким -- я попробую сделать робота, поиграюсь
с ним и кину сюда. Если всё с роботом нормально, то можно для кривых
пакетов сделать им же правку и пересборку с уведомлением мантейнеров.

 >>  - пожалуйста, подскажите куда пинать rpm, чтобы нужный мне код исполнялся
 >>    в конце секции %install (а может просто поправить макросы вроде
 >>    %makeinstall ?
 DVL> Лучше подумать об %__arch_install_post в файле /etc/rpm/%{_target_platform}/macros.

/me читал текст sqlite.spec и много думал. Кстати я бы хотел попросить
людей присутствующих здесь и понимающих как работает libtool посмотреть
туда (особенно в то, что я залил вчера в incoming, хотя разница не шибко
большая).

Конструкции которая там было бы недостаточно обработки только в
%__arch_install_post из-за установки в два этапа, и таки %makeinstall
получается тоже править придётся.

 >>  - можно ли добавить в sisyphus_check матюгалку на неиспользование
 >>    %_libdir и %_lib в секциях %files ?
 DVL> Это не должен быть sisyphus_check, поскольку последний не занимается
 DVL> анализом spec-файлов.

Ясно.

P.S. Вы с mouse@ как-то синхронизируетесь по rpm?

-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] x86_64 -- первый этап борьбы и первые проблемы

[Yuri N. Sedunov]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Воскресенье 05 Сентябрь 2004 00:46, Денис Смирнов wrote:

<skip>
>
>  DVL> Не надо бить sisyphus_check по голове, он не занимается анализом
>  DVL> spec-файлов.
>
> Сейчас существует какая-нибудь сущность, анализирующая spec-файлы?
> Может этой сущностью может быть cleanup-spec? Только видится мне что это
> не так просто как кажется, особенно если не просто выдавать warning'и, а
> делать автоматическую замену.

$ cat ~/bin/prespec
#!/bin/sh
 
SPEC=$1
 
cleanup_spec $SPEC
 
subst 's,%prefix/bin,%_bindir,g
s,%prefix/lib,%_libdir,g
s,%prefix/share,%_datadir,g
s,%prefix/include,%_includedir,g
s,%prefix/man,%_mandir,g
s,/usr/bin,%_bindir,g
s,/usr/lib,%_libdir,g
s,/usr/share,%_datadir,g
s,/usr/include,%_includedir,g' $SPEC

-- 
Yuri N. Sedunov
09/05/04 17:11:15

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] x86_64 -- первый этап борьбы и первые проблемы

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

On Sun, Sep 05, 2004 at 05:19:25PM +0400, Yuri N. Sedunov wrote:

 >> Сейчас существует какая-нибудь сущность, анализирующая spec-файлы?
 >> Может этой сущностью может быть cleanup-spec? Только видится мне что это
 >> не так просто как кажется, особенно если не просто выдавать warning'и, а
 >> делать автоматическую замену.
 YNS> $ cat ~/bin/prespec
 YNS> #!/bin/sh
 YNS>  
 YNS> SPEC=$1
 YNS>  
 YNS> cleanup_spec $SPEC
 YNS>  
 YNS> subst 's,%prefix/bin,%_bindir,g
 YNS> s,%prefix/lib,%_libdir,g
 YNS> s,%prefix/share,%_datadir,g
 YNS> s,%prefix/include,%_includedir,g
 YNS> s,%prefix/man,%_mandir,g
 YNS> s,/usr/bin,%_bindir,g
 YNS> s,/usr/lib,%_libdir,g
 YNS> s,/usr/share,%_datadir,g
 YNS> s,/usr/include,%_includedir,g' $SPEC

/me думает -- всегда ли корректна такая замена? Если да, то тогда всё
вообще элементарно -- я ищу скриптом во всех спеках совпадение хотя бы
одной из этих замен. Только к ним ещё ^/lib добавить надо. Если хоть одна
есть -- автоматом заменяю, добавляю запись в changelog и пересобираю srpm
пакет.

-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] x86_64 -- первый этап борьбы и первые проблемы

[Anton Kachalov]

Я смог-таки собрать новый (0.16.16) dev86 и новый (22.6) lilo со всеми
патчами. Gfxboot работает :) bmp'ки тож пашут, ядро грузится :)
Завтра выложу.
Ещё бы syslinux* пособирать...

Желающие затетсить новый lilo есть? :-)

Rgds,
Anton

Re: [devel] x86_64 -- первый этап борьбы и первые проблемы

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

On Sun, Sep 05, 2004 at 12:51:12PM +0400, Anton Kachalov wrote:

 AK> Я смог-таки собрать новый (0.16.16) dev86 и новый (22.6) lilo со всеми
 AK> патчами. Gfxboot работает :) bmp'ки тож пашут, ядро грузится :)
 AK> Завтра выложу.
 AK> Ещё бы syslinux* пособирать...
 AK> Желающие затетсить новый lilo есть? :-)

Да. Это я. Можешь куда-нибудь на ftp выложить и url дать?
И не подскажешь какую часть доки читать, чтобы каскадировать 2 lilo (один
в MBR, он грузит всё, другой пусть будет в /dev/sda2, он и будет грузить
x86_64 когда мне нужно). Чтобы в случае глюки в lilo не парится с дисками
:)

И ещё -- ты XFree86-devel, tetex, и python не собирал? Без них пол-сизифа
не собирается, а по крайней мере tetex хочет XFree86-devel. Может я у тебя
возьму ту сборку x.org, которая хоть как vesa работала?

P.S. Не-на-ви-жу ATI.
P.P.S. На неделе приеду меняться сборками с ZIV'ой :) Думаю во
вторник-среду. Надеюсь к тому времени бОльшая часть моих патчей уже
окажутся в Сизифе.

-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] [JT] Re: x86_64 -- первый этап борьбы и первые проблемы

[Michael Shigorin]

On Sat, Sep 04, 2004 at 08:37:10PM +0400, Денис Смирнов wrote:
> Что mouse@ что я устанем давать по голове каждому мантейнеру --
> пущай лучше это робот-пересборщик делает, он железный, его не
> жалко.

А нас?!

-- 
:)

Re: [devel] [JT] Re: x86_64 -- первый этап борьбы и первые проблемы

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

On Mon, Sep 06, 2004 at 11:05:30AM +0300, Michael Shigorin wrote:

 >> Что mouse@ что я устанем давать по голове каждому мантейнеру -
 >> пущай лучше это робот-пересборщик делает, он железный, его не
 >> жалко.
 MS> А нас?!

В отличии от робота -- жалко :-) Вот пусть робот и работает :-)

--
С уважением, Денис, окончательно озверевший от выходных, проведённых ночами
за экспериментами с x86_64, и которого уже с утра терроризируют звонками с
никакнесфрмулироваными ТЗ на поднятие очередной пары серверов со
срочностью "позавчера".


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] Re: x86_64 -- первый этап борьбы и первые проблемы

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

Денис Смирнов пишет:
> On Mon, Sep 06, 2004 at 11:05:30AM +0300, Michael Shigorin wrote:
> 
>  >> Что mouse@ что я устанем давать по голове каждому мантейнеру -
>  >> пущай лучше это робот-пересборщик делает, он железный, его не
>  >> жалко.
>  MS> А нас?!
> 
> В отличии от робота -- жалко :-) Вот пусть робот и работает :-)
А ты знаешь, что железный робот бьёт больнее!.. ;)
Так ведь еще и не устает бить, и бьет всегда одинакого сильно!.. ;)

> С уважением, Денис, окончательно озверевший от выходных, проведённых ночами
> за экспериментами с x86_64, и которого уже с утра терроризируют звонками с
> никакнесфрмулироваными ТЗ на поднятие очередной пары серверов со
> срочностью "позавчера".
Бывает...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] Re: x86_64 -- первый этап борьбы и первые проблемы

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

On Tue, Sep 07, 2004 at 05:37:14PM +0900, Ivan Fedorov wrote:

 >> В отличии от робота -- жалко :-) Вот пусть робот и работает :-)
 IF> А ты знаешь, что железный робот бьёт больнее!.. ;)
 IF> Так ведь еще и не устает бить, и бьет всегда одинакого сильно!.. ;)

Правильный робот не должен бить, он должен работать, работать, и ещё раз
работать. Как на энерджайзере :) А человек, значится, думать должен. Хотя
это и трудно :)

 >> С уважением, Денис, окончательно озверевший от выходных, проведённых ночами
 >> за экспериментами с x86_64, и которого уже с утра терроризируют звонками с
 >> никакнесфрмулироваными ТЗ на поднятие очередной пары серверов со
 >> срочностью "позавчера".
 IF> Бывает...

Это не страшно :-) Страшно когда нехорошие люди отказываются везти сервер
мне домой для настройки, и мне приходится тащиться о офис, чотбы каждые 5
минут у меня спрашивали по поводу глюков винды, и чтобы я ломал глаза о
дешёвые 17" мониторы двухлетней давности, ибо ноутбук сломан.
 
-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] Re: x86_64 -- первый этап борьбы и первые проблемы

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

> Это не страшно :-) Страшно когда нехорошие люди отказываются везти сервер
> мне домой для настройки, и мне приходится тащиться о офис, чотбы каждые 5
дадада. одни такие люди попустились за неделю. для этого даже делать ничего не 
пришлось. буквально ;-)
через неделю сами позвонили и спросили куда привезти :-)

-- 
Regards, Nick S. Grechukh
NSG1-UANIC
network administrator at many places :-)

=== ALT Linux fortune: ========================
Лучше не постить в рассылку после принятия пива.
  -- ldv in sisyphus@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]