/srv/irclogs.ubuntu.com/2010/12/08/#ubuntu-arm.txt

rcn-eeSp0tter, it'll run ubuntu's userspace, you'll have to figure out the kernel stuff yourself..00:16
Sp0tterhmm00:39
Sp0tterdrats i was hoping to just benifit from someone elses previous hard work :)00:39
Sp0tterarchos 32 is too new and not popular enough yet though to have much of a following, so maybe i'll look into it00:40
=== Crisco is now known as zz_Crisco
rcn-eeSp0tter, it might be as easy as copying their kernel and modules into an ubuntu rootfs..01:54
=== asac_ is now known as asac
Sp0tterdefine "their"02:23
Sp0tterit runs android02:23
=== zz_Crisco is now known as Crisco
=== Crisco is now known as zz_Crisco
=== hrw|gone is now known as hrw
=== ogra_ac_ is now known as ogra_ac
=== zyga-afk is now known as zyga
=== dmart_ is now known as dmart
=== zul_ is now known as zul
=== xfaf is now known as zul
=== robclark_ is now known as robclark
apacheloggerrsalveti: so I installed the omap3 graphics foo and now the demo apps fall over http://paste.ubuntu.com/541043/ any clues16:20
apachelogger(Qt also fails to find a EGL display for that matter)16:21
apacheloggeroh ah eh16:48
apacheloggerrsalveti: apparentlyt eh init script failed because we are currently running the n900 with the meego kernel16:48
apacheloggercommented out the ti_something modprobe, and the script worked *but* now it segfaults ^^16:48
* apachelogger thinks that meego kernel and ubuntu sgx stuff does not go well together16:49
=== hrw is now known as hrw|gone
rsalvetiapachelogger: one thing is to make sure your user is also at the video group17:55
rsalvetiapachelogger: and yes, I don't think maemo's kernel will work nicely with these libraries17:55
rsalvetiif you're using it at the n900 you should just grab the meego's sgx libraries17:55
rsalvetithey are also available at meego's repository, just need to convert into deb packages17:56
rsalvetiGrueMaster: why did you create bug 687396? isn't it easier to just change bug 673509 saying that also affects the linaro's kernel?17:56
ubot2Launchpad bug 687396 in linux-linaro (Ubuntu) "Beagleboard-XM chooses a new IP address everytime the interface is brought up (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/68739617:57
ubot2Launchpad bug 673509 in linux (Ubuntu Maverick) (and 1 other project) "Beagleboard-xm chooses a new IP address on each boot (affects: 1) (heat: 12)" [Undecided,Fix committed] https://launchpad.net/bugs/67350917:57
GrueMasterrsalveti: Given the current issues with the kernel team...no.17:57
GrueMasterThe issue is that they rely on a verification- tag, which encompasses the bug, not the package.17:58
rsalvetiGrueMaster: argh, true17:58
rsalvetithat was the reason for quite a lot of confusion lately17:58
GrueMasterThis is also partly why the go around for the panda fix.  The patch listed both bug reports in the commit, so both bug reports get updated when only one kernel gets patched.18:00
rsalvetiGrueMaster: yeah, true18:00
GrueMasterThere are several flaws in the current system.  I think I found 5-6 bugs tagged with verification-needed for kernel updates that I was never informed of.  Mainly for babbage & dove.18:03
rsalvetijanimo: so, it seems that the meego tree is our only choice for the natty cycle18:05
janimorsalveti: yes18:05
rsalvetiI know linaro's testing the omap 3 kernel on it, but it'd be good to make sure it works fine with our tools18:05
rsalvetisuch as rootstock18:05
rsalvetijust got another answer from peter saying that the omap 3 patches are on top of the priority list18:06
rsalvetiand giving the qemu release cycle, those patches are probably going to end upstream luckly for n+118:07
rsalvetiand the worst case for n+218:07
janimorsalveti: right, so for natty we package maemo stuff. I wonder if we need a new source package or is it reasonable easy to patch existing qemu18:07
janimoI haven;t looked yet at qemu packaging internals18:08
rsalvetijanimo: we discussed that at uds, and it seems that it's easier just to create a different package for arm18:08
janimorsalveti: but we need an OMAP3 compatible QEMU soon right?18:08
rsalvetibecause otherwise the server team is going to maintain all these patches in the package itself18:08
janimonotjust by release18:08
rsalvetijanimo: we need a working qemu, omap 3 is just the most used atm18:09
rsalvetithere is another blueprint from the server side, let me find it18:09
janimorsalveti: shall I take this spec over or do you prefer working on it?18:09
* janimo reads the new emails18:11
rsalvetijanimo: https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours18:12
janimorsalveti: still maemo-qemu is a bit of a misnomer at this time18:12
rsalvetijanimo: it'd be good to get the patch set, see how many they are and ask the server team what they think about it18:12
rsalvetiwe're ok for uploading a different package for arm18:12
rsalvetibut if they prefer to apply and maintain all those patches, we're also fine18:12
janimorsalveti: ok, I'll read this spec18:13
janimoso we'd only pick omap3 subset of the maemo tree?18:13
rsalvetijanimo: I'm ok for you taking up this spec, just ping me before closing the WI so I can see the progress :-)18:13
janimorsalveti: ok :)18:13
rsalvetijanimo: probably, and also the arm fixes that could be also not yet integrated18:13
rsalvetijanimo: so please add also new WI18:14
janimorsalveti: not sure what else is in the maemo tree besides those, I need to check18:14
janimoto see what we do not carry over18:14
janimoprobably nokia device specifics18:14
rsalveti- get the patch list of the differences from the upstream tree18:14
rsalveti- talk with the server team to see what they think about maintaining the patches or simply pushing a new qemu-maemo package at the archive18:15
rsalvetijanimo: yup18:15
rsalvetijanimo: - test current linaro's omap 3 kernel with qemu and report back to the server team if it's enough for us, so they can drop versatile18:15
rsalveti janimo https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours18:16
janimoshould I add the last WI to this spec or to our spec?18:17
rsalvetiafter changing our tools to use it, test to see if we get at least the same behavior of the main qemu-kvm package18:17
rsalvetijanimo: to our18:17
janimook18:17
rsalvetijanimo: I'm just pointing this spec, as it's the one that they put a WI to see if they should drop versatile or not18:17
rsalvetidepending on our feedback18:17
janimoso if omap3 works they drop versatile patches from qemu?18:18
rsalvetijanimo: they drop the versatile build from the ubuntu kernel18:20
rsalvetiat maverick, for example, the versatile build only exists because of the need from qemu18:21
rsalvetias it's the only working target for arm18:21
janimorsalveti: I see18:21
rsalvetias we already need an omap 3 build (now maintained by linaro), if we can get qemu working with it there's no need to keep versatile18:21
suihkulokkiwell, there was discussion to make versatile the "virtualized" arm/qemu flavour18:26
suihkulokkieg to get virtio and goodies18:26
rsalvetiyeah, but don't know much about the current state of it18:32
rsalvetiwhat we know is that we have already quite a lot of people using and testing the maemo tree nowadays18:32
rsalvetiand because of that it'd probably be the better choice for us18:33
prpplaguersalveti: whats the git url for the ubuntu x-loader and u-boot?18:39
rsalvetiprpplague: http://gitorious.org/~rsalveti/pandaboard/rsalveti-x-loader/commits/omap4_panda_es2.118:40
rsalvetifor x-loader18:40
rsalvetiprpplague: http://git.linaro.org/gitweb?p=ubuntu/u-boot-linaro-stable.git;a=summary18:40
rsalvetiu-boot18:40
prpplaguersalveti: thanks18:40
* prpplague makes a note so he doesn't have to ask again18:40
rsalvetiprpplague: np :-)18:41
rsalvetiprpplague: any news about the 200/400mhz memory issues?18:41
prpplaguersalveti: none that i am aware of18:42
rsalvetihm, ok :-(18:42
prpplaguersalveti: i think we just had one or two people with boards populated incorrectly18:42
prpplagueiirc those are going to be swapped out18:42
rsalvetiprpplague: oh, ok18:42
GrueMasterprpplague: Any changes to the panda we should be concerned about post ES2.1 A1?18:44
prpplagueGrueMaster: none18:45
prpplagueGrueMaster: the mounting holes will be bigger18:45
GrueMasterMy main concern is a hardware change that needs kernel updates and I have no way to test them.18:45
prpplagueGrueMaster: thats about it18:45
GrueMasterOk.18:45
GrueMasterCan't test the new mounting holes.  Sorry.18:45
GrueMaster:P18:45
ogra_acslacker !18:45
GrueMasterogra_ac: If you were watching what has been happening in the kernel realm, you wouldn't say that.18:46
ogra_aci have18:46
GrueMasterNot the PM's.18:46
ogra_aci think the prob is that the kernel team rotates every cycle so one habit yu have established with someone working on SRUs is lost if the next one comes up18:47
ogra_acwe need clearer rules for them, preferably done by a spec next UDS18:47
ogra_acs/the prob/one prob/18:48
GrueMasterUnfortunately, I have not seen a single trend (other than dropped patches).18:48
ogra_acwell, lets make up a spec for budapest and sort that one and for all18:48
ogra_aci agree that this is an unbearable situation18:49
* GrueMaster feels like more weight will end up on his shoulders.18:49
ogra_aci doubt that18:49
ogra_acwe just need clearly written down rules18:49
ogra_acand people to stick to them indeed ;)18:50
GrueMasterI don't think it is just a set of rules.  We have broken tools.  Launchpad is part of the problem, the scripts that everyone runs in automation is another.18:50
ogra_acwell, thne lets define the rules in a way that human interaction is required for armel kernels ;)18:51
GrueMasterWith launchpad, if we have a bug that crosses multiple packages, we can't rely solely on a verification- tag.18:51
ogra_acthen lets define additional verification tags18:51
GrueMasterThat won't work.  The verification needs to be on a per-package basis and shouldn't be a tag.  This was discussed in the QA CoP.18:52
GrueMasterThe only way to make it work currently is by having separate bugs per package, but then scripts fail when a commit is made that tags multiple bugs.18:53
ogra_acwell, nothing i want to discuss now, but i'm sure if we sit down all together at UDS with the right people we will find a solution18:53
GrueMaster(hence the reason for the misfires on the MAC address bugs).18:54
ogra_acyeah18:54
GrueMasterok18:54
GrueMasterogra_ac: Why does it take so long for new packages to get published in armel?  Is it a manual process?18:58
ogra_acGrueMaster, depends on the package, the kernel chsanges it binary package name with every upload, so it ends up on binary-NEW and needs an archive admin to let it out19:42
apacheloggerrsalveti: tried that, didn't get me far, then again I fear my image was a bit broken yesterday, I'll try again with a new image21:36
rsalvetioh, ok21:36
janimoanyone tried 10.10 omap3 image in qemu? It does not completely boot for me23:24
* janimo tries passing -mtd to qemu23:26
apacheloggerrsalveti: so, I tried again... it only works with their xorg fbdev driver and then X segfaults23:39

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!