Hello, Guest the thread was called1.9k times and contains 56 replays

last post from Zirias/Excess at the

V1541Commander -- Tool für 1541 disk images (D64)

  • Ich muss mir Dein Buildsystem nur noch einmal anschauen (es sei Du kannst gleich adHoc die Antwort geben), damit der Anteil "update-mime-database" nicht ausgeführt wird vom "strip" target.

    Kann ich, update-mime-database wird NUR ausgeführt, wenn es kein PORTABLE build ist UND DESTDIR nicht gesetzt ist. DESTDIR sollte man beim Paketieren ja eigentlich immer setzen :)


    edit: "strip" führt das sowieso nie aus, das tun nur die "install" targets -- aber wie gesagt nicht, wenn man mit DESTDIR installiert.

  • Ich muss mir Dein Buildsystem nur noch einmal anschauen (es sei Du kannst gleich adHoc die Antwort geben), damit der Anteil "update-mime-database" nicht ausgeführt wird vom "strip" target.

    Kann ich, update-mime-database wird NUR ausgeführt, wenn es kein PORTABLE build ist UND DESTDIR nicht gesetzt ist. DESTDIR sollte man beim Paketieren ja eigentlich immer setzen :)


    edit: "strip" führt das sowieso nie aus, das tun nur die "install" targets -- aber wie gesagt nicht, wenn man mit DESTDIR installiert.

    Okay, danke. Bei diesem fehlte in der Tat das DESTDIR noch :rolleyes:

  • Fulgore : ich muss noch etwas mit dem Mimetypen fixen und dann hochladen.

    Die abhängige lib1541img ist schon paketiert (aber noch nicht im AUR).

    Ja cool - dann gib mal bitte Bescheid wenns im AUR ist. Dann ziehe ich mir das auch mal auf meine Kisten.

    Danke :thumbsup:

  • Fulgore : ich muss noch etwas mit dem Mimetypen fixen und dann hochladen.

    Die abhängige lib1541img ist schon paketiert (aber noch nicht im AUR).

    Ja cool - dann gib mal bitte Bescheid wenns im AUR ist. Dann ziehe ich mir das auch mal auf meine Kisten.

    Danke :thumbsup:

    Ja, Bescheid.

    Probier mal die folgenden aus und gib mal bitte ein kurzes Feedback.


    https://aur.archlinux.org/packages/lib1541img

    https://aur.archlinux.org/packages/v1541commander-nonstatic

  • Probier mal die folgenden aus und gib mal bitte ein kurzes Feedback.


    https://aur.archlinux.org/packages/lib1541img

    https://aur.archlinux.org/packages/v1541commander-nonstatic

    Coole Sache :) Diese Monsterliste an Abhängigkeiten glaub ich aber nicht... Das sind fast alles (teils wieder indirekte) Abhängigkeiten von Qt. Habe noch nie gesehen, dass man beim Paketieren indirekte Abhängigkeiten angeben muss/soll, das wäre ja auch richtig doof, stell dir vor die nächste Version von Qt nutzt eine weitere Lib, dann musst du ALLE Pakete anpassen, die Qt nutzen :)


    Also da gehört nur hin: Qt5-base (falls das mehrere pakete sind Qt5Core, Qt5Gui, Qt5Widgets und Qt5Network) und eben lib1541img :) Zur build-zeit wird moc und lrelease gebraucht, falls man das extra angeben muss.


    edit: Bei lib1541img würde ich auch vermuten, dass die "glibc" überflüssig ist, weil von der auf GNU/Linux alles abhängig ist, was mit C oder C++ compiliert wird. Die meisten Paket-Buildsysteme handlen das automatisch, aber ich kenne natürlich Arch nicht :)


    Kleinigkeit noch: bei "prefix" und "DESTDIR" (allgemein bei pfaden, auch nicht nur bei V1541Commander) gehört kein slash ans ende. Die Anführungszeichen sind in der Regel auch überflüssig.


    Sieht jedenfalls sehr simpel und sauber aus, genau wie das sein sollte :thumbup:


    edit2: Ich vermute die Aufräumaktionen (mime-database etc) gehören eher in "post-remove" :)

  • Ui, noch ne Kleinigkeit (sorry für das Gestückel, ist mir eben erst aufgefallen):


    Hast du eigentlich die Abhängigkeit auf die XDG (freedesktop.org) tools wie "update-mime-database" drin? Wie auch immer da das richtige Paket auf Arch heißt :)

  • Ich habe jetzt nicht alles gelesen, vielleicht hat es ja schon jemand angebracht.

    Es wäre schön wenn man bei export von Files wählen könnte ob es ein prg ist mit den zwei Start Bytes oder als bin ohne diese zwei Bytes.

    Dann müsste man bei machen Dateine diese nicht erst wieder im Hex editor auf dem PC entfernen.

  • Es wäre schön wenn man bei export von Files wählen könnte ob es ein prg ist mit den zwei Start Bytes oder als bin ohne diese zwei Bytes.

    Dann müsste man bei machen Dateine diese nicht erst wieder im Hex editor auf dem PC entfernen.

    Wo ist denn da der Anwendungsfall? Du meinst wohl die Ladeadresse, die hat aber nichts direkt mit dem PRG file zu tun (ist da ganz normaler Dateiinhalt) sondern ist eher Konvention, wie die CBM Rechner PRG files verwenden. Eine solche Auswahl wäre wohl am sinnvollsten machbar, wenn man bei Export auch ".bin" als Dateityp anbieten würde (was dann aber NUR für PRG files Sinn ergibt)...

    Wenn ich eine bereits erstellte .D64 Datei öffnen will beendet sich der V1541commander.

    Das Fenster verschwindet einfach? Da würde es mich eigentlich wundern, wenn das am paketieren liegen würde. Vielleicht ja auch ein bisher unbekannter Bug.

    • Kannst du selbst compilieren? Dann einfach mal sowohl die lib als auch v1541commander selbst mit BUILDCFG=debug bauen, wenn du es dann in GDB laufen lässt, sollte zumindest ein Stacktrace rauskommen, wenn es abstürzt
    • Hast du getestet, ob das mit allen .d64 Files passiert oder nur bei dem einen speziellen? Falls letzteres, kannst du mir das mal senden?
  • Hast du getestet, ob das mit allen .d64 Files passiert oder nur bei dem einen speziellen? Falls letzteres, kannst du mir das mal senden?

    Er stürzt auch ab wenn ich eine neue D64 erstellen will.

    Ich habe alles de-installiert aber der Fehler bleibt bestehen.

    Ich muss nochmal weiter testen.

  • Probier mal die folgenden aus und gib mal bitte ein kurzes Feedback.

    Hmmm irgendwie ist bei mir noch der Wurm drinnen.
    Wenn ich eine bereits erstellte .D64 Datei öffnen will beendet sich der V1541commander.

    Hattest Du das Problem auch ?

    Hi, bei mir funktioniert das alles.

    Ich habe aber keine parallel Installation gehabt - sprich ich hatte vorher die manuelle Version vom System entfernt und dann die Pakete installiert.

  • Ich habe aber keine parallel Installation gehabt - sprich ich hatte vorher die manuelle Version vom System entfernt und dann die Pakete installiert.

    Das dürfte keine Rolle spielen ... das "setup.sh" Script im statischen Build installiert nur icons, desktop-file und mimetypes und das nur für den eingeloggten User.

    Er stürzt auch ab wenn ich eine neue D64 erstellen will.

    Ok, das klingt eher fatal -- da ist vielleicht auf deinem System etwas mit den Libraries durcheinandergekommen. Welche Version von qt5 ist denn installiert? Hast du mal ein komplettes Paket-Upgrade versucht?

  • Ja, die Liste ist Monsterhaft - ich weiß. Da besteht noch Optimierungsbedarf und wahrscheinlich gibt es auch Abhängigkeiten die schon irgendwo inkludiert sind.

    Ich wollte das Paket aber erst einmal im AUR haben und die Feinheiten kann ich dann noch nachziehen.


    Zum Thema "Slash", ja das mag sein - alle Beispiele und Anleitungen für die Archpakete haben die aber drin.

    Und damit ggf. ein // sollte nicht zum Fehler führen, ein fehlender Slash könnte aber zum Fehler führen (je nach Makefile). Anführungszeichen finde ich persönlich auch nicht schadhaft bei der Übergabe von Daten :)


    Ja, mit post-remove hast Du recht. Man sollte nicht immer alles am Abend machen :D

  • Ja, die Liste ist Monsterhaft - ich weiß. Da besteht noch Optimierungsbedarf und wahrscheinlich gibt es auch Abhängigkeiten die schon irgendwo inkludiert sind.

    Praktisch alle außer Qt5 (base) und lib1541img -- und irgendwas fehlt stattdessen, um sicherzustellen, dass "update-mime-database" auch da ist.

    Zum Thema "Slash", ja das mag sein - alle Beispiele und Anleitungen für die Archpakete haben die aber drin.

    Und damit ggf. ein // sollte nicht zum Fehler führen, ein fehlender Slash könnte aber zum Fehler führen (je nach Makefile). Anführungszeichen finde ich persönlich auch nicht schadhaft bei der Übergabe von Daten :)

    Slash ist falsch, und dieses "//" wird eventuell auch in das Binary eincompiliert. Dann ist das in allen Archpaketen falsch. Ein Buildsystem, das etwas an z.B. $prefix anhängt ohne selbst einen slash einzufügen, hat einen Bug, wirklich. Gibt's natürlich trotzdem, aber zum Glück SEHR selten. Anführungszeichen sind relativ egal, bei normalen prefixes (/usr, /usr/local, ...) aber schlicht überflüssig -- in keinem filesystem hierarchy standard gibt es Namen mit Leerzeichen ;)


    edit: Wie gesagt, nicht falsch verstehen, das sind alles "Kleinigkeiten". Extra Abhängigkeiten schaden nicht direkt was, aber es könnte ja sein, dass neuere Qt-Versionen die ein oder andere Lib nicht mehr brauchen -- dann würde das Paket unbemerkt ne unnütze Abhängigkeit mit herumschleppen. Und fest eincompilierte "Doppelslahses" machen auch nichts kaputt, sind aber einfach unschön ...


    Zur Referenz die Abhängigkeiten aus dem FreeBSD port:

    Code
    1. LIB_DEPENDS= lib1541img.so:devel/lib1541img
    2. USES= gmake qt:5 shared-mime-info pkgconfig
    3. USE_QT= buildtools_build core gui linguisttools_build network widgets

    Und das ist auch wirklich schon alles :) (gmake brauchst du auf Linux nicht, das ist da sowieso das "standard make")


    Wo ich das zitiere fällt mir noch auf: pkg-config ist natürlich eine Build-Abhängigkeit, kann es sein, dass du die noch ergänzen müsstest?

  • Hmmm ... ich bin da nicht ganz überzeugt, weil das definitiv nichts mehr mit der Diskette oder dem Laufwerk zu tun hat. Klar, wenn man auf dem C64 ein EPROM image speichern will nimmt man in der Regel das PRG Format, damit die Startadresse gleich mit im File ist -- aus Sicht der Floppy ist PRG aber auch nur ein "octet stream", spezielle Behandlung der ersten beiden Bytes sind Sache des Computers, der den Dateiinhalt verwendet.


    Andererseits habe ich natürlich mit Zipcode und Lynx auch schon Features drin, die auch nichts mit dem Laufwerk bzw Format auf der Diskette zu tun haben, aber trotzdem nützlich sind. Ich denke aber *wenn* ich noch so ein Feature zur Konvertierung PRG -> BIN einbaue müsste ich (aus Gründen der Symmetrie) auch erlauben, ein BIN in ein PRG-File zu importieren, unter Angabe einer Startadresse. Das wäre dann vielleicht ein weiterer Dialog? Nicht ganz so einfach, sich da eine "vernünftige" Bedienung einfallen zu lassen.