[00:21] is ubiquity-3d going to be happy with GLES2 (i.e. is someone actively finishing Compiz for GLES2?) for Natty release? [00:24] 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] (once you install compizbackend-gconf and reboot it works fine but fails GL and gives you a "working session" anyway) [00:26] Neko: linaro is doind the for to port compiz to gles [00:26] don't know yet if it'll be ready for natty [00:26] but we'll release at least at a ppa [00:33] so on ARM, default desktop will be unity-2d? [00:33] or unity-3d with the compiz falling back to software? [00:48] Neko: for now default will be unity-2d [00:49] ideally unity-3d would be the default when you have your drivers installed [00:49] and unity-2d the fallback [00:49] only at arm [00:49] at desktop the classic desktop will be the fallback [00:49] unity-3d does fall back properly though [00:49] unity-2d does 3d just fine if the drivers support it. [00:50] (I'd assume so anyway since it's Qt) [00:50] it just doesn't *today* because of some compiz misversioning halfway-uploaded builder mania :) === Jack87 is now known as Jack87|Away [00:51] ah well. I guess we had the weekend to get a stable snapshot of the mirror and missed the opportunity :3 [01:02] ScottK: well, unity-2d with 3d support, from Qt is a little bit different, but yes, 3d still [01:02] the normal unity would be with compiz [01:02] and nux, but still need more work to support gles [02:16] GrueMaster: cool, webkit bug is finally tested [02:16] just running ubiquity again with the slideshow [02:16] working fine [02:16] will update the bug with the debdiff [02:16] more than 15 hours per build [02:16] Sweet [02:17] and at least 2gb of ram to be able to link it [02:17] scary === asac_ is now known as asac [02:17] Now to fix openoffice. [02:17] one step at a time [02:17] :-) [02:17] GrueMaster: I suggest more fire. [02:17] lol [02:17] That takes something like 2 days on x86. [02:17] ouch [02:18] GrueMaster: Uh? libreoffice on i386 finished in 5 hours. [02:18] 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] Systems are a little faster these days. [02:19] The armel build started ... yesterday [02:19] Back then, we created a 4G ram disk to do the build. Watching it with -j 10 was cool (for about 30 seconds). === Jack87|Away is now known as Jack87 [03:49] ogra / rsalveti ping [03:50] prpplague: pong [03:50] rsalveti: hey, i'm totally brain dead this evening but...... [03:50] rsalveti: i need to compile a custom kernel for the panda ubuntu images [03:51] prpplague: ok [03:51] 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] prpplague: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=summary [03:52] for natty [03:52] rsalveti: is that 10.10 ? [03:52] prpplague: ti-omap4-dev gets you to the 38 kernel [03:52] 11.04 [03:52] do you need for 10.10? [03:52] 10.10 is what we have on omapedia, but if 11.04 is current that is fine [03:54] rsalveti: any gotchas on doing a basic install on sd , then replacing the kernel with a custom built one? [03:54] i need to add support for a lvds display via the DPI interface [03:54] prpplague: just need to install the kernel package, that will generate the initrd [03:55] then you need to generate and copy the uInitrd and uImage files to the first partition [03:55] or if you're running the board, just call flash-kernel [03:55] if it's not called automatically already [03:56] rsalveti: is the procedure documented somewhere? [03:59] prpplague: you mean, to build the kernel package? [03:59] rsalveti: correct [04:00] cooloney: do you know the correct wiki page that describe how to build the kernel? [04:00] the kernel wiki list is quite huge [04:04] prpplague: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance may help [04:05] rsalveti: thanks!!! [04:05] * prpplague looks [04:07] I generally cross build it with debuild -eCROSS_COMPILE=arm-linux-gnueabi- -b -aarmel [04:07] but at this wiki you can find all the details on how to maintain your own ubuntu kernel package [04:09] rsalveti: hmm, looks like i need to do some reading tomorrow to come up to speed [04:09] prpplague: yup [04:10] rsalveti: well i'll bookmark and have look in the morning [04:10] i'm totally brain dead [04:10] got the hardware for my netpandabook working today [04:11] rsalveti: just need to get the kernel updated for the ubuntu build [06:26] NCommander: https://bugs.launchpad.net/ubuntu/+source/webkit/+bug/728211 [06:26] Launchpad bug 728211 in webkit "webkit crashes with SIGSEGV on ARM" [Undecided,In progress] [06:26] one merge proposal for the webkit fix [06:33] rsalveti: sorry, just back from lunch. [06:33] rsalveti: yeah, your URL is right. [06:36] cool [06:36] * rsalveti gone, back in 7 hours [06:36] rsalveti: good night [06:37] thks! === daurnima1or is now known as daurnimator [10:23] ogra, managed to upgrade your ac100 to natty? === zul_ is now known as zul [10:24] 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] 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] alf: yes, the "test" binaries, which are in pvr-omap4 package today [11:01] What does this break exactly? [11:03] 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] 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] vstehle: (and still be able to compile using the mesa -dev packages) [11:08] 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] 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] alf: agreed. I'll track that. [11:20] 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] 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] janimo, i see that the tsaksel WI was closed, did it just work ? [12:07] *tasksel [12:33] ogra, GrueMaster closed that, I have not worked on that yet [12:33] so I don;t think it should be DONE unless things just fell into place by default :) [12:34] well, i'll do a test install later today lets see, probably it just runs if the debconf frontend is selected [12:35] 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] since the API's are so differnet 2.0 does not look like a regular 'improvement' [12:36] janimo: gles1 and gles2 are not compatible [12:36] alf, yes I know. But is one preferred over the other when writing new apps [12:37] when peiple tlak about let's port to GLES [12:37] janimo: yes, gles2 [12:37] do they mean both? [12:37] ok [12:37] great, thanks [12:38] janimo: in the sense that programmable gfx pipeline is the future (and there is good support for it even now) [12:38] yw [13:31] ./join #gstreamer [14:01] alf: yeah, makes sense [14:01] will change it together with the new -dev package [14:01] should hit the ppa later today [14:01] rsalveti: cool, thanks [14:02] rsalveti: btw, I am getting a Do you want to continue [Y/n]? y [14:02] 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] rsalveti: on alpha3 image, any ideas? [14:03] rsalveti: (using omap-trunk) [14:03] alf: not yet, will try to reproduce [14:03] I have a fresh a3 that just booted [14:04] alf: this is at the first moment you install the packages? [14:04] or after already installing the mesa ones [14:04] including the -dev package [14:05] after having installed the mesa ones, I do an apt-get install pvr-omap4 [14:06] alf: did you installed the -dev packges first? [14:07] rsalveti: yes mesa -dev packages are installed [14:07] that could be the issue [14:08] will try to reproduce [14:12] rsalveti: FWIW, http://pastebin.ubuntu.com/578346/ [14:12] janimo: would you mind applying merge request from bug 728211? [14:12] Launchpad bug 728211 in webkit "webkit crashes with SIGSEGV on ARM" [Undecided,In progress] https://launchpad.net/bugs/728211 [14:12] rsalveti, will do [14:12] janimo: thanks! [14:12] rsalveti, upload too I presume? [14:13] janimo: yes :-) [14:13] oki :) [14:13] alf: what happens if you remove the -dev packages first? [14:13] alf: trying that now... [14:14] rsalveti: trying that now... [14:15] rsalveti: no improvement :/ [14:15] weird [14:24] anyone in here as experience in doing nfs boot using diferent sub-subnets [14:25] connecting from 192.168.1.xxx to 192.168.10.xxx [14:25] 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] being that the latter is a router connected to the other one [14:26] janimo: hm, ok [14:26] not a problem [14:37] janimo, ++ (on the UNRELEASED part) [14:38] 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] 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] I dislike the need to manually keep in sync the branches and packages [14:41] 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] I guess where the FS is created [14:42] not sure, there is an event entry for "start on oem-config-debconf" but that doesnt seem to exist anywhere [14:42] janimo: thanks [14:43] i think its an ubiquity prob with the upstart job, notthing to do with the image creation [14:45] rsalveti, yw [14:45] once the new webkit package hits the archive we can start using it again at ubiquity [14:46] rsalveti, great. So one week :) [14:46] :-) [14:47] LibO is 1 day 16 hours, Qt is 1 day 14 hours [14:47] alf: just installed it here and it went fine [14:47] alf: after install all mesa packages I installed the sgx ones from the tiomap-dev trunk ppa [14:48] and it went find, could be another bug [14:48] will now try to install back the mesa ones to see if it works fine [14:48] janimo: ouch [14:48] webkit will take more than 1 day for sure [14:49] rsalveti: :/, this means that something is messed up with my setup, wish me good luck ;) [14:50] we'll see after removing the test applications from pvr-omap and having a proper -dev package [14:52] rsalveti, last build was 1 day 1h on armel, so not quite as heavy as Qt or LibO [14:52] sill more than 1 day :-) [14:54] 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] GrueMaster, ok thanks [14:56] GrueMaster, any non-NEON hw around you to see if latest Qt works? [14:56] Yea, but it will need to wait for the caffeine to melt the crud keeping my eyes from focusing. [14:57] GrueMaster, 7 AM at you? Sorry [14:57] Almost. [14:58] Few minutes left. [14:58] 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] wow, i386 webkit build takes 53 minutes [16:04] and the arm one more than 1 day [16:07] rsalveti: almost as bad as OOo [16:07] Order of decreasing time-to-build: OO, Qt, gcc, webkit [16:08] s/OO/LibO/ [16:08] firefox/thunderbird [16:08] should be on that list [16:08] probably [16:09] neh, unde 12 hours [16:09] https://launchpad.net/ubuntu/+source/firefox/4.0~rc1+build1+nobinonly-0ubuntu1/+buildjob/2312427 [16:09] the ones above are over one day [16:11] just noticed chromium FTBFS two days ago without buldlog [16:11] like LibO and Qt back then [16:12] given back === Jack87 is now known as Jack87|Away [18:07] geeez, the headless image is so fast [18:07] ogra: :-) [18:25] how can you say that being an ubuntu dev :P [18:25] ?? [18:25] 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] the latter [18:27] i mean, it doesn't need to have a head, but its the common thing when you think about ubuntu [18:27] heh, being the number one linux distro in cloud deployments doesnt count ? [18:28] ubuntu server comes headless by default ;) [18:28] well, you don't redirect kernel output to serial in the omap4 images :P [18:28] yes, it doesnt make sense on the netbook images and breaks plymouth [18:29] the headless one will have serial === steev_ is now known as steev [18:39] 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] Well, headless would imply serial console only. [18:40] do we want to enforce the installer to run on serial [18:40] headles just implies no graphical interface [18:40] No, headless implies no kvm. [18:40] I don't think it implies serial console only [18:40] ogra, can also imply console text mode interface [18:41] janimo, yes [18:41] I've been doing headless systems for 15 years. [18:41] thats what i mean [18:41] Headless in the industry indicates no local console. [18:41] I mean monitor but no GUI just framebuffer [18:41] No gui is different. [18:41] yes [18:41] well, the question is what do we want to default to [18:42] I believe uart would be better for us [18:42] http://en.wikipedia.org/wiki/Headless_system [18:42] but for the scope of this spec I understood people who don't hook up a monitor just ssh into the hw [18:42] most tutorials and such uses uart when dealing with panda and beagle [18:42] what does linaro do for their nano/dev images? [18:42] As do most headless installs. [18:42] for other arches. [18:43] What does server do for x86? [18:43] console [18:43] they dont even set serial by default [18:43] For headless installs? [18:43] for server installs [18:44] the default iso uses console mode [18:44] you have to change the default to get serial [18:44] Does modern server hw still have UART? [18:44] x86 [18:44] yes [18:45] 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] which you have to configure :P [18:48] 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] we do [18:54] d-i has one [18:55] but you have to tell it to use serial console [18:55] through kernel cmdline and preseeding [19:25] 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] 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] Returns blank if nothing found. [19:28] 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] i.e. jasper would need to know its on a headless image [19:29] we have code for setting the default cmdline in the image builder, i would rather like to use that [19:30] Ok. That will create an image that *only* works one way or the other. My idea could be expanded to auto-detect. [19:30] well, your auto detection would need to be a bit bigger :) [19:31] Might be worth exploring in O. [19:31] not all omap kbds are attached via USB HID [19:31] yes, definitely [19:31] (teh blaze kbd isnt usb afaik) [19:31] Is there another method for attaching a keyboard? [19:31] plenty [19:31] i bet persia could hold a talk about it ;) [19:32] ogra / rsalveti lvds is working, just need to add in the kernel modules to the initrd [19:32] the omap3 evm boards (which should boot with our image) only has a keypad for example [19:32] prpplague: cool [19:32] prpplague, awesome [19:33] 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] not usb [19:33] it's a keymap driver [19:34] its a great idea but definitiely requires more than a grep in demsg [19:34] GrueMaster: i2c, spi, ps2, smbus, usb, and via the omap3/4 keyboard matrix [19:34] ok [19:35] GrueMaster: thats just to name a few [19:35] i think you can detect them on the input device layer though [19:36] Still could be a grep in dmesg. Just need to change the search parameters. The full line looks like this: [19:36] [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] [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] it should better be a udev rule that sets a flag or execs a script [19:37] As I don't have HW to test, I don't know what to suggest to look for, but maybe hidraw0? [19:37] GrueMaster: easiest would be to check the input events, either as part of /dev/input or in sysfs [19:37] you can match against the input subsystem [19:38] GrueMaster: iirc the android framework opens each of the /dev/input/events and check to see if certain buttons are available [19:38] thats lame [19:39] i'm pretty sure there is a way to do it through udev [19:40] well, I guess you can use udev to behave in a similar way [19:40] yup [19:40] without having to walk all input devices [19:40] just dump all events [19:40] and see what can be used [19:40] yep [19:41] i know you can match against SUBSYSTEM=input but i dont know if you get actual info if its a kbd [19:43] 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] and that doesnt use the input subsystem of the kernel ? [19:44] 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] right, thats what i feared [19:45] Better yet, how about we make a simple check based on HW we can test, and let the community add to it? [19:46] 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] the prob will be that you dont see jasper output at all if you dont have the right console before jasper already [19:49] We don't see jasper now, not sure it makes a difference. [19:50] ?? [19:50] Plymouth. [19:50] i see all jasper output in the text splash atm [19:50] the missing text on the graphical theme is a bug that will be fixed before release [19:52] So, what happens if you add console=ttyO2,115200 console=tty0? (other than losing plymouth). [19:52] you will see the boot on serial, oem-config will come up on tty0 [19:53] plymouth will die and jasper will echo to tty0 [19:53] so can't you be smart enough to just open oem-config to the "best" place for the user? [19:53] since thats the default console after the kernel has booted [19:53] like if he's using an usb keyboard [19:54] rsalveti, same issue, you dont see the rezize process [19:54] we need a default at image build time [19:54] for now I'd put ttyO2 as default [19:54] i.e. we need a decision [19:54] good that now it's the same one for omap3 and omap4 [19:54] yep [19:58] k, hedless defaults to console=ttyO2,115200n8 now [19:58] *headless [19:59] 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] we need to cover that in the docs somewhere [19:59] GrueMaster, if you use both, oem-config will pick tty0 [19:59] Then either jasper or some pre oem-config process can decide were to route. [20:00] Also need an /etc/init/ttyO2.conf regardless. [20:00] jasper cares for that [20:00] at least it should ;) if not thats a bug [20:00] Must be a new feature. Not in the latest image. [20:01] while i really like the ideas coming up here, i suspect its all Oneric material [20:01] GrueMaster, bug number ? [20:01] ;:) [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] http://paste.ubuntu.com/578496/ [20:03] thats the code in jasper [20:04] 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] Oh, so it only works if I have console=ttyO2 on the boot cmdline. [20:04] yes [20:05] it copies the upstart job in place if it detects that a serial console is used on first boot [20:06] i simplified the upstart script today, it should work more generically in tomorrows image [20:06] in case there was a bug in it === ogra is now known as Guest18809 === Guest18809 is now known as ogra_ [22:20] ogra_: https://picasaweb.google.com/lh/photo/XBDVyGLKlEfA1qimY9IkpQUEcMIzmiipT-Yyx8698II?feat=directlink [22:27] prpplague: finally an omap 4 netbook :-) [22:28] if you put natty with unity-2d it'll be even better [22:28] hi [22:36] rsalveti: hehe [22:36] rsalveti: think there would be demand for it? [22:36] prpplague: I'd like to get one :-) [22:37] rsalveti: with a panda inside? [22:37] yup [22:37] rsalveti: this wasn't designed for the panda to go inside [22:38] prpplague: what was the original idea? [22:38] rsalveti: basically to do netbook development with a stock panda [22:44] 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] but it's nice either way