Greetings,
The sole purpose of this thread is to bring attention to https://bugzilla.redhat.com/show_bug.cgi?id=1646930
Unreliable time on the system is a daily annoyance that will be easily fixed by aligning the Fedora version with the upstream's. Could someone ping the package maintainer? Also, a proven packager could just initiate the build.
Thanks.
On Fri, Nov 09, 2018 at 06:57:33PM -0000, E.N. virgo wrote:
Greetings,
The sole purpose of this thread is to bring attention to https://bugzilla.redhat.com/show_bug.cgi?id=1646930
Unreliable time on the system is a daily annoyance that will be easily fixed by aligning the Fedora version with the upstream's. Could someone ping the package maintainer? Also, a proven packager could just initiate the build.
Adding the package maintainer to CC.
The last update in Rawhide was July and there have been two upstream releases since then. I tend to agree with you that we should stick pretty closely to upstream for this important database.
Although I'm a PP I'm not sure that I am confident enough to update such a key central package. However if there's no movement in a few days then I guess myself or another PP can help out.
Rich.
The sole purpose of this thread is to bring attention to https://bugzilla.redhat.com/show_bug.cgi?id=1646930
No doubt some of the delay is due to compatibility issues with other packages that consume timezone data. Upstream changed the data format: ===== $ rpm -q --changelog tzdata-2018e-1.fc*.noarch * Wed May 16 2018 [tzdata-owner@fedoraproject.org] - 2018e-1 - Rebase to tzdata-2018e - North Korea changed from UTC+8:30 to UTC+9 on May 5, 2018. - In this update, the upstream project now defaults to using the "vanguard" data implementation which includes negative DST offsets. However, we are continuing to provide the "rearguard" format for data which does not use negative DST offsets to provide better compatibility with existing tools. We intend to transition to the "vanguard" data implementation in the future. =====
Unreliable time on the system is a daily annoyance that will be easily fixed by aligning the Fedora version with the upstream's.
Aligning with upstream would update tzdata itself, but dealing with the compatibility issues requires work that contradicts the claim of "easily fixed."
It is reasonable to infer that the untimeliness of tzdata-2018g-1 affects you personally; so why not fix it for yourself? rpmbuild is not that hard to grok. Then you could report on the compatibility issues. You might even become a maintainer :-)
On 11/11/2018 00:10, John Reiser wrote:
The sole purpose of this thread is to bring attention to https://bugzilla.redhat.com/show_bug.cgi?id=1646930
No doubt some of the delay is due to compatibility issues with other packages that consume timezone data. Upstream changed the data format: ===== $ rpm -q --changelog tzdata-2018e-1.fc*.noarch
- Wed May 16 2018 [tzdata-owner@fedoraproject.org] - 2018e-1
- Rebase to tzdata-2018e
- North Korea changed from UTC+8:30 to UTC+9 on May 5, 2018. - In this update, the upstream project now defaults to using the "vanguard" data implementation which includes negative DST offsets. However, we are continuing to provide the "rearguard" format for data which does not use negative DST offsets to provide better compatibility with existing tools. We intend to transition to the "vanguard" data implementation in the future. =====
Fedora had already switched to the new format for F29:
https://fedoraproject.org/wiki/Changes/TZDATA-VANGUARD
That bug is asking for 2018g - we already have 2018e where the format changed.
Tom
On 09. 11. 18 19:57, E.N. virgo wrote:
Greetings,
The sole purpose of this thread is to bring attention to https://bugzilla.redhat.com/show_bug.cgi?id=1646930
Unreliable time on the system is a daily annoyance that will be easily fixed by aligning the Fedora version with the upstream's. Could someone ping the package maintainer? Also, a proven packager could just initiate the build.
I've opened a PR: https://src.fedoraproject.org/rpms/tzdata/pull-request/2
Thanks to everybody for the quick response. As you'll see in the ticket thread, the maintainer is now handling the update.