Bug#1030855: ring_20230206.0~ds1-2_amd64-buildd.changes REJECTED

[Amin Bandali]

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/