[03:21] lool, mesa built successfully in launchpad-buildd on babbage 2 [03:21] lool, I believe I can officially say argh [04:17] 10 hours mcasadevall? [04:18] Build needed 03:44:36, 1393092k disk space [04:18] Nope [04:18] SOmething has got seriously wrong on the actual buildds ... [04:19] ahh was like 12:30 my time when we were talking about it so thought it might have actually taken the 10+ hours [09:17] mcasadevall: Could you bring this up with IS? [09:56] hmm, doesnt look if i gained much with more ram for debootstraps second stage ... its simply the lack of CPU making it slow [10:08] hmm, ok, the unpacking surely is faster [10:37] wow, locale-gen is gotten a lot faster [10:40] real 51m49.350s [10:40] user 48m31.682s [10:40] sys 0m21.285s [10:40] not to bad for an ubuntu-minimal [10:41] * ogra comments all the swap stuff and runs it again [11:37] real 51m9.016s [11:37] user 47m42.963s [11:37] sys 0m22.133s [11:37] hmm, no significant difference [11:38] so guess i'll leave the swap part in but dont add the ugly bits that make it be used *before* debootstrap runs [11:39] since that requires to unpack busybox-static in the choot before switching to VM to have swapon available before a system exists [11:47] meh /me wants a --to-the-rim option for dd so it only fills a file up to the max available space on the target device [11:57] ogra: What's the status of the banshee bug? [11:58] dyfet, is looking into it atm [11:58] ogra: Why are you assigned? [11:59] dyfet: hey what's the status of the banshee bug? [11:59] should i reassign ? [12:00] ogra: What do you think? [12:00] well, i felt responsible for it even though dyfet looks into it atm [12:07] ogra: If you're responsible for it, could you please give me a more detailed status update? There's nothing in the bug [12:07] I don't know what's being investigated, what are the current results etc. [12:08] The fact that dyfet is looking into it is mentionned nowhere [12:08] well, i asked dyfet to take a look and pointed him to the vorbis error [12:09] ogra: When was that? [12:09] ogra: Could you please document that in the bug itself? [12:10] that was two days ago, i'll add info to the bug [12:11] ogra: Thanks [12:11] ogra: What about the debian-cd specs (subarches and mx51 changes); will this happen for Alpha 3? [12:12] i'd really like to have a prototype but without the HW its not that easy to work out a uboot layout [12:14] ogra: Did you test Uboot on the lange? [12:15] ogra: I don't think the subarch changes need any hardware though [12:15] ogra: Are the Uboot packages ready? [12:15] i tested the binary image we had [12:15] but that didnt work [12:15] Ok [12:15] was waiting until NCommander has his binary through NEW [12:15] So it's in NEW? good [12:15] he told me tue. its sitting there [12:16] ogra: So what about the armel -> armel+mx51 changes? [12:16] * ogra sighs ... calling cleanup on 0 1 2 3 9 11 13 15 has intresting sideeffects [12:17] lool, i want to have uboot-install separately [12:17] Yes? [12:17] so i'm blocking on the layout as i mentioned above [12:17] Well you could rename the script first [12:17] That makes room for the Marvell stuff in parallel [12:18] grmbl, why is cleanup called multiple times now [12:18] lool, ok, i'll do the renaming this week [12:19] Ok thanks [12:37] * ogra slaps forhead [12:37] * ogra removes "exit 0" from the end of cleanup() and goes to a corner to cry [12:45] grmbl now it doesnt exit properly [12:46] * ogra curses, it was all working before [12:47] * ogra re-adds the cleanup acll at the end of the script [12:48] trapping on 0 is simeply not working right === cbrake_away is now known as cbrake [13:24] hi all [14:06] dyfet: Hey when you come up, could you update the banshee bug with your findings? [14:06] ogra: trap 0 works fine for me :-) [14:07] lool: yes...but I dont have update yet...I was fighting hw part of yesterday to get karmic setup on it :) [14:07] lool, i have massive probs with all the traps here [14:08] if i trap out of run_vm it essentially does nothing [14:08] well, it prints the "Cleaning up..." but exists immediately [14:11] everywhere else trapping works fine [14:12] well, thats not actually right, trapping works in run_vm if the vm actually runs but not while wget runs or the vm is just starting up [14:12] so is marvell support going to be kept in karmic? [14:13] kept ? [14:13] its being added [14:14] ah, new kernel flavor? i just meant the armv5, didn't know if it was going to go v6 or v7 only during karmic [14:14] it will be v6 [14:15] oh wow, i should have read up more on sheeva [14:17] Sarvatt: Right, Sheeva wont work [14:17] Sarvatt: We didn't support any marvell flavour last cycle [14:18] I find it unfortunate that we're not supporting v5, but we're targetting high end ARMv7 netbooks/hardware so it makes sense to rip the benefits of the new instructions [14:19] lool, swap stuff pushed btw, feel free to edit away [14:23] * ogra builds a desktop image to see how swap affects it [14:24] Morning ogra [14:24] grmpf, why does it die now [14:24] hmm, swapsizes above 1G seem to be no good idea [14:33] i'm so confused, marvell says "It contains advanced three-level branch prediction, a variable stage pipeline, and an integrated memory controller, providing unmatched high-end performance and low-power requirements. Compliant with the Cortex A8, Sheeva also supports both the ARMv6 and ARMv7 instruction sets, making it the world's first dual ARM ISA compatible CPU." but the docs for the sheevaplug say its a Sheeva 88SV131 ARM v5TE Pro [14:33] cessor Core with MMU and L1/L2 Cache [14:34] the docs are right [14:41] so moral of the story is, if i buy one make a copy of the archive now before things move to armv6? :D [14:41] the moral of the story is to switch to debian \o/ [14:42] Sarvatt: marvell is saying that sales stuff that they can produce ARMv6/ARMv7 cpu's based on sheeva tehnology, but their current cores are are ARMv5 [14:44] s/sales stuff that// [14:46] yeah for armv5 i guess thats the best option, i really would like to get a v7 to play with instead but the sheevaplug looks like a better option for me for the price right now vs a beagleboard and i'm starting to get convinced other platforms arent going to come out anytime soon at a decent price :D [15:15] ogra: Hmm you seem to assume all vars aren't set in the env [15:15] ogra: You should be init-ing things like SWAPFILE or NOSWAP [15:16] with ="" ? [15:16] hmm [15:16] thats a lot of extra empty lines ... [15:16] They are not "extra" [15:16] heh [15:16] yeah [15:16] i'll add them [15:16] ogra: Since the script is so young you could still consider set -U [15:17] what does set -U do? [15:17] sorry set -u [15:17] rjune_wrk: It errors out if you use an undefined var in an expansion [15:17] Ahhh [15:17] IOW, a very good habit. [15:18] A bit hard to retrofit in some pieces of code [15:18] I believe that. [15:18] ogra: what cpu was rootstock (well qemu-arm) using by default before the cortex-a8 change? [15:19] Sarvatt, the default versatile one [15:19] it didnt specify -cpu before [15:20] arm926 i belive [15:20] guess it uses "any" if you dont specifiy? [15:20] ah [15:22] its just nuts how much faster it is doing the second stage in a chroot in the android qemu (like 5 minutes there) [15:22] what cpu is that ? [15:22] (specifically at what speed does it run) [15:23] i havent gotten qemu to do more than 200MHz here [15:23] (on arm) [15:30] checking, battery about to die brb [15:40] http://sarvatt.com/downloads/emulator.txt [15:41] BogoMIPS : 736.22 [15:41] thats on my faster pc that took almost 5 hours with rootstock the other day, will check what it is on the one i just built it on in a sec (atom cpu) :D [15:43] BogoMIPS : 85.40 [15:43] right, thats a bit of a differentce [15:43] *difference [15:43] its QEMU PC emulator version 0.8.2 [15:44] but it builds fast on this 85 bogo mips one which is the weird part [15:44] do you see the cpu speed in dmesg ? [15:46] i'd really love to speed up debootstrap ... the rest runs totally fine, but the --second-stage processing is awful [15:46] http://sarvatt.com/downloads/emu-dmesg.txt [15:47] sorry, I had 512mb memory when I did it [15:48] hmm [15:48] only 96 in that dmesg [15:48] right, that means their qemu is hacked up i guess [15:49] yeah it is quite alot, thats why they havent upgraded it since theres so many changes against the old version [15:51] http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary [15:52] doesn't help they do most of the development in a private perforce vcs and just import it in batches every now and then [15:53] yeah [15:53] not very clean [15:53] * ogra rolls a qemu with lool's 512M patch and checks if that changes anything [15:54] i was trying to add a gig of swap today, but that didnt make any speed difference [15:55] (using awful hacks that added the swapspace before debootstrap runs) [15:57] Sarvatt: Oh Google also patches qemu for 512MB of RAM? interesting [15:58] they have a custom platform that allows it I think? [15:58] not using versatile [15:58] ah [15:59] lool, did you notics any speed improvement with your patch [16:00] ogra: For what? [16:00] qemu debootstrapping [16:00] I didn't load qemu with heavy workloads, so no [16:00] ah [16:00] I don't think 256M or 512M make any difference for a debootstrap [16:01] it might make a difference to the dpkg database processing [16:01] it hangs endelss in the preprocessing in rootstock [16:01] *endless [16:03] neat, XenARM has a paravirtualized goldfish platform from android qemu [16:34] lool, hmm, your qemu patch doesnt work if applied against our package it seems :/ [16:34] DEBUG registered size=10000000 SDRAM at 0x0 with offset (nil) [16:34] Not enough memory (requested_size = 268435456, max memory = 268435456) [16:49] hmm, there seems to be a bunch of stuff missing in the patch [17:09] lool, do you remember against which 0.10 version you made the qemu patches ? [17:22] hrm, i suspect we apply some patch that breaks it [17:31] ogra: Against tip [17:31] oh, i thought you did it against 0.10.x [17:31] ogra: No, it wont work against 0.10 [17:32] yes, i see that [17:32] memory management was redone and didn't allow for split memory banks in <= 0.10.x [17:32] aaahh [17:43] ogra: Is it you or NCommander working on the gnome-keyring bug? [17:44] on my list [17:44] NCommander: hey when do you usually roll the wiki page for next meeting? [17:44] i need some more deskspace for the B1 though [17:44] NCommander: I'd like to add a couple of topics early in the agenda [17:44] lool, i think he does it 10mins before the meeting :P [17:53] NCommander: Ah it would be cool if you could roll the pages now; otherwise I can send you topics by email [18:08] lool, I'll roll it a little later today (I usually do it a day or two after the meeting) [18:09] lool, just shoot me an email and I'll amend the pages [18:09] * NCommander has to add somethinge sel as well [18:13] * ogra wasnt aware NCommander speaks french [18:15] NCommander: sent [18:15] * ogra just remembered that sel is salt in french :) [18:16] * NCommander knows no human language expect English [18:16] lol [18:16] partially at least :) [18:17] *grumble* [18:17] wow, the tip qemu just trashed my filesystem in the image completely [18:17] o____o; [18:18] * ogra takes another img ... [18:18] after the last two days i have plenty of them [18:18] /etc/init.d/rc: line 74: /etc/default/rcS: No such file or directory [18:18] error: '/etc/init.d/rc' exited outside the expected code flow. [18:18] init: rc-sysinit main process (379) terminated with status 1 [18:18] wow yeah i'm doing a second stage in 256mb ram and its alot slower [18:18] geeez [18:18] o]______-o; [18:21] * ogra sees no difference with 512M in qemu yet [18:25] still sitting there ... doesnt move [18:25] but i wasnt really expecting a difference through more ram [18:26] that would have shown with the swap this morning already [18:27] i have the gui up this time too though, thats eating alot of the cpu time. 13% phone 11% alarm clock 9% google apps 21% dpkg kernel time 7% user 34% debootstrap user 14% kernel [18:28] well, you are bootstrapping from a running system [18:28] tahts a bit different anyway [18:33] hmm 141mb ram inactive, really doesnt need more ram.. its quite nice how in depth the android debugger is for profiling [18:35] ahhh i think the android environment tries to keep 50% ram free [18:45] lool, ogra, 13563 mcasadev 20 0 372m 367m 64 R 69.6 72.9 7:14.26 lzma [18:45] Looks like lzma is sucking down the machine's resources [18:45] and is paging out [18:49] wait a tick [18:49] never mind [19:08] mcasadevall / NCommander: You said yesterday it was working fine?! [19:08] lool, on my boards, I didn't build on rimu [19:08] lool, but the build passed on both rimu w/ dpkg-buildpackage, and under launchpad-buildd on my B2 [19:08] So on rimu it's slow but on our boards it's not [19:08] lool, it passed though, 4 hours, no hang [19:08] (the build took 3:40 on my boards) [19:08] 4 hours is about the same you got and shorter than on the buildds [19:08] Right [19:09] NCommander: Chase IS to see what is different? [19:09] lool, infinity just went WTF when I told him it passed [19:09] since it shouldn't [19:09] rimu is setup the same way as the buildds expect access permissions, and it doesn't have launchpad-buildd === bizkut-miau is now known as bizkut === cbrake is now known as cbrake_away