[00:02] Ah, that fixes it. [00:02] * michaelh1 tries 768M... [00:04] michaelh1: hm, what x-loader and u-boot were you using before? [00:04] 2010.11? [00:04] u-boot now claims 1 GB of memory [00:05] rsalveti: are you still around? [00:05] TheUni: hey, yes [00:05] rsalveti: great [00:05] rsalveti: one of our devs has done some mangling of the packages, i'd like to ask you a few questions if you don't mind [00:05] TheUni: sure [00:06] rsalveti: basically, we have lots of packages. we would much prefer to condense them down into something like xbmc and xbmc-data... [00:06] but i'm not sure what policy dictates [00:06] TheUni: what are the packages you currently have? [00:06] and what are they for? [00:06] for example, we have some event-clients. each client is a separate binary. for ex, a bin for a ps3 remote control. [00:07] in the past, we've split these out into one package per binary. so xbmc-eventclients-ps3, xbmc-eventclients-java, etc [00:07] we would much prefer to just install all of these along with xbmc. but not if it would be denied by ubuntu policy [00:08] TheUni: well, actually there's nothing wrong for having one major package for it, the only issue is that to use one of them you'll bring all dependencies [00:09] rsalveti: well in this case, you can't use the clients without xbmc anyway. so it's kinda moot. [00:09] I mean, for eventclients-java for example, java is probably necessary [00:09] if java is already a dependency for xbmc, then makes no much sense [00:09] oh, i see [00:10] yea, understood. [00:10] but it was my understanding (please correct me if i'm wrong) that in general, the debian policy is to split packages for each functional binary. [00:10] package split makes more sense in the dependency level than just functionality speaking [00:10] yes, in that example, it would make sense. [00:11] in the best case yes, but if you're creating tons of packages with just small binaries, you could just create one major one [00:11] if the dependencies are quite all the same [00:11] ok [00:12] yep, makes perfect sense. I'll have a look at the binaries and see. we'll construct packages based on that and no extras and see how things look [00:12] *have a look at the deps [00:12] cool [00:13] TheUni: do you have any other updates regarding the gles support on xbmc? [00:13] rsalveti: gles is fully supported. still just a matter of getting it packaged [00:13] I remember topfs2 had something working, but unfortunately still didn't check [00:13] TheUni: oh, that's nice, good to know [00:14] TheUni: already at trunk? [00:14] rsalveti: yep. it's used on the ipad port. [00:15] awesome, natty is finally working with gles and 2.6.38, should be able to try it once I get some free time [00:15] great === prpplague^2 is now known as prpplague [00:39] dang, the HDMI KVM switch I got doesn't seem to forward EDID info [00:46] Amaranth: I have the same problem with my 5 port HDMI switch. Have to make sure the switch is on the system I need before waking up the system. [00:46] rsalveti: the code in id.c in linux-linaro-2.6.28 is correct both re: OMAP4 die ID and how to set a MAC address. [00:46] ah, right [00:52] I hope the autoswitch thing on this doesn't try to outsmart me [00:54] dang, it does [01:08] at least moving my rootfs to a usb stick worked correctly, my read speeds are now 11.9MB/s average according to palimpest instead of 1MB/s or whatever the SD card gives [01:47] hrm, E-EDID checksum failed [02:18] easily solution for that, I put other devices on the HDMI KVM so the panda can get its own direct connection === asac_ is now known as asac === mattgriffin_ is now known as mattgriffin [03:48] rsalveti, ping === TheUni is now known as Guest14241 === 50UAAGBPG is now known as Amaranth === Guest14241 is now known as TheUni_ === JamieBen1ett is now known as JamieBennett === javalogger is now known as apachelogger === lool- is now known as lool === lilstevie|lagche is now known as lilstevie [10:42] wohoo, karmic EOL ! [10:44] so no more support for armv6 even [10:44] yeah, finally [10:44] :o [10:44] * ogra_ likes to have a clear set of supported bits [10:45] heh [11:01] it's a sad day ;( [11:02] ?? [11:02] karmic EOL [11:02] I have an armv6 device ;p [11:02] Lopi: use debian then [11:02] yeah [11:03] use debian for evverything thats not v7 [11:05] ogra_: do we have the datasheet for omap4&c? [11:07] ppisati, i dont think we have the full one, what bits do you need, ndec should be able to get you access [11:07] btw, ndec did you meet ppisati already ? he is our new arm kernel guy [11:09] Lopi: Note that karmic was only support for 18 months on ARM anyway :-) [11:09] I'm glad that I updated from a v6 device to the hummingbird [11:48] ogra_: well, from time to time i would find it handy to have a reference with regs, bits, etcetc === Lopi is now known as Lopi|idle [12:28] ppisati: public TI omap4 specs are available here: http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123&navigationId=12037 - see in section "Technical Documents" [12:28] ppisati: the TRM probably contains most of the info you are looking for [12:37] sebjan: cool, thanks [12:37] np [13:40] ogra_: hi. no haven't met ppisati [13:40] ppisati: hi! [13:50] ndec: hi! :) [13:53] ppisati: nice to meet you ;-) [14:03] ppisati: have you discussed with sebjan, he is the kernel guy on our end [14:07] ndec: nope, just got in touch with him [14:08] ndec: so, you and sebjan are from... Linaro? TI? [14:08] ppisati: TI, both. === apachelogger is now known as thresh_fan_fan === chuck_ is now known as zul === thresh_fan_fan is now known as apachelogger === Dr_Who is now known as tgall_foo [16:27] ogra_: It looks like the images are being rebuilt. Can you make sure headless is added to the rebuild mix? [16:29] asked cjwatson [16:29] but i think he works down the crontab entries anyway [16:43] ok [16:44] ogra_: Does/will the headless image autodetect between serial console and kvm? [16:44] no [16:44] Serial only? Ok. [16:44] i was wondering if we should add a boot-no-serial.scr by default that you can copy over boot.scr [16:44] to make switching back and forth easy [16:45] * ogra_ finds the need for mkimage pretty annoyong [16:45] (or so ... cant type today) [16:45] Not a bad idea. Would need to add a default environment to uboot so the user can just run it. [16:49] rsalveti, thanks for confirming the cpuinfo stuff === TheUni_ is now known as TheUni [16:56] ogra_: np [16:59] ogra_: What was the environment setting used before launching minicom? TERM=vt100? [16:59] GrueMaster, i would really recommend screen [16:59] screen /dev/ttyUSB0 115200 [17:00] I know, just adding a warning to the wiki for minicom purists. [17:00] to exit it ctrl+a+k [17:00] vt100 or vt102 or posix will work [17:00] I'm using byobu and finding it works rather well. [17:00] ah, never used byobu [17:02] It is a window manager for screen. Quite handy. [17:02] i know what it is, i just never used it [17:02] as i dont use tabbed terminal windows [17:02] but i know they exist ;) [17:05] Check http://testcases.qa.ubuntu.com/Install/ARM/Headless and see what you think. [17:10] GrueMaster, thats not what i meant :) [17:10] ?? [17:10] What did I miss? [17:10] after zcat'ing your SD card, plug it out and in again and copy boot-no-serial.scr over the boot.scr file [17:11] thats rather what i meant [17:11] (but we dont have that file atm, thats post beta stuff) [17:12] That only works if you have a linux host system. My method will work regardless of host os. [17:12] its vfat ;) [17:12] (granted, Ubuntu Linux is preferred). [17:12] will work on every system [17:15] the idea behind having that file was exactly that you dont have to type any commands like mkimage or even something at the u-boot prompt [17:15] i.e. that if you want a minimal system with framebuffer you dont need to have serial at all [17:17] GrueMaster, but anyway, we dont have that file yet, remove these lines [17:17] done [17:18] and can we put healessInstall in the right namespace please [17:18] So, why were the images rebuilt? [17:18] ? [17:18] oem-config changes [17:19] ok [17:19] ??? re: and can we put healessInstall in the right namespace please [17:19] https://wiki.ubuntu.com/ARM/OMAPMaverickInstall is the page we use for the netbook images ... we will have OMAPNattyInstall for natty (linked from https://wiki.ubuntu.com/ARM/OMAP) [17:20] sorry, took a min to collect the existing links [17:20] Why? The procedure has not changed between Maverick & Natty. [17:20] errata have and it might change in O [17:20] And I would assume the Headless image install won't change over time. [17:20] in any case you should (like all the download pages) just link to https://wiki.ubuntu.com/ARM/OMAP [17:21] and link the headless install from there [17:21] while i think you could drop the release name you need to have the subarch name in the namespace [17:22] we will likely produce mx51 images for the community that will work different (due to HW differences) [17:22] and if we get dove back we will have another way of using it [17:23] I honestly didn't know https://wiki.ubuntu.com/ARM/OMAP existed. I was going off of https://wiki.ubuntu.com/ARM/OMAPMaverickInstall as that was all you gave me in the past. [17:23] OMAP is linked from each and every dowbnload page we have [17:23] Will make changes. [17:23] thanks :) [17:23] we should possibly discuss the concept at UDS over a beer or so if you feel like [17:24] in the past the install methid changed with every release we had ArchReleasenameBoard for all past images [17:24] i agree that if the install procedure doesnt change we should probably change that [17:25] with preinstalled everything got easier ;) [17:28] Will https://wiki.ubuntu.com/ARM/OMAPNattyHeadlessInstall work? Maybe we should use more subdirectories in the tree, like // [17:28] Or /// [17:28] that would work, though after your comment above i wonder if we actually should have the release name in it [17:29] OMAPHeadlessInstall seems sufficient [17:29] So // [17:29] where is persia if you need him :P [17:29] I would prefer to have some subdirectory structure for readability. [17:29] he surely has pros and cons for exactly that ;) [17:29] somewhere to copy/paste them [17:30] I.e. Arm/Omap/HeadlessInstall [17:30] We can fix this later before release. [17:30] well, do as you like but keep them consistent [17:31] Ok. I'll add a task to confer with the grand master and come up with a standard. :P [17:31] heh [17:56] ogra_: Ok, made some changes to https://wiki.ubuntu.com/ARM/OMAP for headless. Also minor reformatting overall. Check it over and give me some feedback. [17:57] looks ok for now [17:57] "No keybourd" [17:58] :) [17:58] * ogra_ perfers keybelts to bourds :P [18:00] GrueMaster, "that can be configured and controlled via serial console", probably "have to be..." since we dont offer any other way yet ? [18:02] I think I would rather leave it and add the feature post beta. It will only take 5-10 minutes to add the feature, less time than rewording the instructions, then reverting back. [18:02] k [18:02] no objections [18:02] well, looks ok to me [18:03] And even if the system is currently configured only via serial, it will still support keybord, mouse, and monitor post-install. [18:03] sure [18:03] and you still can edit boot.scr, its just more effort [18:20] GrueMaster, can you please default to the zcat method on the headless page (so we have consistency and dont waste gigs of space on users disks) [18:21] No. I have had too many issues with that method, as it doesn't allow for buffered writes on SD compatible boundaries. [18:21] and we should also add the screen line to use (and how to get out of screen again afterwards) oem-config in minicom looks really shitty [18:21] sorry, but i dont get what issues you have still [18:21] I would prefer to have a more stable method. [18:21] and nobody has proven that there are actual issues [18:22] I have had these issues on all but two of my SD cards. [18:22] i have exactly met one person here that in the end admitted that he wasnt sure it was the issue [18:22] please make dd optional [18:24] feel free to blame me if someone comes around who actually has issues with it [18:24] i really dont want to add 10min of uncompressing and 2G of wasted diskspace to the process [18:26] I'll experiment with a zcat|dd pipe. I would rather have the best experience overall. [18:27] thats what just struck me as well [18:27] why not just pipe them together [18:27] Might even recommend a simple tool to flash the sd card with. [18:27] if i get to it before release i'll add a pipe to usb-imagewriter [18:27] * ogra_ has that long on his list but with low prio [18:27] Ugh. [18:28] ?? [18:28] I don't like that utility much personally. [18:28] you also know how to use dd :) [18:29] gunzip ubuntu-netbook-10.10-preinstalled-netbook-armel+.img.gz| sudo dd bs=4M of=/dev/ [18:29] that line might work [18:29] Actually, I have a script I use now. Saves having to type all the dd crap. [18:29] oh, another typo ... [18:30] 11.04, not 10.10 in the image name ;) [18:32] GrueMaster, actually the above command looks better than the zcat variant, i have supported plenty of people that messed up the single quotes from the sh -c [18:33] There. Fixed the wiki. [18:34] the note ablow should be bigger and bold [18:34] Picky picky. [18:34] and there should be a note somewhere that you should really really write to the raw device and not a partition [18:34] thats the most common failure i have seen yet [18:35] ah, we have it in MaverickInstall [18:39] See how this looks. I added bold to the note to make it stand out without getting larger, and added the raw device info. [18:40] yeah, better === renato is now known as renatofilho [18:53] ogra_: Ok, reformatted the minicom section and added screen [18:53] rsalveti, ping [18:55] GrueMaster, looks cool ! [19:21] * GrueMaster twiddles thumbs while waiting for new image builds to post. === stenzel_ is now known as stenzel [20:44] what do I need to test an armel image on an imx51? [20:45] First you'd need us to have such an image. [20:47] ScottK: I signed up to test xubuntu on arm [20:48] AFAIK no mx.51 images exist at the moment. ogra_ and I are going to work on it next week. [20:48] oh, hmm [20:48] You'd need to have some mx.51/53 device. [20:50] ScottK: ok, so I guess I'm off the hook for that testing [20:50] at least until beta 2 [20:50] Hopefully we get it sorted before the. [20:50] n [20:50] micahg: What device do you have for testing? [20:53] ScottK: I have an efika mx [20:53] micahg: smarttop or smartbook? [20:53] * ScottK has smarttop. [20:54] ScottK: I have both actually [20:54] Ah. Cool. [20:54] but I have no idea how to test an ISO on either [20:54] The reports I've heard is that the linaro kernel we have works OK with smarttop, not so much with smartbook, but maybe you can test. [20:55] All work for next week. [20:55] yeah, I'll have to find my restore SD card before I start trying that [21:49] * stgraber finally received his pandaboard ! [21:49] I now have more ARM boards and devices than x86 (2x beagle + 1x panda + 1x smarttop + 1x n900) [21:50] Is that all? :P [21:52] * GrueMaster has lots of dev systems, but no toys (i.e. smarttop/smartbook, n900, etc). [21:52] I like toys, especially useful toys like the n900 :) [21:52] Closest I have to a toy is my Droid 2 global, but I don't want to hack it. [22:34] GrueMaster, ping [22:46] rbelem: pong [23:00] GrueMaster, i need your help :-) [23:00] ok. What can I do for you? [23:00] GrueMaster, do you have some free time to test kubuntu-mobile omap4 images? [23:01] Release testing? Sure, after I do the normal images. [23:01] Shouldn't be too difficult to get them tested. I have the hardware. [23:03] GrueMaster, yup [23:03] GrueMaster, thank you very much :-) [23:03] Not a problem. (personally I am a closet fan of KDE) :P [23:04] :-D [23:04] * rbelem hugs GrueMaster === Willie_ is now known as Guest99256