On Mon, Sep 12, 2011 at 03:20:50PM +0300, Peter Pentchev wrote: > The direct reason for this failure is that, for some reason, dpkg > decided to do more extensive signature checking than usual - namely, to > invoke debsig-verify(1) on the binary package file. Since debsigs is > the only package in the archive that may pull in debsig-verify, this is > the only time this error would have come up :) And since, well, yes, I > failed to sign the debsigs package using itself before uploading it, > debsig-verify would indeed claim an error. So, yes, partly my fault, > I'll take care to sign at least the debsigs packages in my next uploads > :) Thanks for alerting me to this! > > However... The real question is why dpkg even tried to invoke > debsig-verify - isn't the "no-debsig" option present in > /etc/dpkg/dpkg.cfg (again) ever since #311843 and dpkg-1.14.17? Or are > you running this build with a completely cleaned-up /etc/dpkg/dpkg.cfg, > too? In this particular case, this might be a bad idea - if any > packages should pull in debsig-verify, this would indeed prevent the > further installation of, well, pretty much *all* the packages in the > Debian archive, since debsigs does not yet have widespread adoption, to > say the least :P (and no, this is NOT a complaint or anything, I know > that pushing for debsigs adoption for all packages would be kind of, > well, counter-productive and doomed :) > > Of course, as noted above, the only package likely to pull in > debsig-verify is currently debsigs itself, but I still think that doing > mass automated builds withOUT no-debsig is not a very good idea. > > Sure, I'll sign the next debsigs upload, no problem, and thanks for the > bug report and for all of your (and the rest of the QA team's) awesome > work!
I don't think that dak allows you to introduce new ar members it doesn't know about. If it does, that's certainly a bug. Kind regards Philipp Kern
signature.asc
Description: Digital signature