fischertechnik community forum

richard.kunze hat geschrieben:Weiss ich auch nicht - und ich weiß auch nicht, ob das relevant ist.

Yupp, siehe mein letztes post, war absolut relevant!

richard.kunze hat geschrieben:Welcher Build ist das denn eigentlich? Noch der von host-efl, oder schon der für das Target?

Das war noch der Host...

jetzt hat er 13 weitere Pakete gebaut, bis er zur efl für das Target kam. Und rate mal, was jetzt passiert ist: Der nächste nicht gesetzte Pfad, der zu einem Abbruch des Builds führt. Ich werde ihn mit der Holzhammer-Methode setzen und den Build wieder anschubsen...

so, jetzt crasht der build bei
ELUA lib/ecore_audio/ecore_audio_out_sndfile.eo.lua
...100%CPU-Load, keine Ausgaben mehr...

sagt mir, daß er für's target noch nicht gebaut hat, das paßt ja zu obigem Problem.

Ich habe die beiden config.log-files mal hier untergebracht:
Der Build hängt immer noch wie oben beschrieben, jetzt gibt's ein ctrl-c und dann gute Nacht... Eines Tages wird es einen Release der 0.9.3 geben mit fertigen binaries...

Erstmal trotzdem DANKE FÜR DIE TIPS

Peter

PHabermehl hat geschrieben: Ich habe die beiden config.log-files mal hier untergebracht: https://c.gmx.net/@329521639811188859/j ... F-6Jaryhvg

Ich hab Dein host-config.log mal mit meiner Konfiguration verglichen und dabei (neben den erwarteten Unterschieden bei allen möglichen Pfaden) im Wesentlichen zwei Unterschiede gefunden:

• Der Host-GCC ist bei Dir Version 4.8.3, bei mir 4.9.2
• Bei Dir wird "openjpeg.h" gefunden (die Logeinträge ab "configure:42167"), bei mir nicht.

Beides könnte die Ursache des Problems sein, rein instinktiv würde ich aber auf das openjpeg.h tippen.

Schau von daher am besten erst mal, welches Paket das auf Deinem System installiert hat, und ob Du das wirklich brauchst - und wenn nicht, dann deinstallier mal das Paket und bau EFL nochmal komplett neu (also output/build/host-efl-1.17.2 und output/build/efl-1.17.2 löschen).

Wenn das nicht hilft: Schau mal, ob Du für SuSE 42.1 irgendwo auch einen moderneren GCC herbekommst und probier es damit nochmal.

So, jetzt sitz ich hier mit aus den Höhlen gesprungenen Augen, knallrotem Kopf und Schnappatmung vor dem Raspberry...
Leider kann ich Euch kein Bild davon schicken, denn meinen "richtigen" Rechner hat's zersemmelt..

Und das kam so:

Nachdem das Deinstallieren von openjpeg incl. sources keine Verbesserung brachte, wollte ich den gcc von 4.8 auf 5 hochziehen - 4.9 wurde im Standard-Repo nicht angeboten.
Also fix ein paar Klicks im Paketmanager und ab dafür... Am Ende der Installation hat's den X-Server gekillt - schwarzer Bildschirm - Konsolen-Login...

Staunen, failsafe-reboot, bleibt auch beim graphical target hängen...

Was ist denn das für ein Sch..., daß der xserver an einer bestimmten gcc-version hängt und beim Ändern der SW-Pakete nicht mal ne Warnung kommt?

GNARF!

Dann mach dir wenn du den gcc downgradet hast doch ne VM.
Macht nicht so viel schaden
Aber das X weg ist..
Hast du auch schon xdiagnose versucht?

Moin,
Ich habe bei der Gelegenheit ein update auf die 42.2 gemacht, was bis auf kleine Probleme mit dem Bootloader auch prima geklappt hat.
Ich bin mir noch nicht sicher, was ich als nächstes probiere. VM oder doch ein Laptop mit einem schlanken Debian (das wäre mir lieber)....
.

So, hab bei ebay nen E7400 2x2.8GHz Desktoprechner geschossen, der kommt als debian-buildserver unter den Schreibtisch und wird per vnc ferngesteuert.... Das letzte Wort ist noch nicht gesprochen...

Das sah ich eben im VNCViewer
Ein durchgelaufener fw-build...

PHabermehl hat geschrieben:

fwbuild.jpg

Das sah ich eben im VNCViewer
Ein durchgelaufener fw-build...

Sieht auf den ersten Blick sauber aus.

...und der TXT ist damit gerade durchgestartet.

Im übrigen hatte ich auch noch Probleme, weil ein python-Paket für https-Zugriff fehlte, das war aber lösbar.

Gruß
Peter

Das ist seit neustem dabei. Das Problem lag da nicht am python sondern am linux.

Raphael

PHabermehl hat geschrieben: Im übrigen hatte ich auch noch Probleme, weil ein python-Paket für https-Zugriff fehlte, das war aber lösbar.

Das Problem habe ich gerade auch. python-openssl ist vorhanden, python-ncrypt hilft auch nicht. Was fehlte bei Dir denn?

probier's mal mit httplib2, evtl für 2.7 und 3.5 installieren...

Ansonsten hab ich so lange alles, was ssl heißt, nachinstalliert, bis es paßt. Irgendwo stand, daß man die -devel Pakete mitinstallieren sollt...

Ich hab aber jeweils mehrere Änderungen auf einmal gemacht, so daß ich Dir nicht exakt sagen kann, was zum Erfolg geführt hat. die httplib war aber definitiv ein missing link...

Gruß
Peter

edit: python-jsonschema hab ich auch irgendwann nachgelegt... Insgesamt hab ich wohl eher einen Glückstreffer gelandet, weil ja aufgrund irgendwelcher Paketabhängigkeiten dann alles mögliche nachinstalliert wird... Habe aber gestern Abend meinen bauknecht nochmal mit xUbuntu 16.04 neu aufgesetzt. Gleiches Problem, gleiches Vorgehen, build ist inzwischen durchgelaufen.

Klingt als hätte das Lösen der externen vcversioner-Abhängigkeit eine neue externe Abhängigkeit erzeugt ... irgendwann wenn alles halbwegs stabil ist müssen wir ggf. einfach eine Liste dessen machen, was man vor einem erfolgreichen Build an Vorbedingungen erfüllen sollte.

"Bauknecht" find ich klasse

Meine Frau hat das orange cfw übersehen, und sie könnte es auch nicht deuten, und meinte nur, hä, wieso Bauknecht?

Das Problem ist das von Buildroot für den Host gebaute python. Dem scheint irgendwas ssliges zu fehlen. Wenn ich ihn manuell zwinge das systemweite Python zu nehmen geht es.

Finde ich aber überraschend, dass Du das durch hinzuinstallieren von Paketen fixen konntest. Ggf. baut er das eigene Host-Python mit Dingen aus Deinem System.

Ja, ich habe die dev-pakete installiert! Für openssl mindestens...