[Cced the victi^Wpotential assistents this time - next time get it from the list :]
Hi guys, Your first assignment, should you choose to accept it, is to solve the following bugs: Marc 'HE' Brockschmidt 354093 [ ] libnss-ldap: getent segfault when reading large uid-/gidNumbers 356394 [ ] mc-foo: exception on startup 353134 [ ] libtest-builder-tester-perl: FTBFS with perl 5.8.8 Andrea Mennucci 354650 [ H ] lightspeed: segfault at start up on amd64 340538 [ ] apache2: includes non-free and possibly undistributable files 346115 [ ] lineak-xosdplugin: doesn't print onscreen messages anymore Guido Trotter 346354 [ ] distribution of this package is likely a GPL violation 351981 [ ] muine: Fails to start 352926 [ ] System crash while prelinking causes data loss Adeodato Simó 266407 [ ] [NONFREE-DOC:GFDL] reference manual is licensed under GFDL 321102 [ ] kmail looses mails 339749 [ ] maildrop: kills processes it shouldn't Jeroen van Wolffelaar 345823 [ ] apt: Key error at year turnover resembles security problem, and may represent one 346164 [ ] FTBFS on arm, hppa, sparc 276962 [ ] harbour: FTBFS on amd64: harbour hangs on run. Luk Claes 335473 [ ] cricket: Completely broken with latest rrdtool package 1.2.11-0.4 309932 [ ] boot-admin should not be in unstable 311188 [ ] debian-edu-config: Messes "programmatically" with conffiles of other packages Bill Allombert 320375 [ ] conquest-gl: fail to start (Assertion `window->Window.VisualInfo != ((void *)0)' failed.) 350407 [ ] lessdisks-terminal: modifies /etc/kernel-img.conf in postinst 331661 [ ] extensions/*.jar ship without source code, shipped jar files are installed "Solve" can mean many things. The best solution is a fixed package being uploaded to the archive that satisfies the submitter, the maintainer, and everyone else. Alternatively, it might be that it's a non-bug or has already been fixed, and you can satisfy everyone that that's the case. Another option is that the bug might be unfixable, and the package may need to be removed from testing or unstable or both. In some cases the bug may be specific to woody or sarge. In some cases the submitter might not be contactable to verify the problem's solved. By this time in two weeks, you should aim for each of the bugs under your name to have moved forward as far as possible, ideally closed. If it's not clear what the problem is, find out. If it's not clear what would fix it, work it out. If the fix isn't entirely clear, spell it out. If it's fixed upstream, point that out. Prepare a patch if there isn't already one. Do an NMU if appropriate. You get the idea. You might want to consider spending a few minutes looking at each bug now, and, if necessary, ask for any more information that's needed from the submitter, so that you have the information when you've got some more time to spend on it later. Once you've done as much as you're able for the two weeks, make sure the bug report includes all the up to date information, then reply to this mail (to [email protected]) with a brief summary of what's happened and what the next step (if any) is. If you think the package requires removal from testing (or the bug can be fixed by other means from the release team), feel free to forward the proposed fix as soon as possible to the release team. If the above is just too easy, for extra credit you can take on some of the other older bugs from the RC bug list. If you do, include those in your mail next week. If you're not able to fix a bug, ask for help or do as much as you can, then leave it; don't get in over your head, or, worse, upload an NMU that's broken or doesn't completely fix the problem. Of course, you are allowed to use all resources available for bug fixing; this excludes the help of the current release team members for obvious reasons. :) So, have fun, Your Release Managers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
