version and date incorrectly reported re update info

[phillxnet]

The indicated Rockstor package version can get 'confused' with the most recent version available. This leads to inaccuracies re user indicators based on installed package version/build date and the presence or otherwise of the 'up arrow' to indicate available updates. And given the package date is also set incorrectly (via a fail over) we are inadvertently displaying all known changes in our "List of changes in this update" rather than only those associated with the interim package versions.

[phillxnet]

I am currently working on this issue and have fixed package version indication / retrieval and now looking at the change log element as this is, as per uncommitted changes, blank.

[phillxnet]

A related component of this issue is that recent stable package releases appear to have incorrect dates within their changelog:

yum changelog 2017-June-06 rockstor
...
Listing changelogs since 2017-06-06

==================== Installed Packages ====================
rockstor-3.9.2-3.x86_64                  installed
* Mon Nov  6 12:00:00 2017 Suman Chakravartula <suman@rockstor.com>
...
==================== Available Packages ====================
rockstor-3.9.2-4.x86_64                  Rockstor-Stable
* Mon Nov  6 12:00:00 2017 Suman Chakravartula <suman@rockstor.com>

So the installed 3.9.2-3 and available package (3.9.2-4) are both down as having a changelog dated 6th November. Hence the yum changelog, which keys off of these dates returns nothing currently when fed with the otherwise correct:

yum changelog 2017-Dec-06 rockstor

where 2017-Dec-06 is derived from + 1 day of buildtime as retrieved by the now fixed in pending pr
rpm_build_info() which now gets it's date from:

yum info installed -v rockstor

The consequence of this is that even though there are changelogs available, although ver 3.9.2-4 has not been updated, they are not currently listed due to the above embedded date caveat within the rpm's themselves.

Hard wiring the date var within system/pkg_mgmt.py/update_check() to for example '2017-Nov-01' (ie before our installed and now successfully retrieved builddate) proves we do parse successfully when the relevant dates are present within the rpm's themselves.

yum changelog 2017-Nov-01 rockstor

==================== Available Packages ====================
rockstor-3.9.2-4.x86_64                  Rockstor-Stable
* Mon Nov  6 12:00:00 2017 Suman Chakravartula <suman@rockstor.com>
failed to start rockstor hdparm settings #1752 @phillxnet
no drive name on custom smart options page #1756 @phillxnet
...

with the associated UI component for a system that has rockstor-3.9.2-3:
Buildtime "Tue Dec 5 13:34:06 2017"
installed we have the associated changelog:

ie we now have the up arrow, correct reporting of the installed version and, with the hard wired date to promote any change log at all, the same changelog as is presented at the command line.

Obviously we also need to adapt change log entries within future packages to reflect the new hot-fix releases.

[phillxnet]

Pull request to follow shortly.

[phillxnet]

Note that if you are affected by this issue then the following command run as root should update your system

yum update

Please be patient for this command to end as there may be many packages to update.
There after the Web-UI element should indicate the installed version / available versions as intended.