Hello, Aurelien Jarno writes:
> Source: ring > Version: 20230206.0~ds1-2 > Severity: serious > > On 2023-02-08 08:40, Debian FTP Masters wrote: >> jami_20230206.0~ds1-2_amd64.deb: has 5 file(s) with a timestamp too far in >> th= >> e past: >> usr/share/applications/jami.desktop (Thu Jan 1 00:00:01 1970) >> usr/share/i= >> cons/hicolor/scalable/apps/jami.svg (Thu Jan 1 00:00:01 1970) >> usr/share/jam= >> i/jami.desktop (Thu Jan 1 00:00:01 1970) >> usr/share/metainfo/jami.appdata.xm= >> l (Thu Jan 1 00:00:01 1970) usr/share/pixmaps/jami.xpm (Thu Jan 1 >> 00:00:01= >> 1970) >> >> >> >> =3D=3D=3D >> >> Please feel free to respond to this email if you don't understand why >> your files were rejected, or if you upload new files which address our >> concerns. Yes please, I'd like to understand why timestamps in the far past are a 'serious' bug and warrant a rejection. Upstream Jami project has worked on making various aspects of the release and build processes of Jami reproducible over the years, including Jami's release tarballs. The release tarballs are generated with a few additional options[1] to aide reproducibility, including setting '--mtime=@1' to use the epoch as the timestamp for all the files included in the release tarballs. This is quite close to the archive recommendations[2] by the reproducible builds project. So, why would this be considered an issue? [1] https://git.jami.net/savoirfairelinux/jami-client-qt/-/blob/010930febe2c28374c65e25c3147f08bdc2efecc/extras/packaging/gnu-linux/Makefile#L67 [2] https://reproducible-builds.org/docs/archives/
