Für mich "gelöst": sddm und fish (und Kernel?) scheinen sich nicht zu vertragen.

[devil]

Dann sag dem Fräulein mal, der DM sei nicht schuld sondern der Kernel (und nichtmal ursächlich der aus Debian).

[ReinerS]

Hmm, bin ich nicht sicher. Aktuell habe ich 4.17.9-towo.1-siduction-amd64 drauf.
Aber ich gebe es weiter.
Grüße
Reiner

[melmarker]

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.

[hendrikL]

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.

[ReinerS]

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

[melmarker]

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 - 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)

[melmarker]

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.

[ReinerS]

@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 ) 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

[melmarker]

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


# 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:

Code Auswählen Erweitern


# 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

[melmarker]

Und noch nen Nachtrag für alle Fischliebhaber:
https://github.com/jamtur01/sddm/blame/0ec15e9a6d96075db3e6664d2f9a3f37183a8c1b/data/scripts/Xsession#L42

Code (diff) Auswählen Erweitern


- [ -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

[melmarker]

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

Ä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.

[samoht]

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! 

[melmarker]

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.

[ReinerS]

Gut, dann warte ich das mal in Ruhe ab.
Grüße
ReinerS