По горячим следам успешного хакафона, Вадим Жуков (zhuk@) отчитался о своих успехах:


Я прибыл на хакафон с коротким, но суровым списком задач:

1. Закончить KDE 4.13.2 и приготовить 4.13.3 (официальный анонс - 15 июля*)

> * Разработчики KDE дают возможность мейнтейнерам пакетов с KDE в той или иной ОС иметь т.н. предварительный доступ, где-то дней за 3-5 до официального релиза. Это позволяет выпускать "родные" пакеты с KDE для ОС одновременно с официальным анонсом релиза.

2. Наконец-то портировать несколько приложений из openbsd-wip в официальный cvs

3. Исправить давнюю проблему с усиленным поеданием процессора в kded4

4. Продолжить работу над Samba 4.x

5. Исправить проблему с отсутствием ext2fs в установщике для amd64 (RAMDISK_CD)

6. Некоторые вещи, которые я разбабатывал последние месяцы для ports/infrastructure, занести в CVS

7. Занести в CVS порт man-pages-posix

Но прежде всего хакафон для вас начинается со знакомства с людьми, с которыми вы не были прежде знакомы. Учитывая, что до этого единственным мероприятием, связанным с OpenBSD, которое я посещал, была конференция EuroBSDCon 2013, на хакафоне было много новых лиц. Боюсь, что не запомнил их всех, но не потому, что я не уважаю их или их работу, это просто мой недостаток :)

Итак, хакафон начался. Мы с kirby@ - другим портером OpenBSD из России - сели друг напротив друга. И это нам очень помогло - он помог мне тестить сборку ядра с ext2fs и дал мне идею насчёт libinotify (см. ниже), а я помог ему обновить порт rawtherapee.

Мой первый коммит на этом хакафоне был занесением в CVS books/man-pages-posix. Это полезная вещь для разработчиков, и я получил положительные отзывы ещё до того, как начал это импортирование.

Это был не столько мой труд, сколько schwarze@ и других разработчиков, давших большое количество отзывов и замечаний. Я узнал много нового о mandoc, groff и pkg_create во время работы над этим портом. Но, опять же, это было только для разгона.

Большую часть времени я сидел и делал четыре вещи: запускал make, твикал патчи, пушил их в апстрим и засыпал landry@ новыми портами. Я благодарен ему за терпение. Благодаря его отзывам*, у нас теперь есть следующие приложения из KDE4: Calligra suite, Digikam, K3b, Kdenlive, KDevelop, KMyMoney, KTorrent, Tellico и Yakuake (вместе с зависимостями, типа Eigen 3.x).

> * Отзывы (ревью) могут быть и без замечаний, но без ревью занесение в порты не делается.

Из портов, связанных с KDE4, в openbsd-wip осталась только audio/cantata: она имеет несколько кривую интеграцию с KDE4, так что мне быстро это надоело - плееров, в том числе для KDE4, и так хватает. Надеюсь, что Рафаэль Садовски, который постоянно мне помогал, не обидится. :)

Обновление KDE 4.13.2 само по себе скучно и неинтересно. Имеем 200+ портов, значит, 200+ раз пишем "make configure update-plist port-lib-depends-check package clean", отправляем несколько патчей в апстрим, закончили упражнение. Вот и всё. Реально всё. Трудными были задачи собственно портирования KDE4, а также совместного существования KDE3 и KDE4, а поддержка портов KDE4 не так сложна.

И вот пришло время для действительно интересненького. kded4. Если вы не в курсе подробностей: kded4 (что означает "KDE 4 Daemon") обычно запускается с kdeinit... то есть, либо в самом начале сессии kde, либо когда вы запускаете первое приложение KDE. Этот демон хостит так называемые модули KDE - Если вы видели services.exe в Windows, то вы понимаете, о чём я, это почти то же самое. Другая задача kded4 - мониторить файлы конфигурации, особенно связанные с MIME файлы .desktop. При установке/настройке/удалении приложения .destkop-файлы могут изменяться, как системные (в /usr/local), так и ваши личные (в $KDEHOME). Многие программы, особенно различные виджеты рабочего стола (читай: KDE-меню и подобное), заинтересованы в уведомлениях о таких изменениях. Таким образом, kded4 мониторит некоторые директории на предмет добавления/изменения/удаления .desktop-файлов.

В OpenBSD этот процесс был очень неэффективен. А причина в том, что kded4 внутри использует KDirWatch, который по умолчанию использует inotify в Linux и QFSWatch в других операционных системах. Он также поддерживает FAM, но я уже пытался его использовать, но результаты меня не удовлетворили. Я уже начал было думать о реализации бэкэнда на базе kqueue(2), и тут я вспомнил, что kirby@ работает над libinofity. Это ведь то, что нужно - inotify API на базе kqueue. Так что я написал FindInotify.cmake который должен работать и в Linux и вне Linux, сделал несколько #ifdef в коде, пересобрал kdelibs ... и вот оно! Теперь kded4 проверяет файлы при запуске, и дальше живёт абсолютно не напрягаясь!

Ещё после этого akonadi_maildir_resource перестал жрать ресурсы: похоже, он страдал той же проблемой. Две проблемы по цене одной! Покупайте наши libinotify! *

> * важное предупреждение: все пользователи KDirWatch теперь едят намного больше файловых дескрипторов (до нескольких тысяч - по сути, по дескриптору на каждый отслеживаемый каталог и файл). На Linux эта проблема не так заметна, так как там обычно банально не стоит никаких лимитов, или они задраны очень высоко.

Кроме того, за время этого хакафона я успел закончить:
* новую утилиту portbump(1), в связке с sqlports она позволяет сэкономить много времени на масштабных обновлениях.
* добавил переменные TEST_ENV и ALL_TEST_ENV в bsd.port.mk: одного TEST_FLAGS было явно недостаточно, поскольку некоторые порты на CMake (читай: использующие Ninja) не понимают TEST_FLAGS вообще.
* документацию для devel/cmake и x11/kde4. Не имею намерения документировать x11/kde, потому что его больше никто не собирается поддерживать, а кто поддерживает сейчас, и так всё знает.

К сожалению, не хватило времени на samba4. Есть хитрые проблемы, связанные с ld.so и компилятором, которые я надеялся исправить на хакафоне... но не всё сразу. Так или иначе, KDE был приоритетной задачей.

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

В заключение, я хочу (чувствую необходимость, обязан) сказать спасибо Мите Муженичу и гостевому дому "Табор" за организацию этого чудесного мероприятия. Это был мой первый хакафон, и было удивительно, сколько всего произошло за несколько дней. И Любляна - прекрасный город... Я надеюсь что кто-то, кто знает английский язык лучше меня, сможет ярче живоописать этот уютное место и его жителей. Всё было просто классно - спасибо, спасибо и еще раз спасибо!

Ааа, завидую! В хорошем смысле! А Тео там тоже был?
Можно ли поподробнее описать как проходят хакафоны?
1) как туда попасть?
2) много ли людей участвует
3) где все спят
4) как общаются
5) сколько дней всё это длиться

Благодарю)
---
soko1

> Правда придётся копировать весь LUKS раздел на винт и перебивать винт с нуля, чтобы выделить гигов 15 для начала.
> Кстати, сколько нужно место для того чтобы собирать софт из сорцов? Хотя думаю вообще /usr/obj, /usr/xobj сделать в tmpfs, у меня ОЗУ всё равно 8 гиг.

у меня обычно иноды быстрее заканчиваются, если маленькие разделы делать :)

места... про порты или про систему? про порты - иной раз и 6 гб требовалось... больше, вроде, не попадал :) на базовую систему и ксенокару - гига 3, если очищать obj перед сборкой иксов. хотя я на 3 как-то раз упёрся в нехватку места... поэтому, наверное, даже больше трёх...

> Можно ли поподробнее описать как проходят хакафоны?

мы сейчас как раз отзывы переводим :) только как-то вяло... но там люди впечатлениями делятся - несколько сообщений вниз есть ссылка на оригиналы:

Тео был, вот его необработанный ещё перево отзыва Тео: http://51t.ru/Wq6ZYW

> Ааа, завидую! В хорошем смысле! А Тео там тоже был?

Естественно. Это был ежегодный большой "всеобщий" хакатон.

> Можно ли поподробнее описать как проходят хакафоны?
> 1) как туда попасть?

Получить приглашение. :)

> 2) много ли людей участвует

Когда как. Статистика на http://www.openbsd.org/hackathons.html

> 3) где все спят

Обычно устроитель хакатона обеспечивает (сам или при финансовой помощи OpenBSD Foundation) места в каком-нибудь общежитии (ныне их хостелами кличут). Кто не хочет - селится сам в какой-нибудь гостинице.

> 4) как общаются

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

> 5) сколько дней всё это длиться

Когда как, обычно - около недели. Опять же, статистику можно собрать по ссылке выше.

> у меня обычно иноды быстрее заканчиваются, если маленькие разделы делать :)

newfs -i2 (или даже -i1) спасёт отца русской демократии. ;)

> > Кстати, сколько нужно место для того чтобы собирать софт из сорцов? Хотя думаю вообще /usr/obj, /usr/xobj сделать в tmpfs, у меня ОЗУ всё равно 8 гиг.

Для базовой системы уходит гигабайта два, вроде. Или даже меньше. xenocara - не помню, но не больше.

А вот для портов - смотря что и как собирать. У меня сейчас 29 гигов - на случай полной сборки KDE (3+4) и libreoffice без очистки. Нормальному человеку, которому ВДРУГ понадобится прогнать полный bulk build посредством dpb(1), должно хватить 20 гигов для /usr/ports/pobj (у меня он, кстати, живёт в /usr/obj/p) за глаза. Правда, ещё нужно где-то хранить distfiles и собственно собранные пакеты (у меня они живут на одном разделе, 23 гига, из них сейчас занято 16 - перестарался с запасом).

>> Можно ли поподробнее описать как проходят хакафоны?
>> 1) как туда попасть?
> Получить приглашение. :)

ну, там, наверное, только разработчики... или девочек тоже приглашают? :)

>> newfs -i2 (или даже -i1) спасёт отца русской демократии. ;)
>
>я про авторазбивку... было в 5.3.. оно место под usr/src выделило, места хватает, а работать на нём - не работает :)

Про 5.3 не скажу. Я в 5.4 или 5.5 /usr/src получал - вроде, проблем не было... Ты ведь не забываешь "make obj" делать? ;)

>> Для базовой системы уходит гигабайта два, вроде.
>
>я про полный цикл, с сборкой DESTDIR и RELEASEDIR

Ну, добавь ещё мегабайт 300 на упакованный полный комплект. :)

В случае моём и ajacoutot@ девочки развлекались самостоятельно - кто на машине, кто поездом катались по Словении. Благо страна красивая и море есть. :)

> ну, там, наверное, только разработчики

Угу. Правда, не всегда коммиттеры - иногда приглашают многообещающих новичков. Но в целом - да, напрашивающихся и просто "со стороны" туда не зовут. Хакатоны - не конференции, здесь работу работают, которая в удовольствие. :)

> Ты ведь не забываешь "make obj" делать? ;)

там просто не хаватало инодов, самих по себе :)

> Ну, добавь ещё мегабайт 300 на упакованный полный комплект. :)

и на распакованный тоже место нужно... насколько я понимаю, в этом случае у тебя и полный src, и полный obj и полный dest, а потом ещё и тарболы... не меньше трёшки вылазит... потом очищаешь всё добро, кроме тарболов, и то же самое с ксенокарой... (кстати, почему эта штука не дополняет SHA256, а перезаписывает его?)

Вообще-то после make obj у тебя начинает использоваться для сборки /usr/obj. А /usr/src практически не трогается вообще. Ну и DESTDIR и RELEASEDIR можешь указывать куда угодно.

Кстати, раньше, вроде бы в русскоязычном obsd-сообществе прижилось слово "хакафон". Мне оно, кстати, больше нравится. А потом пришли "стиляги" со своими рубями и гитхабами, и стало "хакатон". Надо какой-то общий термин :)

> кстати, почему эта штука не дополняет SHA256, а перезаписывает его?

Вот тут ничего не скажу. Вообще не интересовался SHA256.

Я всегда называл "хакатоном", по собственному почину. Ещё до того как увидел первый раз Ruby и GitHub. :( Предлагаю пока не заморачиваться, а через годик сделать выборку - что популярнее.

> Вообще-то после make obj у тебя начинает использоваться для сборки /usr/obj. А /usr/src практически не трогается вообще.

разумеется... проблема была в том, что, я уже не помню, на какой релиз, инодов не хватало. я сейчас не вспомню, или в src, или в obj или вообще ports - но не хватало инодов даже просто их на этот раздел скопировать :)

> Вот тут ничего не скажу. Вообще не интересовался SHA256.

это файл такой, в релизе лежит... :) в любом каталоге с тарболами на FTP :)

когда делаешь make release для src, он собирает, потом кладёт тарболы и собирает SHA256 с хэшами. а когда делаешь make release на ксенокару, он делает ровно то же самое... приходится сначала копировать файл SHA256, а потом уже два в один обновлять... :)

> приходится сначала копировать файл SHA256, а потом уже два в один обновлять... :)

А-а-а. Дело в том, что релизы базовой ОС и Иксов собираются в разных местах, поэтому проблема не так актуальна: в момент обновления ftp.openbsd.org происходит простое склеивание этих файлов. Вот никто и не чинил. :)