gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] GPSD on Debian 10 (buster): allowing other hosts to acc


From: Gary E. Miller
Subject: Re: [gpsd-users] GPSD on Debian 10 (buster): allowing other hosts to access gpsd
Date: Tue, 1 Oct 2019 14:24:47 -0700

Yo Bernd!

On Tue, 1 Oct 2019 22:53:49 +0200
Bernd Zeimetz <address@hidden> wrote:

> On 9/30/19 10:21 PM, Gary E. Miller wrote:
> >> I'm not asking for a different way how releases are being named.
> >> I'm asking for stable point-releases which do not change the
> >> abi/api, but only fix bugs.  
> > 
> > The API changes you have complained about in the past fixed bugs.
> > That is the ONLY reason the API has changed in years.
> > 
> > So your request is logically impossible.  
> 
> Why?

See below.

> looking at all software in Debian that did the last api change - they
> basically replaced
> 
> gps_read(&gpsd_conn)
> by
> gps_read(&gpsd_conn, NULL, 0)
> 
> so why not adding a new function
> 
> gps_read_new(...) and implementing gps_read(gpsd_conn) as
>   return gps_read_new(&gpsd_conn, NULL, 0);
> 
> That works for most people and doesn't break things...

Maybe a good idea.  Maybe not.  Might have been worth some
thought.  Way too late now.

Please test git head and help make the next release better.

> >>>> A distribution can't just upload a new packages, neither to the
> >>>> current testing/development branch, nor to stable releases.    
> >>>
> >>> And yet, many manage to do that just fine.    
> >>
> >> There are some differences:
> >> - some distributions just don't care if something breaks for some
> >> time
> >> - some have paid developers...
> >> - some are much bigger than others and do not have paid
> >> developers.  
> > 
> > Lost me.  Relevance?  
> 
> In Debian things take longer than in Fedora.
> Choose other distributions that fit above and make up your own
> opinion.

Preaching to the choir.  gpsd tries very hard to compile and run everywhere.

> > Thanks for the list.  I was unaware of those, and none have
> > contacted gpsd, at least for years.  Now how do we get get them the
> > message that they are using an old and known vulnerable API?  
> 
> They already got that message, thanks to the distributions you want to
> get rid of.

Uh, say what?  Once again, please do not put words in my mouth.  I'm
happy to make my own mistakes, but not the ones you wish I made.

> > Fair enough.  But taking several years is something very different.
> > Also a problem of Ubuntu's making.  Other distros do rebuild every
> > day.  
> 
> No distribution rebuilds everything every day. That is just not
> possible, at least not if you have various architectures and lots of
> packages...

Once again, your ignorance is amusing.  But off topic.

> > Sadly CVE are by design private and no warning is possible.  NDA
> > prevented early disclosure of the one API change that you objected
> > to.  
> 
> CVEs are not private by design, you can ask for one in the public,
> thats no problem at all. Debian can do this for you, or github, or
> just send a bug description to oss-sec and ask for help to get one.
> That is easy.

Once again, your ignorance is amusing.  CVE are embargoed, sometimes
for years, much of the related data is never released.

> > Uh, I was not talking about Ubuntu.  Don't take every thing
> > personal.  
> 
> I don't care about Ubuntu, I'm the Debian guy. They take random crap
> from Debian at random times and publish it... Although the gpsd
> package is now in sane hands in Ubuntu.

Sorry, my mistake.  I forget you guys have those turf wars.

> > I'm talking about RHEL which does ship 5+ year old software.  
> 
> But they will also fix bugs in that super old software if you point
> them to, and there are SCLs. No problem to have a currend gpsd in
> rhel6 or 7.

One again, your ignorance is amusing.  My INBOX is full of the RHEL
bugs reported to me, on gpsd, and other packages.  I'll spare you
the long list.

> > I could provide all the patches you need in two days.  If you are
> > gonna be slow, own it.  
> 
> The patches are one part, applying asap them without pissing off other
> maintainers is another one...

You have cart and horse reversed.  I'm annoyed because you refuse to
patch.

> > Apples and oranges.  There is no pickable backport by gpsd policy.
> > The few that have been pointed out to you you have refused to
> > apply.  No point tossing you small one when you refuse the big
> > ones.  
> 
> Which one did I refuse? What are you talking about?

I'm talking about the many changes in 3.19 no picked up.  I guess we
are not in the same discussion?

> >> But the kernel people also tell distributions if there is something
> >> broken, so thats not an issue at all.  
> > 
> > We must be reading a different LKML.  
> 
> That doesn't happen on LKML.

Wow.  You really are in an alternate universe.

> If you are talking about the change for 3.18, again, I can't just
> upload a new gpsd release that breaks KDE and various other software.

Of course not.  Stop raising silly strawmen!

> All reverse build dependencies are fixed, I'm just waiting for an ack
> from the release team.

Well, you could have led with that.  That is all I ask for.

> As mentioned before - transitions need to be coordinated.
> There are >40 transitions going on at the moment, including llvm and
> octave...

Boo hoo, life is hard, then you die.  If you can't take the heat, get
out of the kitchen.

> > But, since you asked, the API change that you refuse to pick up is
> > the really big one that Ubuntu is missing.  If you are not gonna
> > do the big ones, I'm not wsintg my time on the little ones.  
> 
> See above.

Ditto.

> >>>> So basically *you* need to tell the maintainers which issues need
> >>>> to be backported, and which ones are bad enough that they need a
> >>>> CVE or at least a security upload.    
> >>>
> >>> I'm 100% against backports.  I am 100% with Linus that they are a
> >>> sore upon humanity.  If you feel the need to do that, then check
> >>> the gpsd git logs, issues and MR's.    
> >>
> >> Even the Linux kernel has LTS releases which are maintained for
> >> years...  
> > 
> > And the proven track record of those is bad, which is why their
> > number and duration has been shinking fast.  As discussed on LKML.  
> 
> They just have the same issue that I have with you ;)

Great, we agree.  Many projects, as discussed on LKML, and elsewhere
have the issues we seem at odds on.  Maybe Linus, GHK, and others are
correct?  Or at least have good points for you to learn?

> > Seems to me, since you are on an admittedly two year old version,
> > that you wasted time amounts to near zero.  
> 
> HAHAHAHAHAHA. You have so no clue.

Then you wasted your time.

> >> Those packages are not broken.  
> > 
> > Known bugs, that you refuse to fix.  
> 
> Which ones? Point me to them.

I give up.  Every time I am specific you get all random...

This is going nowhere.  I give up until I see a bug report, issue or
MR.  And I don't mean Debian or Ubuntu bug tracker.

When you care to see all the gpsd bugs, known or fixed, they are all out
there in plain site on GitLab.

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

Attachment: pgpo1z0u4sWtB.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]