Hi Peter, On Sat, Jan 28, 2017 at 05:45:30PM +0100, Peter Lebbing wrote: > Hello Carsten, > > On 28/01/17 17:15, Carsten Schoenert wrote: > > we didn't ever have done some patching here. I did a quick search on the > > upstream sources and found mozilla bug 1277976 which introduces this > > change. > > While this sure is the change that made the mtime problem manifest with > user-visible changes, this change is not the problem. > > > I suggest to get in contact with upstream by simply answering in the bug > > report with your analyze. We can patch the source once the position of > > usptream is clear. > > I wonder if this is appropriate. IMO, the bug is about something else > entirely. It's just that the fix effected a different problem. > > Mozilla bug #1277976 is about what users expect a certain keyboard > shortcut does, in a nutshell. > > This Debian bug report I opened is about (many) files having fake > metadata, confusing backup tools. > > While the one led to the other in this specific instance, they are in > essence unrelated.
then I don't understand your first email. The only thing related to set up some "faketime" is while creating the package. We take the timestamp from the changelog entry and this only for reproducibility. The timestamps are partially valid for 1:45.6.0-3 ---%<--- icedove (1:45.6.0-3) experimental; urgency=medium ... -- Christoph Goehre <ch...@sigxcpu.org> Tue, 17 Jan 2017 18:26:06 -0500 --->%--- So I have currently no clue where the timestamps with *.000000000 are coming from. But this looks like something that could be come from the tools the reproducibly team is using and creating. Then we need to bring this to the people there to getting deeper in the reasons why the timestamps are modified in this way. But ... the next upload would have a new time from the changelog. I'm confused. > If you really suggest I bring it up in that bug > report, I'll do so. But it feels like conflating issues in a single bug > report. > > I could also open a new upstream bug report. I'm always a bit uncertain > whether to report upstream or to Debian. I'm using Debian, it feels like > I should report it there. But I'm also using upstream, right... > > I think in any case Debian should be aware of this specific issue, and > decide whether to fix this in stable as well. For users of a whole class > of backup solutions, it's a potential, but relatively benign data-loss > issue. Only filesystem-specific tools and backup tools that always > compare or checksum every byte of every file in the filesystem will not > be fooled by the fake metadata. If the issue is completely unrelated to that change then of course there is no need to bring this up to the Bugzilla of Mozilla. We need to dig deeper into the real issue. Next we need to clarify with which package version such timestamps are shipped for the first time. Regards Carsten
