Dear Maintainer,

The current libopus shipped on debian is not compiled with
the "--enable-custom-modes" configuration option.
opus/opus_custom.h is not included in the -dev package.

Netjack from jackaudio.org can use opus (instead of celt)
but requires the custom-mode feature for that. There may also
be other projects that currently rely on celt-custom that will
run into the same issue.

Please consider adding --enable-custom-modes to debian/rules.

TIA,
robin

PS. there is currently no way to query information about
availability of opus custom-modes using pkg-config. It requires
checking for opus/opus_custom.h or symbols in the .so.

Hi *,

Ron (debian maintainer of libopus - CCed via @bugs..) ping'ed me
yesterday to follow up on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686777

To recap:
  netjack2's + opus needs libopus with --custom-modes
  but libopus on debian does not provide custom modes.


When enabling custom modes in libopus, there's a (small, but still)
performance penalty that everyone will pay -> distribution package of
libopus don't usually have that enabled.

Currently jackd2 in debian is just depending on libopus-dev (and because
it has no custom-mode support, netjack is not compiled with opus support).

Adrian Knoth (debian jack maintainer) volunteered to embed the opus
source in jackd packages (if there's no other option).

@Adi does that offer still stand? Can we work this out?


There might be some other cases - e.g. embedded devices -- which would
also like to use custom-modes. Hence it's not 100% out of the question
that debian might package a libopus with custom modes - or provide a
drop-in-replacement (libopus-vanilla <= libopus-custom). But that is not
ideal..

The best option so far is to statically link netjack2 against libopus.

Other distributions may be affected as well, so we might as well address
that upstream and add libopus as git-submodule to the jack codebase (I
could do that).


Thoughts? Opinions? Volunteers?

ciao,
robin


-=-=-

As a reminder - the options for netjack+opus are

we chose (B).

see also "[Jack-Devel] Switch from CELT to Opus in JACK1/JACK2 sources"
September 2012

Quoting Robin Gareus (2013-06-29 17:59:21)

In my opinion the best option so far is for libopus to enable custom
modes: Primary aim in Debian is to enable most possible features - being
fastest possible has lower priority so can wait until done properly.

...and convenience code copies is explicitly discouraged in Policy, so
range far lower on the list!

That would obviously be most elegant if upstream could offer both
concurrently.


 - Jonas

Ron, what do you think about the following?

Instead of using embedded copies in jackd1/2, let's build two flavours
of OPUS from a single source package.

Just sketching now:

libopus0 will provide /usr/lib/libopus.so.0 (business as usual)
libopus-custom-0 will provide /usr/lib/libopus-custom.so.0

In addition, we'll keep libopus-dev and introduce libopus-custom-dev
containing the additional files and a dependency on libopus-custom-0.

All packages will be co-installable, since no file conflict will occur.

In jackd1/2, we'll build-depend on libopus-custom-dev and link against
libopus-custom instead of libopus.


It's certainly a bit of work on your side (building two binary sets from
the same source). OTOH, at least CDBS supports flavours out of the box,
we use it in ardour to build ardour (generic), ardour-i686 (SSE) and
ardour-altivec.


How does this sound to you?

Hi,

So the background (that's been missing from the BTS up until now) is
that shortly after Robin initially reported this bug, he also contacted
us upstream and we had a fairly detailed discussion on IRC about all the
various issues.  Since Debian was in freeze there wasn't much going to
happen with the package right then, and it wasn't clear at the end of
the discussion whether netjack was still going to use the custom modes
after all.

But it is time now to decide on this soon, so I got in touch with Robin
again yesterday to see what constraints we really have to work with.

My understanding of the background prior to that is that Robin had some
discussion with some of the developers at FOMS, who at the time suggested
the custom modes probably would be appropriate for the use described to
them.

The later discussion on IRC however (including the developers who were
at FOMS) was much less conclusive, and it wasn't at all clear after that,
that the need to do this outweighed the costs, both in general, and to
jack specifically.

The custom modes are not interoperable with anything else, nor are they
a part of the codec standard, but they do exist in the code for people
with very specialised needs in 'closed' applications, where the need for
oddball frame sizes strongly outweighs any other considerations of
interoperability, or codec performance (the latter being both in the
sense of processing resources *and* more importantly audio quality).


My understanding at present is that the primary (only?) reason that
netjack is using custom modes is so that it can use 64 sample frames
which shaves ~1ms of latency off the usual 2.5ms (120 sample) minimum
frame size for normal opus modes.  We didn't quite get to the bottom
of all of that before Robin had to leave, so at present my only
understanding of the reason for that is that "pro audio equipment"
can operate with lower latencies than normal sound cards which makes
this desirable.

What I still don't understand though is why if you are using Pro audio
equipment the degradation in audio quality that this would bring (which
is significant) would be acceptable for that use?  You'd need to stream
at much higher bitrates than normal to recover even some of that, and
even then there are many quality enhancements in the encoder that only
apply to the normal modes, which are completely bypassed in the custom
modes.  And even without those, quality will still suffer compared to
the more normal analysis frame sizes used by this codec, just by virtue
of the tiny window size.  Even 2.5ms frames have notably lower quality
than the default 20ms ones do.  Non-standard 1.3ms frames are at a
considerable disadvantage here for high fidelity reproduction.

The 'normal' latency of Opus is orders of magnitude lower than anything
which can even approach it for quality, but even it has both hands tied
behind its back when it only has 64 samples to work its magic on.

Which basically makes the question become: "If you are using Pro audio
equipment and ~1ms of latency does make a difference to you, then
wouldn't a lossless transport mode be more appropriate for that anyway?"


Which isn't exactly the original question that we need to answer here,
but it is relevant to that, since netjack is the only thing that I'm
aware of that's likely to want support for custom modes from the distro
packages.  So the question of whether it's actually gaining any real
benefit from this is the key to knowing whether we even need to consider
supporting custom modes in the distro in the foreseeable future.

The upstream developers have reaffirmed that they definitely do not
want to enable the custom modes by default in what they release, so
even if we do override that here for the .debs, there'll still be a
question of our compatibility with other distros and users.


Re Jonas's remarks:

I concur with this, which is why I revisited the question of whether
we would even need to with Robin.  And the other upstream developers
agree that should we really need to, enabling this for the packages
is probably the preferred option (unless we really can think of some
better way instead).

There isn't really a "wait until done properly" about this though,
the penalties are largely inherent in the extra complexity this adds.

Part of the catch here is that while enabling this will not break
ABI, disabling it again will, so this is very much a one-way decision
which I'd like to not make until we are certain there will be no
turning back from it, or second thoughts, or regrets over mistakes
that could be remedied now in better ways instead.

We discussed this option upstream to try and find a solution that might
work like this, but it's not simple.  Mainly because the custom modes
are not a simple superset of the normal builds.  They add some API
functions, but it also changes the behaviour of some existing functions.

The big problem with this is that both of those will provide all of
the functions that libopus.so.0 does, only some of the symbols with
the same names will have different implementations in the -custom one.

Which means that when jack links to -custom, and jill links to -vanilla,
and then some high level audio app or desktop environment or whatever
links to both jack and jill ...   hilarity is likely to ensue.

There can be no file conflict, but there will be symbol conflicts.

I'm not worried about the work (it's not much), or being able to package
multiple flavours (I've done this before for various things too).

Mostly I'm worried that we don't make a decision that could later blow up
in our faces and/or be very difficult to unwind, for reasons that turn out
to never have been warranted at all.  And that we will be 'forking' away
incompatibly for other distros, at least for a while if not forever.

So right now I'm basically interested in 2 questions:

 - Can jack really make a case for needing this in a way that actually
   delivers real benefits to jack users.  (Robin has said that this is
   also 'complicated', but I still don't fully understand why yet).
   Or would it be better off only using Opus in cases where 2.5ms of
   latency is acceptable (or even more where quality is more important
   than the lowest possible latency) - and providing lossless transport
   where extreme low latency is required (which I know it already does).

 - And if the answer to the above is yes, the custom modes really are a
   clear advantage for some particular use case, what the least worst way
   to do that in the distro may be.


Good answers to all of my uncertainties above are most welcome :)
I would like to resolve this fairly quickly once we are all sure we
have a firm grip on the relevant facts and do actually know the best
result to be aiming for here.


  Thanks!
  Ron

correct. derf aka Tim Terriberry in this case.

[..]

jack in particular was one of the use-cases for opus-devs to justify
custom modes.

not quite.

netjack is using opus custom modes so that jack can use the same
period-size across the complete jack system.

Adding buffering on either side (sender + receiver) to align jack + opus
buffers will always result in additional latency.

For large jack buffersizes or long-distance communication that
additional latency may be negligible, but it still is more latency.

Furthermore, aligning non-audio jack-data (transport + MIDI) with sample
accuracy to those opus-audio-buffers is far from trivial.

It's not impossible, but it is quite complex because jack is not
designed to cater for that case.

a) because some users demand it :)
b) because celt is no longer available on most distros

low, fixed latency is most important.

There are countless solutions for high-quality streaming - where latency
and jitter is irrelevant, but basically only netjack that provides
synchroneous low latency.

[..]

on a LAN, yes lossless. Over Wifi it may make sense to compress lossy to
accommodate more channels. On WAN there are e.g. remote jam-sessions,
phone relays, live monitoring,.. - none of which requires high quality,
but all require fixed low latency.

[..]

yes, the solution for that would be to add opus as git-submodule to jack
and statically link netjack against it. That'd also accommodate windows,
OSX and *BSD builds of jackd.

[..]
Asynchronous (buffered) communication is orthogonal to everything else
in jack. It will likely be rejected upstream. jack does not aim to do
everything. JACK tries to address 95% and do that right and not care
about the last 5% edge-cases.

On top of of that, there are currently no volunteers to implement
"vanilla opus" on netjack2 (and also no volunteer to implement that in
netjack1). I was scratching my own itch with netjack2+opus. works for me.

The only case for non-custom modes would be:
 1) interoperability with other opus apps
 2) higher quality encoding

(1) is never going to work out. netjack consists of N audio-channels, M
midi-channels. Both include per-port latencies (min,max). And netjack
also comprises transport information (timecode, tempo, bar-beat-tick,
audio-frames per video-frame, etc). It is not a data stream that will be
consumed by non-jack.

(2) if a user chooses lossy encoding s/he does not really care about
quality anyway. jack's main features is no-copy zero-latency with local
clients, being able to include remote clients on the network that align
sample-sync and respond reliably is the main use-case.


ciao,
robin

On 06/30/2013 03:11 AM, Ron wrote:

Hi!

I'll limit my response to the aspect of symbols, since Robin has already
answered the other questions.
really a PITA to diagnose.

But here it seems to be very unlikely: only the jack server links
against libopus(-custom), and this server is a standalone binary that's
not linking or linked to anything else.

All the clients link against libjack, and even if they do link against
libopus, they're not interfering with the server's libopus-custom, since
client-server communication is done via /dev/shm.

So I think we can ignore the symbol aspect for all practical cases.
(Correct me if I'm wrong).



Cheers

Right, and it was Tim who ran through the math in the IRC discussion to
point out that this might not have been the best suggestion after all.

Greg was probably the one who most often raised oddball cases that might
use this, but even he was now scratching his head somewhat at what you
are actually trying to achieve with using it for netjack as you are.

Which is why I wanted to try to get to the bottom of your rationale here.

What gets to pick the period here?  Even custom modes still limit you to
some discrete number of choices, it isn't continuously variable, so there
will surely still be cases where some part of the system needs to adapt
to suit other parts if this is to be true, won't there?

You realise that we are talking about a latency that is equivalent to
moving your head approximately 15 inches from your speakers, right?

Or in the case of a 'jam session', two players standing about a foot
from each other ...  with their instruments held a foot from each
others chins.  If they are any further apart than that, in the same
room, then the latency difference that you are worrying over here
becomes insignificant by comparison.

If they stand a guitar length apart and put headphones on, even the
normal mode of opus will get the sound to their ears faster than the
air between them would.

It doesn't take large buffer sizes or long distances to make this
negligible.  We're not talking coarse yak hairs here, it's the finest
angora.

Elastic stores really are trivial.  So I'm still not really sure what
showstopper complexity you are worried about there.

What exactly are users demanding here?  They surely aren't demanding that
members of the band stand on each others toes and play their guitars with
their teeth.  If they want to use oxygen free copper that's fine, but what
_real_ gain are they demanding to get here?  That's the important question
we need to answer.

It arguably should have never been available on them in the first place :)
But that was a learning experience for us too!

You can still have low latency with standard opus modes.  If you take one
small step toward your speaker it can even be lower than the custom mode
you are currently using :)

On WIFI it's pointless to talk about even the highest latency modes of
opus being a problem.  The potential (and common) latencies there are
orders of magnitude larger.

And these are all _exactly_ the applications that the normal modes of
opus were specifically designed for.  They are point 1. of the chartered
objectives for the standardisation work that took place.

Until someone links an application to both jack and another lib using the
normal opus builds.  At which point kaboom?

Doing this correctly and safely really isn't easier than a simple elastic
store that lets you adapt any frame size to any other.  Or than just
picking 2.5ms as your minimum latency for lossy modes.

Is is, really.  You can write a trivial wrapper around the normal opus
I/O methods iff you really need to adapt to something < 2.5ms.  But it's
still not clear what less than 2.5ms gains you except poorer audio and
higher bitrates.

An elastic store does not make this asynchronous.

Well, there's currently no volunteers to make building with the custom
modes sane and compatible between distros either.  And I'm pretty sure
that fixing netjack would be easier than that.

Scratching your own itch is fine, but we're talking here about what is
suitable for a distro release.  And one way or another, what you've
currently got is going to need some work to be suitable for that.

And it's also not incompatible with using an elastic store.  I'd be kind
of surprised if at least some parts of this chain don't already have one,
whether that is in your code or not.

You can't have either of no-copy or zero-latency if you're going through
a windowed codec as your transport stream.  Laws of physics and all that.
You can still however care about quality.  Opus at just ~128kbs is pretty
much transparent for all but the hardest audio, to even the best of ears.
But not with 1.3ms packets.  If a user cares about lossy, then they have
more to gain from the bitrate improvement which would come with this than
from an imperceptible change in the latency.

All the ideals you have here are wonderful, and I don't want to discourage
you from them, or limit you in any real way from achieving them to the
closest degree that you can.

But I am asking you to do the (fairly simple) math to quantify the _actual_
gains which people might see, and explain how they justify the extra work,
complexity, and potential for real problems that they will cost.


If all you're left with at the end of that is "this was easier to port
from what we did for celt", then that really is the bug we should be fixing
and it really shouldn't be hard to fix it, or nearly as ugly as any of the
alternatives that I'm seeing so far, once everything is added up.


I'm not taking any options off the table here yet, but the more we talk
about this, the less I see what tangible advantage the custom modes are
really giving you here.  They really are meant only for the most oddball
of exceptions, and what you're doing here really isn't that sort of odd.
At least from what I'm able to understand from your descriptions so far.

I'm willing to accept I'm missing something here still, but I'd like to
know what it is before we open a can of worms we can't close, only to
find out that we really never needed to at all.


  Cheers,
  Ron

Where does libjacknet.so.0.1.0 fit into all of that?

I don't think we can guarantee that for the forever future something
using the custom modified symbols would be compatible with the normal
builds.  Optimisation work is really only just beginning, and there
are quite a few places where the normal code might diverge in newly
incompatible ways from what is possible when custom is enabled, and
where a symbol collision could be even worse than it is at present.

This could turn into a snowball of ugly pretty easily I fear ...

Which is why I'm really keen to be sure we're not going down this
path for something so tiny that nobody will ever be able to hear it.

  Cheers,
  Ron

On 07/01/2013 05:59 PM, Ron wrote:
[..]

Sample accurate alignment of buffered netjack streams with the rest of
jack. updating port-latencies,.. Sounds easy, but it's not.

The realshowstopper there is lack of manpower.
No one volunteered to implement it.

ciao,
robin

You do know that you've _already_ got to deal with this if you care about
it when using Opus right?  The first few samples out of the decoder aren't
the first few samples that you put into the encoder, whatever mode you use.

And yeah, I'm not saying it's a one-liner, but it's not squaring the circle
either, it is a fairly normal part of anything dealing with windowed codecs.

Ok, that's fine.  There are no answers here that don't involve work that
still needs to be done, which hasn't been done yet and that someone will
need to do if they want this to happen.

There's still no answer to a sensible way to distribute -custom builds
in a shared environment yet either.  Upstream is very much focussed on
just the standardised modes, and custom is still a hack, that people
with total control over a closed system can use if they really need it,
and if they are prepared to deal with taking full responsibility for
anything that may get broken with it (or be completely untested) over
subsequent releases.  That's not really a state of affairs that we want
if we're going to expose it in general purpose distro libraries (either
from the libopus package or embedded in other public libs).  Sooner or
later some change will bite people badly.  So this needs to be resolved
if there ever is anything that's to go in the distro that uses them.
But while there isn't, it can also wait until more urgent things are
completed too, and everything just settles down a bit in general and
stops changing as rapidly as it currently is.

What I'm concerned about here is that we figure out what the _best_
answer is, so that when someone does have time to do it, they don't
waste it chasing up the wrong tree.

Right now, it really is sounding like the best answer for what we have
at present is for someone to look at the jack code and do the work that
is needed there, to account for the initial padding and window latency.
If that's the real showstopper, that's what people should focus on
fixing first.

I'm still open to suggestions for good ways to manage the how we might
enable custom problem, but that seems orthogonal to also fixing jack
in the way that will work with best results there, and less pressing
until there is a definite need for it.

  Cheers,
  Ron

Ron <ron@debian.org> wrote:

debian bug reports seems to lack a "this affects me too" link. I found the
above disheartening. Every person who uses jackd has had a broken package
since opus showed up and Celt was removed. In my opinion opus is broken
for not using a boundary based on binary that the whole computing world
uses. However, the standard has been set and we have to work with it. The
way to work with it is to allow an opus library that allows non-standard
usage. Low latency means different things to different people... for the
MP3 crowd opus is really low latency... for people using it for
performance it is just barely in the ball game. Adding buffering kills it
for that use (one of opus advertised uses I might add). Really, the jackd
developers know what they are talking about in this area, very few other
people, including those of us who use it, do. I know from experience what
it means, but the programing is beyond me... the last real time, low
latency, project I did was a hardware midi filter where I just had to deal
with one byte before the next arrived.

either jackd has to include a fixed version of opus inside. (which means
any other project with the same needs has to repeat the same work... what
happened to the reusable concept?)

or the shipped opus handles it... everyone wins.

normally the newcomer is fixed not the software that has been here for
years. To get the performance using opus as is, it seems to me every
application that uses jackd would need to be updated to use odd frame
sizes. However, just as with every other software area, there are a number
of jackd applications that while in daily use, are not maintained. We
would loose those as well.

So here I am waiting for opus in jackd. This bug affects me too. This
could be a fantastic tool for Broadcast Remote Content Transport. The only
tools available now are all sip client to pulse to jack with the very
noticeable delay that chain gives.

Hi there.

so, this still seems to be an open problem. lets find some sort of workaround.
or at the very least deduplicate the effort of getting a locally working
jack-opus...

as it seems to be better to not pullute the shared libraries with custom
variants (no way back etc.), i think (until upstream has a better
solution), libopus-dev should just provide an additional static library
including the custom stuff. i.e. build the library twice.

here [1] is a working package (in the custom branch). with the contained
library libopus-custom.a, you can then build an opus enabled jack e.g.
from the opus branch in [2]. without further work, this will lead to
wrong/ambiguous opus symbols in shared objects using the custom libopus.
so its not ready for a release.

$ readelf -s /usr/lib/x86_64-linux-gnu/libjackserver.so.0 |grep opus
   391: 00000000000a0d00     5 FUNC    GLOBAL DEFAULT   11 opus_custom_encoder_destr
   491: 00000000000aa2f0  2068 FUNC    GLOBAL DEFAULT   11 opus_custom_mode_create
   521: 00000000000a8bc0   185 FUNC    GLOBAL DEFAULT   11 opus_custom_decode
   564: 00000000000a6450   100 FUNC    GLOBAL DEFAULT   11 opus_custom_encoder_creat
   577: 00000000000a6440     7 FUNC    GLOBAL DEFAULT   11 opus_custom_encoder_init
   801: 00000000000a5e90  1226 FUNC    GLOBAL DEFAULT   11 opus_custom_encoder_ctl
   820: 00000000000a8f60   151 FUNC    GLOBAL DEFAULT   11 opus_custom_decoder_init
   823: 00000000000a7510     5 FUNC    GLOBAL DEFAULT   11 opus_custom_decoder_destr
   840: 00000000000b2e90     8 FUNC    GLOBAL DEFAULT   11 opus_get_version_string    <=
   876: 00000000000a9000   100 FUNC    GLOBAL DEFAULT   11 opus_custom_decoder_creat
  1111: 00000000000a5e80     8 FUNC    GLOBAL DEFAULT   11 opus_custom_encode_float
  1338: 00000000000a8bb0     8 FUNC    GLOBAL DEFAULT   11 opus_custom_decode_float
  1340: 00000000000b2e60    33 FUNC    GLOBAL DEFAULT   11 opus_strerror              <=
  1418: 00000000000a5e10   108 FUNC    GLOBAL DEFAULT   11 opus_custom_encode
  1536: 00000000000aa270   114 FUNC    GLOBAL DEFAULT   11 opus_custom_mode_destroy
  1853: 00000000000a8c80   730 FUNC    GLOBAL DEFAULT   11 opus_custom_decoder_ctl
  2031: 00000000000a74d0    25 FUNC    GLOBAL DEFAULT   11 opus_custom_decoder_get_s
  2420: 00000000000a0cb0    37 FUNC    GLOBAL DEFAULT   11 opus_custom_encoder_get_s

rather than reinventing opus or even jack and the others, my suggestion
is to rename the non-custom symbols in the custom library before
packaging. the package then will probably be debian specific and will
still contain duplicate object code/symbols for the sake of 1ms. but in
my understanding shipping a static library is revertible enough to give
it a try.

thanks
felix

[1] git://tool.em.cs.uni-frankfurt.de/git/opus
[2] git://tool.em.cs.uni-frankfurt.de/git/jackd2

Hi.  Is there any hope to solve the jack/opus issue?  Been a while
since the BTS report saw any update.

Well, my understanding from the conversations here and on IRC with
the Jack folk was that they misunderstood why they needed custom
modes in the first place, and their application doesn't really
need them at all (and no other user for custom modes like this
has since come up either).

So the "summary status" at this point is probably best described
here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686777#50

  Cheers,
  Ron

I’m currently working on packaging Jamulus, and it needs custom modes
to function at all (that, or embedding a convenience copy of opus,
which is not the Debian way to do things).

Please reconsider. In the meanwhile, I might upload to experimental
with the embedded copy, but that will not make it into a release,
whose freeze approaches… half a year I think.

Hello,

Bug #686777 in opus reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/multimedia-team/opus/-/commit/a75e83c79b87775f3f9c42b3e320a1291319853c
------------------------------------------------------------------------
Enable custom-modes

Closes: #686777
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/686777

We believe that the bug you reported is fixed in the latest version of
opus, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 686777@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
IOhannes m zmölnig (Debian/GNU) <umlaeute@debian.org> (supplier of updated opus package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 18 Jun 2022 16:56:23 +0200
Source: opus
Architecture: source
Version: 1.3.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintainers <debian-multimedia@lists.debian.org>
Changed-By: IOhannes m zmölnig (Debian/GNU) <umlaeute@debian.org>
Closes: 686777 1007034
Changes:
 opus (1.3.1-2) unstable; urgency=medium
 .
   * Enable custom-modes (Closes: #686777)
   * Add patch to fix spelling mistakes
   * Drop libopus-dbg in favour of auto-generated dbgsym packages
   * Longer extended description for libopus-doc
   * Update packaging to use short-form dh
     - Add depends on ${misc:Depends}
   * Add autopkgtest
   * Declare that building this package does not require 'root' powers.
   * Declare that .la-files are not installed
   * Declarative file and manpage installation
   * Fix installation path for doc-base files
   * Add B-D stanza to .symbols file
   * d/copyright
     - Machine-readable d/copyright
     - Add licensecheck target to d/rules
     - Generate d/copyright_hints
   * Remove trailing whitespace in debian/* files
   * Add watch-file
   * Add salsa-ci configuration
   * DEP14: use standard branch names
   * Switch to source format 3.0 (Closes: #1007034)
   * Bump dh-version to 13
     - via debhelper-compat pseudo B-D
   * Bump standards version to 4.6.1
Checksums-Sha1:
 bb6849f95bc08bbcc7d59cac006ac3df0c518a3b 2295 opus_1.3.1-2.dsc
 279fdac4d47929e24ca1313132a58b66f4247659 108140 opus_1.3.1-2.debian.tar.xz
Checksums-Sha256:
 5423068cfefdfc95ea14a68b9c6e8ca154164e3605b794762ca2fe3d3596abc8 2295 opus_1.3.1-2.dsc
 bf3c24889707fe29c3ef24dd5dc137a3e8df1d3445ecde9cf416ae92008bd722 108140 opus_1.3.1-2.debian.tar.xz
Files:
 53cd8ea9b5b15373014944f13a289370 2295 sound optional opus_1.3.1-2.dsc
 f042ee43f6b033b5a10d8048cee97191 108140 sound optional opus_1.3.1-2.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQJKBAEBCAA0FiEEdAXnRVdICXNIABVttlAZxH96NvgFAmKt6LkWHGZvcnVtQHVt
bGFldXRlLm11ci5hdAAKCRC2UBnEf3o2+N7PD/9z7VNvV1It9Uk8xl+pcd5+EoK0
kzwmT0GqegwIQC6RHbaBAngnYwHf+MURrfyoDrfLEZW+Er7ZoSimGzWrneJ5hmzc
rSSa7lcqj8dNyaKZIHOx+EoDLqcAvNneRWBz5gHfv9UWyjFyOiYyTt0o8gDJaeFg
asvUt67MNzVsBD85m5ruKcHdTU9c4KuEj4/lJV4wlv3Y0DSBn1VgADjtFmu1pCdg
+M7j0zg6iILzDhMJuGrjxy3XjElcVzOKqaTQyt04pi2bOJhlg+sss7zjdfikGhgR
iH7wljYJP4XgHANUjRZGUIbsvYlApPoOSJkHHdO1LYMAGXHnN4PR3asBCKQqimu3
5hYGhwkWHEJEdu5iiOH0M3hjj0wV1CFc7ZN/r9MH0JBLuMF2jjsrzpOjyCguwYKp
bPu5k8TbUvVVHNVhdIt06SIo1nDk2ZmAt24JfPmt/dIREBpU96xiKP1iyjTmb704
HZ78NWLhs4g9ptuBCsq3C8h01uKiO+ERLwSvep1hqGWrf7bgK2WMq97ipjKSZuWW
K9Rq6D4ZcoL5thMcsWqnlZJQSvGesd6yZv4eA914gPB5rHLCwMqrp/a/X6Fo1piy
BWBLAlUmaGfG3VrlRFwGAXKbJ2U9pD7hoWjCokfq/j5Z+7Iei6FiflzBzHXnc3hQ
aSG6YodGggSHfTT6Qw==
=wHTS
-----END PGP SIGNATURE-----