[05:48] <danders> cooloney_, ping
[05:49] <cooloney_> danders: hey, man
[05:49] <danders> cooloney_, hey bud
[05:49] <cooloney_> danders: you changed your nickname here?
[05:49] <danders> doh
[05:49] <danders> just reloaded a pc at the house
[05:49] <danders> forgot to change my nick
[05:50] <prpplague> cooloney_, hey you know a matt copeland in stitsville ?
[05:51] <cooloney_> cooloney_: oh, no, don't know that
[05:52] <prpplague> cooloney_: there is a matt copeland on your linkedin.com contacts that is in the ottawa area
[05:52] <cooloney_> prpplague: oh, god. actually, i might not know everyone on my linkedin.com
[05:52] <prpplague> cooloney_: hehe
[05:53] <cooloney_> prpplague: did he contact with you? or make you unconfortable?
[05:53] <prpplague> cooloney_: hehe, no, its a personal matter, just a weird item that his linkedin page showed that he was connected via you to me
[05:54] <cooloney_> prpplague: np, let me check my linkedin.
[05:54] <prpplague> cooloney_: see /msg
[05:55] <prpplague> cooloney_: bizarre sunday evening
[12:44] <XorA> morning
[13:31] <XorA> is the panda es1.0 still supported without hacks?
[13:40] <ogra> no
[13:40] <ogra> it never was supported in a release
[13:40] <ogra> maverick beta should run on it
[13:40] <ogra> but es1.0 support was dropped after beta
[13:40] <persia> maverick beta may be hard to find
[13:40] <ogra> why ?
[13:41] <ogra> should be on the cdimage server
[13:41] <persia> Old betas get deleted without announcement
[13:41] <ogra> bah
[13:41] <ogra> k
[13:41] <ogra> yeah, its gone
[13:41] <XorA> because I have an ES1.0 board lying around
[13:42] <persia> Well, if you can find a suitable kernel patch that makes that work as well as the production models, without regression..
[13:43]  * XorA lacks ubuntu capable hardware :-D
[13:53] <ogra> XorA, i think rsalveti kept a x-loader and u-boot biary around soemwheer (i might misremember) but i dont know about the kernel patch
[13:54] <XorA> ogra: x-loader/u-boot easy enough to frig up from somewhere
[13:54] <XorA> ogra: I never used a Ubuntu generated one anyway
[13:54] <persia> If you have a kernel that works on it (even an old one), you can probably run for a while.
[13:55] <ogra> there is a counter builtin ?
[13:55] <ogra> (or why "for a while") ?
[13:55] <ogra> janimo, did you already take a look at nux ?
[13:56]  * ogra notices that images are still failing 
[13:56] <XorA> if its more than 1/2 a days effort I probably wont attempt it, ES1.0 is missing a lot of functionality anyway
[13:56] <persia> Because as the kernel drifts, userspace tends to drift to match, and there is increasing potential for incompatibilities.
[13:56]  * XorA has a convenient b1n to file old boards into
[13:56] <ogra> persia, oh, you talk about upgrading
[13:57] <persia> Saving them up to deliver to the acid-etching folk for gold recovery?
[13:57] <persia> ogra: No, I talk about staying current.
[13:57] <XorA> persia: recycling place has a place for old electronic
[13:57] <XorA> what they do after that I dont know, probably illegally ship to africa or something
[13:58] <janimo> ogra, yes, and have a merge request with the fix
[13:58]  * ogra hugs janimo 
[13:58] <ogra> awesome !!!
[13:58]  * janimo hugs ogra
[13:58] <ogra> :)
[13:58] <persia> When I ran a electronics reclamation agency (we'll haul by the half-pallet at no charge!), it was mostly a matter of removing the metals from the boards.  The chips were worthless and the boards indestructible.
[13:58] <janimo> however a new nux needs toi be uploaded for unity to build against
[14:01]  * XorA amusingly still has some form of ubuntu rootfs on the zoom3
[14:01] <persia> That probably has better support
[14:02] <XorA> it does?
[14:02] <persia> It's omap3, right?
[14:02] <XorA> yeah, but until 2.6.38-rcX wasnt bootable in mainline
[14:02] <janimo> ogra, persia I also filed a merge request for ubuntu-cdimage . No idea how to test that easily, it is mostly copying what is already there for the netbook project
[14:02] <janimo> https://code.launchpad.net/~jani/ubuntu-cdimage/preinstalled-headless-arm
[14:02] <persia> linux-omap from natty is mainline 2.6.38-rcX
[14:03] <XorA> persia: ah, worth a look then, I can always file a defconfig update
[14:03] <persia> janimo: Testing it requires setting up a complete image building environment.  My general recommendation is to leave it for the cdimage team to critique.
[14:03] <persia> XorA: source package is "linux"
[14:03] <XorA> persia: board is 5 miles away and turned off at moment :-)
[14:03] <janimo> persia, indeed
[14:04] <XorA> persia: thanks for taking care of my friday, was awesome
[14:04] <persia> XorA: Well then, when you have a couple hours :)
[14:04] <janimo> but I thought I'd let you too know
[14:04] <persia> I'm glad you liked it.
[14:04]  * XorA is less likely to kill all hardware designers now :-)
[14:06] <persia> janimo: I'm confused by the case $PROJECT bit in etc/config: I wouldn't have expected you to add arch limitation there matching i386.  (I'm not cdimage, but I've looked at that code a bunch)
[14:06]  * janimo checsk
[14:07]  * persia is looking at https://code.launchpad.net/~jani/ubuntu-cdimage/preinstalled-headless-arm/+merge/50568
[14:07] <janimo> persia, I copied the case for ubuntu-netbook, that is unless ARCHES is set default to i386
[14:07] <rsalveti> XorA: ogra: I should have the pointers to make a valid kernel for it
[14:08] <janimo> I assume for ubuntu-netbook ARCHES is set to armel
[14:08] <rsalveti> just need to find at the irc log, many asked this when the es2.0 was out
[14:08] <persia> janimo: Right.  I probably would have defaulted to armel in that case, for this image.  Doesn't matter that much.  Also, it's probably worth glancing at the -server or -desktop models, as examples where it pulls from a common seed (ubuntu)
[14:08] <XorA> rsalveti: dont hunt too hard, I was just vageuly wondering, wont spend real work on it
[14:08] <janimo> persia, I saw not place except the germinate from seed file where I thought diverging from ubuntu-netbook would make sense
[14:09] <persia> Ah, OK.
[14:09] <janimo> persia, I am sure things can be done better, but not knowing the code and being aware it is full of legacy boobytraps I am not trying to do anything smart
[14:10] <janimo> I suppress my desire to cut and refactor stuff
[14:10] <persia> I don't know if things can be done better, and my understanding is that this code mostly grows organically anyway.
[14:10] <janimo> yes, lots of organic weed too there
[14:10] <persia> Someone should probably refactor it at some point, but it's never a priority, and the risk of getting it wrong is fairly high.
[14:11] <janimo> right, probably Colin and a few others know what is safe to nuke but since few people work on it few are hindered by it as it is
[14:11] <XorA> that sounds like a job for someone with asbestos pants
[14:11]  * persia gets excited about libasound2 1.0.24.1-0ubuntu1
[14:11]  * XorA worries about persia 
[14:12] <persia> XorA: Contains support for UCM
[14:12]  * janimo google UCM
[14:12] <persia> (and just hit natty very recently)
[14:12] <XorA> ah, good old Slimlogic product that :-)
[14:12] <persia> Yep
[14:13]  * XorA thinks he has zero lines of code in there though, so dont blame me
[14:14]  * XorA has had enough headaches with DAPM over the years to avoid UCM coding :-)
[14:15] <rsalveti> XorA: http://paste.ubuntu.com/570052/
[14:15] <rsalveti> this is for maverick
[14:15] <XorA> rsalveti: cheers
[14:19]  * XorA actually saw a mythical Pandora at FOSDEM
[14:26] <ogra> janimo, could you have NCommander review the debian-cd bits (or possibly cjwatson), i'm traveling this week and am happy if i get unity-2d done before FF
[14:27] <janimo> ogra, sure it was more of a heads-up not a request for review
[14:27] <ogra> janimo, looking at it, you shouldnt put the image type into the flavour name
[14:27] <janimo> you mean preinstalled?
[14:28] <ogra> ubuntu-preinstalled-headless should become ubuntu-headless instead
[14:28] <janimo> I was trying to be descriptive, some of the other project names are vague
[14:28] <janimo> and the project naming so far does not seem to follow a guideline, some are one others two words
[14:29] <persia> vague is good in terms of product naming: it provides semantic flexibility
[14:29] <ogra> what if i want a d-i ios with ubuntu-headless on it =
[14:29] <ogra> ?
[14:29] <ogra> *iso
[14:29] <persia> They are all transitioning towards two words.
[14:29] <ogra> for-project is invoked with the type attached usually
[14:30] <persia> So images end up being some combination of ${BRAND} ${PRODUCT} ${TYPE}
[14:30] <persia> e.g. "Xubuntu Desktop Preinstalled"
[14:30]  * persia isn't sure that one will ever exist, but as an example
[14:30] <ogra> for-project <flavour> <imagetype>
[14:30] <ogra> i.e.
[14:31] <ogra> for-project ubuntu-headless cron.daily-preinstalled
[14:31] <ogra> or a headless live image:
[14:31] <ogra> for-project ubuntu-headless cron.daily-live
[14:32] <janimo> persia, well in source code I prefer descriptivness over vagueness :)
[14:33] <ogra> the flavour naming goes beyond source code ... thats the point
[14:33] <persia> Indeed, and as Brands and Products get more important in terms of advocacy, this trend will only continue.
[14:33] <ogra> if you ever create a d-i iso or a dvd with headless they would be called *-preinstalled
[14:33] <janimo> I am happy with any name actually just to get this spec done and have headless images
[14:33] <janimo> :)
[14:34] <ogra> right, just remove the type
[14:34] <persia> You want ubuntu-headless (${BRAND}-${PRODUCT})
[14:34] <ogra> the rest looks actually fine
[14:35] <ogra> you could s/preinstalled/chicken/
[14:35] <ogra> *g*
[14:35] <janimo> I'll do that :)
[14:35] <ogra> that would result in ubuntu-chicken-headless images
[14:35] <janimo> pigeon
[14:35] <persia> Please don't.
[14:35] <ogra> yeah, even better :)
[14:35] <persia> Please pick a vaguely descriptive product name ("Headless" is good)
[14:35] <ogra> and chicken-headless isnt ?
[14:36] <XorA> you all running around random like?
[14:36] <ogra> :)
[14:36] <persia> vague is good, but too vague requires PR coordination, which tends to cause headaches, joint pain, and premature drowsiness in coders.
[14:36] <persia> (and I refuse to help with PR coordination for any product with a fowl name)
[17:03] <sveinse> rsalveti, you around?
[17:14] <rsalveti> sveinse: yup
[17:15] <sveinse> What's the story about powervr-omap3 ?
[17:15] <sveinse> I'm uncertain if I should build my own or use the package
[17:16] <rsalveti> sveinse: well, using the one available at our repo should be fine
[17:16] <rsalveti> there's a newer version, that still didn't have time to test
[17:16] <rsalveti> but the changelog didn't say much, and says it wasn't tested with x11
[17:16] <sveinse> I glanced briefly at it... The package contains (as usual) a lot of build output files :(
[17:17] <sveinse> and repeated files
[17:17] <rsalveti> yeah =\
[17:17] <sveinse> I managed to compress a 600M tar.gz to a 150M git repo, which clearly indicates that the same file is repeated many times
[17:18] <rsalveti> sveinse: and were you able to test it?
[17:18] <sveinse> No, not yet. But I will in the next two weeks or so
[17:18] <rsalveti> if you say it's better I can try to update it
[17:19] <sveinse> ..on 3530
[17:19] <rsalveti> ok, should be fine
[17:19] <sveinse> But it hasn't been approved for mainline yet, have it?
[17:19] <sveinse> I remember some issues with udev permissions
[17:24] <sveinse> *sigh* it's quite an effort finding the useful/needed files from the "build junk". I have to admit I'm a little surprised by the state of the package they release
[17:28] <rsalveti> sveinse: to include it at ubuntu we should be fine, but first I'd like to make sure it runs well with x11
[17:28] <rsalveti> sveinse: and it's better than what we had in the past
[17:28] <persia> Ought test quick: FF is Thursday
[17:29] <ogra> FF exceptions are just paperwork though
[17:30] <persia> They're more than that: extra testing precautions, assertions of quality, etc.
[17:30] <sveinse> I'm not working towards X11. I'm targeting Qt/QWS, so I won't be testing X11. Sorry
[17:30] <rsalveti> persia: even for universe/multiverse?
[17:31] <rsalveti> sveinse: that's fine, if it works for you is already something
[17:31] <rsalveti> then I can test with x11 later
[17:31] <ogra> persia, indeed implying that you do the testing etc before asking for them
[17:31] <persia> rsalveti: Yep.  universe and main aren't really that different.  The only meaningful bit is the code review part of the MIR, in my opinion.
[17:32] <rsalveti> persia: ok, that's fine
[17:32] <sveinse> is the powervr license compatible for multiverse? I know I accepted an license for downloading it, but admit not reading it...
[17:32] <rsalveti> sveinse: if the newer version has the same license as the one we already have at multiverse, then we're fine
[17:33] <rsalveti> but the package is total mess hehe
[17:33] <sveinse> oh indeed times 10
[17:36] <XorA> heh I should fix that :-)
[17:36] <XorA> no idea who to send the patches to though
[17:37] <ogra> XorA, to rsalveti
[17:38] <rsalveti> and I need to find who to send then :-)
[17:38] <rsalveti> sgx-omap 4 people are not the same from sgx-omap 3
[17:38]  * XorA is probably not supposed to stil have the source code though
[17:39] <persia> Everyone who wants to be pvr-omap3 upstream, please raise your hand
[17:39] <XorA> Im surprised anyone still making omap3 packages
[17:39] <XorA> with TIs history of abandonment
[17:41] <sveinse> I really hope that isn't true. We're working on a prototype product based on OMAP3 and are waiting for kernel features to be implemented
[17:41] <sveinse> Like USB OTG for AM3517 and similar
[17:42] <persia> sveinse: The rules are probably a little different for silicon customers compared to volunteer projects
[17:42] <XorA> sveinse: will be different if your buying chips
[17:43] <XorA> sveinse: but for us, omap3 is effectively dead
[17:43] <XorA> sveinse: apart from small team at ASP who do beagle
[17:43] <persia> Well, at least the parts dependent on binary blobs
[17:44] <sveinse> It depends. Unfortunately we're competing (sizewise) agains the mobile industry. As an industrial mfg. we are a drop in the ocean in the big picture
[17:44] <persia> sveinse: The comparison we usually consider is more the difference between buying one more beagleboard  or overo, so your scale is hugely larger in that sense.
[17:45] <lilstevie> persia: solved that issue with X and touch
[17:45] <lilstevie> it was the driver
[17:45] <persia> lilstevie: Cool!  You have a patch?
[17:45]  * XorA would just need TI permission to work on subject, already got the NDAs
[17:45] <vstehle> XorA, rsalveti: if you send me patches I can try to "route" them inside TI (to ASP folks, maybe).
[17:46] <vstehle> (pvr patches, that is)
[17:46] <sveinse> persia, yes. The interesting note that the factor between you and us are probably in the same order of magnitude between us and the mobile industry
[17:46] <XorA> anyway it is time to get bus home
[17:47] <rsalveti> vstehle: do you have the pointers to where I can get the omap 3 code?
[17:47] <XorA|gone> vstehle: I keep forgetting you still hang here :-)
[17:47] <rsalveti> vstehle: would be nice if we could get some bugs fixed, like the soname and etc, but then I'm not sure if I can have access
[17:47] <persia> sveinse: Sure, but it's probably threshold between "spare time" vs. "low-priority funded project" :)
[17:47] <rsalveti> or work on it
[17:47] <lilstevie> persia: no
[17:47] <vstehle> I hang "more" since I setup some highlight keywords :)
[17:47] <persia> lilstevie: No patch required?
[17:47] <lilstevie> persia: the evdev driver isnt compatible with the type of touch panel
[17:48] <lilstevie> switching to mtev solved it
[17:48] <lilstevie> on the galaxy tab we now have unaccelerated graphics, touch wifi
[17:48] <persia> In that case, you need to fiddle the udev rules, and it's all good.
[17:48] <vstehle> rsalveti: I am not sure where the sources are. I think folks like koen use the DDK1.6 w/o DRM, currently.
[17:49] <vstehle> koen would be my first bet :)
[17:49] <rsalveti> vstehle: yeah, will try to ping him
[17:49] <lilstevie> aparently sound can be achieved with a little fiddling
[17:49] <rsalveti> I forget he's also TI now
[17:49] <rsalveti> :-)
[17:49] <lilstevie> graphics are going to be the hardest though
[17:50] <persia> lilstevie: From our experiences with sound, 99% of the issue is driver bugs, which often aren't solved because it's far too easy to fiddle userspace.
[17:50] <lilstevie> yeah
[17:50] <lilstevie> persia: from what the guy said who got sound it was fiddling that got it to work
[17:50] <lilstevie> unfortunantly though graphics is SGX54-
[17:51] <lilstevie> 540*
[17:51] <persia> Once the fiddling with asound.conf and pulse is done, there's usually enough information to fix the driver.
[17:52] <persia> Talk to Samsung: they may be able to make a binary driver available (as TI does for the omap)
[17:52] <lilstevie> we have the kernel binary
[17:52] <persia> No kernel source?
[17:52] <lilstevie> hell if you dive into nexus s kernel you have kernel source as well
[17:52] <rsalveti> you should be able to get at least the kernel source
[17:53] <lilstevie> we dont have the pvr kernel module source
[17:53] <persia> Oh, kernel binary for graphics: yeah, you'll need a new one whenever the ABI changes though :(
[17:53] <lilstevie> the soic is similar to the nexus s though
[17:53] <lilstevie> and that does have it as source
[17:53] <lilstevie> there is talk about samsung open sourcing the driver Q4 2011
[17:54] <lilstevie> also something I have noticed
[17:54] <lilstevie> android RTC and what linux expects are different lol
[18:04] <sveinse> rsalveti, which cpu's use the gfx_rel_es2.x since it's included in the opengles-sgx-omap package?
[18:04] <rsalveti> sveinse: old beagles, 3430
[18:04] <sveinse> ah, thanks
[20:13] <akk> Does anyone know if the Ubuntu armel toolchain will work for the ARM chips in sheevaplugs (Marvell kirkwood)?
[20:15] <akk> I've been told it won't, but I'm having trouble finding anything describing what versions armel covers.
[20:16] <suihkulokki> ubuntu armel targets minimum armv7, kirkwood is armv5
[20:16] <akk> Thanks! Good to have a definite answer.
[20:28] <armin76> akk: http://plugcomputer.org/plugforum/index.php?topic=885
[20:29] <armin76> "Is there any hope that ubuntu will support armv5 in the future again?" <- lol
[20:30] <akk> Hmm, that says Debian still supports it. Wonder if that's true, or if they just mean "because Debian won't release a new version for a long time"?
[20:31] <armin76> lol
[20:31] <armin76> akk: afaik debian has no plans to drop the support for armv4t, which is the minimum they support
[20:31] <armin76> suihkulokki: right?
[20:33] <akk> Cool. I had assumed they didn't because of emdebian: http://emdebian.org/tools/crosstools.html
[20:33] <akk> which seems to be saying that you need that repo to get the cross-compilation tools.
[20:40] <suihkulokki> armin76: we might to got ARMv5t, if upstream gets flimsy on ARMv4t and the openmoko people don't fill in
[20:41] <suihkulokki> to got -> go to
[22:28]  * XorA|gone hates mysql
[22:43] <prpplague> fyi for anyone interested, TinCanTools will be doing a production run of RevB Trainer Boards, if anyone has feedback on changes needed please submit them by the end of the week http://www.elinux.org/BeagleBoard_Trainer , Trainer works with the PandaBoard as well