Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Sun, Sep 13, 2020 at 11:00:17AM +0200, Alec Leamas wrote:
>
> Hi Tobias,
>
> Here we go:
>
> On 12/09/2020 16:28, Tobias Frost wrote:
> > Control: owner -1 !
> >
>
> > Two remarks:
> > - d/changelog You could bumpt the timestamp on the changelog from time to time, though
> > ;-): dch -r "" is a nice trick ;-)
>
> Indeed, thanks! Tried now, will need to to it again.
>
> > - (nitpick) d/changelog Please be consitent on the Closes: Stancas
> > - Line 2 says Closes: 948702, line 3 says Closes #962213. Please use
> > either with '#' or without '#' … just for my eyes to relief…
>
> Fixed
>
> > d/control:
> > - you can drop opencpn-plugins; I guess this is for people who
> > installed before Debian had the package.
>
> Not really. It's about an old version which seemingly has existed in
> Debian about 2015 (I find the traces in the salsa git log for opencpn.
> Still drop? (leaving for now)
Checking…
Reading
https://salsa.debian.org/debian-gis-team/opencpn/-/blob/0b2edd7339f86a5348de47481a549600766406c4/debian/changelog (this is the last commit before you took over;)
there was a release in 2011, but nothing after that. (Note the unreleased)
This is confirmed by http://snapshot.debian.org/package/opencpn/ and tracker.d.o also tells me
that there was nothing in debian since at least oldstable.
The fact that snapshot.d.o does not know anything older than 4.8.8 makes me wonder whether the
package has ever been in Debian or just prepared but never uploaded.
I think the transitional package is no longer required.
> > OK to keep the
> > Break/Replace until opencpn has been released with a Debian stable
> > release. (I cant check if the version constraint is right, because "<<"
> > is strictly earlier, that means 4.8.6~20180801.8d20a06+dfsg.1 was the
> > first version with an empty plugins package?; It would be safe to us <<
> > 4.8.8~, though. Update: #917561 seems to indicate that this change was
> > actually introduced in 4.8.8+dsfg.1-1 -- so the above restriction would
> > be too old…)
>
> Again, this is (was?) about the traces I found in the salsa log. Shall
> we drop the Breaks/Replaces? Or update to the correct value << 5.0.0+dfsg?
>
> Certainly happy to drop, these things are messy and nice to get
> rid of. Your thoughts? (leaving for now)
>
I'd keep them with "(<< 4.8.8~)" and drop it once the next Debian release is out.
This add a saftey net when someone happens to have it still installed for whatever
reason.
> > - is wx3.0-i18n really required to run opencpn? Maybe Recommends is
> > enough?
>
>
> Recommends: is indeed enough. Fixed (*how* did you catch that one?
> Tooling? Experience?)
I just found it strange to have an i18n package as Depend…
>
> > - opencpn recommends binutils. Can you say why, its a bit unusual for
> > non-development applications.
>
> It's about some built-in crash-reporting stuff which uses addr2line.
ok. (it is not phoning home, right?)
> > d/opencpn.install and d/rules…
> > There are some issues, I'll follow up later on those,
> > probably with a patch/MR (hint to update salsa, see below).
>
>
> OK.
>
> > d/clean
> > - NSIS.template.in is appearantly recreated during build, it should be
> > deleted via d/clean. (Then debuild twice will work, too)
>
>
> Indeed, thanks! Fixed.
>
>
> > d/rules:
> > In the override
> > - instead of making the links to the licenses, you could use
> > dh_links(1)
>
>
> Problems:
>
> $ man dh_links
> No manual entry for dh_links
> $ apt-cache search dh_links
> $
>
>
> Google doesn't give anything meaningful either.
I will follow up on that later; this is in combination with the d/rules and d/*install…
(Combined with a typo, I meant dh_link)
Stay tuned and watch for MR against your tmp branch (I hope this is the one…)
>
> > multiarch:
> > - the plugin *.so are not installed in an multiarch aware path.
>
>
> This is actually on purpose. I read the multiarch docs like multiarch
> paths are only applicable to libraries i. e., there are no multiarch
> applications. opencpn is an application, we cannot have multiple
> architectures in $PATH, and hence the plugins which are an integrated
> part of the application lives in /usr/lib/opencpn rather than the
> multiarch path.
>
> Or?
Yeah, you are likely right: The plugins comes indeed with the main package and
so you can only have them on the same arch.
>
> > nitpicks:
> > - theres a trailing space in README.source (use wrap-and-sort(1) ;-))
>
>
> Fixed (using vim...)
>
> > Wishlist:
>
> > (wishlist items related to README.Debian)
> > - I see docs are not packaged for privacy reasons. Could they be when
> > the docs being patches (not an unseen in Debian)?
> > (e.g I hate it if the docs are not matching the version I have
> > installed, as often the docs for the newer version won't apply well
> > enough)
>
>
> I don't follow you here... This should really be fixed upstream, by an
> easy-to-use option for users to download the docs (the download is
> available upstream). However, I don't think it's reasonable to fix it
> downstream.
> Basic problem is that the docs are generated using a wiki system which
> just havn't (and cannot have) sources which are public. Please don't ask
> me why this system is used...
Ok, makes sense; I thought the docs are buildable "in source".
>
> > - (as you are upstream-involved, this is probably easy to fix on your
> > side:) The plugin code could also look into alternative directories…
>
>
> It actually already does. It's perfectly possible to create
> .deb-packaged plugins, and there are plenty around -- this is the way
> plugins have been packaged for Debian/ubuntu since long. In the upstream
> bugs (which you seem to have skimmed to in some cases?), these are
> referred to as legacy plugins.
>
>
> > - The /usr/share/ hierachicy is reserved for packaged stuff, so
> > encouraging users to copy stuff there is a bit meeeh; it can
> > create problems when e.g a new package provides this file.
> > - So probably /usr/local/… or /opt/… would be a better
> > recommendation.
> > - Additionally, when users should be able to install plugins without
> > being root, something like $HOME/.local/… (not sure if this is
> > consenus in Debian, though)
>
>
> There are just so many problem here. In Fedora, packages are explicitly
> forbidden to write anything under /home for good reasons. I don't think
> Debian is or should be different. But, see above, .deb packages work
> out of the box.
In Debian packages must not write to /home as well.
What I meant is that a user (maybe using the pluigin manager) downloads a
plugin and places it into the home directory. (They might have no root privs…)
(But as marked as wishlist, so don't mind)
>
> I have pushed a new version to mentors, with fixes above. The patches
> and d/copyright are fixed to the point that I don't know what more to
> do. I understand that it is possible to simplify d/copyright in some
> cases, but trusting you to judge which.
Ok, downloaded.
>
> Cheers!
> --alec
>
>
Reply to: