(gentoo) Не собирается dev-perl/Pango-1.223.0 . Пишет, что не файл не найден, хотя файл есть и права есть

Честно сказать, причины ошибки я не понимаю, но попробуйте revdep-rebuild. Хуже, во всяком случае, не будет.

Попробую применить телепатию и порекомендую unset path.

sys-fs/udev пересобери потом dev-perl/Cairo

revdep-rebuild не помог.

А как оно может влиять? Тут же абсолютный путь, а не относительный.

Пересобираю весь мир с -a -D --use-new, через несколько часов будет видно.

А куда правильнее такие вопросы задавать для быстрого получения ответа? В bugs.gentoo.org или там слоупоки? Или на англоязычный форум генты? Вы сами где сидите?

а чёрт его знает...
я в лороконфе и gentoo@c.j.r

-aDN для пересборки маловато будет

сорри, eDN

perl-cleaner --reallyall уже прогонял?

Полная пересборка мира проблемы не решила.

ln -s /usr/lib/libudev.so /usr/lib/libudev.so.0 Проблему решила.

Почему-то последний sys-fs/udev создаёт только /usr/lib/libudev.so , /usr/lib/libudev.so.1 , /usr/lib/libudev.so.1.1.0 а вот нужного /usr/lib/libudev.so.0 не создаёт.

Кому писать, чтобы профиксили?

создавай баг на багзилле, не забудь упомянуть версии dev-perl/Pango и sys-fs/udev. Ссылку сюда - я баг побыстрее распределю кому надо

похоже 64-проблемы:

qlist sys-fs/udev | grep libudev.so
/usr/lib/libudev.so.1.1.0
/usr/lib/libudev.so
/usr/lib/libudev.so.1

...
Installing 	[5 of 5]	dev-perl/Pango-1.223.0

Почему-то последний sys-fs/udev создаёт только /usr/lib/libudev.so , /usr/lib/libudev.so.1 , /usr/lib/libudev.so.1.1.0 а вот нужного /usr/lib/libudev.so.0 не создаёт.

libfoo.so.0 и libfoo.so.1 — это такое соглашение об именовании версий библиотек. Вообще говоря, libfoo.so.X и libfoo.so.Y бинарно несовместимы друг с другом. Делать симлинк — плохо, неправильно и обязательно приведет к сегфолтам.

И если у тебя свежий portage, то после апгрейда udev'а он тебе прямо так и напишет: «не буду удалять libudev.so.0, потому что он нужен таким-то бинарникам».

А /usr/lib/libudev.so.0 у тебя точно нету? Если есть, то его md5 отлична от /usr/lib/libudev.so.1 ?

Получается, что мне нужно поставить стабильный udev, проверить наличие /usr/lib/libudev.so.1, после чего поставить testing udev?

Тебе всего лишь надо пересобрать то, что советует сам emerge.

точно нет

lrwxrwxrwx 1 root 0  16 авг.  25 00:33 /usr/lib/libudev.so -> libudev.so.1.1.0
lrwxrwxrwx 1 root 0  16 авг.  25 00:33 /usr/lib/libudev.so.1 -> libudev.so.1.1.0
-rwxr-xr-x 1 root 0 67K авг.  25 00:33 /usr/lib/libudev.so.1.1.0

А в lib64? Все пакеты из тестинг-ветки?

x86
потому кроме lib ничего нет
вся ветка тестинг, да

x86

http://www.yrodu.ru/uploads/posts/2009-02/1233744066_2.jpg

вся ветка тестинг, да

Странно. Пока решилось замаскировыванием ~amd64 udev.

завидуй молча :3
ибо на 32 всё отлично работает, в отличии от

Лорчую аватарку.

Сорри, что так долго:
https://bugs.gentoo.org/show_bug.cgi?id=434034

https://bugs.gentoo.org/show_bug.cgi?id=434034

Тебе всего лишь надо пересобрать то, что советует сам emerge.

Это что ли? Не помогает, вестимо.
emerge -a --oneshot `equery d udev | awk '{print " =«$1}'`

https://bugs.gentoo.org/show_bug.cgi?id=434034

Лорчую аватарку.

А что в ней такого?

Незнаю. Нравится, чо.

1. ща тебе скажут оформить в английской локали
2. жду x86 товарищей

отпишись, что revdep-rebuild не помог, я баг снова открою, а то jer его уже закрыл :-)

1. ща тебе скажут оформить в английской локали
я не заметил, но ничего не сказали.
2. жду x86 товарищей
http://www.mk.ru/upload/iblock_mk/475/3c/a7/b8/DETAIL_PICTURE_682525_73287600...

ты неадекватен, прощай

отпишись, что revdep-rebuild не помог, я баг снова открою, а то jer его уже закрыл :-)

Самое смешное, что revdep-rebuild помог. :) Просто я раньше его запускал, когда 171-r6 был установлен, а не 186. Теперь понимаю, как им правильно пользоваться.

Эм, прошу прощение, если ты столь очевидные замечания по поводу использования устаревших архитектур так близко к сердцу воспринимаешь.

если поставишь портаж 2.2 или FEATURES=«preserved-rebuild» то такие проблемы будут исключены, поскольку там он будет сам следить за теми какие либы используются и не давать удалять ещё используемые и создаст виртуальный сет для тех прог, которые надо пересобрать.

Эм, а это нормально, что 2.2 вообще красным отмечен в eix? :) Какую лучше ставить версию, чтобы особо багов самом портаже не повылезало?

последняя <9999. Баги если и бывают, то весьма хитрые и обычный пользователь их не видит, а в основном там новые фичи, главное обновляться, а об этом портаж и сам напомнит.

#ifdef очень_большой_секрет 2.2 юзабельная очень давно, но если он будет ~ то со стейбла все точно поперелезают. #endif

а это нормально, что 2.2 вообще красным отмечен в eix?

qnikst выше всё правильно сказал - 3 года как полет нормальный на 2.2(сейчас у меня стоит sys-apps/portage-2.2.0_alpha124). На серверах правда держу stable-версию, но там и пакетов меньше, кое-что можно и вручную разгрести. На десктопе с моими экспериментами я бы точно себе что-нибудь отстрелил без preserve-libs :-)

Ты меня заигнорил?

Теперь проблема в том, что dev-perl/gnome2-gconf-1.44.0 собирается только c gnome-base/gconf-2.32.4, а 3.2.5 вываливает:
Can't load 'blib/arch/auto/Gnome2/GConf/GConf.so' for module Gnome2::GConf: blib/arch/auto/Gnome2/GConf/GConf.so: undefined symbol: gconf_engine_key_is_writable at /usr/lib64/perl5/5.16.1/x86_64-linux/DynaLoader.pm line 190.

Не может быть такого, что gnome2-gconf вообще не работает (а не у меня лично) с третьегномовским gconf?

Ну, написано же: libudev.so.0. udev небось обновил.

если пакет gconf имеет слоты(не могу сейчас проверить), то скорее всего да

Ну, написано же: libudev.so.0. udev небось обновил.

При unmasked ~amd64 сейчас libudev.so.1. В начале я сделал просто symlink для сборки, потом удалил symlink и запустил revdep-rebuild. Вот так починилося, вот она ваша гента.

dev-perl/gnome2-gconf-1.44.0 собирается с gnome-base/gconf-3.2.5, во всяком случае у меня. Могу посоветовать опять perl-cleaner --all и revdep-rebuild, если портаж всё ещё не новый, после этого можно будет разбираться дальше.

perl-cleaner --all и revdep-rebuild пишут, что всё отлично. Что делать? :3

И да: в случае автоматической заботы portage об отсутствии автоудаления нужных библиотек, revdep-rebuild не будет видеть проблем, верно? А хотелось бы, что видел и можно было пересобрать, чтобы в будущем проблем с этим пакетами не было.

надо подумать, может что придумаю, а может и @Pinkbyte попозже появится, что полезное скажет.

про новый emerge:

a). revdep-rebuild будет видеть проблемы

б). revdep-rebuild будет не нужен, т.к. emerge как только появляются проблемы будет настойчиво предлагать прогнать emerge @preserved-rebuild, который все проблемы пофиксит.

так у тебя перл новее, щас обновлю его проверю.

И как? :)

после perl-cleaner --all всё отработало успешно:

perl 5.16.1, gnome2-gconf 1.44.0, gconf 3.2.5.

в /usr/lib64/perl5/vendor_perl/5.16.1/x86_64-linux/auto/Gnome2/GConf/GConf.so есть нужные символы (gconf_engine_key_is_writable), в особенностях перла не шарю, поэтому если perl-cleaner и revdep-rebuild не спасают (и не выдают ошибок), то советую запостить баг на багзиллу.