Control: clone -1 -2 Control: retitle -2 dak: Please ignore build-profile packages from Package-List Control: reassign -2 ftp.debian.org
Even though you might want to check the bug history for more context, AFAIR the summary of the report I think is this: ,--- It might make sense to introduce packages f.ex. for bootstrapping purposes, which only get built under certain build-profiles, but not ever by a default build. But as dak uses the entire Package-List from the .dsc for its "seen" tracking this is problematic, because these require NEW processing, or these uploads are not accepted as part of a source-only upload, and even if they get processed once (AFAIR) these get garbage collected as they are never seen in practice, which means they will trigger NEW processing or REJECTs again. This cannot be fixed in dpkg-source, because that field is intended to contain all possbly generated artifacts, and dak does not use the packages from the .changes which should be (but are not currently) restricted to those included in the current upload. `--- If my recollection of some of the details is wrong, Samuel should be able to correct me. On Fri, 2018-11-16 at 17:55:03 +0100, Samuel Thibault wrote: > Guillem Jover, le ven. 16 nov. 2018 17:19:20 +0100, a ecrit: > > On Sat, 2018-11-10 at 22:23:44 +0100, Samuel Thibault wrote: > > > Guillem Jover, le sam. 10 nov. 2018 02:46:27 +0100, a ecrit: > > > > You might want to try the problematic upload but removing the entry > > > > only from the Package-List field, keeping the entries in the .changes > > > > Binary field, and see what happens. > > > > > > I got a reject: > > > > > > Invalid dsc file: Package-List and Binaries fields have a different > > > number of entries. > > > > Ah right, sorry. I guess you could you try instead either of these > > scenarios: > > > > * Remove the problematic entries only from .dsc Package-List and > > Binary fields, keep them in the .changes file, and upload. > > > > * Remove the problematic entries only from .changes Binary and > > Description, keep them in the .dsc, and upload. > > > > My assumption is that the first will let it through, while the second > > will not, > > Indeed, the first upload got accepted without passing through NEW. > > > which would indicate that dak needs to be adapted and not > > dpkg > > Ok, so we need to reassign to ftpmaster? Cloned, as the original should be fixed too in dpkg-source. > > (although the next upload might just trim any non-generated artifact > > from the .changes file anyway). > > Not sure to understand this :) Which "next upload" do you refer to? Sorry, I meant a dpkg upload here. Thanks, Guillem
