Today I pulled the newest version. During the pull my Wolfssh directory was deleted. I then renewed all the submodules and I got the newest Wolfssh. But now the verion 3.3.003-467-ge7f41bd8-dirty won't compile (why is it "dirty" anyways, I didn't change the code ...). First I get CXX build/console_ssh/src/console_ssh.o /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp: In function 'void wolfssh_logger(wolfSSH_LogLevel, const char*)': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:1176:10: error: enumeration value 'WS_LOG_CERTMAN' not handled in switch [- Werror=switch] switch (level) ^ Then I add case WS_LOG_CERTMAN: on line 1178: static void wolfssh_logger(enum wolfSSH_LogLevel level, const char* const msg) { switch (level) { case WS_LOG_CERTMAN: ... But the I run into this error: /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'IdentifyKey': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:883:9: warning: unused variable 'dynType' [-Wunused-variable] int dynType = isPrivate ? DYNTYPE_PRIVKEY : DYNTYPE_PUBKEY; ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'DoKexDhReply': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3947:17: error: implicit declaration of function 'PRIVATE_KEY_UNLOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_UNLOCK(); ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3952:17: error: implicit declaration of function 'PRIVATE_KEY_LOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_LOCK(); ^ Any ideas? Regards Chris
Hi Chris, Yes we unfortunately had an issue where we merged, then reverted a patch. It seems that unfortunately it didn't work for you. Could you try to fetch, then reset your git repo to HEAD, it seems you did not fetch the "revert" patches ? Let us know. Le 13/05/2023 à 19:08, Chris van der Meijden a écrit :
Today I pulled the newest version. During the pull my Wolfssh directory was deleted. I then renewed all the submodules and I got the newest Wolfssh.
But now the verion 3.3.003-467-ge7f41bd8-dirty won't compile (why is it "dirty" anyways, I didn't change the code ...).
First I get
CXX build/console_ssh/src/console_ssh.o /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp: In function 'void wolfssh_logger(wolfSSH_LogLevel, const char*)': /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:1176:10: error: enumeration value 'WS_LOG_CERTMAN' not handled in switch [-Werror=switch] switch (level) ^
Then I add case WS_LOG_CERTMAN: on line 1178:
static void wolfssh_logger(enum wolfSSH_LogLevel level, const char* const msg) { switch (level) { case WS_LOG_CERTMAN: ...
But the I run into this error:
/home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'IdentifyKey': /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:883:9: warning: unused variable 'dynType' [-Wunused-variable] int dynType = isPrivate ? DYNTYPE_PRIVKEY : DYNTYPE_PUBKEY; ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'DoKexDhReply': /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3947:17: error: implicit declaration of function 'PRIVATE_KEY_UNLOCK' [-Werror=implicit-function-declaration] PRIVATE_KEY_UNLOCK(); ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3952:17: error: implicit declaration of function 'PRIVATE_KEY_LOCK' [-Werror=implicit-function-declaration] PRIVATE_KEY_LOCK(); ^
Any ideas?
Regards Chris
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Could you please explain in detail what I need to do? I tried to pull the code completely fresh from master. That does not work. What if a new user tries to compile from scratch? Will they run into the same issues? Am Samstag, dem 13.05.2023 um 19:32 +0200 schrieb Ludovic LANGE:
Hi Chris,
Yes we unfortunately had an issue where we merged, then reverted a patch.
It seems that unfortunately it didn't work for you. Could you try to fetch, then reset your git repo to HEAD, it seems you did not fetch the "revert" patches ?
Let us know.
Le 13/05/2023 à 19:08, Chris van der Meijden a écrit :
Today I pulled the newest version. During the pull my Wolfssh directory was deleted. I then renewed all the submodules and I got the newest Wolfssh.
But now the verion 3.3.003-467-ge7f41bd8-dirty won't compile (why is it "dirty" anyways, I didn't change the code ...).
First I get
CXX build/console_ssh/src/console_ssh.o /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp: In function 'void wolfssh_logger(wolfSSH_LogLevel, const char*)': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:1176:10: error: enumeration value 'WS_LOG_CERTMAN' not handled in switch [- Werror=switch] switch (level) ^
Then I add case WS_LOG_CERTMAN: on line 1178:
static void wolfssh_logger(enum wolfSSH_LogLevel level, const char* const msg) { switch (level) { case WS_LOG_CERTMAN: ...
But the I run into this error:
/home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'IdentifyKey': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:883:9: warning: unused variable 'dynType' [-Wunused-variable] int dynType = isPrivate ? DYNTYPE_PRIVKEY : DYNTYPE_PUBKEY; ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'DoKexDhReply': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3947:17: error: implicit declaration of function 'PRIVATE_KEY_UNLOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_UNLOCK(); ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3952:17: error: implicit declaration of function 'PRIVATE_KEY_LOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_LOCK(); ^
Any ideas?
Regards Chris
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OK ... I deleted the master from my repo on github ... Did a fresh pull from OVMS master to my local and then a fresh push from there to a new master in my github repo. Compiling does not work, so this will also be the case for anyone pulling fresh from master. That is not good ... The OVMS master needs urgently to be restored to a working repository. I would also like to suggest to stop experimenting with OVMS master and use a branch instead untill things are stable. Am Samstag, dem 13.05.2023 um 19:59 +0200 schrieb Chris van der Meijden:
Could you please explain in detail what I need to do?
I tried to pull the code completely fresh from master. That does not work.
What if a new user tries to compile from scratch? Will they run into the same issues?
Am Samstag, dem 13.05.2023 um 19:32 +0200 schrieb Ludovic LANGE: Hi Chris,
Yes we unfortunately had an issue where we merged, then reverted a patch.
It seems that unfortunately it didn't work for you. Could you try to fetch, then reset your git repo to HEAD, it seems you did not fetch the "revert" patches ?
Let us know.
Le 13/05/2023 à 19:08, Chris van der Meijden a écrit :
Today I pulled the newest version. During the pull my Wolfssh directory was deleted. I then renewed all the submodules and I got the newest Wolfssh.
But now the verion 3.3.003-467-ge7f41bd8-dirty won't compile (why is it "dirty" anyways, I didn't change the code ...).
First I get
CXX build/console_ssh/src/console_ssh.o /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp: In function 'void wolfssh_logger(wolfSSH_LogLevel, const char*)': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:1176:10: error: enumeration value 'WS_LOG_CERTMAN' not handled in switch [- Werror=switch] switch (level) ^
Then I add case WS_LOG_CERTMAN: on line 1178:
static void wolfssh_logger(enum wolfSSH_LogLevel level, const char* const msg) { switch (level) { case WS_LOG_CERTMAN: ...
But the I run into this error:
/home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'IdentifyKey': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:883:9: warning: unused variable 'dynType' [-Wunused-variable] int dynType = isPrivate ? DYNTYPE_PRIVKEY : DYNTYPE_PUBKEY; ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'DoKexDhReply': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3947:17: error: implicit declaration of function 'PRIVATE_KEY_UNLOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_UNLOCK(); ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3952:17: error: implicit declaration of function 'PRIVATE_KEY_LOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_LOCK(); ^
Any ideas?
Regards Chris
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Chris, Very puzzling what you experience. As I did exactly the same in a fresh dir without any issue: * git clone git@github.com:openvehicles/Open-Vehicle-Monitoring-System-3.git * cd Open-Vehicle-Monitoring-System-3/ * git submodule update --init --recursive * cd vehicle/OVMS.V3/ * cp support/sdkconfig.default.hw31 sdkconfig * make (And compilation was OK) In particular you can see the reverts here : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commits/mas... * 7b1c932eab4e00d6a20ba1cc8f30d7dbf6db7e2d : Revert "compatibility with WolfSSH >= 1.4.12" * beaada5aaa6c76da2d83612d263a1f3eb17e240c : Revert "Upgrade wolfssh 1.4.13" Can you confirm that in your local dir you have these 2 commits ? And that the last commit id is indeed e7f41bd8d9aabc0cecba369dc1b7e3641e748d17 ? Are other people on the list experience the same as Chris does here ? I know that Github has had some issues in the past week but I'm very puzzled about the different experiences between both of us. Regarding your last comment on master : I do take full responsibility for the issue you're facing, as I did wrongly communicate about the order of PRs that should have been applied to master. However, it was not an experimentation - the experimentation has been properly done on a branch as expected. Regards, Le 13/05/2023 à 21:14, Chris van der Meijden a écrit :
OK ... I deleted the master from my repo on github ... Did a fresh pull from OVMS master to my local and then a fresh push from there to a new master in my github repo.
Compiling does not work, so this will also be the case for anyone pulling fresh from master.
That is not good ... The OVMS master needs urgently to be restored to a working repository.
I would also like to suggest to stop experimenting with OVMS master and use a branch instead untill things are stable.
Am Samstag, dem 13.05.2023 um 19:59 +0200 schrieb Chris van der Meijden:
Could you please explain in detail what I need to do?
I tried to pull the code completely fresh from master. That does not work.
What if a new user tries to compile from scratch? Will they run into the same issues?
Am Samstag, dem 13.05.2023 um 19:32 +0200 schrieb Ludovic LANGE: Hi Chris,
Yes we unfortunately had an issue where we merged, then reverted a patch.
It seems that unfortunately it didn't work for you. Could you try to fetch, then reset your git repo to HEAD, it seems you did not fetch the "revert" patches ?
Let us know.
Le 13/05/2023 à 19:08, Chris van der Meijden a écrit : Today I pulled the newest version. During the pull my Wolfssh directory was deleted. I then renewed all the submodules and I got the newest Wolfssh.
But now the verion 3.3.003-467-ge7f41bd8-dirty won't compile (why is it "dirty" anyways, I didn't change the code ...).
First I get
CXX build/console_ssh/src/console_ssh.o /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp: In function 'void wolfssh_logger(wolfSSH_LogLevel, const char*)': /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:1176:10: error: enumeration value 'WS_LOG_CERTMAN' not handled in switch [-Werror=switch] switch (level) ^
Then I add case WS_LOG_CERTMAN: on line 1178:
static void wolfssh_logger(enum wolfSSH_LogLevel level, const char* const msg) { switch (level) { case WS_LOG_CERTMAN: ...
But the I run into this error:
/home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'IdentifyKey': /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:883:9: warning: unused variable 'dynType' [-Wunused-variable] int dynType = isPrivate ? DYNTYPE_PRIVKEY : DYNTYPE_PUBKEY; ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'DoKexDhReply': /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3947:17: error: implicit declaration of function 'PRIVATE_KEY_UNLOCK' [-Werror=implicit-function-declaration] PRIVATE_KEY_UNLOCK(); ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3952:17: error: implicit declaration of function 'PRIVATE_KEY_LOCK' [-Werror=implicit-function-declaration] PRIVATE_KEY_LOCK(); ^
Any ideas?
Regards Chris
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
After wolfssh was deleted during the fetch I did git submodule update --init --recursive git pull --recurse-submodules git submodule update --remote Then I was stranded with the wrong wolfssh version. git submodule sync --recursive corrected the wolfssh version now. Sorry for my words on "experimenting". Sometimes the complexity of it all is a bit frustrating. Am Samstag, dem 13.05.2023 um 21:37 +0200 schrieb Ludovic LANGE:
Chris,
Very puzzling what you experience. As I did exactly the same in a fresh dir without any issue: * git clone git@github.com:openvehicles/Open-Vehicle-Monitoring- System-3.git * cd Open-Vehicle-Monitoring-System-3/ * git submodule update --init --recursive * cd vehicle/OVMS.V3/ * cp support/sdkconfig.default.hw31 sdkconfig * make (And compilation was OK)
In particular you can see the reverts here :https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commits/mas... * 7b1c932eab4e00d6a20ba1cc8f30d7dbf6db7e2d : Revert "compatibility with WolfSSH >= 1.4.12" * beaada5aaa6c76da2d83612d263a1f3eb17e240c : Revert "Upgrade wolfssh 1.4.13" Can you confirm that in your local dir you have these 2 commits ? And that the last commit id is indeed e7f41bd8d9aabc0cecba369dc1b7e3641e748d17 ?
Are other people on the list experience the same as Chris does here ? I know that Github has had some issues in the past week but I'm very puzzled about the different experiences between both of us.
Regarding your last comment on master : I do take full responsibility for the issue you're facing, as I did wrongly communicate about the order of PRs that should have been applied to master. However, it was not an experimentation - the experimentation has been properly done on a branch as expected.
Regards,
Le 13/05/2023 à 21:14, Chris van der Meijden a écrit :
OK ... I deleted the master from my repo on github ... Did a fresh pull from OVMS master to my local and then a fresh push from there to a new master in my github repo.
Compiling does not work, so this will also be the case for anyone pulling fresh from master.
That is not good ... The OVMS master needs urgently to be restored to a working repository.
I would also like to suggest to stop experimenting with OVMS master and use a branch instead untill things are stable.
Am Samstag, dem 13.05.2023 um 19:59 +0200 schrieb Chris van der Meijden:
Could you please explain in detail what I need to do?
I tried to pull the code completely fresh from master. That does not work.
What if a new user tries to compile from scratch? Will they run into the same issues?
Am Samstag, dem 13.05.2023 um 19:32 +0200 schrieb Ludovic LANGE: Hi Chris,
Yes we unfortunately had an issue where we merged, then reverted a patch.
It seems that unfortunately it didn't work for you. Could you try to fetch, then reset your git repo to HEAD, it seems you did not fetch the "revert" patches ?
Let us know.
Le 13/05/2023 à 19:08, Chris van der Meijden a écrit :
Today I pulled the newest version. During the pull my Wolfssh directory was deleted. I then renewed all the submodules and I got the newest Wolfssh.
But now the verion 3.3.003-467-ge7f41bd8-dirty won't compile (why is it "dirty" anyways, I didn't change the code ...).
First I get
CXX build/console_ssh/src/console_ssh.o /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp: In function 'void wolfssh_logger(wolfSSH_LogLevel, const char*)': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:1176:1 0: error: enumeration value 'WS_LOG_CERTMAN' not handled in switch [-Werror=switch] switch (level) ^
Then I add case WS_LOG_CERTMAN: on line 1178:
static void wolfssh_logger(enum wolfSSH_LogLevel level, const char* const msg) { switch (level) { case WS_LOG_CERTMAN: ...
But the I run into this error:
/home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'IdentifyKey': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:883:9: warning: unused variable 'dynType' [-Wunused-variable] int dynType = isPrivate ? DYNTYPE_PRIVKEY : DYNTYPE_PUBKEY; ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'DoKexDhReply': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3947:17 : error: implicit declaration of function 'PRIVATE_KEY_UNLOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_UNLOCK(); ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3952:17 : error: implicit declaration of function 'PRIVATE_KEY_LOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_LOCK(); ^
Any ideas?
Regards Chris
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Indeed I was going to suggest that you pull fresh from master in another new dir in fact. When doing so, you should have: * "vehicle/OVMS.V3/components/wolfssh/wolfssh" as a submodule * "vehicle/OVMS.V3/components/wolfssl/wolfssl" as a normal dir (for now. Will change in a few PR's) You can check that with : $ git submodule status 7b953e7ebb440ce9461ee469159c3759450e7c98 vehicle/OVMS.V3/components/mongoose/mongoose (6.2-882-g7b953e7) c05f6c7530a8670e3d0ffdf04ee4cecb2d3b0496 vehicle/OVMS.V3/components/wolfssh/wolfssh (v1.4.10-stable) 7c3878f8302c0e84578a67473e49e60bc6b3ada7 vehicle/OVMS.V3/components/zip/libzip (rel-1-5-1-60-g7c3878f) d6bcf4ca4d02479f058fff44cfd171f928148179 vehicle/OVMS.V3/components/zip/zlib (v1.2.11-65-gd6bcf4c) In particular, you should have wolfssh at v1.4.10-stable If not, please try both: git submodule update --init --recursive git submodule sync --recursive If not, please be sure that you do all this in a separate fresh directory. If a new user tries to compile from scratch, I believe it should work. (I've just tried it, and it "works for me") The error you have seems to imply that wolfssh is not at the proper 1.4.10 version but at a version >= 1.4.12 Let us know. Regards, Le 13/05/2023 à 19:59, Chris van der Meijden a écrit :
Could you please explain in detail what I need to do?
I tried to pull the code completely fresh from master. That does not work.
What if a new user tries to compile from scratch? Will they run into the same issues?
Am Samstag, dem 13.05.2023 um 19:32 +0200 schrieb Ludovic LANGE:
Hi Chris,
Yes we unfortunately had an issue where we merged, then reverted a patch.
It seems that unfortunately it didn't work for you. Could you try to fetch, then reset your git repo to HEAD, it seems you did not fetch the "revert" patches ?
Let us know.
Le 13/05/2023 à 19:08, Chris van der Meijden a écrit : Today I pulled the newest version. During the pull my Wolfssh directory was deleted. I then renewed all the submodules and I got the newest Wolfssh.
But now the verion 3.3.003-467-ge7f41bd8-dirty won't compile (why is it "dirty" anyways, I didn't change the code ...).
First I get
CXX build/console_ssh/src/console_ssh.o /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp: In function 'void wolfssh_logger(wolfSSH_LogLevel, const char*)': /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:1176:10: error: enumeration value 'WS_LOG_CERTMAN' not handled in switch [-Werror=switch] switch (level) ^
Then I add case WS_LOG_CERTMAN: on line 1178:
static void wolfssh_logger(enum wolfSSH_LogLevel level, const char* const msg) { switch (level) { case WS_LOG_CERTMAN: ...
But the I run into this error:
/home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'IdentifyKey': /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:883:9: warning: unused variable 'dynType' [-Wunused-variable] int dynType = isPrivate ? DYNTYPE_PRIVKEY : DYNTYPE_PUBKEY; ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'DoKexDhReply': /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3947:17: error: implicit declaration of function 'PRIVATE_KEY_UNLOCK' [-Werror=implicit-function-declaration] PRIVATE_KEY_UNLOCK(); ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3952:17: error: implicit declaration of function 'PRIVATE_KEY_LOCK' [-Werror=implicit-function-declaration] PRIVATE_KEY_LOCK(); ^
Any ideas?
Regards Chris
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
"git submodule sync --recursive" did the trick. I was on wolfssh 1.4.13. Now I'm back on 1.4.10 and 3.3.003-467- ge7f41bd8-dirty compiles. Still "dirty" but it compiles. Thanx! Am Samstag, dem 13.05.2023 um 21:23 +0200 schrieb Ludovic LANGE:
Indeed I was going to suggest that you pull fresh from master in another new dir in fact.
When doing so, you should have: * "vehicle/OVMS.V3/components/wolfssh/wolfssh" as a submodule * "vehicle/OVMS.V3/components/wolfssl/wolfssl" as a normal dir (for now. Will change in a few PR's) You can check that with : $ git submodule status 7b953e7ebb440ce9461ee469159c3759450e7c98 vehicle/OVMS.V3/components/mongoose/mongoose (6.2-882-g7b953e7) c05f6c7530a8670e3d0ffdf04ee4cecb2d3b0496 vehicle/OVMS.V3/components/wolfssh/wolfssh (v1.4.10-stable) 7c3878f8302c0e84578a67473e49e60bc6b3ada7 vehicle/OVMS.V3/components/zip/libzip (rel-1-5-1-60-g7c3878f) d6bcf4ca4d02479f058fff44cfd171f928148179 vehicle/OVMS.V3/components/zip/zlib (v1.2.11-65-gd6bcf4c) In particular, you should have wolfssh at v1.4.10-stable
If not, please try both: git submodule update --init --recursive git submodule sync --recursive
If not, please be sure that you do all this in a separate fresh directory.
If a new user tries to compile from scratch, I believe it should work. (I've just tried it, and it "works for me")
The error you have seems to imply that wolfssh is not at the proper 1.4.10 version but at a version >= 1.4.12
Let us know.
Regards,
Le 13/05/2023 à 19:59, Chris van der Meijden a écrit :
Could you please explain in detail what I need to do?
I tried to pull the code completely fresh from master. That does not work.
What if a new user tries to compile from scratch? Will they run into the same issues?
Am Samstag, dem 13.05.2023 um 19:32 +0200 schrieb Ludovic LANGE:
Hi Chris,
Yes we unfortunately had an issue where we merged, then reverted a patch.
It seems that unfortunately it didn't work for you. Could you try to fetch, then reset your git repo to HEAD, it seems you did not fetch the "revert" patches ?
Let us know.
Le 13/05/2023 à 19:08, Chris van der Meijden a écrit :
Today I pulled the newest version. During the pull my Wolfssh directory was deleted. I then renewed all the submodules and I got the newest Wolfssh.
But now the verion 3.3.003-467-ge7f41bd8-dirty won't compile (why is it "dirty" anyways, I didn't change the code ...).
First I get
CXX build/console_ssh/src/console_ssh.o /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp: In function 'void wolfssh_logger(wolfSSH_LogLevel, const char*)': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:1176:1 0: error: enumeration value 'WS_LOG_CERTMAN' not handled in switch [-Werror=switch] switch (level) ^
Then I add case WS_LOG_CERTMAN: on line 1178:
static void wolfssh_logger(enum wolfSSH_LogLevel level, const char* const msg) { switch (level) { case WS_LOG_CERTMAN: ...
But the I run into this error:
/home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'IdentifyKey': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:883:9: warning: unused variable 'dynType' [-Wunused-variable] int dynType = isPrivate ? DYNTYPE_PRIVKEY : DYNTYPE_PUBKEY; ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'DoKexDhReply': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3947:17 : error: implicit declaration of function 'PRIVATE_KEY_UNLOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_UNLOCK(); ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3952:17 : error: implicit declaration of function 'PRIVATE_KEY_LOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_LOCK(); ^
Any ideas?
Regards Chris
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (2)
-
Chris van der Meijden -
Ludovic LANGE