/srv/irclogs.ubuntu.com/2010/11/15/#ubuntu-mozillateam.txt

=== asac_ is now known as asac
bdrungchrisccoulson: m-d uses recommends, but not depends. therefore FF updates are not blocked by extensions14:50
chrisccoulsonbdrung - hmmmm, what's the point in versioning them then?14:51
chrisccoulsonfta - 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:16
chrisccoulsonmicahg - this abrowser-on-XR stuff is a PITA atm. i might have to shelve it for now until i've got more time ;)15:22
micahgchrisccoulson: no worries15:24
chrisccoulsonmicahg - there's quite a few things we need to resolve before we can do it15:24
=== asac_ is now known as asac
chrisccoulsonthe first one being translations - the translations seem to be incompatible due to the different jar packaging formats15:25
micahgchrisccoulson: if you add the tasks to the blueprint, I'll try to help with it15:25
micahgchrisccoulson: that seems weird15:25
chrisccoulsonthe 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 cleanly15:26
chrisccoulsonalso, 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 now15:27
micahgchrisccoulson: well, we can have versioned abrowser packages with a meta abrowser package that always points to the "current" one15:27
chrisccoulsonmicahg - what happens when we add a new version during upgrades though? the user ends up with 2 different copies of abrowser installed15:27
chrisccoulson(with 2 different launchers which look the same)15:28
chrisccoulsonnote, that we can't use conflicts during stable updates, as update-manager doesn't resolve package removals15:28
micahgchrisccoulson: provides, conflicts, replaces: abrowser?15:28
chrisccoulsoni'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 though15:29
chrisccoulsonand then the user has to do apt-get dist-upgrade to resolve it properly15:30
micahgchrisccoulson: 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 risky15:31
chrisccoulsonyeah, we definately don't want to do that. the versioned xulrunner has to stay for now, so we can have them parallel installable15:31
chrisccoulsoni've got abrowser-on-XR building now btw, so i can push my current work to a separate branch for now15:32
micahgchrisccoulson: that sounds good, would a 2 way profile importer help WRT profiles?15:32
chrisccoulsoni'm not sure. possibly, but that might start to make things quite complicated15:33
bdrungchrisccoulson: shouldn't we version recommends?15:40
chrisccoulsonbdrung, 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:45
chrisccoulsonbut if the recommends are installed already, it doesn't make any difference15:46
chrisccoulsonin this case, the extension shouldn't be in the archive anyway ;)15:46
bdrungand moving recommends back to depends and set the min version?15:47
chrisccoulsonmin version is fine for a depends, but anything which makes a transition difficult (which maxversion generally does), wouldn't be so good IMO15:49
bdrungasac, micahg: what do you think about moving recommends to versioned depends (see above)?15:51
* micahg goes to look up depends/recommends definitions in policy manual :)15:53
chrisccoulsonmicahg - https://code.edge.launchpad.net/~mozillateam/xulrunner/xulrunner-2.0.head.abrowser-on-XR15:54
chrisccoulsonthat's what i've got so far, which seems mostly working15:54
micahgbdrung: well, I guess the question is, do the extensions do anything with any other packages not in the m-devscripts added list?15:55
bdrungmicahg: no - all packages that can have xul extensions should be in the list in m-d15:56
micahgbdrung: 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 necessary15:57
micahgOTOH, 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
bdrungmicahg: there won't be a package removal, because we aren't setting a max version. e.g. "firefox (>= 3.5)" would be still valid15:58
* micahg will run out of hands soon... :-/15:58
chrisccoulsonheh ;)15:58
bdrungmicahg: clone yourself! :P15:59
micahgbdrung: yes, but that's not correct in how the extensions for the most part work though15:59
chrisccoulsonyeah, minversion is fine, but i wouldn't be happy with having a maxversion in the depends15:59
bdrunghaving min and maxversion is impossible if we have alternatives15:59
micahgbdrung: right, I saw that discussion on teh Debian extensions list16:00
* micahg thinks that should be a feature request in dpkg :)16:00
bdrunguntil dpkg has this feature, we can only set minversion :)16:01
micahgbdrung: 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
micahgbdrung: might not be a bad idea for Debian though16:03
bdrungyes, that's more a feature for debian16:04
micahgso, 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 Ubuntu16:07
micahgs/and/therefore/16:09
micahgs/therefore//16:11
* micahg needs caffeine16:11
micahgchrisccoulson: sorry, should have cut and pasted our conversation re: pyxpcom16:14
chrisccoulsonmicahg - that's ok ;)16:14
ftachrisccoulson, 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 intervene16:16
ftachrisccoulson, http://bazaar.launchpad.net/~fta/%2Bjunk/ppa-confs/annotate/head:/ppabot-pkgs-umd.conf16:16
chrisccoulsonfta - ok. i wanted to renams firefox-4.0.head to firefox-trunk.head, which would keep that name stable indefinately then16:17
chrisccoulsonand i wanted to take firefox-4.0.head for the official in-archive packaging branch16:18
ftachrisccoulson, from this file, the idea is that the bot either pull from inside $branch if it exists, or bzr branch $lp $branch otherwise16:18
ftaok, just tell me what you want me to rename and to what16:18
chrisccoulsonfta - so, for now, it's just firefox-4.0.head => firefox-trunk.head.16:20
fta(i really hate the colors of the lp code browser.. light gray text on either white/lighter gray/light ping background)16:21
chrisccoulsonyeah, it's not good for the eyes ;)16:21
chrisccoulsonfta - 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
chrisccoulsonalthough, that would most likely change at some point in the future, but there are other issues to resolve before we do that16:27
ftahmm... i remember we had some problems last time we did something like that... i have to look16:33
=== yofel_ is now known as yofel
micahgchrisccoulson: I think we should just push a new branch, like fta said, there were some issues last time16:34
* micahg has to run16:35
chrisccoulsoni don't mind how we go about doing it16:35
chrisccoulsonbasically, 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
chrisccoulsonif i do that in the current firefox-4.0.head, then umd will be building 2 firefox source packages16:36
chrisccoulsonand 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:37
chrisccoulsonurgh, did mozilla bump their cairo version16:38
ftawe can try. i remember something about the package name not matching something.. but i don't really remember16:38
chrisccoulson?16:38
ftai have a bunch of branches to consider: http://paste.ubuntu.com/532432/16:40
ftafunny, i had a firefox-trunk.head branch in 2007 ;)16:44
bdmurrayfta: is the right package name "chrome" or?16:46
ftachrisccoulson, could please rename in lp?16:46
ftabdmurray, chromium-browser is our src package16:47
chrisccoulsonfta - ok, renamed16:47
ftabdmurray, do you need the binary packages too?16:47
bdmurrayfta: just source since that is what lp uses16:47
bdmurrayfta: okay it'll show up today / tomorrow16:51
ftabdmurray, excellent, thanks!16:52
ftachrisccoulson, is trunk still 4.0?16:54
ftaor did moz already moved it to 4.1, 5.0, .. ?16:54
chrisccoulsonfta - yeah16:54
chrisccoulsonit's still 4.0 atm. so, we'll have 2 4.0 branches for a little while, but that's unavoidable i think16:55
ftahttp://paste.ubuntu.com/532442/16:56
ftai can't change the key as it's the src package (which must match d/control and d/changelog)16:57
ftaso the bot can't do two 4.016:57
ftai 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 case16:58
ftawhen that happens, i need to trigger a manual merge16:59
chrisccoulsonfta -that's ok, we're only changing the branch location atm, so the source package stays as firefox-4.0 for now17:01
chrisccoulsonthe new firefox-4.0.head will just have the "firefox" source pacakge, which is what i'm going to upload to natty17:01
chrisccoulsonbut we don't need daily builds of that atm17:02
ftasure17:02
ftaok, trying17:02
chrisccoulsonthanks17:02
ftahold your breath :)17:02
fta(maybe not)17:02
ftachrisccoulson, \o/17:12
chrisccoulsonfta - it worked ok?17:12
chrisccoulsonoh, yeah. excellent, thanks :)17:12
=== davida is now known as davidascher
bdrungmicahg: i fixed bug #67417120:32
ubot2Launchpad 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/67417120:32
micahgbdrung: great, what was the issue?20:33
bdrungmicahg: the __str__ function added the "20:34
micahgbdrung: ah, ok20:35
bdrungit uses now a different function to get the value20:35
* micahg is getting a python book soon20:37
micahgchrisccoulson: which branch are you planning on releasing from to Natty?20:41
chrisccoulsonmicahg - which bzr branch? it will be the new firefox-4.0.head, once i've updated it20:42
chrisccoulsonthat's what i'm doing right now20:42
chrisccoulsonnot sure if it will be tonight, it depends on when i finish testing the upgrade20:42
micahgchrisccoulson: ah, do you want to keep the versioned .head branches?20:42
* micahg was thinking 3 branches, -trunk, -next, and firefox20:43
chrisccoulsonmicahg - 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
micahgchrisccoulson: well, for now, I would suggest using firefox-next for natty20:44
chrisccoulsonthe issue with that is we want the firefox-next packages to be versioned, so that they are parallel installable with the in-archive version20:45
micahgwhen 4.0 is released, we can create the firefox.head branch20:45
chrisccoulsonbut i don't want the natty source package to be versioned20:45
micahgoh right :(20:45
chrisccoulsonhence the split for now20:45
micahgchrisccoulson: ok, I'll merge what you put in the new firefox-4.0 branch into firefox-next when you release for the PPA then20:46
chrisccoulsoncool, thanks20:46
chrisccoulsonhmmm, no asac20:52
chrisccoulsoni could really do with him merging my ubufox changes :)20:52
chrisccoulsonmicahg - perhaps we need to fork ubufox and maintain it in ~mozillateam ;)20:52
chrisccoulsonmicahg - if you take the firefox-next packages from firefox-4.0.head, you'll need to rename the source package to firefox-4.0 too21:00
chrisccoulsonthat *should* just work though21:01
chrisccoulsonif it doesn't, then we need to fix it21:01
bdrungmicahg: could we split the daily build PPA - e.g. i want the daily build for FF, but not for thunderbird21:02
bdrungs/$/?/21:06
micahgbdrung: well, I don't want to make more work for fta ATM21:10
micahgbdrung: you can accomplish this by pinning21:11
bdrungmicahg: where can i read more about pinning?21:12
micahgbdrung: http://jaqque.sbih.org/kplug/apt-pinning.html, I really need to create a blog and post about it21:13
micahgbdrung: this is what I was discussing in my MOTU app21:14
micahgI'll create a formal proposal for UDS-O21:16
chrisccoulsonbdrung, if you don't want the crack of the daililes, then natty is getting ff-4.0 b7 within the next day or so21:16
micahgand resurrect my apport-browser initiative as well21:16
chrisccoulson**dailies21:16
chrisccoulsonmaybe in a few hours if my laptop hurries up!21:16
bdrungchrisccoulson: natty is a little bit unstable on real hardware - compiz problem21:17
* micahg thinks that should be compiz is a little unstable everywhere :)21:18
chrisccoulsonbdrung, oh, it's ok here ;)21:18
chrisccoulsonbut i'm selective with the packages i upgrade21:18
* micahg has seen a lot of Firefox + compiz bugs lately21:18
bdrungand some apps can't be installed (e.g. mplayer - some dependency problems)21:18
micahgI think it's actually related to the drivers and KMS21:18
BUGabundoevening21:40
bdrungchrisccoulson: which binary xulrunner package will natty have?21:46
chrisccoulsonbdrung, -2.021:46
bdrungchrisccoulson: and will natty have new binary packages besides xulrunner-2.0?21:46
chrisccoulsonbdrung, there shouldn't be any new packages21:47
bdrungchrisccoulson: will there any packages dropped?21:47
* micahg is hoping that FF4 Beta 7 has better memory management21:47
chrisccoulsonbdrung, i hope we'll drop some packages ;)21:47
chrisccoulsoni'm not sure what yet though21:47
micahgchrisccoulson: BTW, weave was dropped from testing since it can't be supported in a stable release according to Debian :)21:48
chrisccoulsonheh21:48
chrisccoulsonwe can drop weave too!21:48
chrisccoulson\o/21:48
chrisccoulsonwe won't need it in a few hours21:48
* micahg will prepare an SRU for maverick later this month21:48
bdrungchrisccoulson: will xulrunner-1.9.2 be in natty?21:56
chrisccoulsonbdrung, no, we'll drop that before release21:57
micahgchrisccoulson: are we sticking with 4.0 even if 4.1 releases (doubtful)?21:57
chrisccoulsonmicahg, it depends when (and if) it happens21:57
bdrungchrisccoulson: is this list correct for natty: http://paste.debian.net/99912/ ?21:58
micahgchrisccoulson: 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:58
chrisccoulsonbdrung, yeah, that looks ok21:59
chrisccoulsonmicahg - we should probably start the work for lucid and maverick this cycle, even if we skip 4.021:59
micahgbdrung: does FF4 need a separate app code?21:59
micahgchrisccoulson: right, I agree, but we can keep in transitional PPA until we need it, right?21:59
chrisccoulsonmicahg, yeah, that's ok22:00
bdrungmicahg: no, because the binary package name doesn't change22:00
micahgbdrung: ah, ok22:00
* micahg needs to update prism22:00
* micahg tries micahgClone = micahg.clone()22:02
bdrungmicahg: fork() is enough22:03
bdrungchrisccoulson, micahg: we have to touch all debian/control files in all extensions (add Depends: ${xpi:Depends})22:11
micahgbdrung: shouldn't we do that in Debian?22:11
micahgI can take care of the sync/merge requests to Ubuntu22:12
micahgbdrung: and is that ok with the Debian moz ext team?22:12
bdrungmicahg: yes, we should do it in debian's moz-ext team22:12
* micahg will send a join email later this week22:13
bdrungmicahg: it will affect debian too22:13
micahgbdrung: I think you should discuss it on the list before making the change since it's fundamental22:13
micahgunless the tangent that was there already qualifies22:13
bdrungmicahg: yes, i will prepare it and then discuss it22:14
micahgchrisccoulson: BTW, is the new ubufox backwards compatible with FF36?22:27
chrisccoulsonmicahg - unfortunately not22:28
chrisccoulsonit was too much of a pain to make it backwards compatible22:28
micahgchrisccoulson: 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:28
chrisccoulsonmicahg - not that i can think of22:30
bdrungchrisccoulson, micahg: please have a look at the pushed m-d changes23:10
bdrungchrisccoulson, micahg, fta: can i change m-d to use debhelper 7 or is there a reason against it?23:12
chrisccoulsonnone of the mozilla packaging is using dh7 atm23:12
bdrungthat's not a reason against it23:12
chrisccoulsonas long as it doesn't break things, it's ok ;)23:16
micahgbdrung: well, the backport won't build on hardy, but I don't particularly care about that ATM23:30
micahgbdrung: is that str thing a bug in python?23:32
bdrungmicahg: maybe?23:32
micahgbdrung: you might not want to remove xul-1.9.2 yet unless iceweasel in experimental is going to 4.023:32
bdrungmicahg: but maybe we shouldn't rely on str. the fix works on unstable, maverick, and natty23:33
bdrungmicahg: i removed xul-1.9.2 for ubuntu23:33
micahgbdrung: ok, but it might be worth asking barry if it's really a bug or not23:33
micahgbdrung: oh right, sorry I see that now23:34
bdrungmicahg: python2.6 didn't change that much23:40
micahgbdrung: I thought 2.7 was the default23:41
bdrungmicahg: not yet23:41
micahgbdrung: ah23:41
bdrungi assume that it's a change in python-librdf23:42
micahgbdrung: the only recent change was in the way that string exceptions are handled, maybe this is it23:46
micahgdebian 58529923:46
ubot2Debian bug 585299 in python-librdf "python-librdf: Python string exceptions no more allowed in Python 2.6" [Minor,Fixed] http://bugs.debian.org/58529923:46
bdrunghm, not sure23:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!