Re: Some Debian package upgrades are corrupting rsync "quick check" backups

2017-01-28 Thread Jonathan Hutchins
Does it occur to you that the reason for having a "testing" release is precisely so that problems like this can be found and fixed, and that this is why it's not smart to run testing on essential production machines?

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

2017-01-28 Thread Lupe Christoph
On Saturday, 2017-01-28 at 14:51:19 +, Holger Levsen wrote: > On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote: > > I highly suspect this stems from packages' rules files supporting > > reproducible builds. > I rather think this is due to binNMUs not modifying debian/changelog…

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

2017-01-28 Thread Bob Weber
As a user I have run into this with X11 files myself. I use rsnapshot to backup the root partition to a location on /home mounted on its own much larger partition before I do upgrades. A while back when xorg was crashing a lot I had to restore from this backup. I routinely use "debsums -ca"

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

2017-01-28 Thread Daniel Reichelt
On 01/28/2017 03:51 PM, Holger Levsen wrote: > On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote: >> I highly suspect this stems from packages' rules files supporting >> reproducible builds. > > I rather think this is due to binNMUs not modifying debian/changelog… > (in the source

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

2017-01-28 Thread Holger Levsen
On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote: > I highly suspect this stems from packages' rules files supporting > reproducible builds. I rather think this is due to binNMUs not modifying debian/changelog… (in the source package while it's modified in the binary packages…)

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

2017-01-28 Thread Daniel Reichelt
Hi, I highly suspect this stems from packages' rules files supporting reproducible builds. The only way I see to solve this would be for the "reproducible builds" infrastructure to hard-wire new timestamps at release-time of a new package version. Also: this is not limited to rsync. Basically

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

2017-01-28 Thread Christoph Biedl
Adam Warner wrote... > Why is a 27 January recompilation of the source package purporting to > have the same modification time as the original binary package > distributed 16 days earlier? Lemme guess: For the sake of reproducible builds, the timestamp of all created files is set to the time of

Some Debian package upgrades are corrupting rsync "quick check" backups

2017-01-28 Thread Adam Warner
Hi all, rsync typically detects file modifications by comparing exact modification time and size of each identically named file in the source and destination locations. An rsync backup can be surreptitiously corrupted by modifying a source file's content while keeping its size and modification