== Dev Week -- Fixing small Ubuntu bugs -- dholbach -- Mon, Jan 25 == UTC {{{#!IRC [17:02] Alrighty... welcome back to Ubuntu Developer Week - this time it's "Fixing small bugs in Ubuntu" :-) [17:02] I picked a few small bugs and I hope a few things will be clearer: [17:03] - how to use basic tools in every day situations later on [17:03] - learn the process of fixing something, how to propose the fix to get accepted, etc. [17:03] so we're not going to cover kernel hacks, crazy C++ stuff or anything else in here :-) [17:04] ok... the first bug I want us to have a look at is: https://bugs.launchpad.net/ubuntu/+source/fsniper/+bug/486612 [17:05] if you check it out, you'll see that indeed it is a small bug, it's about a typo in the package description of fsniper [17:05] to confirm it, just run [17:05] apt-cache show fsniper [17:05] and it says this towards the end: [17:05] This packages comes with no generic rules, so you must write [17:05] them yourself. [17:05] so... we're going to fix it! [17:06] first of all, let's get the package source: [17:06] apt-get source fsniper [17:06] if you run ls you will see that it downloaded a .orig.tar.gz, a .diff.gz and a .dsc file [17:06] and that it created a directory called fsniper-1.3.1 [17:07] ok, here's how it all fits together: [17:07] < vishalrao_dsktop> QUESTION: where does apt-get source store source files? [17:07] - orig.tar.gz is the file that the upstream authors released on their website as the source code [17:07] - .diff.gz is the compressed set of changes we make to make the package build the "debian or ubuntu way" [17:08] - .dsc is just meta-data like md5sums etc [17:08] apt-get downloaded the source from the archive, checked the md5sum, untarred the .orig.tar.gz file and applied the .diff.gz changes [17:09] ok... let's fix this bug now :) [17:09] cd fsniper-1.3.1/ [17:09] cat debian/control [17:09] debian/control was added (among other things) by the Debian/Ubuntu maintainers of the package [17:10] and it describes the source and the resulting binary package (in this simple case just one binary package) [17:10] < michae> QUESTION : no fsniper dir . Normal? [17:10] the description at the bottom is what we need to fix [17:10] this call ought to fix it for us: [17:10] sed -i 's/packages/package/g' debian/control [17:11] michae: I'm sorry, I don't understand your question... can somebody help michae debug the problem in #ubuntu-classroom-chat please? [17:11] < thebwt-lernid> QUESTION: couldn't we just open our favorite editor and fix it as well? Why use sed? [17:12] thebwt-lernid: yes, that'd work too and we'll make more use of the editor in due course :) [17:12] ok... some folks said they ran into trouble because dpkg-dev was not installed - please make sure you have it [17:13] so now that we fixed the problem, we need to document the changes we did [17:13] please run [17:13] dch -i [17:13] (you need devscripts installed for that - session 1) [17:14] if you attended the first session, you will see your name and email address now, if you weren't here or did something wrong, you need to type it in manually [17:15] ok, let's go through the changelog entry one by one [17:15] the first line looks like the following over here: [17:15] fsniper (1.3.1-0ubuntu3) lucid; urgency=low [17:15] first the name of the source package, next the version, then the version of Ubuntu where we want to fix it in and an urgency setting which we can ignore for now [17:16] let's have another look at the version name [17:16] 1.3.1-0ubuntu3 means: 1.3.1 release by upstream, package was not in Ubuntu yet, 3 revisions in Ubuntu [17:17] oops, sorry make that "package was not in Debian yet" [17:17] 0.6-4 would mean: 0.6 release by upstream, 4 revisions in Debian, no changes in Ubuntu [17:17] 1.2.3-4ubuntu5 would mean: 1.2.3 as released by upstream, 4 revisions in Debian, 5 changes following changes in Ubuntu [17:17] etc. [17:18] I hope it gets clearer as we work our way through a few examples [17:18] next up is the description... dch leaves it empty for us, but I put something like this in there: [17:18] * debian/control: replaced "This packages" with "This package" (LP: #486612) [17:18] when I write a changelog entry, I usually try to: [17:18] - mention which files I changes [17:18] - mention which files I changed [17:18] < SoftwareExplorer> QUESTION:Do the numbers after ubuntu reset when debian releases a new version? [17:18] - mention what I changed [17:19] - mention where the change was discussed (bug report, mailing list post, etc.) [17:19] - and as (LP: #486612) means "Launchpad bug 4855112", in this special notation the bug will get automatically closed on upload :) [17:20] SoftwareExplorer: no, if we introduce changes in Ubuntu, we need to either manually merge our changes with Debian changes or we need to decide to drop our changes altogehter and overwrite our package with that from Debian - in the latter case, yes, the version is "reset" [17:21] https://wiki.ubuntu.com/UbuntuDevelopment/Merging has more info [17:21] < venuz> QUESTION:how do we resolve cyclic dependency? [17:21] and on Friday, 17 UTC we will have a dedicated session about that [17:21] venuz: that's a more complicated subject and nothing we can discuss in this session, can you please head to #ubuntu-devel and ask there? [17:21] ok, let's move on [17:22] < strycore74> QUESTION: Is there a way to quickly view all the changes I made in the source code while I'm writing the source code ? Should I keep an intact verison of the source to diff with my [17:22] version ? [17:22] so once you wrote something nice into the changelog entry, please save the file [17:22] and run [17:22] debuild -S [17:22] strycore74: I'm going to mention that in just a sec :) [17:23] < xteejx71> QUESTION: what is the difference between the -S and the -S -sa commands? [17:23] xteejx71: -S will build the source package, -sa is something we can ignore for now - it's just relevant if you want to upload the package somewhere (-sa will also upload the .orig.tar.gz tarball) - please refer to the debuild or dpkg-buildpackage manpage :) === swoody__ is now known as Guest6758 [17:24] please run [17:24] sudo apt-get install quilt [17:24] if "debuild -S" gave you an error message [17:24] and try again [17:24] thanks dbell [17:25] please let me know in #ubuntu-classroom-chat if that worked out for you :) [17:25] ok, some of you seem to have got a debsign error. we can ignore that for now. [17:26] it likely means that you either didn't set up your gpg key correctly, or you gave a different name and email address in your gpg set up and in DEBEMAIL/DEBFULLNAME in ~/.bashrc [17:26] we don't need to sign it now, so please ignore it for now :) [17:26] some of you might also need to run: [17:26] sudo apt-get install debhelper [17:26] sorry :) [17:27] thanks vishalrao_dsktop [17:27] you can run all these commands as regular user, 'sudo' should just be required for pbuilder [17:28] alright, let's crack on, please rerun "debuild -S" once you install debhelper and quilt [17:28] then please run [17:28] cd .. [17:28] now please run [17:28] debdiff fsniper_1.3.1-0ubuntu2.dsc fsniper_1.3.1-0ubuntu3.dsc > fsniper.debdiff [17:28] < mhall119|work> QUESTION: I get a gpg error saying "secret key not available" [17:29] mhall119|work: very likely whatever you have in DEBEMAIL / DEBFULLNAME in ~/.bashrc and in your gpg key set up don't match - please ignore it for now or try to debug it in #ubuntu-classroom-chat [17:30] you might also need the patchutils package, so please install that too [17:30] ok............ [17:31] once you have all that sorted out, please copy the content of fsniper.debdiff to http://paste.ubuntu.com [17:31] and say something like MY-PATCH: http://paste.ubuntu.com/...... in #ubuntu-classroom-chat and I'll take a look at it [17:32] if we did everything right, we might all have a nice patch ready now :) [17:32] xteejx71: http://paste.ubuntu.com/362732/ looks great [17:33] alastair: http://paste.ubuntu.com/362734/ looks good, just replace "karmic" with "lucid", karmic is release already - apart from that: great work! [17:33] strycore74: http://paste.ubuntu.com/362731/ looks great [17:34] vishalrao_dsktop: http://paste.ubuntu.com/362735/ looks great (just karmic -> lucid) [17:35] netritious: http://pastebin.com/f28cffa07 looks good (karmic -> lucid too and maybe your realname :-)) [17:35] < Ravm> QUESTION: So, if I made a mistake, do I just alter the patch, or redo the sequence? [17:35] rmunn: http://paste.ubuntu.com/362740/ looks good, karmic->lucid too and I'd mention which file you changed :) [17:36] Ravm: re-do the sequence in almost all circumstances [17:36] Ravm: it's very easy to botch up the patch file and whoever is reviewing the patch later on can't apply it [17:37] I'm proud of you guys! Awesome work! First patch done! YEEEEEEHAW! :-) [17:37] ok, let's do another one... we have 23 minutes left :-D [17:37] < dbell> QUESTION: do we need to go through the whole process again to change karmic to lucid, do we need to run lucid, or can we just edit the debdiff and change it there? [17:37] dbell: just update karmic to lucid, then run "debuild -S" again [17:38] (and run "debdiff ...") [17:38] the next bug I found it a bit more complicated :-) [17:38] < mhall119|work> QUESTION you wouldn't have to re-do the dch part unless it's been uploaded, right? [17:38] mhall119|work: yes, you'd just run edit debian/changelog instead [17:39] ok... here's the next bug: https://bugs.launchpad.net/ubuntu/+source/meld/+bug/417369 [17:39] somebody requests the meld package to be updated [17:39] < Navaneeth> QUESTION: Is this the same procedure to fix defects even if they are in code (C or C++)? If yes, Once they are fixed, will it goto original projects source repository? [17:40] Navaneeth: the procedure can change somewhat, and the change needs to be forwarded to upstream authors by you manually [17:40] ok... let's fix up meld now [17:41] the bug requests 1.3.1 [17:41] in lucid I get the following: [17:41] daniel@miyazaki:~$ apt-cache showsrc meld | grep ^V [17:41] Version: 1.3.0-2 [17:41] daniel@miyazaki:~$ [17:41] < xteejx71> QUESTION: Should we now remove all the old build files for hello and fsniper? [17:41] xteejx71: as you like it [17:41] ok, so we indeed have to fix meld [17:41] apt-get source meld [17:41] cd meld-1.3.0 [17:42] < lbrinkma> QESTION: Should this upgrade performed upstream(debian)? [17:42] now you need devscripts installed [17:42] lbrinkma: in theory, yes, as much in Debian as possible [17:42] lbrinkma: sometimes you will find that Debian is in a freeze period or that we need a fix urgently - in that case we upload to Ubuntu directly [17:42] or if the Debian maintainer is on holidays, etc :) [17:43] now please run: [17:43] uscan [17:43] if you run [17:43] ls .. [17:43] < xteejx71> QUESTION: Does it make a difference if we update an Ubuntu package, since Ubuntu and Debian sync each other right? [17:43] it will show you that it downloaded meld-1.3.1.tar.gz from the upstream website - cool, eh? [17:44] (debian/watch does thaT) [17:44] xteejx71: check out https://wiki.ubuntu.com/SyncRequestProcess and https://wiki.ubuntu.com/UbuntuDevelopment/Merging - Jorge and I will cover that explicitly in Adopt-An-Upstream :) [17:45] next we use that tarball to "update the package" [17:45] please run [17:45] uupdate ../meld_1.3.1.orig.tar.gz [17:46] what it does it the following: [17:46] - untar the mentioned tarball [17:46] - apply the current set of changes (1.3.0 .diff.gz) [17:46] - add a template changelog entry [17:46] nice, eh? :-) [17:46] now please: [17:46] cd ../ [17:46] diff -u meld-1.3.{0,1}/INSTALL [17:47] what that command does is show you the differences between the INSTALL file (a document provided by upstream) between the two releases [17:48] the important information we filter out now is: [17:48] -## * pygtk-2.6.0 [17:48] -## * gnome-python-2.6.0 [17:48] +## * pygtk-2.8.0 [17:48] +## * gnome-python-2.8.0 [17:48] (it tells us that new versions of gnome-python and pygtk are required) [17:48] if you intend to take care of a package update, be sure to check what changed internally so your users aren't confused afterwards :-) [17:48] now [17:48] cd meld-1.3.1 [17:48] and edit debian/control.in [17:49] (in this case it's debian/control.in and not debian/control because of specialties in the Debian GNOME team) [17:50] I'll now change this line python-gtk2 (>= 2.4), to use 2.8 [17:50] also I'll update python-gnome2, to have (>= 2.8) [17:50] now save the file [17:50] and run [17:50] rm debian/patches/pythonpath.patch [17:51] (this is a patch that is not required any more... I'm just saying it now as we only have 9 minutes left - I tested this before :-)) [17:52] now please edit debian/changelog and document your changes :) === mike is now known as Guest50550 [17:53] now please run [17:53] update-maintainer [17:53] (from the ubuntu-dev-tools package) [17:53] rationale: the Debian maintainers asked us to set an ubuntu.com email address as the Maintainer whenever we introduce a change over Debian so they don't get email for it :-) [17:53] https://wiki.ubuntu.com/DebianMaintainerField [17:54] also please edit debian/rules [17:54] and remove the following line [17:54] DEB_INSTALL_CHANGELOGS_ALL += changelog [17:54] save the file [17:54] and run [17:54] debuild -S -sa [17:55] you might need gnome-pkg-tools installed [17:55] once you're done with this, you can build the package by running the following [17:55] sudo pbuilder build meld_1.3.1-0ubuntu1.dsc [17:55] or rather: [17:55] cd .. [17:55] sudo pbuilder build meld_1.3.1-0ubuntu1.dsc [17:56] sorry for ploughing through this like this but we were running out of time [17:56] < Navaneeth> QUESTION: If I submitted a patch to launch pad and didn't send that to original authors. So does that lead into multiple versions of package? And what happens if the patch submitted to launch pad is not the one the real authors like to include? How ubuntu handles such scenarios? [17:56] normally we would have fixed the bugs one by one [17:56] Navaneeth: first of all the patch is not automatically sent upstream [17:57] https://wiki.ubuntu.com/SponsorshipProcess explains how to get a patch reviewed for inclusion by Ubuntu developers [17:57] sometimes they are going to ask you to get in touch with upstream developers and forward the patch there first (if it's not obvious) [17:57] generally we prefer to stay in sync with upstream [17:57] and want good reasons to deviate [17:57] cjohnston: next [17:57] < Quintasan> QUESTION: what is the Build-Depends-Indep line? [17:59] Quintasan: Build-Depends and Build-Depends-Indep are packages that are necessary to build packages [17:59] if a package is Architecture: all, you list under Build-Depends all the packages that are necessary to run the clean target and the rest under build-depends-indep (sorry it's a bit short, but we#re out of time, sorry) [18:00] have a look at https://wiki.ubuntu.com/PackagingGuide for more info [18:00] https://wiki.ubuntu.com/MOTU/GettingStarted is what you need to bookmark :) [18:00] and THANKS EVERYBODY [18:00] this session was awesome! :-) }}}