Please upgrade libproxy to 0.4.x

[Pēteris Krišjānis]

Please upgrade libproxy to 0.4.0 in Lucid, as it is important for Gwibber (which is one of core apps for Lucid) to provide much needed proxy support (https://bugs.launchpad.net/bugs/259830 - I will provide patch) before release. Current version 0.2.3 is very old (~ 2 years), and only generally support GNOME proxy settings, in same time lacking authentication and https support. But 0.4.0 has very clean and very up to date GNOME proxy settings support, including it also has lot of bugfixes.

Most important reasoning of this appeal is that according to libproxy developer's claim, there is no API changes between 0.2.3 and 0.4.0 versions, therefore after careful investigation there should be no problems with this bump. Also any application which depends on libproxy would benefit from better auto-magical proxy discovery.

[Nathaniel McCallum (nathaniel)]

To be clear, there is ONE, SMALL API change. In versions >= 0.4.0 the function px_proxy_factory_get_proxies() may return NULL. Applications that didn't consider this case should be fixed regardless. Apps that do consider this case will work on both versions. libproxy 0.4.0 does include a soname bump, so applications will probably need to be rebuilt. Applications using any of the bindings should not need a rebuild.

[Sebastien Bacher (seb128)]

the lucid version has been updated to 0.3.2 which is what debian testing has right now and has been tested, why does the new version has a soname change if there is no compatibility breakage?

[Pēteris Krišjānis (pecisk-gmail)]

I hope Nathaniel will answer with more detail, but what I seen in code it's mostly means feature maturity. For example, 0.4 version has very correct GNOME proxy support, where previous versions where lacking stuff like authentication, also inner logic has improved.

[Nathaniel McCallum (nathaniel)]

There is one external API change. In < 0.4.0 I had documented that px_proxy_factory_get_proxies() would never return NULL. In 0.4.0 that is no longer the case. All though technically ABI is probably unchanged (its a grey area), I thought it better safe than sorry to bump the soname. Apps written for < 0.4.0 that ignored my documentation and tested for NULL anyway will work without a recompile. Apps that heeded my old documentation might crash if libproxy returns NULL and should handle that case.

[dobey (dobey)]

I've built 0.4.6 in my personal PPA. It appears there are a few more issues though. It seems like there is now a circular dependency issue with libsoup, as libproxy seems to depend on it now.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Brian J. Murrell (brian-interlinx)]

Look. libproxy 0.3.1 is broken and obsolete. The developers of it have completely abandoned it and are not making any fixes to it, and it's broken!

Current release of libproxy is 0.4.7. Why are you so stubbornly refusing to update even future releases like Natty+1 with the currently maintained release of this package?

[Nerd_bloke (nerd-bloke)]

Canonical won't update until they can pull from Debian, that is why its bug is linked here.

[Brian J. Murrell (brian-interlinx)]

On 11-09-16 07:46 AM, Nerd_bloke wrote:
> Canonical won't update until they can pull from Debian, that is why its
> bug is linked here.

But my O/S vendor is Canonical, not Debian. If I wanted to have to deal
with the Debian political quagmire, I'd install a Debian O/S. Why is
Canonical not pushing (i.e. requesting package updates) of Debian on
behalf of it's users? Why do I, as simply a Ubuntu user have to push
Debian so that you can pull an update from them?

Looking about this another way, I don't have a Debian O/S on which to
actually test Debian's libproxy and so cannot in any good faith put
together a legitimate bug report about a Debian O/S. So why should I
have to?

[Brian J. Murrell (brian-interlinx)]

OK. So this policy that Canonical (i.e. Ubuntu) won't update libproxy until Debian does is just stupid.

Waiting for libproxy 0.4.7 in Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604934) is just another case of some "Debian idealist" who is letting his desire for the *perfect* solution stand in the way of something that will actually work and be useful to user community. In the meanwhile users have broken systems.

Yes, it would be simply wonderful if we could all have ponies and pots of gold and everything else we want, but we can't. So we accept what we can have and try to live a useful life with what we get. Why can't we apply that here? Let's not wait for the Perfect World According to Debian and just have an O/S that is at least functional (if not perfect), yes?

And seriously? Is there really some stupid policy that Ubuntu cannot upgrade a single package until it's available in Debian? Where is that documented?

[Sebastien Bacher (seb128)]

Brian, the update is not blocked on Debian, it's blocked on having somebody with time or interest for libproxy wanting to do the update

[Sebastien Bacher (seb128)]

Ken, could you have a look to that update this cycle? The old version isn't compatible with GNOME3, see i.e bug #893031, so we will have to do the update

[Nerd_bloke (nerd-bloke)]

I think bug 304889 is actually the main one, CMs need an up-to-date libproxy backend.

[Brian J. Murrell (brian-interlinx)]

~sigh~ My mistake for listening to Nerb_bloke. Sorry for the rant in that case.

I guess it would have been nice if somebody spoke up and explained it was not being updated simply due to manpower and not silly policy stupidity. This bug has been open for almost 2 years now with several long gaps where people just simply didn't respond.

In any case, I will look forward to the update since the current version is completely broken. Some easy SRU backports would be nice considering they couldn't make libproxy any more broken than it already is -- that is, completely unusable at the moment.