После десяти месяцев разработки подготовлен (http://openbuildservice.org/2017/04/07/version-2.8/) релиз платформы Open Build Service 2.8 (http://www.open-build-service.org), которая позволяет (http://en.opensuse.org/Build_Service) организовать процесс разработки дистрибутивов и программных продуктов, включая подготовку и сопровождение релизов и обновлений. Система даёт возможность выполнить кросс-компиляцию пакетов для большинства основных дистрибутивов Linux или собрать собственный дистрибутив на основе заданной пакетной базы.Поддерживается сборка для 22 целевых платформ (дистрибутивов), включая CentOS, Debian, Fedora, Mandriva, openSUSE, SUSE Enterprise Linux, Red Hat Enterprise Linux (RHEL) и Ubuntu. Сборка возможна для 6 архитектур, в том числе i386, x86_64 и ARM. OBS используется в качестве первичной системы для сборки проектов openSUSE, Tizen, Sailfish, Mer, ownCloud и VideoLAN, а также для сборки Linux-продуктов в компаниях Dell, Cray и Intel.
Для сборки свежей версии заданной программы в виде бинарного пакета под нужную систему достаточно создать spec-файл или подключить репозиторий пакетов, представленный на сайте software.opensuse.org (http://software.opensuse.org/). Кроме того, можно сформировать готовое минималистичное окружение для выполнения в системах виртуализации, cloud-окружениях или для загрузки в виде Live-дистрибутива. При работе с OBS разработчик может использовать готовый online-сервис build.opensuse.org (http://build.opensuse.org/) или установить (https://github.com/openSUSE/open-build-service) подобную систему на своём сервере. Кроме того, можно быстро развернуть собственную инфраструктуру при помощи специально подготовленных образов (http://www.open-build-service.org/download/) для виртуальных машин, локальной установки или для PXE-загрузки по сети.
OBS даёт возможность автоматизировать загрузку исходных текстов из внешних Git или Subversion репозиториев или архивов с кодом с ftp- и web-серверов первичных проектов, что позволяет избавиться от промежуточной ручной загрузки архивов с кодом на локальную машину разработчика и последующего импорта в openSUSE Build Service. Сопровождающим пакеты предоставляются средства для определения зависимостей от других пакетов с автоматической пересборкой данных зависимостей при внесении в них изменений. При добавлении патчей имеется возможность их тестирования с аналогичными пакетами от других проектов.
Для управления Open Build Service можно использовать как инструментарий для командной строки, так и web-интерфейс. Имеются средства для подключения сторонних клиентов и использования ресурсов с внешних сервисов, таких как SourceForge и kde-apps.org. Разработчикам доступны инструменты для создания групп и организации совместной работы. Код всех компонентов системы, включая web-интерфейс, систему тестирования пакетов и сборочные бэкенды, полностью открыт (https://github.com/openSUSE/open-build-service) под лицензией GPLv2.Среди улучшений (https://github.com/openSUSE/open-build-service/blob/2.8/Rele...), добавленных в Open Build Service 2.8:
- В сборочный бэкенд добавлена экспериментальная возможность формирования самодостаточных пакетов в формате snap;
- В бэкенд добавлена функция mulibuild, позволяющая инициировать несколько сборочных заданий из одного src-пакета, без необходимости определения локальных привязок;
- Модернизирован интерфейс пользователя, добавлена поддержка фильтрации проектов на основе регулярного выражения (фильтр задаёт администратор проекта). Обеспечена возможность инициирования запуска сервисов из GUI. Пользователям предоставлена возможность загрузки открытых GPG-ключей и SSL-сертификатов со страницы проекта или через API. Добавлена опция для импорта описаний процесса сборки в формате Kiwi;
- API расширен средствами для более полного управления пользователями, в том числе добавлены вызовы для блокирования и удаления пользователей из проектов. Реализована возможность определения пользователей как дочерних учётных записей других пользователей (например, удобно для организации запуска скриптов не под основным аккаунтом);
- В компонент для управления работами и отслеживания выполняемых работ добавлен новый сервис obsservicedispatch с реализаций очереди для запуска сервисов в асинхронном режиме;
- В CLI добавлена команда "osc unpublish", позволяющая удалить уже опубликованные пакеты.URL: http://openbuildservice.org/2017/04/07/version-2.8/
Новость: http://www.opennet.ru/opennews/art.shtml?num=46348
Надеюсь что Snap просуществует дольше, чем Mir и Unity DE
А вы уже их пробовали?
Я пробовал, космонафтика. Не говоря уже о том что фильтрация сисколов это шиза.
А как там flatpack в плане безопасности? Говорят при установке snap в Fedora приходится отключать SELinux. И ещё там нет изоляции.
Говорят, SElinux и Apparmor отключают только неосиляторы. Было бы желание, настроить их можно.
два друга пробовали - оказались в писихушке..
в федоре легче там гайды есть, я находил, а вот про апп армор я забил и оставил что есть на убунте...но да, было бы желание, но я оставляю эти варнинги для мэйнтэйнеров пакетов, все таки я простой пользователь, а не админ.
Apparmor проще настроить чем SELinux.
Два воображаемых друга...
> Два воображаемых друга...Почему соседи поциента по палате не могут быть его друзьями?
вот именно, все просто настроить. Пользуюсь AppArmor, пишу кастомные правила под себя, все работает как надо.
> фильтрация сисколов это шиза.У Вас, наверное, есть предложение, как сделать ограничение возможностей процесса лучше?
Процесс в контейнер, контейнер в виртуалку, виртуалку в утку, утку в сундук.
а кощею по яйцам
Как недавно выяснили, оно у него одно.
Виртуалки - хороший вариант изоляции, но немного оверкил. Хотя Qubes OS - вполне годная вещь.
bubblewrap?
Попробовал данную систему внедрить на работе. Требовалась система для автоматизированной сборки rt-ядра под разные архитектуры.Впечатление ужасное. Система ни капли не интуитивно понятная. Чтобы понять, как добавляется репозиторий, мне пришлось потратить пару-тройку дней. А примеры (команды для сборки базовой версии окружения) пришлось самому искать на их сайте сборки, ибо мануалов нигде не нашёл. Документация либо устаревшая, либо непонятна, либо её просто нет (касательно новых возможностей web-интерфейса).
Количество багов - зашкаливает. Одно только удаление задание через веб-интерфейс чего стоит. После каких-то действий появлялось новое задание с названием "[Deleted]". Я был очень удивлён увидеть свою удалённую задачу с другим названием. Я могу себе представить причину ошибки, т.е. что забыл сделать разработчик. Но тут на лицо очень жёсткий костыль.
Итог - ждём, когда выйдет более стабильная и документированная версия.
Уточню, - комментарий относился к версии 2.6, устанавливался поверх OpenSUSE.
Спасибо. Если не секрет, чем в конце концов пользуетесь?
Для сборки ядра и программы пока пользуемся самописными скриптами и виртуализацией, но это крайне неудобно. А для сборки программы идут эксперименты с Gitlab. Там это возможно через заранее подготовленные контейнеры Docker.
>идут эксперименты с GitlabGitLab Runner, не только через контейнер но и отдельную VM, которую можно заснапшотить и будет куда удобней чем через docker.
Не будет удобнее. Заранее подготовленный контейнер предполагает обычный Dockerfile и push в Container Registry. Плюс такого подхода в том, что Dockerfile можно держать прямо в исходниках и обновлять образ каждый раз при добавлении в ПО новых зависимостей вместе с коммитом. Пока мы эту схему внедрить не успели, но в теории должно быть именно так. Но даже без этой схемы образ по сути то же самое, что снапшот.А насчёт ВМ - так это необходимо, например, если не хочется заморачиваться с кросс-компиляцией. Были когда-то сложности: ядро компилировалось под 32 бита, а некоторые модули компилировались под 64 бита, из-за чего ядро стартовало, но выдавалj ошибки. Стандартные команды, ничего особенного. Но чем выяснять причину, проще было перейти на ВМ, что и сделали. Ещё, к примеру, можно поднять новую ВМ c полной эмуляцией ARM и в ней пускать уже без Docker.
Интересно, а зачем вам риалтайм-ядро?
> Интересно, а зачем вам риалтайм-ядро?Embedded
Веб-интерфейс там только для тех, кто не осилил osc. С ним же всё становится намного проще. Впрочем, не уверен, что для Вашей задачи OBS — подходящее решение. Он нужен, когда есть необходимость поддерживать репозитории с десятками и более пакетов, особенно если они нужны под разные дистрибутивы.
Пакетов будет довольно много будет. Ядро только один из них. Поэтому хотелось универсальное решение. Через командную строку то удалось создать простейший пакет под Ubuntu и под Debian. Собственно, через веб-интерфейс не удалось сделать вообще ничего. Но, учитывая, сколько времени было потрачено на то, чтобы разобраться с основами, решил отложить внедрение. Ведь ещё требуется интегрировать его с Gitlab Runner, - работы слишком много.
ALT Linux уже добавлен в OBS? Где можно посмотреть?
Ещё спросите добавили ли snap в ABF.
>ALT Linux уже добавлен в OBS?и сертефикат ФСТЭК
сертификат
Сделай сам, расскажи как - помоги всем!
> ALT Linux уже добавлен в OBS? Где можно посмотреть?А запрос такой был? Если много народу просит — они добавляют, а если нет — значит оно никому и не нужно.
Все, что не скрыто от юзера, теперь модно называть с приставкой опен. Вот в винде рабочий стол доступен юзеру - ждите переименования в Open Desktop.
Сразу видно — молодняк! Даже не застал журнал Open Systems!!!
Хоре уже пиарить, в зубах навязло. Клиент на петоне кстати, ну я про osc. Говорят, можно использовать и для локальной сборки, типа checkinstall, но мне пока лень разбираться и вообще стремно связываться с ЭТИМ.
> даёт возможность автоматизировать загрузку исходных текстов из внешних Git или Subversion репозиториев или архивов с кодом с ftp- и web-серверов первичных проектов, что позволяет избавиться от промежуточной ручной загрузки архивов с кодом на локальную машину разработчика и последующего импорта в openSUSE Build Service. Сопровождающим пакеты предоставляются средства для определения зависимостей от других пакетов с автоматической пересборкой данных зависимостей при внесении в них изменений. При добавлении патчей имеется возможность их тестирования с аналогичными пакетами от других проектов.Прям как про Nix прочитал.
Решил я недавно снап попробовать.
Плеер deadbeef затянул более чем 100мб и сама система снап- ирования
600мб+ на диске.
И нафига оно такое нужно?
У wine и программ установленных под wine, аппетит и то меньше.
дпкг в помошь.
В среднем каждая 10-я новость на OpenNet начинается словами "После [такого-то времени] разработки". Может пора сменить пластинку, а то что-то смахивает на партийные доклады при Брежневе.
Это потому что выдумывание очередного велосипеда с четырьмя колёсами далось нелегко.
Эта штука собирает по спеку. Как внезапно и rpmbuild. О чем новость?
новосиь о выходе новой версии obs, дегенерат
Зачем придумывать велосипед когда есть ebuild?
ebuild пока не может собирать самодостаточные пакеты. Этот, несмотря на кривость здесь по отзывам, может Snap.
А зачем нужны самодостаточные пакеты, и кому? Неосиляторам зависимостей?
А зачем нужны эти зависимости и зачем нужно осиливать их?
Так принято. Это как марафон или тотальный диктант - ты изнуряешь себя решением бессмысленных и бесполезных задач чтобы почувствовать принадлежность к группе. Это вызов себе, настоящее состязание. В первую очередь, с самим собой.
Это когда люди начинают путать решение основной задачи с игрой в "плюшки". Таким часто заболевают программисты и мудрый менеджер с хорошим пряником и кнутом знает как такое исправить. Кнутом по морде и пряник в ж опу. Приводит в чувство программистов сразу же. и вместо того,чтобы страдать фигней, начинают делом заниматься.
Если они самодостаточные, то им и ОС не нужна должно быть
>или собрать собственный дистрибутив на основе заданной пакетной базыА оно на основе каких подсистем инициализации может собрать собственный дистрибутив? Например, OpenRC, используемой в проекте OpenWRT или в BusyBox?
>>или собрать собственный дистрибутив на основе заданной пакетной базы
> А оно на основе каких подсистем инициализации может собрать собственный дистрибутив? Например,
> OpenRC, используемой в проекте OpenWRT или в BusyBox?На основе тех, которые ты осилишь опакетить.