Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Alexei Takaseev]

Добрый день!

----- Исходное сообщение -----
> От: "ALT beekeeper" <hiver@altlinux.org>
> Кому: sisyphus-cybertalk@lists.altlinux.org
> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58
> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

В Сизифе что-то большое рвануло?

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Anton Farygin]

02.02.2018 04:39, Alexei Takaseev пишет:
> Добрый день!
>
> ----- Исходное сообщение -----
>> От: "ALT beekeeper" <hiver@altlinux.org>
>> Кому: sisyphus-cybertalk@lists.altlinux.org
>> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58
>> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)
> В Сизифе что-то большое рвануло?
Когда-то давным давно в пакеты python пробралась паразитная сборочная 
зависимость на пакет python-module-setuptools-tests (кто-то в офисе в 
Москве предположил, что это могло произойти через некорректное 
использование buildreq)

Сейчас этого пакета нет, но зависимость осталась. Чинится пересборкой с 
заменой сборочной зависимости на python-module-setuptools. И я 
предполагаю, что это исправят в ближайшее время скриптом (тот же кто и 
сломал).

Ну и новый glibc приехал, в котором теперь нет libnls - эти пакеты уже 
надо чинить. Но про это изменение, наверное, больше знает ldv@

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Sergey Afonin]

On Friday 02 February 2018, Alexei Takaseev wrote:

> В Сизифе что-то большое рвануло?
 
И интересное. Про Питон я прочитал, но у меня рванул Sendmail с

/usr/src/RPM/BUILD/sendmail-8.15.2/obj.Linux.4.9.78-std-def-alt1.i686/libsm/libsm.a  -ldb -lresolv -lcrypt -ldl -ldb -llber -lcrypt -lgdbm -lnsl -lresolv -lwrap -lssl -lcrypto -lsasl2 -lldap 
/usr/bin/ld: cannot find -lnsl

при том, что ему никогда этот libnsl нужен не был и даже который
в Сизифе сейчас, недавно пересобранный, зависимости на libnsl не
имеет.

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

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Sergey Afonin]

On Friday 02 February 2018, Sergey Afonin wrote:

> > В Сизифе что-то большое рвануло?
>  
> И интересное. Про Питон я прочитал,

Ага, а до конца не дочитал, где про libnsl уже.
Всё понятно.

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

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Anton Farygin]

02.02.2018 09:18, Sergey Afonin пишет:
> On Friday 02 February 2018, Alexei Takaseev wrote:
>
>> В Сизифе что-то большое рвануло?
>   
> И интересное. Про Питон я прочитал, но у меня рванул Sendmail с
>
> /usr/src/RPM/BUILD/sendmail-8.15.2/obj.Linux.4.9.78-std-def-alt1.i686/libsm/libsm.a  -ldb -lresolv -lcrypt -ldl -ldb -llber -lcrypt -lgdbm -lnsl -lresolv -lwrap -lssl -lcrypto -lsasl2 -lldap
> /usr/bin/ld: cannot find -lnsl
>
> при том, что ему никогда этот libnsl нужен не был и даже который
> в Сизифе сейчас, недавно пересобранный, зависимости на libnsl не
> имеет.
>
Скорее всего libnsl приехал откуда-то извне. Например от perl'а.

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Sergey Afonin]

On Friday 02 February 2018, Sergey Afonin wrote:

> Ага, а до конца не дочитал, где про libnsl уже.
> Всё понятно.

Тьфублин, в трёх буквах заблудился. :-) В glibc же nls...

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

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Sergey Afonin]

On Friday 02 February 2018, Anton Farygin wrote:

> > /usr/bin/ld: cannot find -lnsl
> >
> > при том, что ему никогда этот libnsl нужен не был и даже который
> > в Сизифе сейчас, недавно пересобранный, зависимости на libnsl не
> > имеет.
> >
> Скорее всего libnsl приехал откуда-то извне. Например от perl'а.

Это тоже про glibc, судя по описанию, что такое libnsl2. И, как раз,
darktemplar@ пытался оторвать от Sendmail поддержку NIS в последней
пересборке, наверное не дооторвалось, раз хочет nsl. Примерно понятно,
что делать.

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

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Dmitry V. Levin]

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

On Fri, Feb 02, 2018 at 07:44:20AM +0300, Anton Farygin wrote:
[...]
> Ну и новый glibc приехал, в котором теперь нет libnls - эти пакеты уже 
> надо чинить. Но про это изменение, наверное, больше знает ldv@

Скорее так: -lnsl теперь нет, libnsl.so.1 для обратной совместимости пока
ещё сохраняется.

Вчерашняя пересборка пакета perl должна была исправить почти все сборочные
регрессии, связанные с -lnsl:

$ rpmquery --lastchange -p Sisyphus/files/SRPMS/perl-5.26.1-alt4.src.rpm 
* Thu Feb 01 2018 Dmitry V. Levin <ldv@> 1:5.26.1-alt4
- Rebuilt with new glibc (without -lnsl).


-- 
ldv

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

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Levin Stanislav]

[-- Attachment #1.1.1: Type: text/plain, Size: 1322 bytes --]

Здравствуйте!


Занимаюсь починкой сборки python пакетов (python-module-setuptools-tests
-> python-module-setuptools).

Иду по списку, будет сделано ASAP.


Спасибо.



02.02.2018 07:44, Anton Farygin пишет:
> 02.02.2018 04:39, Alexei Takaseev пишет:
>> Добрый день!
>>
>> ----- Исходное сообщение -----
>>> От: "ALT beekeeper" <hiver@altlinux.org>
>>> Кому: sisyphus-cybertalk@lists.altlinux.org
>>> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58
>>> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)
>> В Сизифе что-то большое рвануло?
> Когда-то давным давно в пакеты python пробралась паразитная сборочная
> зависимость на пакет python-module-setuptools-tests (кто-то в офисе в
> Москве предположил, что это могло произойти через некорректное
> использование buildreq)
>
> Сейчас этого пакета нет, но зависимость осталась. Чинится пересборкой
> с заменой сборочной зависимости на python-module-setuptools. И я
> предполагаю, что это исправят в ближайшее время скриптом (тот же кто и
> сломал).
>
> Ну и новый glibc приехал, в котором теперь нет libnls - эти пакеты уже
> надо чинить. Но про это изменение, наверное, больше знает ldv@
>
>
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


[-- Attachment #1.1.2: 0x5D9A19E8.asc --]
[-- Type: application/pgp-keys, Size: 4691 bytes --]

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

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Igor Vlasenko]

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

On Fri, Feb 02, 2018 at 03:05:55PM +0300, Levin Stanislav wrote:
> Здравствуйте!
> 
> 
> Занимаюсь починкой сборки python пакетов (python-module-setuptools-tests
> -> python-module-setuptools).
> 
> Иду по списку, будет сделано ASAP.

Можно еще ускорить это дело.
В аттачменте скрипт fix-stetuptools-tests.pl
На отдельные пакеты его можно применять с помощью
srpmnmu --hook fix-stetuptools-tests.pl <srpm>
srpmnmu --hook fix-stetuptools-tests.pl -i <spec>

а на всю транзакцию сразу с помощью
https://www.altlinux.org/Git.alt/girar-nmu#утилиты для подготовки NMU.
См. там же так же
#Использование girar-nmu utils на примере обновления perl

-- 

I V

[-- Attachment #2: fix-stetuptools-tests.pl --]
[-- Type: application/x-perl, Size: 911 bytes --]

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Dmitry V. Levin]

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

On Fri, Feb 02, 2018 at 07:44:20AM +0300, Anton Farygin wrote:
> 02.02.2018 04:39, Alexei Takaseev пишет:
> > Добрый день!
> >
> > ----- Исходное сообщение -----
> >> От: "ALT beekeeper" <hiver@altlinux.org>
> >> Кому: sisyphus-cybertalk@lists.altlinux.org
> >> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58
> >> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)
> > В Сизифе что-то большое рвануло?
> Когда-то давным давно в пакеты python пробралась паразитная сборочная 
> зависимость на пакет python-module-setuptools-tests (кто-то в офисе в 
> Москве предположил, что это могло произойти через некорректное 
> использование buildreq)
> 
> Сейчас этого пакета нет, но зависимость осталась. Чинится пересборкой с 
> заменой сборочной зависимости на python-module-setuptools. И я 
> предполагаю, что это исправят в ближайшее время скриптом (тот же кто и 
> сломал).

Может, проще было бы добавить provides для обратной совместимости,
чем пересобирать сотни пакетов?


-- 
ldv

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

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Anton Farygin]

03.02.2018 03:14, Dmitry V. Levin пишет:
> On Fri, Feb 02, 2018 at 07:44:20AM +0300, Anton Farygin wrote:
>> 02.02.2018 04:39, Alexei Takaseev пишет:
>>> Добрый день!
>>>
>>> ----- Исходное сообщение -----
>>>> От: "ALT beekeeper"<hiver@altlinux.org>
>>>> Кому:sisyphus-cybertalk@lists.altlinux.org
>>>> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58
>>>> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)
>>> В Сизифе что-то большое рвануло?
>> Когда-то давным давно в пакеты python пробралась паразитная сборочная
>> зависимость на пакет python-module-setuptools-tests (кто-то в офисе в
>> Москве предположил, что это могло произойти через некорректное
>> использование buildreq)
>>
>> Сейчас этого пакета нет, но зависимость осталась. Чинится пересборкой с
>> заменой сборочной зависимости на python-module-setuptools. И я
>> предполагаю, что это исправят в ближайшее время скриптом (тот же кто и
>> сломал).
> Может, проще было бы добавить provides для обратной совместимости,
> чем пересобирать сотни пакетов?

Может быть и проще, но правильнее и честнее пересобрать.

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Dmitry V. Levin]

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

On Sat, Feb 03, 2018 at 07:41:04AM +0300, Anton Farygin wrote:
> 03.02.2018 03:14, Dmitry V. Levin пишет:
> > On Fri, Feb 02, 2018 at 07:44:20AM +0300, Anton Farygin wrote:
> >> 02.02.2018 04:39, Alexei Takaseev пишет:
> >>> Добрый день!
> >>>
> >>> ----- Исходное сообщение -----
> >>>> От: "ALT beekeeper"<hiver@altlinux.org>
> >>>> Кому:sisyphus-cybertalk@lists.altlinux.org
> >>>> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58
> >>>> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)
> >>> В Сизифе что-то большое рвануло?
> >> Когда-то давным давно в пакеты python пробралась паразитная сборочная
> >> зависимость на пакет python-module-setuptools-tests (кто-то в офисе в
> >> Москве предположил, что это могло произойти через некорректное
> >> использование buildreq)
> >>
> >> Сейчас этого пакета нет, но зависимость осталась. Чинится пересборкой с
> >> заменой сборочной зависимости на python-module-setuptools. И я
> >> предполагаю, что это исправят в ближайшее время скриптом (тот же кто и
> >> сломал).
> > Может, проще было бы добавить provides для обратной совместимости,
> > чем пересобирать сотни пакетов?
> 
> Может быть и проще, но правильнее и честнее пересобрать.

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

Правильнее пересобирать все компилируемые пакеты после обновления
тулчейна, мы готовы к этому?


-- 
ldv

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

[devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Ivan Zakharyaschev]

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


On Sun, 4 Feb 2018, Dmitry V. Levin wrote:

> On Sat, Feb 03, 2018 at 07:41:04AM +0300, Anton Farygin wrote:
>> 03.02.2018 03:14, Dmitry V. Levin пишет:
>>> On Fri, Feb 02, 2018 at 07:44:20AM +0300, Anton Farygin wrote:
>>>> 02.02.2018 04:39, Alexei Takaseev пишет:
>>>>> Добрый день!
>>>>>
>>>>> ----- Исходное сообщение -----
>>>>>> От: "ALT beekeeper"<hiver@altlinux.org>
>>>>>> Кому:sisyphus-cybertalk@lists.altlinux.org
>>>>>> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58
>>>>>> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)
>>>>> В Сизифе что-то большое рвануло?
>>>> Когда-то давным давно в пакеты python пробралась паразитная сборочная
>>>> зависимость на пакет python-module-setuptools-tests (кто-то в офисе в
>>>> Москве предположил, что это могло произойти через некорректное
>>>> использование buildreq)
>>>>
>>>> Сейчас этого пакета нет, но зависимость осталась. Чинится пересборкой с
>>>> заменой сборочной зависимости на python-module-setuptools. И я
>>>> предполагаю, что это исправят в ближайшее время скриптом (тот же кто и
>>>> сломал).
>>> Может, проще было бы добавить provides для обратной совместимости,
>>> чем пересобирать сотни пакетов?
>>
>> Может быть и проще, но правильнее и честнее пересобрать.
>
> Почему правильнее?  Станут ли Пакеты, полученные в результате пересборки,
> лучше прежних?

По идее (без рассмотрения конкретно этого случая), пакеты python*-tests 
никому не должны быть нужны ни в runtime, ни при сборке (за исключением, 
возможно, каких-то хитрых %check). (Просто тесты, которые можно запустить 
в системе.)

> Правильнее пересобирать все компилируемые пакеты после обновления
> тулчейна, мы готовы к этому?

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

По идее, их можно было бы сложить в отдельную компоненту все и не 
нагружать обычные pkglists, если уж сложилась практика их паковать. Но 
плодить компоненты, про которые никто не будет знать, тоже не хочется. 
Можно было бы одну компоненту junk завести.

Помимо предположения о том, что какие-то хитрые %check могут использовать 
чужие python*-tests, можно сказать, что пакеты *-checkinstall должны иметь 
возможность использоввать python*-tests (не в виде исключения, а как 
обычное дело).

(Отличие python*-tetss от *-checkinstall в том, что первые просто 
содержат тексты тестов, а вторые их запускают при установке пакета.)

По теме: Provides: python*-tests в нормальном пакете был бы некрасивым 
костылём (каким-то обманом, потому что вообще-то такая сущность не должна 
исользоваться в BuildRequires).

-- 
Best regards,
Ivan

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Anton Farygin]

04.02.2018 02:27, Dmitry V. Levin пишет:
> Правильнее пересобирать все компилируемые пакеты после обновления
> тулчейна, мы готовы к этому?

Да мы то готовы, готова ли сборочница ?

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Leonid Krivoshein]

04.02.2018 02:27, Dmitry V. Levin пишет:
> Правильнее пересобирать все компилируемые пакеты после обновления
> тулчейна, мы готовы к этому?

А сборочница не делает этого автоматически после пересборки хоть 
чего-то, входящего в тулчейн?


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Leonid Krivoshein]

04.02.2018 14:02, Aleksey Novodvorsky пишет:
>
> 4 февр. 2018 г. 11:46 AM пользователь "Leonid Krivoshein" 
> <klark.devel@gmail.com <mailto:klark.devel@gmail.com>> написал:
>
>
>     04.02.2018 02:27, Dmitry V. Levin пишет:
>
>         Правильнее пересобирать все компилируемые пакеты после обновления
>
>         тулчейна, мы готовы к этому?
>
>
>     А сборочница не делает этого автоматически после пересборки хоть
>     чего-то, входящего в тулчейн?
>
>
>
> Но зачем?

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

> У нас, к счастью, есть люди, понимающие, что изменяется и что на самом 
> деле нужно делать.
>

Нисколько не подвергаю сомнению данное утверждение. Моё представление 
откуда-то из LFS и Gentoo вполне может быть здесь неприменимо. Просто 
праздное любопытство.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Dmitry V. Levin]

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

On Sun, Feb 04, 2018 at 02:55:30AM +0300, Ivan Zakharyaschev wrote:
> On Sun, 4 Feb 2018, Dmitry V. Levin wrote:
> > On Sat, Feb 03, 2018 at 07:41:04AM +0300, Anton Farygin wrote:
> >> 03.02.2018 03:14, Dmitry V. Levin пишет:
> >>> On Fri, Feb 02, 2018 at 07:44:20AM +0300, Anton Farygin wrote:
> >>>> 02.02.2018 04:39, Alexei Takaseev пишет:
> >>>>> Добрый день!
> >>>>>
> >>>>> ----- Исходное сообщение -----
> >>>>>> От: "ALT beekeeper"<hiver@altlinux.org>
> >>>>>> Кому:sisyphus-cybertalk@lists.altlinux.org
> >>>>>> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58
> >>>>>> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)
> >>>>> В Сизифе что-то большое рвануло?
> >>>> Когда-то давным давно в пакеты python пробралась паразитная сборочная
> >>>> зависимость на пакет python-module-setuptools-tests (кто-то в офисе в
> >>>> Москве предположил, что это могло произойти через некорректное
> >>>> использование buildreq)
> >>>>
> >>>> Сейчас этого пакета нет, но зависимость осталась. Чинится пересборкой с
> >>>> заменой сборочной зависимости на python-module-setuptools. И я
> >>>> предполагаю, что это исправят в ближайшее время скриптом (тот же кто и
> >>>> сломал).
> >>> Может, проще было бы добавить provides для обратной совместимости,
> >>> чем пересобирать сотни пакетов?
> >>
> >> Может быть и проще, но правильнее и честнее пересобрать.
> >
> > Почему правильнее?  Станут ли Пакеты, полученные в результате пересборки,
> > лучше прежних?
> 
> По идее (без рассмотрения конкретно этого случая), пакеты python*-tests 
> никому не должны быть нужны ни в runtime, ни при сборке (за исключением, 
> возможно, каких-то хитрых %check). (Просто тесты, которые можно запустить 
> в системе.)

По идее да.

> > Правильнее пересобирать все компилируемые пакеты после обновления
> > тулчейна, мы готовы к этому?
> 
> Убрать такую сборочную зависимость -- более существенное улучшение в 
> структуре репозитория Sisyphus, чем просто пересборка отдельных пакетов.

Убрать конкретно эту, или все python*-tests?

> По идее, их можно было бы сложить в отдельную компоненту все и не 
> нагружать обычные pkglists, если уж сложилась практика их паковать. Но 
> плодить компоненты, про которые никто не будет знать, тоже не хочется. 
> Можно было бы одну компоненту junk завести.
> 
> Помимо предположения о том, что какие-то хитрые %check могут использовать 
> чужие python*-tests, можно сказать, что пакеты *-checkinstall должны иметь 
> возможность использоввать python*-tests (не в виде исключения, а как 
> обычное дело).
> 
> (Отличие python*-tetss от *-checkinstall в том, что первые просто 
> содержат тексты тестов, а вторые их запускают при установке пакета.)
> 
> По теме: Provides: python*-tests в нормальном пакете был бы некрасивым 
> костылём (каким-то обманом, потому что вообще-то такая сущность не должна 
> исользоваться в BuildRequires).

Это всё хорошо, конечно, но какое это имеет отношение к данному
конкретному случаю?  Я не вижу, чтобы в результате автоматизированной
слепой пересборки с удалением атавистической сборочной зависимости
полученные пакеты были бы лучше прежних.  Нагрузку на сборочницу вижу,
трафик вижу, а в чём польза-то?


-- 
ldv

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

Re: [devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Ivan Zakharyaschev]

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


On Mon, 5 Feb 2018, Dmitry V. Levin wrote:

>> По идее (без рассмотрения конкретно этого случая), пакеты python*-tests
>> никому не должны быть нужны ни в runtime, ни при сборке (за исключением,
>> возможно, каких-то хитрых %check). (Просто тесты, которые можно запустить
>> в системе.)
>
> По идее да.
>
>>> Правильнее пересобирать все компилируемые пакеты после обновления
>>> тулчейна, мы готовы к этому?
>>
>> Убрать такую сборочную зависимость -- более существенное улучшение в
>> структуре репозитория Sisyphus, чем просто пересборка отдельных пакетов.
>
> Убрать конкретно эту, или все python*-tests?

Вообще из общих соображений все. За сключением каких-то особых хрошо 
обоснованных случаев.

>> По идее, их можно было бы сложить в отдельную компоненту все и не
>> нагружать обычные pkglists, если уж сложилась практика их паковать. Но
>> плодить компоненты, про которые никто не будет знать, тоже не хочется.
>> Можно было бы одну компоненту junk завести.
>>
>> Помимо предположения о том, что какие-то хитрые %check могут использовать
>> чужие python*-tests, можно сказать, что пакеты *-checkinstall должны иметь
>> возможность использоввать python*-tests (не в виде исключения, а как
>> обычное дело).
>>
>> (Отличие python*-tetss от *-checkinstall в том, что первые просто
>> содержат тексты тестов, а вторые их запускают при установке пакета.)
>>
>> По теме: Provides: python*-tests в нормальном пакете был бы некрасивым
>> костылём (каким-то обманом, потому что вообще-то такая сущность не должна
>> исользоваться в BuildRequires).
>
> Это всё хорошо, конечно, но какое это имеет отношение к данному
> конкретному случаю?  Я не вижу, чтобы в результате автоматизированной
> слепой пересборки с удалением атавистической сборочной зависимости
> полученные пакеты были бы лучше прежних.  Нагрузку на сборочницу вижу,
> трафик вижу, а в чём польза-то?

Конечно, не то, чтобы пакеты были заметно отличны. Provides: *-tests тоже 
не хотелось бы оставлять, потому что это будет способствовать нерешению 
проблемы сборочных зависимостей от python*-tests.

-- 
Best regards,
Ivan

Re: [devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Levin Stanislav]

[-- Attachment #1.1.1: Type: text/plain, Size: 3741 bytes --]

05.02.2018 02:35, Dmitry V. Levin пишет:
> On Sun, Feb 04, 2018 at 02:55:30AM +0300, Ivan Zakharyaschev wrote:
>> On Sun, 4 Feb 2018, Dmitry V. Levin wrote:
>>> On Sat, Feb 03, 2018 at 07:41:04AM +0300, Anton Farygin wrote:
>>>> 03.02.2018 03:14, Dmitry V. Levin пишет:
>>>>> On Fri, Feb 02, 2018 at 07:44:20AM +0300, Anton Farygin wrote:
>>>>>> 02.02.2018 04:39, Alexei Takaseev пишет:
>>>>>>> Добрый день!
>>>>>>>
>>>>>>> ----- Исходное сообщение -----
>>>>>>>> От: "ALT beekeeper"<hiver@altlinux.org>
>>>>>>>> Кому:sisyphus-cybertalk@lists.altlinux.org
>>>>>>>> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58
>>>>>>>> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)
>>>>>>> В Сизифе что-то большое рвануло?
>>>>>> Когда-то давным давно в пакеты python пробралась паразитная сборочная
>>>>>> зависимость на пакет python-module-setuptools-tests (кто-то в офисе в
>>>>>> Москве предположил, что это могло произойти через некорректное
>>>>>> использование buildreq)
>>>>>>
>>>>>> Сейчас этого пакета нет, но зависимость осталась. Чинится пересборкой с
>>>>>> заменой сборочной зависимости на python-module-setuptools. И я
>>>>>> предполагаю, что это исправят в ближайшее время скриптом (тот же кто и
>>>>>> сломал).
>>>>> Может, проще было бы добавить provides для обратной совместимости,
>>>>> чем пересобирать сотни пакетов?
>>>> Может быть и проще, но правильнее и честнее пересобрать.
>>> Почему правильнее?  Станут ли Пакеты, полученные в результате пересборки,
>>> лучше прежних?
>> По идее (без рассмотрения конкретно этого случая), пакеты python*-tests 
>> никому не должны быть нужны ни в runtime, ни при сборке (за исключением, 
>> возможно, каких-то хитрых %check). (Просто тесты, которые можно запустить 
>> в системе.)
> По идее да.
>
>>> Правильнее пересобирать все компилируемые пакеты после обновления
>>> тулчейна, мы готовы к этому?
>> Убрать такую сборочную зависимость -- более существенное улучшение в 
>> структуре репозитория Sisyphus, чем просто пересборка отдельных пакетов.
> Убрать конкретно эту, или все python*-tests?
>
>> По идее, их можно было бы сложить в отдельную компоненту все и не 
>> нагружать обычные pkglists, если уж сложилась практика их паковать. Но 
>> плодить компоненты, про которые никто не будет знать, тоже не хочется. 
>> Можно было бы одну компоненту junk завести.
>>
>> Помимо предположения о том, что какие-то хитрые %check могут использовать 
>> чужие python*-tests, можно сказать, что пакеты *-checkinstall должны иметь 
>> возможность использоввать python*-tests (не в виде исключения, а как 
>> обычное дело).
>>
>> (Отличие python*-tetss от *-checkinstall в том, что первые просто 
>> содержат тексты тестов, а вторые их запускают при установке пакета.)
>>
>> По теме: Provides: python*-tests в нормальном пакете был бы некрасивым 
>> костылём (каким-то обманом, потому что вообще-то такая сущность не должна 
>> исользоваться в BuildRequires).
> Это всё хорошо, конечно, но какое это имеет отношение к данному
> конкретному случаю?  Я не вижу, чтобы в результате автоматизированной
> слепой пересборки с удалением атавистической сборочной зависимости
> полученные пакеты были бы лучше прежних.  Нагрузку на сборочницу вижу,
> трафик вижу, а в чём польза-то?
В данном случае пересборка python пакетов с удалением/заменой сборочной
зависимости является вынужденной мерой ( исправление ошибки включения
такой зависимости когда-то в прошлом).
И лучше от этого они ( сами пакеты) действительно не становятся.

Было бы здорово, если бы существовал механизм отложенного применения
действия - изменение спека происходит в настоящем (виртуальный спек?),
который, например, отображается на репозитории/ях, а фактическое
применение - во время следующей сборки.

Спасибо.

[-- Attachment #1.1.2: 0x5D9A19E8.asc --]
[-- Type: application/pgp-keys, Size: 4691 bytes --]

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

Re: [devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Alexey Shabalin]

> Было бы здорово, если бы существовал механизм отложенного применения
> действия - изменение спека происходит в настоящем (виртуальный спек?),
> который, например, отображается на репозитории/ях, а фактическое
> применение - во время следующей сборки.
Мне кажется сейчас такое сделать не возможно.
Тут надо переходить на "централизованный" git и систему poll request.
Например я делаю пакет в packages/shaba/foo.git и предлагаю изменения
для включения в rpms/foo.git.
Кто-то должен принять эти изменения.
ssh gitc.alt build foo tagX собирает пакет не из личного репо
packages/shaba/foo.git, а из "централизованного" rpms/foo.git.
Тогда изменения коллег теряться не будут, и можно накапливать
изменения до следующей сборки.
Конечно, в этом случае, придётся запретить --force для git push.

-- 
Alexey Shabalin

Re: [devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Leonid Krivoshein]

> Было бы здорово, если бы существовал механизм отложенного применения
> действия - изменение спека происходит в настоящем (виртуальный спек?),
> который, например, отображается на репозитории/ях, а фактическое
> применение - во время следующей сборки.

Если планам довести пересборку всего Сизифа за считанные часы суждено 
сбыться, предлагаемая идея очень интересна. Ведь на каждом цикле полной 
пересборки необязательно пересобирать абсолютно все пакеты. Граф 
зависимостей можно построить единожды. Также разово создать новые 
индексы. Это существенно снизит накладные расходы. Фактически и сейчас 
не гарантируется немедленное применение изменений, запросы на сборку 
просто ставятся в очередь.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Leonid Krivoshein]

> >/Было бы здорово, если бы существовал механизм отложенного применения /> >/действия - изменение спека происходит в настоящем (виртуальный спек?), /> >/который, например, отображается на репозитории/ях, а фактическое /> >/применение - во время следующей сборки. /> Мне кажется сейчас такое сделать не возможно.
> Тут надо переходить на "централизованный" git и систему poll request.
> Например я делаю пакет в packages/shaba/foo.git и предлагаю изменения
> для включения в rpms/foo.git.
> Кто-то должен принять эти изменения.
> ssh gitc.alt build foo tagX собирает пакет не из личного репо
> packages/shaba/foo.git, а из "централизованного" rpms/foo.git.
> Тогда изменения коллег теряться не будут, и можно накапливать
> изменения до следующей сборки.
> Конечно, в этом случае, придётся запретить --force для git push.


Как раз так сейчас всё и работает. На git.alt отправлять с --force 
можно, если с моим репозиторием кроме меня никто не кувыркается, на 
build.alt --force уже запрещён. А когда очередь доходит до сборки... ну, 
так она же не всегда сразу доходит.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Alexey Shabalin]

6 февраля 2018 г., 2:05 пользователь Leonid Krivoshein
<klark.devel@gmail.com> написал:
>
>> >/Было бы здорово, если бы существовал механизм отложенного применения />
>> > >/действия - изменение спека происходит в настоящем (виртуальный спек?), />
>> > >/который, например, отображается на репозитории/ях, а фактическое />
>> > >/применение - во время следующей сборки. /> Мне кажется сейчас такое
>> > сделать не возможно.
>> Тут надо переходить на "централизованный" git и систему poll request.
>> Например я делаю пакет в packages/shaba/foo.git и предлагаю изменения
>> для включения в rpms/foo.git.
>> Кто-то должен принять эти изменения.
>> ssh gitc.alt build foo tagX собирает пакет не из личного репо
>> packages/shaba/foo.git, а из "централизованного" rpms/foo.git.
>> Тогда изменения коллег теряться не будут, и можно накапливать
>> изменения до следующей сборки.
>> Конечно, в этом случае, придётся запретить --force для git push.
>
>
>
> Как раз так сейчас всё и работает. На git.alt отправлять с --force можно,
> если с моим репозиторием кроме меня никто не кувыркается,
Нет, не так работает.
C вашим репозиторием никто не может работать, кроме вас.
В смысле, я не могу запушить в ваш репозиторий.
А так же, я не знаю кто еще склонировал мой репозиторий, и ничто мне
не помешает запушить с --force.

> на build.alt
> --force уже запрещён. А когда очередь доходит до сборки... ну, так она же не
> всегда сразу доходит.


-- 
Alexey Shabalin

Re: [devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Anton Farygin]

05.02.2018 15:42, Alexey Shabalin пишет:
>> Было бы здорово, если бы существовал механизм отложенного применения
>> действия - изменение спека происходит в настоящем (виртуальный спек?),
>> который, например, отображается на репозитории/ях, а фактическое
>> применение - во время следующей сборки.
> Мне кажется сейчас такое сделать не возможно.
> Тут надо переходить на "централизованный" git и систему poll request.
> Например я делаю пакет в packages/shaba/foo.git и предлагаю изменения
> для включения в rpms/foo.git.
> Кто-то должен принять эти изменения.
> ssh gitc.alt build foo tagX собирает пакет не из личного репо
> packages/shaba/foo.git, а из "централизованного" rpms/foo.git.
> Тогда изменения коллег теряться не будут, и можно накапливать
> изменения до следующей сборки.
> Конечно, в этом случае, придётся запретить --force для git push.
>
Вопрос в определении целесообразности очередной сборки.

Здесь было бы оптимальнее, на мой взгляд, предусмотреть возможность 
объединения сборочных заданий - т.е. - выполнять такие задания в режиме 
test-only и коммитить их в sisyphus сразу одним таском за один раз.

Если я правильно понимаю волнения Димы, то всё упирается в серверные 
мощности.

Re: [devel] python*-tests; was: Re: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510)

[Leonid Krivoshein]

06.02.2018 02:44, Alexey Shabalin пишет:
> 6 февраля 2018 г., 2:05 пользователь Leonid Krivoshein
> <klark.devel@gmail.com> написал:
>>> Тут надо переходить на "централизованный" git и систему poll request.
>>> Например я делаю пакет в packages/shaba/foo.git и предлагаю изменения
>>> для включения в rpms/foo.git.
>>> Кто-то должен принять эти изменения.
>>> ssh gitc.alt build foo tagX собирает пакет не из личного репо
>>> packages/shaba/foo.git, а из "централизованного" rpms/foo.git.
>>> Тогда изменения коллег теряться не будут, и можно накапливать
>>> изменения до следующей сборки.
>>> Конечно, в этом случае, придётся запретить --force для git push.
>> Как раз так сейчас всё и работает. На git.alt отправлять с --force можно,
>> если с моим репозиторием кроме меня никто не кувыркается,
> Нет, не так работает.
> C вашим репозиторием никто не может работать, кроме вас.
На то он и "мой". Хотя брать оттуда исходники можно.

> В смысле, я не могу запушить в ваш репозиторий.
А для этого у вас имеется "свой". Если нет -- init-db.

> А так же, я не знаю кто еще склонировал мой репозиторий, и ничто мне
> не помешает запушить с --force.

Не совсем так. Если кто-то хочет начать активно работать с вашим 
репозиторием, он прежде может с вами об этом договориться. Понимаю, 
звучит не очень технологично. Но ведь если это представляет 
действительно проблему для вас, значит можно просто избегать --force.

В свою очередь механизм заданий обеспечивает транзакционность запуска 
процессов сборки. Общие (для нескольких маинтейнеров) задания -- да, 
пожалуйста. Копим в своих репо, набиваем в таск и пускаем всё разом. И 
на выходе "централизованный сизиф", состоящий из кучи отдельных гитов.

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

>> на build.alt
>> --force уже запрещён. А когда очередь доходит до сборки... ну, так она же не
>> всегда сразу доходит.
>

-- 
Best regards,
Leonid Krivoshein.