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