[02:35] <DanaG> beagleboard is spiffy.
[08:30] <Shambat> anyone here have any experience with the Sheevaplug?
[08:32] <pranith> hello, i want to install ubuntu on the ipad. which version should i choose?
[08:33] <pranith> UNR?
[08:33] <Stskeeps> is ipad at all hackable?
[08:34] <pranith> Stskeeps, i have special priveleges ;)
[08:34] <Stskeeps> well get a linux kernel working first, :P
[08:34] <pranith> im sure the kernel works
[08:35] <pranith> its a general ARM core in the A4 chip
[08:35] <Stskeeps> well, not so much about that
[08:35] <pranith> cortex-A9 to be specific
[08:35] <Stskeeps> but you need to have linux kernel booting and chipsets/SoC supported etc
[08:35] <pranith> so which version of ubuntu do i choose? UNR? Ubuntu MID?
[08:36] <Stskeeps> and iphone linux attempts haven't gone that well, afaik
[08:36] <pranith> Stskeeps, ya, it's a imaginary scenario... i dont really have the ipad
[08:36] <pranith> :)
[08:37] <pranith> i was asking for ipad like ARM touch devies
[08:37] <pranith> devices*
[08:45] <Shambat> I want to build a custom Ubuntu based on 9.04 that has support for a lot of wifi chipsets ... This is for a Sheevaplug ... what is the best resource for accomplishing this?
[08:46] <Shambat> basically, I need to learn how to gather the parts and compile the OS, and install it....
[09:03] <ogra> pranith, as long as you have a kernbel and bootloader, try rootstock to assdemble a userspace
[09:03] <ogra> *assemble
[09:03]  * ogra needs to take a typing course it seems
[09:05] <ogra> i would start with a simple ubuntu-minimal build to see if the kernel works with the userspace, if that works, install whatever desktop env you like (use the ubuntu-desktop or ubuntu-netbook metapackages for that, MID is rather dead nowadays)
[09:11] <pranith> ogra, thanks!
[11:56] <noisi>  hi! i search for sql-server and client for arm720t. can you give me some advice, please?
[12:05] <lool> Would be great if someone could test valgrind on armel   :-)
[12:05] <lool> I'm aware of one upsteam issue which might affect some code pathes, basic testing against e.g. "ls" would be great
[12:06] <lool> noisi: Are you looking for binaries?
[12:06] <noisi> yes, everything :-)
[12:06] <lool> noisi: Your CPU is very old, I'm not sure it's supported by ARM anymore
[12:07] <lool> noisi: Also, it's of the ARMv4 family, and Ubuntu never supported this
[12:07] <lool> We supported ARMv5t in jaunty (9.04) but that is getting old
[12:07] <lool> noisi: Debian does support ARMv4T though, so Debian binaries should work
[12:07] <lool> noisi: Are you using EABI or OABI?
[12:08] <noisi> i don´t know eabi/oabi
[12:08] <lool> noisi: That's important, you should find out
[12:08] <lool> noisi: check your kernel config, look for ABI in CONFIG_ names
[12:09] <lool> we have CONFIG_AEABI=y CONFIG_OABI_COMPAT=y in Ubuntu for instance
[12:09] <noisi> i got a box with arm720t form http://www.owasys.com/
[12:10] <noisi> with no sources
[12:10] <lool> noisi: I understand, but arm720t wont work with Ubuntu and depending on which ABI you're using, you should use one or the other Debina port
[12:10] <lool> Both will work on your hardware, it depends of your kernel
[12:10] <lool> noisi: So you don't have a kernel?
[12:10] <noisi> ok
[12:11] <noisi> there is running a system
[12:11] <lool> noisi: With Linux?
[12:12] <noisi> Linux (none) 2.4.18-rmk3 #1264 Tue Nov 28 11:40:43 2006 armv4l unknown
[12:12] <noisi> if i type uname -a
[12:13] <lool> noisi: This is antique
[12:13] <lool> noisi: But you should have gotten the sources with your kernel (per the GPL)
[12:14] <lool> noisi: I am not sure how well Debian will work on 2.4.x kernels at this point though
[12:15] <noisi> okk
[12:16] <ogra> lool, do you have any elegant pygtk reciepe to make Popen non-blocking without having to fiddle with fnctl and additional filehandles ?
[12:17] <ogra> i.e. a magic switch i dont know about for subprocess
[12:17] <StevenK> I'm sorry, you can't use 'pygtk' and 'elegant' in the same sentence.
[12:17] <ogra> pfft
[12:17] <ogra> i just cant imagine that subprocess doesnt have anything builtin
[12:19] <lool> ogra: I don't understand the problem
[12:20] <lool> ogra: The default for Popen is to not block
[12:20] <lool> I mean subprocess.Popen
[12:21] <lool> ogra: By default, subprocess.Popen does os.spawn with P_NOWAIT
[12:21] <lool> It's only if you interact() that it will block on it (obviously)
[12:21] <lool> err communicate()
[12:21] <lool> Sorry, I'm confused by expect terminology
[12:22] <ogra> hmm
[12:23] <ogra> well, if i have output where the subprocess is busy for a while without spilling a new line my UI gets unresponsive
[12:23] <lool> ogra: How are you reading from your subprocess?
[12:23] <lool> ogra: code?
[12:24] <ogra> http://paste.ubuntu.com/379703/
[12:24] <ogra> stdout.readline()
[12:26] <ogra> i tried communicate but its buffering eternally
[12:27] <lool> ogra: I think you need to use select.select() and os.read()
[12:27] <ogra> and fnctl then i guess
[12:28] <lool> ogra: oh you're doing while output.poll() is None:
[12:28] <lool> So you should use poll()
[12:28] <lool> check for POLLIN
[12:30] <ogra> ah, thats what i was looking for i think
[12:30] <ogra> all solutions i found yet route through additional filehandles which i'd like to avoid
[12:31] <lool> The pipes should be fine
[12:38] <asac> non-blocking IO for the python world!
[12:42] <ogra> asac, well, even python can do fork() and pipe() :) its just that i dont use that
[12:42] <JamieBennett> we'll get asac loving python sooner or later ;)
[12:42] <ogra> yeah
[12:43] <asac> just remember gwibber spawning threads for blocking IO ;)
[12:44] <ogra> i luckily have never seen gwibber from the inside :)
[12:48]  * asac reboots after upgrade
[12:48] <ogra> dont !
[12:48] <ogra> you'll lose your sound
[12:51] <lool> Sadly there's no proper threading in python   :-(
[12:51] <lool> only real child processes
[12:52] <ogra> yeah
[13:02] <asac> seems my upgrade removed a bunch of stuff i didnt spot ;) ... like nm-applet etc.
[13:02]  * asac goes fixing his system
[13:03] <asac> hmm. is it possible that the sata port of bbg is really really slow?
[13:07] <ogra> yes, because it is no SATA port
[13:08] <JamieBennett> It hangs off of USB doesn't it?
[13:08] <ogra> right
[13:08] <ogra> with usb speeds
[13:08] <ogra> 16MB/s
[13:08] <ogra> can peak up to 20 ... but thats rare :)
[13:15] <asac> ogra: my sata drive is definitly slower than what i had with USB
[13:15] <asac> its really crawling
[13:16] <asac> maybe i should go for SD card again ;)
[13:17] <ogra> heh
[13:19] <ogra> ogra@babbage2:~$ sudo hdparm -t /dev/mmcblk0p2|grep MB
[13:19] <ogra>  Timing buffered disk reads:   32 MB in  3.17 seconds =  10.09 MB/sec
[14:31] <hrw> morning
[14:33] <hrw> Stskeeps: hi here
[14:33] <Stskeeps> moo
[14:34] <hrw> I see that next ubuntu release will target armv7 cpus only. which devices/cpus are supported?
[14:35] <hrw> as https://wiki.ubuntu.com/ARM/DeviceSupport is rather not up-to-date
[14:36] <ogra> hrw, imx51 (freescale) and dove (marvell armada)
[14:36] <ogra> up to now ...
[14:36] <hrw> ogra: no omap3?
[14:36] <ogra> no kernel
[14:37] <hrw> ok
[14:37] <ogra> so we dont build images
[14:37] <ogra> but userspace indeed works on all v7 CPUs
[14:37] <hrw> how many people work on ubuntu/arm?
[14:38] <ogra> well, hard to say ... we ven have a good bunch of beagle people helping on it :)
[14:38] <ogra> or do you mean inside canonical ?
[14:38] <hrw> inside
[14:39] <hrw> I have a bunch of arm boards on desk and just checked how many of them can run ubuntu.
[14:39] <ogra> in the distro/mobile team we're 8 if i didnt miscount, plus a bunch in the kernel team
[14:39] <hrw> but most of them are armv5te or armv6. just beagleboard and n900 are armv7a ones
[14:40] <ogra> v5 was supported in jaunty
[14:40] <ogra> in karmic we switched to v6+vfp
[14:40] <ogra> lucid now is v7+thumb2
[14:40] <hrw> I noticed
[14:40] <ogra> btw, as you can see on http://webapps.ubuntu.com/employment/ it will soon be more than 8 :)
[14:41] <ogra> like ... a lot more :)
[14:41] <hrw> ogra: I do not have to go there to know ;) I just looked into my inbox
[14:41] <hrw> ;D
[14:41] <ogra> lol
[14:43] <asac> hmm
[14:43]  * asac blind
[14:44] <asac> doesnt see where ocaml uses arm.S
[14:44] <asac> i guess its not used at all
[14:45] <asac> anyone can check if i miss something?
[14:45] <asac> hmm. is ASPP a default variable for make?
[14:45] <asac> dont see it defined either
[14:46] <asac> oh
[14:46] <asac> ;)
[14:46]  * asac should go one up
[14:46]  * ogra hands asac some glasses
[14:46] <asac> still cant find that arm.o is really used
[14:46] <asac> dont see anything in the build log either
[14:46]  * asac thinks about marking it as invalid
[14:47] <asac> dmart: ^^
[14:47] <asac> ocaml ... cant find in build system that arm.S is actually used
[14:48] <hrw> btw - armel is not 1st class arch in ubuntu? it is not present in packages.ubuntu.com interface
[14:49] <asac> hrw: thats just a technical detail
[14:49] <asac> it still lives in ports.ubuntu.com for a few reasons
[14:49] <asac> but its supported ;)
[14:49] <hrw> ok
[14:50] <hrw> where I can read more about devices which are supported?
[14:51] <asac> we currently support marvel dove and freescale imx51 devboards
[14:55] <hrw> thx. both looks like hard-to-get devboards
[15:04] <NCommander> hrw: Ubuntu lucid will work on any board with VFP+Thumb2+ARMv7 support, you just need to use rootstock to spin your own image.
[15:04] <hrw> ok
[15:16] <asac> update-notifier: Depends: update-notifier-common (= 0.95) but 0.96 is to be installed
[15:17] <asac> whtas going on :(
[15:17] <ogra> asac, still ?
[15:17] <asac> it definitly built
[15:17] <asac> so its something else
[15:17]  * asac tries what apt-get install says
[15:17] <ogra> was it published etc
[15:17] <asac> that doesnt have a problem
[15:18] <ogra> weird
[15:18] <asac> i didnt ran it, but it didnt complain and asked to go ahead
[15:18] <asac> ogra: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-netbook-imx51/20100219/livecd-20100219-armel.out
[15:18] <asac> maybe thats not a new run=
[15:18] <asac> ?
[15:18] <asac> ogra: can you kick off a llivefs build manually?
[15:19] <ogra> yes
[15:19] <asac> ogra: can you do? :-P
[15:20] <ogra> running
[15:20] <ogra> takes 3h though ...
[15:36] <ogra> asac, didnt fail yet, thats a good sign
[15:36] <ogra> unless the livebuilder locked up :)
[16:10] <Martyn> hey, for those pegatron nettops .. is there a 9.10 or 10.4 image I can throw on it?
[16:10] <ogra> nope
[16:10] <ogra> we dont have a kernel
[16:22] <Guest48348> Martyn: I found Karmic can work, though it requires a bit of a bodge to run it on the existing jaunty kernel
[16:23]  * dmart_ curses nick lockouts
[16:23] <dmart_> ogra, asac: Did anyone have a chance to connect a board running the current imx51 kernel via a hub?
[16:24] <asac> dmart_: ogra tried that
[16:24] <ogra> dmart_, i dont have a hub around and nobody around me seels them :(
[16:24] <asac> he wasnt able to reproduce issues
[16:24] <dmart_> IRC _really_ does not like that I have to keep pulling out my uplink cable to download things onto the board...
[16:24] <ogra> *sells
[16:24] <asac> really
[16:24] <ogra> asac, i only tested on switches
[16:24] <asac> ogra: you sent a mail
[16:24] <asac> ogra: why did you test switches ;)
[16:24] <asac> dmart_: ok scratch that. seems we dont have a hub then
[16:25] <lool> Can one still find hubs?
[16:25] <ogra> asac, because i dont have hubs and nobody said there was a prob with hubs until after i sent the mail
[16:25] <ojn> Martyn: I never got any useful information out of ARM, so I just went with the Genesi-side docs instead. They use a different wifi chip but the rest works: http://blog.efikamx.info/2009/12/releases-for-22nd-december-2009-u-boot.html
[16:25] <asac> ogra: your mail really sounded like you tested hubs ... i wouldnt have expected a mail aabout switches at all
[16:25] <asac> because noone complained about those
[16:25] <ogra> asac, huh ?
[16:25] <asac> nevermind
[16:27] <asac> lool: maybe on ebay
[16:27] <ogra> or as a do-it-yourself soldering kit for kids to learn about network HW :)
[16:28] <dmart_> Maybe fsl could help with this?
[16:29] <ogra> well, i didnt see any issues with iftop on switches when testing karmic and lucid ... there was a difference of 5Mbit/sec between the two though
[16:30] <ogra> dmart_, are you seeing that on lucid too ?
[16:30] <dmart_> It's only on lucid --- it may have come in at the time of the fsl .31 kernel merge, since it didn't happen very early in the cycle.
[16:31] <ogra> early in the cycle we used the karmic kernel
[16:31] <ogra> lucid is 100% freescale now
[16:31] <dmart_> But boards running the current kernel are ~ unusable for development unless I uplink directly --- download drops from normal speed to 10-100kB/s
[16:32] <dmart_> This has been seen with Babbage 2.0 and 3.0, and with multiple hubs.
[16:32] <ogra> bad :/
[16:32] <dmart_> Unfortunately our IT temporarily ran out of switches too...  but I'll try and order one.
[16:35] <ogra> i'll try to get a hub somewhere over the weekend
[16:35] <ogra> cant be that hard to find one
[16:35] <dmart_> hopefully not...
[16:35] <ogra> (i only checked the closest HW shops around)
[16:36] <dmart_> On another topic, is anyone else having trouble with the current armel images?
[16:36] <dmart_> For me, ubuntu-netbook 20100215 (current) -> ubiquity crashes shortly before completion
[16:37] <dmart_> ubuntu-desktop 20100218 -> the same, + nautilus crashes and repeatedly respawns
[16:37] <ogra> there were a lot of fixes to ubiquity within the last three days
[16:37] <ogra> though i heard partitioning is broken atm
[16:37] <dmart_> I didn't try to run ubiquity on 20100219, but nautilis still crashes.
[16:37] <ogra> ignore ubuntu-desktop please
[16:37] <ogra> the livefs isnt updated anymore
[16:37] <ogra> StevenK, ^^^ can we stop producing images as well here ?
[16:38] <dmart_> I did a debootstrap instead and I get a working-ish system (except rsyslogd eats all the CPU), and nautilus does not crash, weirdly.
[16:38] <ogra> (gah, i still didnt check how late it is for steve ... )
[16:38] <dmart_> Ah, if the livefs is no longer updated that would explain why nautilis isn't fixed.
[16:38] <ogra> right
[16:38] <dmart_> I was only using -desktop because the netbook image was borked...
[16:39] <ogra> ignore desktop, i'll care for it not showing up on cdimage anymore next week
[16:39] <dmart_> Sounds sensible
[16:39] <dmart_> Is there a metapackage for -netbook in case I need to bootstrap it?
[16:39] <ogra> yep
[16:39] <ogra> ubuntu-netbook :)
[16:39] <dmart_>  Hmmm, looked for that but couldn't find that before
[16:40] <ogra> though better try the task
[16:40] <ogra> apt-get install ubuntu-netbook^
[16:40] <ogra> (mind the caret)
[16:40] <dmart_> Found it now, maybe my package list was out of date.
[16:40] <ogra> i just did a rootstock testinstall today like that
[16:40] <ogra> right, should be there
[16:41] <dmart_> Found it... maybe my lists were out of date
[16:42] <ogra> yeah
[16:42] <dmart_> Is the intention that ubuntu-desktop should still work?  It's a bit nicer for development purposes, but building images is not really needed.
[16:43] <ogra> should still be installable, yes
[16:43] <ogra> we just dont test it or roll images
[16:43] <dmart_> Sure.  It looks like mono unbroke, so I can install it now, anyway.
[16:43] <ogra> but unless there are massive regressions (which i wouldnt expect) it should just work
[16:44] <dmart_> Nothing untested ever "just works" ;)  But that's fine in this case
[16:44] <ogra> heh
[16:45] <dmart_> asac: How's the Thumb2 porting stuff going?
[16:45] <asac> dmart_: currently working on it my self.
[16:45] <asac> ocaml invalidated (asm isnt used at all)
[16:46] <dmart_> Should we have another sprint?  I don't think a time was suggested yet.
[16:46] <persia> I also haven't seen a time suggested.
[16:46] <asac> dmart_: next week about the same time i would suggest
[16:46] <asac> problem is that australia wants to participate
[16:46] <persia> 11:00 UTC on Thursday?
[16:47] <asac> thats good
[16:47] <asac> then US has to skip i guess
[16:47] <asac> but they had their chance last time
[16:47] <persia> Or come late.
[16:47] <dmart_> I can possibly do an evening, so long as it doesn't happen too often ;)
[16:47] <asac> dmart_: 1100 UTC it is
[16:47] <asac> i will send an invite
[16:48] <dmart_> OK, fine for me.
[16:48] <dmart_> That's a week away though, did we want to do it earlier?
[16:48] <asac> and try to get the team to work on that next week with more pressure ;)
[16:48] <persia> dmart_: The issue is that midnight UTC is a good time to start working in Asia, so "evening" can get quite late :)
[16:48] <asac> dmart_: you are always here ... thats ok; we just need to work outside of the sprint on it too
[16:49] <asac> which I feel we didnt do enough the last week (partly excused by part of the team on the road this week)
[17:02] <dmart_> Is there a list of packages which nobody has picked up yet?  I've been a bit distracted this week, but hopefully I can look at a couple
[17:03] <persia> People should be updating the wiki when they do something.  If you find a pacakge not updated, it's fair game.
[17:03] <dmart_> OK
[17:06] <dmart> How is dove these days?
[17:13] <ogra> curring
[17:13] <ogra> (sorry couldnt resist :P )
[17:13] <ogra> X0 should be fine again
[17:14] <dmart> sounds good
[17:14] <ogra> and i heard even Y1 was good according to GrueMaster
[17:14] <dmart> Was that from kernel updates, or something else?
[17:15] <ogra> kernel updates, mainly the most recent fix afaik
[17:15]  * asac apt-get source mono
[17:15]  * asac find | xargs grep mov.*pc
[17:15] <ogra>  2.6.32-201.10
[17:15] <ogra> only went in yesterday
[17:16] <persia> For lucid also, or just karmic?
[17:16] <asac> dmart: we have really odd issues in the mono testcases... one that strikes me is that Integer.MAX_VALUE++ seems to not overflow ... does that ring any bell?
[17:17] <dmart> Not really.  Is this a regression since Thumb2?
[17:17] <asac> unlikely
[17:17] <asac> in karmic 40 testcases failed
[17:17] <asac> now its just 37 ;)
[17:17] <dmart> ah
[17:17] <asac> nevermind. have to check the code what is actually happening for increment to get an idea
[17:17] <dmart> Maybe the code which detects the overflow is not correct.  I don't know the mono internals myself...
[17:18] <asac> ulong a =  UInt64.MaxValue; ulong t = a++;
[17:18] <asac> thats what is not overflowing
[17:18] <lool> asac: find | xargs grep => rgrep or grep -r
[17:18] <asac> dmart: yeah probably. its odd that it works on other archs though ;)
[17:18] <asac> lool: i know ;)
[17:18] <lool> Oh ok
[17:18] <asac> its jus tthat that flows out of my fingers automatically ;)
[17:19] <asac> also you can more easily restrict what to search with find imo
[17:19]  * lool has grep -rl in his fingers instead
[17:19] <asac> but could be i am just too old ;)
[17:19]  * persia things xargs is obsolete anyway, since find grew exec +
[17:19] <lool> asac: I do **/*.c when I need to limit to certain file types
[17:19] <asac> will try to change my habit ;)
[17:19] <lool> asac: Oh just suggested it in case you wouldn't use it
[17:20] <lool> I discovered grep -r after some years of linux and it changed my life
[17:20] <lool> Would have been suprizing if you hadn't known about it
[17:20] <persia> grep -rn is key to understading source files.
[17:20] <asac> to be honest i discovered it not that long ago ... couple of years maybe ;)
[17:40] <asac> dmart: #define ARM_DEF_BX(reg,sub,cond) (0x12fff << 8 | (reg) | ((sub) << 4) | ((cond) << ARMCOND_SHIFT))
[17:40] <asac> that is supposed to emit bx ;)
[17:40] <asac> is that number correct?
[17:41] <dmart> It looks probably correct for ARM, but the Thumb encodings are different.
[17:41] <asac> right.
[17:41] <dmart> Do you know what gets passed for sub
[17:41] <dmart> >
[17:41] <rbelem> Hey guys! Are you using any crosscompiling toolchain?
[17:42] <ogra> rbelem, nope
[17:42] <asac> dmart: http://paste.ubuntu.com/379877/
[17:42] <ogra> rbelem, use qemu-arm-static and do native builds in chroot :)
[17:42] <asac> so ARMREG_IP
[17:42] <asac> let me check what that is
[17:43] <rbelem> ogra, i'm using that, but i want make builds faster
[17:43] <dmart> Probably the register numper for ip (it's r12)
[17:43] <rbelem> using icecc
[17:43] <rbelem> icecc rocks!
[17:43] <rbelem> :-)
[17:43] <dmart> asac: The fact that mono is doing code gen might be an issue --- it's presumably generating ARM code, so we need to watch out for calls into and out of that code.
[17:44] <asac> dmart: so sub == 1
[17:44] <asac> dmart: not worth fixing the code to emit thumb2 code?
[17:45] <dmart> Yes, but that might be a larger job.  Is this a JIT, or it just generating a few native call veneers or similar?
[17:45] <asac> its a jit ... we have all the defines in the mono/arch/arm/arm-codegen*.h
[17:46] <rbelem> ogra, i'm using maemo(RIP) with qemu-arm-static and icecc to speedup the builds
[17:46] <asac> there is mono/arch/arm/arm-codegen.h and also mono/arch/arm/arm-codegen-vfp.h
[17:46] <asac> and otheres
[17:46] <ogra> rbelem, ah
[17:46] <asac> dmart: wanna take a look at those files to see how much changes it would be to come up with thumb?
[17:47] <asac> feels like if i knew this stuff it would be just going through that full file ;)
[17:47] <asac> dmart: so whats the idea to watch for calls-in and out?
[17:47] <rbelem> ogra, and the scratchbox toolchain
[17:47] <ogra> right, thats fine for maemo stuff :)
[17:47]  * dmart apt-get source mono ...
[17:48] <rbelem> ogra, but now i'm planning help you with arm porting :-)
[17:48] <asac> hmm they already have stuff like: "THUMBOP_TST"
[17:48] <asac> e.g. ThumbOpcode
[17:48] <asac> in mono/arch/arm/arm-codegen.h
[17:49] <ogra> rbelem, well, then qemu and icecc to do native builds are likely the best you can do beyond using real HW
[17:49] <ogra> (or distcc)
[17:51] <rbelem> ogra, that's why i want a crosscompiler. The build nodes will use it.
[17:52] <ogra> just make the nodes run it in qemu-arm-static ?
[17:52] <rbelem> ogra, but it is very painful
[17:52] <ogra> well, cross building is more painful imho
[17:53] <ogra> as long as you have dependenciesw at least
[17:53] <ogra> its surely suitable for something like a kernel testbuild
[17:53] <rbelem> ogra, i use my colleagues computers, so i can not install it on each computer
[17:53] <ogra> but i wouldnt want to build any desktop package in a cross way
[17:54] <ogra> and beyond that you might hit toolchain issues that arent present in native builds or vice versa
[17:54] <ogra> or compiler issues
[17:55] <rbelem> ogra, which issues are possible?
[17:55] <asac> reconnect
[17:55] <ogra> well, you use a different compiler
[17:55] <asac> dmart: didnt get anything from last 5 minuts
[17:55] <ogra> different version, other features etc
[17:56] <dmart> asac: Are you still talking about mono?  If so, not yet --- NFS (slow)
[17:56] <rbelem> ogra, isn't it the same compiler but compiled to be cross?
[17:57] <ogra> rbelem, where do you get that compiler ?
[17:57] <ogra> we dont offer a cross build of our gcc 4.4.3
[17:57] <asac> dmart: just notified you so you can repost if you said something
[17:58] <dmart> OK.  still waiting I'm afraid
[17:59] <dmart> rbelem: You could try using the Ubuntu gcc source and messing with the configure args.  But that's only feasible if you've already build cross-compilers (there are many pitfalls and I've not done it myself recently)
[17:59] <rbelem> ogra, it is just an assumption
[17:59] <ogra> well, its a techincal impossibility atm :)
[17:59] <rbelem> dmart, it would be nice
[18:00] <ogra> right
[18:00] <persia> rbelem: Even if the same compiler, but compiled differently, one can encounter ABI skew, which makes things segfault for unexpected reasons.  It's essential to compile everything in the same way.
[18:00] <ogra> if someone would build a cross compiler from the same source you would be on the safe side
[18:00] <ogra> *safer
[18:00] <persia> Since we compile everything native, anything that needs to link to it should also be compiled natively.
[18:02] <rbelem> let me check a cross compiler package contents
[18:02] <NCommander> rbelem: what are you trying to build specifically?
[18:03] <rbelem> NCommander, nothing specific. But i'm planning to build kde stuff
[18:04] <dmart> Well, there should be no ABI skew in principle between cross and native compilers build from the same compiler source.  But native/cross compatibility is not well tested--- most people use just one of the other, and there have been discrepancies in the past.
[18:04] <NCommander> rbelem: you *really* don't want to cross-compile KDE unless you love torture :-)
[18:04] <rbelem> eheheh
[18:04] <dmart> To accelerate local package hacking, a cross compiler + scratchbox could be useful.  But this is no good for the Ubuntu archive.
[18:04] <NCommander> CMake supports cross compiling, but its really really different from auto**** and kinda wonky
[18:04] <ogra> the dependency cahin will be fun :)
[18:04] <ogra> *chain
[18:05] <NCommander> dmart: indeed. We've made some progress improvmenting qemu-linux-user
[18:05] <ogra> NCommander, none WRT speed though
[18:05] <asac> dmart: i think it might speed things up if you are joining #monodev on irc.gimp.net
[18:05] <ogra> and i doubt you can speed it up
[18:05] <rbelem> dmart, i can do almost the same thing with qemu-arm-static
[18:06] <asac> dmart: the guy that knows all this is currently there it seems ;)
[18:06] <rbelem> dmart, to remove the "almost" i need the cross toolchain
[18:06] <NCommander> ogra: with some cross-compiler hooks, you can offload compiling to native; I played around with it on m68k
[18:06] <rbelem> :-)
[18:06] <NCommander> Its fairly stable as a buildd actually.
[18:06] <persia> rbelem: dmart There's also lots of packages that have assumptions in the build systems that make them unsuitable for cross-compilation which would need to be sorted.
[18:07] <ogra> NCommander, you mean that scary hack suse is using in OBS ?
[18:07] <NCommander> (in that case, there was no QEMU, but I had hacked up distcc to do the offloading)
[18:07] <ogra> ah
[18:07] <rbelem> persia, it is transparent if you use icecc
[18:07] <rbelem> persia, the cross will be in other machine
[18:07] <NCommander> ogra: I remember pitching the idea at UDS jaunty, but we decided that native compiling was just easier
[18:08] <ogra> rbelem, he talks about hardcoded stuff in packages etc
[18:08] <ogra> NCommander, the OBS idea ?
[18:08] <ogra> thats a horrid hack
[18:08] <NCommander> ogra: using cross-compilers via distcc to speed up compilation
[18:08] <rbelem> ogra, which kind of stuff?
[18:08] <asac> dmart: so we need to adjust all ARM_DEF defines vargaz said
[18:09] <ogra> rbelem, injecting x86 libc into the amrel chroots
[18:09] <asac> dmart: with #ifdef thumb
[18:09] <asac> if we go the full jit way
[18:10] <rbelem> ogra, i didn't get. do you have an example?
[18:10] <rbelem> :-)
[18:10] <ogra> NCommander, i would support using distcc across a bunch of machines using qemu-arm-static ;)
[18:10] <asac> dmart: is it usually just the OPTAG that needs to be adjusted?
[18:10] <asac> like ARM_MUL_TAG
[18:10] <asac> or the full ARM_DEF_MUL_COND ?
[18:11] <dmart> You cannot generate Thumb code from an ARM JIT implementation without significant work, because a lot of assumptions break down.
[18:11] <asac> they use BX at least they told me
[18:11] <asac> but yeah
[18:11] <rbelem> ogra, "Now based on GCC 4.4.1!"  - http://www.codesourcery.com/sgpp/lite/arm
[18:11] <ogra> rbelem, they inject the x86 libc into an arm chroot and use the x86 gcc in there, what comes out is arm code like its been cross compiled but the env it is built in is arm, that speeds up and solves the dependency issues
[18:12] <ogra> rbelem, right, we use 4.4.3
[18:12] <rbelem> :-(
[18:12] <dmart> asac: I haven't looked in detail yet
[18:12] <asac> dmart: sure so i guess too much work ;) ...
[18:12] <asac> 19:09 < vargaz> thumb2 support is only required on cpu-s without the arm classic instruction set, which are rare.
[18:12] <asac> dmart: ^^
[18:12] <ogra> heh
[18:13] <asac> or is he just saying that -marm is ok?
[18:13] <ogra> so we should revert the archive ...
[18:13] <dmart> asac: If they have the interworking correct, then that statement is true.  There is no special reason to convert a JIT from Thumb to ARM unless it is the only way to resolve interworking issues.
[18:14] <asac> ok
[18:14] <asac> he claims there are thumb-2 only CPUs out there ;)
[18:14] <asac> 19:13 <@kangaroo> someone makes thumb-2 only cpus?
[18:14] <asac> ah ok
[18:14] <asac> 19:13 < vargaz> yes.
[18:14] <asac> 19:13 < vargaz> there is the cortex-m series or something, which are micro-controllers.
[18:14] <asac> i guess we are not ready for that ;
[18:14] <asac> )
[18:15] <dmart> The ARMv7-M profile does not have the ARM instruction set.  Cortex-M* profiles implement this.  These are intended for microcontrollers and don't have an MMU etc., so this is uClinux territory.
[18:15] <asac> yeah ... was just kidding
[18:16] <rbelem> ogra, yeah! :-( When will them will launch 4.4.3?
[18:16] <ogra> no idea
[18:16] <asac> dmart: anything you would like me to ask now that the right folks for mono seem to be available?
[18:16] <ogra> asac, seems the livebuild doesnt get forward and lamont it in the air :/
[18:17] <asac> ogra: sigh
[18:17] <asac> ogra: single point of failure is just bad
[18:17] <ogra> yeah
[18:17] <asac> is there someone in the pipeline?
[18:17] <ogra> single lifevfs builder too :(
[18:17] <asac> ;)
[18:17] <ogra> i pinged in #is
[18:17] <dmart> asac: Sounds like ARM/Thumb interworking in the mono JIT should be discussed with vargaz?  If he can explain why it works, we're probably fine.  If he doesn't understand the question, we have some work to do ;)  (but it sounds like he has thought about it...)
[18:17] <rbelem> ogra, do you think it is possible for lucid+1?
[18:18] <asac> dmart: see pmsg
[18:18] <ogra> rbelem, i dont think we'll ever support it because you cant be sure the cross built stuff is really identical to a native build ... and i suspect codesourcery might always be behind in versions
[18:19] <persia> rbelem: native build doesn't take *that* much longer.  IF you want it really fast, run distcc on a bunch of ARM hardware.
[18:20] <ogra> asac, seems its still running, just not spitting out logs atm
[18:20] <rbelem> persia, i just have two arm devices :-(
[18:21] <persia> Yeah, well.  That is still a problem for most of us :)
[18:22] <rbelem> persia, ogra suggested to run icecc inside a chroot with qemu-arm-static as an alternative
[18:22] <ogra> asac, ah, there just popped up some logs for dove ;)
[18:23] <ogra> seems to run fine ...
[18:23] <armin76> persia: you can always run cross distcc
[18:23] <persia> rbelem: Sure.  ARM boxes can be real or emulated :)
[18:23] <ogra> i dont get why dove was built before imx51 though ... i gave the command in a different order :/
[18:23] <persia> armin76: I don't trust the reliability of mixing that with native, give that it's not well tested and there have been issues in the past with alignment, etc.
[18:24] <persia> armin76: If it's all cross or all native, no issues.  Since the rest of the archive is native...
[18:24] <armin76> always worked for me :)
[18:24]  * ogra goes afk and will check the builds later tonight again
[18:24] <ogra> armin76, you mix cross and native stuff ?
[18:25] <armin76> ogra: for building my stuff yes
[18:25] <ogra> with a toolcahin and compiler on the edge and highly optimized default flags ?
[18:25] <asac> 19:24 <@kangaroo> yes
[18:25] <asac> 19:24 <@kangaroo> we use interworking all the time
[18:25] <asac> 19:24 <@kangaroo> if its not, its a bug and we'll fix it
[18:25] <asac> 19:24 <@kangaroo> we have to support it to pinvoke thumb libs from C#
[18:25] <asac> dmart: ^^
[18:26] <dmart> Probably it works then... I'll try and chat with him on Monday and check.
[18:26] <armin76> ogra: no, i use what we call stable, which is gcc-4.3.4,glibc-2.10,binutils-2.19 atm
[18:27] <dmart> asac: Mind you I can't figure out where the arm-codegen stuff is actually used from.
[18:27] <asac> dmart: in in mono/mini/arm*
[18:27] <asac> i think
[18:27] <asac> at least thast how i found the codegen parts ;)
[18:27] <asac> (those filse have the mov matches ... which turned out to be just comments before they use those macros)
[18:27] <ogra> anyway ... -> afk
[18:27] <dmart> Oh yes, I see (the first function I searched for wan't used...)
[18:28] <asac> ls mono/mini/mini-arm*
[18:28] <asac> mono/mini/mini-arm.c  mono/mini/mini-arm.h
[18:29]  * rbelem goes check for toolchains
[18:46] <lool> persia: sudo works for me in latest qemu-arm-static
[18:46] <Martyn> ojn : Still about?
[18:46] <Martyn> ojn : I'm downloading your installer and karmic image .. hopefully this will all work sans serial, since I don't have a serial cable for this pegatron
[18:49] <ojn> Martyn: not mine, but genesi's. Yeah, I got a hold of one of the debug boards they have that brings out serial and jtag. I'd been dead in the water with out.
[18:52] <Martyn> Without the serial and jtag, do I have a hope in heck of getting this installer SD and image to work?
[18:54] <NCommander> Martyn: on a pegatron imx51 board?
[18:54] <Martyn> yep
[18:54] <NCommander> Probably not. Pegatron uses Lange which is a variant of babbage
[18:54] <Martyn> the little white one that looks like a genesi
[18:54] <NCommander> Kernel is incompatible
[18:54] <ojn> Martyn: You can borrow my debug board if you want
[18:54] <Martyn> Hmm .. where can I find the original system image for the white Lange based unit?
[18:55] <ojn> Martyn: dmart kept promising one but I never saw one.
[18:55] <Martyn> because what happened is that someone in the company decided to try upgrading from 9.04 to 9.10 using the system updater
[18:55] <Martyn> and let me tell you, it's in a sorry state :)  Kernel panic :)
[18:56] <persia> lool: works for me too.  Nice work!
[18:56] <armin76> Martyn: yes it will
[18:57] <Martyn> armin76 : Wait, so the genesi installer _will_ work on this white pegatron?
[18:57] <armin76> Martyn: you can always change the kernel :)
[18:58] <armin76> Martyn: ask neko on #efika, but i guess so
[18:58] <ojn> Martyn: That's what I used on mine
[18:58] <ojn> Martyn: on a separate SD card
[18:59] <armin76> i believe it still has the nice bug that once you reboot it, ssh won't come up again
[18:59] <Martyn> ojn : So - sequence of events is -- installer-sd.img onto an SD card .. change DIP to 0001 .. power up system
[18:59] <Martyn> without a serial cable, will there be any external indication that the process is complete?
[18:59] <ojn> Martyn: correct. Yes, framebuffer should come up
[19:00] <armin76> it tries to get a ip from dhcp
[19:00] <armin76> Martyn: the efika boots from sd before internal 'ssd' without touching the DIP
[19:00] <Martyn> then copy the karmic-minimal tar to a SD card?
[19:01] <armin76> Martyn: there's a dd image
[19:01] <Martyn> armin76: so installer-sd.img is sufficient on it's own then...
[19:01] <armin76> i believe so
[19:02] <Martyn> allright .. I'll be right back then.    Lets give this a spin
[19:09] <Martyn> I flipped the DIP to 0001, light went blue for a few moments, then power light went green.  No framebuffer came up
[19:09] <Martyn> how long should I leave it be?   What is the expected time before the framebuffer should come up if this was at all successful?
[19:09] <Martyn> armin76: I used the image from http://www.powerdeveloper.org/platforms/efikamx/linux
[19:10] <asac> heh http://infocenter.arm.com ... doesnt work on chromium for me
[19:10] <armin76> Martyn: there is some problems with the display, i don't believe that image has them fixed
[19:11] <armin76> its from last year, so definitely it doesn't
[19:11] <armin76> Martyn: check if it looks for dhcp requests, then you could access it through ssh
[19:11] <Martyn> armin76: Is there an /original/ system image available?  The 9.04 image Pegatron used?
[19:11] <Martyn> Frankly, I'd be happy just getting this unit back to factory-working condition
[19:12] <armin76> i don't have it
[19:12] <armin76> nor its hosted there afaik
[19:13] <Martyn> Grrr.. how the heck can I fix this thing then.
[19:13] <armin76> put gentoo on it *g*
[19:13] <Martyn> It's all fine for them to give them away, but an original system image would be nice.
[19:13] <Martyn> armin76: not the point :)  I'd like to get it just working again.
[19:13] <Martyn> okay, I'll look for a DHCP request .. so far none show up
[19:13] <Martyn> once the SD card installer has finished, is there any exernal indication?
[19:14] <armin76> Martyn: maybe you could try replacing the kernel in that image with the one you already had
[19:16] <Martyn> that's the problem .. without serial, there's no way for me to get to the uboot
[19:16] <Martyn> so I need some sort of flash-recovery image
[19:17] <Martyn> Hmm .. no evidence of DHCP activity
[19:17] <Martyn> I'll flp the DIP switches back to the original state and reboot
[19:17] <Martyn> see if anything changes
[19:17] <armin76> oh, thought the original image was on another sd card
[19:17] <Martyn> no.  They just toasted the box by attempting an ubuntu upgrade from 9.04 to 9.10
[19:17] <armin76> ok, then definitely you're screwed if you aren't able to boot the kernel
[19:18] <armin76> blame ubuntu for breaking stuff :P
[19:18] <armin76> (i just removed the thing about pinging me wrt anyone going to mwc)
[19:22] <Martyn> So what is this thing called exactly?  Babbage 2?
[19:22] <armin76> lange 5.1 i believe
[19:22] <armin76> thats what uboot says
[19:22] <Martyn> I'm obviously going to have to either talk to Pegatron or Freescale about getting a recovery system image
[19:23] <persia> I believe it's sufficiently different from the babbages that the babbage kernel doesn't work (but base this entirely on hearsay)
[19:24] <armin76> Martyn: canonical has lange boards as buildd's, maybe they could help you
[19:28] <armin76> Martyn: just a question, can't you access uboot from video output?
[19:29] <armin76> (haven't plugged my efika, no hdmi monitor)
[20:00]  * lool is a bit pissed off that bzr needs more than 200 MB of RAM to checkout d-i
[20:39] <Martyn> armin76: Nope, can't access uboot from video
[20:39] <Martyn> armin76: uboot doesn't seem to have framebuffer
[20:39] <armin76> ok. thanks :)
[21:01] <Laibsch> Hello
[21:01] <Laibsch> I come from an Openembedded background, but as a user of Ubuntu I'm increasingly interested in Debian/Arm and Ubuntu/Arm
[21:02] <Laibsch> I'll have a few dumb questions if you don't mind
[21:02] <Laibsch> Why are karmic and lucid only available for armv6 and armv7 respectively?
[21:03] <Laibsch> I have a Sharp Zaurus spitz, that is armv5te and I would like to see if I can't get some kind of Ubuntu running on it
[21:07] <lool> Laibsch: We build natively and we don't have enough hardware or manpower to build and qa multiple flavours
[21:08]  * lool &
[21:08] <Laibsch> lool: Hi
[21:08] <Laibsch> Nice to see you again
[21:08] <lool> Hey
[21:08] <Laibsch> What do you mean "/me &"
[21:09] <Laibsch> I take that as "me too"
[21:09] <Laibsch> You have a spitz as well?
[21:09] <lool> I mean I'm putting myself in the background
[21:09] <persia> '&' as in backgrounding
[21:09] <lool> As in going to sleep
[21:09] <Laibsch> I see
[21:09] <Laibsch> good night
[21:09] <lool> you too
[21:09] <Laibsch> Just five more minutes?
[21:10] <Laibsch> lool: I understand your question that if more people with more hardware where trying things out there is nothing in the way of relaxing armv7 to armv5te, for example?
[21:10] <Laibsch> Correct?
[21:11]  * Laibsch REALLY hopes that assumption is correct
[21:12] <Martyn> Laibsch: No, the armv7 + thumb was pretty much a -requirement- for lucid
[21:12] <Laibsch> :-(
[21:12] <Martyn> armv5 support is dropped
[21:12] <Laibsch> d'oh
[21:12] <Laibsch> Can you explain why?
[21:13] <lool> Laibsch: We want v7 + thumb2 in any case due to performance benefits on the platforms we mainly target
[21:13] <Martyn> thumb2ee support
[21:13] <persia> It's a parallel set of reasons to the reasons that real i386 isn't supported by the i386 flavour anymore.
[21:13] <Martyn> so even armv6 is dropped
[21:13] <persia> Basically, newer code runs faster on newer chips.  As there aren't a lot of people who run Ubuntu ARM right now, the baseline has been set high.
[21:13] <Laibsch> I have a Freerunner that I don't use for anything else
[21:14] <persia> This *should* reduce complaints about insufficient optimisation in the future.
[21:14] <Laibsch> So I guss that will have to become the test target, then
[21:14] <persia> I thought the freerunner didn't even support ARMv4 fully.
[21:14] <Laibsch> Oh no!
[21:14] <Laibsch> Well, I think I'll give it a try nonetheless
[21:14] <Laibsch> and don't expect anything really working
[21:16] <Laibsch> Well, if all else fails, at least Debian seems to run on the Freerunner
[21:16] <Martyn> Since new cheap platforms are now mostly v7 (beagleboard, etc) this shouldn't be a huge problem
[21:17] <Martyn> we'll see more platforms based on the omap3xxx omap4xxx armada smooth-stone, etc...
[21:17] <persia> There's even stuff in nice consumer plastic boxes (like the Efika MX and Netwalker)
[21:17] <Martyn> true
[21:18] <Martyn> *curses that his Pegatron i.mx51 board isn't as easy to reflash as the Efika MX*
[21:18] <Martyn> I mean, I --thought-- the hardware would be identical
[21:19] <Laibsch> The way ubuntu-arm works is to compile natively or pull packages from the repo, right?
[21:19] <Laibsch> Openembedded used cross-compilation
[21:20] <persia> Martyn: There's something special about those boards.  The Netwalker is similarly trivial to reflash.
[21:21] <persia> Laibsch: Indeed.  Full native compilation.  This will become less painful when the rumoured >1GHz >1GB devices become easily available.
[21:21] <Martyn> persia : *nod*  Driving me up the wall though ...
[21:21] <Martyn> persia: I'm --working-- on it as hard as I can.  -lol-
[21:21] <Martyn> It's not that easy to tape out a chip, yanno?
[21:21] <persia> Martyn: given the time, you're probably stuck until Sunday night, but I think you need to get support from Pegatron directly for those.
[21:21] <persia> Or at least I haven't heard of a sufficient release that normal folk can get them.
[21:22] <persia> Martyn: Understood.  I'm looking forward to new toys, although I'm hoping you can fit it in a smaller box.  Something the size of a Mac Mini would be a perfect addition to my desktop :)
[21:23] <Martyn> persia : We can fit into a 5cm x 5cm board :)
[21:23] <Laibsch> http://unstable.buildd.net/buildd/armel_Failed.html nice, Debian is even building opie!
[21:23] <persia> With all the power you showed at UDS?
[21:24] <Laibsch> hm, seems to be something else from what I was expecting
[21:26] <Martyn> persia : more performance, less power
[21:26] <Martyn> persia: We're probably now going to be able to clock up to 1.6, maybe 1.8GHz
[21:27] <persia> Oh, excellent.  And I presume that someone is going to package that into a set-top or monitor-back or similar form-factor?
[21:28]  * persia has a weakness for plastic cases
[21:46] <Laibsch> Are you guys intensively using icecc or distcc or is all compilation really done on arm devices?
[21:53] <Martyn> compilation is done natively
[21:53] <Martyn> persia : It's an SoC for anyone to package, but I believe the majority of them are going to be stuffed into high-density clusters in a blade, 1U, 6U or whole rack chassis
[21:54] <Martyn> perisa : 30 to a board or some such
[22:09] <persia> Martyn: Yeah, I suspect you're right.  Same issues I have getting a Sparc: my use case is the extreme minority.
[22:10] <Martyn> persia : What I /can/ guarantee is that we're going to produce a ton of development boards
[22:10] <Martyn> with at least TWO chips each
[22:10] <Martyn> so you can practice making little clusters
[22:12] <persia> And I can probably stuff one in an old NAS or something.  I'm just a bit lazy :)
[22:20] <Martyn> heh
[22:20] <Martyn> likely they will come in a little plastic box
[22:21] <persia> Oh, now I suspect I'll have to get one :)
[22:27] <kblin> Martyn: yay, new toys :)
[22:31] <Martyn> and if I have anyting to do with it .. the system images will be <easy> to find, the wiki will be <open> to edit, and god-damnit the thing will run ubuntu
[22:32] <persia> Martyn: If I can add to the wishlist: could you add a dual-booting bootloader, so that one can easily swap userspace/kernels with a low chance of bricking the unit?
[22:33] <persia> (or n-booting :) )
[22:35] <persia> While I have issues getting new kernels for the Netwalker (I should go study kernel hacking), I know that I've used this a couple times to reinstall with great confidence.
[22:44] <plars> persia: he left already
[22:45] <persia> Yeah.  That happened during my first response.
[22:45] <persia> But I figured I'd complete my thinking for the logs.
[22:46] <plars> :)
[22:46] <persia> Maybe someone else is also making cool devices that run Ubuntu and will also implement it :)
[22:47] <persia> It's really cool.  If I hold down both mouse buttons, I boot off SD, and if I don't, I boot off SSD.
[22:47] <persia> makes it trivial to install different flavours, etc.
[22:47] <persia> Unfortunately, most of the cool flavours with which I want to play don't exist for Jaunty :(
[22:52] <plars> but at least you know you have an easy way to test it if you (or anyone else) feels like hacking it together :)
[22:54] <persia> Absolutely.
[22:54] <persia> And I'm sure someone will produce a newer kernel someday.
[22:54] <persia> But for some reason, nobody outside Japan seems to be buying these.  I've only enountered one user from elsewhere.
[22:54] <GrueMaster1> Maybe if/when device tree ever hits the streets
[22:54] <persia> So there's almost no English-language sites about it.
[22:54] <persia> GrueMaster1: When that happens, I get a kernel in just a few hours :)