From 8fe2deed95968e0287a2b36ad0f13677bd4d9667 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 6 Apr 2025 18:18:52 +0200 Subject: [PATCH] =?UTF-8?q?Upgrade:=20allow=20for=20build=20on=20=C2=BBTri?= =?UTF-8?q?xie=C2=AB=20with=20GCC-14?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * need to upgrade our custom packages to current standards * switch those packages from CDBS to dh * re-build on Trixie and upgrade the Lumiera DEB-Depot After these (in detail quite expensive) preparations, build with Scons and GCC-14 can be started. Fix some further (basically trivial) compile problems, uncovered by the improved type checking of modern compilers. Note: a tremendous amount of warnings (and depreciations) is also indicated, which will be addressed later.... --- src/lib/hetero-data.hpp | 9 +- src/lib/iter-adapter.hpp | 1 + src/stage/timeline/body-canvas-widget.hpp | 6 +- src/tool/alsa.c | 1 + tests/library/iter-zip-test.cpp | 7 +- wiki/thinkPad.ichthyo.mm | 3460 ++++++++++++++++++++- 6 files changed, 3394 insertions(+), 90 deletions(-) diff --git a/src/lib/hetero-data.hpp b/src/lib/hetero-data.hpp index 92513a280..046faeae3 100644 --- a/src/lib/hetero-data.hpp +++ b/src/lib/hetero-data.hpp @@ -305,14 +305,15 @@ namespace lib { class HeteroData : public HeteroData, meta::NullType>> { - using _Front = HeteroData, meta::NullType>>; + using _FrontBlock = HeteroData, meta::NullType>>; public: - using NewFrame = typename _Front::Frame; - using ChainType = _Front; + using NewFrame = typename _FrontBlock::Frame; + using ChainType = _FrontBlock; + using _FrontBlock::_FrontBlock; template - static _Front + static HeteroData build (INIT&& ...initArgs) { return {initArgs ...}; diff --git a/src/lib/iter-adapter.hpp b/src/lib/iter-adapter.hpp index 7cdf425b0..67155f5cb 100644 --- a/src/lib/iter-adapter.hpp +++ b/src/lib/iter-adapter.hpp @@ -108,6 +108,7 @@ #include "lib/meta/value-type-binding.hpp" #include +#include namespace util { // see lib/util.hpp diff --git a/src/stage/timeline/body-canvas-widget.hpp b/src/stage/timeline/body-canvas-widget.hpp index 3918b3628..7907bf377 100644 --- a/src/stage/timeline/body-canvas-widget.hpp +++ b/src/stage/timeline/body-canvas-widget.hpp @@ -154,6 +154,9 @@ namespace timeline { auto get_vadjustment() { return contentArea_.get_vadjustment(); } auto get_hadjustment() { return contentArea_.get_hadjustment(); } + /** a way to get and possibly (re)compute the current TrackProfile */ + using ProfileGetter = std::function; + protected: /* ==== Interface: CanvasHook ===== */ @@ -169,9 +172,6 @@ namespace timeline { void completeLayout (DisplayEvaluation&) override; private:/* ===== Internals ===== */ - - /** a way to get and possibly (re)compute the current TrackProfile */ - using ProfileGetter = std::function; ProfileGetter getProfile; TimelineCanvas& getCanvas(int yPos); diff --git a/src/tool/alsa.c b/src/tool/alsa.c index 23fb6f944..196a31092 100644 --- a/src/tool/alsa.c +++ b/src/tool/alsa.c @@ -19,6 +19,7 @@ #include "alsa.h" +#include #include static snd_pcm_t* playback_handle = 0; diff --git a/tests/library/iter-zip-test.cpp b/tests/library/iter-zip-test.cpp index 3c58945e1..15696057e 100644 --- a/tests/library/iter-zip-test.cpp +++ b/tests/library/iter-zip-test.cpp @@ -160,10 +160,11 @@ namespace test{ CHECK (t1 == "«tuple»──(42,1.61803,7)"_expect ); // ...while the other one was picked by value => t1 unchanged // function may return references.... - auto refr = [](auto&& v) -> decltype(auto) { return v; }; - int five = 5; + auto refr = [](auto& v) -> decltype(auto) { return v; }; + int five{5}; + int& fiveR{five}; CHECK (TYPE (refr(five)) == "int&"_expect); - CHECK (TYPE (refr(5 )) == "int&"_expect); + CHECK (TYPE (refr(fiveR)) == "int&"_expect); auto t2r = mapEach (t2, refr); CHECK (t2r == "«tuple»──(6,6)"_expect ); // function yields references, which are placed into res-tuple diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 64e980c33..2e5567d4b 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -74867,7 +74867,93 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + +

+ die konkrete Antwort schlägt sich +

+

+ (direkt oder mittelbar) +

+

+ im Event-State nieder +

+ + + + + + + + + + + + +

+ wenn sich die Entscheidungsbasis ändert, +

+

+ würde das Ergebnis u.U. anders ausfallen. +

+ + + + + + + + +

+ sofern sich eine Entscheidungsgrundlage ändert, müssen alle davon abhängigen Entscheidungen re-evaluiert werden und könnten ander ausfallen; ist dies der Fall, so müssen rekursiv alle darauf aufbauenden Schritte überprüft und neu aufgespielt werden. Am Ende kann ein drastisch anderer Zustand resultieren, und dies wäre selbst wieder als Event zu dokumentieren. +

+ + + + + + + +

+ die seinerzeit getroffene Entscheidung ist als Event festgehalten und wird von selbst nicht nochmal überprüft. Es können sich somit weitreichende Diskrepanzen im Event-State festsetzen, welche dem aktuell gültigen Zustand der Konfiguration widersprechen; dies kann zu Entgleisungen, katastrophaler Fehlfunktion und nicht-deterministischem Verhalten führen. +

+ + + + + + + + + + + + + + @@ -82228,7 +82314,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + @@ -84625,7 +84712,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -90830,7 +90917,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -90851,7 +90938,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -90974,7 +91061,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -91118,13 +91205,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + - + @@ -91207,6 +91294,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + @@ -91717,7 +91808,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + @@ -91745,6 +91837,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + @@ -92417,8 +92513,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
Alle Parameter einer processing-function sind in ein einziges Tupel zusammengefaßt, aber typischerweise sind einige technisch, während andere die gestalterischen Steuermöglichkeiten der Operation repräsentieren. Beide Aspekte müssen auf dem gleichen NodeBuilder konfiguriert werden, aber aus verschiedenen Quellen (und vermutlich auch in verschiedenen Schritten)

- - + @@ -92428,8 +92523,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
implementiert auf Basis der partial-function-closure

- - + @@ -106614,8 +106708,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) in einem Einzelfall von Hand nachgezählt...

- - + @@ -109300,7 +109393,12 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + + + + + @@ -109572,7 +109670,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -109584,7 +109682,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)

- + @@ -110133,6 +110231,10 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + @@ -110151,8 +110253,39 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -110350,7 +110483,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -110673,6 +110806,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + @@ -112899,7 +113033,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -150335,7 +150469,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -150536,6 +150670,14 @@ std::cout << tmpl.render({"what", "World"}) << s + + + + + + + + @@ -157154,7 +157296,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo

- also keine "Banner" aus Sternen.
Abhilfe: /*********************//** + also keine "Banner" aus Sternen.
Abhilfe: /*********************//**

@@ -157758,6 +157900,113 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + + + + + + + + +

+ ....das auf dh basiert; dabei ist viel Detailwissen über bestehende Buildsysteme bereits eingebaut +

+ + + + + + + + + + + + + +

+ und wird in Lumiera in das »Debian«-Git publiziert, als unabhängier Branch +

+ + + + + + + + + + + + + + + + + + + + +

+ Ubuntu war hier Debian voraus, und hat Debug-Symbole automatisch paketiert, allerdings dafür ein spzielles Format geschaffen. Debian hat dann später etwas ähnliches getan, allerdings paketiert Debian sie als normales DEB +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ this enforces symbol resolution at build time +

+ + + + + + + @@ -157963,6 +158212,182 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + +

+ Konfiguration, Parametrisierung, Regeln und Defaults sind ein komplexes Thema — und es ist überaus schädlich, wenn sich dieses auf unklare Weise mit der Darlegung im Code vermischt. Der einzige Ausweg aus diesem Dilemma besteht in Klarheit und Grenzziehung: der Code muß die Entscheidungsmöglichkeiten deutlich machen, dann eine konkrete Anfrage stellen und der sich daraus ergebenden Entscheidung Folge leisten.... +

+ + + + + + + +

+ Die klare Trennung von Code und Entscheidungen bringt eine Schattenseite zum Vorschein: Die Beherrschbarkeit und Regelmäßigkeit  des Verhaltens steht in Spannung zum Fluß des Einzelfalles, und dem Wunsch nach Anpassungsfähigkeit. Das ist ein Problem, also nicht lösbar; es ist aber eingrenzbar, indem der Weg im Nachhinein aufgeklärt und modifiziert werden kann.... +

+ + + + + + + +

+ Query and Decision-System sind stateful — +

+

+ insofern gehören »Session« und »Setup« zusammen +

+ + + + + +

+ Entscheidungen fügen sich zusammen und bauen aufeinander auf — daraus entsteht ein Weg in das gegenwärtige Setup, welches seinerseits nahtlos übergeht in den Stand des Projekts, der sich in der »Session« niederschlägt. Für das Bindeglied, das sich hier als Teil einer Architektur abzeichnet, wähle ich den Begriff DecisionSystem. +

+ + + + + + + + + + + + + + + + + + + + + + +

+ Das gehört zur ersten Vision (auf der das Projekt oberflächlich segeln soll): Lumiera soll die Standard-Applikation für anspruchsvollere Medien-Arbeiten sein. Diese Applikation muß in allen major-Distros ohne große Komplikationen mitlaufen können; User installieren es einfach aus dem Paketmanager und können sofort loslegen (nachdem sie noch ein Tutorial gelesen oder angeschaut haben). Es darf hier keinesfalls irgendweilche Einstiegshürden oder Zusatzanforderungen geben. +

+ + + + + + + + + + + + + + + + + + + +

+ keine problematischen Libraries +

+ + + + + +

+ Libraries können in verschiedenster Hinsicht »problematisch« sein +

+
    +
  • + sie können aufgegeben werden und verrotten +
    • +
  • + sie können Spielball kurzfristiger Moden und politischer Spielchen werden +
    • +
  • + sie können kommerziallisiert und dann ausgeschlachtet werden +
    • +
  • + sie können technologisch instabil sein / werden +
    • +
  • + sie können exzessive Abhängigkeiten nach sich ziehen +
    • +
  • + sie können die Entwicklung einer Distribution stören +
    • +
+ + + + + + + +

+ Der durchschnittliche User möchte die geläufigen Medienformate einfach öffnen, lesen und schreiben können. Das ist die Kernkompetenz von FFmpeg; was von FFmpeg geöffnet werden kann, gitl als geläufig.  Auch Youtube setzt auf FFmpeg. Daher ist FFmpeg in jeder Distribution da und es gibt dafür jeweils ein eigenes Sicherheitsteam (weil es naturgemäß erhebliches Angriffspotential bietet). +

+ + + + + + + + + + + +

+ Christian kannte bereits Burkart Pflaum, und hat uns auf dessen Libraries aufmerksam gemacht. Die Libraries sind vorbildlich in iherer Struktur und in dem beschränkten Scope. Wahrscheinlich sind sie problemloser einzubinden als FFmpeg. Aber das Kernproblem bleibt: das ist eine one-Man-Show, und wir werden trotzdem auf FFmpeg nicht verzichten können.... +

+ + + + + + +

+ Also wenn es sich — wider Erwarten — herausstellt, daß FFmpeg die elementaren Grundfunktionalitäten nur unbefriedigend für alle Farbtiefen und Pixelformate bieten kann, dann könnten Gavl und Gmerlin leicht die Lücken füllen, denn sie sind einfach einzubinden. +

+ + + + + + + +

+ GStreamer, MLT, libVLC, MPlayer +

+ + + + + + + + + + + + + + + + + + @@ -157996,9 +158421,12 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + @@ -158418,7 +158846,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -158441,7 +158869,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -159080,8 +159508,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + @@ -159114,12 +159542,384 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + + +

+ Daher hieß das Projekt anfangs auch Gnome-Design-Library, und enthielt verschiedene Zusatzfunktionen, die dann vom Toolbuilder (»Glade«) direkt in den generierten Code integriert wurden. In Vorbereitung der Umstellung auf CSS für GTK-3 hat man bereits einige Jahre vorher in dem Bereich „aufgeräumt“ — und dann blieb nur Funktionalität übrig, die von diversen GTK2-Projekten extern genutzt wurde: die flexiblen Docks +

+ + + + + + + +

+ Und in dem Zusammenhang hat unser damaliger GUI-Entwickler, Joel Holdsworth, diese Lösung mitgebracht. Er war auch im Kontakt mit den Anjuta-Leuten, und hat an der Vorbereitung für einen GTK-3-Port mitgeholfen. +

+ + + + + + + + + + + + + 
gdl no longer has any reverse dependencies in Debian and isn't really
+actively maintained upstream. Please remove gdl from Debian.
+ + + + + + + + + +

+ 2021-09-22 +

+ + + + + + + + + + + + + + + + + +

+ ...und zwar, weil GTK-3 bereits stabilisiert und im Wartungsmodus ist; die Entwickler haben längst kein Interesse mehr daran, während ein Großteil des etablierten Ökosystems noch mit dem Übergang von GTK-2 auf GTK-3 hadert.... +

+ + + + + + + + + + + + + + + + + + + + + + +

+ diese sind "distclean", also autoconf bereits ausgeführt +

+ + + + + + + + + + + + + + + +

+ Also die Paketierung selber nicht ändern (ich hatte die ohnehin von Glibmm abgeschaut, ohne mich in die Details einzuarbeiten) ... somit bleibt dieses Paket auf CDBS +

+ + + + + + + + + + +

+ irgend etwas im Build führt folgendes Kommando aus: +

+

+ echo 7 >debian/compat +

+

+ Daraufhin bricht der Build ab, da nun zwei widersprüchliche Compat-Level angegeben sind +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Im Sinne von Redundanz und Transparenz sollte ich im Lumiera-Git-Repo auf jeden Fall die ganze Master-Historie mit einschließen ... (ka man könnte, aber ich lasse die Historien unverbunden so bestehen wie sie waren, nicht zuletzt auch der signierten Build-Tags wegen) +

+ + + + + + + + + + + + + + + +

+ viele DD betrachten CDBS inzwischen als einen »code smell« — der neue dh-Sequencer hat die Herzen im Sturm erobert.... +

+

+ Als einzige Ausnahme gilt das Haskell-Ökosystem, in dem wirklich wichtige Einrichtungen nur in CDBS gepflegt waren +

+ + + + + + + + + + + + + + + + +

+ ...soweit ich sehen kann sind nämlich alle relevanten Pakte aus dem Gnome-Umfeld auf Meson umgestellt, selbst wenn sie dann doch irgendwie noch auf Autotools delegieren; das sind Komplexitäten die hier unangemessen scheinen, da das Quellpaket ja ein funktionsfähiges Buildsystem hat und debhelper direkt mit Autotools umgehen kann +

+ + + + + + + + + + + + 
override_dh_auto_configure:
+    dh_auto_configure -- --prefix=/opt/rawau
+ + + + + + + + + + +

+ override_dh_autoreconf: +

+

+                dh_autoreconf --as-needed +

+ + + + + + + + + + + + +

+    dh_auto_test +

+

+ make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 +

+

+ make[1]: Entering directory '/pack/gdlmm3-3.7.3' +

+

+ Making check in gdl/gdlmm +

+

+ make[2]: Entering directory '/pack/gdlmm3-3.7.3/gdl/gdlmm' +

+

+ make[2]: Nothing to be done for 'check'. +

+

+ make[2]: Leaving directory '/pack/gdlmm3-3.7.3/gdl/gdlmm' +

+

+ Making check in examples +

+

+ make[2]: Entering directory '/pack/gdlmm3-3.7.3/examples' +

+

+ make  dock +

+

+ make[3]: Entering directory '/pack/gdlmm3-3.7.3/examples' +

+

+ .... +

+ + + + + + + + + + + + +

+ Arguments passed directly to dh_makeshlibs, for a particular package <package> +

+ + + + + + + + + +

+ konkret dienen die Zusatz-Argumente dazu, bestimmte Paket+Versions-Constraints in das Shlibs-File zu bekommen, da bisher für dh_makeshlibs als default galt -VNone — aber ab Standard 11 wurde der Default geändert in -VUpstream-Version — was konkret einen Eintrag erzeugt der Form »Paketname  (>= Paketversion)« +

+ + + + + + + + + + + + + + + + + + + + + + +

+ ...das ist eine generelle Regel: man sollte sich nur um die Kernbelange kümmern, aber nicht versuchen, auf allen möglichen Nebenschauplätzen seine eigenen Akzente zu setzen. Mag ja sein, daß hier xz etwas besser komprimiert, aber ist das nicht ehr ein Thema für die Betreuer des DEB-Paketvormats? +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + @@ -159178,8 +159978,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + @@ -159546,9 +160346,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - + + @@ -159588,7 +160387,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -159602,18 +160401,624 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ streng logisch hat der Compiler recht: ich kann ein non-copyable-Objekt nicht aus einer Build-Funktion erzeugen, weil ja die Rückgabe eine »Kopie« ist. Aber die Sprache C++ garantiert die RVO, und deshalb wird das Objekt zwar im Code der Build-Funktion erzeugt, aber tatsächlich bereits an der endgülrigen Storage-Location am Zielort im aufrufenden Kontext. +

+ + + + + + + + + + + +

+ Es ist nämlich tatsächlich nicht ganz korrekt: +

+
    +
  • + ich habe ein Member-Filed (im TurnoutSystem), das auf den front-end-Typ lautet, nicht auf den technischen Basistyp — also HeteroData<A,B,C>, und nicht HeteroData<Node<StorageFrame, NullType>>  +
    • +
  • + aber die Builder-Funktion mit RVO erzeugt den technischen Basis-Typ +
    • +
  • + das bedeutet: beide sind zwar storage-kompatibel, aber streng genommen muß eine Initialisierung des abgeleiteten Typs von einem Objekt des Basistyps stattfinden, und das kann man drehen und Wenden wie man will, das ist eine Copy-Operation +
    • +
+ + + + + + + +

+ ...und dafür auch den Basis-Konstruktor explizit sichtbar machen +

+ + + + + + + + + + +

+ ...das war ein Punkt, den ich neulich für Yoshimi gelernt habe: gewisse Header sind letzten Endes doch pervasiv vorhanden, und man gewinnt nichts durch ein fragiles Konstrukt mit Forward-Deklaration. Also Augen zu und das Ding fressen +

+ + + + + + + + + + + + + - - - + - - + + + + + + +

+ das heißt, um Generator-Kostrukte an der Aufruf-Stelle ein list(gen) wickeln...
das ist OK, aber oftmals nicht schön — geht es besser? +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ gdl-dock-item.c: In function 'gdl_dock_item_class_init': +

+

+ gdl-dock-item.c:358:44: error: passing argument 1 of 'gdl_dock_object_class_set_is_compound' from incompatible pointer type [-Wincompatible-pointer-types] +

+

+   358 |     gdl_dock_object_class_set_is_compound (object_class, FALSE); +

+

+       |                                            ^~~~~~~~~~~~ +

+

+       |                                            | +

+

+       |                                            GObjectClass * {aka struct _GObjectClass *} +

+

+ In file included from gdl-dock.h:26, +

+

+                  from gdl-dock-item.c:38: +

+

+ ../gdl/gdl-dock-object.h:354:74: note: expected 'GdlDockObjectClass *' {aka 'struct _GdlDockObjectClass *'} but argument is of type 'GObjectClass *' {aka 'struct _GObjectClass *'} +

+

+   354 | void          gdl_dock_object_class_set_is_compound (GdlDockObjectClass *object_class, +

+

+       |                                                      ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~ +

+ + + + + + + + + + + + + + +

+ gdl-dock-item.c: In function 'gdl_dock_item_set_property': +

+

+ gdl-dock-item.c:747:36: error: initialization of 'GObject *' {aka 'struct _GObject *'} from incompatible pointer type ' +

+

+  *' {aka 'struct _GtkWidget *'} [-Wincompatible-pointer-types] +

+

+   747 |                 GObject * parent = gtk_widget_get_parent (GTK_WIDGET (item)); +

+

+       |                                    ^~~~~~~~~~~~~~~~~~~~~ +

+ + + + + + + + + + + + + + +

+ gdl-dock-bar.c: In function 'gdl_dock_bar_set_master': +

+

+ gdl-dock-item.c: In function 'gdl_dock_item_realize': +

+

+ gdl-dock-bar.c:428:31: error: assignment to 'GdlDockMaster *' {aka 'struct _GdlDockMaster *'} from incompatible pointer type 'GObject *' {aka 'struct _GObject *'} [-Wincompatible-pointer-types] +

+

+   428 |         dockbar->priv->master = g_object_ref (master); +

+

+       |                               ^ +

+ + + + + + + + + + +

+ und dann wird ein GdlDockMaster* darauf gesetzt mit Refcount +

+ + + + + +

+ und zwar als Feld dockbar->priv->master +

+ + + + + + + + + + + + + + + +

+ gdl-dock-layout.c: In function 'gdl_dock_layout_set_master': +

+

+ gdl-dock-layout.c:623:30: error: assignment to 'GdlDockMaster *' {aka 'struct _GdlDockMaster *'} from incompatible pointer type 'GObject *' {aka 'struct _GObject *'} [-Wincompatible-pointer-types] +

+

+   623 |         layout->priv->master = g_object_ref (master); +

+

+       |                              ^ +

+ + + + + + + + + + + + + + + + + + + +

+ Es ist halt C, und früher war mal der Kontrakt, daß einen C nicht nervt wenn man eh weiß, wohin ein Pointer zeigt. Aber die Zeiten ändern sich; jetzt wird sogar C penibel, und das führt dann dazu, daß man jede Menge herumcasten muß, weil C keine Subtypen-Relation kennt. Die angezeigten Fehler passen allesamt auf dieses Muster; ein kurzer Blick in den Code genügt, und man sieht, daß das gleiche Objekt gemeint ist +

+ + + + + + + +

+ diese Deprecations werden alle zuschlagen, wenn man auf GTK-4 migrieren möchte. Vor allem das Wegfallen der Stock-Icons wird vmtl. einige Reorganisation nach sich ziehen.... +

+ + + + + + + +

+ (seufz). Ob es dann doch ein Problem gibt, sieht man bei diesem GTK-Zeug leider erst zur Laufzeit; die angezeigten deprecations allerdings betreffen lediglich einige Zugriffe auf die private-Properties eines Objekts (dafür gibt es m.W. jetzt einen anderen Zugang), sowie den Wegfall des »Stock-Icon«-systems +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Anfangs waren wir von der Vorstellung ausgegengen, daß Lumiera zumindest ein elementares Raw-Video-Processing machen wird, und sich dabei an der Klassifikation und den Funktionen von Gavl orientieren sollte, also dessen »Domain Ontology«. +

+

+ Inzwischen haben wir eine Architektur, die komplett »Library-agnostic« ist — jedwedes Processing wird an eine LIbrary weitergereicht. In der Basis-Ausstattung wird es sich bei dieser Library sehr wahrscheinlich um FFmpeg handeln, nicht um Gavl und Gmerlin. So schade das ist. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ in der dependency-Liste steht es korrekt drinnen +

+ + + + + @@ -159683,7 +161088,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo

- env.GuiResource(f) for f in env.Glob('stage/*.css') + env.GuiResource(f) for f in env.Glob('stage/*.css')

@@ -159828,8 +161233,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + @@ -160383,7 +161788,23 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + + + +

+ ...mit etwas Hilfe von mir; ich war in der Zeit in Bernbach, dort haben wir dann mal einen Vormittag lang zusammen gehackt und den Build wieder weitgehend flott bekommen (bis auf den Scons-BuilderDoxygen) +

+ + + + + + + @@ -160485,9 +161906,18 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + - + + + + + + + + @@ -160498,7 +161928,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -160570,7 +162000,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -160594,7 +162024,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -160608,7 +162038,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -160618,7 +162048,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -160628,22 +162058,31 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - - - - - - + +

- Referenz: Debian/Jessie (stable) : i386 and x86_64 + Wichtig: hier nur was wirklich gebaut ist und funktioniert!

- + + + + + + + + + + + + + + + + @@ -160657,11 +162096,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + - + @@ -160715,10 +162154,10 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + - + @@ -160776,31 +162215,226 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + - + + + + + + + + + + + + + + + + + + +

- Wichtig: hier nur was wirklich gebaut ist und funktioniert! + As of _1/2011_ (0.pre.01):: +

+

+ the project has created and documented a fairly consistent design, +

+

+ partially coded up -- starting from the technical foundations and working up. +

+

+ The code base is approaching 65k LOC. Roughly half of this is test code. +

+

+ The Application can be installed and started to bring up a GTK GUI framework, +

+

+ but the GUI is very preliminary and not connected to core functionality. +

+

+ The video processing pipeline exists only in the blueprints.

+ + - - - - + + + + +

+ As of _10/2013_ (0.pre.02):: +

+

+ the data models have been elaborated and some significant parts of the session +

+

+ are finished. Work has continued with time handling, a draft of the output +

+

+ connection framework, a draft of the player subsystem and interfaces to the +

+

+ engine and processing network. Unfortunately there was a considerable slowdown +

+

+ and decrease in team size, yet still the code base is growing towards 90k LOC. +

+

+ No tangible progress regarding the GUI and the backend. +

+ + + + + + + + + + +

+ As of _11/2015_ (0.pre.03):: +

+

+ a lot of long standing maintennance work has been done. The Project switched +

+

+ to C++11 and in the end even to C++14 and Debian/Jessie as reference platform, +

+

+ followed by clean-up of now obsolete workarounds. On the GUI side, we largely +

+

+ made the transition to GTK-3, which lead to rework of our timeline widget, not +

+

+ finished yet. This work also spured an effort the connection and communication +

+

+ between Proc and the UI, which is expected to be asynchroneous. Due to the +

+

+ limited developer resources, work on the Engine and Player part is stalled. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
debuild -S -sd --sign-key=11FDF5D2DBD7BBD7F4D9D9C42CF2539262382557
+ + + + + + + + + + +
    +
  • + Über die Launchpad-Oberfläche, dort den Abschnitt mit den Keys anklicken. +
    • +
  • + auf der nächsten Seite gibt man den Fingerprint ein; der Pub-Key wird dann von Keyserver.ubuntu.com geholt +
    • +
  • + Launchpad verschlüsselt eine Token-Nachricht mit diesem Key und schickt ihn an die markierte eMail-Adresse +
    • +
  • + diese Nachricht entschlüsseln und den Token-Link im Browser öffnen ⟹ Key ist verifiziert +
    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + @@ -160834,11 +162468,1676 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + - + + + + + + + +

+ hat sich durch den Umzug auf Gitea geändert +

+ + + + + + + + + + + + + + + + + + + + + + + + + +

+ den hatte ich früher einfach auf den DEB-Branch genommen; jetzt sauber als Patch repräsentieren +

+ + + + + + + +

+ commit 0cb862810701e1b28a443917e02c6c604c469967 +

+

+ Author: Christian Thaeter <ct@pipapo.org> +

+

+ Date:   Tue Apr 5 23:58:15 2011 +0200 +

+

+ +

+

+     Fix: missing NOBUG_USE_PTHREAD conditional +

+ + + + + + + +

+ commit d2fac4617da8cab64709e7fc7e229af181ae82db +

+

+ Author: Christian Thaeter <ct@pipapo.org> +

+

+ Date:   Thu May 26 02:00:13 2011 +0200 +

+

+ +

+

+     remove one final newline from a log message +

+

+     +

+

+     Normally NoBug messages should not end in a newline, but in case NoBug +

+

+     hooks up other logging functions it is not completely avoidable that +

+

+     the log messages there have trailing newline characters. +

+ + + + + + + +

+ commit 661f654b8660eac4bc77f32e4047366c5e2a9770 +

+

+ Author: Christian Thaeter <ct@pipapo.org> +

+

+ Date:   Thu May 26 02:32:37 2011 +0200 +

+

+ +

+

+     export nobug_log_va_ and macros defining limits for log lines +

+ + + + + + + +

+ commit 9a609a3c36a5a6af3b0d6317c03f9edf044cf4ff +

+

+ Author: Christian Thaeter <ct@pipapo.org> +

+

+ Date:   Mon Jun 20 14:45:16 2011 +0200 +

+

+ +

+

+     FIX: whitespace formatting in logging messages +

+ + + + + + + + + + + +

+ commit 9ba2e948a7c95e28d156823174bdca187db679f9 (lumi/fix_c11, fix) +

+

+ Author: Hermann Vosseler <deb@ichthyostega.de> +

+

+ Date:   Mon Mar 17 02:12:37 2014 +0100 +

+

+ +

+

+     FIX: macro string concatenation for C++11 compliance +

+

+     +

+

+     Since C++11 supports user defined string literals, +

+

+     there was the need to clarify string tokenisation +

+

+     in macro expansion. +

+

+     +

+

+     For NoBug, unfortunately this means that +

+

+     +

+

+     ""__VA_ARGS__ +

+

+     +

+

+     is no longer treated as two tokens, but as a single token +

+

+     starting a user defined string literal. The fix is simple +

+

+     to insert a whitespace to clarify we want this parsed as +

+

+     two tokens as previously. +

+

+     +

+

+     http://stackoverflow.com/questions/11909806/g-4-7-evaluates-operator-as-sibling-to-macro-expansion +

+ + + + + + + + + + + + + + + + + + 10.2 + +

+ Libtool .la files should not be installed for public libraries. If they’re required (for libltdl, for instance), the dependency_libs  setting should be emptied. Library packages historically including .la  files must continue to include them (with dependency_libs emptied) until all libraries that depend on that library have removed or emptied their .la files. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Im Copyright/Lizenz muß nur aufgeführt sein, was für die Distribution in Debian relevant ist. Autogenerierte Build-Skripte werden nur während dem Paketbau erzeugt und sind nicht Bestandteil der Distribution. Steht so im Policy-Manual +

+ + + + + + + + + + +

+ ...entweder direkt im LIcense: - Feld, oder unten, in einem Sammelfeld für diese Lizenz. +

+

+ Hierbei versteht man unter »grant« die wörtliche textuelle Formulierung aus der Upstream-Distribution oder einem konkreten zentralen Quelltext, mit einer rechtlich bindenden Aussage die den Quelltext unter eine Lizenz stellt. („This code is Free Software, and can be .... under the terms and conditions....“). Der volle Text der Lizenz muß nur folgen, wenn es sich um eine spezielle LIzenz handelt, die nicht schon in der Debian-Distro mit ausgeliefert wird +

+ + + + + + + +

+ Christian war lediglich schlampig und deshalb gibt es viele Files mit fehlender oder nur partieller Info. Aber ich sehe keine abweichende Lizenz-Statements +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ statt autoconf, automake, libtool +

+ + + + + + + + + + + + + + + + + + + + + + + + +

+ das ist nämlich der alte Standard bevor dieses Feld eingeführt wurde; dieser Fall gilt, falls ein Teil des Build-prozesses Root-Credentials braucht. Wenn das nicht der Fall ist, soll Rules-Requires-Root: no gesetzt werden +

+ + + + + + + +

+ ...denn fakeroot wird inzwischen per Default verwendet; das Paket muß keine Systemdateien anfassen, nur Dateien in einem lokalen Buildverzeichnis erstellen; die Permissions(root) setzt später der Installer +

+ + + + + + + + + + + + + + + + + + + +

+ das Paket ist nicht darauf eingerichtet (obwohl es vermutlich funktionieren würde mit Multiarch: same für das Library-Paket); mir ist nicht klar wie das nobug-dev-Paket dann deklariert wird (Multiarch: foreign? aber was ist dann mit den statischen Libs). Das ganze Kapitel im Debian-Manual ist komplex und sieht ehr nach Work-in-Progress aus; und ich müßte wahrscheinlich den Aufbau der Pakete reorganisieren, und dann auch testen.... +

+

+ +

+

+ Bei aller Liebe — dafür erscheint mir der Nutzen doch zu peripher (YAGNI) +

+ + + + + + + + + + + + + + + +

+ dh_makeshlibs is a debhelper program that automatically scans for shared libraries, and generates a shlibs file for the libraries it finds. +

+

+ It will also ensure that ldconfig is invoked during install and removal when it finds shared libraries. Since debhelper 9.20151004, this is done via a dpkg trigger. In older versions of debhelper, dh_makeshlibs would generate a maintainer script for this purpose. +

+ + + + + + + +

+ # Triggers added by dh_makeshlibs/13.24.1 +

+

+ activate-noawait ldconfig +

+ + + + + + + + + + + + +

+ override_dh_<command>: +

+

+     dh_command +

+

+     make something-else +

+ + + + + + + + + + +

+ execute_after_dh_<command>: +

+

+     make something-else +

+ + + + + + + + + + + +

+ Im debmake-autogenerierten nobug-Package... +

+

+    dh_testdir +

+

+    dh_update_autotools_config +

+

+    dh_autoreconf +

+

+    dh_auto_configure +

+

+    dh_auto_build +

+

+    dh_auto_test +

+

+    create-stamp debian/debhelper-build-stamp +

+

+    dh_testroot +

+

+    dh_prep +

+

+    dh_installdirs +

+

+    dh_auto_install --destdir=debian/nobug/ +

+

+    dh_install +

+

+    dh_installdocs +

+

+    dh_installchangelogs +

+

+    dh_installexamples +

+

+    dh_installman +

+

+    dh_installcatalogs +

+

+    dh_installcron +

+

+    dh_installdebconf +

+

+    dh_installemacsen +

+

+    dh_installifupdown +

+

+    dh_installinfo +

+

+    dh_installinit +

+

+    dh_installtmpfiles +

+

+    dh_installsystemd +

+

+    dh_installsystemduser +

+

+    dh_installmenu +

+

+    dh_installmime +

+

+    dh_installmodules +

+

+    dh_installlogcheck +

+

+    dh_installlogrotate +

+

+    dh_installpam +

+

+    dh_installppp +

+

+    dh_installudev +

+

+    dh_installgsettings +

+

+    dh_installinitramfs +

+

+    dh_installalternatives +

+

+    dh_bugfiles +

+

+    dh_ucf +

+

+    dh_lintian +

+

+    dh_icons +

+

+    dh_perl +

+

+    dh_usrlocal +

+

+    dh_link +

+

+    dh_installwm +

+

+    dh_installxfonts +

+

+    dh_strip_nondeterminism +

+

+    dh_compress +

+

+    dh_fixperms +

+

+    dh_missing +

+

+    dh_dwz -a +

+

+    dh_strip -a +

+

+    dh_makeshlibs -a +

+

+    dh_shlibdeps -a +

+

+    dh_installdeb +

+

+    dh_gencontrol +

+

+    dh_md5sums +

+

+    dh_builddeb +

+ + + + + + + +

+ erzeugt eine Analyse der Hook-  und override-Targets, die dh sehen wird +

+ + + + + + + + + + + + + +

+ Hiermit ist das Git-Repo gemeint, in dem die Debianisierung verfügbar ist, nicht upstream; (in unserem Fall ist da aber auch Upstream mit in der Historie) +

+ + + + + + + + + + +

+ das ist eine non-standard GNU-Extension (wobei size = 1byte angenommen wird). +

+

+ Das hier ist eine aufgegebene Codebasis von einem »old-styler« — Umerziehung sinnlos +

+ + + + + + + + +

+ wegen git-buildpackage bauen wir nicht im Arbeitsverzeichnis, aus dem der Build startet; brauche also eine portable und saubere Lösung, um den Build für das Manual zu starten +

+ + + + + + + + +

+ Autoconf gibt zwar eine Warnung aus, macht es aber trotzdem +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ...da Ubuntu nur ein Nebenschauplatz ist; für Ubuntu gäbe es Launchpad und die PPAs (und ich kenne mich mit dieser Infrastruktur aus) — da *.ddeb die Ubuntu-spezifische Lösung für Debug-Pakete ist, könnte man dorthin ausweichen... +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Anmerkung +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
  • + git clone in ein Unterverzeichnis vom Paketverzeichnis +
    • +
  • + Paketverzeichnis in den Container gemounted
    + + 
    podman run -v /Werk/Gang/pack:/pack -it ichthyo/pack-debian-trixie-20250317
    +
    • +
  • + im Container.... +
    • +
      +
    • + (ggfs dort equivs installieren) +
      • +
    • + cd /pack +
      • +
    • + mk-build-dep --install --remove +
      • +
    • + gbp buildpackage --git-tag +
      • +
    +
+ + + + + + + +

+ Vorbereitung: +

+

+ ./build-pack-dock debian:trixie-2025#### +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Dieses Release ist nur notwendig, um auch auf neueren Plattformen ein NoBug-Paket bereitzustellen; ich repräsentiere es lediglich als eine neue Debian-Version zum Release 2008.1 +

+ + + + + + + + +

+ Christian hatte 2008 ... 2011 noch mit einigen Aufräum-Arbeiten und Dokumentation begonnen und dabei auch ein paar Bugs gefixt; 2017 gab es nochmal zwei Commits zur Dokumentation. Es ist aber offensichtlich, daß Christian das Interesse an NoBug (und generell C) verloren hat; er hat jetzt eine NoBug-Variante für Rust. +

+

+ +

+

+ Ich habe lediglich diejenigen Changesets identifiziert, die nach meiner Einschätzung Bugs fixen. Die Anpassungen zum FNV-Hash nehme ich nicht mit (da wird eine 32-bit-Variante eingeführt), und auch reine Dokumentations-Ergänzungen lasse ich weg, da es sich fast nur um TODOs handelt +

+ + + + + + + + + + + + + + + +

+ vielmehr mache ich nun den *.orig-Tarball sauber und liefere alle nachträglichen Fixes als quilt-Patches aus +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
  • + git clone in ein Unterverzeichnis vom Paketverzeichnis +
    • +
  • + Paketverzeichnis in den Docker gemounted
    + + 
    docker run -v /Werk/Gang/pack:/pack -it ichthyo/pack-debian-buster-20230919
    +
    • +
  • + (ggfs dorts equivs installieren) +
    • +
  • + mk-build-dep --install --remove +
    • +
  • + gbp buildpackage im Docker +
    • +
+ + + + + + + +

+ Vorbereitung: +

+

+ ./build-pack-dock debian:trixie-2025#### +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Historien sowohl für Upstream, alsauch für das DEB-Paket finden sich zum Glück noch als archivierte Git-Repos; das letzte Upstream-Release 3.40 war August 2021, das Debian-Pakete wurde bis Juli 2024 weitergeführt. Die Debian-Historie reicht zurück bis September 2008, wobei anfangs nur das debian-Unterverzeichnis eingecheckt wurde, bis zur Umstellung auf git-buildpackage Dezember 2017, mit Version 3.26. Ab dieser Stelle ist die Debian-Git-Historie über einen upstream-Zwischenbranch regelmäßig mit der Upstream-Git-Historie verbunden (das freut mich; auch andere Leute sind auf die gleiche Idee gekommen) +

+ + + + + + + + + +

+ ...und zwar war der Grund, daß in den vorausgegangenen Jahren unser GUI-Entwickler Joel Holdsworth einige Verbesserungen und Fixes gemacht hatte, die zunächst upstream nicht übernommen wurden (man war damals überwiegend mit dem Port auf GTK-3 beschäftigt). Später, mit Lumiera's Umstellung auf GTK-3 konnten wir auf das offizielle Paket schwenken, in das Joel's Fixes inzwischen eingeflossen waren. +

+ + + + + + + + +

+ markiere die Historien-Übernahme für Lumiera +

+

+ mit einem separaten Merge-Commit (JETZT) +

+

+ — verbindet die Debian-Linien — +

+ + + + + + + + + + + + + + + + +

+ in einem Seitenzweig 2021 +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
  • + git clone in ein Unterverzeichnis vom Paketverzeichnis +
    • +
  • + Paketverzeichnis in den Container gemounted
    + + 
    podman run -v /Werk/Gang/pack:/pack -it ichthyo/pack-debian-trixie-20250317
    +
    • +
  • + im Container.... +
    • +
      +
    • + (ggfs dort equivs installieren) +
      • +
    • + cd /pack +
      • +
    • + mk-build-dep --install --remove +
      • +
    • + gbp buildpackage --git-tag +
      • +
    +
+ + + + + + + +

+ Vorbereitung: +

+

+ ./build-pack-dock debian:trixie-2025#### +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Die GDLmm-Bindings haben es nie geschafft, in Debian aufgenommen zu werden; sie sind aber in anderen Linux-Distros paketiert, und irgendwann in das GNOME-Archiv überführt worden. +

+

+ +

+

+ Seinerzeit habe ich nur irgendwo publizierte Tarballs in eine kurze Historie eingecheckt, aber wie sich nun herausstellt, war das praktisch vollständig; auch habe ich bereits das letzte jemals publizierte Release genommen, um darauf ein DEB-Paket neu aufzubauen. Dabei habe ich mich an das Glibmm-Paket als Vorlage gehalten (und nicht viel Aufwand investiert). Insofern sollte dieses Paket lediglich minimal modernisiert werden, so daß es auf aktuellen Debian-Distros noch akzeptabel ist. Ich bleibe bei CDBS +

+ + + + + + + + + +

+ Die Historie reicht zurück bis 2009 und markiert 5 Releases, das erste davon noch für GTK-2. +

+

+ Zur Dokumentation nehme ich die Upstream-Historie unverknüpft mit in das Lumiera-Repo auf; aber mein DEB-Paket bleibt auf einem »release«-Branch, der den Inhalt der Tarballs dokumentiert +

+ + + + + + + + + + + + + + + + + + + + + + + + +

+ läßt sich jenseits von Standard 10 (post Buster) praktisch nicht mehr verwenden, da viel einfach nicht mehr nachgeführt wurde; CDBS ist inzwischen weitgehend aufgegeben.... +

+ + + + + + + + + + + + + + +

+ ebenfalls von mir lokal gepflegt +

+ + + + + + + + + + + + +

+ commit 4a5affc3f7db1490568fd2aeb199d8411e7ea5a5 +

+

+ Author: Christian Hergert <christian@hergert.me> +

+

+ Date:   Fri Oct 16 18:45:45 2015 -0700 +

+

+ +

+

+     build-fix for recent gtkmm +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
    +
  • + git clone in ein Unterverzeichnis vom Paketverzeichnis +
    • +
  • + Paketverzeichnis in den Container gemounted
    + + 
    podman run -v /Werk/Gang/pack:/pack -it ichthyo/pack-debian-trixie-20250317
    +
    • +
  • + im Container.... +
    • +
      +
    • + (ggfs dort equivs installieren) +
      • +
    • + cd /pack +
      • +
    • + mk-build-dep --install --remove +
      • +
    • + gbp buildpackage --git-tag +
      • +
    +
+ + + + + + + +

+ Vorbereitung: +

+

+ ./build-pack-dock debian:trixie-2025#### +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -160855,7 +164154,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -160871,6 +164170,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo +