13.08.2019, 18:12
Nochmals zum Problem: leider gibt es immer noch Mesh-Haare (z.B. November von Magika im SL) bei denen der Fix keine Wirkung zeigt. Da das Problem ALLE Viewer betrifft, müsste der Fix eigentlich bei Linden Lab erfolgen, aber die haben nie was getan, obwohl das Problem schon sehr lange bekannt ist. Bleibt nur zu hoffen, dass sich endlich was tut, da Bewegung in die Sache gekommen ist.
Wie sich das Firestorm Team über die Freigabe entscheiden wird sei mal dahingestellt. Ich denke aber, dass es keine Freigabe geben wird, bevor das Problem eindeutig identifiziert wurde und besser gelöst ist.
Nun zur Bauanleitung (hust). Leider ist das Ganze nicht so trivial um auf die Schnelle eine funktionierende Anleitung abzugeben. Ich selber habe in der Vergangenheit schon oft Viewer kompiliert und gebildet, so dass ich mit den Zusammenhängen vertraut bin.
Kurz zusammengefasst bin ich wie folgt vorgegangen:
1) Ich habe auf meinem PC Ubuntu 18.04 im Dual Boot. Mein PC verfügt über 16 GB RAM (die Hälfte dürfte auch genügen) und für Linux habe ich eine 120 GB Festplatte frei. Mein Ubuntu ist eher minimal eingerichtet, d.h eine standardmässige Desktopinstallation mit ein paar Tools, die ich im Alltag so brauche und SSH Keys, die ich für meine Serverzugriffe brauche.
Einzig speziell sind bei mir LXD, zfsutils-linux (wird als Filesystem für meine LXD/LXC Container gebraucht), Mono und Git (letzteres ist vermutlich schon mit dabei).
2) Um nun Firestorm zu bilden erstellte ich auf meinem PC zuerst mal mit LXD einen Container mit Ubuntu 18.04 und habe auf diesem SSH eingerichtet, so dass ich ihn aus einem Termialfenster auf meinem PC wie eine externe VM mit ssh und scp ansprechen kann. Darüber hinaus habe ich im Container einen sudo User eingerichtet und auch noch mein Set an Tools für den Alltag installiert. Auf meinen Containern, die ich zum Entwickeln brauche, habe ich in der Regel immer sudo, ssh, vim, mtr-tiny, dnsutils, traceroute, git, gawk, zip, unzip, tmux, und build-essential installiert. Für alles weitere logge ich mich also auf diesem Container ein.
3) Für das weitere Vorggehen habe ich mich an die Links unter https://wiki.firestormviewer.org/#tab-developers gehalten:
Primär habe ich mich dabei unter https://wiki.firestormviewer.org/fs_compiling_firestorm an die aktuellste Anleitung für Debian 9 unter 64-bit Debian 9.x (stretch) - AlexIvy updated 8/18/18 gehalten.
Nachträglich betrachtet wäre es sinnvoller gewesen einen Container mit Debian Stretch (lxc launch images:debian/9 fsdev) zu erstellen, denn es hat sich herausgestellt, dass ich noch einige Probleme mit den Abhängigkeiten hatte.
Da ich aber Debian seit längerer Zeit nicht mehr nutzte fühlte ich mich mit dem mir vertrauten Ubuntu auf der sichereren Seite und habe den Pfad nicht verlassen.
Hilfreich war dann noch ein Blick auf die aktuellste, aber für mich veraltete Doku für Ubuntu 16.04 vom gleichen Autor zu werfen: 64-bit Ubuntu 16.04 (AlexIvy) updated 5/29/19
Mit diesen beiden Anleitungen in Kombination bin ich ganz gut vorangekommmen. Vor allem beim Linken gab es noch die eine oder andere Abhängigkeit, die ich noch nachinstallieren musste und ich musste den Build mehrmals neu starten. Das ganze Prozedere hat so etwa zwei bis drei Stunden gedauert.
Bei den fehlenden Libraries gab es einzelne Komponenten von denen es schwierig war herauszufinden zu welchem Package sie gehören und in einem Fall war es ein Package für die i386 Architektur. Damit hatte ich nicht gerechnet und deshalb etwas Zeit verloren. Google war wieder mal Freund und Helfer.
4) Nachdem alles fertig war habe ich das fertige komprimierte Package mit scp vom Container auf mein Basis-System kopiert und konnte nach dem entpacken gleich mit Testen loslegen. Das .tar.xz File mit dem Package befindet sich nach dem Build direkt im Verzeichnis ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/.
Das erste Mal hatte ich das gesamte Verzeichnis aus ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged rüber kopiert. Das war insofern falsch als dadurch das versteckte Unterverzeichnis bin/.debug mitkopiert wurde, was nahezu 2 GB Daten enthält, die nicht benötigt werden. Ansonsten war aber kein Unterschied spürbar und das Verzeichnis konnte einfach gelöscht werden.
Vielleicht komme ich gelegentlich mal dazu eine vollständige Anleitung für Ubuntu 18.04 zu erstellen, wenn ein Interesse daran besteht.
Nachwort:
Ich bin ein grosser Fan von LXD/LXC Containern. Sie verhalten sich vom Feeling her wie eine VM, sind aber schneller und weniger resourcen-intensiv, da sie immer den Kernel des Hosts teilen. Ist man einmal damit vertraut, so sind sie sehr handlich. Die wichtigsten Befehle sind schnell erlernt und ich finde sie weit weniger kompliziert als etwa Docker Container.
lxc launch ubuntu:1804 fsdev und nach wenigen Sekunden (das erste Mal nach ein paar Minuten) steht ein Container mit einem Ubuntu Server bereit. Mich hat es seinerzeit ca. einen Tag gekostet mich damit vertraut zu machen um soweit zu gehen, dass ich meine Oracle Virtual Box auf einem bei Hetzner gemieteten Server durch LXD ablösen konnte.
Der Vorteil liegt darin, dass ich praktisch jede Linux Distro auf einem Container installieren kann, sofern sie sich noch mit dem aktuellen Kernel verträgt und so von der "Dependency Hell" weitgehend befreit bin, der ich in Entwicklungsprojekten immer wieder begegne.
Und natürlich habe ich auch einen Container mit dem Namen osdev. Darauf ist Mono installiert und Opensimulator, so dass ich auch immer gleich mit der aktuellsten Opensim Version testen kann.
LG Pius
Wie sich das Firestorm Team über die Freigabe entscheiden wird sei mal dahingestellt. Ich denke aber, dass es keine Freigabe geben wird, bevor das Problem eindeutig identifiziert wurde und besser gelöst ist.
Nun zur Bauanleitung (hust). Leider ist das Ganze nicht so trivial um auf die Schnelle eine funktionierende Anleitung abzugeben. Ich selber habe in der Vergangenheit schon oft Viewer kompiliert und gebildet, so dass ich mit den Zusammenhängen vertraut bin.
Kurz zusammengefasst bin ich wie folgt vorgegangen:
1) Ich habe auf meinem PC Ubuntu 18.04 im Dual Boot. Mein PC verfügt über 16 GB RAM (die Hälfte dürfte auch genügen) und für Linux habe ich eine 120 GB Festplatte frei. Mein Ubuntu ist eher minimal eingerichtet, d.h eine standardmässige Desktopinstallation mit ein paar Tools, die ich im Alltag so brauche und SSH Keys, die ich für meine Serverzugriffe brauche.
Einzig speziell sind bei mir LXD, zfsutils-linux (wird als Filesystem für meine LXD/LXC Container gebraucht), Mono und Git (letzteres ist vermutlich schon mit dabei).
2) Um nun Firestorm zu bilden erstellte ich auf meinem PC zuerst mal mit LXD einen Container mit Ubuntu 18.04 und habe auf diesem SSH eingerichtet, so dass ich ihn aus einem Termialfenster auf meinem PC wie eine externe VM mit ssh und scp ansprechen kann. Darüber hinaus habe ich im Container einen sudo User eingerichtet und auch noch mein Set an Tools für den Alltag installiert. Auf meinen Containern, die ich zum Entwickeln brauche, habe ich in der Regel immer sudo, ssh, vim, mtr-tiny, dnsutils, traceroute, git, gawk, zip, unzip, tmux, und build-essential installiert. Für alles weitere logge ich mich also auf diesem Container ein.
3) Für das weitere Vorggehen habe ich mich an die Links unter https://wiki.firestormviewer.org/#tab-developers gehalten:
Primär habe ich mich dabei unter https://wiki.firestormviewer.org/fs_compiling_firestorm an die aktuellste Anleitung für Debian 9 unter 64-bit Debian 9.x (stretch) - AlexIvy updated 8/18/18 gehalten.
Nachträglich betrachtet wäre es sinnvoller gewesen einen Container mit Debian Stretch (lxc launch images:debian/9 fsdev) zu erstellen, denn es hat sich herausgestellt, dass ich noch einige Probleme mit den Abhängigkeiten hatte.
Da ich aber Debian seit längerer Zeit nicht mehr nutzte fühlte ich mich mit dem mir vertrauten Ubuntu auf der sichereren Seite und habe den Pfad nicht verlassen.
Hilfreich war dann noch ein Blick auf die aktuellste, aber für mich veraltete Doku für Ubuntu 16.04 vom gleichen Autor zu werfen: 64-bit Ubuntu 16.04 (AlexIvy) updated 5/29/19
Mit diesen beiden Anleitungen in Kombination bin ich ganz gut vorangekommmen. Vor allem beim Linken gab es noch die eine oder andere Abhängigkeit, die ich noch nachinstallieren musste und ich musste den Build mehrmals neu starten. Das ganze Prozedere hat so etwa zwei bis drei Stunden gedauert.
Bei den fehlenden Libraries gab es einzelne Komponenten von denen es schwierig war herauszufinden zu welchem Package sie gehören und in einem Fall war es ein Package für die i386 Architektur. Damit hatte ich nicht gerechnet und deshalb etwas Zeit verloren. Google war wieder mal Freund und Helfer.
4) Nachdem alles fertig war habe ich das fertige komprimierte Package mit scp vom Container auf mein Basis-System kopiert und konnte nach dem entpacken gleich mit Testen loslegen. Das .tar.xz File mit dem Package befindet sich nach dem Build direkt im Verzeichnis ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/.
Das erste Mal hatte ich das gesamte Verzeichnis aus ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged rüber kopiert. Das war insofern falsch als dadurch das versteckte Unterverzeichnis bin/.debug mitkopiert wurde, was nahezu 2 GB Daten enthält, die nicht benötigt werden. Ansonsten war aber kein Unterschied spürbar und das Verzeichnis konnte einfach gelöscht werden.
Vielleicht komme ich gelegentlich mal dazu eine vollständige Anleitung für Ubuntu 18.04 zu erstellen, wenn ein Interesse daran besteht.
Nachwort:
Ich bin ein grosser Fan von LXD/LXC Containern. Sie verhalten sich vom Feeling her wie eine VM, sind aber schneller und weniger resourcen-intensiv, da sie immer den Kernel des Hosts teilen. Ist man einmal damit vertraut, so sind sie sehr handlich. Die wichtigsten Befehle sind schnell erlernt und ich finde sie weit weniger kompliziert als etwa Docker Container.
lxc launch ubuntu:1804 fsdev und nach wenigen Sekunden (das erste Mal nach ein paar Minuten) steht ein Container mit einem Ubuntu Server bereit. Mich hat es seinerzeit ca. einen Tag gekostet mich damit vertraut zu machen um soweit zu gehen, dass ich meine Oracle Virtual Box auf einem bei Hetzner gemieteten Server durch LXD ablösen konnte.
Der Vorteil liegt darin, dass ich praktisch jede Linux Distro auf einem Container installieren kann, sofern sie sich noch mit dem aktuellen Kernel verträgt und so von der "Dependency Hell" weitgehend befreit bin, der ich in Entwicklungsprojekten immer wieder begegne.
Und natürlich habe ich auch einen Container mit dem Namen osdev. Darauf ist Mono installiert und Opensimulator, so dass ich auch immer gleich mit der aktuellsten Opensim Version testen kann.
LG Pius
