[00:02] <LLStarks> hey asac
[00:03] <LLStarks> or is it asac_
[00:03] <LLStarks> ?
[00:10] <asac> fta: http://paste.ubuntu.com/236209/
[00:10] <asac> LLStarks: its me
[00:11] <asac> but i have to throw myself in the bed soon ;)
[00:11] <LLStarks> asac, is autocomplete acting up for you?
[00:11] <LLStarks> https://bugzilla.mozilla.org/show_bug.cgi?id=507269
[00:11] <LLStarks> also, when will firefox-3.6 be distro package on launchpad?
[00:12] <asac> LLStarks: can you give detailed instructions? e.g. how you trigger autocomplete etc.
[00:12] <fta> asac, l35=l97
[00:12] <LLStarks> i have no idea how i trigger it
[00:12] <asac> fta: oh yeah. the team section at bottom is removed ;)
[00:12] <asac> thx
[00:13] <asac> i thought it was better to start with simple stuff like team and toools ;)
[00:13] <asac> good thing its more or less an open end session ;)
[00:14] <asac> so if you wake up and feel like jumping in at 9 or 9:30 i might still be acting ;)
[00:14] <asac> ok with team at bottom removed: http://paste.ubuntu.com/236213/
[00:15] <fta> i'm at work at that time
[00:15] <asac> that makes sense ;)
[00:16]  * asac is curious who will show up that early ... australians? asians? early-birds?
[00:16] <fta> no one?
[00:16] <asac> i just can hope that whatever set it is,its at least with me ;)
[00:17] <asac> i would hope not :)
[00:20] <asac> LLStarks: usuually we push things in repo on late alphas or early betas
[00:20] <asac> for first time
[00:24] <fta> lzma is good for the size, but the build time jumped to almost 3h
[00:24] <asac> i dont think thats worth it now
[00:24] <asac> chromium is alredy heavy enough
[00:24] <asac> it for now ;)
[00:26] <fta> heavy? you mean slow to build or heavy debs?
[00:28] <asac> slow to build
[00:28] <asac> currenlty PPA cycles seem to be more precious than space ;)
[00:28] <asac> at least we seem to be ok with the current quota (also not much room of course)
[00:29] <asac> damn. i uploaded nss jaunty to intrepid in ppa :(
[00:29] <asac> now the ppa is lost
[00:30] <fta> lol, with 40GB of quota, that's enough..  even if every few days, i reach 38GB
[00:30] <asac> still it works for the current approach :)
[00:33] <asac> have you seen this notify-osd patch from above?
[00:34] <LLStarks> mark better demand delta debs for lucky liger.
[00:34] <asac> i cant parse that to be honest ;)
[00:34] <asac> but its late
[00:34] <LLStarks> or courgette
[00:35] <asac> i think the mozillateam is the wrong group to fix debs to use courgette ;)
[00:37] <fta> asac, http://paste.ubuntu.com/236226/
[00:38] <fta> asac, so your patch could be much simpler
[00:39] <asac> fta: you mean because it unrefs?
[00:40] <BUGabundo> hey guys
[00:41] <asac> fta: not sure what you mean. the patch definitly could make things much simpler, but i dont think the patch can be made much simpler. i do the check for the reference counting of surfaces because of the data thing that the client has to take care on its own
[00:41] <fta> asac, no, your if (ptr != NULL) destroy(ptr);
[00:41] <asac> ok
[00:41] <fta> just call destroy
[00:41] <asac> yeah that could be
[00:41] <asac> it was not specified in api doc
[00:41] <fta> that's why i fetched the sources
[00:42] <asac> yeah. but i am not sure one should rely on undocumented api behaviour
[00:42] <asac> thats why i usually dont look at sources ;)
[00:42] <asac> but i will think about it... maybe there is some general sectio nthat says that all destroys in cairo are NULL safe
[00:42] <fta> cairo does ref counting, so that should be pretty robust
[00:43] <fta> otherwise, we'll see a lot of crashes everwhere in gnome
[00:44] <asac> fta: you say alot of things in gnome call _destroy with NULL ?
[00:44] <asac> not sure why refcounting means that something is NULL safe ;)
[00:45] <asac> anyway. there ar emore memory issues left. at least i am down from 100 Megabyte in 20 minutes using special testcase to 1.4 m ;)
[00:45] <fta> that's the basis of refcounting, don't crash ;)
[00:45] <asac> well. not on NULL
[00:45] <asac> the idea of refconuting is that you can unref it ... but not that you can unref something that doesnt exist
[00:46] <asac> of course its there to prevent doublt free situations... but you rarely call something with NULL and ge ta double free
[00:46] <asac> rarely == never ;)
[00:46] <asac> either its graceful or it crashes
[00:47] <asac> good. nss bits are in the ppa ... so i can sleep  ;) cu 'morrow
[00:47] <fta> 'night
[00:49] <BUGabundo> night
[00:49] <BUGabundo> I'm going to
[00:50] <BUGabundo> still need to make chromium work on debian
[00:50] <BUGabundo> darn lib32-gtk
[00:50] <fta> rebuild it
[00:50] <fta> oh, lol, more ia32 issues
[00:51] <fta> BUGabundo, i will soon experiment with native x64
[00:51] <fta> it's getting closer
[00:51] <BUGabundo> YAY
[01:08] <fta> asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/3fbd367ac70f6232
[01:38] <micahg> asac: I would normally show up for that time period as it's 1AM for me :)
[01:38] <micahg> I won't be there tonight though...
[01:38] <micahg> I'll check the logs over the weekend though
[01:38] <micahg> I wish I could make it
[08:21] <asac> fta_: annoying form thing ... posted two messags. they dont show up
[08:21] <asac> fta_: if you could point them to my issue, that would be great: http://code.google.com/p/v8/issues/detail?id=411
[08:21] <asac> http://groups.google.com/group/chromium-dev/browse_thread/thread/3fbd367ac70f6232
[08:26] <asac> pinged evmar directly
[09:00] <asac> anyone with hardy/intrepid/jaunty here ;)?
[09:05] <e-jat> :)
[10:29] <asac> so i will probably not so another training session at 6 UTC)
[10:30] <e-jat> :( i miss the training ..
[11:40] <andv> asac, which training session?
[12:06] <gnomefreak> asac: did devicekit-power replace devicekit?
[12:09] <gnomefreak> !sound
[12:13] <asac> gnomefreak: dont know. but sounds reasonable
[12:13] <asac> at least devicekit is dead
[12:18] <gnomefreak> ah
[12:18] <gnomefreak> asac: thanks
[13:25] <gnomefreak> asac: my feelings aside im getting the hint that multisearch shyould be removed. 2 more bugs reported today on it.
[13:27] <gnomefreak> - Drop devicekit dependency.
[13:27] <gnomefreak>     - Add Conflicts to devicekit.
[13:27] <gnomefreak> that explains that
[13:27] <gnomefreak> ill be back in a few
[13:33] <asac> gnomefreak: we will remove multisearch for alpha4
[13:33] <asac> that was communicated, wasnt it?
[13:33] <asac> i will check if we can remove it in a week or so. i guess we have want we wanted by then
[13:34] <asac> gnomefreak: please use "multisearch" tag for those bugs. thanks!
[13:48] <gnomefreak> asac: they were duplicates of the 2 main bugs we have
[13:48] <gnomefreak> asac: i will check to make sure they are tagged
[13:49] <gnomefreak> asac: yep both are tagged already
[13:49] <gnomefreak> my Lp script isnt working :(
[13:52] <gnomefreak> bdmurray: as i recall you are the author of the LP greasemonkey script (from PPA) if so it seems i lost the reply choices
[13:53] <gnomefreak> firefox-lp-improvements is the name of it
[14:01] <gnomefreak> asac: it doesnt seem you commented about removing it on either bug. Can you please comment about it either on your blog or on the 2 bugs bug 403246 bug 402767. if on blog let me know i will comment ont he bugs linking them to your blog. blog im talking about is at: http://www.asoftsite.org/s9y/archives/162-What-is-this-Multisearch-thing-in-my-Firefox-about.html
[14:28] <mac_v> guys...In karmic, why is the right-click google search always searching in the Ubuntu start page?
[14:28] <mac_v> I removed ubufox but still it is stuck with the start page :(
[14:31] <mac_v> searching from the searchbox searches in the google.com/firefox , but the right click select always uses ubuntu start page [both in 3.0 &3.5]
[14:32] <mac_v> fta_: asac gnomefreak : is this a known issue or should i open a separate bug^ ?
[14:33] <gnomefreak> mac_v: yes for now disable ubufox should help it
[14:33] <mac_v> gnomefreak: nope , doesnt do it :( , i removed ubufox , but still only start page
[14:34] <gnomefreak> start page == your home page or ubuntu search page
[14:34] <mac_v> ubuntu start page
[14:34] <gnomefreak> mac_v: link?
[14:35] <asac> gnomefreak: ubufox has nothing to do with it
[14:35] <asac> multisearch ;)
[14:35] <asac> is it
[14:35] <mac_v> gnomefreak: what link? i'm confused
[14:35] <gnomefreak> asac: removing ubufox helps some of them. but yes i know multisearch is the problem
[14:35] <mac_v> http://www.google.com/cse?q=
[14:35] <asac> gnomefreak: please dont tell anyone to disable ubufox
[14:36] <mac_v> lol
[14:36] <asac> gnomefreak: for the search issue. thats a wrong thing and spreads around and everyone drops ubufox ;)
[14:36] <gnomefreak> asac: you started that not me
[14:36] <asac> i started it?
[14:36] <asac> i said: disable multsearch ;)
[14:36] <asac> not ubufox
[14:36] <mac_v> guys... gus...
[14:36] <mac_v> guys... how do i solve this? ;p
[14:36] <gnomefreak> asac: ah. thats it :(
[14:37] <asac> mac_v: what is right click google search ... i dont know that
[14:37] <gnomefreak> mac_v: try disabling multisearch :)
[14:37] <asac> ack ;)
[14:37] <gnomefreak> http://www.google.com/cse?q=fun&ie=utf-8&cx=partner-pub-2070091971271392:hsw1kx-3zxg&sa=Search
[14:37] <gnomefreak> you can also check the button that says web search
[14:37] <mac_v> asac: select text and right-click , you have the search option ... i was mentioning that
[14:38] <gnomefreak> at the top of that page but not sure if that is once or once for each search
[14:38] <mac_v> gnomefreak: i tried checking the websearch button , no go for me
[14:38] <gnomefreak> mac_v: disable multisearch extension
[14:38] <gnomefreak> asac: there are 4 or 5 arm patches?
[14:39] <asac> mac_v: yeah disable multisearch then
[14:39] <gnomefreak> there is 18_arm 38_arm bz339782_cvs and bzr 322806_
[14:39] <gnomefreak> i had 3 of them already
[14:40] <gnomefreak> so i feel im missing one
[14:40] <mac_v> hehe... so long i was wondering what was multi-search extension.... just now checked ... that bugger has sneaked in ;p
[14:40] <asac> mac_v: also file a bug about "right click search going to custome search" ... and tag it multisearch please
[14:40] <asac> thx
[14:40] <mac_v> yeah disabling it solves the problem
[14:41] <mac_v> asac: ok... but how did that extension get added?
[14:43] <gnomefreak> hmm that seems those are the only ones. at least the 2 bzr were added
[14:44] <asac> !multisearch
[14:44] <asac> !multisearch is http://www.asoftsite.org/s9y/archives/162-What-is-this-Multisearch-thing-in-my-Firefox-about.html
[14:44] <asac> 15:44 [freenode] [ubottu(n=supybot@ubuntu/bot/ubottu)] Your edit request has been forwarded to #ubuntu-ops.  Thank you for your attention to detail
[14:44] <asac> sigh ... too bad that they dumped me from the ops list
[14:44] <gnomefreak> i got it
[14:44] <gnomefreak> !multisearch is <reply> http://www.asoftsite.org/s9y/archives/162-What-is-this-Multisearch-thing-in-my-Firefox-about.html
[14:44] <gnomefreak> :)
[14:45] <asac> sure. but i am 100% sure it worked for me a while ago ;)
[14:45] <mac_v> lol
[14:45] <gnomefreak> asac: you have to be loggede in to bot to add
[14:45] <gnomefreak> @login
[14:45] <gnomefreak> asac: try that
[14:46] <asac> @login
[14:46] <asac> @me
[14:46] <asac> @whoami
[14:46] <asac> !whoami
[14:46] <asac> you dont rock ubottu
[14:47] <asac> gnomefreak: we already had that a few days ago. i am not in the list anymore i am sure
[14:47] <gnomefreak> asac: i am working on it
[14:47] <asac> dont bother to add me again ;) ... just curious when i got removed
[14:47] <gnomefreak> me too
[14:47] <gnomefreak> !snack
[14:47] <gnomefreak> !treat
[14:47] <gnomefreak> damnit
[14:47] <gnomefreak> !good
[14:47] <asac> !snack is <reply> not something to drink
[14:47] <gnomefreak> :(
[14:47] <asac> hehe
[14:48] <gnomefreak> no there is one already
[14:51] <gnomefreak> gedit is crashing damnit
[14:51] <gnomefreak> gedit patches/series
[14:51] <gnomefreak> Segmentation fault (core dumped)
[14:51] <mac_v> asac: done ... Bug #406893
[15:00] <asac> thx
[15:10] <bdrung_> asac: you wanted a correct version comparison. here you have it: http://paste.ubuntu.com/236641/
[15:10] <gnomefreak> ok arm patches are added :)
[15:10] <bdrung_> asac: the only problem is, that you need all packages installed (e.g. firefox-3.0, firefox-3.5, thunderbird, prism, ...)
[15:10] <asac> bdrung_: please a diff ;)
[15:11] <asac> bdrung_: yeah. but you need those installed then ... i am not sure if we really want it
[15:12] <bdrung_> asac: http://paste.ubuntu.com/236644/
[15:12] <bdrung_> asac: or would it be enough if you strip the upstream version out of the debian package version?
[15:13] <asac> bdrung_: we could say that apps should add a custom header to the binary packages control file
[15:14] <asac> like: Xb-Moz-App-Version: ${xulapp:version}
[15:14] <asac> however, i am currently not sure if we can have access to that on the builders
[15:15] <bdrung_> asac: how do access those information in the terminal?
[15:16] <asac> bdrung_: check apt-cache show mozilla-plugin-gnash | grep Npp-
[15:16] <asac> those are custom headers that are in control like: Xb-Npp-....
[15:24] <bdrung_> asac: i read your classroom session and stumbled upon the xulrunner dependency checks. e.g. "shell pkg-config --exists 'cairo >= 1.5.8'; a=$$?; if test $$a != 1; then echo 1; fi"
[15:25] <bdrung_> asac: you can simplify this or do you really want to check _exactly_ the result version != 1?
[15:27] <gnomefreak> now it no longer crashes
[15:28] <bdrung_> asac: "shell pkg-config --exists 'cairo >= 1.5.8' && echo 1" should do the same. the second command is only run, if the first exits with 0.
[15:39] <asac> bdrung_: yeah i know.
[15:39] <asac> bdrung_: i am not sure when we did it ;)
[15:39] <asac> i usually dont care for working code :)
[15:39] <asac> feel free to suggest improvements
[15:40] <asac> at best by suggesting merges ... lol...
[15:40] <asac> yeah this training session was a bit odd. noone really replied so i think they expected something completely different and ran away
[15:41] <bdrung_> asac: oh, i wanted to only create a patch file :) (so i don't have to write a changelog entry)
[15:41] <bdrung_> asac: or they had to go to university to write an exam.
[15:41] <asac> bdrung_: whatever you prefer. but i assure you that you will love bzr if you actually give it a chance ;)
[15:41] <asac> bdrung_: yeah. actually the time was more for eastern europe/asian/australian folks
[15:42] <bdrung_> asac: i like bzr, but not love it. :)
[15:42] <asac> but afaik free software isnt that popular
[15:42] <asac> bdrung_: that whould be good enough to use it :)
[15:42] <asac> should
[15:42] <asac> TomJaeger: hi
[15:42] <TomJaeger> hi
[15:42] <asac> TomJaeger: so seems xserver 1.7 is at risk
[15:43] <bdrung_> asac: my preference would be a combinition of git and bzr
[15:43] <TomJaeger> asac, yup
[15:43] <asac> bdrung_: for our purposed bzr is pretty perfect
[15:43] <bdrung_> but slow
[15:43] <asac> bdrung_: nowadays?
[15:44] <bdrung_> asac: yes
[15:44] <asac> bdrung_: for me it feels pretty snappy nowadays ;)
[15:44] <asac> at least similar to hg
[15:44] <bdrung_> asac: git feels faster.
[15:44] <asac> and the difference really isnt significant to git for everything but the biggest source tres
[15:44] <asac> bdrung_: i think your current perception is still biased from past experiences ;)
[15:45] <bdrung_> asac: gitweb is better.
[15:45] <asac> thats a fair point
[15:45] <asac> and i kick folks everytime i see it
[15:45] <asac> see them
[15:45] <bdrung_> but the big problem of git is, that is complex and some command are really weird
[15:45] <asac> but imo git web doesnt outweight the brain-pain that git comes with
[15:45] <asac> right. i dont think its worth for packaging. really
[15:46] <asac> its completely over engineered for that purpose
[15:46] <asac> its for a huge development project with centralize main tree ;)
[15:47] <bdrung_> :)
[15:47] <bdrung_> asac: and for ugly packages like eclipse
[15:48] <asac> packages that need git do something wrong i am sure ;)
[15:48] <bdrung_> asac: for the speed: bzr pull in mozilla-devscripts need 4 secs (with no changes)
[15:48] <asac> oh wait. eclipse package is dead
[15:48] <asac> bdrung_: because you go through ssh?
[15:49] <gnomefreak> kernel uses git IIRC
[15:49] <asac> try how quick the http: thing is
[15:49] <asac> bdrung_: if you use lp:~.... it tries ssh first i think
[15:49] <bdrung_> asac: bzr+ssh
[15:49] <asac> yes
[15:49] <bdrung_> asac: but with http i cannot push, right?
[15:50] <asac> bdrung_: you can have http for pull and ssh for push
[15:50] <gnomefreak> bdrung_: https you can
[15:50] <gnomefreak> its slower by a little bit
[15:50] <bdrung_> gnomefreak: that's what asac was referring to (its for a huge development project with centralize main tree)
[15:50] <asac> gnomefreak: no you cannot push
[15:51] <gnomefreak> asac: i thought i did
[15:51] <asac> bdrung_: for me pull taking 4 seconds is completely acceptable. you dont run pull like twenty times in a row ;)
[15:51] <asac> anyway ;)
[15:51] <bdrung_> asac: i have a script which updates all my repos
[15:51] <gnomefreak> apport isnt working in Kamric
[15:52] <asac> bdrung_: yeaah. then pull through https ... just tried takes about 1-2 seconds
[15:52] <gnomefreak> any idea on how to report a crash using apport?
[15:52] <asac> bdrung_: bzr pull --remember https://code.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts
[15:52] <gnomefreak> asac: example i used bzr push sftp://bazaar.launchpad.net/~gnomefreak/firefox/firefox.dev
[15:52] <asac> gnomefreak: you shouldnt use sftp
[15:53] <asac> thats rally old and slow
[15:53] <gnomefreak> asac: shouldnt but had to with firefox
[15:53] <asac> gnomefreak: use lp:~gnomefreak ...
[15:53] <gnomefreak> asac: i couldnt it would stall out every time push or pull using lp~*
[15:53] <bdrung_> asac: http needs 1.1 secs
[15:54] <bdrung_> and https 1.1 secs, too.
[15:55] <bdrung_> thats nearly 4 times faster.
[15:56] <asac> bdrung_: yeah. thats what i mean
[15:56] <asac> the other thing is bzr+ssh
[15:56] <asac> so its all ssh handshake ;)
[15:57] <asac> so do a bzr pull --remember with https://code.launchpad on all branches and bzr push --remember lp:~... then its fine
[15:57] <bdrung_> 3 secs for ssh. i currently tested my ssh connection to the university. they need 3 secs, too.
[15:58] <bdrung_> asac: so i blamed the wrong one. ;)
[15:59] <asac> ack ;)
[16:08] <bdrung_> asac: back to xpi.mk: if all apps would provide a custom header Upstream-Version, then this patch should work: http://paste.ubuntu.com/236723/
[16:09] <asac> bdrung_: yeah. unfortrunately i found out that we have no access to any apt db during build
[16:09] <asac> :(
[16:09] <bdrung_> asac: why not?
[16:10] <bdrung_> asac: isn't it possible to depend on apt?
[16:11] <asac> bdrung_: apt yes, problem is you dont have athe apt db locally ... nor do you have access to network on buildd's
[16:12] <bdrung_> asac: so we need the first approach, that we have the binary packages installed. any other suggestions?
[16:15] <asac> good question.
[16:17] <asac> i will think a bit about it
[16:17] <Willex> hi
[16:18] <asac> we could have two modes: a) accurate versioning (requires build depends) or b) no versioned depends
[16:18] <asac> hi Willex
[16:18] <Willex> is it possible some update has screwed up my firefox as it struggles to start?
[16:18] <bdrung_> asac: can you explain b) more?
[16:19] <bdrung_> hi Willex
[16:20] <Willex> it worked fine in the morning but this evening when I rebooted nothing appears until like 5 min lag...
[16:20] <Willex> I tried reinstalling but still no change
[16:21] <bdrung_> Willex: did you tried to start ff without plugins?
[16:21] <Willex> no
[16:21] <asac> bdrung_: basically extension package maintainers could decide. either they opt-into accurate versions ... which would require them to build depend on all applications he wants to have in Depends/Recommends
[16:22] <asac> or he says: just add packages for the given targetapplication ids ... wihtout considering versions
[16:22] <bdrung_> Willex: you can try to start ff with "firefox -safe-mode"
[16:22] <Willex> well I already disabled all the addons and it now starts fluidly
[16:23] <Willex> so is it some broken extension update that's screwing it up?
[16:23] <bdrung_> Willex: so you can enalbe them step by step and you will catch the problematic one
[16:23] <Willex> I don't remember updating them recently...
[16:24] <bdrung_> or it is a ff problem in combinition with an extension
[16:25] <Willex> well I've had the same ones for quite some time...
[16:26] <Willex> hmm, seems to be Kallout that's the trouble maker here
[16:26] <Willex> waiting... tralalalaaa
[16:28] <bdrung_> asac: updating the changelog and doing the change in the same commit or in different ones?
[16:30] <asac> bdrung_: what change?
[16:31] <asac> the accurate vs. proactive
[16:31] <asac> err sloppy
[16:32] <bdrung_> asac: e.g. the one regarding xulrunner (simplifying the shell command)
[16:32] <asac> bdrung_: rule is: if current changelog is UNRELEASED -> extend the changelog
[16:32] <asac> if its karmic or so it means that last commit was a release update
[16:33] <asac> then open new changelog entry with UNRELEASED
[16:33] <asac> makes sense?
[16:33] <bdrung_> asac: yes, that was clear
[16:33] <asac> bdrung_: oh. do it on xulrunner-1.9.2.head branch ... thats where we usually land improvements first
[16:33] <bdrung_> asac: my question was: a) doing changes, commit, update changelog, commit or b) doing changes, update changelog, commit
[16:33] <asac> as its trunk
[16:33] <asac> bdrung_: ah ok.
[16:34] <asac> bdrung_: doing change, update changelog and use debcommit
[16:34] <asac> so the changelog entry is used for bzr commit of the change
[16:34] <bdrung_> ok
[16:42] <bdrung_> asac: here you are: https://code.launchpad.net/~bdrung/xulrunner/simplify-shell-command/+merge/9469
[16:49] <bdrung_> asac: you can find UNRELEASED twice in the xulrunner changelog. something went wrong there...
[16:56] <asac> let me check
[16:56] <asac> bdrung_: yeah. thats the 1.9.1 changelog still ;)
[16:59] <bdrung_> asac: how to proceed with xpi.mk?
[17:04] <asac> bdrung_: a bit of a difficult question.
[17:04] <asac> bdrung_: not from xpi.mk side, but from what we require applications to do
[17:04] <asac> xpi.mk should get a switch like ..._XPI_AUTO_VERSION
[17:05] <asac> and if its there use whatever mechanism we define for targetapplication packages to expose their version
[17:05] <asac> also we could consider to define a version mapping for packages so we could guess the right lower/upper version bounds for depends
[17:06] <asac> for package versions
[17:06] <asac> let me think a bit ;)
[17:06] <bdrung_> it's now late enough to think clearly ;)
[17:07] <bdrung_> asac: my goal is it to simplify the plugin packages. so simplifying depends, but the having to b-d on the ff, tb, etc. would destroy the win
[17:21] <asac> bdrung_: yes. so if we could invent a mozversion -> deb package mapping, we could generate proper version bounds without having them installed
[17:22] <asac> so we might have impossible combinations like thunderbird (>= 3.0~a1)
[17:22] <asac> but we could maintain a list of special EOL and SOL versions for certain packages
[17:22] <asac> ;)
[17:22] <asac> like thunderbird_sol = 0.1a1pre
[17:22] <asac> thunderbird_eol = 2.0.0.*
[17:23] <bdrung_> what do you mean with eol and sol?
[17:23] <asac> thunderbird-3.0_sol = 3.0a1pre
[17:23] <asac> bdrung_: eol = end of life ;)
[17:23] <bdrung_> aha
[17:23] <asac> sol the opposite ;)  ... version of birth like ;)
[17:25] <bdrung_> not birth date, but fecundation date ;)
[17:26] <bdrung_> asac: you said that in the building we cannot run apt-cache. how should the mozversion -> deb package mapping work?
[17:31] <bdrung_> asac: now i understand it.
[17:41] <bdrung_> asac: here's the implementation of your idea: http://paste.ubuntu.com/236918/
[17:42] <bdrung_> afk
[17:46] <eagles0513875> morning asac
[18:03] <bdrung_> re
[18:04] <bdrung_> asac: we could set the *_sol to the current upstream version of the packages in unstable/karmic, couldn't we?
[18:58] <bdrung_> asac: wow, NEW contains nearly 300 packages.
[19:39] <bdrung_> asac: packages should b-d on xulrunner-dev instead of libxul-dev, right?
[19:51] <bdrung_> asac: do you know how to sru a new upstream version? https://bugs.launchpad.net/ubuntu/+source/adblock-plus/+bug/320762
[20:24] <asac> bdrung_: yes xulrunner-dev is the right one
[20:24] <asac> bdrung_: thtas a backport request. not an SRU?
[20:25] <asac> bdrung_: ok. it basically needs a bug that is severe enough to justify a backport
[20:25] <bdrung_> asac: the backport team said, that sru fits better than backporting
[20:25] <bdrung_> asac: maybe we should adjust the severity
[20:32] <asac> bdrung_: we should make a bug out of it ... like: "adblock-plus filters broken"
[20:32] <asac> what exactly is broken?
[20:33] <bdrung_> asac: some filter expressions do not work, because only the newer version supports the syntax. so less spam is filtered.
[20:33] <bdrung_> asac: so it is not totally broken, but partly.
[20:34] <asac> bdrung_: i remember that there are different filterlist providers
[20:35] <asac> are the new filter expressions used by new providers? or by the old ones?
[20:35] <bdrung_> asac: and depending on how aggressively they use the new syntax...
[20:35] <bdrung_> asac: by the old ones.
[20:35] <bdrung_> asac: they are used by (nearly) all providers listet on adblock website
[20:38] <asac> bdrung_: what i mean is: users that have the old adblock extension ... do they already pull data that they dont properly understand?
[20:39] <bdrung_> asac: yes. the lists are automatically updated (weakly)
[20:47] <pace_t_zulu> fta_: i reckon this command works for formatting the commit date like you suggested GIT_DATE = $(shell cd $(TMP_DIR)/src && git rev-list --max-count=1 --date=rfc --format=%ad HEAD | tail -1 | xargs -i date +%Y%m%dt%H%M -d'{}')
[20:48] <pace_t_zulu> fta_: if you have a better/more compact command... please share
[20:49] <asac> bdrung_: ok make a bug out of it. change severity and subscribe motu-sru
[20:50] <bdrung_> asac: other topic: should we set the *_sol to the current upstream version of the packages in unstable/karmic?
[20:50] <asac> bdrung_: but i think we cannot use the same packaging. so we need to branch off the current jaunty version and maintain a stable branch for jaunty and before
[20:51] <asac> bdrung_: no. i think _sol is basically first upstream version that matches the branch associated with the name
[20:51] <pace_t_zulu> fta_: so now the version looks like this... 0.0.3+git20090717t2107x65f7bc7
[20:51] <pace_t_zulu> i stuck the hash on the end for good measure
[20:51] <asac> bdrung_: example: thunderbird-3.0 -> 3.0a1pre
[20:51] <bdrung_> pace_t_zulu: very long version string
[20:52] <pace_t_zulu> bdrung_: indeed... that's just for the ppa... for unreleased commits
[20:52] <asac> bdrung_: firefox-3.5 -> 3.5a1pre ...
[20:52] <bdrung_> pace_t_zulu: then it's ok. it would be more readable if the date is seperated from the rest
[20:53] <pace_t_zulu> bdrung_: how do you suggest i do it dfferently
[20:54] <bdrung_> pace_t_zulu: for git checkouts i used only the date, e.g. 0.0.3+git20090717 and if you need more than one build per day, add the time 0.0.3+git20090717-1704
[20:54] <asac> bdrung_: alternatively we could say that it should be the first version that entered the archive
[20:55] <asac> have to think a bit about it ... but i currently lean to the first upstream version
[20:55] <bdrung_> asac: and why not the current version in the archive?
[20:55] <pace_t_zulu> bdrung_: you wouldn't include the hash?
[20:56] <bdrung_> pace_t_zulu: no, you could mention the hash in the changelog.
[20:57] <asac> bdrung_: because that would be overly strict imo
[20:57] <bdrung_> s/you could/i would/
[20:57] <bdrung_> asac: but it fits for the normal user.
[20:57] <asac> bdrung_: think about packages. you wouldnt bump lower version if there is no incompatibility
[20:58] <asac> bdrung_: why do you think its better to use current version as sol?
[20:59] <bdrung_> asac: example: we have thunderbird 2.0 in the repo, but the _sol is 0.1a1pre.
[20:59] <asac> yes
[20:59] <bdrung_> asac: we have an extension which works with tb till 1.0.
[20:59] <asac> because what we use _sol for is to figure if it makes sense to have thunderbird as a dependency
[21:00] <bdrung_> asac: so it would not work with tb and so tb should not be listed as possible dependency.
[21:00] <asac> bdrung_: no. it should be listed, but with proper bounds
[21:00] <asac> thunderbird >=0.5 <= 1.0.*
[21:01] <bdrung_> asac: ok, with bound it would be ok.
[21:02] <asac> so if we use current ones we would get overly strict depends
[21:02] <bdrung_> asac: then the xpi.mk need finetuning
[21:02] <asac> if we use upstream sol /eol we would end up with overly lax depends until we do the next and final step and get perfect bounds
[21:03] <asac> imo overly lax is better because it does not prevent you install for targets that work
[21:03] <asac> also its the right way for the final solution imo
[21:03] <andv> asac, are you available for an upload later?
[21:04] <asac> not today
[21:04] <andv> asac, I've decided to take back libagg coz someone wanted to NMU it
[21:04] <asac> tomorrow might work
[21:04] <andv> asac, my other packages are all ok so I can have one more package to work on
[21:04] <andv> asac, I gonna leave for the sea at like 2-3 pm
[21:04] <asac> bdrung_: the final solution would require a version scheme for packages .. e.g. policy
[21:05] <andv> asac, can you make it for the morning?
[21:05] <asac> no
[21:05] <asac> i cants say when
[21:05] <andv> damn : /
[21:05] <asac> i have a haystack of work ;)
[21:05] <bdrung_> asac: how would the version scheme look like?
[21:06] <asac> bdrung_: i think its pretty simple (not sure about *) ... 2.0a1pre -> 2.0~a.1~pre
[21:07] <asac> maybe + instead of .
[21:07] <bdrung_> ?
[21:07] <asac> 2.0~a+1~pre
[21:07] <asac> i am not sure if there can be a perfect mapping ;)
[21:07] <bdrung_> asac: i would prefer 2.0~a1~pre
[21:08] <asac> bdrung_: does it always work if we dont split letter to number transitions?
[21:09] <bdrung_> asac: yes. we only have to split number to letter
[21:09] <asac> bdrung_: maybe it really works
[21:09] <bdrung_> asac: because their interpretation is that an empty string is lower than everything else
[21:09] <asac> dpkg --compare-versions a1 eq a01 && echo asdsa
[21:10] <asac> a1 is equal to a01 ... so dpkg seems to split those transitions somehow
[21:11]  * asac  didnt know that a01 == a1 ;)
[21:11] <bdrung_> even a1 > a-2 works
[21:11] <asac> bdrung_: is it equal in mozilla land too ;)?
[21:11] <bdrung_> asac: yes, they allow negative numbers
[21:11] <asac> bdrung_: no i mean is a01 == a1 ;)
[21:11] <asac> let me test with our script ;)
[21:11] <bdrung_> asac: yes, it was one of the examples
[21:12] <asac> works ;)
[21:12] <asac> ok so lets try to standardize that with debian moilla and debian moz extension maintainers
[21:12] <asac> i will talk to extension guy ... and ask him to ask instead of me ;)
[21:13] <bdrung_> asac: mozilla mailing lists i should subscribe?
[21:14] <asac> bdrung_: no .. debian mozillateam
[21:14] <asac> mozilla has no stake in deb versions ;)
[21:14] <bdrung_> asac: link?
[21:14] <asac> let me get it
[21:15] <asac> http://lists.alioth.debian.org/mailman/listinfo/pkg-mozilla-maintainers + http://lists.alioth.debian.org/mailman/listinfo/pkg-mozext-maintainers
[21:15] <asac> bdrung_: ^
[21:15] <bdrung_> asac: and ubuntu lists?
[21:16] <asac> bdrung_: we only have our mailing list (/topic)
[21:16] <asac> hmm ... there is no url ;)
[21:16] <asac> https://lists.ubuntu.com/mailman/listinfo/ubuntu-mozillateam
[21:17] <asac> bdrung_: ^
[21:18] <bdrung_> asac: done. :) the ubuntu list was the fastest (although i subscribes as last)
[21:23] <andv> asac, k
[21:23] <andv> asac, gonna prepare everything for you for tomorrow
[21:23] <andv> asac, it's just a bug fix anyway on amd64
[21:25] <bdrung_> asac: pkg-mozilla-maintainers needs a spam filter
[21:26] <asac> yeah
[21:26] <asac> debian doesnt want spam filter ;)
[21:26] <bdrung_> why?
[21:28] <asac> bdrung_: i wasnt accurate. debian has tradition to not require a subscription
[21:28] <asac> and since alioth has no spam filtering (compared to debian-devel) its a mess
[21:28] <asac> but even debian-devel gets loads of spam through afaik
[21:28] <asac> but they have pretty good mailadmins that tweak spamfilter quite well
[21:30] <bdrung_> asac: where to report the spam filter request for alioth?
[21:33] <asac> let me check if i can enable spam filtefring for that list
[21:34] <asac> hmm ... i am not admin i think
[21:34] <asac> of the list
[21:34] <asac> just the project
[21:35] <asac> i dont know where to file something. sorry.
[21:39] <bdrung_> asac: what was the conclusion of the _sol version? using the version of the first package release?
[21:44] <BUGabundo> hey . gonna get my self a Android G2 tonight!
[21:47] <andv> asac, does it matter if I gonna provide you orig diff e dsc files instead of branches?
[21:56] <bdrung_> pace_t_zulu: for getting the latest git commit date, i used: "git log --pretty=format:%h -1"
[21:56] <pace_t_zulu> bdrung_: i will test that now
[21:57] <bdrung_> pace_t_zulu: your command looked much more complex
[21:57] <pace_t_zulu> bdrung_: indeed...
[21:58] <bdrung_> pace_t_zulu: ups
[21:58] <bdrung_> pace_t_zulu: that command was only for the hash. for the date i used the current one (date +%Y%m%d)
[21:59] <pace_t_zulu> ?
[21:59] <bdrung_> pace_t_zulu: and i used "${VERSION}+git$(date +%Y%m%d).${GIT_HASH}" as version string. so i did include the hash
[21:59] <fta> hi
[21:59] <asac> bdrung_: i think so. yes.
[21:59] <fta> (booo, localtime, baad)
[22:00] <fta> asac, so, how was your session?
[22:00] <pace_t_zulu> bdrung_: that date command will only get the current date... not the commit date
[22:00] <andv> asac, does it matter if I gonna provide you orig diff e dsc files instead of branches?
[22:00] <bdrung_> pace_t_zulu: yes, i know. i thought i improved that.
[22:01] <pace_t_zulu> bdrung_: the current date isn't as useful as the commit date
[22:01] <asac> andv: i think only you can answer that
[22:01] <andv> asac, lol
[22:01] <andv> asac, nvm then :S
[22:01] <andv> * :D
[22:01] <asac> a) i have no clue what package you are talking about ... b) i have no idea if there were any branches used before/in future
[22:02] <asac> etc.
[22:02] <andv> asac, libagg, there are no branches yet
[22:02] <andv> asac, there will be some branches in the future, but I gonna setup them after the package is uploaded (fixes a grave bug)
[22:03] <andv> asac, so on monday when I get back, I'll make some working branches
[22:03] <asac> k
[22:03] <andv> asac, gonna provide you a dgettable url
[22:03] <andv> asac, don't worry
[22:05] <bdrung_> andv: all ubuntu packages are now in bzr branches. so you could easily branch the karmic version.
[22:06] <andv> bdrung_, are you talking about my package?
[22:06] <andv> (libagg?)
[22:06] <bdrung_> andv: https://code.launchpad.net/ubuntu/+source/agg
[22:06] <bdrung_> andv: yes.
[22:07] <asac> yeah. should be easy to downstream maintain packages in debian from ubuntu
[22:07] <andv> bdrung_, have to upload a package as soon as possible, so I won't have time to do all revisions in bzr
[22:07] <andv> bdrung_, on monday I'll set them up
[22:08] <andv> bdrung_, for now I gonna work with orig diff dsc file
[22:08] <bdrung_> andv: it's only a hint for the future work.
[22:08] <andv> bdrung_, appreciated ty
[22:08] <andv> bdrung_, I'll have to merge the package anyway
[22:08] <andv> I see two ubuntu patches there
[22:08] <andv> for fixing something in jaunty
[22:09] <bdrung_> andv: you're welcome
[22:09] <andv> didnt know all packages are branched now
[22:10] <bdrung_> it's for a short time now
[22:10] <andv> bdrung_, how does it work?
[22:10] <andv> bdrung_, they get synced on bzr automatically?
[22:11] <bdrung_> andv: yes. every time a new package is uploaded a new commit is generated.
[22:11] <andv> cool
[22:12] <bdrung_> andv: i don't know how fast it is. it's probably a cron job which runs every hour or every day or something in between
[22:12] <andv> yeah
[22:12] <andv> looks like a good idea
[22:14] <fta> asac, http://dev.chromium.org/user-experience/omnibox may give you idea for the addon ;)
[22:14] <fta> +s
[22:23] <asac> fta: idea for which addon?
[22:24] <asac> multisearch?
[22:26] <fta> yep
[22:26] <fta> roh, i'm kidding
[22:28] <asac> does chromium not have a search field by default?
[22:31] <fta> no, it's omnibox
[22:33] <asac> k
[22:34] <asac> fta: we have to decide what to do with dailies
[22:34] <asac> err .head for xul + ffox
[22:34] <asac> i will transition stuff like yesterday ;)
[22:34] <asac> at firs tadding xulrunner-dev to 1.9.1
[22:35] <asac> then transitioning rdepends and then moving firefox to 3.5, enablling branding and asking profile migration question
[22:37] <asac> so i see two questions ew have to answer with yes to just continue:
[22:37] <asac> a) is it ok to migrate daily users to xulrunner-dev 1.9.1 by default
[22:37] <asac> b) is it ok to migrate daily users to firefox 3.5 by default
[22:37] <asac> i dont think its a big issue ... and i think thats aktually what most probably want, but still it hsould be an explicit decision that you also agree with ;)
[22:37] <asac> fta: ?
[22:38] <asac> rather than me injecting that in .head and then it happens everywhere
[22:40] <fta> i guess it's fine
[22:40] <asac> yeah only thing i am a bit unsure about is xulrunner-dev
[22:40] <asac> maybe they want to respin a hardy package and then it breaks
[22:40] <asac> but lets assume that those that need this can use pinning
[22:41] <asac> and the rest doesnt care most likely
[22:43] <fta> they should respin in chroot / pbuilder, not on their own box
[22:47] <andv> asac, a linux magazie in italy posted the link to chromium daily ppa
[22:48] <andv> asac, on this month
[22:48] <andv> * magazine
[22:49] <andv> bdrung_, do ppa builds for sid too?
[22:50] <asac> no
[22:50] <bdrung_> andv: no
[22:50] <andv> k ty
[22:50] <bdrung_> andv: and only x86 and amd64
[22:50] <asac> lpia
[22:50] <andv> I gonna change the changelog to karmic then
[22:50] <bdrung_> (due to virtualisation)
[22:51] <bdrung_> asac: lpia counts as x86 for me
[22:51] <asac> still they build separtely
[22:51] <asac> andv: remember to keep version in ppa lower than the actual upload
[22:51] <asac> ~andv1
[22:51] <andv> ok
[22:52] <fta> i wonder if it's possible to hack apport to send crash reports to upstream somehow
[22:53] <fta> google would like that
[22:54] <asac> fta: can google deal with our crash files?
[22:54] <asac> the blocker usually is that they need our symbols
[22:54] <fta> no, they use breakpad
[22:54] <asac> right so its the same thing as with mozilla
[22:54] <fta> yep
[22:54] <fta> breakpad is actually google, not mozilla ;)
[22:54] <asac> fta: the blocker is not really the sending of the crash report
[22:54] <asac> i knew
[22:55] <asac> its the "how to get the symbols uploaded and keep them versioned in their db so they can find the right ones etc."
[22:55] <asac> i would be happy if we solve this with google directly ;)
[22:56] <fta> i often resolve my crash files locally
[22:56] <asac> you do. but most dont have the huge -dbg packages availabl
[22:56] <asac> and it shouldnt be required
[22:58] <fta> that's something lp should do
[23:00] <asac> fta: what should launchpad do?
[23:00] <asac> fta: google has to be ready to accept uploads of symbols from distros
[23:00] <fta> lp has all the debs, fresh and not so fresh, it should be able to resolve all the crashes that are interesting to have and feed the results to a tracker specified in the package
[23:00] <asac> and later be able to assocaited those symbols
[23:00] <asac> fta: you say forward the bugs. ok
[23:01] <asac> thats a different thing
[23:01] <fta> no
[23:01] <asac> than uploading the crashes to breakpad
[23:01] <fta> just an apport service
[23:02] <asac> we discussed forwarding retraced crashes to their db
[23:02] <asac> but there were problems too
[23:02] <fta> i would like to add some apport hooks to my packages to teach apport what it should do with resolved crashes, instead of posting them in a lp bug, or reject it because "it's not a genuine ubuntu package"
[23:03] <asac> fta: unlikely that apport will get a feature to run code etc on the retracers machine
[23:03] <asac> fta: i understand. but where should it post the results to?
[23:03] <asac> fta: you said know if i asked if those should be auto fild upstream
[23:03] <fta> a remote bug tracker
[23:03] <asac> err you said no ;)
[23:04] <fta> not to lp, then forwarded, but directly upstream
[23:04] <asac> ah ok
[23:04] <asac> but still in launchpad ?
[23:04] <asac> nm
[23:05] <fta> apport will run on the ubuntu side, as all the debs are there
[23:06] <asac> so that would involve: a)
[23:07] <asac> make an apport webservice that is the primary upload service, rather than launchpad bugs
[23:07] <fta> yes
[23:07] <fta> something like that
[23:07] <asac> specify a contract that upload plugins can implement
[23:07] <asac> and use that after retracing to do the upload
[23:08] <asac> main problem is really that the retracers machine are deep in a datacenter ... not sure if someone would wnat to give them net access
[23:08] <asac> but one has to find out
[23:08] <asac> something we should suggest to pitti
[23:08] <fta> could be proxified, like pushed in a queue and processed by another machine
[23:09] <asac> yeah. the other thing is that we are talking about privacy related data
[23:09] <asac> so if users upload to ubuntu ... they dont expect google to get the private data
[23:10] <asac> not sure if that is relevant
[23:10] <asac> but users even complained that we violate privacy law in many states by putting multisearch in
[23:10] <asac> even though we just get the amount of clicks done where ;)
[23:11] <asac> and all the requests still go to google
[23:12] <fta> well, it's no different that going through breakpad
[23:12] <asac> fta: its different
[23:12] <asac> well of course it applies to the idea of us uploading to breakpad
[23:12] <asac> as well
[23:12] <fta> maybe i should just find a way to bypass apport and use breakpad then
[23:12] <asac> i meant its different if users directly upload to breakpad
[23:12] <asac> and we provide te symbols
[23:13] <asac> fta: as i told you thats the best way. but the problem is somewhere else
[23:13] <asac> its to get the symbols uploaded ... and afaik breakpad is not ready out of the box to do that
[23:13] <asac> if we can solve that i would jump up and down for 10 minutes ;)
[23:21] <fta> not enough ;)
[23:21] <asac> https://code.edge.launchpad.net/~mozillateam/
[23:22] <asac> fta: ok one time a week 10 minutes additional push ups for a month;)
[23:22] <asac> with each month it takes till this happens i remove 1 minute ;)
[23:22] <fta> bug? they all have the same graph
[23:22] <asac> !date
[23:23] <asac> fta: yeah
[23:23] <asac> thats what i wanted to say ;) and forgot to write it after the link
[23:23] <asac> not sure yet which one they take
[23:23] <asac> i had a different one before i reloaded
[23:32] <fta> anyone using chromium and having crashes on shutdown?
[23:33] <fta> http://code.google.com/p/chromium/issues/detail?id=18112
[23:35] <asac> fta: no
[23:35] <asac> works
[23:35] <asac> since when does ithappen?
[23:35] <fta> with --enable-plugins?
[23:35] <fta> i noticed a few days ago
[23:35] <asac> fta: i use the dailies
[23:35] <asac> i am upgrading to latest now
[23:35] <asac> but i think i upgraded yesterday
[23:36] <fta> try with  --enable-plugins
[23:36] <fta> on the cmd line or in /etc/chromium-browser/default
[23:37] <fta> upstream noticed some crashes when totem plugin is installed, but that's supposedly fixed now
[23:37] <asac> fta: do i need to use something that trigers plugins?
[23:37] <asac> or jus topen and cloe?
[23:37] <fta> no
[23:37] <asac> argh
[23:37] <asac> typing spastics
[23:37] <asac> --enable-plugins works too
[23:37] <asac> i am on 32bit
[23:38] <asac> hmmm ... even works with nspluginwrapper ;)?
[23:38] <asac> nice ;)
[23:39] <asac> hmm. seems they dont resolve links
[23:39] <asac> so i have multiple entries now
[23:44] <andv> asac, sent to build on ppa
[23:45] <andv> asac, if it builds fine on amd64, problem is fixed
[23:48] <fta> asac, it crashed if i have acid3 in a tab
[23:49] <fta> -d+s
[23:54] <asac_> no need to report every progress. just the big steps :)
[23:54] <andv> asac_, k