Arbeitsthread zum Wiki

[intux]

Hi,

Was ist deine Erkenntnis, im Bezug auf 0A.D. ?

bin beim kopieren verrutscht. Es sollte heißen:

danke das du das geprüft hast. Ich habe jetzt mal geschaut bzgl. fglrx und googleearth. Bei openSUSE gibt es einen entsprechenden WIkieintrag [1]. Dort wird auch mit einem symbolischen Link zur entsprechenden libGL.so.1.2 das Problem gelöst. Ich werde das bei mir mal prüfen und melde mich dann nochmal.

Ich bin gespannt ob du zur selben Erkenntnis kommst wie ich!?
Sorry!!!

intux

[cronoik]

Mit dem fglrx benötigt man noch die entsprechenden 32 Bit libs. Ich habe es im Wiki ergänzt [1]. Kannst du das bitte nochmal gegenprüfen? Bisschen unsicher bin ich noch ob die Kategorie Browser passt.

[1] http://wiki.debianforum.de/Google_Earth ... .26_64_Bit

[intux]

Tut mir leid, aber ich habe echt Bauchschmerzen, da es so nicht funktionieren wird! Zwar kann man auf die libGL.so.1.2 der debianeigenen Pakete verlinken, doch funktionieren wird es nicht. Ich habe es getestet aber ohne Erfolg. Übrigens müsste der Link von libGL.so.1 auf libGL.so.1.2 zeigen. Es wäre schön, wenn jemand mit Wheezy und ähnlicher Konfiguration dies bestätigen könnte.

intux

[cronoik]

Was meinst du genau? Bei dir war das Problem das du einen fglrx verwendest und entsprechend musst du den Teil im Wiki mit fglrx abarbeiten, dort gibt es keinen symbolischen Link. Der muss nur beim freien Treiber angelegt werden.

[cronoik]

Tut mir Leid das ich mich bei deinem ersten Wikiartikel so einmische.

[intux]

Nein nein, ich bin doch für jede Hilfe und Unterstützung dankbar. Nur leider wird es eben so nicht funktionieren.

intux

[Saxman]

Nein nein, ich bin doch für jede Hilfe und Unterstützung dankbar. Nur leider wird es eben so nicht funktionieren.

/me macht zur Unterstützung eine Laola Welle..

[cronoik]

Na dann gibt es zweimal supi!
intux liest du dann bitte nochmal meinen anderen Post?

Was meinst du genau? Bei dir war das Problem das du einen fglrx verwendest und entsprechend musst du den Teil im Wiki mit fglrx abarbeiten, dort gibt es keinen symbolischen Link. Der muss nur beim freien Treiber angelegt werden.

[intux]

intux liest du dann bitte nochmal meinen anderen Post?

Ich habe nochmals nachgelesen. Ob es funktioniert kann ich jetzt nicht mehr sagen, da ich gestern auf Testing gesprungen bin.

Viel Erfolg noch!

intux

[cronoik]

Dann erkläre ich den Artikel jetzt für frei zum Review, da die abgedeckten Fälle bei mir funktionieren.

[intux]

OK, und ein großes DANKESCHÖN!

intux

[wanderer]

Ich habe gerade den Artikel MTP geschrieben und bitte nun um Review.

[Cae]

Sieht ziemlich gut aus. Ich hab' leider keine entsprechende Hardware zum Testen da, aber die Anleitung erscheint mir plausibel. Ein paar stilistische und Markup-Korrekturen habe ich eingefuegt.

Zu dem Abschnitt unten, der da sinngemaess heisst "lade von $irgendwo ein *.deb runter und installiere es per dpkg", sollte man noch in irgendeiner Form deutliche Warnungen drankleben, dass

• *.debs Skripte enthalten koennen und diese als root ausgefuehrt werden und
• dass durch dpkg -i die Signaturpruefung umgangen wird.

Effektiv fuehrt man damit also potenziell irgendwelchen Code aus dem Internet als root, ohne das vorher kontrolliert zu haben. Nicht so doll. Kommt aber im Wiki und auch sonst in Anleitungen oefters vor, da sollte man vielleicht mal eine generische Aufklaerung schreiben.

Gruss Cae

[wanderer]

Zu dem Abschnitt unten, der da sinngemaess heisst "lade von $irgendwo ein *.deb runter und installiere es per dpkg" ...

Gerade hab ich gesehen, dass ich da einen Blödsinn geschrieben habe . Es funktioniert doch nicht, das Binärpaket von Jessie in Wheezy zu installieren, wie ich gerade durch testen festgestellt habe. Man nur das Quellcodepaket von Jessie per apt-get source herunterladen, unter Wheezy zu einem Binärpaket bauen und dieses dann installieren. Also quasi ein Backport im Eigenbau. Ich werd das mal ändern.

Gibt es beim Download von Quellcodepaketen eigentlich eine Signaturprüfung?

[ViNic]

Hi, ich war mal so frei und habe einige Reviews entfernt.

Qtractor
UNetbootin
http://wiki.debianforum.de/%C3%9Cbersic ... _Verwalten

Getestet habe ich es nicht, ich berufe mich hier einfach auf den Hinweis - Getestet. Ich bearbeite Sachen, die ich gestartet habe. Einige Artikel sind schon sehr lange im Review und da sich keiner wegen Fehlern meldet, sollten weiteren Reviews entfernt werden. Ich schaue einfach, ob kleine Fehler zu erkennen sind, behebe die und entferne das Review. Einfach damit es in der Aufgabenliste http://wiki.debianforum.de/Kategorie:Review es mal vorwärts geht. Jeden Autor bitte ich, bei längeren Reviews den Review Status zu beenden. Schließlich kann man immer etwas nachtragen und aktualisieren. Sonst wirkt das debianforum.de/wiki noch lange einer Baustelle.

Sonst mache ich das

mfg

[niesommer]

Hi, ich war mal so frei und habe einige Reviews entfernt.

Jeden Autor bitte ich, bei längeren Reviews den Review Status zu beenden. Schließlich kann man immer etwas nachtragen und aktualisieren. Sonst wirkt das debianforum.de/wiki noch lange einer Baustelle.

Sonst mache ich das

mfg

OK, ich mach das mal für meine Beiträge:
https://wiki.debianforum.de/PlayOnLinux
https://wiki.debianforum.de/Wdm_-_WINGs_Display_Manager
https://wiki.debianforum.de/Worker
https://wiki.debianforum.de/Wmaker


So ist erledigt!

[cronoik]

Ich bin mir da ein bisschen unsicher ob das so gut ist. Der Reviewbanner ist kein Vermerk auf Unvollständigkeit, er drückt aus, dass dieser Artikel noch nicht kritisch von einer weiteren Person betrachtet wurde. Ich fände es als neuer Leser sogar besser wenn er da ist, da ich dann weis, dass ich das auf eigene Gefahr hin ausführe. Ich wäre deshalb dafür den Banner lieber ewig dran zu lassen, als ihn vorzeitig zu entfernen. Was denkt ihr?

[Dogge]

Hmm, Beiträge in Wikis oder Blogs können immer Fehler enthalten. Auch nach dem Review.

Edit: Wo es gerade eh um Reviews geht: Es gibt hier doch bestimmt Leute, die nen Debian-Server betreiben und nen Jabber-Server einreichten wollen. Ich würde mich freuen, wenn das jemand nach meinem Prosody-Eintrag durchexerziert und ein Feedback gibt. Der Artikel wurde zwar gereviewed und ein Prosody-Entwickler hat auch drüber geschaut (über google-translator ), aber wenn jemand bestätigt, dass er einen Server nach der Anleitung zum Laufen gebracht hat dann hat das doch eine höhere Qualität. Ich kanns leider selbst nicht testen, da ich nur shared-hosting auf uberspace habe und dadurch leider mit CentOS fremdgehe(n muss).

[Dogge]

Ich habe gerade den Artikel MTP geschrieben und bitte nun um Review.

Ich habe um auf mein Handy zugreifen zu können auch ne udev-rule anlegen müssen. Ist das mittlerweile nicht mehr so oder fehlt der Punkt noch in deinem Artikel?

Code: Alles auswählen

cat /etc/udev/rules.d/69-libmtp.rules 
# Motorola Moto G
ATTR{idVendor}=="22b8", ATTR{idProduct}=="2e82", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

[niesommer]

Ich bin mir da ein bisschen unsicher ob das so gut ist. Der Reviewbanner ist kein Vermerk auf Unvollständigkeit, er drückt aus, dass dieser Artikel noch nicht kritisch von einer weiteren Person betrachtet wurde. Ich fände es als neuer Leser sogar besser wenn er da ist, da ich dann weis, dass ich das auf eigene Gefahr hin ausführe. Ich wäre deshalb dafür den Banner lieber ewig dran zu lassen, als ihn vorzeitig zu entfernen. Was denkt ihr?

Da meine Beiträge eher dinge sind die andere eher nicht bzw. selten nutzen habe ich das für mich so gemacht wie
ViNic geschrieben hat. Bei Artikel die sich um Sachen drehen die sehr viele nutzen würde ich aber eher deiner Meinung folgen. Ich hoffe das klingt nicht zu verdreht. Deshalb habe ich sie auch gleichmal mit aufgeführt.
Reviews können ja auch nur von denen durchgeführt werden die sich damit ganz gut auskennen, was meiner Meinung nach der Grund für den Review stau ist. Und alles was ich über meine Artikel weiß habe ich im Artikel drin. Bei vielen der Review Artikel kann ich auf Grund fehlender Anwendung und Wissen leider nicht helfen, und ich denke ich bin da vielleicht nicht der einzige dem es so geht.
Und wer damit etwas machen will wird vielleicht auch daraufhinweisen das etwas nicht ganz so läuft wie es soll, und im Idealfall korrigiert derjenige es gleich.

[cronoik]

Ich kann mich dunkel erinnern das hnr [1], dass auch mal so gehandhabt hat und das von Saxman für gut befunden wurde. Um das auf einen Nenner zubringen, wäre es vielleicht nicht schlecht einmal die Kriterien für ein Review festzuhalten. Inklusive der anderen Posts würde ich vorschlagen:
*Rechtschreibprüfung,
*Ausdruck,
*grobe inhaltliche Kontrolle (also keine unnötigen Fremdquellen, sudo`s...)

Wenn der Artikel komplett inhaltlich geprüft wurde, dann kann zusätzlich der Getestet-Banner hinzugefügt werden. Der Vorschlag bedeutet natürlich auch, dass kein Autor seinen eigenen Banner entfernt [2]. Wäre das okay?

[1] Schade das er weg ist.
[2] Dementsprechend würde ich die Artikel von niesommer prüfen, damit der Banner nicht wieder dran muss

[niesommer]

Also ich für meinen Teil kann damit prima leben.

[ViNic]

Hallo,

ich habe weitere Review entfernt. Besonders alte Artikel, 2010, 2011, 2012 habe ich kaum durchgeschaut, nur grob überflogen. Neuere habe ich besser durchschaut (ab 2013 - bis Ende 2013), etwas korrigiert, nicht überall ein Review entfernt. Ansonsten auf die Fehler und Lesbarkeit geachtet. Es würde sich vielleicht lohnen, wenn andere nochmal drüber schauen, korrigieren und ihrer Seits dann das Review entfernen. Auf einigen Seiten fehlt mir ein Hinweis, am bestem vom Autor, ob es getestet wurde. Wenn ja mit welcher Version von Debian. Deshalb habe ich da kein Review entfernt. Ein Artikel war sogar fast nur Copy&Paste, das ich mehr abgeändert habe, jedoch kein Review entfernt habe. Aufgefallen sind mir desweiteren Artikel, wo Lizenzrechtliche Probleme aufgetaucht sind.

[cronoik]

An den Lizenzproblemen sitzen wir dran [1]. Saxman hat aber leider derzeit viel zu tun und auf seine Meinung zu dem Problem, möchte ich nicht verzichten.

[1] http://wiki.debianforum.de/Benutzer_Dis ... nzprobleme

[wanderer]

Ich habe gerade den Artikel MTP geschrieben und bitte nun um Review.

Ich habe um auf mein Handy zugreifen zu können auch ne udev-rule anlegen müssen. Ist das mittlerweile nicht mehr so oder fehlt der Punkt noch in deinem Artikel?

Code: Alles auswählen

cat /etc/udev/rules.d/69-libmtp.rules 
# Motorola Moto G
ATTR{idVendor}=="22b8", ATTR{idProduct}=="2e82", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

Welche Version von libmtp9 hast du installiert? Heute kam in die Wheezy-Backports die aktuelle Version 1.1.8 herein. Mit dieser Version dürfte das Problem gelöst sein. Ich habe heute in den Artikel den Hinweis eingebaut, dass man nach Möglichkeit die neueste Version dieser Bibliothek nutzen sollte, damit aktuelle Geräte problemlos funktionieren.
An sich dürfte das Problem das du hattest ofters bei neuen Smartphones auftreten. Hier wäre wahrscheinlich eine generische Anleitung, wie man udev-rules anlegt sinnvoll.