Du bist nicht angemeldet.
Hi,
ich hatte heute ein Problem trotz SVN Schreibrechten und weiss jetzt nicht ob Sourceforge schuld ist oder man beim Projekt selbst was geändert hat, das war mir nicht so wirklich ersichtlich.
1. Ich durfte zwar weiterhin https://avmload.svn.sourceforge.net/svnroot/avmload lesen aber nicht mehr schreiben.
2. Laut Fehlermeldung sollte ich auf http://svn.code.sf.net/p/avmload/code ausweichen, gut das es https sein muss wurde bei der nächsten Meldung klar.
3. Erst https://svn.code.sf.net/p/avmload/code durfte ich Schreiben aber dort greift Fritz!Load für Updates wohl nicht zu. Laut Source => http://avmload.svn.sourceforge.net/view … owRevision
Jedenfalls konnte ich den Online-Updater dadurch nicht wirklich testen ob dann mit der neuen Revision noch alles in Ordnung ist. Interne Tests zeigten das alles okay sei.
Aus dem Grund habe ich mir die Datei gui_update.cgi näher angeschaut und da hatte ich noch mehr Fragen als Antworten danach.
1. Warum wird die Revision unter http://tangoiconsprite.svn.sourceforge. … oad/trunk/ geprüft ?
2. http://avmload.svn.sourceforge.net/view … /?view=log läuft bei mir in einen Timeout oder ähnliche Probleme rein per Fritz!Load+Browser.
3. Gibt man eine höhere Revision als im Repository an, dann ändert Fritz!Load es darauf aber updatet natürlich nichts ausser der Nummer.
Da SF ziemlich auf https abfährt sollte man die Urls vielleicht anpassen.
Mir geht es nicht darum eine Änderung direkt einpflegen zu können aber man räumte diese Möglichkeit vor einiger Zeit dem genutzten Account ein. Kann gerne auch jedes Update per Ticket/Tracker/Thema einreichen. Laut https://sourceforge.net/p/avmload/code/HEAD/tree/ ist es jedenfalls eingecheckt...
Vielen Dank.
Join 9kw.eu Captcha Service now and let your Fritz!Load continue downloads while you sleep.
http://www.9kw.eu/
Abwesend
Da muss einiges überarbeitet werden, da SourceForge das Projekt (wie schon lange mal angekündigt) konvertiert hat.
Deswegen wird jetzt einiges nicht funktionieren und vieles muss angepasst werden.
Abwesend
Gibt's jetzt eigentlich auch sowas wie die timeline fürs neue repository?
https://sourceforge.net/apps/trac/avmload/timeline geht ja nicht mehr, bzw. zeigt nur die Tickets an, aber keine Codeänderungen mehr.
Ein Update der F!L Version mit Bordmitteln ist auch nicht mehr möglich, ich habe halt dann einfach jetzt den ganzen neuesten trunk rüberkopiert.
Sollte man das irgendwo ankündigen oder habe ich es übersehen?
Abwesend
Gibt's jetzt eigentlich auch sowas wie die timeline fürs neue repository?
Würde mich auch interessieren. Hab ja nichts gegen Fortschritt oder einer Umstellung von Sourceforge und ähnliches aber aktuell ist es alles eher Murks.
Sollte man das irgendwo ankündigen oder habe ich es übersehen?
Dann bin ich genauso Blind.
Join 9kw.eu Captcha Service now and let your Fritz!Load continue downloads while you sleep.
http://www.9kw.eu/
Abwesend
Ihr könnt diesen Link verwenden:
http://sourceforge.net/p/avmload/code/HEAD/log/?path=
Der interne Updater funktioniert derzeit übrigens wie schon oben angemerkt nicht, da SourceForge auf Allura umgestellt hat.
Am einfachsten wäre es, einen svn-Clienten auf die Fritzbox zu bringen, um die Funktionalität wiederherzustellen. Es geht natürlich auch ohne und würde wahrscheinlich auch performanter laufen.
Der Beitrag wurde geändert von roadman17 (am 13. Jun. 2013 um 18:13 Uhr)
Abwesend
Danke für den Link zur Versionierung.
Updates funktionieren nur händisch zur Zeit, also trunk holen und auf die Box kopieren.
Abwesend
Am einfachsten wäre es, einen svn-Clienten auf die Fritzbox zu bringen, um die Funktionalität wiederherzustellen.
Hier mal die svn binaries 1.7.10:
71xx/72xx Reihe:
http://thomasheinz.net/fritz/svn/little … 1.7.10.tar
73xx Reihe:
http://thomasheinz.net/fritz/svn/big_en … 1.7.10.tar
Codebeispiele:
Fritz!Load auschecken (einmalig):
./svn checkout svn://svn.code.sf.net/p/avmload/code/trunk/FritzLoad /var/media/ftp/WD-Elements1023-01/fritzload
Fritz!Load updaten:
./svn up /var/media/ftp/WD-Elements1023-01/fritzload
Der Beitrag wurde geändert von TomTomNavigator (am 15. Jun. 2013 um 14:15 Uhr)
Abwesend
Das klingt ja schon mal gut!
Zwingt das die Box in die Knie oder läuft es einigermaßen zufriedenstellend?
Abwesend
Das klingt ja schon mal gut!
Ja, sehe ich auch so - zumindest bis das eingebaute Update-Verfahren wieder funktioniert (wenn denn überhaupt ...).
Zwingt das die Box in die Knie oder läuft es einigermaßen zufriedenstellend?
Ich hab's hier auf einer 7170 installiert - beim ersten checkout (der das Ganze sozusagen initialisiert) gab's Probleme, weil wohl zu viel anderes Zeug noch an der Bandbreite gefressen hat; das führte dann zu timeouts und unvollständigem checkout. Beim anschließenden update-Versuch hieß es dann für ganze Unterverzeichnisse: "Node remains in conflict".
Habe dann den gesamten Inhalt des lokalen Fritzload-Verzeichnisses woanders in ein backup-Verzeichnis verschoben, den Inhalt des .svn-Verzeichnisses gelöscht und das Ganze (checkout) noch mal in Ruhe durchlaufen lassen. Das dauert dann schon mal einige Minuten; anschließend sind alle Dateien aus dem Repository geholt und die SVN-Datenbank aufgebaut. Man darf nicht vergessen, die einschlägigen Dateien aus dem Unterverzeichnis FritzLoad/config wieder aus dem backup-Verzeichnis in das "Live"-Verzeichnis zu kopieren; wenn man will, auch die Zähler für den Captcha-Service in FritzLoad/log/captcha_*_counter.*.
Das anschließende Update war in ein paar Sekunden getan (war ja auch nix zu kopieren). Dieses Update wäre dann auch für den täglichen Betrieb in Betracht zu ziehen; das dürfte keine Box in die Knie zwingen. Ich hab mir das als täglichen Job in die crontab eingebaut (morgens um halb vier ist die Welt noch in Ordnung).
Wie sich das auf die Versionsanzeige in der Fritzload-Oberfläche auswirkt, weiß ich nicht. Bisher habe ich in den letzten Tagen festgestellt, dass nach händisch eingespielten Updates bei Fritzload immer noch die alte Version angezeigt wird; ein anschließendes diff-update tut dann de facto eigentlich gar nichts, stellt aber wenigstens die Anzeige der aktuellen Version her. Ich nehme an, dass dieses auch auf Updates per SVN zutrifft.
Den aktuellen Status kann man sich übrigens so anzeigen lassen, das kann dann aber auch wieder ein paar Minuten dauern:
./svn status /var/media/ftp/STICKFAT/FritzLoad
Von mir ein Danke an TomTomNavigator für den SVN-Tipp und -Link!
Fritz!Box 7362 SL - FRITZ!OS 06.30 - freetz-trunk - Fritz!Load@USB
Abwesend
Scheinbar besteht doch ein größeres Interesse an einem funktionierenden internem Updater. Anscheinend synchronisieren nicht so viele Leute einfach ihr lokales Repository mit der Fritzbox. Ich habe deshalb auf die Schnelle die Funktionialität des Diffupdates wiederhergestellt. Es benötigt derzeit einen svn-Clienten, da ich gerade keine Lust hatte die Änderungen der einzelnen Revisionen manuell zusammenzufassen. Ohne Zusammenfassung gäbe es bei größeren Versionssprüngen zu viele unnötige mehrfache Downloads.
Ihr müsst die Datei FritzLoad/bin/update.sh durch diese http://sourceforge.net/p/avmload/code/H … format=raw ersetzen.
Das vollständige Update habe ich nicht gefixt. Das würde mit einem rekursiven wget (nur aktuelle Revision), svn export oder einer unzip binary funktionieren.
Der Beitrag wurde geändert von roadman17 (am 16. Jun. 2013 um 08:56 Uhr)
Abwesend
Vielleicht noch interessant:
Wo muss das svn-binary liegen?
Die Binaries können ansonsten ja auch einfach generell in Fritz!Load aufgenommen werden (bin/7270 bzw. bin/7390 Ordner), dann ist kein händisches rumkopieren mehr nötig.
Bei mir (7270 mit ext2 HDD) läuft das checkout recht performant, update sowieso.
Abwesend
Du hast schon richtig erkannt, dass das svn-Binary in den Ordner bin/7270 bzw. bin/7390 gehört. Falls es nicht gefunden wird, wird auch darauf hingewiesen. Ich habe es nur nicht eingecheckt, weil ich noch nicht weiß, ob das svn-Binary zu einer Dauerlösung werden soll.
Abwesend
Ich denke, dass die svn Lösung eine sehr gute ist.
Deshalb war ich so frei und habe die Binaries eingecheckt. :-)
Bei mir kommt seit der Umstellung seitens sf jetzt immer eine Passwortabfrage über svn.
Das war vorher nicht so.
Ich verwende den command-line client und habe testweise auch
store-passwords = yes
gesetzt. Leider ohne Erfolg.
Hat sich das sonst noch bei jemandem geändert?
Hab den entscheidenden Hinweis gefunden:
It depends on the protocol you're using. If you're using svn+ssh, the svn client can't save your password because it never touches it - the ssh client prompts you for it directly. In this case, you can use an ssh key and ssh-agent to avoid the constant prompts. If you're using the svnserve protocol or HTTP(S), then the svn client is handling your password and can save it.
Der Beitrag wurde geändert von rolex0815 (am 16. Jun. 2013 um 14:43 Uhr)
Abwesend
Hi,
ich habe eben die update.sh ausgetauscht und die svn-binaries rauf kopiert. Beim Onlineupdate wird die HEAD-Revision noch nicht erkannt. Wenn man r2445 einträgt, läuft das differentielle Update aber los. Der Button Versionprüfung findet die aktuelle HEAD nicht.
Abwesend
Guter Hinweis. Das Webinterface erkennt die aktuelle Version erst ab Revision 2432 richtig.
Abwesend