HEADSUP: json-c SONAME BUMP

[Christopher Meng]

Hi,

As upstream didn't seriously consider the API breakage, json
0.11->0.12 brings an issue of one function which is deprecated from
now on. This has caused bug 1123785 so I will bump the soname
manually:

libjson-c.so.2.0.1->libjson-c.so.3.0.0

Potentially affected:

abrt-plugin-bodhi-0:2.2.2-4.fc22.i686
bti-0:034-3.fc21.i686
ceelog-0:0.2-3.fc21.i686
ceelog-libs-0:0.2-3.fc21.i686
dwb-0:2014.03.07-1.fc21.i686
java-shogun-0:3.2.0.1-0.12.git20140317.6ee3991.fc21.i686
json-c-devel-0:0.12-2.fc22.i686
lcgdm-dav-server-0:0.14.1-6.fc22.i686
libreport-plugin-bugzilla-0:2.2.3-3.fc22.i686
libreport-plugin-kerneloops-0:2.2.3-3.fc22.i686
libreport-plugin-reportuploader-0:2.2.3-3.fc22.i686
libreport-plugin-rhtsupport-0:2.2.3-3.fc22.i686
libreport-plugin-ureport-0:2.2.3-3.fc22.i686
libreport-web-0:2.2.3-3.fc22.i686
libverto-jsonrpc-0:0.1.0-9.fc21.i686
lua-shogun-0:3.2.0.1-0.12.git20140317.6ee3991.fc21.i686
mono-shogun-0:3.2.0.1-0.12.git20140317.6ee3991.fc21.i686
mypaint-0:1.1.0-2.fc21.i686
newsbeuter-0:2.8-2.fc21.i686
octave-shogun-0:3.2.0.1-0.12.git20140317.6ee3991.fc21.i686
opensips-json-0:1.10.1-2.fc21.i686
php-pecl-jsonc-0:1.3.5-4.fc21.i686
postgis-0:2.1.3-3.fc21.i686
pulseaudio-libs-0:5.0-7.fc22.i686
python-shogun-0:3.2.0.1-0.12.git20140317.6ee3991.fc21.i686
python3-shogun-0:3.2.0.1-0.12.git20140317.6ee3991.fc21.i686
rsyslog-0:7.4.10-2.fc21.i686
ruby-shogun-0:3.2.0.1-0.12.git20140317.6ee3991.fc21.i686
shogun-0:3.2.0.1-0.12.git20140317.6ee3991.fc21.i686
shogun-cli-0:3.2.0.1-0.12.git20140317.6ee3991.fc21.i686
steam-noruntime-0:1.0.0.48-2.fc21.noarch
syslog-ng-json-0:3.5.5-1.fc22.i686
zmap-0:1.2.1-1.fc22.i686

However, some don't use json_tokener_errors() in the code, for example
zmap, is not affected, so there are some false positives here. Please
rebuild your package on f21+ branches. I've unpushed the update of
json-c on elder branches.

Thanks.

Yours sincerely,
Christopher Meng

http://cicku.me

HEADSUP: json-c SONAME BUMP - please REVERT

[Remi Collet]

Le 28/07/2014 14:53, Christopher Meng a écrit :
>  Hi,
>  
>  As upstream didn't seriously consider the API breakage, json
>  0.11->0.12 brings an issue of one function which is deprecated from
>  now on. This has caused bug 1123785 so I will bump the soname
>  manually: 

Please consider reverting to 0.11 in Fedora 21


This update breaks php-pecl-jsonc (lot of test are now "failed")


We already have lot of people crying because of minor behavior change
between ext/json (non-free) and pecl/jsonc, introducing some other is
juste a very bad idea.


My goal is to fork the json-c parser, bundled it in pecl/jsonc (yes !)
and adapt it to optimize parser time and fix difference with ext.json

But this is a long road and probably not in a very short time.



Remi.

[Pierre-Yves Chibon]

On Mon, Jul 28, 2014 at 08:53:53PM +0800, Christopher Meng wrote:
>  Hi,
>  
>  As upstream didn't seriously consider the API breakage, json
>  0.11->0.12 brings an issue of one function which is deprecated from
>  now on. This has caused bug 1123785 
>  so I will bump the soname manually 
I'm sorry, wat???

This is not your decision to make as packager. What will you do when upstream
bump the soname? Do soname +1 again?

If the udpate broke packages: a) it should not have been updated on stable
releases (was it?), b) if it was only applied to rawhide (which to my
understanding it should have), then just inform the maintainers of the affected
packages that they have to rebuild or ask to do so yourself. Since can be a
little broken in rawhide as long as maintainers are aware of it and have the
time to fix it.

But bumping the soname manually is really a bad idea.


Pierre

[Michael Schwendt]

On Mon, 28 Jul 2014 15:36:48 +0200, Pierre-Yves Chibon wrote:

>  If the udpate broke packages: a) it should not have been updated on
> stable
>  releases (was it?), 
Two updates have been filed hours ago,

  https://admin.fedoraproject.org/updates/json-c-0.12-1.fc20
  https://admin.fedoraproject.org/updates/json-c-0.12-1.el6

and it seems the upgrade has not been examined at all. I've mentioned in
bugzilla that there are tools such as rpmsodiff and abi-compliance-checker.

[Peter Robinson]

> > If the udpate broke packages: a) it should not have been updated
> on stable
> > releases (was it?),
>
>  Two updates have been filed hours ago,
>
>    https://admin.fedoraproject.org/updates/json-c-0.12-1.fc20
>    https://admin.fedoraproject.org/updates/json-c-0.12-1.el6
>
>  and it seems the upgrade has not been examined at all. I've mentioned in
>  bugzilla that there are tools such as rpmsodiff and abi-compliance-checker. 
There is no way an intrusive change such as this should be going
through to a stable release such as F-20, even worse for an EPEL
release. If it's deemed that a change such as this needs to go through
to a stable release due to something severe such as a security issue
it needs to announced before it happens and coordinated widely before
randomly being pushed without any details with dependent libraries and
applications.

Peter

[Remi Collet]

Le 28/07/2014 16:03, Peter Robinson a écrit :
> >> If the udpate broke packages: a) it should not have been
> updated on stable
> >> releases (was it?),
> >
> > Two updates have been filed hours ago,
> >
> >   https://admin.fedoraproject.org/updates/json-c-0.12-1.fc20
> >   https://admin.fedoraproject.org/updates/json-c-0.12-1.el6
> >
> > and it seems the upgrade has not been examined at all. I've mentioned in
> > bugzilla that there are tools such as rpmsodiff and abi-compliance-checker.
>  
>  There is no way an intrusive change such as this should be going
>  through to a stable release such as F-20, even worse for an EPEL
>  release. If it's deemed that a change such as this needs to go through
>  to a stable release due to something severe such as a security issue
>  it needs to announced before it happens and coordinated widely before
>  randomly being pushed without any details with dependent libraries and
>  applications.
>  
>  Peter
>   
And despite the update claims to fix CVE-2013-6371, this one was already
fixed in
https://admin.fedoraproject.org/updates/FEDORA-2014-5006

Remi.

[Miloslav Trmač]

----- Original Message -----
>  On Mon, Jul 28, 2014 at 08:53:53PM +0800, Christopher Meng wrote:
>  > As upstream didn't seriously consider the API breakage, json
>  > 0.11->0.12 brings an issue of one function which is deprecated from
>  > now on. This has caused bug 1123785
>  
>  > so I will bump the soname manually
>  
>  I'm sorry, wat???
>  
>  This is not your decision to make as packager. What will you do when upstream
>  bump the soname? Do soname +1 again?
>  
>  If the udpate broke packages: 
<snip>
>  b) if it was only applied to rawhide (which to my
>  understanding it should have), then just inform the maintainers of the
>  affected
>  packages that they have to rebuild or ask to do so yourself. 
No, that would completely defeat the point of the soname.  If upstream won’t use sonames
or symbol versioning, it’s better for Fedora to patch the software to use them properly,
even if it means having to continue to patch it.  IIRC we do have various packages that
have to do this.

(The tradeoff here is that if we don’t fix the soname/versioning usage, locally-compiled
software of _Fedora’s_ users, and packages in _Fedora_ that didn’t get updated, are
silently broken; if we do fix the soname/versioning usage, other people’s _non-Fedora_
packages may not be installable on Fedora easily.  The best thing of course is to have
upstream use sonames/versioning correctly, and have nothing broken; but if that’s not
possible, a Fedora-specific fix does seem much more preferable.)
    Mirek

[Simo Sorce]

On Mon, 2014-07-28 at 12:02 -0400, Miloslav Trmač wrote:
>  ----- Original Message -----
>  > On Mon, Jul 28, 2014 at 08:53:53PM +0800, Christopher Meng wrote:
>  > > As upstream didn't seriously consider the API breakage, json
>  > > 0.11->0.12 brings an issue of one function which is deprecated from
>  > > now on. This has caused bug 1123785
>  > 
>  > > so I will bump the soname manually
>  > 
>  > I'm sorry, wat???
>  > 
>  > This is not your decision to make as packager. What will you do when upstream
>  > bump the soname? Do soname +1 again?
>  > 
>  > If the udpate broke packages:
>  <snip>
>  > b) if it was only applied to rawhide (which to my
>  > understanding it should have), then just inform the maintainers of the
>  > affected
>  > packages that they have to rebuild or ask to do so yourself.
>  
>  No, that would completely defeat the point of the soname.  If upstream
>  won’t use sonames or symbol versioning, it’s better for Fedora to
>  patch the software to use them properly, even if it means having to
>  continue to patch it.  IIRC we do have various packages that have to
>  do this. 
If upstream is not using soname bumping then it would probably be better
for fedora to use symbol versioning rather than arbitrarely bumping so
names ...

>  (The tradeoff here is that if we don’t fix the soname/versioning
>  usage, locally-compiled software of _Fedora’s_ users, and packages in
>  _Fedora_ that didn’t get updated, are silently broken;  
it is a very bad tradeoff, esp given symbol versioning can be used to
avoid that.

>  if we do fix the soname/versioning usage, other people’s
> _non-Fedora_
>  packages may not be installable on Fedora easily.  The best thing of
>  course is to have upstream use sonames/versioning correctly, and have
>  nothing broken; but if that’s not possible, a Fedora-specific fix does
>  seem much more preferable.) 
Making upstream aware of the problem and sending patches is always
preferable. Educate them so the problem is solved once and for all.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Michael Schwendt]

On Mon, 28 Jul 2014 12:02:24 -0400 (EDT), Miloslav Trmač wrote:

>  If upstream won’t use sonames or symbol versioning, it’s better for
> Fedora to patch the software to use them properly, even if it means having to continue to
> patch it.  IIRC we do have various packages that have to do this.
>   
Just for the record, they do use soname versioning,

  libjson.so.0.1.0
  libjson-c.so.2.0.1

but it may have been an accident to not bump it this time. The first thing
to do would be to contact them (two tickets have been opened already) and
talk about it.

Simply bumping the soname version at Fedora can easily lead to trouble,
e.g. if the next upstream release dropped more symbols together with
bumping the soname, Fedora would be out-of-sync again and would need to
stay incompatible with even another soname bump. That's not good and
inconvenient, too.

$ rpmsodiff json-c-0.11-6.fc20.x86_64.rpm json-c-0.12-1.fc20.x86_64.rpm 
	sonames only in json-c-0.11-6.fc20 [1]:
libjson.so.0	/usr/lib64/libjson.so.0.1.0

	common sonames:
libjson-c.so.2	/usr/lib64/libjson-c.so.2.0.1	/usr/lib64/libjson-c.so.2.0.1

--- json-c-0.11-6.fc20/libjson-c.so.2	2014-07-28 15:52:50.704003501 +0200
+++ json-c-0.12-1.fc20/libjson-c.so.2	2014-07-28 15:52:54.744786003 +0200
@@ -20,2 +20,3 @@
 json_object_array_sort	T
+json_object_free_userdata	T
 json_object_from_file	T
@@ -42,2 +43,3 @@
 json_object_new_double	T
+json_object_new_double_s	T
 json_object_new_int	T
@@ -58,2 +60,3 @@
 json_object_to_json_string_ext	T
+json_object_userdata_to_json_string	T
 json_parse_double	T
@@ -61,3 +64,2 @@
 json_tokener_error_desc	T
-json_tokener_errors	D
 json_tokener_free	T
@@ -89,3 +91,2 @@
 lh_table_resize	T
-mc_abort	T
 mc_debug	T

	2 symbols removed
D json_tokener_errors
T mc_abort

	3 symbols added
T json_object_free_userdata
T json_object_new_double_s
T json_object_userdata_to_json_string

# template for libjson-c.so.2 version script
JSON_0.12 {
    global:
	json_object_free_userdata;
	json_object_new_double_s;
	json_object_userdata_to_json_string;
};

vim:ft=diff

[Paolo Bonzini]

Il 28/07/2014 18:02, Miloslav Trmač ha scritto:
>  No, that would completely defeat the point of the soname.  If
>  upstream won’t use sonames or symbol versioning, it’s better for
>  Fedora to patch the software to use them properly, even if it means
>  having to continue to patch it.  IIRC we do have various packages
>  that have to do this. 
In this particular case, maybe it's possible to add back the symbols so
that the ABI is preserved.

Paolo

[Christopher Meng]

Hi all,

Thanks for your comment. Those 2 updates was already canceled
yesterday as I've realized the problem after Sandro's bug report.

TL;DR: Updates revoked, rawhide+f21 reverted to 0.12 without bump,
deciding if we need to add epoch to revert back to 0.11.

It's tricky now.

1. Upstream changelog:

  * Make the json_tokener_errors array local.  It has been deprecated for
     a while, and json_tokener_error_desc() should be used instead.

Relative commit: [2]

Porting the code is needed for other upstreams. For the soname bump
I've opened a PR on github but since upstream are inactive since May
so I don't expect they will reply to/dicuss it.

2. As requested by some people[3], 0.12 is not compatible with some
existing packages in the repo, thus I think it's time postpone the
update.

As there are a few hours before today's rawhide compose, I'm going to
revert back the
soname bump in -4 build, now they're done[3][4].

Thanks.

[1]---https://raw.githubusercontent.com/json-c/json-c/master/ChangeLog
[2]---https://github.com/json-c/json-c/commit/f9136f68520db4761f05810f9792...
[3]---https://bugzilla.redhat.com/show_bug.cgi?id=1123785#c7
[4]---http://koji.fedoraproject.org/koji/buildinfo?buildID=548502
[5]---http://koji.fedoraproject.org/koji/buildinfo?buildID=548503

[Matthias Runge]

On Tue, Jul 29, 2014 at 09:43:14AM +0800, Christopher Meng wrote:
>  TL;DR: Updates revoked, rawhide+f21 reverted to 0.12 without bump,
>  deciding if we need to add epoch to revert back to 0.11. 
Thank you.

I noticed, you're a bit quick in pushing updates to stable releases.
When pushing to older branches, please keep our stable updates policy in
mind [1].

Thanks,
Matthias

[1] https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases

-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;

[Florian Weimer]

On 07/28/2014 10:40 PM, Paolo Bonzini wrote:
>  Il 28/07/2014 18:02, Miloslav Trmač ha scritto:
> > No, that would completely defeat the point of the soname.  If
> > upstream won’t use sonames or symbol versioning, it’s better for
> > Fedora to patch the software to use them properly, even if it means
> > having to continue to patch it.  IIRC we do have various packages
> > that have to do this.
>
>  In this particular case, maybe it's possible to add back the symbols so
>  that the ABI is preserved. 
We need a soname bump and one point anyway to address the symbol 
collisions between json-c, json-glib, and jansson.  The json-c/json-glib 
collisions actually materialize in existing binaries.  Removing some 
symbols seems kind of unavoidable, but it is obviously best to bundle 
all this into a single soname bump.

-- 
Florian Weimer / Red Hat Product Security

[Richard W.M. Jones]

On Mon, Jul 28, 2014 at 08:53:53PM +0800, Christopher Meng wrote:
>  Hi,
>  
>  As upstream didn't seriously consider the API breakage, json
>  0.11->0.12 brings an issue of one function which is deprecated from
>  now on. This has caused bug 1123785 so I will bump the soname
>  manually:
>  
>  libjson-c.so.2.0.1->libjson-c.so.3.0.0 
As others have said, this seems a bad idea.  It's best to get upstream
to bump the soname rather than carrying this intrusive change in
Fedora.

Anyway, came here to say that pulseaudio-libs is uninstallable at
Rawhide at the moment ...

DEBUG util.py:283:  Error: Package: pulseaudio-libs-5.0-7.fc22.i686 (build)
DEBUG util.py:283:             Requires: libjson-c.so.2
DEBUG util.py:283:  Error: Package: php-pecl-jsonc-1.3.5-4.fc21.i686 (build)
DEBUG util.py:283:             Requires: libjson-c.so.2

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[drago01]

On Mon, Jul 28, 2014 at 2:53 PM, Christopher Meng <cickumqt(a)gmail.com&gt; wrote:
>  Hi,
>
>  As upstream didn't seriously consider the API breakage, json
>  0.11->0.12 brings an issue of one function which is deprecated from
>  now on. This has caused bug 1123785 so I will bump the soname
>  manually:
>
>  libjson-c.so.2.0.1->libjson-c.so.3.0.0 
No don't do that. Either get the change upstream or leave it as is.
Please revert.