* [PATCH] initscripts: Properly handle new timestamp format
@ 2012-03-01 14:43 Gary Thomas
2012-03-01 14:59 ` Richard Purdie
0 siblings, 1 reply; 10+ messages in thread
From: Gary Thomas @ 2012-03-01 14:43 UTC (permalink / raw)
To: openembedded-core
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 <gary@mlbassoc.com>
---
.../initscripts/initscripts-1.0/bootmisc.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh b/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
index 20ec0a0..383de82 100755
--- a/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
+++ b/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
@@ -70,8 +70,8 @@ if test -e /etc/timestamp
then
SYSTEMDATE=`date -u +%4Y%2m%2d%2H%2M`
read TIMESTAMP < /etc/timestamp
- if [ ${TIMESTAMP} -gt $SYSTEMDATE ]; then
- date -u $TIMESTAMP
+ if [ ${TIMESTAMP%????} -gt ${SYSTEMDATE%????} ]; then
+ date -u ${TIMESTAMP#????}${TIMESTAMP%????????}
/etc/init.d/hwclock.sh stop
fi
fi
--
1.7.7.6
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] initscripts: Properly handle new timestamp format
2012-03-01 14:43 [PATCH] initscripts: Properly handle new timestamp format Gary Thomas
@ 2012-03-01 14:59 ` Richard Purdie
2012-03-01 15:11 ` Gary Thomas
0 siblings, 1 reply; 10+ messages in thread
From: Richard Purdie @ 2012-03-01 14:59 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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 <gary@mlbassoc.com>
> ---
> .../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?
Cheers,
Richard
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] initscripts: Properly handle new timestamp format
2012-03-01 14:59 ` Richard Purdie
@ 2012-03-01 15:11 ` Gary Thomas
2012-03-01 15:27 ` Gary Thomas
0 siblings, 1 reply; 10+ messages in thread
From: Gary Thomas @ 2012-03-01 15:11 UTC (permalink / raw)
To: openembedded-core
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<gary@mlbassoc.com>
>> ---
>> .../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.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] initscripts: Properly handle new timestamp format
2012-03-01 15:11 ` Gary Thomas
@ 2012-03-01 15:27 ` Gary Thomas
2012-03-01 15:44 ` Richard Purdie
2012-03-01 16:01 ` Otavio Salvador
0 siblings, 2 replies; 10+ messages in thread
From: Gary Thomas @ 2012-03-01 15:27 UTC (permalink / raw)
To: openembedded-core
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<gary@mlbassoc.com>
>>> ---
>>> .../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.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] initscripts: Properly handle new timestamp format
2012-03-01 15:27 ` Gary Thomas
@ 2012-03-01 15:44 ` Richard Purdie
2012-03-01 15:52 ` Gary Thomas
2012-03-01 16:01 ` Otavio Salvador
1 sibling, 1 reply; 10+ messages in thread
From: Richard Purdie @ 2012-03-01 15:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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<gary@mlbassoc.com>
> >>> ---
> >>> .../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 :(.
Cheers,
Richard
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] initscripts: Properly handle new timestamp format
2012-03-01 15:44 ` Richard Purdie
@ 2012-03-01 15:52 ` Gary Thomas
2012-03-01 16:04 ` Otavio Salvador
0 siblings, 1 reply; 10+ messages in thread
From: Gary Thomas @ 2012-03-01 15:52 UTC (permalink / raw)
To: openembedded-core
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<gary@mlbassoc.com>
>>>>> ---
>>>>> .../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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] initscripts: Properly handle new timestamp format
2012-03-01 15:27 ` Gary Thomas
2012-03-01 15:44 ` Richard Purdie
@ 2012-03-01 16:01 ` Otavio Salvador
1 sibling, 0 replies; 10+ messages in thread
From: Otavio Salvador @ 2012-03-01 16:01 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, Mar 1, 2012 at 12:27, Gary Thomas <gary@mlbassoc.com> wrote:
> 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.
This is indeed the better solution.
Please send an updated patch in meanwhile so Richard can apply it once
he has some time and restore the right behavior.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] initscripts: Properly handle new timestamp format
2012-03-01 15:52 ` Gary Thomas
@ 2012-03-01 16:04 ` Otavio Salvador
2012-03-01 16:06 ` Gary Thomas
0 siblings, 1 reply; 10+ messages in thread
From: Otavio Salvador @ 2012-03-01 16:04 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, Mar 1, 2012 at 12:52, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2012-03-01 08:44, Richard Purdie wrote:
>> 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.
So we can have compat and 64-bit math and have it properly behaving?
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] initscripts: Properly handle new timestamp format
2012-03-01 16:04 ` Otavio Salvador
@ 2012-03-01 16:06 ` Gary Thomas
2012-03-02 6:15 ` Lauri Hintsala
0 siblings, 1 reply; 10+ messages in thread
From: Gary Thomas @ 2012-03-01 16:06 UTC (permalink / raw)
To: openembedded-core
On 2012-03-01 09:04, Otavio Salvador wrote:
> On Thu, Mar 1, 2012 at 12:52, Gary Thomas<gary@mlbassoc.com> wrote:
>> On 2012-03-01 08:44, Richard Purdie wrote:
>>> 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.
>
> So we can have compat and 64-bit math and have it properly behaving?
Yes, I believe so. I'll work up the patch and test it now.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] initscripts: Properly handle new timestamp format
2012-03-01 16:06 ` Gary Thomas
@ 2012-03-02 6:15 ` Lauri Hintsala
0 siblings, 0 replies; 10+ messages in thread
From: Lauri Hintsala @ 2012-03-02 6:15 UTC (permalink / raw)
To: openembedded-core
On 03/01/2012 06:06 PM, Gary Thomas wrote:
>>> 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.
>>
>> So we can have compat and 64-bit math and have it properly behaving?
>
> Yes, I believe so. I'll work up the patch and test it now.
It might be very helpful for other developers if 64-bit math requirement
of busybox would be documented somewhere.
BR,
Lauri
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-03-02 6:24 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-01 14:43 [PATCH] initscripts: Properly handle new timestamp format Gary Thomas
2012-03-01 14:59 ` Richard Purdie
2012-03-01 15:11 ` Gary Thomas
2012-03-01 15:27 ` Gary Thomas
2012-03-01 15:44 ` Richard Purdie
2012-03-01 15:52 ` Gary Thomas
2012-03-01 16:04 ` Otavio Salvador
2012-03-01 16:06 ` Gary Thomas
2012-03-02 6:15 ` Lauri Hintsala
2012-03-01 16:01 ` Otavio Salvador
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox