2009-04-30

Impromptu tutorial on StableReleaseUpdates


   1 [03:24] <dtchen> for people idling in here, in about 2 minutes, i'll be giving an SRU tutorial
   2 [03:24] <Mike||busy> what's SRU?
   3 [03:24] <dtchen> Mike||busy: https://wiki.ubuntu.com/StableReleaseUpdates
   4 [03:25] <dtchen> background: in #ubuntu-offtopic, MadPilot was bemoaning the state of Muine in Jaunty
   5 [03:25] <zaidka> dtchen, is this in the timetable?
   6 [03:25] <dtchen> the relevant bug is https://bugs.launchpad.net/debian/+source/muine/+bug/366620
   7 [03:26] <dtchen> zaidka: no, it's impromptu
   8 [03:26] <zaidka> then dtchen, you're awesome :)
   9 [03:26] <dtchen> for starters, when i first took a look at the bug a few minutes ago, there was no link to the Debian bug
  10 [03:27] <dtchen> whenever i look at Ubuntu bugs using Launchpad, if the bugs have no Debian and/or upstream bug references, i seek them out
  11 [03:27] <dtchen> i then add them
  12 [03:27] <dtchen> so in this instance, i looked at http://packages.qa.debian.org/muine
  13 [03:28] <dtchen> (that's known as PTS, or Debian Package Tracking System)
  14 [03:28] <dtchen> to add the Debian bug reference to the Ubuntu bug in Launchpad, i clicked "Also affects distribution"
  15 [03:29] <dtchen> in the Distribution dropdown, i chose Debian
  16 [03:29] <dtchen> note that in PTS, on the trailing vertical edge (for English speakers, the right side), there's a link to bugs
  17 [03:30] <dtchen> in PTS, i clicked the 9 for "All bugs"
  18 [03:31] <dtchen> i found debian #524181, read its description and status to confirm, and pasted its url into the "Also affects distribution" text entry field
  19 [03:32] <dtchen> any questions thus far?
  20 [03:33] <dtchen> ok, continuingi
  21 [03:33] <zaidka> QUESTION: Why does it matter to Ubuntu what other distros a certain bug affects?
  22 [03:33] <dtchen> the next step after linking the Debian upstream bug is to search for the GNOME upstream bug
  23 [03:34] <dtchen> zaidka: it matters that we have as many links to other bug trackers as possible for the same bugs, because there are only so many resources available for development
  24 [03:34] <dtchen> zaidka: the more eyes looking at bugs, the higher the probability someone will have a resolution
  25 [03:34] <dtchen> zaidka: often, the same bugs plague different Linux distributions
  26 [03:35] <dtchen> zaidka: perhaps most importantly, we take advantage of web search engines: Google is often used to search for workarounds/fixes to symptoms
  27 [03:36] <dtchen> zaidka: having many bug links is an effective way to harness more resources
  28 [03:36] <dtchen> any other questions before i continue?
  29 [03:37] <zaidka> should we ask here or in -chat?
  30 [03:37] <dtchen> here is fine
  31 [03:37] <zaidka> okay. no more questions from me :)
  32 [03:37] <dtchen> all right, so we need to find if there's an existing GNOME bug for the symptoms
  33 [03:38] <dtchen> i next browsed over to http://svn.gnome.org/ to discover that it has been deprecated for git :-)
  34 [03:38] <dtchen> by the way, this just happens to be one approach; other developers/maintainers have their approaches
  35 [03:39] <dtchen> (i read changelogs and source code commits regularly, so that's my preferred approach)
  36 [03:40] <dtchen> so, having been redirected to git, i find the muine repository
  37 [03:40] <dtchen> upon reading the changelogs, i see there's a commit for a very similar-looking bug
  38 [03:40] <dtchen> 2008-11-10Fix for bgo #560077 non-working buttons on Add Song/Album windows. Patch
  39 [03:40] <genii> Q: Does the "Affects other distributions" also somehow know/decide which upstream package it may be that is affected? Many packages have *buntu specific naming, etc and may be difficult sometimes to suss out the upstream name/originating packages
  40 [03:41] <dtchen> genii: in my experience, one needs to set the package explicitly
  41 [03:41] <genii> dtchen: OK, thanks
  42 [03:42] <dtchen> so, upon clicking the link for the commit, we see the changes are applicable to the symptom described in the Ubuntu bug
  43 [03:42] <dtchen> not only that, but we now have an upstream bug to link to!
  44 [03:42] <dtchen> that's what i'll take care of right now
  45 [03:44] <dtchen> there are generally a couple ways to do so
  46 [03:44] <dtchen> you can either leave a comment with the url of the upstream bug, and/or you can choose "Also affects project"
  47 [03:45] <dtchen> when you choose "Also affects project", you'd enter "muine" in the text entry field
  48 [03:45] <dtchen> on the next screen, you'd fill in the url to the upstream bug (http://bugzilla.gnome.org/show_bug.cgi?id=560077) in the "I already have..."
  49 [03:46] <dtchen> so, now that we have a Debian bug entry and a GNOME bug entry in the Ubuntu bug report, we can get to work on fixing the bug for jaunty-proposed
  50 [03:46] <dtchen> as i mentioned earlier, this process is outlined at https://wiki.ubuntu.com/StableReleaseUpdates
  51 [03:47] <dtchen> i tend to get the patches and debdiffs in order first (uploaded to Launchpad) and then fill out the SRU information in the bug description
  52 [03:47] <stefanlsd> QUESTION: Wouldnt we be checking / fixing karmic first?
  53 [03:48] <dtchen> stefanlsd: yes, that's appropriate and a very good point
  54 [03:49] <dtchen> in this case, we'd want to file a bug using the Debian BTS, attach a debdiff against sid's 0.8.10-3, and have it merged as appropriate into karmic
  55 [03:50] <dtchen> again, my approach is to do all the work in parallel, so even though it seems like i'm jumping ahead, i'm actually just changing the debdiffs as appropriate :-)
  56 [03:51] <dtchen> the patch we're interested in is http://git.gnome.org/cgit/muine/patch/?id=ed0e81a673fbe09fa18622ff437c36075d33984d
  57 [03:51] <dtchen> it's linked at (patch) from http://git.gnome.org/cgit/muine/commit/?id=ed0e81a673fbe09fa18622ff437c36075d33984d
  58 [03:52] <dtchen> now, for the next part, you'll need the patchutils binary package installed
  59 [03:53] <dtchen> i saved the patch to ~, but of course one can save it anywhere one pleases
  60 [03:54] <dtchen> wget -O ~/fix-add-dialogs.diff http://git.gnome.org/cgit/muine/patch/?id=ed0e81a673fbe09fa18622ff437c36075d33984d
  61 [03:54] <dtchen> the next part assumes some packaging knowledge, so if you're not familiar with patching systems, please see the Ubuntu wiki for various tutorials/sessions on patch systems
  62 [03:56] <dtchen> next, pull down the jaunty source for muine. you'll either need to manually wget each portion of the source package (yuck), or you can use pull-lp-source (from the ubuntu-dev-tools binary package), or you can use dget (in devscripts) or dgetlp (in ubuntu-dev-tools)
  63 [03:56] <dtchen> and, of course, if you have a deb-src line for jaunty universe, you can just `apt-get source muine'
  64 [03:57] <dtchen> now, since you're read the SRU wiki page, note that the changes need to be as uninvasive as possible
  65 [03:57] <dtchen> upon inspecting the patch (in ~/fix-add-dialogs.diff now)
  66 [03:58] <dtchen> i see there is a patch hunk in Changelog that i don't need to apply, since i'll be referencing it in debian/changelog anyway
  67 [03:58] <dtchen> (a handy tool to do this is called diffstat, i.e., diffstat ~/fix-add-dialogs.diff)
  68 [03:59] <dtchen> next, i look to see whether there is existing patching infrastructure, e.g., quilt, cdbs, etc.
  69 [03:59] <dtchen> i can see from debian/changelog and from the lack of debian/patches/ that the source has been patched inline
  70 [04:00] <dtchen> standard practise is not to introduce patching infrastructure if it's not already present
  71 [04:00] <dtchen> (there are arguments pro and con, but i won't discuss them now)
  72 [04:00] <dtchen> thus, i'm going to apply the changes directly to the source (as has been done in jaunty)
  73 [04:01] <dtchen> so, in the extracted source directory, i'll use: filterdiff -x '*ChangeLog' ~/fix-add-dialogs.diff |patch -p1 --dry-run
  74 [04:01] <dtchen> (next, i'd apply the patch by removing the --dry-run, since i've determined that the patch applies cleanly)
  75 [04:02] <dtchen> now it's off to edit debian/changelog and add the appropriate SRU information
  76 [04:03] <dtchen> the new version will be 0.8.10-1ubuntu2.1, and the distribution will be jaunty-proposed instead of jaunty
  77 [04:05] <zaidka> QUESTION: How did you decide what version number you should give it?
  78 [04:06] <dtchen> zaidka: i tend to follow the older -security/-proposed protocol, which just bumps the minor version
  79 [04:06] <stefanlsd> zaidka: Have a look here- describes it well.  https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update the packaging
  80 [04:06] <dtchen> the correct answer, however, is that all SRUs need to have a version lower (sorted before) than the version in the current development branch
  81 [04:08] <dtchen> knowing that the karmic version will be 0.8.10-3ubuntu1 to retain existing Ubuntu changes and incorporate Debian changes, anything lower than 0.8.10-3ubuntu1 would work
  82 [04:08] <dtchen> (presuming there's not going to be a 0.8.10-4 to sid that rolls in all the changes)
  83 [04:09] <dtchen> i or any other dev/maintainer am happy to discuss the versioning intricacies in #ubuntu-motu after this
  84 [04:09] <zaidka> QUESTION: the fix will automatically go to the next version of Ubuntu? or do I have to manually submit it again?
  85 [04:09] <dtchen> zaidka: that brings me to stefanlsd's earlier question
  86 [04:09] <dtchen> zaidka: ideally the fix is uploaded to the next version of Ubuntu
  87 [04:11] <dtchen> in this case, i'll work on pushing the fix to Debian sid and Ubuntu karmic simultaneously
  88 [04:11] <dtchen> then, if all the Ubuntu changes are subsumed in the next sid packaging revision, then one can request a sync from sid
  89 [04:12] <dtchen> so, to answer your question, because there's an existing Ubuntu delta, the fixes won't be automatically applied
  90 [04:12] <dtchen> one needs to push to karmic and jaunty-proposed
  91 [04:13] <dtchen> i'm not going to cover merging for karmic, because this is already growing lengthy, but someone in #ubuntu-motu will be happy to answer further questions
  92 [04:14] <dtchen> after the changes have been made, one needs to rebuild the source package using debuild -S
  93 [04:15] <dtchen> then, one can use pbuilder/sbuild to generate a deb, and then one can use piuparts to test it
  94 [04:16] <dtchen> one important process bit is modifying the Ubuntu bug report for attribution, so i've assigned the bug to myself and changed the status appropriately
  95 [04:16] <stefanlsd> QUESTION: Should we be nominating this bug for Karmic and Jaunty and attaching both debdiffs to the same bug?
  96 [04:16] <dtchen> stefanlsd: yes
  97 [04:17] <stefanlsd> QUESTION: What do you mean by 'for attribution'?
  98 [04:17] <dtchen> unfortunately, since i'm no longer core-dev, i can't accept or reject release nominations
  99 [04:17] <dtchen> stefanlsd: the connotation would be "who's working on it, or who do i blame for it?"
 100 [04:18] <stefanlsd> dtchen: got it :)
 101 [04:19] <dtchen> now, for sake of time, i'll just proceed as if the karmic version is going to be 0.8.10-1ubuntu3
 102 [04:20] <dtchen> that way we'll see 0.8.10-1ubuntu3 in karmic and 0.8.10-1ubuntu2.1 in jaunty-proposed
 103 [04:20] <dtchen> the last step is completing the template for SRU in the bug description
 104 [04:21] <dtchen> i'm also skipping over the part where i use a vm to test the change
 105 [04:21] <dtchen> (i have a jaunty desktop cd booted in virtualbox for that purpose)
 106 [04:21] <dtchen> are there any further questions so far?
 107 [04:22] <zaidka> QUESTION: when I submit the patch, does it go directly to proposed or does someone have to review it first?
 108 [04:22] <dtchen> zaidka: it's reviewed first
 109 [04:23] <dtchen> zaidka: both by motu-sru and by whomever accepts the upload
 110 [04:23] <dtchen> zaidka: if you don't have upload privileges to Ubuntu universe, whoever sponsors the upload also would review it
 111 [04:24] <zaidka> QUESTION: I'm not sure I understand, someone has to upload it for me? if so, will it still be under my name?
 112 [04:25] <dtchen> zaidka: if your name is in the changelog, yes, it will be in your name
 113 [04:26] <dtchen> zaidka: more specifically, if your name and e-mail address are listed for the main changelog entry, yes, the upload will appear in your name
 114 [04:26] <dtchen> what would happen is this:
 115 [04:26] <dtchen> one would attach the debdiffs and update the bug description
 116 [04:27] <dtchen> then the source changes will be approved (acked) by a member of ~motu-sru
 117 [04:27] <dtchen> then a member of ~ubuntu-universe-sponsors will (re)sign the source package and upload it
 118 [04:28] <genii> Interesting process.
 119 [04:29]  * zaidka just realizes there's more to software development than programming .
 120 [04:30] <dtchen> right, the coding portion is really a small part
 121 [04:30] <dtchen> the design and QA are *supposed* to be the most critical portions
 122 [04:31] <dtchen> for the SRU process, we don't want people's packages breaking any worse than the release version
 123 [04:31] <dtchen> hence the additional checks
 124 [04:33] <dtchen> now, i've just walked through the process, but an enterprising person will note that a very similar debdiff already exists in bug 294659
 125 [04:34] <meshuggah_> dtchen, i dont really understand this channel, are you giving a course?
 126 [04:35] <dtchen> meshuggah_: i just gave an impromptu course on an example of the StableReleaseUpdate process, yes
 127 [04:35] <meshuggah_> dtchen, it is nice from you and this community
 128 [04:35] <dtchen> (people really don't use this channel often enough)
 129 [04:35] <meshuggah_> dtchen, are you paid for it?
 130 [04:35] <meshuggah_> no :)
 131 [04:35] <meshuggah_> i dont think you are
 132 [04:36] <dtchen> (correct, no)
 133 [04:36] <meshuggah_> so we all thank you i think
 134 [04:36] <cody-somerville> indeed we do
 135 [04:36] <dtchen> you're welcome, but the thanks really go to the people who mentored me
 136 [04:37] <zaidka> QUESTION: How is debdiff different from regular diff?
 137 [04:37] <stefanlsd> hehe. thanks. it was really great. (i learnt a couple of cool things). and kept me awake at 4.30am
 138 [04:37] <meshuggah_> stefanlsd, living in UK?
 139 [04:37] <dtchen> zaidka: a debdiff has additional data pertaining to Debian source package-specific things
 140 [04:38] <meshuggah_> dtchen, can i ask you question i have, about, thing you arent teaching right now?
 141 [04:38] <dtchen> meshuggah_: sure, but i don't know if i'll be the appropriate person to answer it
 142 [04:39] <stefanlsd> meshuggah_: south africa (same time zone)
 143 [04:39] <dtchen> zaidka: e.g., a debdiff can be generated against two Debian/Ubuntu source packages, so the debdiff will contain hunks pertaining to debian/changelog, etc.
 144 [04:39] <meshuggah_> dtchen, how can i make my TV-OUT of my videocard works? :)
 145 [04:39] <dtchen> zaidka: more specifically, a debdiff is a diff, but not all diffs are debdiffs
 146 [04:40] <meshuggah_> dtchen, everything is working great, but even after a few hours of trying i didnt found how
 147 [04:40] <zaidka> interesting
 148 [04:40] <dtchen> zaidka: more to the example, the ~/fix-add-dialogs.diff is a diff, but it's not a debdiff
 149 [04:40] <meshuggah_> dtchen, evertyhing except tv-out
 150 [04:41] <dtchen> zaidka: on the other hand, http://paste.ubuntu.com/161107/ is a debdiff
 151 [04:41] <dtchen> meshuggah_: sorry, but i think that question is better posed in #ubuntu
 152 [04:42] <meshuggah_> dtchen, i tried before, anyway i thank you for your time
 153 [04:45] <dtchen> all right, thanks for the questions!


CategoryPackaging

Packaging/Training/Logs/2009-04-30 (last edited 2009-04-30 04:24:11 by crimsun)