[lfs-support] e2fsprogs test failures on version SVN-20120806

Bruce Dubbs bruce.dubbs at gmail.com
Fri Aug 17 08:51:06 PDT 2012


Ken Moffat wrote:
> On Fri, Aug 17, 2012 at 11:42:26AM +0300, Markku Pesonen wrote:
>>
>> I think the problem may lie in the way LFS installs the tzdata package.
>> Glibc 2.15 (and earlier) installed timezone data without leap second
>> information in /usr/share/zoneinfo and /usr/share/zoneinfo/posix (why
>> two copies of the same data, I don't know). Timezone data with leap
>> seconds was installed in /usr/share/zoneinfo/right. At least Debian
>> seems to do it that way too. LFS only installs timezone data with leap
>> seconds in /usr/share/zoneinfo.
>>
>   Thanks for the pointer.  I noticed the following in glibc's
> Makeconfig yesterday, but because glibc-2.15 had the same, I was
> none the wiser :
>
> # What to use for leap second specifications in compiling the
> # default
> # timezone files.  Set this to `/dev/null' for no leap second
> # handling as
> # 1003.1 requires, or to `leapseconds' for proper leap second
> # handling.
> # Both zone flavors are always available as `posix/ZONE' and
> # `right/ZONE'.
> # This variable determines the default: if it's `/dev/null',
> # ZONE==posix/ZONE; if it's `leapseconds', ZONE==right/ZONE.
> ifndef leapseconds
> leapseconds = /dev/null
> endif
>
>   I'll take a look at how debian do things.

On a fresh LFS svn system, I can do

$ TZ=EST date;date;date -u
Thu Aug 16 23:56:26 EST 2012
Fri Aug 17 04:56:26 GMT 2012
Fri Aug 17 04:56:51 UTC 2012

My understanding is that POSIX ignores leap seconds, and TZ settings 
does not.  The above seems correct to me, but I'm not 100% sure.  The 
above is with a /etc/localtime setting of '/usr/share/zoneinfo/GMT' -> 
'/etc/localtime'.  Without that, the 'date' command reverts to UTC.

   -- Bruce



More information about the lfs-support mailing list