Beiträge von Sven H

    Danke :smiling_face:


    Hab sie jetzt mal in die fstab eingetragen.
    Beim einem Test-Neustart gab es zumindest keine Probleme.


    Was mich etwas wundert ist die Ausgabe von 'fdisk -l' zum System (HPFS/NTFS).
    Sollte da nicht Linux stehen - hab sie doch als ext4 eingerichtet.
    Könnte das auch ein Problem sein?


    Code
    Disk /dev/mmcblk1: ... bytes
    ...
            Device Boot      Start         End      Blocks  Id System
    /dev/mmcblk1p1               3       15546   124852224   7 HPFS/NTFS
    Found valid GPT with protective MBR; using GPT


    bei 'mount' wird das angezeigt:

    Code
    /dev/mmcblk1p1 on /media/sdcard type ext4 (rw,relatime,data=ordered)

    Ich habe mir eine SD-Karte gekauft, um dort das Permanent Timeshift laufen zu lassen.
    Die Karte wurde beim ersten Start erkannt, mit dem GP3.3 Gerätemanager als ext4 formatiert und als "sdcard" benannt.
    Danach den Timeshift-Aufnahmepfad geändert und es hat alles funktioniert.


    Gestern kam ich Abend nach Hause und schaltete die Box aus dem Idle-Mode ein.
    Die Box ging dabei einige Stunden vorher per Elektro-Plugin aus dem DeepStandby in den Idle-Mode.
    Nach dem Einschalten kam der Hinweis dass der Timeshift-Pfad nicht verfügbar ist oder so.
    Dann stellte ich fest, dass die sdcard als "ro" (read only) gemounted war.
    Erst nach einem Box-Neustart korrigierte sich das Problem und alles funktionierte wieder.
    Einige Tests mit Neustart und Anschalten per Elektro aus DeepStandby konnten das Problem nicht reproduzieren.


    Heute nun wieder das gleiche Problem - sdcard wurde als "ro" gemountet.
    GUI-Neustart half nicht, aber Box-Neustart. Nun geht wieder alles.


    Auch ist mir nicht klar, warum es bei den Tests (inkl. Elektro) funktioniert hat und dann 2x beim längerfristigen Elektroaufwachen nicht.
    Einziger Unterschied zu den Tests war der längere DeepStandby-Zeitraum (ca. 11h).


    Woran kann das liegen ?
    Kann ich die Karte fest mit "rw" in die fstab eintragen oder beißt sich das dann mit dem GP3-Gerätermanager ?

    Mit Samsung TV sollte mit CEC zumindest das Ein-/Ausschalten zusammen mit der Dreambox funktionieren.


    Die Lautstärke am TV regle ich über die FB der Dreambox.
    Hier ist allerdings als Einschränkung zu erwähnen, dass das nur geht, wenn man das Tonsignal als Downmix an den TV weiterreicht. Gebe ich den Originalton weiter, kann man die Lautstärke am TV nicht mehr mit der Dreambox-FB steuern, da die Weiterleitung der Lautstärketasten per CEC bei Samsung nicht funktioniert. Der Unterschied zwischen Originalton und Downmix ist für mich kaum wahrnehmbar, so dass ich damit leben kann.
    So nutze ich nur noch die FB der Dreambox und die vom Samsung-TV wird grundsätzlich nicht mehr benötigt.

    Dass die Leerzeile nichts mit der Package Architektur zu tun hat, ist mir schon klar :winking_face:


    Wollte nur vorbeugen, dass du bei meinem control-file den fehlenden Zeilenwechsel am Ende bemängelst, weil der hier im code-Abschnitt immer entfernt wird :face_with_tongue:


    Das Entscheidende ist ja, dass bei dir das "PackageArch: all" im Control nicht drin ist und offensichtlich auch unter OE2.5 nicht benötigt wird.
    Diese Bestätigung zu meiner Frage in #62 hätte mir eigentlich gereicht :winking_face:

    Also ist lt. deinem control-file der Parameter "PackageArch: all" für deb entbehrlich, wenn du dieses Control für deb und ipk verwendest.


    Dann nutze ich jetzt folgendes control-file für deb und ipk inkl. Leerzeile am Ende (geht vermutlich nur bei Verwendung für all):

    Code
    Package: enigma2-plugin-extensions-githubpluginupdater
    Version: 1.0.0
    Description: Enigma2 Plugin to Update Plugins from github
    Architecture: all
    Section: base
    Priority: optional
    Maintainer: .....
    Homepage: ......
    OE: enigma2-plugins

    Achso, dann brauche ich für das deb gar nicht den Eintrag "PackageArch: all" in der Control?
    Denn der macht ja im ipk Probleme.

    Das 2. Problem (im control.tar bei ipk lagen alle Files aus DEBIAN) konnte ich auch lösen :winking_face:


    folgende Zeile im ipkg-build-script:

    Code
    tar -C $pkg_dir/$CONTROL -czf $tmp_dir/control.tar.gz .


    in folgende geändert:

    Code
    tar -C $pkg_dir/$CONTROL -czf $tmp_dir/control.tar.gz control

    Muss ich nur aufpassen, das anzupassen, wenn ich mal noch weitere conf-files benötige :winking_face:

    Ok, das Problem mit dem DEBIAN im data.tar bei ipk konnte ich lösen.


    Im ipkg-build-script einfach folgende Zeile:

    Code
    FILESWITHOUTCONTROL=`cd $pkg_dir; ls -1 | grep -v CONTROL`

    in folgende geändert:

    Code
    FILESWITHOUTCONTROL=`cd $pkg_dir; ls -1 | grep -v DEBIAN`

    Hab gerade mal ein ipk mit dem control für ipk in DEBIAN erstellt.
    Im Paket ist dann aber in data.tar neben /usr/... auch dieser DEBIAN-Ordner zusätzlich enthalten.
    Stört das oder ist das nur ein Schönheitsfehler?
    Beim deb-Paket finde ich in data.tar richtigerweise nur den /usr/...


    Was muss man denn im Script ändern, damit für ipk das richtige control-file verwendet wird, falls ich mehrere habe? (1 x für deb + 1x für ipk)


    Wenn ich in DEBIAN die verschiedenen Control-files liegen habe, dann sind die ungünstigerweise alle im ipk-Paket im control.tar enthalten.

    Ok.
    Dann muss ich aber das control-file vor dem Erstellen immer wechseln/tauschen, da ja das control von deb nicht für ipk genutzt werden kann, oder?

    Ein Problem habe ich doch noch :winking_face:
    Da ich die gleiche Ordnerstruktur zur Erstellung der *.ipk und der *.deb verwendet, habe ich im deb-Paket noch den CONTROL-Ordner und im ipk-Paket noch den DEBIAN-Ordner jeweils mit der control mit drin.


    Kann ich irgendwo angeben, dass diese Ordner jeweils ignoriert werden?


    Eine doppelte Ordnerstruktur (je eine für ipk und deb) wollte ich gern vermeiden :winking_face:

    Das habe ich mir schon fast gedacht.
    Dann ist es also überhaupt kein Problem, wenn ich das nicht gleich beim 1. Mal hinbekommen habe :face_with_tongue:


    Vielleicht könnte ja ein Admin/Moderator die ganzen Posts hier zur deb-/ipk-Erstellung als eigenen Thread auslagern.


    Ich finde, dass sind sehr hilfreiche Infos, die man sonst vermutlich nirgends so gebündelt findet :smiling_face:

    Ahh, super.


    Dann sollte es jetzt passen.
    Hab jetzt für *.deb sowohl für Architecture: als auch für PackageArch: all eingetragen.

    Ok, Danke.
    Hab es zum Glück noch nicht versucht zu installieren :smiling_face:


    Hab jetzt das PackageArch und OE im control für ipk rausgenommen.


    Welches PackageArch muss ich denn für OE2.5 eintragen, wenn es für mips32el und armhf sein soll.
    Dachte da reicht dann Architecture: all


    Muss ich den PackageArch: mips32el komplett löschen, wenn es für alle sein soll ? (Also z.B. für 7080 + 9x0)


    Oder muss das dann so rein:
    Architecture: all
    PackageArch: all

    Weiß auch nicht, wie das mit dem Kopieren passiert ist.
    Hatte ich wie gesagt noch nie.
    Egal - jetzt hat es ja geklappt :winking_face:


    Ja, das einfache ENTER habe ich nach dem letzten Text gemacht.


    Wenn man es erstmal fertig hat, ist es gar nicht so kompliziert :grinning_squinting_face:


    Aber ohne Hilfe hätte ich das nicht geschafft, Danke nochmal :thumbs_up:

    Hab ja einen Linux-fähigen Editor und damit die control in DEBIAN erstellt.
    Blöderweise wurde beim Kopieren in den anderen Ordner in dos gewandelt.
    Ist mir leider nicht gleich aufgefallen :winking_face:
    Sowas ist mir ja noch nie passiert.


    Reicht ein Enter hinter dem letzten Text "Source: .........", oder muss ich in der letzten Zeile noch ein Leerzeichen machen und noch ein Enter?

    Jetzt hat es geklappt - binutils waren bereits installiert.


    Vielen Dank !!! :thumbs_up:


    Das mit den "illegal characters" lag am falsch kopierten control-file.
    Da kamen plötzlich Windows-Zeilenumbrüche rein. :angry_face:

    mir kommt es so vor, als wenn das Script nichts aus der control auslesen kann.


    Das steht in der control in CONTROL