Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Jul 2014 01:15:55 +0400
From: Solar Designer <>
Subject: tzdata


I thought I'd quickly update our tzdata package today, but it turned out
to be a bit trickier than I had time for.

Apparently, our current tzdata-base-0.tar.bz2 (with glibc-derived files)
is no longer exactly right for tz{code,data}2014e.tar.gz.  Simply
dropping those new upstream tarballs in results in a failed build (it
looks for tzselect.ksh in a wrong directory, or the current directory
might be wrong - I didn't investigate this for real).

So I thought: rather than debug/update tzdata-base-0.tar.bz2, why don't
we use upstream tzcode's Makefile to build this package, dropping our
tzdata-base?  I briefly tried doing just that - spec file attached.
It builds, but the resulting tzdata RPM differs from what we had before
in that it doesn't contain /usr/share/zoneinfo/posix and
/usr/share/zoneinfo/right.  Overall, it contains about 600 files,
whereas our current package contains about 1800 (most of them are
hard-links, though), with this discrepancy being almost exclusively from
missing "posix" and "right".  Another change is that our current tzdata
is (probably) built with glibc's zic (installed on the system), whereas
after switching to tzcode's Makefile the build (probably) uses tzcode's
own copy of zic.  I don't know if they're fully compatible or not.

I am not committing this update yet.  I'd appreciate comments from
someone more knowledgeable.  Dmitry, what are your plans for updating
tzdata in ALT Linux?  Can we use the same approach for ALT Linux and
Owl, and can it be a simpler approach like what I tried above?

tzcode's Makefile has been much improved recently by Paul Eggert.
I guess this is what broke compatibility with our old tzdata-base, but
it's also a reason why we might not need tzdata-base anymore.  For
example, there's now proper DESTDIR support in tzcode's Makefile.

While we're at it, another detail I noticed is that our glibc's
timezone/Makefile has a race condition when building with -j, which is
put in MAKEFLAGS on Owl when we use "make PACKAGE=glibc".  This started
failing for me after a kernel upgrade on a quad-core machine; setting
PROCESSORS=3 in makes the build succeed.  Specifically:

tzbases := africa antarctica asia australasia europe northamerica \
           southamerica etcetera factory \
           solar87 solar88 solar89
tzlinks := backward systemv
tzfiles := $(tzbases) $(tzlinks)

does not ensure that $(tzbases) are built before $(tzlinks) are started
being built, which results in:

/usr/src/world/rpm-work-1/BUILD/glibc-2.3.6/build-x86_64-linux/timezone/zic: Can't link from /usr/src/world/rpm-work-1/buildroot/usr/share
/zoneinfo/right/America/Indianapolis to /usr/src/world/rpm-work-1/buildroot/usr/share/zoneinfo/right/SystemV/EST5: No such file or directory
make[3]: *** [/usr/src/world/rpm-work-1/buildroot/usr/share/zoneinfo/right/SystemV/AST4ADT] Error 1

BTW, a quick Google web search finds that this was a common problem for
people building LFS.

Since we're not packaging glibc's zoneinfo anyway, I tried patching the
tzfiles line to be just:

tzfiles := factory

but then it failed on needing "America/New York" for posixrules.  Maybe
this would work:

tzfiles := northamerica factory

(I didn't try.)  Or maybe we should disable more of the zoneinfo build
(but we do need the factory timezone as part of glibc package).

I don't know if this glibc timezone build race is already fixed upstream
or not.  At first glance, it is not - but somehow there are no recent
complaints from LFS users, so maybe it went away with some other change.


View attachment "tzdata.spec" of type "text/plain" (1564 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.