Hallo zusemmen,
Bin mir jetzt nicht sicher, ob das hier interessiert...
Jedenfalls habe ich heute früh einen update gemacht (via SVN), bis jetzt alles gut..
SVN und hier sollten momentan gleich sein oder ?
Ganz gleich nicht, meine Kommentare sind z.B. ja zum überwiegenden Teil dafür da festzuhalten, wo die Quelle zur Lösung zu finden ist bzw. das Problem zu finden.
Im ersten Post war zu HMUARTLGW schon gestern was zu lesen, und zum Rest seit eben.
HMLAN scheint ein Problem mit dem Einchecken zu haben, Details hatte Martin nicht mitgeteilt. Ich hatte erst die commandref im Verdacht, vermute jetzt aber eher einen neueren pre-commit-hook, z.B. "my $foo= 'Bäh' if $baz". Mehr weiß ich im Moment nicht, also falls jemand Ideen hat oder die betreffende Stelle identifizieren kann: gerne!
Was CUL_HM betrifft, gibt es zum einen gewisse Teile (rund um autocreate), die Martin nicht übernommen hat, aber die wesentlichen Teile schon. Das im Detail durchzugehen, wird etwas dauern, bei autocreate scheine ich das nicht gut erklärt zu haben...
Nach der Meldung von @benni wg. des Loggings gehe ich auch davon aus, dass wir da so oder so noch mal nacharbeiten sollten. Aktueller Ansatz dazu wäre, ein Internal hochzählen zu lassen und bei Nichtvohandensein des Internals auch eine (erweiterte) verbose 0-Meldung ins Log zu schreiben. So sollte das einmalig passieren, und man kann am Zähler erkennen, wie gravierend das Problem ist?
Weiter war da noch was mir den AES-Keys, das noch unrund war.
Was heißt das nun:
- die svn-Fassung sollte für die meisten User ok sein, wer HMLAN im Einsatz hat, sollte bis zum Einchecken eines Updates die gepatchte von hier verwenden.
- Wer noch nicht die gepatchte Fassung hatte oder bisher nicht ins Log geschaut hatte, sollte so oder so (von der svn-Vorversion oder einer früheren patch-Version kommend nach dem update) ins Log schauen, ob das wegen eines Konfigurationsproblems "explodiert" und die Ursache beheben
- dringliche Aktionen bzgl. update vs. Version von hier sind m.E. nicht erforderlich.
- Es wird vermutlich nochmal eine Runde geben zu den o.g. Problemen. Von daher wäre ich dankbar, wenn es wieder ein paar Tester gäbe, oder:
Falls jemand Muße hat:
- Mein nächster Ausgangspunkt betr. CUL_HM wäre wieder eine "verglichene" Version auf aktuellem svn-Stand.
- Über TYPE=autocreate kann man streiten, ich meine aber, die Prüfung auf aktiviertes Pairing sei sinnvoll. Vielleicht sollte man Martin diese vereinfachte Variante vorschlagen? (Falls ichwas übersehe, darf mich an der Stelle auch jemand wissendes bremsen).
- Es dürfte nicht so schwierig sein, die o.g. Punkte noch abzuarbeiten.
-- Speziell @benni: ggf. könntest du einen Vorschlag zu dem Counter-Thema liefern? (kann auch in die letzte patch-Fassung eingebaut sein)
-- das mit den AES-keys ist ein Sonderthema bei der Attr-Routine bzw. der NotifyFn, aber vermutlich auch nicht übermäßig komplex. Je schneller wir einen getesteten Lösungsvorschlag haben, desto schneller wird es im svn landen - also "Freiwillige vor" (auch hier ist es m.E. prinzipiell egal, welche Basis).
Hoffe, der Stand ist jetzt klarer.
