<> '''Impromptu tutorial on StableReleaseUpdates''' ---- {{{#!irc [03:24] for people idling in here, in about 2 minutes, i'll be giving an SRU tutorial [03:24] what's SRU? [03:24] Mike||busy: https://wiki.ubuntu.com/StableReleaseUpdates [03:25] background: in #ubuntu-offtopic, MadPilot was bemoaning the state of Muine in Jaunty [03:25] dtchen, is this in the timetable? [03:25] the relevant bug is https://bugs.launchpad.net/debian/+source/muine/+bug/366620 [03:26] zaidka: no, it's impromptu [03:26] then dtchen, you're awesome :) [03:26] for starters, when i first took a look at the bug a few minutes ago, there was no link to the Debian bug [03:27] whenever i look at Ubuntu bugs using Launchpad, if the bugs have no Debian and/or upstream bug references, i seek them out [03:27] i then add them [03:27] so in this instance, i looked at http://packages.qa.debian.org/muine [03:28] (that's known as PTS, or Debian Package Tracking System) [03:28] to add the Debian bug reference to the Ubuntu bug in Launchpad, i clicked "Also affects distribution" [03:29] in the Distribution dropdown, i chose Debian [03:29] note that in PTS, on the trailing vertical edge (for English speakers, the right side), there's a link to bugs [03:30] in PTS, i clicked the 9 for "All bugs" [03:31] i found debian #524181, read its description and status to confirm, and pasted its url into the "Also affects distribution" text entry field [03:32] any questions thus far? [03:33] ok, continuingi [03:33] QUESTION: Why does it matter to Ubuntu what other distros a certain bug affects? [03:33] the next step after linking the Debian upstream bug is to search for the GNOME upstream bug [03:34] 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 [03:34] zaidka: the more eyes looking at bugs, the higher the probability someone will have a resolution [03:34] zaidka: often, the same bugs plague different Linux distributions [03:35] zaidka: perhaps most importantly, we take advantage of web search engines: Google is often used to search for workarounds/fixes to symptoms [03:36] zaidka: having many bug links is an effective way to harness more resources [03:36] any other questions before i continue? [03:37] should we ask here or in -chat? [03:37] here is fine [03:37] okay. no more questions from me :) [03:37] all right, so we need to find if there's an existing GNOME bug for the symptoms [03:38] i next browsed over to http://svn.gnome.org/ to discover that it has been deprecated for git :-) [03:38] by the way, this just happens to be one approach; other developers/maintainers have their approaches [03:39] (i read changelogs and source code commits regularly, so that's my preferred approach) [03:40] so, having been redirected to git, i find the muine repository [03:40] upon reading the changelogs, i see there's a commit for a very similar-looking bug [03:40] 2008-11-10Fix for bgo #560077 non-working buttons on Add Song/Album windows. Patch [03:40] 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 [03:41] genii: in my experience, one needs to set the package explicitly [03:41] dtchen: OK, thanks [03:42] so, upon clicking the link for the commit, we see the changes are applicable to the symptom described in the Ubuntu bug [03:42] not only that, but we now have an upstream bug to link to! [03:42] that's what i'll take care of right now [03:44] there are generally a couple ways to do so [03:44] you can either leave a comment with the url of the upstream bug, and/or you can choose "Also affects project" [03:45] when you choose "Also affects project", you'd enter "muine" in the text entry field [03:45] 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..." [03:46] 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 [03:46] as i mentioned earlier, this process is outlined at https://wiki.ubuntu.com/StableReleaseUpdates [03:47] 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 [03:47] QUESTION: Wouldnt we be checking / fixing karmic first? [03:48] stefanlsd: yes, that's appropriate and a very good point [03:49] 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 [03:50] 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 :-) [03:51] the patch we're interested in is http://git.gnome.org/cgit/muine/patch/?id=ed0e81a673fbe09fa18622ff437c36075d33984d [03:51] it's linked at (patch) from http://git.gnome.org/cgit/muine/commit/?id=ed0e81a673fbe09fa18622ff437c36075d33984d [03:52] now, for the next part, you'll need the patchutils binary package installed [03:53] i saved the patch to ~, but of course one can save it anywhere one pleases [03:54] wget -O ~/fix-add-dialogs.diff http://git.gnome.org/cgit/muine/patch/?id=ed0e81a673fbe09fa18622ff437c36075d33984d [03:54] 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 [03:56] 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) [03:56] and, of course, if you have a deb-src line for jaunty universe, you can just `apt-get source muine' [03:57] now, since you're read the SRU wiki page, note that the changes need to be as uninvasive as possible [03:57] upon inspecting the patch (in ~/fix-add-dialogs.diff now) [03:58] 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 [03:58] (a handy tool to do this is called diffstat, i.e., diffstat ~/fix-add-dialogs.diff) [03:59] next, i look to see whether there is existing patching infrastructure, e.g., quilt, cdbs, etc. [03:59] i can see from debian/changelog and from the lack of debian/patches/ that the source has been patched inline [04:00] standard practise is not to introduce patching infrastructure if it's not already present [04:00] (there are arguments pro and con, but i won't discuss them now) [04:00] thus, i'm going to apply the changes directly to the source (as has been done in jaunty) [04:01] so, in the extracted source directory, i'll use: filterdiff -x '*ChangeLog' ~/fix-add-dialogs.diff |patch -p1 --dry-run [04:01] (next, i'd apply the patch by removing the --dry-run, since i've determined that the patch applies cleanly) [04:02] now it's off to edit debian/changelog and add the appropriate SRU information [04:03] the new version will be 0.8.10-1ubuntu2.1, and the distribution will be jaunty-proposed instead of jaunty [04:05] QUESTION: How did you decide what version number you should give it? [04:06] zaidka: i tend to follow the older -security/-proposed protocol, which just bumps the minor version [04:06] zaidka: Have a look here- describes it well. https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update the packaging [04:06] the correct answer, however, is that all SRUs need to have a version lower (sorted before) than the version in the current development branch [04:08] 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 [04:08] (presuming there's not going to be a 0.8.10-4 to sid that rolls in all the changes) [04:09] i or any other dev/maintainer am happy to discuss the versioning intricacies in #ubuntu-motu after this [04:09] QUESTION: the fix will automatically go to the next version of Ubuntu? or do I have to manually submit it again? [04:09] zaidka: that brings me to stefanlsd's earlier question [04:09] zaidka: ideally the fix is uploaded to the next version of Ubuntu [04:11] in this case, i'll work on pushing the fix to Debian sid and Ubuntu karmic simultaneously [04:11] then, if all the Ubuntu changes are subsumed in the next sid packaging revision, then one can request a sync from sid [04:12] so, to answer your question, because there's an existing Ubuntu delta, the fixes won't be automatically applied [04:12] one needs to push to karmic and jaunty-proposed [04:13] 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 [04:14] after the changes have been made, one needs to rebuild the source package using debuild -S [04:15] then, one can use pbuilder/sbuild to generate a deb, and then one can use piuparts to test it [04:16] 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 [04:16] QUESTION: Should we be nominating this bug for Karmic and Jaunty and attaching both debdiffs to the same bug? [04:16] stefanlsd: yes [04:17] QUESTION: What do you mean by 'for attribution'? [04:17] unfortunately, since i'm no longer core-dev, i can't accept or reject release nominations [04:17] stefanlsd: the connotation would be "who's working on it, or who do i blame for it?" [04:18] dtchen: got it :) [04:19] now, for sake of time, i'll just proceed as if the karmic version is going to be 0.8.10-1ubuntu3 [04:20] that way we'll see 0.8.10-1ubuntu3 in karmic and 0.8.10-1ubuntu2.1 in jaunty-proposed [04:20] the last step is completing the template for SRU in the bug description [04:21] i'm also skipping over the part where i use a vm to test the change [04:21] (i have a jaunty desktop cd booted in virtualbox for that purpose) [04:21] are there any further questions so far? [04:22] QUESTION: when I submit the patch, does it go directly to proposed or does someone have to review it first? [04:22] zaidka: it's reviewed first [04:23] zaidka: both by motu-sru and by whomever accepts the upload [04:23] zaidka: if you don't have upload privileges to Ubuntu universe, whoever sponsors the upload also would review it [04:24] QUESTION: I'm not sure I understand, someone has to upload it for me? if so, will it still be under my name? [04:25] zaidka: if your name is in the changelog, yes, it will be in your name [04:26] 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 [04:26] what would happen is this: [04:26] one would attach the debdiffs and update the bug description [04:27] then the source changes will be approved (acked) by a member of ~motu-sru [04:27] then a member of ~ubuntu-universe-sponsors will (re)sign the source package and upload it [04:28] Interesting process. [04:29] * zaidka just realizes there's more to software development than programming . [04:30] right, the coding portion is really a small part [04:30] the design and QA are *supposed* to be the most critical portions [04:31] for the SRU process, we don't want people's packages breaking any worse than the release version [04:31] hence the additional checks [04:33] now, i've just walked through the process, but an enterprising person will note that a very similar debdiff already exists in bug 294659 [04:34] dtchen, i dont really understand this channel, are you giving a course? [04:35] meshuggah_: i just gave an impromptu course on an example of the StableReleaseUpdate process, yes [04:35] dtchen, it is nice from you and this community [04:35] (people really don't use this channel often enough) [04:35] dtchen, are you paid for it? [04:35] no :) [04:35] i dont think you are [04:36] (correct, no) [04:36] so we all thank you i think [04:36] indeed we do [04:36] you're welcome, but the thanks really go to the people who mentored me [04:37] QUESTION: How is debdiff different from regular diff? [04:37] hehe. thanks. it was really great. (i learnt a couple of cool things). and kept me awake at 4.30am [04:37] stefanlsd, living in UK? [04:37] zaidka: a debdiff has additional data pertaining to Debian source package-specific things [04:38] dtchen, can i ask you question i have, about, thing you arent teaching right now? [04:38] meshuggah_: sure, but i don't know if i'll be the appropriate person to answer it [04:39] meshuggah_: south africa (same time zone) [04:39] 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. [04:39] dtchen, how can i make my TV-OUT of my videocard works? :) [04:39] zaidka: more specifically, a debdiff is a diff, but not all diffs are debdiffs [04:40] dtchen, everything is working great, but even after a few hours of trying i didnt found how [04:40] interesting [04:40] zaidka: more to the example, the ~/fix-add-dialogs.diff is a diff, but it's not a debdiff [04:40] dtchen, evertyhing except tv-out [04:41] zaidka: on the other hand, http://paste.ubuntu.com/161107/ is a debdiff [04:41] meshuggah_: sorry, but i think that question is better posed in #ubuntu [04:42] dtchen, i tried before, anyway i thank you for your time [04:45] all right, thanks for the questions! }}} ---- CategoryPackaging