Created attachment 12499 [details] ключи Имя: Артём Курашов Псевдоним: saahriktu Адрес для пересылки: saahriktu@yandex.ru Ментор: Michael Shigorin (mike@) Цель: Хочу помогать поддерживать и улучшать дистрибутив. Для начала планирую причесать и выложить в Сизиф ряд пакетов из https://saahriktu.tech/alt-hacker/ .
FYI: [#315089] DONE flameshot.git=12.1.0-alt2
(Ответ для Артём Курашов на комментарий #0) > Имя: Артём Курашов Ура! > Ментор: Michael Shigorin (mike@) Подтверждаю; если "задумался" -- прошу потормошить личной почтой (или сразу). По ugrep: у меня он на обновлении по watch-файлику, приму патч на спек либо передам сопровождение; xfe бесхозный; tuxguitar последний раз был в p8 (avfs припоминается ещё в нулевых); hypnotix в сизифе уже 3.2; по mame & co стоит связаться с arbars@. По существующим пакетам стоит провзаимодействовать с их сопровождающими (например, развесив предлагаемые патчи багами с пояснением сути/цели изменений, если из патча неочевидно). Предлагаю начать с чего-либо из отсутствующего в сизифе -- например, tuxguitar, xfe, xisxwayland, ydotool или ещё чего на Ваше усмотрение. Сложные инфраструктурные вещи вроде git точно стоит хакать более аккуратно и не меняя способ ведения пакета в плане gear/srpm, если охота провести изменения в сизиф. В любом случае стоит освоить add_changelog из rpm-utils -- см. тж. http://altlinux.org/changelogs_guide -- и формировать записи %changelog как для новых пакетов, так и для затрагиваемых существующих (также предлагаю vim-plugin-spec_alt-ftplugin, чтоб по \ac добавлять, а не пешком).
Created attachment 12501 [details] emkatic.spec.diff В качестве примера того, как я бы доработал спек для вновь добавляемого пакета, прилагаю emkatic.spec.diff; проделанные операции: 1) добавление %changelog и записи в нём от Вашего имени (add_changelog+руки); 2) cleanup_spec emkatic.spec; 3) sed -i s/Source0/Source/ emkatic.spec (вкусовщина); 4) учёт http://altlinux.org/ALT_Packaging_HOWTO#Порядок_тэгов (вручную); 5) мелкая оптимизация установки (заодно обеспечивается строгое соответствие секций %install и %files в части пути к бинарнику, в развесистых спеках такие мелочи порой оказываются важны в долгосрочном плане).
(In reply to Артём Курашов from comment #0) > Created attachment 12499 [details] Приложите, пожалуйста, ключи в виде отдельных вложений.
Created attachment 12506 [details] GPG ключ
Created attachment 12507 [details] SSH ключ
ping
Похоже, вчера Глеб не смог добраться...
(In reply to Артём Курашов from comment #5) > Created attachment 12506 [details] > GPG ключ (In reply to Артём Курашов from comment #6) > Created attachment 12507 [details] > SSH ключ Ok.
Ура! :) Глеб, считаю, что мы на самом деле на 3.0 с учётом comment 0 и по опыту общения с Артёмом, которого уже много лет дожидался насчёт join. Артём, прошу Вашего отклика на уже изложенное в comment 2 и comment 3.
https://disk.yandex.ru/d/u-zIAOcR046pWQ
(Ответ для Артём Курашов на комментарий #11) > https://disk.yandex.ru/d/u-zIAOcR046pWQ xisxwayland.spec технически выглядит нормально; эстетически я бы поправил так: Summary: Tool to check if the X server is XWayland License: MIT Group: System/X11 Url: https://www.x.org Packager: Artem Kurashov <saahriktu@altlinux.org> Source: https://www.x.org/pub/individual/app/%name-%version.tar.xz [...] %prep %setup [...] %_man1dir/%name.1* (%setup по умолчанию как раз и делает -n %name-%version, а вместо %mandir/man есть более краткий макрос -- см. тж. rpm --showrc | grep man1, например)
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
https://disk.yandex.ru/d/XDjfY7ZpVl6T3g
(Ответ для Артём Курашов на комментарий #14) > https://disk.yandex.ru/d/XDjfY7ZpVl6T3g Думаю, такому пакету найдётся место в сизифе. :) Предлагаю переходить к шагу 3.
(In reply to Michael Shigorin from comment #15) > (Ответ для Артём Курашов на комментарий #14) > > https://disk.yandex.ru/d/XDjfY7ZpVl6T3g > Думаю, такому пакету найдётся место в сизифе. :) > > Предлагаю переходить к шагу 3. Я думаю, что было бы неплохо запушить что-нибудь на git.alt.
(Ответ для Gleb F-Malinovskiy на комментарий #16) > Я думаю, что было бы неплохо запушить что-нибудь на git.alt. Артём, предлагаю начать с того же xisxwayland.
http://git.altlinux.org/people/saahriktu/packages/?p=xisxwayland.git
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5.
Глеб, благодарю; Артём, прошу собрать пробное задание в сизиф.
https://packages.altlinux.org/ru/tasks/319909/
xisxwayland-2-alt1: https://packages.altlinux.org/ru/tasks/319949/ bvi-1.4.0-alt1: https://packages.altlinux.org/ru/tasks/320003/ vimpager-2.06-alt1: https://packages.altlinux.org/ru/tasks/320069/ xmp-4.1.0-alt1: https://packages.altlinux.org/ru/tasks/320071/
Глеб, мы можем двигаться дальше или ещё пакетиков пособирать в текущем режиме -- меня устраивают оба варианта, внимания должны потребовать сопоставимо. Т.е. технически Артём уже освоился, дальше этап наработки опыта.
Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
https://git.altlinux.org/tasks/archive/done/_312/319949/gears/100/git?p=git;a=blob;f=xisxwayland.spec;h=da526f3fcfc9c55cd37d546726946166966910bb;hb=fd1dc394bd77d7390d4c3af5ef3c5a29edfac812 Поле Packager лучше не использовать - оно само заполнится на основании того, кто собирал пакет. Добавьте тэг VCS, с этим тэгом наши системы получат возможность автоматически отслеживать новые версии. VCS: https://gitlab.freedesktop.org/xorg/app/xisxwayland Как вариант - в качестве homepage указать URL на gitlab. Дело в том, что внешние системы поиска и сравнения пакетов часто используют Homepage для идентификации пакета. Общее пожелание - при наличии живого и доступного апстримного git лучше собирать из него по схеме .gear поверх апстрима, в этом случае у нас локально будет храниться вся история изменения и в целом работа с апстримными исходниками станет несколько проще (например, будет возможность делать cherry-pick патчей). Если пишете Changelog с большой буквы, то заканчивайте на точку, как предложение.
https://git.altlinux.org/tasks/archive/done/_312/320003/gears/100/git?p=git;a=tree;h=643284e70335e753549407265f207bbfc6e50dd0;hb=643284e70335e753549407265f207bbfc6e50dd0 замечания аналогичные.
vimpager: https://git.altlinux.org/tasks/archive/done/_312/320069/gears/100/git?p=git;a=tree;h=9e86fa9b31a443693452ccfe0ff77a6fc176cd3e;hb=9e86fa9b31a443693452ccfe0ff77a6fc176cd3e Поле Packager тоже лишнее, убирайте его (и скажите, пожалуйста, где у нас написано про обязательность использования этого поля, я это место поправлю) Не совсем понятно почему исключён из поиска зависимостей vimcat, что именно падает и с какой диагностикой ? Возможно этот комментарий надо расширить, что бы было более понятно в чём проблема.
К пакету xmp замечания такие же как и к пакету xisxwayland https://git.altlinux.org/tasks/archive/done/_312/320071/gears/100/git?p=git;a=blob_plain;f=xmp.spec;hb=1b01b9be27a97716ba413e7fc2deacd10e258125
https://git.altlinux.org/tasks/archive/done/_306/314230/gears/100/git?p=git;a=blob;f=.gear/termgraph.spec;h=305721185ca98c2bfaf4ec24950e7c4276a379bb;hb=5e15ec70fcbfe2abdd763bb61f686da899341a78 Поле Packager лучше не использовать - оно само заполнится на основании того, кто собирал пакет. Если пишете запись в Changelog с большой буквы, то ставьте в конце точку.
(Ответ для Anton Farygin на комментарий #30) > https://git.altlinux.org/tasks/archive/done/_306/314230/gears/100/git?p=git; > a=blob;f=.gear/termgraph.spec;h=305721185ca98c2bfaf4ec24950e7c4276a379bb; > hb=5e15ec70fcbfe2abdd763bb61f686da899341a78 > > Поле Packager лучше не использовать - оно само заполнится на основании того, > кто собирал пакет. > > Если пишете запись в Changelog с большой буквы, то ставьте в конце точку. Не туда:)
Точно. Ещё рекомендую ознакомиться с документами: Имя патча лучше всего сделать в соответствии с правилами именования патчей: https://www.altlinux.org/ALT_Packaging_HOWTO#%D0%9D%D0%B0%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D1%82%D1%87%D0%B5%D0%B9 Changelog надо или заканчивать точкой или начинать с маленькой буквой: https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog
Ну и в целом, работа проделана хорошая, но единообразная. Хотелось бы увидеть работу кандидата с пакетами, содержащими Shared библиотеки, для понимания https://www.altlinux.org/Shared_Libs_Policy
> Не совсем понятно почему исключён из поиска зависимостей vimcat, что именно > падает и с какой диагностикой ? Возможно этот комментарий надо расширить, > что бы было более понятно в чём проблема. Даже не знаю как именно расширять комментарий по этому поводу: BUILDROOT/vimpager-buildroot/usr/bin/vimcat: line 235: syntax error near unexpected token `)' BUILDROOT/vimpager-buildroot/usr/bin/vimcat: line 235: `" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND' shell.req: ERROR: BUILDROOT/vimpager-buildroot/usr/bin/vimcat: /bin/sh --rpm-requires failed find-requires: ERROR: /usr/lib/rpm/shell.req failed ошибка: /bin/sh failed ошибка: Failed to find Requires
(In reply to Артём Курашов from comment #34) > > Не совсем понятно почему исключён из поиска зависимостей vimcat, что именно > > падает и с какой диагностикой ? Возможно этот комментарий надо расширить, > > что бы было более понятно в чём проблема. > > Даже не знаю как именно расширять комментарий по этому поводу: > BUILDROOT/vimpager-buildroot/usr/bin/vimcat: line 235: syntax error near > unexpected token `)' > BUILDROOT/vimpager-buildroot/usr/bin/vimcat: line 235: `" LOSS OF USE, DATA, > OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND' > shell.req: ERROR: BUILDROOT/vimpager-buildroot/usr/bin/vimcat: /bin/sh > --rpm-requires failed > find-requires: ERROR: /usr/lib/rpm/shell.req failed > ошибка: /bin/sh failed > ошибка: Failed to find Requires Вы пакуете shell-скрипт, в котором синтаксическая ошибка, из-за этого пакет не собирается. Вместо того, чтобы исправить ошибку в скрипте, вы решаете проблему сборки пакета путём отключения диагностики синтаксических ошибок в скрипте.
Там многострочный комментарий. То, что он не понравился парсеру, ещё не значит, что в скрипте действительно есть ошибка. Просто таковы особенности парсера. Если объединить строки комментария в одну, то получится очень длинная строка. Автор разбил комментарий на строки чтобы их ширина не превышала 80 символов. Но при этом открывающая и закрывающая скобки оказались на разных строках этого многострочного комментария, что и не понравилось парсеру.
В общем, формат vimcat'а не предполагает выполнение его как просто shell скрипта. Он выполняется в vim'е. Для этого в нём второй строчкой прописано "#!/usr/bin/env vim". Попробовал оставить только эту строчку и удалить первую строчку "#!/bin/sh". Результат не совсем тот, который ожидался. Парсер перестал ругаться на vimcat, но в итоге он просто открывает в vim'е самого себя.
да, согласен - скрипт совсем не простой и парсер shell просто не понимает такую конструкцию. @ldv можешь глянуть на него внимательнее ? я согласен с Артёмом что такой скрипт не получится адекватно разобрать парсером для поиска зависимостей.
Извиняюсь, выпадал из процесса вступления. Итак, теперь получилось вот это: xmp 4.2.0-alt1: https://packages.altlinux.org/ru/tasks/323810/ libnvme1 1.6-alt1.g4fe9e40: https://packages.altlinux.org/ru/tasks/334959/ bvi 1.4.2-alt2: https://packages.altlinux.org/ru/tasks/335638/ vimpager 2.06-alt2: https://packages.altlinux.org/ru/tasks/335641/ xisxwayland 2-alt2: https://packages.altlinux.org/ru/tasks/335642/ libnvme в моё отсутствие успели добавить в Сизиф, но в версии без Python'овских биндингов. У меня версия с Python'овскими биндингами.
(Ответ для Артём Курашов на комментарий #39) > Извиняюсь, выпадал из процесса вступления. > > Итак, теперь получилось вот это: > xmp 4.2.0-alt1: https://packages.altlinux.org/ru/tasks/323810/ А почему xmp собран из тарболла а не из гита ?
Ко всем остальным проектам вопрос такой же.
Вот этот коммит не нужен, можно просто переделать все предыдущие https://git.altlinux.org/tasks/335642/gears/100/git?p=git;a=commit;h=34ca5db8bee4caf89a2ae9033ca6b393d2b31b1d
(Ответ для Артём Курашов на комментарий #39) > libnvme в моё отсутствие успели добавить в Сизиф, но в версии без > Python'овских биндингов. У меня версия с Python'овскими биндингами. Тогда нужно их добавить к той версии, которая уже есть в репозитории с увеличением релиза.
> А почему xmp собран из тарболла а не из гита ? xmp выкладывают на sourceforge.net тарболами. В git'е только зеркало. С bvi тоже самое, только нормального зеркала в git'е в его случае вообще нет. Ещё xisxwayland из тарбола. Там было 2 релиза, теперь его пока что не развивают дальше. А vimpager и libnvme1 я собирал из git'а.
(Ответ для Anton Farygin на комментарий #42) > Вот этот коммит не нужен, можно просто переделать все предыдущие > https://git.altlinux.org/tasks/335642/gears/100/git?p=git;a=commit; > h=34ca5db8bee4caf89a2ae9033ca6b393d2b31b1d Могу и передалать, просто предыдущая версия xisxwayland'а уже в Сизифе: https://packages.altlinux.org/ru/sisyphus/srpms/xisxwayland/ . Поэтому я думал, что переделать без нового коммита нельзя.
(Ответ для Артём Курашов на комментарий #45) > (Ответ для Anton Farygin на комментарий #42) > > Вот этот коммит не нужен, можно просто переделать все предыдущие > > https://git.altlinux.org/tasks/335642/gears/100/git?p=git;a=commit; > > h=34ca5db8bee4caf89a2ae9033ca6b393d2b31b1d > Могу и передалать, просто предыдущая версия xisxwayland'а уже в Сизифе: > https://packages.altlinux.org/ru/sisyphus/srpms/xisxwayland/ . Поэтому я > думал, что переделать без нового коммита нельзя. Точно, всё верно. Не заметил.
(Ответ для Артём Курашов на комментарий #44) > > А почему xmp собран из тарболла а не из гита ? > xmp выкладывают на sourceforge.net тарболами. В git'е только зеркало. Это не оно? https://github.com/libxmp/xmp-cli
Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6.
(Ответ для Anton Farygin на комментарий #47) > (Ответ для Артём Курашов на комментарий #44) > > > А почему xmp собран из тарболла а не из гита ? > > xmp выкладывают на sourceforge.net тарболами. В git'е только зеркало. > > Это не оно? > https://github.com/libxmp/xmp-cli Этот адрес я прописал в .spec в VCS, но, по ходу, это только зеркало. А основной адрес: https://xmp.sourceforge.net/ .
(Ответ для Anton Farygin на комментарий #43) > (Ответ для Артём Курашов на комментарий #39) > > libnvme в моё отсутствие успели добавить в Сизиф, но в версии без > > Python'овских биндингов. У меня версия с Python'овскими биндингами. > > Тогда нужно их добавить к той версии, которая уже есть в репозитории с > увеличением релиза. Вот, добавил к той версии: https://packages.altlinux.org/ru/tasks/335844/ .
Насколько понимаю, мячик на моей стороне; мнение то же, человека давно жду в команде: (Ответ для Michael Shigorin на комментарий #23) > Т.е. технически Артём уже освоился, дальше этап наработки опыта. (включая различные классы пакетов и далее со всеми остановками) Артём, по поводу подобных коммитов: http://git.altlinux.org/tasks/archive/done/_327/335844/gears/100/git?p=git;a=commitdiff;h=20104d4827d0cfff78aba3f9582a51afd74ef9e0 -- постарайтесь _изменения_ и _описание_ оформлять отдельно (т.е. сделали всё, закоммитили; поправили версию и/или релиз, дополнили %changelog, gear-commit -a): это облегчает перенос правок между ветками. Например, поправили что-то точечно в сизифе, но ровно это же изменение было бы полезно и для той версии, что в бранче -- можно делать заново то же самое или чпикать с конфликтом, но гораздо удобнее cherry-pick'нуть само необходимое изменение, а оформление произвести заново.
(Ответ для Michael Shigorin на комментарий #51) > Артём, по поводу подобных коммитов: > http://git.altlinux.org/tasks/archive/done/_327/335844/gears/100/git?p=git; > a=commitdiff;h=20104d4827d0cfff78aba3f9582a51afd74ef9e0 -- постарайтесь > _изменения_ и _описание_ оформлять отдельно (т.е. сделали всё, закоммитили; > поправили версию и/или релиз, дополнили %changelog, gear-commit -a): это > облегчает перенос правок между ветками. > > Например, поправили что-то точечно в сизифе, но ровно это же изменение было > бы полезно и для той версии, что в бранче -- можно делать заново то же самое > или чпикать с конфликтом, но гораздо удобнее cherry-pick'нуть само > необходимое изменение, а оформление произвести заново. Хорошо, постараюсь.
Я жду от вас изменений на review.
Странно. Я был уверен, что я уже всё исправил ранее.
Напишите что нужно посмотреть и я посмотрю.
В 39-м комментарии я привёл ссылки на task'и, где я всё переделал. После этого были вопросы про источники (тарболы и git'ы), коммит и добавление Python'овских биндингов к версии библиотеки из Сизифа. Вот те самые ссылки на таски: xmp 4.2.0-alt1: https://packages.altlinux.org/ru/tasks/323810/ libnvme1 1.6-alt1.g4fe9e40: https://packages.altlinux.org/ru/tasks/334959/ bvi 1.4.2-alt2: https://packages.altlinux.org/ru/tasks/335638/ vimpager 2.06-alt2: https://packages.altlinux.org/ru/tasks/335641/ xisxwayland 2-alt2: https://packages.altlinux.org/ru/tasks/335642/ После этого я собирал https://packages.altlinux.org/ru/tasks/335844/ . Результат уже был Вами одобрен и уже в Сизифе.
xmp всё-таки есть git (ажно два) и я рекомендую собрать его не из тарболла, а из апстримного гита. Ссылки на git тут: https://xmp.sourceforge.net/
libnvme1 - не понял разницы с libnvme: https://packages.altlinux.org/ru/tasks/334959/ https://packages.altlinux.org/ru/tasks/335844/ Зачем нужен ещё один пакет ?
vimpager 2.06-alt2: https://packages.altlinux.org/ru/tasks/335641/ Патч с alt-fixes странный. Зачем он нужен ? Для того, что бы не вылезали лишние зависимости - можно использовать переменные.
xisxwayland 2-alt2: https://packages.altlinux.org/ru/tasks/335642/ уже заапрувлен.
(Ответ для Anton Farygin на комментарий #60) > vimpager 2.06-alt2: https://packages.altlinux.org/ru/tasks/335641/ > Патч с alt-fixes странный. Зачем он нужен ? > Для того, что бы не вылезали лишние зависимости - можно использовать > переменные. Пути к лишним shell'ам уже прописаны в скрипте из апстрима. Парсер при сборке пакета ищет другие пакеты с ними, считая их важными зависимостями, и падает когда их не находит.
(Ответ для Anton Farygin на комментарий #59) > libnvme1 - не понял разницы с libnvme: > https://packages.altlinux.org/ru/tasks/334959/ > https://packages.altlinux.org/ru/tasks/335844/ > Зачем нужен ещё один пакет ? libnvme1 собирал я сам чтобы продемонстрировать то, что я уже умею собирать библиотеки (ответ на Ваше задание из комментария 33).
(Ответ для Артём Курашов на комментарий #63) > (Ответ для Anton Farygin на комментарий #59) > > libnvme1 - не понял разницы с libnvme: > > https://packages.altlinux.org/ru/tasks/334959/ > > https://packages.altlinux.org/ru/tasks/335844/ > > Зачем нужен ещё один пакет ? > libnvme1 собирал я сам чтобы продемонстрировать то, что я уже умею собирать > библиотеки (ответ на Ваше задание из комментария 33). Не надо эмулировать задачи, надо собирать то что нужно - это задание надо удалить, оно ошибочное.
(Ответ для Anton Farygin на комментарий #64) > (Ответ для Артём Курашов на комментарий #63) > > (Ответ для Anton Farygin на комментарий #59) > > > libnvme1 - не понял разницы с libnvme: > > > https://packages.altlinux.org/ru/tasks/334959/ > > > https://packages.altlinux.org/ru/tasks/335844/ > > > Зачем нужен ещё один пакет ? > > libnvme1 собирал я сам чтобы продемонстрировать то, что я уже умею собирать > > библиотеки (ответ на Ваше задание из комментария 33). > > Не надо эмулировать задачи, надо собирать то что нужно - это задание надо > удалить, оно ошибочное. Ну, на тот момент в Сизифе этой библиотеки ещё не было (а у меня эта библиотека уже была (https://disk.yandex.ru/d/V6jCPZ92Ln3L8A); мне оставалось только допилить её под стандарты ALT'а). Меня просто опередили с добавлением. Поэтому я пришёл к выводу, что для демонстрирования того, что я уже умею собирать библиотеки, она подойдёт. А потом можно будет и удалить, да.
Не подойдёт, т.к. некоторые проблемы видно будет только после попадания пакета в репозиторий. Предлагаю исправить замечания выше.
(Ответ для Anton Farygin на комментарий #66) > Не подойдёт, т.к. некоторые проблемы видно будет только после попадания > пакета в репозиторий. > > Предлагаю исправить замечания выше. Значит, мне придётся искать библиотеку, которой нет в Сизифе. А вот xmp собранный из git'а: https://packages.altlinux.org/ru/tasks/336648/ .
(Ответ для Anton Farygin на комментарий #64) > > > libnvme1 - не понял разницы с libnvme: > > libnvme1 собирал я сам чтобы продемонстрировать то, что я уже умею собирать > > библиотеки (ответ на Ваше задание из комментария 33). > Не надо эмулировать задачи, надо собирать то что нужно Вот человек и собирает то, что ему нужно. > - это задание надо удалить, оно ошибочное. Это _требование_ надо удалить, оно ошибочное. И где регламент по добавлению требований в регламент приёма людей в команду? Там точно должен быть пункт против произвольного произвола. От своих сотрудников требуй чего сочтёшь нужным, но у нас есть люди, которые собирают полезные пакеты и не собирают библиотек вообще; например, ogion@ сопровождает несколько химических пакетов как специалист, ему тоже надо было уметь собирать библиотеки? Глеб, предлагаю докоп по библиотекам отклонить как таковой.
(Ответ для Артём Курашов на комментарий #67) > (Ответ для Anton Farygin на комментарий #66) > > Не подойдёт, т.к. некоторые проблемы видно будет только после попадания > > пакета в репозиторий. > > > > Предлагаю исправить замечания выше. > > Значит, мне придётся искать библиотеку, которой нет в Сизифе. Ну или просто новую версию той, которая есть. > > А вот xmp собранный из git'а: https://packages.altlinux.org/ru/tasks/336648/ changelog rpm пакета говорит что собрано из git, но для пользователя пакета это не несёт никакого смысла. Лучше просто написать об обновлении версии и убрать лишние коммиты и записи в changelog.
(Ответ для Anton Farygin на комментарий #60) > vimpager 2.06-alt2: https://packages.altlinux.org/ru/tasks/335641/ > Патч с alt-fixes странный. Зачем он нужен ? > Для того, что бы не вылезали лишние зависимости - > можно использовать переменные. Можно, особенно если предлагать в апстрим -- тогда патч получается универсальным, хотя код и грязнеет (вне контекста автоматического поиска зависимостей читать такое -- глазами больше спотыкаться). Артём, альтовый анализатор зависимостей игнорирует запуски чего-либо с выставлением переменных -- наиболее типовой вариант патчей (или кусочков своих скриптов), о которых говорит Антон, выглядит как-то так: - exec /usr/xpg4/bin/sh "$0" "$@" + a= exec /usr/xpg4/bin/sh "$0" "$@" Но в данном случае я бы переделывать не стал, если апстримить не собираетесь. Ещё есть макрос filter_from_requires -- см. тж. http://altlinux.org/Spec/Предопределенные_макросы; пример из первого попавшегося 389-ds-base.spec: %filter_from_requires /python3(gdb\(\..*\)\?)/d Копия http://git.altlinux.org/people/specbot/public/specs.git в помощь :)
> чтобы не вылезали лишние зависимости - можно использовать переменные Написал статью: http://altlinux.org/Игнорирование_зависимостей_при_сборке -- спасибо вам обоим, что дали материал под руку, давно пора было.
(Ответ для Anton Farygin на комментарий #69) > (Ответ для Артём Курашов на комментарий #67) > > (Ответ для Anton Farygin на комментарий #66) > > > Не подойдёт, т.к. некоторые проблемы видно будет только после попадания > > > пакета в репозиторий. > > > > > > Предлагаю исправить замечания выше. > > > > Значит, мне придётся искать библиотеку, которой нет в Сизифе. > > Ну или просто новую версию той, которая есть. В каком смысле новую? Что ей будет демонстрироваться? Если речь об обновлении уже имеющейся в Сизифе библиотеки, то принципиально новая сборка для этого не подойдёт, поскольку она не будет унаследована от имеющейся в Сизифе версии. Собственно, я выше выкладывал две разные версии библиотеки libnvme. Одна принципиально другая, которую я не из Сизифа брал, поэтому в ней сразу у меня были Python'овские биндинги, сборку которых мне оставалось лишь допилить для хэшера, что я и сделал. И вторая версия: улучшенная мной версия из Сизифа, куда я перенёс Python'овские биндинги из своей версии. А так вот ещё, например, libretro-fceumm 0.1-alt1.gd11428d: https://packages.altlinux.org/ru/tasks/336663/ . > > > > А вот xmp собранный из git'а: https://packages.altlinux.org/ru/tasks/336648/ > > changelog rpm пакета говорит что собрано из git, но для пользователя пакета > это не несёт никакого смысла. Лучше просто написать об обновлении версии и > убрать лишние коммиты и записи в changelog. xmp 4.2.0-alt1 (такой версии в Сизифе пока ещё не было, поэтому сплющил до неё): https://packages.altlinux.org/ru/tasks/336679/ .
(Ответ для Артём Курашов на комментарий #72) > xmp 4.2.0-alt1 (такой версии в Сизифе пока ещё не было, поэтому сплющил до > неё): https://packages.altlinux.org/ru/tasks/336679/ . Только опять потерялась сборка из апстримного гита.
(Ответ для Артём Курашов на комментарий #72) > (Ответ для Anton Farygin на комментарий #69) > > (Ответ для Артём Курашов на комментарий #67) > > > Значит, мне придётся искать библиотеку, которой нет в Сизифе. > > > > Ну или просто новую версию той, которая есть. > В каком смысле новую? Что ей будет демонстрироваться? Если речь об > обновлении уже имеющейся в Сизифе библиотеки, то принципиально новая сборка > для этого не подойдёт, поскольку она не будет унаследована от имеющейся в > Сизифе версии. > Нет, я имел ввиду обновление _других_ библиотек в Sisyphus. > > А так вот ещё, например, libretro-fceumm 0.1-alt1.gd11428d: > https://packages.altlinux.org/ru/tasks/336663/ . Это вообще не пакет, а ошибка какая-то. Оно не то что нашему - оно в принципе не соответствует правилам сборки Shared библиотек - версий нет никаких. https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
(Ответ для Anton Farygin на комментарий #73) > (Ответ для Артём Курашов на комментарий #72) > > xmp 4.2.0-alt1 (такой версии в Сизифе пока ещё не было, поэтому сплющил до > > неё): https://packages.altlinux.org/ru/tasks/336679/ . > > Только опять потерялась сборка из апстримного гита. Не то, чтобы потерялась. Это такая же версия как и предыдущая, только сплющенная. Исходники там из git'а. Да, директория xmp/.git не вошла в дерево исходников, так почему-то не происходит. А если создавать репозиторий с нуля, то туда и не войдут коммиты, которые пришлось бы сплющивать. При этом сборочница выдаёт "gears inheritance check FAILED", поскольку пакет уже есть в Сизифе. Хотя, по ходу, так было бы правильнее, да.
(Ответ для Anton Farygin на комментарий #74) > Это вообще не пакет, а ошибка какая-то. Оно не то что нашему - оно в > принципе не соответствует правилам сборки Shared библиотек - версий нет > никаких. > > https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html Это не полноценная shared библиотека, да. Она не сама по себе работает. Её подгружает RetroArch. Поэтому она и не в самой %_libdir располагается.
> Да, директория xmp/.git не вошла в дерево исходников, так почему-то не происходит. Смержил потерянный xmp/.git как ветку upstream/master: https://git.altlinux.org/people/saahriktu/packages/?p=xmp.git;a=commit;h=3ea00cb96e8213eba419cf9710e4a103590e9662 .
(Ответ для Артём Курашов на комментарий #76) > (Ответ для Anton Farygin на комментарий #74) > > Это вообще не пакет, а ошибка какая-то. Оно не то что нашему - оно в > > принципе не соответствует правилам сборки Shared библиотек - версий нет > > никаких. > > > > https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html > > Это не полноценная shared библиотека, да. Она не сама по себе работает. Её > подгружает RetroArch. Поэтому она и не в самой %_libdir располагается. Это просто плагин к библиотеке, но в его сборке есть ошибка. Попросите, пожалуйста, вашего ментора объяснить в чём именно.
(Ответ для Anton Farygin на комментарий #78) > (Ответ для Артём Курашов на комментарий #76) > > (Ответ для Anton Farygin на комментарий #74) > > > Это вообще не пакет, а ошибка какая-то. Оно не то что нашему - оно в > > > принципе не соответствует правилам сборки Shared библиотек - версий нет > > > никаких. > > > > > > https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html > > > > Это не полноценная shared библиотека, да. Она не сама по себе работает. Её > > подгружает RetroArch. Поэтому она и не в самой %_libdir располагается. > > Это просто плагин к библиотеке, но в его сборке есть ошибка. Попросите, > пожалуйста, вашего ментора объяснить в чём именно. К сожалению стало только хуже. Для перехода с одной схемы сборки на другую вам нужно: 1) объединить несовместимые истории через git merge с ours без коммита 2) сбросить дерево до состояния апстримного тэга, c которым идёт объединение 3) забрать из вашего HEAD specfile и .gear Если возникнут сложности - попросите ментора помочь.
(Ответ для Michael Shigorin на комментарий #68) > > Не надо эмулировать задачи, надо собирать то что нужно > Вот человек и собирает то, что ему нужно. > > - это задание надо удалить, оно ошибочное. > Это _требование_ надо удалить, оно ошибочное. [...] > Глеб, предлагаю докоп по библиотекам отклонить как таковой. (Ответ для Anton Farygin на комментарий #78) > > Это не полноценная shared библиотека, да. Она не сама по себе работает. > > Её подгружает RetroArch. Поэтому она и не в самой %_libdir располагается. > Это просто плагин к библиотеке, но в его сборке есть ошибка. > Попросите, пожалуйста, вашего ментора объяснить в чём именно. Ментор всё так же просит ревьюера пояснить смысл требования сборки библиотеки. Артём, при сомнениях с мержами лучше пишите сразу, наобум точно не надо -- кашу после попадания в репозиторий бывает легче разрубить, чем расхлебать, а это чревато потерей сведений о трудах предшественников.
Ошибки при сборке библиотек с нарушениями SharedLibsPolicy нормально могут быть исправлены только при сборке новой версии библиотеки с изменением Soname, соответственно они очень критичны. Делают их обычно малоопытные ментейнеры. Поэтому лучше убедиться в умении обращаться с такими случаями до того момента, как ограничения на review у кандидата будет снято.
(Ответ для Anton Farygin на комментарий #79) > К сожалению стало только хуже. Переделал формат репозитория в соответствии с описанным на https://www.altlinux.org/Gear/tags . Теперь в ветке master хранятся только .gear со .spec'ом, а исходники хранятся в ветке upstream. https://packages.altlinux.org/ru/tasks/336827/ .
(Ответ для Артём Курашов на комментарий #82) > https://packages.altlinux.org/ru/tasks/336827/ . Прошу прощения, а это так и задумано: 25 %setup -n %name-%version/%name ?
(Ответ для Andrew Vasilyev на комментарий #83) > (Ответ для Артём Курашов на комментарий #82) > > https://packages.altlinux.org/ru/tasks/336827/ . > > Прошу прощения, а это так и задумано: > > 25 %setup -n %name-%version/%name > > ? Спасибо, пригляделся и нашёл свою ошибку. Вот даже просто беру и переделываю свой репозиторий со старого коммита. Локально в хэшере собирается хорошо, сборочница ругается на ненайденный тег. Делаю "gear-store-tags -acv && gear-create-tag -f" - вылазят удалённые файлы... Надо с этим доразобраться, да.
Разобрался. В моём случае выполнение "gear-store-tags -acv" было лишним, достаточно было "gear-create-tag -f". https://packages.altlinux.org/ru/tasks/336853/ .
https://git.altlinux.org/tasks/336853/gears/100/git?p=git;a=tree;h=3781e9bff36d968579cedfc00e1c6eeafd2ecc03;hb=3781e9bff36d968579cedfc00e1c6eeafd2ecc03 Дерево апстримное куда потерялось ?
(Ответ для Anton Farygin на комментарий #86) > https://git.altlinux.org/tasks/336853/gears/100/git?p=git;a=tree; > h=3781e9bff36d968579cedfc00e1c6eeafd2ecc03; > hb=3781e9bff36d968579cedfc00e1c6eeafd2ecc03 > Дерево апстримное куда потерялось ? Оно в ветке upstream в соответствии с https://www.altlinux.org/Gear/tags. Веб интерфейс git.altlinux.org эту ветку не отображает, поскольку и в случае "git checkout master" содержимое ветки upstream не видно. Но gear оттуда извлекает исходники при сборке. Если выполнить "git rebase", то содержимое ветки upstream появится и в ветке master, но это не то, что нужно, тем более, что в этом случае потеряется наследование и сборочница выдаст ошибку "gears inheritance check FAILED".
Нет, это не то. Так делать плохо. Я ожидаю что-то вроде этого: https://git.altlinux.org/gears/c/curl.git?p=curl.git;a=tree;h=a4c50ee72c2da5ca62e78883bbe570573fc6c791;hb=a4c50ee72c2da5ca62e78883bbe570573fc6c791
(Ответ для Anton Farygin на комментарий #88) > Нет, это не то. Так делать плохо. > Я ожидаю что-то вроде этого: > https://git.altlinux.org/gears/c/curl.git?p=curl.git;a=tree; > h=a4c50ee72c2da5ca62e78883bbe570573fc6c791; > hb=a4c50ee72c2da5ca62e78883bbe570573fc6c791 Ну что же. Тогда чтобы не терялось наследование мне остаётся вариант с Git subtree merges. Добавил ветку с апстримом xmp-cli: $ git branch -a * master remotes/origin/master remotes/xmp-cli/master $ Исходники из xmp-cli/master скопированы в директорию xmp, что визуально не отличается от одного из прошлых вариантов. https://packages.altlinux.org/ru/tasks/336877/
Артём, попросите вашего ментора вам помочь. Вы делаете совсем не то, о чём я пишу.
(Ответ для Anton Farygin на комментарий #90) > Вы делаете совсем не то, о чём я пишу. Ты про git merge -s ours и вот это обсуждение? http://lore.altlinux.org/devel/20201105012407.052de7cd5e130426ad765305@altlinux.org/ Лично я теперь стараюсь вовсе избегать фиктивных мержей (и схемы упаковки а-ля led@, когда в gear'е "чисто спек и патчи") -- как справедливо упрекнул в своё время mithraen@, по такому даже не по'git grep'ать без выяснения, где тут собственно код (к сожалению, эту схему подхватили некоторые другие в команде). И делаю для своих проектов "всё в master", для чужих -- как правило, remote/upstream (git remote add upstream ... и при надобности git remote update upstream с последующим git merge upstream/master или по тегу). Делать выборки по тегу в .gear/rules тоже избегаю, поскольку на фоне постоянных прерываний это чревато ситуациями "патчишь-патчишь, собираешь-собираешь, проверяешь -- без изменений" (по той простой причине, что патчишь голову, а собираешь тег). А вообще это о том, что наш гибкий инструментарий gear давным-давно нуждается в профилирующем наборе утилит, которые бы позволили (и помогали) вести репозитории в одном из трёх устоявшихся форматов и которые было бы возможно задокументировать (в отличие от стихийно сложившейся практики).
Кстати, попался на глаза другой местами схожий случай: bug 38040 comment 43 (результат -- потеря интереса кандидатом).
http://bugzilla.altlinux.org/show_bug.cgi?id=38040#c43
Перевёл xmp на сборку из git'а: https://packages.altlinux.org/ru/tasks/337422/ . Также опакетил 3 своих библиотеки (сборка также из git'а): libcamell++: https://packages.altlinux.org/ru/tasks/350944/ libfatchars: https://packages.altlinux.org/ru/tasks/350836/ libhalfmk61: https://packages.altlinux.org/ru/tasks/350916/
(Ответ для Anton Farygin на комментарий #56) > Напишите что нужно посмотреть и я посмотрю. Здравствуйте. Я уже переделал пакет xmp и опакетил 3 своих библиотеки. https://bugzilla.altlinux.org/show_bug.cgi?id=45253#c94
ok, всё проверил и заапрувил.
я предлагаю ещё потренироваться на кошках, и обновить что-то из этого списка: curl -s https://git.altlinux.org/acl/list.packages.sisyphus|grep @nobody лучше, конечно, нужное.
Обновил fpc до версии 3.2.3 и пропатчил lazarus под новый fpc. Задание: https://packages.altlinux.org/ru/tasks/365054/ .
В дальнейшем я жду от вас задания в состоянии EPERM а не DONE. К работе над fpc вопросов очень много. Начиная с того, что URL там указан некорректный и заканчивая бардаком с патчами. Приведите пожалуйста всё в порядок - в состояние, которое можно ревьювить. Так, как будто этот пакет вы собираете первый раз в репозиторий (changelog только оставьте от старого). Я посмотрю. Примерно такие же вопросы к Lazarus.
(Ответ для Anton Farygin на комментарий #100) > В дальнейшем я жду от вас задания в состоянии EPERM а не DONE. > > К работе над fpc вопросов очень много. Начиная с того, что URL там указан > некорректный и заканчивая бардаком с патчами. > > Приведите пожалуйста всё в порядок - в состояние, которое можно ревьювить. > Так, как будто этот пакет вы собираете первый раз в репозиторий (changelog > только оставьте от старого). > > Я посмотрю. > > Примерно такие же вопросы к Lazarus. Здравствуйте. Вот переработанный fpc с упрощённой структурой подпакетов и адаптированный к текущей ситуации в Сизифе (https://bugzilla.altlinux.org/show_bug.cgi?id=56874), где из-за texlive не может быть пересобран пакет fpc-docs: https://packages.altlinux.org/ru/tasks/408975/ . Удаление пакета fpc-docs из-за бага в текущей версии texlive было согласовано с Андреем Черепановым, но дальнейшее упрощение структуры подпакетов он не одобрил по той причине, что у каждого пакета есть свой исторический смысл для системы.
Вы обсудили изменение в пакете с текущим ментейнером fpc и lazarus ?
(Ответ для Anton Farygin на комментарий #102) > Вы обсудили изменение в пакете с текущим ментейнером fpc и lazarus ? Во-первых, я выполнял Ваше задание по упрощению структуры .spec'а fpc чтобы Вы могли оценить мои умения работать со .spec'ами. Во-вторых, да, я вот и пишу, что я обсуждал изменения с Андреем Черепановым, который активно сопровождает fpc и lazarus. Удаление пакета fpc-docs из-за бага в текущей версии texlive он одобрил, а саму идею упрощения структуры подпакетов - нет. Так что, сама изначальная постановка задания была такой, что оно исключительно для Join, а не для прохождения в Сизиф.
нет, такого не бывает, что бы показать свои знания "только для JOIN". Посмотрите какие-то другие задачи.
И да, уж если вы меняете чужой пакет, то по крайней мере попробуйте разделить измненения на структурные части и коммитить их отдельно, а не одним большим коммитом "Fix compiler version in sources." Возвращаю ментору на доработку.
(Ответ для Anton Farygin на комментарий #104) > нет, такого не бывает, что бы показать свои знания "только для JOIN". > Посмотрите какие-то другие задачи. Давайте вернёмся к формулировке comment 0 -- если пакеты программ собственной разработки, которые Артём изначально собирался добавить в сизиф, где-то сейчас доступны, хорошо бы упомянуть текущее местоположение (saahriktu.tech всё). Касательно comment 33 -> comment 64 -- продолжаю настаивать, что это избыточное требование: про особенности сборки разделяемых библиотек на этом этапе стоит знать, но если в первоначальное и дополнительное задание они не вошли -- то и ладно; по той же логике можно затребовать сборку модуля ocaml или компиляцию под e2k, а то вдруг человек когда-то что-то сломает по не продемонстрированному на этапе join незнанию (ср.: comment 23, comment 68; по comment 81 тж. ниже). То есть эту часть обучения стоит перенести из join time назад в maintain time. (Ответ для Anton Farygin на комментарий #105) > И да, уж если вы меняете чужой пакет, то по крайней мере попробуйте > разделить измненения на структурные части и коммитить их отдельно, > а не одним большим коммитом "Fix compiler version in sources." Собственно, "поступай с другими так, как хотел бы, чтоб поступали с тобой". Отсматривать мегапатч, в котором всё про всё -- хлопотно и муторно. См. тж. comment 51, там про частный случай. Постучаться к майнтейнеру, когда по %changelog и гитам можно предположить, что он живой и на пакет не забил -- всегда лучше _до_ вложения существенных сил и времени на работы по нему, чтоб не получить результат на выброс (например, когда в работе новая версия или когда задуманное направление изменений противоречит пониманию предмета майнтейнером). Ну и меня стоило тоже в копию поставить. > Возвращаю ментору на доработку. Гм, а зачем разбрасываться заданиями весом со слона (comment 100) вместо того, чтоб отпинать ментора или самому указать на то, что это неудобоваримый со всех сторон кандидат -- сложный объёмный пакет с кучей взаимосвязей и перегруженным майнтейнером? И повторюсь в надцатый раз: зачем пытаться в младших классах переходить к дифференциальному исчислению, не пуская без него в средние? Всему своё время. По своим нынешним требованиям ты сам, Антон, наверняка бы в team не попал. А я -- так почти гарантированно. С учётом comment 81 я бы скорее целился на user level в сборочнице -- при сборке новичком до TESTED/EPERM новых классов пакетов, с которыми по опыту известны новичковые проблемы, ставить задание на отсмотр профильной группой старших товарищей (review_lib@, review_$lang@ и т.п.); успешная сборка одного или нескольких (возможно, с дифференцированным порогом) пакетов приводит к снятию автозапроса отсмотра. Ну, try/catch вместо попытки обложить вообще всё if'ами заранее. (Ответ для Anton Farygin на комментарий #78) > Попросите, пожалуйста, вашего ментора объяснить в чём именно. Прошу тормошить лично -- багопочту как прекратил регулярно читать в 2018 году по причине дикого перегруза, так и не восстановил это дело (изредка набегаю, но в целом сизиф уже несколько лет обходится по большей части без меня). (Ответ для Anton Farygin на комментарий #88) > Нет, это не то. Так делать плохо. А где у нас задокументированы стилистические указания вроде Secure Packaging? Иначе, извини, вкусовщина и "перепишите форму вот так" (сам когда-то столкнулся именно с таким явлением: одному сотруднику нравилось вот так, а другому -- так, как было заполнено ровно в предыдущий раз; с учётом пинга в неделю тогда сказал "давайте я сейчас в коридоре все эти четыре листа перепишу, но Вы их примете"). Проблема того, что gear позволяет почти как угодно; в gear-rules(5) есть разве что три примера -- второй из которых тебе, как понимаю, и не нравится -- и в остальном полная свобода действий с поправкой на хотя бы формальное наследование. То, что порой такое приводит к _худшему_ (более трудоёмкому и чреватому ошибками в подготовке и дальнейшем сопровождении кем бы то ни было, в т.ч. скриптом) результату -- насколько понимаю, является одной из причин того, что сборку из srpms в girar, было утерянную по сравнению со старинным incoming, всё-таки практически полноценно восстановили. Думаю, более разумно было бы вместо механического требования гита как раз выйти на понимание того, когда лучше собирать апстримный гит (у нас в сизифе хватает куда более актуальных примеров, если что), а когда брать тарболы даже при наличии гита (например, при автоматизации рутинных обновлений модулей). Также прошу озвучить критерии прохождения review, причём желательно -- применяемые на практике к сотрудникам обнинского или саратовского подразделения ООО "Базальт СПО". Глядя на результаты их работы -- в том числе несобираемые на e2k наши собственные разработки -- сомнения порой берут, что критерии были столь же тщательны (при обычно куда более низком техническом уровне кандидатов на входе -- но ведь дальше-то учатся). Иначе гонка может оказаться не просто за подвижной целью, а за миражом; но тогда нам стоит перестать вводить общественность в заблуждение, что проект заинтересован в новых участниках (http://altlinux.org/join).
> хорошо бы упомянуть текущее местоположение > (saahriktu.tech всё). А, да, точно. За это время https://saahriktu.tech успел переехать на ttps://saahriktu.ru .
> ttps://saahriktu.ru . Извините, https://saahriktu.ru .
Вот, скажем, во вполне себе аккуратно написанном по большей части mupdf.spec сейчас поправил такое: - XLDFLAGS="-g -L/usr/lib64" XLIBS="-lgdcmjpeg8" --trace + XLDFLAGS="-g -L%_libdir" XLIBS="-lgdcmjpeg8" --trace А кто это допустил прибившего гвоздём /usr/lib64 собирать пакеты в сизиф? Возвращать на стадию с подтверждением будем? :] (конечно, нет, это был бы бред -- но подсказать, заметив, явно стоило)
(Ответ для Anton Farygin на комментарий #105) > И да, уж если вы меняете чужой пакет, то по крайней мере попробуйте > разделить измненения на структурные части и коммитить их отдельно, а не > одним большим коммитом "Fix compiler version in sources." > Возвращаю ментору на доработку. Антон, а давай-ка вернём на доработку proskur@ по мотивам http://git.altlinux.org/tasks/archive/done/_401/411159/ и rm#225209: пожалуйста, хотя бы задания в p11, а лучше и в сизиф -- чтоб отсматривать, пока не подрастёт и не подрастеряет лишней самоуверенности. Ну или напишем на берегу (!) -- что должен уметь майнтейнер; по пунктам.
