Ubuntu Wiki

Ubuntu Open Week - Polishing a package - Emmet Hikory - Wed, Nov 5th, 2008

(10:00:51 AM) persia: OK.  Welcome to the OpenWeek session Polishing a Package.
(10:01:44 AM) persia: I'm Emmet Hikory, a MOTU interested in package quality, amoung other things.  I tend to prefer an interactive discussion, so please feel free to interrupt with questions if you have any.
(10:02:43 AM) persia: So, the goal of this session is to demonstrate some of the resources available to help improve the quality of a package.
(10:03:06 AM) persia: Most packages in Ubuntu come from Debian, and those tend to have a maintainer, who generally does a pretty good job of keeping the package in shape.
(10:04:04 AM) persia: While these techniques may also be applied to such packages, it's generally better to use them for packages that don't have a maintainer, at least until all those are in perfect shape.
(10:05:14 AM) persia: The Ubuntu External Health Status pages try to keep track of packages that don't have Debian maintainers, and the status in relation to upstream.  You can take a look at http://qa.ubuntuwire.com/uehs/
(10:05:55 AM) persia: Of most interest are the packages without a watch file or packages not updated.  These are good candidates for some investigation and polish.
(10:06:25 AM) persia: For today's example, I selected the ikvm package, which is shown as out of date on http://qa.ubuntuwire.com/uehs/no_updated.html
(10:06:48 AM) persia: We have version 0.34.0.4 and upstream has 0.36.0.11, which probably contains some useful improvements that users might want.
(10:08:27 AM) persia: So, looking at debian/copyright for the ikvm package, we can see that the upstream homepage is at ikvm.net.  Some packages also have this information in the debian/control file, some in a README, etc.  Depending on the state of the package, you may need to hunt a bit, although the contents of debian/watch may be helpful.
(10:09:57 AM) persia: So, the first step is to grab the new upstream, and prepare the update.  Doing that alone would make the package drop from the list of non-updated packages, but it's not always enough.
(10:10:18 AM) persia: Next would be to take a look at the bugs outstanding against ikvm : you can see those from https://bugs.launchpad.net/ubuntu/+source/ikvm/+bugs
(10:11:33 AM) persia: As you can see, there's a few bugs that indicate some adjustments are required.  At least making sure the pathnames are correct and that it can be used as a jvm seem reasonable requests, so it's worth trying to fix those as part of the update.
(10:11:46 AM) weboide: persia: can you join #ubuntu-classroom-chat ?
(10:12:33 AM) persia: Did I miss a question there?
(10:13:05 AM) persia: < ian_brasil> QUESTION: what is the best way to package for hildon?..pass --enable-hildon into configure.ac or some other way?
(10:13:48 AM) persia: Well, that's a little outside of the scope of polishing packages, but it very much depends on the upstream sources.
(10:15:14 AM) persia: So, once we've cleaned up those issues, it's worth checking to see if the package is in Debian.  I usually do that by visiting http://packages.qa.debian.org
(10:16:14 AM) persia: Entering the package name there will bring you to http://packages.qa.debian.org/i/ikvm.html which provides a nice summary of things needing doing.
(10:17:34 AM) persia: We already knew about the new upstream, but it's worth checking the lintian warning. Apparently the manpage needs to have the charset defined, so that's another thing we can do before uploading.
(10:18:00 AM) persia: There's also a link to the Debian bugtracker available from this page, so we can see the bugs in Debian.
(10:19:03 AM) persia: One of these (Provide java-virtual-machine) looks a lot like the "ikvm is not installed as a viable java alternative" in Malone, so that's already done.
(10:19:54 AM) persia: The other three are worth looking at in a bit more detail, and worth fixing.
(10:21:25 AM) persia: Next, we'll take a look upstream.  The "Report Bugs" link on the upstream homepage goes to the sourceforge bug tracker, and shows 1 open bug, which seems different than any of the other bugs we've seen.
(10:22:27 AM) persia: This one is a bit more complicated, as it's hard to reproduce, so we'll let it go, but for a different package, you might find easy bugs, or bugs with patches available that you might want.
(10:24:01 AM) persia: It's also worth checking to see if the package is in other distributions, and if they have any good patches that we might want.  While this can be done manually, I tend to be lazy, and just check Harvest to use the automated patch collectors people have writted.
(10:24:36 AM) persia: Harvest is available from http://daniel.holba.ch/harvest/ Checking the Sourcepackage list, we see that ikvm doesn't have any outstanding opportunities, so there's nothing to get from there.
(10:25:22 AM) persia: Note that right now, Harvest is only pulling patches from Fedora : I'm sure the Harvest team would appreciate it if anyone wants to write a feed for other distributions.
(10:26:15 AM) persia: So, at this point, we've investigated everything, and hopefully put all the fixes into the package.
(10:27:04 AM) persia: Next is cleanup : if we found a bug not reported upstream, and not fixed with the new upstream, and needed to create a patch, it's worth reporting that to the sourceforge tracker with the patch (and linking to the bug in Launchpad).
(10:28:13 AM) persia: Similarly, if patches were prepared for the Debian bugs, those patches should be attached to the relevant Debian bugs, and we should add bug watches for the BTS bugs where we found them to match bugs already in Launchpad.
(10:29:31 AM) persia: At this point, we're almost ready : it's worth running lintian a last time locally, just in case there's anything that happened as a result of the patching, and the package can be uploaded.
(10:29:41 AM) persia: QUESTION: Because of the different freezes in current ubuntu release for package to go into repos, there's no real point in updating packages for intrepid for example? (except for release critical bugs right?)
(10:30:55 AM) persia: For intrepid, no.  For Jaunty, there's great value in updating and polishing the packages.  Most packages have open bugs that don't get fixed because they aren't so important to the people usually working on the package (or maybe nobody works on the package).
(10:31:59 AM) persia: While none of these would qualify for a stable release update (targeted at intrepid today), fixing them in the development release (jaunty today) means that when the next release happens, those users affected by the bugs are likely to be very pleased.
(10:32:42 AM) persia: QUESTION: how can one get rights to upload a package? or should a updated package be sent to the maintainer?
(10:34:45 AM) persia: Well, none of the packages listed at UEHS have an explicit maintainer : generally it's either one of the Ubuntu packaging teams or the Debian QA team.  In cases where there is a Maintainer, it's best to communicate the patches in the Debian BTS, but if there's enough oustanding, or a good reason to update in Ubuntu (and you plan to track the package), one doesn't have to wait for the maintainer to upload.
(10:37:10 AM) persia: If one doesn't yet have permission to upload, it's best to attach either a debdiff (no new upstream version), or the resulting diff.gz from the updated package to a bug, and subscribe the relevant sponsors team (ubuntu-main-sponsors or ubuntu-universe-sponsors) to request review and upload.
(10:37:59 AM) persia: Any other questions?  Is the process by which one finds various reported bugs or minor issues clear?
(10:40:49 AM) persia: QUESTION: would harvest benefit from integration into maemo or are the patches there automatically pulled into ubuntu-mid
(10:42:07 AM) persia: Well, I'm not sure what "integration into maemo" would mean for harvest, but any additional feeds to pull patches from known reliable patch authors for harvest would probably be good, as this helps to provide a complete picture of available fixes.
(10:43:15 AM) persia: The package I picked didn't happen to be listed there, but if you look at other packages in the sourcepackages list, you can see that some have quite a few available patches, perhaps from Fedora, or perhaps in the bugtracker.
(10:44:05 AM) persia: The more sources from which patches are available and shown, the easier it is for those cleaning up packages to make sure they are perfect.
(10:46:37 AM) persia: QUESTION: there's a package with a new version in debian, but also a new (at the top) upstream version. What should we do? packaging it for debian, then packaging it for ubuntu?
(10:48:03 AM) persia: Well, if you pick a package without a Debian Maintainer, and you prepare a new upstream version, it's worth checking with the Debian QA team to see if they would appreciate the update.  Generally they advise that you might want to become the Debian maintainer, but rarely turn down help.
(10:48:54 AM) persia: If such an update is accepted into Debian, and the Ubutu repositories are not yet frozen, that can be synced directly into Ubuntu, so there's no value in packaging it separately for Ubuntu.
(10:50:06 AM) persia: If there's some reason that it can't be updated, or significant delay, and a freeze is approaching, or you really want to, it's worth sending it to Ubuntu directly, although usually this is just a change to the first line of the changelog, rather than a significant packaging difference.
(10:51:29 AM) persia: Also note that it's not always worth grabbing the very newest upstream : it may be that upstream has a stable release and a development release, and doesn't recommend the development release for most users.  It may also be that a new upstream is incompatible with something else in some way, which may have to be resolved before it can be updated.
(10:53:25 AM) persia: For packages with Maintainers, it's especially desirable not to update in advance of Debian, unless you're personally willing to be responsible for the package until Debian catches up: most Maintainers will update soon enough, and it's best not to duplicate work (as there are plenty of packages without maintainers).
(10:54:19 AM) persia: meaning we should look for ophans packages ?
(10:55:26 AM) persia: Well, I recommend starting with the packages in UEHS, or the packages in Harvest.  Either is a good source of packages needing work.  I usually recommend UEHS more at the beginning of a development cycle, and Harvest later, once things start to settle.
(10:56:04 AM) persia: Every package in UEHS is either orphaned in Debian, or doesn't exist in Debian, and so has no specific individual maintainer.
(10:56:47 AM) persia: Many packages in Harvest have a Debian maintainer, but in Ubuntu there are no specific maintainers generally, so most packages are fair game for basic updates.
(10:57:28 AM) persia: There's no need to look specifically for an orphaned package.  Of course, if there's nothing in UEHS, and nothing in Harvest, then maybe it's worth it, but there's a few thousand packages that need a bit of polich first :)
(10:58:04 AM) persia: I think we have time for one more question before the end, if anyone has one.
(10:58:48 AM) persia: weboide> persia: ok, so the most important would be UEHS, Harvest, and then orphans (debian or not?) packages
(10:59:31 AM) persia: Well, once UEHS and Harvest are clear, I'd suggest just looking for packages with a few bugs in Launchpad, and using the same techniques to bring them up to date.  Doesn't really matter if they are orphaned.
(10:59:56 AM) persia: And with that, I'll turn you over to the Ubuntu Netbook Remix crew.  Thanks for attending.