On 2022-12-09 15:08, Benjamin Drung wrote:
On Thu, 2022-12-08 at 12:50 -0800, Paul Eggert wrote:
In the past I've gotten my Ubuntu systems updated within 24 hours of a tzdata release, simply by applying patches as usual from Ubuntu. But as Benjamin indicates, this is not happening with 2022g. I just now checked for updates and I'm still stuck on 2022f. So from my point of view, Ubuntu is slow in this case - instead of taking less than a day, it's taking more than a week.
Ubuntu has as stable release update (SRU) process [1]. The process includes letting the update age in -proposed for at least seven days. That hasn't changed since the beginning in 2006. So I wonder how you get the updates within 24 hours.
I remember writing to this list about the speed of Ubuntu updates at least once. After some searching today, I found that after the 2015f release was announced August 11, 2015 at 04:37:39 UTC, I wrote on August 13 at 15:01:16 UTC that my Ubuntu workstation was already updated. See: https://mm.icann.org/pipermail/tz/2015-August/022594.html I didn't do anything special; I simply ran updates. So it sounds like the SRU process has had some sort of exception in the past for tzdata, and it suggests that Ubuntu could continue to have this exception. That said, running updates is complicated in Ubuntu as there are several ways to do it. On the Ubuntu 22.10 workstation I'm typing this on, if I click on Activities and search for "update" I get three different Ubuntu-supplied GUI icons, labeled "Software Updater", "Software & Updates", and "Ubuntu Software"; each can update tzdata. I can also do command-line updates with shell commands like "apt" or terminal-window commands like "aptitude". These alternate ways of doing updates typically do not agree, so although I did just update as usual in 2015, perhaps I used a different update procedure than the one you're thinking about. (Back in 2015 I was probably using "aptitude".)
There should be no copies of tzdata in Ubuntu. All software packages should only rely on tzdata. Please let me know if you find any. The only problematic package that I know is python3-tz which includes a hard coded list of time zone names [4].
I suspect there are several packages other than python3-pytzdata that have such lists. Although I by no means have a lot of packages installed on my workstation, I just now ran the command grep -rl Africa/Casablanca /usr /snap and found several files that mentioned this string (which is almost surely derived from tzdata). Here are three: /usr/share/liblangtag/common/bcp47/timezone.xml /usr/lib/thunderbird/libxul.so /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.6 from the liblangtag-common, thunderbird, and libqt5core5a packages. Also, due to Ubuntu's use of snaps there are multiple copies of tzdata on my workstation, not all of which agree. For example, the shell command: find /usr /snap '(' -name right -o -name posix ')' -prune -o -name Ojinaga -type f -print outputs six file names, representing two distinct time zone histories for America/Ojinaga, as shown by the following command. Although I hope apps never use the obsolete Ojinaga files, I don't know how to check this - nor do I know why Ubuntu keeps around the obsolete files given the desire that there be just one copy of tzdata in Ubuntu. $ diff -u <(zdump -i /usr/share/zoneinfo/America/Ojinaga) <(zdump -i /snap/core20/1695/usr/share/zoneinfo/America/Ojinaga) | head -n 17 --- /dev/fd/63 2022-12-10 12:28:58.449876843 -0800 +++ /dev/fd/62 2022-12-10 12:28:58.449876843 -0800 @@ -1,5 +1,5 @@ -TZ="/usr/share/zoneinfo/America/Ojinaga" +TZ="/snap/core20/1695/usr/share/zoneinfo/America/Ojinaga" - - -065740 LMT 1922-01-01 00 -07 MST 1927-06-11 00 -06 CST @@ -60,4 +60,958 @@ 2021-03-14 03 -06 MDT 1 2021-11-07 01 -07 MST 2022-03-13 03 -06 MDT 1 -2022-10-30 02 -06 CST +2022-11-06 01 -07 MST +2023-03-12 03 -06 MDT 1 +2023-11-05 01 -07 MST