Gentoo: media-gfx/gimp maintainer-needed

сам бы и взял :)

Я пока об этом думаю, но там 5 пакетов завязанных друг на друга + меня пугает «вдруг случится переход на gtk+3».

Но главное, боюсь, я сейчас не смогу выделить время, чтобы разобраться в деталях пакета - до компа редко дома добираюсь. Разве что сейчас изменения минимальные и можно хоть сходу подписаться как proxied-maintainer и отправлять pull request. Но разбираться всё равно придётся в итоге. Я пока морально не созрел :(

С другой стороны изменения не так уж часто случаются, а один пакет, который на мне висит обычно в декабре выходит, а для для него за 2 года так патч в апстрим и не доделал для условной (наличие каталогов) сборки. То есть для опакечивания на месте и мой патч подойдёт, но для сборки из trunk не прокатит.

Я сталкивался с поддержкой [некоторых из] перечисленных ебилдов, но я больше не пользователь Gentoo.

Есть подозрение, что поддержка по факту прекратилась ещё чуть раньше, потому что сборка media-libs/gegl-9999 падает вот уже примерно месяц, не в силах найти configure.ac. Жаль, конечно, что так выходит.

Баг закрыт 4 дня назад: https://bugs.gentoo.org/694506

На следующий день ментейнер отписался от пакетов.

А не мог найти, потому, что вместо autotools теперь используется meson.

Обычно live-ebuild рекомендуют проверять хотя бы раз в месяц. Но не уверен, что все ментейнеры следуют этой рекомендации. Я, например, нет :(

Собственно, вот письмо:

https://archives.gentoo.org/gentoo-dev/message/b9d49791fd744842a1d010bc3a09825e

Hello,

I need to admit that I don't have enough time to keep up with maintaining the Gimp-related packages well enough in Gentoo.

Latest ebuild of Babl and Gegl ebuilds are using Meson by now, Gimp is up next and 2.10.14 is just out the door.

These packages are up for grabs now:

  media-gfx/gimp

  media-libs/babl
  media-libs/gegl

  media-gfx/mypaint  (not mine but maintainer-needed and related)
  media-gfx/mypaint-brushes
  media-libs/libmypaint

Best

Sebastian

Помимо самого пакета и его основных зависимостей, летом без ментейнера осталась одна из зависимостей media-libs/gegl: media-libs/libnsgif.

Попробовал собрать 9999, сначала не хватало dev-util/gtk-doc для генерации gtk-doc.make; потом dev-libs/gjs; после этого в системе не нашлось Babl-0.1.gir, пока не выяснил кто его поставляет. Скорее всего media-libs/babl[introspection].

«Крысы» бегут с тонущего корабля…

Barracuda72 ,если это твой pull request, то, пожалуйста, удали из предлагаемого ebuild архитектуру ~x86: ошибка CI tests прежде всего связана с этим, так как поддержка этой архитектуры не указана в media-libs/gegl-0.4.18, а у него она не указана из-за её отсутствия в media-libs/libnsgif-0.2.1-r1.

После локальной правки в локальном оверлее старайся запускать repoman -dx full - он протестирует на совсем уж грубые ошибки, связанные в том числе с архитектурами зависимостей.

После этого, возможно, CI всё равно выдаст ошибки, т.к. будет ругаться на другие пакеты (дерево сильно могло измениться с тех пор). Потому лучше попробовать сделать rebase:

git remote add upstream https://github.com/gentoo/gentoo.git

git fetch upstream

git checkout your_branch

git rebase upstream/your_branch

чтобы обновилось дерево твоей копии и твои коммиты сместились в начало. Можно заодно после этого объединить получившиеся 3 коммита, прежде чем пуш-форсить.

Было б неплохо узнать у последнего ментейнера (и контрибьютеров) media-libs/libnsgif, почему эта arch не указана. Возможно ничего страшного там нет и её можно добавить, если никто не против.

Туда долго писать, поэтому пишу здесь. По поводу мёрджа в дерево узнавай непосредственно у Andreas Sturmlechner, который тебе там отписывался; у первого всё равно нет прав мёрджить в дерево.

Либо подожди, пока я протестирую в x86 chroot media-libs/libnsgif-0.2.1-r1 и media-libs/gegl-0.4.18 и, если всё хорошо, отправлю pull request. Только после того, как его замёрджат, всё равно придётся делать push -f, чтобы перeзапустить CI test.

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

Barracuda72 ,если это твой pull request

Да, пулл-реквест мой.

repoman -dx full

Я запускал, но оно выдает тонну всякой инфы, слабо понятной непосвященному. Потому забил.

В общем, если вкратце - что мне сейчас делать? Тебя ждать или убрать ~x86 и запушить еще раз?

Лучше убрать ~x86 и запушить.

Скорее всего он выдавал тонну инфы насчёт отсутствия в gegl нужной версии архитектуры x86 в доступных профилях.

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

Лучше убрать ~x86 и запушить.

Ну ОК. Сливать коммиты в один я не стал (влоб нагугленной командой не вышло, а разбираться и читать документацию времени нет).

Никак не заставлю себя поставить хотя бы в виртуалке repoman и portage из testing :( Там более новые проверки обычно есть.

Похоже, теперь в некоторых случаях обязательна строчка

RESTRICT="!test? ( test )" 

Она вставляется после переменной IUSE перед RDEPEND. По крайней мере, QA bot сейчас ругается из-за неё.

Там всё просто. Раздел «Объединение коммитов». Rebase вообще очень полезен в деле работы с pull request, постоянно им пользуюсь.

Да он на это матерится уже черт знает сколько, судя по логу.

Благодарю, почитаю на досуге (эх, был бы он еще). Я просто гит использую втупую как ДСКВ и метод резервного копирования исходников, все прочие фишки обошли меня стороной.

~x86: ошибка CI tests прежде всего связана с этим, так как поддержка этой архитектуры не указана в media-libs/gegl-0.4.18, а у него она не указана из-за её отсутствия в media-libs/libnsgif-0.2.1-r1.

Zlogene, просвятишь как происходит «добавление» архитектур пакетам? Чего для этого достаточно? А то для gegl (соответственно и для нового gimp её нельзя указать) минимум одну дропнули из-за отсутствия указания её в данный момент в зависимости. Предыдущий ментейнер gimp написал, что добавлением заведует соответствующая arch команда и он не уверен, что pull request «со стороны» подходит для этой цели.

Ага, но похоже, теперь это обязательно к исправлению в данном случае (выделено оранжевым для нового пакета), если не ошибаюсь.

Я тут ещё баг с тестами лезущими в интернет пофиксил (плюс дублирующий его). Мне нужно протестировать сборку для всех флагов и могу после этого скинуть патч, либо потом отдельной ревизией можно исправить.

ОК, ждемс

Я уже скоро 10 лет на генте и не всегда мир могу собрать, а ты такое предлагаешь

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

Только будь готов к тому, что всё-таки попросят сделать rebase + добавить в коммиты signed-off в соответствии с GLEP 76.

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

У меня «перерыв» в генте был 4 года, а как вернулся, то через полгода решил пакет себе взять поддерживать.

ОК, запилено

TL;DR: сделай баг в багзилле, там есть компонент KEYWORDING, в CC помести x86@gentoo.org

Есть пулреквест на существующий баг на эту тему.

https://github.com/gentoo/gentoo/pull/13541

https://bugs.gentoo.org/698696

Баг создавал не я, ко мне он пока не приписан, поэтому СС добавить не могу.

Ты не в курсе, кстати, общей ситуации в генту? А то у меня что-то такое ощущение, что она загибается потихоньку. Пихтон 3.8 уже месяц как вышел, а его не то, что не добавили - даже не просмотрели ни мой баг-репорт с ебилдом и портированными патчами, ни пул-реквест, вообще ничего. Как будто и нет никого.

Прошло 3 недели с момента выпуска и примерно неделя с момента пулл реквеста, в котором ответили, что-то вроде,что патчи придётся проверять вручную (они прикреплены отдельно, а не коммитами), поэтому пулреквест скорее всего не смогут смёрджить.

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

Я обычно иногда в irc пытаюсь уточнять или чаще письмами в личной переписке, чего ещё нужно исправить в реквесте.

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

Хм, я-то думал как раз-таки наоборот - именно подобные критичные пакеты мейнтейнят в первую очередь, а все остальное - по остаточному принципу

3.8 как раз не критична в данный момент, а обновление веток 3.6 и 3.7 более важны.

на pull пофиг, а вот баг нормальный.

угу, пулл такой всё равно не рассматривают похоже :(

Спасибо, что добавили keyword обратно. Возможно, баг тогда переименовать нужно.

Ну вот :(

Что же я делаю то со своей жизнью?

Ну ничего, потренируешься, а там глядишь и девом станешь. Рук на реально сложные проекты у нас нехватка. Большинство (по моим наблюдениям) идут по пути наименьшего сопротивления.

Я уже 1.5 года тренируюсь :D Но другие 2 пакета раз в 2 года выходят.

Надо будет на #gentoo-gnome поспрашивать как принято сейчас переходить с использования gnome2.eclass при переезде на eapi7.

Да, ментейнеров маловато: всего ~150 человек + ~280 proxied.

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

Тебе изнутри виднее. Под количеством я скорее время имею ввиду: иногда страшно смотреть на колличество коммитов в день у разработчиков, сопровождающих мои пулреквесты. Но ты и не время, наверняка, имеешь ввиду.

Если успею сегодня доползти до компа, то закину пулреквест на обновление-починку gimp-9999.ebuild. Он уже «готов». Заодно может и закрою один баг для gegl-1.4.0 и добавлю пакет gimp-help-2.10.

Обновлён пакет app-doc/gimp-help до версии 2.10.0.

Справка открывается в браузере для LC_MESSAGES соответствующему тому с которым запущен сам GIMP. Если в системе LC_MESSAGES=C, то справка должна открываться на английском.

Если при сборке воспроизводится этот баг: https://bugs.gentoo.org/677198 , то попросите переоткрыть его.

Если кому срочно нужен новый gimp-9999.ebuild (2.99.1 с gtk+3), то ссылка на pull request есть на странице с соответствующим багом. Там его предварительная версия.

AP, не подскажешь, что планируется делать в отношении системы сборки gimp-help в отношении python2, в частности, для используемого скрипта xml2po? Или лучше на канале #gimp поспрашивать?

Насколько я знаю, пока ничего не планируется.

Вопрос важный, лучше завести багрепорт в https://gitlab.gnome.org/GNOME/gimp-help/issues.

gegl-1.4.0

Нет такой версии пока :)

Если вы любите ставить gimp-9999, то спешу (я слоупок) обрадовать, что 2 дня назад требования сборки изменились и теперь нужны gegl-0.4.20 и babl-0.1.74. Поэтому пока они не появятся в дереве пакет не начнёт собираться.

AP, не подскажешь, как лучше отправлять патчи в проекты gegl, gimp? За pull request появляющимися на зеркале github кто-нибудь следит или лучше git-formated патчи по почте слать (куда)?

PR на гитхабском зеркале отключены, поэтому следить не за чем :)

Можно залогиниться с гитхабским аккаунтом на гномовском гитлабе, сделать форк https://gitlab.gnome.org/GNOME/gimp и послать merge request.

Ну или залить отформатированный гитом патч в https://gitlab.gnome.org/GNOME/gimp/issues.

PR на гитхабском зеркале отключены

ну вот, уже отключили: 14 закрытых висит.

Спасибо, тогда залогинюсь гитлабовским аккаунтом и issue создам с прикреплением патча. Они мелкие, по части сборки.

Посмотрел ещё раз: почему-то включены. Помню, что договаривались об отключении. Возможно, что-то сломалось. Так или иначе, на гитхабе они не рассматриваются. Вот, Жеан правильно написал: https://github.com/GNOME/gimp/pull/22#issuecomment-442404283. Так что да — на гитлаб, спасибо :)