Control: forwarded -1 https://github.com/pyinstaller/pyinstaller-hooks-contrib/issues/953
On Thu, 2025-10-09 at 13:47:43 -0700, Soren Stoutner wrote: > Control: severity -1 wishlist Well, I disagree, but *shrug*. > On Thursday, October 9, 2025 1:27:00 PM Mountain Standard Time Guillem Jover > wrote: > > On Thu, 2025-10-09 at 11:19:21 -0700, Soren Stoutner wrote: > > > On Thursday, October 9, 2025 9:56:57 AM Mountain Standard Time Guillem > Jover > > > > > > wrote: > > > > This package FTBFS when setting the TZ variable using the abbreviated > > > > > > > timezone and offset format. Such as when calling it with: > > > Thank you for your detailed bug report. > > > > > > pyinstaller-hooks-contrib does indeed include a test expecting to find the > > > timezone described in the Continent/City (zoneinfo) syntax. This is the > > > generally recommended timezone format in Linux. > > > > Recommended by who? > > By the Debian installer, among many other examples. If by recommended you mean that the debian-installer presents the geographical timezones to users to select from, then, to me that seems like the obvious thing to do, because that's what most if not all end users want to select from and configure in their systems, also because they are more user friendly. > > > The package builds fine for me, on Salsa, and on the official buildds. > > > > That does not mean the package does not contain a broken test though. > > > > :) > > Although I can understand where you are coming from claiming this test is > broken, that is based on the premise that obsolete timezone formats is > something that should be supported by all upstream software. Although that > may be the case, I am not aware of that being Debian’s official stance. I guess I don't agree that that the proleptic format is obsolete. Or more accurately (as was also mentioned on the d-d thread), I think it's not a great format (as in UX, maintainability and as an interface) to encode geographical and political timezones, but it's just fine or in some cases preferred to specify fixed timezones. > > : > > > Can you point me to any official documentation that says one of the goals > of > > > the Debian project is to enforce that all software works with the > deprecated > > > GMT+12 format? If so, I would be happy to take a look at this bug. > > > > Sorry, but deprecated by who? I see no such statement on neither of: > > > > https://sourceware.org/glibc/manual/2.42/html_node/TZ-Variable.html > > https://sourceware.org/glibc/manual/2.42/html_node/Proleptic-TZ.html > > https://manpages.debian.org/unstable/manpages-dev/tzset.3.en.html > > https://pubs.opengroup.org/onlinepubs/9799919799/functions/tzset.html > > > > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/ > V1_chap08.html#tag_ > > 08 > > > > Instead, from the POSIX standard the main take away is that, for the > > third form (that is the non-colon-prefixed, non-proleptic form), it is > > stated: > > > > ``` > > the value indicates either a geographical timezone or a special > > timezone from an implementation-defined timezone database. > > ``` > > > > Where to me that clearly reads that this format is non-portable, so I > > don't see how the others would then be deprecated in any form. > > I do find these links to be at least partially persuasive. From them I would > take that the older format definitely is not the recommended format. For > example, from the second link: > > "Although the proleptic format is cumbersome and inaccurate for old > timestamps, POSIX.1-2017 and earlier specified details only for the proleptic > format, and you may need to use it on small systems that lack a time zone > information database.” > > That sounds like the definition of deprecated to me. However, deprecated > does > not mean unused. It meas that it is not recommended that anything new uses > it > by default and that, at some point in the future, everyone expects the > deprecated format to go away. > > But deprecated things are often still supported for a while. I will need to > ponder over whether, in this case, it is important for pyinstaller-hooks- > contrib to continue to support an older format. See my comment above, so I agree with the glibc phrasing that using the proleptic format to specify a geographical and/or political timezone is not ideal. But there are other uses besides that. This package does not seem to be timezone related, it just seems to have a test case that transitively depends on a python module that does not support this format. But its test still fails. > > > If there is no documentation saying this is a technical goal of the Debian > > > project, then I will close this bug as wontfix. > > > > Hmm, we do not have an exhaustive list of all potentially broken things > > a build system, or anything in a package can do. lintian or Debian Policy > > encode either things that are easy to miss, or nice to automate, or where > > different trade-offs could be made. Here we have a clear build failure > > when setting a variable to a supported (non-deprecated) value, so I'm not > > sure I understand the request, TBH. > > > > The build even fails with something like TZ=UTC0 or TZ=UTC+0 (which is > > the strictly conforming way to specify a UTC timezone). (And this is > > something that I could see «dpkg-buildpackage --sanitize-env» setting > > and potentially that becoming a default in the future.) > > For now I am lowering this to wishlist, as supporting the old timezone > formatting in all upstream programs does not appear to be an official Debian > technical goal. If that ever does become a Debian technical goal then I will > take a closer look. I don't think the project works via "official Debian technical goals". But as mentioned before: - We no longer install tzdata by default as part of the essential or buildd deboostrap/mmdebstrap sets. - Using a geographical/political timezone in TZ w/o tzdata installed produces bogus results. - The only way to specify a portable non-geographical/political timezone w/o requiring tzdata to be always installed in such chroots/installations via tools that normalize the environment (for example) is to use a proleptic timezone. > In the meantime I will ponder of this for a while and then eventually either > close this as wontfix or exclude the test. Ok. I've filed a report upstream, and tomorrow I'll file another one against the tzlocal upstream. Regards, Guillem
