Псевдоним: bne Почта: burykin@basealt.ru Менторы: Андрей Савченко (bircoph@altlinux.org) и Михаил Шигорин (mike@altlinux.org) Цель: Сборка freelan, fleet, fleet-launcher, osquery, и в перспективе помощь сообществу сборкой других пакетов из области системного администрирования.
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@. > Пользователь добавлен в группу мейнтейнеров. > > Желаю удачного мейнтейнерства! Спасибо за оказанное доверие! Надеюсь смогу быть полезным для команды)
