[devel] I: подготовка Сизифа к бранчеванию p9

[devel] I: подготовка Сизифа к бранчеванию p9

[Dmitry V. Levin]

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

On Tue, Feb 26, 2019 at 07:49:17PM +0300, Anton Farygin wrote:
> 26.02.2019 19:38, Dmitry V. Levin пишет:
[...]
> > Я не понял, вы что, планируете во время фриза обновить версию qt5?
> >
> А что, было объявление о фризе ?

Да, о подготовке к p9 хорошо известно внутри компании.
Но, поскольку p9 не t9, то и фриз этот затрагивает в первую очередь
сотрудников компании, объявлять фриз Сизифа для подготовки p9
было бы некорректно.

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

> Мы планировали обновить версию qt до выпуска p9,

Вы планировали?  Интересная новость.
А что вы ещё планировали до выпуска p9?
Огласите весь список, пожалуйста.

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

План выпуска p9 очень простой:
1. обеспечить пересобираемость всех (или почти всех) пакетов,
   предположительно входящих в дистрибутивы на p9, и в целом по бранчу
   уменьшить множество несобирающихся пакетов до приемлемого минимума;
2. пересобрать все пакеты, которые существенно меняются
   в результате пересборки, в особенности пакеты с зависимостями на
   .sisyphus.* и пакеты, при пересборке получающие зависимости
   на другие soname.

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

> Хотя Зерг утверждает что это можно сделать и потом, но мне кажется что 
> было бы лучше обновить сейчас, вместе с KDE.

Если обновление сломает собираемость пакетов, входящих в дистрибутивы
на p9, это обновление следует отложить.

Текущий список несобирающихся пакетов, предположительно входящих
в дистрибутивы на p9, находится тут:
http://git.altlinux.org/people/qa_ldv/public/?p=proscriptions.git;a=blob_plain;f=snames-ftbfs.list

Этот список обновляется автоматически по окончании тестовой пересборки
Sisyphus/x86_64.


-- 
ldv

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

Re: [devel] I: подготовка Сизифа к бранчеванию p9

[Anton Farygin]

27.02.2019 3:40, Dmitry V. Levin пишет:
> On Tue, Feb 26, 2019 at 07:49:17PM +0300, Anton Farygin wrote:
>> 26.02.2019 19:38, Dmitry V. Levin пишет:
> [...]
>>> Я не понял, вы что, планируете во время фриза обновить версию qt5?
>>>
>> А что, было объявление о фризе ?
> Да, о подготовке к p9 хорошо известно внутри компании.
> Но, поскольку p9 не t9, то и фриз этот затрагивает в первую очередь
> сотрудников компании, объявлять фриз Сизифа для подготовки p9
> было бы некорректно.
>
> Хотя я был бы благодарен, если бы во время подготовки Сизифа для
> бранчевания все (не только сотрудники компании) сосредоточились бы
> на исправлении пакетов, и постарались бы воздержаться от изменений,
> ломающих другие пакеты.
>
>> Мы планировали обновить версию qt до выпуска p9,
> ф

qt, kde, php5 > /dev/null, selinux-refpolicy, подпись нового shim (в 
процессе), libmysqlclient, поддержка AMD Ryzen (который не работает на 
сизифе, что бы там не утверждал aen).



>
>> но т.к. у нас никаких
>> понятых кому-то кроме тебя планов по выпуску веток нету - то она будет
>> обновляться сейчас.
> План выпуска p9 очень простой:
> 1. обеспечить пересобираемость всех (или почти всех) пакетов,
>     предположительно входящих в дистрибутивы на p9, и в целом по бранчу
>     уменьшить множество несобирающихся пакетов до приемлемого минимума;
> 2. пересобрать все пакеты, которые существенно меняются
>     в результате пересборки, в особенности пакеты с зависимостями на
>     .sisyphus.* и пакеты, при пересборке получающие зависимости
>     на другие soname.
>
> В случае существенных регрессий в Сизифе есть техническая возможность
> бранчевать p9 не от текущего состояния Сизифа, а от более стабильного
> состояния из прошлого, но мне бы очень хотелось этого избежать.
Странная цель - пересобираемость пакетов. Цель наверное должна быть 
всё-таки какая-то другая ?
Как показывает практика p8 - пересобираемость пакетов через какое-то 
время разламывается.
>
>> Хотя Зерг утверждает что это можно сделать и потом, но мне кажется что
>> было бы лучше обновить сейчас, вместе с KDE.
> Если обновление сломает собираемость пакетов, входящих в дистрибутивы
> на p9, это обновление следует отложить.
Нет дистрибутивов на p9, невозможно понять, какие в них будут пакеты.
>
> Текущий список несобирающихся пакетов, предположительно входящих
> в дистрибутивы на p9, находится тут:
> http://git.altlinux.org/people/qa_ldv/public/?p=proscriptions.git;a=blob_plain;f=snames-ftbfs.list
>
> Этот список обновляется автоматически по окончании тестовой пересборки
> Sisyphus/x86_64.

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

Re: [devel] I: подготовка Сизифа к бранчеванию p9

[Anton Farygin]

27.02.2019 7:44, Aleksey Novodvorsky пишет:
>
>     поддержка AMD Ryzen (который не работает на
>     сизифе, что бы там не утверждал aen).
>
> Это очень легко проверить. Приезжай в Московский офис, пощупай, -- мы 
> купили такой десктоп пару дней назад  и водрузили на него тестовую 
> сборку Workstation 9 на Сизифе.

Наверное не все десктопы одинаковые - у меня несколько дней назад 
заводилось без 3D.

Re: [devel] I: подготовка Сизифа к бранчеванию p9

[Leonid Krivoshein]

27.02.2019 07:51, Anton Farygin пишет:
> 27.02.2019 7:44, Aleksey Novodvorsky пишет:
>>
>>     поддержка AMD Ryzen (который не работает на
>>     сизифе, что бы там не утверждал aen).
>>
>> Это очень легко проверить. Приезжай в Московский офис, пощупай, -- мы 
>> купили такой десктоп пару дней назад  и водрузили на него тестовую 
>> сборку Workstation 9 на Сизифе.
>
> Наверное не все десктопы одинаковые - у меня несколько дней назад 
> заводилось без 3D.
>

Ryzen 3 или 5? Vega 11? Вот здесь отзывы пользователей по Ryzen на p8 и 
Сизифе:
https://forum.altlinux.org/index.php?topic=41412.msg335784#msg335784

Даже с новым ядром на p8 нарекания есть.
3D не проверяли ещё, другая задача была.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] I: подготовка Сизифа к бранчеванию p9

[Vladimir D. Seleznev]

On Wed, Feb 27, 2019 at 07:38:06AM +0300, Anton Farygin wrote:
> >> но т.к. у нас никаких
> >> понятых кому-то кроме тебя планов по выпуску веток нету - то она будет
> >> обновляться сейчас.
> > План выпуска p9 очень простой:
> > 1. обеспечить пересобираемость всех (или почти всех) пакетов,
> >     предположительно входящих в дистрибутивы на p9, и в целом по бранчу
> >     уменьшить множество несобирающихся пакетов до приемлемого минимума;
> > 2. пересобрать все пакеты, которые существенно меняются
> >     в результате пересборки, в особенности пакеты с зависимостями на
> >     .sisyphus.* и пакеты, при пересборке получающие зависимости
> >     на другие soname.
> >
> > В случае существенных регрессий в Сизифе есть техническая возможность
> > бранчевать p9 не от текущего состояния Сизифа, а от более стабильного
> > состояния из прошлого, но мне бы очень хотелось этого избежать.
> Странная цель - пересобираемость пакетов. Цель наверное должна быть 
> всё-таки какая-то другая ?
> Как показывает практика p8 - пересобираемость пакетов через какое-то 
> время разламывается.
> >
> >> Хотя Зерг утверждает что это можно сделать и потом, но мне кажется что
> >> было бы лучше обновить сейчас, вместе с KDE.
> > Если обновление сломает собираемость пакетов, входящих в дистрибутивы
> > на p9, это обновление следует отложить.
> Нет дистрибутивов на p9, невозможно понять, какие в них будут пакеты.
> >
> > Текущий список несобирающихся пакетов, предположительно входящих
> > в дистрибутивы на p9, находится тут:
> > http://git.altlinux.org/people/qa_ldv/public/?p=proscriptions.git;a=blob_plain;f=snames-ftbfs.list
> >
> > Этот список обновляется автоматически по окончании тестовой пересборки
> > Sisyphus/x86_64.
> 
> Дима, я согласен с тобой в том, что пересобираемость пакетов важный 
> показатель качества репозитория. Но, к сожалению, далеко не самый важный.

Пересобираемость пакетов не только показатель качества репозитория. Все
пакеты, входящие в дистрибутивы, нужно мочь собрать из исходников;
список таких пакетов можно получить по факту собрав дистрибутивы из
репозитория. Помимо технической возможности показать, что все входящие
пакеты в дистрибутивы возможно собрать, есть ещё и лицензионная
составляющая: для всех пакетов, распространяемых под GPL, помимо
предоставления исходных кодов, необходимо предоставить инструкции по
сборке пакетов. В данном случае это spec'и и инструментарии сборки.
Поэтому распространение в дистрибутивах непересобирающихся пакетов,
распространяемых под GPL, является нарушением GPL.

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

Re: [devel] I: подготовка Сизифа к бранчеванию p9

[Anton Farygin]

27.02.2019 19:05, Vladimir D. Seleznev пишет:
>> Дима, я согласен с тобой в том, что пересобираемость пакетов важный
>> показатель качества репозитория. Но, к сожалению, далеко не самый важный.
> Пересобираемость пакетов не только показатель качества репозитория. Все
> пакеты, входящие в дистрибутивы, нужно мочь собрать из исходников;
> список таких пакетов можно получить по факту собрав дистрибутивы из
> репозитория. Помимо технической возможности показать, что все входящие
> пакеты в дистрибутивы возможно собрать, есть ещё и лицензионная
> составляющая: для всех пакетов, распространяемых под GPL, помимо
> предоставления исходных кодов, необходимо предоставить инструкции по
> сборке пакетов. В данном случае это spec'и и инструментарии сборки.
> Поэтому распространение в дистрибутивах непересобирающихся пакетов,
> распространяемых под GPL, является нарушением GPL.

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

Просто мы в любом случае будем делать запланированные изменения - до 
бранчевания или после. И в любом случае нам чинить сломавшиеся пакеты.

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

[devel] 0ad segfaults with libmozjs38 alt3.1

[Alexey Tourbin]

On Thu, Feb 28, 2019 at 7:35 AM Anton Farygin <rider@basealt.ru> wrote:
> 27.02.2019 19:05, Vladimir D. Seleznev пишет:
> > Поэтому распространение в дистрибутивах непересобирающихся пакетов,
> > распространяемых под GPL, является нарушением GPL.
>
> Да, я как раз про это и пишу - собираемость репозитория важный
> показатель качества, но далеко не единственый и даже не на первом месте.

Да, пожалуй поважнее будет, чтобы программы не падали в segfault.
Добиться этого к сожалению довольно сложно. Обнаружил, что после
простой пересборки libmozjs38 (alt3 -> alt3.1) стал падать 0ad.
Правда, полной уверенности у меня нету: падает редко. Но раньше не
падал.

Мне кажется это он стал падать из-за того, что в rpm добавили disttag.
Потому когда disttag'а не было, то он и не падал.  А как disttag
добавили, так сразу стал падать.  В общем, как говорили древние, post
hoc ergo πρωκτός hoc. Задница какая-то короче.

Re: [devel] 0ad segfaults with libmozjs38 alt3.1

[Anton Farygin]

28.02.2019 8:44, Alexey Tourbin пишет:
> On Thu, Feb 28, 2019 at 7:35 AM Anton Farygin <rider@basealt.ru> wrote:
>> 27.02.2019 19:05, Vladimir D. Seleznev пишет:
>>> Поэтому распространение в дистрибутивах непересобирающихся пакетов,
>>> распространяемых под GPL, является нарушением GPL.
>> Да, я как раз про это и пишу - собираемость репозитория важный
>> показатель качества, но далеко не единственый и даже не на первом месте.
> Да, пожалуй поважнее будет, чтобы программы не падали в segfault.
> Добиться этого к сожалению довольно сложно. Обнаружил, что после
> простой пересборки libmozjs38 (alt3 -> alt3.1) стал падать 0ad.
> Правда, полной уверенности у меня нету: падает редко. Но раньше не
> падал.
>
> Мне кажется это он стал падать из-за того, что в rpm добавили disttag.
> Потому когда disttag'а не было, то он и не падал.  А как disttag
> добавили, так сразу стал падать.  В общем, как говорили древние, post
> hoc ergo πρωκτός hoc. Задница какая-то короче.

Юмор оценил, спасибо.

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

Ведь воспроизвести стабильную сборку уже невозможно.

Re: [devel] 0ad segfaults with libmozjs38 alt3.1

[Andrey Savchenko]

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

On Thu, 28 Feb 2019 09:36:17 +0300 Anton Farygin wrote:
> 28.02.2019 8:44, Alexey Tourbin пишет:
> > On Thu, Feb 28, 2019 at 7:35 AM Anton Farygin <rider@basealt.ru> wrote:
> >> 27.02.2019 19:05, Vladimir D. Seleznev пишет:
> >>> Поэтому распространение в дистрибутивах непересобирающихся пакетов,
> >>> распространяемых под GPL, является нарушением GPL.
> >> Да, я как раз про это и пишу - собираемость репозитория важный
> >> показатель качества, но далеко не единственый и даже не на первом месте.
> > Да, пожалуй поважнее будет, чтобы программы не падали в segfault.
> > Добиться этого к сожалению довольно сложно. Обнаружил, что после
> > простой пересборки libmozjs38 (alt3 -> alt3.1) стал падать 0ad.
> > Правда, полной уверенности у меня нету: падает редко. Но раньше не
> > падал.
> >
> > Мне кажется это он стал падать из-за того, что в rpm добавили disttag.
> > Потому когда disttag'а не было, то он и не падал.  А как disttag
> > добавили, так сразу стал падать.  В общем, как говорили древние, post
> > hoc ergo πρωκτός hoc. Задница какая-то короче.
> 
> Юмор оценил, спасибо.
> 
> Интересно, насколько нарушается GPL для случая, когда простая пересборка 
> приводит к тому, что приложения начинают иногда падать, хотя до этого 
> они не падали ?
> 
> Ведь воспроизвести стабильную сборку уже невозможно.

GPL не нарушается, т.к. требований стабильной сборки там нет и, тем
более, требований стабильной работы.

Best regards,
Andrew Savchenko

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

Re: [devel] 0ad segfaults with libmozjs38 alt3.1

[Anton Farygin]

28.02.2019 10:12, Andrey Savchenko пишет:
> On Thu, 28 Feb 2019 09:36:17 +0300 Anton Farygin wrote:
>> 28.02.2019 8:44, Alexey Tourbin пишет:
>>> On Thu, Feb 28, 2019 at 7:35 AM Anton Farygin <rider@basealt.ru> wrote:
>>>> 27.02.2019 19:05, Vladimir D. Seleznev пишет:
>>>>> Поэтому распространение в дистрибутивах непересобирающихся пакетов,
>>>>> распространяемых под GPL, является нарушением GPL.
>>>> Да, я как раз про это и пишу - собираемость репозитория важный
>>>> показатель качества, но далеко не единственый и даже не на первом месте.
>>> Да, пожалуй поважнее будет, чтобы программы не падали в segfault.
>>> Добиться этого к сожалению довольно сложно. Обнаружил, что после
>>> простой пересборки libmozjs38 (alt3 -> alt3.1) стал падать 0ad.
>>> Правда, полной уверенности у меня нету: падает редко. Но раньше не
>>> падал.
>>>
>>> Мне кажется это он стал падать из-за того, что в rpm добавили disttag.
>>> Потому когда disttag'а не было, то он и не падал.  А как disttag
>>> добавили, так сразу стал падать.  В общем, как говорили древние, post
>>> hoc ergo πρωκτός hoc. Задница какая-то короче.
>> Юмор оценил, спасибо.
>>
>> Интересно, насколько нарушается GPL для случая, когда простая пересборка
>> приводит к тому, что приложения начинают иногда падать, хотя до этого
>> они не падали ?
>>
>> Ведь воспроизвести стабильную сборку уже невозможно.
> GPL не нарушается, т.к. требований стабильной сборки там нет и, тем
> более, требований стабильной работы.
Да это я тоже так пошутил ;)

Re: [devel] 0ad segfaults with libmozjs38 alt3.1

[Aleksei Nikiforov]

28.02.2019 8:44, Alexey Tourbin пишет:
> On Thu, Feb 28, 2019 at 7:35 AM Anton Farygin <rider@basealt.ru> wrote:
>> 27.02.2019 19:05, Vladimir D. Seleznev пишет:
>>> Поэтому распространение в дистрибутивах непересобирающихся пакетов,
>>> распространяемых под GPL, является нарушением GPL.
>>
>> Да, я как раз про это и пишу - собираемость репозитория важный
>> показатель качества, но далеко не единственый и даже не на первом месте.
> 
> Да, пожалуй поважнее будет, чтобы программы не падали в segfault.
> Добиться этого к сожалению довольно сложно. Обнаружил, что после
> простой пересборки libmozjs38 (alt3 -> alt3.1) стал падать 0ad.
> Правда, полной уверенности у меня нету: падает редко. Но раньше не
> падал.
> 
> Мне кажется это он стал падать из-за того, что в rpm добавили disttag.
> Потому когда disttag'а не было, то он и не падал.  А как disttag
> добавили, так сразу стал падать.  В общем, как говорили древние, post
> hoc ergo πρωκτός hoc. Задница какая-то короче.

Не уверен насчёт причастности rpm к сегфолтам, а вот из-за пересборки 
пакетов свежим gcc проблемы уже были:

https://bugzilla.altlinux.org/36038

Возможно, вылезло нечто аналогичное.

Re: [devel] 0ad segfaults with libmozjs38 alt3.1

[Sergey Afonin]

On Thursday 28 February 2019, Aleksei Nikiforov wrote:

> Не уверен насчёт причастности rpm к сегфолтам

at@ так шутит. :-)

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

Re: [devel] I: подготовка Сизифа к бранчеванию p9

[Andrey Savchenko]

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

On Wed, 27 Feb 2019 19:05:13 +0300 Vladimir D. Seleznev wrote:
> On Wed, Feb 27, 2019 at 07:38:06AM +0300, Anton Farygin wrote:
[...]
> > Дима, я согласен с тобой в том, что пересобираемость пакетов важный 
> > показатель качества репозитория. Но, к сожалению, далеко не самый важный.
> 
> Пересобираемость пакетов не только показатель качества репозитория. Все
> пакеты, входящие в дистрибутивы, нужно мочь собрать из исходников;
> список таких пакетов можно получить по факту собрав дистрибутивы из
> репозитория. Помимо технической возможности показать, что все входящие
> пакеты в дистрибутивы возможно собрать, есть ещё и лицензионная
> составляющая: для всех пакетов, распространяемых под GPL, помимо
> предоставления исходных кодов, необходимо предоставить инструкции по
> сборке пакетов. В данном случае это spec'и и инструментарии сборки.
> Поэтому распространение в дистрибутивах непересобирающихся пакетов,
> распространяемых под GPL, является нарушением GPL.

Не согласен. Я сейчас перечитал GPL-2 и GPL-3 — там нет требования
гарантий сборки без ошибок или гарантий работы без ошибок
предоставляемого ПО. Мало того, разделы 11, 12 GPL-2 и 15, 16
GPL-3 явно указывают на отсутствие гарантий работоспособности
предоставляемого ПО и на отсутствие ответственности за результаты
его работы. Если ты считаешь иначе, пожалуйста, процитируй
конкретные части GPL, где есть такое требование.

Если речь идёт про RPM, то необходимо предоставлять все исходные
коды, необходимые для его получения, т.е. исходники, патчи и spec,
например, в виде SRPM. Есть RPM не собирается по причине тех или
иных ошибок — это, согласно GPL, проблема пользователя, а не
разработчика.

Best regards,
Andrew Savchenko

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