=== NCommander is now known as Guest48610 === Guest48610 is now known as NCommander === NCommander is now known as Guest88322 === Guest88322 is now known as NCommander === asac_ is now known as asac [07:58] Grr.. Illegal instruction in mksquashfs in dove livefs build. Is this a different bug than the one we saw for imx51 livefs last week? [08:47] persia: It might be that the dove kernels on the buildds have to be updated [08:47] persia: I think there was an errata for thumb 2 traps for dove which dave mentionned ina bug [08:47] Actually Eric did [08:48] bug #494831 [08:48] Launchpad bug 494831 in linux-mvl-dove "Alignment trap/Unhandled fault errors on boot" [Critical,In progress] https://launchpad.net/bugs/494831 [08:48] I definitely heard about that. Do you think that would affect makesquashfs? [08:48] persia: If we rebuilt it with thumb2 it might [08:48] But I thought it had been rebuilt with -marm to workaround that [08:49] That was my memory as well, and we ended up having working livefs builds for imx51. [08:49] Do you have hardware that could run a mksquashfs test to replicate the bug? [09:01] I do but it's not online [09:02] OK. Maybe someone else will volunteer then. [09:02] Checking the build log, I don't see the mksquashfs version [09:02] If it works in a local environment, then it's a config thing on the builder, and if it doesn't, then it's something we need to tweak, and I'm not sure which applies. [09:04] I checked livecd-rootfs, and mksquashfs is run in the chroot [09:04] You could check on the porter box, but that's imx51 [09:05] persia: BTW you might want to allow both for aufs and unionfs in your script [09:06] (Ideally mount --union and fuse union as well; I think that's all casper supports) [09:06] I have my own script which OOPSes the kernel :-( [09:06] heh. Guess we don't want to merge that. [09:07] Yeah, I was looking at /proc to try to figure out which filesystems the running kernel supported, and do some case statement to use them in some preferred order. [09:07] But I didn't figure it out in 10 minutes, and figured I'd just merge plars' stuff because it does make it simpler for the lucid work. [09:10] persia: /proc/filesystems only list the modprobe-d or builtin ones though; aufs and unionfs were often built as modules [09:11] lool: Hrm. Which means I'd have to do some probing, which gets annoying (and the installer prober warns it may crash the machine) [09:18] grmpf [09:19] Sometimes I'm tempted to try to set up a distributed network of proxies, each attached to a separate (specific) node, and forwarding me only unique entries. [09:27] persia, did anyone ask lamont to update the squashfs-tools version on clementine ? [09:28] ogra_: No idea. Is that something that would be different between imx51 and dove? [09:28] no, clementine is the livefs builder for both subarches [09:30] Hrm. [09:30] * persia looks at logs again [09:30] the crontab entry is a bit silly [09:31] seems imx51 is never tried if the other arches have a non zero exit code [09:33] Ah, that explains why I didn't get any mail about imx51 [09:33] the crontab entry connects the two builds with && [09:33] should be changed to ; [09:34] Who can change that? [09:37] me if i'm back from vacation, StevenK, lool, cjwatson etc etc [09:37] wotn help the illegal instruction though [09:38] * ogra_ wonders if the -marm actually applied to the current build thats used on clementine [09:40] Dunno. [09:40] So it's ubuntu-cdimage? [09:40] I'll bug someone from the team to look at it soon then. [09:45] its not that important [09:46] Well, except that I promised to watch the daily builds this week. [09:46] the illegal instruction will be identical no matter for which target you build [09:46] And if they aren't working, that needs to be investigated. [09:46] so squashfs-tools needs to be fixed first ... else you just waste buildd time [09:47] if -marm doesnt work, i know that -O0 is supposed to [09:48] And it's the same group that can check versions on the builder, or do I need a buildd OSA? [09:50] you need lamont [09:50] Heh. OK. [09:50] he pinned the karmic version until last sunday [09:50] That's straightforward enough. [09:50] and had a cronjob to release the pinning [09:51] but probably it just unpinned and didnt upgrade to the version built with -marm [09:51] Right. That needs to be checked, and maybe force-upgraded. [09:51] If it *did* upgrade, it needs to be recompiled with -O0 [09:51] so first check if the -marm built version is there ... if so, rebuild squashfs-tools with -O0 [09:52] and if that doesnt work, we're out of ideas and probably need to pin the karmic version for longer [09:52] Cool. That's a set of instructions that can be executed :) [09:52] Well, except we'd need to do a manual downgrade, etc. [09:52] until someone can investigate deeper [09:52] But yeah. [09:55] I've updated the crontab [09:56] lool: Cool. Now I'll get twice as many emails :) [09:56] http://launchpadlibrarian.net/36706216/buildlog_ubuntu-lucid-armel.squashfs_1:4.0-3ubuntu1_FULLYBUILT.txt.gz seems to have -marm [09:56] but -O2 [09:56] ogra_: Yep, but it's a question of which is installed. [09:56] right, i just wanted to make sure it built [09:56] being on vacation i dont check such stuff ;) [09:57] heh :) [10:12] Note that it said illegal instructions, not sigbus [10:12] (sigbus would have said: bus error ...) [10:14] Should a -mthumb2 vs. -marm issue report a bus error? I thought it was just illegal instructions. === ogra_ is now known as ogra [10:23] persia: My understanding is that the boards support thumb2 but mishandle unaligned accesses in thumb2 [10:23] (They should handle these, but not without a fixed kernel) [10:24] That was my understanding as well [10:25] But the side discussion about squashfs-tools might provide a workaround for the short term (or did I misunderstand? ) [10:25] we're supposed to get a kernel with mtd support at some point so we can replace the existing broken one [10:25] or a mtd module for the existing one [10:25] MTD? Aren't those the on-chip flash devices? [10:25] right [10:25] thats where the kernel lives in these boards [10:25] That's surely a different issue. [10:25] and we have no access to the devices [10:25] Oh, you mean we don't have access to update the kernels? [10:25] Ah. [10:25] so we cant reflash with a new kernel atm [10:26] a driver exists but not for this specifc kernel binary [10:26] RIght. [10:27] I understand. [10:27] So the issue exists *only* on the buildds? Should replication testing not happen on other hardware? [10:27] I'd think it'd be interesting to fix it elsewhere, and then look at the buildds, but maybe I am behind. [10:27] it doesnt occur elsewhere [10:27] and nobody of us has the buildd HW [10:28] Ah. [10:28] well [10:28] davidm has [10:28] If that's already been tested, I won't ask for testing :) [10:28] and i replicated the original issue on his board remotely [10:28] but he shut off access to it afterwards [10:28] This is the action item from the 20091208 meeting? [10:28] yes [10:29] OK. I understand then. [10:29] dmart has a board as well, but i'm not sure it has the exact same kernel [10:29] Well, neither of them seem to be in-channel right now. [10:29] he brought up the two fixes (-marm and -O0) [10:29] and davidm wont be until new year [10:30] So is the squashfs-tools a useful workaround? [10:30] ? [10:30] Won't we still encounter other issues running lucid code on those? [10:30] we shouldnt according to dmart [10:30] either of the above compile options should fix it [10:30] I don't quite understand why *only* mksquashfs is affected [10:31] kernel module vs userspace [10:31] But I'll try to sort that, and we'll see what breaks next. [10:31] Oh, it's an ABI thing between the kernel squashfs interface and mksquashfs? [10:31] So it wouldn't affect other stuff? [10:32] well, it might if you have userspace things using kernel ABI ... [10:32] Would linux-libc-dev be affected? [10:33] That's the only part of the toolchain that I think regularly uses that sort of stuff. [10:33] hmm, i doubt it, we would have seen more fallout if it had [10:34] OK. Then we have a workaround. [10:34] Be a few hours before we have access to look though :( [10:34] yeah [13:23] rabeeh: do i get a present? :) [13:24] Does anyone happen to know how Soyuz handles two source packages in Ubuntu that build a binary package with the same name? [13:26] -ECHANNEL [14:48] ok chromium building now in qemu-arm-static chroot ;) [15:04] asac: how many hours? :) [15:09] not sure ... i hope less than native ;) [15:10] but maybe i am too optimistic ;) [15:10] on native it takes 19h or so with more or less fast usb drive (with tests disabled) [15:10] on babbage 3 [15:11] or 16 ... not so sure atm ;) [15:11] Surely a big chunk of that is swapping, no? [15:11] well... whenever i looked most of CPU was really on action ;) [15:11] but swapping is probably a big thing for the linking [15:12] would be interesting to see how long it'd take with distcc:ing over to a non-emulated cross compiler too. :) [15:12] I was thinking for some of the libraries as well. I've been doing a build that includes webkit on a 512MB powerpc box and it keeps swapping out just to make more cache space available. I'd expect the same for armel. [15:13] i hope that qemu is in the middle of native cross and all native [15:13] Depends on the RAM of the host, really. [15:13] qemu system emulation was quite a bit slower than native for me. Hopefully static is quicker. [15:13] If you have lots of RAM, qemu gets pretty fast. [15:13] If you don't, qemu isn't. [15:13] i had to take one ram module out because of brokenness recently ... so sad ;) [15:14] i think the idea is to do that in the cloud ;) [15:14] ojn: at what comparative rates? For me, qemu seems to perform at about 40% of native speed, which is faster than some of my ARM hardware :) [15:14] persia: I don't remember the details, let's see if I wrote them down [15:15] it feels faster for me atm [15:15] not lightning speed, but i hope that will cut it by half [15:16] Looks like the only numbers I actually wrote down was building bash native for x86 vs for arm inside a scratchbox2 environment. I think the qemu system emulation was too slow to even consider, so I didn't keep track of performance. [15:17] Yeah, compared to cross-compilation it's slow. [15:17] But cross-compilation has it's own collection of issues :) [15:17] oh, definitely. [15:17] distcc:ing over to a cross compiler is the best of both worlds, really. [15:18] Well, sometimes. I remember someone doing that for test building some stuff for jaunty, and they didn't get caught by a buildchain bug, which was confusing when doing the full native build later. [15:26] ojn: which script do you use? [15:27] zumbi_: for what? [15:27] distcc:ing over to a cross compiler [15:27] icecream provides that IIRC [15:27] zumbi_: no script needed. Stick a couple of links to distcc named gcc in a directory, make sure it's at the front of your path, then just build. Set DISTCC_HOSTS correspondingly. Caveat: I have yet to try it for a debian package rebuild. [15:28] I used it all the time for powerpc kernel builds back in "the days". [15:29] i need to test this. Do you know if it is compatible with buildbot? [15:29] Well, i guess it won't be hard to integrate [15:29] ^^^ see three lines up. :) [15:29] i.e. no idea [15:30] qemu system emulation compiling could be improved quite a bit by using virtio disk [15:39] suihkulokki: yes, and it is great :-) [15:41] suihkulokki: imagine adding distcc to that :) [15:41] * zumbi_ has to go.. [16:18] asac: have you done any benchmarking to see how much faster it is to build things under qemu-arm-static environment? Does it only benefit you for large packages? [16:18] or rather, things that take a long time to build [16:19] plars: atm, i dont know nothing - first time i use it ;). will get better stats when this is done [16:22] asac: what is your host system? how much ram, what cpu, etc? [16:22] only 2G ...one module is dead [16:23] CPU too old to remember ;) [16:23] so my time will be least possible win [16:24] && GYP_GENERATORS=make GYP_DEFINES="target_arch=arm disable_nacl=1 v8 [16:24] good [16:24] asac: heh, I had meant to try it out a while back but wasn't able to at the time. I have an old p4, 3GHz box that I revived recently, may install it on there to mess with [16:24] plars: its really easy. install qemu-arm-static package ... [16:24] run build-arm-chroot ... like debootstrap [16:24] and then you are done [16:24] you can chroot into it and just use it [16:24] asac: yeah, I have a link to the wiki page that ogra did for it, looks simple. I just didn't have a machine to do it on a while back [16:24] kk [16:29] fta: not sure whats going on, but atm its stilil python dominting my CPU: 14014 asac 20 0 201m 82m 2816 R 100 4.1 3:21.12 python [16:29] ah ... all fine [16:29] now make is there ;) [16:29] asac, did you take the branch? rev389? [16:30] i picked latest gyp from daily [16:30] ppa [16:30] for chromium [16:30] ? [16:30] latest daily version as well from latest bzr [16:30] yes [16:30] its [16:31] ok [16:31] 17:05 < asac> starting over [16:31] 17:06 < asac> 389. [16:31] so yeah [16:31] great [16:33] 389 packaging revisions \o/ but still nothing in the archives /o\ [16:33] might be allusion [16:33] illusion [16:33] but it seems to be indeed faster compiling stuff [16:34] is there a feature that would allow to dump the full compile line just for errors? [16:34] rather than making everything verbose? [16:37] grep [16:37] *g* [16:38] asac: got tired building on native? :D [16:39] asac: getting a lot of qemu: Unsupported syscall: 335 from things when I try to apt-get install packages [16:40] plars: i get that too ... but seems not to hurt [16:41] asac, nope :( [16:41] asac: did you hit any snags setting up the qemu-static environment? [16:42] ojn: no. just install qemu-arm-static ... then run build-arm-chroot [16:42] ojn: I just set one up a bit ago for lucid, very simple [16:42] and then oyou have a working chroot [16:42] that is arm [16:42] cool [16:42] ojn: https://wiki.ubuntu.com/ARM/BuildEABIChroot [16:42] Ah, nice [16:42] plars: thanks [16:42] ojn: getting a nice stream of spam regarding the unsupported syscalls [16:44] plars: are you on i386 or x86_64? [16:44] ojn: i386 [16:44] hm, there is a 335 syscall on i386 [16:45] wow, that's enough spam to cause my gnome-terminal session to eat ~33% cpu! [16:45] wait, is it from qemu or in dmesg on the host? [16:46] ojn: qemu [16:46] its from qemu [16:46] drops that syscall i guess [16:46] not sure what 335 is [16:46] I don't see a 335 syscall in current mainline sources for arm. I wonder what's using it. [16:47] oh, nevermind. bad grep. [16:47] #define __NR_pselect6 (__NR_SYSCALL_BASE+335) [16:48] needs to be added to qemu [16:48] ah yes [16:48] I think pselect is missing on arm actually [16:48] or it used to be at least [16:48] well, it seems to be plumbed up now [16:49] ojn: not in our kernels yet [16:49] CALL(sys_ni_syscall) /* eventually pselect6 */ [16:49] plars: but in glibc, it seems. :) [16:50] apt-get failed [16:51] looks like postfix and bsd-mailx failed to finish installing, don't care thouth [16:54] plars: what did you install? [16:54] i only bootstrapped -> worked [16:54] asac: pbuilder [16:54] bunch of deps [16:54] then i installed builddeps [16:54] and stuff [16:54] hmm [16:54] pbuilder inside of chroot? ;) [16:54] i would rather make pbuilder use that [16:54] asac: heh, thought it might be interesting to try :) [16:54] try the other approach [16:55] tweak pbuilder config to use build-emu-static for constructing the chroot [16:55] (if thats possible) [16:55] asac: ah, that would probably be more useful, yet [16:55] i dont use pbuilder, but feels doable [16:58] asac, what the plan to test the perf of chromium & ff? which tools/methodology? [16:59] fta: those tasks ar assigned to dave [16:59] they seem to have something internally for that [17:02] internally? [18:03] fta: dave is from arm [18:04] so: out/Release/obj.target/webcore/third_party/WebKit/WebCore/dom/Document.o [18:04] feels slower than native ;) [18:12] asac: I have a test build running on both, building something sizable enough, but not too insane [18:13] asac: I have them both building bash, I started on the babbage much earlier and it already finished: real 30m21.368s [18:13] asac: I wouldn't be too surprised if it was a bit slower, but might be interesting to see if there is good-enough benefit from running them in parallel with distcc [18:14] asac: also, this is a pretty slow machine - yes, much faster than any arm proc I have sitting on my desk, but still [18:14] plars: hah, i just started the same exact test ;) [18:15] ojn: no kidding, with bash even? [18:15] yep [18:15] ha [18:15] you'd think we used to work together or something :) [18:15] :) [18:16] ojn: will be interesting to see how your numbers compare to mine, I suspect my time from the babbage is not great (running off a 16G usb stick at the moment) [18:16] grmbl, -j doesn't seem to work with dpkg-buildpackage though. [18:16] I had 34m real time here, running off of internal flash on the pegatron [18:16] ojn: I was just about to ask asac if he knew how to make debuild call make with -j [18:16] actually, 34m54s. [18:16] ojn: DEB_BUILD_OPTIONS=parallel=${n} [18:16] ojn: ok, so not too much different from mine anyway [18:17] persia: thanks! [18:17] (you need a debian/rules that supports that) [18:17] dpkg-buildpackage has a -j switch, but it'll fail due to some of the jobs trying to get into the directory before it's created. :) [18:17] It's not well tested :) [18:17] I'll do an apples-to-apples and do single-thread first. [18:17] * ojn watches 3.5 cores being idle on his $600 nehalem box. :) [18:19] GrueMaster: I had a try at an inital sort for mobile-lucid-arm-suspend-resume-testplan : http://paste.ubuntu.com/343650/ What do you think? [18:21] Looks reasonable. I don't know enough about eSATA, but it might be more of a middle option. Isin't it like an external USB drive (separate power from the system, but able to take sleep/wake commands)? [18:21] No, it draws power from the system. [18:22] But it's not nearly as common as USB. [18:22] I suppose there are also eSATA enclosures with separate power, but they aren't so interesting :) [18:22] My basic thought was as follows: [18:22] Are you sure? Every motherboard I have in recent years has come with a chassis eSATA connector, which is just a sata extension cable. [18:22] Base is the stuff that we can't function without [18:23] right. [18:23] Standard is the stuff that we expect to find in most hardware [18:23] and Extra is the rest of the stuff. [18:23] I expect that we'll find Extra stuff in most hardware, but I don't expect to find all of it in anything. [18:23] eSATA should be middle then. Most nettop systems come with eSATA now. [18:23] Whereas I could easily imagine something with all of Standard. [18:24] OK. Handhelds don't. [18:24] (too much power draw) [18:24] True. Nor do laptops or netbooks. [18:24] Well, some laptops do [18:24] But those are the big ones :) [18:25] You mean the next gen luggables? [18:25] :P [18:26] Well, I've seen people carrying eSATA enabled laptops to conferences, but yeah :) [18:26] I have a friend with one of those beasts. 17" wide screen, dual core nvidia graphics, Core2Quad cpu 4G mem, 1T drive, blue-ray, etc. [18:26] Yeah. [18:26] So Extra? [18:26] plars: any results yet? [18:26] (comparison) [18:27] GrueMaster: So anyway, having sorted the list, I have no idea what needs to happen to solve the "Decide and document testcase priorities; sort into three classes; base, standard, extra: TODO" workitem. [18:27] Does it belong on some specific wiki page? Is more organisation needed? [18:28] * persia suspects "Create suspend resume testplan page that will document how to run suspend resume test" should have been done first, but was at a bit of a loss [18:28] That I don't know. I guess we sort the whiteboard with what you have and document each test case on wiki. [18:28] I can sort the whilteboard. [18:29] Do you know the Testing wiki hierarchy? [18:29] I just don't know where it belongs [18:29] (other than somewhere under https://wiki.ubuntu.com/Testing ) [18:29] Not really. I can figure it out though. [18:30] Cool. I'll sort the blueprint. Let me know if you need me to populate a wiki page once you have a URL [18:30] Wasn't someone generating a wiki map? [18:30] heh. But I'm only doing that for some namespaces, and /Testing/ isn't one of them [18:33] asac: not more than what I gave you earlier [18:33] so clearly, going to be MUCH slower on my system to use the qemu chroot [18:36] persia, GrueMaster: it was my understanding that they were trying to transition all testcases from w.u.c/Testing to testcases.qa.ubuntu.com [18:37] plars: I may need your help then to publish there. I can do the writeup, but I may need you to post it if I don't have the correct privileges. [18:38] GrueMaster: I don't think I had to get any special privileges for posting on that wiki, you just need to be logged in [18:38] ok. I'll check when I'm ready to post. [18:39] testcases.qa.ubuntu.com might require an ubuntu-qa login though (the separate, parallel, single-sign-on exists for historical reasons) [18:41] ah yes, I vaguely remember signing up for that ID [18:42] in any case GrueMaster, if you have problems posting to it, let us know, or ask about it somewhere like #ubuntu-testing. You need to have access to that wiki if you don't [18:42] ok, will do. [18:42] I suspect you can just register for the account though, and it will let you post [18:43] SHould do. [18:46] mobile-lucid-arm-suspend-resume-testplan whiteboard updated with sorting. [18:57] ah, my qemu-arm-static build of bash is nearing the end finally [19:00] plars: Mine took _exactly_ as long on qemu as on native hardware without a -j option [19:00] ojn: that's encouraging [19:00] mine will be longer by a fair margin for certain, but on pretty slow hardware [19:01] ojn: did you kick it off with distcc also? [19:01] no, not at this time [19:02] I might give that a go next; I'm waiting on fedex though so once I get that I will be 100% busy with new board work. :) [19:02] q. i would like to have an hw running arm and ubuntu. ideally a cortex a8 or a9. where i can find such hw ? [19:05] jetienne: I don't think you can buy a9 hardware anywhere today. Buying a freescale babbage eval board is the only supported platform to date, but some are using ubuntu on a beagleboard (much much cheaper) [19:05] someone from canonical should correct me if I'm wrong though. :) [19:05] There's also some retail hardware that works, but again, it runs into the kernel issue. [19:06] the ubuntu arm images will not support beagleboard, so you'd need your own kernel, but could run ubuntu packages on top of that. Certainly I've heard of people doing it [19:06] i look for a reference, something i can buy. this is mostly to test the perf of arm on linux [19:06] plars: ok so no beagleboard. i need it to be easy to install [19:07] also, if you really just want low cost, the $99 sheevaplugs run something based on Jaunty iirc [19:07] cost is no issue [19:07] jetienne: What sort of platform do you want? [19:07] but already installed is ultra good [19:07] * persia is happy with the Sharp Netwalker, but it does need a custom kernel to run Ubuntu other than 9.04 [19:07] Genesi Efika MX comes preinstalled with jaunty, but it's not officially supported. [19:07] persia: im part of a startup doing softward and hardward. the hw will be outsourced. currently im just evaluating the need [19:08] dev board from freescale will run jaunty, or also let you run lucid images that are already available [19:08] jetienne: OK. Do you want a dev board or a handheld? [19:08] jetienne: sounds like you should talk to the SoC vendors about getting some eval boards. Marvell Dove and Freescale Bababge officially support ubuntu, none of the others do. [19:08] (but with your own kernel most of them can run it) [19:08] dev board is ok, handheld too [19:09] ojn: SoC = ? [19:09] For a dev board, FSL sells babbage, which has kernel support in Ubuntu. [19:09] jetienne: Oh boy. SoC == system on a chip [19:09] how much is it ? [19:09] For a handheld, Sharp sells the Netwalker, which is the same CPU, but needs a different kernel because of how ARM kernels work today. [19:09] I don't know of anything else available retail (but someone could correct me) [19:10] persia: Ha, OMAP kernels don't have that issue. :) [19:10] they can be multi-platform. [19:10] ojn: Yes they do, just less so. Try running the same kernel on OMAP1 and OMAP3 [19:10] persia: how much did you pay for the board [19:10] persia: sure, but within a family they work. Freescale doesn't even support it that far, do they? [19:11] jetienne: I paid 44800 yen for a Netwalker. I don't have a babbage: you'd have to ask someone else [19:11] * persia looks for a website [19:11] There is also the Beagle Board (http://beagleboard.org). While not directly supported by Ubuntu (kernel), there is a help page for getting Ubuntu installed. [19:12] It uses the OMAP4 chip (I believe). Still ARMv7. [19:13] persia: so around 400euro ? wow ultra cheap [19:13] jetienne: If you get conics to import it, they'll charge a bit of a premium, but yeah. [19:16] jetienne: Sorry. I remember representatives from freescale saying the Babbage was available retail at UDS, but I can't figure out how to order it from their site. Maybe you'll have better luck. [19:16] hahah [19:16] real 107m58.740s [19:16] ojn, asac ^ [19:16] GrueMaster: Beagleboard has OMAP 3530, Cortex A8 [19:16] GrueMaster: http://beagleboard.org/hardware [19:16] plars: Wow. I guess my machine is quite a bit faster [19:17] :) [19:17] right. [19:17] ojn: yeah, I told you this was an old box [19:17] persia: ok thanks [19:17] :) [19:18] q. i read a lot of doc on ubuntu-arm, they talks about "lucid"... what is this ? [19:19] :D [19:19] https://wiki.ubuntu.com/ is a good place to start for that sort of question. [19:19] It's the code name for what will become the Ubuntu 10.04 release in April. [19:20] https://wiki.ubuntu.com/LucidLynx has limited information along those lines [19:20]