Report image versions

> * version of combined image (reported by system-image-cli --build)

This information now comes from `system-image-cli --info` in somewhat unstructured form, e.g.:

root@ubuntu-phablet:/# system-image-cli --info
current build number: 2
device name: grouper
channel: daily

* version of ubuntu rootfs image + dotted cdimage build
* version of android rootfs + jenkins build id (I guess)

This information must be available in the image somewhere, right?

* date of last update and possibly dates of these images

I can do the date of the last update. Where would dates of the images come from?

I'm thinking that there would be a DBus call such as .Info() which would return all this information in a structured way.

Date of last update > how about taking the latest of the dates of the version stamps? it's not technically the time it was applied, but the freshness of the image.

On Sep 04, 2013, at 04:39 PM, Loïc Minier wrote:

>Date of last update > how about taking the latest of the dates of the
>version stamps? it's not technically the time it was applied, but the
>freshness of the image.

What do you mean when you say "version stamps"? Do you mean the timestamp of
the downloaded files?

I'd much prefer to drive all this information explicitly from index.json data
or data laid down on the file system after an update.

What I really want to avoid is implicit semantics, such as that the image
description has any meaning (it currently contains things like "20130828.1"
which looks a lot like a date stamp and version number) or the file name of
the .tar.xz files (which contains similar information).

In summary: explicit is better than implicit. :)

Can we extend index.json to contain the dates? Or can we use the date stamp
(or contents) of a file included in the upgrade? I was planning on using the
date stamp of /etc/system-image/channel.ini falling back to /etc/ubuntu-build.

Similarly for the "version of ubuntu rootfs image" and "version of android
rootfs".

Note that /etc/system-image/channel.ini already has the latest build_number.
It probably wouldn't be difficult to add the dates and versions to this file.
What do you think Stephane?

I've now got the last update date working as described above.

See LP: #1220907 for what we're going to do on the server side.

On the client side, for -cli we'll just parse the version_detail field if it exists and pretty print the details. If it doesn't exist, we'll just suppress the output.

For -dbus, I will implement the .Info() method as previously described, even though some of that information is included in the UpdateAvailableStatus signal. (yay for duplication)

I'll ask Didier to decide whether he'd rather have a string returned for the version_detail and do the parsing himself, or whether he'd like the DBus API to return a dict-of-strings-to-strings.

On Wed, Sep 04, 2013, Barry Warsaw wrote:
> What do you mean when you say "version stamps"? Do you mean the timestamp of
> the downloaded files?

no, I meant the timestamp of /etc/ubuntu-build for instance (or of
/etc/system-image/channel.ini)

> I'd much prefer to drive all this information explicitly from index.json data
> or data laid down on the file system after an update.

That would work

> What I really want to avoid is implicit semantics, such as that the image
> description has any meaning (it currently contains things like "20130828.1"
> which looks a lot like a date stamp and version number) or the file name of
> the .tar.xz files (which contains similar information).
>
> In summary: explicit is better than implicit. :)

Yeah; I personally wanted us having to maintain yet another version
thing somewhere; just using a date from a file we've generated
server-side seemed a solid information about the time where the update
was generated.

> Can we extend index.json to contain the dates? Or can we use the date stamp
> (or contents) of a file included in the upgrade? I was planning on using the
> date stamp of /etc/system-image/channel.ini falling back to /etc/ubuntu-build.
>
> Similarly for the "version of ubuntu rootfs image" and "version of android
> rootfs".

Exactly!

> Note that /etc/system-image/channel.ini already has the latest build_number.
> It probably wouldn't be difficult to add the dates and versions to this file.
> What do you think Stephane?

WFM

--
Loïc Minier