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