There are several with FTBR. I found that the day of the *.poms s a date =
from
1970.
I=E2=80=99ve had a look at this. The files have various, *differing*,
timestamps within the month of January 1970, which in itself
is not proper.
It=E2=80=99s not a t64-related JDK bug: I tested=E2=80=A6
import java.io.*;
class T1 {
public static void main(String args[]) throws IOException {
File sf =3D new File("T1.java");
File df =3D new File("T1.out");
System.out.println(sf.lastModified());
InputStream is =3D new FileInputStream(sf);
OutputStream os =3D new FileOutputStream(df);
byte[] data =3D new byte[32768];
int nbytes =3D is.read(data);
os.write(data, 0, nbytes);
os.close();
is.close();
df.setLastModified(sf.lastModified());
}
}
=E2=80=A6 on armhf with OpenJDK 8, 17 and 21 (11 needs t64-transitioning).
Given the range of January 1970=E2=80=A6
$ TZ=3DUTC date -d '1970-01-31T23:59:59Z' +%s
2678399
$ TZ=3DUTC date -d @2678399000
Sun Nov 15 23:43:20 UTC 2054
=E2=80=A6 it is entirely possible that someone confused time_t and
Java millis, so the timestamps are off by a factor of 1000.
-rw-r--r--=C2=B7=C2=B7=C2=B70=C2=B7root=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=
=C2=B7=C2=B7=C2=B7(0)=C2=B7root=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=
=C2=B7=C2=B7(0)=C2=B7=C2=B7=C2=B7=C2=B7=C2=B71415=C2=B71970-01-06=C2=B708:0=
3:05.000000=C2=B7./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/v=
innie-2.0.2.pom
-rw-r--r--=C2=B7=C2=B7=C2=B70=C2=B7root=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=
=C2=B7=C2=B7=C2=B7(0)=C2=B7root=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=
=C2=B7=C2=B7(0)=C2=B7=C2=B7=C2=B7=C2=B7=C2=B71415=C2=B71970-01-03=C2=B713:2=
7:14.000000=C2=B7./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/v=
innie-2.0.2.pom
-rw-r--r--=C2=B7=C2=B7=C2=B70=C2=B7root=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=
=C2=B7=C2=B7=C2=B7(0)=C2=B7root=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=
=C2=B7=C2=B7(0)=C2=B7=C2=B7=C2=B7=C2=B7=C2=B71416=C2=B71970-01-09=C2=B701:3=
6:03.000000=C2=B7./usr/share/maven-repo/com/github/mangstadt/vinnie/debian/=
vinnie-debian.pom
-rw-r--r--=C2=B7=C2=B7=C2=B70=C2=B7root=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=
=C2=B7=C2=B7=C2=B7(0)=C2=B7root=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=
=C2=B7=C2=B7(0)=C2=B7=C2=B7=C2=B7=C2=B7=C2=B71416=C2=B71970-01-04=C2=B721:4=
0:23.000000=C2=B7./usr/share/maven-repo/com/github/mangstadt/vinnie/debian/=
vinnie-debian.pom
$ for t in 1970-01-06T08:03:05 1970-01-03T13:27:14 \
1970-01-09T01:36:03 1970-01-04T21:40:23; do \
=09TZ=3DUTC date -d @$(TZ=3DUTC date -d "${t}Z" +%s)000; \
done
Fri Aug 10 11:23:20 UTC 1984
Tue Jan 4 13:53:20 UTC 1977
Sat Feb 1 16:50:00 UTC 1992
Mon Sep 8 01:03:20 UTC 1980
Okaaay=E2=80=A6 So, maybe not so much. I *was* guessing something with
DEB_SOURCE_EPOCH vs. project.build.outputTimestamp, but that=E2=80=99s
apparently not it either.
So I fear someone=E2=80=99ll have to dig through all the various Maven-
related source packages=E2=80=A6
FWIW, the 517-day-old .deb currently in the repo has=E2=80=A6
-rw-r--r-- root/root 1415 2022-12-17 18:36 ./usr/share/maven-repo/com/=
github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom
=E2=80=A6 which matches Sat, 17 Dec 2022 18:36:19 +0100 from d/changelog,
so something something reproducible-builds is still suspect.
Good luck with that,
//mirabilos
--=20
Infrastrukturexperte =E2=80=A2 Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn =E2=80=A2 https://www.qvest-digital.com/
Telephon +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB AG Bonn 18196 =E2=80=A2 USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter N=C3=B6then