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