[09:58] <hrw> did someone had keyboard-configuration hang on postinst on panda?
[10:01] <hrw> sveinse: have a moment to discuss bug 683832?
[10:01] <ubot2> Launchpad bug 683832 in gcc-4.5-armel-cross "gcc fails to cross compile Qt" [Undecided,Confirmed] https://launchpad.net/bugs/683832
[10:02] <sveinse> Yes, I do
[10:03] <hrw> sveinse: did you tried to compile in ARM mode?
[10:03] <hrw> sveinse: Thumb2 is default
[10:04] <sveinse> hrw, Yes, that works. However I'm if it has any performance impact
[10:05] <hrw> sveinse: for Thumb2 mode you need to check ubuntu qt patches
[10:05] <hrw> there were some for it iirc
[10:06] <ogra> hrw, console-setup being broken is a known issue and not arm specific
[10:06] <hrw> as this bug is a bug in Qt not in gcc
[10:07] <hrw> ogra: ok, but it hangs only on arm for me so thats why I asked here
[10:07] <ogra> no idea whats the workarouns
[10:07] <hrw> ogra: rm /var/lib/dpkg/info/keyboard-configuration.postinst ;d
[10:07] <ogra> if you upgrade to natty you get about 20 requests to configure your kbd
[10:07] <sveinse> hrw, Yes. Qt does have some fixes for the thumb2 issue which I have also tried
[10:08] <hrw> ogra: I am on natty
[10:08] <sveinse> However it fails during early compilation. Let me see if I can find the error.
[10:08] <hrw> and yes, console-setup is insane
[10:08] <hrw> anyway... console-setup does not even lists my keyboards ;S
[10:08] <ogra> hrw, when do you run the keyboard configuration then if you are on natty ?
[10:09] <sveinse> hrw, The reason I'm mentioning this is I'm suspecting some difference between CSL and Linaro/ubuntu gcc
[10:09] <ogra> the issue is that some value is missing in /etc/default/console-setup
[10:09] <hrw> ogra: during "apt-get upgrade"
[10:09] <ogra> ah, k
[10:09] <hrw> sveinse: I think that csl defaults to -marm, ubuntu defaults to -mthumb
[10:09] <ogra> well, thats the same i get when upgrading from maverick then
[10:11] <ogra> hrw, i think its CHARMAP or CODESET being empty that causes this
[10:11] <sveinse> hrw, but for your inital question -marm fixed the compilation as such
[10:17] <hrw> ok
[10:17] <sveinse> hrw, however my qt compilation relies on sysroot... I haven't figured out how to cross compile without it yet (nor has I investigated how to, so its on me)
[10:18] <hrw> sveinse: "xapt install lib1 lib2 lib3" + configure + make
[10:19] <sveinse> hrw, lib1 lib2 lib3 being the libxxx-dev build-depends to the software you're building, right?
[10:21] <hrw> yes
[10:21] <sveinse> elegant!
[10:21] <hrw> works under natty, no idea about maverick
[10:26] <ogra> hrw, why doesnt xapt-get build-dep <my target source package> work ?
[10:26] <hrw> no idea?
[10:26] <ogra> i.e. why doesnt it just stick to apt syntax
[10:29] <hrw> good question
[10:29] <hrw> probably fast written tool while waiting for multiarch
[10:33] <ogra> heh
[10:34] <lool> hrw: hang > that sounds like very very slow perl, I had that a while ago; maybe it's something else though
[10:35] <hrw> lool: I just removed postinstall scripts
[10:36] <hrw> lool: a4tech keyboard which I use do not require extra config. and is not listed in console-setup list anyway
[11:18] <sveinse> hrw, if I check out qt on the master branch (where qt has fixed the thumb2 issue), the compilation fails in the compilation of the first file:
[11:18] <sveinse> {standard input}: Assembler messages:
[11:18] <sveinse> {standard input}:527: Error: thumb conditional instruction should be in IT block -- `strexeq r2,r5,[r6]'
[11:18] <sveinse> {standard input}:528: Error: thumb conditional instruction should be in IT block -- `teqeq r2,#1'
[11:18] <sveinse> Now, I dont know if this is related to GCC or if its a qt issue. Is this familiar?
[11:19] <hrw> familiar
[11:19] <hrw> moment
[11:19] <hrw> check bug 675347
[11:19] <ubot2> Launchpad bug 675347 in gcc-linaro "volatile int causes inline assembly build failure" [Medium,In progress] https://launchpad.net/bugs/675347
[11:20] <hrw> no, it is rather bug 682742
[11:20] <ubot2> Launchpad bug 682742 in thunderbird "thunderbird doesn't build on armel in natty (Error: thumb conditional instruction should be in IT block)" [High,Fix released] https://launchpad.net/bugs/682742
[11:21] <hrw> hm.. not this too
[11:21] <hrw> there was a bug about it...
[11:21] <sveinse> :D
[11:22] <hrw>  bug 490371
[11:22] <ubot2> Launchpad bug 490371 in qt4-x11 "Atomic operations not safe for ARMv7,Thumb-2 and multicore" [Medium,In progress] https://launchpad.net/bugs/490371
[11:23] <hrw> also bug 673085
[11:23] <ubot2> Launchpad bug 673085 in qt4-x11 "Qt/KDE fails to build on ARM without implicit-it=thumb" [High,Fix released] https://launchpad.net/bugs/673085
[11:24] <sveinse> What is the difference of armv6 and armv7? Because the qt fix in 490371 is agains armv6 it seems
[11:25] <ogra> there is a new QT coming this week i was told
[11:25] <ogra> that might fix some of these issues
[11:25] <persia> Could check the beta, unless it's a fix since then
[11:25] <sveinse> ogra, we're using git, not the official snapshots/releases
[11:26] <sveinse> and the armel compilation issue is still present in the head of their branches
[11:26] <hrw> sveinse: there were no optimizations for armv7 in Qt so armv6 ones are used or sth like that
[11:27] <sveinse> I'm a little surprised that qt doesn't fix this, armel build for qt must surely be focus area for nokia
[11:29] <ogra> erm, indeed, our package sets -march=armv6
[11:35] <sveinse> I think I shall check out the qt source package to see if there are any other relevant qt patches for armel
[11:35] <ogra> i think there are a bunch
[11:35] <hrw> probably also check other projects for their patches
[11:37] <ogra> yeah, checking OE usually makes sense for arm patches
[11:40] <hrw> ogra: and vice versa ;D
[11:40] <hrw> ogra: OE has Debian, Ubuntu, Gentoo, Fedora patches
[11:40] <ogra> well, i wouldnt really care for the armv5 patches of debian or fedora
[11:51] <persia> Actually, a lot of the armv5 patches *also* help with armv7 (which is part of why we have all of the Debian ones in Ubuntu)
[12:34] <sveinse> hrw, Do I understand that I should be the one to close bug 683832 ?
[12:34] <ubot2> Launchpad bug 683832 in gcc-4.5-armel-cross "gcc fails to cross compile Qt" [Undecided,Confirmed] https://launchpad.net/bugs/683832
[12:36] <hrw> sveinse: I prefer you to be one, or I can mark it as invalid
[12:41] <sveinse> hrw, done
[12:41] <hrw> thx
[14:33] <ogra> bug 684148
[14:33] <ubot2> ogra: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/684148)
[14:49] <lool> LP #684148
[14:49] <ubot2> Launchpad bug 684148 in unity-2d "[i18n] integrate gettext and use translations from Unity" [High,Triaged] https://launchpad.net/bugs/684148
[14:49] <lool> Ah
[15:04] <rsalveti> ogra: did you move the image script for omap4 to get the new x-loader from the new package?
[15:04] <rsalveti> ogra: then we can request the removal of x-loader-omap4
[15:05] <ogra> rsalveti, can you check if it actually ends up on the image ?
[15:06] <ogra> (yes, i did change the scripts)
[15:06] <rsalveti> ogra: sure, just wanted to ask you first, as I know you changed for omap3
[15:06] <rsalveti> but don't know for omap4
[15:06] <rsalveti> will check the logs
[15:07] <ogra> i changed both at the same time
[15:07] <rsalveti> cool, so we should be fine
[15:30] <zul> hi guys i know you guys you did a lot of work in lucid to get arm working on likewise-open do you guys want to take another crack at it?
[15:30] <apw> ogra, i've got some new kernels previews you might like to test: http://people.canonical.com/~apw/misc/arm/
[15:30] <rsalveti> apw: why preview?
[15:30] <rsalveti> what is special about this kernel?
[15:31] <apw> preview as in the arm kernels take days to build in the archive so won't be in there for at least another 24 hours
[15:31] <apw> so these are hand built for earlier access
[15:31] <rsalveti> apw: oh, ok, cool
[15:31] <rsalveti> will give it a try now
[15:43] <rsalveti> weee, kernel panic while installing new deb hehe
[15:43]  * rsalveti is trying again
[15:57] <hrw> ogra: ac100 has sata internally used?
[15:58] <ogra> no
[15:58] <hrw> ogra: emmc storage?
[15:58] <ogra> yep
[15:59] <rsalveti> apw: eeek, not good
[16:00] <hrw> thx ogra
[16:00] <apw> rsalveti, s'up
[16:00] <rsalveti> apw: http://paste.ubuntu.com/559064/
[16:00] <rsalveti> warning but later on failed to start omapfb
[16:00] <rsalveti> so, no display
[16:00] <apw> rsalveti, not sure if the warning matters per-see
[16:01] <apw> not having a framebuffer looks more annoying
[16:01] <rsalveti> yeah, don't know if they are related atm, need to properly check the code
[16:01] <apw> rsalveti, yeah
[16:02] <rsalveti> well, at least some fun debugging time for later today
[16:04] <apw> rsalveti, yeah :)  we have a couple of days (well two i guess) before we freeze for A2
[16:06] <rsalveti> apw: ok, ping you back if I get any other news about it
[16:06] <KC9SJQ> Hey all.
[16:07] <apw> rsalveti, thanks ... i note there is exactly one commit between v2.6.37 and the tip for omapfb
[16:07] <KC9SJQ> Going from ubuntu netbook version to ubuntu desktop is just a matter of removing ubuntu-netbook package and installing ubuntu-desktop, right?
[16:08] <rsalveti> apw: cool, just checkout out the git tree
[16:11] <apw> rsalveti, ok that warn_on is telling you you  have an erratum
[16:11] <apw>         if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
[16:12] <apw> rsalveti, any idea what graphics driver one should have?
[16:12] <GrueMaster> Wow.  Firefox is using 172% of cpu on omap4, reporting an oem-config crash bug.
[16:17] <apw> rsalveti, do you have the whole of the dmesg
[16:18] <rsalveti> apw: not yet, checking the code atm
[16:18] <rsalveti> apw: sure, 1 sec
[16:21] <rsalveti> apw: http://paste.ubuntu.com/559074/
[16:22] <rsalveti> [    0.147460] Unable to get DVI reset GPIO
[16:23] <rsalveti> [    4.675109] regulator_init_complete: VPLL2: incomplete constraints, leaving on
[16:23] <rsalveti> [    4.682983] regulator_init_complete: VDAC: incomplete constraints, leaving on
[16:24] <apw> commit f8362d215549c66066f78e67c033dd370ae50322
[16:24] <apw> Author: Koen Kooi <koen@beagleboard.org>
[16:24] <apw> Date:   Tue Jan 11 17:13:36 2011 +0000
[16:24] <apw>     omap3: beaglexm: fix DVI reset GPIO
[16:24] <apw> rsalveti, th
[16:25] <apw> rsalveti, though we _have_ that in the kerenls you are running
[16:25] <apw> rsalveti, is this an XM or regular
[16:25] <rsalveti> XM
[16:29] <apw> rsalveti, i idly wonder if yours is on the other gpio number
[16:31] <apw> rsalveti, the v2.6.37 based kernel worked on your xM didn't it?
[16:31] <apw> rsalveti, diffing to there there is no mention of the 129 gpio in the code before
[16:32] <rsalveti> apw: 37 worked fine
[16:32] <apw> rsalveti, also i see that things like cpus and swap coming up in the dmesg, were you able to login to the machine remotely?  i suspect other than the display it came up
[16:32] <rsalveti> apw: yup, login works fine
[16:33] <apw> rsalveti, i think i might suggest that you try as a first stab making this bit always use 170
[16:33] <apw> +       if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
[16:33] <apw> +               beagle_dvi_device.reset_gpio = 129;
[16:33] <apw> +       else
[16:33] <apw> +               beagle_dvi_device.reset_gpio = 170;
[16:33] <apw> as i think in 27 it always used 170 for all beagles
[16:34] <apw>  static struct omap_dss_device beagle_dvi_device = {
[16:34] <apw>         .type = OMAP_DISPLAY_TYPE_DPI,
[16:34] <apw> [...]
[16:34] <apw> -       .reset_gpio = 170,
[16:34] <apw> was the old .27 code
[16:36] <rsalveti> apw: at maverick we have this change, but differently
[16:36] <rsalveti> but also using 129 for xm
[16:36] <rsalveti> so it should be fine
[16:37] <rsalveti> but weird that it worked fine for 37
[16:37] <rsalveti> if it was only using 170
[16:37] <apw> rsalveti, welll not necessarily
[16:37] <apw> static int beagle_enable_dvi(struct omap_dss_device *dssdev)
[16:37] <apw> {
[16:37] <apw>         if (gpio_is_valid(dssdev->reset_gpio))
[16:37] <apw>                 gpio_set_value(dssdev->reset_gpio, 1);
[16:37] <apw>         return 0;
[16:37] <apw> as the platform init does that
[16:38] <rsalveti> on maverick the reset_gpio was struct was set as 170
[16:38] <rsalveti> but then we had a check at beagle_display_init
[16:38] <rsalveti> then then set it correctly if it's a xm
[16:39] <rsalveti> *that then
[16:39] <apw> but then that other check may occur in time before it or something
[16:39] <rsalveti> so 37 probably had something similar
[16:40] <apw> using the diff from v2.6.37 and the tip of natty 129 does not appear with a -
[16:40] <apw> ie if it was there its still there
[16:43] <apw> rsalveti, we might also consider putting the failed gpio pin number in the error on failure
[16:43] <apw> might help know if its an init ordering issue
[16:45] <apw> rsalveti, hrm how much did you miss i wonder
[16:45] <rsalveti_> let me check the logs from bip
[16:46] <rsalveti_> rebooting my host pc, got dead for some unknown reason
[16:46] <rsalveti_> natty
[16:46] <apw> hrm
[16:46] <rsalveti_> still 37 :-)
[16:46] <rsalveti_> but with btrfs
[16:46] <apw> :) good
[16:46] <apw> :( bad
[16:47] <rsalveti_> yeah :-(
[16:48] <apw> rsalveti_, so any oppinion as to what debug to shove in, and will you do it, or do you need me to make kernels
[16:48] <rsalveti> don't worry, I can check this here
[16:48] <rsalveti> and easily cross build the kernel
[16:49] <apw> ok cool ... i guess we are at 'have h/w will debug stage' so i'll get out your hair
[16:49] <rsalveti> ok, ping you back with more results later
[16:49] <rsalveti> thanks anyway
[16:49] <ogra> where do you have his hair ? in a drawer ?
[16:50]  * ogra imagines apw with a rsalveti wig
[16:50] <apw> rsalveti, :)  thanks
[16:50] <apw> ogra, with mine yep :)
[16:50] <ogra> *g*
[16:52] <apw> rsalveti, do keep me in the loop as i will need to upload pretty soon for A2 as you know and i have some bits for aufs pending which i would batch up with yours :)
[16:52] <rsalveti> apw: sure, np
[16:59] <GrueMaster> Hey, maybe we can use these as buildd's.  Quad core Cortex A9, portable (small), what's not to like?  http://games.slashdot.org/story/11/01/27/1432205/Sony-Reveals-the-Next-Generation-Portable-Console
[17:20] <prpplague> GrueMaster: hehe
[17:21] <prpplague> GrueMaster: i suspect it isn't going to be quad core
[17:21] <prpplague> GrueMaster: first versions probably with just be dual core
[17:22] <GrueMaster> I just saw the article and the mention of quad core Cortex-A9.  I have no detailed specs yet, but haven't looked either.
[17:49] <ClubPetey> hey all, I'm trying to get the 10.04-server-armel+omap image working with qemu (emulating a beagleboard).  I have it booting to the install script (where you select a language) but the keyboard doesn't work.  I ran a debian image just fine with the same emulator, so I'm starting to think it's not the qemu build.Anyone experience this before?
[18:04]  * apw wonders how rsalveti is getting on :)
[18:07] <rsalveti> apw: waiting a build to finish, to properly check what's happening, my host seems quite unstable atm :-(
[18:07] <rsalveti> had to reboot 2 times already
[18:07] <rsalveti> apw: how is the 38 testing going?
[18:07]  * rsalveti thinking about changing to 38
[18:08] <rsalveti> but heard people were facing lots of issues with it
[18:08] <apw> rsalveti, ahh how long does it takeing
[18:08] <apw> my machines here are running .38 based kernels, previews like the arm ones, but i'd not say i was stressing them
[18:09] <rsalveti> apw: hm, what are you running at your desktop?
[18:09] <rsalveti> 38?
[18:09] <apw> this machine is back furhter than that
[18:10] <apw> my other smaller boxses are on the preview though
[18:10] <apw> running unity, when it works
[18:10] <rsalveti> hehehe
[18:10] <rsalveti> mine is very broken
[18:11] <rsalveti> using classic desktop atm, with metacity instead of compiz 2d
[18:11] <apw> so this machine is all uptodate, including the upcoming kernel
[18:11] <apw> and its holding together mostly, well as long as you remeber to right click to get the menus working
[18:12] <rsalveti> hehe, cool, maybe will update mine later on
[18:12] <rsalveti> today
[18:12] <apw> but i've not got the guts to put it on my bigger machine as i am not yet ready for the paradigm shift
[18:13] <apw> just about to do an update on a desktop
[18:14] <rsalveti> something to check later is why it's powering DVI down using 170 as a hardcoded value at omap3_beagle_init
[18:15] <rsalveti> while when starting up it checks if it's running xm or not, and select the proper gpio pin
[18:16] <rsalveti> don't know what is connected to 170 at xm
[18:16] <rsalveti> need to check the hw docs
[18:37] <apw> rsalveti, this bit you mean:
[18:37] <apw>         omap_mux_init_gpio(170, OMAP_PIN_INPUT);
[18:37] <apw>         gpio_request(170, "DVI_nPD");
[18:37] <apw>         /* REVISIT leave DVI powered down until it's needed ... */
[18:37] <apw>         gpio_direction_output(170, true);
[18:37] <apw> looks like it should be using the reset_gpio as well indeed
[18:38] <rsalveti> yup
[18:38] <apw> maybe... hard to tell it does use different descriptions
[18:38] <apw> as if 170 is power and 129 is reset on xm, but both on !xm
[18:39] <apw> all depends on semantics i guess
[18:39] <apw> the docs sounds like ones freind here for sure
[18:43] <apw> rsalveti, the below sounds bad:
[18:43] <apw> "Passing invalid GPIO numbers to gpio_request() will fail, as will requesting
[18:43] <apw> GPIOs that have already been claimed with that call."
[18:43] <apw> as far as i can tell for !xm we would request 170 twice and violate that
[18:44] <apw> which would lead to that error ...
[18:44] <rsalveti> hm, makes sense
[18:45] <rsalveti> on maverick this was remove with commit 8c3818913431c5ae62a7e56a38d38c4ca81ee4a2
[18:45] <rsalveti> let me check 37
[18:46] <apw> rsalveti, oh yeah its removed ... hrm
[18:47]  * rsalveti is still waiting his build to finish
[18:47] <apw> rsalveti, how long do they take ?
[18:48] <rsalveti> this is the first one, then I can just make what changed
[18:48] <rsalveti> but 30 min probably
[18:48] <rsalveti> apw: if it's faster for you, can you try removing that out and build it again?
[18:48] <apw> rsalveti, about the same once i've pushed it so you can get to it
[18:49] <apw>         omap_mux_init_gpio(170, OMAP_PIN_INPUT);
[18:49] <apw>         gpio_request(170, "DVI_nPD");
[18:49] <apw>         /* REVISIT leave DVI powered down until it's needed ... */
[18:49] <apw>         gpio_direction_output(170, true);
[18:49] <apw> seems it was in there for .37
[18:49] <apw> which is perplexing
[18:49] <rsalveti> hm, not from one I'm seeing here
[18:49] <rsalveti> from Ubuntu-2.6.37-9.22
[18:49] <rsalveti> let me check again
[18:50] <rsalveti> git show Ubuntu-2.6.37-9.22:arch/arm/mach-omap2/board-omap3beagle.c
[18:50] <rsalveti> sounds fine
[18:50] <apw> yeah
[18:50] <apw> yep clearly new...
[18:50] <apw> shall i build without that in parallel ?
[18:51] <rsalveti> apw: sure
[18:53] <apw> rsalveti, i can see how that got lost, as we dropped all the omap stuff for XM as it was coming down in spades from upstream ... clearly not all of it
[18:54] <rsalveti> apw: yup, the same patch that changes to use 129 is the one who removes this piece
[18:54] <rsalveti> and you got a conflict and probably just removed the patch
[18:55] <apw> yep thats what i would have done, there is clearly stuff in there saying "added support for Xm" so it would be a simple choice to drop
[18:55] <apw> rsalveti, heres hoping thats the main issue
[18:56] <apw> if i had been diffing to a sensible place for .37 i'd have noticed that too ... silly me
[19:05] <apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre5_armel.deb-2
[19:05] <apw> rsalveti, stupidly i made it with the same pre5 name ...
[19:05] <rsalveti> apw: awesome, mine is still building =\
[19:05] <apw> rsalveti, just tried a new way to copy it ... saved self 15 mins
[19:06] <apw> avoided a tortuos upload over my adsl
[19:06] <rsalveti> nice
[19:07] <apw> rsalveti, just tell me it works :)
[19:08] <rsalveti> we'll see :-)
[19:08] <apw> i suspect the testing will be as slow as the build :)  its never easy to get a kernel onto one of those
[19:08] <rsalveti> yeah, very slow sd card
[19:10] <apw> "oh no you want to <pause> save a lot <pause> of files to <pause> me ..."
[19:16] <rsalveti> argh, panic while installing
[19:16] <rsalveti> rebooting and trying again
[19:17] <apw> rsalveti, noo
[19:23]  * apw drums his fingers in agitation
[19:23] <rsalveti> Linux version 2.6.38-1-omap (root@tangerine) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.1-10ubuntu3) ) #27~pre5 Thu Jan 27 18:53:05 UTC 2011 (Ubuntu 2.6.38-1.27~pre5-omap 2.6.38-rc2)
[19:24] <rsalveti> still same issue
[19:24] <apw> thats the rigth timestamp
[19:24] <apw> poop
[19:27] <rsalveti> that was the only thing that is actually different at the board-omap3beagle.c from our 37 to mainline
[19:27] <apw> i would say i tend to concur, there is some odd ordering, but nothing 100% different
[19:27] <apw> s/odd/difference in
[19:27] <rsalveti> yeah
[19:28] <rsalveti> oh god, trashed my sd card :-(
[19:28] <rsalveti> too many kernel panics while booting
[19:28] <apw> rsalveti, oh
[19:28] <apw> -       if (cpu_is_omap3630())
[19:28] <apw> -               beagle_dvi_device.reset_gpio = 129;
[19:28] <apw> -       else
[19:28] <apw> -               beagle_dvi_device.reset_gpio = 170;
[19:28] <apw> -
[19:28] <apw>         r = gpio_request(beagle_dvi_device.reset_gpio, "DVI reset");
[19:28] <apw> is that difference significant
[19:28] <rsalveti> 37 has an issue with the mmc driver it seems, so sometimes giving i/o errors all around
[19:28] <rsalveti> but the same logic is applied later on
[19:29] <apw> yeah but note, that the line after the context uses it
[19:29] <apw> so is the other place its added, earlier in execution
[19:29] <rsalveti> beagle_display_init is the last function from omap3_beagle_init
[19:30] <rsalveti> beagle_twl_gpio_setup is a .setup from beagle_gpio_data
[19:30] <rsalveti> that gets registered at omap3_beagle_i2c_init
[19:30] <apw> +       if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
[19:30] <rsalveti> and probably calls the .setup
[19:31] <apw> -       if (cpu_is_omap3630())
[19:31] <apw> and we know those are the synonymous
[19:31] <rsalveti> that could be another diff, but that would break a lot of stuff for xm
[19:31] <apw> yeah tend to agree
[19:33] <rsalveti> only if .setup is not being called before beagle_display_init
[19:33] <rsalveti> but need to check the callbacks
[19:33] <apw> rsalveti, perhaps i should just print it in the routine
[19:33] <rsalveti> apw: that would do it
[19:33] <apw> you got a testable system if i slam in some dbg ?
[19:34] <rsalveti> sure
[19:34] <rsalveti> put some printks all around and lets see
[19:39] <GrueMaster> Out of curiosity, when will we be seeing a new omap4 kernel?
[19:40] <apw> rsalveti, ok building a new one with loads of output
[19:40] <apw> GrueMaster, thats in ti's hands
[19:40] <apw> (isn't it?)
[19:40] <GrueMaster> Ah, ok.
[19:40] <rsalveti> GrueMaster: yup, ti released a new version, but not that well tested
[19:40] <rsalveti> as I reported at the meeting today
[19:40] <rsalveti> so they are waiting to add support for es2.2
[19:40] <GrueMaster> You expect me to actually be awake for that meeting?
[19:40] <rsalveti> then will probably request us to update it
[19:40] <rsalveti> :-)
[19:41] <apw> rsalveti, what was it based on ?
[19:41] <rsalveti> now for the 38 is a completely different history
[19:41] <rsalveti> apw: 35 still
[19:41] <apw> .35 ? thats ... erm ... old
[19:41] <rsalveti> hehehe
[19:42] <rsalveti> that's.... ermm.... ti?
[19:42] <rsalveti> they are building a landing team at linaro to care about pushing stuff upstream
[19:47] <apw> rsalveti, well thats something ... wonder what chance we have of having a kernel in time ...
[19:48] <rsalveti> yeah, that's what worries me the most
[19:52] <apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre6a_armel.deb
[19:53] <rsalveti> let me try
[19:54]  * apw whips rsalveti to get a result :)
[19:55] <apw> rsalveti, there will be much APW noise
[19:55] <rsalveti> :-)
[19:57] <apw> rsalveti, ok have to run to the shop to get some food in ... back in 20
[19:57] <rsalveti> apw: ok
[20:06] <rsalveti> apw: eeek: APW: beagle_display_init: reset_gpio=-22
[20:07] <rsalveti> the function that initializes reset_gpio is called later on
[20:07] <rsalveti> so that's why
[20:08] <rsalveti> so we need a patch to move this as before and also removing the settings for the hardcoded gpio
[20:08] <rsalveti> the 170 one
[20:13] <rsalveti> apw: http://paste.ubuntu.com/559192/ will probably be enough
[20:14] <rsalveti> just need to build and test
[20:16] <GrueMaster> janimo_: can bug 697382 be reproduced on other arches now?
[20:16] <ubot2> Launchpad bug 697382 in pyside "ftbfs on armel" [Undecided,New] https://launchpad.net/bugs/697382
[20:16] <rsalveti> renatofilho: ^ :P
[20:16] <janimo_> GrueMaster, yes, it fauils on x86 too
[20:16] <janimo_> it is a cmake isseu from what I can tell
[20:16] <GrueMaster> Ok, will tag appropriately.
[20:17] <janimo_> pyside 1.0 beta4 is out but still not in debian too see if it fixes it
[20:17] <janimo_> I think doko's archive rebuild should point out if pyside fails on all archs now (if it inlcudes universe)
[20:19] <renatofilho> GrueMaster, this was fixed some time ago on pyside check bug: http://bugs.openbossa.org/show_bug.cgi?id=415
[20:19] <ubot2> bugs.openbossa.org bug 415 in PySide "phonon bindings does not build" [Major,Closed: fixed]
[20:20] <GrueMaster> Ok.  Hasn't hit the pool yet then.
[20:20] <rsalveti> renatofilho: cool, thanks :-)
[20:22] <rsalveti> apw: I'm firing up another build, but it'll probably take longer than yours
[20:22] <rsalveti> apw: can you try rebuilding your deb with the supposed fixes when you're back?
[20:36] <apw> rsalveti, just back
[20:41] <apw> rsalveti, ok build in progress
[21:01] <apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre6b_armel.deb
[21:04]  * apw pokes rsalveti 
[21:07] <rsalveti> apw: sorry, getting something to eat
[21:10] <rsalveti> installing
[21:13] <apw> heh no worries
[21:18] <rsalveti> apw: that error is gone, but still no display
[21:18] <rsalveti> one less bug at least
[21:20] <rsalveti> let me get the dmesg for you
[21:24] <apw> rsalveti, ok cool
[21:29] <rsalveti> apw: http://paste.ubuntu.com/559224/
[21:30] <rsalveti> then same messages for omapfb
[21:40] <rsalveti> hm, I don't like having a warning for an erratum
[21:40] <rsalveti> just a kernel message saying it would be enough
[21:41] <rsalveti> let me put more debug at omapfb
[21:43] <rsalveti> seems it's not getting a proper dss device
[21:43] <rsalveti> and I just noticed that we have 18 patches against dss at l-o
[21:43] <apw> yeah WARN is dumb as it will trigger apport etc for no reasdn
[21:43] <apw> rsalveti, worth looking indeed
[21:44] <apw> rsalveti, what timezone you in?
[21:44] <rsalveti> apw: utc-2
[21:44] <apw> so its near midnight ?
[21:44] <rsalveti> almost 8 pm
[21:45] <apw> hrm ok :)  thinking its food time here, but i can provide build services in the AM if thats helpful
[21:46] <rsalveti> apw: sure, don't worry :-)
[21:46] <rsalveti> my new build just finished, so it should be ok now
[21:48] <apw> excellent, speedyier once one is done
[21:48] <apw> i'll catch you in the morning see how it all went
[21:48] <rsalveti> ok, thanks!
[22:44] <GrueMaster> rsalveti: Have you seen the latest patch link attached to the panda MAC bug?  bug 673504
[22:44] <ubot2> Launchpad bug 673504 in linux-ti-omap4 "Pandaboard chooses a new IP address on each boot" [High,Fix committed] https://launchpad.net/bugs/673504
[22:45] <GrueMaster> THis would really be helpful for us and for the buildd pool (if it ever gets online).
[22:45] <rsalveti> GrueMaster: yup, sounds fine, just didn't follow if it's upstream or not already
[22:57] <Neko> hey guys, any reason why linux-headers does not pull in the plat-mxc/include/* stuff into the headers here?
[22:57] <Neko> I'm just using make-kpkg and wondering if there is some clever overlay trick to it
[23:13] <apw> Neko, probabally an oversite as things have moved over time, if there is something needed in there then get a bug filed saying they are missing
[23:14] <Neko> well what I'd like to do is file a bug and ship a patch at the same time
[23:14] <Neko> but I am having trouble working out how I'd detect the scenario
[23:14] <Neko> I can't tell what machine the kernel is built for...
[23:14] <Neko> only the arch
[23:15] <Neko> it seems like the whole kernel thing just never ever worked for any arm platforms and this would affect arm on debian too
[23:15] <Neko> or worse, linux kernel doesn't do it
[23:52] <rcn-ee> Hey Neko in 2.6.38-rc's the mainline deb-pkg now generates linux-headers, but like make-kpkg it too only seems to generate x86 stuff..