Vuze в snap.

Vuze (ранее известный как Azureus) - bittorrent клиент, написанный на Java. Вам на ум может придти мысль, что чего-чего, а уж клиентов славного битторента в линуксе достаточно. Меня не покидала эта мысль тоже, но всё-таки данный клиент обладает своими плюсами, которые вылились в лишние мучения при запихивании в snap пакет.

Внутренний браузер

Во многих языках программирования, Java не исключение, есть возможность отобразить внешний сайт внутри программы аля браузер. Vuze использует Standard Widget Toolkit (SWT) для создания GUI и отображает веб-контент в разделе для начинающих Get Started и в разделе Сеть Vuze StudioHD Network.

Данная Vuze StudioHD Network является интересной фишкой. Есть сайт, на котором каталогизируют интересное видео и оно доступно нативно в программе, но следует признать, что видео там англоязычное, разделов мало, хотя в существующих разделах видео актуальное, но в целом создаётся впечатление хорошей идеи, но не получившее развитие. Возможно, всё упёрлось в человеческий фактор и 2,5 человека устали пополнять базу.

Но идея с доступом к каталогу видео, шоу, передачам из клиента мне понравилась. Можно в один щелчок подписаться на канал или скачать конкретное видео на данном канале.

Чтобы заработал этот внутренний браузер, программе требуется xulrunner. Сначала грешным делом подумал, что потребуется Mozilla Firefox внутри снап пакета, ибо xulrunner и переменная MOZILLA_FIVE_HOME в стартовом скрипте vuze намекали на это. Оказалось что XULrunner - отдельный проект и доступен на сайте Mozilla. И вот здесь произошла интересная ситуация. Какую версию скачали бы вы? Наивно полагал, что лучше взять последнюю - 41. Только вот Vuze выводил сообщение об ошибке что не найден libxpcom.so. Пришлось перебирать версии XULrunner'а и только в его 10 версии нашёл требуемое.

Вот здесь, в очередной раз, хотелось бы показать вам фундаментальный недостаток всех традиционных linux систем с зависимостями. Это мир людей, которые строят свою свободную систему мечты. Программистов стороннего софта, как бы приглашают к себе, дескать айда к нам, следите за нашими изменениями и изменениями в компонентах что вы используете и подправляйте программы. Но мир не такой. Стороннему программисту, возможно и справедливо, дела нет до зоопарка линукса и нет желания отслеживать там версии библиотек и есть ли они вообще. Вот на таком простом примере с отсутствующей библиотекой libxpcom, мне и стало понятно почему в линукс системах вроде как и есть софт, а вроде как его толком и нет. Стороннему программисту невероятно сложно попасть в официальные репозитория, а потом вкладывать силы в поддержку и отслеживание тех компонент, которые были использованы при написании программы и станут в дальнейшем её зависимостями.

Выходом была бы статическая линковка, когда библиотеки "становятся" частью исполняемого файла, но в мире линукс все пошли путём "пакет А зависит от Б, который зависит от С".

Итак, версия XULrunner не топовая, но затык прошли и двигаемся дальше.

Плагины

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

Тут два варианта на выбор: сделать симлинки или тупо скопировать базовый набор плагинов. Решил скопировать:

• ибо Vuze умеет обновлять свои плагины и устанавливать дополнительные по запросу. Это не принято в мире линукс дистрибутивов и программам отключают функционал автообновления чего-либо. Но выбора почти не было - симлинки вызовут проблемы с обновлением существующих плагинов и подготовить первоначальный конфигурационный файл vuze для пользователя, с заранее настроенным отключением автоустановки и автообновления, было затруднительно.
• некоторые плагины создают для себя файлы с настройками пользователя и создают их там где первично размещён данный плагин.

Чтобы пользователям меньше качать и обновлять, дождался новшеств и всех их записал в базовый набор плагинов. $SNAP_USER_DATA олицетворяет путь /home/$username/snap/$app-name/$revision/ куда можно записывать. $SNAP олицетворяет /snap/$app-name/$revision/ куда установлен snap пакет программы с доступом только для чтения.

Мой стартовый скрипт-враппер содержит

if [ ! -e "$SNAP_USER_DATA/.azureus/plugins/" ]; then
    echo "Please wait, this may take a minute. "
    mkdir -p "$SNAP_USER_DATA/.azureus/plugins/"
    cp --preserve=timestamps -dR "$SNAP/opt/vuze/plugs/plugins" "$SNAP_USER_DATA/.azureus/"
fi

VLC

Следующей фишкой Vuze, которую нужно было элегантно представить в рабочем виде в снап пакете, стала возможность проигрывать скачанный медиа материал средствами программы. В последней версии Vuze медиа материалы показываются с помощью плагина HD Player (Azureus embedding media player - azemp), задействующий мощь видеоплеера VLC, к которому есть джава привязки (bindings) в лице VLCJ.

Код внутри plugins/azemp/vlcj_3.10.1.jar вызывал функцию NativeDiscovery().discover() для штатного розыска libvlc. Пришлось читать официальную документацию по VLCJ на предмет как и где осуществляется поиск. Вначале реально напрягся, когда в linux/DefaultLinuxNativeDiscoveryStrategy.java нашёл строки

private static final Pattern[] FILENAME_PATTERNS = new Pattern[] {
        Pattern.compile("libvlc\\.so(?:\\.\\d)*"),
        Pattern.compile("libvlccore\\.so(?:\\.\\d)*")
    };
    protected void onGetDirectoryNames(List directoryNames) {
        directoryNames.add("/usr/lib");
        directoryNames.add("/usr/local/lib");
    }

Жёстко вшитые адреса! Что может быть хуже!? Напомню вам, что программа в snap пакете работает в жёстком профиле AppArmor, НО не обладает своим корнем / и своими /etc/ и /usr/. Если программа вздумает прочесть в системе каталог /usr/lib/, то ей будет в этом отказано. Но набрёл в коде discovery/StandardNativeDiscoveryStrategy.java на функцию

  protected final void getDirectoryNames(List directoryNames) {
        // Look in the current directory
        directoryNames.add(System.getProperty("user.dir"));
        // Look in the directories on the system path
        directoryNames.addAll(getSystemPath());
        // Look in the extra directories supplied by the sub-class
        onGetDirectoryNames(directoryNames);
    }

Уф, есть возможность пойти через переменную $PATH. В данном месте нужно было выбрать между двумя вариантами: самому насобирать библиотеки vlc или попросить в snap добавлять мне весь vlc при сборке через snapcraft. Пакеты snap склоны к полноте и решил тут хоть немного уменьшить итоговый размер. Сам наскрёб нужное в отдельную папку и добавил путь к ней в $PATH. Vuze в опциях программы стал находить vlc библиотеки и медиа материалы стали проигрываться.

В данном моменте позвольте поделиться найденной строкой на официальном сайте videolan.org, где для VLC рекомендуется использовать именно джава привязки VLCJ, а предыдущий лидер JVLC умер, так как нет сопровождающего! At the moment the JVLC project is dead, as there is no maintainer for it. Как много умерло проектов, потому что нет сопровождающих!?

GTK

Начал обращать внимание, что выбранный мною тулкит GTK3 как-то криво справляется с отображением Vuze и появляются графические артефакты. Нашёл что это ошибка между GTK3 и SWT и советуют переменную SWT_GTK3=0. Пришлось быстро в snapcraft.yaml всё поменять с gtk3 на gtk2, с которой Vuze дружит давно.

Решил после раздумий отключить глобальное меню Unity - export UBUNTU_MENUPROXY=

Заключение

До этой увлекательный игры в снапкрафтера, где вам предлагается запихать арестанта в темницу со всем необходимым ему, я считал что знаю linux. Оказалось, думал что знал. При упаковке софта в snap пакет придётся погрузиться в знания различных компонент, особенно для GTK, которые вызываются при установке любого софта. Обычно мы это пропускаем визуально, когда ставим софт через apt, так как многое делается за нас автоматически. Архив deb кроме софта несёт в себе скрипты (post/pre), которые могут делать дополнительные вещи в системе и вызывать своими действиями системные хуки типа таких:

• update-mime-database - обновление mime.cache для иконок
• gio-querymodules - создание кеша модулей Gnome Input/Output (GIO)
• gtk-query-immodules - собирает информацию о загружаемых методах ввода для GTK+ и создаёт кеш
• glib-compile-schemas - компилирует указанные схемы GSettings в XML формате в конкретной директории и создаёт бинарный gschemas.compiled для использования его в GSettings
• update-icon-cache - кеширование иконок визуальных тем
• localedef - компилирует файлы определений локали

Только не подумайте, что до всего допёр я сам. Эти команды впервые увидел в эталонных реализациях упаковки программ, использующих различные графические тулкиты, от разработчиков, которые оформили их в облачные кусочки (cloud parts). Англоязычные разработчики только болт положили на локализацию и долгое время не мог заставить софт в снап пакете открывать файлы, если путь содержал русские буквы. Пришлось разбираться с localedef и победить беду самостоятельно.

Призываю вас поиграть в эту игру по упаковке софтины в снап пакет и вы получите бонус к прокачке скилла "знаю linux" и благодарность пользователей.
Первый snap пакет. Java программа LanguageTool. sudo snap install languagetool
Второй snap пакет. GTK программа DeaDBeeF. sudo snap install deadbeef-vs
Третий snap пакет. Java программа TuxGuitar. sudo snap install tuxguitar-vs
Пятый snap пакет. Java программа osddm. sudo snap install osddm
Шестой snap пакет. PAC (Perl Auto Connector). sudo snap install pac-vs

Дата последней правки: 2017-08-23 21:39:00