#1126000 snapshot.debian.org: Preserve timestamps

#1126000#5
Date:
2026-01-20 08:19:01 UTC
From:
To:
Hello maintainers of snapshot.debian.org,

While trying to reproduce the official live images of Debian, I've noticed that the timestamp of .deb files differ between deb.debian.org and snapshot.debian.org [1].

An example: (Downloaded with wcurl, then: TZ="Z" ls --time-style=+%s -l)
https://deb.debian.org/debian/pool/main/h/hwdata/pnp.ids_0.394-1_all.deb
1743744651

https://snapshot.debian.org/archive/debian/20251231T202918Z/pool/main/h/hwdata/pnp.ids_0.394-1_all.deb
1743756392

I've found the code on Salsa [2], but don't know where to start looking to prepare a fix.

With kind regards,
Roland Clobus

[1] https://lists.reproducible-builds.org/pipermail/rb-general/2026-January/003991.html
[2] https://salsa.debian.org/snapshot-team/snapshot

#1126000#10
Date:
2026-01-21 10:30:23 UTC
From:
To:
That's probably very hard to fix. We don't keep the timestamps as far as
I know and the first seen timestamp is when we created the file in the
pool. The redirect you get directs the web server to fetch the file from
the filesystem and that is attaching the timestamp to the download. We
could in theory scrub the timestamp there but that would not be helpful
either.

I think the answer should be to compare under scrubbing of timestamps on
your side, unfortunately. I assume we already do that in other cases.

Kind regards
Philipp Kern

#1126000#15
Date:
2026-01-22 13:30:09 UTC
From:
To:
Hello Philipp,
I assume that at that moment the origin is still known, so the timestamp can be deducted from there.

I'll pursue that strategy as well.

With kind regards,
Roland Clobus

#1126000#20
Date:
2026-01-22 14:25:44 UTC
From:
To:
If it's created on security-master first, it will get a different
timestamp on ftp-master later on. I don't think that's a universally
winning strategy either.

Kind regards
Philipp Kern