[00:03] plars: killing what? [00:03] dove? [00:04] asac: yep [00:04] plars: wow [00:04] plars: so without it, all works fine? [00:04] asac: yes, not what I was expecting [00:05] asac: sorta... gdm still continually restarts. Haven't had a chance to focus on that yet [00:05] plars: hmm ... so skipping gdm brings you a usable desktop and its stable? [00:06] asac: haven't tried bringing up X on it's own, just pulling pybootchartgui [00:06] how can you log in if gdm restarts? [00:06] asac: command line [00:06] ok; so no X [00:07] at least a small improve [00:07] asac: I suspect that X may start ok on its own, just didn't get a chance to try yet [00:07] asac: yes, we have a workaround to make progress at least :) [00:10] ok. when can you try that? [00:11] also, didnt someone say that gdm was fixed and now gnome-panel restarts? [00:15] asac: I can mess with it more tonight, trying to get kids fed right now [00:38] asac: I'm starting an alternate install now so I have an installation to work from (easier than modifying the live image). [00:38] great [00:50] asac, GrueMaster: I had several packages out of date, after the update gdm was stable, but it hung once I got into X again. Looks like there is more than one thing that can cause the hang. I did try running a few gui programs (gcalctool, oowriter, etc) and nothing hung when running over ssh [01:04] plars: do you have a Xorg log from that run? [01:05] plars: another thing to test would be to just start X with a single app [01:14] I'm wondering it it may be in the exception handler. It would be nice to know what is different in X0. === asac_ is now known as asac [06:03] asac, nope, didn't work (sorry, on lagged repsonse) [06:40] I have a question about building a package from source... I don't have the hardware yet but I know it'll run 9.10 arm [06:41] If the program is using only tcl c++ and c how weary do I have to be of the tarball? [06:42] Forgive my obvious stupidity on this one I still just rock simple java etc so architecture until very recently was totally not an issue [10:36] asac: ping [10:37] hmm, intresting, the qemu-kvm armel build seems to get a lot further in the recent upload but fails with assembler messages now [10:38] OS [10:38] (oops, wrong window) [10:39] ogra, maybe you can help me here: we have a kernel patch to trap and emulate the swp instruction. It's not upstream yet, but it would be worthwhile merging it into ubuntu. [10:40] What's the best way to raise it? [10:40] the kernel-team mailing list [10:40] OK, I'll try there. Thanks [10:40] https://lists.ubuntu.com/mailman/listinfo/kernel-team [10:40] Cheers [10:40] they usually get all patches for review on that list first [11:12] dmart: hi [11:12] ogra: It's the other way around, the qemu-kvm/armel build doesn't go as far as it used to [11:12] It used to go further than arm-softmmu/exec.o [11:12] dmart: yes, the kernel list. feel free to CC me on the mail [11:13] I fixed it a bit in karmic, but then the toolchain changes exposed more regressions [11:13] Such as usage of swp [11:13] (i am not subscribed) [11:13] But I think you folks are working on fixing issues such as /tmp/ccmwUgQ9.s:5392: Error: selected processor does not support `swp r4,r4,[r3]' [11:13] So would be cool to fix this immediate issue [11:20] asac, OK, will do [11:32] hmm, i thought it failed even before it started compiling stuff in the past [11:38] ogra: I fixed it a bit in the karmic cycle [11:38] ah [11:39] i just remember it failing on something like bochsbios or similar but then i didnt look at the logs for quite a while [11:41] dmart: http://blog.vlad1.com/2009/07/28/measuring-startup/ [11:42] http://blog.mozilla.com/tglek/2010/01/19/chromium-vs-minefield-cold-startup-performance-comparison/ [11:44] asac, what is minefield? Is that a firefox variant or something else? [11:45] dmart: minefield is daily build of firefox trunk [11:45] so atm heading to 3.7 [11:46] for ppa supported archs we also have it in http://launchpad.net/~ubuntu-mozilla-daily [11:46] you can use it side by side with 3.6 and 3.5 :) [11:46] but its just a placeholder for firefox here [11:47] Do we have 3.7 for armel anywhere? [11:47] There doesn't seem to be a build on the ubuntu-mozilla-daily PPA [11:53] right. thats why i said: "for ppa supported archs" dmart [11:53] i dont think we want to check that build [11:53] for now [11:53] asac, sorry, misread that [11:53] OK [11:53] np. should have been more explicit [11:53] asac, i think someone needs to look at the busybox ftbfs soon, that might get in our way [11:53] dyfet, ^^^ something for you ? [11:53] asac, I will try the startup time test on chromium and ff3.6 anyway; would be interesting to see what happend. [11:53] * ogra grumbles about bad reconnect time [11:53] ogra: ok [11:54] okay [11:54] I can after some coffee :) [11:54] dyfet: hi [11:54] thanks [11:54] dyfet, awesome :) [11:54] dmart: right. that would be great [11:55] dmart: i am waiting for more input ;) [11:55] from moz folks [11:55] looking at all tehse segfaults in the ftbfs list i wonder if our buildds have issues [11:55] doko said that one build machine is broken most likely [11:55] giving back usuall yhelps [11:55] yeah, smells like [11:55] he said he disabled the builder [11:55] and someone enabled it again ... guess lamont [11:56] i'll try to give back pulse ... wont harm anything, lets see if it gets through [11:56] yes do that [11:56] if it helps, lets check why the builder that doko disabled got pushed in the farm again [11:56] seems that was imbe [11:57] and yes, imbe is in the pool again [11:58] pulse is now building on jambul [11:59] evolutions segfault wasnt on imbe though [11:59] but on huito [11:59] i wonder if that points more to a toolchain issue than to a specific buildd [12:00] or an issue with the way the chroots are set up [12:01] hmm the same for empathy [12:01] seems to be pretty random across the builders [12:02] (that segfault was on korlan this time) [12:02] ok [12:02] was there a toolchain upload? [12:02] not that i noticed, let me check [12:03] seems like ... 4 days ago [12:03] * Update the gnat patch for arm from the trunk. [12:03] yeah [12:03] well, lets see how the given back packages behave now [12:03] i gave back evo as well [12:03] empathy failed too [12:04] yep gave that back too now [12:04] evo-couchdb needs to wait for evo to build first [12:04] ok see that now [12:05] launchpad-integration and indicator application look like good candidates for a give back as well [12:05] both waiting for python-gtk2 [12:06] * ogra gives back both [12:46] ogra: hmm. ok. [12:46] but you said they were on multiple biulders [12:46] but ok [12:46] right [12:46] thats why i say we should still watch it [12:47] but if it doesnt show up again its rather cosmic rays or bad weather behvaior ;) [13:18] dmart: http://dromaeo.com/ ... also got that one === dmart_ is now known as dmart === dmart_ is now known as dmart === bjf-afk is now known as bjf [15:22] asac, FYI all give backs survived [15:23] is there a best place to get a list of packages built for 9.10? [15:24] jkridner, we build all packages in the archive [15:24] ogra: nice [15:24] thats good news [15:24] so maybe something got fixed magically again [15:24] jkridner, http://qa.ubuntuwire.org/ftbfs/ has a list of failed builds though [15:24] asac, right, that happens from time to time which is why i blame cosmic rays :) [15:24] was neon disabled already again, or are we still running that? [15:25] no idea [15:25] asac, i didnt know we enabled it [15:25] bug 490326 [15:25] Launchpad bug 490326 in fontconfig "Please merge fontconfig 2.8.0-2 from Debian testing (main)" [Wishlist,In progress] https://launchpad.net/bugs/490326 [15:25] ogra: it was enabled (more or less by accident) in latest BSP upload [15:25] so good. i will bring up a chromium NEON build then to compare [15:26] asac, in the upload ? i thought only in the test kernels [15:26] after i asked for a test kernel, dmart found that we have it enabled in archive now ;) [15:26] but i might have misunderstood [15:26] ah, right, then i misremember [15:26] it wasnt a conscious change ;) [15:27] my had is spinning from that uboot crap [15:27] heh. i know what you mean [15:27] testbuild is running though, then i'll upload ... i'll add the fix for the board revision numbers as soon as i have all of them [15:27] Is anyone using Babbage-2 boards right now? [15:27] i want to get that package crap done now :) [15:28] dmart, asac is [15:28] my board is powered off.... still have getting the rev on my list [15:28] let me see [15:28] asac, how if your bbg 2 connected to the network? I'm still getting terrible network performance in lucid, but it only occurs when connected via a hub. [15:29] dmart, using uboot or redboot ? [15:29] dmart, we discovered some heavy issues with the NIC initalization under uboot [15:29] ogra, it's redboot (actually, I'm currently running the 20100120 image) [15:29] ah, k [15:30] redboot should be fine [15:30] The network works, and the hub claims it's at 100MB, but the IT guys here were wondering whether it's running half-duplpex for some reason. [15:30] sounds like a valid explanation [15:30] did you check with mii-tool ? [15:31] dmart, do you run a 2.0 or a 2.5 atm ? [15:32] i'm looking for: "cat /proc/cpuiunfo|grep ^Revision" from a 2.0 under redboot [15:32] thanks ogra. looks like Skype is a special case. [15:32] ogra, it's a 20. [15:32] jkridner, yeah [15:32] dmart, could you get me that number ? [15:33] ogra, what number? [15:33] that saves asac to create a boot SD with redboot :) [15:33] Oh, right [15:33] dmart, cat /proc/cpuiunfo|grep ^Revision [15:33] 51020 [15:33] 510 ? [15:33] and thats under redboot ? [15:33] I dunno, that's what it says [15:33] Yes. [15:33] ok [15:34] 2.5 and 3.0 have 511 at the front [15:34] I think so anyway... you're not using uboot in the images yet, right? [15:34] means my patch will be only two lines instead of three, thanks a lot ! [15:34] Where does mii-tool come from? [15:34] no, uboot is to broken [15:35] dmart, net-tools iirc [15:35] asac, so you dont need to fiddle with your board anymore, got my info for the patch [15:35] ogra, SIOCGMIIPHY on 'eth0' failes: Operation not supported [15:36] ouch [15:36] messy driver i guess ... did you sudo the command ? meight need admin privs [15:36] Yeah, this was running as root [15:36] then its a driver issue [15:37] it might not properly integrate with the mii layer [15:37] that would also excplain why we dont see cable plug events [15:38] Unfortunately I don't know how to confirm whether the connection is half-duplex, and it don't think anyone else has been able to reproduce it yet. [15:40] no, only MII tool could confirm that or the dmesg entry for a plug event in your logs :) [15:52] asac, do you know how to run Vlad's startup time test on Chromium? It seems to rely on being able to dump to the console from JavaScript, but I'm not sure whether Chromium supports that. [15:58] hmm [15:58] dmart: good question [16:00] dmart: http://blog.mozilla.com/tglek/2010/01/19/chromium-vs-minefield-cold-startup-performance-comparison/ [16:00] does that not work? [16:00] or did i forget to post that url? [16:02] You posted it, but I just seem to see a blank page with no result visible. I'll try again later... [16:04] hmm [16:04] Maybe I did something stupid... [16:06] i think the idea is that it also displays it in the browser [16:07] Oh... hmmm. I'll try more carefully and let you know (I'm waiting for something else to run right now) [16:07] ...or not... (board lockup) [16:08] sure [16:08] Is anyone else seeing this intermittent lockup problem? It may be specific to babbage 2 [16:09] Generally the board will lock up every 1-2 days [16:10] dmart: use http://people.canonical.com/~asac/tmp/startup.html [16:11] removed the dumps so it doesnt fail in chromium ... now its displayed [16:11] empty page for me [16:11] ogra: thats normal [16:11] ogra: do [16:11] firefox http://people.canonical.com/~asac/tmp/startup.html#`python -c 'import time; print int(time.time() * 1000);'` [16:12] i dont have FF installed :P [16:12] $BROWSER man ;) [16:12] *g* [16:12] botty ogra :-P [16:12] http://people.canonical.com/~asac/tmp/startup.html#1264003964709 [16:12] thats all i get [16:12] hmm [16:13] mabe i failed to upload ;) [16:13] * asac checks [16:13] ogra@osiris:~$ chromium-browser http://people.canonical.com/~asac/tmp/startup.html#`python -c 'import time; print int(time.time() * 1000);'` [16:13] Created new window in existing browser session. [16:13] and thats on the cmdline [16:13] do i need to fully close the running one ? [16:14] ogra: try again ;) [16:14] yes, you should close the running one to get startup time [16:14] ELAPSED 395 [16:14] right. thats probably not a full open [16:14] 395ms [16:14] ah, well, to many tabs atm i dont want to lose [16:14] heh [16:14] my browser tabs are usually part of my TODO list :) [16:15] but seems to work :) === suihkulo1ki is now known as suihkulokki [16:31] asac, I get the following numbers using your version: [16:31] ff-3.6: 8564, 9123, 8599, 6654, 8914, 8397, 8747, 8792 (dropping fs cache between runs) [16:32] ff-3.6: 4439, 4528, 4364, 4358, 4354, 4445, 4456, 4379 (not dropping cache) [16:32] chromium: 5396, 5194, 5260, 5072, 5231, 5341, 7110, 5054 (dropping fs cache between runs) [16:32] chromium: 1929, 1974, 2402, 1871, 1879, 1810, 1869, 2100 (not dropping cache) [16:33] ok. [16:34] i will upload a ffox 3.6 without xulrunner [16:34] wow, thats significant differences [16:34] we should compare that again [16:34] at least there are loads of less .so's to load for that [16:36] It might be the case that we're much more exposed to the hugeness of ff on this platform [16:36] yes, but IO is also pretty bad [16:36] which means that having lots of files to load is worse [16:36] firefox all-in-one has everything linked statically [16:36] I would like to run oprofile here, but oprofile seems to have build problems in the archive... I'm trying an offline build. [16:37] Total amount of data and number of files seems potentially significant [16:37] If the ff-3.6 build Thumb-2? I'm assuming it is, but just want to check. [16:38] yes. i think for a fair comparison we need the all-static package ... which is what we are aiming for in lucid anyway. i am just verifying that its fine and then upload it in a few minutes to the same location [16:38] dmart: ffox 3.6 from lucid should be thumb2 ... yes. [16:38] The amount of relocation work ld.so has to do might make a difference too. [16:38] Are there all-static packages for both browsers? [16:38] i can push a chromium-browser with thumb2 now that we have neon easily ... guess i should do that [16:39] Oh, was Chromium not Thumb-2? [16:39] dmart: chromium is all static ... there is no supported shared build [16:39] dmart: no. remember we talked about it: reason is that they dont support a non-neon build with thumb2 atm (build system restriction) [16:39] i want to fix that upstream still [16:40] but now that we have by accident a neon kernel, i can just upload with full armv7 [16:40] so lets check tomorrow again [16:40] hopefully both packages will be ready then [16:40] OK; I couldn't remember the precise issue. If you could do a T2 build of Chromium that we can test in the meantime that would be good... we want to check like with like as much as possible. [16:42] yes, i ffox 3.6 all-static will be uploaded a in a few minutes [16:43] chromium with t2 and neon will be uploaded shortly after [16:43] then i will work on build ssytem fix so we can build t2 without neon [16:44] gah [16:44] i was to quick with giving back evo-couchdb :( [16:46] hehe [16:46] plenty of builders ;) [16:49] gah [16:49] uboot ftbfs [16:50] objdump: '/build/buildd/uboot-imx-2009.08+really2009.01/build/build-imx51/post/libpost.a': No such file [16:50] ld: post/libpost.a: No such file: No such file or directory [16:50] make[1]: *** [/build/buildd/uboot-imx-2009.08+really2009.01/build/build-imx51/u-boot] Error 1 [16:50] * ogra glares at that log [16:51] it builds locally ! [16:51] damned [16:53] make[2]: Entering directory `/build/buildd/uboot-imx-2009.08+really2009.01/post' [16:53] (echo create /build/buildd/uboot-imx-2009.08+really2009.01/build/build-imx51/post/libpost.a; for lib in ; \ [16:53] do echo addlib $lib; done; echo save) \ [16:53] | ar -M [16:53] +Syntax error in archive script, line 1 [16:53] GEEZ ! [17:03] what the heck do i do now :( [17:04] seems ar cant handle + signs [17:04] Ah Cody complained about similar issues in the build when the directory name (version number) has odd chars [17:04] Where did you unpack it locally? [17:06] i used the old upstream patch indeed [17:06] *path [17:06] ... uboot-imx-2009.01/ [17:07] no plus there [17:07] (echo create $(LIB); for lib in $(GPLIB) $(SPLIB) ; [17:07] thats in the Makefile [17:08] i wonder if i can do anything with clever quoting [17:11] What's wrong with something like ar cq ? [17:11] the worst part is that the archive is empty anyway [17:12] " for lib in ; \" ... creates a null byte file anyway, i could probably just touch it [17:13] echo '!' >lib.a gives you an empty .a file [17:13] ...but of a dirty hack though... [17:13] well, the whole package is the worst crap i every created anyway [17:15] ogra: Is there a bug for this issue? [17:15] lool, not that i know of [17:19] lool, bug 494797 [17:19] Launchpad bug 494797 in binutils "ar fails when double-slashes are used in certain paths" [Low,Confirmed] https://launchpad.net/bugs/494797 [17:19] reported by Nonconventionally Creative ... heh [17:23] IIRC, the GNU ar format uses an internal file called "//" to store the archive symbol table... if wonder it that's related? [17:24] Could be [17:24] That said, I'm not sure it's the same bug since Cody worked arund it by changing the version [17:24] might be [17:25] lool, i *wont* change the version again ... rolling that messy package took me the whole day already ... [17:25] and its supposed to be only interim until we get fixes from freescale [17:25] I'm not asking you to, just commenting on whether it's the same bug or not [17:26] yeah [17:26] but given that the .a file ends up empty anyway i guess i'll just change the Makefile for now to create an empty archive [17:49] * ogra dputs a hacked up fix [18:02] yippie, that survived [18:09] ogra@babbage2:~$ cat /proc/cpuinfo |grep ^Revision [18:09] Revision : 51120 [18:09] and there we go [18:09] all working