timezone_data: update to version 2023c

[OscarL]

Set make flags also on BUILD(), otherwise tzselect ended up with the wrong location for TZDIR.

Previous version failed with:
/bin/tzselect: time zone files are not set up correctly

Now it finds the files ok, but trying to use it further causes /bin/date to crash around 7 times in a row (?!).

> zdump -v America/Buenos_Aires also works now, while previously failed with:

America/Buenos_Aires: No such file or directory,

or with:

> ln -s /boot/system/data/zoneinfo/America/Buenos_Aires /etc/localtime
> zdump -v /etc/localtime
/etc/localtime: No error

Now the latter also works OK.

[OscarL]

Opening as "Draft" due to the mentioned /bin/date crashes, and because it still includes a libtz.a file (but no headers for it?).

Not sure what to do with that. CC: @Begasus, @korli.

[korli]

/bin/date is from coreutils, what's the relation? libtz.a is also provided without headers by arch linux. Why is there a lib:libtz PROVIDES btw?

[OscarL]

/bin/date is from coreutils, what's the relation?

tzselect (a bash script) calls date in several places. I'm assuming some of the parameters it sets just cause /bin/date to crash with.

		state: Exception (General protection fault)

		Frame		IP			Function Name
		-----------------------------------------------
		0x7fdd84b03340	0x10fad76f8f0	u_strToUTF8WithSub_66 + 0x140 
			Disassembly:
				u_strToUTF8WithSub_66:
				0x0000010fad76f7b0:               55  push %rbp
				0x0000010fad76f7b1:           4c63d6  movsxd %esi, %r10

[...edited for brevity...]

			Frame memory:
				[0x7fdd84b032f0]  .%......h3......   e6 25 00 8f f0 ef bf ff 68 33 b0 84 dd 7f 00 00
				[0x7fdd84b03300]  .4.......8......   10 34 b0 84 dd 7f 00 00 00 38 b0 84 dd 7f 00 00
				[0x7fdd84b03310]  .7..............   e0 37 b0 84 dd 7f 00 00 03 00 00 00 00 00 00 00
				[0x7fdd84b03320]  tamarca.h3......   74 61 6d 61 72 63 61 00 68 33 b0 84 dd 7f 00 00
				[0x7fdd84b03330]  .7.......'v.....   a0 37 b0 84 dd 7f 00 00 02 27 76 ad 0f 01 00 00
		0x7fdd84b037b0	0x10fad7626fd	icu_66::UnicodeString::toUTF8(icu_66::ByteSink&) const + 0xcd 
		0x7fdd84b03880	0x1095e41234f	BPrivate::Libroot::ICUTimeConversion::TZSet(char const*, char const*) + 0x21f 
		0x7fdd84b038b0	0x1095e40fb89	BPrivate::Libroot::ICULocaleBackend::TZSet(char const*, char const*) + 0x29 
		0x7fdd84b039e0	0x111383a451c	tzset + 0xcc 
		0x7fdd84b03a00	0x111383a4563	localtime_r + 0x13 
		0x7fdd84b03a20	0x3259946dbd	localtime_rz + 0x2d 
		0x7fdd84b03ab0	0x325993bf64	show_date + 0x34 
		0x7fdd84b03bd0	0x325993bb1a	main + 0x6ca 
		0x7fdd84b03c00	0x325993bf1a	_start + 0x3a 
		0x7fdd84b03c40	0x1ccfda1fae3	runtime_loader + 0x103 
		00000000	0x7fffff698258	commpage_thread_exit + 0 

Why is there a lib:libtz PROVIDES btw?

Left over from the original recipe, and my lack of experience, as usual.

[OscarL]

@korli:

Found what causes /bin/date to crash.

tzselect calls (eight times in a loop, at line 638):

		TZdate=`LANG=C TZ="$TZ_for_date" date`

At that point, $TZ_for_date contains the path to a timezone file (depending on user choice).

The following works from Terminal:

> LANG=C TZ="/system/data/zoneinfo/America/Argentina/Buenos_Aires" date

But tzselect is doing:

> LANG=C TZ="/packages/timezone_data-2023c-1/.self/data/zoneinfo/America/Argentina/Buenos_Aires" date

And that crashes /bin/date (saved report looks like an exact match to my previous comment).

While

> LANG=C TZ="/packages/timezone_data-2023c-1/.self/data/zoneinfo/America" date

does not crashes.

---

This is as far as my skills go so... HALP!? :-D

[korli]

@korli:

Looks like it would deserve an Haiku bug report...

[OscarL]

Looks like it would deserve an Haiku bug report...

For reference, done as: https://dev.haiku-os.org/ticket/18598

[OscarL]

The /bin/date crash should be fixed on nightlies after hrev57356.

[korli]

What's left with this PR?

[OscarL]

Nothing else from my end.

[Begasus]

Build failure on 32bit: https://build.haiku-os.org/buildmaster/master/x86_gcc2/logviewer.html?buildruns/5306/builds/82206.log

[OscarL]

Yup. Seems I misremembered having tested it on 32 bits.

I have a working recipe now, after moving it to _x86. But I'm a bit concerned about having to change the Python recipes (3.11/3.12) that REQUIRES timezone_data.

What are the alternatives here?

1- Adding:

if [ "$targetArchitecture" = x86_gcc2 ]; then
	REPLACES="
		timezone_data
	"
fi

Would this be enough for now until the Python recipes are changed to require timezone_data$secondaryArch?

2- Adding

if [ "$targetArchitecture" = x86_gcc2 ]; then
	PROVIDES+="
		timezone_data
	"
fi

This shouldn't require changes on other recipes, but as there's a lib/x86/libtz.a file... this sounds a bit weird.

3- Split the package into pure data (timezones only, any arch?), and another with _tools / _devel?

Three packages for this seems excessive, but not sure about what to call a package that includes both the cmd:s + libtz.a.

4- Fix the problem with that restrict, and leave ARCHITECTURE="all".

I don't feel comfortable touching the defines on private.h, so... if others find a proper fix, great!

5- Something else?

@Begasus. @korli, I'll follow your expertise here.

[korli]

Seems, for C89, a macro needs to be defined:
https://github.com/eggert/tz/blob/dd83b3a2b5afb4b1c296aede092785830487adc9/NEWS#L118

[OscarL]

Thanks @korli!

Adding CFLAGS="-DPORT_TO_C89" to the make call did the trick on 32 bits. Will re-check on 64 bits later today, and open a PR with that, if everything looks fine.