diff options
Diffstat (limited to 'meeting-logs/20120816.txt')
| -rw-r--r-- | meeting-logs/20120816.txt | 539 |
1 files changed, 539 insertions, 0 deletions
diff --git a/meeting-logs/20120816.txt b/meeting-logs/20120816.txt new file mode 100644 index 0000000..c6ea614 --- /dev/null +++ b/meeting-logs/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 |