Hi Mark,
On Sat, 2020-08-08 at 10:50 +0100, Mark Hindley wrote:
> On Fri, Aug 07, 2020 at 11:57:57PM +0300, Boian Bonev wrote:
> > > I assume you have checked functionality.
> >
> > Not all of it, because I do the development on an amd64 vm and
> > there I
> > can only test install and to see that the daemon starts, but not
> > that
> > it actually works. I have an aarch64 RPI GPS NTP server and will
> > test
> > it there (it is a production one, but I have means to bypass in
> > case it
> > breaks).
>
> OK.
Test in a real gpsd usage went fine. I just upgraded the package,
restarted gpsd and all is fine:
~# dpkg -l|grep gps
ii gpsd 3.20-
12+devuan1 arm64 Global Positioning System -
daemon
ii gpsd-clients 3.20-
12+devuan1 arm64 Global Positioning System -
clients
ii gpsd-debugtools 3.20-
12+devuan1 arm64 Global Positioning System -
debugging tools
ii gpsd-tools 3.20-
12+devuan1 arm64 Global Positioning System -
tools
ii libgps26:arm64 3.20-
12+devuan1 arm64 Global Positioning System -
library
ii libqgpsmm26:arm64 3.20-
12+devuan1 arm64 Global Positioning System -
Qt wrapper for libgps
ii python3-gps 3.20-
12+devuan1 arm64 Global Positioning System -
Python 3 libraries
>
> > > Are you able to fix #314?
....
>
> > I am wondering how bugs are distinguished, is there a tag like LP:
> > that
> > closes Devuan bugs? I did a test build of iwd and lintian was
> > complaining about improbable-bug-number-in-closes.
>
> They aren't. It is just that building on Devuan buildhosts will close
> Devuan BTS
> bugs.
OK. Some day these will clash, anyways I believe there is enough time
to find a solution until then. It would be a good idea to have a tag
for Devuan specific tag - this will allow Debian package to close
Devuan bugs (like LP:).
> If you install devuan-lintian-profile you should get more sane
> lintian warnings.
I did, but most probably not using it.
> > > - d/control: as you have renamed gpsd-dbg to gpds-dbg-tools
> > > (which
> > > seems
> > > sensible) you will need conflicts, provides and replaces for
> > > gpsd-
> > > dbg
> > > otherwise upgrades will fail due to a file conflict.
> >
> > I have planned one more change for this part - to install the
> > executables under /usr/libexec/gpsd/debug; then there will be no
> > conflict.
> >
> > But on second thought, to avoid possible confusion, it is a
> > good idea to set them - when main package is upgraded it will be a
> > good
> > idea to also upgrade this part and not leave the old gpsd-dbg
> > installed
> > with new gpsd-dbg-tools.
>
> Yes, exactly.
I have abandoned the idea to rename a package - that will be too big
hassle to support in future and there is no other benefit. Fixing the
other things is enough, IMHO.
> > Also I see that there is a transition for
> > gpsd-dbg to gpsd-dbgsym which I believe is long ago finished.
> >
> > > Once those are fixed I can copy the repo to
> > > https://git.devuan.org/devuan/gpsd
> > > and make you maintainer. Then you will be able to trigger the
> > > production build.
> >
> > I have no idea how that part works. Is there a way to test it
> > first?
>
> Not really. If a local build with gbp works it should be OK. The
> documentation
> for how to trigger the production build is
OK, lets go for it. Current repo should be fine to go, also if there is
something to fix, I will do it fast.
https://git.devuan.org/devuan/documentation/src/branch/master/maintainers/JenkinsAutobuild.md
With best regards,
b.
::
[devuan-dev] bug#490: bug#490: gpsd…
