Re: buildd administration
Anthony Towns <email@example.com> 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
- 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
Inst. f. Biochemie der Univ. Zürich