Hallo, ich habe einen Server mit einer 11.3 am Laufen. Die Konfiguration des FTP servers über YAST schlägt mit folgender Fehlermeldung fehl: "UI Syntax Error. Multiple Buttons with Role [Cancel]" Im log von yast y2log finden sich für diesen Vorgang gefühlte tausend Einträge. Ich habe mal die letzten hier reinkopiert. Ich kann damit nix anfangen. Die 11.3 ist eigentlich ein Minimalsystem mit etwas Adminkram vom Provider. Aus der Glasgoogle konnte ich herauslesen, dass solche Fehler auftauchen können, wenn Komponenten fehlen bzw. nicht installiert sind. Aber ist das hier der Fall? und was könnte fehlen? Gruß Joachim == snipp y2log == 2012-03-30 17:42:46 <1> XXX(23831) [zypp] SATResolver.cc(solving):444 ....Solver end 2012-03-30 17:42:46 <3> XXX(23831) [zypp] SATResolver.cc(solving):579 Solverrun finished with an ERROR 2012-03-30 17:42:46 <2> XXX(23831) [zypp] SATResolver.cc(resolvePool):747 SATResolver::resolvePool() done. Ret:0 2012-03-30 17:42:46 <1> XXX(23831) [Pkg] PackageSystem.ycp:198 Pkg Builtin called: IsAnyResolvable 2012-03-30 17:42:46 <5> XXX(23831) [Measure] Measure.cc(Impl):145 START MEASURE(id2item) 2012-03-30 17:42:46 <5> XXX(23831) [Measure] Measure.cc(~Impl):153 MEASURE(id2item) 0 (u 0.00 s 0.00 c 0.00) 2012-03-30 17:42:46 <5> XXX(23831) [YCP] PackageSystem.ycp:200 Target solved: false, something to transact: true 2012-03-30 17:42:46 <1> XXX(23831) [Pkg] PackageSystem.ycp:109 Pkg Builtin called: PkgInstall 2012-03-30 17:42:46 <2> XXX(23831) [YCP] PackageSystem.ycp:212 The current system is not consistent 2012-03-30 17:42:46 <1> XXX(23831) [ui] YPushButton.cc(setFunctionKey):204 Guessing button role YOKButton for YPushButton "Fortfahren" at 0x167c5410 from function key F10 2012-03-30 17:42:46 <1> XXX(23831) [ui] YPushButton.cc(setRole):172 Guessing function key F9 for YPushButton "Überspringen" at 0x167c58a0 from button role YCancelButton 2012-03-30 17:42:46 <1> XXX(23831) [ui] YPushButton.cc(setFunctionKey):204 Guessing button role YCancelButton for YPushButton "Abbrechen" at 0x167c5c20 from function key F9 2012-03-30 17:42:46 <2> XXX(23831) [ui] YButtonBox.cc(sanityCheck):650 THROW: Multiple buttons with role [Cancel] 2012-03-30 17:42:46 <2> XXX(23831) [ui] YCPDialogParser.cc(parseButtonBox):1155 CAUGHT: Multiple buttons with role [Cancel] 2012-03-30 17:42:46 <3> XXX(23831) [libycp] Popup.ycp:1559 Bad ButtonBox content 2012-03-30 17:42:46 <2> XXX(23831) [ui] YCPDialogParser.cc(parseButtonBox):1157 RETHROW: Multiple buttons with role [Cancel] 2012-03-30 17:42:46 <2> XXX(23831) [ui] YCP_UI.cc(OpenDialog):572 CAUGHT: Multiple buttons with role [Cancel] 2012-03-30 17:42:46 <3> XXX(23831) [libycp] Popup.ycp:1559 UI::OpenDialog() failed 2012-03-30 17:42:46 <1> XXX(23831) [ui] YPushButton.cc(setRole):172 Guessing function key F10 for YPushButton "Close" at 0x167c5c20 from button role YOKButton == snapp == -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Joachim, hallo Leute, Am Samstag, 31. März 2012 schrieb Joachim H.:
Für mich klingt das eher nach einem Programmierfehler im betreffenden YaST-Modul. Probier mal, ob das Problem auch noch mit openSUSE 12.1 auftritt - wenn ja, reiche bitte einen Bugreport ein. (11.3 ist nicht mehr supported - von daher macht ein Bugreport für die 11.3 wenig Sinn.) Außerdem könnte ein rpm -V `rpm -qa |grep -i yast` Licht ins Dunkel bringen - vielleicht ist ja "nur" eine Datei kaputt... Davon abgesehen ist es nicht wirklich schwierig, vsftpd "von Hand" zu konfigurieren ;-) Gruß Christian Boltz -- Nobody will ever need more than 640 kB RAM. -- Bill Gates, 1983 Windows XP requires 64 MB RAM. -- Bill Gates, 2001 Nobody will ever need Windows XP. -- logical conclusion -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Sun, 01 Apr 2012, Christian Boltz schrieb:
rpm -Va '*yast*' Ein Paket mit andersgeschriebenem 'yast' findet sich hier zumindest nicht. HTH, -dnh -- Inkonsistenz ist, wenn's nicht so läuft, wie man's gesagt hat, daß man's halten würde. Inkontinenz ist, wenn's läuft, obwohl man's lieber halten würde. -- Matthias Kryn -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo David, hallo Leute, Am Montag, 2. April 2012 schrieb David Haller:
Stimmt - allerdings war ich zu faul, das im Detail nachzuprüfen. Und obwohl mein Laptop einen Haufen Pakete installiert hat [1], gibt es trotzdem einige Pakete, die ich nicht installiert habe (und die möglicherweise[2] "YaST" statt "yast" im Namen haben). Ich weiß, dass Du bei unnötigen greps und rpm-Aufrufen allergisch reagierst ;-) - aber wenn man das Ergebnis an ein rpm -V verfüttert, dürfte der Performance-Unterschied nicht wirklich messbar sein *g* Gruß Christian Boltz PS: Ich such mal die passende sig raus ;-) [1] / hat 8,5 GB used - wobei /tmp, /var und natürlich /home auf einer anderen (verschlüsselten) Partition liegen [2] nein, ich will das jetzt nicht nachprüfen ;-) --
Hallo, Am Mon, 02 Apr 2012, Christian Boltz schrieb:
Dito. AFAIK nein. Ok, da sollte dann rpm -Va '*[Yy][Aa][Ss][Tt]*' helfen... ;)
Stimmt wohl, die meiste Zeit dürfte für's 'rpm -qa' (implizit in -Va) draufgehen, also die Abfrage aller Pakete. Der Rest ist dann weitgehend I/O. Das extra 'rpm -V' und 'grep' zu starten sollte nicht viel ausmachen. # time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 0m2.673s # time rpm -V `rpm -qa |grep -i yast` real 0m2.810s Sowas ist nicht wirklich relevant. Der Unterschied dürften weitgehend die Startzeiten vom extra rpm und grep sein. Nur: daß rpm auch selber Paketnamen "matchen" kann (vgl. rpm -qa '*kernel*') ist noch wenig bei den Anwendern angekommen.
PS: Ich such mal die passende sig raus ;-)
*hrhrhr* dito.
[1] / hat 8,5 GB used - wobei /tmp, /var und natürlich /home auf einer anderen (verschlüsselten) Partition liegen
Inkl. /var und /tmp lt. 'df -m': 27515M used. /home wäre je nach Zählweise dann zw. 5.4G (used auf /home) und ~14T groß :P
*keuch* *schnüff* -dnh PS: hab heute mal den 3.3 aus Kernel:stable getestet, der vermurkst einem offenbar das DVB, ich bekomm da nur noch Artefakte mit ein paar Bild- und Tonfetzen. mit 3.1.9 läufts (und ich dachte schon fast, meine TV-Karte verreckt schon wieder). -- Bugzilla beißt nicht und ist viel, viel netter als ich. -- Lars Müller -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo David, hallo Leute, Am Dienstag, 3. April 2012 schrieb David Haller:
Entweder Du hast kaum YaST-Pakete installiert oder (was ich eher vermute) die obigen Zeiten sind mit vorgewärmtem Plattencache gemessen. Sieht hier so aus: # time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 1m39.836s # erster Durchlauf - Cache war vorher "leer" # time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 0m3.811s # zweiter Durchlauf kurz danach - Cache hilft :-) # time rpm -V `rpm -qa |grep -i yast` real 0m4.053s # nicht schlecht, aber... # time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 0m2.865s # ... speziell für diesen Befehl gecacht geht es noch schneller ;-) (wahrscheinlich lag vorher nur ein Teil der RPM- Datenbank im Cache)
Sowas ist nicht wirklich relevant.
Genau. Der wichtigste Unterschied ist, ob die RPM-Datenbank und die Dateien aller zu prüfenden Pakete schon im Cache liegen ;-) Zumindest bei letzteren ist es unwahrscheinlich - wer ruft schon zweimal hintereinander rpm -V fürs gleiche Paket auf?
Der Unterschied dürften weitgehend die Startzeiten vom extra rpm und grep sein.
Ja - aber im Vergleich zu einem rpm -V bei leerem Plattencache sind diese Zeiten eher lächerlich. Wo ich eh schon am Testen bin, noch eine Variante: Übergabe aller Paketnamen direkt beim rpm-Aufruf. Damit haben wir den Teil "Auflistung der Pakete" ausgeklammert. Jeweils die Daten vom 2. Durchlauf (vorgewärmter Cache): # time liste=$(rpm -qa '*[Yy][Aa][Ss][Tt]*') real 0m1.928s # time liste=$(rpm -qa | grep -i yast) real 0m2.033s Das zusätzliche grep kostet also 5% Performance. Weltuntergang! ;-) # time rpm -V $liste real 0m1.100s Wer will, kann diese Zahlen jetzt noch zusammenrechnen und mit den Werten von oben vergleichen ;-)
Nur: daß rpm auch selber Paketnamen "matchen" kann (vgl. rpm -qa '*kernel*') ist noch wenig bei den Anwendern angekommen.
Weiß ich ;-)
PS: Ich such mal die passende sig raus ;-)
*hrhrhr* dito.
OK, das sig-Match ist eröffnet. Ich suche nochmal ;-)
27G? Da würde mich der Anteil von /var und /tmp doch interessieren. Ich hätte bei Dir ein schlankeres System vermutet ;-)
Ich glaube, ich muss Dir die Benutzung von Bugzilla nicht erklären, oder?
(und ich dachte schon fast, meine TV-Karte verreckt schon wieder).
Ging mir bei meinem internen Cardreader mit dem Kernel der 12.1 ähnlich - nur dass der mit dem 3.3er Kernel wieder geht. Gruß Christian Boltz -- Du bist wirklich Designfetischist, oder? IMHO merkt den Unterschied später sowieso keiner. Aber deinen Arbeitseifer zu stoppen wäre ja fatal... ;-))) [Andreas Schott zu David Haller in suse-linux-faq] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Tue, 03 Apr 2012, Christian Boltz schrieb:
Mit Cache natürlich. Sonst müßte ich ja zwischendrin rebooten! Ok, zum Vergleich mal ne Laufzeit ohne Cache wäre evtl. sinnvoll, bzgl. "Relevanz" der Laufzeitunterschiede vs. Laufzeit ohne gefüllten Cache.
/me wenn er das Ergebnis des ersten Laufs nicht nachvollziehen kann. Hast zufällig den nvidia-Treiber aus dem nvidia-Repo installiert? $ time rpm -Va '*nvidia*' 5S.T..... /usr/bin/X.x11-video-nvidiaG02 ...T..... /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so Ja, das ist ok so. Wird im postinstall-script gemacht. Aber bis man das nachvollzogen hat ... ;)
ACK.
Das könnte scheitern ... allerdings scheint da jemand an der max. Länge der Argument-Liste gedreht zu haben, ich hatte zuletzt immer was von 131xxx in den config.log ... Im WindowMaker-Log find ich: checking the maximum length of command line arguments... 1572864 $ rpm -qa | wc -c 112051 ok, da ist dann doch (inzwischen) noch gut Luft ;)
Aber doch ... Woast Bub, ich denk bei sowas immer willkürlich an den Worst-case. Nämlich das das nicht ein Gscheidle wie du macht, sondern daß das irgendeiner hier oder in irgendeinem Forum aufschnappt. Und dann das macht: for i in $(rpm -qa); do rpm -Va | grep -i $i; done Oder so. Ok, da ist das grep auch eher wurst. Hier mal ne Auswahl an Grausamkeiten bei einer einfachen Aufgabe: ,----[ dynip_testing.sh ] | #!/bin/bash | export LC_ALL=C | test -n "$1" || { | echo "Usage: [LOOPS=<iterations>] $0 INTERFACE [IP]"; | exit 1 | } | trap "echo "Aborted!" && exit 1" 2 | dh1() { sed -n 's/.*addr:\([0-9\.]*\).*/\1/p'; }; | dh2() { grep "inet addr:" | sed 's/.*addr:\([0-9\.]*\).*/\1/'; }; | dh3() { echo -n $(sed -n 's/.*addr:\([0-9\.]*\).*/\1/p'); } | dh4() { echo -n $( grep "inet addr:" | sed 's/.*addr:\([0-9\.]*\).*/\1/' ); } | dh5() { while read l; do m="${l%%*addr:[0-9.]*}"; if test "x$m" = "x"; then | a="${l//*addr:/}"; a="${a// */}"; echo "$a"; fi; done; } | dh6() { sed -n '/addr:/s/.*addr:\([0-9\.]*\).*/\1/p'; } | tj1() { grep "inet addr:" | awk '{print $2}' | cut -c 6- | perl -pe 'chomp;'; } | tj2() { grep "inet addr:" | awk '{print $2}' | cut -c 6- ; } | sd1() { perl -ne 'if (/inet addr:(\S+)/) { print $1 }'; } | ww1() { grep "inet addr:" | cut -f2 -d: | cut -f1 -d' '; } | mh1() { grep inet | awk '{print $2}' | awk -F: '{print $2}'; } | mt1() { grep 'inet addr:' | cut -f2 -d":" | awk '{ print $1 }'; } | dk1() { read; read -a A; echo ${A[1]#*:}; } | jt1() { awk '/inet addr:/{print substr($2, index($2,":") +1) }'; } | dh7() { awk -F'[: ]+' '/inet addr:/{print $4;}'; } | | echo "testing for IF: $1" | | IFCFG="$(/sbin/ifconfig "$1")" | if test -z "$2"; then | IP=$(echo $IFCFG | dh1) | fi | | # run some dummies first (using all external tools at least twice) | echo "caching tools ..." >&2 | for m in dh1 dh7 mt1 sd1 dk1 tj1; do { | time for i in $(seq ${LOOPS:=2}); do | test "x$(echo "$IFCFG" | $m )" = "x${IP}" || { | echo "ERROR" >/dev/stderr; break; | }; done } >/dev/null 2>&1 | done | | echo "running benchmark ..." >&2 | for m in dk1 dh5 dh1 dh6 dh3 dh2 dh4 ww1 mt1 mh1 tj2 sd1 tj1 jt1 dh7; | do | echo -ne "$m: " >&2 | { | time for i in $(seq ${LOOPS:=1000}) | do | test "x$(echo "$IFCFG" | $m )" = "x${IP}" || { | echo "ERROR" >/dev/stderr; break; | } | done | } 2>&1 | sed -n '/real/p' | done | exit 0 `---- Gedacht die dynamische IP eines ppp/dsl devices per ifconfig auszulesen. Achso, die 'dh*' sind bis auf dh1, dh5, dh6 und dh7 rein akademisch zum Vergleich mit drin. Die nicht 'dh*' sind alle als IIRC ersten Vorschläge hier in der ML geschrieben worden ... Besonders klasse übrigens das "perl -pe 'chomp;'", tut mir leid IIRC Thorsten (da hätt's ein xargs echo oder printf "%s" $( ... ) auch getan :) und das extra perl sieht man in der Laufzeit ... $ dynip_testing.sh eth1 testing for IF: eth1 caching tools ... running benchmark ... dk1: real 0m1.458s dh5: real 0m1.681s dh1: real 0m2.432s dh6: real 0m2.470s dh3: real 0m3.135s dh2: real 0m2.786s dh4: real 0m3.270s ww1: real 0m3.104s mt1: real 0m3.522s mh1: real 0m3.529s tj2: real 0m3.365s sd1: real 0m3.395s tj1: real 0m4.742s jt1: real 0m2.667s dh7: real 0m2.702s Im anderen Durchlauf war dk1 ähnlich, tj1 bei ~5.2s. Da war wohl perl evtl. noch nicht ganz fit ;) Und nein, daß die rein auf die bash-builtins setzenden dk1 und dh5 vorn liegen ist wenig überraschend. Und daß dann 'dh1' folgt ist zumindest für mich nicht überraschend. Das möge aber jede(r) selber austesten und nachvollziehen. Leider sind auf der neuen Kiste mit DDR3-1333 RAM und 3GHz Doppelkern bei warmem Cache die Startzeiten der Tools nimmer so deutlich wie auf der alten (mit SDRAM (133) und 500MHz Einzelkern). Da hatte ich schon bei 100 Loops krasse Unterschiede, IIRC um Größenordnungen (also z.B. 2s für dk1 und >20s für tj1 oder so in der Richtung). Bei "kaltem" FS-Cache schlägt die Größe der Programme speziell gegen die bash-builtins weiter voll zu, allerdings laufen die verwendeten Programme sowieso beim boot in diversen init-scripten. Mit systemd dürfte sich das aber ändern, was v.a. bei perl zuschlagen würde. bash läuft wohl eh und cut/grep/sed/awk dürften bzgl. Startzeit in etwa gleichauf sein. Achso, was ich schreiben wollte: wenn du die Tools kennst (und dabei helfen solche Threads), dann kannst du immer besser abschätzen, was effizient ist[2] und was nicht (und in einer Schleife über $viele Hosts z.B. "ewig" dauert). Um mal die wichtigsten 2 meiner Faustregeln zu nennen: - Prozesse starten ist lahm - x kann alles was auch y kann Liste (x<y): grep < sed < awk < perl[1] ed einzusortieren ist nicht ganz einfach (irgendwo sehr nah bei ed). Von (x)emacs (vim?) im batch-mode sowie python, lua etc. will ich hier nicht anfangen ;) Wenn man also irgendwo in ner Pipe ein 'sed' verwendet darf da eigentlich kein 'grep' mehr drin auftauchen (denn das kann sed selber, ist dabei aber teils arg lahm, da ist ein grep | sed ggfs. ok). awk kann noch mehr als sed und perl alles außer [1] was awk kann. Ich selber schreib mein längeren scripte inzwischen im Zweifelsfall in perl (und ein fertiges sub für's bequeme fehlerbehandelnde Aufrufen externer Programme hab ich auch ;) [1] mit einer Ausnahme: den "Record seperator", der darf bei awk auch ne Regex sein, bei perl nicht (und das nachzuarbeiten ist selten trivial, und braucht entweder mehr Speicher oder mehr Zeit). ==== man perlvar ==== HANDLE->input_record_separator( EXPR ) $INPUT_RECORD_SEPARATOR $RS $/ The input record separator, newline by default. [..] Remember: the value of $/ is a string, not a regex. awk has to be better for something. :-) ==== [2] bei perl "intern" gibt's da aber durchaus mal die ein oder andere Überraschung.
Du und ich und noch ein paar ... Was "man" daheim an der Konsole ist die eine Sache, was man in Scripte schreibet eine andere. Wenn man die Script aber publiziert oder Befehle in einer ML, NG oder nem Forum schreibt gelten andere Maßstäbe. Wenn du wüßtest, was ich hier im xterm schon an Mist getippert hab ... BTW: $ for f in ~/bin/*[^~]; do test -f "$f" || continue; file -- "$f"; done \ | awk '/shell/{s++;};/perl/{p++;}END{print s, p;}' 304 234 Ich glaub ich sollte mein ~/bin/ mal ausmisten. Da ist definitiv einiger "Schrott" dabei (aber viele Perlen, sach ich ma so ;)
BTW: deine is ein Fake. Das hat A. Schott an mich geschrieben. Und das auf einer anderen Liste ... .oO( gut daß ich auch (vermeintliche) Sigs meinerseits archiviere *hrhrhr* )
/tmp ist praktisch leer, in /var/ liegt ein großer Haufen logs # du -ms /var/cache/ /var/lib/ /var/log /var/tmp/ 6447 /var/cache/ 707 /var/lib/ 1319 /var/log 13 /var/tmp/ Äh, und der Rest dürfte dann /var/spool/news sein :P Da ich leafnode verwende (atime-basiertes "zu holen oder nicht") mach ich da mal kein 'du' drüber, will die Gruppen nicht wieder aus interesting.groups rauspopeln. Und ja, da liegen mind. 2 Gruppen mit nem dicken Archiv ;) Bei anderen könnte ich mal das expire anpassen oder sie gleich ganz rauswerfen, da ich da eh nix les. Aber so 2-3 Monate Archiv find ich schon angemessen ;)
Nein. Bin aber noch nicht dazu gekommen. Hab heute auch nochmal den nvidia-Treiber auf die 290.10 Version aus dem nvidia-Repo runtergezogen, nur um das auszuschließen, hatte ein paar Artefakte, das dürfte aber an der HW gelegen haben. Oder dem Mesa-Update heute. *GNORF* Das mit dem Kernel 3.3 war aber vor o.g. nur bis ich nen nvidia-Treiber unter 3.3 am Laufen hatte (naja, der Patch ist zum Glück einfach, ich kipp den hier einfach schonmal ab, der gilt AFAIK schon seit dem 270er Treiber, spätestens seit dem 290er, nur hat man vom RPM halt nicht das .spec + Patches): ==== diff -x '*~' -x '*.o' -urN NVIDIA-Linux-x86_64-295.33/kernel/conftest.sh NVIDIA-Linux-x86_64-295.33.dh/kernel/conftest.sh --- NVIDIA-Linux-x86_64-295.33/kernel/conftest.sh 2012-03-17 22:55:27.000000000 +0100 +++ NVIDIA-Linux-x86_64-295.33.dh/kernel/conftest.sh 2012-04-02 10:57:07.000000000 +0200 @@ -127,6 +127,7 @@ if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include -I$SOURCES/arch/x86/include/generated" + CFLAGS="$CFLAGS -I$OUTPUT/arch/x86/include -I$OUTPUT/arch/x86/include/generated" elif [ "$ARCH" = "ARMv7" ]; then CFLAGS="$CFLAGS -I$SOURCES/arch/arm/include -I$SOURCES/arch/arm/include/generated" fi ==== Die Folgefehler aus den fehlenden Includes sind teilweise extrem irreführend (und mit make -j > 1 hat man verloren ;) Achso, ja, der Patch sollte auch für kleinere Versionen passen, 290.10, und auch 270er. Evtl. noch älter. Verd....e Ka... hab ich da lange rumprobiert mit dem Krams bis ich auf obiges im conftest.sh gekommen bin. Kernel 'make *prepare', Argumente für den installer und und und und und. Hab mich schon beim überletzten Kernelupdate mit rumgeschlagen, und irgendwann aufgegeben und das 290er RPM installiert (was erfreulicherweise funktionierte). Den 295er mit 3.1.9er Kernel (der 12.1) hab ich noch nicht getestet. Das mach ich wohl als erstes. Und dann mal gucken ob der 290er mit dem Patch auch auf dem 3.3 läuft. Ist eben sehr zeitaufwendig, zumal wenn wie die Tage noch ein Mesa Update mal wieder an libGL.so* rummacht.
Na denn :) -dnh, der den 3.3 wg. dem wohl verbesserten I/O Verhalten auf z.B. USB Krams mal testen will -- *pieps* Die Verkehrshinweise: Im Netzwerkkabel von Marc 100 MB Stau wegen einer Vollsperrung der Ausfahrt Festplatte. Bitte warten Sie auf dem Rasthof FTP-Server. *pieps* -- C. Boltz -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Christian, Am 01.04.2012 21:08, schrieb Christian Boltz:
Für mich klingt das eher nach einem Programmierfehler im betreffenden YaST-Modul.
Für mich auch. Da hat jemand zwei unterschiedlichen Objekten die Funktion "Cancel" zugewiesen? Sucht man in Google nach dieser Fehlermeldung, stößt man eigentlich nur darauf, dass irgendwas nicht korrekt installiert war, was aber eben nicht yast selbst war.
Probier mal, ob das Problem auch noch mit openSUSE 12.1 auftritt
Nein, tut es nicht.
Ich habe es auch mit yast2 probiert. Da kam die Meldung, dass die GUI fehlt und man zu GtK zurückschaltet. Auch dann kam der Fehler beim Versuch, den FTP-Server zu konfigurieren. Letztlich habe ich dann GUI von YAST2 nachinstalliert. Jetzt tut's wie es soll. Gruß Joachim -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Joachim, hallo Leute, Am Samstag, 31. März 2012 schrieb Joachim H.:
Für mich klingt das eher nach einem Programmierfehler im betreffenden YaST-Modul. Probier mal, ob das Problem auch noch mit openSUSE 12.1 auftritt - wenn ja, reiche bitte einen Bugreport ein. (11.3 ist nicht mehr supported - von daher macht ein Bugreport für die 11.3 wenig Sinn.) Außerdem könnte ein rpm -V `rpm -qa |grep -i yast` Licht ins Dunkel bringen - vielleicht ist ja "nur" eine Datei kaputt... Davon abgesehen ist es nicht wirklich schwierig, vsftpd "von Hand" zu konfigurieren ;-) Gruß Christian Boltz -- Nobody will ever need more than 640 kB RAM. -- Bill Gates, 1983 Windows XP requires 64 MB RAM. -- Bill Gates, 2001 Nobody will ever need Windows XP. -- logical conclusion -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Sun, 01 Apr 2012, Christian Boltz schrieb:
rpm -Va '*yast*' Ein Paket mit andersgeschriebenem 'yast' findet sich hier zumindest nicht. HTH, -dnh -- Inkonsistenz ist, wenn's nicht so läuft, wie man's gesagt hat, daß man's halten würde. Inkontinenz ist, wenn's läuft, obwohl man's lieber halten würde. -- Matthias Kryn -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo David, hallo Leute, Am Montag, 2. April 2012 schrieb David Haller:
Stimmt - allerdings war ich zu faul, das im Detail nachzuprüfen. Und obwohl mein Laptop einen Haufen Pakete installiert hat [1], gibt es trotzdem einige Pakete, die ich nicht installiert habe (und die möglicherweise[2] "YaST" statt "yast" im Namen haben). Ich weiß, dass Du bei unnötigen greps und rpm-Aufrufen allergisch reagierst ;-) - aber wenn man das Ergebnis an ein rpm -V verfüttert, dürfte der Performance-Unterschied nicht wirklich messbar sein *g* Gruß Christian Boltz PS: Ich such mal die passende sig raus ;-) [1] / hat 8,5 GB used - wobei /tmp, /var und natürlich /home auf einer anderen (verschlüsselten) Partition liegen [2] nein, ich will das jetzt nicht nachprüfen ;-) --
Hallo, Am Mon, 02 Apr 2012, Christian Boltz schrieb:
Dito. AFAIK nein. Ok, da sollte dann rpm -Va '*[Yy][Aa][Ss][Tt]*' helfen... ;)
Stimmt wohl, die meiste Zeit dürfte für's 'rpm -qa' (implizit in -Va) draufgehen, also die Abfrage aller Pakete. Der Rest ist dann weitgehend I/O. Das extra 'rpm -V' und 'grep' zu starten sollte nicht viel ausmachen. # time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 0m2.673s # time rpm -V `rpm -qa |grep -i yast` real 0m2.810s Sowas ist nicht wirklich relevant. Der Unterschied dürften weitgehend die Startzeiten vom extra rpm und grep sein. Nur: daß rpm auch selber Paketnamen "matchen" kann (vgl. rpm -qa '*kernel*') ist noch wenig bei den Anwendern angekommen.
PS: Ich such mal die passende sig raus ;-)
*hrhrhr* dito.
[1] / hat 8,5 GB used - wobei /tmp, /var und natürlich /home auf einer anderen (verschlüsselten) Partition liegen
Inkl. /var und /tmp lt. 'df -m': 27515M used. /home wäre je nach Zählweise dann zw. 5.4G (used auf /home) und ~14T groß :P
*keuch* *schnüff* -dnh PS: hab heute mal den 3.3 aus Kernel:stable getestet, der vermurkst einem offenbar das DVB, ich bekomm da nur noch Artefakte mit ein paar Bild- und Tonfetzen. mit 3.1.9 läufts (und ich dachte schon fast, meine TV-Karte verreckt schon wieder). -- Bugzilla beißt nicht und ist viel, viel netter als ich. -- Lars Müller -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo David, hallo Leute, Am Dienstag, 3. April 2012 schrieb David Haller:
Entweder Du hast kaum YaST-Pakete installiert oder (was ich eher vermute) die obigen Zeiten sind mit vorgewärmtem Plattencache gemessen. Sieht hier so aus: # time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 1m39.836s # erster Durchlauf - Cache war vorher "leer" # time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 0m3.811s # zweiter Durchlauf kurz danach - Cache hilft :-) # time rpm -V `rpm -qa |grep -i yast` real 0m4.053s # nicht schlecht, aber... # time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 0m2.865s # ... speziell für diesen Befehl gecacht geht es noch schneller ;-) (wahrscheinlich lag vorher nur ein Teil der RPM- Datenbank im Cache)
Sowas ist nicht wirklich relevant.
Genau. Der wichtigste Unterschied ist, ob die RPM-Datenbank und die Dateien aller zu prüfenden Pakete schon im Cache liegen ;-) Zumindest bei letzteren ist es unwahrscheinlich - wer ruft schon zweimal hintereinander rpm -V fürs gleiche Paket auf?
Der Unterschied dürften weitgehend die Startzeiten vom extra rpm und grep sein.
Ja - aber im Vergleich zu einem rpm -V bei leerem Plattencache sind diese Zeiten eher lächerlich. Wo ich eh schon am Testen bin, noch eine Variante: Übergabe aller Paketnamen direkt beim rpm-Aufruf. Damit haben wir den Teil "Auflistung der Pakete" ausgeklammert. Jeweils die Daten vom 2. Durchlauf (vorgewärmter Cache): # time liste=$(rpm -qa '*[Yy][Aa][Ss][Tt]*') real 0m1.928s # time liste=$(rpm -qa | grep -i yast) real 0m2.033s Das zusätzliche grep kostet also 5% Performance. Weltuntergang! ;-) # time rpm -V $liste real 0m1.100s Wer will, kann diese Zahlen jetzt noch zusammenrechnen und mit den Werten von oben vergleichen ;-)
Nur: daß rpm auch selber Paketnamen "matchen" kann (vgl. rpm -qa '*kernel*') ist noch wenig bei den Anwendern angekommen.
Weiß ich ;-)
PS: Ich such mal die passende sig raus ;-)
*hrhrhr* dito.
OK, das sig-Match ist eröffnet. Ich suche nochmal ;-)
27G? Da würde mich der Anteil von /var und /tmp doch interessieren. Ich hätte bei Dir ein schlankeres System vermutet ;-)
Ich glaube, ich muss Dir die Benutzung von Bugzilla nicht erklären, oder?
(und ich dachte schon fast, meine TV-Karte verreckt schon wieder).
Ging mir bei meinem internen Cardreader mit dem Kernel der 12.1 ähnlich - nur dass der mit dem 3.3er Kernel wieder geht. Gruß Christian Boltz -- Du bist wirklich Designfetischist, oder? IMHO merkt den Unterschied später sowieso keiner. Aber deinen Arbeitseifer zu stoppen wäre ja fatal... ;-))) [Andreas Schott zu David Haller in suse-linux-faq] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Tue, 03 Apr 2012, Christian Boltz schrieb:
Mit Cache natürlich. Sonst müßte ich ja zwischendrin rebooten! Ok, zum Vergleich mal ne Laufzeit ohne Cache wäre evtl. sinnvoll, bzgl. "Relevanz" der Laufzeitunterschiede vs. Laufzeit ohne gefüllten Cache.
/me wenn er das Ergebnis des ersten Laufs nicht nachvollziehen kann. Hast zufällig den nvidia-Treiber aus dem nvidia-Repo installiert? $ time rpm -Va '*nvidia*' 5S.T..... /usr/bin/X.x11-video-nvidiaG02 ...T..... /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so Ja, das ist ok so. Wird im postinstall-script gemacht. Aber bis man das nachvollzogen hat ... ;)
ACK.
Das könnte scheitern ... allerdings scheint da jemand an der max. Länge der Argument-Liste gedreht zu haben, ich hatte zuletzt immer was von 131xxx in den config.log ... Im WindowMaker-Log find ich: checking the maximum length of command line arguments... 1572864 $ rpm -qa | wc -c 112051 ok, da ist dann doch (inzwischen) noch gut Luft ;)
Aber doch ... Woast Bub, ich denk bei sowas immer willkürlich an den Worst-case. Nämlich das das nicht ein Gscheidle wie du macht, sondern daß das irgendeiner hier oder in irgendeinem Forum aufschnappt. Und dann das macht: for i in $(rpm -qa); do rpm -Va | grep -i $i; done Oder so. Ok, da ist das grep auch eher wurst. Hier mal ne Auswahl an Grausamkeiten bei einer einfachen Aufgabe: ,----[ dynip_testing.sh ] | #!/bin/bash | export LC_ALL=C | test -n "$1" || { | echo "Usage: [LOOPS=<iterations>] $0 INTERFACE [IP]"; | exit 1 | } | trap "echo "Aborted!" && exit 1" 2 | dh1() { sed -n 's/.*addr:\([0-9\.]*\).*/\1/p'; }; | dh2() { grep "inet addr:" | sed 's/.*addr:\([0-9\.]*\).*/\1/'; }; | dh3() { echo -n $(sed -n 's/.*addr:\([0-9\.]*\).*/\1/p'); } | dh4() { echo -n $( grep "inet addr:" | sed 's/.*addr:\([0-9\.]*\).*/\1/' ); } | dh5() { while read l; do m="${l%%*addr:[0-9.]*}"; if test "x$m" = "x"; then | a="${l//*addr:/}"; a="${a// */}"; echo "$a"; fi; done; } | dh6() { sed -n '/addr:/s/.*addr:\([0-9\.]*\).*/\1/p'; } | tj1() { grep "inet addr:" | awk '{print $2}' | cut -c 6- | perl -pe 'chomp;'; } | tj2() { grep "inet addr:" | awk '{print $2}' | cut -c 6- ; } | sd1() { perl -ne 'if (/inet addr:(\S+)/) { print $1 }'; } | ww1() { grep "inet addr:" | cut -f2 -d: | cut -f1 -d' '; } | mh1() { grep inet | awk '{print $2}' | awk -F: '{print $2}'; } | mt1() { grep 'inet addr:' | cut -f2 -d":" | awk '{ print $1 }'; } | dk1() { read; read -a A; echo ${A[1]#*:}; } | jt1() { awk '/inet addr:/{print substr($2, index($2,":") +1) }'; } | dh7() { awk -F'[: ]+' '/inet addr:/{print $4;}'; } | | echo "testing for IF: $1" | | IFCFG="$(/sbin/ifconfig "$1")" | if test -z "$2"; then | IP=$(echo $IFCFG | dh1) | fi | | # run some dummies first (using all external tools at least twice) | echo "caching tools ..." >&2 | for m in dh1 dh7 mt1 sd1 dk1 tj1; do { | time for i in $(seq ${LOOPS:=2}); do | test "x$(echo "$IFCFG" | $m )" = "x${IP}" || { | echo "ERROR" >/dev/stderr; break; | }; done } >/dev/null 2>&1 | done | | echo "running benchmark ..." >&2 | for m in dk1 dh5 dh1 dh6 dh3 dh2 dh4 ww1 mt1 mh1 tj2 sd1 tj1 jt1 dh7; | do | echo -ne "$m: " >&2 | { | time for i in $(seq ${LOOPS:=1000}) | do | test "x$(echo "$IFCFG" | $m )" = "x${IP}" || { | echo "ERROR" >/dev/stderr; break; | } | done | } 2>&1 | sed -n '/real/p' | done | exit 0 `---- Gedacht die dynamische IP eines ppp/dsl devices per ifconfig auszulesen. Achso, die 'dh*' sind bis auf dh1, dh5, dh6 und dh7 rein akademisch zum Vergleich mit drin. Die nicht 'dh*' sind alle als IIRC ersten Vorschläge hier in der ML geschrieben worden ... Besonders klasse übrigens das "perl -pe 'chomp;'", tut mir leid IIRC Thorsten (da hätt's ein xargs echo oder printf "%s" $( ... ) auch getan :) und das extra perl sieht man in der Laufzeit ... $ dynip_testing.sh eth1 testing for IF: eth1 caching tools ... running benchmark ... dk1: real 0m1.458s dh5: real 0m1.681s dh1: real 0m2.432s dh6: real 0m2.470s dh3: real 0m3.135s dh2: real 0m2.786s dh4: real 0m3.270s ww1: real 0m3.104s mt1: real 0m3.522s mh1: real 0m3.529s tj2: real 0m3.365s sd1: real 0m3.395s tj1: real 0m4.742s jt1: real 0m2.667s dh7: real 0m2.702s Im anderen Durchlauf war dk1 ähnlich, tj1 bei ~5.2s. Da war wohl perl evtl. noch nicht ganz fit ;) Und nein, daß die rein auf die bash-builtins setzenden dk1 und dh5 vorn liegen ist wenig überraschend. Und daß dann 'dh1' folgt ist zumindest für mich nicht überraschend. Das möge aber jede(r) selber austesten und nachvollziehen. Leider sind auf der neuen Kiste mit DDR3-1333 RAM und 3GHz Doppelkern bei warmem Cache die Startzeiten der Tools nimmer so deutlich wie auf der alten (mit SDRAM (133) und 500MHz Einzelkern). Da hatte ich schon bei 100 Loops krasse Unterschiede, IIRC um Größenordnungen (also z.B. 2s für dk1 und >20s für tj1 oder so in der Richtung). Bei "kaltem" FS-Cache schlägt die Größe der Programme speziell gegen die bash-builtins weiter voll zu, allerdings laufen die verwendeten Programme sowieso beim boot in diversen init-scripten. Mit systemd dürfte sich das aber ändern, was v.a. bei perl zuschlagen würde. bash läuft wohl eh und cut/grep/sed/awk dürften bzgl. Startzeit in etwa gleichauf sein. Achso, was ich schreiben wollte: wenn du die Tools kennst (und dabei helfen solche Threads), dann kannst du immer besser abschätzen, was effizient ist[2] und was nicht (und in einer Schleife über $viele Hosts z.B. "ewig" dauert). Um mal die wichtigsten 2 meiner Faustregeln zu nennen: - Prozesse starten ist lahm - x kann alles was auch y kann Liste (x<y): grep < sed < awk < perl[1] ed einzusortieren ist nicht ganz einfach (irgendwo sehr nah bei ed). Von (x)emacs (vim?) im batch-mode sowie python, lua etc. will ich hier nicht anfangen ;) Wenn man also irgendwo in ner Pipe ein 'sed' verwendet darf da eigentlich kein 'grep' mehr drin auftauchen (denn das kann sed selber, ist dabei aber teils arg lahm, da ist ein grep | sed ggfs. ok). awk kann noch mehr als sed und perl alles außer [1] was awk kann. Ich selber schreib mein längeren scripte inzwischen im Zweifelsfall in perl (und ein fertiges sub für's bequeme fehlerbehandelnde Aufrufen externer Programme hab ich auch ;) [1] mit einer Ausnahme: den "Record seperator", der darf bei awk auch ne Regex sein, bei perl nicht (und das nachzuarbeiten ist selten trivial, und braucht entweder mehr Speicher oder mehr Zeit). ==== man perlvar ==== HANDLE->input_record_separator( EXPR ) $INPUT_RECORD_SEPARATOR $RS $/ The input record separator, newline by default. [..] Remember: the value of $/ is a string, not a regex. awk has to be better for something. :-) ==== [2] bei perl "intern" gibt's da aber durchaus mal die ein oder andere Überraschung.
Du und ich und noch ein paar ... Was "man" daheim an der Konsole ist die eine Sache, was man in Scripte schreibet eine andere. Wenn man die Script aber publiziert oder Befehle in einer ML, NG oder nem Forum schreibt gelten andere Maßstäbe. Wenn du wüßtest, was ich hier im xterm schon an Mist getippert hab ... BTW: $ for f in ~/bin/*[^~]; do test -f "$f" || continue; file -- "$f"; done \ | awk '/shell/{s++;};/perl/{p++;}END{print s, p;}' 304 234 Ich glaub ich sollte mein ~/bin/ mal ausmisten. Da ist definitiv einiger "Schrott" dabei (aber viele Perlen, sach ich ma so ;)
BTW: deine is ein Fake. Das hat A. Schott an mich geschrieben. Und das auf einer anderen Liste ... .oO( gut daß ich auch (vermeintliche) Sigs meinerseits archiviere *hrhrhr* )
/tmp ist praktisch leer, in /var/ liegt ein großer Haufen logs # du -ms /var/cache/ /var/lib/ /var/log /var/tmp/ 6447 /var/cache/ 707 /var/lib/ 1319 /var/log 13 /var/tmp/ Äh, und der Rest dürfte dann /var/spool/news sein :P Da ich leafnode verwende (atime-basiertes "zu holen oder nicht") mach ich da mal kein 'du' drüber, will die Gruppen nicht wieder aus interesting.groups rauspopeln. Und ja, da liegen mind. 2 Gruppen mit nem dicken Archiv ;) Bei anderen könnte ich mal das expire anpassen oder sie gleich ganz rauswerfen, da ich da eh nix les. Aber so 2-3 Monate Archiv find ich schon angemessen ;)
Nein. Bin aber noch nicht dazu gekommen. Hab heute auch nochmal den nvidia-Treiber auf die 290.10 Version aus dem nvidia-Repo runtergezogen, nur um das auszuschließen, hatte ein paar Artefakte, das dürfte aber an der HW gelegen haben. Oder dem Mesa-Update heute. *GNORF* Das mit dem Kernel 3.3 war aber vor o.g. nur bis ich nen nvidia-Treiber unter 3.3 am Laufen hatte (naja, der Patch ist zum Glück einfach, ich kipp den hier einfach schonmal ab, der gilt AFAIK schon seit dem 270er Treiber, spätestens seit dem 290er, nur hat man vom RPM halt nicht das .spec + Patches): ==== diff -x '*~' -x '*.o' -urN NVIDIA-Linux-x86_64-295.33/kernel/conftest.sh NVIDIA-Linux-x86_64-295.33.dh/kernel/conftest.sh --- NVIDIA-Linux-x86_64-295.33/kernel/conftest.sh 2012-03-17 22:55:27.000000000 +0100 +++ NVIDIA-Linux-x86_64-295.33.dh/kernel/conftest.sh 2012-04-02 10:57:07.000000000 +0200 @@ -127,6 +127,7 @@ if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include -I$SOURCES/arch/x86/include/generated" + CFLAGS="$CFLAGS -I$OUTPUT/arch/x86/include -I$OUTPUT/arch/x86/include/generated" elif [ "$ARCH" = "ARMv7" ]; then CFLAGS="$CFLAGS -I$SOURCES/arch/arm/include -I$SOURCES/arch/arm/include/generated" fi ==== Die Folgefehler aus den fehlenden Includes sind teilweise extrem irreführend (und mit make -j > 1 hat man verloren ;) Achso, ja, der Patch sollte auch für kleinere Versionen passen, 290.10, und auch 270er. Evtl. noch älter. Verd....e Ka... hab ich da lange rumprobiert mit dem Krams bis ich auf obiges im conftest.sh gekommen bin. Kernel 'make *prepare', Argumente für den installer und und und und und. Hab mich schon beim überletzten Kernelupdate mit rumgeschlagen, und irgendwann aufgegeben und das 290er RPM installiert (was erfreulicherweise funktionierte). Den 295er mit 3.1.9er Kernel (der 12.1) hab ich noch nicht getestet. Das mach ich wohl als erstes. Und dann mal gucken ob der 290er mit dem Patch auch auf dem 3.3 läuft. Ist eben sehr zeitaufwendig, zumal wenn wie die Tage noch ein Mesa Update mal wieder an libGL.so* rummacht.
Na denn :) -dnh, der den 3.3 wg. dem wohl verbesserten I/O Verhalten auf z.B. USB Krams mal testen will -- *pieps* Die Verkehrshinweise: Im Netzwerkkabel von Marc 100 MB Stau wegen einer Vollsperrung der Ausfahrt Festplatte. Bitte warten Sie auf dem Rasthof FTP-Server. *pieps* -- C. Boltz -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (3)
-
Christian Boltz -
David Haller -
Joachim H.