== Ubuntu Open Week - Packaging Firefox Extensions - Alexander Sack - Wed, Apr 30, 2008 == {{{ === jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | Current Session: "Packaging Firefox Extensions" - Alexander Sack [19:00] ok, next up is Packaging Firefox Extensions with asac! [19:00] thanks jcastro [19:00] asac: take it away! [19:00] Welcome to the Firefox Extension Packaging world. [19:00] First I want to give some general information about extension packaging. In particular the why. [19:01] (this questions pops-up frequently so i think its good to address here upfront) [19:01] Then I'll go and give a quick review on what was done during the hardy cycle and where we plan to go for the future. [19:01] Next, I will give a short insight in how you can contribute. [19:02] and finally we'll go and exercise some basics by packaging an extension. For that we will repackage ubufox which should help to show. [19:02] the general idea [19:02] So why do we want extensions packaged. Isn't addons.mozilla.org good enough? [19:03] addons.mozilla.org surely is a great portal for getting extensions and automatically updating them. [19:03] But its not all positive: [19:03] 1. it doesn't allow you to install extensions globally easily. [19:03] 2. more important is the fact that automatically updated extensions might not match the quality expectations of users, especially in corporate environments [19:04] packaged extensions would allow us to stabilize extensions and given the track record of crashes due to extensions it looks worth to do [19:05] Any questions on these? [19:05] < toobuntu> QUESTION: Are Ubuntu packaged Firefox extensions meant to replace the -install-global-extension option? There seem to often be issues with permissions and configs, and they globals just haven't work out well for me in a multiuser environment. [19:06] right the install global option is not really working properly [19:06] packages don't replace it, but its the better approach for distributing extensions [19:06] ok lets go on [19:07] * waiting on questions * [19:08] OK, lets move one. What was done in hardy? [19:09] In hardy we started to package extensions using our new mozilla-devscripts helpers that make packaging quite easy [19:09] we will use this helper to package the example later on [19:09] anyway, It was hard work, especially since most extensions were not yet available for firefox 3. [19:10] But thanks to the hard work of contributors we managed to get more extensions into the archive than ever before. [19:10] An overview of packages can be seen on the firefox 3 extension page: https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions which is used to document the data needed to properly maintain extensions in ubuntu. [19:11] so in short, I would declare this a victory and i want to express my thanks to all involved in making that happen [19:11] However, we are still not where we would like to be and for intrepid we are planning to scale this up. [19:12] Based on our experiences from the hardy cycle we discussed how to better automize the extension packaging process. [19:12] which is a requirement to maintain as many extensions as possible in the future with as little manpower as possible. [19:13] of course we will still need you on the manpower side ;) [19:13] as not everything can be done automatically [19:14] For those intereseted the (not yet finished) current state of that discussion can be found on https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/LargeScaleMaintenance [19:14] Any questions? [19:15] < toobuntu> QUESTION: If we encounter an extension that is not already packaged, we should make an effort to package it, then? Please tell us what's involved... [19:15] i think we will come to that later. but basically all starts with adding the extension to the https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions wiki page and gather all the data in the table [19:16] once that is done and everything is available, the packaging can start. [19:16] its not even required that you do the packaging on your own. getting the data is often harder than packaging itself [19:16] :) [19:16] especially sorting out licensing ;) [19:16] Next [19:17] < MiSc0110> QUESTION: Are this packaged extensions for Firefox only, or are they for Thunderbird too? [19:17] currently we focussed on extensions for firefox [19:18] but that doesn't mean that we won't do the same for thunderbird in future. [19:18] I agree, that we should add a similar wiki page for thunderbird extensions. the process will be similar and we can certainly maintain include thunderbird extensions in our intrepid work [19:19] Next [19:19] (if you are interested in particular thunderbird extensions, please come to #ubuntu-mozillateam channel and ask there) [19:20] ok ... lets move on [19:20] So, how can you contribute? [19:20] obviously you can help doing the packaging work. after some practice you will usually learn quickly how to package extensions [19:21] and usually reach an expertise level just after a few extensions. [19:21] packaging extensions is definitly a good starter task [19:21] but as said above, you can also contribute by suggesting new extensions [19:21] and getting all the data required before we can start packaging them. [19:22] for that you do not need any special technical skills [19:22] as said above the most important things you need to figure before you suggest an extension for packaging is to check: [19:22] 1. does the .xpi include a license file - and is the license suitable for ubuntu [19:22] 2. does the xpi support firefox 3 - if not, does it work if you disable compatibility. [19:23] however, extension authors are not really used to licensing and often they just don't know the difference of including a license in the .xpi or just stating the license on a website [19:24] so if there is no license file in the .xpi it makes sense to contact the author, explaining the situation and asking him politely to include a license file in the top level directory of the xpi [19:24] Which license is suitable and how to check if an extension works with firefox 3 is documented in the first paragraph of the https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions wiki page. [19:24] (there might be more licenses, but the list should cover most cases) [19:25] Questions? [19:25] Question: how does one disable compatibility [19:25] this is documented in the top most paragraph on the https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions page [19:26] you have set the extensions.checkCompatibility to false [19:26] in about:config [19:26] next [19:27] OK, lets get started on the packaging excersize for today. [19:27] I wrote a basic packaging page once: [19:27] https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging [19:27] You do not need to read it now, please just do what is listed in the Prerequisites section (on top of that page). [19:28] (if you want to do this excersize) [19:28] OK, lets wait a few minutes for those of you who want to follow ... [19:28] feel free to ask questions during this excersize whenever you want :) [19:33] ok, while you are finalizing your preparations some words. [19:33] packaging usually starts with setting up an upstream branch [19:34] this is what the ubufox.upstream branch is. [19:34] its a bit unfair, because ubufox ships decent sources, and in real live you need to convert .xpis to proper upstream branches first [19:34] rogfou> QUESTION: what is the policy for updating such extension packages? especially for an LTS (it's ok to answer this question after the exercise if prefered) [19:35] our largescalemaintenance approachs plans to provide latest extensions to -backports for _all_ stable distributions [19:36] unless there is a serious bug we won't send new upstrewam versions to -updates though. but i think thats a good compromise [19:36] serving our users with a somewhat similar experience than AMO ... just QAed and opt-in [19:36] end of answer :) [19:36] ok, lets go on [19:37] so basically you need an .upstream branch. based on that you create a packaging branch. to do so run: [19:37] bzr branch ubufox.upstream ubufox.ubuntu [19:37] this will create a ubufox.ubuntu directory next to your ubufox.upstream branch [19:38] now we have to add the initial packaging. [19:38] for that we copy the debian/ directory from the XPI.TEMPLATE into the ubufox.ubuntu directory [19:38] e.g. cp -r XPI.TEMPLATE/debian ubufox.ubuntu/ [19:39] then you switch to the ubufox.ubuntu directory [19:39] cd ubufox.ubuntu [19:39] and add the new files to the branch [19:39] bzr add debian [19:40] the output i get from this looks like: http://paste.ubuntu.com/8993/ [19:40] the content of the ubufox.ubuntu directory looks like http://paste.ubuntu.com/8994/ after doing that [19:41] now you have to edit the template files [19:41] 1. changelog: change the package name in the first line to match the package you are trying to package [19:41] and change the name to match your name/email [19:42] the changelog currently contains some documentation about the best-practices on how to commit, but thats not important for this session. [19:42] usually you would also change the version of the changelog to match the upstream version (which is in install.rdf) [19:43] so in this case you would use 0.6~a1-0ubuntu1 [19:44] 2. control: here you have to change the Source: field to match your package (ubufox) and the XSBC-Original-Maintainer field (use your name if you want to be the primary packaging contact) [19:44] usually you would also change the Vcs-Bzr field, but since this is just an excersize you can skip this [19:44] together with fixing package description and so on [19:45] in case you would create a thunderbird extension you would also adapt the Depends: field accordingly. [19:45] the template should cover the most common firefox cases (usable for firefox 2 + firefox 3) [19:46] 3. copyright ... you don't need to edit this for this excersize. usually you would fill in the license of the extension you package [19:47] oh, for 2. i forgot that you need to change the Package: field as well (ubufox) [19:48] 4. rules: here you have to change the fields MOZ_EXTENSION_PKG and the MOZ_XPI_BUILD_COMMAND [19:48] the MOZ_EXTENSION_PKG would be the value you added to the Package: field in control [19:49] the MOZ_XPI_BUILD_COMMAND is expected to produce an .xpi in the top level directory [19:49] the rules files looks like http://paste.ubuntu.com/8996/ for me now [19:50] ok lets sync up [19:51] my changelog looks like: http://paste.ubuntu.com/8998/ [19:51] my control looks like: http://paste.ubuntu.com/8999/ [19:52] and the rules like above (http://paste.ubuntu.com/8996/) [19:52] when you are done you can commit everything like [19:52] bzr commit -m "* initial packaging (0.6~a1-0ubuntu1)" [19:52] and do a test build [19:52] dpkg-buildpackage -rfakeroot -b [19:53] ok, kind of a rush, but i hope you could follow [19:53] questions so far? [19:53] QUESTION: does the update policy specify if one should update only on security issue and major bugs correction (data loss) or also on added new features? [19:53] problems? [19:53] we want latest extensions everywhere ... thats why our policy for -backports allows new features [19:53] dpkg-buildpackage: fallo: fakeroot debian/rules binary gave error exit status 2 [19:54] for -updates we have the same policy as the ubuntu distribution [19:54] e.g. only security related changes that are minimal. [19:54] however, security issues have to be considered case-by-case [19:55] there might be cases where updating to latest upstream might be better, but usually we want minimal patches for security changes [19:55] next [19:55] ah [19:55] for that error, please post the complete output [19:56] http://paste.ubuntu.com/9002/ [19:58] anyway. i think time is running low. if you want to finish this excersize feel free to join us in #ubuntu-mozillateam. we can surely sort out the final issues there :) [19:58] mailing list? [19:58] same goes for further questions. you can ask in #ubuntu-classroom-chat, or in the mozillateam channel [19:59] mailing list is: ubuntu-mozillateam AT lists DOT ubuntu DOT com. [19:59] but you need to be subscribed. most discussion happens in #ubuntu-mozillteam [19:59] asac, thank you \o/ [19:59] thanks for joining ... and thanks for helping for extension packaging in future [19:59] hope you had some fun at least ;) }}} ---- [[CategoryMozillaTeam]]