Hi, the first round of T&S for RAs is done.
First of all, thank you all for participating in this, and thanks for squashing bugs. Survived until now have Robert Edmonds Julien Cristau Pierre Habouzit Neil McGovern (on the vacations list) This week, we go into more details. As you can see from the delays in getting new assignments to you, release team work requires a great deal of self-direction -- our goal is to equip you with the skillset you need in order to dig in to the list of RC issues on your own, and continue working when we're not looking... of course, also helping out with areas identified as critical when help is needed. So first, please continue to work on the RC bugs you already have, and select at least two RC bugs from our RC bug list and add them to your work list even if you did that already for part 1. Second, in addition to fixing *reported* RC bugs, you will often find that you need to find, report, *and* fix bugs in others' packages. One category of bugs where this may be the case is build failures. Each of you will find below assigned to you a build failure from buildd.debian.org. Your task is to analyze/reproduce the build failure, file any bugs necessary, and follow through until a fixed package reaches testing. You may of course consult the appropriate porters. There may or may not be a bug filed already on the package, though most such bugs don't offer much help in understanding the cause of the failure anyway. You should all be familiar already with the list of porter machines, http://db.debian.org/machines.cgi, and know to contact debian-admin if you need build-dependencies installed for a test build. Please have a look at the mentioned URL and try to fix 2 different build issues (from the categories Failed, Maybe-Failed or Build-Attempted). Let me know which issues you're looking at and how you will try to solve them. Robert Edmonds http://buildd.debian.org/~jeroen/status/architecture.php?a=mips Julien Cristau http://buildd.debian.org/~jeroen/status/architecture.php?a=hppa Pierre Habouzit http://buildd.debian.org/~jeroen/status/architecture.php?a=arm Neil McGovern http://buildd.debian.org/~jeroen/status/architecture.php?a=powerpc Now, we'll show you something else (example from the past): how to bring updates into testing where more packages need to travel together. Take for example cdcd | 0.6.5-4.1 | testing | source libcdaudio | 0.99.9-2.1 | testing | source audio-cd | 0.05-4 | testing | source Now, there are these updates waiting: cdcd | 0.6.6-2 | unstable | source libcdaudio | 0.99.12p2-1 | unstable | source audio-cd | 0.05-6 | unstable | source However: Package: cdcd Version: 0.6.6-2 Depends: libc6 (>= 2.3.5-1), libcdaudio1 (>= 0.99.12p2-1), libncurses5 (>= 5.4-5), libreadline5 (>= 5.1) but libcdaudio1 is only in unstable (as part of libcdaudio), whereas the testing version of cdcd depends on libdaudio0 (which is provided from the old version of libcdaudio). Now, libcdaudio cannot be updated because it breaks cdcd, and cdcd cannot be updated, because it needs the new libcdaudio. The solution is to bring both packages in together (and also audio-cd, as that also depends on it). Technically, we write: easy cdcd/0.6.6-2 libcdaudio/0.99.12p2-1 audio-cd/0.05-6 That will bring in all three versions at the same time, and compares the result after that if it's worse (regarding installability count) than it used to be before, and if not, commits is. Your last task for the next two weeks is now to find at least one set of packages, e.g. on http://bjorn.haxx.se/debian/, and send us an working hint. Please don't be disappointed if your hint doesn't work on first try - it's not that easy, but as you're now a bit more experienced, you should forward to that level. Your Release Managers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
