checking for /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/as... /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/as checking version of /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/as... 2.20.1.20100303, bad checking for /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld... /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld checking version of /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld... 2.20.1.20100303, bad ... *** These critical programs are missing or too old: as ld *** Check the INSTALL file for required versions.
Irgendwie überkamen mich da leichte Zweifel das eine Version, die Monate jünger ist als die glibc, zu alt sein soll. Oder hat da jemand beim Prüfen der Versionsnummer nicht mit 4-teiligen Angaben gerechnet? Was auch immer ich erwartet habe, es kam noch schlimmer:
echo $ECHO_N "checking version of $AS... $ECHO_C" >&6; }
ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* \([0-9]*\.[0-9.]*\).*$//p'`
case $ac_prog_version in
'') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
2.1[3-9]*)
ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
*) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
]]>Westerwelle: 2011 wird erste Provinz an Afghanen übergeben. Eigentlich kann er das jetzt schon haben. Denn er hat nicht gesagt das er es an die afghanische Regierung übergibt. Und selbst wenn er das tut: die Warlords gewinnen sowieso. Die regieren auch jetzt selbst unter den Augen der NATO. Insofern kann er auch bei einem sofortigen Abzug die Provinzen an die Afghanen übergeben. Nur halt an andere. ]]>
My workaround was always to revert my libphonon to the version shipped in openSuSE 11.2 as this did not show the problem. But now I can't do this anymore since KDE 4.5 requires a newer phonon for development. Since I have some bugs to fix I decided to look into this.
For reference I take a copy of libphonon.so.4.3.0 which worked for me until now. A short look showed that this symbol is not mentioned anywhere within this library. Now let's look into the current one:
$ nm -D /usr/lib/libphonon.so.4.4.0 | grep pa_ext U pa_ext_device_manager_read U pa_ext_device_manager_reorder_devices_for_role U pa_ext_device_manager_set_subscribe_cb U pa_ext_device_manager_subscribe
What does this show? In the dynamic symbols of that library there are unresolved references to pa_ext_something. Ok, let's do some shell magic: scan all libraries libphonon.so.4.4.0 links against and look if they have something that would resolve this:
$ for i in $(ldd /usr/lib/libphonon.so.4.4.0 | sed 's/.*=> //;s/ (0x[a-f0-9]*)$//'); do nm -D $i | grep pa_ext && echo $i; done 00011710 T pa_ext_stream_restore_delete 000112b0 T pa_ext_stream_restore_read 00010f60 T pa_ext_stream_restore_set_subscribe_cb 00011070 T pa_ext_stream_restore_subscribe 000114e0 T pa_ext_stream_restore_test 00011a00 T pa_ext_stream_restore_write /usr/lib/libpulse.so.0
Ok, this shows that other pa_ext_* symbols are coming from libpulse.so.0, but not the ones we need. Since this is the only libpulse package I find in any repositories I have I'm locked here.
So what happens? If I read an older message by Harald Fernengel correctly the package was build using a pulseaudio version with device manager extensions. But that version is not shipped in the same repository (which is a bug IMHO). At runtime I don't have this symbols around as the only versions I have seem to miss that extension. Seems to be a problem not only openSuSE faces.
]]>
Hörer des ältesten Kulturmagazins der Welt werden Onkel Hotte kennen und lieben. Deutschlands derzeitige Lieblingssängerin kommt auch aus Hannover, aber sie assoziiert wohl jemand anderen als das Original. Und der Inhaber des Kompromatkoffer denkt sich jetzt wohl auch: "abgesägt, gut getan".
]]>And for those who want to know why it's called "CAFF" mode: there is a perl script caff in the package signing-party that does basically the same. But that script has some drawbacks, e.g. it wants to send all your mail with your local sendmail. While this might be handy with a one-person workstation this sucks when it comes to laptops (where you often don't have a proper local MDA set up) or even non-Un*x hosts (think of KDE on Windows). Since that script always annoyed me in one or the other way I couldn't let it go because it is just too useful. So now KGpg can do the same work hopefully for me and use my usual mail setup. Whoa! ;)
So everyone who wants to know how this key signing stuff is intended to work please have a look at the docs I've written and tell me if this is understandable. Improvements always welcome.
]]>Wie auch immer, in den letzten Tagen habe ich ein Testsystem installiert, auf dem neben einem XP32 und Win7-64 zwei openSuSE 11.2 ihren Platz fanden, nämlich jeweils ein mal in 32 und 64 Bit. Interessanter weise wird der Dual-Boot-Betrieb mit Windows automatisch eingerichtet und funktioniert ohne jede Beanstandung. Eine parallele Installation von 2 SuSEn ist jedoch nicht möglich: die Kerneldateien heißen für 32 und 64 Bit gleich und überschreiben sich gegenseitig...
Ich habe mir dann damit geholfen das ich dem 32 Bit-System schlicht einen selbstgebackenen Kernel 2.6.34 verpasst habe, das macht den Testraum auch etwas breiter. Aber peinlich finde ich das schon.
]]>So this is some basic technical stuff, includes collecting things from different RfCs, getting the implementation right etc., or to make a long story short: somethings that deserves my attraction ;) The other, simpler, but much more unlikely way to get my attention to such a problem would be some money (just in case *g*). Ok, anyway, the good news is: the current trunk is the best browser in this tests. Here is how the results would look like with the current trunk (previous results shamelessly stolen from the original site). I hope I can backport some or all of these fixes to 4.4.0 or 4.4.1.
| Test Case | Konqueror 4.3.1 | Konqueror trunk (r1075763) | |
|---|---|---|---|
| Summary |
|
| |
| Content-Disposition: Disposition-Type Inline | inlonly | pass | pass |
| inlwithasciifilename | pass (filename information not used) | pass (filename information not always used) | |
| inlwithasciifilenamepdf | pass (filename information not used) | pass (filename information used) | |
| Content-Disposition: Disposition-Type Attachment | attonly | pass | pass |
| attonlyucase | fail | pass | |
| attwithasciifilename | pass | pass | |
| attwithasciifnescapedchar | pass | pass | |
| attwithfilenameandextparam | pass | pass | |
| attwithasciifilenameucase | fail (filename parameter is ignored) | pass | |
| attwithasciifilenamenq | warn (accepts the unquoted value) | warn (accepts the unquoted value) | |
| attwithisofnplain | pass | pass | |
| attwithutf8fnplain | pass | pass | |
| attwithfnrawpctenca | pass | pass | |
| attwithfnrawpctenclong | pass | pass | |
| attwithasciifilenamews1 | pass | pass | |
| attwithasciifilenamews2 | pass | pass | |
| Content-Disposition: Additional Parameters | attcdate | unsupported (seems to ignore the parameter) | unsupported (seems to ignore the parameter) |
| attmdate | unsupported (seems to ignore the parameter) | unsupported (seems to ignore the parameter) | |
| Content-Disposition: Disposition-Type Extension | dispext | fail (does not treat it as 'attachment') | pass |
| RFC2231 Encoding: Character Sets | attwithisofn2231iso | unsupported | pass |
| attwithfn2231utf8 | unsupported | pass | |
| attwithfn2231noc | unsupported | pass | |
| attwithfn2231utf8comp | unsupported | pass | |
| attwithfn2231utf8-bad | unsupported | warn (displays the raw octet sequence as if it was ISO-8859-1) | |
| attwithfn2231ws1 | unsupported | pass | |
| attwithfn2231ws2 | unsupported | pass | |
| attwithfn2231ws3 | unsupported | pass | |
| attwithfn2231quot | unsupported | pass | |
| attwithfn2231encmissing | unsupported | pass | |
| RFC2231 Encoding: Continuations | attfncont | unsupported | pass |
| attfncontenc | unsupported | pass | |
| attfncontlz | unsupported | pass | |
| attfncontnc | unsupported | pass | |
| attfnconts1 | unsupported | pass | |
| attfncontord | unsupported | pass | |
| RFC2231 Encoding: Fallback Behaviour | attfnboth | pass (picks the traditionally encoded value -- the one it understands) | pass (picks the RFC2231 encoded value) |
| attfnboth2 | pass (picks the traditionally encoded value -- the one it understands) | pass (picks the RFC2231 encoded value) | |
| RFC2047 Encoding | attrfc2047token | fail (decodes it anyway to "foo-ä.html") | pass |
| attrfc2047quoted | fail (decodes it anyway to "foo-ä.html") | pass | |
Update: the attwithfn2231noc testcase was added after I mentioned that particular unclarity.
]]>