On Fri, Dec 09, 2016 at 04:00:04PM -0500, Sam Hartman wrote:
>
> First, upgrading to new upstream is presumed good, not always good.
> My concern with Ron's position is mostly that he wants the people
> requesting a new upstream to justify that rather than wanting the htags
> users to justify not
ned this package, and he has my blessing and sympathy
for being responsible for whatever happens with it from here. I haven't
filed a WNPP bug for that as we don't need to offer it to someone random.
Wookey: if you want the complete git history, right back to the very first
package in 1999, you can grab it from the Vcs-Git URL in the sid package.
I'm not going to go Full Bruce and rage delete it, but eventually I should
decruft alioth and remove it from there, so if you want it you should
probably clone it somewhere that works for you.
Good luck!
Ron
On Fri, Dec 09, 2016 at 05:13:48PM +0100, Didier 'OdyX' Raboud wrote:
>
> What I see as fundamental difference here was your use of #196762 as a single
> point of contact for the problem you were facing with groff 1.19, in which
> you
> explained, commented and followed up on what the problem w
On Fri, Dec 09, 2016 at 11:58:02AM +0100, Didier 'OdyX' Raboud wrote:
> Le vendredi, 9 décembre 2016, 04.55:20 h CET Ron a écrit :
> > > If you haven't yet, I urge you to use our standard interface to report
> > > such
> > > bugs; please make sure issu
On Thu, Dec 08, 2016 at 06:24:32PM +0100, Didier 'OdyX' Raboud wrote:
> Le jeudi, 8 décembre 2016, 18.14:12 h CET Tollef Fog Heen a écrit :
> > Using open like in the code snippet above is pretty much inexcusable in
> > this day and age.
>
> Fair enough, thank
lution.
Now I feel like goldilocks, first I'm bad because I didn't respond enough,
now I'm bad because I respond too much.
But apparently, I should have actually said just a little more in this
one too, to explain to you how perl works :) So I'll do that now!
> Le jeu
On Thu, Dec 08, 2016 at 03:41:14PM +0100, Vincent Bernat wrote:
> ❦ 9 décembre 2016 00:32 +1030, Ron :
>
> > How much am I supposed to hound you when you give a non-answer?
>
> Maybe assume good faith and tell me that the answer doesn't fit you?
You said you weren&#x
On Thu, Dec 08, 2016 at 02:39:44PM +0100, Vincent Bernat wrote:
> ❦ 8 décembre 2016 23:32 +1030, Ron :
>
> > One is whatever it is that the third-party ggtags wrapper needs, which
> > aiui is what Vincent and Punit are most annoyed about. But I don't
> > use em
On Mon, Dec 05, 2016 at 10:13:05PM +0100, Philip Hands wrote:
> Ron writes:
>
> > I'm not insisting that's what we should do. But it's certainly an
> > option, and it dodges the bullet of having to say "Sucks to be you"
> > without any notic
Hi Sam,
On Wed, Nov 30, 2016 at 11:39:08AM -0500, Sam Hartman wrote:
> >>>>> "Ron" == Ron writes:
>
> Ron> Hi OdyX,
>
> Ron> On Wed, Nov 16, 2016 at 03:23:47PM +0100, Didier 'OdyX' Raboud wrote:
> >> Hi there,
&
le who don't use htags are currently making.
"You're on the wrong side of a version number" isn't a very compelling
or satisfying or technically astute rationale, if that's all it boils
down to. I'd like to have something a bit more substantial and fair
than that to offer the people who'd get burned without notice by this.
Cheers,
Ron
reported.
It should be fixed in sid now though.
Good bug reports are the foundation for getting things fixed, so
thanks for setting a good example there.
Cheers,
Ron
On Tue, Nov 08, 2016 at 04:56:40PM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to
> package a new upstream version"):
> > I made this timeline to show how Ron thinks it is appropriate to deal
> > with
On Tue, Nov 08, 2016 at 02:52:29PM +, Ian Jackson wrote:
> Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new
> upstream version"):
> > I think you missed the bit about "comprehending the problem and building
> > consensus o
On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote:
> On Nov 07 2016, Ron wrote:
>
> > I've taken the time to repeat this all again now, because regardless
> > of how it got here, I actually have some faith in the new face of the
> > TC as a forum for buil
On Sun, Nov 06, 2016 at 05:09:56PM -0800, Nikolaus Rath wrote:
> On Nov 06 2016, Ron wrote:
> > On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote:
> >> Ron writes:
> >> >
> >> > I can try to clarify that if there's a question in your mind
On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote:
> Ron writes:
> >
> > I can try to clarify that if there's a question in your mind that
> > you don't think I touched on there.
>
> The question that remains is what you actually intend to do.
No
most
> reasonable
> outcome, given the current situation. This means that global gets updated to
> the
> latest version, with a NEWS message stating that htags functionality has been
> removed and that users that care about htags should install global5 instead.
>
> Ron, you ha
On Tue, Oct 25, 2016 at 09:03:40AM +0200, Philip Hands wrote:
> Ron writes:
>
> ...
> > That's basically why "just nuke htags now" is starting to look like
> > a viable, and even sensible, option. But it's tricky to know who
> > might be upset by t
upstream isn't accepting
that yet.
But I haven't forgotten the hatemail I got for finally killing off
svgatextmode, a whole decade after its upstream declared it an
obsolete solution, when kms finally made it impossible to keep it
working - so I don't underestimate what some people might cling to.
Cheers,
Ron
ople like me -
then I don't have the spare time to entertain your senile crap.
There's a release freeze looming and all of us have important things
to do. So if you don't have anything actually useful to contribute,
then please just go away and leave this to the adults to discuss in
a mature and sensible fashion.
Thank you.
Ron
On Sun, Oct 23, 2016 at 08:48:53PM +0200, Tollef Fog Heen wrote:
> ]] Ron
>
> > I'm appalled at the status quo. My concern is that we don't make
> > that even worse with uninformed decisions. In the absence of good
> > information, sometimes the best thing to
On Sun, Oct 23, 2016 at 09:55:43AM +0200, Vincent Bernat wrote:
> ❦ 23 octobre 2016 17:19 +1030, Ron :
> > If you're saying yes to the question I put above, then what I'm asking
> > is: what real evidence can you show to back up your assertion that
> > "no
On Sat, Oct 22, 2016 at 05:41:54PM +0200, Vincent Bernat wrote:
> ❦ 22 octobre 2016 14:44 +1030, Ron :
>
> > It seems fair to assume that you aren't seriously asking them to
> > endorse the idea of chmod 777 as an acceptable interface for
> > distro software - b
and
point to that the next time someone asks "what needs to be done
to fix this?". But that's hard to do when people are just tugging
hard in some direction solely on their own self interest.
I want a good solution to this at least as much as anyone else does,
but the path of least resistance is what makes a river crooked, so if
we don't want this to end up as some sort of bug infested billabong
spreading disease to the people who use it, then we will need some
better answers than just "blindly package and upload a new upstream
version" - because the minimal work needed to do just that is not the
actual problem here.
Cheers,
Ron
On Sat, Nov 22, 2014 at 08:51:41PM +, Dimitri John Ledkov wrote:
> On 22 November 2014 at 16:21, Ron wrote:
> >
> > Dimitri wrote:
> >> Thus multiarch cross tooling is not so relevant for fresh bootstraps,
> >> and/or targeting non-debian architectures, or
hat it actually broke,
if anything, to warrant removing it, without comment or warning,
at this late stage of the Jessie release.
Ron
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141122162145.gu29...@hex.shelbyville.oz
able system where packages are changing rapidly (and because
stable deps are kind of an important thing too :)
Cheers,
Ron
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141121144342.go29...@hex.shelbyville.oz
sible belief that the old code really is safe still,
or patches to make it so. I just don't buy people telling me "pfft,
it's fine" when they haven't looked at all - after a person who had
done much of the insanely thorough testing of this code told me that
they thought
On Tue, Jul 24, 2012 at 06:25:04PM +0100, Ian Jackson wrote:
> Ron writes ("Bug#682010: [mumble] Communication failures due to CELT codec
> library removal"):
> > I understand your line of thinking there, and for 99% of the code in the
> > world, I'd be in complet
On Tue, Jul 24, 2012 at 01:17:10PM +0100, Ian Jackson wrote:
> Ron writes ("Re: Bug#682010: [mumble] Communication failures due to CELT
> codec library removal"):
> > My primary concern is with the fact we would be shipping very complicated
> > code, that only about
On Mon, Jul 23, 2012 at 02:38:19PM -0400, Chris Knadle wrote:
> On Monday, July 23, 2012 13:16:55, Ron wrote:
> > On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
> […]
> > Maybe that is true for the gamers, but when I asked I didn't get
> > any confir
f life of
wheezy, so not supporting it will just disadvantage our users,
and possibly put them right back in the situation we are presently
trying to avoid. The new server does have an opus threshold option
and once critical mass of that is triggered, clients without opus
will not be able to talk o
On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote:
> Ron writes ("Bug#682010: [mumble] Communication failures due to CELT codec
> library removal"):
> > That point is currently still true. Every existing client has the ability
> > to *decode* speex if speex
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
is the advice people are given in those cases,
by the developer who disabled the speex support ...
That was an exchange from today, which I only saw just now.
Like this wasn't complicated enough already,
Ron :/
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a sub
On Fri, Jul 20, 2012 at 02:48:07PM -0700, Don Armstrong wrote:
> I've updated the summary with the suggested changes (at the end).
>
> On Sat, 21 Jul 2012, Ron wrote:
> > I think that's roughly right. If there's anything more people need
> > clarified or answe
g to understand the background to the removal of the
> > dependency from ices2 to roaraudio.
> >
> > I have seen this:
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676541
> > and the package changelog:
> >* Stop build-depending on libroar-dev or s
questions
> ** Can speex be made to be an option?
> ** Is a convenience copy acceptable, assuming mumble is the only thing with
> it?
> ** What are the other clients that we want to make sure the mumble servers
> can communicate with?
> * Involved parties
> ** chris.kna...@co
On Fri, Jul 20, 2012 at 04:09:43PM +0100, Ian Jackson wrote:
> Ron writes ("Re: Bug#682010: re celt and mumble referred to the TC"):
> > What's left to stop us from moving forward with this again now?
>
> Also, please stop trying to bounce us into a decision and ot
On Fri, Jul 20, 2012 at 03:25:00PM +0100, Ian Jackson wrote:
> Ron writes ("Bug#682010: re celt and mumble referred to the TC"):
> > Making a binary release for windows users is bottlenecked behind Thorvald
> > too
> > right now. The problem goes something like thi
On Fri, Jul 20, 2012 at 08:49:54AM -0400, Chris Knadle wrote:
> On Friday, July 20, 2012 08:32:01, Ron wrote:
> > On Fri, Jul 20, 2012 at 08:14:48AM -0400, Chris Knadle wrote:
> > > On Friday, July 20, 2012 07:54:21, Ian Jackson wrote:
> […]
> > > > How will t
On Fri, Jul 20, 2012 at 08:14:48AM -0400, Chris Knadle wrote:
> On Friday, July 20, 2012 07:54:21, Ian Jackson wrote:
> > Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the
> TC"):
> > > On Thursday, July 19, 2012 19:07:52, Ron wrote:
> >
fore
he left, but otherwise this is about a week away from happening too.
There may be some way that people can build their own from source or
override the 'security' feature on their windows machine to install
one from someone else, but someone who actually uses windows will
probably have to a
Otherwise ... well, then I don't know what ... you'll have to
suggest a plan B all your own, because this is the best we have ...
All Thorvald asked is that people stay calm, so he can actually worry
about working on the code rather than being stressed by the drama :)
I'll ma
> single package, and we can deal with problems as they come up.
>
> Since Ron is listed as co-maintainer for mumble do you feel you have
> the authority to do this ? I imagine Ron would object, so you would
> in any case need a TC ruling to arbitrate between you.
*sigh* Why would
bers of the TC, the Project Leader, former DPLs, and
> the suchlike would be happy to help anyone who is the victim of such
> abuse. Part of our responsibility is to use our positions of
> influence to make sure that abuse does not continue.
I think I might actually have logs of the ALL
On Thu, Jul 19, 2012 at 07:39:37PM +0100, Ian Jackson wrote:
> Ron writes ("Bug#682010: #682010 re celt and mumble referred to the TC"):
> > I don't want to niggle over words here, but "chosen" would imply that
> > somebody actually exercised s
On Thu, Jul 19, 2012 at 12:55:59PM +0100, Ian Jackson wrote:
> Ron writes ("Re: #682010 re celt and mumble referred to the TC"):
> > You understand this is a fairly arbitrary 'daily' snapshot of an
> > experimental research codec, from ~2.5 years ago, that nobo
and I put in the effort
to make that as possible as it might be.
Maybe that really was a mistake. I don't mind taking full
responsibility for my mistakes - but being bullied into making
even bigger mistakes, by people who didn't understand the set
that created the problem in the fi
d opus support with a way that may not compatible with us, then
> we will be in a passive position.
Nobody is proposing that *we* do this. It has been discussed with upstream
and they are working on it. When they have something to test, then you can
begin testing it.
So far as I can see,
t in qemu/kvm guest OS.
> >
> >2) Celt, the root of our problem
> >Spice uses celt[3] for audio codec. Different celt version may use
> >different bitstream, it means that if Spice client want to correctly
> >decode audio codec from spice server, it should use the sa
problems too..
perhaps what we should do is have a debian3.0-upgrade metapackage,
which has dependancies on all the major package upgrades required
to make a smooth transition from slink.
just another 2c down the slot..
best,
Ron.
53 matches
Mail list logo
