Dev Week -- Introduction to Ubuntu Distributed Development (UDD) -- barry -- Mon, Feb 28th, 2011

   1 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Introduction to Ubuntu Distributed Development (UDD) - Instructors: barry
   2 [18:01] <barry> hi, my name is barry warsaw, and i live near washington dc.  i work for canonical, do ubuntu development, am a core python developer and project leader for gnu mailman.  i'm here to introduce you to a new way of developing ubuntu, called 'ubuntu distributed development', or 'udd'
   3 [18:01] <dholbach> next up is the ROCKing Barry Warsaw
   4 [18:01] <barry> thanks dholbach!
   5 [18:01] <dholbach> ... not only an Ubuntu, Launchpad and Python hacker, but also a fun guy, friend and exceptional bass player
   6 [18:02] <barry> aw shucks, thanks :)
   7 [18:02] <dholbach> enjoy the session, you'll love Ubuntu Distributed Development afterwards
   8 [18:02] <barry> in a nutshell, udd uses the bazaar revision control system to fix bugs and develop features in ubuntu packages.  in this session, we'll learn how to fix a bug by:
   9 [18:02] <barry>  * creating a local branch of the project
  10 [18:02] <barry>  
  11 [18:02] <barry>  * developing a fix, then committing it to your local branch
  12 [18:02] <barry>  * link the branch to the bug report in launchpad
  13 [18:02] <barry>  * request a 'merge proposal' for the package maintainer to review
  14 [18:03] <barry> we'll probably just be scratching the surface of how this works, but hopefully you will come out of this session feeling more confident about using bzr to work on you ubuntu packages.  i won't cover much about packaging in particular, or bzr, but i will try to answer any questions you have!
  15 [18:03] <barry> just a note: we'll be using a bug in computer-janitor as an example.  c-j is a little different than most packages in ubuntu because it's developed natively in launchpad. for the purposes of this class, this difference won't matter too much.  if it comes up, i'll point it out.
  16 [18:04] <barry> why use bzr when the old tools work just fine?  bzr gives you the benefit of a full distributed version control system to manage package changes.
  17 [18:04] <barry>   * incremental changes can be committed locally as you go
  18 [18:04] <barry>   * logging, diffing, intelligent merging
  19 [18:04] <barry>   * interact better w/other ubuntu devs by sharing works-in-progress
  20 [18:04] <barry>   * work disconnected
  21 [18:04] <barry>   * manage all artifacts in launchpad
  22 [18:04] <barry>   * request reviews online
  23 [18:05] <barry>   * automatic requests for sponsorship review
  24 [18:05] <barry>   * soon: build-from-branch-to-archive
  25 [18:05] <barry> for now, the documentation is a little bit scattered, but the best place to start is on the wiki.  we are acdtively working on cleaning this up and moving it to the official ubuntu developers documentation.
  26 [18:05] <barry> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
  27 [18:06] <barry> so, i'm going to give folks a few minutes to catch up on all the prepared overview above, then i'll start digging in...
  28 [18:08] <barry> anybody need a few more minutes to catch up?
  29 [18:08] <barry> or are there any questions about the introductory material, or what i hope to cover today?
  30 [18:09] <barry> so, we need to start by making sure you have the basic tools.  you'll need bazaar and a special plugin that adds a lot of useful stuff
  31 [18:10] <barry> start by doing this:
  32 [18:10] <barry> sudo aptitude install bzr bzr-builddeb
  33 [18:10] <barry> you're also going to need to know your launchpad id.  dholbach covered this in the previous session.  it's the bit after the ~ in your launchpad url
  34 [18:11] <barry> if you don't have a launchpad login yet, either go get one now or there will be a few steps later that don't work for you.  no worries, you can still follow along
  35 [18:11] <barry> dholbach: points out that you can visit this url:
  36 [18:11] <barry> https://launchpad.net/people/+me
  37 [18:12] <barry> and after it redirects, you can look for the ~ in the url.  the bit after that is your launchpad id
  38 [18:13] <ClassBot> monish001 asked: bzr launchpad-login monish001 bzr: ERROR: The user name monish001 is not registered on Launchpad.
  39 [18:13] <barry> monish001: be sure you've registered on launchpad first.  'bzr launchpad-login' will not create a login for you
  40 [18:14] <barry> also, some folks may not have aptitude, you can install the bzr tools with this instead:
  41 [18:14] <barry> sudo apt-get install bzr bzr-builddeb
  42 [18:15] <barry> okay, now, i'd like you to run this command:
  43 [18:15] <barry> bzr --version
  44 === evilshadeslayer is now known as shadeslayer
  45 [18:15] <barry> and note the version of bzr that you are using
  46 [18:16] <barry> we are going to use two different urls later to refer to package source in launchpad.  if you are using bzr version 2.3 or higher, you will be able to do things like this:
  47 [18:16] <barry> bzr branch ubuntu:mypackage
  48 [18:16] <barry> to get the version of 'mypackage' in natty
  49 [18:17] <barry> if you have bzr 2.2 or older, this will be spelled like this:
  50 [18:17] <barry> bzr branch lp:ubuntu/mypackage
  51 [18:17] <barry> if you sat in on dholbach's session, you've already done this:
  52 [18:17] <barry> bzr whoami "Your Name <me@example.com>"
  53 [18:17] <barry> bzr launchpad-login mylpid
  54 [18:17] <barry> and now we're ready to use bzr to fix a bug in ubuntu!
  55 [18:18] <ClassBot> hugohirsch asked: Is it a problem that I still run 10.10? My bzr is 2.2.1
  56 [18:18] <barry> hugohirsch: it is not a problem.  this will work just fine.  just remember to use the lp:ubuntu/foo urls instead of ubuntu:foo
  57 [18:18] <ClassBot> cire831 asked: how does it know to get the natty version?  what if I'm running lucid and want that version?
  58 [18:19] <barry> cire831: the ubuntu:foo urls always pick the current in-development version of ubuntu, i.e. as we speak, that's natty
  59 [18:19] <barry> you can always use ubuntu:natty/foo or ubuntu:maverick/foo etc. to get a specific version of a package in a specific version of ubuntu
  60 [18:20] <barry> those could also be spelled as lp:ubuntu/natty/foo or lp:ubuntu/maverick/foo or lp:ubuntu/lucid/foo etc
  61 [18:20] <ClassBot> palhmbs asked: Why does bzr-builddeb setup mail, do I really need it?
  62 [18:21] <barry> it sets up your email which will be used when you commit changes later on (i.e. it'll show up in your debian/changelog file)
  63 [18:21] <ClassBot> chilicuil asked: can I use bzr and lp to pull debian versions?
  64 [18:21] <barry> yes.  you can use urls like this:
  65 [18:21] <barry> debian-lp:squeeze/foo
  66 [18:21] <barry> or
  67 [18:22] <barry> lp:debian/squeeze/foo
  68 [18:22] <barry> okay, let's fix a bug!
  69 [18:22] <barry> go ahead and open this url in your browser: http://launchpad.net/bugs/726616
  70 [18:22] <barry> someone noticed a typo in a file in the package.  we'll fix that the udd way :)
  71 [18:23] <barry> go ahead and cd to a location where you want to do the work.  we'll be creating a bunch of directories in there
  72 [18:23] <barry> cd someplace
  73 [18:23] <barry> now, just a little bazaar boilerplate to make things efficient:
  74 [18:23] <barry> bzr init-repo janitor
  75 [18:23] <barry> cd janitor
  76 [18:24] <barry> and now we're going to grab the source branch for the current version of computer-janitor in natty:
  77 [18:24] <barry> bzr branch ubuntu:computer-janitor natty
  78 [18:24]  * barry will give you a moment to catch up
  79 [18:24] <ClassBot> mhall119 asked: why is init-repo necessary? why not just bzr branch?
  80 [18:25] <barry> it's not strictly necessary, but as you'll see in the next step, using a bazaar 'shared repository' like this will make future steps go much faster by reducing the amount of network traffic you'll consume
  81 [18:25] <barry> (i.e. bzr can cache things locally if you use a shared repo)
  82 [18:26] <ClassBot> cire831 asked: didn't work.  bzr branch ubuntu:computer-janitor natty says not a branch.
  83 [18:26] <barry> does 'bzr branch lp:ubuntu/computer-janitor' work for you?
  84 [18:27] <barry> ah.  this ubuntu: url might not work for computer-janitor.  remember i said it was a little weird because c-j is developed in launchpad natively?  if it does not work for you, use this url instead:
  85 [18:27] <barry> bzr branch lp:computer-janitor
  86 [18:27] <barry> in general you will use the ubuntu: urls, but in this case it's a little different.  don't let that confuse you too much ;)
  87 [18:28] <barry> everybody good?
  88 [18:28] <barry> bzr branch lp:computer-janitor natty
  89 [18:28] <barry> ^^
  90 [18:28] <barry> (that just gives you the branch in a directory called 'natty')
  91 [18:29] <barry> okay, so we're going to work on bug 726616.  let's branch the current c-j trunk to a working directory which will only contain our fix
  92 [18:29] <barry> bzr branch natty bug-726616
  93 [18:29] <ClassBot> cire831 asked: what exactly does the natty on the end do?  rather than say bzr lp:ubuntu/natty/computer-janitor
  94 [18:29] <barry> all it does is leave you with a local directory called 'natty' instead of the default 'computer-janitor'.  there's no other difference
  95 [18:30] <barry> it's totally up to you
  96 [18:30] <barry> now...
  97 [18:30] <barry> cd bug-726616
  98 [18:30] <barry> and we're sitting in a directory where we'll make our fix!
  99 [18:31] <barry> look around.  you'll see the upstream source code, and a debian directory with all the packaging information.  it looks like a pretty typical ubuntu source package, right?
 100 [18:31] <ClassBot> cire831 asked: so I should be able to do bzr branch lp:ubuntu/lucid/computer-janitor lucid to get the lucid version?
 101 [18:31] <barry> yes
 102 [18:31] <barry> these urls are very handy when you want to backport fixes for sru's and such
 103 [18:33] <barry> okay, sorry, just triaging some questions
 104 [18:34] <barry> so, now, if you open the NEWS file in your favorite editor, and search for the word 'publically' you see the typo
 105 [18:34] <barry> just use your favorite editor to spell check this to 'publicly' and congratulations!  you've just fixed an ubuntu bug
 106 [18:35] <barry> but of course, now you'd like to share your fix with the world and get it into ubuntu, right?  let's do that now
 107 [18:35] <barry> exit your editor and then at the command line do this:
 108 [18:35] <barry> bzr diff
 109 [18:36] <barry> you should see that the NEWS file has the fix.  what you'll see is a unified diff between your local change and the original source code
 110 [18:36] <barry> next thing you want to do is commit this change, but before you do that, you also want to add a debian/changelog entry which records what you've done
 111 [18:36] <barry> type this: dch -i
 112 [18:37] <barry> this will open an editor providing you with a template to fill in your change
 113 [18:37] <barry> you'll add a little bit of descriptive text, such as what i did here:
 114 [18:37] <barry> computer-janitor (2.1.0-0ubuntu4~udd0) UNRELEASED; urgency=low
 115 [18:37] <barry>  
 116 [18:37] <barry>   * NEWS: fixed a typo.  (LP: #726616)
 117 [18:37] <barry>  
 118 [18:37] <barry>  -- Barry Warsaw <barry@ubuntu.com>  Mon, 28 Feb 2011 11:18:20 -0500
 119 [18:37] <barry>  
 120 [18:37] <barry> note a couple of things:
 121 [18:38] <barry> the version number will be filled in, but when you see it, it won't have the ~ppa0 suffix.  that's a trick we use to specify a version "in the middle" of the previous release and what will be the next release
 122 [18:38] <barry> using a ~ suffix makes it easier for testing later, but it's not strictly necessary
 123 [18:39] <barry> also notice the UNRELEASED tag.  we'll eventually change that to 'natty' but again, this is a middle step so we can do some testing
 124 [18:39] <barry> finally, the most important part
 125 [18:39] <barry> notice this text at the end of the description line:
 126 [18:39] <barry> (LP: #726616)
 127 [18:39] <barry> that is really critical to include.  it will be used to link your branch with the fix to the bug report
 128 [18:39] <barry> it must be exactly like that (the parentheses are optional)
 129 [18:40] <barry> but it must be of the form:
 130 [18:40] <barry> LP: #123456
 131 [18:40] <barry> with a space between the colon and hash, and the hash must be there
 132 [18:40] <barry> anyway, save the changelog and exit your editor.  i'll take some questions now
 133 [18:40] <ClassBot> fisch246 asked: "bzr branch natty bug-726616" what command do i use if i'm on maverick?
 134 === Nik is now known as Nekhelesh
 135 [18:41] <barry> note that 'natty' in the above example is the local directory of the source branch that you checked out previously.  you'd still use that, since you're working on the natty version of the package, even though you're on maverick
 136 [18:41] <ClassBot> darkdevil56 asked: bash: cd: bug-726616: No such file or directory?
 137 [18:42] <barry> did you do the 'bzr branch natty bug-726616' command from earlier?
 138 [18:43] <ClassBot> figure002 asked: where does dch get your email address from?
 139 [18:44] <barry> in the previous session, dholbach described how to set the DEBEMAIL and DEBFULLNAME environment variables.  dch gets those values from there by default, but do a 'man dch' for details
 140 [18:44] <barry> okay.  now, we've fixed the bug, and we've added a changelog entry.  we just need to commit our changes to the local branch
 141 [18:45] <barry> run this: debcommit
 142 [18:45] <barry> this will call 'bzr commit' with some useful defaults, so it's mostly a convenience.  you could use 'bzr commit' but for now, 'debcommit' is better
 143 [18:45] <barry> you can ask bzr to show you the history of the change you just made:
 144 [18:46] <barry> bzr log -c -1
 145 [18:46] <barry> up to now though, your fix is just sitting in a branch on your local machine.  we want to push the change to launchpad so we can share it with others.  to do this, run this command:
 146 [18:46] <barry> bzr push lp:~myid/computer-janitor/bug-726616
 147 [18:47] <barry> where of course you use your launchpad id instead of 'myid'
 148 [18:47] <barry> that'll take just a few seconds to run, and then when the command comes back, type this:
 149 [18:47] <barry> bzr lp-open
 150 [18:47] <barry> this should open your web browser to the launchpad page that represents your just pushed branch
 151 [18:48] <ClassBot> palhmbs asked: if you fix a bug that hasn't been reported, what then, create a bug on launchpad?
 152 [18:48] <barry> it's generally good practice for there to always be a bug report first.  it's not strictly required for any of the udd tasks, but it makes everyone's life easier to track the issue if there is a bug report
 153 [18:49] <barry> so i do suggest creating the bug report first.  do that directly in launchpad not through bzr though
 154 [18:49] <ClassBot> jderose asked: when i fix a bug, i like to do a PPA test build (also so others can easily test fix) - in this case, is it okay to commit, say, "natty" in the changelog rather than "UNRELEASED"?  Wont the PPA builders choke on UNRELEASED?
 155 [18:49] <barry> i'm running out of time, but i do plan on covering this later.  or if time runs out i will answer this in -chat
 156 [18:50] <ClassBot> cire831 asked: where can I find out how all these tools are integrated.  ie.  how the bzr stuff knows about LP: #<bug> etc.
 157 [18:50] <barry> more info can be found in #ubuntu-devel or #udd or #bzr
 158 [18:50] <barry> okay, so we've pushed our fix branch to launchpad, now what?
 159 [18:51] <barry> if you look at the page that 'bzr lp-open' opened in your browser, scroll down to the 'related bugs' section
 160 [18:51] <barry> you should see a link to bug 726616
 161 [18:51] <ClassBot> There are 10 minutes remaining in the current session.
 162 [18:51] <barry> this was done automatically by debcommit, and launchpad when you pushed your branch.  it was made possible by the 'LP: #726616' text you added in debian/changelog
 163 [18:52] <barry> if you click on the related bug link, you'll hop over the bug.  notice that the bug page also has a link for 'related branches'. that should let you get back to the branch page
 164 [18:52] <barry> though, there may be multiple such branches from all the other folks in this class :)
 165 [18:52] <barry> be sure to pick yours!  or use the back button
 166 [18:52] <barry> now, make sure you're on your branch page.  scroll down and look for a link that says 'propose for merging'
 167 [18:53] <barry> click on that
 168 [18:53] <barry> what that does is inform the owner of the master branch, and all the ubuntu sponsors, that you have a fix for an ubuntu bug
 169 [18:53] <barry> so you don't have to request a sponsor, or a review, explicitly.  (again, here's where computer-janitor is a little odd, but the above is true for 99% of branches)
 170 [18:53] <barry> er, packages
 171 [18:55] <barry> maco points out that sponsors aren't specifically notified, but your branch does show up in the sponsorship queue automatically.  you can still ping a sonsor directly as normal
 172 [18:55] <ClassBot> There are 5 minutes remaining in the current session.
 173 [18:55] <ClassBot> cire831 asked: mine didn't link automatically.  I can do it by hand though.
 174 [18:56] <barry> it can take several minutes for launchpad to process your branch and create the link.  you can of course do it manually if you get impatient :)
 175 [18:56] <ClassBot> cire831 asked: should we actually go ahead and do it?
 176 [18:56] <barry> go for it!  don't worry, i'll be processing that bug when the class is over :)
 177 [18:56] <ClassBot> darkdevil56 asked: aborting commit write group: PointlessCommit(No changes to commit) bzr: ERROR: No changes to commit. Use --unchanged to commit anyhow.?
 178 [18:57] <barry> bzr will spit this out if you've already committed all your changes.  just use --unchanged, or make another change.
 179 [18:57] <barry> it can happen if you used 'bzr commit' before you did debcommit
 180 [18:58] <barry> please note that i skipped a lot of stuff about doing test builds, creating source packages, uploading to a ppa etc.   we've basically run out of time, but i'll head over to #ubuntu-classroom-chat to continue for a while
 181 [18:58] <barry> remember that all the gory details are on the wiki:
 182 [18:58] <barry> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
 183 [18:59] <barry> i'll take a few more questions before the next session starts, and thank you all for listening!
 184 [18:59] <ClassBot> stefwal82 asked: is the worked on problem now uploaded?
 185 [18:59] <barry> no.  a sponsor would have to merge your branch, build the source package, and upload that
 186 [19:00] <barry> in the future though, there will be some very cool stuff to do even that automatically in launchpad
 187 [19:00] <barry> if you have upload rights of course :)
 188 [19:00] <ClassBot> hugohirsch asked: If i fix a bug do I need to create a PPA or is a branch sufficient enough?
 189 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Taking bite out of Unity - Instructors: DBO, jcastro
 190 [19:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/02/28/%23ubuntu-classroom.html following the conclusion of the session.
 191 [19:01] <barry> a branch is sufficient for a sponsor to review and apply your change.  a ppa is not necessary at all!  but it's useful for testing your package, or sharing your changes with others before it gets uploaded
 192 [19:02] <jcastro> woo, thanks barry, great job!

MeetingLogs/devweek1103/UbuntuDistributedDev (last edited 2011-03-02 05:48:04 by nigelbabu)