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

[Bernd Zeimetz]

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



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


> 
>> Reverse Build-depends in main:
>> ------------------------------
>>
>> alfred
>> collectd
>> direwolf
>> foxtrotgps
>> marble
>> navit
>> osmo-bts
>> plasma-workspace
>> s3d
>> uhd
>> viking
> 
> 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.



>>> We are here to help.  
>>
>> Nothing you can help with, except you want to provide patches for
>> ~half of the projects mentioned above.
> 
> The API change is trivial.  I'd be happy to work with any that
> care to not be using a known broken API.
> 
>>>> That alone is not the problem, it happens automatically.  
>>>
>>> Oh, well then, why bring it up?  
>>
>> We can't rebuild the everything every other day, transitions need to
>> be coordinated.
> 
> 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...


>>>> But we also have other transitions that trigger a lot of rebuilds,
>>>> so things need to be coordinated. Which takes some more time and
>>>> ressources. Then gpsd is in a development release.  
>>>
>>> Every distro handles that transitions differently.  Is there
>>> something gpsd should do differently in there?  
>>
>> If you change things that need code changes in the projects which are
>> using libgps, warn early. As soon as they land in git would be the
>> best time...
> 
> 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.


>> Avoiding soname bumps if possible would be nice, also (I know its not
>> always possible, but often it is.
> 
> The API changes have been very few and far between.  The ABI changes
> will be frequent as long as gpsd use C and C has no map class.
> 
>>>> For stable releases, this is impossible.  
>>>
>>> Fair enough, but shipping 5 year old gpsd in a new "stable" release
>>> is unfair to the gpsd users.  
>>
>> 5 years old? Please don't talk bullshit.
>> 3.17: 2017-09-07. That is two years ago.
>> 3.18: 2018-10-02 - we had a transition freeze on 2019-01-12 - two
>> months are just not enough time to fix all packages which failed to
>> build with the new release.
> 
> 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.


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


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

>>>> We can't rebuild the whole archive. All we can do is to fix bugs
>>>> without breaking other things. So..  
>>>
>>> Yeah, boxed yourself in there, didn't you?  
>>
>> What do you mean? We've fixed the CVEs and at least those bugs in
>> json.c in buster, and the CVE in oldstable... I had a look through
>> the commit logs and actually asked on irc and by mail to esr if there
>> is something else to fix, I did not get a reply - and I was not able
>> to find another pickable commit. Don't blame me..
> 
> 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?


>>> And I'm with Linus on this one, flagging changes as CVEs, or
>>> critical, just helps the black hats.  The kernel does not do it.  
>>
>> Should I get you the list of CVEs in the kernel?
> 
> I'm already on it.
> 
>> 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.
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.

All reverse build dependencies are fixed, I'm just waiting for an ack
from the release team.
As mentioned before - transitions need to be coordinated.
There are >40 transitions going on at the moment, including llvm and
octave...

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

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


>>> I guess I'll take #3.  Not enough man power for the first two.  #3
>>> will save us a lot of time helping people with broken packages.  
>>
>> Oh and it will save me a lot of time I seem to be wasting to package
>> gpsd...
> 
> 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.


>> Those packages are not broken.
> 
> Known bugs, that you refuse to fix.

Which ones? Point me to them. I don't refuse to fix bugs I know about.
Are they in the Debian bug tracker? Are they on launchpad? Don't say
there are bugs unless you point me to a bug report.


>> What you see are those who don't know
>> how to use Linux.
> 
> Actually, it is just those that get cconfused by the turd that is
> systemd(ingleberry).
> 
>> Do you really want to help them to compile gpsd and
> 
> YES!  I'm sick of supporting Ubuntu's mistakes.

again, please point me to the issues you are seeing there - basically
they take the stuff from me. So far you are only complaining.

-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F