Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Thu, Sep 10, 2020 at 12:12:29PM +0200, Alec Leamas wrote:
> On Thu, 10 Sep 2020 05:12:34 -0400 The Wanderer <wanderer@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
>
Reply to: