VDR-Installation unter Arch Linux : vdr-2.1.6-5-x86_64 hat keine gültige Architektur

  • Hallo zusammen,


    ich habe gerade versucht, den VDR anhand dieses Wikis unter Arch Linux (32Bit, Kernel 3.14.4-1-ARCH) zu installieren. Einträge in pacman.conf wie im Wiki angegeben,


    Code
    -> pacman -Sy 
    -> pacman -S vdr 
    ->Fehler: Konnte den Vorgang nicht vorbereiten (Die Paket-Architektur ist ungültig)
       :: Paket vdr-2.1.6-5-x86_64 hat keine gültige Architektur


    kennt jemand dieses Problem ? Wie kann ich das Paket aus dem dort genannten Repo installieren ?

  • Gibt es für dich einen speziellen Grund kein x86_64 einzusetzen?


    Gute Frage...


    Ich habe nie daran gedacht, dass jemand 32 Bit einsetzen möchte. Das wäre theoretisch einfacher zu unterstützen als ARM (was ich weiterhin auf meiner TODO Liste habe), für einen Einzigen werde ich das aber nicht machen.
    Sagen wir du findest 5 Leute, die 32 Bit Pakete haben möchten und du sollst 32 Bit Pakete bekommen.

  • Copperhead bietet die fertigen Pakete im Repo nur für x86_64 an.


    Für i686 wirst du sie wohl selber bauen müssen (makepkg bzw. repo-make). Gibt es für dich einen speziellen Grund kein x86_64 einzusetzen?


    Mein altes Laptop hat 4G RAM,da reichen mir 32Bit :)


    Wenns nur über den manual build geht, dann sei es so, kein Problem, ist allerdings gut zu wissen. :)



    Btw:


    ->new topic? :)

  • Mein altes Laptop hat 4G RAM,da reichen mir 32Bit :)

    Man weiß gar nicht wie oft man das noch sagen muß, die 4GB Grenze ist nicht der Grund um auf 64-bit zu setzen. Es ist seit Jahren easy peasy möglich mehr als 4GB mit 32bit Kernel zu addressieren, PAE = Physical Address Extension.


    Es gibt nur einen Grund nicht 64-bit zu installieren, auf HW die das nicht kann. Da diese inzwischen so selten ist, ist 64-bit eigentlich Standard, auch bei Linux. Alles läuft besser, schneller, die HW wird mit allen Fähigkeiten ausgenutzt. Meine VDRs laufen seit ca. 2006 64-bit, mit 1, 2 oder auch 4GB. Während der VDPAU Findungsphase in 2009/2010 hatte ich viele Probleme anderer Nutzer nicht, weil das System mehr Daten schneller durchsetzen konnte ...


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Volle Zustimmung. Wenn 64bit geht, dann wäre Umstellen die einfachste Lösung.


    Ansonsten wäre auch selberkompilieren eine Option. Ist mit den vdr4arch-Paketen wirklich keine große Sache. Du brauchst nur ein 32bit ArchLinux in einer VirtualBox installieren und via "repo-make" das ganze Repository durchkompilieren.

  • Volle Zustimmung. Wenn 64bit geht, dann wäre Umstellen die einfachste Lösung.


    Ansonsten wäre auch selberkompilieren eine Option. Ist mit den vdr4arch-Paketen wirklich keine große Sache. Du brauchst nur ein 32bit ArchLinux in einer VirtualBox installieren und via "repo-make" das ganze Repository durchkompilieren.


    Das Durchcompilieren habe ich bereits probiert, dabei trat der o.g. Fehler auf. :)


    Ich nehme eure Meinungen bezüglich der 64Bit-Wahl zur Kenntnis, halte die Diskussion allerdings nicht für sonderlich zielführend, lasst uns bitte NICHT über die Pros/Cons von 64Bit-Systemen reden. :)


    Leider ist der manual build nicht gelungen (s.o.), könntet ihr mir zu diesem Problem vielleicht etwas raten ? (...außer "nimm ein 64Bit-System" :P )

  • Leider ist der manual build nicht gelungen (s.o.), könntet ihr mir zu diesem Problem vielleicht etwas raten ?


    Ja, die aktuellste Version aus dem Git nutzen, die gleich zwei Probleme beseitigt: das compilieren auf 32-Bit Systemen und einen Segfault beim Beenden des Plugins.
    Im PKGBUILD reicht es die _gitver anzupassen (und ggf. die Versionsnummer hochzudrehen):

    Code
    _gitver=d264ad83ac3b2eb7d0230f9ecf4230cdee1d4f74

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Gut. Dann ändere ich das später. Ich springe bei den epgd Sachen normalerweise nur von Release zu Release. Dort wird so oft etwas committet wer soll da noch mitkommen.


    Edit: Ich habe es im Git geändert. Ich lass gerade auch mal einen 32 Bit Build laufen, um noch weitere Fehler aufzuspüren.

  • lasst uns bitte NICHT über die Pros/Cons von 64Bit-Systemen reden. :)

    Ich wollte nicht diskutieren, gibt es eigentlich auch nichts, Du lehnst 64-bit aufgrund einer nicht korrekter Annahme ab und Cons gibt es auch keine.


    Copperhead hat m.E. eine tollen Job in seiner Freizeit mit seine Pakete für vdr4arch gemacht, 64-bit, und die Frage ist wirklich ob ausser Dir jemals jemand wieder 32-bit Pakete dafür benötigt. Das wirft eher die Frage auf, was hier zielführend ist, just my 2 cents.


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Ich nehme eure Meinungen bezüglich der 64Bit-Wahl zur Kenntnis, halte die Diskussion allerdings nicht für sonderlich zielführend, lasst uns bitte NICHT über die Pros/Cons von 64Bit-Systemen reden.
    Leider ist der manual build nicht gelungen (s.o.), könntet ihr mir zu diesem Problem vielleicht etwas raten ? (...außer "nimm ein 64Bit-System" :P )


    Du bist schon irgendwie witzig, Erst sagst du die 64Bit-Diskussion ist nicht zielführend, obwohl du doch ganz genau weißt dass sie es doch ist.
    Denn es ist ja nun so, dass eine 64Bit-Version zum Ziel führt.


    Außer du hast ein uns völlig unbekanntes Ziel. Ich denke die meisten hier gingen wohl davon aus, dass du einen VDR unter Archlinux betreiben wolltest.


    Was hast du denn wirklich vor?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • crawler: Funktioniert es jetzt für dich?


    Bei Arch Linux wollte man i686 Support sowieso schonmal entfernen. https://www.archlinux.org/news/dropping-i686-support/
    Warum das seitdem aber nicht passiert ist, weiß ich nicht.


    Für vdr4arch könnte man natürlich argumentieren, dass es wegen den fehlenden 32 Bit Paketen nicht vollständig kompatibel zu Arch Linux ist.
    Es stellt für mich keinen übermäßigen Mehraufwand dar. Meine Skripte sind grundsätzlich dazu in der Lage auch für eine zweite Architektur zu kompilieren.


    Aber da ist selbst die Nachfrage nach Manjaro Paketen größer... Wenn du trotzdem darauf bestehst... Ich werde aber nichts versprechen.


    Nächster Schritt ist jetzt erstmal armv6...

  • Meinem aktuellen Wissensstand nach benötige ich die entsprechende Hardware um die Pakete zu kompilieren.
    Daher werde ich mir die nächsten Tage einen Raspberry Pi anschaffen.


    Ich habe ARMv6 schonmal mit qemu emuliert, das ist aber extrem langsam.

  • Meinem aktuellen Wissensstand nach benötige ich die entsprechende Hardware um die Pakete zu kompilieren.
    Daher werde ich mir die nächsten Tage einen Raspberry Pi anschaffen.


    Ich habe ARMv6 schonmal mit qemu emuliert, das ist aber extrem langsam.

    ja das weiss ich ... ich hätte da Nachts ein armv5 frei ;)

    Banana PI MLD server

    Banana PI Satip Server


    ESXI MLD 5.x




    Raspberry mit Kodi als Frontend , mit waf

  • ich hätte da Nachts ein armv5 frei


    Mal schauen. Jetzt muss erstmal ARMv6 funktionieren.
    Im Arch Linux ARM Forum hat es jemand geschafft, die Pakete für ARM komplett auf seinem x86 System zu kompilieren.


    Er hat das allerdings etwas schlecht erklärt und daher bin ich gerade am experimentieren.


    Edit: Geht wohl nicht. Keine Ahnung, was der gemacht hat.


  • Mal schauen. Jetzt muss erstmal ARMv6 funktionieren.
    Im Arch Linux ARM Forum hat es jemand geschafft, die Pakete für ARM komplett auf seinem x86 System zu kompilieren.


    Er hat das allerdings etwas schlecht erklärt und daher bin ich gerade am experimentieren.


    Edit: Geht wohl nicht. Keine Ahnung, was der gemacht hat.

    ok, kein stress... können ja bei Gelegenheit via PM darüber unterhalten
    gruß
    karsten

    Banana PI MLD server

    Banana PI Satip Server


    ESXI MLD 5.x




    Raspberry mit Kodi als Frontend , mit waf

  • Was i686 angeht: Schau mal auf das Datum von dem Newsartikel. Kann Zufall sein, aber wer weiß...


    Ich würde mir den Aufwand dennoch nicht antun. Zumindest meine Erfahrung ist: Biete nichts an was du nicht auch selber testen kannst oder willst.


    Für ARM bauen ist leider nicht ganz trivial. Selbst Archlinux-ARM empfiehlt hier DistCC. Ich habe es damals probiert und bei mir wurde der angebliche Vorteil vom langsamen IO der ARM-Platine aufgefressen. Da hätte ich auch gleich direkt auf dem ARM-Board bauen können. Um von DistCC profitieren zu können braucht man wohl mindestens ein natives LAN. Am besten Gigabit.


    Unproblematisch sind nur Kernel. Die unterstützen direkt Cross-Compile und brauchen neben einem Compiler keine externen Abhängigkeiten. Hier kann man die volle Geschwindigkeit des Desktop-Systems ausnutzen.


    Kennt jemand eine wirklich schnelle ARM5-Platine? Könnte ich auch für meine Zwecke gut brauchen...

  • Definiere mal schnell. Das zyxel nsa 325v2 was ich habe hat gigabit lan. 1,6mghz cpu und 512 mb ram


    Gesendet von meinem GT-I9100 mit Tapatalk

    Banana PI MLD server

    Banana PI Satip Server


    ESXI MLD 5.x




    Raspberry mit Kodi als Frontend , mit waf

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!