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