[00:09] <asac> fta: did you try to drop courgette?
[00:09] <fta> fighting with it
[00:13] <asac> committed another license checkpoint
[00:15] <Pavlov> hey guys, how do you name xulrunner betas and alphas?
[00:16] <Pavlov> s/name/version/?
[00:16] <Pavlov> multiple ~s
[00:17] <Pavlov> yeah, hm.
[00:17] <asac> Pavlov: NEXTVERSION~b1
[00:17] <asac> e.g. 1.9.2~b1
[00:17] <Pavlov> right
[00:17] <asac> why?
[00:17] <Pavlov> fennec debian versioning hell
[00:18] <asac> you want to wrok on feenec?
[00:18] <Pavlov> i am
[00:18] <asac> or is fennec in debian?
[00:18] <Pavlov> for maemo, actually
[00:18] <asac> cool
[00:18] <asac> you put that in debian?
[00:18] <asac> i think fennec needs 1.9.2
[00:18] <Pavlov> it does
[00:18] <asac> thats not in debian (and not yet in ubuntu, but soon)
[00:18] <Pavlov> no, sorry, i'm actually working _on_ fennec
[00:18] <asac> you can use our dailies
[00:19] <asac> great
[00:19] <asac> for mozilla?
[00:19] <Pavlov> yeah
[00:19] <asac> nice to meat you!
[00:19] <Pavlov> trying to get our debian package versions right
[00:19] <Pavlov> you too
[00:19] <Pavlov> learning all about ~s and such ;/
[00:19] <Pavlov> the hard way!
[00:19] <asac> we have a fennec package ;)
[00:19] <Pavlov> nice
[00:19] <asac> not the latest. but i would suggest to help on that ;)
[00:20] <micahg> 1.0~a2...
[00:20] <asac> or are you doing a package for your internal stuff?
[00:20] <gavin> we have a repo for maemo
[00:20] <asac> https://code.edge.launchpad.net/~mozillateam/fennec/fennec.head
[00:20] <asac> we should share the packaging imo
[00:20] <Pavlov> yeah we need to make a source deb at some point
[00:20] <Pavlov> right now they're built from our build system
[00:21] <asac> if we get the branch up to speed we could easily include it as a daily build in our daily repo
[00:21] <asac> for everything: hardy/intrepid/jaunty/karmic/lucid
[00:22] <asac> https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[00:22] <Pavlov> asac: we're trying to get our versioning stuff "right"
[00:23] <Pavlov> the problem right now is that we've been releasing xulrunner packages like: 1.9.2b6pre-datetime
[00:23] <Pavlov> now we're trying to release 1.9.2-datetime
[00:23] <Pavlov> and well, one is earlier than the other
[00:23] <asac> argh
[00:23] <asac> thats too late then
[00:23] <Pavlov> right
[00:23] <asac> look at our xulrunner version
[00:23] <Pavlov> so i figure we need to bump the epoch
[00:23] <asac> oh ... thats even worse
[00:23] <Pavlov> is it?
[00:23] <asac> how many consumers do you have?
[00:24] <Pavlov> enough that i don't want to tell them to reinstall
[00:24] <asac> at best you could wipe everything ;)
[00:24] <asac> moving ahead of us is a mess :)
[00:24] <Pavlov> heh
[00:24] <asac> well. then you need an epoch.
[00:24] <asac> so we have a mozilla version to ubuntu version script
[00:24] <Pavlov> oh realy?
[00:24] <asac> that is a perfect bi-dirctional mapping
[00:25] <gavin> ooooh
[00:25] <asac> yes
[00:25]  * gavin likes the sound of that
[00:25] <Pavlov> that would be huge huge help
[00:25] <micahg> asac: almost perfect...
[00:25] <asac> its in mozilla-devscripts ... let me check
[00:25] <asac> micahg: alḿost? afaik its not lossy
[00:25] <micahg> prism...
[00:25] <asac> well. prism doesn use that script ;)
[00:26] <asac> its rather new for our automagic extension dependency stuff
[00:26] <micahg> asac: ah, right
[00:26] <micahg> so the script is perfect :)
[00:26]  * micahg needs to fix prism..
[00:26] <Pavlov> asac: do you have al ink to the right place?
[00:26]  * asac looks it up
[00:26] <asac> ;)
[00:26] <asac> http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/annotate/head:/src/moz_version.py
[00:27] <asac> its a lib
[00:27] <asac> but we could make a command line tool out of it
[00:27] <asac> just say what you want ;)
[00:27] <asac> bdrung: ?
[00:28] <asac> bdrung: moztodebian version ... thought we had a wrapper for that too ;)
[00:28] <asac> http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/annotate/head:/src/moz-version
[00:28] <bdrung> asac: yes. i added that. please check if it works correctly
[00:29] <asac> bdrung: what Pavlov needs is moztodebian
[00:29] <asac> where is that?
[00:29] <bdrung> asac: i can write that easily
[00:29] <Pavlov> that would be awesome
[00:29] <asac> that would be fantastic and you would get hugs from Pavlov ;)
[00:29] <Pavlov> many hugs
[00:29] <bdrung> asac: how should i call this moz-version parameter?
[00:30] <Pavlov> gavin: wonder if we can just use these in the build system?
[00:30] <asac> bdrung: either --to-moz .. --to-deb ... or make two high level wrappers
[00:30] <asac> Pavlov: once they are done you could copy them in worst case
[00:30] <Pavlov> yeah
[00:31] <bdrung> asac:  high level wrappers?
[00:31] <asac> soo ... epoch is bad because that would kind of kill the ecosystem ;) ... what we should do is do something ugly for 1.9.2 so you can go back to normal when 1.9.3 arrives
[00:31] <Pavlov> any suggestions?
[00:31] <asac> bdrung: like moz-to-debian ... debian-to-moz
[00:31] <Pavlov> can we do 1.9.2+foo?
[00:31] <Pavlov> or something?
[00:31] <asac> what was your current version?
[00:32] <asac> yeah. so you can do CURRENT_VERSION+REALVERSION
[00:32] <bdrung> asac: no, i put it into moz-version
[00:32] <asac> so 1.9.2fuckedup+1.9.2~b2~hg20090920
[00:32] <asac> for the snapshot from 20th sep 2009
[00:32] <asac> pre beta2
[00:32] <asac> bdrung: if that works
[00:33] <asac> --to-moz --to-deb
[00:33] <bdrung> asac: the infrastructure is there
[00:33] <asac> or whatever you think is better ;)
[00:33] <micahg> asac: is this part of the in package mozclient?
[00:33] <Pavlov> asac: our last real thing was xulrunner_1.9.2b6pre-20091231145857_armel.deb
[00:33] <bdrung> asac: and how to call the one char parameter?
[00:34] <asac> dpkg --compare-versions 1.9.2fuckedup+1.9.2~b2~hg20090920 lt 1.9.3~a1~xxx && echo yes
[00:34] <asac> yes
[00:34] <asac> so that works
[00:34] <gavin> Pavlov: yeah probably - DEB_VERSION = $(shell moztodebian MOZ_APP_VERSION) or whatever
[00:34] <asac> Pavlov: so you build native packages ;)?
[00:34]  * asac wonders if that would be compared as if it was debian revision
[00:34]  * asac checks
[00:35] <Pavlov> the version is..
[00:35] <asac> dpkg --compare-versions 1.9.2b6pre-20091231145857+1.9.2~b6~20091231145857 lt 1.9.3~a1~xxx && echo yes
[00:35] <Pavlov> Version: 1.9.2b6pre-20091231145857
[00:35] <bdrung> asac: what do you think about "moz-version --to-deb 1.2.3 --epoch 2"?
[00:36] <asac> if you want epoch ... but i would like to hide that feature ;)
[00:36] <bdrung> asac: i can implement it but do not add a parameter until it is required
[00:36] <Pavlov> dpkg --compare-versions 1.9.2b6pre-200912311458571 lt 1.9.2+ && echo yes ? :)
[00:36] <asac> yeah
[00:36] <asac> oh ;)
[00:37] <asac> yeah
[00:37] <asac> so good
[00:37] <asac> you can do that
[00:37] <asac> 1.9.2+1.9.2~b6~20091231145857
[00:37] <asac> ;)
[00:37] <asac> ugly
[00:37] <asac> but better
[00:37] <Pavlov> well
[00:38] <Pavlov> this would be for 1.9.2 itself
[00:38] <Pavlov> no beta
[00:38] <Pavlov> can put a date if you think that is good
[00:39] <Pavlov> 1.9.2+~20100107133804 ?
[00:39] <asac> let me check something
[00:39] <Pavlov> we might have a 1.9.2.x, or some other things, i guess
[00:40] <asac> so yeah. until 1.9.2 is final, use that or whatever you want
[00:40] <asac> after that, why dont you pocket copy our xulrunner packages daily?
[00:40] <Pavlov> 1.9.2 is final
[00:40] <asac> is it?
[00:40] <Pavlov> or rc2
[00:40] <asac> its rc2
[00:40] <Pavlov> er, rc1
[00:40] <asac> right
[00:40] <asac> so its not yet;)
[00:41] <asac> otherwise you could directly use our package versions
[00:41] <asac> we have 1.9.2+nobinonly... ;)
[00:41] <asac> but before final its 1.9.2~rc2...
[00:41] <Pavlov> well
[00:41] <Pavlov> the way our release process usually works is that we call the rcs the final version
[00:42] <Pavlov> at least internally
[00:42] <asac> right.
[00:42] <Pavlov> we can call the debian version rc1 i guess
[00:42] <asac> so ... rc1 is a bit special because it gets its own version right?
[00:42] <asac> so for stable updates we do:
[00:42] <Pavlov> it doesn't
[00:42] <asac> 1.9.2+build1
[00:42] <asac> 1.9.2+build2
[00:42] <asac> 1.9.2+build3
[00:42] <Pavlov> right
[00:42] <Pavlov> so right now we have:
[00:42] <asac> and whatever is last gets released
[00:42] <Pavlov> 1.9.2b6pre-20091231145857
[00:43] <Pavlov> and 1.9.2-20100107133804
[00:43] <asac> yeah. so you could release as 1.9.2+build1 now
[00:43] <Pavlov> ok
[00:43] <asac> if thats ok
[00:43] <Pavlov> yeah
[00:43] <asac> and if you dont like +nobinonly (which we add for final builds if we spin one)
[00:43] <asac> you can say: +final
[00:43] <Pavlov> right
[00:43] <micahg> asac: what if there are multiple rcs?
[00:43] <asac> but if you are fine to just sticking with +build3
[00:43] <asac> then its fine
[00:43] <asac> micahg: build1 is rc1 usually
[00:43] <asac> build2 is rc2
[00:43] <Pavlov> gavin: how do you feel about just adding a +rc1 to the version on the rc branch?
[00:44] <asac> except for the prerelease rampup time
[00:44] <Pavlov> er, rel branch?
[00:44] <gavin> sounds good to me
[00:44] <asac> Pavlov: be careful
[00:44] <asac> rc > final
[00:44] <asac> build1 < final
[00:44]  * Pavlov grumbles ;p
[00:44] <asac> if you stick with rc3 then its fine
[00:44] <asac> oh you can ro
[00:44] <Pavlov> we will
[00:44] <asac> rc1
[00:44] <asac> rc2
[00:44] <asac> release
[00:44] <asac> :-P
[00:44] <Pavlov> someone should have worked on this versioning stuff a bit more;p
[00:44] <asac> in case ;)
[00:45] <asac> yeah. but you are lucky it seems
[00:45] <Pavlov> we have to fix our 1.9.3 people
[00:45] <Pavlov> but no one is really on that channel
[00:45] <asac> yeah. just wipe that
[00:45] <Pavlov> so we can fix it to use the script you guys have
[00:45] <micahg> hmm Fennec went from FENNEC_1_0_RELEASE to FENNEC_1_0rc2_RELEASE...
[00:46] <asac> micahg: they usually add both tags
[00:46] <fta> micahg, no, _RELEASE is fake, it's a moving tag
[00:46] <asac> and then if it needs a respin move the _RELEASE tag
[00:46] <asac> but i would have expected
[00:46] <micahg> ah
[00:46] <gavin> yeah each RC will have a tag, and the one we ship will also have RELEASE
[00:46] <asac> FENNEC_1_0_BUILD1 ;)
[00:46] <asac> tats what is used everywhere else
[00:46] <gavin> yeah, mobile is a bit different
[00:47] <asac> but then: imo the pre-final RCs are different from the RCs for stable updates
[00:47] <gavin> I can ask our build guy about that
[00:47] <micahg> then FENNEC_1_0_BUILD2, then FENNEC_1_0rc2_BUILD1, then FENNEC_1_0rc2_BUILD2
[00:47] <asac> i really think that the pre release rcs are different
[00:47] <Pavlov> gavin: http://pastebin.mozilla.org/695534 ? :)
[00:47] <asac> you even have a 3.0rc1 or something in application.ini
[00:47] <asac> in RCs as in stable updates you have just moving tags
[00:48] <gavin> Pavlov: looks good to me
[00:49] <asac> hope you do well ;) ... in the end i would still suggest that you sync our daily packages ;)
[00:49] <asac> for 1.9.3
[00:49] <asac> etc.
[00:49] <Pavlov> well
[00:49] <Pavlov> we build our own packages
[00:49] <Pavlov> daily
[00:49] <Pavlov> for maemo
[00:49] <bdrung> asac: what do you think about this: http://paste2.org/p/599114
[00:49] <Pavlov> i would assume you guys aren't building daily maemo5 packages
[00:50] <asac> we are building daily sources
[00:50] <Pavlov> ah
[00:50] <asac> you just sync those and spin them
[00:50] <asac> think about it ;)
[00:50] <asac> still some time ahead
[00:50] <asac> there are risks for dowstreams ... but also a big win ;)
[00:51] <asac> but you dont have a build system for debs i guess?
[00:51] <asac> Pavlov: how do you build fennec deb? are you spinning whole xulrunner? or are you just copying the build system and use --with-libxul-sdk?
[00:52] <asac> bdrung: err. install .xpi file? e.g. without unpacking?
[00:52] <asac> oh ;)
[00:53] <asac> misread
[00:53] <bdrung> asac: better explanations are welcome
[00:53] <asac> bdrung: thats good. somewhat similar to the deprecated thing we talked about ... did that work out btw?
[00:54] <asac> Pavlov: btw, are you X-compiling for arm? or do you have native builders?
[00:54] <bdrung> asac: i removed the depracated variable, the packages still build and should work (e.g. there was thunderbird in the list and install-xpi creates a link for thunderbird)
[00:54] <Pavlov> asac: we're using scratchbox
[00:55] <asac> bdrung: ok.
[00:56] <bdrung> asac: i need this install-dir parameter for gears (it plays with the file after installation)
[00:56] <asac> gears? doesnt that ship a proper .xpi?
[00:56] <asac> why doesnt the auto detection work?
[00:58] <bdrung> asac: it wan't some files in /usr/share and some in /usr/lib
[00:58] <bdrung> asac: i assumes that the xpi is installed in /usr/share (but 0.18 installs it in /usr/lib -> ftbfs)
[00:59] <gavin> asac: we use --with-libxul-sdk and a two-stop build (i.e. MOZ_BUILD_PROJECTS)
[00:59] <gavin> two-step*
[01:00] <asac> gavin: what i am wondering about is that we manually pack up the xulrunner build system and ship that as part of xulrunner-dev
[01:00] <asac> and now that you probably need something like that maybe we can do something better upstream
[01:00] <gavin> builds xulrunner, then fennec, then fennec's build scripts package both into debs
[01:00] <bdrung> asac: all xul extension build (some after patching)
[01:00] <asac> so basically fennec build unpacks the build system for us at the beginning
[01:01] <asac> gavin: yeah. so you still have the full source tree ;)
[01:01] <gavin> yes
[01:01] <asac> the build system packup as part of xul sdk is quite nice. i would think it just needs to be standardized so all xulapps and extensions could use that
[01:02] <asac> s/could/would/
[01:02] <asac> probably would require a single script or something that everyone wuld includ ein top level dir of its xulapp
[01:02] <asac> this also would help stop xulapps from patching xulrunner ;) .. because they just dont have all the source at hand
[01:02] <bdrung> asac: build system packup for extension? isn't xpi-pack enough?
[01:02] <asac> and adding the full tree would make a slink build heavy wait
[01:03] <asac> bdrung: native extensions
[01:03] <gavin> we already have that
[01:03] <gavin> http://mxr.mozilla.org/mobile-browser/source/installer/Makefile.in#115
[01:03] <gavin> fennec just calls into the existing xulrunner packaging stuff
[01:03] <asac> gavin: thats packaging at the end
[01:03] <asac> i am talking about checking out the fennec tree
[01:03] <asac> and then run a script to get the build system from the xulrunner sdk
[01:04] <asac> or is that what you posted?
[01:04] <gavin> no
[01:04] <gavin> I misunderstood what you meant
[01:04] <asac> if you currently read build instructions on how to build fennec or xulapps you always need the full tree
[01:05] <asac> i want them to just use the build system
[01:05] <asac> but not as a hard copy, rather on the fly
[01:05] <asac> from the sdk
[01:05] <asac> is that better worded ?
[01:05] <gavin> yeah I see what you mean
[01:06] <asac> at best it wouldnt need to copy it but just include /usr/lib/xulrunner-devel/...sdk/build-system.mk
[01:06] <gavin> we don't really benefit from doing any of that work, though
[01:06] <gavin> and the build system isn't that self-contained
[01:06] <asac> it helps the xulrunner eco system ;)
[01:06] <asac> gavin: its not that bad anymore ;)
[01:07] <asac> basically you can unpack the build system nowadays and ./configure --application=yourcoolapp
[01:07] <asac> there are some rough edges
[01:09] <gavin> well yeah, that's what we do, it's just done manually :)
[01:09] <asac> scp /usr/lib/xulrunner-devel-1.9.1.6/sdk/build-system.tar.gz rookery.canonical.com:public_html/tmp/
[01:09] <asac> -> http://people.canonical.com/~asac/tmp/build-system.tar.gz
[01:09] <asac> right. i think it just needs some infrastructure and then evangilism so all the xulapps start to ship a full xulrunner copy
[01:10] <asac> tar tzf build-system.tar.gz  | pastebinit
[01:10] <asac> http://pastebin.com/f5c4fdf59
[01:10]  * gavin made the mistake of extracting that to ~/
[01:10] <asac> ouch
[01:10] <asac> tar tzf | xargs rm ;)
[01:11] <asac> take care :)
[01:11] <asac> imo would need some magic default .mk that all xulapps could ship on top level
[01:12] <asac> and then allow that whole thing to work even if its under build-system/
[01:12] <asac> (so it doesnt clutter the whole source tree)
[01:13] <Pavlov> hmm, did we sort out the version script thing?
[01:13] <Pavlov> too many version numbers melt my brain :(
[01:13] <bdrung> asac: btw, m-d 0.19 is faster than v0.18
[01:14] <asac> Pavlov: from what i understood you are going to use 1.9.2+rc1 ;)
[01:15] <Pavlov> oh, we are
[01:15] <Pavlov> for today;)
[01:15] <asac> i am not yet sure how you do the dailies afterwards then :)
[01:15] <asac> hehe
[01:15] <asac> so i would still suggest to go for OLDVERSION+NEWVERSION
[01:15] <asac> and then just adapt whatever great new versioning scheme we decide on
[01:15] <asac> for NEWVERSION
[01:15] <fta> asac, all fine without courgette now. at last
[01:15] <asac> and from 1.9.3 on just use OLDVERSION
[01:16] <Pavlov> 1.1~a1~datetime seems ok
[01:16] <Pavlov> or for xulrunner, 1.9.3~a1~datetime?
[01:16] <asac> our script will produce a good version for the thing that is in application.ini
[01:16] <asac> Pavlov: yes. thats basically it.
[01:16] <Pavlov> how does it deal with releases and other stuff
[01:16] <Pavlov> or do you set some env var to add +foo to things?
[01:17] <asac> i would suggest this:
[01:17] <asac> if you have version 1.9a1pre ... the script would cut of the pre and remember that its a daily
[01:17] <Pavlov> yep
[01:17] <asac> the you run the version through the moz-to-version thing we produce
[01:17] <asac> and if its remembered daily, append ~DATETIME
[01:18] <asac> we use
[01:18] <asac> hgDATEtTIME
[01:18] <asac> ;)
[01:18] <asac> 1.9.3~a1~hg20091227r36701+nobinonly-
[01:18] <asac> oh now we use r
[01:18] <asac> rather than time
[01:18] <asac> thats good
[01:18] <asac> i think you should adopt that ;)
[01:18] <Pavlov> heh
[01:18] <asac> i think the problem is that hg doesnt always move ahead
[01:18] <Pavlov> right
[01:18] <asac> thats why we wnet to r rather than t
[01:19] <Pavlov> well, those are local
[01:19] <bdrung> asac: do the xulapps check a directory in /usr/share for extensions?
[01:19] <Pavlov> not necessarily global
[01:19] <asac> Pavlov: its better to use a reproducible version
[01:19] <asac> so we use versions that we know we can recreate the source for
[01:19] <Pavlov> yeah those are hex
[01:19] <Pavlov> heh
[01:19] <asac> if you use build system local time then you cannot do that
[01:20] <asac> problem is that you have xulrunner also checked out
[01:20] <asac> so you either build xulrunner independently (like we do)
[01:20] <asac> or you declare it a DEP
[01:20] <asac> and have a DEP file with the current revision in fennec or something
[01:21] <asac> so just reproducing the same fennec tree will allow you to also reproduce xulrunner
[01:21] <asac> makes sense ? ;)
[01:21] <asac> (its late)
[01:22] <asac> ok now you distracted me from what i wanted to do this night initially ;)
[01:23] <asac> fta: i think we are close:
[01:23] <asac> http://pastebin.com/f48ffd9fb
[01:23] <asac> unless i messed up something completely (not that anyone would spot that in this 1Million line copyright file ;)
[01:24] <asac> hmm "Public Domain" isnt whitelisted it seems
[01:25] <asac> maybe that should be case insensitive ;)
[01:25] <asac> fixed
[01:25] <asac> fta: waiting for a fresh stripped tarball ... to see if stripped the same stuff you stripped now
[01:28] <asac> http://people.canonical.com/~asac/tmp/copyright.full
[01:33] <fta> i stripped everything you asked except sdch/open-vcdiff
[01:34] <asac> yeah. those are still in the probs
[01:36] <fta> -rw-r--r-- 1 fta fta 87406668 2010-01-07 04:10 chromium-browser_4.0.292.0~svn20100107r35689.orig.tar.gz
[01:36] <fta> -rw-r--r-- 1 fta fta 80988593 2010-01-08 01:25 chromium-browser_4.0.293.0~svn20100108r35757.orig.tar.gz
[01:36] <fta> -7%
[01:37] <asac> cool ;)
[01:37] <asac> hope it was not 07 to 08 ;)
[01:37] <asac> but our stripping
[01:41] <fta> why do you have build-tree/src/base/third_party/purify/* twice with different Copyright?
[01:44] <Pavlov> asac: hey, lets say we pulled xulrunner in to our fennec package
[01:44] <Pavlov> what would be the best way to deprecate the xulrunner one?
[01:48] <asac> Pavlov: you want to deprecate xulrunner?
[01:48] <asac> heh
[01:48] <asac> ok
[01:49] <asac> do you want all folks that just have your xulrunner to automatically get fennec?
[01:49] <asac> if so, you add transitional packages to fennec
[01:49] <asac> but ... are you sure maemo doesnt have xulrunner?
[01:55] <Pavlov> yes
[01:55] <Pavlov> it has xulrunner, but not installed like xulrunner
[02:01] <micahg> _Tsk_: is there anything we can do about mozilla 534651
[02:02] <asac> 03:00 < StevenK> asac: gyp looks okay, aside from the OMG-my-eyes-are-bleeding debian/rules.
[02:02] <asac> fta: ^^
[02:02] <asac> so ... go ahead
[02:02] <asac> finish this stuff
[02:03] <fta> then he will cry in front of chromium ;)
[02:03] <asac> fta: already prepared him ;)
[02:03] <asac> feeding him copyright.full and the pastebin
[02:03] <asac> fta: can you upload that now or do you want him to upload
[02:04] <fta> what? gyp to lucid?
[02:04] <asac> he would do the changelog bump to -0ubuntu1
[02:04] <asac> yes
[02:04] <asac> what version do you have?
[02:04] <fta> 0.1~svn770-0ubuntu1
[02:04] <asac> right
[02:04] <asac> upload that with the bug closed
[02:04] <fta> ok
[02:07] <asac> what is in debian/rules?
[02:07] <asac> he said he didnt like it ;)
[02:07] <fta> done
[02:07] <asac> oh get-orig-source
[02:07] <fta> 4 lines of python, + get orig
[02:08] <asac> ok now the usual its past 22pm reminder ;)
[02:08]  * asac off
[02:08] <fta> off too
[02:08] <fta> ++
[02:08] <asac> did you do everything right or do i need to wait
[02:08] <asac> fta: ?
[02:08] <Pavlov> hm
[02:08] <asac> e.g. ensure that its in the archive?
[02:08] <Pavlov> time for one more dumb question?
[02:08] <asac> its 3am ;)
[02:09] <fta> "Successfully uploaded packages."
[02:09] <asac> fta: well. sometimes it gets rejected because of something bad ... especially at 3am ;)
[02:09] <Pavlov> if we did merge fennec and xulrunner, we'd need some kind of version that has both things in them :/
[02:09] <asac> bogus checksum etc.
[02:09] <Pavlov> oh hm thats not true
[02:09] <Pavlov> nevermind
[02:09] <Pavlov> get some sleep
[02:09] <Pavlov> :)
[02:09] <asac> Pavlov: yes. i already asked above:
[02:09] <asac> 02:48 < asac> heh
[02:09] <asac> 02:48 < asac> ok
[02:09] <asac> 02:49 < asac> do you want all folks that just have your xulrunner to automatically get fennec?
[02:09] <asac> 02:49 < asac> if so, you add transitional packages to fennec
[02:10] <asac> 02:49 < asac> but ... are you sure maemo doesnt have xulrunner?
[02:10] <asac> but lets talk tomorrow ;)
[02:10] <Pavlov> ok
[02:10] <Pavlov> thanks again for your help
[02:10] <fta> asac, got the NEW email
[02:11] <asac> good
[02:11] <asac> fta: good night!!
[02:11] <fta> asac, thx, you too
[08:44] <_Tsk__> micahg:  how do you feel about making a patch ?
[08:44] <micahg> _Tsk__: if I knew what to patch, I would be happy to try :)
[08:45] <_Tsk__> can you come to irc.mozilla.org in #maildev and ask that specific question to standard8
[08:46] <micahg> _Tsk__: k, I'll have to do it a little later though, it's too late for me right now to concentrate on that (almost 3AM)
[08:46] <micahg> thanks _Tsk__
[08:46] <_Tsk__> elcome
[09:11] <micahg> _Tsk_: one last Q, you know what tz Standard8 is in?
[09:12] <_Tsk_> BST
[09:13] <micahg> ugh, so I better ask now I guess, otherwise when I get up, he'll be gone for the weekend
[09:16] <_Tsk_> he stays late - but yes that would be wise
[09:45] <asac> BST ... its 9:45 for BST (if thtas british)
[09:45] <asac> ah ... guess its late for micahg ;)
[09:46] <micahg> asac: yes :)
[09:46] <micahg> wanted to catch standard 8
[09:46] <asac> making a patch?
[09:46] <asac> whats that about?
[09:46] <asac> fixing tbird?
[09:46] <micahg> and try to figure out this devel thing for tb3
[09:46] <micahg> yeah
[09:46] <asac> glorious ;)
[09:46] <asac> what bug?
[09:46] <asac> ah -devel packages
[09:46] <asac> cool
[09:47] <micahg> asac: wanna hop in the mail-dev channel?
[09:47] <asac> i am not in there?
[09:47] <asac> now i am ;)
[10:05] <micahg> asac: if I tell debuild not to purge, if it completes, can I still see the full dir structure?
[10:06] <asac> debuild -nc is fine
[10:06] <asac> you might need to remove the build-stamp
[10:06] <asac> otherwise it skips it and doesnt see that you changed something
[10:06] <asac> or the install-stamp if you want to just test make install
[10:06] <asac> or nothing if you just want to test the debian packaging install stuff
[10:07] <asac> so yes. its highly recommended to develop dewbian packaging by running debuild -nc rather than a full builds
[10:07] <asac> saves you hours ;)
[10:07] <asac> or even days
[10:08] <asac> just in the end remember to do a full spin to verify ... and remember to copy stuff to your bzr tree before it gets purged next time by accident
[10:08] <micahg> that's the thing you gave me before that I couldn't remember
[10:09] <micahg> ok, I'll try this sat night
[10:09] <asac> ccheney: heya
[10:09] <asac> ccheney: status update?
[10:09] <micahg> I have to get some sleep now and probably won't get to it when I get up tomorrow
[10:09] <micahg> short day
[10:30] <asac> crimsun: hey. old nick ;)?
[12:01] <BUGabundo_work> morning
[12:06] <fta> asac, http://code.google.com/p/chromium/issues/detail?id=308103
[12:06] <fta> asac, http://code.google.com/p/chromium/issues/detail?id=30810
[12:06] <fta> BUGabundo_work, lo
[12:08] <asac> create symlinks?
[12:08] <asac> is that done on first run?
[12:08] <asac> thats messy
[12:09] <fta> that's their wrapper, i don't use it
[12:09] <fta> i have mine
[12:11] <asac> why does redhat have the wrapper in their svn?
[12:11] <asac> does redhat create symlinks in the system lib dir?
[12:11] <asac> or is that in profile?
[12:12] <fta> no, upstream is doing a deb and a rpm
[12:12] <fta> i don't think fedora ships this wrapper either
[12:12] <fta> i will ask
[12:15] <asac> so what does it do? need root access?
[12:21] <fta> seems like it :P
[12:22] <asac> that should get removed imo
[12:22] <asac> something like that is not really something ever to be done again ;)
[12:23] <asac> someone needs to see that and stop it ;)
[12:23] <fta> they don't use sudo or anything so it most likely doesn't work at all
[12:23] <asac> hmm. i think they ship it like the firefox tar.gz
[12:23] <asac> so you can unpack in your home
[12:24] <fta> but not when used through the deb or rpm
[12:35] <fta> it's a bad idea but i don't see what else they could do
[12:35] <fta> they have only 1 binary for a bunch of distros
[12:54] <asac> yeah
[12:54] <asac> ship more ;)
[12:54] <asac> in-sorce
[13:14] <fta> asac, i can't find an obvious culprit for the chromium regression. i hope it's not one of our changes from yesterday..
[13:22] <BUGabundo_work> hello fta
[13:22] <BUGabundo_work> chromium unbroken ?
[13:22] <fta> nope
[13:23] <BUGabundo_work> :\
[13:23] <BUGabundo_work> then i'll pin Ch down !
[13:23] <fta> http://code.google.com/p/chromium/issues/detail?id=31809
[13:23] <fta> star it
[13:23] <fta> but don't add a me too
[13:25] <BUGabundo_work> fta: i'm not new to BTS :o
[13:25] <BUGabundo_work> well glad i have my old debs locally
[13:26] <BUGabundo_work> i'll downgrade to one of those if need be
[14:20] <asac> fta: thoought there is a bug upstream
[14:21] <asac> are all those using our packages?
[14:21] <asac> fta: you can spin chromium with tarball from two days ago to test
[14:21] <asac> if its our thing
[14:21] <asac> e.g. run the cleanup stuff etc. on the old tarball
[14:22] <fta> it's all from the daily ppa, but it's the only widely used daily so i'm not sure
[14:23] <fta> could also be the gl build-deps
[14:24] <fta> did you try it? (you don't use the nvidia driver iirc)
[14:24] <fta> asac, ^^
[14:25] <BUGabundo_work> bla
[14:25] <BUGabundo_work> bug 504149
[14:53] <fta> asac, too many changes. i've created two up-to-date tarballs, one with the get-orig-source from 2 days ago, and one with the new rule
[14:53] <fta> but there's also the gl build-deps
[14:54] <fta> not sure which one try 1st
[14:54] <fta> i need the gl deps to build
[14:56] <asac> try the last yo uknow that worked
[14:56] <asac> run the removal and see if it works
[14:56] <asac> if so we can rule out its the stripping
[15:09] <fta> asac, http://code.google.com/p/gyp/issues/detail?id=133  => fixed
[15:17] <ccheney> asac: was working on openoffice yesterday and ran into some sort of build breakage due to what appears to be lucid :-\
[15:18] <asac> fta: cool
[15:21] <fta> asac, i didn't check, is it enough?
[15:22] <asac> will check after release meeting
[15:22] <asac> have to do the report now :(
[15:22] <asac> ccheney: pleaes dont upload ooo before a2
[15:22] <asac> you will certainly bust our arm images with that
[15:23] <asac> ccheney: ooo is painful, so consider to continue 30% of day on the backporting  ;)
[15:23] <asac> much more fun
[15:24] <ccheney> asac: slangasek asked for OOo upload specifically because images are already oversized
[15:24] <ccheney> alternate cd for i386 or amd64 iirc
[15:26] <fta> asac, *sigh* http://paste.ubuntu.com/353513/
[15:26] <asac> please provide context
[15:26] <asac> ;)
[15:26] <asac> what tarball etc.
[15:26] <vish> asac: hi.. [mac_v here] reminding Bug #386900 :)  could you target it to a milestone which would ensure it is fixed for Lucid?
[15:28] <ccheney> asac: i just heard how to hopefully fix the OOo issue so i will be rebuilding 3.1.1 instead of 3.2.0 if it works and uploading it so hopefully it won't hurt arm, plus there is another arm patch to include from doko.
[15:31] <asac> does that fix the oversize issues?
[15:31] <asac> hopefully is really not enough
[15:31] <asac> if you upload that and it breaks it means no image for a2 for arm
[15:31] <asac> i ping slangasek. lets see
[15:32] <asac> bug  * Bug:431963: linux-fsl-imx51: io/fs errors when launching gdm on imx51 with sata
[15:33] <asac> bug 431963
[15:33]  * vish wonders if asac noticed previous message ...
[15:37] <fta> asac, x64 host, 32bit builder, v8 is confused. seems it's a regression
[15:41] <ccheney> asac: yea it fixes the issue due to not needing old icu library anymore from what slangasek told me
[15:41] <ccheney> asac: the old library is currently using 7MB on the disk from what he said
[16:22] <fta> asac, fresh rev without yesterday's stripping, NOK
[16:22] <asac> good
[16:22] <fta> well, sort of :)
[16:22] <asac> if its the same issue we could rule out the stripping, but trying with a good checkpoint would be better to verify
[16:46] <micahg> bdrung: the dailies broke after yesterday's updates
[16:47] <bdrung> micahg: dailies of what?
[16:47] <micahg> bdrung: xul192, prism, tb3
[16:48] <micahg> I think it's based on the new m-dev in lucid
[16:48] <micahg> hmm
[16:48] <micahg> nm
[16:48] <micahg> it must be something else
[16:49] <bdrung> micahg: do you updated the m-d in the ppa?
[16:49] <micahg> but prism I know is due to some of the changes
[16:49] <micahg> prism is due to its own changes
[16:49] <micahg> the other 2 I'm not sure
[16:49] <bdrung> micahg: do you have a link to the ppa?
[16:49] <micahg> since it was only on lucid
[16:49] <micahg> https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+packages
[16:50] <micahg> hmm
[16:50] <micahg> maybe there isn't an issue afterall
[16:50]  * micahg was tired when I discovered it
[16:51] <micahg> probably just need to wait for tomorrow so there's an updated m-dev
[16:51] <micahg> bdrung: don't worry about it
[16:53] <micahg> bdrung: can we update the packages to require a certain version of m-dev if that's the case?
[16:55] <bdrung> micahg: the build failure thunderbird-3.1 can be due to m-d, but the other package have probably other reasons. in m-d i have only changes the extension part (xpi.mk and such tools)
[16:55] <micahg> bdrung: I think TB31 is upstream
[16:55] <bdrung> k
[16:55]  * micahg already has to fix that
[16:56] <micahg> they updated their configure file and it doesn't like our changing the binary name
[16:57] <micahg> what about this in prism:  with open("debian/control") as f:             ^ SyntaxError: invalid syntax
[16:57] <micahg> hardy and intrepid use python 2.5
[16:58] <asac> ok ... so i promissed to do something after releas meeting ;) ... what was that?
[16:59] <micahg> asac: do we have to make everything in dailies backport properly?
[16:59] <micahg> prism is failing on some python code that's valid in 2.6 but not 2.5
[17:01] <asac> hmm.
[17:02] <asac> what python code is that?
[17:02] <micahg> with open("debian/control") as f:             ^ SyntaxError: invalid syntax
[17:02] <asac> its probably again itchy developers jumping on latest api crap without rason ;)
[17:02] <micahg> it's something in m-dev
[17:02] <asac> micahg: can you check if that is fixable? if you dont figure i can check, but maybe a good excersize for python :-P
[17:03] <asac> m-dev?
[17:03] <micahg> mozilla-devscripts
[17:03] <asac> in our package?
[17:03] <asac> then tell that bdrung
[17:03] <asac> bdrung: dont use python 2.6 in m-dev
[17:03] <asac> we need backports
[17:03] <asac> 18:02 < asac> its probably again itchy developers jumping on latest api crap without rason ;)
[17:03] <asac> please
[17:03] <asac> ;)
[17:03] <asac> thx
[17:04] <asac> i am running around evangelising folks to not use latest API stuff to improve the linux ecosystem ... so mozillateam should try to be good example ;)
[17:05] <asac> great that we spotted that
[17:05] <asac> thx fta for pushing devscripts to daily
[17:06] <fta> it's supposed to be automatic
[17:06] <fta> it didn't work?
[17:06] <fta> branch nick: mozilla-devscripts.daily
[17:06] <fta> timestamp: Fri 2010-01-08 05:25:25 +0100
[17:06] <fta> message:
[17:06] <fta>   * Merge with mozilla-devscripts #302
[17:07] <asac> fta: it worked ;)
[17:07] <asac> read a bit back
[17:07] <asac> like last 25 lines
[17:07] <fta> asac, oh, it was not a request, lol. nm then
[17:07] <asac> it just revealed a bug in python code
[17:07] <asac> fta: it was a kudo
[17:08] <fta> :)
[17:08] <asac> if i say thx i _always_ mean it that wy
[17:08] <asac> way
[17:08] <asac> would never be that impolite/sarcastic
[17:36] <bdrung> asac: sorry, i tried to avoid python 2.6 (but that slipped through)
[17:37] <asac> no problem ;)
[17:37] <asac> i should have thought about that and ask to test it
[17:38] <asac> guess its a one minute fix for you ;)
[17:39] <bdrung> asac: yes, will fix it
[17:39] <bdrung> asac: after finishing moz-version
[17:39] <asac> thx
[17:39] <asac> i think next daily run is 4am UTC
[17:39] <asac> so getting it fixed by then might allow to verify on sat or sun
[17:40] <asac> not sure if md goes up before prism
[17:40] <bdrung> that's no problem
[17:40] <micahg> it looks like it goes up first
[17:45] <asac> micahg: sure it goes up first? or finishes first?
[17:45] <micahg> ah
[17:45] <micahg> good question
[17:45]  * micahg checks the logs from the bot
[17:45] <asac> the latter is expected but would mean prism doesnt catch it ;)
[17:46] <asac> it should be > 1h difference on i386 etc.
[17:48] <micahg> uploaded first
[17:48] <asac> good
[17:48] <micahg> prism is uploaded last
[17:55] <asac> fta: what bug was that ld thing?
[17:55] <asac> 18:51 < fujimitsu> Inconsistency detected by ld.so: dl-minimal.c: 138: realloc: Assertion `ptr == alloc_last_block' failed!
[17:57] <asac> got it
[17:57] <asac> fta: unping
[18:02] <debfx> asac: what are your thoughts on the firefox kde integration? is there a chance it will go into lucid? anything I can do to help?
[18:03] <asac> we need upstream bugs with indidivual patches
[18:03] <asac> otherwise we wont get approval ... i am pretty sure
[18:03] <asac> so if you have an individual bug list we can review that and then decide on a case by case base
[18:04] <asac> to get some credits we need to shepherd the stuff into trunk
[18:04] <asac> at least actively working on that.
[18:05] <asac> just pulling in incomplete patches without helping out wont give us approval i am sure
[18:08] <bdrung> asac: pushed moz-version. please test it thoroughly (moz-version --compare VS dpkg --compare-version)
[18:11] <asac> no test cases? ;)
[18:12] <asac> didnt we do that before?
[18:12] <asac> i thought we just add the debtomoz and moztodeb mapping feature
[18:12] <asac> i really thought we had a complete test for the --compare at some point
[18:12] <asac> where did that go?
[18:14] <bdrung> asac: i have a local test for --compare. but i want a test for the new parameter.
[18:15] <bdrung> asac: take two moz version, compare them, then convert them into deb version and compare them again
[18:16] <bdrung> asac: 2. the other way around
[18:18] <asac> hmm.
[18:18] <asac> cant we make a direct test case for tomoz and todeb first
[18:18] <asac> that indirect test case looks reasonable to cover more
[18:18] <asac> but definitly isnt the thing to start ;)
[18:18] <bdrung> asac: here my local script http://paste2.org/p/600229
[18:18] <asac> how do you interpret *?
[18:18] <asac> can you commit that to mozilla-devscripts ?
[18:19] <asac> like in tests/ and tests/data
[18:19] <asac> or something
[18:19] <bdrung> asac: you can to moz-version -> deb version -> moz-version and compare both moz versions
[18:19] <asac> feels like the right thing to do
[18:19] <bdrung> * = int.max
[18:19] <asac> heh
[18:19] <asac> ok
[18:19] <asac> i would think we should error
[18:19] <asac> rather than that
[18:19] <asac> but ok
[18:19] <bdrung> error?
[18:20] <asac> most likely happens becaues of the underlying code
[18:20] <asac> yes. for compare there is a reasonable meaning
[18:20] <asac> for todeb there is none
[18:21] <asac> at least a warning to stderr ;)
[18:21] <asac> or spit out the result, but give error exit code
[18:22] <asac> but thanks so far ;) ... lets commit the current test anad we can check ;)
[18:22] <bdrung> k
[18:24] <bdrung> asac: how can i import the module from another dir? import ../src/moz_version does not work
[18:51] <bdrung> asac: am i allowed to apply this patch? http://paste2.org/p/600264
[19:24] <fta> asac, http://codereview.chromium.org/524075 \o/
[19:30] <micahg> asac: we seem to have a problem with the upstream fennec xul deb builds being pulled in by our FF app on moblin
[19:31]  * micahg guesses he should see what it installs where...
[19:35]  * micahg can't figure out what's causing it to conflict...
[19:35] <micahg> hmm
[19:36] <micahg> maybe it's a different build
[19:55] <thekorn> hi moziall team ;)
[19:55] <thekorn> what is the difference between xpt and xpi
[19:56] <thekorn> esp. when looking into creating packages
[19:57] <thekorn> my understanding is: xpi is an extension, and xpt is a component, but my understanding is also that extensions can contain components
[20:10] <bdrung> asac: ^
[21:54] <bdrung> asac: done
[21:54] <bdrung> asac: it's now ready for release. objections?
[21:55] <[reed]> thekorn: you are correct
[22:58] <bdrung> asac: icedove ignores the extension in /usr/lib/mozilla/extensions/{...}/. why?
[23:19] <mahfouz> http://ffextensionguru.wordpress.com/2009/12/28/hide-menu-bar-in-firefox-3-6/
[23:19] <mahfouz> will this be in ubuntu too?
[23:19] <mahfouz> i guess it's currently just in windows