[21:27:14] ok let's start [21:27:23] roll call plz [21:27:26] !herd kde [21:27:28] (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired [21:27:48] here [21:28:17] . [21:28:43] here [21:28:56] * alexxy here or there [21:29:00] alexxy: indeed :P [21:30:19] . [21:30:25] Sput: we need you for this one, present? [21:31:03] lets start with kdepim [21:31:14] jorge is going to be around in ~10 minutes [21:31:22] hmm [21:31:26] so the relevant tasks even for him should be that way preserved :] [21:31:31] TOPICS: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/meeting-2010-02-25;h=dafe5aa85c43ba9737c783576af83c972ea82afa;hb=594ec14216daa0f2f331295d4baff3e0f6d78a5c [21:32:14] ok about kdepim and enterprise useflag [21:32:32] also can we discuss snapshots for 4.5 pre alphas? [21:32:33] =) [21:32:50] ohnoes [21:32:51] sure, along with this [21:33:11] *** Quits: j0hu (~quassel@quassel/contributor/j0hu) (Read error: Connection reset by peer) [21:33:19] also using lxc as testbead for testing kde builds [21:33:25] the kdepim issue is about the trunk kde i don't know if anyone of you is interested in it [21:33:30] * alexxy prepared some containers [21:33:55] tampakrap: what issue? [21:34:01] kmail is broken in current trunk, i tried to package the enterprise branch which is supposed to work [21:34:26] why we should care about trunk? [21:34:31] afaik the enterprise branch should be available for releases as well [21:34:39] reavertm: because that's what's going to be in 4.5 [21:34:44] enterprise branch should be availible for everything [21:35:01] scarabeus: jmbsvicetto and i talked with a kde dev [cant recall his name right now] who told us enterprise branch is what they really care about [21:35:24] we should just monthly generate our own kdepim tarball from that branch [21:35:27] and be done with it [21:35:34] maybe even forgot about non-enterprise :] [21:35:36] considering the [crappy] state of kdepin right now, thats a good idea [21:35:39] two packages failed to compile from enterprise stuff, plus a flag isn't possible for trunk as ebuilds are different [21:35:40] kdepim* [21:36:28] 1) there is enterprise related cmake switch in cmakelists.txt - maybe it should be used when bulding enterprise branch [21:36:47] am i right that kmail is broken because of mail storage migrartion to akonadi? [21:36:49] 2) still don't see why we should care :P [21:37:02] reavertm: enterprise should actually work OK [21:37:08] and kde devs care about it not breaking [21:37:17] at least thats what we've been told [21:37:18] :p [21:37:22] i agree with reavertm, too much work, maybe we should just wait [21:37:28] too much work for nothing [21:37:29] problem is it does not follow kde release schedule [21:37:44] it is released with each even release [21:37:51] especially if apparently they're going to merge it eventually? [21:38:40] no its not going to be merged [21:38:49] now, I've not tried to build it yet - is it possible to use our ebuilds? [21:38:59] or it differs too much so that it's impossible? [21:39:04] okay, i am having hardware issues with my trunk machine and don't know when it will be back, so i can't work on it any more [21:39:10] it differs too much [21:39:21] it's not impossible, it is way too much work [21:39:21] Hello [21:39:26] tampakrap: you are talking about trunk, we are talking about releases [21:39:28] hey jmbsvicetto [21:39:34] sorry for being late [21:39:37] i'm talking about enterprise itself [21:39:40] I confused the hour again :\ [21:39:52] * spatz is back [21:40:16] and my opinion is the same for the snapshots, way too broken to be provided to users [21:40:45] i can announce it and blog it, whatever, that we can't provide them if you agree [21:40:49] other issue, how are we going to provide it? split like kdepim? [21:41:15] yes, it needs different branch of ebuilds [21:41:44] anyone willing to work on it? [21:41:54] and probably blocking kdepim... [21:42:01] or just postpone it for next meeting? [21:42:03] exactly [21:42:17] ok i personaly cant promise i will devote time to it :/ [21:42:30] so it would need some maintainer, even non dev [21:42:39] just in overlay so we see the potential [21:42:44] and then we can put it into tree [21:42:48] agreed [21:42:50] i could announce it [21:43:28] ok we should anounce global call if we find someone interested, i think we can help with basics but are busy enough to do it ourselves [21:43:38] tampakrap: so could you sent it to dev-anounce and desktop mls? [21:43:45] although i doubt there will be someone willing to do so much work for nothing [21:43:47] I'm not interested in kdepim, so I won't be working on it [21:44:05] yes, even blog the whole kdepim problem in trunk [21:44:34] and thus i'm against providing the snapshots ( alexxy ) yet [21:45:02] yeah no snapshot until .70 as with 4.4 should be done [21:45:16] *** Joins: Civil (~Civilian@95-27-138-158.broadband.corbina.ru) [21:45:16] .85 I would say even :P [21:45:21] haha [21:45:25] no =) [21:45:27] .70 [21:45:28] .70 is enough for ricers :D [21:45:28] beta 1 :P [21:45:30] 4.5.1? :P [21:45:33] aka alpha0 [21:45:34] =) [21:45:36] btw, word of warning [21:45:45] when kmail is ready i'd say [21:45:52] dev.ge.o will migrate to new hardware soon, so expect a day or two of confusion [21:46:02] thats good to know :] [21:46:07] thanks patrick [21:46:33] ok i think we should get back on track with topic one :] [21:46:38] i think we are ready on this (btw i'm writing summary as soon as we speak) [21:46:55] so we dont jump over those carefully written numbered topics in chaotic order :] [21:47:08] ok back to topic one: new leader elections [21:47:26] candidates: jmbsvicetto, scarabeus, plz vote (devs only) [21:47:28] bring it on! [21:47:48] I vote yes ;) [21:47:52] DrEeevil: you cant [21:47:53] pick [21:47:55] i vote scarabeus (sorry jorge :) ) [21:48:11] DrEeevil: :P [21:48:12] I'd like to hear manifesto from both! ;) [21:48:17] * reavertm runs [21:48:22] lol [21:48:23] tampakrap: no hurt feelings ;) [21:48:45] not to break kde and keep it working for everyone of us :] and provide my qa tools for kde [21:48:49] i vote for scarabeus =) [21:48:53] scarabeus: nothing prevents us from having more than one lead, but let people choose [21:48:58] note that this manifesto wont change for me if not voted for :] [21:49:03] hmm [21:49:09] what qa tools? [21:49:11] or lets have two leads [21:49:12] =) [21:49:20] if its possible [21:49:22] i have quite few scripts that checks x11 state [21:49:25] i like that idea too [21:49:26] no, just one to rule them all :) [21:49:32] and i can adjust it for kde [21:49:38] no, one leader is enough [21:49:39] which i plan for month or so already :D [21:49:42] we are a large herd [21:50:00] actualy multiple leads are weird, just pick guys [21:50:08] it does not matter to jorge or me who wins :] [21:50:16] we just comply to the 1 year election rule :] [21:50:21] how many members with voting power are here? [21:50:33] lets vote and find out [21:50:34] ;p [21:50:39] 9 [21:50:56] sorry 10 [21:51:12] what about 5:5 ? [21:51:22] reavertm: that would not amuse me [21:51:36] ok, let's hear it [21:51:47] in case 5:5 i'll change my vote :P [21:51:47] * ABCD votes scarabeus [21:51:55] * reavertm votes scarabeus [21:51:56] * alexxy votes scarabeus [21:52:03] scarabeus: I'll break the tie ;) [21:52:03] * tampakrap votes scarabeus [21:52:11] * wired votes scarabeus [21:52:14] * spatz votes scarabeus [21:52:15] * jmbsvicetto votes in scarabeus [21:52:20] lol [21:52:23] ok ok ok [21:52:23] nice [21:52:25] i get it [21:52:38] like it or not you're lead [21:52:38] :p [21:52:39] * scarabeus votes for jmbsvicetto :] [21:52:39] congrats now abuse your powah :P [21:52:40] I said before I would prefer to have someone else being lead ;) [21:52:47] scarabeus: No!!!! :P [21:52:48] * wired remembered [21:53:04] Congratulations Tomas [21:53:13] scarabeus: \o/ congrats :) [21:53:22] Now everyone i guess we should drink something good in favor of our good benevolent now-ex lead. So on Jorge :] [21:53:38] and thanks, lets i will try to not doom us all :] [21:53:59] * wired has a beer open =] [21:54:05] * scarabeus too [21:55:02] ok little girls you played enough for today, now let's move on [21:55:15] Review work flow for KDE minor bumps and improve collaboration with arch teams [21:55:48] 1) BUG [21:55:48] 2) keywordlist [21:55:48] 3) portage addition [21:55:48] 4) profiles touching [21:56:00] this should be workflow from now-on so we dont touch anyones toes [21:56:13] scarabeus: The Founder Power has been bestowed on you for #gentoo-kde ;) [21:56:22] * ssuominen votes scarabeus [21:56:28]

abcd * gentoo/xml/htdocs/proj/en/desktop/kde/index.xml: We have a new lead! [21:56:36] :P [21:56:57] ssuominen: ha ha ha :D [21:57:10] all cards have been played already ;) [21:57:15] scarabeus: I propose something different [21:57:31] jmbsvicetto: i just wrote this one after start with jer, and then i got distracted [21:57:38] jmbsvicetto: how does your approach look? [21:57:43] if its better just make it policy [21:57:44] :] [21:58:01] its once per 6 months, and it wont hurt to have written down somewhere in Documentation/ [21:58:14] good idea, whatever we decide on this should be forwarded as a global policy [21:58:23] scarabeus: 1) Ask arch teams to test new deps in the overlay. 2) If they don't want to use the overlay, try to add a snapshot or a early release masked in the tree and ask them to keyword it [21:58:35] scarabeus: then your policy [21:59:06] i don't like this approach [21:59:18] well, your 3) would be done before, so it could be 3) unmask in the tree [21:59:18] what if they do something stupid while using the overlay? [21:59:56] tampakrap: I might not have been clear, I meant to let them try the ebuilds from there and for us to add their keyword [22:00:07] tampakrap: I'm not giving commit access [22:00:07] jmbsvicetto: sounds sane [22:00:18] altho i dont think about that snapshot into main tree [22:00:20] i was not clear [22:00:26] deps can go if released [22:00:28] but not the kde [22:00:33] I don't like snapshots in tree either [22:00:33] it is annoying 280 packages [22:00:38] i meant what if they use other testing ebuilds while using the overlay? [22:00:42] its 4 hours commit [22:00:47] (even if those are kde deps just) [22:00:58] scarabeus: The snapshot as a last resort if upstream doesn't have a release 2 weeks / 1 month before getting the new version in the tree [22:01:27] but only for deps [22:01:32] no touching of kde-base/ itself [22:01:35] I'm only talking about new deps [22:01:35] there is problem - we have no arch team members in kde team [22:01:40] we have [22:01:42] for amd [22:01:43] :D [22:01:48] only ssuominen, but we would need some for other archs [22:01:58] me stable for amd64 from time to time [22:02:00] i can keyword arm and mips [22:02:01] =) [22:02:09] scarabeus: It's 30 minutes if you commit at category level. [22:02:38] Philantrop: i know, but i managed to clash 3x already with someone else :] [22:02:42] if you commit in 10 threads then it takes about 5 minutes [22:02:45] even when i announced it :D [22:02:46] to commit whole kde [22:02:54] and since keywording kde is quite a bottleneck .. kde dev (which clearly uses kde) could do it faster [22:02:56] hmm i could thread bump tool indeed [22:03:13] scarabeus: force commit and kick anyone interfering from the herd. That's what I did. :-> [22:03:30] scarabeus: i added kde 4.4.0 in about 5-7 minutes to tree [22:03:35] * ABCD is x86-linux and amd64-linux [22:03:38] working with 10 threds [22:03:48] *threads [22:04:05] ok lets write out the rules on the Documentation [22:04:09] and i will thread the bumptool [22:04:11] its quite simple [22:04:44] <- not a part of amd64, just have stable chroot for xfce/kde/xorg/base-system/media [22:05:05] i also stable only when i have long night :D [22:05:19] but people mostly dont complain if qa guys stable on archs they can test :] [22:05:53] i would say this topic should be reviewed on next meeting with respective prepared documentation for approach in the overlay, anyone some additions? [22:06:33] no problem in this, i just hope there will be something prepared until next meeting [22:06:59] ok kde-4.3.5 then :] [22:07:01] i think we can use lxc containers instead of chroots [22:08:03] so we are waiting on archies only, are there any issues with it? [22:08:35] what's advantage of lxc over chroot? [22:08:49] (which I can boot to natively as well) [22:08:58] it run separate system in separate namespace [22:09:10] so its more closer to vms [22:10:28] VM's [22:10:29] =) [22:10:38] ok back to topic [22:10:46] so we are waiting on archies only, are there any issues with it? [22:11:25] anyone? [22:11:35] not that I've seen, as an archie :D [22:11:55] ok next one [22:12:03] *** Joins: aboow (house5@gateway/shell/bshellz.net/x-vhnffmhwlxzbhinj) [22:12:05] tampakrap: won't be really online until in about 1 hour [22:12:06] sitting in the train currently with shaky net [22:12:24] just one addition, dont remove 4.3.4, just wipe out 4.3.3 and 4.3.4 in one step when 4.3.5 is ready :] [22:12:34] if anyone gets remove ideas :P [22:12:35] Sput: ok we can talk then [22:12:51] kde 4.4 status [22:12:51] s/anyone/alexxy/ [22:12:59] * alexxy has remove idea of old kde's [22:13:00] :) [22:13:01] :D [22:13:15] referring to kdepim: if we found a way to package the current 4.4 kdepim in a way that it works with -9999 (no idea, copying the ebuilds from 4.4 into some overlay and renaming them to -9999) that should be more or less easy [22:13:21] as 4.4 kdepim is supposed to work with trunk kde [22:14:22] Sput: we can talk about it later, the other members have already expressed their opinions and you are messing with the topics now :) [22:14:34] back again to kde 4.4 [22:14:46] any known problems? blockers? [22:14:55] yeah it is slightly flaky [22:14:57] archies =) [22:15:02] i got few crashes in kwin and plasma [22:15:24] also, congrats scarabeus :) [22:15:25] few crashes in krunner and plasma [22:15:27] me too, so i guess 4.4.1 will be the stable candidate [22:15:30] also the virtuoso migration is not exactly funky working out of the box for some [22:15:36] 4.4.1 or 4.4.2 [22:15:41] 4.4.2 most likely [22:15:42] we shall see after 4.4.1 release [22:15:51] ok [22:15:51] i would rather wait too [22:15:58] judging from the past... [22:15:59] anything else on 4.4? [22:16:20] i guess not [22:16:32] jmbsvicetto: amarok and mysql 5.1 status [22:16:32] *** Joins: hwoarang (~mystical@gentoo/developer/hwoarang) [22:16:49] poor Jorge [22:17:03] oh wait, akonadi is indifferent... [22:17:26] virtuoso migration failed for me [22:17:31] amarok works with mysql 5.1 [22:17:33] ok [22:17:38] if it compiled with -FPIC [22:17:42] so, amarok and mysql-5.1 [22:18:01] Fortunately it's way better than I feared when I added it to the agenda [22:18:32] The ebuilds have been updated and no one complained for the past 3 days(?) so it seems users are getting used to it ;) [22:18:43] AIUI, amarok[-embedded] should work just fine - amarok[embedded] has the same problems with 5.1 that it did with 5.0 - namely, that we need a libmysqld.so again [22:18:50] A few people are still following the bug, but we can live with it as is [22:19:03] ABCD: exactly [22:19:52] there's another quirk, preserved-libs will keep the libmysqld.so for those upgrading, which does allow amarok to work (it happened here), until we have an abi / api incompatible change [22:20:32] that is for amarok to work with mysql-5.1 - but that might cause serious issues "sooner than later" [22:20:56] in any case, I've resumed my work to get a working patch, so let's see if I can do this before we have to elect a new lead ;) [22:21:31] :D [22:21:40] thank you x-boss [22:21:47] how about we stop supporting the embedded part :] [22:21:51] and just force full amarok [22:21:58] patch-- [22:21:58] ? [22:22:00] like akonadi does [22:22:01] ^^!! [22:22:08] let them have it! [22:22:20] that should teach those bastards :P [22:22:30] :D [22:22:38] ok anything else? serious? [22:22:42] ok lets go for koffice [22:22:47] i guess i should answer that one [22:22:59] problem with koffice is that expect graphic tools it is totaly unusable [22:23:00] * reavertm fixed kword recently [22:23:02] go on [22:23:11] and it needs all deps reviewed and updated based on cmakelists [22:23:36] i personaly use only krita and dont care about rest of the bunch so it needs some dedicated guy whom will actualy use the stuff [22:23:49] i will take this one but i may need your help [22:24:01] query still works :] [22:24:19] *** Quits: aboow (house5@gateway/shell/bshellz.net/x-vhnffmhwlxzbhinj) (Disconnected by services) [22:24:49] anything else? [22:24:57] nop, nothing from me to add [22:25:13] ok knetworkmanager [22:25:19] scarabeus: no harm in keeping embedded for now [22:25:25] jmbsvicetto: oky [22:25:33] ok we need snapshot [22:25:40] and monthly refreshed snapshot probably [22:25:43] scarabeus: if I can get a patch for mysql, we can make it simple again [22:25:45] knetworkmanager crashes plasma here, i didn't prepare a snapshot i just tested with live ebuild [22:25:46] who is willing to take that one out :] [22:25:59] tampakrap: well plasmoid can be disabled [22:26:07] tampakrap: most people are interested in kcm module [22:26:22] we need monthly refreshed snapshot from svn [22:26:23] i didn't use the plasmoid [22:26:31] only the system tray item [22:26:35] the same thing [22:26:39] sure [22:26:40] kcm is in systemsettings [22:26:45] tampakrap: is it working? [22:26:53] kcm wasn't working though :) [22:26:58] ok [22:27:03] so anyone uses NM these days [22:27:07] or are we all on wicd? [22:27:16] i guess i didn't have time to test it since it was crashing [22:27:43] i can prepare a snapshot but it will need a lot of testing and i'd prefer if someone with non-crashing results would do it [22:27:58] i'm on openrc init scripts and wpa_gui [22:28:18] *** Joins: jmrk_ (~jmrk@dslb-088-064-075-227.pools.arcor-ip.net) [22:28:19] tampakrap: ok just add it masked to main tree [22:28:25] and lets ask users for testing and feedback :] [22:28:29] anyone else? no? [22:28:50] good question, there is quite few more team members :P [22:28:55] who is willing to do this one? :] [22:29:36] ABCD / reavertm? [22:29:51] there is also DrEeevil whom enjoy the user feedback anyway :D [22:30:04] I don't use NM [22:30:19] tampakrap: i got it [22:30:22] tampakrap: coordinate with dagger [22:30:28] tampakrap: afterall he is maintainer of NM [22:30:34] ah yes [22:30:39] ok next topic [22:30:45] * reavertm does have static network [22:31:14] the documentation is fine, i updated it about a month ago, if you all want can take a look and propose fixes [22:31:19] two issues though: [22:31:32] 1) jmbsvicetto promised to clean up the member list [22:31:48] which will be probably my task now :/ [22:32:01] 2) i have an open bug about xdm configuration which i don't like, i'd like your feedback [22:32:09] i will sent mail to everyone who does not have 5 commits month into kde cat [22:32:13] scarabeus: I sorted it asciibetically for you (except your name is at the top) :D [22:32:34] ABCD: lovely, you earn the big plus point :P [22:32:50] http://bugs.gentoo.org/attachment.cgi?id=220755&action=view [22:33:08] scarabeus: also plz remove qt members they are still there [22:33:34] tampakrap: yeah [22:33:44] tampakrap: I'll talk to scarabeus about that [22:33:46] a small note: i didn't add the usefull links in the guide as jmbsvicetto pointed as they are not that useful :P [22:34:00] tampakrap: recommend dejavu and droid fonts for christ sake [22:34:26] tampakrap: other than that you should point to x11 guide which should describe xdm config iirc [22:34:39] cool [22:34:43] i like that [22:35:26] last point: i'm going to blog about kde3 removal and the kde-sunset existence, so that ppl will hopefully stop filling stupid kde3 bugs anymore [22:35:38] its only gnu_andrew [22:35:45] and he will fill them anyway just to annoy us [22:36:05] heh [22:36:07] i don't have to say anything else about the docs, just i am waiting for you to take a look plz [22:36:24] remove kdeprefix from docs [22:36:31] kde guide is way too red [22:36:45] funny, i agree on that [22:36:51] friendly 'notes' everywhere [22:37:10] it's impossible to follow [22:37:11] :D [22:37:22] yeah just wipe out kdeprefix from docs is good idea [22:37:34] about kde3 and kde-sunset, my opinion is that we did one thing wrong [22:37:49] also maybe sets... [22:37:56] my initial goal was never to make kde-sunset a "dumping ground" to be mastered by users alone [22:38:01] info about sets - remove as well? [22:38:14] reavertm: i think we can have a note about sets, but keep metas as the default option [22:38:27] nah sets are weird [22:38:31] they are bbd now [22:38:32] jmbsvicetto: i'm sure everyone knows that, but you can't force devs to work on it :) [22:38:39] jmbsvicetto: i'm still following the kde-sunset commits [22:38:43] I'd rather have an overlay with commits just by devs and trusted committers (akin to sunrise) and another overlay with free access by users [22:38:55] jmbsvicetto: well your idea assumes devs are interested [22:38:59] but now it's too late, so we'll have to live with it as is [22:38:59] jmbsvicetto: we have none of those [22:39:00] :p [22:39:15] * jmbsvicetto cries for sets [22:39:34] jmbsvicetto: not in this implementation, sorry [22:39:34] I know (devs and KDE3) [22:39:55] ok, i guess we are done [22:39:56] pretty much all gentoo devs have commit access to that overlay.. [22:40:48] the following two topics are long time ideas i had [22:40:54] drop prefixes from kde ebuilds (like kdeartwork etc) [22:40:59] I use NM with the plasmoid and both work great [22:41:01] trunk though. [22:41:22] if anyone dares to remove the plasmoid from -9999 I will keel him [22:41:23] :) [22:41:23] tampakrap: things like kdebase-data... you think it should just be "emerge data"?! [22:41:45] well no [22:41:48] drop prefixes? no [22:41:51] but for kdebase-startkde yes [22:41:56] add prefixes? more likely :P [22:41:58] or for the artwork ones [22:42:01] please no another dev-haskell/ [22:42:09] try emerge opengl or emerge x11 [22:42:20] startkde makes sense [22:42:20] or zlib for that matter [22:42:23]