Backport jansson 2.14 to jammy from kinetic

debdiff with kinetic which shows it is a simple rebuild in jammy

debdiff with jammy which shows the diff from 2.13 to 2.14

The attachment "jansson_kinetic.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

Testing I did
1. I have built jansson 2.14 on all architecture in my personal PPA. https://launchpad.net/~hm-hui/+archive/ubuntu/sru-all/+packages

2. Verified the bug with a private package on arm64 platform on jammy and the bug gone after the package is rebuilt with jansson 2.14 in jammy.

3. Upgrade jansson to 2.14 on an amd64 desktop and performed some basic functions with network-manager without any issue. Also there aren't any interruption during upgrade/downgrade of jansson library

4. Use emacs to do some json file formatting and editing with jansson 2.14 installed. No issues discovered.

I reviewed the diff between 2.14 in kinetic and this upload (just changelog), and I carefully reviewed the 2.13 + Ubuntu changes to 2.14 + Debian changes diff again; outside of some autotools noise, the changes were carefully adding symbol versioning, a few symbols for new functions, and on the packaging side bumping the generated dependencies – +1, uploaded to -proposed (waiting for SRU team to review)

somehow the diff on the sru queue only shows the changelog diff and nothing else

Is there a specific user story that you're looking to fix here? Eg. crash reports in specific apps? What are you planning to rebuild to use the newly versioned symbols? If possible, I'd like to see these verified in proposed at the same time.

On the specific fix, there is quite a bit of noise here. Did you consider cherry-picking the symbol versioning change only? I think this should be safe and not an ABI break, but I'm not that familiar in this area. Is there something I'm missing - why is a backport required instead?

@Timo/SRU team: I think the debdiff you're seeing is between kinetic and jammy, and since it's essential a backport, it would indeed be trivially small.

The debdiff between latest jammy and this SRU corresponds to the new upstream release, and that's the part I've carefully reviewed with Hon Ming and that will bring the relevant fix.

The package that will experience the symbol conflict and crash is called vvas. We package it for the Xilinx partner project. VVAS is a major video analytic component and it linked with both jansson and json-c . I have some test packages built in my own ppa https://launchpad.net/~hm-hui/+archive/ubuntu/xilinx/+packages

I will also rebuild and test the jansson backport when it is landed to proposed

OK, so to make sure I understand: nothing in the archive is directly affected by this bug. But if a user builds their own thing with both jansson and json-c, then the symbol conflict arises.

I think this is still fine in principle to SRU, but I would like your out-of-archive component (vvas) tested against the proposed pocket as part of the SRU verification please, and your confirmation that the problem is fixed, before we release it.

Separately, above I asked:

> On the specific fix, there is quite a bit of noise here. Did you consider cherry-picking the symbol versioning change only? I think this should be safe and not an ABI break, but I'm not that familiar in this area. Is there something I'm missing - why is a backport required instead?

I think this question is still outstanding. Why can we not make the minimal necessary changes?

Thanks for the review Robie!

Agreed that verification makes sense with a program built against both libraries before and after this fix

Why backport 2.14 rather than cherry-pick the corresponding change? It would be feasible to cherry-pick just the change to add symbol versioning (you can see it here: https://github.com/akheron/jansson/pull/540/files), but IMO:
1) we'd have to autoreconf in a patch or at build-time, which would be a similar amount of noise in build files (the patch touches configure.ac, Makefile.am, CMakeLists.txt)

2) I think it's good to land the actual version number bump along with this kind of change: it reflects through the version number that we have this fix in (I know the proper way to check if a feature is there is to test for the feature and not the upstream version), in particular when it's about adding symbol versioning

3) the other minor changes in the new upstream release all seemed conservative fixes addressing simple issues that seemed LTS worthy (some even seemed to border on improving the security of some functions)

4) taking the backport as a whole seemed simplest and less risky than splitting things up

Hope you see the same pros and cons and why we went this way

> 3) the other minor changes in the new upstream release all seemed conservative fixes addressing simple issues that seemed LTS worthy (some even seemed to border on improving the security of some functions)

The catch is that these changes then need individual review and consideration as to whether they are acceptable, including by the SRU team. The default is that we expect each change to be individually tested, too, unless the upstream meets the quality criteria detailed at https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases. Is this the case here?

An upload of jansson to jammy-proposed has been rejected from the upload queue for the following reason: "Questions in https://bugs.launchpad.net/ubuntu/+source/jansson/+bug/1987678 remain unresolved after many months".