ОМСКАЯ ГРУППА ПОЛЬЗОВАТЕЛЕЙ LINUX » Debian http://omsklug.com Свобода - это ответственность. Вот почему все её так боятся. Бернард Шоу Fri, 10 Nov 2017 17:30:02 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Косяки с установкой redmine_git_hosting в Debian 8 Jessie http://omsklug.com/2015/09/smashing-redmine-git-hosting-in-deian-jessie/ http://omsklug.com/2015/09/smashing-redmine-git-hosting-in-deian-jessie/#comments Tue, 29 Sep 2015 18:19:26 +0000 Shroom http://omsklug.com/?p=1954 .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; }
Icon for application-x-ruby MIME type

До меня время от времени доходили слухи, что установка и сопровождение Redmine — это не то, чтобы адЪ, но как минимум геморрой неслабые головняки. Вероятно, я подогнался под эту тему и в первый раз установка заняла у меня дня три. Во второй раз я уложился в пару дней. В последнее время я делаю успехи, поскольку установка плагина redmine_git_hosting прошла не более, чем за сутки. И это не может не радовать. Последовательность шагов по установке очень подробно описана в руководстве от разрабов, которое можно найти здесь: Get started. Собственно, именно такого порядка действий я и буду придерживаться в статье. Вследствие этого изложенный здесь материал может показаться фрагментарным и несколько несвязным. И если вам так и кажется, вы, пожалуй, правы…

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

Начало: клонирование и сборка

На всякий пожарный инструкция предупреждает нас о необходимости сбэкапить базу и остановить Redmine. Благоразумно воспользуемся этим советом и приступим…

Как ни странно, в самом начале процесс идёт на удивление гладко. Шаги по установке зависимостей и клонированию реп проходят без проблем. :)

Однако, как только дело доходит до bundle install, он тут же начинает орать. Во-первых, выдаёт предупреждение о дубликате зависимости «gem 'redcarpet', '~> 3.1.2'». Это не страшно, убирается комментированием соответствующей строчки в Gemfile внутри каталога плагина. Во-вторых, ошибка, связанная с несоответствием версий rake. Дескать, установлена 1.5.2, а плагин через зависимость от gitlab-grack требует аж 1.6.0. Это вызвано тем, что в репе jbox-web не указана версия rake; соотвественно, bundler вытягивает и собирает самую последнюю. Собственно, сам автор плагина предлагает бороться с этим косяком, используя гитлабовский форк. В результате получаем такой кусок Gemfile:

## Redmine 3.x
## Ruby/Rack Git Smart-HTTP Server Handler (use our own repository because Redmine uses Rails 4.2 and Rack 1.6)
#gem 'gitlab-grack', git: 'https://github.com/jbox-web/grack.git', require: 'grack', branch: 'fix_rails4'
#gem 'redcarpet', '~> 3.1.2'

# fix for Debian Jessie with rails 4.1
# (https://github.com/jbox-web/redmine_git_hosting/issues/497#issuecomment-133768646)
gem 'gitlab-grack', git: 'https://github.com/gitlabhq/grack.git', require: 'grack', branch: 'master'

После этих манипуляций все гемы собираются, как надо.

Следующй шаг — migrate

Здесь сразу же вылетает ошибка «The git source https: github.com/jbox-web/gitolite-rugged.git is not yet checked out. Please run bundle install before trying to start your application». Естественно, bundle install не помогает. Решение: закомментировать ссылки на git и поставить просто зависимость, как от обычных гемов. В результате получим что-то подобное:

# Gitolite Admin repository management
#gem 'gitolite-rugged', git: 'https://github.com/jbox-web/gitolite-rugged.git', tag: '1.1.1'
gem 'gitolite-rugged'

#gem 'gitlab-grack', git: 'https://github.com/gitlabhq/grack.git', require: 'grack', branch: 'master'
gem 'gitlab-grack', require: 'grack'

Кстати, в Интернете можно найти довольно много вопросов, связанных именно с таким глюком, когда какой-нибудь гем ставится из гита. ИЧСХ, внятных ответов, как бороться с этой напастью, никто не даёт. В основном какие-то шаманские рецепты типа придуманного мной. Это намекает на пару возможных причин: или эта ситуация настолько тривиальна, что отвечать просто нет смысла, или же действительно никто не знает, что там на самом деле происходит в недрах RoR вообще и Redmine в частности.

Ну так вот. После этого нужно ещё раз запустить bundle install, после чего migrate будет ругаться на другие вещи. Или, если redmine изначально был поставлен по-человечески, всё пройдёт гладко. В моём случае пользователю БД не хватало прав на создание и удаление таблиц. Выполнение в mysql

grant all privileges on `redmine_db`.* to 'redmine_user'@'localhost';
flush privileges;

решило проблему радикально.

Установка и настройка Gitolite

Пользователи и ключи

Поскольку Gitolite работает от одного пользователя через ssh, нам нужно сгенерировать некоторое количество ключей. Этот процесс вызвал единственный вопрос относительно места их хранения. В инструкции для создания пары административных ключей для плагина рекомендовано создать каталог ssh_keys в REDMINE_ROOT. Однако, если внимательно посмотреть на init.rb, становится понятно, что в дереве плагина уже есть ssh_keys, и создан он там отнюдь не случайно. Плагин в первую очередь именно там и ищет ключи. Впрочем, когда всё заработает, каталог с ключами можно переопределить в настройках.

Во время установки Gitolite нужно будет указать пользователя, из-под которого он будет работать (и в которого будут логиниться все имеющие доступ к репозиториям). Для общности пусть это будет юзер git. В качестве административного ключа нужно указывать открытый ключ того человека, который будет админом (ну или сразу ключ, сгенерированный для redmine). Дополнительные ключи (для redmine, в частности) кладутся в GITOLITE_HOME/.gitolite/conf/gitolite.conf. После этого нужно сделать gitolite compile от пользователя git. Но на самом деле ничего такого делать не нужно. Gitolite управляется через git-репу. Поэтому после установки с добавлением одного административного ключа можно и даже нужно просто склонировать репозиторий gitolite-admin тому пользователю, которого сделали git-админом. После этого можно настраивать конфиги как угодно, не забывая заливать коммиты обратно. Как и что делать, подробно разжёвано в соответствующем руководстве.

Дополнительно (для версии Gitolite 3) «патчится» пара скриптов, но это описывать не имеет смысла, поскольку процесс тривиален.

Если что-то пошло не так…

Но вот если забыть, как работает ssh, возникнут некоторые сложности с доступом по ключам. Во-первых, домашний каталог Gitolite должен принадлежать руту или тому юзеру, из-под которого работает Gitolite (и мы в самом начале решили, что это git). Следствие: если с репозиториями работает ещё кто-то (например, gitdaemon), этого кого-то нужно добавить в группу git. С другой стороны, что касается gitdaemon‘а, то его-то как раз можно запустить от имени любого нужного пользователя. Во-вторых, нужно выставить адекватные права на .ssh и то, что в нём. В-третьих, Gitolite различает git-юзеров по их ключам, поддерживая соответствующую структуру файла authorized_keys: перед ключом должна идти строчка

command="/usr/share/gitolite3/gitolite-shell <git_user_name>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

Если выполнены все эти условия, с доступом проблем не будет. В крайнем случае поможет анализ /var/log/auth.log. Вообще на сайте Gitolite есть специальная страница, где собраны все возможные косяки с ssh и способы их устранения. Опять же, если не лазить в конфиги руками, а делать всё через git, как расписано в документации, всё должно работать адекватно.

Что же там всё-таки с именами?

Кстати, есть ещё один нюанс, связанный с тем, как Gitolite определяет имена пользователей. Всё очень просто: как обзовёшь открытый ключ, так тебя и будут звать дальше. Опять же, всё не настолько фатально, если вспомнить, что вся конфигурация хранится в git-репозитории. Однако же, вот такая штука. Руководство по установке плагина предлагает назвать сгенерированный ключ каким-то нечеловечески длинным именем с суффиксом rsa_id. И это означает, что административный пользователь redmine будет назван этим самым непроизносимым именем. В сущности, и redmine, и плагину, и Gitolite — всем пофиг, формально всё будет работать. Однако, мне лично удобнее, когда подконтрольные мне сущности называются просто и понятно. Поэтому я переобозвал ключи в redmine-admin и redmine-admin.pub. И теперь в конфиге всё прозрачно и тихо.

Запуск Redmine и настройка плагина через веб-морду

Наконец-то, наконец-то! Если вы дошли до этого торжественного момента с минимальными потерями, вас можно поздравить. Остальных, наверное, тоже можно. Просто им уже не до поздравлений.

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

Реальные баги

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

Вывод ReadMe

Итак, первый косяк в коде, с которым я столкнулся в процессе эксплуатации плагина, находится в файле REDMINE_HOME/plugins/redmine_git_hosting/lib/redmine_git_hosting/hooks/display_repository_readme.rb. Не буду рассказывать, как я его отлавливал и локализовал в конце концов, поскольку дебаггинг — это тема для отдельной статьи. Лучше сразу покажу, что нужно менять:

diff old/display_repository_readme.rb new/display_repository_readme.rb
58c58
<           raw_readme_text = repository.cat(readme_file.path, rev)
---
>           raw_readme_text = Redmine::CodesetUtil.to_utf8_by_setting(repository.cat(readme_file.path, rev))

А теперь поясню, ради чего, собственно, менять. Этот модуль должен выводить ReadMe под списком файлов и логом коммитов. Практически как на гитхабе. Однако же, без принудительного перевода прочитанного буфера в UTF-8 этот модуль падает на символах с кодами, выходящими за пределы таблицы ASCII. А внешне это выражается в том, что если в репе есть ReadMe с какими-то нестандартными символами (типа диакритики или расширенной пунктуации), то вместо репы мы увидим шиш с маслом Server Error 500. Это некрасиво да и вообще как-то неправильно. Поэтому вот такой нехитрый патч. Сделал pull request с этим «патчем»; будем ждать, когда окажется в апстриме. Upd[2015-10-02]:патч принят в основной репозиторий.

Дополнительно нужно отметить, что для отображения ReadMe в формате ReStructuredText требуется установка python-docutils. Да, именно. Это питоновский пакет, который нужен программе на ruby. Так тоже бывает.

Вывод новостей

В процессе работы был выявлен ещё один косяк, характерный именно для этой версии redmine. В случае, когда у пользователя выставлен признак «Отображать комментарии в обратном хронологическом порядке», при попытке просмотреть отдельную новость (вне зависимости от проекта и наличия комментариев) сервер выдавал Error 500. После анализа логов, мониторинга базы и изучения исходников удалось обнаружить ошибку в REDMINE_HOME/app/controllers/news_controller.rb. Косяк выпрямляется вот таким вот незатейливым способом:

diff old/news_controller.rb new/news_controller.rb
61c61
<     @comments = @news.comments
---
>     @comments = @news.comments.to_a

Кстати, как оказалось впоследствиии, в транке redmine этот баг был пофиксен в ревизии 13595 абсолютно так же.

Автоматическая подгрузка изменений

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

Чтобы redmine могла автоматически отслеживать изменения в репозиториях, в GITOLITE_HOME/.gitolite/hooks/common/post-receive.d нужно добавить скрипт, вызывающий метод fetch_changeset либо через WebAPI, либо напрямую через запуск redmine. Например, такой:

#!/bin/bash

API_KEY=XXXXXXXXXXXXXXXXX

PROJECT_ID=`git config redminegitolite.projectid || echo ''`

[ "${PROJECT_ID}" ] && {
    wget "https://<redmine.server.name>/sys/fetch_changesets?id=${PROJECT_ID}&key=${API_KEY}" >&/dev/null
    echo Redmine repository updated successfully
}

exit 0

Естественно, для доступа через веб должна быть включена соответствующая опция в настройках и получен ключик. Это делается в пару кликов на странице «Administration → Settings» на вкладке «Repositories».

Собственно, на этом всё.


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


И как обычно, текст этой статьи в формате PDF можно совершенно свободно скачать вот по этой ссылке

]]>
http://omsklug.com/2015/09/smashing-redmine-git-hosting-in-deian-jessie/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
Установка Linux на ноутбук с процессором 386sx http://omsklug.com/2012/08/linux-at-i386sx/ http://omsklug.com/2012/08/linux-at-i386sx/#comments Wed, 29 Aug 2012 06:53:37 +0000 linuxmasterz http://omsklug.com/?p=1177 386DX от AMDhttp://hackaday.com/2011/08/12/installing-linux-on-a-386-laptop/

Чудесная статья, как поставить довольно рабочий Debian GNU/Linux даже на компьютер с процессором 386SX (без математического сопроцессора!) и 4 Mb оперативной памяти.

]]>
http://omsklug.com/2012/08/linux-at-i386sx/feed/ 0
C днем рождения, Debian! http://omsklug.com/2011/08/c-dnem-rozhdeniya-debian/ http://omsklug.com/2011/08/c-dnem-rozhdeniya-debian/#comments Wed, 17 Aug 2011 13:35:43 +0000 Сторож http://omsklug.com/?p=21  Лого с сайта DebianВ 1993-08-16, Ян Мёрдок сделал сообщение в news-группе comp.linux.os.development о создании нового дистрибутива Linux. Как можно догадаться из названия топика – это был дистрибутив Debian GNU/Linux. C того времени было выпущено 11 релизов и репозиторий дистрибутива содержит на настоящее время 35000 бинарных пакетов разнообразных свободных компьютерных программ.
Долгих лет тебе, Debian! Ты уже большой, тебе 18!
Подарки принимаются по адресу: http://thank-you.debian.net/ ^___^
]]>
http://omsklug.com/2011/08/c-dnem-rozhdeniya-debian/feed/ 0