BFGMiner 5.5.0: CPU/GPU/FPGA/ASIC mining software, GBT+Stratum, RPC, Linux/Win64

[Luke-Jr]

Nah, I was looking for some hint as to what went wrong during detection.

I don't see significant differences (a part from the device name CBM vs AMU) when I compared the old debug log with the new one during the detection phase, but perhaps you can see that.

I found one bug. Can you confirm what command-line you are using?

[.anto.]

I found one bug. Can you confirm what command-line you are using?

I have already confirmed that on my previous post as below. The only different between the information on that post and the one containing the comparison are the voltage, clock and timing parameters.

I don't set the parameters on the command line and I have BFGMiner running on my router so I am using the command line as below.

Code:

root:~# screen -dmS bfgminer bfgminer --config /etc/bfgminer/bfgminer.conf

And the content of my bfgminer.conf is below (with usernames hidden)

Code:

root:~# cat /etc/bfgminer/bfgminer.conf
{
"pools" : [
	{
		"url" : "stratum+tcp://stratum.mining.eligius.st:3334",
		"user" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
		"pass" : "x",
		"pool-priority" : "0"
	},
	{
		"url" : "stratum+tcp://stratum.antpool.com:3333",
		"user" : "XXXXXXXX",
		"pass" : "x",
		"pool-priority" : "1"
	}
]
,
"api-mcast-port" : "4028",
"api-port" : "4028",
"debuglog" : true,
"expiry" : "120",
"expiry-lp" : "3600",
"failover-switch-delay" : "300",
"log" : "30",
"no-local-bitcoin" : true,
"no-pool-disable" : true,
"no-client-reconnect" : true,
"queue" : "1",
"quiet" : true,
"quiet-work-updates" : true,
"quiet-work-update" : true,
"scan-time" : "60",
"show-processors" : true,
"show-procs" : true,
"skip-security-checks" : "0",
"submit-stale" : true,
"temp-hysteresis" : "3",
"shares" : 0,
"kernel-path" : "/usr/share/bfgminer",
"scan" : [
	"antminer:/dev/ttyUSB0",
	"antminer:/dev/ttyUSB1"
],
"set-device" : [
	"antminer:voltage=x800",
	"antminer:clock=x882",
	"antminer:timing=0.0166"
]
}

[Luke-Jr]

OK, I think that's related to the bug I found then.
Not a very simple fix, but it could cause other problems in the future, so I'll try to get it fixed.

[.anto.]

OK, I think that's related to the bug I found then.
Not a very simple fix, but it could cause other problems in the future, so I'll try to get it fixed.

Could you please briefly explain the bug?

Is that related to the issue that I raised on your github 2 months ago?

If you would like to make sure that what your suspected to be the bug is related to the way I executed bfgminer, could you please just tell me the command line that I should execute to confirm whether it is really a bug or not?

[Luke-Jr]

OK, I think that's related to the bug I found then.
Not a very simple fix, but it could cause other problems in the future, so I'll try to get it fixed.

Could you please briefly explain the bug?

Drivers are registered in a hash table by their name, and when you specify -S dname:anything, when <anything> is seen, it always probes <dname> first. But the hash table does not support multiple entries with the same string, so since compac was called "antminer", it was getting probed for anything specifying "antminer".

Is that related to the issue that I raised on your github 2 months ago?

No.

If you would like to make sure that what your suspected to be the bug is related to the way I executed bfgminer, could you please just tell me the command line that I should execute to confirm whether it is really a bug or not?

The only way I can think to confirm it further, would be to produce a 5.3.0 with only that bug fixed.
Probably won't have this until tomorrow or Monday.

[Luke-Jr]

If you would like to make sure that what your suspected to be the bug is related to the way I executed bfgminer, could you please just tell me the command line that I should execute to confirm whether it is really a bug or not?

The only way I can think to confirm it further, would be to produce a 5.3.0 with only that bug fixed.
Probably won't have this until tomorrow or Monday.

This is ready to be tested. Please download and test these binaries (or GitHub branch tmp40389 if you build from source).

[.anto.]

This is ready to be tested. Please download and test these binaries (or GitHub branch tmp40389 if you build from source).

How do we actually test this build? 

I am using your tmp40389 branch as I need to compile it for my WiFi router. The initialisation phase below looks the same to me.

Code:

 [2015-10-19 18:05:06] Timers: Using clock_gettime(CLOCK_MONOTONIC)
 [2015-10-19 18:05:06] Global quota greatest common denominator set to 1
 [2015-10-19 18:05:06] Global quota greatest common denominator set to 1
 [2015-10-19 18:05:06] Global quota greatest common denominator set to 1
 [2015-10-19 18:05:06] setrlimit: Soft fd limit not being changed from 1024 (FD_SETSIZE=1024; hard limit=4096)
 [2015-10-19 18:05:06] Started bfgminer 5.3.0-unknown
 [2015-10-19 18:05:06] Loaded configuration file /etc/bfgminer/bfgminer.conf
 [2015-10-19 18:05:06] lowlevel_scan: Found vcom device at dev_t:000000000000bc01 (path=/dev/ttyUSB1, vid=0000, pid=0000, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)
 [2015-10-19 18:05:06] lowlevel_scan: Found vcom device at dev_t:000000000000bc00 (path=/dev/ttyUSB0, vid=0000, pid=0000, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:voltage=x830
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:voltage=x830
 [2015-10-19 18:05:06] AMU: Applying rule antminer:voltage=x830: Unknown option: voltage
 [2015-10-19 18:05:06] AMU: Applying rule antminer:voltage=x830: Unknown option: voltage
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:clock=x0882
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:clock=x0882
 [2015-10-19 18:05:06] AMU: Applying rule antminer:clock=x0882: Unknown option: clock
 [2015-10-19 18:05:06] AMU: Applying rule antminer:clock=x0882: Unknown option: clock
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:timing=0.0154
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:timing=0.0154
 [2015-10-19 18:05:06] (null): Init: mode=value read_timeout_ms=65 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] (null): Init: mode=value read_timeout_ms=65 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] AMU: Applied rule antminer:timing=0.0154
 [2015-10-19 18:05:06] AMU: Applied rule antminer:timing=0.0154
 [2015-10-19 18:05:06] antminer: Attempting to open /dev/ttyUSB0
 [2015-10-19 18:05:06] antminer: Attempting to open /dev/ttyUSB1
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB1
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB0
 [2015-10-19 18:05:06] antminer: Test succeeded at /dev/ttyUSB1: got 000187a2
 [2015-10-19 18:05:06] /dev/ttyUSB1: Init: mode=value read_timeout_ms=75 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] antminer: Test succeeded at /dev/ttyUSB0: got 000187a2
 [2015-10-19 18:05:06] /dev/ttyUSB0: Init: mode=value read_timeout_ms=75 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB1
 [2015-10-19 18:05:06] antminer: Work division not specified - autodetecting
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB0
 [2015-10-19 18:05:06] antminer: Work division not specified - autodetecting
 [2015-10-19 18:05:06] antminer: Work division autodetection got 417c0f36 (=4)
 [2015-10-19 18:05:06] antminer: Work division autodetection got 417c0f36 (=4)
 [2015-10-19 18:05:06] Found AMU 0 at /dev/ttyUSB0
 [2015-10-19 18:05:06] Found AMU 1 at /dev/ttyUSB1
 [2015-10-19 18:05:06] AMU 0: Init: baud=115200 work_division=0 fpga_count=0
 [2015-10-19 18:05:06] AMU 1: Init: baud=115200 work_division=0 fpga_count=0
 [2015-10-19 18:05:06] Probing for an alive pool
.
.

[.anto.]

I have one suggestion Luke, if you don't mind.

I have been trying different branches of your github. At some points (and actually just now), I am confused with the versions as all of them only show "bfgminer 5.3.0-unknown". I can differentiate them from the package versions as I can set them. But there is no way to know the version on the screenshot of the UI or debug log (unless I make sure to identify them from the log file name).

Would it be possible to include an indication of branch/tag/commit/whatever in the UI and debug log to differentiate between each version?

[Mikestang]

Hmm, maybe try changing the single-quotes to double-quotes.

Thank you, that did the trick!

Code:

C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,0x0a02"
Reply was 'STATUS=E,When=1445296756,Code=93,Msg=PGA 0 set failed: invalid clock: '0x0a02' data must be
 prefixed with an x,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => E
   [When] => 1445296756
   [Code] => 93
   [Msg] => PGA 0 set failed: invalid clock: '0x0a02' data must be prefixed with an x
   [Description] => bfgminer 5.3.0
)

It appears that the leading '0' needs to be dropped from the hex frequency value, however:

Code:

C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,x0a02"
Reply was 'STATUS=S,When=1445296795,Code=92,Msg=PGA 0 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => S
   [When] => 1445296795
   [Code] => 92
   [Msg] => PGA 0 set OK
   [Description] => bfgminer 5.3.0
)

I can successfully report an immediate increase in hash speed on the sticks once the command is issued.  Thanks again, looking forward to 5.4.0.  

I looks like you do not need the trailing quote mark for whatever reason, but it will error if you omit the leading one:

Code:

C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,x0982
Reply was 'STATUS=S,When=1445297249,Code=92,Msg=PGA 0 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => S
   [When] => 1445297249
   [Code] => 92
   [Msg] => PGA 0 set OK
   [Description] => bfgminer 5.3.0
)

Edit - for some reason the forum keeps inserting the extra /code breaks at the end.  I didn't put them there, and when I edit to delete them they just show up again when I save...[/code][/code][/code]


I have two gekko compacs running on this particular machine and the rpc command only appears to have increased the frequency on one stick.  I replaced "cbm0" with "cbm1" to see if I could effect the other stick.  The command was accepted successfully, however, the second stick did not increase in hash rate.  Do I need to do something different to get the second stick to see the new frequency?

[Luke-Jr]

Hmm, maybe try changing the single-quotes to double-quotes.

Thank you, that did the trick!

Code:

C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,0x0a02"
Reply was 'STATUS=E,When=1445296756,Code=93,Msg=PGA 0 set failed: invalid clock: '0x0a02' data must be
 prefixed with an x,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => E
   [When] => 1445296756
   [Code ] => 93
   [Msg] => PGA 0 set failed: invalid clock: '0x0a02' data must be prefixed with an x
   [Description] => bfgminer 5.3.0
)

It appears that the leading '0' needs to be dropped from the hex frequency value, however:

Code:

C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,x0a02"
Reply was 'STATUS=S,When=1445296795,Code=92,Msg=PGA 0 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
   [STATUS] => S
   [When] => 1445296795
   [Code ] => 92
   [Msg] => PGA 0 set OK
   [Description] => bfgminer 5.3.0
)

I can successfully report an immediate increase in hash speed on the sticks once the command is issued.  Thanks again, looking forward to 5.4.0.  

Sounds like the "leading zero" is your problem.
There was never any expectation/support for one.
How can I improve documentation to make that clear?

I have two gekko compacs running on this particular machine and the rpc command only appears to have increased the frequency on one stick.  I replaced "cbm0" with "cbm1" to see if I could effect the other stick.  The command was accepted successfully, however, the second stick did not increase in hash rate.  Do I need to do something different to get the second stick to see the new frequency?

I forgot pgaset doesn't take a device specification like that. Really you need to identify them by number, so 0 and 1 instead of cbm0 and cbm1.

[Luke-Jr]

This is ready to be tested. Please download and test these binaries (or GitHub branch tmp40389 if you build from source).

How do we actually test this build? 

I am using your tmp40389 branch as I need to compile it for my WiFi router. The initialisation phase below looks the same to me.

Code:

 [2015-10-19 18:05:06] Timers: Using clock_gettime(CLOCK_MONOTONIC)
 [2015-10-19 18:05:06] Global quota greatest common denominator set to 1
 [2015-10-19 18:05:06] Global quota greatest common denominator set to 1
 [2015-10-19 18:05:06] Global quota greatest common denominator set to 1
 [2015-10-19 18:05:06] setrlimit: Soft fd limit not being changed from 1024 (FD_SETSIZE=1024; hard limit=4096)
 [2015-10-19 18:05:06] Started bfgminer 5.3.0-unknown
 [2015-10-19 18:05:06] Loaded configuration file /etc/bfgminer/bfgminer.conf
 [2015-10-19 18:05:06] lowlevel_scan: Found vcom device at dev_t:000000000000bc01 (path=/dev/ttyUSB1, vid=0000, pid=0000, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)
 [2015-10-19 18:05:06] lowlevel_scan: Found vcom device at dev_t:000000000000bc00 (path=/dev/ttyUSB0, vid=0000, pid=0000, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:voltage=x830
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:voltage=x830
 [2015-10-19 18:05:06] AMU: Applying rule antminer:voltage=x830: Unknown option: voltage
 [2015-10-19 18:05:06] AMU: Applying rule antminer:voltage=x830: Unknown option: voltage
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:clock=x0882
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:clock=x0882
 [2015-10-19 18:05:06] AMU: Applying rule antminer:clock=x0882: Unknown option: clock
 [2015-10-19 18:05:06] AMU: Applying rule antminer:clock=x0882: Unknown option: clock
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:timing=0.0154
 [2015-10-19 18:05:06] AMU: cgpu_set_defaults: Matched with set default: antminer:timing=0.0154
 [2015-10-19 18:05:06] (null): Init: mode=value read_timeout_ms=65 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] (null): Init: mode=value read_timeout_ms=65 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] AMU: Applied rule antminer:timing=0.0154
 [2015-10-19 18:05:06] AMU: Applied rule antminer:timing=0.0154
 [2015-10-19 18:05:06] antminer: Attempting to open /dev/ttyUSB0
 [2015-10-19 18:05:06] antminer: Attempting to open /dev/ttyUSB1
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB1
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB0
 [2015-10-19 18:05:06] antminer: Test succeeded at /dev/ttyUSB1: got 000187a2
 [2015-10-19 18:05:06] /dev/ttyUSB1: Init: mode=value read_timeout_ms=75 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] antminer: Test succeeded at /dev/ttyUSB0: got 000187a2
 [2015-10-19 18:05:06] /dev/ttyUSB0: Init: mode=value read_timeout_ms=75 limit=0ms Hs=1.540000e-11
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB1
 [2015-10-19 18:05:06] antminer: Work division not specified - autodetecting
 [2015-10-19 18:05:06] Acquired exclusive advisory lock on /dev/ttyUSB0
 [2015-10-19 18:05:06] antminer: Work division not specified - autodetecting
 [2015-10-19 18:05:06] antminer: Work division autodetection got 417c0f36 (=4)
 [2015-10-19 18:05:06] antminer: Work division autodetection got 417c0f36 (=4)
 [2015-10-19 18:05:06] Found AMU 0 at /dev/ttyUSB0
 [2015-10-19 18:05:06] Found AMU 1 at /dev/ttyUSB1
 [2015-10-19 18:05:06] AMU 0: Init: baud=115200 work_division=0 fpga_count=0
 [2015-10-19 18:05:06] AMU 1: Init: baud=115200 work_division=0 fpga_count=0
 [2015-10-19 18:05:06] Probing for an alive pool
.
.

This looks good, thanks.

[Luke-Jr]

I have one suggestion Luke, if you don't mind.

I have been trying different branches of your github. At some points (and actually just now), I am confused with the versions as all of them only show "bfgminer 5.3.0-unknown". I can differentiate them from the package versions as I can set them. But there is no way to know the version on the screenshot of the UI or debug log (unless I make sure to identify them from the log file name).

Would it be possible to include an indication of branch/tag/commit/whatever in the UI and debug log to differentiate between each version?

You must be doing something unusual to build BFGMiner.
That "5.3.0-unknown" usually has the git commit id for custom builds.
Are you perhaps downloading zips/tars from GitHub rather than using git itself to fetch?

[.anto.]

This looks good, thanks.

  I don't see any significant differences when I compared the debug logs from the HEAD and tmp40389 line by line, but you said "this looks good". Care to explain please?

Your tmp40389 has been running for more than 12 hours on my router as you can see below. And I saw you have commited some changes on the HEAD version (bfgminer branch). Are the changes related to the bug included in that commits?

[Luke-Jr]

This looks good, thanks.

  I don't see any significant differences when I compared the debug logs from the HEAD and tmp40389 line by line, but you said "this looks good". Care to explain please?

Your tmp40389 has been running for more than 12 hours on my router as you can see below. And I saw you have commited some changes on the HEAD version (bfgminer branch). Are the changes related to the bug included in that commits?

tmp40389 is 5.3.0 with only the intended fix for the issue.
So it doesn't have the accidental workaround (naming the compac driver correctly) that was in the main bfgminer branch.

[.anto.]

You must be doing something unusual to build BFGMiner.
That "5.3.0-unknown" usually has the git commit id for custom builds.
Are you perhaps downloading zips/tars from GitHub rather than using git itself to fetch?

Yes, perhaps I did. But I always use your Makefile for my OpenWRT 14.07 package build. The only differences are instead using the following

Code:

PKG_SOURCE_URL:=http://luke.dashjr.org/programs/bitcoin/files/$(PKG_NAME)/$(PKG_VERSION)/

I use the following for tmp40389 branch

Code:

PKG_SOURCE_URL:=git://github.com/luke-jr/bfgminer
PKG_SOURCE_VERSION:=tmp40389

Or I use the following for the HEAD version (bfgminer branch)

Code:

PKG_SOURCE_URL:=git://github.com/luke-jr/bfgminer
PKG_SOURCE_VERSION:=HEAD

And I don't do anything else a part from building it with the following command.

Code:

make package/bfgminer/{clean,compile,install}

Do you think there are some build environment variables that I missed to set?

Where is the version that is being displayed on the UI or spit out on the debug log, being set on?

[Luke-Jr]

You must be doing something unusual to build BFGMiner.
That "5.3.0-unknown" usually has the git commit id for custom builds.
Are you perhaps downloading zips/tars from GitHub rather than using git itself to fetch?

Yes, perhaps I did. But I always use your Makefile for my OpenWRT 14.07 package build. The only differences are instead using the following

Code:

PKG_SOURCE_URL:=http://luke.dashjr.org/programs/bitcoin/files/$(PKG_NAME)/$(PKG_VERSION)/

I use the following for tmp40389 branch

Code:

PKG_SOURCE_URL:=git://github.com/luke-jr/bfgminer
PKG_SOURCE_VERSION:=tmp40389

Or I use the following for the HEAD version (bfgminer branch)

Code:

PKG_SOURCE_URL:=git://github.com/luke-jr/bfgminer
PKG_SOURCE_VERSION:=HEAD

And I don't do anything else a part from building it with the following command.

Code:

make package/bfgminer/{clean,compile,install}

Do you think there are some build environment variables that I missed to set?

Where is the version that is being displayed on the UI or spit out on the debug log, being set on?

gen-version.sh builds version.h during make
I bet OpenWrt is cloning the git, then copying it somewhere else without the .git directory...
If so, you can probably fix it by generating version.h from/in that directory first.

If you do get a working OpenWrt-from-git, I'd be interested in merging the changes.

[.anto.]

gen-version.sh builds version.h during make
I bet OpenWrt is cloning the git, then copying it somewhere else without the .git directory...
If so, you can probably fix it by generating version.h from/in that directory first.

If you do get a working OpenWrt-from-git, I'd be interested in merging the changes.

As I always say, I am not a programmer. But it looks quite simple so I think I will fork your repository, try to work out what you suggested and pull request it when I manage to implement that.

[toptek]

LUke


will 5.4 stay in the S5 on reboot or do i have to find someone that knows how to compile one of bitmians images and replace cgminer or  learn it my self which im gonna do either way because i want to . just wondering how that's gonna work inside in a S5, btw, can't wait .



I'm about to buy a OpenWRT  switch/router and learn that as well . my verizon router model #  no one has a way of doing yet but the model it self can be done just not the batch # router i have  or id have it at OpenWR, i own that router.

[Luke-Jr]

will 5.4 stay in the S5 on reboot or do i have to find someone that knows how to compile one of bitmians images and replace cgminer or  learn it my self which im gonna do either way because i want to . just wondering how that's gonna work inside in a S5, btw, can't wait .

Someone will need to add it to a firmware image for it to stay permanently.

[.anto.]

gen-version.sh builds version.h during make
I bet OpenWrt is cloning the git, then copying it somewhere else without the .git directory...
If so, you can probably fix it by generating version.h from/in that directory first.

If you do get a working OpenWrt-from-git, I'd be interested in merging the changes.

Yes. You are right that OpenWRT clones your repository, packs it, copies it into the package source directory and deletes the whole cloned directory. However, I think the gen-version.sh does not generate the version of the latest git as it uses "git describe" command which takes the version base on the latest tag as below.

Code:

anto@hp8530w:~/Development$ git clone -b bfgminer https://github.com/luke-jr/bfgminer.git bfgminer-5.3.0
Cloning into 'bfgminer-5.3.0'...
remote: Counting objects: 47192, done.
remote: Compressing objects: 100% (87/87), done.
remote: Total 47192 (delta 48), reused 0 (delta 0), pack-reused 47105
Receiving objects: 100% (47192/47192), 36.94 MiB | 6.02 MiB/s, done.
Resolving deltas: 100% (30084/30084), done.
Checking connectivity... done.
anto@hp8530w:~/Development$ 
anto@hp8530w:~/Development$ cd bfgminer-5.3.0/
anto@hp8530w:~/Development/bfgminer-5.3.0$ 
anto@hp8530w:~/Development/bfgminer-5.3.0$ git describe
bfgminer-5.2.0-49-g3f30343
anto@hp8530w:~/Development/bfgminer-5.3.0$ 
anto@hp8530w:~/Development/bfgminer-5.3.0$ git log -1
commit 3f303439dd2ca3d329c7ac981e8d89cfc65438da
Merge: c000fc9 04e9c86
Author: Luke Dashjr <luke-jr+git@utopios.org>
Date:   Tue Oct 20 19:22:24 2015 +0000

    Merge branch 'bm1382clock' into bfgminer
anto@hp8530w:~/Development/bfgminer-5.3.0$ 

I think you need to decide Luke how you would set the version of the latest git. Perhaps something like including the commit SHA for instance bfgminer-5.3.0-3f30343 for the above example.