Meeting log 2012/08/16.

1 files changed, 539 insertions, 0 deletions

diff --git a/meeting-logs/kde-project-meeting-log-20120816.txt b/meeting-logs/kde-project-meeting-log-20120816.txt
new file mode 100644
index 0000000..c6ea614
--- /dev/null
+++ b/meeting-logs/kde-project-meeting-log-20120816.txt
@@ -0,0 +1,539 @@
+<johu> 1. Roll call
+<johu> !herd kde
+<willikins> (kde) abcd, alexxy, creffett, dilfridge, jmbsvicetto, johu,
+kensington, mschiff, patrick, reavertm, scarabeus, thev00d00
+<dilfridge> you're repeating yourself
+-*- creffett is still here
+-*- johu is here
+-*- dilfridge is here
+-*- tampakrap is here
+<johu> tampakrap wanna rejoin?
+<tampakrap> no
+-*- dilfridge thinks we should just do it
+<johu> jmbsvicetto / Thev00d00 ?
+-*- ago here too
+<dilfridge> :D
+<johu> ok meeting opened
+<johu> 2. KDE SC stabilization (15 minutes)
+<johu>    * Discuss/vote the options:
+<johu>    a) First 4.8.5 as decided in a former meeting, then 4.9.1 / 4.9.2.
+<johu>    b) Skip 4.8.5, start with 4.9.0 / 4.9.1 directly.
+<johu>    c) Other?
+<ago> tampakrap: do you know anything about kde-stable subproject?
+<jmbsvicetto> here
+<creffett> isn't 4.8.5 mostly bugfix?
+<dilfridge> yes
+<dilfridge> problem is, noone of the team is running it
+<johu> yes we can stable it realy fast because of no new deps...
+<jmbsvicetto> judging from prior experience, we should probably skip 4.9.0
+<dilfridge> and all ~arch users have already upgraded to 4.9
+<johu> dilfridge: wrong i run 4.8.5 on netbook
+<ago> dilfridge: I'm here to run it
+<dilfridge> ok cool & cool :)
+<johu> there are 2 issues: da translation and a missing theme for splashx
+<johu> the translation compile error should occure on kdepim-l10n as we split
+this up
+<dilfridge> are there fixes / workarounds?
+<johu> if we decide on option b) i would start with 4.9.1 as upstream done a
+lot of bug fixing since 4.9.0
+<johu> dilfridge: yes we can patch it
+<dilfridge> both?
+<johu> for l10n
+<creffett> my question is whether it fixes any bugs that are relevant to us
+<johu> with the theme i hadnt a look so far
+<johu> creffett: which version?
+<creffett> johu: 4.8.5
+<johu> we had two fixed tracking bugs as i remember right
+<johu> any opinions about the direction a) b) c)?
+<ago> A imho
+-*- dilfridge votes a)
+<creffett> ++a, then on to 4.9.1
+-*- johu votes a)
+<Thev00d00> I'm here FYI
+<johu> Thev00d00: then use your voice :P
+-*- Thev00d00 reading backlog
+<jmbsvicetto> a)
+<ago> After the vote I would just add a note, plese give me a voice when I can
+<johu> ago: can we do 485 faster than the 30 days?
+<ago> johu: sure, for amd64 and x86
+<Thev00d00> b)
+<ago> but scarabeus can do it on ppc :P
+-*- ago hides
+<dilfridge> ago: feel free to do and say whatever you want... btw if you leave
+and rejoin you'll be op in #gentoo-kde :]
+<ago> dilfridge: thanks...
+<dilfridge> speaking of scarabeus...
+<johu> summary: majority is for 485 and continue with 491/492 afterwards
+<jmbsvicetto> dilfridge: no need to leave - /cycle
+<dilfridge> ah ok
+<johu> 3. Solaris patches (5 minutes)
+<johu>    * We apply many patches to support Solaris, but there seems to be no
+prefix
+<johu>    keyword. Does anyone know anything about them? If we are supporting
+Solaris,
+<johu>    Kensington would like to push these patches upstream. Does anyone
+have
+<johu>    access to a box to test if they are still useful?
+<johu> that was kensingtons topic but we can talk about it
+-*- dilfridge wanders off in search of a beer
+-*- johu personally dont cares about minor arches in kde point of view...
+<ago> ok, is know that every +1 releases is better than the precedent, but in
+this case I would copy kernel's team strategy about stabilization, they
+stabilize always non the first release, e.g. x.x.7/8 so, since the stable kde
+works pretty good, how sound think to stabilize a major release of 4.9?
+<ago> e.g. 4.9.4
+<ago> instead aof proposed 4.9.1
+<johu> ago: the past has shown that with start of stabilization we fixed a lot
+of bugs
+<johu> and .1/.2 are in common the most valuable releases
+<ago> johu: yes, sure, but for me, go to 4.8.5 to 4.9.1(in that case) seems
+like a regression, since there will be a lot of bugs
+<Thev00d00> I don't prefer agos idea
+<ago> Thev00d00: reason?
+<johu> ago: which bugs to you mean " since there will be a lot of bugs"?
+<johu> /s/to/do/
+<dilfridge> I think ago means upstream bugs
+<ago> johu: mean usually bugs of first release
+<ago> dilfridge: yes
+<johu> thats why i prefer not to stable a .0 release
+<dilfridge> we're more concerned about finding Gentoo / packaging bugs, and
+having two runs of stabilization inside one 4.X cycle helps there
+<ago> johu: me too, but I'm only said to increase that .0 :P
+<johu> ok we are finished now with 2) ?
+<jmbsvicetto> ago: the kernel moves a lot faster than kde and they used to
+have parallel development
+<ago> jmbsvicetto: yes, but is just the concept to stabilize not the first
+release
+<johu> ago: thats what we are doing :D
+<jmbsvicetto> ago: kde basically throws away the previour minor release when
+they launch a new one. So it's very unlikely we'll get a 4.8.6 with any fixes
+and 4.9.4 will likely take around 4 / 5 months
+<dilfridge> I think we should target .1 ... usually we go for .2 anyway then
+:D
+<Thev00d00> people will moan
+<Thev00d00> they like fast fast stabilisation
+<Thev00d00> :-)
+<johu> keep ppc please in mind...
+<ago> Thev00d00: who wants a newer kde, go to ~arch
+<ago> the stable users expect minor bugs as possible
+<johu> thats right!
+<johu> <johu> 3. Solaris patches (5 minutes)
+<johu> <johu>    * We apply many patches to support Solaris, but there seems
+to be no prefix
+<johu> <johu>    keyword. Does anyone know anything about them? If we are
+supporting Solaris,
+<johu> <johu>    Kensington would like to push these patches upstream. Does
+anyone have
+<johu> <johu>    access to a box to test if they are still useful?
+<johu> <johu> that was kensingtons topic but we can talk about it
+<dilfridge> ago: how about this,
+<dilfridge> we now decide "490 will never go stable, we talk about 491 when
+it's out for a while"
+<ago> dilfridge: fine
+<dilfridge> and then we can always still say we wait for a later release
+<dilfridge> if it's too buggy.
+<dilfridge> the one problem with testing is,
+-*- johu is chairing
+<dilfridge> many problems for users occur when they upgrade major version
+-*- creffett suggests hitting people with the gavel until they move on
+<dilfridge> so, many problems we will only see once many people upgrade to 4.9
+<dilfridge> but anyway, this is not urgent now
+<dilfridge> so let's continue
+<johu> so where are the dinosaurs?
+<dilfridge> [21:40:05] <johu> <johu> 3. Solaris patches (5 minutes)
+<dilfridge> [21:40:05] <johu> <johu>    * We apply many patches to support
+Solaris, but there seems to be no prefix
+<dilfridge> [21:40:05] <johu> <johu>    keyword. Does anyone know anything
+about them? If we are supporting Solaris,
+<dilfridge> [21:40:05] <johu> <johu>    Kensington would like to push these
+patches upstream. Does anyone have
+<dilfridge> [21:40:05] <johu> <johu>    access to a box to test if they are
+still useful?
+<dilfridge> [21:40:07] <johu> <johu> that was kensingtons topic but we can
+talk about it
+<johu> whats about the solaris stuff?
+-*- creffett votes "no opinion"
+<dilfridge> well reavertm is obviously logging but away, I sent scarabeus a
+reminder but got no reply yet
+<johu> jmbsvicetto?
+-*- dilfridge thinks "remove the patches if noone is interested in a keyword"
+<jmbsvicetto> johu: solaris? I don't know anything about it
+<johu> ok then we can give kensington the go to drop it
+<jmbsvicetto> johu: I'd ping the prefix team about that. If we get no reply,
+drop them and wait for someone to cry about them ;)
+<johu> ?
+<johu> jmbsvicetto: good statement lets move on
+<johu> 4. KDE stable subproject (10 minutes)
+<johu>    * Discuss the new KDE stable subproject, as proposed by ago.
+<johu> ago: its your turn :P
+<ago> well
+<ago> I explain all in a mail sent to all, anything not clear?
+<ago> or everyone didn't look at it?
+<johu> how many ppl do you have gathered so far?
+-*- johu likes the idea but testers are not very long term motivated in
+general
+<ago> johu: this is the point of start for new developers interested to join
+kde
+<ago> in gentoo obviously
+<dilfridge> I think we can always use more people who run stable/stable
+candidate and fix bugs there
+<dilfridge> because most kde devs run 9999
+<jmbsvicetto> I honestly don't see if there's much to gain from having
+separate sub-projects for HTs and stable KDE, but if there are enough people
+wanting to do stable kde work and not general HT work, then go for it
+<ago> ok, since there is the time, let me re-explain for all :)
+<creffett> well, we don't really have an active HT group last I checked...
+<ago> creffett: yes
+<ago> jmbsvicetto: the HT project seems dead
+<jmbsvicetto> creffett: but what would prevent anyone from being a member of
+HT and do stable work?
+<johu> obviously :D
+<dilfridge> [21:49:39] <ryao> dilfridge: The last I heard, Qt was broken on
+Prefix. Once that is fixed, the solaris patches should become relevant.
+<ago> so the goal of kde-stable is involve people without doing ebuild quiz
+<creffett> jmbsvicetto: I have no problem with that, but we kind of need to
+restart the project first
+<jmbsvicetto> ago: I understand, but I don't think there's much to gain from a
+stable sub-project. If you get people interested on that, I won't object,
+though
+<ago> Now the quiz for arch/herd tester has been changed, but I remember When
+I did it for arch tester...is a pita
+<dilfridge> creffett: jmbsvicetto: johu: we could see it as an alternative
+approach to HT
+<jmbsvicetto> dilfridge: HTs did a more general job
+<dilfridge> ok
+<jmbsvicetto> dilfridge: they also helped with patches, testing stuff,
+following upstream (live) commits
+<ago> jmbsvicetto: when members counts our HT project?
+<jmbsvicetto> but to be clear, I don't have anything against a stable
+sub-project. If you can gather people wanting to do that, great :)
+<dilfridge> I just find ago's idea very useful, because our kde team work is
+often much focussed on the bleeding edge, and only the one guy leading the
+stabilization runs the candidate
+<creffett> +1 dilfridge
+<johu> i would vote for a more upstream oriented direction
+<johu> like kdepim bug day
+<ago> johu: I think there are a lot of people interested in kde (in general),
+we do it for improve QA on gentoo
+-*- dilfridge gets a headache hearing "kdepim bug day"
+<johu> take a aspirin :P
+<creffett> how about we start by re-establishing a KDE herd-testing group
+<ago> @all: which members counts ht project?
+<creffett> and from there, if we have time, inclination, and interest, we make
+a sub-group for stable
+<ago> I know many people and AT that runs kde, they will happy to help
+<dilfridge> creffett: better not, we should really focus this on "stable"
+<creffett> dilfridge: why not general testers first?
+<johu> so let me summarize: we have no objections, ago takes care of
+establishing that group of people and updates our site
+<dilfridge> creffett: because it's getting to "undefined"...
+<johu> any additions?
+<dilfridge> vague
+<ago> johu: ok, I'm just asking about HT, if there are no people, we just make
+it as dead?
+<dilfridge> ago++
+<johu> yes
+<dilfridge> yes
+<creffett> ++
+<johu> last chance, any additions?
+<ago> yes
+<dilfridge> [21:57:12] <darkside_> dilfridge: dunno. feel free to drop all
+non-upstreamed stuff.
+<ago> kde-stable probably will inherit things from HT, e.g. you can ask a test
+to any member and/or similar, we can document it
+<ago> so, see it as an improvement from HT without quiz
+<dilfridge> sounds reasonable I think
+<johu> fine
+<creffett> agreed
+<johu> 5. Bugs (30 minutes)
+<johu>  * app-cdr/k3b: Excessive use of REQUIRED_USE (and wrong combination
+<johu>    USE="lame"+"encode") REQUIRED_USE was added, otherwise USE="-encode
+lame"
+<johu>    does nothing. https://bugs.gentoo.org/show_bug.cgi?id=417235
+<johu>    Options:
+<johu>         1. Revert to original behaviour - we don't care that
+USE="-encode lame"
+<johu>         does nothing
+<johu>         2. Keep the REQUIRED_USE, but rename lame -> mp3
+<johu>         3. Drop the encode flag, but move the optional RDEPS to an elog
+<johu>         4. Drop the encode flag and keep optional RDEPS (current
+behaviour)
+<johu> kensington is not here, any opinions?
+<Thev00d00> #2
+<tampakrap> 2
+<johu> tampakrap: you wanna rejoin? :D
+-*- dilfridge has no opinion
+<tampakrap> I said no!
+<johu> :D
+<dilfridge> _ /msg Chanserv add #gentoo-kde tampakrap ...
+<johu> i am so forgetful 
+-*- johu votes for 2
+<ago> 2 is fine
+<johu> * cmake-utils.eclass: add support for dev-util/ninja
+<johu>    https://bugs.gentoo.org/show_bug.cgi?id=430608
+<dilfridge> do we want to support two different build systems?
+<johu> i would vote for an new eclass that inherits cmake.eclass 
+<dilfridge> I'd suggest we only allow this with I_KNOW_WHAT_I_AM_DOING
+<Thev00d00> AFAIK ninja just generates make files?
+<dilfridge> nope it's a make alternative
+<dilfridge> cmake generates the files for ninja, as it generates Makefiles for
+make
+<Thev00d00> oh I see
+<dilfridge> actually, before we decide on this one someone should try to build
+whole kde with the new generator :D
+<dilfridge> and no, I'm not volunteering
+-*- johu has a lot of things to compile as x86 arch member, no interest
+<dilfridge> we can add this to the eclass
+<tampakrap> I am willing to build/test stuff
+<Thev00d00> +1 for applying the patch
+<dilfridge> but the generator variable should only be respected if
+I_KNOW_WHAT_I_AM_DOING is set
+<tampakrap> but not willing to fix or patch anything
+<dilfridge> to avoid an insane number of bugs
+<dilfridge> imho
+<ago> if there is anything to compile give me a list
+<ago> :D
+<Thev00d00> same as tampakrap here
+<Thev00d00> I don't think I_KNOW is needed
+<dilfridge> yeah after all it needs to be set in ebuild or make.conf
+<Thev00d00> but make should be preferred
+<Thev00d00> even if ninja is present
+<dilfridge> for sure
+<Thev00d00> agreed then?
+<johu> yes
+<dilfridge> can we at least have some elog about untested backend?
+<dilfridge> or einfo
+<Thev00d00> elog spam FTL
+<dilfridge> how about,
+<dilfridge> we only output a message if the build fails
+<dilfridge> must be possible somehow
+<dilfridge> then telling "please use make backend before reporting bug"
+<Thev00d00> yeah, sounds good
+<tampakrap> bad idea, elog beforehands is sufficient
+<johu>    * app-office/calligra-2.4.3: move fonts to separate packages
+<johu>    https://bugs.gentoo.org/show_bug.cgi?id=427910
+<Thev00d00> for every make based package? :(
+<Thev00d00> *make
+<dilfridge> didnt I close that one already
+<johu> dilfridge: i know you closed the bug but i want to discuss this
+<Thev00d00> argh android
+<dilfridge> ok
+-*- creffett thinks it's pointless to split off a few small files here for no
+appreciable gain
+<johu> is there an license breakage?
+<tampakrap> isn't there a license violation by splitting oxygen-icons? :)
+<johu> we dont split it :P we remove svgas
+<dilfridge> tampakrap: not really since we use the bindist useflag I think...
+<jmbsvicetto> dilfridge: I think there would be a license violation if we
+didn't provide a way to get the official tarball
+<jmbsvicetto> dilfridge: but we should probably ask licenses@ about that
+<johu> from technical point of view this is a totally senseless bug....
+<johu> there is no purpose at all (you save some kbs on HD) and get with new
+bumps maybe more work 
+<johu> we could extend LICENSE var if its needed...
+<dilfridge> the overall reaction to this bug seems to be a definite "meh."
+<creffett> mhm
+<johu> "we are not debian" :P
+<dilfridge> le sigh
+<dilfridge> [22:24:41] <willikins> New bug: https://bugs.gentoo.org/431680
+"app-office/calligra-2.5.0 has dev-db/mysql automagic"; Gentoo Linux, KDE;
+CONF; nikoli:dilfridge
+<johu> * www-client/rekonq-1.0: please move Nunito-Regular.ttf to separate
+package
+<johu>    https://bugs.gentoo.org/show_bug.cgi?id=427914
+<johu> this is the related bug to the last one...
+<johu> its ONE file!
+<creffett> same reaction
+<tampakrap> recruit the guy to do those things by himself
+<dilfridge> the question is, are these fonts already somewhere else...
+<johu> tampakrap: do it
+<tampakrap> he is in #gentoo-kde btw
+<dilfridge> but even then, if versions differ we're creating the bugs from
+hell
+<dilfridge> tampakrap: yes we know :]
+<johu> so summarize?
+<creffett> summary: RESOLVED DONTCARE
+<dilfridge> cleanest way would probably be "the fonts are already in a
+dedicated font package, so we depend on it and delete them locally"
+<dilfridge> but creating a new font package for one file, NO
+<ago> creffett: ++ :D
+<dilfridge> and if versions differ that may lead to strange problems
+<dilfridge> so I think I'm with creffet
+<johu> whats about the license problem?
+<dilfridge> that needs to be spelled out in detail first
+<johu> who asks license@?
+<dilfridge> as long as we dont even know if there is a license problem, ...
+-*- creffett files a bug to add "DONTCARE" as a bugzie option
+<dilfridge> RESOLVED MEH
+<johu> this log is public...
+<johu> dilfridge: how about to involve upstream?
+<tampakrap> good luck
+<dilfridge> we can do it, and calligra upstream is usually responsive, but
+before that we need to figure out if there actually IS a problem
+<tampakrap> and a gain by the move
+<dilfridge> so, anyone figure out if there is a license problem, and a gain by
+the move,
+<dilfridge> and then I can talk to calligra upstream (who know me)
+<johu> anybody interested?
+<johu> ok i take that as no
+<johu> * net-libs/libkolabxml-0.8.0[php] fails
+<johu>    https://bugs.gentoo.org/show_bug.cgi?id=430858
+<johu>    The cause here appears to be that FindPHP4.cmake does not look in
+<johu>    /usr/include/php5.*. (and there is no FindPHP5.cmake). This
+potentially means 
+<johu>    that every search for PHP in cmake is broken (though it appears that
+nothing
+<johu>    in kde-base at least has IUSE="php, explaining this not being
+caught)
+<creffett> my turn
+<creffett> I've upstreamed this one, but just wanted to see if anyone else has
+opinions on it
+<johu> this issue is connected to kde491 stable :P
+<creffett> it is?
+<dilfridge> sounds good to push this upstream
+<johu> its a dep of kdepim-runtime, if we solve this properly we can servce
+users the feature
+<creffett> mmkay
+<creffett> well
+<creffett> question 1: does anyone know of a KDE package that actually
+uses/deps on PHP?
+<johu> not that i know....
+<tampakrap> yes
+<tampakrap> a kdevelop plugin
+<dilfridge> kdevelop parts
+<dilfridge> yes
+<creffett> hm, I'll look at that
+<tampakrap> and it's working pretty well actually
+<johu> tampakrap: i miss you
+<creffett> but basically what happens here is libkolabxml calls
+FIND_PACKAGE(PHP4 5.3 required) or something to that effect
+<tampakrap> <3
+<creffett> because there is no FindPHP5 module
+<creffett> but regardless of that, our PHP is in /usr/lib/php${PV}
+<tampakrap> there is no module in official cmake or kde packages you mean?
+<tampakrap> or noone ever wrote one?
+<creffett> tampakrap: no official module
+<creffett> a google search turned up a couple custom ones, but basically all
+they did was replace "php4" with "php5" which still doesn't solve things
+<tampakrap> then ask kensington to try to push one upstream
+<tampakrap> since he is pretty known in buildsystem now
+<creffett> my concern here is that I don't know if there's a nice way to do
+this for Gentoo's PHP style
+<creffett> is there a nicer way to specify the paths available than listing
+every PHP minor version? (e.g. 5.3, 5.4, 5.5 when it comes out...)
+<johu> creffett: good proposal from tampa, kensington knows a lot of cmake
+stuff
+<creffett> johu: okay, will shoot him a note
+<dilfridge> creffett: not sure about that, I still remember the FindBoost pain
+<tampakrap> listing every minor version does not look dirty to me tbh
+<creffett> tampakrap: we then have to bump the modules every time a new PHP
+comes out
+<Thev00d00> other distros don't slot their php generally
+<tampakrap> if you want to avoid that, then you need to write a proper build
+system first
+<johu> 6. Open floor (15 minutes)
+<tampakrap> I know, deal with it
+<creffett> tampakrap: "deal with it" wasn't quite what I was hoping to hear :P
+<tampakrap> life is hard :)
+<dilfridge> http://dev.gentoo.org/~dilfridge/shirts-from-hell-small.jpg
+<tampakrap> so, regarding open floor, and since I missed the discussion for HT
+and stable subproject
+<tampakrap> may I revive the topic?
+<tampakrap> is ago still here?
+<johu> ago is chuck norris
+<dilfridge> ago: ^
+<johu> he is everwhere
+<dilfridge> (ago's highlight works only with the :)
+<tampakrap> ok so
+<tampakrap> in short
+<tampakrap> scarabeus I think invented to have HTs back then, with the first
+candidate being me
+<tampakrap> but it turned out to be a failure as an idea, since people that
+wanted to do ebuild stuff were fine with just overlay access
+<tampakrap> and the HT status offers a cloak only, which is bullshit
+<tampakrap> so, I decided in a previous meeting to stop that and just have a
+list with overlay committers
+<Sput> indeed :)
+<tampakrap> and try to make them directly developers
+<tampakrap> so, if you are going to invent any sub-project again or whatever
+-*- johu wants reviewboard or similiar for overlay access by users
+<tampakrap> don't put any paperwork there, and try to motivate people to get
+dev status directly
+<tampakrap> johu: clone the repo in gentoo's github account, there's your
+reviewboard
+<johu> tampakrap: that doesnt solve the problem that they can push the
+official overlay
+<tampakrap> don't follow
+<tampakrap> they can send merge requests, they can easily get account without
+quiz (just by asking)
+<tampakrap> so what's the problem?
+<ago> just go for a moment in another place :)
+<dilfridge> btw kde is one of the best-staffed projects I know at the
+moment...
+<tampakrap> anyway, I think I made my point regarding the HT subproject, feel
+free to ping me for anything regarding getting new contributors
+<tampakrap> I'm interested
+<tampakrap> either to provide experience or mentor people
+<ago> tampakrap: the goal is have more testing, not just rename HT project
+<johu> tampakrap: my 
+<johu> arg
+<johu> ignore me
+<dilfridge> _ /ignore johu
+<dilfridge> done
+<dilfridge> :D
+<tampakrap> ago: you want to create a project that does what exactly?
+<tampakrap> sorry for asking but you had internal discussion I suppose instead
+of doing it in gentoo-desktop ml :)
+-*- johu will prepare kde 485 next week
+<ago> take care of testing next stable version on a completely stable
+environment
+<tampakrap> ok, my personal opinion is that you don't want a subproject or a
+new team for that
+<tampakrap> you need to document procedure, write intergration tests maybe,
+and put it somewhere under QA
+<tampakrap> and make it more general, as it doesn't seem to me something that
+can be kde only
+<tampakrap> alternatively:
+<tampakrap> KDE upstream have a QA team now that test the betas when they come
+out, you could ask for their suggestions and ways of working
+<tampakrap> and cooperate in order to have a good set of products BEFORE the
+next major release hits distros (and ours as well)
+<dilfridge> tampakrap: but we're NOT talking about KDE betas here
+<ago> tampakrap: wait, you can't know more details about it, let me explain :)
+<tampakrap> true, we are talking about QA tests before stabilization
+<tampakrap> which is something that I'm doing professionally the past 8 months
+:)
+<dilfridge> we're talking about all the problems that always ONE guy had to
+fix, the one gentoo-kde dev who is overseeing the stabilization and the only
+one still  running that version :P
+<ago> tampakrap: now we have decided t ostabilize 4.8.5, so when johu will
+prepare a list I will start to test and use it in the next time but I can't
+ask to other member/tester to use beta or software that have potentially bugs,
+because they will use it ~ as a primary system
+-*- dilfridge thinks we should close the meeting, his laptop battery is giving
+up...
+<tampakrap> yeah sorry
+<Thev00d00> dilfridge + +
+<tampakrap> we can move the discussion in gentoo-kde
+<johu> no no
+<johu> i have topic too
+<Thev00d00> Quassel for android needs nick completion...
+<dilfridge> Thev00d00: ++
+<dilfridge> Sput: ^
+<johu> i will start with moving defaulting KDE_SCM to git
+<dilfridge> err sorry, wrong person
+<johu> any objections?
+<dilfridge> no, sounds ok
+<dilfridge> what is still in svn?
+<johu> 1/3 i would guess
+<Thev00d00> there you go then :-)
+<dilfridge> we'll probably have portage in git before they finish
+<Sput> Thev00d00: afaik it has if you long-tap the search button or something
+<johu> kdegames for example, but svn2git rules are heavily in construction
+<dilfridge> since the upstream migration is far over 50% then, I see no
+problem with switching default
+<johu> ok thanks]
+<Thev00d00> Sput: it works! my word :-)
+<johu> meeting is over, thanks to all
+<dilfridge> johu: thanks for chairing :D
+<Thev00d00> G'nite all