[Debian GNUstep maintainers] Bug#837010: gnustep-base: FTBFS: Tests failures

[Eric Heintzmann]

> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
> > 
> > Testing NSXMLParser.m...
> > Running base/headers/NSXMLParser.m...
> > Passed test:     NSXMLParser.m:9 ... include of Foundation/NSXMLParser.h works
> > Completed file:  NSXMLParser.m
> > 
> > Testing NSZone.m...
> > Running base/headers/NSZone.m...
> > Passed test:     NSZone.m:9 ... include of Foundation/NSZone.h works
> > Completed file:  NSZone.m
> > 
> > Testing Unicode.m...
> > Running base/headers/Unicode.m...
> > Passed test:     Unicode.m:9 ... include of GNUstepBase/Unicode.h works
> > Completed file:  Unicode.m
> > debian/rules:166: recipe for target 'override_dh_auto_test' failed
>
> The full build log is available from:
>    http://people.debian.org/~lucas/logs/2016/09/06/gnustep-base_1.24.9-3_unstable.log
> <http://people.debian.org/%7Elucas/logs/2016/09/06/gnustep-base_1.24.9-3_unstable.log>
I can't reproduce the issue (with pdebuild on amd64)
but looking at your build log, I see a problem with your date and time zone:

>base/NSCalendarDate/test00.m:
>Failed test:     test00.m:107 ...
+dateWithString:calendarFormat:locale: handles Africa/Addis_Ababa
>Failed test:     test00.m:246 ... date check with 2002-03-31 01:30:00
>Failed test:     test00.m:261 ... date check with 2002-03-31 01:30:00
>Failed test:     test00.m:265 ... date check with 2002-03-31 00:30:00
>Failed test:     test00.m:422 ... date year calculation preserves timezone
>
>base/NSCalendarDate/test02.m:
>Failed test:     test02.m:173 ... %Z format works in description
>Failed test:     test02.m:177 ... %z format works in description
>Failed test:     test02.m:197 ... %H%M format works in description
>
>base/NSDateFormatter/general.m:
>Failed test:       general.m:56 ... EST time zone is correctly
accounted for.
>
>
>base/NSTimeZone/create.m:
>Failed test:     create.m:33 ... +timeZoneWithAbbreviation works
>Failed test:     create.m:37 ... +timeZoneWithName works
>
>base/NSTimeZone/use.m:
>Failed test:     use.m:57 ... can calculate next DST transition
>Failed test:       use.m:92 ... Returns correct Daylight Saving offset.
>Failed test:       use.m:95 ... Returns correct Daylight Saving offset.


>Failed test:     test00.m:107 ...
+dateWithString:calendarFormat:locale: handles Africa/Addis_Ababa
>
>Failed test:     test00.m:261 ... date check with 2002-03-31 01:30:00
>Failed test:     test00.m:265 ... date check with 2002-03-31 00:30:00
>
>Failed test:     test00.m:422 ... date year calculation preserves timezone
>
>Failed test:     test02.m:173 ... %Z format works in description
>Failed test:     test02.m:177 ... %z format works in description
>
>Failed test:     test02.m:197 ... %H%M format works in description
>
>Failed test:       general.m:56 ... EST time zone is correctly
accounted for.
>
>Failed test:     create.m:33 ... +timeZoneWithAbbreviation works
>Failed test:     create.m:37 ... +timeZoneWithName works
>
>Failed test:       use.m:92 ... Returns correct Daylight Saving offset.
>Failed test:       use.m:95 ... Returns correct Daylight Saving offset.

There is also a recurrent message:

>Unable to create time zone for name: 'Etc/UTC'
>(source '(null)').
>
>You can override the timezone name by setting the 'Local Time Zone'
>NSUserDefault via the 'defaults' command line utility, a Preferences
>application, or some other utility.
>eg "defaults write NSGlobalDomain 'Local Time Zone' 'Africa/Nairobi'"
>See '(null)'
>for the standard timezones such as 'GB-Eire' or 'America/Chicago'.
>2016-09-06 23:03:53.983 runtime[30247:30247] Using time zone with
absolute offset 0.