Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1265410 > unrolled thread

Bug#1117683: pyinstaller-hooks-contrib: FTBFS due to test failure on valid TZ value

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1117683: pyinstaller-hooks-contrib: FTBFS due to test failure on valid TZ value Soren Stoutner <soren@debian.org> - 2025-10-09 20:30 +0200
    Bug#1117683: pyinstaller-hooks-contrib: FTBFS due to test failure on valid TZ value Guillem Jover <guillem@debian.org> - 2025-10-09 22:30 +0200
      Bug#1117683: pyinstaller-hooks-contrib: FTBFS due to test failure on valid TZ value Soren Stoutner <soren@debian.org> - 2025-10-09 22:50 +0200
        Bug#1117683: pyinstaller-hooks-contrib: FTBFS due to test failure on valid TZ value Guillem Jover <guillem@debian.org> - 2025-10-10 00:00 +0200
          Bug#1117683: pyinstaller-hooks-contrib: FTBFS due to test failure on valid TZ value Soren Stoutner <soren@debian.org> - 2025-10-10 00:10 +0200
            Bug#1117683: pyinstaller-hooks-contrib: FTBFS due to test failure on valid TZ value Soren Stoutner <soren@debian.org> - 2025-10-10 22:00 +0200

#1265410 — Bug#1117683: pyinstaller-hooks-contrib: FTBFS due to test failure on valid TZ value

[Multipart message — attachments visible in raw view] — view raw

Guillem,

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.

The package builds fine for me, on Salsa, and on the official buildds.

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.

If there is no documentation saying this is a technical goal of the Debian 
project, then I will close this bug as wontfix.

-- 
Soren Stoutner
soren@debian.org

[toc] | [next] | [standalone]

#1265427

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?

> 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.
:)

> 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.

> 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.)

Thanks,
Guillem

[toc] | [prev] | [next] | [standalone]

#1265430

[Multipart message — attachments visible in raw view] — view raw

Control: severity -1 wishlist

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.

In general, the lists of recommended timezones is managed for the community by 
the IANA (Internet Assigned Numbers Authority).

https://en.wikipedia.org/wiki/Tz_database

> > 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.

> :
> > 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.

> > 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.

In the meantime I will ponder of this for a while and then eventually either 
close this as wontfix or exclude the test.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#1265439

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

[toc] | [prev] | [next] | [standalone]

#1265440

[Multipart message — attachments visible in raw view] — view raw

On Thursday, October 9, 2025 2:56:14 PM Mountain Standard Time Guillem Jover 
wrote:
> I've filed a report upstream, and tomorrow I'll file another one
> against the tzlocal upstream.

Thanks.  Please post links to your upstream bug reports here to make it easy 
for everyone to follow them.

For anyone looking at this bug report who is interested in more background 
information, they can read the thread which starts at:

https://lists.debian.org/debian-devel/2025/10/msg00006.html

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#1265554

[Multipart message — attachments visible in raw view] — view raw

The upstream pyinstaller-hooks-contrib bug report is here:

https://github.com/pyinstaller/pyinstaller-hooks-contrib/issues/953

They addressed the bug complaint with a patch that simply ignores the timezone 
used by the server.

The effects of this change is that now the Salsa CI reprotest will pass.

The reproducible builds test, which used to pass, will continue to do so but 
will now no long exercise the timezone shift in this test.

The regression in the testing of the timezone shift is a bit sad to me, but 
not enough that I am going alter the upstream behavior (I have a strong 
preference as a packager to ship code as similar to upstream as possible).  
This is probably the best possible outcome as it is unlikely that the large 
number of upstream projects that expect time zones to be in the zoneinfo 
format are going to add support for antiquated formats just to make a very 
small number of older, embedded systems happy.  Also, as support for time zone 
reproducible build variation is not a core goal of the majority of these 
projects, hard coding the time zone doesn’t register as a loss for them.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web