cdr_pgsql: SQL errors on inserting entries

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Please see https://wiki.ubuntu.com/StableReleaseUpdates for Ubuntu's policy, rationale and procedure for updating a stable release.

I'm not sure I follow upstream's versioning scheme, but if the updates fit SRU policy, then this just needs a volunteer to drive it through. The procedure to follow is documented at the above link.

If it does not fit SRU policy, adding a newer version to xenial-backports may be more appropriate. Again, it just needs a volunteer to drive it - details at https://wiki.ubuntu.com/UbuntuBackports

I see. Actually, it probably won't fit SRU policy due to the paragraph:

> Note that some noise introduced by autoreconf is okay, but making structural changes to the build system (such as introducing new library dependencies) is generally not.

in the linked document.

13.1-cert7 and 13.9.1 depend on a newer version of pjproject which is currently not available in the 16.04 repositories, meaning that at least those two packages need to be backported (there is a huge mess with audio/video related issues. How is Ubuntu's stance on bundled libraries? 13.9.1 supports building against a bundled copy of pjproject which removes the need to backport any other dependency. In fact, that is how I'm currently building 13.9.1 on Xenial.

The library is bundled to ensure that a version that has been tested for regressions by Digium is used for linking (Asterisk links to it statically).

Is this allowed? I won't be able to do the packaging on company time because we have the above setup working quite well but am interested in following up on this project on my own time (i.e. not very hurriedly).

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

As is, Asterisk is completely broken in Xenial. A fresh install crashes within seconds of service start up. While I can't guarantee that tracking upstream would fix this particular problem, it stands a much higher chance of getting the attention of the Asterisk developers. Shipping an outdated and unmaintained version isn't doing anybody any favors.

On the other hand, I do understand that developer resources are limited. So, maybe, completely pulling the broken copy of Asterisk from Xenial is the only viable option at this point?

As a work-around for Ubuntu users, I found that moving Asterisk into an LXD container works pretty well. Obviously, I can't run Xenial in that container, as it would trigger the same problem. But Debian Jessie has a working copy of Asterisk at this time and that easily installs in a container.

Hi Earlybird,
I highly appreciate your suggestion to spent some time on that!

In regard to library bundling in general it is not a thing people like as it tends to let the security and maintenance overhead explode.
There is another way in case a library is only used by one single source.
This seems to be the case here.

$ grep Package debian/control | cut -d " " -f 2 > binaries
$ for i in $(cat binaries); do reverse-depends -l -b $i; done
asterisk
$ for i in $(cat binaries); do reverse-depends -l $i; done | sort | uniq | grep -v -f binaries
asterisk-modules

So bumping the library would not affect anybody but asterisk and since the need would be for asterisk that would be kind of ok.
@Rbasak would you have some better words on the possible next steps here?

@Gutsche - I expect you talk about bug 1458323 right?
If not I'd recommend you report a new one so that tracking and reproducing it is documented. Especially if Earlybird really find some time to refresh Asterisk (universe) in the LTS that might resolve all that it would be great to have a how-to-trigger and some logs available in that extra bug. Also there please could you check if it is resolved in Yakkety which has a far more modern asterisk?

gutschke said "As is, Asterisk is completely broken in Xenial". If this is true for all users of Xenial, in that no single Xenial user is successfully using current Asterisk packaging, then SRU policy tends to be fairly lax since there cannot be any risk to existing Asterisk users. So if this can be demonstrated, then the SRU team may be willing to accept an update to a newer version, such as an upstream LTS branch.

On the other hand, if there are Xenial users on Asterisk (for example if they applied a workaround), then we have to consider them and not regress them by bumping up major versions.

This consideration doesn't apply to the backports pocket. Users have to opt-in to receiving a package update from backports, as opposed to SRUs which are recommended to all users automatically.

In terms of required version bumps to dependencies, as Christian says if the packages exist solely for Asterisk then I think the SRU team will consider bumping them at the same time if bumping the version of Asterisk that requires them is acceptable. Another thing to consider is if users have any reason to use those dependencies outside Asterisk packaging (or for example if they are using those dependencies to build Asterisk from source locally). We don't want to break those users in an SRU either, but again a bump in backports is generally OK.

Making any update here will need someone committed to preparing one and taking care not to regress existing Ubuntu users by following our policies diligently. I welcome you to take this on though - it'd be great for the community to have this fixed.

It would be nice if someone could make a definitive statement on which path would be acceptable to fixing the current state of Asterisk on Ubuntu LTS - the backports page says that backports should not be used to fix bugs, but the comments here suggest that an SRU may not be possible if people have hacked around the existing bugs...

An SRU *to backport a new version* may not be acceptable if it risks breaking existing users. I hope the rationale for this policy is obvious. Unfortunately it's not possible to make a definitive statement unless someone does a technical assessment (which any suitably well-versed developer can do).

Is there a reason that the specific bug causing problems in Xenial cannot just be fixed on its own? That would probably be the easiest to drive unless there's some technical reason this is difficult.

A backport of a newer version that introduces new features is generally always acceptable in the backports pocket, as this is exactly what backports users have opted in to receiving. It doesn't matter if such an update also fixes bugs; that's to be expected.

> Is there a reason that the specific bug causing problems in Xenial cannot just be fixed on its own? That would probably be the easiest to drive unless there's some technical reason this is difficult.

Looking at the upstream report, it seems that the problem has been analysed and a simple SRU to fix it should be straightforward.

There's also bug 1458323, that I suspect is not properly fixed without moving to a later version, and updating pjsip, or a config hack to disable the offending module (which is the officially supported core SIP module).