Speex on AMD64 Dapper
william.grant at ubuntu.com.au
Mon Oct 23 10:54:51 BST 2006
On Monday 23 October 2006 19:19, Jean-Marc Valin wrote:
> > Just to clarify -- When William said "speex is in main", he meant the
> > source package speex is in main. Although the binary package speex is
> > in universe, since both speex and libspeex1 are built from the source
> > package speex, and libspeex1 is in main, this means the source package
> > speex is in main. (Yeah, it is quite confusing when you look at
> > Launchpad.)
> Can the binary package be fixed in universe. There's actually no problem
> with libspeex1, only with the speex binary package. In any case, if you
> cannot update the binary package "speex", please *remove* it from amd64.
> As it is, any attempt to use speexenc on AMD64 results in a crash right
> at the beginning. There is simply no reason to include it in AMD64
> Dapper if it's not fixed.
Removing a package from a stable release is a major change, and is (I believe)
unprecedented. I see no real reason for doing it.
> > As I've commented in bug #19482, to update a main package in dapper, the
> > procedures in https://wiki.ubuntu.com/StableReleaseUpdates needs to be
> > followed. And I agree with William that contacting ubuntu-devel list
> > would be a good idea.
> Had a quick look at the conditions. It seems like they don't allow for
> "package is totally broken",
I believe that would count, and it is the basis of another pending update.
> so unless they make an exception (unlikely
> considering they didn't even bother applying the patch *before* Dapper
> was released), only options left are:
> 1) Fixing the speex binary package in universe (and keeping the broken
> source package)
We can't upload binary-only packages, but we'll try to get the source fixed.
This probably won't happen before Edgy's release (there are more pressing
things that need to be done within the next three days, this issue has no
real time limit), but soon after.
> 2) Removing the speex binary package from universe (for Dapper AMD64 only).
> 3) Keeping a binary that will either (if you're lucky) crash on startup
> or else (if unlucky) generate a corrupted encoded file.
> Please don't choose 3!
Option 1 will most likely be executed in the next week, although maybe a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20061023/8c543238/attachment.pgp
More information about the Ubuntu-motu