Re: [devel] [#7001] FAILED ipsec-tools.git=0.7.2-alt1

Re: [devel] [#7001] FAILED ipsec-tools.git=0.7.2-alt1

[Dmitry Lebkov]

On 24.05.2009 03:57, Girar Builder robot wrote:
> http://git.altlinux.org/tasks/7001/task/log
>
> 2009-May-23 20:56:02 :: task #7001 for sisyphus started:
> #1 build 0.7.2-alt1 from /people/dlebkov/packages/ipsec-tools.git
> 2009-May-23 20:56:04 :: created pkg.tar for ipsec-tools.git tag 0.7.2-alt1
> 2009-May-23 20:56:05 :: [x86_64] ipsec-tools.git 0.7.2-alt1: build start
> 2009-May-23 20:56:05 :: [i586] ipsec-tools.git 0.7.2-alt1: build start
> make[4]: *** [install-include_racoonHEADERS] Error 1
> make[4]: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src/racoon'
> make[3]: *** [install-am] Error 2
> make[3]: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src/racoon'
> make[2]: *** [install] Error 2
> make[2]: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src/racoon'
> make[1]: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src'
> make[1]: *** [install-recursive] Error 1
> make: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2'
> make: *** [install-recursive] Error 1
> 2009-May-23 20:57:31 :: [x86_64] ipsec-tools.git 0.7.2-alt1: remote: build failed
> 2009-May-23 20:57:31 :: [x86_64] ipsec-tools.git 0.7.2-alt1: build FAILED
> make[4]: *** [install-include_racoonHEADERS] Error 1
> make[4]: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src/racoon'
> make[3]: *** [install-am] Error 2
> make[3]: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src/racoon'
> make[2]: *** [install] Error 2
> make[2]: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src/racoon'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src'
> make: *** [install-recursive] Error 1
> make: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2'
> 2009-May-23 20:57:47 :: [i586] ipsec-tools.git 0.7.2-alt1: remote: build failed
> 2009-May-23 20:57:47 :: [i586] ipsec-tools.git 0.7.2-alt1: build FAILED
> 2009-May-23 20:57:32 :: [x86_64] build FAILED
> 2009-May-23 20:57:48 :: [i586] build FAILED
> 2009-May-23 20:57:48 :: task #7001 for sisyphus FAILED

Локально, через gear-hsh, всё собирается нормально. Какие-то проблемы на удаленной
сборочнице?

-- 
WBR, Dmitry Lebkov

Re: [devel] [#7001] FAILED ipsec-tools.git=0.7.2-alt1

[Alexey I. Froloff]

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

* Dmitry Lebkov <dima@> [090523 21:29]:
> Локально, через gear-hsh, всё собирается нормально.
Это не показатель.

> Какие-то проблемы на удаленной сборочнице?
Какие-то проблемы в пакете:

include_racoon_HEADERS = racoonctl.h var.h vmbuf.h misc.h gcmalloc.h admin.h \
>                                          ^^^^^^^
        schedule.h sockmisc.h vmbuf.h isakmp_var.h isakmp.h isakmp_xauth.h \
>                             ^^^^^^^
        isakmp_cfg.h isakmp_unity.h ipsec_doi.h evt.h


-- 
Regards,
Sir Raorn.

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

Re: [devel] FAILED ipsec-tools.git=0.7.2-alt1

[Alexey Tourbin]

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

On Sun, May 24, 2009 at 04:27:40AM +1100, Dmitry Lebkov wrote:
> >make[4]: *** [install-include_racoonHEADERS] Error 1
> >make[4]: Leaving directory 
> >`/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src/racoon'
> >make[3]: *** [install-am] Error 2
> >make[3]: Leaving directory 
> >`/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src/racoon'
> >make[2]: *** [install] Error 2
> >make[2]: Leaving directory 
> >`/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src/racoon'
> >make[1]: *** [install-recursive] Error 1
> >make[1]: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2/src'
> >make: *** [install-recursive] Error 1
> >make: Leaving directory `/usr/src/RPM/BUILD/ipsec-tools-0.7.2'
> >2009-May-23 20:57:47 :: [i586] ipsec-tools.git 0.7.2-alt1: remote: build 
> >failed
> >2009-May-23 20:57:47 :: [i586] ipsec-tools.git 0.7.2-alt1: build FAILED
> >2009-May-23 20:57:32 :: [x86_64] build FAILED
> >2009-May-23 20:57:48 :: [i586] build FAILED
> >2009-May-23 20:57:48 :: task #7001 for sisyphus FAILED
> 
> Локально, через gear-hsh, всё собирается 
> нормально. Какие-то проблемы на удаленной
> сборочнице?

/bin/install: will not overwrite just-created `/usr/src/tmp/ipsec-tools-buildroot/usr/include/racoon/vmbuf.h' with `vmbuf.h'
http://git.altlinux.org/tasks/7001/build/1/x86_64/log

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

Re: [devel] [#7001] FAILED ipsec-tools.git=0.7.2-alt1

[Dmitry Lebkov]

On 24.05.2009 04:42, Alexey I. Froloff wrote:
> * Dmitry Lebkov<dima@>  [090523 21:29]:
>> Локально, через gear-hsh, всё собирается нормально.
> Это не показатель.
>
>> Какие-то проблемы на удаленной сборочнице?
> Какие-то проблемы в пакете:
>
> include_racoon_HEADERS = racoonctl.h var.h vmbuf.h misc.h gcmalloc.h admin.h \
>>                                           ^^^^^^^
>          schedule.h sockmisc.h vmbuf.h isakmp_var.h isakmp.h isakmp_xauth.h \
>>                              ^^^^^^^
>          isakmp_cfg.h isakmp_unity.h ipsec_doi.h evt.h

Этого-то я и не заметил при рассматривании логов ... Мда ... =\

Спасибо всем отозвавшимся. Интересно, а такие проблемы как-то
можно отлавливать при локальном тестировании, до отправки задания
на сборку?

-- 
WBR, Dmitry Lebkov

Re: [devel] [#7001] FAILED ipsec-tools.git=0.7.2-alt1

[Sergey Vlasov]

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

On Sun, May 24, 2009 at 11:49:51AM +1100, Dmitry Lebkov wrote:
> On 24.05.2009 04:42, Alexey I. Froloff wrote:
> > * Dmitry Lebkov<dima@>  [090523 21:29]:
> >> Локально, через gear-hsh, всё собирается нормально.
> > Это не показатель.
> >
> >> Какие-то проблемы на удаленной сборочнице?
> > Какие-то проблемы в пакете:
> >
> > include_racoon_HEADERS = racoonctl.h var.h vmbuf.h misc.h gcmalloc.h admin.h \
> >>                                           ^^^^^^^
> >          schedule.h sockmisc.h vmbuf.h isakmp_var.h isakmp.h isakmp_xauth.h \
> >>                              ^^^^^^^
> >          isakmp_cfg.h isakmp_unity.h ipsec_doi.h evt.h
> 
> Этого-то я и не заметил при рассматривании логов ... Мда ... =\
> 
> Спасибо всем отозвавшимся. Интересно, а такие проблемы как-то
> можно отлавливать при локальном тестировании, до отправки задания
> на сборку?

Можно, если иметь локально достаточно свежий Сизиф (в данном случае
проблема проявилась из-за изменений в coreutils).

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

Re: [devel] [#7001] FAILED ipsec-tools.git=0.7.2-alt1

[Denis Medvedev]

-----Original Message-----
From: Sergey Vlasov <vsu@altlinux.ru>
To: devel@lists.altlinux.org
Date: Sun, 24 May 2009 11:29:37 +0400
Subject: Re: [devel] [#7001] FAILED ipsec-tools.git=0.7.2-alt1

> On Sun, May 24, 2009 at 11:49:51AM +1100, Dmitry Lebkov wrote:
> > On 24.05.2009 04:42, Alexey I. Froloff wrote:
> > > * Dmitry Lebkov<dima@>  [090523 21:29]:
> > >> Локально, через gear-hsh, всё собирается нормально.
> > > Это не показатель.
> > >
> > >> Какие-то проблемы на удаленной сборочнице?
> > > Какие-то проблемы в пакете:
> > >
> > > include_racoon_HEADERS = racoonctl.h var.h vmbuf.h misc.h gcmalloc.h admin.h \
> > >>                                           ^^^^^^^
> > >          schedule.h sockmisc.h vmbuf.h isakmp_var.h isakmp.h isakmp_xauth.h \
> > >>                              ^^^^^^^
> > >          isakmp_cfg.h isakmp_unity.h ipsec_doi.h evt.h
> > 
> > Этого-то я и не заметил при рассматривании логов ... Мда ... =\
> > 
> > Спасибо всем отозвавшимся. Интересно, а такие проблемы как-то
> > можно отлавливать при локальном тестировании, до отправки задания
> > на сборку?
> 
> Можно, если иметь локально достаточно свежий Сизиф (в данном случае
> проблема проявилась из-за изменений в coreutils).
Кстати, если есть анлим достаточно быстрый интернет, то можно сизиф локально вообще не скачивать, указать в качестве исходников сизифа, скажем, зеркало на mirrors.yandex.ru и установить себе squid c политикой LFUDA вместо LRU и большим максимальным размером файла. Будет скачиваться только "рабочий набор" пакетов только один раз в день. Скорость потом будет практически такая же как и на локальном сизифе. 

[devel] I: automake-1.11

[Dmitry V. Levin]

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

On Sun, May 24, 2009 at 11:29:37AM +0400, Sergey Vlasov wrote:
> On Sun, May 24, 2009 at 11:49:51AM +1100, Dmitry Lebkov wrote:
> > On 24.05.2009 04:42, Alexey I. Froloff wrote:
> > > * Dmitry Lebkov<dima@>  [090523 21:29]:
> > >> Локально, через gear-hsh, всё собирается нормально.
> > > Это не показатель.
> > >
> > >> Какие-то проблемы на удаленной сборочнице?
> > > Какие-то проблемы в пакете:
> > >
> > > include_racoon_HEADERS = racoonctl.h var.h vmbuf.h misc.h gcmalloc.h admin.h \
> > >>                                           ^^^^^^^
> > >          schedule.h sockmisc.h vmbuf.h isakmp_var.h isakmp.h isakmp_xauth.h \
> > >>                              ^^^^^^^
> > >          isakmp_cfg.h isakmp_unity.h ipsec_doi.h evt.h
> > 
> > Этого-то я и не заметил при рассматривании логов ... Мда ... =\
> > 
> > Спасибо всем отозвавшимся. Интересно, а такие проблемы как-то
> > можно отлавливать при локальном тестировании, до отправки задания
> > на сборку?
> 
> Можно, если иметь локально достаточно свежий Сизиф (в данном случае
> проблема проявилась из-за изменений в coreutils).

Это из-за обновления automake-1.10 -> automake-1.11; согласно NEWS,
* Miscellaneous changes:
  - The targets `install' and `uninstall' are more efficient now, in that
  for example multiple files from one Automake variable such as
  `bin_SCRIPTS' are copied in one `install' (or `libtool --mode=install')
  invocation if they do not have to be renamed.
  [...]
  These changes may need some adjustments from users:  For example,
  some `install' programs refuse to install multiple copies of the
  same file in one invocation, so you may need to remove duplicate
  entries from file lists.


-- 
ldv

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

Re: [devel] I: automake-1.11

[Led]

On Monday, 25 May 2009 01:28:14 Dmitry V. Levin wrote:
> On Sun, May 24, 2009 at 11:29:37AM +0400, Sergey Vlasov wrote:
> > On Sun, May 24, 2009 at 11:49:51AM +1100, Dmitry Lebkov wrote:
> > > On 24.05.2009 04:42, Alexey I. Froloff wrote:
> > > > * Dmitry Lebkov<dima@>  [090523 21:29]:
> > > >> Локально, через gear-hsh, всё собирается нормально.
> > > >
> > > > Это не показатель.
> > > >
> > > >> Какие-то проблемы на удаленной сборочнице?
> > > >
> > > > Какие-то проблемы в пакете:
> > > >
> > > > include_racoon_HEADERS = racoonctl.h var.h vmbuf.h misc.h gcmalloc.h
> > > > admin.h \
> > > >
> > > >>                                           ^^^^^^^
> > > >
> > > >          schedule.h sockmisc.h vmbuf.h isakmp_var.h isakmp.h
> > > > isakmp_xauth.h \
> > > >
> > > >>                              ^^^^^^^
> > > >
> > > >          isakmp_cfg.h isakmp_unity.h ipsec_doi.h evt.h
> > >
> > > Этого-то я и не заметил при рассматривании логов ... Мда ... =\
> > >
> > > Спасибо всем отозвавшимся. Интересно, а такие проблемы как-то
> > > можно отлавливать при локальном тестировании, до отправки задания
> > > на сборку?
> >
> > Можно, если иметь локально достаточно свежий Сизиф (в данном случае
> > проблема проявилась из-за изменений в coreutils).
>
> Это из-за обновления automake-1.10 -> automake-1.11; согласно NEWS,
> * Miscellaneous changes:
>   - The targets `install' and `uninstall' are more efficient now, in that
>   for example multiple files from one Automake variable such as
>   `bin_SCRIPTS' are copied in one `install' (or `libtool --mode=install')
>   invocation if they do not have to be renamed.
>   [...]
>   These changes may need some adjustments from users:  For example,
>   some `install' programs refuse to install multiple copies of the
>   same file in one invocation, so you may need to remove duplicate
>   entries from file lists.

По этим граблям мы будем ходить бесконечно (когда после обновления 
auto{что-то} "отваливается" куча пакетов.

Есть же макросы %set_auto*_version, при их явном указании в BuildRequires в 
src.rpm попадают зависимости на конкретные версии auto*. Почему бы не сделать 
так, чтобы и БЕЗ явного использования этих макросов происходило то же самое?

-- 
Led

Re: [devel] I: automake-1.11

[Dmitry V. Levin]

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

On Mon, May 25, 2009 at 02:00:43AM +0300, Led wrote:
> On Monday, 25 May 2009 01:28:14 Dmitry V. Levin wrote:
[...]
> > Это из-за обновления automake-1.10 -> automake-1.11; согласно NEWS,
> > * Miscellaneous changes:
> >   - The targets `install' and `uninstall' are more efficient now, in that
> >   for example multiple files from one Automake variable such as
> >   `bin_SCRIPTS' are copied in one `install' (or `libtool --mode=install')
> >   invocation if they do not have to be renamed.
> >   [...]
> >   These changes may need some adjustments from users:  For example,
> >   some `install' programs refuse to install multiple copies of the
> >   same file in one invocation, so you may need to remove duplicate
> >   entries from file lists.
> 
> По этим граблям мы будем ходить бесконечно (когда после обновления 
> auto{что-то} "отваливается" куча пакетов.

Мы будем пытаться содержать свои пакеты в порядке, или будем жаловаться,
что эти вредители ломают наши пакеты? ;)
Я считаю, что новые версии тех пакетов, которые я собираю в Сизиф,
в целом лучше предыдущих версий.
Впрочем, желающие могут использовать %set_*_version для привязки версий
пакетов.

> Есть же макросы %set_auto*_version, при их явном указании в BuildRequires в 
> src.rpm попадают зависимости на конкретные версии auto*. Почему бы не сделать 
> так, чтобы и БЕЗ явного использования этих макросов происходило то же самое?

Не понимаю.


-- 
ldv

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

Re: [devel] I: automake-1.11

[Led]

On Monday, 25 May 2009 22:47:17 Dmitry V. Levin wrote:
> On Mon, May 25, 2009 at 02:00:43AM +0300, Led wrote:
> > On Monday, 25 May 2009 01:28:14 Dmitry V. Levin wrote:
>
> [...]
>
> > > Это из-за обновления automake-1.10 -> automake-1.11; согласно NEWS,
> > > * Miscellaneous changes:
> > >   - The targets `install' and `uninstall' are more efficient now, in
> > > that for example multiple files from one Automake variable such as
> > > `bin_SCRIPTS' are copied in one `install' (or `libtool --mode=install')
> > > invocation if they do not have to be renamed.
> > >   [...]
> > >   These changes may need some adjustments from users:  For example,
> > >   some `install' programs refuse to install multiple copies of the
> > >   same file in one invocation, so you may need to remove duplicate
> > >   entries from file lists.
> >
> > По этим граблям мы будем ходить бесконечно (когда после обновления
> > auto{что-то} "отваливается" куча пакетов.
>
> Мы будем пытаться содержать свои пакеты в порядке, или будем жаловаться,
> что эти вредители ломают наши пакеты? ;)

Вы меня с кем-то путаете:) Я - за ПОВЫШЕННОЕ внимаение к своим пакетам.

> Я считаю, что новые версии тех пакетов, которые я собираю в Сизиф,
> в целом лучше предыдущих версий.
> Впрочем, желающие могут использовать %set_*_version для привязки версий
> пакетов.
>
> > Есть же макросы %set_auto*_version, при их явном указании в BuildRequires
> > в src.rpm попадают зависимости на конкретные версии auto*. Почему бы не
> > сделать так, чтобы и БЕЗ явного использования этих макросов происходило
> > то же самое?
>
> Не понимаю.

Жаль. В любом случае - я не настаиваю.

-- 
Led

Re: [devel] I: automake-1.11

[Dmitry V. Levin]

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

On Mon, May 25, 2009 at 11:41:48PM +0300, Led wrote:
> On Monday, 25 May 2009 22:47:17 Dmitry V. Levin wrote:
> > On Mon, May 25, 2009 at 02:00:43AM +0300, Led wrote:
[...]
> > > Есть же макросы %set_auto*_version, при их явном указании в BuildRequires
> > > в src.rpm попадают зависимости на конкретные версии auto*. Почему бы не
> > > сделать так, чтобы и БЕЗ явного использования этих макросов происходило
> > > то же самое?
> >
> > Не понимаю.
> 
> Жаль. В любом случае - я не настаиваю.

Если речь идёт о том, чтобы помещать версию automake, которая
предположительно использовалась для сборки, в зависимости собранного
srpm-пакета, то это не будет работать при сборке из git-репозиториев.


-- 
ldv

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

Re: [devel] I: automake-1.11

[Led]

On Monday, 25 May 2009 23:51:48 Dmitry V. Levin wrote:
> On Mon, May 25, 2009 at 11:41:48PM +0300, Led wrote:
> > On Monday, 25 May 2009 22:47:17 Dmitry V. Levin wrote:
> > > On Mon, May 25, 2009 at 02:00:43AM +0300, Led wrote:
>
> [...]
>
> > > > Есть же макросы %set_auto*_version, при их явном указании в
> > > > BuildRequires в src.rpm попадают зависимости на конкретные версии
> > > > auto*. Почему бы не сделать так, чтобы и БЕЗ явного использования
> > > > этих макросов происходило то же самое?
> > >
> > > Не понимаю.
> >
> > Жаль. В любом случае - я не настаиваю.
>
> Если речь идёт о том, чтобы помещать версию automake, которая
> предположительно использовалась для сборки, в зависимости собранного
> srpm-пакета,

Да

> то это не будет работать при сборке из git-репозиториев. 

Да, не будет. Но тестовые персборки происходят разве из git-репозитариев? Я 
так понял, что тестовые пересборки производятся для проверки собираемости 
srpms. Я неправ?

-- 
Led

Re: [devel] I: automake-1.11

[Dmitry V. Levin]

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

On Tue, May 26, 2009 at 12:04:33AM +0300, Led wrote:
> On Monday, 25 May 2009 23:51:48 Dmitry V. Levin wrote:
> > On Mon, May 25, 2009 at 11:41:48PM +0300, Led wrote:
> > > On Monday, 25 May 2009 22:47:17 Dmitry V. Levin wrote:
> > > > On Mon, May 25, 2009 at 02:00:43AM +0300, Led wrote:
> >
> > [...]
> >
> > > > > Есть же макросы %set_auto*_version, при их явном указании в
> > > > > BuildRequires в src.rpm попадают зависимости на конкретные версии
> > > > > auto*. Почему бы не сделать так, чтобы и БЕЗ явного использования
> > > > > этих макросов происходило то же самое?
> > > >
> > > > Не понимаю.
> > >
> > > Жаль. В любом случае - я не настаиваю.
> >
> > Если речь идёт о том, чтобы помещать версию automake, которая
> > предположительно использовалась для сборки, в зависимости собранного
> > srpm-пакета,
> 
> Да

Интересно, а если automake не использовался во время сборки, что помещать
в зависимости?

> > то это не будет работать при сборке из git-репозиториев. 
> 
> Да, не будет. Но тестовые персборки происходят разве из git-репозитариев? Я 
> так понял, что тестовые пересборки производятся для проверки собираемости 
> srpms. Я неправ?

Для чего нужны тестовые пересборки?  Для тестирования воспроизводимости
пересборки из исходного кода.  Если srpm является производным объектом, а
не исходным кодом, то эффект от тестирования такого srpm будет не тот, на
который мы рассчитываем, затевая тестовую пересборку.
Тем не менее, сейчас тестовые пересборки всё ещё используют srpm-пакеты даже
там, где следует использовать git-репозитории.  Это хочется исправить, но
руки ещё не дошли.


-- 
ldv

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

Re: [devel] I: automake-1.11

[Led]

On Tuesday, 26 May 2009 00:27:05 Dmitry V. Levin wrote:
> On Tue, May 26, 2009 at 12:04:33AM +0300, Led wrote:
> > On Monday, 25 May 2009 23:51:48 Dmitry V. Levin wrote:
> > > On Mon, May 25, 2009 at 11:41:48PM +0300, Led wrote:
> > > > On Monday, 25 May 2009 22:47:17 Dmitry V. Levin wrote:
> > > > > On Mon, May 25, 2009 at 02:00:43AM +0300, Led wrote:
> > >
> > > [...]
> > >
> > > > > > Есть же макросы %set_auto*_version, при их явном указании в
> > > > > > BuildRequires в src.rpm попадают зависимости на конкретные версии
> > > > > > auto*. Почему бы не сделать так, чтобы и БЕЗ явного использования
> > > > > > этих макросов происходило то же самое?
> > > > >
> > > > > Не понимаю.
> > > >
> > > > Жаль. В любом случае - я не настаиваю.
> > >
> > > Если речь идёт о том, чтобы помещать версию automake, которая
> > > предположительно использовалась для сборки, в зависимости собранного
> > > srpm-пакета,
> >
> > Да
>
> Интересно, а если automake не использовался во время сборки, что помещать
> в зависимости?

Это можно выяснить, например, по использованию макроса %autoreconf, и, 
возможно, %__automake

>
> > > то это не будет работать при сборке из git-репозиториев.
> >
> > Да, не будет. Но тестовые персборки происходят разве из git-репозитариев?
> > Я так понял, что тестовые пересборки производятся для проверки
> > собираемости srpms. Я неправ?
>
> Для чего нужны тестовые пересборки?  Для тестирования воспроизводимости
> пересборки из исходного кода.  Если srpm является производным объектом, а
> не исходным кодом, то эффект от тестирования такого srpm будет не тот, на
> который мы рассчитываем, затевая тестовую пересборку.
> Тем не менее, сейчас тестовые пересборки всё ещё используют srpm-пакеты
> даже там, где следует использовать git-репозитории.  Это хочется исправить,
> но руки ещё не дошли.

А контейнер (вместо src.rpm) для исходного кода уже утверждён?
К тому же, в бинарном rpm-пакете указано, из чего он собран. До сегодняшнего 
дня в качестве своего исходника пакеты указывали некий src.rpm. Они врут? Или 
для того, чтобы найти исходники пакетов с GPL-софтом, нужно 
быть "посвящённым", куда-то подписываться или у кого-то паспрашивать?
ИМХО git-репозитарий - это не контейнер для пакета с исходниками.

-- 
Led

Re: [devel] I: automake-1.11

[Alexey Rusakov]

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

В Втр, 26/05/2009 в 00:46 +0300, Led пишет:
> On Tuesday, 26 May 2009 00:27:05 Dmitry V. Levin wrote:
> > Интересно, а если automake не использовался во время сборки, что помещать
> > в зависимости?
> 
> Это можно выяснить, например, по использованию макроса %autoreconf, и, 
> возможно, %__automake
Это не работает, если используются скрипты autogen.sh - automake тогда
вызывается (или не вызывается - не знаю, впрочем, таких случаев) помимо
rpm.
В целом, имхо, не очень надёжный подход.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: automake-1.11

[Led]

On Tuesday, 26 May 2009 01:12:18 Alexey Rusakov wrote:
> В Втр, 26/05/2009 в 00:46 +0300, Led пишет:
> > On Tuesday, 26 May 2009 00:27:05 Dmitry V. Levin wrote:
> > > Интересно, а если automake не использовался во время сборки, что
> > > помещать в зависимости?
> >
> > Это можно выяснить, например, по использованию макроса %autoreconf, и,
> > возможно, %__automake
>
> Это не работает, если используются скрипты autogen.sh - automake тогда
> вызывается (или не вызывается - не знаю, впрочем, таких случаев) помимо
> rpm.
> В целом, имхо, не очень надёжный подход.

"Серебрянной пули" не бывает.
Я с вами полностью согласен, что это не 100-процентный метод.
Я всего лишь высказал мнение/предложение. Уверен, что вы предложите более 
правильный вариант (а заодно и покритикуете те не-100-процентные методы, 
которые у нас успешно используюся:)

-- 
Led

Re: [devel] I: automake-1.11

[Alexey Rusakov]

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

В Втр, 26/05/2009 в 01:20 +0300, Led пишет:
> On Tuesday, 26 May 2009 01:12:18 Alexey Rusakov wrote:
> > В Втр, 26/05/2009 в 00:46 +0300, Led пишет:
> > > On Tuesday, 26 May 2009 00:27:05 Dmitry V. Levin wrote:
> > > > Интересно, а если automake не использовался во время сборки, что
> > > > помещать в зависимости?
> > >
> > > Это можно выяснить, например, по использованию макроса %autoreconf, и,
> > > возможно, %__automake
> >
> > Это не работает, если используются скрипты autogen.sh - automake тогда
> > вызывается (или не вызывается - не знаю, впрочем, таких случаев) помимо
> > rpm.
> > В целом, имхо, не очень надёжный подход.
> 
> "Серебрянной пули" не бывает.
> Я с вами полностью согласен, что это не 100-процентный метод.
> Я всего лишь высказал мнение/предложение. Уверен, что вы предложите более 
> правильный вариант (а заодно и покритикуете те не-100-процентные методы, 
> которые у нас успешно используюся:)
Честно говоря, я придерживаюсь довольно радикальной точки зрения, что
automake - это часть тулчейна, а при апгрейде тулчейна разломы - обычное
дело. Автоматизированные методы неплохо помогают справиться с разломами,
они тоже не 100%-ны, но в результате обычно можно получить всё-таки
более прямую сборку.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: automake-1.11

[Led]

On Tuesday, 26 May 2009 01:30:16 Alexey Rusakov wrote:
> В Втр, 26/05/2009 в 01:20 +0300, Led пишет:
> > On Tuesday, 26 May 2009 01:12:18 Alexey Rusakov wrote:
> > > В Втр, 26/05/2009 в 00:46 +0300, Led пишет:
> > > > On Tuesday, 26 May 2009 00:27:05 Dmitry V. Levin wrote:
> > > > > Интересно, а если automake не использовался во время сборки, что
> > > > > помещать в зависимости?
> > > >
> > > > Это можно выяснить, например, по использованию макроса %autoreconf,
> > > > и, возможно, %__automake
> > >
> > > Это не работает, если используются скрипты autogen.sh - automake тогда
> > > вызывается (или не вызывается - не знаю, впрочем, таких случаев) помимо
> > > rpm.
> > > В целом, имхо, не очень надёжный подход.
> >
> > "Серебрянной пули" не бывает.
> > Я с вами полностью согласен, что это не 100-процентный метод.
> > Я всего лишь высказал мнение/предложение. Уверен, что вы предложите более
> > правильный вариант (а заодно и покритикуете те не-100-процентные методы,
> > которые у нас успешно используюся:)
>
> Честно говоря, я придерживаюсь довольно радикальной точки зрения, что
> automake - это часть тулчейна, а при апгрейде тулчейна разломы - обычное
> дело.

Возможно. Но, по факту, automake обновился отдельно, как и чуть раньше 
libtool, а не в составе какого-то "тулчейна".

> Автоматизированные методы неплохо помогают справиться с разломами, 
> они тоже не 100%-ны, но в результате обычно можно получить всё-таки
> более прямую сборку.

Я, например, не вижу ничего продуктивного и прогрессивного в том, чтобы 
переписывать ПРАВИЛЬНО написанные configure.ac и Makefile.am на новый 
инструмент (пусть он и лучше, чем был старый). Тем более, что более старые 
инструменты долго живут в репозитарии. Зачем "бежать впереди паровоза", 
переписывая configure.ac и Makefile.am, пытаясь уложиться в 10 недель, если в 
большистве случаев произойдёт стандартная процедура: апстрим выпустит новую 
весию софтины (через полгода, пусть в течение года - разве это критично?), 
которая уже будет собираться с новыми auto*?

-- 
Led

Re: [devel] I: automake-1.11

[Alexey Rusakov]

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

В Втр, 26/05/2009 в 01:43 +0300, Led пишет:
> On Tuesday, 26 May 2009 01:30:16 Alexey Rusakov wrote:
> > Честно говоря, я придерживаюсь довольно радикальной точки зрения, что
> > automake - это часть тулчейна, а при апгрейде тулчейна разломы - обычное
> > дело.
> 
> Возможно. Но, по факту, automake обновился отдельно, как и чуть раньше 
> libtool, а не в составе какого-то "тулчейна".
Вот это как раз, имхо, не очень хорошо.

> Я, например, не вижу ничего продуктивного и прогрессивного в том, чтобы 
> переписывать ПРАВИЛЬНО написанные configure.ac и Makefile.am на новый 
> инструмент (пусть он и лучше, чем был старый). Тем более, что более старые 
> инструменты долго живут в репозитарии. Зачем "бежать впереди паровоза", 
> переписывая configure.ac и Makefile.am, пытаясь уложиться в 10 недель, если в 
> большистве случаев произойдёт стандартная процедура: апстрим выпустит новую 
> весию софтины (через полгода, пусть в течение года - разве это критично?), 
> которая уже будет собираться с новыми auto*?
Ну во-первых, далеко не ко всем апстримам это относится. А во-вторых,
никто не мешает поставить в своём пакете привязку к конкретным версиям
autotools и обновлять её по мере своего и апстрима
желания/возможности/готовности. Почему это не сделано умолчанием - не
знаю, не ко мне. Меня такое умолчание в целом устраивает - хлопот от
ошибок времени выполнения лично у меня куда больше, чем от ошибок
времени сборки. С другой стороны, я сейчас сравнительно мало пакетов
собираю. С третьей, если бы собирал много, точно знаю, что вопрос
исправления сборок решал бы автоматизацией. И поскольку ничего на самом
деле не происходит "само собой", я время от времени исправления сборок и
тому подобные вещи забрасываю в апстрим. После чего апстрим "сам собой"
начинает поддерживать, например, --as-needed или новую версию
gnome-doc-utils или ещё что - например, тот же новый automake. Не знаю,
не ощущаю себя как-то "впереди паровоза". Скорее как раз на нём.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: automake-1.11

[Led]

On Tuesday, 26 May 2009 01:55:17 Alexey Rusakov wrote:
> В Втр, 26/05/2009 в 01:43 +0300, Led пишет:
> > On Tuesday, 26 May 2009 01:30:16 Alexey Rusakov wrote:
> > > Честно говоря, я придерживаюсь довольно радикальной точки зрения, что
> > > automake - это часть тулчейна, а при апгрейде тулчейна разломы -
> > > обычное дело.
> >
> > Возможно. Но, по факту, automake обновился отдельно, как и чуть раньше
> > libtool, а не в составе какого-то "тулчейна".
>
> Вот это как раз, имхо, не очень хорошо.

Опять же, "по факту", тулчейн - это то, что у нас тянется в хэшер во время 
сборки(?). Почему туда "тянется" по-умолчанию "распоследний" auto* и libtool? 
При том, что в хост-систему они по dist-upgrade не ставятся?
Я не вижу здесь логики. Не потому, что её нет. Просто я её не вижу:)

>
> > Я, например, не вижу ничего продуктивного и прогрессивного в том, чтобы
> > переписывать ПРАВИЛЬНО написанные configure.ac и Makefile.am на новый
> > инструмент (пусть он и лучше, чем был старый). Тем более, что более
> > старые инструменты долго живут в репозитарии. Зачем "бежать впереди
> > паровоза", переписывая configure.ac и Makefile.am, пытаясь уложиться в 10
> > недель, если в большистве случаев произойдёт стандартная процедура:
> > апстрим выпустит новую весию софтины (через полгода, пусть в течение года
> > - разве это критично?), которая уже будет собираться с новыми auto*?
>
> Ну во-первых, далеко не ко всем апстримам это относится. А во-вторых,
> никто не мешает поставить в своём пакете привязку к конкретным версиям
> autotools и обновлять её по мере своего и апстрима
> желания/возможности/готовности. Почему это не сделано умолчанием - не
> знаю, не ко мне. Меня такое умолчание в целом устраивает - хлопот от
> ошибок времени выполнения лично у меня куда больше, чем от ошибок
> времени сборки. С другой стороны, я сейчас сравнительно мало пакетов
> собираю.

Аналогично. Поэтому даже не столько что-то предлагаю, сколько "интересуюсь", 
спрашиваю:)

> С третьей, если бы собирал много, точно знаю, что вопрос 
> исправления сборок решал бы автоматизацией. И поскольку ничего на самом
> деле не происходит "само собой", я время от времени исправления сборок и
> тому подобные вещи забрасываю в апстрим.

"Время от времени" - это и есть "не бежать впереди паровоза". А не "всё 
бросаю - нужно за 10 недель всё переделать под новый automake". А после того, 
как героически пересобрал велосипеды - начинай сначала: "Новый autofoo 
приехал!":)

> После чего апстрим "сам собой" 
> начинает поддерживать, например, --as-needed или новую версию
> gnome-doc-utils или ещё что - например, тот же новый automake. Не знаю,
> не ощущаю себя как-то "впереди паровоза". Скорее как раз на нём.

-- 
Led

Re: [devel] I: automake-1.11

[Michael Shigorin]

On Tue, May 26, 2009 at 12:04:33AM +0300, Led wrote:
> Но тестовые персборки происходят разве из git-репозитариев?
> Я так понял, что тестовые пересборки производятся для проверки
> собираемости srpms. Я неправ?

Насколько понимаю, ещё и в качестве прогноза.  Вот прилетело мне
раннее предупреждение, что пакет разломается -- у меня есть выбор:
%set_auto*_version, посмотреть, а не было ли новой версии, или
даже исправить (самому или с помощью более опытных коллег).

Если дефолтом сделать фиксирование версий, то этот выбор будет
сделан за всех.  Даже лодыря-меня это устраивает меньше, чем
текущее положение.

Вообще предлагая что-либо, может быть полезным использовать
формулировки из описаний изобретений: "существует такое-то,
имеет недостатки такие-то; предложенное решает такие из них
и так".  А не играть в "угадай мелодию".

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

Re: [devel] I: automake-1.11

[Led]

On Tuesday 26 May 2009 15:55:13 Michael Shigorin wrote:
> On Tue, May 26, 2009 at 12:04:33AM +0300, Led wrote:
> > Но тестовые персборки происходят разве из git-репозитариев?
> > Я так понял, что тестовые пересборки производятся для проверки
> > собираемости srpms. Я неправ?
>
> Насколько понимаю, ещё и в качестве прогноза.  Вот прилетело мне
> раннее предупреждение, что пакет разломается -- у меня есть выбор:
> %set_auto*_version, посмотреть, а не было ли новой версии, или
> даже исправить (самому или с помощью более опытных коллег).

У тебя и сейчас нет выбора: в зависимость сборки попадают виртуальные auto*, и 
ты даже преположить не можешь, что туда попадёт в incoming'

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

Я высказал идею, предположение. Конструктивной критики, кроме "это не работает 
в 100% случаев" я не увидел.
В любом случае, нет - так нет, в своих полдюжине пакетов я как-нибудь могу и 
фиксированный auto* проставить:)

-- 
Led

Re: [devel] I: automake-1.11

[Michael Shigorin]

On Tue, May 26, 2009 at 04:43:22PM +0300, Led wrote:
> > > Я так понял, что тестовые пересборки производятся для
> > > проверки собираемости srpms. Я неправ?
> > Насколько понимаю, ещё и в качестве прогноза.  Вот прилетело
> > мне раннее предупреждение, что пакет разломается -- у меня
> > есть выбор: %set_auto*_version, посмотреть, а не было ли
> > новой версии, или даже исправить (самому или с помощью 
> У тебя и сейчас нет выбора: в зависимость сборки попадают
> виртуальные auto*, и ты даже преположить не можешь, что туда
> попадёт в incoming'

Эээ... "%set_auto*_version" -- в смысле прибить нужное макроскопом.
Вполне себе выбор, нередко так делаю, поскольку не специалист в.

> Я высказал идею, предположение. Конструктивной критики,
> кроме "это не работает в 100% случаев" я не увидел.

Ну меня ты этой идеей удивил вообще-то.  Есть ещё "работает,
не ломай" -- мне вот пока кажется, что текущий подход вполне
работает (даже если и приводит к периодической надобности глупой
или нудной починки пакетов).

> В любом случае, нет - так нет, в своих полдюжине пакетов я
> как-нибудь могу и фиксированный auto* проставить:)

Вопрос в том, надо ли.  Не знаю лично апстрим автокрапа и не
вникал в вопрос, но почему-то думаю, что они не ради лишь
зловредности новые и новые грабли раскладывают в новых версиях.

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

Re: [devel] srpms

[Dmitry V. Levin]

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

On Tue, May 26, 2009 at 12:46:02AM +0300, Led wrote:
> On Tuesday, 26 May 2009 00:27:05 Dmitry V. Levin wrote:
> > On Tue, May 26, 2009 at 12:04:33AM +0300, Led wrote:
> > > On Monday, 25 May 2009 23:51:48 Dmitry V. Levin wrote:
[...]
> > > > то это не будет работать при сборке из git-репозиториев.
> > >
> > > Да, не будет. Но тестовые персборки происходят разве из git-репозитариев?
> > > Я так понял, что тестовые пересборки производятся для проверки
> > > собираемости srpms. Я неправ?
> >
> > Для чего нужны тестовые пересборки?  Для тестирования воспроизводимости
> > пересборки из исходного кода.  Если srpm является производным объектом, а
> > не исходным кодом, то эффект от тестирования такого srpm будет не тот, на
> > который мы рассчитываем, затевая тестовую пересборку.
> > Тем не менее, сейчас тестовые пересборки всё ещё используют srpm-пакеты
> > даже там, где следует использовать git-репозитории.  Это хочется исправить,
> > но руки ещё не дошли.
> 
> А контейнер (вместо src.rpm) для исходного кода уже утверждён?

При сборке пакета из git-репозитория srpm является внутренним транспортным
контейнером, который использует hasher.  srpm является функцией этого
git-репозитория и сборочной среды.  Иногда spec-файлы устроены так хитро,
что srpm сложно воспроизвести из содержащихся в нём файлов.

> К тому же, в бинарном rpm-пакете указано, из чего он собран. До сегодняшнего 
> дня в качестве своего исходника пакеты указывали некий src.rpm. Они врут?

%{sourcerpm} по прежнему указывает на тот srpm, из которого был собран
бинарный пакет.  Но в случае со сборкой из git-репозитория этот srpm,
очевидно, является лишь транспортом между git-репозиторем и бинарным
пакетом.

> Или 
> для того, чтобы найти исходники пакетов с GPL-софтом, нужно 
> быть "посвящённым", куда-то подписываться или у кого-то паспрашивать?
> ИМХО git-репозитарий - это не контейнер для пакета с исходниками.

git-репозиторий -- это сам исходный код, во всей его полноте.
А вот srpm -- это не всегда полноценный исходный код, поскольку тривиальное
на вид действие вида распаковать-модифицировать-запаковать не всегда
воспроизводимо для srpm, ибо srpm является функцией содержащихся в нём
файлов И сборочной среды, которую эти файлы не всегда описывают полностью.

Кстати, то, что вы предложили в плане привязки версий в заголовке srpm,
сделало бы srpm ещё менее воспроизводимым из содержащихся в нём файлов.


-- 
ldv

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

Re: [devel] srpms

[Michael Shigorin]

On Wed, May 27, 2009 at 03:41:20AM +0400, Dmitry V. Levin wrote:
> > К тому же, в бинарном rpm-пакете указано, из чего он собран.
> > До сегодняшнего дня в качестве своего исходника пакеты
> > указывали некий src.rpm. Они врут?
> %{sourcerpm} по прежнему указывает на тот srpm, из которого был
> собран бинарный пакет.  Но в случае со сборкой из
> git-репозитория этот srpm, очевидно, является лишь транспортом
> между git-репозиторем и бинарным пакетом.

И он при этом публикуется в files/SRPMS/.

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

Re: [devel] srpms

[Mikhail Gusarov]

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


Twas brillig at 13:16:45 27.05.2009 UTC+03 when mike@osdn.org.ua did gyre and gimble:

 >> %{sourcerpm} по прежнему указывает на тот srpm, из которого был
 >> собран бинарный пакет.  Но в случае со сборкой из git-репозитория
 >> этот srpm, очевидно, является лишь транспортом между git-репозиторем
 >> и бинарным пакетом.

 MS> И он при этом публикуется в files/SRPMS/.

Который теперь есть место отстоя транспортов :)

-- 

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

Re: [devel] srpms

[Dmitry V. Levin]

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

On Wed, May 27, 2009 at 01:16:45PM +0300, Michael Shigorin wrote:
> On Wed, May 27, 2009 at 03:41:20AM +0400, Dmitry V. Levin wrote:
> > > К тому же, в бинарном rpm-пакете указано, из чего он собран.
> > > До сегодняшнего дня в качестве своего исходника пакеты
> > > указывали некий src.rpm. Они врут?
> > %{sourcerpm} по прежнему указывает на тот srpm, из которого был
> > собран бинарный пакет.  Но в случае со сборкой из
> > git-репозитория этот srpm, очевидно, является лишь транспортом
> > между git-репозиторем и бинарным пакетом.
> 
> И он при этом публикуется в files/SRPMS/.

При этом публикуется не только он, но и репозиторий с тэгом, из которого
этот srpm был собран.  Наступит время, когда srpm'ы перестанут
публиковаться за ненадобностью.


-- 
ldv

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

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 02:20:19PM +0400, Dmitry V. Levin wrote:
> Наступит время, когда srpm'ы перестанут публиковаться за ненадобностью.
нет, вы точно издеваетесь. давайте сравним:

1й вариант:
1. apt-get source srpm
2. роемся

2й вариант:
1. найти нужный gear
2. скачать gear репу: 
   - git clone репа
   - git checkout тег/коммит
   либо
   - найти тег на http://git.alt
   - скачать snaphsot и распаковать
3. gear-rpm -bs --nodeps
4. rpm -ihv srpm
5. роемся


это все для чего? чтобы оттолкнуть побольше патчеписателей, на отсутствие
которых и так жалуются?

неет, вот сделаете чтобы по <apt-get source пакет> качался нужный снапшот
gear'а, сделаете чтобы для работы с пакетом нужно было знать ЛИБО gear
ЛИБО srpm - вот тогда да, тогда отменяем.

а до тех пор - gear инструмент подготовки srpm, а не основа.

-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] srpms

[Kirill A. Shutemov]

2009/5/27 Afanasov Dmitry <ender@altlinux.org>:
> On Wed, May 27, 2009 at 02:20:19PM +0400, Dmitry V. Levin wrote:
>> Наступит время, когда srpm'ы перестанут публиковаться за ненадобностью.
> нет, вы точно издеваетесь. давайте сравним:
>
> 1й вариант:
> 1. apt-get source srpm
> 2. роемся
>
> 2й вариант:
> 1. найти нужный gear
> 2. скачать gear репу:
>   - git clone репа
>   - git checkout тег/коммит
>   либо
>   - найти тег на http://git.alt
>   - скачать snaphsot и распаковать
> 3. gear-rpm -bs --nodeps
> 4. rpm -ihv srpm
> 5. роемся
>

Зачем пункты 3-5?

Re: [devel] srpms

[Andrey Rahmatullin]

On Wed, May 27, 2009 at 02:44:03PM +0300, Kirill A. Shutemov wrote:
> > 3. gear-rpm -bs --nodeps
> > 4. rpm -ihv srpm
> > 5. роемся
> Зачем пункты 3-5?
Для тех, кто может рыться только в srpm, т.к. по результату git checkout
4.2-alt1 в общем случае не понять, особенно сходу, что же там собирается.

Re: [devel] srpms

[Kirill A. Shutemov]

2009/5/27 Andrey Rahmatullin <wrar@altlinux.ru>:
> On Wed, May 27, 2009 at 02:44:03PM +0300, Kirill A. Shutemov wrote:
>> > 3. gear-rpm -bs --nodeps
>> > 4. rpm -ihv srpm
>> > 5. роемся
>> Зачем пункты 3-5?
> Для тех, кто может рыться только в srpm, т.к. по результату git checkout
> 4.2-alt1 в общем случае не понять, особенно сходу, что же там собирается.

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

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 02:44:03PM +0300, Kirill A. Shutemov wrote:
> 2009/5/27 Afanasov Dmitry <ender@altlinux.org>:
> > On Wed, May 27, 2009 at 02:20:19PM +0400, Dmitry V. Levin wrote:
> >> Наступит время, когда srpm'ы перестанут публиковаться за ненадобностью.
> > нет, вы точно издеваетесь. давайте сравним:
> >
> > 1й вариант:
> > 1. apt-get source srpm
> > 2. роемся
> >
> > 2й вариант:
> > 1. найти нужный gear
> > 2. скачать gear репу:
> >   - git clone репа
> >   - git checkout тег/коммит
> >   либо
> >   - найти тег на http://git.alt
> >   - скачать snaphsot и распаковать
> > 3. gear-rpm -bs --nodeps
> > 4. rpm -ihv srpm
> > 5. роемся
> >
> 
> Зачем пункты 3-5?
затем, что иначе требуют от привычных к srpm дополнительного изучения gear
и git. и требуют
- заменить 2 на поиск и checkout branch (интересно, многие знают про git branch
  --contains <commit>?)
- также добавить поиск бранча, откуда же растут патчи
- не забыть про commit

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

/me до сих пор с ужасом вспоминает кучу перелопаченной инфы, когда не зная
git полез разбиратьсяв kernel, куда esfq делось, и как его накладывать
заного.
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] srpms

[Mikhail Gusarov]

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


Twas brillig at 15:56:28 27.05.2009 UTC+04 when ender@altlinux.org did gyre and gimble:

 AD> - также добавить поиск бранча, откуда же растут патчи

Нет.

 AD> всё это требует более глубокое знание git,

Нет.

-- 

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

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 02:56:09PM +0300, Kirill A. Shutemov wrote:
> Если вы не можете разобраться в том, что лежит в git, то смысл смотреть в
> srpm? В случае сборки из git, srpm исходником не является и править его
> бессмысленно.
что тоже является очередным барьером к пониманию, как работает альт.
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] srpms

[Slava Semushin]

27 мая 2009 г. 18:56 пользователь Afanasov Dmitry <ender@altlinux.org> написал:
[...]
>> > 2. скачать gear репу:
>> >   - git clone репа
>> >   - git checkout тег/коммит
>> >   либо
>> >   - найти тег на http://git.alt
>> >   - скачать snaphsot и распаковать
[...]
> - заменить 2 на поиск и checkout branch (интересно, многие знают про git branch
>  --contains <commit>?)

Нет. А что эта команда далает полезного и когда её использовать?


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

Re: [devel] srpms

[Andrey Rahmatullin]

On Wed, May 27, 2009 at 02:56:09PM +0300, Kirill A. Shutemov wrote:
> Если вы не можете разобраться в том, что лежит в git, то смысл смотреть в
> srpm?
Српм я видел, например, в моём основном дистрибутиве, а насчёт гита - в
српме не надо искать и руками получать актуальные исходники/патчи, они там
уже лежат.

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 07:00:22PM +0700, Slava Semushin wrote:
> 27 мая 2009 г. 18:56 пользователь Afanasov Dmitry <ender@altlinux.org> написал:
> > - заменить 2 на поиск и checkout branch (интересно, многие знают про git branch
> >  --contains <commit>?)
> 
> Нет. А что эта команда далает полезного и когда её использовать?
столкнулся то ли в ffmpeg'е, то ли в mlayer'е, когда пытался понять,
откуда растет коммит.

$ cd git/mplayer
$ git branch --contains=1.0rc3-alt1.M50.1
branch/5.0

жаль эта команда показывает все бранчи, куда по истории подключен этот
коммит, а не только тот, куда он приложен. брр, примером проще показать.
та же репа:
$ git branch --contains=ffmpeg/r18694
  1.0rc3-master
  1.0rc3-patch/nls
  1.0rc3-sources
  branch/5.0
* master
  patch/nls
  patch/vaapi
  sources

а нужно было показать только sources, так как он по сути sources^8. 

кстати, вопрос, а в commit'е указание, в какой бранч он закоммичен, есть?
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 06:57:59PM +0700, Mikhail Gusarov wrote:
> 
> Twas brillig at 15:56:28 27.05.2009 UTC+04 when ender@altlinux.org did gyre and gimble:
> 
>  AD> - также добавить поиск бранча, откуда же растут патчи
> 
> Нет.
Кирпич.
> 
>  AD> всё это требует более глубокое знание git,
> 
> Нет.
Кирпич.

-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] srpms

[Aleksey Avdeev]

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

Afanasov Dmitry пишет:
...
> 
> кстати, вопрос, а в commit'е указание, в какой бранч он закоммичен, есть?

   Нет: Коммит вещь постоянная, а бранч -- переменная.

-- 

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



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

Re: [devel] srpms

[Aleksey Avdeev]

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

Afanasov Dmitry пишет:
> On Wed, May 27, 2009 at 04:24:55PM +0400, Aleksey Avdeev wrote:
>> Afanasov Dmitry пишет:
>> ...
>>> кстати, вопрос, а в commit'е указание, в какой бранч он закоммичен, есть?
>>    Нет: Коммит вещь постоянная, а бранч -- переменная.
> жаль. значит правильно я refs/heads/* вопринимаю как указатель,
> перемещаийся с каждым коммитом.

   Да.

-- 

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



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

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 04:24:55PM +0400, Aleksey Avdeev wrote:
> Afanasov Dmitry пишет:
> ...
> > 
> > кстати, вопрос, а в commit'е указание, в какой бранч он закоммичен, есть?
> 
>    Нет: Коммит вещь постоянная, а бранч -- переменная.
жаль. значит правильно я refs/heads/* вопринимаю как указатель,
перемещаийся с каждым коммитом.

-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] srpms

[Alexey I. Froloff]

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

* Afanasov Dmitry <ender@> [090527 15:42]:
> 1. найти нужный gear
git://git.altlinux.org/gears/и/имяисходногопакета.git (или
/srpms/ если сборка была из src.rpm'а).

>    - найти тег на http://git.alt
Этот тег совпадает с HEAD соответствующей репозитарию ветки.

Так что не надо тут делать вид, что это непосильная задача.

-- 
Regards,
Sir Raorn.

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

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 04:53:02PM +0400, Alexey I. Froloff wrote:
> * Afanasov Dmitry <ender@> [090527 15:42]:
> > 1. найти нужный gear
> git://git.altlinux.org/gears/и/имяисходногопакета.git (или
> /srpms/ если сборка была из src.rpm'а).
ой, а там структура уже изменилась, линейной стала. так что теперь
независимо от устройства родного gear'а, итоговый репозиатрий будет самым
простым.

теперь заодно ясно стало зачем в gear проверка на merge
(is_ancestor_commit который) - без неё коммиты, откуда был взят патч, не
войдут репу на gears/

прошу прощения, я считал основной репой тот, что из git.alt:/people/. а
оказывается он тоже "транспорт" - основа в gears/.

> >    - найти тег на http://git.alt
> Этот тег совпадает с HEAD соответствующей репозитарию ветки.
для точности - сопадает только для тега соответствующему последнему
релизу. по сути - смотрится там же, в ветке для бранча. а то и в списке
тегов.

> Так что не надо тут делать вид, что это непосильная задача.
в ноябре, пока не ухлопал рабочую неделю на изучение git, была непосильна.
как время ухлопал, работать с пакетами на постоянной основе стало конечно
проще. всегда можно откатить, не городить море каталогов для каждой
сохраненной версии.

но - "пока не ухлопал". а тут частенько жалуются на время, значит такая
возможностьт есть не у всех.

и - "на постоянной": внести быструю правку и пнуть мантейнера проще при
apt-get source srpm, чем git clone и gear-rpm -ba.

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

засим я стою на прежнем: пока apt-get source (ну или gear-get source) не
будет сам искать репу, качать оттуда snapshot и распаковывать, говорить об
отказе srpm рано.

-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] srpms

[Alexey I. Froloff]

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

* Afanasov Dmitry <ender@> [090527 17:20]:
> прошу прощения, я считал основной репой тот, что из git.alt:/people/. а
> оказывается он тоже "транспорт" - основа в gears/.
Не совсем.  В gears/ тоже по большому счёту транспорт.
Посмотреть какие патчи приложены ещё можно, а вот собрать на базе
этого репо новую версию пакета может быть затруднительно.

> засим я стою на прежнем: пока apt-get source (ну или gear-get source) не
> будет сам искать репу, качать оттуда snapshot и распаковывать, говорить об
> отказе srpm рано.
Есть пакет girar-utils, в репозитарий которого я слегка пописываю.
Как должен выглядеть этот girar-get, какие опции принимать и что
выдавать на выходе?

-- 
Regards,
Sir Raorn.

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

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 05:27:58PM +0400, Alexey I. Froloff wrote:
> * Afanasov Dmitry <ender@> [090527 17:20]:
> > прошу прощения, я считал основной репой тот, что из git.alt:/people/. а
> > оказывается он тоже "транспорт" - основа в gears/.
> Не совсем.  В gears/ тоже по большому счёту транспорт.
кхмм, я конечно любитель обобщать, но чую мы так мы скоро докатимся, что у
нас все "транспорт" между мозгом разрабов и конечным процессором :)

> Посмотреть какие патчи приложены ещё можно, а вот собрать на базе
> этого репо новую версию пакета может быть затруднительно.
основываться на нем для постоянной работы - согласен, затруднительно. для
постоянной работы и srpm менее удобен :)

но я все продолжаю гнуть линию о людях, в чьи задачи не входит поддержка
пакетов, но которым надо что-то починить/добавить. есть же народ, что
знает C, может накладывать патчи, так? есть народ, что знает C, умеет
патчить, знает git. вот только C+paches+git много меньше чем про просто
C+patches. а ведь им всем ещё в нашем spec'о писании разобраться надо.

для них нужен apt-get source и srpm.

> Есть пакет girar-utils, в репозитарий которого я слегка пописываю.
это интересно, отдельным письмом :)
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 05:27:58PM +0400, Alexey I. Froloff wrote:
> > засим я стою на прежнем: пока apt-get source (ну или gear-get source) не
> > будет сам искать репу, качать оттуда snapshot и распаковывать, говорить об
> > отказе srpm рано.
> Есть пакет girar-utils, в репозитарий которого я слегка пописываю.
> Как должен выглядеть этот girar-get, какие опции принимать и что
> выдавать на выходе?
по треду задача будет выглядеть так:
на входе -  <package>, имя бинарного rpm пакета из apt'кеша.
на выходе - gear репозитарий либо tar.[gz|bz2] snapshot (ключик --snapshot
добавить)

сразу вижу большое но - для разработки (нам) это неудобно, для внешних
пользователей - очередная неизвестная утилита, о которой ещё надо
проинформировать.

потому я и уперся на apt-get, как основной инструмент доступа к пакетной
базе.


а так мне очень интересен расширенный функционал git.alt find-packages. на входе
опять-таки имеем rpm пакет, на выходе список ссылок, откуда этот пакет
вырос.

то есть задача: разыменовать бинарный пакет в srpm, по srpm вычислить
таг/коммит, найти репы с этим коммитом на git.alt'е.
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] srpms

[Alexey I. Froloff]

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

* Afanasov Dmitry <ender@> [090527 17:56]:
> то есть задача: разыменовать бинарный пакет в srpm,
Это просто.

> по srpm вычислить таг/коммит,
В общем случае невозможно.

> найти репы с этим коммитом на git.alt'е.
В общем случае невозможно.

-- 
Regards,
Sir Raorn.

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

Re: [devel] srpms

[Afanasov Dmitry]

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

On Wed, May 27, 2009 at 06:16:44PM +0400, Alexey I. Froloff wrote:
> * Afanasov Dmitry <ender@> [090527 17:56]:
> > то есть задача: разыменовать бинарный пакет в srpm,
> Это просто.
> 
> > по srpm вычислить таг/коммит,
> В общем случае невозможно.
> 
> > найти репы с этим коммитом на git.alt'е.
> В общем случае невозможно.
и это грустно. слишком много свободы в git'е. один rebase с cherry-pick
чего стоит.

но если хоть какое-то попадаение будет, уже здорово.
-- 
С уважением
Афанасов Дмитрий

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