ОМСКАЯ ГРУППА ПОЛЬЗОВАТЕЛЕЙ LINUX » build http://omsklug.com Свобода - это ответственность. Вот почему все её так боятся. Бернард Шоу Fri, 10 Nov 2017 17:30:02 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Нам нравится Profanity! http://omsklug.com/2016/03/we-like-profanity/ http://omsklug.com/2016/03/we-like-profanity/#comments Wed, 02 Mar 2016 19:20:35 +0000 Shroom http://omsklug.com/?p=1988 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local pre {overflow-x:auto;} .local code {font-family: Monospace,Courier!important;} .local code > span.kw { color: #268BD2; font-weight: bold; } .local code > span.dt { color: #268BD2; } .local code > span.dv { color: #D33682; } .local code > span.bn { color: #D33682; } .local code > span.fl { color: #D33682; } .local code > span.ch { color: #4070a0; } .local code > span.st { color: #2AA198; } .local code > span.co { color: #93A1A1; font-style: italic; } .local code > span.ot { color: #A57800; } .local code > span.al { color: #CB4B16; font-weight: bold; } .local code > span.fu { color: #268BD2; } .local code > span.er { color: #D30102; font-weight: bold; }
profanity project logo

Правда. :) Даже несмотря на наличие под катом ненормативной лексики. Так что, если вам нет 18 лет или если инвективная лексика является основной причиной ваших нравственных страданий, добро пожаловать в основной раздел нашего сайта. Если же вам интересны некоторые пикантные подробности наших счастлвых отношений с программкой из сабжа, тогда идёмте дальше…

По OmskLUG прокатилось поветрие сборки и/или установки консольного xmpp-клиента profanity. Может быть, это следствие его специфической суровой консольной кавайности, может быть, омсклуговцы просто устали от навороченного минимализма mcabber’а… А может быть, он на самом деле лучший из всех консольных джаббер-клиентов на сегодняшний день. И сегодня я не буду, как обычно это делал, скучно и долго рассказывать, как протанцевать по граблям сборки, установки и настройки очередного несговорчивого софта. Лучше я, как говорят в этих ваших интернетах, «просто оставлю это здесь»…

Собери Profanity!

(По щелчку на миниатюре загрузится оригинал)

“build profanity” banner in russian

И то же самое по-английски:

“build profanity” banner in english

На сегодня всё.


Спасибо за внимание!


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

]]>
http://omsklug.com/2016/03/we-like-profanity/feed/ 0
Как собрать chatbot’а для Tox http://omsklug.com/2015/01/how-to-build-toxbot/ http://omsklug.com/2015/01/how-to-build-toxbot/#comments Sat, 24 Jan 2015 22:00:22 +0000 Shroom http://omsklug.com/?p=1777 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local code {font-family: Monospace,Courier!important;}

В этой статье собраны некоторые подводные камни, обнаруженные лично автором при сборке чатбота для tox на Debian GNU/Linux 7 (Wheezy) для архитектуры amd64. Приведены способы обхода обнаруженных ошибок.

Подготовка

Для начала нам нужно установить некоторое количество пакетов с библиотеками и заголовочными файлами и вообще со средствами разработки (если таковых в системе ещё нет). Начнём с инструментария разработчика:

apt-get install build-essential libtool autotools-dev \
automake checkinstall check git yasm

Для удовлетворения сборочных зависимостей и для разных дополнительных плюшек типа аудио/видео, возможности запуска bootstrap-демона и хостинга ноды, ncurses-интерфейса поставим ещё несколько пакетов:

apt-get install libopus-dev libvpx-dev pkg-config \
libconfig-dev ncurses-dev

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

Итак, начнём, так сказать, с базовых вещей. Для шифрования нужна библиотека NaCl (старая и плохо портируемая, но быстрая) или sodium (новая, хорошо переносимая, с совместимым API, но несоколько медленнее). При этом существуют косяки как с первой, так и со второй библиотекой. Косяк с первой: нет объектников randombytes.o и cpucycles.o, которые требуются для сборки toxcore, но которые не являются частью NaCl [см. обсуждение подобной проблемы]. Косяк со второй — её тупо нет в репах для Wheezy (появилась только в Jessie), поэтому нужно сливать сырцы для Jessie и собирать (Естественно, для этого нужно добавить соответствующий репозиторий в /etc/apt/sources.list, настроить pinning, чтобы ненароком не обновить систему и т.п. Хотя можно, конечно, скачать нужный пакет прямо с сайта Debian). Соответственно, на старых системах (или если хочется «скорости»):

apt-get install libnacl-dev

А вообще NaCl лучше собирать из исходников, чтобы было откуда выцарапать randombytes.[c|o].

На новых системах (а также на Ubuntu, Mint, Arch, Gentoo и прочих, где всё новьё можно найти в стандартных репах/ppa/портах и пр.):

apt-get install libsodium-dev libsodium13

На старых же системах, где libsodium придётся брать в виде исходиков для Jessie, нужно дополнительно поставить pkg-config и dh-autoreconf, которые указаны в зависимостях для сборки. Впрочем, первый из них мыуже поставили в самом начале, поэтому остаётся только второй (Я лично ограничился сборкой с использованием NaCl, поэтому не могу сказать, какие глюки можно словить с sodium. Однако, смею предположить, что как минимум отсутствие randombytes.o породит похожие эффекты).

Сборка NaCl

Предположим, мы собрались использовать NaCl.

apt-get source nacl-tools

Из этого получатся пакеты для «-tools» и для «-dev». Здесь в зависимостях для сборки присутствует docbook-to-man, поэтому ставим и его тоже.

Сборка пакета: ничего страшного. Как обычно,

dpkg-buildpackage -b -us -uc

Но перед этим нужно в файлике debian/rules закомментировать строчку вида

rm -f $(CURDIR)/build/$(SHORTHOSTNAME)/lib/*.o

чтобы иметь возможность упаковать вместе с основной библиотекой и нужные нам объектники (ну или просто чтобы найти их после сборки). На самом деле по зрелом размышлении можно понять, что сборка пакета по сути не нужна. Можно ограничиться готовым пакетом из репы. Однако, при этом в любом случае нужно в верхнем каталоге дерева исходников libnacl выполнить магический скрипт ./do, который, собственно, и занимается сборкой либы. И уже после этого можно выдернуть и куда-нибудь сложить cpucycles.o и randombytes.o. Этот вариант будет даже более правильным с точки зрения поддержания чистоты пакетов.

Сборка ToxCore

Со стандартными либами покончено. можно сливать с гитхаба исподники toxcore:

git clone git://github.com/irungentoo/toxcore.git

После этого нужно перейти в каталог toxcore и фигачить далее по тексту руководства. Почти. Потому что, как обычно, появятся небольшие нюансы. Начнётся всё просто замечательно:

autoreconf -i

отработает без ошибок, поскольку здесь ломаться в принципе нечему. Зато следующий шаг

./configure --enable-nacl --enable-log --enable-ntox \
--enable-daemon --disable-testing

(в данном случае вся фишка в --enable-nacl; всё остальное — по желанию) закончится ошибкой. Нам скажут, что либа NaCl якобы не найдена, и предложат явно указать путь к ней. Хорошо, сделаем то, что просят, и даже больше, предполагая, что те самые cpucycles.o и randombytes.o лежат в одном из каталогов, известных линкеру (например, в /usr/lib рядом с libnacl.a):

./configure --enable-nacl --enable-log --enable-ntox \
--enable-daemon --disable-testing --with-nacl-libs=/usr/lib \
--with-nacl-headers=/usr/include/nacl

После того, как конфигуратор удовлетворится этой подсказкой, можно делать

make

Однако, сборка тоже не пройдёт с первого раза. Это, вероятно, связано как раз с ошибочным мнением разрабов toxcore о том, что randombytes.o принадлежит libnacl. Но это метафизика, а нам нужно что-нибудь уже собрать. Короче, процесс останавливается на линковке tox-bootstrapd с воплями о том, что в нескольких модулях найдены «undefined reference to ‘randombytes’». Хорошо, предоставим костыль в виде

make LIBS=''/usr/lib/randombytes.o''

после чего чудесным образом (Ну то есть сразу после ошибки запускаем «костыль» — и всё. Не нужно ничего нигде чистить, менять, копаться в файлах и др.пр.) дособерётся демон tox-bootstrapd (Естественно, если нет необходимости в этом функционале (а её в подавляющем большинстве случаев нет) и не был указан параметр --enable-daemon при вызове ./configure, то всё соберётся без проблем). После этого параноики могут проверить качество сборки, запустив

make check

(кстати, все тесты должны завершиться успешно), а все остальные могут сразу же приступить к сборке deb-пакета (ну или любого другого пакета на выбор) и его установке. Например, так:

sudo checkinstall -D make install

По умолчанию либы и бинарники будут установлены в /usr/local, поскольку мы не меняли эти пути в параметрах конфигуратора. Собственно, никто не мешает при вызове ./configure добавить параметр --prefix=/usr. Однако, это не является критичным для сборки бота.

Сборка ToxBot

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

Перед тем, как что-то собирать, это что-то нужно стянуть с гитхаба:

git clone git://github.com/JFreegman/ToxBot.git

Далее всё тривиально. Почти, опять же… Если взглянуть на руководство по установке, может возникнуть ложное чувство уверенности в своих силах и полного контроля над происходящим. В самом-то деле, что уж, так сложно единственную команду make запустить что ли?! Однако, в реальности всё не так, как на самом деле… Наверняка сборка загнётся опять же на этапе линковки, и линкер будет орать, что нашёл «undefined reference to `clock_gettime’» где-то в недрах toxcore. В принципе, он прав, потому что эта функция находится в библиотеке librt, а про неё линкеру никто ничего не рассказал. Поэтому придётся лезть в Makefile и менять строчку

LDFLAGS = $(shell pkg-config --libs $(LIBS))

на почти такую же, только с упоминанием нужной библиотеки:

LDFLAGS = -lrt $(shell pkg-config --libs $(LIBS))

После этого всё должно пройти без ошибок. Результат сборки — свежий бинарник toxbot, который не требует настройки и заводится с полпинка. Дальнейшие вопросы вроде «что делать, чтобы он признал хозяина?» и «как пробиться через заботливо закрытый файрвол?» автор статьи оставляет в качестве упражнения для читателя. Поверьте, это абсолютно несложно и даже описано в документации.


Спасибо за внимание!

Как обычно, полный текст этой статьи можно совершенно бесплатно, без регистрации, без смс свободно скачать отсюда в формате PDF.

]]>
http://omsklug.com/2015/01/how-to-build-toxbot/feed/ 0
Сборка unstable-версии Wine для stable-ветки Debian (TrueЪ Debian-way) http://omsklug.com/2013/01/build-wine-on-debian-stable/ http://omsklug.com/2013/01/build-wine-on-debian-stable/#comments Thu, 10 Jan 2013 11:36:24 +0000 Shroom http://omsklug.com/?p=1362

Аннотация

В статье описан способ получения набора пакетов последней версии Wine для stable-ветки Debian GNU/Linux. В качестве инструмента используется утилита dpkg-buildpackage. Также кратко описан вариант использования dh_make.

Где найти?

Первая мысль, которая приходит в ответ на вопрос, где взять свежий Wine, — посмотреть собственно на сайте WineHQ в разделе Wine downloads (http://www.winehq.org/download/). Однако, как можно обнаружить при детальном исследовании ссылок на этой странице, никаких бинарников там нет. На самом же деле всё, что нам нужно, хранится на сайте стороннего разработчика, который и публикует сборки для Debian sid/unstable, а также выкладывает исходники с патчами. То есть, если у вас стоит sid (или подключены репозитории от unstable и experimental для разрешения зависимостей), вы можете взять пакеты прямо отсюда: http://dev.carbon-project.org/debian/wine-unstable/. Если же вы предпочитаете стабильность, но при этом хотите использовать новейшие разработки создателей Wine, придётся качать исходники. Ссылки на них размещены на этой же странице в разделе Source package. Фактически для сборки понадобятся два архива: wine-unstable_1.5.5.orig.tar.bz2 (это собственно дерево исходников) и wine-unstable_1.5.5-0.1.debian.tar.bz2 (это параметры для системы сборки пакетов). А файл wine-unstable_1.5.5-0.1.dsc — это подписанное маинтейнером описание архивов с исходниками.

С чего начать?

  1. Распаковать архив wine-unstable_1.5.5.orig.tar.bz2. Получится каталог wine-1.5.5.
  2. Распаковать архив wine-unstable_1.5.5-0.1.debian.tar.bz2 внутрь каталога wine-1.5.5. Таким образом внутри wine-1.5.5 должен появиться каталог с именем debian.
  3. Проверить, есть ли в системе пакет dpkg-dev (dpkg-buildpackage находится именно в нём): выполнить dpkg -l dpkg-dev | grep ii — если в результате вернётся строка с кратким описанием пакета, значит он уже есть, если ничего не будет, значит его нет. Если такой пакет не установлен, это недоразумение нужно исправить, выполнив apt-get install dpkg-dev.
  4. Перейти в wine-1.5.5 и запустить dpkg-buildpackage -b -us -uc (значения ключей будут описаны в следующем разделе). Если после всевозможных проверок сразу же началась компиляция, значит по какой-то волшебной причине у вас уже были поставлены все пакеты, от которых зависит сборка Wine. Если же процесс ещё и завершился корректно с кучей пакетов на выходе, вас можно только поздравить. Однако, с большой степенью вероятности dpkg-buildpackage завершится через пару секунд, вывалив примерно такое сообщение:
    dpkg-checkbuilddeps: Неудовлетворённые сборочные зависимости:
    debhelper flex bison libx11-dev libxext-dev libxi-dev
    libxrandr-dev libxrender-dev libxt-dev libxkbfile-dev
    libxxf86dga-dev libxxf86vm-dev libxinerama-dev libxcomposite-dev
    libgl1-mesa-dev | libgl-dev libglu1-mesa-dev | libglu-dev
    freeglut3-dev | libglut-dev libxmu-dev libxcursor-dev
    libncurses5-dev libcups2-dev libjpeg-dev libpng-dev
    libfreetype6-dev libfontconfig1-dev libopenal-dev libasound2-dev
    oss4-dev libsane-dev libusb-dev libgsm1-dev libmpg123-dev
    libcapi20-dev libdbus-1-dev | dbus-1-dev libgphoto2-2-dev
    liblcms1-dev libldap2-dev libssl-dev libgnutls-dev libxml2-dev
    libxslt1-dev unixodbc-dev prelink dctrl-tools | grep-dctrl lzma
    sharutils libgstreamer-plugins-base0.10-dev gettext valgrind
    dpkg-buildpackage: предупреждение: Неудовлетворительные
    зависимости/конфликты при сборке, останов.

  5. Поставить все пакеты из списка неудовлетворённых зависимостей, полученного на предыдущем шаге. Обратите внимание на пары имён пакетов, разделённых символом «|» («конвейер»). Это альтернативы, то есть одно имя соответствует реальному пакету, который найдётся в репозитории, а второе имя — это или виртуальный пакет, или устаревшее название. И ставить нужно реальный пакет. Так что, прежде чем копировать кучей сразу все названия в командную строку после apt-get install, выясните, какие из названий, разделённых «|», реально присутствуют в репозитории (например, через apt-cache search <regexp> или dpkg -l <regexp>.

Как собрать?

Совершенно тривиально:
dpkg-buildpackage -b -us -uc

После тучи ошибок первого запуска dpkg-buildpackage наверняка предложил во второй раз запустить себя с ключом -d. Этот ключ означает «не определять зависимости». Если вы уверены, что ничего не упустили, можно, конечно, добавить и его… Но ведь заранее никогда не знаешь… Поэтому перезапускаем как есть, с теми же тремя ключами:

-b
Ключ, предписывающий собирать только бинарные пакеты, без упаковки исходников. Без этого ключа dpkg-buildpackage попытается создать src-deb и будет искать архив с исходниками (то есть wine-unstable_1.5.5.orig.tar.bz2) рядом с каталогом сборки (то есть с wine-1.5.5). Если всё будет на месте, дополнительно получим ещё один пакет, который, впрочем, никому особо не нужен. И чтобы не множить сущности, ставим этот ключ.
-us
Не пытаться подписать .dsc-файл.
-uc
Не пытаться подписать файл .changes.

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

Если всё прошло удачно, то в результате вы получите примерно такой список пакетов:

  • libwine-alsa-unstable_1.5.5-0.1_i386.deb
  • libwine-bin-unstable_1.5.5-0.1_i386.deb
  • libwine-capi-unstable_1.5.5-0.1_i386.deb
  • libwine-cms-unstable_1.5.5-0.1_i386.deb
  • libwine-dbg-unstable_1.5.5-0.1_i386.deb
  • libwine-dev-unstable_1.5.5-0.1_i386.deb
  • libwine-gl-unstable_1.5.5-0.1_i386.deb
  • libwine-gphoto2-unstable_1.5.5-0.1_i386.deb
  • libwine-ldap-unstable_1.5.5-0.1_i386.deb
  • libwine-openal-unstable_1.5.5-0.1_i386.deb
  • libwine-oss-unstable_1.5.5-0.1_i386.deb
  • libwine-print-unstable_1.5.5-0.1_i386.deb
  • libwine-sane-unstable_1.5.5-0.1_i386.deb
  • libwine-unstable_1.5.5-0.1_i386.deb
  • wine-bin-unstable_1.5.5-0.1_i386.deb
  • wine-unstable_1.5.5-0.1_i386.deb

Сразу замечу, что некоторые из пакетов можно не ставить:

libwine-cms-unstable_1.5.5-0.1_i386.deb
если вам не нужна система управления цветом (Color Management System) под вайном (то есть, если вы не собираетесь калибровать ваши монитор, принтер и сканер из-под Wine);
libwine-dbg-unstable_1.5.5-0.1_i386.deb
поскольку это отладочные символы для бинарников;
libwine-dev-unstable_1.5.5-0.1_i386.deb
потому что этот пакет нужен для разработки под Wine;
libwine-gphoto2-unstable_1.5.5-0.1_i386.deb
если вы не собираетесь смотреть фотки со своего цифрового фотоаппарата из виндовых приложений, запущенных под Wine’ом;
libwine-ldap-unstable_1.5.5-0.1_i386.deb
если вы не собираетесь авторизоваться через Wine в домене;
libwine-oss-unstable_1.5.5-0.1_i386.deb
поскольку технология OSS в Линуксе считается атавизмом (в отличие, например, от BSD-систем);
libwine-sane-unstable_1.5.5-0.1_i386.deb
если вы не собираетесь давать виндовым приложениям доступ к вашему сканеру.

Если же вожделенных пакетов вы так и не обнаружили… Что ж, переходите к чтению следующего раздела.

Что делать, если что-то пошло не так?

Во-первых, ещё раз проверить зависимости. Если какой-то пакет не ставится — скорее всего, вы пытаетесь поставить альтернативный вариант, который стоит рядом с «|». В этом случае нужно ставить тот пакет, который записан с другой стороны от значка конвейера.

Во-вторых, проверить, не поломалась ли структура «дебианизации» дерева исходников — содержимое каталога debian. Если есть сомнения, его нужно прибить и распаковать заново из скачанного архива. В данном случае из-за отсутствия некоторых специфических настроек в debian/rules после сборки могут запуститься тесты, которые на подавляющем большинстве систем будут давать сбои (как заявляют сами разработчики Wine’а в одном из списков рассылки). А потеряться эти настройки могут, если по ошибке каталог debian будет перезаписан или удалён и создан заново по шаблону с помощью команды dh_make.

В-третьих, прочитать man по dpkg-buildpackage и понять, какие параметры реально нужны в данной ситуации. Например, если его запускать без ключа -b, дополнительно будет собран src-пакет. Вернее, он будет собран, если рядом с каталогом wine-1.5.5 будет обнаружен архив wine-unstable_1.5.5.orig.tar.bz2. В противном случае вам предъявят следующее:

…
dpkg-source: ошибка: невозможно собрать с форматом
исходника «3.0 (quilt)»: файл orig.tar не найден
dpkg-buildpackage: ошибка:
dpkg-source -b wine-1.5.5 возвратил код ошибки 255
…

И если после этого захотеть исправить ситуацию с помощью dh_make, как об этом пишут на некоторых форумах, мы получим сброшенные настройки правил сборки пакетов и вернёмся к пункту «во-вторых».

И последнее. Все операции, кроме установки пакетов, осуществляются с правами обычного пользователя. Если в процессе сборки от вас потребовали права администратора, скорее всего, у вас не установлен пакет fakeroot (или подобный).

Примечание: если вы чувствуете растерянность от обилия в тексте непонятных команд и утомлены описаниями вещей, которые кажутся вам бессмысленными, настоятельно рекомендую сделать паузу в чтении, отдохнуть и прочитать документацию ко всем упомянутым командам в формате man или info.

Что же такое dh_make?

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

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

Самое первое — конечно же, распаковать архив с исходниками. Название директории после распаковки может быть, вообще говоря, любым, но для использования с dh_make нужно привести его к виду <названиепакета>-<версия>, причём <названиепакета> обязано содержать только маленькие буквы латинского алфавита, возможно, с цифрами и знаками «-» (обычный минус).

Следующим шагом будет собственно зайти в переименованную директорию и запустить там dh_make. И тут, как обычно, начинаются разные «но» и «если». Если не указан ключ --native, dh_make будет искать рядом с каталогом исходников архив вида <названиепакета>-<версия>.orig.tar.gz (впрочем, он может быть не только .gz, но также и .bz2, и .lzma). Если там такого файла нет, но указан ключ -f <имяфайла>, то dh_make скопирует <имяфайла> и использует его в качестве оригинального архива. Если же ключ -f не указан, но есть ключ --createorig, то dh_make создаст архив из текущего дерева исходников. Архив, кстати, нужен будет другим утилитам для генерации различий между оригинальными файлами и обновлёнными версиями (соответственно, для подготовки патчсета) и для построения дебиановской структуры src-пакета.

После того, как разобрались с архивом, нужно будет ответить на дополнительный вопрос: что мы хотим получить в результате — единственный пакет (single binary), архитектурно-независимые файлы (arch-independent), несколько пакетов (multiple binary), библиотеку (library), модуль ядра (kernel module) или же патч для ядра (kernel patch). От сделанного выбора будут зависеть параметры, которые dh_make запишет в структуру внутри каталога debian.

В сущности, это всё. После того, как dh_make отработал (будем надеяться, без ошибок), можно переходить к процедуре сборки пакета с помощью dpkg-buildpackage.

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

Благодарности

Автор выражает признательность члену OmskLUG с ником Lumpy за осуществление на практике и тестирование всего процесса, описанного в этом руководстве.

Спасибо за внимание!

Эту статью можно скачать в формате PDF отсюда совершенно свободно.

]]> http://omsklug.com/2013/01/build-wine-on-debian-stable/feed/ 0 Как собрать пакет WHDD http://omsklug.com/2012/12/whdd-assemble-and-install/ http://omsklug.com/2012/12/whdd-assemble-and-install/#comments Sat, 15 Dec 2012 07:04:12 +0000 Shroom http://omsklug.com/?p=1344 Аннотация

В статье рассказывается, как быстро собрать пакет WHDD для Debian-based дистрибутивов GNU/Linux.

1 Что такое WHDD?

  Собственно, эту информацию можно найти в README. Буквально там говорится следующее. «WHDD — это утилита для диагностики и восстановления блочных устройств (практически аналог MHDD для Linux)». Функционал пока весьма скромен, однако вполне полезен. WHDD умеет распознавать подключенные блочные устройства, может выдать информацию о параметрах S.M.A.R.T., а также может протестировать диск в двух режимах: «только чтение» (данные остаются на месте) и «запись нулей» (соответственно, все данные при этом будут потеряны). Естественно, эта утилита умеет и отображать результаты тестирования, при этом интерфейс практически один к одному повторяет таковой у MHDD.

2 Где найти?

  На момент написания этого Mini-HowTo (декабрь 2012 года) ни в одном дистрибутиве, кроме Gentoo, пакета WHDD не было. Если верить статье WHDD как аналог MHDD под GNU/Linux (http://syslinux.ru/node/1364), в Gentoo «whdd с марта 2012 года находится в основном дереве портежей, и максимум, что нужно сделать — это размаскировать этот пакет». Поэтому для Debian придётся скачать исходники из репозитория на github (https://github.com/krieger-od/whdd/ или сразу получить архив с последней версией исходников отсюда: https://github.com/krieger-od/whdd/archive/master.zip) и собрать программу на своей машине. Ничего страшного и сложного в этом нет; сейчас объясню, как это сделать.

3 Что понадобится?

  1. Естественно, прежде всего для сборки нужны исходники. Предполагаем, что они уже скачаны. Затем их нужно куда-то распаковать. Пусть, например, это будет каталог zoo в домашнем каталоге пользователя. Поскольку исходники находятся в zip-архиве, распаковать их в zoo, я надеюсь, не составит никакого труда (иначе вся информация, изложенная здесь, будет для вас абсолютно бесполезной).
  2. Библиотеки для работы программы:
    1. libmenuw.so и libncursesw.so находятся в пакете libncursesw5 («w» — это wide-character, то есть поддержка многобайтных символов);
    2. libtinfo.so находится в пакете libtinfo5;
    3. libc.so, libm.so, libdl.so, librt.so, libpthread.so являются частью пакета libс6, который ставится при установке, поскольку без него система просто не сможет работать. Поэтому о них можно не беспокоиться.
  3. Пакеты для сборки:
    1. libncursesw5-dev;
    2. libtinfo-dev;
    3. dialog;
    4. libncurses5-dev (обратите внимание — это пакет заголовков для libncurses без поддержки многобайтных символов, без него не находится unctrl.h, на который ссылается dialog.h);
    5. libc6-dev (если вы до этого момента никогда и ничего не собирали на своей машине, вам нужно его поставить; если же собирали, скорее всего, он у вас уже есть).
  4. Инструменты для сборки:
    gcc
    Компилятор C от GNU, если кто не в курсах. По умолчанию обычно не ставится, поэтому, если вы не разработчик, скорее всего, придётся поставить и его.
    make
    Система для автоматического разрешения зависимостей и оптимизации процесса сборки. Полезна не только для программистов, поскольку изначально предназначена для описания процесса создания неких конечных файлов из некоторого количества исходных. Основная особенность — процессы обработки запускаются только для тех файлов, которые были изменены после последней сборки.
    cmake
    Кросс-платформенный генератор make-файлов. При установке пакета тянет за собой emacsen-common (опосредованно, через зависимость от cmake-data), так что не пугайтесь.
    checkinstall
    Весьма полезная утилита, которая позволяет отслеживать файлы и каталоги, которые получаются в процессе сборки и установки софта из исходников (с помощью make && make install), и делать из них полноценный .deb-пакет. Собственно для процесса сборки не нужна, поэтому её можно не ставить. Однако я настоятельно рекомендую использовать именно её вместо традиционного make install, поскольку установленный пакет вычистить из системы значительно проще, нежели рыскать по дереву каталогов в поисках хвостов установленной когда-то программы, особенно если исходников уже давно нет и make uninstall сделать просто невозможно.

Если вы время от времени намерены собирать что-нибудь из исходников, вероятно, имеет смысл поставить пакет build-essential, в зависимостях которого указаны и libc6-dev, и gcc, и make.

 Итак, резюмируя вышесказанное одной командой,
# apt-get install build-essential libncursesw5-dev \
libtinfo-dev libncurses5-dev dialog libc6-dev cmake \
checkinstall libncursesw5 libtinfo5

  Обратите внимание на символ «\» (бэкслэш) на концах строк: здесь он приведён, чтобы показать, что вторая и третья строка являются продолжением первой. Никакой другой цели, кроме эстетической (избежать слишком длинной строки), в его использовании не было. В настоящем терминале можно обойтись и без него (записать команду со всеми параметрами просто в одну строчку), хотя там он выполняет ту же функцию — говорит оболочке о том, что строка не закончилась и будет продолжена дальше.

4 Как собрать?

  Для сборки проекта необходимо перейти в каталог с исходными текстами и выполнить всего две команды:
$ cmake . && make

  Обратите внимание на то, что эти две команды записаны в одной строке, причём оператор && гарантирует выполнение второй команды только после успешного завершения первой. Точка после cmake важна, так как задаёт рабочий каталог, в котором находятся параметры для cmake и в котором будет сгенерирован make-файл. Также можно запустить сборочный скрипт, который находится в этом же каталоге с исходниками:
$ ./build.sh
Но по сути этот скрипт запускает те же две команды сборки и предлагает выполнить make install для установки.

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

5 Как установить?

  Если вы выбрали путь наименьшего сопротивления и согласились выполнить make install (из-под административного аккаунта, то есть, от имени root‘а), можете пропустить этот раздел и сразу запустить whdd:
# whdd-cli
или
# whdd-curses

  Если же вы являетесь адептом строгого и рационального Debian-way, то сначала вы соберёте .deb-пакет, а затем установите его, и ваша система останется прозрачной, логичной и управляемой.

  Итак, checkinstall… Как вы, вероятно, заметили, сборка программы идёт с правами обычного пользователя, поскольку процесс происходит в пользовательском каталоге. То же самое касается и сборки пакета. Установка же предполагает запись в системные директории, что потребует наличия прав администратора. Сам по себе checkinstall, запущенный без параметров, соберёт пакет и попытается его установить. Таким образом, если вы хотите собрать пакет и сразу же установить его (автоматически), вы можете сделать это, выполнив
# checkinstall
с правами администратора. Если же вы хотите только собрать пакет без непосредственной установки, вы можете задать параметр --install=no, выполнив
$ checkinstall --install=no
с правами обычного пользователя.

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

Этот пакет был создан с использованием данных значений:
0 -  Maintainer: [ root@localhost ]
1 -  Summary: [  ]
2 -  Name:    [ krieger-od-whdd-c8a8691 ]
3 -  Version: [ c8a8691 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ checkinstall ]
7 -  Architecture: [ amd64 ]
8 -  Source location: [ krieger-od-whdd-c8a8691 ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [  ]
12 - Conflicts: [  ]
13 - Replaces: [  ]

Введите номер для изменения параметра или нажмите ВВОД для продолжения:

  Опять же, если вы не собираетесь распространять этот пакет, можете только изменить на что-то вменяемое имя пакета (2 - Name), версию (3 - Version) и предоставляемые пакеты (11 - Provides). Впрочем, последнее необязательно. Имя должно отражать реальное название софта, версия должна быть адекватной для того, чтобы можно было легко апгрейдиться после выхода новых и/или официальных версий (для whdd последняя версия на момент написания этого текста была 1.1), поле предоставляемых пакетов сообщает пакетному менеджеру информацию для разрешения зависимостей.

  Если хочется всё сделать правильно, тогда очень желательно дополнительно изменить поля «Ответственный за поддержку» (0 - Maintainer, обычно пишется имя, а затем адрес электронной почты в угловых скобках), «Краткое описание» (1 - Summary, сюда можно вставить первое предложение из README), «Раздел» (6 - Group, ветка дерева пакетов, в которую попадёт этот пакет; для whdd можно выставить util или admin), «Зависимости» (10 - Requires, здесь указываются пакеты, без наличия которых в системе приложение не запустится, и их версии). Вот что получилось в результате у меня (версии библиотек указаны для Debian 7 Wheezy/testing):

Этот пакет был создан с использованием данных значений:
0 -  Maintainer: [ Philaret Nikonov <phil@hyperion.cc> ]
1 -  Summary: [ WHDD is a diagnostic and recovery tool for
     block devices (near to replace MHDD for Linux). ]
2 -  Name:    [ whdd ]
3 -  Version: [ 1.1-git20121213-c8a8691 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ util ]
7 -  Architecture: [ amd64 ]
8 -  Source location: [ krieger-od-whdd-c8a8691 ]
9 -  Alternate source location: [  ]
10 - Requires: [ libc6 (= 2.13-37), libncursesw5 (=5.7), libtinfo5 (=5.7) ]
11 - Provides: [ whdd ]
12 - Conflicts: [  ]
13 - Replaces: [  ]

Введите номер для изменения параметра или нажмите ВВОД для продолжения:

Installing with make install...

  В сущности, это всё. После нажатия <Enter> checkinstall соберёт пакет и (если ему этого не запретили явно) попытается его установить. После того, как пакет был успешно установлен, дерево исходников можно с лёгким сердцем удалять до следующего релиза.

6 Кого спросить?

  Итак, с вопросом «что делать?» мы (надеюсь) разобрались, остался вопрос «кто виноват?» То есть, «кому задавать вопросы, если всё пошло не так?»

  Во-первых, конечно же, авторам программы WHDD. Их координаты можно найти в файле README, который лежит в каталоге doc дерева исходных текстов, или в указанном выше репозитории на github.

  Во-вторых, автору этого текста. Его можно найти в джаббер-конференции омских линуксоидов (omsklug@conference.jabber.ru) под ником Shroom.

  Ну и, наконец, всем участникам вашего местного (или ближайшего к вам) LUG’а и вообще любым первым встречным линуксоидам.

  Спасибо за внимание!

Эту статью можно скачать в формате PDFотсюда совершенно свободно.

]]>
http://omsklug.com/2012/12/whdd-assemble-and-install/feed/ 2