- Linux - LUG OWL

Abhängigkeiten unter Debian z.B. als Baum darstellen?
by Stefan U. Hegner 16 Okt '09

16 Okt '09

Hi Liste, gibt's bei Debian unter apt etc. auch sowas wie die -t option bei Gentoos emerge? Will grad' ein dist-upgrade auf einem chroot machen und soll dabei ein halbes Gnome installieren. - Wie finde ich raus, woran es liegt, damit ich um die ~80 unerwünschten neu zu installierenden Pakete herumkomme? Unter Gentoo sieht das in etwa so aus: foo-bar + lib-foo-bar + lib-foo-bar-dev + foo-bar-devtools + bar-headers | + whiskey-bar | + djinanntonyks + bar-keeper usw. - So was gibt es doch sicher auch unter Debian, oder? Ich vermute, ich brauche nur ein oder zwei Pakete entfernen, und schon bin ich mein halbes Gnome aus dem dist-upgrade los ... nur die finden muss ich die erst. Gruß Stefan. -- Stefan U. Hegner <stefan(a)hegner-online.de> * * * D-32584 Löhne --- good ole Germany internet: http://www.hegner-web.de * * * GPG-Key | D9DB 51BD 2DA6 9B3A 41CB F-Print | 0287 05A1 8D11 38BA CE91

4 6

Re: X verweigert hohe Aufl?sung
by Hubert Drecker 16 Okt '09

16 Okt '09

Tag, >(II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. >(II) RADEON(0): I2C device "VGA-0:ddc2" removed. >(II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. >(II) RADEON(0): I2C device "VGA-0:ddc2" removed. >(II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. >(II) RADEON(0): I2C device "VGA-0:ddc2" removed. >(II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 ddc versucht 3x den Monitor automag. zu bestimmen und schlägt fehl. >(II) RADEON(0): Found color CRT connected to primary DAC >in RADEONProbeOutputModes also wird defaultmäßig eine Kathodenröhre zum Ausstrahlen angenommen. >Apropos: Kann das in diesem Falle Stress machen, dass eine KVMoverCat5 >Box zwischen Box und Monitor h?ngt? - Wie gesagt, beim alten xorg.conf >Setup unter Etch war das kein Thema. Wäre ja mal einen Versuch wert ohne auszukommen. Kommuniziert ddc in der jetzigen Version mit KVM anstatt mit dem Monitor? Die automag. Monitorerkennung lässt sich mit folgender Zeile ausschalten: Option "NoDDC" Wenn das das Problem löst, könntest du folgendem Bug zustimmen: https://bugs.freedesktop.org/show_bug.cgi?id=3779 Voten kann man auf den ersten Blick jedoch nicht dafür... Ansonsten wäre auch die xorg.conf interessant... Gruß hubert

3 2

Re: Linux Digest, Vol 78, Issue 14
by Hubert Drecker 15 Okt '09

15 Okt '09

Hi, hattest die Option wohl auch schon gefunden... Unter http://www.x.org/wiki/Server14Branch lassen sich noch zwei Patches für radeon in der Richtung finden. Gruß hubert

1 0

X verweigert hohe Auflösung
by Stefan -Hegi- Hegner 15 Okt '09

15 Okt '09

Moin, bin grad dabei meine Kisten von Etch auf Lenny zu ziehen. Was mich total irritiert: Auf einer Box lief vorher problemlos eine Auflösung von 1680x1050. Jetzt fährt X mit 1280x768 hoch. - Und das obwohl dieser Mode gar nicht in der xorg.conf drin steht. Dabei habe ich an der xorg.conf gar nichts gedreht (wollte dpkg auch nicht anpassen). KDE bietet mir darüber hinaus ein paar recht merkwürdige Modi an, aber da ist nichts dabei, was auch nur ansatzweise an die 1680x1050 kommt. Habe jetzt ein paar Dinge an der xorg.conf probiert: Vesa-Treiber, andere Auflösungen, Modelines. Aber weiter bringen tut mich das nicht. Mag' mir wer einen Tipp geben, wie ich wieder an eine akzeptable Auflösung komme (putzig ist, dass auf der andern Kiste nach dem lenny-upgrade die 1400x1050 ootb funktionierten)? Bin dankbar für jeden Hinweis. MfG Stefan. -- Stefan U. Hegner <stefan(a)hegner-online.de> * * * D-32584 Löhne --- good ole Germany internet: http://www.hegner-web.de * * * GPG-Key | D9DB 51BD 2DA6 9B3A 41CB F-Print | 0287 05A1 8D11 38BA CE91

6 8

Re: X verweigert hohe Aufl?sung
by Hubert Drecker 14 Okt '09

14 Okt '09

Tag, >(II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. >(II) RADEON(0): I2C device "VGA-0:ddc2" removed. >(II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. >(II) RADEON(0): I2C device "VGA-0:ddc2" removed. >(II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. >(II) RADEON(0): I2C device "VGA-0:ddc2" removed. >(II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 ddc versucht 3x den Monitor automag. zu bestimmen und schlägt fehl. >(II) RADEON(0): Found color CRT connected to primary DAC >in RADEONProbeOutputModes also wird defaultmäßig eine Kathodenröhre zum Ausstrahlen angenommen. >Apropos: Kann das in diesem Falle Stress machen, dass eine KVMoverCat5 >Box zwischen Box und Monitor h?ngt? - Wie gesagt, beim alten xorg.conf >Setup unter Etch war das kein Thema. Wäre ja mal einen Versuch wert ohne auszukommen. Kommuniziert ddc in der jetzigen Version mit KVM anstatt mit dem Monitor? Die automag. Monitorerkennung lässt sich mit folgender Zeile ausschalten: Option "NoDDC" Wenn das das Problem löst, könntest du folgendem Bug zustimmen: https://bugs.freedesktop.org/show_bug.cgi?id=3779 Voten kann man auf den ersten Blick jedoch nicht dafür... Ansonsten wäre auch die xorg.conf interessant... Gruß hubert

1 0

Re: Virtuelle Windowsapplicationen
by Pierre Bernhardt 13 Okt '09

13 Okt '09

Chris schrieb: > Hallo, > ich betreue ein Debian Netzwerk in dem nicht nur die Server auf Debian > laufen sondern auch die Clients. > Allerdings gibt es ein paar Anwendungsprogramme die nur unter Windows > laufen, unter Wine habe ich Sie nicht zu laufen gebracht. Gibt es die > Möglichkeit auf einen WinXP-Rechner diese Anwendung laufen zu lassen > und Sie direkt auf den Linux-Pc zu bringen bzw. weiterzureichen. Ich > meine jetzt nicht die Möglichkeit, sich per RDP auf diesem Rechner > anzumelden sondern nur die einzelne Applikation auf den Linuxclient zu > bringen. Hmm, also ich weiss das eine der vielen virtuellen Maschinen so angepasst werden kann, dass jede Windows Applikation sich als Fenster unter dem lokalen KDE, Gnome was auch immer zeigt. Es war irgend ein Heft mit Tests von Virtuellen Maschinen unter Linux (VMWare, XEN, KVM, QEMU,...) Ich weiss nur nicht mehr welche das war. Auf jedenfall benötigst Du dafür eine Windowslizenz, da das Betriebssystem in der virtuellen Maschine installiert sein muss. MfG... Pierre

3 2

blank page detection nach dem scannen
by Florian Lohoff 11 Okt '09

11 Okt '09

Hi, nachdem ich mit Sane und einen kleinen selbstgebastelten daemon meinen scanner am laufen habe d.h. auf knopdruck das gesamte dokument mit scanadf durchgezogen und in ein PDF gewandelt wird habe ich nun das problem das ich gerne leere seiten eliminieren wuerde. Der scanner kann duplex scannen und je nach function macht der das auch - nur ist oftmals der letzte ruecken oder so leer und den wuerde ich gerne im resultierenden pdf eliminieren. Derzeitiger workflow: Nach dem erfolgreichen scan wird dieses script aufgerufen was dann die scans erst mit unpaper nen bischen aufraeumt und dann mit tiff2cp und tiff2pdf in ein pdf wandelt: TMPDIR=$1 unpaper=/usr/bin/unpaper pnmtotiff=/usr/bin/pnmtotiff tiffcp=/usr/bin/tiffcp tiff2pdf=/usr/bin/tiff2pdf set -x OUTPUT=~/Desktop/scan-`date +%Y%m%d%H%M%S`.pdf ${unpaper} -v --layout none ${TMPDIR}/scan-%d.pnm ${TMPDIR}/unpaper-%d.pnm for file in ${TMPDIR}/unpaper*; do ${pnmtotiff} $file >$file.tiff done ${tiffcp} ${TMPDIR}/*.tiff ${TMPDIR}/allpages.tiff ${tiff2pdf} -z -o ${OUTPUT} ${TMPDIR}/allpages.tiff Der naechste schritt waere noch via tesseract ein OCR und das als comment ans PDF haengen - aber das beim naechsten mal. Jetzt erstmal - Wie werde ich "leere" seiten los? Flo -- Florian Lohoff flo(a)rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin

10 38

wine mit ctlib unter amd64 lenny
by Pierre Bernhardt 11 Okt '09

11 Okt '09

Hallo, ich wollte ein Programm unter Wine zum laufen bringen, welches auch auf meinem Cardreader zugreifen können soll. Wine bringt dabei aber nur ctapi-Support mit. Nun funktioniert das ganze mit pcsc... und der libpcsc... von gpg schon ganz gut ohne irgendwelche properitären Treiber zu verwenden. Der Kartenleser und pcsc gehen also. Also habe ich mir gedacht, nimmst Du den libpcsc-ctapi-wrapper den es nicht bei debian gibt und kompilierst Ihn mal schnell. Ok getan und dann die zugehörige Lib mit make install installiert. Kurzer Test ob ich denn nun nicht doch hibiscus nehmen kann... Ja, der Zugriff funktioniert, aber leider wars dass dann doch, weil hibiscus meine rsa-Karten nicht mag (RDH-1) und ich dann doch wieder kein HBCI-Banking machen kann. Hibiscus greift dabei auch via ctapi zu, der Leser wurde bei Angabe der lib gefunden, so dass ich davon ausgehe das das funktionierte. Nun aber weiter mit wine und nach Anleitung die Registry angepasst. Das wars dann aber auch schon. Er mag die Library wohl nicht, weil diese als 64bit vorliegt, aber wine nur mit 32bit rennt und daher auch auf nur eine 32bit lib zugreifen mag. Naja also ich los und das Makefile so geändert das mit -m32 übersetzt wird: Geht. Nun noch die lib erstellen: Essig. gcc such nun nach einer kompatiblen libpcsclite, die wiederum nur als 64 bit vorliegt und gefunden wird. Ich also die i386-Pakete kurz runtergeladen und im Pfad ausgepackt, in der Hoffnung, ich bekomme die dann irgendwie mit dem gcc verwurschtelt, was aber nicht geklappt hat. Nun stehe ich hier und frage mich, ob ein anderer Weg nicht sinnvoller wäre. Die Dateien habe ich: Hallo, kann mir kurz jemand zur Seite stehen wie ich denn die Library als 32 Bit kompiliere? Das Make macht auf meinem AMD64 immer ein 64Bit draus, und das mag Wine scheinbar nicht. Für die Kompilierung musste ich das Paket libpcsclite-dev mit installieren. Der Aufruf unter make lautet pierre@AMD64x2:~/Downloads/pcsc-ctapi-wrapper-0.3$ find . ./usr ./usr/lib ./usr/lib/pkgconfig ./usr/lib/pkgconfig/libpcsclite.pc ./usr/lib/libpcsclite.so.1 ./usr/lib/libpcsclite.so ./usr/lib/libpcsclite.a ./usr/lib/libpcsclite.so.1.0.0 ./usr/lib/libpcsclite.la ./usr/include ./usr/include/PCSC ./usr/include/PCSC/winscard.h ./usr/include/PCSC/ifdhandler.h ./usr/include/PCSC/debuglog.h ./usr/include/PCSC/reader.h ./usr/include/PCSC/wintypes.h ./usr/include/PCSC/pcsclite.h ./usr/share ./usr/share/doc ./usr/share/doc/libpcsclite-dev ./usr/share/doc/libpcsclite-dev/changelog.gz ./usr/share/doc/libpcsclite-dev/examples ./usr/share/doc/libpcsclite-dev/examples/pcsc_demo.c.gz ./usr/share/doc/libpcsclite-dev/changelog.Debian.gz ./usr/share/doc/libpcsclite-dev/copyright ./usr/share/doc/libpcsclite1 ./usr/share/doc/libpcsclite1/changelog.gz ./usr/share/doc/libpcsclite1/changelog.Debian.gz ./usr/share/doc/libpcsclite1/copyright ./LICENSE ./pcsc-ctapi-wrapper.o ./Makefile ./libpcsclite-dev_1.5.5-1_i386.deb ./README ./pcsc-ctapi-wrapper.c ./libpcsclite1_1.5.5-1_i386.deb Der Befehl klappt: pierre@AMD64x2:~/Downloads/pcsc-ctapi-wrapper-0.3$ gcc -m32 -O2 -Wall -I /usr/include/PCSC/ -c -fPIC pcsc-ctapi-wrapper.c Das kommt raus: pierre@AMD64x2:~/Downloads/pcsc-ctapi-wrapper-0.3$ file pcsc-ctapi-wrapper.o pcsc-ctapi-wrapper.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped Und hier gehts dann nicht weiter: pierre@AMD64x2:~/Downloads/pcsc-ctapi-wrapper-0.3$ gcc -m32 -O2 -Wall -I usr/include/PCSC/ -I . -shared -o libpcsc-ctapi-wrapper.so.0.3 -Wl,-soname="libpcsc-ctapi-wrapper.so" pcsc-ctapi-wrapper.o -lpcsclite -L usr/lib/ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status Letztendlich brauche ich die lib erst mal nur für wine. Habt Ihr einen Tipp, was ich da machen kann? Bin nicht so bei dem Thema der Experte. Danke schon mal für die Hilfe... Pierre

2 2

400 Bad request mit squid
by Kai Krebber 09 Okt '09

09 Okt '09

Hi! Wir haben einen squid webproxy (3.0.STABLE6) in Betrieb genommen und nun klappen einige automatisierte http-checks nicht mehr. Mitsniffen ergibt: GET / HTTP/1.1 User-Agent:blabla Host: 82.100.230.226 HTTP/1.0 400 Bad Request Server: squid/3.0.STABLE6 : M.E. ist der Request gem. rfc 2616 korrekt. Hier steht ja: ' The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as "/" (the server root).' Die Reihenfolge der Header-Felder ist auch egal: 'The order in which header fields with differing field names are received is not significant.' Wenn ich alles in eine Zeile packe (also gem. RFC eine absoluteURI statt abs_path nehme), klappts: GET http://82.100.230.226/ HTTP/1.1 User-Agent:blabla Host:82.100.230.226 HTTP/1.0 200 OK : Ich könnte also meine checks umschreiben, aber hätte gerne das Verhalten des Squid verstanden. Kann mir da jemand auf die Sprünge helfen? Gruß; Kai

2 2

WG: Your message to Linux awaits moderator approval
by Kai Krebber 09 Okt '09

09 Okt '09

Mmh - was genau stört das System denn am Header? -----Ursprüngliche Nachricht----- Von: linux-bounces(a)lug-owl.de [mailto:linux-bounces@lug-owl.de] Gesendet: Freitag, 9. Oktober 2009 09:50 An: Kai Krebber Betreff: Your message to Linux awaits moderator approval Your mail to 'Linux' with the subject 400 Bad request mit squid Is being held until the list moderator can review it for approval. The reason it is being held: Message has a suspicious header Either the message will get posted to the list, or you will receive notification of the moderator's decision.

2 1