[00:17] <blackshirt> hello, good morning
[00:21] <Hayate> hello,good morning
[00:22] <Hayate> is there class rom this morning?
[14:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/07/31/%23ubuntu-classroom.html following the conclusion of the session.
[14:04] <tumbleweed> Hello everyone
[14:04] <tumbleweed> Welcome to our little Debian RC bug squashing party
[14:04] <tumbleweed> glad to see there's already an audience of 2
[14:04] <tumbleweed> anyone else here? please say hi in the chat channel
[14:04] <tumbleweed> that's #ubuntu-classroom-chat, which is also the place to ask questions
[14:05] <tumbleweed> so, I'm Stefano Rivera, a Debian & Ubuntu Developer
[14:05] <tumbleweed> and I'm here to guide you through working with Debian, today
[14:05] <tumbleweed> I assume you all know that Ubuntu is derived from Debian
[14:05] <tumbleweed> in fact, about 75% of packages in Universe are entirely unmodified from Debian
[14:05] <tumbleweed> and that's a good thing
[14:06] <tumbleweed> there's no need for those packages to be modified in Ubuntu
[14:06] <tumbleweed> the vast majority of bugs that we'd encounter in them are relevant to both Debian & Ubuntu
[14:06] <tumbleweed> and it makes sense to fix them as close to the source as possible
[14:06] <tumbleweed> that means the least duplication of effort, and shares the benefit as widely as possible
[14:06] <tumbleweed> https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
[14:06] <tumbleweed> I hope at this point, you are aware of the advantages of working well with our upstream, Debian
[14:06] <tumbleweed> (and that I might have written up some of this beforehand, for pasting) :P
[14:07] <tumbleweed> so, what are we here to do today?
[14:07] <tumbleweed> Debain has frozen their next release, wheezy, and is now trying to fix all the remaining RC bugs in it
[14:07] <tumbleweed> we're going to try and help with that
[14:07] <tumbleweed> a lot of these are also relevant to Ubuntu, and it's generally in our interest for Debian to release quickly
[14:07] <tumbleweed> what's an RC bug?
[14:07] <tumbleweed> the Debian Release team has helpfully defined that for us
[14:07] <tumbleweed> http://release.debian.org/wheezy/rc_policy.txt
[14:07] <tumbleweed> how many need to still be fixed?
[14:07] <tumbleweed> far too many: http://bugs.debian.org/release-critical/
[14:07] <tumbleweed> we need to get the green line down to zero
[14:08] <tumbleweed> everyone still with me?
[14:08] <tumbleweed> what's the best way to find RC bugs?
[14:09] <tumbleweed> I suggest using this search: http://deb.li/fOvv
[14:09] <tumbleweed> that should find issues that are blocking the release of wheezy, and nobody has looked at yet
[14:09] <tumbleweed> if anyone has any more questions about that search interface, please ask me
[14:09] <tumbleweed> here's another query that may be interesting to us: http://deb.li/3Yc7n
[14:09] <tumbleweed> that will list bugs that may have been fixed in Ubuntu, but the patch hasn't been forwarded to Debian
[14:09] <tumbleweed> many of the bugs you'll see on these lists are not trivial to fix
[14:09] <tumbleweed> there's a reason that they've been open for a long time, and nobody has fixed them
[14:09] <tumbleweed> so, if you want to find something easy to work on, it's often best to look at 10 of them, and pick the easiest one
[14:09] <tumbleweed> but, of course, they all need to be fixed :)
[14:10] <tumbleweed> (or found to be not actually blocking bugs)
[14:10] <tumbleweed> how do you go about fixing these issues?
[14:10] <tumbleweed> I'm afraid there are way too many types of RC bug for me to answer that
[14:10] <tumbleweed> but we can take that on a case-by-case basis, if you point to a bug you aren't sure how to deal with, I'm sure someone can suggest the answer
[14:11] <tumbleweed> I can briefly explain the procedures
[14:11] <tumbleweed> when Debian is frozen, Debian package maintainers are strongly encouraged not to upload anything to unstable, that won't end up in the frozen release
[14:11] <tumbleweed> so, for most packages, the same version should be present in both unstable, and testing
[14:12] <tumbleweed> (if you don't know about debian testing, packages automatically migrate from unstable to testing after 10 days, if there are no issues that should stop the migration)
[14:12] <tumbleweed> but during the freeze, this is disabled
[14:12] <tumbleweed> we'll fix it in unstable, and then ask the release team to let it migrate through to testing
[14:12] <tumbleweed> this means that the fix should be as minimal as possible, as the release team will have to review it
[14:12] <tumbleweed> it should also be minimal, if we intend to NMU (non-maintainer upload) it
[14:14] <tumbleweed> the chat channel seems deathly silent, am I going way too fast?
[14:15] <tumbleweed> So:
[14:15] <tumbleweed> verify that the bug exists in wheezy (testing), and that the version is the same as unstable
[14:15] <tumbleweed> it may be so trivially obvious that it doesn't need to be verifified
[14:15] <tumbleweed> or it has enough commenters / logs to be sure it's real
[14:16] <tumbleweed> if not, you can always fire up a chroot / vm (and people around here can help you set that all up)
[14:16] <tumbleweed> You can see more information about the package at http://packages.qa.debian.org/$PACKAGENAME
[14:16] <tumbleweed> (when I say $packagename in this talk, I mean source package)
[14:16] <tumbleweed> or run rmadison -u debian $package
[14:17] <tumbleweed> pull-debian-source $package
[14:17] <tumbleweed> should get you the current source
[14:17] <tumbleweed> then you get to fix it (that's the easy bit, right? :)
[14:17] <tumbleweed> test-build against sid (unstable)
[14:17] <tumbleweed> generate a debdiff, and attach it to the bug, tagging the bug +patch
[14:17] <tumbleweed> has anyone here never used debian's bugtracker before?
[14:18] <tumbleweed> (it's probably very different to anything you are used to, so I can give you a crash course in it)
[14:20] <tumbleweed> it's worth noting that debbugs recently gained a new feature. You can now tag a bug +patch by making the first line of your e-mail
[14:20] <tumbleweed> Tags: +patch
[14:20] <tumbleweed> and then a blank line
[14:21] <tumbleweed> (in other words, all e-mail to debbugs can now take pseudo-headers)
[14:21] <tumbleweed> no need no cc control@bugs.debian.org
[14:23] <tumbleweed> right. So. Once you've attached a patch to a bug and tagged it patch
[14:23] <tumbleweed> Chances are a Debian Developer who's looking at RC bugs will notice it and sponsor it, fairly quickly.
[14:23] <tumbleweed> But you can also ask for sponsorship. Usually, #debian-mentors on irc.debian.org is a good place.
[14:23] <tumbleweed> #ubuntu-motu / #ubuntu-devel would work too (be clear that it's a debian bug that you are looking for a sponsor for)
[14:23] <tumbleweed> and today, you can raise it in the classroom chat channel
[14:24] <tumbleweed> ok, that's everything I intended to cover in classroom style
[14:24] <tumbleweed> now, I'm entirely open to questions
[14:33] <ClassBot> Rcart asked: Fixed bugs are automatically removed from those lists?
[14:33] <tumbleweed> yes
[14:34] <tumbleweed> the RC bug search like I gave you doesn't ignore bugs which arceh marked as done
[14:34] <tumbleweed> *are
[14:34] <tumbleweed> (which is the traditional way to mark a bug as fixed)
[14:34] <tumbleweed> but instead relies on debbugs (the debian bugtracking system)'s version tracking feature
[14:35] <tumbleweed> it knows which version of a package a bug was found in, and wwhich in was fixed in
[14:35] <tumbleweed> (when people close bugs in the changelog, that is)
[14:36] <tumbleweed> you asked about logkeys
[14:36] <tumbleweed> $ rmadison -u debian logkeys logkeys | 0.1.0-1  | squeeze | source, amd64, armel, i386, ia64, mips, mipsel, powerpc, sparc logkeys | 0.1.0-1  | wheezy  | source, amd64, armel, i386, ia64, mips, mipsel, powerpc, sparc logkeys | 0.1.0-1  | sid     | source, mips, mipsel logkeys | 0.1.1a-3 | sid     | source, amd64, armel, armhf, i386, ia64, powerpc, sparc
[14:36] <tumbleweed> erk, that wasn't pretty
[14:36] <tumbleweed> http://packages.qa.debian.org/l/logkeys.html
[14:37] <tumbleweed> you can see the fixed version hasn't entered testing yet
[14:37] <tumbleweed> because it didn't build on some architectures
[14:38] <tumbleweed> https://buildd.debian.org/status/logs.php?pkg=logkeys
[14:38] <tumbleweed> it successfully built on some architectures in the past, that it isn't building on now
[14:38] <tumbleweed> so those old versions are holding the new ones back
[14:43] <ClassBot> chilicuil asked: all the rc bugs must be corrected in debian?, what about unity or some projects specific to ubuntu, can they be defined as RC?, if so, how can I find them?
[14:43] <tumbleweed> chilicuil: to answer the example first: unity isn't in Debian
[14:44] <tumbleweed> (although hopefully it will be, at same point)
[14:44] <tumbleweed> Ubuntu has its own definition of RC bugs
[14:44] <tumbleweed> but Ubuntu doesn't require all RC bugs to be fixed before releasing
[14:44] <tumbleweed> we do a time-based release, where we release on a particular day
[14:45] <tumbleweed> and do our best to fix all the show-stopper bugs before that date
[14:45] <tumbleweed> we'd love to fix all our RC bugs, but one can't do that and regular, timely, releases
[14:46] <tumbleweed> https://wiki.ubuntu.com/Bugs/Importance describes Ubuntu's bug importance levels
[14:47] <tumbleweed> but our RC bugs are usually bugs that are noticed during ISO testing. i.e. bugs that actually block releasing
[14:47] <tumbleweed> that and bugs that are critical enough that the release team is informed of them
[14:50] <ClassBot> UndiFineD asked: looking at the number of rc-bugs, the number seems to decrease, how many are caused by kfreebsd and can i easily check that ?
[14:50] <ClassBot> There are 10 minutes remaining in the current session.
[14:52] <tumbleweed> so, yes, Debian is releasing with kfreebsd as supported architectures, in wheezy
[14:52] <tumbleweed> http://release.debian.org/wheezy/arch_qualify.html
[14:53] <tumbleweed> the number decreases, because people put attention into fixing them
[14:53] <tumbleweed> (although, it generally climbs a bit after the freeze, as people notice bugs in all the last-minute uploads)
[14:54] <tumbleweed> freezing testing means developers aren't introducing new bugs (hopefully), and effort should mostly go into RC bug fixing
[14:55] <tumbleweed> as to bugs caused by kfreebsd. I see a bunch of usertags that may be helpful in finding them
[14:55] <tumbleweed> http://udd.debian.org/cgi-bin/bts-usertags.cgi?user=&tag=*kfreebsd*
[14:55] <tumbleweed> of course, not all of those will be RC
[14:55] <ClassBot> There are 5 minutes remaining in the current session.
[14:56] <tumbleweed> and many architecture-specific RC bugs can be solved by removing the binary packages from that architecture
[14:56] <tumbleweed> (assuming they have no significant reverse dependencies)
[14:56] <ClassBot> Rcart asked: can we use ubuntu's procedure to fix bugs in Debian? Like setting up an instance of Debian in pbuilder? I mean, fixing Debian bugs from Ubuntu?
[14:57] <tumbleweed> yes, you can easily set up a debian chroot in pbuilder
[14:57] <tumbleweed> pbuilder-dist create sid
[14:57] <tumbleweed> should work
[14:58] <tumbleweed> Debian and Ubuntu are incredibly similar, under the hood
[15:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/07/31/%23ubuntu-classroom.html
[15:01] <tumbleweed> I guess that's it everyone. Thanks