SQL-Adapter beim Update zerschossen

Thisoft

@Homoran sagte in SQL-Adapter beim Update zerschossen:

Dann sind das wohl die Nachteile von OpenSource - viele Programmierer verderben den Versions-Brei

Den Satz verstehe ich jetzt gar nicht. Kannst du mal sagen was du damit meinst.

Ist nicht böse gemeint - ist halt so, bei anderer Software gibt's wieder andere Probleme. Ich meinte damit nur, dass ein Programmierer (z.B. der des Adapters) sich ja wieder auf Abhängigkeiten anderer Software (z.B. Node) verlässt (verlassen muss). Wenn dann an einem Ende bzw. zwischendurch ein Stück Software upgradet wird (was ja auch gut ist - sonst wär sie ja tot) dann ist halt nicht immer kontrollier- bzw. vorhersehbar was mit den nachfolgenden Abhängigkeiten passiert.

Nodejs war zu früheren zeiten, jetzt heisst es nur noch node.

Wie die pakete unter Windows heißen weiss ich nicht, aber wenn nodejs nicht gefunden wird uss das noch lange nicht schlecht sein.

Wenn das so ist dann wäre der Punkt ja schon mal geklärt und ich kann woanders weitersuchen. Ich dachte nur es wird gebraucht weil es in meiner bisherigen Installation (Node8.11) verfügbar war.

Jetzt brauch ich nur weitere Ideen...

Thisoft

Noch eine Frage dazu:

gyp ERR! node -v v10.15.3
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok 

npm ERR! code ELIFECYCLEnpm ERR! errno 1
npm ERR! mmmagic@0.5.2 install: `node-gyp rebuild`
npm ERR! Exit status 1

Was ist denn das "node-gyp" was da möglicherweise eine falsche Version hat oder anderweitig einen Fehler liefert?

apollon77

@Thisoft @Jeeper-at Ja hat er:
Sorry, absoluter Müll! Die Version 1.9.4 ist von Anfang März und 1521 mal installiert ... also liegt es gaaaanz bestimmt an dieser Version und an den Open-Source-Entwicklern ... WTF ... Sorry, aber Bullshit. Solche Kommentare nerven ungemein. ja ich habe gelesen was Du weiter unten geschrieben hast, dennoch ...
@Jeeper-at Und wenn es mit einer Version bekannterweise Probleme gibt ... wo ist das GitHub issue?

Damit mal zur Realität: Am Adapter hat sich seit laaaangem nichts mehr geändert! Der Adapter und das Adapter Update ist es nicht!

Jetzt mal zu Hilfeversuchen:
Wie weiter oben von Thisoft schon korrekt vermutet liegt die wahre Ursache darin das der Fehler auftritt:

npm ERR! mmmagic@0.5.2 install: node-gyp rebuild
Warum ist jetzt die interessante Frage. node-gyp ist der Teil der native kompilierte Module bei der Installation auf Deinem System jeweils neu baut.

Weiterhin hattest Du Zu beginn node 8, jetzt node 10. Hast Du generell ein "npm rebuild" ausgeführt wie man es bei nodejs Updates braucht? Sonst kann gerade noch mehr defekt sein. Das "Nodejs" unbekannt ist könnte zu anderen Dingen führen, aber ich denke hat mit dem Problem nichts zu tun.

Mit einer Google Suche kommst Du ganz schnell zu https://github.com/mscdex/mmmagic/issues/135 ... und schau mal von wem das ist ... Also Ja es liegt an Deinen Build Tools denke ich. Diese mmmagic braucht seit node 10 (was Du ja jetzt hast) eine höhere Version der MS VS Libs, nämlich mindestens 2015 ... An sich sollte das aber bei den Build Tools installiert werden (https://www.npmjs.com/package/windows-build-tools#visual-studio-2017-vs-visual-studio-2015) Schau da nochmal rein ...

Thisoft

@apollon77 sagte in SQL-Adapter beim Update zerschossen:

Sorry, absoluter Müll! Die Version 1.9.4 ist von Anfang März und 1521 mal installiert ... also liegt es gaaaanz bestimmt an dieser Version und an den Open-Source-Entwicklern ... WTF ... Sorry, aber Bullshit. Solche Kommentare nerven ungemein. ja ich habe gelesen was Du weiter unten geschrieben hast, dennoch ...

Ich weiß selber aus Erfahrung dass solche "Verallgemeinerungen" ungemein nerven können. Sorry wenn ich da schief rüberkam, ich hab aber auch nirgends behauptet dass das an den Entwicklern liegt...

Ich weiß dass die Version von Anfang März ist, eben deshalb fand ich jetzt dass es mal Zeit wäre upzudaten :-(

"npm rebuild" hab ich nach jeder Node-Neuinstallation gemacht. Das Node-Upgrade hab ich übrigens gemacht weil Homoran oben meinte dass die 8er-Version ein Speicherleck hätte...

Mit den Windows-Build-Tools hab ich mich auch schon beschäftigt. Die sind mit Sicherheit hier der Kern des Übels. Ich hab die auch gleich nach dem ersten Fehlschlag mit "npm install --global windows-build-tools" upgedated - dachte ich zumindest. Leider verweist da wohl irgendwo irgendwas irgendwie auf die falsche Version. Zwischendurch stand mal in der Konsole dass er die "V141" sucht und diese aber in einem Pfad namens "...\V140" nicht finden kann - verständlich.
Die V141 sind lt. Google die MSBuildTools 2017, diese waren aber bereits installiert und ich hab das alles auch nochmal neu installiert, zwischendurch die 2015er Version auch mal runtergeworfen...
Hat bis jetzt alles nichts geholfen:-( Von der Warte bin ich eben mittlerweile auch so bisschen an dem Punkt wo ich das nur noch als nervigen Bullshit finde - ich hoffe das ist auch ein wenig verständlich...

Wie auch immer - irgendwie muss ich durch - ich plage mich mal weiter mit den Build-Tools herum...

apollon77

Hey,

alles gut.

Naja hättest auf in der 8er Linie updazen können - denke das meinte Homoran eher :-) Alles unter 8.15 hatte nen memory-leak, aber alles danach nicht mehr. Also ein Update auf 8.15 hätte gereicht, aber jetzt bist Du denke einige Schritte weiter.

Das das mit den Build Tools nervt kann ich verstehen, da bin ich dann aber leider kein Windows-User der da viel helfen könnte :-( Vllt mal über Windows-Einstellungen MS VS xx Pakete deinstallieren falls die da drin gelistet sind :-(
Danach dann über die windows-build-tools neu installieren ?!
Drücke die Daumen das Du es hinbekommst

Jeeper.at

@Jeeper-at Und wenn es mit einer Version bekannterweise Probleme gibt ... wo ist das GitHub issue?

Was ein GIT Issue bringt sehe ich ja am Plumb. Der ist sei Monaten offen. Ach ja, der ist ja nur auf Platz 246 der Wichtigkeitskala.

Ich kann nur sagen, das nach dem Upgrade der SQL nicht mehr funktioniert hat. Und zwar genauso wie der TE geschrieben hat. Ob du das jetzt Müll findest bleibt dir überlassen.

apollon77

@Jeeper-at Habs ja fast geahnt das das Deine Antwort ist. Äpfel und Birnen ...

Fakten zu "nach dem Update tut es nicht mehr" stehen oben, wenn Du dazu etwas neues beizutragen hast dann jederzeit gern. Ich persönlich habe sql unter node 8 und 10 unter Linux laufen ohne Probleme und das automatische Adapter-Testing läuft mit MSVS2015 ebenfalls problemlos mit nodejs 10. Probleme, siehe oben, sind momentan nur bekannt unter Windows und mit nodejs 10 und MSVS <2015.

Thisoft

So - mal wieder ein kleines Update - hatte die Feiertage nicht wirklich Zeit für diese Baustelle...

Ich habe:
-erstmal alle (also ALLE) MS C++ Redistributables deinstalliert
-dann mal Reboot und alles nochmal gecheckt ob's weg ist
-dann ein "npm install --global windows-build-Tools"; damit hab ich die 2017er Version bekommen
-wieder ein Reboot
-nochmal zur Sicherheit "npm rebuild" (weiß nicht ob das nötig war - dieses ständige Neukompilierungskonzept von Linux hab ich noch nicht wirklich verstanden...)
-dann neuer Versuch; wieder erfolglos :-( allerdings mit etwas anderen Fehlermeldungen:

C:\ioBroker>iobroker install sql@latest --production

C:\ioBroker>node node_modules/iobroker.js-controller/iobroker.js install sql@latest --production
NPM version: 6.4.1
npm install iobroker.sql@latest --production --save --prefix "C:/ioBroker" (System call)
npm WARN deprecated sprintf@0.1.5: The sprintf package is deprecated in favor of sprintf-js.
npm WARN deprecated core-js@1.2.7: core-js@<2.6.5 is no longer maintained. Please, upgrade to core-js@3 or at least to actual version of core-js@2.
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:189:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\ioBroker\node_modules\iobroker.sql\node_modules\mmmagic
gyp ERR! node -v v10.15.3
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! mmmagic@0.5.2 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the mmmagic@0.5.2 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Thilo\AppData\Roaming\npm-cache\_logs\2019-04-23T07_25_53_799Z-debug.log
host.Acer2 Adapter directory "null" does not exists
Cannot parse null/io-package.json:Error: ENOENT: no such file or directory, open 'null/io-package.json'``

Kann mir bitte jemand helfen, was ich jetzt gegen diesen node-gyp-Error 1 und ELIFECYCLE tun müsste?

Verzweifelte Grüße
Thilo

apollon77

Hey, das ist Mist :-(

Der "Neukompilierungskram von Linux" hat in dem Fall nichts mit Linux zu tun. Es geht simpel um Performance. Einige nodejs Module haben "binäre" teile die nicht in Javascript geschrieben sind sondern in C/C++, meistens wegen performance oder weil man nur so System-Libs nutzen kann. Das kann man zum Teil "vorkompilieren" und laden aber einige hängt auch von anderen lokalen Libraries auf dem Zielsystem ab. Damit bleibt nur der Weg diese binären Teile bei der Installation zu kompilieren. Und das ist das was hier passiert. Also nix Linux ;-) Auch Windows ...

Am besten probier das doch mal getrennt von iobroker aus ... Leg ein verzeichnis an egal wo und öffne shell dahin. Dann

"npm install mmmagic@0.5.2 --production"

Dann sollte der gleiche Fehler kommen. Dann aber mal das Logfile was da angegeben wird posten, vllt ist da ja was hilfreiches drin

Thisoft

@apollon77
Also --- der Fehler bleibt der Gleiche, egal wohin ich mmmagic versuche zu installieren.
Was lt. Log IMO das Problem sein dürfte:

Der Buildvorgang wurde am 23.04.2019 18:06:37 gestartet.
Projekt "C:\ioBroker\node_modules\mmmagic\build\binding.sln" auf Knoten "1" (Standardziele).
ValidateSolutionConfiguration:
  Die Projektmappenkonfiguration "Release|x64" wird erstellt.
Das Projekt "C:\ioBroker\node_modules\mmmagic\build\binding.sln" (1) erstellt "C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj" (2) auf Knoten "1" (Standardziele).
C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj(20,3): error MSB4019: Das importierte Projekt "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Cpp.Default.props" wurde nicht gefunden. Vergewissern Sie sich, dass der Pfad in der <Import>-Deklaration korrekt und die Datei auf dem Datentr„ger vorhanden ist.
Die Erstellung des Projekts "C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj" ist abgeschlossen (Standardziele) -- FEHLER.
Die Erstellung des Projekts "C:\ioBroker\node_modules\mmmagic\build\binding.sln" ist abgeschlossen (Standardziele) -- FEHLER.

Fehler beim Buildvorgang.

"C:\ioBroker\node_modules\mmmagic\build\binding.sln" (Standardziel) (1) ->
"C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj" (Standardziel) (2) ->
  C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj(20,3): error MSB4019: Das importierte Projekt "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Cpp.Default.props" wurde nicht gefunden. Vergewissern Sie sich, dass der Pfad in der <Import>-Deklaration korrekt und die Datei auf dem Datentr„ger vorhanden ist.

    0 Warnung(en)
    1 Fehler

Irgendwie kann ich auch nichts finden dass während der Installation überhaupt der Ordner "..\mmmagic" erstellt würde geschweige denn irgendwelcher Inhalt... Schreibrechte hab ich aber, kann den Ordner aus der Konsole heraus anlegen...

Wäre das ein Ansatzpunkt?

apollon77

@Thisoft sagte in SQL-Adapter beim Update zerschossen:

"C:\Program Files (x86)\MSBuild\14.0\Microsoft.Cpp.Default.props" wurde nicht gefunden

Ich habe mal etwas gegoogelt, vllt ist ja hier was drin:

https://stackoverflow.com/questions/16092169/why-does-msbuild-look-in-c-for-microsoft-cpp-default-props-instead-of-c-progr
https://stackoverflow.com/questions/49327432/microsoft-cpp-default-props-not-found-when-running-npm-install
https://stackoverflow.com/questions/41695251/c-microsoft-cpp-default-props-was-not-found

Thisoft

@apollon77

Hurra - er läuft wieder :-)

Deine Links waren zwar noch nicht die eigentliche Lösung aber der richtige Weg. Die Systemvariable "VCTargetsPath" war falsch. Allerdings waren alle Pfade die in den Links angegeben waren auch falsch. Ich habe dann auf meiner Platte erstmal nach Dateien namens "Microsoft.cpp" gesucht. Die liegen bei mir seltsamerweise in einem völlig anderen Pfad als überall von Dr.Google ausgespuckt wird... Kann sein, dass sich der Pfad mit der 2017er Version geändert hat, dass dann allerdings die entsprechenden Umgebungsvariablen nicht richtig gesetzt werden ist wohl entweder eine unglückliche Konstellation auf meinem Rechner oder ein Bug von Windows.

Jedenfalls habe ich dann die beiden Umgebungsvariablen wie folgt gesetzt:

C:\ioBroker>set VCTargetsPath=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets

C:\ioBroker>set VS140COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\Tools

und dann lief die Installation des Adapters fehlerfrei durch :-) Juhu - nach einer Woche endlich wieder geloggte Daten...

apollon77

@Thisoft Cool gratuliere!

@Jeeper-at Vllt willst Du es auch mal so versuchen? Oder hast Du kein Windows und ein anderes Problem?

Community Forum

NEWS

SQL-Adapter beim Update zerschossen

Support us

532

32.5k

81.7k

1.3m