Bug 15376 - [FR] выделение не-полиси-специфичной части
Summary: [FR] выделение не-полиси-специфичной части
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: sisyphus_check (show other bugs)
Version: unstable
Hardware: all Linux
: P2 major
Assignee: Dmitry V. Levin
QA Contact: qa-sisyphus
URL:
Keywords:
: 15377 (view as bug list)
Depends on:
Blocks: 15619 34231 16550
  Show dependency tree
 
Reported: 2008-04-16 15:10 MSD by Evgeny Sinelnikov
Modified: 2020-05-16 19:02 MSK (History)
17 users (show)

See Also:


Attachments
Примерный патч для подстановки run_sisyphus_check() (3.46 KB, patch)
2011-05-13 23:46 MSK, Evgeny Sinelnikov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Evgeny Sinelnikov 2008-04-16 15:10:38 MSD
Необходимо добавить поддержку различных (не только @altlinux) доменов в адресах
электронной почты. Дело в том, что hasher, по умолчанию использует
sisyphus_check. А текущий sisyphus_check выполняет проверки почтовых имён с
пробитыми строками "altlinux". Грубо говоря, это означает невозможность
нормального использования hasher пользователями, которые не являются
разработчиками altlinux и пишут в changelog'ах свои электронные почтовые адреса.

Пример исправления выглядит так:
http://git.etersoft.ru/people/sin/packages/?p=sisyphus_check.git;a=blobdiff;f=sisyphus_check/sisyphus_check;h=81b5cff152da3ff4b529206b22224e670bd55dd3;hp=f55becd2d515ea1a498a40955b2d55613109c669;hb=89463da76a2837f517293d6e6bccb4cead0c5f21;hpb=19fb15dfcc32aabff3837d1d6c8133eaf135dc51"

Это не совсем универсальный вариант исправления, вероятно стоит его расширить...
Comment 1 Mikhail Gusarov 2008-04-16 15:14:58 MSD
sisyphus_check на то и sisyphus_check, чтобы проверять, пройдёт ли пакет в 
Sisyphus :)
Comment 2 Alexey Gladkov 2008-04-16 15:23:53 MSD
Если ослабить эту проверку, то такие пакеты смогут попасть в сизиф т.к.
sisyphus_check участвует в incominger.

AFAIK это INVALID
Comment 3 Mikhail Gusarov 2008-04-16 15:32:19 MSD
*** Bug 15377 has been marked as a duplicate of this bug. ***
Comment 4 Mikhail Gusarov 2008-04-16 15:34:58 MSD
Нет, баг не invalid - никто не требует держать на incoming'е sisyphus_check, 
сконфигурированный по умолчанию.

Вопрос в том, чтобы чётко разделить проверки, которые делаются исключительно 
для репозитория Sisyphus (вероятно, это только проверка почтового адреса, ибо 
определяющей чертой Sisyphus является ALT Linux Team) и те, которые делаются 
для всех потенциальных пользователей технологии Sisyphus.

После чего отключить первые по умолчанию (и включить обратно в обработке 
пакетов в incoming).
Comment 5 Alexey Gladkov 2008-04-16 15:51:07 MSD
Насколько я помню, в сизифе как в подписях, так и в changelog должны быть адреса
@altlinux (в sisyphus_check есть такая проврека check_gpgname()). Именно это и
проверяет sisyphus_check.

sisyphus_check проверяет пакет на соответствие полиси о публикации пакетов в
сизифе. Если делать эти провреки переопределяемыми, то в них нет смысла.

Чтобы реализовать то что описано в этой баге, нужно разделить sisyphus_check на
отдельные проверки и сделать из них два пакета sisyphus_check и rpm_check. Это
не сложно, но это другая история.
Comment 6 Evgeny Sinelnikov 2008-04-16 16:04:01 MSD
(In reply to comment #5)
> Насколько я помню, в сизифе как в подписях, так и в changelog должны быть адреса
> @altlinux (в sisyphus_check есть такая проврека check_gpgname()). Именно это и
> проверяет sisyphus_check.
> 
(In reply to comment #1)
> sisyphus_check на то и sisyphus_check, чтобы проверять, пройдёт ли пакет в 
> Sisyphus :)
> 

Оно конечно верно, но тогда нужно делать интерфейс для создания своих
etersoft_check, armd_check и т.д.

(In reply to comment #2)
> Если ослабить эту проверку, то такие пакеты смогут попасть в сизиф т.к.
> sisyphus_check участвует в incominger.
> 
> AFAIK это INVALID

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

Хотя тут может быть нет вовсе никакой проблемы, особенно если будет введена
корпоративная регистрация :) Хотя я думаю, что понятия  ALT Linux Team и
сторонние разработчики, использующие в своих решениях сизиф не стоит
смешивать... Поскольку первое - это добрая воля, а второе может быть работой. А
как вы думаете?

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

Даю бизнес-идею... :) Многие компании предоставляют всякого рода партнёрства и
сертификаты. В данном случае можно говорить о предоставлении сертификатов на
разработку сизифа сторнними компаниями, с добавлением их доменов в sisyphus_check...

(In reply to comment #4)
> Нет, баг не invalid - никто не требует держать на incoming'е sisyphus_check, 
> сконфигурированный по умолчанию.
> 
> Вопрос в том, чтобы чётко разделить проверки, которые делаются исключительно 
> для репозитория Sisyphus (вероятно, это только проверка почтового адреса, ибо 
> определяющей чертой Sisyphus является ALT Linux Team) и те, которые делаются 
> для всех потенциальных пользователей технологии Sisyphus.
> 
> После чего отключить первые по умолчанию (и включить обратно в обработке 
> пакетов в incoming).
> 

Тут, вероятно, стоит либо предоставить вариант настроек для sisyphus_check, если
конечно рассматривать этот инструмент не только для проверки на прохождение
пакетов в Сизиф.

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

(In reply to comment #5)
> Насколько я помню, в сизифе как в подписях, так и в changelog должны быть адреса

Это уже вроде пофиксили...

> @altlinux (в sisyphus_check есть такая проврека check_gpgname()). Именно это и
> проверяет sisyphus_check.
> 
> sisyphus_check проверяет пакет на соответствие полиси о публикации пакетов в
> сизифе. Если делать эти провреки переопределяемыми, то в них нет смысла.
> 
> Чтобы реализовать то что описано в этой баге, нужно разделить sisyphus_check на
> отдельные проверки и сделать из них два пакета sisyphus_check и rpm_check. Это
> не сложно, но это другая история.

Ну, не совсем... Как быть с hasher'ом всё равно непонятно... Если вас так
смущает название sisyphus_check, то может быть его переименовать в rpm_check?
Comment 7 Mikhail Gusarov 2008-04-16 16:08:51 MSD
(In reply to comment #5)

> sisyphus_check проверяет пакет на соответствие полиси о публикации пакетов в
> сизифе. Если делать эти провреки переопределяемыми, то в них нет смысла.

В этом случае баг в том, что hasher цепляет sisyphus_check по умолчанию, ибо 
hasher не только для сизифа предназначен.
Comment 8 Evgeny Sinelnikov 2008-04-16 16:12:18 MSD
(In reply to comment #7)
> (In reply to comment #5)
> 
> > sisyphus_check проверяет пакет на соответствие полиси о публикации пакетов в
> > сизифе. Если делать эти провреки переопределяемыми, то в них нет смысла.
> 
> В этом случае баг в том, что hasher цепляет sisyphus_check по умолчанию, ибо 
> hasher не только для сизифа предназначен.
> 

На самом деле sisyphus_check, как механизм, крайне удобен... Вот бы им ещё
воспользоваться не только на сборки пакетов в Сизиф... Иначе нужно будет или
оторвать все проверки, или свой такой же писать, в котором домен другой
указан... Глупо как-то получается...
Comment 9 Alexey Gladkov 2008-04-16 16:21:20 MSD
(In reply to comment #6)
> В ином случае по факту hasher становится инструментом исключительно для
> владельцев @altlinux адресов, что для сторонних разработчиков, использующих
> сизиф может быть не приемлемо. Все просто обязаны получить @altlinux адреса...

Стоп-стоп. Причём тут hasher ?

вы про ключи:
$ hsh --help |grep sisyphus
  --no-sisyphus-check-in[=LIST]     do not run sisyphus_check input tests
  --no-sisyphus-check[=LIST]        do not run sisyphus_check tests
  --no-sisyphus-check-out[=LIST]    do not run sisyphus_check output tests

знаете ?
 
> Ну, не совсем... Как быть с hasher'ом всё равно непонятно... Если вас так
> смущает название sisyphus_check, то может быть его переименовать в rpm_check?

Его не нужно переименовывать т.к. то что он делает отражено в названии. Он не
делает абстрактных проверок. Он проверяет на соотвествие полиси.
Comment 10 Evgeny Sinelnikov 2008-04-16 16:39:06 MSD
(In reply to comment #9)
> (In reply to comment #6)
> > В ином случае по факту hasher становится инструментом исключительно для
> > владельцев @altlinux адресов, что для сторонних разработчиков, использующих
> > сизиф может быть не приемлемо. Все просто обязаны получить @altlinux адреса...
> 
> Стоп-стоп. Причём тут hasher ?
> 

Потому, что сторонние разработчики тоже хотят использовать все проверки, за
одним исключением, чтобы была поддержка их электронных почтовых адресов... Но в
sisyphus_check эти имена пробиты хардкодом. Можно конечно каждому делать свой
вариант MYCOMPANY_check и скармливать его hasher'у... Но как-то оно не очень, да
и sisyphus_check к hasher'у прибит...

> вы про ключи:
> $ hsh --help |grep sisyphus
>   --no-sisyphus-check-in[=LIST]     do not run sisyphus_check input tests
>   --no-sisyphus-check[=LIST]        do not run sisyphus_check tests
>   --no-sisyphus-check-out[=LIST]    do not run sisyphus_check output tests
> 
> знаете ?
>  

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

> > Ну, не совсем... Как быть с hasher'ом всё равно непонятно... Если вас так
> > смущает название sisyphus_check, то может быть его переименовать в rpm_check?
> 
> Его не нужно переименовывать т.к. то что он делает отражено в названии. Он не
> делает абстрактных проверок. Он проверяет на соотвествие полиси.
> 

Хорошо, тогда хотелось бы видеть не просто варианты отключения отдельных
элементов полиси, а ещё и небольших расширений...
Comment 11 Alexey Gladkov 2008-04-16 16:57:31 MSD
(In reply to comment #10) 
> и sisyphus_check к hasher'у прибит...

Вот поэтому я и считаю что эта бага INVALID. Нужно повесить на hasher FR о том
чтобы иметь возможность переопределять программу проверки.

> Знаем... Но как-то оно не очень... отрывать полезные проверки из-за того, что
> имена почтовых доменов гвоздями прибиты...

Они прибиты по объективой причине - это полиси. И повторюсь, "прибито" там не
только это.

Все эти проблемы не относятся к sisyphus_check ... ты говоришь про использование
hasher не для сизифа.
Comment 12 Evgeny Sinelnikov 2008-04-16 17:43:27 MSD
(In reply to comment #11)
> (In reply to comment #10) 
> > и sisyphus_check к hasher'у прибит...
> 
> Вот поэтому я и считаю что эта бага INVALID. Нужно повесить на hasher FR о том
> чтобы иметь возможность переопределять программу проверки.
 
То есть чтобы собрать пакет в hasher, по уму, нужно будет сначала собрать пакет
с программой проверки, которую в hasher собрать будет нельзя... Простой такой
бутстрап... Но вопрос в том, а нужен ли он? И как быть при этом с зависимостями?
От чего теперь будет зависеть hasher? От виртуального пакета abstract_check,
который предоставляют все программы проверки?

> > Знаем... Но как-то оно не очень... отрывать полезные проверки из-за того, что
> > имена почтовых доменов гвоздями прибиты...
> 
> Они прибиты по объективой причине - это полиси. И повторюсь, "прибито" там не
> только это.
 
По не менее объективной причине у меня возник вопрос о том, что бы отбить
прибитое и переместить в настройку...

> Все эти проблемы не относятся к sisyphus_check ... ты говоришь про использование
> hasher не для сизифа.

Я говорю о том, что для сборки пакетов с помощью hasher сторонняя компания
вынуждена, в общем случае, чтобы не иметь лишних проблем, включать своих
сотрудников в ALT Linux Team. Это не плохо, но не удобно и не очевидно...
Comment 13 Alexey Gladkov 2008-04-16 18:01:37 MSD
(In reply to comment #12)
> То есть чтобы собрать пакет в hasher, по уму, нужно будет сначала собрать пакет
> с программой проверки, которую в hasher собрать будет нельзя... Простой такой
> бутстрап... Но вопрос в том, а нужен ли он? И как быть при этом с зависимостями?

Я говорил о том чтобы в hasher добавить ключ --sisyphus-check=PROG.

Я ход твоих мыслей понять не могу (хотя стараюсь). О каком бутстрапе речь?! ...
если тебе нужна другая программа проверки, то ты её будешь указывать в качестве
PROG (или в конфиге). Если ты хочешь эту программу запаковать - отлично. Пакуй и
клади в сизиф. Если это не нужно, то используй с локальной машины.

Ещё раз, собрать в hasher можно и без провреки через sisyphus-check, поэтому нет
таких "программой проверки, которую в hasher собрать будет нельзя".

> От чего теперь будет зависеть hasher? От виртуального пакета abstract_check,
> который предоставляют все программы проверки?

$ rpmquery -R hasher hasher-priv |grep sisyphus_check |wc -l
0

> По не менее объективной причине у меня возник вопрос о том, что бы отбить
> прибитое и переместить в настройку...

Я вижу у нас с тобой сильно разные понятия о реализации полиси. Я не понимаю что
такое настраиваемое полиси.

> Я говорю о том, что для сборки пакетов с помощью hasher сторонняя компания
> вынуждена, в общем случае, чтобы не иметь лишних проблем, включать своих
> сотрудников в ALT Linux Team. Это не плохо, но не удобно и не очевидно...

Не должна. Но если компании так хочется, то конечно можно :)

P.S.
Предлагаю не спамить мантейнера этим диалогом.
Reassign => legion
Comment 14 Evgeny Sinelnikov 2008-04-16 18:46:26 MSD
(In reply to comment #13)
> Я говорил о том чтобы в hasher добавить ключ --sisyphus-check=PROG.
> Я ход твоих мыслей понять не могу (хотя стараюсь). О каком бутстрапе речь?! 

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

> если тебе нужна другая программа проверки, то ты её будешь указывать в качестве
> PROG (или в конфиге). Если ты хочешь эту программу запаковать - отлично. Пакуй и
> клади в сизиф. Если это не нужно, то используй с локальной машины.
> 
> Ещё раз, собрать в hasher можно и без провреки через sisyphus-check, поэтому нет
> таких "программой проверки, которую в hasher собрать будет нельзя".
 
Ход моих мыслей состоит в том, что для смены логики проверки не требовалось
проделывать излишний набор действий... Для того, чтобы получить программу
проверки первое, что мне приходит в голову - это форкнуть по-быстрому
sisyphus_check изменив в нём несколько забитых строк. Всё, что я смогу
посоветовать, желающим собрать в хешере свои пакеты - это оторвать проверки или
сделать ещё один форк sisyphus_check для себя... Ты думаешь это правильно?


> > От чего теперь будет зависеть hasher? От виртуального пакета abstract_check,
> > который предоставляют все программы проверки?
> 
> $ rpmquery -R hasher hasher-priv |grep sisyphus_check |wc -l
> 0
> 

хм.... а это что?
$ grep pkg_build_list /usr/bin/hsh-sh-functions
pkg_build_list='basesystem rpm-build>=0:4.0.4-alt21
kernel-headers-common>=0:1.1.4-alt1 sisyphus_check>=0:0.7.3 time'

Сам он его не тянет, но сборочная среда должна вытягивать пакет со вполне
определённым интерфейсом. Держать два таких интерфейса и согласовывать их есть
ли резон? Нужно будет составлять некий консольный-API, для программ проверки.
Кто это будет описывать? И всё только для того чтобы заменить несколько строк...

> > По не менее объективной причине у меня возник вопрос о том, что бы отбить
> > прибитое и переместить в настройку...
> 
> Я вижу у нас с тобой сильно разные понятия о реализации полиси. Я не понимаю что
> такое настраиваемое полиси.
 
Это означает, что я готов следовать технологическим полиси в сизифе, но
организационные полиси, вроде имён электронных почтовых адресов, хочу суметь
настроить под себя... И мне не хочется для это поддерживать свой форк
sisyphus_check.


> > Я говорю о том, что для сборки пакетов с помощью hasher сторонняя компания
> > вынуждена, в общем случае, чтобы не иметь лишних проблем, включать своих
> > сотрудников в ALT Linux Team. Это не плохо, но не удобно и не очевидно...
> 
> Не должна. Но если компании так хочется, то конечно можно :)

Чтобы не создавать себе лишней работы она вынуждена на это идти. Причём это не
очень хорошо...

Comment 15 Alexey Gladkov 2008-04-16 19:17:17 MSD
(In reply to comment #14)
> Речь о том, что в рамках sisyphus_check новый пакет проверки собрать будет
> нельзя, поскольку, он собирается по правилам, которые прописаны в нём самом...

Если ты хочешь построить свой репозиторий с нуля, то да ... тебе предётся
бутсрапить репозиторий вместе с полиси о добавлении туда пакетов.
 
> сделать ещё один форк sisyphus_check для себя... Ты думаешь это правильно?

Этот форк называется новое полиси - sin_check. И это полиси только случайно
похоже на полиси сизифа (из-за того что полиси сизифа послужило основой), потому
что в момент времени N sin_check может начать противоречить sisyphus_check.
Собственно, они уже противоречат из-за этого этот тред.

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

Решение я тебе тоже предложил: давай попросим кого-нибудь разделить
sisyphus_check на утилиту и отдельные проверки. Таким оборазом ты сможешь
уменьшить дублирование пересекающихся проверок и sisyphus_check останется
неизменной реализацией полиси.

> Кто это будет описывать? И всё только для того чтобы заменить несколько 

sisyphus_check старая утилита и интерфейс уже устаканился давно.

> Это означает, что я готов следовать технологическим полиси в сизифе, но
> организационные полиси, вроде имён электронных почтовых адресов, хочу суметь
> настроить под себя... 

Ты в этой фразе противоречишь сам себе. Нельзя следовать полиси сизифа и при
этом менять его пункты под себя. Это будет не полиси сизифа, а твоё.
Comment 16 Mikhail Gusarov 2008-04-16 20:01:50 MSD
(In reply to comment #15)
> Решение я тебе тоже предложил: давай попросим кого-нибудь разделить
> sisyphus_check на утилиту и отдельные проверки.

И получится почти repocop :) Может, пора их уже сливать? :)
Comment 17 viy 2008-04-16 20:19:10 MSD
> > Решение я тебе тоже предложил: давай попросим кого-нибудь разделить
> > sisyphus_check на утилиту и отдельные проверки.
> 
> И получится почти repocop :) Может, пора их уже сливать? :)
 
$ du -sh /tmp/.private/igor/repocop 
608M    /tmp/.private/igor/repocop

sisyphus_chack не может себе такого позволить.
Comment 18 Alexey Gladkov 2008-04-16 20:27:16 MSD
(In reply to comment #16)
> И получится почти repocop :) Может, пора их уже сливать? :)
 
Я думаю можно внести туда часть проверок из repocop. У sisyphus_check есть
некоторые ограничения.

(In reply to comment #17)
> 608M    /tmp/.private/igor/repocop

Ой, а что так много ?!
Comment 19 viy 2008-04-16 20:33:07 MSD
> Ой, а что так много ?!
-rw-r--r-- 1 igor igor 392K Апр 15 17:08 altlinux-alternatives.db
-rw-r--r-- 1 igor igor 581M Апр 15 17:09 rpm.db

Плата за то, что можно делать такие тесты, как
# file vs. dir conflict
select a.FILENAME, a.pkgid, b.pkgid FROM rpm_files as a, rpm_files as b WHERE
a.pkgid<>b.pkgid and a.filename=b.filename and a.filemode & 16384 > 0 and
b.filemode & 16384=0;
Comment 20 Evgeny Sinelnikov 2008-04-16 20:38:17 MSD
(In reply to comment #15)
[...]
> Я считаю правильным разделение таких программ на разные пакеты. Как я уже
> говорил, единственная неприятность в том, что дублируется код.
> 
> Решение я тебе тоже предложил: давай попросим кого-нибудь разделить
> sisyphus_check на утилиту и отдельные проверки. Таким образом ты сможешь
> уменьшить дублирование пересекающихся проверок и sisyphus_check останется
> неизменной реализацией полиси.
 
Ну, сам подход мне нравится за исключением одного момента. Вместо настроек для
некого общего набора проверок. У меня, по умолчанию, требуется создание новой
программы проверки. ИМХО, это плохо и не правильно.

Сейчас же ситуация такая...
1) hasher смену пакета с программой проверки не поддерживает... Тут ведь нужно
не просто программу проверки, нужен новый пакет, в котором будет лежать новая
программа проверки. Так что передавать хешеру нужно не только имя программы, но
и имя пакета, где она лежит...
2) sisyphus_check целый и его ещё нужно разбивать... Я готов попросить кого
угодно, но получается, что мне он нужен сейчас причём вместе с переделанным хешером.

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


> > Кто это будет описывать? И всё только для того чтобы заменить несколько 
> 
> sisyphus_check старая утилита и интерфейс уже устаканился давно.

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


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

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

(In reply to comment #18)
> (In reply to comment #16)
> > И получится почти repocop :) Может, пора их уже сливать? :)
>  
> Я думаю можно внести туда часть проверок из repocop. У sisyphus_check есть
> некоторые ограничения.
> 

Итак, я понял, что принципиально проблема разрешима, но решать её мы будет
неограниченно долго... И мне это не нравится... Да и устаканивание консольного
API для разных вариантов программ проверок скорее похоже на эмуляцию
sisyphus_check. А ведь sisyphus_check ещё будет развиваться... Вот уже слияние с
repocop наметилось...

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

В общем сейчас я вынужден делать хитрый форк... :)
Comment 21 Slava Semushin 2008-04-17 09:24:04 MSD
Так, а (что-то вроде) hsh --no-sisyphus-check=packager, не подходит?
Comment 22 Evgeny Sinelnikov 2008-04-17 11:24:24 MSD
(In reply to comment #21)
> Так, а (что-то вроде) hsh --no-sisyphus-check=packager, не подходит?

туда нужно добавить ещё changelog, gpg, и gpgname ибо строка altlinux в имени
домена прибита в sisyphus_check.

И вопрос был не в том чтобы это всё оторвать и выключить, а в том, что hasher,
использующий sisyphus_check, позволял собирать пакеты со своими именами email'ов
и со своими подписями... Вариант с добавлением опции выбирающей программу
проверки в hasher нормален...

У меня вот вопрос про разбивание пакета sisyphus_check на функциональные
элементы и объединение с repocop. А насколько сложно организовать
sisyphus_check, как программу проверки использующую отдельные модули от repocop?
Требуется ли для эффективной организации sisyphus_check на основе модулей
repocop модифицировать интерфейс самих модулей?

И ещё, по этому вопросу сделать ещё один баг или этот оставим? Или отложим? Для
себя пока я придумал только вариант с форком sisyphus_check в виде другого
пакета... Не хочется на этом надолго останавливаться, поскольку для меня это
вспомогательная задача, я склонен скорее отказаться от проверок на первом этапе,
чем посвятить всё время их исправлению.

Comment 23 Michael Shigorin 2008-04-17 11:31:01 MSD
(In reply to comment #11)
> Нужно повесить на hasher FR о том  чтобы иметь возможность переопределять 
> программу проверки.
[...]
> Они прибиты по объективой причине - это полиси. И повторюсь, "прибито" там не
> только это.
--strict?

> Все эти проблемы не относятся к sisyphus_check ... ты говоришь про 
> использование hasher не для сизифа.
Я тоже спотыкался о подобное (и молча решал), но действительно хотелось бы
видеть более организованный фреймворк.

Мне кажется, у нас выходит такой список:

- hasher и sisyphus_check используются в одинаковом виде и конфигурации:
  + разработчиками Sisyphus (участниками ALT Linux Team)
  + для работы incoming
  + расширяющимся кругом людей, не входящих в ALT [*]
- hasher по умолчанию вызывает sisyphus_check в "строгом" режиме

Предлагаю один из вариантов выхода -- договориться о файловом флажке (записи в
~/.rpmmacros, ...), который используется участниками команды и в сборочной среде
для incoming с целью означить "строгий" режим; при этом те, кого он касается,
имеют возможность быть в курсе вопроса или уже не иметь надобности в проверке
домена в силу уже заполненных ~/.rpmmacros и ~/.hasher/config, а те, кого не
касается -- получают возможность использовать те же технологии без не имеющей
отношения к ним мороки вроде hsh --no-sisyphus-check=gpgname.

Вроде бы на такой вариант ровно ложится и эта мысль:
> Решение я тебе тоже предложил: давай попросим кого-нибудь разделить
> sisyphus_check на утилиту и отдельные проверки. Таким образом ты сможешь
> уменьшить дублирование пересекающихся проверок и sisyphus_check останется
> неизменной реализацией полиси.

[*] далеко не всегда им есть какой-либо смысл входить в команду -- например,
если пакет разрабатывается in-house, специфичен или вообще не подлежит
распространению; у меня есть минимум один такой текущий случай
Comment 24 Michael Shigorin 2008-04-17 11:33:47 MSD
(In reply to comment #23)
> > давай попросим кого-нибудь разделить sisyphus_check на утилиту 
> > и отдельные проверки.
BTW тогда можно попробовать так:

hasher зависит от rpm_check
sisyphus_check зависит от rpm_check
hasher проверяет, доступен ли скрипт sisyphus_check, и если да -- использует
его, а если нет -- фолбэкается на rpm_check

Тогда проверяемость полиси регулируется установкой пакета sisyphus_check, но это
site-wide.
Comment 25 Michael Shigorin 2008-04-17 12:26:02 MSD
(In reply to comment #22)
> У меня вот вопрос про разбивание пакета sisyphus_check на функциональные
> элементы и объединение с repocop. А насколько сложно организовать
> sisyphus_check, как программу проверки использующую отдельные модули от repocop?
Не хочешь попробовать копнуть в сторону rpm_check, который бы получалось
использовать из sisyphus_check?
Comment 26 viy 2008-04-17 12:36:57 MSD
(In reply to comment #22)
> Требуется ли для эффективной организации sisyphus_check на основе модулей
> repocop модифицировать интерфейс самих модулей?
в принципе, все тесты без состояния можно было бы гонять из - под sisyphus_check,
вопрос в том, куда их устанавливать.
Comment 27 Alexey Gladkov 2008-04-17 12:47:09 MSD
(In reply to comment #23)
> --strict?

И что будет делать sisyphus_check с этим ключём, если речь идёт об изменении в
его проверок (как их состава, так и того что они проверяют)? 

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

На чём ты спотыкался? На то что тебе нужен hasher, но пакет не проходит наше
полиси? Если да, то не применяй проверку полиси.

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

Хитрец. Тогда кто угодно сможет отключить проверку :) А тогда в этом нет смысла.
Comment 28 Alexey Gladkov 2008-04-17 12:50:26 MSD
(In reply to comment #26)
> в принципе, все тесты без состояния можно было бы гонять из - под sisyphus_check,
> вопрос в том, куда их устанавливать.

В sisyphus_check есть некоторые ограничения связанные с безопасностью т.к. он
может выполняться в хост системе. Не любые запросы rpm к пакету возможны.
Comment 29 Michael Shigorin 2008-04-17 13:10:23 MSD
(In reply to comment #27)
> На чём ты спотыкался? На то что тебе нужен hasher, но пакет не проходит наше
> полиси? Если да, то не применяй проверку полиси.
На том, что пакет предсказуемо не пройдёт весь комплект проверок (поскольку
сборщик -- не в ALT Linux Team), но был бы полезен общий (назовём ALT
Linux-specific) субкомплект.

check_fhs(), check_perms() и дальше по тексту.

> > Предлагаю один из вариантов выхода -- договориться о файловом флажке
> > (записи в ~/.rpmmacros, ...), который используется участниками команды
> > и в сборочной среде
> Хитрец. Тогда кто угодно сможет отключить проверку :)
Где -- на localhost?  Там и так желающие могут отключить что угодно, т.е. не
мера безопасности.  В incoming?  Ой сомневаюсь, что "кто угодно" при грамотно
выбранном методе.

> А тогда в этом нет смысла.
Насколько понимаю -- мы с sin@ не за дырку для обхода полиси, а за расширение
аудитории hasher естественным и разумным по количеству проблем путём.

Наверное, начать стоит с переформулирования этой баги в "нужен пакет/скрипт с
[неспецифичными для полиси ALT Linux]/[общеполезными на платформе ALT Linux]
проверками" и отдельного FR на hasher, когда будет что предлагать в качестве
варианта для не-участников ALT Linux Team.
Comment 30 Alexey Gladkov 2008-04-17 15:35:47 MSD
Дайте мне несколько дней на подумать над кодом. Я попробую сделать
sisyphus_check более реюзабильным. Если конечно мантейнер не против.
Comment 31 Michael Shigorin 2008-04-17 17:05:54 MSD
Спасибо :)
Comment 32 Alexey Gladkov 2008-04-21 16:16:20 MSD
Вот что получилось:

http://git.altlinux.org/people/legion/packages/sisyphus_check.git?p=sisyphus_check.git;a=shortlog;h=split

Проверки и инициализация вынесены отдельно. Есть определённый API для проверок.
Для самого sisyphus_check тоже появился плюс: теперь все проверки выполняются в
subshell. Таким образом проверка не сможет навредить другим проверкам. За всё
нужно платить. Эта реализация чуть медленнее чем текущая из сизифа.

Зависимости между проверками реализовывать не стал т.к. сейчас порядок проверок
исходит из утилиты.
Comment 33 Michael Shigorin 2008-04-21 22:34:44 MSD
Вау, выглядит намного красивше той здоровенной простыни :-)
Comment 34 Alexey Gladkov 2008-04-22 15:08:12 MSD
(In reply to comment #33)
> Вау, выглядит намного красивше той здоровенной простыни :-)

Я доработал реализацию. Убрал жёсткий список проверок и почистил чуть-чть код.
Теперь все проверки из каталога будут подхватываться.

Теперь есть бонус для разных @packages. Есть возможность расширять базовые
проверки sisyphus_check для соответствующего полиси.

Даже не знаю хорошо это или плохо. Как бы не стали писать конфликтующие проверки.

Нужно подумать.
Comment 35 Dmitry V. Levin 2008-05-11 23:30:16 MSD
В Сизиф ушёл sisyphus_check-0.8.0-alt1.
Однако поставленную задачу настройки себя он не решает.
Собственно говоря, я перечитал весь тред и ничего конкретного на эту тему не
нашёл (не считая хака в самом начале).
Comment 36 Michael Shigorin 2008-05-11 23:55:31 MSD
(In reply to comment #35)
> В Сизиф ушёл sisyphus_check-0.8.0-alt1.
> Однако поставленную задачу настройки себя он не решает.
Ничего, это уже часть решения.
Comment 37 viy 2008-08-08 22:01:29 MSD
эта же проблема всплыла и при запуске из repocop (#16550)
Comment 38 viy 2008-08-08 22:02:46 MSD
(кросспост)
я написал пускатель sisyphus_check под repocop.

Первый вывод - не все тесты надо запускать.
вот типичный пример.

$ sisyphus_check --verbose --files /home/repocop/Sisyphus/files/noarch/RPMS/pngbook-1.0-alt1.noarch.rpm
/home/repocop/Sisyphus/files/noarch/RPMS/pngbook-1.0-alt1.noarch.rpm: rpmsign failed
sisyphus_check: check-gpg ERROR: package signatures violation
grep: /usr/lib/rpm/*-files.req.list: No such file or directory

check-gpg был явно лишний.

подводя итоги:

похоже sisyphus_check надо серьезно порезать.
тесты нужно выделить отдельно, и не в один пакет, а 
хотя бы в 3:

tests-genertic
общего характера 
(например, могут применяться в Etersoft для проверки своих приватных пакетов)

tests-sisyphus
sisyphus specific

tests-experimental
(не запускаются в incoming)
Comment 39 viy 2008-08-08 22:39:41 MSD
еще характерный пример

fail    FTSC-20020412-alt2.noarch       sisyphus_check failed:  /home/repocop/Sisyphus/files/noarch/RPMS/FTSC-20020412-alt2.noarch.rpm: unacceptable BUILDHOST: altair.office.altlinux.ru sisyphus_check: check-buildhost ERROR: unacceptable non-hasher buildhost name /home/repocop/Sisyphus/files/noarch/RPMS/FTSC-20020412-alt2.noarch.rpm: rpmsign failed sisyphus_check: check-gpg ERROR: package signatures violation grep: /usr/lib/rpm/*-files.req.list: No such file or directory;
Comment 40 Sir Raorn 2008-08-09 14:32:59 MSD
(In reply to comment #39)
> fail    FTSC-20020412-alt2.noarch       sisyphus_check failed:  /home/repocop/Sisyphus/files/noarch/RPMS/FTSC-20020412-alt2.noarch.rpm:
> unacceptable BUILDHOST: altair.office.altlinux.ru sisyphus_check: check-buildhost ERROR: unacceptable non-hasher buildhost name
> /home/repocop/Sisyphus/files/noarch/RPMS/FTSC-20020412-alt2.noarch.rpm: rpmsign failed sisyphus_check: check-gpg ERROR: package signatures

Я некрофил и полон сил?  Пакет собирался когда про hasher ещё даже не думали, подписан проэкспайреным ключом.  Тест правильно ругается (а пакет надо фтопку).
Comment 41 Evgeny Sinelnikov 2009-03-20 03:09:52 MSK
Хочу вернуться в этому вопросу... Можно ли как решить вопрос с указанием проверок по умолчанию?

Вопреки текущему названию баги "[FR] выделение не-полиси-специфичной части", изначально речь шла о выделении именно полиси-специфичной части.

Поскольку sisyphus_check уже стал именем нарицательным выкидывать все пакеты от него зависящие (#15619 здесь нет ни одного комментария) и переделывать приложения его использующие гораздо более накладно, чем выделить политику в отдельный, заменяемый пакет.

Может быть так стоит разрешить вопрос о возможности изменения ограничений?
Проблемными вопросами являются:
1) проверка имён релизов,
2) электронных адресов сборщиков пакетов,
3) имён сборочных хостов,
4) gpg подписей.

Последний момент требует вообще отдельного рассмотрения, поскольку каталог/usr/lib/alt-gpgkeys довольно жёстко прибит в пакете rpm к макросу %_internal_gpg_path, что в свою очередь не позволяет расширить список поиска системных публичных ключей не меняя пакет alt-gpgkeys.

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

Предлагаю определится с этим вопросом. Либо все желающие делать решения на базе сизифа и бранчей должны вступать в альт и использовать только общепринятные средства совместной сборки, либо даётся возможность влиять на политики стандартными средствами.
Comment 42 Alexey Gladkov 2009-03-20 09:55:22 MSK
Проверки и так вынесены отдельно, что делает возможным использовать их в других программах проверки. Выделение политик считаю неправильным в рамках пакета SISYPHUS_check, поэтому делать этого не буду.
Comment 43 Evgeny Sinelnikov 2009-03-30 20:19:46 MSD
Ну, да... значит вместо того, чтобы научиться по разному использовать инструмент, на который другие уже давно опираются де-факто, вы предлагаете бегать и просить всех эти инструменты поправить? Или править их самому? Отличный вариант...

Кстати, поправить тоже мало, кто соглашается... В первую очередь это #15619.

Прежде всего я хочу получить возможность реализовать свой набор политик, а не один из ответственных в этом не заинтересован.
Comment 44 Vitaly Lipatov 2009-10-17 16:56:13 MSD
Я предлагаю выступить в devel@ с предложением из комментария #41.
Может быть более широкое обсуждение даст какое-то решение проблемы.

Хотя разве не было бы решением отключение неподходящих проверок, и добавление своих проверок, раз уж подхватываются все проверки из каталога?
Comment 45 Michael Shigorin 2009-11-12 19:30:59 MSK
Поскольку "вы оба правы" (tm) -- и legion@, и sin@ -- то хотелось бы услышать мнение пользователей sisyphus_check, в первую очередь разработчиков hasher, насчёт переименования пакета (и, возможно, утилиты) sisyphus_check в что-либо из списка:
- altlinux_check (IMHO случай LINUX@Etersoft сюда уже не вписывается);
- package-check
- alt-rpm-lint
- <ваш вариант>
Comment 46 Dmitry V. Levin 2009-11-12 21:01:22 MSK
(In reply to comment #45)
> Поскольку "вы оба правы" (tm) -- и legion@, и sin@ -- то хотелось бы услышать
> мнение пользователей sisyphus_check, в первую очередь разработчиков hasher,
> насчёт переименования пакета (и, возможно, утилиты) sisyphus_check в что-либо
> из списка:
> - altlinux_check (IMHO случай LINUX@Etersoft сюда уже не вписывается);
> - package-check
> - alt-rpm-lint
> - <ваш вариант>

Параметризуйте слово sisyphus_check, которое используется в run_sisyphus_check(), в чём проблема-то?
Comment 47 Evgeny Sinelnikov 2011-05-13 22:43:11 MSK
(В ответ на комментарий №46)
> Параметризуйте слово sisyphus_check, которое используется в
> run_sisyphus_check(), в чём проблема-то?

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

Хочется следующего:
1) добавить в список подключенных репозиториев дополнительный
2) собрать туда, к примеру, etersoft_check
3) внести в систему набор такую настройку, которая по умолчанию будет запускать etersoft_check вместо sisyphus_check

Прежде всего требуется, чтобы hasher использовал заданную 

Что же имеется в виду под параметризацией run_sisyphus_check(), если он выглядит следующим образом?
run_sisyphus_check()
{
        local dir="$1" no_check="$2" add_gpg="${3:-}"

        [ -n "$no_check" ] ||
                no_check="$no_sisyphus_check"
        [ "$no_check" != all ] || return 0

        if [ -n "$no_check" ]; then
                [ -z "$add_gpg" ] ||
                        no_check="$no_check,gpg"
        else
                no_check=gpg
        fi

        create_entry_header
        cat >>"$entry" <<__EOF__
sisyphus_check --no-check="$(quote_shell "$no_check")" "$dir"
__EOF__

        wlimit_time_elapsed=$wlimit_time_long wlimit_time_idle=$wlimit_time_long wlimit_bytes_written=$wlimit_bytes_out \
            chrootuid2 </dev/null &&
                verbose "$sname: sisyphus_check passed." ||
                fatal "$sname: sisyphus_check failed."
} # run_sisyphus_check

У меня есть задумка, что имело в виду под такой параметризацией. Приведу это в виде патча отдельным файлом.
Comment 48 Evgeny Sinelnikov 2011-05-13 23:46:01 MSK
Created attachment 4930 [details]
Примерный патч для подстановки run_sisyphus_check()

В этом патче я привожу изменения предполагаемые для подстановки run_sisyphus_check(), которые параметризуют слово sisyphus_check.

Изменения не отлажены и в них не хватает проверки передаваемого имени файла в путях поиска файлов.

Хотелось бы уточнить, этот ли вариант "параметризации слова sisyphus_check, которое используется в run_sisyphus_check()" имелся в виду?

Если да, то не ясно как добиться запуска фиксированного приложения для проверки (например, sisyphus_check vs etersoft_check), по умолчанию?
Comment 49 Dmitriy Kruglikov 2011-05-23 16:52:31 MSK
(В ответ на комментарий №46)
> Параметризуйте слово sisyphus_check, которое используется в
> run_sisyphus_check(), в чём проблема-то?

Есть предложение на заменять sisyphus_check, а дополнить его следующими возможности:
1) В /etc/sisyphus_check/ поместить файл no_check, в котором перечислить проверки, которые выполнять не нужно. 
Таким образом, не привлекая параметры вызова sisyphus_check можно влиять на его работу.
Если такого файла нет, или он пустой, то выполняется весь набор правил и политик ALTLinux.
2) В /etc/sisyphus_check/ поместить файл с правилами проверки подписей и почтовых адресов.
В нем прописан домен domain.com, следовательно и сборщик, и автор записи в changelog будут из этого домена, 
равно как и @altlinux ...
Если такого файла нет, или он пустой, то выполняется весь набор правил и политик ALTLinux.

Так как sisyphus_check выполняется в chroot, то единственный правильный путь размещения таких файлов 
- установка собственного пакета при построении окружения hasher-ом.

Пусть это будет какой-то $distributor-sisyphus_check-rules, с конфликтами на любой другой подобный.
Comment 50 Evgeny Sinelnikov 2011-06-05 20:44:35 MSK
(В ответ на комментарий №49)
> (В ответ на комментарий №46)
> > Параметризуйте слово sisyphus_check, которое используется в
> > run_sisyphus_check(), в чём проблема-то?
> 
> Есть предложение на заменять sisyphus_check, а дополнить его следующими
> возможности:
[...]

Этот вопрос уже рассматривался. sisyphus_check - это не настраиваемая программа "by design". Поэтому-то и предложен вариант параметризации самой программы проверки.

Чуть выше, я предложил вариант решения. Хотелось бы понять принципиальное к нему отношение со стороны мейнтейнера hasher.

Появление, в последнем коммите sisyphus_check, вот такого дополнения, только усугубляет вопрос:
# Alright you Primitive Screwheads, listen up! You see this? This... 
# is my Serial! When you build a package for your precious Sisyphus, 
# pretty please, with sugar on to, remove this fucking Serial. 
# You got that? 
Serial: 1024

Проблема этого коммита заключается как раз в том, что для выхода из этой ситуации, я держал в репозитории исправленый sisyphus_check с расширенным списком ограничений (по сути, с поддержкой etersoft в дополнении к altlinux для почтовых адресов списках изменений и имени мейнтейнера, имён релизов и подписей). Чтобы этот вариант пакета приезжал по зависимостям, в нём было установлено Epoch: 1.
Comment 51 Evgeny Sinelnikov 2011-06-05 21:50:42 MSK
(В ответ на комментарий №50)
> (В ответ на комментарий №49)
> > (В ответ на комментарий №46)
> > > Параметризуйте слово sisyphus_check, которое используется в
> > > run_sisyphus_check(), в чём проблема-то?
> > 
> > Есть предложение на заменять sisyphus_check, а дополнить его следующими
> > возможности:
> [...]
> 
[...]
> Serial: 1024

Пожалуй, я поторпился объявить об этой проблеме... Пока что её не существует, поскольку это изменение в сизифе отсутствует... Репозиторий
git://git.altlinux.org/people/raorn/packages/sisyphus_check.git
с коммитом 8f24e086 (Tue May 17 2011 Alexey I. Froloff <raorn@altlinux.org> 1024:0.8.25.1-alt1) в Сизиф не уезжал...
Comment 52 Dmitry V. Levin 2011-06-06 22:14:06 MSK
(In reply to comment #51)
> Пожалуй, я поторпился объявить об этой проблеме... Пока что её не существует,
> поскольку это изменение в сизифе отсутствует... Репозиторий
> git://git.altlinux.org/people/raorn/packages/sisyphus_check.git
> с коммитом 8f24e086 (Tue May 17 2011 Alexey I. Froloff <raorn@altlinux.org>
> 1024:0.8.25.1-alt1) в Сизиф не уезжал...

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

Полагаю что эта история имеет мало общего с темой настоящего FR.
Comment 53 Evgeny Sinelnikov 2011-08-06 12:16:50 MSK
(В ответ на комментарий №52)
> Полагаю что эта история имеет мало общего с темой настоящего FR.

Ну, хорошо, но комментарий №48 явно позволяет продвинутся завершении исходного вопроса. Если sisyphus_check должен быть неизменен в своём поведении (комментарий №1), то нужно уметь использовать не только его, но и, например, etersoft_check.

Ключевым элементом, для такой замены, является возможность применения hasher с другими утилитами проверки - Ошибка 15619

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

Пример патча я привёл. Хотелось бы уточнить, стоит ли его завершать, или такая концептуальная схема пока ещё не принята?

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

Вариант с использованием произвольного скрипта проверки для hasher решает проблему, но строго фиксирует интерфейс самой утилиты проверки в том виде, в котором она сейчас используется и применяется (связка hasher вызывает утилиту sisyphus_check).
Comment 54 Michael Shigorin 2012-02-06 12:34:00 MSK
См. тж. http://lists.osdn.org.ua/wws/arc/linux-list/2012-02/msg00005.html
Comment 55 Michael Shigorin 2012-12-23 18:51:18 MSK
2 aen, ldv: есть мысль, что это был бы хороший штрих к седьмой платформе,
и желание его всё-таки сделать.
Comment 56 Michael Shigorin 2018-08-13 17:35:45 MSK
...ну или хоть к девятой...
Comment 57 Aleksey Cheusov 2020-05-15 17:45:04 MSK
Прошло 12 лет, а использовать свой почтовый адрес все еще нельзя. Это удивительно и печально одновременно. В чем вообще криминал при использованиии ЛЮБОГО почтового адреса, если в сизиф попадают только пакеты, ПОДПИСАННЫЕ разработчиком AltLinux? О чем, простите, эта многотомная дискуссия на 12 лет?
Comment 58 alexey.tourbin 2020-05-15 18:02:53 MSK
Предлагаю чтобы можно было использовать любой email адрес, но только чтобы домен у него был наш, русский. Например razrabotchik_linuxa@mail.ru.
Comment 59 Aleksey Cheusov 2020-05-15 18:23:39 MSK
(In reply to alexey.tourbin from comment #58)
> Предлагаю чтобы можно было использовать любой email адрес, но только чтобы
> домен у него был наш, русский. Например razrabotchik_linuxa@mail.ru.

Ну почему русский то? Вот я -- гражданин Беларуси -- хотел бы вести буквально несколько пакетов в AltLinux. Почтовый домен у меня  на немецком
сайте gmx.net, и я с ним уже больше 20 лет. Мне не хочется от
него отказываться, тем более что я не вижу для этого никаких разумных причин.
Таким неразумным требованием вы же сознательно отсекаете разработчиков из сопредельных стран. По-моему это очевидно как белый день. Я переформулирую свой вопрос: моя gpg подпись под коммитом перестает быть валидной, если я использую "немецкий" почтовый адрес или cheusov@netbsd.org?
Comment 60 Michael Shigorin 2020-05-15 18:26:08 MSK
Лёша, это Лёша юродствует.
Лёша, Лёша хакер не хуже тебя, уймись.
Comment 61 Aleksey Cheusov 2020-05-15 18:47:46 MSK
Да я не сомневаюсь. Фамилия и поделки на слуху. Видимо, нет у меня чувства юмора. Как бы там ни было по этому вопросу я умялся... На ближайшие 12 лет.
Comment 62 Alexey Gladkov 2020-05-15 19:39:09 MSK
Ну если только ldv@ что-то сделает по этой баге. Проглядев этот тред я не поменял своего мнения. Я считаю, что нужно в hasher добавить --check-prog=PROG и делайте на основе sisyphus_check какое угодно полиси.
Comment 63 Dmitry V. Levin 2020-05-15 21:24:57 MSK
(In reply to Aleksey Cheusov from comment #57)
> Прошло 12 лет, а использовать свой почтовый адрес все еще нельзя. Это
> удивительно и печально одновременно. В чем вообще криминал при
> использованиии ЛЮБОГО почтового адреса, если в сизиф попадают только пакеты,
> ПОДПИСАННЫЕ разработчиком AltLinux?

А какая разница для человека, какой из его почтовых адресов там написан?

> О чем, простите, эта многотомная дискуссия на 12 лет?

А кто её знает, она слишком большая, чтобы её сейчас читать. :)
Comment 64 Dmitry V. Levin 2020-05-15 21:27:04 MSK
(In reply to Alexey Gladkov from comment #62)
> Ну если только ldv@ что-то сделает по этой баге.

Это вряд ли.

> Проглядев этот тред я не поменял своего мнения.
> Я считаю, что нужно в hasher добавить
> --check-prog=PROG и делайте на основе sisyphus_check какое угодно полиси.

Если на это есть спрос, то можно так сделать.  Но я не вижу, чтобы на это был спрос.
Comment 65 Aleksey Cheusov 2020-05-15 21:59:11 MSK
(In reply to Dmitry V. Levin from comment #63)
> (In reply to Aleksey Cheusov from comment #57)
> > Прошло 12 лет, а использовать свой почтовый адрес все еще нельзя. Это
> > удивительно и печально одновременно. В чем вообще криминал при
> > использованиии ЛЮБОГО почтового адреса, если в сизиф попадают только пакеты,
> > ПОДПИСАННЫЕ разработчиком AltLinux?
> 
> А какая разница для человека, какой из его почтовых адресов там написан?

Да мало ли у людей бывают какие тараканы в голове? Кто-то например,
пользуется, gmail-ом, и из принципа не пользуется другой почтой, потому что
Google -- это корпорация Дора. Кому-то не хочется заводить новый ящик на каждый чих, и не надо его заставлять это делать.
Кто-то может кичиться свои университетским
адресом. Кто-то тщеславный и хочет легко гуглиться по щелчку пальцев вне зависимости от того, работает он Сегодня на AltLinux или нет, является он разработчиком AltLinux Сегодня и инет. Сегодня в AltLinux, а завтра, глядишь, в Nikia^wIntel или RedHat^wIBM работать пойдет. Кому-то нужно поменять свою "английскую" фамилию, переведенную транслитерированием с белорусского/украинского, и паспортному столу нужны свидетельства того, что
он известен Вот Прямо Всему Миру именно под такой фамилией и именем.
И так далее и тому подобное. Конкретно у меня много разных адресов, но использую я как правило один -- vle@gmx.net. В рассылках иногда использую cheusov@tut.by
просто потому, что smtp.gmx.net иногда отфутболивает мои письма, не знаю, почему, не разбирался, может, и рассосалась уже проблема давно.

Вопрос надо ставить другим образом. Какие Преимущества дает ограничение на почтовый ящик пакетировщика при условии, что git тэг подписан gpg ключем.
Мой ответ -- никаких. Какие преимущества дает --check-prog=PROG.
Мой ответ -- никаких. То есть, код есть, а функций он не несет никаких.
Пусть это десяток строк, но тем не менее.
В любом случае если forward почты настроен правильно, человек всегда найдется,
и не потеряется.

> > О чем, простите, эта многотомная дискуссия на 12 лет?
> 
> А кто её знает, она слишком большая, чтобы её сейчас читать. :)

Вопрос про подписанный gpg ключем тэг git-а -- выше ;-)
Comment 66 Dmitry V. Levin 2020-05-15 22:36:01 MSK
(In reply to Aleksey Cheusov from comment #65)
> Вопрос надо ставить другим образом. Какие Преимущества дает ограничение на
> почтовый ящик пакетировщика при условии, что git тэг подписан gpg ключем.
> Мой ответ -- никаких.

Это ограничение позволило реализовать проверку того, что последняя запись в %changelog соответствует подписи.
Comment 67 Alexey Gladkov 2020-05-15 22:38:39 MSK
(Ответ для Aleksey Cheusov на комментарий #65)
> > А какая разница для человека, какой из его почтовых адресов там написан?
> 
> Да мало ли у людей бывают какие тараканы в голове? Кто-то например,
> пользуется, gmail-ом, и из принципа не пользуется другой почтой, потому что
> Google -- это корпорация Дора. Кому-то не хочется заводить новый ящик на
> каждый чих, и не надо его заставлять это делать.

Причём тут отдельный почтовый ящик ? <name>@altlinux.org у многих является алиасом на их любимую почту.

У нас есть очень старое полиси, что для всех участников заводится почтовый алиас и он же должен быть в gpg-ключе. Собственно это и проверяет sisyphus_check.

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

Ответ: единообразие. Также по %changelog хорошо видно, когда и кто из команды начал собирать пакет. Кстати, я думаю, что какие-то скрипты точно сломаются если отойти от этого правила.

> Вопрос про подписанный gpg ключем тэг git-а -- выше ;-)

Это не всегда будет работать.
Comment 68 Aleksey Cheusov 2020-05-15 23:48:32 MSK
(In reply to Dmitry V. Levin from comment #66)
> (In reply to Aleksey Cheusov from comment #65)
> > Вопрос надо ставить другим образом. Какие Преимущества дает ограничение на
> > почтовый ящик пакетировщика при условии, что git тэг подписан gpg ключем.
> > Мой ответ -- никаких.
> 
> Это ограничение позволило реализовать проверку того, что последняя запись в
> %changelog соответствует подписи.

Для этого почтовый адрес @altlinux.org иметь совершенно не обязательно. Мой gpg ключ -- на адрес vle@gmx.net

Представим себе следующую ситуацию. Я -- очень продвинутый школьный учитель, или data scientist, который по работе столкнулся с AltLinux и желает в нем что-то улучить/исправить. Представим также, что я лично знаком с некоторым количеством разработчиков AltLinux, и они даже подписали мой gpg ключ. Мои действия: 1) клонирую gear репу к себе, я же продвинутый 2) вношу свои изменения, отлаживаюсь с помощью hasher-а, обновляю changes Своим почтовым адресом 3) Выставляю тэг, подписываю его Своим gpg ключем на тот же адрес 4) push-аю это дело на какой-нибудь github 5) Пишу письмо ldv@:"Дима, я вот тут наковырял чутка, проверь, все ли правильно, и пульни это, пожалуйста, в сизиф". При этом у меня нет ни малейшего желания становиться разработчиком АльтЛинукс, и ты знаешь, что *я* -- это действительно *я*. Казалось бы при чем тут почтовый адрес @altlinux.org?

Здесь в комментарии #6 12-летней давности есть очень смешной комментарий по поводу раздачи сертификатов за возможность работы с репозиторием Сизиф. По-моему он очень смешной. Мне во всяком случае понравился :-)
Comment 69 Aleksey Cheusov 2020-05-15 23:59:25 MSK
(In reply to Alexey Gladkov from comment #67)
> (Ответ для Aleksey Cheusov на комментарий #65)
> Причём тут отдельный почтовый ящик ? <name>@altlinux.org у многих является
> алиасом на их любимую почту.

Я в курсе, что такое почтовый алиас. Но даже он не нужен, это просто лишняя сущность, не добавляющая к системе ни-че-го. Такого нет ни в OpenSuSE, ни в NetBSD, ни в ArchLinux -- нигде насколько мне известно. Использовать или нет алиас конкретного дистрибутива или системы всегда (насколько я знаю) остается на совести разработчика. Для пакетировщиков -- вход свободен, см. ответ Диме Левину.

> У нас есть очень старое полиси, что для всех участников заводится почтовый
> алиас и он же должен быть в gpg-ключе. Собственно это и проверяет
> sisyphus_check.

Очень странный ненужный полиси IMNSHO.

> > Вопрос надо ставить другим образом. Какие Преимущества дает ограничение на
> > почтовый ящик пакетировщика при условии, что git тэг подписан gpg ключем.
> 
> Ответ: единообразие.

Это такой же сильный аргумент как мой "OpenSuSE прекрасно обходится без этого". Нет смысла здесь быть самобытным. Это не то место.

> Также по %changelog хорошо видно, когда и кто из
> команды начал собирать пакет.

Мой емейл известен по крайней мере одному человеку из Alt. Назовись я, скажем, vle@altlinux.org -- хрен его знает, тот я чел, о котором что-то известно или нет.

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

Это забавно, но очень плохо.

> > Вопрос про подписанный gpg ключем тэг git-а -- выше ;-)
> 
> Это не всегда будет работать.

Примеры, пожалуйста.
Comment 70 Alexey Gladkov 2020-05-16 00:43:29 MSK
(Ответ для Aleksey Cheusov на комментарий #69)
> Но даже он не нужен, это просто лишняя
> сущность, не добавляющая к системе ни-че-го. Такого нет ни в OpenSuSE, ни в
> NetBSD, ни в ArchLinux -- нигде насколько мне известно.

Ох. Ещё один кто пытается убедить аргументом "все так делают".

> Использовать или нет
> алиас конкретного дистрибутива или системы всегда (насколько я знаю)
> остается на совести разработчика.

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

> Это такой же сильный аргумент как мой "OpenSuSE прекрасно обходится без
> этого". Нет смысла здесь быть самобытным. Это не то место.

Ну вот и давайте и останемся каждый при своём.

> Мой емейл известен по крайней мере одному человеку из Alt. Назовись я,
> скажем, vle@altlinux.org -- хрен его знает, тот я чел, о котором что-то
> известно или нет.

Авторитет ничего про качество кода не говорит, уж извините.

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

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

> Примеры, пожалуйста.

https://mirror.yandex.ru/altlinux/Sisyphus/files/x86_64/RPMS/mozilla-plugin-adobe-flash-32.0.0.371-alt113.x86_64.rpm

Найдите пожалуйста git тэг этого пакета.
Comment 71 Dmitry V. Levin 2020-05-16 01:21:23 MSK
(In reply to Aleksey Cheusov from comment #69)
> (In reply to Alexey Gladkov from comment #67)
> > (Ответ для Aleksey Cheusov на комментарий #65)
> > Причём тут отдельный почтовый ящик ? <name>@altlinux.org у многих является
> > алиасом на их любимую почту.
> 
> Я в курсе, что такое почтовый алиас. Но даже он не нужен, это просто лишняя
> сущность, не добавляющая к системе ни-че-го. Такого нет ни в OpenSuSE, ни в
> NetBSD, ни в ArchLinux -- нигде насколько мне известно.

Я думаю, у нас это по аналогии с Debian было сделано, сильно задолго до OpenSuSE с ArchLinux.
Comment 72 AEN 2020-05-16 01:25:52 MSK
(Ответ для Dmitry V. Levin на комментарий #71)
> (In reply to Aleksey Cheusov from comment #69)
> > (In reply to Alexey Gladkov from comment #67)
> > > (Ответ для Aleksey Cheusov на комментарий #65)
> > > Причём тут отдельный почтовый ящик ? <name>@altlinux.org у многих является
> > > алиасом на их любимую почту.
> > 
> > Я в курсе, что такое почтовый алиас. Но даже он не нужен, это просто лишняя
> > сущность, не добавляющая к системе ни-че-го. Такого нет ни в OpenSuSE, ни в
> > NetBSD, ни в ArchLinux -- нигде насколько мне известно.
> 
> Я думаю, у нас это по аналогии с Debian было сделано, сильно задолго до
> OpenSuSE с ArchLinux.
+1
Насколько я помню, в изначальном Нюрнбергском SuSe было как в Debian. А Arch тогда еще не придумали.
Comment 73 AEN 2020-05-16 01:26:28 MSK
(Ответ для Dmitry V. Levin на комментарий #71)
> (In reply to Aleksey Cheusov from comment #69)
> > (In reply to Alexey Gladkov from comment #67)
> > > (Ответ для Aleksey Cheusov на комментарий #65)
> > > Причём тут отдельный почтовый ящик ? <name>@altlinux.org у многих является
> > > алиасом на их любимую почту.
> > 
> > Я в курсе, что такое почтовый алиас. Но даже он не нужен, это просто лишняя
> > сущность, не добавляющая к системе ни-че-го. Такого нет ни в OpenSuSE, ни в
> > NetBSD, ни в ArchLinux -- нигде насколько мне известно.
> 
> Я думаю, у нас это по аналогии с Debian было сделано, сильно задолго до
> OpenSuSE с ArchLinux.
+1
Насколько я помню, в изначальном Нюрнбергском SuSe было как в Debian. А Arch тогда еще не придумали.
Comment 74 Aleksey Cheusov 2020-05-16 01:27:42 MSK
(In reply to Alexey Gladkov from comment #70)
> (Ответ для Aleksey Cheusov на комментарий #69)
> Ох. Ещё один кто пытается убедить аргументом "все так делают".
> 
> > Использовать или нет
> > алиас конкретного дистрибутива или системы всегда (насколько я знаю)
> > остается на совести разработчика.
> 
> Да какая разница, что там у дистрибутива N ? У нас в дистрибутиве это не
> единственное, чего нет в других дистрибутивах. У нас hasher, gear а также
> некоторых требований к пакетам нет у других. Если вы считаете более
> правильным и удобным дистрибутив N, то включайтесь в дистрибутив N.

Я прекрасно знаю об особенностях AltLinux, поскольку вижу его на протяжении почти всей его жизни. И прекрасно знаю, что многие вещи в нем были реализованы впервые (или уж точно раньше, чем у многих) и знаю про вещи, уникальные и остающиеся таковыми до сих пор. Как у других -- это всего лишь
common practice. Отступать от нее может быть как вредно так и полезно.
В данном случае нет никаких ТЕХНИЧЕСКИХ предпосылок для этого.
Вы просто искусственно обрезаете потенциальных контрибьютеров, не желающих становиться полноценными ментейнерами и не желающих усложнять себе жизнь
получением новых почтовых адресов.

> > Это такой же сильный аргумент как мой "OpenSuSE прекрасно обходится без
> > этого". Нет смысла здесь быть самобытным. Это не то место.
> 
> Ну вот и давайте и останемся каждый при своём.

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

> > > Кстати, я думаю, что какие-то скрипты точно
> > > сломаются если отойти от этого правила.
> > 
> > Это забавно, но очень плохо.
> 
> Ну извините, что до появление git, gear и hasher, когда придумывались эти
> полиси мы забыли вас разыскать и попросить рассказать как правильно.

Сильно.

> > Примеры, пожалуйста.
> 
> https://mirror.yandex.ru/altlinux/Sisyphus/files/x86_64/RPMS/mozilla-plugin-
> adobe-flash-32.0.0.371-alt113.x86_64.rpm
> 
> Найдите пожалуйста git тэг этого пакета.

Maintainer: Cronbuild Service <cronbuild@altlinux.org>
Отличный пример. Очень в тему
Comment 75 Aleksey Cheusov 2020-05-16 01:35:22 MSK
(In reply to AEN from comment #72)
> (Ответ для Dmitry V. Levin на комментарий #71)
> > (In reply to Aleksey Cheusov from comment #69)
> > > (In reply to Alexey Gladkov from comment #67)
> > > > (Ответ для Aleksey Cheusov на комментарий #65)
> > > > Причём тут отдельный почтовый ящик ? <name>@altlinux.org у многих является
> > > > алиасом на их любимую почту.
> > > 
> > > Я в курсе, что такое почтовый алиас. Но даже он не нужен, это просто лишняя
> > > сущность, не добавляющая к системе ни-че-го. Такого нет ни в OpenSuSE, ни в
> > > NetBSD, ни в ArchLinux -- нигде насколько мне известно.
> > 
> > Я думаю, у нас это по аналогии с Debian было сделано, сильно задолго до
> > OpenSuSE с ArchLinux.
> +1
> Насколько я помню, в изначальном Нюрнбергском SuSe было как в Debian. А Arch
> тогда еще не придумали.

Тот самый Нюрнбергский SuSE -- мой первый Линукс, с которым я реально работал, а не поставил на поиграться. Тогда еще не было ни АльтЛинукса ни Мендрейка. Но дело же не в том, как было тогда, а в том, что с тех пор времена сильно изменились, Линукс стал сильно популярнее, и потенциальных пакетировщиков стало больше на три порядка. Если бы им только не ставить палки в колеса... ;-)
Сейчас же OpenSuSE OBS -- по удобству и простоте вхождения для новичков (игнорируем другие характеристики на секундочку) -- одна из лучших систем в отрасли.
Comment 76 AEN 2020-05-16 01:44:42 MSK
1. Хорошая аналогия с обрезанием, спасибо! 
2. Да, аргумент "а у них" лично у меня вызывает желание закончить разговор. 
3. Но я в него, тем не менее, вступил. Написано много, отвечу завтра по прочтении. 

Коллеги,давайте постараемся понять друг друга.
Comment 77 AEN 2020-05-16 01:51:16 MSK
Эх. 
Тот SuSe был первым дистрибутивом, в котором я (вместе со smi@) был контрибьютором. И мы обмывали эти адреса в Нюрнберге в 89м, кажется.
Comment 78 Alexey Gladkov 2020-05-16 02:41:10 MSK
(Ответ для Aleksey Cheusov на комментарий #74)
> >
> > Ну вот и давайте и останемся каждый при своём.
> 
> Обиделся :-)

Вы себя переоцениваете :)

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

> Сильно.

Сильно переоцениваете :)
 
> > > Примеры, пожалуйста.
> > 
> > https://mirror.yandex.ru/altlinux/Sisyphus/files/x86_64/RPMS/mozilla-plugin-
> > adobe-flash-32.0.0.371-alt113.x86_64.rpm
> > 
> > Найдите пожалуйста git тэг этого пакета.
> 
> Maintainer: Cronbuild Service <cronbuild@altlinux.org>
> Отличный пример. Очень в тему

Я это даже комментировать не буду.

Поскольку в этой баге не появилось новых доводов я устраняюсь из обсуждения до их появления. В #62, #64 сказано достаточно для этой итерации обсуждения.
Comment 79 AEN 2020-05-16 07:58:34 MSK
Мое мнение.
1. Репозиторий Sisyphus делаютт участники ALT Linux Team, получившие при вступлении адрес в доменах altlinux.* 
// Кстати, если есть желающие, altlinux.by пока свободен.
2. Ограничение sisypus_check для общей сборочницы Sisyohus на адреса altlinux мне представляется разумным, так как это сборочница не для всех, а для прошедших инициацию (вступление, крещение, обрезание etc.)
3. Наш софт. обеспечиваюший инфраструктуру сборки -- свободный проект, на его основе другая сборочница может быть развернута, использована и модифицирована вне проекта и вне всякого контроля или в привязке к проекту.
4. Естественно, в последнем варианте sisyphus_check может быть измене как угодно. Он может быть изменен и в пакете репозитория, но вот его настройки для сборочницы собственно проекта Sisyphus я бы не стал менять, см. п.2
5. Задача создания _продукта_, позволяющего создавать свои репозитории, синхронизируемые с Sisyphus актуальна. Есть, например ppa Ubuntu. Другое дело, что я бы не отдавал им безусловно ресурсы общей сборочницы, а предложил бы разворачивать ее локально. Запрос на такой продукт есть на рынке, в том числе от проприетарщиков, которые опасаются засветить свой код и хотели бы не делать общедоступными свои репозитории. Свободные же проекты могут нуждаться в возможности изменения настроек (в том числе sisyphus_check), экспериментов с пакетами, на которые в Sisyphus у них нет прав (недавно были дискуссия о user-agent в браузерах) etc. 
6. П.5 относится как к Sisyhus, так и к стабильным бранчам. Мы обсуждали этот п.5 с ldv@ и glebfm@ и договорились продолжить обсуждение. После согласования наших мнений и планов, мы их обнародуем.
Comment 80 alexey.tourbin 2020-05-16 19:02:00 MSK
(In reply to Aleksey Cheusov from comment #59)
> (In reply to alexey.tourbin from comment #58)
> > Предлагаю чтобы можно было использовать любой email адрес, но только чтобы
> > домен у него был наш, русский. Например razrabotchik_linuxa@mail.ru.
> 
> Ну почему русский то? Вот я -- гражданин Беларуси -- хотел бы вести
> буквально несколько пакетов в AltLinux. Почтовый домен у меня  на немецком
> сайте gmx.net, и я с ним уже больше 20 лет.

Если вы поддерживаете импортозамещение и не подвержены заразе западных ценностей, то думаю, что ваш адрес @gmx.net можно в порядке исключения признать относящимся к домену .ru.