[needs-packaging] Mumble

I also think it would be good to have this appear somewhat soon, can it also be backported to feisty while at it?

Working with upstream to clean up package...

Thanks,
Justin M. Wray

---------- Forwarded message ----------
From: SourceForge.net <email address hidden>
Date: Aug 24, 2007 11:20 AM
Subject: [ mumble-Bugs-1781152 ] Release Cleanup (debain/)
To: <email address hidden>

Bugs item #1781152, was opened at 2007-08-24 15:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=768005&aid=1781152&group_id=147372

Please note that this message will contain a full copy of the comment
thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Mumble
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Justin M. Wray (Ubuntu) (wrayubuntu)
Assigned to: Nobody/Anonymous (nobody)
Summary: Release Cleanup (debain/)

Initial Comment:
Hello, I am attempting to package Mumble for inclusion in the upcoming
Ubuntu release (Gutsy Gibbon -- out sometime in October).

However, Ubuntu (and Debian which would also benefit from this packaging)
follow strict packaging rules, one of which being the debian/ directory
cannot be found in the upstream tarball.

i am posting this bug in hopes that a new tarball can be released which does
not contain the debain/ directory.

I look forward to working with you further to help supply this application
to the Ubuntu and Debian based communities.

Thanks,
Justin M. Wray

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=768005&aid=1781152&group_id=147372

Justin,

you should check this page to undestand what bug status is:

https://wiki.ubuntu.com/Bugs/Status

I'm changing back to In Progress.

Being the "upstream", is there anything I can do to help this along?

Hi Torvald,

Thanks indeed for your interest. There is a number of points that I had asked Justin to forward to you. Let me paste them here in case you haven't got them (in no particular order):

1) The upstream tarball must not contain a debian directory, upstream should exclude it in their dist target.

2) The .desktop file doesn't validate, and should be corrected as follow:

- the "Encoding" key is deprecated.
- a semicolon should be added as trailing character in the "Categories" key.
- the Icon entry should not use an extension

3) Copyright/License

Your LICENSE quote Copyright (C) 2005-2007, Thorvald Natvig <email address hidden>, but some of the included
source files seem to be copyrighted far before this date. There seem also to be some other copyrighters:

        Xiph.org Foundation
        Jean-Marc Valin
        David Rowe
        EpicGames
        Analog Devices
        Commonwealth Scientific and Industrial Research Organisation (CSIRO)
        Mark Borgerding
        Jutta Degener and Carsten Bormann
        Christopher Montgomery

The files bits.c (File: speex_bits.c) and jitter.c (File: speex_jitter.h) headers should be corrected.

speex/libspeex/kiss_fft.h doesn't have a copyright notice.

mallfft.c, speex_types.h and smallfft.h are not licensed through a BSD license.

4) I have seen some .ts files which seems to provide translation of the program in some languages. They don't seem to be installed though; is this is done on purpose?

As I said in the sourceforge bug report, I was under the impression that tarballs with a embedded "debian/" dir were considered "native" packages? Or is that reserved for packages that exist only on debian and nowhere else?

I can fix the desktop file. Alternately if you have a patch I can apply that.

The speex/ directory is a snapshot of libspeex SVN (http://www.speex.org), and I'm not a Speex developer. That directory does contain the COPYING file from the original Speex distribution.

The .ts files are "compiled" into .qm files through Qt linguist tools, and these .qm files are embedded in the binary. This is done as part of the build process.

Thanks for the clarifications Thorvald:

1) Native Debian packages are packages which have been written especially for Debian (or Ubuntu in our case), which is not the case for Mumble. To give you an example, if you are familiar with Ubuntu, update-manager is a native debian package.

2) Patch is attached.

3) Note that libspeex is a common library. For instance we already have it (1.1.12-3) in our repositories, and it would make sense for us to use it instead of replicating a local copy just for mumble. The best would be to have an upstream tarball that DO NOT include this library, and we can just make sure that it is specified as a Build-Depends and Depends.

4) Thanks for the clarification. I'm not familiar with this tool myself, but if you tell me that your makefile take care of it I'm happy. Is there anything that we have to do from our end to make sure the right process is enforced?

1) Ubuntu is my main Linux distro at the moment, and our primary (and only) disitribution for binary packages for Mumble, so yes, I'm familar with Ubuntu :) I'd be interested in keeping the debian/ stuff (possibly integrating whatever changes you make the "official" package) in the SVN tree so we can easily make packages available whenever a new major version is released. I can remove it from the tarball though.

2) Thanks for the patch :) Applied to current SVN.

3) The problem with libspeex is that some of the advanced functionality (like the preprocessor and jitter buffer) have a very unstable API, and there is no easy way to check the currently installed version at compile time as it's not included in the header files. We'd have to use pkg-config and create some defines based on that. This problem stems from the fact that the current "stable" Speex version is 1.0.5, which is too old to have any of the functionality we need. What Ubuntu (and debian) is currently shipping is a development version in which the API is expected to change. You've picked the September 2006 snapshot. I've picked the August 2007 snapshot, and there are major API incompabilities. We tried supporting 1.1.11 and 1.1.12 through #ifdefs for one of our 0.9.x releases, and it really didn't work out at all. Things will hopefully be better once a final 1.2 version is released with a stable API.

4) No, mumble and murmur should build through a standard qmake-qt4/make pair. The current rules file should cover everything needed.

Of course you are free to have a /debian in your tree. As long as its excluded once you make dist (or whatever you use to make your tarball) thats fine.
I'm personally not very happy to ship an extra copy of libspeex just for the purpose of your package.
I discussed with some developers and they are of the opinion that we shouldn't use the bundled one if at all possible.

1) We want to minimise the number of live copies of libraries in the archive.
2) Since our resources for Universe are limited, remaining synced with Debian's source versions poses less of a risk, generally, than bundling our own.
3) Since speex is a main source package (with several rdepends), our opinion is that we should not bundle further updates of our (Ubuntu) own in this dev cycle.
4) We think it would be very unwise to bundle a snapshot in the 8.04 dev cycle (its LTS for us). We should act as if binary packages will only be installed once and not updated via any mechanism. Will the program using the libspeex snapshot be stable and useful for 18 months?

In the meantime perhaps it makes sense for you to investigate if and when the "stable" release will be available, since its in beta2 already.

Actually, the library is just used when building; it's embedded in the binary as a static library and is not in any way exported to the rest of userspace. It is completely internal to Mumble.

You're already bundling a snapshot; speex 1.1.12 is a development snapshot, it is not a "stable release". The current 1.2beta2 contains no new major features beyond what 1.1.12 does, but it does contain a number of bugfixes and a few API changes. There are features in 1.1.12 which break horribly, but they work in 1.2beta2. So in all regards 1.2beta2 is a more "stable release" than 1.1.12 is. If you go to the Speex homepage, you'll see that 1.0.5 is the stable release, and the current "unstable" release (which is recommended over the stable one) is 1.2beta2. What we are including in Mumble is 1.2beta2 + bugfixes. Without the 1.5 years of bugfixing that's happened since 1.1.12, some of the central functionality in Mumble will have to be disabled. So it's not really possible to use 1.1.12 with Mumble.

So, yes, using the current snapshot release will be much more stable and useful than using an older snapshot release.

I'm not sure when the 1.2.0 release will happen. It seems it will appear "when it's ready", and I have no control or influence over this.

About the "18 months"; The 1.0 (current release) and 1.1.x (SVN) branches of mumble are protocol incompatible. 1.0 uses a unencrypted protocol while 1.1 uses SSL sockets. Support for SSL in Qt requires Qt 4.3. Qt 4.3 requires Gutsy, so it was our plan to release Mumble 1.1.0 a day or so after the Gutsy release. If you're looking at the 8.04 dev cycle already, I'd strongly recommend waiting and using the 1.1 branch there, because 1.0 will be obsolete on October 18th ;)

Its too late for gutsy anyhow, the NPF was on Agust the 30th. If the package was to be ready before beta freeze we could have asked an exception but I doubt this can be done.
In any case, what was the point of proposing 1.0 for gutsy if 1.0 will be obsolete by the time gutsy is out? It would have been better indeed to have 1.1 and be working on that.

As things are now, we should be working on a package for Hardy and review the situation in few months time. If we have libspeex 1.2beta2 by then (its in debian experimental now) or even better 1.2 we can revise the package and use, if possible, the repository package.

Justin, what are your plans on this? You wanted to do this, but I haven't seen much interest from your side.

Sorry for the delay in my response, extended holiday this past weekend.

>Justin, what are your plans on this? You wanted to do this, but I haven't seen much interest from your side.

Cesare, I am absolutely interested in packaging the next released version mumble for Hardy. Unfortunitally working on other packages, delayed my attention on this one. Either way, we no have plenty of time to work out issues with other packages such as 'speex' and fix upstream issues like the debian/ directory.

>About the "18 months"; The 1.0 (current release) and 1.1.x (SVN) branches of mumble are protocol incompatible. 1.0 uses a unencrypted protocol while 1.1 uses SSL sockets. Support for SSL in Qt requires Qt 4.3. Qt 4.3 requires Gutsy, so it was our plan to release Mumble 1.1.0 a day or so after the Gutsy release. If you're looking at the 8.04 dev cycle already, I'd strongly recommend waiting and using the 1.1 branch there, because 1.0 will be obsolete on October 18th ;)

This obviously gears a release towards a Hardy release anyway. I think once the timeline is published we should work on a stable (updated) release for inclusion, knowing the date of the NPF will give us a solid target.

Keep in mind though that Hardy is supposed to be a "LTS" and therefore we should really ensure that this is a stable package, and not bleeding edge.

Thanks,
Justin M. Wray

1.1.0 is out the door with our homebuilt .deb packages for gutsy. There's a lot of new functionality in there, so there's likely a few bugs as well. So a 1.1.1 and 1.1.2 is probably expected "sometime in the not-too-distant future".

However, the binary protocol, build system and dependencies are stable for the 1.1.x series. This means we can start creating proper .deb packages right away :) And when I say "we", I mean "you", because my attempts are apparantly in the "crude but functional" department.

So, I'd love to see a proper ubuntu patch sometime soon, and with your permission I'd like to add that to our SVN tree so we can use exactly the same build system for our own releases.

I have a small list of things that I know should probably be in the ubuntu package but currently isn't. Where would be an appropriate place to discuss such things? Here?

It depends on how you want to proceed.
If you want to make the package yourself, then the best would be to upload your package to REVU, and we will assist you there:

https://wiki.ubuntu.com/MOTU/Packages/REVU

If you want to have leave your package to Justin, just coordinate with him, for instance through this bug report.

I'd be more than happy if Justin does the official packaging, providing he still has time?

Thorvald Natvig, Justin M. Wray:

What is current state of debian/ubuntu packaging ?

Can you provide an url with the work in progress ?

I'm not that a packaging expert, but I can help you if there is specific things that needs to be done.

Thorvald,

I have assigned Johan to this.
Its his first complete package but I'm backing him up fully. Please coordinate with him and I'm sure we will have a very good mumble package in hardy soon.

All right.

The current work in progress is the current Mumble SVN from sourceforge (See http://mumble.sf.net for links). That contains the debian/ directory I used to build the binaries we have on sourceforge. At Justin's request, the debian/ dir has been removed from the tarballs as I understood this is more in line with current philosophy?

Anyway.

The current things missing from the package are:

- Fixing of Ubuntu bug https://bugs.launchpad.net/bugs/155784 . The Qt supplied with hardy does dlopen() on "libssl.so", which doesn't exist. The bug is currently marked invalid, but it's a showstopper for any application using the new features in Qt4.3.
- The mumble binary handles the mumble:// URLs. The package needs to register 'mumble' as a protocol handled by the mumble binary both for Gnome, KDE and whatever other programs are necesarry. I'm not really sure how to do this globally in a clean way, but I suppose the freedesktop people have a good solution.
- Both mumble and murmurd are missing man pages. This has been on my own "todo" list for quite some time, but the only place it's needed is to get lintian to stop complaining. If I provide a man page which says "please see murmurd -h", will that suffice? Experience has taught me that multiple documentation documents usually mean all but one are outdated, and we already have the -h output and the README.
- A user for murmurd. While I've done my best to avoid any security problems and follow good security practices, and we have also passed static code analysis from Klocwork, I utterly and strongly discourage running it as root.
- Registration of Dbus permissions for murmurd (See http://mumble.sourceforge.net/DBus - the /etc/dbus-1/... stuff needs to be added to the package)
- A murmur.ini file customized to a system-wide installation. Hm. I guess it makes sense to store murmur.ini itself in /etc somewhere, and the default log should be in /var/log and the database should be.. somewhere in /var?
- A init.d script suitable for Ubuntu (which passes the -ini /etc/murmur.ini parameter as well)
- The murmur.pl and weblist.pl scripts are actually CGI scripts. It is probably very beneficial if these get automatically installed as cgi scripts runnable by apache, and also installed in such a way that at least murmur.pl has correct permissions for the SQLite database. I forgot to add weblist.pl to the 1.1.0 tarball so you'll have to pull that from SVN for now.

As you can see the list is quite long :( I have had plans to fix all of these, but with limited time and the choice between fixing crashbugs and packaging details, crashbugs have to take priority.

However, if you can fix the above I will be very happy. If you also grant me permission to check the resulting build files into SVN so we can use them for our sourceforge releases, I will be even happier :)

Hi,

I've build the package from svn trunk on:
http://mumble.aminche.com/

Just as you reported it, lintian outputed the following error/warning:
http://mumble.aminche.com/lintian.out

I've installed a murmurd server on:
mumble://mumble.aminche.com:64738/

murmul.pl cgi can be accessed from:
http://mumble.aminche.com/cgi-bin/murmur.pl

Steps of setuping can be followed via:
http://hg.mumble.aminche.com/

The items I thought about addressing first are (because they are easy
and all about packaging):
- Create init.d script (will help with the path issue below)
- Move murmur.ini to /etc/murmur (nb: I didn't manage to locate it
after running the server)
- Move murmur.sqlite to /var/lib/murmur (currently it shows up in /usr/bin)
- Move murmur.log to /var/log/ (currently it shows up in the current directory)
- Move murmur.pid to /var/run/ (currently it shows up in the current directory)
- Move the .pl in /usr/lib/cgi-bin (there is also some perl dependency missing)

What do you (two) think ?

Murmurd searches around a bit for a .ini file. If it can't find one, it goes with it's builtin defaults. There's a sample one distributed in the scripts/ directory.

If you put that file into /etc, you can set the logpath, database path, pidpath etc from that file.

The current murmur.pl script needs an absolute path to the database. It also needs write access to the database file and to the directory the database file resides in (it needs to create transaction logs). Does Ubuntu's apache ship with suexec or do you have suidperl available?

> The items I thought about addressing first are (because they are easy
> and all about packaging):

> What do you (two) think ?

First of all, I would like to see the package in revu:

https://wiki.ubuntu.com/UbuntuDevelopment#NewPackages
https://wiki.ubuntu.com/MOTU/Packages/REVU

So that we can use it to coordinate our efforts. The only thing I would like
to ask you is to keep to a minimum the number of upload so that we can track
all the changes in an easy and coordinated way.

> - Create init.d script (will help with the path issue below)

Concerning the daemon initialisation, you should refer to the debian policy:

http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit
http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.4

The scripts in /etc/init.d should be good examples of how to write the init
script.

The dmraid package should give you an idea how to install and start it
(basically, its just a question of installing the script in /etc/init.d and
registering it with update-rc.d during postinst, which is done calling the
dh_installinit debhelper)

> - Move murmur.ini to /etc/murmur (nb: I didn't manage to locate it
> after running the server)
> - Move murmur.sqlite to /var/lib/murmur (currently it shows up in /usr/bin)
> - Move murmur.log to /var/log/ (currently it shows up in the current
> directory) - Move murmur.pid to /var/run/ (currently it shows up in the
> current directory) - Move the .pl in /usr/lib/cgi-bin (there is also some
> perl dependency missing)

Concerning the locations, again the policy is the best available source:

http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1
http://www.debian.org/doc/debian-policy/ch-files.html

As you already correctly said:

configuration files go to /etc/mumble
log files in /var/log/mumble (there should be a configure option)
pid files in /var/run/mumble (there should be a configure option)
pl files in /usr/lib/cgi-bin/mumble

I don't think /var/lib is a good place for murmur.sqlite, shouldn't be
in /etc/ too?

> I don't think /var/lib is a good place for murmur.sqlite, shouldn't be
in /etc/ too?

As murmur.sqlite is often changed by the program itself and not by the user
My first thought was that it belong to /var/lib and not to /etc.

I get the following information from "Filesystem Hierarchy Standard"
from http://www.pathname.com/fhs/pub/fhs-2.3.html:

/var/lib : Variable state information
Purpose

This hierarchy holds state information pertaining to an application or
the system. State information is data that programs modify while they
run, and that pertains to one specific host. Users must never need to
modify files in /var/lib to configure a package's operation.

/etc : Host-specific system configuration
Purpose

The /etc hierarchy contains configuration files. A "configuration
file" is a local file used to control the operation of a program; it
must be static and cannot be an executable binary. [4]

Do you know if debian/ubuntu package usually follow this scheme for
file-based database ?

> First of all, I would like to see the package in revu:

That will be my next step on this subject.

> Concerning the daemon initialisation, you should refer to the debian policy:
>
> http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit
> http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.4
>
> The scripts in /etc/init.d should be good examples of how to write the init
> script.
>
> The dmraid package should give you an idea how to install and start it
> (basically, its just a question of installing the script in /etc/init.d and
> registering it with update-rc.d during postinst, which is done calling the
> dh_installinit debhelper)
>

I will take a look at the policy and the dmraid example, do you know
about /etc/init.d/skeleton, I used to write one or two init.d script
based on it.

> Concerning the locations, again the policy is the best available source:
>
> http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1
> http://www.debian.org/doc/debian-policy/ch-files.html
>
> As you already correctly said:
>
> configuration files go to /etc/mumble
> log files in /var/log/mumble (there should be a configure option)
> pid files in /var/run/mumble (there should be a configure option)
> pl files in /usr/lib/cgi-bin/mumble
>
> I don't think /var/lib is a good place for murmur.sqlite, shouldn't be
> in /etc/ too?
>

/var/log/mumble/mumble.log vs /var/log/mumble.log
/var/run/mumble/mumble.pid vs /var/run/mumble.pid
/usr/lib/cgi-bin/mumble.pl vs /usr/lib/cgi-bin/mumble.pl

What do you think ?

After reporting a couple of minor bugs in the debian/rules script, I was advised to post my findings here:

1: The murmur icon gets installed to /usr/share/pixmaps/mumble.png.1. This causes some issues because gnome can't find the icon with the .1 appended.
Fix: Change line 99 (as of SVN) in debian/rules to the following:
install ./icons/mumble.png.1 $(CURDIR)/debian/mumble/usr/share/pixmaps/mumble.png

2: The above .png and the .desktop file get executable permissions. This can be solved by passing '-m 644' to the install lines for these files (line 98 and 99 as of SVN)
This should fix a couple of those lintian warnings mentioned above.

Regarding the init script - couldn't the debian init script in the wiki (http://mumble.sourceforge.net/Murmur_Init_Script%28Debian%29) be used/modified?

I'm assuming the above posts were a replay of some off-list email conversation and that you aren't discussing with yourself ;)

murmur.sqlite definitely belongs in /var somewhere. It's a binary database with no user-servicable parts inside it. /var/lib/mumble/murmur.sqlite sounds perfect to me, as that also allows us to set the correct owner and permissions for the directory.

When you decide on a file structure, let me know and I'll have the default murmur.ini file we ship reflect it. That should make the diff smaller :)

PS: A user on our forums asked about debian packages. Theoretically speaking, the source package resulting from this should be usable on lenny, right?

Uploaded in current state on REVU http://revu.tauware.de/details.py?upid=447

http://revu.tauware.de/details.py?upid=448
Fix .svn in source

http://revu.tauware.de/details.py?upid=449
Fix debian-rules-ignores-make-clean-error

Uploaded to http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=mumble as well

Fixed General and changelog issue with:
http://revu.tauware.de/details.py?upid=456

Following changes have been applied to the svn debian/ directory.
(See attached patch)

Uploaded to http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=mumble as well.

To Thorvald Natvig:
Norsetto and I noticed that there are additional authors quoted in some souces, are there missing name from the following list ?
./LICENSE:Copyright (C) 2005-2007, Thorvald Natvig <email address hidden>
./speex/COPYING:Copyright 2002-2007 Xiph.org Foundation
./speex/COPYING:Copyright 2002-2007 Jean-Marc Valin
./speex/COPYING:Copyright 2005-2007 Analog Devices Inc.
./speex/COPYING:Copyright 2005-2007 Commonwealth Scientific and Industrial Research
./speex/COPYING:Copyright 1993, 2002, 2006 David Rowe
./speex/COPYING:Copyright 2003 EpicGames
./speex/COPYING:Copyright 1992-1994 Jutta Degener, Carsten Bormann
./speex/include/speex/speex.h:/* Copyright (C) 2002-2006 Jean-Marc Valin*/
./speex/libspeex/_kiss_fft_guts.h:Copyright (c) 2003-2004, Mark Borgerding
./speex/libspeex/vorbis_psy.c:/* Copyright (C) 2005 Jean-Marc Valin, CSIRO, Christopher Montgomery
./src/mumble/PAAudio.cpp: Copyright (C) 2007, Stefan Gehn <mETz AT gehn DOT net>
./src/mumble/TextToSpeech_macx.cpp:/* Copyright (C) 2007, Sebastian Schlingmann <email address hidden>

Here is the list in a more readable format, Thanks in advance:

Thorvald Natvig
Xiph.org Foundation
Jean-Marc Valin
Analog Devices Inc.
Commonwealth Scientific and Industrial Research
David Rowe
EpicGames
Jutta Degener
Carsten Bormann
Jean-Marc Valin
Mark Borgerding
Christopher Montgomery
Stefan Gehn
Sebastian Schlingmann

License holders has been discussed before in this very thread. The speex/ directory is a snapshot of libspeex and libspeexdsp. It includes the COPYING file from that directory. Stefan Gehn and Sebastian Schlingmann have both submitted larger OSX-related patches to Mumble and as such should probably be mentioned in the toplevel LICENSE file. I'll get that fixed.

BTW, before anyone gets confused, Mumble's sourcecode is BSD (revised) licensed, but any binary packages are GPL as you include GPL'd headers when you compile (and link to GPL libraries). So make sure the final package is licensed with GPL. (This is also the reason LICENSE and debian/copyright differ)

Thorvald Natvig, I'm leaving the job to <email address hidden>, he needs mumble packaged for amarok radio.

You can check his last upload on:
http://revu.tauware.de/details.py?package=mumble

This sort of became very, very quiet.

I updated my debian rules and put the package at https://edge.launchpad.net/~slicer/+archive

Could someone take a peek at it?

 - Is debian/nohup.out required?
 - Can we rip out 'speex' out of the tarball? Our archive-admins won't be happy about an internal version of speex. Security fixes will always have to be applied not only for the speex source package but for mumble too. This package should be able to get built with the packaged version of speex.

nohup.out is the output of "nohup". "man nohup" should show it's usage. As an output file that's obviously been included by mistake, it is not required.

The speex issue has been discussed in this very thread.

ISSUE: There is mention in the documentation of Mumble that there is "Proprietary" code within Mumble. Through an IRC discussion, it was determined by Thorvald that there, in fact, was not "Proprietary" code within Mumble. Perhaps this was a misuse of the word. Regardless, it was also determined that this word must be removed from the documentation, in order to be included within the Ubuntu repositories.

ISSUE: The version of Speex libraries included with Ubuntu have insufficient features to be used with Mumble. The newest version of Speex 1.2~beta3 does have, for the most part, sufficient features. By getting Speex 1.3~beta into the Debian Experimental repository, Mumble can be packaged for Ubuntu without duplication of those libraries. This will require updating the Experimental repository. It has already been determined, through the same IRC discussion mentioned above, that the new libraries should not break compatibilities with existing applications with Speex dependencies, by Jean-Marc Valin - lead developer of the Speex project.

ACTION REQUIRED: Update Debian Experimental repository with Speex 1.2~beta3. Sync Ubuntu repository with this upstream package.

The documentation issue is fixed and will be included in the next upload.
Unbundling of speex will have to wait for speex 1.2~beta4 or 1.2 final (whichever happens first) -- the changes mumble requires are now included in speex svn and will be included in the next release.

Mumble is now included in hardy.

Uploaded to hardy.