=== dave_m is now known as dmart === neverendingo__ is now known as neverendingo === mthalmei is now known as MichiSoft [13:45] hey [13:51] quit [14:11] hello [14:12] hello [14:24] What are the preparations required for today's session : Fixing small bugs in Ubuntu === openweek7 is now known as dlightle === qwebirc39867 is now known as iEternity [15:53] date-u [15:59] qwebirc47066, that goes into your terminal.:) [16:01] and you need a space: date -u [16:01] anyway.. I missed yesterday's "classes".. so.. yeah.. I wonder about today.. :) [16:02] shiki-: the IRC logs are posted if you want to read through them, not sure if you knew that [16:03] ah yeah I'll read them on the weekend.. for now, I only have time to keep up with the today's lessons/classes [16:04] ty for the hint anyway === Amaranth_ is now known as Amaranth === marvin_ is now known as Guest4654 [16:42] Ubuntu Developer Week starting in 18 minutes [16:43] hooray [16:51] 10 min .. waiting patiently [16:52] nice [16:52] awesome :) [16:54] how do i remove the join and quit parts? [16:54] am using xchat [16:55] and I pidgin, I have the same problem [16:55] right click on the channel [16:55] and in extra alerts set hide join [16:55] syedam, got it :) thanks [16:55] sorry in settings [16:59] __ [17:00] WELCOME TO ANOTHER GREAT DAY OF UBUNTU DEVELOPER WEEK! [17:00] Thanks dholbach [17:00] thx :) [17:00] Who do we have here for "Fixing small bugs in Ubuntu"? :-) [17:00] o/ [17:00] :) [17:00] me [17:00] me [17:00] me :) [17:00] me! [17:00] i am in [17:01] o/ [17:01] me :D [17:01] Hi [17:01] :) [17:01] ayay! [17:01] hi! [17:01] me [17:01] me [17:01] :) [17:01] me [17:01] :) [17:01] me [17:01] :) [17:01] hi all [17:01] *lurks* [17:01] me 2 [17:01] me [17:01] me [17:01] o/ [17:01] howdy [17:01] me [17:01] dholbach: QUESTION: do we need karmic for that? [17:01] me [17:01] hi [17:01] sum-it: I'll answer that in a sec [17:01] +m ? [17:01] 'lo [17:02] +1 [17:02] me [17:02] :) [17:02] * freelancer317 waving [17:02] OK dear friends of Ubuntu Development, let's get the session started! [17:02] for those of you who are new to Ubuntu Developer Week - this channel is muted, so please head over to #ubuntu-classroom-chat and ask questions there [17:03] please make sure you prefix them with QUESTION: [17:03] If have problems following in English or want to ask a question in your local language, fine people in these channels might help you out: [17:03] * Catalan: #ubuntu-classroom-chat-ca [17:03] * Danish: #ubuntu-nordic-dev [17:03] * Finnish: #ubuntu-fi-devel [17:03] * German: #ubuntu-classroom-chat-de [17:03] * Spanish: #ubuntu-classroom-chat-es [17:03] * French: #u-classroom [17:04] To answer sum-it's question: no you don't necessarily need karmic for this session, but as I said yesterday, please have a look into https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases [17:04] if you're interested in developing Ubuntu it's important that you run the devel release in some form [17:04] some sane form like a virtual machine, etc. [17:04] alright my friends: quick preparations for those of you who weren't here yesterday [17:05] sudo apt-get install --no-install-recommends bzr ubuntu-dev-tools devscripts dpkg-dev cdbs [17:05] also please enable "Sources" in System -> Administration -> Software Sources -> Ubuntu Software [17:05] also please add something like this to your ~/.bashrc file: [17:05] export DEBFULLNAME='Daniel Holbach' [17:05] export DEBEMAIL='daniel.holbach@ubuntu.com' [17:05] save it and run [17:06] source ~/.bashrc [17:06] please don't use MY NAME [17:06] thanks :-) [17:06] we covered this in yesterday's session so please either read the logs or ask somebody in #ubuntu-classroom-chat to help you [17:06] ok... we want to fix simple bugs in Ubuntu [17:07] I took the liberty of choosing a few that I think we should get done :-) [17:07] please all take a look at https://bugs.launchpad.net/ubuntu/+source/edubuntu-addon-meta/+bug/404608 [17:07] it talks about a small typo in a package description [17:08] so to get the source code, please run: [17:08] apt-get source edubuntu-addon-meta [17:08] now please [17:08] cd edubuntu-addon-meta-0.12 [17:08] as explained yesterday you can find things like the package description in debian/control, so please open that file in your favourite editor [17:09] ah and there the bug is... "form" in the last line [17:09] please change it to "from" [17:09] save the file [17:09] ok... just a bit of background about debian/control: [17:10] the first stanza is always about the source package (refer to yesterday's log or to https://wiki.ubuntu.com/PackagingGuide) [17:10] the stanzas afterwards (just one in this case) describe the binary packages (the resulting .deb files) [17:10] alright, as far as we can see this should fix the bug [17:10] one thing I mentioned yesterday too is documentation [17:11] we need to document the change we just did in debian/changelog [17:11] luckily there's a nice tool in the devscripts package called dch that makes the job of editing the changelog a lot easier [17:11] so if you set up ~/.bashrc with DEBEMAIL and DEBFULLNAME and ran source ~/.bashrc please now run: [17:11] dch -i [17:12] this will create a new changelog entry and increment the version number [17:12] if you look at the entry closely, you'll see that it always starts with the source package name [17:12] then there's the version number which I'll get back to in a sec [17:12] next is the release in which we want to fix it in [17:13] the urgency is a debian-ism which we can ignore [17:13] next we have the entry which we still have to write, then our name, email and timestamp [17:14] ok, I talked about version numbers a bit yesterday [17:14] normally we'd add "ubuntu1" to indicate that we took a Debian package and modified it [17:14] in this case it's an Ubuntu only package [17:14] so instead of 12ubuntu1, we'll use 13 [17:15] now I'll put something like this as the actual changelog entry [17:15] * debian/control: replaced "form" with "from". (LP: #404608) [17:15] it's important to use a form like this (or similar)... what did I do? [17:16] - I described which file I touched [17:16] - I described what I did [17:16] - I mentioned the bug number in a special format [17:16] it's important that you provide as much information as possible [17:16] the bug report usually has all that information and enables others to revisit the bug and better understand why you did your changes [17:17] also did I use (LP: #404608) because only in the (LP: #xxxxxxxxxx) format the bug will be automatically closed on upload [17:17] alright... now save the file [17:17] now please run debuild -S [17:18] this will rebuild the source package (the .tar.gz and .dsc file) [17:18] it might ask you for your gpg key, but it's not necessary to sign it [17:18] now if you [17:18] cd .. [17:18] you should see edubuntu-addon-meta_0.12.dsc edubuntu-addon-meta_0.12.tar.gz edubuntu-addon-meta_0.13.dsc edubuntu-addon-meta_0.13.tar.gz [17:18] (and a few other files) [17:19] which means we successfully rebuilt the source package with our changes [17:19] QUESTION : why shouldnt we use debian/rules here to build the .deb again? [17:19] arvind_khadri: for this exercise we don't need to build the .deb and you might want to take a look at pbuilder for building packages (https://wiki.ubuntu.com/PbuilderHowto) [17:20] generally you're right though... if you want to fix a bug, you definitely need to test it too [17:20] now it'd be a bit much for this session [17:20] QUESTION: how do we know it's an Ubunty only package [17:20] bananeweizen: edubuntu should be a hint in this case, generally it's a bit harder to tell [17:21] https://packages.debian.org/src: should find the debian package if available [17:21] QUESTION: i did the debuild -S but it failed: clearsign failed: secret key not available, what do i do there? [17:21] noiz777: normally you'd sign a source package so you can upload it to a PPA for example [17:21] for this exercise it's not necessary [17:21] alright [17:21] now please run [17:22] debdiff edubuntu-addon-meta_0.12.dsc edubuntu-addon-meta_0.13.dsc [17:22] this will show you the diff between the old and the new version [17:22] if you run [17:22] debdiff edubuntu-addon-meta_0.12.dsc edubuntu-addon-meta_0.13.dsc > edubuntu-addon-meta.fix [17:22] it will give you a nice file to attach to the bug report [17:22] (remember: test it first :-)) [17:22] I'll talk a bit about sponsoring / patch review later on [17:23] so you know how to get your good fixes reviewed and included [17:23] first bug fixed :-) [17:23] ok... up next is https://bugs.launchpad.net/ubuntu/+source/qutim/+bug/346528 [17:23] please run: [17:23] apt-get source qutim [17:24] when I prepared the session the bug was still under app-install-data-ubuntu - it took me a bit to realise that the app-install-data is retrieved from lots of .desktop files from various packages [17:25] so if we fix it in qutim now, it should get fixed in the app-install-data too (for "Add/Remove...") [17:25] QUESTION: I obtained this: gpg: Signature made Thu Mar 19 18:05:37 2009 CET using DSA key ID 92742B33 [17:25] gpg: Can't check signature: public key not found [17:25] what does it mean? [17:25] EagleScreen: it means that the package was originally signed by somebody whose public key you don't have in your keyring - that's safe to ignore [17:25] alright [17:26] cd qutim-0.1 [17:26] grep -ri massanger * [17:26] this will search for "massanger" in all files, ignoring if it's upper case or lower case [17:26] seems like we have two files to fix [17:26] debian/qutim.desktop:GenericName=Instant Massanger [17:26] debian/qutim.1:qutIM \- Qt Instant Massanger [17:27] one of them is the .desktop file (that creates the menu entry) which is mentioned in the bug report [17:27] and also there's the manpage [17:28] now please run: [17:28] sed -i 's/Massanger/Messenger/g' debian/qutim.desktop [17:28] sed -i 's/Massanger/Messenger/g' debian/qutim.1 [17:28] this will replace Massanger with Messenger in both files [17:29] ok [17:29] now let's document our changes [17:29] please run [17:29] dch -i [17:30] 0.1-0ubuntu2 should be fine [17:30] and as a description of what we did, I chose [17:30] * debian/qutim.desktop, debian/qutim.1: replaced "Massanger" with [17:30] "Messenger" (LP: #346528) [17:30] (it's good practise to wrap lines at 80 characters) [17:31] bug number two fixed too :-) [17:31] QUESTION: isn't typo fixed a better discription in this case ? [17:31] roxan: sure, you can do that too - I usually prefer to explicitly mention what was wrong and how I fixed it :) [17:32] alright... let's talk a bit about sponsoring and patch review [17:33] once you have a nice patch, you obviously attach it to the bug report so people can check it out [17:33] but for it to be included in Ubuntu (if you can't upload source packages yourself yet), you need to subscribe the reviewers team [17:33] https://wiki.ubuntu.com/SponsorshipProcess explains the process in detail [17:34] essentially you subscribe ubuntu-main-sponsors for packages in main or restricted [17:34] and subscribe ubuntu-universe-sponsors for packages in universe or multiverse [17:34] they'll give you feedback and upload the patch once it's ok [17:35] QUESTION: I have a build problem: http://pastebin.ca/1550481 [17:35] EagleScreen: try installing qmake & qmake-dev [17:35] ^ for those of you wondering why debuild -S doesn't work in the case of qutim [17:35] thanks rugby471 [17:36] ok... let's move on to our third bug :) [17:36] some questions first [17:36] QUESTION: sometimes debdiffs take quite a while to be sponsored, what are the ways that I can make sure it get's uploaded as fast as it can? [17:36] rugby471: make sure the patch is tip top tested and documented very very well [17:36] so reviewers don't have to go into a very long feedback loop [17:36] usually you can ask in #ubuntu-devel or #ubuntu-motu too to get some help [17:37] QUESTION: can you find out using apt which repository a package comes from? [17:37] apt-cache showsrc qutim | grep ^Dir [17:37] QUESTION: When I want to submit a fix, what do I submit? The debdiff file only? [17:38] AntoineLeclair: yes in cases where you just submit a simple fix, yes [17:38] again https://wiki.ubuntu.com/SponsorshipProcess has more info on the topic [17:38] ok, our third bug is: [17:38] https://bugs.launchpad.net/ubuntu/+source/quickly/+bug/422212 [17:38] for those of you who attended yesterday's session, you will know what it is about [17:39] also you'll see that Markus Korn filed the bug after the session because he was interested in it :-) [17:40] in most cases you can safely use the "apt-get source" command to obtain the source [17:40] as I know that quickly is maintained in Launchpad's Code hosting (be sure to visit the session later this week!), we'll get the latest trunk of quickly and see if it needs fixing there [17:41] please run [17:41] bzr branch lp:quickly [17:41] this will get the latest trunk of quickly [17:41] this might take a little bit as it gets the whole history of quickly and its development [17:41] once it's done, please [17:41] cd quickly [17:41] grep -ri arborting * [17:42] which... again ... will search in all directories and check for upper and lower case alike [17:42] I get the following output: [17:42] bin/quickly: print _("Arborting.") [17:42] bin/quickly: print _("Arborting.") [17:42] quickly/tools.py: print _("Arborting.") [17:42] so three occurences we need to fix [17:43] these commands should get you there: [17:43] sed -i 's/Arborting/Aborting/g' bin/quickly [17:43] sed -i 's/Arborting/Aborting/g' quickly/tools.py [17:43] I don't have enough time to go into the use of the sed command, but "-i" means "replace in place" (so modify the file) [17:44] and the last "/g" means "fix all occurrences [17:44] QUESTION : What is a trunk exactly ? [17:44] Johan1: trunk is the development focus... usually projects use various branches in which small features or bugs are developed indepently of each other [17:45] once they're deemed ready, they're merged into 'trunk' [17:45] ... which gets released every now and then when it seems to make sense [17:45] software projects often work a bit differently because of how they are set up [17:45] in this case we want trunk [17:46] alright [17:46] once that's done, you can run [17:46] bzr diff [17:46] to have another look at your changes again [17:46] instead of documenting in debian/changelog, I'll show you something else this time [17:47] please run bzr commit --fixes lp:422212 -m "changed 'Arborting.' to 'Aborting.'" [17:48] this will commit the change (locally) and add the log message "changed 'Arborting.' to 'Aborting.'" to the revision history [17:48] you will be able to see it this way: bzr log | head [17:48] the other great thing is that when you push the change to launchpad, it will automatically link your branch to the bug report [17:49] http://bazaar-vcs.org/Documentation has more information on the topic [17:49] let's try to see if we manage to fix another bug: [17:49] https://bugs.launchpad.net/ubuntu/+source/qemulator/+bug/348172 [17:50] another nice typo [17:50] this time in the qemulator package [17:50] apt-get source qemulator [17:50] QUESTION: bzr log | head shows wrongly my e-mail, any thing similar to DEBEMAIL var? [17:50] EagleScreen: you're right... try bzr whoami [17:51] the qemulator case is a bit different [17:51] cd qemulator-0.5/; grep -ri snpashot * [17:52] will show you a few occurences [17:52] some in binary files (which we can't fix) - they are translation files [17:53] but before we go ahead and change Qemulator.pot and usr/local/lib/qemulator/qemulator.glade I need to explain something [17:53] in our qutim and edubuntu-addon-something case we edited files in the debian/ directory [17:53] these are files supplied by us (or other Ubuntu/Debian maintainers) [17:54] in the case of quickly we fixed it in trunk (so where the upstream developers work) [17:54] yesterday I talked a bit about how we make use of a .orig.tar.gz (that contains the source code that we get from the upstream software authors and which we don't change) [17:54] we merely add the "packaging" in the debian/ directory [17:55] so some maintainers decide to store patches that fix something in the source code of upstreams in debian/patches/ [17:55] if you [17:55] ls debian/patches [17:55] you'll find there's already a patch [17:56] https://wiki.ubuntu.com/PackagingGuide/PatchSystems goes into more detail about all the "patch systems" that maintainers use [17:56] we have 4 minutes left, so let's make it quick [17:56] run [17:56] what-patch [17:56] (from the ubuntu-dev-tools package) [17:56] and it'll tell you that the patch system is CDBS [17:56] so please run [17:56] cdbs-edit-patch fix-snapshot-typo [17:57] this will fire up a "sub shell" in which we fix the issue now [17:57] now please run [17:57] sed -i 's/snpashot/snapshot/g' Qemulator.pot usr/local/lib/qemulator/qemulator.glade [17:57] this should fix the issue in both places [17:57] now please hit Ctrl-D (or type 'exit') [17:58] if you now look at ls debian/patches/ [17:58] you'll see our patch file [17:58] now we'd just do dch -i again to document the change we just did [17:58] we'd say something like [17:59] * debian/patches/fix-snapshot-typo.patch: replace 'snpashot' with 'snapshot'. (LP: #348172) [17:59] done :-) [17:59] QUESTION: What's the best way of finding these 'easy' bugs that newbies stand a chance of being able to fix? [17:59] plumstead21: great one! [17:59] a few people wrote harvest which is supposed to find those low-hanging fruit [17:59] its current home is http://daniel.holba.ch/harvest [17:59] it's not very pretty, so some of us are working on https://wiki.ubuntu.com/Harvest/NewUI [17:59] if you're a web developer PLEASE help out! [18:00] dholbach at ubuntu dot com [18:00] thanks a lot everybody! [18:00] thanks dholbach :) [18:00] and please check out #ubuntu-motu for more help [18:00] thanks dholbach! [18:00] thanks. great talk [18:00] https://wiki.ubuntu.com/MOTU/GettingStarted too [18:00] thanks :) [18:00] thanks! [18:00] t [18:00] thanks! [18:00] thx dholbach [18:01] Thank You [18:01] <^arky^> thanks dholbach , another great session [18:01] well done [18:01] Next session : Kernel Triaging and Debugging [18:01] next up is Leann Ogasawara who will help us dive into Kernel Triaging and Debugging! [18:01] great class!!! [18:01] Hi Everyone! Welcome :) [18:01] * iulian waves [18:01] hii [18:01] Hello [18:01] My name is Leann Ogasawara and I help manage the Ubuntu Kernel Team's incoming and existing bugs against the kernel. [18:01] hi ogasawara [18:02] Having to deal with such a large volume of bugs is always a huge challenge for us. [18:02] note: chat and questions please in #ubuntu-classroom-chat [18:02] I thought this session would be a good opportunity to share some best practices I've learned along the way for triaging kernel bugs as well as share some information for helping debug issues. [18:02] We're always looking for more involvement from the community to help triage kernel bugs so hopefully after today's session some of you might be interested in helping out. [18:02] Let's first start with what the role of a kernel bug triager is. [18:03] The goal for any kernel bug triager is to get a bug into a state such that a developer can immediately being working on a fix. [18:03] Remember, as a triager we are often the first point of contact for a bug reporter. [18:03] It's important that we help move a bug into a good working state as well as help educate the bug reporter to submit better bug reports in the future. [18:03] So how does that happen? [18:03] First, we help make sure Ubuntu kernel bugs are assigned to the Ubuntu linux kernel package. [18:03] http://bugs.launchpad.net/ubuntu/+source/linux [18:04] For example, if someone is experiencing a kernel oops or panic, then that's obviously a kernel bug. [18:04] If a bug reporter did not correctly file the bug against the linux kernel package, help reassign the bug and kindly remind them to report future kernel bugs against the linux kernel package. [18:04] Failing to do so may result in the bug getting overlooked. [18:04] It may be helpful to also point them at https://wiki.ubuntu.com/Bugs/FindRightPackage . [18:04] Next, we want to make sure a bug is really not a duplicate of another bug. [18:05] This is where we as kernel triagers need to be careful. [18:05] Kernel bugs are usually hardware specific. [18:05] Just because someone may be experiencing the same symptom of another bug reporter doesn't necessarily mean they have the same bug. [18:05] When in doubt, don't mark it as a duplicate and ask for a second opinion. [18:05] Additionally, if you see someone comment on a bug and they don't have the same hardware, ask them to open a new bug report and explain why. [18:06] This really helps avoid bugs becoming wildly out of control and impossible for a developer to follow, let alone fix. [18:06] Next, help make sure the title of the bug as well as the bug description is informative. [18:06] "Sounds is broken" or "Suspend fails" is not informative. [18:06] Like I mentioned above, kernel bugs are usually hardware specific. It's always best to mention the affected hardware in the title as well as the bug description. [18:07] This will again help avoid bugs becoming a mess. [18:07] If you find you have the same hardware as a bug being reported, try to reproduce the bug yourself. [18:07] t's not unheard of for hardware to become faulty. [18:07] Being able to help confirm this is or is not the result of hardware going bad is important. [18:07] Also, be sure to document the steps to reproduce if possible. [18:08] Now I know the next part is sometimes a bit controversial, but it's also best if the issue has been confirmed against the latest kernel available. [18:08] I realize this is a touchy subject for some individuals and some reporters often object to always being asked to "test the latest". [18:08] However, when you are dealing with the kernel, keep in mind there are literally thousands of commits between each release. [18:08] Then consider that each commit touches more than just one line of code and you've now hit insanity trying to isolate one fix (if it even exists) for a single bug. [18:09] Finally, one of the most important aspects of traiging kernel bugs is making sure the appropriate log information is attached. [18:09] For the kernel this means dmesg output, lspci, kernel version info, etc. [18:09] I recommend that instead of asking bug reporters to attach these files individually, have them run apport-collect. [18:09] apport-collect will automatically gather and attach general linux kernel debug information for a bug. [18:10] For example, if we wanted kernel debug info attached to pretend bug 987654, the apport-collect command would look like: [18:10] apport-collect -p linux 987654 [18:10] The nice part about this is we're only asking the bug reporter to run a single command. [18:10] There's less room for error having a bug reporter run one command versus having a bug reporter run multiple commands. [18:11] Even better than reporting a bug and running apport-collect on it, is to use ubuntu-bug to report the bug in the first place. [18:11] This will automatically file the bug against the linux kernel package and again automatically gather and attach kernel debug info to the new bug. [18:11] The command looks like the following: [18:11] ubuntu-bug -p linux [18:11] In the process of attempting to triage a bug, if you've asked a bug reporter to provide more information, be sure to set the bug's status to Incomplete. [18:12] Also be sure to subscribe yourself to a bug so that you are automatically notified when they have responded with the requested information. [18:12] Once the bug looks ready for a developer to begin working on it, set the status of the bug to Triaged and make sure the Importance is set. [18:12] Note that being able to set a bug to Triaged and also to set the Importance requires that you be a member of the Ubuntu Bug Control team in Launchpad. [18:13] To learn how to join the ubuntu-bugcontrol team, refer to https://launchpad.net/~ubuntu-bugcontrol [18:13] I'd also like to bring up one last thing to keep in mind when triaging kernel bugs . . . and that's forwarding the bug upstream. [18:13] Before a bug can be forwarded upstream, it needs to be confirmed to exist when running the upstream kernel. [18:13] The Ubuntu kernel team has started building vanilla mainline kernel builds for users to test with. [18:13] See https://wiki.ubuntu.com/KernelTeam/MainlineBuilds [18:14] If a bug exists with the upstream kernel, the bug should be forwarded upstream so that the upstream kernel developers are also aware of the issue. [18:14] Additionally, it may be discovered that the bug is fixed upstream and we should pull in the fix back into the Ubuntu kernel. [18:14] If a bug has already been reported to the upstream kernel bugzilla, http://bugzilla.kernel.org/ , we should make sure we set up an upstream bug watch from the Launchpad bug report to the upstream bug report. [18:14] See https://wiki.ubuntu.com/Bugs/Watches for more information on how to set an upstream bug watch. [18:15] That should pretty much cover the basics of kernel bug triaging. [18:15] As always, feel free to take a look at https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies for more information. [18:15] Now that we've touched on the basics, I'd like to take this opportunity to quickly mention Kernel Bug Days. [18:15]