⌨ Labor omnia vincit ☮

openSUSE factory :: cool-retro-term

Posted in Qt, SuSE [ru] by anaumov on 14.09.2014

cool-retro-term

Advertisements

openSUSE :: CITRIX Receiver 13.0

Posted in SuSE [ru] by anaumov on 26.05.2014

200px-Citrix.svgCitrix Receiver является ключевым элементом комплексной стратегии Citrix в области виртуальных вычислений, которая была создана с целью оптимизировать работу ИТ-служб и предоставить пользователям большую гибкость при выборе способа и места работы. Решение Citrix Receiver позволяет сотруднику, находящемуся вдали от офиса, работать с привычными настольными, web- или SaaS-приложениями и инструментами в режиме реального времени (посредством собственного ICA-протокола).
Рассмотрим процесс её установки в openSUSE 13.1 (x86_64).
Читать дальше…

Every little bit counts ;)

Posted in SuSE [ru] by anaumov on 28.04.2014

SUSE_CLA
То самое чувство, когда ты Software Engineer и к администрированию не имеешь вообще-то никакого отношения 🙂

New openSUSE kernel available for testing

Posted in Linux Kernel, SuSE [ru] by anaumov on 10.01.2014

Сегодня утром были пересобраны desktop ядра 3.11.10. Был добавлен патч, исправляющий проблему с зависанием (минут на 20) во время установки системы (на этапе инициализации разделов: seeking for Linux partitions). Проблема заключалась в запуске blkid(8) для устройства /dev/fd0.

Тестируем:

  • Найти машину, на которой получится воспроизвести проблему
  • Отключить floppy в BIOS
  • Установить систему
  • Включить floppy в BIOS
  • Убедиться, что yast2 partitioner зависает
  • Устанавливать новое ядро ​​и перезагрузиться
  • Убедиться, что yast2 partitioner больше не зависает 🙂

Эта проблема не связана с новым YaST, который недавно был переписан. Баг тянется еще с openSUSE 12.2 (патч добавлен и в SLE-SP3).

Если BIOS не позволяет отключить floppy, просто добавте brokenmodules=floppy как параметр при загрузке. При этом не забудьте проверить modprobe.conf посте успешной установки (во время тестирования).

openSUSE :: Atheros TL-WN822N

Posted in Linux Kernel, SuSE [ru] by anaumov on 01.09.2013

TL-WN822N-atherosЦикл тестирования следующей версии нашего любимого дистрибутива в самом разгаре. Сейчас я работаю с четвертой milestone и хотел бы коротко рассказать о внешнем USB wifi-адаптере TL-WN822N от компании TP-LINK. Он соборан на основе седьмого и девятого поколения чипов Atheros Communications.

В июле 2008 г. компания Atheros решила сменить политику, наняла двух ключевых разработчиков Linux: Луиса Родригеса (исп. Luis Rodriguez) и Йоуни Малинена (фин. Jouni Malinen), выпустивших открытые драйверы для работы устройств 802.11n в Linux. Atheros также опубликовала часть исходного кода их бинарного HAL под лицензией ISC в целях помощи сообществу в добавлении поддержки чипов Atheros 802.11a/802.11b/802.11g. Компания стала принимать активное участие в разработке драйвера ath9k для Linux, с поддержкой всех нынешних 802.11n чипсетов.

Итак, драйвера ath9k и ath9k_htc открыты и включены в ядро. Тем не менее, ожидаемого результата после включения этого устройства мы не получим… но обо всем по порядку.
Читать дальше…

openSUSE :: Encrypted File Systems

Posted in Linux Kernel, SuSE [ru] by anaumov on 22.07.2013

Криптография – наука о шифрах – очень глубокая, требующая изучения, тема, история которой насчитывает более четырех тысяч лет. Это один из основных инструментов, использующихся при защите информации. Спецслужбы бывшего Советского Союза, США, Франции и других стран вкладывали огромные средства в разработку криптостойких алгоритмов для своих информационных каналов, параллельно пытаясь вскрывать чужие. Сегодня этими технологиями мы пользуемся каждый день, даже не задумываясь об этом.
Причин зашифровать информацию может быть несколько. К примеру, у вас есть любого рода секретная информация, которая ни в коем случае не должна попасть к кому-то конкретно, а может вы просто хотите оградить свою личную жизнь от чужих глаз. Мы теряем нетбуки или флешки, а на них, как правило, конфиденциальная информаця. Просто поломка носителя это уже печально, но на много хуже, когда наша информация попадает в чужие руки. Можно лишь догадываться как будет использованна эта информация, и надеяться, что она не будет использованна нам во вред.
В этом посте я расскажу о методе шифрования файловых систем (ФС) в openSUSE 13.1-m3, которая собрана на основе последней на данный момент stable-версии ядра – 3.10.0.
upd:
Тут вы так же можете найти руководство (добавленное в октябре 2018) по установке openSUSE Leap 15.1 на зашифрованный LVM-контейнер.
Читать дальше…

[factory] openSUSE 13.1 :: Milestone 3

Posted in SuSE [ru] by anaumov on 17.07.2013

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

Кстати, как вы наверняка помните, с января этого года несколько ребят из Чехии работали над переводом YaST на Ruby. Тем самым было принято решение избавиться от старого проприетарного языка YCP. Язык Ruby был выбран для более простого взаимодействия с WebYaST. Образы третьего milestone с новым YaST можно найти тут.

Хотелось бы также упомянуть о вчерашнем выходе KDE 4.11 RC1. В ISO-образ с milestone он естественно не попал, но пересобрать мы его уже успели. Все необходимые oS-пакеты доступны для тестирования. Для этого, как обычно, необходимо подключить KDE:Distro:Factory репозиторий и обновиться. Тем самым вы убиваете двух зайцев: тестируете и новый KDE и openSUSE 🙂
Не забудьте только, что об ошибках в openSUSE надо сообщить на http://bugzilla.novell.com/ (это ошибки, связанные в основном с неправильной работой пакетов, конфликты при установке, проблемы с зависимостями, отсутствием файлов или неправильной установкой прав для них), а вот в случае с проблемами в самом KDE сообщить стоит на http://bugs.kde.org/ (крах программ или просто их некорректная работа). Помните также, что вы работаете с нестабильными версиями как самой openSUSE, так и KDE. Это не релиз, и никто даже не намекает на стабильное поведение этой связки. Используйте это только для тестирования!

Последнюю тестовую версию openSUSE вы можете найти тут.

openSUSE Kicks Off Development with Milestone 3
openSUSE 12.3 openSUSE Factory
KDE 4.7.2 4.10.90
GNOME 3.6 3.9.3
apache2 2.2.22 2.4.4
digikam 3.0.0 3.2.0
giflib 4.1.6 5.0.4
icecream 0.9.7 1.0.1
kernel 3.7.10 3.10.0
libreoffice 3.6.3.2.4 4.0.3.3.4
ocaml 3.12.1 4.00.1
qemu 1.3.0 1.5.0
qt-creator 2.6.2 2.7.2
ruby 1.9.3 2.0
systemd 195 204
wpa_supplicant 1.1 2.0
xorg-x11-server 1.13.2 1.14.2

Test the upcoming openSUSE 12.3 + KDE 4.10 Workspace

Posted in KDE, SuSE [ru] by anaumov on 09.02.2013

KDE 4.10 WorkspaceОстается месяц до выхода следующей версии нашего любимого дистрибутива. Я хотел бы напомнить всем пользователям KDE, что наши образы можно найти тут. 3 дня назад были пересобраны образы последней openSUSE 12.3 с KDE 4.10 Workspace.

Пожалуйста не поленитесь потратить один вечер и проверить их на своем железе. Следуйте инструкциям на этой странице для записи образа на USB. Как и обычно, о найденных ошибках в KDE вы можете сообщить на bugs.kde.org, или на bugzilla.novell.com в случае проблем в самой openSUSE. Не забывайте, что это live-образы, т.е. настройки не сохраняются между сессиями.

Напомню так же, что в Beta1 был поломан GRUB2, который автоматически добавлял пункты меню для других установленных на компьютере ОС, однако не позволял их загрузить. Я так же жду продвижения в работе над ошибкой в YaST/udev, которая возникает во время установки системы на этапе инициализации оборудования (установщик замирает на отметке в 60%). Не забываем про NetworkManagement и systemd! KDE разработчики просят так же обратить внимание на этот список.

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

(fun (open-build-service (+ openSUSE stumpWM)))

Posted in Lisp, SuSE [ru] by anaumov on 10.10.2012

Common Lisp – один из диалектов мультипарадигменного языка программирования Lisp. Поддерживает комбинацию процедурного, функционального и объектно-ориентированного программирования. Я начал изучать Lisp именно из-за его истинно функциальной природы. Реализация решений тех или иных задачь при использовании функционального подхода (декларативного программирования) сильно отличается от столь привычного императивного. Его использование очень расширяет горизонты программиста.

Одной из интересных особенностей Lisp-программ является возможность их изменения “на лету”. Это значит, что мне не надо их перекомпилировать или перезапускать интерпретатор. Я просто подключаюсь к запущенному процессу и меняю его поведение, внося изменения в его код. Это делает хакинг на много проще и интересней.

К сожаленью в openSUSE-репозиториях практически нет Lisp-программ. Есть Emacs, но он написан на Emacs Lisp, а это другой диалект с другими правилами. Есть Lisp-интерпретаторы, но вносить изменения в код интерпретатора и следить за изменениями в его поведении все же не столь интересно. Свои первые программы aka “hello world” изменять тоже скучно; хочется работать с большим проектом, чтение кода которого научит тебя новым трюкам этого языка и просто покажет как надо на нем программировать.

Мой выбор остановился на проекте stumpWM. Его не было в репах, так что собирать его предстояло из исходников. Собрать С/C++ или даже Python-проекты с Qt/GTK+ библиотеками не составляет особого труда для большинства из нас, но в мире Lisp все это работает несколько иначе…
Читать полностью…

ARM cross compilation using OBS

Posted in ARM, SuSE [ru] by anaumov on 05.10.2012

Кросс-компиляция — это процесс компиляции кода для другой платформы, т.е. отличной от той, на которой она выполняется. Причин для кросс-компиляции может быть несколько, например скорость сборки, или просто недоступность той архитектуры, для которой нужно собрать проект. Я в двух словах расскажу о кросс-компиляции для ARM процессоров. Эта архитектура становится все более популярной.

Для знакомства с ARM я раздобыл RaspberryPi. Она представляет из себя так называемую development-board систему, на борту которой два USB, один 10/100 Ethernet, слот для SD/MMC/SDIO карт (с нее и стартует ОС), GPIO-разьем, HDMI, Broadcom BCM2835 чипсет, 256 MB памяти SDRAM и 700 MHz ARM11 процессор. Питание через microUSB (5V/700 mA). Стоит это удовольствие не больше стакана хорошего виски, т.е. порядка 20-30 € (в зависимости от цены за доставку). Думаю, что те, кто понимает, что речь идет о самой перспективной в мире архитектуре для мобильных устройств, не будут долго раздумывать о цене 🙂
Но вернемся к кросс-компиляции…

Первое, о чем хочется сказать – это о принципе кросс-компиляции и работы OBS вообще. Для того, чтобы скомпилировать и слинковать программу для другой архитектуры нам понадобиться окружение, в котором будет доступен инструментарий разработки для этой архитектуры. Недостаточно просто сказать компилятору, чтобы он транслировал, к примеру, С-код программы для ARM, потому что даже для hello world будет использоваться внешняя библиотека glibc. Линковка объектного ARM-кода с x86_64-библиотекой в лучшем случае приведет к segmentation fault. В этом плане принцип кросс-компиляции один в один повторяет принцип работы OBS: для каждого процесса сборки OBS создает специальное окружение. Это окружение представляет из себя изолированную псевдо-систему, внутри которой запускается свой компилятор или интерпретатор, который опрашивет “свои” библиотеки. Так, к примеру, OBS работает под управлением 64-битной openSUSE, а в build-окружении может быть 32-битная Debian-система.

> cat /proc/cpuinfo 
Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 0002
Serial          : 000000003f1fd8df

Ок, 32- и 64-битные архитектуры все же как-никак совместимы, а что делать в случае с ARM? Для этого добавляется еще один необольшой, но очень важный компонент сборки – эмулятор процессора qemu. Использование эмулятора позволит нам на x86_64 процессоре собрать бинарные пакеты для архитектур armv5el и/или armv7l.

Packaging

Давайте теперь соберем тестовый пакет для RaspberryPi. Создадим самый простой spec и какой-нибудь hello world на С. Я думаю, что примеры этих файлов давать не надо, выглядеть они дожны точно так же как и для x86_64 арихитектуры (никаких особых параметров компилятору передавать не надо, но не забудьте установить пакет qemu-linux-user). После этого в том же каталоге соберем rpm следующей командой:

> osc build --alternative-project=openSUSE:Factory:ARM armv5el armv5el *.spec --clean

Как вы видтие, для создания окружения мы используем “альтернативный проект” openSUSE:Factory:ARM, репозиторий armv5el для арихитектуры armv5el. Именно из этого репозитория будут установленны необходимые для ARM-сборки компоненты. Все окружение будет развернуто за пару минут. Если ошибок в коде и spec-файле нет, то мы получим rpm для armv5el. Если вы решили начать с чего-то посложнее, то не забывайте, что процесс портированая openSUSE на ARM еще не закончен. Не все библиотеки, доступные для i586 и x86_64, пересобранны для ARM. Полный список для armv5el тут.

То же самое касается сборки для других дистрибутивов: внимательный читатель уже наверное заметил, что мы собрали rpm, а на RaspberryPi по дефолту скорее всего будет Raspbian. В OBS пока не собранно достаточно deb-пакетов для создания ARM-окружения. По этой причине придется либо использовать alien, либо вручную распаковывать rpm и собирать deb. Для “поиграть” такой метод еще пойдет, но о непрерывной интеграции (в случае использования Raspbian на производстве) пока не может быть и речи.

В сети вы можете найти много мануалов о создании ARM-окружения при помощи различных toolchain. Описание создания такого окружения для кросс-компиляции занимает как правило около полстраницы. OBS создает это окружение одной командой, предоставляя разработчику готовые к инсталяции пакеты.

openSUSE :: Broadcom wireless

Posted in SuSE [ru] by anaumov on 26.08.2012

Большинство wifi контроллерв поддерживаются ядром openSUSE из коробки. Тем не менее, некоторые драйверы (именно они обеспечивают поддержку контроллеров/устройств) не включаются в ядро из-за проблем с лицензией. В эту группу входит и модуль для broadcom контроллера, счастливым обладателем которого на своем lenovo S12 являюсь и я 🙂

Первый шаг в настройке wifi – определение чипсета (набора микросхем) и его производителя. Для этого можно воспрользоваться либо lspci (или lsusb, если карта подключенна через USB), либо hwinfo:

> /sbin/lspci | grep Network
07:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)

После того как мы узнали, что на борту у нас BCM4312 чип от broadcom, заходим к ним на страницу и смотрим, если ли у них драйвер для нашей wifi. Драйвер есть, и поддерживает он не только bcm4312 чипы, но и bcm4313, bcm4321, bcm4322, bcm43224, bcm43225, bcm43227 и bcm43228. Мы можем скачать архив с их сайта и установить драйвер из исходников, но лучше использовать rpm, инсталляция с помощью которого значительно упростит дальнейшую настройку wifi.

Кстати, если у вас более старый чип (bcm4303, bcm4306, bcm4309, bcm4311, bcm4318), вы можете использовать firmware из пакета b43-fwcutter:

> sudo zypper in b43-fwcutter
> sudo /usr/sbin/install_bcm43xx_firmware

Вы должны быть online пока не завершится установка.

Возвращаемся к чипу BCM4312. Необходимые пакеты лежат в suse-репозитории packman. Можно подключить вручную этот репозиторий и установить пакет broadcom-wl, который, в зависимости от используемого ядра, потянет за собой еще пару пакетов-зависимостей.

> sudo zypper ar http://packman.inode.at/suse/openSUSE_11.4 packman
> sudo zypper mr -r packman
> sudo zypper in broadcom-wl

То же самое можно сделать автоматически через механизм one-click-install. Для этого просто нажмите на иконку. Обратите внимание, что в примере я подключаю репозиторий openSUSE 11.4. One-click-install-метод автоматически добавит репозиторий для используемой вами версии openSUSE(12.1/12.2?).

После установки пакета в списке подгруженных модулей мы видим наш новый драйвер:

> pwd
/sys/bus/pci/devices/0000:07:00.0

> l | grep driver
lrwxrwxrwx 1 root root     0 Aug 26 22:20 driver -> ../../../../bus/pci/drivers/wl/

> lsmod | grep wl
wl                   2463028  0 
cfg80211              154761  1 wl
lib80211                5542  2 lib80211_crypt_tkip,wl

# hwinfo --wlan --short
network:                                                        
  eth1                 Broadcom BCM4312 802.11b/g

Имя нового сетевого интерфейса – eth1, вместо ожидаемого wlan0, но это не играет особой роли. Теперь выходим в инет или просто подключаемся к какой-нибудь wifi-сети. Список сетей, который видит наша карта, можно посмотреть с помощью iwlist:

> /usr/sbin/iwlist eth1 scan | grep ESSID
                    ESSID:"EasyBox-5DD252"
                    ESSID:"EasyBox-3CC555"
                    ESSID:"alex"
                    ESSID:"x23aatm.144"
                    ESSID:"WLAN-4B8775"
                    ESSID:"Arcor-C82816"
                    ESSID:"Hier gibts WLAN"
                    ESSID:"Leega-Speed"

Моя сеть называется “alex”, и для выхода в инет я буду использовать не NetworkManager, который является дефолтным для этого в openSUSE, а wpa_supplicant.
Единственное, что надо сделать перед его запуском – сгенерировать WPA/WPA2-Enterprise PSK для нашей SSID. Для этого запускаем wpa_passphrase и передаем ей два параметра – SSID и пароль. Например:

> wpa_passphrase alex alexalex
network={
        ssid="alex"
        #psk="alexalex"
        psk=9036fc877e43a122dab5454ecbb3245d8bd4edbc50d903c8a9b6182311522517
}

Это вывод wpa_passphrase. Копируем теперь это в любой файл, например в ~/wifi.conf и добавляем в начало две строчки:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

Все, конфиг готов (более подробная информация о синтаксисе/параметрах конфиг-файла). Теперь скармливаем его wpa_supplicant, указывая также имя устройства, под которым драйвер зарегистрировал wifi-карту. Не забываем после этого сделать dhcp-запрос:

> wpa_supplicant -i eth1 -c wifi.conf &
> dhclient eth1

Все достаточно просто, проблем возникнуть не должно. Через ifconfig проверь IP и, если dhcp-сервер ответил, доступ в сеть открыт. Обрати внимание, что для настройки wifi и выхода в сеть нам не понадобился ни X-сервер, ни какие-либо GUI.

OBS and Jenkins: a bit about continuous integration and packaging

Posted in GNU/Linux, SuSE [ru] by anaumov on 25.06.2012

Трудно представить разработку крупного software-проекта без системы непрерывной интеграции. Они являются неотъемлемой частью инфраструктуры любой software-компании. Уже около года я использую параллельно две open source системы: Jenkins и OBS. Являются ли они взаимозаменяемыми, какая для каких проектов больше подходит и на какую стоит обратить внимание, я расскажу в этой небольшой статье. Задача, которую я ставил перед обоими системами, достаточно тривиальна для большинства software-компаний: пересборка новых RPM/DEB-пакетов после svn-/git-коммитов группы разработчиков, и скалыдвание их в определенном порядке в соответствующие репозитории.

Who is who?

Проект Open Build Service (первоначально openSUSE Build Service) был начат в главном отделении SUSE/Novell, как платформа для разработки дистрибутива openSUSE/SLE, и впервые был представлен на FOSDEM в 2006 году. Все компоненты OBS являются Free Software. Проект поддерживают такие организации и компании как Linux Foundation и AMD, а так же имеет большое дружное сообщество. Написан на perl/ruby/python.
Разработка Jenkins (первоначально Hudson) была начата в Sun Microsystems. Проект, как того и стоило ожидать, целиком написан на Java. Распространяется по MIT-лицензии.

OBS представляет из себя абсолютно самодостаточную development-платформу. Развернув её вы получите в свое распоряжение не только систему управления версиями, семантика которой идентична svn/cvs/git, но и репозиторий с новоиспеченными пакетами, который будет автоматически создан/обновлен после каждой удачной сборки. Jenkins в этом плане представляет из себя более модульную систему. Вам придется во-первых настроить svn/cvs/git-хранилище, во-вторых для создания репозитория придется также немного поколдовать (еще одно “shell-правило”). С другой стороны, если проект был создан до установки Jenkins, то это как раз то, что вам нужно, а вот интеграция такого проекта с OBS потребует доустановки специальных дополнений, синхронизирующих его хранилище с svn или git. Для обоих систем есть большое количество плагинов, расширяющих их возможности.

Time of build

OBS собирает пакет в свежем окружении выбранного дистрибутива, учитывая зависимости и архитектуру. Процесс сборки одного пакета длится около 3-5 минут (все это время уходит в основном на установку окружения). Это не гарантирует корректной работы пакета. Pre/Post-скрипты не запускаются, а это значит, что даже если вы успешно пересобрали пакет, он все равно может быть сломаным. К сожаленью, OBS так же не предусматривает добавление тестов, которые должен пройти пакет. Другими словами, стабильность работы пакета полностью ложится на плечи команды QA.
Кстати, изменив один файл в проекте, работая через WebUI, OBS запускает новый build-процесс, потому что воспринимает это как новый коммит (build-процесс запускается автоматически после каждого коммита). Таким образом, если вам надо будет изменить более одного файла, вы постоянно будете обрывать предыдущий build-процесс, начатый после предыдущего коммита автоматически. При сборке RPM это не так критично, но в случае сборки DEB-пакетов, где, к примеру, номер версии пакета находится в двух файлах и должен быть одинаковым, это будет происходить постоянно. Чтобы этого не происходило используйте osc, где у вас есть время подумать после исправления первого файла и перед изменением второго, и лишь после этого сделать коммит.

Jenkins не предоставляет каких-либо специальных вкусняшек для сборки пакетов. Собирать их можно самым обычным образом через dpkg -deb или rpmbuild. У этого метода есть одно преимущество – скорость сборки. На один пакет уйдет паку секунд. Для этого надо просто создать каталог со структурой, который будет иметь пакет. Pre/Post-скрипты так же запущенны не будут, так что удачи при тестировании.
Стоит отметить, что хоть обе системы и не тестирует новоиспеченные пакеты, мы можем добавить целую группу shell-правил (при использовании Jenkins) или просто написать скрипт, используеющий osc (при использовании OBS), так или иначе эмулирующих эти тесты.

Resources

В связи с тем, что OBS является более профессиональной системой, специально заточенной для сборки пакетов, он сначала создает псевдосистему, в которой после и происходит сборка пакета. Это дает незаменимое преимущество при разработке сложных систем, состоящих из группы пакетов (дистрибутивов). Тут, как я писал выше, учитывается и архитекрура, и связи с другими пакетами, которые уже установленны в системе. Как вы понимаете, для развертывания такой системы нужны ресурсы. Для каждой сборки OBS требует один CPU_CORE. К примеру, вам надо собрать два разных пакета для Debian и Ubuntu, для 32- и 64-битной архитекруры. Для параллельной сборки понадобится 8 ядер. Я не знаю точно сколько разработчики советуют использовать RAM для каждой сборки, но по моему наблюдению меньше одного гигабайта на один build-процесс лучше не выделять.
Jenkins не соберет пакет для ARM или PowerPC, он так же не скажет вам, что файл с таким именем создать нельзя, потому что в системе уже существует файл с таким именем, и принадлежит он другому пакету. Если вы занимаетесь разработкой проекта, установка которого никак не влияет на систему (к примеру, не будут измененны/перезаписанны системные файлы), то Jenkins’ом вполне можно обойтись. Это может быть, к примеру, Java-проект, код которого протестирует Jenkins во время сборки, соберет проект, после чего мы получим jar-архивы, и положит эти jar-архивы в пакет. При установке все эти архивы будут просто скопированы в нужный нам каталог. Для сборки такого проекта не нужна псевдосистема, разворачиваемая OBS’ом для каждого пакета, следовательно нам не надо ждать 3-5 минут и тратить на это такие ресурсы. Нам надо просто запаковать наш каталог в deb или rpm-архив. Jenkins сделает это за пару секунд, даже если вы выделите ему всего один гигибайт на все про все.

Conclusion

OBS предоставляет очень интересные возможности для профессиональной архитектурно-зависимой сборкой сложных пакетных систем. Платой за это являются потребляемые им ресурсы, некоторые проблемы, которые могут возникнуть при обновлении OBS, а так же обучение персонала работе с osc. Jenkins более наглядно показывает историю build-процессов, более стабилен в работе и настройке, и не столь требователен к ресурсам. Он так же очень прост в использовании, но не предоставляет таких возможностей для разрабтки пакетных дистрибутивов, оставаясь системой непрерывной интеграции общего назначения.

openSUSE :: Russian Documentation

Posted in SuSE [ru] by anaumov on 05.05.2012

Хочу напомнить, что для всех русскоязычных пользователей openSUSE есть переводы официальной документации. Documentation Team предоставляет возможность отправлять им переводы, и наша команда не перестает работать над его улучшением. Обновляя периодически пакеты в documentation-репозитории, мы стараемся создать как можно более качественную и понятную документацию для русскоязычных новичков в GNU/Linux.
Каждый из вас может следить за процессом перевода. Для этого совсем не обязательно вникать в процесс работы команды переводчиков, “клонировать” git-хранилища или что-то в этом роде. Просто подключите documentation-репозиторий и установите/обновите интересующие вас пакеты:

> sudo zypper ar -f \
http://download.opensuse.org/repositories/Documentation/openSUSE_Factory Documentation

> zypper se 'opensuse*_ru*'
Loading repository data...
Reading installed packages...

S | Name                      | Summary                                          | Type      
--+---------------------------+--------------------------------------------------+-----------
  | opensuse-kvm_ru-pdf       | openSUSE manual: KVM Guide (PDF, Russian)        | package   
  | opensuse-manuals_ru       | Complete set of openSUSE Manuals (HTML, Russian) | package   
  | opensuse-manuals_ru       | Complete set of openSUSE Manuals (HTML, Russian) | srcpackage
  | opensuse-reference_ru-pdf | openSUSE manual: Reference (PDF, Russian)        | package   
  | opensuse-security_ru-pdf  | openSUSE manual: Security Guide (PDF, Russian)   | package   
  | opensuse-startup_ru-pdf   | openSUSE manual: Start-Up (PDF, Russian)         | package   
  | opensuse-tuning_ru-pdf    | openSUSE manual: Tuning Guide (PDF, Russian)     | package

> sudo zypper in opensuse-startup_ru-pdf
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  opensuse-startup_ru-pdf 

1 new package to install.
Overall download size: 9.4 MiB. After the operation, additional 10.0 MiB will be used.
Continue? [y/n/?] (y): 
Retrieving package opensuse-startup_ru-pdf-12.1.8762-27.7.noarch (1/1), 9.4 MiB (10.0 MiB unpacked)
Retrieving: opensuse-startup_ru-pdf-12.1.8762-27.7.noarch.rpm [done (1.6 MiB/s)]
Installing: opensuse-startup_ru-pdf-12.1.8762-27.7 [done]

> rpm -ql opensuse-startup_ru-pdf
/usr/share/doc/manual/opensuse-startup_ru-pdf
/usr/share/doc/manual/opensuse-startup_ru-pdf/book.opensuse.startup_ru.pdf
/usr/share/help/opensuse-startup_ru-pdf.document

> okular /usr/share/doc/manual/opensuse-startup_ru-pdf/book.opensuse.startup_ru.pdf &

Lords of the Realm II

Posted in fun, SuSE [ru] by anaumov on 04.05.2012

Вчера вечером, случайно найдя видео на youtube о Lords of the Realm II, мысленно погрузился в детство. Как же приятно окунуться в воспоминания о том прекрасном времени, навеяные той музыкой. Мне было тогда лет 10-11, и программы, за которыми я провел тогда столько времени, я люблю до сих пор.
Итак, что же такое Lords of the Realm II? Это пошаговая стратегия с тактическими битвами в реальном режиме, разработанная Impressions Games и изданная компанией Sierra Entertainment в конце 1996 года. Возможно вы слышали об играх серии Total War. Они были популярны где-то в 2005/06 году, т.е. почти через 10 лет после выхода Lords of the Realm II. Однако в них нет ничего нового. Ничего нового, кроме графики. Первый шаг в направлении этого жанра был сделан именно Sierr’ой, и сделан он был настолько успешно, что на года занял сердца и умы юных игровых стратегов 🙂 15 лет прошло с момента выхода этой замечательной игры, однако до сих пор геймеры обсуждают её на многих игровых форумах.

Я думаю, что этот пост не был бы столь интересен, если бы я не рассказл о том, как запустить Lords of the Realm II сегодня. Да не просто запустить, а в GNU/Linux, да что б без необходимости установки Windows.
Что ж… без проблем 😉
На “игровой” машине у меня openSUSE 12.1 с дефолтным (свободным/открытым) nvidia видео-драйвером. Никаких лишних телодвижений делать не надо. Просто устанавливаем wine:

> sudo zypper in wine

После этого ищем ISO образ самого диска. Я его нашел тут. Скачиваем, запускаем:

> wine LotR2RusSetup.exe

Запускается инсталлятор. У меня русифицированный ISO образ, поэтому в окне установщика вместо букв каракули. Это ничуть не затрудняет процесс устновки, т.к. ничего важного в процессе спрашивать не будут. Единственное, что я не сразу понял, это вопрос о расположении игры: С:/Programm_Files/Lords of the Realms 2? Сначала я переписал адрес на /home/alex/games, но этого делать не стоит. Надо просто кликать “далее” (или как там оно называется). Прокликав “далее”, и прождав пару минут, я установил игру. Все (где-то сотня файлов) копируется в ~/.wine/drive_c/Program Files/Lords of the Realms 2, в том числе и LORDS2.EXE. Теперь просто запускаем его в том же wine и… наслаждаемся игрой 🙂

> wine LORDS2.EXE

Разрешение экрана автоматически переключается на 256 цветов, и никаких проблем с запуском игры нет.

openSUSE :: Travel Support Program

Posted in SuSE [ru] by anaumov on 16.02.2012


Отличные новости для всех openSUSE-контрибьютеров. В рамках проекта запущена программа финансовой поддержки для всех, кто способствует развитию openSUSE. Речь идет о посещении конференций, так или иначе связанных с openSUSE и Free Software. Проект перенимает 80% расходов за поездку/полет + отель.
Как программа будет работать на практике покажет время, но лично я уже пользовался подобной плюшкой от KDE e.V., и должен сказать, что это помогает не только собрать сообщество вместе, но и очень мотивирует на дальнейшую поддержку проекта.

Детали могут быть изменены, но в общем программа поддержки работает следующим образом: за пару месяцев до начала конференции Вы отсылаете email, где рассказываете о своем вкладе в проект и желании посетить event. Неплохим вариантом будет подготовка презентации, так или иначе связанной с проектом openSUSE. В течении нескольких дней travel-cовет решает получите ли Вы поддерджку или нет, и если решение окажется положительным, то после предоставления чеков, соответсвующая сумма будет переведена на счет.

Have a lot of fun 🙂