[devel] ACL request for perl update to 5.30

[devel] ACL request for perl update to 5.30

[Igor Vlasenko]

Уважаемый администратор Сизифа,

прошу добавить acl @cpan к пакетам ниже,
чтобы их можно было пересобрать при обновлении perl.
(зависят от libperl*.so*).

hivex   shaba rider
libguestfs      shaba rider
libstfl0        vseleznv
pve-cluster     shrek

-- 

I V

Re: [devel] ACL request for perl update to 5.30

[Dmitry V. Levin]

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

On Wed, Dec 04, 2019 at 08:15:16PM +0200, Igor Vlasenko wrote:
> Уважаемый администратор Сизифа,
> 
> прошу добавить acl @cpan к пакетам ниже,

@cpan - это, конечно, не @python, но тоже неплохая компания людей.

> чтобы их можно было пересобрать при обновлении perl.
> (зависят от libperl*.so*).
> 
> hivex   shaba rider
> libguestfs      shaba rider
> libstfl0        vseleznv
> pve-cluster     shrek

Пусть лучше мантейнеры сами добавят.

Когда надо будет одобрить задание с пересборкой пакетов под новую версию
perl, просто напишите об этом.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > On Wed, Dec 04, 2019 at 08:15:16PM +0200, Igor Vlasenko wrote:
 >> Уважаемый администратор Сизифа,
 >> 
 >> прошу добавить acl @cpan к пакетам ниже,

 > @cpan - это, конечно, не @python, но тоже неплохая компания людей.

 >> чтобы их можно было пересобрать при обновлении perl.
 >> (зависят от libperl*.so*).
 >> 
 >> hivex   shaba rider
 >> libguestfs      shaba rider
 >> libstfl0        vseleznv
 >> pve-cluster     shrek

 > Пусть лучше мантейнеры сами добавят.

 > Когда надо будет одобрить задание с пересборкой пакетов под новую версию
 > perl, просто напишите об этом.

Говоря о perl:

$ LC_ALL=C rpmquery -p --lastchange packages/sisyphus/files/SRPMS/perl-BDB-1.92-alt2.src.rpm
* Tue Dec 03 2019 Igor Vlasenko <viy@altlinux.ru> 1:1.92-alt2

- migration to libdb4.8

$ LC_ALL=C rpmquery -p --requires packages/sisyphus/files/SRPMS/perl-BDB-1.92-alt2.src.rpm |fgrep libdb
libdb4.8-devel  

$ LC_ALL=C rpmquery -p --requires packages/sisyphus/files/x86_64/RPMS/perl-BDB-1.92-alt2.x86_64.rpm|fgrep libdb
libdb-4.7.so()(64bit) >= set:jgqk0ScdIenx2

Кажется, что-то пошло не так.

-- 

Re: [devel] ACL request for perl update to 5.30

[Igor Vlasenko]

On Thu, Dec 05, 2019 at 09:39:09AM +0300, Sergey Bolshakov wrote:
> Говоря о perl:
> 
> $ LC_ALL=C rpmquery -p --lastchange packages/sisyphus/files/SRPMS/perl-BDB-1.92-alt2.src.rpm
> * Tue Dec 03 2019 Igor Vlasenko <viy@altlinux.ru> 1:1.92-alt2
> 
> - migration to libdb4.8
> 
> $ LC_ALL=C rpmquery -p --requires packages/sisyphus/files/SRPMS/perl-BDB-1.92-alt2.src.rpm |fgrep libdb
> libdb4.8-devel  
> 
> $ LC_ALL=C rpmquery -p --requires packages/sisyphus/files/x86_64/RPMS/perl-BDB-1.92-alt2.x86_64.rpm|fgrep libdb
> libdb-4.7.so()(64bit) >= set:jgqk0ScdIenx2
> 
> Кажется, что-то пошло не так.

Все так, это же модули для старого perl 5.28, 
который собран с libdb-4.7.

С libdb4.8 я хочу собрать новый perl 5.30 и модули
к нему, для этого я зарезервировал новый макрос.

После пересборки с новым perl perl-BDB
автоматом будет с libdb4.8, сейчас он с libdb4.7.

-- 

I V

Re: [devel] ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:

 > On Thu, Dec 05, 2019 at 09:39:09AM +0300, Sergey Bolshakov wrote:
 >> Говоря о perl:
 >> 
 >> $ LC_ALL=C rpmquery -p --lastchange packages/sisyphus/files/SRPMS/perl-BDB-1.92-alt2.src.rpm
 >> * Tue Dec 03 2019 Igor Vlasenko <viy@altlinux.ru> 1:1.92-alt2
 >> 
 >> - migration to libdb4.8
 >> 
 >> $ LC_ALL=C rpmquery -p --requires packages/sisyphus/files/SRPMS/perl-BDB-1.92-alt2.src.rpm |fgrep libdb
 >> libdb4.8-devel  
 >> 
 >> $ LC_ALL=C rpmquery -p --requires packages/sisyphus/files/x86_64/RPMS/perl-BDB-1.92-alt2.x86_64.rpm|fgrep libdb
 >> libdb-4.7.so()(64bit) >= set:jgqk0ScdIenx2
 >> 
 >> Кажется, что-то пошло не так.

 > Все так, это же модули для старого perl 5.28, 
 > который собран с libdb-4.7.

 > С libdb4.8 я хочу собрать новый perl 5.30 и модули
 > к нему, для этого я зарезервировал новый макрос.

 > После пересборки с новым perl perl-BDB
 > автоматом будет с libdb4.8, сейчас он с libdb4.7.

Да нет, не так -- cейчас такие src.rpm пересобрать невозможно
из-за конфликтующих сборочных зависимостей.

-- 

Re: [devel] ACL request for perl update to 5.30

[Igor Vlasenko]

On Thu, Dec 05, 2019 at 03:12:05PM +0300, Sergey Bolshakov wrote:
>  > После пересборки с новым perl perl-BDB
>  > автоматом будет с libdb4.8, сейчас он с libdb4.7.
> 
> Да нет, не так -- cейчас такие src.rpm пересобрать невозможно
> из-за конфликтующих сборочных зависимостей.

Где такое поведение наблюдается? на armh?
Проверьте, может быть у вас rpm-build-perl-0.84-alt17,
в то время как в Сизифе rpm-build-perl-0.84-alt18.

-- 

I V

Re: [devel] ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:

 > On Thu, Dec 05, 2019 at 03:12:05PM +0300, Sergey Bolshakov wrote:
 >> > После пересборки с новым perl perl-BDB
 >> > автоматом будет с libdb4.8, сейчас он с libdb4.7.
 >> 
 >> Да нет, не так -- cейчас такие src.rpm пересобрать невозможно
 >> из-за конфликтующих сборочных зависимостей.

 > Где такое поведение наблюдается? на armh?
 > Проверьте, может быть у вас rpm-build-perl-0.84-alt17,
 > в то время как в Сизифе rpm-build-perl-0.84-alt18.

Я ничего не писал про armh, более того, привёл примеры из x86_64.
Давайте я попробую ещё раз, по слогам:
чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
зависимость на libdb4-devel, которая удовлетворяется пакетом
libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
Так яснее ?

-- 

Re: [devel] ACL request for perl update to 5.30

[Igor Vlasenko]

On Thu, Dec 05, 2019 at 04:39:55PM +0300, Sergey Bolshakov wrote:
> Я ничего не писал про armh, более того, привёл примеры из x86_64.
> Давайте я попробую ещё раз, по слогам:
> чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
> perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
> зависимость на libdb4-devel, которая удовлетворяется пакетом
> libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
> Так яснее ?

Сергей,
посмотрите, пожалуйста, исходники.
в perl-BDB.spec (1.92-alt2) 
BuildRequires: %{perl_libdb_pkgname}-devel

что раскрывается в libdb4-devel.

Где вы увидели libdb4.8-devel? в %changelog? 
там да, правильнее написать 
- prepared for migration to libdb4.8.


-- 

I V

Re: [devel] ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:

 > On Thu, Dec 05, 2019 at 04:39:55PM +0300, Sergey Bolshakov wrote:
 >> Я ничего не писал про armh, более того, привёл примеры из x86_64.
 >> Давайте я попробую ещё раз, по слогам:
 >> чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
 >> perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
 >> зависимость на libdb4-devel, которая удовлетворяется пакетом
 >> libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
 >> Так яснее ?

 > Сергей,
 > посмотрите, пожалуйста, исходники.
 > в perl-BDB.spec (1.92-alt2) 
 > BuildRequires: %{perl_libdb_pkgname}-devel

 > что раскрывается в libdb4-devel.

 > Где вы увидели libdb4.8-devel? в %changelog? 
 > там да, правильнее написать 
 > - prepared for migration to libdb4.8.

Что ж, видимо мне придётся ещё раз повторить:
"чтобы собрать perl-BDB-1.92-alt2.src.rpm " и т.д.
src.rpm -- понимаете ? их ещё зачем-то складывают на ftp.a.o,
я слышал, и мне неинтересно заглядывать, что там внутри.

-- 

Re: [devel] ACL request for perl update to 5.30

[Igor Vlasenko]

On Thu, Dec 05, 2019 at 04:58:20PM +0300, Sergey Bolshakov wrote:
> >>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:
> 
>  > On Thu, Dec 05, 2019 at 04:39:55PM +0300, Sergey Bolshakov wrote:
>  >> Я ничего не писал про armh, более того, привёл примеры из x86_64.
>  >> Давайте я попробую ещё раз, по слогам:
>  >> чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
>  >> perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
>  >> зависимость на libdb4-devel, которая удовлетворяется пакетом
>  >> libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
>  >> Так яснее ?
> 
>  > Сергей,
>  > посмотрите, пожалуйста, исходники.
>  > в perl-BDB.spec (1.92-alt2) 
>  > BuildRequires: %{perl_libdb_pkgname}-devel
> 
>  > что раскрывается в libdb4-devel.
> 
>  > Где вы увидели libdb4.8-devel? в %changelog? 
>  > там да, правильнее написать 
>  > - prepared for migration to libdb4.8.
> 
> Что ж, видимо мне придётся ещё раз повторить:
> "чтобы собрать perl-BDB-1.92-alt2.src.rpm " и т.д.
> src.rpm -- понимаете ? их ещё зачем-то складывают на ftp.a.o,

понял, наконец, вас. увидел libdb4.8-devel в
rpmquery --requires -p perl-BDB-1.92-alt2.src.rpm
Это rpmbuild -bs в моей host системе, в которой уже perl 5.30.
Стоит ли из-за этого отдельно устраивать их пересборку,
не дожидаясь perl 5.30?

IMHO, не стоит.
Для сборочницы это не важно, из-за repack.
В домашней машине всегда можно обойтись
rpmbuild -bs --nodeps.

-- 

I V

Re: [devel] ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:

 > On Thu, Dec 05, 2019 at 04:58:20PM +0300, Sergey Bolshakov wrote:
 >> >>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:
 >> 
 >> > On Thu, Dec 05, 2019 at 04:39:55PM +0300, Sergey Bolshakov wrote:
 >> >> Я ничего не писал про armh, более того, привёл примеры из x86_64.
 >> >> Давайте я попробую ещё раз, по слогам:
 >> >> чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
 >> >> perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
 >> >> зависимость на libdb4-devel, которая удовлетворяется пакетом
 >> >> libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
 >> >> Так яснее ?
 >> 
 >> > Сергей,
 >> > посмотрите, пожалуйста, исходники.
 >> > в perl-BDB.spec (1.92-alt2) 
 >> > BuildRequires: %{perl_libdb_pkgname}-devel
 >> 
 >> > что раскрывается в libdb4-devel.
 >> 
 >> > Где вы увидели libdb4.8-devel? в %changelog? 
 >> > там да, правильнее написать 
 >> > - prepared for migration to libdb4.8.
 >> 
 >> Что ж, видимо мне придётся ещё раз повторить:
 >> "чтобы собрать perl-BDB-1.92-alt2.src.rpm " и т.д.
 >> src.rpm -- понимаете ? их ещё зачем-то складывают на ftp.a.o,

 > понял, наконец, вас. увидел libdb4.8-devel в
 > rpmquery --requires -p perl-BDB-1.92-alt2.src.rpm
 > Это rpmbuild -bs в моей host системе, в которой уже perl 5.30.
 > Стоит ли из-за этого отдельно устраивать их пересборку,
 > не дожидаясь perl 5.30?

 > IMHO, не стоит.
 > Для сборочницы это не важно, из-за repack.
 > В домашней машине всегда можно обойтись
 > rpmbuild -bs --nodeps.

Есть и другое мнение, которое сводится примерно к тому, что
опубликованное на ftp.a.o было бы хорошо содержать в виде, пригодном
для простого hsh path/to/src.rpm
Иными словами, трюкачество, подобное устроенному в ряде perl-пакетов,
предсказуемо ломает пересборку из src.rpm и я не вижу веских
причин его терпеть.

-- 

[devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Ivan Zakharyaschev]

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

On Thu, 5 Dec 2019, Sergey Bolshakov wrote:

> >>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:
> 
>  > On Thu, Dec 05, 2019 at 04:58:20PM +0300, Sergey Bolshakov wrote:
>  >> >>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:
>  >> 
>  >> > On Thu, Dec 05, 2019 at 04:39:55PM +0300, Sergey Bolshakov wrote:
>  >> >> Я ничего не писал про armh, более того, привёл примеры из x86_64.
>  >> >> Давайте я попробую ещё раз, по слогам:
>  >> >> чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
>  >> >> perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
>  >> >> зависимость на libdb4-devel, которая удовлетворяется пакетом
>  >> >> libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
>  >> >> Так яснее ?
>  >> 
>  >> > Сергей,
>  >> > посмотрите, пожалуйста, исходники.
>  >> > в perl-BDB.spec (1.92-alt2) 
>  >> > BuildRequires: %{perl_libdb_pkgname}-devel
>  >> 
>  >> > что раскрывается в libdb4-devel.
>  >> 
>  >> > Где вы увидели libdb4.8-devel? в %changelog? 
>  >> > там да, правильнее написать 
>  >> > - prepared for migration to libdb4.8.
>  >> 
>  >> Что ж, видимо мне придётся ещё раз повторить:
>  >> "чтобы собрать perl-BDB-1.92-alt2.src.rpm " и т.д.
>  >> src.rpm -- понимаете ? их ещё зачем-то складывают на ftp.a.o,
> 
>  > понял, наконец, вас. увидел libdb4.8-devel в
>  > rpmquery --requires -p perl-BDB-1.92-alt2.src.rpm
>  > Это rpmbuild -bs в моей host системе, в которой уже perl 5.30.
>  > Стоит ли из-за этого отдельно устраивать их пересборку,
>  > не дожидаясь perl 5.30?
> 
>  > IMHO, не стоит.
>  > Для сборочницы это не важно, из-за repack.
>  > В домашней машине всегда можно обойтись
>  > rpmbuild -bs --nodeps.
> 
> Есть и другое мнение, которое сводится примерно к тому, что
> опубликованное на ftp.a.o было бы хорошо содержать в виде, пригодном
> для простого hsh path/to/src.rpm

Мнение, конечно, разумное. Но можно предлагать использовать просто:

hsh --query-repackage path/to/src.rpm

Можно считать это способом по умолчанию. (Более вычислительно нагруженный, 
зато так, как теперь в girar по умолчанию.)

> Иными словами, трюкачество, подобное устроенному в ряде perl-пакетов,
> предсказуемо ломает пересборку из src.rpm и я не вижу веских
> причин его терпеть.


-- 
Best regards,
Ivan

Re: [devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Ivan" == Ivan Zakharyaschev <imz-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
[skipped]
 
 >> Есть и другое мнение, которое сводится примерно к тому, что
 >> опубликованное на ftp.a.o было бы хорошо содержать в виде, пригодном
 >> для простого hsh path/to/src.rpm

 > Мнение, конечно, разумное. Но можно предлагать использовать просто:

 > hsh --query-repackage path/to/src.rpm
 > Можно считать это способом по умолчанию. (Более вычислительно нагруженный, 
 > зато так, как теперь в girar по умолчанию.)

Дело не в ключах вызова hsh, по большому счёту.
Сейчас в опубликованных src.rpm написано: собрано быть не может, simple as.
Впору спросить себя -- зачем мы их вообще выкладываем.

 >> Иными словами, трюкачество, подобное устроенному в ряде perl-пакетов,
 >> предсказуемо ломает пересборку из src.rpm и я не вижу веских
 >> причин его терпеть.

-- 

Re: [devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Michael Shigorin]

On Thu, Dec 05, 2019 at 05:57:17PM +0300, Sergey Bolshakov wrote:
>  > hsh --query-repackage path/to/src.rpm
> Дело не в ключах вызова hsh, по большому счёту.

В них самых.  Похоже, это изменение сперва у меня,
а затем на первичной сборочнице -- просто-напросто
забыли озвучить всем, кого оно могло затрагивать.

За подробностями лучше к ldv@.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Michael" == Michael Shigorin <mike-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > On Thu, Dec 05, 2019 at 05:57:17PM +0300, Sergey Bolshakov wrote:
 >> > hsh --query-repackage path/to/src.rpm
 >> Дело не в ключах вызова hsh, по большому счёту.

 > В них самых.  Похоже, это изменение сперва у меня,
 > а затем на первичной сборочнице -- просто-напросто
 > забыли озвучить всем, кого оно могло затрагивать.

 > За подробностями лучше к ldv@.

Миша, мне кажется, ты снова упускаешь шанс высказаться
по теме, в которой ориентируешься сам, без переадресаций --
поэтому прошу, без стеснений -- какие ключи hsh мне следует
применить, чтобы из сизифного perl-BDB-1.92-alt2.src.rpm
получить сизифный же perl-BDB-1.92-alt2.x86_64.rpm
с точностью до зависимостей ?

-- 

Re: [devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Michael Shigorin]

On Thu, Dec 05, 2019 at 06:20:09PM +0300, Sergey Bolshakov wrote:
>  >> > hsh --query-repackage path/to/src.rpm
>  >> Дело не в ключах вызова hsh, по большому счёту.
>  > В них самых.
> Миша, мне кажется, ты снова упускаешь шанс высказаться
> по теме, в которой ориентируешься сам, без переадресаций --

У меня оно вымучено и "ушло в архив" не позже прошлого года...

> поэтому прошу, без стеснений -- какие ключи hsh мне следует
> применить, чтобы из сизифного perl-BDB-1.92-alt2.src.rpm
> получить сизифный же perl-BDB-1.92-alt2.x86_64.rpm
> с точностью до зависимостей ?

Не проверял именно на этом примере, но наблюдаю локально:
--repackage-source --query-repackage

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Anton Farygin]

On 05.12.2019 18:34, Michael Shigorin wrote:
>> поэтому прошу, без стеснений -- какие ключи hsh мне следует
>> применить, чтобы из сизифного perl-BDB-1.92-alt2.src.rpm
>> получить сизифный же perl-BDB-1.92-alt2.x86_64.rpm
>> с точностью до зависимостей ?
> Не проверял именно на этом примере, но наблюдаю локально:
> --repackage-source --query-repackage

желающие могут проверить и сравнить зависимости у x86_64 пакета из 
сизифа и у того, что получилось в результате.

В общем это проблема будет решена, как только у нас появится armv7 
сборочница. А пока архитектура догоняющая, то так и будут странности.

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

Re: [devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Igor Vlasenko]

On Thu, Dec 05, 2019 at 06:44:19PM +0300, Anton Farygin wrote:
> В общем это проблема будет решена, как только у нас появится armv7
> сборочница. А пока архитектура догоняющая, то так и будут странности.

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

Гм. это не баг, а фича rpm.
в спеке в BR: используются макросы, 
а в src.rpm в BR: записывается раскрытие макроса в контексте конкретного значения этих макросов.
никуда не деться от такого факта, что со временем эти значения разойдутся.
Главное, чтобы сборочница делала --query-repackage,
чтобы использовать не старые, а актуальные значения макросов.

Это же касается и других тегов, ExclusiveArch: %{arches_with_bla}, к примеру.

-- 

I V

Re: [devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:

 > On Thu, Dec 05, 2019 at 06:44:19PM +0300, Anton Farygin wrote:
 >> В общем это проблема будет решена, как только у нас появится armv7
 >> сборочница. А пока архитектура догоняющая, то так и будут странности.

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

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

 > Гм. это не баг, а фича rpm.
 > в спеке в BR: используются макросы, 
 > а в src.rpm в BR: записывается раскрытие макроса в контексте конкретного значения этих макросов.
 > никуда не деться от такого факта, что со временем эти значения разойдутся.

В обсуждаемом случае это некоторое время составляло минуты до окончания
сборки задания.

 > Главное, чтобы сборочница делала --query-repackage,
 > чтобы использовать не старые, а актуальные значения макросов.
 > Это же касается и других тегов, ExclusiveArch: %{arches_with_bla}, к примеру.

Рационализировать можно сколько угодно, но факт состоит в том,
что не нужно никакой сборочницы -- достаточно rpmquery на несколько
пакетов, чтобы убедиться в том, что бинарные rpm существенно не
соответствуют исходным.

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

-- 

Re: [devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Ivan Zakharyaschev]

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

On Thu, 5 Dec 2019, Sergey Bolshakov wrote:

> >>>>> "Michael" == Michael Shigorin <mike-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
> 
>  > On Thu, Dec 05, 2019 at 05:57:17PM +0300, Sergey Bolshakov wrote:
>  >> > hsh --query-repackage path/to/src.rpm
>  >> Дело не в ключах вызова hsh, по большому счёту.
> 
>  > В них самых.  Похоже, это изменение сперва у меня,
>  > а затем на первичной сборочнице -- просто-напросто
>  > забыли озвучить всем, кого оно могло затрагивать.
> 
>  > За подробностями лучше к ldv@.
> 
> Миша, мне кажется, ты снова упускаешь шанс высказаться
> по теме, в которой ориентируешься сам, без переадресаций --
> поэтому прошу, без стеснений -- какие ключи hsh мне следует
> применить, чтобы из сизифного perl-BDB-1.92-alt2.src.rpm
> получить сизифный же perl-BDB-1.92-alt2.x86_64.rpm
> с точностью до зависимостей ?

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

-- 
Best regards,
Ivan

Re: [devel] hsh --query-repackage Re: ACL request for perl update to 5.30

[Dmitry V. Levin]

On Thu, Dec 05, 2019 at 05:57:17PM +0300, Sergey Bolshakov wrote:
> >>>>> "Ivan" == Ivan Zakharyaschev <imz-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
> [skipped]
>  
>  >> Есть и другое мнение, которое сводится примерно к тому, что
>  >> опубликованное на ftp.a.o было бы хорошо содержать в виде, пригодном
>  >> для простого hsh path/to/src.rpm
> 
>  > Мнение, конечно, разумное. Но можно предлагать использовать просто:
> 
>  > hsh --query-repackage path/to/src.rpm
>  > Можно считать это способом по умолчанию. (Более вычислительно нагруженный, 
>  > зато так, как теперь в girar по умолчанию.)
> 
> Дело не в ключах вызова hsh, по большому счёту.
> Сейчас в опубликованных src.rpm написано: собрано быть не может, simple as.
> Впору спросить себя -- зачем мы их вообще выкладываем.

Хороший вопрос.  Вероятно, для тестовой пересборки, она их использует.

Кстати, в сборочнице используется hsh-rebuild --query-repackage.
Иначе бы тот пакет, о котором идёт речь, даже не собрался бы.


-- 
ldv

[devel] detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30

[Ivan Zakharyaschev]

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

On Thu, 5 Dec 2019, Dmitry V. Levin wrote:

> On Thu, Dec 05, 2019 at 05:57:17PM +0300, Sergey Bolshakov wrote:
> > >>>>> "Ivan" == Ivan Zakharyaschev <imz-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
> > [skipped]
> >  
> >  >> Есть и другое мнение, которое сводится примерно к тому, что
> >  >> опубликованное на ftp.a.o было бы хорошо содержать в виде, пригодном
> >  >> для простого hsh path/to/src.rpm
> > 
> >  > Мнение, конечно, разумное. Но можно предлагать использовать просто:
> > 
> >  > hsh --query-repackage path/to/src.rpm
> >  > Можно считать это способом по умолчанию. (Более вычислительно нагруженный, 
> >  > зато так, как теперь в girar по умолчанию.)
> > 
> > Дело не в ключах вызова hsh, по большому счёту.
> > Сейчас в опубликованных src.rpm написано: собрано быть не может, simple as.
> > Впору спросить себя -- зачем мы их вообще выкладываем.
> 
> Хороший вопрос.  Вероятно, для тестовой пересборки, она их использует.
> 
> Кстати, в сборочнице используется hsh-rebuild --query-repackage.
> Иначе бы тот пакет, о котором идёт речь, даже не собрался бы.

Как тут в этом обсуждении говорили, как я понял, при пересборке этого 
пакета в нынешней среде Sisyphus получается какой-то не очень разумный 
результат. (Поправьте, если я неправильно понял.) Т.е. претензия даже не в 
том, что результат другой, но и что плохой. Стал плохим после того, как 
значение макроса изменилось.

И вообще, это, конечно, не очень хорошая ситуация (даже если результат 
другой, а не плохой). Потому что получается что на текущем состоянии 
репозитория мы не можем (не важно с какой опцией hsh) воспроизвести сборку 
некоторых пакетов, которые там лежат. Т.е. например, в дистрибутив попали 
они в старом виде, а если нас просят для сертификации воспроизвести сборку 
и доказать, что получается такой результат, это сделать не получается.

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

(Я такие механизмы уже некоторое время назад обдумывал.)

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

-- 
Best regards,
Ivan

Re: [devel] detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30

[Anton Farygin]

On 05.12.2019 23:10, Ivan Zakharyaschev wrote:
> Можно было бы добавить механизм автоматического отслеживания значений
> макросов, использованных при сборке пакета, так чтобы в случае изменения
> значения возникало нечто аналогичное unmets сейчас. Т.е. пакет, меняющий
> значение макроса, использованного для сборки других пакетов, нельзя
> закоммитить, не пересобрав все пакеты, на которые он может повлиять.

Зачем отслеживать макросы, если у нас уже отслеживаются результаты 
пересборок ? Достаточно сравнение пакетов сделать из предупреждения ошибкой.

Re: [devel] detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30

[Ivan Zakharyaschev]

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


On Thu, 5 Dec 2019, Anton Farygin wrote:

> On 05.12.2019 23:10, Ivan Zakharyaschev wrote:
> > Можно было бы добавить механизм автоматического отслеживания значений
> > макросов, использованных при сборке пакета, так чтобы в случае изменения
> > значения возникало нечто аналогичное unmets сейчас. Т.е. пакет, меняющий
> > значение макроса, использованного для сборки других пакетов, нельзя
> > закоммитить, не пересобрав все пакеты, на которые он может повлиять.
> 
> Зачем отслеживать макросы, если у нас уже отслеживаются результаты пересборок
> ? Достаточно сравнение пакетов сделать из предупреждения ошибкой.

Это тоже ценный источник информации, согласен.

Но в текущей ситуации есть такое но:

Сравнение пакетов делается в beehive, асинхронно после того, как 
"виновник" с другим значением макроса уже попал в репозиторий.

Сделать это ошибкой, которая бы помешала заданию успешно завершится, не 
получится.

А довольно дёшево можно сравнить значения макросов и бустро зарубить 
задание. Примерно так же быстро, как сейчас обнаруживаются unmets. (Но 
может быть довольно много сообщений об изменениях, которые реально не 
отражаются на результате сборки. Трудно заранее оценить, много ли будет 
таких не очень удобных "ложных" срабатываний.)

-- 
Best regards,
Ivan

Re: [devel] detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30

[Anton Farygin]

On 05.12.2019 23:23, Ivan Zakharyaschev wrote:
> On Thu, 5 Dec 2019, Anton Farygin wrote:
>
>> On 05.12.2019 23:10, Ivan Zakharyaschev wrote:
>>> Можно было бы добавить механизм автоматического отслеживания значений
>>> макросов, использованных при сборке пакета, так чтобы в случае изменения
>>> значения возникало нечто аналогичное unmets сейчас. Т.е. пакет, меняющий
>>> значение макроса, использованного для сборки других пакетов, нельзя
>>> закоммитить, не пересобрав все пакеты, на которые он может повлиять.
>> Зачем отслеживать макросы, если у нас уже отслеживаются результаты пересборок
>> ? Достаточно сравнение пакетов сделать из предупреждения ошибкой.
> Это тоже ценный источник информации, согласен.
>
> Но в текущей ситуации есть такое но:
>
> Сравнение пакетов делается в beehive, асинхронно после того, как
> "виновник" с другим значением макроса уже попал в репозиторий.
>
> Сделать это ошибкой, которая бы помешала заданию успешно завершится, не
> получится.
>
> А довольно дёшево можно сравнить значения макросов и бустро зарубить
> задание. Примерно так же быстро, как сейчас обнаруживаются unmets. (Но
> может быть довольно много сообщений об изменениях, которые реально не
> отражаются на результате сборки. Трудно заранее оценить, много ли будет
> таких не очень удобных "ложных" срабатываний.)

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

Re: [devel] detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30

[Ivan Zakharyaschev]

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

On Thu, 5 Dec 2019, Anton Farygin wrote:

> On 05.12.2019 23:23, Ivan Zakharyaschev wrote:
> > On Thu, 5 Dec 2019, Anton Farygin wrote:
> >
> > > On 05.12.2019 23:10, Ivan Zakharyaschev wrote:
> > > > Можно было бы добавить механизм автоматического отслеживания значений
> > > > макросов, использованных при сборке пакета, так чтобы в случае изменения
> > > > значения возникало нечто аналогичное unmets сейчас. Т.е. пакет, меняющий
> > > > значение макроса, использованного для сборки других пакетов, нельзя
> > > > закоммитить, не пересобрав все пакеты, на которые он может повлиять.
> > > Зачем отслеживать макросы, если у нас уже отслеживаются результаты
> > > пересборок
> > > ? Достаточно сравнение пакетов сделать из предупреждения ошибкой.
> > Это тоже ценный источник информации, согласен.
> >
> > Но в текущей ситуации есть такое но:
> >
> > Сравнение пакетов делается в beehive, асинхронно после того, как
> > "виновник" с другим значением макроса уже попал в репозиторий.
> >
> > Сделать это ошибкой, которая бы помешала заданию успешно завершится, не
> > получится.
> >
> > А довольно дёшево можно сравнить значения макросов и бустро зарубить
> > задание. Примерно так же быстро, как сейчас обнаруживаются unmets. (Но
> > может быть довольно много сообщений об изменениях, которые реально не
> > отражаются на результате сборки. Трудно заранее оценить, много ли будет
> > таких не очень удобных "ложных" срабатываний.)
> 
> Можно придумать сотни способов слома чужих пакетов без использования макросов.
> Макросы это не показатель.

В целом я согласен.

Думал о них в первую, как о ключевых рычагах влияния на другие пакеты.

Например, повлиять на получившийся srpm можно главным образом через 
макросы. (Остальные инструменты влияют на бинарные пакеты.)

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

-- 
Best regards,
Ivan

Re: [devel] detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30

[Dmitry V. Levin]

On Thu, Dec 05, 2019 at 11:10:02PM +0300, Ivan Zakharyaschev wrote:
> On Thu, 5 Dec 2019, Dmitry V. Levin wrote:
> 
> > On Thu, Dec 05, 2019 at 05:57:17PM +0300, Sergey Bolshakov wrote:
> > > >>>>> "Ivan" == Ivan Zakharyaschev <imz-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
> > > [skipped]
> > >  
> > >  >> Есть и другое мнение, которое сводится примерно к тому, что
> > >  >> опубликованное на ftp.a.o было бы хорошо содержать в виде, пригодном
> > >  >> для простого hsh path/to/src.rpm
> > > 
> > >  > Мнение, конечно, разумное. Но можно предлагать использовать просто:
> > > 
> > >  > hsh --query-repackage path/to/src.rpm
> > >  > Можно считать это способом по умолчанию. (Более вычислительно нагруженный, 
> > >  > зато так, как теперь в girar по умолчанию.)
> > > 
> > > Дело не в ключах вызова hsh, по большому счёту.
> > > Сейчас в опубликованных src.rpm написано: собрано быть не может, simple as.
> > > Впору спросить себя -- зачем мы их вообще выкладываем.
> > 
> > Хороший вопрос.  Вероятно, для тестовой пересборки, она их использует.
> > 
> > Кстати, в сборочнице используется hsh-rebuild --query-repackage.
> > Иначе бы тот пакет, о котором идёт речь, даже не собрался бы.
> 
> Как тут в этом обсуждении говорили, как я понял, при пересборке этого 
> пакета в нынешней среде Sisyphus получается какой-то не очень разумный 
> результат. (Поправьте, если я неправильно понял.) Т.е. претензия даже не в 
> том, что результат другой, но и что плохой. Стал плохим после того, как 
> значение макроса изменилось.

Я понял это обсуждение совершенно иначе.

> И вообще, это, конечно, не очень хорошая ситуация (даже если результат 
> другой, а не плохой). Потому что получается что на текущем состоянии 
> репозитория мы не можем (не важно с какой опцией hsh) воспроизвести сборку 
> некоторых пакетов, которые там лежат. Т.е. например, в дистрибутив попали 
> они в старом виде, а если нас просят для сертификации воспроизвести сборку 
> и доказать, что получается такой результат, это сделать не получается.

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

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

Изменение макросов - частный случай существенного изменения сборочной
среды.


-- 
ldv

[devel] Воспроизводимая сборка пакетов (Was: detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30)

[Vladimir D. Seleznev]

On Thu, Dec 05, 2019 at 11:10:02PM +0300, Ivan Zakharyaschev wrote:
> On Thu, 5 Dec 2019, Dmitry V. Levin wrote:
> 
> > On Thu, Dec 05, 2019 at 05:57:17PM +0300, Sergey Bolshakov wrote:
> > > >>>>> "Ivan" == Ivan Zakharyaschev <imz-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
> > > [skipped]
> > >  
> > >  >> Есть и другое мнение, которое сводится примерно к тому, что
> > >  >> опубликованное на ftp.a.o было бы хорошо содержать в виде, пригодном
> > >  >> для простого hsh path/to/src.rpm
> > > 
> > >  > Мнение, конечно, разумное. Но можно предлагать использовать просто:
> > > 
> > >  > hsh --query-repackage path/to/src.rpm
> > >  > Можно считать это способом по умолчанию. (Более вычислительно нагруженный, 
> > >  > зато так, как теперь в girar по умолчанию.)
> > > 
> > > Дело не в ключах вызова hsh, по большому счёту.
> > > Сейчас в опубликованных src.rpm написано: собрано быть не может, simple as.
> > > Впору спросить себя -- зачем мы их вообще выкладываем.
> > 
> > Хороший вопрос.  Вероятно, для тестовой пересборки, она их использует.
> > 
> > Кстати, в сборочнице используется hsh-rebuild --query-repackage.
> > Иначе бы тот пакет, о котором идёт речь, даже не собрался бы.
> 
> Как тут в этом обсуждении говорили, как я понял, при пересборке этого 
> пакета в нынешней среде Sisyphus получается какой-то не очень разумный 
> результат. (Поправьте, если я неправильно понял.) Т.е. претензия даже не в 
> том, что результат другой, но и что плохой. Стал плохим после того, как 
> значение макроса изменилось.
> 
> И вообще, это, конечно, не очень хорошая ситуация (даже если результат 
> другой, а не плохой). Потому что получается что на текущем состоянии 
> репозитория мы не можем (не важно с какой опцией hsh) воспроизвести сборку 
> некоторых пакетов, которые там лежат. Т.е. например, в дистрибутив попали 
> они в старом виде, а если нас просят для сертификации воспроизвести сборку 
> и доказать, что получается такой результат, это сделать не получается.

О воспроизводимости сборки имеет смысл говорить только в том же
сборочном окружении, в котором собирался пакет. Т.к. мы журналируем
метаинформацию о сборочных заданиях в индексах исходных пакетов [1], из
которых мы можем вытащить информацию о том, в какой сборочном окружении
мы собирали пакет, и мы сохраняем состояния репозиториев для всех
собранных тасков [2], то мы можем легко воспроизвести сборочное
окружение и воспроизвести сборку. Другое дело, что сейчас не для всех
пакетов сборочный результат получается идентичным. У меня пока нет
статистики, но я думаю, что не вредно будет собирать такую статистику.
Т.е., организовать регулярную ассинхронную проверку, что результат
пересборки пакета в том же сборочном окружении, при котором он попал в
репозиторий, совпадает с тем, что лежит в репозитории.

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

Про воспроизводимость сборки можно почитать тут [3].

> Можно было бы добавить механизм автоматического отслеживания значений 
> макросов, использованных при сборке пакета, так чтобы в случае изменения 
> значения возникало нечто аналогичное unmets сейчас. Т.е. пакет, меняющий 
> значение макроса, использованного для сборки других пакетов, нельзя 
> закоммитить, не пересобрав все пакеты, на которые он может повлиять.
> 
> (Я такие механизмы уже некоторое время назад обдумывал.)
> 
> С одной стороны, больше труда при сборке пакетов с макросами, с другой 
> стороны, мы приобретаем лучшую готовность к пересборке пакетов на текущем 
> состоянии репозитория (по тем или иным причнам: пресборка ради 
> сертификации; пересборка с патчем -- плохо, если неожиданно сборка с 
> патчем начнёт приводить совсем не к тому виду пакета, к которому 
> привыкли).

Ссылки:
[1] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/
[2] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/task/archive/
[3] https://reproducible-builds.org/

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] Воспроизводимая сборка пакетов (Was: detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30)

[Ivan Zakharyaschev]

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

On Fri, 6 Dec 2019, Vladimir D. Seleznev wrote:

> On Thu, Dec 05, 2019 at 11:10:02PM +0300, Ivan Zakharyaschev wrote:
> > On Thu, 5 Dec 2019, Dmitry V. Levin wrote:
> > 
> > > On Thu, Dec 05, 2019 at 05:57:17PM +0300, Sergey Bolshakov wrote:
> > > > >>>>> "Ivan" == Ivan Zakharyaschev <imz-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
> > > > [skipped]
> > > >  
> > > >  >> Есть и другое мнение, которое сводится примерно к тому, что
> > > >  >> опубликованное на ftp.a.o было бы хорошо содержать в виде, пригодном
> > > >  >> для простого hsh path/to/src.rpm
> > > > 
> > > >  > Мнение, конечно, разумное. Но можно предлагать использовать просто:
> > > > 
> > > >  > hsh --query-repackage path/to/src.rpm
> > > >  > Можно считать это способом по умолчанию. (Более вычислительно нагруженный, 
> > > >  > зато так, как теперь в girar по умолчанию.)
> > > > 
> > > > Дело не в ключах вызова hsh, по большому счёту.
> > > > Сейчас в опубликованных src.rpm написано: собрано быть не может, simple as.
> > > > Впору спросить себя -- зачем мы их вообще выкладываем.
> > > 
> > > Хороший вопрос.  Вероятно, для тестовой пересборки, она их использует.
> > > 
> > > Кстати, в сборочнице используется hsh-rebuild --query-repackage.
> > > Иначе бы тот пакет, о котором идёт речь, даже не собрался бы.
> > 
> > Как тут в этом обсуждении говорили, как я понял, при пересборке этого 
> > пакета в нынешней среде Sisyphus получается какой-то не очень разумный 
> > результат. (Поправьте, если я неправильно понял.) Т.е. претензия даже не в 
> > том, что результат другой, но и что плохой. Стал плохим после того, как 
> > значение макроса изменилось.
> > 
> > И вообще, это, конечно, не очень хорошая ситуация (даже если результат 
> > другой, а не плохой). Потому что получается что на текущем состоянии 
> > репозитория мы не можем (не важно с какой опцией hsh) воспроизвести сборку 
> > некоторых пакетов, которые там лежат. Т.е. например, в дистрибутив попали 
> > они в старом виде, а если нас просят для сертификации воспроизвести сборку 
> > и доказать, что получается такой результат, это сделать не получается.
> 
> О воспроизводимости сборки имеет смысл говорить только в том же
> сборочном окружении, в котором собирался пакет. Т.к. мы журналируем

Да, я говорил о воспроизводимости в другом смысле. Можно так сказать: 
актуальны ли сохранённые в репозитории пакеты или при их пересборке в 
текущем репозитории получится другой результат. (Если другой, то это может 
противоречить задумке авторов изменения макросов и других сборочных 
инструментов: они считают, что правильнее делать по-новому.) Говорю о 
помощи в улучшении текущего репозитория и всех пакетов, а не о раскопках с 
целью убедить, что в истории пакета нет обмана.

> Что касается сертифицикации, то, возможно, самым простым решением будет
> сразу после бранчевания делать пересборку всех тех пакетов, что пойдут
> на сертификацию, и после этого доказать (статистически)
> воспроизводимость уже этой сборки.
> 
> Про воспроизводимость сборки можно почитать тут [3].
> 
> > Можно было бы добавить механизм автоматического отслеживания значений 
> > макросов, использованных при сборке пакета, так чтобы в случае изменения 
> > значения возникало нечто аналогичное unmets сейчас. Т.е. пакет, меняющий 
> > значение макроса, использованного для сборки других пакетов, нельзя 
> > закоммитить, не пересобрав все пакеты, на которые он может повлиять.
> > 
> > (Я такие механизмы уже некоторое время назад обдумывал.)
> > 
> > С одной стороны, больше труда при сборке пакетов с макросами, с другой 
> > стороны, мы приобретаем лучшую готовность к пересборке пакетов на текущем 
> > состоянии репозитория (по тем или иным причнам: пресборка ради 
> > сертификации; пересборка с патчем -- плохо, если неожиданно сборка с 
> > патчем начнёт приводить совсем не к тому виду пакета, к которому 
> > привыкли).
> 
> Ссылки:
> [1] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/
> [2] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/task/archive/
> [3] https://reproducible-builds.org/
> 
> -- 
>    С уважением,
>    Владимир Селезнев
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] (Полу)Автоматическая Пересборка пакетов

[Anton Farygin]

On 06.12.2019 23:45, Ivan Zakharyaschev wrote:
> Да, я говорил о воспроизводимости в другом смысле. Можно так сказать:
> актуальны ли сохранённые в репозитории пакеты или при их пересборке в
> текущем репозитории получится другой результат. (Если другой, то это может
> противоречить задумке авторов изменения макросов и других сборочных
> инструментов: они считают, что правильнее делать по-новому.) Говорю о
> помощи в улучшении текущего репозитория и всех пакетов, а не о раскопках с
> целью убедить, что в истории пакета нет обмана.

Основная проблема в том, что после пересборки в новом окружении может 
получится неработающий пакет.

В этом плане нам помогло бы (в какой-то степени) включение секции %check 
во всех пакетах, если это предусмотрено апстримом.

Но - на нашей x86 сборочнице нет, например, ipv6 и некоторые тесты не 
получается выполнить.

Re: [devel] ACL request for perl update to 5.30

[Sergey V Turchin]

On Thursday, 5 December 2019 16:39:55 MSK Sergey Bolshakov wrote:

[...]
> чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
> perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
> зависимость на libdb4-devel, которая удовлетворяется пакетом
> libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
В perl-BDB.spec наверняка достаточно будет поменять местами perl-devel и 
libdb4.8-devel в BuildRequires.
Чтоб сперва шёл libdb4.8-devel.

[...]

-- 
Regards, Sergey.

Re: [devel] ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Sergey" == Sergey V Turchin <zerg-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > On Thursday, 5 December 2019 16:39:55 MSK Sergey Bolshakov wrote:
 > [...]
 >> чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
 >> perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
 >> зависимость на libdb4-devel, которая удовлетворяется пакетом
 >> libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
 > В perl-BDB.spec наверняка достаточно будет поменять местами perl-devel и 
 > libdb4.8-devel в BuildRequires.
 > Чтоб сперва шёл libdb4.8-devel.
 
libdb4.8-devel не предоставляет libdb4-devel, во всяком случае пока.

-- 

Re: [devel] ACL request for perl update to 5.30

[Sergey V Turchin]

On Thursday, 5 December 2019 17:12:25 MSK Sergey Bolshakov wrote:

[...]
>  > В perl-BDB.spec наверняка достаточно будет поменять местами perl-devel и
>  > libdb4.8-devel в BuildRequires.
>  > Чтоб сперва шёл libdb4.8-devel.
> libdb4.8-devel не предоставляет libdb4-devel, во всяком случае пока.
Ааа. Видимо, или perl-BDB не прав и должен тащить то же, что и perl-devel или 
perl-devel не должен зависеть от libdb*-devel вообще.

-- 
Regards, Sergey.

Re: [devel] ACL request for perl update to 5.30

[Igor Vlasenko]

On Thu, Dec 05, 2019 at 05:10:17PM +0300, Sergey V Turchin wrote:
> On Thursday, 5 December 2019 16:39:55 MSK Sergey Bolshakov wrote:
> 
> [...]
> > чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
> > perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
> > зависимость на libdb4-devel, которая удовлетворяется пакетом
> > libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
> В perl-BDB.spec наверняка достаточно будет поменять местами perl-devel и 
> libdb4.8-devel в BuildRequires.
> Чтоб сперва шёл libdb4.8-devel.

Там в спеке нет libdb4.8-devel, поэтому я и не понял, что
Сергей Большаков хотел сказать.

Это такой artifact в BR src.rpm
от rpmbuild -bs в host-системе с perl-devel 5.30 -
на сборочницу не влияет, так как в сборочнице srpm переупаковывается
в текущее актуальное состояние.

-- 

I V

Re: [devel] ACL request for perl update to 5.30

[Sergey Bolshakov]

>>>>> "Igor" == Igor Vlasenko <vlasenko-mwWcnE6MXDzNsqkvetdkXg@public.gmane.org> writes:

 > On Thu, Dec 05, 2019 at 05:10:17PM +0300, Sergey V Turchin wrote:
 >> On Thursday, 5 December 2019 16:39:55 MSK Sergey Bolshakov wrote:
 >> 
 >> [...]
 >> > чтобы собрать perl-BDB-1.92-alt2.src.rpm, нужны, в числе прочего,
 >> > perl-devel и libdb4.8-devel, первый из них содержит, в свою очередь,
 >> > зависимость на libdb4-devel, которая удовлетворяется пакетом
 >> > libdb4.7-devel, а тот конфликтует с libdb4.8-devel => тупик.
 >> В perl-BDB.spec наверняка достаточно будет поменять местами perl-devel и 
 >> libdb4.8-devel в BuildRequires.
 >> Чтоб сперва шёл libdb4.8-devel.

 > Там в спеке нет libdb4.8-devel, поэтому я и не понял, что
 > Сергей Большаков хотел сказать.

 > Это такой artifact в BR src.rpm
 > от rpmbuild -bs в host-системе с perl-devel 5.30 -
 > на сборочницу не влияет, так как в сборочнице srpm переупаковывается
 > в текущее актуальное состояние.

Нет, это не артефакт в BR src.rpm от rpmbuild -bs в host-системе (чьей?)
с perl-devel 5.30, это положение дел в актуальном сизифе -- все примеры
с src.rpm оттуда, и в таком состоянии оказался отнюдь не только perl-BDB.
Призываю вас вернуть такие пакеты в собираемое состояние ASAP.

-- 

Re: [devel] ACL request for perl update to 5.30

[Sergey Afonin]

On Thursday 05 December 2019, Sergey Bolshakov wrote:

> Нет, это не артефакт в BR src.rpm от rpmbuild -bs в host-системе (чьей?)
> с perl-devel 5.30, это положение дел в актуальном сизифе -- все примеры
> с src.rpm оттуда, и в таком состоянии оказался отнюдь не только perl-BDB.
> Призываю вас вернуть такие пакеты в собираемое состояние ASAP.
 
То есть получается, что в репозиторий попадает тот srpm, который залит
в сборочницу, а не тот, который получился после пересборки?

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

Re: [devel] ACL request for perl update to 5.30

[Dmitry V. Levin]

On Fri, Dec 06, 2019 at 09:27:38AM +0400, Sergey Afonin wrote:
> On Thursday 05 December 2019, Sergey Bolshakov wrote:
> 
> > Нет, это не артефакт в BR src.rpm от rpmbuild -bs в host-системе (чьей?)
> > с perl-devel 5.30, это положение дел в актуальном сизифе -- все примеры
> > с src.rpm оттуда, и в таком состоянии оказался отнюдь не только perl-BDB.
> > Призываю вас вернуть такие пакеты в собираемое состояние ASAP.
>  
> То есть получается, что в репозиторий попадает тот srpm, который залит
> в сборочницу, а не тот, который получился после пересборки?

Да, в репозиторий попадает srpm, подписанный автором.


-- 
ldv