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?
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…
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" afte
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 pa
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…)
--
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 an
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 t
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 ti
8 matches
Mail list logo
