On Thu, 2023-02-16 at 13:59 +0100, Michael Biebl wrote: > [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?
I agree that restoring /etc/timezone is the right solution for the bookworm. I'll prepare a tzdata upload for it. > [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. > > > > Cheers > > > > > > > > I 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 > > > > > > -- Benjamin Drung Debian & Ubuntu Developer
