Bug 172102

Summary:	Package fails tests when built from source rpm
Product:	[Fedora] Fedora	Reporter:	Andy Halls <ajhalls>
Component:	tzdata	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	2005n-2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-11-02 12:39:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andy Halls 2005-10-31 15:09:09 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
build tests fails on checking timezone data.

In source package tzdata.tar.bz2 , in the top Makefile the environment variable TZDATA should be TZDIR to get glibc libs to use a different location for the zonedata.

Version-Release number of selected component (if applicable):
tzdata-2005m

How reproducible:
Always

Steps to Reproduce:
1.Have incorrect daylight saving data for test date in test program tst-timezone
2.build package from source
3.should fail at the second test stage


Actual Results:  Checking timezone Australia/Adelaide
tzname[0]: CST
tzname[1]: CST
daylight: 1
timezone: -34200
*** Timezone: Australia/Adelaide, tzname[0] is: CST but should be: ACST
*** Timezone: Australia/Adelaide, tzname[1] is: CST but should be: ACDT
tzname[0]: CST
tzname[1]: CST
daylight: 1
timezone: -34200
*** Timezone: Australia/Adelaide, tzname[0] is: CST but should be: ACST
*** Timezone: Australia/Adelaide, tzname[1] is: CST but should be: ACDT
 Finally with
TEST FAILED
make: *** [/usr/src/redhat/BUILD/tzdata-code/obj/tst-timezone] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.22990 (%install)




Expected Results:  Built RPMS & SRPMS

Additional info:

I suspect that this have been around for a while, a couple of years at least, as I remember catching this problem with fc1 but did not have the time to fix it.
(just copied the /etc/localtime file from a RH 8 or 9 system that I had done, no changes to zonedata required until this year).
I prefer to know that the system has switched to daylight saving so I create my own zonedata and tests.
Also fails the Asia/Tokyo tests even when the environment variable is set correctly. I have remove this test from my version.
I will check Japanese zone data at a later date and file another bug report if I find the problem.

Comment 1 Charles C. Van Tilburg 2005-11-01 14:29:46 UTC

Daylight savings time still has not switched for me

Comment 2 Andy Halls 2005-11-01 16:27:21 UTC

(In reply to comment #1)
> Daylight savings time still has not switched for me
Hi Charles
       A bit more information please.
   Your time zone and if you installed from SRPM or RPM update ?
Andy H

Comment 3 Charles C. Van Tilburg 2005-11-01 16:47:00 UTC

Well, upon further reflection, it does now show EST.  So it may be correct
in some way.  My /etc/localtime is EST5EDT.  

BUT, IF it was showing EDT before (I don't recall), then the 1 hour delta 
was definately not applied... does the system have to be running for that 
to happen?  If so, that should be fixed.  If not, did I switch it off 
somehow?

tzdata was installed via binary rpm originally and updated via binary update.

Comment 4 Andy Halls 2005-11-01 17:20:50 UTC

(In reply to comment #3)
> Well, upon further reflection, it does now show EST.  So it may be correct
> in some way.  My /etc/localtime is EST5EDT.  
> 
> BUT, IF it was showing EDT before (I don't recall), then the 1 hour delta 
> was definately not applied... does the system have to be running for that 
> to happen?  If so, that should be fixed.  If not, did I switch it off 
> somehow?
> 
> tzdata was installed via binary rpm originally and updated via binary update.
Hi Charles
   The only time *NIX's know is UTC so everything has to be be converted from
that based on either /etc/localtime or data from /usr/share/zoneinfo.
   Please check to see if /etc/localtime is a symbolic link ? if so where does
if point ?
   If not then what is the date/time on that file. ?
   Is it before you updated by the rpm ? if so then you will have to manually
copy the EST5EDT file from /usr/share/zoneinfo to /etc/localtime.
   Currently the tzdata update rpms do not appear to update that file only the
data in /usr/share/zoneinfo.

   run command zdump -v <timezone>, replace <timezone> with a valide timezaone,
and it will output for you the year, date, time and UTC offset of any changes
from when the data begins, usually around the year 1900, to the year 2038.

Andy H

Comment 5 Jakub Jelinek 2005-11-02 12:39:36 UTC

There was both a typo in the makefile (as you said), fixed by s/TZDATA/TZDIR/
and the testcase needed updating (imported newer version of the testcase from
glibc CVS HEAD).

Comment 6 Andy Halls 2005-11-02 13:25:50 UTC

(In reply to comment #5)
> There was both a typo in the makefile (as you said), fixed by s/TZDATA/TZDIR/
> and the testcase needed updating (imported newer version of the testcase from
> glibc CVS HEAD).

Good one , I will not ask the obvious ;)
Andy H