Сообщество разработчиков ядра Linux, к сожалению, потеряло одного из давних и продуктивных разработчиков драйверов для беспроводной сети (WiFi). Скончался Ларри Фингер, который с 2005 года вносил свой вклад в разработку ядра Linux и внес более 1500 исправлений.

( читать дальше... )

>>> Оригинал новости на Phoronix

Вопрос к ЛОР-у.

Имеется внешний почтовый сервер POP3/SMTP, на котором имеется нужный почтовый ящик, через который должна идти корреспонденция (требование не моё). Поскольку это POP3, понятно, что наличие нескольких желающих работать с этим ящиком = тотальный геморрой. Итого решено (теоретически) делать собственный proxy-relay, берущий почту с POP3-ящика и дающий доступ к уже собранному по IMAP. SMTP - просто relay.

Задача чем-то похожа на уже решённую, но сильно проще: локальных ящиков требуется ровно один, к которому имеют доступ нужные лица. Т.е., совсем упрощая, нужно «конвертировать» для пользователей POP3 в IMAP.

Т.к. большого опыта работы с postfix/dovecot не имею, хочется знать мнения по двум вопросам, по которым имеются сомнения:

• есть-ли «более лучшие варианты» связки fdm + dovecot/postfix (как делать - понятно, но если есть вариант не городить огород, то его лучше не городить)
• подводные камни варианта, когда локальный домен совпадает с виртуальным. Т.е. внешний адрес имеет имя abc@xyz.com и локальный имеет такой-же ящик abc@xyz.com (во внешний мир это не транслируется, кроме как SMTP-relay). Есть мнение что пользователи могут теряться, работая не с *@xyz.com, а с *@xyz.local, поэтому вот так.

cast waker

Появилось время, допилил плагин SNI (ссылку даю на свою репу, потом запатчу оригинальную). Т.к., как я понял, добавлять в static-deps библиотеку libdbusmenu считается проблематичным и нецелесообразным, то я сделал небольшой манёвр

• сделал с ней бандл (в репе каталог bundle)
• в процессе сборки он там же распаковывается и пути добавляются пути сборки линковки для GCC
• (!пункт к которому у меня вопрос) на завершающем этапе сборки информации о библиотеке, как я понял, LD_LIBRARY_PATH не подставишь, поэтому я делаю симлинк прямо в каталог static-deps

PATH_BUNDLE ?= bundle
FILE_BUNDLE ?= $(PATH_BUNDLE)/bundle.tar.xz
FILE_DBUS_LIBRARY = $(PATH_BUNDLE)/libdbusmenu-glib.so.4
PATH_STATIC_DEPS = $(LIBDIR)/gtk-3.10.8/lib

all: deps gtk3
deps: $(abspath $(FILE_BUNDLE))
	@tar -xvf $^ -C $(abspath $(PATH_BUNDLE)) && ln -s $(abspath $(FILE_DBUS_LIBRARY)) $(PATH_STATIC_DEPS)

Вопрос: так можно делать, или это не считается правильным?

В остальном всё нормально собирается (gtk3-версия). Вроде-бы нормально работает (проверял последнюю Plasma, GNOME3/40, XFCE, Cinnamon) и как добавлять в DPB, в целом, понятно. Я попробую это сделать, если такой подход не является проблемой. Сейчас собирается так (docker): manifest.json, make.patch.

Собрать gtk2 версию в билдере не получится, потому что нужен GVariant, который ЕМНИП только с glib >=2.24, а в билдере для gtk2 только 2.16.

cast waker

Допиливаю по-немногу SNI-плагин. Более-менее всё починил, но возник один затык, который не могу придумать, как решить (туплю) - как гарантированно отследить статус плеера при его запуске.

В данный момент отслеживаются ссобщения DB_EV_PAUSED и DB_EV_SONGCHANGED (если to == NULL - это стоп, иначе - плей) и это замечательно работает в обычном режиме. Проблема заключается в том что:

• StatusNotifier инициализируется независимо от плеера и может проинициализироваться в произвольное время при запуске (для этого есть ожидание в отдельном потоке callback_wait_notifier_register (здесь), пока просто активное ожидание playback-а)
• определение состояния через

DB_output_t* out = deadbeef->get_output();
switch (out->state()) {
    ...
}

сопряжено с трудностями, т.к. StatusNotifier может загрузиться слишком рано и получается мусор в out->state() (мусор - частично решено функцией playback_state_active_waiting) или при вызове в момент загрузки трека (подгрузки coverart или ещё чего) получается DDB_PLAYBACK_STATUS_STOP, а сообщения о готовности трека не предусмотрено.

• определение через таймер, как делаю сейчас, в принципе, работает хорошо (пока ещё код на уровне идеи, но работает), но тут возникает проблема, что при запуске порядок сообщений выглядит таким образом (лог при помощи моего простенького отладочного плагина)

[MSG (16:21:23.495064159)] DB_EV_SONGCHANGED (1000) <0x7ffae8000c20,0,0> | from: [(nil)], to: [0x14b7360], sec: [0.000]
[MSG (16:21:23.495077924)] DB_EV_SONGSTARTED (1001) <0x7ffae8000c50,0,0> | from: [0x14b7360]
[MSG (16:21:23.495086305)] DB_EV_PAUSED (14) <(nil),1,0> | сhange: [paused]
[MSG (16:21:23.495123667)] DB_EV_CONFIGCHANGED (11) <(nil),0,0>
[MSG (16:21:23.497253534)] DB_EV_SONGCHANGED (1000) <0x7ffae8011e50,0,0> | from: [(nil)], to: [0x14b7360], sec: [0.000]
[MSG (16:21:23.497287863)] DB_EV_SONGSTARTED (1001) <0x7ffae8011e80,0,0> | from: [0x14b7360]
[MSG (16:21:23.497303655)] DB_EV_SEEKED (1005) <0x7ffae8011eb0,0,0> | from: [0x14b7360], position: [41.982]

т.е. сообщение DB_EV_SONGCHANGED приходит почему-то два раза (почему???) и после паузы тоже. Поэтому, по логике обработки сообщений, которая на данный момент используется, получается что после PAUSED пришло сразу сообщение SONGCHANGED и воспроизведение запущено.

Пока больше не могу придумать, как правильно при запуске notifier-а понять в каком состоянии его запускать, т.е. отследить в каком состоянии находится плеер на момент загрузки notifier-a (возможно, что воспроизведение уже запустили вручную, пока notifier грузился). Как я понимаю, в случае, например, больших coverart-ов состояние DDB_PLAYBACK_STATUS_STOP может продлиться довольно долго и условный sleep(какое-то время) не поможет.

Каким более правильным образом можете посоветовать решить проблему? Потому что у меня кроме как вариантов убрать, каким-то образом, второе сообщение SONGCHANGED на уровне ядра плеера или добавить какой-нибудь EVENT фактического старта воспроизведения / готовности трека (что решило бы все проблемы), опять же на уровне ядра плеера, не возникает.

ЗЫ. issue на github не создаю, потому что какбы и не баг, вроде бы, а просто мой тупизм и я что-то не понимаю.