dreckhände

 Nach einem dist-upgrade von lenny zu squeeze auf meinem root server stelle ich fest, dass denyhosts nicht mehr richtig funktioniert. 
Im denyhosts.log findet sich die Zeile:

sync        : ERROR    long int exceeds XML-RPC limits

und dem folgt eine Traceback. Es ist für debian ein bekannter bug und anscheinend auch gefixt und archiviert.
"Found in version denyhosts/2.6-6. Fixed in version denyhosts/2.6-10." Na super! Squeeze kommt mit 2.6.7 und da ist es nicht gefixt. 
Stattdessen fand ich in den ubuntu-Foren einen hilfreichen Beitrag mit einer filigranen Änderung an der auch im Trackback benannten /usr/share/denyhosts/DenyHosts/sync.py :

Die hat, bei mir auf Zeile 55/56, 
fp = open(os.path.join(self.__work_dir, SYNC_TIMESTAMP), "a")     und das ändern wir (als root) in:
fp = open(os.path.join(self.__work_dir, SYNC_TIMESTAMP), "w")

Dann noch das misshandelte Timestamp resetten:

date +%s > /var/lib/denyhosts/sync-timestamp

und fertig! 

Ein seltsamer Effekt ist neuerdings aufgefallen, beim Einbinden der dm-crypt - devices liest sich das so:

cryptsetup luksOpen /dev/sdc silva
Geben Sie den Passsatz für /dev/sdc ein: 
semid 131072: semop failed for cookie 0xd4df6e3: incorrect semaphore state
Failed to set a proper state for notification semaphore identified by cookie value 223213283 (0xd4df6e3) to initialize waiting for incoming notifications.

An GoogleEarth habe ich so viele male rumgedoktert, und immer nur ein schwarzer Block da, wo die Erdkugel sein sollte. Für eine Weile hatte ich mich schon damit abgefunden, dafür eine dedizierte vm mit xp zu nehmen. Aber beim Schatzsuchen braucht man GE nun mal dauernd und als ich dann ein .deb für 64bit entdeckte, habe ich mich noch einmal darangemacht. Download, sudo dpkg -i google-earth-stable_current_amd64.deb und:?? Schwarzer Bildschirm.

Ok, also auf die Suche gemacht. Es finden sich viele Hinweise, dass lsb-core und lib32nss-mdns und ia32-libs-gtk installiert sein müssen. Sind es auch, trotzdem schwarz. Dann ein Hinweis auf sudo aptitude install nvidia-glx-ia32 - und heureka, endlich gehts.

Fein. Wäre es eigentlich zu viel verlangt, wenn Google's .deb solche Abhängigkeit prüft oder wenigstens einen Hinweis auf bekannte Problemquellen gibt? Die sind ja nun kein Fischgeschäft. Grummel.

I stumbled over this when I I had to fix a little something on an older project Flex3 and a certain part needed to get compiled by mxmlc.exe. But it wouldn't, all the path names etc. looked just fine but mxmlc wouldn't even start.  All I got was a message in the command line interface like:

Exception in thread "main" java.lang.UnsupportedClassVersionError: flex2/tools/Compiler (Unsupported major.minor version  48.0)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$100(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)

And why flex2? Google didn't help much, I found a thread in the Adobe Knowledge base with a matching description but no useful answer, the OP got the advice to edit the build.xml file but it didn't solve his problem and looking at mine it looked just fine.

It took me ages of search until I found someone mention  64 Bit difficulties: and yes, move the sdk and projekt files to a 32 bit environment in a vm and it compiles nicely.

What is it with adobe and 64 bit: no flash debug player on linux, no air runtime on linux and the mxmlc dompiler doesn't even run on 64 bit Windows.  

Nein, ich meine nicht RTL2 auf einem Breitwand-Fernseher...
Ich pendele ohnehin, was file managment angeht, auf dem Linux desktop (Debian Squeeze, KDE) zwischen grafischer Oberfläche und Terminal / mc hin- und her, aber seit einer Weile wollte Dolphin mich nun gar keine Dateien mehr löschen lassen. Stattdessen bekam ich einen Dolphin error gezeigt:
"The trash has reached its maximum size! Cleanup the trash manually. "

Dabei war der Trash in  ~/.local/share/Trash bis auf drei folder und eine Datei metadata ganz leer. Aber metadata hatte einen konfusen Eintrag, 

[Cached]
Size=18446744073517368387

Der Wert scheint nicht willkürlich zu sein,  Google findet mehrere Seiten von KDE-Nutzern, die diese Zahl bei sich vorfanden. Die Abhilfe war zum Glück einfach: metadata (von der command line) löschen und nach dem nächsten "Move to trash" hat sich dolphin korrekte Metadaten neu erzeugt.