Wenn scribus unter gentoo bei der Auswahl der Bilddatei für einen Rahmen sich freundlich mit signal #11 verabschiedet, kann das ggf. mit einem remerge behoben werden.
Die Symptome bei mir im Detail:
Backtrace:
[plain]#0 0xb758b6df in jpeg_CreateDecompress () from /usr/lib/libjpeg.so.62
#1 0xb7b1c2ba in read_jpeg_image () from /usr/qt/3/lib/libqt-mt.so.3
#2 0xb7859e77 in QImageIO::read () from /usr/qt/3/lib/libqt-mt.so.3
#3 0xb785a03e in QImage::loadFromData () from /usr/qt/3/lib/libqt-mt.so.3
#4 0x08221384 in ExifData::ProcessExifDir ()
#5 0x08221ad7 in ExifData::ProcessExifDir ()
#6 0x08221c4e in ExifData::process_EXIF () […][/plain]
Dabei scheint die Datei /usr/lib/libjpeg.so.62 Probleme zu bereiten. Ein
[plain]# equery belongs /usr/lib/libjpeg.so.62 [ Searching for file(s) /usr/lib/libjpeg.so.62 in *… ]
media-libs/jpeg-7 (/usr/lib/libjpeg.so.62)
media-libs/jpeg-compat-6b-r1 (/usr/lib/libjpeg.so.62)[/plain]
führt direkt zu
[plain]# emerge -av media-libs/jpeg[/plain]
Augenscheinlich ist das dann aber noch der Weisheit letzter Schluss, denn
[plain]$ scribus
scribus: error while loading shared libraries: libjpeg.so.62: cannot open shared object file:
No such file or directory[/plain]
hält dann immernoch von der Arbeit ab. revdep-rebuild sollte dann aber scribus mit aufführen. Andernfalls muss scribus per Hand neu emerge’d werden:
[plain]emerge –oneshot app-office/scribus[/plain]