Subject: gpsd: Current version of gpsd does not install /etc/init.d/gpsd and fails to start

From: Boian Bonev <[email-masked]>
Date: Sun, 12 Jul 2020 02:48:03 +0300

Package: gpsd
Version: 3.20-12
Severity: grave
Justification: renders package unusable

I suppose that the soltion is to fork the package. In case that is agreed upon, I can prepare the modified package and upload it somewhere...

-- System Information:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 4 (chimaera/ceres)
Release:	testing/unstable
Codename:	n/a
Architecture: aarch64

Kernel: Linux 4.16.14-v8+ (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gpsd depends on:
ii  adduser        3.118
ii  libbluetooth3  5.50-1.2
ii  libc6          2.30-8
ii  libdbus-1-3    1.12.20-1+devuan1
ii  libgps26       3.20-12
ii  libusb-1.0-0   2:1.0.23-2
ii  lsb-base       11.1.0
ii  netbase        6.1
ii  python3        3.8.2-3

Versions of packages gpsd recommends:
ii  eudev [udev]  3.2.9-7
ii  gpsd-tools    3.20-12

Versions of packages gpsd suggests:
pn  apparmor      <none>
ii  dbus          1.12.20-1+devuan1
ii  gpsd-clients  3.20-12

-- Configuration Files:
/etc/default/gpsd changed [not included]

-- no debconf information

---

From: Mark Hindley <[email-masked]>
Date: Mon, 13 Jul 2020 19:19:06 +0100

On Sun, Jul 12, 2020 at 02:48:03AM +0300, Boian Bonev wrote:
> I suppose that the soltion is to fork the package. In case that is agreed
> upon, I can prepare the modified package and upload it somewhere...

Boian,

Thanks for this.

If you are prepared to fork an maintain a package that would be great.

In  the first instance I suggest you put it in your personal namespace on
https://git.devuan.org. Once we have reviewed it we can adopt it as an official
package.

You will find information about the Devuan packaging style here:
https://git.devuan.org/devuan/documentation/src/branch/master/maintainers

Thanks.

Mark

---

From: Boian Bonev <[email-masked]>
Date: Tue, 14 Jul 2020 04:47:56 +0300

Hi Mark,

> If you are prepared to fork an maintain a package that would be

Sure, why not.

At first glance the package in Debian sid has some changes that are not
in the package git repository https://github.com/bzed/pkg-gpsd - the
latest there is 3.19-1. It would have been nicer to keep that history
but alas 3.20-12 is not there. Cloning that and committing the 3.20-12
on top of that does not make much sense to me, so I decided to only
import 3.20-12 without history.

I am going to remove systemd dependencies and stuff first and then
maybe do some cleanup; I am wondering how much cleaning it up is a good
idea or not - maintaining that later would be easier if it is kept as
close to the Debian package as possible...

> https://git.devuan.org. Once we have reviewed it we can adopt it as

My repo is https://git.devuan.org/bbonev/gpsd I will update here after
it is ready for review.

With best regards,
b.

---

From: [email-masked]
Date: Wed, 15 Jul 2020 18:14:10 +0300

Hi Mark,

I have done the initial fork effort, also fixed some things that were, IMHO, problems in the original package. From what I see, there is lots more work to do for this package, but at least I think that it is OK for a review.

I could test it on aarch64 and amd64, but only via debuild/dpkg-buildpackage. Setting up a proper build env with chroots, cross, etc is not a thing that I know how to do...

I saw in the gpsd package change log that sysvinit stuff was removed because it was causing problems with systemd; what concerns me is that in case these reasons are valid (and most probably they are) then the same is going to happen with many other packages.

it is ready for review.

With best regards,

b.

---

From: Mark Hindley <[email-masked]>
Date: Thu, 16 Jul 2020 11:16:10 +0100

On Wed, Jul 15, 2020 at 06:14:10PM +0300, [email-masked] wrote:
>    Hi Mark,
>    I have done the initial fork effort, also fixed some things that were,
>    IMHO, problems in the original package. From what I see, there is lots
>    more work to do for this package, but at least I think that it is OK
>    for a review.

Thanks.

>    I could test it on aarch64 and amd64, but only via
>    debuild/dpkg-buildpackage. Setting up a proper build env with chroots,
>    cross, etc is not a thing that I know how to do...

The documentation is here:
https://git.devuan.org/devuan/documentation/src/branch/master/maintainers/PackagingGuide.md

You will need to follow that. Out package builder uses git buildpackage and your
repo doesn't build with that ATM.

Ping me on #devuan-dev if you need more help.

It might be worth asking the Debian maintainer to update their tree and then you
can just import it with history.

>    I saw in the gpsd package change log that sysvinit stuff was removed
>    because it was causing problems with systemd; what concerns me is that
>    in case these reasons are valid (and most probably they are) then the
>    same is going to happen with many other packages.

Possibly :(

Thanks

Mark

---

From: Boian Bonev <[email-masked]>
Date: Fri, 17 Jul 2020 20:41:47 +0300

Hi Mark,

> repo doesn't build with that ATM.

I have been following exactly that.

Have tried on ascii and chimaera hosts - on ascii the build fails
because scons requires newer Python while on chimaera "dpkg-source -b
." exits with 127 without particular reason for that:

 dpkg-source -b .
dpkg-source: warning: upstream signing key but no upstream tarball
signature
dpkg-source: info: using options from gpsd-3.20/debian/source/options:
--extend-diff-ignore=^\.travis\.yml$
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building gpsd using existing ./gpsd_3.20.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit
status 127

I have got the same error on aarch64/RPI with Devuan/chimaera while
using debuild and could make it work only by renaming dpkg-source and
wrapping it to change 127 to 0 (but obviously that is only a temp
workaround). I suppose there is some problem in latest dpkg-source or I
have missed to install/configure something but couldn't find what it
is.

Can you share some error message that you have seen?

> Ping me on #devuan-dev if you need more help.

Haven't been on irc last 25+ years ;) Will try to see if I still
remember how that is done.

> can just import it with history.

Will try that. It wouldn't be too hard to rebase my commits on top of
it.

With best regards,
b.

---

From: Mark Hindley <[email-masked]>
Date: Sat, 18 Jul 2020 15:28:39 +0100

> I have been following exactly that.

Well it describes how to set up pbuilder chroots and git-buildpackage.

> ." exits with 127 without particular reason for that:

You need to build for unstable (ceres):

 - apt install git-buildpackage pbuilder cowbuilder
 - gbp buildpackage --git-pbuilder --git-dist=ceres create --mirror http://pkgmaster.devuan.org/merged
 - set up debian/gbp.conf
 - tag the upstream release
 - gbp buildpackage --git-pbuilder --git-dist=ceres

Hope that helps.

Mark

---

From: Boian Bonev <[email-masked]>
Date: Sun, 19 Jul 2020 05:33:38 +0300

Hi Mark,

>  - gbp buildpackage --git-pbuilder --git-dist=ceres

Thanks for the hint; I was missing the tag part, but that didn't help
either. If I build for chimaera, then all works fine. For ceres it
fails with the same problem. I have tried to install gpg and gpg-agent
in the chroot, the warning messages disappeared but that also didn't
help.

The good news is that I could fix some of the lintian warnings for the
package; the bad news is that I have no clue why this is not working
for ceres...

With best regards,
b.

---

From: Mark Hindley <[email-masked]>
Date: Fri, 7 Aug 2020 17:21:09 +0100

Boian,

Hi.

Thanks for working on this.

On Fri, Aug 07, 2020 at 05:11:52AM +0300, Boian Bonev wrote:
[…]
 
> In the meantime I have fixed this and that in the gpsd package, most of
> the fixes were accepted upstream, some are pending.
> 
> Just don't know how good idea it is to also make improvements while
> forking, but I felt like gpsd needed these changes ;) Anyways, I
> believe that it is now ready, please check it.

If you are maintaining and think those changes are right and necessary, that
seems fine to me. 

I have just built your new branch suites/unstable and it builds for me without
any other problems than the test failure (ignored) that we have both seen. I
assume you have checked functionality.

Are you able to fix #314?

A couple of comments about the packaging:-

 - Please close #490 in the 'Fork for Devuan' changelog entry.
 
 - d/gbp.cong: debian-tag would be better as devuan/%(version)s.
 
 - d/control: please base the Vcs-* URLs on https://git.devuan.org/devuan/gpsd
   so they will be correct once the package is in the definitive location.

 - 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.

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.

Thanks.

Mark

---

From: Boian Bonev <[email-masked]>
Date: Fri, 07 Aug 2020 23:57:57 +0300

Hi Mark,

On Fri, 2020-08-07 at 17:21 +0100, Mark Hindley wrote:

...

> 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).

I tried to do a cross build but that didn't work... And the native one
takes too much time.

> Are you able to fix #314?

Checked it just now - that one does not apply to gpsd 3.20; previous
gpsd versions generated header file with a fix for roll overs during
build time (based on current time), so gpsd 3.16 built back in time had
the problem while newly built one didn't have it. Upstream reworked the
whole thing long ago. Unfortunatelly I can't verify it, just checked
the source of gpsd and https://gitlab.com/gpsd/gpsd/-/issues/3 and it
seems fixed.

>  - Please close #490 in the 'Fork for Devuan' changelog entry.

sure, also closed 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.

>  - d/gbp.cong: debian-tag would be better as devuan/%(version)s.

ok

>    so they will be correct once the package is in the definitive

ok

>    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. Also I see that there is a transition for
gpsd-dbg to gpsd-dbgsym which I believe is long ago finished.

> and make you maintainer. Then you will be able to trigger the

I have no idea how that part works. Is there a way to test it first?

I will update the bug after I think that the package is ready.

With best regards,
b.

---

From: Mark Hindley <[email-masked]>
Date: Sat, 8 Aug 2020 10:50:21 +0100

On Fri, Aug 07, 2020 at 11:57:57PM +0300, Boian Bonev wrote:
> > I assume you have checked functionality.
> 

OK.

> >  - Please close #490 in the 'Fork for Devuan' changelog entry.

Great.
 
> complaining about improbable-bug-number-in-closes.

They aren't. It is just that building on Devuan buildhosts will close Devuan BTS
bugs.

If you install devuan-lintian-profile you should get more sane lintian warnings.
 
> conflict.
> But on second thought, to avoid possible confusion, it is a
> with new gpsd-dbg-tools.

Yes, exactly.

> Also I see that there is a transition for

Not really. If a local build with gbp works it should be OK. The documentation
for how to trigger the production build is
https://git.devuan.org/devuan/documentation/src/branch/master/maintainers/JenkinsAutobuild.md

Thanks.

Mark

---

From: Boian Bonev <[email-masked]>
Date: Sun, 09 Aug 2020 03:13:40 +0300

Hi Mark,

> > it there (it is a production one, but I have means to bypass in

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?
....
> They aren't. It is just that building on Devuan buildhosts will close

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

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

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.

> 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.

With best regards,
b.

---

From: Mark Hindley <[email-masked]>
Date: Sun, 9 Aug 2020 11:32:45 +0100

Great.

[…]

> something to fix, I will do it fast.

I have copied to https://git.devuan.org/devuan/gpsd and added you as
maintainer. 

> https://git.devuan.org/devuan/documentation/src/branch/master/maintainers/JenkinsAutobuild.md

You should be able to trigger a build as documented ^^^

Thanks.

Mark