Debian Bug report logs - #674634
transition: celt

Package: release.debian.org; Maintainer for release.debian.org is Debian Release Team <debian-release@lists.debian.org>;

Reported by: Ron <ron@debian.org>

Date: Sat, 26 May 2012 09:18:01 UTC

Severity: normal

Done: "Adam D. Barratt" <adam@adam-barratt.org.uk>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#674634; Package release.debian.org. (Sat, 26 May 2012 09:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 26 May 2012 09:18:12 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: transition: celt
Date: Sat, 26 May 2012 18:38:11 +0930
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

Hi,

We'd like to remove the celt package from the distro for the Wheezy release.
CELT was an experimental codec from Xiph, and that work has now been merged
into the Opus codec which is about to be ratified as an IETF standard.

As a result of that, upstream is no longer maintaining celt at all, and being
an experimental codec, no two releases of it were ever bitstream compatible
with each other (and only one release was ever made that even maintained API
compatibility with prior versions).  All packages using it at the time knew
and accepted that this would be the situation with it while it evolved ...

The version that Debian currently is shipping we tried to get consensus on
people agreeing to consider it an interoperability snapshot before squeeze,
but in the end that never actually happened in practice and other distros
shipped other incompatible versions of it anyway.

So we (meaning myself, upstream, and anyone else who has discussed this with
us in detail) see little value in continuing to ship this, and plenty of
opportunity for Harm.  Apps using it in Debian will only be interoperable
with the Debian releases of themselves, there will be no security support,
and it will just further fragment the codec space, at a time when there
is a real standard alternative people should be looking at for the future.


I'd have moved on this sooner, but it's only been in the last few days that
we actually had enough certainty about the IETF process concluding to really
know what the foreseeable future of all this was going to be.  I've already
been actively talking to upstreams of the affected packages to be sure we
might actually pull this off in the time we have remaining, and I'm sure
enough that this will be possible now to really propose a formal course of
action for Wheezy.  We've been planning for this in general terms for years
now, but nothing could actually move until the IETF did.  And now they have.


Death, taxes, and bad timing.


Anyhow, this actually should be fairly simple, being an experimental codec
almost everything already has support for only optionally enabling it. So
we just need sourceful uploads of packages to turn it off - then celt can
safely be removed.

Some of the deps have already been updated to remove it, the remaining ones
as of yesterday were:

# Broken Depends:
gst-plugins-bad0.10: gstreamer0.10-plugins-bad
jack-audio-connection-kit: jackd1
jackd2: jackd2
        libjack-jackd2-0
mangler: libventrilo3-0
opal: libopal3.10.4 [amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc]
roaraudio: libroar2
           roaraudio


Opal I've been told will remove it with its next upload.

Mangler appears to be under control, details here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674244

gst, I've spoken to upstream and this is a no-brainer, but I still
need to get a ping back from slomo about updating the package.

jack should be just disable the option too, but I'm still chasing its
Debian maintainer for confirmation of doing it.  Worst case I should
be able to do a trivial NMU myself.

Roar, I've been assured by its upstream is likewise easy to just disable
support for it - but the-me is giving me some pointless pushback ...
I'll NMU that too when the time comes if really needed if this is the
final blocker.

There shouldn't be any other flow on from this so far as I know.
Some of these packages may enable Opus support instead, but doing so
is not a prerequisite for us being able to remove celt for Wheezy.


 Thanks!
 Ron




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#674634; Package release.debian.org. (Mon, 28 May 2012 11:33:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Philipp Schafft <lion@lion.leolix.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 28 May 2012 11:33:15 GMT) Full text and rfc822 format available.

Message #10 received at 674634@bugs.debian.org (full text, mbox):

From: Philipp Schafft <lion@lion.leolix.org>
To: Ron <ron@debian.org>, 674634@bugs.debian.org
Subject: Re: Bug#674634: transition: celt
Date: Mon, 28 May 2012 11:54:14 +0200
[Message part 1 (text/plain, inline)]
reflum,

On Sat, 2012-05-26 at 18:38 +0930, Ron wrote:
> Roar, I've been assured by its upstream is likewise easy to just disable
> support for it - but the-me is giving me some pointless pushback ...
> I'll NMU that too when the time comes if really needed if this is the
> final blocker.
> 
> There shouldn't be any other flow on from this so far as I know.
> Some of these packages may enable Opus support instead, but doing so
> is not a prerequisite for us being able to remove celt for Wheezy.

Removal of CELT will remove a major feature of src:roaraudio. It will
not render the package useless just will make it useless for a group of
users. This is why we like to make this a smooth transition with getting
in Opus first, then removing CELT. Also note that this transition needs
users using it to change config so it should not be a single upload
removing one and adding the other.

The cirtical factor is time here. Ron Lee is a bit late with this
transition in the release cycle. Had he given us about a month more we
would have done all this already and everybody would be happy.

I have discusses several possibile ways to get this solved with the-me
(the maintainer). In fact both of us would *really* like to get this
done. CELT always added some extra work both upstream and in maintaining
packages because of the unfrozen bitstream.

-- 
Philipp.
 (Rah of PH2)
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#674634; Package release.debian.org. (Mon, 28 May 2012 11:57:20 GMT) Full text and rfc822 format available.

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 28 May 2012 11:57:23 GMT) Full text and rfc822 format available.

Message #15 received at 674634@bugs.debian.org (full text, mbox):

From: Cyril Brulebois <kibi@debian.org>
To: Philipp Schafft <lion@lion.leolix.org>, 674634@bugs.debian.org
Cc: Ron <ron@debian.org>
Subject: Re: Bug#674634: transition: celt
Date: Mon, 28 May 2012 13:53:00 +0200
[Message part 1 (text/plain, inline)]
Hello Philipp, Ron, etc.

Philipp Schafft <lion@lion.leolix.org> (28/05/2012):
> The cirtical factor is time here. Ron Lee is a bit late with this
> transition in the release cycle. Had he given us about a month more we
> would have done all this already and everybody would be happy.

Yes it's late.

> I have discusses several possibile ways to get this solved with the-me
> (the maintainer). In fact both of us would *really* like to get this
> done. CELT always added some extra work both upstream and in maintaining
> packages because of the unfrozen bitstream.

Not speaking for the release team as a whole, but it looks to me that we
should be able to consider letting a new roaraudio in (switching from
celt to opus) after the freeze.

Mraw,
KiBi.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#674634; Package release.debian.org. (Mon, 28 May 2012 13:18:21 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 28 May 2012 13:18:26 GMT) Full text and rfc822 format available.

Message #20 received at 674634@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Philipp Schafft <lion@lion.leolix.org>
Cc: 674634@bugs.debian.org
Subject: Re: Bug#674634: transition: celt
Date: Mon, 28 May 2012 22:37:53 +0930
On Mon, May 28, 2012 at 11:54:14AM +0200, Philipp Schafft wrote:
> reflum,
> 
> On Sat, 2012-05-26 at 18:38 +0930, Ron wrote:
> > Roar, I've been assured by its upstream is likewise easy to just disable
> > support for it - but the-me is giving me some pointless pushback ...
> > I'll NMU that too when the time comes if really needed if this is the
> > final blocker.
> > 
> > There shouldn't be any other flow on from this so far as I know.
> > Some of these packages may enable Opus support instead, but doing so
> > is not a prerequisite for us being able to remove celt for Wheezy.
> 
> Removal of CELT will remove a major feature of src:roaraudio. It will
> not render the package useless just will make it useless for a group of
> users.

For anyone actually relying on CELT for this (of which I highly suspect
there is very near to nobody), the current situation is already worse
than useless.  The version we have is not bitstream compatible with the
version of celt that other distros are shipping, so the result of trying
to use it will be something approximating speaker and ear popping noise.

This also would have happened to them if I'd actually uploaded a newer
version of CELT as several people had requested ...

If nobody has reported that to you, then it confirms my suspicion that
nobody will actually notice it going away.

Since you don't even mention celt support in any of your descriptions
of roar, either in the package or on your website, this seems more like
a minor easter egg than a "major feature" anyway.


> This is why we like to make this a smooth transition with getting
> in Opus first, then removing CELT. Also note that this transition needs
> users using it to change config so it should not be a single upload
> removing one and adding the other.

If you can't sanely handle this in one upload, then your package is
broken for your users anyway.  There is no arbitrary period of time
on the order of "1 month" as you claimed earlier in which they will
all update to the first version before you upload the second.


> The cirtical factor is time here. Ron Lee is a bit late with this
> transition in the release cycle. Had he given us about a month more we
> would have done all this already and everybody would be happy.

Let's be very clear on this point.  You have been asking me about this
for over a year now, and have been fully informed on everything that
was planned.  So if anyone is "a bit late" getting their act together,
you'll need to discuss that with the man you see in the mirror.

Yes, this is late in the cycle - but only from the perspective of the
release team.  Everyone else, including you, has known this was coming,
and that things would happen fast after the IETF working group finally
concluded, as uncertain as the actual date for that had been.  And
everyone else, except you, has been extremely cooperative and has got
their part of the work done already, efficiently and painlessly.

A few days ago, you claimed this would take 4 months.  Today you claim
a month.  Without getting gnuplot out to fit this, on that projection
we should be down to my 15 minute estimate, by say, this Wednesday?

I already sent you the one line patch that was needed.  And I still have
the 12 minutes up my sleeve from doing that if you'd like me to upload it.

Just say "Ok".  and it will happen.  It doesn't get much easier than that.


> I have discusses several possibile ways to get this solved with the-me
> (the maintainer). In fact both of us would *really* like to get this
> done. CELT always added some extra work both upstream and in maintaining
> packages because of the unfrozen bitstream.

You keep saying that, and then keep denying any action that would actually
really do it.  The last time I asked you, you even denied being one of the
maintainers and having any say in what happens with this at all ...

What exactly is the "several possible ways" you have in mind?

<hint> Embedding celt in roar is not one of them </>


  Ron






Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#674634; Package release.debian.org. (Wed, 06 Jun 2012 23:30:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Philipp Schafft <lion@lion.leolix.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Wed, 06 Jun 2012 23:30:16 GMT) Full text and rfc822 format available.

Message #25 received at 674634@bugs.debian.org (full text, mbox):

From: Philipp Schafft <lion@lion.leolix.org>
To: Ron <ron@debian.org>
Cc: 674634@bugs.debian.org
Subject: Re: Bug#674634: transition: celt
Date: Thu, 07 Jun 2012 01:23:57 +0200
[Message part 1 (text/plain, inline)]
reflum,

On Mon, 2012-05-28 at 22:37 +0930, Ron wrote:
> On Mon, May 28, 2012 at 11:54:14AM +0200, Philipp Schafft wrote:
> > On Sat, 2012-05-26 at 18:38 +0930, Ron wrote:
> > > Roar, I've been assured by its upstream is likewise easy to just disable
> > > support for it - but the-me is giving me some pointless pushback ...
> > > I'll NMU that too when the time comes if really needed if this is the
> > > final blocker.
> > > 
> > > There shouldn't be any other flow on from this so far as I know.
> > > Some of these packages may enable Opus support instead, but doing so
> > > is not a prerequisite for us being able to remove celt for Wheezy.
> > 
> > Removal of CELT will remove a major feature of src:roaraudio. It will
> > not render the package useless just will make it useless for a group of
> > users.
> 
> For anyone actually relying on CELT for this (of which I highly suspect
> there is very near to nobody), the current situation is already worse
> than useless.  The version we have is not bitstream compatible with the
> version of celt that other distros are shipping, so the result of trying
> to use it will be something approximating speaker and ear popping noise.

This is completly untrue. You yourself told me you taked to other
distros to sync this. Also the Protocol requires sending a magic
including the bitstream version. If the versions don't match it will
fail and tell the user about the problem. Please stop telling
everybody's software would be broken.


> This also would have happened to them if I'd actually uploaded a newer
> version of CELT as several people had requested ...

No. See above.


> If nobody has reported that to you, then it confirms my suspicion that
> nobody will actually notice it going away.

No. See above.


> Since you don't even mention celt support in any of your descriptions
> of roar, either in the package or on your website, this seems more like
> a minor easter egg than a "major feature" anyway.

Package descriptions are no docs. If I list all features I will have
documentation. See your own package descriptions...


> > This is why we like to make this a smooth transition with getting
> > in Opus first, then removing CELT. Also note that this transition needs
> > users using it to change config so it should not be a single upload
> > removing one and adding the other.
> 
> If you can't sanely handle this in one upload, then your package is
> broken for your users anyway.  There is no arbitrary period of time
> on the order of "1 month" as you claimed earlier in which they will
> all update to the first version before you upload the second.

This has nothing to do with the package but with users. Users are
nothing I can update via upload.



> > The cirtical factor is time here. Ron Lee is a bit late with this
> > transition in the release cycle. Had he given us about a month more we
> > would have done all this already and everybody would be happy.
> 
> Let's be very clear on this point.  You have been asking me about this
> for over a year now, and have been fully informed on everything that
> was planned.  So if anyone is "a bit late" getting their act together,
> you'll need to discuss that with the man you see in the mirror.

Let's make it *very* clear: Last time I asked you you said nothing about
this nor pinged the package maintainer via an offical (like BTS) or
inoffical (like pinging me on IRC) channel.


> Yes, this is late in the cycle - but only from the perspective of the
> release team.  Everyone else, including you, has known this was coming,
> and that things would happen fast after the IETF working group finally
> concluded, as uncertain as the actual date for that had been.  And
> everyone else, except you, has been extremely cooperative and has got
> their part of the work done already, efficiently and painlessly.

See above.

> A few days ago, you claimed this would take 4 months.  Today you claim
> a month.  Without getting gnuplot out to fit this, on that projection
> we should be down to my 15 minute estimate, by say, this Wednesday?

I'm sorry if this was unclear: I was talking about the technical part
here. The diffrence is because there is not only your schedule but also
the one of other groups. The RoarAudio project has a defined release
cycle to ensure quality. Depending on when you ping us (what you never
did) changes take one or two months to go in if they are accepted.
You can read about it here:
https://bts.keep-cool.org/wiki/ReleaseCycle



> I already sent you the one line patch that was needed.  And I still have
> the 12 minutes up my sleeve from doing that if you'd like me to upload it.
> 
> Just say "Ok".  and it will happen.  It doesn't get much easier than that.

You send a one line patch to break the package.

In the bug you opend (after you gave us 13 minutes to upload or NMU as
you said, very nice move btw.) you tell us that it is this easy as it is
no transition to opus but a pure removal of celt. Please look at the
title of this ticket. Transitions do *NOT* consist of removing something
without replaceing it.


> What exactly is the "several possible ways" you have in mind?

Possible ways include taking CELT, removing everything, removing parts,
stopping working for and with Debian.

> <hint> Embedding celt in roar is not one of them </>

Oh, that was what you recommended before we told you that this is a very
bad idea. Rememer?




Dear release team,

the-me (the maintainer) just uploaded a new version with CELT disabled.
Opus support is not yet entered upstream (see
https://bts.keep-cool.org/ticket/243 for details).

This is NOT because the maintainers think this is right but *ONLY*
because we stop caring. Ron Lee is not willing to help, does not follow
the standards (like opening tickets early), telling everbody technically
wrong things (like the above). The rest of what we hear from him is
strong language.

We gave up. This is the same for mumble, where the maintainer(s) gave up
and handed the maintainership to ron. He broke the package and now it is
*completly* *useless* (#675971). In case of RoarAudio it is only
completly useless for some of it's users.

Whenever there is a problem somebody like him stand up, shout at you and
you can be sure one of those words are included: RM, drop or NMU.
Most NMUs I saw lately broke the packages in one or another way.

The result are developers no longer caring like me. Just a few months
ago I hoped to become a DD. Now I think of switching away even as user.
Other DDs I know consider the same. Some already done.


-- 
Philipp.
 (Rah of PH2)
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#674634; Package release.debian.org. (Wed, 06 Jun 2012 23:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to pmatthaei@debian.org:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Wed, 06 Jun 2012 23:54:03 GMT) Full text and rfc822 format available.

Message #30 received at 674634@bugs.debian.org (full text, mbox):

From: Patrick Matthäi <pmatthaei@debian.org>
To: 674634@bugs.debian.org
Cc: Philipp Schafft <lion@lion.leolix.org>, Ron <ron@debian.org>
Subject: Re: Bug#674634: transition: celt
Date: Thu, 07 Jun 2012 01:51:02 +0200
[Message part 1 (text/plain, inline)]
Hey,

I will answer as the current/still roaraudio and the previous mumble
maintainer, but I do not want to lost too much words anymore about this
*** whole situation.

As an side note, please CC me, I am not subscribed to this list anymore.

Am 07.06.2012 01:23, schrieb Philipp Schafft:
>> Since you don't even mention celt support in any of your descriptions
>> of roar, either in the package or on your website, this seems more like
>> a minor easter egg than a "major feature" anyway.
> 
> Package descriptions are no docs. If I list all features I will have
> documentation. See your own package descriptions...

Full ACK with Philipp.

> 
> 
>>> This is why we like to make this a smooth transition with getting
>>> in Opus first, then removing CELT. Also note that this transition needs
>>> users using it to change config so it should not be a single upload
>>> removing one and adding the other.
>>
>> If you can't sanely handle this in one upload, then your package is
>> broken for your users anyway.  There is no arbitrary period of time
>> on the order of "1 month" as you claimed earlier in which they will
>> all update to the first version before you upload the second.
> 
> This has nothing to do with the package but with users. Users are
> nothing I can update via upload.

I also can not understand why it is a fix to break compatiblity and
(main) features by just disabling them blindly..

>>> The cirtical factor is time here. Ron Lee is a bit late with this
>>> transition in the release cycle. Had he given us about a month more we
>>> would have done all this already and everybody would be happy.
>>
>> Let's be very clear on this point.  You have been asking me about this
>> for over a year now, and have been fully informed on everything that
>> was planned.  So if anyone is "a bit late" getting their act together,
>> you'll need to discuss that with the man you see in the mirror.
> 
> Let's make it *very* clear: Last time I asked you you said nothing about
> this nor pinged the package maintainer via an offical (like BTS) or
> inoffical (like pinging me on IRC) channel.

With my package maintainer hat on I just heard about this removal ~7-10
days ago, and I heard it from one of my upstreams..

>> Yes, this is late in the cycle - but only from the perspective of the
>> release team.  Everyone else, including you, has known this was coming,
>> and that things would happen fast after the IETF working group finally
>> concluded, as uncertain as the actual date for that had been.  And
>> everyone else, except you, has been extremely cooperative and has got
>> their part of the work done already, efficiently and painlessly.
> 
> See above.

Everyone else is not ready to replace celt or to support opus, see my
messages later..


> 
>> A few days ago, you claimed this would take 4 months.  Today you claim
>> a month.  Without getting gnuplot out to fit this, on that projection
>> we should be down to my 15 minute estimate, by say, this Wednesday?
> 
> I'm sorry if this was unclear: I was talking about the technical part
> here. The diffrence is because there is not only your schedule but also
> the one of other groups. The RoarAudio project has a defined release
> cycle to ensure quality. Depending on when you ping us (what you never
> did) changes take one or two months to go in if they are accepted.
> You can read about it here:
> https://bts.keep-cool.org/wiki/ReleaseCycle


I also taked to several people that Philipp said that it *may* be
possible to include opus/whatever support withing 1-2 months (I said
that around seven days ago), but in the same sentence I said, that it
wouldn't be stable, it would be something like a hack to build with the
missing celt..

>> I already sent you the one line patch that was needed.  And I still have
>> the 12 minutes up my sleeve from doing that if you'd like me to upload it.
>>
>> Just say "Ok".  and it will happen.  It doesn't get much easier than that.
> 
> You send a one line patch to break the package.
> 
> In the bug you opend (after you gave us 13 minutes to upload or NMU as
> you said, very nice move btw.) you tell us that it is this easy as it is
> no transition to opus but a pure removal of celt. Please look at the
> title of this ticket. Transitions do *NOT* consist of removing something
> without replaceing it.

Full ACK with Philipp.

>> <hint> Embedding celt in roar is not one of them </>
> 
> Oh, that was what you recommended before we told you that this is a very
> bad idea. Rememer?

YOU (ron) said to me, that mumble is such a special case within your
great planned and well done celt => opus transition, why it should use
it's embedded celt version. I have told you several times that it is a
quite bad idea, it would be better to maintain celt as an ato. package
about the wheezy lifetime! Using the embedded celt version is a bug per
policy and debian-security also will not be happy about this (but I told
this too much times..)...

> Dear release team,
> 
> the-me (the maintainer) just uploaded a new version with CELT disabled.
> Opus support is not yet entered upstream (see
> https://bts.keep-cool.org/ticket/243 for details).
> 
> This is NOT because the maintainers think this is right but *ONLY*
> because we stop caring. Ron Lee is not willing to help, does not follow
> the standards (like opening tickets early), telling everbody technically
> wrong things (like the above). The rest of what we hear from him is
> strong language.

Again full ACK.

> 
> We gave up. This is the same for mumble, where the maintainer(s) gave up
> and handed the maintainership to ron. He broke the package and now it is
> *completly* *useless* (#675971). In case of RoarAudio it is only
> completly useless for some of it's users.

Given the above (that he wanted to use the embedded version and I do not
agree with it, and with this so called "transition" at this time in
general) I realy were suprised that Ron completly moved mumble to opus
now, with the side effects that (I will just quote from the bugreport):

* without CELT, you sit on a small island, population you,
and talk to yourself :-P

* With disabled CELT, mumble produces horrible audio glitches which are
a known issue with the current OPUS integration. Furthermore, it means
Debian mumble clients can no longer sanely communicate with any
officially released version. In the worst case, it will even break
things for other users on a server since it shows very incomplete codec
support.

IMHO mumble is release critical now and should not be released in this
state, also if Ron downgraded this issue to wishlist and closed it.


> 
> Whenever there is a problem somebody like him stand up, shout at you and
> you can be sure one of those words are included: RM, drop or NMU.
> Most NMUs I saw lately broke the packages in one or another way.
> 
> The result are developers no longer caring like me. Just a few months
> ago I hoped to become a DD. Now I think of switching away even as user.
> Other DDs I know consider the same. Some already done.
> 

Or upstreams (okay Philipp is also an upstream), but I also were
contacted by some mumble upstream developers what I have done with my
last upload (ok not my fault, not my upload), but it is realy
disappoitining). Much thanks to Nicos for publishing the logs. Get some
popcorn and read e.g.:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675971#29

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatthaei@debian.org
        patrick@linux-dev.org
*/


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#674634; Package release.debian.org. (Sat, 30 Jun 2012 23:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 30 Jun 2012 23:18:03 GMT) Full text and rfc822 format available.

Message #35 received at 674634@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Ron <ron@debian.org>, 674634@bugs.debian.org
Subject: Re: Bug#674634: transition: celt
Date: Sun, 1 Jul 2012 01:16:17 +0200
[Message part 1 (text/plain, inline)]
On Sat, May 26, 2012 at 18:38:11 +0930, Ron wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> We'd like to remove the celt package from the distro for the Wheezy release.
> CELT was an experimental codec from Xiph, and that work has now been merged
> into the Opus codec which is about to be ratified as an IETF standard.
> 
The only rdep left in testing at this point is mumble.  What's the plan
here?

Cheers,
Julien
[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending. Request was from Julien Cristau <jcristau@debian.org> to control@bugs.debian.org. (Sat, 30 Jun 2012 23:18:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#674634; Package release.debian.org. (Sun, 01 Jul 2012 04:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sun, 01 Jul 2012 04:24:03 GMT) Full text and rfc822 format available.

Message #42 received at 674634@bugs.debian.org (full text, mbox):

From: Ron <ron@debian.org>
To: Julien Cristau <jcristau@debian.org>
Cc: 674634@bugs.debian.org
Subject: Re: Bug#674634: transition: celt
Date: Sun, 1 Jul 2012 13:42:03 +0930
On Sun, Jul 01, 2012 at 01:16:17AM +0200, Julien Cristau wrote:
> On Sat, May 26, 2012 at 18:38:11 +0930, Ron wrote:
> 
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian.org@packages.debian.org
> > Usertags: transition
> > 
> > Hi,
> > 
> > We'd like to remove the celt package from the distro for the Wheezy release.
> > CELT was an experimental codec from Xiph, and that work has now been merged
> > into the Opus codec which is about to be ratified as an IETF standard.
> > 
> The only rdep left in testing at this point is mumble.  What's the plan
> here?

There are too many things that still need fixing with mumble at this stage for
me to recommend it as a viable release candidate for wheezy.  It currently
FTBFS now that boost1.46 was removed, and I don't know yet if that will just
need the build-dep adjusted, or actual changes to the source - which is kind
of academic while it's also still blocked by the zeroc-ice ABI breakage of
#672066 (which at this stage is debian specific, and we have no idea what
zeroc-ice upstream is really going to do to make it work with gcc 4.7).

So the best plan I have right now would be to remove mumble from testing and
worry about fixing its problems in unstable with a free hand (knowing we won't
be annoying the release team with large patches to review - which I'm pretty
sure it's going to need still before this is all in good shape again).

That will let you close this bug - and also give you the option of removing
zeroc-ice too if that bug doesn't get a sane fix soon (since mumble is also
its only rdep).  Shipping that in its current state doesn't really seem like
something I'd recommend either, but that one is less of my call to make ...


 Cheers,
 Ron






Reply sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
You have taken responsibility. (Sat, 08 Dec 2012 17:03:14 GMT) Full text and rfc822 format available.

Notification sent to Ron <ron@debian.org>:
Bug acknowledged by developer. (Sat, 08 Dec 2012 17:03:14 GMT) Full text and rfc822 format available.

Message #47 received at 674634-done@bugs.debian.org (full text, mbox):

From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
To: Ron <ron@debian.org>, 674634-done@bugs.debian.org
Subject: Re: Bug#674634: transition: celt
Date: Sat, 08 Dec 2012 16:59:26 +0000
On Sat, 2012-05-26 at 18:38 +0930, Ron wrote:
> We'd like to remove the celt package from the distro for the Wheezy release.

That finally happened a few weeks ago (modulo the embedded copy in
mumble); closing.

Regards,

Adam




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 06 Jan 2013 07:26:20 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 15:06:53 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.