The string is built using git describe, which fetches the most recent tag from the current tree:

balzer@leela:~/esp/esp-idf> git describe --always --tags --dirty
v3.1-dev-391-g8d8d62da

That's set at…

balzer@leela:~/esp/esp-idf> git show v3.1-dev
commit 22489d70214a5b7650ab197ffd6ab73e9c50a772
Merge: c4448714 f58c5b21
Author: Jiang Jiang Jian <jack@espressif.com>
Date:   Fri Dec 1 22:06:43 2017 +0800

    Merge branch 'bugfix/wdt_periph_enable' into 'master'
   
    watchdogs: make sure timer group peripherals are enabled
   
    See merge request !1623


So you're missing that tag ref after doing a fresh clone…

…and indeed, the tag is missing from our fork on github, it's only present in the esp origin:

https://github.com/openvehicles/esp-idf/tree/v3.1-dev → 404
https://github.com/espressif/esp-idf/tree/v3.1-dev → ok

So it seems we forgot to push the tags we fetched from upstream into our own fork. I did that now, so if you pull again, you should get the tag and the version string should be up to date.

But that should have had no effect on your issue then, as the revision tree is consistent. Tags are just that -- tags.

Another idea on your issue then: is your partition table unchanged & correct?

balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> cat partitions.csv
# OVMS 16MB flash ESP32 Partition Table
# Name,   Type, SubType, Offset,   Size
nvs,      data, nvs,     0x9000,  0x4000
otadata,  data, ota,     0xd000,  0x2000
phy_init, data, phy,     0xf000,  0x1000
factory,  app,  factory, 0x10000,  4M
ota_0,    app,  ota_0,   ,         4M
ota_1,    app,  ota_1,   ,         4M
store,    data, fat,     ,         1M


Regards,
Michael


Am 16.02.2018 um 19:24 schrieb Greg D.:
Hi Michael,

Yes, that was one of the first things I checked.  It points to /home/greg/esp/esp-idf, which is the current esp-idf directory.

m.version is this:

OVMS > metrics list m.version

m.version                                3.0.0/factory/main build (idf v3.0-dev-1781-g8d8d62da) Feb 15 2018 22:01:48
OVMS >

Where would I find the source of that string in the build environment?

Greg


Michael Balzer wrote:
Greg,

have you checked your IDF_PATH?

What does "m.version" show?

Regards,
Michael


Am 16.02.2018 um 09:27 schrieb Greg D.:
Present and accounted for.  Also, when I compile code, there's no warning about cross-versions, and I have a fresh copy of esp-idf from Github.  When I had the wrong branch, there was a warning about mismatched versions.

So, the git log matches, yet what I'm building doesn't; that's like, impossible, right?

Greg


Mark Webb-Johnson wrote:
Another thought - maybe the compiler version?

3.1 requires xtensa gcc 1.22.0-80 (g6c4433a-5.2.0).


Regards, Mark.

On 16 Feb 2018, at 2:19 PM, Stephen Casner <casner@acm.org> wrote:

Mine says:

OVMS > metrics list m.version
m.version
3.0.0/factory/main build (idf v3.1-dev-212-g00fa3889-dirty) Feb  7 2018 22:10:10

But, truth be told, I'm currently compiing from my own fork of
espressif/esp-idf that I set up to issue a PR to espressif for my
changes that support the memory diagnostics.

                                                       -- Steve

On Thu, 15 Feb 2018, Greg D. wrote:

Ok.  Back to half-sanity.  rm -rf esp-idf, Refetched from master including submodule
stuff, rm -r build, make clean, make, make flash.  Compiles and runs.

But still shows wrong version for m.version, and /store is still a mess.  Not sure if
I care about the m.version; what is going on with vfs?

Back to the TV...

Greg


Stephen Casner wrote:

Right.

    -- Steve

On Thu, 15 Feb 2018, Greg D. wrote:

Ok, so master from the openvehicles clone?

Greg


Stephen Casner wrote:

Gre,

No, we left behind the v2.1 of esp-idf a while ago.  We're now on
master.

                                                       -- Steve

On Thu, 15 Feb 2018, Greg D. wrote:

Mmm, never mind...  I realize we're still based on v2.1, right?

I've re-fetched stuff from the 2.1 branch, and still have the same results.  v3.0.0
listed as m.version, and junk in /store.

Now what?

Greg


Greg D. wrote:
     Ok, this is odd...  Are you sure esp-idf v3.1 is actually on Github?
     Tried re-fetching everything, and found this:

           greg@linux-0rpb:~/esp> git clone
           https://github.com/openvehicles/esp-idf.git
           Cloning into 'esp-idf'...
           remote: Counting objects: 44182, done.
           remote: Compressing objects: 100% (8/8), done.
           remote: Total 44182 (delta 0), reused 1 (delta 0), pack-reused
           44174
           Receiving objects: 100% (44182/44182), 50.53 MiB | 11.75
           MiB/s, done.
           Resolving deltas: 100% (31074/31074), done.
           greg@linux-0rpb:~/esp> cd esp-idf
           greg@linux-0rpb:~/esp/esp-idf> git branch -a
           * master
             remotes/origin/HEAD -> origin/master
             remotes/origin/feature/psram_malloc
             remotes/origin/master
             remotes/origin/release/v2.0
             remotes/origin/release/v2.1
             remotes/origin/release/v3.0
           greg@linux-0rpb:~/esp/esp-idf>

     Shouldn't there be a v3.1 listed there too?  Last entry is 3.0.

     Anyway, the first question is whether we have one problem or two...  Is my
     problem with /store related to v3.0 vs v3.1, or is it a separate problem
     on its own?  Do I simply need to clear flash and reload my config?  If so,
     what is the best way?

     Greg


     Mark Webb-Johnson wrote:
     Nope. Old hardware.
Out of ideas. I thought it just picked up the git version.

Regards, Mark.

     On 15 Feb 2018, at 12:07 PM, Greg D. <gregd2350@gmail.com>
     wrote:

No difference.

Are you on the new hardware?

Greg


Mark Webb-Johnson wrote:
     In your ovms directory:
     make clean
rm -rf build
make flash


That’s all I can think of.

Regards, Mark

     On 15 Feb 2018, at 11:59 AM, Greg D.
     <gregd2350@gmail.com> wrote:

Yes, and yes.  The top entry exactly matches your log.

Greg


Mark Webb-Johnson wrote:
     And you’ve already ‘git pull’ and ‘git
     submodule update’ in that esp idf?
If you ‘git log’, you should get:

     commit
     8d8d62da9e58305c8f7f4792264f8cab3ffe104b
     (HEAD -> master, origin/master,
     origin/HEAD)
Merge: 5bf85d06 ca3faa61
Author: Mark Webb-Johnson
<mark@webb-johnson.net>
Date:   Tue Feb 13 13:27:55 2018 +0800

    Merge remote-tracking branch
'espressif/master'


(which is where the 8d8d62da comes from)

Regards, Mark.

     On 15 Feb 2018, at 11:42 AM, Greg D.
     <gregd2350@gmail.com> wrote:

Yes and yes.
     greg@linux-0rpb:~/esp/esp-idf>
     git branch -a
     * master
       remotes/origin/HEAD ->
     origin/master

     remotes/origin/feature/psram_malloc
       remotes/origin/master
       remotes/origin/release/v2.0
       remotes/origin/release/v2.1
       remotes/origin/release/v3.0
     greg@linux-0rpb:~/esp/esp-idf>
     git remote -v
     origin
     https://github.com/openvehicles/esp-idf.git
     (fetch)
     origin
     https://github.com/openvehicles/esp-idf.git
     (push)
     greg@linux-0rpb:~/esp/esp-idf>

Greg


Mark Webb-Johnson wrote:
     In your esp idf directory, can
     you check ‘git branch -a’. Make
     sure you are on ‘master’ branch.
     Also ‘git remote -v’. Make sure
     you are on openvehicles clone.
Mark


     On 15 Feb 2018, at 10:24
     AM, Greg D.
     <gregd2350@gmail.com>
     wrote:

Hi Mark,

So, I changed the
CONFIG_LWIP_SO_REUSE value and
did a make flash.  That
displayed another option,
default Yes, changed to no.
But, same result with /store.

One significant difference is
that you're on idf 3.1 and I'm
on 3.0...  (3.0.0/factory/main
build (idf
v3.0-dev-1781-g8d8d62da) Feb 14
2018 18:12:05)

Did I miss a cog on this?

Greg


Mark Webb-Johnson wrote:
     My store seems ok:
     OVMS > vfs ls
     /store
ovms_config
obd2ecu
play

OVMS > metrics list
m.version
m.version

 3.0.0/factory/main
build (idf
v3.1-dev-391-g8d8d62da)
Feb 13 2018 14:05:21


Anybody else seeing this
issue?

Regarding the
CONFIG_LWIP_SO_REUSE, in
menuconfig you can use ‘/‘
to search for it. The
parameter is in Component
Config / LWIP.

Regards, Mark.


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev






_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26