Web lists-archives.com

Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master




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…