On 2012-03-01 08:44, Richard Purdie wrote:
On Thu, 2012-03-01 at 08:27 -0700, Gary Thomas wrote:
On 2012-03-01 08:11, Gary Thomas wrote:
On 2012-03-01 07:59, Richard Purdie wrote:
On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote:
Recent changes have attempted to make consistant use of /etc/timestamp
In particular
5aab665 initscripts: Make /etc/timestamp consistent again.
173a48f image.bbclass: Ensure timestamp matches format used in initscripts 
after recent changes

This new format can cause problems as the value is too large for
most [32 bit] machines. Work around this by only comparing the
YYYYMMDD portion (which does fit in 32 bits). Also, the new format
is not directly compatible with the 'date' command line, so it
must be reformatted for use.

Signed-off-by: Gary Thomas<[email protected]>
---
.../initscripts/initscripts-1.0/bootmisc.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

I merged the changes to busybox in relation to this. Is this patch still
needed?

Let me check - I didn't see the related busybox change.


I missed the busybox change because there was no PR bump :-(

The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that
now 'date' from busybox works one way and 'date' from coreutils works another.

Using coreutils:

root@cobra8148p81:~# date 201203011520
date: invalid date `201203011520'
root@cobra8148p81:~# date 030115202012
Thu Mar  1 15:20:00 UTC 2012
root@cobra8148p81:~# ls -l /bin/date
lrwxrwxrwx 1 root root 14 Mar  1 15:14 /bin/date ->  date.coreutils

Using busybox:

root@cobra8148p81:~# ln -s /bin/busybox /tmp/date
root@cobra8148p81:~# /tmp/date 201203011520
Thu Mar  1 15:20:00 UTC 2012

I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back
on along with my reformatting change.

I can make an updated patch if you agree.

Is this going to cause us a problem in real world usage? I'd hope in the
general case we use standard formatting?

I have to admit I'm getting more than a little frustrated with what
seems like a continual set of changes bouncing this format around in
different directions :(.

I agree and I'm sorry I missed this in my first change - I was just
trying to make the time stamps be consistent.

As far as I can recall (which is a really long time), 'date' has always
wanted the format MMDDHHmm[YYYY], so I think that's what we should expect.
That format doesn't compare easily which is why the timestamp was changed
(not by me) to a more ISO standard YYYYMMDDHHmm.  If busybox has 64-bit
math enabled, then this can be compared with no problems, it just has
to be munged into the format 'date' wants.


--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to