I will forward this to the upstream to tell this problem.

And, have you requested a rebuild of postgis to see if it still exists?

postgis does not build against the new json-c due to the API changes. I think the first priority is bumping the soname so that all packages with broken dependencies get caught. In particular, for stable releases, the update should get unpushed.

Per upstream changelog, function json_tokener_error_desc() should be its replacement. I will modify the Makefile tomorrow to bump the soname.

I'm starting the checkup to see how many packages affected, 1 confirm unaffected: zmap.

[tinga@fab hhvm]$ readelf -Ws /usr/sbin/zmap | grep json
    15: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_array
    16: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_to_json_string
    17: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_string
    30: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_array_add
    33: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_object
    57: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_int
    67: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_object_add
    92: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_double
   118: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_int64
   124: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_put
   207: 080708a0    32 OBJECT  GLOBAL DEFAULT   24 module_json_file
   223: 080600c0  1537 FUNC    GLOBAL DEFAULT   13 json_output_file_init
   244: 0805fe00   597 FUNC    GLOBAL DEFAULT   13 json_output_file_ip
   365: 08060060    86 FUNC    GLOBAL DEFAULT   13 json_output_file_close

In progress...

Bumped:

json-c-0.12-3.fc22

json-c-0.12-3.fc21

Thank you

This could have been avoided by using basic tools, such as rpmsodiff (or abi-compliance-checker), more often than not during version upgrades.


> +# Bump the soname manually.
> +sed -i 's#2:1:0#3:0:0#' Makefile.am

Has this been acknowledged by the upstream developers? If you bump soname versions on your own, that bears several risks.

Bumping soname without upstream acknowledgment seems a very bad idea (what will you do when upstream will really bump soname ?)


I really prefer we keep 0.11 for now (at least in Fedora 21).


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

(In reply to Remi Collet from comment #7)
> Bumping soname without upstream acknowledgment seems a very bad idea (what
> will you do when upstream will really bump soname ?)
> 
> 
> I really prefer we keep 0.11 for now (at least in Fedora 21).
> 
> 
> More: this update breaks php-pecl-jsonc (lot of test are now "failed")

Is it OK for you to port your code to 0.12? Schedule?

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

Yes I understand. I just spent 2 hours reading your code.

(In reply to Christopher Meng from comment #8)
> > More: this update breaks php-pecl-jsonc (lot of test are now "failed")
> 
> Is it OK for you to port your code to 0.12? Schedule?

Not planed.

External issue appears to be:

https://github.com/json-c/json-c/issues/147

All packages should have been fixed.

Upstream is still keeping silent on the soname bump, I have no idea.