[12:53] <armin76> ogra: lool: does ubuntu support the netwalker?
[13:40] <lool> armin76: The netwalker ships with a Canonical Ubuntu OEM version
[13:41] <lool> I have one here
[13:41] <lool> But it's not supported in vanilla Ubuntu
[13:41] <lool> It's mostly imx51 though
[13:52] <asac> fta: great. chromium works
[13:53] <asac> please use gcc-4.3 for now
[13:53] <asac> on armel
[13:53] <asac> so its gcc 4.4 bustage that caused this mess
[13:53] <asac> i already have an idea which compile flags those are
[13:53] <asac> let me commit the hack to workaround the issue for -m32
[13:53] <asac> armin76: ^^
[13:54] <fta> ok
[13:55] <fta> what about the other flags?
[13:55] <asac> have to test
[13:55] <asac> let me first get this working
[13:55] <asac> one second
[13:56] <asac> my guess is that its the -fdata-sections and -ffunction-sections flag combined with --gc-sections linkking
[13:56] <asac> i will drop those to test that
[13:56] <asac> they are supposed to remove symbols supposely not used from what i understand
[13:57] <asac> feels rarely tested ;)
[13:58] <asac> fta: btw, the GCC version hook you hvae in rules doesnt work with gyp=make
[13:58] <fta> really? hm
[13:58] <fta> how did you test then?
[14:00] <asac> i fixed rules too
[14:00] <asac> ;)
[14:01] <asac> http://pastebin.com/f5757e288
[14:03] <asac> ok all committed
[14:04] <armin76> asac: but does google work?
[14:04] <asac> yes
[14:04] <asac> everything works
[14:04] <asac> and is rockingly fast ... even over ssh ;)
[14:05] <zumbi> congrats ! :-)
[14:05] <asac> hehe
[14:05] <asac> let me see how it is on real X
[14:07] <fta> strange, CC and CXX are supposed to be used by gyp.. probably another bug there
[14:08] <asac> 5 seconds on first startup
[14:08] <asac> fta: yes. its a bug in the make generator most likely
[14:08] <asac> i saw that scons generator at least looks at those
[14:08] <fta> i will talk with the author of this generator
[14:08] <asac> while the make one doesnt even reference those
[14:12]  * asac a bit happy
[14:17] <fta> btw, i'm working on setting up a dev-channel, between the beta-channel and pure dailies
[14:18] <asac> i always thought that was the plan
[14:18] <asac> actually i thought that the dailies are more or less redundant
[14:19] <asac> at least for users (and most ubuntu devs) the -dev channel is more fruitful i guess
[14:19] <asac> fta: so if i remove stuff from ppa ... will that give more space?
[14:20] <fta> if users want to switch, i don't mind, but from the feedbacks i got with the beta, users prefer dailies
[14:20]  * asac considers to upload rather than wait for a new daily to not upload a new tarball
[14:20] <asac> yeah. but i think -dev is more what they want. but we will see
[14:20] <asac> just push the builds to 4am for chromium ;)
[14:20] <asac> hehe
[14:20] <asac> last time i said that
[14:21] <asac> i promiss
[14:28] <fta> i have new problems with those 3 ppas now, like should i align the codecs and gyp on each version, or let those 2 track trunk..
[14:31] <lool> asac: chromium on armel weee \o/
[14:31] <asac> yeah
[14:32] <asac> lool: do you remember why NEON is disabled for imx?
[14:32] <asac> someone said CPU hangs ... is that understood?
[14:35] <asac> fta: i dont know. isnt gyp more or less stable enough to do that on a as-needed base?
[14:36] <fta> asac, well, yes
[14:38] <asac> and codecs?
[15:05] <fta> the code itself is quite stable, but they keep adding patches (mostly to fix security stuff) and build flags may change
[15:06] <asac> darn. bad syntax error in my commit ;)
[15:06]  * asac reuploads
[15:17] <asac> ok retrying with gc 4.4 but with section gc dropped
[15:35] <asac> its kinda strange. the CC=... isnt honoured for v8 altogether
[15:35] <asac> still it helped here ;)
[15:35] <asac> sigh. we should definitly enable V=1 on builders
[15:36] <asac> there is no reason not to imo
[15:42] <armin76> ricing
[15:43] <armin76> lool: why nageia doesn't build stuff anymore?
[16:05] <lool> asac: TO1 and 2 have broken NEON implementations which will hang with some NEON code
[16:05] <lool> asac: But TO3 fixes it
[16:05] <lool> asac: It's a silicon bug, and apparently you can trigger it in some uncommon circunstances, but valid uses cases
[16:06] <lool> Ideally, we'd have a kernel patch to enable it only on TO3 and later at run time, but I don't think the kernel has any provision for this
[16:06] <lool> armin76: I have no idea
[16:06] <lool> armin76: Sometimes the buildd hang
[16:10]  * armin76 blames rabeeh 
[17:21] <asac> so since when is thumb (not 2) supported? i guess its good for karmic, but not jaunty?
[17:30] <lool> asac: ?
[17:30] <lool> asac: Thumb has always been working
[17:30] <lool> AFAIK
[17:30] <asac> cool
[17:30] <lool> Only Thumb 2 and NEON had issues in TO before 3
[17:30]  * asac enables thumb everywhere then
[18:16] <armin76>   g++ -pthread -fno-exceptions -fvisibility=hidden -Wall -D_FILE_OFFSET_BITS=64 -fno-ident -fdata-sections -ffunction-sections -fno-asynchronous-unwind-tables -fomit-frame-pointer -O3 -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -DENABLE_LOGGING_AND_PROFILING -DENABLE_DEBUGGER_SUPPORT -D__STDC_FORMAT_MACROS -DDISABLE_NACL -DV8_TARGET_ARCH_ARM -DCHROMIUM_BUILD -DNDEBUG -DNVALGRIND -Iv8/src -Iv8/src/arm -MMD -MF out/Release/ob
[18:16] <armin76> j.host/v8_base/v8/src/arm/cpu-arm.o.d.tmp -c -o out/Release/obj.host/v8_base/v8/src/arm/cpu-arm.o v8/src/arm/cpu-arm.cc
[18:16] <armin76> /var/tmp/portage/www-client/chromium-9999/temp/ccs57NS8.s: Assembler messages:
[18:16] <armin76> /var/tmp/portage/www-client/chromium-9999/temp/ccs57NS8.s:49: Error: selected processor does not support `bkpt 0'
[18:16] <armin76> make: *** [out/Release/obj.host/v8_base/v8/src/arm/cpu-arm.o] Error 1
[18:16]  * armin76 complains
[18:21] <armin76> ah, stupid thing
[18:22] <asac> hmm ... odd ... what did i do in my build to fix this LOGGING_AND_PROFILING thing
[18:22] <asac> err
[18:22] <asac> this virutal function call thing
[18:22] <asac> it happens again with fresh builds ;)
[18:23] <armin76> hah
[18:23] <asac> i remember i removed a bunch of -D stuff
[18:23] <asac> so its probably one of those
[18:24] <asac> B
[18:24] <asac> VALGRIND ... maybe
[18:24] <asac> or DEBUGGER support ;) or really profiling and debugging
[18:26]  * asac wonders what this mksnapshot thing does 
[18:28] <armin76> fta: why isn't the sse2 patch applied upstream?
[18:29] <asac> the patch isnt applied in our packages
[18:29] <asac> hmm
[18:29] <asac> seems it is ;)
[18:30] <armin76> asacfail
[18:31] <asac> +            # Disabled: see http://code.google.com/p/chromium/issues/detail?id=9007
[18:31] <asac> Result: layout tests require SSE2, normal builds probably shouldn't and Google Chrome
[18:31] <asac> packages don't. We don't control other packages.
[18:32] <asac> "I understand it's not ideal but as Chrome Linux is now shipped without those SSE2
[18:32] <asac> flags, i don't see why Chromium has to."
[18:32] <armin76> ricing!
[18:32] <asac> dunno what that means ;)
[18:34] <fta> armin76: because they don't want it in chrome, it makes the testsuite regress
[18:35] <armin76> i see
[18:35] <armin76> asac:  echo | gcc -dM  -E -  | grep ARCH <- what does this return to you?
[18:36] <asac> echo | gcc -dM  -E -  | grep ARCH
[18:36] <asac> #define __ARM_ARCH_6__ 1
[18:36] <asac> but i am on karmic
[18:36] <asac> echo | gcc -dM  -E -  | grep ARCH
[18:36] <asac> #define __ARM_ARCH_7A__ 1
[18:36] <asac> thats on lucid
[18:37] <asac> armin76: ^
[18:37] <armin76> i see, thanks
[18:47] <asac> http://people.canonical.com/~asac/screenshots/ffox35_vs_chromium_armel_sunspider.png
[18:48] <asac> odd that gyp generator make doesnt create clean targets ;)
[18:56] <asac> http://people.canonical.com/~asac/screenshots/chromium_karmic_armel_whatsmyuseragent.png
[18:56] <asac> armin76: ^
[18:57] <armin76> asac: quick!
[18:58] <asac> just wanted to encourage you not to give up ;)
[18:58] <asac> did you get further than the prop you posted above now?
[19:00] <armin76> nope not yet
[19:01] <armin76> that error happened because we tend to have the packages respect the cflags
[19:01] <armin76> and we don't use default -march on gcc
[19:01] <armin76> so it was building for armv4t as i forgot to add -march
[19:02] <asac> kk
[19:06] <asac> ok now it seems to work
[19:06] <asac> those ugly gcc44 flags cause all the trouble
[19:06] <asac>             'conditions': [
[19:06] <asac>               [ 'gcc_version==44', {
[19:06] <asac>                 'cflags': [
[19:06] <asac>                   # Avoid gcc 4.4 strict aliasing issues in dtoa.c
[19:06] <asac>                   '-fno-strict-aliasing',
[19:06] <asac>                   # Avoid crashes with gcc 4.4 in the v8 test suite.
[19:06] <asac>                   '-fno-tree-vrp',
[19:06] <asac>                 ],
[19:06] <asac> thats causing bustage for me
[19:07] <armin76> and why are you using that?
[19:08] <asac> me?
[19:08] <asac> thats not me... thats chromium
[19:08] <asac> they just run g++ --version ... and if its 4.4 they use those
[19:09] <asac> would be interesting to know which one it is
[19:09] <asac> mos tlikely the one preventing crashes ;)
[19:09] <armin76> ah
[19:09] <fta> we have tons of bugs that are 44 related
[19:10] <asac> i will narrow it down now ... pushed one more round to builders to see if it succeeds there
[19:10] <fta> like http://crbug.com/28749
[19:11] <asac> imo they play too much with optimization flags ;)
[19:11] <asac> that calls for troubles ;)
[19:11] <asac> but lets see
[19:11]  * asac goes back to 4.4 locally without the no-tree-vrp
[19:13] <fta> you will crash in v8
[19:16] <asac> well. i crash with both for sure ;)
[19:16] <asac> even on 4.3
[19:17] <asac> at least i dont run test suite ;)
[19:17] <asac> hehe
[19:23] <asac> darn. wanted to enable V=1 for that ppa upload :/
[19:55] <asac> hmm failed on the builder again :/
[19:56] <asac> wonder if i really included everything
[19:58] <armin76> asac: on the GYP_DEFINES you're still using gcc_version=44
[20:08] <asac> no
[20:12] <asac> that happens automatically
[20:12] <armin76> ah ok
[20:12] <asac> hmm
[20:13]  * asac scratches head
[20:16] <asac> fta: so is VERBOSE = 1 really that bad that we dont know what flags got passed if something fails on builders ;)?
[20:18] <fta> well, it's easier to spot errors without it. verbose makes very long lines filling the screen, that's why it's off by default
[20:18] <asac> heh?
[20:18] <asac> i think now with make build fails right away anyway
[20:18] <asac> and you usually want to see the lines
[20:19] <asac> if there are build failures
[20:20] <fta> failing right away is not related to scons vs make, both has --keep-going, i just forgot to re-enable it since i move to make :P
[20:20] <fta> +se +d, grr
[21:36] <mturquette> i see on https://wiki.ubuntu.com/ARM that "Kernels are planned for omap targets".  Who is working on that?  I'd like to see what progress is made and how I can help.
[21:40] <Martyn> mturquette : Actually, that is for the omap4
[21:40] <Martyn> once it's comes out ..
[21:40] <Martyn> *thinks*
[21:40]  * ojn looks to his right
[21:40] <Martyn> well, for lucid any armv7 ...
[21:40] <ojn> got one right here. :)
[21:41] <Martyn> ojn : So do I.. but that's not general availability yet :)
[21:41] <mturquette> I'm employed by TI, so getting an OMAP4 board is possible.
[21:41] <Martyn> ojn : That said though, even smooth-stone should have a processor out by the time general availability of the omap4 is there
[21:41] <Martyn> which is all kinds of yay :)
[21:41] <mturquette> and I want Ubuntu to rock on OMAP, so I'm trying to find out who to talk to ;-)
[21:42] <Martyn> Well, you're certainly in the right place.
[21:43] <ojn> mturquette: the basic work isn't that bad. Doing a kernel package is the easy part. DSP packaging, drivers, 3D accel X server, etc, is the more complicated parts. And none of the other supported platforms do that yet either.
[21:43] <mturquette> interesting to know.
[21:44] <mturquette> i'm basically interested in two things:
[21:44] <mturquette> 1) how hard/much time is it to get the base armv7a packages for lucid working on OMAP (I assume that maybe the RootfsFromScratch wiki page should make that quite easy)
[21:45] <mturquette> 2) how can I help get support for our accel packages (gles libs for 3D, gstreamer plugins for OMX, etc etc)
[21:45] <ojn> mturqutte: 1) is easy. That's what we're doing (Agnilux). It's trivial (rootstock + SD card  or NFS root is my preference). Base system works out of the box, comes up with X, etc.
[21:49] <ojn> mturquette: on the other packages, working on making deb packages to wrap them up in is a good start. That way you could even distribute them on your own on top of the distro, even if they don't get picked up by official ubuntu. There's a ton of resources out there on how to make debian/ubuntu packages, and this should be a decent place to ask questions about it as well.
[21:50] <mturquette> sure, i've done dpkg's before.  i'm interested in what process is necessary to get them adopted by Ubuntu.
[21:50] <armin76> mturquette: i want a board *g*
[21:52] <mturquette> haha.  you're barking up the wrong tree.
[21:52] <mturquette> *i* still have to beg for hardware and I work for the damned place!
[21:56] <ojn> mturquette: good question. I suppose that requires answers from some of the canonical folks on here, of all seem to be quiet. lool, asac? Not sure who handles what.
[22:02] <asac> mturquette: who are you working for?
[22:03] <armin76> asac: TI
[22:03] <asac> heh
[22:03] <asac> ok
[22:03] <armin76> not interested? :P
[22:04] <asac> why not ;)
[22:04] <asac> so he wants to recompile everything?
[22:04] <asac> or just produce a custom rootfs?
[22:04] <asac> mturquette: ?
[22:05] <asac> armin76: so its strict-aliasing
[22:05] <asac> unpatch that
[22:05] <asac> and it will build even on 4.4
[22:05] <armin76> asac: unpatch what?
[22:05] <asac> that chromium sets -fno-strict-aliasing for gcc4.4
[22:05] <asac> one sec
[22:06] <asac> http://pastebin.com/f2d00a846
[22:07] <asac> but could be that my build isnt at dtoa yet
[22:07] <asac> with all 4.3 it works as that doesnt set it
[22:09] <asac> mturquette: for your driver packages, what help do you want? just advice with how to package?
[22:10] <asac> third_party/WebKit/WebCore/bindings/v8/DerivedSourcesAllInOne.cpp  takes really really long to biuld here ;)
[22:10] <mturquette> asac: i'm actually not asking for help.  it seems i'm coming to the party a bit late and I just want to know, how *can* I help?
[22:11] <asac> heh
[22:11] <mturquette> i work for TI, on OMAP, all things Linux, and Ubuntu is important to me as another zealot-type.  so basically what has been done, what hasn't?  what is blocking you?
[22:12] <Martyn> Ahhhh!
[22:12] <Martyn> Now I know who you are :)  -laugh-
[22:12] <Martyn> San Mehat and I were talking about you not that long ago
[22:13] <Martyn> (nothing bad!  We were just discussing power management in OMAP vs other platforms)
[22:13]  * mturquette is concerned by this turn of events.  ;-)
[23:05] <asac> fta: no-strict-laiasing is used for gcc_version44=1 in v8 ... unconditionally in WebCore and if no_strict_aliasing=1 is set for the rest of the build
[23:06] <asac> feels odd
[23:06] <fta> it was initially just a temporary workaround for a crash in v8 snapshot
[23:06] <asac> for v8, yes.
[23:07] <asac> but what about WebCore ... thats right?
[23:07] <fta> but we later discovered other areas where strict aliasing creates bad code
[23:07] <fta> with gcc 4.4
[23:08] <fta> some were understood and fixed, others are just obscure, or gcc bugs
[23:08] <fta> hence the global no_strict_aliasing=1 i use for gcc 4.4
[23:12] <asac> fta: yeah. so what you definitly dont need anymore is gcc_version44=1
[23:12] <asac> thats auto detected
[23:12] <asac> the no_strict_aliasing is not redundant though
[23:12] <fta> yes, i know
[23:12] <asac> however, thats why i ask
[23:12] <asac> why arent the other uses of no-strict-aliasing being made dependent on gcc 44 rather than having two ways
[23:12] <asac> and one unconditional way even
[23:13] <fta> because some devs want to track those down
[23:13] <asac> not sure how that conflicts with making them gcc44 dependent
[23:14] <asac> if they are in fact gcc44 dependent
[23:14] <asac> if they are not, then that answers my question
[23:16] <asac> guess icu is at least needed for 4.3 at least