Проблема: перестал запускаться blueman-manager - программа для управления bluetooth подключениями.

$ blueman-manager

Traceback (most recent call last):

File "/usr/bin/blueman-manager", line 15, in <module>

from blueman.main.Manager import Blueman

ModuleNotFoundError: No module named 'blueman'

Эту проблему в общем виде я уже знаю - обновил python на 3.13 а библиотеки остались в путях "...3.10" поэтому он их не видит.

Хороший вариант будет обновить систему в этом случае (как и во многих других когда не охота решать проблемы, возникшие на пустом месте)

$ sudo pacman -Suy

:: Synchronizing package databases...

core 118.0 KiB 274 KiB/s 00:00 [########################################################] 100%

extra 7.6 MiB 9.22 MiB/s 00:01 [########################################################] 100%

multilib 133.8 KiB 801 KiB/s 00:00 [########################################################] 100%

:: Starting full system upgrade...

:: Replace lib32-sdl2 with multilib/lib32-sdl2-compat? [Y/n] y

:: Replace p7zip with extra/7zip? [Y/n] y

:: Replace sdl2 with extra/sdl2-compat? [Y/n] y

:: Replace webrtc-audio-processing with extra/webrtc-audio-processing-0.3? [Y/n] y

resolving dependencies...

looking for conflicting packages...

error: failed to prepare transaction (could not satisfy dependencies)

:: installing icu (76.1-1) breaks dependency 'libicui18n.so=75-64' required by electron28

:: installing icu (76.1-1) breaks dependency 'libicuuc.so=75-64' required by electron28

:: installing flac (1.5.0-1) breaks dependency 'libFLAC.so=12-64' required by electron28

Тут можно вызвать пояснительную команду: чего ему надо?

Эта ошибка pacman говорит о конфликте зависимостей. Обновление системы пытается установить новые версии пакетов icu (76.1-1) и flac (1.5.0-1), но у вас установлен пакет electron28, который жестко зависит от старых версий библиотек из этих пакетов (libicui18n.so=75-64, libicuuc.so=75-64, libFLAC.so=12-64).

Что происходит:

1. pacman -Suy хочет обновить icu и flac.

2. Новые icu и flac предоставляют библиотеки libicu*.so=76-64 и libFLAC.so=13-64 (или похожие новые версии).

3. Пакет electron28 требует именно старые версии (...=75-64, ...=12-64).

4. pacman не может одновременно удовлетворить требование electron28 (старые библиотеки) и установить новые версии icu и flac (которые предоставляют новые библиотеки). Поэтому он останавливает транзакцию.

Почему electron28 вызывает проблему:

Пакет electron28 скорее всего:

1. Из AUR (Arch User Repository): Пакеты из AUR собираются локально и могут отставать от обновлений в официальных репозиториях. Мантейнер пакета electron28 в AUR еще не обновил его для сборки с новыми icu и flac.

2. Из неофициального репозитория: Аналогично AUR, репозиторий может отставать.

3. Очень старый пакет: Возможно, он когда-то был в репозиториях, но был удален, а у вас остался.

Решение:

Самый частый и рекомендуемый способ - временно удалить пакет, вызывающий конфликт, обновиться, а затем попробовать установить его снова (он, вероятно, потребует пересборки из AUR).

1. Определите, что зависит от electron28: Чтобы понять, нужен ли вам electron28 напрямую, или он нужен для какой-то другой программы:

   pacman -Qi electron28 | grep "Required By"

   # Или более подробно:

   pactree -r electron28

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

2. Удалите electron28:

   sudo pacman -Rdd electron28

   • Внимание: Флаг -dd используется для игнорирования зависимостей при удалении. Используйте его с осторожностью. В данном случае он нужен, чтобы pacman не ругался, что удаление electron28 сломает сам electron28 (что логично).

   • Альтернатива (безопаснее): Если electron28 нужен какой-то программе (например, some-app), лучше удалить и программу, и electron28 вместе: sudo pacman -R some-app electron28.

3. Запустите обновление системы снова:

   sudo pacman -Suy

   Теперь конфликта быть не должно, и система обновится.

Сработало. Обновилось. Проблемы ушли. Но, правда, пришлось откатить ядро 6.14.2-arch1-1 на прошлую версию 6.12.1-arch1-1 которая была установлена потому что в новом пакете ядра больше нет модуля reiserfs, а у меня все еще эта файловая система.

$ uname -r

6.12.1-arch1-1

В 2011м когда ArchLinux был установлен на этот ноут версия ядра была 2.6.33
За 14 лет много ядер сменилось, а система работает как вечная несмотря на все проблемы с обновлениями, которые иногда бывают.

Всем спасибо за внимание. Если кому-то будет полезно то здесь более полный лог того, что я делал для последнего обновления.

Надысь , в процессе сёрфинга наткнулся на интересную реплику из зала под лозунгом "вся это ваша оптимизация производительности это шарлатанство "

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

Начало цитаты
Ну как бы "производительность БД" "по факту" не интересна никому...
Это интересное замечание , потому как использует стандартное обобщение "непонятно и неинтересно мне , а значить никому".
Всех "по факту" интересует "производительность прикладного приложения".
При этом никто(и это факт по крайней мере в окружающей реальности ) не знает и не умеет считать "производительность приложения".
Да есть связи между ними, но они "совсем не простые"... :-)
Астрология , магия и алхимия в начале 21го века . "Связи есть, но они не простые" Меркурий в третьем доме , блин , связан с Венерой в зодиаке 🤪
К примеру БД нагружается (выразимся так) "различными прикладными задачами".
Это очень интересный термин "нагружается". Ну , а что взяли тачку нагрузили чернозёмом . С БД также - "нагружается".
И у прикладных "задач" есть различные "требования" по времени ответа (от БД в том числе).
Требования есть только в волшебном лесу эльфов. В реальном мире нагрузочное тестирование проводят, чтобы подписать этап договора. Нет никаких требований, правило простое - закрыть этап, получить бабки , как то работает и ладно.
Если в БД нет "встроенных" средств "приотеризации" - это уже "не есть хорошо".
А зачем ?
Вот и получаем ситуацию когда один (для приложения не приоритетный) запрос в БД (который БД обрабатывает как бы быстро и оптимально) "убивает" производительность других приоритетных для приложения запросов.
И тут Остапа понесло. Понять это невозможно . Остаётся - простить.
Для PG это достаточно актуально.
Да уж.
Конец цитаты.

С одной стороны смешно и прикольно .

С другой стороны , вспоминается талантливый фильм "Такси-блюз":
- "Вань, да тебе радио хватит - во! (выше лба)".

Какой вам performance engineering и корреляционный анализ, мат.статистика и линия регрессии , вам Zabbixа воооо, с запасом, с головой, надолго хватит.
На дворе 21й век, а основная масса DBA как были ремесленниками так и остались

Вспомнилось из недавнего, на эту же тему

Мысли вслух - DBA ремесло или наука ?

пора брать кредит на пошив панамки
#comment_344335766