bruce.dubbs at gmail.com
Mon Aug 20 08:12:35 PDT 2012
Matt Burgess wrote:
> On Sun, 2012-08-19 at 18:09 -0500, Bruce Dubbs wrote:
>> Ken Moffat wrote:
>>> On Sun, Aug 19, 2012 at 12:12:20PM -0500, Bruce Dubbs wrote:
>>>> You suggested separating the time zone data into a separate page.
>>>> One problem is that the tarball does not expand into a separate directory.
>>>> One place where this can cause a problem is with jhalfs. What do you
>>>> think about repackaging the data so it expands to a directory
>>>> tzdata2012e/ and storing it on anduin?
>>>> The other option is to hack jhalfs.
>>> Earlier, I think I said something like " I'm fixing my buildscripts" -
>>> that was caused by this. Jhalfs is, as you know, not something I use.
>> Yes, I knew that.
>>> If it's easier to repackage tzdata, we can note why we are doing that.
>>> Most changes will be known well in advance.
>> Well it was only a matter of:
>> mkdir tzdata2012e-lfs
>> cd tzdata2012e-lfs
>> tar -xf ../tzdata2012e.tar.gz
>> cd ..
>> tar -jcf tzdata2012e-lfs.tar.bz2 tzdata2012e-lfs
>> The file is now at
>> I added the -lfs to the directory name just to prevent confusion with
>> the upstream package.
>> I think this is better than trying to use a different procedure than the
>> "unpack; cd; build" process we use in all the other packages.
> I must admit, I really don't like putting 'lfs' in the tarball name.
I didn't really like it either, but ideally the extracted directory
should be the same name as the tarball.
> Can't we still use the same 'unpack; cd; build' process, if we add a
> note that one needs to use tar's --transform option? The following
> works for me:
> tar xf ../tzdata2012c.tar.gz --transform 's|^|tzdata-2012c/|'
Where are you located if you are extracting ../tzdata2012c.tar.gz?
> That would still need an 'adjustment' :-) to jhalfs but shouldn't be too
> ugly and/or onerous.
If we are going to update jhalfs, then we only need:
tar -xf ../tzdata2012e.tar.gz
And a big note saying the extraction procedures are different
> Additionally, this packaging issue should be reported upstream. I don't
> mind doing that, if no one's got around to it yet?
A change in upstream packaging would be ideal.
More information about the lfs-dev