<> '''Prerequisites:''' Run {{{ sudo apt-get install build-essential devscripts ubuntu-dev-tools debhelper diff patch quilt fakeroot lintian libtool gnome-common gnome-doc-utils gtk-doc-tools}}} You should also have {{{ deb-src http://archive.ubuntu.com/ubuntu/ jaunty main restricted}}} in your `/etc/apt/sources.list` (and then `sudo apt-get update`). {{{#!irc [20:00] DING DONG, it's classroom time :) [20:00] yep :-) [20:00] just to know a little about the audience, who is ready to update some packages? :) [20:01] me [20:01] I am! [20:01] not yet still learning the basics [20:01] For sure [20:01] total package newbie [20:01] I am ready [20:01] yes [20:02] I am on Intrepid but have Jaunty in virtualbox [20:02] will I need Jaunty for this? [20:02] great, some people there! For those who don't know the basics/can't practice, there will be a lot of copy/paste in pastebin so that you can follow the lesson :) [20:02] Pollywog: appart for last part, no, you can use your intrepid box [20:02] I have hardy intalled [20:02] installed [20:02] hardy has well be fine :) [20:02] as* [20:02] First and before the introduction, if not done yet, install theses packages : [20:03] sudo apt-get install build-essential devscripts ubuntu-dev-tools debhelper diff patch quilt fakeroot lintian libtool gnome-common gnome-doc-utils gtk-doc-tools. [20:03] (without the final dot, of course) [20:03] didrocks: already done [20:03] You should also have "deb-src http://archive.ubuntu.com/ubuntu/ jaunty main restricted" in your /etc/apt/sources.list (and then sudo apt-get update). [20:03] tell me when I can begin my introduction during the download :) [20:04] done [20:04] (and yes, that's a bunch of packages ;)) [20:05] I will begin with a very generalist introduction so that people can follow what will be in this lesson [20:05] As most of user want to live on the edge about what best the Open Source community has to offer, we are going to see how to update a package to offer the very last release to all ubuntu users. [20:05] First, be warned that once a release is out and for all supported releases (jaunty soon!), we never update a package to a new software version (appart from backports repository and ppa, when requested). [20:05] We only cherrypick bug and security fixes from a new release to adapt it an older version. This is intended to have as little breakage as possible. [20:06] So don't expect to have OpenOffice 3 in intrepid from the casual repositories, it will never happen. Jaunty, on the contrary, has it! [20:06] does this mean I should not report bugs in Intrepid's kmail? [20:07] Pollywog: I'm more a GNOME packager than a KDE one. If a major bug in kmail happens, yes, report it [20:07] Pollywog: you should provided it does not say "please update to latest version" [20:07] (it's an extra bonus point if it's still happens in the last release) [20:07] didrocks: which bugs should be fixed and which should be left for the next release? [20:07] but, it only concerns major crash/unusable version. If it's a major issue, no, it will not be updated [20:08] blfgomes: minor issues [20:08] for instance [20:08] ICQ has changed its protocol recentely [20:08] making it unusable fo pidgin [20:08] with* [20:08] I see [20:08] so, we reported the patch in pidgin for every supported version [20:08] that is to say, dapper, gutsy, hardy, intrepid… and jaunty :) [20:09] that's a lot of work, even for a minor patch [20:09] :) [20:09] that's why only major bugs are handled for stable releases [20:09] blfgomes: does this answer your question? [20:09] didrocks: with jaunty release gutsy will have end of life [20:09] yes, it does! Thank you! [20:10] slytherin: yes, but we will have one more unstable version, so, no change for us :) [20:10] Today, we are going to update gnome-terminal. We will see quickly what are the different steps we have to handle generally to update packages, but the best is, of course, to practice! [20:10] right [20:10] Even if I use bzr-buildpackage now to work on, we will not use it today. The Unstoppable James Westby has given a great rocking introduction on this last week (https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Education/Events/01172009). [20:11] Also, this lesson is not intended to teach you how to package. For this, see the corresponding courses in last developpers week session (https://wiki.ubuntu.com/UbuntuDeveloperWeek). Don't forget also the excellent packaginguide: https://wiki.ubuntu.com/PackagingGuide. [20:11] Well, ready? Let's download the old version: mkdir gnome-terminal && cd gnome-terminal && apt-get source gnome-terminal [20:11] This will download the last release present in jaunty, which is 2.26.0. [20:11] tell me when it's ok :) [20:12] Remember that you can interrupt the course at any level: even if you feel lost, we will find you! :-) [20:12] I'm ready [20:12] done [20:13] (let's wait for few seconds too ;)) [20:14] ok, let's say that the others are too shy :) Let's get into the source package: cd gnome-terminal-2.26.0 [20:14] k I am ready too [20:14] To check if new release is available, if a debian/watch file is present, we just have to use: uscan --report --verbose. [20:14] The output should be something like this: http://paste.ubuntu.com/151393/. You can see there that a new version is available and corresponds to 2.26.1. [20:15] everyone has something similar to the pastebin? [20:15] y [20:15] yes [20:15] yes, me too [20:15] yup [20:16] Excited by this new version? \o/ Let's get the new upstream code using uscan! This command just download the new archive, and extract its contents, whith the debian/ubuntu changes applied! [20:16] so, just executes uscan this time, with no option :) [20:17] it is getting it [20:17] The output of the command is telling us that we have to do a "cd ../gnome-terminal-2.26.1" to get into the new package, let's do it (http://paste.ubuntu.com/151399/). [20:17] (yes, you can see that I prepared most of the lesson yesterday ;)) [20:18] done [20:18] done [20:18] done [20:18] Easy, isn't it? Well, when the debian diff doesn't apply because of inline patch, it's getting more difficult, but most of packages are in good shape and every debian difference from vanilla version are in debian/ directory. [20:18] didrocks: what does it do under the hood to apply the diff? [20:19] blfgomes: it's downloading the vanilla tar file, [20:19] then, trying to apply ../gnome-terminal-2.26.0.diff.gz diff file [20:19] (this file contains the debian diff) [20:19] and that's all? [20:20] exactly :) [20:20] cool [20:20] it's also adding a new entry to debian/changelog [20:20] we will see that later :) [20:20] ok! [20:20] Now begins the real packager work. We have to see what changed in upstream release reading the NEWS files (less NEWS and q to exit): http://paste.ubuntu.com/151409/ [20:20] do I need to apply a patch? [20:20] or was it done for me? [20:20] it was done for you [20:20] Pollywog: it was done for you [20:20] k [20:20] Pollywog: seing the debian/ directory? [20:20] seeing* [20:21] yes [20:21] this folder typically contains the changes from upstream to ubuntu :) [20:22] This is mostly a bugfix release. We will see later what have been fixed. Now, let's discover what changed in configure.{ac,in} file: diff -Nup ../gnome-terminal-2.26.0/configure.ac configure.ac [20:22] You will get http://paste.ubuntu.com/151411/ [20:22] here are the changes from previous version to the last release [20:22] What is important in it? m4_define([gt_version_micro] change from 0 to 1 is to tell that a new version is available (2.26.0 to 2.26.1). That's just tell that upstream does a good job. [20:23] If it's not present, there is for librairies something like SHVER variable that you have to change in debian/rules. In every cases, it's good to give a look at debian/rules to see if the version number is present or not. [20:23] Ok for everyone? [20:23] yes [20:23] didrocks: how do you know that only that file is changed? [20:24] francescom: no, I didn't say that :) [20:24] I just say that we have to look at this file, it's different :) [20:24] didrocks: ok thanks [20:24] we will see why just after (all important changes for us are there) [20:25] ok for everyone, can we go on? [20:25] yes [20:25] ok [20:25] yes, following [20:25] What is most important here is the GTK_REQUIRED and VTE_REQUIRED change. That means that we have to bump the dependencies version request of the package (it will request now 2.14.0 for gtk and 0.20.0 for vte librairies). This has to be changed in debian/control.in (or debian/control if there is not control.in file). [20:26] You can edit it with your prefered tool (vim ROCKS \o/) and change libgtk2.0-dev (>= 2.13.6) and libvte-dev (>= 1:0.19.1) to libgtk2.0-dev (>= 2.14.0) and libvte-dev (>= 1:0.20.0). [20:26] didrocks: what's the difference between control.in and control? [20:27] blfgomes: control.in will generate control file. It just contains some automatisation ($GNOME-TEAM is remplaced by the team in charge, it also list the last uploaders of the package…) [20:28] ok [20:28] So then, as there is a debian/control.in file, we have to generate a new debian/control file from it. This is proceed by executing: DEB_AUTO_UPDATE_DEBIAN_CONTROL=yes fakeroot debian/rules clean [20:29] from which directory is that done? [20:29] Pollywog: from the source package one. You should list the debian/ folder from it [20:30] didrocks: won't control file generate automatically when you do debuild -S (I don't have source right now). [20:30] Pollywog: basically gnome-terminal-2.26.1 [20:30] k [20:30] done [20:30] slytherin: most of the time, yes, when using bzr, it's good to generate it before [20:30] (because you will commit the previous revision) [20:31] Finally, inform of your change! dch -a and add to the file so that it will look like: http://paste.ubuntu.com/151422/. You see that the so kind uscan command has automatically created "gnome-terminal (2.26.1-0ubuntu1) jaunty; urgency=low" for us. [20:31] tell me when it's done :) [20:32] done [20:33] (this diff files between old and new configure.in files can also tell us from added/removed dependencies btw. There is no black magic there :D) [20:34] we lost everyone but Pollywog? :) [20:34] we are here :) [20:34] great o/ [20:34] Ok, now that build dependencies are ok, we have to see if ubuntu/debian patches still apply to the new version. The what-patch commands tells us that this package use cdbs. Let's try using cdbs-edit-patch debian/patches/99_autoreconf.patch (the last patch in the queue). [20:34] were here [20:34] We exited in error in the debian/patches/30_honour_point_pixel_sizes.patch (http://paste.ubuntu.com/151427/). [20:35] That can means two things: either upstream has integrated the patch (or we took previously the patch from upstream svn), or that the code has been slightely modified and we can't apply it easily. [20:35] mean* [20:35] Looking at debian/changelog has to be the first thing to do: http://paste.ubuntu.com/151431/ [20:36] In this case, we see a bug report LP: #345189 associated to the patch. Looking at it (https://bugs.launchpad.net/bugs/345189), we deduce that the change is present upstream, looking at the Fix Released next to "gnome-terminal" upstream task. [20:36] Consequently, we can safely remove the patch, "rm debian/patches/30_honour_point_pixel_sizes.patch". [20:36] question: should we always apply the last patch first? [20:37] blfgomes: no, but it's a good way to lost the less time as possible :) [20:37] you can apply them one by one [20:37] I thought patches had to be applied in the order they were issued [20:37] but if you apply the last one, it will try to apply all the others before, in alphabetical order (for cdbs, quilt is quite different) [20:37] issued > released [20:37] so, you know if it crashed or not [20:37] oh, alright [20:38] Pollywog: when you apply the last patch in alphanumerical order with cdbs, it applies every others patches before [20:38] oic [20:38] didn't know that [20:38] that's why when applying 99_… it first failed on 30_… :) [20:39] So, here, patch is integrated upstream. That's why we removed it. If it wasn't the case and the cause was that upstream changed slightely its code, we had to cdbs ....patch and adapt it to make it apply again. [20:39] That's why we have always to report our patch upstream (appart from specific ubuntu ones) :) [20:40] it's good for them, less work for us, everyone wins \o/ [20:40] Ok, bring this information to debian/changelog: dch -a and report the change to make it look like that: http://paste.ubuntu.com/151442/ [20:40] tell me when it's ok :) [20:41] I will have to come back to it later... ready [20:41] done [20:42] Ok! Let's go on with next patch: $ cdbs-edit-patch debian/patches/99_autoreconf.patch again. [20:42] The last patch doesn't apply /o\ [20:43] That's pretty normal: autotools/autoconf/autoreconf patch are different from others patches. They basically consist of generating configure scripts from configure.in, makefile.in one (like debian/control.in that generates debian/control file) and have to use generally the last revision of libtool to generate them [20:43] We have to exit first, without updating the patch: "exit 1" [20:44] are you in a chroot? [20:44] I do not understand the exit 1 [20:44] 6 out of 478 hunks FAILED -- saving rejects to file configure.rej [20:44] fenris-: yes, that's why I told it failed [20:44] Pollywog: cdbs-edit-patch basically copy your files and drop you in a subshell [20:45] oh [20:45] when exiting, it will diff /tmp/old /tmp/new > patch [20:45] ic [20:45] (exiting with 0, if you exit in error, like exit 1, it will change nothing) [20:46] let me seek for a good introduciton about [20:46] introduction* [20:46] patch system [20:46] so : exit 1 ? [20:46] Pollywog: https://wiki.ubuntu.com/MeetingLogs/devweek0809/PackagePatches [20:46] fenris-: as just told previously, "exit 1" prevent from refreshing the patch [20:47] as it failed [20:47] we will regenerate the patch from scratch [20:47] this only work for this package with a jaunty box unfortunately (you need to have the last libtool version) [20:47] ty [20:47] but I pastebin the result, so, you can follow [20:48] and as it is the last, but not least step, I have to show you this :) [20:48] so, what you can do, is to remove the patch: "rm debian/patches/99_autoreconf.patch" [20:48] Finally, $ "cdbs-edit-patch debian/patches/99_autoreconf.patch" [20:48] (it again drop you to a subshell) [20:48] and to generate the configure and makefiles: autoreconf [20:49] so, this takes Makefile.in to create Makfile, configure.in to create configure, and so on… [20:49] Once done (ignore the warnings), exit 0 to refresh the patch and document the change: dch -a to get http://paste.ubuntu.com/151449/ [20:50] We have almost finished: every patches applies and build-dependencies are ok. Normally, you testbuild at this stage, but we won't do it as we are running out of time and not everybody has been abled to do the previous steps [20:50] k [20:50] Once done, a good practice is to put changes from the upstream NEWS file in the changelog. So, get the changes following the given link in the NEWS file and report it to the changelog. Extra bonus point is given if you look at LP bugs corresponding to upstream correction and list them. [20:51] If this time-consuming work is well done, you will get this: http://paste.ubuntu.com/151454/ [20:51] You can take a breath now! You have your new package updated! Think about testing it throughly and everything will be all right. [20:51] Now, rooms for remaining questions , just fire up! :) [20:51] sorry .. dc .. [20:51] didrocks: after exit 1 [20:51] e-jat: yes ? [20:51] e-jat: if you have a jaunty box, you can do: [20:52] - rm debian/patches/99_autoreconf.patch [20:52] - cdbs-edit-patch debian/patches/99_autoreconf.patch [20:52] - autoreconf [20:52] - exit 0 [20:52] I followed _some_ of this, thanks for your time and sharing wisdom Didier [20:52] you will generate a new autoreconf patch [20:53] I have the logs to go over and the links you gave [20:53] it was a please padawan. Take some time to look at basics for packaging first, hope you can refer to this afterwards :) [20:53] pastebin are not removed generally [20:53] willdo, see you all soon, gnight [20:53] but be aware that few times after jaunty is out, this update 2.26.1 for gnome-terminal will be available [20:53] didrocks: could you point us to a autoreconf/configuration files tutorial? [20:54] so, apt-get source gnome-terminal will download 2.26.1 :) [20:54] blfgomes: here is a great lesson about autools: http://www.lrde.epita.fr/~adl/autotools.html [20:54] I thought it downloaded an older version [20:54] autotools* sorry [20:54] didrocks: updating from upstream is OK, what about syncing from Debian? [20:55] Pollywog: yes, but when jaunty will be out, one of the first SRU will be this update :) [20:55] oic [20:55] didrocks: after exit 0 ? [20:55] Rail: it all depends on the "project" [20:55] I understand now [20:55] didrocks: thanks! [20:55] e-jat: just update the changelog [20:55] e-jat: logs will be available soon :) [20:55] Rail: in desktop team, generally [20:55] as we are in advance from debian, why pushed changes back to debian with alioth svn [20:56] (removing specific ubuntu changes) [20:56] changelog in which folder ? debian @ gnome-terminal ? [20:56] e-jat: debian/changelog [20:56] is alioth a PPA for Debian? [20:56] (one sec) [20:57] e-jat: http://paste.ubuntu.com/152293/ [20:57] Pollywog: nope, it is the service where many teams from Debian maintain the packaging bits in version control systems (svn). [20:57] oic [20:57] thanks slytherin ;) [20:58] didrocks: thank you [20:58] Pollywog: some non debian developper can gain commit access to this svn [20:58] ic [20:58] one last question: why hasn't gnome-terminal been frozen yet? [20:58] blfgomes: gnome-terminal is frozen [20:58] we are at 2.26.0 in jaunty [20:59] but you said there will be a 2.26.1 [20:59] in jaunty [20:59] you can see my pending request there : https://bugs.edge.launchpad.net/ubuntu/+source/gnome-terminal/+bug/361053 [20:59] blfgomes: most of the gnome packages have standing freeze exception. when I say gnome packages it means the ones identified as official modules of gnome. [20:59] yes, once jaunty released, as GNOME 2.26.1 is mostly a bug fix, there is an exception for it [21:00] we update it through SRU process [21:00] so, that would be a case of cherrypicking [21:00] blfgomes: the changes between 2.26.0 and 2.26.1 is really tight [21:00] most of packages have only translation update, for instance [21:01] this one, bumping dependencies is really exceptional [21:01] but as it was a real good example to see a lot of things, I choose it as a candidate for this lesson :) [21:01] dependency changes, patches that doesn't apply \o/ [21:02] :) [21:02] well, more questions or everything is clear in everyone's mind? :) [21:02] (practice and you will learn :)) [21:02] didrocks: thanks for the presentation [21:03] :) [21:03] thanks didrocks [21:03] again, thanks to all the attendees :) [21:03] didrocks: thank you, it was really great! [21:03] didrocks: tnanks! [21:03] have a nice day/evening/night everyone ;) [21:03] nite ... [21:03] next session for those interested will be "Package testing: piuparts and VMs" by dtchen. The 23rd April, 00:00 UTC. }}} ---- CategoryPackaging