**** BEGIN LOGGING AT Wed Nov 21 02:59:58 2012
Nov 21 12:02:17 <GNUtoo-desktop> hi JaMa 
Nov 21 12:25:10 <JaMa> hi
Nov 21 12:28:04 <GNUtoo-desktop> JaMa, I think we must discuss the long term future with reguard to systemd<->kernel versions
Nov 21 12:28:34 <GNUtoo-desktop> for instance I've a device(bug20) with 2.6.35 and I was unable to make it boot because of systemd
Nov 21 12:28:43 <GNUtoo-desktop> nokia900 is 2.6.37
Nov 21 12:29:06 <GNUtoo-desktop> gta02 is 2.6.39
Nov 21 12:29:31 <lindi-> 2.6.39 does not suspend/resume reliably for me, I use 2.6.34
Nov 21 12:29:44 <lindi-> GNUtoo-desktop: or do you have a fix?
Nov 21 12:30:08 <GNUtoo-desktop> lindi-, I tried recently and I was unable to reproduce 
Nov 21 12:30:13 <GNUtoo-desktop> I tried like 20min or more
Nov 21 12:30:28 <GNUtoo-desktop> with your suspend script that uses the rtc for wakeup
Nov 21 12:32:16 <lindi-> GNUtoo-desktop: could you test with http://lindi.iki.fi/lindi/openmoko/linux-2.6-gta02/linux-image-2.6.39-gta02-gta02_2.6.39-1gta021_armel.deb ?
Nov 21 12:34:20 <GNUtoo-desktop> ok I'll do a bit later
Nov 21 12:34:36 <lindi-> since I can't understand how the bug could just disappear
Nov 21 12:41:58 <GNUtoo-desktop> ok
Nov 21 12:42:11 <GNUtoo-desktop> when I tested I had a battery gauge that didn't work
Nov 21 12:42:19 <GNUtoo-desktop> probably userspace related
Nov 21 12:42:51 <lindi-> GNUtoo-desktop: when you tested what?
Nov 21 12:44:28 <JaMa> GNUtoo-desktop: I think this was discussed on FSOSHRCON, supported devices have new enough kernels, the rest was moved to unsupported
Nov 21 12:48:30 <GNUtoo-desktop> devices were moved to unsuported for another reason:
Nov 21 12:48:37 <GNUtoo-desktop> lack of interest => unsuported
Nov 21 12:48:52 <GNUtoo-desktop> for instance htc dream didn't have one change in so long => unsuported
Nov 21 12:49:47 <GNUtoo-desktop> I think that n900 could eventually be dropped
Nov 21 12:49:50 <GNUtoo-desktop> but not gta02
Nov 21 12:50:17 <lindi-> largest problem with gta02 is RAM
Nov 21 12:50:30 <GNUtoo-desktop> I though it was glamo
Nov 21 12:50:32 <lindi-> web browsing is already quite bad
Nov 21 12:50:46 <GNUtoo-desktop> ok
Nov 21 12:50:47 <lindi-> 128 MB just isn't enough in 2012
Nov 21 12:51:13 <GNUtoo-desktop> so you mean we should drop the almost-working gta02?
Nov 21 12:51:33 <GNUtoo-desktop> like when we have a too old kernel
Nov 21 12:51:39 <JaMa> GNUtoo-desktop: I was talking about pre and bug
Nov 21 12:51:50 <lindi-> GNUtoo-desktop: I can't give advice to you, it all depends on what you value
Nov 21 12:52:00 <lindi-> GNUtoo-desktop: I still use gta02
Nov 21 12:52:20 <lindi-> GNUtoo-desktop: but probably in a year or two I'm going to jump to some android system
Nov 21 12:52:34 <lindi-> GNUtoo-desktop: just don't have the time to investigate options right no
Nov 21 12:52:36 <lindi-> +w
Nov 21 12:52:44 <GNUtoo-desktop> JaMa, ah? but now it comes to pre and bug20 and later it will come to n900 and gta02
Nov 21 12:53:32 <JaMa> then later we maybe will have to upgrade kernel for them or stay with older systemd
Nov 21 12:54:17 <JaMa> are you suggesting returning to sysvinit just because there is possibility that some newer version of systemd will need newer kernel?
Nov 21 12:54:25 <GNUtoo-desktop> no
Nov 21 12:54:34 <GNUtoo-desktop> I'm suggesting to find a way to upgrade kernels
Nov 21 12:54:45 <GNUtoo-desktop> like to put me to work on gta02 kernel 
Nov 21 12:54:53 <GNUtoo-desktop> instead of me working on other stuff
Nov 21 12:55:33 <JaMa> then work on gta02 kernel if you like
Nov 21 12:56:06 <GNUtoo-desktop> the main problem is that s3c24xx is not dt yet
Nov 21 12:56:12 <GNUtoo-desktop> and not even multiarch
Nov 21 12:56:15 <JaMa> I'm using 3.2 for long time, because it works for my use-case and I'm not putting anyone to anything
Nov 21 12:56:47 <GNUtoo-desktop> ok
Nov 21 13:00:10 <GNUtoo-desktop> the problem is that if I work on gta02 kernel, you and slyon will have to take care of the rest
Nov 21 13:00:15 <GNUtoo-desktop> including gta04
Nov 21 13:00:35 <GNUtoo-desktop> else I could try to fix 3.2 to gain some time
Nov 21 13:01:13 <JaMa> hmm
Nov 21 13:04:24 <JaMa> right now I'm trying to fix that SIGILL in systemd on armv4t and I don't see why you have to work on newer kernel *now* when old one works fine with current systemd (and has other more important issues then remote possibility of needed upgrade in future)
Nov 21 13:05:06 <GNUtoo-desktop> I've to work on it before it's too late tough
Nov 21 13:05:19 <JaMa> ?
Nov 21 13:05:21 <GNUtoo-desktop> like before when it's not working anymore
Nov 21 13:05:33 <GNUtoo-desktop> because doing a kernel can take a long time
Nov 21 13:05:59 <GNUtoo-desktop> and so if I start when it's already not working......that will prevent the sync of the feeds during too long
Nov 21 13:06:03 <GNUtoo-desktop> like months
Nov 21 13:06:10 <JaMa> do you have some systemd roadmap saying that they will depend on newer kernel soon?
Nov 21 13:06:18 <GNUtoo-desktop> no
Nov 21 13:06:32 <JaMa> danny branches are locked already
Nov 21 13:06:38 <JaMa> feeds are locked to danny branches
Nov 21 13:06:38 <GNUtoo-desktop> ok
Nov 21 13:06:42 <JaMa> I don't see your point
Nov 21 13:06:42 <GNUtoo-desktop> ok
Nov 21 13:06:43 <GNUtoo-desktop> good
Nov 21 13:06:52 * pabs3 wonders if focusing on forward-porting and upstreaming everything would be the best option
Nov 21 13:07:17 <JaMa> feeds are stuck for too long because of that SIGILL issues we already have not because of some teoretical issue
Nov 21 13:07:20 <GNUtoo-desktop> I was thinking with master branches
Nov 21 13:07:27 <GNUtoo-desktop> ok
Nov 21 13:07:42 <GNUtoo-desktop> then maybe I should help you with that sigkill instead
Nov 21 13:08:23 <JaMa> or you can finish that hwrouting with slyon as you already started working on it afaik
Nov 21 13:08:33 <GNUtoo-desktop> yes
Nov 21 13:08:45 <GNUtoo-desktop> that's also very important
Nov 21 13:08:54 <JaMa> that's also issue we already have, not just possible issue in future
Nov 21 13:10:44 <GNUtoo-desktop> then:
Nov 21 13:10:49 <GNUtoo-desktop> 1) finish hw routing
Nov 21 13:10:59 <GNUtoo-desktop> 2) help you with the SIGKILL
Nov 21 13:11:21 <GNUtoo-desktop> s/then:/then my todo is:/
Nov 21 13:12:10 <lindi-> pabs3: my plan was to make 2.6.39 usable first and then start upstreaming the patches but I got stuck at the first step
Nov 21 13:12:15 <JaMa> s/SIGKILL/SIGILL/
Nov 21 13:12:23 <GNUtoo-desktop> ah?
Nov 21 13:13:13 <JaMa> it's illegal instruction
Nov 21 13:13:20 <GNUtoo-desktop> ah ok
Nov 21 13:13:36 <GNUtoo-desktop> let's use gdb doctor then
Nov 21 13:13:53 <GNUtoo-desktop> (gnu doctor debugger)
Nov 21 13:13:57 <JaMa> have you seen http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-November/042298.html ?
Nov 21 13:14:16 <GNUtoo-desktop> in the past yes
Nov 21 13:14:18 <GNUtoo-desktop> let me look
Nov 21 13:15:10 <GNUtoo-desktop> what's vsli.32 ?
Nov 21 13:17:28 <GNUtoo-desktop> I know a bit atomic stuff
Nov 21 13:17:31 <GNUtoo-desktop> at least I did
Nov 21 13:17:34 <GNUtoo-desktop> for armv4
Nov 21 13:17:43 <GNUtoo-desktop> I had some issues with it long time ago
Nov 21 13:19:34 <GNUtoo-desktop> ok I know this code
Nov 21 13:19:45 <GNUtoo-desktop> __kernel_cmpxchg
Nov 21 13:19:55 <GNUtoo-desktop> do you know what's that or do you want me to explain?
Nov 21 13:22:20 <GNUtoo-desktop> JaMa, ^^^
Nov 21 13:23:47 <GNUtoo-desktop> https://lwn.net/Articles/314561/
Nov 21 13:27:51 <GNUtoo-desktop> vsli seem vector shift left and insert
Nov 21 13:28:32 <GNUtoo-desktop> it's probably NEON
Nov 21 13:31:01 <GNUtoo-desktop> they said "Advanced SMID"
Nov 21 13:34:28 <GNUtoo-desktop> bbl
Nov 21 14:27:59 <GNUtoo-x60> JaMa, ping me when you're back to continue debugging
Nov 21 14:33:33 <JaMa> I've already replied to bug with work around
Nov 21 14:34:05 <JaMa> checking fix for master now
Nov 21 14:35:43 <GNUtoo-x60> ok let me look
Nov 21 14:37:02 <GNUtoo-x60> where's the reply?
Nov 21 14:37:35 <jake42> http://www.shr-project.org/trac/ticket/2080#comment:3
Nov 21 14:37:38 <GNUtoo-x60> seem we have an issue with xf86-video-omapfb too as you said
Nov 21 14:37:42 <GNUtoo-x60> thanks
Nov 21 14:38:36 <GNUtoo-x60> so it might be __kernel_cmpxchg? 
Nov 21 15:54:33 <GNUtoo-x60> about the last patch, xf86-video-omap won't work
Nov 21 15:54:49 <GNUtoo-x60> so preffer rather xf86-video-fbdev
Nov 21 15:55:42 <JaMa> why? 16:54:35 < GNUtoo-x60> about the last patch, xf86-video-omap won't work
Nov 21 15:55:57 <GNUtoo-x60> because it requires pdata for it
Nov 21 15:56:01 <GNUtoo-x60> I tried already
Nov 21 15:56:12 <GNUtoo-x60> + a driver that is in staging
Nov 21 15:56:25 <GNUtoo-x60> which depend on an experimental libdrm backend
Nov 21 15:56:34 <GNUtoo-x60> so it requires quite some work
Nov 21 15:56:36 <JaMa> then fbdev should be in added to XSERVER not as PREFERRED_PROVIDER
Nov 21 15:56:44 <GNUtoo-x60> assuming the oe parts work
Nov 21 15:56:48 <GNUtoo-x60> the kernel parts are lacking
Nov 21 15:57:06 <GNUtoo-x60> yes
Nov 21 19:18:52 <GNUtoo-x60> <JaMa> checking fix for master now 
Nov 21 19:19:09 <GNUtoo-x60> hmmm the fix is in the meta-something?
Nov 21 19:19:56 <JaMa> not yet, it didn't work
Nov 21 19:21:38 <GNUtoo-x60> ah ok
Nov 21 19:21:43 <GNUtoo-x60> what was it?
Nov 21 19:22:10 <GNUtoo-x60> what id we disass the __kernel_cmpxchg memory reagion?
Nov 21 19:22:13 <GNUtoo-x60> *if
Nov 21 19:23:55 <JaMa> GNUtoo-x60: I'm reverting tc to point where it worked ok
Nov 21 19:24:01 <GNUtoo-x60> ok
Nov 21 19:24:26 <GNUtoo-x60> like gcc and friends?
Nov 21 19:24:43 <GNUtoo-x60> is libatomic included in gcc? how does it works nowadays?
Nov 21 19:53:22 <nully> How come we dont put version numbers or machinetype/phone/type/whatever on the build.shr-project.org site? I cant be the only one who finds the lack of any markings on the file names highly confusing >.>
Nov 21 20:00:08 <GNUtoo-x60> nully, hi
Nov 21 20:00:17 <GNUtoo-x60> what do you mean?
Nov 21 20:00:32 <GNUtoo-x60> you mean gta02 == freerunner == om-gta02 ==
Nov 21 20:00:34 <GNUtoo-x60> ...
Nov 21 20:00:36 <GNUtoo-x60> ?
Nov 21 20:10:59 <JaMa> GNUtoo-x60: yes tc as toolchain
Nov 21 20:12:00 <JaMa> nully: files are in directory named as machine and most of them also have machine name in their filename, can you show some example where it's not clear?
Nov 21 20:24:31 <GNUtoo-desktop> ERROR:gitosis.serve.main:Repository read access denied
Nov 21 20:24:39 <GNUtoo-desktop> do I have access to that repository:
Nov 21 20:24:47 <GNUtoo-desktop> git+ssh://git@git.shr-project.org/libphone-ui.git
Nov 21 20:25:40 <GNUtoo-desktop> JaMa, ^^^
Nov 21 20:25:50 <GNUtoo-desktop> I want to push my work in a branch
Nov 21 20:27:37 <JaMa> GNUtoo-desktop: now you have
Nov 21 20:27:52 <GNUtoo-desktop> thanks
Nov 21 20:51:46 <GNUtoo-desktop> hmmm
Nov 21 20:52:11 <GNUtoo-desktop> mrmoku, hi
Nov 21 20:53:18 <GNUtoo-desktop> I wonder how to call a one time dbus thing in libphone-ui
Nov 21 20:53:37 <GNUtoo-desktop> I do it the blocking way and don't care?
Nov 21 20:53:42 <GNUtoo-desktop> I do it in init?
Nov 21 20:53:53 <GNUtoo-desktop> I do it trough callbacks?
Nov 21 20:55:35 <GNUtoo-desktop> blocking way means dbus_g_proxy_call
Nov 21 20:58:43 <GNUtoo-desktop> I'll do that
Nov 21 21:03:02 <GNUtoo-desktop> hmmm bad idea
Nov 21 21:03:04 <GNUtoo-desktop> hi dos1 
Nov 21 21:04:11 <dos1> hello
Nov 21 21:05:32 <GNUtoo-desktop> dos1, do you know libphone-ui ?
Nov 21 21:08:23 <GNUtoo-desktop> dos1, I need to do that inside it:
Nov 21 21:08:34 <GNUtoo-desktop> mdbus2 -s org.freesmartphone.odeviced /org/freesmartphone/Device/Info org.freesmar
Nov 21 21:08:34 <GNUtoo-desktop> tphone.Device.Info.GetCpuInfo
Nov 21 21:08:38 <GNUtoo-desktop> which would return:
Nov 21 21:08:45 <dos1> hmm
Nov 21 21:08:46 <GNUtoo-desktop> ({'CPU revision': <'2'>, 'Features': <'swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls'>, 'Revision': <'A3'>, 'CPU implementer': <'0x41'>, 'CPU architecture': <'7'>, 'CPU variant': <'0x3'>, 'BogoMIPS': <'191.40'>, 'CPU part': <'0xc08'>, 'Hardware': <'GTA04'>, 'Serial': <'0000000000000000'>},)
Nov 21 21:08:52 <GNUtoo-desktop> and get the A3 string
Nov 21 21:09:11 <dos1> I'd guess that mrmoku should know it
Nov 21 21:09:23 <GNUtoo-desktop> until now I found the call initiate
Nov 21 21:09:26 <GNUtoo-desktop> ok
Nov 21 21:09:30 <GNUtoo-desktop> but mrmoku is not there
Nov 21 21:09:43 <GNUtoo-desktop> I'm not going to wait months to see mrmoku
Nov 21 21:10:01 <GNUtoo-desktop> we need A3/A4 detection as soon as possible
Nov 21 21:10:11 <GNUtoo-desktop> else we loose all contributions for people with A3
Nov 21 21:10:11 <dos1> AFAIK libphone-ui uses libfso-glib
Nov 21 21:10:13 <GNUtoo-desktop> *A4
Nov 21 21:10:18 <GNUtoo-desktop> yes
Nov 21 21:10:27 <GNUtoo-desktop> but I don't understand a thing
Nov 21 21:10:33 <dos1> it should have proper interfaces exposed
Nov 21 21:10:36 <GNUtoo-desktop> else I'll just copy the call 
Nov 21 21:10:42 <dos1> the bad thing is that i don't understand it either :x
Nov 21 21:11:14 <GNUtoo-desktop> ok
Nov 21 21:30:44 <nully> JaMa: OKay, sorry i guess the type is there, but there is no version numbers. Like: http://build.shr-project.org/shr-core/images/nokia900/shr-image-nokia900.tar.gz or http://build.shr-project.org/shr-2012.01/images/nokia900/shr-image-nokia900.tar.gz or http://build.shr-project.org/shr-core-staging/106/images/nokia900/shr-image-nokia900.tar.gz
Nov 21 21:32:24 <JaMa> nully: those are symlinks to latest
Nov 21 21:32:54 <JaMa> so use versioned name if you want name, use name without version when you want latest and don't care about version
Nov 21 21:38:09 <nully> I think i understand...
Nov 21 21:38:36 <nully> it just confuses me i guess, having to keep track of what is what on my end because of the generic names on the server.
Nov 21 21:47:23 <GNUtoo-desktop> I think the callback goes up until the efl GUI
Nov 21 21:47:37 <GNUtoo-desktop> I need to handle blocking locally.....
**** ENDING LOGGING AT Thu Nov 22 02:59:58 2012