On Sun, 2017-07-09 at 15:41 +0100, James Clarke wrote: > Now, the issue here is not its presence, but its > name; however, I'd argue this is the correct name for it; it *is* a buildinfo > file for an amd64 build.
And that has little to do with what ends up in the archive, unlike other files dak processes: those usually are what ends up in the archive, but here it's just random data that might lie about what ends up in thhe archive. > Uploading a source-only changes file called > _amd64.changes has been done many times in the past (and used to be what you > would get with pbuilder pre-stretch) and never posed an issue, I guess because > the .changes files were thrown away(?), though I seem to recall in some cases > there were issues? There are issues with files named _amd64.changes in the same cases where there are issues with files named _amd64.buildinfo, just that is much worse with _amd64.buildinfo as one cannot rename them (see the .changes why that is so). (Uploads to unstable usually don't trigger that problem.) > Anyway, I don't especially care whether the _amd64.buildinfo > gets renamed (copied) by dpkg-genchanges -S, or whether dak is fixed to allow > multiple buildinfo files for the same arch (maybe renaming the file itself); Or fixed to just silently discard .buildinfo files that might not work. Or reject them always (though that also causes issues because arch:all uploads also seem to get a _amd64.buildinfo, except when they come from the buildds). Ansgar
