LINUX.ORG.RU

openSUSE Build Service 1.7

 ,


0

0

openSUSE Build Service - это инструмент, предоставляющий разработчикам возможность собирать бинарные пакеты своих программ для дистрибутивов openSUSE, SLES, Fedora, Red Hat, Mandriva, Debian и Ubuntu.

Особенности данного релиза:

  • Новая система атрибутов, хранящая информацию, относящуюся к проектам или пакетам;
  • Более высокая скорость сборки;
  • Возможность запускать систему с USB-носителей, а так же обновлять её без потери данных, отправленных на сервер;
  • Введен механизм ревью;
  • Традиционные мелкие улучшения и исправления ошибок.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: maxcom (всего исправлений: 2)

хорошая новость, надо обновляться

anonymous
()

+1 Novell. Вот Build Service — это их хорошая разработка.

Ruth ★★
()

обирать бинарные пакеты своих программ

Да собирать то это ладно, репы делать можно, как на лаунчпаде?

a3
()

Надо попробовать будет. Как это работает и чем оно может быть полезно.

digiwhite
()

ЛОР остывает после вчерашнего DE-срача. :)

helios ★★★★★
()
Ответ на: комментарий от digiwhite

а фиг ее знает... может есть... я вот сеня потыкал билдсервис с утречка раннего, думал РПМки deadbeef'a собрать для просящих... а spec файл писать в лом стало... :)

daemonpnz ★★★★★
()
Ответ на: комментарий от yoghurt

>> Введен механизм _ревью_

Хотел написать «инспекций». Please offer a better solution.

«Введён механизм проверок» (или Введён механизм обзоров/пересмотра).

GladAlex ★★★★★
()
Ответ на: IMHO от yoghurt

«Введён механизм проверок изменений перед подтверждением»

GladAlex ★★★★★
()

Я правильно понял, я хочу собрать, скажем, что_то_там.tar.bz2

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

anonymous
()
Ответ на: комментарий от anonymous

Просто так пакет никак не соберешь, в любом случае для RPM spec надо, для DEB тоже (не помню название). Профит в том, что ты не греешь комнату процессором и не так долго ждешь, ибо сервак заведомо мощнее, ну и плюс автоматизация разного рода.

PayableOnDeath
()
Ответ на: комментарий от PayableOnDeath

Т.е. получается, что что дома, что там нужно руками писать метданные. Т.е. выгоды никакой )) кроме скорости сборки.

А если соберу там, а будут зависимости, а у меня этих покетов дома нет. Что тогда? Кам там вопрос с зависимостями?

anonymous
()
Ответ на: комментарий от PayableOnDeath

Ну серваки там не мощнее фенома. Главное то, что можно собирать под разные дистрибутивы, не держа весь зоопарк дистрибутивов у себя, и то, что собранные пакеты сразу попадают в публичный репозиторий.

Хотя надо сказать, что сборка .deb в этом билдсервисе – то ещё удовольствие.

anonymous
()
Ответ на: комментарий от anonymous

> А если соберу там, а будут зависимости, а у меня этих покетов дома нет. Что тогда? Кам там вопрос с зависимостями?

Пакеты попадают в репозиторий, и с зависимостями разберется пакетный менеджер.

anonymous
()

У них там mplayer в блек-листе:

http://en.opensuse.org/Application_black_list

т.е. его нельзя собирать с помощью этого сервиса.

Как правильно тогда установить в opensuse mplayer?

(компиляция, ... а как дальше, и.е. не при помощи make install)

Более того, на 11.2 mplayer не компилируктся, так как по умолчанию идет gcc 4.4.1, который как уже все знаю не собирает mplayer. Для этого нужна 4.2 ветка.

Я скачал готовый, поставил, при помощи zypper. Но хочется все-таки родоное решение.

anonymous
()
Ответ на: комментарий от anonymous

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

PayableOnDeath
()
Ответ на: комментарий от anonymous

В YasT нажми «добавить репозитории сообщества» и там выбери Packman, там вся мультимедиа без банальных и прочих ограничений

PayableOnDeath
()
Ответ на: комментарий от anonymous

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

Верно?

Осталось 2 вопроса:

1) В какой репозитарий попадают? (публичный или свой создается) 2) Если есть зависимсоти, которые zypper не решит что будет :))

Просто если бы не мой более 10 летний опыт работы с линуксом на десктопе, то хер бы )) я поставил mplayer. Пришлось какчать чужую сборку и руки выламывать дистибутиву поиском в интернете библиотек нудных версий и подсовыванию их mplayer, каждый раз запуская ldconfig в надежде на то, что либа нужная.

Вопрос 2 для меня интересный, так как на эксперименты времени просто нет

anonymous
()
Ответ на: комментарий от anonymous

>Более того, на 11.2 mplayer не компилируктся, так как по умолчанию идет gcc 4.4.1, который как уже все знаю не собирает mplayer. Для этого нужна 4.2 ветка.

А в пакмане они чем собирают?! http://packman.links2linux.org/package/MPlayer

GladAlex ★★★★★
()
Ответ на: комментарий от PayableOnDeath

2PayableOnDeath:

Спасибо за ответ. Пардон за опечатки. Нет русских букв.

Буду пробовать packman. Интересный совет.

Но вопрос номер 2 интересен чисто из соображений экспиринса.

anonymous
()
Ответ на: комментарий от anonymous

>Просто если бы не мой более 10 летний опыт работы с линуксом на десктопе, то хер бы )) я поставил mplayer.

Вы не ищите лёгких путей, да? ;) Через вышеуказанную ссылку пакмана ставится в один клик + подключается хранилище пакмана, в котором много других разных вкусностей для openSUSE 11.2. Существует уже очень давно, как Вы про него не знали?! :)

GladAlex ★★★★★
()
Ответ на: комментарий от GladAlex

>А в пакмане они чем собирают

Я даже не знаю, может кто-нибудь знает?

Вот этот родной не собирает:

kernel@linux-j8ob:~> gcc --version gcc (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839] Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Разработчики mplayer'а говаорят, что нужно 4.2 веткой собирать. В 4.4. много что изменилось.

anonymous
()
Ответ на: комментарий от GladAlex

2GladAlex **** (10.02.2010 12:31:23)

Я не знал :) Спасибо кто подсказал.

Просто всю жизнь на Debian сижу. Но по причинам, чтобы небыло холиварс в топике, ну буду писать почему на openSUSE _только_ на ноутбуке решил перейти.

anonymous
()
Ответ на: комментарий от anonymous

> 1) В какой репозитарий попадают? В твой личный. Из которого их может скачать весь мир, предварительно найдя в software.opensuse.org/search

2) Если есть зависимсоти, которые zypper не решит что будет

Так не бывает. Пакет в билдсервисе собирается на системе, к которой подключен основной репозиторий и этот твой личный репозиторий. Зависимостям, не удовлетворимым этими двумя репозиториями, взяться просто неоткуда. Если только ты их не пропишешь руками в .spec, но тогда пакет не соберется.

anonymous
()
Ответ на: комментарий от anonymous

> 1) В какой репозитарий попадают?

В твой личный. Из которого их может скачать весь мир, предварительно найдя в software.opensuse.org/search

2) Если есть зависимсоти, которые zypper не решит что будет

Так не бывает. Пакет в билдсервисе собирается на системе, к которой подключен основной репозиторий и этот твой личный репозиторий. Зависимостям, не удовлетворимым этими двумя репозиториями, взяться просто неоткуда. Если только ты их не пропишешь руками в .spec, но тогда пакет не соберется.

anonymous
()
Ответ на: комментарий от anonymous

> В твой личный. Из которого их может скачать весь мир, предварительно найдя в software.opensuse.org/search

А можно сделать так, например, чтобы весь мир не мог скачать пока пакет не будет протестирован до конца мной. Т.е. После сборки его сразу можно найти через software.opensuse.org/search или нужно принудительно это сделать?

anonymous
()
Ответ на: комментарий от anonymous

>Так не бывает. Пакет в билдсервисе собирается на системе, к которой подключен основной репозиторий и этот твой личный репозиторий. Зависимостям, не удовлетворимым этими двумя репозиториями, взяться просто неоткуда. Если только ты их не пропишешь руками в .spec, но тогда пакет не соберется.

Мысль ясна, спасибо.

Скажем, у нас есть packman или mysuperrepo и в зависимостях у mplayer'а стоит x264 либа 78 минорной версии, а ее нет в данном репозитарии. Но без нее mplaer не запустится.

Какое поведение прогнозируется у zypper?

Как уже писал интересно поведение пакетного менеджера, т.е. были ли у Вас опыт по данной проблематике.

anonymous
()
Ответ на: комментарий от anonymous

В 11.2 mplayer из svn прекрасно у меня собирается. И обычный и многопоточный. Другое дело, что падает на некоторых файлах, т.е. в итоге проще действительно из репозитария поставить. И морды оттуда-же.

anonymous
()
Ответ на: комментарий от anonymous

2anonymous (10.02.2010 13:11:52)

А у меня на make вывалилась с error'ом

Разбираться не стал.

11.2 был не обновленный. Т.е. из коробки. Качал тарбол, т.е не из из svn.

Любопытно, а можно gcc --version Ваше посмотреть. Я же теперь не успокоюсь пока не соберу )

anonymous
()
Ответ на: комментарий от GladAlex

2GladAlex **** (10.02.2010 13:18:51)

Анонимоусов много, а Вы один )

Давайте только по делу.

anonymous
()
Ответ на: комментарий от anonymous

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

Можно снять флаг «publish» для этого пакета, тогда в репозиторий он не попадёт.

Скажем, у нас есть packman или mysuperrepo и в зависимостях у mplayer'а стоит x264 либа 78 минорной версии, а ее нет в данном репозитарии. Но без нее mplaer не запустится. Какое поведение прогнозируется у zypper?

В packman'е x264 либа 78 минорной версии есть, как и все необходимые для packman'овского же mplayer'а библиотеки.

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

Есть, конечно, вариант, что ты специально снимешь у пакета libx264 флаг «publish». В этом случае zypper при попытке поставить mplayer не найдет нужный пакет и предложит два варианта: не ставить mplayer либо игнорировать недостающие зависимости. Но таким вредительством нужно заниматься специально; понятно, что никто этого не делает.

Или я не так вопрос понял?

anonymous
()
Ответ на: комментарий от anonymous

любой из последних mplayer'ов собирал в генте с версиями gcc 4.4.х. Полет нормальный.

daemonpnz ★★★★★
()
Ответ на: комментарий от anonymous

2anonymous (10.02.2010 13:26:47)

Я мысль уловил. Спасибо.

Просто в мои годы не было zypper'а, был только YAST и SAX2.

Вот и интересно как там дела обстоят.

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

Я правильно понял, все-таки можно собирать то, что нарушаем потенты, скачать и удалить :)

anonymous
()
Ответ на: комментарий от anonymous

> Просто в мои годы не было zypper'а, был только YAST

А в те времена у YaST'а поведение не такое же было бы? Просто к тому времени, как я узнал, что бывают репозитории кроме установочных CD/DVD дисков, это было так :) (правда, тогда и zypper уже был).

anonymous
()
Ответ на: комментарий от anonymous

> Я правильно понял, все-таки можно собирать то, что нарушаем потенты, скачать и удалить :)

Вот только есть ли смысл тогда заморачиваться с билдвервисом?

Да и потом, проблему представляют в основном низкоуровневые мультимедийные библиотеки (ffmpeg x264 etc.) и то, что от них напрямую зависит. Первое и большая часть второго есть в packman'е. Из того, чего нет, мне попадался только aegisub, но вот только нехрен в редакторе субтитров использовать ffmpeg напрямую: есть gstreamer и phonon.

anonymous
()
Ответ на: комментарий от anonymous

>А если соберу там, а будут зависимости, а у меня этих покетов дома нет. Что тогда? Кам там вопрос с зависимостями?

сервер можно настроить так, что он будет брать все недостающее с интернет-репозитариев, или каких-нибудь других, ллокальных

HighwayStar ★★★★★
()
Ответ на: комментарий от PayableOnDeath

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

Плюс автоматическое создание репов и еще много чего вкусного.

ZigmunD
()

2anonymous

вы не путайте сайт билдсервиса build.opensuse.org с самим билдсервисом, который зарелизился.

из сабжа можно установить у себя дома точно такой же билдсервис как на buil.opensuse.org с такой же вебмордой, и с оснонвным билдсервисом он никак связан не будет, собирать в нем можно будет все что угодно

для не-зузе десктопов есть cli утилита управления называется osc и еще какая-то фигня на mono была гуевая, пакеты с osc есть под другие дистрибутивы., в том числе под убунту, мандриву, дебиан и федору вот здесь http://download.opensuse.org/repositories/openSUSE:/Tools/

HighwayStar ★★★★★
()
Ответ на: комментарий от HighwayStar

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

HighwayStar ★★★★★
()

>Возможность запускать систему с USB-носителей

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

HighwayStar ★★★★★
()
Ответ на: комментарий от anonymous

>11.2 был не обновленный. Т.е. из коробки. Качал тарбол, т.е не из из svn.

Любопытно, а можно gcc --version Ваше посмотреть. Я же теперь не успокоюсь пока не соберу )

11.2 x64 из коробки. Версию gcc могу только вечером глянуть дома. mplayer и из svn, и из архива, либу x264 из git с сайта vlc брал.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.