[07:58] <persia> 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] <lool> persia: It might be that the dove kernels on the buildds have to be updated
[08:47] <lool> persia: I think there was an errata for thumb 2 traps for dove which dave mentionned ina bug
[08:47] <lool> Actually Eric did
[08:48] <lool> bug #494831
[08:48] <ubot4> Launchpad bug 494831 in linux-mvl-dove "Alignment trap/Unhandled fault errors on boot" [Critical,In progress] https://launchpad.net/bugs/494831
[08:48] <persia> I definitely heard about that.  Do you think that would affect makesquashfs?
[08:48] <lool> persia: If we rebuilt it with thumb2 it might
[08:48] <lool> But I thought it had been rebuilt with -marm to workaround that
[08:49] <persia> That was my memory as well, and we ended up having working livefs builds for imx51.
[08:49] <persia> Do you have hardware that could run a mksquashfs test to replicate the bug?
[09:01] <lool> I do but it's not online
[09:02] <persia> OK.  Maybe someone else will volunteer then.
[09:02] <lool> Checking the build log, I don't see the mksquashfs version
[09:02] <persia> 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] <lool> I checked livecd-rootfs, and mksquashfs is run in the chroot
[09:04] <lool> You could check on the porter box, but that's imx51
[09:05] <lool> persia: BTW you might want to allow both for aufs and unionfs in your script
[09:06] <lool> (Ideally mount --union and fuse union as well; I think that's all casper supports)
[09:06] <lool> I have my own script which OOPSes the kernel  :-(
[09:06] <persia> heh.  Guess we don't want to merge that.
[09:07] <persia> 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] <persia> 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] <lool> persia: /proc/filesystems only list the modprobe-d or builtin ones though; aufs and unionfs were often built as modules
[09:11] <persia> 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] <lool> grmpf
[09:19] <persia> 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] <ogra_> persia, did anyone ask lamont to update the squashfs-tools version on clementine ?
[09:28] <persia> ogra_: No idea.  Is that something that would be different between imx51 and dove?
[09:28] <ogra_> no, clementine is the livefs builder for both subarches
[09:30] <persia> Hrm.
[09:30]  * persia looks at logs again
[09:30] <ogra_> the crontab entry is a bit silly
[09:31] <ogra_> seems imx51 is never tried if the other arches have a non zero exit code
[09:33] <persia> Ah, that explains why I didn't get any mail about imx51
[09:33] <ogra_> the crontab entry connects the two builds with &&
[09:33] <ogra_> should be changed to ;
[09:34] <persia> Who can change that?
[09:37] <ogra_> me if i'm back from vacation, StevenK, lool, cjwatson etc etc
[09:37] <ogra_> 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] <persia> Dunno.
[09:40] <persia> So it's ubuntu-cdimage?
[09:40] <persia> I'll bug someone from the team to look at it soon then.
[09:45] <ogra_> its not that important
[09:46] <persia> Well, except that I promised to watch the daily builds this week.
[09:46] <ogra_> the illegal instruction will be identical no matter for which target you build
[09:46] <persia> And if they aren't working, that needs to be investigated.
[09:46] <ogra_> so squashfs-tools needs to be fixed first ... else you just waste buildd time
[09:47] <ogra_> if -marm doesnt work, i know that -O0 is supposed to
[09:48] <persia> And it's the same group that can check versions on the builder, or do I need a buildd OSA?
[09:50] <ogra_> you need lamont
[09:50] <persia> Heh.  OK.
[09:50] <ogra_> he pinned the karmic version until last sunday
[09:50] <persia> That's straightforward enough.
[09:50] <ogra_> and had a cronjob to release the pinning
[09:51] <ogra_> but probably it just unpinned and didnt upgrade to the version built with -marm
[09:51] <persia> Right.  That needs to be checked, and maybe force-upgraded.
[09:51] <persia> If it *did* upgrade, it needs to be recompiled with -O0
[09:51] <ogra_> so first check if the -marm built version is there ... if so, rebuild squashfs-tools with -O0
[09:52] <ogra_> and if that doesnt work, we're out of ideas and probably need to pin the karmic version for longer
[09:52] <persia> Cool.  That's a set of instructions that can be executed :)
[09:52] <persia> Well, except we'd need to do a manual downgrade, etc.
[09:52] <ogra_> until someone can investigate deeper
[09:52] <persia> But yeah.
[09:55] <lool> I've updated the crontab
[09:56] <persia> lool: Cool.  Now I'll get twice as many emails :)
[09:56] <ogra_> http://launchpadlibrarian.net/36706216/buildlog_ubuntu-lucid-armel.squashfs_1:4.0-3ubuntu1_FULLYBUILT.txt.gz seems to have -marm
[09:56] <ogra_> but -O2
[09:56] <persia> ogra_: Yep, but it's a question of which is installed.
[09:56] <ogra_> right, i just wanted to make sure it built
[09:56] <ogra_> being on vacation i dont check such stuff ;)
[09:57] <persia> heh :)
[10:12] <lool> Note that it said illegal instructions, not sigbus
[10:12] <lool> (sigbus would have said: bus error  ...)
[10:14] <persia> Should a -mthumb2 vs. -marm issue report a bus error?  I thought it was just illegal instructions.
[10:23] <lool> persia: My understanding is that the boards support thumb2 but mishandle unaligned accesses in thumb2
[10:23] <lool> (They should handle these, but not without a fixed kernel)
[10:24] <persia> That was my understanding as well
[10:25] <persia> But the side discussion about squashfs-tools might provide a workaround for the short term (or did I misunderstand? )
[10:25] <ogra> we're supposed to get a kernel with mtd support at some point so we can replace the existing broken one
[10:25] <ogra> or a mtd module for the existing one
[10:25] <persia> MTD?  Aren't those the on-chip flash devices?
[10:25] <ogra> right
[10:25] <ogra> thats where the kernel lives in these boards
[10:25] <persia> That's surely a different issue.
[10:25] <ogra> and we have no access to the devices
[10:25] <persia> Oh, you mean we don't have access to update the kernels?
[10:25] <persia> Ah.
[10:25] <ogra> so we cant reflash with a new kernel atm
[10:26] <ogra> a driver exists but not for this specifc kernel binary
[10:26] <persia> RIght.
[10:27] <persia> I understand.
[10:27] <persia> So the issue exists *only* on the buildds?  Should replication testing not happen on other hardware?
[10:27] <persia> I'd think it'd be interesting to fix it elsewhere, and then look at the buildds, but maybe I am behind.
[10:27] <ogra> it doesnt occur elsewhere
[10:27] <ogra> and nobody of us has the buildd HW
[10:28] <persia> Ah.
[10:28] <ogra> well
[10:28] <ogra> davidm has
[10:28] <persia> If that's already been tested, I won't ask for testing :)
[10:28] <ogra> and i replicated the original issue on his board remotely
[10:28] <ogra> but he shut off access to it afterwards
[10:28] <persia> This is the action item from the 20091208 meeting?
[10:28] <ogra> yes
[10:29] <persia> OK.  I understand then.
[10:29] <ogra> dmart has a board as well, but i'm not sure it has the exact same kernel
[10:29] <persia> Well, neither of them seem to be in-channel right now.
[10:29] <ogra> he brought up the two fixes (-marm and -O0)
[10:29] <ogra> and davidm wont be until new year
[10:30] <persia> So is the squashfs-tools a useful workaround?
[10:30] <ogra> ?
[10:30] <persia> Won't we still encounter other issues running lucid code on those?
[10:30] <ogra> we shouldnt according to dmart
[10:30] <ogra> either of the above compile options should fix it
[10:30] <persia> I don't quite understand why *only* mksquashfs is affected
[10:31] <ogra> kernel module vs userspace
[10:31] <persia> But I'll try to sort that, and we'll see what breaks next.
[10:31] <persia> Oh, it's an ABI thing between the kernel squashfs interface and mksquashfs?
[10:31] <persia> So it wouldn't affect other stuff?
[10:32] <ogra> well, it might if you have userspace things using kernel ABI ...
[10:32] <persia> Would linux-libc-dev be affected?
[10:33] <persia> That's the only part of the toolchain that I think regularly uses that sort of stuff.
[10:33] <ogra> hmm, i doubt it, we would have seen more fallout if it had
[10:34] <persia> OK.  Then we have a workaround.
[10:34] <persia> Be a few hours before we have access to look though :(
[10:34] <ogra> yeah
[13:23] <armin76> rabeeh: do i get a present? :)
[13:24] <persia> Does anyone happen to know how Soyuz handles two source packages in Ubuntu that build a binary package with the same name?
[13:26] <persia> -ECHANNEL
[14:48] <asac> ok chromium building now in qemu-arm-static chroot ;)
[15:04] <ojn> asac: how many hours? :)
[15:09] <asac> not sure ... i hope less than native ;)
[15:10] <asac> but maybe i am too optimistic ;)
[15:10] <asac> on native it takes 19h or so with more or less fast usb drive (with tests disabled)
[15:10] <asac> on babbage 3
[15:11] <asac> or 16 ... not so sure atm ;)
[15:11] <persia> Surely a big chunk of that is swapping, no?
[15:11] <asac> well... whenever i looked most of CPU was really on action ;)
[15:11] <asac> but swapping is probably a big thing for the linking
[15:12] <ojn> would be interesting to see how long it'd take with distcc:ing over to a non-emulated cross compiler too. :)
[15:12] <persia> 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] <asac> i hope that qemu is in the middle of native cross and all native
[15:13] <persia> Depends on the RAM of the host, really.
[15:13] <ojn> qemu system emulation was quite a bit slower than native for me. Hopefully static is quicker.
[15:13] <persia> If you have lots of RAM, qemu gets pretty fast.
[15:13] <persia> If you don't, qemu isn't.
[15:13] <asac> i had to take one ram module out because of brokenness recently ... so sad ;)
[15:14] <asac> i think the idea is to do that in the cloud ;)
[15:14] <persia> 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] <ojn> persia: I don't remember the details, let's see if I wrote them down
[15:15] <asac> it feels faster for me atm
[15:15] <asac> not lightning speed, but i hope that will cut it by half
[15:16] <ojn> 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] <persia> Yeah, compared to cross-compilation it's slow.
[15:17] <persia> But cross-compilation has it's own collection of issues :)
[15:17] <ojn> oh, definitely.
[15:17] <ojn> distcc:ing over to a cross compiler is the best of both worlds, really.
[15:18] <persia> 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] <zumbi_> ojn: which script do you use?
[15:27] <ojn> zumbi_: for what?
[15:27] <zumbi_> distcc:ing over to a cross compiler
[15:27] <lool> icecream provides that IIRC
[15:27] <ojn> 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] <ojn> I used it all the time for powerpc kernel builds back in "the days".
[15:29] <zumbi_> i need to test this. Do you know if it is compatible with buildbot?
[15:29] <zumbi_> Well, i guess it won't be hard to integrate
[15:29] <ojn> ^^^ see three lines up. :)
[15:29] <ojn> i.e. no idea
[15:30] <suihkulokki> qemu system emulation compiling could be improved quite a bit by using virtio disk
[15:39] <zumbi_> suihkulokki: yes, and it is great :-)
[15:41] <zumbi_> suihkulokki: imagine adding distcc to that :)
[15:41]  * zumbi_ has to go..
[16:18] <plars> 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] <plars> or rather, things that take a long time to build
[16:19] <asac> plars: atm, i dont know nothing - first time i use it ;). will get better stats when this is done
[16:22] <plars> asac: what is your host system? how much ram, what cpu, etc?
[16:22] <asac> only 2G ...one module is dead
[16:23] <asac> CPU too old to remember ;)
[16:23] <asac> so my time will be least possible win
[16:24] <asac> && GYP_GENERATORS=make GYP_DEFINES="target_arch=arm disable_nacl=1 v8
[16:24] <asac> good
[16:24] <plars> 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] <asac> plars: its really easy. install qemu-arm-static package ...
[16:24] <asac> run build-arm-chroot ... like debootstrap
[16:24] <asac> and then you are done
[16:24] <asac> you can chroot into it and just use it
[16:24] <plars> 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] <asac> kk
[16:29] <asac> 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] <asac> ah ... all fine
[16:29] <asac> now make is there ;)
[16:29] <fta> asac, did you take the branch? rev389?
[16:30] <asac> i picked latest gyp from daily
[16:30] <asac> ppa
[16:30] <fta> for chromium
[16:30] <fta> ?
[16:30] <asac> latest daily version as well from latest bzr
[16:30] <asac> yes
[16:30] <asac> its
[16:31] <fta> ok
[16:31] <asac> 17:05 < asac> starting over
[16:31] <asac> 17:06 < asac> 389.
[16:31] <asac> so yeah
[16:31] <fta> great
[16:33] <fta> 389 packaging revisions \o/ but still nothing in the archives /o\
[16:33] <asac> might be allusion
[16:33] <asac> illusion
[16:33] <asac> but it seems to be indeed faster compiling stuff
[16:34] <asac> is there a feature that would allow to dump the full compile line just for errors?
[16:34] <asac> rather than making everything verbose?
[16:37] <armin76> grep
[16:37] <armin76> *g*
[16:38] <armin76> asac: got tired building on native? :D
[16:39] <plars> asac: getting a lot of qemu: Unsupported syscall: 335 from things when I try to apt-get install packages
[16:40] <asac> plars: i get that too ... but seems not to hurt
[16:41] <fta> asac, nope :(
[16:41] <ojn> asac: did you hit any snags setting up the qemu-static environment?
[16:42] <asac> ojn: no. just install qemu-arm-static ... then run build-arm-chroot
[16:42] <plars> ojn: I just set one up a bit ago for lucid, very simple
[16:42] <asac> and then oyou have a working chroot
[16:42] <asac> that is arm
[16:42] <ojn> cool
[16:42] <plars> ojn: https://wiki.ubuntu.com/ARM/BuildEABIChroot
[16:42] <ojn> Ah, nice
[16:42] <ojn> plars: thanks
[16:42] <plars> ojn: getting a nice stream of spam regarding the unsupported syscalls
[16:44] <ojn> plars: are you on i386 or x86_64?
[16:44] <plars> ojn: i386
[16:44] <ojn> hm, there is a 335 syscall on i386
[16:45] <plars> wow, that's enough spam to cause my gnome-terminal session to eat ~33% cpu!
[16:45] <ojn> wait, is it from qemu or in dmesg on the host?
[16:46] <plars> ojn: qemu
[16:46] <asac> its from qemu
[16:46] <asac> drops that syscall i guess
[16:46] <asac> not sure what 335 is
[16:46] <ojn> I don't see a 335 syscall in current mainline sources for arm. I wonder what's using it.
[16:47] <ojn> oh, nevermind. bad grep.
[16:47] <ojn> #define __NR_pselect6                   (__NR_SYSCALL_BASE+335)
[16:48] <ojn> needs to be added to qemu
[16:48] <plars> ah yes
[16:48] <plars> I think pselect is missing on arm actually
[16:48] <plars> or it used to be at least
[16:48] <ojn> well, it seems to be plumbed up now
[16:49] <plars> ojn: not in our kernels yet
[16:49] <plars> CALL(sys_ni_syscall)            /* eventually pselect6 */
[16:49] <ojn> plars: but in glibc, it seems. :)
[16:50] <plars> apt-get failed
[16:51] <plars> looks like postfix and bsd-mailx failed to finish installing, don't care thouth
[16:54] <asac> plars: what did you install?
[16:54] <asac> i only bootstrapped -> worked
[16:54] <plars> asac: pbuilder
[16:54] <plars> bunch of deps
[16:54] <asac> then i installed builddeps
[16:54] <asac> and stuff
[16:54] <asac> hmm
[16:54] <asac> pbuilder inside of chroot? ;)
[16:54] <asac> i would rather make pbuilder use that
[16:54] <plars> asac: heh, thought it might be interesting to try :)
[16:54] <asac> try the other approach
[16:55] <asac> tweak pbuilder config to use build-emu-static for constructing the chroot
[16:55] <asac> (if thats possible)
[16:55] <plars> asac: ah, that would probably be more useful, yet
[16:55] <asac> i dont use pbuilder, but feels doable
[16:58] <fta> asac, what the plan to test the perf of chromium & ff? which tools/methodology?
[16:59] <asac> fta: those tasks ar assigned to dave
[16:59] <asac> they seem to have something internally for that
[17:02] <fta> internally?
[18:03] <asac> fta: dave is from arm
[18:04] <asac> so: out/Release/obj.target/webcore/third_party/WebKit/WebCore/dom/Document.o
[18:04] <asac> feels slower than native ;)
[18:12] <plars> asac: I have a test build running on both, building something sizable enough, but not too insane
[18:13] <plars> asac: I have them both building bash, I started on the babbage much earlier and it already finished: real	30m21.368s
[18:13] <plars> 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] <plars> 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] <ojn> plars: hah, i just started the same exact test ;)
[18:15] <plars> ojn: no kidding, with bash even?
[18:15] <ojn> yep
[18:15] <plars> ha
[18:15] <plars> you'd think we used to work together or something :)
[18:15] <ojn> :)
[18:16] <plars> 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] <ojn> grmbl, -j<largenumber> doesn't seem to work with dpkg-buildpackage though.
[18:16] <ojn> I had 34m real time here, running off of internal flash on the pegatron
[18:16] <plars> ojn: I was just about to ask asac if he knew how to make debuild call make with -j
[18:16] <ojn> actually, 34m54s.
[18:16] <persia> ojn: DEB_BUILD_OPTIONS=parallel=${n}
[18:16] <plars> ojn: ok, so not too much different from mine anyway
[18:17] <plars> persia: thanks!
[18:17] <persia> (you need a debian/rules that supports that)
[18:17] <ojn> 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] <persia> It's not well tested :)
[18:17] <ojn> 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] <persia> 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] <GrueMaster> 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] <persia> No, it draws power from the system.
[18:22] <persia> But it's not nearly as common as USB.
[18:22] <persia> I suppose there are also eSATA enclosures with separate power, but they aren't so interesting :)
[18:22] <persia> My basic thought was as follows:
[18:22] <GrueMaster> 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] <persia> Base is the stuff that we can't function without
[18:23] <GrueMaster> right.
[18:23] <persia> Standard is the stuff that we expect to find in most hardware
[18:23] <persia> and Extra is the rest of the stuff.
[18:23] <persia> 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] <GrueMaster> eSATA should be middle then.  Most nettop systems come with eSATA now.
[18:23] <persia> Whereas I could easily imagine something with all of Standard.
[18:24] <persia> OK.  Handhelds don't.
[18:24] <persia> (too much power draw)
[18:24] <GrueMaster> True.  Nor do laptops or netbooks.
[18:24] <persia> Well, some laptops do
[18:24] <persia> But those are the big ones :)
[18:25] <GrueMaster> You mean the next gen luggables?
[18:25] <GrueMaster> :P
[18:26] <persia> Well, I've seen people carrying eSATA enabled laptops to conferences, but yeah :)
[18:26] <GrueMaster> 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] <persia> Yeah.
[18:26] <persia> So Extra?
[18:26] <asac> plars: any results yet?
[18:26] <asac> (comparison)
[18:27] <persia> 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] <persia> 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] <GrueMaster> That I don't know.  I guess we sort the whiteboard with what you have and document each test case on wiki.
[18:28] <persia> I can sort the whilteboard.
[18:29] <persia> Do you know the Testing wiki hierarchy?
[18:29] <persia> I just don't know where it belongs
[18:29] <persia> (other than somewhere under https://wiki.ubuntu.com/Testing )
[18:29] <GrueMaster> Not really.  I can figure it out though.
[18:30] <persia> 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] <GrueMaster> Wasn't someone generating a wiki map?
[18:30] <persia> heh.  But I'm only doing that for some namespaces, and /Testing/ isn't one of them
[18:33] <plars> asac: not more than what I gave you earlier
[18:33] <plars> so clearly, going to be MUCH slower on my system to use the qemu chroot
[18:36] <plars> 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] <GrueMaster> 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] <plars> 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] <GrueMaster> ok.  I'll check when I'm ready to post.
[18:39] <persia> testcases.qa.ubuntu.com might require an ubuntu-qa login though (the separate, parallel, single-sign-on exists for historical reasons)
[18:41] <plars> ah yes, I vaguely remember signing up for that ID
[18:42] <plars> 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] <GrueMaster> ok, will do.
[18:42] <plars> I suspect you can just register for the account though, and it will let you post
[18:43] <persia> SHould do.
[18:46] <persia> mobile-lucid-arm-suspend-resume-testplan whiteboard updated with sorting.
[18:57] <plars> ah, my qemu-arm-static build of bash is nearing the end finally
[19:00] <ojn> plars: Mine took _exactly_ as long on qemu as on native hardware without a -j option
[19:00] <plars> ojn: that's encouraging
[19:00] <plars> mine will be longer by a fair margin for certain, but on pretty slow hardware
[19:01] <plars> ojn: did you kick it off with distcc also?
[19:01] <ojn> no, not at this time
[19:02] <ojn> 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] <jetienne> 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] <ojn> 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] <ojn> someone from canonical should correct me if I'm wrong though. :)
[19:05] <persia> There's also some retail hardware that works, but again, it runs into the kernel issue.
[19:06] <plars> 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] <jetienne> i look for a reference, something i can buy. this is mostly to test the perf of arm on linux
[19:06] <jetienne> plars: ok so no beagleboard. i need it to be easy to install
[19:07] <plars> also, if you really just want low cost, the $99 sheevaplugs run something based on Jaunty iirc
[19:07] <jetienne> cost is no issue
[19:07] <persia> jetienne: What sort of platform do you want?
[19:07] <jetienne> 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] <ojn> Genesi Efika MX comes preinstalled with jaunty, but it's not officially supported.
[19:07] <jetienne> persia: im part of a startup doing softward and hardward. the hw will be outsourced. currently im just evaluating the need
[19:08] <plars> dev board from freescale will run jaunty, or also let you run lucid images that are already available
[19:08] <persia> jetienne: OK.  Do you want a dev board or a handheld?
[19:08] <ojn> 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] <ojn> (but with your own kernel most of them can run it)
[19:08] <jetienne> dev board is ok, handheld too
[19:09] <jetienne> ojn: SoC = ?
[19:09] <persia> For a dev board, FSL sells babbage, which has kernel support in Ubuntu.
[19:09] <ojn> jetienne: Oh boy. SoC == system on a chip
[19:09] <jetienne> how much is it ?
[19:09] <persia> 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] <persia> I don't know of anything else available retail (but someone could correct me)
[19:10] <ojn> persia: Ha, OMAP kernels don't have that issue. :)
[19:10] <ojn> they can be multi-platform.
[19:10] <persia> ojn: Yes they do, just less so.  Try running the same kernel on OMAP1 and OMAP3
[19:10] <jetienne> persia: how much did you pay for the board
[19:10] <ojn> persia: sure, but within a family they work. Freescale doesn't even support it that far, do they?
[19:11] <persia> 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] <GrueMaster> 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] <GrueMaster> It uses the OMAP4 chip (I believe).  Still ARMv7.
[19:13] <jetienne> persia: so around 400euro ? wow ultra cheap
[19:13] <persia> jetienne: If you get conics to import it, they'll charge a bit of a premium, but yeah.
[19:16] <persia> 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] <plars> hahah
[19:16] <plars> real	107m58.740s
[19:16] <plars> ojn, asac ^
[19:16] <ojn> GrueMaster: Beagleboard has OMAP 3530, Cortex A8
[19:16] <jetienne> GrueMaster: http://beagleboard.org/hardware
[19:16] <ojn> plars: Wow. I guess my machine is quite a bit faster
[19:17] <ojn> :)
[19:17] <GrueMaster> right.
[19:17] <plars> ojn: yeah, I told you this was an old box
[19:17] <jetienne> persia: ok thanks
[19:17] <ojn> :)
[19:18] <jetienne> q. i read a lot of doc on ubuntu-arm, they talks about "lucid"... what is this ?
[19:19] <armin76> :D
[19:19] <persia> https://wiki.ubuntu.com/ is a good place to start for that sort of question.
[19:19] <persia> It's the code name for what will become the Ubuntu 10.04 release in April.
[19:20] <persia> https://wiki.ubuntu.com/LucidLynx has limited information along those lines
[19:20] <jetienne> thanks
[19:22] <jetienne> all those boxes got very limited ram (i have seen 128mbyte, or 512mbyte), what is the motivation behind that ?
[19:22] <jetienne> to save battery life ? or more to save hw cost
[19:24] <ojn> jetienne: most of the embeddded ARM chips use package-on-package memory (LPDDR), and while there might be options to get 1GB that way, it's usually very expensive.
[19:24] <ojn> Some chips can use regular DDR2 memory, and then you can go to larger sizes. I think babbage can, Marvell Dove should be able to as well.
[19:26] <jetienne> ojn: thanks
[19:27] <jetienne> i think for my testing, i could use a modern phone, or archos hw... can they run ubuntu ?
[19:27] <ojn> jetienne: if you have hardware platform selection to do, I would recommend finding someone to assist you with it that knows about these things already. There are many details you want to consider when selecting a hardware base for your product.
[19:28] <persia> Definitely!
[19:28] <jetienne> ojn: we will outsource it to a company we know in cambridge
[19:28] <persia> Grabbing some random thing to examine the software stack is a completely different activity than selecting the basis of a product.
[19:29] <jetienne> ojn: currently im just doing some prospective research
[19:29] <ojn> jetienne: sounds like you should have them assist you in the selection too, if you don't have any of that knowledge in-house.
[19:29] <ojn> jetienne: ok. :)
[19:29] <jetienne> for example i need to know if it is feasible to do video transcoding on a modern arm, or do i need a intel cpu, or a special chip to encode mp4
[19:30] <ojn> on arm you most definitely need to use the hardware offload assist to do it in a reasonable speed
[19:30] <ojn> ubuntu doesn't provide that on any platform, as far as I know
[19:30] <persia> Depending on the solution, that might be a separate chip, or it might be onboard (based on the block diagrams I've seen)
[19:30] <jetienne> ojn: yep, the ubuntu on arm is only there to know if i can use arm chip to encode
[19:30] <persia> ojn: That's mostly a lack of available software that meets the licensing requirements.
[19:31] <ojn> jetienne: I can answer that right now. :-)
[19:31] <persia> We'd be *very* happy to provide that.
[19:31] <jetienne> the personn doing x264, a well known software video encoder, is telling me it is possible to encode 320x240 in real time on a cortex a8
[19:31] <ojn> persia: sure, I'm just saying it's not included. The codec licensing paperwork is a nightmare on most platforms.
[19:31] <persia> Indeed.
[19:32] <ojn> jetienne: ah, that low resolution might be possible. Sorry, I was thinking higher bandwidths.
[19:32] <persia> And so far, nobody has submitted code to our nice public collaborative code review site for package inclusion :)
[19:32] <jetienne> i dont need real time. but i need to be sure this is actually possible
[19:32] <jetienne> ojn: thats ok
[19:32] <jetienne> persia: you are in canonical
[19:32] <jetienne> ?
[19:33] <jetienne> in our case, we will use specific IP lawyers to get codec license, and i do agree this is a nightmare
[19:34] <jetienne> http://arstechnica.com/gadgets/news/2009/10/nokias-n900-is-an-important-step-forward-for-mobile-linux.ars <- ok i will get the company to get this toy :)
[19:34] <jetienne> thanks a lot for your helps guy
[19:34] <persia> jetienne: No promises that Ubuntu can be run on there.  I know several people tried with N810s and had various issues.
[19:36] <jetienne> i know the author behind strigi, he is paid to code on one of those nokia
[19:36] <jetienne> i will bug him to get running what i wnat :)
[19:45] <ojn> plars: halting bulding experiments, got new hardware toys. :)
[19:46] <plars> ojn: merry Christmas :)
[19:46] <plars> ojn: I also tested hello, it took about 4x as long on my qemu-arm-static environment as it took on my babbage :(
[19:47] <plars> 1m5.991s vs 4m19.461s
[19:47]  * plars needs some new hardware
[19:49] <ojn> plars: I was monitoring these for a while, snagged one when it showed up for $609. http://outlet.us.dell.com/ARBOnlineSales/topics/global.aspx/arb/online/en/InventorySearch?c=us&cs=22&l=en&s=dfh
[19:50] <ojn> uh, that link didn't work. XPS 435 mini tower.
[19:51] <plars> ojn: wow, not bad, cheapest at the moment is $739
[19:52] <ojn> yeah. they go up and down a bit depending on memory configs, etc.
[19:52] <ojn> mine was a bit low on memory, but I picked up some at fry's to fix that.
[23:14] <ojn> Hm, is there a bootargs option to make init provide debug info on what it is spawning?
[23:15] <persia> For which release?
[23:15] <ojn> karmic (upstart)
[23:15] <ojn> Oh, there seems to be a --debug.
[23:16] <persia> Kill that, and add quiet (see /usr/share/doc/upstart/README.Debian.gx for more)