#21 ZIP format does not support timestamps before 1980; Silverblue sets 1970
Opened 5 months ago by pviktori. Modified 5 months ago

Silverblue sets the timestamp of files on disk to 1970-01-01, which can't be represented in ZIP files.
The zip utility seems to work around this limitation by silently bumping the timestamp to the first representable date, 1980-01-01 00:00:00.
Python's zipfile module doesn't have this workaround:

$ python3 -m zipfile -c foo.zip /etc/os-release
Traceback (most recent call last):
  ...
ValueError: ZIP does not support timestamps before 1980

(FWIW, I strongly prefer this to silently mangling data!)

This is a problem when bootstrapping Python virtual environments, mentioned in Fedora bug 1599422, the following does not work in Silverblue:

$ python3 -m venv testing
Error: Command '['/tmp/testing/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.

What happens here? When a venv (semi-isolated Python environment) is bootstrapped, pip (the package installer) is installed into it. Python normally bundles pip as a wheel (the Python-native distribution format), but Fedora unbundles this – it's a compiled blob upstream, and it's a needless duplicate of bits already present on disk. Instead, we use rewheel (a Fedora-specific thing) to pack the RPM-installed pip back into a wheel, and feed it to the normal installation machinery.

Wheels are a ZIP-based OS-independent format, and packing Silverblue stuff blows up with the ZIP does not support timestamps before 1980 error.

We can possibly add some workaround to rewheel, but maybe this could be solved at a different level.
How important to Silverblue is having UNIX timestamps of zero? Could it be bumped to 1980 or later, to enable zipping OS components properly?


At a high level I think people should be doing venvs in containers (though that pushes the problem out to when we use ostree for containers):

How important to Silverblue is having UNIX timestamps of zero? Could it be bumped to 1980 or later, to enable zipping OS components properly?

It's how OSTree works, it just uses hardlinks, and we need a canonical timestamp. We can't change it now as it would entail duplicating everything on disk and cause other problems.

I think probably rewheel needs to do the same 1980 canonicalization...or just use the current time, the timestamps don't matter right?

OK.
It will take some time to allow Python zipfile to handle pre-1980 mtimes. I filed a Python upstream issue and assigned Marcel to on it. We'll backport the result to Fedora as soon as it's accepted in Python 3.8; hopefully in a few months at most.

In the mean time, please keep in mind that one of the main advantages of Fedora is not yet functional in Silverblue. It would be nice to not advertise Silverblue as a Workstation replacement until this is solved.

Are there any deadlines I should be aware of?

is not yet functional in Silverblue.

Sure it is: Use a Fedora container. That's what you should be doing anyways even on "classic" Fedora. Example: A developer wants to use Silverblue as a desktop but build applications in Python that target RHEL7. Great! They can use a RHEL7 container, which works the same as a Fedora container.

My comment probably sounded less friendly than I intended. I'm sorry. I do want to emphasize that "Fedora has functioning Python venv" is a major point for Fedora in the Python crowd.

The use case is different -- I want to build applications that target Python in general.
This is the first time I hear that you should always use containers. Why?

If we want people to always use containers, we need to re-think all of our messaging around Python in Fedora. Places like the Developer Portal start with "create a venv". I'm not aware of discussions that this should change.

If we want people to always use containers, we need to re-think all of our messaging around Python in Fedora. Places like the Developer Portal start with "create a venv". I'm not aware of discussions that this should change.

You still haven't done the mental shift: Where you see instructions for "Fedora" - and most particularly developer focused command line things; those are things to do in a Fedora container (or VM) on a CoreOS/Silverblue system.

And yes, I think CoreOS/Silverblue haven't succeeded until containers are the default. Fixing that (IMO) is our mission.

As I understand it, you do not do stuff in CoreOS/Silverblue directly, you only use it as a container host, hence you don't usually develop in Python on CoreOS/Silverblue directly, it's there just as a dependency for container related tools.

One exception might be when you actually develop container related tools that are supposed to work on CoreOS/Silverblue.

How important to Silverblue is having UNIX timestamps of zero? Could it be bumped to 1980 or later, to enable zipping OS components properly?

It's how OSTree works, it just uses hardlinks, and we need a canonical timestamp. We can't change it now as it would entail duplicating everything on disk and cause other problems.

Why isn't the timestamp clamped to what the package data contains? This seems fundamentally broken.

Why isn't the timestamp clamped to what the package data contains? This seems fundamentally broken.

When e.g. a rebuild happens for whatever reason, or a package is bumped for a spec file change - or generally anything that doesn't result in the content changing, there are now two (or more) possible timestamps for identical content.

There is more information here
https://mail.gnome.org/archives/ostree-list/2013-December/msg00001.html
and here https://bugzilla.redhat.com/show_bug.cgi?id=1229160
etc.

Compare with the way e.g. Docker/OCI works - by default, the content isn't deduplicated on disk. If something like that were to be implemented it'd need to rely on reflinks.

OSTree predates overlayfs and reflinks. It's proved that one can implement a transactional upgrade system with just plain hardlinks - but yes, some userspace changes are necessary. So far...the benefits of moving to a reflink approach just aren't worth it, at this point most of the userspace that we care about has adapted.

Login to comment on this ticket.

Metadata