LaTeX Forum

Vielleicht hilft es auch, einfach einmal ein anderes Repository zu verwenden, zu dem es eine stabilere Verbindung gibt. Jedenfalls hat das laut Google bei anderen Leuten geholfen. Eventuell gibt es da aber auch tatsächlich ein Problem in MiKTeX, dass es nicht erkennt, wenn ein Paket nicht korrekt heruntergeladen werden kann. Eventuell sitzt das Problem aber auch schlicht vor dem Computer …

Jedenfalls meldet man denselben Bug nicht mehrfach in einem Bug-Tracker, sondern vermeidet genau das. Stattdessen versucht man, den Bug möglichst genau zu dokumentieren und ggf. eine vorhandene Beschreibung sachlich zu verbessern. Bei MiKTeX kann man AFAIK irgendwelche Debug-Optionen setzen, damit eine zusätzlich Log-Datei o. ä. erstellt wird. Wenn solche Möglichkeiten vorhanden sind, sollte man auch diese nutzen.

Wenn ein Entwickler ein Problem nicht nachvollziehen kann, ist es logischerweise sehr schwierig, dieses zu beseitigen. Wenn dann außerdem die Informationen nur sehr wischi-waschi sind und auch auf Aufforderung (viele Bug-Tracker machen das automatisch) weiter nichts kommt, dann verliert der Entwickler auch die Lust an dem Problem und es kann sogar passieren, dass es geschlossen wird. Dann muss man es ggf. wieder öffnen und schauen, was man sinnvolles beitragen kann.

Wenn so etwas desöfteren vor kommt und solche Meldungen dann auch noch eher aus Anschuldigungen oder Gejammer bestehen, dann verliert der Entwickler insgesamt die Lust, immer wieder dieselben Hinweise zu geben. Das ist übrigens hier im Forum ganz ähnlich, wenn die Helfer immer wieder auf dieselben Grundlagen schon zum Stellen von Fragen hinweisen müssen.

Vorteilhaft bei einem Bug-Report ist auch, wenn der Melder signalisiert, dass er bereit ist, an der Beseitigung mit zu helfen und nicht nach zwei Tagen die Geduld verliert. Ich habe vor einiger Zeit einen Bug im Linux-ACPI-System gemeldet. Es hat über ein halbes Jahr gedauert und mich mehrere Wochen intensiver Arbeit gekostet, um immer wieder teilweise die gleichen Daten zu liefern, Dinge auszuprobieren, Kernel zu compilieren und zu installieren, Dokus zu Dingen zu wälzen, mit denen ich mich vorher nie beschäftigt hatte. Das begann bereits vor dem Bug-Report, indem ich mich u. a. aus anderen Bug-Report informiert hatte, welche Daten üblicherweise benötigt werden, und wie man die beschaffen kann. Am Ende wurde mein Einsatz damit belohnt, dass das Problem soweit beseitigt wurde, dass mein altes Notebook wieder bootet. Dass ich das zwischenzeitlich ersetzt hatte, spielte für mich keine Rolle. Schließlich bin ich nicht der einzige mit diesem Modell. Inzwischen verwende ich das Gerät sogar teilweise wieder u. a. zum Surfen (z. B. jetzt).

Ich schreibe das, um zu verdeutlichen, dass ein Bug-Report auch eine gewisse Verantwortung mit sich bringt, und man häufig selbst dafür verantwortlich ist, wie er behandelt wird und ob er zu einem nützlichen Ergebnis führt.

Achja: Man darf nicht erwarten, dass ein Bug-Report zu Begeisterung beim Entwickler führt. Die natürliche Reaktion ist: »Oh Mist, schon wieder!«. Niemand macht gerne Fehler. Man sollte das nicht dadurch verstärken, dass man die eigene Frustration auch noch an den Entwickler weiter gibt. Gut ist, wenn die natürliche Reaktion des Entwicklers am Ende »Prima, wieder ein Problem gelöst!« sein wird und nicht »Hoffentlich schreibt der nie wieder einen Bug-Report!« Das im Auge zu behalten, kann nicht schaden.

Eventuell sitzt das Problem aber auch schlicht vor dem Computer …

das wäre ja gut, dann würde so ein Problem ja sogar von mir leicher zu lösen sein.

Vielleicht hilft es auch, einfach einmal ein anderes Repository zu verwenden, zu dem es eine stabilere Verbindung gibt

alles schon probiert. Das Problem ist nur, das eine Installation auf einem 64 Bit Win 7 perfekt bei mir funktioniert, eine Installation auf einem 32 Bit System aber nicht klappt.

Jedenfalls meldet man denselben Bug nicht mehrfach in einem Bug-Tracker,

neeee, so hatte ich da auch nicht gemeint. Tschuldigung. Mann/Frau kann sich doch aber an einen Report dranhängen. Wenn mehrere Leuts versuchen ein Problem zu lösen, findet man eventuell doch noch eine Lösung.

Man sollte das nicht dadurch verstärken, dass man die eigene Frustration auch noch an den Entwickler weiter gib

wenn man denn mal mitknobeln könnte, warum etwas nicht so funktioniert wie es sein sollte. Ich sitze jetz selber schon fast zwei Wochen an der Sache und versuche MiKTeX auch auf meinen 32 Bit Systemen ans Laufen zu bekommen. Was meinst Du wohl wie gefrustet ich bin. Das ist kein tolles Gefühl, wenn ich manchmal denke: "Mann was bist Du blöd. Andere bekommen das doch auch hin."

Wenn ich Meldungen der Art "message: Permission denied: C:\Users\Thor\AppData\Local\Temp\mik82\xymtex.tpm" bekommen würde, würde ich als erstes versuchen, den Inhalt des angegebenen Temp-Verzeichnisses komplett zu löschen, in diesem Falle also alles, was in C:\Users\Thor\AppData\Local\Temp an alten Leichen drin ist. Anschließend würde ich sicherheitshalber einen Dateisystemcheck über C: laufen lassen. Danach Windows neu booten (hat schon zu Windows 3.0-Zeiten manchmal geholfen, und hilft bei mir unter Vista immer noch manchmal ), und es nochmal probieren.

Wenn das dann immer noch nicht funktioniert, würde ich TeXlive statt MikTeX installieren.

würde ich als erstes versuchen, den Inhalt des angegebenen Temp-Verzeichnisses komplett zu löschen

das ist doch auch so ein Witz. Das Verzeichniss und/oder die Datei gibt es ja gar nicht. Ist auch jedes Mal ein anderer Name.

Wenn das dann immer noch nicht funktioniert, würde ich TeXlive statt MikTeX installieren.

auch auf die Gefahr hin, jetzt für einen wirklichen Dummkopf gehalten zu werden, das klappt ja auch nicht Auf einem 64 Bit System kein Problem. TeXLive lässt sich da wunderbar einrichten. Auf einem 32 Bit System - ich habe zwei davon - geht das bei mir so. Es fängt die Installation an zu laufen. Nach 5, 10, oder auch schon mal 50 Files steigt das Programm aus und es erscheint nur der nette Fehler: "Perl.exe funktioniert nicht mehr." Das war es dann

Obwohl es nicht genz exakt die Fragestellung trifft möchte ich Ihnen meine Erfahrungen mit der Installation von Miktex berichten.
Mit den Querelen aus dem Internet konnte ich nichts rechtes anfangen.
Allerdings habe ich Miktex 28 auf Win XP Prof. installiert.
1. Mit der Win Installationsdisk habe ich mein Windows repariert. Dabei wurde auch SP3 nicht mitinstalliert.
2. Sämtliche Sicherheitssoftware, Virenscanner, Registryprüfer habe ich deinstalliert.
3. Die Installation von Miktex Basic verlief ohne Fehler.
4. Winedt 5.5 hat die Installation erkannt. Das System funktionierte sowohl für DVI und PDF Files.
5. Nach Reinstallation aller Sicherheitssoftware und von SP 3 funktioniert Miktex immer noch.
Happy!!!!
Für Win 7 tappe ich noch sehr im Dustern, eine Erleuchtung ist z.Zt. nicht in Sicht.
Vielleicht hat der Beitrag einigen geholfen.

Es grüßt Jochen Rein alias chacmool
[/b]