Bug#682010: [mumble] Communication failures due to CELT codec library removal

[Ron]

On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:
> The issue I have now is that The Plan that Ron and Thorvald have come up with 
> Will Not Work, depending what the _goal_ is.  If the goal is to be able to 
> interoperate with the existing *server* base [which was exactly why this came 
> to the TC in the first place], that won't be possible -- because the Speex 
> codec up to this point is not part of the selection process in the existing 
> servers.

I am 110% certain that Thorvald is not going to accept any solution that he
thinks can't be made to work for the vast majority of users.  That was the
crux of our conversation last week, and something which he has always been
unwavering about.  We have had many such conversations in the past, trying to
reconcile the, uh, idiosyncrasies, of gamers with best practice for Debian.

What you seem to have failed to note, or that Nicos has failed to tell you,
is that Speex is not included in the server side negotiation because it is
assumed axiomatically that *every* client has speex decoding ability.  So
it does not need to be negotiated.  You can send it at any time, and it will
work, without needing to be announced in advance, or the server needing to
do anything.

That point is currently still true.  Every existing client has the ability
to *decode* speex if speex packets arrive.

The only thing removed from recent clients was the ability to encode them.
This is what we need to restore.


> [Special thanks goes to Nicos for watching our backs here.]

Just to be clear here, because at some point Ian described Nicos as being
"a mumble developer", and you have now declared him a "sage" ...

$ git log master | wc -l
30363

$ git log master | grep Nicos | wc -l
12

And all of those commits afaics relate to GUI overlay stuff for games,
nothing at all to do with the protocol negotiation we are talking about
here ...   So I think I'd still rather put my trust in the the opinion
of Thorvald about what can be made to work, than in someone who has said
repeatedly, "Debian should just remove this, nobody cares because nobody
uses Debian anyhow".  Which is also clearly quite incorrect, or we wouldn't
be having this discussion at all.


The current facts are:

 - The server is currently 100% broken in testing, and will remain so
   for our users for as long as this is blocked here.

 - Thorvald has a plan that nobody here had thought of or considered
   previously.  We can't assess that until he gets back and implements
   it - but second guessing him here in the meantime is only going to
   waste his time with more mail to read before he gets to doing that.
   And his time is already very limited.

 - If that plan doesn't work, we have other plans we can weigh up
   falling back to.

 - If we have to fall back to those plans, and -ctte wants to assert
   that it would rather Debian ship an unmaintained codec, which nobody
   has spent more than a couple of hours quickly auditing for obvious
   problems, but which does have a real suspicion of deep problems ...

   Then provided we have a clear public record of the people wanting
   that putting *their* own heads on the block, and taking the full
   responsibility for any fall out or required remedy -- then I have
   clean hands, and someone to point at who is completely to blame for
   an action I advised against in the event it goes Horribly wrong.

   If the people wanting that can get the consensus of the TC (and
   I would much rather see this as an even informal consensus than
   than as a formal but narrowly won vote), then I'll set my own
   objection aside and we'll let history and fate be the judge.

Worrying about things that we aren't precluding as fallback options
before we've confirmed we do need to fall back to them doesn't seem
particularly productive to me though.  I think Steve pretty accurately
spotted there are _no_ ideal solutions here.  Hopefully mumble will
improve on these things too and this will be less of a problem for
Wheezy+1, but in the meantime I think we need to balance the amount
of inconvenience some users might experience (which seems unavoidable
whatever we do) against the amount of risk we are prepared to expose
them to (which seems quite avoidable).


The weekend here is nearly over, and I can't keep stealing time from
my Work customers to keep discussing this in circles next week (and
I'm sure many others here are in the same position).

The longer we draw this out, the less testing any of it is going to
have, the less time is going to be available to fix any shortcomings
that we haven't so far seen, and the poorer the result that we are
ultimately going to end up with.

 Ron


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120722083500.gw18...@audi.shelbyville.oz

Bug#681687: missing mime entry

[Michael Biebl]

On 21.07.2012 23:40, Adam D. Barratt wrote:
> On Sat, 2012-07-21 at 23:12 +0200, Michael Biebl wrote:
>> On 21.07.2012 09:11, Steve Langasek wrote:
>>
>>> Now, I think providing a tool to auto-translate .desktop files into mailcap
>>> entries is a perfectly appropriate way to go about solving this bug, if
> [...]
>> The new mime support maintainer team, which took over the package just a
>> few days ago, did ask the release team, if it would be possible to still
>> apply this patch for wheezy [2].
> [...]
>> [2] https://lists.debian.org/debian-release/2012/07/msg01048.html
> 
> As far as I can tell, that's very much not what that message says.  In
> fact, it doesn't appear to request anything of the release team at all.

Well, Charles did not specifically ask the release team, but he CCed the
release team and his email contains:

> 4) Postpone any other change on the main branch until either #681687 (tech.
>comittee) is solved or Wheezy released.

This reads to me as if Charlees is waiting for a decision from the ctte.

If Steve and other members of the ctte consider such a tool as an
approriate way to solve this bug, would the release team also
acknowledge this approach or not?

Anyway, let's put Charles and Laszlo on CC so they have chance to
comment on it.

My position is clearly, that this issue should be solved for good.
Postponing this for another release just doesn't seem right to me, as
simply adding back a single mime file would be an incomplete workaround
at best.

From past experience we still have around 5 months until we release.
This should be enough time to get this ready for wheezy. And as said, if
unsurmountable problems turn up which can't be addressed within say two
months, we can simply drop the converter again and then add back the
evince mime file.

Is this a proposal that the ctte, release team and mime-support
maintainers could agree with?


Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#681687: missing mime entry

[Adam D. Barratt]

On Sun, 2012-07-22 at 15:24 +0200, Michael Biebl wrote:
> On 21.07.2012 23:40, Adam D. Barratt wrote:
> > On Sat, 2012-07-21 at 23:12 +0200, Michael Biebl wrote:
> >> On 21.07.2012 09:11, Steve Langasek wrote:
> >>
> >>> Now, I think providing a tool to auto-translate .desktop files into 
> >>> mailcap
> >>> entries is a perfectly appropriate way to go about solving this bug, if
> > [...]
> >> The new mime support maintainer team, which took over the package just a
> >> few days ago, did ask the release team, if it would be possible to still
> >> apply this patch for wheezy [2].
> > [...]
> >> [2] https://lists.debian.org/debian-release/2012/07/msg01048.html
> > 
> > As far as I can tell, that's very much not what that message says.  In
> > fact, it doesn't appear to request anything of the release team at all.
> 
> Well, Charles did not specifically ask the release team, but he CCed the
> release team

Well, he hit "reply all" on a thread that was already CCed to the
release team.  I'm not sure it would otherwise have been copied.

> and his email contains:
> 
> > 4) Postpone any other change on the main branch until either #681687 (tech.
> >comittee) is solved or Wheezy released.
> 
> This reads to me as if Charlees is waiting for a decision from the ctte.

Agreed.  It's still not even implicitly a request for release team
comment on the solution imo, but let's leave that particular horse in
peace before the discussion gets any more circular. :-/

> If Steve and other members of the ctte consider such a tool as an
> approriate way to solve this bug, would the release team also
> acknowledge this approach or not?

If it's the solution that the TC decide on to resolve the issue, it
sounds like something we could work with, at least imho, from what I've
seen so far.  I've CCed -release for any further comments, as I don't
know how many members of the team are following -ctte and/or this bug.

For clarity, the current proposal would be
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;filename=mime-support-desktop.patch;att=1;bug=497779
 , or something similar?

[...]
> From past experience we still have around 5 months until we release.
> This should be enough time to get this ready for wheezy. And as said, if
> unsurmountable problems turn up which can't be addressed within say two
> months, we can simply drop the converter again and then add back the
> evince mime file.

With my release hat on, it feels like "there's still a while until we
release" is being used more often recently as a justification for trying
to get larger scale changes incorporated or fixes delayed.  While I'm
not implying that's the intention in this case, I do think we need to be
wary of saying "there'll be plenty of time to fix that still".


Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1342968190.13223.156.ca...@jacala.jungle.funky-badger.org

Bug#681687: missing mime entry

[Ian Jackson]

Adam D. Barratt writes ("Bug#681687: missing mime entry"):
> If it's the solution that the TC decide on to resolve the issue, it
> sounds like something we could work with, at least imho, from what I've
> seen so far.  I've CCed -release for any further comments, as I don't
> know how many members of the team are following -ctte and/or this bug.

Right.  So far I think my personal view is that I'm happy for the
release team to carry on doing whatever they think is best, on this
issue.

> For clarity, the current proposal would be
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;filename=mime-support-desktop.patch;att=1;bug=497779
>  , or something similar?

I would be worried that this would make a widespread and radical
change to the behaviour of the mime-support-using packages.  Are we
sure that that's the right thing to do at this stage of the release ?

If we were wanting to do this properly, we would compare the
automatically-generated entires with the previous manually-written
ones, to see what behavioural changes we would expect.

> With my release hat on, it feels like "there's still a while until we
> release" is being used more often recently as a justification for trying
> to get larger scale changes incorporated or fixes delayed.  While I'm
> not implying that's the intention in this case, I do think we need to be
> wary of saying "there'll be plenty of time to fix that still".
> 

I certainly don't think "we failed to get the automatic machinery
deployed and tested properly before the freeze" is a good excuse for
insisting on a freeze exception for it.

I can see why the evince maintainers are reluctant to keep on with an
approach they regard as obsolete and deprecated, but until the
replacement is properly deployed and tested that's what we should do.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20492.6400.872581.996...@chiark.greenend.org.uk

Bug#681687: missing mime entry

[Steve Langasek]

On Sat, Jul 21, 2012 at 11:12:25PM +0200, Michael Biebl wrote:
> A patch providing this converter has been available for a few months
> [1]. The mime-support maintainer just never got around to upload it or
> even comment on it.

> The new mime support maintainer team, which took over the package just a
> few days ago, did ask the release team, if it would be possible to still
> apply this patch for wheezy [2].
> I think this should be the solution we should aim for and I would
> appreciate if the release team could give the mime-support maintainers a
> green light for the unstable upload.

I agree that we should aim for such an automated, long-term solution.  In
the meantime, I think it's correct to say that evince has a release-critical
bug.

I think that the right thing for the evince maintainers to do is to upload
the package *now* with re-added mime-support handling, and worry about
dropping it only after mime-support .desktop support has proven itself -
knowing that this may not happen in time for the wheezy release.

(And if you disagree, well, it's an RC bug... so someone can upload an NMU
for it...)

> If the converter solution turns out to be too buggy or requires larger
> changes, we have a simple contigency plan, i.e. just drop the converter
> again.

> I would really appreciate if we could try to fix this *whole* issue for
> good for *wheezy*. Re-adding the mime file in evince can still be done
> if the proper mime-support fix has not been done in say a month or two.

>From the discussion so far, there are two issues that in the release
managers' position, I would be concerned about seeing addressed before
endorsing this as a solution for wheezy.

 - The .desktop format does not include an equivalent to the mailcap
   'priority' field; it's not clear what the expected / desirable handling
   is when multiple packages provide .desktop files for the same mime type. 
   The documented default priority is '5', which is probably a reasonable
   starting point, but there's still a loss of expressiveness that seems to
   require an extension of the .desktop file format (especially since
   priority values are meant to be per-mime-type).

 - It's not clear what the transitional behavior should be when a package
   includes both a .desktop file and a usr/lib/mime/packages file.  There's
   no reliable way to associate the contents of the two files, so this
   probably ends up with duplicated entries in /etc/mailcap, possibly with
   small variations; just from a quick look on my system, I find that the
   libreoffice .desktop and mime files use quite different program
   invocations.  This is of course exactly why we want to not maintain
   duplicate information in multiple files, but we should have a clear idea
   about which we expect to take precedence, and make sure this is
   implemented, so that users don't wind up with buggy behavior on their
   systems due to random ordering.  If this update-mime change is accepted
   for wheezy, the transition will most definitely be ongoing at release
   time, so we really ought to get this right.

But that's just my two cents; the release managers may have a different set
of concerns.  Either way, my recommendation to the GNOME maintainers is that
if you think it's important to not have to re-add the mime file to evince
for wheezy, you should participate in finding a solution to these issues and
not regard it as the mime-support maintainer's problem to fix - which I have
the impression has been the general approach up to this point.

On Sun, Jul 22, 2012 at 03:43:10PM +0100, Adam D. Barratt wrote:
> > If Steve and other members of the ctte consider such a tool as an
> > approriate way to solve this bug, would the release team also
> > acknowledge this approach or not?

> If it's the solution that the TC decide on to resolve the issue, it
> sounds like something we could work with, at least imho, from what I've
> seen so far.  I've CCed -release for any further comments, as I don't
> know how many members of the team are following -ctte and/or this bug.

Broadly speaking, I think the correct long-term solution is to first add
support to update-mime for reading both .desktop files and mime files, and
then to update policy to tell maintainers to use .desktop files instead of
mime files.  And I think it's better for Debian if we can get the first part
done prior to the wheezy release.  But I would like the release team to make
their own determination of whether the patch that's currently up for
consideration is of sufficient quality, and sufficiently safe, to be granted
a freeze exception.

> For clarity, the current proposal would be
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;filename=mime-support-desktop.patch;att=1;bug=497779
> , or something similar?

Yes. The nascent mime-support maintenance team has also committed a patch to
the repo at
,
probably best to reference the 

Bug#681687: Bug#658139: Bug#681687: Bug#658139: missing mime entry

[Josselin Mouette]

Le mercredi 18 juillet 2012 à 16:52 -0700, Russ Allbery a écrit : 
> Michael Biebl  writes:
> > On 18.07.2012 11:14, Neil McGovern wrote:
> 
> >> For info, I do not consider all packages missing a mime file to be RC
> >> buggy. I consider #658139 RC.
> 
> > And what is the reason that makes evince special and distinguishes it
> > from other packages which never shipped a mime file or no longer do?
> 
> It leads to PDF files being opened in Gimp, which you must agree is very
> surprising behavior.

This is a completely unrelated issue. Gimp opening PDFs is a bug in
gimp, not a bug in evince. Furthermore, it only happens with the XDG
system outside GNOME/KDE, not with the old MIME system, since gimp
doesn’t ship a legacy MIME file.

I’d appreciate if the release team and CTTE could avoid basing their
decisions upon such misinformed claims.

Thanks,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1342991716.24016.12.camel@tomoyo

Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal

[Chris Knadle]

On Sunday, July 22, 2012 04:35:00, Ron wrote:
> On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:
...
> > [Special thanks goes to Nicos for watching our backs here.]
> 
> Just to be clear here, because at some point Ian described Nicos as being
> "a mumble developer", and you have now declared him a "sage" ...

You've misquoted me.  I said "he's consistently given us sage technical 
advice".

> $ git log master | wc -l
> 30363
> 
> $ git log master | grep Nicos | wc -l
> 12
> 
> And all of those commits afaics relate to GUI overlay stuff for games,
> nothing at all to do with the protocol negotiation we are talking about
> here ... 

Nicos is the only one that has hinted to how the protocol negotiation works; 
being judgmental about his commits isn't going to help.  If you know more 
about how the selection algorithm works, that would be good, but I haven't yet 
heard you discuss the subject when it has come up.

> So I think I'd still rather put my trust in the the opinion
> of Thorvald about what can be made to work, than in someone who has said
> repeatedly, "Debian should just remove this, nobody cares because nobody
> uses Debian anyhow".  Which is also clearly quite incorrect, or we wouldn't
> be having this discussion at all.

I'm quite willing to discuss Thorvald's plan when he comes back.

> The current facts are:
> 
>  - The server is currently 100% broken in testing, and will remain so
>for our users for as long as this is blocked here.

The current -2 is also undistributable, so this doesn't really matter.  You'll 
see why.

I just found something out about the Opus-only client and the codec selection 
by the server.

This test involves four Mumble clients: 
  - "348" client from Wheezy (has Opus and CELT)
  - "1.2.2-6+squeeze1" client from Stable (lacks Opus)
  - "361" Windows developer snapshot (lacks Opus)
  - "349" client from Sid (has Opus only)

And the server version is again -2 from Sid.

Steps:
  1.  "361" Windows client connects (Codec CELT)
  2.  I connected the "1.2.2-6_squeeze1" client; doesn't show which
  codec is use, but it's CELT
  3.  I connect my "348" client, connection shows Codec CELT
  4.  Talk a while -- everything works
  5.  I connect the "349" client from Sid, shows Codec OPUS
  6.  All audio connections for everybody DO NOT WORK from here on.
  "348" client still shows Codec CELT.
  As long as the "349" client from Sid is connected, disconnecting
  and reconnecting any other client gets a message from the server
  "Warning: Your client doesn't support the Opus codec, you won't
   be able to talk or hear anyone.  Please upgrade to a client with
   Opus support."
  7.  Disconnect the "349" client
  Audio connections still do not work.
  8.  In order to get the audio connection to work again between the
  clients that have CELT, one of them must disconnect and then
  reconnect in order to get the server to renegotiate which codec
  is used.

This is 100% repeatable.

This means that the Opus-only client ruins the audio connection for everybody 
else that's connected, at least in this case.

From seeing this I really think releasing a client that only has the Opus 
codec available is a directly detrimental plan.

It also implies that the current version of the server seems to choose using 
Opus over everything else, regardless of whether the other clients have it.

[…]
>Then provided we have a clear public record of the people wanting
>that putting *their* own heads on the block, and taking the full
>responsibility for any fall out or required remedy -- then I have
>clean hands, and someone to point at who is completely to blame for
>an action I advised against in the event it goes Horribly wrong.

Quit the social engineering.

[…]
> The weekend here is nearly over, and I can't keep stealing time from
> my Work customers to keep discussing this in circles next week (and
> I'm sure many others here are in the same position).
> 
> The longer we draw this out, the less testing any of it is going to
> have, the less time is going to be available to fix any shortcomings
> that we haven't so far seen, and the poorer the result that we are
> ultimately going to end up with.

Since you're low on time I'll cut to the chase.
As far as I'm concerned I now think we're down to three distinct options.

   1) Fix up "348" from Wheezy so it compiles and uses the CELT
  codec library [very undesirable]
   2) Same as 1) but with embedded CELT (would need testing)
   3) drop mumble from Wheezy

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

Bug#681687: Bug#658139: Bug#681687: Bug#658139: missing mime entry

[Russ Allbery]

Josselin Mouette  writes:

> This is a completely unrelated issue. Gimp opening PDFs is a bug in
> gimp, not a bug in evince. Furthermore, it only happens with the XDG
> system outside GNOME/KDE, not with the old MIME system, since gimp
> doesn’t ship a legacy MIME file.

> I’d appreciate if the release team and CTTE could avoid basing their
> decisions upon such misinformed claims.

Yes, there was subsequent mail that clarified that, which you probably
hadn't gotten to when you sent this.

To reassure, that's not the basis by which I'm saying that it would be a
good idea for evince, in particular, to re-add the legacy MIME mapping for
application/pdf, *for wheezy*, so that we have some time to sort this out
properly.  GIMP aside, PDF opening is the most common complaint from
people who are using applications that still use the old metamail MIME
system, so adding the mapping for the most common PDF viewer on the GNOME
platform would make a lot of the user impact quietly disappear.

I completely agree (as I think I've mentioned before) that the legacy
metamail system should change or go away entirely.  I agree that requiring
every package maintainer to worry about it is not a good idea going
forward; the FDO standard is much easier for Debian to support in the long
run.  I don't think there's any real debate here on the long-term
direction.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vchfxvai@windlord.stanford.edu

Bug#681687: missing mime entry

[Russ Allbery]

Steve Langasek  writes:

>  - It's not clear what the transitional behavior should be when a package
>includes both a .desktop file and a usr/lib/mime/packages file.  There's
>no reliable way to associate the contents of the two files, so this
>probably ends up with duplicated entries in /etc/mailcap, possibly with
>small variations; just from a quick look on my system, I find that the
>libreoffice .desktop and mime files use quite different program
>invocations.  This is of course exactly why we want to not maintain
>duplicate information in multiple files, but we should have a clear idea
>about which we expect to take precedence, and make sure this is
>implemented, so that users don't wind up with buggy behavior on their
>systems due to random ordering.  If this update-mime change is accepted
>for wheezy, the transition will most definitely be ongoing at release
>time, so we really ought to get this right.

I think the mime/packages file should obviously take precedence for
programs using mailcap, since that's the target of the automated
conversion.  You always want the manually-maintained file to override the
results of any automated conversion, since that way you can work around
any bugs in the conversion (or missing features, like priority) by
providing a manually-maintained file.

> Broadly speaking, I think the correct long-term solution is to first add
> support to update-mime for reading both .desktop files and mime files,
> and then to update policy to tell maintainers to use .desktop files
> instead of mime files.  And I think it's better for Debian if we can get
> the first part done prior to the wheezy release.  But I would like the
> release team to make their own determination of whether the patch that's
> currently up for consideration is of sufficient quality, and
> sufficiently safe, to be granted a freeze exception.

This sounds right to me as well.  I think we should ensure the most
critical media types are working in both systems for the wheezy release
and then aim at removing the requirement to support update-mime for all
packages providing .desktop files for wheezy+1.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fw8jxupp@windlord.stanford.edu

Bug#681687: missing mime entry

[Charles Plessy]

> On Sun, 2012-07-22 at 15:24 +0200, Michael Biebl wrote:
> > > [...]
> > >> The new mime support maintainer team, which took over the package just a
> > >> few days ago, did ask the release team, if it would be possible to still
> > >> apply this patch for wheezy [2].
> > > [...]
> > >> [2] https://lists.debian.org/debian-release/2012/07/msg01048.html

Dear all,

about the mail discussed above: while it is addressed to Brian and Laszlo,
I made sure that the release team, the technical comitte and the evince
maintainers get a copy so that they can see that things are moving.  But
before getting Laszlo's and Brian's replies, I did not feel like making
promises.

Nevertheless, earlier in http://bugs.debian.org/658139#117, I also wrote the
following to "everybody", with the release team, the tech. comittee and the
evince maintainers copied:

> Wouldn't one of the following solutions be acceptable for you ?
> 
>  - Add the function to mime-support in Wheezy to update /etc/mailcap using
>the FreeDesktop menu entry files in /usr/share/applications via dpkg
>triggers.
> 
>  - Do this in Sid, and add back the MIME entries in evince in Wheezy as a
>temporary compromise.

To keep both possibilities open - without expressing a particular preference
for one or another - me and Laszlo are limiting ourselves to work on the
conversion from Desktop to mailcap, with exceptions limited to packaging
updates that I hope will not prevent our package to be reviewed by the release
team if the consensus is to update mime-support in Wheezy. 

We are getting ready to upload to experimental; things go a bit slowly because
time zone effects inserts some delays between our email exchanges, but on the
other hand, I think that it is a good thing as mime-support will be the first
time I work on a package of standard priority.  Also, it happens that the
previous and next week-ends I am not avaiable for Debian work, which postpones
more extensive tests on my side, but I think that an upload to experimental
would be appropriate now.  The last piece missing is that we are looking for a
mailing list address for the Maintainer field, as the trick to send messages to
the PTS do not work because it would create loops.  Or perhaps we can enhance
the PTS to not transmit messages to itself...

I intend to announce on debian-devel that the adoption has been completed after
we uploaded to experimental (Laszlo, you are of course free to do so yourself
if you are the one who uploads).  As Steve noted later in this thread, the
package is already in collab-maint, although I would like to keep an option
option just in case until we upload, that in case we find a defect in the
conversion we might reset it.

  http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723005137.ga20...@falafel.plessy.net

Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal

[Chris Knadle]

On Sunday, July 22, 2012 18:31:27, Chris Knadle wrote:
> On Sunday, July 22, 2012 04:35:00, Ron wrote:
> > On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:

[…]
> Steps:
>   1.  "361" Windows client connects (Codec CELT)
>   2.  I connected the "1.2.2-6_squeeze1" client; doesn't show which
>   codec is use, but it's CELT
>   3.  I connect my "348" client, connection shows Codec CELT
>   4.  Talk a while -- everything works
>   5.  I connect the "349" client from Sid, shows Codec OPUS
>   6.  All audio connections for everybody DO NOT WORK from here on.
>   "348" client still shows Codec CELT.
>   As long as the "349" client from Sid is connected, disconnecting
>   and reconnecting any other client gets a message from the server
>   "Warning: Your client doesn't support the Opus codec, you won't
>be able to talk or hear anyone.  Please upgrade to a client with
>Opus support."

I got curious as to which platforms supported Opus.  It just so happens my 
girlfriend is a Mac user, and also has an iPad.  [Not my thing for obvious 
reasons, but... to each their own.]

Opus support

 Windows 1.2.3a   *no*
 Windows "361" dev snapshot   *no*
 iOS 1.1  *no*
 Mac OSX 1.2.3a   *no*
 Mac OSX "409" dev snapshot   *yes*
   ("409" is brand new within the last couple of days)

Debian specifically
---
1.2.2-6+squeeze1  *no*
"348" in Wheezy   *no*
"349" in Sid  *yes, only*


So who /exactly/ can the Debian -2 version of Mumble talk to?

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.