=== bjf is now known as bjf-afk === asac_ is now known as asac [08:10] moin moin [08:38] yawn yawn [08:39] asac: ogra morning guys === cooloney_ is now known as cooloney [08:40] cooloney, hey, thanks for poking the NIC issue :) [08:40] dmart: there? [08:40] hi cooloney [08:42] ogra: no problem, i got no clue about that, so asked for help. heh [08:43] gah, seems i dont het uboot off my back today ... [08:43] *get [09:34] asac, no go for the NIC fix [09:54] huh? [09:54] ogra: thought you ignore that until we get input from fsl [10:19] asac, FSL attached a patch to bug 507887# [10:19] Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,Confirmed] https://launchpad.net/bugs/507887 [10:20] but seems its only half the fix [10:26] ogra: cool. and not ;) [10:26] right [10:26] there were 3 patches overall attached to three bugs [10:26] sadly none for the MMC issue and all of them against 2009.08 [10:27] so nothing that helps us [10:27] the L2 fix looks intresting though [10:27] the NIC patch looks simple enough [10:27] to check if it would work on .01 [10:27] where is the L2 patch attached? [10:28] mail [10:28] the NIC patch doesnt work [10:28] as i said above (and in teh bug), we seem to miss the actual patch that implements the function [10:29] heh. can you reply in bug and to mail? [10:29] i did [10:29] well, not by mail though [10:30] kk [10:30] see commants 3,4 and 5 on bug 507887 [10:30] Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,Confirmed] https://launchpad.net/bugs/507887 === dmart is now known as Guest46463 === Guest46463 is now known as dmart [13:48] fsck from util-linux-ng 2.16 [13:48] e2fsck 1.41.9 (22-Aug-2009) [13:48] /dev/sda6: clean, 146136/2321984 files, 948823/9277521 blocks (check deferred; on battery) [13:49] * ogra pokes his babbage with a pointy stick ... [13:49] you got no battery you darn thing !!! [13:51] ogra@babbage2:~$ sudo cat /proc/apm [13:51] 1.13 1.2 0x02 0xff 0xff 0xff -1% -1 ? [13:51] mumble [14:24] bug 456659 [14:24] Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,In progress] https://launchpad.net/bugs/456659 [14:25] bug 488267 [14:25] Launchpad bug 488267 in ffmpeg "ffmpeg should be built with -marm for lucid on armel" [Low,Fix released] https://launchpad.net/bugs/488267 === bjf-afk is now known as bjf [15:16] cooloney, do you know if the FSL kernel patches change anything wrt /proc/apm output ? [15:28] https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid [15:28] ogra: plars: GrueMaster: persia: dyfet: ^^ [15:29] asac, i think the fact that we have an outdated uboot is also RC (if RC means release critical :) ) [15:30] i.e. i doubt we'll ever get a fix for the MMC issues for 2009.01 ... so i think they should still be on release team radar [15:30] (which in turn enforces us to update to .08) [15:30] ogra: well. thats covered [15:31] or do we have a bug for that? [15:31] imo its well covered by the other two problems [15:31] which reminds me that i should RC the other bug if its not yet [15:31] we have a bug for the MMC issue [15:31] not for "hey we chose an old version" :) [15:31] ogra: can you target for lucid + milestone alpha-3 [15:31] and gimme bug id ;) [15:31] * ogra digs [15:32] Bug 506761 [15:32] Launchpad bug 506761 in uboot-imx "lucid uboot hangs on fatload uImage on fsl TO2 TO2.5 and TO3" [Medium,Confirmed] https://launchpad.net/bugs/506761 [15:32] thx [15:33] ogra: why is that wontfix for lucid? [15:33] that demotes that to non-RC ;) [15:33] uh [15:33] * asac changes that [15:33] also its medium ;) [15:33] thats overly polite -> critical now [15:34] you did set the Wontfix :P [15:34] and the Medium :) [15:34] really? [15:34] ouch [15:34] oh... maybe when i thought that the paritioning was good enough [15:34] right [15:34] right after the commant about partitioning [15:35] ogra: the version revision thing is not RC? [15:35] because it "doesnt block release" [15:35] not for now imho [15:35] dyfet: did busybox -marm work? [15:35] as long as FSL stands to their promises and we get a fixed release [15:35] yeah [15:35] ok [15:36] asac: yes [15:36] asac, i'm about to upload busybox [15:36] asac: already posted for sponsor [15:36] Bug 511197 [15:36] Launchpad bug 511197 in busybox "fails to build on arm lucid (thumb2)" [Undecided,Confirmed] https://launchpad.net/bugs/511197 [15:36] dyfet: where? [15:36] got that in my queue ... [15:36] ah in the bug [15:36] just ping me here ;) [15:36] just didnt get to it yet [15:36] i read bugmail at most twice a decade :-P [15:36] lol [15:37] asac, dont worry, i need some sponsoring points anyway ;) [15:38] asac, did you talk with doko about Bug 417009 (shipping the jaunty libgcc_uno.so [15:38] ) [15:38] Launchpad bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,Confirmed] https://launchpad.net/bugs/417009 [15:39] its still "confirmed" so i assume we still ship the hack [15:40] asac, if you want the hack gone that should be on our list [15:43] ogra: talked to doko about this today [15:43] ah, good [15:43] does he see a chance to get that fixed ? [15:43] he said its not RC if we ensure that we build it again from fresh sources [15:43] aka the lib [15:44] well, we still ship old crap :) [15:44] not RC because the fix is so unlikely, that it doesnt make sense to stirr up release team [15:44] ok [15:44] plars: so after talking to doko about python dove killage, he mentioned that python wasnt even build in lucid yet, so maybe the python2.6 package that is building right now, will help [15:50] fsck from util-linux-ng 2.16 [15:50] e2fsck 1.41.9 (22-Aug-2009) [15:50] /dev/sda6 has been mounted 40 times without being checked, check forced. [15:50] Pass 1: Checking inodes, blocks, and sizes [15:50] GEEZ !!!! [15:50] i only added a printf ! [15:50] why the heck does it not think its on battery anymore °! [15:51] * ogra reboots again [15:52] ogra: wrong negation? feels ok if it doesnt think its on battery ;) [15:52] unless you have a battery :-P [15:52] oh [15:52] * asac should read more backlog [15:52] good [15:52] well, you saw the code before [15:52] ogra: do you get a warning during build? [15:52] like missing prototype? [15:52] i just added a printf to print out the value of the ac [15:52] nope [15:52] so stdio is probably included ;)= [15:52] ? [15:52] ok [15:53] lets see, probably it was actually an enforced check because 40 mounts were done [15:53] does it build with all warnings? [15:53] maybe [15:53] mountall: Could not connect to Plymouth [15:53] fsck from util-linux-ng 2.16 [15:53] e2fsck 1.41.9 (22-Aug-2009) [15:53] /dev/sda6: clean, 146112/2321984 files, 949695/9277521 blocks [15:53] init: plymouth-log main process (3168) terminated with status 111 [15:53] hmm, it really doesnt see the battery anymore [15:53] now thats weird [15:55] if (fscanf(f, "%s %s %s %x", tmp, tmp, tmp, &acflag) != 4) [15:55] acflag = 1; [15:55] is the original code [15:56] if (fscanf(f, "%s %s %s %x", tmp, tmp, tmp, &acflag) != 4) [15:56] printf("acflag is: %x", acflag); [15:56] acflag = 1; [15:56] is what i made out of it [15:56] it doesnt exec the printf ... nor does it set acflag [16:23] asac: cool, will give it a try [16:48] uff [16:48] so next week i want a better meeting [16:48] ;) [16:48] more success to report [16:48] please make that happen :) [16:48] heh [16:49] at least you didnt have to report many disasters :) [16:56] ogra: when did pitti send that announce? [16:56] was that in a thread? [16:56] i cant even find it ;) [16:56] you mean the moving of people from rookery to a new machine ? [16:56] no. the moving of the work itesm from macaroni to people ;) [16:57] http://people.canonical.com/~pitti/workitems/canonical-mobile.html [16:57] vs [16:57] http://macaroni.canonical.com/~pitti/workitems/canonical-mobile.html [16:57] hmm [16:58] asac, ubuntu-platform@ [16:58] ogra: right. but was that standalone mail or a reply to an existing thread? [16:58] 20.01.2010 14:25:05 [16:58] standalone [16:58] i have all that in my main inbox [16:59] with a big ANNOUNCE tag [16:59] ok i dont have it ;) [16:59] look for ANNOUNCE in the subject [16:59] guess it was killed in a my eager zero inbox effort ;) [16:59] heh [17:01] hmm, so powertop seems to miss some kernel options on imx51 === fta_ is now known as fta [17:58] asac: what about snapdragon? :) [18:01] fta: i will demote the ffmpeg depends for this upload ... so its not rejected because depends arent fulfillable [18:01] we can put that back when its in [18:02] asac, /me sad. why not use !armel instead? [18:02] fta: we have it on armel. just not in the archive [18:02] its not because of armel ... just because of archive [18:03] i dont want to block the chromium upload on first getting the other stuff up [18:03] why is it rejected in the 1st place? [18:03] if its not fulfillable [18:03] then it cant go in [18:03] all depends need to be there [18:03] so its recommends now. [18:03] you can drive the ffmpeg als in [18:03] why not submit it first? [18:03] its just licensing for that [18:03] because i dont want to wait any longer [18:03] *sigh* ok [18:03] you could have uploaded it ;) [18:04] would be great if you could do. [18:19] asac: chromium now fails for me :P [18:19] export LD_LIBRARY_PATH=/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/lib.host:/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/lib.target:$LD_LIBRARY_PATH; cd v8/tools/gyp; mkdir -p /var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/obj.target/geni; "/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/mksnapshot" "/var/tmp/portage/www-client/chrom [18:19] ium-9999/work/chromium-9999/out/Release/obj.target/geni/snapshot.cc" [18:19] pure virtual method called [18:19] terminate called without an active exception [18:22] what was that error about? [18:23] and i'm using gcc-4.3 [18:35] that was about -fno-strict-alias breakage for ggc 4.3 [18:35] if you are really sure everything uses gcc 4.3 on your system now then i dont know [18:35] but i would expect it doesnt [18:35] you can try -fno-tree-sink [18:36] grab the patch from our packaging .head [18:36] no_tree_sink_v8.patch [18:36] * asac out [18:38] well, but the -fno-tree-sink is used only if gcc_version=44 [18:38] and it worked before, i'm wondering if you now need gcc-4.4 :P [19:32] new python didn't help btw [20:47] damn [20:47] plars: there? [20:48] plars: so you basically can go to console, and make the board hang by running import pybootchargui right? [20:48] asac: yes [20:48] asac: right, that one and uno both seem to do it so far. Haven't found others yet [20:48] plars: so idea is to run python -v [20:49] that should spit out the modules that get implicitly imported [20:49] if you | tee that to a file you might be able to try each of those until you find which import causes this [20:49] ah, neat, didn't know about that [20:49] right [20:50] ok, the last thing I see it trying to import was cStringIO [20:50] need to reboot, sec [20:50] yeah [20:50] so check if that alone causes it ;) [20:50] then we can check what it does etc. [20:50] also ... did you find any module you could import without a hang? [20:51] asac: yes, plenty. These had been the only two so far that I found that caused it to hang [20:52] cat ./Modules/cStringIO.c | pastebinit [20:52] http://pastebin.com/f51e45d28 [20:52] cStringIO imports ok, must be something after that [20:53] plars: so we dont see the module that fails to import? [20:54] e.g. it hangs before the dump? [20:54] asac: correct [20:54] plars: can you paste the current import list? [20:56] asac: I don't think it's an import from there... [20:56] asac: importing socket gives me the same impot list with python -v, and that's the last thing that this module imports [20:57] from where? [20:58] let me check something [20:58] asac: I'm still looking at uno [20:59] ah [20:59] http://paste.ubuntu.com/360871/ [21:00] thats import uno on x86 [21:00] >>> import pybootchartgui [21:00] import pybootchartgui # directory /usr/lib/pymodules/python2.6/pybootchartgui [21:00] # /usr/lib/pymodules/python2.6/pybootchartgui/__init__.pyc matches /usr/lib/pymodules/python2.6/pybootchartgui/__init__.py [21:00] import pybootchartgui # precompiled from /usr/lib/pymodules/python2.6/pybootchartgui/__init__.pyc [21:00] thats the thing i get for bootchart [21:00] so its not that easy :( [21:08] plars: do you know about other modules that cause this hang? [21:09] asac: those are the only two I've found so far [21:10] # pybootchartgui/__init__.pyc has bad magic [21:10] what does that mean? [21:13] plars: maybe removing the precompiled bits helps? sudo rm /usr/lib/pymodules/python2.6/pybootchartgui/*.pyc [21:13] sorry... just trying random things [21:18] >>> import pybootchartgui [21:18] import pybootchartgui # directory pybootchartgui [21:18] # pybootchartgui/__init__.pyc has bad magic [21:18] import pybootchartgui # from pybootchartgui/__init__.py [21:18] # wrote pybootchartgui/__init__.pyc [21:18] ah ... now i see where its coming from. [21:18] the package ships an old __init__.pyc here: [21:18] /usr/share/python-support/pybootchartgui/pybootchartgui/__init__.pyc [21:18] remove that ;) [21:19] asac: interesting [21:19] I don't have that file [21:20] and I don't see any .pyc file in the dpkg -L list [21:20] odd [21:20] dpkg -L pybootchartgui | grep pyc$ [21:20] /usr/share/python-support/pybootchartgui/pybootchartgui/__init__.pyc [21:20] well. its karmic [21:20] however after the earlier rm, I seem to be able to run pybootchartgui [21:20] so its probably clean ;) [21:20] cool ;) [21:20] so maybe... but what about uno? [21:21] and where did some stray .pyc come from? this was a new install [21:21] plars: have you tried to reinstall pybootchargui after python upgrade? [21:21] maybe give that a try [21:21] no [21:21] maybe it needs just fresh .pyc [21:21] the other directory i asked you to clean is generated during install [21:21] by python-central or something [21:22] not sure if tere are triggers that recreate all .pyc if python is updated though [21:22] to be sure check if reinstalling still keeps pybootchartgui working [21:22] also... [21:22] sudo rm /usr/lib/python2.6/dist-packages/uno.pyc [21:22] import uno still hangs [21:23] plars: uno is something different. thats ooo [21:24] thats a different beast [21:24] asac: right, but symptom is the same [21:24] yes [21:24] plars: so does reinstalling pybootchartgui make keep it working? [21:24] ;) [21:24] asac: have to wait for the reboot [21:24] I hung it again trying uno [21:25] ah ok [21:26] * asac checks something [21:27] asac: pybootchartgui seems to be working now [21:28] very good [21:30] plars: have you tried to remove /usr/lib/python2.6/socket.pyc as well? [21:30] asac: no, but importing socket seemd ok [21:30] asac: no help [21:30] ok. [21:31] so i somehow dont get rid of the thought that the uno issue has something to do with the [21:31] uno thin we have in OOO [21:31] e.g. the bug that requires us to ship the jaunty so [21:31] i am not sure if that is pyuno.so though [21:31] do you remember? [21:31] asac: no idea, sorry [21:31] the bug about this was https://bugs.edge.launchpad.net/ubuntu/+source/binutils/+bug/436617 [21:32] Launchpad bug 436617 in binutils "ARM unwind table linker processing broke OO's uno2cpp" [High,Confirmed] [21:32] will be interesting to boot the next livecd if it has the new python in it and see if it works [21:32] let me poke chris [21:38] plars: so ... pyuno.so pulls in that ugly jaunty libgcc3_uno.so [21:38] through libpyuno.so [21:39] somehow [21:39] guess thats not build with thumb2 [21:39] I see [21:39] I'm afraid that all of this may be hit or miss until x0 [21:40] from the sounds of things, this all likely relates back to that [21:40] the gcc3_uno.so thing probably yes. [21:44] plars: anyway, so with just removing pyuno we get a booting desktop now? [21:44] plars: if thats the case thats all we can hope for ;) [21:44] and we should consider to just do it to get working images until we get X0 to test [21:44] asac: oh, pyuno was never preventing it from booting, just happened to be another pythong module I noticed that caused trouble. Previously I was able to get it booting by taking pybootchartgui out of the init [21:45] asac: so no reason to remove uno [21:45] plars: cool. so basically with a reinstalled bootchart it works? [21:45] asac: seems to be, tomorrows image will be good to double-check with [21:45] guess we have flaky but working images tomorrow with some luck then ;) [21:46] plars: great. with that you can go and do more positive stuff until we get news on hardware/kernel front i guess. thanks a lot!!! [21:46] asac: thanks for all your help! [21:48] no thanks to you ... at least i can somehow sleep again ;) [21:48] the good I get out of this is that if we have everything recompiled the Y1 boards might become more and more stable ;) [21:53] asac: I didn't think you ever slept! [21:53] its those things i tell you :-P [21:54] actually i skip the timezone lag for sprints this way [21:54] i just keep my live going in central US time ;) [21:54] anti-jetlag method its called [21:55] heh [23:19] persia: http://pastebin.com/f429b20ae ... anything else you would like to see there? [23:23] asac: From policy 4.1.4, missing bits include: [23:24] 1. how to generate the fully patched source, in a form ready for editing, that would be built to create Debian packages. [23:24] (most people do this with debian/rules patch, which might work for your CDBS mess) [23:25] 3. Remove source modifications that are currently being applied when building the package [23:25] This might just be telling someone to unroll the tarball, but I'm not sure. [23:26] You've hit #2 and #4 well, and added lots of other interesting stuff :) [23:30] persia: 1. is covered in patching [23:30] section [23:30] imo [23:30] and 3. sounds odd ;) [23:30] not sure what that means [23:30] some patches are feature patches, some are needed to build (or at least there might be patches) [23:31] i dont think anyone can ask for keeping those separately documented ;) [23:31] for me patching section also tells 3. [23:31] asac: You7re supposed to provide a step-by-step guide, not say "start a local build and break in" :) [23:31] yeah. thats bad ;) but debian/rules patch is broken :-P [23:31] the joy of cdbs [23:31] I've always interpretedf "remove source modifications" as being both classes of packages. Someone who does silly things gets to keep both parts. [23:32] anyway, for a reasonably educated guy this shouldnt be a problem ;) [23:32] You know, lots of people don't use CDBS anymore :) [23:32] right. but kick off a local build is quite generic ;) [23:32] you can even use the instructions in the section above ;) [23:32] good. i think all is fine. thanks! [23:32] Well, but it's also a non-ideal way to do it, because you have to break it. [23:33] thats a bug [23:33] debian/rules patch should just work, but last time i checked it didnt [23:33] There's probably a CDBS rule like secret-internal-quilt-patched-but-not-built-but-you-don't-know-the-rule-name: rule that one could call. [23:33] heh. we tried a bit [23:33] its a bug in the tarball.mk i think [23:33] Oh. Ugh. [23:33] we have that in firefox etc. [23:34] Did I mention that tarball-in-tarball is ugly too :) [23:34] but let me assure oyu its not a practical problem [23:34] you want to edit and then usually continue build anyway ... [23:34] yes, but without tarball in tarball you dont want to build the sources regularly [23:34] Anyway, your README.source is massively better than not having one at all, especially for such a confusing package using a strange special private CDBS derivative. [23:34] heh [23:35] I understand the problem, I just think the solution is more RAM :) [23:42] so with enough ram, even cdbs-edit-patch would be great experience ;) [23:43] Well, not as bad, assuming the content was fully cached or one is operating on a tmpfs [23:44] I'd probably still use quilt, but that's just because I've come to not like digging through CDBS when I wanted to figure out how to do something. dh(1) makes my life easier. [23:46] aha