Aktuelle Buildfehler bei make image für Kronos_V2

[[MCP]]

Hallo,

Buildsystem aktuelles Debian 11 (amd64)

Beim Image-Bau sind folgende Fehler aufgetreten:

- ni-linux-kernel -> doppelte Definition von YYLTYPE yylloc

Das erste auftreten ist bei Zeile 42 -> /scripts/dtc/dtc-lexer.l
Das zweite auftreten ist bei Zeile 640 -> /scripts/dtc/dtc-lexer.lex.c_shipped

Als Beseitigung hilft die Zeile 640 auf extern YYLTYPE yylloc; zu ändern.

Testweise hatte ich auch mal für HD51 gebaut, dort trat das Fehlerbild für den KERNEL auch auf.

- target-tools.mk -> DJMOUNT baut nicht durch

Beseitigung: Zwei extra Zeilen

@@ -420,6 +420,8 @@ djmount: $(DJMOUNT_DEPENDENCIES) $(DL_DIR)/$(DJMOUNT_SOURCE) | $(TARGET_DIR)
$(call APPLY_PATCHES,$(PKG_PATCHES_DIR))
$(CHDIR)/$(PKG_DIR); \
touch libupnp/config.aux/config.rpath; \
+ sed -i configure.ac -e 's@AM_LANGINFO_CODESET@@'; \
+ autoreconf -fi; \
$(CONFIGURE); \
$(MAKE1); \
$(MAKE1) install DESTDIR=$(TARGET_DIR)

- /package/minicom/minicom.mk -> minicom-2.7.1 lässt sich nicht von http://fossies.org/linux/misc herunterladen

Ausweich: MINICOM_SITE = http://sources.buildroot.net/minicom

Das wars erst einmal für jetzt.

[vanhofen]

Die Tatsache, dass wir (nahezu) täglich Nightlies für kronos_v2 auf dem Server liegen haben, spricht gegen diese Sachen. Ich schaue sie mir dennoch mal an. Danke dafür.

[[MCP]]

Ich bin jetzt seit einer Woche mit basteln und testen beschäftigt gewesen.

Bezüglich YYTYPE yylloc habe ich die Ursache insoweit gefunden,
das es an DEBIAN 11 liegt, genauer an dem jetzt benutzten gcc 10.

Ich verweise am besten auf folgende Liste:

https://lists.linaro.org/pipermail/linu ... 78818.html

Ab Verwendung des gcc 10 poppt dann der Ärger auf.

Das dort vorgeschlagene löschen der Deklaration von YYLTYPE yyylloc
funktioniert für Kernel 3.10.108 aber leider nicht.

Hilfe bringt Fix-coolstream-hd2-yylloc-linux-kernel.patch
der gegen remotes/origin/ni/linux-3.10.108 gemacht ist.

Fix-coolstream-hd2-yylloc-linux-kernel.patch

(440 Bytes) 274-mal heruntergeladen

Bei mir lässt sich damit der Kernel ohne Probleme bauen und funktioniert dann auch.

Für djmount ist bei mir Fix-djmount-build-target-tools.patch zum erfolgreichen Image bauen nötig.

Fix-djmount-build-target-tools.patch

(502 Bytes) 263-mal heruntergeladen

Ich hoffe, ich nerve nicht all zu sehr.

[vanhofen]

Es gibt tatsächlich Dinge, die einem mit der Zeit nerven. Jungs, die konstruktiv mitarbeiten und Patches liefern, gehören definitiv *nicht* dazu.

Zu DJMount: Dazu habe ich letztens einen Patch von Max eingecheckt. https://github.com/neutrino-images/ni-b ... 14b2fda15f
Behebt der dein Build-Problem nicht?

Danke für die Patches.

[[MCP]]

Sorry von mir, habe gerade neu ausgecheckt und lasse alles komplett neu bauen.

Dauert etwa eine Stunde, dann werde ich genaue Rückmeldung geben.

[[MCP]]

So, meine Stunde ist rum

Entwarnung, es baut jetzt ohne Abbrüche durch. Danke.

Ausserdem habe ich die letzten Tage damit zugebracht durch die Commits zu streifen.

Ich habe viele Nick Namen gelesen und dabei gesehen, wie lange manche schon dabei sind.

Das alles in der Freizeit, ohne entsprechende Gegenleistung.
Dafür möchte ich mich hiermit einfach generell bedanken und meinen Respekt äussern.

Ausserdem habe ich in den letzten 7 Tagen vieles im Quellcode gesehen, was mir richtig
gut gefallen hat. Ich habe vieles dazulernen können.

Das einzige was dabei wirklich erschwerend für mich war, ist die fehlende Dokumentation dafür.
Wenn dazu schon Material existiert gut. Ich wäre über Infos nicht abgeneigt.

Heute habe ich endlich gerafft, welche Auswirkungen die CZapitAuditChannelType Deklarationen
real haben.

Dadurch habe ich jetzt eine Idee, wie ich mein Audio-Problem für alte Aufnahmen elegant
gelösst bekomme. Nach erfolgreichen Tests werde ich mich dazu zurückmelden.

Auch ist mir der Zuordnungsfehler in den Stream-Informationen durch libcoolstream für HD2 klar
geworden und will dafür auch eine Lösung finden.
Ist zwar mehr Spielerei aber regt den Geist an, sich weiter zu bilden.
Ich werde dann berichten.

[[MCP]]

Hi,

bei absolut neuem Aufbau der Buildumgebung tritt während

make init

innerhalb von kernel.do_prepare_git (in linux-kernel.mk)
folgende Fehlermeldung auf:

tar: Die folgenden Optionen wurden im Modus zum Erzeugen oder Aktualisieren
von Archiven hinter nicht optionalen Argumenten angegeben.
Diese Optionen sind positionsabhängig und haben nur auf Argumente Einfluss,
die hinter ihnen stehen. Bitte ordnen Sie sie entsprechend an.
tar: --exclude-vcs hat keinen Einfluss

tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler

Ich sehe zwar, das der Buildvorgang dann trotzdem alleine weiter läuft,
habe aber trotzdem das ganze mal nachvollzogen.

Durfte mich dann mit tar und seinen lieben Parametern anfreunden.
Recht lustig was im Netz im laufe der Zeit dazu alles angefragt wurde.

Die Benutzung von Pipes ist ein mächtiges Werkzeug,
will aber auch richtig angewendet werden.

Ich habe selber eine gute Weile daran getüfftelt,
bis es dann ohne Fehler funktioniert hat.

Wichtig ist dort jeder Bindestrich und auch die Punkte !

Meine ausführliches Ergebnis sieht nun so aus:

Code: Alles auswählen

linux-kernel.mk

kernel.do_prepare_git:
        $(MAKE) kernel.do_checkout
        #
        $(REMOVE)/$(KERNEL_DIR)
        $(MKDIR)/$(KERNEL_DIR)
        tar --create -C $(SOURCE_DIR)/$(NI_LINUX_KERNEL) --exclude-vcs -p --file - . | \
        tar --extract -C $(BUILD_DIR)/$(KERNEL_DIR) --file - .
        $(CD) $(BUILD_DIR)

Im Anhang das ganze wieder als Patch.

Die langen Parameter sind dann nur wieder gekürzt.

FIX_tar_error_message_for_make_kernel.do_prepare_git.patch

(636 Bytes) 280-mal heruntergeladen

Viel Spass damit.

[annie]

Hat mein Papa auch mit Debian 11

[[MCP]]

Danke für die Bestätigung.

Ich war mir selber sehr sicher, das das noch nie wie gewünscht funktioniert hat.

Die passenden Kernel-Quellen landen ja trotzdem im build_tmp Ordner.

Es wird nur jedes mal ein Balast von etwa 800 MByte mit bewegt.

Bei mir sind es dadurch jetzt anstatt 1,4 GByte nur noch 567 MByte an Daten,
die bewegt werden müssen und auch Platten Platz belegen.

Nach durchstöbern meiner Daten-Bestände war das im Januar 2020 auch schon so.

Wurde da noch als kernel.do_prepare.git ausgeführt.

Ist in sich für mich auch logisch erklärbar.

Hat beim Image bauen noch nie gestört und deshalb gab es keine Notwendigkeit
das genau zu analysieren.

Zukünftig kann es aber besser laufen, wenn es dann in den Code-Bestand eingepflegt wird.

Ich möchte aber betonen, das ich persöhnlich keine Dringlichkeit für Sofort-Erledigung sehe.

Wir sind ja hier nicht auf der Arbeit, sondern im richtigen Leben. Da darf man langsamer sein.

Gibt genug anderen Stress.

Ist Abteilung Makel, nicht schön, aber Juckt nicht unbedingt.

Der gesunde Weg führt auch zum Ziel.

[[MCP]]

So, weil heute so ein schöner Tag ist, gleich noch weiter.

Ich komme manchmal auf Dumme Gedanken.

Die Mathematik kennt das Prinzip, Fehler pflanzen sich fort.

Übersetzt, wie hoch ist die Wahrscheinlichkeit das der gleiche Fehler mehrfach auftritt?

Kurz, ich war in Arbeitslaune und bin die Dateien im make Ordner von ni-buildsystem durchgegangen.

Mehrere Treffer mit gleichem Fehlerbild.

Bisher bekkant für mich:

Code: Alles auswählen

linux-kernel.mk

    kernel.do_prepare_git

Neu dazu gekommen:

Code: Alles auswählen

target-ffmpeg-coolstream.mk

    ffmpeg

    
target-libs.mk

    openthreads
    
    rtmdump
    
    
target-tools.mk

   streamripper
   
   ofgwrite
   

Als Abstell-Massnahme habe ich das ganze wieder in einen neuen Patch gepackt,

Der beinhaltet auch den obrigen Patch für linux-kernel.mk.

FIX-tar-error-exclude-vcs-ignored.patch

(3.5 KiB) 277-mal heruntergeladen

Wieder der Hinweis, drängelt nicht. Was wird, das wird.

[vanhofen]

Ich hab das vorhin anders gelöst. Danke für deine Tipps. Gesehen hatte ich die Warnung auch, nur eben gewissenhaft ignoriert.
https://github.com/neutrino-images/ni-b ... 9601804ff2

[annie]

ich hatte nur den 1. Patch von oben benutzt .

Hab für Tank und HD51 gebaut mit Debian 11

[[MCP]]

Ich hab das vorhin anders gelöst. Danke für deine Tipps. Gesehen hatte ich die Warnung auch, nur eben gewissenhaft ignoriert.
https://github.com/neutrino-images/ni-b ... 9601804ff2

Ich hätte es mir denken können, das du auf die gleiche Idee kommen musstest.

Den Parameter zu versetzen reicht natürlich auch.

Meine Lösung war an die Dokumentation von tar angelehnt, bezüglich der Reihenfolge der
zu verwendeten Parameter.

Aber das ist eh akademisch und wertlos.

Mir bleibt nur, mich für die sau schnelle Bearbeitung zu bedanken. Das motiviert mich ungemein.

Du hattest nach meiner Überwachung nicht wirklich einen langen Nachtschlaf.

Jetzt ist erst einmal Mittagspause angesagt.

[vanhofen]

Du hattest nach meiner Überwachung nicht wirklich einen langen Nachtschlaf.

OK, Google. Was ist Schlaf?

[[MCP]]

Du hattest nach meiner Überwachung nicht wirklich einen langen Nachtschlaf.

OK, Google. Was ist Schlaf?

Ist die Pause, die das Gehirn braucht, um mit dem Begriff Zeit klar zu kommen.

Ab und zu sind dort Aufräumungsarbeiten im Gange, die helfen das wir nicht ganz am
Rad drehen.

[satbaby]

Defeminisierung Zeit für Festplatte.

[jokel]

habe schon probleme , bei "make init"

[vanhofen]

Beim Verfassen von aussagekräftigen Posts auch.

Wo ist denn das Problem?

[jokel]

crosstool-ng 2 fehler

[vanhofen]

Achso. Na, dann ist ja alles Ok.