Re: [devel] E: incoming i586 reject: wmmemload-0.1.6-alt4

Re: [devel] E: incoming i586 reject: wmmemload-0.1.6-alt4

[Slava Semushin]

2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
[...]
> + autoreconf -fisv
> autoreconf-default: Entering directory `.'
> autoreconf-default: configure.ac: not using Gettext
> autoreconf-default: running: aclocal --force
> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> aclocal-default: autom4te failed with exit status: 1
> autoreconf-default: aclocal failed with exit status: 1
> error: Bad exit status from /usr/src/tmp/rpm-tmp.79151 (%prep)

Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
были не функциональными, а пакет не собрался на обеих архитектурах.
При этом тот, что в Сизифе вроде бы пересобирается без проблем.

Погуглил на тему этой ошибки. Оба сообщения в sisyphus@, старые и не
дают ответа на вопрос "как исправлять". Вот тут:
http://lists.altlinux.ru/pipermail/sisyphus/2004-March/036879.html
есть лишь фраза "Проблемы в собираемом пакете." от ldv@ и ни слова как
фиксить/искать и что это значит.

devel@, I need help!

-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

[devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Slava Semushin]

2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
[...]
> + autoreconf -fisv
> autoreconf-default: Entering directory `.'
> autoreconf-default: configure.ac: not using Gettext
> autoreconf-default: running: aclocal --force
> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> aclocal-default: autom4te failed with exit status: 1
> autoreconf-default: aclocal failed with exit status: 1
> error: Bad exit status from /usr/src/tmp/rpm-tmp.79151 (%prep)

Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
были не функциональными, а пакет не собрался на обеих архитектурах.
При этом тот, что в Сизифе вроде бы пересобирается без проблем.

Погуглил на тему этой ошибки. Оба сообщения в sisyphus@, старые и не
дают ответа на вопрос "как исправлять". Вот тут:
http://lists.altlinux.ru/pipermail/sisyphus/2004-March/036879.html
есть лишь фраза "Проблемы в собираемом пакете." от ldv@ и ни слова как
фиксить/искать и что это значит.

devel@, I need help!


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] hasher/autoreconf/* problem

[Dmitry V. Levin]

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

On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin wrote:
> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
> [...]
> > + autoreconf -fisv
> > autoreconf-default: Entering directory `.'
> > autoreconf-default: configure.ac: not using Gettext
> > autoreconf-default: running: aclocal --force
> > Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> > aclocal-default: autom4te failed with exit status: 1
> > autoreconf-default: aclocal failed with exit status: 1
> > error: Bad exit status from /usr/src/tmp/rpm-tmp.79151 (%prep)
> 
> Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
> были не функциональными, а пакет не собрался на обеих архитектурах.
> При этом тот, что в Сизифе вроде бы пересобирается без проблем.

Это очень странная история, то ли нужен специалист по перлу чтобы
разобраться, то ли всё ещё интереснее.  У меня пакет libnet2 с аналогичной
проблемой сборки.

Воспроизводится это так:
при первой сборке в hasher'е (когда ещё не создан chroot cache) autoreconf
падает с этой самой диагностикой, при последующих сборках (когда
используется chroot cache) всё собирается нормально.


-- 
ldv

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

Re: [devel] hasher/autoreconf/* problem

[Anton Farygin]

Dmitry V. Levin пишет:
> On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin wrote:
>> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
>> [...]
>>> + autoreconf -fisv
>>> autoreconf-default: Entering directory `.'
>>> autoreconf-default: configure.ac: not using Gettext
>>> autoreconf-default: running: aclocal --force
>>> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
>>> aclocal-default: autom4te failed with exit status: 1
>>> autoreconf-default: aclocal failed with exit status: 1
>>> error: Bad exit status from /usr/src/tmp/rpm-tmp.79151 (%prep)
>> Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
>> были не функциональными, а пакет не собрался на обеих архитектурах.
>> При этом тот, что в Сизифе вроде бы пересобирается без проблем.
> 
> Это очень странная история, то ли нужен специалист по перлу чтобы
> разобраться, то ли всё ещё интереснее.  У меня пакет libnet2 с аналогичной
> проблемой сборки.
> 
> Воспроизводится это так:
> при первой сборке в hasher'е (когда ещё не создан chroot cache) autoreconf
> падает с этой самой диагностикой, при последующих сборках (когда
> используется chroot cache) всё собирается нормально.

А не может ли тут быть виноватым libfakeroot ? Очень похоже.

Re: [devel] hasher/autoreconf/* problem

[Dmitry V. Levin]

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

On Fri, Oct 05, 2007 at 02:40:51PM +0400, Anton Farygin wrote:
> Dmitry V. Levin пишет:
> > On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin wrote:
> >> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
> >> [...]
> >>> + autoreconf -fisv
> >>> autoreconf-default: Entering directory `.'
> >>> autoreconf-default: configure.ac: not using Gettext
> >>> autoreconf-default: running: aclocal --force
> >>> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> >>> aclocal-default: autom4te failed with exit status: 1
> >>> autoreconf-default: aclocal failed with exit status: 1
> >>> error: Bad exit status from /usr/src/tmp/rpm-tmp.79151 (%prep)
> >> Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
> >> были не функциональными, а пакет не собрался на обеих архитектурах.
> >> При этом тот, что в Сизифе вроде бы пересобирается без проблем.
> > 
> > Это очень странная история, то ли нужен специалист по перлу чтобы
> > разобраться, то ли всё ещё интереснее.  У меня пакет libnet2 с аналогичной
> > проблемой сборки.
> > 
> > Воспроизводится это так:
> > при первой сборке в hasher'е (когда ещё не создан chroot cache) autoreconf
> > падает с этой самой диагностикой, при последующих сборках (когда
> > используется chroot cache) всё собирается нормально.
> 
> А не может ли тут быть виноватым libfakeroot ? Очень похоже.

fakeroot используется только для инициализации чрута и установки пакетов.
fakeroot не используется во время сборки пакетов.


-- 
ldv

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

Re: [devel] hasher/autoreconf/* problem

[Anton Farygin]

Dmitry V. Levin пишет:
> On Fri, Oct 05, 2007 at 02:40:51PM +0400, Anton Farygin wrote:
>> Dmitry V. Levin пишет:
>>> On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin wrote:
>>>> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
>>>> [...]
>>>>> + autoreconf -fisv
>>>>> autoreconf-default: Entering directory `.'
>>>>> autoreconf-default: configure.ac: not using Gettext
>>>>> autoreconf-default: running: aclocal --force
>>>>> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
>>>>> aclocal-default: autom4te failed with exit status: 1
>>>>> autoreconf-default: aclocal failed with exit status: 1
>>>>> error: Bad exit status from /usr/src/tmp/rpm-tmp.79151 (%prep)
>>>> Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
>>>> были не функциональными, а пакет не собрался на обеих архитектурах.
>>>> При этом тот, что в Сизифе вроде бы пересобирается без проблем.
>>> Это очень странная история, то ли нужен специалист по перлу чтобы
>>> разобраться, то ли всё ещё интереснее.  У меня пакет libnet2 с аналогичной
>>> проблемой сборки.
>>>
>>> Воспроизводится это так:
>>> при первой сборке в hasher'е (когда ещё не создан chroot cache) autoreconf
>>> падает с этой самой диагностикой, при последующих сборках (когда
>>> используется chroot cache) всё собирается нормально.
>> А не может ли тут быть виноватым libfakeroot ? Очень похоже.
> 
> fakeroot используется только для инициализации чрута и установки пакетов.
> fakeroot не используется во время сборки пакетов.

А файловая система всё та-же tmpfs ?

Re: [devel] hasher/autoreconf/* problem

[Dmitry V. Levin]

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

On Fri, Oct 05, 2007 at 03:14:36PM +0400, Anton Farygin wrote:
> Dmitry V. Levin пишет:
> > On Fri, Oct 05, 2007 at 02:40:51PM +0400, Anton Farygin wrote:
> >> Dmitry V. Levin пишет:
> >>> On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin wrote:
> >>>> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
> >>>> [...]
> >>>>> + autoreconf -fisv
> >>>>> autoreconf-default: Entering directory `.'
> >>>>> autoreconf-default: configure.ac: not using Gettext
> >>>>> autoreconf-default: running: aclocal --force
> >>>>> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> >>>>> aclocal-default: autom4te failed with exit status: 1
> >>>>> autoreconf-default: aclocal failed with exit status: 1
> >>>>> error: Bad exit status from /usr/src/tmp/rpm-tmp.79151 (%prep)
> >>>> Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
> >>>> были не функциональными, а пакет не собрался на обеих архитектурах.
> >>>> При этом тот, что в Сизифе вроде бы пересобирается без проблем.
> >>> Это очень странная история, то ли нужен специалист по перлу чтобы
> >>> разобраться, то ли всё ещё интереснее.  У меня пакет libnet2 с аналогичной
> >>> проблемой сборки.
> >>>
> >>> Воспроизводится это так:
> >>> при первой сборке в hasher'е (когда ещё не создан chroot cache) autoreconf
> >>> падает с этой самой диагностикой, при последующих сборках (когда
> >>> используется chroot cache) всё собирается нормально.
> >> А не может ли тут быть виноватым libfakeroot ? Очень похоже.
> > 
> > fakeroot используется только для инициализации чрута и установки пакетов.
> > fakeroot не используется во время сборки пакетов.
> 
> А файловая система всё та-же tmpfs ?

Воспроизводимость 100%, поэтому фактор нестабильности tmpfs исключён.
Разве что timestamp resolution.


-- 
ldv

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

Re: [devel] hasher/autoreconf/* problem

[Victor Forsyuk]

On Fri, Oct 05, 2007 at 05:12:11PM +0400, Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Fri, Oct 05, 2007 at 03:14:36PM +0400, Anton Farygin wrote:
> > Dmitry V. Levin пишет:
> > > On Fri, Oct 05, 2007 at 02:40:51PM +0400, Anton Farygin wrote:
> > >> Dmitry V. Levin пишет:
> > >>> On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin wrote:
> > >>>> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
> > >>>> [...]
> > >>>>> + autoreconf -fisv
> > >>>>> autoreconf-default: Entering directory `.'
> > >>>>> autoreconf-default: configure.ac: not using Gettext
> > >>>>> autoreconf-default: running: aclocal --force
> > >>>>> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.

[...]
 
> Воспроизводимость 100%, поэтому фактор нестабильности tmpfs исключён.
> Разве что timestamp resolution.

"rm -rf autom4te.cache" не полечит?

Re: [devel] hasher/autoreconf/* problem

[Dmitry V. Levin]

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

On Fri, Oct 05, 2007 at 04:17:47PM +0300, Victor Forsyuk wrote:
> On Fri, Oct 05, 2007 at 05:12:11PM +0400, Dmitry V. Levin <ldv@altlinux.org> wrote:
> > On Fri, Oct 05, 2007 at 03:14:36PM +0400, Anton Farygin wrote:
> > > Dmitry V. Levin пишет:
> > > > On Fri, Oct 05, 2007 at 02:40:51PM +0400, Anton Farygin wrote:
> > > >> Dmitry V. Levin пишет:
> > > >>> On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin wrote:
> > > >>>> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
> > > >>>> [...]
> > > >>>>> + autoreconf -fisv
> > > >>>>> autoreconf-default: Entering directory `.'
> > > >>>>> autoreconf-default: configure.ac: not using Gettext
> > > >>>>> autoreconf-default: running: aclocal --force
> > > >>>>> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> 
> [...]
>  
> > Воспроизводимость 100%, поэтому фактор нестабильности tmpfs исключён.
> > Разве что timestamp resolution.
> 
> "rm -rf autom4te.cache" не полечит?

Я не проверял.  Настораживает сам факт нарушения воспроизводимости сборки.


-- 
ldv

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

Re: [devel] hasher/autoreconf/* problem

[Slava Semushin]

2007/10/5, Dmitry V. Levin <ldv / altlinux.org>:
[...]
> > "rm -rf autom4te.cache" не полечит?
>
> Я не проверял.  Настораживает сам факт нарушения воспроизводимости сборки.

В моём случае, с wmmemload, помогло.


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] hasher/autoreconf/* problem

[Dmitry V. Levin]

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

On Mon, Oct 08, 2007 at 04:48:33PM +0700, Slava Semushin wrote:
> 2007/10/5, Dmitry V. Levin <ldv / altlinux.org>:
> [...]
> > > "rm -rf autom4te.cache" не полечит?
> >
> > Я не проверял.  Настораживает сам факт нарушения воспроизводимости сборки.
> 
> В моём случае, с wmmemload, помогло.

Может быть, стоит добавить этот rm в макрос %__autoreconf?


-- 
ldv

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

Re: [devel] hasher/autoreconf/* problem

[Victor Forsyuk]

On Mon, Oct 08, 2007 at 02:13:19PM +0400, Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Mon, Oct 08, 2007 at 04:48:33PM +0700, Slava Semushin wrote:
> > 2007/10/5, Dmitry V. Levin <ldv / altlinux.org>:
> > [...]
> > > > "rm -rf autom4te.cache" не полечит?
> > >
> > > Я не проверял.  Настораживает сам факт нарушения воспроизводимости сборки.
> > 
> > В моём случае, с wmmemload, помогло.
> 
> Может быть, стоит добавить этот rm в макрос %__autoreconf?

Стоит. Однозначно стоит. Напоминалку в BTS повесить?

Re: [devel] hasher/autoreconf/* problem

[Slava Semushin]

2007/10/8, Dmitry V. Levin <ldv / altlinux.org>:
> On Mon, Oct 08, 2007 at 04:48:33PM +0700, Slava Semushin wrote:
> > 2007/10/5, Dmitry V. Levin <ldv / altlinux.org>:
> > [...]
> > > > "rm -rf autom4te.cache" не полечит?
> > >
> > > Я не проверял.  Настораживает сам факт нарушения воспроизводимости сборки.
> >
> > В моём случае, с wmmemload, помогло.
>
> Может быть, стоит добавить этот rm в макрос %__autoreconf?

Из-за того, что лично мне не очень ясно почему touch'и каталога
autom4te.cache приводят %__autoreconf в ступор, я бы добавлять вызов
rm не стал. Плюс не так много пакетов, это коснулось и, насколько я
понимаю, каталог autom4te.cache не должен попадать в тарболл, т.е. все
эти случаи похожи на ошибки упаковки тарболлов в апстриме.


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] hasher/autoreconf/* problem

[Epiphanov Sergei]

В сообщении от Monday 08 October 2007 14:19:58 Slava Semushin написал(а):
> Из-за того, что лично мне не очень ясно почему touch'и каталога
> autom4te.cache приводят %__autoreconf в ступор, я бы добавлять вызов
> rm не стал. Плюс не так много пакетов, это коснулось и, насколько я
> понимаю, каталог autom4te.cache не должен попадать в тарболл, т.е. все
> эти случаи похожи на ошибки упаковки тарболлов в апстриме.

Согласен. Думаю, что %__autoreconf, как и make, проверяют timestamp и по нему 
решают, что делать с кешем. Отсюда и ступор задачи: вродеб ничего не 
изменилось, а в реальности сборочная среда другая.

-- 
С уважением, Епифанов Сергей

Re: [devel] hasher/autoreconf/* problem

[Slava Semushin]

08.10.07, Epiphanov Sergei<serpiph / nikiet.ru> написал(а):
> В сообщении от Monday 08 October 2007 14:19:58 Slava Semushin написал(а):
> > Из-за того, что лично мне не очень ясно почему touch'и каталога
> > autom4te.cache приводят %__autoreconf в ступор, я бы добавлять вызов
> > rm не стал. Плюс не так много пакетов, это коснулось и, насколько я
> > понимаю, каталог autom4te.cache не должен попадать в тарболл, т.е. все
> > эти случаи похожи на ошибки упаковки тарболлов в апстриме.
>
> Согласен. Думаю, что %__autoreconf, как и make, проверяют timestamp и по нему
> решают, что делать с кешем. Отсюда и ступор задачи: вродеб ничего не
> изменилось, а в реальности сборочная среда другая.

Если я правильно понимаю, то он не должен ориентироваться на
timestamp, потому что вызывается с ключом -f:

[c0der@rock ~]$ rpm --eval %__autoreconf
autoreconf -fisv
[c0der@rock ~]$ man autoreconf
...
       -f, --force
              consider all files obsolete

Или я не прав и тут о чем-то совершенно ином?


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] hasher/autoreconf/* problem

[Victor Forsyuk]

On Mon, Oct 08, 2007 at 07:21:36PM +0700, Slava Semushin <slava.semushin@gmail.com> wrote:
> 08.10.07, Epiphanov Sergei<serpiph / nikiet.ru> написал(а):
> > В сообщении от Monday 08 October 2007 14:19:58 Slava Semushin написал(а):
> > > Из-за того, что лично мне не очень ясно почему touch'и каталога
> > > autom4te.cache приводят %__autoreconf в ступор, я бы добавлять вызов
> > > rm не стал. Плюс не так много пакетов, это коснулось и, насколько я
> > > понимаю, каталог autom4te.cache не должен попадать в тарболл, т.е. все
> > > эти случаи похожи на ошибки упаковки тарболлов в апстриме.
> >
> > Согласен. Думаю, что %__autoreconf, как и make, проверяют timestamp и по нему
> > решают, что делать с кешем. Отсюда и ступор задачи: вродеб ничего не
> > изменилось, а в реальности сборочная среда другая.
> 
> Если я правильно понимаю, то он не должен ориентироваться на
> timestamp, потому что вызывается с ключом -f:

http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_180.html

Re: [devel] hasher/autoreconf/* problem

[Victor Forsyuk]

On Mon, Oct 08, 2007 at 05:19:58PM +0700, Slava Semushin <slava.semushin@gmail.com> wrote:
> 2007/10/8, Dmitry V. Levin <ldv / altlinux.org>:
> > On Mon, Oct 08, 2007 at 04:48:33PM +0700, Slava Semushin wrote:
> > > 2007/10/5, Dmitry V. Levin <ldv / altlinux.org>:
> > > [...]
> > > > > "rm -rf autom4te.cache" не полечит?
> > > >
> > > > Я не проверял.  Настораживает сам факт нарушения воспроизводимости сборки.
> > >
> > > В моём случае, с wmmemload, помогло.
> >
> > Может быть, стоит добавить этот rm в макрос %__autoreconf?
> 
> Из-за того, что лично мне не очень ясно почему touch'и каталога
> autom4te.cache приводят %__autoreconf в ступор, я бы добавлять вызов
> rm не стал.

Это безопасный вызов в любом случае. Есть ли возражения более веские чем "не
очень понятно"?

> Плюс не так много пакетов, это коснулось и, насколько я понимаю, каталог
> autom4te.cache не должен попадать в тарболл, т.е. все эти случаи похожи на
> ошибки упаковки тарболлов в апстриме.

Да, это ошибки упаковки тарболлов в апстриме. Необнаруженные ранее, потому
что таймстампы в исходном тарболле маскировали эту проблему.

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

Re: [devel] hasher/autoreconf/* problem

[Slava Semushin]

08.10.07, Victor Forsyuk<force / altlinux.org> написал(а):
[...]
> > > Может быть, стоит добавить этот rm в макрос %__autoreconf?
> >
> > Из-за того, что лично мне не очень ясно почему touch'и каталога
> > autom4te.cache приводят %__autoreconf в ступор, я бы добавлять вызов
> > rm не стал.
>
> Это безопасный вызов в любом случае. Есть ли возражения более веские чем "не
> очень понятно"?

Виктор, это было не возражение, а моё мнение. Поэтому если все решат,
что надо, и Дима этот макрос изменит, то я буду не против :)


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] hasher/autoreconf/* problem

[Dmitry V. Levin]

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

On Tue, Oct 09, 2007 at 12:22:25PM +0700, Slava Semushin wrote:
> 08.10.07, Victor Forsyuk<force / altlinux.org> написал(а):
> [...]
> > > > Может быть, стоит добавить этот rm в макрос %__autoreconf?
> > >
> > > Из-за того, что лично мне не очень ясно почему touch'и каталога
> > > autom4te.cache приводят %__autoreconf в ступор, я бы добавлять вызов
> > > rm не стал.
> >
> > Это безопасный вызов в любом случае. Есть ли возражения более веские чем "не
> > очень понятно"?
> 
> Виктор, это было не возражение, а моё мнение. Поэтому если все решат,
> что надо, и Дима этот макрос изменит, то я буду не против :)

Изменит обязательно.


-- 
ldv

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

Re: [devel] hasher/autoreconf/* problem

[Victor Forsyuk]

On Fri, Oct 05, 2007 at 05:29:51PM +0400, Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Fri, Oct 05, 2007 at 04:17:47PM +0300, Victor Forsyuk wrote:
> > On Fri, Oct 05, 2007 at 05:12:11PM +0400, Dmitry V. Levin <ldv@altlinux.org> wrote:
> > > On Fri, Oct 05, 2007 at 03:14:36PM +0400, Anton Farygin wrote:
> > > > Dmitry V. Levin пишет:
> > > > > On Fri, Oct 05, 2007 at 02:40:51PM +0400, Anton Farygin wrote:
> > > > >> Dmitry V. Levin пишет:
> > > > >>> On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin wrote:
> > > > >>>> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
> > > > >>>> [...]
> > > > >>>>> + autoreconf -fisv
> > > > >>>>> autoreconf-default: Entering directory `.'
> > > > >>>>> autoreconf-default: configure.ac: not using Gettext
> > > > >>>>> autoreconf-default: running: aclocal --force
> > > > >>>>> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> > 
> > [...]
> >  
> > > Воспроизводимость 100%, поэтому фактор нестабильности tmpfs исключён.
> > > Разве что timestamp resolution.
> > 
> > "rm -rf autom4te.cache" не полечит?
> 
> Я не проверял.  Настораживает сам факт нарушения воспроизводимости сборки.

Ну это уже особенности хешера. В хост-системе такой пакет будет 100%
несобираемым.

Кстати, проблема с autom4te.cache - пример граблей, возникающих из-за отказа
от pristine sources. И чувствую, что эти грабли не последние...

Re: [devel] hasher/autoreconf/* problem

[Dmitry V. Levin]

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

On Mon, Oct 08, 2007 at 05:35:39PM +0300, Victor Forsyuk wrote:
> On Fri, Oct 05, 2007 at 05:29:51PM +0400, Dmitry V. Levin wrote:
> > On Fri, Oct 05, 2007 at 04:17:47PM +0300, Victor Forsyuk wrote:
> > > On Fri, Oct 05, 2007 at 05:12:11PM +0400, Dmitry V. Levin wrote:
> > > > On Fri, Oct 05, 2007 at 03:14:36PM +0400, Anton Farygin wrote:
> > > > > Dmitry V. Levin пишет:
> > > > > > On Fri, Oct 05, 2007 at 02:40:51PM +0400, Anton Farygin wrote:
> > > > > >> Dmitry V. Levin пишет:
> > > > > >>> On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin wrote:
> > > > > >>>> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
> > > > > >>>> [...]
> > > > > >>>>> + autoreconf -fisv
> > > > > >>>>> autoreconf-default: Entering directory `.'
> > > > > >>>>> autoreconf-default: configure.ac: not using Gettext
> > > > > >>>>> autoreconf-default: running: aclocal --force
> > > > > >>>>> Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> > > 
> > > [...]
> > >  
> > > > Воспроизводимость 100%, поэтому фактор нестабильности tmpfs исключён.
> > > > Разве что timestamp resolution.
> > > 
> > > "rm -rf autom4te.cache" не полечит?
> > 
> > Я не проверял.  Настораживает сам факт нарушения воспроизводимости сборки.
> 
> Ну это уже особенности хешера. В хост-системе такой пакет будет 100%
> несобираемым.

Почему?

> Кстати, проблема с autom4te.cache - пример граблей, возникающих из-за отказа
> от pristine sources. И чувствую, что эти грабли не последние...

А разве каталог autom4te.cache должен включаться в pristine sources?


-- 
ldv

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

Re: [devel] hasher/autoreconf/* problem

[Victor Forsyuk]

On Mon, Oct 08, 2007 at 06:42:05PM +0400, Dmitry V. Levin <ldv@altlinux.org> wrote:
> > > > 
> > > > "rm -rf autom4te.cache" не полечит?
> > > 
> > > Я не проверял.  Настораживает сам факт нарушения воспроизводимости сборки.
> > 
> > Ну это уже особенности хешера. В хост-системе такой пакет будет 100%
> > несобираемым.
> 
> Почему?

Хмм... пошел проверить, не забыл ли я за выходные о чем речь была:
"при первой сборке в hasher'е (когда ещё не создан chroot cache) autoreconf
падает с этой самой диагностикой, при последующих сборках (когда
используется chroot cache) всё собирается нормально."

Почему в хост системе все сборки будут вести себя одинаково - там нет таких
различий (нет chroot cache или есть). Все сборки вне хешера одинаковы за
счет того, что в %prep происходит удаление старого сборочного каталога.

> > Кстати, проблема с autom4te.cache - пример граблей, возникающих из-за отказа
> > от pristine sources. И чувствую, что эти грабли не последние...
> 
> А разве каталог autom4te.cache должен включаться в pristine sources?

Нет, не должен включаться. Более того, должен НЕ включаться. Но не все
апстримы идеальны и безошибочны. Некоторые содержат тщательно
замаскированные грабельки. :)

Re: [devel] hasher/autoreconf/* problem

[Grigory Batalov]

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

On Mon, 8 Oct 2007 17:56:26 +0300, Victor Forsyuk wrote:

> > > Ну это уже особенности хешера. В хост-системе такой пакет будет 100%
> > > несобираемым.
> > 
> > Почему?
> 
> Хмм... пошел проверить, не забыл ли я за выходные о чем речь была:
> "при первой сборке в hasher'е (когда ещё не создан chroot cache) autoreconf
> падает с этой самой диагностикой, при последующих сборках (когда
> используется chroot cache) всё собирается нормально."
> 
> Почему в хост системе все сборки будут вести себя одинаково - там нет таких
> различий (нет chroot cache или есть). Все сборки вне хешера одинаковы за
> счет того, что в %prep происходит удаление старого сборочного каталога.

  А разве при обычной сборке в секции %prep не происходит удаления старого
  сборочного каталога?

-- 
 Grigory Batalov,
 ALT Linux Team

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

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Victor Forsyuk]

On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin <slava.semushin@gmail.com> wrote:
> 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
> [...]
> > + autoreconf -fisv
> > autoreconf-default: Entering directory `.'
> > autoreconf-default: configure.ac: not using Gettext
> > autoreconf-default: running: aclocal --force
> > Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> > aclocal-default: autom4te failed with exit status: 1
> > autoreconf-default: aclocal failed with exit status: 1
> > error: Bad exit status from /usr/src/tmp/rpm-tmp.79151 (%prep)
> 
> Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
> были не функциональными, а пакет не собрался на обеих архитектурах.
> При этом тот, что в Сизифе вроде бы пересобирается без проблем.

Да, в спеке все изменения были нефункциональны. Но есть один маленький
нюансик. Исходный тарболл в wmmemload-0.1.6-alt4.src.rpm побайтово идентичен
тому, который был в -alt3.src.rpm, но отличается датами файлов. В нем всё
"тачнуто" в "Oct  5 08:15". Откуда это появилось?
 
В этом причина неидентичности сборки. Кстати вызов autoreconf в этоме спеке
совершенно ненужен, все патчи изменяют только исходники, никакой причины
перестраивать аутотулзовскую обвязку нет...

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Victor Forsyuk]

On Fri, Oct 05, 2007 at 03:50:11PM +0300, Victor Forsyuk <force@altlinux.org> wrote:
> On Fri, Oct 05, 2007 at 01:56:25PM +0700, Slava Semushin <slava.semushin@gmail.com> wrote:
> > 2007/10/5, Upravdom Team Robot <upravdom / altlinux.org>:
> > [...]
> > > + autoreconf -fisv
> > > autoreconf-default: Entering directory `.'
> > > autoreconf-default: configure.ac: not using Gettext
> > > autoreconf-default: running: aclocal --force
> > > Can't locate object method "path" via package "Request" at /usr/share/autoconf-2.5/Autom4te/C4che.pm line 69, <GEN1> line 111.
> > > aclocal-default: autom4te failed with exit status: 1
> > > autoreconf-default: aclocal failed with exit status: 1
> > > error: Bad exit status from /usr/src/tmp/rpm-tmp.79151 (%prep)
> > 
> > Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
> > были не функциональными, а пакет не собрался на обеих архитектурах.
> > При этом тот, что в Сизифе вроде бы пересобирается без проблем.
> 
> Да, в спеке все изменения были нефункциональны. Но есть один маленький
> нюансик. Исходный тарболл в wmmemload-0.1.6-alt4.src.rpm побайтово идентичен
> тому, который был в -alt3.src.rpm, но отличается датами файлов. В нем всё
> "тачнуто" в "Oct  5 08:15". Откуда это появилось?
>  
> В этом причина неидентичности сборки. Кстати вызов autoreconf в этоме спеке
> совершенно ненужен, все патчи изменяют только исходники, никакой причины
> перестраивать аутотулзовскую обвязку нет...

Сделайте
rm -rf autom4te.cache
и уберите вызов
%__autoreconf

После этого будет собираться:

--- wmmemload.spec.orig 2007-10-05 08:16:07 +0300
+++ wmmemload.spec      2007-10-05 16:12:47 +0300
@@ -3,10 +3,9 @@
 Release: alt4

 Summary: This dockapp displays memory and swap space usage
-Summary(ru_RU.CP1251): щРНР ЮООКЕР НРНАПЮФЮЕР ХЯОНКЭГНБЮМХЕ ОЮЛЪРХ Х ТЮИКЮ ОНДЙЮВЙХ
-
-License: GPL
+License: GPLv2+
 Group: Graphical desktop/Window Maker
+
 Url: http://markstaggs.net/wmmemload/
 Packager: Slava Semushin <php-coder@altlinux.ru>

@@ -17,36 +16,21 @@
 Patch1: %name-0.1.6-alt-warnings-fix.patch
 Patch2: %name-0.1.6-alt-src-print_help_fix.patch

-# For %%__autoreconf (-alt54) macros
-BuildPreReq: rpm >= 4.0.4-alt54
-
 BuildRequires: libXt-devel libXext-devel libXpm-devel

 %description
 Dockapp which displays memory and swap space usage in percent and uses
 nice LCD-style.

-%description -l ru_RU.CP1251
-юООКЕР НРНАПЮФЮЧЫХИ ХЯОНКЭГНБЮМХЕ НОЕПЮРХБМНИ ОЮЛЪРХ Х ЯБНОЮ Б
-ОПНЖЕМРЮУ Х БШОНКМЕММШИ Б ОПХЪРМНЛ LCD ЯРХКЕ.
-
 %prep
 %setup

-# fix warnings from aclocal
-sed -i 's|AC_DEFUN(DA_CHECK_LIB,|AC_DEFUN([DA_CHECK_LIB],|' acinclude.m4
-sed -i 's|AC_DEFUN(DA_CHECK_HEADER,|AC_DEFUN([DA_CHECK_HEADER],|' acinclude.m4
-
-# fix Makefile.am
-sed -i 's|CPPFLAGS =|AM_CPPFLAGS =|' src/Makefile.am
-
 %patch0
 %patch1
 %patch2

-%__autoreconf
-
 %build
+rm -rf autom4te.cache
 %configure
 %make_build --no-print-directory CFLAGS="%optflags -W -Werror"

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Epiphanov Sergei]

В сообщении от Friday 05 October 2007 17:11:35 Victor Forsyuk написал(а):
> -License: GPL
> +License: GPLv2+

А не "License: GPLv2plus"?

-- 
С уважением, Епифанов Сергей

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Victor Forsyuk]

On Fri, Oct 05, 2007 at 05:15:16PM +0400, Epiphanov Sergei <serpiph@nikiet.ru> wrote:
> В сообщении от Friday 05 October 2007 17:11:35 Victor Forsyuk написал(а):
> > -License: GPL
> > +License: GPLv2+
> 
> А не "License: GPLv2plus"?

Вы с макросом не попутали?

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Epiphanov Sergei]

В сообщении от Friday 05 October 2007 17:32:13 Victor Forsyuk написал(а):
> > > +License: GPLv2+
> >
> > А не "License: GPLv2plus"?
>
> Вы с макросом не попутали?

Да, есть такое. :) Тут всё просят макросы вписывать в поле лицензии, вот и 
здесь смотрю - и никак в толк не возьму, что за странная запись.

-- 
С уважением, Епифанов Сергей

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Victor Forsyuk]

On Fri, Oct 05, 2007 at 05:36:39PM +0400, Epiphanov Sergei <serpiph@nikiet.ru> wrote:
> В сообщении от Friday 05 October 2007 17:32:13 Victor Forsyuk написал(а):
> > > > +License: GPLv2+
> > >
> > > А не "License: GPLv2plus"?
> >
> > Вы с макросом не попутали?
> 
> Да, есть такое. :) Тут всё просят макросы вписывать в поле лицензии, вот и 
> здесь смотрю - и никак в толк не возьму, что за странная запись.

Пока rpm-build-licenses не присутствует в базовой сборочной среде я не вижу
смысла втягивать этот пакет в явные зависимости сборки.

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Dmitry V. Levin]

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

On Fri, Oct 05, 2007 at 04:32:13PM +0300, Victor Forsyuk wrote:
> On Fri, Oct 05, 2007 at 05:15:16PM +0400, Epiphanov Sergei <serpiph@nikiet.ru> wrote:
> > В сообщении от Friday 05 October 2007 17:11:35 Victor Forsyuk написал(а):
> > > -License: GPL
> > > +License: GPLv2+
> > 
> > А не "License: GPLv2plus"?
> 
> Вы с макросом не попутали?

А что, "License: GPLv2+" не эстетично?


-- 
ldv

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

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Slava Semushin]

2007/10/5, Victor Forsyuk <force / altlinux.org>:
[...]
> > Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
> > были не функциональными, а пакет не собрался на обеих архитектурах.
> > При этом тот, что в Сизифе вроде бы пересобирается без проблем.
>
> Да, в спеке все изменения были нефункциональны. Но есть один маленький
> нюансик. Исходный тарболл в wmmemload-0.1.6-alt4.src.rpm побайтово идентичен
> тому, который был в -alt3.src.rpm, но отличается датами файлов. В нем всё
> "тачнуто" в "Oct  5 08:15". Откуда это появилось?

Ну как откуда? Я же этот пакет засунул в git и теперь тарболл
генерируется на лету. Видимо, отсюда и дата.

> В этом причина неидентичности сборки. Кстати вызов autoreconf в этоме спеке
> совершенно ненужен, все патчи изменяют только исходники, никакой причины
> перестраивать аутотулзовскую обвязку нет...

Зато в спеке есть:

# fix warnings from aclocal
sed -i 's|AC_DEFUN(DA_CHECK_LIB,|AC_DEFUN([DA_CHECK_LIB],|' acinclude.m4
sed -i 's|AC_DEFUN(DA_CHECK_HEADER,|AC_DEFUN([DA_CHECK_HEADER],|' acinclude.m4

# fix Makefile.am
sed -i 's|CPPFLAGS =|AM_CPPFLAGS =|' src/Makefile.am

Для этого я и добавил вызов %__autoreconf'а.


Виктор, спасибо, что обнаружили проблему!


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Victor Forsyuk]

On Sat, Oct 06, 2007 at 12:45:07PM +0700, Slava Semushin <slava.semushin@gmail.com> wrote:
> 2007/10/5, Victor Forsyuk <force / altlinux.org>:
> [...]
> > > Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
> > > были не функциональными, а пакет не собрался на обеих архитектурах.
> > > При этом тот, что в Сизифе вроде бы пересобирается без проблем.
> >
> > Да, в спеке все изменения были нефункциональны. Но есть один маленький
> > нюансик. Исходный тарболл в wmmemload-0.1.6-alt4.src.rpm побайтово идентичен
> > тому, который был в -alt3.src.rpm, но отличается датами файлов. В нем всё
> > "тачнуто" в "Oct  5 08:15". Откуда это появилось?
> 
> Ну как откуда? Я же этот пакет засунул в git и теперь тарболл
> генерируется на лету. Видимо, отсюда и дата.

Я вполне себе могу представить программу, сборка которой не сломается от
таких вольностей с исходниками, но которая будет собираться неправильно.
Ничего сверх-ухищренного. К примеру, при сборке используется самый свежий
файл по какой-то маске имен из определенного каталога... Не самое умное
решение, но много ли вы видели идеальных апстримов? И это даже _не ошибка_
автора (как упаковка того же autom4te.cache), а просто freaky way.

Вы готовы поручиться, что у пакетов, которые Вы таким образом собираете из
git подобных проблем не будет?

> > В этом причина неидентичности сборки. Кстати вызов autoreconf в этоме спеке
> > совершенно ненужен, все патчи изменяют только исходники, никакой причины
> > перестраивать аутотулзовскую обвязку нет...
> 
> Зато в спеке есть:
> 
> # fix warnings from aclocal
> sed -i 's|AC_DEFUN(DA_CHECK_LIB,|AC_DEFUN([DA_CHECK_LIB],|' acinclude.m4
> sed -i 's|AC_DEFUN(DA_CHECK_HEADER,|AC_DEFUN([DA_CHECK_HEADER],|' acinclude.m4
> 
> # fix Makefile.am
> sed -i 's|CPPFLAGS =|AM_CPPFLAGS =|' src/Makefile.am
> 
> Для этого я и добавил вызов %__autoreconf'а.

Понятно, но эти "фиксы" - чистая косметика. Как по мне, лучше сообщить о них
автору и не морочиться до следующей версии. :)

Re: [devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Dmitry V. Levin]

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

On Mon, Oct 08, 2007 at 07:30:38PM +0300, Victor Forsyuk wrote:
> On Sat, Oct 06, 2007 at 12:45:07PM +0700, Slava Semushin <slava.semushin@gmail.com> wrote:
> > 2007/10/5, Victor Forsyuk <force / altlinux.org>:
> > [...]
> > > > Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
> > > > были не функциональными, а пакет не собрался на обеих архитектурах.
> > > > При этом тот, что в Сизифе вроде бы пересобирается без проблем.
> > >
> > > Да, в спеке все изменения были нефункциональны. Но есть один маленький
> > > нюансик. Исходный тарболл в wmmemload-0.1.6-alt4.src.rpm побайтово идентичен
> > > тому, который был в -alt3.src.rpm, но отличается датами файлов. В нем всё
> > > "тачнуто" в "Oct  5 08:15". Откуда это появилось?
> > 
> > Ну как откуда? Я же этот пакет засунул в git и теперь тарболл
> > генерируется на лету. Видимо, отсюда и дата.
> 
> Я вполне себе могу представить программу, сборка которой не сломается от
> таких вольностей с исходниками, но которая будет собираться неправильно.
> Ничего сверх-ухищренного. К примеру, при сборке используется самый свежий
> файл по какой-то маске имен из определенного каталога... Не самое умное
> решение, но много ли вы видели идеальных апстримов? И это даже _не ошибка_
> автора (как упаковка того же autom4te.cache), а просто freaky way.
> 
> Вы готовы поручиться, что у пакетов, которые Вы таким образом собираете из
> git подобных проблем не будет?

За свои пакеты я готов поручиться, поскольку я имею привычку сравнивать
логи сборки.  Но априори исключать влияние timestamp'ов в тарболе на
сборку, конечно, нельзя.  Такие грабли следует репортить upstream по мере
обнаружения.


-- 
ldv

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