=== doko_ is now known as doko === asac_ is now known as asac === lag` is now known as lag [08:55] morning [10:06] hi [10:06] i want to run ubuntu on the beagleboard xM [10:07] i#d prefer a prebuilt sd-card image [10:07] is there anything recent that i can use? [10:08] there is natty alpha-2 images [10:08] noah1989, Ubuntu 10.10 release or a few weeks old Natty image [10:08] i found the 10.10 at http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ [10:08] where do i find the natty images? [10:08] the omap one [10:09] cdimage.ubuntu.con/ubuntu-netbook I think [10:09] ah. found it, thanks [10:10] is there a way to modify it so that it uses the s-video output by default? [10:10] I don't know [10:11] i'm gonna buy a dvi-d cabe just in case... [10:13] ah.. found it: http://elinux.org/BeagleBoardUbuntu#S-Video [10:16] also i need a simple window manager [10:17] preferably with all-fullscreen windows and simple switching [10:17] side by side doesnt make sense at 640x480 [10:21] well maybe two xterms may be useful. i'll stick with awesome === zul__ is now known as zul [12:04] ogra: ping [12:10] doko, yo [12:11] hello [12:11] ogra: I don't have a working babbage board anymore. could you have a look at bug #605042 (and test it) [12:11] Launchpad bug 605042 in linux-fsl-imx51 "[armel] java fails to start with eglibc-2.12-0ubuntu4" [Critical,In progress] https://launchpad.net/bugs/605042 [12:12] just wondering. Is it possible, with natty, to remove the ... how to say ... new panel ? [12:13] I'd like to have the background alone, and make the panel appear when I want. Said differently : not always visible [12:13] doko, hmm, my babbage didnt boot anymore last time i tried (though i didnt inspect it and might have done something wrong) [12:13] doko, can that wait until after A3 ? [12:13] something like a shortcut, e.g. toggle visible /hidden would be great [12:14] ogra: yes, I'll assign it to you for testing [12:15] k [12:15] doko, note that i only have a 2.5 board, thats not what is in the datacenter [12:16] linaro has the 3.0 ones if anyone does [12:16] didn't we have 2.5 in the data center? [12:16] no [12:16] 3.0 [12:17] there are only minro differences iirc but they are not the same [13:37] doko, what is the issue with openjdk-6 on ARM? Not supported well by upstream yet? [13:38] ogra, qt 4.7.2 released :) [13:39] GrueMaster: new kernel for you to test, for omap 4: http://people.canonical.com/~roc/kernel/natty-ti-omap4-dev/ and http://people.canonical.com/~roc/kernel/natty-ti-omap4-dev-linaro/ [13:40] the first one is based on our tree + ti, the other also includes the linaro changes for 38 [13:41] GrueMaster: use the DVI as your default output: console=ttyO2,115200,n8 vram=32M mem=456M@0x80000000 mem=256M@0xA0000000root=/dev/mmcblk0p2 rootwait omapfb.mode=dvi:1280x1024MR-32@60omapdss.def_disp=dvi [13:52] janimo, yes, Riddell announced it this morning in -devel [13:52] rsalveti, any idea how we handle upgrades ? (wrt cmdline) [13:54] ogra: don't think we're handling this now, the image still uses the boot.scr available from the installer [13:54] right [13:54] i'm wondering how to handle it properly [13:54] before using this as default we should for sure make a way to change the default boot args [13:55] the final idea is to have the hdmi driver, so it's more a temporary solution [13:55] but it'd be good to be prepared in case we have similar changes [13:55] i mean, we cant really handle it ... the user needs to plug the monitorf into the other socket [13:55] like once we fix the 1gb bug [13:55] ogra: yeah, at least this [13:55] oh, there are plans for making hdmi work before release ? [13:55] before final release, yes [13:56] * ogra understood that wont make natty [13:56] ah, good then [13:56] but we will still need to mangle boot.scr [13:56] at least this was the plan, and they are heavily working on the hdmi driver atm [13:56] k [13:57] yup [13:57] do you think we could convince them to add a sane default for the resolution so we dont need to touch the bootargs ? [13:57] you mean, for dvi? [13:58] no, for hdmi [13:58] or is hdmi supposed to do edid detection again ? [13:58] for hdmi it'll probe the edid [13:58] and get the best resolution available [13:58] ah, sweet [13:58] yes, that's why I'm also waiting some more for the edid work for omap 3 [13:58] because it'll basically be the same code [13:58] same solution [13:58] yup, saw that [13:59] but we still document a way to update the boot args, when needed [13:59] maybe post inst, not sure [14:00] once we fix the 1g bug we'd like to change that for all the boards, when the kernel is updated [14:00] for example [14:01] i'd like to have some automation [14:01] maybe through u-m [14:02] the function flush_cache_all() flushes all cache or only L1 cache? it's from asm/cacheflush.h [14:05] ogra: could be [14:05] was thinking more like we have for grub [14:06] the legacy vs grub2 update script ? [14:06] with default args and etc, and once a tool is called the boot args would be updated [14:06] thats not automated [14:06] and then write the boot.scr file [14:06] its tricky to handle it if your monitor goes black [14:07] so i would rather like to force it in an automated way [14:07] to make sure the user still sees something [14:07] i'm less concerned about the 1G bit here [14:08] it's just an example [14:08] but about users using milestones that have the DVI stuff and if the HDMI patch does *not* make it also for maverick->natty upgrades [14:10] ogra: we should have at least edid detection, even if it's just dvi [14:11] in initrd ? [14:11] ogra: so then the problem would be the natty milestones, before this feature is in [14:11] no, in kernel [14:11] or as a kernel fix [14:11] ah [14:11] well, if its only milestones we can probably get away with documentation [14:13] ok, that works, then I believe we're fine [15:00] ogra, call time? [15:00] davidm, sure (why do you ping here) [15:01] ogra, you mentioned a free/open libz160 while in Cambridge, tried to find it but I didn't really end up with something, got a url somewhere? [15:02] the one I have from FSL is definitely not open :) [15:04] arm ppas work without special flags these days? [15:22] janimo gone? === brendand_ is now known as brendand [15:40] markos_, asac had it iirc [15:44] ogra: its not free/open because of a stupid license header missing [15:44] ogra: current state is in the canonical-arm ppa iirc [15:45] ogra: i followed up one more time last cycle and never got a reply from Paul whether this is now resolved [15:45] i can check with our fsl LT [15:49] asac, if it's the same one I have, it's *definitely* not open [15:49] the one we had was definitely open, just missing the license [15:50] afaik, fsl built only one libz160 [15:50] and we had been promised severeal times that would be fixed [15:50] could you point me to a url? [15:51] i dont know where asac put it, i have ssen it first in a BSP which i cant make public [15:51] fsl bsp? [15:51] yep [15:51] it's probably the same, hate to let you know, this one is not open [15:51] hmm, they told us differently [15:51] probably some misunderstanding [15:52] it had only 2d accel, EXA support and XV iirc [15:52] no other acceleration [15:52] and back when i touched it it was very crashy [15:52] Neko could comment more on that [15:53] afaik it's closed, I'd love to have it open, but I got a very firm *not open* [15:53] but yes, it's probably the same one [15:54] in fact the one I have here has a zero-sized file "DO_NOT_DISTRIBUTE" [15:54] looks closed to me :) [15:55] the headers are bsd-like licensed though :) [15:56] hmm [15:56] i dont think my version had that [15:56] ogra: its in canonical-arm-dev private iirc or fsl private ... we circled that back tot hem asking to add a COPYING [15:56] some other files in there have a very very firm "AMD_CONFIDENTIAL, DO NOT DISTRIBUTE" [15:56] I'm pretty sure it's not open [15:57] the adm bit is definately not open [15:57] i was talking about the other one === zul__ is now known as zul [16:00] what other one, there is only one library libz160 [16:00] iirc it was called something with 140 [16:02] doko: What do you need testing on babbage 3? I have one still that I keep for SRU testing. [16:04] Hey All [16:05] https://wiki.ubuntu.com/ARM/OMAPMaverickInstall <-- this the best place to find out how to put ubuntu on beagle board [16:06] GrueMaster: bug #605042 [16:06] Launchpad bug 605042 in linux-fsl-imx51 "[armel] java fails to start with eglibc-2.12-0ubuntu4" [Critical,In progress] https://launchpad.net/bugs/605042 [16:07] install the kernel from the bug report, the old eglibc packages (on a maverick chroot). with the old kernel, java -version segfaults, with the new kernel it should not [16:09] I'll have a look. Might not get to it until after A3, but I'll add it to the priority list. === zyga is now known as zyga-food [16:09] Might take a while just to read through the bug log. :P [16:13] any one got a little to give me some noob guidance [16:14] DevilCode: What more info do you need? [16:14] well on the link:https://wiki.ubuntu.com/ARM/OMAPMaverickInstall [16:14] a little stuck on booting the image [16:15] What system do you have? [16:15] with xM rev B [16:15] my SD card is just one partition /dev/sdd1 [16:15] Ok, Follow the instructions for BeagleBoard XM rev A3 and B. [16:16] whats the second partition though [16:16] You need to flash the image to the sd card, not the partition. [16:16] gaaw] [16:16] The image has two partitions. [16:16] sudo dd bs=4M if=ubuntu-netbook-10.10-preinstalled-netbook-armel+.img of=/dev/sdd <--- instead of sdd1 [16:16] yes [16:17] *blush* [16:17] ok [16:17] is a placeholder [16:17] use the right name ;) [16:18] lol [16:18] *dances that i got that right* [16:38] On OMAP4 Blaze Mount the first SD card partition at your host PC and copy the following files to it: [16:38] how do i know [16:38] do you own a blaze ? [16:39] is that a rev V [16:39] rev B [16:39] (did you pay $2500 for your devboard) [16:39] lol no [16:39] right and it doesnt have a case that looks like an elephant mobile phone either i guess :) [16:40] just a cardboard box *sniffle* [16:40] right, so you dont have a blaze [16:40] and you said above you have a beagle [16:40] which is omap3 [16:40] so ignore all omap4 stuff :) [16:40] crap [16:40] i went for the 4 lol [16:40] *start again* [16:40] heh, I think Linaro have most of the worlds blazes :-) [16:42] how many do they have ? [16:42] we have two in the team [16:43] ogra: I dont think TI made very many at all, or 4430sdp [16:43] ogra: I know just getting omap4 hardware for my work was difficult [16:44] yeah [16:44] was difficult for everyone [16:44] ogra: yeah but I was contracted by TI to work on it :-) [16:44] not even enough for their own employees let alone anyone else [16:45] yup, same prob we had [16:46] * XorA is still waiting for his panda :-) [16:49] they are slow creatures :P [16:50] and slow cars [16:50] generally slow [16:50] Yea, but the boards are fast. [16:50] and the animal is tasty [16:50] :P [16:54] http://www.tshirthell.com/funny-shirts/this-shirt-is-100-organic-65-baby-seal-25-panda-10-manatee/ [17:13] rsalveti: I am setting up to test the .38 kernels. Will I be able to output via DVI? My panda didn't have the DVI rework from the TI Rally. [17:14] Nevermind. It's coming up [17:21] GrueMaster: nice [17:22] No X, though. [17:22] Apparently I am not authorized to start it. [17:22] Might have something to do with the TI drivers being installed. [17:24] could be [17:25] for the drivers to work you also need a kernel module [17:25] that for sure you don't have atm [17:25] so just remove them [17:26] right. [17:30] janimo: pong ? [18:08] rsalveti: I'm seeing major problems, but they are likely due to my hacked up image. I'm going to wait until we have a new image to test these kernels with. [18:08] GrueMaster: ok [18:08] we should have new images today [18:08] I really don't want to start fresh with a two week old kernel and try to update it to current. [18:09] Yea, sure. Believe it when I see it. :P [18:09] hehe [18:10] New image build fail reports. Wheee. [18:14] anyone get BeagleBoard running with DirectFB [18:15] DevilCode: try asking #beagle [18:15] kk [18:17] GrueMaster, i guess that was pitti s manually killed build [18:17] Ah. [18:17] * GrueMaster just notes yet another failed build attempt === jhobbs_ is now known as jhobbs === zyga is now known as zyga-afk === zyga-afk is now known as zyga === zul_ is now known as zul === npitre_ is now known as npitre [22:33] Hmm. Looks like sources.list may not be populated. [22:33] not at all ?!? [22:36] Well, that was according to syslog. checking filesystem. [22:36] * ogra checks jasper ... [22:37] No, it's ok. No universe or multiverse though. [22:37] yeah [22:38] longstabnding bug i have on my plate [23:32] bug 650703 [23:32] Launchpad bug 650703 in ubiquity "oem-config-prepare works, but oem-config fails to start after reboot" [High,Confirmed] https://launchpad.net/bugs/650703 [23:45] ogra: hey, got a minute for me to pester you about an ubuntu desktop oddity ? [23:46] prpplague, what is it, i'm trying to debug image breakage atm [23:46] ogra: not important atm, go back to debugging [23:46] (for images we will have to release on thu, so i'm a bit under pressure) [23:46] well, you can still just throw in your question, probably its an easy task [23:48] ogra: i've got 10.10 desktop on both a desktop pc and a netbook, on the netbook the task switch allows me to drag a window from one workspace to another, but on my desktop pc install it doesn't, just curious if there was something quirky about that [23:48] ogra: not really important, just saw you online and thought i'd ask [23:49] well, is the netbook using the netbook UI ? [23:50] ogra: negative, same for both [23:50] ogra: used the same thumbdrive in fact [23:50] thats indeed weird ... possibly worth a bug report [23:52] prpplague: what are your video card at your desktop? [23:52] could be that on your desktop you're actually running with 2 x servers [23:54] rsalveti: hmm that an install option? [23:55] not install, but a runtime option [23:55] for example, with nvidia driver you can select how your x11 will behave [23:55] rsalveti: should i be able to grep the running processes for multiple x? [23:57] prpplague: probably, also check your xorg logs [23:57] rsalveti: intel chipset, but i only see one x running [23:57] I remember I used to run the nvidia driver this way, having two different displays over each monitor [23:57] and I couldn't move one window to the other [23:57] hm, so could be a bug [23:58] rsalveti: i'll dig around some with that [23:58] prpplague: compare both xorg logs [23:58] see if anything pops up [23:58] rsalveti: just an annoyance at this stage, since it _works_ with the latest fedora :P [23:59] you should try our alpha 3 image so ;-) [23:59] once it's available hehe