[11:56] <armin76> asac: did it bumb? :D
[13:42] <asac> armin76: the build failed ... but but but ... i dont see any error ;)
[13:43] <asac> worst case i would say ;)
[13:43] <asac> let me try to get the log somewhere
[13:43]  * lool wins  \o
[13:45] <lool> asac: Was a date set to move armel to archive.u.c?
[13:47] <asac>  http://people.canonical.com/~asac/tmp/chromium-browser_4.0.260.0~svn20091128r33239-0ubuntu1~ucd1_armel.build.bak.bz2
[13:47] <asac> lool: ^^
[13:47] <asac> no error ;)
[13:47] <asac> but still build failed
[13:47] <asac> i ran the last command you can se there ... linked fine ;)
[13:47] <asac> not sure whats going on
[13:47] <asac> i guess OOM ;)
[13:50] <asac> lool: not sure that it was discussed. was that prediscussed/should i add that as a lucid goal?
[13:50] <lool> asac: scons: *** [/home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o] Error 1
[13:50] <lool> as -o /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s
[13:50] <lool> /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s: Assembler messages:
[13:50] <lool> /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s:2: Error: junk at end of line, first unrecognized character is `,'
[13:51] <lool> /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s:5: Error: unrecognized symbol type ""
[13:51] <lool> asac: Doesn't look like oom to me
[13:51] <asac> oh
[13:52] <asac> darn chromium build system
[13:52] <asac> --keep-going
[13:52] <asac> what a bad invention ;)
[13:52] <asac> i looked from the back ;)
[13:52] <lool> --keep-going is called from the rules
[13:52] <asac> yes
[13:52] <asac> thats the bad thing
[13:52] <lool> So you could trash it, it's not scons' default
[13:52] <asac> i dont know why fta has it
[13:52] <asac> sure
[13:52] <asac> already done
[13:52] <lool> Well if you know it's there, I find it helpful
[13:52] <asac> also did it before, just took latest snapshot and forgot to remove that
[13:53] <asac> why would you want to keep going? because scons is too slow to do quick incremental builds?
[13:53] <lool> The nice thing is that you know there is only this one error from everything which could be build in this pass; perhaps other errors will popup later, but it tested a good part of the build already
[13:54] <lool> You might want to "fire the build and forget" and then look back at all errors, especially on random arches
[13:54] <lool> (on buildds)
[13:54] <lool> It's a compromise because it also wastes a lot of machine time if things go wrong every time; if you do fix build failures, it saves machine time though
[13:54] <lool> Anyway, matter of taste
[13:55] <asac> right
[13:55] <asac> jocote:/tmp/icudt42l_dat.s
[13:55] <asac> lool: ^
[13:56]  * asac gets coffee ;)
[13:58] <lool> asac: I'd disable stack protection for now; it seems to be broken in the toolchain here; would be nice to keep the test case though
[13:58] <armin76> asac: who won? :)
[13:58] <lool> asac: Just pass -fno-stack-protector
[13:58] <lool> in CFLAGS
[13:59] <lool> armin76: You're a gentoo guy right?
[13:59] <giorgio__> Hi
[13:59] <armin76> lool: yep
[14:00] <lool> armin76: I find http://www.gentoo.org/proj/en/hardened/gnu-stack.xml really nice
[14:00] <giorgio__> to build my ubuntu-arm image for beagle board, should i have ubuntu on my development PC (i.e. to be compatible with rootstock) or i can use kubuntu without problems ?
[14:01] <lool> armin76: What do you work on in gentoo?  arm porting?
[14:01] <giorgio__> i would save time to install ubuntu
[14:01] <armin76> lool: we're nice ppl :P
[14:01] <lool> giorgio__: kubuntu should be just fine
[14:01] <giorgio__> i'm asking 'cause i cannot fetch rootstock from apt-cache search
[14:01] <armin76> lool: http://armin762.wordpress.com/about/
[14:01] <lool> giorgio__: kubuntu and ubuntu are built from the same underlying packages, just a different selection / default config, so worst case you have to install a couple more packages
[14:01] <lool> giorgio__: Which release are you on?
[14:02] <giorgio__> i installed an old one, and the let it upgrade itself, it should be kubuntu 9.04
[14:02] <giorgio__> maybe i have tu follow the instruction for Jaunty ubuntu ?
[14:03] <lool> armin76: good to know, thanks
[14:04] <lool> giorgio__: rootstock is shipped in ubuntu/kubuntu since karmic
[14:05] <lool> giorgio__: So either upgrade to karmic (you'll have to at some point anyway   ;-) or add the rootstock jaunty PPA to your config
[14:05] <lool> giorgio__: Also note that rootstock is in universe, so this needs to be enabled (isn't by default)
[14:07] <giorgio__> ok thanks, i'm following the instructions for jaunty, i think should not be different
[14:07] <giorgio__> hope difficult either :D
[14:07] <lool> asac: I can't figure why "," would be an invalid char; it seems fine from the example in http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
[14:10] <armin76> icu sucks
[14:10] <armin76> 4.2.1 fails for me on arm, i think it was assembler related thing as well
[14:10] <armin76> haven't had time to look at it
[14:10] <armin76> but on debian it built fine...
[14:18] <asac> lool: using @progbits helps
[14:18] <asac> err
[14:18] <asac> %progbits ;)
[14:18] <asac> like on the gnu-stack.xml
[14:19] <asac> http://paste.ubuntu.com/331089/
[14:19] <asac> does that make sense ;)?
[14:19] <asac> %object i did too ;)
[14:21] <lool> asac: Yeah I spotted the @ versus %, but other examples say @; not sure what it means
[14:21] <asac> lool: i changed %progbits and %object ;) ... whats the difference ;)
[14:24] <asac> wow ... really huge .s file ;)
[14:24] <asac> 6M gzipped ;)
[14:25] <asac> lool: so @ works on x86 ... but % works too
[14:26] <asac> readelf -S looks identical at least
[14:27] <asac> lool: where is a @ example?
[14:28] <asac> https://svn.pardus.org.tr/pardus/2009/stable/system/devel/gcc/files/note-gnu-stack.dpatch
[14:28] <asac> seems %progbits is used for arm stuff
[14:28] <asac> everywhere else its @objcet
[14:28] <asac> err @progbits
[14:28] <asac> too bad i dont have lucid chroot
[14:30] <asac> lool: i assume you have no lucid toolchain on your board and you could check whether thtas still needed?
[14:33] <armin76> asac: i won!
[14:33] <armin76> now you owe me an armv7 board
[14:34] <asac> armin76: we will see ;)
[14:34] <asac> armin76: i am still convinced your talent would be better invested in the ubuntu project ;)
[14:36] <asac> now the build is at linking stage
[14:36] <asac> i guess that will consume all damn mem and swap together ;)
[14:47] <asac> "Note on targets where the @ character is the start of a comment (eg ARM) then another character is used instead. For example the ARM port uses the % character."
[14:47] <asac> lool: ^
[14:47] <asac> http://sourceware.org/binutils/docs-2.20/as/Section.html#Section
[14:49] <asac> ok that explains it ... guess we need and #if defined...
[14:49] <asac> but which one ;)
[15:13] <lool> asac: I dont have a lucid host yet
[15:14] <lool> asac: What is that .s generated from?
[15:15] <asac> good question ;)
[15:15] <asac> let me check
[15:17] <lool> From ./build-tree/src/third_party/icu/source/data/in/icudt42l.dat
[15:18] <asac> i dont see where it gets generated
[15:18] <lool> It might be pregenerated in the tree
[15:19] <asac> right thats what i think
[15:19] <lool> It's really slow to unpack lzma though
[15:19] <lool> -rw-r--r-- fta/fta    25347229 2009-11-26 16:02 src/third_party/icu/linux/icudt42l_dat.s
[15:19] <asac> so we either need to hope that % really works everywhere
[15:19] <lool> It is pregenerated
[15:19] <armin76> chromium's build system sucks :P
[15:19] <asac> or we have to ship two different files ;)
[15:19] <asac> % works at least here on x86
[15:19] <asac> feels ugly though if gnu docs say @ ;)
[15:20] <lool> asac: It might mean something else on x86?
[15:21] <asac> lool: the readelf looked identical at least ;)
[15:21] <lool>          # These are hand-generated, but will do for now.  The linux
[15:21] <lool>          # version is an identical copy of the (mac) icudt42l_dat.s file,
[15:21] <lool>          # modulo removal of the .private_extern and .const directives and
[15:21] <lool>          # with no leading underscore on the icudt42_dat symbol.
[15:21] <lool>         'linux/icudt42l_dat.s',
[15:21] <asac> right.... but _how_ are they hand generated ;)
[15:22] <lool>     - {mac,linux}/icudt42l_dat.s : Built on Mac and Linux with all the
[15:22] <lool>       patches above applied and checked in.
[15:22] <lool>     - source/data/in/icudt42l.dat : Built on Linux with all the patches
[15:22] <lool>       above applied,
[15:22] <lool> 11. Pre-built data libraries are checked in.
[15:22] <asac> i see that section
[15:22] <lool> build-tree/src/third_party/icu/README.google
[15:23] <lool> Given that it's to put this in a symbol in a .o, I wonder whether they could generate a C file instead
[15:24] <asac> yes. but you have to wrap each line with asm("... right?
[15:25] <lool> I think it's just data; they could export a const array
[15:26] <lool> The declaration says it's not executable anyway
[15:26] <lool> So something like unsigned long data[] = {0x...};
[15:27] <asac> hmm
[15:27] <lool> + static
[15:27] <lool> It's in section .rodata, so clearly const
[15:27] <asac> yep
[15:27] <lool> .align 8 => can probably be achieved with __attribute__
[15:27] <lool> Not sure what .type icudt42_dat,%object means
[15:28] <asac> i asked on the #chromium channel now ... lets see if anyone answers
[15:28] <asac> http://sourceware.org/binutils/docs-2.20/as/Type.html#Type
[15:28] <lool> "Mark the symbol as being a data object. "
[15:29] <lool> Right just landed on that page as well
[15:29] <asac> hmm so STT_OBJECT?
[15:29] <lool> Does this exist in C?
[15:29] <lool> I'm not even sure this stuff is needed
[15:30] <asac> ok STT_OBJECT works
[15:31] <lool> in C?
[15:32] <asac> no in .s
[15:32] <asac>         .type icudt42_dat STT_OBJECT
[15:32] <asac> rather than ,@object
[15:33] <asac> doc says thats the gnu arch independent way
[15:33] <lool> Well yes, that's the same thing
[15:33] <asac> that reduces the problem to the progbits ;)
[15:33] <lool> I was proposing to move this whole .s stuff to .c to aovid the porting issue
[15:33] <asac> which doesnt really help :)
[15:33] <asac> right
[15:33] <asac> i understood
[15:33] <lool> Oh the object part was rejected as well?
[15:33] <asac> yes
[15:34] <asac> @ is a comment on arm asm
[15:34] <lool> Ok didn't see that far
[15:34] <lool> Right
[15:34] <asac> Note on targets where the @ character is the start of a comment (eg ARM) then another character is used instead. For example the ARM port uses the % character.
[15:34] <asac> http://sourceware.org/binutils/docs-2.20/as/Section.html#Section
[15:34] <asac> hell ... i want a portable for that too ;)
[15:34] <lool> Yup, read that too; just didn't spot use of @ in object
[15:34] <asac> or know how the .s is generated so we can create a .c
[15:34] <asac> ah ok
[15:35] <lool> Well to me it seems the .s is just the bytes from the .dat
[15:35] <asac> #chromium channel folks are laggers ... noone replying sundays as it seems ;)
[15:35] <lool> haha
[15:35] <asac> yes. but there must be  ascript or something ;)
[15:36] <asac> so we want to use static unsigned long icudt42_dat[] { .... } ?
[15:37] <asac> feels like we could even postprocess that from the .s file ;)
[15:46] <asac> echo "const unsigned long icudt42_dat[] = {" > out.c; grep ^\.long icudt42l_dat.s | sed -e 's/\.long//' | sed -e 's/$/,/' >> out.c; echo '};' >> out.c
[15:47] <asac> might complain about final , ;)
[15:49] <asac> lool: isnt the alignment automatically done by gcc?
[15:49] <lool> asac: Only on size long
[15:49] <asac> hmm
[15:49] <lool> It might be more, but how do you know?
[15:51] <asac> so __attribute__ ((aligned (8))); ?
[15:51] <lool> Yup
[15:52] <asac> echo "const unsigned long icudt42_dat[] = {" > out.c; grep ^\.long icudt42l_dat.s | sed -e 's/\.long//' | sed -e 's/$/,/' >> out.c; echo '} __attribute__ ((aligned (8)));' >> out.c
[15:52] <lool> I checked build-tree/src/third_party/icu/linux/icudt42l_dat.s, it starts with the same bytes as build-tree/src/third_party/icu/source/data/in/icudt42l.dat
[15:52] <asac> hmm
[15:52] <asac> ok so we could write the full binary generator
[15:52] <asac> isnt there such a tool already ;)
[15:52] <asac> must be somewhere
[15:52] <lool> asac: FYI, the conversion is completely unportable like this
[15:52] <lool> It uses long despite the fact that it's represented differently on little endian and big endian arches
[15:53] <lool> I think we just want some uint8_ts
[15:53] <asac> maybe the code consuming this does the endianess shuffeling?
[15:54] <asac> do we know?
[15:54] <lool> I have my doubts
[15:55] <asac> why is ICU such a mess ;)
[15:55] <giorgio__> do you know anything about touch screen issues with the beagleboard ?
[15:55] <lool> I did a grep -rl icudt42_dat build-tree/src/* but couldn't find where the symbol was used exactly
[15:55] <asac> heh
[15:55] <lool> asac: and the end of the file is also the same
[15:55] <asac> right
[15:55] <asac> thats expected (now)
[15:56] <asac> so the gcc on the out.c runs for 5 minutes already ;)
[15:56] <asac> ok to be fair chromium is linking in the background ;)
[15:57] <lool> 10515 asac      20   0  494m 140m   84 R  1.3 29.8   1:56.70 cc1
[15:58] <asac> yep ;)
[15:58] <asac> thats the out.c one
[15:58] <asac> as was much faster ;)
[15:58] <lool> I'm just scared with the memory use
[15:58] <asac> yeah. probably HUGE array gets parsed first
[15:58] <asac> let me abort that for now
[15:59] <asac> give some air to breath to ld
[15:59] <asac> ;)
[15:59] <lool> ld is also hungry
[15:59] <lool>  8683 asac      20   0 1245m 352m   76 D  3.2 74.7   5:59.52 ld
[15:59] <asac> right
[15:59] <asac> but thats expected
[16:00] <asac> chromium takes like 3G
[16:00] <lool> wow
[16:00] <asac> we only have 512m :(
[16:00] <asac> for linking
[16:00] <asac> it links everything static
[16:00] <asac> and does that for 1000 binaries or so ;)
[16:00] <asac> all tests etc.
[16:01] <asac> lool: did you succeed with your full/dynamic arm chroot thing?
[16:01] <lool> I stopped at UDS
[16:01] <asac> kk
[16:01] <lool> I need to finish this
[16:01] <lool> I clearly didn't manage to avoid binfmt though
[16:02] <lool> It might be possible with some awful hacks
[16:08] <fta> most chromium devs use gold instead of regular ld, but i don't know for arm
[16:08] <asac> do you know where this icu blob is actually used ;)?
[16:08] <asac> icudt42_dat
[16:09] <fta> Assembling /build/buildd/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o
[16:09] <fta> Creating library /build/buildd/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/lib/libicuuc.a
[16:09] <asac> yes
[16:09] <lool> asac: No, as I said above I grepped for it and couldn't find it
[16:09] <asac> right thats why i asked fta ;)
[16:09] <asac> (sorry for missing nick)
[16:09] <lool> I found it referenced in other .a files, but I didn't see where the symbol was used
[16:09] <lool> Oh sorry
[16:09] <asac> lool: referenced in other .a files?
[16:10] <asac> which one?
[16:10] <lool> Sorry off buffer
[16:10] <lool> grepping again
[16:10] <asac> :)
[16:12] <giorgio__> wich is the newest kernel version and where i can get the link to pass to rootstack ?
[16:13] <fta> http://code.google.com/p/chromium/issues/detail?id=22369
[16:13] <lool> giorgio__: We dont support beagleboard kernels sadly
[16:14] <lool> build-tree/src/sconsbuild/Release/lib/libicuuc.a
[16:14] <lool> build-tree/src/sconsbuild/Release/lib/libicudata.a
[16:14] <lool> asac: ^
[16:14] <lool> it continues
[16:15] <asac> nm on those?nm build-tree/src/sconsbuild/Release/lib/libicuuc.a | grep icu.*_dat U icudt42_dat
[16:15] <giorgio__> lool: i found it, simply navigate in the rcn-ee.net website
[16:15] <giorgio__> tnx anyway
[16:15] <asac> nm ./build-tree/src/sconsbuild/Release/lib/libicudata.a
[16:15] <asac> icudt42l_dat.o:
[16:15] <asac> 00000000 R icudt42_dat
[16:16] <lool> build-tree/src/sconsbuild/Release/obj/icu/icuuc/source/common/udata.o
[16:16] <lool> build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o
[16:17] <lool> Oh right it's mentionned in some tests as well
[16:18] <asac> build-tree/src/third_party/icu/source/common/umapfile.c:#       define U_ICUDATA_ENTRY_NAME "icudt" U_ICU_VERSION_SHORT U_LIB_SUFFIX_C_NAME_STRING "_dat"
[16:19] <asac> lool: ^
[16:19] <asac> so U_ICUDATA_ENTRY_NAME
[16:19] <armin76> lool: why don't you support beagleboard?
[16:20] <asac> loaded question i guess
[16:20] <asac> we provide rootstock ;)
[16:20] <fta> asac, lool: which version are you using, in r30145, there's a fix for icu on arm, but 1 month old now
[16:20] <armin76> asac: did you saw the link fta posted?
[16:20] <asac> fta: I use latest daily
[16:20] <asac> fta: link to that commit?
[16:20] <fta> hmm
[16:21] <armin76> asac: but thats not commited?
[16:21] <asac> maybe icu snapshot wasnt bumped to latest?
[16:21] <armin76> oh, it is
[16:21] <armin76> well, i don't understand google code :P
[16:21] <fta> here is the patch http://codereview.chromium.org/338031
[16:21] <asac> is icu a copy? not a on-demand checkout?
[16:21] <asac> ok
[16:21] <asac> heh
[16:21] <asac> yes
[16:22] <asac> thats the fix
[16:22] <asac> though .type icudt42_dat STT_OBJECT is "better" ;)
[16:22] <fta> i know, but it's strange you still see it though
[16:22] <asac> fta: why isnt that in daily?
[16:22] <asac> guess it wasnt committed?
[16:23] <fta> it was, as i said, it's in r30145
[16:23] <asac> when was it backed out ;)?
[16:23] <asac> when they merged icu?
[16:24] <asac> can you confirm that its not in anymore? or is our tarball bogus?
[16:26] <fta> checking
[16:26] <lool> asac: http://paste.ubuntu.com/331166/
[16:27] <asac> yeah
[16:27] <asac> 17:18 < asac> build-tree/src/third_party/icu/source/common/umapfile.c:#       define U_ICUDATA_ENTRY_NAME "icudt" U_ICU_VERSION_SHORT U_LIB_SUFFIX_C_NAME_STRING "_dat"
[16:27] <asac> 17:19 < asac> lool: ^
[16:27] <asac> so grepping for U_ICUDATA_ENTRY_NAME gives the usesin code
[16:27] <asac> not sure if we should check if that deals with endianes properly there
[16:31] <fta> chromium pulls /trunk/deps/third_party/icu42@32651 so it's in. are you sure you're patching the same file?
[16:31] <asac> so this was committed to icu tree?
[16:31] <asac> where i sthe tree?
[16:31] <asac> (svn)
[16:32] <fta> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/
[16:32] <asac> thx
[16:33] <lool> asac: Ah cool, that's what I would have grepped next, but I feared being overwhelmed with results
[16:35] <asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?revision=32640&view=markup
[16:35] <asac> fta: ^^
[16:35] <asac> its clearly not on trunk anymore
[16:36] <asac> i dont even see any commit backing that out ;)
[16:36] <asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?r1=26784&view=log
[16:36] <asac> how can i get longer log for that?
[16:36] <asac> oh maybe they added it to 38?
[16:36] <fta> viewvc is crap
[16:36] <asac> no ... its not there either :/
[16:36] <asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu38/linux/icudt38l_dat.s?view=log
[16:36] <asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu38/linux/icudt38l_dat.s?revision=24730
[16:38] <asac> its odd if i look at the diff to previous of the ARM portable commit
[16:39] <asac> it _adds_ the @ stuff
[16:39] <asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?r1=25651&r2=26784
[16:39] <asac> oh ;)
[16:39] <asac> its on the right
[16:39] <asac> didnt even see anything of that on my screen :)
[16:39] <asac> yeah. so this regressed in commit http://src.chromium.org/viewvc/chrome?view=rev&revision=29728
[16:40] <armin76> reverted :)
[16:42] <lool> asac: http://paste.ubuntu.com/331180/
[16:42] <lool> asac: Change "L>*" to "L*" to use native encoding; "<" is LE, ">" is BE
[16:43] <lool> (nothing is whatever the host runs == native)
[16:43] <lool> And tweak $chunk and sprintf as you please
[16:43] <armin76> lool: asac was compiling with -j8
[16:43]  * armin76 runs
[16:44] <asac> ?
[16:44] <armin76> asac: j/k
[16:44] <lool> asac: if you talk to upstream, would love if you made them generate a .s or .c at build time; it's one less large and weird sourcefile and more maintainable for us in such cases
[16:44] <asac> ack
[16:45] <asac> thats what we should be aiming for i guess
[16:47] <fta> asac, 32640 did it
[16:48] <fta> crbug.com/20406
[16:49] <lool> love that URL scheme
[16:50] <lool> fta, asac: So it's pretty clear the fact that the generation happens manually participated in this issue.... :-(
[16:50] <lool> anyway /me runs &
[16:50] <asac> enjoy
[16:53] <fta> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/README.google   look at 11.
[16:57] <fta> asac, i will reopen the bug
[16:57] <asac> yes... already read
[16:57] <fta> (i'm bugcontrol there)
[16:58] <asac> fta: can you suggest to generate those on the fly?
[17:00] <fta> it seems difficult based on all the changes mentioned in the readme
[17:00] <asac> from what i understand the changes are done to the .dat file
[17:00] <asac> so that one would be the base for mac/linux at least
[17:03] <asac> which bug will you open=
[17:03] <asac> there were two ;)
[17:04] <asac> how much faster would chromium finish if built without tests? ;)
[17:04] <asac> :-P
[17:04] <fta> I build it in 20 minutes here ;)
[17:06] <asac> g++ -o /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/ui_tests
[17:06] <fta> i reopened crbug.com/20406
[17:07] <asac> without comment?
[17:07] <asac> hmm that bug is a different one
[17:07] <asac> not the ARM regression bug
[17:07] <fta> oops, crbug.com/22369
[17:07] <fta> bad paste buffer
[17:07] <asac> http://code.google.com/p/chromium/issues/detail?id=22369
[17:25] <fta> asac, anything else broken on arm?
[17:25] <asac> cant tell ;)
[17:25] <asac> build is slow
[17:25] <asac> linking
[17:25] <asac> atm
[17:26] <asac> fta: we should add armv7=1 to GYP_DEFINES
[17:26] <asac> if we are on armv7 i guess
[17:26] <asac> at least i added it here ;)
[17:27] <fta> could you please paste a dpkg-architecture?
[17:27] <asac> http://paste.ubuntu.com/331205/
[17:27] <asac> doesnt show if we are on v7
[17:28] <fta> uname -m?
[17:28] <asac> $ uname -m
[17:28] <asac> armv7l
[17:28] <fta> better
[17:28] <fta> do you have other flavors you want to support?
[17:28] <asac> i am not sure we want to not use the uname -m ... rather something that figures if the toolchain defaults to v7
[17:29] <asac> fta: i think it would be nice if it also can be compiled on armv7 machines for hardy
[17:29] <asac> thats why we need to use toolchain or CFLAAGS or something to determine that
[17:40] <asac> fta: i think we want to use that for lucid and later
[17:40] <asac> for now
[18:50] <asac> fta: tests are running ;)
[18:50] <asac> ## list of FAILED tests:
[18:50] <asac> [  FAILED  ] ConditionVariableTest.FLAKY_MultiThreadConsumerTest (796 ms)
[18:51] <asac> [WARNING] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/testing/gtest/src/gtest-death-test.cc:741:: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test couldn't detect the number of threads.
[18:52] <asac> Timeout: aborting command ``./base_unittests'' with signal 9
[18:52] <asac> Killed
[18:52] <asac> quite a lot tests work though
[18:52] <asac> nice
[20:55] <asac> chromium-browser .deb seems to be done on jocote ;)
[20:56] <asac> fta: package is building -dbg .deb still ... is it normal that i see a test_shell_test process running still?
[20:56] <asac> baseunit_tests too afaict
[20:56] <asac> 17863 asac      20   0 77348    8    4 R 33.0  0.0  66:33.30 base_unittests
[20:56] <asac> 22152 asac      20   0 47516    8    4 R 33.0  0.0  22:27.81 test_shell_test
[20:57] <asac> 23507 asac      20   0  372m 368m   60 R 33.0 78.2  12:00.53 lzma
[21:02] <fta> nope, should have been killed by timeout
[21:02] <asac> kk
[21:04] <fta> i use a timeout of 600 sec, it's usually enough to let each test run. the idea is just to prevent the build from being blocked on network accesses.
[21:06] <fta> by default, the builder kills builds that didn't produce outputs for 4 hours, my stuff makes that 10 minutes minus the running time
[21:06] <fta> so it seems timeout is broken on arm
[21:07] <fta> could you check in the logs how base_unittests & test_shell_test ended up?
[21:07] <fta> asac, ^^
[21:07] <asac> fta: build is still running ;) ... but let me look
[21:09] <asac> fta: http://paste.ubuntu.com/331304/
[21:11] <fta> hm, fork()
[21:11] <fta> i should kill those too
[21:12] <fta> i guess the ppid is gone, right?
[21:12] <asac> ;)
[21:12] <asac> its defunct
[21:12] <fta> yep, that's expected
[21:12] <asac> asac@jocote:~$ ps -eaf | grep base
[21:12] <asac> asac     17600     1  0 18:47 ?        00:00:24 /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/base_unittests
[21:12] <asac> asac     17848 17600  0 18:48 ?        00:00:00 [base_unittests] <defunct>
[21:12] <asac> asac     17863 17600 49 18:48 ?        01:11:33 /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/base_unittests
[21:12] <asac> asac     25011 24437  0 21:12 pts/1    00:00:00 grep base
[21:12] <asac> so can i kill them without risking the packaging stop  ;)
[21:12] <asac> ?
[21:12] <fta> yes
[21:12] <asac> those dead tests consume 60% of CPU
[21:12] <fta> lol
[21:13] <asac> asac     22152     1 34 19:52 ?        00:27:57 /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/test_shell_tests
[21:13] <asac> that is still running too
[21:13] <asac> guess same boat?
[21:14] <fta> if the ppid is defunct, yes
[21:14] <asac> great ... funally lzma gets 70% of CPU ;)
[21:14] <asac> should speed this up by factor 3 ;)
[21:14] <asac> ppid was 1 ;)
[21:15] <asac> 23507 asac      20   0  372m 364m   56 R 96.4 77.2  18:14.76 lzma
[21:15] <asac> yay
[21:15] <asac> full speed
[21:15] <asac> -dbg
[21:15] <asac>  ;)
[21:16] <fta> could you pastebin your /proc/cpuinfo?
[21:17] <asac> http://paste.ubuntu.com/331310
[21:18] <fta> funny, it looks totally different from the usual format
[21:18] <asac> different arch ;)
[21:18] <asac> no MhZ ;)
[21:19] <fta> i mean, the linux kernel usually spits something similar, same keys, different values
[21:20] <asac> fta: sparc: http://paste.ubuntu.com/331313/
[21:21] <fta> oh
[21:21] <asac> fta: ppc http://paste.ubuntu.com/331314/
[21:22] <asac> so not really much in common ;)
[21:23] <asac> hmm ... do we really need lzma ;) ... someone said lzma was awefully unoptimized on arm
[21:23] <asac> i see what that means atm ;)
[21:25] <fta> i can disable it easily for arm, i have a knob
[21:25] <fta> you will just have 30% to 50% bigger debs
[21:25] <fta> but with thumb, you can produce smaller binaries, so maybe that's ~
[21:26] <asac> yeah.
[21:26] <asac> fta: did you commit the regressoin unpatching yet? ... also the lucid == armv7 would be great so i can copy the sources to some native ppa for lucid/karmic tomorrow?
[21:26] <fta> regressoin unpatching? you mean icu?
[21:27] <asac> yes.
[21:27] <asac> s/@/%/
[21:27] <fta> i didn't, i will kick upstream to have relanded asap
[21:27] <fta> +it
[21:28] <asac> kk
[21:28] <asac> i think the karmic debs should be good enough to get someone trying to run those bits
[21:28] <asac> to get a first idea about how broken it is ;)
[21:29] <asac> but you could add the lsb_release -c == lucid -> armv7=1 thing
[21:29] <asac> thats definitly wanted
[21:29]  * asac can do that too
[21:30] <fta> you mean, armv7 without even checking it's a v7 capable box?
[21:32] <fta> WANT_TESTS = 0 too? (that's sad)
[21:32] <asac> for 9.10 and above we dont support anything below v5
[21:32] <asac> err v7
[21:32] <asac> you could do a double check
[21:32] <asac> if armv7l or better and if lucid or newer -> do it
[21:32] <asac> so if someone ports lucid to armv6 or something it would still build
[21:33] <asac> i think we can keep tests on
[21:33] <asac> they didnt take that much time after all ;)
[21:33] <asac> just a few hours ;)
[21:33] <asac> maybe ensure that its easy to unset that by env
[21:33] <asac> ;)
[21:33] <asac> but not really important
[21:34] <asac> also a variable for KEEP_GOING=0 ;)
[21:34] <asac> maybe just remember to kill those processes looping if the tests fail ;)
[21:38] <asac> : chromium-browser-inspector: image-file-in-usr-lib usr/lib/chromium-browser/resources/inspector/Images/warningsErrors.png
[21:39] <asac> W: chromium-browser-inspector: image-file-in-usr-lib usr/lib/chromium-browser/resources/inspector/Images/whiteConnectorPoint.png
[21:39] <asac> E: chromium-browser-inspector: copyright-should-refer-to-common-license-file-for-lgpl
[21:39] <asac> E: chromium-browser-inspector: lzma-deb-archive
[21:39] <asac> E: chromium-browser-l10n: copyright-should-refer-to-common-license-file-for-lgpl
[21:39] <asac> E: chromium-browser-l10n: lzma-deb-archive
[21:39] <asac> we are close :)
[21:39] <fta> is it ok if i target the armv7 for ubuntu+1 instead of hardcoding lucid? i mean, lsb_release -ds matching either unstable or development to cover both debian & ubuntu
[21:40] <asac> i am not sure about the target arch of debian
[21:40] <asac> but if you also check for target CPU then probably yet
[21:40] <asac> yes
[21:40] <fta> it will match sid and lucid
[21:40] <asac> (not sure what to test so we can still cross-compile )
[21:40] <fta> of course, for arm(el) only
[21:40] <asac> fta: i know. but i odnt know what target sid has ;)
[21:41] <asac> i wouldnt necessarily say that they stop supporting armv5
[21:41] <asac> would have to check with whowever has a say on that in debian ;)
[21:41] <asac> lool: ?
[21:41] <asac> who is that?
[21:42] <asac> BUILD FINISHED ;)
[21:42] <asac> \o/
[21:42] <asac> cheers
[21:42]  * asac gets a drunk
[21:42] <asac> drink ;)
[21:42] <fta> lol
[21:43] <fta> does it run?
[21:43] <asac> i have no local machine
[21:43] <asac> lool: wanna grab the debs from jocote and try? ;)
[21:43] <asac> its karmic build
[21:44] <asac> JamieBennett: ogra: NCommand`: ^^
[21:44] <asac> GrueMaster: ^^
[21:44] <asac> ;)
[21:44] <asac> ls ~asac/*.deb
[21:46] <asac> xforwarding seems to be not enabled there
[21:46] <asac> hmm. maybe because it goes thorugh a ssh proxy? not sure
[21:46] <asac> lets hope for one of the above to test it ;)
[21:46] <asac> fta: arent there tests against xvfb ?
[21:47] <fta> yes, they are
[21:47] <asac> e.g. couldnt i check if some test worked to see if chances are high that it works?
[21:47] <asac> fta: which test would i look for?
[21:48] <fta> those are unittests, so not a guaranty that the whole thing runs :(
[21:48] <asac> well
[21:48] <fta> test_shell would be nice, but you still need a display
[21:48] <asac> [19742:19742:1129/193121:3402522844231:ERROR:/home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/base/shared_memory_posix.cc(192)] Creating shared memory in /dev/shm/com.google.chrome.shmem.unit_tests-19742 failed: Permission denied
[21:48] <asac> i see a bunch of those
[21:49] <asac> feels like that could be a buildd setup problem
[21:50] <asac> fta: http://people.canonical.com/~asac/tmp/chromium-browser_4.0.260.0~svn20091128r33239-0ubuntu1~ucd1_armel.build.gz
[21:50] <asac> thtas the full log (incremental though)
[21:51] <asac> ok seems /dev/shm has not right permissions in the chroot
[21:51] <asac> s -la /dev/shm/
[21:51] <asac> total 8
[21:51] <asac> drwxr-xr-x 2 root root 4096 Sep  9 18:48 .
[21:52] <asac> but outside of chroot its fine
[21:52] <asac> will check with lamont
[21:56] <fta> yeah, 550 lines of d/rules file
[21:56] <fta> crazy thing to build
[21:58] <armin76> asac: debian hasn't dropped i486 for i686, no point they are dropping armv5
[21:58] <asac> we havent dropped i486 either
[21:59] <asac> :-P
[21:59] <armin76> asac: are you still a debian dev?
[22:00] <asac> in my non-existing spare time ... yes ;)
[22:01] <armin76> asac: ok, another point: ubuntu doesn't support any publicly-available board, debian does
[22:01] <asac> i know
[22:01] <armin76> and they don't support any armv7
[22:01] <armin76> nor anything avobe v5, for that matter
[22:02] <armin76> err, above :P
[22:02] <asac> not sure what point you are trying to make ;) ... the question here was if we wanted to enable armv7 for debian sid ;) ... which i said was probably not right
[22:02] <asac> so you confirmed that i guess ;)
[22:03] <armin76> in fact debian supports armv4t, which the untouch gcc code didn't support, for example :)
[22:03] <asac> i think we support armv5 ... just not the kernel ;) ... so no image
[22:04] <asac> does debian offer images for all kind of arm SoCs?
[22:04] <armin76> hrm...i have no clue
[22:04] <armin76> i know the installer supports them, but not sure how you get the installer
[22:04] <asac> right
[22:05] <asac> thats what i mean. in general we support everything (well until lucid where we now make use of modern stuff)
[22:05] <armin76> asac: we as in ubuntu or?
[22:05] <asac> just have no images... because we dont have kernels for all the SoCs that are out there ;)
[22:05] <asac> yes
[22:05] <armin76> debian has the kernels, though
[22:06] <asac> armin76: which ones?
[22:06] <asac> http://www.debian.org/ports/arm/
[22:07] <armin76> yep
[22:07] <armin76> i find funny you ask me, you being a debian dev :P
[22:08] <armin76> marvell kirkwood is supported on squeeze iirc
[22:08] <asac> i am not really into arm that long ;)
[22:09] <armin76> also i believe they only support those devices that have kernel.org support
[22:11] <armin76> anyway, let's focus on topic
[22:11] <armin76> asac: you owe me an armv7 board :)
[22:11] <asac> noted
[22:11] <armin76> danke
[22:12] <suihkulokki> debian supports only mainline kernel boards due to resource constraints
[22:13] <suihkulokki> then again, any vendor claiming to support boards that are not mainlined is lying to their customers
[22:14] <suihkulokki> ..in a few upstream kernel releases, the customer will find out that _they_ are not getting any kernel upgrades..