**** BEGIN LOGGING AT Fri Dec 02 02:59:57 2011
Dec 02 04:31:57 <CIA-69> freesmartphone.org: 03morphis 07aurora * r2eb66cbe938c 10/aurora-daemon/ (configure.ac src/bin/Makefile.am): 
Dec 02 04:31:57 <CIA-69> freesmartphone.org: aurora-daemon: depend on x11 for compilation as we're using parts of it
Dec 02 04:31:57 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Dec 02 04:37:52 <CIA-69> freesmartphone.org: 03morphis 07aurora * rba9bc42bcc4b 10/aurora-daemon/ (configure.ac src/bin/Makefile.am): 
Dec 02 04:37:52 <CIA-69> freesmartphone.org: aurora-daemon: depend on x11 for compilation as we're using parts of it
Dec 02 04:37:52 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Dec 02 05:47:13 <mrmoku> JaMa: pulled 
Dec 02 05:47:16 <mrmoku> and building
Dec 02 05:47:17 <mrmoku> thx
Dec 02 06:36:35 <JaMa> moin
Dec 02 06:41:18 <mrmoku> moin JaMa 
Dec 02 06:41:40 <mrmoku> gah without coffee I forgot to cleansstate ffalarms :P
Dec 02 06:44:50 <JaMa> mrmoku: :)
Dec 02 06:45:47 <mrmoku> NOTE: package shr-lite-image-2.0-r20: task do_rootfs: Started
Dec 02 06:47:33 <antrik> JaMa: don't you think it's a bit silly to complain about API breaks in trunk?...
Dec 02 06:49:48 <JaMa> antrik: if you break API one way and then you reverse it.. then I think there should be better plan how to change API for start
Dec 02 06:50:48 <JaMa> antrik: in this case, why to force people to change their core to use new elm_gen_* API just to force them after 14 days go back to elm_genlist/gengrid API
Dec 02 06:53:58 <antrik> no, that's normal development process; you can hardly blame them for doing development on trunk. they don't force anyone -- it is *your* choice to use trunk builds instead of releses, and breaks are what you get for it
Dec 02 06:59:27 <antrik> (well, OK, TAsn is actually pushing for the use of trunk, so I guess he can be blamed to some extent... I hope that's not true of all EFL developers though)
Dec 02 07:00:36 <JaMa> antrik: I'm upgrading efl a lot lately because there will be new release soon (not elementary though) so I wanted to give them some testing before they release it
Dec 02 07:01:32 <mrmoku> and if nobody would do that... bad for the release
Dec 02 07:02:16 <JaMa> antrik: normal development process, when you're changing APIs (not for normal changes) then you should have some vision how the APIs are looking now and how they should look like after your changes
Dec 02 07:03:50 <JaMa> antrik: but if you change them one week in one direction, after 2 weeks back to original, then 3 week to another new direction then you probably had very blury vision or not one at all and you're breaking existing apps just because
Dec 02 07:05:48 <JaMa> and I'm not whinning that I had to update 5 apps to even build with newer trunk (that's what I've expected when I decided to make those apps ready for new release), I'm complaining _only_ because I had to partially revert such changes
Dec 02 07:39:06 <mrmoku> JaMa: hmm... elsa still does not work
Dec 02 07:40:01 <JaMa> pam or without pam?
Dec 02 07:40:28 <JaMa> mrmoku: btw please review update Stabilizing wiki page
Dec 02 07:41:16 <mrmoku> JaMa: hmm... did you re-disable it?
Dec 02 07:41:21 <mrmoku> I'm using shr.conf unmodified
Dec 02 07:43:17 <mrmoku> JaMa: (stabilizing) *much* better :)
Dec 02 07:43:33 <JaMa> I've forced --disable-pam in elsa recipe and then reverted this patch after testing that elsa still builds and works (at least as with pam) with --disable-pam
Dec 02 07:43:47 <mrmoku> what does 1/2 mean though?
Dec 02 07:44:20 <JaMa> ah forgot it in Legend .. we should be able to say something like "partialy works"
Dec 02 07:45:00 <mrmoku> ok
Dec 02 07:45:21 <mrmoku> there's no pam loggers in elsa.log
Dec 02 07:45:23 <mrmoku> so without pam
Dec 02 07:52:00 <antrik> JaMa: no, they should do whatever works best for *them* -- if they prefer experimenting over trying to come up with a perfect vision up front, that's perfectly valid. (personally, I believe such an approach often leads to better results)
Dec 02 07:53:14 <mrmoku> antrik: during beta stage before release?
Dec 02 07:53:20 * mrmoku disagrees
Dec 02 07:53:40 <mrmoku> ok, right... elementary will not see the release
Dec 02 07:53:42 <mrmoku> anyway
Dec 02 07:54:38 <JaMa> antrik: it's just wasting efford to updated all API consumers just to check your Elementary.h looks nice..
Dec 02 07:54:38 <antrik> API breaks during beta are indeed bad
Dec 02 07:55:30 <JaMa> antrik: and one more point.. it's not some API magic which needs to be done.. it's usually just renaming functions
Dec 02 07:55:49 <antrik> JaMa: well, nobody forces you to follow each API change immediately. again, using trunk versions is your own choice...
Dec 02 07:56:04 <JaMa> antrik: so quite easy to rename in consumers too.. but also quite easy to make your mind how those functions should be named in the end
Dec 02 07:56:39 <JaMa> antrik: they are broking their own trunk.. many apps are there, BINDINGS are not updated..
Dec 02 07:57:56 <JaMa> antrik: so you maintain some app you shouln't update it's api to be compatible with APIs of libs you're depending on?
Dec 02 07:59:02 <JaMa> so shr-settings would depend on elementary from 2009, shr-e-gadget on elementary from 2010 and elsa on api from 2011 and we'll just say that you cannot use all 3 apps in same image? ;)
Dec 02 07:59:58 <JaMa> antrik: see http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg37313.html
Dec 02 08:06:34 <mrmoku> damn... systemd ordering cycle again :/
Dec 02 08:06:41 <mrmoku> now daywork first...
Dec 02 08:06:43 <mrmoku> bbl
Dec 02 08:36:11 <JaMa> and efl release.. r65800
Dec 02 08:48:12 <CIA-69> SHR: 03Martin.Jansa 07shr-chroot * r7b4b801feede 10/ (96 files in 17 dirs): system upgrade
Dec 02 08:50:55 <antrik> JaMa: naming is usually the *hardest* thing to make you mind up about ;-)
Dec 02 08:52:18 <antrik> as for the applications in efl repository, you are not forced to use trunk versions of these either...
Dec 02 08:52:41 <antrik> changing your mind is part of the normal development process; it's the final result that matters
Dec 02 08:54:02 <angelox|laptop> Good Morning Guys!
Dec 02 08:56:07 <antrik> the real problem is that efl developers fail to do regular releases, not that they mess with trunk
Dec 02 09:14:17 <TAsn> antrik, blamed? :P
Dec 02 09:14:43 <TAsn> antrik, as for releases: there'll be a new release sometime this week iirc
Dec 02 09:15:06 <TAsn> I *pushed* for trunk, because trunk was way better
Dec 02 09:15:17 <TAsn> after 1.1 I think it should be fairly the same
Dec 02 09:15:27 <TAsn> elementary is not yet released so you have to use trunk
Dec 02 09:15:47 <TAsn> and what API breaks did you notice during beta?
Dec 02 09:15:57 <TAsn> elementary is not beta
Dec 02 09:17:38 <TAsn> antrik, ah, let me correct myself, efl 1.1 was released an hour ago http://enlightenment.org/p.php?p=news/show&l=en&news_id=37
Dec 02 09:17:38 <TAsn> :P
Dec 02 09:18:42 <TAsn> I was pushing for trunk for a long time
Dec 02 09:18:54 <TAsn> because things were being more stable in trunk than releases
Dec 02 09:18:57 <TAsn> this is not the case anymore
Dec 02 09:19:18 <TAsn> but also, I use arch, I believe in constant upgrading :)
Dec 02 10:27:58 <mickey|> mrmoku: will you be @ ohsw on weekend?
Dec 02 10:30:27 <mickey|> morning PaulFertser 
Dec 02 10:33:06 <mickey|> bbiab, need to switch my new installation from unity to gnome
Dec 02 10:37:09 <mrmoku> mickey|: already switched? :)
Dec 02 10:44:47 <mickey_office> ~seen morphis
Dec 02 10:44:49 <apt> morphis <~morphis@dslb-092-076-172-134.pools.arcor-ip.net> was last seen on IRC in channel #openmoko-cdevel, 13h 59m 19s ago, saying: 'gn8'.
Dec 02 10:49:17 <mrmoku> mickey_office: hey
Dec 02 10:49:24 <PaulFertser> mickey_office: hey, g'day :)
Dec 02 10:49:32 <mrmoku> mickey_office: I had no plans to come... yesterday I took a look at the agenda
Dec 02 10:49:41 <mrmoku> which tempted me
Dec 02 10:49:54 <mickey_office> :)
Dec 02 10:50:02 <mrmoku> especially your vala talks and what Slyon has to say about SHR :)
Dec 02 10:50:27 <mrmoku> I don't know yet though... got to finish some daywork for a client till tuesday
Dec 02 10:50:29 <mickey_office> hmm…. right…. my vala talk *cough* i need to start
Dec 02 10:50:35 <mrmoku> and I'm late
Dec 02 10:50:37 <mrmoku> hehe :)
Dec 02 10:50:47 <mickey_office> ok, well it's pretty informal, so if you feel you have some time, just pop by
Dec 02 10:50:53 <mrmoku> great
Dec 02 10:51:04 <mickey_office> otherwise see you two weeks later i goess :)
Dec 02 10:51:09 <mrmoku> sure :)
Dec 02 11:01:31 * mrmoku lunch
Dec 02 12:44:01 * JaMa closing staging 001 
Dec 02 13:05:00 <CIA-69> SHR: 03Martin.Jansa 07shr-chroot * r39e9a9dab6c5 10/OE/bin/ (shr_core_staging_new.sh shr_core_update.sh): staging scripts: fix info symlink location and cd HOME before calling make update
Dec 02 13:11:53 <JaMa> mrmoku: released efl in jama branch :)
Dec 02 13:12:02 <JaMa> and SHR buildhost is working on 002 now
Dec 02 13:12:13 <JaMa> everybody please test 001
Dec 02 13:12:32 * JaMa sending announcement
Dec 02 13:16:15 <mrmoku> JaMa: cool... so you're free to do daywork now :-)
Dec 02 13:20:22 <JaMa> email sent
Dec 02 15:01:11 <GNUtoo> ok I'll test
Dec 02 15:01:21 <GNUtoo> btw how to make the feed include stuff?
Dec 02 15:01:29 <GNUtoo> I add in shr-feed task?
Dec 02 15:01:39 <GNUtoo> or is there a procedure?
Dec 02 15:02:08 <JaMa> sed replace for feed is written on wiki and in e-mail
Dec 02 15:02:23 <GNUtoo> no I mean add for instance picocom to the feeds
Dec 02 15:02:40 <GNUtoo> is it sufficent to add it to the feed task and push
Dec 02 15:02:45 <JaMa> there is task-shr-feed and picocom is already in
Dec 02 15:02:46 <GNUtoo> or is there a long procedure
Dec 02 15:02:50 <GNUtoo> ok
Dec 02 15:03:59 <JaMa> could you please cleanup your patches in meta-oe-contrib/shr so I can submit them in pull-request?
Dec 02 15:04:06 <GNUtoo> which patches?
Dec 02 15:05:09 <JaMa> picocom, fbreader, mplayer_svn
Dec 02 15:05:15 <GNUtoo> ok
Dec 02 15:05:19 <GNUtoo> I'll look
Dec 02 15:05:29 <GNUtoo> but for mplyer_svn it's way too much work
Dec 02 15:05:53 <JaMa> then can we drop it or move to some wip branch?
Dec 02 15:06:07 <GNUtoo> move is better
Dec 02 15:06:14 <GNUtoo> but wait a bit
Dec 02 15:06:27 <GNUtoo> I think there are problems with mplayer2 currently
Dec 02 15:06:30 <GNUtoo> and I must find why
Dec 02 15:06:48 <GNUtoo> it worked before and I suspect that some bits of mplayer1 remained
Dec 02 15:07:30 <GNUtoo> problems means impossible to play correctly a song without beeing cut often
Dec 02 15:08:21 <JaMa> or move it to meta-smartphone as I don't think meta-oe will ever accept that
Dec 02 15:08:35 <GNUtoo> let me finish debugging it 
Dec 02 15:08:38 <JaMa> ok
Dec 02 15:08:39 <GNUtoo> and then we can move
Dec 02 15:12:24 <pespin> GNUtoo, it seems changing alsa sink on gstreamer/emotion/enjoy is not easily feasible
Dec 02 15:12:32 <pespin> we'd need pulseaudio
Dec 02 15:14:19 <pespin> GNUtoo, btw, bt headsets arrived :) they work in PC with mplayer
Dec 02 15:14:56 <pespin> but we need some generic approach to get it working easily everywhere and that users can use easily
Dec 02 15:15:25 <pespin> I'd like to use them with enjoy but I can't find the way
Dec 02 15:17:13 <GNUtoo> pespin, what do you mean we need pulseaudio?
Dec 02 15:17:21 <GNUtoo> it's simple as writing an asoundrc
Dec 02 15:17:29 <GNUtoo> echo "foo" > .asoundrc
Dec 02 15:17:43 <GNUtoo> because we faces quite some problem with pulseaudio:
Dec 02 15:17:45 <GNUtoo> *)it's slow
Dec 02 15:17:52 <pespin> GNUtoo, I don't have much idea about sound stuff sorry
Dec 02 15:17:52 <GNUtoo> *)it doesn't work well on armv4:
Dec 02 15:18:06 <GNUtoo> it's simple
Dec 02 15:18:14 <GNUtoo> instead of using pulse
Dec 02 15:18:18 <pespin> so how would you set all sound go through BT without modifying apps?
Dec 02 15:18:24 <pespin> in a dynamic way
Dec 02 15:18:26 <GNUtoo> we should adapt fso to have a -Dbluetooth thing
Dec 02 15:18:32 <pespin> for example a UI toggle
Dec 02 15:18:37 <GNUtoo> in the /etc/asound.conf
Dec 02 15:18:47 <GNUtoo> and then play to bluetooth
Dec 02 15:18:51 <GNUtoo> or to normal
Dec 02 15:18:52 <pespin> but lots of apps doesn't let you define the alsa sink afaik
Dec 02 15:18:56 <GNUtoo> (!default)
Dec 02 15:19:14 <GNUtoo> ?
Dec 02 15:19:17 <pespin> so, if I understand correctly, most apps just have hardcoded "default" sink right?
Dec 02 15:19:18 <GNUtoo> gstreamer can do that
Dec 02 15:19:20 <GNUtoo> as mplayer
Dec 02 15:19:34 <GNUtoo> then you can change !default
Dec 02 15:19:53 <pespin> at any moment? 
Dec 02 15:19:57 <pespin> without problems?
Dec 02 15:19:58 <GNUtoo> no
Dec 02 15:20:05 <lindi-> GNUtoo: the problem with -Dbluetooth is that you need to kill the application to change the output to some other device?
Dec 02 15:20:30 <GNUtoo> lindi-, do you use pulseaudio on the freerunner?
Dec 02 15:20:45 <lindi-> GNUtoo: not yet :)
Dec 02 15:20:49 <GNUtoo> ok
Dec 02 15:21:10 <GNUtoo> pespin, try pulse and see by yourself, I'm not sure it's usable
Dec 02 15:21:41 <pespin> GNUtoo, about gstreamer, the problem is that you need to set a specific pipeline for that, and for example emotion(used by enjoy) uses generic playbin, which doesn't allow that easily.
Dec 02 15:22:00 <GNUtoo> there are priorities in gstreamer
Dec 02 15:22:02 <pespin> GNUtoo, for me it's ok to avoid pulseaudio, but I don't know if this can be done with alsa allow in a reasonable way
Dec 02 15:22:05 <GNUtoo> just change the priority
Dec 02 15:22:07 <pespin> with good user experience
Dec 02 15:22:10 <GNUtoo> or the settings in gconf
Dec 02 15:22:29 <pespin> I tried changing them
Dec 02 15:22:34 <GNUtoo> pespin, pulseaudio will eat too much CPU
Dec 02 15:22:43 <pespin> I know, that's why I'd like to avoid it
Dec 02 15:23:07 <GNUtoo> specially on armv4 where some atomic instructions are absent
Dec 02 15:23:09 <pespin> I tried changing settings in gconf in PC but couldn't get music go through BT headsets using gst
Dec 02 15:23:31 <GNUtoo> I cannot work on everything at the same time
Dec 02 15:23:41 <GNUtoo> in one hand JaMa pressure me for fixing some recipes
Dec 02 15:23:58 <pespin> I'm just asking if you if you had some idea, not telling you to fix it :)
Dec 02 15:24:01 <GNUtoo> in the other hand if I work on that I cannot fix the recipes
Dec 02 15:24:03 <GNUtoo> etc...
Dec 02 15:24:07 <GNUtoo> yes I've some idea
Dec 02 15:24:33 <GNUtoo> let me look for gconf
Dec 02 15:24:33 <pespin> as I don't have knowledge on sound stuff
Dec 02 15:24:38 <GNUtoo> ok
Dec 02 15:24:56 <pespin> in gconf you have system/gstreamer-0.10  there you have sinks stuff
Dec 02 15:25:04 <GNUtoo> ok
Dec 02 15:26:15 * mrmoku checks if fsoaudiod is already on the hacking agenda for FSOSHRCON
Dec 02 15:26:31 <GNUtoo> pespin, morphis also has some sound knowledge
Dec 02 15:27:32 <mrmoku> added
Dec 02 15:31:48 <GNUtoo> I don't find gstreamer-properties
Dec 02 15:32:57 <pespin> GNUtoo, in archlinux it's in gnome-media package
Dec 02 15:33:20 <pespin> btw, opening gstreamer-properties resets some values of gconf I changed manually ;)
Dec 02 15:33:37 <pespin> for example setting audiosink = "alsasink device=btbluetooth"
Dec 02 15:33:38 <GNUtoo> yes but I want to verify something
Dec 02 15:33:44 <GNUtoo> yes
Dec 02 15:34:11 <GNUtoo> because if I remember well you can put a pipe there
Dec 02 15:34:23 <pespin> mrmoku, will there be videoconference of FSOSHRCON?
Dec 02 15:34:25 <GNUtoo> and also there is a gstreamer bluetooth plugin
Dec 02 15:34:52 <GNUtoo> p   bluez-gstreamer                 - Bluetooth GStreamer support
Dec 02 15:34:58 <pespin> yeah the problem is that most players use playbin which doesn't permit all this smart modifications in pipelines
Dec 02 15:35:06 <GNUtoo> it permits it
Dec 02 15:35:10 <GNUtoo> let me try
Dec 02 15:36:05 <mrmoku> pespin: no
Dec 02 15:36:28 <GNUtoo> in gstreamer-properties you can choose:
Dec 02 15:36:30 <GNUtoo> *alsa
Dec 02 15:36:40 <GNUtoo> in alsa you can choose the device
Dec 02 15:36:42 <GNUtoo> and
Dec 02 15:36:45 <GNUtoo> *custom
Dec 02 15:36:55 <GNUtoo> where you can choose the pipeline
Dec 02 15:37:01 <GNUtoo> so it's very flexible
Dec 02 15:37:37 <pespin> I can't modify the pipeline there
Dec 02 15:38:01 <GNUtoo> on my laptop I can
Dec 02 15:38:42 <GNUtoo> the problem is rather another with alsa+bluetooth
Dec 02 15:38:49 <GNUtoo> there is no dmix for bluetooth
Dec 02 15:39:04 <GNUtoo> so you've got to ring on the external speakers
Dec 02 15:39:12 <GNUtoo> s/external//
Dec 02 15:39:14 <apt> GNUtoo meant: so you've got to ring on the  speakers
Dec 02 15:39:31 <pespin> I don't know what dmix is for mm
Dec 02 15:39:59 <pespin> GNUtoo, I don't have "custom" device in Alsa in gst-properties mm
Dec 02 15:40:08 <pespin> aaah
Dec 02 15:40:17 <pespin> custom on plugin :D
Dec 02 15:40:19 <pespin> yeah I can now
Dec 02 15:40:55 <GNUtoo> ok
Dec 02 15:41:07 <pespin> I'll try with that tomorrow
Dec 02 15:41:08 <GNUtoo> dmix means sound multiplexing at the alsa level
Dec 02 15:41:19 <GNUtoo> for instance ring+music at the same time
Dec 02 15:41:33 <pespin> ok, so we can't send music+ring to the bt headsets at same time right?
Dec 02 15:42:41 <GNUtoo> maybe it's possible but I've not found how yet
Dec 02 15:42:52 <GNUtoo> altough with my setup the phone do ring...on speakers
Dec 02 15:43:12 <GNUtoo> and I've not integrated yet the SCO
Dec 02 15:43:45 <mrmoku> hmm... should be possible if dmix happens on some virtual devices above, no?
Dec 02 15:47:33 <GNUtoo> dmix depends on hw plugin
Dec 02 15:47:38 <GNUtoo> or plughw
Dec 02 15:47:42 <GNUtoo> I don't remember
Dec 02 16:13:52 <GNUtoo> it seem indeed that mplayer2 is broken
Dec 02 16:14:00 <GNUtoo> [AO_ALSA] Write error: Broken pipe
Dec 02 16:14:00 <GNUtoo> [AO_ALSA] Trying to reset soundcard.
Dec 02 16:14:03 <GNUtoo> lots and lots of that
Dec 02 16:14:11 <GNUtoo> that's with alsa
Dec 02 16:14:20 <GNUtoo> oss->alsa should be changed in mplayer.conf I guess
Dec 02 16:17:39 <GNUtoo> doesn't seem in the deps
Dec 02 16:17:47 <GNUtoo> but in mplayer/mplayer2 binary itself
Dec 02 16:28:16 <CIA-69> freesmartphone.org: 03barklome 07settings-rework * r31d6f99d7066 10aurora/aurora-daemon/src/applications/app-settings/ (8 files in 4 dirs): aurora-daemon: settings: rework Slider for all delegates
Dec 02 16:31:37 <mrmoku> dos1: yo, if you have some time... I think shr-settings needs some API fixes :)
Dec 02 16:36:36 <dos1> mrmoku: it's possible :D
Dec 02 16:36:40 <dos1> mrmoku: but what's the problem?
Dec 02 17:11:36 <mrmoku> dos1: give me a bit of time to reproduce :-)
Dec 02 17:15:28 <mrmoku> that postmaster spam wave is starting to get on my nerves :(
Dec 02 17:16:47 <mrmoku> dos1: ImportError: /usr/lib/python2.7/site-packages/elementary/c_elementary.so: undefined symbol: elm_object_item_label_get
Dec 02 17:17:30 <JaMa> mrmoku: is it with image from jansa/test?
Dec 02 17:17:35 <dos1> mrmoku: ach, this kind of API fixes
Dec 02 17:17:39 <mrmoku> JaMa: with staging 001
Dec 02 17:17:45 <JaMa> mrmoku: ok :)
Dec 02 17:17:49 <dos1> mrmoku: yep, probably, i'm not up to date with e...
Dec 02 17:17:53 <mrmoku> or is that already fixed somewhere?
Dec 02 17:18:04 <mrmoku> dos1: text_get is what they call it now :P
Dec 02 17:18:47 <JaMa> mrmoku: I guess this one is binding fault not fixable in shr-settings
Dec 02 17:19:10 <JaMa> and probably already fixed in our version
Dec 02 17:19:41 <mrmoku> ahh, ok
Dec 02 17:19:45 <mrmoku> dos1: nvm then :)
Dec 02 17:19:49 <JaMa> r65791
Dec 02 17:20:52 <JaMa> but not sure if this whole commit can be applied in current SRCREV in shr branch
Dec 02 17:21:16 <JaMa> because it's changing a lot of genlist api which are newer than the rev there
Dec 02 17:21:46 <JaMa> mrmoku: we should test 1.1.0 from jansa/test and merge it to shr soon..
Dec 02 17:23:07 <JaMa> I plan to bump it as soon as 002 is out and I hope genlist API change will be complete
Dec 02 17:28:31 <mrmoku> ok
Dec 02 17:41:54 * mrmoku updates and triggers a build
Dec 02 17:42:43 <JaMa> *g*
Dec 02 17:42:45 <mrmoku> JaMa: btw. I wonder if we should suspend systemd work for a while
Dec 02 17:42:57 <JaMa> why?
Dec 02 17:43:00 <mrmoku> until it is better integrated
Dec 02 17:43:14 <mrmoku> hmm
Dec 02 17:43:17 <JaMa> isn't only elsa/xorg missing?
Dec 02 17:43:28 <mrmoku> elsa, yeah
Dec 02 17:43:43 <JaMa> we can still use old xserver-nodm-init..
Dec 02 17:44:00 <mrmoku> hmmm
Dec 02 17:44:11 <mrmoku> we probably should do that until elsa is working
Dec 02 17:44:33 <JaMa> agreed, if we want to finish systemd migration sooner than yes
Dec 02 17:44:54 <mrmoku> I somehow have to decide to either finish it fast or switch back to shr
Dec 02 17:44:58 <JaMa> I just expected that elsa will be drop in replacement so I've changed it and also switched to x11-common from xserver-common
Dec 02 17:45:05 <mrmoku> it's blocking anything else
Dec 02 17:45:13 <mrmoku> (on my part)
Dec 02 17:45:59 <mrmoku> JaMa: what do I have to do to switch back?
Dec 02 17:46:09 <JaMa> elsa?
Dec 02 17:46:12 <mrmoku> yeah
Dec 02 17:46:30 <JaMa> it should be in first 5 patches or so.. no big deal
Dec 02 17:46:37 <mrmoku> ok will check
Dec 02 17:47:07 <JaMa> btw did you notice PRINC change?
Dec 02 17:48:06 <mrmoku> just comment out those two:
Dec 02 17:48:08 <mrmoku> +VIRTUAL-RUNTIME_graphical_init_manager = "elsa"
Dec 02 17:48:08 <mrmoku> +VIRTUAL-RUNTIME_xserver_common = "x11-common"
Dec 02 17:48:28 <mrmoku> I saw the mails on oe lists
Dec 02 17:48:45 <JaMa> and later I've added more -systemd packages for it
Dec 02 17:48:48 <mrmoku> but not the end-result
Dec 02 17:48:52 <JaMa> and rebuild task-x11*
Dec 02 17:48:56 <mrmoku> ok
Dec 02 17:49:29 <JaMa> what if I split our changes to jansa/efl and jansa/systemd ?
Dec 02 17:49:51 <JaMa> whould that help you to revert only to latest efl and keep systemd separate from it?
Dec 02 17:50:01 <mrmoku> what else does efl have?
Dec 02 17:50:13 <JaMa> ?
Dec 02 17:50:14 <mrmoku> probably that would help me, yeah
Dec 02 17:50:31 <mrmoku> I mean jansa/efl what would it contain?
Dec 02 17:50:37 <mrmoku> (apart from elsa)
Dec 02 17:50:54 <JaMa> 1.1.0 efl including elsa changes but good old sysvinit image
Dec 02 17:51:09 <JaMa> so not forcing you to use elsa if you don't want to manually
Dec 02 17:51:23 <mrmoku> hmm
Dec 02 17:51:35 <mrmoku> testing 1.1.0 would be a good thing though
Dec 02 17:51:44 <JaMa> and then we would move jansa/efl to shr
Dec 02 17:51:47 <JaMa> for 003
Dec 02 17:51:58 <mrmoku> ok
Dec 02 17:52:02 <JaMa> I've also changed the way how efl bumps are
Dec 02 17:52:12 <JaMa> now released stuff will stay at 1.1.0
Dec 02 17:52:33 <mrmoku> very good
Dec 02 17:52:33 <JaMa> and only bindings/elementary and e17 will be bumped if EFL_SRCREV is changed (this is already in jansa/test)
Dec 02 17:53:11 <mrmoku> good, I will build anyway now with elsa disabled as login manager
Dec 02 17:54:33 <JaMa> and one last thing.. what if we add shr branch to meta-smartphone and master will be (in most cases) compatible with oe-core/meta-oe master and shr will be the branch for our extra commits not yet usable for oe-core/meta-oe master?
Dec 02 17:55:17 <JaMa> I don't want just another rebaseble repo, but still people are complaining when meta-smartphone/master gets incompatible and vice versa..
Dec 02 17:56:06 <mrmoku> hmm
Dec 02 17:56:41 <mrmoku> fine for me
Dec 02 17:57:32 <JaMa> the problem is that almost everytime someone pushes something to master, shr branch should merge it
Dec 02 17:58:14 <JaMa> ie for oe-core I'm maintaining sometimes 5 branches just to keep jansa/test up2date :/\
Dec 02 17:58:24 <mrmoku> heh
Dec 02 17:58:54 <JaMa> oe-core/master <- jansa/pull <- shr <- jansa/test
Dec 02 17:59:16 <JaMa> ok that's just 4 :)
Dec 02 17:59:23 <mrmoku> :)
Dec 02 17:59:49 <JaMa> but locally I'm doing all the builds only with jansa/test (because I need all changes in our queue)
Dec 02 18:00:30 <JaMa> but if I find some bug in commit which is already prepared in jansa/pull then I have to amend it to jansa/pull then rebase shr on top of jansa/pull and then rebase jansa/test on top of shr
Dec 02 18:00:41 <mrmoku> ERROR: xserver-common was skipped: shr DOES NOT support xserver-common because use x11-common now
Dec 02 18:00:44 <mrmoku> that one I missed
Dec 02 18:00:51 <JaMa> it's blacklisted in shr.conf
Dec 02 18:01:27 <mrmoku> yup, commented it out
Dec 02 18:15:29 <mrmoku> JaMa: I just saw that mickeyl put init system on the topics to discuss :)
Dec 02 18:18:16 <JaMa> yup I've noticed yesterday
Dec 02 18:30:08 <CIA-69> SHR: 03Martin.Jansa 07meta-smartphone * r85452a3fb965 10/ (29 files in 28 dirs): Subject: [PATCH] recipes: allow PRINC in multiple .bbappends
Dec 02 18:38:48 <nschle85> hello, i have a small git question: sometimes i think i have a deja vu: very often i see that the same patch seem to be applied several times, exaple: http://cgit.openembedded.org/openembedded-core-contrib/commit/?h=shr&id=32ffec1f0f5f75aeb9469cf27f1b26037ce84f17 but i swear that this patch is minimum some weeks old. 
Dec 02 18:39:13 <nschle85> who can explain it ?
Dec 02 18:41:11 <mrmoku> nschle85: that happens through rebasing or merging I think
Dec 02 18:41:11 <JaMa> that's because of rebase
Dec 02 18:42:46 <nschle85> rebase of shr branch against oe master ?
Dec 02 18:44:01 <JaMa> yes
Dec 02 18:59:06 <angelox|laptop> nschle85, as said,that apply's some-branch's patches in a branch to maintain some kind of equality of patches
Dec 02 18:59:40 <angelox|laptop> helps developers to do their work without loosing the master's patches (for example)
Dec 02 19:02:48 <nschle85> but why does it come several times ? i expect after one rebase it would never come again but this example i have seeen i think minimum 4 times
Dec 02 19:04:12 <angelox|laptop> maybe in different branches,that is supposed to be common i think
Dec 02 19:04:49 <angelox|laptop> in your example, OE hasn't just one branch :)
Dec 02 19:05:29 <nschle85> JaMa: rest in peace :-(   http://www.tagesschau.de/kultur/maulwurf100-magnifier_pos-1.html
Dec 02 19:06:18 <JaMa> nschle85: ie oe-core/master <- jansa/pull <- shr <- jansa/test
Dec 02 19:06:28 <JaMa> nschle85: and all those branches are rebased on each other
Dec 02 19:08:46 <nschle85> ahh ok, rebasing each other results in several equal commit messages
Dec 02 19:08:54 <CIA-69> SHR: 03Martin.Jansa 07meta-smartphone * r3492976e57d4 10/meta-shr/ (6 files in 5 dirs): shr-image: don't use IMAGE_BOOT to select basic runtime deps
Dec 02 19:32:32 <CIA-69> SHR: 03Martin.Jansa 07meta-smartphone * r5148bedd775d 10/meta-shr/recipes-shr/3rdparty/ (9 files in 2 dirs): iliwi: move to different git repo to maintain those patches
Dec 02 19:35:02 <waraqa> Hi
Dec 02 19:35:20 <waraqa> I'm trying to use usb keyboard on freerunner
Dec 02 19:36:09 <waraqa> Although keyborad is working but the text is only appearing on the console
Dec 02 19:36:53 <waraqa> How can I get X application to work with usb keyboard
Dec 02 19:37:59 <JaMa> mrmoku: update your config.mk, efl/systemd changes are splitted now
Dec 02 19:38:15 <mrmoku> JaMa: ok, thx
Dec 02 19:38:25 <mrmoku> jama/efl and jama/systemd ?
Dec 02 19:38:33 <JaMa> jansa/efl and jansa/systemd
Dec 02 19:38:46 <mrmoku> ahh, yeah... oe repo
Dec 02 19:39:57 <JaMa> and I've used same names in shr repo so my bash history lasts longer :)
Dec 02 19:42:52 <JaMa> mrmoku: also elsa changes are separated now
Dec 02 19:42:59 <JaMa> if you want to give it last try
Dec 02 19:43:22 * mrmoku pulls to get an overview
Dec 02 19:50:44 * JaMa going to reboot, bbl
Dec 02 20:19:26 <CIA-69> freesmartphone.org: 03barklome 07settings-rework * rf9ed06ee0343 10aurora/aurora-daemon/src/applications/app-settings/ (9 files in 5 dirs): aurora-daemon: settings: code cosmetics
Dec 02 20:43:58 <nschle85> mrmoku: did jama died during reboot ?
Dec 02 20:45:29 * angelox|laptop lol
Dec 02 20:45:57 <mrmoku> nschle85: he said bbl... so I already asumed it will be a longer reboot :-)
Dec 02 21:13:55 <CIA-69> freesmartphone.org: 03barklome 07aurora * rff5afa1ddbaf 10/aurora-daemon/README: 
Dec 02 21:13:55 <CIA-69> freesmartphone.org: aurora-daemon: add qmlwebkitplugin as dependence
Dec 02 21:13:55 <CIA-69> freesmartphone.org: - Needed by Aoura 0.2
Dec 02 21:18:25 <CIA-69> freesmartphone.org: 03barklome 07settings-rework * r0b688e65ae77 10aurora/aurora-daemon/src/applications/app-settings/ (7 files in 5 dirs): aurora-daemon: settings: cosmetics++
Dec 02 21:21:30 <CIA-69> freesmartphone.org: 03barklome 07aurora * r215f5a734fc4 10/aurora-daemon/src/applications/app-settings/ (14 files in 5 dirs): Merge branch 'settings-rework'
Dec 02 21:50:50 <nschle85> ok bye , i have to drive on ski-challenge
Dec 02 21:51:08 <angelox|laptop> see ya nschle85 
Dec 02 21:51:33 <nschle85> angelox are you skiing ?
Dec 02 21:53:31 <angelox|laptop> in Brazil? Are you kidding? :( ( /me would like to do that if in Brazil we had somehow to ski)
Dec 02 21:54:33 <nschle85> would you like to attend the biggest virtual contest in europe ? (is free of charge)
Dec 02 21:55:13 <nschle85> this weekend is the first race
Dec 02 21:55:57 * angelox|laptop never played a ski game/simulator
Dec 02 21:56:10 <nschle85> its funny :-)
Dec 02 21:56:37 <nschle85> because all alpine countries are plaining :-)
Dec 02 21:57:06 <nschle85> first time its not funny
Dec 02 21:57:20 <nschle85> do you have an irc client for windows ?
Dec 02 21:57:39 <angelox|laptop> hmm nope
Dec 02 21:57:48 <nschle85> i also nope
Dec 02 21:58:01 <angelox|laptop> webirc does help when in Windows :)
Dec 02 21:58:20 <angelox|laptop> but i hardly am in windows,just for some school works
Dec 02 21:58:35 <nschle85> so ok lets meet agian after reboot in the nemies OS :-)
Dec 02 21:58:41 <nschle85> enemies
Dec 02 21:59:12 <nschle85> my collegues does windwows not call an os .-)
Dec 02 21:59:28 <angelox|laptop> i don't think they are enemies,i just think they are some company that doesn't make a real-usable OS :)
Dec 02 21:59:45 <nschle85> angelox|laptop: agree
Dec 02 22:00:05 <nschle85> ok it can host some online games :-)
Dec 02 22:00:21 <angelox|laptop> yes :)
Dec 02 22:00:52 <nschle85> so are you interesed in popular online skiing ? 
Dec 02 22:01:07 <nschle85> so ill reboot and introduce you
Dec 02 22:01:28 <angelox|laptop> is needed some download or the game is in browser?
Dec 02 22:01:46 <nschle85> download, its really for free !!!
Dec 02 22:02:07 <nschle85> but ill explain you
Dec 02 22:02:26 * angelox|laptop doesn't think that this is a good somewhere to talk about it :)
Dec 02 22:03:25 <nschle85> so lets meet again in irc after reboot ?
Dec 02 22:03:54 <angelox|laptop> just tell me,how much MBs is the size of it?
Dec 02 22:04:15 <nschle85> its round about 70MB
Dec 02 22:04:30 <angelox|laptop> ok,i'll also reboot
Dec 02 22:04:46 <nschle85> so hope well meet in matrix :-)
Dec 02 22:04:55 <angelox|laptop> cya there! :)
Dec 02 22:05:01 <nschle85> bye
Dec 02 22:05:07 <angelox|laptop> bye
Dec 02 22:18:05 <nschle85> angelox|laptop: welcome
Dec 02 22:19:12 <angelox|laptop> nschle85: isn't talking via PM better? :)
**** ENDING LOGGING AT Sat Dec 03 02:59:57 2011