Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Linux RPM/DEB-Pakete
#51
Entweder ist der Schlüssel falsch kodiert oder der Schlüssel wird nicht gefunden.

Hast Du die sim-germany.repo bei Dir gespeichert? Darin ist auch der Link der Suse mitteilt wo der öffentliche Schlüssel zu finden ist.

(03-09-2017, Sunday-19:16:46 )Wurzelgnom schrieb: ....
/etc/yum.repos.d/sim-germany.repo
sim-germany.repo
....
Zitieren
#52
Ich habe das Thema nur mal schnell überflogen.
Opensuse bietet bereits Simutrans im game repo an, aktuell 120.2.2
Eine RPM für viele Distris zu erstellen ist häufig problematisch, da unterschiedliche distris häufig unterschiedliche Konventionen z.B. für die Verzeichnisse haben.
Für opensuse sollte ihr einfach einen Blick in das games repo werfen: http://download.opensuse.org/repositories/games/
Und die Konventionen über nehmen, so lange die nicht zu Problemen mit anderen RPM distris führen.

Ein solches repo befürworte ich stark, besonders wenn neben der sdl Version noch eine headless Version, also ohne UI, makeobj und die aktuellen Versionen von den am häufigsten genutzten paks über das Repo installierbar sind.

Es sollte auch versucht werden zu möglichst vielen disttis kompatibel zu sein, aber das wird wegen vieler Unterschiede im Detail nicht einfach, wie ihr bereits festgestellt habt.

P.s. ich nutze aktuell opensuse leap 42.2 und windoof, mein simu Server nutzt leap 42.2 und simutrans ohne UI.

Ich habe das Thema nur mal schnell überflogen.
Opensuse bietet bereits Simutrans im game repo an, aktuell 120.2.2
Eine RPM für viele Distris zu erstellen ist häufig problematisch, da unterschiedliche distris häufig unterschiedliche Konventionen z.B. für die Verzeichnisse haben.
Für opensuse sollte ihr einfach einen Blick in das games repo werfen: http://download.opensuse.org/repositories/games/
Und die Konventionen über nehmen, so lange die nicht zu Problemen mit anderen RPM distris führen.

Ein solches repo befürworte ich stark, besonders wenn neben der sdl Version noch eine headless Version, also ohne UI, makeobj und die aktuellen Versionen von den am häufigsten genutzten paks über das Repo installierbar sind.

Es sollte auch versucht werden zu möglichst vielen disttis kompatibel zu sein, aber das wird wegen vieler Unterschiede im Detail nicht einfach, wie ihr bereits festgestellt habt.

P.s. ich nutze aktuell opensuse leap 42.2 und windoof, mein simu Server nutzt leap 42.2 und simutrans ohne UI.
Zitieren
#53
(11-09-2017, Monday-12:03:37 )Freahk schrieb: Ich habe das Thema nur mal schnell überflogen.
Opensuse bietet bereits Simutrans im game repo an, aktuell 120.2.2
Eine RPM für viele Distris zu erstellen ist häufig problematisch, da unterschiedliche distris häufig unterschiedliche Konventionen z.B. für die Verzeichnisse haben.
Für opensuse sollte ihr einfach einen Blick in das games repo werfen: http://download.opensuse.org/repositories/games/
Und die Konventionen über nehmen, so lange die nicht zu Problemen mit anderen RPM distris führen.
....

Das Problem bei den Distries ist schlicht, das gerade mal 3 Grafiksets ( die 3 mit Artistik-Lizenz pak64/pak128/pak128.britain ) enthalten sind, wenn überhaupt.

Der nächste Punkt ist, das ältere Versionen häufig keine Updates bekommen von Drittprogrammen. Also nur die Distrie selber und wichtige Komponenten/Programme werden weiter gepflegt.

Was die Mentalität der Verzeichnisse angeht, die ist mir prinzipiell unwichtig, da ich ja keine Aufnahme in die jeweiligen Distrie-Repos anstrebe. Deshalb auch der eher unorthodoxe Pfad /usr/local/bin/simutrans. Würde man nämlich Simutrans selber kompilieren würde es wohl genau da landen. Ich nehme dem User nur das kompilieren ab.

Ich gehe davon aus, das die Pakete selber schon funktionieren. Nur die Distries unterschiedliche Metadaten im Repo erwarten. Und das es durchaus nötig werden kann angepasste Repos zu erstellen sieht man bei CentOS. Dort werden aktuell keine Menüeinträge erstellt. Muss aber auch dazu sagen das ich nur mit xfce getestet hab. Dort hab ich auch die SDL-Packete dazu gepackt um das einbinden zusätzlicher Repos zu vermeiden für den User.

Auffällig ist, das sämtliche Doku relativ alt ist ( 2013 und früher ). Bei den Metadaten für Mageia zBsp. bin ich auf ner französischen Seite fündig geworden. Nach rund einer Woche rum suchen.

Aktuell brauche ich halt Tester und Feedback.
Zitieren
#54
Tests und feedback meinerseits müssen sich gedulden bis ich aus dem Urlaub zurück bin.
Mit unterschiedlichen Pfaden meinte ich den kompletten Pfad der Abhängigkeiten.
Die libs sind in den distris teilweise unterschiedlich benannt.
Zitieren
#55
(11-09-2017, Monday-13:10:03 )Freahk schrieb: Tests und feedback meinerseits müssen sich gedulden bis ich aus dem Urlaub zurück bin.
Mit unterschiedlichen Pfaden meinte ich den kompletten Pfad der Abhängigkeiten.
Die libs sind in den distris teilweise unterschiedlich benannt.

Die Libs selber sind kein Problem, da es dafür Einträge ( Aliase ) gibt bei rpm. Entsprechend werden dann Symlinks angelegt die dann auf den jeweiligen installierten Libnamen weiterleiten.

Das war halt bei Mageia das Problem mit der libbz2. Weshalb die jetzt statisch drin ist und damit vom System unabhängig.

Bei deb sieht es wieder anders aus, weil da muss man den Paketnamen angeben. Und der kann unterschiedlich sein bei den verschiedenen Distries.
Zitieren
#56
Es hat ja schon mal funktioniert. Erst seit die Pakete Signiert sind hängt er beim Schlüssel prüfen. Nicht beim den RPM sondern im bereits beim Repo Verzeichnis laden.
Ich bin dran, vielleicht find ich den Fehler. Ich werde mal das SuSE eigene mit deinem vergleichen.

Die Idee ist ja auch nicht das unter openSUSE zum fliegen zu bringen. Sondern wenn es hier funktioniert dann sollten die gröbsten Fehler raus sein und es auch in anderen RPM, zypper oder Yast2 Distributionen funktionieren
Zitieren
#57
Hab die falsche Datei als repomd.xml.key gespeichert.

Sollte jetzt gehen.

Hab das Script nicht geändert gehabt nachdem es ging.
Zitieren
#58
aha jetzt läuft es so wie es soll

openSUSE tumbleweed
Zitieren
#59
Ist allerdings seltsam, das Yast sich aufhängt nur weil die repomd.xml.key nicht der öffentliche Schlüssel ist.
Zitieren
#60
Scheinbar hat die https-Umstellung dafür gesorgt, das der gpg-Schlüssel der Repos nicht mehr gefunden wird.

Jedenfalls scheinen alle Paketverwaltungen die Signatur nicht mehr prüfen zu können.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste