staging.inyokaproject.org

Moin liebe Ubuntu-Gemeinde,

ich versuche mich seit einigen Tagen leider immer wieder vergeblich darin für mein Lucid-System den aktuellen Release vom Firefox zu bauen. Hierzu habe ich mir den aktuellsten Tarball von Mozilla gezogen und die Lokalisierungen und die Python-Scripts "compare-locales" dazugelegt. Als Ausgangspunkt zum späteren Bauen dann das debian-Verzeichnis des letzten Lucid-Builds genommen, ein paar Patches entfernt und den Rest aktualisiert. Dann noch eine kleine Änderung in debian/rules und debian/build/mozbuild.mk vorgenommen. Letzt genannte sind aber nur Kosmetik, da compare-locales jetzt unter dem Verzeichnis python liegt und dpkg-source keine Option 'extend-diff-ignore = "^\.mozconfig\."' kennt, sondern nur die Kurzform '-i', welche ich ja bei debian/source/options nicht verwenden kann. Oder gibt es doch Möglichkeiten beim format 3.0 Kurzformen von Optionen in debian/source/options aufzunehmen? Aber zurück zum eigentlich Thema. Eigentlich läuft es beim Übersetzen aus meiner Sicht ganz gut und meiner Einschätzung nach geht sogar recht weit voran. Allerdings bleibe ich immer wieder bei dem folgenden Test hängen, bei dem ich dachte dass dieser bei Fehlerauftritt vollständig ignoriert werden sollte → siehe hierzu debian/patches/test-integration/xpcshell-disable-tests-which-need-appdir-write-access.patch.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

TEST-UNEXPECTED-FAIL | /tmp/buildd/firefox-21.0/obj-x86_64-linux-gnu/_tests/xpcshell/browser/components/places/tests/unit/test_browserGlue_distribution.js | test failed (with xpcshell return code: 0), see following log:
>>>>>>>

TEST-INFO | (xpcshell/head.js) | test 1 pending

TEST-INFO | (xpcshell/head.js) | test 2 pending

TEST-PASS | /tmp/buildd/firefox-21.0/obj-x86_64-linux-gnu/_tests/xpcshell/browser/components/places/tests/unit/test_browserGlue_distribution.js | [run_test : 32] true == true

TEST-PASS | /tmp/buildd/firefox-21.0/obj-x86_64-linux-gnu/_tests/xpcshell/browser/components/places/tests/unit/test_browserGlue_distribution.js | [run_test : 40] 1 == 1

TEST-UNEXPECTED-FAIL | /tmp/buildd/firefox-21.0/obj-x86_64-linux-gnu/_tests/xpcshell/browser/components/places/tests/unit/test_browserGlue_distribution.js:43 | TypeError: Cc['@mozilla.org/browser/browserglue;1'] is undefined - See following stack:
JS frame :: run_test@/tmp/buildd/firefox-21.0/obj-x86_64-linux-gnu/_tests/xpcshell/browser/components/places/tests/unit/test_browserGlue_distribution.js:43
JS frame :: _execute_test@/tmp/buildd/firefox-21.0/testing/xpcshell/head.js:325
JS frame :: @-e:1

TEST-PASS | /tmp/buildd/firefox-21.0/obj-x86_64-linux-gnu/_tests/xpcshell/browser/components/places/tests/unit/test_browserGlue_distribution.js | [null : 102] false == false
<<<<<<<

Aber so wie es im Moment aussieht scheine ich da wohl doch falsch zu denken.. Jemand vielleicht eine Idee wie ich den Test explizit unterbinden kann?

Schöne Grüße
Endi

PS: Da ich mich jetzt in die Koje werfe, wünsche ich allen eine angenehme Nacht.

Endanwender schrieb:

für mein Lucid-System den aktuellen Release vom Firefox zu bauen.

Wenn Du dann eine unterstützte Ubuntu-Version fährst, wirst Du wohl auch Fx nicht mehr kompilieren brauchen (eh eine Sache für sich, hab' das auch eine zeitlang gemacht), sofern Du nicht irgendwelche Spezialgeschichten benötigen solltest.

Hi Endi,

wegen der langen Option brauchst du mindestens dpkg 1.15.6, kurze Optionen gehen nicht.

Bei Paketen wird meist die Option nocheck unterstützt, um zu verhindern, dass die Testsuites ausgeführt werden. Entsprechend die Umgebungsvariable DEB_BUILD_OPTIONS damit erweitern, z.B.: "export DEB_BUILD_OPTIONS=$DEB_BUILD_OPTIONS,nocheck"

Wie genau das bei Iceweasel, bzw. Firefox unterstützt wird, kann ich ohne Kenntnis des Debiancodes nicht sagen. Falls es damit nicht geht, schaue ich mir mal den Patch an und warum er nicht so wirkt wie gewünscht. (Hoffentlich wird quilt verwendet...)

Gruss Lasall

Eine Idee ist auch noch, sich einfach den zur Architektur passenden tarball zu laden und fertig. firefox und thunderbird zu kompilieren macht keinerlei Spass und dauert imho unverhältnismäßig lange. Eine andere Idee ist, sich einfach mit gentoo zu befassen, da findet man bestimmt auch ein funktionierendes ebuild in einem Overlay. Und dann kompilieren, was das Herz begehrt. Für debianoide Systeme ist das im allgemeinen recht sinnbefreit.

Äh, noch einer zum Bauen: Damit man die Chance hat, seine Builds unabhängig von der aktuellen Installation reproduzierbar zu halten, hat man auf debianoiden Systemen noch die Werkzeuge pbuilder und sbuild, auf den pbuilder und cowdancer aufsetzend, den cowbuilder. Eine dieser Möglichkeiten sollte man nutzen. Zum Nachhalten der eigenen Änderungen und patches bietet sich quilt an. Man sollte diese Werkzeuge nutzen, alles andere ist Zeitverschwendung.

Hallo agaida, hallo Lasall,

klar könnte ich das statische Binary vom Firefox nutzen und das würde mir sicherlich auch Zeit und Nerven kosten. Aber da ich mich gerade sowieso mit der Materie Paketbau etc. beschäftige, sehe ich das momentan auch als gewisse Herausforderung und sei es nur akademischer Natur. Insbesondere gerade durch die aufgetretenen Probleme sind mir in den letzten Tagen doch einige Dinge klarer geworden.
Für meine Bauvorgänge nutze ich generell pbuilder als Umgebung. Allein schon aus dem Grund sich nicht das System mit allen möglichen Paketen zu zuballern. Meine bisherigen bescheidenen Erfahrungen sind bisher auch sehr positiv verlaufen. Auch quilt habe ich gerade in den letzten Tagen schätzen gelernt, weil man durch die einfache Art von Erstellen/Entfernen von Patches eben auch mal Sachen ausprobieren kann und gegebenenfalls auch schnell wieder verwerfen. Macht schon irgendwie Spaß, auch wenn ich noch ganz am Anfang der Materie stehe. Leider sehe ich mich aber gerade beim Firefox jetzt in einer Sackgasse. Okay es ist auch ein recht komplexes Thema, aber gern würde ich es schaffen wollen.

Schöne Grüße
Endi

Hi Endi,

hilft die nocheck-Option weiter?

Gruss Lasall

peste doch mal die debian/rules

Hallo agaida, hallo Lasall,

an dieser Stelle und mit Verspätung möchte ich mich bei euch für euer Interesse bedanken. Das Problem ist insoweit gelöst, als dass ich die aktuellste Firefox-Version (22.0) erfolgreich für Lucid bauen könnte. Hat etwas Mühe und Zeit gekostet dahinter zu kommen, aber der Lerneffekt dabei wird zukünftig vielleicht im Allgemeinen hilfreich sein.

Schöne Grüße
Endi

Wenn Du damit Erfolg hattest - ganz feine Sache. Ich tue mich mit Firefox, Thunderbird und Chromium immer schwer, es macht keinerlei Spass. Mal grade eben einen Kernel zu patchen und bauen ist da wesentlich erfrischender, weil ist nicht so kompliziert und dauert nicht so lange. Aber jeder so wie er will und mag 😀

Ja einfach war es wirklich nicht. Aber mich hat der Ehrgeiz irgendwie nicht verlassen und siehe da mit etwas Ausdauer und viel Lust am Experimentieren ging es letztlich. Zu mindestens läuft der FeuerFuchs bisher recht gut, so hoffe ich doch nicht allzu viele Fehler dabei gemacht zu haben.

Schöne Grüße
Endanwender

Hi Endanwender,

klasse dass es geklappt hat! Kannst du evtl. im Groben sagen, was du alles anpassen musstest?

Gruss Lasall

Hallo Lasall,

klar kann ich das ☺. Alles nachzulesen da → https://launchpad.net/~fziegler/+archive/support/+packages.
Kurz und knapp: Ich habe den letzten Debian-Tarball von Firefox-20.0 aus Lucid genommen, alles was nicht zu Lucid direkt gehört rausgeworfen und mich dann an dem offiziellen Tarball aus Precise mehr oder weniger orientiert.

Schöne Grüße
Endanwender

So, ich glaube ich mache hier mal doch wieder weiter... ☺

Aktuell versuche ich mich an einem Build der aktuellen Beta von Firefox 23. Soweit so gut und die Beta 1 klappte auch mit wenigen Änderungen erfolgreich. Bei der Beta 2 allerdings ging dann irgendwie gar nichts mehr und jeder Build endete mit der Fehlermeldung:

/usr/include/asm/ptrace.h:5:48: error: linux/linkage.h: No such file or directory

Irgendwie kam mir das merkwürdig vor und wenn ich richtig im Netz recherchiert habe, dann hat der Fehler doch weniger mit Firefox selbst zu tun, oder? Oben genannte Datei wird doch eher durch die libc-dev eingeführt. Als Gegenprobe hatte ich dann auch nochmal den bisher erfolgreich verlaufenden Build von Firefox 22 Version angestossen, und siehe da auch dieser Build quitiert jetzt den Abschluss mit oben genannter Fehlermeldung, sowohl bei mir lokal, als auch beim Build-Service von Canonical. Vor einigen Tage kam auch ein Update der Kernels, samt Header und linux-libc-dev. Irgendwie habe ich die Vermutung dass es genau mit dieser Aktualisierung in Verbindung steht. Ist das möglich oder interpretiere ich eher doch in die falsche Richtung.

Schöne Grüße
Endanwender

Hi Endanwender,

ist das Kernel-Header-Paket installiert, zeigt "dpkg -S linux/linkage.h" eine Ausgabe?

Gruss Lasall

Hallo Lasall!

Du meinst in der Build-Umgebung? Nein nicht so ohne weiteres. Ich hatte testweise auch das Paket linux-headers-generic für den Bauvorgang als Abhängigkeit aufgenommen, aber auch das hilft nicht den vorherigen Zustand wieder herzustellen. Ich für meinethalben bin nun doch etwas ratlos.

Schöne Grüße
Endanwender 😉