| === asac_ is now known as asac | ||
| armin76 | asac: did it bumb? :D | 11:56 |
|---|---|---|
| asac | armin76: the build failed ... but but but ... i dont see any error ;) | 13:42 |
| asac | worst case i would say ;) | 13:43 |
| asac | let me try to get the log somewhere | 13:43 |
| * lool wins \o | 13:43 | |
| lool | asac: Was a date set to move armel to archive.u.c? | 13:45 |
| 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:47 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| asac | right | 13:55 |
| asac | jocote:/tmp/icudt42l_dat.s | 13:55 |
| asac | lool: ^ | 13:55 |
| * asac gets coffee ;) | 13:56 | |
| 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:58 |
| lool | armin76: You're a gentoo guy right? | 13:59 |
| giorgio__ | Hi | 13:59 |
| armin76 | lool: yep | 13:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| lool | armin76: good to know, thanks | 14:03 |
| lool | giorgio__: rootstock is shipped in ubuntu/kubuntu since karmic | 14:04 |
| 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:05 |
| 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:07 |
| 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:10 |
| asac | lool: using @progbits helps | 14:18 |
| asac | err | 14:18 |
| asac | %progbits ;) | 14:18 |
| asac | like on the gnu-stack.xml | 14:18 |
| asac | http://paste.ubuntu.com/331089/ | 14:19 |
| asac | does that make sense ;)? | 14:19 |
| asac | %object i did too ;) | 14:19 |
| 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:21 |
| asac | wow ... really huge .s file ;) | 14:24 |
| asac | 6M gzipped ;) | 14:24 |
| asac | lool: so @ works on x86 ... but % works too | 14:25 |
| asac | readelf -S looks identical at least | 14:26 |
| asac | lool: where is a @ example? | 14:27 |
| 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:28 |
| asac | lool: i assume you have no lucid toolchain on your board and you could check whether thtas still needed? | 14:30 |
| armin76 | asac: i won! | 14:33 |
| armin76 | now you owe me an armv7 board | 14:33 |
| asac | armin76: we will see ;) | 14:34 |
| asac | armin76: i am still convinced your talent would be better invested in the ubuntu project ;) | 14:34 |
| asac | now the build is at linking stage | 14:36 |
| asac | i guess that will consume all damn mem and swap together ;) | 14:36 |
| 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:47 |
| asac | ok that explains it ... guess we need and #if defined... | 14:49 |
| asac | but which one ;) | 14:49 |
| lool | asac: I dont have a lucid host yet | 15:13 |
| lool | asac: What is that .s generated from? | 15:14 |
| asac | good question ;) | 15:15 |
| asac | let me check | 15:15 |
| lool | From ./build-tree/src/third_party/icu/source/data/in/icudt42l.dat | 15:17 |
| asac | i dont see where it gets generated | 15:18 |
| lool | It might be pregenerated in the tree | 15:18 |
| 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:19 |
| lool | asac: It might mean something else on x86? | 15:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| asac | yes. but you have to wrap each line with asm("... right? | 15:24 |
| lool | I think it's just data; they could export a const array | 15:25 |
| lool | The declaration says it's not executable anyway | 15:26 |
| lool | So something like unsigned long data[] = {0x...}; | 15:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| asac | ok STT_OBJECT works | 15:30 |
| lool | in C? | 15:31 |
| asac | no in .s | 15:32 |
| asac | .type icudt42_dat STT_OBJECT | 15:32 |
| asac | rather than ,@object | 15:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| asac | so we want to use static unsigned long icudt42_dat[] { .... } ? | 15:36 |
| asac | feels like we could even postprocess that from the .s file ;) | 15:37 |
| 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:46 |
| asac | might complain about final , ;) | 15:47 |
| 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:49 |
| asac | so __attribute__ ((aligned (8))); ? | 15:51 |
| lool | Yup | 15:51 |
| 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:52 |
| lool | I think we just want some uint8_ts | 15:53 |
| asac | maybe the code consuming this does the endianess shuffeling? | 15:53 |
| asac | do we know? | 15:54 |
| lool | I have my doubts | 15:54 |
| 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:55 |
| 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:56 |
| lool | 10515 asac 20 0 494m 140m 84 R 1.3 29.8 1:56.70 cc1 | 15:57 |
| 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:58 |
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| lool | It might be possible with some awful hacks | 16:02 |
| 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:08 |
| 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:09 |
| asac | which one? | 16:10 |
| lool | Sorry off buffer | 16:10 |
| lool | grepping again | 16:10 |
| asac | :) | 16:10 |
| giorgio__ | wich is the newest kernel version and where i can get the link to pass to rootstack ? | 16:12 |
| fta | http://code.google.com/p/chromium/issues/detail?id=22369 | 16:13 |
| lool | giorgio__: We dont support beagleboard kernels sadly | 16:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| lool | Oh right it's mentionned in some tests as well | 16:17 |
| 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:18 |
| asac | lool: ^ | 16:19 |
| asac | so U_ICUDATA_ENTRY_NAME | 16:19 |
| armin76 | lool: why don't you support beagleboard? | 16:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| asac | can you confirm that its not in anymore? or is our tarball bogus? | 16:24 |
| fta | checking | 16:26 |
| lool | asac: http://paste.ubuntu.com/331166/ | 16:26 |
| 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:27 |
| 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:31 |
| fta | http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/ | 16:32 |
| asac | thx | 16:32 |
| lool | asac: Ah cool, that's what I would have grepped next, but I feared being overwhelmed with results | 16:33 |
| 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:35 |
| 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:36 |
| asac | its odd if i look at the diff to previous of the ARM portable commit | 16:38 |
| 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:39 |
| armin76 | reverted :) | 16:40 |
| lool | asac: http://paste.ubuntu.com/331180/ | 16:42 |
| lool | asac: Change "L>*" to "L*" to use native encoding; "<" is LE, ">" is BE | 16:42 |
| 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:43 | |
| 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:44 |
| asac | thats what we should be aiming for i guess | 16:45 |
| fta | asac, 32640 did it | 16:47 |
| fta | crbug.com/20406 | 16:48 |
| lool | love that URL scheme | 16:49 |
| 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:50 |
| fta | http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/README.google look at 11. | 16:53 |
| fta | asac, i will reopen the bug | 16:57 |
| asac | yes... already read | 16:57 |
| fta | (i'm bugcontrol there) | 16:57 |
| asac | fta: can you suggest to generate those on the fly? | 16:58 |
| 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:00 |
| asac | which bug will you open= | 17:03 |
| asac | there were two ;) | 17:03 |
| 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:04 |
| 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:06 |
| 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:07 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| asac | fta: i think we want to use that for lucid and later | 17:40 |
| asac | for now | 17:40 |
| asac | fta: tests are running ;) | 18:50 |
| asac | ## list of FAILED tests: | 18:50 |
| asac | [ FAILED ] ConditionVariableTest.FLAKY_MultiThreadConsumerTest (796 ms) | 18:50 |
| 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:51 |
| 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 | 18:52 |
| asac | chromium-browser .deb seems to be done on jocote ;) | 20:55 |
| 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:56 |
| asac | 23507 asac 20 0 372m 368m 60 R 33.0 78.2 12:00.53 lzma | 20:57 |
| fta | nope, should have been killed by timeout | 21:02 |
| asac | kk | 21:02 |
| 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:04 |
| 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:06 |
| 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:07 |
| asac | fta: http://paste.ubuntu.com/331304/ | 21:09 |
| fta | hm, fork() | 21:11 |
| fta | i should kill those too | 21:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| fta | could you pastebin your /proc/cpuinfo? | 21:16 |
| asac | http://paste.ubuntu.com/331310 | 21:17 |
| fta | funny, it looks totally different from the usual format | 21:18 |
| asac | different arch ;) | 21:18 |
| asac | no MhZ ;) | 21:18 |
| fta | i mean, the linux kernel usually spits something similar, same keys, different values | 21:19 |
| asac | fta: sparc: http://paste.ubuntu.com/331313/ | 21:20 |
| fta | oh | 21:21 |
| asac | fta: ppc http://paste.ubuntu.com/331314/ | 21:21 |
| asac | so not really much in common ;) | 21:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 | |
| fta | you mean, armv7 without even checking it's a v7 capable box? | 21:30 |
| 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:32 |
| 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:33 |
| asac | also a variable for KEEP_GOING=0 ;) | 21:34 |
| asac | maybe just remember to kill those processes looping if the tests fail ;) | 21:34 |
| asac | : chromium-browser-inspector: image-file-in-usr-lib usr/lib/chromium-browser/resources/inspector/Images/warningsErrors.png | 21:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| asac | JamieBennett: ogra: NCommand`: ^^ | 21:44 |
| asac | GrueMaster: ^^ | 21:44 |
| asac | ;) | 21:44 |
| asac | ls ~asac/*.deb | 21:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| asac | feels like that could be a buildd setup problem | 21:49 |
| 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:50 |
| 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:51 |
| asac | but outside of chroot its fine | 21:52 |
| asac | will check with lamont | 21:52 |
| fta | yeah, 550 lines of d/rules file | 21:56 |
| fta | crazy thing to build | 21:56 |
| armin76 | asac: debian hasn't dropped i486 for i686, no point they are dropping armv5 | 21:58 |
| asac | we havent dropped i486 either | 21:58 |
| asac | :-P | 21:59 |
| armin76 | asac: are you still a debian dev? | 21:59 |
| asac | in my non-existing spare time ... yes ;) | 22:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| asac | armin76: which ones? | 22:06 |
| asac | http://www.debian.org/ports/arm/ | 22:06 |
| armin76 | yep | 22:07 |
| armin76 | i find funny you ask me, you being a debian dev :P | 22:07 |
| armin76 | marvell kirkwood is supported on squeeze iirc | 22:08 |
| asac | i am not really into arm that long ;) | 22:08 |
| armin76 | also i believe they only support those devices that have kernel.org support | 22:09 |
| 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:11 |
| suihkulokki | debian supports only mainline kernel boards due to resource constraints | 22:12 |
| suihkulokki | then again, any vendor claiming to support boards that are not mainlined is lying to their customers | 22:13 |
| suihkulokki | ..in a few upstream kernel releases, the customer will find out that _they_ are not getting any kernel upgrades.. | 22:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!