Anleitung zum Kompilieren von VLC 2.0 gesucht

[KBDCALLS]

Im Prinzip ist Backporting ja relativ einfach . Man holt sich die Sourcen entweder mittlles apt-get source oder manuell , muß sie dann aber selbst entpacken dpkg -source -x vlc...dsc. Dann macht mit dch --bpo einen Eintrag im Logfile.Und kann dann kompilieren . Entweder mit pbuilder oder pdebuild. So in etwa in Kurzform wenn alle Build dependcies ins Squeeze erfüllt wären. Dem ist aber leider nicht so. Selbst wenn man die Backports dazunimmt, dann funktionierts nicht. Mindestens 1 Paket mus man selbst Backporten, und das funktioniert nicht so wie gedacht. libbluray machte mehr Probleme als gedacht. . Aptitude/apt/get wollten es nicht installieren , wegen abweichender Größe.

[KBDCALLS]

Selbst der Bau von VLC 2.0.0 (Debian Original) auf wheezy funktioniert nicht.

[Henrikx]

Hmmm
ich werde mal bis Dienstag schauen, wie weit ich komme...und dann berichten.

[KBDCALLS]

Was mir bislang aufgefallen ist, in den Sourcen vom multimedia.org ist nasm als build-depend mit angegeben. Schicke das mal durch den Compiler mit Wheezy mal sehen was dabei rauskommt.

[chb]

Selbst der Bau von VLC 2.0.0 (Debian Original) auf wheezy funktioniert nicht.

Wo hängt's denn?
Ich bin zwischenzeitlich von vlc_2.0.0-1 [debian-multimedia testing] auf 2.0.0-6 [debian.org testing] umgestiegen;
Hier tut's ein triviales "apt-get build-dep vlc/testing" gefolgt von "apt-get --build source vlc/testing"
- compiliert & baut problemlos unter Wheezy [686]
Welche Fehlermeldung(en) bekommst Du?

[KBDCALLS]

Ich poste mal die letzen Zeilen des Logfiles 36321 . Mein Verdacht ist übrigens das sich den Builddepends Fehler eingeschlichen haben . Es fehlen dabei 5 Pakete , wenn man die mit den Build-depends von Multimedia.org vergleicht. Quilt kann übrigens dabei vernachlässigen. Denn Multimedia.org verwendet noch das alte Sourcenformat.

[chb]

"Error 1" - ist idT eine wahnsinnig qualifizierte, hilfreiche Fehlermeldung

Mit den Builddepends könntest Du recht haben. 'vlc-dmo' aus debian-multimedia verlangt u.a. zusätzlich 'ccache' und 'nasm'; die entsprechende build-Zeile beginnt bei mir demgemäß auch anders: "libtool: compile: ccache cc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. [...]" 36325 (was gibt 'apt-cache policy ccache' bei Dir aus?).
Zum Vergleich die Build-Depends aus vlc_2.0.0-6.dsc 36322 und vlc-dmo_2.0.0-0.1.dsc 36323.

So, hab jetzt aus Neugier einfach mal "apt-get build-dep vlc-dmo" und "apt-get --build source vlc-dmo" angeschmissen - compiliert & baut bei mir auch einwandfrei! Woran liegt's also??
Falls nicht nur 'ccache' fehlte, spiel doch evtl. mal die vlc/testing -Dependencies(!) vor dem nächsten Versuch ein, vlc-dmo zu bauen ...ggf. hängt's tatsächlich nur an einer falschen (Versions-) Angabe in den Build-Depends, vlc/testing fordert in mehreren Fällen eine höhere Version der Bibliotheken als vlc-dmo, evtl. liegt das Problem hier?

Ich habe ein buildlog zu vlc-dmo_2.0.0 angelegt und könnte es hochladen, falls gewünscht - ist aber 3,2MB(!) groß...

[KBDCALLS]

Die Build-depends fehlten tatsächlich. Warum yasm und nasm beide verwendet wurden ist eigentlich unlogisch, die tun nach der Beschreibung beide das gleiche.

Yasm is a complete rewrite of the NASM assembler

ccache ist warscheinlich verzichtbar. Der beschleugnigt das ganze, in dem er Doppelkompilierungen verhindert. Das Buildlog war mit 3816 KB noch etwas größer.

Jetzt stünde dem Backport von VLC eigentlich nix mehr im Wege, wenn das Problem mit libbluray nicht wäre. http://debianforum.de/forum/viewtopic.p ... 30#p871156

[chb]

Das hört sich doch schon mal gut an.
yasm, nasm und ccache sind grundsätzlich scheinbar ohnehin verzichtbar(?), schon im vlc_2.0.0-2 changelog steht "Remove nasm and yasm form build dependencies (they are not used)" [1], ccache ist ebenfalls i.d. vlc/testing Build-Depends [s.o.] nicht (mehr) gefordert. Hmmm...

Das libbluray -Problem versteh' ich grad nicht... 'libbluray1' und 'libbluray-dev' sind in den squeeze-backports verfügbar [2], warum selbst bauen? Oder waren bereits diese mit 'leider zu alt' [3] gemeint?
Und wenn: lässt sich die von Dir backportierte libbluray noch nicht mal a la 'dpkg -i --force-bad-verify xxyyzz' einspielen?
Mangels Squeeze, zudem reichlich pbuilder -Allergie bin ich für die eigentliche backport -Fragestellung aber sicher keine große Hilfe...

[1] Debian Changelog vlc http://packages.debian.org/changelogs/p ... /changelog
[2] Debian Paketsuche squeeze-backports http://packages.debian.org/search?suite ... =libbluray
[3] http://debianforum.de/forum/viewtopic.p ... 15#p869853

[Henrikx]

Ist das Problem jetzt gelöst?

[KBDCALLS]

Das hört sich doch schon mal gut an.
yasm, nasm und ccache sind grundsätzlich scheinbar ohnehin verzichtbar(?), schon im vlc_2.0.0-2 changelog steht "Remove nasm and yasm form build dependencies (they are not used)" [1], ccache ist ebenfalls i.d. vlc/testing Build-Depends [s.o.] nicht (mehr) gefordert. Hmmm...

Das war wohl zu voreilig., bzw da der Wunsch Vater des Gedanken.

Das libbluray -Problem versteh' ich grad nicht... 'libbluray1' und 'libbluray-dev' sind in den squeeze-backports verfügbar [2], warum selbst bauen? Oder waren bereits diese mit 'leider zu alt' [3] gemeint?

Das ist genau das Problem Das was ist den Backports ist zu alt.

Und wenn: lässt sich die von Dir backportierte libbluray noch nicht mal a la 'dpkg -i --force-bad-verify xxyyzz' einspielen?
Mangels Squeeze, zudem reichlich pbuilder -Allergie bin ich für die eigentliche backport -Fragestellung aber sicher keine große Hilfe...

Das könnte man versuchen in der apt.conf des base.tgz von Pbuilder unterzubringen. pbuilder ist aber die beste Möglichkeit festzustellen, ob die Build-depends stimmen. Da fällts sofort auf wenn etwas nicht stimmig ist. Baue ich mit dpkg-buildpackage baue ich im laufenden Sytem. Ist ein benötigtes Paket auf Rechner A installiert fällts garnicht auf , das es in builddepends nicht aufgeführt ist. Auf Rechner B ist es nicht installiert und es kracht und man wundert sich warum.

[KBDCALLS]

Ist das Problem jetzt gelöst?

Wollens wirs hoffen, Bis auf libbluyray scheint jetzt alles vorhanden zu sein.

[KBDCALLS]

Das wird ne größere Aktion. Da muß einiges gebackported werden. Auch Programme die mit VLC selbst nicht zu haben. Die Javatools beispielsweise. Und was mir immer wieder nen Strich durch die Rechnung macht ist der Multi-Arch Support.

[clue]

Wie macht denn arch Linux das (oder wars Gentoo?)? Die holen sich doch automatisch die sourcen und kompilieren standardmäßig jedes Paket für den eigenen Rechner.

Nee ... ich wart jetzt auf den Backport / nächsten Debian release

[chb]

Auch auf die Gefahr hin, zu nerven... ich verstehe das libbluray -Problem immer weniger:
Wie der Zufall will, durfte ich gestern spät für Freunde ein squeeze (6.0.3 live-cd, LXDE, x686) installieren und habe für eigene Zwecke eine Installation auf externe HDD 'mitlaufen' lassen. 'apt-get update', 'apt-get dist-upgrade', pbuilder mit allen recommends eingespielt (aber bisher nicht verwendet ;-| ), beide jre's installiert, Iceweasel aktualisiert. Neugierhalber heute früh 'apt-get build-dep --no-install-recommends libbluray1' angeworfen, danach manuell von [1] libbluray_0.2.1+git20111208.63e308d-3.dsc, libbluray_0.2.1+git20111208.63e308d.orig.tar.gz, libbluray_0.2.1+git20111208.63e308d-3.debian.tar.gz heruntergeladen. 'dpkg-source -x libbluray_0.2.1+git20111208.63e308d-3.dsc' durchgeführt, im Verzeichnis schlicht './configure' und 'fakeroot debian/rules binary' laufen lassen. Tut, baut, die .deb-Pakete lassen sich aber zunächst wg. fehlender Multiarch-Unterstützung nicht installieren.
Afaik keinerlei anderen relevanten Probleme (oder ich kapier's nicht?).

Dann muss die Multiarch-Unterstützung eben raus, gabs noch nicht in Squeeze. Gemäß [2] revers rules anpassen (also "#DEB_HOST_MULTIARCH [einfach auskommentiert]") und in den *.install files "usr/lib/*/" wieder zu "usr/lib". Klappt, baut, lässt sich per gdebi brav installieren, ebenfalls libbluray-dev. Auch mit der aktuellen git -Version[3] probiert: dito.

Ein im backport leicht modifiziertes xxyyzz.debian.tar.gz wäre doch vermutlich akzeptabel(?)
Aber warum klappt das auf einem halb-'nackten' squeeze hier fast ootb und im pbuilder ja scheinbar nicht??
Ich habe meine 'sources.list' angefügt, vielleicht findet sich die Ursache - oder der backport klappt doch noch

[1] Debian Source Package: libbluray (1:0.2.1+git20111208.63e308d-3) http://packages.debian.org/source/wheezy/libbluray
[2] http://wiki.debian.org/Multiarch/Implementation
[3] git://git.debian.org/git/pkg-multimedia/libbluray.git
[4] sources.list 36337

[KBDCALLS]

Was da genau schiefgeht ist mir momentan nicht ganz klar. Habe aber mittlerweile den Backport hinbekommen. Allerdings mußte dafür libbluray und libmatroska vorübergehend deaktivieren. Und das sind genau die Mutiarchgeschichten. Muß auch dazusagen über die Offiziellen Backports ist ein neues dpkg-dev Paket heireingeschneit. Wegen Multiarch. Was des Kompilieren des Quellcodes anbetrifft, würde ich mal in Betracht ziehen das daß configure Script so intelligent ist das es Optionen die es nicht mit kompilieren kann , weil die Vorausetzung dafür nicht vorhanden sich erst garnicht aufnimmt.

[chb]

Was spricht denn dagegen, Multiarch-Unterstützung zu deaktivieren (immerhin bietet das System auch keine) - und ist 'rules' nicht der geeignete Ort dafür (ist im o.g. Debian-wiki Artikel zu Multiarch so dokumentiert) "Set DEB_HOST_MULTIARCH in debian/rules by calling: DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)" ?

Das Konsolenlog hab ich hier 36338 mal abgelegt, vielleicht ist's nützlich, wenn nicht lösche ich es.

[KBDCALLS]

Multiarch reicht nicht alleine. Habe die betreffenden Pakete noch mal neu gebaut und dabei die in /usr/lib untergebracht. dann funktionierts auch mit dem Kompilieren. Bei den Wheezy Paketen sind die Libs in /usr/lib/i386-linux-gnu. Das funktionierte nur nicht. Auf jedenfall ists geschafft. Backporten mußte ich javatools, libarchive-zip-perl , libbluray, libebml, liblivemediia, libmatroska, orc und schroedinger Ein Teil kam aus den offiziellen Backports.

[clue]

Ok, und wer von Euch lädt das jetzt bei Backports hoch

[chb]

Da KBDCALLS uneingeschränkt damit Recht hat, dass ein größerer backport ohne geeignete build-Umgebung wie pbuilder kaum 'sauber' ablaufen kann, ist mein backport von vlc2 entsprechend nur mäßig 'clean' (wäre aber ggf. zu haben).
Um der apt .log & -purge Hölle zu entgehen, versuche ich, mich über's WE doch temporär mit pbuilder anzufreunden.
KBDCALLS build ist aber sicher der 'gescheitere'.

Ich habe übrigens nur libbluray selbst neugebaut (ohne Multiarch-Unterstützung, s.o.), und libebml [1], liblivemediia [2], libmatroska [3] (weitere?) von snapshot.debian.org 'ziehen lassen', z.T. in der sources.list Einträge a la
'deb http://snapshot.debian.org/archive/debian/20120310/ squeeze main'
gesetzt (die exakten Einträge muss ich zusammenfummeln), sparte mir Zeit & Nerven.
Sollte mit pbuilder nach 'offiziellem' Prozedere auch gehen (oder)?
Wenn nichts gegen dieses Vorgehen spricht(?), sollte ich SO oder MO einen 'sauberen' und vollständigen port hinkriegen können, falls nicht KBDCALLS doch besser seinen zur Verfügung stellt, er hat wohl mehr Erfahrung mit backports

[1] http://snapshot.debian.org/package/libebml/1.0.0-1/
[2] http://snapshot.debian.org/package/libl ... 9.11.27-1/
[3] http://snapshot.debian.org/package/libmatroska/1.3.0-1/

[clue]

Wäre cool, chb

Was ich auch noch mal sagen wollte: Pbuilder funzt deswegen nicht so rund, gerade weil er dazu konzipiert worden ist, bei allen möglichen Entscheidungen die Dümmste zu wählen. Dadurch können die Paketbauer sehen, wo etwas im build schief läuft.

[KBDCALLS]

Wäre cool, chb

Was ich auch noch mal sagen wollte: Pbuilder funzt deswegen nicht so rund, gerade weil er dazu konzipiert worden ist, bei allen möglichen Entscheidungen die Dümmste zu wählen. Dadurch können die Paketbauer sehen, wo etwas im build schief läuft.

Das kommt auf den Standpunkt an, ob man der Ansicht ist das pbuilder nicht rund läuft. Hat immerhin den Vorteil man muß sein System nicht mit allen erdenklichen Develpaketen zumüllen muß.

[chb]

EDIT: aktualisiert, siehe unten.

[chb]

Vlc2 und die dependencies libebml2, libmatroska2, libbluray1 sind auf squeeze backportiert - einschl. optionaler Pakete und der sourcen.
[Architektur i686, Version vlc-dmo, gg. Bibliotheken aus debian-multimedia.org gelinkt, bisher sind die Pakete nicht signiert].
Das browser-plugin-vlc wird in einigen Tagen voraussichtlich ebenfalls als squeeze-backport dort verfügbar sein.

Ich habe das Ganze mittlerweile in ein weiteres Projekt, ein inoffizielles kleines ppa eingebunden.
Die Pakete und Quellen stehen unter http://ppa.bplaced.net zur Verfügung.

Zur Installation müssen die Quellen

Code: Alles auswählen

deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free
deb http://www.debian-multimedia.org stable main non-free

aktiviert sein.
Zusätzlich dann ppa.bplaced.net in die sources.list eintragen:

Code: Alles auswählen

deb http://ppa.bplaced.net/backports /
# deb-src http://ppa.bplaced.net/backports /  [optional]

Bitte online readme lesen.
Testen & Rückmeldung sind sehr erwünscht.

EDIT: Dieser Bereich ist ab sofort nicht mehr öffentlich zugänglich.
Bitte ggf Testinstallationen löschen, um Versionsprobleme mit dem 'offiziellen debian-multimedia.org' backport auszuschließen!

[clue]

COOL, CHB

Sag mal, warum brauchen wir denn trotzdem die debian-multimedia Pakete? Bei mir haben die offiziellen Squeeze Pakete noch nie mit denen aus multimedia harmoniert. Wenn ich die gemixt habe, dann konnten immer irgendwelche Videos nicht mehr abgespielt werden, die sonst funktionierten. Ich kann dafür auch gerne ein Beispiel hochladen.