On Mon, 2017-08-28 at 12:58 +0200, Aurelien Jarno wrote:
[...]
> > > These files haven't been built on a build daemon, but instead have
> > > been uploaded by the maintainer [1]. This is therefore not a buildd
> > > issue, the issue has been fixed there already with the upgrade to
> > > stretch.
>
On 2017-08-28 12:42, Aurelien Jarno wrote:
> On 2017-08-28 12:33, Aurelien Jarno wrote:
> > On 2017-08-28 18:06, Adam Warner wrote:
> > > On Sat, 2017-05-13 at 22:48 +0200, Aurelien Jarno wrote:
> > > > On 2017-05-13 21:34, Aurelien Jarno wrote:
> > > > > On 2017-05-13 17:52, Mattia Rizzolo wrote:
On 2017-08-28 12:33, Aurelien Jarno wrote:
> On 2017-08-28 18:06, Adam Warner wrote:
> > On Sat, 2017-05-13 at 22:48 +0200, Aurelien Jarno wrote:
> > > On 2017-05-13 21:34, Aurelien Jarno wrote:
> > > > On 2017-05-13 17:52, Mattia Rizzolo wrote:
> > > > > On Sat, May 13, 2017 at 03:44:57PM +0100,
On 2017-08-28 18:06, Adam Warner wrote:
> On Sat, 2017-05-13 at 22:48 +0200, Aurelien Jarno wrote:
> > On 2017-05-13 21:34, Aurelien Jarno wrote:
> > > On 2017-05-13 17:52, Mattia Rizzolo wrote:
> > > > On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
> > > > > a) Has anything changed
On Sat, 2017-05-13 at 22:48 +0200, Aurelien Jarno wrote:
> On 2017-05-13 21:34, Aurelien Jarno wrote:
> > On 2017-05-13 17:52, Mattia Rizzolo wrote:
> > > On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
> > > > a) Has anything changed in the meantime?
> > >
> > > Yes: sbuild stopped
On Sat, May 13, 2017 at 10:48:18PM +0200, Aurelien Jarno wrote:
> The above change should now be deployed on most jessie based buildds,
> it's only missing on the buildds that are currently down.
cool, thank you!
--
cheers,
Holger
signature.asc
Description: Digital signature
On 2017-05-13 21:34, Aurelien Jarno wrote:
> On 2017-05-13 17:52, Mattia Rizzolo wrote:
> > On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
> > > a) Has anything changed in the meantime?
> >
> > Yes: sbuild stopped repeating the changelog time taking it from the last
> > entry, and
On 2017-05-13 17:52, Mattia Rizzolo wrote:
> On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
> > a) Has anything changed in the meantime?
>
> Yes: sbuild stopped repeating the changelog time taking it from the last
> entry, and will instead generate a new timestamp based on the
On Sat, May 13, 2017 at 05:52:04PM +0200, Mattia Rizzolo wrote:
> On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
> > a) Has anything changed in the meantime?
>
> Yes: sbuild stopped repeating the changelog time taking it from the last
> entry, and will instead generate a new
On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
> a) Has anything changed in the meantime?
Yes: sbuild stopped repeating the changelog time taking it from the last
entry, and will instead generate a new timestamp based on the current
time:
* For binNMUs, instead of copying the
Hi all,
Just following up on this thread. As it's been a while, here's the
thread index:
https://lists.debian.org/debian-security/2017/01/threads.html#00014
... but AIUI, the issue is as follows. Naturally, let me know if this
a poor or inaccurate summary:
* binNMUs do not bump
Hi,
Quoting Holger Levsen (2017-01-30 14:58:33)
> On Mon, Jan 30, 2017 at 02:47:45PM +0100, Johannes Schauer wrote:
> > > b.) if thats the case, shall we scan all packages in sid for files which
> > > have the same timestamp+filename but different checksums and ask for
> > > binNMUs of those
On Mon, Jan 30, 2017 at 02:47:45PM +0100, Johannes Schauer wrote:
> > (the sbuild maintainer reads the above list which has been cc:ed so he
> > should be able to comment…)
>
> You were talking about buildd-tools-de...@lists.alioth.debian.org
yes
> You forgot to CC that one (I understood that
Hi Henrik & Holger,
sbuild maintainer here.
Quoting Holger Levsen (2017-01-30 14:25:51)
> On Mon, Jan 30, 2017 at 01:10:12PM +0100, Mattia Rizzolo wrote:
> > > Would reproducible-bui...@lists.alioth.debian.org be the correct mailing
> > > list to discuss this?
>
> the debian-buildd list or a
On Mon, Jan 30, 2017 at 01:10:12PM +0100, Mattia Rizzolo wrote:
> > Would reproducible-bui...@lists.alioth.debian.org be the correct mailing
> > list to discuss this?
the debian-buildd list or a bug against sbuild might be more
appropriate…
(the sbuild maintainer reads the above list which has
On Mon, Jan 30, 2017 at 02:01:10PM +0200, Henrik Ahlgren wrote:
> On Sat, 2017-01-28 at 23:00 +0100, Lupe Christoph wrote:
> > 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
On Sat, 2017-01-28 at 23:00 +0100, Lupe Christoph wrote:
> 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.
>
> >
On Sunday, 29 January 2017 8:07:09 PM AEDT Santiago Vila wrote:
> IMO, if we want reproducible builds and we don't want this to happen,
> we should probably change the way we do binNMUs (where "change" could
> well be not doing binNMUs at all and always include full and exact
> source with every
Hi,
On 2017-01-28 22:00, Lupe Christoph wrote:
This problem may affect many other backups too. Did anybody research
backup programs before this was introduced to Debian?
I do not consider this an acceptable attitude on Debian lists.
Thanks,
--
Jonathan Wiltshire
On Sat, Jan 28, 2017 at 11:00:32PM +0100, Lupe Christoph wrote:
> This problem may affect many other backups too. Did anybody research
> backup programs before this was introduced to Debian?
This is really the combination of two different things:
* The way we currently do binNMUs.
*
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"
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
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
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
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
28 matches
Mail list logo
