DSA candidates
ansible/stable -- bitlbee/stable -- calibre/stable -- dhcpcd5/stable -- glassfish/stable -- gnutls28/stable -- imagemagick/stable -- jbig2dec/stable -- kgb-bot/stable -- libarchive/stable -- libav/stable -- libgit2/stable -- libphp-phpmailer/stable -- libtorrent-rasterbar/stable -- libvpx/stable -- libwebp/stable -- lshell/stable -- mcollective/stable -- mysql-5.5/stable -- mysql-connector-python/stable -- ntopng/stable -- openjpeg2/stable -- owncloud/stable -- percona-xtrabackup/stable -- potrace/stable -- python-pysaml2/stable -- shadow/stable -- slurm-llnl/stable -- svgsalamander/stable -- tcpdf/stable -- tiff/stable -- wavpack/stable -- zendframework/stable -- -- The above is a list of DSA candidates based on the tracker's information. One should evaluate the candidates and either add them to dsa-needed.txt or consider tagging them no-dsa.
Unidentified subject!
Bcc: Subject: Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups Reply-To: In-Reply-To: <148578965254.16460.821466934538220169@localhost> On 2017-01-30 16:20, Johannes Schauer wrote: > 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 packages? > > > 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. :) > > > > so it seems we should > > > > a.) get this fix deployed on all the buildds. (how?) > > b.) do the b.) above… (because AIUI this issue atm is only be noticed > > by those running unstable or stretch, while once stretch is released > > many > > more people will notice it…) > > I'm not involved in buildd development. I think Aurélien Jarno (CC) is > involved > as there are many commits from him in the respective sbuild git branch. > Possibly the right mailing is debian-dak@l.d.o but I'm not active there. The right contact point is wb-t...@buildd.debian.org or alternatively the mailing list wb-t...@lists.debian.org. > The buildds are running a custom version of sbuild with their own patches on > top. So I'd expect that once Stretch is released, they will rebase their > patches on top of sbuild from Stretch. We have merged all of our patches except one that disable the init script at the time of the Jessie release. The patches that have been added later in this branch are just cherry-picks from the master branch. Once Stretch is released, we'll indeed do the same process. > So as far as I understand Henrik's original message, their problem should be > fixed once packages start being built with sbuild from Stretch which happens > after the Stretch release. I don't know what is the issue you are talking about. If there is a patch available (preferably committed first to the master branch), we might be able to cherry-pick it. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups
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 packages? > > 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. :) > > so it seems we should > > a.) get this fix deployed on all the buildds. (how?) > b.) do the b.) above… (because AIUI this issue atm is only be noticed > by those running unstable or stretch, while once stretch is released many > more people will notice it…) I'm not involved in buildd development. I think Aurélien Jarno (CC) is involved as there are many commits from him in the respective sbuild git branch. Possibly the right mailing is debian-dak@l.d.o but I'm not active there. The buildds are running a custom version of sbuild with their own patches on top. So I'd expect that once Stretch is released, they will rebase their patches on top of sbuild from Stretch. So as far as I understand Henrik's original message, their problem should be fixed once packages start being built with sbuild from Stretch which happens after the Stretch release. Thanks! cheers, josch signature.asc Description: signature
Re: Some Debian package upgrades are corrupting rsync "quick check" backups
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 was your intention) but I'm also > still subscribed to reproducible-builds@l.a.d.o. :) no, I didnt forget to cc: the list as I didnt know it's exact name and I was too lazy to look for it as I knew you read the reproduible list ;) [nice explaination deleted, nothing to add here, except thanks for explaining.] > > 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. you are refering to "fixed in sbuild" here, while I ment (but didnt excplitly say…) "fixed in the buildd network"… > > 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? > 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. :) so it seems we should a.) get this fix deployed on all the buildds. (how?) b.) do the b.) above… (because AIUI this issue atm is only be noticed by those running unstable or stretch, while once stretch is released many more people will notice it…) -- cheers, Holger signature.asc Description: Digital signature
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-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… 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-de...@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.768...@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 signature.asc Description: signature
Re: Some Debian package upgrades are corrupting rsync "quick check" backups
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 been cc:ed so he should be able to comment…) > 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. > > 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) so, two questions: a.) has been fixed, so that no new occurrances of this problem will occur? 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… -- cheers, Holger signature.asc Description: Digital signature
Re: Some Debian package upgrades are corrupting rsync "quick check" backups
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 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…) > > > > This is completely counter intuitive. I'm using rsnapshot to backup a > > few private machines. I will have to set up separate rsnapshots for > > those parts of the backup that suffer from this , to avoid > > bogging down the data parts by unnecessary checksum calculations. > > > > This problem may affect many other backups too. Did anybody research > > backup programs before this was introduced to Debian? > > Would reproducible-bui...@lists.alioth.debian.org be the correct mailing > list to discuss this? 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. 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) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Some Debian package upgrades are corrupting rsync "quick check" backups
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. > > > I rather think this is due to binNMUs not modifying debian/changelog… > > (in the source package while it's modified in the binary packages…) > > This is completely counter intuitive. I'm using rsnapshot to backup a > few private machines. I will have to set up separate rsnapshots for > those parts of the backup that suffer from this , to avoid > bogging down the data parts by unnecessary checksum calculations. > > This problem may affect many other backups too. Did anybody research > backup programs before this was introduced to Debian? Would reproducible-bui...@lists.alioth.debian.org be the correct mailing list to discuss this?
Re: Some Debian package upgrades are corrupting rsync "quick check" backups
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 upload). Why is it desirable to have bunNMUs anyway? For small packages there's little overhead in just rebuilding it on all architectures. For complex packages I think that it's best to avoid the potential problems of binNMUs in terms of tracking changes etc. Things like LibreOffice and the kernel are complex enough without having binary changes that lack a changelog entry. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
