James Clarke dixit: >file for an amd64 build. 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
Both wrong, the buildd uploads were REJECTed as the _arch.changes already existed in the archive. >>> I fine with that answer. My point was just that, should ftpmasters say that >>> it >>> was unsupported to have an _<arch>.buildinfo file inside a _source.changes, >>> then something was wrong in the build toolchain. >> [08:06:05] (ansgar): Corsac: I fixed it by changing the filename and >> resigning >> the buildd's changes. But please don't upload _amd64.buildinfo unless you >> include amd64 binaries. >> it's pbuilder, debhelper or dpkg-dev or a combination thereof. I just drop the buildinfo file from the _source.changes manually. I believe there’s an unclearness about what exactly a buildinfo file is and what exactly the arch qualifier in its name stands for, while there *is* a clear definition that each filename may occur in the archive at most once. I think it’s best that the persons responsible for creating those buildinfo files comment on the scope of then, after which it should be decided whether 1) *_source.changes should never list a buildinfo file, or 2) *_source.changes may list a *_source.buildinfo file, or 3) something else that does not work with the way the archive works. bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles kaputt? :) 15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…