**** BEGIN LOGGING AT Thu Feb 24 02:59:57 2011
Feb 24 04:18:41 <TheUni> rsalveti: ping
Feb 24 04:18:49 <rsalveti> TheUni: pong
Feb 24 04:19:00 <rsalveti> TheUni: was looking for you :-)
Feb 24 04:19:03 <TheUni> heh
Feb 24 04:19:13 <rsalveti> TheUni: was checking xbmc code and etc now
Feb 24 04:19:18 <TheUni> rsalveti: just wanted to let you know that one of our devs has a gstreamer POC up and running
Feb 24 04:19:47 <rsalveti> TheUni: yeah, I remember topfs2 said he made it work, but was still going to release the code
Feb 24 04:19:58 <TheUni> also that we've spoken to the enna devs some. they would rather work on openbricks and let us work on the mediacenter part :)
Feb 24 04:20:07 <rsalveti> TheUni: is this at master already?
Feb 24 04:20:20 <rsalveti> TheUni: yeah, xbmc is the future
Feb 24 04:20:25 <TheUni> no, not yet
Feb 24 04:20:39 <rsalveti> TheUni: want to work with you at least to have a working PPA
Feb 24 04:20:49 <rsalveti> daily would be good to have
Feb 24 04:20:58 <TheUni> yep, i've been working on that for the last week
Feb 24 04:21:12 <TheUni> pbuilder currently chugging away on my laptop
Feb 24 04:21:30 <rsalveti> nice, too bad I've being busy with some other stuff :-(
Feb 24 04:21:57 <TheUni> it's no problem. it needs lots of help. i'm adding one hack after another to get it building. once nightlies are working, we can work on cleaning it up
Feb 24 04:22:07 <rsalveti> TheUni: cool
Feb 24 04:22:18 <rsalveti> TheUni: were are you putting all these modifications?
Feb 24 04:22:24 <rsalveti> any branch?
Feb 24 04:22:33 <TheUni> i'm almost embarrassed to show you :)
Feb 24 04:22:44 <rsalveti> well, at least pointers so I can try to help :-)
Feb 24 04:22:47 <TheUni> heh
Feb 24 04:22:53 <TheUni> https://github.com/xbmc/xbmc-packaging
Feb 24 04:23:11 <rsalveti> hehe, I still need to learn to love github
Feb 24 04:23:14 <TheUni> as i've said, it's built on years of shoving things in with not cleanup
Feb 24 04:23:20 <TheUni> ooh, the love will come.
Feb 24 04:24:10 <rsalveti> np, after finishing this enna testing will jump right at xbmc
Feb 24 04:24:19 <TheUni> i'm on (i hope) the last build failure now. sec for log
Feb 24 04:24:58 <TheUni> we bundle our own ffmpeg builds, though we support external as well. packager can't find our internal ones...
Feb 24 04:25:06 <rsalveti> got the latest PVR driver available at the omap ppa, so I want to test xbmc with it :-)
Feb 24 04:25:08 <rsalveti> see how it goes
Feb 24 04:25:16 <rsalveti> and after test the gstreamer support
Feb 24 04:25:26 <rsalveti> hm
Feb 24 04:25:40 <rsalveti> bundle your own ffmpeg helps a lot, but it's evil
Feb 24 04:25:40 <TheUni> https://launchpad.net/~team-xbmc/+archive/unstable/+buildjob/2280569
Feb 24 04:25:50 <TheUni> yea, but we carry ~45 patches
Feb 24 04:25:58 <rsalveti> not that much
Feb 24 04:26:04 <TheUni> ffmpeg is a bumpy road in the last month, anyway ;)
Feb 24 04:27:29 <rsalveti> :-)
Feb 24 04:27:33 <rsalveti> hm, failed at dh_shlibdeps
Feb 24 04:27:37 <TheUni> rsalveti: more importantly though, we run on win32/osx as well
Feb 24 04:27:54 <TheUni> so it's nice to know that all OSs are running the same version of ffmpeg, built the same way
Feb 24 04:28:04 <rsalveti> yeah, makes sense
Feb 24 04:29:29 <TheUni> rsalveti: any tips for using LD_LIBRARY_PATH ? i can't seem to get it hooked up properly
Feb 24 04:32:41 <rsalveti> TheUni: but are you setting it at build time?
Feb 24 04:32:48 <rsalveti> let me check
Feb 24 04:34:27 <TheUni> google says it should be in the pbuilderrc. but not very helpful when uploading to launchpad
Feb 24 04:34:58 <TheUni> so i tried setting it in the debian/rules as a test, but no luck
Feb 24 04:37:06 <rsalveti> dh_shlibdeps also has the -l option
Feb 24 04:41:22 <TheUni> right, but i couldn't figure out how to override it
Feb 24 04:42:22 <ruckuus> Hello all, I am the guy from two weeks ago asking about ubuntu ARM on s3c6410
Feb 24 04:43:31 <ruckuus> I am trying to specify the kernel to use on rootstock command, but I can't figure it out
Feb 24 04:44:19 <ruckuus> Do I have to create .deb package for the kernel, then --seed linux-kernel-image-s3c6410 (the name of the kernel package)?
Feb 24 04:45:07 <ruckuus> Anyone can give me a hint?
Feb 24 04:45:13 <ruckuus> Thanks in advance
Feb 24 04:47:31 <rsalveti> TheUni: did you try creating an override for dh_shlibdeps?
Feb 24 04:47:45 <rsalveti> ruckuus: it's easier if you have the deb package
Feb 24 04:48:19 <rsalveti> you can also use --kernel-image http://foobar/kernel.deb
Feb 24 04:48:43 <TheUni> rsalveti: hmm, did see that i could override that
Feb 24 04:51:05 <ruckuus> rsalveti: thank you. So, what I have to do now is to cross compile the kernel, then dpkg-buildpackage with the result .deb then use this package?
Feb 24 04:51:33 <rsalveti> ruckuus: yup, if you want to generate the rootfs with the kernel deb, yes
Feb 24 04:51:45 <rsalveti> ruckuus: you can also compile your kernel and then copy to the rootfs
Feb 24 04:51:46 <ruckuus> rsalveti: or this packaging must be done in chroot jail with ARM based RFS?
Feb 24 04:51:49 <rsalveti> with the correct modules
Feb 24 04:52:14 <rsalveti> ruckuus: I usually use the kernel deb-pkg rule
Feb 24 04:52:16 <rsalveti> make -j 3 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CONFIG_DEBUG_SECTION_MISMATCH=y deb-pkg
Feb 24 04:52:26 <rsalveti> for example, will cross compile and then create a deb for it
Feb 24 04:52:34 <rsalveti> not perfect, but works
Feb 24 04:52:46 <ruckuus> rsalveti: thank you, I will try that
Feb 24 04:55:08 <ruckuus> rsalveti: by using specified kernel, do I have to take care also the libc version?
Feb 24 04:55:25 <pcacjr_> rsalveti: one question: once built the kernel with the deb-pkg stuff, that deb package will contain the *arch* specified by the ARCH= ? (e.g package_armv7el.deb)
Feb 24 04:56:10 <rsalveti> pcacjr: yup, that's why it's useful while cross compiling it
Feb 24 04:56:42 <rsalveti> ruckuus: you shouldn't
Feb 24 04:57:20 <pcacjr_> rsalveti: hm, ok
Feb 24 04:57:51 <ruckuus> rsalveti: OK, thank you
Feb 24 04:59:51 <pcacjr_> rsalveti: I've had problems while compiling the kernel for x86_64 arch on an x86 one. the deb genereted by the make deb-pkg is always i386 instead of x86_64
Feb 24 05:00:35 <rsalveti> pcacjr_: hm, how are you building it?
Feb 24 05:01:30 <pcacjr_> rsalveti: make -j 3 ARCH=x86_64 deb-pkg
Feb 24 05:02:45 <pcacjr_> rsalveti: however the binaries which it has are all 64-bit ones
Feb 24 05:03:35 <rsalveti> pcacjr_: interesting, could be a bug at the packaging part
Feb 24 05:03:38 <pcacjr_> so I had to use --force-architecture to install it on an x86_64
Feb 24 05:03:43 <rsalveti> just putting i386 for everything
Feb 24 05:03:47 <pcacjr_> rsalveti: perhaps
Feb 24 05:03:52 <pcacjr_> rsalveti: yep
Feb 24 05:04:39 <rsalveti> actually it's being quite a while that I don't build my own kernel for x86 :-)
Feb 24 05:04:52 <pcacjr_> rsalveti: hehe :-)
Feb 24 05:04:55 <rsalveti> just ARM atm, unfortunately my main host is still x86
Feb 24 05:05:08 <pcacjr_> ahahah
Feb 24 05:05:20 <pcacjr_> let's just wait the quad core ARMs
Feb 24 05:05:53 <rsalveti> TheUni: if you're building locally you can try the debian rules calls by hand, without the need to rebuild everything
Feb 24 05:06:04 <rsalveti> like fakeroot debian/rules binary
Feb 24 05:06:06 <pcacjr_> rsalveti: I'll try to reproduce the bug again later on
Feb 24 05:06:34 <rsalveti> pcacjr_: :-)
Feb 24 05:06:59 <pcacjr_> rsalveti: time to get some sleep. g'night
Feb 24 05:07:06 <rsalveti> pcacjr: c-ya
Feb 24 05:07:10 <TheUni> rsalveti: thanks for the tip. obviously deb packaging is new to me.
Feb 24 05:07:49 <rsalveti> TheUni: not a problem :-)
Feb 24 05:08:04 <rsalveti> TheUni: and where can I find the branch with initial gst support?
Feb 24 05:08:09 <rsalveti> if already available somewhere
Feb 24 05:08:25 <TheUni> rsalveti: i think topfs2 has them local. i'll ask him to publish next time i see him
Feb 24 05:08:49 <TheUni> as i said, it's just a POC. but he had playback in xbmc in 2 days, so think it's very reasonable
Feb 24 05:08:53 <rsalveti> cool, will ping him when he's around here
Feb 24 05:08:59 <rsalveti> nice
Feb 24 07:32:51 <rsalveti> persia: ping
Feb 24 07:34:08 <rsalveti> persia: I'm thinking if it's worthy creating a task for our set-up-box blueprint, and how it'd be called
Feb 24 07:34:21 <rsalveti> we currently already have many tasks related with mythtv
Feb 24 07:34:40 <rsalveti> that's kind the official and supported set-up-box solution at ubuntu
Feb 24 07:35:09 <rsalveti> but for arm we would still need a lighter solution, as enna is atm
Feb 24 07:35:20 <rsalveti> and soon xbmc
Feb 24 07:37:12 <rsalveti> so for us this task would basically install enna, and possibly lirc
Feb 24 08:40:36 <sveinse> Are there any particular restrictions on the X-loader / MLO file when booting from SD?
Feb 24 08:41:36 <hrw> other then mistic 'it has to be first file' or 'partition should start at X and end at 666'?
Feb 24 08:42:06 <hrw> I would suggest to wait for ubuntu/arm guys to wake up and arrive
Feb 24 08:43:29 <sveinse> My point being today the boot is MLO->U-Boot->kernel, but perhaps it would be possible to do MLO->kernel or perhaps the MLO could be the kernel itself (with some customization)
Feb 24 08:43:36 <sveinse> Sure, I can wait
Feb 24 08:44:59 <hrw> iirc you can add some headercode to kernel instead of mlo but I do not remember details
Feb 24 08:45:12 <sveinse> hrw, are there any new updates to gcc 4.5 armel-cross in the loop (for maverick)?
Feb 24 08:45:37 <hrw> sveinse: omap(3,4) cpu has bootrom which loads xloader (mlo) which initialize board and goes with booting
Feb 24 08:45:49 <hrw> sveinse: next week will bring something
Feb 24 08:46:00 <hrw> sveinse: I am at emdebian sprint this week
Feb 24 08:48:08 <sveinse> hrw, sure, thanks. I just keep fighting compiling Qt with gcc4.5. It's either bugs in Qt or bugs in gcc4.5.. The ironic thing is that downgrading to gcc4.4 makes it compile, but its not maintained by linary iirc
Feb 24 08:48:23 <hrw> gcc 4.4 is still supported by linaro
Feb 24 08:48:41 <hrw> but not for long - 4.6 is on a way to release
Feb 24 09:50:10 <lardman|home> morning
Feb 24 09:51:08 <lardman|home> I've got a question about my rootstock generated image for the Galaxy Tab, basically I'm trying to work out where/how Xorg is started (as I need to poke a sysfs entry to switch the LCD screen back on after X starts)
Feb 24 09:51:44 <lardman|home> my rootstock was built using --seed netbook-launcher-efl,onboard,ubuntu-netbook-efl-default-settings,wicd,wicd-curses,wicd-cli
Feb 24 09:52:20 <lardman|home> I can't find a gdm binary nor an X* binary anywhere in the bin/sbin directories; do they hide elsewhere?
Feb 24 09:52:31 <lardman|home> or is my --seed wrong and needs more options added?
Feb 24 09:52:42 <ogra> you didnt specify them in your --seed
Feb 24 09:52:54 <ogra> and nothing of the packages you listed depends on them
Feb 24 09:53:04 <lardman|home> are they not pulled in as part of the other --seed meta packages?
Feb 24 09:53:08 <lardman|home> ah ok
Feb 24 09:53:22 <lardman|home> is there a list anywhere of a recommended --seed list?
Feb 24 10:00:15 <lardman|home> I see here https://wiki.ubuntu.com/ARM/RootfsFromScratch that one can specify --seed xubuntu-desktop - presumably that will pull in all the X deps unlike the netbook-launcher-efl I specified?
Feb 24 10:02:06 <lilstevie> hey lardman|home
Feb 24 10:02:39 <lardman|home> hi lilstevie
Feb 24 10:03:10 <lardman|home> in the absence of anyone knowing how to get multitouch working in Meego ARM, I'm having a go with Ubuntu
Feb 24 10:03:26 <lilstevie> is there a way to change where the battery manager grabs its battery levels from?
Feb 24 10:03:36 <lilstevie> ah damn, meego on the tab would have been cool
Feb 24 10:04:16 <lardman|home> well I'll get there in the end, but I need some help working out what to enable in Qt and whether it still supports mtev, etc
Feb 24 10:04:24 <lilstevie> ah
Feb 24 10:04:39 <lardman|home> and really I'd like to be able to use the beast in the meantime :)
Feb 24 10:04:48 <lilstevie> :)
Feb 24 10:05:08 <lilstevie> I think samsung were just blowing me off by saying they handed my request to the development team
Feb 24 10:05:15 <lilstevie> havent heard anything since
Feb 24 10:05:43 <lardman|home> Well see what happens, you might have to give them a few days
Feb 24 10:05:47 <lardman|home> few more that is
Feb 24 10:06:00 <lardman|home> then start shouting about it
Feb 24 10:06:21 <lilstevie> heh
Feb 24 10:06:42 <lardman|home> ok, so I'll try a rebuild - I didn't get any kernel panics, so I guess the stock-ish Android kernel will work with Ubuntu too
Feb 24 10:07:07 <lardman|home> which would mean dual boot is back in, and for those without the internal memory card, booting from an external card (which is the setup I'm using now)
Feb 24 10:07:15 <lilstevie> heh yeah
Feb 24 10:07:28 <lilstevie> problem is audio drivers are going to need some mods
Feb 24 10:07:36 <lardman|home> did that rootstock list you put on the wiki work for you? There's apparently no Xorg in there...?
Feb 24 10:07:45 <lilstevie> and possibly the V4L Driver
Feb 24 10:07:47 <lardman|home> kexec it is then
Feb 24 10:08:06 <lilstevie> lardman|home: yeah I grabbed that out of my .bash_history
Feb 24 10:08:23 <lardman|home> hmm strange
Feb 24 10:08:39 <lardman|home> I'm going to try with this, for want of any better ideas: rootstock --fqdn GalaxyTab --login ubuntu --password ubuntu --imagesize 5G --seed xubuntu-desktop,netbook-launcher-efl,ubuntu-netbook=efl-default,onboard,wicd,wicd-curses,wicd-cli,build-essential,openssh-server
Feb 24 10:08:48 <lilstevie> add gdm though
Feb 24 10:09:11 <lardman|home> ah, I guess gdm might pull X in, which would solve the problems
Feb 24 10:10:11 <lardman|home> tbh I don't like that efl launcher anyway, so might just go for the default xubuntu-desktop one
Feb 24 10:11:28 <lardman|home> rootstock doesn't seem to cache packages...
Feb 24 10:12:37 <lilstevie> no it doesnt :(
Feb 24 10:15:27 <lardman|home> lilstevie: did you install mtev or just copy the binary in?
Feb 24 10:15:40 <lardman|home> and do you have a copy of the patched binary handy?
Feb 24 10:15:48 <lilstevie> I copied the binary in from cb22
Feb 24 10:16:02 <lilstevie> wait until a bit later when he shares the new one or do you want it now?
Feb 24 10:16:29 <lardman|home> I'm happy without the wierd and wonderful tap 3 times and hold your nose to left click stuff ;)
Feb 24 10:16:43 <lilstevie> I don't have that stuff
Feb 24 10:17:18 <lilstevie> I have a left mouse button only vers
Feb 24 10:17:29 <lardman|home> so yes, just the basic one which emits a click event would be useful
Feb 24 10:17:50 <lardman|home> just so I can add it now and get something up and running, can try the new all singing and dancing version later on
Feb 24 10:22:22 <lardman|home> ouch, another 450MB being downloaded
**** BEGIN LOGGING AT Thu Feb 24 17:26:17 2011
Feb 24 17:28:22 <sveinse> Poll: Which device do you use for JTAG debugging?
Feb 24 17:28:38 <prpplague> sveinse: hehe, i'm biased but i use the flyswatter
Feb 24 17:28:50 <prpplague> sveinse: and soon the flyswatter2
Feb 24 17:28:56 <sveinse> how soon?
Feb 24 17:29:25 <prpplague> sveinse: testing prototypes now, so i'd say probably 90 days
Feb 24 17:30:21 <prpplague> sveinse: flyswatter is fully tested with openocd and openocd has support for a wide range of processors and debugging methods
Feb 24 17:30:25 <sveinse> openocd, right? Do you know if openocd has scripts for omap3515 and am3505 ?
Feb 24 17:31:01 <prpplague> sveinse: not specific to those but omap3 and cortex-a8
Feb 24 17:31:03 * sveinse *googling*
Feb 24 17:31:08 <prpplague> sveinse: shouldn't be hard to add
Feb 24 17:31:54 <sveinse> Hmm. I've tried that once. Had to abandon it because I was missing docs for the properitary JTAG muxer inside the SoC
Feb 24 17:31:59 <prpplague> sveinse: this page is probably a little out of date but has the basic info - http://www.elinux.org/BeagleBoardOpenOCD
Feb 24 17:32:11 <prpplague> sveinse: yea that has been resolved
Feb 24 17:32:24 <prpplague> sveinse: TI has provided enough info for openocd to handle it
Feb 24 17:34:42 <sveinse> Where can I sign up for flyswatter2 preorder? ;)
Feb 24 17:35:02 <prpplague> sveinse: send an email to rusty@tincantools.com
Feb 24 17:38:29 <prpplague> sveinse: i know these guys are doing a bunch of openocd work http://www.ok-labs.com/leadership/bio/daniel-potts-phd
Feb 24 18:16:46 * ogra feels it getting cold ...
Feb 24 18:16:50 <ogra> freeze is in effect
Feb 24 18:24:03 <GrueMaster> and I just thought it was my wife. :P
Feb 24 18:42:54 <lardman> lilstevie: ping
Feb 24 18:43:05 <lilstevie> pong
Feb 24 18:43:26 <lardman> so, after about 13s I get a dmesg message that the power has been set on on the LCD
Feb 24 18:43:36 <lardman> but it then goes off immediately
Feb 24 18:43:46 <lilstevie> interesting
Feb 24 18:44:01 <lardman> so looks like it's up and running ok, just need to do some tweaking of where the sysfs echo is happening
Feb 24 18:44:11 <lardman> Does your image use gdm?
Feb 24 18:44:21 <lardman> and do you have to login, or does it happen automatically?]#
Feb 24 18:44:28 <lilstevie> I use GDM
Feb 24 18:44:33 <lilstevie> and i have autologin set
Feb 24 18:44:44 <lardman> was that set by default?
Feb 24 18:44:49 <lilstevie> no
Feb 24 18:45:10 <lardman> just wondering if the X server is restarted when the login happens, and I don't get to call the sysfs stuff again
Feb 24 19:52:27 <armin76> Guest91304: i like your new nick :D
Feb 24 20:25:02 <ScottK> janimo: python-qt4 built, so I can retry kdebindings here in ~20 minutes.
Feb 24 20:30:52 <janimo> ScottK, sure I am following that. The packages are not yet in the archive
Feb 24 20:31:23 <ScottK> janimo: Should be there when this publiser run finishes in 10 or 15 minutes.
Feb 24 20:31:23 <lardman> does the X server restart when you login?
Feb 24 20:37:37 <ScottK> janimo: OK.  Let's see how it goes.
Feb 24 20:38:14 <ScottK> lardman: By default when you logout, GDM does restart it, but KDM doesn't.  Don't think either one does on login.
Feb 24 20:38:51 <lardman> thanks ScottK
Feb 24 20:39:18 <lardman> am just trying to work out where to switch the LCD back on after X starts (which for some reason turns it off)
Feb 25 01:42:29 <TheUni> rsalveti: you around?
Feb 25 01:42:57 <TheUni> rsalveti: i got xbmc building, but need some 'best-practice' advice
**** ENDING LOGGING AT Fri Feb 25 02:59:57 2011