=== asorbus is now known as sps === sps is now known as shawnps === Pricey is now known as PriceChild === PriceChild is now known as Pricey [05:27] gl === MT- is now known as MT === MT is now known as MT- [07:01] good morning! [07:02] good morning ! [07:02] anyone here ;)? [07:02] good evening(?) [07:02] ah good. [07:02] almost good afternoon here (india) [07:03] good morning! [07:03] Hello [07:04] 2 am here [07:04] i almost wondered if anyone would show up at this time ;) ... but great [07:05] ok lets get started. please be a bit patient with me ... its really early and usually i wouldnt be awake now ;) [07:05] Me neither :P [07:05] i really appreciate that you came then ;) [07:06] good thing is that - afaik - there is no session directly after this session, so in case it takes a bit longer we won't thrown out. (though i will try to keep it within one hour) [07:07] so basiclly todays packaging training session is supposed to be about "Mozilla packaging techniques (extensions, patchsystems, bzr)" === MT- is now known as MTeck [07:07] why mozilla? [07:08] Mozillateam takes care of a variety of packages surrounding mozilla software [07:09] + we have pretty big beasts like tbird/sunbird/firefox/xulrunner [07:09] + our expertise touches various packages that interface with mozilla in one way or another ... (cairo, fontconfig,) (plugins and embedding apps) [07:10] + xulrunner applications: fennec, prism [07:10] (and probably know, but I can't reember) [07:10] more;) [07:10] + lots of extensions [07:10] + helper tools to standardize and easy mozilla package maintenance [07:10] s/easy/ease/ [07:12] so thats quite a lot work; i want to show you know what techniques were established to make the package maintenance as efficient as possible [07:12] one more adverstiment thing: we have our channel in #ubuntu-mozillteam ... so any questions wrt mozilla packages are best anwered there [07:13] so today i planned to how we achieve a few of the various objectives; in particular: [07:14] efficiency and transparency for upstream [07:14] (damn my typo is still bad ... if you get confused by too many typos let me know ;)) [07:15] wrt to efficiency I want to look at various aspects: [07:16] 1. how to improve efficiency of a team [07:16] 2. how to maintain patches in an efficient way - show tricks [07:17] 3. how source tree layout can contribute to efficiency [07:17] 4. how we make backporting efficient === MTeck is now known as MT- [07:18] 5. and special requirements we get by providing daily builds [07:18] so i want to start with section one of todays session ;) ... "Team & Tools" [07:19] efficient team maintenance depends on a shared set of tools and best practices [07:19] basically the goal is: [07:20] anyone in a Team should be able to fix/adjust/extend packaging branches without thinking twice [07:20] this [07:20] helps to be better leverage learning effects, but also reduces discussion about such meta topics itself to a minimum [07:21] Examples (team & tools): [07:21] + mozillateam uses bzr - discussing the benefits of a distributed VCS for a team is a bit beyond the scope of this session, but probably feel obvious to most, right? [07:22] + something less obvious, which helps to improve team efficiency is the use of the same changelog format [07:23] doesnt sound like a big deal, but besides from improving readability it also helps [07:24] to avoid regular discussions about how this or that format is better ... so team members can focus on the real work ;) [07:25] two examples of changelog formats used; first the comon one: [07:25] * path/to/file: what did you do [07:25] that one is pretty common, but for mozilla (at least the big beast apps mentioned above) it turned out to be suboptimal [07:26] basically because most of the work we do is related to patches: updating patches, adding patches, removing patches === noodles775 is now known as noodles === noodles is now known as noodles775 [07:26] also we explicitly add some meta information to our patches to increase upstream transparency [07:27] so our file names would be rather long: [07:27] * debian/patches/bz386904_config_rules_install_dist_files.patch ... [07:27] if you have a bunch of those files touched the changelog becomes unreadable ... thats why mozillateam took a different approach and first state what is done and then how and what files touched [07:28] * i did this [07:28] - update debian/patches/bz386904_config_rules_install_dist_files.patch [07:28] - update debian/patches/series [07:28] - drop debian/patches/yetanother_patch [07:29] you can see this format being used in most mozilla related packages in ubuntu i would think [07:29] next thing is similar trivial, but even more important: "Branch names" [07:29] agreeing on how to name branches improves efficiency quite a lot [07:30] ideally, anyone in the team can find any branches by typing in the location bar or console directly [07:30] our format is: [07:30] Release branches: lp:~${TEAM}/${PROJECT}/${PACKAGE}.[${RELEASE}|head] [07:30] (release branches are the main branches that are used to release uploads from) [07:31] Topic branches lp:~${TEAM}/${PROJECT}/${PACKAGE}.[${RELEASE}|head].${TOPIC_NAME} [07:31] so for example: lp:~mozillateam/firefox/firefox-3.0.head [07:31] TEAM = mozillateam [07:31] PROJECT = firefox [07:31] PACKAGE = firefox-3.0 (source package) [07:32] RELEASE = hardy|intrepid|jaunty ... "head" [07:32] head is a special release name somehow which we use to signal that its the branch for the current development release [07:33] soinstead of using .karmic now we are using .head; when we come close to a release we cut off stable releaes branches where we dont do much development on anymore [07:33] so if you have a "real" release it means in mozillateam land that its a stable maintenance branch [07:34] two more things before we do a quick exercise for the team & tools section [07:34] we also do "release commits": [07:34] -> this boosts efficiency because you can easily spot revisions that reflect any given package version [07:35] we use bzr-builddeb accors the board as a conventient way to produce sources/binaries etc. [07:36] and we use debian/rules get-orig-source quite heavily to produce tarballs directly from upstream repositories (e.g. snapshots/dailies/releases) [07:36] hmm... time is running fast. any questions for now? [07:37] maybe lets do a simple exercise about "branch names": [07:37] guess the branch url for the nss jaunty release branch and bzr branch it [07:37] anyone can guess the name ;)? [07:38] so the template is: lp:~${TEAM}/${PROJECT}/${PACKAGE}.[${RELEASE}|head] [07:38] bzr branch lp:~mozillateam/nss/nss.jaunty ;) [07:40] everyone got that branch ;O)? [07:41] ok ... so for next excersize you similarly should branch the "nspr" karmic branch as we want to prepare a release ;) [07:41] bzr branch lp:~mozillateam/nspr/nspr.head [07:43] so what you usually do during development is to keep the changelog at UNRELEASED (check out debian/changelog) [07:43] currently its karmic, but assume its all the time UNRELEASED until the real upload [07:43] so when you are done with all the branchwork you do a release commits. Thats basically two commands: [07:44] 1. dch -r -DRELEASE (e.g. dch -r -Dkarmic) [07:44] -> this updates the changelog timestamps and flipps UNRELEASED to karmic (or whatever you specified in RELEASE [07:44] 2. debcommit -r [07:45] -> this does the actual release commit. it autoamtically creates a bzr commit log reading like: "releasing 0.0-0ubuntu1" [07:45] this helps anyone in the team later to spot the actual release by just looking at changelog [07:46] also it creates a tag using the version in changelog - which is a good thing, but the mozillateam usually does not use tags for that [07:46] so when you did those two commands you basically have prepared a nspr release in mozilla-team-style [07:47] so seince you are not a mozillateam member, where would you push the branch to in order to contribute? [07:47] answer is simple: push your branch up to launchpad using an appropriate topic branch name [07:47] and request a merge [07:48] Topic branches lp:~${TEAM}/${PROJECT}/${PACKAGE}.[${RELEASE}|head].${TOPIC_NAME} [07:48] so for this it could be: lp:~yourname/nss/nss.head.4.8-0ubuntu1 [07:48] ok thats it for teams and tools :) [07:49] since time is already running low i will a bunch of things i said to say ... [07:49] lets go from team & tools to patches [07:49] in particular its important that adding patches also causes long term maintenance pain [07:50] especially in an environmnet where you want to provide daily builds based on a really active upstream [07:50] like firefox [07:50] (example: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive) [07:51] one thing to wake you up: [07:51] + seemingly easy patches can become a pain; see http://bazaar.launchpad.net/~chromium-team/chromium-v8/chromium-v8.head/annotate/37/debian/patches/enable_soname.patch [07:51] thats a patch i recently added to our chromium v8 branch (the chrome javascript engine) [07:51] anyone has any idea whats so painful about that patch? [07:53] the problem is not that its a big patch that is hard to figure how to port in caes upstream changes the underlying file [07:53] the problem here is that it touches a context that frequently changes: e.g. MINOR_VERSION, BUILD_NUMBER, PATCH_LEVEL [07:54] those regularly change and i am sure if that patch would have been kept we would get build failures every few days in our ~chromium-daily ppa [07:54] anyone can think of a way to prevent that? [07:55] here is the better approach (even if its a bit ugly its much less painful): [07:55] http://bazaar.launchpad.net/~chromium-team/chromium-v8/chromium-v8.head/revision/39#debian/rules [07:55] so basically we dont put a patch in there, but rather do the change using sed from debian/rules :) [07:56] ok another thing about patches ... [07:56] + dpatch-edit-patch and simple-patchsys is suboptimal approach for a) large packages and b) medium packages that are work intensive [07:56] - example: adjusting one patch in xulrunner 1.8 (even smaller than 1.9) with dpatch-edit-patch run took several minutes [07:56] thats time better spend on other things i am sure [07:57] mozillateam uses quilt ... its a bit more to learn up front, but you can work within a source tree and dont need to regularly create full copies of it and so on [07:58] as an exercise you could try to adjust the soname patch from above using quilt (not now though). [07:58] i will stay in the channel if you have questions. or join #ubuntu-mozillateam [07:59] i will skip two topics now because of time constraints and move directly to last topic: tricks on how to make backports easy [08:00] about backporting [08:00] especially for the dailies we dont want to maintain branches for each and every ubuntu releaes [08:00] instead we take care that .head branches just work everywhere [08:00] for that we use various tricks ;) [08:01] one trick is to enable/disable features based on the version that is available [08:01] so if firefox 3.0 needs PACKAGE b >= VERSION 1 for a certain feature [08:01] we wouldnt add a hard depent to debian/control like b >= VERSION1 [08:01] instead we just add an unversoined dependency on package b to debian/control [08:02] and then in debian/rules check the installed version and enable/disable a certain feature on demand [08:02] you can check that yourself in rules and control of http://code.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.2.head [08:02] look for nspr/nss and cairo and sqlite [08:04] ok since time is off, go ahead and ask me [08:04] include my nick so i can see your questions [08:04] the notes i prepared for this session can be found here: http://paste.ubuntu.com/236213/ [08:04] maybe it helps you to re-read something [08:05] if you do the exercises and need help, let me know [08:05] if not today here, you can ask i #ubuntu-mozillateam [08:05] i didnt touch extension maintainence this cycle because i did it like 4 last time i did a session [08:05] if you are interested in helping out doing extensions, jump in our channel [08:05] we have lots of work todo this cycle [08:06] and extensions are an easy starter [08:06] ok thanks [08:06] ! === croppa_ is now known as croppa [11:05] date -u === noodles775 is now known as noodles775-afk === noodles775-afk is now known as noodles775 === noodles775_ is now known as noodles775 === noodles775 is now known as noodles775-afk [17:01] Does anyone have invites on DEMONOID or BITME? Could exchange some === noodles775-afk is now known as noodles775 [22:09] anyone having trouble getting MPEGs to play ?