gentoo заскоки

[devilr]

Нет, у меня это отдельные каталоги, с разным содержимым.

Я уже написал, что профиль не углядел. Просто удалять не стал, чтобы написанное пером топором не вырубать.
Заработало хоть?

[yoricI]

Заработало вроде. Но почему оно не подхватывает нвидиевый модуль со своего места, а Х-овый подхватывает?

[ormorph]

Но почему оно не подхватывает нвидиевый модуль со своего места, а Х-овый подхватывает?

Ну а в каталоге, что прописывали:

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

ModulePath "/usr/lib64/extensions/nvidia"

Библиотека libglx.so.xxx имела ссылку в этом же каталоге libglx.so? Обычно xorg именно библиотеку с таким названием ищет.

[devilr]

А зачем делать ссылку? У меня /usr/lib64/xorg/modules/extensions/libglx.so вполне таки файл и появляется штатно. Может с флагами что напутали?

[ormorph]

А зачем делать ссылку? У меня /usr/lib64/xorg/modules/extensions/libglx.so вполне таки файл и появляется штатно. Может с флагами что напутали?

Может и так, а может ещё что, но судя по логу xorg не находил модуль, а следовательно вполне возможно что файл с таким названием отсутствовал в каталоге /usr/lib64/extensions/nvidia
Хотя так же вполне возможно из за того что модуль xorg загружался вперёд, а следовательно драйвер nviiva это допускает.

[yoricI]

Библиотека libglx.so.xxx имела ссылку в этом же каталоге libglx.so?

$ ls -l /usr/lib64/extensions/nvidia/ total 14628 lrwxrwxrwx 1 root root 17 авг 20 23:11 libglx.so -> libglx.so.390.138 -rwxr-xr-x 1 root root 14976296 авг 20 23:11 libglx.so.390.138

/usr/lib64/xorg/modules/extensions/libglx.so

У меня тоже. Но

odulePath "/usr/lib64/extensions/nvidia"

это другое, там см. выше, тоже всё как надо. А оно не хочет. И это до первого обновления-пересборки.

файл с таким названием отсутствовал в каталоге /usr/lib64/extensions/nvidia

Нет, см. выше.

[yoricI]

Так это баг или не баг?

[yoricI]

Похоже, работы ведутся, nvidia-drivers обновился на три версии, кое-какие пути из обсуждённых прописаны, но всё равно не работает без подмены ссылки :-)

[yoricI]

Когда ж починят это дело? Достало уже, с каждым обновлением mesa вручную ссылку делать. Можно куда-то прилепить скрипт, на автоматическое создание /usr/lib64/xorg/modules/extensions/libglx.so -> ../../../extensions/nvidia/libglx.so.390.141?

[yoricI]

Что это за? Это не ошибка? Пролазит и пролазит этот системД тихой сапой. И ладно бы в сторонних пакетах, в том числе и под него рассчитанных, а тут системный. У меня глобально "USE -systemd"

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

[ebuild  N] sys-apps/systemd-tmpfiles-246::gentoo  USE="(-selinux) -test" 9 311 KiB
[uninstall] sys-apps/opentmpfiles-0.2::gentoo  USE="(-selinux)" 
[blocks b] sys-apps/opentmpfiles ("sys-apps/opentmpfiles" is blocking sys-apps/systemd-tmpfiles-246)

Очень странно, OpenRC утилиту выкидывать, а системд вставлять, когда стоит OpenRC

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

Package Metadata
    Upstream
    Remote-Id 	https://github.com/openrc/opentmpfiles
    License    BSD-2
    Maintainer(s)    William Hubbs ,  Gentoo OpenRC Team

А если замаскировать sys-apps/systemd-tmpfiles? Против системы не попрёшь?

[ormorph]

Флаг elogind включён?
А так посмотрите зависимости, для каких пакетов требуется данный пакет systemd...
Может какой нестабильный ебилд.

[yoricI]

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

 grep -r systemd /etc/portage/*
/etc/portage/make.conf:-systemd -consolekit -elogind -infiniband smp -lirc -pda -cddb \

Хм, странно, почему-то он замаскировался... Вот замена и подтянулась...

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

eix sys-apps/opentmpfiles
[?] sys-apps/opentmpfiles
     Available versions:  [M]0.1.1 [M]0.1.2 [M]0.1.3 [M]~0.1.3-r1 [M]0.2 {selinux}
     Installed versions:  0.2(18:13:37 25.11.2018)(-selinux)

[bars]

Хм, странно, почему-то он замаскировался... Вот замена и подтянулась...

Те же яйца.
Вчера обновился.

[yoricI]

А вот почему:

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

grep -r opentmp /usr/portage/profiles/*
base/package.mask:sys-apps/opentmpfiles

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

# Andreas K. Hüttel <dilfridge@gentoo.org> (06.07.2021)
# Root privilege escalation, CVE-2017-18925, bug 751415
sys-apps/opentmpfiles

[Bizdelnick]

CVE-2017-18925, bug 751415

Почитал. Какой-то сюр начиная с того, зачем вообще понадобился этот tmpfiles.d. И не увидел способа эксплуатации, не имея рута.

[bars]

sys-apps/opentmpfiles

Пока размаскировывать не буду.
По пользуюсь /systemd-tmpfiles-246.

[ormorph]

По пользуюсь /systemd-tmpfiles-246.

Ну и не надо, этот пакет работает с openrc, а не с systemd.

[bars]

systemd

название как то не в тему тогда, если используешь openrc.

[ormorph]

название как то не в тему тогда, если используешь openrc.

Не совсем так, просто тут собирается один из бинарников из исходника systemd, и для его запуска добавляется init скрипт для openrc. Просто вытащили часть systemd для запуска в openrc, от сюда и название такое.

[yoricI]

Похоже шторм подняли, пришлось запоздалую новость сочинять))

"Despite the name, 'systemd-tmpfiles' does not depend on systemd, does not use dbus, and is just a drop-in replacement for opentmpfiles. It is a small binary built from systemd source code, but works separately, similarly to eudev or elogind. It is known to work on both glibc and musl systems."

[yoricI]

А что мешает сделать работу с зависимостями более интеллектуальной, то есть, например, если я установил пакет pkg-meta как экспериментальный ~amd64, то и зависимости pkg-lib & pkg-util и ещё 256 штук встали как ~, без дополнительного их персонального прописывания в keywords? Желание на ~amd64 выражено, так чего стесняться?

[yoricI]

Когда ж починят это дело? Достало уже, с каждым обновлением mesa вручную ссылку делать. Можно куда-то прилепить скрипт, на автоматическое создание /usr/lib64/xorg/modules/extensions/libglx.so -> ../../../extensions/nvidia/libglx.so.390.141?

А всего-то дело было в порядке строк в файле /etc/X11/xorg.conf.d/20opengl.conf

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

Section "Files"
ModulePath "/usr/lib64/extensions/nvidia"
ModulePath "/usr/lib64/xorg/modules"
EndSection

Выдвинув вперёд строку nvidia, заработало без лишних движений.

Дай думаю проверю, чей это файл:
globus@aspera ~ $ equery b /etc/X11/xorg.conf.d/20opengl.conf * Searching for /etc/X11/xorg.conf.d/20opengl.conf ... globus@aspera ~ $
А ничей! Ох, бичей на Руси, ох бичей...

[yoricI]

Чего ему надо? Удаление установленного dev-python/docutils-0.17 ен помогло, больше ничего в голову не идёт.

docutils-truble.jpg

[ormorph]

Чего ему надо? Удаление установленного dev-python/docutils-0.17 ен помогло

Ну а что ещё надо? Все же собирается, выскакивает только варнинг, что не может установить более новую версию dev-python/docutils, так как более новая версия конфликтует с ебилдами dev-python/sphinx и dev-python/sphinx_rtd_theme. Просто придется использовать более старую версию dev-python/docutils-0.17, а на сборку то не особо влияет.

[yoricI]

Бывает затянешь так, а потом совсем колом встанет)) Это когда не совсем понятно. Вот там почему стрелочками на phyton-3.10 указывает?

[/dev/random]

Вот там почему стрелочками на phyton-3.10 указывает?

Он не на питон указывает. Это просто в терминале в одну строку всё не уместилось. Маленькие стрелки указывают на "<", а большие - на "0.18".

[yoricI]

А почему в llvm насильно впихнуты чуждые мне архитектуры, можно как-то отключить? У меня amd64, вроде как MIPS AVR и прочие RISC не по моей теме?

llvm-big.jpg

[/dev/random]

А почему в llvm насильно впихнуты чуждые мне архитектуры, можно как-то отключить? У меня amd64, вроде как MIPS AVR и прочие RISC не по моей теме?
llvm-big.jpg

# Michał Górny <email> (2021-11-04)
# Enable all LLVM targets unconditionally. Unfortunately, disabling
# targets tend to break reverse dependencies (e.g. Rust) and we are yet
# to find a clean way of resolving that. Compared to the damage
# potential, the increase of build time is a minor problem. Users who
# really insist of building a smaller system can un-force the flags
# at their own responsibility.

[yoricI]

Доходчиво, спасибо))

[bars]

Доходчиво, спасибо))

Что за обратная зависимость rust?
Сейчас только заметил, что куча не нужных архитектeр компилится в llvm.