Created attachment 9095 [details]
gpg pub key

Created attachment 9096 [details]
ssh pub key

(Ответ для burykin на комментарий #0)
> Менторы: Андрей Савченко (bircoph@altlinux.org)
> и Михаил Шигорин (mike@altlinux.org)
Подтверждаю; рад видеть.

(In reply to burykin from comment #0)
> Псевдоним: bne
> Почта: burykin@basealt.ru
> Менторы: Андрей Савченко (bircoph@altlinux.org) и Михаил Шигорин
> (mike@altlinux.org)

Подтверждаю.

(In reply to burykin from comment #1)
> Created attachment 9095 [details]
> gpg pub key

Это не обязательные требования, но я рекомендую следующее:
1) Добавить к gpg-ключу отдельный подключ для подписей (gpg --edit-key ... addkey, sign capability only; при это с основного ключа sign capability можно снять).
2) Отправить публичный ключ на любой публичный сервер (gpg --send-key), чтоб он был доступен всем реципиентам, а не только там, где подключены ключи Альта из пакета.

(Ответ для Andrew Savchenko на комментарий #4)
> (In reply to burykin from comment #0)
> > Псевдоним: bne
> > Почта: burykin@basealt.ru
> > Менторы: Андрей Савченко (bircoph@altlinux.org) и Михаил Шигорин
> > (mike@altlinux.org)
> 
> Подтверждаю.
> 
> (In reply to burykin from comment #1)
> > Created attachment 9095 [details] [подробности] [details]
> > gpg pub key
> 
> Это не обязательные требования, но я рекомендую следующее:
> 1) Добавить к gpg-ключу отдельный подключ для подписей (gpg --edit-key ...
> addkey, sign capability only; при это с основного ключа sign capability
> можно снять).
> 2) Отправить публичный ключ на любой публичный сервер (gpg --send-key), чтоб
> он был доступен всем реципиентам, а не только там, где подключены ключи
> Альта из пакета.

1) Суть рекомендации понял. Добавил к gpg-ключу отдельно подключ с возможностью подписи. С основного ключа возможность подписи пока снимать не стал.

2) Отправил публичный ключ на сервер keys.gnupg.net

Created attachment 9098 [details]
Новый gpg pub key

Надеюсь еще не слишком поздно, и можно опубликовать ssh pub key здесь. 
После сбоя в работе keepass обнаружил безвозвратную потерю пароля для созданного ssh-ключа. К сожалению это событие произошло до создания резервной копии базы, поэтому безальтернативно пришлось создавать новый ключ

Created attachment 9103 [details]
Новый ssh pub key

(In reply to burykin from comment #7)
> Надеюсь еще не слишком поздно, и можно опубликовать ssh pub key здесь. 
> После сбоя в работе keepass обнаружил безвозвратную потерю пароля для
> созданного ssh-ключа. К сожалению это событие произошло до создания
> резервной копии базы, поэтому безальтернативно пришлось создавать новый ключ

Ещё не поздно, но на будущее рекомендую бэкапить.

(Ответ для burykin на комментарий #6)
> Создано вложение 9098 [details] [подробности]
> Новый gpg pub key
(Ответ для burykin на комментарий #8)
> Создано вложение 9103 [details] [подробности]
> Новый ssh pub key

Ok.

Считаю, что кандидат готов к переходу на следующий этап.

ssh ключ на gitery.alt зарегистрирован.
ssh ключ на gyle.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 2.4.

Считаю, что кандидат готов двигаться дальше и собирать пакеты.

(Ответ для Andrew Savchenko на комментарий #13)
> Считаю, что кандидат готов двигаться дальше и собирать пакеты.
+1

ping!

Пакет alt-gpgkeys обновлён.

T/J/S -> 3.4.

Считаю, что кандидат готов к самостоятельной работе в Сизифе.

Добрый день.

Я так понимаю переход на этап 4.0 предполагает независимую оценку от другого ментора. Полагаю это займёт некоторое время. Требуются ли от меня какие-либо дополнительные действия?

Добрый вечер!

(In reply to burykin from comment #18)
> Добрый день.
> 
> Я так понимаю переход на этап 4.0 предполагает независимую оценку от другого
> ментора. Полагаю это займёт некоторое время. Требуются ли от меня какие-либо
> дополнительные действия?

Нет, не требуется. Ментор, желающий проводить оценку, уже есть. Ждём официального утверждения и продвижения до 4.2 от одного из секретарей тима.

Призван ещё один ментор (vseleznv@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.

По сборкам пакетов серьёзных замечаний нет.

freelan.init стоило бы переписать, используя /etc/rc.d/init.d/template, для консистентности с остальными скриптами альта. Мне кажется, использовать reload() для перезапуска скриптов в общем случае не стоит, её следует использовать для обновления конфигурации без останова процесса, или не использовать вообще, если такое не поддерживается. Следующий комментарий вводит в заблуждение:

# Function that sends a SIGNUP to the daemon/service

Однако, если вы не пользуетесь SysVinit'ом, то лучше лишний раз файл не трогать.

Замечания по пакету edbrowse: лицензия указана некорректно, но это апстрим не позаботился о том, чтобы её явно указать, но похоже имелась в виду GPL-2 or later. В именах файлов патчей обычно указывается версия, относительно который были сделаны (или обновлены) изменения, т.е. вместо использования %version лучше явно писать версию, что позволит лишний раз не переименовывать файл, если патч не изменился при обновлении.

Общие замечания по использованию gear:

* Тарболы в случае сборки из gear лучше не сжимать — пакеты RPM и так сжаты, в поле source не надо указывать путь до апстримного тарбола, лучше указать его в комментарии перед source.

* При использовании gear лучше отделять по разным коммитам изменения, касаемые апстримный исходников (импорт, обновление), от альтоских (изменения spec'а, обновление патчей и сторонних файлов). При использовании схемы импортирования апстримных тарболов рекомендуется использовать утилиту gear-import(1), для создания релизного коммита и тега — gear-commit(1) и gear-create-tag(1) соответственно.

Предлагаю собрать ещё один пакет.

(In reply to Vladimir D. Seleznev from comment #21)
> Замечания по пакету edbrowse: лицензия указана некорректно, но это апстрим
> не позаботился о том, чтобы её явно указать, но похоже имелась в виду GPL-2
> or later.

Я специально разбирал этот случай с Николаем, это необычный случай. Лицензия указана верно. Апстрим указывает в файле COPYING:

This program is copyright (C) Karl Dahlke, 2000-2014.
It is made available by the author under the terms of the GNU General Public
License (GPL), as articulated by the Free Software Foundation.
http://www.fsf.org/licensing/licenses/gpl.html
It may be used for any purpose, and redistributed,
provided this copyright notice is included.

И в хедерах отдельных файлов:
* This file is part of the edbrowse project, released under GPL.

А теперь перейди по ссылке, указанной апстримом выше и почитай внимательнее пункт 14, параграф 2:

If the Program does not specify a version number of the GNU General Public
License, you may choose any version ever published by the Free Software Foundation.

Поэтому применимы все версии GPL, начиная с 1.0.

(Ответ для Vladimir D. Seleznev на комментарий #21)
Добрый день.
Спасибо за конструктивную критику.
 
> freelan.init стоило бы переписать, используя /etc/rc.d/init.d/template, для
> консистентности с остальными скриптами альта.

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

> В именах файлов патчей обычно указывается версия, относительно
> который были сделаны (или обновлены) изменения, т.е. вместо использования
> %version лучше явно писать версию, что позволит лишний раз не
> переименовывать файл, если патч не изменился при обновлении.

Учёл, переименую.

> 
> Общие замечания по использованию gear:
> 
> * Тарболы в случае сборки из gear лучше не сжимать — пакеты RPM и так сжаты,

Здесь видимо имеется ввиду репозиторий edbrowse, где в gear/rules я оставил tar.gz: edbrowse? 
Особых причин сжимать его вроде бы не было. Поправлю. 

> в поле source не надо указывать путь до апстримного тарбола, лучше указать
> его в комментарии перед source.

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

Url: http://www.freelan.org
# repacked https://github.com/freelan-developers/freelan/archive/refs/tags/%version.tar.gz 
Source0: %name-%version.tar

и аналогично в edbrowse.

> * При использовании gear лучше отделять по разным коммитам изменения,
> касаемые апстримный исходников (импорт, обновление), от альтоских (изменения
> spec'а, обновление патчей и сторонних файлов). 

В целом я примерно так и планирую вести репозиторий. Каждое глобальное действие - отдельным коммитом. При сборке новой версии - добавление тэга.
Initial build for ALT в качестве единственного коммита на данный момент служит исключительно указателем на готовность репозитория. 
Изначально оба репозитория я подготавливал и согласовывал с менторами на github, и там эта история велась именно в таком виде. Например:
https://github.com/burykinne/edbrowse/commits/master
Когда был получен доступ к git.alt, пересоздал заново уже только с одним коммитом. Соответственно дальше, по мере изменений и обновлений буду историю пополнять (скоро буду обновлять edbrowse до 3.8.0 например).
Требуются ли сейчас какие-либо действия в этом направлении?

> При использовании схемы
> импортирования апстримных тарболов рекомендуется использовать утилиту
> gear-import(1), для создания релизного коммита и тега — gear-commit(1) и
> gear-create-tag(1) соответственно.

Присматривался к этой утилите. Обновление edbrowse попробую провести с её помощью. 

> Предлагаю собрать ещё один пакет.

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

(In reply to burykin from comment #23)
> (Ответ для Vladimir D. Seleznev на комментарий #21)
> > [skip] 
> > в поле source не надо указывать путь до апстримного тарбола, лучше указать
> > его в комментарии перед source.
> 
> Вот здесь наверное нужно уточнение. Правильно ли я понял, что необходимо
> часть спека привести к такому виду?
> 
> Url: http://www.freelan.org
> # repacked
> https://github.com/freelan-developers/freelan/archive/refs/tags/%version.tar.
> gz 
> Source0: %name-%version.tar

Да.

> и аналогично в edbrowse.

Да.

> > * При использовании gear лучше отделять по разным коммитам изменения,
> > касаемые апстримный исходников (импорт, обновление), от альтоских (изменения
> > spec'а, обновление патчей и сторонних файлов). 
> 
> В целом я примерно так и планирую вести репозиторий. Каждое глобальное
> действие - отдельным коммитом. При сборке новой версии - добавление тэга.
> Initial build for ALT в качестве единственного коммита на данный момент
> служит исключительно указателем на готовность репозитория. 
> Изначально оба репозитория я подготавливал и согласовывал с менторами на
> github, и там эта история велась именно в таком виде. Например:
> https://github.com/burykinne/edbrowse/commits/master
> Когда был получен доступ к git.alt, пересоздал заново уже только с одним
> коммитом. Соответственно дальше, по мере изменений и обновлений буду историю
> пополнять (скоро буду обновлять edbrowse до 3.8.0 например).
> Требуются ли сейчас какие-либо действия в этом направлении?

Какие действия?

> > При использовании схемы
> > импортирования апстримных тарболов рекомендуется использовать утилиту
> > gear-import(1), для создания релизного коммита и тега — gear-commit(1) и
> > gear-create-tag(1) соответственно.
> 
> Присматривался к этой утилите. Обновление edbrowse попробую провести с её
> помощью. 
> 
> > Предлагаю собрать ещё один пакет.
> 
> У меня есть еще несколько пакетов в разной степени готовности, постараюсь в
> ближайшее время опубликовать.

Хорошо.

Добрый день.

Вроде бы со всем разобрался.
По пакету Freelan:
- Внёс корректирующие изменения в spec
- Поправил init файл. Не знаю где были мои глаза, когда я занимался им в первый раз, но практика показала, что работал он не правильно. Команда /etc/init.d/freelan stop не останавливала службу. Поэтому пришлось немного поправить поведение функций stop и start. После этого проверки на стенде прошли успешно, и выдали ожидаемое поведение.

По пакету Edbrowse:
- Внёс корректирующие изменения в spec
- К сожалению пока не обновил, там достаточно много изменений, и не со всеми я еще разобрался. Но вот использование gear-import при попытке обновиться на новую версию оценил, это правда удобно.
Одно из нововведений новой версии - использование нового движка JS с названием quickjs. Оказалось, что он отсутствует в репозитории Альта, поэтому даже сомнений не оставалось какой пакет собирать следующим.

Новый собранный пакет для контрольной проверки - quickjs:
Репозиторий
- http://git.altlinux.org/people/bne/packages/?p=quickjs.git;a=summary
Результаты тестовой сборки
- http://git.altlinux.org/tasks/274443/logs/events.1.1.log

(In reply to burykin from comment #25)
> Добрый день.
> 
> Вроде бы со всем разобрался.
> По пакету Freelan:
> - Внёс корректирующие изменения в spec
> - Поправил init файл. Не знаю где были мои глаза, когда я занимался им в
> первый раз, но практика показала, что работал он не правильно. Команда
> /etc/init.d/freelan stop не останавливала службу. Поэтому пришлось немного
> поправить поведение функций stop и start. После этого проверки на стенде
> прошли успешно, и выдали ожидаемое поведение.

По инит-скрипту есть замечания.

Вижу строки

# Please enter config file name (comma-separated list)
CONFIGURATIONS=""

Вы предлагаете править скрипт? Так нельзя делать. Вместо этого мы пользуемся environment files, находящимися в /etc/sysconfig (например, freelan), и сорсим его в нужном месте в скрипте. Посмотрите на примерах других пакетов как это сделано. Также вы просите перечислить конфиги, но после первого же конфига досрочно выходите из цикла, независимо от исхода операции. Зачем? А после остановки сервиса удаляете конфиг-файл. Я не понимаю, это выглядит неправильно.

> По пакету Edbrowse:
> - Внёс корректирующие изменения в spec

Изменения в d5da1814620b44faf5f572d670d5efbf0d7fc44d — LGTM.

> - К сожалению пока не обновил, там достаточно много изменений, и не со всеми
> я еще разобрался. Но вот использование gear-import при попытке обновиться на
> новую версию оценил, это правда удобно.
> Одно из нововведений новой версии - использование нового движка JS с
> названием quickjs. Оказалось, что он отсутствует в репозитории Альта,
> поэтому даже сомнений не оставалось какой пакет собирать следующим.
> 
> Новый собранный пакет для контрольной проверки - quickjs:
> Репозиторий
> - http://git.altlinux.org/people/bne/packages/?p=quickjs.git;a=summary
> Результаты тестовой сборки
> - http://git.altlinux.org/tasks/274443/logs/events.1.1.log

> По инит-скрипту есть замечания.
> 
> Вижу строки
> 
> # Please enter config file name (comma-separated list)
> CONFIGURATIONS=""
> 
> Вы предлагаете править скрипт? Так нельзя делать. Вместо этого мы пользуемся
> environment files, находящимися в /etc/sysconfig (например, freelan), и
> сорсим его в нужном месте в скрипте. Посмотрите на примерах других пакетов
> как это сделано. Также вы просите перечислить конфиги, но после первого же
> конфига досрочно выходите из цикла, независимо от исхода операции. Зачем? А
> после остановки сервиса удаляете конфиг-файл. Я не понимаю, это выглядит
> неправильно.

Добрый день.

Да, предполагается ручная правка init-скрипта. Это решение было предложено разработчиком.
Попробую объяснить что происходит в этом init-скрипте, и почему.

Разработчик предполагает 3 варианта развертывания VPN-туннелей.
1. Ручной. В этом варианте пользователь, установив freelan, может сразу ввести что-то в духе:
# freelan --security.passphrase "mypassphrase"
и получит у себя готовый VPN сервер.
Этот вариант использования является приоритетным.
В этом варианте не предусмотрено использование cкриптов инициализации.
2. Статичный конфиг.
В этом варианте имя файла помещается в init-скрипт, сам скрипт добавляется в автозапуск и при загрузке поднимает VPN-туннель в соответствии с настройками указанными в конфигурационном файле.
3. То же что и в.2, только конфигурационных файлов больше одного.

Что делает init-скрипт, который я приложил к пакету:
1. Проверяет перечислены ли имена конфигурационных файлов в переменной $CONFIGURATIONS. Если переменная пуста, запуск скрипта прерывается с предложением создать конфиг. Если это условие выполнилось, то далее пользователю нужно либо создать конфиг (раз уж он зачем-то добавил init-скрипт в автозагрузку), либо использовать ручной вариант создания туннеля.
2. Если в переменной $CONFIGURATIONS что-то всё таки есть то скрипт в цикле проходится по списку конфигурационных файлов, для каждого запуская новый экземпляр freelan, и поднимая несколько VPN-туннелей.
3. После остановки сервиса конфигурационный файл не удаляется. Удаляется pid файл, название которого ассоциировано с конкретным конфигом из которого запущен экземпляр freelan.


Я наверное мог бы переписать скрипт, и привести в соответствие стандарту /etc/sysconfig. Но честно говоря пока немного в ступоре и не понимаю как логику, описанную выше, наложить на эту схему.
P.S. Чтение пакетов аналогичных по смыслу (openvpn , tor) пока не помогло. Тот же Tor например вообще не использует /etc/syscofig.

(In reply to burykin from comment #27)
> Добрый день.
> 
> Да, предполагается ручная правка init-скрипта. Это решение было предложено
> разработчиком.

Так в любом случае делать нельзя.

> Попробую объяснить что происходит в этом init-скрипте, и почему.
> 
> Разработчик предполагает 3 варианта развертывания VPN-туннелей.
> 1. Ручной. В этом варианте пользователь, установив freelan, может сразу
> ввести что-то в духе:
> # freelan --security.passphrase "mypassphrase"
> и получит у себя готовый VPN сервер.
> Этот вариант использования является приоритетным.
> В этом варианте не предусмотрено использование cкриптов инициализации.
> 2. Статичный конфиг.
> В этом варианте имя файла помещается в init-скрипт, сам скрипт добавляется в
> автозапуск и при загрузке поднимает VPN-туннель в соответствии с настройками
> указанными в конфигурационном файле.
> 3. То же что и в.2, только конфигурационных файлов больше одного.
> 
> Что делает init-скрипт, который я приложил к пакету:
> 1. Проверяет перечислены ли имена конфигурационных файлов в переменной
> $CONFIGURATIONS. Если переменная пуста, запуск скрипта прерывается с
> предложением создать конфиг. Если это условие выполнилось, то далее
> пользователю нужно либо создать конфиг (раз уж он зачем-то добавил
> init-скрипт в автозагрузку), либо использовать ручной вариант создания
> туннеля.
> 2. Если в переменной $CONFIGURATIONS что-то всё таки есть то скрипт в цикле
> проходится по списку конфигурационных файлов, для каждого запуская новый
> экземпляр freelan, и поднимая несколько VPN-туннелей.

Смотрите, у вас в начале инит-скрипта есть строка

    config: /etc/freelan/freelan.cfg

С другой стороны, в service-файле нет вообще никаких манипуляций с CONFIGURATIONS. Греп показал, что это конфиг по-умолчанию. Не хотелось бы, чтобы поведение init-скрипта и service-файла различалось. Предлагаю сделать по аналогии с тем, как сделано в openvpn: по-умолчанию использовать этот конфиг, для остальных сделать по аналогии с openvpn channel'ами. И соответственно поправить service-файл.

> 3. После остановки сервиса конфигурационный файл не удаляется. Удаляется pid
> файл, название которого ассоциировано с конкретным конфигом из которого
> запущен экземпляр freelan.

Да, проглядел.

> Я наверное мог бы переписать скрипт, и привести в соответствие стандарту
> /etc/sysconfig. Но честно говоря пока немного в ступоре и не понимаю как
> логику, описанную выше, наложить на эту схему.
> P.S. Чтение пакетов аналогичных по смыслу (openvpn , tor) пока не помогло.
> Тот же Tor например вообще не использует /etc/syscofig.

Я вижу, что в openvpn есть пример использования environment file. А также отедльно есть возможность передать в init-скрипт конфигурацию. Посмотрите на channel'ы.

И расположение pid-файлов лучше использовать одно и то же для init-скрипта и service-файла. Если предполагается несколькоо инстансов сервиса, то лучше завести каталог в /run/freelan, для этого нужно задействовать tmpfiles.d(5).

> Так в любом случае делать нельзя.

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

Добрый день.

Получилось наконец разобраться с CHANNEL'ами и переписать init-скрипт для Freelan.
http://git.altlinux.org/people/bne/packages/?p=freelan.git;a=summary

Попутно, разбираясь с тем как оно работает, у меня возник вопрос по init-скрипту самого openvpn. Конкретно по работе функции enabled_channels.
Я предположил, что она должна работать следующим образом (мне это показалось логичным, и именно этот вариант я сделал в init-скрипте для freelan):
1. Сравнивается список имен конфигурационных файлов в каталоге /etc/openvpn с именами конфигурационных файлов, указанными в /etc/sysconfig/openvpn в секции MANUAL.
2. Если имя конфигурации нашлось и там и там, то имя передаётся в переменную CHANNELS.
3. CHANNELS в свою очередь передаётся дальше функции start
4. Функция start проходится по списку CHANNELS, запуская поочередно каждый канал указанный в списке (если он конечно существует).
 
Скопировав функцию в свой init-скрипт, и начав тестировать, я обнаружил что работает она несколько иначе. Если быть точным, то строго наоборот, запуская все конфигурационные файлы, кроме тех что указаны в /etc/sysconfig/openvpn в секции MANUAL. Мне это показалось странным, потому что в /etc/sysconfig/openvpn в примечании к секции написано:
# Add here a names of OpenVPN channels in /etc/openvpn/
# that shouldn't be started automatically

Я установил пакет openvpn, и проверил как эта функция работает в родном пакете. Результат оказался таким же.
То есть я добавляю в /etc/sysconfig/openvpn в MANUAL реальный конфиг, после чего запускаю openvpn через
# /etc/init.d/openvpn start , и получаю:
Starting openvpn service: No channels to start!                                                                                                                 [FAILED]
Configure one or more VPN's and place configuration files in /etc/openvpn
Sample config could be obtained from /usr/share/doc/openvpn

Так как других конфигов, кроме добавленного в MANUAL у меня в каталоге /etc/openvpn нет.

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

# Add here a names of OpenVPN channels in /etc/openvpn/
# that shouldn't be started automatically

  "Добавьте сюда каналы, которые не должны стартовать автоматически"
  Т.е. MANUAL - список каналов, запускаемых вручную (сюрприз).

(Ответ для Andrew Vasilyev на комментарий #32)
> # Add here a names of OpenVPN channels in /etc/openvpn/
> # that shouldn't be started automatically
> 
>   "Добавьте сюда каналы, которые не должны стартовать автоматически"
>   Т.е. MANUAL - список каналов, запускаемых вручную (сюрприз).

Понял. Виновата моя исключительная невнимательность. Прошу прощения. 
Мне то как раз нужно было поведение, озвученное мной, и видимо зациклившись на этом я упорно не обращал внимание на то, что там shouldn't, а не should.

Добрый день.

Мне понадобилось подготовить обновление уже собранного в сизиф пакета (Tidy).
Дело в том, что без версии 5.6.0 не собирается новая версия собираемого мной пакета edbrowse (3.8.0). 
Наверное в рамках репозитория обновление текстового браузера не столь уж важное событие, но в пользу принятия мной решения всё таки заняться этим были две вещи:
- версия tidy в сизифе сама по себе очень старая;
- рано или поздно передо мной встала бы задача подобного плана, наверное лучше отработать такое в рамках процедуры join.
Ну и плюс ко всему @mike, как основной мэйнтейнер данного пакета, был не против если я озадачусь поддержкой tidy.

Как итог прилагаю здесь результат своих действий по обновлению пакета: 
http://git.altlinux.org/people/bne/packages/?p=tidy.git;a=summary

А также лог сборочницы. На первый взгляд сборка прошла успешно:
http://git.altlinux.org/tasks/282099/logs/events.1.1.log

(In reply to burykin from comment #34)
> Добрый день.
> 
> Мне понадобилось подготовить обновление уже собранного в сизиф пакета (Tidy).
> Дело в том, что без версии 5.6.0 не собирается новая версия собираемого мной
> пакета edbrowse (3.8.0). 
> Наверное в рамках репозитория обновление текстового браузера не столь уж
> важное событие, но в пользу принятия мной решения всё таки заняться этим
> были две вещи:
> - версия tidy в сизифе сама по себе очень старая;
> - рано или поздно передо мной встала бы задача подобного плана, наверное
> лучше отработать такое в рамках процедуры join.
> Ну и плюс ко всему @mike, как основной мэйнтейнер данного пакета, был не
> против если я озадачусь поддержкой tidy.
> 
> Как итог прилагаю здесь результат своих действий по обновлению пакета: 
> http://git.altlinux.org/people/bne/packages/?p=tidy.git;a=summary

Hi! Зачем импортировать сорцы в каталог 5, а не tidy? В этом нет никакого смысла, и гораздо сложнее смотреть дифф между разными версиями. Пожалуйста, импортируйте сорцы в tidy.

> А также лог сборочницы. На первый взгляд сборка прошла успешно:
> http://git.altlinux.org/tasks/282099/logs/events.1.1.log

> Hi! Зачем импортировать сорцы в каталог 5, а не tidy? 

Я не сделал этого, потому что на момент импорта уже существовал каталог tidy, но содержал он не сорцы а часть документации (которая теперь переехала в онлайн), а сорцы были в каталоге tidy_src_170301.

Мне тоже кажется, что в tidy сложить было бы правильнее. Технически я могу сделать так же как делал для своих пакетов. Всё исходники сложить в %name, а от каталогов типа tidy_src_%ver избавиться. 

Но diff между 5.6 и 5.4 при таком исходе тоже будет тяжело делать кмк.

(In reply to burykin from comment #36)
> > Hi! Зачем импортировать сорцы в каталог 5, а не tidy? 
> 
> Я не сделал этого, потому что на момент импорта уже существовал каталог
> tidy, но содержал он не сорцы а часть документации (которая теперь переехала
> в онлайн), а сорцы были в каталоге tidy_src_170301.

Ага, я проглядел этот момент. Тогда лучше сделать импорт в tidy_src_%ver, и в том же коммите удалить предыдущий tidy_src_%oldver. git может сообразить, что тут перемещение файлов.

> Мне тоже кажется, что в tidy сложить было бы правильнее. Технически я могу
> сделать так же как делал для своих пакетов. Всё исходники сложить в %name, а
> от каталогов типа tidy_src_%ver избавиться. 
> 
> Но diff между 5.6 и 5.4 при таком исходе тоже будет тяжело делать кмк.

> Ага, я проглядел этот момент. Тогда лучше сделать импорт в tidy_src_%ver, и
> в том же коммите удалить предыдущий tidy_src_%oldver. git может сообразить,
> что тут перемещение файлов.

Спасибо, понял. Переделаю.

Готово, вроде ничего не забыл. На всякий случай сделал повторное задание, прошло успешно:
http://git.altlinux.org/tasks/282107/logs/events.1.1.log

Да, гит действительно сам определил, что tidy_src_%newver это новый каталог с исходниками, и пометил как перемещение.

(In reply to Vladimir D. Seleznev from comment #37)
> (In reply to burykin from comment #36)
> > > Hi! Зачем импортировать сорцы в каталог 5, а не tidy? 
> > 
> > Я не сделал этого, потому что на момент импорта уже существовал каталог
> > tidy, но содержал он не сорцы а часть документации (которая теперь переехала
> > в онлайн), а сорцы были в каталоге tidy_src_170301.
> 
> Ага, я проглядел этот момент. Тогда лучше сделать импорт в tidy_src_%ver, и
> в том же коммите удалить предыдущий tidy_src_%oldver. git может сообразить,
> что тут перемещение файлов.

Я думаю, что гораздо удобнее и практичнее отдельным коммитом переименовать каталог tidy_src_%oldver в tidy, а после этого импортировать в него новые исходники.

(Ответ для Gleb F-Malinovskiy на комментарий #40)
> (In reply to Vladimir D. Seleznev from comment #37)
> > (In reply to burykin from comment #36)
> > > > Hi! Зачем импортировать сорцы в каталог 5, а не tidy? 
> > > 
> > > Я не сделал этого, потому что на момент импорта уже существовал каталог
> > > tidy, но содержал он не сорцы а часть документации (которая теперь переехала
> > > в онлайн), а сорцы были в каталоге tidy_src_170301.
> > 
> > Ага, я проглядел этот момент. Тогда лучше сделать импорт в tidy_src_%ver, и
> > в том же коммите удалить предыдущий tidy_src_%oldver. git может сообразить,
> > что тут перемещение файлов.
> 
> Я думаю, что гораздо удобнее и практичнее отдельным коммитом переименовать
> каталог tidy_src_%oldver в tidy, а после этого импортировать в него новые
> исходники.

То есть делать три коммита в итоге?
Меня немного смущает в этой схеме одна вещь. Получается, что в двух коммитах, где мы переименовываем tidy_src_%oldver в tidy, и последующем, где импортируем обновление, не остаётся части исходников (которая в версии 5.4 всё еще присутствует в каталоге tidy).
Могу ли я предложить как вариант такую схему?
1. Импорт архива в tidy_src_%newver, удаление tidy_src_%oldver (уже сделано по рекомендации Владимира Селезнева).
2. Обновление tidy до 5.6 с сохранением наименования tidy_src_%newver, но уже с отсутсвующим каталогом tidy (уже сделано, в версии 5.6 этого каталога просто нет).
3. Промежуточный коммит, с переименованием tidy_src_%newver в tidy (готов сделать при положительном решении).

(In reply to Nikolay Burykin from comment #41)
> (Ответ для Gleb F-Malinovskiy на комментарий #40)
> > (In reply to Vladimir D. Seleznev from comment #37)
> > > (In reply to burykin from comment #36)
> > > > > Hi! Зачем импортировать сорцы в каталог 5, а не tidy? 
> > > > 
> > > > Я не сделал этого, потому что на момент импорта уже существовал каталог
> > > > tidy, но содержал он не сорцы а часть документации (которая теперь переехала
> > > > в онлайн), а сорцы были в каталоге tidy_src_170301.
> > > 
> > > Ага, я проглядел этот момент. Тогда лучше сделать импорт в tidy_src_%ver, и
> > > в том же коммите удалить предыдущий tidy_src_%oldver. git может сообразить,
> > > что тут перемещение файлов.
> > 
> > Я думаю, что гораздо удобнее и практичнее отдельным коммитом переименовать
> > каталог tidy_src_%oldver в tidy, а после этого импортировать в него новые
> > исходники.
> 
> То есть делать три коммита в итоге?
> Меня немного смущает в этой схеме одна вещь. Получается, что в двух
> коммитах, где мы переименовываем tidy_src_%oldver в tidy, и последующем, где
> импортируем обновление, не остаётся части исходников (которая в версии 5.4
> всё еще присутствует в каталоге tidy).

Да, я упустил, что каталог tidy уже существует и занят.  На самом деле, самая большая проблема в том, что в название каталога попадает версия, из-за этого при каждом обновлении будет неудобно смотреть на изменения между версиями.  Т.е. лучше переименовать в tidy_src, если каталог tidy уже используется для других целей.

> Могу ли я предложить как вариант такую схему?
> 1. Импорт архива в tidy_src_%newver, удаление tidy_src_%oldver (уже сделано
> по рекомендации Владимира Селезнева).
> 2. Обновление tidy до 5.6 с сохранением наименования tidy_src_%newver, но
> уже с отсутсвующим каталогом tidy (уже сделано, в версии 5.6 этого каталога
> просто нет).
> 3. Промежуточный коммит, с переименованием tidy_src_%newver в tidy (готов
> сделать при положительном решении).

Если старый каталог tidy с документацией уже не нужен, то я бы в этом случае сделал:
1. удаление каталога tidy;
2. переименование каталога tidy_src_%oldver в tidy;
3. импорт новой версии.

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

Доброго дня.

В качестве тренировки собрал еще один пакет:
Tinyproxy:
http://git.altlinux.org/people/bne/packages/?p=tinyproxy.git;a=summary

Результат сборки:
http://git.altlinux.org/tasks/283986/logs/events.1.1.log

Параллельно задействовал использование tmpfiles.d в freelan.
Однако с его сборкой теперь не всё так радужно. Почему то на armh он перестал собираться. Буду разбираться с этим.
http://git.altlinux.org/tasks/284021/logs/events.1.1.log
Не уверен, что на это повлияло добавление юзера freelan и создание отдельного каталога в /run.

Добрый день.

К сожалению мне пока так и не удалось справиться с ошибкой сборки Freelan для архитектуры armh,
поэтому в качестве временной меры я был вынужден добавить в spec-файл - ExcludeArch %arm.
В перспективе конечно планирую всё-таки разобраться с этой проблемой.
Надеюсь этот нюанс не является критическим и блокирующим при принятии решения о прохождении join.

Остальные замечания ранее вроде бы были отработаны.
Оставляю ссылки на текущее состояние репозитория, и последнюю успешную тестовую сборку:
http://git.altlinux.org/people/bne/packages/?p=freelan.git;a=summary
http://git.altlinux.org/tasks/287087/logs/events.1.1.log

Добрый день!

(In reply to Nikolay Burykin from comment #44)
> К сожалению мне пока так и не удалось справиться с ошибкой сборки Freelan
> для архитектуры armh,
> поэтому в качестве временной меры я был вынужден добавить в spec-файл -
> ExcludeArch %arm.
> В перспективе конечно планирую всё-таки разобраться с этой проблемой.
> Надеюсь этот нюанс не является критическим и блокирующим при принятии
> решения о прохождении join.
> 
> Остальные замечания ранее вроде бы были отработаны.
> Оставляю ссылки на текущее состояние репозитория, и последнюю успешную
> тестовую сборку:
> http://git.altlinux.org/people/bne/packages/?p=freelan.git;a=summary
> http://git.altlinux.org/tasks/287087/logs/events.1.1.log

На мой взгляд проблема с armh — не блокер для join. Архитектура относительно экзотическая, проблем с ней много. Без доступа к оборудованию или тестовой среде на нём, только по логам сборочницы проводить отладку сложно. Я на днях попробую посмотреть, что там за проблема, быть может, появятся какие-то идеи. Но в целом подход «отключить поддержку архитектуры, если на ней есть проблемы и нет желающих ими заниматься» я считаю нормальным, пусть и не лучшим из возможных.

Коллеги, прошу обратить внимание, что Николай уже проделал большую и качественную работу. Пакеты достались непростые в разных аспектах. С тем же tidy я не комментировал, т.к. апстрим ведёт себя необычно и есть разные способы обойти эту проблему. Вариант решения, предложенный bne, вполне приемлемый. Да, можно сделать по другому — и таких вариантов очень много, но здесь мы переходим от объективных технических требований к субъективному как красивее будет. Поэтому не вижу смысла закапываться в такие детали в процессе join'а.

Я не вижу смысла дальше тянуть с join и прошу пропустить кандидата.

(In reply to Nikolay Burykin from comment #44)
> http://git.altlinux.org/people/bne/packages/?p=freelan.git;a=summary
> http://git.altlinux.org/tasks/287087/logs/events.1.1.log

Обратите, пожалуйста, внимание на warning, который виден в сборке для i586:
verify-elf: WARNING: ./usr/bin/freelan: uses non-LFS functions: fcntl fopen open
это значит, что программа собрана без large file support.

(In reply to Andrew Savchenko from comment #45)
> На мой взгляд проблема с armh — не блокер для join.

Согласен.

> Я не вижу смысла дальше тянуть с join и прошу пропустить кандидата.

Володя, у тебя остались какие-то возражения?

(In reply to Nikolay Burykin from comment #43)
> Доброго дня.
> 
> В качестве тренировки собрал еще один пакет:
> Tinyproxy:
> http://git.altlinux.org/people/bne/packages/?p=tinyproxy.git;a=summary

Я всё же рекомендую использовать gear-import(1) и импортировать исходники отдельным коммитом. Это не ошибка, но так гораздо удобнее.

(In reply to Andrew Savchenko from comment #45)
> На мой взгляд проблема с armh — не блокер для join.

Безусловно не блокер.



(In reply to Gleb F-Malinovskiy from comment #46)
> (In reply to Andrew Savchenko from comment #45)
> > Я не вижу смысла дальше тянуть с join и прошу пропустить кандидата.
> 
> Володя, у тебя остались какие-то возражения?

По freelan'у вроде всё хорошо (ну, кроме того, что подготовленный релиз не попал в Сизиф).

Мне не понятно что происходит с tidy, но я так понимаю, что это всё не критично и может быть продложено потом.

В целом, считаю, что кандидата можно пропускать.

Адрес подписан на devel@.
Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!

(Ответ для Vladimir D. Seleznev на комментарий #47)
> (In reply to Nikolay Burykin from comment #43)
> > Доброго дня.
> > 
> > В качестве тренировки собрал еще один пакет:
> > Tinyproxy:
> > http://git.altlinux.org/people/bne/packages/?p=tinyproxy.git;a=summary
> 
> Я всё же рекомендую использовать gear-import(1) и импортировать исходники
> отдельным коммитом. Это не ошибка, но так гораздо удобнее.


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


(Ответ для Gleb F-Malinovskiy на комментарий #48)
> Адрес подписан на devel@.
> Пользователь добавлен в группу мейнтейнеров.
> 
> Желаю удачного мейнтейнерства!

Спасибо за оказанное доверие!
Надеюсь смогу быть полезным для команды)