collaboration in foss

rpm-build-mono

Алексей Турбин решил все проблемы с моновскими зависимостями в репозитарии СИЗИФУС им. Р.М.Столлмана.

Integer overflow in Math-BigInt-FastCalc 0.15

Регрессионное тестирование СИЗИФА (регулярная тестовая пересборка пакетов) помогает обнаруживать и исправлять реальные ошибки в пакетах.

Некоторое время назад я обновил пачку перловых модулей для работы с "большими числами" (Math-BigInt и ещё несколько модулей, включая Math-BigInt-FastCalc. После тестовой пересборки сломался модуль Convert-ASN1 -- отвалился один из тестов (в большинстве пакетов make test выполняется по умолчанию и влияет на результат сборки).

Первичное исследование показало, что поломка происходит как раз вследствие обновления модуля Math-BigInt-FastCalc. Я повесил багу rt.cpan.org #29720. К сожалению, по моим наблюдениям, автор этих модулей Tels занимается своим целочисленным хозяйством наскоками, примерно раз в несколько месяцев.

Пришлось браться за дело самому. Выяснилось, что падает один из тестов, в котором в качестве целочисленного аргумента используется 2**31 = 2147483648. Короче, мне удалось расковырять и исправить integer overflow при сравнении целых чисел. Дело в том, что это число не вмещается в примитивный тип int -- оно занимает самый старший бит машинного представления, то есть имеет бинарное представление 10000000000000000000000000000000. При попытке сравнения этого числа как обычного int старший разряд интерпретируется как отрицательный знак числа, то есть проверка типа i < MAX всегда выполняется, но не таким образом, как это было задумано.

Исправленный пакет perl-Math-BigInt-FastCalc отправлен в СИЗИФУС.

Футболка с рыжей лисой

На днях до меня дошла таки футболка Firefox 2 International Development Team. Маршрут футболки был таким: MoFo - Essen - Istanbul - Antalya - Москва (шла почти три месяца). Но зато приятно было вскрыть после такого долгого ожидания. :)

Читая блоги

• Джеймс Макговерн пишет о том, что CentOS — не просто клон редхата, а нелегальный клон редхата. Почему-то он говорит о “неэтичности” такого клонирования, то есть выводит дело в область субъективных оценок. По-моему, это он делает зря и ситуация вполне однозначна: если я использую чужие пакеты, никак их не меняя, кроме вырезания торговых марок, то это обыкновенное правонарушение, и этика здесь не при чем.
• Джон Дауделл пишет о том, что Стивен Шэнклэнд пишет, что гугловский Андроид содержит форк Java и задает вопросы о целесообразности такого подхода.
• Савио Родригес пишет о том, что RedHat заключил начал сотрудничество с Hyperic. По-видимому, RedHat не считает приложения по управлению и мониторингу “своим” рынком. Правильное решение — там слишком много “специфики”.

Дыбр. Symlink resolution strategy

Где-то последние два дня опять думал над rpm'ом, будь он неладен. Есть такое дело: в пакетах бывают симлинки, и они могут смотреть за пределы самого этого пакета. Требуется некая идея или стратегия разрешения зависимостей в связи с наличием таких симлинков. То есть зависимости должны обеспечить более или менее то, что в конечном счёте не должно быть битых симлинков после установки пакета.

Первичное это дело не самым топорным способом было реализовано ещё по весне. Называется symlinks.req.

Но здесь есть слишком много тонкостей. Допустим, мы хотим разрешить зависимость на /usr/share/libtool/config.sub. У нас /usr/share/libtool -> libtool-1.5/ -- это альтренатива. То есть в будущем она может смотреть на -> libtool-1.6/ или куда-то ещё. Поэтому ставить конкретную зависимость на пакет libtool_1.5 нежелательно. Нужно ограничиться виртуальной зависимостью на /usr/share/libtool, хотя она и не даёт гарантию, что при очередном апгрейде либтула там будет лежать config.sub.

Теперь на это накладывается проблема каноникализации путей. Допустим, кто-то требует путь /usr/share/libtool/../../bin/perl. Бывает всякое, правда?! Какая зависимость здесь должна появиться? Если примитивно отсекать всё что /usr/share/libtool/*, то мы получим зависимость на /usr/share/libtoot вместо /usr/bin/perl!

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

Короче, мне удалось придумать почти окончательно правильное решение для этого класса проблем. Некоторые подробности этого решения можно узнать здесь:
http://git.altlinux.org/people/at/packages/rpm.git
https://bugzilla.altlinux.org/show_bug.cgi?id=13374

Попутно ещё занимался питоном. Питон у нас бесхозный, и никому до него нет дела, если только не считать, как бы это сказать, более случайных людей. Однако дело идёт в гору. Имеет место исполнение желаний в стране СИЗИФУС!! Практически страна дураков, я так думаю. Но об этом в следующий раз.

PS: конквер глючит, ох как крепко глючит, сука! Стал думать уже что раз браузер падает то всё это наше дело ни к чёрту не годится, типа надо самораспускаться. А потом стал уже думать ну и хрен с ними с браузерами, у самих револьверы найдутся.

syntax highlighting in hgweb

j2a поделился ссылкой на расширение, раскрашивающее исходники в web-интерфейсе mercurial.

Поскольку этот extension ещё не попал в релиз, пришлось слегка поработать напильником, чтобы включить:

1. Взял файл из репозитория.


2. Положил в /var/lib/python-support/python2.4/hgext, поскольку было лениво собирать пакет.


3. Включил по инструкции в /etc/mercurial/hgrc. Точнее, почти по инструкции: "hgext.highlight =" не работает - trailing whitespace парсером конфига не откусывается, нужно "hgext.highlight=".


4. Сгенерировал CSS-ку: pygmentize -f html -S colorful > /usr/share/mercurial/templates/static/highlight.css (как я понимаю, этот шаг после релиза станет не нужен)

Работает.

Иерархия, однако...

Музыка для дистрибутива

OpenBSD пишет песенки приуроченные к выпуску дистрибутивов. Думаю что эта идея сгодится и для ALT Linux Team. Либретто будет таким.

Бранч четыре-ноль!
Бранч четыре-ноль!
Надежность и стабильность --
Бранч четыре-ноль!

Бранч четыре-ноль!
Бранч четыре-ноль!
Платформа и мобильность --
Бранч четыре-ноль!

[Далее "Фирменная стильность" или что-нибудь такое.]

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

Какие ещё есть идеи насчёт либретто?

branch-4.0.mp3

Креатив говно получился, нужно будет по-нормальному записать, но сейчас нет такой возможности.
ftp://ftp.altlinux.org/pub/people/at/branch-4.0.mp3

Угроза бездействием

Сильно раздражают люди, предлагающие игнорировать нарушение FLOSS-лицензий на том основании, что если начать наезжать на нарушителей, то эти нарушители возьмут и закроются.

timidity

Timidity плохо делает барабаны. Я покрутил реверберацию и хорус и вроде стало получше, но всё равно не очень солидно. В принципе есть отдельная продвинутая драм-машина называется Гидроген, и она делает барабаны получше, я раньше пробовал. Но как всё это потом сводить это неохота голову ломать, а придётся.

Думаю если разбогатею то нужно купить пианино Yamaha CLP-240, а если нет то какую-нибудь дрищовенькую миди-клавиатуру. И заняться музыкой. Но для начала нужно написать слова для песен. Кто бы мне с этим помог? Тема песни напр. "Я собрал Перл". Жанр ориентировочно в районе джаз-рок...хард-техно.

Приватные зависимости у пакетов

С rpm-зависимостями существует одна общая проблема -- это так называемые "приватные" зависимости в пределах одного пакета. Например, в пакете могут лежать "приватные" разделяемые библиотеки /usr/lib/%name/lib*.so*. Их нежелательно предоставлять как библиотеки в пределах репозитария, но желательно уметь разрешать зависимости на такие библиотеки в пределах этого самого пакета. Если же их явно не предоставлять, то нельзя ставить и "комплементарный" Requires в пакете, потому что это будет unmet dependency.

Аналогичная проблема существует не только с ELF библиотеками, но и, например, c моновскими библиотеками. Общесистемные моновские библиотеки лежат в /usr/lib/mono/gac/, и они должны явно предоставляться для репозитария. С другой стороны, многие пакеты содержат "приватные" диелели (DLL), которые лежат в другом каталоге, специально для этого пакета. Такие приватные диелели предоставлять для репозитария тоже не надо, но нужно каким-то образом уметь разрешать зависимости на эти библиотеки в пределах самого пакета.

_avm_ размышлял над этой проблемой и предложил ad-hoc решение (или же "хак"), который сводится к тому, что можно предоставлять некоторые зависимости с "флагом" [private]. Зависимости provides с этим флагом в самом конце удаляются, но только после того, как они взаимно уничтожают совпадающие зависимости requires в пределах пакета. Это решение некрасиво по многим причинам. Прежде всего, оно залезает в librpm и делает там грубый хак, который не особо вписывается в те базовые механизмы, которые даёт librpm.

Но в ходе разбора полётов также выяснилось, что решение _avm_ имеет принципиальное ограничение -- приватные зависимости могут уничтожаться только в пределах одного подпакета. Если же пакет распилен на несколько подпакетов, то взаимное уничтожение requires и private provides между подпакетами уже не происходит. На примере пакета openoffice.org, который имеет подпакеты openoffice.org-kde и -gnome, было показано, что этот подход в данном "критическом" случае ничего не даёт.

Я предложил другой подход -- сводить зависимости на приватные библиотеки к файловым зависимостям. То есть если удаётся обнаружить, что в $RPM_BUILD_ROOT лежит "эта приватная штука" (которую кто-то здесь же требует), типа /usr/lib/foo/libfoo.so.0 или же /usr/lib/bar/bar.dll, то достаточно поставить зависимость на этот файл, и всё. rpm и apt сейчас более-менее нормально разрешают файловые зависимости такого рода (то есть не нужно явно "предоставлять" файл, чтобы потом его требовать; апт пришлось захачить примерно три раза!). Более того, я реализовал оптимизацию зависимостей в addReqProv, чтобы любая зависимость на файл, который содержится в этом же самом пакете, оптимизировалась (удалялась). Поэтому в большинстве случаев, когда файловую зависимость можно определить однозначно, получается "всё чисто". То есть файловые зависимости дают дополнительные связи между подпакетами без явных provides в репозитарии.

Только тут есть такая тонкость, что не всегда это получается слишком однозначно. Появляется неоднозначность: мы считаем, что файлы, которые лежат в $RPM_BUILD_ROOT, должны быть запакованы в какой-либо подпакет (по крайней мере, те из них, которые нас "интересуют"). На самом же деле нет никакой гарантии, что какой-то файл под $RPM_BUILD_ROOT будет на самом деле запакован, и хуже того, базовая идеология rpm вполне себе позволяет не паковать какие бы то ни было файлы что лежат в $RPM_BUILD_ROOT. То есть мы генерируем зависимость на файл в $RPM_BUILD_ROOT, полагая, что он будет запакован, хотя нам никто не давал окончательного права так полагать. То есть тут остаётся некоторое пространство для фальсификации. Хотя на практике это пространство небольшое, и воспользоваться этой фальсификацией "случайно" практически нереально, а если делать атаку на "логику зависимостей" то особой защиты от дурака сейчас в любом случае нет (или почти нет). Её и нельзя особо сделать, иногда даже из соображений halting problem, -- иногда всё "висит на волоске" (или "на соплях") и остаётся только надеяться, что maintainter не делает глупостей.

В общем, в случае с моновскими библиотеками в первом приближении мой подход вроде бы работает правильно. http://git.altlinux.org/people/at/packages/rpm-build-mono.git Хотя полное сканирование $RPM_BUILD_ROOT в поисках потенциальных приватных библиотек меня всё же смущает.

Я начал делать этот же подход в самом rpm-build по части скриптов и симлинков. http://git.altlinux.org/people/at/packages/rpm.git Тут меня тоже многое смущает. Не знаю удастся ли мне побороть своё смущение и продавить всё это до конца или нет.