Created attachment 9829 [details] Open ssh key Псевдоним - CausaPrincipalis71 Адрес пересылки почты - leonid@znamenok.com Имя ментора - Георгий Курячий. Почта - george@altlinux.org. Цель - просто помочь со сборкой чего-нибудь.
Мне кажется, CausaPrincipalis71 — слишком монструозный и незапоминающийся ник (особенно 71), у нас в сообществе нет особых проблем с выбором ника, это я вам как человек с ником george говорю) Поменяйте, пожалуйста, на что-нибудь более удобное в общении
Created attachment 9830 [details] Open gpg key
(Ответ для Fr. Br. George на комментарий #1) > Мне кажется, CausaPrincipalis71 — слишком монструозный и незапоминающийся > ник (особенно 71), у нас в сообществе нет особых проблем с выбором ника, это > я вам как человек с ником george говорю) > > Поменяйте, пожалуйста, на что-нибудь более удобное в общении Хорошо. Новые: Ник - ad_astra Почта - ytinka7@gmail.com
(In reply to Leonid from comment #3) > Ник - ad_astra Увы, так не получится: "Имя должно начинаться с буквы, содержать только буквы и цифры, быть не короче трёх символов;" https://www.altlinux.org/Процедура_принятия_в_Team
(Ответ для Gleb F-Malinovskiy на комментарий #4) > (In reply to Leonid from comment #3) > > Ник - ad_astra > > Увы, так не получится: > > "Имя должно начинаться с буквы, содержать только буквы и цифры, быть не > короче трёх символов;" > https://www.altlinux.org/Процедура_принятия_в_Team Хорошо, тогда прикрепляю новый ключ. Ник - respublica. В alt-gpgkeys был не занят.
Created attachment 9840 [details] New open gpg key
(In reply to Leonid from comment #6) > Created attachment 9840 [details] > New open gpg key В этом ключе два uid-а в домене altlinux.org, тот, который с подчёркиванием стоит удалить.
Created attachment 9841 [details] Open gpg key with only one uid Исправил
(In reply to Leonid from comment #0) > Created attachment 9829 [details] > Open ssh key Ok. (In reply to Leonid from comment #8) > Created attachment 9841 [details] > Open gpg key with only one uid Ok.
Подтверджаю своё менторство. Мне кажется, ключи в порядке. Можно потихоньку дальше идти. → 2.0
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
У кандидата уже несколько репозиториев рабочих. Есть предложение запустить человека на сборочницу. → 3.0
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.4.
Два пакета для готово https://git.altlinux.org/people/respublica/packages/?p=stockfish.git;a=summary https://git.altlinux.org/people/respublica/packages/?p=dconf-defaults-editor.git;a=summary
(Ответ для Leonid на комментарий #14) > https://git.altlinux.org/people/respublica/packages/?p=stockfish.git Поле "Release:" обозначает релиз пакета в репозитории, его не нужно увеличивать, если пакет туда не попал. Если вы разбиваете работу с пакетом на несколько коммитов (что совершенно правильно), сам релиз и Changelog меняются только один раз (с сообщением об этом в последнем коммите). Предлагаю воспользоваться тем, что пакет не опубликован и потренироваться в git rebase — поменять сообщения, релиз, и заодно убрать неиспользуемые закомментироанные строки. > https://git.altlinux.org/people/respublica/packages/?p=dconf-defaults-editor.git Если в самой программе ссылка на документацию? https://causaprincipalis71.github.io/dconf-defaults-editor/ Если нет, стоит подумать либо об этом, либо о том, чтобы как-то включить её в состав пакета, хотя бы в виде ссылки из файла README. P. S. Что там с package-into-appimage ? Правильно ли я понимаю, что hsh-rpm-into-appimage устарел, и сейчас у вас есть разнодистрибутивный продукт, который на ALT работает?
(Ответ для Fr. Br. George на комментарий #15) > > https://git.altlinux.org/people/respublica/packages/?p=stockfish.git > > Предлагаю воспользоваться тем, что пакет не опубликован и потренироваться в > git rebase — поменять сообщения, релиз, и заодно убрать неиспользуемые > закомментироанные строки. > Поправил > > https://git.altlinux.org/people/respublica/packages/?p=dconf-defaults-editor.git > Если в самой программе ссылка на документацию? > https://causaprincipalis71.github.io/dconf-defaults-editor/ > > Если нет, стоит подумать либо об этом, либо о том, чтобы как-то включить её > в состав пакета, хотя бы в виде ссылки из файла README. Ссылка из README уже есть, а саму программу сейчас перерабатываю > P. S. > > Что там с package-into-appimage ? Правильно ли я понимаю, что > hsh-rpm-into-appimage устарел, и сейчас у вас есть разнодистрибутивный > продукт, который на ALT работает? Там нужно рефакторинг сделать, слишком много хардкода
Считаю, что эти пакеты готовы и их можно пускать на сборку https://git.altlinux.org/people/respublica/packages/?p=stockfish.git https://git.altlinux.org/people/respublica/packages/?p=package-to-appimage.git
Меня призвали как соментора. В общем, я это подтверждаю.
(Ответ для Gleb F-Malinovskiy на комментарий #13) > ssh ключ на gyle.alt зарегистрирован. > Пакет alt-gpgkeys обновлён. > > T/J/S -> 3.4. Может 3.5? 3.4 как-то довольно необычно.
(In reply to Grigory Ustinov from comment #19) > Может 3.5? 3.4 как-то довольно необычно. Да, в процедуре в какой-то момент поменялся порядок пунктов.
Кандидат вроде бы освоил некоторые базовые принципы сборки пакетов. Я считаю, что нужно звать рецензента.
Из собранного: Stockfish https://git.altlinux.org/people/respublica/packages/?p=stockfish.git;a=summary TLPUI https://git.altlinux.org/people/respublica/packages/?p=tlpui.git;a=summary Cutechess https://git.altlinux.org/people/respublica/packages/?p=cutechess.git;a=summary Pychess https://git.altlinux.org/people/respublica/packages/?p=pychess.git;a=summary python3-module-chess https://git.altlinux.org/people/respublica/packages/?p=python3-module-chess.git;a=summary
Всё ещё ждём рецензента, кстати.
(Ответ для Leonid на комментарий #0) > Цель - просто помочь со сборкой чего-нибудь. О, а у меня что-нибудь есть, если что :) (Ответ для Leonid на комментарий #5) > Хорошо, тогда прикрепляю новый ключ. Ник - respublica. Из уважения к собственно смыслам слов... --- http://vitlav.livejournal.com/173879.html -> Например, после Французской революции, в некоторых переводах Аристотеля на французский язык, стали заменять латинское слово «республика», обозначавшее «политию», то есть третий хороший режим, греческим словом «демократия», у Аристотеля обозначавшее извращение этой самой политии, то есть наименее плохой из трёх плохих режимов. Затем такая подмена стала распространяться и на переводы и на другие языки, и в наши дни стала общепринятой. Таким образом, один из извращенных (плохих) политических режимов был переклассифицирован как хороший режим. --- http://rusk.ru/st.php?idar=52838
Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6.
Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
https://packages.altlinux.org/ru/sisyphus/srpms/mediamtx/specfiles/2970359690095238413#line-11 поле Packager уберите, пожалуйста и больше не используйте - у нас автоматически в это поле записывается тот, кто выполняет сборку пакета.
поле Packager надо убирать из всех ваших спек-файлов. Это можно делать по мере обновления, главное не забывать.
https://packages.altlinux.org/ru/sisyphus/srpms/cutechess/specfiles/2991872384523603320 - в описании сказано что это библиотека, но библиотеки в пакете я не нашёл.
при обновлении shotcut было бы неплохо пройтись по ошибкам в этом пакете: https://packages.altlinux.org/ru/sisyphus/srpms/shotcut/issues/2926170616378566879
(Ответ для Anton Farygin на комментарий #28) > поле Packager надо убирать из всех ваших спек-файлов. > Это можно делать по мере обновления, главное не забывать. Сделано https://git.altlinux.org/tasks/341040/ https://git.altlinux.org/tasks/341036/ (Ответ для Anton Farygin на комментарий #29) > https://packages.altlinux.org/ru/sisyphus/srpms/cutechess/specfiles/ > 2991872384523603320 - в описании сказано что это библиотека, но библиотеки в > пакете я не нашёл. Поправил https://git.altlinux.org/tasks/341045/
(Ответ для Leonid на комментарий #31) > (Ответ для Anton Farygin на комментарий #28) > > поле Packager надо убирать из всех ваших спек-файлов. > > Это можно делать по мере обновления, главное не забывать. > > Сделано > https://git.altlinux.org/tasks/341040/ https://git.altlinux.org/tasks/341040/gears/100/git?p=git;a=commitdiff;h=1184a64f3403cdd307f78646650cd6a1cfc31a2d в TLP UI убран desktop file. Это или ошибка, или должна быть описана причина для такого изменения в changelog. > https://git.altlinux.org/tasks/341036/ Спасибо, выдал approve. > > (Ответ для Anton Farygin на комментарий #29) > > https://packages.altlinux.org/ru/sisyphus/srpms/cutechess/specfiles/ > > 2991872384523603320 - в описании сказано что это библиотека, но библиотеки в > > пакете я не нашёл. > > Поправил > https://git.altlinux.org/tasks/341045/ changelog оформлен не по правилам оформления changelog, попросите пожалуйста вашего ментора их подробно разъяснить. 52 * Mon Feb 19 2024 Leonid Znamenok <respublica@altlinux.org> 1.3.1-alt2 53 - Corrected summary 54 55 * Fri Oct 06 2023 Leonid Znamenok <respublica@altlinux.org> 1.3.1-alt1 56 - New release 1.3.1 57 58 * Tue Jul 11 2023 Leonid Znamenok <respublica@altlinux.org> 1.3.0-alt0.beta4 59 - Initial build for Sisyphus
(Ответ для Anton Farygin на комментарий #32) > changelog оформлен не по правилам оформления changelog, попросите пожалуйста > вашего ментора их подробно разъяснить. > > 52 * Mon Feb 19 2024 Leonid Znamenok <respublica@altlinux.org> 1.3.1-alt2 > 53 - Corrected summary > 54 > 55 * Fri Oct 06 2023 Leonid Znamenok <respublica@altlinux.org> 1.3.1-alt1 > 56 - New release 1.3.1 > 57 > 58 * Tue Jul 11 2023 Leonid Znamenok <respublica@altlinux.org> > 1.3.0-alt0.beta4 > 59 - Initial build for Sisyphus Ментор сам не в курсе, что тут неправильного. Пока в тиме есть majioa@, все остальные ченджлоги выглядят вполне себе приемлемо.
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 тут всё сказано.
Ещё актуально ?
Да, в ближайшее время всё поправлю
Обновил пакеты: https://git.altlinux.org/tasks/368601/ https://git.altlinux.org/tasks/368600/ https://git.altlinux.org/tasks/368477/ Скорректировал стиль changelog'ов Поле Packager везде удалил
(In reply to Leonid from comment #37) > Обновил пакеты: > > https://git.altlinux.org/tasks/368601/ > https://git.altlinux.org/tasks/368600/ > https://git.altlinux.org/tasks/368477/ > > Скорректировал стиль changelog'ов > Поле Packager везде удалил https://git.altlinux.org/tasks/368601/gears/200/git?p=git;a=commitdiff;h=d2a68c416bb3f83e89f395bb65954b317f846974 А зачем сделан этот коммит ? Из описания коммита непонятно, чем не устроило стандартное поведение.
Аналогично тот - нет никакого смысла в такомм коммите писать что сделано - гораздо важнее написать зачем это сделано. https://git.altlinux.org/tasks/368477/gears/200/git?p=git;a=commitdiff;h=cf2d05983498d102dd11be53ca3d8a34a866c048
https://git.altlinux.org/tasks/368477/gears/200/git?p=git;a=blob;f=.gear/mediamtx.spec;h=e5000fed9be6e1cc0024f4ca081f887d6a2c9a67;hb=d5dba90f5449d62783e9e9137760b96556928808 в этом пакете, как будто бы не хватает .service файла для запуска его в качестве системного сервиса. Как предполагается использовать этот пакет ?
к #368600 у меня вопросов нет, заапрувил.
(Ответ для Anton Farygin на комментарий #38) > https://git.altlinux.org/tasks/368601/gears/200/git?p=git;a=commitdiff; > h=d2a68c416bb3f83e89f395bb65954b317f846974 > > А зачем сделан этот коммит ? Из описания коммита непонятно, чем не устроило > стандартное поведение. Мотивация была в том, чтобы упростить в будущем возможные наложения новых патчей при помочи gendiff, руководствовался https://www.altlinux.org/PatchHowto После изменений в коммите (добавления base=stockfish) есть возможность прямо внутри gear репозитория создать .orig файлы, внести изменения и создать патч через gendiff, который можно применять внутри спека. Без этого коммита в полученном патче пришлось бы ещё дописывать версию в пути применения. То есть валидный патч до изменений начинался бы так: --- stockfish-16/src/Makefile.orig 2023-07-19 17:38:44.506818016 +0300 +++ stockfish-16/src/Makefile 2023-07-19 17:40:58.684779063 +0300 После он может начинаться так: --- stockfish/CONTRIBUTING.md.orig 2025-01-13 15:39:57.009487500 +0300 +++ stockfish/CONTRIBUTING.md 2025-01-13 15:40:05.880526480 +0300 И второй вариант как раз получается при использовании gendiff в gear репозитории. Плюс ко всему первый вариант гарантированно ломается при любом обновлении версии - т.к. цифра в пути до исходников изменяется, и даже если патч валидный, то как минимум придётся поменять название директории. А это похоже на лишнюю работу, которая зашумляла бы общую картину изменений при обновлении. Как эту логику кратко высказать в описании к коммиту - не знаю. И она вообще корректная, или я исхожу из ложных предпосылок?
(Ответ для Anton Farygin на комментарий #39) > Аналогично тот - нет никакого смысла в такомм коммите писать что сделано - > гораздо важнее написать зачем это сделано. > > https://git.altlinux.org/tasks/368477/gears/200/git?p=git;a=commitdiff; > h=cf2d05983498d102dd11be53ca3d8a34a866c048 Локальная сборка падала с ошибкой go: cannot find GOROOT directory: 'go' binary is trimmed and GOROOT is not set В devel было обсуждение, в котором было сказано: "Как следствие GOROOT больше не константа, а пытается вычислиться. А для этого не хватает /proc." https://lists.altlinux.org/pipermail/devel/2023-August/217781.html Добавление BuildRequires: /proc починило локальную сборку, это изменение оставил. (Ну и зависимость на /proc есть практически у всех пакетов на go, мне показалось что эта зависимость там именно для исправления этой ошибки) (Ответ для Anton Farygin на комментарий #40) > https://git.altlinux.org/tasks/368477/gears/200/git?p=git;a=blob;f=.gear/ > mediamtx.spec;h=e5000fed9be6e1cc0024f4ca081f887d6a2c9a67; > hb=d5dba90f5449d62783e9e9137760b96556928808 > > в этом пакете, как будто бы не хватает .service файла для запуска его в > качестве системного сервиса. > > Как предполагается использовать этот пакет ? Я не уверен, что там нужен именно системный сервис. Сценарий использования в том, что делается копия/корректируется исходный mediamtx.yml с заданием нужных параметров, после чего от пользователя происходит запуск сервера. Идея создать отдельный сервис, который будет запускаться от рута, кажется довольно сомнительной. Идея создать отдельного пользователя под этот сервис - несколько избыточной. Поэтому я решил оставить только бинарник и изначальный конфиг, не добавляя ничего сверх того, что предоставляется апстримом.
(In reply to Leonid from comment #42) > (Ответ для Anton Farygin на комментарий #38) > > https://git.altlinux.org/tasks/368601/gears/200/git?p=git;a=commitdiff; > > h=d2a68c416bb3f83e89f395bb65954b317f846974 > > > > А зачем сделан этот коммит ? Из описания коммита непонятно, чем не устроило > > стандартное поведение. > > Мотивация была в том, чтобы упростить в будущем возможные наложения новых > патчей при помочи gendiff, руководствовался > https://www.altlinux.org/PatchHowto > > После изменений в коммите (добавления base=stockfish) есть возможность прямо > внутри gear репозитория создать .orig файлы, внести изменения и создать патч > через gendiff, который можно применять внутри спека. > > Без этого коммита в полученном патче пришлось бы ещё дописывать версию в > пути применения. > > То есть валидный патч до изменений начинался бы так: > --- stockfish-16/src/Makefile.orig 2023-07-19 17:38:44.506818016 +0300 > +++ stockfish-16/src/Makefile 2023-07-19 17:40:58.684779063 +0300 > > После он может начинаться так: > --- stockfish/CONTRIBUTING.md.orig 2025-01-13 15:39:57.009487500 +0300 > +++ stockfish/CONTRIBUTING.md 2025-01-13 15:40:05.880526480 +0300 > > И второй вариант как раз получается при использовании gendiff в gear > репозитории. > > Плюс ко всему первый вариант гарантированно ломается при любом обновлении > версии - т.к. цифра в пути до исходников изменяется, и даже если патч > валидный, то как минимум придётся поменять название директории. А это похоже > на лишнюю работу, которая зашумляла бы общую картину изменений при > обновлении. > > Как эту логику кратко высказать в описании к коммиту - не знаю. > И она вообще корректная, или я исхожу из ложных предпосылок? опция -p у %patch, почитайте пожалуйста. И попросите ментора рассказать подробнее про неё.
(In reply to Leonid from comment #43) > (Ответ для Anton Farygin на комментарий #39) > > Аналогично тот - нет никакого смысла в такомм коммите писать что сделано - > > гораздо важнее написать зачем это сделано. > > > > https://git.altlinux.org/tasks/368477/gears/200/git?p=git;a=commitdiff; > > h=cf2d05983498d102dd11be53ca3d8a34a866c048 > > Локальная сборка падала с ошибкой > go: cannot find GOROOT directory: 'go' binary is trimmed and GOROOT is not > set > > В devel было обсуждение, в котором было сказано: > "Как следствие GOROOT больше не константа, а пытается вычислиться. А > для этого не хватает /proc." > https://lists.altlinux.org/pipermail/devel/2023-August/217781.html > > Добавление BuildRequires: /proc починило локальную сборку, это изменение > оставил. > > (Ну и зависимость на /proc есть практически у всех пакетов на go, мне > показалось что эта зависимость там именно для исправления этой ошибки) Я понимаю зачем это было сделано, но в коммите про это ничего не сказано. По хорошему нужно какое-то похожее описание в коммит мессейдж.
> (Ответ для Anton Farygin на комментарий #40) > > https://git.altlinux.org/tasks/368477/gears/200/git?p=git;a=blob;f=.gear/ > > mediamtx.spec;h=e5000fed9be6e1cc0024f4ca081f887d6a2c9a67; > > hb=d5dba90f5449d62783e9e9137760b96556928808 > > > > в этом пакете, как будто бы не хватает .service файла для запуска его в > > качестве системного сервиса. > > > > Как предполагается использовать этот пакет ? > > Я не уверен, что там нужен именно системный сервис. Сценарий использования в > том, что делается копия/корректируется исходный mediamtx.yml с заданием > нужных параметров, после чего от пользователя происходит запуск сервера. > > Идея создать отдельный сервис, который будет запускаться от рута, кажется > довольно сомнительной. > Идея создать отдельного пользователя под этот сервис - несколько избыточной. > > Поэтому я решил оставить только бинарник и изначальный конфиг, не добавляя > ничего сверх того, что предоставляется апстримом. Запуск от обычного пользователя сервисов выглядит тоже ошибкой. Апстрим, судя по всему, ориентирован на использование службы в докере и этим всё объясняется.
(Ответ для Anton Farygin на комментарий #44) > опция -p у %patch, почитайте пожалуйста. Разобрался. Что с изменением делать?
Такой же вопрос и про сервис для mediamtx
(In reply to Leonid from comment #47) > (Ответ для Anton Farygin на комментарий #44) > > опция -p у %patch, почитайте пожалуйста. > > Разобрался. Что с изменением делать? не делать такое изменение.
(In reply to Leonid from comment #48) > Такой же вопрос и про сервис для mediamtx https://github.com/bluenviron/mediamtx?tab=readme-ov-file#linux
(Ответ для Anton Farygin на комментарий #49) > не делать такое изменение. + https://git.altlinux.org/tasks/368601/ (Ответ для Anton Farygin на комментарий #45) > Я понимаю зачем это было сделано, но в коммите про это ничего не сказано. По > хорошему нужно какое-то похожее описание в коммит мессейдж. (Ответ для Anton Farygin на комментарий #50) > https://github.com/bluenviron/mediamtx?tab=readme-ov-file#linux + https://git.altlinux.org/tasks/368477/
(In reply to Leonid from comment #51) > (Ответ для Anton Farygin на комментарий #49) > > не делать такое изменение. > + > > https://git.altlinux.org/tasks/368601/ Ещё заметил - надо поправить URL и прописать VCS. > > (Ответ для Anton Farygin на комментарий #45) > > Я понимаю зачем это было сделано, но в коммите про это ничего не сказано. По > > хорошему нужно какое-то похожее описание в коммит мессейдж. > (Ответ для Anton Farygin на комментарий #50) > > https://github.com/bluenviron/mediamtx?tab=readme-ov-file#linux > + > > https://git.altlinux.org/tasks/368477/ Этот заапрувил
(Ответ для Anton Farygin на комментарий #52) > Ещё заметил - надо поправить URL и прописать VCS. А что с URL исправить? https://stockfishchess.org доступен и это сайт проекта
в спеке http://
(Ответ для Anton Farygin на комментарий #52) > Ещё заметил - надо поправить URL и прописать VCS. + https://git.altlinux.org/tasks/368601/
Можно ещё одно обновление посмотреть? https://git.altlinux.org/tasks/369516/
Есть ещё обновление tlpui: https://git.altlinux.org/tasks/369541/ Но здесь затрагивается tlp, у которого lav@ мейнтейнер. Я ему написал, но пока ответа не было.
Ещё собрал scid_vs_pc https://git.altlinux.org/tasks/369607/
(In reply to Leonid from comment #57) > Есть ещё обновление tlpui: > https://git.altlinux.org/tasks/369541/ > > Но здесь затрагивается tlp, у которого lav@ мейнтейнер. > Я ему написал, но пока ответа не было. Заапрувил.
(In reply to Leonid from comment #58) > Ещё собрал scid_vs_pc > > https://git.altlinux.org/tasks/369607/ 23 Requires: %name-sounds = %version-%release вместо %version-%release лучше писать %EVR
(Ответ для Anton Farygin на комментарий #59) > Заапрувил. Спасибо (Ответ для Anton Farygin на комментарий #60) > вместо %version-%release лучше писать %EVR + https://git.altlinux.org/tasks/369607/
https://git.altlinux.org/tasks/369607/gears/500/git?p=git;a=commitdiff;h=92640357d42dc6fad366eac168b270bc8365f492 я задумался о причине, которая сподвигла сделать подпакет со звуками и не могу её понять.
(Ответ для Anton Farygin на комментарий #62) > https://git.altlinux.org/tasks/369607/gears/500/git?p=git;a=commitdiff; > h=92640357d42dc6fad366eac168b270bc8365f492 > > я задумался о причине, которая сподвигла сделать подпакет со звуками и не > могу её понять. Видимо, чтобы сделать его noarch и не пихать одно и то же во все бинарные пакеты?
(In reply to Andrew Vasilyev from comment #63) > (Ответ для Anton Farygin на комментарий #62) > > https://git.altlinux.org/tasks/369607/gears/500/git?p=git;a=commitdiff; > > h=92640357d42dc6fad366eac168b270bc8365f492 > > > > я задумался о причине, которая сподвигла сделать подпакет со звуками и не > > могу её понять. > > Видимо, чтобы сделать его noarch и не пихать одно и то же во все бинарные > пакеты? сэкономить 496 килобайт и добавить зависимостей и пакетов ? выглядит так себе.
(Ответ для Anton Farygin на комментарий #64) > > Видимо, чтобы сделать его noarch и не пихать одно и то же во все бинарные > > пакеты? > > сэкономить 496 килобайт и добавить зависимостей и пакетов ? > выглядит так себе. На общие файлы в /usr/share в бинарных пакетах, AFAIK, repocop будет ругаться...
(Ответ для Andrew Vasilyev на комментарий #65) > (Ответ для Anton Farygin на комментарий #64) > > > Видимо, чтобы сделать его noarch и не пихать одно и то же во все бинарные > > > пакеты? > > > > сэкономить 496 килобайт и добавить зависимостей и пакетов ? > > выглядит так себе. > > На общие файлы в /usr/share в бинарных пакетах, AFAIK, repocop > будет ругаться... Ну не то чтобы ругаться. Скорее бормотать что-то невнятное сквозь зубы. Не видел ни одного мейнтейнера, который бы посмотрел какое-нибудь сообщение от репокопа и такой: ой, да, пойду исправлю=)
В пакете общих файлов гораздо больше чем звуков.
(Ответ для Andrew Vasilyev на комментарий #63) > (Ответ для Anton Farygin на комментарий #62) > > https://git.altlinux.org/tasks/369607/gears/500/git?p=git;a=commitdiff; > > h=92640357d42dc6fad366eac168b270bc8365f492 > > > > я задумался о причине, которая сподвигла сделать подпакет со звуками и не > > могу её понять. > > Видимо, чтобы сделать его noarch и не пихать одно и то же во все бинарные > пакеты? Да, идея в этом, но до конца не довёл (Ответ для Anton Farygin на комментарий #64) > сэкономить 496 килобайт и добавить зависимостей и пакетов ? > > выглядит так себе. Сейчас подумал, что логичнее будет выделить всё содержимое usr/share/scid_vs_pc в отдельный -data пакет. Экономится уже почти 50 мегабайт, что выглядит получше
Вот так: https://git.altlinux.org/tasks/369607
Да, так смысл появился. спасибо. Заапрувил.
Что от меня ещё потребуется?
Я ещё бы понаблюдал. пособирайте библиотки. можно пройтись по FTBFS с ffmpeg, например.
https://packages.altlinux.org/ru/sisyphus/srpms/ffmpeg6/what_depends/by_binary
(Ответ для Anton Farygin на комментарий #72) > можно пройтись по FTBFS с ffmpeg, например. + https://git.altlinux.org/tasks/370572/
netgen то как раз лучше обновить.
(Ответ для Anton Farygin на комментарий #75) > netgen то как раз лучше обновить. Нужно чуть больше времени - там проблемы при сборке возникают, отчего именно - пока не разобрался. Показалось, что лучше сейчас патч для исправления FTBFS наложить, тем более что это не очень сложно делается.
ну да, согласен.
И можно ещё на это задание посмотреть? Тут тоже исправление FTBFS https://git.altlinux.org/tasks/370553/
(In reply to Leonid from comment #78) > И можно ещё на это задание посмотреть? Тут тоже исправление FTBFS > > https://git.altlinux.org/tasks/370553/ Когда делаете NMU всегда правьте URL. https://www.speech.kth.se/snack/ VCS: https://github.com/scottypitcher/tcl-snack и там, кстати, новая версия.
(In reply to Leonid from comment #78) > И можно ещё на это задание посмотреть? Тут тоже исправление FTBFS > > https://git.altlinux.org/tasks/370553/ А зачем увеличивать release для пересборки ?
(Ответ для Anton Farygin на комментарий #79) > VCS: https://github.com/scottypitcher/tcl-snack > и там, кстати, новая версия. Я видел, но это похоже на неявный форк от другого автора. Поэтому не уверен, что ничего в зависящих пакетах не сломается. (Ответ для Anton Farygin на комментарий #80) > А зачем увеличивать release для пересборки ? Согласен, этого делать не нужно было
(Ответ для Anton Farygin на комментарий #75) > netgen то как раз лучше обновить. + https://git.altlinux.org/tasks/370626/
(In reply to Leonid from comment #82) > (Ответ для Anton Farygin на комментарий #75) > > netgen то как раз лучше обновить. > + > https://git.altlinux.org/tasks/370626/ в netgen закомментированные старые строки лучше зачистить, что бы спек читался легче.
+%filter_from_requires /^\/usr\/bin\/bash/d + эта конструкция без объяснения причин выглядит очень странно.
(Ответ для Anton Farygin на комментарий #83) > в netgen закомментированные старые строки лучше зачистить, что бы спек > читался легче. Не понял о каких строках речь. О неприменённых патчах? Или про вызовы sed? Если про второе, то там висит: > #TODO: uncomment and apply if no MPI version to be assembled in future И не похоже на то, что это стоит удалять.
(Ответ для Anton Farygin на комментарий #84) > +%filter_from_requires /^\/usr\/bin\/bash/d > + > > эта конструкция без объяснения причин выглядит очень странно. В некоторых скриптах внутри пакета в шебангах прописан /usr/bin/bash, И автоматический поиск зависимостей добавляет в пакет Requires: /usr/bin/bash, а это unmet dependency. https://git.altlinux.org/tasks/370626/logs/events.7.1.log Мне показались логичными два пути: либо делать sed на эти скрипты, заменяя /usr/bin/bash на /bin/bash, либо просто исключить /usr/bin/bash из зависимостей пакета. При этом эти скрипты генерируются в ходе сборки, а не лежат в исходном коде, поэтому патч наложить на них заранее не совсем понятно как. Это нормальное решение? Ни в каких других пакетах подобной конструкции (с %filter_from_requires /usr/bin/bash) не нашёл.
(In reply to Leonid from comment #86) > (Ответ для Anton Farygin на комментарий #84) > > +%filter_from_requires /^\/usr\/bin\/bash/d > > + > > > > эта конструкция без объяснения причин выглядит очень странно. > В некоторых скриптах внутри пакета в шебангах прописан /usr/bin/bash, И > автоматический поиск зависимостей добавляет в пакет Requires: /usr/bin/bash, > а это unmet dependency. > https://git.altlinux.org/tasks/370626/logs/events.7.1.log > > Мне показались логичными два пути: либо делать sed на эти скрипты, заменяя > /usr/bin/bash на /bin/bash, либо просто исключить /usr/bin/bash из > зависимостей пакета. > > При этом эти скрипты генерируются в ходе сборки, а не лежат в исходном коде, > поэтому патч наложить на них заранее не совсем понятно как. > > Это нормальное решение? Ни в каких других пакетах подобной конструкции (с > %filter_from_requires /usr/bin/bash) не нашёл. Нет, я бы заменил шебанг. Но вообще в p11 и Sisyphus bash уже доступен в /usr/bin и причина анметы возможно - ошибка в каком-то другом месте. Напишите про это в devel, пожалуйста.
(In reply to Leonid from comment #85) > (Ответ для Anton Farygin на комментарий #83) > > в netgen закомментированные старые строки лучше зачистить, что бы спек > > читался легче. > Не понял о каких строках речь. О неприменённых патчах? Или про вызовы sed? > Если про второе, то там висит: > > #TODO: uncomment and apply if no MPI version to be assembled in future > И не похоже на то, что это стоит удалять. В оригинальном виде это было по другому: +#TODO: uncomment and apply if no MPI version to be assembled in future +#sed -i 's|NG_INSTALL_DIR_CMAKE_DEFAULT lib/cmake/${NG_INSTALL_SUFFIX}|NG_INSTALL_DIR_CMAKE_DEFAULT share/cmake|' CMakeLists.txt +#sed -i 's|${NG_RPATH_TOKEN};${NG_RPATH_TOKEN}/${NETGEN_RPATH}|${NG_RPATH_TOKEN};${NG_RPATH_TOKEN}/${NETGEN_RPATH};%%mpidir/lib:%%_tcllibdir|' CMakeLists.txt +#sed -i 's|${NG_RPATH_TOKEN};${NG_RPATH_TOKEN}/${NETGEN_RPATH}|%%_tcllibdir|' CMakeLists.txt +#sed -i 's|${NG_RPATH_TOKEN}/../${NETGEN_PYTHON_RPATH}||' ng/CMakeLists.txt И там уже что-то раскомментировали.
(In reply to Anton Farygin from comment #87) > (In reply to Leonid from comment #86) > > (Ответ для Anton Farygin на комментарий #84) > > > +%filter_from_requires /^\/usr\/bin\/bash/d > > > + > > > > > > эта конструкция без объяснения причин выглядит очень странно. > > В некоторых скриптах внутри пакета в шебангах прописан /usr/bin/bash, И > > автоматический поиск зависимостей добавляет в пакет Requires: /usr/bin/bash, > > а это unmet dependency. > > https://git.altlinux.org/tasks/370626/logs/events.7.1.log > > > > Мне показались логичными два пути: либо делать sed на эти скрипты, заменяя > > /usr/bin/bash на /bin/bash, либо просто исключить /usr/bin/bash из > > зависимостей пакета. > > > > При этом эти скрипты генерируются в ходе сборки, а не лежат в исходном коде, > > поэтому патч наложить на них заранее не совсем понятно как. > > > > Это нормальное решение? Ни в каких других пакетах подобной конструкции (с > > %filter_from_requires /usr/bin/bash) не нашёл. > > Нет, я бы заменил шебанг. Но вообще в p11 и Sisyphus bash уже доступен в > /usr/bin и причина анметы возможно - ошибка в каком-то другом месте. > Напишите про это в devel, пожалуйста. https://bugzilla.altlinux.org/50150
(Ответ для Arseny Maslennikov на комментарий #89) > https://bugzilla.altlinux.org/50150 Если я правильно понял, то лучшим путём сейчас будет просто поменять в скриптах /usr/bin/bash на /bin/bash?
(Ответ для Anton Farygin на комментарий #88) > В оригинальном виде это было по другому: > ..... > И там уже что-то раскомментировали. Тогда тем более удалять не нужно, ведь это уже зачем-то использовали?
комментарии были добавлены 6 лет назад, их актуальность могла сильно устареть.
+ https://git.altlinux.org/tasks/370626/
(In reply to Leonid from comment #93) > + > https://git.altlinux.org/tasks/370626/ Всё-таки лучше глубже разобраться с изменением, которое там делается. Я не уверен что комментарий соответствует тому, что применяется. по крайней мере выглядит так, как будто с MPI это никак не связано.
(Ответ для Anton Farygin на комментарий #94) > (In reply to Leonid from comment #93) > > + > > https://git.altlinux.org/tasks/370626/ > > Всё-таки лучше глубже разобраться с изменением, которое там делается. Я не > уверен что комментарий соответствует тому, что применяется. > > по крайней мере выглядит так, как будто с MPI это никак не связано. > sed -i 's|NG_INSTALL_DIR_CMAKE_DEFAULT lib/cmake/${NG_INSTALL_SUFFIX}|NG_INSTALL_DIR_CMAKE_DEFAULT %_libdir/cmake/%name|' CMakeLists.txt Да, изменения заключается в том, что апстрим в пути к cmake файлам захардкодил lib. А sed'ом заменяется lib на %_libdir Значения ${NG_INSTALL_SUFFIX} и %name в данном случае совпадают. Это netgen.
Комментарий поправил, таск запустил
https://git.altlinux.org/tasks/370626/gears/1160/git?p=git;a=blobdiff;f=netgen.spec;h=c8c10c592eb33a2c7c82c3a83dbb02f396663daf;hp=91b1d911ceec88de1343caaf450dbb805f92f350;hb=c371ebad69e7101cdbe539918fe104d7407cda50;hpb=837c956abb12b3ce402fe1e7d8e7da645918e714
Отлично, спасибо.
По возможности - отправляйте свои изменения в p11, пожалуйста.
Пользуясь активностью кандидата, хотелось бы попросить Леонида починить, а ещё лучше обновить пакет pychess.
(Ответ для Grigory Ustinov на комментарий #100) > Пользуясь активностью кандидата, хотелось бы попросить Леонида починить, а > ещё лучше обновить пакет pychess. Этим и занимаюсь
(Ответ для Grigory Ustinov на комментарий #100) > Пользуясь активностью кандидата, хотелось бы попросить Леонида починить, а > ещё лучше обновить пакет pychess. https://git.altlinux.org/tasks/370974/
поле Packager не надо использовать, убирайте его всегда по возможности.
(Ответ для Anton Farygin на комментарий #103) > поле Packager не надо использовать, убирайте его всегда по возможности. +
(Ответ для Anton Farygin на комментарий #103) > поле Packager не надо использовать, убирайте его всегда по возможности. Без этого поля Repology будет считать мэнтейнером последнего сборщика, а это не всегда правильно (совсем).
Мы можем выгрузить в Repology другую информацию. repology забирает то, что мы ему отдаём. сейчас отдаём Packager, но можем отдавать что-то другое.
(Ответ для Anton Farygin на комментарий #106) > Мы можем выгрузить в Repology другую информацию. > repology забирает то, что мы ему отдаём. сейчас отдаём Packager, но можем > отдавать что-то другое. https://bugzilla.altlinux.org/49104 Пока отдаём поле Packager видимо оно имеет смысл. Как будем "отдавать что-то другое", так избавимся от него, звучит разумно?
Не смотря на всё остальное - лучше убирать при случае. Схему отдачи на repology мы поменяем без необходимости пересобирать десятки тысяч пакетов.
Там кстати netgen не запускается уже года 3 как минимум. Теперь работает: https://git.altlinux.org/tasks/370984/
И какая судьба у pychess? https://git.altlinux.org/tasks/370974/
(In reply to Leonid from comment #110) > И какая судьба у pychess? > https://git.altlinux.org/tasks/370974/ approved.
(In reply to Leonid from comment #109) > Там кстати netgen не запускается уже года 3 как минимум. > > Теперь работает: > https://git.altlinux.org/tasks/370984/ Отлично. Заапрувил.
Можно ещё эту задачу посмотреть? https://git.altlinux.org/tasks/370553/ Версия 2.11 - это нечто непонятное, если до неё обновляться - там пропадает часть файлов и похоже несколько меняется функционал. Вариант оставить 2.10 с исправленным FTBFS выглядит получше
(In reply to Leonid from comment #113) > Можно ещё эту задачу посмотреть? > https://git.altlinux.org/tasks/370553/ > > Версия 2.11 - это нечто непонятное, если до неё обновляться - там пропадает > часть файлов и похоже несколько меняется функционал. > Вариант оставить 2.10 с исправленным FTBFS выглядит получше ok. заапрувил. Но не понял зачем пересобирать второй пакет, если версия первого не меняется.
(Ответ для Anton Farygin на комментарий #114) > ok. заапрувил. Но не понял зачем пересобирать второй пакет, если версия > первого не меняется. https://git.altlinux.org/tasks/370553/logs/events.2.1.log Похоже с момента сборки пакета поменялся механизм автоматического вывода зависимостей у tcl
(In reply to Leonid from comment #115) > (Ответ для Anton Farygin на комментарий #114) > > ok. заапрувил. Но не понял зачем пересобирать второй пакет, если версия > > первого не меняется. > https://git.altlinux.org/tasks/370553/logs/events.2.1.log > > Похоже с момента сборки пакета поменялся механизм автоматического вывода > зависимостей у tcl Ясно, спасибо.
https://git.altlinux.org/tasks/371729/ Для сборки одного из пакетов понадобилась зависимость на ocaml-lablgtk3-sourceview3, а его в репозитории не оказалось. Несколько поменял процесс сборки ocaml-lablgtk3 и добавил подпакеты для goocanvas2, gtkspell3, rsvg2 и sourceview3.
Ещё обновил mediamtx https://git.altlinux.org/tasks/371732/
https://git.altlinux.org/tasks/371748/ Исправление FTBFS
(In reply to Leonid from comment #117) > https://git.altlinux.org/tasks/371729/ > > Для сборки одного из пакетов понадобилась зависимость на > ocaml-lablgtk3-sourceview3, а его в репозитории не оказалось. > > Несколько поменял процесс сборки ocaml-lablgtk3 и добавил подпакеты для > goocanvas2, gtkspell3, rsvg2 и sourceview3. С ocaml не совсем корректно. Надо модифицировать rpm-build-ocaml так, что бы он поддерживал разбивку на подпакеты. Или всё складывать в один пакет. Но использования макроса, расскладывающего файлы по devel/не-devel обязательно.
(Ответ для Anton Farygin на комментарий #120) > С ocaml не совсем корректно. > Надо модифицировать rpm-build-ocaml так, что бы он поддерживал разбивку на > подпакеты. Или всё складывать в один пакет. Но использования макроса, > расскладывающего файлы по devel/не-devel обязательно. Тогда так? https://git.altlinux.org/tasks/371729/
https://git.altlinux.org/tasks/371761 Собрал Coq, для него (coqide) собственно и нужно было добавить ocaml-lablgtk3-sourceview3 как сборочную зависимость
нужно использовать %ocaml_find_files вместо ручного раскладывания файлов по подпакетам ocaml А зачем вообще понадобился coq ?
(Ответ для Anton Farygin на комментарий #123) > А зачем вообще понадобился coq ? Мне лично нужен в сизифе, наверняка ещё кому-то тоже. Полезный пакет, странно что его ещё до этого никто не собирал. > нужно использовать %ocaml_find_files вместо ручного раскладывания файлов по > подпакетам ocaml Ну так он же умеет только в devel и не-devel, как мы уже выяснили? Плохая идея тащить пользователю ide, если ему нужны только консольные утилиты, например.
(In reply to Leonid from comment #124) > (Ответ для Anton Farygin на комментарий #123) > > А зачем вообще понадобился coq ? > Мне лично нужен в сизифе, наверняка ещё кому-то тоже. Полезный пакет, > странно что его ещё до этого никто не собирал. > > > нужно использовать %ocaml_find_files вместо ручного раскладывания файлов по > > подпакетам ocaml > Ну так он же умеет только в devel и не-devel, как мы уже выяснили? > Плохая идея тащить пользователю ide, если ему нужны только консольные > утилиты, например. При двух равных - ручное раскладывание хуже, к тому же оно сейчас сделано неправильно.
(Ответ для Anton Farygin на комментарий #125) > При двух равных - ручное раскладывание хуже, к тому же оно сейчас сделано > неправильно. Что конкретно сделано не так? Руководствовался тем, как оно собрано в Федоре.
(In reply to Leonid from comment #126) > (Ответ для Anton Farygin на комментарий #125) > > При двух равных - ручное раскладывание хуже, к тому же оно сейчас сделано > > неправильно. > Что конкретно сделано не так? > Руководствовался тем, как оно собрано в Федоре. Можно посмотреть rpm-build-ocaml 1.6.4 https://packages.altlinux.org/ru/tasks/370960/ в нём есть алгоритм раскладывания файлов по подпакетам.
(Ответ для Anton Farygin на комментарий #127) > Можно посмотреть rpm-build-ocaml 1.6.4 > https://packages.altlinux.org/ru/tasks/370960/ > в нём есть алгоритм раскладывания файлов по подпакетам. Там есть разделение на devel и runtime. Это имелось ввиду? Ну и ещё, насколько я разобрался, для coq это не сработает, потому что в нём есть ".v" файлы, которые в регулярных выражениях не фигурируют.
посмотрел внимательнее, всё с coq с точки зрения ocaml нормально. но задание лучше запустить с зависимостью на #370960, что бы они друг другу не помешали. запускайте с зависимостью, я после этого заапрувлю.
(Ответ для Anton Farygin на комментарий #129) > посмотрел внимательнее, всё с coq с точки зрения ocaml нормально. > > но задание лучше запустить с зависимостью на #370960, что бы они друг другу > не помешали. > > запускайте с зависимостью, я после этого заапрувлю. +
На этом моя работа закончилась. Кандидат стал готов к самостоятельной работе в Team. Леониду предложение какое-то время, особенно в сложных случаях обращаться на review.
Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
Мои поздравления!
Всем спасибо! :)
