[04:17] <TheUni> rsalveti: ping
[04:17] <rsalveti> TheUni: pong
[04:18] <rsalveti> TheUni: was looking for you :-)
[04:18] <TheUni> heh
[04:18] <rsalveti> TheUni: was checking xbmc code and etc now
[04:18] <TheUni> rsalveti: just wanted to let you know that one of our devs has a gstreamer POC up and running
[04:18] <rsalveti> TheUni: yeah, I remember topfs2 said he made it work, but was still going to release the code
[04:19] <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 :)
[04:19] <rsalveti> TheUni: is this at master already?
[04:19] <rsalveti> TheUni: yeah, xbmc is the future
[04:19] <TheUni> no, not yet
[04:19] <rsalveti> TheUni: want to work with you at least to have a working PPA
[04:19] <rsalveti> daily would be good to have
[04:20] <TheUni> yep, i've been working on that for the last week
[04:20] <TheUni> pbuilder currently chugging away on my laptop
[04:20] <rsalveti> nice, too bad I've being busy with some other stuff :-(
[04:21] <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
[04:21] <rsalveti> TheUni: cool
[04:21] <rsalveti> TheUni: were are you putting all these modifications?
[04:21] <rsalveti> any branch?
[04:21] <TheUni> i'm almost embarrassed to show you :)
[04:21] <rsalveti> well, at least pointers so I can try to help :-)
[04:21] <TheUni> heh
[04:22] <TheUni> https://github.com/xbmc/xbmc-packaging
[04:22] <rsalveti> hehe, I still need to learn to love github
[04:22] <TheUni> as i've said, it's built on years of shoving things in with not cleanup
[04:22] <TheUni> ooh, the love will come.
[04:23] <rsalveti> np, after finishing this enna testing will jump right at xbmc
[04:23] <TheUni> i'm on (i hope) the last build failure now. sec for log
[04:24] <TheUni> we bundle our own ffmpeg builds, though we support external as well. packager can't find our internal ones...
[04:24] <rsalveti> got the latest PVR driver available at the omap ppa, so I want to test xbmc with it :-)
[04:24] <rsalveti> see how it goes
[04:24] <rsalveti> and after test the gstreamer support
[04:24] <rsalveti> hm
[04:24] <rsalveti> bundle your own ffmpeg helps a lot, but it's evil
[04:24] <TheUni> https://launchpad.net/~team-xbmc/+archive/unstable/+buildjob/2280569
[04:24] <TheUni> yea, but we carry ~45 patches
[04:25] <rsalveti> not that much
[04:25] <TheUni> ffmpeg is a bumpy road in the last month, anyway ;)
[04:26] <rsalveti> :-)
[04:26] <rsalveti> hm, failed at dh_shlibdeps
[04:26] <TheUni> rsalveti: more importantly though, we run on win32/osx as well
[04:27] <TheUni> so it's nice to know that all OSs are running the same version of ffmpeg, built the same way
[04:27] <rsalveti> yeah, makes sense
[04:28] <TheUni> rsalveti: any tips for using LD_LIBRARY_PATH ? i can't seem to get it hooked up properly
[04:31] <rsalveti> TheUni: but are you setting it at build time?
[04:31] <rsalveti> let me check
[04:33] <TheUni> google says it should be in the pbuilderrc. but not very helpful when uploading to launchpad
[04:34] <TheUni> so i tried setting it in the debian/rules as a test, but no luck
[04:36] <rsalveti> dh_shlibdeps also has the -l option
[04:40] <TheUni> right, but i couldn't figure out how to override it
[04:41] <ruckuus> Hello all, I am the guy from two weeks ago asking about ubuntu ARM on s3c6410
[04:42] <ruckuus> I am trying to specify the kernel to use on rootstock command, but I can't figure it out
[04:43] <ruckuus> Do I have to create .deb package for the kernel, then --seed linux-kernel-image-s3c6410 (the name of the kernel package)?
[04:44] <ruckuus> Anyone can give me a hint?
[04:44] <ruckuus> Thanks in advance
[04:46] <rsalveti> TheUni: did you try creating an override for dh_shlibdeps?
[04:46] <rsalveti> ruckuus: it's easier if you have the deb package
[04:47] <rsalveti> you can also use --kernel-image http://foobar/kernel.deb
[04:47] <TheUni> rsalveti: hmm, did see that i could override that
[04:50] <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?
[04:50] <rsalveti> ruckuus: yup, if you want to generate the rootfs with the kernel deb, yes
[04:50] <rsalveti> ruckuus: you can also compile your kernel and then copy to the rootfs
[04:50] <ruckuus> rsalveti: or this packaging must be done in chroot jail with ARM based RFS?
[04:50] <rsalveti> with the correct modules
[04:51] <rsalveti> ruckuus: I usually use the kernel deb-pkg rule
[04:51] <rsalveti> make -j 3 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CONFIG_DEBUG_SECTION_MISMATCH=y deb-pkg
[04:51] <rsalveti> for example, will cross compile and then create a deb for it
[04:51] <rsalveti> not perfect, but works
[04:51] <ruckuus> rsalveti: thank you, I will try that
[04:54] <ruckuus> rsalveti: by using specified kernel, do I have to take care also the libc version?
[04:54] <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)
[04:55] <rsalveti> pcacjr: yup, that's why it's useful while cross compiling it
[04:55] <rsalveti> ruckuus: you shouldn't
[04:56] <pcacjr_> rsalveti: hm, ok
[04:56] <ruckuus> rsalveti: OK, thank you
[04:58] <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
[04:59] <rsalveti> pcacjr_: hm, how are you building it?
[05:00] <pcacjr_> rsalveti: make -j 3 ARCH=x86_64 deb-pkg
[05:01] <pcacjr_> rsalveti: however the binaries which it has are all 64-bit ones
[05:02] <rsalveti> pcacjr_: interesting, could be a bug at the packaging part
[05:02] <pcacjr_> so I had to use --force-architecture to install it on an x86_64
[05:02] <rsalveti> just putting i386 for everything
[05:02] <pcacjr_> rsalveti: perhaps
[05:03] <pcacjr_> rsalveti: yep
[05:03] <rsalveti> actually it's being quite a while that I don't build my own kernel for x86 :-)
[05:04] <pcacjr_> rsalveti: hehe :-)
[05:04] <rsalveti> just ARM atm, unfortunately my main host is still x86
[05:04] <pcacjr_> ahahah
[05:04] <pcacjr_> let's just wait the quad core ARMs
[05:05] <rsalveti> TheUni: if you're building locally you can try the debian rules calls by hand, without the need to rebuild everything
[05:05] <rsalveti> like fakeroot debian/rules binary
[05:05] <pcacjr_> rsalveti: I'll try to reproduce the bug again later on
[05:05] <rsalveti> pcacjr_: :-)
[05:06] <pcacjr_> rsalveti: time to get some sleep. g'night
[05:06] <rsalveti> pcacjr: c-ya
[05:06] <TheUni> rsalveti: thanks for the tip. obviously deb packaging is new to me.
[05:06] <rsalveti> TheUni: not a problem :-)
[05:07] <rsalveti> TheUni: and where can I find the branch with initial gst support?
[05:07] <rsalveti> if already available somewhere
[05:07] <TheUni> rsalveti: i think topfs2 has them local. i'll ask him to publish next time i see him
[05:07] <TheUni> as i said, it's just a POC. but he had playback in xbmc in 2 days, so think it's very reasonable
[05:08] <rsalveti> cool, will ping him when he's around here
[05:08] <rsalveti> nice
[07:31] <rsalveti> persia: ping
[07:33] <rsalveti> persia: I'm thinking if it's worthy creating a task for our set-up-box blueprint, and how it'd be called
[07:33] <rsalveti> we currently already have many tasks related with mythtv
[07:33] <rsalveti> that's kind the official and supported set-up-box solution at ubuntu
[07:34] <rsalveti> but for arm we would still need a lighter solution, as enna is atm
[07:34] <rsalveti> and soon xbmc
[07:36] <rsalveti> so for us this task would basically install enna, and possibly lirc
[08:39] <sveinse> Are there any particular restrictions on the X-loader / MLO file when booting from SD?
[08:40] <hrw> other then mistic 'it has to be first file' or 'partition should start at X and end at 666'?
[08:41] <hrw> I would suggest to wait for ubuntu/arm guys to wake up and arrive
[08:42] <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)
[08:42] <sveinse> Sure, I can wait
[08:44] <hrw> iirc you can add some headercode to kernel instead of mlo but I do not remember details
[08:44] <sveinse> hrw, are there any new updates to gcc 4.5 armel-cross in the loop (for maverick)?
[08:44] <hrw> sveinse: omap(3,4) cpu has bootrom which loads xloader (mlo) which initialize board and goes with booting
[08:44] <hrw> sveinse: next week will bring something
[08:45] <hrw> sveinse: I am at emdebian sprint this week
[08:47] <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
[08:47] <hrw> gcc 4.4 is still supported by linaro
[08:47] <hrw> but not for long - 4.6 is on a way to release
[09:49] <lardman|home> morning
[09:50] <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)
[09:50] <lardman|home> my rootstock was built using --seed netbook-launcher-efl,onboard,ubuntu-netbook-efl-default-settings,wicd,wicd-curses,wicd-cli
[09:51] <lardman|home> I can't find a gdm binary nor an X* binary anywhere in the bin/sbin directories; do they hide elsewhere?
[09:51] <lardman|home> or is my --seed wrong and needs more options added?
[09:51] <ogra> you didnt specify them in your --seed
[09:52] <ogra> and nothing of the packages you listed depends on them
[09:52] <lardman|home> are they not pulled in as part of the other --seed meta packages?
[09:52] <lardman|home> ah ok
[09:52] <lardman|home> is there a list anywhere of a recommended --seed list?
[09:59] <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?
[10:01] <lilstevie> hey lardman|home
[10:01] <lardman|home> hi lilstevie
[10:02] <lardman|home> in the absence of anyone knowing how to get multitouch working in Meego ARM, I'm having a go with Ubuntu
[10:02] <lilstevie> is there a way to change where the battery manager grabs its battery levels from?
[10:02] <lilstevie> ah damn, meego on the tab would have been cool
[10:03] <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
[10:03] <lilstevie> ah
[10:03] <lardman|home> and really I'd like to be able to use the beast in the meantime :)
[10:03] <lilstevie> :)
[10:04] <lilstevie> I think samsung were just blowing me off by saying they handed my request to the development team
[10:04] <lilstevie> havent heard anything since
[10:04] <lardman|home> Well see what happens, you might have to give them a few days
[10:04] <lardman|home> few more that is
[10:05] <lardman|home> then start shouting about it
[10:05] <lilstevie> heh
[10:05] <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
[10:06] <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)
[10:06] <lilstevie> heh yeah
[10:06] <lilstevie> problem is audio drivers are going to need some mods
[10:06] <lardman|home> did that rootstock list you put on the wiki work for you? There's apparently no Xorg in there...?
[10:06] <lilstevie> and possibly the V4L Driver
[10:06] <lardman|home> kexec it is then
[10:07] <lilstevie> lardman|home: yeah I grabbed that out of my .bash_history
[10:07] <lardman|home> hmm strange
[10:07] <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
[10:07] <lilstevie> add gdm though
[10:08] <lardman|home> ah, I guess gdm might pull X in, which would solve the problems
[10:09] <lardman|home> tbh I don't like that efl launcher anyway, so might just go for the default xubuntu-desktop one
[10:10] <lardman|home> rootstock doesn't seem to cache packages...
[10:11] <lilstevie> no it doesnt :(
[10:14] <lardman|home> lilstevie: did you install mtev or just copy the binary in?
[10:14] <lardman|home> and do you have a copy of the patched binary handy?
[10:14] <lilstevie> I copied the binary in from cb22
[10:15] <lilstevie> wait until a bit later when he shares the new one or do you want it now?
[10:15] <lardman|home> I'm happy without the wierd and wonderful tap 3 times and hold your nose to left click stuff ;)
[10:15] <lilstevie> I don't have that stuff
[10:16] <lilstevie> I have a left mouse button only vers
[10:16] <lardman|home> so yes, just the basic one which emits a click event would be useful
[10:16] <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
[10:21] <lardman|home> ouch, another 450MB being downloaded
[15:04] <ericb2> hello
[15:05] <ericb2> are there pre-installed Ubuntu versions for OMAP3 available, and hat we can use with a screen 1024x768 only (BeagleBoard xM) ?
[15:28] <rsalveti> ericb2: https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
[15:29] <rsalveti> ericb2: you can change the boot args and put the resolution you want/need
[15:30] <ericb2> rsalveti: I already tested these images, and I didn't find how to change that. Was simply not working. But maybe it was my fault.  Ok, I'll retry :)
[15:31] <rsalveti> ericb2: https://wiki.ubuntu.com/ARM/BeagleEditBootscr
[15:31] <rsalveti> ericb2: it should work, so ping me back if it fails again for you
[15:31] <ericb2> rsalveti: ok, I'll try. Thanks a ot
[15:32] <ericb2> rsalveti: btw, I did an ARM version of OOo4Kids, and I'm searching testers
[15:33] <ericb2> rsalveti: http://ftp.educoo.org/home/OOo4Kids/Linux_ARM/OMAP3/
[15:33] <ericb2> rsalveti: I optimized a critical part using assembler, but I didn't put online the version. Will do tonight or tomorrow
[15:34] <rsalveti> ericb2: cool!
[15:35] <ericb2> rsalveti: it works on sakoman version, not sure it will work on Ubuntu
[15:35] <ericb2> rsalveti: would be great to confirm
[15:35] <rsalveti> well, it should :-)
[15:35] <ericb2> rsalveti: I used ARCH_FLAGS+=-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -D__SOFTFP__
[15:36] <ericb2> rsalveti: I'm not sure add -D__SOFTFP__ is a great idea, but was efficient
[15:38] <ericb2> rsalveti: is Ubuntu compatible with such flags ?  Was Steve Sakoman who suggested most of them
[15:39] <rsalveti> ericb2: yeah, you should be fine with it
[15:42] <ericb2> rsalveti: ok, great :)
[15:55] <ericb2> sakoman: ping ?
[15:55] <sakoman> pong
[15:55] <ericb2> sakoman: hello
[15:55] <ericb2> sakoman: after some investigations, looks like the flex issue was caused by a bad m4 path
[15:56] <ericb2> sakoman: in the recipes add #define M4 "/usr/bin/m4"   helped
[15:56] <ericb2> sakoman: and most of the issues were solved
[15:56] <ericb2> sakoman: I meant add this in the config.h  , in the recipes
[15:57] <sakoman> ah, OK
[15:57] <ericb2> sakoman: the fix has been not been found by me, but I report it
[15:57] <sakoman> is there anything that I could do to avoid the need for this?
[15:57] <ericb2> sakoman: no idea. Maybe flex was built before m4 being installed ?
[15:58] <sakoman> perhaps, I will take a look at the recipe for flex
[15:58] <ericb2> sakoman: ok, thanks :)
[15:58] <sakoman> it might not have set m4 as a dependency
[15:58] <ericb2> sakoman: could be
[15:59] <ericb2> sakoman: btw, I did the assembler part, and indeed, its faster
[15:59] <ericb2> sakoman: but I need to continue, because I'm over 10s at first launch, and that's prohibitive
[15:59] <sakoman> ericb2: looks like flex is indeed missing m4 as a dependency
[16:00] <sakoman> so it likely got built prior to m4
[16:00] <ericb2> sakoman: good. So it might explain
[16:00] <sakoman> I'll fix that and we can see if that helps next time you do a build from scratch
[16:00] <ericb2> sakoman: sure. Just tell me when I can update
[16:20] <ScottK> ogra: Correction from the meeting.  The kernel for n900 was uploaded, but rejected.  Needs a bit more work.
[16:23] <ogra> ah
[16:23] <ogra> still a chance it makes it before FF ?
[16:23] <ScottK> Usually with archive-admin rejected pacakges they can be reuploaded after FF.
[16:24] <ScottK> I don't think it'll have a hard time getting an FFe if needed.  The whole plasma-mobile effort (of which that's a part) is still tech preview.
[16:25] <ogra> yeah
[16:40] <GrueMaster> ogra: Is there a reason that the initrd.img-`uname -r` is missing from /boot on the preinstalled images prior to first boot?  The link is there, but the actual initrd is missing.
[16:40] <GrueMaster> I have checked several images since A2.
[16:41] <ogra> GrueMaster, we dont need it
[16:42] <GrueMaster> We will.  I will need it for test automation.  I need to be able to rip it apart and add scripts from my desktop prior to first boot.
[16:42] <GrueMaster> I can't do that with uInitrd.
[16:47] <ogra> GrueMaster, did we use to have it ?
[16:47] <dmart> ericb2: /quit
[16:47]  * ogra dorsnt think so
[16:48] <GrueMaster> Not sure.  But the link is there, so it is being generated during image build.  And uInitrd has to come from somewhere.
[16:48] <ogra> it is never generated *inside*  the rootfs, but separately
[16:48] <ogra> thats why i sak
[16:48] <ogra> *ask
[16:49] <ogra> if it was there before A2 and isnt anymore it must be a change we introduced
[16:49] <GrueMaster> Then what creates the link in the image?
[16:49] <ogra> livecd-rootfs
[16:49] <sveinse> Have anyone tried to let X-Loader load the kernel directly and not via U-Boot? I don't see why I want to use U-Boot on a SD-card, since its removable.
[16:51] <GrueMaster> ogra: Doesn't make sense to create a link to a non-existent file.
[16:52] <rsalveti> sveinse: I know people that created the http://gitorious.org/0xlab-bootloader/qi-bootloader to load the uImage directly
[16:52] <rsalveti> but I believe currently it only supports omap 3
[16:52] <ogra> GrueMaster, no, it rolls the initrd and during that process the link gets created
[16:52] <GrueMaster> sveinse: I believe I heard someone doing this on beagle.  Not sure.
[16:52] <rsalveti> at least for omap 3 it's very fast, and avoids loading u-boot
[16:53] <GrueMaster> ogra: ok.  But why keep the link and not the file?
[16:53] <sveinse> fast is music :D
[16:53] <XorA> if you on an omap 3630/3730 you dont need x-loader, kernel can load directly
[16:54] <XorA> just need someone to write a script to generate the correct header
[16:55] <sveinse> XorA, I'm on am3505 and omap3515, so the MLO is limited to 128k IIRC
[16:55] <XorA> sveinse: then you have to have some form of bootlader :-)
[16:56] <sveinse> XorA: yup, and the idea was to add the kernel init to X-Loader.
[16:56] <sveinse> XorA, today MLO/X-Loader loads U-boot which loads the kernel
[16:56] <ogra> GrueMaster, the file reappears after update-initramfs was run .... its a space decision stemming from x86
[16:56] <XorA> did you try renaming uImage to u-boot.bin :-)
[16:57] <XorA> that might even just work (tm) :-)
[16:57]  * ericb2 yet not understood what dmart wanted to say 
[16:57] <XorA> need to hardcode the CMD_LINE and machine number of course
[16:58] <ogra> GrueMaster, on live and preinstalled, that file is never used for booting, after ubiquity/oem-config has run the actual file to run the system is created (and differs quite a lot) on x86 isos it saves about 5M to not have it in /boot
[16:58] <ogra> GrueMaster, if we want to keep that file that will need some hackery in livecd-rootfs
[16:58] <sveinse> XorA, hmm, that I'll try. However the bootprompt is not setup by X-Loader in that case
[16:59] <XorA> sveinse: Id be interested if you do code it to put it into OE
[17:04] <GrueMaster> ogra: On x86 iso it does exist.  /casper/initrd.lz
[17:07] <ogra> GrueMaster, thats the equivalent of uInitrd ;)
[17:08] <ogra> GrueMaster, what you talk about would be /boot inside the squashfs
[17:13] <GrueMaster> At least with x86, I can lzma -dc <initrd.lz >initrd.img and muck with it from there.  I have yet to successfully rip the uboot header from uInitrd.
[17:13] <GrueMaster> Even using dd to strip the 64 byte header.
[17:14] <GrueMaster> Or is it lz compressed as well?
[17:15] <GrueMaster> Nope.  Decoder error.
[17:16] <GrueMaster> Nevermind.  Figured it out.  It is gzip, but the file meta gets clobbered sometimes.  Very odd.
[17:26] <prpplague> fyi, tomorrow is the last day to provide feedback for rev2 of the Trainer Board for use with the Beagle and Panda boards : http://www.elinux.org/BeagleBoard_Trainer
[17:28] <sveinse> Poll: Which device do you use for JTAG debugging?
[17:28] <prpplague> sveinse: hehe, i'm biased but i use the flyswatter
[17:28] <prpplague> sveinse: and soon the flyswatter2
[17:28] <sveinse> how soon?
[17:29] <prpplague> sveinse: testing prototypes now, so i'd say probably 90 days
[17:30] <prpplague> sveinse: flyswatter is fully tested with openocd and openocd has support for a wide range of processors and debugging methods
[17:30] <sveinse> openocd, right? Do you know if openocd has scripts for omap3515 and am3505 ?
[17:31] <prpplague> sveinse: not specific to those but omap3 and cortex-a8
[17:31]  * sveinse *googling*
[17:31] <prpplague> sveinse: shouldn't be hard to add
[17:31] <sveinse> Hmm. I've tried that once. Had to abandon it because I was missing docs for the properitary JTAG muxer inside the SoC
[17:31] <prpplague> sveinse: this page is probably a little out of date but has the basic info - http://www.elinux.org/BeagleBoardOpenOCD
[17:32] <prpplague> sveinse: yea that has been resolved
[17:32] <prpplague> sveinse: TI has provided enough info for openocd to handle it
[17:34] <sveinse> Where can I sign up for flyswatter2 preorder? ;)
[17:35] <prpplague> sveinse: send an email to rusty@tincantools.com
[17:38] <prpplague> sveinse: i know these guys are doing a bunch of openocd work http://www.ok-labs.com/leadership/bio/daniel-potts-phd
[18:16]  * ogra feels it getting cold ...
[18:16] <ogra> freeze is in effect
[18:24] <GrueMaster> and I just thought it was my wife. :P
[18:42] <lardman> lilstevie: ping
[18:43] <lilstevie> pong
[18:43] <lardman> so, after about 13s I get a dmesg message that the power has been set on on the LCD
[18:43] <lardman> but it then goes off immediately
[18:43] <lilstevie> interesting
[18:44] <lardman> so looks like it's up and running ok, just need to do some tweaking of where the sysfs echo is happening
[18:44] <lardman> Does your image use gdm?
[18:44] <lardman> and do you have to login, or does it happen automatically?]#
[18:44] <lilstevie> I use GDM
[18:44] <lilstevie> and i have autologin set
[18:44] <lardman> was that set by default?
[18:44] <lilstevie> no
[18:45] <lardman> just wondering if the X server is restarted when the login happens, and I don't get to call the sysfs stuff again
[19:52] <armin76> Guest91304: i like your new nick :D
[20:25] <ScottK> janimo: python-qt4 built, so I can retry kdebindings here in ~20 minutes.
[20:37] <ScottK> janimo: OK.  Let's see how it goes.
[20:38] <ScottK> lardman: By default when you logout, GDM does restart it, but KDM doesn't.  Don't think either one does on login.
[20:38] <lardman> thanks ScottK
[20:39] <lardman> am just trying to work out where to switch the LCD back on after X starts (which for some reason turns it off)