А в оверлеях нет ебилдов посвежее?

Я еще не смотрел сам ебилд и билдсистему, только сам баг, но навскидку:

У тебя есть решение проблемы сборки при которой ejabberd в процессе сборки тянет что-то из git-а?

И да, я сам вряд ли возьмусь за этот ебилд, ибо erlang, в котором я нихрена не понимаю. Но потыкать людей в IRC - могу

ebuild or GTFO

Ну так уволь этого Tim Harder. А, так ты его не нанимал и денег ему не платишь. Ну тогда расторгни контракт с Gentoo, пусть выплатят тебе неустойку. Что, и контракта не заключал? Тогда остаётся только самому написать подходящий ebuild.

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

А он живой вообще?

В треде есть чувак, у которого уже год всё работает.

P.S. Он там вроде ебилд прикладывал в комментах.

У тебя есть решение проблемы сборки при которой ejabberd в процессе сборки тянет что-то из git-а?

Я такие штуки выпиливаю седом в своих ебилдах. Типа sed -i '/someshit/d' rebar.config и добавлением этой фигни в качестве зависимостей.

Ебилды уже написали. Ему остается привести их в чувство и закоммитить.

I look at build process of 15.02 and it still pull from git repos during compile. Good thing - they hardcode exact commits to rebar script. So - it anyway live pakage now. We can package downloaded modules and patch out git pull during compile by palacing ".got" file into «deps» folder and unpack needed modules to it.

Так что решение есть, да.

что плохого в том, что он что-то тянет из гита?

То, что он может тянуть из master? И ты собрав два раза пакет получишь разный результат?

Ну, я так всегда и делаю :) Есть всего две версии - latest и устаревшая. Если устаревшая - надо обновляться. Хорошо, если в программе есть система нотификаций о новых версиях, и эта система сама может запустить обновление. Для самих программ лучше не давать доступ прямо к master, потому что тогда обновляться придется слишком часто (представим, что популярный проект, и коммиты в мастер приходят каждые 5 минут). Но у библиотек-то таких ограничений нет, т.к. пользователь никогда не обновляет библиотеки самостоятельно. Каждый раз, когда rebar тянет зависимости, он будет тянуть их самые свежие версии.

Вижу одну проблему - что будет, если кодер захардкодил в зависимости master чужой библиотеки, и у этой чужой библиотеки сломалось апи. Ну это просто значит, что данной софтиной пользоваться не нужно - ее разработчик осёл.

Тянешь либу из мастера, а не указываешь тег/хэш коммита? ССЗБ!

Ну, я так всегда и делаю :)

Мои поздравления, ты обезьяна.

Ты видимо мало с erlang работал. Там очень любят так делать.

гентушнеги уже два года не могут обновить пакет

Да это ещё нормально. Для i2p уже 6 лет не могут сделать ебилд. А для малопопулярных пакетов бывает и ещё дольше.

Ты понимаешь, ejabberd это самый популярный в сети xmpp сервер. Выглядит просто глупо.

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

Я бы поспорил насчет размера аудитории, но в целом ты прав, да. Тривиальные баги там годами тянутся.

Мои поздравления, ты ниасилятор. Не нравится, как разрабы написали ебилд, не смог написать свой, не смог разобраться с системой сборки. Что ты делаешь в генту? xD Может тогда не выпендриваться, а скачать уже собранный бинарь? Гарантированно нужной версии, собранный прямыми руками, итп.

Ты видимо мало с erlang работал.

Не угадал.

Там очень любят так делать

Хм, посмотрел на rebar.config наиболее часто используемых у нас в конторе либ, - ни в одной нет захардкоденой ветки master, везде либо хэш коммита, либо тег.

Не нравится, как разрабы написали ебилд, не смог написать свой, не смог разобраться с системой сборки. Что ты делаешь в генту?

Если юзеры будут сами писать себе ебилды, то зачем им гента с её мейнтейнерами?

Уф. В треде по ссылке всё уже сделали. Осталось закоммитить. Я не хочу добавлять ещё один ебилд в свой оверлей, их там уже и так блять больше сотни.

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

Ну как сказать. Всё остальное просто ещё хуже. В шляпе все протухло, с дебианом грустно в плане нетривиальных зависимостей и привычки мейнтейнеров к повальной автоматизации всего и вся, не спрашивая хочу ли я этого.

А десктоп-юзеры генты в состоянии самостоятельно запилить ебилд.

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

Я могу понарассказать про ejabberd. Начать можно с того что новых версий, которые Community Edition, почти нигде нет. Но основная проблема даже не в этом, а в том что для новых версий есть не все модули. Например XEP-0136 не поддерживается в новых версиях, а XEP-0313 еще не допилен, да и поддержка на клиентах оставляет желать лучшего. В итоге ситуация, когда новые версии оказываются неюзабельными(считаю что история на сервере MustHave) и приходится пользоваться протухшими.

//С Prosody кстати таже фигня. А вы еще удивляетесь почему джаббер не может популярным стать.

А есть ли у тебя опыт работы с поделкой от эрланг-солюшнз?

А есть ли у тебя опыт работы с поделкой от эрланг-солюшнз?

Это который MongooseIM? Нет, пока не успел. Хотя у меня сейчас остро стоит вопрос с джаббер сервером. Попробую наверное его. Правда для поддержки XEP-0313 придется на Gajim перейти с VacuumIM(разработчик упорно отрицает 0313, даже когда 0136 все уже дропают как устаревший).

Кому это всё надо? Оно сообщения отправляет? Отправляет. Принимает? Принимает. Что вам блин ещё надо.

Кому это всё надо? Оно сообщения отправляет? Отправляет. Принимает? Принимает. Что вам блин ещё надо.

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

Да, мне это нужно. Не будет таких простых фич, так все и будут скайпег выбирать, а не этот Ъ-ждаббер.

Нуоаяхз. Я жаббир использую как IRC с отложенной доставкой.

Работает < Работает у всех и проходит все QA-тесты

Боюсь там одним/двумя/тремя sed-ами не обойдешься. Потому что выкатывать ejabberd без плагинов(которые он тянет) - это равносильно невыкатыванию его вообще

Есть всего две версии - latest и устаревшая

enjoy your unstable. Стабильность предполагает предсказуемость результата. Сборка из trunk-а/git master - с точки зрения пользователя непредсказуема по умолчанию(если ты конечно не автор софтины и разрабатываешь её)

И да, отвечая на твой вопрос - такой ебилд не пройдет QA-тесты в network sandbox режиме, потому что доступ к сети у ебилда при сборке в идеале есть только на 1 этапе - на этапе скачивания сырцов(в виде tarball или из VCS). Билдсистема качает на этапе компиляции -> фэйл

Если юзеры будут сами писать себе ебилды, то зачем им гента с её мейнтейнерами?

Буду краток - инфраструктура и возможность переложить часть работы на другие плечи.

Если ты готов писать сборочные скрипты и прикладывать патчи на все что есть у тебя в системе, да - гента тебе не подойдет. Тут больше LFS заруливает :-)

Для i2p уже 6 лет не могут сделать ебилд

Я уже объяснял почему это так. Есть такой софт, который опакетировать чревато аццкой головной болью по поддержке. Вот пока не найдется человек, готовый лопатой разгребать все говна - дело с места и не сдвинется.

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

Так что решение есть, да.

Буду рад взглянуть на ебилд, проходящий тесты в network sandbox

инфраструктура и возможность переложить часть работы на другие плечи

Так и я о том же. Если мне предлагают писать ебилды руками, то какую часть работы я куда перекладываю? Мне придётся делать всю работу самому. Более того, документация и стандарты по ебилдам разбросаны так, что чтобы научиться делать «правильные» нужно потратить намного больше времени, чем это делает мейнтейнер с уже имеющимися навыками, и больше, чем просто собрать софт локально. Поэтому я держу папочку sources, где собираю нужный софт и использую, потому что это делается обычно одной командой make (или cmake && make), тогда как на написание даже «неправильного» (не соответствующего стандартам) ебилда у меня уходило несколько дней (и это не считая общения с теми кто уже умеет).

Если мне предлагают писать ебилды руками, то какую часть работы я куда перекладываю?

Писать ебилды руками != писать ебилды на всё руками

Мне придётся делать всю работу самому.

Нет. Тебе никто не предлагает заниматься адом в виде написания ебилдов на gcc, glibc и прочий нетривиальный низкоуровневый треш.

Более того, документация и стандарты по ебилдам разбросаны так, что чтобы научиться делать «правильные» нужно потратить намного больше времени, чем это делает мейнтейнер с уже имеющимися навыками

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

Я уже объяснял почему это так. Есть такой софт, который опакетировать чревато аццкой головной болью по поддержке. Вот пока не найдется человек, готовый лопатой разгребать все говна - дело с места и не сдвинется.

Дык а в чём проблема? Ебилды в багзилле есть, они рабочие. Может там не 100% выпилены не systemwide зависимости, но это никак не мешает пакету собираться и работать.

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

Опять же, что мешает? В оверлеях оно отлично собирается и работает. Если мейнтейнеру оверлея не лень это делать, почему не пригласить его в дерево, чтобы он этим пакетом занимался?

Я о том, что эти плагины пакуются отдельно. Sed нужен только чтобы rebar не тянул их при сборке.

«Собирается и работает» - это необходимый, но недостаточный критерий для принятия в главное дерево.

C i2p была проблема с bundled libs, как сейчас - хз. От Java ПО я настолько же далек как и от Erlang.

Писать ебилды руками != писать ебилды на всё руками

Большую часть работы по написанию ебилда составляет изучение документации по ебилдам. Если ты её изучил, не составляет никакой проблемы поддерживать все ебилды (тем более что для большинства апдейт заключается в копировании и переименовании .ebuild файла).

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

Проблема не в самом объёме, а в архитектуре и документации. Даже сложную систему можно спроектировать так, что она будет интуитивно понятно и для пользователей, и для разработчиков. Это не всегда можно сделать с первого раза, но имея например сегодняшний портеж с его ебилдами, можно элементарно собрать статистику того, с какими частями больше всего сложностей и затраченного времени при изучении или написании ебилдов. А потом передизайнить эту часть нормально.

Судя по тому что пишут в баге(в ебилд я всё еще не смотрел, работа, мать её) - скорее всего так и придется поступить

«Собирается и работает» - это необходимый, но недостаточный критерий для принятия в главное дерево.

Ну и зачем надуманные проблемы? Что изменится, если принять в дерево пакет с bundled libs?

Если есть какой-то юзкейс, когда действительно стоит оградить юзеров от определённых пакетов, можно сделать 2 дерева. Одно основное, второе с «рабочими, но не кошерными» пакетами. 90% подключат оба, оставшиеся 10% второе подключать не станут.

Если ты её изучил, не составляет никакой проблемы поддерживать все ебилды (тем более что для большинства апдейт заключается в копировании и переименовании .ebuild файла).

Если ты считаешь, что слепое копирование и проверка, собирается ли новая версия является достаточным условием для обновления версии в главном дереве, то поспешу тебя разочаровать - это не так.

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

Если ты считаешь, что слепое копирование и проверка, собирается ли новая версия является достаточным условием для обновления версии в главном дереве, то поспешу тебя разочаровать - это не так.

Вот мне и интересно, почему это не так. Почему у дерева есть дополнительные требования к пакетам и чем они обусловлены?

Что изменится, если принять в дерево пакет с bundled libs?

Экспоненциально увеличится головная боль команды Gentoo Security

Если есть какой-то юзкейс, когда действительно стоит оградить юзеров от определённых пакетов, можно сделать 2 дерева. Одно основное, второе с «рабочими, но не кошерными» пакетами.

google://Gentoo Sunrise

Туда кстати пользователи могут коммитить ебилды после верификации их синтаксиса. QA-проверки там - гораздо более мягкие. В общем случае - работает, уже хорошо