[00:20] <playya_> how much space is required to bootstrap ubuntu-minimal on ARM?
[04:24]  * mozzwald is away: snore...
[07:17] <EthanZ6174> how can i get a arm-ubuntu source list?
[07:17] <EthanZ6174> i got so many 404 when i use the kind of normal ones..
[08:21] <hrw> morning
[08:36] <cooloney> amitk: around?
[08:36] <amitk> cooloney: yes
[08:36] <cooloney> amitk: i am looking at the OTG config issue you pointed out yesterday
[08:37] <cooloney> from the git log, i think you revert the patch which enabling the OTG in the kernel
[08:37] <cooloney> so why you revert that?
[08:37] <cooloney> OTG driver doesn't work at all?
[08:39] <amitk> cooloney: that config was causing OOPs, IIRC. So we need to see if some more patches are necessary
[08:40] <cooloney> amitk: yeah, i guess so. so firstly we enable the OTG as the omap3 beagle board defconfig
[08:40] <cooloney> and test and file another bug?
[08:40] <cooloney> i think OTG should be built-in
[08:41] <cooloney> oh, maybe the dmesg.txt from ogra_cmpc in the LP is from a kernel which built-in OTG stuff
[08:51] <amitk> cooloney: if possible OTG should be a module so we can switch between different gadget drivers - audio, ethernet, gadgetfs, mass storage, etc.
[08:52] <amitk> cooloney: actually, only the USB Gadget drivers need to be modular, the HW-specific driver can be compiled in
[08:53] <amitk> cooloney: http://paste.ubuntu.com/449992/ is the diff for that should enable OTG
[08:53] <amitk> s/for//
[08:56] <cooloney> amitk: i agree, gadget upper level drivers should be modulars, and TI OTG controller driver should be built-in
[08:57] <cooloney> amitk: after a study of the oops from the dmesg, i think we missed to built-in the OTG transceiver driver as well as OMAP OTG driver
[08:57] <cooloney> amitk: let me try to build in them and post a kernel for testing
[09:01] <lag> Good morning every-peeps
[09:03] <amitk> morning lag
[09:03] <lag> Hey amitk
[09:08] <cooloney> lag and amitk morning. -:)
[09:09] <lag> Morning cooloney, I'm just replying to your emails
[09:13] <lag> cooloney: How far have you progressed with the Maverick - Panda kernel?
[09:15] <cooloney> lag: I added some panda supported yesterday, and sebjan will review that. if that's ok, i will send out for review and pull
[09:15] <cooloney> lag: for the bug #592295
[09:15] <ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/592295
[09:16] <cooloney> lag: is on .33 or .34?
[09:16] <cooloney> and i think you may have some solution now
[09:17] <lag> cooloney: 2.6.34-900-omap4
[09:18] <lag> If you send me a .33 kernel, I can see if the problem is a lasting one
[09:18] <lag> cooloney: I have seen your solution, but I think I have a neater one
[09:19] <cooloney> lag: ok, got it, but in the LP post, you said it is 2.6.33-900-omap4
[09:19] <cooloney> lag: ok, cool, i don't have the hardware. hehe
[09:21] <lag> In which case, I have tested it on both
[09:21] <lag> So it is .33 and .34
[09:22] <lag> cooloney: Have you read your emails?
[09:23] <cooloney> lag: oh, just got it.
[09:24] <lag> ;)
[09:24] <cooloney> for the .34 repo, git://kernel.ubuntu.com/roc/ubuntu-maverick.git ti-ubuntu-2.6.34
[09:24] <cooloney> i think sebjan will do his work based on this branch
[09:25] <lag> Does that boot?
[09:25] <cooloney> hmmm, i think you told me it boots from you panda
[09:26] <cooloney> hehe
[09:26] <lag> If it's the same one you sent me yesterday it does
[09:26] <cooloney> and after sebjan fixed his kernel cmdline, he boots that kernel on his panda too
[09:26] <lag> However, I tried to build it and it didn't boot
[09:26] <cooloney> lag: yeah, it is the same
[09:26] <cooloney> lag: really?
[09:26] <lag> Yeah, really
[09:26] <cooloney> you built from the same tree, but does not boot?
[09:27] <cooloney> oh, maybe you are trying the my old base
[09:27] <cooloney> so which commit SHA is your base in you building tree
[09:27] <lag> It's the one on kernel.ubuntu.com
[09:27] <lag> Wait one
[09:27] <cooloney> np
[09:28] <lag> ea34fca089b7ab2986ff391f1fc036d4425e6995
[09:29] <cooloney> oh, sorry, that is not including the panda support
[09:29] <cooloney> pls just git fetch
[09:29] <cooloney> and rebuild,
[09:30] <lag> That was the latest when you went offline last night
[09:30] <lag> :(
[09:30] <lag> I thought it was something I was doing wrong!
[09:30] <cooloney> lag: oh, sorry, hold on,
[09:30] <cooloney> could you post your git log --oneline?
[09:31] <lag> I've just fetched
[09:32] <cooloney> ok,
[09:32] <cooloney> that should be the same as my kernel source, i think
[09:33] <cooloney> you are using sbuild or just crosscompile
[09:41] <lag> cooloney: It's still at ea34fca089b7ab2986ff391f1fc036d4425e6995 UBUNTU: SAUCE: fix changelog for our target release - maverick
[09:41] <lag> Even after a fetch
[09:48] <cooloney> lag: yeah, i think you got the same kernel source as me
[09:48] <lag> And that should work?
[09:48] <cooloney> yeah, i built the kernel package from that.
[09:48] <cooloney> and uploaded to you and sebjan
[09:49] <cooloney> so is there any error message when you was booting your own built kernel?
[09:49] <lag> Nope, I just don't receive any output
[09:52] <cooloney> lag: hmmm, too bad, no idea about that. you changed the kernel cmdline or something?
[09:53] <lag> Nope, I'm using the same one
[09:53] <lag> When I do a diff on or images, they 'differ'
[09:53] <lag> Is ea34fca089b7ab2986ff391f1fc036d4425e6995 your final commit?
[09:55] <cooloney> yeah, i didn't change anything since that
[09:57] <cooloney> lag: you are using sbuild or just cross compiling?
[09:59] <lag> I'm just using schroot
[09:59] <lag> I'm using the build scripts
[10:05] <cooloney> lag: the kernel i uploaded yesterday is cross compiled
[10:07] <lag> Okay
[10:07] <lag> Let me try it again
[11:36] <cooloney> ogra_cmpc and amitk, i updated bug #566645
[11:36] <ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 2) (heat: 70)" [High,Confirmed] https://launchpad.net/bugs/566645
[11:38] <hrw> http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/
[11:43] <zumbi> hrw: congrats! can you try powerpc or mips/el?
[11:44] <hrw> zumbi: thats dpkg-cross way
[11:44] <zumbi> hrw: yes, but binary-*-cross.mk merged into binary-*.mk?
[11:45] <hrw> zumbi: no, this is still on a list
[11:46] <zumbi> oh! ok, also biarch cross compilers were broken for multilib and non-multilib builds, on lenny used to work fine
[11:47] <zumbi> anyway, well done :)
[11:47] <hrw> zumbi: gcc-4.5 cross work resulted in a set of fixes
[11:47] <zumbi> in a couple weeks I hope to have some time available to help out
[11:47] <hrw> zumbi: https://edge.launchpad.net/ubuntu/+spec/arm-m-cross-compilers has them linked
[11:48] <zumbi> i remember you showing me a patch
[11:56] <JameswStubbs> Hello, anyone here who can give some advice?
[11:56] <lool> zumbi: We dont have mips/mipsel in Ubuntu and powerpc in not in the main priorities of Linaro, it's more a Debian thing, but that should just work -- problem is that the patches aren't in the Debian toolchain yet
[11:58] <lool> JameswStubbs: don't ask to ask   ;-)
[11:58] <hrw> lool: those patches are also not in ubuntu toolchain yet
[11:59] <lool> hrw: Ok, did you apply any to build http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ ?
[12:00] <JameswStubbs> Ok then, basically I've built a Ubuntu minimal rootfs using rootstock and have it mounted in qemu with networking, I'm trying to install matchbox. I've installed xorg, and all the matchbox applications but I need GTK, Is there a way to do this without installing the full gnome enviroment?
[12:00] <hrw> lool: 594534, 590696 were needed
[12:01] <hrw> I have a build with also 593281 applied to get libgcc1-dbg
[12:02] <hrw> libgcc1-dbg-armel-cross_4.5.0-5ubuntu1.lool1_all.deb
[12:05] <JameswStubbs> Bump (Sorry for bumping)
[12:06] <cwillu_at_work> JameswStubbs, um, then don't bump?
[12:06] <cwillu_at_work> this isn't ubuntuforums
[12:06] <lool> lool1 that's me!
[12:06] <lool> hrw: ~hrw1 please  :-)
[12:07] <lool> JameswStubbs: in theory you should just be able to apt-get install that
[12:07] <lool> JameswStubbs: does it pull more than it should?
[12:07] <lool> JameswStubbs: what specifically is pulled which shouldnt be?
[12:07] <JameswStubbs> apt-get install what?
[12:07] <lool> JameswStubbs: matchbox
[12:07] <JameswStubbs> matchbox pulls everything it needs
[12:07] <JameswStubbs> But it depends on GTK which is gnome's toolkit I think
[12:07] <lool> JameswStubbs: You need Gtk+ for what, a custom application?
[12:08] <JameswStubbs> Matchbox-session needs gtk
[12:08] <zumbi> lool: then maybe sparc? -- I just wonder if biarch cross compilers are fixed. I saw you having some mails with doko about it, but he was wanting to fix it in the right way, while you wanted a quick hack for linaro
[12:08] <cwillu_at_work> not seeing the problem
[12:08] <lool> JameswStubbs: Gtk+ is the toolkit used in GNOME, but it's not the full GNOME environment
[12:08] <cwillu_at_work> gtk isn't all of gnome
[12:08] <lool> zumbi: This is incorrect
[12:08] <JameswStubbs> So what do I need to enter into apt-get to get gtk?
[12:08] <JameswStubbs> apt-get install gtk??
[12:09] <lool> zumbi: Linaro is investing time in fixing it the right way, hrw is working on that, but it will take a while so I've asked him to produce intermediate builds the "old" way (regular Emdebian way) in the mean time
[12:09] <lool> zumbi: there is no additional hack than the existing Emdebian binary-cross stuff
[12:09] <lool> JameswStubbs: the matchbox-session package should depend on the libgtk package
[12:10] <lool> JameswStubbs: So this should just all work
[12:10] <lool> JameswStubbs: I fail to understand your actual problem   :-(
[12:10] <hrw> lool: patch was yours
[12:10] <hrw> lool: and I do not provide them outside of my hdd
[12:10] <lool> hrw: You mean the build fixes?
[12:10] <zumbi> lool: sure, but Emdebian way only works for armel (also sh4) but the rest of arches were broken
[12:10] <JameswStubbs> I'd copy and paste it all but it's within 2 vm's :) , When I enter matchbox-session from the prompt, it says something like gtk: couldnt open
[12:10] <lool> hrw: These are not additional hacks though, they just fix bugs in the current approach, do you agree?
[12:11] <zumbi> lool: i agree
[12:11] <hrw> lool: they are fixes, yes
[12:11] <lool> zumbi: We didn't look into that, we don't have people blocking on cross-compilers for the arches you mention
[12:11] <lool> zumbi: I would hope that everything will work once hrw is done, but we don't need to produce daily cross-compilers for sparc or powerpc in Linaro right now
[12:12] <lool> zumbi: We do need to hand out some armel cross-compilers while hrw continue on the quest to clean cross-compilers builds
[12:12] <lool> JameswStubbs: Ok, you need to be more specific though
[12:12] <JameswStubbs> Ok I'll try
[12:13] <zumbi> lool: while I understand you focus on armel (which is primary) I'll try to work on the rest of arches (at least test builds)
[12:13] <lool> JameswStubbs: (IIUC, you installed only Ubuntu packages in your rootfs, but you see some error messages with gtk, can only comment if we know what the error is)
[12:13] <lool> zumbi: As I said, I expect the *final* solution to work on other arches
[12:13] <zumbi> `buildcross` could easily be used to test all cross compiler arches
[12:13] <lool> zumbi: But I asked hrw to provide hand-built packages *right now* because we need them, we don't need them for other arches than armel
[12:13] <zumbi> lool: i got it. thanks :)
[12:14] <lool> Ok  :-)
[12:14] <JameswStubbs> I've made a rootfs using rootstock. I've then opened it in qemu. I then installed xorg. I then installed matchbox. Now when I enter matchbox-session is returns: (matchbox-desktop:434) : Gtk-Warning **: cannot open display:
[12:15] <lool> JameswStubbs: Do you run matchbox-session from within Xorg?
[12:15] <JameswStubbs> Should I enter startx
[12:15] <JameswStubbs> Then when I get the x shell then enter matchbox-session?
[12:15] <lool> JameswStubbs: matchbox-session should be started from within a Xorg context, otherwise it doens't know which Xorg DISPLAY to connect to or which credential (XAUTHORITY) to use
[12:16] <lool> JameswStubbs: I'm not sure what the proper way is to start matchbox-session on boot or to start Xorg + matchbox-session, perhaps startx will do the trick, perhaps you need to setup more things
[12:16] <lool> JameswStubbs: One way to quickly test matchbox-session is to start Xorg with a xterm and then run matchbox-session from there, but that's certainly not what you would want in the end I guess
[12:16] <JameswStubbs> I think I need to add match-box session to xinitrc
[12:17] <lool> Yes, it is indeed possible you have to do that
[12:28] <JameswStubbs> Hm, All I'm getting after adding matchbox-session to xinitrc is a blackscreen and a mouse, which I can't move.
[12:31] <JameswStubbs> Any ideas lool?
[12:57] <lool> JameswStubbs: Check the xinit man page, and/or read through /etc/X11/Xsession.d/* scripts and /etc/X11/Xsession
[12:57] <lool> JameswStubbs: I don't have a recipe for you, as I didn't do this myself, but it should be easy to look into what the shell scripts are doing
[12:57] <lool> JameswStubbs: I think one important thing is to have .xinitrc +x or something like that
[12:57] <lool> and you need a shebang too if you do this obvisouly
[12:58] <JameswStubbs> shebang? !#?
[12:58] <lool> #!/bin/sh
[13:00] <lool> JameswStubbs: I checked and if you look at startx, it will pass xinitrd to xinit which expects to be passed a client program
[13:00] <lool> So if you pass it a text file, it wont work
[13:47] <asac> ogra_cmpc: where is rcn? isnt he usually hanging out here?
[13:48] <lool> asac: 16:10 < cwillu_at_work> okay, that's a week since rcn was last on, anybody want  to come with me on a rescue mission? :p
[13:49] <lool> asac: 17:09  * cwillu_at_work found rcn
[13:49] <cwillu_at_work> asac, he should be back today
[13:49] <cwillu_at_work> took an unannounced vacation
[13:50] <asac> ah ... one of the weak ones ;)
[13:51] <armin76> he's running from you :D
[13:51] <armin76> *away
[13:51] <cwillu_at_work> I was wondering about that actually :p
[13:53] <cwillu_at_work> omg
[13:53] <cwillu_at_work> that's embarrasing
[13:53] <cwillu_at_work> I've got a webapp I run in an undecorated fullscreen firefox window
[13:53] <cwillu_at_work> been having horrible performance
[13:54] <cwillu_at_work> firefox using 60-80% cpu, with the backend server using the other 20%
[13:54] <cwillu_at_work> (backend has to poll a bunch of serial devices and push data to firefox)
[13:54] <cwillu_at_work> figured it was just the overhead of updating things / the push system
[13:54] <cwillu_at_work> finally got around to getting venkman on it
[13:56] <cwillu_at_work> a completely unrelated piece of code was in a hard mutually recursive loop:  initializing a drop-down menu was triggering a request to get data, and the request handler was triggering an init of the drop-down
[13:57] <cwillu_at_work> the embarrassing part is that I've been working under the false assumption for long enough to have actually shipped this to customers :p
[15:22] <hrw> http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ contains now amd64 and i386 cross toolchains for armel target
[16:22] <rsavoye> hrw: is there a branch for the source used to build your cross toolchain ?
[16:22] <hrw> rsavoye: I used ubuntu sources
[16:22] <hrw> will add README
[16:22] <rsavoye> so no Code Sourcery patch yet ?
[16:22] <hrw> not yet
[16:23] <rsavoye> you hacked libstdc++ and libiberty to cross configure ?
[16:23] <rsavoye> hrw: there is a nice patch in GCC trunk for Android you might want to add when you get to patching 4.4
[16:23] <rsavoye> all it does is cleanup linking mostly
[16:24] <hrw> rsavoye: url?
[16:24] <rsavoye> the thread is at http://www.pubbs.net/201005/gcc/37284-patch-06-add-support-for-android.html
[16:25] <rsavoye> it's based on my older Android patch, and adds bionic support in a nice generic way
[16:25] <lool> hey rsavoye
[16:25] <rsavoye> howdy
[16:26] <lool> rsavoye: Might make sense for you folks to discuss this on #linaro, but here is fine too
[16:26] <rsavoye> ah, didn't think of that, thanks
[16:26] <rsavoye> I was just hacking on ARM toolchains this weekend for Gnash, so pipped up when I saw the link to debs
[21:16] <fabrice_sp> Hi. Just as a follow up of last time I connected (About atlas build on arm): I'll upload atlas as someone has been able to build it in qemu
[21:16] <fabrice_sp> in case it loops, who should I poke to kill it?
[22:06] <tumbleweed> ogra: I'm still getting a fair number of qemu segfaults with lucid