+ Das war eine Richtlinien-Entscheidung, nachdem wir den Vortrag »Video-Output« auf der FrOSCon gehalten haben. +
++ Dazu gibt es mehrere Gründe +
++ ...der Grund liegt in der Pflicht zur Bereitstellung der "Quellen". Das zwingt im Zusammenhang mit allgemeinen Inhalten wie Text, Bild und Video zur Auslegung, und dadurch wird die Situation rechtlich zweideutig. Theoretisch wäre das kein Problem, aber praktisch kann es ein Hindernis darstellen für jemanden, der lediglich gestalterischen Content weiterverwenden und umgestalten möchte, also in unserem Fall Texte und Bilder. Daher bieten wir eine Wahlmögichkeite der Creatvice-Commons-By-SA, denn diese verpflichtet nicht zur Bereitstellung eines Quelltextes. +
+ + ++ Einschätzung: ja +
+ + + ++ ABER: das verpflichtet UNS, die CC-By-SA einzuhalten +
+ + ++ Und zwar deshalb, weil es nur einen kompatiblen Pfad gibt von CC-By-SA ⟶ GPL-3. +
++ Deshalb müssen wir die Vereinigungsmenge der Forderungen beider Lizenzen erfüllen, was aber möglich ist.... +
+ + ++ ...hier müssen wir aufpassen. Da die CC-By-SA nicht auf Quellcode abstellt, muß die Attributierungs-Information jeweils auch textuell nahe bei dem jeweiligen Content aufgeführt sein. +
+ + ++ ...das tun wir, unser Git-Repo ist öffentlich und die veröffentlichten Webseiten werden aus Asciidoc generiert. Für Bilder halten wir die bestmögliche Auflösung bereit, bzw. verwenden SVG, wo möglich +
+ + ++ das heißt, mal eben den Spell-Checker laufen lassen, oder den Markup reparieren ist noch kein Beitrag, der eine Autorenschaft konstituiert. +
+ + ++ ABER: jeder relevante Autor eines Textes / Bildes muß im Text selber aufgeführt sein +
+ + ++ Denn ich mußte mir das heute schon wieder zusammensuchen... +
++ Beschluß: wir gehen auf 3.10 +
+ + + ++ Was war denn überhaupt der Sinn der vgsuppression? Welche Aufrufe sollten damit ausgenommen werden? warum brauchen die die Tests??? +
+ + ++ Die »klassischen Hacker« waren seinerzeit unbedingt davon überzeugt, daß wir viel mit Valgrind arbeiten müssen, weil wir ja sonst Probleme mit Memory-Leaks „nie in den Griff bekommen“. Ich dagegen wollte immer ein deterministisches Memory-Management, und hab mich mit diesem Ansatz durchgeführt. Erste Versuche mit Valgrind waren nicht sonderlich hilfreich. Vor allem wegen Dingen wie dem "MPool", der nicht deterministisch ist. Ebenso hat Christian irgendwann einmal einen "Leak-Checker" geschrieben, und wollte den eingebunden haben. Dann kam heraus, daß sein C-Code leakt, aber der C++-Code nicht, weil die smart-Pointer per Konstruktion »wasserdicht« sind. Daraufhin hat Christian schlagartig das Interesse an dem Thema verloren. Und sich auch nie um eine brauchbare Konfiguration der vgsuppression gekümmert. Ich hatte darauf auch keinen Bock, denn das ist eine endlose Knobelei, und wozu? Ich weiß ja daß die smart-pointer nicht leaken. +
+ + ++ searchpath.cpp : replaceMagicLinkerTokens() +
+ + ++ SCons würde nämlich diese $ORIGIN ebenfalls versuchen, zu expandieren +
+ + ++ ...dies dient dazu, Defaults aus dem 'optcache' zu laden +
+ + ++ ...hab heute schon wieder ganzschön lang gebraucht, um mir das zusammenzupuzzeln (und ich kenne SCons und unser Buildsystem) +
+ + ++ Hauptsache, man hat irgendwas total trickreich eingefädelt, so daß man sich später von der linken Tasche in die rechte Tasche spielen kann +
+ + ++ und exakt so machen wir es bereits +
+ + ++ das Config-System ist nur noch pro forma da +
+ + ++ lumiera_get_plugin_path_default() +
+ + ++ Nein! denn unser Buildsystem ist nicht Autotools oder CMake +
+ + ++ das beruht aber auf einer Mystifikation +
+ + ++ ...weil es dadurch zusätzliche Seiteneffekt-Abhängigeiten gibt, die man dem System nicht »ansieht« +
+ + ++ ...das dann auch die üblichen Overlay-Ebenen hat (Paket, System, User) +
+ + ++ Für den normalen Build ist das irrelevant; erst wenn wir das Install-Target aufrufen, passiert da etwas. Und dann sollte das auf Betriebssystem-Ebene geregelt sein (und das erfordert i.d.R. auch Root-Rechte) +
+ + ++ Das ist so eine ganz typische Paketbau-Funktionalität: prüfen ob das Zielverzeichnis existiert, richtige Rechte hat und leer ist — oder eben einige dieser Kriterien grade nicht prüftn +
+ + +- wähle Kompatibiltät genau so, daß Ubuntu-Trusty noch unterstützt wird. + wähle Kompatibiltät genau so, daß Ubuntu-Noble noch unterstützt wird, ansonsten den Level für »Trixie«
+ ...das war ein Beschluß auf dem Entwickler-Meeting im September: auch wenn wir (Benny+ich) jetzt viel Know-How aufgesammelt haben, verschieben wir das Thema »Shader-Programmierung« dann doch noch in die Zukunft, weil es nicht strikt notwendig ist, um die einfachste Form von Playback zu bekommen. Demnach könnten wir sogar mit dem bestehenden XVideo-Code weitermachen (oder eben Legacy GL nehmen, sofern noch Motivation dafür da ist) +
+ ++ ...heißt nämlich, daß man Lumiera derzeit nicht nach /usr/local/ installieren könnte! +
++ Das wenn ein »richtiger« Unix-Hacker mitbekommt, dann haben wir uns ziemlich lächerlich gemacht: „mit Autotools wär das nicht passiert...“ +
+ + ++ Ich würde nie auf die Idee kommen, etwas anders ins System zu installieren, als via DEB-Paket. Und für das Debian-Paketieren brauchen wir ja einen Pfad relativ zum Build-Root (nämlich im debian/lumiera - Unterverzeichnis, denn dort wird der Content für das neue DEB-Paket nach dem Build zusammengestellt....) +
+ + ++ wie viele Build-Systeme beruht auch der SCons-Build darauf, rekursiv definierte Sub-Builds aus Unterverzeichnissen zu aggregieren. Das bedeutet, daß für den eigentlichen Bauvorgang jeweils in das Unterverzeichnis gewechselt wird. Das ist aber problematisch für Aktionen im Build-Tree, und deshalb bietet SCons diese spezielle Konvention mit dem '#'-Präfix, das den Pfad dann relativ zum Build-Root verankert +
+ + ++ Nov.2025 beim Erweitern/Debuggen entdeckt: da stößt das Setup mit der Hilfsfunktion getDirname() an ihre Grenzen. Gilt vermutlich auch für den ConfigData()-Builder. So belassen. Also: besser immer ein Präfix angeben, es ist ja auch kein optionales Argument +
+ + ++ wird veröffentlicht in einem separaten Git-Repo debian/lumiera, ist aber auch in meinem 'ichthyo'-Repository +
+ + ++ die stammt eigentlich aus der Lumiera-Webiste und wurde umgeschrieben in ein eigenständiges HTML.... unbedingt per Diff/Merge aktualisieren vom Website-Content! +
+ + + ++ Dort bin ich bereits vor ½ Jahr durch die ganze Serie von Neuerungen im Debian-Standard gegangen und habe viele Detail-Fragen geklärt +
+ + ++ Soll die Dokumentationsgenerierung überspringen, aber ein leeres Doumentations-Paket bauen +
+ + ++ ...und wenn das problematisch wird, sollte das DEB-Packaging die DEB_BUILD_OPTIONS "terse" unterstützen +
+ + ++ war letztlich eine Sackgasse, +
++ hat aber wichtige Umstände geklärt +
+ + + + ++ Speziell GLib ist bekanntermaßen buggy, wenngliech auch sich das in den letzten Jahren verbessert hat. Aber die Leute ändern und modernisieren auch ständig ... also gibt es nicht wirklich einen »Kompatibilitäts-Level« +
+ + ++ deshalb ist es ja »Referenz-Platform«, was auch bedeutet, wir orientieren uns nach Vorne, und die Referenz-Platform ist eigentlich der Mindest-Level (mit ein klein wenig Wasser unter dem Kiel, wegen Ubuntu) +
+ + ++ ...nur mit dem Unterschied, daß wir hier nun die Aufrufe direkt im debian/rules stehen haben; im Grunde hat uns die "magic" gar nicht viel gebracht, nachdem man sich erst mal damit beschäftigt hat. +
+ + ++ override_dh_auto_clean: (hier zusätzlich optcache und configure-cache weglöschen) +
++ override_dh_auto_build +
++ override_dh_auto_test +
++ override_dh_auto_install +
+ + ++ DEB_SCONS_OPTIONS = \ +
++ BUILDLEVEL=ALPHA \ +
++ DEBUG=True \ +
++ OPTIMIZE=False \ +
++ VALGRIND=False \ +
++ ARCHFLAGS=" -fstack-protector-strong" +
+ + ++ SCons verwendet eine MD5-Summe über den Quellcode und außerdem auch über alle Compiler-Schalter und Environment-Settings +
+ + + ++ sollte daher alle drei Targets mit den gleichen Settings aufrufen +
+ + ++ Folgeproblem: *** Directory path for variable 'INSTALLDIR' does not exist: debian/lumiera +
+ + + ++ prüft und Syntax, aber nicht ob das Filesystem-Element existiert +
+ + + ++ NodeDevel_test : hier werden Checksummen über Datenblöcke gebildet und eine dafür präparierte Render-Pipeline geschickt. +
++ Dieser Test enthält keine concurrency — also deutet ein (nicht reproduzierbarer) Fehler hier auf ein Hardware-Problem hin (den Verdacht hab ich schon länger) +
+ + ++ Unterschied: -fstack-protector-strong +
+ + ++ Buffer clone[50]; +
++ for (uint i=0; i<channels; ++i) +
++ CHECK (not clone[i]->isSane()); +
++ +
++ ist Sane() prüft nur header_.isPlausible() ⟹ das prüft ob ein das Marker-Wort im Header liegt — was durchaus der Fall sein kann, wenn exakt an der gleichen Stelle vorher schon mal ein Buffer-Header lag.... +
+ + ++ ...vermutlich mit dem temporären TestFrame, der beim vorhergehenden Test während der Verifikation erzeugt wird. Dieser dürfte ja in den Bereich fallen, der in dieser Methode vom zweiten Array abgedeckt wird +
+ + ++ alle Verwendungen (nur in diesem Test) brauchen einen sauberen Buffer +
+ + ++ Dieses Konstrukt wird (augenscheinlich, habe dies stichprobenhaft geprüft) nur in diesem einen Test verwendet. Es werden jeweils ein/mehrere Buffer auf den Stack gelegt. In den meisten Fällen wir dann in diesen Buffer etwas generiert. In einigen Testfällen wird vorher geprüft, daß der Buffer keinen validen Testframe enthält, und nachher, daß dies der Fall ist. Die Prüfung vorher scheitert im vorliegenden Problemfall, vermutlich weil im Stack-Speicher exakt an der gleichen Stelle vorher das gleiche Verarbeitungsmuster stattfand +
+ + ++ TestFrame selber generiert in seinem Konstruktor stets eine valide Buffer-Füllung und belegt alle Metadaten. Möglicherweise hatte ich die Idee, den »Buffer« über beliebige Storage legen zu können, um sie dann zu begutachten. Diese Verwendung fand dann aber nicht statt +
+ + ++ das erspart mir das Gewürge, da std::byte kein numerischer Datentyp ist +
+ + ++ hab gesehen daß der Speicher jetzt mit NULL gefüllt wird +
+ + + ++ Seltsam.... +
++ Ich sehe keinerlei generische Platzhalter in meinem File... Allerdings werde ich das demnächst ohnehin umstellen auf das maschinenlesbare Format +
+ + ++ g++ -o target/modules/libtest-vault.so -Wl,--no-undefined -Wl,--as-needed -Wl,-soname=libtest-vault.so -Wl,-rpath=\$ORIGIN/../modules,--enable-new-dtags -shared tests/vault/mem/extent-family-test.os tests/vault/gear/activity-detector-test.os tests/vault/gear/scheduler-usage-test.os tests/vault/gear/test-chain-load-test.os tests/vault/gear/scheduler-commutator-test.os tests/vault/gear/scheduler-activity-test.os tests/vault/gear/scheduler-invocation-test.os tests/vault/gear/work-force-test.os tests/vault/gear/block-flow-test.os tests/vault/gear/scheduler-stress-test.os tests/vault/gear/scheduler-service-test.os tests/vault/gear/scheduler-load-control-test.os tests/vault/gear/special-job-fun-test.os -lm -ldl -lpthread -lrt -lnobugmt -lstdc++fs -lboost_program_options -lgavl target/modules/liblumieravault.so target/modules/liblumieracommon.so target/modules/liblumierasupport.so +
+ + + ++ Da wir ja ein durchaus spezielles Versionsnummernschema haben. Die Fehlermeldung sieht so aus, als würde das als ein RC für eine Version v0 gedeutet +
+ + ++ Für die Installation per DEB-Paket brauchen wir kein allgemeines README, da vor allem die Bau- und Installations-Vorrausetzungen bereits erfüllt sind, und auch die Lizenz anderweitig deklariert wird. Daher sollte hier im README.debian alles für den reinen User Wissenswerte stehen +
+ + ++ /documentation/user/manual.html +
+ + ++ das war eine Scheiß-Arbeit... +
++ und den Output in doc/devel/LumieraHelpLandingPage.html einchecken +
+ + ++ Denn in Zukunft sollt das Buildsystem auch irgendwann mal ein User-Manual generieren und korrekt installieren; diese Platzhalter-Seite markiert mithin bereits den Ort dieser Installation und dient auch als Anker für diese zukünftige Funktionalität +
+ + + ++ ....naja... das ist relativ; wie bei jeder DSL, wenn man mal das Schema verstanden hat, dann ist es konzis und deklarativ, und wenn man das Schema wieder vergessen hat, dann ist es »magisch« +
+ + ++ (gemäß FHS) ⟹ <prefix>/share/doc/<paktename>/ +
+ + ++ Das hier ist ein Buildsystem für ein Projekt von überschaubarem Umfang. Ganz ehrlich, ich erwarte nicht, daß irgendjemand außer mir das SCons mag und pflegt. Also geht es höchstens darum, nach bestehendem Schema die eine oder andere Datei hinzuzufügen. Überdies frage ich mich, wie lange wir bei SCons bleiben können (hoffentlich noch lange, und hoffentlich darf dann nicht ich einen Ersatz programmieren, oder mich mit CMake herumärgern, das bei Weitem nicht so deklarativ ist +
+ + + ++ dann wird subdir = <die letzte Pfadkomponente>, und das ist nicht, was man erwartet, sofern die Directories mehr als eine Ebene tief liegen. Kann ich jetzt nicht so ohne Weiteres ändern, ohne die Hilfsfunktion getDirname() (BuildHelper.py) umzuschreiben. Das ist es mir dann doch nicht wert! +
+ + + ++ Installationsziel: <prefix>/share/doc/lumiera/manual-html/index.html +
+ + + ++ Was aber auch daran liegen könnte, daß XFCE nicht Gnome ist +
+ + ++ all licenses and all copyrights of component parts to the entire combined work. Both are generally accepted by the open source community, as long as it's clear that an effort is being made to identify and comply with the original licenses. +
+ + ++ Derzeit(2025) ist noch überhaupt nicht klar, in welcher Form wir Dokumentation ausliefern; naheliegend wäre es, unser (nicht vorhandenes) User-Manual aus den Asciidoc-Quellen zu bauen und damit als HTML lokal auszuliefern; das funktioniert aber nicht so ohne Weiteres, da die Seiten auf unsere Website abgestellt sind, und daher die volle Struktur vorraussetzen, und im Besonderen einen Webserver. Diesbezüglich fällt mir natürlich sofort das Stichwort »HTML-Help« ein — kann Asciidoc sowas generieren? +
+ + +