=== asac_ is now known as asac
[14:50] <bdrung> chrisccoulson: m-d uses recommends, but not depends. therefore FF updates are not blocked by extensions
[14:51] <chrisccoulson> bdrung - hmmmm, what's the point in versioning them then?
[15:16] <chrisccoulson> fta - if i rename lp:~mozillateam/firefox/firefox-4.0.head to firefox-trunk.head, would that upset the daily builds? they're just using the lp:firefox alias aren't they?
[15:22] <chrisccoulson> micahg - this abrowser-on-XR stuff is a PITA atm. i might have to shelve it for now until i've got more time ;)
[15:24] <micahg> chrisccoulson: no worries
[15:24] <chrisccoulson> micahg - there's quite a few things we need to resolve before we can do it
=== asac_ is now known as asac
[15:25] <chrisccoulson> the first one being translations - the translations seem to be incompatible due to the different jar packaging formats
[15:25] <micahg> chrisccoulson: if you add the tasks to the blueprint, I'll try to help with it
[15:25] <micahg> chrisccoulson: that seems weird
[15:26] <chrisccoulson> the second one being that because xulrunner is a versioned source package, and there can be more than one copy in the archive (especially when we add new XR versions as a stable update), we need a way to transition cleanly
[15:27] <chrisccoulson> also, i'm not sure if we should make abrowser use the ~/.mozilla/firefox profile. if we do, then firefox and abrowser still need to conflict. if we don't, then you can install both browsers side-by-side, but you can't switch between the 2 different brandings like you can now
[15:27] <micahg> chrisccoulson: well, we can have versioned abrowser packages with a meta abrowser package that always points to the "current" one
[15:27] <chrisccoulson> micahg - what happens when we add a new version during upgrades though? the user ends up with 2 different copies of abrowser installed
[15:28] <chrisccoulson> (with 2 different launchers which look the same)
[15:28] <chrisccoulson> note, that we can't use conflicts during stable updates, as update-manager doesn't resolve package removals
[15:28] <micahg> chrisccoulson: provides, conflicts, replaces: abrowser?
[15:29] <chrisccoulson> i'm not sure what that would do. but, any package relationships which force a removal will end up with update-manager offering a partial upgrade though
[15:30] <chrisccoulson> and then the user has to do apt-get dist-upgrade to resolve it properly
[15:31] <micahg> chrisccoulson: well, we can transition back to an unversioned xulrunner, but then we have to update everything when we do a version jump, that seems more risky
[15:31] <chrisccoulson> yeah, we definately don't want to do that. the versioned xulrunner has to stay for now, so we can have them parallel installable
[15:32] <chrisccoulson> i've got abrowser-on-XR building now btw, so i can push my current work to a separate branch for now
[15:32] <micahg> chrisccoulson: that sounds good, would a 2 way profile importer help WRT profiles?
[15:33] <chrisccoulson> i'm not sure. possibly, but that might start to make things quite complicated
[15:40] <bdrung> chrisccoulson: shouldn't we version recommends?
[15:45] <chrisccoulson> bdrung, i'm just wondering what benefit it gives in this case. so, if an extension in the archive is not compatible with the current version of firefox, then installing it just won't pull in the recommends, right?
[15:46] <chrisccoulson> but if the recommends are installed already, it doesn't make any difference
[15:46] <chrisccoulson> in this case, the extension shouldn't be in the archive anyway ;)
[15:47] <bdrung> and moving recommends back to depends and set the min version?
[15:49] <chrisccoulson> min version is fine for a depends, but anything which makes a transition difficult (which maxversion generally does), wouldn't be so good IMO
[15:51] <bdrung> asac, micahg: what do you think about moving recommends to versioned depends (see above)?
[15:53]  * micahg goes to look up depends/recommends definitions in policy manual :)
[15:54] <chrisccoulson> micahg - https://code.edge.launchpad.net/~mozillateam/xulrunner/xulrunner-2.0.head.abrowser-on-XR
[15:54] <chrisccoulson> that's what i've got so far, which seems mostly working
[15:55] <micahg> bdrung: well, I guess the question is, do the extensions do anything with any other packages not in the m-devscripts added list?
[15:56] <bdrung> micahg: no - all packages that can have xul extensions should be in the list in m-d
[15:57] <micahg> bdrung: OTOH, firefox/xulrunner/thunderbird will just ignore an incompatible extension for the most part, so forcing package removal on a transition like the one we're doing isn't necessary
[15:58] <micahg> OTOH, forcing the transition means we won't miss updating/dropping extensions before the end of the cycle as someone will probably file a bug ;)
[15:58] <bdrung> micahg: there won't be a package removal, because we aren't setting a max version. e.g. "firefox (>= 3.5)" would be still valid
[15:58]  * micahg will run out of hands soon... :-/
[15:58] <chrisccoulson> heh ;)
[15:59] <bdrung> micahg: clone yourself! :P
[15:59] <micahg> bdrung: yes, but that's not correct in how the extensions for the most part work though
[15:59] <chrisccoulson> yeah, minversion is fine, but i wouldn't be happy with having a maxversion in the depends
[15:59] <bdrung> having min and maxversion is impossible if we have alternatives
[16:00] <micahg> bdrung: right, I saw that discussion on teh Debian extensions list
[16:00]  * micahg thinks that should be a feature request in dpkg :)
[16:01] <bdrung> until dpkg has this feature, we can only set minversion :)
[16:03] <micahg> bdrung: well, I guess a minversion is better than nothing, but I don't really see a use case where it's extremely useful unless an extension is brand new and only for the newer version (almost all the old extensions maintain last stable version/current dev version compatibility)
[16:03] <micahg> bdrung: might not be a bad idea for Debian though
[16:04] <bdrung> yes, that's more a feature for debian
[16:07] <micahg> so, depends instead of recommends is technically more correct as well (since all possible consumers should be listed), and I don't see any harm in having it in Ubuntu
[16:09] <micahg> s/and/therefore/
[16:11] <micahg> s/therefore//
[16:11]  * micahg needs caffeine
[16:14] <micahg> chrisccoulson: sorry, should have cut and pasted our conversation re: pyxpcom
[16:14] <chrisccoulson> micahg - that's ok ;)
[16:16] <fta> chrisccoulson, no, the bot uses the full branch name (in fact, it uses my local copy too, which has the --remember urls) so i have to intervene
[16:16] <fta> chrisccoulson, http://bazaar.launchpad.net/~fta/%2Bjunk/ppa-confs/annotate/head:/ppabot-pkgs-umd.conf
[16:17] <chrisccoulson> fta - ok. i wanted to renams firefox-4.0.head to firefox-trunk.head, which would keep that name stable indefinately then
[16:18] <chrisccoulson> and i wanted to take firefox-4.0.head for the official in-archive packaging branch
[16:18] <fta> chrisccoulson, from this file, the idea is that the bot either pull from inside $branch if it exists, or bzr branch $lp $branch otherwise
[16:18] <fta> ok, just tell me what you want me to rename and to what
[16:20] <chrisccoulson> fta - so, for now, it's just firefox-4.0.head => firefox-trunk.head.
[16:21] <fta> (i really hate the colors of the lp code browser.. light gray text on either white/lighter gray/light ping background)
[16:21] <chrisccoulson> yeah, it's not good for the eyes ;)
[16:27] <chrisccoulson> fta - if we change firefox-4.0.head to firefox-trunk.head now, the package name would stay the same for now (firefox-4.0)
[16:27] <chrisccoulson> although, that would most likely change at some point in the future, but there are other issues to resolve before we do that
[16:33] <fta> hmm... i remember we had some problems last time we did something like that... i have to look
=== yofel_ is now known as yofel
[16:34] <micahg> chrisccoulson: I think we should just push a new branch, like fta said, there were some issues last time
[16:35]  * micahg has to run
[16:35] <chrisccoulson> i don't mind how we go about doing it
[16:36] <chrisccoulson> basically, i just want to get FF4.0 uploaded in to the archive, which means renaiming the source to firefox (from firefox-4.0)
[16:36] <chrisccoulson> if i do that in the current firefox-4.0.head, then umd will be building 2 firefox source packages
[16:37] <chrisccoulson> and if i do it in firefox-3.6.head, then we lose the 3.6 dailies on all releases (and the branch name doesn't make much sense then either)
[16:38] <chrisccoulson> urgh, did mozilla bump their cairo version
[16:38] <fta> we can try. i remember something about the package name not matching something.. but i don't really remember
[16:38] <chrisccoulson> ?
[16:40] <fta> i have a bunch of branches to consider: http://paste.ubuntu.com/532432/
[16:44] <fta> funny, i had a firefox-trunk.head branch in 2007 ;)
[16:46] <bdmurray> fta: is the right package name "chrome" or?
[16:46] <fta> chrisccoulson, could please rename in lp?
[16:47] <fta> bdmurray, chromium-browser is our src package
[16:47] <chrisccoulson> fta - ok, renamed
[16:47] <fta> bdmurray, do you need the binary packages too?
[16:47] <bdmurray> fta: just source since that is what lp uses
[16:51] <bdmurray> fta: okay it'll show up today / tomorrow
[16:52] <fta> bdmurray, excellent, thanks!
[16:54] <fta> chrisccoulson, is trunk still 4.0?
[16:54] <fta> or did moz already moved it to 4.1, 5.0, .. ?
[16:54] <chrisccoulson> fta - yeah
[16:55] <chrisccoulson> it's still 4.0 atm. so, we'll have 2 4.0 branches for a little while, but that's unavoidable i think
[16:56] <fta> http://paste.ubuntu.com/532442/
[16:57] <fta> i can't change the key as it's the src package (which must match d/control and d/changelog)
[16:57] <fta> so the bot can't do two 4.0
[16:58] <fta> i remember the problem now, it was when we change the src package name. the bot chokes just at the transition as it compares two versions but the pkg is not the same. it's a tricky case
[16:59] <fta> when that happens, i need to trigger a manual merge
[17:01] <chrisccoulson> fta -that's ok, we're only changing the branch location atm, so the source package stays as firefox-4.0 for now
[17:01] <chrisccoulson> the new firefox-4.0.head will just have the "firefox" source pacakge, which is what i'm going to upload to natty
[17:02] <chrisccoulson> but we don't need daily builds of that atm
[17:02] <fta> sure
[17:02] <fta> ok, trying
[17:02] <chrisccoulson> thanks
[17:02] <fta> hold your breath :)
[17:02] <fta> (maybe not)
[17:12] <fta> chrisccoulson, \o/
[17:12] <chrisccoulson> fta - it worked ok?
[17:12] <chrisccoulson> oh, yeah. excellent, thanks :)
=== davida is now known as davidascher
[20:32] <bdrung> micahg: i fixed bug #674171
[20:32] <ubot2> Launchpad bug 674171 in mozilla-devscripts (Ubuntu) (and 1 other project) "[NATTY] Adblock 1.3.1doesn't load up in FF 3.6.12 (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/674171
[20:33] <micahg> bdrung: great, what was the issue?
[20:34] <bdrung> micahg: the __str__ function added the "
[20:35] <micahg> bdrung: ah, ok
[20:35] <bdrung> it uses now a different function to get the value
[20:37]  * micahg is getting a python book soon
[20:41] <micahg> chrisccoulson: which branch are you planning on releasing from to Natty?
[20:42] <chrisccoulson> micahg - which bzr branch? it will be the new firefox-4.0.head, once i've updated it
[20:42] <chrisccoulson> that's what i'm doing right now
[20:42] <chrisccoulson> not sure if it will be tonight, it depends on when i finish testing the upgrade
[20:42] <micahg> chrisccoulson: ah, do you want to keep the versioned .head branches?
[20:43]  * micahg was thinking 3 branches, -trunk, -next, and firefox
[20:44] <chrisccoulson> micahg - for now, yes. we need to resolve how we'd handle the dailies to make that work. (if we just had a firefox branch, then we'd lose the 3.6 dailies straight away)
[20:44] <micahg> chrisccoulson: well, for now, I would suggest using firefox-next for natty
[20:45] <chrisccoulson> the issue with that is we want the firefox-next packages to be versioned, so that they are parallel installable with the in-archive version
[20:45] <micahg> when 4.0 is released, we can create the firefox.head branch
[20:45] <chrisccoulson> but i don't want the natty source package to be versioned
[20:45] <micahg> oh right :(
[20:45] <chrisccoulson> hence the split for now
[20:46] <micahg> chrisccoulson: ok, I'll merge what you put in the new firefox-4.0 branch into firefox-next when you release for the PPA then
[20:46] <chrisccoulson> cool, thanks
[20:52] <chrisccoulson> hmmm, no asac
[20:52] <chrisccoulson> i could really do with him merging my ubufox changes :)
[20:52] <chrisccoulson> micahg - perhaps we need to fork ubufox and maintain it in ~mozillateam ;)
[21:00] <chrisccoulson> micahg - if you take the firefox-next packages from firefox-4.0.head, you'll need to rename the source package to firefox-4.0 too
[21:01] <chrisccoulson> that *should* just work though
[21:01] <chrisccoulson> if it doesn't, then we need to fix it
[21:02] <bdrung> micahg: could we split the daily build PPA - e.g. i want the daily build for FF, but not for thunderbird
[21:06] <bdrung> s/$/?/
[21:10] <micahg> bdrung: well, I don't want to make more work for fta ATM
[21:11] <micahg> bdrung: you can accomplish this by pinning
[21:12] <bdrung> micahg: where can i read more about pinning?
[21:13] <micahg> bdrung: http://jaqque.sbih.org/kplug/apt-pinning.html, I really need to create a blog and post about it
[21:14] <micahg> bdrung: this is what I was discussing in my MOTU app
[21:16] <micahg> I'll create a formal proposal for UDS-O
[21:16] <chrisccoulson> bdrung, if you don't want the crack of the daililes, then natty is getting ff-4.0 b7 within the next day or so
[21:16] <micahg> and resurrect my apport-browser initiative as well
[21:16] <chrisccoulson> **dailies
[21:16] <chrisccoulson> maybe in a few hours if my laptop hurries up!
[21:17] <bdrung> chrisccoulson: natty is a little bit unstable on real hardware - compiz problem
[21:18]  * micahg thinks that should be compiz is a little unstable everywhere :)
[21:18] <chrisccoulson> bdrung, oh, it's ok here ;)
[21:18] <chrisccoulson> but i'm selective with the packages i upgrade
[21:18]  * micahg has seen a lot of Firefox + compiz bugs lately
[21:18] <bdrung> and some apps can't be installed (e.g. mplayer - some dependency problems)
[21:18] <micahg> I think it's actually related to the drivers and KMS
[21:40] <BUGabundo> evening
[21:46] <bdrung> chrisccoulson: which binary xulrunner package will natty have?
[21:46] <chrisccoulson> bdrung, -2.0
[21:46] <bdrung> chrisccoulson: and will natty have new binary packages besides xulrunner-2.0?
[21:47] <chrisccoulson> bdrung, there shouldn't be any new packages
[21:47] <bdrung> chrisccoulson: will there any packages dropped?
[21:47]  * micahg is hoping that FF4 Beta 7 has better memory management
[21:47] <chrisccoulson> bdrung, i hope we'll drop some packages ;)
[21:47] <chrisccoulson> i'm not sure what yet though
[21:48] <micahg> chrisccoulson: BTW, weave was dropped from testing since it can't be supported in a stable release according to Debian :)
[21:48] <chrisccoulson> heh
[21:48] <chrisccoulson> we can drop weave too!
[21:48] <chrisccoulson> \o/
[21:48] <chrisccoulson> we won't need it in a few hours
[21:48]  * micahg will prepare an SRU for maverick later this month
[21:56] <bdrung> chrisccoulson: will xulrunner-1.9.2 be in natty?
[21:57] <chrisccoulson> bdrung, no, we'll drop that before release
[21:57] <micahg> chrisccoulson: are we sticking with 4.0 even if 4.1 releases (doubtful)?
[21:57] <chrisccoulson> micahg, it depends when (and if) it happens
[21:58] <bdrung> chrisccoulson: is this list correct for natty: http://paste.debian.net/99912/ ?
[21:58] <micahg> chrisccoulson: ok, but we don't have to rush for Lucid and Maverick until 3.6 is close to EOL, right (meaning maybe we can jump to 4.1)?
[21:59] <chrisccoulson> bdrung, yeah, that looks ok
[21:59] <chrisccoulson> micahg - we should probably start the work for lucid and maverick this cycle, even if we skip 4.0
[21:59] <micahg> bdrung: does FF4 need a separate app code?
[21:59] <micahg> chrisccoulson: right, I agree, but we can keep in transitional PPA until we need it, right?
[22:00] <chrisccoulson> micahg, yeah, that's ok
[22:00] <bdrung> micahg: no, because the binary package name doesn't change
[22:00] <micahg> bdrung: ah, ok
[22:00]  * micahg needs to update prism
[22:02]  * micahg tries micahgClone = micahg.clone()
[22:03] <bdrung> micahg: fork() is enough
[22:11] <bdrung> chrisccoulson, micahg: we have to touch all debian/control files in all extensions (add Depends: ${xpi:Depends})
[22:11] <micahg> bdrung: shouldn't we do that in Debian?
[22:12] <micahg> I can take care of the sync/merge requests to Ubuntu
[22:12] <micahg> bdrung: and is that ok with the Debian moz ext team?
[22:12] <bdrung> micahg: yes, we should do it in debian's moz-ext team
[22:13]  * micahg will send a join email later this week
[22:13] <bdrung> micahg: it will affect debian too
[22:13] <micahg> bdrung: I think you should discuss it on the list before making the change since it's fundamental
[22:13] <micahg> unless the tangent that was there already qualifies
[22:14] <bdrung> micahg: yes, i will prepare it and then discuss it
[22:27] <micahg> chrisccoulson: BTW, is the new ubufox backwards compatible with FF36?
[22:28] <chrisccoulson> micahg - unfortunately not
[22:28] <chrisccoulson> it was too much of a pain to make it backwards compatible
[22:28] <micahg> chrisccoulson: hmm, ok, I was thinking to backport it in the firefox-next PPA, but I guess not, anything you think should go in there besides Firefox?
[22:30] <chrisccoulson> micahg - not that i can think of
[23:10] <bdrung> chrisccoulson, micahg: please have a look at the pushed m-d changes
[23:12] <bdrung> chrisccoulson, micahg, fta: can i change m-d to use debhelper 7 or is there a reason against it?
[23:12] <chrisccoulson> none of the mozilla packaging is using dh7 atm
[23:12] <bdrung> that's not a reason against it
[23:16] <chrisccoulson> as long as it doesn't break things, it's ok ;)
[23:30] <micahg> bdrung: well, the backport won't build on hardy, but I don't particularly care about that ATM
[23:32] <micahg> bdrung: is that str thing a bug in python?
[23:32] <bdrung> micahg: maybe?
[23:32] <micahg> bdrung: you might not want to remove xul-1.9.2 yet unless iceweasel in experimental is going to 4.0
[23:33] <bdrung> micahg: but maybe we shouldn't rely on str. the fix works on unstable, maverick, and natty
[23:33] <bdrung> micahg: i removed xul-1.9.2 for ubuntu
[23:33] <micahg> bdrung: ok, but it might be worth asking barry if it's really a bug or not
[23:34] <micahg> bdrung: oh right, sorry I see that now
[23:40] <bdrung> micahg: python2.6 didn't change that much
[23:41] <micahg> bdrung: I thought 2.7 was the default
[23:41] <bdrung> micahg: not yet
[23:41] <micahg> bdrung: ah
[23:42] <bdrung> i assume that it's a change in python-librdf
[23:46] <micahg> bdrung: the only recent change was in the way that string exceptions are handled, maybe this is it
[23:46] <micahg> debian 585299
[23:46] <ubot2> Debian bug 585299 in python-librdf "python-librdf: Python string exceptions no more allowed in Python 2.6" [Minor,Fixed] http://bugs.debian.org/585299
[23:50] <bdrung> hm, not sure