[devel] Q: srpms buildrequires

[devel] Q: srpms buildrequires

[Alexey Gladkov]

Приветствую!
При сборке приходящих пакетов под несколько архитектур одновременно
возникла проблема, которую я не знаю как решить, кроме как на уровне
полиси.
В инкоминиг приходят исходные пакеты собранные под одну архитектуру. В
некоторых пакетах некоторые BuildRequires взяты в %ifarch блоки т. е.
часть сборочных зависимостей проявляются только на определенной
архитектуре. Чтобы узнать какие пакеты нужны для сборки такого пакета
нужно сделать его перепаковку (rpm -bs --nodeps).  В "чистом" chroot'е
перепаковку сделать нельзя. Перепаковка возможна если в сборочной
среде уже установлены все необходимые пакеты.... например
предоставляющие дополнительные rpm-макросы и т.д. Получается замкнутый
круг.

Чтобы узнать сборочные зависимости нужна перепаковка <-> для
перепаковки нужны сборочные зависимости.

Причем напомню, в BuildRequires может быть то, чего еще вообще нет ...
в случае если это совсем новый пакет. Так что прибить гвоздями
необходимые пакеты нельзя.
Разобрать спек не реально. Это делает "rpm -bE" и ему тоже нужна
готовая сборочная среда. Даже если найдется такой умелец, который
возьмется парсер написать, то найдется спек который не обработается
этим парсером.

Таким образом, BuildRequires в исходном пакете становятся архитектурно
зависимыми. Но это нарушает основную идею SRPMS.

Единственным выходом мне видится, запрет на уровне полиси создания
сборочных зависимостей зависящих от _сборочной_архитектуры_ .
Подчеркиваю, что речь идет только про BuildRequires.

Если у кого-нибудь есть конструктивные предложения прошу высказаться.

-- 
Rgrds, legion

Re: [devel] Q: srpms buildrequires

[Alexey I. Froloff]

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

* Alexey Gladkov <legion@> [050719 16:13]:
> Единственным выходом мне видится, запрет на уровне полиси создания
> сборочных зависимостей зависящих от _сборочной_архитектуры_ .
> Подчеркиваю, что речь идет только про BuildRequires.
А можно пример?

-- 
Regards, Sir Raorn.
-------------------
> >огласить весь список rpm -qa | grep ^kde? :)
> >3.2.3, Sisyphus (20040804)
> Ничче не понимаю. У меня вроде то же самое (см. выше). Будем Зерга звать?
пора.

Зееерггггг!!!!!?
		-- shrek in sisyphus@

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

[devel] Re: Q: srpms buildrequires

[Anton Farygin]

On Tue, 19 Jul 2005 16:34:26 +0400, Alexey I. Froloff wrote:

> * Alexey Gladkov <legion@> [050719 16:13]:
>> Единственным выходом мне видится, запрет на уровне полиси создания
>> сборочных зависимостей зависящих от _сборочной_архитектуры_ .
>> Подчеркиваю, что речь идет только про BuildRequires.
> А можно пример?

dbus и mono

Rgds,
Rider

Re: [devel] Q: srpms buildrequires

[Dmitry V. Levin]

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

On Tue, Jul 19, 2005 at 04:34:26PM +0400, Alexey I. Froloff wrote:
> * Alexey Gladkov <legion@> [050719 16:13]:
> > Единственным выходом мне видится, запрет на уровне полиси создания
> > сборочных зависимостей зависящих от _сборочной_архитектуры_ .
> > Подчеркиваю, что речь идет только про BuildRequires.
> А можно пример?

%ifarch %ix86
%def_with ada
%else
%def_without ada
%endif
[...]
%{?_with_ada:BuildPreReq: gcc%gcc_branch-gnat}

Увы, rpm'овский spec-файл существенно сложнее чем deb'овский
debian/control.

Между прочим, есть workaround: hsh --query-repackage,
и делает он следующее:

cat >chroot/.host/query_req <<__EOF__
#!/bin/sh -e
rpmi -i -- "\$@"
cd \`rpm --eval %_specdir\`
rpmbuild -bs --nodeps $rpmargs -- *.spec >/dev/null
cd \`rpm --eval %_srcrpmdir\`
rpmquery -pR -- "\$@"
__EOF__

Так что, если имя файла исходного пакета при перепаковке не изменится,
то этот метод будет работать.
А вот изменение имени файла исходного пакета надо ограничить правилами.


-- 
ldv

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

Re: [devel] Q: srpms buildrequires

[Anton D. Kachalov]

On Fri, Jul 22, 2005 at 11:30:30PM +0400, Dmitry V. Levin wrote:
> Так что, если имя файла исходного пакета при перепаковке не изменится,
> то этот метод будет работать.
> А вот изменение имени файла исходного пакета надо ограничить правилами.
Мы этот вариант прорабатывали. Тут есть другая проблема.
Например, перепаковка любого kernel-спека или чего-либо ещё, что требует
дополнительных пакетов с макросами. Как тут быть? У меня была одна идея,
но тоже безумная :) Можно немного модифицировать сам rpm, добавив
некоторое расширение к BuildRequires:
> BuildRequires(i586): mono
или
> BuildRequires: mono(i586)
В Requires будет прописано:
mono(i586), а сам rpm при запросе requires будет смотреть на наличие
(arch) у requires и в случае, если архитектура совместима, выдаёт уже:
> Requires: mono
А если нет, то просто игнорирует эту зависимость.

--
mouse

Re: [devel] Q: srpms buildrequires

[Alexey Gladkov]

Anton D. Kachalov wrote:
> On Fri, Jul 22, 2005 at 11:30:30PM +0400, Dmitry V. Levin wrote:
> 
>>Так что, если имя файла исходного пакета при перепаковке не изменится,
>>то этот метод будет работать.
>>А вот изменение имени файла исходного пакета надо ограничить правилами.
> 
> Мы этот вариант прорабатывали. Тут есть другая проблема.
> Например, перепаковка любого kernel-спека или чего-либо ещё, что требует
> дополнительных пакетов с макросами. Как тут быть? У меня была одна идея,
> но тоже безумная :) Можно немного модифицировать сам rpm, добавив
> некоторое расширение к BuildRequires:
> 
>>BuildRequires(i586): mono
> 
> или
> 
>>BuildRequires: mono(i586)

+1

Жаль только, что для этого нужно модифицировать rpm.

-- 
Rgrds, legion

Re: [devel] Q: srpms buildrequires

[Ivan Fedorov]

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

Anton D. Kachalov пишет:

>>BuildRequires: mono(i586)
+1


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

[devel] Re: Q: srpms buildrequires

[Michael Shigorin]

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

On Fri, Jul 22, 2005 at 11:30:30PM +0400, Dmitry V. Levin wrote:
> А вот изменение имени файла исходного пакета надо ограничить
> правилами.

Зафиксируешь/объявишь?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] Re: Q: srpms buildrequires

[Igor Zubkov]

В сообщении от Вторник, 26-Июл-2005 17:28 Michael Shigorin написал(a):
> On Fri, Jul 22, 2005 at 11:30:30PM +0400, Dmitry V. Levin wrote:
> > А вот изменение имени файла исходного пакета надо ограничить
> > правилами.
>
> Зафиксируешь/объявишь?

+ запретить перепаковывать оригинальные исходники. (tar.gz->tar.bz2)
+ ложить в  srpm'ку подпись пакета с исходниками от оригинального разработчики 
(если он конечно их подписывает). а после можно и робота нарисовать для 
проверки того что исходники из "нормального места" пришли.

Re: [devel] Re: Q: srpms buildrequires

[Ivan Fedorov]

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

Igor Zubkov пишет:
> В сообщении от Вторник, 26-Июл-2005 17:28 Michael Shigorin написал(a):
> 
>>On Fri, Jul 22, 2005 at 11:30:30PM +0400, Dmitry V. Levin wrote:
>>
>>>А вот изменение имени файла исходного пакета надо ограничить
>>>правилами.
>>
>>Зафиксируешь/объявишь?
> 
Похоже вы не поняли где проблема, и что требуется...
> 
> + запретить перепаковывать оригинальные исходники. (tar.gz->tar.bz2)
Да ну? У вас видимо траффик халявный?..
> + ложить в  srpm'ку подпись пакета с исходниками от оригинального разработчики 
> (если он конечно их подписывает). а после можно и робота нарисовать для 
> проверки того что исходники из "нормального места" пришли.
Ну вот больше мне заняться нечем, кроме как искать подписи. Не, такое
ТОЛЬКО опционально.


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

Re: [devel] Re: Q: srpms buildrequires

[Igor Zubkov]

В сообщении от Четверг, 28-Июл-2005 05:45 Ivan Fedorov написал(a):
> > + запретить перепаковывать оригинальные исходники. (tar.gz->tar.bz2)
>
> Да ну? У вас видимо траффик халявный?..

Он не халявный, он э-э-э-э, рабочий! ;-)

> > + ложить в  srpm'ку подпись пакета с исходниками от оригинального
> > разработчики (если он конечно их подписывает). а после можно и робота
> > нарисовать для проверки того что исходники из "нормального места" пришли.
>
> Ну вот больше мне заняться нечем, кроме как искать подписи. Не, такое
> ТОЛЬКО опционально.

Как вариант.

Re: [devel] Re: Q: srpms buildrequires

[Andrey Rahmatullin]

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

On Thu, Jul 28, 2005 at 07:51:02PM +0300, Igor Zubkov wrote:
> Он не халявный, он э-э-э-э, рабочий! ;-)
То у вас.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> Не кидаю всё это в BTS так как хочу сначала спросить является ли это
> вообще ошибками или так всё и задумывалось.
Да, да. Это четко спланированная диверсия.
		-- aris in devel@

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

Re: [devel] Re: Q: srpms buildrequires

[Andrey Rahmatullin]

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

On Wed, Jul 27, 2005 at 11:59:57PM +0300, Igor Zubkov wrote:
> + запретить перепаковывать оригинальные исходники. (tar.gz->tar.bz2)
> + ложить в  srpm'ку подпись пакета с исходниками от оригинального разработчики 
> (если он конечно их подписывает). а после можно и робота нарисовать для 
> проверки того что исходники из "нормального места" пришли.
А как запаковываемые руками CVS-снапшоты?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> "Не давайте больному костыли, лучше научите его ходить" (с)
> А без красивых слов - надо просто править исходные коды и
> отсылать патчи в upstream.
Согласен.  Я постараюсь не забыть без -Wall -Werror этот модуль
в Сизиф не пропустить.
		-- ldv in sisyphus@

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

Re: [devel] Re: Q: srpms buildrequires

[Igor Zubkov]

В сообщении от Четверг, 28-Июл-2005 06:09 Andrey Rahmatullin написал(a):
> > + запретить перепаковывать оригинальные исходники. (tar.gz->tar.bz2)
> > + ложить в  srpm'ку подпись пакета с исходниками от оригинального
> > разработчики (если он конечно их подписывает). а после можно и робота
> > нарисовать для проверки того что исходники из "нормального места" пришли.
>
> А как запаковываемые руками CVS-снапшоты?

Варианта два:
1) в архиве вида tool-<date>.tar.bz2 лежит папка вида tool-<date>.
2) в архиве вида tool.tar.bz2 лежит папка вида tool.

Мне нравится 1 вариант.

Re: [devel] Re: Q: srpms buildrequires

[Andrey Rahmatullin]

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

On Thu, Jul 28, 2005 at 07:56:33PM +0300, Igor Zubkov wrote:
> > А как запаковываемые руками CVS-снапшоты?
> Варианта два:
Вопрос был не про именование, а про запрет перепаковки и про подписи.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Человека, который умудрился в 7 утра 1-го января перед тем
как лечь спать залить пакет в incoming уже не спасёт ничего :)
		-- mithraen in talk-room@

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

[devel] Re: Q: srpms buildrequires

[Michael Shigorin]

On Tue, Jul 19, 2005 at 04:07:30PM +0400, Alexey Gladkov wrote:
> Таким образом, BuildRequires в исходном пакете становятся
> архитектурно зависимыми. Но это нарушает основную идею SRPMS.
> Если у кого-нибудь есть конструктивные предложения прошу высказаться.

Кажется, Корчмарь бухтел про "слишком умные спеки" как раз 
по части исчезновения однозначности результата сборки...

> Единственным выходом мне видится, запрет на уровне полиси
> создания сборочных зависимостей зависящих от _сборочной
> архитектуры_ .  Подчеркиваю, что речь идет только про
> BuildRequires.

А можешь привести примеры?  Бишь что бывает различным?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: Q: srpms buildrequires

[Sergey Vlasov]

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

On Tue, Jul 19, 2005 at 03:39:50PM +0300, Michael Shigorin wrote:
> On Tue, Jul 19, 2005 at 04:07:30PM +0400, Alexey Gladkov wrote:
> > Таким образом, BuildRequires в исходном пакете становятся
> > архитектурно зависимыми. Но это нарушает основную идею SRPMS.
> > Если у кого-нибудь есть конструктивные предложения прошу высказаться.
> 
> Кажется, Корчмарь бухтел про "слишком умные спеки" как раз 
> по части исчезновения однозначности результата сборки...
> 
> > Единственным выходом мне видится, запрет на уровне полиси
> > создания сборочных зависимостей зависящих от _сборочной
> > архитектуры_ .  Подчеркиваю, что речь идет только про
> > BuildRequires.
> 
> А можешь привести примеры?  Бишь что бывает различным?

Вот, например, только что засунутое в kernel CVS изменение в
kernel-image-std26-up:

%ifarch x86_64
%add_patch_list kernel-fix-core-skbuff
%endif

На i586 этот патч, раздувающий struct sk_buff, мне применять не
хочется...

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

[devel] Re: Q: srpms buildrequires

[Michael Shigorin]

On Tue, Jul 19, 2005 at 04:59:34PM +0400, Sergey Vlasov wrote:
> > > Единственным выходом мне видится, запрет на уровне полиси
> > > создания сборочных зависимостей зависящих от _сборочной
> > > архитектуры_ .  Подчеркиваю, что речь идет только про
> > > BuildRequires.
> > А можешь привести примеры?  Бишь что бывает различным?
> Вот, например, только что засунутое в kernel CVS изменение в
> kernel-image-std26-up:
> 
> %ifarch x86_64
> %add_patch_list kernel-fix-core-skbuff
> %endif
> 
> На i586 этот патч, раздувающий struct sk_buff, мне применять не
> хочется...

srpm fork? :(

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] Re: Q: srpms buildrequires

[Michael Shigorin]

On Tue, Jul 19, 2005 at 04:59:34PM +0400, Sergey Vlasov wrote:
> %ifarch x86_64
> %add_patch_list kernel-fix-core-skbuff
> %endif
> На i586 этот патч, раздувающий struct sk_buff, мне применять не
> хочется...

OTOH: если это _один_ случай, возможно ли сделать piggybacking
через arch-specific .config?  В смысле прикладывать-то
прикладывать, но смотрелку в конфиг?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] Re: Q: srpms buildrequires

[Alexey Tourbin]

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

On Tue, Jul 19, 2005 at 04:59:34PM +0400, Sergey Vlasov wrote:
> %ifarch x86_64
> %add_patch_list kernel-fix-core-skbuff
> %endif
> 
> На i586 этот патч, раздувающий struct sk_buff, мне применять не
> хочется...

А можно эту логику вынести не в добавление патча, а собственно
в накладывание патча?

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

Re: [devel] Re: Q: srpms buildrequires

[Sergey Vlasov]

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

On Tue, Jul 19, 2005 at 05:06:20PM +0400, Alexey Tourbin wrote:
> On Tue, Jul 19, 2005 at 04:59:34PM +0400, Sergey Vlasov wrote:
> > %ifarch x86_64
> > %add_patch_list kernel-fix-core-skbuff
> > %endif
> > 
> > На i586 этот патч, раздувающий struct sk_buff, мне применять не
> > хочется...
> 
> А можно эту логику вынести не в добавление патча, а собственно
> в накладывание патча?

В накладывание, похоже, тоже плохо - могут появиться arch-specific
конфликты между патчами.  Видимо, придётся всё-таки накладывать этот
патч, но напихать туда каких-нибудь #ifdef.

Кстати, этого патча почему-то до сих пор нет в kernel CVS.

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

Re: [devel] Re: Q: srpms buildrequires

[Anton D. Kachalov]

On Tue, Jul 19, 2005 at 05:15:14PM +0400, Sergey Vlasov wrote:
> В накладывание, похоже, тоже плохо - могут появиться arch-specific
> конфликты между патчами.  Видимо, придётся всё-таки накладывать этот
> патч, но напихать туда каких-нибудь #ifdef.
> 
> Кстати, этого патча почему-то до сих пор нет в kernel CVS.
Сорри, уже там :)

--
mouse

Re: [devel] Re: Q: srpms buildrequires

[Alexey Gladkov]

Alexey Tourbin wrote:
> А можно эту логику вынести не в добавление патча, а собственно в
> накладывание патча?

Интересное предложение, но к сожалению оно слишком частное. Если
решить проблему с патчами в ядре это будет очень хорошо. Но у нас есть
такие не kernel пакеты.

Другой пример:
на i586 dbus собирается c mono
на x86_64 без.

-- 
Rgrds, legion

[devel] Re: Q: srpms buildrequires

[Michael Shigorin]

On Tue, Jul 19, 2005 at 05:17:40PM +0400, Alexey Gladkov wrote:
> Другой пример: на i586 dbus собирается c mono на x86_64 без.

Интересно, как это решали (если) в Debian?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: Q: srpms buildrequires

[Alexey Gladkov]

Michael Shigorin wrote:
> Интересно, как это решали (если) в Debian?

В Debian не rpm.

-- 
Rgrds, legion

Re: [devel] Re: Q: srpms buildrequires

[Kirill A. Shutemov]

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

On 17:39 Tue 19 Jul, Alexey Gladkov wrote:
> Michael Shigorin wrote:
> > Интересно, как это решали (если) в Debian?
> 
> В Debian не rpm.
> 
Врёшь! ;)
-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

Это вообще традицией уже становится вписал настройки в конфиг - chattr +i его
а не то какой-то очередной plug'n'pray туда влезет и "исправит" его.
		-- mrkooll in hardware@

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

Re: [devel] Re: Q: srpms buildrequires

[Alexey Gladkov]

Kirill A. Shutemov wrote:
> Врёшь! ;)

Можно ссылку на полный debian'овский rpm репозиторий ?

P.S. Я же написал про конструктивные предложения.

-- 
Rgrds, legion

[devel] Re: Q: srpms buildrequires

[Michael Shigorin]

On Tue, Jul 19, 2005 at 05:39:14PM +0400, Alexey Gladkov wrote:
> > Интересно, как это решали (если) в Debian?
> В Debian не rpm.

Сборочные зависимости-то есть?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: Q: srpms buildrequires

[Alexey I. Froloff]

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

* Sergey Vlasov <vsu@> [050719 17:00]:
> > А можешь привести примеры?  Бишь что бывает различным?
> %ifarch x86_64
> %add_patch_list kernel-fix-core-skbuff
> %endif
Ну тут наверно только делать архитектурно-зависимые патчи.
Накладывать только на определённой архитектуре.  Либо патчи
перелопачивать, либо допустимые архитектуры делать аргументами
%add_patch_list...

-- 
Regards, Sir Raorn.
-------------------
[...] как старый опытный светофор лучше молодого и зелёного
гаишника, так и старый добрый mhonarc лучше любых порывов
потратить время на обработку и публикацию, не дошедших до
логического завершения.
		-- mike in community@

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

Re: [devel] Re: Q: srpms buildrequires

[Anton D. Kachalov]

On Tue, Jul 19, 2005 at 05:06:24PM +0400, Alexey I. Froloff wrote:
> Ну тут наверно только делать архитектурно-зависимые патчи.
> Накладывать только на определённой архитектуре.  Либо патчи
> перелопачивать, либо допустимые архитектуры делать аргументами
> %add_patch_list...
Угу, что-то вроде:
%add_patch_list kernel-fix-core-skbuff x86_64 ...

@vsu?

--
mouse

Re: [devel] Re: Q: srpms buildrequires

[Denis Ovsienko]

> На i586 этот патч, раздувающий struct sk_buff, мне применять не
> хочется...
Нельзя использовать в патче что-то вида

#ifdef X86_64
[...]
#endif

?

-- 
    DO4-UANIC

Re: [devel] Re: Q: srpms buildrequires

[Anton D. Kachalov]

On Tue, Jul 19, 2005 at 05:35:12PM +0400, Denis Ovsienko wrote:
> Нельзя использовать в патче что-то вида
> 
> #ifdef X86_64
> [...]
> #endif

Не во всех случаях такое возможно. Это частность. Если говорить про тот же
dbus, то ручками и его можно заставить собираться. Это не решение.
Например, если мне вздумалось ещё поправить конфиг? Тогда что? ifdef в
конфиге? А если Makefile? Слишком много условий... Проще решить этот
вопрос на уровне применять/не применять патч :)

--
mouse

[devel] Re: Re: Q: srpms buildrequires

[Anton Farygin]

On Tue, 19 Jul 2005 17:28:38 +0400, Anton D. Kachalov wrote:

> On Tue, Jul 19, 2005 at 05:35:12PM +0400, Denis Ovsienko wrote:
>> Нельзя использовать в патче что-то вида
>> 
>> #ifdef X86_64
>> [...]
>> #endif
> 
> Не во всех случаях такое возможно. Это частность. Если говорить про тот же
> dbus, то ручками и его можно заставить собираться. Это не решение.
> Например, если мне вздумалось ещё поправить конфиг? Тогда что? ifdef в
> конфиге? А если Makefile? Слишком много условий... Проще решить этот
> вопрос на уровне применять/не применять патч :)

В случае с dbus нужно собрать mono под x86_64.

Или оторвать поддержку mono для всех архитектур.

Rgds,
Rider

[devel] Re: Q: srpms buildrequires

[Michael Shigorin]

On Tue, Jul 19, 2005 at 05:28:38PM +0400, Anton D. Kachalov wrote:
> Слишком много условий... Проще решить этот вопрос на уровне
> применять/не применять патч :)

По встречной тоже проще ездить иной раз.  В ряде случаев это даже
разрешено :)

Может, клинические случаи стоит решать srpm fork, если "проще"
разламывает околосборочные процессы?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: Q: srpms buildrequires

[Mikhail Zabaluev]

В Втр, 19/07/2005 в 15:39 +0300, Michael Shigorin пишет:
> On Tue, Jul 19, 2005 at 04:07:30PM +0400, Alexey Gladkov wrote:
> > Таким образом, BuildRequires в исходном пакете становятся
> > архитектурно зависимыми. Но это нарушает основную идею SRPMS.
> > Если у кого-нибудь есть конструктивные предложения прошу высказаться.
> 
> Кажется, Корчмарь бухтел про "слишком умные спеки" как раз 
> по части исчезновения однозначности результата сборки...

Этим, насколько я помню, также страдает нынешняя система сборки
python-модулей.

Re: [devel] Q: srpms buildrequires

[Sergey Vlasov]

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

On Tue, Jul 19, 2005 at 04:07:30PM +0400, Alexey Gladkov wrote:
> Таким образом, BuildRequires в исходном пакете становятся архитектурно
> зависимыми. Но это нарушает основную идею SRPMS.

Кстати, надо бы ввести по этому поводу проверку: после пересборки
пакета сравнивать BuildRequires исходного src.rpm и получившегося при
пересборке, при их несовпадении присылать мантейнеру хотя бы
предупреждение.  При этом ошибки типа той, что получилась при
пересборке ядер std26-2.6.11-alt11, отлавливались бы сразу.

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

[devel] Q: digital photo & quicktime MOV support

[Igor Vlasenko]

Уважаемые коллеги,

Хочу поделиться своими проблемами.

Купили мы недавно с другом цифровики с видеозаписью в quicktime *.MOV.
Видео в них пишется как motionJPEG, а звук у меня PCM, а у друга raw.

1. Воспроизведение.
Не было нативной поддержки звука.
xine молчит, mplayer молчит. Звук есть только через вражий dll из win32codecs 
(кстати, куда они подевались? в мастере 2.2 еще были прямо в SRPM mplayer'a,
а так пришлось руками ставить)
Однако вражий dll тормозит, и бедная бабушка на своем K6-2-500 под альт мастер 
не может нормально увидеть внука :(
при том, что mpeg4 у нее идет на ура.

Попробовал libquicktime --- 
с рсм были проблемы понимания, raw яко бы поняло, но шел сплошной свист.
последние версим libquicktime вроде бы лучше,
там свист перемежается членораздельными обрывками :)

Нашел openquicktime (пошло в Сизиф) 
Проэкт порядком заброшеный, однако аудиокодек хорош. 
С ней дружит gstreamer,
когда выложу openquicktime, повешу FR на %def_enable openquicktime.

2. Редактирование/монтаж.
Пока, как я понимаю, единственный способ сделать что-либо ---
mencoder'oм перегнать в avi (потеря качества???) и далее avidemux.
потом,  если благо, попробую через gstreamer.

нашел много интересного на heroinewarriors ---
буду собирать и смотреть.

А как с этим борется народ?
Хочу смонтировать отснятые куски под альтом.
Есть трудовой энтузиазм что-то собрать/попилить.
Кто что знает? 

-- 

Dr. Igor Vlasenko
--------------------
Topology Departament
Institute of Math
Kiev, Ukraine

[devel] Re: Q: digital photo & quicktime MOV support

[Michael Shigorin]

On Wed, Jul 20, 2005 at 04:47:13PM +0300, Igor Vlasenko wrote:
> А как с этим борется народ?

Не поддерживает козлов деньгами?  Моя камера делает MPEG,
например.  И QT был одним из поводов исключить из рассмотрения
несколько вариантов. (нет, им я про это писать обломался)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: Q: digital photo & quicktime MOV support

[Igor Vlasenko]

On Wed, 20 Jul 2005, Michael Shigorin wrote:

> On Wed, Jul 20, 2005 at 04:47:13PM +0300, Igor Vlasenko wrote:
> > А как с этим борется народ?
> 
> Не поддерживает козлов деньгами?  Моя камера делает MPEG,
> например.  И QT был одним из поводов исключить из рассмотрения
> несколько вариантов. (нет, им я про это писать обломался)
Нет, они не козлы...
Это же Motion JPEG + PCM (twos), самая что ни на есть простота.
Я историю про бабушку для затравки рассказал --- был я там 2 дня,
и там ооочень древний альлинукс стоит...
Проблема в другом. кодеков то навалом, свободных и открытых,
тот же mplayer спокойно играет с коробки -ac pcm -vc ffmjpeg.

Кодек pcm из mplayer'а юзает только mplayer, а тот же avidemux 
юзает свой набор. ffmjpeg там есть, а вот pcm -- нет.
у libquicktime кодек Motion JPEG есть,  кодек pcm есть, но глючит..
у openquicktime  кодек Motion JPEG есть,  кодек pcm есть, но глючит...
А бульдог с носорогом не скрещивается, поскольку нет такого API.
Чтобы положил кодек, а дальше все его юзают.

Собрал cinelerrу, может в ней получится что-то смонтировать.

-- 

Dr. Igor Vlasenko
--------------------
Topology Departament
Institute of Math
Kiev, Ukraine

[devel] [JT] Re: Q: digital photo & quicktime MOV support

[Michael Shigorin]

On Thu, Jul 21, 2005 at 08:09:32PM +0300, Igor Vlasenko wrote:
> у libquicktime кодек Motion JPEG есть,  кодек pcm есть, но глючит..
> у openquicktime  кодек Motion JPEG есть,  кодек pcm есть, но глючит...
> А бульдог с носорогом не скрещивается, поскольку нет такого API.
> Чтобы положил кодек, а дальше все его юзают.

"Ну и кто они после этого?" (ц)

PS: не, видать, не дано мне понять, где QT стандартней
и поддерживаемей MPEG1/2. :)

PPS: спасибо.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Q: srpms buildrequires

[Alexander Bokovoy]

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

On Tue, Jul 19, 2005 at 04:07:30PM +0400, Alexey Gladkov wrote:
> Таким образом, BuildRequires в исходном пакете становятся архитектурно
> зависимыми. Но это нарушает основную идею SRPMS.
> 
> Единственным выходом мне видится, запрет на уровне полиси создания
> сборочных зависимостей зависящих от _сборочной_архитектуры_ .
> Подчеркиваю, что речь идет только про BuildRequires.
Увы, придется с этим мириться. Поверь мне, есть несколько серьезных
причин, почему приходится так делать. 

Решение этой проблемы было в sandman.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

Re: [devel] Q: srpms buildrequires

[Anton D. Kachalov]

On Wed, Jul 20, 2005 at 07:44:34PM +0400, Alexander Bokovoy wrote:
> Увы, придется с этим мириться. Поверь мне, есть несколько серьезных
> причин, почему приходится так делать. 
> 
> Решение этой проблемы было в sandman.
А нельзя ли озвучить это решение?

--
mouse

[devel] Re: Q: srpms buildrequires

[Sergey Bolshakov]

>>>>> "Anton" == Anton D Kachalov <mouse@altlinux.org> writes:

 > On Wed, Jul 20, 2005 at 07:44:34PM +0400, Alexander Bokovoy wrote:
 >> Увы, придется с этим мириться. Поверь мне, есть несколько серьезных
 >> причин, почему приходится так делать. 
 >> 
 >> Решение этой проблемы было в sandman.
 > А нельзя ли озвучить это решение?

В sandman был запрет на прописывание исходников/патчей
в об'ifdef'ленной части. Вариации с (не)накладыванием патчей
и в части сборки были разрешены.
Информация (вместе с историей) о том, какие значения должна принимать
конкретная пара-тройка conditionals в даннном пакете хранилась
централизованно для каждого из репозитариев.
Вкратце, так.

-- 

Re: [devel] Re: Q: srpms buildrequires

[Alexey Gladkov]

Sergey Bolshakov wrote:
> В sandman был запрет на прописывание исходников/патчей
> в об'ifdef'ленной части. Вариации с (не)накладыванием патчей
> и в части сборки были разрешены.

Видимо я поступлю также, но с зависимостями.

-- 
Rgrds, legion

Re: [devel] Q: srpms buildrequires

[Alexey I. Froloff]

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

* Alexander Bokovoy <ab@> [050720 19:48]:
> > Единственным выходом мне видится, запрет на уровне полиси создания
> > сборочных зависимостей зависящих от _сборочной_архитектуры_ .
> > Подчеркиваю, что речь идет только про BuildRequires.
> Увы, придется с этим мириться. Поверь мне, есть несколько серьезных
> причин, почему приходится так делать. 
> Решение этой проблемы было в sandman.
На самом деле в sandman всплывают некоторые другие проблемы...
Которые решаются несколько ректальным способом.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Q: srpms buildrequires

[Sergey V Turchin]

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

В сообщении от Четверг 21 Июль 2005 00:51 Alexey I. Froloff 
написал(a):

[...]

> ректальным способом. 
Так же можно для пакета package в package.spec
BuildRequires: package-archbuildreq
а package-archbuildreq, соответственно, собирается под все 
архитекруры, и в package-archbuildreq.spec
%if_arch XX
Requires: YY

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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