> Plugin 'libautoplaylist.so' has the wrong api version Аналогично все gmpc-plugin-* Стоит обновить до версии 0.17
ну раз уж я в cc вижу пользователей gmpc :), то будет предложение. заберите его у меня вместе с плагинами. и claws-mail в качестве бонуса.
Так нечестно, я только что вернулся на MPD и как раз думаю пересесть с Evolution обратно на Claws-Mail :) И что, мне всё это поддерживать? Пишите роботу, что сказать...
давайте выясним с led@ кого добавлять в кач-ве лидера. сейчас по факту libmpd и gmpc в его ведении.
(В ответ на комментарий №3) > давайте выясним с led@ кого добавлять в кач-ве лидера. сейчас по факту libmpd и > gmpc в его ведении. Готов их (libmpd и gmpc) отдать мейнтейнеру, более заинтересованному и регулярно ими пользующемуся. Оба пакета "загитованы", лежат в .../led/packages/
принято.
2 led: Склонировал репозитории с libmpd и gmpc, пытаюсь собрать 0.18.0. Возник дилетантский вопрос: в чём глубокий смысл хранения апстрима отдельно от спека? И второй вопрос: каким образом в таком репозитории делать пакеты? Не делать же каждый раз полный мердж с последующим немедленным удалением апстримовых файлов из master - это как-то очень странно выглядит. В общем, хотелось бы понять, каким был порядок сборки очередной версии.
(В ответ на комментарий №6) > И второй вопрос: каким образом в таком репозитории делать пакеты? См. .gear/rules. gear-hsh спокойно собрал.
(В ответ на комментарий №6) > Не делать же > каждый раз полный мердж с последующим немедленным удалением апстримовых файлов Да, т.к. для этого есть merge -s ours
Всем спасибо, но уже :) Даже понял rationale для такого распила по веткам.
(В ответ на комментарий №6) > В общем, хотелось бы понять, > каким был порядок сборки очередной версии. Прошу прощения, что не сразу ответил. Да, именно так, как сказали уже выше: с помощью git merge -s ours У меня все пакеты так сделаны (а их больше сотни). Может я и неправ, но мне так кажется удобнее:)
Напротив, я уже понял, для чего это удобно. Осталось выйти на контакт с апстримом, чтобы он почувствовал насколько мы к нему дружественны - специальный бранч только с доработками и безо всяких спекфайлов и прочего :) Но это после запаковки плагинов.
(В ответ на комментарий №11) > Напротив, я уже понял, для чего это удобно. Осталось выйти на контакт с > апстримом, чтобы он почувствовал насколько мы к нему дружественны - специальный > бранч только с доработками и безо всяких спекфайлов и прочего :) апстрим pull'ится прямо в бранч upstream из апстримового же git'а, боагодаря записи в config: [remote "origin"] url = git://repo.or.cz/gmpc.git fetch = +refs/heads/master:refs/heads/upstream
Забрал баг себе.
В общем, task #2669 :)
Соответственно, завтра это добро (хочется верить) будет в Сизифе.
(В ответ на комментарий №14) > В общем, task #2669 :) А почему без libsexy? есть какие-то противопоказания?
Только большая просьба к algor@, заапрувить таск и/или добавить меня в список право имеющих в отношении всех плагинов к gmpc.
(В ответ на комментарий №16) > (В ответ на комментарий №14) > > В общем, task #2669 :) > > А почему без libsexy? есть какие-то противопоказания? А что libsexy? libsexy thresh@ собирает.
А, всё, не допёр сразу. Речь о том, что gmpc без libsexy собран? Честно говоря, не обратил внимания...
(В ответ на комментарий №19) > А, всё, не допёр сразу. Речь о том, что gmpc без libsexy собран? Честно говоря, > не обратил внимания... Ну... вообще-то в changelog'е об этом сказано... Я, правда, уже начинаю сомневаться, что мейнтейнеры читают чейнжлоги того, что собирают :(
Читают, но по диагонали и половину потом забывают. Добавил -alt2 в тот же таск. Интересно, осилит ли girar две сборки одного и того же пакета в одном задании.
