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!