Anthony Towns <aj@azure.humbug.org.au> wrote: > Sure, getting tetex-3.0 done would've been quicker; but it wouldn't > necessarily have been quick enough -- after all, it's not ready *now* > and there's been six months since sarge's release. And this isn't just > *you*, everyone's in a similar position.
I guess you are right... >> > You can use usertags to track bugs fairly easily. From the RC buglist, >> > the only open RC bug mentioning tetex is against gnuplot, and has had >> > a patch since it was filed four and half months ago -- that's exactly >> > the sort of thing that should be fixed far more quickly than it has been. >> There are I think 6 more; look for the strings "dvi" or "pdf" - >> unfortunately the last one also gives some xpdf code security bugs ATM. > > Sure; but again, look at the broader context: if people aren't fixing > trivial bugs like the gnuplot one, why should anyone else spend time > worrying about the harder ones? Why haven't you done the appropriate > NMU of gnuplot already, eg? Because I've already cared more about other people's packages than I should have, looking at my non-Debian workload. >> >> I (and some others) manage teTeX as a volunteer in my free time. If >> >> Debian thinks that this is not enough, it should either help us with >> >> manpower or drop teTeX and depending packages. Just ranting at how we >> >> handle the package doesn't help us, our users or the release process. >> > There're at least three aspects: one is changing the attitude from "eh, >> > whatever, we're not releasing for months anyway" to "argh, i hate bugs, >> > kill, maim, destroy", >> Do you imply that I have the first attitude, and why? > > In arguing that it's okay not to fix bugs quickly? Definitely. I'm not saying that it's okay not to fix the bugs quickly. I'm just saying that - I'm fixing as fast as I can - leaving tetex-3.0 in experimental would slow down all that even more. > Heck, why are we even talking about this without spending the time to > fix gnuplot? Hrm. One reason is that it takes ages to setup a unstable > chroot to check it builds right, and another is it takes even longer to > work out how to encode your name... Doh. :) Alternatively, you could work on checking whether our complete building toolchain runs smoothly with utf-8, submit the necessary patches, NMU if necessary, and have the policy changed that changelog and control must be in utf-8. And I know of more such jobs... :( If you are in a hurry doing an NMU, you can also use the common transcription "Kuester". Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer