[Gentoo] SANE wil niet, verkeerd gelinkte library's

[deepbass909]

Ik zit sinds dit weekend met een vervelend probleempje onder Gentoo, wat ik niet opgelost krijg...

Na een update van m'n systeem, wil SANE niet meer compileren, en met een wel heel opmerkelijke foutmelding...
Ik heb sane-backends-1.0.20 erop staan, maar sane-frontends klaagt dat ik minimaal 1.0.0 moet hebben (wat ik toch zeker weten heb, aangezien er 1.0.20 opstaat...). Xsane meldt dezelfde fout. Deze fout is een bekende en vaak fixed het opnieuw compileren van sane-backends dit wel, maar dus niet bij mij...
Als ik daarnaast revdep-rebuild draai, krijg ik de volgende fout:

code:

* Configuring search environment for revdep-rebuild

 * Checking reverse dependencies
 * Packages containing binaries and libraries broken by a package update
 * will be emerged.                                                     

 * Collecting system binaries and libraries
 * Found existing 1_files.rr               
 * Collecting complete LD_LIBRARY_PATH     
 * Found existing 2_ldpath.rr.             
 * Checking dynamic linking consistency    
 * Found existing 3_broken.rr.             
 * Assigning files to packages             
 *  !!! /usr/lib64/libsane.so.1.1.0 not owned by any package is broken !!!
 *   /usr/lib64/libsane.so.1.1.0 -> (none)                                
 *  !!! /usr/lib64/sane/libsane-dc210.so.1.1.0 not owned by any package is broken !!!
 *   /usr/lib64/sane/libsane-dc210.so.1.1.0 -> (none)
 *  !!! /usr/lib64/sane/libsane-dc240.so.1.1.0 not owned by any package is broken !!!
 *   /usr/lib64/sane/libsane-dc240.so.1.1.0 -> (none)
 *  !!! /usr/lib64/sane/libsane-dell1600n_net.so.1.1.0 not owned by any package is broken !!!
 *   /usr/lib64/sane/libsane-dell1600n_net.so.1.1.0 -> (none)
 *  !!! /usr/lib64/sane/libsane-gphoto2.so.1.1.0 not owned by any package is broken !!!
 *   /usr/lib64/sane/libsane-gphoto2.so.1.1.0 -> (none)
 *  !!! /usr/lib64/sane/libsane-pixma.so.1.0.19.old not owned by any package is broken !!!
 *   /usr/lib64/sane/libsane-pixma.so.1.0.19.old -> (none)
 * Generated new 4_raw.rr and 4_owners.rr
 * Found some broken files, but none of them were associated with known packages
 * Unable to proceed with automatic repairs.
 * The broken files are listed in 4_owners.rr

Het vreemde is, dat deze verkeerde library verwijzingen blijven bestaan, ook na het verwijderen van sane-backends, waar ze een onderdeel van zijn.

Er zit dus sowieso iets fout in m'n library database, alleen weet ik niet hoe ik dit moet herstellen...
Ik vermoed dat dit ook de bron van m'n problemen met de frontends is...

Wie ow wie heeft een idee?

[Rainmaker]

Verwijder die files dan even met de hand en emerge sane-backends even opnieuw.

Zijn de files waar revdep-rebuild over klaagt symlinkjes die nergens meer naartoe wijzen o.i.d.?

[deepbass909]

Dat was ook mijn eerste gedachte, maar het weghalen van de bestanden heeft geen invloed. Revdep-rebuild scant ook niet de mappen zelf, maar werkt op basis van een library-database, waar dus foute verwijzingen in staan. De bestanden zijn de werkelijke library's (te herkennen aan de getallen achter de .so).

Inmiddels wil, miraculeus, sane-frontends en xsane wel weer compileren Maar de foute verwijzingen blijven bestaan...

[Rainmaker]

Heb je ook revdep-rebuild -i gebruikt?

Ik zie namelijk: using existing ....

[laurencevde]

Eem, revdep-rebuild scant dus wel alle libs in dirs in /etc/ld.so.conf...
Maar iig, met qfile -o /usr/lib64/* kun je alle "orphaned" bestanden in lib64 zien.
Er horen er geen te zijn...

[deepbass909]

Ik ga daar vanavond eens mee aan de slag. De libs die genoemd worden, waren bij één van de vele scans zeker weten niet aanwezig in /usr/lib64, aangezien ik de volledige /usr/lib64/sane map had verplaatst naar een compleet andere locatie. Vandaar dat ik ook zeker weet dat er blijkbaar ergens een database verkeerd is...

[laurencevde]

* Found existing 1_files.rr

Ook een feature van revdep-rebuild: als er tijdens een revdep iets fout gaat, laat-ie de al gedane stappen staan, zodat ie die de volgende keer niet hoeft te doen. En als revdep klaar is, of ze ouder zijn dan een dag verwijdert revdep die temp-bestanden.
Ze worden in ~ (/root?) gezet, en beginnen met .revdep-rebuild.

[deepbass909]

Hmmz, ik heb in het verleden daar ook weleens ruzie mee gehad, maar dan was het een door mij zelf afgebroken revdep-rebuild, blijkbaar is revdep-rebuild nu iets intelligenter (of juist niet) geworden.

qfile -o /usr/lib64/* leverde wel een lijst van orphaned libs op, maar deze behoorde bij Totem, blijkbaar een restje van Gnome die er ooit op heeft gestaan.

Nu loopt revdep-rebuild -i, waar hij inderdaad weer een stuk langer over doet.

Edit:
Inmiddels heb ik alle gebroken libs gevonden die ik ook verwachte na de ingreep afgelopen weekend, namelijk libGL.la is gewijzigd en libxcb.la is vervallen en dit moest wel dingen breken. Sterker nog, na het weghalen van libxcb.la moest ik wel revdep-rebuild draaien, maar deze liep dus vast op de eerder gemelde fouten.

Gezien de lijst van pakketten (43 stuks) en de aard van de pakketten (o.a. cairo en gimp) wordt het wel een nachtje doordraaien voor m'n machine...

[ Voor 35% gewijzigd door deepbass909 op 05-10-2009 23:14 ]

[Rainmaker]

laurencevde schreef op maandag 05 oktober 2009 @ 22:32:
[...]

Ze worden in ~ (/root?) gezet, en beginnen met .revdep-rebuild.

Al een tijdje niet meer. Sinds een paar versies staan de files in /var/cache/revdep-rebuild. Vandaar dat ik mezelf ondertussen heb aangeleerd altijd -i te gebruiken:

code:

  -i, --ignore         Ignore temporary files from previous runs

[ Voor 21% gewijzigd door Rainmaker op 05-10-2009 23:45 ]

[deepbass909]

@Rainmaker
Dat moet ik mezelf dus ook aanleren.
Revdep-rebuild is trouwens ook nog verre van perfect. Gisteren kreeg ik dus 43 pakketten te zien die opnieuw gecompileerd moesten worden, vanwege hun link met libGL.so. Alleen lagen de problemen niet in deze pakketten, maar in libGL.so zelf. Deze wordt namelijk dynamisch gelinkt aan de videokaart library's, doormiddel van eselect opengl, en blijkbaar was deze link gebroken. Opnieuw m'n opengl instellen, en alles was opgelost.