Re: [gpsd-dev] Repo and web pages have been re-homed

[Gary E. Miller]

Yo Fred!

On Tue, 11 Jun 2019 16:13:30 -0700 (PDT)
Fred Wright <address@hidden> wrote:

> On Tue, 11 Jun 2019, Gary E. Miller wrote:
> > On Mon, 10 Jun 2019 21:27:35 -0700 (PDT)
> > Fred Wright <address@hidden> wrote:
> >  
> >> On Mon, 10 Jun 2019, Gary E. Miller wrote:
> >>  
> >>> Probably about time to do a new release to go with the new
> >>> repository address and web page address.  Also the new NMEA 4.10,
> >>> ZED, SiRFStar V, multi signal (L1/L2/L5), and Android support are
> >>> cool new features.  
> >>
> >> Also, if it hasn't already been done, it would be good to migrate
> >> all the existing releases to wherever the new releases will be on
> >> GitLab, so that one doesn't need "split horizon" release fetches.  
> >
> > Good point.  Does GitLab have an noptions for arbitrary file
> > hosting? Or should be consider some other file hosting?  
> 
> I don't know how the GitLab release mechanism works, but I presume
> there's some sort of "make a release" feature that captures a release
> tarball. The question is whether it's possible to load preexisting
> release tarballs into that same area.  It *might* be possible to
> populate it by creating GitLab releases from all the release tags,
> but that would be rather tedious and almost certainly wouldn't result
> in bitwise identical tarballs.

Yeah, unknown.  Investigating.

> >>> Ideas?  
> >>
> >> There are a bunch of suspicious warnings in *BSD builds.  They're
> >> probably not really release blockers, since 3.18.1 didn't build at
> >> all on *BSD, but I'll see if I can fix them.  It may not be
> >> trivial, though, since they may involve the ever-troublesome
> >> config flags.  
> >
> > I don't run any BSD.  Can someone run point on that?  
> 
> I have VMs for FreeBSD 10.3, OpenBSD 5.6, and NetBSD 6.1.5, which is
> how I know about the issue. :-)

Hal is giing to look at it.  If you could send your build failures
they may be easily fixable.

> >> Meanwhile, it would be good to hold off on any changes with a
> >> significant risk of breakage until after the release.  Each of the
> >> last three releases introduced at least one new bug; it would be
> >> nice to break that habit. :-)  
> >
> > Yeah, from here forward I'd prefer on doc changes and rifle shot
> > bug fixes.  
> 
> It occurred to me that, given the timing, it might make sense to wait
> for the July Bulletin C (probably out in the first week of July), in
> order to incorporate a December leap second, if applicable.  But then
> again, a December leap second looks pretty unlikely, given the
> current DUT1 forecast.

The leap second is built into gpsd at build time, not at release time.

This is confusing Debian as they keep asking me to fix a file in git
that is only created at build time...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpJ0efJ4X3Im.pgp
Description: OpenPGP digital signature