=== zumbi|eislusft is now known as zumbi === asac_ is now known as asac [05:48] cooloney_, ping [05:49] danders: hey, man [05:49] cooloney_, hey bud [05:49] danders: you changed your nickname here? [05:49] doh [05:49] just reloaded a pc at the house [05:49] forgot to change my nick === danders is now known as prpplague [05:50] cooloney_, hey you know a matt copeland in stitsville ? [05:51] cooloney_: oh, no, don't know that [05:52] cooloney_: there is a matt copeland on your linkedin.com contacts that is in the ottawa area [05:52] prpplague: oh, god. actually, i might not know everyone on my linkedin.com [05:52] cooloney_: hehe [05:53] prpplague: did he contact with you? or make you unconfortable? [05:53] 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] prpplague: np, let me check my linkedin. [05:54] cooloney_: see /msg [05:55] cooloney_: bizarre sunday evening === ogra_ is now known as ogra === amitk is now known as amitk-afk === amitk-afk is now known as amitk === XorA|gone is now known as XorA [12:44] morning [13:31] is the panda es1.0 still supported without hacks? [13:40] no [13:40] it never was supported in a release [13:40] maverick beta should run on it [13:40] but es1.0 support was dropped after beta [13:40] maverick beta may be hard to find [13:40] why ? [13:41] should be on the cdimage server [13:41] Old betas get deleted without announcement [13:41] bah [13:41] k [13:41] yeah, its gone [13:41] because I have an ES1.0 board lying around [13:42] 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] 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] ogra: x-loader/u-boot easy enough to frig up from somewhere [13:54] ogra: I never used a Ubuntu generated one anyway [13:54] If you have a kernel that works on it (even an old one), you can probably run for a while. [13:55] there is a counter builtin ? [13:55] (or why "for a while") ? [13:55] janimo, did you already take a look at nux ? [13:56] * ogra notices that images are still failing [13:56] 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] 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] persia, oh, you talk about upgrading [13:57] Saving them up to deliver to the acid-etching folk for gold recovery? [13:57] ogra: No, I talk about staying current. [13:57] persia: recycling place has a place for old electronic [13:57] what they do after that I dont know, probably illegally ship to africa or something [13:58] ogra, yes, and have a merge request with the fix [13:58] * ogra hugs janimo [13:58] awesome !!! [13:58] * janimo hugs ogra [13:58] :) [13:58] 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] 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] That probably has better support [14:02] it does? [14:02] It's omap3, right? [14:02] yeah, but until 2.6.38-rcX wasnt bootable in mainline [14:02] 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] https://code.launchpad.net/~jani/ubuntu-cdimage/preinstalled-headless-arm [14:02] linux-omap from natty is mainline 2.6.38-rcX [14:03] persia: ah, worth a look then, I can always file a defconfig update [14:03] 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] XorA: source package is "linux" [14:03] persia: board is 5 miles away and turned off at moment :-) [14:03] persia, indeed [14:04] persia: thanks for taking care of my friday, was awesome [14:04] XorA: Well then, when you have a couple hours :) [14:04] but I thought I'd let you too know [14:04] I'm glad you liked it. [14:04] * XorA is less likely to kill all hardware designers now :-) [14:06] 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] persia, I copied the case for ubuntu-netbook, that is unless ARCHES is set default to i386 [14:07] XorA: ogra: I should have the pointers to make a valid kernel for it [14:08] I assume for ubuntu-netbook ARCHES is set to armel [14:08] just need to find at the irc log, many asked this when the es2.0 was out [14:08] 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] rsalveti: dont hunt too hard, I was just vageuly wondering, wont spend real work on it [14:08] persia, I saw not place except the germinate from seed file where I thought diverging from ubuntu-netbook would make sense [14:09] Ah, OK. [14:09] 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] I suppress my desire to cut and refactor stuff [14:10] I don't know if things can be done better, and my understanding is that this code mostly grows organically anyway. [14:10] yes, lots of organic weed too there [14:10] 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] 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] 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] XorA: Contains support for UCM [14:12] * janimo google UCM [14:12] (and just hit natty very recently) [14:12] ah, good old Slimlogic product that :-) [14:12] 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] XorA: http://paste.ubuntu.com/570052/ [14:15] this is for maverick [14:15] rsalveti: cheers [14:19] * XorA actually saw a mythical Pandora at FOSDEM [14:26] 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] ogra, sure it was more of a heads-up not a request for review [14:27] janimo, looking at it, you shouldnt put the image type into the flavour name [14:27] you mean preinstalled? [14:28] ubuntu-preinstalled-headless should become ubuntu-headless instead [14:28] I was trying to be descriptive, some of the other project names are vague [14:28] and the project naming so far does not seem to follow a guideline, some are one others two words [14:29] vague is good in terms of product naming: it provides semantic flexibility [14:29] what if i want a d-i ios with ubuntu-headless on it = [14:29] ? [14:29] *iso [14:29] They are all transitioning towards two words. [14:29] for-project is invoked with the type attached usually [14:30] So images end up being some combination of ${BRAND} ${PRODUCT} ${TYPE} [14:30] e.g. "Xubuntu Desktop Preinstalled" [14:30] * persia isn't sure that one will ever exist, but as an example [14:30] for-project [14:30] i.e. [14:31] for-project ubuntu-headless cron.daily-preinstalled [14:31] or a headless live image: [14:31] for-project ubuntu-headless cron.daily-live [14:32] persia, well in source code I prefer descriptivness over vagueness :) [14:33] the flavour naming goes beyond source code ... thats the point [14:33] Indeed, and as Brands and Products get more important in terms of advocacy, this trend will only continue. [14:33] if you ever create a d-i iso or a dvd with headless they would be called *-preinstalled [14:33] I am happy with any name actually just to get this spec done and have headless images [14:33] :) [14:34] right, just remove the type [14:34] You want ubuntu-headless (${BRAND}-${PRODUCT}) [14:34] the rest looks actually fine [14:35] you could s/preinstalled/chicken/ [14:35] *g* [14:35] I'll do that :) [14:35] that would result in ubuntu-chicken-headless images [14:35] pigeon [14:35] Please don't. [14:35] yeah, even better :) [14:35] Please pick a vaguely descriptive product name ("Headless" is good) [14:35] and chicken-headless isnt ? [14:36] you all running around random like? [14:36] :) [14:36] vague is good, but too vague requires PR coordination, which tends to cause headaches, joint pain, and premature drowsiness in coders. [14:36] (and I refuse to help with PR coordination for any product with a fowl name) === lilstevi is now known as lilstevie === npitre_ is now known as npitre [17:03] rsalveti, you around? [17:14] sveinse: yup [17:15] What's the story about powervr-omap3 ? [17:15] I'm uncertain if I should build my own or use the package [17:16] sveinse: well, using the one available at our repo should be fine [17:16] there's a newer version, that still didn't have time to test [17:16] but the changelog didn't say much, and says it wasn't tested with x11 [17:16] I glanced briefly at it... The package contains (as usual) a lot of build output files :( [17:17] and repeated files [17:17] yeah =\ [17:17] 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] sveinse: and were you able to test it? [17:18] No, not yet. But I will in the next two weeks or so [17:18] if you say it's better I can try to update it [17:19] ..on 3530 [17:19] ok, should be fine [17:19] But it hasn't been approved for mainline yet, have it? [17:19] I remember some issues with udev permissions [17:24] *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] 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] sveinse: and it's better than what we had in the past [17:28] Ought test quick: FF is Thursday [17:29] FF exceptions are just paperwork though [17:30] They're more than that: extra testing precautions, assertions of quality, etc. [17:30] I'm not working towards X11. I'm targeting Qt/QWS, so I won't be testing X11. Sorry [17:30] persia: even for universe/multiverse? [17:31] sveinse: that's fine, if it works for you is already something [17:31] then I can test with x11 later [17:31] persia, indeed implying that you do the testing etc before asking for them [17:31] 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] persia: ok, that's fine [17:32] is the powervr license compatible for multiverse? I know I accepted an license for downloading it, but admit not reading it... [17:32] sveinse: if the newer version has the same license as the one we already have at multiverse, then we're fine [17:33] but the package is total mess hehe [17:33] oh indeed times 10 [17:36] heh I should fix that :-) [17:36] no idea who to send the patches to though [17:37] XorA, to rsalveti [17:38] and I need to find who to send then :-) [17:38] 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] Everyone who wants to be pvr-omap3 upstream, please raise your hand [17:39] Im surprised anyone still making omap3 packages [17:39] with TIs history of abandonment [17:41] 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] Like USB OTG for AM3517 and similar [17:42] sveinse: The rules are probably a little different for silicon customers compared to volunteer projects [17:42] sveinse: will be different if your buying chips [17:43] sveinse: but for us, omap3 is effectively dead [17:43] sveinse: apart from small team at ASP who do beagle [17:43] Well, at least the parts dependent on binary blobs [17:44] 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] 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] persia: solved that issue with X and touch [17:45] it was the driver [17:45] lilstevie: Cool! You have a patch? [17:45] * XorA would just need TI permission to work on subject, already got the NDAs [17:45] XorA, rsalveti: if you send me patches I can try to "route" them inside TI (to ASP folks, maybe). [17:46] (pvr patches, that is) [17:46] 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] anyway it is time to get bus home === XorA is now known as XorA|gone [17:47] vstehle: do you have the pointers to where I can get the omap 3 code? [17:47] vstehle: I keep forgetting you still hang here :-) [17:47] 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] sveinse: Sure, but it's probably threshold between "spare time" vs. "low-priority funded project" :) [17:47] or work on it [17:47] persia: no [17:47] I hang "more" since I setup some highlight keywords :) [17:47] lilstevie: No patch required? [17:47] persia: the evdev driver isnt compatible with the type of touch panel [17:48] switching to mtev solved it [17:48] on the galaxy tab we now have unaccelerated graphics, touch wifi [17:48] In that case, you need to fiddle the udev rules, and it's all good. [17:48] rsalveti: I am not sure where the sources are. I think folks like koen use the DDK1.6 w/o DRM, currently. [17:49] koen would be my first bet :) [17:49] vstehle: yeah, will try to ping him [17:49] aparently sound can be achieved with a little fiddling [17:49] I forget he's also TI now [17:49] :-) [17:49] graphics are going to be the hardest though [17:50] 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] yeah [17:50] persia: from what the guy said who got sound it was fiddling that got it to work [17:50] unfortunantly though graphics is SGX54- [17:51] 540* [17:51] Once the fiddling with asound.conf and pulse is done, there's usually enough information to fix the driver. [17:52] Talk to Samsung: they may be able to make a binary driver available (as TI does for the omap) [17:52] we have the kernel binary [17:52] No kernel source? [17:52] hell if you dive into nexus s kernel you have kernel source as well [17:52] you should be able to get at least the kernel source [17:53] we dont have the pvr kernel module source [17:53] Oh, kernel binary for graphics: yeah, you'll need a new one whenever the ABI changes though :( [17:53] the soic is similar to the nexus s though [17:53] and that does have it as source [17:53] there is talk about samsung open sourcing the driver Q4 2011 [17:54] also something I have noticed [17:54] android RTC and what linux expects are different lol [18:04] rsalveti, which cpu's use the gfx_rel_es2.x since it's included in the opengles-sgx-omap package? [18:04] sveinse: old beagles, 3430 [18:04] ah, thanks [20:13] Does anyone know if the Ubuntu armel toolchain will work for the ARM chips in sheevaplugs (Marvell kirkwood)? [20:15] I've been told it won't, but I'm having trouble finding anything describing what versions armel covers. [20:16] ubuntu armel targets minimum armv7, kirkwood is armv5 [20:16] Thanks! Good to have a definite answer. [20:28] akk: http://plugcomputer.org/plugforum/index.php?topic=885 [20:29] "Is there any hope that ubuntu will support armv5 in the future again?" <- lol [20:30] 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] lol [20:31] akk: afaik debian has no plans to drop the support for armv4t, which is the minimum they support [20:31] suihkulokki: right? [20:33] Cool. I had assumed they didn't because of emdebian: http://emdebian.org/tools/crosstools.html [20:33] which seems to be saying that you need that repo to get the cross-compilation tools. [20:40] armin76: we might to got ARMv5t, if upstream gets flimsy on ARMv4t and the openmoko people don't fill in [20:41] to got -> go to [22:28] * XorA|gone hates mysql [22:43] 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