[devel] Q: virtualbox

[devel] Q: virtualbox

[Anton D Kachalov]

Всем привет!

Никто не будет против, если я пособираю VirtualBox? На дворе уже 2.0. А 
у нас всё ещё 1.6.2, который несовместим с SMBIOS. Оч. хочется эту 
вкусняшку.

Rgds,
Anton

Re: [devel] Q: virtualbox

[Evgeny Sinelnikov]

9 сентября 2008 г. 15:32 пользователь Anton D Kachalov <mouse@mayc.ru> написал:
> Всем привет!
>
> Никто не будет против, если я пособираю VirtualBox? На дворе уже 2.0. А у
> нас всё ещё 1.6.2, который несовместим с SMBIOS. Оч. хочется эту вкусняшку.
>

Конечно не против... :)

Я с прошлой недели тестирую последний "стабильный" релиз 1.6.6 -
готовлю пакеты с перекладыванию в сизиф... вместе с новыми ядерными
модулями...

Затормозил на следующем - хотел собрать сразу и под x86_64... но
возникло два вопроса:
1) hasher не может нормально распознать разные билдовые зависимости:
%ifarch x86_64
BuildRequires: i586-gcc4.1 i586-libstdc++4.1-devel
%endif
Хотелось бы понять как можно обойти вопрос небходимости 32-битного
компилятора, а также любых дургих сборочных зависимостей, под
конкретную архитектуру...

2) Даже собранный не в hasher, virtualbox на x86_64 у меня номально не
завёлся - модуль грузится, машина запускается, но на стадии запуска
вываливает ошибку:

Unknown error creating VM.
VBox status code: -102 (VERR_FILE_NOT_FOUND).


Код ошибки:
0x80004005
Компонент:
Console
Интерфейс:
IConsole {d5a1cbda-f5d7-4824-9afe-d640c94c7dcf}



В общем сейчас я решил сделать новую сборку 1.6.6 только под i586, как
раньше, а далее уже чинить x86_64...

PS: когда всё почищу, залью всё в своё git.


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Q: virtualbox

[Anton D Kachalov]

Evgeny Sinelnikov wrote:
> Затормозил на следующем - хотел собрать сразу и под x86_64... но
> возникло два вопроса:
> 1) hasher не может нормально распознать разные билдовые зависимости:
> %ifarch x86_64
> BuildRequires: i586-gcc4.1 i586-libstdc++4.1-devel
> %endif
> Хотелось бы понять как можно обойти вопрос небходимости 32-битного
> компилятора, а также любых дургих сборочных зависимостей, под
> конкретную архитектуру...
>   
Если за пару лет ничего не изменилось, то BuildRequires прописывается 
жёстко в src.rpm. Вроде, была ручка у hasher'a, чтобы можно 
перезапаковать src.rpm при сборке под нужной архитектурой. А может и нет :)
> В общем сейчас я решил сделать новую сборку 1.6.6 только под i586, как
> раньше, а далее уже чинить x86_64...
>
> PS: когда всё почищу, залью всё в своё git.
>   
Может, стоит сразу 2.0? Оно вкуснее ;)

Rgds,
Anton

Re: [devel] Q: virtualbox

[Evgeny Sinelnikov]

9 сентября 2008 г. 15:58 пользователь Anton D Kachalov <mouse@mayc.ru> написал:
> Evgeny Sinelnikov wrote:
>>
>> Затормозил на следующем - хотел собрать сразу и под x86_64... но
>> возникло два вопроса:
>> 1) hasher не может нормально распознать разные билдовые зависимости:
>> %ifarch x86_64
>> BuildRequires: i586-gcc4.1 i586-libstdc++4.1-devel
>> %endif
>> Хотелось бы понять как можно обойти вопрос небходимости 32-битного
>> компилятора, а также любых дургих сборочных зависимостей, под
>> конкретную архитектуру...
>>
>
> Если за пару лет ничего не изменилось, то BuildRequires прописывается жёстко
> в src.rpm. Вроде, была ручка у hasher'a, чтобы можно перезапаковать src.rpm
> при сборке под нужной архитектурой. А может и нет :)
>>
>> В общем сейчас я решил сделать новую сборку 1.6.6 только под i586, как
>> раньше, а далее уже чинить x86_64...
>>
>> PS: когда всё почищу, залью всё в своё git.
>>
>
> Может, стоит сразу 2.0? Оно вкуснее ;)
>

Нужно собрать и проверить - разница в релизах в два дня не внушает
доверия... к тому же на сайте указано, что последняя стабильная версия
1.6.6... С другой стороны стабильность это для нового релиза не
определяет... следующим шагом будем собирать 2.0.0. Но для него нужно
решать вопрос 1) по поводу сборочных зависимостей на 32-битные пакеты
при сборке под x86_64.



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Q: virtualbox

[Evgeny Sinelnikov]

9 сентября 2008 г. 16:08 пользователь Evgeny Sinelnikov
<sin@altlinux.ru> написал:
> 9 сентября 2008 г. 15:58 пользователь Anton D Kachalov <mouse@mayc.ru> написал:
>> Evgeny Sinelnikov wrote:
>>>
>>> Затормозил на следующем - хотел собрать сразу и под x86_64... но
>>> возникло два вопроса:
>>> 1) hasher не может нормально распознать разные билдовые зависимости:
>>> %ifarch x86_64
>>> BuildRequires: i586-gcc4.1 i586-libstdc++4.1-devel
>>> %endif
>>> Хотелось бы понять как можно обойти вопрос небходимости 32-битного
>>> компилятора, а также любых дургих сборочных зависимостей, под
>>> конкретную архитектуру...
>>>
>>
>> Если за пару лет ничего не изменилось, то BuildRequires прописывается жёстко
>> в src.rpm. Вроде, была ручка у hasher'a, чтобы можно перезапаковать src.rpm
>> при сборке под нужной архитектурой. А может и нет :)
>>>
>>> В общем сейчас я решил сделать новую сборку 1.6.6 только под i586, как
>>> раньше, а далее уже чинить x86_64...
>>>
>>> PS: когда всё почищу, залью всё в своё git.
>>>
>>
>> Может, стоит сразу 2.0? Оно вкуснее ;)
>>
>
> Нужно собрать и проверить - разница в релизах в два дня не внушает
> доверия... к тому же на сайте указано, что последняя стабильная версия
> 1.6.6... С другой стороны стабильность это для нового релиза не
> определяет... следующим шагом будем собирать 2.0.0. Но для него нужно
> решать вопрос 1) по поводу сборочных зависимостей на 32-битные пакеты
> при сборке под x86_64.
>

В общем, есть два предложения или даже два с половиной:
1) добавить опцию --repackage-source при сборке пакета в инкаминге
2) держать разные исходные пакеты под разные архитектуры. Но тут есть
тоже два варианта:
- собирать под разные архитектуры пакеты с разными именами
- воспользоваться плоской моделью репозиториев, для которых нужно
научиться складывать разные исходные пакеты для разных архитектур в
свой каталог, но тогда и инкаминг долже уметь брать пакеты для сборки
под конкретную архитектуру.

Поскольку, вариант 2 выглядит проблематичным предлагаю вариант 1.

Есть правда ещё один вариант... У меня-то, до момента пересборки
пакета собранного для i586 на x86_64, вообще проблем никаких не было -
я давно собираю из gear, с помощью gear-hsh. Может инкамингу пора
научиться собирать из git?



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Q: virtualbox

[Michael Shigorin]

On Tue, Sep 09, 2008 at 08:57:26PM +0400, Evgeny Sinelnikov wrote:
> 1) добавить опцию --repackage-source при сборке пакета в инкаминге

Подпись слетит.

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

Re: [devel] Q: virtualbox

[Evgeny Sinelnikov]

9 сентября 2008 г. 20:59 пользователь Michael Shigorin
<mike@osdn.org.ua> написал:
> On Tue, Sep 09, 2008 at 08:57:26PM +0400, Evgeny Sinelnikov wrote:
>> 1) добавить опцию --repackage-source при сборке пакета в инкаминге
>
> Подпись слетит.
>

Нужно класть в исходники первичный пакет, а не тот, который hasher собирёт...

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Q: virtualbox

[Led]

On Tuesday, 09 September 2008 23:05:08 Evgeny Sinelnikov wrote:
> 9 сентября 2008 г. 20:59 пользователь Michael Shigorin
>
> <mike@osdn.org.ua> написал:
> > On Tue, Sep 09, 2008 at 08:57:26PM +0400, Evgeny Sinelnikov wrote:
> >> 1) добавить опцию --repackage-source при сборке пакета в инкаминге
> >
> > Подпись слетит.
>
> Нужно класть в исходники первичный пакет, а не тот, который hasher
> собирёт...

Давайте лучше "пилить" rpm с поддержкой biarch и исправлять пакеты, чтоб они 
были biarch-ready, а не городить костыли.

-- 
Led

Re: [devel] Q: virtualbox

[Anton D Kachalov]

Led wrote:
> Давайте лучше "пилить" rpm с поддержкой biarch и исправлять пакеты, чтоб они 
> были biarch-ready, а не городить костыли.
>
>   

Проблема несколько глубже, чем biarch. Например, мы собираем пакет, 
который, взависимости от архитектуры (ix86, x86_64, ppc, s390, so on...) 
хочет разные пакеты. Например, некий враппер между бут-лоадерами.

В общем, я ща пилю rpm до следующего состояния. Можно задавать 
зависимости вида
# Common build reqs
BuildRequires: foo >= 9.0-alt1 bar
REQUIRENAME будет [foo >= 9.0-alt1, bar]

# x86_64 build reqs
BuildRequires(arch:x86_64): xyz64
REQUIRENAME будет [xyz64(arch:x86_64)]

# ppc build reqs
BuildRequires(arch:ppc64): zyx >= 1.0
REQUIRENAME будет [zyx(arch:ppc64) >= 1.0]

Частично уже написал :) Осталось выдрессировать rpmdepCheck распознавать 
arch:xyz в зависимостях.
В спеке "arch:xyz" распознаётся ток для тегов BuildRequires & BuildPreReq.

Rgds,
Anton

Re: [devel] rpm

[Dmitry V. Levin]

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

On Wed, Sep 10, 2008 at 03:30:19AM +0400, Anton D Kachalov wrote:
[...]
> В общем, я ща пилю rpm до следующего состояния. Можно задавать 
> зависимости вида
> # Common build reqs
> BuildRequires: foo >= 9.0-alt1 bar
> REQUIRENAME будет [foo >= 9.0-alt1, bar]
> 
> # x86_64 build reqs
> BuildRequires(arch:x86_64): xyz64
> REQUIRENAME будет [xyz64(arch:x86_64)]
> 
> # ppc build reqs
> BuildRequires(arch:ppc64): zyx >= 1.0
> REQUIRENAME будет [zyx(arch:ppc64) >= 1.0]
> 
> Частично уже написал :) Осталось выдрессировать rpmdepCheck распознавать 
> arch:xyz в зависимостях.
> В спеке "arch:xyz" распознаётся ток для тегов BuildRequires & BuildPreReq.

Апстримные rpmы смотрел?  Получится совместимый синтаксис или нет?


-- 
ldv

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

Re: [devel] Q: virtualbox

[Led]

On Wednesday, 10 September 2008 02:30:19 Anton D Kachalov wrote:
> Led wrote:
> > Давайте лучше "пилить" rpm с поддержкой biarch и исправлять пакеты, чтоб
> > они были biarch-ready, а не городить костыли.
>
> Проблема несколько глубже, чем biarch. Например, мы собираем пакет,
> который, взависимости от архитектуры (ix86, x86_64, ppc, s390, so on...)
> хочет разные пакеты. Например, некий враппер между бут-лоадерами.
>
> В общем, я ща пилю rpm до следующего состояния. Можно задавать
> зависимости вида
> # Common build reqs
> BuildRequires: foo >= 9.0-alt1 bar
> REQUIRENAME будет [foo >= 9.0-alt1, bar]
>
> # x86_64 build reqs
> BuildRequires(arch:x86_64): xyz64
> REQUIRENAME будет [xyz64(arch:x86_64)]
>
> # ppc build reqs
> BuildRequires(arch:ppc64): zyx >= 1.0
> REQUIRENAME будет [zyx(arch:ppc64) >= 1.0]
>
> Частично уже написал :) Осталось выдрессировать rpmdepCheck распознавать
> arch:xyz в зависимостях.
> В спеке "arch:xyz" распознаётся ток для тегов BuildRequires & BuildPreReq.

Я делал такое, без всякого хакания rpm.
Заводится виртуальный пакет zyx-multiarch, в котором проставляются Requires в 
зависимости от архитектуры. Этот zyx-multiarch и проставляется в 
BuildRequires.
Посмотрите на anyasm - он как раз для такого случая, как вы описали.

-- 
Led

Re: [devel] Q: virtualbox

[Alexey Tourbin]

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

On Wed, Sep 10, 2008 at 03:30:19AM +0400, Anton D Kachalov wrote:
> Проблема несколько глубже, чем biarch. 
> Например, мы собираем пакет, который, 
> взависимости от архитектуры (ix86, x86_64, ppc, 
> s390, so on...) хочет разные пакеты. Например, 
> некий враппер между бут-лоадерами.
> 
> В общем, я ща пилю rpm до следующего 
> состояния. Можно задавать зависимости 
> вида
> # Common build reqs
> BuildRequires: foo >= 9.0-alt1 bar
> REQUIRENAME будет [foo >= 9.0-alt1, bar]
> 
> # x86_64 build reqs
> BuildRequires(arch:x86_64): xyz64
> REQUIRENAME будет [xyz64(arch:x86_64)]
> 
> # ppc build reqs
> BuildRequires(arch:ppc64): zyx >= 1.0
> REQUIRENAME будет [zyx(arch:ppc64) >= 1.0]
> 
> Частично уже написал :) Осталось 
> выдрессировать rpmdepCheck распознавать arch:xyz 
> в зависимостях.
> В спеке "arch:xyz" распознаётся ток для тегов 
> BuildRequires & BuildPreReq.

Будет ли работать 'apt-get build-dep'?

Вообще, зависимости rpm сейчас имеют чисто текстовое представление.
Это имеет, например, такое важное преимущество, что совершенно
естественным образом работает соединение requires на provides.
А если одна и та же зависимость будет допускать различное текстовое
представление, то это будет major pitfall -- уже нельзя будет искать
provides по текстовому совпадению с названием зависимости requires.

Прошу заранее анонсировать нетривиальные изменения в rpm,
с подробной мотивацией и идеей реализации.

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

Re: [devel] rpm

[Anton D Kachalov]

Dmitry V. Levin wrote:
> On Wed, Sep 10, 2008 at 03:30:19AM +0400, Anton D Kachalov wrote:
> [...]
>   
> Апстримные rpmы смотрел?  Получится совместимый синтаксис или нет?
>
>   
Вот поглядел гит. Ничего не нашёл. И в парсинге buildrequires всё точно 
так же, как и десять лет назад :)
Могёшь ткнуть пальцем, если оно там есть?

Rgds,
Anton

Re: [devel] Q: virtualbox

[Anton D Kachalov]

Anton D Kachalov wrote:
> Частично уже написал :) Осталось выдрессировать rpmdepCheck 
> распознавать arch:xyz в зависимостях.
> В спеке "arch:xyz" распознаётся ток для тегов BuildRequires & 
> BuildPreReq.
>
Хорошо, давайте сделаю проще. Физически, в файле будет прописано то, что 
я описал. Любые же попытки получить REQUIRENAME будут враппить мои 
хитрые зависимости в соответствии с хостовым arch'ем. Есть только одно 
но - на x86 не увидеть специфичных зависимостей в src.rpm для 
x86_64/ppc/... Думаю, что для src.rpm это не смертельно. Одно НО - 
hasher тащит зависимости прямо из спека awk'ом. Тут-то hsh'ый "--target" 
можно и распарсить, если собираем пакет через qemu. Встаёт вопрос как 
быть с compact arches. Множественные sed'ы? В остальном, криминала не вижу.

Rgds,
Anton

Re: [devel] Q: virtualbox

[Kirill A. Shutemov]

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

On Wed, Sep 10, 2008 at 03:21:15AM +0300, Led wrote:
> On Wednesday, 10 September 2008 02:30:19 Anton D Kachalov wrote:
> > Led wrote:
> > > Давайте лучше "пилить" rpm с поддержкой biarch и исправлять пакеты, чтоб
> > > они были biarch-ready, а не городить костыли.
> >
> > Проблема несколько глубже, чем biarch. Например, мы собираем пакет,
> > который, взависимости от архитектуры (ix86, x86_64, ppc, s390, so on...)
> > хочет разные пакеты. Например, некий враппер между бут-лоадерами.
> >
> > В общем, я ща пилю rpm до следующего состояния. Можно задавать
> > зависимости вида
> > # Common build reqs
> > BuildRequires: foo >= 9.0-alt1 bar
> > REQUIRENAME будет [foo >= 9.0-alt1, bar]
> >
> > # x86_64 build reqs
> > BuildRequires(arch:x86_64): xyz64
> > REQUIRENAME будет [xyz64(arch:x86_64)]
> >
> > # ppc build reqs
> > BuildRequires(arch:ppc64): zyx >= 1.0
> > REQUIRENAME будет [zyx(arch:ppc64) >= 1.0]
> >
> > Частично уже написал :) Осталось выдрессировать rpmdepCheck распознавать
> > arch:xyz в зависимостях.
> > В спеке "arch:xyz" распознаётся ток для тегов BuildRequires & BuildPreReq.
> 
> Я делал такое, без всякого хакания rpm.
> Заводится виртуальный пакет zyx-multiarch, в котором проставляются Requires в 
> зависимости от архитектуры. Этот zyx-multiarch и проставляется в 
> BuildRequires.
> Посмотрите на anyasm - он как раз для такого случая, как вы описали.

Это костыль, который плодит сущности без необходимости.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] Q: virtualbox

[Anton D Kachalov]

Led wrote:
> On Wednesday, 10 September 2008 02:30:19 Anton D Kachalov wrote:
>   
>> Led wrote:
>>     
>>> Давайте лучше "пилить" rpm с поддержкой biarch и исправлять пакеты, чтоб
>>> они были biarch-ready, а не городить костыли.
>>>       
>> Проблема несколько глубже, чем biarch. Например, мы собираем пакет,
>> который, взависимости от архитектуры (ix86, x86_64, ppc, s390, so on...)
>> хочет разные пакеты. Например, некий враппер между бут-лоадерами.
>>
>> В общем, я ща пилю rpm до следующего состояния. Можно задавать
>> зависимости вида
>> # Common build reqs
>> BuildRequires: foo >= 9.0-alt1 bar
>> REQUIRENAME будет [foo >= 9.0-alt1, bar]
>>
>> # x86_64 build reqs
>> BuildRequires(arch:x86_64): xyz64
>> REQUIRENAME будет [xyz64(arch:x86_64)]
>>
>> # ppc build reqs
>> BuildRequires(arch:ppc64): zyx >= 1.0
>> REQUIRENAME будет [zyx(arch:ppc64) >= 1.0]
>>
>> Частично уже написал :) Осталось выдрессировать rpmdepCheck распознавать
>> arch:xyz в зависимостях.
>> В спеке "arch:xyz" распознаётся ток для тегов BuildRequires & BuildPreReq.
>>     
>
> Я делал такое, без всякого хакания rpm.
> Заводится виртуальный пакет zyx-multiarch, в котором проставляются Requires в 
> зависимости от архитектуры. Этот zyx-multiarch и проставляется в 
> BuildRequires.
> Посмотрите на anyasm - он как раз для такого случая, как вы описали.
>
>   
Х-м-м, для сильно разборчивого к arch'у пакета my, держать 
my-multiarch.{i586,ppc,sparc,x86_64}.rpm в которых будут соответствующие 
специфичные за'ifdef'ленные зависимости? Больно на ногу наступать - 
берём костыль.

В общем, дорогой all, какие есть ещё предложения по хаканию RPM? :)

Rgds,
Anton

Re: [devel] Q: virtualbox

[Anton Farygin]

Anton D Kachalov пишет:
> Led wrote:
>> On Wednesday, 10 September 2008 02:30:19 Anton D Kachalov wrote:
>>  
>>> Led wrote:
>>>    
>>>> Давайте лучше "пилить" rpm с поддержкой biarch и исправлять пакеты, 
>>>> чтоб
>>>> они были biarch-ready, а не городить костыли.
>>>>       
>>> Проблема несколько глубже, чем biarch. Например, мы собираем пакет,
>>> который, взависимости от архитектуры (ix86, x86_64, ppc, s390, so on...)
>>> хочет разные пакеты. Например, некий враппер между бут-лоадерами.
>>>
>>> В общем, я ща пилю rpm до следующего состояния. Можно задавать
>>> зависимости вида
>>> # Common build reqs
>>> BuildRequires: foo >= 9.0-alt1 bar
>>> REQUIRENAME будет [foo >= 9.0-alt1, bar]
>>>
>>> # x86_64 build reqs
>>> BuildRequires(arch:x86_64): xyz64
>>> REQUIRENAME будет [xyz64(arch:x86_64)]
>>>
>>> # ppc build reqs
>>> BuildRequires(arch:ppc64): zyx >= 1.0
>>> REQUIRENAME будет [zyx(arch:ppc64) >= 1.0]
>>>
>>> Частично уже написал :) Осталось выдрессировать rpmdepCheck распознавать
>>> arch:xyz в зависимостях.
>>> В спеке "arch:xyz" распознаётся ток для тегов BuildRequires & 
>>> BuildPreReq.
>>>     
>>
>> Я делал такое, без всякого хакания rpm.
>> Заводится виртуальный пакет zyx-multiarch, в котором проставляются 
>> Requires в зависимости от архитектуры. Этот zyx-multiarch и 
>> проставляется в BuildRequires.
>> Посмотрите на anyasm - он как раз для такого случая, как вы описали.
>>
>>   
> Х-м-м, для сильно разборчивого к arch'у пакета my, держать 
> my-multiarch.{i586,ppc,sparc,x86_64}.rpm в которых будут соответствующие 
> специфичные за'ifdef'ленные зависимости? Больно на ногу наступать - 
> берём костыль.
> 
> В общем, дорогой all, какие есть ещё предложения по хаканию RPM? :)

Захакать rpm-5.1.4 ;)

Re: [devel] Q: virtualbox

[Anton D Kachalov]

Anton Farygin wrote:
> Anton D Kachalov пишет:
>> [...]
>> В общем, дорогой all, какие есть ещё предложения по хаканию RPM? :)
>
> Захакать rpm-5.1.4 ;)
У меня до сих пор сохранился недохаченный rpm4.4...можно продолжить 
изысканное хакание :)
Насчёт того, как поступить с hasher'ом и его awk-скриптом. В теории, 
можно добавить  тип вывода в lib/rpmtag.h для 
RPMTAG_BUILD{PREREQ,REQUIRES} и тогда можно запрашивать requires 
командой rpm -q --qf '[%{BUILDREQUIRES}\n]' --specfile myspec.spec. Но 
вопрос передачи target'a останется открытым.
Либо же, добавить в rpmbuild параметр -bR и получать соответствующий 
список зависимостей с учётом переданного target.
Второй вариант мне нра больше.
Разумеется, что хак с arch:target будет. Но разруливать его будем на 
уровне предложенного выше варианта - враппера в query.

Rgds,
Anton

Re: [devel] Q: virtualbox

[Alexey I. Froloff]

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

* Anton D Kachalov <mouse@> [080910 13:39]:
> Насчёт того, как поступить с hasher'ом и его awk-скриптом.
Его "awk-скрипт" используется только для BuildRequires(pre),
необходимый минимум макросов чтобы работал rpm -bs --nodeps.  Как
часто там могут возникать такие "архитектурно-зависимые"
зависимости, извините за тавтологию?

-- 
Regards,
Sir Raorn.

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

Re: [devel] rpm-5

[Anton Farygin]

Anton D Kachalov пишет:
> Anton Farygin wrote:
>> Anton D Kachalov пишет:
>>> [...]
>>> В общем, дорогой all, какие есть ещё предложения по хаканию RPM? :)
>>
>> Захакать rpm-5.1.4 ;)
> У меня до сих пор сохранился недохаченный rpm4.4...можно продолжить 
> изысканное хакание :)

Лучше сразу на rpm-5

Там, правда, придётся начинать с нуля.

Re: [devel] Q: virtualbox

[Led]

On Wednesday 10 September 2008 12:49:31 Alexey I. Froloff wrote:
> * Anton D Kachalov <mouse@> [080910 13:39]:
> > Насчёт того, как поступить с hasher'ом и его awk-скриптом.
>
> Его "awk-скрипт" используется только для BuildRequires(pre),
> необходимый минимум макросов чтобы работал rpm -bs --nodeps.  Как
> часто там могут возникать такие "архитектурно-зависимые"
> зависимости, извините за тавтологию?

Не более 0.1% от всех пакетов

-- 
Led

Re: [devel] rpm-5

[Anton D Kachalov]

Anton Farygin wrote:
> [...]
>>> Захакать rpm-5.1.4 ;)
>> У меня до сих пор сохранился недохаченный rpm4.4...можно продолжить 
>> изысканное хакание :)
>
> Лучше сразу на rpm-5
>
> Там, правда, придётся начинать с нуля.
Не будем сгущать краски :) Там не так уж и много кода отличается от 
апстримного.

Rgds,
Anton

Re: [devel] Q: virtualbox

[Anton D Kachalov]

Alexey I. Froloff wrote:
> * Anton D Kachalov <mouse@> [080910 13:39]:
>   
>> Насчёт того, как поступить с hasher'ом и его awk-скриптом.
>>     
> Его "awk-скрипт" используется только для BuildRequires(pre),
> необходимый минимум макросов чтобы работал rpm -bs --nodeps.  Как
> часто там могут возникать такие "архитектурно-зависимые"
> зависимости, извините за тавтологию?
>   
Думаю, что не должно быть вообще. Если потом делается rpmbuild -bs 
--nodeps --target=... то можно обойтись и одними ifdef'aми. Странно, что 
кто-то поделывал костыли, если пакеты всё равно ребилдятся. Но в целях 
ненарушения подписи, всё-таки можно добавить фичу :)

Rgds,
Anton
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Q: virtualbox

[Anton D Kachalov]

Led wrote:
> [...]
> Не более 0.1% от всех пакетов
>   
Которые хотят arch-dependent макросы?

Rgds,
Anton

Re: [devel] Q: virtualbox

[Evgeny Sinelnikov]

10 сентября 2008 г. 16:44 пользователь Led <ledest@gmail.com> написал:
> On Wednesday 10 September 2008 12:49:31 Alexey I. Froloff wrote:
>> * Anton D Kachalov <mouse@> [080910 13:39]:
>> > Насчёт того, как поступить с hasher'ом и его awk-скриптом.
>>
>> Его "awk-скрипт" используется только для BuildRequires(pre),
>> необходимый минимум макросов чтобы работал rpm -bs --nodeps.  Как
>> часто там могут возникать такие "архитектурно-зависимые"
>> зависимости, извините за тавтологию?
>
> Не более 0.1% от всех пакетов
>

К сожалению, многим таким зависимостей не хватает... А в связи с этим
обламывается их сборка из git, с помощью gear-hsh. Может быть добавить
проверку на необходимость таких зависимостей в repocop?


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Q: virtualbox

[Led]

On Wednesday 10 September 2008 17:26:14 Evgeny Sinelnikov wrote:
> 10 сентября 2008 г. 16:44 пользователь Led <ledest@gmail.com> написал:
> > On Wednesday 10 September 2008 12:49:31 Alexey I. Froloff wrote:
> >> * Anton D Kachalov <mouse@> [080910 13:39]:
> >> > Насчёт того, как поступить с hasher'ом и его awk-скриптом.
> >>
> >> Его "awk-скрипт" используется только для BuildRequires(pre),
> >> необходимый минимум макросов чтобы работал rpm -bs --nodeps.  Как
> >> часто там могут возникать такие "архитектурно-зависимые"
> >> зависимости, извините за тавтологию?
> >
> > Не более 0.1% от всех пакетов
>
> К сожалению, многим таким зависимостей не хватает... А в связи с этим
> обламывается их сборка из git, с помощью gear-hsh. Может быть добавить
> проверку на необходимость таких зависимостей в repocop?

"Многим" - чёткий критерий:) Я не увидел здесь ни одного КОНКРЕТНОГО случая.

-- 
Led

Re: [devel] Q: virtualbox

[Evgeny Sinelnikov]

10 сентября 2008 г. 18:34 пользователь Led <ledest@gmail.com> написал:
> On Wednesday 10 September 2008 17:26:14 Evgeny Sinelnikov wrote:
>> 10 сентября 2008 г. 16:44 пользователь Led <ledest@gmail.com> написал:
>> > On Wednesday 10 September 2008 12:49:31 Alexey I. Froloff wrote:
>> >> * Anton D Kachalov <mouse@> [080910 13:39]:
>> >> > Насчёт того, как поступить с hasher'ом и его awk-скриптом.
>> >>
>> >> Его "awk-скрипт" используется только для BuildRequires(pre),
>> >> необходимый минимум макросов чтобы работал rpm -bs --nodeps.  Как
>> >> часто там могут возникать такие "архитектурно-зависимые"
>> >> зависимости, извините за тавтологию?
>> >
>> > Не более 0.1% от всех пакетов
>>
>> К сожалению, многим таким зависимостей не хватает... А в связи с этим
>> обламывается их сборка из git, с помощью gear-hsh. Может быть добавить
>> проверку на необходимость таких зависимостей в repocop?
>
> "Многим" - чёткий критерий:) Я не увидел здесь ни одного КОНКРЕТНОГО случая.
>

полного списка у меня и нет, но статистически их должно быть
достаточно... Я эту гипотезу делаю на основании того, что с
произвольными, время от времени собираемыми пакетами, возникают такие
проблемы. Примеры:
- в kdelibs-3.5.10-alt1 необходим BuildRequires(pre): kde-common-devel:
[...]
warning: Macro %_K_if_ver_lt not found
error: line 9: Unknown tag: %_K_if_ver_lt 2.5.1 2.5
hsh-rebuild: pkg.tar: failed to fetch build dependencies.

- в пакете apache2-mod_clamav-0.21-alt4.1 BuildRequires(pre): apache2-devel
[...]
warning: Macro %apache_apxs not found
warning: Macro %a_mods_available not found
warning: Macro %apache_addonconfdir not found
warning: Macro %apache_moduledir not found
warning: Macro %a_mods_start not found
warning: Macro %apache_moduledir not found
warning: Macro %a_mods_available not found
warning: Macro %a_mods_available not found
warning: Macro %a_mods_start not found
warning: Macro %apache_addonconfdir not found
error: Macro %a_sbindir not found
error: line 48: %a_sbindir/a2chkconfig

Installing apache2-mod_clamav-0.21-alt4.1.src.rpm
Building target platforms: i586
Building for target i586
Command exited with non-zero status 1
0.16user 0.00system 0:00.16elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+664outputs (0major+668minor)pagefaults 0swaps
hsh-rebuild: rebuild of `pkg.tar' failed.

- в пакетах использующих макросы лицензий, например вида
License: %gpl2plus
необходима зависимость BuildRequires(pre): rpm-build-licenses

Я так с ходу больше, сразу не перечислю... Идея как раз была в том,
чтобы сделать это автоматически, уточнив мою гипотезу, подтверждённую
в некоторой степени, на практике...


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Q: virtualbox

[Led]

On Wednesday 10 September 2008 18:16:22 Evgeny Sinelnikov wrote:
> 10 сентября 2008 г. 18:34 пользователь Led <ledest@gmail.com> написал:
> > On Wednesday 10 September 2008 17:26:14 Evgeny Sinelnikov wrote:
> >> 10 сентября 2008 г. 16:44 пользователь Led <ledest@gmail.com> написал:
> >> > On Wednesday 10 September 2008 12:49:31 Alexey I. Froloff wrote:
> >> >> * Anton D Kachalov <mouse@> [080910 13:39]:
> >> >> > Насчёт того, как поступить с hasher'ом и его awk-скриптом.
> >> >>
> >> >> Его "awk-скрипт" используется только для BuildRequires(pre),
> >> >> необходимый минимум макросов чтобы работал rpm -bs --nodeps.  Как
> >> >> часто там могут возникать такие "архитектурно-зависимые"
> >> >> зависимости, извините за тавтологию?
> >> >
> >> > Не более 0.1% от всех пакетов
> >>
> >> К сожалению, многим таким зависимостей не хватает... А в связи с этим
> >> обламывается их сборка из git, с помощью gear-hsh. Может быть добавить
> >> проверку на необходимость таких зависимостей в repocop?
> >
> > "Многим" - чёткий критерий:) Я не увидел здесь ни одного КОНКРЕТНОГО
> > случая.
>
> полного списка у меня и нет, но статистически их должно быть
> достаточно... Я эту гипотезу делаю на основании того, что с
> произвольными, время от времени собираемыми пакетами, возникают такие
> проблемы. Примеры:
> - в kdelibs-3.5.10-alt1 необходим BuildRequires(pre): kde-common-devel:
> [...]
> warning: Macro %_K_if_ver_lt not found
> error: line 9: Unknown tag: %_K_if_ver_lt 2.5.1 2.5
> hsh-rebuild: pkg.tar: failed to fetch build dependencies.
>
> - в пакете apache2-mod_clamav-0.21-alt4.1 BuildRequires(pre): apache2-devel
> [...]
> warning: Macro %apache_apxs not found
> warning: Macro %a_mods_available not found
> warning: Macro %apache_addonconfdir not found
> warning: Macro %apache_moduledir not found
> warning: Macro %a_mods_start not found
> warning: Macro %apache_moduledir not found
> warning: Macro %a_mods_available not found
> warning: Macro %a_mods_available not found
> warning: Macro %a_mods_start not found
> warning: Macro %apache_addonconfdir not found
> error: Macro %a_sbindir not found
> error: line 48: %a_sbindir/a2chkconfig
>
> Installing apache2-mod_clamav-0.21-alt4.1.src.rpm
> Building target platforms: i586
> Building for target i586
> Command exited with non-zero status 1
> 0.16user 0.00system 0:00.16elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+664outputs (0major+668minor)pagefaults 0swaps
> hsh-rebuild: rebuild of `pkg.tar' failed.
>
> - в пакетах использующих макросы лицензий, например вида
> License: %gpl2plus
> необходима зависимость BuildRequires(pre): rpm-build-licenses
>
> Я так с ходу больше, сразу не перечислю... Идея как раз была в том,
> чтобы сделать это автоматически, уточнив мою гипотезу, подтверждённую
> в некоторой степени, на практике...

Ну, и где здесь архитектурно-специфичные зависимости?

-- 
Led

Re: [devel] Q: virtualbox

[Alexey I. Froloff]

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

* Led <ledest@> [080910 19:54]:
> Ну, и где здесь архитектурно-специфичные зависимости?
Разговор мягко спрыгнул на BuildRequires(pre) "в принципе".

-- 
Regards,
Sir Raorn.

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

Re: [devel] Q: virtualbox

[Evgeny Sinelnikov]

10 сентября 2008 г. 19:56 пользователь Alexey I. Froloff
<raorn@altlinux.ru> написал:
> * Led <ledest@> [080910 19:54]:
>> Ну, и где здесь архитектурно-специфичные зависимости?
> Разговор мягко спрыгнул на BuildRequires(pre) "в принципе".

Перечитал... ну, да... как-то я так отклонился от темы, что сам чёткой
логики не прослеживаю... Тем не менее вопросы по BuildRequires(pre)
остаются, но это отдельная тема...



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Q: apache2-mod_clamav-0.21-alt4.1 (was: virtualbox)

[Aleksey Avdeev]

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

Evgeny Sinelnikov пишет:
...
> 
> - в пакете apache2-mod_clamav-0.21-alt4.1 BuildRequires(pre): apache2-devel
> [...]
> warning: Macro %apache_apxs not found
> warning: Macro %a_mods_available not found
> warning: Macro %apache_addonconfdir not found
> warning: Macro %apache_moduledir not found
> warning: Macro %a_mods_start not found
> warning: Macro %apache_moduledir not found
> warning: Macro %a_mods_available not found
> warning: Macro %a_mods_available not found
> warning: Macro %a_mods_start not found
> warning: Macro %apache_addonconfdir not found
> error: Macro %a_sbindir not found
> error: line 48: %a_sbindir/a2chkconfig
> 
> Installing apache2-mod_clamav-0.21-alt4.1.src.rpm
> Building target platforms: i586
> Building for target i586
> Command exited with non-zero status 1
> 0.16user 0.00system 0:00.16elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+664outputs (0major+668minor)pagefaults 0swaps
> hsh-rebuild: rebuild of `pkg.tar' failed.

   Этому для исправления rpm-macros-apache2-compat достаточно, наверное, 
будет...

-- 

С уважением. Алексей.



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

Re: [devel] rpm

[Wartan Hachaturow]

2008/9/10 Anton D Kachalov <mouse@mayc.ru>:

> Вот поглядел гит. Ничего не нашёл. И в парсинге buildrequires всё точно так
> же, как и десять лет назад :)
> Могёшь ткнуть пальцем, если оно там есть?

Оно было. jbj его выкинул довольно давно ещё, поскольку по его мнению
делать такое в rpm-мире неправильно, ибо arch namespace очень широкий.
Ну типа ppc бывает куча разных: ppc, ppc64, ppcpseries, ppciseries и
так далее. Been there, asked that :)

Найди лучше этот патчик, не пиши заново.

-- 
Regards, Wartan.

Re: [devel] rpm

[Anton D Kachalov]

Wartan Hachaturow wrote:
> [...]
> Оно было. jbj его выкинул довольно давно ещё, поскольку по его мнению
> делать такое в rpm-мире неправильно, ибо arch namespace очень широкий.
> Ну типа ppc бывает куча разных: ppc, ppc64, ppcpseries, ppciseries и
> так далее. Been there, asked that :)
>
> Найди лучше этот патчик, не пиши заново.
>
>   
Дык, нам ж ток для src.rpm, дабы не перепаковывать. Для большего и 
ненужно. Попробую поискать.
Насчёт ppc/не ппц, это вопрос манейнера. Тем более, какая разница:
  %ifarch ppcpseries ppc64
  BuildRequires: foo_p
  %endif
и:
  BuildRequires(arch:ppcseries,arch:ppc64): foo_p
? :)

Зависимости прописывает мантейнер. И это уже его головная боль.

Rgds,
Anton

Re: [devel] rpm

[Kirill A. Shutemov]

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

On Thu, Sep 11, 2008 at 11:50:19AM +0400, Anton D Kachalov wrote:
> Wartan Hachaturow wrote:
> > [...]
> > Оно было. jbj его выкинул довольно давно ещё, поскольку по его мнению
> > делать такое в rpm-мире неправильно, ибо arch namespace очень широкий.
> > Ну типа ppc бывает куча разных: ppc, ppc64, ppcpseries, ppciseries и
> > так далее. Been there, asked that :)
> >
> > Найди лучше этот патчик, не пиши заново.
> >
> >   
> Дык, нам ж ток для src.rpm, дабы не перепаковывать. Для большего и 
> ненужно. Попробую поискать.
> Насчёт ppc/не ппц, это вопрос манейнера. Тем более, какая разница:
>   %ifarch ppcpseries ppc64
>   BuildRequires: foo_p
>   %endif
> и:
>   BuildRequires(arch:ppcseries,arch:ppc64): foo_p
> ? :)

Перечисление архитектур с префиксом arch: несколько не удобно: нельзя
использовать макросы типа %ix86 или %arm, которые разворачиваются в список
архитектур.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

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