Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote: > > Also here, it feels to me that once something is accepted into a policy > > queue, dak should already consider it something controlled by itself, > > store checksums in the database and be done, not keep the .changes > > around as a "source of truth" for additional processing, imho. > > Throwing away .changes doesn't help with .buildinfo name conflicts. It helps in the sense that once the .changes is thrown away, dak would be free to rename the .buildinfo however it likes. > We could also just not accept .buildinfo uploads when they don't contain > useful information about published binaries, that is for source-only > uploads. > > Maybe I should reenable the check for this at least on security-master? > It was rejecting uploads that are okay for unstable/experimental so I > disabled it again the last time. That would indeed be a fine workaround for me, and reduce the load the security team is experience, since it's the team which is the most affect by this. (Incidentally, it also is the same way launchpad works, there you can't upload a .buildinfo for an arch that you aren't uploading, and humans can't upload binaries, so you can't upload .buildinfo for binaries at all). -- 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 ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote: > The .buildinfo files are referred to in the .changes files; renaming > them would require updating the .changes file. The .changes files are > used to upload the security updates to ftp-master. With .changes being ephemeral, it feels to me that using them to cross the archive is not really a good solution, and whatever is used to copy packages from one archive to another (is it dak itself?) should instead re-create the upload and re-sign it. Also because that way it would be perfectly able to "upload" all of the sources+binaries from sec-master to ftp-master in a single go, which can't be bad. > ftp-master also has the same problem when uploads end up in policy > queues (the renaming to .buildinfo.N is only done when dak is "done" > with the file and will never touch it again). Also here, it feels to me that once something is accepted into a policy queue, dak should already consider it something controlled by itself, store checksums in the database and be done, not keep the .changes around as a "source of truth" for additional processing, imho. Sure, I understand that things works like that, I'm just showing a few design points that could potentially be done differently. -- 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 ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote: > > This behaviour is really causing issues for the security-archive so in > > one way or the other there needs to be a solution. Regularly we need > > to fetch the buildd changes and build binary packages, resign them and > > reupload them due to this bug. > > What's unclear to me is why the workaround in DAK for the main archive, > which adds .buildinfo.N for duplicate .buildinfo filenames, can't be or > hasn't been applied for the security archive. Is there something > fundamentally different with the security archive? The .buildinfo files are referred to in the .changes files; renaming them would require updating the .changes file. The .changes files are used to upload the security updates to ftp-master. ftp-master also has the same problem when uploads end up in policy queues (the renaming to .buildinfo.N is only done when dak is "done" with the file and will never touch it again). As most uploads go to unstable and experimental, one mostly doesn't notice the issue. Ansgar ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
