Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 9/27/23 04:43, Peter Robinson wrote:
> On Wed, Sep 27, 2023 at 6:24 AM Remi Collet  wrote:
>>
>> Le 26/09/2023 à 19:32, Carlos O'Donell a écrit :
>>
 In version 8.3 (F40) we'll includes the UTC definition
 in our patch to use system tzdata, UTC being use
 as the fallback value.
>>>
>>> I'm curious; what does this patch look like?
>>
>> (trivial) patch to our system tzdata patch attached
>>
>> In short, if file is missing use bundled content
>>
>> Full patch for PHP 8.3:
>> https://git.remirepo.net/cgit/rpms/scl-php83/php.git/plain/php-8.3.0-systzdata-v24.patch
>>
>> Remi
>>
>>
>> P.S. IMHO, allowing removal of tzdata for PHP doesn't make any sense
>> as most app will fail badly (runtime exception) because of missing
>> TZ when upstream use a bundle copy of the full database, so this can
>> never happen, so this will create another RPM specific problem
> 
> Can't you just explicitly require tzdata?

I agree, if PHP requires tzdata then please add "Requires: tzdata"

With any kind of minimization work where we split up the packages we are going 
to
find implicit dependencies that should be made explicit. It is perfectly OK to
require tzdata from PHP if that's what is needed for your users, and you know
your users best.

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Peter Robinson]

On Wed, Sep 27, 2023 at 6:24 AM Remi Collet  wrote:
>
> Le 26/09/2023 à 19:32, Carlos O'Donell a écrit :
>
> >> In version 8.3 (F40) we'll includes the UTC definition
> >> in our patch to use system tzdata, UTC being use
> >> as the fallback value.
> >
> > I'm curious; what does this patch look like?
>
> (trivial) patch to our system tzdata patch attached
>
> In short, if file is missing use bundled content
>
> Full patch for PHP 8.3:
> https://git.remirepo.net/cgit/rpms/scl-php83/php.git/plain/php-8.3.0-systzdata-v24.patch
>
> Remi
>
>
> P.S. IMHO, allowing removal of tzdata for PHP doesn't make any sense
> as most app will fail badly (runtime exception) because of missing
> TZ when upstream use a bundle copy of the full database, so this can
> never happen, so this will create another RPM specific problem

Can't you just explicitly require tzdata?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Remi Collet]

Le 26/09/2023 à 19:32, Carlos O'Donell a écrit :


In version 8.3 (F40) we'll includes the UTC definition
in our patch to use system tzdata, UTC being use
as the fallback value.


I'm curious; what does this patch look like?


(trivial) patch to our system tzdata patch attached

In short, if file is missing use bundled content

Full patch for PHP 8.3:
https://git.remirepo.net/cgit/rpms/scl-php83/php.git/plain/php-8.3.0-systzdata-v24.patch

Remi


P.S. IMHO, allowing removal of tzdata for PHP doesn't make any sense
as most app will fail badly (runtime exception) because of missing
TZ when upstream use a bundle copy of the full database, so this can
never happen, so this will create another RPM specific problem
(when upstream is opposed to our change, for years)From db0a54781ce95dbbe7adbf26346322075794a931 Mon Sep 17 00:00:00 2001
From: Remi Collet 
Date: Fri, 22 Sep 2023 15:56:38 +0200
Subject: [PATCH] add internal UTC if tzdata is missing

---
 ext/date/lib/parse_tz.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/ext/date/lib/parse_tz.c b/ext/date/lib/parse_tz.c
index 648d16c12c..ec196a98b6 100644
--- a/ext/date/lib/parse_tz.c
+++ b/ext/date/lib/parse_tz.c
@@ -35,6 +35,17 @@
 
 #include "php_scandir.h"
 
+static const unsigned char internal_utc[] = {
+0x54, 0x5a, 0x69, 0x66, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x55, 0x54, 0x43, 0x00, 0x54, 0x5a, 0x69, 0x66, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
+0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x55, 0x54, 0x43, 0x00, 0x0a, 0x55, 0x54, 0x43,
+0x30, 0x0a
+};
+
 #else
 #define TIMELIB_SUPPORTS_V2DATA
 #define TIMELIB_SUPPORT_SLIM_FILE
@@ -934,6 +945,9 @@ static void create_zone_index(timelib_tzdb *db)
 
 qsort(db_index, index_next, sizeof *db_index, sysdbcmp);
 
+	if (!index_next) {
+		db_index[index_next++].id = strdup("UTC");
+	}
 	db->index = db_index;
 	db->index_size = index_next;
 
@@ -1040,7 +1054,12 @@ static char *map_tzfile(const char *timezone, size_t *length)
 
 	fd = open(fname, O_RDONLY);
 	if (fd == -1) {
-		return NULL;
+		if (strcmp(timezone, "UTC")) {
+			return NULL;
+		} else {
+			*length = sizeof(internal_utc);
+			return internal_utc;
+		}
 	} else if (fstat(fd, ) != 0 || !is_valid_tzfile(, fd)) {
 		close(fd);
 		return NULL;
@@ -,7 +1130,7 @@ const timelib_tzdb *timelib_builtin_db(void)
 	if (timezonedb_system == NULL) {
 		timelib_tzdb *tmp = malloc(sizeof *tmp);
 
-		tmp->version = "0.system";
+		tmp->version = "0";
 		tmp->data = NULL;
 		create_zone_index(tmp);
 		retrieve_zone_version(tmp);
@@ -1144,7 +1163,9 @@ int timelib_timezone_id_is_valid(const char *timezone, const timelib_tzdb *tzdb)
 		if (timezone[0] == '\0' || strstr(timezone, "..") != NULL) {
 			return 0;
 		}
-
+		if (!strcmp(timezone, "UTC")) {
+			return 1;
+		}
 		if (system_location_table) {
 			if (find_zone_info(system_location_table, timezone) != NULL) {
 /* found in cache */
@@ -1274,7 +1295,9 @@ timelib_tzinfo *timelib_parse_tzfile(const char *timezone, const timelib_tzdb *t
 			}
 
 			/* Now done with the mmap segment - discard it. */
-			munmap(memmap, maplen);
+			if (memmap != internal_utc) {
+munmap(memmap, maplen);
+			}
 		} else {
 #endif
 		if (type == TIMELIB_TZINFO_PHP) {
-- 
2.41.0

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On Mon, Sep 25, 2023 at 4:39 AM Vít Ondruch  wrote:
> Dne 22. 09. 23 v 16:01 Zbigniew Jędrzejewski-Szmek napsal(a):
> > On Fri, Sep 22, 2023 at 10:43:05AM +0200, Vít Ondruch wrote:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3
> >>
> >> This probably answers my question. So heads up to others.
> >>
> >> Dne 22. 09. 23 v 10:39 Vít Ondruch napsal(a):
> >>> Was this implemented in past days? I am asking because this FTBFS
> >>> suggest so:
> >>>
> >>> https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40
> > Yes. The change was done in rawhide a while ago, but it got pushed to F39
> > only recently, see https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3.
>
> Dealing now with FTBFS rubygem- packages, the change proposal briefly
> mentions: "In June of 2021, we proposed creating a new tzdata
> sub-package that would only provide the UTC timezone.". I assume that
> this have not happened, but I don't remember why and it seems that this
> could be helpful.

In discussions with upstream IANA Tzdata and the Fedora developer
community in 2021, it was concluded that the consensus was to remove
tzdata entirely and fall back to UTC.

The noted problem was that any files provided by tzdata could be an
indication that all of tzdata is installed when that is not the case.

It was clearer to have no files installed and fallback to UTC or all
files installed and provide the full set of functionality.

Today, if a package needs UTC *and* more complex leap second
processing, then they need to install all of tzdata.

Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On Mon, Sep 25, 2023 at 4:52 AM Remi Collet  wrote:
>
> Le 25/09/2023 à 10:38, Vít Ondruch a écrit :
> >
> > Dne 22. 09. 23 v 16:01 Zbigniew Jędrzejewski-Szmek napsal(a):
> >> On Fri, Sep 22, 2023 at 10:43:05AM +0200, Vít Ondruch wrote:
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3
> >>>
> >>> This probably answers my question. So heads up to others.
> >>>
> >>> Dne 22. 09. 23 v 10:39 Vít Ondruch napsal(a):
>  Was this implemented in past days? I am asking because this FTBFS
>  suggest so:
> 
>  https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40
> >> Yes. The change was done in rawhide a while ago, but it got pushed to F39
> >> only recently, see
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3.
> >
> >
> > Dealing now with FTBFS rubygem- packages, the change proposal briefly
> > mentions: "In June of 2021, we proposed creating a new tzdata
> > sub-package that would only provide the UTC timezone.". I assume that
> > this have not happened, but I don't remember why and it seems that this
> > could be helpful.
>
> We have the same issue with PHP and lot of recent FTBFS
>
> timezone is really mandatory for PHP

If they are mandatory for building then you may need a "BuildRequires:
tzdata" in your package now, as you may no longer have it included
transitively.

If your APIs need tzdata at runtime then you may need a "Requires:
tzdata" if the APIs cannot operate in UTC-only mode with tzdata
removed (minimized container).

> In version 8.3 (F40) we'll includes the UTC definition
> in our patch to use system tzdata, UTC being use
> as the fallback value.

I'm curious; what does this patch look like?

Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Remi Collet]

Le 25/09/2023 à 10:38, Vít Ondruch a écrit :


Dne 22. 09. 23 v 16:01 Zbigniew Jędrzejewski-Szmek napsal(a):

On Fri, Sep 22, 2023 at 10:43:05AM +0200, Vít Ondruch wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3

This probably answers my question. So heads up to others.

Dne 22. 09. 23 v 10:39 Vít Ondruch napsal(a):

Was this implemented in past days? I am asking because this FTBFS
suggest so:

https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40

Yes. The change was done in rawhide a while ago, but it got pushed to F39
only recently, see 
https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3.



Dealing now with FTBFS rubygem- packages, the change proposal briefly 
mentions: "In June of 2021, we proposed creating a new tzdata 
sub-package that would only provide the UTC timezone.". I assume that 
this have not happened, but I don't remember why and it seems that this 
could be helpful.


We have the same issue with PHP and lot of recent FTBFS

timezone is really mandatory for PHP

In version 8.3 (F40) we'll includes the UTC definition
in our patch to use system tzdata, UTC being use
as the fallback value.

Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Vít Ondruch]

Dne 22. 09. 23 v 16:01 Zbigniew Jędrzejewski-Szmek napsal(a):

On Fri, Sep 22, 2023 at 10:43:05AM +0200, Vít Ondruch wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3

This probably answers my question. So heads up to others.

Dne 22. 09. 23 v 10:39 Vít Ondruch napsal(a):

Was this implemented in past days? I am asking because this FTBFS
suggest so:

https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40

Yes. The change was done in rawhide a while ago, but it got pushed to F39
only recently, see https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3.



Dealing now with FTBFS rubygem- packages, the change proposal briefly 
mentions: "In June of 2021, we proposed creating a new tzdata 
sub-package that would only provide the UTC timezone.". I assume that 
this have not happened, but I don't remember why and it seems that this 
could be helpful.



Vít




Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 22, 2023 at 10:43:05AM +0200, Vít Ondruch wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3
> 
> This probably answers my question. So heads up to others.
> 
> Dne 22. 09. 23 v 10:39 Vít Ondruch napsal(a):
> > Was this implemented in past days? I am asking because this FTBFS
> > suggest so:
> > 
> > https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40

Yes. The change was done in rawhide a while ago, but it got pushed to F39
only recently, see https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Vít Ondruch]

https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3

This probably answers my question. So heads up to others.


Vít



Dne 22. 09. 23 v 10:39 Vít Ondruch napsal(a):
Was this implemented in past days? I am asking because this FTBFS 
suggest so:


https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40


Vít


Dne 26. 06. 23 v 17:54 Aoife Moloney napsal(a):

https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Allow the removal of tzdata especially on containers in order to 
minimize size.



== Owner ==
* Name: Patsy Griffin (Franklin)

* Email: pa...@redhat.com


== Detailed Description ==
This change will allow the removal of tzdata.  When tzdata is removed,
the system will default to UTC. In order to reduce overhead, many
container installations now remove the data associated with tzdata but
cannot fully remove the package due to dependencies by other packages.
This results in confusion regarding the expected timezone info.

In order for this to work, we need packages that use tzdata at run
time to switch from Require'ing tzdata to Recommend'ing tzdata. These
packages should also gracefully handle instances where tzdata has been
removed.  For example, this would require recognizing that tzdata is
not present and providing an appropriate error, such as recommending
that the user install tzdata.

== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone.  As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.


== Benefit to Fedora ==
This change will allow tzdata to be removed from containers without
leaving inconsistent package remnants.


== Scope ==
* Proposal owners: No changes are needed to tzdata.

* Other developers: Some packages need to change their spec files from
`Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
all packages switched in this way, but it is not required. Supporting
optional tzdata installation for as many workloads as possible allows
those workloads to minimize their container image size.
List of packages which need to be changed:
* glibc (glibc-common)
* gcc (libstdc++)
* python3.XX (3.9, 3.10, 3.11, 3.12)
List of packages which would be beneficial to be changed:
* python3-dateutil
* python3-pytz
* libical
Upon acceptance of the change request we will file bugs to fix each of
these packages for Fedora 39.


* Release engineering: No changes needed.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==
If tzdata is already installed, then it continues to be installed on 
the system.


Following the Fedora Weak Dependencies Policy dnf will treat the
Recommends on tzdata as if it were a Requires and tzdata will always
be installed in a default system
(https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/) 



However, the recommends will allow tzdata to be correctly uninstalled
in a container build file rather than having to use ‘rm -rf’ to delete
the zone files to recover space.


== How To Test ==
Language runtimes were installed and A/B tests carried out with tzdata
present and tzdata removed. The intent of these tests was to ensure
that the system can use the language frameworks without tzdata present
and that when the data was required that meaningful errors were
presented to the user.

Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11),
using their time and date APIs. This testing led to the correction of
the libstdc++ implementation as noted here:
https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea42b42c3 



Developers can test this by installing Rawhide and uninstalling tzdata
and verifying their package operates as expected.

If tzdata cannot be uninstalled then we recommend filling a bug
against the package that Requires: tzdata and having a discussion with
the maintainer to make tzdata optional e.g. Recommends: tzdata.


== User Experience ==
The user can remove tzdata to minimize the container size.

With tzdata removed the system is UTC only.



== Dependencies ==
Fixing glibc, gcc, and python3.xx at a minimum to make tzdata
Recommends instead of Requires.



== Contingency Plan ==
* Contingency mechanism: Back out the change. Don’t do it.
* Contingency deadline:  Can be backed out at the last minute since we
are only dealing with conversions from Requires to Recommends.
* Blocks release? No

== Documentation ==
Document that the tzdata package may be removed if needed to reduce
space on 

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Vít Ondruch]

Was this implemented in past days? I am asking because this FTBFS 
suggest so:


https://koschei.fedoraproject.org/package/rubygem-timecop?collection=f40


Vít


Dne 26. 06. 23 v 17:54 Aoife Moloney napsal(a):

https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Allow the removal of tzdata especially on containers in order to minimize size.


== Owner ==
* Name: Patsy Griffin (Franklin)

* Email: pa...@redhat.com


== Detailed Description ==
This change will allow the removal of tzdata.  When tzdata is removed,
the system will default to UTC. In order to reduce overhead, many
container installations now remove the data associated with tzdata but
cannot fully remove the package due to dependencies by other packages.
This results in confusion regarding the expected timezone info.

In order for this to work, we need packages that use tzdata at run
time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
packages should also gracefully handle instances where tzdata has been
removed.  For example, this would require recognizing that tzdata is
not present and providing an appropriate error, such as recommending
that the user install tzdata.

== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone.  As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.


== Benefit to Fedora ==
This change will allow tzdata to be removed from containers without
leaving inconsistent package remnants.


== Scope ==
* Proposal owners: No changes are needed to tzdata.

* Other developers: Some packages need to change their spec files from
`Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
all packages switched in this way, but it is not required. Supporting
optional tzdata installation for as many workloads as possible allows
those workloads to minimize their container image size.
List of packages which need to be changed:
* glibc (glibc-common)
* gcc (libstdc++)
* python3.XX (3.9, 3.10, 3.11, 3.12)
List of packages which would be beneficial to be changed:
* python3-dateutil
* python3-pytz
* libical
Upon acceptance of the change request we will file bugs to fix each of
these packages for Fedora 39.


* Release engineering: No changes needed.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==
If tzdata is already installed, then it continues to be installed on the system.

Following the Fedora Weak Dependencies Policy dnf will treat the
Recommends on tzdata as if it were a Requires and tzdata will always
be installed in a default system
(https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/)

However, the recommends will allow tzdata to be correctly uninstalled
in a container build file rather than having to use ‘rm -rf’ to delete
the zone files to recover space.


== How To Test ==
Language runtimes were installed and A/B tests carried out with tzdata
present and tzdata removed. The intent of these tests was to ensure
that the system can use the language frameworks without tzdata present
and that when the data was required that meaningful errors were
presented to the user.

Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11),
using their time and date APIs. This testing led to the correction of
the libstdc++ implementation as noted here:
https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea42b42c3

Developers can test this by installing Rawhide and uninstalling tzdata
and verifying their package operates as expected.

If tzdata cannot be uninstalled then we recommend filling a bug
against the package that Requires: tzdata and having a discussion with
the maintainer to make tzdata optional e.g. Recommends: tzdata.


== User Experience ==
The user can remove tzdata to minimize the container size.

With tzdata removed the system is UTC only.



== Dependencies ==
Fixing glibc, gcc, and python3.xx at a minimum to make tzdata
Recommends instead of Requires.



== Contingency Plan ==
* Contingency mechanism: Back out the change. Don’t do it.
* Contingency deadline:  Can be backed out at the last minute since we
are only dealing with conversions from Requires to Recommends.
* Blocks release? No

== Documentation ==
Document that the tzdata package may be removed if needed to reduce
space on containers.  With tzdata removed, the system will default to
UTC.


== Release Notes ==





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Patsy Griffin]

On Fri, Jun 30, 2023 at 11:54 AM Chris Adams  wrote:

> Once upon a time, Jonathan Wakely  said:
> > From the change proposal:
> >
> > == Feedback ==
> > In June of 2021, we proposed creating a new tzdata sub-package that
> > would only provide the UTC timezone.  As part of the discussion around
> > this proposal, it was recommended that we completely remove tzdata. We
> > appreciated this input and welcome additional feedback.
>
> It would be nice to know the reasons behind the recommendation.  It
> seems trying to eliminate tzdata completely is going to require a
> significant amount of work and package churn, so why is this the better
> path?
>

Anyone interested in reviewing the previous change proposal and discussion
can search for tzdata-minimal in the List Archives (July, 2021).

Thanks again for all of the helpful feedback!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Stephen Smoogen]

On Fri, 30 Jun 2023 at 11:50, Jonathan Wakely  wrote:

> On Fri, 30 Jun 2023 at 16:38, Ian Pilcher wrote:
> > Rather than expecting runtimes and applications to be fixed to work
> > without any timezone information, perhaps the best way forward would be
> > to create a tzdata-utc (and similar Java and Python packages).
> >
> > (Sorry if this has already been suggested & rejected.  I don't remember
> > seeing it in this thread, but ...)
>
> From the change proposal:
>
> == Feedback ==
> In June of 2021, we proposed creating a new tzdata sub-package that
> would only provide the UTC timezone.  As part of the discussion around
> this proposal, it was recommended that we completely remove tzdata. We
> appreciated this input and welcome additional feedback.
>
>
Thanks, I have enrolled in a basic reading and comprehension program since
I missed this twice on read-through.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Chris Adams]

Once upon a time, Jonathan Wakely  said:
> From the change proposal:
> 
> == Feedback ==
> In June of 2021, we proposed creating a new tzdata sub-package that
> would only provide the UTC timezone.  As part of the discussion around
> this proposal, it was recommended that we completely remove tzdata. We
> appreciated this input and welcome additional feedback.

It would be nice to know the reasons behind the recommendation.  It
seems trying to eliminate tzdata completely is going to require a
significant amount of work and package churn, so why is this the better
path?
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Jonathan Wakely]

On Fri, 30 Jun 2023 at 16:38, Ian Pilcher wrote:
> Rather than expecting runtimes and applications to be fixed to work
> without any timezone information, perhaps the best way forward would be
> to create a tzdata-utc (and similar Java and Python packages).
>
> (Sorry if this has already been suggested & rejected.  I don't remember
> seeing it in this thread, but ...)

From the change proposal:

== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone.  As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Stephen Smoogen]

On Fri, 30 Jun 2023 at 11:39, Ian Pilcher  wrote:

> On 6/30/23 10:22, Jonathan Wakely wrote:
> > On Mon, 26 Jun 2023 at 19:10, Miro Hrončok  wrote:
> >> We would also need to ensure UTC work even without tzdata installed.
> >
> > Yes, that would be useful.
> >
> > Although IMHO even that seems like a nice-to-have not an absolute
> > showstopper. Most containerized workloads that don't need time zone
> > info probably aren't using ZoneInfo("UTC") to convert from UTC to UTC,
> > they're probably not using ZoneInfo at all.
> >
> >>
> >> I would be reluctant to carry this as a downstream-only patch. And the
> upstream
> >> window for changes like this has already closed for Python 3.12.
>
> Rather than expecting runtimes and applications to be fixed to work
> without any timezone information, perhaps the best way forward would be
> to create a tzdata-utc (and similar Java and Python packages).
>
> (Sorry if this has already been suggested & rejected.  I don't remember
> seeing it in this thread, but ...)
>
>
I have not seen it and I think it is probably the best way to deal with
this. Going from how many sysadmin tasks I have dealt with where tzdata is
broken on a system.. a LOT of existing code being used in a lot of places
is silently relying on it.. usually in ways where you end up with a bad
crash long after startup, etc. A bare set of whatever fulfills utc and/or
defaults from LANG=C would at least get them working.

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Ian Pilcher]

On 6/30/23 10:22, Jonathan Wakely wrote:

On Mon, 26 Jun 2023 at 19:10, Miro Hrončok  wrote:

We would also need to ensure UTC work even without tzdata installed.


Yes, that would be useful.

Although IMHO even that seems like a nice-to-have not an absolute
showstopper. Most containerized workloads that don't need time zone
info probably aren't using ZoneInfo("UTC") to convert from UTC to UTC,
they're probably not using ZoneInfo at all.



I would be reluctant to carry this as a downstream-only patch. And the upstream
window for changes like this has already closed for Python 3.12.


Rather than expecting runtimes and applications to be fixed to work
without any timezone information, perhaps the best way forward would be
to create a tzdata-utc (and similar Java and Python packages).

(Sorry if this has already been suggested & rejected.  I don't remember
seeing it in this thread, but ...)

--

Google  Where SkyNet meets Idiocracy

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Jonathan Wakely]

On Mon, 26 Jun 2023 at 19:10, Miro Hrončok  wrote:
>
> Hello Patsy,
>
> On 26. 06. 23 17:54, Aoife Moloney wrote:
> > https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata
> >
> > == Summary ==
> > Allow the removal of tzdata especially on containers in order to minimize 
> > size.
> > ...
> >
> > In order for this to work, we need packages that use tzdata at run
> > time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
> > packages should also gracefully handle instances where tzdata has been
> > removed.  For example, this would require recognizing that tzdata is
> > not present and providing an appropriate error, such as recommending
> > that the user install tzdata.
> > ...
> > * python3.XX (3.9, 3.10, 3.11, 3.12)
>
> Who is expected to work on this? Python maintainers or this Change proposal 
> owners?
>
> *PEP 615 – Support for the IANA Time Zone Database in the Standard Library* 
> says:
>
>
> """
> Python distributors are encouraged to ensure that time zone data is installed
> alongside Python whenever possible (e.g. by declaring tzdata as a dependency
> for the python package).
> """
>
> from https://peps.python.org/pep-0615/#system-time-zone-information
>
>
> By changing the Requires to Recommends, we would diverge from upstream
> recommendation.
>
> ---
>
> The current problem with Python without tzdata is:
>
> ===
>  >>> from zoneinfo import ZoneInfo
>  >>> ZoneInfo("Europe/Prague")
> Traceback (most recent call last):
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
>  return resources.files(package_name).joinpath(resource_name).open("rb")
> ^
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, in 
> files
>  return from_package(get_package(package))
>  
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, in
> get_package
>  resolved = resolve(package)
> 
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, in 
> resolve
>  return cand if isinstance(cand, types.ModuleType) else
> importlib.import_module(cand)
>
> ^
>File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in 
> import_module
>  return _bootstrap._gcd_import(name[level:], package, level)
> 
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1140, in _find_and_load_unlocked
> ModuleNotFoundError: No module named 'tzdata'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
>  raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
> Europe/Prague'

This error looks very similar to the one for a non-existent timezone,
e.g. if I have tzdata installed and create ZoneInfo("Fake/McFakeface")
then I get exactly the same error except for the string
"Europe/Prague" in the last line. So it seems like it's actually
working fine. With no tzdata installed, all time zones are treated as
unknown, with the same result as requesting a completely bogus time
zone.



> ===
>
> Not that ZoneInfo("UTC") also fails:
>
> ===
>  >>> ZoneInfo("UTC")
> Traceback (most recent call last):
> ...
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> ===
>
> So we would need to patch Python to detect missing tzdata and report something
> like:
>
>   ZoneInfoNotInstalledError: 'No time zone information installed on the 
> system,
> you can only use UTC'

I'm not sure that's really needed. You can just treat missing tzdata
as the extreme case of an unknown time zone, where they're all
unknown.

>
> We would also need to ensure UTC work even without tzdata installed.

Yes, that would be useful.

Although IMHO even that seems like a nice-to-have not an absolute
showstopper. Most containerized workloads that don't need time zone
info probably aren't using ZoneInfo("UTC") to convert from UTC to UTC,
they're probably not using ZoneInfo at all.

>
> I 

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Miro Hrončok]

On 29. 06. 23 17:57, Carlos O'Donell wrote:

On 6/29/23 00:44, Miro Hrončok wrote:

On 29. 06. 23 0:31, Carlos O'Donell wrote:

Can we allow users to create a minimal installation by hand, while still 
complying
with PEP-615 for default installs?

The size savings for a minimal container that is UTC-only would be quite 
valuable
for Fedora minimal containers.

Yes, but see the rest of my email.



Just for clarity, and 3-way-communication:

(a) You are concerned about the UTC case failing today.


I am. It seems that without tzdata, we cannot even use UTC in Python.


(b) You would like to see an upstream patch to python to detect missing tzdata 
and report something like:

 ZoneInfoNotInstalledError: 'No time zone information installed on the 
system, you can only use UTC'


Yes.


(c) You would like to ensure UTC works even without tzdata installed.


Indeed.


(d) You don't want to carry a downstream patch, but you would be OK with a 
backported upstream patch?


I don't. Probably OK, depending on the size of it, but I don't expect this to 
be super complex.



Does that match your expectations?


All 4 points match my expectations 100%, but I also have another one:

(e) The Python Maint team currently has no capacity to drive this upstream in 
the Fedora 39 development cycle. We are in the middle of the Python 3.12 rebase.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/28/23 19:54, Michael Catanzaro wrote:
> Because Recommends and Supplements are installed by default, we need
> to be careful and use them sparingly, only when it really makes sense
> for some package to be pulled in for almost all users of another
> package. Thus far, Fedora and RHEL have done a good job of this,
> primarily because we were very late to the weak dep party and have
> had much more time to learn best practices and much less time to
> screw up. This is in contrast to some other distros where it's common
> for users to disable weak deps to avoid "bloat." We don't ever want
> our Recommends/Supplements to be considered bloat. (That's what
> Suggests/Enhances is for. :) And since they're not bloat, they should
> be respected when building most non-minimal images.

I agree.

Do you consider the removal of tzdata to be a valuable use of Recommends?

It is my opinion that glibc should Recommends: tzdata because it frees up an 
optional
~8MiB of zoneinfo that will never be used by UTC-only microservice workloads. 
It is
a further refinement of having really small containers with LANG=C.UTF-8/C and 
TZ=UTC.

Some spec files will need BuildRequires: tzdata, because their %check and 
testsuite
run needs it. In addition to this we should continue to adopt Fedora CI and 
test the
results as required in an installed scenario (with or without tzdata as your 
package
might need to test).

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/29/23 00:44, Miro Hrončok wrote:
> On 29. 06. 23 0:31, Carlos O'Donell wrote:
>> Can we allow users to create a minimal installation by hand, while still 
>> complying
>> with PEP-615 for default installs?
>>
>> The size savings for a minimal container that is UTC-only would be quite 
>> valuable
>> for Fedora minimal containers.
> Yes, but see the rest of my email.
> 

Just for clarity, and 3-way-communication:

(a) You are concerned about the UTC case failing today.

(b) You would like to see an upstream patch to python to detect missing tzdata 
and report something like:

ZoneInfoNotInstalledError: 'No time zone information installed on the 
system, you can only use UTC'

(c) You would like to ensure UTC works even without tzdata installed.

(d) You don't want to carry a downstream patch, but you would be OK with a 
backported upstream patch?

Does that match your expectations?

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Miro Hrončok]

On 29. 06. 23 0:31, Carlos O'Donell wrote:

Can we allow users to create a minimal installation by hand, while still 
complying
with PEP-615 for default installs?

The size savings for a minimal container that is UTC-only would be quite 
valuable
for Fedora minimal containers.

Yes, but see the rest of my email.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Michael Catanzaro]

On Thu, Jun 29 2023 at 12:24:23 AM +0200, Fabio Valentini 
 wrote:
Thanks for the clarification, though this is only partially 
reassuring:

I'm not sure how this accounts for the fact that there are some
situations in which weak dependencies are *not installed at all*.
Most notably, they are not installed into build environments *at all*
(i.e. mock sets `install_weak_deps=0`).


I guess this is OK. It's not what I would have expected, but if 
something important winds up missing, it just means you need more 
BuildRequires and is generally not a big deal.



I'm not sure how the process that builds ISOs and container images
handle this, but I assume they set this option as well.
So we'd need to be careful not to remove "hard" dependencies on tzdata
and replace them with lots of "weak" dependencies all over the place -
just to find out that it ends up missing from important places because
they disable weak dependencies.


For Recommends/Supplements weak dependencies to be useful, packagers 
must be able to assume they are installed by default. With that 
assumption, you can stop second-guessing when to use weak deps; without 
that assumption, nothing works and the weak deps are not useful.  
Accordingly, most ISOs, container images, etc. should be built with 
weak dependencies enabled; it would be a serious bug if weak deps were 
missing from the Fedora Workstation images, for example. Opting out of 
weak deps should be done with the understanding that there will be 
degraded functionality and some features will not work. E.g. minimal 
images will want to be really minimal and not install the weak deps, 
even though this means missing timezones.


Because Recommends and Supplements are installed by default, we need to 
be careful and use them sparingly, only when it really makes sense for 
some package to be pulled in for almost all users of another package. 
Thus far, Fedora and RHEL have done a good job of this, primarily 
because we were very late to the weak dep party and have had much more 
time to learn best practices and much less time to screw up. This is in 
contrast to some other distros where it's common for users to disable 
weak deps to avoid "bloat." We don't ever want our 
Recommends/Supplements to be considered bloat. (That's what 
Suggests/Enhances is for. :) And since they're not bloat, they should 
be respected when building most non-minimal images.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/28/23 18:24, Fabio Valentini wrote:
> On Thu, Jun 29, 2023 at 12:15 AM Carlos O'Donell 
> wrote:
>> 
>> On 6/26/23 16:12, Fabio Valentini wrote:
>>> So all this considered, I'm not sure whether this change is
>>> actually worth it, if tzdata databases of some form will likely
>>> be pulled into installs anyway.
>> 
>> Quoting the "Weak Dependencies Policy":
>> 
>> "Weak dependencies allow smaller minimal installations while
>> keeping the default installation feature rich."
>> 
>> The change is worth it for minimizing container runtimes based on
>> Fedora.
>> 
>> Just for clarity, a default install will always have tzdata.
>> 
>>> I'd rather have *one* tzdata that's up-to-date and used by
>>> everything (for example, so Python and Ruby programs can actually
>>> agree what time it is).
>> I agree strongly with this statement.
>> 
>> I have worked with Patsy over the years to remove as many bundled
>> copies of out-of-date tzdata as we can find :-)
>> 
>> It is important for consistency that all language runtimes have the
>> same concept of time.
>> 
>> This change request does not change that.
> 
> Thanks for the clarification, though this is only partially
> reassuring: I'm not sure how this accounts for the fact that there
> are some situations in which weak dependencies are *not installed at
> all*. Most notably, they are not installed into build environments
> *at all* (i.e. mock sets `install_weak_deps=0`).

Yes, this is a general issue with all weak dependencies.

This is similar to the "minimal buildroot" conversation, whose conclusion was
that we should not dictate what should be in the minimal buildroot but have
the packages express the dependencies as required for their build and check
phases.

See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#buildrequires
~~~
You MAY assume that enough of an environment exists for RPM to function, 
to build packages and execute basic shell scripts, but you SHOULD NOT 
assume any other packages are present as RPM dependencies and anything
brought into the buildroot by the build system can change over time.
~~~
https://pagure.io/packaging-committee/issue/497

We have two options:

- glibc-devel 'Requires: tzdata' (close to the current behaviour)
- All packages that neeed tzdata in rpm %check tests add 'BuildRequires: tzdata'

If a testsuite runs in %check and needs tzdata it seems to me that it is 
valuable
to express this as 'BuildRequires: tzdata'. Therefore I lean towards the latter
solution of having packages that truly need tzdata for testing all of their
code to 'BuildRequires: tzdata', but only if actually required.
 
> I'm not sure how the process that builds ISOs and container images 
> handle this, but I assume they set this option as well. So we'd need
> to be careful not to remove "hard" dependencies on tzdata and replace
> them with lots of "weak" dependencies all over the place - just to
> find out that it ends up missing from important places because they
> disable weak dependencies.

Building ISOs and container images must install Recommends: by default otherwise
the Weak Dependency Policy would not work in Fedora.

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/26/23 14:14, Peter Robinson wrote:
> On Mon, Jun 26, 2023 at 7:10 PM Miro Hrončok  wrote:
>> *PEP 615 – Support for the IANA Time Zone Database in the Standard Library* 
>> says:
>>
>>
>> """
>> Python distributors are encouraged to ensure that time zone data is installed
> 
> The wording of "encouraged to ensure" doesn't sound like a hard
> requirement to me based on a lot of specs I've dealt with, but it
> depends a bit on how the specific spec defines "encouraged".
> 
>> alongside Python whenever possible (e.g. by declaring tzdata as a dependency
>> for the python package).
>> """
>>
>> from https://peps.python.org/pep-0615/#system-time-zone-information
>>
>>
>> By changing the Requires to Recommends, we would diverge from upstream
>> recommendation.

I agree with Peter. The "Recommends:" will ensure tzdata is installed by 
default.

This work lines up exactly with the Fedora Weak Dependencies Policy:
"Weak dependencies allow smaller minimal installations while keeping the default
 installation feature rich."

Can we allow users to create a minimal installation by hand, while still 
complying
with PEP-615 for default installs?

The size savings for a minimal container that is UTC-only would be quite 
valuable
for Fedora minimal containers.

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Fabio Valentini]

On Thu, Jun 29, 2023 at 12:15 AM Carlos O'Donell  wrote:
>
> On 6/26/23 16:12, Fabio Valentini wrote:
> > So all this considered, I'm not sure whether this change is actually
> > worth it, if tzdata databases of some form will likely be pulled into
> > installs anyway.
>
> Quoting the "Weak Dependencies Policy":
>
> "Weak dependencies allow smaller minimal installations while keeping the 
> default
>  installation feature rich."
>
> The change is worth it for minimizing container runtimes based on Fedora.
>
> Just for clarity, a default install will always have tzdata.
>
> > I'd rather have *one* tzdata that's up-to-date and used by everything
> > (for example, so Python and Ruby programs can actually agree what time
> > it is).
> I agree strongly with this statement.
>
> I have worked with Patsy over the years to remove as many bundled copies of 
> out-of-date
> tzdata as we can find :-)
>
> It is important for consistency that all language runtimes have the same 
> concept of time.
>
> This change request does not change that.

Thanks for the clarification, though this is only partially reassuring:
I'm not sure how this accounts for the fact that there are some
situations in which weak dependencies are *not installed at all*.
Most notably, they are not installed into build environments *at all*
(i.e. mock sets `install_weak_deps=0`).

I'm not sure how the process that builds ISOs and container images
handle this, but I assume they set this option as well.
So we'd need to be careful not to remove "hard" dependencies on tzdata
and replace them with lots of "weak" dependencies all over the place -
just to find out that it ends up missing from important places because
they disable weak dependencies.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/26/23 14:40, Vít Ondruch wrote:
> Yep, this is the case for rubygem-tzinfo. It would deserve recommends
> at minimum, because in theory, the tzdata can be suplied by
> tzinfo-data gem instead.

Thank you for adding the `Recommends: tzdata`!

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/26/23 16:12, Fabio Valentini wrote:
> So all this considered, I'm not sure whether this change is actually
> worth it, if tzdata databases of some form will likely be pulled into
> installs anyway.

Quoting the "Weak Dependencies Policy":

"Weak dependencies allow smaller minimal installations while keeping the 
default 
 installation feature rich."

The change is worth it for minimizing container runtimes based on Fedora.

Just for clarity, a default install will always have tzdata.

> I'd rather have *one* tzdata that's up-to-date and used by everything
> (for example, so Python and Ruby programs can actually agree what time
> it is).
I agree strongly with this statement.

I have worked with Patsy over the years to remove as many bundled copies of 
out-of-date
tzdata as we can find :-)

It is important for consistency that all language runtimes have the same 
concept of time.

This change request does not change that.

With a weak dependency on tzdata the default installs will still have it, but 
someone
making a specifically UTC-only container should be able to remove it.

Python, and other language runtimes should be capable of getting to a point 
where they
operate correctly with only C.UTF-8 (no language packs) and UTC (no tzdata).

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/27/23 05:38, Jiri Vanek wrote:
> JDK will behave similarly. We ave (small) advantage that we have also
> in-jdk-bundled tzdata.  However fallback in case of removed system
> tzdata is not automatic, and requires human touch. Long ago we have a
> patch in jdk which looked to system tzdata - if they were present,
> they were used.  If not, the bundled copy was used.  Also user could
> set up on startup which to use. But it had not prooved itself, as it
> was casue of weird missonfigurations.

Please note that we are only talking about tzdata, not tzdata-java.

We do not intend to allow the removal of tzdata-java because OpenJDK depends 
upon it.

When you say "in-jdk-bundled tzdata" do you mean something other than 
tzdata-java?

> If this proposal will come live, we may introduce this patch again, or
> leave it as it is now - on human touch.

Could you please expand a bit more on this topic?

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/28/23 03:44, Miroslav Lichvar wrote:
> On Mon, Jun 26, 2023 at 04:54:00PM +0100, Aoife Moloney wrote:
>> * Other developers: Some packages need to change their spec files from
>> `Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
>> all packages switched in this way, but it is not required. Supporting
>> optional tzdata installation for as many workloads as possible allows
>> those workloads to minimize their container image size.
>> List of packages which need to be changed:
>> * glibc (glibc-common)
> 
> There are packages that rely on the glibc->glibc-common->tzdata
> dependency. The one I know is chrony, which in the default
> configuration needs the "right/UTC" timezone to get the TAI-UTC
> offset. I suspect there are other packages that will need to add
> Recommends or Requires.
 
Thanks, filed against chrony to fix that.

chrony: Uses right/UTC and needs Requires: tzdata
https://bugzilla.redhat.com/show_bug.cgi?id=2218368

My opinion is that this all part of the work required to make the distribution
more flexible for deploying as the basis for containerized workloads.

If you know of any other such missing dependencies we should file bugs and
get them fixed.

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Vít Ondruch]

Dne 27. 06. 23 v 10:13 Vít Ondruch napsal(a):


Dne 26. 06. 23 v 22:12 Fabio Valentini napsal(a):

On Mon, Jun 26, 2023 at 8:40 PM Vít Ondruch  wrote:


Dne 26. 06. 23 v 20:24 Fabio Valentini napsal(a):
On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  
wrote:

(snip)


---

The current problem with Python without tzdata is:

=== 


   >>> from zoneinfo import ZoneInfo
   >>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
 File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in 
load_tzdata
   return 
resources.files(package_name).joinpath(resource_name).open("rb")

  ^
 File "/usr/lib64/python3.11/importlib/resources/_common.py", 
line 22, in files

   return from_package(get_package(package))
   
 File "/usr/lib64/python3.11/importlib/resources/_common.py", 
line 53, in

get_package
   resolved = resolve(package)
  
 File "/usr/lib64/python3.11/importlib/resources/_common.py", 
line 44, in resolve

   return cand if isinstance(cand, types.ModuleType) else
importlib.import_module(cand)

^
 File "/usr/lib64/python3.11/importlib/__init__.py", line 126, 
in import_module

   return _bootstrap._gcd_import(name[level:], package, level)

 File "", line 1204, in _gcd_import
 File "", line 1176, in 
_find_and_load
 File "", line 1126, in 
_find_and_load_unlocked
 File "", line 241, in 
_call_with_frames_removed

 File "", line 1204, in _gcd_import
 File "", line 1176, in 
_find_and_load
 File "", line 1126, in 
_find_and_load_unlocked
 File "", line 241, in 
_call_with_frames_removed

 File "", line 1204, in _gcd_import
 File "", line 1176, in 
_find_and_load
 File "", line 1140, in 
_find_and_load_unlocked

ModuleNotFoundError: No module named 'tzdata'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in 
load_tzdata
   raise ZoneInfoNotFoundError(f"No time zone found with key 
{key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with 
key Europe/Prague'
=== 



Not that ZoneInfo("UTC") also fails:

=== 


   >>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with 
key UTC'
=== 



So we would need to patch Python to detect missing tzdata and 
report something

like:

    ZoneInfoNotInstalledError: 'No time zone information installed 
on the system,

you can only use UTC'

We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And 
the upstream

window for changes like this has already closed for Python 3.12.

Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?
Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.

There's a similar issue with some Rust libraries (and probably other
language-specific timezone handling libraries),


Yep, this is the case for rubygem-tzinfo. It would deserve 
recommends at
minimum, because in theory, the tzdata can be suplied by tzinfo-data 
gem

instead.

That might work with something like

Requires: (tzdata or rubygem(tzinfo-data))



We don't have rubygem-tzinfo-data in Fedora. But it can be installed 
via `gem install` or Bundler. So that is the reason for soft dependency.




I have added the soft dependency into rubygem-tzinfo:

https://src.fedoraproject.org/rpms/rubygem-tzinfo/c/6822ef00ad1b64a81ddd64c1728e49fa309d7603?branch=rawhide

If nothing else, the dependency will be visible now.


Vít



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Miroslav Lichvar]

On Mon, Jun 26, 2023 at 04:54:00PM +0100, Aoife Moloney wrote:
> * Other developers: Some packages need to change their spec files from
> `Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
> all packages switched in this way, but it is not required. Supporting
> optional tzdata installation for as many workloads as possible allows
> those workloads to minimize their container image size.
> List of packages which need to be changed:
> * glibc (glibc-common)

There are packages that rely on the glibc->glibc-common->tzdata
dependency. The one I know is chrony, which in the default
configuration needs the "right/UTC" timezone to get the TAI-UTC
offset. I suspect there are other packages that will need to add
Recommends or Requires.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[John Reiser]

On 6/27/23 02:00, Miro Hrončok wrote:

On 26. 06. 23 20:24, Fabio Valentini wrote:

On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:




(snip)


---

The current problem with Python without tzdata is:

===
  >>> from zoneinfo import ZoneInfo
  >>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
    ...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
Europe/Prague'
===

Not that ZoneInfo("UTC") also fails:

===
  >>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
===

So we would need to patch Python to detect missing tzdata and report something
like:

   ZoneInfoNotInstalledError: 'No time zone information installed on the system,
you can only use UTC'

We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And the upstream
window for changes like this has already closed for Python 3.12.


Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?


Yes. That's why it is Required and not Recommended.


Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.


Either that or adapt their code to fail in a reasonable way. Both sound quite 
unreasonable to me.



The case with LANG seems analogous.  If LANG is unset, then any software
should use the default LANG=C, and should work acceptably well.
If TZ is unset (or there is no other indication
of which timezone to use, or if the timezone data is unavailable)
then any software should use UTC, and should work acceptably well.
(In formal scientific work then UTC *is* the default timezone.)
For either unset LANG or missing timezone info, it is optional
for an application to emit a polite informative message *once* on stderr.
In particular, the zoneinfo module should handle all the details
so that individual applications need not bother.
.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Patsy Griffin]

Hi Miro,

Very much appreciate the feedback. Please see my responses below.

Thank you,
Patsy

On Mon, Jun 26, 2023 at 2:09 PM Miro Hrončok  wrote:

> Hello Patsy,
>
> On 26. 06. 23 17:54, Aoife Moloney wrote:
> > https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata
> >
> > == Summary ==
> > Allow the removal of tzdata especially on containers in order to
> minimize size.
> > ...
> >
> > In order for this to work, we need packages that use tzdata at run
> > time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
> > packages should also gracefully handle instances where tzdata has been
> > removed.  For example, this would require recognizing that tzdata is
> > not present and providing an appropriate error, such as recommending
> > that the user install tzdata.
> > ...
> > * python3.XX (3.9, 3.10, 3.11, 3.12)
>
> Who is expected to work on this? Python maintainers or this Change
> proposal owners?
>


This does not change the default.  It allows users to remove tzdata if they
want to minimize their container.  (Note: currently we are seeing cases
where just the data is removed leaving tzdata in an inconsistent state.)

We will work with maintainers as needed.  The respective package owners are
more knowledgeable in the changes needed to check for the availability of
tzdata and respond appropriately, such as informing the user that tzdata
needs to be installed.


> *PEP 615 – Support for the IANA Time Zone Database in the Standard
> Library* says:
>
>
> """
> Python distributors are encouraged to ensure that time zone data is
> installed
> alongside Python whenever possible (e.g. by declaring tzdata as a
> dependency
> for the python package).
> """
>
> from https://peps.python.org/pep-0615/#system-time-zone-information
>
>
> By changing the Requires to Recommends, we would diverge from upstream
> recommendation.
>
> ---
>
> The current problem with Python without tzdata is:
>
> ===
>  >>> from zoneinfo import ZoneInfo
>  >>> ZoneInfo("Europe/Prague")
> Traceback (most recent call last):
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in
> load_tzdata
>  return
> resources.files(package_name).joinpath(resource_name).open("rb")
> ^
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22,
> in files
>  return from_package(get_package(package))
>  
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53,
> in
> get_package
>  resolved = resolve(package)
> 
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44,
> in resolve
>  return cand if isinstance(cand, types.ModuleType) else
> importlib.import_module(cand)
>
> ^
>File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in
> import_module
>  return _bootstrap._gcd_import(name[level:], package, level)
> 
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in
> _find_and_load_unlocked
>File "", line 241, in
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in
> _find_and_load_unlocked
>File "", line 241, in
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1140, in
> _find_and_load_unlocked
> ModuleNotFoundError: No module named 'tzdata'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in
> load_tzdata
>  raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key
> Europe/Prague'
> ===
>
> Not that ZoneInfo("UTC") also fails:
>
> ===
>  >>> ZoneInfo("UTC")
> Traceback (most recent call last):
> ...
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> ===
>
> So we would need to patch Python to detect missing tzdata and report
> something
> like:
>
>   ZoneInfoNotInstalledError: 'No time zone information installed on the
> system,
> you can only use UTC'
>

 Yes, or possibly recommend installing tzdata if additional timezone info
is needed.


> We would also need to ensure UTC work even without tzdata installed.
>
> I would be reluctant to carry this as a downstream-only patch. And the
> upstream
> window for changes like this has already closed for Python 3.12.
>

Understood.


>
> --

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Jiri Vanek]

JDK will behave similarly. We ave (small) advantage that we have also
in-jdk-bundled tzdata.  However fallback in case of removed system
tzdata is not automatic, and requires human touch. Long ago we have a
patch in jdk which looked to system tzdata - if they were present,
they were used.  If not, the bundled copy was used.  Also user could
set up on startup which to use. But it had not prooved itself, as it
was casue of weird missonfigurations.

If this proposal will come live, we may introduce this patch again, or
leave it as it is now - on human touch.

TY!

 J.

On Tue, 27 Jun 2023 at 11:00, Miro Hrončok  wrote:
>
> On 26. 06. 23 20:24, Fabio Valentini wrote:
> > On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:
> >>
> >
> > (snip)
> >
> >> ---
> >>
> >> The current problem with Python without tzdata is:
> >>
> >> ===
> >>   >>> from zoneinfo import ZoneInfo
> >>   >>> ZoneInfo("Europe/Prague")
> >> Traceback (most recent call last):
> >> ...
> >> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
> >> Europe/Prague'
> >> ===
> >>
> >> Not that ZoneInfo("UTC") also fails:
> >>
> >> ===
> >>   >>> ZoneInfo("UTC")
> >> Traceback (most recent call last):
> >> ...
> >> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> >> ===
> >>
> >> So we would need to patch Python to detect missing tzdata and report 
> >> something
> >> like:
> >>
> >>ZoneInfoNotInstalledError: 'No time zone information installed on the 
> >> system,
> >> you can only use UTC'
> >>
> >> We would also need to ensure UTC work even without tzdata installed.
> >>
> >> I would be reluctant to carry this as a downstream-only patch. And the 
> >> upstream
> >> window for changes like this has already closed for Python 3.12.
> >
> > Does this mean that tzdata needs to be present for doing datetime /
> > timezone calculations at runtime with the zoneinfo module?
>
> Yes. That's why it is Required and not Recommended.
>
> > Would this Change require that all Python programs that use this
> > module add "Requires: tzdata"? I don't think that would be a
> > reasonable change.
>
> Either that or adapt their code to fail in a reasonable way. Both sound quite
> unreasonable to me.
>
> > There's a similar issue with some Rust libraries (and probably other
> > language-specific timezone handling libraries), where they explicitly
> > assume that the timezone database is available, and will either fail
> > (bad case) or fall back to UTC (less bad case). Similar to the Python
> > case, I don't think adding "Requires: tzdata" to all packages like
> > these (either to the library in the case of dynamically linked /
> > scripting languages, or to all affected *applications* in the case of
> > statically linked languages) would be reasonable.
>
> Thanks for sharing a similar concern.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Miro Hrončok]

On 26. 06. 23 20:24, Fabio Valentini wrote:

On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:




(snip)


---

The current problem with Python without tzdata is:

===
  >>> from zoneinfo import ZoneInfo
  >>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
Europe/Prague'
===

Not that ZoneInfo("UTC") also fails:

===
  >>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
===

So we would need to patch Python to detect missing tzdata and report something
like:

   ZoneInfoNotInstalledError: 'No time zone information installed on the system,
you can only use UTC'

We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And the upstream
window for changes like this has already closed for Python 3.12.


Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?


Yes. That's why it is Required and not Recommended.


Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.


Either that or adapt their code to fail in a reasonable way. Both sound quite 
unreasonable to me.



There's a similar issue with some Rust libraries (and probably other
language-specific timezone handling libraries), where they explicitly
assume that the timezone database is available, and will either fail
(bad case) or fall back to UTC (less bad case). Similar to the Python
case, I don't think adding "Requires: tzdata" to all packages like
these (either to the library in the case of dynamically linked /
scripting languages, or to all affected *applications* in the case of
statically linked languages) would be reasonable.


Thanks for sharing a similar concern.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Vít Ondruch]

Dne 26. 06. 23 v 22:12 Fabio Valentini napsal(a):

On Mon, Jun 26, 2023 at 8:40 PM Vít Ondruch  wrote:


Dne 26. 06. 23 v 20:24 Fabio Valentini napsal(a):

On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:
(snip)


---

The current problem with Python without tzdata is:

===
   >>> from zoneinfo import ZoneInfo
   >>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
 File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
   return resources.files(package_name).joinpath(resource_name).open("rb")
  ^
 File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, in 
files
   return from_package(get_package(package))
   
 File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, in
get_package
   resolved = resolve(package)
  
 File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, in 
resolve
   return cand if isinstance(cand, types.ModuleType) else
importlib.import_module(cand)

^
 File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in 
import_module
   return _bootstrap._gcd_import(name[level:], package, level)
  
 File "", line 1204, in _gcd_import
 File "", line 1176, in _find_and_load
 File "", line 1126, in _find_and_load_unlocked
 File "", line 241, in 
_call_with_frames_removed
 File "", line 1204, in _gcd_import
 File "", line 1176, in _find_and_load
 File "", line 1126, in _find_and_load_unlocked
 File "", line 241, in 
_call_with_frames_removed
 File "", line 1204, in _gcd_import
 File "", line 1176, in _find_and_load
 File "", line 1140, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'tzdata'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
   raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
Europe/Prague'
===

Not that ZoneInfo("UTC") also fails:

===
   >>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
===

So we would need to patch Python to detect missing tzdata and report something
like:

ZoneInfoNotInstalledError: 'No time zone information installed on the 
system,
you can only use UTC'

We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And the upstream
window for changes like this has already closed for Python 3.12.

Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?
Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.

There's a similar issue with some Rust libraries (and probably other
language-specific timezone handling libraries),


Yep, this is the case for rubygem-tzinfo. It would deserve recommends at
minimum, because in theory, the tzdata can be suplied by tzinfo-data gem
instead.

That might work with something like

Requires: (tzdata or rubygem(tzinfo-data))



We don't have rubygem-tzinfo-data in Fedora. But it can be installed via 
`gem install` or Bundler. So that is the reason for soft dependency.



Vít



Suggests: tzdata

(similarly for python, since there's a tzdata package on pypi as well)

But this comes at the cost of still pulling in tzdata, potentially in
different flavors and formats, in different stages of being outdated,
further bloating install size ... which is what this change is trying
to avoid?

So all this considered, I'm not sure whether this change is actually
worth it, if tzdata databases of some form will likely be pulled into
installs anyway.
I'd rather have *one* tzdata that's up-to-date and used by everything
(for example, so Python and Ruby programs can actually agree what time
it is).

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to 

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Fabio Valentini]

On Mon, Jun 26, 2023 at 8:40 PM Vít Ondruch  wrote:
>
>
> Dne 26. 06. 23 v 20:24 Fabio Valentini napsal(a):
> > On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:
> > (snip)
> >
> >> ---
> >>
> >> The current problem with Python without tzdata is:
> >>
> >> ===
> >>   >>> from zoneinfo import ZoneInfo
> >>   >>> ZoneInfo("Europe/Prague")
> >> Traceback (most recent call last):
> >> File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in 
> >> load_tzdata
> >>   return 
> >> resources.files(package_name).joinpath(resource_name).open("rb")
> >>  ^
> >> File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, 
> >> in files
> >>   return from_package(get_package(package))
> >>   
> >> File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, 
> >> in
> >> get_package
> >>   resolved = resolve(package)
> >>  
> >> File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, 
> >> in resolve
> >>   return cand if isinstance(cand, types.ModuleType) else
> >> importlib.import_module(cand)
> >>
> >> ^
> >> File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in 
> >> import_module
> >>   return _bootstrap._gcd_import(name[level:], package, level)
> >>  
> >> File "", line 1204, in _gcd_import
> >> File "", line 1176, in _find_and_load
> >> File "", line 1126, in 
> >> _find_and_load_unlocked
> >> File "", line 241, in 
> >> _call_with_frames_removed
> >> File "", line 1204, in _gcd_import
> >> File "", line 1176, in _find_and_load
> >> File "", line 1126, in 
> >> _find_and_load_unlocked
> >> File "", line 241, in 
> >> _call_with_frames_removed
> >> File "", line 1204, in _gcd_import
> >> File "", line 1176, in _find_and_load
> >> File "", line 1140, in 
> >> _find_and_load_unlocked
> >> ModuleNotFoundError: No module named 'tzdata'
> >>
> >> During handling of the above exception, another exception occurred:
> >>
> >> Traceback (most recent call last):
> >> File "", line 1, in 
> >> File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in 
> >> load_tzdata
> >>   raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
> >> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
> >> Europe/Prague'
> >> ===
> >>
> >> Not that ZoneInfo("UTC") also fails:
> >>
> >> ===
> >>   >>> ZoneInfo("UTC")
> >> Traceback (most recent call last):
> >> ...
> >> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> >> ===
> >>
> >> So we would need to patch Python to detect missing tzdata and report 
> >> something
> >> like:
> >>
> >>ZoneInfoNotInstalledError: 'No time zone information installed on the 
> >> system,
> >> you can only use UTC'
> >>
> >> We would also need to ensure UTC work even without tzdata installed.
> >>
> >> I would be reluctant to carry this as a downstream-only patch. And the 
> >> upstream
> >> window for changes like this has already closed for Python 3.12.
> > Does this mean that tzdata needs to be present for doing datetime /
> > timezone calculations at runtime with the zoneinfo module?
> > Would this Change require that all Python programs that use this
> > module add "Requires: tzdata"? I don't think that would be a
> > reasonable change.
> >
> > There's a similar issue with some Rust libraries (and probably other
> > language-specific timezone handling libraries),
>
>
> Yep, this is the case for rubygem-tzinfo. It would deserve recommends at
> minimum, because in theory, the tzdata can be suplied by tzinfo-data gem
> instead.

That might work with something like

Requires: (tzdata or rubygem(tzinfo-data))
Suggests: tzdata

(similarly for python, since there's a tzdata package on pypi as well)

But this comes at the cost of still pulling in tzdata, potentially in
different flavors and formats, in different stages of being outdated,
further bloating install size ... which is what this change is trying
to avoid?

So all this considered, I'm not sure whether this change is actually
worth it, if tzdata databases of some form will likely be pulled into
installs anyway.
I'd rather have *one* tzdata that's up-to-date and used by everything
(for example, so Python and Ruby programs can actually agree what time
it is).

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Vít Ondruch]

Dne 26. 06. 23 v 20:24 Fabio Valentini napsal(a):

On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:
(snip)


---

The current problem with Python without tzdata is:

===
  >>> from zoneinfo import ZoneInfo
  >>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
  return resources.files(package_name).joinpath(resource_name).open("rb")
 ^
File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, in 
files
  return from_package(get_package(package))
  
File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, in
get_package
  resolved = resolve(package)
 
File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, in 
resolve
  return cand if isinstance(cand, types.ModuleType) else
importlib.import_module(cand)

^
File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in 
import_module
  return _bootstrap._gcd_import(name[level:], package, level)
 
File "", line 1204, in _gcd_import
File "", line 1176, in _find_and_load
File "", line 1126, in _find_and_load_unlocked
File "", line 241, in _call_with_frames_removed
File "", line 1204, in _gcd_import
File "", line 1176, in _find_and_load
File "", line 1126, in _find_and_load_unlocked
File "", line 241, in _call_with_frames_removed
File "", line 1204, in _gcd_import
File "", line 1176, in _find_and_load
File "", line 1140, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'tzdata'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
  raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
Europe/Prague'
===

Not that ZoneInfo("UTC") also fails:

===
  >>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
===

So we would need to patch Python to detect missing tzdata and report something
like:

   ZoneInfoNotInstalledError: 'No time zone information installed on the system,
you can only use UTC'

We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And the upstream
window for changes like this has already closed for Python 3.12.

Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?
Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.

There's a similar issue with some Rust libraries (and probably other
language-specific timezone handling libraries),



Yep, this is the case for rubygem-tzinfo. It would deserve recommends at 
minimum, because in theory, the tzdata can be suplied by tzinfo-data gem 
instead.


Vít



  where they explicitly
assume that the timezone database is available, and will either fail
(bad case) or fall back to UTC (less bad case). Similar to the Python
case, I don't think adding "Requires: tzdata" to all packages like
these (either to the library in the case of dynamically linked /
scripting languages, or to all affected *applications* in the case of
statically linked languages) would be reasonable.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, 

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Fabio Valentini]

On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:
>

(snip)

> ---
>
> The current problem with Python without tzdata is:
>
> ===
>  >>> from zoneinfo import ZoneInfo
>  >>> ZoneInfo("Europe/Prague")
> Traceback (most recent call last):
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
>  return resources.files(package_name).joinpath(resource_name).open("rb")
> ^
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, in 
> files
>  return from_package(get_package(package))
>  
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, in
> get_package
>  resolved = resolve(package)
> 
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, in 
> resolve
>  return cand if isinstance(cand, types.ModuleType) else
> importlib.import_module(cand)
>
> ^
>File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in 
> import_module
>  return _bootstrap._gcd_import(name[level:], package, level)
> 
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1140, in _find_and_load_unlocked
> ModuleNotFoundError: No module named 'tzdata'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
>  raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
> Europe/Prague'
> ===
>
> Not that ZoneInfo("UTC") also fails:
>
> ===
>  >>> ZoneInfo("UTC")
> Traceback (most recent call last):
> ...
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> ===
>
> So we would need to patch Python to detect missing tzdata and report something
> like:
>
>   ZoneInfoNotInstalledError: 'No time zone information installed on the 
> system,
> you can only use UTC'
>
> We would also need to ensure UTC work even without tzdata installed.
>
> I would be reluctant to carry this as a downstream-only patch. And the 
> upstream
> window for changes like this has already closed for Python 3.12.

Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?
Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.

There's a similar issue with some Rust libraries (and probably other
language-specific timezone handling libraries), where they explicitly
assume that the timezone database is available, and will either fail
(bad case) or fall back to UTC (less bad case). Similar to the Python
case, I don't think adding "Requires: tzdata" to all packages like
these (either to the library in the case of dynamically linked /
scripting languages, or to all affected *applications* in the case of
statically linked languages) would be reasonable.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Peter Robinson]

On Mon, Jun 26, 2023 at 7:10 PM Miro Hrončok  wrote:
>
> Hello Patsy,
>
> On 26. 06. 23 17:54, Aoife Moloney wrote:
> > https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata
> >
> > == Summary ==
> > Allow the removal of tzdata especially on containers in order to minimize 
> > size.
> > ...
> >
> > In order for this to work, we need packages that use tzdata at run
> > time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
> > packages should also gracefully handle instances where tzdata has been
> > removed.  For example, this would require recognizing that tzdata is
> > not present and providing an appropriate error, such as recommending
> > that the user install tzdata.
> > ...
> > * python3.XX (3.9, 3.10, 3.11, 3.12)
>
> Who is expected to work on this? Python maintainers or this Change proposal 
> owners?
>
> *PEP 615 – Support for the IANA Time Zone Database in the Standard Library* 
> says:
>
>
> """
> Python distributors are encouraged to ensure that time zone data is installed

The wording of "encouraged to ensure" doesn't sound like a hard
requirement to me based on a lot of specs I've dealt with, but it
depends a bit on how the specific spec defines "encouraged".

> alongside Python whenever possible (e.g. by declaring tzdata as a dependency
> for the python package).
> """
>
> from https://peps.python.org/pep-0615/#system-time-zone-information
>
>
> By changing the Requires to Recommends, we would diverge from upstream
> recommendation.
>
> ---
>
> The current problem with Python without tzdata is:
>
> ===
>  >>> from zoneinfo import ZoneInfo
>  >>> ZoneInfo("Europe/Prague")
> Traceback (most recent call last):
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
>  return resources.files(package_name).joinpath(resource_name).open("rb")
> ^
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, in 
> files
>  return from_package(get_package(package))
>  
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, in
> get_package
>  resolved = resolve(package)
> 
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, in 
> resolve
>  return cand if isinstance(cand, types.ModuleType) else
> importlib.import_module(cand)
>
> ^
>File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in 
> import_module
>  return _bootstrap._gcd_import(name[level:], package, level)
> 
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1140, in _find_and_load_unlocked
> ModuleNotFoundError: No module named 'tzdata'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
>  raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
> Europe/Prague'
> ===
>
> Not that ZoneInfo("UTC") also fails:
>
> ===
>  >>> ZoneInfo("UTC")
> Traceback (most recent call last):
> ...
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> ===
>
> So we would need to patch Python to detect missing tzdata and report something
> like:
>
>   ZoneInfoNotInstalledError: 'No time zone information installed on the 
> system,
> you can only use UTC'
>
> We would also need to ensure UTC work even without tzdata installed.
>
> I would be reluctant to carry this as a downstream-only patch. And the 
> upstream
> window for changes like this has already closed for Python 3.12.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> 

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Miro Hrončok]

Hello Patsy,

On 26. 06. 23 17:54, Aoife Moloney wrote:

https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata

== Summary ==
Allow the removal of tzdata especially on containers in order to minimize size.
...

In order for this to work, we need packages that use tzdata at run
time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
packages should also gracefully handle instances where tzdata has been
removed.  For example, this would require recognizing that tzdata is
not present and providing an appropriate error, such as recommending
that the user install tzdata.
...
* python3.XX (3.9, 3.10, 3.11, 3.12)


Who is expected to work on this? Python maintainers or this Change proposal 
owners?

*PEP 615 – Support for the IANA Time Zone Database in the Standard Library* 
says:


"""
Python distributors are encouraged to ensure that time zone data is installed 
alongside Python whenever possible (e.g. by declaring tzdata as a dependency 
for the python package).

"""

from https://peps.python.org/pep-0615/#system-time-zone-information


By changing the Requires to Recommends, we would diverge from upstream 
recommendation.


---

The current problem with Python without tzdata is:

===
>>> from zoneinfo import ZoneInfo
>>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
  File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
return resources.files(package_name).joinpath(resource_name).open("rb")
   ^
  File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, in files
return from_package(get_package(package))

  File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, in 
get_package

resolved = resolve(package)
   
  File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, in 
resolve
return cand if isinstance(cand, types.ModuleType) else 
importlib.import_module(cand)


^
  File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1204, in _gcd_import
  File "", line 1176, in _find_and_load
  File "", line 1126, in _find_and_load_unlocked
  File "", line 241, in _call_with_frames_removed
  File "", line 1204, in _gcd_import
  File "", line 1176, in _find_and_load
  File "", line 1126, in _find_and_load_unlocked
  File "", line 241, in _call_with_frames_removed
  File "", line 1204, in _gcd_import
  File "", line 1176, in _find_and_load
  File "", line 1140, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'tzdata'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
Europe/Prague'
===

Not that ZoneInfo("UTC") also fails:

===
>>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
===

So we would need to patch Python to detect missing tzdata and report something 
like:


 ZoneInfoNotInstalledError: 'No time zone information installed on the system, 
you can only use UTC'


We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And the upstream 
window for changes like this has already closed for Python 3.12.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Aoife Moloney]

https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Allow the removal of tzdata especially on containers in order to minimize size.


== Owner ==
* Name: Patsy Griffin (Franklin)

* Email: pa...@redhat.com


== Detailed Description ==
This change will allow the removal of tzdata.  When tzdata is removed,
the system will default to UTC. In order to reduce overhead, many
container installations now remove the data associated with tzdata but
cannot fully remove the package due to dependencies by other packages.
This results in confusion regarding the expected timezone info.

In order for this to work, we need packages that use tzdata at run
time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
packages should also gracefully handle instances where tzdata has been
removed.  For example, this would require recognizing that tzdata is
not present and providing an appropriate error, such as recommending
that the user install tzdata.

== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone.  As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.


== Benefit to Fedora ==
This change will allow tzdata to be removed from containers without
leaving inconsistent package remnants.


== Scope ==
* Proposal owners: No changes are needed to tzdata.

* Other developers: Some packages need to change their spec files from
`Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
all packages switched in this way, but it is not required. Supporting
optional tzdata installation for as many workloads as possible allows
those workloads to minimize their container image size.
List of packages which need to be changed:
* glibc (glibc-common)
* gcc (libstdc++)
* python3.XX (3.9, 3.10, 3.11, 3.12)
List of packages which would be beneficial to be changed:
* python3-dateutil
* python3-pytz
* libical
Upon acceptance of the change request we will file bugs to fix each of
these packages for Fedora 39.


* Release engineering: No changes needed.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==
If tzdata is already installed, then it continues to be installed on the system.

Following the Fedora Weak Dependencies Policy dnf will treat the
Recommends on tzdata as if it were a Requires and tzdata will always
be installed in a default system
(https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/)

However, the recommends will allow tzdata to be correctly uninstalled
in a container build file rather than having to use ‘rm -rf’ to delete
the zone files to recover space.


== How To Test ==
Language runtimes were installed and A/B tests carried out with tzdata
present and tzdata removed. The intent of these tests was to ensure
that the system can use the language frameworks without tzdata present
and that when the data was required that meaningful errors were
presented to the user.

Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11),
using their time and date APIs. This testing led to the correction of
the libstdc++ implementation as noted here:
https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea42b42c3

Developers can test this by installing Rawhide and uninstalling tzdata
and verifying their package operates as expected.

If tzdata cannot be uninstalled then we recommend filling a bug
against the package that Requires: tzdata and having a discussion with
the maintainer to make tzdata optional e.g. Recommends: tzdata.


== User Experience ==
The user can remove tzdata to minimize the container size.

With tzdata removed the system is UTC only.



== Dependencies ==
Fixing glibc, gcc, and python3.xx at a minimum to make tzdata
Recommends instead of Requires.



== Contingency Plan ==
* Contingency mechanism: Back out the change. Don’t do it.
* Contingency deadline:  Can be backed out at the last minute since we
are only dealing with conversions from Requires to Recommends.
* Blocks release? No

== Documentation ==
Document that the tzdata package may be removed if needed to reduce
space on containers.  With tzdata removed, the system will default to
UTC.


== Release Notes ==



-- 
Aoife Moloney

Product Owner

Community Platform Engineering Team

Red Hat EMEA

Communications House

Cork Road

Waterford
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to 

F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Aoife Moloney]

https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Allow the removal of tzdata especially on containers in order to minimize size.


== Owner ==
* Name: Patsy Griffin (Franklin)

* Email: pa...@redhat.com


== Detailed Description ==
This change will allow the removal of tzdata.  When tzdata is removed,
the system will default to UTC. In order to reduce overhead, many
container installations now remove the data associated with tzdata but
cannot fully remove the package due to dependencies by other packages.
This results in confusion regarding the expected timezone info.

In order for this to work, we need packages that use tzdata at run
time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
packages should also gracefully handle instances where tzdata has been
removed.  For example, this would require recognizing that tzdata is
not present and providing an appropriate error, such as recommending
that the user install tzdata.

== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone.  As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.


== Benefit to Fedora ==
This change will allow tzdata to be removed from containers without
leaving inconsistent package remnants.


== Scope ==
* Proposal owners: No changes are needed to tzdata.

* Other developers: Some packages need to change their spec files from
`Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
all packages switched in this way, but it is not required. Supporting
optional tzdata installation for as many workloads as possible allows
those workloads to minimize their container image size.
List of packages which need to be changed:
* glibc (glibc-common)
* gcc (libstdc++)
* python3.XX (3.9, 3.10, 3.11, 3.12)
List of packages which would be beneficial to be changed:
* python3-dateutil
* python3-pytz
* libical
Upon acceptance of the change request we will file bugs to fix each of
these packages for Fedora 39.


* Release engineering: No changes needed.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==
If tzdata is already installed, then it continues to be installed on the system.

Following the Fedora Weak Dependencies Policy dnf will treat the
Recommends on tzdata as if it were a Requires and tzdata will always
be installed in a default system
(https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/)

However, the recommends will allow tzdata to be correctly uninstalled
in a container build file rather than having to use ‘rm -rf’ to delete
the zone files to recover space.


== How To Test ==
Language runtimes were installed and A/B tests carried out with tzdata
present and tzdata removed. The intent of these tests was to ensure
that the system can use the language frameworks without tzdata present
and that when the data was required that meaningful errors were
presented to the user.

Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11),
using their time and date APIs. This testing led to the correction of
the libstdc++ implementation as noted here:
https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea42b42c3

Developers can test this by installing Rawhide and uninstalling tzdata
and verifying their package operates as expected.

If tzdata cannot be uninstalled then we recommend filling a bug
against the package that Requires: tzdata and having a discussion with
the maintainer to make tzdata optional e.g. Recommends: tzdata.


== User Experience ==
The user can remove tzdata to minimize the container size.

With tzdata removed the system is UTC only.



== Dependencies ==
Fixing glibc, gcc, and python3.xx at a minimum to make tzdata
Recommends instead of Requires.



== Contingency Plan ==
* Contingency mechanism: Back out the change. Don’t do it.
* Contingency deadline:  Can be backed out at the last minute since we
are only dealing with conversions from Requires to Recommends.
* Blocks release? No

== Documentation ==
Document that the tzdata package may be removed if needed to reduce
space on containers.  With tzdata removed, the system will default to
UTC.


== Release Notes ==



-- 
Aoife Moloney

Product Owner

Community Platform Engineering Team

Red Hat EMEA

Communications House

Cork Road

Waterford
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code