On Thu, Sep 10, 2020 at 12:12:29PM +0200, Alec Leamas wrote: > On Thu, 10 Sep 2020 05:12:34 -0400 The Wanderer <wande...@fastmail.fm> > wrote: > > On 2020-09-10 at 01:45, Tobias Frost wrote: > > > > > On Wed, Sep 09, 2020 at 10:53:37PM +0200, Alec Leamas wrote: > > > > > > > Well, actually, all those lines probably should be removed: > > > debian/changelog is intended to record changes to the packaging part > > > only, it is not to record changes made upstream; more generally: Only > > > stuff that changes files in the debian directory should be mentioned > > > in d/changelog. (See > > > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog > > > for some better/more accurate wording in the Policy) > > > > I'm not sure I read that section as meaning that. Could you point more > > specifically to the exact wording there which you understand as > > reflecting this rule? > > > > Regardless, I'm fairly sure there are exceptions to this in practice. > > For example, if a new upstream release includes a change which closes an > > open Debian bug report or fixes a particular CVE, a notation in the > > changelog recording that fact seems to be de rigueur, and in fact as I > > understand matters the tooling recognizes and parses notes such as > > "Closes: #123456" or "CVE-1000-123-1234" to auto-close the given bug > > report or to mark a newly-packaged version as unaffected by the given > > CVE. > > > > For that matter, look at the Linux kernel packages > > (linux-image-VERSION-ARCH, among others). They don't seem to ship a > > changelog.Debian.gz, but the changelog.gz which they do ship seems to be > > > > This seems to be a Deep Philosophical Discussion between Debian > Developers. I should thus basically stay quiet, but I feel the > discussion is a little bit off in this case.
(Sorry that this RFS has been hijacked. I try keep on topic now; I'm not sure whether The Wanderer is DD or package maintainer, but its not relevant anyway) > I'm working tight with upstream, so the upstream/downstream boundaries > are a little obscured. >The references was a result (all cases) of a > workflow like > > - Packaging, I find a bug and make a patch in d/patches > - The bug is filed upstream. > - The patch is converted to an upstream PR. > - The PR is merged on upstream master branch, to be included in next > release. > - The patch in d/patches is updated with DEP-5 info (yes, did that). > - The line in the changelog is (was) updated with the upstream bug #. > > So, these references stem from my downstream work. They do (did) *not* > reference anything in the release tag, only changes after that. Srry, EPARSE, can you expand? Oh wait, I guess I see the misunderstanding now… Oops, totally sorry, I misread the changelog entries all the time and missing the word "patch"… Actually those changes _are_ changes to the debian package, so of course they need to be in d/changelog. However, May I propose a better structuring like: * New patches: - udev rule installation patch. - metadata installation patch. - Remove bogus svg file patch. (**) - Patch to fix cmake parallel execution. - Add two plugin compatiblity patches (#1997). (in my packages I usually write "New patch $patch-filename.", because details would be the dep3 headers of the patch. This allow sometime better to understand which patch is what change. But thats personal taste) While having the changelog open: * Handle some lintian informational warnings. is not a good changelog entry, because it does have enough information what has been changed (and why)) * Remove bogus svg file patch. Its unclear to me why are you removing it? (If it doesn't cause problems I would leave it…) I will continue later, I need some food first ;-) But I'm glad this knot in my brain has been sliced ;-) > Having these lines, with or without upstream references is no big thing, > at least not for me. Just trying to clarify > Cheers! > --alec >