Bei mir über verschiedene Internetzugänge auch. Seit vielen Tagen. Scheint also ein Problem dort zu sein. Gibt es da inzwischen mehr Infos? Ist schon bedenklich lange wie ich finde.
Freetz Homepage "502 Bad Gateway"
- Ersteller smodo1977
- Erstellt am
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Sonntag ging's mal wieder ... nicht nervös werden und wer wirklich nur den Trunk braucht, kann problemlos die GitHub-Kopie nehmen. Der SVN-Stand wird bei jedem Commit dorthin repliziert und wenn auch SVN nicht funktioniert (die "Webansicht" darauf ist ja nur ein möglicher Blickwinkel), kann auch niemand über SVN Änderungen einchecken. Funktioniert SVN noch (z.B. über SSH), klappt auch die Replikation ... so sieht man es jedenfalls, wenn man SVN und GitHub (regelmäßig) im Auge hat.
Für das Wiki (zur eigenen Kontrolle, wenn ich wieder mal behaupten will, man würde das problemlos bei einer Suche finden) habe ich bei mir einfach mal eine Kopie mit "wget" und Mirroring erzeugt - mit passend konfigurierten lokalen HTTP-Server (z.B. dem der BusyBox, wobei den Seiten beim Mirroring leider erst mal die Erweiterung fehlt, weil Trac das ja alles aus der Datenbank generiert), kann man das dann auch lokal betrachten.
Auf den Rest kann ich persönlich verzichten - und ein "kompletter" Trac-Mirror braucht auch einiges an Platz, weil da natürlich auch Links zu Patches und verschiedenen Darstellungsformen derselben enthalten sind, die viel Redundanz hervorrufen (auch weil teilweise identische Seiten über mehrere "Pfade" erreichbar sind und das kriegt das "wget" natürlich dann nicht mit) oder viel Arbeit beim "Ausschließen" von Dubletten.
Für das Wiki (zur eigenen Kontrolle, wenn ich wieder mal behaupten will, man würde das problemlos bei einer Suche finden) habe ich bei mir einfach mal eine Kopie mit "wget" und Mirroring erzeugt - mit passend konfigurierten lokalen HTTP-Server (z.B. dem der BusyBox, wobei den Seiten beim Mirroring leider erst mal die Erweiterung fehlt, weil Trac das ja alles aus der Datenbank generiert), kann man das dann auch lokal betrachten.
Auf den Rest kann ich persönlich verzichten - und ein "kompletter" Trac-Mirror braucht auch einiges an Platz, weil da natürlich auch Links zu Patches und verschiedenen Darstellungsformen derselben enthalten sind, die viel Redundanz hervorrufen (auch weil teilweise identische Seiten über mehrere "Pfade" erreichbar sind und das kriegt das "wget" natürlich dann nicht mit) oder viel Arbeit beim "Ausschließen" von Dubletten.
@PeterPawn Danke für Deine Antwort. Mir ist es auch nicht aufgefallen als ich mir ein neues Image gemacht habe und mir den Trunk per SVN geholt habe. Wollte halt neulich was nachschauen und bin nach der Google-Suche auf ner 502er Meldung statt auf der gefundenen Unterseite von freetz.org gehängt. Gut, egal, war nicht superwichtig, aber ein paar Tage später wieder und und dann nochmal. Daher mein Post hier. Man wird halt nervös. Ich persönlich sorge mich da eher, dass das Projekt nicht mehr existiert, dabei ist, einzuschlafen oder sonstwas. Ist ja nicht "normal", dass der Webauftritt über Tage oder gar Wochen komplett weg ist, nicht jeder wird so hosten, was? ;-)
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Da bin ich mir gar nicht immer so sicher ... ich habe gerade die Links für die 6490-OSS-Pakete der 06.87 erhalten und die liegen (den Links nach zu urteilen) wohl auch eher auf irgendeinem Rechner eines AVM-Mitarbeiters als auf einem (ordentlich (ab)gesicherten) Download-Server.
Das mit der Freetz-Trac-Site (bzw. dem nginx auf dem virt. Server insgesamt, wenn ich das richtig einschätze) zieht sich jetzt > 1 Jahr - immer wieder mal gespickt mit längeren Ausfälllen. Ich will lieber nicht wissen, wieviele (einsatzbereite) Sicherungen der Datenbank dahinter (ich bilde mir ein, irgendwo mal eine PostgresSQL-Fehlermeldung gelesen zu haben, muß aber nicht stimmen) tatsächlich existieren, falls das Teil mal komplett "abraucht".
Und dann heißt's am Ende (um den Tenor der verlinkten Seite aufzugreifen): Hätte uns doch bloß jemand davor gewarnt.
Das mit der Freetz-Trac-Site (bzw. dem nginx auf dem virt. Server insgesamt, wenn ich das richtig einschätze) zieht sich jetzt > 1 Jahr - immer wieder mal gespickt mit längeren Ausfälllen. Ich will lieber nicht wissen, wieviele (einsatzbereite) Sicherungen der Datenbank dahinter (ich bilde mir ein, irgendwo mal eine PostgresSQL-Fehlermeldung gelesen zu haben, muß aber nicht stimmen) tatsächlich existieren, falls das Teil mal komplett "abraucht".
Und dann heißt's am Ende (um den Tenor der verlinkten Seite aufzugreifen): Hätte uns doch bloß jemand davor gewarnt.
Ja, schon manchmal komisch wie das so läuft mit Hosting, und anderen Dingen. ;-) Das mit den Images von AVM ist mir auch schon aufgefallen, dass es hier teilweise schon "komische" Links gibt. Spannend...
Die Freetz-Trac-Seite... Wird dort Hostinginfrastruktur oder Hostinghilfe benötigt? Trac ist nun ja soweit ich das bisher erlebt habe keine Rocket Science. Denke es gibt viele, die Freetz nutzen und denen das Projekt wichtig ist, dass sie sich da kostenfrei für so etwas einbringen könnten. Inklusive mir. Inklusive Sicherung. ;-)
Die Freetz-Trac-Seite... Wird dort Hostinginfrastruktur oder Hostinghilfe benötigt? Trac ist nun ja soweit ich das bisher erlebt habe keine Rocket Science. Denke es gibt viele, die Freetz nutzen und denen das Projekt wichtig ist, dass sie sich da kostenfrei für so etwas einbringen könnten. Inklusive mir. Inklusive Sicherung. ;-)
gismotro
Mitglied
- Mitglied seit
- 5 Sep 2007
- Beiträge
- 525
- Punkte für Reaktionen
- 128
- Punkte
- 43
Hier findet man ggf. Seiten als Backup wenn man nur mal was nachlesen möchte :
Startseite
packages
howtos
FAQ
Ich hab das auch mal als Hinweiß zu den Newbie HowTos eingearbeitet.
https://www.ip-phone-forum.de/threads/freetz-für-newbies-was-man-wissen-muß-oder-wissen-sollte-über-freetz.205448/#post-1671188
Startseite
packages
howtos
FAQ
Ich hab das auch mal als Hinweiß zu den Newbie HowTos eingearbeitet.
https://www.ip-phone-forum.de/threads/freetz-für-newbies-was-man-wissen-muß-oder-wissen-sollte-über-freetz.205448/#post-1671188
WileC
Mitglied
- Mitglied seit
- 28 Nov 2007
- Beiträge
- 395
- Punkte für Reaktionen
- 13
- Punkte
- 18
Hallo,
nachdem das mit dem "502 Bad Gateway" ein Dauerproblem zu werden scheint, würde ich mich auch gerne am Freetz-Projekt beteiligen und einen Webspace mit Umzug der freetz.org und ein oder mehreren mysql DBs zur Verfügung stellen. Es wären auch Server in Deutschland.
Falls Interesse besteht...
MfG
Tobias
nachdem das mit dem "502 Bad Gateway" ein Dauerproblem zu werden scheint, würde ich mich auch gerne am Freetz-Projekt beteiligen und einen Webspace mit Umzug der freetz.org und ein oder mehreren mysql DBs zur Verfügung stellen. Es wären auch Server in Deutschland.
Falls Interesse besteht...
MfG
Tobias
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Das Problem ist wohl, daß die Trac-Installation in schöner Regelmäßigkeit die Ressourcen des Hosts "auffrißt" und keiner wirklich Zeit und/oder Lust und/oder Zugriffsmöglichkeiten hat, um dem Problem mal auf den Grund zu gehen. Daher wird (soweit mir das bekannt ist) immer nur der Server neu gestartet (inzwischen läuft das wohl als einziges Projekt noch auf einem älteren "dedicated server" bei Strato, weil der bisherige "Spender" der Hosting-Kapazitäten alles andere schon umgezogen und auf Container umgestellt hat) und das war's dann auch schon.
Warum nimmst Du nicht einfach das "offizielle" Freetz-Repository bei GitHub?
Auch für "Issues" kann man das ja benutzen ... irgendwann muß/soll der Umzug wohl ohnehin erfolgen - unklar sind halt die "Zuständigkeiten" und auch das Vorgehen, wenn es um Inkompatibilitäten zwischen GitHub und Trac/SVN geht (Wiki, Tickets).
Ich will Deinen Enthusiasmus keinesfalls bremsen ... aber eine 1:1-Übernahme der derzeitigen Installation mitsamt aller Probleme wirst Du auch nicht wollen. Wenn es wirklich nur am Server-Space mangeln würde, hätte sich sicherlich auch schon länger eine Lösung finden lassen bzw. es gab auch auf der (Freetz-Developer-)Mailing-List (auf der bin ich eigentlich auch nur "aus Versehen") schon entsprechende Angebote. Nur ist halt die Frage, ob ein "weiter so" tatsächlich der richtige Ansatz wäre ... und nichts hält bekanntermaßen so lange, wie das nächste Provisorium.
Warum nimmst Du nicht einfach das "offizielle" Freetz-Repository bei GitHub?
Auch für "Issues" kann man das ja benutzen ... irgendwann muß/soll der Umzug wohl ohnehin erfolgen - unklar sind halt die "Zuständigkeiten" und auch das Vorgehen, wenn es um Inkompatibilitäten zwischen GitHub und Trac/SVN geht (Wiki, Tickets).
Ich will Deinen Enthusiasmus keinesfalls bremsen ... aber eine 1:1-Übernahme der derzeitigen Installation mitsamt aller Probleme wirst Du auch nicht wollen. Wenn es wirklich nur am Server-Space mangeln würde, hätte sich sicherlich auch schon länger eine Lösung finden lassen bzw. es gab auch auf der (Freetz-Developer-)Mailing-List (auf der bin ich eigentlich auch nur "aus Versehen") schon entsprechende Angebote. Nur ist halt die Frage, ob ein "weiter so" tatsächlich der richtige Ansatz wäre ... und nichts hält bekanntermaßen so lange, wie das nächste Provisorium.
WileC
Mitglied
- Mitglied seit
- 28 Nov 2007
- Beiträge
- 395
- Punkte für Reaktionen
- 13
- Punkte
- 18
Okay, danke für die ausführliche Erklärung. Ich nutze halt schon sehr lange freetz und mangels Programierkenntnissen wollte ich eben so meinen Beitrag zum Projekt leisten.
Was anderes: warum lässt man den Server/nginx nicht via script jeden Tag neu starten?!
Was anderes: warum lässt man den Server/nginx nicht via script jeden Tag neu starten?!
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Was bringt das genau, wenn der Service nach 4 Stunden erneut aussteigt?
Die einzige wirkliche Alternative, die ich da sehen würde, ist der Neustart "on demand" ... sprich, wenn der Service ausgefallen ist, was man mit einer passenden Überwachung problemlos feststellen kann.
Das erfolgt auch bereits, nur die nachfolgende Aktion des Neustarts fehlt:
Die einzige wirkliche Alternative, die ich da sehen würde, ist der Neustart "on demand" ... sprich, wenn der Service ausgefallen ist, was man mit einer passenden Überwachung problemlos feststellen kann.
Das erfolgt auch bereits, nur die nachfolgende Aktion des Neustarts fehlt:
alis123
Neuer User
- Mitglied seit
- 13 Mrz 2016
- Beiträge
- 28
- Punkte für Reaktionen
- 8
- Punkte
- 3
Gibt es schon Infos wann die Seite wieder online geht oder kann ich bei GitHub auch die Änderungen verfolgen ?
Mir geht es um diese Übersicht : http://freetz.org/timeline
Mir geht es um diese Übersicht : http://freetz.org/timeline
gitHub ist hier: https://github.com/Freetz/freetz
Allerdings finde ich - trotz allen buh Rufen - svn übersichtlicher, angenehmer, besser, usw...
Ich vermisse das Ticketsystem und die Timeline ebenfalls schmerzlich!
Gruß
Allerdings finde ich - trotz allen buh Rufen - svn übersichtlicher, angenehmer, besser, usw...
Ich vermisse das Ticketsystem und die Timeline ebenfalls schmerzlich!
Gruß
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Also die "timeline" ist ja nun schnell gefunden:
https://github.com/Freetz/freetz/commits/master
und wenn man das Ticket-System immer weiter nur benutzt und sich niemand um den Umzug kümmert, obwohl die gewollte Abschaltung des Servers (oder zumindest ein Umzug der Inhalte in einer neuen VM mit aktueller Software (bzw. in einem Container) auf einen anderen Host) auch vom Betreiber mehr oder weniger deutlich angekündigt wurde, dann kommt halt irgendwann mal der Zeitpunkt, wo es nicht mehr geht.
Immerhin funktioniert offenbar wenigstens der SVN-Server (auf demselben Host, wenn er nicht durch einen Reverse-Proxy umgeleitet wird) weiterhin ... wenn der auch noch ausfällt/abgeschaltet wird, greift auch die automatische Synchronisation vom SVN zu GitHub (das ist im Moment ein regelmäßiger Batch - mit recht kurzen Intervallen - auf einen privaten PC) irgendwann ins Leere.
Ansonsten ist es vielleicht auch eine Frage des persönlichen Geschmacks ... aber die Nutzerzahlen bei den git-basierten Diensten (GitHub, GitLab, BitBucket) und den älteren Services (wie sourceforge.net u.a., bei SourceForge kann man zwischen git, mercurial und subversion wählen) sprechen eigentlich eher gegen einen eigenen SVN- und Trac-Server - mal ganz abgesehen von den besseren Möglichkeiten der verteilten Arbeit bei der Benutzung von "git" (es gab schließlich Gründe, warum CVS und SVN nicht mehr ausreichten für die Kernel-Programmierung und nachdem die Bitkeeper-Lizenz sich geändert hatte, irgendetwas Neues her mußte, was verteiltes Arbeiten besser unterstützt als die alten SCM) und der Tatsache, daß man mit einem einzigen Account bei GitHub auf viele Projekte zugreifen kann und nicht für jedes einen eigenen braucht (wie es beim Trac der Fall ist), ist eigentlich auch ganz angenehm.
https://github.com/Freetz/freetz/commits/master
und wenn man das Ticket-System immer weiter nur benutzt und sich niemand um den Umzug kümmert, obwohl die gewollte Abschaltung des Servers (oder zumindest ein Umzug der Inhalte in einer neuen VM mit aktueller Software (bzw. in einem Container) auf einen anderen Host) auch vom Betreiber mehr oder weniger deutlich angekündigt wurde, dann kommt halt irgendwann mal der Zeitpunkt, wo es nicht mehr geht.
Immerhin funktioniert offenbar wenigstens der SVN-Server (auf demselben Host, wenn er nicht durch einen Reverse-Proxy umgeleitet wird) weiterhin ... wenn der auch noch ausfällt/abgeschaltet wird, greift auch die automatische Synchronisation vom SVN zu GitHub (das ist im Moment ein regelmäßiger Batch - mit recht kurzen Intervallen - auf einen privaten PC) irgendwann ins Leere.
Ansonsten ist es vielleicht auch eine Frage des persönlichen Geschmacks ... aber die Nutzerzahlen bei den git-basierten Diensten (GitHub, GitLab, BitBucket) und den älteren Services (wie sourceforge.net u.a., bei SourceForge kann man zwischen git, mercurial und subversion wählen) sprechen eigentlich eher gegen einen eigenen SVN- und Trac-Server - mal ganz abgesehen von den besseren Möglichkeiten der verteilten Arbeit bei der Benutzung von "git" (es gab schließlich Gründe, warum CVS und SVN nicht mehr ausreichten für die Kernel-Programmierung und nachdem die Bitkeeper-Lizenz sich geändert hatte, irgendetwas Neues her mußte, was verteiltes Arbeiten besser unterstützt als die alten SCM) und der Tatsache, daß man mit einem einzigen Account bei GitHub auf viele Projekte zugreifen kann und nicht für jedes einen eigenen braucht (wie es beim Trac der Fall ist), ist eigentlich auch ganz angenehm.
Mit den Ausführungen über GIT hast du sicherlich Recht, PeterPawn.
Was mich persönlich am Meisten an GIT stört, ist halt die nicht gerade hilfreiche Revision Nummerierung.
Wenn bei SVN 14985 steht, weiß jeder sofort und ohne nachzusehen, dass 14984 älter und 14986 neuer ist.
Das ist halt bei GIT - für meinen unmaßgeblichen Geschmack - nicht der Fall, oder gibt es einen einfachen
Weg, ohne jedes mal im GIT nach zu schauen, wie die Reihenfolge bzw. das Alter eines Checkouts ist?
Liegen - als Beispiel - diese Nummern nun direkt neben einander 98ea9c2, a742ae6, 6887d00 und d627c15,
oder sind da mehrere Monate dazwischen? Natürlich kann ich mir das auch raus suchen, aber das ist deutlich
mehr Aufwand, als einfach nur die Nummern mit einander zu vergleichen...
Grüße
Was mich persönlich am Meisten an GIT stört, ist halt die nicht gerade hilfreiche Revision Nummerierung.
Wenn bei SVN 14985 steht, weiß jeder sofort und ohne nachzusehen, dass 14984 älter und 14986 neuer ist.
Das ist halt bei GIT - für meinen unmaßgeblichen Geschmack - nicht der Fall, oder gibt es einen einfachen
Weg, ohne jedes mal im GIT nach zu schauen, wie die Reihenfolge bzw. das Alter eines Checkouts ist?
Liegen - als Beispiel - diese Nummern nun direkt neben einander 98ea9c2, a742ae6, 6887d00 und d627c15,
oder sind da mehrere Monate dazwischen? Natürlich kann ich mir das auch raus suchen, aber das ist deutlich
mehr Aufwand, als einfach nur die Nummern mit einander zu vergleichen...
Grüße
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Warum muß man das wissen, wenn man einfach immer mit der aktuellen Version arbeitet? Ein "pull" dauert nicht lange und auch bei einer Differenz von Eins oder Zwei zwischen zwei Changesets im SVN muß man sich ja entweder dafür entscheiden, die "unbesehen" zu aktualisieren oder sich den Inhalt genauer anzusehen.
Oder aktualisierst Du Deine ausgecheckten Dateien erst dann, wenn eine "Mindestdifferenz" zwischen den CS-Nummern besteht?
Wenn man schon Paradigmen wie "Continuous Delivery" oder "Continuous Integration" verwenden (also fertige (abgeschlossene) Einheiten umgehend zur Verfügung stellen) will, macht das ja nur dann Sinn, wenn die eingecheckten Änderungen auch in jedem Falle ankommen beim "Anwender". Das setzt natürlich voraus, daß man jederzeit einen funktionierenden Stand in dem Zweig hat, der für die Öffentlichkeit gedacht ist ... und sogar das macht "git" wieder extrem gut, weil man sich seine Branches in einem lokalen Repository erst mal so weit zusammenbasteln (und testen) kann, daß sie auch funktionieren, bevor man sie "an die Öffentlichkeit" gibt.
Bei mir sehen die Repos für ein Projekt z.B. so aus:
Vom "upstream" kommen die SVN-Änderungen, das "origin"-Repo ist ein Fork von "Freetz/freetz" (auf einem lokalen Server hier, das kann ggf. sogar eine FRITZ!Box sein, wenn man das "git"-Paket aus Freetz installiert) und "github" ist mein Freetz-Fork eben dort bei GitHub, in dem das am Ende alles wieder landen soll.
Wenn ich jetzt etwas ändern will, dann mache ich in "origin" einen Branch auf, fasse da alle (thematisch zu diesem Branch gehörenden) Änderungen zusammen, kann auf der Basis dieses Branches auch lokale Checkouts auf anderen PCs machen, die Änderungen so testen und optimieren und wenn sie fertig sind, werden sie auf das "github"-Repo übertragen.
Zwar hält man das nicht immer durch (manchmal macht man auch einen schnellen "push" nach "github", weil man zu faul zum eigenen Test ist), aber vom Prinzip her funktioniert die verteilte Entwicklung und die Arbeit an einem gemeinsamen Projekt so (wobei dann Freetz ein schlechtes Beispiel war) und damit muß der "Anwender" in meinen Augen gar nicht wissen, wieviele Commits genau nun zwischen seinem letzten Stand und dem aktuellen liegen ... es sei denn, er ist selbst Entwickler und will das alles ganz genau wissen - dann muß er aber ohnehin durch die (zeitlich sortierte) Liste aller Änderungen und es ist wieder egal, wie diese nun "nummeriert" sind.
Der große Vorteil, die Commits mit ihrem Hash-Wert zu verwalten, ist es nun mal, daß damit auch mittendrin welche herausfallen oder hinzukommen können (man kann also Patches (Commits) auch in einer anderen Reihenfolge anwenden - "reorder on rebase"), was bei sequentieller Nummerierung entweder die Reihenfolge auch ändert oder Löcher läßt oder "Unternummern" erfordert, wenn weitere (zwischen zwei älteren) hinzukommen sollen.
Oder aktualisierst Du Deine ausgecheckten Dateien erst dann, wenn eine "Mindestdifferenz" zwischen den CS-Nummern besteht?
Wenn man schon Paradigmen wie "Continuous Delivery" oder "Continuous Integration" verwenden (also fertige (abgeschlossene) Einheiten umgehend zur Verfügung stellen) will, macht das ja nur dann Sinn, wenn die eingecheckten Änderungen auch in jedem Falle ankommen beim "Anwender". Das setzt natürlich voraus, daß man jederzeit einen funktionierenden Stand in dem Zweig hat, der für die Öffentlichkeit gedacht ist ... und sogar das macht "git" wieder extrem gut, weil man sich seine Branches in einem lokalen Repository erst mal so weit zusammenbasteln (und testen) kann, daß sie auch funktionieren, bevor man sie "an die Öffentlichkeit" gibt.
Bei mir sehen die Repos für ein Projekt z.B. so aus:
Code:
vidar:/home/GitHub/freetz $ git remote -v
github [email protected]:PeterPawn/freetz.git (fetch)
github [email protected]:PeterPawn/freetz.git (push)
origin git@git:/srv/git/freetz.git (fetch)
origin git@git:/srv/git/freetz.git (push)
upstream https://github.com/Freetz/freetz.git (fetch)
upstream https://github.com/Freetz/freetz.git (push)
vidar:/home/GitHub/freetz $Wenn ich jetzt etwas ändern will, dann mache ich in "origin" einen Branch auf, fasse da alle (thematisch zu diesem Branch gehörenden) Änderungen zusammen, kann auf der Basis dieses Branches auch lokale Checkouts auf anderen PCs machen, die Änderungen so testen und optimieren und wenn sie fertig sind, werden sie auf das "github"-Repo übertragen.
Zwar hält man das nicht immer durch (manchmal macht man auch einen schnellen "push" nach "github", weil man zu faul zum eigenen Test ist), aber vom Prinzip her funktioniert die verteilte Entwicklung und die Arbeit an einem gemeinsamen Projekt so (wobei dann Freetz ein schlechtes Beispiel war) und damit muß der "Anwender" in meinen Augen gar nicht wissen, wieviele Commits genau nun zwischen seinem letzten Stand und dem aktuellen liegen ... es sei denn, er ist selbst Entwickler und will das alles ganz genau wissen - dann muß er aber ohnehin durch die (zeitlich sortierte) Liste aller Änderungen und es ist wieder egal, wie diese nun "nummeriert" sind.
Der große Vorteil, die Commits mit ihrem Hash-Wert zu verwalten, ist es nun mal, daß damit auch mittendrin welche herausfallen oder hinzukommen können (man kann also Patches (Commits) auch in einer anderen Reihenfolge anwenden - "reorder on rebase"), was bei sequentieller Nummerierung entweder die Reihenfolge auch ändert oder Löcher läßt oder "Unternummern" erfordert, wenn weitere (zwischen zwei älteren) hinzukommen sollen.
Hallo, ich habe eine Fritzbox 7490, und wollte jetzt mit Freetz einsteigen.
Ich habe mir freetz-linux 1.4.1 runtergeladen, in VMWare Fusion (auf Mac) gestartet und username/passwort eingegeben.
Aber beim Aufruf eurer Newbie- Hilfeseiten, z.B.
http://freetz.org/wiki/help/howtos/common/newbie
oder
http://trac.freetz.org/wiki/help/howtos/common/newbie
kommt nach langer Zeit immer ein "502 Bad Gateway".
ich habe es schon mit verschiedenen Browsern, auf mehreren Rechnern und aus verschiedenen Netzen heraus versucht.
freetz.org wird bei mir zu server.falkenhain.info(81.169.232.98) aufgelöst...
Mach ich da irgendwas falsch?
Bitte gern ins passende Forum verschieben!
Danke für infos und Rückmeldungen...
// passend verschoben by stoney
Ich habe mir freetz-linux 1.4.1 runtergeladen, in VMWare Fusion (auf Mac) gestartet und username/passwort eingegeben.
Aber beim Aufruf eurer Newbie- Hilfeseiten, z.B.
http://freetz.org/wiki/help/howtos/common/newbie
oder
http://trac.freetz.org/wiki/help/howtos/common/newbie
kommt nach langer Zeit immer ein "502 Bad Gateway".
ich habe es schon mit verschiedenen Browsern, auf mehreren Rechnern und aus verschiedenen Netzen heraus versucht.
freetz.org wird bei mir zu server.falkenhain.info(81.169.232.98) aufgelöst...
Mach ich da irgendwas falsch?
Bitte gern ins passende Forum verschieben!
Danke für infos und Rückmeldungen...
// passend verschoben by stoney
Zuletzt bearbeitet von einem Moderator:
alis123
Neuer User
- Mitglied seit
- 13 Mrz 2016
- Beiträge
- 28
- Punkte für Reaktionen
- 8
- Punkte
- 3
Ich habe die Tage eine neue Linux Umgebung (VM) aufgesetzt um alles einmal auf den neusten Stand zu bringen.
Der Checkout hat auch nocht funktioniert, aber nach den Konfiguration, beim Erstellen des ersten Images hapert es:
mpfr-3.1.6.tar.xz kann weder von "freetz.3dfxatwork.de" noch von "freetz.magenbrot.net" bezogen werden, beidesmal 404 not Found - Download failed --> Error Code 8.
Hat das etwas damit zu tun dass die Seite wieder seit Tagen nicht erreichbar ist?
Der Checkout hat auch nocht funktioniert, aber nach den Konfiguration, beim Erstellen des ersten Images hapert es:
mpfr-3.1.6.tar.xz kann weder von "freetz.3dfxatwork.de" noch von "freetz.magenbrot.net" bezogen werden, beidesmal 404 not Found - Download failed --> Error Code 8.
Hat das etwas damit zu tun dass die Seite wieder seit Tagen nicht erreichbar ist?
alis123
Neuer User
- Mitglied seit
- 13 Mrz 2016
- Beiträge
- 28
- Punkte für Reaktionen
- 8
- Punkte
- 3
Neueste Beiträge
-
[Problem] Tonwahl beim T48S- Letzte: NDiIPP
-
[Frage] Dect-WS500S Verbindungen an Compact 4000
- Letzte: oezi
-
Analoges Wählgerät einer Alarmanlage an VoIP betreiben ...
- Letzte: provisorischerFtmmsch
