2009-04-30
Next Session: TBD |
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!
Packaging/Training/Logs/2009-04-30 (last edited 2009-04-30 04:24:11 by 216-15-41-218)