path: root/meeting-logs/20120816.txt

<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