[devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Dmitry V. Levin]

FYI,

вот такие у нас есть ответственные мантейнеры:

$ rpmquery --lastchange -p Sisyphus/files/SRPMS/publican-4.3.2-alt3_13.src.rpm 
* Mon Jun 17 2019 Igor Vlasenko <viy@altlinux> 4.3.2-alt3_13
- update to new release by fcimport

Просьба мантейнерам нижеперечисленных пакетов docs-* озаботиться
исправлением FTBFS в связи с неизбежным удалением пакета publican:

$ echo publican |\
  join -11 -22 -o2.1 - beehive/stats/Sisyphus-x86_64/ufb-2 |\
  join -t$'\t' - ALT/acl/list.packages.sisyphus 
docs-alt-education	azol @docs @everybody
docs-alt-kworkstation	azol @docs @everybody
docs-alt-server	azol @docs @everybody
docs-alt-server-v	lepata @docs @everybody
docs-alt-spworkstation	lepata @docs @everybody
docs-alt-workstation	mike @docs @everybody
docs-centaurus	azol @docs @everybody
docs-kdesktop	alex @docs @everybody
docs-lxdesktop	azol @docs @everybody
docs-lxdesktop-lite	azol @docs @everybody
docs-school-junior	azol @docs
docs-school-master	azol @docs
docs-school-server	azol @docs
docs-school-teacher	azol @docs @everybody
docs-simply-linux	azol @docs @everybody
publican-jboss	viy @everybody

----- Forwarded message from "Girar awaiter (beekeeper)" <girar-builder@altlinux> -----

Date: Sat, 6 Feb 2021 14:32:53 +0000
From: "Girar awaiter (beekeeper)" <girar-builder@altlinux>
To: ALT beekeper <beekeeper@altlinux>
Cc: sisyphus-incominger@lists.altlinux, Igor Vlasenko <viy@altlinux>, girar-builder-sisyphus@altlinux
Subject: [#265890] FAILED del=publican

http://git.altlinux/tasks/265890/logs/events.1.1.log

2021-Feb-06 14:30:42 :: task #265890 for sisyphus started by beekeeper:
2021-Feb-06 14:30:42 :: message: FINAL removal of 66+ weeks i586 ftbfs package
#100 delete publican
2021-Feb-06 14:30:44 :: build check OK
2021-Feb-06 14:30:44 :: noarch check OK
2021-Feb-06 14:30:45 :: plan: src +0 -1 =17799, noarch +0 -5 =17345
2021-Feb-06 14:31:25 :: patched apt indices
2021-Feb-06 14:31:45 :: created next repo
2021-Feb-06 14:32:05 :: duplicate provides check OK
	x86_64: NEW unmet dependencies detected:
 publican-jboss#2.6-alt2_14jpp8:sisyphus+246347.100.1.1@1581791061  publican >= 2.5
	i586: NEW unmet dependencies detected:
 publican-jboss#2.6-alt2_14jpp8:sisyphus+246347.100.1.1@1581791061  publican >= 2.5
	aarch64: NEW unmet dependencies detected:
 publican-jboss#2.6-alt2_14jpp8:sisyphus+246347.100.1.1@1581791061  publican >= 2.5
	ppc64le: NEW unmet dependencies detected:
 publican-jboss#2.6-alt2_14jpp8:sisyphus+246347.100.1.1@1581791061  publican >= 2.5
	armh: NEW unmet dependencies detected:
 publican-jboss#2.6-alt2_14jpp8:sisyphus+246347.100.1.1@1581791061  publican >= 2.5
	ACLs of affected packages (1):
 publican-jboss  viy @everybody
2021-Feb-06 14:32:53 :: unmets: x86_64 +1 -0 =1, i586 +1 -0 =1, aarch64 +1 -0 =5, ppc64le +1 -0 =6, armh +1 -0 =33
2021-Feb-06 14:32:53 :: dependencies check FAILED
2021-Feb-06 14:32:53 :: task #265890 for sisyphus FAILED

----- End forwarded message -----

-- 
ldv

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Michael Shigorin]

On Sat, Feb 06, 2021 at 07:16:15PM +0300, Dmitry V. Levin wrote:
> Просьба мантейнерам нижеперечисленных пакетов docs-* озаботиться
> исправлением FTBFS в связи с неизбежным удалением пакета publican:

Ты смеёшься, издеваешься или собираешься сам сопровождать docs-*?

> $ echo publican |\
>   join -11 -22 -o2.1 - beehive/stats/Sisyphus-x86_64/ufb-2 |\
>   join -t$'\t' - ALT/acl/list.packages.sisyphus 
> docs-alt-education	azol @docs @everybody
> docs-alt-kworkstation	azol @docs @everybody
> docs-alt-server	azol @docs @everybody
> docs-alt-server-v	lepata @docs @everybody
> docs-alt-spworkstation	lepata @docs @everybody
> docs-alt-workstation	mike @docs @everybody
> docs-centaurus	azol @docs @everybody
> docs-kdesktop	alex @docs @everybody
> docs-lxdesktop	azol @docs @everybody
> docs-lxdesktop-lite	azol @docs @everybody
> docs-school-junior	azol @docs
> docs-school-master	azol @docs
> docs-school-server	azol @docs
> docs-school-teacher	azol @docs @everybody
> docs-simply-linux	azol @docs @everybody
> publican-jboss	viy @everybody

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

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Dmitry V. Levin]

On Sat, Feb 06, 2021 at 08:53:06PM +0300, Michael Shigorin wrote:
> On Sat, Feb 06, 2021 at 07:16:15PM +0300, Dmitry V. Levin wrote:
> > Просьба мантейнерам нижеперечисленных пакетов docs-* озаботиться
> > исправлением FTBFS в связи с неизбежным удалением пакета publican:
> 
> Ты смеёшься, издеваешься или собираешься сам сопровождать docs-*?

Я предупреждаю, как обычно.

> > $ echo publican |\
> >   join -11 -22 -o2.1 - beehive/stats/Sisyphus-x86_64/ufb-2 |\
> >   join -t$'\t' - ALT/acl/list.packages.sisyphus 
> > docs-alt-education	azol @docs @everybody
> > docs-alt-kworkstation	azol @docs @everybody
> > docs-alt-server	azol @docs @everybody
> > docs-alt-server-v	lepata @docs @everybody
> > docs-alt-spworkstation	lepata @docs @everybody
> > docs-alt-workstation	mike @docs @everybody
> > docs-centaurus	azol @docs @everybody
> > docs-kdesktop	alex @docs @everybody
> > docs-lxdesktop	azol @docs @everybody
> > docs-lxdesktop-lite	azol @docs @everybody
> > docs-school-junior	azol @docs
> > docs-school-master	azol @docs
> > docs-school-server	azol @docs
> > docs-school-teacher	azol @docs @everybody
> > docs-simply-linux	azol @docs @everybody
> > publican-jboss	viy @everybody


-- 
ldv

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Aleksey Novodvorsky]

сб, 6 февр. 2021 г. в 20:53, Michael Shigorin <mike@altlinux.org>:
>
> On Sat, Feb 06, 2021 at 07:16:15PM +0300, Dmitry V. Levin wrote:
> > Просьба мантейнерам нижеперечисленных пакетов docs-* озаботиться
> > исправлением FTBFS в связи с неизбежным удалением пакета publican:
>
> Ты смеёшься, издеваешься или собираешься сам сопровождать docs-*?
Это призыв. :)
Михаил, нужно решить вопрос со сборкой publican. Учитывая, что он
собирается во всех репозиториях наших коллег, это должно быть реально.

Rgrds, Алексей

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Dmitry V. Levin]

On Sat, Feb 06, 2021 at 09:32:20PM +0300, Aleksey Novodvorsky wrote:
> сб, 6 февр. 2021 г. в 20:53, Michael Shigorin <mike@altlinux.org>:
> > On Sat, Feb 06, 2021 at 07:16:15PM +0300, Dmitry V. Levin wrote:
> > > Просьба мантейнерам нижеперечисленных пакетов docs-* озаботиться
> > > исправлением FTBFS в связи с неизбежным удалением пакета publican:
> >
> > Ты смеёшься, издеваешься или собираешься сам сопровождать docs-*?
> Это призыв. :)
> Михаил, нужно решить вопрос со сборкой publican. Учитывая, что он
> собирается во всех репозиториях наших коллег, это должно быть реально.

Это ещё и наглядная иллюстрация, чего на самом деле стоят эти
цельнотянутые пакеты, сопровождающие у которых только числятся.

Как только с таким пакетом требуется что-то сделать, например, пофиксить
FTBFS, выясняется, что пакет на самом деле не сопровождается.


-- 
ldv

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Alexey Gladkov]

On Sat, Feb 13, 2021 at 02:14:41PM +0300, Dmitry V. Levin wrote:
> On Sat, Feb 06, 2021 at 09:32:20PM +0300, Aleksey Novodvorsky wrote:
> > сб, 6 февр. 2021 г. в 20:53, Michael Shigorin <mike@altlinux.org>:
> > > On Sat, Feb 06, 2021 at 07:16:15PM +0300, Dmitry V. Levin wrote:
> > > > Просьба мантейнерам нижеперечисленных пакетов docs-* озаботиться
> > > > исправлением FTBFS в связи с неизбежным удалением пакета publican:
> > >
> > > Ты смеёшься, издеваешься или собираешься сам сопровождать docs-*?
> > Это призыв. :)
> > Михаил, нужно решить вопрос со сборкой publican. Учитывая, что он
> > собирается во всех репозиториях наших коллег, это должно быть реально.
> 
> Это ещё и наглядная иллюстрация, чего на самом деле стоят эти
> цельнотянутые пакеты, сопровождающие у которых только числятся.

+1

> Как только с таким пакетом требуется что-то сделать, например, пофиксить
> FTBFS, выясняется, что пакет на самом деле не сопровождается.

А много ли протекло таких пакетов протекло из их компонента в сизиф ?

-- 
Rgrds, legion

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Michael Shigorin]

On Sat, Feb 13, 2021 at 02:14:41PM +0300, Dmitry V. Levin wrote:
> Это ещё и наглядная иллюстрация, чего на самом деле стоят эти
> цельнотянутые пакеты, сопровождающие у которых только числятся.
> Как только с таким пакетом требуется что-то сделать, например, пофиксить
> FTBFS, выясняется, что пакет на самом деле не сопровождается.

Ты точно не забыл про http://bugzilla.altlinux.org/38843?

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

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Anton Farygin]

On 13.02.2021 14:14, Dmitry V. Levin wrote:
> On Sat, Feb 06, 2021 at 09:32:20PM +0300, Aleksey Novodvorsky wrote:
>> сб, 6 февр. 2021 г. в 20:53, Michael Shigorin <mike@altlinux.org>:
>>> On Sat, Feb 06, 2021 at 07:16:15PM +0300, Dmitry V. Levin wrote:
>>>> Просьба мантейнерам нижеперечисленных пакетов docs-* озаботиться
>>>> исправлением FTBFS в связи с неизбежным удалением пакета publican:
>>> Ты смеёшься, издеваешься или собираешься сам сопровождать docs-*?
>> Это призыв. :)
>> Михаил, нужно решить вопрос со сборкой publican. Учитывая, что он
>> собирается во всех репозиториях наших коллег, это должно быть реально.
>>
>> Это ещё и наглядная иллюстрация, чего на самом деле стоят эти
>> цельнотянутые пакеты, сопровождающие у которых только числятся.
>>
>> Как только с таким пакетом требуется что-то сделать, например, пофиксить
>> FTBFS, выясняется, что пакет на самом деле не сопровождается.
>>
>>
Я не вижу разницы между цельнотянутыми пакетами и пакетами у 
перегруженных ментейнеров, особенно если объём изменений по сравнению с 
апстримом был приличный.

Явный пример этому postfix, который вроде как сопровождается, но новой 
версии не собрано.

Хотя да, он работает, тут спора нет.

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Dmitry V. Levin]

On Sat, Feb 13, 2021 at 02:26:12PM +0300, Michael Shigorin wrote:
> On Sat, Feb 13, 2021 at 02:14:41PM +0300, Dmitry V. Levin wrote:
> > Это ещё и наглядная иллюстрация, чего на самом деле стоят эти
> > цельнотянутые пакеты, сопровождающие у которых только числятся.
> > Как только с таким пакетом требуется что-то сделать, например, пофиксить
> > FTBFS, выясняется, что пакет на самом деле не сопровождается.
> 
> Ты точно не забыл про http://bugzilla.altlinux.org/38843?

Миша, тебе должно быть стыдно пытаться подменить тему обсуждения.

Мы здесь обсуждаем пакет, цельнотянутый из Федоры, который FTBFS в течение
67 недель (perl сегфолтится во время сборки), который никто даже не
собирается исправлять.

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


-- 
ldv

Re: [devel] уровни сопровождения пакетов

[Dmitry V. Levin]

On Sat, Feb 13, 2021 at 02:40:30PM +0300, Anton Farygin wrote:
[...]
> Я не вижу разницы между цельнотянутыми пакетами и пакетами у 
> перегруженных ментейнеров, особенно если объём изменений по сравнению с 
> апстримом был приличный.

Однако ты видишь эту разницу, потому что она очевидна.
Бывают разные уровни сопровождения.  Пакеты, у которых вообще нет
сопровождающих, находятся на самом низком уровне сопровождения.
Их разрушает любое изменение окружения, к которому они не могут
адаптироваться самостоятельно.

> Явный пример этому postfix, который вроде как сопровождается, но новой 
> версии не собрано.

Текущая версия собирается и работает,
новую версию будет собирать другой мантейнер.

> Хотя да, он работает, тут спора нет.


-- 
ldv

Re: [devel] уровни сопровождения пакетов

[Anton Farygin]

On 13.02.2021 14:52, Dmitry V. Levin wrote:
> On Sat, Feb 13, 2021 at 02:40:30PM +0300, Anton Farygin wrote:
> [...]
>> Я не вижу разницы между цельнотянутыми пакетами и пакетами у
>> перегруженных ментейнеров, особенно если объём изменений по сравнению с
>> апстримом был приличный.
> Однако ты видишь эту разницу, потому что она очевидна.
> Бывают разные уровни сопровождения.  Пакеты, у которых вообще нет
> сопровождающих, находятся на самом низком уровне сопровождения.
> Их разрушает любое изменение окружения, к которому они не могут
> адаптироваться самостоятельно.

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

Но мне так-же не нравятся пакеты, объём изменений в которых заметно 
превышает ресурс сопровождающего.


>
>> Явный пример этому postfix, который вроде как сопровождается, но новой
>> версии не собрано.
> Текущая версия собирается и работает,
> новую версию будет собирать другой мантейнер.
Да, ждём появления нового ментейнера.
>
>> Хотя да, он работает, тут спора нет.
>

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Michael Shigorin]

On Sat, Feb 13, 2021 at 02:44:01PM +0300, Dmitry V. Levin wrote:
> > > Это ещё и наглядная иллюстрация, чего на самом деле стоят эти
> > > цельнотянутые пакеты, сопровождающие у которых только числятся.
> > > Как только с таким пакетом требуется что-то сделать, например, пофиксить
> > > FTBFS, выясняется, что пакет на самом деле не сопровождается.
> > Ты точно не забыл про http://bugzilla.altlinux.org/38843?
> Миша, тебе должно быть стыдно пытаться подменить тему обсуждения.
> Мы здесь обсуждаем пакет, цельнотянутый из Федоры, который
> FTBFS в течение 67 недель (perl сегфолтится во время сборки),
> который никто даже не собирается исправлять.

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

Тебя как самодержца всего сизифа не устраивают эти пакеты?
Так выкинь их.  И прими на себя ответственность перед теми же
документаторами за ftbfs уже у них.

> Поэтому сперва ты отвечаешь на вопрос, почему ты защищаешь этот
> порочный подход, благодаря которому пакеты, которые FTBFS в
> течение 67 недель, никто даже не собирается исправлять, и
> только потом предлагаешь новую тему.  А ещё лучше пойди и
> исправь сборку сломанного и заброшенного пакета, который ты так
> яростно защищаешь.  Иначе всё это только слова.

Я говорю, что ты лукав в этой претензии -- применительно
к вопросам по postfix отсылаешь в LATER с невнятным
"наломал дров" (причём я склонен такой характеристике
всё равно доверять в этом случае), а применительно
к вопросам по publican начинаешь катить бочку лично на
человека, который известен конструктивной критикой твоей
сборочницы.  Это типа месть или просто желание всех под
одну гребёнку?

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

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

[devel] perl/gcc bug? (was: [girar-builder@altlinux: [#265890] FAILED del=publican])

[Michael Shigorin]

On Sat, Feb 13, 2021 at 02:44:01PM +0300, Dmitry V. Levin wrote:
> А ещё лучше пойди и исправь сборку сломанного и заброшенного
> пакета, который ты так яростно защищаешь.

Кстати, возможно, именно это уже объезжали на e2k:
http://bugzilla.altlinux.org/35523
(wd@ наработал воспроизводилку)

Самое забавное будет, если косяк прокрался в gcc, конечно...
(ну или если реализация в perl 5.28/5.30 уживалась со старым
gcc, но не с lcc или новым gcc)

Мне пора по своим делам, отправил на всякий пробное #266271.

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

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Andrey Savchenko]

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

On Sat, 13 Feb 2021 15:08:34 +0300 Michael Shigorin wrote:
> On Sat, Feb 13, 2021 at 02:44:01PM +0300, Dmitry V. Levin wrote:
> > > > Это ещё и наглядная иллюстрация, чего на самом деле стоят эти
> > > > цельнотянутые пакеты, сопровождающие у которых только числятся.
> > > > Как только с таким пакетом требуется что-то сделать, например, пофиксить
> > > > FTBFS, выясняется, что пакет на самом деле не сопровождается.
> > > Ты точно не забыл про http://bugzilla.altlinux.org/38843?
> > Миша, тебе должно быть стыдно пытаться подменить тему обсуждения.
> > Мы здесь обсуждаем пакет, цельнотянутый из Федоры, который
> > FTBFS в течение 67 недель (perl сегфолтится во время сборки),
> > который никто даже не собирается исправлять.
> 
> С твоим обычным формализмом недостаёт квалификатора "видимым для
> сборочницы образом" или вроде того; я, конечно, не могу отвечать
> за viy@ и не знаю, занимается ли он publican, perl 5.32 или ещё
> чем -- но тебе эта шпилька была за то, что ты не менее
> загруженного человека, которого следовало бы подстраховать
> на случай подобных случаев (и получить в сумме более высокую
> степень как свежести пакетов, так и их поддерживаемости),
> начал гнобить.
> 
> Тебя как самодержца всего сизифа не устраивают эти пакеты?
> Так выкинь их.  И прими на себя ответственность перед теми же
> документаторами за ftbfs уже у них.
> 
> > Поэтому сперва ты отвечаешь на вопрос, почему ты защищаешь этот
> > порочный подход, благодаря которому пакеты, которые FTBFS в
> > течение 67 недель, никто даже не собирается исправлять, и
> > только потом предлагаешь новую тему.  А ещё лучше пойди и
> > исправь сборку сломанного и заброшенного пакета, который ты так
> > яростно защищаешь.  Иначе всё это только слова.
> 
> Я говорю, что ты лукав в этой претензии -- применительно
> к вопросам по postfix отсылаешь в LATER с невнятным
> "наломал дров" (причём я склонен такой характеристике
> всё равно доверять в этом случае), а применительно
> к вопросам по publican начинаешь катить бочку лично на
> человека, который известен конструктивной критикой твоей
> сборочницы.  Это типа месть или просто желание всех под
> одну гребёнку?
> 
> (здесь тоже подковырка: не хочу в такое углубляться, но делать
> вид, что ты полностью прав, я не могу -- и должен же хоть кто-то
> сказать, что твои дела противоречат декларируемым тобою же
> взглядам; мне порой было крайне нужно, чтоб кто-то да осадил)
 
https://memepedia.ru/wp-content/uploads/2020/06/eto-drugoe-vy-ne-ponimaete.jpg

Best regards,
Andrew Savchenko

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

Re: [devel] perl/gcc bug (was: [girar-builder@altlinux: [#265890] FAILED del=publican])

[Michael Shigorin]

On Sat, Feb 13, 2021 at 04:22:26PM +0300, Michael Shigorin wrote:
> On Sat, Feb 13, 2021 at 02:44:01PM +0300, Dmitry V. Levin wrote:
> > А ещё лучше пойди и исправь сборку сломанного и заброшенного
> > пакета, который ты так яростно защищаешь.
> Кстати, возможно, именно это уже объезжали на e2k:
> http://bugzilla.altlinux.org/35523
> (wd@ наработал воспроизводилку)
> 
> Мне пора по своим делам, отправил на всякий пробное #266271.

Считается?

---
2021-Feb-13 13:42:18 :: [x86_64] #200 publican-4.3.2-alt3_13.src.rpm: build start
[x86_64] /.out/publican-4.3.2-alt3_13.noarch.rpm: the package obsoletes itself
[x86_64] sisyphus_check: check-deps ERROR: package dependencies violation
[x86_64] /.out/publican-doc-4.3.2-alt3_13.noarch.rpm: The use of such a license name is ambiguous: Artistic
[x86_64] /.out/publican-doc-4.3.2-alt3_13.noarch.rpm: the package obsoletes itself
[x86_64] sisyphus_check: check-deps ERROR: package dependencies violation
[x86_64] /.out/publican-releasenotes-4.3.2-alt3_13.noarch.rpm: The use of such a license name is ambiguous: Artistic
[x86_64] --
[x86_64] /.out/publican-common-db5-web-4.3.2-alt3_13.noarch.rpm: The use of such a license name is ambiguous: Artistic
[x86_64] hsh-rebuild: publican-4.3.2-alt3_13.src.rpm: sisyphus_check failed.
2021-Feb-13 13:45:06 :: [x86_64] publican-4.3.2-alt3_13.src.rpm: remote: build failed
--- http://git.altlinux.org/tasks/266271/logs/events.1.1.log

> Самое забавное будет, если косяк прокрался в gcc, конечно...
> (ну или если реализация в perl 5.28/5.30 уживалась со старым
> gcc, но не с lcc или новым gcc)

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

Re: [devel] perl/gcc bug (was: [girar-builder@altlinux: [#265890] FAILED del=publican])

[Dmitry V. Levin]

On Sat, Feb 13, 2021 at 08:36:36PM +0300, Michael Shigorin wrote:
> On Sat, Feb 13, 2021 at 04:22:26PM +0300, Michael Shigorin wrote:
> > On Sat, Feb 13, 2021 at 02:44:01PM +0300, Dmitry V. Levin wrote:
> > > А ещё лучше пойди и исправь сборку сломанного и заброшенного
> > > пакета, который ты так яростно защищаешь.
> > Кстати, возможно, именно это уже объезжали на e2k:
> > http://bugzilla.altlinux.org/35523
> > (wd@ наработал воспроизводилку)
> > 
> > Мне пора по своим делам, отправил на всякий пробное #266271.
> 
> Считается?
> 
> ---
> 2021-Feb-13 13:42:18 :: [x86_64] #200 publican-4.3.2-alt3_13.src.rpm: build start
> [x86_64] /.out/publican-4.3.2-alt3_13.noarch.rpm: the package obsoletes itself
> [x86_64] sisyphus_check: check-deps ERROR: package dependencies violation
> [x86_64] /.out/publican-doc-4.3.2-alt3_13.noarch.rpm: The use of such a license name is ambiguous: Artistic
> [x86_64] /.out/publican-doc-4.3.2-alt3_13.noarch.rpm: the package obsoletes itself
> [x86_64] sisyphus_check: check-deps ERROR: package dependencies violation
> [x86_64] /.out/publican-releasenotes-4.3.2-alt3_13.noarch.rpm: The use of such a license name is ambiguous: Artistic
> [x86_64] --
> [x86_64] /.out/publican-common-db5-web-4.3.2-alt3_13.noarch.rpm: The use of such a license name is ambiguous: Artistic
> [x86_64] hsh-rebuild: publican-4.3.2-alt3_13.src.rpm: sisyphus_check failed.
> 2021-Feb-13 13:45:06 :: [x86_64] publican-4.3.2-alt3_13.src.rpm: remote: build failed
> --- http://git.altlinux.org/tasks/266271/logs/events.1.1.log

Поздравляю, ты обнаружил, что у пакета publican аж 2 разных причины
FTBFS: первой (perl сегфолтится на i586 и armh) уже 67 недель,
а второй (obsoletes itself) - "всего 24" недели.
Причём вторая причина помешала тебе проверить, удался ли хак для первой.
Попробуй --fail-late, что ли.


-- 
ldv

Re: [devel] perl/gcc bug (was: [girar-builder@altlinux: [#265890] FAILED del=publican])

[Michael Shigorin]

On Sat, Feb 13, 2021 at 09:18:33PM +0300, Dmitry V. Levin wrote:
> > > Кстати, возможно, именно это уже объезжали на e2k:
> > > http://bugzilla.altlinux.org/35523
> > ---
> > 2021-Feb-13 13:42:18 :: [x86_64] #200 publican-4.3.2-alt3_13.src.rpm: build start
> > [x86_64] /.out/publican-common-db5-web-4.3.2-alt3_13.noarch.rpm: The use of such a license name is ambiguous: Artistic
> > --- http://git.altlinux.org/tasks/266271/logs/events.1.1.log
> Поздравляю, ты обнаружил, что у пакета publican аж 2 разных причины
> FTBFS: первой (perl сегфолтится на i586 и armh) уже 67 недель,
> а второй (obsoletes itself) - "всего 24" недели.
> Причём вторая причина помешала тебе проверить, удался ли хак для первой.
> Попробуй --fail-late, что ли.

task #266271: try #2 is AWAITING, но проверка-то уже по .out сломалась
-- насколько помню, по той баге мне вообще не получалось хоть какой-то
пакет publican собрать.

Впрочем, теперь видно, что перл опять сегфолтнулся:

---
[i586] + /usr/bin/perl -CDAS -I /usr/src/RPM/BUILD/Publican-v4.3.2/blib/lib /usr/src/RPM/BUILD/Publican-v4.3.2/blib/script/publican build --formats=html-desktop --publish --langs=en-US --common_config=/usr/src/RPM/BUILD/Publican-v4.3.2/blib/datadir --common_content=/usr/src/RPM/BUILD/Publican-v4.3.2/blib/datadir/Common_Content --nocolours
[i586] /usr/src/tmp/rpm-tmp.44662: line 110: 764217 Segmentation fault      XML_CATALOG_FILES=$dir/catalog /usr/bin/perl -CDAS -I $dir/blib/lib $dir/blib/script/publican build --formats=html-desktop --publish --langs=en-US --common_config="$dir/blib/datadir" --common_content="$dir/blib/datadir/Common_Content" --nocolours
--- http://git.altlinux.org/tasks/266271/logs/events.2.1.log

Можно попробовать учинить ещё одну сессию отладки (кстати, wd@
подумывал в team, насколько помню) -- но если перл работал,
а затем вдруг начал падать, то сломать могли и компилятор,
этот вариант тоже есть смысл прокопать.

На наступающей неделе у меня http://mcst.ru/elbrus-tech-day-2021
и как-то особо ввязываться, боюсь, пока не смогу.

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

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Dmitry V. Levin]

On Sat, Feb 13, 2021 at 10:18:23PM +0300, Michael Shigorin wrote:
> On Sat, Feb 13, 2021 at 09:18:33PM +0300, Dmitry V. Levin wrote:
> > > > Кстати, возможно, именно это уже объезжали на e2k:
> > > > http://bugzilla.altlinux.org/35523
> > > ---
> > > 2021-Feb-13 13:42:18 :: [x86_64] #200 publican-4.3.2-alt3_13.src.rpm: build start
> > > [x86_64] /.out/publican-common-db5-web-4.3.2-alt3_13.noarch.rpm: The use of such a license name is ambiguous: Artistic
> > > --- http://git.altlinux.org/tasks/266271/logs/events.1.1.log
> > Поздравляю, ты обнаружил, что у пакета publican аж 2 разных причины
> > FTBFS: первой (perl сегфолтится на i586 и armh) уже 67 недель,
> > а второй (obsoletes itself) - "всего 24" недели.
> > Причём вторая причина помешала тебе проверить, удался ли хак для первой.
> > Попробуй --fail-late, что ли.
> 
> task #266271: try #2 is AWAITING, но проверка-то уже по .out сломалась
> -- насколько помню, по той баге мне вообще не получалось хоть какой-то
> пакет publican собрать.
> 
> Впрочем, теперь видно, что перл опять сегфолтнулся:
> 
> ---
> [i586] + /usr/bin/perl -CDAS -I /usr/src/RPM/BUILD/Publican-v4.3.2/blib/lib /usr/src/RPM/BUILD/Publican-v4.3.2/blib/script/publican build --formats=html-desktop --publish --langs=en-US --common_config=/usr/src/RPM/BUILD/Publican-v4.3.2/blib/datadir --common_content=/usr/src/RPM/BUILD/Publican-v4.3.2/blib/datadir/Common_Content --nocolours
> [i586] /usr/src/tmp/rpm-tmp.44662: line 110: 764217 Segmentation fault      XML_CATALOG_FILES=$dir/catalog /usr/bin/perl -CDAS -I $dir/blib/lib $dir/blib/script/publican build --formats=html-desktop --publish --langs=en-US --common_config="$dir/blib/datadir" --common_content="$dir/blib/datadir/Common_Content" --nocolours
> --- http://git.altlinux.org/tasks/266271/logs/events.2.1.log
> 
> Можно попробовать учинить ещё одну сессию отладки (кстати, wd@
> подумывал в team, насколько помню) -- но если перл работал,
> а затем вдруг начал падать, то сломать могли и компилятор,
> этот вариант тоже есть смысл прокопать.

$ grep ^publican beehive/stats/Sisyphus-i586/ftbfs-since
publican	1572700846
$ date -d @1572700846
Sat Nov  2 13:20:46 UTC 2019

Не понимаю, зачем гадать, когда можно было просто сравнить 2 файла:
beehive/logs/Sisyphus/i586/archive/2019/1101/success/publican-4.3.2-alt3_13.zst
beehive/logs/Sisyphus/i586/archive/2019/1102/error/publican-4.3.2-alt3_13.zst
и, если нужно,
archive/repo/sisyphus/date/2019/11/01/files/list/src.list.xz
archive/repo/sisyphus/date/2019/11/02/files/list/src.list.xz

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

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


-- 
ldv

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Michael Shigorin]

On Sun, Feb 14, 2021 at 12:41:01AM +0300, Dmitry V. Levin wrote:
> Не понимаю, зачем гадать, когда можно было просто сравнить 2 файла:

Сравнивать по этой гипотезе нужно сборки perl, очевидно.

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

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Dmitry V. Levin]

On Sun, Feb 14, 2021 at 12:44:07AM +0300, Michael Shigorin wrote:
> On Sun, Feb 14, 2021 at 12:41:01AM +0300, Dmitry V. Levin wrote:
> > Не понимаю, зачем гадать, когда можно было просто сравнить 2 файла:
> 
> Сравнивать по этой гипотезе нужно сборки perl, очевидно.

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


-- 
ldv

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Andrey Savchenko]

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

On Sun, 14 Feb 2021 00:50:37 +0300 Dmitry V. Levin wrote:
> On Sun, Feb 14, 2021 at 12:44:07AM +0300, Michael Shigorin wrote:
> > On Sun, Feb 14, 2021 at 12:41:01AM +0300, Dmitry V. Levin wrote:
> > > Не понимаю, зачем гадать, когда можно было просто сравнить 2 файла:
> > 
> > Сравнивать по этой гипотезе нужно сборки perl, очевидно.
> 
> Очевидно, сравнивать нужно то, что поменялось, а не то, что оставалось
> неизменным.  Если perl не поменялся, то зачем сравнивать его сборки?

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

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

Best regards,
Andrew Savchenko

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

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Dmitry V. Levin]

On Sun, Feb 14, 2021 at 02:33:13AM +0300, Andrey Savchenko wrote:
> On Sun, 14 Feb 2021 00:50:37 +0300 Dmitry V. Levin wrote:
> > On Sun, Feb 14, 2021 at 12:44:07AM +0300, Michael Shigorin wrote:
> > > On Sun, Feb 14, 2021 at 12:41:01AM +0300, Dmitry V. Levin wrote:
> > > > Не понимаю, зачем гадать, когда можно было просто сравнить 2 файла:
> > > 
> > > Сравнивать по этой гипотезе нужно сборки perl, очевидно.
> > 
> > Очевидно, сравнивать нужно то, что поменялось, а не то, что оставалось
> > неизменным.  Если perl не поменялся, то зачем сравнивать его сборки?
> 
> Затем, что на новом коде может выявиться ошибка неизменной сборки
> perl, которая ранее не наблюдалась на старом коде.

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

> Вообще, если что-то сегфолтится, то нужно исправлять это что-то,
> а не его пользователя (даже если входные данные некорректны
> приложение не должно падать).

Приложение может сегфолтиться по самым разным причинам, и не всегда
исправлять надо именно это приложение, хотя оно обычно первое под
подозрением.

Так выглядел в логе сегфолт от последней Мишиной сборки:
perl[123456]: segfault at fffffffb ip 00000000f7ab60f4 sp 00000000ffb72d50 error 4 in libc-2.32.so[f7a4d000+128000]
(попытка чтения по адресу -5).

В p9 падает точно также, как и в Сизифе, хотя версии perl и gcc сильно различаются.
$ grep ^publican beehive/stats/p9-i586/ftbfs-since
publican	1573386786
$ date -d @1573386786
Sun Nov 10 11:53:06 UTC 2019

FTBFS в p9 появился сразу после того, как то самое изменение
было скопировано из Сизифа в p9.

Есть желающие поотлаживать?


-- 
ldv

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Ivan A. Melnikov]

On Sun, Feb 14, 2021 at 03:10:40AM +0300, Dmitry V. Levin wrote:
> On Sun, Feb 14, 2021 at 02:33:13AM +0300, Andrey Savchenko wrote:
> > On Sun, 14 Feb 2021 00:50:37 +0300 Dmitry V. Levin wrote:
> > > On Sun, Feb 14, 2021 at 12:44:07AM +0300, Michael Shigorin wrote:
> > > > On Sun, Feb 14, 2021 at 12:41:01AM +0300, Dmitry V. Levin wrote:
> > > > > Не понимаю, зачем гадать, когда можно было просто сравнить 2 файла:
> > > > 
> > > > Сравнивать по этой гипотезе нужно сборки perl, очевидно.
> > > 
> > > Очевидно, сравнивать нужно то, что поменялось, а не то, что оставалось
> > > неизменным.  Если perl не поменялся, то зачем сравнивать его сборки?
> > 
> > Затем, что на новом коде может выявиться ошибка неизменной сборки
> > perl, которая ранее не наблюдалась на старом коде.
> 
> Ошибка может выявиться вообще где угодно, но для начала надо хотя бы
> понимать, что поменялось, а что осталось неизменным.  Для этого нужен
> мантейнер, сама ошибка искаться не станет, как мы видим.
> 
> > Вообще, если что-то сегфолтится, то нужно исправлять это что-то,
> > а не его пользователя (даже если входные данные некорректны
> > приложение не должно падать).
> 
> Приложение может сегфолтиться по самым разным причинам, и не всегда
> исправлять надо именно это приложение, хотя оно обычно первое под
> подозрением.
> 
> Так выглядел в логе сегфолт от последней Мишиной сборки:
> perl[123456]: segfault at fffffffb ip 00000000f7ab60f4 sp 00000000ffb72d50 error 4 in libc-2.32.so[f7a4d000+128000]
> (попытка чтения по адресу -5).
> 
> В p9 падает точно также, как и в Сизифе, хотя версии perl и gcc сильно различаются.
> $ grep ^publican beehive/stats/p9-i586/ftbfs-since
> publican	1573386786
> $ date -d @1573386786
> Sun Nov 10 11:53:06 UTC 2019
> 
> FTBFS в p9 появился сразу после того, как то самое изменение
> было скопировано из Сизифа в p9.
> 
> Есть желающие поотлаживать?

Поотлаживать я что-то не успеваю, но можно попробовать угадать:

id=266293 locked=no shared=no fail_early=yes test_only=yes repo=sisyphus owner=iv state=TESTED try=1 iter=1 age=0w build_time=2021-Feb-14/06:51:17
 100:libxml2.git=2.9.10-alt6
 200:srpm=publican-4.3.2-alt3_13.1.src.rpm

Была (и наверное есть) проблема в libxlst, которую исправляли
в libxml2:
- https://gitlab.gnome.org/GNOME/libxml2/-/issues/132
- https://github.com/shlomif/perl-XML-LibXSLT/issues/2

Я забирал это исправление на mipsel, но (позор на мою седую бороду)
совершенно забыл отправить его мейнтейнеру libxml2.

Завтра ещё кое-что проверю и, если возражений не поступит,
отправлю #266293 в Сизиф, @qa там прав хватает.

-- 
  wbr,
    iv m.

Re: [devel] уровни сопровождения пакетов

[Mikhail Novosyolov]

13.02.2021 15:02, Anton Farygin пишет:
> On 13.02.2021 14:52, Dmitry V. Levin wrote:
>> On Sat, Feb 13, 2021 at 02:40:30PM +0300, Anton Farygin wrote:
>> [...]
>>> Я не вижу разницы между цельнотянутыми пакетами и пакетами у
>>> перегруженных ментейнеров, особенно если объём изменений по сравнению с
>>> апстримом был приличный.
>> Однако ты видишь эту разницу, потому что она очевидна.
>> Бывают разные уровни сопровождения.  Пакеты, у которых вообще нет
>> сопровождающих, находятся на самом низком уровне сопровождения.
>> Их разрушает любое изменение окружения, к которому они не могут
>> адаптироваться самостоятельно.
>
> Да, я категорически против тянутых скриптами пакетов. Тут ты прав.

Против прям вообще всех тянутых скриптами пакетов? А каковы альтернативы по сборке, например, java вместо утягивания [и при необходимости взаимодействия с апстримом, откуда тянется]?

А в чем разница между утянутым пакетом и родным, в котором никто не собирается соблюдать политику упаковки библиотек?

[devel] [JT] Re: уровни сопровождения пакетов

[Michael Shigorin]

On Sun, Feb 14, 2021 at 02:22:25PM +0300, Mikhail Novosyolov wrote:
> > Да, я категорически против тянутых скриптами пакетов.
> > Тут ты прав.
> Против прям вообще всех тянутых скриптами пакетов?

Прям вижу сотню вакансий из Обнинска -- CPAN собирать, ага.
Притом вручную, а не этими вашими rpm-hasher-girar!

PS: по существу: "тянутое скриптами" -- заведомые заготовки;
если у кого есть время, внимание, компетенция и желание --
вперёд; хоть с нуля, хоть рашпилем пройти сделанное в шляпе.

PPS: и RPMS.contrib, да.

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

Re: [devel] [JT] Re: уровни сопровождения пакетов

[Mikhail Novosyolov]

14.02.2021 16:05, Michael Shigorin пишет:
> On Sun, Feb 14, 2021 at 02:22:25PM +0300, Mikhail Novosyolov wrote:
>>> Да, я категорически против тянутых скриптами пакетов.
>>> Тут ты прав.
>> Против прям вообще всех тянутых скриптами пакетов?
> Прям вижу сотню вакансий из Обнинска -- CPAN собирать, ага.
> Притом вручную, а не этими вашими rpm-hasher-girar!

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

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

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

Сейчас же ботами вполне качественно собрана такая гора пакетов, которую вручную никогда не соберете и не сможете ту же freeipa собирать в сертифицируемом виде, не пойму, почему на viy@ такие бочки катятся.

>
> PS: по существу: "тянутое скриптами" -- заведомые заготовки;
> если у кого есть время, внимание, компетенция и желание --
> вперёд; хоть с нуля, хоть рашпилем пройти сделанное в шляпе.
>
> PPS: и RPMS.contrib, да.
>

Re: [devel] [JT] Re: уровни сопровождения пакетов

[Vladimir D. Seleznev]

On Sun, Feb 14, 2021 at 06:17:19PM +0300, Mikhail Novosyolov wrote:
> 
> 14.02.2021 16:05, Michael Shigorin пишет:
> > On Sun, Feb 14, 2021 at 02:22:25PM +0300, Mikhail Novosyolov wrote:
> >>> Да, я категорически против тянутых скриптами пакетов.
> >>> Тут ты прав.
> >> Против прям вообще всех тянутых скриптами пакетов?
> > Прям вижу сотню вакансий из Обнинска -- CPAN собирать, ага.
> > Притом вручную, а не этими вашими rpm-hasher-girar!
> 
> Думаю, даже если бы была сотня вакансий для сборщиков CPAN, NPM, pypi
> и пр. вручную, это не увеличило бы качество репозитория относительно
> имеющегося, обсулуживаемого ботами Игоря.
> 
> Во-первых, пакет из Федоры проверен на работоспособность путем
> использования как минимум в качестве сборочной зависимости в Федоре
> и/или КШ, а значит он с очень большой вероятностью хотя бы минимально
> работоспособен.

Пакет из Федоры проверен на работоспособность на репозитории Федоры.
Увы, почему-то в Федоре не тестируют свои пакеты на работоспособность в
Сизифе.

> Во-вторых, столько много вакансий - это большая текучка кадров и
> низкая общая квалификация, а значит низкое качество ручной сборки и
> сопровождения таких пакетов в целом.
> 
> Сейчас же ботами вполне качественно собрана такая гора пакетов,
> которую вручную никогда не соберете и не сможете ту же freeipa
> собирать в сертифицируемом виде, не пойму, почему на viy@ такие бочки
> катятся.


-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [JT] Re: уровни сопровождения пакетов

[Anton Farygin]

On 14.02.2021 18:17, Mikhail Novosyolov wrote:
> Сейчас же ботами вполне качественно собрана такая гора пакетов, которую вручную никогда не соберете и не сможете ту же freeipa собирать в сертифицируемом виде, не пойму, почему на viy@ такие бочки катятся.

freeipa, как раз, собирается вручную с очень активным участием её 
ментейнера в апстримной разработке.

А вот с цельнотянутыми пакетами вылезающие проблемы предлагаете 
репортить в RH ?

Re: [devel] [JT] Re: уровни сопровождения пакетов

[Anton Farygin]

On 14.02.2021 16:05, Michael Shigorin wrote:
> On Sun, Feb 14, 2021 at 02:22:25PM +0300, Mikhail Novosyolov wrote:
>>> Да, я категорически против тянутых скриптами пакетов.
>>> Тут ты прав.
>> Против прям вообще всех тянутых скриптами пакетов?
> Прям вижу сотню вакансий из Обнинска -- CPAN собирать, ага.
> Притом вручную, а не этими вашими rpm-hasher-girar!

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

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

>
> PS: по существу: "тянутое скриптами" -- заведомые заготовки;
> если у кого есть время, внимание, компетенция и желание --
> вперёд; хоть с нуля, хоть рашпилем пройти сделанное в шляпе.

нет, часто тянутое уже никто не берёт. Не знаю почему.

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

Re: [devel] [JT] Re: уровни сопровождения пакетов

[Mikhail Novosyolov]

14.02.2021 18:51, Anton Farygin пишет:
> On 14.02.2021 18:17, Mikhail Novosyolov wrote:
>> Сейчас же ботами вполне качественно собрана такая гора пакетов, которую вручную никогда не соберете и не сможете ту же freeipa собирать в сертифицируемом виде, не пойму, почему на viy@ такие бочки катятся.
>
> freeipa, как раз, собирается вручную с очень активным участием её ментейнера в апстримной разработке.
dogtag (pki-core) собирается с помощью огромного дерева пакетов, собранными ботами, и является зависимостью FreeIPA. И в Альте это дерево пакетов, если раскрутить все зависимости зависимостей, в т.ч. сборочных, не полностью само себя пересобирает из исходников, в процессе участвуют подложенные jar-ы.
>
> А вот с цельнотянутыми пакетами вылезающие проблемы предлагаете репортить в RH ?
Мне тоже интересен вопрос взаимодействия с апстримом утягиваемых пакетов, с java-пакетами скоро попробую.

Re: [devel] [JT] Re: уровни сопровождения пакетов

[Anton Farygin]

On 14.02.2021 18:59, Mikhail Novosyolov wrote:
> 14.02.2021 18:51, Anton Farygin пишет:
>> On 14.02.2021 18:17, Mikhail Novosyolov wrote:
>>> Сейчас же ботами вполне качественно собрана такая гора пакетов, которую вручную никогда не соберете и не сможете ту же freeipa собирать в сертифицируемом виде, не пойму, почему на viy@ такие бочки катятся.
>> freeipa, как раз, собирается вручную с очень активным участием её ментейнера в апстримной разработке.
> dogtag (pki-core) собирается с помощью огромного дерева пакетов, собранными ботами, и является зависимостью FreeIPA. И в Альте это дерево пакетов, если раскрутить все зависимости зависимостей, в т.ч. сборочных, не полностью само себя пересобирает из исходников, в процессе участвуют подложенные jar-ы.

Я давно уже не следил за java, но мне всегда казалось что Игорь её 
собирает не из федоры.

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

>> А вот с цельнотянутыми пакетами вылезающие проблемы предлагаете репортить в RH ?
> Мне тоже интересен вопрос взаимодействия с апстримом утягиваемых пакетов, с java-пакетами скоро попробую.

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

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

Re: [devel] [JT] Re: уровни сопровождения пакетов

[Mikhail Novosyolov]

14.02.2021 19:04, Anton Farygin пишет:
> On 14.02.2021 18:59, Mikhail Novosyolov wrote:
>> 14.02.2021 18:51, Anton Farygin пишет:
>>> On 14.02.2021 18:17, Mikhail Novosyolov wrote:
>>>> Сейчас же ботами вполне качественно собрана такая гора пакетов, которую вручную никогда не соберете и не сможете ту же freeipa собирать в сертифицируемом виде, не пойму, почему на viy@ такие бочки катятся.
>>> freeipa, как раз, собирается вручную с очень активным участием её ментейнера в апстримной разработке.
>> dogtag (pki-core) собирается с помощью огромного дерева пакетов, собранными ботами, и является зависимостью FreeIPA. И в Альте это дерево пакетов, если раскрутить все зависимости зависимостей, в т.ч. сборочных, не полностью само себя пересобирает из исходников, в процессе участвуют подложенные jar-ы.
>
> Я давно уже не следил за java, но мне всегда казалось что Игорь её собирает не из федоры.
Основа из Федоры, в Федоре с ней уже несколько лет бардак, поэтому Игорь сам ее подтягивает до вменяемого состояния, насколько я понимаю.
>
> Всё-таки пакеты из федоры могут у нас или не работать, или работать не так, как задумывали ментейнеры этих пакетов в федоре. Поэтому, конечно, лучше собирать всё дерево самостоятельно, понимая что, как и в какой момент делается (ну или разбираясь в этом по ходу дела).
>
>>> А вот с цельнотянутыми пакетами вылезающие проблемы предлагаете репортить в RH ?
>> Мне тоже интересен вопрос взаимодействия с апстримом утягиваемых пакетов, с java-пакетами скоро попробую.
>
> если я не ошибаюсь, то в случае с java пакетами можно писать генератор, который будет использовать систему сборки, принятую в java.
>
> т.е. - собирать почти так, как считает нужным для сборки апстрим.

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

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Aleksey Novodvorsky]

вс, 14 февр. 2021 г. в 09:54, Ivan A. Melnikov <iv@altlinux.org>:
>
> On Sun, Feb 14, 2021 at 03:10:40AM +0300, Dmitry V. Levin wrote:
> > On Sun, Feb 14, 2021 at 02:33:13AM +0300, Andrey Savchenko wrote:
> > > On Sun, 14 Feb 2021 00:50:37 +0300 Dmitry V. Levin wrote:
> > > > On Sun, Feb 14, 2021 at 12:44:07AM +0300, Michael Shigorin wrote:
> > > > > On Sun, Feb 14, 2021 at 12:41:01AM +0300, Dmitry V. Levin wrote:
> > > > > > Не понимаю, зачем гадать, когда можно было просто сравнить 2 файла:
> > > > >
> > > > > Сравнивать по этой гипотезе нужно сборки perl, очевидно.
> > > >
> > > > Очевидно, сравнивать нужно то, что поменялось, а не то, что оставалось
> > > > неизменным.  Если perl не поменялся, то зачем сравнивать его сборки?
> > >
> > > Затем, что на новом коде может выявиться ошибка неизменной сборки
> > > perl, которая ранее не наблюдалась на старом коде.
> >
> > Ошибка может выявиться вообще где угодно, но для начала надо хотя бы
> > понимать, что поменялось, а что осталось неизменным.  Для этого нужен
> > мантейнер, сама ошибка искаться не станет, как мы видим.
> >
> > > Вообще, если что-то сегфолтится, то нужно исправлять это что-то,
> > > а не его пользователя (даже если входные данные некорректны
> > > приложение не должно падать).
> >
> > Приложение может сегфолтиться по самым разным причинам, и не всегда
> > исправлять надо именно это приложение, хотя оно обычно первое под
> > подозрением.
> >
> > Так выглядел в логе сегфолт от последней Мишиной сборки:
> > perl[123456]: segfault at fffffffb ip 00000000f7ab60f4 sp 00000000ffb72d50 error 4 in libc-2.32.so[f7a4d000+128000]
> > (попытка чтения по адресу -5).
> >
> > В p9 падает точно также, как и в Сизифе, хотя версии perl и gcc сильно различаются.
> > $ grep ^publican beehive/stats/p9-i586/ftbfs-since
> > publican      1573386786
> > $ date -d @1573386786
> > Sun Nov 10 11:53:06 UTC 2019
> >
> > FTBFS в p9 появился сразу после того, как то самое изменение
> > было скопировано из Сизифа в p9.
> >
> > Есть желающие поотлаживать?
>
> Поотлаживать я что-то не успеваю, но можно попробовать угадать:
>
> id=266293 locked=no shared=no fail_early=yes test_only=yes repo=sisyphus owner=iv state=TESTED try=1 iter=1 age=0w build_time=2021-Feb-14/06:51:17
>  100:libxml2.git=2.9.10-alt6
>  200:srpm=publican-4.3.2-alt3_13.1.src.rpm
>
> Была (и наверное есть) проблема в libxlst, которую исправляли
> в libxml2:
> - https://gitlab.gnome.org/GNOME/libxml2/-/issues/132
> - https://github.com/shlomif/perl-XML-LibXSLT/issues/2
>
> Я забирал это исправление на mipsel, но (позор на мою седую бороду)
> совершенно забыл отправить его мейнтейнеру libxml2.
>
> Завтра ещё кое-что проверю и, если возражений не поступит,
> отправлю #266293 в Сизиф, @qa там прав хватает.

Иван, большое спасибо.

Rgrds, Алексей

Re: [devel] [girar-builder@altlinux: [#265890] FAILED del=publican]

[Konstantin Lepikhov]

Hi Michael!

On 02/13/2021, at 03:08:34 PM you wrote:

> Я говорю, что ты лукав в этой претензии -- применительно
> к вопросам по postfix отсылаешь в LATER с невнятным
> "наломал дров" (причём я склонен такой характеристике
> всё равно доверять в этом случае), а применительно
Как тот, кто тоже приложил руку к сборке postfix, могу сказать, что наезд
не засчитан - postfix просто работает(tm). Да, он старой версии и,
наверное, что-то не умеет, но 90% функционала там до сих пор достаточно в
90% случаев.

Я смотрел возможность собрать 3.x, там очень много работы потому что:
- у postfix опять поменялась система сборки, а у нас она и так была
  нестандартная, т.е. всю сборку надо переписывать и переосмысливать
  по-новой.
- там теперь lookup dicts из debian, т.е. наш патч (который был очень
  красив по релизации вместо костылей апрстрима) нужно переписывать и
  скорее всего отдавать в апстрим, т.к. тянуть это самостоятельно очень
  непродуктивно
- на postfix накладывается 100+ патчей (как наших, так и owl), я не
  уверен, что кто-то так аудитил код 3.x

Т.е. это как ядро (которое уже не торт) или bind (который тоже уже не
торт), наша уникальная фишка дистрибутива. Если мы хотим с этой фишкой
расстаться ради красивой версии "как в апстриме/у всех", пожалуйста, но
тогда зачем выбирать ALT? :)  

-- 
WBR et al.