Re: "Missing" entries in timezone tables
Hi, I am not entirely sure, but I think you can probably find those missing timezones in tzdata-legacy package. Best, Ananthu
Should be wtmp considered as successor of who(1)?
Hi curl's and boys =D in relation to the discussion of 'utmp in trixie' * https://lists.debian.org/debian-devel/2025/04/msg00011.html It looks like, that wtmp is an well alternative to who(1). For that the command $> last -p now should be able to use in the future. But the developers at upstream of wtmpdb persist in the opinion that wtmp has nothing to do with utmp before merging PR#36. * https://github.com/thkukuk/wtmpdb/issues/33 Now, I have not the guts to ask them, if they would like to implement an own who(1) utility. I think it should not be an security issue, if by default who(1) logs every libpam-login without an installed autitd or selinux extension. What do you think ??? But please, before writing: Calm down! It makes no sense to discuss that frantically. Please think before writing! I know such mailing lists. Dirk. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Formal warning for conduct on Debian mailing lists
[Forwarded copy of original email: signed for authentication] On Sat, Apr 05, 2025 at 04:06:17PM +, Andrew M.A. Cater wrote: > Dear Branden, > > The Debian Code of Conduct[1] (and the mailing list Code of Conduct[2]) can > be boiled down to two sentences in simple English: > Assume good faith. > Treat others with respect, both within and outside Debian. > > > You seem to be complaining about the conduct of the Community Team with > almost every email. Each of the three members of the team has written > separately to you here in the threads on debian-devel or on the > debian-private mailing list. The content of the one (private) email written > directly to you by the Community Team has previously been quoted by you to > the lists. > > The first few lines in your response to that initial mail from the Community > Team were that you would go quiet on the lists - I understood you to have > meant that in good faith. Instead, you have escalated the tone of your > responses in > debian-private, here in debian-devel, and in your questions to prospective > DPLs on debian-vote. > > You have taken it upon yourself to tell the Project and the team how > Community Team business should be run, not once but several times and at > great length. You have expressly treated this like a debate. > Robert's Rules of Order aren't appropriate here. > > Assuming good faith is very much on point: you have chosen to use personal > attacks on style as veiled attacks on the character of the members of the > Community Team. You have chosen to mischaracterise replies written in good > faith as attacks on you. Stop this, please. > > As a former DPL, and as someone who was very much around when the Code of > Conduct was introduced, the way the Community Team works should not be a > surprise to you. The common expectations of proper behaviour from every > Debian developer should not come as a shock nor should you feel that you > have been unduly singled out to be reminded. > > This is an explicit reminder to you that the mailing list Code of Conduct [2] > applies in each Debian mailing list. > This is a formal warning to you that we believe your conduct on the Debian > mailing lists appears to be in breach of the main Debian Code of Conduct [1]. > This warning (and the tone of any subsequent emails from you) may be shared > with the listmasters. They may consider suspending you from Debian lists in > due course if this conduct continues. > > [1]: https://www.debian.org/code_of_conduct > [2]: https://www.debian.org/MailingLists/#codeofconduct > > For the Community Team, > > Andrew Cater > (amaca...@debian.org) signature.asc Description: PGP signature
Re: Should be wtmp considered as successor of who(1)?
* Dirk Lehmann [250408 17:20]: in relation to the discussion of 'utmp in trixie' * https://lists.debian.org/debian-devel/2025/04/msg00011.html It looks like, that wtmp is an well alternative to who(1). For that the command $> last -p now should be able to use in the future. But the developers at upstream of wtmpdb persist in the opinion that wtmp has nothing to do with utmp before merging PR#36. They are correct. Now, I have not the guts to ask them, if they would like to implement an own who(1) utility. I think that would be wrong. Chris
Re: "Missing" entries in timezone tables
On Tue, Apr 08, 2025 at 04:50:58PM -0500, Richard Laager wrote: Option C would also keep the whole system consistent. But in that scenario, installing python-tz indirectly adds system-wide timezone values. I'm hesitant about that idea; it feels like "spooky action at a distance". FWIW, that's how I feel about stuff that worked literally for decades up and disappearing for no apparent reason, but that's neither here nor there. As a sysadmin, I could see that leading me to troubleshoot, "Why does this systemd timer that uses US/Pacific work on system A, but not system B?" or "Why does `TZ=US/Pacific date` work on some terminals and not others?" The answer, "Because system A installed software P that depends on python-tz, so that pulled in tzdata-legacy.", would feel surprising once I found it. This is heavily my personal opinion, though. It's IMO much easier to understand this outcome in a debian context as dpkg -S US/Pacific will clarify things pretty quickly.
Re: "Missing" entries in timezone tables
I got bit (not in pytz) by US/Pacific disappearing, so I understand the annoyance from the user perspective. However, as that is what has happening in tzdata, I don't think we should have individual packages trying to fight that individually/haphazardly. I looked at the patches in the package. Am I correct in understanding that python-tz loads from zoneinfo at runtime? If so, then I think you should leave things alone. If the user needs things like US/Pacific, they can install tzdata-legacy and get it system-wide. If you patch US/Pacific back in manually, then you have two problems: 1. Things are inconsistent. For example, US/Pacific works in Python, but not in systemd. (I realize that's the state that upstream pytz is creating already, but you needn't follow them down this road.) 2. You will never know when it's acceptable to remove these, so you'll feel stuck carrying that forever. (On the other hand, you are just following upstream pytz, so you can say it's their problem. But, they will definitely have this same problem of not knowing when to remove the backwards compatibility.) On 2025-04-08 11:14, Michael Stone wrote: On Tue, Apr 08, 2025 at 06:42:43AM +0100, Alastair McKinstry wrote: But ./gen_tzinfo.py in python-tz adds extra timezones it believes should be present, including some backwards-compatible entries such as "US/Pacific". Adding these timezones is possible, but I am loath to diverge from tzdata.. Any opinions or recommendations? I'd just depend on tzdata-legacy. I don't really understand why it was decided to put some names in a separate package, but it's a small one and if you need compatibility, that's what you need to do. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Should be wtmp considered as successor of who(1)?
On Tue, Apr 08, 2025 at 05:19:38PM +0200, Dirk Lehmann wrote: in relation to the discussion of 'utmp in trixie' * https://lists.debian.org/debian-devel/2025/04/msg00011.html It looks like, that wtmp is an well alternative to who(1). For that the command $> last -p now No. utmp and wtmp are two different interfaces, which have two different purposes.
Bug#1102391: ITP: python-typing-inspection -- Tools to inspect Python type annotations at runtime
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-typing-inspection Version : 0.4.0 Upstream Contact: Victorien Plot * URL : https://github.com/pydantic/typing-inspection * License : MIT Programming Lang: Python Description : Tools to inspect Python type annotations at runtime This package provides low-level functions to check if a variable is a "typing" object, and high-level introspection utilities used to inspect type annotations that take runtime edge cases into account. Recent versions of the "pydantic" data validation library, which I co-maintain in Debian, require typing-inspection. I intend to maintain it within the Debian Python Team. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: "Missing" entries in timezone tables
On Tue, Apr 08, 2025 at 06:42:43AM +0100, Alastair McKinstry wrote: But ./gen_tzinfo.py in python-tz adds extra timezones it believes should be present, including some backwards-compatible entries such as "US/Pacific". Adding these timezones is possible, but I am loath to diverge from tzdata.. Any opinions or recommendations? I'd just depend on tzdata-legacy. I don't really understand why it was decided to put some names in a separate package, but it's a small one and if you need compatibility, that's what you need to do.
Re: "Missing" entries in timezone tables
Perhaps I was unclear, which might have made things worse than having not said anything at all. So I'll take one attempt at clarifying. The issue doesn't impact me personally all that much, I don't have strong feelings, and I recognize that all options have pros and cons. As I understood the initial email from Alastair McKinstry, there were a couple of options: A) Change nothing. python-tz continues to use zoneinfo at runtime, as it has in Debian for a long time. B) Bake in some aliases in python-tz itself. This might be considered similar conceptually (but implementation details would almost certainly vary) to what pytz upstream is doing in gen_tzinfo.py. Michael Stone proposed: C) Make python-tz depend on tzdata-legacy. On 2025-04-08 12:37, Michael Stone wrote: On Tue, Apr 08, 2025 at 12:08:05PM -0500, Richard Laager wrote: I got bit (not in pytz) by US/Pacific disappearing, so I understand the annoyance from the user perspective. However, as that is what has happening in tzdata, I don't think we should have individual packages trying to fight that individually/haphazardly. If you're maintaining a package that itself is trying to maintain compatibility, what else would you do? Since we were asked, I gave my opinion. I agreed with A, with the explicit mention that the user could install tzdata-legacy if they wanted. If you patch US/Pacific back in manually, then you have two problems: 1. Things are inconsistent. For example, US/Pacific works in Python, but not in systemd. (I realize that's the state that upstream pytz is creating already, but you needn't follow them down this road.) Why would it not work in systemd? I'd argue that any inconsistency would be to have debian's pytz needlessly diverge from its expected functionality. When I was discussing inconsistency, it was in the context of B. That is, if python-tz makes US/Pacific work again without tzdata-legacy (for example, by internally aliasing it to America/Los_Angeles), then that obviously only makes it work in python-tz. Other parts of the system (I gave systemd as an example, since that was my personal experience in the matter) would not work with US/Pacific. I was saying that I think it would be better for the whole system to be consistent, i.e. using one tzdata/zoneinfo database. After all, that is why we have tzdata. Option C would also keep the whole system consistent. But in that scenario, installing python-tz indirectly adds system-wide timezone values. I'm hesitant about that idea; it feels like "spooky action at a distance". As a sysadmin, I could see that leading me to troubleshoot, "Why does this systemd timer that uses US/Pacific work on system A, but not system B?" or "Why does `TZ=US/Pacific date` work on some terminals and not others?" The answer, "Because system A installed software P that depends on python-tz, so that pulled in tzdata-legacy.", would feel surprising once I found it. This is heavily my personal opinion, though. That said, I do recognize that option C has the benefit of pytz everywhere, including Debian, always includes US/Pacific. I know from multiple different points of view (Debian packager, upstream developer, and practicing sysadmin) the potential cons (and the pros) of "Debianisms". There is a potential slippery slope here... If pytz makes other edits (and the original email says it "pulls down zoneinfo...and edits it", though it's unclear what those edits are), is the expectation that those need to be preserved in Debian as well? What if they conflict with the system tzdata? I realize that decision can be made if/when it actually occurs. I'm just trying to highlight the tension between keeping Debian consistent system-wide and keeping pytz consistent between upstream and Debian. On the other hand, now that Python (starting with 3.9) includes native support for tzdata/zoneinfo, a major (the only?) reason to use pytz any more is for backwards compatibility (i.e. some Python program needs to work on < 3.9 and >= 3.9). In that case, pytz being inconsistent with the system zoneinfo is already an issue, as it means the available timezones change when you cross the Python 3.9 boundary. Lastly, I recognize that punting this to the user has cons as well. 2. You will never know when it's acceptable to remove these, so you'll feel stuck carrying that forever. (On the other hand, you are just following upstream pytz, so you can say it's their problem. But, they will definitely have this same problem of not knowing when to remove the backwards compatibility.) Yeah, that's how backward compatibility works. I don't see the problem at the cost of a few symlinks. For option B, it almost certainly would not be symlinks. It'd be some changes to pytz. For example, adding special cases in timezone() or _case_insensitive_zone_lookup(). The maintenance cost of that is similar, but at least potentially higher. For option C, yes, it's ultima
