[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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-builds@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…

Yes.

> (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-devel@lists.alioth.debian.org

You forgot to CC that one (I understood that was your intention) but I'm also
still subscribed to reproducible-builds@l.a.d.o. :)

> > Not really, because that has been done in sbuild since long before the
> > reproducible builds project became active: 0.62.2-1, Tue, 05 Apr 2011:
> >     - Improve binNMU handling to permit binNMUs for multiarch packages
> >       (Closes: #620112).  Currently, binary NMUs use the current date
> >       in the new changelog entry, but co-installable packages require
> >       an identical changelog.  To avoid this, take the date from the
> >       previous changelog entry to ensure the same date for all binNMUs.
> >       Thanks to Anders Kaseorg for this patch.

The reason for this commit became void now that changelogs are stored in
architecture specific paths. Thus, as far as coinstallability of the changelog
is concerned, versions from different architectures having different timestamps
in their binNMU changelog entry is not a problem anymore. The remaining
coinstallability problem can come from packages that share files with content
that depends on the SOURCE_DATE_EPOCh timestamp which is calculated from the
generated binNMU changelog entry. But the following commit allows to tell
sbuild the exact timestamp for the new changelog entry and thus it is possible
to synchronize it across binNMUs on different architectures:

> > And, incidentally, this has been kind of reverted in 0.73.0-1 (Sat, 24
> > Dec 2016) after a fairly long and annoying discussion in debian-devel:
> >   * For binNMUs, instead of copying the timestamp of the last changelog entry,
> >     generate a new one (closes: #843773)

The discussion that prompted this change was this one:

https://lists.debian.org/22562.21637.415611.768269@chiark.greenend.org.uk

> so, two questions:
> 
> a.) has been fixed, so that no new occurrances of this problem will occur?

Hopefully. I welcome reports that show the contrary.

> 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 packages?
> 
> thinking about b.) debian-release@l.d.o might be the right list for
> this…

The version of sbuild used on the buildds probably doesn't bump the timestamp
yet. At least the binNMU-ed packages on my system share the binNMU changelog
timestamp with the timestamp of the last source upload. :)

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature


Reply to: