Dev Week -- How to update a package -- didrocks -- Tue, Sep 1st, 2009


(02:00:30 PM) didrocks: I'll wait for a couple of minutes before beginning :)
(02:00:48 PM) didrocks: In the meanwhile, you can install a few packages:
(02:00:49 PM) didrocks: 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
(02:01:18 PM) didrocks: and ensure you have "deb-src jaunty main restricted" in /etc/apt/sources.list (and then executes sudo apt-get update)
(02:03:27 PM) didrocks: DING DONG, it's time to get started and fire some package updates!
(02:03:49 PM) didrocks: just to know a little about the audience, who is ready to update some packages? (answer on #ubuntu-clasroom-chat) :)
(02:05:05 PM) didrocks: waow, 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 :)
(02:05:42 PM) didrocks: you can follow the session and do what I type in a jaunty ubuntu box
(02:06:07 PM) didrocks: just ensure you installed and changed what I said earlier ^
(02:06:40 PM) didrocks: I will begin with a very generalist introduction so that people can follow what will be in this lesson
(02:07:11 PM) didrocks: <Quarth> didrock should I change jaunty for kamic?
(02:07:32 PM) didrocks: Quarth: no no, really, I adapted the lesson so that you can use jaunty :)
(02:07:50 PM) didrocks: so, just drop the "deb-src jaunty main restricted" line
(02:08:05 PM) didrocks: ok, some introduction:
(02:08:08 PM) didrocks: 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.
(02:08:40 PM) didrocks: 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).
(02:08:48 PM) didrocks: 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.
(02:09:26 PM) didrocks: So, that why OpenOffice 3 didn't do it into Intrepid. On the contrary, Jaunty that I hope all of you use, have it :)
(02:10:02 PM) didrocks: do you have any queston about what can be elected as an update, and what can't?
(02:10:56 PM) didrocks: apparently, everyone knows, so, I'm going on :)
(02:11:09 PM) didrocks: 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!
(02:11:46 PM) didrocks: Even if I use bzr-buildpackage now to work on, we will not use it today. The Unstoppable James Westby will give an introduction on this this week
(02:12:13 PM) didrocks: Also, this lesson is not intended to teach you how to package. For this, see the corresponding courses in last developpers week session ( Don't forget also the excellent packaginguide:
(02:12:28 PM) didrocks: ell, ready? Let's download the current version of gnome-terminal:
(02:12:37 PM) didrocks: mkdir gnome-terminal && cd gnome-terminal && apt-get source gnome-terminal
(02:12:49 PM) didrocks: This will download the last release present in jaunty, which is 2.26.0.
(02:12:58 PM) didrocks: tell me on -chat when you are ready :)
(02:14:22 PM) didrocks: ok, most of people seems to be ready. Let's get into the source package: cd gnome-terminal-2.26.0
(02:14:36 PM) didrocks: To check if new release is available, if a debian/watch file is present, we just have to use: uscan --report --verbose.
(02:15:01 PM) didrocks: The output should be something like this: You can see there that a new version is available and corresponds to 2.27.91
(02:15:38 PM) didrocks: <EagleScreen> QUESTION: in which package is scan command?
(02:15:49 PM) didrocks: EagleScreen: it's not scan, but _uscan_
(02:16:16 PM) didrocks: this one will be pull as a dep of devscripts (see before for compulsory package)
(02:17:28 PM) didrocks: (remember, you have to download this: 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)
(02:17:35 PM) didrocks: (and yes, that's a bunch :)
(02:18:02 PM) didrocks: so, 2.27.91 is out. 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!
(02:18:12 PM) didrocks: so, just executes uscan this time, with no option :)
(02:18:53 PM) didrocks: The output of the command is telling us that we have to do a "cd ../gnome-terminal-2.27.91" to get into the new package, let's do it
(02:19:21 PM) didrocks: you should get something similar to that:
(02:20:13 PM) didrocks: is everything finished? :)
(02:20:15 PM) didrocks: <bas89> wow that is easy going!
(02:20:29 PM) didrocks: false friend, we have still a lot to do :)
(02:21:06 PM) didrocks: 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
(02:21:44 PM) didrocks: in a seperate debian/ folder
(02:22:08 PM) didrocks: So, now, the hard begins :)
(02:22:12 PM) didrocks: hard work*
(02:22:36 PM) didrocks: just to precise what's done when executing uscan:
(02:22:41 PM) didrocks: - it's downloading the vanilla tar file,
(02:22:56 PM) didrocks: then, trying to apply ../gnome-terminal-2.26.0-0ubuntu2.diff.gz diff file
(02:23:03 PM) didrocks: (this file contains the debian/ diff)
(02:23:23 PM) didrocks: it also adds a new entry in debian/changelog to update to last version
(02:23:34 PM) didrocks: <trothigar> QUESTION: What is the difference between inline patches and patches under debian/patches?
(02:23:47 PM) didrocks: trothigar: in short, inline patches is bad (in my opinion) :)
(02:24:22 PM) didrocks: so, inline patches add diff in diff.gz, but those diffs applied directly to files
(02:24:46 PM) didrocks: patches under debian/patches enables still to use uscan, even if the patch won't apply in the new sources
(02:24:53 PM) didrocks: (we will experience that later ^^)
(02:25:10 PM) didrocks: bas89> QUESTION: Does uscan get that new version from upstream? What happens if there is an ubuntu-customized version of gnome-terminal on our harddisk?
(02:25:40 PM) didrocks: uscan looks at debian/watch to know where to fetch the original tarball
(02:25:56 PM) didrocks: if you downloaded it manually, you can use the uupdate <path to original tarball>
(02:26:24 PM) didrocks: this command will do the same thing than uscan, without downloading it (run it in your source package as well)
(02:26:35 PM) didrocks: in fact uscan calls uupdate :)
(02:26:52 PM) didrocks: <dinxter> QUESTION: What methods does uscan work with, tarballs, bzipped, svn?...
(02:27:14 PM) didrocks: from what I know, it works with tarballs and bzipped (if we just get origin tarball target)
(02:27:56 PM) didrocks: 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):
(02:28:28 PM) didrocks: This is mostly a bugfix release. We will see later what has been fixed. Now, let's discover what changed in configure.{ac,in} file: diff -Nup ../gnome-terminal-2.26.0/
(02:28:38 PM) didrocks: You will get
(02:29:11 PM) didrocks: Here are the most important changes for a packager from previous version to the last release
(02:29:41 PM) didrocks: What matters for us? gt_version_minor and gt_version_micro changed to tell that a new version is available. That's just tell that upstream did a good job.
(02:29:57 PM) didrocks: If it's not present, there is for librairies something like SHVER for library 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
(02:30:05 PM) didrocks: present in this file (debian/rules)
(02:30:12 PM) didrocks: Ok for everyone?
(02:31:00 PM) didrocks: 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 the new version)
(02:31:58 PM) didrocks: 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).
(02:32:12 PM) didrocks: those changes have to take place in debian/
(02:33:03 PM) didrocks: <trothigar> QUESTION: what's the difference between control and
(02:33:14 PM) didrocks: hehe, that was my next sentence :)
(02:33:16 PM) didrocks: So then, as there is a debian/ 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
(02:33:46 PM) didrocks: so, debian/ is used to generate debian/control
(02:34:24 PM) didrocks: it generally adds some automation to debian/control, like last uploaders update, @GNOME_TEAM@ in debian is replaced by the debian gnome team mailing list
(02:34:55 PM) didrocks: Finally, inform of your change! dch -a and add to the file so that it will look like: You see that the so kind uscan command has automatically created "gnome-terminal
(02:35:18 PM) didrocks: oupss, wrong pastebin, correct one is:
(02:35:27 PM) didrocks: You see that the so kind uscan command has automatically created "gnome-terminal 2.27.91"
(02:35:40 PM) didrocks: tell me when it's done :)
(02:36:33 PM) didrocks: (the diff diff files between old and new files can also tell us from added/removed dependencies btw. There is no black packager magic there :D)
(02:37:28 PM) didrocks: 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 usescdbs. Let's try using cdbs-edit-patch debian/patches/99_autoreconf.patch (last patch of the list)
(02:38:30 PM) didrocks: <EagleScreen> why this ?
(02:38:43 PM) didrocks: this command is to update debian/control from debian/
(02:39:02 PM) didrocks: the fakeroot is to simulate that we are root even if we aren't :)
(02:39:12 PM) didrocks: (most debian/rules commands must be launched as root)
(02:39:50 PM) didrocks: DEB_AUTO_UPDATE_DEBIAN_CONTROL=yes is used to desactivate some stuff done by "debian/rules clean" as we just want to update debian/
(02:40:10 PM) didrocks: to make this successfully, you need to have gnome-pkg-tools
(02:40:22 PM) didrocks: (that's why I listed it at the begining ^^)
(02:40:40 PM) didrocks: ok, so, what happened when we tried to apply the patch?
(02:41:08 PM) didrocks: We exited in error in the debian/patches/30_honour_point_pixel_sizes.patch
(02:41:30 PM) didrocks: That can mean 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.
(02:42:02 PM) didrocks: Looking at debian/changelog has to be the first thing to do:
(02:42:17 PM) didrocks: <EagleScreen> QUESTION: how can I change the text editor that dch uses by default?
(02:42:38 PM) didrocks: EagleScreen: just change the environment EDITOR variable, or use update-alternatives
(02:42:54 PM) didrocks: In this case, we see a bug report LP: #345189 associated to the patch. Looking at it (, we deduce that the change is present upstream, looking at the Fix Released
(02:43:21 PM) didrocks: so, the fix has been fixed upstream
(02:43:36 PM) didrocks: Consequently, we can safely remove the patch, "rm debian/patches/30_honour_point_pixel_sizes.patch" as it's no more useful
(02:43:53 PM) didrocks: 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
(02:44:21 PM) didrocks: (cdbs-edit-patch <file>.patch)
(02:44:36 PM) didrocks: I try to not use too many abbreviations, sorry :)
(02:44:47 PM) didrocks: <frandieguez__> QUESTION: so Fix Released at launchpad means the patch is applied to trunk?
(02:45:06 PM) didrocks: frandieguez: you have upstream task and package task on LP
(02:45:28 PM) didrocks: if upstream task is written as fixed release, they rolled a tarball with the fix
(02:46:07 PM) didrocks: if package task is set to fix released, that mean that at least, the fixed version is in the development distribution (presently, karmic)
(02:46:39 PM) didrocks: So, when something is fixed upstream, we can remove the patch
(02:46:42 PM) didrocks: That's why we have always to report our patch upstream (appart from specific ubuntu ones) :)
(02:46:51 PM) didrocks: it's good for them, less work for us, everyone wins \o/
(02:46:59 PM) didrocks: Ok, bring this information to debian/changelog: dch -a and report the change to make it look like that:
(02:47:59 PM) didrocks: so, if the patch was an inline patch, uupdate/uscan would have failed
(02:48:13 PM) didrocks: (as the patch will be directly in diff.gz)
(02:48:30 PM) didrocks: so, this will more clutter our work
(02:48:40 PM) didrocks: Ok! Let's go on with next patch: $ cdbs-edit-patch debian/patches/99_autoreconf.patch again.
(02:48:58 PM) didrocks: The last patch doesn't apply /o\
(02:49:24 PM) didrocks: That's pretty normal: autotools/autoconf/autoreconf patch are different from others patches. They basically consist of generating configure scripts from, on (yes, the famous ./configure is generated there!)
(02:49:35 PM) didrocks: We have to exit first, without updating the patch: "exit 1"
(02:49:55 PM) didrocks: (exit 0 update the patch, exit 1 update it)
(02:50:03 PM) didrocks: oupss
(02:50:14 PM) didrocks: (exit 0 updates the patch, exit 1 does not update it)
(02:50:18 PM) didrocks: that's better :)
(02:50:33 PM) didrocks: (for those interested: a good introduction about patch system is there:
(02:50:57 PM) didrocks: so, now, we will regenerate the patch from scratch
(02:51:17 PM) didrocks: what you can do, is to remove the patch: "rm debian/patches/99_autoreconf.patch"
(02:51:36 PM) didrocks: creating a blank one again: $ cdbs-edit-patch debian/patches/99_autoreconf.patch
(02:51:48 PM) didrocks: (it will again drop you in a subshell)
(02:52:09 PM) didrocks: then, let's regenerate new configure and makefiles: to generate the configure and makefiles: autoreconf
(02:52:32 PM) didrocks: so, this takes to create Makfile, to create configure, and so on.
(02:52:47 PM) didrocks: Once done (ignore the warnings), exit 0 to refresh the patch and document the change: dch -a to get
(02:54:57 PM) didrocks:  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
(02:56:10 PM) didrocks: 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.
(02:56:26 PM) didrocks: once this extra bonus point is done, you will get this:
(02:56:49 PM) didrocks: You can take a breath now! You have your new package updated! Think about testing it throughly and everything will be all right.
(02:57:18 PM) didrocks: Last thing to note is to check which bugs are fixed in current upstream release, find them on launchpad to be able to close them as well by referencing them in debian/changelog.
(02:57:22 PM) didrocks: This can sometimes take a lot of times.
(02:57:27 PM) didrocks: time*
(02:57:43 PM) didrocks: ok, that's all for this session, there are 3 minutes left for question, you can fire up quickly :)
(02:58:34 PM) didrocks: <bas89> ho do i get my updated version into the karmic  repos?
(02:58:55 PM) didrocks: bas89: you should give a look to the sponsoring process until you have upload rights:
(02:59:18 PM) didrocks: bas89: btw, this package is already updated. I picked it because it was interesting with a lot of issues :)
(02:59:31 PM) didrocks: <rugby471> QUESTION: if say you have a small patch, is it better to try and get it applied upstream and the update the package, or write a debian patch?
(02:59:59 PM) didrocks: rugby471: upstream is always the best choice. If you really feel you need it into the last version of ubuntu, apply in both places
(03:00:32 PM) didrocks: <frandieguez__> QUESTION: if a LOCO Team make new translations to a package why this is don't commited to the repository in order to make that release more completed... ??  I ask when the release of ubuntu has do
(03:00:52 PM) didrocks: (this will be the last question)
(03:01:32 PM) didrocks: frandieguez: frankly, I don't know a lot about translations, but new versions are dropped in localized packages which are updated regularly, even when the new version is released
(03:01:53 PM) didrocks: thanks all for all your question, I'll still be in -chat for a couple of minutes, don't hesitate to ask remaining questions

MeetingLogs/devweek0909/PkgUpdate (last edited 2009-09-01 19:09:25 by pool-71-182-107-66)