[Looping Benjamin in] Hi everyone,
the removal of /etc/timezone was discussed in the context of a systemd upload targeting experimental, where I suggested this should be handled by the tzdata package and not by systemd, as I considered tzdata the "primary" owner of that file [1]. systemd-localed also handles that file currently via a Debian specific patch, which we'd like to get rid of. The information in /etc/timezone is basically redundant as you can just as easily get the information from looking where the /etc/localtime symlink points at. It also avoids that /etc/localtime and /etc/timezone get out-of-sync.
/etc/timezone is mostly a Debianism afaiu.Benjamin was so kind to implement this suggestion swiftly and uploaded this to unstable. If this is now causing regressions in several packages, it's probably ok to revert this change for bookworm. I did briefly skim over the codesearch list, and found a lot of false positives and fixes for this issue are usually pretty simple, but yes, I'd say this could be done early in the trixie release cycle as well with an accompanying MBF.
Benjamin, would it cause a lot of trouble to revert this change again or how would you prefer to proceed?
Michael [1] https://salsa.debian.org/systemd-team/systemd/-/merge_requests/189 Am 16.02.23 um 13:30 schrieb Sebastian Ramacher:
On 2023-02-16 12:34:29 +0100, Daniel Leidert wrote:Am Donnerstag, dem 16.02.2023 um 08:41 +0100 schrieb Paul Gevers:Control: tags -1 moreinfo Control: severity -1 normal Hi Daniel, On 16-02-2023 01:11, Daniel Leidert wrote:I ask you to find a reasonable approach to deal with this for the Bookworm release.That's not how we normally work. Please come with concrete proposals and we can evaluate them.Hi Paul. That is the release team's job. Your team should be on top of that situation and control that. There is already a freeze in process. You made that very clear. New transitions are not allowed. The date has passed that re-introductions into Testing are not allowed anymore. And people break other packages just like that? It is my expectation that your team evaluates the situation together with the maintainer of tzdata now, and then comes to a conclusion and a decision, how this should be handled. codesearch.d.o proves that multiple packages use code that relies on the existence of /etc/timezone. So, its removal should have been handled in a coordinated way in the first place. Either the maintainer of tzdata does a mass-bug filing, or this change should be reverted.I suggest you file a bug with the package that introduced any breakage first. I see no such bug against tzdata. CheersI have already spent two dozen unpaid hours of tracking down and handling breakages introduced since February 7th(!!) by fellow DDs. I spent multiple dozen hours of bug-fixing and uploading since the new year started, to make sure users will get the software they expect in Bookworm, also unpaid of course. And now I have to evaluate the impact of the change in tzdata as well and create proposals? No. I'm not the tzdata maintainer and I'm not a member of the release team. It is your job to handle transitions. <frustrated> And I suggest that you finally do your job and make sure that people stop uploading breaking changes, so the work for Bookworm gets less and not constantly more. </frustrated> Daniel
OpenPGP_signature
Description: OpenPGP digital signature
