gentoo заскоки

[ormorph]

В Gentoo сейчас смотрю нужно быть осторожными баг. Тот кто ранее обновился, должен обновить порты и откатить app-arch/xz-utils на стабильную. Так как в новой версии обнаружен бэкдор. Если ранее собирали ядро где для модулей используется сжатие xz, нужно заново пересобрать ядро со старым app-arch/xz-utils, либо использовать уже собранный gentoo-kernel-bin, где для модулей не применялось сжатие. Последние версии xz-utils смотрю уже удалены с git. Так уж совпало, что в новом профиле 23.0 добавлен включенный флаг lzma.
Будьте внимательны...

[bars]

привет, заметил что при старте системы етсь ругань при старте сервисов.

Код: Выделить всё

systemd-tmpfiles-setup-dev |/usr/lib/tmpfiles.d/static-nodes-permissions.conf:18
systemd-tmpfiles-setup-dev |/usr/lib/tmpfiles.d/static-nodes-permissions.conf:19
systemd-tmpfiles-setup-dev |/usr/lib/tmpfiles.d/static-nodes-permissions.conf:20
systemd-tmpfiles-setup-dev |* ERROR: systemd-tmpfiles-setup-dev failed to start

содержимое файла /usr/lib/tmpfiles.d/static-nodes-permissions.conf
строки 18/19/20

Код: Выделить всё

z /dev/kvm          0666 - kvm -
z /dev/vhost-net    0666 - kvm -
z /dev/vhost-vsock  0666 - kvm -

Пока эти строки просто закоментировал, но не пойму из-за чего ругается.

[yoricI]

А в новости тут [ON] В библиотеке xz/liblzma выявлен бэкдор, организующий вход через sshd пишут, что gentooo не подвержена.

[ormorph]

А в новости тут [ON] В библиотеке xz/liblzma выявлен бэкдор, организующий вход через sshd пишут, что gentooo не подвержена.

В багзиле, ссылке что я дал написано что вроде как не подвержена, так как там ищутся файлы deb и rpm. Но тут же говорят, что это до конца не изучено.

[Bizdelnick]

пишут, что gentooo не подвержена.

Проверить недолго:

Shell

% ldd /usr/sbin/sshd | grep liblzma
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007ff7a597f000)
%

[yoricI]

У меня чисто, спасибо за науку.

[gamper785]

Народ, у вас последние ядра на ~ветке генкернелом нормально собираются?

[/dev/random]

Народ, у вас последние ядра на ~ветке генкернелом нормально собираются?

В таких случаях принято приводить лог с ошибкой. Без него я могу только предположить, что вы столкнулись с этим багом: https://bugs.gentoo.org/928573.
Виновато в нём не ядро, а sys-kernel/linux-headers, для сборки busybox с новыми версиями которого требуются патчи. Genkernel, пытаясь собрать initramfs (а не ядро), не включает эти патчи.

[gamper785]

Спасибо, Ранд, большое ззавтра попробую

[dimonchik]

У меня само ядро 6.8.4 собирается, dracut вполне успешно собирает initram, но при загрузке ядра на первой секунде получаю kernel panic.
Ядро 6.7.12 собирается и работает нормально. Собирал так: взял готовый конфиг для ядра 6.7.12 как обычно сделал make oldconfig, потом собрал и даже модуль nvidia-drivers нормально собрался. Но при старте - кернел паника. Конфиг прилагаю.

dima.zip

[ormorph]

Но при старте - кернел паника. Конфиг прилагаю.

Это нужно смотреть на вывод что за паника. Если связанно с dracut, тот там вроде можно было добавлять модули в initramfs, не помню уже как, когда то давно делал такое, уже давно не требуется такое. А так я не стремлюсь использовать нестабильное ядро, по этому не знаю что там с ним не то.

[dimonchik]

Для пробы устанавливал ядро gentoo-dist-bin версии 6.8.4 - грузилось нормально, а вот сборка по конфигу просто gentoo-dist с официальным конфигом - висит на uefi logo и что там посмотреть лог не могу. В моем конфиге uefi logo отключено. Есть способ как сохранить вывод?

[ormorph]

Есть способ как сохранить вывод?

Не только сфоткать. Оно даже не дошло до логирования, по этому нет. У меня uefi работает через grub, проблем как то не вижу у себя. gentoo-dist-bin работает норм, так же норм работает и собранное gentoo-sources c моим конфигом, я его долго под свой комп доводил, теперь он мигрирует от версии к версии. Собирать gentoo-dist как то не было надобности, сильно долго будет.
Хотя бывало что после обновления, в том числе и ядра, у меня наворачивалась установка с EFI с grub, уже не помню в чём это выражалось. На сколько я помню я вообще форматировал раздел EFI и с LiveUSB заново ставил GRUB. Если бы у меня на другом компе с тем же самым ядром проблем не было, то я бы заморочился пересборкой ещё ядра, но я переключился на legacy и всё загрузилось.

[dimonchik]

ormorph
Да не вопрос.

photo_2024-04-11_05-10-01.jpg

[ormorph]

Похоже какая то фигня с btrfs. У меня в gentoo-kernel-bin-6.6.21 оно собрано непосредственно в ядре(не модулем). Как у вас в sys-kernel/gentoo-kernel я не знаю. Тут нужно смотреть файл .config в архиве с исходником. Если собрано модулем то скорее всего в этом дело, тогда смотреть в сторону initramfs. Как initramfs сейчас там собирается не углублялся.

[dimonchik]

Похоже какая то фигня с btrfs.

Похоже решил проблему. У меня BTRFS тоже вшито в ядро. Но после того как отключил выделенное на картинке, ядро успешно стартовало.

2024-04-11-123228_hyprshot.png

[yoricI]

Интересно, что так могло повлиять на увеличение времени компиляции? Было стабильно менее 10 минут, стало стабильно за полчаса.
Fri Sep 1 09:45:30 2023 >>> dev-lang/python-3.11.5 merge time: 8 minutes and 44 seconds. Fri Dec 1 01:49:53 2023 >>> dev-lang/python-3.11.6 merge time: 8 minutes and 44 seconds. Fri Dec 1 01:56:18 2023 >>> dev-lang/python-3.12.0_p1 merge time: 6 minutes and 25 seconds. Thu Dec 14 10:57:07 2023 >>> dev-lang/python-3.12.1 merge time: 7 minutes and 25 seconds. Fri Dec 29 01:18:35 2023 >>> dev-lang/python-3.11.7 merge time: 7 minutes and 42 seconds. Thu Jan 18 12:32:30 2024 >>> dev-lang/python-3.12.1_p1 merge time: 7 minutes and 22 seconds. Fri Mar 1 01:35:02 2024 >>> dev-lang/python-3.11.8_p1 merge time: 7 minutes and 45 seconds. Fri Mar 1 01:48:32 2024 >>> dev-lang/python-3.12.2_p1 merge time: 7 minutes and 55 seconds. Fri Mar 15 05:56:51 2024 >>> dev-lang/python-3.11.8_p1 merge time: 32 minutes and 21 seconds. Fri Mar 15 06:30:09 2024 >>> dev-lang/python-3.12.2_p1 merge time: 33 minutes and 18 seconds. Thu Mar 28 23:49:09 2024 >>> dev-lang/python-3.11.8_p1 merge time: 31 minutes and 34 seconds. Fri Mar 29 05:49:50 2024 >>> dev-lang/python-3.12.2_p1 merge time: 33 minutes and 7 seconds.

Добавлено (05:40):

Вспомнил, это же я LTO-оптимизацию включил, и ещё какую-то. Надеюсь, что затраты окупятся при работе))

[Bizdelnick]

Надеюсь, что затраты окупятся при работе))

Обязательно. За пару сотен лет.

[yoricI]

Обязательно. За пару сотен лет.

Будем измерять удовольствием. На глаз, который очень точный и чувствительный инструмент, кстати говоря, firefox ощутимо быстрее шевелится при прокрутке страниц. Но и ресурсов в два раза больше требует при сборке: 13Гб диска вместо 6-ти, чего не жалко, а по времени собирается столько же.

[dimonchik]

Привет. После вчерашнего обновления поломались некоторые приложения: waybar, rofi, nwg-launcher и даже clementine и др.
nwgbar и nwggrid не хотят запускаться.

Код: Выделить всё

❯ nwggrid
INFO: wm: hyprland
INFO: trying /home/dima/.config/nwg-launchers/nwggrid/grid.conf
INFO: Locale: 
INFO: Using css file '"/home/dima/.config/nwg-launchers/nwggrid/style.css"'
ERROR: Failed to load fallback icon '/usr/share/nwg-launchers/icon-missing.svg'
ERROR: Failed to load fallback icon '/usr/share/nwg-launchers/icon-missing.png'
ERROR: No fallback icon available

rofi - запускается но жалуется на то, что не может открыть иконки.

Код: Выделить всё

❯ rofi -show drun -show-icons -theme simple-tokyonight.rasi

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.300: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/symbolic/actions/search-symbolic.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.303: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/kitty.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.320: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/org.clementine_player.Clementine.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.321: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/skypeforlinux.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.321: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/com.obsproject.Studio.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.323: Failed to load image: Не удалось распознать формат изображения для файла «/usr/share/icons/hicolor/16x16/apps/io.github.thetumultuousunicornofdarkness.cpu-x.png»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.323: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/viber.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.323: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/preferences-system.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.345: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/utilities-log-viewer.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.346: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/2048-qt.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.346: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/ark.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.346: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/audacity.svg»

(process:2937): Helpers.IconFetcher-WARNING **: 19:45:07.347: Failed to load image: Не удалось распознать формат изображения для файла «/home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/bleachbit.svg»

waybar тоже жалуется, что не может открыть иконки

Код: Выделить всё

❯ waybar -c ~/.config/waybar/hyprpaper/config -s ~/.config/waybar/hyprpaper/style.css
[2024-05-03 19:46:19.309] [info] Using configuration file /home/dima/.config/waybar/hyprpaper/config
[2024-05-03 19:46:19.312] [info] Discovered appearance 'dark'
[2024-05-03 19:46:19.312] [info] Using CSS file /home/dima/.config/waybar/hyprpaper/style.css
[2024-05-03 19:46:19.323] [info] Hyprland IPC starting
[2024-05-03 19:46:19.327] [info] Loading persistent workspaces from Hyprland workspace rules
[2024-05-03 19:46:19.425] [info] Found device 2.4G Receiver at '/dev/input/event3'

(waybar:3017): Gtk-WARNING **: 19:46:20.008: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
[2024-05-03 19:46:20.227] [info] Bar configured (width: 1670, height: 40) for output: DVI-D-1
[2024-05-03 19:46:20.227] [error] Item '': No icon name or pixmap given.

** (waybar:3017): CRITICAL **: 19:46:20.228: 
unhandled exception (type Glib::Error) in signal handler:
domain: gdk-pixbuf-error-quark
code  : 3
what  : Failed to load /home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/image-missing.svg: Нераспознанный формат файла изображения

[2024-05-03 19:46:20.228] [error] Item '': No icon name or pixmap given.

** (waybar:3017): CRITICAL **: 19:46:20.229: 
unhandled exception (type Glib::Error) in signal handler:
domain: gdk-pixbuf-error-quark
code  : 3
what  : Failed to load /home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/image-missing.svg: Нераспознанный формат файла изображения

[2024-05-03 19:46:20.229] [error] Item '': No icon name or pixmap given.

** (waybar:3017): CRITICAL **: 19:46:20.229: 
unhandled exception (type Glib::Error) in signal handler:
domain: gdk-pixbuf-error-quark
code  : 3
what  : Failed to load /home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/image-missing.svg: Нераспознанный формат файла изображения

[2024-05-03 19:46:20.229] [error] Item '': No icon name or pixmap given.

** (waybar:3017): CRITICAL **: 19:46:20.229: 
unhandled exception (type Glib::Error) in signal handler:
domain: gdk-pixbuf-error-quark
code  : 3
what  : Failed to load /home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/image-missing.svg: Нераспознанный формат файла изображения

[2024-05-03 19:46:20.229] [error] Item '': No icon name or pixmap given.

** (waybar:3017): CRITICAL **: 19:46:20.229: 
unhandled exception (type Glib::Error) in signal handler:
domain: gdk-pixbuf-error-quark
code  : 3
what  : Failed to load /home/dima/.local/share/icons/Tela-circle-dark/scalable/apps/image-missing.svg: Нераспознанный формат файла изображения


(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.247: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.247: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.247: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.248: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.248: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.249: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.249: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.249: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.249: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

(waybar:3017): LIBDBUSMENU-GTK-WARNING **: 19:46:20.249: Unable to build Pixbuf from icon data: Нераспознанный формат файла изображения

Ну а в clementine просто отсутствуют иконки в контекстном меню трея.

[dimonchik]

Вопрос больше не актуален, сегодня было обновление и все опять заработало.

[yoricI]

Почему не обновляется, 3 дня такая ошибка:
# eix-sync * Running emerge --sync >>> Syncing repository 'gentoo' into '/usr/portage'... * Using keys from /usr/share/openpgp-keys/gentoo-release.asc * Refreshing keys via WKD ... [ ok ] >>> Starting rsync with rsync://rsync.ru.gentoo.org... timed out rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(713) [Receiver=3.2.7] >>> Retrying... >>> Starting retry 1 of 3 with rsync://rsync.ru.gentoo.org timed out rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(713) [Receiver=3.2.7] >>> Retrying... >>> Starting retry 2 of 3 with rsync://rsync.ru.gentoo.org timed out rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(713) [Receiver=3.2.7] >>> Retrying... >>> Starting retry 3 of 3 with rsync://rsync.ru.gentoo.org timed out rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(713) [Receiver=3.2.7] >>> Retrying... !!! Exhausted addresses for rsync.ru.gentoo.org Action: sync for repo: gentoo, returned code = 1 * emerge --sync failed * Time statistics: 70 seconds for syncing 71 seconds total
С помощью mirrorselect несколько раз менял зеркала
$ cat /etc/portage/repos.conf/gentoo.conf [DEFAULT] main-repo = gentoo [gentoo] location = /usr/portage sync-type = rsync sync-uri = rsync://rsync.ru.gentoo.org auto-sync = yes $ grep -i mirror /etc/portage/make.conf ###GENTOO_MIRRORS="http://gentoo.bloodhost.ru/ http://ftp.halifax.rwth-aachen.de/gentoo/" GENTOO_MIRRORS="https://mirror.yandex.ru/gentoo-distfiles/ \ https://gentoo-mirror.alexxy.name/ \ rsync://mirror.mephi.ru/gentoo-distfiles/" А воз и ныне тут. eix-webrsync работает

[ormorph]

Просто поменять зеркало для синхронизации, у меня /etc/portage/repos.conf/gentoo.conf такой:

Spoiler

Shell

[DEFAULT]
main-repo = gentoo

[gentoo]
location = /var/db/repos/gentoo
sync-type = rsync
#sync-uri = rsync://rsync.gentoo.org/gentoo-portage
sync-uri = rsync://rsync.ru.gentoo.org/gentoo-portage/
auto-sync = yes
sync-rsync-verify-jobs = 1
sync-rsync-verify-metamanifest = yes
sync-rsync-verify-max-age = 24
sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
sync-openpgp-keyserver = hkps://keys.gentoo.org
sync-openpgp-key-refresh-retry-count = 40
sync-openpgp-key-refresh-retry-overall-timeout = 1200
sync-openpgp-key-refresh-retry-delay-exp-base = 2
sync-openpgp-key-refresh-retry-delay-max = 60
sync-openpgp-key-refresh-retry-delay-mult = 4
sync-webrsync-verify-signature = yes

При желании можно вместо rsync установить git для скачивания дерева портов, у меня на системе с rpi4 так:

Spoiler

Shell

[DEFAULT]
main-repo = gentoo

[gentoo]

location = /var/db/repos/gentoo
sync-type = git
clone-depth = 1
sync-depth = 1
sync-uri = https://github.com/gentoo-mirror/gentoo
auto-sync = yes
sync-git-verify-commit-signature = true

[yoricI]

Просто поменять зеркало для синхронизации, у меня /etc/portage/repos.conf/gentoo.conf такой:

Было у меня подозрение, что этот mirrorselect некорректно работает, и оно подтвердилось. Первоначально просто что-то не сложилось, а потом mirrorselect усугубил. Спасибо, сейчас работает.

можно вместо rsync установить git для скачивания дерева портов,

В чём преимущества? Качает только дельты (изменения), а не всё?
Когда дельты исходников будут актуальны? Или уже никогда, в свете стомиллионовгигабитных скоростей и ёмкостей?

[ormorph]

В чём преимущества? Качает только дельты (изменения), а не всё?
Когда дельты исходников будут актуальны? Или уже никогда, в свете стомиллионовгигабитных скоростей и ёмкостей?

Преимущества в скорости загрузки, git это делает быстрее. Недостатки, зеркало для скачивания одно git. Первыми на git перешли в Funtoo, и многие пользователи Gentoo тогда говорили когда же у нас такое появится. Сейчас оно доступно в Gentoo, но не по умолчанию, это нужно делать самому.

[ormorph]

Осторожно, переход на python-3.12, много ебилдов ещё не поддерживает эту версию, а её уже вклинили по умолчанию. Теперь требуется правка в make.conf на версию 3.11, если возникают проблемы, а они скорее всего будут.

[yoricI]

Похоже, это оно, неделю назад пришло, вроде нестрашно грозят))

Python news in gentoo

$ eselect news read 70 2024-05-09-python3-12 Title Python 3.12 to become the default on 2024-06-01 Author Michał Górny <mgorny@gentoo.org> Posted 2024-05-09 Revision 1 We are planning to switch the default Python target of Gentoo systems on 2024-06-01, from Python 3.11 to Python 3.12. If you have not changed the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will have immediate effect on your system and the package manager will try to switch automatically on the next upgrade following the change. If you did change the values, prefer a safer approach or have problems with the update, read on. Please note that the default upgrade method switches packages to the new Python versions as they are rebuilt. This means that all interdependent packages have to support the new version for the upgrade to proceed, and that some programs may temporarily fail to find their dependencies throughout the upgrade (although programs that are already started are unlikely to be affected). If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared in make.conf, please remove these declarations as they will interfere with the package.use samples provided below. Using make.conf for Python targets is discouraged as it prevents package defaults from applying when necessary. This news item assumes using /etc/portage/package.use or your package manager's equivalent file for configuration. At this point, you have a few configuration options to choose from: 1. If you wish Python upgrades to apply automatically, you can remove PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations. When the defaults change, your package manager should handle the upgrade automatically. However, you may still need to run the update commands if any problems arise. 2. If you wish to defer the upgrade for the time being, you can explicitly set the old values in package.use. 3. If you wish to force the upgrade earlier, you can explicitly set the new values and run the upgrade commands. 4. If you wish to use a safer approach (i.e. less likely to temporarily break packages during the upgrade), you can perform a multi-step upgrade as outlined below. 5. Finally, you can use an arbitrary combination of PYTHON_TARGETS and PYTHON_SINGLE_TARGET. Deferring the upgrade ===================== To defer the upgrade, explicitly set the old targets: */* PYTHON_TARGETS: -* python3_11 */* PYTHON_SINGLE_TARGET: -* python3_11 This will enforce Python 3.11 and block any future updates. However, please note that this is only a temporary solution and you will eventually need to perform the migration. Forcing the upgrade =================== To force the upgrade earlier, explicitly select the Python 3.12 targets: */* PYTHON_TARGETS: -* python3_12 */* PYTHON_SINGLE_TARGET: -* python3_12 However, it is important to remember to remove this after the defaults change, as it will interfere with the automatic switch to the next Python version in the future. Safer upgrade procedure ======================= A safer approach is to add Python 3.12 support to your system first, and only then remove Python 3.11. However, note that this involves two rebuilds of all the affected packages, so it will take noticeably longer. First, enable both Python 3.11 and Python 3.12, and then run the upgrade commands: */* PYTHON_TARGETS: -* python3_11 python3_12 */* PYTHON_SINGLE_TARGET: -* python3_11 Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades: */* PYTHON_TARGETS: -* python3_11 python3_12 */* PYTHON_SINGLE_TARGET: -* python3_12 Finally, switch to the final version and upgrade: */* PYTHON_TARGETS: -* python3_12 */* PYTHON_SINGLE_TARGET: -* python3_12 You may wish to remove the target overrides after the defaults switch. Alternatively, you can keep them to block the next automatic upgrade to Python 3.13, and upgrade manually then. Upgrade commands ================ The Python 3.11 cleanup requires that Python 3.11 is removed from the complete dependency trees in batch. If some of the installed packages using an older Python version are not triaged for the upgrade, the package manager will throw dependency conflicts. This makes it important that the upgrade is carried via a --deep --changed-use @world upgrade, as well as that any stray packages are removed prior to it, e.g.: emerge --depclean emerge -1vUD @world emerge --depclean

[ormorph]

Похоже, это оно, неделю назад пришло, вроде нестрашно грозят))

Да как раз страшно, у меня сразу отказали virtualbox и devhelp. Пришлось править make.conf и прописывать python3_11 по умолчанию, на мой взгляд при переходе это довольно серьёзный косяк. Это было бы нормально если бы это сделал я, но когда это делает разработчик Gentoo, это серьёзный косяк при переходе. Тем более что не собираются стабильные пакеты.

[yoricI]

То есть по первому абзацу новости (ничего не делая ни до ни после), автоматика не сработала? Это да...

[ormorph]

То есть по первому абзацу новости (ничего не делая ни до ни после), автоматика не сработала? Это да...

Ну так само собою не все ебилды на python-3.12 переписаны, а переход уже влупили. Честно говоря такого я уже давно не видел в Gentoo. Как только кажется что стало что то лучше, а они быстро опускают на землю. Вот я и написал им, что иначе как это сделано намеренно я не вижу. Тем более что это проверяется на раз-два. Конечно резко это было, но они меня тут сильно удивили. У них пошла резкая беготня по обновлениям, так что уже добегались.