DBus API reports meaningless id

[Loïc Minier]

Hi,

system-image-dbus reports the build number from the contents of /etc/ubuntu-build which is a meaningless counter incremented from zero at the beginning of the month.

(I hate this id BTW :-)

The DBus API should report something more meaningful, perhaps the date of /etc/ubuntu-build or the contents of some other file.

Cheers,

[Barry Warsaw (barry)]

I can't really think of anything better, except that I want to keep the general approach, which is to say, the local identifier should come from a file laid down by a package, and the target identifier should come from the server.

Build numbers are rarely human friendly. ;)

[Loïc Minier (lool)]

So proposal:
* use stat() on the file to get a meaningful date and display that (more meaningful to an end-user)
* include build id between parenthesis, but split it to be less confusing

So instead of:
20130800
show:
2013/08/01 13:34 (201308.00)

[Barry Warsaw (barry)]

On Aug 02, 2013, at 02:54 PM, Loïc Minier wrote:

>* use stat() on the file to get a meaningful date and display that (more
>meaningful to an end-user)

Would that show the date the update was applied, or the actual release date of
the last upgrade? Also, this may not provide a meaningful reference point if
we can't use the same information regarding the target build that the upgrade
will leave you in. In the latter case, currently *all* we know is the build
number.

>* include build id between parenthesis, but split it to be less confusing
>
>So instead of:
>20130800
>show:
>2013/08/01 13:34 (201308.00)

I do like putting the build number in parentheses. Many OSes/applications do
this with even more cryptic build numbers than ours. ;)

[Loïc Minier (lool)]

On Fri, Aug 02, 2013, Barry Warsaw wrote:
> >* use stat() on the file to get a meaningful date and display that (more
> >meaningful to an end-user)
> Would that show the date the update was applied, or the actual release date of
> the last upgrade? Also, this may not provide a meaningful reference point if
> we can't use the same information regarding the target build that the upgrade
> will leave you in. In the latter case, currently *all* we know is the build
> number.

stat() should show the date the upgrade was assembled on the server (I
guess it's part of the version tarball. The recovery unpacking should
preserve timestamps (or it's a bug we should fix).

I don't understand your second point

--
Loïc Minier

[Barry Warsaw (barry)]

In email, stgraber suggests using <device>-<channel>-<buildnumber>, e.g. mako-daily-20130700

I like that, and it would be easy to add.

[Barry Warsaw (barry)]

lool suggests in irc that `system-image-cli --build` would print these numbers.

[Oliver Grawert (ogra)]

the rootfs stamp was now moved from /var/log/installer/media-info to /etc/media-info

[Barry Warsaw (barry)]

I've marked this as a duplicate of #1215959 since I think resolution of that bug will magically solve this one too. If you disagree, please un-dupe and explain! :)