Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: ReinerS on 2018/07/23, 11:59:34
-
Gestern kam sddm mit nem du neu rein. Seitdem fällt er bei der Anmeldung immer wieder auf den Anmeldebildschirm zurück. Start mit startx funktioniert.
Yesterday sddm was updatet at du. Since then it returns always back to the login screen. Starting with startx works.
Fehlermeldung/Error messages:
[17495.752821] sddm-greeter[5650]: file:///usr/lib/x86_64-linux-gnu/qt5/qml/SddmComponents/LayoutBox.qml:59: TypeError: Cannot r
ead property of null
[17495.753111] sddm-greeter[5650]: file:///usr/lib/x86_64-linux-gnu/qt5/qml/SddmComponents/LayoutBox.qml:60: TypeError: Cannot r
ead property of null
[17495.753411] sddm-greeter[5650]: file:///usr/lib/x86_64-linux-gnu/qt5/qml/SddmComponents/LayoutBox.qml:51: TypeError: Cannot r
ead property of null
regards
Reiner
-
please paste
/etc/apt/apt.conf.d/80siduction
Bitte zeig uns mal jene datei.
edit, zweite Frage/ second question: welches theme benuzt Du / which theme are you using.
und/ and ist/is haveged installiert/installed
-
Aktuell versuche ich es mit debian-maui. Vorher hatte ich ein angepassten Theme aber dann gleich gewechselt da ich annahm dass es daran liegt.
/etc/apt/apt.conf.d/80siduction gibt es bei mir nicht (relativ neue Installation seit ein paar Wochen)
Seltsam, auf meinem anderen Rechner mit ner älteren Installation gibts die Datei.
I use actually debian-maui. Before I used an self adjusted theme, but I exchanged it as I believed that it was causing it.
/etc/apt/apt.conf.d/80siduction doesn't exist here (a quite new installation since some weeks)
Strange, on my other box with an older installation this File exists.
Grüße
Reiner
-
please provide
inxi -S -c0
and
ls /etc/apt/apt.conf.d/ | grep siduction
apt policy apt-conf-siduction
-
Inxi:
System: Host: RS8470p Kernel: 4.17.8-towo.2-siduction-amd64 x86_64 bits: 64 Desktop: Xfce 4.12.4
Distro: siduction 18.3.0 Patience - xfce - (201805132203)
root@RS8470p /h/reiner# ls /etc/apt/apt.conf.d/ | grep siduction
root@RS8470p /h/reiner# apt policy apt-conf-siduction
apt-conf-siduction:
Installiert: (keine)
Installationskandidat: 0.5.1
Versionstabelle:
0.5.1 500
500 http://packages.siduction.org/extra unstable/main amd64 Packages
500 http://packages.siduction.org/extra unstable/main i386 Packages
0.5.0 500
500 http://packages.siduction.org/fixes unstable/main amd64 Packages
500 http://packages.siduction.org/fixes unstable/main i386 Packages
regards
Reiner
-
Gerade festgestellt dass der andere Rechner, der normalerweise ne direkte Anmeldung ohne Passwort macht sich ähnlich verhält, nur dass er da immer gleich auf die Kommandozeile zurückfällt und dann wohl erneut die Anmeldung probiert.
Just realizes that the other box, which normally does an automatic login without password, shows similar behavior. But it seems to fall back onto command line and starts trying the login again.
Grüße
Reiner
-
ich babel mal auf deutsch weiter,
installiere erst mal apt-conf-siduction.
(ich frage mich, warum es nicht installiert ist)
So, ich lese da selbst gebasteltes sddm-theme, hat jenes jemals funktioniert bzw jemals richtig?
Funktionieren irgend welche themes, oder kommt dort die selbe fehlermeldung?
-
Installier ich gleich nach. Das selbstgebastelten Theme hat die ganze Zeit bis gestern Abend einwandfrei funktioniert. Es läuft ja auch mit den Standard-Themes (mit der selben Fehlermeldung) und auch beim anderen Rechner mit automatischer Anmeldung (ohne Theme (?)) auch nicht.
Ich habe mir die angemeckerte Datei mal angeschaut. Sieht mir eher so aus als würden Funktionen in qt (anchor.top etc.) nicht funktionieren oder fehlen.
Grüße
Reiner
-
verstehe ich das richtig?
Maui funktioniert auch nicht?
Ich kann es leider nicht nachvollziehen, hier™ funzt alles einwandfrei!
-
Ja, keines der Standard-themen. I werde mal die automatische Anmeldung bei dem anderen Rechner rausnehmen um zu sehen was der dann sagt.
Grüße
Reiner
-
ReinerS: haveged installiert und aktiv?
-
systemctl status haveged.service
● haveged.service - Entropy daemon using the HAVEGE algorithm
Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2018-07-23 08:28:46 CEST; 7h ago
Docs: man:haveged(8)
http://www.issihosts.com/haveged/
Main PID: 954 (haveged)
Tasks: 1 (limit: 4915)
Memory: 3.6M
CGroup: /system.slice/haveged.service
└─954 /usr/sbin/haveged --Foreground --verbose=1 -w 1024
Jul 23 08:28:46 RS8470p systemd[1]: Started Entropy daemon using the HAVEGE algorithm.
Jul 23 08:28:46 RS8470p haveged[954]: haveged: ver: 1.9.1; arch: x86; vend: GenuineIntel; build: (gcc 6.4.0 ITV); collect: 128K
Jul 23 08:28:46 RS8470p haveged[954]: haveged: cpu: (L4 VC); data: 32K (L4 V); inst: 32K (L4 V); idx: 22/40; sz: 31886/59215
Jul 23 08:28:46 RS8470p haveged[954]: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B): last entropy estimate 8.00093
Jul 23 08:28:46 RS8470p haveged[954]: haveged: fills: 0, generated: 0
Scheint so
Grüße
Reiner
-
peste mal bitte Deine etc/sddm.conf
-
sddm.conf:
[Autologin]
Relogin=false
Session=
User=
[General]
HaltCommand=
RebootCommand=
[Theme]
Current=debian-maui
CursorTheme=Vienna3Ubuntu
[Users]
MaximumUid=65000
MinimumUid=1000Grüße
Reiner
-
inxi -r -c0
bitte
-
Inxi:
root@RS8470p /etc# inxi -r -c0
Repos: No active apt repos in: /etc/apt/sources.list
Active apt repos in: /etc/apt/sources.list.d/deb-multimedia.list
1: deb http://www.deb-multimedia.org/ sid non-free main
Active apt repos in: /etc/apt/sources.list.d/debian.list
1: deb http://httpredir.debian.org/debian/ unstable main contrib non-free
2: deb http://httpredir.debian.org/debian/ testing main contrib non-free
No active apt repos in: /etc/apt/sources.list.d/downloads.list
Active apt repos in: /etc/apt/sources.list.d/dropbox.list
1: deb [arch=i386,amd64] http://linux.dropbox.com/debian/ sid main
Active apt repos in: /etc/apt/sources.list.d/google-talkplugin.list
1: deb http://dl.google.com/linux/talkplugin/deb/ stable main
Active apt repos in: /etc/apt/sources.list.d/liquorix.list
1: deb http://liquorix.net/debian/ sid main
Active apt repos in: /etc/apt/sources.list.d/playonlinux_wheezy.list
1: deb http://deb.playonlinux.com/ wheezy main
Active apt repos in: /etc/apt/sources.list.d/siduction.list
1: deb http://packages.siduction.org/base/ unstable main contrib non-free
2: deb-src http://packages.siduction.org/base/ unstable main contrib non-free
3: deb http://packages.siduction.org/extra/ unstable main contrib non-free
4: deb http://packages.siduction.org/fixes/ unstable main contrib non-free
5: deb http://packages.siduction.org/user/ unstable main contrib non-free
Active apt repos in: /etc/apt/sources.list.d/skype-stable.list
1: deb [arch=amd64] https://repo.skype.com/deb/ stable main
Active apt repos in: /etc/apt/sources.list.d/spotify.list
1: deb http://repository.spotify.com/ stable non-free
Active apt repos in: /etc/apt/sources.list.d/steam.list
1: deb [arch=amd64,i386] http://repo.steampowered.com/steam/ precise steam
2: deb-src [arch=amd64,i386] http://repo.steampowered.com/steam/ precise steam
Active apt repos in: /etc/apt/sources.list.d/teamviewer.list
1: deb http://linux.teamviewer.com/deb stable main
2: deb http://linux.teamviewer.com/deb preview main
Active apt repos in: /etc/apt/sources.list.d/x2go.list
1: deb http://packages.x2go.org/debian/ sid heuler
Habe den autologin auf dem anderen Rechner jetzt raus. Ist genau dasselbe Spiel.
Grüße
Reiner
-
benenn die /etc/sddm.conf um - braucht eh kein mensch :P
Schritt 2: galternatives und das sddm-theme damit setzen - debian alternativen sind immer ein grund zur Freude
-
@ Melmarker:
Hab ich gemacht, hat aber nichts verändert. Habe jetzt an Themen nur debian-maui und patience zur Auswahl.
Danach mal nen Neustart mit neuerem Kernel gemacht, sddm und themes entfernt und nochmal probiert.
Leider nach wie vor keinerlei Änderung. Nach dem "Login" rödelt die Kiste kurz, bringt im Journal die Fehlermeldungen und startet anscheinend sddm neu.
Wenn ich nicht anscheinend der Einzige wäre dem das passiert (und das gleich auf zwei Rechnern) würde ich ja dringenst QT5 oder eines der dazugehörigen "Anhängsel" verdächtigen. ;)
Grüße
Reiner
-
als Du hast mit
apt purge sddm* das geraffel deinstalliert und dann mit apt install --install-recommends sddm sddm<theme> wieder installiert?
-
So ähnlich aber mit synaptic. Kanns aber gerne nochmal mit apt versuchen.
Grüße
Reiner
-
@hendrikL:
Habe sicherheitshalber noch mal genau so gemacht. Dasselbe Spiel.
Grüße
Reiner
-
Festplatte voll?
-
nun, ja ich glaube auch das da etwas nicht stimmt, multimedia und synaptic!
Es ist nicht umsonst, dass wir alle sagen, kinners tut das nicht, es geht früher oder später schief.
Bei solch waghalsigen experimenten, sollte man sehr genau wissen was man tut!
Das ist so gut wie nicht zu debugen, wo soll man da ansetzten?
Ich beantrage den Thread nach experimente zu verschieben, dies ist keine upgrade warnung und hat damit überhaupt nichts zu tun, es ist ein schief gegangenes experiment!
Wenn man so etwas macht, dann bitte mit einem spiel rechner, den man ohne Reue wieder neu aufsetzen kann.
So zum lernen, aber ansonsten, bitte macht doch so etwa nicht mit den Alltagsrechnern.
-
@VoFiWG:
Leider nein.
@hendrikL:Also alles was recht ist aber "experimental" "waghalsige Experimente"? Gehts noch? >:(
Da laufen zwei Rechner brav und treu teilweise über Jahre, dann spinnt, aus welchen Gründen auch immer, ein Programm bei beiden Rechnern (einer vor ein paar Wochen neu installiert) nachdem sich wahrscheinlich was in QT und/oder sddm geändert hat und dann sollen synaptic und oder multimedia schuld sein?
Obwohl die Fehlermeldung doch sehr nach irgendwas in QT hindeutet ?
Also wirklich, so einen Unfug habe ich jetzt schon lange nicht mehr gehört!
Ich löse das Problem jetzt selbst dahingehend dass ich erstmal auf sddm verzichte und mit gdm3 weitermache bis es vielleicht mit sddm wieder läuft.
Du kannst den Thread gern hinschieben wo immer du ihn auch haben willst, ich werde ihn als "für mich gelöst" markieren.
Grüße
Reiner
-
Und genau hier hake ich mal ein. hendrikL hat es haargenau auf den Punkt gebracht, allerdings war er wie immer sehr zurückhaltend und feinfühlig in der Wortwahl.
deb http://www.deb-multimedia.org/ sid non-free main
deb [arch=i386,amd64] http://linux.dropbox.com/debian/ sid main
deb http://dl.google.com/linux/talkplugin/deb/ stable main
deb http://liquorix.net/debian/ sid main
deb http://deb.playonlinux.com/ wheezy main
deb [arch=amd64] https://repo.skype.com/deb/ stable main
deb http://repository.spotify.com/ stable non-free
deb [arch=amd64,i386] http://repo.steampowered.com/steam/ precise steam
deb-src [arch=amd64,i386] http://repo.steampowered.com/steam/ precise steam
deb http://linux.teamviewer.com/deb stable main
deb http://linux.teamviewer.com/deb preview main
deb http://packages.x2go.org/debian/ sid heuler
Da ich mich nicht unbedingt an solche Sachen wie Feinfühligkeit, Korrektheit (ausser fachlich) und ähnlichen Schmus gebunden fühle, hier meine Einschätzung:
Gratulation, diese Installation definiert Frankensid(uction) wirklich neu, Respekt. Wir lehnen in Kenntins der Paketliste jeglichen weiteren Support vollkommen ab.
-
@Melmarker:
Bitte sehr, wie ihr wollt. Ob ich diese Pöösen Repos auch alle nutze hat ja auch keiner gefragt. ;)
Inzwischen habe ich anderweitig eine Lösung gefunden, war wohl doch nicht der Einzige der sowas mal hatte (ganz ohne synaptic und multimedia-Gedöns).
Was die "Feinfühligkeit" betrifft: Wenn man die ganze Zeit die tatsächlichen Fehlermeldungen ignoriert und mehr im Dunkeln rumstochert und nichts findet bzw. keine Idee mehr hat akzeptiere ich das duchaus. Geht mir ja auch oft genug so.
Dass dann aber ohne jeden wirklichen Zusammenhang oder tatsächliche Hinweise eben mal wieder die "synaptic" und "Multimedia" Schublade aufgemacht wird aktzeptiere ich eher nicht. Da hatte ich eigentlich gedacht dass man/wir bei siduction inzwischen weiter wären. Verborke ich mein System bin ich auch der Erste der das zugibt und im Zweifelsfall halt neu installiert.
Würde mich allerdings dann auch nicht wundern wenn ihr dann demnächst bei kniffligen Frage "Debian-Stable" als das einzig Richtige und alles Andere als Teufelswerk und Ketzerei bezeichnet! ::)
Grüße
Reiner
-
Hast du mal einen Kernel =< 4.15 probiert. Das Problem wurde vermutlich mit einem Dist-Upgrade am Freitag, den 20 Juli eingeschleppt. Ursächlich verantwortlich ist vermutlich CVE-2018-1108. Auch bei Ubuntu gab es eine entsprechende Regression.
Das Problem scheint zu sein, dass das System beim Hochfahren einen Prozess zum Erzeugen von Entropie abbricht in der Annahme, er sei bereits beendet. Mehr konnte ich mangels Zeit nicht herausfinden. Auf debian-kde@lists.debian.org gibt es auch einen Thread dazu.
-
Wenn das so ist, dann wäre die Install von haveged sinnvoll.
-
@devil: war ziemlich defiiniv wohl sddm vom 22.Juli.
Kann natürlich sein dass die von dir erwähnten Probleme da auch noch mit reinspielen.
Es gibt 3 Lösungsansätze:
1) Die brutale Art (gefunden bei Arch) => Neuinstallation
2) Etwas eleganter (hat mich letztendlich auf die Spur gebracht) => Neuer User, Daten übernehmen.
3) Änderung meinerseits => bash statt fish wieder zur Standardshell machen.
Ich muss zu meiner Schande gestehen dass ich vor etwa nem halben Jahr auf Empfehlung einer sehr eloquenten, ebenfalls nicht immer feinfühligen, jungen Dame (mit, in diesem Bereich, deutlich mehr Wissstand als ich) die fish (aus Debian, nix multimedia oder pööse Repos) mal ausprobiert habe und , da sie gut funktionierte, beibehalten habe. ;)
Hat auch bis gestern noch gut funktioniert, bis ich neu hochgefahren habe und der neue sddm "zuschlug".
Hier noch ein aktueller Kommentar der Jungen Dame:
Wie elendig muss man bitte einen DM verkacken dass dir Standardshell das Ding in die Knie zwingt? 😂
Grüße
Reiner
-
@towo: havegd war schon drauf, meine ich.
Grüße
Reiner
-
Dann sag dem Fräulein mal, der DM sei nicht schuld sondern der Kernel (und nichtmal ursächlich der aus Debian).
-
Hmm, bin ich nicht sicher. Aktuell habe ich 4.17.9-towo.1-siduction-amd64 drauf.
Aber ich gebe es weiter. :D
Grüße
Reiner
-
Deswegen war meine Frage nach haveged. qt-kde hat das entropieproblem jetzt damit gelöst, dass sie sddm ein recommend auf haveged gegeben haben. Wir hatten haveged schon vorher - um andere Sachen zu erleichtern oder stark zu Beschleunigen: halt alles was Entropie braucht und wo es nervig wird, wenn man diese nicht hat. Wer schon einmal einen 4K-Schlüssel auf die Schnelle erzeugen musste, weiss, wieviel Mausbewegungen und sinnloses Tastaturgeklimper man braucht, wenn der Rechner grad gestarted ist.
Bei einem nicht startenden sddm sieht das ganz leicht anders aus: Im vorliegenden Fall ist das Ding auf die Nase gefallen, weil ein paar Properties nicht da waren - da das parent properties waren, bedeutet das, dass der Parent nicht erzeugt oder gleich wieder abgeräumt wurde. Kann mit Entropie zusammenhängen, muss aber nicht. Wahrscheinlicher ist es halt, dass irgendetwas(tm) die Verarbeitung von QML gestört hat. Und genau in diesem Fall haben wir keinerlei Chance mehr, was zu tun.
BTW: Antwort zur shell - goarnyx - separates Problem, es ist oftmals so, dass Dinge nicht so sind, wie sie beim ersten, zweiten und dritten Draufschauen scheinen. Wenn das anders wäre - das wäre ja nicht zum aushalten, das wäre total langweilig.
-
Dass dann aber ohne jeden wirklichen Zusammenhang oder tatsächliche Hinweise eben mal wieder die "synaptic" und "Multimedia" Schublade aufgemacht wird aktzeptiere ich eher nicht. Da hatte ich eigentlich gedacht dass man/wir bei siduction inzwischen weiter wären. Verborke ich mein System bin ich auch der Erste der das zugibt und im Zweifelsfall halt neu installiert.
tja, du hattest den fred direkt zugemacht, denn ich hätte Dich dann als nächstes nach und nach dein System aufdröseln lassen.
Ich hatte die entropie (haveged, siehe ersten post von mir und von Dir unvollständig beantwortet) oder qt in verdacht, weiterhin hatte agaida sämtliche isos durch getestet und keinen fehler in sddm gefunden.
Also haben wir mal ins blaue geschossen, die Kristallkugel ist uns leider verlustig gegangen, und haben Dir Information für Information aus der Nase gezogen, bis Du den fred mehr oder minder beleidigt geschlossen hattest!
Und wenn ich an qt denke, multimedia sehe, da kommt mir als erstes vlc in den Sinn und jener nutzt nun mal auch qt.
Dann sehe die ganzen anderen Quellen und denke mir, naja da sieht mindestens eine nach Ubuntu aus, wo speichern die den ihr qt geraffel usw.....!
Da ist nix böse und plöde, auch nicht so gemeint, die haben andere Standards, ganz einfach.
Wobei deb-multimedia noch ein Sonderfall ist!
Die Pakete werden zwar für debian paketiert, nur hält man sich da nicht an den debian Standard und da kann es sehr schnell oder auch schleichend, früher oder später zu Problemen kommen, welche Paket-Abhängigkeiten betreffen und die sind dann nicht mehr mal so einfach zu lösen.
Synaptic ist für sid/unstable nicht gerade das tool der ersten Wahl, für stable und testing ok, wobei testing naja.
Apt hat für unstable den besten problem solver, also kann mit abhängigkeiten und so am besten umgehen was sid/unstable angeht.
Dieses zum Xten mal zum Verständnis, warum wir auf so etwas (Franken-Siduction³) so reagieren.
-
Also mit havegard hast du Recht, ich hatte es einfach überlesen/nicht kapiert. Später stellte sich aber, meine ich, heraus dass es installiert war.
Ich gebe zu dass meine sources.list ziemlich verstrubbelt ist da ich mal gelegentlich was probieren wollte und sie hinterher nicht wirklich aufgeräumt habe, sowie die immer "mitgenommen" habe. Muß ich mir mal wieder durchsehen und bereinigen.
Die Probleme die synaptic manchmal bringt sind mir auch nicht unbekannt, darum benutze ich es mit der gebotenen Vorsicht. Ansonsten nehme ich auch meistens ausschlieslich apt.
Ubuntu Pakete habe ich nicht drin, Teamviewer ist vor einiger Zeit rausgeflogen, anydesk dafür reingekommen. Liquorix habe ich noch mit drin, benutze aber die Kernel schon länger nicht.
Als zusätzliche Repos sind eigenlich nur deb-multimedia und heuler (x2go) tatsächlich aktiv.
X2go für Funktionalitäten in meinem lokalen Netzwerk die ich so nicht in Debian gefunden habe.
Deb-Multimedia ist allerdings ein ganz anderer Fall:
Ich benutze deb-multimedia seit seligen Kanotix-Zeiten weil es damals von Debian nicht wirklich was Brauchbares in dem Bereich gab.
Erst später kamen dann Debian-Entwickler angedackelt und wollten nach dem Motto "Wir auch" ("wir sind die Größten") da mitmischen. Die Pakete die die dann damals hatten waren eher bestens "halbgar", aber sie hatten auf einmal den Anspruch "Debian" zu sein und selbst die "Regeln" zu bestimmen. Gab da auch damals ziemlich Krach deswegen.
Ich habe damals beschloßen die Schiene deb-multimedia weiterzufahren und habe damit bisher über mehrere sid-Distros keine wirklichen Probleme gehabt ausser dass sich gelegentlich Pakete von Debian dazwischendrängeln wollten. Vielleicht habe ich die ganzen Jahre ja auch nur Glück gehabt.
Bei Fragen hatte ich immer schnelle und brauchbare Reaktionen (bei Debian nicht immer soo wirklich) vom "freundlichen Franzosen" und habe ihn auch deshalb entsprechend weiterempfohlen. Zur Zeit läuft deb-multimedia auf 8 von mir betreuten und 3-4 weiterempfohlenen Debian Distros problemlos.
Bei einer Installation/Neuistallation ist deb-multimedia deshalb auf allen vor mir betreuten Debian/siduction Systemen mit das Erste was ich nach der Installation einrichte. Vielleicht tue ich den Debian-Entwicklern ja inzwischen Unrecht und die Pakete von denen sind inzwischen genauso gut, aber warum sollte ich das Risiko eingehen und umsteigen?
Wenn das diese Systeme zu "Frankensid" macht ist es halt so. Vielleicht benenne ich dann deren Systemkennung in "Frankensid" um damit es keine unliebsamen Verwechslungen gibt. :)
Grüße
Reiner
-
Erm - hendrikL - und hier irrst Du ganz gewaltig: Marillat ist DD (https://nm.debian.org/person/marillat) - das ist also etwas anderes, vergleichbar mit gutem Benehmen: Nur wer die Regeln verinnerlicht hat, kann sich wirkungsvoll über sie hinwegsetzen, sie umgehen oder aushebeln, ohne sich zur Wurst zu machen 8) - Rein technisch sind die Pakete 1a. Über das, was dieses nette Repo so toll für Sid macht, habe ich mich schon mehrmals ausgekotzt und möchte das nicht wiederholen (Stichwort: epoch).
Thema fish: ReinerS - bitte erklär Deiner Bekannten höflichst, dass Sie sich bitte mit solchen Äusserungen zurückhalten sollte, wenn sie keinerlei Plan hat - das wirkt nur peinlich. Nur so zur Erläuterung - bei mir hat fish als shell auch nicht auf Anhieb funktioniert - wenn allerdings die debian bash-completion auch in fish reingrätscht und damit die Ausführung der startup-scripts unmöglich macht - hmm, also ich tue mich sehr schwer damit, diesen umstand sddm anzulasten. Soviel zur Aussage:
Wie elendig muss man bitte einen DM verkacken dass dir Standardshell das Ding in die Knie zwingt? 😂
Btw: Den Grund für den "Fehlschlag" der Anmeldung findet man in den x-logs. Aka: Die Anmeldung samt PAM ist tutto completo gelaufen, leider fällt dann ein nachgeordnetes script auf die Fresse und hui: Rückfall auf den login-screen. apt purge bash-completion hilft gar fein.
(Wenn die junge Dame sich Janne K. nennt, dann schöne Grüße)
-
Noch nen Nachtrag: fish fällt bei einem unmotivierten shopt auf die Fresse - und shopt ist wirklich bash-spezifisch. Gesetzt den Fall, dass fish nen Versuch macht, die vorhandene .bashrc zu interpretieren und dabei die Contenance verliert - erm ja - zsh macht solchen Scheiss nicht. Und ganz eindeutig wäre das dann ein Fehler vom Flossenviech, dass man den Devs mal mitteilen sollte. Wenn die tatsächlich in Ermanglung von was besserem die ~/.bashrc nutzen sollten, dann sollen sie zumindest sicherstellen, dass shopt ein noop ist und lautstark darauf hinweisen, dass der nicht ausgewertet wird. Wäre zumindest ein Ansatz.
Edit: Es kann natürlich auch bei debian verfrickelt worden sein - der Ansatz, der mit der bash-completion gegangen wird ist zumindest fragwürdig und hat mir schöne Stunden beschert: bash-completion verteilt auch die zsh-completion - was aufgrund der Namensgebung des Pakets nun wirklich nicht wirklich auf den ersten Blick erkennbar ist.
-
@Melmarker:
Das mit dem "kein Plan" erzähl ich ihr lieber nicht. Vielleicht liest sie es ja als Gast mit. :)
Du könntest da duchaus extrem schief liegen. ;)
Eine Janne K. ist mir nicht bekannt, Die Bekannte werkelt in England, neben dem Studium, bei der ESA rum und hat wohl vorher für Canonical/Ubuntu (ist halt in schlechte Gesellschaft geraten, aber zu Debian kontne ich sie nicht bekehren ;D ) Programme verbrochen/verzapft.
Was bitte ist ein unmotivierter shopt?
Zu fish kann ich nur sagen, bis gestern gings etwa seit nem halben Jahr problemlos, Neu war nur der sddm vom 22.7.. Wo genau was/es verfrickelt wurde kann ich als Nicht-Programmierer eher nicht feststellen. Habe mich halt auf die offensichtlichen Fehlermeldungen gestürzt. X-Log hatte ich nicht auf dem Plan, hat auch keiner gefragt.
Grüße
Reiner
-
hihihi - ok, ikke hab das mit fish jetzt nicht wirklich tiefgründig debuggt. ich war nur mal so frei auf meiner Produktionsinstallation folgendes zu machen:
apt install fish
sudo chsh -s /usr/bin/fish agaida
und mich neu einzuloggen - wie von hendrikL bestätigt ging das erst mal nicht, journald war unauffällig, aka die PAM-Aufrufe liefen problemlos durch. Nu gut, dann hab ich mir halt die üblichen Verdächtigen angeschaut. Gefunden hab ich:
* in sddm:
# in sddm-0.18.0/debian/Xsession
*/fish)
[ -f /etc/profile ] && . /etc/profile
xsess_tmp=`mktemp /tmp/xsess-env-XXXXXX`
$SHELL --login -c "/bin/sh -c 'export -p' > $xsess_tmp"
. $xsess_tmp
rm -f $xsess_tmp
Dat bedeutet im Klartext, dass sddm netterweise /etc/profile sourced. Und das bedeutet:
# ende of /etc/profile
if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi
Nu ja - dann schaut man da mal rein und sieht zu, welches dieser scripts halt nen Fehler wirft. Voila:
/etc/profiles.d/bash_completion.sh wars - erstaunlicherweise funktionieren die von uns mitgelieferten scripts (oder besser - stören nicht weiter)
Und jetzt kommt halt der Clou:
https://github.com/sddm/sddm/issues/879
und https://github.com/sddm/sddm/commit/f749f1d65165de7ce7b9ae073b19f057b205ab35
tja - halt nur doof, wenn ein File in /etc/profiles.d/ giftig für den fish ist - ich hatte erst unsere Erweiterungen in Verdacht - aber nö, dat war das offizielle script von bash-comletion in debian, was für Zerstreuung sorgt.
Ich gebs ungern zu, auch wir sind in dieser Hinsicht nicht ganz sauber und eigentlich richtig grundfalsch - weil die Kennzeichnung eines Scripts mit .sh - was eingentlich ein posix-kompatibles shell script sein sollte - und dahinter ein script mit bashisms zu verbergen ist zugegebenermaßen ein ganz klein wenig mehr als Panne. Zu unserer Entlastung kann ich nur behaupten, darauf acht gegeben zu haben, dass ich halt keine bashisms - oder keine giftigen - benutzt zu haben :)
-
Und noch nen Nachtrag für alle Fischliebhaber:
https://github.com/jamtur01/sddm/blame/0ec15e9a6d96075db3e6664d2f9a3f37183a8c1b/data/scripts/Xsession#L42
- [ -f /etc/profile ] && . /etc/profile
+ [ -f /etc/profile ] && . /etc/profile | true
Löst auch das erst mal auf die ganz harte Tour. Bevorzugt ändert man das in /etc/sddm/Xsession
-
ReinerS: Erstaunlich - aber ok, weder synaptic noch deb-mm sind schuld, den Tag streich ich mir rot im Kalender an. Und InformatikstudentInnen sind die sind die Schlimmsten, wenn es um ohne Plan geht, vertrau mir, ikke hab das auch mal studiert :P
Ändert nix an meiner Grundeinstellung zu Frankensids, deb-mm und der allgemeinen Wartbarkeit von Systemen. Und ich hab jetzt ein kleines Problem damit, wem ich diesen netten Bug ans Bein tacker:
* fish soll nich so sauer sein, wenn mal was nicht passt
* bash-completion soll nix für Fische giftiges ausliefern
* sddm soll nicht aus der Anmeldung rausfliegen, weil beim Sourcen von profiles.d irgend ein bescheuerter Fehler auftritt.
Normal müsste man alle 3 Pakete abwatschen.
-
Auf meinem Rechner laufen zwei siductions, komplett aktualisiert, aber an verschiedenen Tagen.
In einer Installation funktioniert die Anmeldung per sddm, in der anderen nicht. >:(
Standard apt-sources, haveged installiert.
Bisher aus diesem Thread nicht schlau geworden. :(
Geht wieder nach Neustart - wohl einmaliger Ausrutscher?
Sorry für die Ruhestörung! :-[
-
So - und dank permanenter Nörgelei meinerseits ist die für ReinerS relevante Zeile aus debians sddm raus. Ich gebs zu, dass mein Lösungsansatz den Fehler nur zugekleistert hat. Maxy war da gründlicher und seine Erklärung ist auch besser - und vor allem auch richtig. ;)
* https://salsa.debian.org/qt-kde-team/3rdparty/sddm/commit/27bc924c9231b81a33d714e8ef6bec1e19ee5240
* https://salsa.debian.org/qt-kde-team/3rdparty/sddm/commit/bfbd6c3665bcb47b456f4c319b9e341a8322d210
und so kann man dann auch meinen Lösungsansatz in die Tonne kloppen - ich bin von der irrigen Annahme ausgegangen, dass fish posix-kompatibel ist - isser natürlich™ nicht, also keine Standard-Shell. Ein Blick meinerseits auf die Seite vom Upstream hätte gereicht, um diese irrige Annahme aufzuklären.
Jetzt muss das Zeug nur noch irgendwann in Sid erscheinen. Schätzungsweise wird das dann sein, wenn die Qt-Transition soweit durch ist, dass das auch wieder baubar ist.
-
Gut, dann warte ich das mal in Ruhe ab. :D
Grüße
ReinerS