⌨ Labor omnia vincit ☮

GNU Screen v.4.5.0

Posted in GNU/Linux, openSUSE by anaumov on 18.01.2017

I’m proud to announce the release of GNU Screen v.4.5. This time it’s mostly a bugfix release. We added just one new feature: now it’s possible to specify logfile name by using parameter -L (default name stays screenlog.0). Myself also spent some time to make source code a bit cleaner.

As you probably noticed we were going to release 4.5 until Christmas. Unfortunately, we could not do it because of some internal GNU problems. I apologise for that.

As usual, we merged some community patches from our bug tracing system (small patches also were presented in IRC) and I would like to thank everyone who contribute to Screen and helps us to test development git-version!

For openSUSE users: I updated our devel-package already. It’s soon in factory and, as usual, after openQA routine new package will be available in Tumbleweed.

Advertisements

Debian Packaging System: Tools and Fundamental Principles

Posted in GNU/Linux by anaumov on 07.12.2013

deb-package16 августа проект Debian отметил свое 20-летие. Я являюсь большим поклонником этого проекта, и моим скромным подарком для всех русскоязычных пользователей к юбилею стал перевод пятой главы “Настольной книгаи администратора Debian”. Глава повествует о пакетной Debian-системе, инструментах и основных принципах их работы. На данный момент материал актуализирован для Wheezy.

Для меня лично этот проект (перевода) был интересен, потому что я какое-то время работал мейнтейнером в небольшой компании в Гёттингене. В мои обязанности входило создание и поддержка debian-пакетов для ПО, разрабатываемого в стенах компании, включая процесс обновления для всего дистрибутива + поддержка нескольких репозиториев. После переезда в Мюнхен в феврале этого года я больше этим не занимаюсь. Тем не менее, как видете, эта тема мне по-прежднему интересна 😉

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

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 :: eGalaxTouch X.Org input driver in Open Build Service

Posted in GNU/Linux, openSUSE by anaumov on 17.03.2012

Let’s start by saying that the eGalaxTouch is a X.Org input driver developed by EETI for their touch screens.
Here you can download the suitable driver for your Linux Kernel and architecture. After untar it you will get a directory named eGalaxTouch32 or eGalaxTouch64. Inside this directory you can find a setup.sh script. This complicated script will handle the entire instalaton proccess. It works fine, but the script blasted files and symbolic links all over the filesystem, and there is no way to clean it. As a packager I want to use more professional mechanism to install or remove it. So I built a RPM/DEB packages for that.

How it works?

There are just 4 things that you needed to care about: egalax_drv.so, the binary driver used by the X.Org server; eGalaxTouch, the utility for calibrating and setting preferences; TKCal, a lower level utility for setting options in the hardware; and script also add some information about new configuration to X.Org config-file (I changed it: package create the new config file called /etc/X11/xorg.conf.d/50-egalax.conf).

Section "InputDevice"
        Identifier "EETI"
        Driver "egalax"
        Option "Device" "/dev/ttyS1"
        Option "Parameters" "/var/lib/eeti.param"
        Option "ScreenNo" "0"
EndSection

As you can see I use /dev/ttyS1. EGalaxTouch support S232, USB, PS2, and I2C controllers. So, if you use, for example, USB, you have to change device-string like this:

        Option "Device" "usbauto"

X -version

Here is also one important thing what you have to know: X.Org server and input drivers/modules should have same versions (support same API). EGalaxTouch driver contain modules for different X.Org versions. That means, that package have to check X.Org version during installation to know which input module should be used. I tested package on openSUSE 11.4/12.1 and Ubuntu 10.04 and it looks stable. Anyway, let me know if it will not works for you.

Don’t forget after installing the package and restarting X.Org Server also run eGalaxTouch and TKCal. This will let you calibrate the touchscreen. It takes a bit time to complete, but it increases the precision of the touch position.

Good luck and happy touching 🙂

SIGTERM != SIGKILL

Posted in GNU/Linux by anaumov on 09.06.2011

Мы все знаем, что произойдет в UNIX/Linux системе, если мы сделаем

> kill 4055

Процессу с pid 4055 будет отправлен сигнал о его завершении. Какой именно сигнал и почему нам приходится иногда использовать ключ -9, когда мы хотим сделать тоже самое?

> kill -9 4055

В чем разница? Это очень интересный момент, давайте рассмотрим его поподробнее. Программа kill по умолчанию шлет сигнал SIGTERM. Именно этот сигнал предназначен для завершения процесса, и в штатной ситуации процесс, получивший этот сигнал, завершается (см. man kill). Что именно должен сделать процесс описанно в файле signal.h стандартной библиотеки С.
Читать полностью…

Learn the UNIX/Linux command line

Posted in books, GNU/Linux by anaumov on 05.04.2011

Знание команд и свободное владение интерпретатором shell всегда говорят о квалификации пользователя. Новички в GNU/Linux неправильно понимают назначение интерпретатора, и относятся к нему как к вынужденной мере, к которой приходится прибегать из-за отсутствия “нормальных” альтернатив. Более квалификацированные пользователи знают, что работа в консоли является самым быстрым и удобным средством для решения целого ряда задач. Не столь требовательный к ресурсам, более стабильный и быстрый… работу в shell хакеры уже давно возвели в ранг культуры и искусства, понятной лишь для своих.
Читать полностью…

AppStream meeting summary

Posted in GNU/Linux by anaumov on 24.01.2011

На одном из обсуждений, которые мы провели на openSUSE Conference, была затронута тема о состоянии ПО для openSUSE. Главными проблемами, названными тогда, были 1) Отсутствие многих пользовательских программм, которые однако есть для других платформ и 2) Сложность установки ПО в openSUSE. Возможно кто-то возразит, что ничего сложного в установке через тот же zypper нет, а даже если есть, то всегда доступен YaST, в котором уж точно никаких проблем быть не должно… даже у новичка в мире GNU/Linux. Так-то оно так, но сообщество хочет иметь не просто дружелюбный к новичку в GNU/Linux дистрибутив, но к новичку в компьютерах вообще. Другими словами, обсуждение свелось к недоработке openSUSE в этом вопросе, поиску решений и выходов из этой ситуации…
Читать полностью…

alien: converting DEB => RPM

Posted in GNU/Linux by anaumov on 12.11.2010

Вчера я хотел установить себе XMind, но на странице проекта не нашел rpm для своей openSUSE. Проект отдает предпочтение лишь Ubuntu/Debian-пользователям GNU/Linux. В репах zypper se XMind тоже ничего не нашел.

Программа alien представляет из себя конвертор форматов различных пакетных систем, используемых в UNIX/Linux. Удобно, если не хочется возиться со сборкой из исходников. Она есть у нас в репах.
Читать полностью…

FOSS and openness

Posted in GNU/Linux by anaumov on 01.11.2010

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

Открыть исходники своего проекта (если речь идет о программном обеспечении) еще не значит, что проект станет успешным. Преимущества Open Source получит тот проект, вокруг которого будет собранно активное и дружное сообщество (это уже касается абсолютно любого проекта, развивающегося по модели Open Source). Проект расцветает именно благодаря совместной работе, построенной как правило на энтузизме, любви к проекту и хакингу (если software-проект).
Читать полностью…

Why do you use GNU/Linux?

Posted in GNU/Linux by anaumov on 23.09.2010

Достаточно часто можно увидеть темы на форуме или в багзилле, как новички GNU/Linux оскорбляют его разработчиков. Не понимают, как работает та или иная его часть, не могут с этим разобраться, и в итоге виноватыми оказываются программисты. В этом они чем-то напоминают Script kiddie, которые так же умееют/желают лишь использовать готовые продукты. Как это работает их не интересует.
Читать полностью…

OpenSSH: using keys for access

Posted in GNU/Linux, OpenSSH by anaumov on 04.08.2010

Понадобилось настроить вход через OpenSSH на удаленную машину, без постоянного ввода пароля. Погуглил, и нашел немало мануалов (в основном в блогах), о том как это можно сделать. К сожаленью, почти все они оказались как две капли воды похожи, а последовательность преведенных там команд предоставляла достаточно скудные возможности или вообще нерабочие соединение. К тому же мне понадобилось создавать запросы через web-интерфейс, а не через консоль, т.е. мне не просто надо было логиниться без пароля, но и при помощи одного запроса получать вывод той или иной команды с удаленной машины.
Читать полностью…

Open Source в уни

Posted in GNU/Linux by anaumov on 11.01.2010

Хорошая новость для всех сторонников свободного программиного обеспечения приходит из северной Баварии. Со следующего зимнего семестра профессор Dr. Dirk Riehle в университете Friedrich-Alexander-Universität (Нюрнберг) включит в свой курс лекции по изучению Open_Source. Основная задача на ближайшие 3 года будет заключаться в изучении философии open souce, а так же исследовании концепций разработки ПО с открытым исходным кодом в компаниях, занимающихся разработкой ПО. Будет так же специально создана платформа, схожая с Sourceforge, для разработки ПО для студетов. Компании Novell и Red Hat выступают в данной инициативе как спонсоры. Так же они будут финансировать докторские проекты на кафедре. Ежегодно эта инициатива будет принесить более тысячи высококвалифицированных программистов в мир open source.