[00:21] <Neko> is ubiquity-3d going to be happy with GLES2 (i.e. is someone actively finishing Compiz for GLES2?) for Natty release?
[00:24] <Neko> is there any way I can know if a bug got reported for the fact that Natty alpha3 doesn't install a working backend (gconf for example) by default, so Compiz doesn't run?
[00:24] <Neko> (once you install compizbackend-gconf and reboot it works fine but fails GL and gives you a "working session" anyway)
[00:26] <rsalveti> Neko: linaro is doind the for to port compiz to gles
[00:26] <rsalveti> don't know yet if it'll be ready for natty
[00:26] <rsalveti> but we'll release at least at a ppa
[00:33] <Neko> so on ARM, default desktop will be unity-2d?
[00:33] <Neko> or unity-3d with the compiz falling back to software?
[00:48] <rsalveti> Neko: for now default will be unity-2d
[00:49] <rsalveti> ideally unity-3d would be the default when you have your drivers installed
[00:49] <rsalveti> and unity-2d the fallback
[00:49] <rsalveti> only at arm
[00:49] <rsalveti> at desktop the classic desktop will be the fallback
[00:49] <Neko> unity-3d does fall back properly though
[00:49] <ScottK> unity-2d does 3d just fine if the drivers support it.
[00:50] <ScottK> (I'd assume so anyway since it's Qt)
[00:50] <Neko> it just doesn't *today* because of some compiz misversioning halfway-uploaded builder mania :)
[00:51] <Neko> ah well. I guess we had the weekend to get a stable snapshot of the mirror and missed the opportunity :3
[01:02] <rsalveti> ScottK: well, unity-2d with 3d support, from Qt is a little bit different, but yes, 3d still
[01:02] <rsalveti> the normal unity would be with compiz
[01:02] <rsalveti> and nux, but still need more work to support gles
[02:16] <rsalveti> GrueMaster: cool, webkit bug is finally tested
[02:16] <rsalveti> just running ubiquity again with the slideshow
[02:16] <rsalveti> working fine
[02:16] <rsalveti> will update the bug with the debdiff
[02:16] <rsalveti> more than 15 hours per build
[02:16] <GrueMaster> Sweet
[02:17] <rsalveti> and at least 2gb of ram to be able to link it
[02:17] <rsalveti> scary
[02:17] <GrueMaster> Now to fix openoffice.
[02:17] <rsalveti> one step at a time
[02:17] <rsalveti> :-)
[02:17] <StevenK> GrueMaster: I suggest more fire.
[02:17] <rsalveti> lol
[02:17] <GrueMaster> That takes something like 2 days on x86.
[02:17] <rsalveti> ouch
[02:18] <StevenK> GrueMaster: Uh? libreoffice on i386 finished in 5 hours.
[02:18] <GrueMaster> Well, it did back in 2006 when I was at Intel.  That was on 8x PIII Xeon 900mhz with something like 8G ram (32 bit PAE).
[02:18] <GrueMaster> Systems are a little faster these days.
[02:19] <StevenK> The armel build started ... yesterday
[02:19] <GrueMaster> Back then, we created a 4G ram disk to do the build.  Watching it with -j 10 was cool (for about 30 seconds).
[03:49] <prpplague> ogra / rsalveti  ping
[03:50] <rsalveti> prpplague: pong
[03:50] <prpplague> rsalveti: hey, i'm totally brain dead this evening but......
[03:50] <prpplague> rsalveti: i need to compile a custom kernel for the panda ubuntu images
[03:51] <rsalveti> prpplague: ok
[03:51] <prpplague> rsalveti: what git tree do i need to use, and are there any gotchas to doing a based install on the sd card, and then replacing the kernel with my custom one?
[03:52] <rsalveti> prpplague: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=summary
[03:52] <rsalveti> for natty
[03:52] <prpplague> rsalveti: is that 10.10 ?
[03:52] <rsalveti> prpplague: ti-omap4-dev gets you to the 38 kernel
[03:52] <rsalveti> 11.04
[03:52] <rsalveti> do you need for 10.10?
[03:52] <prpplague> 10.10 is what we have on omapedia, but if 11.04 is current that is fine
[03:54] <prpplague> rsalveti: any gotchas on doing a basic install on sd , then replacing the kernel with a custom built one?
[03:54] <prpplague> i need to add support for a lvds display via the DPI interface
[03:54] <rsalveti> prpplague: just need to install the kernel package, that will generate the initrd
[03:55] <rsalveti> then you need to generate and copy the uInitrd and uImage files to the first partition
[03:55] <rsalveti> or if you're running the board, just call flash-kernel
[03:55] <rsalveti> if it's not called automatically already
[03:56] <prpplague> rsalveti: is the procedure documented somewhere?
[03:59] <rsalveti> prpplague: you mean, to build the kernel package?
[03:59] <prpplague> rsalveti: correct
[04:00] <rsalveti> cooloney: do you know the correct wiki page that describe how to build the kernel?
[04:00] <rsalveti> the kernel wiki list is quite huge
[04:04] <rsalveti> prpplague: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance may help
[04:05] <prpplague> rsalveti: thanks!!!
[04:05]  * prpplague looks
[04:07] <rsalveti> I generally cross build it with debuild -eCROSS_COMPILE=arm-linux-gnueabi- -b -aarmel
[04:07] <rsalveti> but at this wiki you can find all the details on how to maintain your own ubuntu kernel package
[04:09] <prpplague> rsalveti: hmm, looks like i need to do some reading tomorrow to come up to speed
[04:09] <rsalveti> prpplague: yup
[04:10] <prpplague> rsalveti: well i'll bookmark and have look in the morning
[04:10] <prpplague> i'm totally brain dead
[04:10] <prpplague> got the hardware for my netpandabook working today
[04:11] <prpplague> rsalveti: just need to get the kernel updated for the ubuntu build
[06:26] <rsalveti> NCommander: https://bugs.launchpad.net/ubuntu/+source/webkit/+bug/728211
[06:26] <ubot2> Launchpad bug 728211 in webkit "webkit crashes with SIGSEGV on ARM" [Undecided,In progress]
[06:26] <rsalveti> one merge proposal for the webkit fix
[06:33] <cooloney> rsalveti: sorry, just back from lunch.
[06:33] <cooloney> rsalveti: yeah, your URL is right.
[06:36] <rsalveti> cool
[06:36]  * rsalveti gone, back in 7 hours
[06:36] <cooloney> rsalveti: good night
[06:37] <rsalveti> thks!
[10:23] <janimo> ogra, managed to upgrade your ac100 to natty?
[10:24] <janimo> anyone else with a tegra or other non-NEON capable hardware could test latest Qt in natty to see if it works - it is supposed to be built without NEON except for a few files which should only be used on NEON-capable hw
[11:00] <alf> vstehle: rsalveti: Hi! Is there a reason for pvr-omap4 to depend on libgles and libegl? It breaks my workflow (installing libgles, libegl separately under /usr/local and using LD_LIBRARY_PATH to run with them) :(
[11:01] <vstehle> alf: yes, the "test" binaries, which are in pvr-omap4 package today
[11:01] <vstehle> What does this break exactly?
[11:03] <alf> vstehle: 1. The ability to have both mesa and pvr installed and select at will (eg LD_LIBRARY_PATH) and 2. the pvr packages don't provide -dev versions so I can't build anything with them (I have to have mesa -dev packages installed which I can't because they conflict with the pvr ones)
[11:05] <alf> vstehle: previously I had installed pvr-omap4 normally and manually extracted libgles/egl -sgx under /usr/local/lib/sgx, so I could just select what to use with LD_LIBRARY_PATH
[11:06] <alf> vstehle: (and still be able to compile using the mesa -dev packages)
[11:08] <vstehle> alf: I am not sure we can have 1. For 2, we now have a -dev package on-going "internally". rsalveti is on it :)
[11:10] <alf> vstehle: That's good news I guess. Still I don't think pvr-omap4 depending on libgles is the best approach. Eg you could have eg a pvr-omap4-tests that contains the tests and is suggested by pvr-omap4
[11:16] <vstehle> alf: agreed. I'll track that.
[11:20] <alf> vstehle: Thanks :) Another argument for this is that although there are separate packages for gles, gles2, vg there is no way to install only a subset of them (because they depend on pvr-omap4 that in turn depends on all of them).
[12:02] <ogra> janimo, probably GrueMaster can test if i.e. mumble starts on hhis dove, i havent attempted a new upgrade yet on the ac100
[12:06] <ogra> janimo, i see that the tsaksel WI was closed, did it just work ?
[12:07] <ogra> *tasksel
[12:33] <janimo> ogra, GrueMaster closed that, I have not worked on that yet
[12:33] <janimo> so I don;t think it should be DONE unless things just fell into place by default :)
[12:34] <ogra> well, i'll do a test install later today lets see, probably it just runs if the debconf frontend is selected
[12:35] <janimo> alf, is GLES 2.0 preferred over GLES 1.1 or they should be picked on an app by app basis and should coexist?
[12:35] <janimo> since the API's are so differnet 2.0 does not look like a regular 'improvement'
[12:36] <alf> janimo: gles1 and gles2 are not compatible
[12:36] <janimo> alf, yes I know. But is one preferred over the other when writing new apps
[12:37] <janimo> when peiple tlak about let's port to GLES
[12:37] <alf> janimo: yes, gles2
[12:37] <janimo> do they mean both?
[12:37] <janimo> ok
[12:37] <janimo> great, thanks
[12:38] <alf> janimo: in the sense that programmable gfx pipeline is the future (and there is good support for it even now)
[12:38] <alf> yw
[13:31] <ranisuneela> ./join #gstreamer
[14:01] <rsalveti> alf: yeah, makes sense
[14:01] <rsalveti> will change it together with the new -dev package
[14:01] <rsalveti> should hit the ppa later today
[14:01] <alf> rsalveti: cool, thanks
[14:02] <alf> rsalveti: btw, I am getting a Do you want to continue [Y/n]? y
[14:02] <alf> rsalveti: E: Could not perform immediate configuration on 'libgles2-sgx-omap4'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
[14:03] <alf> rsalveti: on alpha3 image, any ideas?
[14:03] <alf> rsalveti: (using omap-trunk)
[14:03] <rsalveti> alf: not yet, will try to reproduce
[14:03] <rsalveti> I have a fresh a3 that just booted
[14:04] <rsalveti> alf: this is at the first moment you install the packages?
[14:04] <rsalveti> or after already installing the mesa ones
[14:04] <rsalveti> including the -dev package
[14:05] <alf> after having installed the mesa ones, I do an apt-get install pvr-omap4
[14:06] <rsalveti> alf: did you installed the -dev packges first?
[14:07] <alf> rsalveti: yes mesa -dev packages are installed
[14:07] <rsalveti> that could be the issue
[14:08] <rsalveti> will try to reproduce
[14:12] <alf> rsalveti: FWIW, http://pastebin.ubuntu.com/578346/
[14:12] <rsalveti> janimo: would you mind applying merge request from bug 728211?
[14:12] <ubot2> Launchpad bug 728211 in webkit "webkit crashes with SIGSEGV on ARM" [Undecided,In progress] https://launchpad.net/bugs/728211
[14:12] <janimo> rsalveti, will do
[14:12] <rsalveti> janimo: thanks!
[14:12] <janimo> rsalveti, upload too I presume?
[14:13] <rsalveti> janimo: yes :-)
[14:13] <janimo> oki :)
[14:13] <rsalveti> alf: what happens if you remove the -dev packages first?
[14:13] <alf> alf: trying that now...
[14:14] <alf> rsalveti: trying that now...
[14:15] <alf> rsalveti: no improvement :/
[14:15] <rsalveti> weird
[14:24] <rlameiro> anyone in here as experience in doing nfs boot using diferent sub-subnets
[14:25] <rlameiro> connecting from 192.168.1.xxx to 192.168.10.xxx
[14:25] <janimo> rsalveti, I think it is better to keep UNRELEASED instead of natty in branches in the future. Otherwise it creates  a branch for revision name. I am not too good with bzr/debcommit so scracthed my head a bit why it says tag already exists
[14:25] <rlameiro> being that the latter is a router connected to the other one
[14:26] <rsalveti> janimo: hm, ok
[14:26] <rsalveti> not a problem
[14:37] <ogra> janimo, ++ (on the UNRELEASED part)
[14:38] <ogra> janimo, tasksel runs fine by default, the only two probs i have seen are oem-config not starting at all and colormap distortion during package removal
[14:39] <janimo> rsalveti, uploaded, fingers crossed. I am really lousy at UDD style sposonring, took me more than 20 min
[14:39]  * janimo awaits the merge triggers pkg upload LP feature
[14:40] <janimo> I dislike the need to manually keep in sync the branches and packages
[14:41] <janimo> ogra, yes I saw the two bugreports. Any idea where I should start looking? Is this in the ubuntu-cdimage or debian-cd project?
[14:41] <janimo> I guess where the FS is created
[14:42] <ogra> not sure, there is an event entry for "start on oem-config-debconf" but that doesnt seem to exist anywhere
[14:42] <rsalveti> janimo: thanks
[14:43] <ogra> i think its an ubiquity prob with the upstart job, notthing to do with the image creation
[14:45] <janimo> rsalveti, yw
[14:45] <rsalveti> once the new webkit package hits the archive we can start using it again at ubiquity
[14:46] <janimo> rsalveti, great. So one week :)
[14:46] <rsalveti> :-)
[14:47] <janimo> LibO is 1 day 16 hours, Qt is 1 day 14 hours
[14:47] <rsalveti> alf: just installed it here and it went fine
[14:47] <rsalveti> alf: after install all mesa packages I installed the sgx ones from the tiomap-dev trunk ppa
[14:48] <rsalveti> and it went find, could be another bug
[14:48] <rsalveti> will now try to install back the mesa ones to see if it works fine
[14:48] <rsalveti> janimo: ouch
[14:48] <rsalveti> webkit will take more than 1 day for sure
[14:49] <alf> rsalveti: :/, this means that something is messed up with my setup, wish me good luck ;)
[14:50] <rsalveti> we'll see after removing the test applications from pvr-omap and having a proper -dev package
[14:52] <janimo> rsalveti, last build was 1 day 1h on armel, so not quite as heavy as Qt or LibO
[14:52] <rsalveti> sill more than 1 day :-)
[14:54] <GrueMaster> janimo: I tested the headless install yesterday.  Had to launch oem-config manually after manipulating the image to get a login.  oem-config launched tasksel just fine, so I marked that WI as done.
[14:55] <janimo> GrueMaster, ok thanks
[14:56] <janimo> GrueMaster, any non-NEON hw around you to see if latest Qt works?
[14:56] <GrueMaster> Yea, but it will need to wait for the caffeine to melt the crud keeping my eyes from focusing.
[14:57] <janimo> GrueMaster, 7 AM at you? Sorry
[14:57] <GrueMaster> Almost.
[14:58] <GrueMaster> Few minutes left.
[14:58] <GrueMaster> But I have coffee.  :D
[16:02]  * NCommander coughs
[16:02]  * rsalveti out for lunch
[16:03]  * ogra takes a break and will then test the oem-config fix
[16:04] <rsalveti> wow, i386 webkit build takes 53 minutes
[16:04] <rsalveti> and the arm one more than 1 day
[16:07] <NCommander> rsalveti: almost as bad as OOo
[16:07] <janimo> Order of decreasing time-to-build: OO, Qt, gcc, webkit
[16:08] <janimo> s/OO/LibO/
[16:08] <NCommander> firefox/thunderbird
[16:08] <NCommander> should be on that list
[16:08] <janimo> probably
[16:09] <janimo> neh, unde 12 hours
[16:09] <janimo> https://launchpad.net/ubuntu/+source/firefox/4.0~rc1+build1+nobinonly-0ubuntu1/+buildjob/2312427
[16:09] <janimo> the ones above are over one day
[16:11] <janimo> just noticed chromium FTBFS two days ago without buldlog
[16:11] <janimo> like LibO and Qt back then
[16:12] <janimo> given back
[18:07] <ogra> geeez, the headless image is so fast
[18:07] <rsalveti> ogra: :-)
[18:25] <armin76> how can you say that being an ubuntu dev :P
[18:25] <ogra> ??
[18:25] <armin76> thats like saying windows has more market share than ubuntu :D
[18:26]  * ogra doesnt get it ... do you mean ubuntu has to be slow or ubuntu has to have a head ?
[18:27] <armin76> the latter
[18:27] <armin76> i mean, it doesn't need to have a head, but its the common thing when you think about ubuntu
[18:27] <ogra> heh, being the number one linux distro in cloud deployments doesnt count ?
[18:28] <ogra> ubuntu server comes headless by default ;)
[18:28] <armin76> well, you don't redirect kernel output to serial in the omap4 images :P
[18:28] <ogra> yes, it doesnt make sense on the netbook images and breaks plymouth
[18:29] <ogra> the headless one will have serial
[18:39] <ogra> rsalveti, janimo, GrueMaster, any suggestion how to set the default console on headless ? if i set to serial only the installer will default to serial too, if i set serial and tty1 the installer will default to DVI
[18:40] <GrueMaster> Well, headless would imply serial console only.
[18:40] <ogra> do we want to enforce the installer to run on serial
[18:40] <ogra> headles just implies no graphical interface
[18:40] <GrueMaster> No, headless implies no kvm.
[18:40] <rsalveti> I don't think it implies serial console only
[18:40] <janimo> ogra, can also imply console text mode interface
[18:41] <ogra> janimo, yes
[18:41] <GrueMaster> I've been doing headless systems for 15 years.
[18:41] <ogra> thats what i mean
[18:41] <GrueMaster> Headless in the industry indicates no local console.
[18:41] <janimo> I mean monitor but no GUI just framebuffer
[18:41] <GrueMaster> No gui is different.
[18:41] <ogra> yes
[18:41] <ogra> well, the question is what do we want to default to
[18:42] <rsalveti> I believe uart would be better for us
[18:42] <GrueMaster> http://en.wikipedia.org/wiki/Headless_system
[18:42] <janimo> but for the scope of this spec I understood people who don't hook up a monitor just ssh into the hw
[18:42] <rsalveti> most tutorials and such uses uart when dealing with panda and beagle
[18:42] <janimo> what does linaro do for their nano/dev images?
[18:42] <GrueMaster> As do most headless installs.
[18:42] <GrueMaster> for other arches.
[18:43] <GrueMaster> What does server do for x86?
[18:43] <ogra> console
[18:43] <ogra> they dont even set serial by default
[18:43] <GrueMaster> For headless installs?
[18:43] <ogra> for server installs
[18:44] <ogra> the default iso uses console mode
[18:44] <ogra> you have to change the default to get serial
[18:44] <janimo> Does modern server hw still have UART?
[18:44] <janimo> x86
[18:44] <ogra> yes
[18:45] <GrueMaster> janimo: most current x86 server platforms also have a special serial over ip system at the hardware level.
[18:46]  * GrueMaster worked on this at Intel in 2006.
[18:48] <armin76> which you have to configure :P
[18:48] <armin76> at least on hp machines
[18:52]  * ogra wonders what plymouth will do on serial only systems
[18:54]  * GrueMaster is surprised that we don't have a method for installing on a headless server.
[18:54] <ogra> we do
[18:54] <ogra> d-i has one
[18:55] <ogra> but you have to tell it to use serial console
[18:55] <ogra> through kernel cmdline and preseeding
[19:25] <GrueMaster> ogra: As to headless console and output either via dvi or serial, you could check from jasper if a keyboard is present.  dmesg | grep "USB HID" will either show a kb or be blank if none present.
[19:25] <GrueMaster> I've tested this twice now on the headless image with break=init at boot before jasper-setup runs.  With usb keyboard it returns a value (... USB HID v1.10 Keyboard...)
[19:25] <GrueMaster> Returns blank if nothing found.
[19:28] <ogra> GrueMaster, hmm, i didnt actually plan to put it into jasper since we will need to add additional info to the image then
[19:29] <ogra> i.e. jasper would need to know its on a headless image
[19:29] <ogra> we have code for setting the default cmdline in the image builder, i would rather like to use that
[19:30] <GrueMaster> Ok.  That will create an image that *only* works one way or the other.  My idea could be expanded to auto-detect.
[19:30] <ogra> well, your auto detection would need to be a bit bigger :)
[19:31] <GrueMaster> Might be worth exploring in O.
[19:31] <ogra> not all omap kbds are attached via USB HID
[19:31] <ogra> yes, definitely
[19:31] <ogra> (teh blaze kbd isnt usb afaik)
[19:31] <GrueMaster> Is there another method for attaching a keyboard?
[19:31] <ogra> plenty
[19:31] <ogra> i bet persia could hold a talk about it ;)
[19:32] <prpplague> ogra / rsalveti lvds is working, just need to add in the kernel modules to the initrd
[19:32] <ogra> the omap3 evm boards (which should boot with our image) only has a keypad for example
[19:32] <rsalveti> prpplague: cool
[19:32] <ogra> prpplague, awesome
[19:33] <GrueMaster> but how is the keyboard mapped?  It would make more sense to have it connected via usb as the driver base is already there.
[19:33] <rsalveti> not usb
[19:33] <rsalveti> it's a keymap driver
[19:34] <ogra> its a great idea but definitiely requires more than a grep in demsg
[19:34] <prpplague> GrueMaster: i2c, spi, ps2, smbus, usb, and via the omap3/4 keyboard matrix
[19:34] <GrueMaster> ok
[19:35] <prpplague> GrueMaster: thats just to name a few
[19:35] <ogra> i think you can detect them on the input device layer though
[19:36] <GrueMaster> Still could be a grep in dmesg.  Just need to change the search parameters.  The full line looks like this:
[19:36] <GrueMaster> [1380061.936154] input: USB KB as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2.1/2-2.1:1.0/input/input5
[19:36] <GrueMaster> [1380061.936511] generic-usb 0003:05D5:6781.0004: input,hidraw0: USB HID v1.10 Keyboard [USB KB] on usb-0000:00:1d.0-2.1/input0
[19:37] <ogra> it should better be a udev rule that sets a flag or execs a script
[19:37] <GrueMaster> As I don't have HW to test, I don't know what to suggest to look for, but maybe hidraw0?
[19:37] <prpplague> GrueMaster: easiest would be to check the input events, either as part of /dev/input or in sysfs
[19:37] <ogra> you can match against the input subsystem
[19:38] <prpplague> GrueMaster: iirc the android framework opens each of the /dev/input/events  and check to see if certain buttons are available
[19:38] <ogra> thats lame
[19:39] <ogra> i'm pretty sure there is a way to do it through udev
[19:40] <rsalveti> well, I guess you can use udev to behave in a similar way
[19:40] <rsalveti> yup
[19:40] <ogra> without having to walk all input devices
[19:40] <rsalveti> just dump all events
[19:40] <rsalveti> and see what can be used
[19:40] <ogra> yep
[19:41] <ogra> i know you can match against SUBSYSTEM=input but i dont know if you get actual info if its a kbd
[19:43] <prpplague> i don't think that is going to help since you could have something like a usb numberic keypad or even just some gpio buttons
[19:43] <ogra> and that doesnt use the input subsystem of the kernel ?
[19:44] <prpplague> yes those use input subsystem, but the input subsystem doesn't really distinguish between input "types", only the keys/functions that are registered to the device
[19:45] <ogra> right, thats what i feared
[19:45] <GrueMaster> Better yet, how about we make a simple check based on HW we can test, and let the community add to it?
[19:46] <prpplague> you could easily take evtest.c and hack it a little to open each of the events, check for the keys QWERTY registered. if it finds one return a known value
[19:47] <ogra> the prob will be that you dont see jasper output at all if you dont have the right console before jasper already
[19:49] <GrueMaster> We don't see jasper now, not sure it makes a difference.
[19:50] <ogra> ??
[19:50] <GrueMaster> Plymouth.
[19:50] <ogra> i see all jasper output in the text splash atm
[19:50] <ogra> the missing text on the graphical theme is a bug that will be fixed before release
[19:52] <GrueMaster> So, what happens if you add console=ttyO2,115200 console=tty0?  (other than losing plymouth).
[19:52] <ogra> you will see the boot on serial, oem-config will come up on tty0
[19:53] <ogra> plymouth will die and jasper will echo to tty0
[19:53] <rsalveti> so can't you be smart enough to just open oem-config to the "best" place for the user?
[19:53] <ogra> since thats the default console after the kernel has booted
[19:53] <rsalveti> like if he's using an usb keyboard
[19:54] <ogra> rsalveti, same issue, you dont see the rezize process
[19:54] <ogra> we need a default at image build time
[19:54] <rsalveti> for now I'd put ttyO2 as default
[19:54] <ogra> i.e. we need a decision
[19:54] <rsalveti> good that now it's the same one for omap3 and omap4
[19:54] <ogra> yep
[19:58] <ogra> k, hedless defaults to console=ttyO2,115200n8 now
[19:58] <ogra> *headless
[19:59] <GrueMaster> Well, currently I see nothing on serial beyond u-boot standard output.  I would suggest using both console output additions, or creating a way for jasper output to be mirrored on serial at the least.
[19:59] <ogra> we need to cover that in the docs somewhere
[19:59] <ogra> GrueMaster, if you use both, oem-config will pick tty0
[19:59] <GrueMaster> Then either jasper or some pre oem-config process can decide were to route.
[20:00] <GrueMaster> Also need an /etc/init/ttyO2.conf regardless.
[20:00] <ogra> jasper cares for that
[20:00] <ogra> at least it should ;) if not thats a bug
[20:00] <GrueMaster> Must be a new feature.  Not in the latest image.
[20:01] <ogra> while i really like the ideas coming up here, i suspect its all Oneric material
[20:01] <ogra> GrueMaster, bug number ?
[20:01] <ogra> ;:)
[20:02]  * GrueMaster is currently reproducing 2 other bugs on different systems, checking NCommander's panda to figure out why it is unstable, and chatting on 2 irc channels.  I'll get to it.
[20:03] <ogra> http://paste.ubuntu.com/578496/
[20:03] <ogra> thats the code in jasper
[20:04] <ogra> you should in any case have a serial.conf file if you had a console=ttyS* or O* option set before jasper runs
[20:04] <GrueMaster> Oh, so it only works if I have console=ttyO2 on the boot cmdline.
[20:04] <ogra> yes
[20:05] <ogra> it copies the upstart job in place if it detects that a serial console is used on first boot
[20:06] <ogra> i simplified the upstart script today, it should work more generically in tomorrows image
[20:06] <ogra> in case there was a bug in it
[22:20] <prpplague> ogra_: https://picasaweb.google.com/lh/photo/XBDVyGLKlEfA1qimY9IkpQUEcMIzmiipT-Yyx8698II?feat=directlink
[22:27] <rsalveti> prpplague: finally an omap 4 netbook :-)
[22:28] <rsalveti> if you put natty with unity-2d it'll be even better
[22:28] <TitanMKD> hi
[22:36] <prpplague> rsalveti: hehe
[22:36] <prpplague> rsalveti: think there would be demand for it?
[22:36] <rsalveti> prpplague: I'd like to get one :-)
[22:37] <prpplague> rsalveti: with a panda inside?
[22:37] <rsalveti> yup
[22:37] <prpplague> rsalveti: this wasn't designed for the panda to go inside
[22:38] <rsalveti> prpplague: what was the original idea?
[22:38] <prpplague> rsalveti: basically to do netbook development with a stock panda
[22:44] <GrueMaster> From the photo, it looks like someone has a laptop connected to a panda.  Nothing in the photo indicates that the laptop is just a display & keyboard for the panda.
[22:54] <rsalveti> but it's nice either way