[00:11] <chrisccoulson> fta - this is a reproducer for the chromium/breakpad issue btw - http://paste.ubuntu.com/580859/
[02:51] <micahg> fta: chromium seems to work fine on natty
[03:04] <LLStarks> chrisccoulson, is the search popover supposed to cover the status popover?
[03:05] <LLStarks> *statusbar
[03:07] <LLStarks> nvm
[15:14] <fta> micahg, [03:51] <micahg> fta: chromium seems to work fine on natty <= uh? did you expect it not to? I need more context..
[15:14] <fta> asac, ping
[15:24] <asac> fta: hoh
[15:24] <fta> how are you?
[15:24] <fta> any update on the arm board(s)?
[15:26] <asac> sorry, that dropped off my busy schedule ... /me hits himself
[15:26] <asac> let me add that to next week tech lead agenda
[15:26] <asac> monday i will know more
[15:27] <asac> done
[15:27] <asac> will not be forgotten
[15:27] <asac> https://wiki.linaro.org/EngineeringUnits/Management/Meetings/2011-03-21
[15:36] <fta> bug 735877
[15:36] <ubot2> Launchpad bug 735877 in chromium-browser "Illegal instruction in chromium on startup on armel" [Undecided,New] https://launchpad.net/bugs/735877
[15:36] <fta> asac, ^^
[15:39] <asac> right
[15:39] <asac> i had folks staring on this today
[15:39] <asac> fta: is that a patch of mine?
[15:40] <asac> otherwise he is probably right ... vfpv3-d16
[15:40] <fta> nope, it's from upstream
[15:40] <fta> no idea what that vfpv3-d16 is, and how i should know about it. is it documented somewhere?
[15:40] <asac> hmm
[15:45] <davidgiluk> fta: Hi
[15:45] <asac> fta: meet davidgiluk
[15:45] <asac> he wants to help you discuss upstream if needed ;)
[15:45] <fta> hi
[15:45] <davidgiluk> http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?view=diff&r1=40698&r2=40699
[15:46] <asac> so i guess question is if we want to make the point upstream to use -d16 for maximum compatibility
[15:46] <asac> or if we just want to set this for ubuntu
[15:46] <asac> https://wiki.ubuntu.com/ARM/Thumb2
[15:46] <asac> this is still the default set of flags that we expect
[15:46] <asac> was decided to be maximum compatible while getting most benefit of most armv7
[15:47] <davidgiluk> fta: So my understanding is that there are 2 semi-separate chip features; Neon, and the number of vector registers;   some chips have no neon, and have only 16 vector registers - and that's what we default to
[15:47] <asac> so in ubuntu - unless there is runtime detection for things like neon - -mfpu=vfpv3-d16  is the default we have to use
[15:48] <fta> davidgiluk, that particular changeset is not the real change, it just moved the flag from a hardcoded value to a variable, which i can change in my package
[15:49] <davidgiluk> fta: Hmm true
[15:49] <fta> so it seems i need to pass arm_fpu=vfpv3-d16 too now
[15:49] <davidgiluk> fta: Yes
[15:49] <davidgiluk> fta: What concerns me is why has this changed - or has it always been brokwn?
[15:49] <davidgiluk> e
[15:49] <fta> i will discuss with upstream. they mostly want arm for chrome-os, not sure what h/w they target
[15:50] <davidgiluk> fta: The Tegra2 chip is the case it broke for Ramana which is non-neon and as I understand it d16
[15:50] <fta> it didn't change in a while, but i used to have a bogus test in my packaging, leading to armv7=0
[15:50] <fta> i fixed it in ch10
[15:50] <davidgiluk> fta: IMHO it would be best not to pass any flag at all and leave it to the compiler defaults
[15:51] <fta> no, the chromium build system overrides most system defaults
[15:51] <davidgiluk> ok
[15:51] <ramana> fta: well then in that case we (or they) have to be building for the lowest common denominator which is vfpv3-d16
[15:52] <ramana> I believe that's the reason why we ended defaulting to vfpv3-d16
[15:52] <asac> right
[15:52] <asac> thats why we do that in ubuntu
[15:52] <asac> similar to overriding the neon=1 default hat chromium has
[15:52] <davidgiluk> but has this ever worked on the ac100?
[15:52] <asac> its interesting ... seems noone cared even though we got bashed that our qt crashed on ac100 ;)
[15:53] <fta> most probably, it's just that i'm not well aware of those arm specificities. ubuntu  vs debian vs chrome-os, all have different targets in mind
[15:53] <asac> and we had to backout NEON
[15:53] <ramana> davidgiluk: well michaelh1 recommended I tried chromium-browser on my ac100 over firefox.
[15:53] <asac> fta: right ... just add vfpv3-d16 for now. then all is fine
[15:53] <ramana> so I gave that a shot and that's how it showed up
[15:53] <asac> we are working on runtime detecting neon for chromium/skia
[15:53] <ramana> so I think he's got it working .
[15:53] <asac> upstream is not responsive though :(
[15:54] <davidgiluk> ramana: OK
[15:54] <fta> ok, i'm fine with arm_fpu=vfpv3-d16
[15:54] <asac> fta: thanks!!
[15:54] <fta> will land that in the next stable update
[15:54] <ramana> with an older package ofcourse.
[15:54] <ramana> fta: Thanks.
[15:56] <davidgiluk> fta: Can you take bug 735877 then?
[15:56] <ubot2> Launchpad bug 735877 in chromium-browser "Illegal instruction in chromium on startup on armel" [Undecided,New] https://launchpad.net/bugs/735877
[15:56] <fta> so by default, i'll have: arm_thumb=1 arm_neon=0 arm_fpu=vfpv3-d16.  and armv7=1 only for maverick onward
[15:56] <fta> is that correct?
[15:57] <davidgiluk> yeh I think so - I don't know the pre-maverick world
[16:14] <fta> davidgiluk, ramana, asac: here is when the vfpv3 value 1st appeared: http://codereview.chromium.org/660067
[16:18] <davidgiluk> fta: Looking at ffmpeg it has a configure flag you can pass that would cause it to pass a -mfpu=vfpv3 but it doesn't look like the default
[16:19] <fta> (it's an old patch)
[18:17] <micahg> did i connect twice or once?
[18:19] <jdstrand> micahg:
[18:19] <jdstrand> 13:07 -!- micahg [~quassel@ubuntu/member/micahg] has joined #ubuntu-mozillateam
[18:19] <jdstrand> 13:14 -!- micahg [~quassel@ubuntu/member/micahg] has quit [Remote host closed  the connection]
[18:19] <jdstrand> 13:17 -!- micahg [~micahg@ubuntu/member/micahg] has joined #ubuntu-mozillateam
[19:51] <fta> micahg, would you be able to help with the chromium bugs? because i'm really bad with this due to lack of time. most should go upstream anyway
[19:55] <micahg> fta, sure, stuff related to regressions I can definitely help with idr if I have an upstream account
[19:56] <micahg> fta, where's the upstream tracker again?
[19:56] <fta> http://code.google.com/p/chromium/issues/list
[20:05] <micahg> fta, is #chromium a good place for me to idle/ask questions as well?
[20:07] <fta> micahg, sure, but it's purely a dev channel, so they hate end user questions, which should go to the support channels, cf /topic
[20:07] <micahg> fta, ok
[20:21] <chrisccoulson> heh, this looks a bit like the chrome release schedule: http://people.mozilla.com/~sayrer/2011/temp/process.html
[20:21] <chrisccoulson> "This proposal makes security updates occur along with Firefox releases, meaning we'll no longer be maintaining old branches."
[20:21] <chrisccoulson> oh, fudge
[20:22] <chrisccoulson> i guess we're screwed with all browsers now ;)
[20:22] <micahg> :(
[20:22]  * micahg needs to talk to upstream
[20:23] <chrisccoulson> fta - you have a separate nightly PPA for each channel of chromium don't you?
[20:23] <chrisccoulson> and you don't make them parallel installable?
[20:24] <fta> correct
[20:24] <fta> http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html
[20:24] <chrisccoulson> fta - i'm wondering whether that might be a better approach for firefox too, given the proposals for the release process
[20:24] <fta> i should not have used "daily" in the name
[20:24] <chrisccoulson> as there's going to what looks like 4 active channels
[20:30] <fta> chrisccoulson, looking at chromium, most users will end up using either the stable builds or the dailies, not much users in between
[20:41] <fta> jcastro, is the scroll wheel supposed to work in the dash now?
[20:41] <fta> i had it working a few days ago at work, but never at home
[20:41] <fta> similar setups
[20:41] <jcastro> I am not sure
[20:41] <jcastro> ah yeah
[20:41] <jcastro> it works for me
[20:44] <jcastro> fta: new compiz upload, see if this one helps
[20:44] <fta> jcastro, also is it possible to filter out the "Recents" in the dash? mine is filled with stuff i don't need in there, like mp3.. i have rhythmbox playing all day long
[20:44] <jcastro> fta: there's a blacklist thing you can do in zeitgeist
[20:45] <fta> where? how?
[20:45] <jcastro> however I've not looked into it, I think you want to search for blacklisting, zeitgeist, and gnome-activity-journal
[20:45] <jcastro> seiflofty on #ayatana can sort you out probably
[20:55] <fta> upgrading...
[20:55] <fta> jcastro, any update for the ch webapps since yesterday?
[20:55] <jcastro> fta: trevino's going to look at it on friday, he's on holiday right now
[20:58] <fta> k
[23:30] <fta> jdstrand, [ 9012.547609] type=1400 audit(1300318178.116:20): apparmor="DENIED" operation="file_mmap" parent=4945 profile="/usr/bin/evince-thumbnailer" name="/usr/lib/i386-linux-gnu/gconv/UTF-16.so" pid=4946 comm="evince-thumbnai" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0