[00:59] <persia> conics.net also ships the NetWalker worldwide
[04:02] <ericnj> Hi guys, is it possible to get armel on Palm Tungsten T3?
[04:07]  * persia checks for specs
[04:08] <persia> ericnj: You might be able to shove 9.04 on it, but nothing newer.  I'd recommend trying to install Debian on that device.
[04:08] <ericnj> where can I get a ready made image,  rootfs?
[04:10] <ericnj> 9.04 is fine for me, just want minimal with light widows manager.
[04:11] <persia> There aren't any images for the Palm Tunsten T3.
[04:12] <ericnj> can I use the instruction on https://wiki.ubuntu.com/ARM/RootfsFromScratch?
[04:12] <persia> The babbage image from http://cdimage.ubuntu.com/ports/releases/jaunty/release/ will have an extractable rootfs for all of desktop (but that might need too much RAM)
[04:13] <persia> Yes.  Those instructions should work fine (you got the URL faster than I)
[04:15] <ericnj> what is the smallest image size I can use on the rootstock?
[04:17] <ericnj> I want to install it on a SD card
[04:19] <persia> I don't know precisely about "smallest".  The buildd minimal chroots are about 60MB after bzip2, so maybe a couple hundred MB?
[04:19] <persia> Try installing the ubuntu-minimal task only, and see what that gets you.
[04:20] <ericnj> Do I have to do it with qemu?
[04:22] <persia> No, but that's easiest.
[04:22] <persia> So, there are two ways to construct a chroot that are fairly easy.
[04:23] <persia> 1) If you have a current Ubuntu armel install, you can use debootstrap.  This may or may not work for some Debian installs, depending on a number of factors.
[04:24] <ericnj> ok, I'm listening
[04:24] <persia> 2) If you have an Ubuntu install on i386 or amd64 (and potentially other architectures, but not well tested), you can use rootstock to run debootstrap in an emulated environment.
[04:24] <persia> There are, of course, N other ways, but neither is as easy as those.
[04:25] <ericnj> can you send me some instruction on my e-mail?
[04:25] <ericnj> I'm a noobie
[04:25] <persia> What sort of instruction, and for which path?
[04:26] <persia> and I'd much prefer to work with you interactively to sort it, rather than trying to write some customised documentation..
[04:26] <ericnj> I understand
[04:26] <tkmedia> yes and others may bennefit from it
[04:27] <persia> That too :)
[04:27] <tkmedia> ;)
[04:28] <ericnj> I've tried the instructions on the above page and that's what I've got at the end of my log file: Reading package lists... 99%  Reading package lists... Error!  E: Unable to write mmap - msync (28 No space left on device) E: The package lists or status file could not be parsed or opened. Kernel panic - not syncing: Attempted to kill init! I: Killed ...
[04:28] <persia> That usually means you need to pass a larger value to --imagesize
[04:29] <tkmedia> if if setup ubuhntu-armel I should be able to debbostrap lenny right ?
[04:29] <persia> tkmedia: That *should* work, but it's not well tested.  There is a small chance that there are some internetworking issues that could be exposed.
[04:30] <ericnj> thanks, I'll try that
[04:30] <tkmedia> k
[04:30] <persia> tkmedia: If you are up for testing and reporting any bugs, that would be great.  I'd much prefer if we could support that use case.
[04:31] <tkmedia> can i setup ubuntu-armel in kvm by chance ?
[04:32] <Martyn> ??
[04:32] <Martyn> I thought there was zero KVM support in armel.
[04:32] <Martyn> There's no hardware support for hypervisor functions...
[04:33] <Martyn> (TrustZone doesn't provide the right kinds of abstraction)
[04:33] <persia> tkmedia: You can't in kvm.  You can in qemu-kvm.  I personally use `mk-sbuild --arch=armel lucid` to create build chroots (works in lucid)
[04:34] <persia> tkmedia: Also, read https://wiki.ubuntu.com/ARM/RootfsFromScratch for richer instructions on getting something running in real qemu, rather than just a chroot.
[04:34] <tkmedia> yep tried that
[04:34] <tkmedia> unfortunately i have arm 4
[04:35] <persia> Then you can't run Ubuntu anyway.
[04:35] <tkmedia> hence then lenny deboostrap question
[04:36] <persia> aha!
[04:36] <persia> You might do better to try to port rootstock to work also with Debian, and then just build your Debian rootfs directly.
[04:36] <tkmedia> am i way off
[04:37] <persia> No, but I think you're doing it the hard way :)
[04:37] <tkmedia> k
[04:37] <tkmedia> what else is new
[04:37] <tkmedia> if there is a hard way ... i seem to find it
[04:38] <tkmedia> i guess i should jkust suck it up and build a qemu
[04:38] <persia> tkmedia: What are you trying to accomplish as an end goal?
[04:39] <tkmedia> but i have proxmox and it makes kvm soooo easy
[04:39] <tkmedia> good question
[04:39] <tkmedia> dev environtment under lenny iguess
[04:39] <tkmedia> ARM 4
[04:39] <persia> kvm doesn't deal well with cross-architecture things.  Works *great* for i386/amd64/powerpc as long as the guest architecture matches the host architecture, but that's not usually the case here.
[04:39] <persia> tkmedia: What hardware?
[04:40] <tkmedia> samsung 9
[04:40] <tkmedia> mini2440
[04:41] <tkmedia> 7-10 touch screen
[04:41] <tkmedia> maybe a cortex board is better
[04:41] <tkmedia> ?
[04:42] <tkmedia> wall mount
[04:43] <persia> If you're just looking for an electronic picture frame, a newer board is a waste of power.
[04:43] <tkmedia> http://www.friendlyarm.net/products/mini2440
[04:44] <persia> http://code.google.com/p/mini2440/wiki/EmdebianChroot might be a reasonable place to start.
[04:45] <tkmedia> yep i keep ending up back there
[04:45] <tkmedia> so iguess i should stop fighting that
[04:46] <persia> It oughtn't be that hard to generalise the emdebian instructions to work with Debian proper.
[04:46] <persia> Also, rootstock would benefit from growing the ability to also create Debian rootfs artifacts.
[04:47] <persia> But if you just want it to work today, the emdebian instructions are probably fastest.
[04:47] <tkmedia> I have been tainted by the M$ world
[04:48] <tkmedia> so my mind needs reprogramming
[04:48] <tkmedia> and VB by day doesnt help
[04:49] <persia> Martyn: Just for completeness sake: 9.04 supported ARMv5, 9.10 supported ARMv6, and 10.04+ is ARMv7.
[04:49] <tkmedia> is rootstock script based ?
[04:50] <persia> Also, there were no formal Ubuntu releases of armel prior to 9.04 (although the mojo project had good stuff for several releases from cross-compilation)
[04:50] <Martyn> persia : Thanks for the clarification
[04:50] <persia> tkmedia: https://code.launchpad.net/project-rootstock is the best place to check.
[04:50] <tkmedia> k
[04:50] <tkmedia> thanks
[04:50] <persia> Martyn: Thanks for steering now3d in the right direction :)
[04:51] <Martyn> persia : I had a complete 8.04 system built for/from ARM itself, but that was before the release of the Cortex-A8... more a proof of concept than anything supported
[04:51] <persia> Not the mojo stuff?
[04:52] <persia> ( mojo.handhelds.org )
[04:52] <Martyn> nope, not the mojo stuff
[04:52] <Martyn> in fact, a lot of it was compiled with the CodeSourcery toolchain, inside of ARM.   It predates all the nice root filesystem tools too...
[04:53] <Martyn> Which, for the record, rock my world.
[04:53] <Martyn> rootstock = FTW
[04:54] <persia> rootstock is very nice indeed.
[04:54] <persia> But yeah, that sounds like a special thing.  Not something I'd heard about before.
[04:58] <Martyn> It was, but it was also fun
[04:58] <Martyn> And these days I'm still working on getting Lenny working as an arm server
[04:58] <Martyn> so much that we discussed at UDS has been abandoned
[04:58] <Martyn> No Device Tree
[04:58] <Martyn> no software boot
[04:59] <Martyn> and there's no point in even trying to get an official arm server build...
[04:59] <persia> Hrm?
[04:59] <persia> What's http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/
[04:59] <persia> Looks like two armel server builds to me.
[05:00] <persia> DeviceTree just didn't get finished in time, from what I heard.
[05:00] <persia> And mukluk needs love, but there's been persistent bugs about kexec() issues, which I believe are finally just getting sorted (but too late for lucid).
[05:00] <Martyn> Yep.  Grant is working really hard
[05:00] <Martyn> but the patches are only just now starting to flow
[05:00] <persia> Yeah, all credit to him.  It's just a matter of timing against the 6-month cycle.
[05:01] <persia> Based on what I hear, I have a feeling that we might be able to get that for the next cycle.
[05:01] <Martyn> yep
[05:01] <Martyn> and that's kind of critical for smooth-stone chips
[05:01] <Martyn> device tree will make booting our SoC much, much easier
[05:02] <tkmedia> hmm ps3 install
[05:02] <persia> Make booting *everything* easier.
[05:02] <persia> tkmedia: -> #ubuntu-powerpc :)
[05:02] <tkmedia> anyone try that?
[05:03] <tkmedia> is it virtual
[05:03] <tkmedia> it runs intheir hypervisor right ?
[05:04] <persia> Martyn: Have you been testing the DT stuff in your kernels?  Do you know what we need to tweak in image builds to make it just work?
[05:04] <tkmedia> or can you take full advantage of the hardware?
[05:05]  * tkmedia is off to read up
[05:05] <Martyn> no, I'm not touching the DT stuff at _all_
[05:05] <Martyn> Right now, I'm porting linux to specifications, since we don't have a test chip built .. and RTL runs 8 million times slower than the actual processor
[05:06] <persia> 8 million!  So you get, what, about 1.5KHz?
[05:07]  * persia can't do math, and gives up.
[05:09] <Martyn> no, 200Hz
[05:09] <Martyn> 300 if the simulation is run on a very, very fast nehalem (3.2Ghz or better)
[05:09] <persia> Ouch!
[05:09] <Martyn> multicore isn't yet supported by anyone for RTL sim
[05:10] <Martyn> so you basically are running unicore
[05:10] <Martyn> (that's being addressed, but a lot of this kind of thing CAN'T be run parallel)
[05:10] <persia> Right.
[05:10] <persia> So if DT gets far enough to land in lucid+1, that actually works for you.
[05:10] <Martyn> yep
[05:11] <Martyn> One of my workmates (JAson Hobbes - n3onfr3on) is working on that part
[05:11] <persia> Also, have you tested the server images at all?  I don't know that they are getting enough testing, but I suspect they ought get some.
[05:11] <Martyn> since he's writing the bootloader
[05:11] <persia> (and it was your spec that made them happen)
[05:11] <Martyn> I can't test them .. while they are built for v7a, my kernels don't properly support thumb2 yet
[05:12] <persia> I thought you had a Lange
[05:12] <Martyn> because I'm running in FastModel
[05:12] <Martyn> Yeah, I have a lange board .. but I don't have the debug cable
[05:12] <Martyn> I need to get that from ojn before I can reconfigure u-boot
[05:12] <Martyn> lange 5.1 even
[05:12] <persia> Oh right, I remember now.  Sorry for the reminder of the pain.
[05:12] <Martyn> in fact, I'd like to try the -desktop- build on the lange 5.1
[05:13] <persia> That's been dropped.  THe only images being built are Ubuntu Netbook, Kubuntu Netbook, and Ubuntu Server.
[05:13] <persia> Not to say you can't create one, but images just aren't being built.
[05:14] <Martyn> yep
[05:14] <Martyn> I can use the server image, and apply most of what's needed to get desktop
[05:15] <persia> Just preseed a late-command to install the ubuntu-desktop task, and you can do it in one shot.
[05:16] <Martyn> yep
[05:16] <persia> Although netinstall images might be better for that use case, because most of the server pool is uninteresting for desktop.
[05:16] <Martyn> but, for now the lange sits on my desk unused
[05:16] <Martyn> the versatile2 gets a lot more attention
[05:16] <persia> Waiting on ojn :)
[05:16] <Martyn> even if it is just a 400Mhz Cortex-A9
[05:16] <persia> That's not bad at all.
[05:37] <DanaG> interesting... device-tree coming to ARM?
[05:39] <persia> DanaG: Indeed.  The idea is to move from kernel-per-board to kernel-per-SoC by using DeviceTree to handle board-level variations.
[05:40] <DanaG> hmm, how would it handle different memory locations?
[05:40] <persia> And this is critical from a distribution POV, as it means we can actually support N devices.
[05:40] <persia> How do you mean?
[05:40] <DanaG> ah, that's the per-SOC part.
[05:40] <DanaG> Same SOC will have same memory layout for at least main RAM.
[05:40] <persia> Oh, yeah.  Moving from per-SoC to per-architecture will require an entirely different level of cooperation
[05:41] <DanaG> First time I'd used Device-Tree was with Microblaze.... that was an exercise in broken tools.
[05:43] <persia> If you've experience working with it, and want to help make it happen (to avoid the broken tool situation), please track followups to http://www.kernel.org/doc/ols/2008/ols2008v2-pages-27-38.pdf
[05:44] <persia> git://git.secretlab.ca/git/linux-2.6 test-devicetree seems another good source
[06:06] <DanaG> what I mean by broken tools, is things like a cross-compiler, that, when trying to build, segfaults the host compiler. =þ
[06:08] <persia> Ugh.  Yet another argument against cross-compilers.
[06:10] <DanaG> Yeah, I thought that was comically bad -- I mean, I don't even see how you could make a compiler segfault.  Really bad code? =þ
[06:13] <persia> ICE isn't hard to achieve if one takes the effort.
[06:13] <persia> THis is unfortunate, but the nature of developing tools.
[06:59] <tkmedia> what do you guys think of the smart Q7
[07:02] <persia> tkmedia: It's too big :)  Also, it can't run lucid (ARMv6)
[07:02] <GrueMaster> persia: I thought lucid was armv7?
[07:03] <GrueMaster> (or are you referring to the smart?
[07:03] <persia> GrueMaster: SmartQ7
[07:03] <GrueMaster> ah
[07:04] <persia> They ship with something based on jaunty, but I *think* they could be upgraded to karmic if someone uses a custom kernel.
[07:04] <persia> I'm fairly certain they can't run lucid.
[07:04] <persia> (although SmartDevices may well come out with another generation, and the price is certainly right)
[07:14] <ethana2> hello, from my Droid
[13:38] <asac> JamieBennett: gave you a RC  bug so we can upload in freeze: bug 537356
[13:38] <ubot4> Launchpad bug 537356 in webservice-office-zoho (Ubuntu Lucid) (and 1 other project) "application menu entries dont do anything (affects: 1)" [High,Triaged] https://launchpad.net/bugs/537356
[13:42] <asac> xserver with imx fallback patch is about to finish building ;)
[13:43] <JamieBennett> asac: thanks :)
[13:43] <ogra> wohooo
[13:44] <ogra> asac, now it just needs proper EDID detection :)
[13:44] <asac> ogra: the current solution is quite good enough i think ;)
[13:44] <persia> Well, depends on one's monitor
[13:44] <ogra> i want my 1900x1002 !
[13:44] <asac> oh edid
[13:44] <asac> yeah
[13:44] <ogra> *1200
[13:44] <asac> ogra: how is that done?
[13:45] <ogra> no idea i have to look into it, it wasnt ready in the old driver i have around here
[13:45] <asac> well its not ready here either
[13:45] <asac> but maybe its just a code fix ;)
[13:45] <ogra> but i think its already done when the fb device inits
[13:45] <asac> hmm on init feels wrong
[13:45] <asac> monitor might get plugged in/out swapped etc.
[13:45] <asac> xrandr should tell us better info ;)
[13:46] <ogra> xrandr is after EDID
[13:46] <ogra> iirc
[13:46] <asac> ok i will check that
[13:47] <asac> sure xrandr hopefully just reflects what EDID gave us
[13:47] <asac> or gives us (when mohnitor changes)
[13:47] <persia> I was under the impression xrandr wasn't available based on the snipped of the log that was pasted yesterday.
[13:48] <ogra> fbcvt: 1024x768@60: CVT Name - .786M3
[13:48] <ogra> thats what i have in dmesg
[13:48] <ogra> xrandr is available but only with a handfull of default resolutions
[13:48] <ogra> up to  1024x768
[13:48] <asac> ack
[13:49] <asac> at least it detects for me its a lcd with proper subpixel
[13:49] <ogra> and we dont know if resolution changing works yet
[13:49] <asac> cant you try lower resolution in fbdev?
[13:51] <ogra> you can try setting modelines with fbset
[13:52] <ogra> and you can indeed add modelines in xorg.conf
[13:52] <ogra> if xranbdr works you should even be able to use modelines there to add new modes
[13:56] <NCommander> dmart: ping?
[13:57] <dmart> NCommander: hi there
[13:57] <NCommander> dmart: sorry I missed you yesterday
[13:57] <dmart> no probs; just wondering what our next steps should be on OOo
[13:57] <NCommander> dmart: funny, I was going to ask you the same thing :-)
[13:58] <NCommander> dmart: I retested karmic gcc-4.3 + jaunty binutils, and got a working uno from fresh sources
[13:59] <ogra> NCommander, did you talk to doko btw, i think he did all these varaition tests already
[13:59] <ogra> he should have a test matrix for what combo works and which one doesnt
[13:59] <NCommander> ogra: I talked to him earlier, but he didn't say anything about that. I'll make sure to ask him for that
[14:00] <ogra> i tested a *ton* of different builds he did
[14:00] <ogra> each with a different combo of gcc and binutils
[14:00] <NCommander> ogra: I'll ping him
[14:01] <NCommander> ogra: that's good to know. I just wish it was on the bug :-/
[14:01] <NCommander> dmart: TBH, I'm kinda out of ideas on this one.
[14:01] <NCommander> dmart: we know what appears to be the base underlying cause for the OOo boom
[14:01] <NCommander> but I don't really know how to fix it, or how to even rewrite the ASM snippet to be less evil
[14:03] <ogra> NCommander, just build it with --no-uno-crash
[14:03] <ogra> ;)
[14:03]  * NCommander whacks ogra
[14:03]  * NCommander feels better
[14:03]  * ogra feels short now
[14:04] <persia> So, about OO.o.
[14:05] <persia> From what I saw recently, I thought we knew what changes to the toolchain were providing what extra bits that caused which problems.
[14:05] <persia> Was the .eh... issue resolved or still open upstream?
[14:05] <persia> Or did someone confirm this wasn't really the issue?
[14:11] <NCommander> dmart: I'm not even sure what to bring to OOo upstream about this, from there perspective, it looks like a pure toolchain bug
[14:21] <dmart> NCommander: the problem file had some maintainers' names -- have you tried to contact them?  I think the first thing is to understand from them what the code is trying to do, and explain our concerns about why it looks incorrect.
[14:22] <NCommander> dmart: no, I haven't
[14:24] <dmart> I can draft a mail if you like.
[14:28] <dmart> oooh
[14:28] <dmart> hang on a moment
[14:30] <dmart> NCommander: did you look at this?: http://pastebin.ubuntu.com/393294/
[14:31] <NCommander> dmart: I smell magic in that file
[14:31] <NCommander> deep scary magic
[14:31] <dmart> Ummm, yeah
[14:31] <dmart> The two first *p++ poke ARM instructions into memory
[14:31] <dmart> > mov r12, pc
[14:32] <dmart> > ldr pc, [pc, #4]
[14:32] <dmart> This explains why privateSnippetExecutor assumes there is something in ip (r12)
[14:32] <NCommander> dmart: I think my crack fuse just burt out :-/
[14:33] <dmart> I guess it's used to look up the functionIndex and vtableOffset values which get poked
[14:34] <NCommander> dmart: there is no guarette thats going to laid out like that in memory though, or with no padding and stuff done
[14:36] <NCommander> dmart: actually, it could have been the move to ARMv6 that might have brokened it in the first place since that removed the strict algnment access requirements
[14:36] <NCommander> (not sure, but a possible theory)
[14:40] <dmart> Hey ramana
[14:40] <dmart> I know what's in ip (ish)
[14:41] <dmart> It contains the pc value in a trampoline used to read the destination vtable offset and function index, see http://pastebin.ubuntu.com/393294/
[14:41] <dmart> ...or at least it would contain that if any version of the linker ever provided a guarantee
[14:41] <NCommander> dmart: on a scale of 1-10, how high is the crack factor of what OOo is doing here?
[14:42] <NCommander> dmart: but privateSnippetExecutor works
[14:42] <NCommander> dmart: thats been previously tested, and works as expected
[14:42] <persia> Shouldn't it not work as expecting, as with all the mov *,pc stuff?
[14:43] <dmart> The linker is allowed insert trampolines for function calls, which are permitted to corrupt ip.  The chance of this happening is pretty low, but it's not "safe"
[14:43] <dmart> I think the code in question will get executed as ARM, and the way it branches it interworking-compatible.
[14:44] <dmart> ...anyway, I don't think this code is failing, it's just a bit scary
[14:44] <NCommander> dmart: bit?
[14:44] <NCommander> dmart: ugh, I just realized something nasty
[14:45] <NCommander> dmart: part of the ASM instructions exist outside the .S (as the hex magic)
[14:45] <NCommander> dmart: so even if we add unwind table entries, ther're not going to properly "mesh"
[14:46] <dmart> Because the trampoline generated by privateSnippetExecutor only trashes ip, it might not need any unwind info... but I'm not the expert on this
[14:47] <dmart> Also, I think no exception can occur in the trampoline itself, because it calls no functions except for jumping to privateSnippetExecutor
[14:48] <NCommander> dmart: thats not the problem, the problem is libgcc bails out because on CANTUNWIND segments (in theory)
[14:48]  * dmart is grepping the OOo source to try and work out where this code gets called from, but it will take a while
[14:48] <johannes_> cortex a9 processor seems to be the fastest and most fitting processor for a small client with gui, does someone know where I can buy a mainboard with this cpu?
[14:48] <ynezz> nvidia tegra2
[14:49] <dmart> johannes_: I've seen Ubuntu at least Ubuntu karmic working on tegra2
[14:49] <NCommander> dmart: uno2cpp.cxx only
[14:49] <NCommander> dmart: same folder
[14:49] <dmart> NCommander: I mean, where the functions codeSnippet and flushCode in uno2cpp.cxx are called from...
[14:49] <ynezz> johannes_: http://tegradeveloper.nvidia.com/tegra/
[14:49] <NCommander> dmart: if you read the UNO CPP code, your mind will release itself from mundane concerns as the horror of it takes over
[14:50] <johannes_> thanks Ill have a look at tegra2
[14:50] <NCommander> dmart: ah. theres a porting uno guide you might want to look at
[14:50] <dmart> Oh, where?  That sounds useful
[14:50] <NCommander> dmart: http://wiki.services.openoffice.org/wiki/Lazy_Hackers_Guide_To_Porting - skip to the first part of Hard Bit
[14:51] <NCommander> dmart: it deals with how the HPPA port was done.
[15:02] <johannes_> mhm bei tegra2 finde ich nur dinge, wie tablet pcs, ich suche aber nach etwas, wie dem beagleboard nur mit einem oder mehreren Cortex A9
[15:03] <ogra> johannes_, i dont think they are freely sold yet
[15:03] <persia> One needs to apply.
[15:03] <johannes_> oh sry for writing in german
[15:03] <ogra> macht nix :)
[15:04] <persia> johannes_: Are you looking to build something, or do you want a shipping device?
[15:04] <johannes_> I thought about a fileserver with a quadcore Cortex A9 as I read some articles it would have a lot of power
[15:05] <johannes_> I want to build something for myself
[15:08] <ynezz> tegra is dual core "only"
[15:09] <ogra> yeah, lame, isnt it ? :P
[15:09] <johannes_> but there are processor on it, I dont need, 3d graphics for example
[15:09] <johannes_> and I couldnt find a mainboard yet
[15:09] <ynezz> it's too hot
[15:10] <ynezz> you can't even buy it in Europe
[15:10] <persia> I've not seen any bare mainboards except for "development boards".
[15:10] <persia> Most stuff seems to be inside devices.
[15:10] <johannes_> thats sad
[15:11] <ogra> http://www.dlink.com/boxeebox
[15:11] <ogra> that will use a tegra2
[15:11] <ogra> i read somewhere
[15:11] <ynezz> but who knows when they start shipping it out :)
[15:12] <persia> Real Soon Now
[15:12] <ynezz> hm, good
[15:12] <persia> heh
[15:13] <persia> That's why I like the devices I *know* are shipping.
[15:13] <persia> We can get them today.
[15:13] <ogra> well, just hit the fast forward button ...
[15:14] <persia> One of those several-month retreats?
[15:14] <ogra> heh, yeah
[15:15] <johannes_> a question in general: would a quadcore Cortex A9 actually be powerful enough to support: mdadm raid 5, trunked Gigabit Ethernet, 2 HDTV tuner cards (for a vdr backend without decoding)?
[15:16] <ogra> if you find HDTV cards that fit into any ARM device ...
[15:17] <ogra> are there HD USB tuner cards ?
[15:17] <johannes_> size doesnt matter, it is only about power consumption
[15:17] <johannes_> some but most are pcie or pci
[15:17] <ogra> right, PCI is rare on ARM boards
[15:17] <ogra> sockets at least
[15:18] <persia> There are USB HD DTV devices.
[15:18] <johannes_> mhm I guess I was a bit naive, thinking I could simply change my opteron board with a armsystem
[15:19] <persia> Well, there exist a few boards with PCIe, but nothing running those chips I've seen
[15:19]  * persia has PCIe on an orion board
[15:19] <ogra> there will surely be some server boards with a9 chips *soon*
[15:19] <johannes_> what do you mean by soon?
[15:19] <ogra> those would have PCIe i assume
[15:20] <ogra> johannes_, within the next 254 months ?
[15:20] <persia> Maybe.  Maybe PCIx
[15:20] <ogra> err
[15:20] <ogra> 24 :)
[15:20] <persia> No, 254 is definitely correct.  24 is a bet.
[15:20] <johannes_> mhm better than 254, but still a long time
[15:20] <ogra> no idea ... i dont know how many companies wortk on server boards
[15:21] <ogra> but a9 are definately somehting thats intresting for datacenters
[15:21] <johannes_> When ubuntu is installed on an arm system, can I use all the programs, that are available for x86 ubuntu too?
[15:21] <persia> johannes_: I suspect that what you want is a next-generation NAS box (for the raid), with the HDTV USB bits plugged in the back.
[15:21] <persia> This wouldn't be building it yourself, but is probably the earliest purchase option.
[15:22] <persia> johannes_: There's a couple hundred packages that don't work right now, but we try to get that as close to zero as we can.
[15:22] <ogra> johannes_, yes, the majority works on arm as on x86
[15:22] <johannes_> I would prefer if it was still more pc than NAS, as I like to try things out with linux
[15:22] <johannes_> that sounds great
[15:23] <johannes_> what about drivers? (for tuner cards) can they simply be installed or do I need special ones?
[15:23] <persia> johannes_: The difference between a "Small form factor PC" and a "NAS box" is a USB keyboard and a USB Display module :)
[15:24] <ogra> johannes_, as long as there are linux drivers they should just work
[15:24] <persia> For USB tuner cards, the same drivers should work for any architecture.  For other tuners, you may need to do some tweaking.
[15:24] <suihkulokki> johannes_: openrd board comes with one PCIe slot
[15:24] <johannes_> I look it up
[15:24] <ogra> suihkulokki, but can the CPU do HD processing ?
[15:25] <ogra> though its a backend ... probably thats not actually needed if the card is powerful
[15:25] <suihkulokki> ogra: didn't he say we won't do decoding ?
[15:25] <persia> suihkulokki: That's the ARMv5 chip that's in the SheevaPlug, right?
[15:25] <suihkulokki> persia: which is good enough for the usecase.
[15:25] <persia> Absolutely.  Just wanted to confirm my reading.
[15:25] <ogra> suihkulokki, well, recording and streaming i guess
[15:26] <johannes_> basically streaming only
[15:27] <suihkulokki> oviously thing like recompressing streams or analyzing + cutting out ad breaks is out of question with any arm cpu
[15:27] <NCommander> dmart: *sigh*, how best do we draft this email?
[15:30] <dmart> I will look a bit more and then send you something...  But I think the code in armhelper.s is a fairly straightforward trampoline in which case the solution might not be too complicated.  Too early to say though...
[15:32] <tkmedia> how about using a network tuner like hd homerun
[15:34] <ogra> i think thats only DVB-T
[15:34] <ogra> there are no german HD channels over DVB-T
[15:34] <tkmedia> k
[15:34] <ogra> (assuming johannes_ is german after he spoke german here :) )
[15:35] <persia> wikipedia claims there are 4 modles of which only one is DVB-T
[15:35] <tkmedia> I use the US version
[15:35] <ogra> persia, the german version is DVB-T only afaik
[15:36] <persia> Ah.
[15:38] <johannes_> yes, I am german and thing is: I already got myself a skystar hd2 for the server I am using right now
[15:44] <dmart> NCommander, ramana: The code which looks interesting is in:
[15:44] <dmart> bridges/source/cpp_uno/shared/vtablefactory.cxx
[15:44] <dmart> bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
[15:45] <dmart> bridges/source/cpp_uno/gcc3_linux_arm/armhelper.s
[15:45] <dmart> (if you want to look and didn't already look at one of those)
[16:23] <dmart> NCommander: hi again
[16:24] <lool> dmart: Yes, that's the uno2cpp bridge, and it's what upstream told me was likely broken
[16:25] <NCommander> dmart: hola again
[16:25] <dmart> Hi there... I was just chatting for ramana and matt
[16:26] <dmart> We now understand better what privateSnippetExecutor is doing
[16:26] <dmart> and we think we have a fix: http://pastebin.ubuntu.com/393376/
[16:26] <dmart> (i.e., delete 2/3 of the function :P )
[16:26] <NCommander> dmart: O_o;
[16:26] <lool> dmart: Amazing!
[16:27] <NCommander> that will be one hell of a fix if it works
[16:27] <dmart> This may just expose the next bug :/
[16:27] <dmart> Could you give it a try?
[16:27] <ogra> haha
[16:27] <dmart> My OOo build will take some more days to finish...
[16:27] <ogra> funny fix :)
[16:27]  * dmart admits that we did change a couple of lines as well as deleting some
[16:28] <persia> !ohmy
[16:28] <ubot4> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
[16:28] <NCommander> dmart: incremently building, please stand by
[16:29] <NCommander> persia: where was the language violation?
[16:29] <dmart> Basically, the unwinder doesn't need to see this function at all if we tail-call optimise it (i.e., just jump to cpp_vtable_call and let it worry about the return)
[16:29] <ogra> persia, if i would mention it in a religious context would you also "ohmy" me ?
[16:29] <persia> ogra: No.
[16:30] <ogra> so why do you do it in this context ?
[16:30] <persia> (but if I don't ohmy people in #ubuntu-* I may get chastised by those who oversee me keeping the channels open)
[16:30] <NCommander> dmart: we MAY have a winner
[16:30] <NCommander> stand by
[16:30] <persia> ogra: IRC guidelines for #ubuntu-*.  I don't personally really care, but I like having IRC channels :)
[16:31] <dmart> Ummm, actually, who was the ohmy for?  If no-one can tell it will just cause confusion...
[16:31] <ogra> thats a pretty silly rule
[16:31] <ogra> dmart, <NCommander> that will be one hell of a fix if it works
[16:31] <ogra> (risking another ohmy)
[16:32]  * dmart kpees smoe fngries cssoerd but it mkeas it hrad to tpye
[16:32] <ogra> heh
[16:33]  * persia should get better at passing | to the bot
[16:33] <dmart> NCommander: it would also be interesting if you can shove this patch into your current working distro+libs+OOo combination and see whether it breaks anything
[16:34] <dmart> If not, pushing the patch is a no-brainer because is provides some cleanup, and also will avoid the risk the current code has of an incoming signal corrupting the stack
[16:34] <NCommander> dmart: buildingnow
[16:34] <NCommander> (with g++ 4.4/binutils 2.20)
[16:35] <dmart> =lucid?
[16:35] <NCommander> dmart: kmaric
[16:35] <dmart> Oh, right
[16:35] <NCommander> ladies and gentleman
[16:35] <NCommander> IT WORKS!
[16:35] <lool> \o/
[16:35] <NCommander> (also tested on lucid)
[16:35] <ogra> well, try lucid
[16:35] <ogra> hooray !!!!
[16:35]  * lool thinks the ARM folks deserve some Champagne
[16:35] <dmart> Ooo works, or just builds?
[16:35] <NCommander> dmart: works
[16:36] <dmart> Wow, cool :D
[16:36] <ogra> lool, free beer for dmart and his team for the whole UDS i'D say !
[16:36] <NCommander> ogra: +1
[16:36] <dmart> What, I have to wait till then :(
[16:36] <NCommander> dmart: we don't have beer transport over IRC
[16:36]  * ogra send some virtual beer right now
[16:36] <NCommander> dmart: how'd you figure out to reduce armhelper.s to what it is now?
[16:36] <lool> Someone uploads to lucid?
[16:36]  * NCommander quite envious to cracked this so quickly
[16:36] <ogra> *german* beer
[16:36] <dmart> Save some for ramana and matt, this was definitely a collaborative effort
[16:37] <NCommander> free beer for anyone who touched this bug
[16:37] <ogra> dmart, so i hope we'll see them in brussels
[16:37] <NCommander> lool: someone has to dump it into ooo-build upstream. OOo in lucid has no patch system of its own
[16:37]  * NCommander goes to grab ccheney
[16:37] <ogra> NCommander, heh, then i'd get the most beer, i filed it :P
[16:37] <ogra> touching really doesnt count :)
[16:38] <NCommander> ogra: we can just make david file it as expense. Brain damage remover!
[16:38] <dmart> NCommander: looking at the call too privateSnippetExtractor, we observed that it does nothing after the call to cpp_vtable_call, except to tidy up a stack frame which is only needed at all because it was set up
[16:38] <dmart> ...so we just branch to cpp_vtable_call.  cpp_vtable_call's return later goes straight back to the original caller.
[16:39] <NCommander> dmart: thats clever
[16:39] <lool> It's basically a jump trampoline I guess
[16:39] <dmart> Because there's no return address on the stack pointing into privateSnippetExecutor, the unwinder doesn't need to know about it at all
[16:40] <NCommander> dmart: so the unwinder was the root cause of the problem, and you just made privateSnippetExecutor disappear?
[16:40] <dmart> When an exxception occurs, the unwinder saw that there was a pending return into privateSnippetExecutor, but didn't know how to unwind that function
[16:41] <dmart> But since no state needs restoring anyway, we can have the unwinder skip it completely simply by not returning to it.
[16:42] <NCommander> dmart: wow. thats clever
[16:42]  * NCommander feels humbled
[16:42] <NCommander> ^in the precense of greatness
[16:47] <asac> dmart: you guys fixed it?
[16:48] <persia> asac: That's the theory : we have to do the upload / builder / install dance to 100% verify.
[16:49] <asac> yep
[16:49] <asac> NCommander: patch attached to bug? ooo target opened?
[16:50] <NCommander> asac: I just poked ccheney to add it to ooo-build
[16:50] <asac> yeah saw in -deesktop
[16:50] <asac> dmart: plenty of kudos to whoever was involved in this!!
[16:52] <dmart> Since we don't really understand OOo, I don't understand much about exceptions and we couldn't debug or test this locally, I'll certainly be happy if it works ;)
[16:52] <dmart> I passed on the good news to ramana and matt here
[16:55] <NCommander> dmart: lets call it a successful joint effort between Canonical-ARM in futhering the position of ARM on the desktop. Regardless, this wouldn't have been possible without you, ramana and matt :-)
[16:57] <dmart> Well, the OOo community might have fixed it, but it's harder to persuade upstreams to undertake that when we're not sure whether the real problem is a tools issue or something else.
[16:58] <lool> dmart: the arm port isn't actually upstream, it's a fedora patch
[16:58]  * dmart anticipates a shiny new .deb to confirm all this
[16:58] <NCommander> lool: its partially upstream, but not considered a priority by OOO as far as I can tell
[16:58] <NCommander> half of it is in their CVS, the other half is in ooo-build
[16:59] <dmart> Anyway, hopefully they'll accept the patch without problems; it cleans up some code if nothing else.
[16:59] <dmart> ...and we still think the old code wasn't signal-safe
[17:01] <dmart> ramana: take a bow :)
[17:02] <ogra> *clap* *clap* *clap* *clap* *clap* *clap*
[17:02] <ogra> :)
[17:05] <ramana> Thanks but the credit is actually due to Matt and the others in the team who spotted the differences with respect to the frame.
[17:05] <dmart> Well, it was a shared effort...
[17:06] <dmart> NCommander: thanks to you too
[17:06] <lool> dmart: Oh I'm sure the maintainer of that piece of code will welcome it heartily
[17:06] <NCommander> dmart: I just figured out how build the beast
[17:06] <lool> I'm pretty sure it's going to hit the next RHEL and I think they care about the ARM port there
[17:08] <armin76> thanks to me too!
[17:08] <dmart> ;)
[17:09] <dmart> mgretton: quick, take some credit before it's all gone!
[17:19] <Who_> ogra: ping - I've got an issue with building from rootstock and the wiki says to come and talk to you...
[17:19] <ogra> whats the issue ?
[17:22] <Who_> ogra: I'm using a Lucid VM to build a lucid image, and it got as far as unpacking libglibmm but has been hung for the last two (ish_) hours after outputting the message 'udevd[45]: specified user 'usbmux' unknown'
[17:22] <Who_> that message is there three times
[17:22] <ogra> yeah, known bug (and no fix yet)
[17:23] <ogra> bug 532733
[17:23] <ubot4> Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/532733
[17:23] <Who_> ogra: so for now, there's not a way to build a lucid image that requires libglibmm?
[17:23] <Who_> ogra: thanks
[17:23] <ogra> Who_, build an image with ubuntu-minimal for now, then just apt-get install waht you need on real HW
[17:24] <ogra> minimal definately works
[17:24] <Who_> ogra: yep - I was just modifying my script :)
[17:24] <Who_> ogra: do you know much about sound on Beagle/IGEP?
[17:24] <ogra> its some mystical qemu issue i'm not able to track down properly
[17:25] <Who_> or can you point me to someone who does?
[17:25] <ogra> no, sadly not, rcn-ee builds the beagle kernel package, he might at least know the kernel side
[17:26] <Who_> ogra: it doesn't seem to be kernel related: I've got an 9.04 image (shipped with device) that has working sound and my 9.10 rootstock (using the same kernel and modules) doesn't work...
[17:26] <ogra> NCommander, so since you like to dig into the odd bugs ... i'm lost on bug 532733, probably you have any ideas
[17:26] <ubot4> Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/532733
[17:26] <NCommander> dmart: what do we want to call teh patch?
[17:26] <ogra> Who_, try to create an audio group and add your user to it
[17:27] <persia> NCommander: dmart: Also, to whom should be given author attribution?
[17:27] <Who_> ogra: also, while I'm thinking about it... I made this for myself: https://launchpad.net/rfsm - I don't know if it is of any interest more generally - but if there's now a good way to tie it in to the rootstock system I should look at doing that... (I notice rcn-ee seems to be using a --script command)
[17:28] <ogra> Who_, rootstock in lucid has the --script option
[17:29] <ogra> Who_, even the new gui has the option to select a post install script :)
[17:30] <Who_> ogra: okay, I'll try and tie in with that
[17:31] <Who_> ogra: also, audio group already exists. I'll keep digging on the sound issue
[17:31] <dmart> NCommander: How about "privateSnippetExtractor simplification to avoid exception unwind failures and stack corruption risk" ?
[17:32] <dmart> or
[17:32] <dmart> "privateSnippetExtractor simplification to avoid exception unwind failures and stack corruption risk on ARM"
[17:32] <persia> Ideally we want a name that can also be a filename :)
[17:33] <persia> That looks like a Description: entry for DEP3
[17:33] <ogra>  branch_directly_to_cpp_vtable_call_on_arm.patch
[17:33] <ogra> and dmart's description
[17:33] <persia> Just needs Author: then.
[17:33] <dmart> Yeah, sounds ok
[17:33] <ogra> "the arm guys"
[17:34] <persia> It's supposed to be a person who can grant license for reuse in the project, etc.
[17:34] <persia> silly tort law to work around silly copyright law, etc.
[17:49] <Martyn> I'm going to spend my day porting this: http://community.livejournal.com/openvz/24651.html to Lucid
[17:49] <persia> I think that a bunch of that work was already done
[17:49] <ogra> Martyn, openvz was rejected from the ubuntu kernel
[17:49]  * persia hunts for the bug
[17:50] <Martyn> ogra : I know, but I need to get it working for a demonstration of virtualization on the A9
[17:50] <Martyn> ogra : Rejected or not ...
[17:50] <ogra> then you likely need to maintain your own kernel as well
[17:50] <Martyn> Because OpenVZ is the Path of Least Resistance .. unless you have a suggestion for a better container solution?
[17:51] <Martyn> ogra : I already do ...  the Versatile2 is anything but supported...
[17:51] <ogra> whats versatile2 ?
[17:51] <Martyn> ogra : Quad core a9 platform from ARM .. I showed one off at UDS
[17:51] <Martyn> now generally available
[17:51] <ogra> ah, you call it versatile ?
[17:51] <ogra> heh
[17:51]  * persia can't find the bug
[17:51] <Martyn> That's it's final name "Versatile2"
[17:52] <Martyn> (our internal codename for it is 'crandall')
[17:52] <ogra> i like the internal one more :)
[17:52] <Martyn> persia : If you happen to come across it, ping me : martin@smooth-stone.com
[17:52] <ogra> Versatile makes me thing of qemu which makes me think of underpowered
[17:52] <persia> "Versatile2" is too easy to confuse with the qemu target.
[17:52] <persia> Martyn: I'm not likely to, since I didn't find it in a search.
[17:53] <Martyn> persia : The QEMU target is a simulation of /real/ hardware, called versatile :)
[17:53] <persia> Ah!
[17:53] <ogra> Martyn, which is underpowered as well :)
[17:53] <Martyn> There are various models over time .. Versatile PB, PBX, EB ...
[17:53] <Martyn> (EB is the current generation -- Cortex-A9)
[17:53] <Martyn> ogra : hey, don't scoff at a 400MHz quad core processor.   It's pretty snazzy
[17:53] <ogra> heh, ok ok
[17:54] <Martyn> ogra : And I've already got another, faster platform to play with now too -- tegra2
[17:54] <ogra> i'm waiting for the 1GHz quad cores
[17:54] <ogra> yeah
[17:54] <ogra> i'd love a tegra2
[17:54] <ogra> its the future !
[17:54] <Martyn> ogra : We're targeting 1.6GHz now.
[17:54] <Martyn> ogra : If Global Foundries becomes available to us, the second rev of the chip will be shrunk and probably hit 2.2GHz
[17:55]  * ogra thinks tegra2 will be the direct atom competiotor
[17:55] <persia> Martyn: Based on https://lists.ubuntu.com/archives/kernel-team/2010-March/thread.html I believe there's a git tree, but not a package.
[17:55] <Martyn> it's a nice chip, but has it's .. issues.
[17:55] <ogra> indeed, nvidia built it :)
[17:55] <Martyn> persia : Git tree of a valid, running kernel is enough
[17:55] <ogra> but i'd be willing to live with that drawback :)
[17:55] <Martyn> persia: that would save me -tons- of time
[17:56] <Martyn> ogra : I /need/ 8x PCIe .. and tegra2 doesn't have it
[17:56] <Martyn> only 1x and 4x
[17:56] <ogra> you should really switch your servers to USB
[17:56]  * ogra ducks
[17:56] <Martyn> persia : Looking at the threads, haven't found the mention of openVZ yet
[17:57] <persia> Martyn: Mail Kir for details : I didn't see a git repo listed.
[17:57] <Martyn> done already :)
[17:57] <Martyn> he has patches available for the overo
[17:57] <persia> There you go :)
[17:57] <persia> Cool.
[17:57] <Martyn> http://download.openvz.org/.kir/overo/kernel/
[17:57] <Martyn> 2.6.27 though
[17:57] <ogra> Martyn, "OpenVZ kernel for Ubuntu 10.4"
[17:57] <ogra> ids the thread name
[17:57] <persia> Martyn: If you get it all working, toss it in a PPA :)
[17:58] <persia> Yes, PPAs don't build for armel, but it means that anyone can build it easily from your source.
[17:59] <Who_> rcn-ee: are you there? I've got a sound-on-igep question (I have no sound from aplay, but can by piping to /dev/dsp) and I'm making very little headway with just my head and Google.
[18:00] <Martyn> persia : You got it
[18:00] <persia> Martyn: Thanks.
[18:00] <Martyn> persia : although if it's integrated into Lenny, would I still have to build a PPA?  (it's upstream at that point)
[18:01] <Martyn> ojn: You around?
[18:01] <Martyn> (we really need a messaging bot on channel :) )
[18:01] <persia> Martyn: If it's in Lenny, people can grab from there and build, so it doesn't matter.
[18:01] <persia> Martyn: email?
[18:01] <Martyn> mine?
[18:01] <Martyn> martin@smooth-stone.com
[18:01] <Martyn> OH ..
[18:02] <Martyn> heh .. no, because I don't have everyone's email on channel
[18:02] <Martyn> there used to be a note-server capability on chanserv ... you could leave someone a sticky note that would be displayed when they next came on channel
[18:02] <Martyn> sort of like:
[18:02] <Martyn> chanserv, tell <recipient> <message>
[18:02] <ogra> doesnt that still work ?
[18:03] <Martyn> however it's long gone...
[18:03] <ogra> though its nickserv i think
[18:03] <persia> One can use /ms for that, I thnk
[18:03] <persia> (MemoServ)
[18:04] <ogra> ah
[18:04] <ogra> yeah
[18:04] <ogra>  /msg memoserv help ;)
[18:05] <persia> "/ms help" works
[18:05] <ogra>  /msg MemoServ SEND Martyn "get me a tegra2"
[18:06] <ogra> ;)
[18:06] <persia> "/ms send Martyn" is *shorter* and *easier* :p
[18:06] <ogra> tsk ... you embedded folks
[18:07] <ogra> *g*
[18:07] <persia> Me?  Embedded?  No.  I happen to like 3.5-4" laptops, but I want full features.
[18:11] <dmart> http://www.arm.com/products/tools/versatile-express.php
[18:13] <Martyn> Oh!  We have a msgserv again!
[18:13] <Martyn> I had no idea :)
[18:13] <Martyn> me? Embedded?
[18:14]  * Martyn points to the mid-sized tower with a Tegra2 mini-ITX board 
[18:14] <Martyn> It's got 2 sata drives, a DVD burner, but is using the integrated graphics .. and a whole -2GB- of memory
[18:14] <Martyn> embedded my buttocks...
[18:15] <persia> Precisely.  ARM != embedded.
[19:08] <Who_> ogra (et al - anyone who will know): are there plans to change the build scripts for some packages in the arm repositories so they make 'more sense' on ARM - such as specifying EGL as or XEGL as the clutter backend?
[19:09] <Who_> sorry - that should have been to ogra_cmpc, I guess ^
[19:10] <persia> Are we sure that makes more sense for arbitrary hardware solutions?
[19:10] <persia> I'd much prefer not to align "armel" and "embedded" in any way.
[19:13] <Who_> persia: interesting. do you know of any armel devices with full OpenGL support (just asking, not suggesting there aren't!)?
[19:13] <Who_> persia: I guess though that there'd be no harm in a 'clutter-backend-egl' package or equivalent
[19:14] <persia> I know of armel devices with PCIe slots.
[19:14] <persia> Getting full OpenGL there is just a matter of driver testing.
[19:14] <Who_> persia: and armel drivers for the cards?
[19:15] <persia> I also stuffed some DisplayLink drivers in the archive for lucid, for which I hear there are plans to grow OpenGL support upstream.  That's USB, and arch-independent.
[19:15] <Who_> persia: okie, sounds like changing the build isn't ideal
[19:15] <persia> Who_: Why not?  No good reason any of the existing opensource drivers can't be ported.
[19:15] <persia> Who_: Well, maybe building twice and making two flavours of a binary is useful.
[19:16] <Who_> persia: Sorry - I should be more clear - I was agreeing with you that making the default packages more 'embedded' didn't make sense
[19:16] <persia> That's just tricky, and it's important to identify which packages make sense for that, and how much work.
[19:16] <Who_> but I think it would be helpful for people like me if there were some more embedded-target style packages built
[19:17] <Who_> persia: and I guess you also then need to have some (likely non OS) graphics libraries on the build system to be able to compile?
[19:17] <persia> Right, that's why I say that in some cases, two flavours may make sense.
[19:17] <persia> I'm not sure I understand that last question.
[19:19] <Who_> persia: My understanding is that in order to build Clutter with, for example, an EGL backend, you would need to have EGL development headers on the system - are there Open Source headers that you can link against, and then still get hw accelerated performance on systems that have hardware drivers?
[19:20] <persia> But I think the real solution for X is to have a more pluggable GL library, so that various libraries can register the ability to do various functions, using a GPU, CPU, DSP, etc. (whatever hardware happens to be available).
[19:20] <persia> Oh.  I have no idea if there are open-source EGL headers available.
[19:26] <Who_> persia: seems so http://www.khronos.org/registry/gles/
[19:26] <persia> Cool.
[19:26] <persia> It's probably too late for lucid, but we ought be able to get that stuff into the next release.
[19:41] <Who_> persia: sounds sweet
[19:42] <Who_> persia: I made sound work on my IGEP, but the process was a bit... confusing... I'm not entirely sure I should have needed to do what I had to do (run .snddevices from the alsa-driver source package on the arm) - is it worth raising as a bug, or is it too device specific?
[19:42] <Who_> persia: more specifically, I made aplay work. Pulseaudio is still unhappy
[19:44] <persia> It's worth filing as a bug.  If you're not using a distro kernel, and it looks like a kernel thing, don't be too surprised if it gets rejected.
[19:46] <Who_> persia: I _think_ it's a kernel thing - I don't know where the line between kernel and userspace is when it comes to alsa. I am using the kernel sources from the board manufacturere
[19:46] <persia> If you want help with investigation, file a bug :)
[19:46] <persia> Worst case someone tells you it's your kernel.
[19:47] <Who_> :)
[20:07] <Who_> persia: on further investigation, it seems udev is at fault, as it is supposed to create these devices. any new thoughts?
[20:08] <persia> If it's udev, file a bug.
[20:08] <persia> But udev mostly relies on kernel events, so it might be a kernel issue or a udev rules issue.  Hard to say without looking closely.
[23:46] <andruk> i followed the guide at http://elinux.org/BeagleBoardUbuntu page and im getting "Unhandled fault: external abort on non-linefetch (0x1018) at 0x40..." errors on booting my Beagleboard rev C4.  im not new to coding, but im new to kernel debugging...help?
[23:49] <persia> Unfortunately, the best person to help you is rcn-ee, who tends to be idle at this time of day.
[23:50] <rcn-ee> sweet timing.. just walked in after work...
[23:50] <persia> Wonderful :)
[23:50] <rcn-ee> andruk, those errors are annoying, but safe to ignore..
[23:51] <rcn-ee> aka i haven't debugged to figure out what it was, but it doesn't seem to affect anything.. ;)
[23:53] <rcn-ee> persia, just noticed this last night: https://wiki.ubuntu.com/KernelTeam/TopicBranches  your kernel guys are going to be busy. ;)
[23:54] <persia> so they say :)
[23:54] <persia> rcn-ee: Feel free to jump into #ubuntu-kernel if you want to help push that effort.
[23:55] <rcn-ee> persia, of course.. ;) already queied my first patch https://code.launchpad.net/~beagleboard-kernel/+junk/lucid-ti-omap
[23:56] <rcn-ee> still need the beagle/iegp2 to boot before i open my mouth on ubuntu-kernel. ;)
[23:57] <persia> heh.