sisyphus_check на то и sisyphus_check, чтобы проверять, пройдёт ли пакет в 
Sisyphus :)

Если ослабить эту проверку, то такие пакеты смогут попасть в сизиф т.к.
sisyphus_check участвует в incominger.

AFAIK это INVALID

*** Bug 15377 has been marked as a duplicate of this bug. ***

Нет, баг не invalid - никто не требует держать на incoming'е sisyphus_check, 
сконфигурированный по умолчанию.

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

После чего отключить первые по умолчанию (и включить обратно в обработке 
пакетов в incoming).

Насколько я помню, в сизифе как в подписях, так и в changelog должны быть адреса
@altlinux (в sisyphus_check есть такая проврека check_gpgname()). Именно это и
проверяет sisyphus_check.

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

Чтобы реализовать то что описано в этой баге, нужно разделить sisyphus_check на
отдельные проверки и сделать из них два пакета sisyphus_check и rpm_check. Это
не сложно, но это другая история.

(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?

(In reply to comment #5)

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

В этом случае баг в том, что hasher цепляет sisyphus_check по умолчанию, ибо 
hasher не только для сизифа предназначен.

(In reply to comment #7)
> (In reply to comment #5)
> 
> > sisyphus_check проверяет пакет на соответствие полиси о публикации пакетов в
> > сизифе. Если делать эти провреки переопределяемыми, то в них нет смысла.
> 
> В этом случае баг в том, что hasher цепляет sisyphus_check по умолчанию, ибо 
> hasher не только для сизифа предназначен.
> 

На самом деле sisyphus_check, как механизм, крайне удобен... Вот бы им ещё
воспользоваться не только на сборки пакетов в Сизиф... Иначе нужно будет или
оторвать все проверки, или свой такой же писать, в котором домен другой
указан... Глупо как-то получается...

(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?

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

(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?
> 
> Его не нужно переименовывать т.к. то что он делает отражено в названии. Он не
> делает абстрактных проверок. Он проверяет на соотвествие полиси.
> 

Хорошо, тогда хотелось бы видеть не просто варианты отключения отдельных
элементов полиси, а ещё и небольших расширений...

(In reply to comment #10) 
> и sisyphus_check к hasher'у прибит...

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

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

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

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

(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. Это не плохо, но не удобно и не очевидно...

(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

(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. Это не плохо, но не удобно и не очевидно...
> 
> Не должна. Но если компании так хочется, то конечно можно :)

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

(In reply to comment #14)
> Речь о том, что в рамках sisyphus_check новый пакет проверки собрать будет
> нельзя, поскольку, он собирается по правилам, которые прописаны в нём самом...

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

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

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

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

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

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

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

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

(In reply to comment #15)
> Решение я тебе тоже предложил: давай попросим кого-нибудь разделить
> sisyphus_check на утилиту и отдельные проверки.

И получится почти repocop :) Может, пора их уже сливать? :)

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

sisyphus_chack не может себе такого позволить.

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

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

Ой, а что так много ?!

> Ой, а что так много ?!
-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;

(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 для поддержки разных программ
проверки. Я же вынужден, при таком исходе, либо сам им стать, либо ждать у моря
погоды...

В общем сейчас я вынужден делать хитрый форк... :)

Так, а (что-то вроде) hsh --no-sisyphus-check=packager, не подходит?

(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 в виде другого
пакета... Не хочется на этом надолго останавливаться, поскольку для меня это
вспомогательная задача, я склонен скорее отказаться от проверок на первом этапе,
чем посвятить всё время их исправлению.

(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, специфичен или вообще не подлежит
распространению; у меня есть минимум один такой текущий случай

(In reply to comment #23)
> > давай попросим кого-нибудь разделить sisyphus_check на утилиту 
> > и отдельные проверки.
BTW тогда можно попробовать так:

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

Тогда проверяемость полиси регулируется установкой пакета sisyphus_check, но это
site-wide.

(In reply to comment #22)
> У меня вот вопрос про разбивание пакета sisyphus_check на функциональные
> элементы и объединение с repocop. А насколько сложно организовать
> sisyphus_check, как программу проверки использующую отдельные модули от repocop?
Не хочешь попробовать копнуть в сторону rpm_check, который бы получалось
использовать из sisyphus_check?

(In reply to comment #22)
> Требуется ли для эффективной организации sisyphus_check на основе модулей
> repocop модифицировать интерфейс самих модулей?
в принципе, все тесты без состояния можно было бы гонять из - под sisyphus_check,
вопрос в том, куда их устанавливать.

(In reply to comment #23)
> --strict?

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

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

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

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

Хитрец. Тогда кто угодно сможет отключить проверку :) А тогда в этом нет смысла.

(In reply to comment #26)
> в принципе, все тесты без состояния можно было бы гонять из - под sisyphus_check,
> вопрос в том, куда их устанавливать.

В sisyphus_check есть некоторые ограничения связанные с безопасностью т.к. он
может выполняться в хост системе. Не любые запросы rpm к пакету возможны.

(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.

Дайте мне несколько дней на подумать над кодом. Я попробую сделать
sisyphus_check более реюзабильным. Если конечно мантейнер не против.

Спасибо :)

Вот что получилось:

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

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

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

Вау, выглядит намного красивше той здоровенной простыни :-)

(In reply to comment #33)
> Вау, выглядит намного красивше той здоровенной простыни :-)

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

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

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

Нужно подумать.

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

(In reply to comment #35)
> В Сизиф ушёл sisyphus_check-0.8.0-alt1.
> Однако поставленную задачу настройки себя он не решает.
Ничего, это уже часть решения.

эта же проблема всплыла и при запуске из repocop (#16550)

(кросспост)
я написал пускатель 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)

еще характерный пример

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;

(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 ещё даже не думали, подписан проэкспайреным ключом.  Тест правильно ругается (а пакет надо фтопку).

Хочу вернуться в этому вопросу... Можно ли как решить вопрос с указанием проверок по умолчанию?

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

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

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

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

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

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

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

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

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

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

Я предлагаю выступить в devel@ с предложением из комментария #41.
Может быть более широкое обсуждение даст какое-то решение проблемы.

Хотя разве не было бы решением отключение неподходящих проверок, и добавление своих проверок, раз уж подхватываются все проверки из каталога?

Поскольку "вы оба правы" (tm) -- и legion@, и sin@ -- то хотелось бы услышать мнение пользователей sisyphus_check, в первую очередь разработчиков hasher, насчёт переименования пакета (и, возможно, утилиты) sisyphus_check в что-либо из списка:
- altlinux_check (IMHO случай LINUX@Etersoft сюда уже не вписывается);
- package-check
- alt-rpm-lint
- <ваш вариант>

(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(), в чём проблема-то?

(В ответ на комментарий №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

У меня есть задумка, что имело в виду под такой параметризацией. Приведу это в виде патча отдельным файлом.

Created attachment 4930 [details]
Примерный патч для подстановки run_sisyphus_check()

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

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

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

Если да, то не ясно как добиться запуска фиксированного приложения для проверки (например, sisyphus_check vs etersoft_check), по умолчанию?

(В ответ на комментарий №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, с конфликтами на любой другой подобный.

(В ответ на комментарий №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.

(В ответ на комментарий №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) в Сизиф не уезжал...

(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.

(В ответ на комментарий №52)
> Полагаю что эта история имеет мало общего с темой настоящего FR.

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

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

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

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

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

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

См. тж. http://lists.osdn.org.ua/wws/arc/linux-list/2012-02/msg00005.html

2 aen, ldv: есть мысль, что это был бы хороший штрих к седьмой платформе,
и желание его всё-таки сделать.

...ну или хоть к девятой...

Прошло 12 лет, а использовать свой почтовый адрес все еще нельзя. Это удивительно и печально одновременно. В чем вообще криминал при использованиии ЛЮБОГО почтового адреса, если в сизиф попадают только пакеты, ПОДПИСАННЫЕ разработчиком AltLinux? О чем, простите, эта многотомная дискуссия на 12 лет?

Предлагаю чтобы можно было использовать любой email адрес, но только чтобы домен у него был наш, русский. Например razrabotchik_linuxa@mail.ru.

(In reply to alexey.tourbin from comment #58)
> Предлагаю чтобы можно было использовать любой email адрес, но только чтобы
> домен у него был наш, русский. Например razrabotchik_linuxa@mail.ru.

Ну почему русский то? Вот я -- гражданин Беларуси -- хотел бы вести буквально несколько пакетов в AltLinux. Почтовый домен у меня  на немецком
сайте gmx.net, и я с ним уже больше 20 лет. Мне не хочется от
него отказываться, тем более что я не вижу для этого никаких разумных причин.
Таким неразумным требованием вы же сознательно отсекаете разработчиков из сопредельных стран. По-моему это очевидно как белый день. Я переформулирую свой вопрос: моя gpg подпись под коммитом перестает быть валидной, если я использую "немецкий" почтовый адрес или cheusov@netbsd.org?

Лёша, это Лёша юродствует.
Лёша, Лёша хакер не хуже тебя, уймись.

Да я не сомневаюсь. Фамилия и поделки на слуху. Видимо, нет у меня чувства юмора. Как бы там ни было по этому вопросу я умялся... На ближайшие 12 лет.

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

(In reply to Aleksey Cheusov from comment #57)
> Прошло 12 лет, а использовать свой почтовый адрес все еще нельзя. Это
> удивительно и печально одновременно. В чем вообще криминал при
> использованиии ЛЮБОГО почтового адреса, если в сизиф попадают только пакеты,
> ПОДПИСАННЫЕ разработчиком AltLinux?

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

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

А кто её знает, она слишком большая, чтобы её сейчас читать. :)

(In reply to Alexey Gladkov from comment #62)
> Ну если только ldv@ что-то сделает по этой баге.

Это вряд ли.

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

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

(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-а -- выше ;-)

(In reply to Aleksey Cheusov from comment #65)
> Вопрос надо ставить другим образом. Какие Преимущества дает ограничение на
> почтовый ящик пакетировщика при условии, что git тэг подписан gpg ключем.
> Мой ответ -- никаких.

Это ограничение позволило реализовать проверку того, что последняя запись в %changelog соответствует подписи.

(Ответ для Aleksey Cheusov на комментарий #65)
> > А какая разница для человека, какой из его почтовых адресов там написан?
> 
> Да мало ли у людей бывают какие тараканы в голове? Кто-то например,
> пользуется, gmail-ом, и из принципа не пользуется другой почтой, потому что
> Google -- это корпорация Дора. Кому-то не хочется заводить новый ящик на
> каждый чих, и не надо его заставлять это делать.

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

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

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

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

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

Это не всегда будет работать.

(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-летней давности есть очень смешной комментарий по поводу раздачи сертификатов за возможность работы с репозиторием Сизиф. По-моему он очень смешной. Мне во всяком случае понравился :-)

(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-а -- выше ;-)
> 
> Это не всегда будет работать.

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

(Ответ для 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 тэг этого пакета.

(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.

(Ответ для 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 тогда еще не придумали.

(Ответ для 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 тогда еще не придумали.

(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>
Отличный пример. Очень в тему

(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 -- по удобству и простоте вхождения для новичков (игнорируем другие характеристики на секундочку) -- одна из лучших систем в отрасли.

1. Хорошая аналогия с обрезанием, спасибо! 
2. Да, аргумент "а у них" лично у меня вызывает желание закончить разговор. 
3. Но я в него, тем не менее, вступил. Написано много, отвечу завтра по прочтении. 

Коллеги,давайте постараемся понять друг друга.

Эх. 
Тот SuSe был первым дистрибутивом, в котором я (вместе со smi@) был контрибьютором. И мы обмывали эти адреса в Нюрнберге в 89м, кажется.

(Ответ для 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 сказано достаточно для этой итерации обсуждения.

Мое мнение.
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@ и договорились продолжить обсуждение. После согласования наших мнений и планов, мы их обнародуем.

(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.