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