Meeting logs migrated to git+ssh://git@git.gentoo.org/sites/projects/kde.git

56 files changed, 0 insertions, 18372 deletions

diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20071013.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20071013.txt
deleted file mode 100644
index 720381ebb0..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20071013.txt
+++ /dev/null
@@ -1,338 +0,0 @@
-[Sa Okt 13 2007] [20:00:44] Join	tgurr has joined this channel (n=tgurr@hbrn-590f7fff.pool.einsundeins.de).
-[Sa Okt 13 2007] [20:00:54] <Philantrop>	!herd kde
-[Sa Okt 13 2007] [20:00:57] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
-[Sa Okt 13 2007] [20:01:00] <genstef>	here?
-[Sa Okt 13 2007] [20:01:03] <keytoaster>	yes
-[Sa Okt 13 2007] [20:01:19] <cryos|laptop>	Is it 18:00 hours already?
-[Sa Okt 13 2007] [20:01:22] <keytoaster>	yes
-[Sa Okt 13 2007] [20:01:24] <Philantrop>	cryos|laptop: Yes. :-)
-[Sa Okt 13 2007] [20:01:33] <Philantrop>	At least in UTC. :-)
-[Sa Okt 13 2007] [20:01:34] <keytoaster>	20:00 in germany :)
-[Sa Okt 13 2007] [20:01:40] <Philantrop>	20:01!
-[Sa Okt 13 2007] [20:01:44] <cryos|laptop>	I make it 14:01.
-[Sa Okt 13 2007] [20:01:58] <Philantrop>	cryos|laptop: You're *way* behind! ;-)
-[Sa Okt 13 2007] [20:02:03] <tgurr>	hi all :)
-[Sa Okt 13 2007] [20:03:12] <Philantrop>	Any  objections against waiting for two or three more minutes? Deathwing00 told me he would be here. :-)
-[Sa Okt 13 2007] [20:03:43] <genstef>	yes
-[Sa Okt 13 2007] [20:03:49] 	 * cryos|laptop murmurs about German efficiency :D
-[Sa Okt 13 2007] [20:03:52] <genstef>	just start
-[Sa Okt 13 2007] [20:05:17] <Philantrop>	Ok, let's go then.
-[Sa Okt 13 2007] [20:05:47] <Philantrop>	1. Update to the project page - are we happy with it now that it's been updated? Any additions, etc?
-[Sa Okt 13 2007] [20:06:55] <keytoaster>	i'm happy with it :)
-[Sa Okt 13 2007] [20:07:03] <Philantrop>	We, jmbsvicetto, keytoaster and myself have added what we thought was appropriate and it seems we all agree on it, atm. :-)
-[Sa Okt 13 2007] [20:07:29] <Philantrop>	So that task from the last meeting is done. :-)
-[Sa Okt 13 2007] [20:07:50] <Philantrop>	2. Review of the project page is done, too, aunless anyone objects now. :-)
-[Sa Okt 13 2007] [20:08:11] <cryos|laptop>	Nope.
-[Sa Okt 13 2007] [20:08:34] <Philantrop>	3. Process improvement - NeddySeagoon can't make it today, it seems. 
-[Sa Okt 13 2007] [20:08:48] <Philantrop>	It doesn't seem as if much can be done about it anymore anyway...
-[Sa Okt 13 2007] [20:09:02] <keytoaster>	yup
-[Sa Okt 13 2007] [20:09:19] <Philantrop>	4. Miscellaneous - bump to KDE 3.5.8
-[Sa Okt 13 2007] [20:09:53] <Philantrop>	As I'Ve mailed to all of you, I've set up a git repository to collaborate on it. So far, jmbsvicetto, Ingmar^, tgurr and myself worked on it.
-[Sa Okt 13 2007] [20:10:12] <Philantrop>	I've gotten exactly zero feedback to my mail about it. :-)
-[Sa Okt 13 2007] [20:10:33] <cryos|laptop>	Are you manually bumping it? Sorry - I have been mostly offline these last few weeks/months.
-[Sa Okt 13 2007] [20:10:49] <keytoaster>	i couldn't answer because i'm currently not at home and running windows :(
-[Sa Okt 13 2007] [20:11:13] <Philantrop>	cryos|laptop: we've bumped the monolithic ebuilds manually, yes. The splits were initially done by the script and are now being combed through manually.
-[Sa Okt 13 2007] [20:11:47] <cryos|laptop>	Philantrop: OK - sounds good. We always used to just mask and bump - why the git repo now if I may ask?
-[Sa Okt 13 2007] [20:12:20] <Philantrop>	cryos|laptop: The last bump was critisized by many as rushed and bad. I wanted to avoid that this time. :)
-[Sa Okt 13 2007] [20:12:26] <cryos|laptop>	Masking allowed us to get the arch teams on board and give them access to the tarballs before release via dev.gentoo.org and gentoo-core.
-[Sa Okt 13 2007] [20:12:44] <cryos|laptop>	Then we could just unmask after the official release.
-[Sa Okt 13 2007] [20:12:46] <Philantrop>	cryos|laptop: Furthermore, like this, interested users like Ingmar^ could help, too.
-[Sa Okt 13 2007] [20:13:01] <Philantrop>	cryos|laptop: And, of course, we'll put them into the tree and package.mask soon. :-)
-[Sa Okt 13 2007] [20:13:26] <genstef>	Philantrop: thanks for your mail, was very good :)
-[Sa Okt 13 2007] [20:13:34] <genstef>	Philantrop: is there a release date scheduled yet?
-[Sa Okt 13 2007] [20:13:41] <cryos|laptop>	Just seems to be making the process more hassle for arch teams to get involved with and interested users can send patches. I have been away so I am mainly asking.
-[Sa Okt 13 2007] [20:13:50] <Philantrop>	genstef: Yes, it's to be released on the 16th. :-)
-[Sa Okt 13 2007] [20:14:36] <Philantrop>	cryos|laptop: Well, yes, they could but why not combine both? We can still do the p.mask/tarball stuff (like tomorrow :-) ) *and* let others help directly.
-[Sa Okt 13 2007] [20:14:46] <cryos|laptop>	I always worry about the trend towards overlays and separate repos making it harder to see and track stuff.
-[Sa Okt 13 2007] [20:14:58] <cryos|laptop>	Just my opinion though - I know others like it.
-[Sa Okt 13 2007] [20:15:24] <Philantrop>	cryos|laptop: My main point is: People like Ingmar^ are very, very good dev "material" and training them on the job helps, IMHO.
-[Sa Okt 13 2007] [20:15:29] <genstef>	cryos|laptop: right, but this stuff isnot meant to be public by upstream
-[Sa Okt 13 2007] [20:15:31] <cryos|laptop>	I have very little right to criticise anything due to my recent inactivity anyway.
-[Sa Okt 13 2007] [20:16:01] <Philantrop>	cryos|laptop: No, that's wrong. You have *all* the right to critisize. I'd just like to *convince* you. :-)
-[Sa Okt 13 2007] [20:16:15] 	 * cryos|laptop will be quiet - I can see the reasoning.
-[Sa Okt 13 2007] [20:16:45] <genstef>	well, but cryos is right. Last time the mail went to gentoo-core and every dev was able to test iirc
-[Sa Okt 13 2007] [20:17:19] <Philantrop>	Anyway, I intend to put the stuff into the tree by tomorow (in p.mask) and inform -core. :-)
-[Sa Okt 13 2007] [20:17:25] <Philantrop>	Any objections?
-[Sa Okt 13 2007] [20:17:37] <genstef>	Philantrop: right, sounds cool! Enough time for the arch teams to test then :)
-[Sa Okt 13 2007] [20:17:54] <Philantrop>	genstef: Yes, I hope so. 
-[Sa Okt 13 2007] [20:18:10] <Philantrop>	I don't think, though, we'll make it to 2007.1 or do you think we can/should?
-[Sa Okt 13 2007] [20:18:25] <Philantrop>	Into stable, I mean.
-[Sa Okt 13 2007] [20:18:34] <cryos|laptop>	When is the snapshot date?
-[Sa Okt 13 2007] [20:18:37] 	 * genstef does not care about releases
-[Sa Okt 13 2007] [20:18:48] <genstef>	everyone runs emerge --sync anyways ..
-[Sa Okt 13 2007] [20:18:58] <Philantrop>	xxxxxxxxxxxx - Initial snapshot
-[Sa Okt 13 2007] [20:18:58] <Philantrop>	xxxxxxxxxxxx - Final snapshot
-[Sa Okt 13 2007] [20:18:58] <Philantrop>	xxxxxxxxxxxx - Release
-[Sa Okt 13 2007] [20:19:21] <genstef>	well, imo stable the earlier the better
-[Sa Okt 13 2007] [20:19:25] <Philantrop>	cryos|laptop: ^^^
-[Sa Okt 13 2007] [20:19:34] <cryos|laptop>	It would be silly to try and make those dates, but I totally agree with genstef.
-[Sa Okt 13 2007] [20:19:40] <cryos|laptop>	Stable the earlier the better.
-[Sa Okt 13 2007] [20:20:03] <genstef>	but 19th will not happen I think
-[Sa Okt 13 2007] [20:20:04] <Philantrop>	genstef: Yes, same here. I just wouldn't want to tell the release guys now we'll make it and possibly delay them if we don't. Opinions?
-[Sa Okt 13 2007] [20:20:11] <keytoaster>	sorry, we are having dinner now, i'll read the conversation when i'm back
-[Sa Okt 13 2007] [20:20:17] <genstef>	ok
-[Sa Okt 13 2007] [20:20:36] <genstef>	Philantrop: so we will not make it
-[Sa Okt 13 2007] [20:20:50] <cryos|laptop>	Philantrop: I wouldn't tell them we would make it - the 9th is too tight a schedule really.
-[Sa Okt 13 2007] [20:21:25] <cryos|laptop>	In some ways it is a shame - would be good to have 3.5.8 GRPed.
-[Sa Okt 13 2007] [20:21:33] <Philantrop>	Ok, let's say we can *try* but if we don't, the world will not stop spinning. I will *not* inform the release guys about us making it in time.
-[Sa Okt 13 2007] [20:21:53] <tgurr>	sounds good to me
-[Sa Okt 13 2007] [20:21:58] <jmbsvicetto>	I'm home
-[Sa Okt 13 2007] [20:22:02] <jmbsvicetto>	Sorry for the delay
-[Sa Okt 13 2007] [20:22:06] <Philantrop>	jmbsvicetto: Welcome back! :-)
-[Sa Okt 13 2007] [20:22:28] <Philantrop>	Ok, next point: "Changing to split ebuilds by default? That would mean going through all KDE ebuilds and changing the dependency order."
-[Sa Okt 13 2007] [20:22:47] 	 * genstef is against it.
-[Sa Okt 13 2007] [20:22:56] 	 * Philantrop is against it, too.
-[Sa Okt 13 2007] [20:23:05] <genstef>	But if you must for 4.0, you can
-[Sa Okt 13 2007] [20:23:27] <Philantrop>	I don't see the need but maybe there are other opinions?
-[Sa Okt 13 2007] [20:23:34] <cryos|laptop>	I would rather see us do it for 4.0 and leave 3.5 well enough alone.
-[Sa Okt 13 2007] [20:24:10] <jakub>	yeah, not for 3.x
-[Sa Okt 13 2007] [20:24:12] <cryos|laptop>	The apache herd screw around lots inside minor releases and it hasn't made them very popular...
-[Sa Okt 13 2007] [20:24:21] <Philantrop>	cryos|laptop: That sounds like a good idea. genstef, what do you think?
-[Sa Okt 13 2007] [20:24:31] <cryos|laptop>	May be not lots, but when they have it has been painful at times.
-[Sa Okt 13 2007] [20:24:33] <jakub>	and better kill monolithic stuff for 4.0 altogether
-[Sa Okt 13 2007] [20:24:42] <Philantrop>	jakub: That's one more point later. :-)
-[Sa Okt 13 2007] [20:24:43] <genstef>	jakub: sounds good
-[Sa Okt 13 2007] [20:25:04] <jakub>	Philantrop: well, just a suggestion... :)
-[Sa Okt 13 2007] [20:25:15] 	 * cryos|laptop adds a here, here.
-[Sa Okt 13 2007] [20:25:22] <jakub>	but yeah, messing with the (last?) 3.5.x release in this way will piss off users
-[Sa Okt 13 2007] [20:25:36] <Philantrop>	So, we keep the current dep order for now but change it to split as default for >=4.0?
-[Sa Okt 13 2007] [20:26:05] <genstef>	Philantrop: right, because split definitely has advantages, with many patches coming in
-[Sa Okt 13 2007] [20:26:19] <jmbsvicetto>	I would like to see us go to split by default
-[Sa Okt 13 2007] [20:26:21] <genstef>	Philantrop: and 4.0 I expect to get many bugreports+patches early :)
-[Sa Okt 13 2007] [20:26:23] <Philantrop>	genstef: Indeed. :-)
-[Sa Okt 13 2007] [20:26:34] <jakub>	Philantrop: as said, you really want to keep monolithic stuff for 4.0?
-[Sa Okt 13 2007] [20:26:41] <jakub>	sounds just like maintenance overhead to me
-[Sa Okt 13 2007] [20:26:49] <genstef>	jakub: hey, leave the lead to Philantrop!
-[Sa Okt 13 2007] [20:27:01] <Philantrop>	genstef: We already get them for the 4.0 overlays. Which leads us to the next point: KDE4 in the overlays. :-)
-[Sa Okt 13 2007] [20:27:07] <jakub>	genstef: hey, gimme a beer! :P
-[Sa Okt 13 2007] [20:27:17] <jmbsvicetto>	I can live with split for >= 4.0, though
-[Sa Okt 13 2007] [20:27:26] <Philantrop>	jmbsvicetto: Ok, that's decided then. :-)
-[Sa Okt 13 2007] [20:27:30] 	 * genstef paurs some beer into the wire to jakub's glass
-[Sa Okt 13 2007] [20:27:44] <jakub>	anyway, the point - users are horrible confused by the blockers b/w monolithic/split, they've never grokked it
-[Sa Okt 13 2007] [20:27:52] <jakub>	and really makes the eclasses/ebuilds a mess
-[Sa Okt 13 2007] [20:28:08] <Philantrop>	KDE4 in the overlay is doing well. People are reporting bugs, installing it and using it. We currently have both monolithic and split ebuilds.
-[Sa Okt 13 2007] [20:28:40] <genstef>	and you have a special project and channel for it :)
-[Sa Okt 13 2007] [20:28:42] <jmbsvicetto>	jakub: I got a block earlier because I tried to emerge kdesdk-3.5.8 and kdevelop-3.5
-[Sa Okt 13 2007] [20:28:46] <Philantrop>	Personally, I'd like to keep the monolithic ebuilds. We usually follow upstream and we give our users the freedom of choice. :-)
-[Sa Okt 13 2007] [20:28:54] <jakub>	Philantrop: if you could make zmedico into sticking ranged deps into EAPI-1 by the KDE4 release time, that'd be awesome :P
-[Sa Okt 13 2007] [20:28:58] <jmbsvicetto>	jakub: We should really have a way to prevent that
-[Sa Okt 13 2007] [20:29:23] <jmbsvicetto>	jakub: We need ranges and sets
-[Sa Okt 13 2007] [20:29:48] <jakub>	jmbsvicetto: well, for sets, you can workaround in a semi-reasonable way by the metabuilds...
-[Sa Okt 13 2007] [20:29:52] <jmbsvicetto>	jakub: That would allow us to drop the meta / meta use flags
-[Sa Okt 13 2007] [20:29:54] <jakub>	for ranged deps, the hacks are insane :/
-[Sa Okt 13 2007] [20:30:23] <Philantrop>	Let's assume for now that we won't get ranged deps/real sets in time for 4.0. :-)
-[Sa Okt 13 2007] [20:30:46] <jakub>	Philantrop: gah, torture Zac to do it! :>
-[Sa Okt 13 2007] [20:31:25] <jmbsvicetto>	hehe
-[Sa Okt 13 2007] [20:31:27] <Philantrop>	jakub: :-)) I can't. I only torture soon-to-be devs. Not grizzled veterans. ;-)
-[Sa Okt 13 2007] [20:31:34] <jmbsvicetto>	jakub: I thought your preferred method involved beer ;)
-[Sa Okt 13 2007] [20:31:51] <jmbsvicetto>	jakub: even kegs of beer
-[Sa Okt 13 2007] [20:32:01] <jakub>	jmbsvicetto: heh, if that fails, you need something more... effective :D
-[Sa Okt 13 2007] [20:32:31] <Philantrop>	Guys, KDE4 and monolithic ebuilds - to keep them or not to keep them. That's the question. What's your answer? Mine is: Keep them. :-)
-[Sa Okt 13 2007] [20:32:56] <Philantrop>	!herd kde
-[Sa Okt 13 2007] [20:33:00] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
-[Sa Okt 13 2007] [20:33:11] 	 * genstef did not write those
-[Sa Okt 13 2007] [20:33:23] <genstef>	so I just go with philantrop on that matter :)
-[Sa Okt 13 2007] [20:33:38] <jmbsvicetto>	Philantrop: As long as we can start the work for split from the meta, we might as well keep them
-[Sa Okt 13 2007] [20:33:44] <tgurr>	but the splits should be default by then
-[Sa Okt 13 2007] [20:33:53] <Philantrop>	tgurr: Agreed.
-[Sa Okt 13 2007] [20:33:53] <jmbsvicetto>	tgurr++
-[Sa Okt 13 2007] [20:34:23] <jakub>	shrug; you're going to maintain the stuff :P
-[Sa Okt 13 2007] [20:34:36] <Philantrop>	Three times "yes" so far: Philantrop, genstef, tgurr (splits will be default). cryos|laptop?
-[Sa Okt 13 2007] [20:34:49] <genstef>	like: kdebase and kdebase-mon? ;) instead of kdebase-meta?
-[Sa Okt 13 2007] [20:35:23] <cryos|laptop>	I would get rid, but don't object that much to keeping.
-[Sa Okt 13 2007] [20:35:24] <jakub>	-mon? :)
-[Sa Okt 13 2007] [20:35:25] <jmbsvicetto>	kdebase is going to be split in two, right?
-[Sa Okt 13 2007] [20:35:31] <cryos|laptop>	So I vote no.
-[Sa Okt 13 2007] [20:35:37] <jmbsvicetto>	kdebase and kdebase-plasma(?)
-[Sa Okt 13 2007] [20:35:59] <Philantrop>	masterdriverz: Any thoughts? :)
-[Sa Okt 13 2007] [20:36:13] <Philantrop>	cryos|laptop: Thanks, noted. :-)
-[Sa Okt 13 2007] [20:37:05] <Philantrop>	Ok, so it's 3:1 for keeping the monolithic ebuilds for KDE4. 
-[Sa Okt 13 2007] [20:37:17] <Philantrop>	Anything else on KDE4?
-[Sa Okt 13 2007] [20:37:37] <Sho_>	jmbsvicetto: From our side we have runtime, workspace and apps in kdebase
-[Sa Okt 13 2007] [20:37:43] 	 * jakub still offers a keg for getting sets and ranged deps in b4 KDE4 :D
-[Sa Okt 13 2007] [20:37:51] <jmbsvicetto>	Sho_: sorry, that's it - kdebase and kdebase-workspace
-[Sa Okt 13 2007] [20:38:28] <jmbsvicetto>	Sho_: That's what Ingmar^ said, iirc
-[Sa Okt 13 2007] [20:38:47] <jakub>	jmbsvicetto: ^^ ding ding - motivation above! :)
-[Sa Okt 13 2007] [20:38:54] <Philantrop>	jmbsvicetto: Ingmar^ is a great fan of splitting. He might do even more. :-)
-[Sa Okt 13 2007] [20:38:57] <jmbsvicetto>	:)
-[Sa Okt 13 2007] [20:38:57] <jakub>	anyway, /me out for a couple of plops, have fun guys :)
-[Sa Okt 13 2007] [20:39:14] Quit	tibix_ has left this server (Read error: 110 (Connection timed out)).
-[Sa Okt 13 2007] [20:39:17] <Philantrop>	Ok, the point for KDE4 should be done then. :-)
-[Sa Okt 13 2007] [20:39:46] Join	tibix_ has joined this channel (n=tibix@host86.200-45-178.telecom.net.ar).
-[Sa Okt 13 2007] [20:39:48] <Philantrop>	Next point: I'm going to document the procedure of bumping to the minor KDE revisions. Any help is welcome. I'll present a draft soon.
-[Sa Okt 13 2007] [20:40:05] <jmbsvicetto>	jakub: If we need you, we'll send you a *SIGBEER* ;)
-[Sa Okt 13 2007] [20:40:58] <Philantrop>	Anything I should take special care of when documenting possible bump procedures?
-[Sa Okt 13 2007] [20:42:01] <Philantrop>	Ok, obviously not. :-)
-[Sa Okt 13 2007] [20:42:11] <jmbsvicetto>	Philantrop: Sorry, but since you're talking about documentation, most people are likely to need some kde4 crash course - in particular to cmake
-[Sa Okt 13 2007] [20:42:29] <jmbsvicetto>	s/most/some/
-[Sa Okt 13 2007] [20:42:31] <jakub>	jmbsvicetto: ok, sounds like a deal :)
-[Sa Okt 13 2007] [20:42:56] <Philantrop>	jmbsvicetto: :-) Well, yes, but there's not much we can do about it, I think. Self-education should be most effective unless you have a better suggestion. :)
-[Sa Okt 13 2007] [20:43:40] <Philantrop>	jmbsvicetto: Unless you want to install a "re-education camp". ;)
-[Sa Okt 13 2007] [20:43:46] <jmbsvicetto>	hehe
-[Sa Okt 13 2007] [20:44:13] <jakub>	hmmm, camp... steaks... _beer_
-[Sa Okt 13 2007] [20:44:19] <jakub>	Philantrop++
-[Sa Okt 13 2007] [20:44:21] <jmbsvicetto>	Well, I guess I'll need to reeducate myself, since I haven't seen kde4 in a while ;)
-[Sa Okt 13 2007] [20:44:31] <Philantrop>	jmbsvicetto: I'll add this to the summary, though. Maybe someone has an idea or helpful link. :-)
-[Sa Okt 13 2007] [20:44:52] <Philantrop>	jakub: I thought more along the lines of a prison camp. ;-)
-[Sa Okt 13 2007] [20:44:59] <genstef>	Philantrop: it would be cool to explain why it is best to have the non-working ebuilds in the git to allow external help and afterwards in gentoo-x86 to allow internal testing :)
-[Sa Okt 13 2007] [20:45:32] <jmbsvicetto>	genstef: It doesn't have to be git, just an overlay
-[Sa Okt 13 2007] [20:45:46] <genstef>	jmbsvicetto: right
-[Sa Okt 13 2007] [20:45:46] <jmbsvicetto>	genstef: But git is good a choice
-[Sa Okt 13 2007] [20:46:10] <genstef>	git would be cool for the portage tree imo. Just pull from external contributors :)
-[Sa Okt 13 2007] [20:46:16] <jakub>	well, * >> cvs :)
-[Sa Okt 13 2007] [20:46:36] <jmbsvicetto>	genstef: You know how the cvs/svn/git/* debate ended last time ;)
-[Sa Okt 13 2007] [20:46:48] <Philantrop>	genstef: We don't *have* to do it in a git repository for all times. This was just one approach. :-)
-[Sa Okt 13 2007] [20:47:07] <jakub>	jmbsvicetto: well yeah, it's not gonna get anywhere...
-[Sa Okt 13 2007] [20:47:11] <genstef>	jmbsvicetto: ok, better not discuss it then ;)
-[Sa Okt 13 2007] [20:47:20] <jakub>	jmbsvicetto: we'll be stuck w/ cvs until we switch infra first
-[Sa Okt 13 2007] [20:47:53] <jmbsvicetto>	jakub: I wouldn't say that. I think robbat2 is close to accept git
-[Sa Okt 13 2007] [20:48:06] <Philantrop>	!herd kde
-[Sa Okt 13 2007] [20:48:09] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
-[Sa Okt 13 2007] [20:48:09] <genstef>	switch infra!
-[Sa Okt 13 2007] [20:48:10] <Philantrop>	Anything else we should discuss? :-)
-[Sa Okt 13 2007] [20:48:11] <jmbsvicetto>	jakub: He has worked on it to supress the shortcommings
-[Sa Okt 13 2007] [20:48:16] 	 * jakub really out now... oh btw, getting the new eclasses eclass-manpages friendly would be nice :)
-[Sa Okt 13 2007] [20:48:26] <Philantrop>	jakub: Yes, that's in the making. :-)
-[Sa Okt 13 2007] [20:48:48] <jakub>	Philantrop: if you want help, poke me ;)
-[Sa Okt 13 2007] [20:48:55] <jmbsvicetto>	Philantrop: What about the cmake eclass?
-[Sa Okt 13 2007] [20:49:00] <Philantrop>	jakub: Thanks, I surely will! :-)
-[Sa Okt 13 2007] [20:49:26] <Philantrop>	jmbsvicetto: We have one more showstopper in it: cmake-utils-src_test. We need to work on that before I re-submit it.
-[Sa Okt 13 2007] [20:49:26] <jmbsvicetto>	Philantrop: Has it been merged to Portage or is it still on the overlay?
-[Sa Okt 13 2007] [20:49:36] <Philantrop>	jmbsvicetto: It's still in the overlay only.
-[Sa Okt 13 2007] [20:49:37] <jmbsvicetto>	Philantrop: Oh and one final issue - ATs/HTs!
-[Sa Okt 13 2007] [20:49:43] <genstef>	waah, cmake.eclass is not yet in the tree?
-[Sa Okt 13 2007] [20:49:56] <genstef>	urrx, should be imo
-[Sa Okt 13 2007] [20:50:12] <Philantrop>	genstef: Unfortunately, no. People had lots of suggestions. We've done most of it but that one remains.
-[Sa Okt 13 2007] [20:50:28] <Philantrop>	genstef: I'm going to try to get it in next week, though.
-[Sa Okt 13 2007] [20:51:45] <shade>	jmbsvicetto: ping
-[Sa Okt 13 2007] [20:51:55] <Philantrop>	The problem is: cmake-utils' src_test is mostly a copy of the one in ebuild.sh but we currently need it to check whether it's an in-source or out-of-source build.
-[Sa Okt 13 2007] [20:52:05] <Philantrop>	Any help on this would be greatly appreciated.
-[Sa Okt 13 2007] [20:52:37] <Philantrop>	jmbsvicetto: "ATs/HTs". What's your suggestion about them?
-[Sa Okt 13 2007] [20:52:51] <jmbsvicetto>	Well, glep41 http://www.gentoo.org/proj/en/glep/glep-0041.html created ATs and HTs
-[Sa Okt 13 2007] [20:53:01] <shade>	jmbsvicetto: so, config ata is sompiled into the kernel, same as config ide
-[Sa Okt 13 2007] [20:53:03] <jmbsvicetto>	I think kde would benefit from having a HT team
-[Sa Okt 13 2007] [20:53:10] <Philantrop>	jmbsvicetto: Yes, but it has been rejected by the council in its current state. :)
-[Sa Okt 13 2007] [20:53:19] <jmbsvicetto>	shade: We're in the middle of a meeting. Give us a few minutes, ok? Thanks
-[Sa Okt 13 2007] [20:53:34] <jmbsvicetto>	Philantrop: Not rejected. It hasn't been implemented
-[Sa Okt 13 2007] [20:53:36] <shade>	jmbsvicetto: ok, np:)
-[Sa Okt 13 2007] [20:53:51] <jmbsvicetto>	Philantrop: And ATs get official recognition
-[Sa Okt 13 2007] [20:53:55] <Philantrop>	jmbsvicetto: I thought so, too. Look at the relevant meeting's log, though. :)
-[Sa Okt 13 2007] [20:54:21] <jmbsvicetto>	Philantrop: What hasn't been accepted is the @g.o email addresses. Everything else was accepted
-[Sa Okt 13 2007] [20:54:32] <jmbsvicetto>	Philantrop: So, can I be a kde ht?
-[Sa Okt 13 2007] [20:54:40] <cryos|laptop>	We use HTs in the sci herd quite successfully.
-[Sa Okt 13 2007] [20:54:42] <Philantrop>	jmbsvicetto: There's nothing to say against Herd Testers, though. :-)
-[Sa Okt 13 2007] [20:54:57] <jmbsvicetto>	Philantrop: Pretty, pretty please?
-[Sa Okt 13 2007] [20:55:04] <jmbsvicetto>	;)
-[Sa Okt 13 2007] [20:55:05] <Philantrop>	cryos|laptop: Oh? That's good to know. Never heard about them before. :)
-[Sa Okt 13 2007] [20:55:05] <cryos|laptop>	I got them boosted bugzilla powers and access the overlay.
-[Sa Okt 13 2007] [20:55:23] <cryos|laptop>	Philantrop: Quite a few went on to become devs later too.
-[Sa Okt 13 2007] [20:55:32] <Philantrop>	cryos|laptop: How's the procedure to make them HTs?
-[Sa Okt 13 2007] [20:55:55] <cryos|laptop>	I think I was supposed to make a web page about this stuff.
-[Sa Okt 13 2007] [20:56:01] <Philantrop>	cryos|laptop: :-))
-[Sa Okt 13 2007] [20:56:05] <jmbsvicetto>	Philantrop: Anyway, "personally" I won't gain anything I don't have yet, with the exception of showing up in the kde team page. But other people could get official recognition
-[Sa Okt 13 2007] [20:56:27] <Philantrop>	jmbsvicetto: Well, there's precedent, it seems and it makes sense...
-[Sa Okt 13 2007] [20:56:31] <cryos|laptop>	I just used to talk to someone who I have forgotten now who was in charge of the AT project about getting bugzie sorted.
-[Sa Okt 13 2007] [20:56:34] <genstef>	yeah, I like the idea
-[Sa Okt 13 2007] [20:56:41] <jmbsvicetto>	cryos|laptop: hparker ;)
-[Sa Okt 13 2007] [20:56:43] <Philantrop>	cryos|laptop: That would be hparker. 
-[Sa Okt 13 2007] [20:56:48] <cryos|laptop>	Yes jmbsvicetto!
-[Sa Okt 13 2007] [20:56:54] <genstef>	cryos|laptop: hparker
-[Sa Okt 13 2007] [20:56:57] <cryos|laptop>	It has been a while :)
-[Sa Okt 13 2007] [20:57:08] <Philantrop>	So, do we want Herd Testers? I support the idea. Others?
-[Sa Okt 13 2007] [20:57:20] <cryos|laptop>	I think it works well and would support the idea.
-[Sa Okt 13 2007] [20:57:35] <jmbsvicetto>	cryos|laptop: s/would/will/ !!! ;)
-[Sa Okt 13 2007] [20:57:57] <Philantrop>	masterdriverz, tgurr: Your vote?
-[Sa Okt 13 2007] [20:58:04] <tgurr>	sure :)
-[Sa Okt 13 2007] [20:58:08] <cryos|laptop>	It is a great chance for people to get a bit of a taste of being a dev and decide if it is for them. Some only ever want the HT position and others drift away again,.
-[Sa Okt 13 2007] [20:58:43] <cryos|laptop>	Means when people go on to become devs they are usually more certain about actually wanting to do it too.
-[Sa Okt 13 2007] [20:58:56] <Philantrop>	Ok, so we have four "yes" (genstef, cryos|laptop, tgurr, Philantrop) and no objections. :-)
-[Sa Okt 13 2007] [20:59:04] <Philantrop>	cryos|laptop: Yes, sounds really good to me. :-)
-[Sa Okt 13 2007] [20:59:21] <Philantrop>	I'll talk to hparker about it.
-[Sa Okt 13 2007] [20:59:24] <genstef>	so we need some amendment to the project page about that, right?
-[Sa Okt 13 2007] [20:59:39] <Philantrop>	genstef: Yes, thanks for volunteering! ;)
-[Sa Okt 13 2007] [20:59:45] <genstef>	including the procedure of how a herd member goes about promoting someone to HT :)
-[Sa Okt 13 2007] [20:59:50] <genstef>	ok :)
-[Sa Okt 13 2007] [20:59:58] <jmbsvicetto>	genstef: You would add a section listing the HT members and some documentation on how to become one
-[Sa Okt 13 2007] [21:00:06] <genstef>	right
-[Sa Okt 13 2007] [21:00:29] <Philantrop>	genstef: So you'd be willing to make a draft for that? Maybe for the next meeting (or earlier)? :)
-[Sa Okt 13 2007] [21:00:30] <jmbsvicetto>	genstef: I'm probably going to have to do something similar for sparc ATs, so if you want, I can work with you on that
-[Sa Okt 13 2007] [21:01:02] <genstef>	jmbsvicetto: ok, cool!
-[Sa Okt 13 2007] [21:01:14] <genstef>	Philantrop: will send it to kde@gentoo.org then
-[Sa Okt 13 2007] [21:01:27] <Philantrop>	genstef, jmbsvicetto: Thanks, guys! I'll add that to the summary, too.
-[Sa Okt 13 2007] [21:01:44] <Philantrop>	Anything else, gentlemen?
-[Sa Okt 13 2007] [21:02:43] <jmbsvicetto>	Philantrop: About six-sigma, are we still interested in trying it on kde?
-[Sa Okt 13 2007] [21:02:55] <jmbsvicetto>	Philantrop: If so, do we leave that for a future meeting where NeddySeagoon can help?
-[Sa Okt 13 2007] [21:03:12] <Philantrop>	jmbsvicetto: Good question. Opinions?
-[Sa Okt 13 2007] [21:03:36] <tgurr>	six-sigma?
-[Sa Okt 13 2007] [21:04:07] <Philantrop>	tgurr: Oh, right. That was before your dev time. It's a process improvement thing.
-[Sa Okt 13 2007] [21:04:25] <Philantrop>	tgurr: I'll forward you a mail about it.
-[Sa Okt 13 2007] [21:04:47] <keytoaster>	re
-[Sa Okt 13 2007] [21:05:00] <Philantrop>	I'd say we invite Neddy to our next meeting and see about it then. Any objections?
-[Sa Okt 13 2007] [21:05:07] <tgurr>	Philantrop, thanks :)
-[Sa Okt 13 2007] [21:05:14] <Philantrop>	keytoaster: Welcome back! :-)
-[Sa Okt 13 2007] [21:05:27] <keytoaster>	:)
-[Sa Okt 13 2007] [21:05:29] <Philantrop>	Anything else?
-[Sa Okt 13 2007] [21:06:29] <Philantrop>	I'll make a summary of our meeting and export a log from Konversation. I'll mail it around to kde@g.o and if it's fine, I'll ask keytoaster to add it to our project page. Ok?
-[Sa Okt 13 2007] [21:06:33] <jmbsvicetto>	Philantrop: Maybe just a heads-up about next meeting date?
-[Sa Okt 13 2007] [21:06:39] <genstef>	Philantrop: thanks :)
-[Sa Okt 13 2007] [21:06:41] <jmbsvicetto>	Philantrop: sure
-[Sa Okt 13 2007] [21:07:08] <jmbsvicetto>	If I'm not mistaken, next meeting will take place at 13/11
-[Sa Okt 13 2007] [21:07:28] <Philantrop>	Ok, then. The next meeting will take place on November, 10th, 2007 at 18:00 UTC here in #gentoo-kde. :-) I'll mail reminders again and poke you guys on IRC whereever I find you. :-)
-[Sa Okt 13 2007] [21:08:04] <jmbsvicetto>	Sorry, 10/11
-[Sa Okt 13 2007] [21:08:15] <keytoaster>	Philantrop, uhm, could we do that on another date
-[Sa Okt 13 2007] [21:08:25] <Philantrop>	keytoaster: What's wrong with that date? :-)
-[Sa Okt 13 2007] [21:08:43] <keytoaster>	i just found out that my family visits my friend every second saturday of the month as well...
-[Sa Okt 13 2007] [21:09:02] <keytoaster>	so we'll probably be having dinner at this time, just like today
-[Sa Okt 13 2007] [21:09:14] <keytoaster>	so i will most likely never be able to attend the whole meeting
-[Sa Okt 13 2007] [21:09:17] <genstef>	first saturday then? :)
-[Sa Okt 13 2007] [21:09:22] <keytoaster>	fine for me
-[Sa Okt 13 2007] [21:09:28] <jmbsvicetto>	hehe
-[Sa Okt 13 2007] [21:09:32] <Philantrop>	!herd kde
-[Sa Okt 13 2007] [21:09:35] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
-[Sa Okt 13 2007] [21:09:45] <Philantrop>	Shall we move our meetings to the first Saturday each month?
-[Sa Okt 13 2007] [21:09:48] <jmbsvicetto>	first saturday is bug day, but fine with me ;)
-[Sa Okt 13 2007] [21:10:42] <Philantrop>	cryos|laptop, genstef, keytoaster, masterdriverz, tgurr? First Saturday each month from November on?
-[Sa Okt 13 2007] [21:10:51] <keytoaster>	yes
-[Sa Okt 13 2007] [21:11:07] <cryos|laptop>	Yes.
-[Sa Okt 13 2007] [21:11:17] <tgurr>	fine to me
-[Sa Okt 13 2007] [21:11:44] <jmbsvicetto>	Anyone objects having a note on the project page about the "usual" meeting time?
-[Sa Okt 13 2007] [21:12:01] <jmbsvicetto>	In case any interested party wants to follow the meetings
-[Sa Okt 13 2007] [21:12:12] <Philantrop>	If I didn't misread genstef he doesn't object to it either so that would be 5:0 in favour of moving it. :-)
-[Sa Okt 13 2007] [21:12:54] <Philantrop>	keytoaster: Could you add a note about the 1st Sat every month as our meeting time?
-[Sa Okt 13 2007] [21:13:28] <keytoaster>	yup
-[Sa Okt 13 2007] [21:13:53] <Philantrop>	It's decided then: The next meeting will take place on November, 3rd, 2007 at 18:00 UTC here in #gentoo-kde. :-)
-[Sa Okt 13 2007] [21:14:05] <keytoaster>	i'll do it as soon as i'm home
-[Sa Okt 13 2007] [21:14:12] <Philantrop>	keytoaster: Sure, no worries. :-)
-[Sa Okt 13 2007] [21:14:30] <Philantrop>	!herd kde
-[Sa Okt 13 2007] [21:14:31] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
-[Sa Okt 13 2007] [21:14:32] <Philantrop>	Anything else for tonight, guys?
-[Sa Okt 13 2007] [21:15:16] <jmbsvicetto>	Can't recall anything else
-[Sa Okt 13 2007] [21:15:37] <Philantrop>	Ok, thanks to all of your for attending. It's great this works and I really appreciate your feedback and help!
-[Sa Okt 13 2007] [21:15:46] <Philantrop>	s/your/you :-)
-[Sa Okt 13 2007] [21:15:52] <genstef>	Philantrop: well, I wonder about a kde lead? I think we decided last time about it, but cannot find anything on the project page?
-[Sa Okt 13 2007] [21:16:03] <Philantrop>	genstef: We didn't decide about it. :)
-[Sa Okt 13 2007] [21:16:30] <jmbsvicetto>	genstef: I think we decided to *not* decide ;)
-[Sa Okt 13 2007] [21:16:41] <Philantrop>	We could decide about it, of course.
-[Sa Okt 13 2007] [21:16:46] <genstef>	Philantrop: some note like "we do not have a lead: decisions can be made by everyone but it usually it is a good idea to ask philantrop because he is around and knowledgable"
-[Sa Okt 13 2007] [21:17:46] <jmbsvicetto>	I would like to propose we select a lead for kde and I want to suggest Philantrop
-[Sa Okt 13 2007] [21:17:46] <genstef>	anyways, not that important ..
-[Sa Okt 13 2007] [21:18:48] <jmbsvicetto>	Does anyone want to open up the election process?
-[Sa Okt 13 2007] [21:18:58] <genstef>	jmbsvicetto: totally against it
-[Sa Okt 13 2007] [21:19:05] <genstef>	we already decided on the matter :)
-[Sa Okt 13 2007] [21:19:13] <genstef>	it just needs to be reflected on the project page
-[Sa Okt 13 2007] [21:19:14] <jmbsvicetto>	Against the lead or the election? ;)
-[Sa Okt 13 2007] [21:19:19] <jmbsvicetto>	Ah, ok :)
-[Sa Okt 13 2007] [21:19:38] <genstef>	you said what we decided
-[Sa Okt 13 2007] [21:19:42] <jmbsvicetto>	:)
-[Sa Okt 13 2007] [21:19:51] <Philantrop>	genstef: We'll add the note as you suggested to the project page. :-)
-[Sa Okt 13 2007] [21:19:56] <jmbsvicetto>	keytoaster: Mind to add a note to the page? ;)
-[Sa Okt 13 2007] [21:20:11] <jmbsvicetto>	Philantrop: We should also send a mail to -core or -dev announcing it
-[Sa Okt 13 2007] [21:20:20] <keytoaster>	give me a complete text :)
-[Sa Okt 13 2007] [21:20:40] <genstef>	keytoaster: look a few lines a bove the long text.
-[Sa Okt 13 2007] [21:21:00] <Philantrop>	keytoaster: "We do not have a formal lead: Decisions can be made by every herd member but it usually is a good idea to ask philantrop because he is around and knowledgable."
-[Sa Okt 13 2007] [21:21:41] <keytoaster>	ah, k, thanks
-[Sa Okt 13 2007] [21:22:17] <Philantrop>	Ok, final call: Anything else? :-)
-[Sa Okt 13 2007] [21:22:18] <genstef>	possibly close to the members box
-[Sa Okt 13 2007] [21:22:34] <Philantrop>	keytoaster: Directly above the box, I'd say. :-)
-[Sa Okt 13 2007] [21:24:28] <tgurr>	I'm off then, ok?
-[Sa Okt 13 2007] [21:25:00] <Philantrop>	Ok, let's call this meeting closed! Thanks again! :-)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20080306.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20080306.txt
deleted file mode 100644
index acda721d40..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20080306.txt
+++ /dev/null
@@ -1,518 +0,0 @@
-[Do Mär 6 2008] [20:30:29] <Philantrop>	!herd kde 
-[Do Mär 6 2008] [20:30:31] <jeeves>	Philantrop: (kde) caleb, carlo, cryos, deathwing00, genstef, ingmar, jmbsvicetto, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, zlin
-[Do Mär 6 2008] [20:30:32] <Philantrop>	ping ^^^
-[Do Mär 6 2008] [20:30:37] <Ingmar>	evening :)
-[Do Mär 6 2008] [20:30:38] <deathwing00>	pong
-[Do Mär 6 2008] [20:30:50] <zlin>	:>
-[Do Mär 6 2008] [20:31:14] <ctennis>	ctennis == caleb
-[Do Mär 6 2008] [20:31:19] <tgurr>	meh
-[Do Mär 6 2008] [20:31:24] <Philantrop>	ctennis: Yes, thanks, I know. :-)
-[Do Mär 6 2008] [20:31:32] <ctennis>	just making sure everyone else did :)
-[Do Mär 6 2008] [20:32:05] <keytoaster>	bzzzzz
-[Do Mär 6 2008] [20:32:09] 	 * gentoofan23 guessed
-[Do Mär 6 2008] [20:33:02] <Philantrop>	jmbsvicetto, masterdriverz, genstef around? :-)
-[Do Mär 6 2008] [20:33:11] 	 * cryos|laptop had no clue...
-[Do Mär 6 2008] [20:33:22] Mode	ChanServ gives channel operator privileges to deathwing00.
-[Do Mär 6 2008] [20:33:28] Mode	deathwing00 gives channel operator privileges to you.
-[Do Mär 6 2008] [20:33:34] Mode	deathwing00 gives masterdriverz the permission to talk.
-[Do Mär 6 2008] [20:34:20] <Philantrop>	Ok, let's start guys! :-) First on the agenda is the bump to 3.5.9 which was somewhat, bumpy... ;)
-[Do Mär 6 2008] [20:34:24] Mode	deathwing00 gives ctennis the permission to talk.
-[Do Mär 6 2008] [20:34:44] <Philantrop>	deathwing00: Thanks, but this will be open floor anyway. :-)
-[Do Mär 6 2008] [20:34:50] <deathwing00>	ok
-[Do Mär 6 2008] [20:35:29] <Philantrop>	We have one major issue open: Split and monotlithic ebuilds. Split ebuilds depend hard on split dependencies and won't accept monolithic ebuilds. 
-[Do Mär 6 2008] [20:35:45] <Philantrop>	Some of us want to change that, some others don't. Your opinions?
-[Do Mär 6 2008] [20:36:33] <gentoofan23>	Well, doesn't it depend on the program? Some could do a || dep on split/monolithic and some can't, right?
-[Do Mär 6 2008] [20:37:25] <Philantrop>	gentoofan23: No, not really as basically any monolithic ebuild would install what its split packages would.
-[Do Mär 6 2008] [20:37:43] <Philantrop>	But we're talking about kde-base/* only here. 
-[Do Mär 6 2008] [20:38:10] <deathwing00>	My opinion is that we should opt to drop monolithic ebuilds for the following reasons: 1) Applying security fixes and patches to a split ebuild implies less development and maintenance effort, which in turn 2) implies less compilation on users and 3?) if I remember correctly KDE 4 was going to drop monolithic components (how's that by the way?)
-[Do Mär 6 2008] [20:38:46] <keytoaster>	++
-[Do Mär 6 2008] [20:38:48] <Ingmar>	KDE 4 has had them dropped already
-[Do Mär 6 2008] [20:38:53] <Philantrop>	!bug 211116
-[Do Mär 6 2008] [20:38:55] <jeeves>	Philantrop: https://bugs.gentoo.org/211116 maj, P2, All, infoman1985@gmail.com->kde@gentoo.org, REOPENED, pending, kde-base/*-3.5.9 split packages can't be mixed with kde-base/*-3.5.9 monolithic packages.
-[Do Mär 6 2008] [20:38:55] <jeeves>	Philantrop: https://bugs.gentoo.org/211116 maj, P2, All, infoman1985@gmail.com->kde@gentoo.org, REOPENED, pending, kde-base/*-3.5.9 split packages can't be mixed with kde-base/*-3.5.9 monolithic packages.
-[Do Mär 6 2008] [20:39:15] <Philantrop>	^^^ That's the bug. 
-[Do Mär 6 2008] [20:39:29] <Ingmar>	but I disagree, dropping monolithic :3.5 ebuilds is a regression imho, besides, some slow arches only have those keyworded, and I see no reason to force a change upon them on a version of KDE that's getting EOL'ed soon
-[Do Mär 6 2008] [20:40:12] <tgurr>	mixing splits and monolithic was never supported by us anyways, was it? possible yes.. sadly :)
-[Do Mär 6 2008] [20:40:15] <zlin>	I'm with Ingmar on this one
-[Do Mär 6 2008] [20:40:31] <Philantrop>	I'd like to keep it the way it is as only a few users even complained and most jsut switched to split ebuilds. :-)
-[Do Mär 6 2008] [20:40:49] 	 * Philantrop scribbles two names into his little black book... ;-)
-[Do Mär 6 2008] [20:40:55] <Ingmar>	well, other users apparently care enough to attach a partial patch
-[Do Mär 6 2008] [20:41:03] <deathwing00>	we are not planning on offering monolithic ebuilds on KDE 4, are we?
-[Do Mär 6 2008] [20:41:04] <zlin>	tgurr: it used to be possible through the eclasses. 3.5.9 uses EAPI=1 and thus doesn't use those eclass functions anymore...
-[Do Mär 6 2008] [20:41:11] <Philantrop>	deathwing00: Nope. :-)
-[Do Mär 6 2008] [20:41:17] <jmbsvicetto>	pong
-[Do Mär 6 2008] [20:41:20] <jmbsvicetto>	sorry, just got home
-[Do Mär 6 2008] [20:41:22] <Ingmar>	and it doesn't make sense for a user that kdebase + kdenetwork works, but kdebase + kopete doesn't
-[Do Mär 6 2008] [20:41:30] <Philantrop>	jmbsvicetto: No problem. Thanks for being here. 
-[Do Mär 6 2008] [20:41:36] <gentoofan23>	I object as some boxes I maintain use monolithic and it'd be a huge pain to switch to split. I imagine many others would feel pain to
-[Do Mär 6 2008] [20:41:48] <Ingmar>	and that's a good point too
-[Do Mär 6 2008] [20:41:49] <deathwing00>	If we are to not provide it on KDE 4, we can let it be for now, I guess
-[Do Mär 6 2008] [20:41:55] <Ingmar>	converting = lots of useless work
-[Do Mär 6 2008] [20:42:15] <zlin>	gentoofan23: the problem is mixing. not all splits or all monos.
-[Do Mär 6 2008] [20:42:34] <deathwing00>	make all splits block all monos and vice-versa
-[Do Mär 6 2008] [20:42:52] <zlin>	that's essentially what we have now
-[Do Mär 6 2008] [20:42:58] <deathwing00>	 "you want a full mono, you got -meta"
-[Do Mär 6 2008] [20:43:06] <deathwing00>	I agree on that one
-[Do Mär 6 2008] [20:43:35] <deathwing00>	zlin: is it correctly implemented or are we missing something?
-[Do Mär 6 2008] [20:43:46] <Philantrop>	Ok, let's try a slightly different approach - is anyone here willing to change what we have now? :-)
-[Do Mär 6 2008] [20:43:59] 	 * Philantrop looks at Ingmar and zlin. *g*
-[Do Mär 6 2008] [20:44:32] <deathwing00>	we can sort of vote if necessary
-[Do Mär 6 2008] [20:44:36] <Ingmar>	Guess that means that I'll do it
-[Do Mär 6 2008] [20:44:49] <Ingmar>	Sure you can vote, but unless you convince me *not* to do it, it's going to happen though :>
-[Do Mär 6 2008] [20:45:18] Join	mikb has joined this channel (n=mikb@c211-31-30-148.belrs4.nsw.optusnet.com.au).
-[Do Mär 6 2008] [20:45:19] <deathwing00>	Ingmar: I missed something in here... what is gonna happen?
-[Do Mär 6 2008] [20:45:20] <Philantrop>	deathwing00: Well, I've already recorded opinions. At the moment, we're stuck at 2:2 but if Ingmar volunteers, why not. :-)
-[Do Mär 6 2008] [20:45:37] <deathwing00>	Philantrop: ok, got it
-[Do Mär 6 2008] [20:45:43] Quit	mikb has left this server (Client Quit).
-[Do Mär 6 2008] [20:45:53] <zlin>	\o/
-[Do Mär 6 2008] [20:45:54] <Philantrop>	deathwing00: What Ingmar wants to do is allowing users to mix 3.5.9 splits and monos again. I'm not too strongly against it. :-)
-[Do Mär 6 2008] [20:46:02] <Ingmar>	It's simply stupid to force monolithic users to switch
-[Do Mär 6 2008] [20:46:38] <Philantrop>	Ingmar: Well, considering that they will have to switch for KDE4 anyway, it wouldn't be too bad, I think, but since you volunteered... :-)
-[Do Mär 6 2008] [20:46:43] <zlin>	arfie's patch shows what's we want to change.. might not be complete but you get the idea...
-[Do Mär 6 2008] [20:46:48] <jmbsvicetto>	As I've told others before, I agree that the problems caused by mixing splits/monos is reason enough to have splits hard dep on split
-[Do Mär 6 2008] [20:47:11] <jmbsvicetto>	But if Ingmar wants to support it, let him
-[Do Mär 6 2008] [20:47:27] <Philantrop>	jmbsvicetto: Well, a thing Ingmar brought up elsewhere, we might run into even more bug reports now. :)
-[Do Mär 6 2008] [20:47:39] <jmbsvicetto>	Ingmar: If anyone else is willing to help you, you might want ot use an overlay to do that work
-[Do Mär 6 2008] [20:47:45] <deathwing00>	Philantrop: so who is 'yeah' and who is 'nay'?
-[Do Mär 6 2008] [20:48:15] <jmbsvicetto>	deathwing00: I'm a yeay/neah ;)
-[Do Mär 6 2008] [20:48:20] <deathwing00>	hehe
-[Do Mär 6 2008] [20:48:30] 	 * gentoofan23 isn't sure if he can vote, so he abstains. :). That's rather paradoxical though 
-[Do Mär 6 2008] [20:48:36] <Philantrop>	deathwing00: I've recorded you as "nay" to mixing, me too, jmbsvicetto undecided. Ingmar and zlin "yay". :-)
-[Do Mär 6 2008] [20:48:44] <deathwing00>	ok
-[Do Mär 6 2008] [20:48:51] 	 * cryos|laptop is nay...
-[Do Mär 6 2008] [20:48:54] <deathwing00>	jmbsvicetto: decide already
-[Do Mär 6 2008] [20:49:17] <Philantrop>	cryos|laptop: Just to be sure: "Nay" to mixing splits and monos in 3.5.9?
-[Do Mär 6 2008] [20:49:23] <cryos|laptop>	Yep
-[Do Mär 6 2008] [20:49:23] <jmbsvicetto>	Ingmar: If you do that work on an overlay, I can try to help on "a few" ebuilds - no promises though
-[Do Mär 6 2008] [20:49:45] <Philantrop>	cryos|laptop: Thanks, noted. Anything you could add to make Ingmar see the light? ;-)
-[Do Mär 6 2008] [20:50:16] <cryos|laptop>	Philantrop: Just that it really does not seem worth the effort, we looked at this in the beginning when splits were introduced..
-[Do Mär 6 2008] [20:50:26] <jmbsvicetto>	deathwing00: My view is that allowing that is a good thing, but I understand if we decide otherwise. In any case, I can't commit that to the tree. I can try to help on an overlay though
-[Do Mär 6 2008] [20:50:48] <zlin>	carlo is clearly a "yay" too and it was supported till 3.5.8
-[Do Mär 6 2008] [20:50:52] <cryos|laptop>	If he wants to do it I think he should try it but I wouldn't spend my time trying to fix that personally. It seems tough to get it right and I wonder where the pay off is.
-[Do Mär 6 2008] [20:51:27] 	 * cryos|laptop has been largely AFK in recent months though - desktop in a US customs area in New York still :-(
-[Do Mär 6 2008] [20:51:46] <Philantrop>	cryos|laptop: That's annyoing. :-(
-[Do Mär 6 2008] [20:52:04] <Philantrop>	Ok, se can we settle this by saying Ingmar may fix it if he wants? :-)
-[Do Mär 6 2008] [20:52:05] <deathwing00>	I have another argument that you could consider, if we add this for 3.5.9 and then it exists no longer to KDE 4, won't the users be forced into monolithic anyway?
-[Do Mär 6 2008] [20:52:14] <cryos|laptop>	Yeah - delays, delays and more delays. Do have my Gentoo laptop working with KDE4 and 3.5.9 though.
-[Do Mär 6 2008] [20:52:26] <Philantrop>	deathwing00: To split ebuilds, yes.
-[Do Mär 6 2008] [20:52:37] <Philantrop>	cryos|laptop: At least something. :-)
-[Do Mär 6 2008] [20:52:48] <deathwing00>	Philantrop: yeah, that's what I meant
-[Do Mär 6 2008] [20:52:52] <zlin>	deathwing00: that's a different SLOT though so it doesn't matter all that much imo
-[Do Mär 6 2008] [20:52:59] <jmbsvicetto>	Philantrop: I agree with that
-[Do Mär 6 2008] [20:53:15] Quit	ZeRoX has left this server (Client Quit).
-[Do Mär 6 2008] [20:53:19] <jmbsvicetto>	IIRC, the move forward is another point on this discussion
-[Do Mär 6 2008] [20:53:32] <deathwing00>	zlin: I understand, but it might be a needless effort, we could focus our efforts elsewhere, m¢ :)
-[Do Mär 6 2008] [20:53:39] <Philantrop>	Ok, final call for violent objections against Ingmar changing it. :-)
-[Do Mär 6 2008] [20:53:48] <deathwing00>	no veto here
-[Do Mär 6 2008] [20:54:07] <zlin>	deathwing00: that just means it's low priority.. :)
-[Do Mär 6 2008] [20:54:16] <deathwing00>	zlin: agreed
-[Do Mär 6 2008] [20:54:22] <Philantrop>	Ok, any other points that should be brought up for the past 3.5.9 version bump?
-[Do Mär 6 2008] [20:55:10] <Philantrop>	Ok, topic 2: KDE 3.5.8 is stable now and will be in the 2008.0 release. :-)
-[Do Mär 6 2008] [20:55:10] <gentoofan23>	I have a point(slightly related). Is there anything wrong with keeping the old stable around a little longer(3.5.7 specifically)?
-[Do Mär 6 2008] [20:55:34] <Philantrop>	gentoofan23: Well, what's wrong with removing it after a newer one has gone stable?
-[Do Mär 6 2008] [20:56:15] Join	ZeRoX has joined this channel (n=zerox@nelug/developer/zer0x).
-[Do Mär 6 2008] [20:56:16] <Ingmar>	Well, we don't intend to support 5 versions of KDE
-[Do Mär 6 2008] [20:56:38] <gentoofan23>	Philantrop: Stable users only had 19 days(iirc) to upgrade before 3.5.7 got booted. It bit me in that I needed to install a specific aspect of Kde and only 3.5.8 was available. So I had to upgrade all of kdelibs,base to get that new portion
-[Do Mär 6 2008] [20:57:11] <zlin>	given that we have a newer version which we know is way better, fixes tons of bugs and noone neither upstream nor downstream want to support the old version...
-[Do Mär 6 2008] [20:57:26] <gentoofan23>	Ingmar: I'm not suggesting that, I'm suggesting keeping it around a bit longer. 19 days is a little short
-[Do Mär 6 2008] [20:57:30] <Ingmar>	I honestly don't see why we'd keep old stable versions around when never, better stable ebuilds are available
-[Do Mär 6 2008] [20:57:33] <Ingmar>	it isn't
-[Do Mär 6 2008] [20:57:42] <Philantrop>	gentoofan23: Well, yes, I would have thought two weeks were enough to update. It was even for my old Alpha workstation with 233 MHz. :)
-[Do Mär 6 2008] [20:58:16] <gentoofan23>	eh, I was a little busy. but granted that, I concede my point I guess
-[Do Mär 6 2008] [20:58:22] <Philantrop>	gentoofan23: What would have been long enough for you?
-[Do Mär 6 2008] [20:58:35] <Philantrop>	(Under normal circumstances.)
-[Do Mär 6 2008] [20:58:41] <jmbsvicetto>	Philantrop: This falls down to the discussion between maintainers/ats about whether old working versions shold be kept around or not
-[Do Mär 6 2008] [20:58:55] <gentoofan23>	Philantrop: maybe 45 days?
-[Do Mär 6 2008] [20:59:07] <Philantrop>	gentoofan23: How about 30? :-)
-[Do Mär 6 2008] [20:59:15] 	 * Philantrop emulates a bazaar. ;-)
-[Do Mär 6 2008] [20:59:19] <gentoofan23>	Philantrop: even that'd be ok I guess
-[Do Mär 6 2008] [20:59:19] <deathwing00>	30 sounds more reasonable to me
-[Do Mär 6 2008] [20:59:25] Join	NeddySeagoon has joined this channel (n=NeddySea@gentoo/developer/NeddySeagoon).
-[Do Mär 6 2008] [20:59:25] Mode	ChanServ gives NeddySeagoon the permission to talk.
-[Do Mär 6 2008] [20:59:30] <jmbsvicetto>	Philantrop: I agree that for maintainers it makes sense to kick old versions - in particular for a project with as many ebuilds as kde
-[Do Mär 6 2008] [20:59:30] <gentoofan23>	19 is rather unreasonable to me.
-[Do Mär 6 2008] [20:59:41] <deathwing00>	yay to 30 days by me then
-[Do Mär 6 2008] [20:59:54] <Philantrop>	jmbsvicetto: That's why we did it, indeed. :-)
-[Do Mär 6 2008] [21:00:08] <gentoofan23>	hey, Kubuntu is still supporting a KDE from 3 years ago :-P
-[Do Mär 6 2008] [21:00:08] <Philantrop>	And Ingmar stole all those commits from me! ;-)
-[Do Mär 6 2008] [21:00:19] <jmbsvicetto>	hehe
-[Do Mär 6 2008] [21:00:38] <Philantrop>	gentoofan23: 30 days are ok then? :-)
-[Do Mär 6 2008] [21:00:40] <Ingmar>	So next time Philantrop will be so pressed to get thsoe commits, it won't even be 19 days :>
-[Do Mär 6 2008] [21:00:57] <gentoofan23>	Philantrop: yeah, it should be. Of course, I don't use mips :p
-[Do Mär 6 2008] [21:01:21] <jmbsvicetto>	gentoofan23: It doesn't matter anymore. mips has gone the unstable road
-[Do Mär 6 2008] [21:01:35] <gentoofan23>	jmbsvicetto: Oh yes, that is true
-[Do Mär 6 2008] [21:01:37] <Philantrop>	Ok, anything else on the bump or 3.5.8 in the upcoming release?
-[Do Mär 6 2008] [21:01:49] <jmbsvicetto>	gentoofan23: From now on, mips needs to keyword a version at least until everyone marks it stable
-[Do Mär 6 2008] [21:02:00] <Ingmar>	they already did
-[Do Mär 6 2008] [21:02:03] <Ingmar>	monolithic 3.5.9
-[Do Mär 6 2008] [21:02:10] <jmbsvicetto>	Ingmar: ok
-[Do Mär 6 2008] [21:02:11] 	 * Philantrop sobs
-[Do Mär 6 2008] [21:02:21] 	 * Philantrop sees his ebuilds tainted. ;-)
-[Do Mär 6 2008] [21:02:30] <jmbsvicetto>	Philantrop: :)
-[Do Mär 6 2008] [21:02:31] <Ingmar>	or he didn't, but he's going to, any time soon :)
-[Do Mär 6 2008] [21:03:01] <Philantrop>	Ok, anything else on the bump or 3.5.8 in the upcoming release? (Final call)
-[Do Mär 6 2008] [21:03:31] <Philantrop>	Great. gentoofan23 already brought up topic 3 - Removal of KDE < 3.5.8 from the tree. :-)
-[Do Mär 6 2008] [21:04:02] <Philantrop>	Ingmar kindly killed 3.5.5 to 3.5.7. So we don't have to worry about those anymore. :-)
-[Do Mär 6 2008] [21:04:05] <gentoofan23>	uh, I swear I didn't see that on the agenda.
-[Do Mär 6 2008] [21:04:08] 	 * gentoofan23 hides
-[Do Mär 6 2008] [21:04:09] <zlin>	so that's done. next! :>
-[Do Mär 6 2008] [21:05:04] <Philantrop>	Well, I guess since zlin has a hot date with a rubber doll, we should move on to topic 4 - State of KDE4 in the tree. ;-)
-[Do Mär 6 2008] [21:05:24] <tgurr>	Oo
-[Do Mär 6 2008] [21:05:34] <Philantrop>	Ingmar, zlin: Let's hear - what's in the tree, when's 4.0.2 going in? :-)
-[Do Mär 6 2008] [21:05:54] <zlin>	well, as such the ebuilds in the tree are in a pretty good state. the deps need to be updated for compatibility with the newly introduced split qt-4.4 ebuilds and it needs to be bumped to 4.0.2 (only kdebase and games have been bumped thus far)...
-[Do Mär 6 2008] [21:05:54] <Philantrop>	Ingmar, zlin: And: What's the state of KDE 4.0.2 by your findings? :-)
-[Do Mär 6 2008] [21:06:07] <Ingmar>	Well, some time this weekend, so far we've been busy with the newer Qt
-[Do Mär 6 2008] [21:06:40] <Philantrop>	And the two of you did a great job with Qt, I'd say. :)
-[Do Mär 6 2008] [21:06:43] <zlin>	honestly I haven't had a lot of time to use 4.0.2 yet.. but it'll come in the following days.
-[Do Mär 6 2008] [21:06:48] <jmbsvicetto>	Ingmar / zlin: Can I start working on kdenetwork?
-[Do Mär 6 2008] [21:06:55] <zlin>	jmbsvicetto: certainly
-[Do Mär 6 2008] [21:06:58] <Ingmar>	jmbsvicetto: Yes, please :)
-[Do Mär 6 2008] [21:07:01] <jmbsvicetto>	ok
-[Do Mär 6 2008] [21:07:07] <jmbsvicetto>	Do you want me to look at anything else?
-[Do Mär 6 2008] [21:07:14] <zlin>	any help with bumping it will be appreciated
-[Do Mär 6 2008] [21:07:46] <gentoofan23>	eh, I'd help but amd64 AT's need a stable system. :(
-[Do Mär 6 2008] [21:07:46] <Ingmar>	Right, and that goes for bug reports too :)
-[Do Mär 6 2008] [21:07:51] <jmbsvicetto>	I've updated my amd64 and x86 to 4.0.2 during the night, so I can start working on kdenetwork after the meeting
-[Do Mär 6 2008] [21:08:11] <gentoofan23>	maybe I'll be able to do it,  but don't expect much :)
-[Do Mär 6 2008] [21:08:27] <gentoofan23>	s/do/help/
-[Do Mär 6 2008] [21:08:31] <Philantrop>	As for zlin's plea for help: Anyone who wants to help should simply mail me his ssh public key. Interested users who can show they're able and willing to work on ebuilds are *explicitly* invited, too. :-)
-[Do Mär 6 2008] [21:09:29] <Philantrop>	The bump to 4.0.2 is taking place in a git overlay again to allow for non-ebuild devs to participate, too, and it's a great way to become a full dev as Ingmar and zlin can verify. :-)
-[Do Mär 6 2008] [21:09:48] <Ingmar>	:)
-[Do Mär 6 2008] [21:09:56] <zlin>	and as we want berniyh to do too! :>
-[Do Mär 6 2008] [21:10:17] <deathwing00>	poor ignorants... they don't know it yet... *g*
-[Do Mär 6 2008] [21:10:22] <gentoofan23>	well, I might be able to help in places. I
-[Do Mär 6 2008] [21:10:29] <gentoofan23>	I'll e-mail my key
-[Do Mär 6 2008] [21:10:46] <Philantrop>	gentoofan23: Ok, thanks, we'll work out the details later.
-[Do Mär 6 2008] [21:11:14] <Philantrop>	Ok, anything else about KDE4 for now?
-[Do Mär 6 2008] [21:12:03] <gentoofan23>	just a question, what's the policy for things from playground/ going into gentoo-x86?
-[Do Mär 6 2008] [21:12:26] <gentoofan23>	various plasmoids come to mind.
-[Do Mär 6 2008] [21:12:27] <zlin>	we can discuss that later
-[Do Mär 6 2008] [21:12:29] <Ingmar>	It'd be wrong
-[Do Mär 6 2008] [21:12:39] <Ingmar>	playground is what upstream doesn't consider release worthy
-[Do Mär 6 2008] [21:12:45] <gentoofan23>	alright.
-[Do Mär 6 2008] [21:13:12] <Philantrop>	gentoofan23: We could have it in the overlay, though. :-)
-[Do Mär 6 2008] [21:13:14] <Ingmar>	Meaning that it may work, but they won't support it
-[Do Mär 6 2008] [21:13:18] <Ingmar>	definitely
-[Do Mär 6 2008] [21:13:26] <zlin>	we already have a lot of it in the overlay
-[Do Mär 6 2008] [21:13:29] <gentoofan23>	Ok.
-[Do Mär 6 2008] [21:13:40] <Philantrop>	Ingmar: They don't really support the other stuff either - see KDE 4.0.0. ;->
-[Do Mär 6 2008] [21:13:56] <orzelf>	do we ? which cpv ?
-[Do Mär 6 2008] [21:14:02] <Philantrop>	They just release it. Like Pandora did. ;-)
-[Do Mär 6 2008] [21:14:05] <Ingmar>	Pfft, stop being a pansy and use 4.0.2 damnit
-[Do Mär 6 2008] [21:14:36] <Philantrop>	Ok, anything else about KDE4 for now? (Final call.)
-[Do Mär 6 2008] [21:14:41] <zlin>	orzelf: 6-8 packages...
-[Do Mär 6 2008] [21:15:01] <Philantrop>	orzelf: Please ask about that in #genkdesvn. The guys there will help you.
-[Do Mär 6 2008] [21:15:05] <Ingmar>	Most of the extragear things is really few work to package it btw
-[Do Mär 6 2008] [21:15:59] <zlin>	oh, I might be confusing extragear and playground. maybe it's only a couple of packages then. ;)
-[Do Mär 6 2008] [21:16:44] <Philantrop>	Ok, topic 5 - Herd Testers: Current state and next steps. jmbsvicetto, you're the one in charge with respect to that. :-)
-[Do Mär 6 2008] [21:17:17] <jmbsvicetto>	Well, I haven't done much yet. With the elections and a few other things, I was distracted
-[Do Mär 6 2008] [21:17:31] <jmbsvicetto>	However, the only person that as contacted me about HT was gentoofan23
-[Do Mär 6 2008] [21:17:40] <Philantrop>	jmbsvicetto: Yes, I know. You corrupted Neddy and four others. ;-)
-[Do Mär 6 2008] [21:17:47] <jmbsvicetto>	Philantrop: Has anyone else talked with you about it?
-[Do Mär 6 2008] [21:17:57] <Ingmar>	Did you get berniyh's mail? :p
-[Do Mär 6 2008] [21:18:05] <Philantrop>	jmbsvicetto: No, not so far. What we should
-[Do Mär 6 2008] [21:18:17] <gentoofan23>	jmbsvicetto: yeah, I was accepted by Philantrop as well. Haven't been doing much though
-[Do Mär 6 2008] [21:18:17] <NeddySeagoon>	hehe
-[Do Mär 6 2008] [21:18:23] <jmbsvicetto>	berniyh: Did you sent me an email?
-[Do Mär 6 2008] [21:18:27] <berniyh>	Ingmar: mail?
-[Do Mär 6 2008] [21:18:33] <berniyh>	jmbsvicetto: not that i know of ;)
-[Do Mär 6 2008] [21:18:35] <Philantrop>	* do is flesh things a bit out, I think so that people know what we'd like to see done. :-)
-[Do Mär 6 2008] [21:18:38] <berniyh>	*none
-[Do Mär 6 2008] [21:18:52] <jmbsvicetto>	berniyh: ufff! :)
-[Do Mär 6 2008] [21:19:01] <Philantrop>	jmbsvicetto: Don't worry, berniyh is worse a slacker than you are. ;-)
-[Do Mär 6 2008] [21:19:11] <jmbsvicetto>	hehe
-[Do Mär 6 2008] [21:19:20] <berniyh>	jmbsvicetto: maybe he meant that viagra thing? *g*
-[Do Mär 6 2008] [21:19:32] <orzelf>	Philantrop, zlin : ok ,thx.
-[Do Mär 6 2008] [21:19:55] <jmbsvicetto>	Philantrop: Agreed. We might also want to announce again that we're open for HTs and that people can help that way
-[Do Mär 6 2008] [21:20:10] <deathwing00>	I can announce that on GMN
-[Do Mär 6 2008] [21:20:11] <jmbsvicetto>	Philantrop: We might want to push something to gmn and gentoo-pr
-[Do Mär 6 2008] [21:20:18] <deathwing00>	shall I take note?
-[Do Mär 6 2008] [21:20:21] <jmbsvicetto>	berniyh: :)
-[Do Mär 6 2008] [21:20:26] <Philantrop>	jmbsvicetto: Yes, good idea. We'll come to that in topic 8 - misc. :-)
-[Do Mär 6 2008] [21:20:32] <Philantrop>	deathwing00: Yes, please.
-[Do Mär 6 2008] [21:20:42] <jmbsvicetto>	I can also "abuse" the forums for that ;)
-[Do Mär 6 2008] [21:20:44] <gentoofan23>	maybe have dberkholz put something on the front page? (as in not gmn)
-[Do Mär 6 2008] [21:20:47] <deathwing00>	Philantrop: noted :)
-[Do Mär 6 2008] [21:20:53] <jmbsvicetto>	deathwing00: yes, please
-[Do Mär 6 2008] [21:21:04] <Philantrop>	deathwing00, jmbsvicetto: Can you come up with a good text together? 
-[Do Mär 6 2008] [21:21:04] <jmbsvicetto>	gentoofan23: that's gentoo-pr ;)
-[Do Mär 6 2008] [21:21:11] <deathwing00>	Philantrop: sure thing
-[Do Mär 6 2008] [21:21:16] <jmbsvicetto>	Philantrop: I'll work with deathwing00
-[Do Mär 6 2008] [21:21:18] <gentoofan23>	jmbsvicetto: oh, k
-[Do Mär 6 2008] [21:21:26] <deathwing00>	jmbsvicetto: right after the meeting would be a good timing for me
-[Do Mär 6 2008] [21:21:46] <Philantrop>	jmbsvicetto, deathwing00: Thanks, great! Once you're done, please mail it to kde@ so that we all can review it. Agreed?
-[Do Mär 6 2008] [21:21:57] <deathwing00>	Philantrop: agreed
-[Do Mär 6 2008] [21:21:58] <jmbsvicetto>	deathwing00: If you could give me 30 minutes to have dinner, my stoamach would thank you ;)
-[Do Mär 6 2008] [21:22:07] <deathwing00>	jmbsvicetto: no problem
-[Do Mär 6 2008] [21:22:07] <jmbsvicetto>	Philantrop: sure
-[Do Mär 6 2008] [21:22:23] <jmbsvicetto>	Philantrop: next ?
-[Do Mär 6 2008] [21:22:29] <Philantrop>	Thanks! Anything else on HTs?
-[Do Mär 6 2008] [21:22:50] <gentoofan23>	other than the fact that I have no idea what to do, no ;-)
-[Do Mär 6 2008] [21:23:07] <Philantrop>	gentoofan23: jmbsvicetto and deathwing00 will get you up to speed. *g*
-[Do Mär 6 2008] [21:23:11] <jmbsvicetto>	Philantrop: I don't think so. Not at this moment, at least
-[Do Mär 6 2008] [21:23:18] <jmbsvicetto>	Philantrop: :)
-[Do Mär 6 2008] [21:23:34] <Philantrop>	Ok, anything else on HTs? (Final call.)
-[Do Mär 6 2008] [21:23:54] <Philantrop>	Ok, let's move on to topic 6: 
-[Do Mär 6 2008] [21:23:56] <Philantrop>	6. Lead election:
-[Do Mär 6 2008] [21:23:56] <Philantrop>	During recent recruitments, DevRel informed us that the KDE project should have
-[Do Mär 6 2008] [21:23:56] <Philantrop>	a lead as per GLEP39. Some herd members and other devs contacted Philantrop 
-[Do Mär 6 2008] [21:23:56] <Philantrop>	about it, too, and requested an election. A simple vote on IRC should be held.
-[Do Mär 6 2008] [21:24:01] <deathwing00>	jmbsvicetto: I have to do forums threads as well btw
-[Do Mär 6 2008] [21:24:09] <jmbsvicetto>	ok
-[Do Mär 6 2008] [21:24:35] <jmbsvicetto>	Philantrop: I think it's about time we elect some leads
-[Do Mär 6 2008] [21:25:14] <Philantrop>	jmbsvicetto: Yes, people asked me about that. As most of you know or can imagine, I volunteer. :-)
-[Do Mär 6 2008] [21:25:22] <jmbsvicetto>	Philantrop: That can help, by letting other people know who to talk to
-[Do Mär 6 2008] [21:25:37] <jmbsvicetto>	Philantrop: O'rly? ;)
-[Do Mär 6 2008] [21:25:42] <deathwing00>	haha
-[Do Mär 6 2008] [21:25:51] <jmbsvicetto>	I second your nomination
-[Do Mär 6 2008] [21:26:02] <zlin>	I even vote for Philantrop :)
-[Do Mär 6 2008] [21:26:12] <deathwing00>	Philantrop++
-[Do Mär 6 2008] [21:26:13] <jmbsvicetto>	Philantrop: I sugest we have 2 leads
-[Do Mär 6 2008] [21:26:14] <Ingmar>	Same ;)
-[Do Mär 6 2008] [21:26:27] <gentoofan23>	jmbsvicetto: political power corrupting you? ;-)
-[Do Mär 6 2008] [21:26:49] <jmbsvicetto>	Philantrop: Whether we want an operation and a strategic lead or just a lead and sub-lead, it can help having a failsafe contact
-[Do Mär 6 2008] [21:26:50] <zlin>	jmbsvicetto: why?
-[Do Mär 6 2008] [21:26:50] <deathwing00>	I think jmbsvicetto means lead + sublead, as in former times
-[Do Mär 6 2008] [21:27:03] <jmbsvicetto>	gentoofan23: :)
-[Do Mär 6 2008] [21:27:25] <jmbsvicetto>	zlin: For the failsafe
-[Do Mär 6 2008] [21:27:27] <deathwing00>	Philantrop: I think we concluded that we didn't want to split dutties (op + start), right?
-[Do Mär 6 2008] [21:27:40] <Ingmar>	I don't think we need more than one lead, tbh
-[Do Mär 6 2008] [21:27:52] <zlin>	'dutties (op + start)'?
-[Do Mär 6 2008] [21:28:04] <deathwing00>	op + strat*
-[Do Mär 6 2008] [21:28:10] <Ingmar>	Some of us are more than active enough on irc, that there's always someone quick enough to answer KDE questions etc
-[Do Mär 6 2008] [21:28:14] <deathwing00>	actually it's operation and technical
-[Do Mär 6 2008] [21:28:14] <jmbsvicetto>	Ingmar: What? You just want a lead and an HT lead? :o ;)
-[Do Mär 6 2008] [21:28:16] <zlin>	ahh, and duties. ;)
-[Do Mär 6 2008] [21:28:34] <deathwing00>	zlin: my bad :)
-[Do Mär 6 2008] [21:28:58] <deathwing00>	I propose to vote if we want to have a sublead first, then vote for candidates
-[Do Mär 6 2008] [21:29:03] <Philantrop>	I'm with Ingmar on this - the students among us are around anyway. ;-)
-[Do Mär 6 2008] [21:29:45] <zlin>	I'm with Ingmar on this too.
-[Do Mär 6 2008] [21:29:46] <jmbsvicetto>	zlin: The principle behind the strategic + operational lead, was to have someone concerned with the big picture and another person taking care of the day-to-day
-[Do Mär 6 2008] [21:30:14] <Philantrop>	jmbsvicetto: We all take care of day-to-day stuff. :-)
-[Do Mär 6 2008] [21:30:16] <Ingmar>	Yes, and my point is that day-to-day is more than taken care of
-[Do Mär 6 2008] [21:30:23] <jmbsvicetto>	ok
-[Do Mär 6 2008] [21:30:35] <jmbsvicetto>	If you're happy with just a lead, then I accept that
-[Do Mär 6 2008] [21:30:39] <Philantrop>	Let's vote on the sub-lead, I'd say. Yay/Nay, please.
-[Do Mär 6 2008] [21:30:45] <Ingmar>	not that we can't improve in that, but I don't see a problem, and I don't see your suggestion as a solution ;)
-[Do Mär 6 2008] [21:30:48] <Ingmar>	Nay
-[Do Mär 6 2008] [21:30:49] <jmbsvicetto>	I've already seconded a nomination ;)
-[Do Mär 6 2008] [21:30:49] <deathwing00>	Yay
-[Do Mär 6 2008] [21:30:51] 	 * Philantrop votes nay
-[Do Mär 6 2008] [21:30:54] <zlin>	Nay
-[Do Mär 6 2008] [21:31:02] <jmbsvicetto>	Yay
-[Do Mär 6 2008] [21:31:17] 	 * cryos|laptop abstains
-[Do Mär 6 2008] [21:31:17] <jmbsvicetto>	2 Yay - 3 Nay ?
-[Do Mär 6 2008] [21:31:22] <jmbsvicetto>	ctennis: ^^
-[Do Mär 6 2008] [21:31:30] <deathwing00>	masterdriverz: ^^
-[Do Mär 6 2008] [21:31:31] <deathwing00>	hehe
-[Do Mär 6 2008] [21:31:34] 	 * gentoofan23 isn't sure if he can vote...
-[Do Mär 6 2008] [21:31:42] <Ingmar>	You can, if you say nay
-[Do Mär 6 2008] [21:31:43] <deathwing00>	gentoofan23: go on
-[Do Mär 6 2008] [21:31:47] <jmbsvicetto>	Ingmar: lol
-[Do Mär 6 2008] [21:31:54] <gentoofan23>	nay then
-[Do Mär 6 2008] [21:32:02] <zlin>	haha
-[Do Mär 6 2008] [21:32:16] <deathwing00>	I guess, nay passes then
-[Do Mär 6 2008] [21:32:21] <gentoofan23>	honestly, that *was* my opinion :)
-[Do Mär 6 2008] [21:32:43] <Ingmar>	:p
-[Do Mär 6 2008] [21:33:02] <deathwing00>	so, do we want Philantrop as lead? Yay/Nay?
-[Do Mär 6 2008] [21:33:04] <deathwing00>	Yay
-[Do Mär 6 2008] [21:33:05] <ctennis>	yay
-[Do Mär 6 2008] [21:33:09] <zlin>	Yay
-[Do Mär 6 2008] [21:33:10] <ctennis>	yay above too
-[Do Mär 6 2008] [21:33:12] <cryos|laptop>	yay
-[Do Mär 6 2008] [21:33:13] <gentoofan23>	yay
-[Do Mär 6 2008] [21:33:15] <Ingmar>	yay
-[Do Mär 6 2008] [21:33:24] <jmbsvicetto>	Philantrop: To do it the right way, we should open a nomination period and then have a voting period
-[Do Mär 6 2008] [21:33:39] <gentoofan23>	why are we even voting if there is only one nominee? *g*
-[Do Mär 6 2008] [21:33:53] <jmbsvicetto>	ok, if anyone feels comfortable with that, Yay
-[Do Mär 6 2008] [21:33:58] <deathwing00>	gentoofan23: well, if over 50% goes nay, then we have to elect someone else
-[Do Mär 6 2008] [21:34:08] <Ingmar>	If there're any other nominees, I'd suggest them to stand up :)
-[Do Mär 6 2008] [21:34:20] <Ingmar>	Else Idon't see the point of an election, waste of time :)
-[Do Mär 6 2008] [21:34:29] <gentoofan23>	oh, I guess I was likening it to a political election.
-[Do Mär 6 2008] [21:34:29] <deathwing00>	Ingmar: tell devrel
-[Do Mär 6 2008] [21:35:07] <deathwing00>	Philantrop: the sublead thing is 3y - 4n
-[Do Mär 6 2008] [21:35:07] <Ingmar>	So, other candidates?
-[Do Mär 6 2008] [21:35:11] <zlin>	this isn't a political election. we just need the whole team to be comfortable with the chosen lead
-[Do Mär 6 2008] [21:35:31] <Ingmar>	zlin: right :)
-[Do Mär 6 2008] [21:35:54] <jmbsvicetto>	Philantrop: This is another good reason to get gmn and gentoo-pr
-[Do Mär 6 2008] [21:36:05] <deathwing00>	?
-[Do Mär 6 2008] [21:36:17] <jmbsvicetto>	Philantrop: Let people know about our new lead and remind them of kde HTs
-[Do Mär 6 2008] [21:36:29] <jmbsvicetto>	Philantrop: ^
-[Do Mär 6 2008] [21:36:35] <jmbsvicetto>	bah, deathwing00 ^
-[Do Mär 6 2008] [21:36:35] <Philantrop>	jmbsvicetto: Yes, a sec. :-)
-[Do Mär 6 2008] [21:36:37] <deathwing00>	Philantrop: u sure you don't want jmbsvicetto as your sublead?
-[Do Mär 6 2008] [21:36:46] <deathwing00>	jmbsvicetto: noted
-[Do Mär 6 2008] [21:36:51] <jmbsvicetto>	deathwing00: Thanks, but I'm not interested
-[Do Mär 6 2008] [21:37:03] <jmbsvicetto>	deathwing00: If we were to have a sub-lead, I had another in mind
-[Do Mär 6 2008] [21:37:25] <Philantrop>	deathwing00: Well, let's keep things simple - everyone here can still make decisions so you're all sub-leads, IMHO. :)
-[Do Mär 6 2008] [21:37:35] <deathwing00>	hehe
-[Do Mär 6 2008] [21:38:17] <Philantrop>	For verification: sublead vote: 3 "yays", 3 "nays", one abstention, right?
-[Do Mär 6 2008] [21:38:19] <deathwing00>	Philantrop: can you give me the vote counts on sublead y/n/a and lead election y/n/a?
-[Do Mär 6 2008] [21:38:23] <jmbsvicetto>	wheeeeeeeee! I'm one of the 10+ gentoo-kde executive vps^D^D^Dsub-leads ;)
-[Do Mär 6 2008] [21:38:24] <jeeves>	dooooooork
-[Do Mär 6 2008] [21:38:37] <jmbsvicetto>	jeeves: :P
-[Do Mär 6 2008] [21:38:53] <Philantrop>	lead election: 7 yays, no nays, no abstention.
-[Do Mär 6 2008] [21:39:04] <deathwing00>	noted
-[Do Mär 6 2008] [21:39:17] <deathwing00>	sublead is a deadlock then?
-[Do Mär 6 2008] [21:39:44] <tgurr>	let's make it a 3 yays and 4 nays then :)
-[Do Mär 6 2008] [21:40:04] <deathwing00>	noted
-[Do Mär 6 2008] [21:40:08] <jmbsvicetto>	ok
-[Do Mär 6 2008] [21:40:15] <deathwing00>	tgurr: I need your vote on Philantrop :)
-[Do Mär 6 2008] [21:40:32] <tgurr>	yay for this wulf thing ;)
-[Do Mär 6 2008] [21:40:42] <deathwing00>	done with that
-[Do Mär 6 2008] [21:41:02] <deathwing00>	Philantrop: you have been elected as KDE lead, my congratulations
-[Do Mär 6 2008] [21:41:13] <deathwing00>	Philantrop: copy-paste your speech here
-[Do Mär 6 2008] [21:41:14] <Philantrop>	Thanks, guys. :-)
-[Do Mär 6 2008] [21:41:17] 	 * deathwing00 grins
-[Do Mär 6 2008] [21:41:44] <Philantrop>	I have no speech and I don't want to waste your time so just let me thank my grand-parents, my parents, my wife, my children, my pet... ;-)
-[Do Mär 6 2008] [21:41:54] <Philantrop>	;-))
-[Do Mär 6 2008] [21:41:58] <deathwing00>	next issue
-[Do Mär 6 2008] [21:42:10] <Philantrop>	Topic 7 - Review of the project page.
-[Do Mär 6 2008] [21:42:28] <Philantrop>	Apart from the lead thing - what do we need to update=?
-[Do Mär 6 2008] [21:42:37] <deathwing00>	kde-pr could take care of it if you want
-[Do Mär 6 2008] [21:42:40] <gentoofan23>	lots of kde 3.5.7 stuff.
-[Do Mär 6 2008] [21:42:47] <jmbsvicetto>	stable version + testing version and status of kde4
-[Do Mär 6 2008] [21:42:52] <gentoofan23>	I have a cvs checkout here, I could update things to a semi-sane state
-[Do Mär 6 2008] [21:43:14] <Ingmar>	That'd be nice
-[Do Mär 6 2008] [21:43:16] <zlin>	kde-pr?
-[Do Mär 6 2008] [21:43:36] <deathwing00>	kde-pr: just invented subproject
-[Do Mär 6 2008] [21:43:47] <Philantrop>	gentoofan23, deathwing00: How about the two of you do it together?
-[Do Mär 6 2008] [21:43:49] <zlin>	who volunteered? :>
-[Do Mär 6 2008] [21:44:12] <deathwing00>	yeah, I am already asuming these duties
-[Do Mär 6 2008] [21:44:15] <gentoofan23>	deathwing00: that means you are an indirect sublead :)
-[Do Mär 6 2008] [21:44:24] <deathwing00>	gentoofan23: you mean a monkey
-[Do Mär 6 2008] [21:44:40] <deathwing00>	hehe
-[Do Mär 6 2008] [21:44:44] <gentoofan23>	deathwing00: well, the two   can be related :)
-[Do Mär 6 2008] [21:44:55] 	 * cryos|laptop has to go - duty calls
-[Do Mär 6 2008] [21:45:00] <cryos|laptop>	Congrats Philantrop :D
-[Do Mär 6 2008] [21:45:02] <Philantrop>	gentoofan23, deathwing00: Can I take that for a "yes"?
-[Do Mär 6 2008] [21:45:07] <Ingmar>	cryos|laptop: laters :)
-[Do Mär 6 2008] [21:45:12] <Philantrop>	cryos|laptop: Thanks and thanks for having been here! 
-[Do Mär 6 2008] [21:45:15] <gentoofan23>	Philantrop: sure. ;)
-[Do Mär 6 2008] [21:45:33] <deathwing00>	Philantrop: affirmative, I'll take care of everything that needs to be spread to the public opinion everyone likes, with the help of everyone who likes
-[Do Mär 6 2008] [21:45:46] <Philantrop>	gentoofan23, deathwing00: Can you do it till the next meeting (next month)?
-[Do Mär 6 2008] [21:45:51] <deathwing00>	cryos|laptop: thank you for sparing your time :)
-[Do Mär 6 2008] [21:46:18] <deathwing00>	Philantrop: when is the next meeting? tomorrow?
-[Do Mär 6 2008] [21:46:28] <Philantrop>	deathwing00: next month. :-)
-[Do Mär 6 2008] [21:46:32] <gentoofan23>	Philantrop: probably.
-[Do Mär 6 2008] [21:46:38] <gentoofan23>	I already am editing a few things.
-[Do Mär 6 2008] [21:46:49] <deathwing00>	will do
-[Do Mär 6 2008] [21:46:55] <gentoofan23>	I'll send any patches to kde@ for review
-[Do Mär 6 2008] [21:47:04] <jmbsvicetto>	Philantrop: What are we missing?
-[Do Mär 6 2008] [21:47:21] <Philantrop>	gentoofan23, deathwing00: Ok, thanks! :-) And, yes, please, mail it to kde@.
-[Do Mär 6 2008] [21:47:25] <jmbsvicetto>	Philantrop: I'm being poked to have dinner
-[Do Mär 6 2008] [21:47:44] <Philantrop>	jmbsvicetto: Missing? And poked by whom? :-)
-[Do Mär 6 2008] [21:47:46] <deathwing00>	jmbsvicetto: meet you here in 35 minutes
-[Do Mär 6 2008] [21:48:04] <jmbsvicetto>	Philantrop: What other points? I'm at my parents house
-[Do Mär 6 2008] [21:48:14] <deathwing00>	gentoofan23: can we have talk about it after the meeting?
-[Do Mär 6 2008] [21:48:18] <Philantrop>	jmbsvicetto: Misc and next meeting date. :-)
-[Do Mär 6 2008] [21:48:29] <gentoofan23>	deathwing00: uh, maybe. I might have to go after the meeting though
-[Do Mär 6 2008] [21:48:32] <Philantrop>	jmbsvicetto: Nothing very special, I think. :-)
-[Do Mär 6 2008] [21:48:37] <jmbsvicetto>	ok
-[Do Mär 6 2008] [21:48:42] Quit	orzelf has left this server (Remote closed the connection).
-[Do Mär 6 2008] [21:48:51] <jmbsvicetto>	I'll try to poke in a few minutes
-[Do Mär 6 2008] [21:49:25] <Philantrop>	deathwing00, gentoofan23: 3, 4, 8, 9 of kde.gentoo.org need to updated, I think. :-)
-[Do Mär 6 2008] [21:49:43] <deathwing00>	Philantrop: noted
-[Do Mär 6 2008] [21:49:46] <gentoofan23>	what do you mean by all those numbers?
-[Do Mär 6 2008] [21:49:54] <Philantrop>	gentoofan23: The headlines. :-)
-[Do Mär 6 2008] [21:50:01] <gentoofan23>	oh, noted
-[Do Mär 6 2008] [21:50:16] <Philantrop>	Ok, anything else about the project page?
-[Do Mär 6 2008] [21:50:31] <zlin>	and of course we are here if you need additional info to write it... :)
-[Do Mär 6 2008] [21:51:00] <gentoofan23>	just a reminder to someone with cvs access to update proj/en/desktop/ with Philantrop as the Lead of the KDE project
-[Do Mär 6 2008] [21:51:12] <gentoofan23>	should be a one-liner
-[Do Mär 6 2008] [21:51:20] <gentoofan23>	zlin: noted, thanks!
-[Do Mär 6 2008] [21:51:42] <Philantrop>	Anything else about the project page? (Final call.)
-[Do Mär 6 2008] [21:51:56] <deathwing00>	zlin: :)
-[Do Mär 6 2008] [21:52:11] <Philantrop>	Topic 8 - Miscellaneous
-[Do Mär 6 2008] [21:52:14] <berniyh>	gentoofan23: write a paragraph, then it looks like it is important ;)
-[Do Mär 6 2008] [21:52:33] <Philantrop>	Anyone with anything to bring up?
-[Do Mär 6 2008] [21:53:18] <Philantrop>	Ok, I have one point - as he hinted at earlier, deathwing00 kindly volunteered to help with spreading the news about the Gentoo KDE project. I'd like to take up this offer. :-)
-[Do Mär 6 2008] [21:53:25] <deathwing00>	oh
-[Do Mär 6 2008] [21:53:25] <gentoofan23>	oh, what about #5 in index.xml? what is the status on monthly meetings?
-[Do Mär 6 2008] [21:53:28] <deathwing00>	let me interrupt
-[Do Mär 6 2008] [21:54:01] <deathwing00>	Philantrop: gentoofan23 made me notice that we could create a new section about meetings, with dates, sumary and logs
-[Do Mär 6 2008] [21:54:02] <Philantrop>	gentoofan23: We'll resume that. :-)
-[Do Mär 6 2008] [21:54:33] <genstef>	kde herd meeting?
-[Do Mär 6 2008] [21:54:33] <deathwing00>	summary*
-[Do Mär 6 2008] [21:54:33] <Philantrop>	deathwing00: Yes, we should updated section 5. I'd like to have monthly meetings again.
-[Do Mär 6 2008] [21:54:34] <genstef>	;-)
-[Do Mär 6 2008] [21:54:40] <Philantrop>	genstef: Welcome! :-)
-[Do Mär 6 2008] [21:54:41] <gentoofan23>	right.
-[Do Mär 6 2008] [21:54:45] <deathwing00>	hi genstef
-[Do Mär 6 2008] [21:55:04] <deathwing00>	Philantrop: noted :)
-[Do Mär 6 2008] [21:55:15] <Philantrop>	Anything else for topic 8 - Miscellaneous?
-[Do Mär 6 2008] [21:55:25] <gentoofan23>	one thing to note is that the first saturday of every month is Bugday, not sure if that will make any conflicts.
-[Do Mär 6 2008] [21:55:34] <eroyf>	bugday is dead
-[Do Mär 6 2008] [21:55:47] <deathwing00>	eroyf: don't blame me plz :)
-[Do Mär 6 2008] [21:55:52] <eroyf>	not your fault
-[Do Mär 6 2008] [21:55:58] <Philantrop>	gentoofan23: Oh, right, most people turned out to have no time during the weekend. What's best for everyone here?
-[Do Mär 6 2008] [21:55:59] <eroyf>	more my fault
-[Do Mär 6 2008] [21:56:13] <deathwing00>	Philantrop: why not like today?
-[Do Mär 6 2008] [21:56:16] <Philantrop>	Is Thursday good for everyone?
-[Do Mär 6 2008] [21:56:23] <gentoofan23>	Well, it is probably best for me
-[Do Mär 6 2008] [21:56:29] <gentoofan23>	Sundays are not very good
-[Do Mär 6 2008] [21:56:41] <gentoofan23>	Thursday afternoons are good, usually
-[Do Mär 6 2008] [21:57:14] <Philantrop>	I like Thursdays, too. :-)
-[Do Mär 6 2008] [21:57:38] <zlin>	thursday is great
-[Do Mär 6 2008] [21:57:49] <Philantrop>	Anyone *against* (!) choosing Thursday?
-[Do Mär 6 2008] [21:57:53] <Ingmar>	I prefer thursday over friday at least
-[Do Mär 6 2008] [21:58:13] 	 * Philantrop hums "It's just another manic Thursday"... ;-)
-[Do Mär 6 2008] [21:58:18] <gentoofan23>	anyone for Mondays? *g*
-[Do Mär 6 2008] [21:58:33] <Philantrop>	Thursday it is. :-)
-[Do Mär 6 2008] [21:58:44] <deathwing00>	PR: noted
-[Do Mär 6 2008] [21:58:52] <Philantrop>	Second one, I'd say. Objections?
-[Do Mär 6 2008] [21:59:07] <deathwing00>	first thursday of every month
-[Do Mär 6 2008] [21:59:31] <Philantrop>	Ok, first. Objections?
-[Do Mär 6 2008] [21:59:42] <Philantrop>	Perfect. *g* Anything else for topic 8 - Miscellaneous?
-[Do Mär 6 2008] [22:00:07] <deathwing00>	can we go now? there's so much to do... *g*
-[Do Mär 6 2008] [22:00:12] <genstef>	btw, I am at Cebit tomorrow :-)
-[Do Mär 6 2008] [22:00:17] Join	zsz has joined this channel (n=zsz@sa-184-64.saturn.infonet.ee).
-[Do Mär 6 2008] [22:00:18] <Philantrop>	Ok, guys, final topic - Date of the next meeting and closing.
-[Do Mär 6 2008] [22:00:19] <gentoofan23>	well, I'm out, later everyone
-[Do Mär 6 2008] [22:00:19] <genstef>	eh on the weekend
-[Do Mär 6 2008] [22:00:21] <zlin>	second thursday is council meetings. not sure if that's a pro or a con though. :>
-[Do Mär 6 2008] [22:00:24] <gentoofan23>	Congrats, Philantrop
-[Do Mär 6 2008] [22:00:40] <Philantrop>	zlin: Oh, right. Then it's really first. :-)
-[Do Mär 6 2008] [22:00:52] <deathwing00>	yes
-[Do Mär 6 2008] [22:00:57] <genstef>	gentoofan23: goodbye :-)
-[Do Mär 6 2008] [22:01:04] <Philantrop>	Last topic: Date of the next meeting and closing.
-[Do Mär 6 2008] [22:01:11] Quit	gentoofan23 has left this server (Client Quit).
-[Do Mär 6 2008] [22:01:16] <Philantrop>	April, 3rd, 2008.
-[Do Mär 6 2008] [22:01:30] 	 * zlin acks
-[Do Mär 6 2008] [22:01:33] <deathwing00>	noted
-[Do Mär 6 2008] [22:01:43] <brot>	:)
-[Do Mär 6 2008] [22:01:44] <Philantrop>	Anything else, guys? :-)
-[Do Mär 6 2008] [22:01:50] Topic	Ingmar sets the channel topic to "KDE 4.0 guide: http://tinyurl.com/27tbt5 | KDE herd meeting (april 3rd, 2008, 19:30 UTC, here). Agenda: http://tinyurl.com/2hhsvc | Problems upgrading to stable KDE 3.5.8? http://tinyurl.com/yqk4le | http://dev.gentoo.org/~masterdriverz/kde-help.txt | KDE Bugs: http://tinyurl.com/3bpdlv | If we're too quiet try #kde | KDE4 live ebuilds? -> "kde" overlay and #genkdesvn. | KDE 4 doesn't work with qt-4.4 *yet*".
-[Do Mär 6 2008] [22:01:51] <brot>	yes.
-[Do Mär 6 2008] [22:02:05] <brot>	you missed to say that you all are doing a great job.
-[Do Mär 6 2008] [22:02:26] <ctennis>	Hats off to the qt4 beta1 folks
-[Do Mär 6 2008] [22:02:38] <Philantrop>	No, that's closing and that's what I'm doing now: Thanks for all your great work, guys! It's a great pleasure to work with you! :-)
-[Do Mär 6 2008] [22:03:00] <berniyh>	ctennis: you mean "heads off" ;-)
-[Do Mär 6 2008] [22:03:08] <ctennis>	that too!
-[Do Mär 6 2008] [22:03:33] Quit	mark_alec has left this server ("Konversation terminated!").
-[Do Mär 6 2008] [22:03:35] <Philantrop>	ctennis: And it's nice to have one of the grumpy old men back on IRC. ;-)
-[Do Mär 6 2008] [22:03:47] <deathwing00>	:)
-[Do Mär 6 2008] [22:03:58] <ctennis>	heh
-[Do Mär 6 2008] [22:04:07] <ctennis>	I wish I had more time to play
-[Do Mär 6 2008] [22:04:28] <ctennis>	but it seems like there's no problem  in picking up my slack
-[Do Mär 6 2008] [22:04:34] <deathwing00>	:)
-[Do Mär 6 2008] [22:04:34] <Philantrop>	Ok, guys, this meeting is now officially closed! :-)
-[Do Mär 6 2008] [22:04:46] 	 * deathwing00 cheers at the new lead
-[Do Mär 6 2008] [22:04:56] <berniyh>	ctennis: with qt-4.4?
-[Do Mär 6 2008] [22:04:57] <zlin>	ctennis: :)
-[Do Mär 6 2008] [22:04:58] <Philantrop>	ctennis: Oh, you should have seen Ingmar and zlin swear about Qt's build system sometimes... ;-)
-[Do Mär 6 2008] [22:05:11] 	 * berniyh nods
-[Do Mär 6 2008] [22:05:13] <zlin>	we're still swearing.. ;)
-[Do Mär 6 2008] [22:05:23] <Philantrop>	I'll mail the log and summary to kde@. :-)
-[Do Mär 6 2008] [22:05:46] <deathwing00>	Philantrop: I'll reuse it :)
-[Do Mär 6 2008] [22:06:04] <Philantrop>	deathwing00: That was my dark intention. :-)
-[Do Mär 6 2008] [22:06:21] <deathwing00>	:)
-[Do Mär 6 2008] [22:07:04] <keytoaster>	okay, zlin forced me to say that I vote for philantrop and against a sub-lead
-[Do Mär 6 2008] [22:07:37] <Philantrop>	LOL
-[Do Mär 6 2008] [22:07:37] <keytoaster>	err
-[Do Mär 6 2008] [22:07:44] <keytoaster>	s/.*I vote/I vote/
-[Do Mär 6 2008] [22:07:52] <deathwing00>	keytoaster: noted
-[Do Mär 6 2008] [22:09:35] <brot>	ehrm, when will the 4.0.2 ebuilds be in portage ?
-[Do Mär 6 2008] [22:09:44] <deathwing00>	Philantrop: I'll post the most interesting things on our forums btw :)
-[Do Mär 6 2008] [22:09:49] 	 * brot ducks
-[Do Mär 6 2008] [22:10:09] <Philantrop>	deathwing00: Thanks! :-) Please let me know the link. :-)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20081204.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20081204.txt
deleted file mode 100644
index e4c2b609bd..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20081204.txt
+++ /dev/null
@@ -1,641 +0,0 @@
-2008 Dec 04 20:01:04  <scarabeus> http://dev.gentoo.org/~scarabeus/kde_meeting0812.txt
-2008 Dec 04 20:01:11  <scarabeus> time is here
-2008 Dec 04 20:01:13  <scarabeus> so who is around?
-2008 Dec 04 20:01:23  -*- tampakrap 
-2008 Dec 04 20:01:26  -*- bonsaikitten 
-2008 Dec 04 20:01:43  <scarabeus> !herd kde
-2008 Dec 04 20:01:44  <Willikins> (kde) caleb, carlo, cryos, deathwing00, genstef, jmbsvicetto, keytoaster, mattepiu, scarabeus, tgurr
-2008 Dec 04 20:01:54  <scarabeus> guys you should all show up :]
-2008 Dec 04 20:01:54  -*- krytzz 
-2008 Dec 04 20:02:01  <keytoaster> hi there!
-2008 Dec 04 20:02:22  -*- jmbsvicetto 
-2008 Dec 04 20:02:40  <scarabeus> krytzz, Sput: you two around?
-2008 Dec 04 20:02:42  -*- cryos|work is here
-2008 Dec 04 20:02:49  <krytzz> yes
-2008 Dec 04 20:03:20  <scarabeus> ok i think that is most we can get, any words from others, stating that they show up too?
-2008 Dec 04 20:03:35  <jmbsvicetto> scarabeus: No idea
-2008 Dec 04 20:03:49  <bonsaikitten> I guess we should let their backlog do its work ;)
-2008 Dec 04 20:04:02  <jmbsvicetto> scarabeus: About your agenda, we should start with a "simple" point - who is still working / willing to work with KDE 3.5
-2008 Dec 04 20:04:10  <tampakrap> me
-2008 Dec 04 20:04:15  <jmbsvicetto> bonsaikitten: That doesn't work with caleb and carlo ;)
-2008 Dec 04 20:04:28  <cryos|work> I am somewhat, but with limited time...
-2008 Dec 04 20:04:31  <bonsaikitten> as long as it is only ebuild maintenance and not C++ stabbing I'm willing to keep it alive
-2008 Dec 04 20:04:41  <bonsaikitten> but I have no interest in 3.5 anymore :)
-2008 Dec 04 20:04:48  <tampakrap> i said i still use kde3 in my main desktop and wanted to have various tests about that and check bugs of course
-2008 Dec 04 20:04:54  <tampakrap> but i was busy with the quiz
-2008 Dec 04 20:04:55  -*- cryos|work has waning interest in it...
-2008 Dec 04 20:05:18  <bonsaikitten> our users want it, so those primitives have to be kept happy ;)
-2008 Dec 04 20:05:41  <scarabeus> yes i would say it is requirement to have kde3 around until kde4.3
-2008 Dec 04 20:05:42  --> MartyMcFly (n=martin@dslb-088-064-190-153.pools.arcor-ip.net) has joined #gentoo-kde
-2008 Dec 04 20:06:00  <bonsaikitten> maybe even longer. if 3.5 is stable enough maintenance should be cheap
-2008 Dec 04 20:06:01  <krytzz> yes
-2008 Dec 04 20:06:03  <jmbsvicetto> I'm not saying we should drop 3.5, I'm asking who is willing to keep it alive ;)
-2008 Dec 04 20:06:05  <cryos|work> Quite probably, but it is essentially dead upstream.
-2008 Dec 04 20:06:07  <scarabeus> jkt|: maybe you will be interested in this too
-2008 Dec 04 20:06:20  -=- hwoarang is now known as hwo[a]rang
-2008 Dec 04 20:06:25  <cryos|work> I will do what I can to help.
-2008 Dec 04 20:06:28  <jmbsvicetto> Also, who is willing to work on the issues caused by the mixing of 3.5 with 4
-2008 Dec 04 20:06:44  <tampakrap> me :)
-2008 Dec 04 20:06:44  <cryos|work> I have noted many distros already dropping it in new releases. Just keeping unported apps around.
-2008 Dec 04 20:07:08  <scarabeus> cryos|work: people would hate us, kde4 is not yet ready, even i miss some features
-2008 Dec 04 20:07:10  <bonsaikitten> I guess all of us will be hybrid users as noone goes back to a 3.5 desktop anymore :)
-2008 Dec 04 20:07:16  <cryos|work> I will help when I can, I think I may have neglected to pick up all the pieces...
-2008 Dec 04 20:07:34  --> reavertm (n=maciek@bcv18.neoplus.adsl.tpnet.pl) has joined #gentoo-kde
-2008 Dec 04 20:07:34  <bonsaikitten> cryos|work: life happened. don't beat yourself up for that :)
-2008 Dec 04 20:07:48  <cryos|work> scarabeus: I am not talking about dropping it, I am however pointing out the deadness of upstream in that sense and what other distros are tending to do.
-2008 Dec 04 20:08:08  <scarabeus> i understand.
-2008 Dec 04 20:08:12  <cryos|work> Thanks bonsaikitten ;-)
-2008 Dec 04 20:08:13  <reavertm> (if I'm out again it means my hardware is failing again, don't bother)
-2008 Dec 04 20:08:17  <-- duog (n=doug@78-86-178-196.zone2.bethere.co.uk) has quit (Remote closed the connection)
-2008 Dec 04 20:08:22  <cryos|work> We should keep an eye on what is happening elsewhere.
-2008 Dec 04 20:08:22  -=- Mode #gentoo-kde [+v reavertm] by scarabeus
-2008 Dec 04 20:08:35  <bonsaikitten> so we'll keep it alive, but there's a good chance we won't give it high priority
-2008 Dec 04 20:09:03  <scarabeus> agreed, on low priority i think we can handle this, and we should be closing up enhancement request for kde3
-2008 Dec 04 20:09:10  <scarabeus> since it would be just pointless work
-2008 Dec 04 20:09:24  <-- hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has quit (Read error: 110 (Connection timed out))
-2008 Dec 04 20:09:42  <bonsaikitten> mostly agree
-2008 Dec 04 20:09:53  <reavertm> kde page stated along with some kde4 release announcement: "Don't look back" :)
-2008 Dec 04 20:09:55  <tampakrap> after all kde4.2 is close and will be stable enough
-2008 Dec 04 20:10:31  <scarabeus> ok so lets mark kde3 as work for cryos and tampakrap, i think you two can talk out what is needed on that field
-2008 Dec 04 20:10:38  <scarabeus> anyone else willing to jump on kde3?
-2008 Dec 04 20:10:57  <tampakrap> i don't think we need more people
-2008 Dec 04 20:11:05  <tampakrap> let's focus on kde4 "the future"
-2008 Dec 04 20:11:09  <jmbsvicetto> cryos|work: Yes, a dead upstream (3.5) and their lack of work to keep more than one version around are the most important cause of the open bugs - imho
-2008 Dec 04 20:11:43  <-- St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has quit ("http://quassel-irc.org - Chat comfortably. Anywhere.")
-2008 Dec 04 20:11:49  <cryos|work> jmbsvicetto: Certainly, and so the distros are forced to move along with them unless they have considerable resources.
-2008 Dec 04 20:11:55  --> St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has joined #gentoo-kde
-2008 Dec 04 20:12:01  <reavertm> well, upstream simply has no manpower to maintaint both
-2008 Dec 04 20:12:07  <bonsaikitten> cryos|work: never underestimate gentoo users ;)
-2008 Dec 04 20:12:07  <cryos|work> There was some talk of a distro maintained patch set but I haven't seen mention of it recently.
-2008 Dec 04 20:12:24  <scarabeus> cryos|work: ask arch linux team
-2008 Dec 04 20:12:25  <jmbsvicetto> cryos|work: For 3.5?
-2008 Dec 04 20:12:31  <scarabeus> they have probably best kde3 team around
-2008 Dec 04 20:12:33  <scarabeus> currently
-2008 Dec 04 20:12:43  <scarabeus> their kdemod is epic
-2008 Dec 04 20:13:06  <St_MPA3b> htmlhandbook provides whole help or only some additional files?
-2008 Dec 04 20:13:20  <scarabeus> St_MPA3b: whole help
-2008 Dec 04 20:13:33  <St_MPA3b> scarabeus: thanks
-2008 Dec 04 20:13:55  <jmbsvicetto> scarabeus: talking about htmlhandbook, I ended up not moving it away from ebuilds and into the eclass :\
-2008 Dec 04 20:13:57  <St_MPA3b> scarabeus: and there are currently no file collisions if htmlhandbook is turned off?
-2008 Dec 04 20:15:11  <St_MPA3b> in @kde-live
-2008 Dec 04 20:15:30  <scarabeus> jmbsvicetto: well that goes for next point of meeting
-2008 Dec 04 20:15:33  <scarabeus> kde4 eclasses
-2008 Dec 04 20:15:40  <scarabeus> i heavily rewrote them
-2008 Dec 04 20:15:48  <scarabeus> applied some suggestions from jmbsvicetto
-2008 Dec 04 20:15:53  <reavertm> (again?)
-2008 Dec 04 20:15:55  --> breiti (n=breiti@p5DD69917.dip0.t-ipconnect.de) has joined #gentoo-kde
-2008 Dec 04 20:15:57  <scarabeus> any moar points to them
-2008 Dec 04 20:16:04  <St_MPA3b> when there will be commit?
-2008 Dec 04 20:16:13  <scarabeus> reavertm: they are still the same, it was not yet accepted.
-2008 Dec 04 20:16:52  <cryos|work> So what are the main changes made?
-2008 Dec 04 20:17:12  <scarabeus> mostly we allow dynamic detection for kde4
-2008 Dec 04 20:17:23  <scarabeus> so apps can work with kde4.1 and kde4.2 and live
-2008 Dec 04 20:17:25  <scarabeus> no matter what
-2008 Dec 04 20:17:32  <St_MPA3b> nice
-2008 Dec 04 20:17:32  <scarabeus> eclasses handles all deps correctly
-2008 Dec 04 20:17:40  <scarabeus> also i removed most of not required code
-2008 Dec 04 20:17:41  <cryos|work> Which one are they linking too/building against?
-2008 Dec 04 20:17:45  <jmbsvicetto> This is a bad thing(tm) in design, but I don't have a better alternative
-2008 Dec 04 20:18:21  <scarabeus> cryos|work: well now you can specify which kde it needs as minimal and then specify search order for other kde versions
-2008 Dec 04 20:18:26  <scarabeus> basicly it preffers -kdeprefix
-2008 Dec 04 20:18:34  <reavertm> (actually one guy had problems with updating from 4.1.2 to 4.1.3 with -kdeprefix using portage eclasses and kde-crazy ones didn't help
-2008 Dec 04 20:18:45  <cryos|work> If they build/link against the latest version installed, they may not link to an earlier version, if it builds against old that doesn't have new symbols it won't compile.
-2008 Dec 04 20:18:46  <reavertm> it may still need some checks
-2008 Dec 04 20:19:12  <scarabeus> cryos|work: that all can be ebuld specified
-2008 Dec 04 20:19:21  <-- mx-tvt (n=costa@175.230.54.77.rev.vodafone.pt) has quit (Remote closed the connection)
-2008 Dec 04 20:19:23  <cryos|work> That is why I have always erred on the side of saying this is possible but a support nightmare.
-2008 Dec 04 20:19:37  <scarabeus> reavertm: he had fucked up kdesvn eclasses i guess, since we used that slot loong ago
-2008 Dec 04 20:19:41  <cryos|work> If it seems to work that is great though.
-2008 Dec 04 20:19:55  <scarabeus> yeah it works for all overlay guys
-2008 Dec 04 20:20:06  <scarabeus> and also my eclass supports koffice
-2008 Dec 04 20:20:07  <cryos|work> I think in general they should build/link against oldest installed version that satisfies the deps.
-2008 Dec 04 20:20:13  <scarabeus> which i can maintain with bonsaikittens help
-2008 Dec 04 20:20:17  <scarabeus> if he is still interested
-2008 Dec 04 20:20:19  <cryos|work> If KDE devs did their job well it will link to the latest version.
-2008 Dec 04 20:20:21  <scarabeus> koffice2
-2008 Dec 04 20:20:41  <krytzz> i could help there too a little bit
-2008 Dec 04 20:20:41  <scarabeus> cryos|work: that is default behavior
-2008 Dec 04 20:20:42  <cryos|work> So if we are planning on supporting it that should be the default behaviour.
-2008 Dec 04 20:20:52  <cryos|work> That sounds good to me then.
-2008 Dec 04 20:21:00  <jmbsvicetto> scarabeus: There are a few things about get_latest_kdedir. That function shouldn't have hardcoded version strings - they should instead be defined in a var like KDE_SLOTS
-2008 Dec 04 20:21:02  <scarabeus> but dev can specify other order in ebuild
-2008 Dec 04 20:21:31  <cryos|work> OK, but I would discourage them from doing that unless they have an amazing reason to do so.
-2008 Dec 04 20:21:33  <scarabeus> jmbsvicetto: well enjoy its updating :] i will be hapy to see help from others :], i have no idea how to use it best, so i did it this way
-2008 Dec 04 20:21:50  <scarabeus> cryos|work: all written in comments for those variables
-2008 Dec 04 20:21:56  <jmbsvicetto> scarabeus: Yeah, I'll see what I can do about it
-2008 Dec 04 20:22:52  <cryos|work> Sounds fine, we just need to stick to some policies for in tree stuff at least.
-2008 Dec 04 20:23:08  <jmbsvicetto> scarabeus / cryos|work: Most of the issues that we're having (besides the linking to a versioned dir) is that upstream is breaking ABI continuously for KDE4, right?
-2008 Dec 04 20:23:09  <scarabeus> i use it for in tree stuff just fine
-2008 Dec 04 20:23:14  --> NSaibot (n=quassel@i3ED6C704.versanet.de) has joined #gentoo-kde
-2008 Dec 04 20:23:18  <scarabeus> jmbsvicetto: right
-2008 Dec 04 20:23:33  <-- NSaibot (n=quassel@i3ED6C704.versanet.de) has quit (Remote closed the connection)
-2008 Dec 04 20:23:46  <scarabeus> cryos|work: i will run some test tomorow and fix all remaining compatibility problems
-2008 Dec 04 20:24:10  <cryos|work> jmbsvicetto: Yeah, but they promised not to after 4.1. I guess they are failing...
-2008 Dec 04 20:24:23  --> non7top (n=non7top@77.66.156.160) has joined #gentoo-kde
-2008 Dec 04 20:24:25  <jmbsvicetto> Oh, an important point about the eclasses - are we ready to block kde4 eclasses for EAPI-0 and EAPI-1?
-2008 Dec 04 20:24:30  <cryos|work> I am talking at Camp KDE 2009 too - KDE and Gentoo.
-2008 Dec 04 20:24:43  <krytzz> cool ^^
-2008 Dec 04 20:24:47  <scarabeus> i volte for only eapi2
-2008 Dec 04 20:24:54  --> NSaibot (n=quassel@i3ED6C704.versanet.de) has joined #gentoo-kde
-2008 Dec 04 20:24:57  <jmbsvicetto> scarabeus: EAPI-2 or later ;)
-2008 Dec 04 20:25:00  <scarabeus> yes
-2008 Dec 04 20:25:39  <cryos|work> Can we block change the EAPI on an existing in tree e-class? Don't we need to maintain backwards compatibility on eclasses?
-2008 Dec 04 20:26:08  <cryos|work> That is a question as I can't remember what the policy is.
-2008 Dec 04 20:26:09  <scarabeus> cryos|work: well packages will be broken if they use eapi lower than 2 and our eclass even currently
-2008 Dec 04 20:26:13  <scarabeus> so we should block it
-2008 Dec 04 20:26:24  <jmbsvicetto> That would allow us to drop the QT4_BUILT_WITH_USE_CHECK, KDE4_BUILT_WITH_USE_CHECK and friends
-2008 Dec 04 20:26:33  <-- fedux (n=fedux@host157.190-137-19.telecom.net.ar) has quit ("Saliendo")
-2008 Dec 04 20:26:57  <jmbsvicetto> cryos|work: I'll confirm it with zmedico, but iirc the eclasses are now saved to vdb
-2008 Dec 04 20:27:13  <cryos|work> I am just not certain we can do that, but I could be wrong. An eclass that used to work with a version of portage should at least work to uninstall said ebuild.
-2008 Dec 04 20:27:14  <scarabeus> and no eapi1 package currently uses our eclass
-2008 Dec 04 20:27:38  <cryos|work> If the policy has changed due to portage changes then fine, but last I checked it had not.
-2008 Dec 04 20:27:47  <jmbsvicetto> cryos|work: I'll be sure to check it
-2008 Dec 04 20:27:50  <cryos|work> You could leave empty functions there, but they had to remain there.
-2008 Dec 04 20:28:14  <cryos|work> So that it is possible to uninstall the cached ebuild that didn't cache its eclass.
-2008 Dec 04 20:28:16  -*- jmbsvicetto mumbles - versioned eclasses
-2008 Dec 04 20:28:29  -*- cryos|work thinks versioning should be used.
-2008 Dec 04 20:28:29  <jmbsvicetto> cryos|work: understood
-2008 Dec 04 20:28:37  <cryos|work> It would get rid of many of these concerns.
-2008 Dec 04 20:29:00  <scarabeus> ok this could be handled later, jmbsvicetto can i wrote you as man taking care of eapi2only?
-2008 Dec 04 20:29:03  <cryos|work> We have what we have and I didn't want changes to hose peoples systems.
-2008 Dec 04 20:29:59  <-- kaffeedoktor (n=kaffeedo@rps3741.ovh.net) has quit (Remote closed the connection)
-2008 Dec 04 20:30:24  --> kaffeedoktor (n=kaffeedo@rps3741.ovh.net) has joined #gentoo-kde
-2008 Dec 04 20:30:35  <scarabeus> ok for next issue i see is wrong SLOT for our kde4 packages in the tree
-2008 Dec 04 20:30:41  <jmbsvicetto> scarabeus: sure
-2008 Dec 04 20:30:41  <scarabeus> how to deal that
-2008 Dec 04 20:30:51  <scarabeus> i did something that should work for ktorrent
-2008 Dec 04 20:30:59  <krytzz> hm ill have a look
-2008 Dec 04 20:31:01  <scarabeus> but i hope there will be better solution for the others
-2008 Dec 04 20:31:12  <jmbsvicetto> scarabeus: what "wrong" slot?
-2008 Dec 04 20:31:16  <scarabeus> they use 4.1
-2008 Dec 04 20:31:21  -*- cryos|work is confused too.
-2008 Dec 04 20:31:25  <scarabeus> what used to mark kde they work
-2008 Dec 04 20:31:34  <scarabeus> but with new eclasses they should be marked as app version
-2008 Dec 04 20:31:36  <scarabeus> not slot of kde
-2008 Dec 04 20:31:53  <cryos|work> What app version?
-2008 Dec 04 20:32:00  <scarabeus> for example
-2008 Dec 04 20:32:04  <scarabeus> ktorrent has version 3
-2008 Dec 04 20:32:07  <scarabeus> and 2
-2008 Dec 04 20:32:10  <scarabeus> in the tree
-2008 Dec 04 20:32:15  <scarabeus> so 2 is slot:0
-2008 Dec 04 20:32:19  <scarabeus> and 3 is slot:3
-2008 Dec 04 20:32:25  <scarabeus> but now it was slot:4.1
-2008 Dec 04 20:32:28  <jmbsvicetto> cryos|work: I know what he means
-2008 Dec 04 20:32:34  <reavertm> 2 is for kde3?
-2008 Dec 04 20:32:39  <scarabeus> reavertm: yes
-2008 Dec 04 20:32:43  <jmbsvicetto> cryos|work: The code used to apply only for packages in kde-base, that restriction was removed
-2008 Dec 04 20:32:54  <cryos|work> Can the two actually be slotted?
-2008 Dec 04 20:33:02  <jmbsvicetto> That is another issue
-2008 Dec 04 20:33:05  <reavertm> isn't this an issue only for -kdeprefix?
-2008 Dec 04 20:33:08  <cryos|work> Is it wise to remove the restriction?
-2008 Dec 04 20:33:21  <cryos|work> Are they all going into kdeprefix now?
-2008 Dec 04 20:33:22  <scarabeus> cryos|work: yes it is working as charm :]
-2008 Dec 04 20:33:34  <jmbsvicetto> cryos|work: probably not, but it was done to enforce the use of prefix in kde-misc
-2008 Dec 04 20:33:34  <scarabeus> cryos|work: yes all packages sets themself based on kdeprefix
-2008 Dec 04 20:33:50  <reavertm> I mean, if kde3 apps are going to /usr/kde/3.5 soon, there should be no issue anymore
-2008 Dec 04 20:34:20  <jmbsvicetto> reavertm: That means we'll get with the kde3 apps the same issue we currently have with kde4 apps - they stop working after you bump kde version
-2008 Dec 04 20:34:23  <cryos|work> What about with -kdeprefix? They are still good I assume?
-2008 Dec 04 20:34:40  <jmbsvicetto> The slot is changed, but the install location is still /usr
-2008 Dec 04 20:35:01  <reavertm> well, kde3 will be no longer revbumped I'm afraid
-2008 Dec 04 20:35:02  <cryos|work> So they do the funky blocker that allows simulataneous files that collide,
-2008 Dec 04 20:35:15  <jmbsvicetto> cryos|work: yes - that needs to be fixed
-2008 Dec 04 20:35:22  <krytzz> jmbsvicetto hm i thought every future version of ktorrent for example it stays in the 3 slot right?
-2008 Dec 04 20:35:33  <scarabeus> cryos|work: i will give you my list of thoughts for kde3
-2008 Dec 04 20:35:38  <krytzz> and with the other extragear apps too
-2008 Dec 04 20:35:57  <scarabeus> cryos|work: http://dev.gentoo.org/~scarabeus/kde3-misc_packages.txt
-2008 Dec 04 20:36:06  <jmbsvicetto> with scarabeus update yes. It was going to be 4.X without it
-2008 Dec 04 20:36:07  <scarabeus> krytzz: yep
-2008 Dec 04 20:36:12  <cryos|work> If you are installing the app into the kdeprefix then it makes sense for it to share the slot of the prefix dir it goes into.
-2008 Dec 04 20:36:28  <-- deathwing00 (n=deathwin@gentoo/developer/Deathwing00) has quit ("Leaving.")
-2008 Dec 04 20:36:32  <scarabeus> cryos|work: well it can go to -kdeprefix too
-2008 Dec 04 20:36:35  <jmbsvicetto> cryos|work: That was my thought, but now I have my doubts
-2008 Dec 04 20:36:51  <scarabeus> and you cant make dynamic slot
-2008 Dec 04 20:37:03  <jmbsvicetto> cryos|work: amarok stopped working here with 4.1.80 because it was installed with 4.1.3, even though I still have 4.1.3 around
-2008 Dec 04 20:37:07  <scarabeus> sice ktorrent-3.1 now can go intoo 4.1 4.2 and live dirs
-2008 Dec 04 20:37:20  <cryos|work> That is why I have always had my doubts about slotting apps not released with the main KDE modules, you have to make artificial bumps I guess to other packages?
-2008 Dec 04 20:37:40  <cryos|work> How does ktorrent decide which prefix to install to?
-2008 Dec 04 20:37:40  <jmbsvicetto> cryos|work: at this point I really don't know what to do
-2008 Dec 04 20:38:05  <krytzz> :(
-2008 Dec 04 20:38:07  <cryos|work> This scheme sounds really messy, but I haven't been using it and so don't know what to say.
-2008 Dec 04 20:38:16  <jmbsvicetto> cryos|work: One idea that crossed my mind was to install these apps into /usr/kde/apps/${PN}/${PV}
-2008 Dec 04 20:38:24  <reavertm> the easiest would be to allow only one KDE4 installed...
-2008 Dec 04 20:38:41  -*- cryos|work kinda suggested that...
-2008 Dec 04 20:38:48  <jmbsvicetto> but scarabeus tried doing that and couldn't get it working with symlinks
-2008 Dec 04 20:38:58  <scarabeus> yeah i failed there too much
-2008 Dec 04 20:39:03  <scarabeus> it was not working for me
-2008 Dec 04 20:39:10  <cryos|work> Having so many options can be extremely tough to support.
-2008 Dec 04 20:39:13  <scarabeus> feel free to do it again for yourself
-2008 Dec 04 20:39:21  <scarabeus> cryos|work: i know :(
-2008 Dec 04 20:40:06  <cryos|work> That is why many distros choose not to do this, and it has bitten us many times in the past. 3.5 is simpler now due to no more bumps.
-2008 Dec 04 20:40:11  <jmbsvicetto> cryos|work: This is another case were the real solution would be for upstream to think about this and provide a solution for having multiple versions in the same prefix
-2008 Dec 04 20:40:36  <scarabeus> we should try to push versioning on upstream
-2008 Dec 04 20:40:40  <scarabeus> that is not bad idea
-2008 Dec 04 20:40:41  <cryos|work> I agree with you entirely
-2008 Dec 04 20:40:55  <krytzz> has anyone asked for this already?
-2008 Dec 04 20:41:07  <jmbsvicetto> cryos|work: You've talked before with upstream about this, haven't you?
-2008 Dec 04 20:41:12  <cryos|work> I do think having multiple minor versions available to people who do not really know what they are doing is possibly a recipe for failure...
-2008 Dec 04 20:41:28  <cryos|work> jmbsvicetto: Yes, and I will probably talk about it again at Camp KDE in January.
-2008 Dec 04 20:41:48  <cryos|work> Many other distro developers also very much wanted this, and to a degree it works.
-2008 Dec 04 20:41:56  <jmbsvicetto> Didn't you have a presentation you did about this issue?
-2008 Dec 04 20:41:57  <cryos|work> Not to the degree Gentoo would like though.
-2008 Dec 04 20:42:08  <cryos|work> Yes - it is on my blog somewhere.
-2008 Dec 04 20:42:22  <jmbsvicetto> That should be an interesting reading for people in the team
-2008 Dec 04 20:42:49  <-- MartyMcFly (n=martin@dslb-088-064-190-153.pools.arcor-ip.net) has quit (Remote closed the connection)
-2008 Dec 04 20:43:03  <scarabeus> yeah i would like to see it :]
-2008 Dec 04 20:43:23  <krytzz> hm but with -kdeprefix there is no problem then... if the ABI is stable
-2008 Dec 04 20:43:38  <cryos|work> http://blog.cryos.net/archives/146-Gentoo-KDE-Talk-at-aKademy.html
-2008 Dec 04 20:44:58  <scarabeus> ok next point is more nice and all developers are needed: we need some lead, so people can oficialy find one, /me is proposing jmbsvicetto O:P (meantime looking on presentation on second monitor)
-2008 Dec 04 20:45:00  <cryos|work> I will be preparing half of the talk for the KDE and distros talk in January - so let me know if there are things you would like to be raised.
-2008 Dec 04 20:45:46  -*- cryos|work never really saw the need for the hierarchy in small herds, but whatever makes you happy.
-2008 Dec 04 20:46:23  --> Scorcere1 (n=Scorek@77-87-120-128.rev.masterkom.pl) has joined #gentoo-kde
-2008 Dec 04 20:46:28  <cryos|work> The KDE herd didn't have a lead for years and flourished, then dwindled... It is all about building a friendly community (lead or no).
-2008 Dec 04 20:46:58  <jmbsvicetto> I agree with cryos|work about having a friendly community
-2008 Dec 04 20:47:00  <krytzz> i have nothing against it :p
-2008 Dec 04 20:47:05  <scarabeus> :D
-2008 Dec 04 20:47:31  <jmbsvicetto> Oh and I'm not that eager to get the "lead" hat :P
-2008 Dec 04 20:47:32  <scarabeus> i dont mind how this will evolve so i leave this one definetly up to all
-2008 Dec 04 20:47:44  <scarabeus> jmbsvicetto: yeah i am pretty sure of this :D
-2008 Dec 04 20:47:54  <scarabeus> noone wants to be lead i would say
-2008 Dec 04 20:47:56  <tampakrap> i think we should have a leader just as the other herds do
-2008 Dec 04 20:48:05  <tampakrap> not because we need someone to decide
-2008 Dec 04 20:48:16  <jmbsvicetto> A quick note - team and not herd :P
-2008 Dec 04 20:48:27  <jmbsvicetto> We're talking about the people and not about the packages ;)
-2008 Dec 04 20:48:41  <tilya> i will be the queen ;)
-2008 Dec 04 20:48:41  <scarabeus> jmbsvicetto: herd is missused for this for so long...
-2008 Dec 04 20:48:44  --> dagger (n=dagger@piasek.co.uk) has joined #gentoo-kde
-2008 Dec 04 20:49:06  <scarabeus> i think word herd needs redefinition but it is not on todays topic
-2008 Dec 04 20:49:12  -*- cryos|work never got why people were so picky about the words used, is it really a herd of packages? :D
-2008 Dec 04 20:49:34  <krytzz> a bunch of packages
-2008 Dec 04 20:49:35  <scarabeus> ok so no lead for now, when times change jmbsvicetto is first on the row :P
-2008 Dec 04 20:49:41  <krytzz> gentoo kde-bunch-of-people
-2008 Dec 04 20:49:56  <cryos|work> It is work time for me over here, I could do with getting stuff done soon. So I may leave in 5-10 mins.
-2008 Dec 04 20:49:59  <jmbsvicetto> moving on to other not so pleasant topic, I think we need to look at the team members again - afaik, we have people listed in the kde page that haven't done anything kde related for many, many months
-2008 Dec 04 20:50:06  <-- comawhite (n=comawhit@unaffiliated/comawhite) has quit ("Leaving")
-2008 Dec 04 20:50:26  --> tgurr (n=tgurr@gentoo/developer/tgurr) has joined #gentoo-kde
-2008 Dec 04 20:50:26  -=- Mode #gentoo-kde [+o tgurr] by ChanServ
-2008 Dec 04 20:50:36  <jmbsvicetto> Hi tgurr 
-2008 Dec 04 20:50:40  <scarabeus> agreed, we should clean it up, ask everyone if they are willing to do something and so on (does not count for people that are mentioned away)
-2008 Dec 04 20:50:46  <tgurr> jmbsvicetto: hi
-2008 Dec 04 20:50:58  <-- erulabs (n=seandon@net-cf9a4013.noc.impulse.net) has quit ("Leaving.")
-2008 Dec 04 20:51:05  <-- JaMa (n=JaMa@chaos.mk.cvut.cz) has quit (Remote closed the connection)
-2008 Dec 04 20:51:32  <jmbsvicetto> Getting to the same old same, it would help if all the members would be willing to join irc, but I don't have any illusions about getting some people in here
-2008 Dec 04 20:51:50  <scarabeus> jmbsvicetto: are you willing to mail them
-2008 Dec 04 20:52:06  <jmbsvicetto> About being team members, sure?
-2008 Dec 04 20:52:11  <scarabeus> ok
-2008 Dec 04 20:52:16  <scarabeus> i am writing up notes
-2008 Dec 04 20:52:20  <scarabeus> so we have them after end
-2008 Dec 04 20:52:21  <scarabeus> :]
-2008 Dec 04 20:52:38  <scarabeus> about members
-2008 Dec 04 20:52:42  <scarabeus> we have problem in qt herd
-2008 Dec 04 20:52:46  <scarabeus> it is just yngwin 
-2008 Dec 04 20:53:00  <scarabeus> how to get some qt devepoer :]
-2008 Dec 04 20:53:05  <jmbsvicetto> I can even do something better, send a mail to the kde alias and ask everyone for a little introspection and to let us know if they're still part of the team and or want to be part of the team ;)
-2008 Dec 04 20:53:20  <scarabeus> jmbsvicetto: that i leave up to you :]
-2008 Dec 04 20:53:22  <jmbsvicetto> scarabeus: I thought carlo and caleb where still in the team
-2008 Dec 04 20:53:39  <yngwin> they are but they are inactive and non-responsive
-2008 Dec 04 20:53:40  <scarabeus> did you hear/see some commits from them in last month/2
-2008 Dec 04 20:53:41  <jmbsvicetto> scarabeus: with the obvious reservations about the above point
-2008 Dec 04 20:53:56  <jmbsvicetto> yngwin: ok, just wanted to confirm
-2008 Dec 04 20:54:04  <scarabeus> reavertm: maybe you might be interested
-2008 Dec 04 20:54:11  <reavertm> well, no major qt release recently so they may just wait for 4.5
-2008 Dec 04 20:54:21  <jmbsvicetto> yngwin: I'll talk to you about qt
-2008 Dec 04 20:54:22  <reavertm> in qt maintenance a bit?
-2008 Dec 04 20:54:28  <scarabeus> and that reminds me, yngwin should get commit acces to kde-crazy
-2008 Dec 04 20:54:32  <scarabeus> reavertm: yes
-2008 Dec 04 20:54:57  <jmbsvicetto> yngwin: do you have access to kde-testing? If not, you should also have it
-2008 Dec 04 20:54:58  <krytzz> does bonsaikitten have access? :p
-2008 Dec 04 20:55:11  <yngwin> jmbsvicetto: i dont
-2008 Dec 04 20:55:16  <scarabeus> krytzz: silence there! ;D
-2008 Dec 04 20:55:21  <yngwin> unless i do but dont know it 
-2008 Dec 04 20:55:33  <reavertm> hmm, well I can try by forget about Qt from Trolltech svn fro bow - they shit svn only as daily snapshots via rsync
-2008 Dec 04 20:55:37  <jmbsvicetto> bonsaikitten: I forgot to tell you, but robbat2 replied to me earlier saying you should have access now
-2008 Dec 04 20:55:46  <bonsaikitten> jmbsvicetto: ok, let me try :)
-2008 Dec 04 20:55:57  <reavertm> for now^^
-2008 Dec 04 20:55:58  <bonsaikitten> also, phonecall, I kinda missed the last half hour or so
-2008 Dec 04 20:56:01  <jmbsvicetto> ok, my purpose with the kde-* overlays was for everyone on the team to have access to them
-2008 Dec 04 20:56:10  <scarabeus> yeah agreed
-2008 Dec 04 20:56:36  <jmbsvicetto> I initially asked jokey to grant access to everyone at the time in the team. I haven't followed it through, so I'll talk to robbat2 again asking for an update about the current status
-2008 Dec 04 20:56:52  <scarabeus> and i took the liberty and added yngwin to team list on kde page, since it is project page for qt and kde, not only kde, i think i forget to mention that before for that i am ashamed
-2008 Dec 04 20:57:05  <yngwin> ok tnx
-2008 Dec 04 20:57:18  <yngwin> maybe i should get op status here then as well
-2008 Dec 04 20:57:18  <jmbsvicetto> scarabeus: Yes, you're right
-2008 Dec 04 20:57:22  <jmbsvicetto> sure
-2008 Dec 04 20:57:30  <jmbsvicetto> keytoaster: I think it has to be you doing it
-2008 Dec 04 20:57:45  <jmbsvicetto> keytoaster: iirc, we transfered +F to you
-2008 Dec 04 20:58:57  <bonsaikitten> oooh. can has access :D
-2008 Dec 04 20:59:01  <jmbsvicetto> yngwin: seems I was able to grant it to you
-2008 Dec 04 20:59:06  <bonsaikitten> DrEeevil: you fail.
-2008 Dec 04 20:59:08  <-- NSaibot (n=quassel@i3ED6C704.versanet.de) has quit (Remote closed the connection)
-2008 Dec 04 20:59:12  <jmbsvicetto> bonsaikitten: :)
-2008 Dec 04 20:59:32  <scarabeus> ok one more infra thing
-2008 Dec 04 20:59:36  -=- Mode #gentoo-kde [+o yngwin] by jmbsvicetto
-2008 Dec 04 20:59:44  <scarabeus> tampakrap would need normal mentor if he wants to became full dev
-2008 Dec 04 20:59:51  <scarabeus> i am willing to help him with the quiz
-2008 Dec 04 20:59:57  <scarabeus> but someone must oversee
-2008 Dec 04 20:59:59  <scarabeus> who can do that
-2008 Dec 04 21:00:11  <bonsaikitten> I'm too young for that I think
-2008 Dec 04 21:00:14  <scarabeus> end-quiz we are speaking about
-2008 Dec 04 21:00:15  <jmbsvicetto> I'm also willing to help, but I still don't have the 6 months, so I can't mentor
-2008 Dec 04 21:00:16  --> genady12 (n=genady12@87.69.85.204) has joined #gentoo-kde
-2008 Dec 04 21:00:17  <tampakrap> first of all is everyone ok with that?
-2008 Dec 04 21:00:19  <bonsaikitten> my quantum status is confusing
-2008 Dec 04 21:00:31  -*- bonsaikitten is 2 years on, 2 years off ...
-2008 Dec 04 21:00:42  <jmbsvicetto> bonsaikitten: You're *chaotic* ;)
-2008 Dec 04 21:00:44  <scarabeus> bonsaikitten: ;] you are cheating :D
-2008 Dec 04 21:00:47  <krytzz> i am
-2008 Dec 04 21:00:55  <bonsaikitten> so is that 2 years or 2 months now? :)
-2008 Dec 04 21:00:57  --> oc2k1 (n=oc2k1@p5B104618.dip.t-dialin.net) has joined #gentoo-kde
-2008 Dec 04 21:01:16  <jmbsvicetto> bonsaikitten: we need to ask Betelgeuse
-2008 Dec 04 21:01:22  <bonsaikitten> :)
-2008 Dec 04 21:01:39  <bonsaikitten> I think it is better if I stay out of it for a while
-2008 Dec 04 21:01:39  <krytzz> perhaps jokey could do it?
-2008 Dec 04 21:01:54  <jmbsvicetto> krytzz: jokey is away
-2008 Dec 04 21:01:56  <yngwin> i thought jokey was caught up in real life
-2008 Dec 04 21:01:57  <scarabeus> jokay is away
-2008 Dec 04 21:02:01  <krytzz> ok
-2008 Dec 04 21:02:06  <scarabeus> yngwin: you cant do it?
-2008 Dec 04 21:02:19  <yngwin> i can
-2008 Dec 04 21:02:29  <yngwin> although i dont feel guru enough
-2008 Dec 04 21:02:53  <scarabeus> :]
-2008 Dec 04 21:03:07  <bonsaikitten> yngwin: you are guru enough!
-2008 Dec 04 21:03:14  <scarabeus> dont worry, from mine humble PoV you are guru enought
-2008 Dec 04 21:03:16  <yngwin> well, if you say so :)
-2008 Dec 04 21:03:27  <jmbsvicetto> :)
-2008 Dec 04 21:03:36  <tampakrap> thanks :)
-2008 Dec 04 21:03:52  <yngwin> is there a bug for tampakrap's recruitment?
-2008 Dec 04 21:04:01  <tampakrap> no
-2008 Dec 04 21:04:02  <keytoaster> keytoaster: yes you did
-2008 Dec 04 21:04:06  <keytoaster> err
-2008 Dec 04 21:04:08  <-- Scorcerer (n=Scorek@77-87-120-128.rev.masterkom.pl) has quit (Connection timed out)
-2008 Dec 04 21:04:08  -=- Scorcere1 is now known as Scorcerer
-2008 Dec 04 21:04:08  <keytoaster> jmbsvicetto: yes you did
-2008 Dec 04 21:04:21  <scarabeus> yngwin: nope i can create one, i made him HT yesterday
-2008 Dec 04 21:04:27  <yngwin> okay
-2008 Dec 04 21:04:42  <jmbsvicetto> I let it pass, but since scarabeus mentioned the project page, we both applied some changes to the page to integrate KDE4 as a regular release and to update the status of the overlays
-2008 Dec 04 21:04:58  <jmbsvicetto> Don't know if everyone has checked it and whether there's any objection to it
-2008 Dec 04 21:05:03  <yngwin> scarabeus: then i'll second on that, and then we can see what betelgeuse says
-2008 Dec 04 21:05:09  <-- scratch[x] (n=scratch@83.239.148.148) has quit (No route to host)
-2008 Dec 04 21:05:14  <yngwin> tampakrap: kaloriziko ;)
-2008 Dec 04 21:05:23  <tampakrap> wtf?
-2008 Dec 04 21:05:25  <scarabeus> we can do this stuff after meeting, great :]
-2008 Dec 04 21:05:43  <scarabeus> ok last two things per my list
-2008 Dec 04 21:05:46  <scarabeus> first is kde4.2
-2008 Dec 04 21:05:50  <scarabeus> so what shape is it in
-2008 Dec 04 21:05:56  <scarabeus> it is just statusreport for it
-2008 Dec 04 21:06:00  <jmbsvicetto> scarabeus: Good and BAD!!!
-2008 Dec 04 21:06:01  <scarabeus> so speak up kde-crazy people
-2008 Dec 04 21:06:04  <bonsaikitten> I'll take care of them snapshots
-2008 Dec 04 21:06:09  <reavertm> well, it works :)
-2008 Dec 04 21:06:15  <tampakrap> i'll also give priority to snapshots
-2008 Dec 04 21:06:21  <krytzz> plasma crashes often :p
-2008 Dec 04 21:06:22  <yngwin> kde 4.2? its crap. it friggin' needs mysql
-2008 Dec 04 21:06:28  <jmbsvicetto> scarabeus: my keyboard layout is still messed up - but nepomuk and plasma have a better look ;)
-2008 Dec 04 21:06:36  <bonsaikitten> it works quite well for me
-2008 Dec 04 21:06:41  <krytzz> also for me nepomuk is strange
-2008 Dec 04 21:06:46  <bonsaikitten> had a few compile failures, but nothing unexpected
-2008 Dec 04 21:06:54  <reavertm> I guess trunk is way better than snapshots, but... regressions are quite often recently
-2008 Dec 04 21:07:01  <krytzz> but rest is ok
-2008 Dec 04 21:07:02  <reavertm> ebuild-wise - it's pretty mature
-2008 Dec 04 21:07:14  <jmbsvicetto> One important point about snapshots, they can't rely on live packages
-2008 Dec 04 21:07:24  <bonsaikitten> live is in a very good shape, snapshots have been a bit neglected
-2008 Dec 04 21:07:25  <reavertm> but upstream will mess with buildsystem for sure
-2008 Dec 04 21:07:31  -*- bonsaikitten is just digesting them
-2008 Dec 04 21:07:35  <jmbsvicetto> So we need to bug other teams or add new versions/snapshots if required to the overlay/tree
-2008 Dec 04 21:07:50  <krytzz> especially opensync :p
-2008 Dec 04 21:07:55  <scarabeus> opensync is problem
-2008 Dec 04 21:07:57  <scarabeus> currently
-2008 Dec 04 21:08:20  <scarabeus> and also networkmanager, i took liberty of speaking up with rbu on our behalf
-2008 Dec 04 21:08:31  <reavertm> opensync and it;s plugins were problematic with kde3 already
-2008 Dec 04 21:08:34  <scarabeus> and today/tomorow nm-0.7 hit the tree
-2008 Dec 04 21:08:38  <jmbsvicetto> scarabeus: one solution is to try to add an update to kde-crazy overlay until it gets in the tree
-2008 Dec 04 21:08:52  <krytzz> ah nice
-2008 Dec 04 21:08:55  <reavertm> kitchensync is just lame kde3 port
-2008 Dec 04 21:08:59  <jmbsvicetto> scarabeus: rbu has shown interest in getting nm working
-2008 Dec 04 21:09:03  <scarabeus> yes
-2008 Dec 04 21:09:08  <jmbsvicetto> scarabeus: he might need some help with it, though
-2008 Dec 04 21:09:09  <scarabeus> he already made it work
-2008 Dec 04 21:09:17  <scarabeus> jmbsvicetto: well i will ask
-2008 Dec 04 21:09:48  <jmbsvicetto> The GNOME team was also interested in getting 0.7 in the tree, iirc
-2008 Dec 04 21:10:19  <reavertm> yeah, everyone is crazy about those networkmanager desktop applets...
-2008 Dec 04 21:10:42  <bonsaikitten> can we prevent such cross-repo dependencies in the future?
-2008 Dec 04 21:10:54  <jmbsvicetto> I would just love to get some applet that does the eap stuff for me ;)
-2008 Dec 04 21:11:05  <jmbsvicetto> bonsaikitten: what deps?
-2008 Dec 04 21:11:08  <scarabeus> there will be rule for next time all must be on portage/overlay
-2008 Dec 04 21:11:14  <bonsaikitten> like nm 
-2008 Dec 04 21:11:23  <reavertm> like kde4 requiring nm from rbu overlay
-2008 Dec 04 21:11:24  <bonsaikitten> we should have a copy in our repo if that happens
-2008 Dec 04 21:11:31  <jmbsvicetto> yeah, agreed
-2008 Dec 04 21:11:36  <krytzz> hm but this sucks somehow
-2008 Dec 04 21:11:44  <krytzz> if you have both overlays you have the ebuild 2 times
-2008 Dec 04 21:11:50  <jmbsvicetto> at least until we can get Zac to support repo deps ;)
-2008 Dec 04 21:11:50  <krytzz> and you dont know if the 2 differ or something
-2008 Dec 04 21:12:05  <scarabeus> repodeps ;]
-2008 Dec 04 21:12:10  <scarabeus> it sounds llike sam rep band
-2008 Dec 04 21:12:11  <krytzz> also its additional maintenance work
-2008 Dec 04 21:12:25  <tampakrap> talking about overlays i'd like to remind everyone that versioned misc packages go to kde-testing :)
-2008 Dec 04 21:12:35  <jmbsvicetto> krytzz: yes, we should only have them until it gets pushed into the tree
-2008 Dec 04 21:12:36  <reavertm> yeah, i just see GLEP for it being discussed, then presented, then rejected or suspended :P
-2008 Dec 04 21:12:39  <krytzz> ok tampakrap :p
-2008 Dec 04 21:13:02  <scarabeus> ok so what with opensync
-2008 Dec 04 21:13:06  <scarabeus> it is BbD
-2008 Dec 04 21:13:08  <jmbsvicetto> tampakrap: versioned "not known to be broken" misc packages ;)
-2008 Dec 04 21:13:13  <scarabeus> broken by design
-2008 Dec 04 21:13:13  <krytzz> i wouldnt mind with a central gentoo-deps overlay :p
-2008 Dec 04 21:13:30  <bonsaikitten> we call that "the main tree"
-2008 Dec 04 21:13:38  <reavertm> scarabeus you mean opensync akonadi plugin or kitchensync?
-2008 Dec 04 21:13:44  <bonsaikitten> so, how fast are we going to get 4.2 there as ~arch?
-2008 Dec 04 21:13:51  <krytzz> bonsaikitten then stab people to get things faster in there then :p
-2008 Dec 04 21:13:54  <bonsaikitten> and is kde 4.2 a stable candidate?
-2008 Dec 04 21:14:06  <jmbsvicetto> bonsaikitten: I don't think we should get 4.2 in the tree until RC
-2008 Dec 04 21:14:09  <scarabeus> yeah crappy opensync
-2008 Dec 04 21:14:16  <bonsaikitten> krytzz: I'm just cleaning up. If that's not enough go screw yourself counterclockwise ;)
-2008 Dec 04 21:14:24  <jmbsvicetto> bonsaikitten: I would also hard mask the RCs and lift the mask with 4.2
-2008 Dec 04 21:14:25  <tampakrap> i think it is time to have a stable kde4 version
-2008 Dec 04 21:14:31  <bonsaikitten> jmbsvicetto: acceptable
-2008 Dec 04 21:14:48  <reavertm> scarabeus yes, but be more specific, opensync from portage is crappy or kde opensync support?
-2008 Dec 04 21:14:49  <krytzz> i think if the 4.2 progress continues like know it should be great by 4.2.1
-2008 Dec 04 21:14:58  <scarabeus> opensync from portage
-2008 Dec 04 21:14:59  <krytzz> now
-2008 Dec 04 21:14:59  <jmbsvicetto> bonsaikitten: we might however start thinking on moving 4.2 into kde-testing
-2008 Dec 04 21:15:02  <scarabeus> opensync itself
-2008 Dec 04 21:15:09  <jmbsvicetto> bonsaikitten: at least as soon as we take care of the eclasses
-2008 Dec 04 21:15:17  <scarabeus> eclasses first! :D
-2008 Dec 04 21:15:17  <tampakrap> jmbsvicetto: +1
-2008 Dec 04 21:15:34  <jmbsvicetto> and I do think 4.2 should be a stable candidate - let's just see how it works
-2008 Dec 04 21:15:47  <jmbsvicetto> one thing we need to solve quickly is getting 3.5.10 marked stable
-2008 Dec 04 21:16:05  <scarabeus> that is already stated in the summary paper :]
-2008 Dec 04 21:16:08  <reavertm> jmbsvicetto which 4.2? you mean snapshots and revbump as 4.2 and keep them updated along with snaphots from kde-crazy?
-2008 Dec 04 21:16:10  <tampakrap> jmbsvicetto: i'll start working on kde3 right after this meeting
-2008 Dec 04 21:16:18  <reavertm> if yes, then you are crazy ;)
-2008 Dec 04 21:16:33  <tampakrap> why?
-2008 Dec 04 21:16:35  <scarabeus> nope to testing should go only snapshots marked as betaX
-2008 Dec 04 21:16:36  <jmbsvicetto> reavertm: I mean that I think 4.2 snapshots should be moved to testing
-2008 Dec 04 21:16:45  <jmbsvicetto> reavertm: after the eclasses are merged back again
-2008 Dec 04 21:16:49  <scarabeus> snapshot itself i disagree
-2008 Dec 04 21:16:57  <scarabeus> but snapshots for beta1 beta2 rcX
-2008 Dec 04 21:16:58  <scarabeus> yes
-2008 Dec 04 21:17:04  <jmbsvicetto> scarabeus: yes, that's what I mean
-2008 Dec 04 21:17:10  <jmbsvicetto> should have been clearer
-2008 Dec 04 21:17:16  <reavertm> I wouldn't advise that atm - there may be many changes and syncing them between kde-crazy <-> kde-testing ...
-2008 Dec 04 21:17:17  <scarabeus> great then we agree :]
-2008 Dec 04 21:17:34  <scarabeus> reavertm: just delete it and copy from point A to point B
-2008 Dec 04 21:17:39  <jmbsvicetto> reavertm: git cherry-pick ;)
-2008 Dec 04 21:17:41  <scarabeus> it wont harm kittens TM
-2008 Dec 04 21:17:52  <scarabeus> jmbsvicetto: cherry-pick cross repos?
-2008 Dec 04 21:17:56  <jmbsvicetto> yes
-2008 Dec 04 21:17:58  <scarabeus> wow
-2008 Dec 04 21:18:00  <scarabeus> that i didnt know
-2008 Dec 04 21:18:05  <scarabeus> that is even more cooler
-2008 Dec 04 21:18:11  <reavertm> scnaphots are keep sync from live now - and I would just wait until some rc is released, and patched in kde-crazy and then quick revbup and move -> testing
-2008 Dec 04 21:18:28  <jmbsvicetto> scarabeus: hmm, now you're going to force me to test it to be sure I didn't came up with that
-2008 Dec 04 21:18:36  <reavertm> well, if you volunteer to do it :)
-2008 Dec 04 21:19:14  <-- genady12 (n=genady12@87.69.85.204) has quit (Read error: 145 (Connection timed out))
-2008 Dec 04 21:19:15  <scarabeus> ok this can be suspended and handled later
-2008 Dec 04 21:19:20  <jmbsvicetto> reavertm: The idea was to try to have RCs in the tree, so we should try to get something in testing before that
-2008 Dec 04 21:19:21  <scarabeus> now more pain in the ass TM issue
-2008 Dec 04 21:19:25  <scarabeus> mysql
-2008 Dec 04 21:19:28  <scarabeus> whole kde needs it
-2008 Dec 04 21:19:33  <bonsaikitten> aarghl! :)
-2008 Dec 04 21:19:33  <scarabeus> and amarok is chapter itself
-2008 Dec 04 21:19:42  <scarabeus> what to do with it
-2008 Dec 04 21:19:43  <jmbsvicetto> scarabeus: There's only one option here: work with robbat2
-2008 Dec 04 21:19:50  <krytzz> yes... we cant do anything about that :(
-2008 Dec 04 21:19:58  <scarabeus> did you see the eclass
-2008 Dec 04 21:19:58  <reavertm> yes, I agres 4.2 should be in tree asap but moving it to testing only for the sake of having it in kde-testing is bad idea imho
-2008 Dec 04 21:20:01  <krytzz> does he maintain mysql?
-2008 Dec 04 21:20:04  <scarabeus> did? did? i dont like it
-2008 Dec 04 21:20:09  <scarabeus> krytzz: yes he does
-2008 Dec 04 21:20:09  <jmbsvicetto> scarabeus: I've asked him yesterday and he's still waiting for mysql upstream to reply to his request for a dynamic lib for mysql/e
-2008 Dec 04 21:20:17  <reavertm> I've already put my mysql rant in gentoo-dev :P
-2008 Dec 04 21:20:17  <krytzz> ah ok
-2008 Dec 04 21:20:31  <jmbsvicetto> scarabeus: what do you mean?
-2008 Dec 04 21:21:03  <scarabeus> jmbsvicetto: too chaotical too much patches too much crazy
-2008 Dec 04 21:21:11  <scarabeus> but i dunno how is upstream cooperating
-2008 Dec 04 21:21:19  <jmbsvicetto> reavertm: The point of kde-testing is to be the bridge to the tree
-2008 Dec 04 21:21:28  <scarabeus> ok on other hand who is willing to cooperate with robbat2 on that?
-2008 Dec 04 21:21:32  <jmbsvicetto> scarabeus: you mean mysql eclass?
-2008 Dec 04 21:21:37  <scarabeus> jmbsvicetto: ay sir
-2008 Dec 04 21:21:46  <jmbsvicetto> scarabeus: mysql isn't that "simple"
-2008 Dec 04 21:22:05  <jmbsvicetto> scarabeus: And robbat2 if surely one if not the "one" gentoo mysql yoda
-2008 Dec 04 21:22:09  <jmbsvicetto> s/if/is/
-2008 Dec 04 21:22:12  <reavertm> I've seen this eclass and it's.. well.. a bit complex as eclass for one package
-2008 Dec 04 21:22:34  <bonsaikitten> reavertm: it adds a build system to a braindead package ;)
-2008 Dec 04 21:22:39  <jmbsvicetto> scarabeus: I'm willing to work with robbat2 about mysql
-2008 Dec 04 21:22:58  <reavertm> yeah, I heard....
-2008 Dec 04 21:23:09  --> genady12 (n=genady12@87.69.85.204) has joined #gentoo-kde
-2008 Dec 04 21:23:12  <scarabeus> great puting you to the txt :]
-2008 Dec 04 21:23:27  <scarabeus> ok issues from my side mentioned
-2008 Dec 04 21:23:32  <jmbsvicetto> scarabeus: I'll have to check that text - it feels like I'm being "canned" ;)
-2008 Dec 04 21:23:36  <scarabeus> someone else has something that needs to be handled
-2008 Dec 04 21:23:49  <scarabeus> jmbsvicetto: dont worry i try to make it to be factical
-2008 Dec 04 21:23:58  <tampakrap> is there an open bug for 3.5.10 stabilization?
-2008 Dec 04 21:24:01  <jmbsvicetto> yes
-2008 Dec 04 21:24:08  <tampakrap> if not let's create one to sum up the issues
-2008 Dec 04 21:24:12  <tampakrap> ok then
-2008 Dec 04 21:24:15  <krytzz> yeah, about the kde-plasma category: could we do it?
-2008 Dec 04 21:24:15  <jmbsvicetto> If ctrl+f3 worked here, I could get you the number quicker ;)
-2008 Dec 04 21:24:17  <tampakrap> i'll search
-2008 Dec 04 21:24:24  <jmbsvicetto> bug kde-3.5.10
-2008 Dec 04 21:24:27  <krytzz> do you like it?
-2008 Dec 04 21:24:44  <jmbsvicetto> krytzz: I don't think we should go down that route
-2008 Dec 04 21:25:13  <scarabeus> ok what are the alternatives
-2008 Dec 04 21:25:14  <jmbsvicetto> krytzz: If we try to get kde-plasma, kde-plasmoids, ..., we're going to create resistance
-2008 Dec 04 21:25:28  <krytzz> no, only kde-plasma jmbsvicetto for everything plasma-related
-2008 Dec 04 21:25:31  <scarabeus> kde-plasma only it is going to be
-2008 Dec 04 21:25:32  <jmbsvicetto> we've lived with kde-base and kde-misc for a long, long time
-2008 Dec 04 21:25:34  <tampakrap> could we have plasmoids for more than one version? and in case of slotted kde's, could we install a plasmoid for every session?
-2008 Dec 04 21:25:59  <jmbsvicetto> how many packages are we talking and what type of packages
-2008 Dec 04 21:25:59  <scarabeus> tampakrap: nope it is same as misc packages for more kde installs
-2008 Dec 04 21:26:09  <reavertm> tampakrap they won't build that easy
-2008 Dec 04 21:26:11  <scarabeus> jmbsvicetto: plasma aplets and enginges
-2008 Dec 04 21:26:15  <krytzz> hm ok thats just personal preference how filled the categories are, but i prefer fewer packages per category
-2008 Dec 04 21:26:28  <scarabeus> currently about 150 on kde-apps/look
-2008 Dec 04 21:26:39  <scarabeus> and we can bundle them all in the end
-2008 Dec 04 21:26:54  <jmbsvicetto> scarabeus: if we're talking about kde-look, perhaps we're going down the wrong path
-2008 Dec 04 21:26:58  <reavertm> categories are bad btw, some tag clouds should be introduced one day...
-2008 Dec 04 21:27:10  <jmbsvicetto> scarabeus: I'm thinking if we couldn't try to do something similar to what the perl team did with cpan
-2008 Dec 04 21:27:15  --> Eythan (n=Eythan@AMontpellier-152-1-30-159.w81-251.abo.wanadoo.fr) has joined #gentoo-kde
-2008 Dec 04 21:27:16  <krytzz> reavertm one day... yes :p
-2008 Dec 04 21:27:22  <scarabeus> jmbsvicetto: what they did
-2008 Dec 04 21:27:40  <scarabeus> some perl magic i guess ;]
-2008 Dec 04 21:27:45  <jmbsvicetto> yup ;)
-2008 Dec 04 21:28:09  --> fedux (n=fedux@190.55.126.139) has joined #gentoo-kde
-2008 Dec 04 21:28:11  <jmbsvicetto> app-portage/g-cpan g-cpan: generate and install CPAN modules using portage
-2008 Dec 04 21:28:19  <krytzz> hm
-2008 Dec 04 21:28:58  <krytzz> i assume this is like ruby gems?
-2008 Dec 04 21:28:59  <reavertm> so dedicated tool only for some plasmoids?
-2008 Dec 04 21:29:24  <reavertm> not worth it imho
-2008 Dec 04 21:29:31  <jmbsvicetto> I haven't looked at their implementation, but if I'm not mistaken, they've created a tool to help install packages in cpan. So instead of having one ebuild for every kde-look package, we could try to have some tool that helps install packages from kde-look
-2008 Dec 04 21:29:38  <tampakrap> i thought that upstream was going to apply a tool for downloading and easy installing plasmoids
-2008 Dec 04 21:29:53  <krytzz> yeah kde-look, but plasmoids still have to be compiled
-2008 Dec 04 21:30:04  <krytzz> cpan stuff not
-2008 Dec 04 21:30:07  <reavertm> and have various dependencies
-2008 Dec 04 21:30:31  <jmbsvicetto> No way to get them working without ebuilds?
-2008 Dec 04 21:30:34  <krytzz> tampakrap hm but only for script plasmoids?
-2008 Dec 04 21:30:34  <tampakrap> and apply to different kde versions
-2008 Dec 04 21:30:44  <tampakrap> i'm not sure
-2008 Dec 04 21:30:48  <reavertm> well, actually I was thinking about some ebuild generator with automatic depencency discovering (originally for plasmoids from playground)
-2008 Dec 04 21:31:11  <scarabeus> jmbsvicetto: not bad idea
-2008 Dec 04 21:31:13  <jmbsvicetto> I think we need to think more about this
-2008 Dec 04 21:31:17  <scarabeus> writing it down as long-term goal
-2008 Dec 04 21:31:18  <reavertm> while ebuild generator (without deps) I got done already, eclass is not yet ready for fetch/unpack from playground
-2008 Dec 04 21:31:56  <jmbsvicetto> Are plasmoids "heavy"?
-2008 Dec 04 21:32:09  <tampakrap> some of them
-2008 Dec 04 21:32:12  <tampakrap> very few
-2008 Dec 04 21:32:13  <krytzz> some are pretty normal c++ apps, so i would say yes
-2008 Dec 04 21:32:33  <krytzz> the script ones can be installed by plasma, we dont have to care about these
-2008 Dec 04 21:33:38  <jmbsvicetto> Anything else?
-2008 Dec 04 21:33:45  <reavertm> well, we could do as well some knewstuff2 interface for kde4 for plasmoids but we're not kde devs..
-2008 Dec 04 21:34:10  <reavertm> (it could reduce problem of plasmoids to installing them as icon themes)
-2008 Dec 04 21:34:26  <krytzz> yeah debug useflag in eclass
-2008 Dec 04 21:34:33  <krytzz> but ok this was already discussed
-2008 Dec 04 21:34:41  <scarabeus> it is on dev already
-2008 Dec 04 21:34:45  <reavertm> was it?
-2008 Dec 04 21:34:45  <krytzz> ah ok
-2008 Dec 04 21:34:46  <scarabeus> so lets see how that evolve
-2008 Dec 04 21:34:53  <reavertm> aa, my proposition?
-2008 Dec 04 21:34:59  <scarabeus> reavertm: we might have to write it as glep
-2008 Dec 04 21:35:00  <reavertm> it won't evolve...
-2008 Dec 04 21:35:03  <scarabeus> and push it trhought
-2008 Dec 04 21:35:38  <reavertm> no way, just pass - it's against "ultimate freedom" and to package manager specific
-2008 Dec 04 21:35:45  <scarabeus> i dont care they are picky about it, i think they would not agree with anything that does not worship their ethernal glory (dont cite me that is just brief overview of those flames)
-2008 Dec 04 21:35:46  <reavertm> as it uses FEATURES
-2008 Dec 04 21:36:43  <reavertm> anyway, "our own" debug suport you mean?
-2008 Dec 04 21:37:03  <reavertm> well, "additiomnal debug codepaths" are supported already
-2008 Dec 04 21:38:01  <krytzz> hm so scarabeus whats the role model for kde-misc ebuilds now?
-2008 Dec 04 21:38:22  <scarabeus> krytzz: have no idea
-2008 Dec 04 21:38:29  <scarabeus> everything what is not in kde-base
-2008 Dec 04 21:38:32  <reavertm> actually I see no role for kde-misc really - never seen
-2008 Dec 04 21:38:32  <scarabeus> from what i can see
-2008 Dec 04 21:38:44  <reavertm> ok, kdevelop, kdesvn then?
-2008 Dec 04 21:39:03  <krytzz> hm
-2008 Dec 04 21:39:09  <scarabeus> oh it is mess like hell
-2008 Dec 04 21:39:14  <reavertm> kdevelop is in KDE even and it will be in kde-base soon I guess (released as part of KDE)
-2008 Dec 04 21:39:21  <reavertm> it is messy a bit
-2008 Dec 04 21:40:00  <scarabeus> ok is this still part of meeting chat or we can dismisso ourselfs?
-2008 Dec 04 21:40:11  <krytzz> i have nothing further
-2008 Dec 04 21:40:12  <scarabeus> oh typos it is going to kill me one day
-2008 Dec 04 21:40:39  <reavertm> scarabeus bug wranglers - needed or not?
-2008 Dec 04 21:40:47  <scarabeus> not now, we have pretty big list
-2008 Dec 04 21:40:59  <scarabeus> i will write it onto longterm with you as person interested
-2008 Dec 04 21:40:59  <scarabeus> ok
-2008 Dec 04 21:41:01  <scarabeus> ?
-2008 Dec 04 21:41:37  <jmbsvicetto> I think you're looking at it from the wrong pov - bug-wranglers
-2008 Dec 04 21:41:40  <reavertm> well, I'm not going to push if it's seen not necessary
-2008 Dec 04 21:42:13  <yngwin> ok, i'm putting in a staffing-needs/recruitment request for developers and/or herd testers for qt herd
-2008 Dec 04 21:42:16  <reavertm> I would like to model it a bit like KDE team, at least have more of them than 1
-2008 Dec 04 21:42:25  <jmbsvicetto> We don't need bug wranglers to look at new bugs and check if they're kde bugs. We need people that work through kde bugs and help get them resolved - by providing patches, by doing tests, by interacting with users.
-2008 Dec 04 21:42:31  <krytzz> ok when the eclasses are merged every kde-testing ebuild should have the KDE_MINIMUM  thing scarabeus?
-2008 Dec 04 21:42:42  <scarabeus> nope
-2008 Dec 04 21:42:56  <scarabeus> krytzz: kde_minimal is only override variable
-2008 Dec 04 21:43:00  <scarabeus> it should work as they are now
-2008 Dec 04 21:43:10  <scarabeus> read up description in eclass
-2008 Dec 04 21:43:13  <krytzz> ok
-2008 Dec 04 21:43:14  <krytzz> ill do
-2008 Dec 04 21:43:45  <jmbsvicetto> ok, one last request from me - if you work in the overlays, be sure to run repoman full from time to time. There's some extra cookies for those also running pcheck ;)
-2008 Dec 04 21:44:04  <scarabeus> http://dev.gentoo.org/~scarabeus/kde_meeting_state.txt
-2008 Dec 04 21:44:12  <scarabeus> and i am going to save the log from this
-2008 Dec 04 21:44:13  <krytzz> got it ^^
-2008 Dec 04 21:44:21  <scarabeus> should i put it onto kde space?
-2008 Dec 04 21:44:37  <tampakrap> and please try to forward my access to kde-testing, i want to do some kde3 work there
-2008 Dec 04 21:45:58  <jmbsvicetto> scarabeus: sure
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090108.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090108.txt
deleted file mode 100644
index 264dc6a03d..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090108.txt
+++ /dev/null
@@ -1,666 +0,0 @@
-[20:00:10] <PSYCHO___> my dear friends it the time to start the meeting :]
-[20:00:13] <bonsaikitten> masking 4.1 shouldn't be needed
-[20:00:21] <bonsaikitten> MEATING
-[20:00:22] <Sput> it is.
-[20:00:28] <bonsaikitten> *ding ding ding*
-[20:00:30] <alexxy> yes =)
-[20:00:31] --> linex (n=quassel@60.54.93.166) has joined #gentoo-kde
-[20:00:35] <PSYCHO___> !herd kde
-[20:00:36] <Willikins> PSYCHO___: (kde) caleb, carlo, cryos, deathwing00, genstef, jmbsvicetto, keytoaster, mattepiu, patrick, scarabeus, tgurr
-[20:00:40] <alexxy> time for meating
-[20:00:43] <Sput> emerge -DuvaN world will pull in 4.1 packages unless all your world entries use :3.5
-[20:00:47] <Sput> it's quite annoying actually
-[20:00:49] <bonsaikitten>  /mode +m
-[20:00:52] <bonsaikitten> tehehehehehe
-[20:00:53] *** Mode #gentoo-kde +v alexxy by scarabeus
-[20:01:12] <wired^> =)
-[20:01:20] <alexxy> heh
-[20:01:20] <mortalmatt> Thanks a lot! Have fun with the meeting.
-[20:01:20] <alexxy> =)
-[20:01:28] -*- Sput had to fix his dad's world file to avoid installing KDE4
-[20:01:28] *** Mode #gentoo-kde +v hwoarang by scarabeus
-[20:02:02] --> cryos|work (n=mhanwell@gentoo/developer/cryos) has joined #gentoo-kde
-[20:02:02] *** Mode #gentoo-kde +o cryos|work by ChanServ
-[20:02:08] <-- mortalmatt (n=matthew@p54A6D9A6.dip.t-dialin.net) has quit ("Leaving")
-[20:02:12] <tampakrap> now we can start :)
-[20:02:17] <PSYCHO___> :D
-[20:02:30] <PSYCHO___> cant we have at least few devs anounce their presence
-[20:02:37] -*- yngwin present
-[20:02:44] <cryos|work> Look in the nick list...
-[20:02:52] <yngwin> jmbsvicetto?
-[20:03:15] <linex> hello
-[20:03:25] <linex> I'm using quassel
-[20:03:26] <PSYCHO___> cryos|work: well only you me and yngwin are online, rest is away :]
-[20:03:40] <alexxy> bonsaikitten: ??
-[20:03:43] <bonsaikitten> yes?
-[20:03:44] <alexxy> are you there?
-[20:03:46] <PSYCHO___> he is :]
-[20:03:50] <cryos|work> Sucks - I nearly didn't make it. Compositing and Avogadro crashed my X server...
-[20:03:54] <linex> I got the core running and I use my client to connect to it.
-[20:03:56] <Sput> bonsaikitten is away-faking as usual :)
-[20:04:03] <bonsaikitten> whut!
-[20:04:16] <cryos|work> Its just a bot!
-[20:04:16] <PSYCHO___> ok i guess we can wait few minutes if jmbsvicetto shows up :]
-[20:04:28] <PSYCHO___> or start without him?
-[20:04:29] <tampakrap> maybe reavertm too
-[20:04:31] <cryos|work> bonsaikitten: Are you turing complete?
-[20:04:48] <linex> Why do I have do pane of the same channel topand below
-[20:05:05] <bonsaikitten> cryos|work: I doubt it, but I do have some strange loops
-[20:05:13] <-- the_p (n=the_p@cust.static.62-152-211-38.swisscomdata.ch) has quit (Remote closed the connection)
-[20:05:35] <victorlf__> does anyone know when dev.gentooexperimental.org will be up again?
-[20:05:47] <bonsaikitten> victorlf__: it isn't?
-[20:05:58] <DerKomisar> nope
-[20:05:59] <bonsaikitten> right
-[20:06:45] --> MartyMcFly (n=martin@dslb-088-066-055-066.pools.arcor-ip.net) has joined #gentoo-kde
-[20:07:27] <MrRat> linex: the top one is the chat monitor, it shows activity in all channels that you are in
-[20:07:53] <MrRat> linex: you can move it
-[20:08:05] <MrRat> linex: or hide it by rightclick
-[20:08:16] <tampakrap> why is d.ge.o so popular?
-[20:08:22] <MrRat> in the top bar^
-[20:08:24] --> tbeadle_ (n=tbeadle@204.181.64.60) has joined #gentoo-kde
-[20:08:26] <PSYCHO___> because we have our files in there :]
-[20:08:26] <linex> Ah ok. nice feature but I don't think I want it. Not right now. Its removable, right ?
-[20:08:35] <tampakrap> what files?
-[20:09:00] -*- Sput failed getting a shell on d.ge.o yet :/
-[20:09:02] <PSYCHO___> tampakrap: snapshots of phonon4exampe
-[20:09:03] <bonsaikitten> tampakrap: because it hots so much
-[20:09:13] <bonsaikitten> right. someone fscked php
-[20:09:14] <tampakrap> ah yes
-[20:09:36] <linex> MrRat: I right clck. There Configure. Then what ?
-[20:09:49] <MrRat> linex: yes rightclick in the bar above topic, where file,view,etc... is
-[20:10:03] <linex> ok
-[20:10:03] --> restle (n=restle@212.6.7.10) has joined #gentoo-kde
-[20:10:23] <MrRat> see "show chat monitor"
-[20:10:30] <linex> ok, its gone. Its called Chat Monitor, right ?
-[20:10:44] <bonsaikitten> there.
-[20:11:24] <linex> Mr Rat : is it possible to have the traditional channel tabs instead of the tree-like on the left ?
-[20:11:31] <MrRat> linex: #quassel for other quassel related help :p
-[20:11:40] <PSYCHO___> ok i guess we should start so we can end up reasonably and hope others show up in progress... objections?
-[20:11:41] <linex> MrRat: ok fair enough
-[20:12:36] <-- tbeadle_ (n=tbeadle@204.181.64.60) has quit (Read error: 54 (Connection reset by peer))
-[20:12:41] <PSYCHO___> first on the nice list is just sumarising of previous meeting (read as what is not done from that list :])
-[20:12:43] <yngwin> no objections here
-[20:12:43] --> tbeadle_ (n=tbeadle@204.181.64.60) has joined #gentoo-kde
-[20:12:44] <MrRat> linex: however id prefer tabs myself too :p
-[20:12:46] <PSYCHO___> http://www.gentoo.org/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20081204.txt
-[20:13:04] <linex> MrRat: :)
-[20:13:17] -*- cryos|work is listening...
-[20:13:30] <yngwin> ok, what's the latest on 3.5.10 stabilizing?
-[20:13:37] <cryos|work> For the record PSYCHO___ = ?
-[20:13:44] <yngwin> scarabeus
-[20:13:44] <PSYCHO___> scarabeus
-[20:13:48] <cryos|work> OK
-[20:13:52] <-- tbeadle (n=tbeadle@204.181.64.60) has quit (Read error: 104 (Connection reset by peer))
-[20:14:05] <-> scarabeus is now known as frogeater
-[20:14:13] <-> You are now known as scarabeus
-[20:14:42] <tampakrap> 3.5.10 is stable enough for the users but still there are many open bugs regarding it
-[20:14:55] <tampakrap> and of course there is still the issue with the misc apps
-[20:15:18] <scarabeus> is there any progress? or nobody is working on it seriously
-[20:15:25] <tampakrap> the eclass has to be updated to make them prefixed to /usr/kde/3.5
-[20:15:29] <scarabeus> maybe we should write on dev we want some volunteers
-[20:15:46] <tampakrap> i'm ok with this
-[20:15:53] <Sput> as a side remark: 3.5.10 will definitely be upstream's last release
-[20:15:55] --> agamn (n=agamn@ip-83-134-215-20.dsl.scarlet.be) has joined #gentoo-kde
-[20:15:58] <tampakrap> i also can work on it but was busy with quiz and other things lately
-[20:15:59] <yngwin> ok
-[20:16:00] <yngwin> shame
-[20:16:28] <Sput> some patches still go into svn, but no further releases are planned.
-[20:16:36] -*- cryos|work has found it tough finding spare time to work on 3.5.10...
-[20:16:44] <scarabeus> we need it stable in order to make 4.X stable :]
-[20:16:56] <scarabeus> since only 3.5.10 has correct cryos magic :]
-[20:17:11] <tampakrap> ok but i think we should concentrate on kde-4.2 release first and then to 3.5
-[20:17:21] <yngwin> so let's do a call for volunteers to help squash bugs on 3.5.10
-[20:17:31] <tampakrap> agreed
-[20:17:31] <scarabeus> ok who will sent the mail on dev?
-[20:17:40] <tampakrap> you :)
-[20:17:48] <cryos|work> I will as and when I can send the time, but currently my spare time is at a real premium :-(
-[20:18:08] <scarabeus> well i am getting my time pretty sqeezed too :]
-[20:18:16] <scarabeus> so we shall see :]
-[20:19:12] <scarabeus> ok next thing is kde4 eclasses are ready for commit to the main tree
-[20:19:27] <scarabeus> after this commits, all in tree ebuilds must be updated and revbump
-[20:19:38] <alexxy> and seems most of kde4 misc apps already ready for this eclasses
-[20:19:39] <scarabeus> and users must use these versions in order for flawless update
-[20:19:45] <cryos|work> I still think the default for live outside of kde-base should be changed back to what it was - doesn't directly affect tree ebuilds though.
-[20:20:07] <scarabeus> cryos|work: ok that i missed, fix  that in some commit please, so i dont forget again
-[20:20:23] <cryos|work> I will do it - I just didn't want to cause it to yo-yo...
-[20:20:26] <scarabeus> make it +kdeprefix for everything live by default
-[20:20:38] <scarabeus> cryos|work: i already agreed on it :P i only forget
-[20:20:52] <cryos|work> Yep - explicitly setting to - will continue to work.
-[20:20:56] -*- cryos|work goes to do that...
-[20:21:18] <scarabeus> anything else to eclasses?
-[20:21:21] <alexxy> but there still should be possible to install live kde misc apps with kde 4.1 or 4.2
-[20:21:31] <scarabeus> alexxy: it is :}
-[20:21:39] <scarabeus> you just need to set kdeprefix correctly first
-[20:21:41] <cryos|work> It is - set -kdeprefix.
-[20:21:46] <scarabeus> and for that you need to know what are you doing
-[20:22:19] <alexxy> because some misc apllets exists only as -9999 ones
-[20:22:24] <cryos|work> Anyone using live should know what they are doing...
-[20:22:38] <scarabeus> agreed with cryos on this
-[20:22:47] <alexxy> me too =)
-[20:23:05] <scarabeus> ok i guess ecalsses were polished pretty fine :]
-[20:23:10] <-- undetected (n=laika@27.138.45.66.cm.sunflower.com) has quit
-[20:23:11] <alexxy> btw i saw kde 4.1.4 tagged in svn
-[20:23:17] <cryos|work> They are looking good to me.
-[20:23:27] <bonsaikitten> alexxy: yeah, that'll keep us busy next week :)
-[20:23:29] <scarabeus> ok since he mention it SOMEBODY willing to bump 4.1.4
-[20:23:39] <scarabeus> do we want it or need it?
-[20:23:41] <cryos|work> Yes it was and I think tarballs are uploaded.
-[20:23:42] <tampakrap> and what about misc apps?
-[20:23:42] <cryos|work> It will be a nice bump to all KDE apps when the new eclass goes in.
-[20:23:56] <scarabeus> cryos|work: good idea
-[20:23:57] <scarabeus> :]
-[20:24:00] <tampakrap> should live misc apps stay in :live and not in stable systems?
-[20:24:06] <cryos|work> Kill two birds with one stone.
-[20:24:07] <scarabeus> ok so we do eclass -> misc apps ->4.1.4
-[20:24:37] <scarabeus> ok who is going to do actual bump
-[20:24:40] <cryos|work> All live apps should be in the :live slot shouldn't they?
-[20:24:52] <tampakrap> my opinion to this: ^^
-[20:25:04] <scarabeus> can be in :0 if dev thinks it is needed
-[20:25:12] <tampakrap> we shouldn't provide live ebuilds for stable systems, it gets maintainance a hell
-[20:25:13] <scarabeus> but default is live
-[20:25:24] <cryos|work> It seems like a bad move to me.
-[20:25:33] <cryos|work> May be snapshots if it is warranted...
-[20:25:38] <alexxy> we can make snapshots for some mis apps
-[20:25:43] <alexxy> if they realy needed
-[20:25:51] <alexxy> *misc
-[20:26:05] <scarabeus> well we dont give users chance to use live in stable, and if they pull kde-crazy, they have to pick consequences themselves
-[20:26:27] <scarabeus> agreed with snapshots if it is needed app
-[20:26:44] <-- tbeadle_ (n=tbeadle@204.181.64.60) has quit (Read error: 60 (Operation timed out))
-[20:26:46] <tampakrap> and what about the opposite? should we provide versioned apps in :live?
-[20:26:50] <yngwin> i would suggest only make snapshots for things that should go into official tree
-[20:26:51] <alexxy> and some things about kde :4.2
-[20:26:57] <alexxy> it needs
-[20:27:03] <alexxy> networkmanager 0.7
-[20:27:19] <scarabeus> well i finished nm-0.7 with blessing from rbu :]
-[20:27:24] <alexxy> so it also needs policykit
-[20:27:59] <scarabeus> policykit is suspended for now, i spoke with gnome and they have it too, i would do it with cooperation, so we will have actualy better chance not to screw up :]
-[20:28:00] <alexxy> also if we want to bump some stuff like kde printer applet we should have system-config apps unmasked
-[20:28:31] <scarabeus> alexxy: one problem per while man, if you throw 15 problems we should pick up on what to answer? :D
-[20:28:51] <bonsaikitten> let's start with the overlay situation before we discuss versioning ...
-[20:28:56] <alexxy> scarabeus: its still one global problem
-[20:29:02] <alexxy> deps of kde-4.2
-[20:29:02] --> tbeadle_ (n=tbeadle@204.181.64.60) has joined #gentoo-kde
-[20:29:03] <alexxy> )
-[20:29:09] <scarabeus> i know :D
-[20:29:26] <scarabeus> important question about stable tree:
-[20:29:35] <scarabeus> should we allow usage of +kdeprefix for stable users?
-[20:29:49] <tampakrap> i vote for no :)
-[20:29:53] <scarabeus> we had this nice discussion and i think for stable tree this feature could be disabled
-[20:30:02] <cryos|work> I always voted no...
-[20:30:19] <cryos|work> I think jmbsvicetto may have more to say here though.
-[20:30:26] <alexxy> this fature should be use.masked
-[20:30:32] <cryos|work> I am not sure this can be decided without others here.
-[20:31:00] <alexxy> so if people realy realy want it they should unmask this feature
-[20:31:10] <scarabeus> yup ;]
-[20:31:33] <cryos|work> Sounds like a good idea - still a shame more devs are not present if they wanted to discuss this further.
-[20:31:47] <scarabeus> alexxy: you have meeting about becoming dev tomorow right?
-[20:31:53] <tampakrap> well, in case we provide this, we could not officially support it
-[20:31:53] <alexxy> its will look like a situation with clustered lvm extensions =) they are masked by default
-[20:32:00] <alexxy> scarabeus: yes
-[20:32:01] <scarabeus> cryos|work: well this time i announced it properly
-[20:32:20] <cryos|work> I didn't say you didn't - you did a great job coordinating the meeting.
-[20:32:20] <scarabeus> ok i think alexxy can do bump for 4.1.4 as act of new dev :] so he try it too :}
-[20:32:42] <tampakrap> +1
-[20:32:58] <scarabeus> cryos|work: it was supposed to sound like i am sad they didnt come even with proper anouncement...
-[20:33:27] <scarabeus> that handles in tree moves for 4.2 preparation, which is great :]
-[20:33:34] <alexxy> heh =) i'll try
-[20:33:49] <scarabeus> also one thing for kde-testing overlay, somebody should doublecheck for missing ebuilds, in last week we added 2 completely new ones
-[20:33:52] <cryos|work> Sounds good, although make sure people are around to help/mentor ;-)
-[20:34:07] <cryos|work> scarabeus: Real life happens... I am sure jmbsvicetto would have made it if he could.
-[20:34:42] <scarabeus> yes yes he was looking forward on this meeting, he has few issues, and i think he would like to present his mysql magic ;]
-[20:35:07] <scarabeus> so who is willing to look up on kde-testing, that is important think that should not be forgoten
-[20:35:23] <cryos|work> What do you mean look up on?
-[20:35:43] <alexxy> also i think we should sanitize deps of kde:4.2 packages
-[20:35:47] <cryos|work> You mean bump to rcs etc when they are tagged?
-[20:35:57] <alexxy> some of deps already provided by kdelibs
-[20:35:59] <scarabeus> nope, there are missing ebuilds from dirs
-[20:36:08] <scarabeus> for example some missing games
-[20:36:12] <scarabeus> and missing applications
-[20:36:22] <scarabeus> as example bomber and kwrited
-[20:36:24] <alexxy> so i think this deps shoul be reoved from kde-base packages since they already depend on kdelibs
-[20:36:30] <tampakrap> bomber added today
-[20:36:37] <tampakrap> kwrited yesterday
-[20:36:42] <scarabeus> tampakrap: i know, and what else is missing, that is the point
-[20:36:51] <tampakrap> oh
-[20:36:52] <scarabeus> someone has to doublecheck, cmakelists/directories
-[20:37:03] <scarabeus> you wanna do it?
-[20:37:17] <tampakrap> ok but we want two for this :)
-[20:37:37] <alexxy> scarabeus: ok i'll oko for missing 4.2 apps
-[20:37:38] <alexxy> =)
-[20:37:43] <scarabeus> ok so you two :]
-[20:37:58] -*- alexxy uses kde 4.2 as dayly desktop]
-[20:38:01] <scarabeus> :]
-[20:38:35] <scarabeus> policykit is suspended until gnome starts working on it too as i said
-[20:38:44] <scarabeus> and one last thing regarding 4.2
-[20:38:49] <scarabeus> there is printing dialog again
-[20:38:52] <scarabeus> written in python
-[20:39:01] <scarabeus> using system-config-bla
-[20:39:02] <scarabeus> files
-[20:39:53] <tampakrap> and something else
-[20:39:55] <scarabeus> these packages are from dberkholz whom allowed us to mess with them, i think we should start playing with this in testing
-[20:40:08] <scarabeus> and add printing later and not with bump of 4.2
-[20:40:09] -*- dberkholz highlights
-[20:40:12] <tampakrap> we should bump every kde-misc app to eapi2 in kde-testing
-[20:40:15] <scarabeus> since it wont be correctly tested
-[20:40:40] <scarabeus> tampakrap: what for, only if they use kde4-base
-[20:40:50] <dberkholz> i mentioned to scarabeus previously but not to everyone. it's very important that you bump everything before testing, because current versions are very outdated.
-[20:41:03] <-- bicyclerepairman (n=sam@host86-128-227-224.range86-128.btcentralplus.com) has quit (Read error: 110 (Connection timed out))
-[20:41:22] <scarabeus> anyone specialy interested in making this work?
-[20:41:41] <bonsaikitten> :(
-[20:41:55] <tampakrap> reavertm could do this but he isn't here :(
-[20:42:08] <scarabeus> he said he wont have time today
-[20:42:15] <scarabeus> he is only one properly excused :D
-[20:42:41] --> mikb (n=mikb@c122-106-202-225.belrs3.nsw.optusnet.com.au) has joined #gentoo-kde
-[20:42:52] <tampakrap> ok, leave this one open and if he won't handle it, we'll announce it on g-desktop
-[20:43:04] <yngwin> sounds good
-[20:43:04] <scarabeus> anyone has something with regards for kde4.1/4,2 what i didnt speak of?
-[20:43:28] --> looonger (n=quassel@host-89-231-128-7.rawamaz.mm.pl) has joined #gentoo-kde
-[20:43:35] <tampakrap> yes
-[20:43:58] <tampakrap> should we provide versioned kde4 apps in live?
-[20:44:04] <-- BCMM (n=bcmm@unaffiliated/bcmm) has quit (Remote closed the connection)
-[20:44:09] <tampakrap> or only live ones?
-[20:44:14] <scarabeus> in crazy you mean?
-[20:44:27] <scarabeus> there should be everything we think that is not mature enought
-[20:44:32] <scarabeus> for example those koffice ebuilds
-[20:44:35] <tampakrap> i mean globally
-[20:44:40] <alexxy> what about kde-plasmoids?
-[20:44:52] <scarabeus> alexxy: you want them, you review them
-[20:44:56] <scarabeus> :D
-[20:45:01] <tampakrap> should we provide install of amarok2 in live and add block for amarok-live?
-[20:45:01] --> tgurr (n=tgurr@gentoo/developer/tgurr) has joined #gentoo-kde
-[20:45:01] <alexxy> ohhh
-[20:45:01] *** Mode #gentoo-kde +o tgurr by ChanServ
-[20:45:08] <alexxy> and what about sets
-[20:45:13] <alexxy> in off tree?
-[20:45:27] <scarabeus> in off tree we can use them as we want i think
-[20:45:39] <scarabeus> for tree we have to prepare metas, which will be done with 4.2 bump
-[20:45:58] <alexxy> can we add sets to off tree?
-[20:46:16] <yngwin> why not
-[20:46:18] <alexxy> or this will be done only after stabilazing portage-2.2?
-[20:46:37] <tampakrap> btw i'll write the guide for 4.2 and live this time for real :)
-[20:46:53] <scarabeus> ok writing it up to summary :]
-[20:46:54] --> undetected (n=laika@27.138.45.66.cm.sunflower.com) has joined #gentoo-kde
-[20:47:16] <yngwin> we can't put any sets in the official tree, but you can provide sets for them in the overlay
-[20:47:25] <scarabeus> as said yngwin
-[20:47:39] <scarabeus> for now we have to live with metas and be happy with eapi2
-[20:47:41] <xdmx> guys, why don't you put the direct url for each kde application instead of the generic www.kde.org? i mean, let's take for example marble, it's homepage is set to www.kde.org, but i think it would be 100 times better to put its own homepage ( http://edu.kde.org/marble/ ). so one interested to marble don't go to the kde homepage, but to its own. what do you think?
-[20:48:08] --> jbrouault (n=jbrouaul@ARennes-552-1-79-210.w92-135.abo.wanadoo.fr) has joined #gentoo-kde
-[20:48:18] <scarabeus> xdmx: open bug and give us ebuilds and correct urls, up to then kde.org will be used, we wont search web for them i guess :]
-[20:48:41] <tampakrap> or we could use edu.kde.org for example
-[20:48:47] <xdmx> scarabeus: http://nopaste.com/p/aHK4XLra6 this is a first one (some are to recheck because unmantained, i don't know if it's better to set directly the usertech site for some..) :)
-[20:49:32] <scarabeus> wow :] is anyone willing to do this? i am pretty sure i wont have itme for it, so i can only mark it as long term :]
-[20:49:54] <scarabeus> bonsaikitten: you dont wana use your regexp skillz?
-[20:50:44] <bonsaikitten> scarabeus: meh. maybe. if noone else can be coerced :)
-[20:51:02] <scarabeus> i guess it looks you are only one left with nothing assigned
-[20:51:13] <tampakrap> scarabeus: you too :)
-[20:51:31] <scarabeus> nope i am with putting eclasses to the tree and fixing all ebuilds
-[20:51:37] <tampakrap> :)
-[20:51:38] <scarabeus> i think it is pretty annoymarble -> http://edu.kde.org/marble/
-[20:51:38] <scarabeus> kbounce -> http://games.kde.org/game.php?game=kbounce
-[20:51:38] <scarabeus> kbreakout -> http://games.kde.org/game.php?game=kbreakout
-[20:51:38] <scarabeus> kdiamond -> http://games.kde.org/game.php?game=kdiamond
-[20:51:38] <scarabeus> kgoldrunner -> http://games.kde.org/game.php?game=kgoldrunner
-[20:51:38] <scarabeus> klines -> http://games.kde.org/game.php?game=klines
-[20:51:38] <scarabeus> kolf -> http://games.kde.org/game.php?game=kolf
-[20:51:38] <scarabeus> kollision -> http://games.kde.org/game.php?game=kollision
-[20:51:38] <scarabeus> ksame -> http://games.kde.org/game.php?game=ksame
-[20:51:38] <scarabeus> kspaceduel -> http://games.kde.org/game.php?game=kspaceduel
-[20:51:38] <scarabeus> kbattleship -> http://games.kde.org/game.php?game=kbattleship
-[20:51:38] <scarabeus> kmahjongg -> http://games.kde.org/game.php?game=kmahjongg
-[20:51:38] <scarabeus> kreversi -> http://games.kde.org/game.php?game=kreversi
-[20:51:38] <scarabeus> kshisen -> http://games.kde.org/game.php?game=kshisen
-[20:51:38] <scarabeus> kfourinline -> http://games.kde.org/game.php?game=kfourinline
-[20:51:43] <scarabeus> crap
-[20:51:46] <scarabeus> what did i push
-[20:52:02] <scarabeus> hm
-[20:52:04] <scarabeus> interesting
-[20:52:12] <yngwin> lol
-[20:52:28] <tampakrap> please pastebin don't spam the channel
-[20:52:31] <scarabeus> grrr
-[20:52:35] <wired^> lmao
-[20:52:51] <scarabeus> second time today quassel pasted when i didnt push that damn button :D
-[20:53:15] <alexxy> scarabeus: cause you text contains newlines
-[20:53:36] <scarabeus> alexxy: i didnt write it i marked it from buffer and put into my editor
-[20:53:38] <scarabeus> not here
-[20:53:41] <tampakrap> i think this is everything about 4.1/4.2
-[20:53:46] <scarabeus> yes /me too
-[20:53:53] <scarabeus> anyone has something in regards for that
-[20:54:06] <yngwin> guess not
-[20:54:21] <scarabeus> tgurr: your ebuild in genkdesvn for that pdf in scribus is broken, take look on fixed one in kde-crazy
-[20:54:35] <scarabeus> ok we get to qt4 yngwin, you have something interesting there?
-[20:54:42] <yngwin> yes
-[20:54:50] <yngwin> i have several recruits now
-[20:55:00] <yngwin> so it's starting to look good :)
-[20:55:21] <hwoarang> :)
-[20:55:22] <yngwin> hwoarang is doing good work on qt4-build.eclass
-[20:55:23] <-- Psychey (n=me@1x-193-157-193-9.uio.no) has quit (Success)
-[20:55:25] <tgurr> scarabeus: not my biggest problem atm ;) kernel is also broken on 2 machines here ...
-[20:55:28] <hwoarang> ah hold on
-[20:55:37] <hwoarang> yngwin and everybody
-[20:55:50] <hwoarang> qt4-build class needs to be ported on EAPI2 standards
-[20:55:55] <scarabeus> yngwin: great you should sent the other aprentices here too so we can meet them :]
-[20:56:03] <hwoarang> this means that qt-4.4.9999 live ebuilds
-[20:56:06] <hwoarang> need to change too
-[20:56:07] <yngwin> yes, i think sping came by the other day
-[20:56:10] <scarabeus> hwoarang: i guess on that you should use reavertm, he has great insight :]
-[20:56:27] <yngwin> he's one of the qt-creator devs
-[20:56:44] <hwoarang> ok scarabeus. will talk to him
-[20:56:48] <yngwin> so, we have been squashing qt4 bugs
-[20:56:56] <hwoarang> but qt ebuilds should move to qt overlay when it is ready
-[20:57:13] <hwoarang> i dont feel comfortable to play on kde-crazy :D
-[20:57:18] <tampakrap> i agree with this
-[20:57:29] <yngwin> yes, we should have the qt overlay up and running in a few days
-[20:57:44] <scarabeus> hwoarang: we dont bite ;D
-[20:57:47] <yngwin> then we'll push stuff to kde-testing/crazy when they're ready
-[20:57:56] <yngwin> scarabeus: we do :p
-[20:58:02] <hwoarang> :D
-[20:58:13] <scarabeus> yngwin: dont forget to upload kde-teams keys if you want us to help you ;]
-[20:58:35] <yngwin> yes, i'll look into that once it's really up
-[20:58:47] <scarabeus> :]
-[20:59:02] <yngwin> another thing, i want to stabilize qt 4.4.2
-[20:59:10] <yngwin> first split ebuilds version to go stable
-[20:59:15] <scarabeus> i volte yes :]
-[20:59:24] <-- hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has quit (Read error: 145 (Connection timed out))
-[20:59:38] <scarabeus> note: new kde4 eclasses specialy depends on splited qt ebuilds, i dropped the old mono qt stuff
-[20:59:55] <yngwin> i wrote a migration guide, because i've seen many problems, but according to jkt and zmedico it should go smooth now
-[20:59:55] <scarabeus> you need some help there from us or bug is filled and all is going fine?
-[21:00:42] <yngwin> well, i need a stable system with qt-4.3 and PyQt4, then test if keywording 4.4 ebuilds and masking 4.3 really gives a smooth upgrade path
-[21:01:18] <scarabeus> hm, read as: ANYONE ON STABLE HERE? ;]
-[21:01:26] <wired^> whats that? :P
-[21:01:26] -*- tampakrap 
-[21:01:36] <yngwin> so i was planning to test that in a chroot tonight otherwise
-[21:02:01] -*- alexxy uses ~arch ( read as ~amd64 ~x86 ~mips and ~arm)
-[21:02:03] <scarabeus> ok you two can talk it out, it is up to you :]
-[21:02:07] <yngwin> tampakrap: you have qt-4.3 on there?
-[21:02:24] <tampakrap> no but i can downgrade 4.4 isn't even needed in this one
-[21:02:42] <yngwin> ok, we'll talk about that after the meeting then
-[21:03:03] <scarabeus> ook
-[21:03:41] <yngwin> another item is qt-embedded has not been receiving any love
-[21:03:58] <yngwin> but i probably should speak to embedded people about that
-[21:04:32] <scarabeus> there i guess we are not much able to help :] only if as embedded can be count some cluster ;]
-[21:05:36] <alexxy> he he =)
-[21:06:11] <scarabeus> yngwin: btw i looked on hwoarangs eom today and give him notes, i guess when he incorporate the updates he will pass review from recruiters so you will get new coleague :]
-[21:06:23] <yngwin> and i need to get a pythonista to mentor me a bit wrt ebuilds using python (mostly PyQt4 packages)
-[21:06:34] <Sput> qt-embedded = Qt Extended now?
-[21:06:36] <yngwin> scarabeus: great
-[21:06:44] <Sput> or what is that supposed to be?
-[21:07:03] <alexxy> seems qt extended
-[21:07:06] <scarabeus> yngwin: when you are on pyqt take creepy look on pykde on the route i think :]
-[21:07:14] <bonsaikitten> yngwin: I can try to help with python things
-[21:07:15] <alexxy> since qt embedded was renamed to it
-[21:07:20] <yngwin> Sput: yes, qt-extended / qtopia
-[21:07:27] <Sput> k
-[21:07:46] -*- Sput would like to have a Gentoo way of installing the Qtopia SDK
-[21:07:55] <yngwin> scarabeus: i'll do what i can
-[21:08:00] <scarabeus> :]
-[21:08:03] <yngwin> bonsaikitten: great
-[21:09:12] --> hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has joined #gentoo-kde
-[21:09:19] <scarabeus> now i would like to know what is state of that mysql issue, but we are out since only guy working on it is jmbsvicetto so this note will be added to the summary additionaly, i would really like to have amarok2 on amd64 with kde4.2 bump
-[21:09:45] <-- St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has quit (Read error: 54 (Connection reset by peer))
-[21:09:50] --> St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has joined #gentoo-kde
-[21:09:53] -*- cryos|work would love to see amarok 2, but thinks the move to MySQL as the *only* backend wasn't good...
-[21:10:07] <yngwin> indeed
-[21:10:17] --> neyz (n=neyz@ram94-6-82-242-23-69.fbx.proxad.net) has joined #gentoo-kde
-[21:10:22] <tampakrap> they are going to import others too
-[21:10:25] <yngwin> i wonder why they couldn't use qt-sql interface, which can use various DBs
-[21:10:43] <scarabeus> because *censored* *censored* *censored*
-[21:11:56] <cryos|work> I am going to need to pay less attention to this meeting and more to work now...
-[21:11:57] <Sput> no they are not going to import others
-[21:12:01] <Sput> it'll stay mysql only
-[21:12:07] <yngwin> ok, so we need to wait for feedback from jmbsvicetto on this
-[21:12:08] <cryos|work> I heard they weren't either, but don't know.
-[21:12:41] <cryos|work> I really question the intelligence of using such a heavy weight dep for a music player as the only option though.
-[21:12:58] -*- yngwin just uses mpd
-[21:12:58] <cryos|work> I am not about to go trolling, but think it is a step backwards.
-[21:13:15] <scarabeus> well most of packagers think that it is step back
-[21:13:25] <scarabeus> what for fully fledged mysql on desktop machine
-[21:13:29] <cryos|work> In Avogadro we very carefully consider even optional deps, required deps even more so.
-[21:13:43] <bonsaikitten> from my own experience I claim that being unable to use sqlite is a sign of bad design
-[21:13:45] <cryos|work> I don't want to have to install things like MySQL on my EeePC...
-[21:13:52] <xiando> they're censoring the chatroms! protest!
-[21:13:53] <scarabeus> mysql only pseudoproffesional db :(
-[21:13:55] <bonsaikitten> it can handle millions of items, why can't it handle 6k songs?
-[21:14:05] <bonsaikitten> scarabeus: be quiet please :D
-[21:14:09] <Sput> sqlite can's work remotely though
-[21:14:12] <Sput> *can't
-[21:14:13] <xiando> 6k should be enough for anybody
-[21:14:22] <Sput> amarok upstream is not willing to maintain more than one backend
-[21:14:27] <bonsaikitten> Sput: uhm ... yeah ... let me just stab you a bit
-[21:14:30] <scarabeus> bonsaikitten: well i am doing some things as db specialist, so i know what is good db, and mysql never was such thing :D
-[21:14:32] -*- yngwin has 21k
-[21:14:34] <cryos|work> Why do I care if it can work remotely?
-[21:14:43] <Sput> and yes, they didn't properly design their db access :p
-[21:14:52] <scarabeus> thanks to embeded, they need to run on local machine which is also great
-[21:14:53] <scarabeus> :D
-[21:14:53] <bonsaikitten> scarabeus: I've worked with sqlite and currently have >50 MySQL servers to babysit
-[21:14:59] <Sput> cryos|work: many people share their db over several instances
-[21:15:07] <scarabeus> bonsaikitten: hope you enjoy it :]
-[21:15:10] <Sput> cryos|work: I have a central file server, and with amarok1 I used to have a central database
-[21:15:11] <cryos|work> Yeah, but everyone?
-[21:15:18] <xiando> I like Amarok 2.0.
-[21:15:19] <cryos|work> I certainly don't.
-[21:15:23] <bonsaikitten> scarabeus: I could tell you things, but then I'd have to shoot me
-[21:15:30] <scarabeus> :D
-[21:15:31] <-- Aw0L (n=awol@mx1.spfldsparc.org) has quit (Read error: 104 (Connection reset by peer))
-[21:15:31] <-- St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has quit (Operation timed out)
-[21:15:35] <cryos|work> I loved amarok, love the look of amarok 2.
-[21:15:37] <xiando> is this a good time to mention that I'd like koffice snapshots in kde-testing?
-[21:15:41] <cryos|work> We are drifting off topic though.
-[21:15:44] <scarabeus> hey i found one non flame topic
-[21:15:49] <scarabeus> MONO bindings in kde4
-[21:15:50] <yngwin> ok, before this becomes a flamefest, anything else on meeting?
-[21:15:54] <scarabeus> do we ship them or not?
-[21:15:59] <xiando> MONO is inherntly bad.
-[21:16:01] <bonsaikitten> no
-[21:16:06] <scarabeus> i volte for no
-[21:16:09] <scarabeus> !herd mono
-[21:16:14] <scarabeus> but if they will do them...
-[21:16:18] <scarabeus> there is no mono herd?
-[21:16:25] <tampakrap> lol
-[21:16:26] <cryos|work> I would go with no unless someone really wants to do it themselves.
-[21:16:27] <yngwin> do we have any apps that use them?
-[21:16:44] <scarabeus> !herd dotnet
-[21:16:45] <Willikins> scarabeus: (dotnet) compnerd, jurek, loki_val
-[21:16:58] <scarabeus> ok i will ask them if they want to create them :]
-[21:17:04] <bonsaikitten> haha
-[21:17:04] <scarabeus> otherwise they wont be shipped then
-[21:17:16] <loki_val> scarabeus: ?
-[21:17:52] <yngwin> loki_val: if you want kde-mono bindings
-[21:17:53] <scarabeus> loki_val: we have mono bindings in kde4, and nobody here uses mono, are you interested in it?
-[21:18:42] <loki_val> I use only kde3
-[21:18:58] <bonsaikitten> so it's dead :)
-[21:19:05] <loki_val> Sometime when kde4 works for me, perhaps.
-[21:19:05] <scarabeus> so its dead :]
-[21:19:16] <scarabeus> loki_val: ok i will write suspended for now :]
-[21:19:28] --> Vash63 (n=quassel@ip68-2-28-213.ph.ph.cox.net) has joined #gentoo-kde
-[21:19:31] <Sput> did we discuss the overlay situation already?
-[21:19:32] <Sput> bonsaikitten: ?
-[21:19:39] <bonsaikitten> afaik no
-[21:19:45] <bonsaikitten> might be a good time now :)
-[21:19:45] <scarabeus> nope i leave it on last thing
-[21:19:50] <scarabeus> because ti will be flame again
-[21:19:54] <scarabeus> i have one last thing
-[21:19:59] <tampakrap> no but we can't without jmbsvicetto and reavertm
-[21:20:15] <scarabeus> you know how we handle linguas in kde ebuilds
-[21:20:24] <scarabeus> how about move this magic to cmake-utils eclass
-[21:20:29] <scarabeus> so every cmake ebuild can use it
-[21:20:40] <tampakrap> agree
-[21:20:51] <ni1s> How come kde-base/kde-l10n isnt in @kdebase?
-[21:20:54] <yngwin> actually, i think there should be a generic linguas eclass
-[21:20:59] <scarabeus> ni1s: it is in @kde
-[21:21:10] <scarabeus> yngwin: well i write most abstract cmake stuff
-[21:21:22] <scarabeus> if some autotools mage wants to step in and write the same for autotools
-[21:21:24] <yngwin> ok, that could be a start
-[21:21:39] <ni1s> scarabeus, yeah, but it feels very baseish
-[21:21:59] <scarabeus> ni1s: it is not base requirement for system, and some people dont want it at all
-[21:22:35] <-- gyama (n=gyama@89.143.147.33) has left #gentoo-kde
-[21:22:41] <ni1s> scarabeus, ah ok
-[21:23:00] <scarabeus> ok i suspend the move to cmake utils eclass for now
-[21:23:05] <scarabeus> lets see how time evolve then :]
-[21:23:14] <scarabeus> i will try to talk someone to try it on autotools :]
-[21:23:33] <scarabeus> ok now we get to highly awaited topic
-[21:23:52] <scarabeus> too many overlays someone says :] merge kde-testing to kde-crazy or keep them splitted
-[21:23:53] <alexxy> overlays?
-[21:24:00] <scarabeus> i personaly want them splitted like they are
-[21:24:04] <bonsaikitten> merge
-[21:24:08] --> ivanich (n=ivanich@ivanich.tenet.odessa.ua) has joined #gentoo-kde
-[21:24:10] <tampakrap> cryos|work said we should define a policy
-[21:24:11] <hwoarang> split
-[21:24:20] <bonsaikitten> there's too many changes that don't get applied to the other
-[21:24:27] <tampakrap> but it is hard to maintain and sync changes between reavertm and alexxy :)
-[21:24:43] <scarabeus> that is good point
-[21:24:45] <alexxy> yes
-[21:24:53] <scarabeus> but what about users that want only test something that is almost ready
-[21:24:59] <wired^> split feels better assuming the eclasses are always in sync (or different per overlay)
-[21:25:00] <scarabeus> we should use package masks?
-[21:25:00] <alexxy> so we should efine policy for commiting tio overlays
-[21:25:18] <tampakrap> yes it is easier to maintain this way
-[21:25:23] <alexxy> since no one merge changes from one overlay to other if he commit something
-[21:25:32] <tampakrap> personally my main duties was the syncing
-[21:25:37] <tampakrap> *were
-[21:25:42] <scarabeus> we can have merging supervisor ;]
-[21:25:47] <scarabeus> tampakrap was great one :D
-[21:25:55] <tampakrap> but didn't want to :)
-[21:25:57] <Sput> merge
-[21:26:18] <yngwin> depends how much syncing is needed
-[21:26:26] <alexxy> to my mind its better to merge overlays again
-[21:26:29] <scarabeus> quite much
-[21:26:41] <scarabeus> well i like the split only from users view
-[21:26:43] <yngwin> then i can imagine having 1 overlay would be better
-[21:26:43] <alexxy> and keep live stuff masked + unkeyworded
-[21:26:53] <yngwin> just keep live unkeyworded
-[21:27:06] <yngwin> only hardmask stuff that is known not to work
-[21:27:08] <scarabeus> if we are able to make visible only mature stuff for users which first checkout
-[21:27:10] <scarabeus> i am for merge too
-[21:27:21] <alexxy> two overlays is realyhard to maintain
-[21:27:25] <tampakrap> profile.mask is the solution
-[21:27:32] <yngwin> no
-[21:27:44] -*- cryos|work was getting coffee and doing work...
-[21:27:59] <yngwin> kde-testing stuff can go ~arch, and crazy stuff unkeyworded
-[21:28:00] <alexxy> scarabeus: we can mask all live stuff
-[21:28:07] <scarabeus> live stuff is already masked
-[21:28:08] <tampakrap> right
-[21:28:14] <scarabeus> ok that sounds reasonable
-[21:28:16] <tampakrap> no it isn't
-[21:28:29] <tampakrap> it isn't hardmasked i mean
-[21:28:31] <cryos|work> If it is unkeyworded it is enough.
-[21:28:32] <scarabeus> about masking
-[21:28:39] <scarabeus> oh
-[21:28:42] <scarabeus> my bad
-[21:28:47] <cryos|work> You have to specially keyword and checkout an overlay.
-[21:28:50] <alexxy> its better to have live stuff p.masked also
-[21:28:58] <cryos|work> If it makes you happy.
-[21:29:02] <scarabeus> :D
-[21:29:04] <yngwin> alexxy: why? unkeywording is enough
-[21:29:14] <scarabeus> unkeywording is indeed enought
-[21:29:21] <tampakrap> no it isn't
-[21:29:21] <scarabeus> i have to drink my cure, brb
-[21:29:28] <tampakrap> in case of phonon it isn't
-[21:29:34] <alexxy> yngwin: its too easy for user to unmask live stuff by error
-[21:29:36] <cryos|work> It is already in an overlay, and has no keywords. You have to specifically keyword **/
-[21:29:46] <-- Vash63 (n=quassel@ip68-2-28-213.ph.ph.cox.net) has quit (Read error: 54 (Connection reset by peer))
-[21:29:46] <cryos|work> It isn't too easy.
-[21:29:47] <tampakrap> people symlink everything and live phonon gets installed in snapshots' machines
-[21:29:52] <yngwin> alexxy: they need to specifically add ** keyowrds
-[21:29:57] <cryos|work> If it makes you happy and you stop bickering you can mask it too.
-[21:29:59] <-- hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has quit (Connection timed out)
-[21:30:07] --> hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has joined #gentoo-kde
-[21:30:10] <cryos|work> I think it is overkill though.
-[21:30:13] <yngwin> symlinking unmask is easy too
-[21:30:19] <tampakrap> yeah but they symlink the whole p.keywords folder even if i splitted it for every version
-[21:30:29] <yngwin> that is users fault
-[21:30:34] <tampakrap> the solution is a clear guide then
-[21:30:35] --> St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has joined #gentoo-kde
-[21:30:39] <yngwin> yes
-[21:30:41] <tampakrap> not two overlays
-[21:30:46] <cryos|work> You cannot prevent stupid users from doing stupid things.
-[21:30:57] <cryos|work> Just provide a clear path and reasonable policies.
-[21:31:02] <yngwin> indeed
-[21:31:05] --> Vash63 (n=quassel@ip68-2-28-213.ph.ph.cox.net) has joined #gentoo-kde
-[21:31:14] <cryos|work> It is too easy for a user to type rm -rf /
-[21:31:21] <tampakrap> lol
-[21:31:21] <scarabeus> :D
-[21:31:24] <wired^> lol
-[21:31:30] <alexxy> cryos|work: this wil not work =)
-[21:31:34] <scarabeus> cryos|work: so what is your merge/split statement :D
-[21:31:42] <alexxy> i mean rm -rf / will not work
-[21:31:48] <alexxy> =)
-[21:31:53] <wired^> [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo "You live"
-[21:31:53] <cryos|work> I would merge, but don't mind too much.
-[21:32:01] <yngwin> brb
-[21:32:09] <cryos|work> rm -rf /* then?
-[21:32:11] <scarabeus> ok so far the voltes are:
-[21:32:18] <scarabeus> yngwin: merge
-[21:32:18] <scarabeus> kitten: merge
-[21:32:18] <scarabeus> scarab: merge
-[21:32:18] <scarabeus> tampakrap: merge
-[21:32:18] <scarabeus> reavertm: merge
-[21:32:18] <scarabeus> alexxy: merge
-[21:32:18] <scarabeus> cryos: dont mind merge
-[21:32:22] <cryos|work> Still to easy...
-[21:32:31] <scarabeus> so i guess we will again have one overlay :D
-[21:32:33] <tampakrap> also sput merge
-[21:32:34] <cryos|work> I would go with, but won't cry if you don't ;-)
-[21:32:46] <jmbsvicetto> Hi
-[21:32:48] <scarabeus> :D
-[21:32:51] <cryos|work> Hey - he's here!
-[21:32:53] <tampakrap> HELLOOOOO
-[21:32:56] <jmbsvicetto> sorry guys, but I've been tied up at work :\
-[21:32:57] <scarabeus> hi!
-[21:32:57] <tampakrap> it's alive!!!!!
-[21:33:08] <scarabeus> its moving, RUN :D
-[21:33:11] <tampakrap> ok meeting is over we have one overlay end of the story bye
-[21:33:13] <jmbsvicetto> I'm very sorry, but I had expected to be free for the meeting
-[21:33:15] <cryos|work> I need to mostly disappear and get some work done...
-[21:33:30] <cryos|work> Sorry I missed you jmbsvicetto.
-[21:33:43] -*- cryos|work out - will read ML summary if there is one...
-[21:33:43] <jmbsvicetto> I'll have to grab dinner in around 15 minutes. Is there anything I can clear up / explain / detail ?
-[21:33:50] <jmbsvicetto> cryos|work: Hi. I'm sorry too
-[21:34:09] <cryos|work> jmbsvicetto: Life happens. We tried not to steam roll stuff ;-)
-[21:34:27] <cryos|work> I do need to go though.
-[21:34:30] <scarabeus> jmbsvicetto: we were volting about merge/split overlays and all volted for merge or dont mind merge :D
-[21:34:54] <jmbsvicetto> About the tasks I was expected to do from the last meeting: 1. mysql - I'm stuck at the patch in the bug - I wasn't able to do more yet. 2. contact people to check whether they want to be in the kde team - I'm sorry, but I didn't got this done.
-[21:35:01] <jmbsvicetto> cryos|work: hehe
-[21:35:03] <jmbsvicetto> cryos|work: later
-[21:35:11] <scarabeus> :D
-[21:35:20] <jmbsvicetto> scarabeus: ok, so my vote would have lost
-[21:35:27] --> tinytony_ (n=tinytony@77.53.34.198) has joined #gentoo-kde
-[21:35:37] <jmbsvicetto> scarabeus: what was the 3rd task I had to do?
-[21:35:37] <scarabeus> jmbsvicetto: ok for the mails i guess you will do it in future so no biggie in that
-[21:35:54] <scarabeus> jmbsvicetto: the third one i did instead of you
-[21:35:55] <scarabeus> :D
-[21:36:09] <jmbsvicetto> Yeah, I'll try to get it done this week. I can also tell you some of them are under undertakers notice
-[21:36:16] <jmbsvicetto> scarabeus: what was it?
-[21:36:20] <jmbsvicetto> scarabeus: eclasses?
-[21:36:23] <scarabeus> eapi2only eclasses
-[21:36:25] <scarabeus> which i handled
-[21:36:37] <jmbsvicetto> scarabeus: Thanks and sorry for leaving it up to you
-[21:36:52] <scarabeus> no problem really, i had time so i did it :]
-[21:36:58] <scarabeus> at least i know the eclass pretty well :]
-[21:37:04] <jmbsvicetto> hehe
-[21:37:15] <jmbsvicetto> scarabeus: want to know mysql "intimately"? ;)
-[21:37:18] <tampakrap> are we ok with moving eclasses to the tree?
-[21:37:28] <yngwin> back
-[21:37:44] <scarabeus> looks like i will do it on saturday i guess
-[21:37:46] <jmbsvicetto> scarabeus: I noticed reavertm seemed to find a bug in the eclasses related to the blocks
-[21:37:48] <scarabeus> tampakrap: ^
-[21:38:00] <jmbsvicetto> Were you able to sort that out?
-[21:38:02] <scarabeus> jmbsvicetto: ok one bug, needs to be fixored
-[21:38:10] <scarabeus> jmbsvicetto: he didnt tell me a thing
-[21:38:20] <Sput> btw I even think that merging the overlays is less confusing for users than the current state, where they always need to ask around which overlay contains what
-[21:38:21] <jmbsvicetto> I think he sent a mail to the desktop alias
-[21:38:32] <Sput> there should be only one official gentoo KDE overlay one can point people
-[21:38:35] <jmbsvicetto> Sput: I also didn't do the blog entry :\
-[21:38:40] <scarabeus> oh i see
-[21:38:50] <Sput> jmbsvicetto: which blog entry?
-[21:38:57] <scarabeus> btw alexxy has review tomorow in case you dont know
-[21:39:03] <jmbsvicetto> The one I was going to explain it (the overlays)
-[21:39:08] <jmbsvicetto> scarabeus: I didn't
-[21:39:10] <jmbsvicetto> alexxy: Good luck :)
-[21:39:18] <alexxy> jmbsvicetto: thanks
-[21:39:19] <alexxy> =)
-[21:39:35] <scarabeus> and i guess we should pronounce the meeting over uness jmbsvicetto has something new he wants to adres
-[21:39:42] <jmbsvicetto> alexxy: I'm going to be busy tonight, but if you want / need to ask something, poke me until I reply ;)
-[21:39:42] <scarabeus> oh missing letters, shame on me
-[21:39:55] <jmbsvicetto> scarabeus: No, nothing to add
-[21:40:14] <scarabeus> unit DISMISS!
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090305.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090305.txt
deleted file mode 100644
index a52c5351e3..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090305.txt
+++ /dev/null
@@ -1,769 +0,0 @@
-[21:08:49] <scarabeus> LETS BEGIN :D
-[21:09:07] <scarabeus> so first nice question is
-[21:09:10] <scarabeus> WHO IS AROUND?
-[21:09:16] <NoirSoldats> o/
-[21:09:17] <yngwin> !herd kde
-[21:09:21] <Willikins> yngwin: (kde) alexxy, caleb, carlo, cryos, deathwing00, genstef, jmbsvicetto, keytoaster, mattepiu, patrick, scarabeus, tampakrap, tgurr
-[21:09:21] <yngwin> !herd qt
-[21:09:22] <Willikins> (qt) caleb, carlo, hwoarang, yngwin
-[21:09:24] -*- wired is here
-[21:09:29] -*- yngwin is present
-[21:09:37] -*- alexxy here
-[21:09:50] <bumbl> xine-lib-9999 does not compile yngwin because of missing Makefile.in
-[21:09:50] *** Mode #gentoo-kde +v reavertm by scarabeus
-[21:10:22] <scarabeus> where are the other slackers :P
-[21:10:37] <wired> slacking
-[21:10:38] <wired> :p
-[21:10:54] <yngwin> bumbl: see forum thread. if there is a patch/solution, i will apply it (tonight or tomorrow)
-[21:10:58] -*- cryos|work is kinda here, ill, stressed...
-[21:11:19] <scarabeus> cryos|work: hi :]
-[21:11:59] <-- KotBehemot (n=dracul66@unaffiliated/kotbehemot) has quit (Remote closed the connection)
-[21:12:03] <jmbsvicetto> ping
-[21:12:20] <jmbsvicetto> Sorry for being late
-[21:12:22] <scarabeus> ok we are closing onto desired goal >50% around :]
-[21:12:22] <cryos|work> I think you need to ping an address, or is that a broadcast packet?
-[21:12:24] <hwoarang> here
-[21:12:34] <-- genady12__ (n=genady12@80.178.17.222.adsl.012.net.il) has quit (Read error: 110 (Connection timed out))
-[21:12:54] <alexxy> where is our main slacker? bonsaikitten are you here?
-[21:12:56] <alexxy> =)
-[21:13:09] <bonsaikitten> am I ?
-[21:13:16] <bonsaikitten> yes!
-[21:13:29] <jmbsvicetto> cryos|work: broadcast ping ;)
-[21:13:34] <scarabeus> ok so i guess we can start, others would have to show up later...
-[21:13:37] <scarabeus> any objections?
-[21:13:54] <yngwin> none
-[21:13:57] <jmbsvicetto> who are we missing?
-[21:13:59] <alexxy> =)
-[21:14:02] <yngwin> tampa
-[21:14:05] <Philantrop> Carlo! ;->
-[21:14:05] <scarabeus> tampakrap i guess and reaver
-[21:14:14] <jmbsvicetto> Philantrop: :P
-[21:14:17] <scarabeus> Philantrop: you actualy get him on irc at some point? :]
-[21:14:17] <jmbsvicetto> Hi Wulf
-[21:14:30] <Philantrop> scarabeus: No, he never was nor will he ever.
-[21:14:34] <bonsaikitten> Hi Phil :)
-[21:14:34] <Philantrop> jmbsvicetto: Hello! :-)
-[21:14:39] <scarabeus> hehe
-[21:14:52] <jmbsvicetto> scarabeus: carlo is a "mail" guy
-[21:14:52] --> KotBehemot (n=dracul66@unaffiliated/kotbehemot) has joined #gentoo-kde
-[21:15:05] <scarabeus> yea i got that :]
-[21:15:14] <Philantrop> jmbsvicetto: ... if he communicates at all.
-[21:15:37] <jmbsvicetto> Philantrop: well, a reply to a 4 or 6 month mail is still a reply :P
-[21:15:40] <scarabeus> http://www.pastebin.cz:80/15872
-[21:15:44] <Philantrop> jmbsvicetto: :-) True.
-[21:15:48] <tampakrap> i'm here
-[21:15:50] <scarabeus> here is a list what we will chat about today
-[21:15:53] <scarabeus> hello tampy
-[21:15:59] <wired> tampy!
-[21:16:03] <wired> lol
-[21:16:32] -*- cryos|work only claims 42% presence --- man flu...
-[21:16:44] <scarabeus> ok so we can start with kde3.5.10 state
-[21:16:50] <bumbl> cryos|work: get well soon
-[21:16:51] <scarabeus> cause on that we all probably will just listen :D
-[21:16:52] <tampakrap> i'd like to say a few things about KDE 3 first
-[21:17:17] <tampakrap> may I?
-[21:17:20] <jmbsvicetto> Hi Theo
-[21:17:21] <scarabeus> yes proceed
-[21:17:22] <yngwin> say
-[21:17:32] <tampakrap> ok
-[21:17:39] <jmbsvicetto> cryos|work: yeah, my cold has been bugging me for the past week :\
-[21:17:50] <tampakrap> in kde-testing i have a kde-3.5 branch with new eclasses
-[21:18:13] <tampakrap> those eclasses prefix misc kde apps in /usr/kde/3.5 and permit eapi2 ebuilds
-[21:18:38] <tampakrap> i have started writing all kde-base ebuilds in eapi 2 i have about 60 here
-[21:19:02] <tampakrap> jmbsvicetto told me today to try to get rid of arts and use a different backend
-[21:19:18] <tampakrap> i'm not sure if this can be done and to be honest i don't know if it worths it
-[21:19:24] <tampakrap> i'd like your opinion
-[21:19:24] -*- jmbsvicetto looks innocently into the sky
-[21:19:37] <tampakrap> and of course some testing of you people
-[21:19:53] <jmbsvicetto> tampakrap: if it's too much work, forget arts
-[21:19:54] <bonsaikitten> kill arts.
-[21:20:05] <yngwin> in my opinion kde 3.5.10 works as is, and i wouldnt spend too much time on 'improving' the ebuilds
-[21:20:07] <tampakrap> especially the kde4 guys, as the pending big issue is the proper use of kde3 apps inside kde4 environment
-[21:20:12] <jmbsvicetto> tampakrap: I was just interested to find out if we could kill it
-[21:20:21] <Philantrop> jmbsvicetto: You could.
-[21:20:22] --> looonger (n=looonger@host-89-231-128-7.rawamaz.mm.pl) has joined #gentoo-kde
-[21:20:43] <wired> tampakrap: have you done any changes to the eclasses since we lasted talked about them?
-[21:20:46] <scarabeus> i agree with killing
-[21:20:53] <jmbsvicetto> Philantrop: we should, but meh :\
-[21:20:57] <yngwin> give peas a chance
-[21:21:17] <tampakrap> wired: yes but not pushed
-[21:21:17] <Philantrop> jmbsvicetto: I wouldn't do it anymore. It's not worth the effort anymore.
-[21:21:24] <jmbsvicetto> yeah, I agree
-[21:21:50] <scarabeus> it was allways broken from my POV and it is not worth the problems with it i guess
-[21:21:57] <jmbsvicetto> tampakrap: how can we help you getting it done?
-[21:22:02] <wired> tampakrap: ok, just asking because last time i used them [by accident] kdebluetooth failed to install
-[21:22:23] <scarabeus> wired: most of the bugs i tried to fix
-[21:22:24] <yngwin> kdebluetooth is problematic anyway
-[21:22:30] <yngwin> should probab;ly be hardmasked
-[21:22:30] <tampakrap> jmbsvicetto: i'll ping you guys when i need help don't worry
-[21:22:41] <jmbsvicetto> tampakrap: If you think the eclasses are "almost done", you should probably merge them to the master branch
-[21:22:54] <wired> yngwin: it works fine for me (with bluez < 4)
-[21:22:57] <tampakrap> yes i'm about to do it
-[21:23:03] <jmbsvicetto> ok :)
-[21:23:14] <scarabeus> ok
-[21:23:31] --> scratch[x] (n=scratch@83.239.148.148) has joined #gentoo-kde
-[21:23:46] <tampakrap> but i  agree with Philantrop it is not worth the effort, everyone is moving to kde4.2, just a quick cleanup of kde3 is enough
-[21:23:53] <scarabeus> yep
-[21:23:59] <yngwin> on a related note, i want to mask ~qt-3.3.8 for removal, and leave only ~qt-3.3.8b in tree
-[21:24:05] <tampakrap> and i am more intrested in kde4 too
-[21:24:30] <alexxy> kde 3.5.x is old =)
-[21:24:31] <tampakrap> yngwin: feel free
-[21:24:31] <-- er0x (n=kvirc@client-87-247-122-156.inturbo.lt) has quit ("KVIrc Insomnia 4.0.0, revision: , sources date: 20090224, built on: 2009/03/04 18:54:25 UTC http://www.kvirc.net/")
-[21:24:56] <yngwin> alexxy: maybe old, but it works ;)
-[21:25:02] <scarabeus> :]
-[21:25:04] <jmbsvicetto> yngwin: Is anything holding qt-3.3.8 around?
-[21:25:13] <jmbsvicetto> yngwin: looking at keywords I see they're the same
-[21:25:15] <yngwin> i thought kdebluetooth
-[21:25:30] <tampakrap> ok about kdebluetooth
-[21:25:31] <jmbsvicetto> ah, ok
-[21:25:38] <yngwin> not 100% sure, will look tomorrow
-[21:25:43] <bumbl> there might be some users who still want to use kde 3.5 until ~ kde 4.4 (which is when all the third party developers will have ported their apps (hopefully))
-[21:25:51] <scarabeus> NOTE: (guys i found out that my loging is not working with this weechat version so i will write summary and somebody else will have to put the log on devspace)
-[21:26:08] <jmbsvicetto> bumbl: hmm, besides k3b, which major apps are still missing?
-[21:26:09] -*- wired keeps logs
-[21:26:11] <tampakrap> bumbl: it's no reason to wait for them to release, we can provide working snapshots
-[21:26:17] <tampakrap> jmbsvicetto: nothing!
-[21:26:20] <jmbsvicetto> scarabeus: I have logs, don't worry
-[21:26:23] <scarabeus> ouk
-[21:26:40] <yngwin> jmbsvicetto: k3b, konversation, that i know
-[21:26:46] <scarabeus> kile
-[21:26:48] <scarabeus> and others
-[21:26:51] <bumbl> jmbsvicetto: kaffeine4 is still very basic (kaffeinegl seems dead)
-[21:26:53] <scarabeus> kde3 is still needed
-[21:26:54] <yngwin> quanta!!!!!!!!!!
-[21:26:56] <alexxy> kile works from :live
-[21:27:07] <_genuser_> qt-core is almost done.
-[21:27:08] <alexxy> k3b dont at this moment
-[21:27:09] <scarabeus> live is not good for normal users :]
-[21:27:13] <jmbsvicetto> yngwin: I liked quanta :)
-[21:27:13] <tampakrap> ok about kdebluetooth i'll have a look at it and try to find the very best solution
-[21:27:16] <_genuser_> then more hours for kdelibs.
-[21:27:21] <Sho_> Konversation's KDE 4 port is shaping up nicely, so that will be gone from the list soon.
-[21:27:27] <wired> jmbsvicetto: yeah quanta is badly missing
-[21:27:35] <alexxy> we can make snapshots for kile
-[21:27:36] <alexxy> =)
-[21:27:43] <yngwin> jmbsvicetto: i was hoping for quanta with vimpart
-[21:27:44] <scarabeus> blah
-[21:27:47] <_genuser_> I'm so excited that in 2 days I can finally run kde4.2. :)
-[21:28:06] <_genuser_> that was sarcastic.
-[21:28:09] <bumbl> shouldn't kdevelop4 replace quanta?
-[21:28:09] <_genuser_> hopefully it runs soon.
-[21:28:10] <Bluespear> jmbsvicetto: Kile
-[21:28:14] <tampakrap> we can make snapshots for many packages and maybe we can start doing it
-[21:28:15] <scarabeus> tampakrap: do you need our help somewhere on kde3?
-[21:28:30] <Bluespear> using TexClipse and this just sucks :D
-[21:28:36] <tampakrap> scarabeus: not now maybe in a few days
-[21:28:52] <jmbsvicetto> oh and obviously we still a "working" amarok ;)
-[21:29:00] <bumbl> genady12_: ah that's why my sarcasm detector went wild
-[21:29:16] <jmbsvicetto> scarabeus: next? getting 3.5.10 stabled?
-[21:29:21] <tampakrap> people please we have a meeting here...
-[21:29:26] <tampakrap> right
-[21:29:29] <scarabeus> hehe lets wait what tampakrap shows us
-[21:29:43] <scarabeus> for now lets fix the prefixing
-[21:29:45] <scarabeus> :]
-[21:29:51] <scarabeus> we still have  ~2 months :D
-[21:30:06] <jmbsvicetto> For getting 3.5.10 marked as stable? :\
-[21:30:08] <yngwin> why? there's no need to keep 3.5.10 from going stable
-[21:30:12] <Sho_> scarabeus: remember my kepas thing *g*
-[21:30:15] <jmbsvicetto> I was hoping to do it next month
-[21:30:18] <tampakrap> as i said the main issue is running kde3 apps inside kde4 env that's where i need help and testing
-[21:30:22] <yngwin> THIS month
-[21:30:32] <jmbsvicetto> yngwin: :)
-[21:30:33] <tampakrap> how can we do it this month with so many bugs open?
-[21:30:36] <scarabeus> jmbsvicetto: for 4.2 starting its consideration :D
-[21:30:48] <-- ABCD (n=ABCD@wikipedia/ABCD) has quit (Client Quit)
-[21:31:03] <scarabeus> ok this leads to the virtualbox snapshots i talked about
-[21:31:09] <yngwin> tampakrap: can you make a list of the important bugs that need fixing? so we can work on that, and ask users (bugday!) to help
-[21:31:14] <scarabeus> we should create some generic gentoo instalation with kde3 and kde4 for testing
-[21:31:17] <tampakrap> yes i can
-[21:31:27] --> ABCD (n=ABCD@wikipedia/ABCD) has joined #gentoo-kde
-[21:31:28] <yngwin> that would be helpful
-[21:31:37] <wired> scarabeus: Im on that
-[21:31:51] <tampakrap> i should separate kde base bugs from the misc ones as a first step
-[21:31:52] <jmbsvicetto> yngwin / tampakrap: I think the most imporant point to get 3.5.10 marked as stable is getting the eclasses in the tree
-[21:31:56] <NoirSoldats> wired: How is that coming? Do you need my help?
-[21:32:26] <jmbsvicetto> brb
-[21:32:31] * tampakrap has changed topic for #gentoo-kde to: "MEETING NOW | Official gentoo-kde project channel | KDE 4 guide: http://tinyurl.com/4n47v4 | Overlays: kde-testing, qting-edge | Want to help us? Ask channel staff for info | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | KDE 4.2.1 is available | Weird issues with nvidia-drivers-180.35? bug 260441 | Qt 4.5.0 committed"
-[21:32:34] <wired> NoirSoldats: well with 4.2.1 and all it kinda fell behind, but its cool, i figured out how to compact the thing as well so its more a matter of time now
-[21:32:49] <tampakrap> i think we're done with kde3
-[21:32:57] <scarabeus> if nobody has questions on ya
-[21:33:08] <NoirSoldats> wired: I'm here if ya need me or my processors. :)
-[21:33:31] <wired> alright, we'll talk about it after the meeting
-[21:33:32] <tampakrap> oh the last i wanted to tell about kde3
-[21:33:34] --> panard (n=panard@2a01:e35:8a09:e130:2e0:61ff:fe11:7adb) has joined #gentoo-kde
-[21:33:34] <comawhite> anyone ever noticed you can compile all of koffice-2 except Krita
-[21:33:50] <scarabeus> comawhite: i know, not now, later i will talk with you
-[21:34:04] <comawhite> okay
-[21:34:23] <tampakrap> carlo is doing an excellent job with kde3 misc apps he closed many bugs but he is never on irc, has anyone contacted him ever?
-[21:34:33] <bonsaikitten> only by email
-[21:34:52] <yngwin> i gave up after he didnt answer my emails last year
-[21:35:00] <tampakrap> ok i'll keep that in mind
-[21:35:05] <-- Bluespear (n=speedy@dhcp-83-219-104-51.customers.tvtnet.ch) has quit ("Leave")
-[21:35:06] <jmbsvicetto> tampakrap: You should use mail to talk to carlo
-[21:35:07] <scarabeus> tampakrap: only by mail, or best is creating bug with high priority assigned to him
-[21:35:11] <scarabeus> that is how i contacted :D
-[21:35:22] <tampakrap> ok
-[21:35:49] <scarabeus> ok next thingie is:
-[21:35:55] <scarabeus> we need somebody maintain the amarok
-[21:36:10] <yngwin> not me
-[21:36:18] <alexxy> not me =)
-[21:36:23] <NoirSoldats> hehe
-[21:36:24] <scarabeus> is anyone from us willing to be official maintainer?
-[21:36:25] <tampakrap> both kde3 and 4?
-[21:36:29] <scarabeus> yeah both
-[21:36:32] <jmbsvicetto> scarabeus: I haven't looked at 5.1.72 yet (mysql), but I'll get back to it this week
-[21:36:34] <tampakrap> omg
-[21:36:37] --> eyal_ (n=eyal@IGLD-80-230-109-116.inter.net.il) has joined #gentoo-kde
-[21:36:51] <jmbsvicetto> scarabeus: I don't think amarok for kde3 should require much work
-[21:36:55] <scarabeus> jmbsvicetto: :P
-[21:37:00] --> mschiff (n=mschiff@e176096142.adsl.alicedsl.de) has joined #gentoo-kde
-[21:37:05] <scarabeus> jmbsvicetto: well not much work but minor bugz are poping up
-[21:37:06] <tampakrap> jmbsvicetto: no it does :)
-[21:37:10] <scarabeus> so polishing it needs
-[21:37:17] <jmbsvicetto> :\
-[21:37:25] <tampakrap> it is a mess, pretty abandoned
-[21:37:42] <yngwin> yes, flameeyes tried to drop it on me
-[21:37:44] <scarabeus> i guess we could sent mail on -dev
-[21:37:48] <jmbsvicetto> amarok-1.4 ?
-[21:37:54] <yngwin> indeed
-[21:38:11] <yngwin> as i offered to help at the time when he had to go to hospital
-[21:38:40] <scarabeus> hehe
-[21:38:54] <yngwin> he assigned all amarok bugs to me
-[21:38:55] <scarabeus> soo do we have suicider, erm i mean maintainer...
-[21:38:59] <tampakrap> btw amarok-2.2 released
-[21:39:04] <scarabeus> tampakrap: yeah i know
-[21:39:20] <alexxy> tampakrap: what?!
-[21:39:24] <scarabeus> 2.0.2
-[21:39:28] <scarabeus> he cant write
-[21:39:29] <scarabeus> :D
-[21:39:32] <tampakrap> look i'm a big fun of amarok but until the end of the month i'll be pretty busy with some things and i can't take it
-[21:39:43] <scarabeus> yes i know i am not saying you should
-[21:39:45] <yngwin> we could just hardmask it and assign to maintainer-needed ;)
-[21:39:58] <scarabeus> ok i will sent the mail on the dev you lazy ....
-[21:40:00] <scarabeus> :D
-[21:40:01] <hwoarang> i wonder if amarok compiles with qt-4.5 now
-[21:40:11] <NoirSoldats> hwoarang: Mine did.
-[21:40:19] <alexxy> hmm
-[21:40:26] <hwoarang> so does here  but the upstream bug is still open
-[21:40:27] <NoirSoldats> hwoarang: With a little hacking.
-[21:40:31] <alexxy> we can add amarok 2.0.2 to overlay
-[21:40:36] <hwoarang> and reproducable by many users
-[21:40:36] <alexxy> to see if it works
-[21:40:41] <jmbsvicetto> scarabeus: add me silently to the amarok bugs
-[21:40:42] <hwoarang> +1 to alexxy
-[21:41:01] <scarabeus> jmbsvicetto: ok adding as note if you are really sure :]
-[21:41:09] <jmbsvicetto> yup
-[21:41:16] <jmbsvicetto> scarabeus: I'll take a look at it
-[21:41:23] <tampakrap> will the kde-herd and sound-herd maintainers remain though?
-[21:41:33] <scarabeus> yes of course :]
-[21:41:41] <scarabeus> ok amarok is done i think :]
-[21:41:56] <yngwin> i dont think anyone @sound is really interested
-[21:42:16] <scarabeus> now i have "homepage updates" it means that we have pretty much tons of outdates info on webspace, in doc and in informations
-[21:42:23] <tampakrap> i don't care for sound-herd after all :)
-[21:42:28] <scarabeus> so we need somebody that will actualy try to keep that up-to-date
-[21:42:39] -*- tampakrap 
-[21:42:43] <yngwin> tampakrap: careful, i am in sound :p
-[21:42:45] <tampakrap> next subject :)
-[21:42:54] <tampakrap> :P
-[21:43:08] <scarabeus> tampakrap: you will really keep the web updated? are you sure it is lots of pages and lots of stuff :]
-[21:43:23] <scarabeus> specialy now main page and the guide needs heavy lifting
-[21:43:29] <scarabeus> so do you have time?...
-[21:43:33] <yngwin> i can help
-[21:43:36] <tampakrap> look as i said until the end of a month i'll be pretty busy with some things, next i'll have too much free time
-[21:43:49] <tampakrap> i'll take care of the guide though
-[21:44:14] <scarabeus> ok you two, try to work it out somehow then :]
-[21:44:30] <scarabeus> bonsaikitten: ping
-[21:44:33] <scarabeus> now i need you :]
-[21:44:36] <bonsaikitten> what!
-[21:44:39] <tampakrap> wait a minute
-[21:44:46] <bonsaikitten> I'm just providing access to tarballs ;)
-[21:45:02] <scarabeus> bonsaikitten: nope, i need YOU to take look on pykde bugs, and actualy fix them
-[21:45:10] <bonsaikitten> yeah
-[21:45:11] <scarabeus> since you are most relevant for this
-[21:45:14] <tampakrap> one quick note about the guide, people when you are fixing major stuff please do the guide fixes too immediately or assign it to someone, but it is a must
-[21:45:23] <bonsaikitten> scarabeus: I claim incompetence ;)
-[21:45:32] <bonsaikitten> been quite busy with work, maybe I find some time during the weekend
-[21:46:14] <scarabeus> greatie
-[21:46:21] <scarabeus> bonsaikitten: feel free to even remove it from kdeprefix
-[21:46:32] <bonsaikitten> well, first gotta fix slotting
-[21:46:37] <scarabeus> yup
-[21:46:39] <bonsaikitten> then see why it randomly fails
-[21:46:46] <bonsaikitten> then learn enough C++ to fix it
-[21:46:50] <scarabeus> :D
-[21:47:24] <scarabeus> there is nothing how i could help, combo of python and cpp is overhead for me
-[21:47:25] <scarabeus> :]
-[21:47:29] <bonsaikitten> hehe
-[21:47:37] <bonsaikitten> I still have so many other bugs I want to take care of :(
-[21:47:53] <yngwin> maybe mask pykde4 then
-[21:47:59] <scarabeus> it will allways be that way, but this is one of the biggest kde4 stable blockers now
-[21:48:54] <scarabeus> yngwin: even that might be the final solution if we wont make it work
-[21:49:02] <scarabeus> althrought it would disable lots of plasmoids
-[21:49:10] <bonsaikitten> no Final Solutions here
-[21:49:20] <yngwin> now it just fails for too many ppl
-[21:49:23] <bonsaikitten> we are pacifists who give every ebuild a chance
-[21:49:34] <scarabeus> :D
-[21:49:36] <jmbsvicetto> :)
-[21:50:13] -*- bonsaikitten glares at Phil
-[21:50:59] <scarabeus> any of you have any ideas about the bluez and kbluetooth, somebody who uses it, i might make it work, but frankly i dont use it much so i might missed stuff, it needs testing and maybe even patching
-[21:51:03] <scarabeus> kbluetooth4
-[21:51:56] <bonsaikitten> so let's ask users :)
-[21:52:04] <scarabeus> bluez is hardmasked
-[21:52:06] <bumbl> just compiled pykde4-9999 successfully
-[21:52:07] <bonsaikitten>  I have no bluetooth equipment
-[21:52:12] <scarabeus> so it needs really brave insaners to test
-[21:52:25] -*- alexxy dont have bluetoth
-[21:52:33] <wired> i have bluetooth but i stopped trying with kbluetooth4 some time ago because it broke my nerves
-[21:52:36] <wired> i can test again
-[21:52:45] --> himikof (n=himikof@129.167.249.ozerki.net) has joined #gentoo-kde
-[21:52:51] --> Varox (n=Varox@p4FD441A6.dip.t-dialin.net) has joined #gentoo-kde
-[21:53:04] <scarabeus> wired: ok
-[21:53:08] <scarabeus> i will leave it up to you
-[21:53:18] <bumbl> gnokii + bluez + kdebluetooth4 + /me = /me insane
-[21:53:34] <wired> ok. i think i saw a patch for solid and bluez4 somewhere
-[21:53:39] <-- Ghabit (n=quassel@91.149.157.195) has quit ("No Ping reply in 30 seconds.")
-[21:53:41] <scarabeus> ok as sidenote and selfegomasturbation, this week i fixed KOFFICE and it works fine
-[21:53:53] <scarabeus> so we are prepared to add it for the tree :]
-[21:53:54] --> Ghabit (n=quassel@91.149.157.195) has joined #gentoo-kde
-[21:53:58] <tampakrap> i was about to ask it, what was the issue?
-[21:54:00] <bonsaikitten> yey
-[21:54:16] <scarabeus> i spent 6-7 hours on it
-[21:54:21] -*- wired writes down todo notes ^_^
-[21:54:29] <scarabeus> and developed nice cmake hate :D
-[21:54:40] <tampakrap> ok well done
-[21:54:58] --> bschindler|away (n=quassel@zux221-218-241.adsl.green.ch) has joined #gentoo-kde
-[21:55:17] <bonsaikitten> haha
-[21:55:25] <bonsaikitten> build systems seem to be very good for hate
-[21:55:30] <scarabeus> indeed
-[21:55:39] <scarabeus> but still i like it more than scons and bam
-[21:55:42] <jmbsvicetto> scarabeus: so you've finally learned to hate cmake? :P
-[21:55:53] <scarabeus> jmbsvicetto: sorry for my disbelieve
-[21:55:53] <jmbsvicetto> scarabeus: Are you feeling the love for autotools again? ;)
-[21:55:57] <scarabeus> yes :D
-[21:55:57] --> kostekjo (n=opera@chello084010120054.chello.pl) has joined #gentoo-kde
-[21:56:03] <scarabeus> cause autotools wont allow such messy code
-[21:56:08] <-- Varox (n=Varox@p4FD441A6.dip.t-dialin.net) has quit (Remote closed the connection)
-[21:56:08] <scarabeus> or i didnt see it anywhere
-[21:56:17] <jmbsvicetto> hehe
-[21:56:28] <scarabeus> reavertm: pingping
-[21:56:29] <alexxy> scarabeus: take a look @gromacs
-[21:56:30] <alexxy> =)
-[21:56:30] <jmbsvicetto> scarabeus: you should check kde autotools - it's also great ;)
-[21:56:39] <scarabeus> :D
-[21:56:39] <alexxy> to see autotools mess code
-[21:56:47] <scarabeus> ok ok dont make me ruin my ideals
-[21:56:52] <jmbsvicetto> hehe
-[21:56:59] <bonsaikitten> let's rewrite kde to use maven
-[21:57:09] <bonsaikitten> that would be orgasmic
-[21:57:14] <jmbsvicetto> bonsaikitten: let's use propper autotools :P
-[21:57:25] <bonsaikitten> jmbsvicetto: that would have been my second-best suggestion :)
-[21:57:46] <scarabeus> ok jmbsvicetto do you have some items that we need to squash for 4.2 stabling
-[21:57:54] <scarabeus> currently we get hit by only minor stuff
-[21:58:04] <scarabeus> so i am asking if you have something actualy major
-[21:58:04] --> non7top (n=non7top@77.66.156.160) has joined #gentoo-kde
-[21:58:11] <jmbsvicetto> we need to double check webkit, qt-phonon and java deps
-[21:58:21] <scarabeus> jmbsvicetto: i already did webkit optional
-[21:58:23] <jmbsvicetto> some arches don't support any or some of these
-[21:58:41] <alexxy> mips dont have java
-[21:58:50] <scarabeus> for that we have virtuoso i guess
-[21:58:53] <alexxy> at least untill icedtea6 will hit tree
-[21:58:54] <tampakrap> isn't the java issue fixed for soprano and such?
-[21:58:56] <scarabeus> btw that package needs to be splitted
-[21:58:58] <yngwin> which reminds me, can we make all deps in kde4-base.eclass optional?
-[21:59:03] <scarabeus> cause it is 150mb big as one
-[21:59:11] <scarabeus> yngwin: talk with me later about it
-[21:59:15] <yngwin> ok
-[21:59:16] <scarabeus> i am open for suggestions
-[21:59:56] <-- S-man (n=quassel@cc84863-b.zwoll1.ov.home.nl) has quit (Remote closed the connection)
-[22:00:09] <tampakrap> i'll repeat, isn't the java issue fixed?
-[22:00:18] <alexxy> tampakrap: seems yes
-[22:00:34] <alexxy> at least i have sane deps tree on mips
-[22:00:38] <jmbsvicetto> tampakrap / alexxy: Have you talked to ali_bush about that?
-[22:00:49] <wired> i talked with ali_bush
-[22:00:51] <jmbsvicetto> He was reporting an issue with gen1 jvms
-[22:01:05] <wired> he said he'll look into it tomorrow
-[22:01:14] --> S-man (n=quassel@cc84863-b.zwoll1.ov.home.nl) has joined #gentoo-kde
-[22:01:41] <scarabeus> great :]
-[22:01:43] <bumbl> virtuoso does need ~15mb (the parts kde actually uses)
-[22:02:18] <scarabeus> yes but the rest is 10x bigger that is why i said that we should split it
-[22:02:27] <reavertm> (apparently)
-[22:02:54] <yngwin> (qt-)phonon is not supported/keyworded on alpha, ia64, mips, sparc and x86-fbsd
-[22:02:55] <bumbl> yep
-[22:03:12] <reavertm> stil the idea of splitting proposed by trueg is rather silly? (virtuoso-data, virtuoso-backends? it's database server :P)
-[22:03:17] <alexxy> yngwin: i'll keyword phonon on mips
-[22:03:22] <yngwin> ok
-[22:03:31] <hwoarang> alexxy: please keyword qt-demo as well
-[22:03:32] <jmbsvicetto> webkit seems to have problems at least in big endian arches
-[22:03:39] <alexxy> hwoarang: later
-[22:03:44] <hwoarang> yes
-[22:03:44] <alexxy> only after kde =)
-[22:03:52] <reavertm> btw, there is probably no more separate phonon release
-[22:04:03] <alexxy> jmbsvicetto: my mips is bigendian
-[22:04:27] <bumbl> USE-flags if possible
-[22:05:00] <jmbsvicetto> alexxy: at least for sparc and I think ppc64 webkit has alignment issues
-[22:05:41] -*- alexxy thinks that we should have abi and endianes keywords for packages
-[22:05:47] <yngwin> only sparc
-[22:05:58] <yngwin> ppc64 does have qt-webkit keyworded
-[22:06:29] <yngwin> alpha and ia64 dont
-[22:07:33] <wired> on the soprano[sesame2] java issue, it seems sesame doesn't like sun-jre-bin
-[22:08:15] <scarabeus> ok lads
-[22:08:16] <tampakrap> isn't this fixed?
-[22:08:31] <scarabeus> i will take care of easying the deps in eclass and you take care about keywording and deps :]
-[22:09:22] <reavertm> wired to build? of it doesn't like switching between sun-jdk and sun-jre-bin after it was succesfully built
-[22:09:54] --> Zucca (i=zucca@a88-112-55-25.elisa-laajakaista.fi) has joined #gentoo-kde
-[22:09:54] <wired> reavertm: when i was testing it it would skip sesame2 support if sun-jre-bin was set as system-vm
-[22:10:05] <scarabeus> build fail
-[22:10:14] <scarabeus> it need somebody from java to look and investigate
-[22:10:22] <wired> there's also another issue with sesame
-[22:10:34] <-- bschindler (n=quassel@zux221-218-241.adsl.green.ch) has quit (Read error: 110 (Connection timed out))
-[22:10:37] <wired> if you run emerge with sudo
-[22:10:41] <jmbsvicetto> scarabeus: I've heard of cmake not finding java
-[22:10:44] <wired> it skips sesame support
-[22:10:56] <wired> i talked to ali_bush about it and he said he'll look into it
-[22:10:56] <scarabeus> jmbsvicetto: it find it
-[22:11:00] <scarabeus> but marks as not sufficient
-[22:11:04] <scarabeus> i did bit investigation
-[22:11:13] <reavertm> you can't build it with sun-jre and no wonder - it needs jdk - that's first
-[22:11:44] <reavertm> second is - cmake FindJNI doesn't support many jdk's (IBM to mention one)
-[22:11:53] <wired> sounds reasonable, but no checks are done for it
-[22:11:59] <reavertm> (I have even some patch for that module somewhere)
-[22:12:08] <scarabeus> then give it upstream
-[22:13:52] <scarabeus> ok now we are getting to the fancy stuff
-[22:13:54] <-- kostekjo (n=opera@chello084010120054.chello.pl) has left #gentoo-kde
-[22:14:01] <scarabeus> reavertm: how is looking the cmake stuff you are working on
-[22:14:11] <scarabeus> now the eclass in the testing is working right, can we make it more gentooish
-[22:14:17] <scarabeus> or it is not worth efforts?
-[22:14:32] <hwoarang> gentooish?
-[22:14:34] <hwoarang> :D
-[22:14:40] <tampakrap> scarabeus: could you please expand? i have no idea what you are talking about
-[22:14:57] <reavertm> it's done, testing (rebuilding with kde now)
-[22:14:58] <scarabeus> tampakrap: obeying our variables and so on
-[22:15:05] <scarabeus> i tested too
-[22:15:08] <scarabeus> this afternoon
-[22:15:10] <scarabeus> works fine
-[22:15:16] <reavertm> it's about preserving gentoo C(XX)?_FLAGS and such
-[22:15:32] --> Zuccace_ (i=zucca@a88-112-55-25.elisa-laajakaista.fi) has joined #gentoo-kde
-[22:15:35] <hwoarang> goodie
-[22:15:43] <scarabeus> reavertm: ok so lets say we have this as final agreed?
-[22:15:50] <scarabeus> no more major updates :]
-[22:16:01] <reavertm> scarabeus you tested it with obsolete cmake-utils and I already fund some user of forum (or here) complainging at /usr/local and claimig that he sysnced overlay recently
-[22:16:13] <scarabeus> he is lying
-[22:16:14] <d00p> g
-[22:16:16] <scarabeus> it is working
-[22:16:17] <d00p> ups :p
-[22:16:23] <scarabeus> tested on tons of cmake-utils ebuilds
-[22:16:29] <wired> i have some stuff in /usr/local too
-[22:16:36] <scarabeus> wired: then try the stuff recompile
-[22:16:48] <wired> kk
-[22:16:57] <wired> its just soprano, i'll do it now
-[22:17:17] <reavertm> no, it's cmake issue, not soprano issue
-[22:17:22] <wired> i mean
-[22:17:25] <wired> its soprano files
-[22:17:26] <wired> in there
-[22:17:27] <wired> :)
-[22:17:31] <scarabeus> yes it is cmake-eclass isue
-[22:17:34] <scarabeus> so sync and try plz
-[22:17:39] <wired> on it
-[22:17:40] <scarabeus> so we can have it from the first hand
-[22:18:09] <-- yngwin (n=yngwin@gentoo/developer/yngwin) has quit (Read error: 104 (Connection reset by peer))
-[22:18:19] <scarabeus> meanwhile we removed htmlhandbook useflag so we have to create new generation for the docs :]
-[22:18:31] --> yngwin_ (n=yngwin@gentoo/developer/yngwin) has joined #gentoo-kde
-[22:18:31] *** Mode #gentoo-kde +o yngwin_ by ChanServ
-[22:18:40] <scarabeus> it is not biggie but it would be nice to have some reasonable doc system instead of broken htmlhandbook for 4.2.2
-[22:18:53] <tampakrap> any ideas on this?
-[22:18:57] <reavertm> doc USE flag?
-[22:19:19] <scarabeus> reavertm: hehehe
-[22:19:21] <yngwin_> sry, lost network
-[22:19:21] <tampakrap> i like this
-[22:19:27] <scarabeus> it was wrong
-[22:19:28] <reavertm> and what then - extracyting /doc when set?
-[22:19:48] <scarabeus> yup but wont be smart to have kde-docs package
-[22:19:52] <scarabeus> easier and convinient
-[22:20:47] -*- NoirSoldats seconds the idea of a kde-docs package.
-[22:21:08] <-> yngwin_ is now known as yngwin
-[22:21:22] <jmbsvicetto> why kde-docs?
-[22:21:25] <reavertm> so... gather docs from all kde-base modules?
-[22:21:35] <scarabeus> yup
-[22:21:36] <jmbsvicetto> If I only install 3 or 4 apps, why should I have the docs for all of KDE?
-[22:21:42] <-- looonger (n=looonger@host-89-231-128-7.rawamaz.mm.pl) has quit (Client Quit)
-[22:21:43] --> ayevee (n=quassel@62.140.238.1) has joined #gentoo-kde
-[22:21:53] -*- reavertm agrees with jmbsvicetto :P
-[22:21:54] <scarabeus> ok so useflag you say
-[22:21:55] <scarabeus> ok
-[22:21:57] <scarabeus> :(
-[22:22:04] <scarabeus> my nice idea squashed to the dust :D
-[22:22:04] <NoirSoldats> jmbsvicetto: How big would the docs really be though? In total?
-[22:22:10] <scarabeus> quite much
-[22:22:17] <reavertm> I mean, it's easier to maintain it at package level
-[22:22:28] <NoirSoldats> <100MB?
-[22:23:04] <ayevee> am I the only one for whom automo-9999 fails to build?
-[22:23:46] <wired> scarabeus: synced, emerge -av1 soprano but the files still installed in /usr/local
-[22:23:48] <NoirSoldats> scarabeus: Hmm, I have a suggestion for how to handle the docs, that should solve both ends of the spectrum.. if I may.
-[22:23:57] <hwoarang> ayevee: not now. we are in the middle of a meeting
-[22:24:08] <ayevee> hwoarang: sorry
-[22:24:19] <-- ayevee (n=quassel@62.140.238.1) has quit (Client Quit)
-[22:24:22] <hwoarang> np
-[22:24:34] <bumbl> scarabeus: why was htmlhandbook wrong?
-[22:24:59] <reavertm> htmlhandbook is installing *unpacked* docs
-[22:25:19] <bumbl> ah ok
-[22:25:20] <reavertm> sth like difference between .chm and  unpacked help contents
-[22:25:36] <bumbl> (i have no problem with that but i see the point)
-[22:27:06] <jmbsvicetto> are we still in point 3 ? :\
-[22:27:27] <scarabeus> :D
-[22:27:33] <scarabeus> we have 3 issues left
-[22:27:39] <jmbsvicetto> I see we'e jumped ab it
-[22:27:39] <scarabeus> i pick randomly :D
-[22:27:42] <jmbsvicetto> a bit*
-[22:27:48] <-- Zucca (i=zucca@a88-112-55-25.elisa-laajakaista.fi) has quit (Read error: 110 (Connection timed out))
-[22:27:54] <jmbsvicetto> 4, 5 and 6 ?
-[22:27:59] <scarabeus> ok reavertm we will probably work on this
-[22:28:12] <scarabeus> those are due to now
-[22:28:19] <wired> scarabeus: ^^ soprano still installs in /usr/local
-[22:28:22] <scarabeus> now lets talk about the splitting then
-[22:28:27] <scarabeus> wired: ok i will owrk on that
-[22:28:32] <wired> ok :)
-[22:28:55] <scarabeus> reavertm: do you know how is upstream going with its splitting for 4.3?
-[22:29:22] --> mikkoc_ (n=mikko@151.59.215.164) has joined #gentoo-kde
-[22:29:57] <tampakrap> upstream is going to split modules or to support splited builds?
-[22:29:58] <-- scratch[x] (n=scratch@83.239.148.148) has quit ("Ухожу")
-[22:30:10] <tampakrap> or something else?
-[22:30:32] <reavertm> related to binary/lib versioning? well, they don't seem to be eager (see the need - talked with dfaure ) to change .so version to make it possible to install multiple installations aside
-[22:30:51] <reavertm> I wonder who came up with the idea (maybe I don't have clear picture)
-[22:31:05] <scarabeus> jmbsvicetto: you are most relevant for this ideas
-[22:31:24] <jmbsvicetto> ok
-[22:32:19] <jmbsvicetto> Our talk at FOSDEM was that they would (could?) probably split all the bins, but there were some resistance to lbis
-[22:32:22] <jmbsvicetto> libs*
-[22:32:45] <jkt|> is that about keeping 4.x and 4.(x+1) aside?
-[22:33:13] <scarabeus> jkt|: yes and in same prefix
-[22:33:49] <reavertm> anyway - providing more restictive .so versions would restict their ABI compatibility - they already increase soversion for newer libs
-[22:34:02] <jmbsvicetto> scarabeus: that's the next step
-[22:34:13] -*- Sput thinks it does not make much sense to split libs that are always needed anyway
-[22:34:37] <reavertm> so we would need either dependencies on *every*library* level (and not tied to particular kde version) or just override their choice on our side
-[22:34:43] <jmbsvicetto> The first step from them was splitting the tarballs. The second step is providing support to have multiple versions around
-[22:34:53] <jmbsvicetto> Sput: I tend to agree
-[22:35:17] <jmbsvicetto> reavertm: libtool!!! ;)
-[22:35:26] <-- anselmolsm (n=anselmo@200.184.118.130) has quit (Read error: 113 (No route to host))
-[22:35:40] <scarabeus> hh
-[22:35:45] <-- Zuccace_ (i=zucca@a88-112-55-25.elisa-laajakaista.fi) has quit (Read error: 110 (Connection timed out))
-[22:35:58] <reavertm> I don't know libtool and I'm not eager to learn it (libtool is broken as well, besides :P)
-[22:36:36] <jmbsvicetto> reavertm: I mean that this issue of lib versions and deps is what libtool does
-[22:37:02] <reavertm> setting versions for kde libs is not a problem
-[22:38:09] <jmbsvicetto> reavertm: I mean run-time deps
-[22:38:32] <jmbsvicetto> reavertm: Having app A with a rdep on lib X-1.0.1 and not lib X-1.0.2
-[22:38:41] <-- Sho_ (n=EHS1@kde/hein) has quit (Read error: 104 (Connection reset by peer))
-[22:39:28] --> anselmolsm (n=anselmo@200.184.118.130) has joined #gentoo-kde
-[22:39:30] <jmbsvicetto> So, who's interested in this subject?
-[22:39:56] <scarabeus> i am not enought l33t for this one
-[22:40:00] --> kostekjo (n=opera@chello084010120054.chello.pl) has joined #gentoo-kde
-[22:40:32] <reavertm> neither am I
-[22:40:37] <-- kostekjo (n=opera@chello084010120054.chello.pl) has left #gentoo-kde
-[22:41:09] <jmbsvicetto> I don't believe you :P
-[22:42:06] --> root (n=root@hor-jdh171.hor.ucl.ac.uk) has joined #gentoo-kde
-[22:42:14] <jmbsvicetto> ok, I guess we should talk about this later. Let's see if we can get anything in the ml
-[22:42:15] <-> root is now known as lfranchi
-[22:42:26] <jmbsvicetto> Are you guys still awake? ;)
-[22:42:36] <-- lfranchi (n=root@hor-jdh171.hor.ucl.ac.uk) has quit (Client Quit)
-[22:42:37] <scarabeus> yep
-[22:42:39] <scarabeus> i am trying
-[22:42:42] <scarabeus> ook
-[22:42:43] <jmbsvicetto> hehe
-[22:42:48] <tampakrap> yeah i just woke up at 19:00 utc
-[22:42:48] <scarabeus> next thing
-[22:42:50] <scarabeus> importand one
-[22:42:51] --> rex_ (n=quassel@host135-243-dynamic.4-87-r.retail.telecomitalia.it) has joined #gentoo-kde
-[22:42:54] <scarabeus> snapshots
-[22:42:57] <scarabeus> what should we do
-[22:43:04] <scarabeus> upstream dont give a f**k
-[22:43:07] <tampakrap> stop providing them i guess
-[22:43:23] <jmbsvicetto> scarabeus: I'll try to mail Dirk directly
-[22:43:34] <reavertm> I don't feel like it's worth repacking
-[22:43:39] <tampakrap> Dirk is the packager?
-[22:43:40] <jmbsvicetto> last time it took him a few months to get back, but I won't lose anything by sending the mail
-[22:43:43] <jmbsvicetto> Philantrop: ping
-[22:43:44] <scarabeus> it is getting high priority cause pple liek the feature
-[22:43:49] <bonsaikitten> scarabeus: I can script fixed ones
-[22:43:56] <reavertm> Dirk Mueller is "release-team" :P
-[22:44:04] <-- Civil (n=Civilian@95-24-48-161.broadband.corbina.ru) has quit (Remote closed the connection)
-[22:44:05] <bonsaikitten> scarabeus: that way we'd use our own mirroring
-[22:44:06] <reavertm> that's why we can't get any feedback :P
-[22:44:22] <Philantrop> jmbsvicetto: Hm?
-[22:44:25] --> leo (n=leo@hor-jdh171.hor.ucl.ac.uk) has joined #gentoo-kde
-[22:44:26] <jmbsvicetto> reavertm: he's on the packagers and release ml
-[22:44:33] <-> leo is now known as lfranchi
-[22:44:40] <alexxy> we can repack this tarbolls
-[22:44:55] <reavertm> yes, but he's de facto only man reposnible for releases and tarballs
-[22:44:56] <jmbsvicetto> Philantrop: Have you tried to get someone from KDE about the snapshots names?
-[22:45:09] <lfranchi> yo Sput
-[22:45:11] <jmbsvicetto> Philantrop: By you, I mean you, Ingmar or someone else from exherbo
-[22:45:22] <lfranchi> Sput: i get to complain at you now :)
-[22:45:33] <Philantrop> jmbsvicetto: Nope, we decided we don't care enough. :)
-[22:45:38] <jmbsvicetto> hehe
-[22:45:42] <tampakrap> that's the spirit
-[22:45:42] <jmbsvicetto> Philantrop: slacker :P
-[22:45:44] <scarabeus> hehe
-[22:45:49] <scarabeus> that is the point we are getting now :D
-[22:46:10] <reavertm> actually we have similar approach I guess :)
-[22:46:12] <Philantrop> jmbsvicetto: "[05. 03. 2009 21:29] <Ingmar> slacker! :p" <-- to me. :->
-[22:46:24] <scarabeus> lol
-[22:46:25] <jmbsvicetto> hehe
-[22:47:00] <jmbsvicetto> I'll provide some feedback to the ml when / if I get something
-[22:47:03] <-- mikkoc (n=mikko@151.59.212.173) has quit (Read error: 110 (Connection timed out))
-[22:47:04] <-- pipipde (n=pip@e179244051.adsl.alicedsl.de) has quit (Read error: 110 (Connection timed out))
-[22:47:08] <alexxy> we still need tarbolls for snapshots
-[22:47:12] <tampakrap> what's the backup plan then?
-[22:47:15] <scarabeus> ok lets state we sent hte mail
-[22:47:22] <scarabeus> and bonsaikitten will repack for time being
-[22:47:26] <jmbsvicetto> I'm going to send another mail today
-[22:47:34] <scarabeus> ok you sent the mail
-[22:47:42] <tampakrap> jmbsvicetto: maybe CC to many KDE people and mls
-[22:47:59] <jmbsvicetto> tampakrap: I'm going to address the packagers, the release team and Dirk directly
-[22:48:01] <lfranchi> so i'm just getting started with kde-svn ebuilds on gentoo, and automoc failed to install (failed to even begin checking out from svn). can anyone in here help me?
-[22:48:09] --> pipipde (n=pip@e179247082.adsl.alicedsl.de) has joined #gentoo-kde
-[22:48:25] <alexxy> lfranchi: later1 we have meeting there
-[22:48:31] <lfranchi> oh, sorry
-[22:48:36] -*- lfranchi hides
-[22:48:59] <reavertm> lfranchi: I guess it will be fixed soon, but will, many people use live kde (didn't have time to look up the issue)
-[22:49:12] <scarabeus> bonsaikitten: so you can rly pack it with not big effort?
-[22:49:42] <alexxy> scarabeus: we can repack them as tar.lzma
-[22:49:43] <alexxy> =)
-[22:49:47] <scarabeus> sweeet
-[22:49:50] <alexxy> via scripts
-[22:49:54] -*- jmbsvicetto kills alexxy 
-[22:49:58] <jmbsvicetto> tar.bz2 :P
-[22:50:08] <alexxy> jmbsvicetto: .lzma better =)
-[22:50:12] <wired> well since they really want their svn in the filename, maybe we can convince them to use a 4.x.SVNREV.tar.bz2 scheme?
-[22:50:26] <scarabeus> wired: well the svnrev is not deterministic
-[22:50:31] <reavertm> jmbsvicetto: if you mailed Dirk, you would be mentining placing .svnrevision file or sth in tarball?
-[22:50:31] <scarabeus> you have to go and check for that revnumber
-[22:50:40] <scarabeus> normaly you just add +1
-[22:50:56] <reavertm> as I guess it's at least the way we agreed with thiago
-[22:50:56] <wired> i see
-[22:51:08] <jmbsvicetto> reavertm: I can suggest that as an alternative
-[22:51:15] <wired> well i don't see them changing their minds any time soon, alexxy's log was pretty clear
-[22:51:38] <reavertm> jmbsvicetto: I mean, let him know we already discussed it with kde folks :P
-[22:52:09] <jmbsvicetto> reavertm: I will also ask for different options if they don't want weekly snapshots to be used by packagers
-[22:52:21] <reavertm> wired: well, you may read jmbsvicetto log as well (later that day)
-[22:52:57] <reavertm> if they don't want us to use - I think we should not use :P we just need to follow trunk changes then :P
-[22:53:31] <reavertm> It's sufficient to prepare next stable (4.3) release
-[22:53:34] --> Linux (n=marcus@92-234-252-159.cable.ubr06.blac.blueyonder.co.uk) has joined #gentoo-kde
-[22:53:41] <Linux> Hey everyone.
-[22:53:49] <reavertm> besides - people should use portage version :P
-[22:53:58] <jmbsvicetto> hehe
-[22:53:59] <Linux> Is KDE 4.2.1 available yet? I synced yesterday.
-[22:54:09] <NoirSoldats> Linux: Yes.
-[22:54:11] <yngwin> yes, sync again
-[22:54:16] <reavertm> so not making snapshots available we probably have greater 4.2 userbase to test and possibly stabilize later
-[22:54:19] <Linux> OK. :)
-[22:54:53] <jmbsvicetto> reavertm: the snapshots are useful, imo
-[22:55:10] <reavertm> as unstable snaphosts are not really *releases* but just svn dump - they are usually as broken as live
-[22:55:16] <tampakrap> i agree with reavertm, live is enough, we already maintain too many kde releases
-[22:55:22] -*- alexxy starts repacking kde 4.2.65
-[22:55:29] <scarabeus> :D
-[22:55:34] <scarabeus> alexxy: talk with kitten
-[22:55:42] <jmbsvicetto> ok, if no one is willing to work on them for now, let them rest
-[22:55:49] <scarabeus> ook
-[22:55:50] <scarabeus> agreed
-[22:55:54] <jmbsvicetto> We have enough things to take are already
-[22:56:18] <jmbsvicetto> scarabeus: bugs? bugz? BUGZ??? ;)
-[22:56:19] <scarabeus> last thing
-[22:56:24] <scarabeus> BUGZZZZZZZZZZZZZZZZZZZZZZZ
-[22:56:30] <jmbsvicetto> :)
-[22:56:30] <scarabeus> we have tons of them
-[22:56:31] <yngwin> zzzzzzzzzz
-[22:56:31] <scarabeus> many dupes
-[22:56:34] <scarabeus> many needs fix
-[22:56:37] <scarabeus> many are trivial
-[22:56:40] <jmbsvicetto> yngwin: :)
-[22:56:44] <scarabeus> and there is sh*tload of them
-[22:57:01] <tampakrap> nice, i was eating
-[22:57:14] <reavertm> don't read then ;)
-[22:57:15] <scarabeus> good now you will starve as me :D
-[22:57:22] <wired> hahahahahah
-[22:57:23] -*- Sput looks into automoc now
-[22:57:37] <Sput> except somebody fixed that already
-[22:57:43] <reavertm> Sput it may be as well cmake-utils related
-[22:58:01] <tampakrap> scarabeus: tell us the last issue and go to watch some pr0n
-[22:58:06] <scarabeus> :D
-[22:58:12] <scarabeus> the issue is we need to work on bugz
-[22:58:24] <Sput> tampakrap: you didn't watch pr0n during the meeting like the rest of us?
-[22:58:25] <scarabeus> we need smebody actualy devolting lots of time on them
-[22:58:44] <tampakrap> we need a cleanup as a first step
-[22:58:44] <jmbsvicetto> Should we set some goals about bugs?
-[22:58:53] <scarabeus> yep that might be good
-[22:58:57] -*- reavertm still has some updates 4.2.1 and wonders whether anyone wants them, especially with 4.2.1 removed from overlay :P
-[22:58:59] <tampakrap> take care of trackers, duplicates and resolved
-[22:59:01] <tampakrap> and then fixed
-[22:59:15] <jmbsvicetto> Do we want to reduce them to a certain number by X months? Do we want to set a goal of taking care of X bugs per week?
-[22:59:15] <scarabeus> reavertm: pastebin it :]
-[22:59:18] <tampakrap> i'm sure 100 of them are already fixed or duplicate
-[22:59:33] <hwoarang> yes
-[22:59:36] <hwoarang> or invalid
-[22:59:36] <tampakrap> jmbsvicetto: you are the leader, you should set the number
-[22:59:51] --> cypr1nus (n=cypr1nus@plus.ds14.agh.edu.pl) has joined #gentoo-kde
-[22:59:57] <reavertm> scarabeus: when I'm done rebuilding kde with them (along with cmake-utils and those pasted kde4 eclass thing - so far so good)
-[23:00:12] <scarabeus> actualy we can have policy like "you want to be in herd fix X bugz a month"
-[23:00:14] <scarabeus> :D
-[23:00:19] <scarabeus> or some other contribution to kde
-[23:00:51] <tampakrap> i'm ok will all these, just give us the deadlines
-[23:00:51] <alexxy> heh =)
-[23:01:07] <jmbsvicetto> OK. Let's have a vote: get bugs under X or fix X bugs per week?
-[23:01:25] <tampakrap> the second
-[23:01:27] <bonsaikitten> yes!
-[23:01:38] <scarabeus> the second is more reasonable :]
-[23:01:38] <reavertm> define "fix"
-[23:01:40] <jmbsvicetto> I think the later might be more productive and may help feeling work done
-[23:01:43] -*- bonsaikitten self-removes from the herd preemptively
-[23:01:44] <hwoarang> +1
-[23:01:53] <jmbsvicetto> bonsaikitten: hehe
-[23:01:56] <tampakrap> hhahahahahha
-[23:02:06] <scarabeus> bonsaikitten: we can give you expection for the kittening :D
-[23:02:08] <reavertm> marking as RESOLVED/FIXED only to decrease bug count is wrong approach  - I'd agree with flameeyes here :P
-[23:02:22] <scarabeus> well it has to be fixed too
-[23:02:30] <jmbsvicetto> I'm not going to create a rule "if you don't fix X bugs per week, you're out", but I think we should all try to solve at least X bugs per week
-[23:02:34] <bonsaikitten> haha
-[23:02:37] <yngwin> well, for starters it would probably help to weed out the duplicates
-[23:02:41] <bonsaikitten> well, I'm fixing too many other things
-[23:02:41] <jmbsvicetto> reavertm: sure
-[23:03:10] <scarabeus> jmbsvicetto: btw did you sent the mail about removing of members to nonactive kde members?
-[23:03:15] <jmbsvicetto> So, a reasonable number would be between 2 and 10?
-[23:03:35] <tampakrap> 4-10
-[23:03:57] <jmbsvicetto> 5 per week?
-[23:03:58] <scarabeus> a week
-[23:04:00] <scarabeus> 5
-[23:04:17] <scarabeus> but actualy we are fixing even more :P
-[23:04:21] <scarabeus> i have 5 for today :D
-[23:04:27] <scarabeus> more than 5
-[23:04:28] <d00p> lol
-[23:04:29] <scarabeus> :D
-[23:04:33] <dagger> ;)
-[23:04:35] <tampakrap> 10?
-[23:04:39] <d00p> 7?
-[23:04:41] <scarabeus> tampakrap: that is hard to tell
-[23:04:46] <jmbsvicetto> Ok, let's all try to fix at least 5 bugs per week
-[23:04:48] <scarabeus> bug a day might be good idea
-[23:04:51] <scarabeus> ook
-[23:04:57] <jmbsvicetto> tampakrap: Let's not aim too high
-[23:04:59] <scarabeus> at least 5 bugs per week
-[23:05:14] <-- Caster (i=Caster@gentoo/developer/caster) has quit ("Don't waste your time, or time will waste you.")
-[23:05:15] <tampakrap> fine
-[23:05:19] <jmbsvicetto> tampakrap: You're feel to fix 50 in a week if you can ;)
-[23:05:27] <tampakrap> oh i am?
-[23:05:34] <jmbsvicetto> yes :P
-[23:05:41] <tampakrap> ok now we are clear
-[23:05:42] <jmbsvicetto> bah, You're free*
-[23:05:44] <bumbl> a bug a day keeps the doctor away
-[23:05:53] <tampakrap> hahahhaaha
-[23:06:05] <scarabeus> bumbl: nice moto
-[23:06:07] <tampakrap> a bug per day keeps the ladys away
-[23:06:12] <scarabeus> rofl
-[23:06:13] <d00p> lawl
-[23:06:17] <dagger> hehe
-[23:06:20] <bumbl> lol
-[23:06:28] <scarabeus> dagger: you wanna help with bugz?
-[23:06:28] <jmbsvicetto> I suggest we had bumbl moto to our page ;)
-[23:06:32] <d00p> do you rly want that to happen?
-[23:06:32] <dagger> tampakrap: 10 bugs a day keep your life away :p
-[23:06:35] <dagger> scarabeus: sure
-[23:06:37] <scarabeus> jmbsvicetto: agreed
-[23:06:56] <jmbsvicetto> So, anything else?
-[23:07:01] <scarabeus> we are done
-[23:07:03] <scarabeus> dismissed
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20071013.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20071013.txt
deleted file mode 100644
index 567b83c076..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20071013.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-Summary of 13 October 2007 KDE herd meeting
-
-Active participants: cryos, genstef, jmbsvicetto*, keytoaster, philantrop, tgurr
-In the channel: masterdriverz
-Missing: caleb, centic, carlo, deathwing00, mattepiu, troll, vanquirius
-* = invited guests
-
-- Project page: The update of the project page was approved by the participants.
-
-- Process improvement: This topic was postponed until the next meeting.
-
-- Misc: 
-
-1. Bump to KDE 3.5.8:
-The bump to KDE 3.5.8 is taking place in a git repository to allow for others
-to take part, too, and avoid critisism like for the last bump.
-This allows interested users to be "trained on the job" including the use of 
-our QA tools in a controlled environment outside the official tree.
-Furthermore, the KDE 3.5.8 is not meant to be public until the release as per
-upstream request.
-Nevertheless, we will put the finished packages into the tree as package.masked
-ASAP to allow arch teams and other devs to test. After that's done, a mail will 
-be sent to kde@g.o and the core mailinglist by Philantrop.
-
-2. KDE 3.5.8 in stable for 2007.1:
-We will *try* to get KDE 3.5.8 into stable in time for 2007.1 but if we don't, 
-the world won't stop spinning. We will *not* inform the release guys about us 
-making it in time to not endanger their time frame needlessly if we don't make it.
-
-3. Changing to split ebuilds by default:
-This suggestion was rejected by the participants for 3.5.x. We will make it the
-default for KDE 4, though.
-
-4. State of KDE4 in the overlay(s):
-KDE4 in the overlay is doing well. People are installing it, using it and are 
-reporting bugs. We currently have both monolithic and split ebuilds.
-The participants decided 3:1 for keeping the monolithic ebuilds for KDE4.
-
-5. Miscellaneous
-- A particpant asked for information on cmake ("crash course"). Any input is
-appreciated.
-
-- cmake-utils.eclass. Several participants asked to get it into the tree. The final
-remaining "showstopper" is the src_test function which is mostly a verbatim copy
-of the one in ebuild.sh. We currently need it to determine if it's an in-source or
-out-of-source build. Any input on this is appreciated. 
-Philantrop is going to re-submit the eclass to the dev mailinglist next week.
-
--  Arch Testers / Herd Testers. It was suggested to have Herd Testers for the KDE 
-herd as per GLEP 41. The suggestion was accepted by unanimous vote.
-Philantrop will talk to hparker, the AT lead about it.
-genstef and jmbsvicetto will prepare a draft for the project page and mail to 
-kde@g.o.
-
-- A participant suggested to move the scheduled meeting to the first Saturday of
-each month. This was approved by unanimous vote.
-keytoaster will update the project page accordingly.
-
-- Several participants asked about the Herd lead status as this is currently not
-reflected on the project page. The participants asked keytoaster to add the 
-following to the project page directly above the "Members" box:
-"We do not have a formal lead: Decisions can be made by every herd member but it usually is a good idea to ask Philantrop because he is around and knowledgable."
-
-
-Tasks:
-- Put the finished KDE 3.5.8 packages into the tree in p.mask by October, 14th 2007
-and inform kde@g.o and the core mailinglist about it. (Philantrop) 
-- cmake-utils.eclass should be re-submitted to the dev mailinglist by next week. (Philantrop)
-- Contact the AT project on how to implement HTs for the KDE herd. (Philantrop)
-- Prepare a draft for the project page about HTs. (genstef, jmbsvicetto)
-- Update the project page with information about project lead and monthly meetings. (keytoaster)
-
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20080306.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20080306.txt
deleted file mode 100644
index 320828531c..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20080306.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-Summary for the Gentoo KDE herd meeting on Thursday, 6th of March 2008
-
-Participants:
-caleb, cryos, deathwing00, genstef, ingmar, jmbsvicetto, keytoaster, philantrop, tgurr,	zlin
-
-1. Bump to KDE 3.5.9:
-
-Apart from a few minor issues, the bump to KDE 3.5.9 went well. 
-
-https://bugs.gentoo.org/211116 (mixing split and monolithic ebuilds) was
-discussed. 3 participants didn't want the current behaviour changed, 3 were in
-favour of changing it. Thus, it was agreed that Ingmar, who volunteered to 
-change it, should feel free to do it.
-
-2. KDE 3.5.8 in stable for 2008.0.
-
-Philantrop stated that KDE 3.5.8 will be in the 2008.0 release.
-
-3. Removal of KDE < 3.5.8 from the tree.
-
-gentoofan23 brought up the issue of the removal of older (specifically 3.5.7)
-stable KDE versions from the tree after about 19 days and asked for a longer
-period for users to upgrade to the newest stable version.
-30 days were suggested as a rule of thumb and agreed upon by the majority of
-the participants.
-
-4. State of KDE4 in the tree.
-
-Ingmar and zlin gave a short information about KDE4 in the tree. The ebuilds in
-the tree are in a pretty good state. Their dependencies need to be updated for
-compatibility with the newly introduced split Qt-4.4 ebuilds.
-
-KDE 4.0.2 is currently planned to be included in the tree during the weekend.
-(p.masked)
-
-Anyone who wants to help with the bump to 4.0.2 should simply mail Philantrop
-his ssh public key. Interested users who can show they're able and willing to
-work on ebuilds are *explicitly* invited, too.
-The bump to 4.0.2 is taking place in a git overlay again to allow for non-ebuild
-devs to participate, too, and it's a great way to become a dev as Ingmar and
-zlin can verify.
-
-5. Herd Testers: Current state and next steps.
-
-The HT stuff was delayed because of the trustee elections, etc.
-jmbsvicetto and deathwing00 agreed to flesh out the work of a KDE Herd Tester
-and publish information about it on the usual Gentoo news channels (pr@g.o, 
-GMN, Forums).
-
-6. Lead election:
-
-Having a sub-lead was discussed to ensure not to have a single point of failure
-in case the lead disappears. In a vote, 3 herd members expressed their wish for
-a sub-lead, 5 voted against it and there was one abstention. Thus, the notion
-was rejected.
-
-deathwing00 initiated a vote for the lead. Philantrop was nominated and accepted
-the nomination.
-Philantrop was voted for by 9 of the participants, no votes against him and no
-abstentions. Thus, Philantrop was elected the lead of the Gentoo KDE project.
-
-deathwing00 is going to inform the GMN, pr@g.o and post it on the forums.
-
-7. Review of the project page
-
-gentoofan23 and deathwing00 volunteered to update the project page with respect
-to KDE versions and other information in the sections 3, 4, 8 and 9 till the
-next meeting.
-
-8. Miscellaneous
-
-It was decided to re-instate the monthly meetings on the first Thursday each 
-month.
-
-9. Date of the next meeting and closing.
-
-The next KDE herd meeting takes place on Thursday, 3rd of April 2008.
-
-Philantrop thanked all the Gentoo KDE people for their great work and their
-trust in him.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20081204.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20081204.txt
deleted file mode 100644
index 8f86331aa6..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20081204.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-kde3:
-	cryos and tampakrap are willing to handle its dying. Their priority should be stabilising 3.5.10 and making it live along 4.X.
-kde4-eclasses:
-	currently in reviewing
-	Jmbsvicetto and krytzz promised helping me up with testing get_latest_kdedir.
-	Moving htmlhandbook to eclass? jmbsvicetto/scarabeus
-	fix remaining tree ebuild so they use NEED_KDE="version" and not NEED_KDE="slot" scarabeus will do it.
-	only eapi2 and greater in eclass: jmbsvicetto will look on this one.
-kde4:
-	try to push versioning in one prefix into upstream. It will be bliss for maintaining. cryos (on kde camp :P)
-people-in-team:
-	write mail to all whom are mentioned on project page and not active to determine their current status. :(
-	jmbsvicetto willing to do this.
-qt4:
-	yngwin is currently only qt dev, he should get some help, reavertm volunteer (see HT guys are useful :])
-tampakrap:
-	getting his ebuild-quiz done i scarabeus am willing to help. Yngwin as mentor.
-kde-crazy:
-	snapshots: tampakrap, alexxy, patrick; state: somehow working
-	live: sput, krytzz, reavertm; state: well live ;]
-networkmanager:
-	scarabeus will ask rbu if he need some help with this vital part of kde4.2 networking.
-mysql:
-	cooperate with robbat2 since kde4.2 and amarok are dead without it. Jmbsvicetto volunteer to help robbat2 so lets se what will be outcome from this.
-
-:::LONG TERM:::
-kde-look/apps:
-	maybe create some generator for those apps, take look onto app-portage/g-cpan how perl mages do it.
-bugwranglers:
-	reavertm, proposal about letting normal users to wrangle our bugs, most of them are needinfo or already closed so let users help us.
-	Maybe some wrangler-quiz.txt will be needed.
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090108.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090108.txt
deleted file mode 100644
index 5b61c01371..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090108.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-kde3:
-  sent mail asking for volunteers since we are short on staff on kde3. Sqashing bugs/etc. - cryos
-eclasses:
-  done, commit to the tree, anounce on dev, make sure all ebuilds are updated to new structure and revbumped. - scarabeus
-kde4:
-  4.1.4 after eclasses and mics apps are done, not earlier!  - alexxy as a new dev :]
-  disable +kdeprefix on stable (in the tree) - jmbsvicetto?
-  4.2 doublecheck for missing ebuilds, generate metas - alexxy, tampakrap
-  policykit: suspended for now, when time comes we should cooperate with gnomies
-  printing: bump everything first in kde-testing, move to tree when we think it is ready, printing suspended until this is done. - !!! NOBODY !!! (leave it on gentoo-desktop?)
-  write nice guide - tampakrap
-  fix homepages for kdebase ebuild on correct ones in kde structure - patrick
-  mono - suspended until someone care, we dont want them - scarabeus
-qt4
-  status: yngwin states he has some qt apprentices, which is great :]
-  overlay: there will be new overlay for qt stuff which is yngwin creating
-  pyqt/pykde messie - patrick, yngwin if they get to it :]
-
-SPLIT/MERGE overlays VOLTES:
-yngwin: merge
-kitten: merge
-scarab: merge
-tampakrap: merge
-reavertm: merge
-alexxy: merge
-cryos: dont mind merge
-sput: merge
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090305.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090305.txt
deleted file mode 100644
index 09f2d372a5..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090305.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-AROUND:
-yngwin, wired, scarabeus, alexxy, cryos, jmbsvicetto, hwoarang, bonsaikitten, tampakrap, reavertm
-
-kde3 state/others:
-- merging to master branch in kde-testing soon, for more info/help offers talk with tampakrap
-- so correct prefixing for kde3 and no more blocks are coming near to you.
-- create important bug list and ask bugday people and others for help -> tampakrap
-
-amarok maintainer:
-- send mail to -dev to get one -> scarabeus
-
-homepage updates:
-- we need to keep our webspace up-to-date and guides actualy working -> yngwin, tampakrap
-
-pykde:
-squash the bugs/issues, unslot, unkdeprefix... -> bonsaikitten
-
-kbluetooth4:
-may be even working, needs testing/patching -> wired
-
-kde4 stabling/keywording:
-we need to check deps so they are working on target arches
-also we should make less strict deps on kde4 eclass -> scarabeus on this
-
-cmake-utils:
-hopefully done, now only bugfixing -> reavertm, scarabeus
-
-removal of htmlhandbook:
-introduce working doc flag -> probably scarabeus (needs to be done before 4.2.2)
-
-tarballs splitting and libs/apps versioning:
-- discussion to start on the desktop ml -> jmbsvicetto
-
-snapshots:
-send mail to dirk -> jmbsvicetto
-repack tarballs -> bonsaikitten
-set on rest for now by majority vote, come and volunteer if you want it changed
-
-bugsquash:
-let's aim at having each kde team member fixing 5 bugs per week
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090212.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090212.txt
deleted file mode 100644
index f8d29e5f29..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090212.txt
+++ /dev/null
@@ -1,761 +0,0 @@
-21:00 <@scarabeus> ok sunshines, meeting time :P
-21:00 <@hwoarang> is it time?
-21:00 <@scarabeus> !herd kde
-21:00 *    yngwin  kicks Willikins
-21:00 <@scarabeus> i am going to hurt willikins...
-21:00 <+wired> lmao
-21:00 <@hwoarang> fail?
-21:00 <+MrRat> wired: do you know the amarok qt-4.5 bug at all?
-21:00 <@hwoarang> errr meeting time
-21:00 <+wired> yeah i read a bug you posted earlier about a missing line
-21:01 <@yngwin> i'll use this clone here
-21:01 <@scarabeus> :]
-21:01 <@hwoarang> ok who broke Willikins
-21:01 <@scarabeus> but i want that herd
-21:01 <@scarabeus> !herd kde
-21:01 < arachnist> hwoarang: i did
-21:01 < arachnist> ;)
-21:01 <+MrRat> wired: http://rafb.net/p/g1msai72.html
-21:01 <@scarabeus> !herd qt
-21:01 <@hwoarang> :D
-21:01 <+wired> !herd kde
-21:01 <@scarabeus> ok the other route
-21:01 <+wired> ^_^
-21:01 <+MrRat> wired, thats it, just one line
-21:02 <+wired> alright - does that work with 4.4.2 as well?
-21:02 <+MrRat> wired: but the file is not generated until about 10% of the build when qtscriptgenerator runs
-21:02 <@scarabeus> alexxy, bonsaikitten, cryos, hwoarang, jmbsvicetto, keytoaster, tampakrap, yngwin, dagger_, krytzz, MrRat, reavertm, Sput, wired
-21:02 <@scarabeus> meeting
-21:02 <@scarabeus> who is around
-21:02 *    alexxy  here
-21:02 * tampakrap
-21:02 *     wired  ^_^
-21:02 <+Sput> see above
-21:02 *  hwoarang  *
-21:02 *    yngwin  is a square
-21:03 <+MrRat> wired: so when the file is generated, i can edit it and back out of the directory and build is success
-21:03 <+krytzz> that joke is OLD :p
-21:03 *  reavertm  reporting
-21:03 <@jmbsvicetto> Sput: You're missing people :P
-21:03 * jmbsvicet  waves hand
-21:03 <@yngwin> krytzz: so am i ;)
-21:03 <+wired> MrRat: i see
-21:03 <+Sput> I'm what?
-21:03 <+Sput> mostly I'm missing alcohol and inspiration right now
-21:03 <@jmbsvicetto> Sput: Not in FOSDEM? ;)
-21:03 <+wired> MrRat: i'll check it out after the meeting
-21:04 *    yngwin  notes that caleb and carlo are missing as usual
-21:04 <@scarabeus> ok so are we waiting on somebody else
-21:04 <@scarabeus> i wrote carlo a mail
-21:04 <@scarabeus> asking him to drop at least for volte :(
-21:04 <@tampakrap> cryos also said he will probably be away
-21:04 <+wired> we'll give him the logs ^_^
-21:05 <@scarabeus> i know about those missing i am asking if we are waiting on somebody more?
-21:05 <@yngwin> bonsaikitten?
-21:05 <@scarabeus> yup right
-21:05 <@scarabeus> this one i would like to see :P
-21:05 <@scarabeus> !lastspoke bonsaikitten
-21:06 <@scarabeus> ok that bot actualy dont work now
-21:06 <@hwoarang> stupid bots
-21:06 -- rangerpb- is now known as rangerhomezzz
-21:06 <@scarabeus> ok i give him 4 minutes (agreed?)
-21:06 <@tampakrap> ok
-21:06 <@hwoarang> k
-21:06 <@tampakrap> should i call him? :)
-21:06 <@scarabeus> so he has 10 minutes after meeting start to show up :]
-21:06 <@scarabeus> :D
-21:07 <@alexxy> ok
-21:07 <@alexxy> bonsaikitten: !~!!!
-21:07 <+krytzz> we count to ten, then shout as loud as we can
-21:07 < kev009> what does use=raster for qt-gui?
-21:07 <+wired> speeds things up
-21:07 <+MrRat> kev009: speed!
-21:07 <@scarabeus> krytzz: i would wake teh kids
-21:07 <+krytzz> kev009 but breaks compositing  :p
-21:08 *  hwoarang  walks around
-21:08 * scarabeus  prepares editor and stuff for volting and so on :]
-21:09 <@hwoarang> time is up
-21:09 *     wired  is building live qt and kde ^_^
-21:10 <@scarabeus> actualy 50 secs
-21:10 <@scarabeus> now up
-21:10 <@scarabeus> ok
-21:10 < kev009> krytzz: is there a document that expalins how compositing breaks?
-21:10 <+reavertm> kev009 later please
-21:10 <@scarabeus> i officialy start february gentoo kde meeting in year 2009
-21:10 <@scarabeus> :}
-21:10 <@scarabeus> so first subject is review of old one
-21:11 <@scarabeus> i think we did great job with 4.2 and we deserve some cookies :]
-21:11 <@scarabeus> only thing that is missing from last month summary is pyqt/pykde and printing
-21:11 <+krytzz> yeah, it was great
-21:11 <@scarabeus> so how is the printing status reavertm
-21:11 <@scarabeus> only testing needed or some more coding?
-21:11 <+reavertm> printing status - it's reportedly working fine
-21:12 <@tampakrap> so can we add it to the tree?
-21:12 <+reavertm> we need maintainer
-21:12 <@scarabeus> ok process will be 1 week in overlay, and then the main tree
-21:12 <@scarabeus> reavertm: that is no problem
-21:12 <@scarabeus> we are kde herd
-21:12 <@scarabeus> we became maintainer
-21:12 <@tampakrap> right
-21:12 <+reavertm> system-config-printer and pycups are part of leftwovers after Donnie
-21:12 <@scarabeus> i know
-21:13 <+reavertm> they are straight dependecies for out printing kde stuff
-21:13 <@scarabeus> but if it is fixed and working for us we canmaintain
-21:13 <@scarabeus> ok there are no issues, so feel free to remove the mask from it in overlay :]
-21:13 <@alexxy> scarabeus: also we should unmask networkmanager/policykit
-21:13 <+reavertm> and there is one new ebuild that possibly needs to be perfected with some python deps as well - hal-cups-info (in overlay)
-21:13 <@scarabeus> alexxy: that is negative my friend
-21:13 <@scarabeus> we get to that
-21:13 <@tampakrap> we can also start maintaining them and ask in -dev if there are any others intrested in maintaining
-21:13 <+reavertm> (it's printer-applet dep)
-21:13 <@jmbsvicetto> We could ask the printing herd if they want to co-maintain it
-21:13 <@scarabeus> jmbsvicetto: there is no printing herd
-21:14 <@scarabeus> really i looked
-21:14 <@scarabeus> they are mostly dead
-21:14 <@jmbsvicetto> ok
-21:14 <@jmbsvicetto> Where's tgur?
-21:14 <@yngwin> paper is so last century :p
-21:14 <@scarabeus> i have no clue
-21:14 <@tampakrap> !seen tgurr
-21:14 < Willikins> tampakrap: tgurr was last seen 6 days, 16 hours, 49 minutes and 14 seconds ago, quitting IRC (Remote closed the connection)
-21:14 < Philantrop> jmbsvicetto: Health troubles.
-21:14 <@jmbsvicetto> Philantrop: ok, thanks for the info
-21:14 <@tampakrap> Philantrop: thanks
-21:14 <@jmbsvicetto> Philantrop: Do you know if he's still interested in printing packages?
-21:15 < Philantrop> jmbsvicetto: Mostly in cups and friends, yes.
-21:16 <@scarabeus> ok in that case reavertm should speak to him :]
-21:16 <@scarabeus> ok we can wait with printing on him :]
-21:16 <@scarabeus> hope his sickness is not serious and he will get well soon :]
-21:18 <@scarabeus> ok one more question for the last meeting
-21:18 <@scarabeus> did somebody sent that mail about kde3?
-21:18 <@yngwin> i havent seen any
-21:18 <@scarabeus> that we actualy ask for help on them
-21:18 <@scarabeus> tampakrap: so it will be your responsibility i guess
-21:18 <@tampakrap> ok
-21:19 <@tampakrap> i'll also talk with carlo about this
-21:19 <@jmbsvicetto> oh, there was a user that had a comment in my blog entry pleading for us not to drop kde3
-21:19 <@scarabeus> we are not droping it :]
-21:19 <@scarabeus> at least for now :]
-21:19 <+reavertm> we're droping 4.1 :)
-21:19 <+reavertm> (are we?)
-21:19 <@scarabeus> and next year i guess
-21:19 <@scarabeus> yup we are
-21:19 <@scarabeus> as said reaver
-21:19 <@scarabeus> anyone is against it?
-21:20 <@scarabeus> i wolte for drop :]
-21:20 <@hwoarang> +1
-21:20 <@tampakrap> drop
-21:20 <+reavertm> kill it
-21:20 <+wired> farewell
-21:20 <@yngwin> 4.1? yes
-21:20 <+Sput> +1
-21:20 <@scarabeus> 4.1 drop are we speaking about :] not the 3.5 :]
-21:20 <@scarabeus> yngwin: ^
-21:20 <@yngwin> :)
-21:20 <+wired> nobody will miss it anyway ^_^
-21:20 <@jmbsvicetto> bye bye 4.1
-21:20 < termite47384> hwoarang, MrRat: amarok fix0red?
-21:20 <@scarabeus> ok super
-21:21 <@hwoarang> termite47384 will get to it
-21:21 <+Sput> absolutely no need to keep that one around
-21:21 <@scarabeus> soo what is on schedule? ah jmbsvicetto you are :]
-21:21 < termite47384> sorry, I was away and wasn't sure if you had already
-21:21 <@hwoarang> \o/
-21:21 <@jmbsvicetto> scarabeus: :P
-21:21 <@scarabeus> btw who will do the drop
-21:21 <@scarabeus> alexxy: ?
-21:21 <@jmbsvicetto> 4.1?
-21:21 <@scarabeus> yup
-21:21 <@scarabeus> the drop
-21:21 <@tampakrap> may I?
-21:21 <@jmbsvicetto> sure
-21:21 <@scarabeus> tampakrap: if you want :]
-21:21 <+reavertm> still we need to sort packages that may explicitly depend on it
-21:22 <+reavertm> so called kde-misc
-21:22 <@scarabeus> there are none in the tree :]
-21:22 <@tampakrap> of course
-21:22 <@scarabeus> tested/fixed
-21:22 <+wired> there are
-21:22 <+wired> i.e. lancelot-menu
-21:22 <@tampakrap> let's double check to be sure
-21:22 <@scarabeus> only the powerdevil and lancelot
-21:22 <@scarabeus> :]
-21:22 <@scarabeus> ok
-21:22 <@scarabeus> lets go and volte the leader as we promised
-21:22 <@scarabeus> jmbsvicetto: looks like you are the only aplicant
-21:22 < Philantrop> *VOTE*. It's *vote*.
-21:23 <@tampakrap> i'll drop it in weekend as i'll be away tomorrow (exams)
-21:23 <@scarabeus> typo is still the typo
-21:23 <+MrRat> The volte is a very small circle that is used in the training of a horse
-21:23 <+MrRat> :)
-21:23 <+reavertm> could anyone nlighten me, what exactly is this voting for?
-21:23 <+wired> o_o MrRat
-21:23 <@scarabeus> reavertm: kde team leader
-21:23 <@scarabeus> gentoo kde team leader
-21:24 <+reavertm> ah, I got confused with Donnie stepping out from desktop lead
-21:24 <@scarabeus> so jmbsvicetto why we should volte for you, some promotial i guess :]
-21:24 <+reavertm> *down
-21:24 <@scarabeus> again
-21:24 <@scarabeus> why the crap i write volte
-21:24 <@scarabeus> i know it is vote :P
-21:24 < dberkholz> well. i can't really step out till someone else steps in
-21:24 < dberkholz> till then, i make a great figurehead
-21:24 <@yngwin> :)
-21:25 <@scarabeus> :D
-21:25 <@jmbsvicetto> scarabeus: hmm, because you were impressed with me in FOSDEM? ;)
-21:25 <@scarabeus> :]
-21:25 <+reavertm> ok, +1 on Jorge
-21:25 <@yngwin> +1
-21:26 <@alexxy> scarabeus: yep =) i can drop 4.1.x
-21:26 <+krytzz> i dont know if i have the right to vote but, +1
-21:26 <+Sput> _1
-21:26 <@scarabeus> alexxy: too late :]
-21:26 <+Sput> eh
-21:26 <+Sput> +1
-21:26 <@hwoarang> +1
-21:26 <+wired> +1
-21:26 <@alexxy> and i vote for jmbsvicetto to be kde lead
-21:26 <@scarabeus> actualy it counts only from devs :}
-21:26 < rane> gratz jmbsvicetto
-21:26 <@scarabeus> but i suggest the other way
-21:26 <@jmbsvicetto> dberkholz: You make much more than a figurehead, but we're very happy with your figurehead ;)
-21:26 <@scarabeus> who is against
-21:26 <+Sput> meh, I can still give my moral support :)
-21:26 <@jmbsvicetto> rane: :)
-21:27 <@jmbsvicetto> scarabeus: you might want to count the positive votes ;)
-21:27 <@scarabeus> and ftr i volte for him too
-21:27 <@jmbsvicetto> scarabeus: hehe (volte) ;)
-21:27 <@tampakrap> jmbsvicetto++
-21:27 *      Sput  applies 240 volts to scarabeus
-21:27 <@scarabeus> sdamn
-21:27 <+wired> lmao
-21:27 <+MrRat> haha
-21:27 <@scarabeus> ok you have 5 votes now
-21:27 <+wired> beat a typo with a typo, thats something ^_^
-21:28 <@jmbsvicetto> scarabeus: Don't know if you want to count deathwing00's vote
-21:28 <@scarabeus> oh right 6
-21:28 <+MrRat> +1
-21:28 <+MrRat> count me
-21:28 <@scarabeus> hwoarang: ping dude
-21:28 <@hwoarang> i did say +1
-21:29 <@hwoarang> :)
-21:29 <@scarabeus> ok 7
-21:29 <@jmbsvicetto> scarabeus: who's missing? bonsaikitten, cryo?
-21:29 <@scarabeus> yup
-21:29 <@jmbsvicetto> c/cryo/cryos/
-21:29 <@scarabeus> we can count kittens volte on fosdem?
-21:29 <@tampakrap> keytoaster and tgurr
-21:29 <@tampakrap> and carlo
-21:30 <@yngwin> and caleb
-21:30 <+reavertm> ok, lets' go further - 7 is enough already :)
-21:30 <@jmbsvicetto> and corsair and genstef if we look at the kde page
-21:30 <@scarabeus> those are kde devs?
-21:30 <@jmbsvicetto> according to the page
-21:30 <@hwoarang> are they active or smtg?
-21:30 <@jmbsvicetto> Not in a long time, afaik
-21:30 <@scarabeus> actualy i remember somebody promised that he will clean that up :]
-21:31 <@jmbsvicetto> So, do I get to wear the KDE royal crown or what? ;)
-21:31 <@scarabeus> jmbsvicetto: ok you are the leader
-21:31 <@hwoarang> \o/
-21:31 <@scarabeus> nobody volted against actualy :]
-21:31 <@yngwin> hail jmbsvicetto
-21:31 <@jmbsvicetto> :)
-21:31 * scarabeus  bows in front of our new leader
-21:31 <@tampakrap> congratulations!!
-21:31 <@hwoarang> and as a leader you should provide us some free beers
-21:31 <@scarabeus> jmbsvicetto: btw you have to update the page yourself, i hate cvs :]
-21:31 <@jmbsvicetto> Thanks for the confidence guys
-21:31 <+krytzz> right
-21:31 <@alexxy> he he =)
-21:31 <@jmbsvicetto> :)
-21:32 <@alexxy> congratulations jmbsvicetto
-21:32 <@tampakrap> POP *champagne*
-21:32 <@yngwin> i can update the webpage
-21:32 <@yngwin> need to edit it anyway
-21:32 <@jmbsvicet> yngwin: thanks
-21:32 <@yngwin> np
-21:33 <@scarabeus> ok this was actualy funniest part of the meeting
-21:33 <@scarabeus> things that will came are not that nice
-21:33 <@alexxy> yep
-21:33 <@yngwin> so grab another beer
-21:34 <@jmbsvicetto> scarabeus: so I guess I can just leave now ;)
-21:34 <@scarabeus> grm
-21:34 <@scarabeus> actualy you should be leading the discussion now ;P
-21:34 <@jmbsvicetto> hehed
-21:34 <@scarabeus> ok lets start with upstream and prefixing thingie
-21:34 <@scarabeus> i think that is something you have something to say about :]
-21:35 <+reavertm> hmm? please introduce topic
-21:35 <+reavertm> ah, kdeprefixing
-21:35 <+reavertm> but what part of exactly?
-21:35 <@tampakrap> i'll change topic
-21:36 <+reavertm> no noe
-21:36 <@scarabeus> not kdeprefixing
-21:36 tampakrap changed the topic of #gentoo-kde to: Official gentoo-kde project channel | KDE 4 guide: http://tinyurl.com/4n47v4 | Next meeting 12/02/2009@20:00 UTC |Overlays: kde-testing, qting-edge | Want to help us? Ask channel staff for info | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | jmbsvicetto is the new leader!!
-21:36 <@scarabeus> instaling multiple kde versions in one prefix
-21:36 <+reavertm> hmm, how?
-21:36 <+reavertm> elaborate please :)
-21:36 <@scarabeus> that what jorge has to do
-21:36 <@scarabeus> i have not much clue
-21:36 jmbsvicetto changed the topic of #gentoo-kde to: Official gentoo-kde project channel | KDE 4 guide: http://tinyurl.com/4n47v4 | meeting: now - multiple installs under 1 prefix |Overlays: kde-testing, qting-edge | Want to help us? Ask channel staff for info | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | jmbsvicetto is the new leader!!
-21:37 <+reavertm> I would like to hear what's all about first
-21:37 <@jmbsvicetto> ok
-21:37 <@jmbsvicetto> We were talking in FOSDEM that the real solution to our kdeprefix issues is to get KDE support for multiple versions in the same prefix
-21:38 <+reavertm> eselect?
-21:38 <@jmbsvicetto> To get that, we'll need versioned libs and we could use versioned apps (possibly with some symlinks to choose the default versions to use)
-21:38 <@alexxy> hmm
-21:38 *  reavertm  shuts up
-21:38 <@alexxy> that will be good
-21:38 <@jmbsvicetto> reavertm: that was one option presented
-21:38 <@scarabeus> which sounds most reasonable
-21:38 <@jmbsvicetto> reavertm: I thought it wasn't the best option - at least according to users. But if we get the versioned libs+apps, than it could be a good solution
-21:38 <@alexxy> jmbsvicetto: what was another option?
-21:39 <@jmbsvicetto> reavertm: the eselect would only select the "default" version
-21:39 <+reavertm> what do you mean - versioned libs/apps
-21:39 --rangerhom- is now known as rangerpb
-21:39 <@scarabeus> sonames pn-version and so on
-21:39 <@alexxy> jmbsvicetto: you mean that konsoel would be konsole-4.2.0 ?
-21:39 <@jmbsvicetto> reavertm: having kwrite-4.1 or libkdeinit4_kinfocenter.so.4.2.0
-21:40 <@scarabeus> alexxy: only 4.2
-21:40 *      Sput  wouldn't add support for point releases
-21:40 <@jmbsvicetto> alexxy: probably 4.2
-21:40 <@scarabeus> :}
-21:40 <@alexxy> hmm
-21:40 <+wired> upstream is willing to do something like that?
-21:40 <+Sput> though this will of course screw up tab completion :(
-21:40 <@scarabeus> upstream is willing to accept our patches for that
-21:40 <+Sput> no more automatic space!
-21:40 <+Sput> ooh, upstream should do that, rather than us?
-21:40 <@jmbsvicetto> alexxy: the idea of the symlinks would be to have a konsole that would point to the version the user wants. Anyone using 4.2 as their default version, could still run 4.1 with konsole-4.1 or live with konsole-live
-21:41 <@alexxy> ok
-21:41 <+wired> this sounds so much cleaner than kdeprefix
-21:41 <@alexxy> what will be with .desktop files?
-21:41 <@jmbsvicetto> Sput: That would be the best option, but it doesn't seem likely they'll want to do it by themselves
-21:41 <+reavertm> and messy
-21:41 <+reavertm> what about shared data?
-21:41 <+Sput> also this would allow other distros (with no concept of slotted installs) to support multiple versions easily
-21:41 <@jmbsvicetto> Sput: They were however somewhat open to accept our patches to get it done
-21:42 <@tampakrap> alexxy and reavertm made some good points
-21:42 <+reavertm> like kbuildsysoca area of interest?
-21:42 <@scarabeus> reavertm: actualy it is easy to suffix any filename with cmake so it can be all sufixed correctly
-21:42 <@jmbsvicetto> reavertm: We could have /usr/share/kde/<version>/* or /usr/share/kde/<pkg>-<version>
-21:43 <+reavertm> for me it's just a rehash of kdeprefix but with messed up files and separate - swtitched shared data areas
-21:43 <@jmbsvicetto> reavertm: kdeprefix was never the best option. It was just the easy way to get around the fact that kde doesn't version libs/apps
-21:43 <+reavertm> it would be easier to just eselect using kdeprefix
-21:43 <@scarabeus> actualy this one would mean pretty nice elimination of kdeprefix really
-21:43 <@jmbsvicetto> yes
-21:44 <+reavertm> and actualy selected version of KDE would be target destination of actually built kde-misc package
-21:44 <@scarabeus> reavertm: dependency nightmare
-21:44 <@scarabeus> really
-21:44 <@jmbsvicetto> reavertm: that seems worse, imho
-21:45 <+reavertm> scarabeus we have deps already set per ebuild
-21:45 <@jmbsvicetto> reavertm: Instead, with this proposal, kde-misc packages could link directly the unversioned deps
-21:45 <@alexxy> ohh
-21:45 <@alexxy> deps hell
-21:45 <@scarabeus> reavertm: as said jmbsvicetto ^^
-21:45 <@jmbsvicetto> reavertm: The issue it raises is that KDE keeps breaking ABI which would break the packages
-21:45 <@scarabeus> you could with this enable easy linking and it would be correct
-21:45 <+Sput> well, easiest would just be going back to good old slots. :>
-21:45 <@scarabeus> Sput: grm
-21:45 <@alexxy> jmbsvicetto: what will be with misc apps that only works with for example kde>=4.3
-21:45 <@jmbsvicetto> Sput: we have slots :P
-21:46 <@scarabeus> they link to the kdelibs.so-4.3.0
-21:46 <@jmbsvicetto> alexxy: well, you're not going to like my answer, but *pkgconfig*
-21:46 <@scarabeus> for example
-21:46 <+Sput> jmbsvicetto: KDE is no longer supposed to break ABI
-21:46 <@jmbsvicetto> scarabeus: kdelibs-4.3 I would say
-21:46 <@scarabeus> or pkgconfig is even better :]
-21:46 <@scarabeus> Sput: they did it.
-21:46 <@scarabeus> so we can expect more
-21:47 <@jmbsvicetto> What we can do in the future, is to be very active in the kde-packagers / kde-build mls and don't let them get away with ABI breakage
-21:48 <@alexxy> hmm
-21:48 <@jmbsvicetto> Now, who would like to work on this and does anyone have any ideas on how to get it started?
-21:48 <@alexxy> so kde upstream will accept splitting of kde apps?
-21:49 <+reavertm> where are kde-misc packages installed and are they subject to versioning as well?
-21:49 <@jmbsvicetto> alexxy: They will start doing it for 4.3
-21:49 <@jmbsvicetto> reavertm: I would say /usr and yes
-21:50 <@jmbsvicetto> reavertm: Perhaps only between major versions
-21:50 <@alexxy> hmm
-21:50 <@alexxy> thats will be good
-21:50 <+reavertm> so the only thing that's to be done is switching XDG_DATA_DIRS?
-21:50 <@alexxy> they idea to add svn rev to snapshots was bad
-21:50 <@scarabeus> probably in basic
-21:50 <@scarabeus> but also adding sonames and so on
-21:50 <@scarabeus> alexxy: that is other point
-21:50 <@jmbsvicetto> alexxy: scarabeus mailed them about it
-21:50 <@scarabeus> i already sent the mail
-21:50 <@scarabeus> but get no response
-21:51 <@scarabeus> for 4 days now
-21:51 <@scarabeus> so i think we need to push it more
-21:51 <@scarabeus> where is the best place?
-21:51 <+reavertm> ok, I have a question - how is versioning binaries going to be implemented?
-21:51 <+reavertm> via symlinks or shell scripts that set proper env for them?
-21:51 <+reavertm> (scripts means overhead)
-21:52 <@jmbsvicetto> reavertm: I think we should add the version when we install
-21:52 <@jmbsvicetto> reavertm: We also need to write an eselect backend that can help manage the symlinks
-21:54 <+reavertm> with eselect env may be switched right away - just like in java-config
-21:54 <@scarabeus> btw you are planning way ahead i think, now we should think about who is willing to work on it :]
-21:54 <+wired> jmbsvicetto: you said upstream will accept patches for versioning, wouldn't that eliminate the need for env switching?
-21:54 <+reavertm> so only symlinks would be sufficient
-21:54 * jmbsvicet  puts the crown and starts delegating
-21:54 <@jmbsvicetto> ;)
-21:55 <@scarabeus> jmbsvicetto: dont look at me
-21:55 <@jmbsvicetto> wired: If we want to have both around, we'll need the 2
-21:55 <+reavertm> wired env switchig is XDG_DATA_DIRS at least
-21:55 <@scarabeus> i will be busy with the other distro patches sharing
-21:55 <@jmbsvicetto> wired: unless users are willing to run kwrite-4.1 and amarok-2, instead of kwrite and amarok
-21:55 * bonsaikit  fell asleep ...
-21:55 <+wired> if kde shipped kwrite-4.2 binary
-21:55 <@jmbsvicetto> bonsaikitten: Got that bored? :P
-21:55 <+wired> we would only need a symlink to make it run
-21:56 <@scarabeus> bonsaikitten: tell me your volte ;P
-21:56 <@jmbsvicetto> lol
-21:56 <@scarabeus> :]
-21:56 <@scarabeus> i am just curious
-21:56 <@scarabeus> he wont be included :D
-21:56 <@jmbsvicetto> wired: yes, but that's what we need eselect for
-21:56 <@bonsaikitten> I vote for freedom
-21:56 <@jmbsvicetto> scarabeus: lol -> "volte" ;)
-21:56 <@scarabeus> ah
-21:56 <@scarabeus> sdflhsdlfgksdhs
-21:56 * bonsaikit  still isn't coherent
-21:56 <+wired> jmbsvicetto: i agree, i was refering to env switching, not symlink management
-21:57 <@jmbsvicetto> wired: ok
-21:57 <+Sput> bonsaikitten: nobody was talking about voting, you are supposed to do a little volte...
-21:57 <+reavertm> I like the idea in general
-21:57 <@jmbsvicetto> reavertm: what can we do to start the work?
-21:57 <@jmbsvicetto> (since you are our cmake expert)
-21:58 <@alexxy> write module for eselect
-21:58 <@scarabeus> alexxy: that might be actualy last point
-21:58 <@bonsaikitten> Sput: re-volt-ing?
-21:58 <+reavertm> yeah, that's the magic part
-21:58 <+wired> eselect is probably the last of our issues
-21:58 <+reavertm> me expert? no..
-21:59 <@scarabeus> reavertm: yes you are our expert :]
-21:59 <+reavertm> besides I can't answer about this off the top of my head right away
-21:59 <@scarabeus> ok who is willing to work on this:
-21:59 <@scarabeus> it is more upstream than gentoo
-21:59 <@scarabeus> ?
-21:59 <@jmbsvicetto> I'll have to look at it
-22:00 <@jmbsvicetto> reavertm: can I nag you about cmake for this?
-22:00 <+reavertm> I'll look into it
-22:01 <@scarabeus> anyone else?
-22:01 <@scarabeus> *doggyeyes*
-22:01 <@scarabeus> or actualy *puppyeyes*
-22:01 <@jmbsvicetto> scarabeus: Thanks for your offer
-22:01 <@scarabeus> that sad look :]
-22:01 <@scarabeus> jmbsvicetto: i will be quite fine with patch cooperation
-22:01 <@scarabeus> :P
-22:01 * jmbsvicet  just made his first lead decision
-22:01 <@jmbsvicetto> :P
-22:01 <@scarabeus> :D
-22:01 <@alexxy> heh =)
-22:01 <@alexxy> btw
-22:01 <@scarabeus> jmbsvicetto: ok and mine lead decision is delegat
-22:02 <@scarabeus> e
-22:02 <@scarabeus> so HTs what are you doing? :P
-22:02 <@alexxy> whet will be with kde 3.5?
-22:02 <@scarabeus> alexxy: that is on tampakrap, dont worry :]
-22:02 <@tampakrap> mostly on carlo i'd say
-22:02 <@jmbsvicetto> bonsaikitten: Anyway we can use your tinderbox for helping with the testing?
-22:02 <@alexxy> there still parts of 3.5.7 3.58 3.5.9 and 3.510
-22:03 <@yngwin> i'd say drop 3.5.{7,8}
-22:03 <@yngwin> and stabilize .10 asap
-22:03 <@scarabeus> ok that is good idea
-22:03 <@scarabeus> get rid of 7.8
-22:03 <@jmbsvicetto> yeah, but we need to check arches keywords
-22:03 <@scarabeus> the arch teams has plenty time up to now to stable 3.5.9 on all needed arch
-22:03 <+reavertm> stabilize 3.5.10 with revbumping kde-misc to be installed in /usr/kde/3.5?
-22:03 <@scarabeus> yep
-22:04 <@alexxy> yep
-22:04 <@alexxy> but 3.5.8 is monolitic
-22:04 <@alexxy> last monolitic release
-22:04 <@scarabeus> that is no problem
-22:04 <@jmbsvicetto> alexxy: 3.5.9
-22:04 <@scarabeus> and 3.5.9 is mono to
-22:04 <@alexxy> so we can drop it =)
-22:04 <@jmbsvicetto> 3.5.10 was teh first release without monos
-22:05 <@jmbsvicetto> we need to check arch keywords as at least mips will probably lose all keywords
-22:05 <@scarabeus> jmbsvicetto: well since mips is only ~ and they had actualy pretty long time to do it up to now...
-22:06 <@scarabeus> but ok, lets poke them
-22:06 <@jmbsvicetto> scarabeus: let's talk to them
-22:06 <@alexxy> heh
-22:06 <@alexxy> i can test kde on ~mips
-22:06 *  reavertm  has his own 3 agenda points on the list
-22:06 <@alexxy> =)
-22:06 <@scarabeus> jmbsvicetto: actualy alexxy can do it :]
-22:06 <@scarabeus> late
-22:06 <@scarabeus> :D
-22:07 <@jmbsvicetto> alexxy: are you in the mips arch team?
-22:07 <@alexxy> seems they add me
-22:07 <@alexxy> =)
-22:07 <@alexxy> i have mips machine @work
-22:07 <@alexxy> running gentoo
-22:07 <@jmbsvicetto> Good :)
-22:07 <@alexxy> also i have premison to add arm keywords
-22:07 <@alexxy> =)
-22:08 <+wired> so our kde4 upstream patches goal is to patch cmake to build/install everything version-prefixed with version-suffixed binaries?
-22:08 <@scarabeus> alexxy: ok i delegate this point to you :]
-22:08 <@scarabeus> ok one last thing from me
-22:08 <@scarabeus> cooperating with reasonable distributions in patches sharing
-22:09 <@alexxy> jmbsvicetto: i'll test kde:4.2 on mips
-22:09 <@scarabeus> reasonable as debian for example
-22:09 <@scarabeus> not as suse
-22:09 <@hwoarang> scarabeus: like?
-22:09 <@jmbsvicetto> alexxy: ok, thanks
-22:09 <@scarabeus> hwoarang: like they have upstream and downstream patches we would like so we use them
-22:09 <+Sput> you mean: distros backporting features from 4.3 trunk to 4.1 stable are not reasonable? :)
-22:09 <@scarabeus> and in return we share our patches
-22:09 <@jmbsvicetto> scarabeus: We can work with any distro - it all depends on their work ;)
-22:09 <@scarabeus> for that i wrote this
-22:09 <@scarabeus> http://dev.gentoo.org/~scarabeus/patches-glep.html
-22:09 <@scarabeus> jmbsvicetto: i know
-22:10 <@scarabeus> but i think we should make our patches nicely accessable like debian do
-22:10 <+dagger_> I just came back home ;(
-22:10 <@scarabeus> dagger_: bad for ya :]
-22:10 <+reavertm> we use sed :P
-22:10 <+Sput> System Message: ERROR/3 (patches-glep.txt, line 65)
-22:10 <+Sput>  Unexpected indentation.
-22:10 <+Sput> coool :
-22:10 <@scarabeus> i know
-22:10 <+Sput> :)
-22:10 <@scarabeus> it is not finished
-22:11 <@scarabeus> christ why i showed it to you
-22:11 <@scarabeus> i thought that somebody start complaining
-22:11 <+Sput> :D
-22:11 <@scarabeus> notes for this one will be accepted on my mail for now
-22:11 <@scarabeus> until i get it into some reasonable shape for anouncing
-22:12 <@hwoarang> your abstract idea is quite resonable
-22:12 <@hwoarang> have you talked about this with other distro dudes?
-22:12 <@tampakrap> we had a small chat with a debian-kde guy at fosdem
-22:12 <@scarabeus> yep i talked with kde
-22:12 <@scarabeus> debina
-22:12 <@scarabeus> craaap
-22:13 <@jmbsvicetto> scarabeus: You'll want to talk to infra and security teams about your proposal
-22:13 <@scarabeus> yes i will do it
-22:13 <@scarabeus> when i finish it
-22:13 <@scarabeus> :P
-22:13 <@jmbsvicetto> hehe
-22:13 <@scarabeus> i dont want to come there with my hands empty
-22:13 <@scarabeus> i would feel lame
-22:14 <@scarabeus> so you know that i am on this one
-22:14 <@scarabeus> that is everything from my side
-22:14 <@scarabeus> anyone what do you have to discuss
-22:14 <@jmbsvicetto> scarabeus: Did we cover all business in the agenda?
-22:15 <@scarabeus> the things i pointed out
-22:15 <@scarabeus> but this month i didnt get notes from others
-22:15 <@scarabeus> (short time)
-22:15 <+reavertm> ok... pykde4?
-22:15 <@scarabeus> that is why i ask now
-22:15 <@scarabeus> that bonsaikitten said that he will look on it
-22:15 <@scarabeus> last meeting
-22:15 <@scarabeus> :D
-22:15 <+reavertm> that's the problem :)
-22:16 <+reavertm> ok, another one
-22:16 <+reavertm> what about non-SLOTted sets?
-22:16 <@alexxy> btw
-22:16 <@alexxy> when sets will be added to tree?
-22:16 <+reavertm> I'd propose to remove them or made symlinks -> @kdebase -> @kdebase-4.2 and so on
-22:17 <@tampakrap> are the symlinks valid?
-22:17 <+reavertm> because unSLOTtted sets pulll all versions from every SLOT
-22:17 <+reavertm> (in overlay)
-22:17 <+reavertm> alexxy no
-22:17 <+reavertm> never :)
-22:17 <+reavertm> tampakrap why they coudn't be?
-22:17 <@scarabeus> reavertm: good idea
-22:18 <@jmbsvicetto> alexxy: That needs more time
-22:18 <@jmbsvicetto> alexxy: we need to get an agreement about it
-22:18 <@alexxy> ohh
-22:18 <@alexxy> =(
-22:18 <@tampakrap> reavertm: i don't know, i'm just asking :)
-22:18 <@scarabeus> tampakrap: it works
-22:18 <@yngwin> i guess that means at least waiting till portage 2.2.0 final release
-22:18 <@jmbsvicetto> reavertm: the unversioned set should match the last version
-22:19 <@tampakrap> last version of portage kde or of snapshots?
-22:19 <+reavertm> yes
-22:19 <@jmbsvicetto> reavertm: wait, you want them to have slotted deps? They can't
-22:19 <+reavertm> those would be symlinks to latest set (but versioned one)
-22:19 <+reavertm> jmbsvicetto it simplyfies upgrade
-22:19 <@alexxy> yep
-22:20 <+reavertm> I want unslotted sets to be removed or changed to symlinks to corresponding slotted sets
-22:20 <@jmbsvicetto> reavertm: The unversioned deps should match the last version with sed s/:.*$//
-22:20 <@alexxy> but unversioned sets should point to latest in tree slot
-22:21 <@jmbsvicetto> reavertm: We need/want users to run the unversioned sets for installing - thus it can't have slotted deps
-22:21 <+reavertm> jmbsvicetto wait wait
-22:21 <+reavertm> there would be @kdebase set - the only difference would be, it would be symlink to @kdebase-4.2
-22:22 <@jmbsvicetto> reavertm: but that would mean it would have a kdebase-startkde:4.2 dep
-22:22 <@tampakrap> aka latest portage version
-22:22 <+reavertm> how are deps related?
-22:22 <@jmbsvicetto> reavertm: I'm thinking :P
-22:22 <+reavertm> they would be symlinks to latest portage version
-22:23 <@jmbsvicetto> reavertm: I understand what you're trying to do. It might be the easiest option and it might even work
-22:23 <+reavertm> (just like they are now) - but with SLOT definition so that we actually pull only that slot
-22:23 < Enrico[ITA]> hi guys! if here there is some dev of kde-testing overlay there are some missing deps in kde-3.5.keywords file: kde-base/kde-i18n:3.5    ~kde-base/dcoppython-3.5.10   (and app-pda/libopensync but this is not part of kde ^^)
-22:23 <@jmbsvicetto> Enrico[ITA]: we're in the middle of a meeting. Stick around and we can talk about it later
-22:24 <@jmbsvicetto> reavertm: ok, I think I can live with it
-22:24 <@tampakrap> i agree with that too
-22:24 <+reavertm> jmbsvicetto well, it doesn't change anything from user perspective
-22:24 <@jmbsvicetto> reavertm: my concern was that we might be restricting users to a specific slot
-22:24 < Enrico[ITA]> jmbsvicetto: oh don't warry it is not a huge issue ^^. but ok i can wait no problem ^^
-22:24 <@scarabeus> yeah it should work
-22:24 <@scarabeus> jmbsvicetto: that should be working correctly
-22:25 <@scarabeus> the update with this
-22:25 <@scarabeus> iirc the behavior portage does
-22:25 <+reavertm> well, we would be responsible for managing those symlinks in overlay
-22:25 <@jmbsvicetto> reavertm / scarabeus: yes, I see it should work
-22:25 <@jmbsvicetto> reavertm: hmm, I do hope to get those sets in the tree - one day, one day
-22:26 <@jmbsvicetto> reavertm: actually, if/when zmedico gets to re-work the sets, we might just have unversioned sets
-22:26 <+reavertm> yeah
-22:26 < Enrico[ITA]> well since you are in the middle of a meeting think about mark kde 3.5.10 as stable (and maybe even kde4.2!!!!) well i'm just kidding don't ban me ihihihi :P
-22:26 <@jmbsvicetto> reavertm: or we would, if upstream stopped playing with moving apps between tarballs and renaming apps
-22:26 < Enrico[ITA]> i don't speak no more promise ^^
-22:27 <+reavertm> well, it's up to us how we split packagees jmbsvicetto :)
-22:27 *  reavertm  likes good refactoring
-22:27 <@jmbsvicetto> reavertm: we'll have to follow the work being done for 4.3
-22:27 <@jmbsvicetto> :)
-22:28 <@tampakrap> that's why snapshots and :live are :)
-22:28 <@tampakrap> we were following 4.2 pretty well if you recall
-22:28 <@jmbsvicetto> yes, but they're talking about splitting packages for 4.3
-22:29 <@jmbsvicetto> They seem willing to break apps, but not libs
-22:29 <@jmbsvicetto> I think we should probably rethink the way we split libs and kdebase-runtime/kdebase-workspace
-22:29 <@alexxy> why?
-22:29 <@tampakrap> so what? i rebuild live every two days i follow changes
-22:30 <@jmbsvicetto> alexxy: we probably don't need to split it up so much
-22:30 <+reavertm> probably
-22:30 <@alexxy> well i think current split are pretty well =)
-22:30 <+reavertm> I'd vote for debian-like splitting scheme
-22:31 <+reavertm> they split kdepim completely (like we do) but kdebase-workspace /runtime not that much
-22:31 <@alexxy> reavertm: what it looks like?
-22:31 <@tampakrap> ok i'll have a look at this
-22:31 <+reavertm> (as those apps need to be installed for kde to work anyway)
-22:31 <+reavertm> (they split plasma from kdelibs - for now reason whatsoever)
-22:32 <@alexxy> hmmm
-22:33 <+reavertm> ok, and I have another idea - drop kdepimlibs from DEPEND in eclass
-22:33 <@alexxy> last time i take a look at debian it was using kde 2.x or 1.x dont remember
-22:33 <+reavertm> I made alittle research and there are just some components that actually need it
-22:34 <+reavertm> and plenty of people crying aabout mysql deps (akonadi server is pulled by kdepimlibs)
-22:34 <+reavertm> alexxy well... you can look at Kubuntu...
-22:34 <@jmbsvicetto> reavertm: seems like aseigo was willing to split plasma from kdelibs too
-22:34 <+reavertm> it's debian afterall
-22:34 <@tampakrap> upstream is going to import other dbs as well
-22:34 <+reavertm> tampakrap any evidence?
-22:34 <@jmbsvicetto> reavertm: if we can drop it, we should
-22:34 <@tampakrap> fosdem talks :)
-22:34 <@jmbsvicetto> (kdepimlibs)
-22:34 <+reavertm> apart tahat techbase article saying that itis possible to implement but not planned?
-22:35 <@jmbsvicetto> tampakrap: s/import/support/ ?
-22:35 <+reavertm> jmbsvicetto yeah, we can
-22:35 <+reavertm> I've made a list for kde-base stuff that needs it (I was grepping KdepimLibs in cmakelistx.txt in tarballs
-22:36 <@jmbsvicetto> reavertm: ok, I'll look at it
-22:36 <+reavertm> jmbsvicetto no, you "encourage" kitten to take care of pykde4 :)
-22:36 <@jmbsvicetto> hehe
-22:37 * jmbsvicet  picks up the whip and calls for bonsaikitten
-22:37 <@jmbsvicetto> kitten, kitten
-22:38 <@scarabeus> :D
-22:38 <@scarabeus> ouka i am back
-22:38 <@scarabeus> what i sleft
-22:38 <@scarabeus> (sorry i feel really dizzy today)
-22:39 <+MrRat> reavertm: yes more db support is coming for akonadi
-22:39 <+MrRat> http://techbase.kde.org/Projects/PIM/Akonadi#Akonadi_FAQ
-22:40 <@jmbsvicetto> What are we still missing for today?
-22:40 <+MrRat> a crazy hack at fixing amarok2 for qt-4.5
-22:40 <@tampakrap> yes, me and scarabeus saw it at fosdem talk of the debian kde packager
-22:41 <@scarabeus> jmbsvicetto: i dont know
-22:41 <@scarabeus> i dont  have anything for adding
-22:41 <@scarabeus> anyone else something?
-22:41 <@ hwoarang> yngwin do we have something to add?
-22:42 <@scarabeus> hwoarang, yngwin: actualy you two could you test qt-4.5 on kde-4.2 and spread patches? :]
-22:42 <@ yngwin|2> kde4 doesnt work here
-22:42 <@tampakrap> y?
-22:42 <@hwoarang> works here though
-22:43 <@hwoarang> scarabeus who this thing gonna work?
-22:43 <@alexxy> http://dpaste.com/119912/
-22:43 <@hwoarang> gentoo qt <-> gentoo kde <-> kde upstream
-22:43 <@alexxy> list of kde-3.5.[45678] ebuilds
-22:43 <+wired> i can help on qt4.5/kde4.2 testing :)
-22:43 <@hwoarang> we need to CC kde@gentoo.org on every kde4+qt4-5 related issue
-22:43 <@   alexxy> yngwin: hwoarang: plasma segfaults with qt 4.5 if you dont recompile it
-22:44 <@alexxy> same for knotify
-22:44 <@hwoarang> there is a topic on kde forums
-22:44 <@hwoarang> kde-4.2+qt-4.5
-22:44 <@tampakrap> recompile qt or knotify?
-22:44 <@alexxy> so you two should add it to ewarn
-22:44 <@hwoarang> maybe it will be good to monitor it
-22:44 <@alexxy> recompile knotify and plasma-workspace
-22:45 <@hwoarang> alexxy: we need to narrow down what should be rebuild
-22:45 <@hwoarang> if something fails
-22:45 <+reavertm> I guess I'm out of ideas for today as well
-22:45 <@hwoarang> and i think that our ewarn message is quite clean
-22:45 <@hwoarang> "if something fails, rebuild it"
-22:45 <@alexxy> yep
-22:45 <@jmbsvicetto> alexxy: the kde packages segfault after qt upgrade is an old issue
-22:45 <@tampakrap> are these talks still on the meeting?
-22:45 <@alexxy> but you only mention kdelibs
-22:45 <@hwoarang> this is what every qt package states on pkg_postinst
-22:45 <@alexxy> =)
-22:46 <@alexxy> jmbsvicetto: i know
-22:46 <@hwoarang> if this solution is valid i ll add it
-22:46 <@alexxy> but for 3.5 only kdelibs was needed to be recompiled
-22:46 <@hwoarang> but there is a report on forums that libplasma+ plasma-workspace didn solve it
-22:46 <@alexxy> for 4.2  its at least kdelibs and plasma-workspace
-22:47 <+MrRat> if sets were in portage an @kde-4.2 would solve it
-22:47 <+MrRat> :P
-22:47 <@alexxy> he he
-22:47 <@hwoarang> so , from my part i ll CC kde@g.o alias on every mixed kde4+qt4.5 bug
-22:47 <@hwoarang> to work it together
-22:47 <@scarabeus> http://pastebin.ca/1335397
-22:48 <@scarabeus> reformat add on cvs
-22:48 <@hwoarang> i wish i could do it on bugs.kde.org too
-22:48 <@scarabeus> i am sick and going to sleep
-22:48 <@scarabeus> i hope i wont be needed today anymore
-22:48 <@tampakrap> i guess meeting is over
-22:49 <@jmbsvicetto> scarabeus: You should end the meeting then ;)
-22:49 <@jmbsvicetto> hwoarang: what are you missing in bgo ?
-22:49 <@tampakrap> you are the leader
-22:49 <@hwoarang> mmm
-22:49 <@jmbsvicetto> ah, bko
-22:50 <@hwoarang> every time i try to add a gentoo alias
-22:50 <@hwoarang> it slaps me
-22:50 <@hwoarang> ah
-22:50 * jmbsvicet  puts the hat and officialy ends the meeting
-22:50 <@hwoarang> no on bgo
-22:50 <@hwoarang> on bugs.kde.org
-22:50 <@jmbsvicetto> yeah, I noticed it after I asked
-22:50 <@jmbsvicetto> scarabeus: just one issue before you go, if you have 2 minutes
-22:52 <@scarabeus> ook
-22:53 <@scarabeus> listening
-22:53 < arachnist> so, since the meeting has ended
-22:53 < arachnist> is there a nice, working networkmanager plasmoid for kde-4.2? :>
-22:53 < arachnist> preferably with an ebuild
-22:54 <@jmbsvicetto> scarabeus: About the meetings, do you want me to start doing the preparation work or would you be willing to keep doing it?
-22:54 <@scarabeus> i am willing to keep doing it if you want :]
-22:54 <@jmbsvicetto> scarabeus: You've been doing a great job and I don't want to take away that pleasure from you ;)
-22:54 <@jmbsvicetto> scarabeus: thanks
-22:54 <@scarabeus> it is not pleasure ;D
-22:54 <@scarabeus> but i will do it
-22:54 <@jmbsvicetto> Hehe
-22:54 <@scarabeus> since nobody else wants to do it :]
-22:55 <@jmbsvicetto> ok, meeting in 1 month?
-22:55 <@scarabeus> arachnist: there is networkmanager-applet-9999 in kde-testing
-22:55 <@jmbsvicetto> I think we should review the date as I missed the council meeting today :\
-22:55 <+MrRat> arachnist: networkmanager-applet ebuild is in kde-testing, but in short, networkmanager nor the applet work well.
-22:56 <+MrRat> arachnist: use wicd
-22:56 < arachnist> wicd?
-22:56 <+MrRat> yes
-22:56 < arachnist> it needs gtk
-22:56 <@scarabeus> yup 1 per month
-22:56 <@scarabeus> feel free to change the date
-22:56 < arachnist> there;s a reason i have gtk+ in package mask
-22:56 < Pesa> may i ask if you could remove the new hard dep on qt-phonon for Qt 4.5, making it optional?
-22:56 <@scarabeus> i just randomly picked
-22:56 < arachnist> there's*
-22:56 <+MrRat> wicd works great and you can start wicd-client in kde4's ststem settings autostart and it works great
-22:57 <@jmbsvicetto> scarabeus: ok
-22:57 < arachnist> not a very valid one, but there is ;>
-22:57 <@jmbsvicetto> scarabeus: I think we might opt for the 1st Thursday of the month
-22:57 <@jmbsvicetto> I'll ask in the alias/ml
-22:57 <@scarabeus> that is already in there or not?
-22:57 <@scarabeus> :D
-22:57 <@jmbsvicetto> ok, I'm going to eat something
-22:58 <@yngwin> Pesa: there is no hard dep on qt-phonon
-22:58 <@scarabeus> on the first Wednesday/Thursday of every month at 19:00 UTC
-22:58 <@scarabeus> indeed i wrote this ;}
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090401.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090401.txt
deleted file mode 100644
index 0c83346ffb..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090401.txt
+++ /dev/null
@@ -1,601 +0,0 @@
-21:01 <@scarabeus> hey
-21:01 <@scarabeus> now we can start
-21:01 <@jmbsvicetto> I'm out of here. See you later :P
-21:02 <@alexxy> jmbsvicetto: stay here =)
-21:02 <@scarabeus> hehe
-21:02 <@scarabeus> !herd kde
-21:02 < Willikins> (kde) alexxy, caleb, carlo, cryos, deathwing00, genstef, jmbsvicetto, keytoaster, mattepiu, patrick, scarabeus, tampakrap, tgurr
-21:02 <@scarabeus> krytzz: reavertm Sput wired 
-21:02 <@scarabeus> ausing again
-21:02 <@scarabeus> meeting time
-21:03 <+krytzz> aye
-21:03  * tampakrap is here
-21:03 <@cryos|work> That was an hour ago wasn't it? I thought we were done :P
-21:03  * jmbsvicetto agrees
-21:03 <@scarabeus> :D
-21:03  * alexxy here or there like a psi^2
-21:04 <@scarabeus> bonsaikitten: dont hide, i saw ya
-21:04 -!- jmbsvicetto changed the topic of #gentoo-kde to: Official Gentoo KDE Project channel | Next Meeting^Wamarok party: Wednesday April 1st 19:00 UTC | KDE 4 guide: http://tinyurl.com/4n47v4 | Overlays: kde-testing, qting-edge | Want to help us? Ask channel staff for info | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3
-21:04 <@scarabeus> !herd qt
-21:04 < Willikins> scarabeus: (qt) caleb, carlo, hwoarang, yngwin
-21:04  * jmbsvicetto starts jumping around
-21:04 <@jmbsvicetto> scarabeus: ok, ok. I'll behave ;)
-21:04 <@hwoarang> im here
-21:04  * hwoarang GOGO GREEEEEEEEEEEEEECE
-21:04 <@scarabeus> jmbsvicetto: well you are the lead, you do the example for us :D
-21:05 <@scarabeus> remember we store meeting logs tho :D
-21:05 <@tampakrap> i think we shouldn't this time
-21:05 <@scarabeus> hehe
-21:05 <+reavertm> ok...
-21:05 <@scarabeus> reavertm: you are first on list
-21:05 <@scarabeus> so speak up
-21:06 <@scarabeus> :D
-21:06 <+reavertm> so, kdeprefix
-21:06 <@scarabeus> http://www.pastebin.cz:80/16911
-21:06 <+reavertm> the idea is ... to drop it :)
-21:06 <@scarabeus> (list for others)
-21:06  * wired back
-21:06 <@alexxy> or mask kdeprefix useflag
-21:06 <@alexxy> =)
-21:06 <+reavertm> (from non kde-base)
-21:06 <@tampakrap> i agree
-21:07 <+reavertm> I already started to play in dropped-kdeprefix-on-non-kde-base branch if anyone is interested
-21:07 <@alexxy> may be better to mask it for all packages
-21:07 <+reavertm> in the process I rewritten kde4 eclass
-21:07 <@alexxy> so people who realy want could unmask it
-21:07 -!- spitfire_ [n=quassel@ackz136.neoplus.adsl.tpnet.pl] has joined #gentoo-kde
-21:07 <+reavertm> important changes are:
-21:07 <@scarabeus> alexxy: nah i prefer nonkdeprefix, it is better
-21:08 <@scarabeus> alexxy: less thins to worry about
-21:08 <+reavertm> NEED_KDE deprecated in favor of KDE_REQUIRED and KDE_MINIMAL (the latter already there)
-21:08 <+wired> scarabeus++
-21:08 <@alexxy> scarabeus: i use -kdeprefix too 
-21:08 <@alexxy> so we can mask kdeprefix use flag for tree packages
-21:08 <@tampakrap> if we mask it, we somehow still provide support for it, something that i don't want
-21:08 <@cryos|work> I use -kdeprefix too, but I think it would be nice to keep it as an option that can be unmasked. It has its uses, I just don't think it is for general consumption...
-21:08 <@alexxy> so people who want install 4.2 4.3 and live together can unmask it
-21:09 <+reavertm> my eclass drops kdeprefix from non-kde-base
-21:09 <@scarabeus> alexxy: the part for non-kde-base
-21:09 <@scarabeus> not for base kde
-21:09 <@scarabeus> :D
-21:09 <+reavertm> do you even read me?
-21:09 <@scarabeus> we are not removing the flags from kdebase/*
-21:09 <@scarabeus> :D
-21:09 <@cryos|work> Is there a way to hack it back in for non-kde-base if you don't care about support?
-21:09 <@tampakrap> everybody stop typing until reavertm finishes his words please
-21:09 <@scarabeus> cryos|work: narp
-21:10 <@scarabeus> for the eclass i already read it and i think it is much cleaner, specialy no "get_latest_kdedir"
-21:10 <@cryos|work> I work on several packages where I would like trunk and release. I could locally hack it, but the current situation is useful even if not supporte.d
-21:10 <+reavertm> RPATH solves possible linking issues
-21:10 <@scarabeus> well we droped mostly live slot for packages
-21:10 <@scarabeus> cryos|work: buty you can allways override prefix so it shoudl be no prob
-21:11 <+reavertm> now packages are built not agains newest available KDE (if more installed) but with the oldest - yet respecting KDE_MINIMIAL
-21:11 <@cryos|work> Seems a shame, but I can maintain custom ebuilds for the few I work on.
-21:11 <+reavertm> scarabeus: all live slots dropped
-21:12 <@jmbsvicetto> hmm, scarabeus / reavertm drop kdeprefix for non-live, right?
-21:12 <@scarabeus> for everything
-21:12 <@jmbsvicetto> scarabeus / reavertm: !kde-base live apps should install under /usr/kde/live
-21:13  * cryos|work thought that too...
-21:13 <+reavertm> /usr/kde/live is KDE release dir and should not contain any 3rd party apps imho
-21:13 <@scarabeus> that wont run for pple that install live misc apps for 4.2 in example
-21:13 <@alexxy> jmbsvicetto: no =)
-21:13 <@jmbsvicetto> We've been talking about this for a long time. all live ebuilds should go under /usr/kde/live
-21:13 <@scarabeus> i use lots of live apps
-21:13 <+reavertm> how aboyut accessing those live packages from kde 4.2 ?
-21:13  * alexxy also use kile amarok and k3b
-21:13 <@alexxy> with 4.2 and 4.3 snapshots
-21:14 <@alexxy> so i dont like idea of dropping kdeprefix for misk apps
-21:14 <@jmbsvicetto> If we use the KDE_MINIMAL it should work, no?
-21:14 <@cryos|work> So you are dropping any support for installing/building live apps against live KDE builds?
-21:14 <@alexxy> in way as jmbsvicetto said
-21:14 -!- [DWSR] is now known as DWSR
-21:14 <+reavertm> how is dropping kdeprefix from live packages related to not being able to use them with 4.2 ?
-21:14 <@scarabeus> cryos|work: so you think live should be special case...
-21:15 <@scarabeus> reavertm: well it can be done so live is special enviroment
-21:15 <@alexxy> i think better to mask kdeprefix use flag for all kde in tree
-21:15 <@scarabeus> and we can just not bother for it
-21:15 <@jmbsvicetto> scarabeus: That's why live doesn't fit in SLOTS ;)
-21:15 <@cryos|work> scarabeus: I always have, but I tend to work with live and do development, but want a stable desktop for work...
-21:15 <@alexxy> so people who want eg 4.2 and live togther can deal with it
-21:16 <@scarabeus> alexxy: current approach is broken
-21:16 <+reavertm> I use 4.2 and live non-kde-base stuff
-21:16 <@scarabeus> i srsly fear next major release
-21:16 <@jmbsvicetto> ok, let's try something different
-21:16 <@jmbsvicetto> The point of having kdeprefix was to allow running more than 1 version at the same time
-21:16 <@cryos|work> I guess for people with live KDE, and live misc apps built against 4.2 things would likely still work though.
-21:16 <@scarabeus> eys that is maintained
-21:16 <+reavertm> jmbsvicetto: be more precise
-21:16 <+reavertm> more than one version of what?
-21:17 <+reavertm> KDE release or any package?
-21:17 <@jmbsvicetto> With the exception of live (imo) which should be under /usr/kde/live - the real solution for that is to change the kde build system and have all versions under /usr
-21:17 <@cryos|work> KDE, but are you really trying to separate packages that build against it?
-21:17 <@scarabeus> well it is like kde3
-21:17 <@scarabeus> cryos|work: 
-21:17 <@jmbsvicetto> reavertm: more than one KDE release
-21:17 -!- non7top [n=non7top@94.77.134.21] has joined #gentoo-kde
-21:17 <+reavertm> and you'll still have it :P
-21:18 <@cryos|work> OK - I will stay quiet. I am really busy today anyway and have not been on IRC for weeks....
-21:18 < spitfire_> cryos|work: no it doesn't always work. I had quassel built against 4.2 and it didn;t run in live complaining about missing symbols in oxygen.so.
-21:18 <@jmbsvicetto> The point is whether anyone is willing to start the work
-21:18 <@jmbsvicetto> I haven't looked at that yet
-21:18 <+reavertm> spitfire_: 
-21:18 <+reavertm> nop
-21:18 <@jmbsvicetto> cryos|work: I would like to get your opinion about this issue
-21:18 <+reavertm> you had quassel built againd live that didn;'t work with 4.2
-21:19 <+reavertm> because so far it was like this - having 4.2 and -9999 - apps were bult againt *the newest* kde
-21:19 <@cryos|work> At least now KDE will work if built against an old KDE and linked to a newer one.
-21:19 <@scarabeus> yes 
-21:19 <@jmbsvicetto> cryos|work: We've talked a lot about this and tried to reach a compromise that would satisfy everyone, so I would like that any change gets our support
-21:19 <@cryos|work> So building against 4.2 and linking to live should work, assuming no one screwed up and I do that a lot.
-21:19 <@scarabeus> yes it have to wor
-21:19 <@scarabeus> the cant break abi
-21:19 < spitfire_> reavertm: sry to interrupt but for example quassel never finds kde-live, always builds against 4.2
-21:19 <+reavertm> actually there's RPATH
-21:20 <+reavertm> if we drop RPATH then we may start worrying about linkage problems
-21:20 <@cryos|work> It doesn't have to - people screw up... And there is RPATH which can force linking to a particular path.
-21:20 <@jmbsvicetto> scarabeus: that's the "theory", but that's not their practice
-21:20 <@alexxy> spitfire_: later
-21:20 <@scarabeus> indeed
-21:20 <@cryos|work> jmbsvicetto: They do pretty well on the whole, but RPATH alleviates issues with screw ups too...
-21:20 <+reavertm> (and I'm going to drop rpath for -kdeprefix)
-21:20 <+reavertm> (btw)
-21:20 <@jmbsvicetto> cryos|work: all the mess with libplasma, phonon, kdeartwork-kscreensaver, ...
-21:21 <+reavertm> phonon is kdeprefix problem
-21:21 <@cryos|work> Like I said, they do pretty well... ABI is really tough to keep stable...
-21:21 <+reavertm> it install kde4 plugins
-21:22 <+reavertm> adding QT_PLUGIN_PATH to /usr/lib64/kde4/plugins could possibly solve it
-21:22 <@jmbsvicetto> cryos|work: The problem is that 4.0 was nowhere where they wanted it to be, so they've realized many things required changes
-21:22 <@cryos|work> Yeah, I know... Mixing versions is always really tough to get right too.
-21:22 <+reavertm> 4.3 is meant to be ABI compliany with 4.2
-21:23 <@scarabeus> ok how about removing prefix totaly
-21:23 <@scarabeus> and have live/stable
-21:23  * jmbsvicetto looks at bonsaikitten 
-21:23 <@scarabeus> so live apps are their own env
-21:23 <@scarabeus> and the stable is /usr
-21:23  * reavertm doesn't get it
-21:23 <+reavertm> where does live go?
-21:23 <@scarabeus> on the live note we can generate snapshots (weekly)
-21:23 <@scarabeus> /usr/kde/live/
-21:24 <@scarabeus> everything live
-21:24 <@bonsaikitten> jmbsvicetto: what!
-21:24 <+reavertm> how is this different from current situation?
-21:24 <@scarabeus> i still prefer your solution
-21:24 <@jmbsvicetto> scarabeus: To be honest, I'm losing the "motivation" to keep hammering about kdeprefix, but that was the major issue I had to deal with when we started working back in KDE
-21:24 <@scarabeus> reavertm: that there wont be kdeprefix anywhrere else than in live
-21:24 <@jmbsvicetto> scarabeus: That's why I've resisted so long to dropping it
-21:24 -!- ali_bush [n=alistair@gentoo/developer/alibush] has quit [Remote closed the connection]
-21:24 <@scarabeus> jmbsvicetto: well reavers approach is working with +kdeprefix and keeping good usability
-21:24 <@jmbsvicetto> bonsaikitten: Do you still care about kdeprefix or not?
-21:25 <@scarabeus> trust me it is  500% better than current solution of mine
-21:25  * cryos|work has also grown tired of the back and forth... Just want a reasonably stable env for users, and a solution for developers....
-21:25 <@alexxy> kdeprefix can be masked 
-21:25 <@jmbsvicetto> bonsaikitten: As I recall, you also felt it was important to have it and to allow users to mix versions
-21:25 <+reavertm> well, it's not working yet :P
-21:25 <@bonsaikitten> jmbsvicetto: my opinion hasn't changed since it was introduced
-21:25 <@alexxy> so users who sant it will unmask it
-21:25 <+reavertm> (plugins are not loaded properly - amarok issue)
-21:25 <@alexxy> but its good fature to have more then one kde release installed
-21:26 <@scarabeus> i would say lets see how it work and we can roll it out with 4.2.3
-21:26 <+reavertm> what's all with this masking kdeprefix?
-21:26 <+reavertm> you can use.force it if you like :P
-21:26 <@jmbsvicetto> cryos|work / bonsaikitten: So, what do you say about this?
-21:26 <@scarabeus> i am for reavers solution
-21:27 <@cryos|work> Honestly, I am no longer certain what is being proposed. I feel like we really need to pick a solution and try to stick with it. The Apache team went back and forth over a few years and drove many users away...
-21:27 <@alexxy> reavertm's solutions better for misk packages 
-21:27 <+reavertm> my idea (if it works) is to be possible to have kdeprefixed releases and the rest in /usr (accessible from any kde installed)
-21:27 <@jmbsvicetto> I guess I'll swallow kdeprefix at this time and will try to force me to look at the build system to allow the multiple versions / better split of packages
-21:27 <@bonsaikitten> jmbsvicetto: I haven't followed the discussion enough to have useful input
-21:28 <@jmbsvicetto> cryos|work / bonsaikitten: Then if you don't oppose, I say we try reavertm's approach
-21:28 <@scarabeus> bonsaikitten: kdeprefix for kde-base, misc apps into /usr including live misc apps
-21:28 <@bonsaikitten> sounds acceptable
-21:28 <@bonsaikitten> as I haven't contributed anything relevant in a while I don't see why I should be the decider
-21:28 <@scarabeus> ok majority already agreed
-21:28 <+reavertm> well,  there's nothing spectaculat to try now, if it works then we'll see - i need to handle this plugins paths 1st
-21:29 <@cryos|work> I can live with it, I would rather be able to put misc live apps in /usr/kde/live too, but can likely hack the ebuilds I care about...
-21:29 <@jmbsvicetto> cryos|work / bonsaikitten: If in the end we realize we lost some flexibility, that will only serve to foster the need to look for the real solution (imho) - fixing the build system
-21:29 <@bonsaikitten> jmbsvicetto: acceptable :)
-21:29 <@scarabeus> bonsaikitten: could you fix at least 258027
-21:29 <+reavertm> actually there's not a problem with restoring kdeprefix for misc apps, but
-21:29 <@cryos|work> So you are going to try and mix multiple versions in /usr?
-21:29 <+reavertm> live kde-misc would nee to have separate prefix :P
-21:30 <@jmbsvicetto> cryos|work: I think that's the "final" solution
-21:30 <@jmbsvicetto> cryos|work: I don't have any particular skill or knowledge to get it done, though
-21:30 <@cryos|work> That sounds amazingly tough to pull off.
-21:30 <@cryos|work> Not this solution though?
-21:30 <+reavertm> ok, cryos|work what's your proposition?
-21:30 <@bonsaikitten> scarabeus: oh ... let's see
-21:31 <+krytzz> hm... would that allow to mix 4.2 kdelibs and live kde-misc stuff for example?
-21:31 <+reavertm> maybe it apperas easier to handle than kde-misc in /usr
-21:31 <@cryos|work> I don't have one, more trying to understand what this proposal is planning on changing.
-21:31 <@jmbsvicetto> cryos|work: That solution isn't "compromised" for the current proposal
-21:31 <@scarabeus> the current pospal is easing major bumps, lets stick with it for 4.3 and then we can think about updating the build system
-21:31  * cryos|work was just trying to figure out if he understood what *this proposal* encompassed.
-21:32 <+reavertm> ok, let me summarize
-21:32 <+reavertm> the problem with kdeprefix for kde-misc apps is as follows :
-21:33 <+reavertm> let's say we have taglib-extras
-21:33 <+reavertm> it has optional kde integration
-21:34 <@cryos|work> So you are concerned with corner cases?
-21:34 <+reavertm> still it's just typical lib and should be accessed globally - it would be nice for it to not be kde-prefixed
-21:34 <+reavertm> or any other app - like amarok - I want it installed and used from any KDE4 i have (and I have 4.2, 4.3, live)
-21:34 <@cryos|work> I totally agree. I was the one who wanted to throw everything in /usr apart from development builds where people got to pick up the pieces themselves...
-21:35 <@cryos|work> If I develop on amarok I can write a custom ebuild if I want it in my /usr/kde/live as any dev can, so the impact is not terrible.
-21:35 <@cryos|work> I was more trying to confirm the scope of the changes proposed.
-21:36 <@jmbsvicetto> reavertm: The only issue I see and the reason for the kdeprefix is if you have k3b-1.* working and want to follow k3b-2.* (which I think is still broken), you're not willing to have to choose between one or the other
-21:36 <@jmbsvicetto> reavertm: But as stated, I'm going to drop my "resistance"
-21:36 <+reavertm> k3b-1 will be installed in kde3 prefix so i am told
-21:36 <+reavertm> (tampakrap?)
-21:36 <@cryos|work> That was my concern, but those users could be out of luck...
-21:36 <@cryos|work> At some stage having too much choice can spread us too thin.
-21:37 <@cryos|work> Many distros are just dropping KDE 3 entirely already.
-21:37 <@jmbsvicetto> cryos|work: yeah. The problem is that some users have been mailing us asking us not to do it
-21:37 <@scarabeus> ok put it straight: lets just comfor for now on that we are going to support unprefixing misc apps
-21:37 <@jmbsvicetto> cryos|work: And I think we haven't convinced everyone in the kde team that kde-4 is better
-21:37  * jmbsvicetto looks at yngwin 
-21:37 <@cryos|work> I am not proposing we do - I am just pointing out what is happening.
-21:38 <@jmbsvicetto> cryos|work: I agree
-21:38 <@cryos|work> I think many distros dropped KDE 3 too soon.
-21:38 <+reavertm> kdeprefix as great idea and flexibility it adds, it's pain in ass to mantain :P
-21:39 <@cryos|work> I was more making the point that Gentoo has such an extreme amount of choice compared to other distros we could end up chasing bugs no-one else cares about that only crop up in slotted envs.
-21:39 <+reavertm> (btw, eselect for kde is not required)
-21:39 <@cryos|work> Reducing overall quality which is bad. Not claiming I have the answer either... ;-)
-21:40 <@scarabeus> :]
-21:40 <@jmbsvicetto> we're all brainstorming ;)
-21:40 <@jmbsvicetto> tampakrap: How's your work on the kde3 eclasses going?
-21:41 <@cryos|work> I am very attached to Gentoo and KDE. I don't want to see it go to crap, don't have as much time as I would like these days.
-21:41 <@tampakrap> eclasses are ready
-21:41 <@tampakrap> i'm still on the ebuilds
-21:41 <@scarabeus> and the packages are compilling fine?
-21:41 <@jmbsvicetto> tampakrap: kdeprefix isses on kde4 are hurting us, but colisions with kde3 apps are doing us more harm (imho)
-21:41 <@cryos|work> Bumped avogadro for the super nerdy people who want to play though ;-)
-21:41 <@tampakrap> i'll tell you what i need
-21:41 <@tampakrap> if there are two people willing to test kde3 misc apps that would be greate
-21:42 <@tampakrap> great
-21:42 <@scarabeus> herd testers i bet
-21:42  * wired raises hand
-21:42 <@yngwin> evening
-21:42 <@scarabeus> also write mail to desktop and dev
-21:42 <+wired> yngwin: =]
-21:42 <@jmbsvicetto> tampakrap: with kde4 env?
-21:42 <@alexxy> cryos|work: i'll test it with students (avogadro)
-21:42 <+reavertm> btw, masking kdeprefix is good idea for typical users
-21:42  * yngwin completely forgot about the meeting, sry
-21:42 <@tampakrap> i'll prepare a list with the packages and eapi2 as well them
-21:42 <@jmbsvicetto> tampakrap: if so, I can do some tests
-21:42 <@cryos|work> alexxy: Great - I fixed the desktop file among many other things...
-21:42 <@tampakrap> i'm on kde-base only still
-21:42 <@alexxy> reavertm: yep
-21:43 <+reavertm> I guess it should be done when 4.2.2 is introduced
-21:43 <@cryos|work> reavertm: That was always my point - typical users don't want/understand kdeprefix. If they do they will unmask and use.
-21:43 <@alexxy> i think kdeprefix is not for users
-21:43 <@alexxy> =)
-21:43 <@cryos|work> It is awesome for devs/power users though.
-21:43 <+wired> many users activate it without knowing though, mask++
-21:43 <+krytzz> hm... i thought gentoo is for powerusers?
-21:43 <@jmbsvicetto> cryos|work: iirc, kdeprefix is no longer an IUSE default
-21:44 <+reavertm> I want 4.2.2 stable in portage, so let make it easier for users to use
-21:44  * yngwin is with krytzz
-21:44 <@scarabeus> krytzz: you. sent. ssh key. me. now
-21:44 <@cryos|work> jmbsvicetto: I didn't know it ever was.
-21:44 <+reavertm> jmbsvicetto: yeah, but still users see USe flag and enable it out of curiosity :P
-21:44 <+wired> krytzz: the definition of a poweruser is amazingly flexible these days....
-21:44 <+krytzz> scarabeus: ok, few minutes
-21:44 <+krytzz> wired: ok well
-21:44 <@scarabeus> cryos|work: YOU CHANGED IT TO ENABLED BY DEFAULT FIRST :D
-21:44 <@scarabeus> heh caps
-21:45 <@cryos|work> Many Gentoo users are not what I would call power users, but I guess by definition we have more advanced users than *buntu for example..
-21:45 <@cryos|work> scarabeus: For :live only!
-21:45 <+wired> we also have a lot of users who'd want to be powerusers 
-21:45 <@alexxy> he he =)
-21:45 <+wired> =]
-21:45 <@yngwin> i'd say gentoo targets powerusers
-21:46 <@yngwin> doesnt mean all our users are tho
-21:46 <@jmbsvicetto> reavertm: well, that's the same thing as CFLAGS. Gentoo's policy has never been to hide it from the user - even if that leads to user bitting himself in the rear ;)
-21:46 <+krytzz> wired: lol
-21:46 <+reavertm> btw, our existing problems with kdeprefix *only* phonon and pykde
-21:47 <@jmbsvicetto> reavertm: +affect?
-21:47 <@scarabeus> ok back on topic tampakrap are you able to get needed stuff around here or you need our direct intervention (ak more devs searching for testing monkeys?)
-21:47 <+reavertm> jmbsvicetto: hmm?
-21:47 <@tampakrap> no just some testing mostly
-21:48 <@tampakrap> i don't think we should waste more manpower on kde3
-21:48  * wired now that we're all here, can someone pretty please cp the latest .2 tbz2s to d.ge.o?
-21:48 <@jmbsvicetto> reavertm: never mind
-21:48 <+reavertm> ah, right - phonon and pykde4 - the only really kdeprefix *issue*
-21:48 <+reavertm> the rest is just inconvenience
-21:49 <@jmbsvicetto> reavertm: The phonon issue is mostly upstream "hard-coding" the plugins location, right?
-21:49 <@scarabeus> ok so kde3 is moving forward, i would say that we need to have it done by end of april some time on may... so we can actualy stable the kde4
-21:49 <+reavertm> I can easily not drop kdeprefix and install 3rd party apps with kde they were built against (still changing need_kde behaviour)
-21:50 -!- smith_ [n=smith_@adsl-62-167-36-86.adslplus.ch] has joined #gentoo-kde
-21:50 <+reavertm> phonon issue is bunding KDE plugins with phonon
-21:50 <@jmbsvicetto> scarabeus: we need to go for 3.5.10 stable *soon*
-21:50 <@scarabeus> jmbsvicetto: btw i would like to mask the kde
-21:50 <@scarabeus> jmbsvicetto: old nonsplit stuff i mean
-21:50 <+reavertm> hence, phonon should be in location visihble by all KDE releases
-21:50 <@jmbsvicetto> 3.5.9?
-21:50 <+reavertm> or kdeprefixed
-21:51 <@scarabeus> jmbsvicetto: yes
-21:51 <@jmbsvicetto> scarabeus: Not without 3.5.10 stable!
-21:51 -!- mikkoc [n=mikko@host254-81-dynamic.7-79-r.retail.telecomitalia.it] has quit [Read error: 60 (Operation timed out)]
-21:51 <@jmbsvicetto> scarabeus: unless you're the one doing it and I can redirect all bugs, mails, threats, ... to you :P
-21:51 <@yngwin> well, we can leave split 3.5.9 unmasked, and just mask the monolithic pkgs
-21:52 <@jmbsvicetto> yngwin: we could, but we have quite vocal users already complaining about the drop of the monos for 3.5.10
-21:52 <+reavertm> or just put proper blocks
-21:52 <@yngwin> then when 3.5.10 is stable, we can mask the rest
-21:52 <@yngwin> jmbsvicetto: well, too bad, i'd say
-21:52 -!- mikkoc [n=mikko@host182-164-dynamic.56-82-r.retail.telecomitalia.it] has joined #gentoo-kde
-21:52 <@jmbsvicetto> ok
-21:52 <@yngwin> or someone must stand up to become monolithic maintainer
-21:53 <+reavertm> jmbsvicetto: who are those vocal users?
-21:53 -!- anselmolsm_ [n=anselmo@200.184.118.130] has joined #gentoo-kde
-21:53 <+reavertm> devs by occasion?
-21:53 <@jmbsvicetto> reavertm: no
-21:53 <+reavertm> idf so, let them step up to maintain :P
-21:53 -!- anselmolsm [n=anselmo@200.184.118.130] has quit [Read error: 113 (No route to host)]
-21:54 <@jmbsvicetto> reavertm: hehe, wait until you become a dev and you'll see how "demanding" some users can be ;)
-21:54 <+reavertm> and what was basis for their objections?
-21:54 -!- anselmolsm_ is now known as anselmolsm
-21:55 <+reavertm> write migrating guide (if there's no already) and that's all. period
-21:55 <@yngwin> we've had that for years
-21:55 <@scarabeus> yeah i was speaking about the monos
-21:55 <@jmbsvicetto> Some people just want monos. I haven't seen many and in particular good motives. But they want them, nonetheless
-21:55 <+reavertm> Qt4 split was much more difficult yet it was done
-21:55 <+reavertm> jmbsvicetto: I want reiser4 in gentoo-sources and?
-21:55 <@jmbsvicetto> ok, ok
-21:56 <+reavertm> some people want some things and they won't have it nevertheless :P
-21:56 <@yngwin> use hitchhiker-sources then
-21:56 <@jmbsvicetto> When they knock at my door I'll be sure to point them somewhere else ;)
-21:56  * cryos|work has a meeting... Bye!
-21:56 <+krytzz> bye
-21:56 <@jmbsvicetto> bye cryos|work 
-21:56 <+reavertm> jmbsvicetto: let me brainwash them then
-21:56 <+reavertm> bye cryos|work
-21:56 <+wired> bye cryos|work 
-21:56  * cryos|work will try to contribute more this month!
-21:56 <@jmbsvicetto> scarabeus: sorry for the disturbance.
-21:57 <@jmbsvicetto> So, about kdeprefix we're done, right?
-21:57 <@scarabeus> bb
-21:57 <@scarabeus> yes
-21:57 <@scarabeus> kde3 and kdeprefix is done
-21:57 <@jmbsvicetto> about 3.5 tampakrap will do more tests and is searching for people to help with kde-misc apps
-21:57 -!- mx-tvt [n=quassel@bl9-29-140.dsl.telepac.pt] has quit [Read error: 110 (Connection timed out)]
-21:57 <+reavertm> I'll see what i can do - anyway i propose some my changes in eclass anyway as it's much shorter and easier to read now
-21:57 <@jmbsvicetto> scarabeus: What's next?
-21:58 <+reavertm> plasmoids to tree
-21:58 <+reavertm> pros/cons :)
-21:58 <@scarabeus> yeah i think we can start adding them
-21:58 <@scarabeus> we cook them since pre 4.1 and still in the overaly
-21:58 <@scarabeus> so lets make users happy
-21:58 <+reavertm> I haven't tested all of them yet
-21:58 <@jmbsvicetto> They're in kde-misc now, right?
-21:59 <@scarabeus> i will add only those i personaly tested
-21:59 <@yngwin> reavertm: that's what ~arch is for
-21:59 <@yngwin> :p
-21:59 <@scarabeus> jmbsvicetto: yes i did the move, actualy forced wire to move it
-21:59 <+wired> i've tried them all at least once
-21:59 <@jmbsvicetto> scarabeus: In that case I have nothing to say ;)
-21:59 <+reavertm> anyway i already found one problem - systemmontor or sth has been moved to kdeplasma-addons and conflicts with kdeplasma-addons:live
-21:59 <@scarabeus> ok i just want to hear OK :D
-21:59 <+reavertm> about plasmoids
-21:59 <+wired> most of them get regular updates btw and there are a lot more available in kde-look
-21:59 <+reavertm> let me check them 1st
-21:59 <@jmbsvicetto> reavertm: we can add a block on a slot package
-22:00 <+reavertm> I fixed most deps in kde-misc but still something may be wrond there
-22:00 <+wired> i think most plasmoids are simple enough to be safely added to ~
-22:00 <+reavertm> wired applied blocks already
-22:00 <@scarabeus> ok this one was quick
-22:00 <@scarabeus> so we just test them and start moving
-22:00 <@scarabeus> :]
-22:01 <@scarabeus> next is printing
-22:01 <@scarabeus> reavertm: how is it looking
-22:01 <+reavertm> printing..
-22:01 <@jmbsvicetto> scarabeus: what are we missing? The deps?
-22:01 <@scarabeus> jmbsvicetto: we have everything
-22:01 <@scarabeus> jmbsvicetto: the problem is it pulls half of gnome
-22:01 <+reavertm> if I leave it as it is now - system-config-printer-kde is done, printer-applet not yet
-22:01 <+reavertm> scarabeus: no longer
-22:01 <@scarabeus> the better then
-22:02 <@scarabeus> ok so i will coordinate it with you after 4.2.2 is released (weekend probably)
-22:02 <@scarabeus> reavertm: agreed
-22:02 <@scarabeus> ?
-22:02 <+reavertm> just let me finish printer-applet the way I did system-config-printer-kde (taking some files from system-config-printer) and they can go
-22:02 <+reavertm> scarabeus: yeah
-22:03 <@scarabeus> ok cool then
-22:03 <@scarabeus> jmbsvicetto: do we have any response on the snapshot thingie?
-22:03 <+reavertm> I made system-config-printer-kde is totally independent from system-config-printer
-22:03 <@jmbsvicetto> Not that I have seen
-22:03 <@jmbsvicetto> scarabeus: I sent the mail 2 days ago, though.
-22:03 <@alexxy> so they simply ignoring us
-22:03 <@scarabeus> jmbsvicetto: ok so alexxy will have to do it himself for all the time
-22:04 <@jmbsvicetto> scarabeus: I think as cryos|work was suggesting, we ignore them for now and keep doing the work alexxy is doing
-22:04 <@scarabeus> alexxy: btw i heared some noise about l10n not working
-22:04 <@alexxy> scarabeus: its working for -kdeprefix
-22:04 <+reavertm> Dirk was in kde-devel for a minute
-22:04 <@alexxy> didnt test it with +kdeprefix 
-22:04 <@alexxy> =)
-22:04 -!- mkyral [n=maros@nezmar.jabbim.cz] has left #gentoo-kde []
-22:04 <@scarabeus> ok then it is their issue they can fix it
-22:05 -!- sIbOk [i=sNOUbOR@56.Red-80-36-227.staticIP.rima-tde.net] has joined #gentoo-kde
-22:05 <@scarabeus> jmbsvicetto: again one more on you
-22:05 <@scarabeus> jmbsvicetto: how is dead member removing
-22:05 <@scarabeus> going on
-22:05 <@jmbsvicetto> I'm going to go over the retirement bugs (I think a few of them have already retired) and will then send mails to the folks that haven't been around for a long time
-22:06 <@jmbsvicetto> I'll have the page cleaned by next meeting
-22:06 <@scarabeus> ok
-22:07 <@scarabeus> pykde
-22:07 <@scarabeus> bonsaikitten: 
-22:07 <@scarabeus> so you say it works
-22:07 <@scarabeus> despite the bugs in bugzilla
-22:07 <@bonsaikitten> I haven't been able to reproduce
-22:07 <+reavertm> problem with pykde4 is kdeprefix
-22:07 <@bonsaikitten> I guess I'll need to change my testing strategy :)
-22:07 <+reavertm> all kde installs pykde4 in site-packages
-22:07 <@jmbsvicetto> reavertm: build or runtime error?
-22:07 <@alexxy> so lets mask kdeprefix use flag
-22:07 <@alexxy> =)
-22:07 <+reavertm> install
-22:07 <@alexxy> like it was for networkmanager
-22:07 <+reavertm> so - two choices
-22:07 <@scarabeus> there was sip buildtime errors
-22:08 <+reavertm> make eselect module or slot them properly
-22:08 <@jmbsvicetto> reavertm: I have pykde-4.2.1 installed with +kdeprefix here
-22:08 -!- kamik [n=quassel@dslb-088-065-079-200.pools.arcor-ip.net] has joined #gentoo-kde
-22:08 <+reavertm> so that pykde4 live will go to /usr/kde/live and so on
-22:08 <+reavertm> jmbsvicetto: install pykde4-9999 as well
-22:08 <+reavertm> you need package.provided entry now to do it
-22:09 <@jmbsvicetto> reavertm: I'm not running live ebuilds here
-22:09 <+reavertm> well, some people are :)
-22:09 <@jmbsvicetto> sure, I'm just conveying my experience here
-22:09 <@scarabeus> one +kdeprefix is ok
-22:09 <@scarabeus> more than one kdeprefix is fail
-22:09 <@scarabeus> for pykde
-22:09 <@jmbsvicetto> ah, ok
-22:10 <+reavertm> hell, it even install files in /usr/share/sip
-22:10 <+reavertm> (apart from site-packages)
-22:11 <+reavertm> bonsaikitten: some QA  notice says that precompiled modules need to go to site-packages
-22:11 <@bonsaikitten> :(
-22:11 <+reavertm> is it possible to create external site packages in kde slot? (/usr/kde/4.2 etc)
-22:12 <+reavertm> and set some PYTHON_PATH or whatever in startkde?
-22:12 <@jmbsvicetto> This is why having multiple versions around in /usr is going to be "messy" :\
-22:13 <+reavertm> bonsaikitten: what useful python env variables do you know that would help here? :)
-22:13 <@jmbsvicetto> reavertm: perhaps the correct solution here would be to remove the python files and have a single package that is used by all versions?
-22:13 <+reavertm> that is also possible but...
-22:14 <+reavertm> pykde4 happeds to install /usr/kde/live/lib64/kde4/kpythonpluginfactory.so
-22:14 <+reavertm> which is in kdeprefixed location
-22:14 <@jmbsvicetto> if they didn't break abi compatibility, it should be possible to use the latest pykde version with earlier 4.X releases
-22:14 <+reavertm> installing it in /usr prefix is the same thing like installing kde-misc in /usr
-22:15 <+reavertm> (may not work - like this plugin thing I'm struggling with)
-22:16 <+reavertm> yes, I'm not worrying about linking, it should work - still ebuild would need some tweaks to make it build not agains kde release it is from but minimal installed
-22:16 <@jmbsvicetto> reavertm: pkgconfig!!
-22:16 <@scarabeus> he he he
-22:16 <@scarabeus> again prefix you
-22:16 <@scarabeus> SILENCE
-22:16 <@scarabeus> :D
-22:17 <+reavertm> what is pkgconfig going to solve?
-22:17 <@alexxy> lets mask kdeprefix =)
-22:17 <+reavertm> buildig is no longer an issue :P
-22:17 <+reavertm> running is :)
-22:17 <@jmbsvicetto> If they were using autotools they could use pkgconfig to chose the minimum so version needed
-22:18 <+reavertm> jmbsvicetto: ah, eclass does it already 
-22:18 <+reavertm> (picks lowest kdelibs, yet >=KDE_MINIMAL)
-22:18 <@scarabeus> ok i gues we are done with the pykde :P
-22:18 <+reavertm> are we?
-22:18 <@yngwin> hardmask?
-22:18 <+reavertm> what's the solution then :P
-22:18 <@scarabeus> yeah lets kitten handle it
-22:19 <@scarabeus> also write whiny mail on dev
-22:19 <+reavertm> I'd slot the f*er
-22:19 <@jmbsvicetto> scarabeus: hehe - solution? hand it over to Patrick ;)
-22:20 <+reavertm> along with phonon
-22:20 <@scarabeus> jmbsvicetto: yup
-22:20 -!- cypr1nus [n=cypr1nus@plus.ds14.agh.edu.pl] has quit [Read error: 104 (Connection reset by peer)]
-22:20 <@scarabeus> (i am practising my "solid-rock" face)
-22:20 <+reavertm> or ,If I get plugins in /usr to work, it will be solved
-22:20 <@scarabeus> :]
-22:21 <@scarabeus> so, um, what was next, ah, koffice2
-22:21 <@jmbsvicetto> reavertm: I haven't looked at that in a long time, but can't you specify more than 1 RPATH?
-22:21 <@jmbsvicetto> reavertm: more than 1 dir in RPATH
-22:21 <+reavertm> RPATH is not problem, they are all linked well, just app can't find those plugins
-22:21 <@jmbsvicetto> isn't it supposed to look in the compiled RPATH?
-22:22 <+reavertm> I am yet to check some things
-22:22 <+reavertm> for plugins? no
-22:22 <+reavertm> RPATh is just for linker
-22:22 -!- neuron [n=neuron@85.252.65.217] has joined #gentoo-kde
-22:23 -!- Civil [n=Civilian@95-24-156-60.broadband.corbina.ru] has quit [Remote closed the connection]
-22:23 <+reavertm> if plugins are in /usr/kde/XXX/lib64/kde/ and /usr/kde/XXX/lib64/kde/plugins - app needs to know where to find them
-22:24 <+reavertm> (usually just works if app was comopiled against kde XXX and istalled in /usr/kde/XXX
-22:24 <+reavertm> otherwise it fails to find them even when KDEDIRS and QT_PLUGIN_PATh is pointed there
-22:25 <+reavertm> yet I'm to test some things so we'll see - it should work somehow
-22:25 -!- cypr1nus [n=cypr1nus@plus.ds14.agh.edu.pl] has joined #gentoo-kde
-22:25 -!- looonger [n=looonger@host-89-231-128-7.rawamaz.mm.pl] has quit [Client Quit]
-22:25 <+reavertm> I have manually compiled kdevelop in ~/kde4 and my KDEDIRS just points there and it workds
-22:26 <+reavertm> so maybe it's something with building it gentoo way
-22:26 <+reavertm> (I guess I'll try kdeprefix-less kdevelop...)
-22:27 -!- _Phlogi [n=quassel@138-135.1-85.cust.bluewin.ch] has joined #gentoo-kde
-22:27 <+reavertm> ok, what's next?
-22:27 -!- non7top [n=non7top@94.77.134.21] has quit [Remote closed the connection]
-22:27 <@scarabeus> koffice
-22:28 <+reavertm> I built kword and it works
-22:28 <@scarabeus> the state is i fixed the crap
-22:28 <@scarabeus> it works
-22:28 <@scarabeus> problem is that it is not much usable
-22:28 <@scarabeus> they are going to release it at the end of this month
-22:28 <@scarabeus> so i will add it to the tree
-22:28 <+reavertm> 2.0? oh crap
-22:28 <@scarabeus> but i am not sure if it should go masked or not
-22:28 <@scarabeus> 2.0 indeed
-22:29 <+krytzz> released? oh zomg :p
-22:29 <@jmbsvicetto> scarabeus: maybe we should get an rc in the tree first, no?
-22:29 <@scarabeus> jmbsvicetto: ideas?
-22:29 <@scarabeus> well i have the tarball and it is just matter of renaming
-22:29 <@scarabeus> anyone can do it
-22:29 <@jmbsvicetto> scarabeus: the rc could be masked and pending bug reports, 2.0 would be unmasked or not
-22:30 <@jmbsvicetto> The 2.0 tarball?
-22:30 <+reavertm> btw, let someone just in any case look at those ebuilds and see whether deps are correct (rdepend, depend, commondepend handled carefully)
-22:30 <@scarabeus> yeah i am worried about it and in doubts
-22:30 <@scarabeus> it definetly is stable
-22:31 <@scarabeus> but it lacks some features and it looks just ugly
-22:31 <@tampakrap> i like the :live one though
-22:31 <@tampakrap> haven't tested the releases
-22:31 <@tampakrap> maybe we can create snapshots
-22:32 <@scarabeus> what for
-22:32 <@scarabeus> i have todays taged rc1
-22:32 <@scarabeus> :D
-22:32 <@tampakrap> ok then
-22:32 <+reavertm> KOffice 1.9.99.0 RC1 uploaded
-22:32 <@scarabeus> not yet, it is on ktown :]
-22:32 <+reavertm> just pasted announcement
-22:32 <@scarabeus> jmbsvicetto: so what do you thing the stable at the end of the month as pure testing or hardmasked?
-22:33 <@jmbsvicetto> I haven't used koffice myself, so I'm not sure
-22:34 <@jmbsvicetto> But if you're in doubt, try pusing something masked into the tree and check for bug reports
-22:34 <@scarabeus> ok
-22:34 <@scarabeus> good idea
-22:35 -!- Varox [n=Varox@p4FD44E52.dip.t-dialin.net] has joined #gentoo-kde
-22:35 <@scarabeus> last thing on the list:
-22:35 <@scarabeus> moving the meeting date
-22:35 <@scarabeus> i would like to see meeting 14 days before upstream release for public
-22:35 <@jmbsvicetto> pushing*
-22:35 <@jmbsvicetto> scarabeus: releases what? ;)
-22:36 <@tampakrap> we don't have much to talk before release i think
-22:36 <@scarabeus> kde
-22:36 <@scarabeus> we are kde team
-22:36 <@tampakrap> after release is everything that comes in surface
-22:36 -!- sIbOk [i=sNOUbOR@56.Red-80-36-227.staticIP.rima-tde.net] has quit ["kUALKIER hiJO dE pUTA sAbE lO q dARTE sI tIENE q dOLERTE pERO No kUALKIER hiJO dE pUTA sABE lO q dARTE sI tIENE q gUSTARTE, y]
-22:37 -!- helch [n=helch@212-41-103-166.adsl.solnet.ch] has quit [Remote closed the connection]
-22:38 <@scarabeus> hmm
-22:38 <@scarabeus> what does other think?
-22:39 <+krytzz> hm 
-22:39 -!- Phlogi [n=quassel@138-135.1-85.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
-22:40 <+wired> maybe a week is enough?
-22:40 <+krytzz> i would agree with tampakrap i think, but i have nothing against short-dated meetings
-22:40 <@jmbsvicetto> scarabeus: floating schedule or point to 3rd Thursday of the month?
-22:40 <@scarabeus> 3rd thursday i had on my mind
-22:40 <+krytzz> when $PANIC_LEVEL reaches 10 would be good :p
-22:41 <@scarabeus> well or 4th week
-22:41 <@jmbsvicetto> krytzz: Isn't it too late by then? ;)
-22:41 <@scarabeus> the problem is that release is today
-22:41 <+krytzz> k... 9? :p
-22:41 <@jmbsvicetto> scarabeus: 4th will hit council meetings
-22:41 <@scarabeus> ok i will write to summary what ever you decide :]
-22:42 <@jmbsvicetto> I think 3rd would be better, but am open to other dates
-22:42 <@yngwin> 3rd sounds good
-22:43 -!- MaNI [n=malcolm@dsl-247-169-66.telkomadsl.co.za] has joined #gentoo-kde
-22:45 <@scarabeus> ok i go for 3rd too then
-22:45 <@jmbsvicetto> So, what are we missing?
-22:45 <@tampakrap> one last joke
-22:45 <@tampakrap> hwoarang wants me to change my cloak to gentoo/slacker/tampakrap
-22:46 <@scarabeus> hm and you could not write this yesterda
-22:46 <+krytzz> hehe
-22:47 <@alexxy> he he =)
-22:47 -!- g1lt [n=quassel@203-79-94-158.cable.telstraclear.net] has joined #gentoo-kde
-22:48 <@scarabeus> jmbsvicetto: http://dpaste.com/22343/
-22:48 <@scarabeus> jmbsvicetto: again no log, i didnt reboot my client yet :D
-22:48 <@scarabeus> uptime 48 days cant be ruined :D
-22:50 <@jmbsvicetto> hehe
-22:50 <@jmbsvicetto> tampakrap: You have a long road to go before you qualify for that :P
-22:50 <@jmbsvicetto> tampakrap: We have real "slacker" experts around here ;)
-22:50 <@tampakrap> i don't think so, take a look at my cia.vc page
-22:51 <@jmbsvicetto> So are we done?
-22:51 <@tampakrap> yes, where is the summary?
-22:51  * reavertm unpauses music
-22:52 <@jmbsvicetto> In that case, let me remind people that we still have a *few* open bugs and that we should all try to help get that number down
-22:52 <@scarabeus> tampakrap: http://dpaste.com/22343/
-22:52 <@scarabeus> yeah and ehm officaly meeting is over ;]
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090521.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090521.txt
deleted file mode 100644
index c66ea365d1..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090521.txt
+++ /dev/null
@@ -1,1769 +0,0 @@
-22:00 (@alexxy) !time
-22:00 (Willikins) alexxy: Europe - Moscow - Thu May 21 23:00 MSD
-22:00 (@alexxy) heh
-22:00 (@scarabeus) roll-call slackers
-22:00 (+wired) w000t
-22:00 (@alexxy) time to start
-22:00 (@scarabeus) !herd kde
-22:00 (@alexxy) =)
-22:00 (Willikins) (kde) alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, patrick, scarabeus, tampakrap, tgurr
-22:00 (+wired) meh
-22:00 (+wired) hopefully last meeting im not in that list
-22:00 (dagger) huh
-22:00 (+wired) :D
-22:00 (@alexxy) time to start meeting
-22:00 (nirbheek) hurr hurr
-22:00 (@scarabeus) Time to start meting :D
-22:00 (@alexxy) who is here?
-22:00  -> tampakrap
-22:00 (@hwoarang) wait!
-22:00 (nirbheek) Time to start mating!
-22:00 -!- Pesa [n=Pesa@bluemchen.kde.org] joins -> #gentoo-kde
-22:00 (@hwoarang) !herd qt
-22:00 (dagger) alexxy: I'm not here :)
-22:00 (@hwoarang) ladies?
-22:01 (dagger) hwoarang: lol
-22:01 (Willikins) (qt) carlo, hwoarang, tampakrap, yngwin
-22:01 (Gentle) is the libusb blocker ( http://dpaste.com/46414/ ) known? How to best avoid it?
-22:01 (nirbheek) !herd gnome
-22:01 (Willikins) (gnome) dang, eva, ford_prefect, leio, nirbheek, remi
-22:01 (+wired) that list as well
-22:01 (nirbheek) Low attendance, hmmm.
-22:01 (@hwoarang) Pesa: dont hide , come over here
-22:01 (+wired) nirbheek: lolz
-22:01 (Pesa) i'm here, just in time :D
-22:01 (@scarabeus) bonsaikitten: you too, are you around?
-22:01 (@bonsaikitten) no, I'm a square
-22:01 -!- mode/#gentoo-kde [+vvvv papillon81 Phlogi _Phlogi Civil] by scarabeus
-22:01 (@alexxy) bonsaikitten: or you square today?
-22:01 (@bonsaikitten) :)
-22:01 (nirbheek) bonsaikitten, lrn2read vowels
-22:02 (@scarabeus) :D
-22:02 (nirbheek) So, wait, this is it? This is the meeting?
-22:02 (@scarabeus) so we are missing few devs, and importantly our lead
-22:02 (nirbheek) rollcall followed by silence?
-22:02 (+krytzz) im a triforce
-22:03 (cvandonderen) I want to join too! :-D:-P
-22:03 (@alexxy) jmbsvicetto: !!!!!
-22:03 (dagger) should I *stab* him?
-22:03 (+wired) nirbheek: our meetings happen in brainwave levels :P
-22:03 (@hwoarang) yngwin_: !!
-22:03 (+wired) the leads are away
-22:03 (@alexxy) Civil: !
-22:03 (@hwoarang) slacking leaders :D
-22:03 (+wired) maybe they went out for beers
-22:03 (+wired) :D
-22:03 (@alexxy) mine beer is near me
-22:03 (@alexxy) =)
-22:04 (@hwoarang) +1
-22:04 (@scarabeus) mine too :]
-22:04 (@scarabeus) ok
-22:04 (+Civil) alexxy, ?
-22:04 (@hwoarang) o_0
-22:04 (+wired) i see
-22:04 (dagger) I've got tonic with me (no without gin)
-22:04 (@yngwin_) present
-22:04 (@hwoarang) !! YEY!!
-22:04 (+wired) beer meeting this will be
-22:04 -!- yngwin_ is now known as yngwin
-22:04 (+wired) yngwin: :D
-22:04 (spatz) for me? you shouldn't have :p
-22:04  -> papillon81 is here
-22:04  -> Civil is here
-22:04 -!- hwoarang topic of #gentoo-kde ->> Gentoo KDE | meeting 21.5. 19:00 UTC | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU | Beer meeting in
-22:04 (@hwoarang) stupid topic
-22:04 -!- joost_op [n=joost@86.92.194.222] joins -> #gentoo-kde
-22:04 (+wired) hwoarang: you fail it
-22:05  -> nirbheek is here
-22:05 (joost_op) evening
-22:05 (@scarabeus) nirbheek: you want really to be listed on the roll-call?
-22:05 -!- mode/#gentoo-kde [+v spatz] by yngwin
-22:05  -> nirbheek does not know why he is here except maybe for espionage and sabotage
-22:05 (@scarabeus) nirbheek: dont you fear other gnomies would burn you as witch
-22:05  -> reavertm around
-22:05 -!- mode/#gentoo-kde [+v Pesa] by yngwin
-22:05 (nirbheek) scarabeus, they're too busy slacking :p
-22:05 (@scarabeus) ok
-22:05 (@scarabeus) i think better it wont get
-22:05 (@scarabeus) most of us is here
-22:05 (@hwoarang) :D
-22:06 (+wired) yodabeus
-22:06 (@scarabeus) :D
-22:06 (@scarabeus) ok somebody must do the log
-22:06 (+reavertm) nirbheek: we'll talk about some desktop file related stuff that touches gnome as well, so stay here :)
-22:06 (@scarabeus) i still didnt find how todo it on quassel
-22:06 (+wired) i'm logging
-22:06 (@scarabeus) great
-22:06 (@hwoarang) nice
-22:06 (nirbheek) reavertm, kewl
-22:06 (@scarabeus) so anyone has something to the topic list we have on the mail, or we should start right away with it?
-22:07 (cvandonderen) scarabeus: you can just copy-paste it from the backlog
-22:07 (@tampakrap) why not wait 10 minutes for others?
-22:07 (@scarabeus) cvandonderen: not convinient
-22:07  -> papillon81 has got no mail
-22:07 (cvandonderen) scarabeus: we did it last time for a kde.org meeting ;-)
-22:07 (@scarabeus) tampakrap: what others, only boss and cryos is missing
-22:07 -!- Red_Devil [n=red@lounge.datux.nl] <- quit [Read error: 110 (Connection timed out)]
-22:07 (@tampakrap) boss then
-22:07  -> jokey enters spectator mode
-22:08 (nirbheek) jokey, YESH
-22:08 (nirbheek) I finally catch you
-22:08 -!- _Phlogi [n=quassel@38-77.76-83.cust.bluewin.ch] <- quit [Read error: 110 (Connection timed out)]
-22:08 (+reavertm) http://dpaste.com/46416/ - meeting agenda
-22:08 (+papillon81) reavertm: thanks
-22:08 (@scarabeus) http://archives.gentoo.org/gentoo-dev/msg_c5211b31c0fbff058bc767e3ac8ef077.xml
-22:08 (@scarabeus) for those whom dont like pastebins
-22:09 (@yngwin) scarabeus: carlo is missing too
-22:09  -> lxnay sniffs packets from now
-22:09 (@scarabeus) yngwin: he will be allways missing
-22:09 (@yngwin) i know, but i consider this an offence
-22:09 (@scarabeus) well he does not reply to mine mails either
-22:10 (@scarabeus) ok i will write it to summary and let it to jorge to sort out :P
-22:10 (@yngwin) yes please
-22:10 (@hwoarang) no
-22:10 (+reavertm) a'ka "removing dead members" ?
-22:10 (@hwoarang) i ve talked to jorge before 2-3 days
-22:10 (cvandonderen) I could do the kde4 guide....
-22:10 (@hwoarang) he said it is up to qt herd to deal with him
-22:10 (@hwoarang) :)
-22:10 (@yngwin) ok
-22:10 (cvandonderen) I'm new to Gentoo, so I can do it based on experiences encontered
-22:10 (@yngwin) i'll take care of it then
-22:11 (@hwoarang) ok
-22:11  -> cryos|work wife is having a baby in a few weeks - he may not be present for the next few meetings. Sorry!
-22:11 -!- kdeR [n=wired@musici.static.otenet.gr] joins -> #gentoo-kde
-22:11 (@hwoarang) o_0
-22:11 (@hwoarang) new developer :D
-22:11 (@tampakrap) congratulations!
-22:11 (@yngwin) good luck with that
-22:11 (+krytzz) haha
-22:11 (@scarabeus) cryos|work: wow, cool, enjoy the little slacker, be sure you wont be sleeping either :]
-22:11 (@yngwin) :)
-22:12 (+krytzz) yeah congratulations
-22:12 (dagger) cryos|work: grats to you and your mrs dude :)
-22:12 (@hwoarang) \o/ congrats cryos|work :)
-22:12 (@cryos|work) Thanks - expecting lots of ups and downs over the next few months. Today has been hectic...
-22:12 (@cryos|work) US time zone doesn't help me get here either...
-22:12 (+wired) cryos|work: congrats =]
-22:12 (@alexxy) he he =) congratulations cryos|work =)
-22:13 (@jmbsvicetto) Hello
-22:13 (jokey) new dev training++
-22:13 (dagger) yaay jmbsvicetto!
-22:13 (+krytzz) yay chef
-22:13 (+wired) jmbsvicetto: leader!
-22:13 (@hwoarang) :)
-22:13 (+wired) w00t
-22:13 (@jmbsvicetto) Sorry guys, but I just sat down at work. I've been working up until now
-22:13 (@hwoarang) no worries
-22:13 (@hwoarang) i bet we are about to break a record today
-22:13 (@scarabeus) jmbsvicetto: the network magic? :]
-22:14 (lxnay) jmbsvicetto: helloes
-22:14 (@scarabeus) ok i know we all can say hello for next 20 minutes, but lets get started :]
-22:14 (@scarabeus) topic 1; doc handling
-22:14 (@scarabeus) reavertm: anything changed on that subject?
-22:14 (nirbheek) <whew<
-22:15 (@scarabeus) the current state is we have one doc useflag
-22:15 (@scarabeus) and some package install under that user documentation and api documentation
-22:15 (@scarabeus) so we decided to use doc useflag for user documentation
-22:15 -!- Dont_Panic [n=dontpani@adsl-230-54-128.mob.bellsouth.net] joins -> #gentoo-kde
-22:15 (@scarabeus) and for specified packages with api-doc we will create new useflag
-22:15 (nirbheek) mumble, mumble, what about packages that just rebuild the docs?
-22:15 (nirbheek) And unconditionally install docs?
-22:15 (@jmbsvicetto) cryos|work: congrats
-22:15 (@scarabeus) nirbheek: we dont have such :]
-22:16 (+reavertm) I support idea of leaving 'doc' for handbooks and introduce some other useflag when there's apidocs along with use documentation
-22:16 (@cryos|work) Thanks jmbsvicetto :P
-22:16 (@jmbsvicetto) scarabeus: getting ready for that
-22:16 (@scarabeus) reavertm: so we agree on that :]
-22:16 (nirbheek) scarabeus, but hypothetically, if you guys did, what would you do :p
-22:16 (+krytzz) nirbheek slap upstream
-22:16 (@jmbsvicetto) Hi everyone
-22:16 (nirbheek) krytzz, difficult to slap entire gnome :p
-22:16 (joost_op) right now compile kdelibs +doc results in a 268MB vs 48MB package
-22:16 (nirbheek) jmbsvicetto, HELLO.
-22:16 (@scarabeus) so what would be the apidoc useflag
-22:17 (+reavertm) same for kdepimlibs
-22:17 (@scarabeus) api-doc apidoc
-22:17 (@scarabeus) anything else?
-22:17 (@jmbsvicetto) reavertm: By default on Gentoo, user docs should be installed
-22:17 (@scarabeus) suggestions ...
-22:17 (cvandonderen) and will the apidoc useflag only be for kde, or Gentoo-wide?
-22:17 (@scarabeus) jmbsvicetto: they are large
-22:17 (@jmbsvicetto) reavertm: Only api / dev docs / examples should be conditional on use flags
-22:17 (+reavertm) jmbsvicetto: hmm
-22:17 (+wired) we could keep useflag for user docs but + it
-22:17 (+reavertm) well, that's the way as well
-22:18 (@scarabeus) sounds reasonable
-22:18 (@scarabeus) +doc on kde-base
-22:18 (@jmbsvicetto) scarabeus / reavertm: If they are large, they fit with the other docs - thus should depend on a use flag
-22:18 (+reavertm) nirbheek: how do you have it on gnome?
-22:18 (@jmbsvicetto) Gentoo does allow for exceptions ;)
-22:18 (nirbheek) reavertm, we ignore the problem entirely =p
-22:18 (+wired) lolz
-22:18 (@scarabeus) jmbsvicetto: well then lets invent apidoc
-22:18 (@jmbsvicetto) nirbheek: hehe
-22:18 (@scarabeus) jmbsvicetto: docs are handled fine
-22:18 (cvandonderen) and then make it kde-docs or something, because Java installs apidoc with doc too
-22:18 (@scarabeus) but as joost said
-22:18 (@scarabeus) 268 mb vs 48 mb
-22:18 (@jmbsvicetto) scarabeus: what fills those 268MB ?
-22:19 (nirbheek) docsdammitwhatelse
-22:19 (@yngwin) maybe a discussion on dev ml is warranted, about global apidoc useflag
-22:19 (@scarabeus) jmbsvicetto: api documentation
-22:19 (@scarabeus) yngwin: i hate writing on -dev
-22:19 (@scarabeus) yngwin: everything that is not anouncement turns to flame
-22:19 (joost_op) for users having +doc in their make.conf, its not what they wanted
-22:19 (lxnay) scarabeus: ;) true
-22:19 (@yngwin) well, thats the official channel...
-22:19 (+reavertm) if gentoo policy is to install docs by default, maybe we should drop 'doc' useflag for handbooks then
-22:20 (+wired) scarabeus: it works if you just ignore flame[baits]
-22:20 (nirbheek) scarabeus, ignore all replies is the solution
-22:20 (@scarabeus) reavertm: now when it finaly works? ;]
-22:20 -!- Devrethman [i=mpd@D-128-208-118-158.dhcp4.washington.edu] <- quit [Read error: 110 (Connection timed out)]
-22:20 (@scarabeus) reavertm: i would go with +doc
-22:20 (+wired) nah it should be optional, its gentoo
-22:20 (+krytzz) me too scarabeus
-22:20 (+spatz) if doc should be enabled by default then it should be done in the profile
-22:20 (+wired) +doc sounds best
-22:20 (@yngwin) no!
-22:20 (+krytzz) why not
-22:20 (@hwoarang) i dont like +doc
-22:20 (+reavertm) not in profile
-22:20 (@alexxy) heh ; to me seems better to use doc for user docs
-22:20 (dagger) +doc sounds the best. If you want, you can disable it
-22:20 (nirbheek) spatz, that results in too many circular deps
-22:20 (@scarabeus) in kde-base packages
-22:20 (@yngwin) not in profile
-22:20 (+reavertm) better +doc per ebuild
-22:20 (@scarabeus) yes per ebuild
-22:21 (nirbheek) spatz, it's officially unsupported by Gentoo for global enabling
-22:21 (@scarabeus) and the apidoc i will sum up some mail then
-22:21 (@jmbsvicetto) scarabeus: But is it only api documentation or the handbook as well?
-22:21 (+reavertm) jmbsvicetto: we need to distinguish them where they are both
-22:21 (+reavertm) (like in kdelibs)
-22:21 (@scarabeus) jmbsvicetto: +doc for documetnation only
-22:21 (+reavertm) +doc whould be just for handbooks
-22:21 (@scarabeus) jmbsvicetto: apidoc or sth for api doc
-22:21  -> yngwin goes off to set -doc in make.conf
-22:21 (@scarabeus) jmbsvicetto: where we ask on -dev for suggestions
-22:22 (@scarabeus) yngwin: :D
-22:22 (@yngwin) i can use internet thankyouverymuch
-22:22 (dagger) yngwin: how about kde-base/* -doc :)
-22:22 (@jmbsvicetto) ok, let me ask again. I'm not talking about use flags yet. I'm just trying to undestand what type of docs we have and an approximate size
-22:22 -!- Enrico|ITA| [n=quassel@host86-47-dynamic.7-87-r.retail.telecomitalia.it] joins -> #gentoo-kde
-22:22 (@yngwin) dagger: if only portage would support that
-22:22 (@scarabeus) jmbsvicetto: the doc is 5-10megs
-22:22 (@scarabeus) per package
-22:22 (dagger) yngwin: ouch. I though it does
-22:22 (@scarabeus) jmbsvicetto: apidoc is big crap
-22:22 (@jmbsvicetto) yngwin: It does, if you change the order for inheritance ;)
-22:23 (@yngwin) huh?
-22:23 (joost_op) jmbsvicetto, it looks like right now on kdelibs with +doc it generates an insane size on the disc.. for no clear reason..
-22:23 (@jmbsvicetto) scarabeus: So 5-10MB for handbook and possible >100MB for the rest?
-22:23 (@scarabeus) y
-22:23 (@scarabeus) so growth in total about +500meg now
-22:23 (@alexxy) ohh
-22:23 (@alexxy) realy big
-22:23 (dagger) that's quite extensive
-22:23  -> scarabeus already has -doc in use
-22:23 (@jmbsvicetto) yngwin: It's possible to affect the way portage treats the use flags - but I'll leave that for another time
-22:24 (@yngwin) jmbsvicetto: we were talking about wildcard support
-22:24 (@jmbsvicetto) Ah, sorry. I -meant you were talking about -* default use flags
-22:24 (+reavertm) or rather per-category USE flags
-22:24 (@jmbsvicetto) s/-meant/thought/
-22:25 (+reavertm) anyway, we're deviating a bit from the topic
-22:25 (@scarabeus) bit
-22:25 (@jmbsvicetto) scarabeus: In that case, let's talk about it in the dev ml
-22:25 (@scarabeus) ok
-22:25 (@scarabeus) i will sent that mail
-22:25 (+reavertm) so we leave kdelibs alone for now or invent use flag for apidocs?
-22:25 (@scarabeus) reavertm: first -dev
-22:25 (@scarabeus) reavertm: then we will do whole thing
-22:25 (@scarabeus) for now waiting on the mail
-22:26 (+reavertm) it will take forever
-22:26 (@jmbsvicetto) scarabeus: Personally I would suggest we install handbook by default (handbook use flag) and leave the doc use flag for the rest (disabled by default)
-22:26 (@scarabeus) reavertm: i give them 7 days
-22:26 (+reavertm) we can rename USE flag anytime
-22:26 (+reavertm) (and play with it in overlay)
-22:26 (@scarabeus) pple would tear us apart :D
-22:26 (@scarabeus) if we move back to handbook D:
-22:26 (+wired) lol
-22:26 (+reavertm) pple can kill our asses - who does the work - decides
-22:26 (@alexxy) he he =)
-22:26 (@jmbsvicetto) scarabeus: +handbook for user docs ;)
-22:26 (@alexxy) someone would forced to rebuild whole kde
-22:26 (nirbheek) ouch
-22:26 (joost_op) yeah it makes more sense..
-22:26 (+reavertm) jmbsvicetto: +handbook or +doc?
-22:27 (joost_op) (o;
-22:27 (@jmbsvicetto) My proposal would be +handbook for handbook and doc for the rest
-22:27 (+wired) alexxy: doesn't portage profile/updates cover user flag changes?
-22:27 (@scarabeus) --newuse
-22:27 (+reavertm) (I'd like to rename +100 ebuilds and eclass)
-22:27 (@jmbsvicetto) reavertm: meaning eapi docs
-22:27 (@scarabeus) pple would hate us
-22:27 (joost_op) since +doc right now generates the handbook
-22:27 (+wired) use*
-22:27 (@jmbsvicetto) s/eapi/api/
-22:27 (joost_op) keeping kdelibs out of it
-22:27 (@alexxy) wired: no =)
-22:27 (+reavertm) (i mena I woundn't lke to rename so many use flags...)
-22:28 (@jmbsvicetto) We can do any changes in the use flags for 4.3
-22:28 (Kuja^) wired: it only handles package renames afaik
-22:28 (+wired) meh
-22:28 -!- BarbieGentoo-er is now known as Tina-
-22:28 (@scarabeus) i agree with reaver, we need some test suicider who will do it, with apidoc we have 2 packages to change
-22:28 -!- jmbsvicetto topic of #gentoo-kde ->> Gentoo KDE | meeting: Now | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
-22:29 (@scarabeus) with handbook we have to touch all
-22:29 (@jmbsvicetto) scarabeus: The handbook should be dealt with in the eclasses, imo
-22:29 (@scarabeus) jmbsvicetto: ok but it will be todo for 4.3
-22:29 (+reavertm) it's already dealt there, but ebuilds need to fixed as well
-22:29 (@jmbsvicetto) scarabeus: that's my opinion
-22:29 (@scarabeus) or 4.4
-22:29 (@scarabeus) :D
-22:30 (@jmbsvicetto) scarabeus: But you don't have to agree with me ;)
-22:30 (joost_op) i'd address it to 4.4
-22:30 (joost_op) but thats just my ho
-22:30 (@scarabeus) well i am just lazy, cause it is annoying work
-22:30 -!- ehustad [n=espen@ti511220a080-1003.bb.online.no] joins -> #gentoo-kde
-22:30 (@scarabeus) go throught all ebuilds and manualy check them
-22:30 (@scarabeus) there is 250 of them
-22:30 (@scarabeus) and pple still commit to them
-22:30 (@scarabeus) so merge failitures
-22:30 (@scarabeus) AAGHR
-22:30 (dagger) scarabeus: make it 40 each :)
-22:31 -!- UT2K3 [n=UT2K3@one.lanrena.ilk.de] joins -> #gentoo-kde
-22:31  -> lxnay can do annoying work
-22:31 (@scarabeus) lxnay: you are realy willing to do it?
-22:32  -> lxnay hides
-22:32 (lxnay) ;)
-22:32 (lxnay) well we can talk about it
-22:32 (@scarabeus) as you wish
-22:32 (joost_op) lxnay, hahaha leave it to scarabeus
-22:32 (lxnay) but sure
-22:32 (joost_op) we have enough todo
-22:32 (lxnay) i can help out
-22:32  -> joost_op grins
-22:32 (@scarabeus) :]
-22:32 (@scarabeus) :D
-22:32 (+reavertm) I'd like to see how it's handled elsewhere 1st
-22:32 (@scarabeus) reavertm: by elsewhere you mean?
-22:33 (UT2K3) hi guys i upgraded to kde-4.3 and now the most icons are missing
-22:33 (@jmbsvicetto) ok, so we'll use the dev ml to discuss the split between the documentation and the use flags for it. Anyone objects?
-22:33 (@jmbsvicetto) UT2K3: We're in the middle of a meeting, please leave it for after the meeting
-22:33 (UT2K3) ok
-22:33 (lxnay) anything that falls into split attracts me, split and reign
-22:34 (+reavertm) elsewhere, gnome (nirbheek by ignoring problem you mean installing everything provided by autoconf not caring whether docs are there or not?), openoffice, whatever
-22:34 (nirbheek) reavertm, yeah, pretty much
-22:34 (@scarabeus) reavertm: mostly they dont care
-22:34 (nirbheek) the doc use-flag on gnome packages rebuilds the docs
-22:34 (nirbheek) But even that's inconsistent for a few packages
-22:35 (nirbheek) (some packages don't use gtk-doc)
-22:35 (nirbheek) Oh, and these are api docs :p
-22:35 (nirbheek) ls /usr/share/gtk-doc/html
-22:35 (@jmbsvicetto) hmm, so do we want to move that discussion to the dev ml?
-22:36  -> jmbsvicetto looks at the clock
-22:36 (@scarabeus) jmbsvicetto: jup
-22:36 (+reavertm) anyway if 'doc' is for developer documentation, we need new USE flag for handbooks
-22:36 (@scarabeus) end of this topic :]
-22:36 (@jmbsvicetto) ;)
-22:36 (@jmbsvicetto) KDE3?
-22:36 (@scarabeus) that was FUBAR
-22:36 (@scarabeus) total one
-22:36 (@scarabeus) when we moved it to the tree
-22:36 (@scarabeus) many things broke
-22:36 -!- jmbsvicetto topic of #gentoo-kde ->> Gentoo KDE | meeting: Now - KDE3 | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
-22:37 (@scarabeus) even now it is not finished
-22:37 (@tampakrap) not exactly
-22:37 (+Pesa) please try to avoid the gtk-doc mess ;)
-22:37 (@tampakrap) we knew from the beginning that were was going to be a mess with kde3 misc apps
-22:37 (@jmbsvicetto) Well, we also have gcc-4.4 and glibc-2.10 joining the *fun*
-22:37 (Mirrakor) :)
-22:37 (+reavertm) kde3, well, the state is kdelibs is hacked to replace some entries of .desktop files on the fly to make kde4 apps (even those from kdeprefix) distinguished (and runnable)
-22:37 (+wired) btw kdelibs3 -r6 just failed on me
-22:37 (+reavertm) but...
-22:38 (+wired) probably due to glibc or gcc =]
-22:38 -!- cvandonderen [n=casper@212-182-159-91.ip.telfort.nl] <- quit ["leaving"]
-22:38 (+wired) kde3 session lists all -kdeprefix kde4 apps in menu now properly
-22:38 (@jmbsvicetto) Just a quick point, I think we should open a tracker bug about gcc-4.4 and another about glibc-2.10 breakages with KDE apps
-22:38 (@alexxy) yep =) i use gcc 4.4 and new glibc
-22:38 (+reavertm) the problem is - not all kde4 executables want to work within kde3 (or any non kde4) session
-22:39 (@scarabeus) reavertm: i think that pple will have to live with it
-22:39 (+wired) reavertm: actually all kde4 apps i tested worked in kde3 session
-22:39 (+wired) reavertm: always -kdeprefix
-22:39 (@scarabeus) with +kdeprefix i know it is evil
-22:39 (+reavertm) wired: install 4.2 in kdeprefix and live in kdeprefix as well (so you have two kde4 releases in kdepredfx) and install kde3
-22:39 (@scarabeus) but it wont work correctly so i think kde3 should not see it at all
-22:39 (+wired) kdeprefix isn't supported atm
-22:39 (+reavertm) troubles start there
-22:40 (+wired) the patch doesn't even care
-22:40 (@scarabeus) and we should focus on making the kde3 misc apps revbumped and stabled
-22:40 (+reavertm) wired: looked at my patch?
-22:40 (+reavertm) my patch does care :)
-22:40 (@scarabeus) reavertm: i know you patched it, simple, just revert it
-22:40 (+wired) haven't seen your patch
-22:40 (+krytzz) i think who uses kde3 and kdeprefix doesnt deserve better :p
-22:40 (+reavertm) well, it works with -kdeprefix as well
-22:40 (@scarabeus) one +kdeprefix version never saw other +kdeprefix one
-22:40 (@scarabeus) so...
-22:40 -!- UT2K3 [n=UT2K3@one.lanrena.ilk.de] <- quit ["Bambus> frei nach dem motto: was ist besser als 14? 2 x 7 :o"]
-22:40 (+wired) reavertm: does it work or not then?
-22:40 (+reavertm) the point is - there's other approach
-22:41 -!- ehustad_ [n=espen@ti511220a080-1003.bb.online.no] <- quit [Read error: 110 (Connection timed out)]
-22:41 (+reavertm) wired: patch works, but just replacing those is not sufficient to run kde4 apps  (kde 4.2 apps) within kde3
-22:41 (+wired) well no
-22:41 (+reavertm) they try to load oxygen theme from live kde
-22:41 (+wired) kde4 kdeprefix apps will need a wrapper script
-22:41 (+reavertm) that's issue that needs to be resolved
-22:41 (+wired) just as kde3 apps need kde3 wrapper script in kde4
-22:41 (+reavertm) that's stupid anyway
-22:42 (+reavertm) let me check wrapper
-22:42 (+papillon81) what is the main issue behind the kde3 topic that needs to be discussed here?
-22:43 (+wired) having all stuff available in all menus
-22:43 (+papillon81) k
-22:43 (@tampakrap) ok apart from that
-22:43 (+reavertm) wrapper doesn't fix this
-22:43 (+reavertm) so anyway
-22:43 (+reavertm) new idea is to modify .desktop files directly
-22:43 (@tampakrap) i started opening stabilization bugs for various kde3 apps
-22:44 (+reavertm) substitute paths with absolute ones, add suffixes to names to make it distinguished etc
-22:44 (@tampakrap) i think monolithics can be masked and 3.5.10 can go to stabilization since 3.5.9 is dead
-22:44 (@yngwin) ah that reminds me, are we deprecating arts as per bug 270575 ?
-22:44 (Willikins) yngwin: https://bugs.gentoo.org/270575 "Dropping USE="arts" and USE="esd""; Gentoo Linux, Applications; NEW; ssuominen@g.o:qa@g.o
-22:44 (+reavertm) i alrady started working on desktop-file-edit util (in desktop-file-utils, maybe it will be added there sometime)
-22:44 (@scarabeus) we should
-22:45 (@hwoarang) at last :)
-22:45 (@yngwin) i think we can just remove arts support in 3.5.10
-22:45 (@scarabeus) yup that would be smart
-22:45 (@tampakrap) can arts be safely disabled? it needs testing
-22:45 (@scarabeus) remove arts support in 3.5.10
-22:45 (@yngwin) but we should check stable tree for packages requiring arts, if any
-22:45 (@scarabeus) tampakrap: actualy more breakages is arts enabled
-22:45 (+reavertm) nirbheek: you're not going to hack .desktop files loader in gnome to make kde4 apps (from multiple prefixes) not seen as duplicates?
-22:45 (@scarabeus) tampakrap: it is more question, can we affort supporting arts
-22:45 (+papillon81) lol
-22:46 (@bonsaikitten) kill it with fire
-22:46 (@bonsaikitten) then kill it again until it is dead
-22:46 -!- gengor|lunch is now known as gengor
-22:46 (+wired) lol
-22:46  -> papillon81 has arts disabled since ages
-22:46 (nirbheek) reavertm, why should they not be shown as duplicates?
-22:47 (nirbheek) (I'm unfamliar with exactly how kde4 prefixes work)
-22:47 (+reavertm) if you have kde4.2 in /usr/kde/4.2 and /usr/kde/live - you'll get two identical "Text editor" icons lanching same app
-22:47 (+reavertm) (the one that is 1rst in PATH
-22:48 (@yngwin) kde4 installs vim?
-22:48 (@hwoarang) lol :P
-22:48 (@yngwin) "text editor" ...
-22:48 (+reavertm) kwrite
-22:48 (nirbheek) reavertm, I'm confused, how can two paths in PATH cause duplicate .desktops?
-22:48 (Enrico|ITA|) yngwin: kde4 rocks, vim rocks so they pull in each other :D
-22:48 -!- jkt| [n=jkt@gentoo/developer/jkt] <- quit [Read error: 60 (Operation timed out)]
-22:49 (@scarabeus) reavertm: i still think it is just wasting time
-22:49 (@scarabeus) reavertm: just forget about some +kdeprefix
-22:49 (@scarabeus) and problem is solved
-22:49 (@scarabeus) really
-22:49 (@scarabeus) we need it stable
-22:49 (@scarabeus) for stabling kde4
-22:49 (@yngwin) yeah, dont make it more complicated than necessary
-22:49 (@scarabeus) then it will be done in 7 months
-22:49 (@scarabeus) s/done/gone
-22:49 (+reavertm) then there's no point in exporting XDG_DATA_DIRS for kdeprefixed installs
-22:49 (nirbheek) Oh, I see
-22:49 (nirbheek) _that_ way
-22:49 (@alexxy) scarabeus: thats why i suggest to mask kdeprefix from regular users
-22:50 (@yngwin) i think once kde4 is in stable, there will be few kde3 users
-22:50 (nirbheek) reavertm, yes, plz2don't export prefixed installs (except for default prefix?)
-22:50 (+papillon81) also think about the issue with networkmanager-applet concerning different paths
-22:50 (@scarabeus) papillon81: later later
-22:50 (@scarabeus) now we are on kde3
-22:50 (@scarabeus) :]
-22:50 (+reavertm) but it can be done :P
-22:50 (@scarabeus) reavertm: can and must are 2 things
-22:50 (@scarabeus) reavertm: and we have other things we need to have done
-22:50 (@scarabeus) which are actualy more important than this
-22:51 (+wired) if user has kdeprefix
-22:51 (nirbheek) You guys have too much time and manpower :p
-22:51 (+wired) we should just export
-22:51 (@scarabeus) if user has kdeprefix, we dont bother with kde3
-22:51 (+wired) the ... higehr version one maybe?
-22:51 -!- Sho_ [n=EHS1@kde/hein] <- quit [Read error: 104 (Connection reset by peer)]
-22:51 (+wired) in XDG_DATA_DIRS
-22:51 (+reavertm) there is a bug already - "kde4 apps not shown in gnome" or whatever
-22:51 -!- Sho_ [n=EHS1@kde/hein] joins -> #gentoo-kde
-22:51 (@scarabeus) reavertm: yep that is other thing, and that can be handled by, newest ap win
-22:51 (+reavertm) (or the other way around?)
-22:52 (@scarabeus) kde4 apps in gnome
-22:52 (+wired) if user has -kdeprefix installed, only that one shows in other DEs, if he has only +kdeprefix then grab newer version (or stabler, whatever)
-22:52 (@scarabeus) yep
-22:52 (@scarabeus) but dont bother with it on kde3
-22:52 (@jmbsvicetto) tampakrap: we can't mask 3.5.9 monos until we get 3.5.10 marked stable
-22:52 (@hwoarang) afaik there was another situation that kde3 apps didnt show on kde4 session
-22:52 (+reavertm) what you have just written - how exactly are you going to implement?
-22:53 (+reavertm) espeically "if he has only +kdeprefix then grab newer version (or stabler, whatever)" part
-22:53 (@jmbsvicetto) tampakrap: That would cause issues for stable users
-22:54 (+wired) reavertm: check in /etc/env.d/... ?
-22:55 (@scarabeus) ok for kde3 i have two things
-22:55 (@scarabeus) - kill arts, all misc apps needs it removed and be stabled before 3.5.10 stabling
-22:55 (@scarabeus) - stable 3.5.10, all kde related misc apps needs to be revbumped/verbumped and stabled before it
-22:55 (@scarabeus) anything to this
-22:55 (@alexxy) jmbsvicetto: thats why i think its better to mask kdeprefix use flag to not confuse stable users at all
-22:55 -!- jkt| [n=jkt@basa.flaska.net] joins -> #gentoo-kde
-22:55 (@tampakrap) kde3 misc apps is up to me
-22:55 (+reavertm) making kdeprefix is differnt topic :)
-22:55 (@yngwin) i'd agree with masking kdeprefix useflag
-22:55 (+wired) actually i agree with alexxy it should be masked
-22:56 (+krytzz) me too ^^
-22:56 (@jmbsvicetto) alexxy: Unmasking a use flag is not something we should ask our users to do
-22:56 (@scarabeus) reavertm: i think we will talk about it on the bug
-22:56 (@tampakrap) i want someone to stable 3.5.10, i don't know the procedure for a list of packages
-22:56 (@jmbsvicetto) alexxy: We already have it disabled by default
-22:56 (+wired) too many users use +kdeprefix without knowing wth it is
-22:56 (+wired) ohhh look shiny use flag
-22:56 (@alexxy) jmbsvicetto: kdeprefix is topper to make kde 4.2 stabel
-22:56 (@hwoarang) wired is right actually :)
-22:56 (@scarabeus) jmbsvicetto: i dont mind having unmasked kdeprefix, when the kdeprefix issues are fixed
-22:56 (@alexxy) jmbsvicetto: users can think that they want to have kde in /usr/kde/<version> and use kdeprefix
-22:56 (@scarabeus) and users install it "by accident"
-22:57 (@jmbsvicetto) wired: Gentoo is not a distro for "not smart" users
-22:57 (+wired) jmbsvicetto: im with you 100%
-22:57 (+wired) the users aint
-22:57 (@jmbsvicetto) wired: We don't want to become Ubuntu ;)
-22:57 (@alexxy) but it will cause troubles if they hav kde3 for example
-22:57 (nirbheek) jmbsvicetto, Hey, you just Godwinned the conversation :p
-22:57 (@yngwin) ok, maybe add an ewarn then
-22:57 (+wired) there seems to be some general confusion regarding it
-22:57 (+wired) maybe it needs to be documented better
-22:57 -!- _Phlogi [n=quassel@168-18.77-83.cust.bluewin.ch] joins -> #gentoo-kde
-22:57 (+reavertm) great, then I need volunteer to fix one bug - the one with picking live oxygen by kde 4.2 apps (both installed in kdeprefix)
-22:58 (+reavertm) after that - I can call kdeprefix supported
-22:58 (+reavertm) volunteers?
-22:58 (+reavertm) if no - mask kdeprefix :P
-22:58 (joost_op) we will have -kdeprefix in our next branch for sure
-22:58 -!- bschindler [n=quassel@77-56-156-71.dclient.hispeed.ch] joins -> #gentoo-kde
-22:58 (@jmbsvicetto) Let's improve our docs and make it *very* clear that users shouldn't enable kdeprefix unless they're ready to assume the support for their install
-22:58 (joost_op) if it helps
-22:58 (@scarabeus) jmbsvicetto: also evarn is not bad idea
-22:58 (@scarabeus) ewarn
-22:58 (@jmbsvicetto) No problem with that
-22:58 (+wired) jmbsvicetto++
-22:58 (@scarabeus) something like I_KNOW_WHAT_I_AM_DOING variable
-22:59 (+wired) and ewarn should be there as well
-22:59 -!- Eythan [n=Eythan@AMontpellier-552-1-118-57.w86-197.abo.wanadoo.fr] <- quit ["Leaving"]
-22:59 (+krytzz) yeah this one is great
-22:59 (nirbheek) Why not just globally use.mask it?
-22:59 (@jmbsvicetto) Although you all know just how much ewarns users tend to pay attention to
-22:59 (nirbheek) People who want to use it can enable it
-22:59 (@jmbsvicetto) scarabeus: no
-22:59 (@yngwin) not another variable, then it'd be better just to mask the useflag
-22:59 (+wired) also many users think kdeprefix is needed for kde3/kde4, we need to tell them thats no longer the case
-22:59 (+reavertm) what's wrong with masking it until kdeprefix issues are fixed?
-22:59 (dagger) nirbheek: global use.mask should be for stuff which is know to be broken.
-23:00 (+reavertm) actually kdeprefix IS KNOWN to be broken :P
-23:00 (@scarabeus) jmbsvicetto: i mean like live warning is handled
-23:00 (@yngwin) well, it *is* known to break things
-23:00 (nirbheek) dagger, isn't this known to be broken? :p
-23:00 (@jmbsvicetto) reavertm: I use it here :P
-23:00 (@scarabeus) jmbsvicetto: i just expresed myself poorly
-23:00 (@scarabeus) jmbsvicetto: broken ktorrent..
-23:00 (+reavertm) it is broken when used with non-kde4 sessions . period
-23:00 (dagger) is it broken for all installs? If you just use one kde (4.2) and no other version?
-23:00 (@jmbsvicetto) scarabeus: I don't think we should require users to set a new use flag or to have to digg how to unmask use flags
-23:00 (@scarabeus) jmbsvicetto: broken misc plasmoids...
-23:00 (@scarabeus) jmbsvicetto: no useflag
-23:00 (@alexxy) reavertm: if its known to be broken then it should be masked by default
-23:00 (@alexxy) from regular users
-23:01 (@scarabeus) jmbsvicetto: like the warning it is doing in live
-23:01 (@jmbsvicetto) reavertm: You're talking about mixing kde versions or using other DEs
-23:01 (nirbheek) dagger, then it's of no use, right? (if you only have one)
-23:01 (@alexxy) people who want to play with it smart enough to unmask it
-23:01 (+reavertm) both
-23:01 (+reavertm) using other DEs with multiple KDE4's installed
-23:01 (dagger) nirbheek: but I might like to have it in /usr/kde/4.2 location
-23:02 (+reavertm) jmbsvicetto: ^
-23:02 -!- mode/#gentoo-kde [+v Kuja^] by scarabeus
-23:02 (nirbheek) dagger, then why not make it default? :p
-23:02 (dagger) use.mask unmasking is not documented and should not be used really
-23:02 (nirbheek) kdeprefix is not documented, and should noe be used really (unless you know what you're doing)
-23:02 (@tampakrap) kdeprefix is documented
-23:02 (+reavertm) what else. use.force?
-23:03 (+reavertm) (and it be overriden in /etc somewhere?)
-23:03 -!- ELITE_x [n=quassel@quassel/user/elite] <- quit [Remote closed the connection]
-23:03 (nirbheek) tampakrap, yeah, and my code is documented ;p
-23:03 (@scarabeus) ok you guys are way of topic :}
-23:03 (@scarabeus) we are suposed to talk about kde3
-23:04 (@scarabeus) so for now we have revbumping all misc packages and removing arts
-23:04 (@jmbsvicetto) So let's focus again on KDE3
-23:04 (@scarabeus) anything else onto that topic?
-23:04 (@tampakrap) yes
-23:04 (@tampakrap) let me talk for a minute
-23:04 (@yngwin) well, this kdeprefix mess should be decided before stabling 3.5.10
-23:04 (@jmbsvicetto) scarabeus: I don't think it's worthy to worry about arts, but if those working on KDE3 want to drop it now, I don't have a problem with it
-23:04 (@scarabeus) jmbsvicetto: it is not working, again ton of bugs open
-23:04 (@tampakrap) the original idea behind hacking kde3 eclasses was to have mostly a kde4 session with kde3 apps working
-23:04 (@scarabeus) jmbsvicetto: so if we kill it we smash bugs
-23:05 (@jmbsvicetto) scarabeus: well, it isn't a regression ;)
-23:05 (@tampakrap) especially those that aren't still ready for kde4
-23:05 (@alexxy) kde3 works perfectly without arts
-23:05 (@alexxy) =)
-23:05 (@tampakrap) this issue is fixed, if wired and reavertm want to play more it is their issue, the stabilizattion can be proceeded normally
-23:05 (@tampakrap) and i'm going to document it
-23:05 (@tampakrap) objections?
-23:05 (+reavertm) nope
-23:06 (+reavertm) we can add some blocker anytime
-23:06 (+reavertm) (if needed)
-23:06 (@tampakrap) also
-23:06 (@jmbsvicetto) tampakrap: I agree with that
-23:06 (@yngwin) as long as kdeprefix is properly documented
-23:06 (@tampakrap) the mess created in kde misc apps was expected, so nothing is fucked
-23:06 (wilder_) hiall, qt-4.5.1 in portage does not contain   http://websvn.kde.org/trunk/qt-copy/patches/0279-svg-rendering-regression.diff
-23:06 (@tampakrap) we new from the beginning that most of them should be rebuilt to work and i am trying to revbump and stabilize the most popular ones
-23:07 (@tampakrap) and close random bugs
-23:07 (wilder_) ?
-23:07 (@jmbsvicetto) tampakrap: At this point, I think we should have 2 goals with KDE3: working environment to those still resisting KDE4 and working KDE3 apps inside a KDE4 session
-23:07 (@hwoarang) wilder_: it does. but we have a meeting now
-23:07 (+krytzz) wilder_ please later, we are in a meeting currently
-23:07 (@tampakrap) jmbsvicetto: both those work
-23:07 (@scarabeus) so we can stable
-23:07 (@scarabeus) goodie
-23:07 (wilder_) sry
-23:07 (+krytzz) np
-23:07 (@jmbsvicetto) tampakrap: right, but we should be explicit that is what we'll support for KDE3
-23:08 (@jmbsvicetto) tampakrap: So people know what we're doing and what we're willing to support
-23:08 (@tampakrap) i can document that
-23:08 (+reavertm) if we disable XDG_DATA_DIRS for kdeprefixed kde4's - current kdelibs patch is sufficient
-23:08 (+reavertm) (for kde3)
-23:08 (@tampakrap) and also propose things to users so as to have a fully working kde4 env
-23:09 (+reavertm) so only remaining issue is to fix kde4 session (kdelibs .desktop files loader) the same way as kdelibs3 one
-23:09 (+reavertm) (I can do it)
-23:09 (@tampakrap) not a major one but feel free
-23:09 (@jmbsvicetto) I also propose we make it clear that upstream stopped working on KDE almost 1 year ago and doesn't show much concern about it anymore
-23:09 (+reavertm) (a'ka fixing kde3 apps in kde4)
-23:09 (@tampakrap) the major issue is to have them working, i don't care much if they aren't listed in kmenu :)
-23:09 (@jmbsvicetto) So people worried about security should start thinking about upgrading
-23:10 (+wired) actually them showing up is important
-23:10 (@tampakrap) ok i'll prepare a new document about kde3 and kde3/4
-23:10 (@jmbsvicetto) That's another reason we need to press for KDE4 going stable
-23:10 (+wired) so that patch reavertm is talking about is needed
-23:10 (+reavertm) tampakrap: it will make them work - they need no special care apart from appending fullpath to executable
-23:10 -!- pgega [n=pgega@tonbridgesecpay.force9.co.uk] <- quit [Remote closed the connection]
-23:10 -!- Phlogi [n=quassel@24-167.77-83.cust.bluewin.ch] <- quit [Read error: 110 (Connection timed out)]
-23:10 (@tampakrap) reavertm: feel free to do it no problem by me
-23:11 (@scarabeus) ok i would say important things about kde3 are done
-23:11 (@scarabeus) what is next...
-23:11 (@scarabeus) KDE 4.3
-23:11 (@jmbsvicetto) tampakrap: So, should we try to define a timeline for 3.5.10?
-23:11 (@scarabeus) oh
-23:11 (@jmbsvicetto) scarabeus: just one sec
-23:11 (@scarabeus) deadline?
-23:11 (@tampakrap) what deadline? i can open the bug even now, the things i wanted to work are ready
-23:12 (@tampakrap) i don't know from the open bugs view if this is possible
-23:12 (@jmbsvicetto) ok
-23:12 (@scarabeus) ok so lets say 15.6 is last day when we cc archies?
-23:12 (@tampakrap) ok we have the kde3 thing settled
-23:12 (@jmbsvicetto) So we'll open a stabilization bug for 3.5.10 asap?
-23:13 (@tampakrap) yes ok
-23:13 (@jmbsvicetto) Good :)
-23:13 (@tampakrap) scarabeus: paste the summary so everyone can see it
-23:13 -!- jmbsvicetto topic of #gentoo-kde ->> Gentoo KDE | meeting: Now - KDE4.3 | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
-23:13 (@hwoarang) http://archives.gentoo.org/gentoo-dev/msg_c5211b31c0fbff058bc767e3ac8ef077.xml
-23:13 (@scarabeus) tampakrap: it is mess
-23:13 (@scarabeus) tampakrap: i need to polish it later
-23:13 (@scarabeus) dont worry summary will be
-23:13 (@tampakrap) ok
-23:13 (@tampakrap) next topic
-23:13 (@scarabeus) libknotification is done
-23:13 (+krytzz) ok for 4.3, i dont know for sure but i think the libnotification stuff is being merged into kdelibs later
-23:13 (@scarabeus) it is pdepend in kdelibs
-23:14 (@scarabeus) it will be merged in 4.4
-23:14 (+krytzz) ah ok
-23:14 (@scarabeus) so for now it is best solution
-23:14 (@scarabeus) also i dont get upstream
-23:14 (@scarabeus) seriously
-23:14 (@scarabeus) the lib is needed in half core packages
-23:14 (@scarabeus) and they didnt add it
-23:14 (@scarabeus) insane
-23:14 (+wired) yes well
-23:14 (@alexxy) yep
-23:14  -> jmbsvicetto whistles
-23:14 (+wired) at first they had it in extra gear
-23:14 (+reavertm) abi/api changes probably
-23:14 (+wired) LOLZ
-23:14 (+wired) :p
-23:14 (+reavertm) they wanted to workaround feature freeze :P
-23:14 (+reavertm) simly
-23:15 (+reavertm) so they invented "experimental" thing
-23:15 (@alexxy) ohh
-23:15 (@scarabeus) ok
-23:15 (@scarabeus) what else we have for kde4.3
-23:15 (@alexxy) some additional deps
-23:15 (@alexxy) like wicd
-23:15 (@tampakrap) kopete will have facebook support :)
-23:15 (+reavertm) and phonon
-23:15 (@hwoarang) LOOOOLZ
-23:15 (@alexxy) yep
-23:16 (@alexxy) also non released phonon as dep
-23:16 (+krytzz) well virtuoso isnt stable as trueg wrote
-23:16 (@scarabeus) krytzz: it is not mandatory for 4.3
-23:16 (@scarabeus) :}
-23:16 (+reavertm) or maybe we pull mplayer with mplayerthumbs?
-23:16 (+reavertm) (it's pretty heavy dep)
-23:16 (dagger) what's the status of policykit with 4.3? Do we need some extra docs?
-23:16 (+krytzz) yes
-23:16 (@scarabeus) ah
-23:16 (@scarabeus) docs
-23:16 (+krytzz) reavertm how do other package handle such deps?
-23:16 (@scarabeus) definetly
-23:16 (@alexxy) well
-23:16 (+reavertm) (that's why I opted for making phonon snapshot evem if I use mplayer myself)
-23:17 (@alexxy) policy kit used to control some privilegies like suspend/resume
-23:17 (+reavertm) krytzz: you mean other distros?
-23:17 (@yngwin) when is kde going to use qt's phonon?
-23:17 (+reavertm) or whether it's compatible?
-23:17 (+krytzz) reavertm no, i mean other packages who just call another binary
-23:17 (@scarabeus) yngwin: hopefully with 4.6
-23:17 (+reavertm) yngwin: for us? never
-23:17 (@scarabeus) yngwin: but we can just hope
-23:17 (@yngwin) ok
-23:17 (+reavertm) unless we package xine backend separately
-23:18 -!- Pesa [n=Pesa@bluemchen.kde.org] <- leaves #gentoo-kde []
-23:18 (+reavertm) (btw, policykit panel crashes in kde trunk, anyone can confirm?)
-23:18 (@scarabeus) reavertm: ok we will ship phonon snapshot
-23:18 (@hwoarang) is this possible? does it worth the pain?
-23:19 (@scarabeus) hwoarang: worth it is
-23:19 (@scarabeus) because we wont have the blocker bugs
-23:19 (+reavertm) pain it is not
-23:19 (@hwoarang) ok then this sounds great !
-23:19 -!- Pesa [n=Pesa@bluemchen.kde.org] joins -> #gentoo-kde
-23:19 (@alexxy) reavertm: in 4.2.87 it works
-23:19 (@scarabeus) ok what state is the policykit anyway
-23:19 (@scarabeus) is it usable
-23:19 (@scarabeus) does it work?
-23:19 (@scarabeus) is there something neede
-23:19 (@scarabeus) d
-23:19 (@scarabeus) (i am quite scared about it)
-23:20 (@alexxy) scarabeus: polkit works
-23:20 (+reavertm) krytzz: I haven't understood, sorry
-23:20 (@alexxy) and its needed for some actions like suspend resume
-23:20 (dagger) alexxy: isn't it controled by hal's policykit settings?
-23:20 (@scarabeus) if it works then ok
-23:20 (@alexxy) dagger: not sure
-23:20 (+krytzz) reavertm hm forget it :p i think i missed something
-23:21 (+reavertm) (in kubuntu thet did it well btw)
-23:21 (@jmbsvicetto) scarabeus: about the blocks, I think we should add a kde use flag for qtscriptgenerator/qt-qt3support so that we can solve the phonon blocks. I talked about that in the bug
-23:21 (@tampakrap) kde4 use flag
-23:21 (@yngwin) we'll come to that
-23:21 (dagger) jmbsvicetto: good point
-23:21 (+reavertm) what about adding virtual for phonon?
-23:21 (@scarabeus) ok so we will ship phonon snapshot in main tree
-23:21 (@alexxy) ahh yes use flags
-23:21 (@scarabeus) any objections
-23:21 (@alexxy) =)
-23:22 (@scarabeus) and i think virtual is better than useflag
-23:22 (@hwoarang) +1 ^^
-23:22 (@yngwin) why?
-23:22 (@scarabeus) it should work
-23:22 (+reavertm) phonon in qt 4.5.1 is the same version as media-sound/phonon in tree
-23:22 (@scarabeus) and we dont have to polute the qt ebuilds
-23:22 (@jmbsvicetto) bug 270188
-23:22 (+reavertm) (just with no-go backend - gstreamer)
-23:22 (Willikins) jmbsvicetto: https://bugs.gentoo.org/270188 "qt-phonon / phonon + phonon-kde block"; Gentoo Linux, Applications; REOP; jannisf@gmail.com:kde@g.o
-23:23 (+reavertm) those blocks are mostly portage bugs btw
-23:23 (@yngwin) yes
-23:23 (@yngwin) well, if kde wants a virtual, i suppose that would work
-23:23 (@scarabeus) yngwin: well i thinked about you
-23:23 (@jmbsvicetto) hmm, how will the virtual solve the isue?
-23:23 (@scarabeus) i dont mind poluting qt ebuilds
-23:23 (@jmbsvicetto) issue*
-23:23 (@scarabeus) but isnt virtual better for maintaining?
-23:24 (+reavertm) || deps will be removed from ebuilds
-23:24 (@jmbsvicetto) The virtual will have to prefer one implementation over the other - which one will we prefer?
-23:24 -!- marco_ [n=marco@95.222.93.133] <- quit [Remote closed the connection]
-23:24 (@scarabeus) media one
-23:24 (+reavertm) || ( qt-phonon phonon ) deps
-23:24 (@scarabeus) cause it is phonon + xine
-23:24 (@jmbsvicetto) scarabeus: I don't think qt will want that
-23:24 (+wired) i agree with jmbsvicetto, kde use sounds better
-23:24 (@scarabeus) ok then we have to separate the xine
-23:24 (@scarabeus) srsly i dont mind
-23:24 (@scarabeus) so make it work :]
-23:24 (@yngwin) we wont use the virtual if qt-phonon is 2nd choice
-23:24 (@jmbsvicetto) scarabeus: Otherwise, we could just revert the deps on the qt ebuilds
-23:25  -> hwoarang lost contact
-23:25 (+reavertm) separating xine needs to be done anyway iho
-23:25 (@hwoarang) qt-phonon+xine sounds better
-23:25 (@hwoarang) n?
-23:25 (@hwoarang) *no?
-23:25 (@yngwin) that sounds like a better solution
-23:25 (+reavertm) make it possible
-23:25 (@jmbsvicetto) reavertm: What we really need to do is to force xine to qt upstream ;)
-23:25 (@hwoarang) you cant
-23:25 (+reavertm) xine is evil GPL
-23:25 (+reavertm) no can do
-23:26 (@jmbsvicetto) right, *evil*
-23:26 (@yngwin) lol
-23:26 (@scarabeus) ok so snapshot and spliting
-23:26 (@hwoarang) the thing is, is it possible to ship xine separately?
-23:26 (@scarabeus) the useflag i guess is ok
-23:26 (@hwoarang) good
-23:26 (+reavertm) hwoarang: shoud be possible
-23:26 (@scarabeus) so lets use it for now
-23:26 (@scarabeus) and later we just drop media-sound/phonon
-23:26 (@scarabeus) problem solved
-23:27 (@yngwin) hwoarang: you ok with USE=kde in qt ebuilds to prefer media-sound/phonon over qt-phonon?
-23:27 (+reavertm) (what about -9999? live phonon frm qt is not really live phonon - media-sound/phonon-9999 will need to stay - virtual can come into play)
-23:27 (@hwoarang) i dont mind
-23:28 (+reavertm) hwoarang: and you need to strip gstreamer from qt-phonon as well
-23:28 (@yngwin) ok
-23:28 (@hwoarang) in case we have kde?
-23:28 -!- d00p [n=d00p@srv3.nutime.de] joins -> #gentoo-kde
-23:28 (@hwoarang) kde? -> media-sound/phonon and strip gstreamer?
-23:28  -> hwoarang lost contact again :S
-23:28 (+reavertm) xine and gstreamer backends could be split from media-sound/phonon
-23:28 (@hwoarang) ok
-23:29 (@jmbsvicetto) yngwin: can we have "kde? ( || ( media-sound/phonon x11-libs/qt-phonon )) !kde? ( || ( x11-libs/qt-phono media-sound/phonon ))" ?
-23:29 (@yngwin) we can work out the details later
-23:29 (@hwoarang) reavertm:  so we ll use the split packages  and strip the gstreamer from qt-phonon
-23:29 (+reavertm) imho - qt-phonon should provide just phonon library - no platorm sound library
-23:29 (@scarabeus) details later plz
-23:29 (@hwoarang) ok
-23:29 (+reavertm) ok
-23:29 (@scarabeus) anything else for kde4.3
-23:29 (@scarabeus) this release seems fine
-23:29 (@jmbsvicetto) That way we can add a dep on kde4 eclasses for x11-libs/qt-qt3support[kde]
-23:29 (@scarabeus) if we have nothing else
-23:29 (+reavertm) yeah, it's b0rked!
-23:29 (@scarabeus) borked by upstream
-23:30 (@scarabeus) but if there is something from our side
-23:30 -!- helch [n=helch@212-41-73-167.adsl.solnet.ch] joins -> #gentoo-kde
-23:30 (+reavertm) (bth, it's misusing kde USE flag - better something related to phonon, not kde)
-23:30 (@tampakrap) phonon use flag?
-23:30 (@hwoarang) we can work on that
-23:31 (@hwoarang) kde4 sounds better to me . or kde
-23:31 (@yngwin) kde it is
-23:31 (@hwoarang) ok move on
-23:31 (@jmbsvicetto) hwoarang: As we're talking about kde-4.3, let's spend a few minutes talking about the use flags
-23:31 (+reavertm) kde, kde4?
-23:31 (@hwoarang) as you wish :)
-23:32 (@jmbsvicetto) hwoarang: We should drop the KDE4 use flag now and instead use KDE and KDE3 use flags
-23:32 (@tampakrap) kde->kde3 and kde4->kde4 and we can document that too
-23:32 (+reavertm) I expreessed my opition on -desktop ml
-23:32 (@hwoarang) that discussion took place ages ago
-23:32 (@tampakrap) why change the kde use flag? it is already used by kde3
-23:32 (@hwoarang) :/ i m not sure if we reached on some solution
-23:32 (@jmbsvicetto) The KDE use flag should give users the best working version at each point in time - that means it should give users KDE4 now
-23:32 (@scarabeus) kde = latest kde, for now kde4
-23:32 (@scarabeus) kde3 = kde 3.5
-23:32 (@yngwin) kde useflag means highest available version that is relevant to the package
-23:33 (@jmbsvicetto) not exactly the latest. As long as a version is experimental, it makes sense to have one use flag for it
-23:33 (@scarabeus) what i write
-23:33 (+reavertm) I don't like idea of self-'migrating' USE flag
-23:33 (@tampakrap) and what about kgtk for example that supports both?
-23:33 (@scarabeus) reavertm: gtk2 gtk1 was pain
-23:33 (+reavertm) "now we consider kde as KDE4, later it will be KDE5)
-23:33 (@scarabeus) trust me self migrating is better
-23:33 (dagger) jmbsvicetto: wouldn't it be less ambiguous to keep kde3 and kde4, so people will _always_ know what potential deps it might have/
-23:33 (@jmbsvicetto) reavertm: that's how it should be, imo
-23:33 (+reavertm) dagger: my point
-23:34 (@scarabeus) their issue
-23:34 (@jmbsvicetto) dagger / reavertm: One can check the local use flags
-23:34 (@scarabeus) they can track our anouncement
-23:34 (@scarabeus) we have news
-23:34 (@scarabeus) so we can sent it to their machine quite obviously
-23:34 (@jmbsvicetto) That's why we can now have local descriptions to make clear what each flag does
-23:34 (+reavertm) ok, what about compiz?
-23:34 (dagger) jmbsvicetto: what if we suddenly change kde flag to old kde4. That will cause problems for users
-23:35 (+reavertm) kde3 and kde USE flags?
-23:35 (@jmbsvicetto) reavertm: I'll fix that one
-23:35 (+reavertm) what about  'kde' meaning "general KDE support"
-23:35 (@jmbsvicetto) reavertm: I haven't spend as much time with it as I would like
-23:35 (+reavertm) what the heck is that?
-23:35 (@scarabeus) dagger: nothing
-23:35 (dagger) I really believe we shoudn't have kde and kde3, just kde4 and kde3. That way it's simple for people
-23:35 (@scarabeus) they just read anoucnement
-23:36 -!- Weaselweb [n=quassel@2001:6f8:9e4:123:21a:92ff:fe5a:1409] <- quit [Read error: 104 (Connection reset by peer)]
-23:36 (dagger) scarabeus: do you read announcements? Most people don't
-23:36 (@scarabeus) their problem
-23:36 (@scarabeus) really
-23:36 (@scarabeus) i read them
-23:36 (@yngwin) indeed
-23:36 (+reavertm) jmbsvicetto: I mean, there's choice to build against kdelibs:3.5 and kdelibs4 - it needs to be distinguished
-23:36 (@hwoarang) wtf
-23:36 (@jmbsvicetto) dagger: That way everyone will have to update their use flags to migrate between versions - I don't think that makes any sense
-23:36 (@hwoarang) stop carying about lazy users
-23:36 (+papillon81) scarabeus is right. kde should always refer to the latest version
-23:36 (@jmbsvicetto) reavertm: yes, I know. I'll keep the 2 use flags, but they're going to become kde3 and kde
-23:36 -!- pip_ [n=pip@e179240053.adsl.alicedsl.de] <- quit [Read error: 110 (Connection timed out)]
-23:36 (dagger) jmbsvicetto: they will have to modify use flags anyway migrating from 3 to 4, as most use flags are different anyway
-23:37 (@yngwin) most users will want/assume support for latest version
-23:37 (+reavertm) "general KDE support" means compiling against some kdelibs
-23:37 (@jmbsvicetto) dagger: that's a different thing, but kde will mean adding support for KDE
-23:37 (+reavertm) there's no "general" kdelibs - it's particular kdelibs that will be pulled
-23:37 (dagger) I don't want to wonder - what version might it be today ... and what will it be tommorow - and I'm pretty sure users don't want it as well
-23:38 (@yngwin) it's pretty straightforward
-23:38 (+reavertm) that being said = "support for KDE" is not clear enough
-23:38 -!- LXj [n=lx@ip211-94.telenet.dn.ua] <- quit [Read error: 110 (Connection timed out)]
-23:38 -!- wohnout [n=wohnout@kolej-mk-60.zcu.cz] joins -> #gentoo-kde
-23:38 (+reavertm) stable users have kde 3.5 and support for kde means support for THEIR kde
-23:38 (dagger) no it's not streaightforward. Some will assume - most recent, some will assume stable, some other wont have idea
-23:38 (+wired) well one valid alternative would be to just ditch kde and keep kde3 and kde4
-23:38 (+reavertm) for me kde treacking latest kde in portage is no go
-23:38 (+reavertm) never
-23:39 (dagger) if we change kde to kde3 - we screw stable users and emerge -DN
-23:39 (@yngwin) it's been that way for a long time, and for good reasons
-23:39 -!- The_Ball [n=The_Ball@d58-106-136-240.sbr4.nsw.optusnet.com.au] joins -> #gentoo-kde
-23:39 (dagger) unless you want to do the change when kde4 goes stable
-23:39 (+reavertm) yes, my recommendation is to drop 'kde' and keep only 'kde3', 'kde4' and so on
-23:39 (@yngwin) dagger: we dont need to change
-23:40 (dagger) yngwin: I'm lost than. I thought kde will suppose to be for kde 4
-23:40 (@jmbsvicetto) dagger: I think you're missing an important point - the kde use flag is relevant for misc apps, not for base kde
-23:40 (+spatz) will be symmetric with 'qt3', 'qt4', which makes sense to many people
-23:40 (@tampakrap) can we vote? options: kde3-kde4 and kde-kde3
-23:40 (@scarabeus) ok
-23:40 (@scarabeus) lets have vote
-23:40 -!- thansen [n=thansen@c-76-27-110-194.hsd1.ut.comcast.net] joins -> #gentoo-kde
-23:40 (@alexxy) reavertm: +1
-23:40 (+Civil) kde3-kde4
-23:40 (@tampakrap) i vote kde3-kde4
-23:40 (dagger) kde3-kde4
-23:40 (@yngwin) kde means kde support
-23:40 (+krytzz) kde3-kde4
-23:40 (+wired) do we vote or dev-only? =]
-23:40 (@scarabeus) on this only devs please
-23:40 (@scarabeus) and use 1 2
-23:40 (+krytzz) oh :p sorry ignore mine
-23:41 (@scarabeus) 1 for kde3-kde4
-23:41 (@scarabeus) 2 for kde3-kde
-23:41 (@hwoarang) 2
-23:41 (@tampakrap) 1
-23:41 (@yngwin) 2
-23:41 (@alexxy) 1
-23:41 (@scarabeus) 1
-23:41 (@jmbsvicetto) 2
-23:41 (dagger) 1
-23:41 (@scarabeus) erm 2
-23:41 (@jmbsvicetto) scarabeus: I think you messe your vote ;)
-23:41 (@scarabeus) i mean 2
-23:41 (@scarabeus) :D
-23:41 (@scarabeus) idiot
-23:41 (@jmbsvicetto) messed*
-23:41 (@scarabeus) yup
-23:41 (@yngwin) you pulled a ssuominen
-23:41 (@scarabeus) 2222222
-23:41 (@scarabeus) i wont change it
-23:42 (@alexxy) no!!!!!!
-23:42 (@hwoarang) 2 it is :P
-23:42 (@scarabeus) i just wanted to mark kde3-kde as one ; then i read it above
-23:42 (dagger) scarabeus: lies!
-23:42 (Viedzmin) ave \m/
-23:42 (dagger) scarabeus: ;)
-23:42 (@scarabeus) ;[
-23:42 (@scarabeus) ;]
-23:42 (@yngwin) so we stay with current practice
-23:42 (@jmbsvicetto) ok, so let's move forward
-23:42 (@scarabeus) yep
-23:42 (@scarabeus) CODE
-23:42 (@tampakrap) wait
-23:42 -!- doobry [n=quassel@host86-169-175-149.range86-169.btcentralplus.com] <- quit [Read error: 104 (Connection reset by peer)]
-23:42 (@yngwin) yes
-23:43 (@tampakrap) who will do the change?
-23:43 (@tampakrap) :)
-23:43 (@yngwin) what change?
-23:43 (@hwoarang) you
-23:43 (@scarabeus) when you smile so much
-23:43 (@scarabeus) guess twice
-23:43 (+reavertm) thos who voted that is
-23:43 (dagger) scarabeus: can you please explain magic CODE
-23:43 (@scarabeus) dagger: you dont get something in it?
-23:43 (@scarabeus) then ask
-23:43 (@scarabeus) ok what code is
-23:43 (@tampakrap) people wait the last topic isn't finished
-23:43 (@scarabeus) it is list of things all kde team packages should comply
-23:43 (dagger) scarabeus: I have no idea what "  - enforcing CODE requirements everywhere" is about
-23:43 (+reavertm) look at CODE file in Documentation
-23:43 (@tampakrap) we need to grep the tree and change the flags who will do it???????????
-23:44 (@yngwin) tampakrap: NO NEED
-23:44 (+reavertm) it's work in progress
-23:44 -!- The_Ball1 [n=The_Ball@d58-106-26-133.sbr2.nsw.optusnet.com.au] joins -> #gentoo-kde
-23:44 (@scarabeus) http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/CODE
-23:44 (@yngwin) only when there is a choice between kde 3 and 4 support do you need to specify USE=kde3
-23:44 (dagger) scarabeus: ok, now I get you
-23:44 (@jmbsvicetto) tampakrap: That needs only to be done for latest versions of misc packages that work with KDE4
-23:45 -!- termite47384 [n=me@cpe-066-057-082-106.nc.res.rr.com] <- quit [Read error: 60 (Operation timed out)]
-23:45 -!- LXj [n=lx@ip211-94.telenet.dn.ua] joins -> #gentoo-kde
-23:45 (+reavertm) ok, so CODE is set of commit policies/guides in overlay basically
-23:46 (@scarabeus) in overlay and in tree too
-23:46 (+reavertm) maybe some ebuild workflow will be recommended there as well
-23:46 (@scarabeus) yup i want everyone to look on it and write some suggestions there and we will merge it
-23:46 (+krytzz) repoman plugin for the CODE :p
-23:46 (@scarabeus) krytzz: :D
-23:46 (@hwoarang) lazy ppl
-23:47 (@hwoarang) you can write a quick draft for kde ebuilds, just like i did for qt4 based ebuilds
-23:47 (+reavertm) will be there
-23:47 (+reavertm) as well as templates for blocks, etc
-23:47 (+reavertm) anyway - one rule
-23:47 (@yngwin) btw, i want $PN in commit messages for qting-edge as well
-23:48 (@hwoarang) hm?
-23:48 (+reavertm) everyone should respect them :)
-23:48 (@jmbsvicetto) scarabeus: If we have a CODE file, I might add a few suggestions about ebuilds (the ones reavertm noted some time ago)
-23:48 (@scarabeus) yep this one is draft
-23:49 (@scarabeus) althrought i enforce it as-is
-23:49 (@scarabeus) so please improve it
-23:49 (@hwoarang) yngwin: what? you want a template for qting-edge commits?
-23:49 (@scarabeus) and in next meeting it will be enabled as hard-forced
-23:49 (@scarabeus) and we should punish not folowing it
-23:49 -!- Red_Devil [n=red@lounge.datux.nl] joins -> #gentoo-kde
-23:49 (@scarabeus) i know annoying, but reduces time needed for maintaining
-23:49 (@hwoarang) indeed
-23:49 (@yngwin) hwoarang: yes please start commit msg with $PN
-23:50 -!- Red_Devil is now known as Guest36992
-23:50 (@hwoarang) thats sad. I really enjoyed funny commit messages
-23:50 (@hwoarang) :D
-23:50 (@yngwin) i dont mind funny :)
-23:50 (@hwoarang) ok hold on
-23:50 (+reavertm) ok, anything else? next?
-23:50 (@yngwin) but i do want to see what pkg is affected
-23:50 (@hwoarang) !herd qt && Pesa && spatz
-23:50 (+wired) lol-cat/pn
-23:50 (@hwoarang) ^^
-23:50 (@hwoarang) && wired
-23:51 (Pesa) hwoarang: i'm here
-23:51 -!- mode/#gentoo-kde [+vv Pesa spatz] by scarabeus
-23:51 (+wired) hwoarang: seriously, we read it already
-23:51 (+wired) :D
-23:51 (@hwoarang) did you see what we said about commit messages?
-23:51 -!- The_Ball_ [n=The_Ball@d58-106-141-118.sbr4.nsw.optusnet.com.au] <- quit [Read error: 110 (Connection timed out)]
-23:51 (+spatz) yep
-23:51 (@hwoarang) you did
-23:51 (@hwoarang) ok
-23:51 (+Pesa) yes
-23:52 (@hwoarang) anything else about CODE kde ppl?
-23:52 (@scarabeus) ok
-23:52 (@scarabeus) code done
-23:52 (@scarabeus) if noone has anything else
-23:52 (Willikins) hwoarang: incorrect usage, ask for help using 'Willikins: help herd'
-23:52 (+wired) lolz
-23:52 (@hwoarang) yes baby whatever
-23:52 (@scarabeus) next new pple in team etc/etc...
-23:52 (@scarabeus) so if you move your eyes to voiced pple
-23:53 (@hwoarang) we have plenty of them :P
-23:53 (@scarabeus) those are our not-yet deved/herdtested resources
-23:53 (@jmbsvicetto) hmmm, we're at around half of the agenda and we're hitting the 2 hour mark
-23:53 (+wired) who did you call a resource!!! :D
-23:53 (@yngwin) wired has finished quizzes, now it's up to recruiters
-23:53 (@hwoarang) this meeting will last forever!
-23:53 (@scarabeus) jmbsvicetto: too much spam about kde3
-23:53 (+krytzz) 1/4 if you add the qt stuff jmbsvicetto :p
-23:53 (@hwoarang) \o/
-23:53 (@scarabeus) most is done
-23:53 (+reavertm) jmbsvicetto: you know - it's merithorical meeting, not just fluff talk! :)
-23:53 (@scarabeus) jmbsvicetto: kdeprefix is done
-23:53 (@scarabeus) and so on
-23:54 (@yngwin) i'm interjecting qt recruits now
-23:54 (@scarabeus) ok so if you pple want to mentor someone
-23:54 (+reavertm) scarabeus: I'd have some idea
-23:54 (@scarabeus) or vice versa, if someone has urge became dev fast :D
-23:54 (@scarabeus) reavertm: you dont count, you have resistance to becaming dev, althrought i dunno why ;D
-23:54 (+reavertm) even if we have quite many HT's and contributors, I still feel we're understaffed in terms of tracking uptream patches
-23:54 (@yngwin) Pesa has been very active with Qt already, and spatz is our newest recruit
-23:55 (@hwoarang) \o/
-23:55 (+wired) woot
-23:55 (@yngwin) they both are on their way to devhood
-23:55 (+spatz) :D
-23:55 (+Pesa) ;)
-23:55 (@yngwin) there is another one, sping, not here now, he will join us after finishing GSoC
-23:55 (@tampakrap) and me :D
-23:55 (@hwoarang) we are growing fast
-23:55 (@hwoarang) be carefeull
-23:55 (@scarabeus) for kde team i would like krytzz and papillon81 to work on their ebuild quiz, cause you two are progressing :]
-23:55 (+papillon81) scarabeus: i have the quiz ready :-)
-23:55 (@scarabeus) great
-23:56 (@scarabeus) papillon81: sent it by mail, and we will discuss the meeting about it
-23:56 (+wired) yngwin: btw when should I expect a response? :)
-23:56 (@scarabeus) later :}
-23:56 (@hwoarang) soon wired
-23:56 (+krytzz) i cant devote enough time currently to do serious stuff
-23:56 (@yngwin) tampakrap: you may hear from sping (sebastian) as he is interested in qt3/kde3 maintenance
-23:56 (@yngwin) wired: usually within a few days
-23:56 (+reavertm) btw, what about 'assigning' some herd packages to particulat people?
-23:57 (+reavertm) for example one would take kdepim, someone else kdebindings
-23:57 (@tampakrap) not kde-base/* only extra packages
-23:57 (@scarabeus) reavertm: it needs interest
-23:57 (+reavertm) this way work is somewhat split
-23:57 -!- mikkoc [n=mikko@host116-78-dynamic.17-79-r.retail.telecomitalia.it] <- quit [Remote closed the connection]
-23:57 (+papillon81) scarabeus: it's mostly ready but already lying around for a year or so. will have to look over it
-23:57 (+wired) yngwin: thnx
-23:57 (@scarabeus) papillon81: no prob :}
-23:57 (+reavertm) scarabeus: of course... unfortunately
-23:58 (@scarabeus) ok i think that is all i wanted about recruits
-23:58 (@jmbsvicetto) reavertm: That's against the spirit of herds
-23:58 (@scarabeus) i wanted you to see them
-23:58 (@scarabeus) and also whom is progressing i contacted
-23:58 (@jmbsvicetto) reavertm: But nothing prevents one from adding himself to a package belonging to one of the herds
-23:58 -!- dagger [n=dagger@gentoo/developer/dagger] <- leaves #gentoo-kde ["http://quassel-irc.org - Chat comfortably. Anywhere."]
-23:58 -!- dagger [n=dagger@gentoo/developer/dagger] joins -> #gentoo-kde
-23:58 -!- mode/#gentoo-kde [+o dagger] by ChanServ
-23:58 (@scarabeus) anything else upon recruits?
-23:58 (@scarabeus) anyone?
-23:59 -!- The_Ball [n=The_Ball@d58-106-136-240.sbr4.nsw.optusnet.com.au] <- quit [Read error: 110 (Connection timed out)]
-23:59 (@scarabeus) jokey: are you here?
-23:59 (+reavertm) jmbsvicetto: I'm not talking about beaurocracy (adding to metadata) but real maintenance (periodically looking for some bugs in kde.org)
-23:59 (+reavertm) or we can just rely on b.g.o
-23:59 (@scarabeus) we are good at handling new bugs
-23:59 (@scarabeus) really
-23:59 (@jmbsvicetto) reavertm: Well, people can focus on particular areas
---- Day changed Fri May 22 2009
-00:00 (jokey) scarabeus: yep
-00:00 (@jmbsvicetto) About bugs, we need to start paying extra attention to security bugs
-00:00 (@scarabeus) jokey: so, what i need to do to be able to add pple to our git overlay
-00:00 (@scarabeus) jokey: i can do for sunrise, so what is needed to be done for kde team ones
-00:00 (@jmbsvicetto) you need to poke him :P
-00:00 (@scarabeus) i know
-00:00 (@jmbsvicetto) or rbu or robbat2
-00:00 (@scarabeus) directly i mean
-00:00 (jokey) need to mess with robin, I'll poke you back
-00:00 (@scarabeus) rbu cant touch git
-00:00 (@jmbsvicetto) scarabeus: he can
-00:01 (@dagger) scarabeus: he can
-00:01 (@scarabeus) jokey: this workflow is unflexible :]
-00:01 (@scarabeus) dagger: good update :]
-00:01 (@scarabeus) okey i will handle this with jokey internaly then :]
-00:01 (@scarabeus) the next topic is our guide
-00:01 (@scarabeus) kde4 one
-00:01 (@scarabeus) it neeeds update/cleanup
-00:01 (@scarabeus) who will do it
-00:01 (+reavertm) "handling cmake relwithdebuginfo compilation to please upstream..." ?
-00:01 (jokey) internally? oO teh sekrit
-00:02 (joost_op) guys can the sabayon point on the agenda be discussed at later time
-00:02 (@jmbsvicetto) joost_op: hehe
-00:02 (@scarabeus) reavertm: deffered
-00:02 (@scarabeus) reavertm: thought about it
-00:02 (@scarabeus) reavertm: not worth
-00:02 (+krytzz) what??
-00:02 (+reavertm) yeah, agreed
-00:02 (+papillon81) goooood
-00:02 (@scarabeus) jokey: definetly
-00:02 (@scarabeus) ;]
-00:03 (joost_op) jmbsvicetto, i think it can be talked about off the record anyway
-00:03 (@scarabeus) so the guide
-00:03 (+krytzz) ok then lets discuss this later scarabeus
-00:03 (@scarabeus) who
-00:03 (@tampakrap) wait
-00:03 (@tampakrap) about the guide
-00:03 (@tampakrap) would you like a kde3/4 monolithic one?
-00:03 (@jmbsvicetto) joost_op: sorry, that was meant for jokey
-00:03 -!- pgega [n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk] joins -> #gentoo-kde
-00:04 (joost_op) oh
-00:04 (@yngwin) tampakrap: i think it makes sense, with kde4 going to go stable
-00:04 (@tampakrap) stating how to install kde4, how to install live/snapshots and how to install 3.5, and how we can mix them
-00:04 (@tampakrap) i'll do the guide
-00:04 (@tampakrap) agreed with the mixed guide?
-00:05 (joost_op) scarabeus, let me know the outcome of the dicussion
-00:05 (@tampakrap) boss? devs? hts?
-00:05 (joost_op) if any
-00:05 (@scarabeus) tampakrap: agreed
-00:05 (@scarabeus) so quiet...
-00:05 (@jmbsvicetto) tampakrap: Perhaps we could have a new doc that points to specific guides about KDE4 and KDE3
-00:05 (@scarabeus) what happend
-00:05 -!- AntiXpucT [n=Skim@77.106.108.232] <- quit []
-00:06 (@jmbsvicetto) tampakrap: That doc would just focus on the integratio of 3 and 4
-00:06 (@yngwin) scarabeus: more beer, less talk ;)
-00:06 (@hwoarang) lolz
-00:06 (@jmbsvicetto) yngwin: I need to have some fun with work network yet, so no beer for me ;)
-00:06 (@yngwin) heh
-00:06 (+reavertm) if we focus guys - we'll finish earlier :P
-00:07 (@hwoarang) ok with the guide?
-00:07 (joost_op) +1
-00:07 (@hwoarang) shall we proceed?
-00:07 (@hwoarang) tampakrap: ?
-00:07 (@tampakrap) jmbsvicetto: the procedure to install kde3 and to install kde3/4 isn't different so i wouldn't agree :)
-00:07 (@tampakrap) same sets, same keyword files...
-00:07 (@jmbsvicetto) tampakrap: ok, feel free to work on it
-00:07 (@yngwin) i say whoever writes the guide(s), gets to make the decision
-00:07 (@tampakrap) ok move on then
-00:08 (@scarabeus) ok yngwin you take over
-00:08 (@hwoarang) what about kdebindings?
-00:08 (@hwoarang) is this off as well?
-00:08 (@scarabeus) eh
-00:08 (+reavertm) lacks some ebuilds
-00:08 (@scarabeus) right
-00:08 (@scarabeus) bindigns
-00:08 (@dagger) "kdebindings, lots of stuff missing there"
-00:08 (@scarabeus) we lacks tons of stuff
-00:08 (+reavertm) usually ruby and c#
-00:08 -!- jmbsvicetto topic of #gentoo-kde ->> Gentoo KDE | meeting: Now - kdebindings | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
-00:09 (+wired) lol
-00:09 (@yngwin) ok, whats the story with ruby for kde? does that depend on (currently broken) qt4-qtruby at all?
-00:09 (+reavertm) nobody knows :)
-00:09 (@scarabeus) ruby java c# php
-00:09 (@scarabeus) so whom wants it
-00:09 (+reavertm) - we need to try add those ebuilds
-00:09 -!- ABCD [n=ABCD@wikipedia/ABCD] joins -> #gentoo-kde
-00:10 (+reavertm) - maybe some ebuild name refactor for 4.3
-00:10 (+reavertm) anything else regarding kdebindings?
-00:10 (@scarabeus) ok reavertm we will talk about it later
-00:10 (@jmbsvicetto) scarabeus: no PERL?
-00:10 (@scarabeus) reavertm: and delegate to other HTs
-00:10 (@scarabeus) jmbsvicetto: no perl
-00:10 (@jmbsvicetto) I suggest we hand JAVA to bonsaikitten :P
-00:10 (@scarabeus) bindigns done
-00:11 (@scarabeus) joost_op: do you want to talk about sabayon then?
-00:11 (@jmbsvicetto) He's becoming too sane
-00:11 (@scarabeus) D
-00:11 (@bonsaikitten) jmbsvicetto: thank you :)
-00:11 (@jmbsvicetto) bonsaikitten: we aim to please ;)
-00:11 (@bonsaikitten) I aim to kill
-00:11 (+papillon81) :D
-00:11 (joost_op) well scarabeus i'm here
-00:12 (+reavertm) go :)
-00:12 (@scarabeus) shoot
-00:12 (@scarabeus) :]
-00:12 (@dagger) RUN!
-00:12 (joost_op) from the sabayon side we want to shoulder the kde herd as much as possible
-00:12 -!- Guest36992 [n=red@lounge.datux.nl] <- quit [Read error: 60 (Operation timed out)]
-00:12 (joost_op) what we can offer would be something in the form off a repository that has experimental kde stuffs, built of the testing tree
-00:12 (+reavertm) you already did with some automagic deps and doc verification
-00:13 (joost_op) since i would maintain that tree, i could feedback about my findings
-00:13 (+reavertm) binary packages you mean? i don't follow
-00:13 (joost_op) nah
-00:14 (joost_op) i built against a tree thats near full portage
-00:14 -!- UT2K3 [n=UT2K3@212.86.209.81] joins -> #gentoo-kde
-00:14 (joost_op) sabayon is near full portage
-00:14 (+reavertm) yes, I know, what would be that experimental kde stuff?
-00:14 -!- FlyingFoX [n=FlyingFo@137.226.140.67] joins -> #gentoo-kde
-00:14 (joost_op) well, e.g. you are working on kde 4.3
-00:15 (joost_op) i could add this in a kde repository
-00:15 (joost_op) and start working on this and feedback my findings
-00:15 (UT2K3) hello guys, i'm using fglrx with dualscreen. When run kde its only on the notebook lcd and the right screen have no wm. Its possible to make it work?
-00:15 (@hwoarang) why not use the ebuilds from kde-testing? whu starting a new repository
-00:15 (joost_op) if you think it would help collect info
-00:15 (@hwoarang) UT2K3: meeting now . laterz :
-00:15 (@hwoarang) :)
-00:16 (joost_op) hwoarang, we don't want that in our mainline repositories ..
-00:16 (+krytzz) joost_op hm well duplicated work/ebuilds is always bad :p
-00:16 (UT2K3) oh its still meeting ok
-00:16 (@hwoarang) as krytzz said, duplicating ebuilds will lead to more compilcated results
-00:17 (@dagger) UT2K3: yeah, but it shouldn't take long now
-00:17 (joost_op) do you guys to start with see a benefit in me, or sabayon, help testing
-00:17 (tdr) duplicated ebuild confuse people
-00:17 (+reavertm) joost_op: you're free to do anything with ebuilds - and patches (those upstream I guess) are always welcome
-00:17 (UT2K3) okay (= ty
-00:17 (@jmbsvicetto) joost_op: If you want to cooperate, using something we provide would seem to be better for both projects than duplicating work
-00:17 (joost_op) nono
-00:17 (joost_op) your ebuilds
-00:17 -!- panard [n=panard@2a01:e35:8a09:e130:2e0:61ff:fe11:7adb] <- quit [Read error: 104 (Connection reset by peer)]
-00:18 (+reavertm) joost_op: you just need to find someone to take care of this - it's quite a bit of work
-00:18 (joost_op) lol
-00:18 (@jmbsvicetto) So you mean you could test ~arch ebuilds?
-00:18 (joost_op) x86 and amd64
-00:18 (+krytzz) joost_op we had this already with kde-crazy and kde-testing, was a mess :p
-00:18 (@jmbsvicetto) Then go for it, we'll be glad to get bug reports
-00:18 (joost_op) i have a power machine to built
-00:18 (@scarabeus) ok i will put it this way
-00:19 (joost_op) i have testers AND users that report
-00:19 (@scarabeus) bugs from ppl with @sabayonlinux.org will be handled legitimely as our bugs
-00:19 (@scarabeus) and we can reflect them as HTs
-00:19 (@jmbsvicetto) joost_op: although most of us run ~arch or stuff in kde-testing
-00:19 (joost_op) i can filter whats important
-00:19 (@scarabeus) just for internal herd needs
-00:19 -!- Sho_ [n=EHS1@kde/hein] <- quit [Read error: 104 (Connection reset by peer)]
-00:19 (@scarabeus) so we can rely for some info from them
-00:19 (+reavertm) especially those automagic deps are welcome
-00:19 (@scarabeus) yep
-00:19 (+reavertm) :)
-00:20 (@scarabeus) those made mine day great :]
-00:20 -!- Sho_ [n=EHS1@kde/hein] joins -> #gentoo-kde
-00:20 (joost_op) yeah in our staff meeting we talked about how to report anything back to gentoo
-00:20 (@jmbsvicetto) ok, I'll have to leave in approximately 10 minutes
-00:20 (@dagger) Qt stuff now?
-00:21 (@scarabeus) jmbsvicetto: did you read what i wrote?
-00:21 (@scarabeus) any objections to that?
-00:21 (joost_op) anybody from our team uses @sabayonlinux.org
-00:21 (@jmbsvicetto) joost_op: we discuss details later with you. We can even schedule some time
-00:21 (joost_op) and each report has been dicussed in our team first
-00:21 -!- panard [n=panard@banquise.backzone.net] joins -> #gentoo-kde
-00:21 (joost_op) to not overload anybody
-00:21 (joost_op) and to certainly not duplicate work
-00:21 (@jmbsvicetto) scarabeus: no objection
-00:22 (joost_op) allright
-00:22 -!- helch [n=helch@212-41-73-167.adsl.solnet.ch] <- quit [Remote closed the connection]
-00:22 (@jmbsvicetto) In some cases we might require some testing to duplicate the bug, but we'll address the bugs
-00:22 (joost_op) i'm saying you can abuse me to get things in our yet to make repository
-00:22 (joost_op) where we can heve people to test it
-00:23 (joost_op) *have
-00:23 (@jmbsvicetto) ok, thanks
-00:23 -!- mpagano [n=mpagano@gentoo/developer/mpagano] <- quit ["cya"]
-00:23 (@scarabeus) ok we will address this issue more at more comfy time :]
-00:23 (@scarabeus) now lets get to the qt
-00:23 (@hwoarang) \o/
-00:23 (@hwoarang) ************************** qt meeting *****************************
-00:23 (joost_op) allright, thx
-00:23 (@hwoarang) wake up ppl
-00:23 (+Pesa) :)
-00:23 (@hwoarang) !herd qt
-00:24 (+wired) hwoarang: seriously, we're all here
-00:24 (Willikins) (qt) carlo, hwoarang, tampakrap, yngwin
-00:24 (+wired) :D
-00:24 (@dagger) bear time :)
-00:24 (@hwoarang) spatz: ping
-00:24 (+spatz) pong
-00:24 (@dagger) (not ever beer :p)
-00:24 (@jmbsvicetto) hwoarang: technically it's still the KDE *team* meeting ;)
-00:24 (@hwoarang) well yes :P
-00:24 (@yngwin) ok, first decision: next time separate qt meeting
-00:24 (@hwoarang) i just wanted to wake them up
-00:24 (@hwoarang) :D
-00:24 (@yngwin) this is getting too long for some ppl
-00:24 (+reavertm) I agree
-00:24 -!- Sho_ [n=EHS1@kde/hein] <- quit [Read error: 104 (Connection reset by peer)]
-00:24 (@tampakrap) for all
-00:24 (@hwoarang) i think this is the first time the kde one took that long
-00:25 (@scarabeus) yngwin: well the issue is due to we didnt have meeting in 2 months window
-00:25 (+reavertm) we're technical, soory ;)
-00:25 (@yngwin) i know
-00:25 (@jmbsvicetto) yngwin: Do you think it's best to have split meetings or should we have more frequent/shorter meetings?
-00:25 (@scarabeus) good Q
-00:25 (@yngwin) more frequent + shorter
-00:25 (+reavertm) split meeting is good anyway
-00:25 (+papillon81) first of all we should go on with the topics
-00:25 (@hwoarang) +1 yngwin
-00:25 (+reavertm) no need to qt folks to attend to kde meeting anyway unless they're interested
-00:26 (@jmbsvicetto) yngwin: I can live with both and if we keep having the same meeting, qt issues don't (shouldn't) be left for the end
-00:26 (@hwoarang) meeting is supposed to be 'project' wise
-00:26 (@hwoarang) not herd wise
-00:26 (@scarabeus) jmbsvicetto: it is for this time
-00:26 (@scarabeus) jmbsvicetto: next time i can shuffle the topics
-00:26 (@jmbsvicetto) yeah, I'm just opening up other solutions in case people prefer them
-00:26 (@scarabeus) and we can have the meetings often i dont mind :]
-00:26 (@yngwin) alright, lets get on it
-00:26 -!- Civil [n=Civilian@95-24-2-240.broadband.corbina.ru] <- quit [Remote closed the connection]
-00:27 (@yngwin) we can discuss needs for next meeting tomorrow ;)
-00:27 (@hwoarang) i think we can pass the recruit stuff
-00:27 (@scarabeus) okey
-00:27 (@yngwin) recruits i already mentioned
-00:27 (@yngwin) qt status in tree
-00:27 (@yngwin) 4.5.1 is goibng stable, but arches are slow
-00:27 (@hwoarang) indeed :/
-00:27 -!- Displacer [n=tool@tool.gtn.ru] <- quit ["Leaving"]
-00:27 (+wired) !earch qt-core
-00:27 (Willikins) wired: x11-libs/qt-core 4.4.2[4]: 4.4.2-r2[4]: amd64 hppa ia64 ppc64 sparc x86 4.5.1[4]: alpha ~amd64 ~arm ~hppa ~ia64 ~mips ppc ~ppc64 ~sparc ~x86 ~x86-fbsd
-00:28 (@hwoarang) there is a bug about the -platform . The addition on qt4-build-edge eclass seems to fix it
-00:28  -> hwoarang searches the bug
-00:28 (+wired) bug 266201
-00:28 (Willikins) wired: https://bugs.gentoo.org/266201 "Please mark x11-libs/qt-*-4.5.1 stable [also regression tracker]"; Gentoo Linux, Ebuilds; NEW; yngwin@g.o:qt@g.o
-00:28 (@hwoarang) bug 270475
-00:28 (Willikins) hwoarang: https://bugs.gentoo.org/270475 "x11-libs/qt-4.5 configure guesses arch based on uname"; Gentoo Linux, Ebuilds; NEW; jokey@g.o:qt@g.o
-00:29 -!- emera|d [n=smaragd@p579DE9E7.dip.t-dialin.net] <- quit []
-00:29 (@hwoarang) this bug ( and the proposed solution ) seems to fix the massive errors we had with ppc, chroots, distcc etc
-00:30 (@yngwin) ok, i propose we add arches on that one, and ask their opinion
-00:30 (@jmbsvicetto) It would great if you could get upstream to fix qt-webkit on sparc
-00:30 (+papillon81) there is another patch for qt-gui (already in the qting-edge overlay), that fixes PPC graphics issues and should go to the treee ASAP
-00:30 (@hwoarang) qt-gui is stable on ppc
-00:30 (@jmbsvicetto) We won't be able to get KDE in sparc until qt-webkit is fixed or we can make KDE upstream make it optional
-00:30 (@yngwin) bug number?
-00:30 (+wired) yngwin: ^^ thats the one i've talked to you about
-00:31 (@hwoarang) jmbsvicetto: dont expect this to happen soon
-00:31 (@yngwin) i know, i still havent heard if its so important and why
-00:31 (@hwoarang) upstream is really really slow
-00:31 (+papillon81) yngwin: no bug #
-00:31 (@hwoarang) i really dont think we should do a revbump just for a ppc patch
-00:31 (@hwoarang) cause all other arches will upgrade for nothing
-00:31 (@hwoarang) maybe we can put is 'silently' on stable qt-gui-4.5.1
-00:31 (@hwoarang) *s/is/it
-00:31 (+papillon81) hwoarang: just add it silently :-)
-00:32 (@yngwin) we need a proper bug report
-00:32  -> papillon81 will do it
-00:32 (@tampakrap) well, revbump and tell ppc to stabilize again
-00:32 (@yngwin) because i still dont know what we're talkingf about
-00:32 (@tampakrap) it won't break stable users anywayz
-00:32 (@hwoarang) tampakrap: revbump is wrong
-00:32 (@hwoarang) the rest of arches dont need to emerge qt-gui again
-00:32 (@jmbsvicetto) yngwin / wired: are you asking the bug number for qt-webkit and sparc?
-00:33 (@hwoarang) it is just a ppc patch that can go on the current qt-gui
-00:33 (@tampakrap) i know but there is no other way
-00:33 (@yngwin) ok, we can discuss that on the bug
-00:33 (+wired) jmbsvicetto: no the patch for qt-gui and ppc
-00:33 (@hwoarang) good
-00:33 (@yngwin) jmbsvicetto: no, the ppc issue
-00:33 (@jmbsvicetto) ok
-00:33 (+wired) jmbsvicetto: it doesn't have a bug
-00:34 (@tampakrap) two options, silent update or revbump and restabilize, choose one, i choose the second
-00:34 (@yngwin) ok, other in tree issues?
-00:34 (@hwoarang) scarc issue should go upstream but i am pretty sure it ll take forever even to accept it as valid
-00:34 -!- ali_bush_work [i=cab44391@gateway/web/ajax/mibbit.com/x-e12143e624250926] joins -> #gentoo-kde
-00:34 (@yngwin) yes, but we can do our duty and report
-00:34 (@hwoarang) yes
-00:34 (@hwoarang) of course
-00:34 (@tampakrap) wait
-00:34 (@tampakrap) the sparc issue is reported by me in gentoo bugzilla long time ago
-00:34 (@tampakrap) i've made some research about it
-00:35 (@hwoarang) yes but did you take it upstream?
-00:35 (@tampakrap) there was actually a patch
-00:35 (@hwoarang) can you ?
-00:35 (@hwoarang) mmm
-00:35 (@yngwin) bug # ?
-00:35 (@tampakrap) but it broke ppc64 i think or something
-00:35 (@jmbsvicetto) tampakrap: The patch wasn't accepted upstream
-00:35 (@tampakrap) of course since it broke ppc64
-00:35 (@jmbsvicetto) tampakrap: And iirc, that bug may also affect alpha (or at least also interests them)
-00:35 (@yngwin) we could apply the patch only on sparc
-00:36 (@tampakrap) yes
-00:36 (@tampakrap) exactly
-00:36 (@hwoarang) sound like an easy work around
-00:36 (@tampakrap) i own a sparc but it will take some time to update it to qt-4.5
-00:36 (@tampakrap) i'll contact sparc herd as well
-00:36 (@hwoarang) ok
-00:36 (@jmbsvicetto) tampakrap: tcunha and jmorgan might be willing to help out with it
-00:37 (@tampakrap) bug 235685
-00:37 (Willikins) https://bugs.gentoo.org/235685 "x11-libs/qt-webkit-4.4.x sigbus on ~sparc"; Gentoo Linux, KDE; NEW; tampakrap@g.o:sparc@g.o
-00:38 (@hwoarang) ok
-00:38 (@yngwin) ok, if you can follow-up on that with sparc arch team
-00:38 (@tampakrap) comment 7 says that it should not be restricted to sparc only
-00:38 -!- B-Man1 [n=B-Man@cpe-098-024-241-139.ec.res.rr.com] joins -> #gentoo-kde
-00:38 (@tampakrap) i don't know why
-00:38 (+papillon81) bug 270769
-00:38 (Willikins) papillon81: https://bugs.gentoo.org/270769 "x11-libs/qt-gui-4.5.1 PPC endian fix"; Gentoo Linux, Ebuilds; NEW; chrschmitt@gmail.com:bug-wranglers@g.o
-00:38 (@yngwin) tampakrap: could be interesing for other arches too, like alpha
-00:39 (@yngwin) papillon81: tnx
-00:40 (@hwoarang) are we done with bugs?
-00:40 (@yngwin) no
-00:40 (@yngwin) i'd like someone to look at bug 209626
-00:40 (Willikins) yngwin: https://bugs.gentoo.org/209626 "Patches for qt4.eclass and qt4-build.eclass to make them ready for eclass-manpages"; Gentoo Linux, Eclasses and Profiles; NEW; bugs@rennings.net:qt@g.o
-00:41 (@hwoarang) I will take care of it
-00:41 (@yngwin) thanks
-00:41 (@hwoarang) anything else?
-00:42 -!- andreax [n=andreaz@p57B94087.dip.t-dialin.net] joins -> #gentoo-kde
-00:42 (@yngwin) and is there anyone interested in bug 224951 ?
-00:42 (Willikins) yngwin: https://bugs.gentoo.org/224951 "[Tracker] dev-ruby/qt4-qtruby issues"; Gentoo Linux, Applications; NEW; unnamedrambler@gmail.com:ruby@g.o
-00:42 -!- Friesia [n=speckius@212.113.107.78] <- quit [Remote closed the connection]
-00:42 (@yngwin) it has been hardmasked (all versions) in tree for a while now
-00:42 (@hwoarang) brrrrrrrrrrrrr ruby
-00:43 (@yngwin) well, i think we should fix it or schedule for removal
-00:43 (@hwoarang) we can ping ruby herd again
-00:43 (@hwoarang) as reach a common decision
-00:43 (@hwoarang) *and
-00:44 (@yngwin) i started doing some testing on 2.x version, but didnt get far
-00:44 (+wired) i could give it a try as well
-00:44 (@hwoarang) we can add it on overlay and start playing
-00:44 (@yngwin) i needs work (which means time)
-00:44 (@yngwin) ok, i'll add what i have to overlay
-00:44 (@hwoarang) ok
-00:44 (+wired) =]
-00:44 (@hwoarang) bug 236341 needs some love as well
-00:44 (Willikins) hwoarang: https://bugs.gentoo.org/236341 "PyQt4 has automagic dependencies"; Gentoo Linux, Ebuilds; REOP; alessandro.guido@gmail.com:qt@g.o
-00:45 (@hwoarang) i think me and Pesa will get this done soon
-00:45 (+Pesa) i'm working on that one
-00:45 (@yngwin) nice
-00:45 (@hwoarang) sweet
-00:45 (@hwoarang) i cant see anything else
-00:45 (+Pesa) btw, bug 251997 was fixed some time ago
-00:45 (Willikins) Pesa: https://bugs.gentoo.org/251997 "net-im/psi: pre-stripped files found"; Gentoo Linux, Ebuilds; NEW; flameeyes@g.o:welp@g.o
-00:45 -!- andreax1 [n=andreaz@p57B9556B.dip.t-dialin.net] <- quit [Operation timed out]
-00:45 (+Pesa) please mark as such :)
-00:45 (@yngwin) ok, we can close that?
-00:45 (@hwoarang) yes indeed
-00:45 (+Pesa) yep
-00:46 (+Pesa) fixed by a change in eqmake4
-00:46 (@yngwin) done
-00:46 (@hwoarang) \o/
-00:46 (+Pesa) thanks
-00:46 (@hwoarang) any other bugs?
-00:46 (@yngwin) what about the embedded stuff
-00:47 (@hwoarang) tricky
-00:47 (@hwoarang) qt-embedded?
-00:47 (@yngwin) esp https://bugs.gentoo.org/show_bug.cgi?id=43827#c9
-00:48 (@hwoarang) we can contact him
-00:48 (@yngwin) maybe we should contact him and see if he still wants to maintain it
-00:48 (@hwoarang) and ask him to be proxy mantainer
-00:48 (@yngwin) then add it to overlay or tree
-00:48 (@yngwin) indeed
-00:48  -> hwoarang noted
-00:48 (@hwoarang) I will contact him
-00:48 (@yngwin) ok, on to overlay then?
-00:49 -!- panard [n=panard@banquise.backzone.net] <- quit [Read error: 54 (Connection reset by peer)]
-00:49 (@hwoarang) sorry?
-00:49 (@tampakrap) yes
-00:49 (@yngwin) next point on agenda
-00:49 (@hwoarang) we are moving on?
-00:49 (@hwoarang) ok
-00:49 (@hwoarang) Pesa: spatz
-00:49 (@hwoarang) are you guys using qt live ebuilds?
-00:49 (+Pesa) no
-00:49 (+spatz) nope
-00:49 -!- Guest36992 [n=red@lounge.datux.nl] joins -> #gentoo-kde
-00:49 (@tampakrap) i am
-00:50 (@hwoarang) ok
-00:50 (+papillon81) me
-00:50 (+reavertm) i use qt-copy in chroot
-00:50 (@hwoarang) so we need to see who maintains what
-00:50 (@hwoarang) i do maintain 4.5.9999 (both qt-copy and nokias )
-00:50 (@yngwin) i use latest release
-00:50 (+reavertm) but I'm no longer maintaing those...
-00:50 (@hwoarang) that is 4.9999?
-00:50 (@hwoarang) wired: is on 4.9999
-00:50 (+wired) i test 4.999 and 4.5.9999[-qt-copy
-00:50 (@yngwin) 4.9999 is nokia qt git trunk
-00:50 (+wired) i test 4.999 and 4.5.9999[-qt-copy]
-00:51 -!- panard [n=panard@2a01:e35:8a09:e130:2e0:61ff:fe11:7adb] joins -> #gentoo-kde
-00:51 (@hwoarang) so we are ok on that
-00:51 -!- Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] <- quit [Remote closed the connection]
-00:51 (+wired) nokia
-00:51 (+wired) 4.6 trunk and 4.5 trunk ^^ :)
-00:51 -!- Hello_World [n=koukos@ip-83-212-218-40.adsl.aueb.gr] joins -> #gentoo-kde
-00:51 (@hwoarang) ok so we re ok on qt libe ebuilds
-00:52 (@hwoarang) *live
-00:52 (+wired) we should discuss what will happen to the RDEPEND in qt4-edge-build
-00:52 (@hwoarang) yes
-00:52 (+wired) are we moving that in tree?
-00:52 (@yngwin) is it tested enough?
-00:52 (+wired) today tampakrap had yet another issue
-00:52 -!- UT2K3 [n=UT2K3@212.86.209.81] <- quit [Remote closed the connection]
-00:53 (@hwoarang) what about the paludis support
-00:53 (+wired) yngwin: so far it seems safe on my tests
-00:53 (+wired) paludis doesn't like it but thats only because ciaran doesn't want to implement blocks the same way portage does
-00:53 (@yngwin) paludis seems to be broken at this point
-00:53 -!- Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] joins -> #gentoo-kde
-00:53 (@bonsaikitten) hwoarang: why do we care?
-00:53 (@hwoarang) cause i cant stand the trolls tomorrow
-00:54 -!- bschindl [n=quassel@77-56-156-71.dclient.hispeed.ch] <- quit [Read error: 104 (Connection reset by peer)]
-00:54 (+wired) no trolls
-00:54 (@hwoarang) if you know what i mean
-00:54 (+wired) actually
-00:54 (@bonsaikitten) so ignore them
-00:54 (@bonsaikitten) "WORKSFORME" is a great defense ;)
-00:54 (+wired) this is one of the few cases where he didn't complain
-00:54 (@hwoarang) in this case we can proceed
-00:54 (+wired) i think the way this works is valid and paludis should adapt if it wants to work
-00:54 (@hwoarang) the solution is pretty clean and easily revertable
-00:55 (@hwoarang) yngwin: what do you think
-00:55 (@yngwin) i dont think there is a better solution
-00:55 -!- termite47384 [n=me@cpe-066-057-082-106.nc.res.rr.com] joins -> #gentoo-kde
-00:55 -!- mode/#gentoo-kde [+v termite47384] by ChanServ
-00:55 (@hwoarang) ok then we can proceed
-00:55 (@yngwin) if we talk about eclass functionality anyway
-00:55 (+wired) ok then it should go to qt4-build along with anything else we decide to migrate
-00:55 (@yngwin) what about other stuff we want to move to tree
-00:56 (@hwoarang) well
-00:56 (@hwoarang) qt4-build can use -platform as discussed before
-00:56 (@hwoarang) but that should take a while
-00:56 (@yngwin) yes
-00:56 (@hwoarang) we need to invite arches on that bug
-00:56 (@hwoarang) i have nothing else to propose for qt4-build
-00:57 (@hwoarang) i think this eclass has been reviewed recently
-00:57 (@hwoarang) just before pushing qt-4.5.0_rc1
-00:57 (@yngwin) we need to remove custom-cxxflags when 4.5.2 goes in
-00:57 (@hwoarang) yes
-00:58 (@hwoarang) this use flag has been dropped on overlay. Works ok .
-00:58 (@hwoarang) we are safe to drop it when 4.5.2 arrives
-00:58 (@yngwin) good, let's not forget
-00:58  -> hwoarang noted
-00:58 (@yngwin) what about qt4.eclass
-00:58 (@hwoarang) Pesa: here we are
-00:58 (@hwoarang) :D
-00:59 (+Pesa) heh
-00:59 (@yngwin) we wanted qt4-edge -> qt4-ng or something?
-00:59 (@hwoarang) i think that you pushed a default src_configure and src_install in the past
-00:59 (@hwoarang) but you revert it
-00:59 (@hwoarang) why?
-00:59 (@yngwin) we had to
-00:59 (@hwoarang) brakeages?
-00:59 (@yngwin) it broke stuff all over the place
-00:59 (@hwoarang) right
-01:00 (@hwoarang) i cant understand how
-01:00 (@hwoarang) since src_install is always overriden
-01:00 (@yngwin) so i do want that back in, but we need it in a separate eclass, so existing ebuilds can be migrated slowly
-01:00 (@hwoarang) but lets play it safe
-01:00 (@hwoarang) ok
-01:00 (+Pesa) isn't it possible to have a drop-in replacement?
-01:00 (@hwoarang) meaning?
-01:01 -!- smorg [n=quassel@75-168-239-242.mpls.qwest.net] <- quit ["http://quassel-irc.org - Chat comfortably. Anywhere."]
-01:01 (+Pesa) a revised qt4.eclass, but maintaining backward compatibility
-01:01 (@yngwin) no, because we require eapi-2 and have new default functionality such as src_configure in there
-01:01 (@hwoarang) we cant
-01:01 -!- smorg [n=quassel@75-168-239-242.mpls.qwest.net] joins -> #gentoo-kde
-01:01 (@hwoarang) how about maintain eqmake4 on qt4.eclass and inherit that eclass on the new one?
-01:02 (@hwoarang) just to avoid mantaining 2 eqmake4
-01:02 (@yngwin) hmm, i dont like the added level of complexity
-01:02 (+Pesa) i agree with yngwin
-01:03  -> hwoarang is thinking
-01:03 (+spatz) is qt4-edge to be merged as-is? at least the translations stuff seems broken on many packages and fixing after merge can be problematic
-01:03 (+Pesa) it'd be better to have a eqmake4.eclass inherited by both the new and the old qt4 eclasses
-01:03 (@hwoarang) the translations part is experimental
-01:04 (+Pesa) spatz: i don't think so
-01:04 (@hwoarang) yngwin:  cant we open a tracker
-01:04 (@hwoarang) about the brakeages?
-01:04 (+spatz) Pesa: which part?
-01:04 (@yngwin) what breakages?
-01:04 (@hwoarang) which are caused by the new eclass?
-01:05 (@hwoarang) in case we push it as qt4.eclass
-01:05 (+Pesa) spatz: well, src_configure() needs improvements imho
-01:05 (@yngwin) only if we dont touch the original eclass, we can't break stable stuff
-01:06 (@hwoarang) introducing the default src_configure and src_install will brake some packages
-01:06 (@hwoarang) we can track them on bugzilla
-01:06 (@hwoarang) on a special tracker
-01:06 (@yngwin) what i propose is to add the new eclass, and mark the old one as deprecated and make a tracker for migration to new eclass
-01:06 (+Pesa) yeah
-01:06 (@tampakrap) ^^nice
-01:06 (+wired) yngwin++
-01:07 (+wired) qt4-v2.eclass?
-01:07 (@hwoarang) nah
-01:07 (@hwoarang) we need a pretty cool name
-01:07 (@hwoarang) :P
-01:07 (@yngwin) we had qt4-ng in mind
-01:07 (@hwoarang) -ng sounds ok
-01:07 (+wired) keep in mind one day we might have another big-bad-ass revision
-01:07 (+wired) lets stick a number in there
-01:07 (@yngwin) yeah, so i'm open for suggestions
-01:07 (@tampakrap) qt4-r1.eclass?
-01:07 (+wired) -r1 isn't bad either
-01:08 (@yngwin) inherit qt4-r1
-01:08 (@hwoarang) nah
-01:08 (@hwoarang) ugly
-01:08 (@hwoarang) :P
-01:08 (@yngwin) i'm not sure i like that
-01:08 (+wired) i prefer qt4-v2
-01:08 (+wired) inherit qt4-v2
-01:08 (kage-ookami) qt4-2nd
-01:08 (@yngwin) qt4-edition2009
-01:08 (@hwoarang) ..
-01:08 (@yngwin) just brainstorming
-01:08 (+spatz) qt4-home_premium
-01:08 (@tampakrap) qt4_pre20090521
-01:08 (+wired) lol
-01:08 (@yngwin) well, that's bikeshedding, can be done tomorrow
-01:09 (+wired) qt4-try2
-01:09 (+wired) :D
-01:09 (@hwoarang) ok
-01:09 (@tampakrap) qt4_thepreviousonewasFAIL
-01:09 (@yngwin) but we agree on principle?
-01:09 (@tampakrap) yes
-01:09 (+wired) i think its the best approach yeah
-01:09 (@hwoarang) ok
-01:09 -!- joost_op [n=joost@86.92.194.222] <- quit ["Leaving"]
-01:09 (+Pesa) i do, if my opinion counts
-01:09 (@yngwin) it does :)
-01:09 (@hwoarang) also Pesa and me are working on eqmake4 patch, to automatically guesses the project name so we can have a more generic src_configure
-01:09 (@yngwin) translation stuff still needs work?
-01:10 (@hwoarang) yes
-01:10 (+Pesa) can be made more generic i think
-01:10 (@hwoarang) i have two ebuilds that I still want to migrate on that
-01:10 (@yngwin) ok, so lets work on it in overlay, and see in a few weeks time or so
-01:10 (@hwoarang) Pesa: i ll add the second patch, then feel free to play  :)
-01:11 (@yngwin) anything about other packages in overlay?
-01:11 (@hwoarang) the current status seems ok
-01:11 (+Pesa) hwoarang: with '.' instead of ${S} though!
-01:11 (@tampakrap) i can take care of live ones
-01:11 (@hwoarang) yes :)
-01:11 (@hwoarang) i ve moved many packages on tree
-01:11 (@hwoarang) and kept the live ones
-01:11 (+Pesa) fine then
-01:12 (@yngwin) what about qtjambi
-01:12 (@yngwin) shouldnt that go to tree as well?
-01:12 (@yngwin) 4.5.0 that is
-01:12 (+Pesa) i added 4.5.0_p1 to the overlay
-01:12 (@hwoarang) does it work?
-01:12 (@hwoarang) or it needs further testing
-01:12 (+Pesa) worksforme :D
-01:12 (@yngwin) it's java, how would i know if it works?
-01:12 (+wired) lol
-01:12 (@yngwin) :p
-01:13 (+wired) yngwin: actually the correct answer would be
-01:13 (@hwoarang) so what can we do with it
-01:13 (+wired) its java, ofcourse not
-01:13 (+Pesa) seriously, it has huge improvements over portage version
-01:13 (+wired) :D
-01:13 (@yngwin) who maintains it in portage again
-01:13 -!- bschindler [n=quassel@77-56-156-71.dclient.hispeed.ch] <- quit [Read error: 110 (Connection timed out)]
-01:14 (@hwoarang) !meta -v qtjambi
-01:14 (Willikins) hwoarang: Package: dev-java/qtjambi Herd: qt, java Maintainer: qt, java
-01:14 (@hwoarang) we do
-01:14 (@hwoarang) :P
-01:14 (+wired) lolz
-01:14 (@dagger) lol ;)
-01:14 (@yngwin) ali_bush it seems from changelog
-01:15 (@yngwin) ok, maybe confer with him
-01:15  -> hwoarang noted
-01:15 (@yngwin) then we can bump
-01:15 (@hwoarang) i ll poke him as long as he is available
-01:15 (@hwoarang) *as soon as
-01:15 (@hwoarang) stupid beer
-01:16 (@yngwin) heh
-01:16 (@jmbsvicetto) ok, I really need to leave now. See you later
-01:16 -!- Guest36992 [n=red@lounge.datux.nl] <- quit [Read error: 60 (Operation timed out)]
-01:16 (@hwoarang) bye bye jmbsvicetto
-01:16 (@yngwin) ok, see you jmbsvicetto
-01:16 -!- sean345 [n=quassel@c-76-105-5-254.hsd1.ca.comcast.net] joins -> #gentoo-kde
-01:16 (+wired) bye jmbsvicetto
-01:16 (@hwoarang) ok i think we are done with the overlay
-01:16 (@yngwin) on to last point?
-01:16 (+Pesa) bye jmbsvicetto
-01:16 (ali_bush_work) you talking to me :)
-01:16 (+spatz) have fun :)
-01:16 (@hwoarang) ah
-01:16 (@hwoarang) there he is
-01:16 (@yngwin) ali_bush_work: yes, we have qtjambi-4.5.0_p1 in overlay
-01:17 (ali_bush_work) cool.  does it work
-01:17 -!- Guest36992 [n=red@lounge.datux.nl] joins -> #gentoo-kde
-01:17 (@hwoarang) lol :)
-01:17 (@yngwin) [00:12:52] <yngwin> it's java, how would i know if it works?
-01:17 (@yngwin) ;)
-01:17 (@yngwin) but Pesa says it does
-01:18 (ali_bush_work) i'll put it on my todo list :)
-01:18 -!- anselmolsm [n=anselmo@200.184.118.130] <- quit [Remote closed the connection]
-01:18 (@yngwin) alright
-01:18 (ali_bush_work) ETC next century
-01:18 (@hwoarang) goodie
-01:18 (@hwoarang) no rush :P
-01:18 (+Pesa) ali_bush_work: yes, demos and examples work, and also qtdesigner integration
-01:18 (@yngwin) we can bump, and let you deal with the bugs :p
-01:19 (@yngwin) but if Pesa says it works, i trust him
-01:19 (+Pesa) ali_bush_work: and there are tons of other improvements
-01:19 (ali_bush_work) ok cool.  I will qa the ebuild just too make sure if follows our standards
-01:20 (@hwoarang) sweet
-01:20 (+Pesa) thanks
-01:20 -!- geo27 [n=quassel@lns-bzn-56-82-255-250-237.adsl.proxad.net] <- quit [No route to host]
-01:20 (@hwoarang) ok last topic
-01:20 (@hwoarang) leader? :/
-01:20 (@yngwin) do we need an elected lead?
-01:20 (@hwoarang) what for
-01:20 (@yngwin) now that we're a fast growing team
-01:21 (@tampakrap) jmbsvicetto is the project leader, scarabeus is KDE HT Lead and yngwin is Qt HT lead
-01:21 (@yngwin) well, i thought i would put it before you
-01:21 (@tampakrap) i think that is enough
-01:21 (@hwoarang) i cant see the reason :)
-01:21 (@yngwin) because i just assumed the position, when no-one was looking
-01:21 (@hwoarang) i am pretty happy with the current situation
-01:22 (@hwoarang) maybe we should discuss it again in July
-01:22 (@yngwin) but if you guys are happy with it
-01:22 (@hwoarang) before we leave
-01:22 (kage-ookami) yngwin: sometimes it takes a person to just assume the position
-01:22 (@yngwin) i know
-01:23 (@hwoarang) so the answer is NO
-01:23 (+spatz) if it works don't fix it
-01:23 (@hwoarang) you ll stay the leader either you like it or not
-01:23 (@yngwin) ok
-01:23 (@hwoarang) </end_of_topic>
-01:23 (+wired) yngwin QT leader woot =]
-01:23 (@scarabeus) :D
-01:23 (@yngwin) </end_of_meeting>
-01:23 (@scarabeus) okey
-01:23 (@scarabeus) :D
-01:23 (@hwoarang) -------------------
-01:23 (+Pesa) :D
-01:23 (@hwoarang) omg
-01:24 (@hwoarang) 3:30 hours
-01:24 (@hwoarang) jesus!
-01:24 (@yngwin) holy mother
-01:24 (+wired) closer to 3 hours actually
-01:24 (+spatz) back to homework :/
-01:24 (+wired) but still!
-01:24  -> yngwin hands out more cookies
-01:24 (+wired) scarabeus: you want log?
-01:24 (@yngwin) wired: CC me as well please
-01:24 (@tampakrap) does it need rendering?
-01:25 (@yngwin) i'll do summary for Qt part
-01:25 (@hwoarang) ohhhhhhhhhhhhhh
-01:25 (@hwoarang) btw
-01:25 (@hwoarang) for those who havent noticed
-01:25 -!- tampakrap topic of #gentoo-kde ->> Gentoo KDE | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
-01:25 (@hwoarang) i ve wrote this guide http://www.gentoo.org/proj/en/desktop/kde/qt4-based-ebuild-howto.xml
-01:25 (@hwoarang) so any additions etc are welcomed
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090618.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090618.txt
deleted file mode 100644
index 96f0650d67..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090618.txt
+++ /dev/null
@@ -1,1064 +0,0 @@
-Note: times are UTC+2
-
-[20:59.03] *** Topic is 'Gentoo KDE | 18.6. @ 19:00 UTC = Meeting [http://dev.gentoo.org/~scarabeus/0906meeting_topics.txt] | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 '
-[20:59.03] *** Set by scarabeus on Thu Jun 18 20:40:41
-[20:59.04] <Pesa> but if you listen, we'll have to kill you
-[20:59.07] <ssuominen> it's custom the ops get to kick everyone except club members out when the meeting starts
-[20:59.08] <Pesa> :P
-[20:59.11] <ssuominen> be ready..
-[20:59.33] <spatz> the meeting starts with a customery kick-banning
-[20:59.54] *** BCMM (n=bcmm@unaffiliated/bcmm) has joined #gentoo-kde
-[21:00.01] <spatz> and when the channel's empty, the discussion can begin
-[21:00.35] <scarabeus> meeting starts ;]
-[21:00.39] <scarabeus> !herd kde
-[21:00.41] <Willikins> (kde) alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, patrick, scarabeus, tampakrap, tgurr
-[21:00.42] <scarabeus> !herd qt
-[21:00.42] <Willikins> scarabeus: (qt) carlo, hwoarang, tampakrap, yngwin
-[21:00.44] <scarabeus> rollcall plz
-[21:00.48] <yngwin> present
-[21:01.16] <scarabeus> tampakrap will be one hour late so his topic is last on the list (FTR)
-[21:01.32] <hwoarang> he might not make it
-[21:01.35] <yngwin> carlo is absent as usual
-[21:01.36] <hwoarang> called me 3 hours ago
-[21:01.41] <hwoarang> hi btw
-[21:02.06] <ayoy> and hi from here :)
-[21:02.13] <hwoarang> haavardw: ping
-[21:02.17] <Pesa> hi hwoarang, yngwin, ayoy
-[21:02.20] *** scarabeus sets mode: +v ABCD
-[21:02.22] <haavardw> hwoarang: pong, I'm here -)
-[21:02.25] <hwoarang> goodie
-[21:02.33] <scarabeus> your recruits? ;]
-[21:02.34] <hwoarang> yngwin: ps, remember to set him up on qting-edge
-[21:02.34] <Pesa> and hi haavardw
-[21:02.41] <haavardw> hi all
-[21:02.46] <scarabeus> i wander one thing
-[21:02.50] <scarabeus> where the ... is the rest
-[21:02.58] <spatz> howdy
-[21:03.01] <hwoarang> aparently only qt is present
-[21:03.08] <yngwin> heh
-[21:03.21] <yngwin> ok, mask kde for removal; done
-[21:03.26] <scarabeus> :D
-[21:03.27] *** BCMM (n=bcmm@unaffiliated/bcmm) Quit (Remote closed the connection)
-[21:03.29] <hwoarang> you failed
-[21:03.29] <Pesa> LOL
-[21:03.31] <yngwin> :p
-[21:03.37] <Pesa> we'll rule the world
-[21:03.43] <hwoarang> meeting's over
-[21:03.43] <scarabeus> bonsaikitten: still arround i assume ;]
-[21:03.51] <yngwin> actually i'm on kde 4.2.4 presently
-[21:03.57] <hwoarang> woooooooooow
-[21:04.03] <hwoarang> big step
-[21:04.05] <yngwin> sabayon
-[21:04.07] * alexxy here
-[21:04.08] *** scarabeus sets mode: +v Sput
-[21:04.22] *** hwoarang sets mode: +v ayoy
-[21:04.24] *** scarabeus sets mode: +v lxnay|two
-[21:04.29] *** hwoarang sets mode: +v haavardw
-[21:04.42] *** hwoarang sets mode: +v Pesa
-[21:04.43] *** yngwin sets mode: +v hwoarang
-[21:04.51] <yngwin> ;)
-[21:05.04] * scarabeus gives them 5 minutes, then he will be seriously unhappy
-[21:05.11] <hwoarang> lol
-[21:05.41] <hwoarang> who do we miss?
-[21:05.43] <hwoarang> jorge?
-[21:05.46] <hwoarang> tampakrap_: is off
-[21:05.51] <hwoarang> bonsaikitten: slacking
-[21:05.54] <yngwin> !herd kde
-[21:05.56] <Willikins> yngwin: (kde) alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, patrick, scarabeus, tampakrap, tgurr
-[21:05.57] <hwoarang> so pretty much everybody is here
-[21:05.58] <reavertm> I almost forgot
-[21:06.03] <scarabeus> dagger
-[21:06.05] <scarabeus> reavertm: hello
-[21:06.11] <reavertm> hi scarabeus
-[21:07.03] <scarabeus> hwoarang: well specialy when we vote on first topic it would be damn nice to have majority of kde devs here
-[21:07.17] <hwoarang> where is the agenda
-[21:07.21] <scarabeus> topic
-[21:07.27] <yngwin> so for those who hadnt noticed yet, we have two new qt recruits present: ayoy and haavardw
-[21:07.36] *** Skim[ihz] (n=skim@skim.static.corbina.ru) has joined #gentoo-kde
-[21:07.40] <scarabeus> yngwin: voice them
-[21:07.50] <yngwin> hwoarang already did
-[21:07.51] <spatz> they are voiced
-[21:07.56] <scarabeus> ah
-[21:07.57] <scarabeus> :]
-[21:07.58] <hwoarang> of course
-[21:07.59] <scarabeus> didnt look :]
-[21:08.00] * haavardw can talk
-[21:08.04] <hwoarang> bla bla
-[21:08.10] <scarabeus> ayoy, haavardw: then welcome guys :]
-[21:08.17] <ayoy> thank you!
-[21:08.20] <ayoy> :)
-[21:08.24] <haavardw> thanks -)
-[21:08.33] <reavertm> http://archives.gentoo.org/gentoo-desktop/msg_1ef792a71171a444d60ecb870a27e9f3.xml <- agenda
-[21:08.41] <hwoarang> http://dev.gentoo.org/~scarabeus/0906meeting_topics.txt
-[21:08.45] <hwoarang> just for the record
-[21:09.02] <scarabeus> yes
-[21:09.09] <hwoarang> scarabeus: we can change the topics order
-[21:09.21] <scarabeus> hwoarang: yes we can
-[21:09.23] <hwoarang> until kde devs are here
-[21:09.34] <scarabeus> but kde3 is last or at least until tampakrap show up
-[21:09.35] <hwoarang> we can start with qt topics if you like
-[21:09.49] <hwoarang> ok scarabeus . but as I said he mgiht not make it
-[21:09.49] <hwoarang> :/
-[21:10.04] <scarabeus> then wired will be his replacement
-[21:10.08] <hwoarang> sweet
-[21:10.11] <hwoarang> where is he
-[21:10.11] <scarabeus> he hopefully tracked him
-[21:10.17] <hwoarang> wired: stupid boy
-[21:10.29] <hwoarang> ping pong
-[21:10.31] <spatz> i foresee that they blame the late announcement :p
-[21:10.37] <wired> im here
-[21:10.39] <hwoarang> excuses
-[21:10.41] <wired> for some weird reason
-[21:10.43] <wired> :p
-[21:10.53] <hwoarang> ok shall we start with qt stuff then?
-[21:11.11] <scarabeus> ok lets start with the qt3 apps first
-[21:11.14] <reavertm> I'm fine with this
-[21:11.18] <scarabeus> and ftr i am really not happy
-[21:11.34] <hwoarang> slackers
-[21:11.38] <hwoarang> ok what about the qt3 apps?
-[21:11.49] <reavertm> btw, who's going to vote on kdeprefix?
-[21:11.55] <hwoarang> kde project devs
-[21:11.58] <hwoarang> i guess
-[21:11.59] <scarabeus> reavertm: devs, including you
-[21:12.09] * alexxy
-[21:12.13] <scarabeus> reavertm: because you are one of few who can work on it
-[21:12.30] * alexxy gonna vote for masking it
-[21:12.33] <reavertm> well, last time it was not the case :P
-[21:12.36] <scarabeus> hwoarang: so lets start with second topic now
-[21:12.42] <hwoarang> ok
-[21:12.53] <hwoarang> yngwin: ping pong
-[21:13.09] <yngwin> kde3 is scheduled to be removed early next year, right?
-[21:13.15] <scarabeus> yes
-[21:13.20] <scarabeus> to some special overaly
-[21:13.25] <scarabeus> so lets create one common overlay
-[21:13.26] <yngwin> and kde3 is the biggest consumer of qt3
-[21:13.29] <scarabeus> kde3 and qt3 crap
-[21:13.36] <scarabeus> instead of just ripping it off
-[21:13.40] <yngwin> i agree
-[21:13.44] <scarabeus> and users can maintain themselves if they want
-[21:13.44] <hwoarang> fine by me
-[21:13.48] <scarabeus> otherwise we can throw it
-[21:13.59] <reavertm> I wouldn't mind creating special overlay for qt4 and kde4 crap :P - to keep them away from main tree "{
-[21:14.11] <hwoarang> oooh flamebite
-[21:14.13] <spatz> what about kde3/qt3 apps not yet ported to kde4/qt4?
-[21:14.14] <scarabeus> ok whom would update the kde team page reffering to the policy
-[21:14.24] <scarabeus> spatz: problematic, but hell for maintaining
-[21:14.25] <hwoarang> spatz: we dont care :)
-[21:14.34] <scarabeus> yngwin: hwoarang ^
-[21:14.38] <scarabeus> the update... :]
-[21:14.40] <spatz> but some are widely used, like k3b
-[21:14.42] <hwoarang> scarabeus: do we need to update it?
-[21:14.47] <hwoarang> for what
-[21:14.58] <spatz> by users
-[21:15.06] <tanderson> ping :)
-[21:15.08] <reavertm> some of them fail to build with libpcre[-static-libs]
-[21:15.09] <yngwin> i would like to propose that we officially discourage further usage of qt3: dont introduce new qt3 based apps, prefer qt4 over qt3
-[21:15.11] <Pesa> i hope k3b will see a stable release before the end of this year
-[21:15.12] <scarabeus> hwoarang: just that other knows
-[21:15.17] <hwoarang> spatz: k3b has already a kde4 version
-[21:15.19] <hwoarang> _alpha
-[21:15.28] <scarabeus> yngwin: good idea
-[21:15.32] <hwoarang> yngwin: +1
-[21:15.37] <scarabeus> spatz: in 6 months ;]
-[21:15.49] <hwoarang> tanderson: ?
-[21:15.57] <yngwin> i think qt3 useflag is enabled by desktop profile? that should be removed
-[21:16.18] <scarabeus> also good idea, but since when
-[21:16.21] <tanderson> Any objections to me patching a kde 3 ebuild with fixes for the .desktop file ?
-[21:16.27] <scarabeus> tanderson: enjoy
-[21:16.28] <tanderson> or JustDoIt ? :)
-[21:16.37] <scarabeus> tanderson: open kde.gentoo.org
-[21:16.42] <scarabeus> tanderson: search for CODE file
-[21:16.45] <scarabeus> tanderson: read it
-[21:16.48] <scarabeus> tanderson: answer is there
-[21:16.59] * bonsaikitten present
-[21:17.03] <scarabeus> yngwin: aka when we switch the discouraging of qt3 useflag
-[21:17.17] <scarabeus> it can be even now but apps will be gone in the feb of 2010
-[21:17.21] <yngwin> i'd say immediately
-[21:17.33] <hwoarang> still we need to make the transission smooth
-[21:17.38] <tanderson> scarabeus: aah ok
-[21:17.40] <hwoarang> i failed on spelling
-[21:17.41] <Skim[ihz]> hmmm
-[21:17.51] <tanderson> scarabeus: oh, did I interrupt your meeting?
-[21:17.52] <hwoarang> so as yngwin said , immediately
-[21:17.57] <scarabeus> tanderson: smart boy
-[21:18.03] *** dipogon (n=dipogon@84.249.84.164) Quit (Remote closed the connection)
-[21:18.09] <scarabeus> tanderson: ;]
-[21:18.12] <Pesa> qt3 is enabled in /usr/portage/profiles/targets/desktop/make.defaults
-[21:18.13] <tanderson> scarabeus: I'm sorry, I'd have taken it to a query if I had known
-[21:18.22] <scarabeus> tanderson: no prob :]
-[21:18.56] <scarabeus> hwoarang: ok since you two agree just do it, i wrote it in summary :]
-[21:19.02] <hwoarang> ok
-[21:19.09] <yngwin> afaik profile changes need announcement/discussion on dev ml, so i'll draft up something
-[21:19.18] <hwoarang> thanks yngwin
-[21:19.34] <Skim[ihz]> it is strange, but I can't add my own language in system settings... l10n is installed, kde installed without "kdeprefix", some software is translated, but I still can't add my own language.... ;(
-[21:19.40] <hwoarang> Skim[ihz]: meeting time
-[21:19.58] * scarabeus consider +m ;]
-[21:20.03] <Skim[ihz]> -_-
-[21:20.07] <scarabeus> we can voice pple if they query us
-[21:20.09] <Skim[ihz]> sorry
-[21:20.10] <wired> stop considering
-[21:20.17] <wired> just do it already
-[21:20.18] *** scarabeus sets mode: +m
-[21:20.20] <wired> :D
-[21:20.22] <scarabeus> should be done
-[21:20.25] <hwoarang> ok
-[21:20.33] <hwoarang> end of story
-[21:20.44] <hwoarang> scarabeus: moving forward?
-[21:20.48] <scarabeus> okey
-[21:20.51] <hwoarang> kde4 stabilization?
-[21:21.01] <scarabeus> bonsaikitten: patrick since you are here, can we talk about the pykde?
-[21:21.10] <bonsaikitten> we can
-[21:21.21] *** gengor (n=gengor@gentoo/developer/gengor) has left <type 'buffer'>
-[21:21.41] <spatz> you agreed to deprecate qt3 as of now, so i assume discussion on moving current packages to an overlay will be postponed?
-[21:21.42] <scarabeus> it is 5th topic for those whom wonder
-[21:21.50] <reavertm> scarabeus: voice tanderson
-[21:21.52] <scarabeus> spatz: yes
-[21:21.54] *** scarabeus sets mode: +v tanderson
-[21:22.32] <scarabeus> bonsaikitten: ok did you find any solution about the collisions in site-packages?
-[21:22.42] <bonsaikitten> not yet, but I haven't spent much time on it
-[21:22.54] <scarabeus> unprefixing of pykde is fine with us, but the issue is also in plasma-workspace now
-[21:22.58] <scarabeus> or plasma-addons not sure now
-[21:23.11] <bonsaikitten> either we allow to use a newer pykde with an older slotted kde (does that work?)
-[21:23.20] <reavertm> (with python USE flag only)
-[21:23.24] <bonsaikitten> or we try to move the pykde package to versioned directories
-[21:23.36] <reavertm> it's all depending on kdeprefix status
-[21:23.37] <bonsaikitten> but then packages trying to use it will most likely need some patching
-[21:23.59] <scarabeus> bonsaikitten: cant we somehow eselect correct site modules for what kde we start
-[21:24.01] <reavertm> (no kdeprefix - no pytkde issue)
-[21:24.20] *** pgega (n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk) Quit (Client Quit)
-[21:24.22] <bonsaikitten> scarabeus: potentially yes, but might be very fragile
-[21:24.34] <yngwin> eselect is not the answer here
-[21:24.43] <scarabeus> and as reaver say, if we agree we can just mask kdeprefix flag, which will be voted
-[21:24.50] <scarabeus> because without this the kde cant be stabled
-[21:24.55] <scarabeus> the collision would piss users
-[21:24.56] <reavertm> anyway - either unslot or eselect - pykde4-9999 is likely to not work very well with kdelibs-4.2
-[21:24.57] <yngwin> someone still might want to run amarok1 in kde4 for example
-[21:25.22] *** haavardw (n=haavardw@cm-84.208.110.202.getinternet.no) Quit (Read error: 104 (Connection reset by peer))
-[21:25.23] <bonsaikitten> right, so we need versioned dirs in site-packages
-[21:25.31] <bonsaikitten> how many packages depend on pykde ?
-[21:25.40] <scarabeus> everything in kde with use python
-[21:25.49] <reavertm> yngwin: I don't see it relevant (amarok1)
-[21:25.58] <reavertm> (as it uses kdelibs3)
-[21:26.06] <yngwin> and pykde3
-[21:26.07] <bonsaikitten> I'm aware of marble plasma-workspace
-[21:26.10] <bonsaikitten> any others?
-[21:26.10] *** haavardw (n=haavardw@cm-84.208.110.202.getinternet.no) has joined #gentoo-kde
-[21:26.26] <reavertm> printing stuff
-[21:26.30] <reavertm> (upcoming in 4.3)
-[21:26.50] <reavertm> + guidance-power-manager (extragear)
-[21:27.01] <bonsaikitten> ok, tolerable amount to patch
-[21:27.19] *** pgega (n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk) has joined #gentoo-kde
-[21:27.29] <reavertm> I don't worry about API differences here, rather ABI issues
-[21:27.34] *** scarabeus sets mode: +v haavardw
-[21:28.08] <bonsaikitten> reavertm: the only thing that will suffer is the detection by other packages afaict, so we will have to frickel them to accept the changes
-[21:28.22] <reavertm> besides nobody really tried yet mixing new pykde4 with 'old' apps (and we're preventing it so far)
-[21:28.22] <bonsaikitten> so if we have to tweak 5 packages that's an acceptable amount of work
-[21:28.30] *** Phlogi_ (n=quassel@236-60.77-83.cust.bluewin.ch) Quit (Read error: 60 (Operation timed out))
-[21:29.12] <reavertm> (I guess we don't plan to support older pykde4 with newer apps - so just SLOT deps would be dropped if any)
-[21:29.18] *** bertodsera (n=quasseul@95.133.248.44) has joined #gentoo-kde
-[21:29.45] <bonsaikitten> anyone willing to help?
-[21:29.50] <yngwin> maybe you should test backwards compatibility of newer pykde4 then, as that would prevent the need for patching
-[21:29.56] <reavertm> I did it partially in local branch
-[21:30.43] <jmbsvicetto> Hi
-[21:30.47] <wired> hey boss
-[21:30.49] <jmbsvicetto> I'm sorry for being late
-[21:31.16] <bonsaikitten> yngwin: right, that will be annoying to test :)
-[21:31.27] <scarabeus> bonsaikitten: so you and reaver will do it
-[21:31.43] *** Phlogi (n=quassel@10-175.0-85.cust.bluewin.ch) has joined #gentoo-kde
-[21:31.49] <scarabeus> ?
-[21:31.52] *** scarabeus sets mode: +v Phlogi
-[21:31.59] <bonsaikitten> *sigh* :)
-[21:32.06] <bonsaikitten> I'll try to have a look on the weekend
-[21:32.07] <scarabeus> i take it as yes :]
-[21:32.44] <scarabeus> ok
-[21:32.55] <scarabeus> anything else to this topic?
-[21:33.07] <scarabeus> jmbsvicetto: o hi, i missed ya ;]
-[21:34.09] <scarabeus> ok, since there wont be more devs here around and since alexxy has pretty late hour i would like to go with his kdeprefix stuff
-[21:34.12] <scarabeus> alexxy: please
-[21:34.22] <scarabeus> the topic Solving the final question about kdeprefix.
-[21:34.45] <alexxy> well
-[21:35.34] <tanderson> One thing: I as a amd64 person won't let kde4 go stable on my architecture with kdeprefix available to my users
-[21:35.49] <reavertm> :)
-[21:36.01] <alexxy> he he =)
-[21:36.03] <tanderson> It causes far too many problems
-[21:36.08] <bonsaikitten> tanderson: don't make us go behind your back ;)
-[21:36.18] <reavertm> you even don't know about one problem I know of :P
-[21:36.20] <alexxy> so kdeprefix will cause many headache to users
-[21:36.27] <hwoarang> it does already
-[21:36.28] <tanderson> bonsaikitten: to whom?
-[21:36.29] <alexxy> so lets mask it!
-[21:36.29] <reavertm> (qt4 bug related to plugin loader)
-[21:36.29] <alexxy> =)
-[21:36.35] <scarabeus> also the python issue
-[21:36.42] <scarabeus> plugin loader i personaly HATE
-[21:36.49] <bonsaikitten> tanderson: well, let me put it this way - you're not the only one on amd64 with a commit access ;)
-[21:37.01] <alexxy> bonsaikitten: if we will mask it
-[21:37.12] <scarabeus> user can still unmask it
-[21:37.17] <alexxy> people who want to use still can do it after unmasking
-[21:37.19] <scarabeus> and we already state it deemed evil
-[21:37.20] <tanderson> bonsaikitten: I think I represent the others on my team
-[21:38.01] <scarabeus> :]
-[21:38.03] <jmbsvicetto> scarabeus: I noticed in the back log ;)
-[21:38.13] <scarabeus> ok i think we should vote on it
-[21:38.19] <scarabeus> and if the vote will be keep unmasked
-[21:38.30] <scarabeus> the voting devs must promise to work on the issues with +kdeprefix
-[21:38.34] <scarabeus> aka they will focus on them
-[21:38.42] <scarabeus> not that I with -kdeprefix would fix them
-[21:38.51] <scarabeus> objections?
-[21:39.06] <jmbsvicetto> tanderson: You're forgetting that you can even mask a use flag in a profile ;)
-[21:39.20] <jmbsvicetto> tanderson: so you could always stable kde4 *without* kdeprefix
-[21:39.34] <tanderson> jmbsvicetto: I am aware of that
-[21:39.37] <reavertm> tanderson: and we're not voting on removing kdeprefix - but masking in profiles
-[21:39.51] <reavertm> (as most of devs will unmask it anyway)
-[21:39.51] <yngwin> why not just remove it?
-[21:40.01] <tanderson> I never mentioned removing kdeprefix! I mentioned "being available to my users"
-[21:40.04] <scarabeus> because we use live and stable right now
-[21:40.04] <tanderson> :)
-[21:40.10] <scarabeus> yngwin: aside
-[21:40.11] <jmbsvicetto> scarabeus / reavertm: what issues do you want to fix by masking it?
-[21:40.15] <scarabeus> with help of +kdeprefix
-[21:40.27] <jmbsvicetto> The pykde conflict and?
-[21:40.28] <scarabeus> jmbsvicetto: update strategy, collisions, broken plugins, user confusion
-[21:40.39] <reavertm> jmbsvicetto: just decrease ^^^ impact on average users
-[21:41.08] <jmbsvicetto> ok, I've became tired of fighting this war
-[21:41.23] <jmbsvicetto> I'll let anyone else take this one if they want
-[21:41.39] <scarabeus> i would more of like to convince you rather than tire you :]
-[21:41.44] <jmbsvicetto> But, just for the record, my +kdeprefix laptop is working fine :P
-[21:42.06] <scarabeus> jmbsvicetto: yeah because me and reaver spent quite stuff on prefix stuff, and it is still not 100%
-[21:42.07] <scarabeus> :]
-[21:42.16] <jmbsvicetto> scarabeus: As I've said before, the real solution is to fix upstream build system to allow co-existence of different versions side by side
-[21:42.18] <scarabeus> fist stuff was to be time
-[21:42.23] <reavertm> jmbsvicetto: you're free to go with +kdeprefix if you fix qt plugin loader to not pick oxygen.so from current kde session (and plugin cache stored in .config/Trolltech.conf) instead of using kde4-config --qtplugins
-[21:42.25] <scarabeus> yes on that i agree
-[21:42.41] <scarabeus> jmbsvicetto: well we wont remove it
-[21:42.42] <reavertm> jmbsvicetto: that's no longer build system issue
-[21:42.44] <scarabeus> just mask in profile
-[21:42.47] <scarabeus> anyone can enable it
-[21:42.50] <jmbsvicetto> scarabeus: this way someone might feel "pressured" to start that work ;)
-[21:42.58] <reavertm> they can coexist
-[21:43.09] <reavertm> there's problem with plugin loader
-[21:43.14] <scarabeus> jmbsvicetto: yeah it might motivate pple to work on it so it will get unmasked
-[21:43.14] <jmbsvicetto> reavertm: I mean having them on the same dir, not on separate prefixes
-[21:43.17] <reavertm> and of course with .desktop files
-[21:43.33] <scarabeus> ok guys we are far away from the subject
-[21:43.35] <reavertm> (they all have relative paths in Exec=)
-[21:43.36] <scarabeus> it is mask/not mask
-[21:43.46] * jmbsvicetto abstains
-[21:44.01] <reavertm> in current state kdeprefix is NO GO
-[21:44.21] <reavertm> one can not like it, but this is the fact
-[21:44.25] <scarabeus> jmbsvicetto: you cant you are lead :D
-[21:44.31] <scarabeus> ok please
-[21:44.34] <scarabeus> !herd kde vote
-[21:44.39] <scarabeus> !herd kde
-[21:44.40] <jmbsvicetto> bonsaikitten: what about you?
-[21:44.48] <scarabeus> i hate that bot
-[21:44.50] <scarabeus> seriously
-[21:44.51] <ABCD> scarabeus: Willikins doesn't have +v
-[21:44.53] <jmbsvicetto> scarabeus: give me a minute
-[21:44.55] <wired> rotfl
-[21:44.57] *** scarabeus sets mode: +v Willikins
-[21:44.57] *** jmbsvicetto sets mode: +v wired
-[21:44.57] <reavertm> I've spent already too many hours working on it - if anyone doesn't like it, I'll be happy to pass the work to him
-[21:44.59] <scarabeus> !herd kde
-[21:44.59] <Willikins> (kde) alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, patrick, scarabeus, tampakrap, tgurr
-[21:45.04] <scarabeus> O;]
-[21:45.13] <jmbsvicetto> scarabeus: Yeah, blame the bot ;)
-[21:45.15] <bonsaikitten> jmbsvicetto: I prefer kdeprefix, but I don't care enough to fight for it
-[21:45.20] <jmbsvicetto> ok
-[21:45.26] <scarabeus> i vote the mask
-[21:45.39] <jmbsvicetto> scarabeus: How do you plan to mask it?
-[21:45.40] <alexxy> i vote for mask this crap!
-[21:45.45] * wired votes on his dev bug
-[21:45.48] <wired> :D
-[21:45.50] <alexxy> jmbsvicetto: via use.mask
-[21:45.55] <scarabeus> globaly in profile in use.mask
-[21:46.00] <jmbsvicetto> base/use.mask ?
-[21:46.02] <reavertm> I vote to mask it (for now)
-[21:46.03] <scarabeus> yes
-[21:46.14] <jmbsvicetto> Can users unmask it in /etc/portage ?
-[21:46.18] <scarabeus> yes
-[21:46.19] <yngwin> yes
-[21:46.21] <reavertm> as it should have been done at the same begin
-[21:46.24] <jmbsvicetto> iirc, last time one would have to do it in profiles/
-[21:46.28] <jmbsvicetto> ok
-[21:46.34] <yngwin> so it would still be available for those who really want it
-[21:46.40] <jmbsvicetto> I can live with the mask then
-[21:46.56] <ABCD> jmbsvicetto: to unmask, put "-kdeprefix" in /etc/portage/profiles/use.mask
-[21:47.15] <jmbsvicetto> ABCD: ok, thanks
-[21:47.15] <scarabeus> ok somebody around whom didnt vote?
-[21:47.22] <reavertm> ABCD: ssshh, users will hear it :P
-[21:47.24] * jmbsvicetto notices Patrick didn't
-[21:47.25] <yngwin> just make sure the whole thing is properly documented
-[21:47.46] <scarabeus> well the guide will be updated, at least tampakrap_ promised he will do it
-[21:48.00] <Pesa> ABCD: it's profile, not profiles, IIRC
-[21:48.07] <ABCD> ...right
-[21:48.17] <ABCD> I blame my IRC client
-[21:48.17] <scarabeus> bonsaikitten: so say mask/notmask plz
-[21:48.25] <Pesa> ;)
-[21:48.50] <reavertm> directory name is profiles, but calling it 'profile' is common :P
-[21:48.57] <bonsaikitten> scarabeus: abstain
-[21:49.04] *** himikof_ (n=himikof@129.167.249.ozerki.net) Quit (Read error: 104 (Connection reset by peer))
-[21:49.04] <scarabeus> :DDDD
-[21:49.06] <ABCD> reavertm: directory name is profie - I just checked
-[21:49.06] <scarabeus> ok
-[21:49.14] <ABCD> profile*
-[21:49.18] *** himikof_ (n=himikof@129.167.249.ozerki.net) has joined #gentoo-kde
-[21:49.23] <reavertm> (ah, you mean the one in /etc/portage)
-[21:49.28] <Pesa> yes
-[21:49.34] <Pesa> it's profile
-[21:49.37] <scarabeus> ok then it will be masked in profiles
-[21:49.38] <reavertm> nm, so results?
-[21:49.40] <scarabeus> per vote
-[21:49.42] <reavertm> great :P
-[21:49.58] <scarabeus> alexxy: please do the change and according documentation update in the guide
-[21:50.19] <tanderson> sweet
-[21:50.31] <tanderson> Now I can stable kde with a clear conscience
-[21:50.32] <alexxy> he he =)
-[21:50.41] <reavertm> there should be information. about being unable to load oxygen.so and the need of wiping ~/.config/Trolltech.conf
-[21:50.57] <alexxy> so tommorow i'll mask it via profile
-[21:51.03] <scarabeus> alexxy: okey
-[21:51.05] <alexxy> and update guide
-[21:51.06] <alexxy> =)
-[21:51.10] <scarabeus> so this topic is done :]
-[21:51.17] * alexxy realy tired and gonna sleep
-[21:51.24] <scarabeus> next one because we ocupied 2 in the row is for qt herd
-[21:51.29] <scarabeus> topic: Handle the PyQt3 qscintilla dependencies
-[21:51.31] <reavertm> (maybe remove all traces of kdeprefix from guide :)
-[21:51.33] <scarabeus> alexxy: gn
-[21:51.44] <scarabeus> yngwin: hwoarang ^
-[21:51.49] <yngwin> what about it?
-[21:51.56] <scarabeus> it is your topic
-[21:51.58] <hwoarang> messy
-[21:51.59] <yngwin> no
-[21:51.59] <alexxy> gn =)
-[21:52.09] <Pesa> i guess the problem is sip and PyQt-3?
-[21:52.11] <yngwin> nn alexxy
-[21:52.16] <hwoarang> nn alexxy
-[21:52.18] <hwoarang> Pesa: no
-[21:52.27] <hwoarang> pyqt3 requires qscintilla-python[-qt4]
-[21:52.30] <yngwin> so what is the problem?
-[21:52.36] <hwoarang> whilst Pyqt4 requires qscintilla-python[qt4]
-[21:52.41] <yngwin> no it doesnt
-[21:52.47] <hwoarang> sorry?
-[21:52.48] <reavertm> :)
-[21:53.05] <yngwin> PyQt4 does not hard depend on qscintilla
-[21:53.15] <Pesa> indeed
-[21:53.16] <reavertm> the other way around
-[21:53.30] <reavertm> if any..
-[21:53.53] <yngwin> if some app needs qscintilla-python[qt4], yes then there will be a blocker
-[21:54.07] *** SaCu (n=quassel@213-172-122-045.dsl.aktivanet.de) has joined #Gentoo-KDE
-[21:54.08] <hwoarang> this blocker does not exist right now
-[21:54.47] <yngwin> sort of, as you can only have qt4 or -qt4 set on qscintilla-python
-[21:54.55] <Pesa> so the problem is that you can't have both qt3 and qt4 qscintilla installed?
-[21:55.00] <hwoarang> ye
-[21:55.01] <yngwin> indeed
-[21:55.31] <hwoarang> adding qscintilla-python[-qt4] on PyQt
-[21:55.37] <hwoarang> creates a kind of mess
-[21:55.44] <yngwin> meaning you can only have PyQt and PyQt4 side by side as long as nothing needs qscintilla-python[qt4]
-[21:55.47] <hwoarang> well , a mess that users dont get it
-[21:55.51] <hwoarang> yes yngwin
-[21:56.17] *** wilder (n=quassel@host126-104-dynamic.21-87-r.retail.telecomitalia.it) has joined #gentoo-kde
-[21:56.22] <spatz> now that qt3 is removed this should happen less frequently
-[21:56.36] <yngwin> it's not removed
-[21:56.46] <hwoarang> spatz: this wont happen until 2010
-[21:56.49] <spatz> it will be soon, i mean
-[21:56.59] <hwoarang> we will remove qt3 use flag from desktop profile and that is all
-[21:57.05] <spatz> removed from desktop profile
-[21:57.17] <yngwin> ok
-[21:57.28] <hwoarang> but still , the blocker is there
-[21:57.34] <hwoarang> users can have qt3 on make.conf
-[21:58.24] <reavertm> what's the problem here? python bindings collision?
-[21:58.41] <reavertm> qt3 itself resides in separate prefix than qt4
-[21:58.52] <Pesa> no
-[21:58.54] <Pesa> qscintilla-python is fine
-[21:58.55] <yngwin> you can build qscintilla-python only for qt3 OR qt4
-[21:59.01] <Pesa> the problem is qscintilla iirc
-[21:59.11] <reavertm> it's buildsystem doesn't allow that or what?
-[21:59.28] <Pesa> file collisions
-[21:59.48] <Pesa> the buildsystem is simply not designed to do that
-[22:00.03] <scarabeus> adjust the build system
-[22:00.04] <scarabeus> simple
-[22:00.04] <yngwin> it may indeed by qscintilla itself, not the python bindings
-[22:00.17] <yngwin> scarabeus: patches welcome
-[22:00.33] <scarabeus> guys it is your bug :D
-[22:00.39] <reavertm> (a'ka gfy :)
-[22:00.43] <yngwin> then i say: mask for removal :p
-[22:01.15] <yngwin> it's qt3, it's deprecated, i dont want to waste time on it
-[22:01.28] <scarabeus> yngwin: well you are the boss
-[22:01.34] <scarabeus> yngwin: and if hwoarang agree... :]
-[22:02.07] <hwoarang> a real day issue is having amarok-1.4 and eric4
-[22:02.20] <hwoarang> this sounds to me like the most common blocker
-[22:02.25] <yngwin> there are just a few apps that use PyQt-3, most importantly amarok:3.5[python]
-[22:02.28] *** jefferai (n=quassel@amarok/developer/mitchell) has joined #gentoo-kde
-[22:02.30] <hwoarang> yes
-[22:02.38] <hwoarang> amarok is the big pain atm
-[22:02.48] <hwoarang> and many many ppl are using it
-[22:03.02] <scarabeus> and what for are the python bindings
-[22:03.10] <yngwin> scripts i suppose
-[22:03.12] *** scarabeus sets mode: +v jefferai
-[22:03.12] <hwoarang> scripts afaik
-[22:03.28] <scarabeus> jefferai: by any chance you know how important are python bindings in amarok 1?
-[22:03.32] <jmbsvicetto> hwoarang: amarok-1.4 can be deprecated after we get amarok-2 marked stable
-[22:03.43] <yngwin> that will take a while
-[22:03.48] <hwoarang> indeed
-[22:03.51] <jefferai> scarabeus: there are python bindings in amarok 1?
-[22:03.59] <hwoarang> :D
-[22:04.20] <scarabeus> guys this is statement from upstream dev
-[22:04.21] <scarabeus> :D
-[22:04.28] <yngwin> so maybe we can mask python useflag in amarok-1* ?
-[22:04.30] <scarabeus> so i think when they dont care why should we :P
-[22:04.37] <jefferai> well, I'd have to ask
-[22:04.42] <scarabeus> yngwin: yep that i was thinking about
-[22:04.43] <jefferai> the fact that I'm not aware of them doesn't mean...
-[22:05.03] <wired> jefferai: too late :P
-[22:05.08] <jefferai> heh
-[22:05.10] <hwoarang> python masking sounds good to me
-[22:05.12] <spatz> that'll get more users annoyed than having problems with qscintilla, imo
-[22:05.16] *** etix (n=etix@videolan/developer/etix) Quit (Remote closed the connection)
-[22:05.18] *** etix (n=etix@nala.l0cal.com) has joined #gentoo-kde
-[22:05.27] <jmbsvicetto> jefferai: too late, python use flag has already been taken to the alley and beaten up^Dmasked ;)
-[22:05.30] <yngwin> or have the useflag renamed and disabled by default
-[22:05.46] <yngwin> as globally python is enabled by profile
-[22:05.48] <jefferai> what's this for?
-[22:06.14] <scarabeus> jefferai: some bindings probably :]
-[22:06.19] <scarabeus> hopefully just bindings
-[22:06.30] <jefferai> oh
-[22:06.31] <yngwin> jefferai: we have a conflict between dependencies of PyQt3 and PyQt4, and amarok-1 is the biggest consumer of PyQt3 it seems
-[22:06.33] <jefferai> webcontrol
-[22:06.42] <jefferai> bah
-[22:06.46] <jefferai> I don't know of anyone using it
-[22:06.50] <jefferai> at least, that I've ever heard
-[22:07.02] <jefferai> it's some random script that allows web control of Amarok -- I guess
-[22:07.17] *** genewbie (n=genewbie@cpe-76-172-51-77.socal.res.rr.com) has joined #gentoo-kde
-[22:07.17] <jefferai> take a look in the ebuild -- just make sure you keep that rm for the webcontrol script in there
-[22:07.24] <jefferai> so that people don't file bugs asking why it doesn't work/run
-[22:08.08] <scarabeus> we are still on the qscintilla topic? ;P
-[22:08.23] <yngwin> yes
-[22:08.35] <scarabeus> :]
-[22:08.36] <scarabeus> okey
-[22:08.51] *** pgega (n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk) Quit (Client Quit)
-[22:09.04] *** pgega (n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk) has joined #gentoo-kde
-[22:09.14] <yngwin> so i propose useflag s/python/webcontrol/ in amarok-1* ebuilds
-[22:09.43] <yngwin> jmbsvicetto: ^
-[22:09.53] <jmbsvicetto> yngwin: I'd suggest dropping the python flag and removing the scrpit
-[22:09.55] <jmbsvicetto> script*
-[22:10.07] <jefferai> either way
-[22:10.24] <jmbsvicetto> yngwin: I think we should start hinting that users should start moving to amarok-2
-[22:10.45] <scarabeus> yeah 2.1 is already usable on same level i think
-[22:10.55] <yngwin> as long as it's not stable...
-[22:11.28] <scarabeus> it will be next topic
-[22:11.28] <scarabeus> :D
-[22:11.36] <scarabeus> just finish with this one
-[22:11.40] <yngwin> anyway, that will make things easier
-[22:12.18] <yngwin> with that one done, what do we think of mutual blocking of PyQt and PyQt4 to prevent portage tripping over the deeper deps issue?
-[22:12.28] *** gengor (n=gengor@gentoo/developer/gengor) has joined #gentoo-kde
-[22:12.37] <scarabeus> yep that is good idea
-[22:12.40] <jmbsvicetto> yngwin: what apps will that mask?
-[22:12.42] <scarabeus> the block between them
-[22:12.54] <Pesa> sorry guys, my connection is lagging a lot
-[22:12.57] <jmbsvicetto> s/mask/cause slot blocks/
-[22:13.00] <yngwin> it won't mask anything, just force users to choose
-[22:13.15] <jmbsvicetto> yeah, I meant what apps will be affected by that
-[22:13.28] <jmbsvicetto> !rdep PyQt
-[22:13.29] <Willikins> jmbsvicetto: Too many packages have reverse RDEPEND on dev-python/PyQt, go to http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/PyQt instead.
-[22:13.30] <yngwin> !rdep PyQt
-[22:13.30] <jmbsvicetto> !rdep PyQt4
-[22:13.31] <Willikins> jmbsvicetto: Too many packages have reverse RDEPEND on dev-python/PyQt4, go to http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/PyQt4 instead.
-[22:13.31] <Willikins> yngwin: Too many packages have reverse RDEPEND on dev-python/PyQt, go to http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/PyQt instead.
-[22:13.37] <yngwin> :)
-[22:13.44] *** tbeadle (n=quassel@division.aa.arbor.net) Quit (Client Quit)
-[22:13.55] <jmbsvicetto> yngwin: sorry, feeling lazy today ;)
-[22:14.06] <yngwin> kelogviewer, releaseforge, kanyremote
-[22:14.07] <scarabeus> no important crap expect amarok i think
-[22:14.25] <jmbsvicetto> hmm, hplip :\
-[22:14.36] <yngwin> hplip also has qt4 option
-[22:14.49] <ABCD> hplip has qt4 option (and I have it installed, so I know it works)
-[22:14.58] <jmbsvicetto> yeah, sorry just noticed it
-[22:15.02] <spatz> i think there's a bug about the new hplip version not really having qt3 support
-[22:15.23] <scarabeus> he he
-[22:15.24] <scarabeus> :D
-[22:15.50] *** wired|quassel (n=quassel@athedsl-290085.home.otenet.gr) has joined #gentoo-kde
-[22:16.01] *** wired|quassel (n=quassel@athedsl-290085.home.otenet.gr) Quit (Client Quit)
-[22:16.17] *** wired|quassel (n=quassel@athedsl-290085.home.otenet.gr) has joined #gentoo-kde
-[22:16.40] <scarabeus> jmbsvicetto: in case you didnt look yet: http://bugs.gentoo.org/chart.cgi?category=-All-&subcategory=-All-&name=320&label0=Kde-Charting&line0=591&datefrom=&dateto=&action-wrap=Chart+This+List
-[22:16.41] <yngwin> so does anyone have anything against the blocker?
-[22:16.48] <scarabeus> no prob here
-[22:16.51] *** Skim[ihz] (n=skim@skim.static.corbina.ru) Quit (Client Quit)
-[22:16.56] <scarabeus> it looks fine when i compared
-[22:17.06] <hwoarang> i am on board
-[22:17.34] <yngwin> ok, let's do it then
-[22:17.52] <yngwin> next topic :)
-[22:18.02] <scarabeus> okey qt team can touch the amarok for this one i assume ;]
-[22:18.12] <scarabeus> KDE 4 Stabilisation.
-[22:18.15] <scarabeus> quite big
-[22:18.41] <scarabeus> but the bugs are ok, and now we agreed masking the prefix useflag only thing that remains is the kde4 apps out of the kde4 session
-[22:18.53] <scarabeus> reavertm: how we are standing on that bug, i was not paying much attention to it lately
-[22:19.02] <jmbsvicetto> scarabeus: hmm, should I get a chart?
-[22:19.14] <scarabeus> jmbsvicetto: yes for me it draws nice chart
-[22:19.19] <scarabeus> jmbsvicetto: open in anything else than FF
-[22:19.28] <scarabeus> and second thing is what version we will stable
-[22:19.29] <jmbsvicetto> so it only fails on FF?
-[22:19.30] <scarabeus> 4.2 or 4.3
-[22:19.30] <yngwin> wow that is fail
-[22:19.31] *** etix (n=etix@videolan/developer/etix) Quit (Client Quit)
-[22:19.41] <scarabeus> jmbsvicetto: yes
-[22:19.42] <jmbsvicetto> I'd say it depends when we get it done
-[22:19.53] <jmbsvicetto> For the next 2 months I would bet on 4.2.4 and or 4.2.5
-[22:19.59] <scarabeus> jmbsvicetto: well i am testing the 4.2.91 and i am damn impressed
-[22:20.02] <reavertm> they would work with kdeprefix if qt plugin loader wasn't affected - with -kdeprefix (and ~.config/Trolltech.conf wiped out) they are fine
-[22:20.23] <reavertm> another issue is with kde3 .desktop icons in kde4 session
-[22:20.38] <jmbsvicetto> scarabeus: Yeah, but it's too early for it
-[22:20.42] <scarabeus> the guys are really working their asses to make it nice
-[22:20.43] <reavertm> currently nothing is shown (because nothing would work)
-[22:20.49] <scarabeus> well it will be in 1 month around
-[22:20.58] <jmbsvicetto> scarabeus: I guess users that have been waiting for 2 years, can wait another month or two for 4.3 ;)
-[22:20.59] <spatz> and you'll have to wait a month to stabilize it
-[22:21.00] <scarabeus> also the printing dialog is tempting
-[22:21.14] <scarabeus> jmbsvicetto: ok should we vote on the thing or we agree
-[22:21.19] <scarabeus> reavertm: what do you think :]
-[22:21.40] <reavertm> scarabeus: does that printing dialog work for you?
-[22:21.46] <scarabeus> reavertm: nope ;D
-[22:21.47] <jmbsvicetto> I guess I'll make an "executive decision" on this one :P
-[22:21.48] <reavertm> (crashes in my cheoot)
-[22:21.54] <scarabeus> it says that it hate me
-[22:21.58] <scarabeus> it cant chat with cups
-[22:22.02] <reavertm> scarabeus: printing is deferred until fixed :P
-[22:22.04] <scarabeus> even tho i am able to print
-[22:22.18] <scarabeus> jmbsvicetto: okey so decide
-[22:22.29] <reavertm> (so no go for system-config-printer-kde and printer-applet)
-[22:22.30] <scarabeus> jmbsvicetto: fine with me you are elected lead, so you choose global policy:]
-[22:22.41] <jmbsvicetto> 4.2.[4|5] for the next 2 months - after that we can talk about 4.3
-[22:22.42] <scarabeus> reavertm: they are already in the tree by accident ;DDD
-[22:22.53] <reavertm> well, masked they can be
-[22:22.58] <scarabeus> reavertm: some looser already opened bug about it has missing deps ;D
-[22:23.08] <scarabeus> because movetocvs just grab everything with nice version :D
-[22:23.08] <reavertm> good
-[22:23.21] <jmbsvicetto> scarabeus: we should also open the bug asap
-[22:23.26] <scarabeus> jmbsvicetto: ok whom will handle stabling of 4.2 then
-[22:23.57] *** ebola_ (i=ebola@S0106066606660666.su.shawcable.net) has joined #gentoo-kde
-[22:24.01] <jmbsvicetto> what is blocking it?
-[22:24.10] <reavertm> most of kde4 issues
-[22:24.10] <scarabeus> the above thng only
-[22:24.11] *** Skim[ihz] (n=skim@skim.static.corbina.ru) has joined #gentoo-kde
-[22:24.12] <reavertm> :P
-[22:24.23] <scarabeus> running the kde4 apps out of the kde4 session
-[22:24.25] <jmbsvicetto> kde-print?
-[22:24.28] <jmbsvicetto> ah
-[22:24.29] <scarabeus> but it should be addressed already
-[22:24.30] <reavertm> also kdm crashes
-[22:24.40] <scarabeus> yeah kdm is weird crap with -O3
-[22:24.53] <jmbsvicetto> scarabeus: KDE has had issues with -O3 since ever
-[22:25.01] <reavertm> without -O3 as well (but works with new user)
-[22:25.02] <jmbsvicetto> scarabeus: If you look in bugzilla there were a few reports about that
-[22:25.13] *** ebola_ (i=ebola@S0106066606660666.su.shawcable.net) has left <type 'buffer'>
-[22:25.16] <jmbsvicetto> reavertm: are you sure it's not a graphics driver issue?
-[22:25.19] *** InvaderNOP (i=ebola@S0106066606660666.su.shawcable.net) has joined #gentoo-kde
-[22:25.28] <scarabeus> if it works with new user...
-[22:25.41] <jmbsvicetto> yeah, hmm config option?
-[22:25.46] <reavertm> like?
-[22:25.55] *** Civil (n=Civilian@95-24-130-90.broadband.corbina.ru) Quit (Remote closed the connection)
-[22:26.02] <reavertm> anyway, stabilization bug could be opened to track issues
-[22:26.09] <scarabeus> tracker bug
-[22:26.13] <jmbsvicetto> let's open the tracker then
-[22:26.15] <scarabeus> 1 for tracking 2 for stabling
-[22:26.17] <reavertm> personally I wouldn't hurry with stabilization
-[22:26.23] <scarabeus> but whom will wrangle the stuff
-[22:26.31] <scarabeus> i guess tampy wont do second round
-[22:26.33] <reavertm> everyone :P
-[22:26.33] <scarabeus> :]
-[22:26.55] <jmbsvicetto> I suppose you want someone with -kdeprefix O:-)
-[22:27.02] *** andreax (n=andreaz@p57B951A2.dip.t-dialin.net) has joined #gentoo-kde
-[22:27.24] <scarabeus> GRM
-[22:27.37] <yngwin> btw i noticed sabayon is on +kdeprefix
-[22:27.38] <scarabeus> i am definetly sure that i will still target on closing bug than on wrangling them
-[22:27.41] <reavertm> I'd take commit count :D
-[22:27.47] <scarabeus> i am allways depressed about wrangling
-[22:28.06] <scarabeus> yngwin: 5.0 branch is -kdeprefix
-[22:28.09] <jmbsvicetto> scarabeus: oh, looking at bugs? we can all do it
-[22:28.16] <scarabeus> remember that we cooperate at sabayon
-[22:28.18] <yngwin> ok good
-[22:28.26] <scarabeus> s/at/with/
-[22:28.34] <yngwin> yes, thats why i mentioned it
-[22:28.37] <scarabeus> !seen joost-op
-[22:28.39] <Willikins> scarabeus: nope!
-[22:28.53] <scarabeus> !seen joost_op
-[22:28.54] <Willikins> scarabeus: joost_op was last seen 4 days, 45 minutes and 54 seconds ago, quitting IRC (Remote closed the connection)
-[22:29.28] <scarabeus> i already discussed with him about it :]
-[22:29.31] <scarabeus> so problem solved :]
-[22:30.03] <scarabeus> ok i think we have stuff that is needed to be done
-[22:30.15] <scarabeus> and i guess each of us can wrangle some itching bug
-[22:30.25] <scarabeus> i think everything above normal must be assinged there
-[22:30.25] *** haavardw (n=haavardw@cm-84.208.110.202.getinternet.no) Quit (Remote closed the connection)
-[22:30.33] <scarabeus> and rest is up to our decision
-[22:31.26] <scarabeus> anything else to this topic?
-[22:31.28] *** ABCD (n=ABCD@wikipedia/ABCD) Quit (Client Quit)
-[22:31.32] *** ABCD (n=ABCD@wikipedia/ABCD) has joined #gentoo-kde
-[22:31.37] <reavertm> hmm,m what about phonon?
-[22:31.38] *** scarabeus sets mode: +v ABCD
-[22:31.44] <scarabeus> already stable
-[22:31.46] <reavertm> it will be blocker for 4.3 I guess
-[22:31.57] <scarabeus> ah this
-[22:32.07] <scarabeus> it is not issue for 4.2 stable bug for now
-[22:32.17] <scarabeus> even if we might transcendent to 4.3 it can be address later
-[22:33.34] <scarabeus> ok since everyone is silent lets go with next topic
-[22:33.37] <scarabeus> topic: Review the useflags we enable by default in qt herd
-[22:33.44] <scarabeus> yngwin, hwoarang: ^
-[22:33.51] <reavertm> (and in kde as well :P)
-[22:33.59] <scarabeus> i think the +gtkdialog is FKHE#(*%$YU#HR$(*%W#URJTN stupid
-[22:34.03] <scarabeus> it pulls gtk
-[22:34.07] <scarabeus> and that pulls X
-[22:34.10] <scarabeus> on -X install
-[22:34.15] <reavertm> gtktheme you mean?
-[22:34.16] <scarabeus> so instead of 17 deps you have 55
-[22:34.20] <scarabeus> oh theme right
-[22:34.38] <spatz> gtkstyle
-[22:34.45] <reavertm> ah
-[22:34.54] <scarabeus> what ever ;]
-[22:35.14] <spatz> but that's in qt-gui which needs X anyway
-[22:35.25] <hwoarang> :)
-[22:35.49] *** bbroeksema (n=bbroekse@cust-02-5286b4cb.adsl.scarlet.nl) Quit (Remote closed the connection)
-[22:35.57] <Pesa> there's another topic in the agenda about this btw
-[22:36.01] <yngwin> we could rename that to gtk, so it only get enabled by default in desktop profile
-[22:36.17] <spatz> was just about to say that
-[22:36.22] <hwoarang> Pesa: which one
-[22:36.31] <Pesa> review the useflags we enable by default in qt herd
-[22:36.33] <spatz> rename to gtk and not have it on by default
-[22:36.38] *** B-Man1 (n=B-Man@cpe-098-024-241-139.ec.res.rr.com) Quit (Client Quit)
-[22:36.45] <yngwin> Pesa: thats what we're discussing now
-[22:36.52] *** B-Man (n=B-Man@cpe-098-024-241-139.ec.res.rr.com) has joined #gentoo-kde
-[22:37.05] <Pesa> ha
-[22:37.09] <Pesa> i failed
-[22:37.09] <hwoarang> :P
-[22:37.17] <Pesa> i'm getting angry with my ISP
-[22:37.33] <hwoarang> do we really need to enable something by default?
-[22:37.37] <spatz> but gtk isn't the only issue, also dbus, glib, qt3support and others
-[22:37.44] <spatz> they're all enabled by default
-[22:37.54] <hwoarang> dbus is already on profile
-[22:37.56] <scarabeus> qt3support disable guys i think
-[22:38.01] <scarabeus> glib can be disabled too
-[22:38.06] <scarabeus> i live without the later
-[22:38.15] <hwoarang> i cant recall why glib is on
-[22:38.16] <scarabeus> and the former we demand on kde but otherwise it is not needed right?
-[22:38.29] <hwoarang> i think
-[22:39.08] <spatz> the default should be off by default unless there's a good reason, not the way it is right that almost everything is on by default, IMHO
-[22:39.20] <spatz> i'm talking about all qt-* useflags
-[22:39.36] <hwoarang> yes
-[22:39.39] <yngwin> the reasoning why i enabled most of those is to have the default qt4 install have all the functionality that most users would want
-[22:40.04] <hwoarang> define: all the functionality
-[22:40.05] <spatz> most users of qt will have a desktop profile and/or have all the useflags they want enabled
-[22:40.05] <hwoarang> :P
-[22:40.26] <hwoarang> desktop profile enables most of them anyway
-[22:40.42] <scarabeus> i would suggest remove all + and see what it does
-[22:40.48] <scarabeus> and introduce only where really needed
-[22:40.49] <yngwin> yes, so we can drop those that the desktop profile enables
-[22:40.54] <scarabeus> re-introduce
-[22:40.57] <spatz> the current behavious is useless to the average user and annoying to those actually having a benefit from split ebuilds
-[22:40.59] <Pesa> qt3support is enabled by desktop
-[22:41.10] <yngwin> useless??
-[22:41.10] <jmbsvicetto> scarabeus: I don't quite agree
-[22:41.24] <spatz> yes, because he has those useflags enabled anyway
-[22:41.30] <scarabeus> jmbsvicetto: see above
-[22:41.32] <jmbsvicetto> scarabeus: default use flags allow us to drop most use flags from profiles
-[22:41.33] <spatz> it doesn't affect him at all
-[22:41.34] <scarabeus> jmbsvicetto: the flag is in profile
-[22:41.41] <yngwin> more superfluous than useless
-[22:41.47] <scarabeus> i was damn angry having +qt3support on sever
-[22:41.51] <spatz> yes
-[22:41.53] <scarabeus> so i had to edit useflag list
-[22:41.56] <spatz> bad choice of words
-[22:42.06] <jmbsvicetto> spatz: nothing prevents you from adding -<use> to your /etc/portage/package.use[/*] config file(s)
-[22:42.34] <hwoarang> mm
-[22:42.46] <spatz> of course, but useflags should be opt-in, not opt-out in the general case
-[22:42.48] <jmbsvicetto> scarabeus: yes, but instead of removing default use flags because they're enabled on profiles, we should be dropping use flags from profiles and moving them to default use flags
-[22:43.03] <yngwin> so let's drop the + on the useflags that are already in profiles
-[22:43.11] <hwoarang> +1
-[22:43.12] <spatz> that would be a good start
-[22:43.13] <scarabeus> jmbsvicetto: really? why?
-[22:43.15] <yngwin> and rename gtkstyle to gtk
-[22:43.24] *** Kame2 (n=manuel@port-92-196-126-246.dynamic.qsc.de) Quit (Remote closed the connection)
-[22:43.36] <jmbsvicetto> because that would prevent users from getting all the crap they get from profiles with ton of use flags like qt, kde, gtk or gnome
-[22:43.45] <jmbsvicetto> tons*
-[22:43.46] <scarabeus> jmbsvicetto: i really like that i have different useflags on case like server/desktop based on profile
-[22:44.01] <scarabeus> and for the qt it really made me sad
-[22:44.02] <jmbsvicetto> yeah, but desktop profiles currently have too many use flags
-[22:44.25] <spatz> maybe the desktop profile needs to be split, but that's out of scope
-[22:44.28] <jmbsvicetto> scarabeus: the first thing I add to my servers is USE="-X -gtk -gnome -kde -qt" ;)
-[22:44.39] <scarabeus> yeah yeah but i need qt on mine server
-[22:44.40] <yngwin> maybe desktop profile should be divided into subprofiles
-[22:44.43] <scarabeus> quassel ;\
-[22:44.45] <scarabeus> ;]
-[22:45.10] <yngwin> so?
-[22:45.10] <jmbsvicetto> No, I don't think it's out of scope. Instead of spliting profiles or moving flags from packages to profiles, I think we should be going the other way around and dropping use flags from profiles back to packages
-[22:45.16] <spatz> and you shouldn't use the desktop profile on your server :)
-[22:45.19] <yngwin> you can still have quassel with -qt
-[22:45.42] <scarabeus> jmbsvicetto: mail the idea to the -dev :]
-[22:45.42] <spatz> per profile is more appropriate than per package
-[22:45.45] <jmbsvicetto> spatz: I don't use the desktop profile on my workstations ;)
-[22:45.45] <yngwin> jmbsvicetto: well, that's stuff for a wider policy discussion
-[22:45.51] <spatz> that was also agreed last week on -dev, iirc
-[22:45.56] <jmbsvicetto> yngwin: indeed
-[22:46.08] <spatz> that's what i meant by "out of scope"
-[22:46.16] *** scarabeus sets mode: +v wired|quassel
-[22:47.07] <jmbsvicetto> Anyway, I think kde should retain default use flags for most optional support features that upstream enables by default
-[22:47.26] <yngwin> well, i dont have a string preference here, but it looks like my qt brothers do
-[22:47.32] <yngwin> strong*
-[22:48.10] <spatz> http://archives.gentoo.org/gentoo-dev/msg_d676d199747afac881bbf444dac478ea.xml
-[22:48.48] <scarabeus> ok lets continue this topic there
-[22:48.56] <scarabeus> rather on the meeting :]
-[22:49.16] <scarabeus> wired: are you around?
-[22:49.25] <wired> yes
-[22:49.33] * bonsaikitten gone
-[22:49.34] *** geo27 (n=quassel@lns-bzn-30-82-253-130-209.adsl.proxad.net) Quit (Remote closed the connection)
-[22:49.36] <reavertm> jmbsvicetto: upstream enabled by default everything that's autodetected
-[22:49.39] <scarabeus> wired: did you tracked the tampakrap what he is doing with kde3?
-[22:49.48] <reavertm> hence, it's bad approach imho
-[22:49.50] <wired> only the eclass part
-[22:49.53] <scarabeus> ah
-[22:49.59] <wired> scarabeus: btw i talked to him a few minutes ago
-[22:50.04] *** geo27 (n=quassel@lns-bzn-30-82-253-130-209.adsl.proxad.net) has joined #gentoo-kde
-[22:50.05] <scarabeus> where is he
-[22:50.10] <wired> he missed the meeting because he was traveling to athens
-[22:50.19] <scarabeus> and can he get online now?
-[22:50.24] <scarabeus> only to give us status info?
-[22:50.32] <scarabeus>  /report
-[22:50.33] <wired> hmm
-[22:50.39] <wired> let me call him and ask
-[22:50.42] <wired> 1min
-[22:50.51] <spatz> yngwin: so let's do what you decided and check back in while
-[22:51.27] <jmbsvicetto> reavertm: They don't autoenable everything
-[22:51.31] <scarabeus> jmbsvicetto: they do
-[22:51.36] <spatz> gtkstyle->gtk, remove default on all flags enabled in desktop profile
-[22:51.37] <wired> scarabeus: he'll be in here in 15m
-[22:51.38] <scarabeus> jmbsvicetto: if they detect package, they enable it
-[22:51.44] <jmbsvicetto> reavertm: For instance kopete doesn't enable by default all protocols and plugins
-[22:51.47] <yngwin> do we change them now or on next release?
-[22:51.56] <reavertm> there are some exceptions, yes
-[22:51.59] *** mrpouet (n=mrpouet@gentoo/developer/mrpouet) Quit (Client Quit)
-[22:52.00] <scarabeus> ok guys how much you want to read last topic
-[22:52.19] <wired> scarabeus: ok? =]
-[22:52.33] <scarabeus> wired: well it depends on others
-[22:52.41] <scarabeus> i cant hold them here for another 20 minutes ;]
-[22:52.45] <spatz> yngwin: would that require re-stabilizing?
-[22:52.46] <scarabeus> the meeting already lasts 2 hours
-[22:53.02] <yngwin> hmm, good question
-[22:53.03] <scarabeus> spatz: nope, archies are supposed to test various use flags
-[22:53.13] <jmbsvicetto> wired: he can login when he can and put a short status message here
-[22:53.21] <yngwin> so i guess not :)
-[22:53.29] <spatz> if not than we should do it now, imo
-[22:53.36] <spatz> otherwise we'll forget :)
-[22:53.37] *** hkBst (n=hkBst@gentoo/developer/hkbst) Quit (Read error: 104 (Connection reset by peer))
-[22:53.40] *** himikof_ (n=himikof@129.167.249.ozerki.net) Quit (Remote closed the connection)
-[22:53.55] <Pesa> 4.5.2 shouldn't be too far
-[22:53.58] *** NSaibot (n=quassel@dslb-094-217-110-040.pools.arcor-ip.net) has joined #gentoo-kde
-[22:53.58] <yngwin> in that case we can also drop custom-cxxflags useflag as we decided before
-[22:54.02] <jmbsvicetto> yngwin: it can change the installed package, so it should go through the revbump process
-[22:54.20] <yngwin> ok
-[22:54.23] <Pesa> then wait for 4.5.2
-[22:54.31] <yngwin> i agree
-[22:54.37] <spatz> for everything or just custom-cxxflags?
-[22:54.42] <yngwin> everything
-[22:54.42] <Pesa> everything
-[22:54.55] <spatz> ok
-[22:55.27] <yngwin> of course we can already do it in the overlay, where applicable
-[22:55.29] <spatz> next topic?
-[22:55.43] *** bearsh (n=quassel@80-219-1-239.dclient.hispeed.ch) Quit (Remote closed the connection)
-[22:55.45] <spatz> btw, what about libX11 dep in qt-core?
-[22:56.02] <yngwin> that's good to go into the tree
-[22:56.20] <Pesa> should we do the same for qt-dbus?
-[22:56.21] <spatz> those deps should be added to qt-gui and friends, no?
-[22:56.35] <yngwin> ah good call
-[22:56.35] <spatz> Pesa: it works for me
-[22:56.48] <yngwin> can you commit to overlay?
-[22:56.53] <spatz> those that do depend on libX11 and libXext should get it
-[22:57.16] <yngwin> make sure all modules are ok and checked for those
-[22:57.34] *** himikof_ (n=himikof@129.167.249.ozerki.net) has joined #gentoo-kde
-[22:57.35] *** DeSoVoDaMu (n=deso@77-21-66-33-dynip.superkabel.de) Quit (Read error: 113 (No route to host))
-[22:58.03] <spatz> i might not have time to do it in the overlay because of my exams :/
-[22:58.10] <yngwin> so we need to revbump those packages anyway
-[22:58.54] <yngwin> then we might as well do the useflag change, unless 4.5.2 is released very soon
-[22:59.04] <Pesa> right
-[22:59.18] <spatz> ok, great
-[22:59.55] *** papillon81 (n=papillon@f053145102.adsl.alicedsl.de) has joined #gentoo-kde
-[23:00.05] <yngwin> scarabeus: shall we close the meeting then?
-[23:00.06] *** scarabeus sets mode: +v papillon81
-[23:00.18] <scarabeus> well we can wait 8 minutes and tampy will be here
-[23:00.23] <scarabeus> it is up to you
-[23:00.31] <yngwin> you forget he's greek
-[23:00.42] <spatz> for what topic? (i forgot)
-[23:00.43] <scarabeus> what does it mean
-[23:00.51] <scarabeus> Progress of kde3 mess and way how anyone can help (here we call even for non-kdeteam devs)
-[23:00.52] <yngwin> 8 minutes could mean anything
-[23:01.23] *** scarabeus sets mode: +v wohnout
-[23:01.33] *** Gabrys (n=Gabrys@77-254-190-150.adsl.inetia.pl) has joined #gentoo-kde
-[23:02.02] <scarabeus> wired: ok tell him not to rush, and he will have to sent us the mail onto the kde@ and qt@ alliases or onto -desktop
-[23:02.24] <scarabeus> ok i hereby close the meeting
-[23:02.30] <scarabeus> and btw someone create log
-[23:02.30] <wired> well he should be here shortly, but ok :)
-[23:02.36] *** scarabeus sets mode: -m
-[23:02.55] <tampakrap_> i'm here
-[23:02.57] <scarabeus> aghr
-[23:02.59] *** tampakrap_ is now known as tampakrap
-[23:03.02] <scarabeus> you are joking :D
-[23:03.04] <yngwin> lol
-[23:03.05] *** scarabeus sets mode: +m
-[23:03.06] <tampakrap> no i am here
-[23:03.15] <yngwin> welcome :)
-[23:03.15] <scarabeus> yeah i see :]
-[23:03.16] <scarabeus> ok
-[23:03.33] <scarabeus> welcome indeed
-[23:03.34] <tampakrap> what's the deal
-[23:03.36] <tampakrap> ?
-[23:03.41] <wired> lol
-[23:03.48] <yngwin> kde3
-[23:03.54] <scarabeus> we want to know
-[23:03.59] <spatz> <scarabeus> Progress of kde3 mess and way how anyone can help (here we call even for non-kdeteam devs)
-[23:04.00] <scarabeus> state/progress what is to be done
-[23:04.02] <scarabeus> what is done
-[23:04.16] <tampakrap> ok
-[23:04.31] <tampakrap> kde3 misc apps need slotmove and stabilization this will take some time
-[23:04.34] <tampakrap> as i have no help
-[23:04.35] <jmbsvicetto> yngwin: hehe
-[23:04.39] <jmbsvicetto> Heya Theo
-[23:04.44] <tampakrap> koffice is my playground, i'll fix eclass
-[23:04.47] <scarabeus> tampakrap: hey i did about 5-10 apps
-[23:04.51] <tampakrap> *hello hello*
-[23:05.00] <tampakrap> not the stabilization part though
-[23:05.07] <tampakrap> so i still have to take care of the list
-[23:05.13] <tampakrap> and kde-base/*3.5.10*
-[23:05.20] <tampakrap> has many *stupid* bugs
-[23:05.22] <scarabeus> tampakrap: i would suggest to switch all misc apps
-[23:05.25] <tampakrap> that i have no motivation to fix
-[23:05.26] <scarabeus> and then open 1 stable bug
-[23:05.33] <tampakrap> this can't be done
-[23:05.40] <tampakrap> they don't have the same keywords
-[23:05.40] <scarabeus> why not
-[23:05.44] <scarabeus> no problem
-[23:05.45] <tampakrap> and it is against the rules :)
-[23:05.48] <scarabeus> just make list for each arch
-[23:06.02] <scarabeus> we do it in X when we stable all the stuff
-[23:06.09] <tampakrap> this isn't easier for me
-[23:06.13] <scarabeus> okey
-[23:06.16] <scarabeus> as pleases you
-[23:06.19] <scarabeus> since you do the work
-[23:06.20] <tampakrap> i slotmove package, check bugs and open bug
-[23:06.34] <tampakrap> anything else?
-[23:06.41] <tampakrap> what did you say about the stabilization?
-[23:06.44] <tampakrap> of kde4
-[23:06.55] <scarabeus> KDE 4 Stabilisation.
-[23:06.55] <scarabeus> - Jorge decided to start with 4.2 stabilisation.
-[23:06.55] <scarabeus> - stabilisation bug will have to be opened
-[23:06.55] <scarabeus> - tracking bug will have to be opened and bugs wrangled (volunteers??)
-[23:06.59] <scarabeus> this is summary
-[23:07.08] <tampakrap> ok
-[23:07.11] <tampakrap> we need tracker again
-[23:07.18] <scarabeus> ah how about asking for help with kde3 misc stuff on -dev
-[23:07.25] *** Skim[ihz] (n=skim@skim.static.corbina.ru) Quit (Client Quit)
-[23:07.26] <tampakrap> i volunteer with bug wrangling
-[23:07.37] <scarabeus> ssuominen did probably great job with removing arts usefla
-[23:07.38] <scarabeus> g
-[23:07.44] <scarabeus> how is its progress
-[23:07.49] *** scarabeus sets mode: +v ssuominen
-[23:07.59] <tampakrap> well we can say that kde3 is *open* for anyone
-[23:08.09] <ssuominen> media-sound cat. is clear of all arts deps
-[23:08.10] <scarabeus> !rdep arts
-[23:08.10] <Willikins> scarabeus: Too many packages have reverse RDEPEND on kde-base/arts, go to http://tinderbox.dev.gentoo.org/misc/rindex/kde-base/arts instead.
-[23:08.14] <ssuominen> media-libs half way
-[23:08.14] <tampakrap> not for maintaining but for random bugfixing
-[23:08.16] *** [Enrico] (n=chiccoro@host224-36-dynamic.16-79-r.retail.telecomitalia.it) Quit (Read error: 104 (Connection reset by peer))
-[23:08.21] <ssuominen> media-video undone
-[23:08.31] <scarabeus> 785 packages
-[23:08.34] * scarabeus is sad
-[23:08.41] <ssuominen> the media-sound apps left on the list are masked for removal or similar
-[23:08.43] <ssuominen> yeah
-[23:08.51] *** g1lt (n=quassel@203-79-94-158.cable.telstraclear.net) has joined #gentoo-kde
-[23:08.52] <scarabeus> just set allways arts never when there is optional in ebuild in eclass?
-[23:08.56] <scarabeus> that might close few?
-[23:08.57] <ssuominen> there's lots to be done, i can handle it by opening some bugs for teams
-[23:09.05] <ssuominen> to speed it up
-[23:09.20] <ssuominen> did similar when i killed gtk+-1.2 from 50%+ pkgs the another summer
-[23:09.24] <ssuominen> :P
-[23:09.32] <wohnout> death to arts
-[23:10.09] <ssuominen> can we quick vote on "let's remove arts from use defaults immediately?"
-[23:10.12] <ssuominen> ;)
-[23:10.19] <scarabeus> ssuominen: voted allowed already
-[23:10.21] <scarabeus> just do it
-[23:10.24] * ssuominen does
-[23:10.35] <scarabeus> ssuominen: will you be our asignee for arts thing? you seems to enjoy it ;}
-[23:11.49] <ssuominen> don't mind handling it so why not
-[23:11.56] <scarabeus> okey
-[23:12.04] <scarabeus> i will sent you the eclass update then
-[23:12.08] <scarabeus> for arts removal
-[23:12.18] <scarabeus> btw how much packages probably has arts HARDDEP?
-[23:12.21] <scarabeus> can it be found out?
-[23:12.22] <ssuominen> over the half way, there will always be a maintainer or two who attacks you for removings on false grounds (hit few of those on the gtk+-1.2 road)
-[23:13.04] <scarabeus> you see how much it hurts mine heart? ;]
-[23:13.05] <ssuominen> well in media-sound i've fixed about 50% pkgs to not dep on arts anymore
-[23:13.08] <scarabeus> so painfull ;]
-[23:13.10] <ssuominen> it was totally false
-[23:13.29] <scarabeus> well they can state it to us, probably anouncal on -dev might be good
-[23:13.30] <ssuominen> and removed about the optional dep on 25% and remaining 25% got punted
-[23:14.13] <ssuominen> but i guess there's no hurry
-[23:14.21] <ssuominen> but giving it a small boost won't hurt
-[23:14.23] <ssuominen> ;)
-[23:14.24] <tampakrap> yes
-[23:14.26] <scarabeus> :]
-[23:14.48] *** mikkoc (n=mikko@host161-90-dynamic.0-87-r.retail.telecomitalia.it) Quit (Remote closed the connection)
-[23:14.52] *** Devrethman (n=quassel@209.90.234.102) has joined #gentoo-kde
-[23:15.29] <scarabeus> anything else we have for kde3?
-[23:15.37] *** YaCK (n=brayan@unaffiliated/yack) Quit (Client Quit)
-[23:15.38] <tampakrap> kill it?
-[23:15.48] *** geo27 (n=quassel@lns-bzn-30-82-253-130-209.adsl.proxad.net) Quit (Remote closed the connection)
-[23:16.13] <tampakrap> look ppl i told you i have no motivation in this thing any more, what i did was to make sure it can work with kde4
-[23:16.29] <scarabeus> tampakrap: ok we should recruit someone for that
-[23:16.41] <tampakrap> since this thing works, we have to tell ppl *asap* that we have no motivation for maintaining it any more
-[23:16.43] <scarabeus> tampakrap: i really agree that you dont have to push it so hard forward if you dont have the motivation
-[23:16.49] <tampakrap> it started not to compile you know :)
-[23:17.02] <jmbsvicetto> And to have security issues!
-[23:17.04] <scarabeus> tampakrap: open the requirement on the stuffing needs
-[23:17.18] <jmbsvicetto> scarabeus: nope, add it to our project page
-[23:17.19] <tampakrap> no, no, kde3 doesn't need maintainer
-[23:17.25] <reavertm> it would be best to have it handled by some dev determined to stay with kde3
-[23:17.29] <tampakrap> just various bugfixing by ppl who use it
-[23:17.43] <scarabeus> yeah somebody determined using it would be nice
-[23:17.43] <reavertm> at least in kde team there is none...
-[23:17.49] <reavertm> :)
-[23:17.52] <scarabeus> well carlo...
-[23:17.58] <scarabeus> last seen on february
-[23:18.09] <scarabeus> when he broke quite few packages with wrong eapi2 bump
-[23:18.45] <reavertm> well, nobody is as experienced in eapi2 bumps like we are :P
-[23:18.49] <scarabeus> so we reaaaally need someone
-[23:18.52] <scarabeus> reavertm: yeah :D
-[23:18.57] <scarabeus> we are masters :D
-[23:19.07] *** Skim[ihz] (n=skim@skim.static.corbina.ru) has joined #gentoo-kde
-[23:19.21] <yngwin> sping is interested
-[23:19.40] <scarabeus> who is sping
-[23:19.44] <scarabeus> where is sping
-[23:19.51] <scarabeus> give us sping!
-[23:19.53] <tampakrap> jmbsvicetto: will you use your hat and send an email to -dev plz?
-[23:19.59] <yngwin> sebastian ping, currently doing GSoC
-[23:20.02] <reavertm> scarabeus: just drop 'packages up for grab' list on gentoo-dev with `200 kde3 ebuilds that kde team doesn't care about anymore :D
-[23:20.07] *** sean345 (n=sean345@c-76-105-5-254.hsd1.ca.comcast.net) has joined #gentoo-kde
-[23:20.10] *** BCMM (n=bcmm@unaffiliated/bcmm) has joined #gentoo-kde
-[23:20.16] <scarabeus> rofl
-[23:20.21] <scarabeus> jmbsvicetto: could we do it?
-[23:20.22] <scarabeus> :DDDDDD
-[23:20.27] <yngwin> pipping*
-[23:20.38] *** Varox (n=Varox@p4FD46B43.dip.t-dialin.net) has joined #gentoo-kde
-[23:20.38] <yngwin> the PackageMap guy
-[23:20.48] <scarabeus> oh i see
-[23:20.54] <scarabeus> and is he on irc from time to time?
-[23:21.07] <yngwin> yes
-[23:21.12] <scarabeus> but i assume he is uberbusy with gsoc on the other hand
-[23:21.17] <yngwin> yes
-[23:21.30] <yngwin> he will return to recruitment after gsoc
-[23:22.17] <jmbsvicetto> tampakrap: about kde3? ok
-[23:22.39] <scarabeus> jmbsvicetto: wait for summary i have 2 mails for you probably :D
-[23:22.39] <jmbsvicetto> scarabeus / reavertm: no :\
-[23:23.02] <scarabeus> ok we are probably done about the topic for now, at least until gsoc is over
-[23:23.05] <jmbsvicetto> no (no we can't drop kde3 on maintainer-needed)
-[23:23.17] <reavertm> that was joke :)
-[23:23.31] <tampakrap> i can supervise the commits
-[23:23.34] <scarabeus> jmbsvicetto: it was really joke :]
-[23:23.41] *** spatz (n=spatz@unaffiliated/spatz) Quit (Remote closed the connection)
-[23:23.44] <tampakrap> but for bugfixing i doubt it
-[23:23.57] <scarabeus> ok i anounce the meeting over then :]
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090820.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090820.txt
deleted file mode 100644
index ad6bf17322..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090820.txt
+++ /dev/null
@@ -1,545 +0,0 @@
-[20:55:28] <scarabeus> 57 secs
-[20:55:40] <wired> =]
-[20:56:45] <scarabeus> okey
-[20:56:50] <scarabeus> i guess we will have to wait
-[20:57:05] <scarabeus> since 3 devs; 2 hts and 2 exherbos are not exactly desired combo
-[20:57:18] <reavertm> I'm here
-[20:57:19] <wired> lol
-[20:58:00] --> bonsaikitten (i=quassel@gentoo/developer/bonsaikitten) has joined #gentoo-meetings
-[20:58:02] --> dagger (n=quassel@gentoo/developer/dagger) has joined #gentoo-meetings
-[20:58:12] <wired> that helped... a bit :)
-[20:58:23] --> yngwin (n=yngwin@gentoo/developer/yngwin) has joined #gentoo-meetings
-[20:58:25] --> Ingmar (i=ingmar@exherbo/developer/ingmar) has joined #gentoo-meetings
-[20:58:33] --> ayoy (n=ayoy@cs78245237.pp.htv.fi) has joined #gentoo-meetings
-[20:58:43] <yngwin> here
-[20:59:10] <scarabeus> ok
-[20:59:14] <scarabeus> looks better :]
-[20:59:19] <scarabeus> so  for the tampakrap
-[20:59:21] <scarabeus> http://www.pastebin.cz/b594e8e991906a
-[20:59:30] <scarabeus> i count him as excuses due to personal matters
-[20:59:41] --> Gentoochild (n=bla@vpn5.rz.tu-ilmenau.de) has joined #gentoo-meetings
-[20:59:43] <scarabeus> please read the above paste
-[20:59:50] <yngwin> pesa has no internet currently
-[21:00:35] <yngwin> and ayoy is being grilled by his recruiter
-[21:01:03] <scarabeus> ok
-[21:01:16] <scarabeus> anyone said that he will be late?
-[21:01:32] <scarabeus> otherwise i just wrote up our roll-call, i count everyone whom joined as here
-[21:01:34] <yngwin> not that i know
-[21:01:42] <yngwin> ok
-[21:02:08] <scarabeus> ok so i would say lets start with topic 1
-[21:02:12] <yngwin> i'm having a headache, so i'd like to keep this short on my end
-[21:02:37] <scarabeus> for that i count as relevant tampakraps opinion, and reavertm's they are the last one working on it
-[21:02:51] <scarabeus> so since tampakrap said it in mail i would ask reavertm if he has something to add
-[21:02:52] <jmbsvicetto> scarabeus: I'll talk to tampakrap, but 2 things about the KDE3 overlay
-[21:03:07] <jmbsvicetto> scarabeus: 1. Let's call it kde-junk, kde-sunset, or something like that.
-[21:03:27] <scarabeus> jmbsvicetto: no problem i have all powers about gitosis
-[21:03:36] <jmbsvicetto> scarabeus: 2. We can't drop any ebuilds from the tree before at least the end of the year
-[21:03:37] <scarabeus> just sent me after decided name
-[21:03:51] <scarabeus> with 2 i agree
-[21:03:56] <jmbsvicetto> The reason is that we shouldn't tie an overlay to a specific kde version
-[21:03:57] <scarabeus> i would start it after 4.4
-[21:04:01] <scarabeus> if nothing evil happen
-[21:04:17] <jmbsvicetto> At least not before we get 2 KDE4 minor versions marked stable
-[21:04:22] <bonsaikitten> I is here, mostly :)
-[21:04:38] <jmbsvicetto> So if we got 4.2 and 4.3 marked stable, then we could consider dropping 3.5 from the tree
-[21:04:38] <wired> we'll probably need an announcement and a news item and any other possible means of communication to alert current kde3 users that they have to add the overlay if they want kde3
-[21:04:59] <wired> a few months before we remove it
-[21:05:04] <scarabeus> that is simple news item
-[21:05:13] <scarabeus> ad it can go hand in hand with mask :]
-[21:05:23] <scarabeus> i think 3 month mask for this is good idea :]
-[21:05:26] <dagger> I think we should make such news after first kde4 goes stable
-[21:05:32] <wired> its simple but it can also be devastating if we forget :p
-[21:05:44] <scarabeus> and before i forget "DID ANYONE FIND SOME CONTRIBUTORS?"
-[21:06:10] <reavertm> I suppose we'll find some gentoo devs still with 3.5
-[21:06:13] <yngwin> iirc sping showed some interest before the summer
-[21:06:37] <yngwin> he's resuming recruitment process now
-[21:07:00] <scarabeus> will you talk to him and find out?
-[21:07:07] <scarabeus> *mind
-[21:07:08] <yngwin> i can yes
-[21:07:28] <Ronis_BR> I don't know if my opinion counts, but I really agree to dagger, you should announce that even befor kde4 is marked as stable. It may be very painful for some users to make the change.
-[21:07:49] <scarabeus> he has point ^
-[21:08:16] <reavertm> scarabeus: kde3 packages moved to overlay won't be subject of package.mask, will they?
-[21:08:17] <dagger> some people dont like kde4 and we wont change it. We just need to make sure they've got enough time to get use to overlay
-[21:08:28] <reavertm> (they shouldn't imho)
-[21:08:29] <wired> we just need to make sure that people will have the overlay added before we remove the ebuilds
-[21:08:32] <scarabeus> reavertm: wont
-[21:08:39] <wired> and i agree we reavertm we shouldnt mask it
-[21:08:40] <ABCD> I would suggest announcing loudly and often, in many venues so that (hopefully) very few users are taken by suprise
-[21:08:41] <reavertm> (just have keywords dropped probably)
-[21:08:44] <yngwin> and it needs to be stable before it is marked stable
-[21:08:46] <jmbsvicetto> scarabeus: news item, planet blog entries, forums thread, front page announcement, ... ;)
-[21:09:04] <dagger> jmbsvicetto: sounds good
-[21:09:40] <scarabeus> jmbsvicetto: can you do it, please please our PR farry
-[21:10:22] <yngwin> i'd wait with too widespread announcements until there is a stable candidate
-[21:10:45] <reavertm> indeed
-[21:11:00] <scarabeus> well i was not saying NOW i mean when the time will come
-[21:11:04] <reavertm> (which movesus towards second topic)
-[21:11:04] <dagger> that moves us to point no 2
-[21:11:25] <scarabeus> wait a bit, i have one problem with kde3
-[21:11:44] <scarabeus> i have seen that debian ship more patches marked as security for kde3 than we even have as bugs
-[21:11:55] --> ahf (i=ahf@irssi/staff/ahf) has joined #gentoo-meetings
-[21:12:14] <yngwin> we need people now to start maintaining kde3
-[21:12:49] <scarabeus> or mask it right after we stable first kde4, dont say remove just mask for sec-issues
-[21:13:17] <dagger> kde3 is dead end. I think we need to decide how long are we going to maintain it
-[21:13:26] <yngwin> users wont be happy, but i have to agree
-[21:14:04] <reavertm> I'd suggest faster gentoo stable releases so that we can keep up with stable version being the one actually yet supported by upstream
-[21:14:08] <scarabeus> i think we can write some news item onto the homepage/spread as news
-[21:14:20] <scarabeus> and if noone will volunteer to work on it in 7 days...
-[21:14:22] <reavertm> for example 4.2 branch is no longer mainataned...
-[21:14:26] <jmbsvicetto> scarabeus: ok
-[21:14:30] <jmbsvicetto> scarabeus: About the news
-[21:14:48] <yngwin> i agree, we need to recruit kde3 maintainers immediately
-[21:14:49] --> tampakrap (n=tuxicity@gentoo/developer/tampakrap) has joined #gentoo-meetings
-[21:15:04] <scarabeus> tampakrap: you, here, how, why
-[21:15:11] <dagger> go home!
-[21:15:14] <tampakrap> just for logs bye
-[21:15:14] <jmbsvicetto> reavertm: What do you mean about the package.mask? Do you mean masking KDE3 ebuilds now or after they're moved to the overlay?
-[21:15:16] <dagger> ^^
-[21:15:58] <scarabeus> jmbsvicetto: he was worried if we would keep the mask in tree after we move it to the overlay, which is NO
-[21:16:13] <reavertm> what scarab said
-[21:16:19] <yngwin> if we mask it, we might as well move it
-[21:16:40] <jmbsvicetto> scarabeus / reavertm: I see and I agree with you - no
-[21:16:55] <scarabeus> no, users sometimes hate overlays, unmasking is simple
-[21:17:00] <scarabeus> or we actualy can let them decide
-[21:17:10] <jmbsvicetto> But we shouldn't mask it until some time after we get KDE-4 marked stable
-[21:17:14] <scarabeus> i would start with the anouncing call for maintainers on homepage and on all pcs
-[21:17:27] <scarabeus> then we will know if someone cares
-[21:17:32] <scarabeus> we can recruit the peeps
-[21:17:35] <scarabeus> we have the powah
-[21:17:37] <scarabeus> :]
-[21:17:37] <jmbsvicetto> I'm sorry, but half my brain is being pulled to #gentoo-userrel
-[21:17:55] <scarabeus> jmbsvicetto: yes that we mentioned too, after at least 1 kde4 stabled
-[21:18:48] <yngwin> but if there are security issues that nobody is fixing, we may need to mask earlier
-[21:19:04] <scarabeus> jmbsvicetto: anouncement on homepage and as newsitem if noone reply in timely manner (week) then after
-[21:19:04] <scarabeus> kde4 is stabilised we will right away mask it as security threat. then it will live until
-[21:19:04] <scarabeus> kde4.4 but masked/or in overlay (to be decided).
-[21:19:16] <scarabeus> this is my braindead summary
-[21:19:51] <reavertm> agreed
-[21:19:55] <dagger> I would say make kde4.a stable, than make kde4.b stable and mask kde3
-[21:20:23] <dagger> unless critical bugs will force us to make it earlier
-[21:20:30] <scarabeus> dagger: there must be security ones
-[21:20:32] <dagger> mask*
-[21:20:49] <scarabeus> just browse debian patches
-[21:20:51] <Gentoochild> another thing to consider when ditching KDE3 is whether all kde3 apps are available for kde4 (like k3b)
-[21:21:06] <dagger> k3b for kde4 works perfectly
-[21:21:10] <scarabeus> Gentoochild: security has privilege
-[21:21:13] <Gentoochild> (was jsut an exampolke)
-[21:21:14] <reavertm> dagger: not really
-[21:21:14] <yngwin> mythtv seems to be a problem
-[21:21:30] <reavertm> I wonder whether leaving kdelibs:3.5 + some apps would be a problem
-[21:21:32] <dagger> reavertm: I'm using it 2-3 times a week for cd dvd5/9 - all fine
-[21:21:43] <wired> reavertm thats what i was thinking as well
-[21:22:00] <wired> maybe we can leave kdelibs3 and a few apps around for a little longer (like +6 months)
-[21:22:10] <jmbsvicetto> yngwin: I wouldn't mask it, but after we get one KDE4 version marked stable, we should start warning users *publicly* to the status of KDE3 security
-[21:22:13] <reavertm> dagger: try writing udf image wth verify - it will lock on 50% on disk eject, but that's off topic
-[21:22:29] <reavertm> jmbsvicetto: what are those security issue? khtml?
-[21:22:37] <jmbsvicetto> yngwin: If that upsets upstream, I don't care. Maybe it might lead someone to start fixing issues
-[21:22:41] <scarabeus> reavertm: khtml as starters
-[21:22:42] <yngwin> jmbsvicetto: no it's very simple: if there are security issues they need to be fixed or the affected packages masked
-[21:22:47] <scarabeus> there was some more in kdelibs and parts
-[21:22:56] <scarabeus> simple tracking debian can work
-[21:22:57] <reavertm> maybe it's easier just to dump kde desktop (along with affected apps) and leave kdelibs + some apps that are known to work
-[21:22:59] <scarabeus> but we need that maintainer
-[21:23:23] <Ronis_BR> I use Kile very often, and the kde4 version of if is far far away to be usable...
-[21:23:35] --> ABCD_ (n=ABCD@gentoo/contributor/abcd) has joined #gentoo-meetings
-[21:23:53] <jmbsvicetto> yngwin: As a Gentoo policy, you're right. But in that case we should probably have masked KDE-3 a few months ago
-[21:24:03] <yngwin> yes
-[21:24:11] <scarabeus> jmbsvicetto: yes but now we will have stable replacement
-[21:24:14] <yngwin> so let's try to make things right asap
-[21:24:29] <-- ABCD (n=ABCD@gentoo/contributor/abcd) has quit (Nick collision from services.)
-[21:24:32] <scarabeus> i would say wait with this decision we can wait for the anouncement and proceed if noone appears
-[21:24:33] <ABCD_> could someone PM me the logs from "<scarabeus> this is my braindead summary" through my re-joining?
-[21:24:48] <-> ABCD_ is now known as ABCD
-[21:24:50] <reavertm> I suppose masking the only stable kde release is not an option so please make sure we have one left :P
-[21:25:08] <wired> sure hold on
-[21:25:45] <yngwin> reavertm: if no maintainers step up, that is currently our only option
-[21:26:38] <jmbsvicetto> yngwin: ok
-[21:26:48] <reavertm> then we should do as scarabeus said
-[21:27:07] <dagger> can we make a poll on forums, to see how many users still use kde3 and how many moved to kde4?
-[21:27:33] <jmbsvicetto> yngwin: but we should all be aware that even when kde-4 gets marked stable, it's very unlikely that any arch besides x86, amd64, ppc and ppc64 will get it marked stable soon
-[21:27:34] <yngwin> yes we can
-[21:27:35] <scarabeus> dagger: well usage is not our issue, we need maintainers
-[21:27:37] <dagger> of course it will represent only small percentage of users, but should give us some guidelines
-[21:27:51] <ayoy> hey there
-[21:27:54] <scarabeus> jmbsvicetto: i bet on hppa
-[21:28:01] <yngwin> jmbsvicetto: sure, i dont think it will be marked stable soon on any arch
-[21:28:09] <jmbsvicetto> yngwin: so masking kde-3 will upset quite a few users from these arches, but it will also upset people in the other arches
-[21:28:35] <jmbsvicetto> scarabeus: Don't forget ia64 or sparc
-[21:28:42] <yngwin> so the key is to get some ppl to step up and maintain&fix
-[21:28:55] <scarabeus> yes
-[21:29:01] <scarabeus> so exactly what i said
-[21:29:05] <jmbsvicetto> scarabeus: sparc is still tied to qt-webkit dying with alignment issues
-[21:29:20] <scarabeus> so no cookies for sparc
-[21:29:32] <scarabeus> jmbsvicetto: i agree it is bad solution, but it is worse to leave it rot around
-[21:29:40] <scarabeus> at least 1 maintainer
-[21:29:48] <scarabeus> it is not so hard, the ebuilds are mostly cleaned and fixed
-[21:29:56] <scarabeus> they just need the patches and testing
-[21:29:57] <jmbsvicetto> scarabeus: And unfortunately, it seems each day KDE upstream is more concerned with Windows,OS/X than with Linux alternative arches
-[21:30:15] <scarabeus> i expected that one
-[21:30:34] <jmbsvicetto> scarabeus: I'm not arguing against your proposal. I'm just making a few "warning" ;)
-[21:30:46] <scarabeus> so you can show the logs when they blame you :P
-[21:30:48] <scarabeus> :DDDDD
-[21:30:58] <yngwin> they can still unmask or use overlay if they want kde3
-[21:31:02] <scarabeus> i would say lets go for next subject
-[21:31:22] <reavertm> agreed
-[21:32:06] <scarabeus> i summarised it really nicely and jorge as boss can tweak it more to reflect us so we all write our proposals for it
-[21:32:15] <scarabeus> jmbsvicetto: one Q, did you see carlo lately?
-[21:32:31] <scarabeus> jmbsvicetto: he did kde3 commits when he was around, so that is why i ask :]
-[21:33:18] <scarabeus> the awkard silence...
-[21:33:36] <scarabeus> okey so for the 4.2 stabling i would say vote?
-[21:34:04] <yngwin> i vote hell no
-[21:34:05] <wired> i say we go for 4.3
-[21:34:10] <dagger> hell no
-[21:34:13] <wired> so no =]
-[21:34:21] <dagger> 4.3 is the way to go
-[21:34:25] <reavertm> I vote.. wait for 4.3.1
-[21:34:34] -*- yngwin is with reavertm
-[21:34:45] <reavertm> there's one 'problem'
-[21:34:51] <dagger> yeah, 4.3.1 sounds like the best candidate
-[21:34:53] <scarabeus> you know my opinion but for the record 4.3
-[21:35:00] <reavertm> kde 4.3 will need phonon-4.4pre
-[21:35:08] <scarabeus> the snapshot is stable
-[21:35:11] <scarabeus> where is the issue
-[21:35:20] <yngwin> what snapshot
-[21:35:21] <reavertm> which is good as it works very well, just doen't look official (and it's not, it's our snapshot)
-[21:35:26] <scarabeus> phonon
-[21:35:39] <scarabeus> reavertm: i would say it is ook
-[21:35:46] <scarabeus> it works peachy for everyone around here
-[21:35:49] <reavertm> second thing - akonadi-server sqlite USE flag could be masked in profile
-[21:35:59] <scarabeus> reavertm: why? it is so borked?
-[21:36:04] <scarabeus> i didnt get time to test it yet
-[21:36:13] <jmbsvicetto> scarabeus: ok
-[21:36:13] <jmbsvicetto> scarabeus: carlo? no
-[21:36:13] <yngwin> no prblems with phonon
-[21:36:42] <jmbsvicetto> scarabeus: I'll have to double check, but I think he's got under undertakers view
-[21:36:42] <reavertm> no idea, works for me, but upstream says sqlite threads support is broken sometimes and may cause data loss when using sqlite backend
-[21:36:47] <jmbsvicetto> scarabeus: meaning is subject to retirement for inactivity
-[21:36:54] <scarabeus> jmbsvicetto: understood
-[21:37:00] <reavertm> and I think would just need better testinb whether it's really the case
-[21:37:04] <jmbsvicetto> About KDE4, 4.2.4
-[21:37:08] <dagger> data loss = mask it
-[21:37:15] <jmbsvicetto> If we wait for 4.3, time will fly by us
-[21:37:35] <yngwin> 4.2.4 is not stable, boss
-[21:37:35] <reavertm> (mysql is enabled by default for now and sqlite is marked as experimental in pkg_postinst anyway)
-[21:37:40] <jmbsvicetto> 4.3.0 has some nasty bugs that upstream has admitted already and 4.3.1 shouldn't be out before 1st or 2nd week of September
-[21:37:42] <yngwin> neither is 4.3.0
-[21:37:48] <dagger> jmbsvicetto: yes and no. 4.2 is no longer maintained, and 4.3.1 will give us some time to fix some bugs in 4.3
-[21:37:58] <jmbsvicetto> Add at least 1 month to that for asking for it to be marked stable and we'll be getting very close to the year's end
-[21:38:38] <scarabeus> yep, but i think we need 1 month to fix all the issues we have in the tracker anyway
-[21:38:39] <jmbsvicetto> yngwin: I think 4.2.4 is not a perfect release, but it's getting very close and will allow us to have a stable version almost 2 months before 4.3
-[21:38:52] <dagger> I believe having 4.3.1 stable by the time 4.3.3 is released sounds good
-[21:38:55] <reavertm> of course before anyone thinks of any kde4 stabilization, blocker bugs needs to be fixed first
-[21:38:59] <yngwin> 4.2.4 is usable, but certainly not stable
-[21:39:13] <jmbsvicetto> 4.2.4 is my vote - but majority rules ;)
-[21:39:23] <scarabeus> yeah we rule and you rock :]
-[21:39:28] <scarabeus> (you know the joke right?)
-[21:39:35] -*- reavertm knows
-[21:39:35] <dagger> 4.3.0 is more stable than 4.2.4 ;)
-[21:39:45] -*- scarabeus confirm
-[21:39:50] <Ronis_BR> If i can vote, I vote on 4.3.1, 4.3.0 crashes sometimes...
-[21:40:03] <Ronis_BR> much more than 4.2.4 in fact
-[21:40:09] <reavertm> actually stability wise i have never had plasma crash yet on 4.3.9999 (and there were some on 4.2 for me)
-[21:40:16] <dagger> i never had a crash on 4.3.0, but saw some bugs about it
-[21:40:36] <yngwin> i'm having plasma issues with both 4.2.4 and 4.3.0
-[21:41:05] <reavertm> my vote is to go with 4.3.1 (or 4.3.0 with some patches added) and if so - remove 4.2.4 from tree
-[21:41:18] <yngwin> well, not on 4.2 anymore as i upgraded both boxes now
-[21:41:24] <dagger> the only plasmoid which crashes plasma for me is microblogging = 100% crash rate
-[21:41:30] <Ronis_BR> reavertm: I don't mean a plasma crash, but dolphin crashes, konqueror crashes sometimes, and plasma crashes :D but it isn't often and it "recover" itself all the times here
-[21:41:56] <reavertm> I doubt anyone still uses 4.2 - adding 4.3 umasked was epic kill for idea of stabilizing 4.2
-[21:42:01] <yngwin> on 4.2.4 i had plasma crashes completely freeze up X
-[21:42:23] <scarabeus> i am for that removal
-[21:42:26] <scarabeus> 4.2
-[21:42:27] <dagger> so, do we need to count the votes than?
-[21:42:36] <scarabeus> dagger: no need, only boss was for 4.2
-[21:42:36] <dagger> or is it decided
-[21:42:40] <Ronis_BR> yngwin: i can be video drivers issue, I have never had a X freeze up with kde 4.2.*
-[21:42:49] <yngwin> nvidia
-[21:42:53] <Ronis_BR> yngwin: ati
-[21:42:59] <reavertm> nvidia, worksformetm
-[21:43:08] <wired> what reavertm said
-[21:43:10] <scarabeus> btwwho is working on stable bugs?
-[21:43:20] <scarabeus> i saw only reaver commenting on them and i closed few
-[21:43:24] <scarabeus> but the list is still large
-[21:43:29] <dagger> intel 4500hd and nvidia here. Nvidia doesn't like new kernel and heci (from staging) driver
-[21:43:34] <scarabeus> i need to ask you to pick 1-2 from there and fix them
-[21:43:39] <reavertm> some of them are gfx driver issues
-[21:43:54] <reavertm> yeah, we need them fixed asap
-[21:44:16] <yngwin> ok, can we move on?
-[21:44:33] <scarabeus> i want to hear that they read what i wrote ^
-[21:44:39] <scarabeus> :D
-[21:44:57] <reavertm> summary of no. 2 please :)
-[21:45:32] <scarabeus> http://www.pastebin.cz/22046
-[21:45:34] <scarabeus> here you are
-[21:45:50] --> Coopy (n=Coop@p4FEDA352.dip.t-dialin.net) has joined #gentoo-meetings
-[21:46:01] <dagger> looks good
-[21:46:28] <scarabeus> yngwin: next topic is yours
-[21:47:07] <yngwin> ok, we're ready to add qt4-tng.eclass to portage, no alternative names have been proposed
-[21:47:39] <yngwin> i plan to do a review this weekend and send it to -dev ml for rfc
-[21:48:06] <scarabeus> qt4-superstar could go?
-[21:48:09] <scarabeus> qt4-meh
-[21:48:11] <scarabeus> :]
-[21:48:12] <wired> lol
-[21:48:15] <dagger> qt4-blah ?
-[21:48:17] <wired> qt4-v2 ?
-[21:48:23] <ayoy> qt5
-[21:48:25] <scarabeus> :D
-[21:48:26] <yngwin> qt4-thisistheoneyouwant
-[21:48:27] <wired> im a bit worried about tng, it sounds good and all
-[21:48:31] <wired> ayoy: LOL
-[21:48:39] <-- |Francis| (n=kvirc@AGrenoble-152-1-28-162.w82-122.abo.wanadoo.fr) has quit (Remote closed the connection)
-[21:48:48] <wired> but what if we want to replace it again in the distant future
-[21:48:59] <Ronis_BR> what is tng?
-[21:49:01] <dagger> qt4-tng sounds a lil bit like star trek, but I think we can live with it ;p
-[21:49:04] <yngwin> well, you can send bikeshedding proposals once the rfc is on ml
-[21:49:04] <scarabeus> well you can live with one damn eclass like us
-[21:49:08] <wired> it doesnt sound like it
-[21:49:10] <scarabeus> Ronis_BR: the next generation
-[21:49:11] <wired> it is startrek
-[21:49:12] <wired> :p
-[21:49:16] <Ronis_BR> O_o
-[21:49:30] <Ronis_BR> wierd :)
-[21:49:39] <Gentoochild> to baldly go where no-one has gone before
-[21:49:44] --> |Francis| (n=kvirc@AGrenoble-152-1-28-162.w82-122.abo.wanadoo.fr) has joined #gentoo-meetings
-[21:49:48] -*- wired wonders if after tng we'll have the-empire-strikes-back or something
-[21:49:51] <wired> :P
-[21:49:55] <scarabeus> to baldly compile what noone else was able to do
-[21:50:03] <dagger> wired: lol
-[21:50:08] <yngwin> wired: good name for kde3 overlay maybe?
-[21:50:13] <wired> :D
-[21:50:16] <ayoy> lol
-[21:50:21] <scarabeus> yngwin: i am open for proposals
-[21:50:27] <scarabeus> and i have strong feelings for this one
-[21:50:31] <scarabeus> :}
-[21:50:32] <Ronis_BR> eheheh
-[21:50:38] <ayoy> but isn't qt4-tng or whatever meant to replace the old qt4.eclass?
-[21:50:47] <yngwin> eventually yes
-[21:51:00] <wired> qties4.eclass
-[21:51:01] <wired> :D
-[21:51:07] <dagger> we can't just dump the old one and put the new one in place
-[21:51:11] <yngwin> no
-[21:51:12] <scarabeus> you cant
-[21:51:13] <ayoy> dagger: sure
-[21:51:17] <scarabeus> you would break the ebulds
-[21:51:22] <scarabeus> *current
-[21:51:22] <dagger> yep
-[21:51:24] <wired> yes we need a migration
-[21:51:30] <reavertm> you guys should really "learn" how to make drastic eclass changes in place like we do :D (with no new eclasses involved)
-[21:51:33] <Ronis_BR> qt4-tng is a gentoo version with patches or not?
-[21:51:36] <yngwin> unless you want to check all ebuilds that use qt4.eclass wrt new functionality
-[21:51:39] <scarabeus> reavertm: see this is reason why i slapped you everytime for backcompat
-[21:51:50] <reavertm> scarabeus: with kde-misc? :P
-[21:51:58] <wired> its TNG folks
-[21:52:05] <wired> does picard look like kirk to you?
-[21:52:07] <wired> :D
-[21:52:10] <scarabeus> reavertm: yep :]
-[21:52:20] <scarabeus> kirk had better chicks
-[21:52:22] <scarabeus> they had skirts
-[21:52:23] <dagger> ok, back to the point please
-[21:52:24] <-- Coopy (n=Coop@p4FEDA352.dip.t-dialin.net) has quit ("Leaving")
-[21:52:29] <scarabeus> ok ok
-[21:52:33] <scarabeus> i think tng is done
-[21:52:49] <yngwin> as far as i'm concerned yes
-[21:53:02] <reavertm> or just qt4-0.1.eclass
-[21:53:10] <reavertm> (then 0.2 for next revision :P)
-[21:53:13] <Ronis_BR> "Backcompat is to still commit in the present the errors commited in the past"
-[21:53:15] <scarabeus> jmbsvicetto: you should push your versioned eclasses idea
-[21:53:28] <scarabeus> ok anyway
-[21:53:36] <scarabeus> the last thing is bit brainstorming
-[21:53:42] <scarabeus> what shoudl we focus on in future
-[21:53:45] <reavertm> too bad you can't do it in place
-[21:54:32] <ABCD> I remember seeing an agenda item in some email about the unversioned sets
-[21:54:35] <jmbsvicetto> sorry guys - mind at userrel
-[21:55:11] <scarabeus> ABCD: i was waiting on jorge to come back so i left it as totaly last
-[21:55:19] <ABCD> scarabeus: ok
-[21:55:21] <jmbsvicetto> scarabeus: That idea wasn't mine, I just pulled it out of the dust ark ;)
-[21:55:38] <scarabeus> :]
-[21:55:46] <scarabeus> ok any ideas/proposals what we should focus
-[21:55:51] <scarabeus> we will have new recruits
-[21:55:51] <jmbsvicetto> scarabeus: The versioned eclasses
-[21:55:58] <scarabeus> jmbsvicetto: i understood
-[21:56:07] <scarabeus> and for them we need something creative to do
-[21:56:12] <scarabeus> we cant just leave them fix bugs
-[21:56:14] <scarabeus> same for us
-[21:56:22] <scarabeus> if i would only fix bugs i would went insane
-[21:57:10] <yngwin> in qt team we are actively looking at adding new qt4-based packages all the time
-[21:57:13] <scarabeus> i had idea about branding, but then i cant draw
-[21:57:22] <ayoy> :)
-[21:57:33] <scarabeus> so someone else would have to mentor the idea
-[21:57:34] <yngwin> documentation could use more work too
-[21:57:49] <ayoy> I had an idea of qt-based portage gui
-[21:57:56] <ayoy> but then I wouldn't use it
-[21:58:00] <scarabeus> :D
-[21:58:06] <dagger> ayoy: noone would I think :p
-[21:58:09] <ayoy> :)
-[21:58:10] <jmbsvicetto> scarabeus: There's always the "fix upstream build system" idea ;)
-[21:58:21] <yngwin> there was a kde(3?) one iirc
-[21:58:21] <wired> scarabeus: branding is actually a lovely idea, remember that gentoo kstart icon quantumsummers had?
-[21:58:24] <wired> we need artists
-[21:58:25] <reavertm> I have some task, not sure whether suitable for newcomers
-[21:58:40] <scarabeus> i have tasks not suitable for myself :D
-[21:58:44] <scarabeus> so go on
-[21:58:45] <scarabeus> :]
-[21:58:47] <reavertm> I need eclass for odbc driver management
-[21:59:01] <reavertm> supporting iODBC and unixODBC interfaces
-[21:59:35] <scarabeus> well that is totaly not beginner work
-[21:59:37] <ayoy> ok, next
-[21:59:40] <dagger> I'm sorry guys, but I will have to leave you now. I need to pick up my wife.
-[21:59:48] <reavertm> registering/unregistring drivers, in similar way like in debian, (but separately - one for iODBC and one for unixODBC)
-[21:59:56] <wired> c ya dagger
-[22:00:21] <reavertm> (it should be easy, mostrly it's just invocation of unixodbc tool with creating some files in /etc)
-[22:00:33] <scarabeus> well if you find interested recruit go for it
-[22:00:36] --> Francois (n=francois@193.253.141.72) has joined #gentoo-meetings
-[22:00:50] <scarabeus> reavertm: question. how is your reviewing going by?
-[22:01:08] <reavertm> I'm lazy to send fixed quizzes
-[22:01:25] <scarabeus> gosh
-[22:01:31] <scarabeus> please do so
-[22:01:34] <scarabeus> sooon
-[22:01:35] <scarabeus> :]
-[22:01:35] <reavertm> nevermind
-[22:01:47] <scarabeus> ok last topic is SETS
-[22:01:53] <scarabeus> I hate the current state
-[22:01:56] <scarabeus> i preffer metas more
-[22:02:12] <scarabeus> so we need someone to write proper specs for what we need from sets
-[22:02:12] <-- |Francis| (n=kvirc@AGrenoble-152-1-28-162.w82-122.abo.wanadoo.fr) has quit (Read error: 104 (Connection reset by peer))
-[22:02:21] <scarabeus> and talk about it with zac
-[22:02:27] <scarabeus> and even better help him implementing
-[22:02:34] <scarabeus> jmbsvicetto: ^ ?
-[22:02:38] <reavertm> oh yes, have anyone read bug 272488 ?
-[22:02:40] <scarabeus> am i right?
-[22:02:53] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=272488
-[22:03:04] <scarabeus> i did i liked
-[22:03:08] <jmbsvicetto> reavertm: That sounds like an eselect and not eclass (odbc)
-[22:03:09] <scarabeus> you volunteer?
-[22:03:29] <jmbsvicetto> scarabeus: I'll take this one
-[22:03:47] <jmbsvicetto> scarabeus: I've been meaning to write about it for a *long* time, but I keep postponning it
-[22:03:48] <scarabeus> jmbsvicetto: use teh bug as base, i like the idea
-[22:03:57] <jmbsvicetto> scarabeus: Can I ask you to poke me about it until I do? ;)
-[22:04:54] <reavertm> jmbsvicetto: hmm, not really, it would be eclass for packages that provide odbc driver
-[22:04:55] <jmbsvicetto> reavertm: I know the bug. My plan is to get back to the basics about sets
-[22:05:07] <reavertm> it's not about switching between iodbc vs unixodbc
-[22:05:07] <scarabeus> if you promise you wont mark me as your counter person for next lead vote ;]
-[22:05:09] <scarabeus> :D
-[22:05:11] <scarabeus> ok can do
-[22:05:13] <reavertm> (it's determined at compilation time)
-[22:05:18] <Ronis_BR> I wonder when gentoo guys will look at https://bugs.gentoo.org/show_bug.cgi?id=268891
-[22:05:18] <jmbsvicetto> reavertm: ok, then I misunderstood. sorry
-[22:05:46] <jmbsvicetto> scarabeus: Are you affraid instead I'll point to you when it gets time for the next election? ;)
-[22:06:04] <scarabeus> :D
-[22:06:20] <scarabeus> okey
-[22:06:28] <scarabeus> anything else for the sets, we will leave them to you
-[22:06:32] <scarabeus> and poke you about it :]
-[22:06:42] <reavertm> jmbsvicetto: I think 2.2 style sets are dead end
-[22:07:02] <reavertm> confusing syntax
-[22:07:39] <yngwin> what i want is kde-latest-release sets
-[22:07:58] <scarabeus> that is quite hard to make but i see the point :]
-[22:08:00] <yngwin> so that 4.2.4 would be automatically updated to 4.3.0
-[22:08:19] <jmbsvicetto> yngwin: that's basically unversioned sets ;)
-[22:08:21] <scarabeus> also i think we should stop encouraging set usage in docs
-[22:08:24] <yngwin> yes
-[22:08:33] <wired> the unversioned sets work like that :)
-[22:08:39] <scarabeus> they dont
-[22:08:44] <scarabeus> too much package fuzz movement
-[22:08:52] <scarabeus>  /
-[22:09:07] <jmbsvicetto> scarabeus: they do - the problem is our "non-stopping" upstream ;)
-[22:09:42] <yngwin> ok, anything else for the meeting?
-[22:10:01] <jmbsvicetto> scarabeus: They have what we call here "bicho de carpinteiro". They can sit still for a minute and thus keep moving packages left and right, adding new ones, killing old ones and finding new and better ways to make distros life harder ;)
-[22:10:11] <wired> do you guys think we should move the plasmoids from kde-testing to the tree?
-[22:10:13] <jmbsvicetto> The can't sit still*
-[22:10:24] <scarabeus> wired: we can
-[22:10:30] <jmbsvicetto> wired: How good do you think they are?
-[22:10:32] <scarabeus> just test them for leaks
-[22:10:36] <scarabeus> and crashes
-[22:10:38] <scarabeus> everytime
-[22:10:40] <scarabeus> plasma is core
-[22:10:44] <scarabeus> if it crashes it is PITA
-[22:10:48] <wired> jmbsvicetto: some of them are pretty good, others i have no idea
-[22:10:59] <scarabeus> wired: then add the one you like
-[22:11:00] <wired> i mostly test that they build and occasionally that they load
-[22:11:09] <jmbsvicetto> wired: I don't see a problem with adding good ones
-[22:11:21] <scarabeus> but you really have to test them
-[22:11:24] <jmbsvicetto> and what scarabeus said ;)
-[22:11:31] <wired> ok so on a per-plasmoid basis
-[22:11:36] <wired> kk
-[22:11:55] <reavertm> well, kde developers doesn't test their code sometimes, so we should
-[22:11:56] <Ronis_BR> you have already discussed about kdeprefix i think, haven't you?
-[22:12:15] <scarabeus> Ronis_BR: that was decided long ago, not matter of this meeting
-[22:12:15] <reavertm> Ronis_BR: yes, it's dead (for now)
-[22:12:24] <Ronis_BR> ok
-[22:12:30] <Ronis_BR> too bad, but ok :)
-[22:12:40] <wired> Ronis_BR: we accept patches
-[22:12:40] <wired> :D
-[22:12:54] <ABCD> Ronis_BR: that was decided at the June meeting :)
-[22:13:12] <scarabeus> ok i would like to dismiss the meeting for this moth
-[22:13:14] <scarabeus> any objections?
-[22:13:25] <Ronis_BR> ABCD: sorry, it is the first time that I hear about gentoo meetings :)
-[22:13:39] <jmbsvicetto> scarabeus: Before we go, when should we have the next meeting?
-[22:13:41] <scarabeus> Ronis_BR: kde.gentoo.org its on the page, logs+summary
-[22:13:53] <reavertm> I suppose we don't need more meeting recently - just people eager to work on issues :P
-[22:13:54] <scarabeus> 17.9.
-[22:13:57] <scarabeus> jmbsvicetto: ^
-[22:14:02] <scarabeus> 3rd thursday in the month
-[22:14:09] <scarabeus> 19:00 utc
-[22:14:15] <scarabeus> if noone found it really evil or bad
-[22:14:17] <jmbsvicetto> right
-[22:14:33] <jmbsvicetto> Oh!!!
-[22:14:38] <yngwin> scarabeus: i will be on holiday that week
-[22:14:39] <reavertm> scarabeus: actually we could just meet in two weeks to evaluate work done
-[22:14:40] <jmbsvicetto> One last item I forgot to add to the meeting
-[22:14:50] <jmbsvicetto> Anyone willing to help solar about the 10.0 release?
-[22:15:00] <ABCD> I'll have to check my class schedule for Fall semester again, but I think that will work (it does fall in the middle of the day here, though)
-[22:15:10] <yngwin> jmbsvicetto: what kind of help
-[22:15:15] <jmbsvicetto> I want to help with KDE (and if I can compiz), but it would be great if more people could help
-[22:15:18] -*- scarabeus busy with x11stabling/overlays rework
-[22:15:54] <jmbsvicetto> yngwin: solar and a few others are working on catalyst specs to build a live-dvd with x86/amd64 to celebrate Gentoo's 10th birthday
-[22:16:08] <reavertm> catalyst....
-[22:16:22] <yngwin> well thats release team work
-[22:16:23] <scarabeus> jmbsvicetto: can they add ~ packages?
-[22:16:35] <scarabeus> yngwin: there is no such team iirc
-[22:16:36] <scarabeus> :D
-[22:16:37] <reavertm> they could add kde 4.3 :)
-[22:17:11] -*- yngwin sends thunderbolts scarabeus' way
-[22:17:13] <scarabeus> because if kde3 will be there, we can simply grab sabayon, it will be more promotial
-[22:17:23] <reavertm> and polished :P
-[22:18:15] <jmbsvicetto> scarabeus: There's an release team
-[22:18:26] <jmbsvicetto> But this is a "special edition"
-[22:18:39] <jmbsvicetto> scarabeus: The point is to have KDE4, not 3.5.10
-[22:18:40] <reavertm> solar or agaffney?
-[22:19:33] <-- Francois (n=francois@193.253.141.72) has quit (Client Quit)
-[22:20:27] <wired> ...?
-[22:20:36] <reavertm> release tem
-[22:21:30] <yngwin> http://www.gentoo.org/proj/en/releng/
-[22:22:24] <scarabeus> ok guys anyway i have to run
-[22:22:31] <scarabeus> here is the summary: http://dev.gentoo.org/~scarabeus/0908summary.txt
-[22:22:33] <scarabeus> do logs yourself
-[22:22:36] <scarabeus> jmbsvicetto: ^^
-[22:22:39] <scarabeus> download it NOW
-[22:22:44] <scarabeus> :D
-[22:23:08] <jmbsvicetto> scarabeus: ok
-[22:23:12] <-- tbeadle (n=quassel@division.aa.arbor.net) has left #gentoo-meetings ("http://quassel-irc.org - Chat comfortably. Anywhere.")
-[22:23:34] * scarabeus has changed topic for #gentoo-meetings to: "Rem tene, verba sequentur || Keep to the subject and the words will follow"
-[22:23:50] <jmbsvicetto> scarabeus: can't find the file in packer
-[22:23:54] <jmbsvicetto> pecker*
-[22:24:29] <wired> jmbsvicetto: it downloads, its in public_html probably :D
-[22:24:48] <wired> jmbsvicetto: i have logs, do you need them?
-[22:24:51] -*- yngwin out
-[22:25:14] <jmbsvicetto> scarabeus: please ignore me
-[22:25:32] <jmbsvicetto> wired: I can't connect through http at the moment, but thanks
-[22:25:55] <jmbsvicetto> wired: I got it from Tomas. I was just showing signs of my "split brains" :\
-[22:26:03] <wired> heheheh
-[22:26:09] <wired> no problem
-[22:26:20] <wired> did you log the meeting or you want me to give you my log?
-[22:26:57] <-- ABCD (n=ABCD@gentoo/contributor/abcd) has left #gentoo-meetings ("http://quassel-irc.org - Chat comfortably. Anywhere.")
-[22:27:50] <wired> jmbsvicetto: ^^
-[22:29:25] <jmbsvicetto> wired: I didn't log
-[22:29:36] <jmbsvicetto> wired: Thanks for reminding me I forgot to add a rule to my irssi about this
-[22:31:37] <-- ayoy (n=ayoy@cs78245237.pp.htv.fi) has left #gentoo-meetings ("kbai")
-[22:32:27] <wired> jmbsvicetto: yw
-[22:32:42] <wired> jmbsvicetto: so where do you want log? pecker?
-[22:35:05] <wired> jmbsvicetto: ~wired/kde/200908_meeting.log
-[22:36:24] <jmbsvicetto> wired: thanks
-[22:40:10] <wired> :)
-[22:41:49] <jmbsvicetto> scarabeus: I have another request for you - starting Saturday, poke me for the logs/summary ;)
-[23:10:08] <Gentoochild> \part
-[23:10:16] <-- Gentoochild (n=bla@vpn5.rz.tu-ilmenau.de) has left #gentoo-meetings ("Konversation terminated!")
-[23:17:09] <scarabeus> btw you can leave now, next on the list is gnome meeting, and i dont think you want to slack around that ;D
-[23:27:43] <reavertm> gnome meeting? nice
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090917.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090917.txt
deleted file mode 100644
index 0d64e9e85b..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090917.txt
+++ /dev/null
@@ -1,572 +0,0 @@
-[22:01:31] *** Joins: wired (n=wired@gentoo/developer/wired)
-[22:01:32] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi)
-[22:01:55] *** Joins: dabbott (n=david@gentoo/developer/dabbott)
-[22:02:07] *** Joins: toralf (n=toralf@g224122197.adsl.alicedsl.de)
-[22:02:33] *** Joins: Battousai (n=bryan@maduin.southcape.org)
-[22:03:44] * wired makes sure logging is on
-[22:04:59] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
-[22:05:07] <reavertm> I'm here
-[22:05:09] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
-[22:05:39] <wired> scarabeus: jmbsvicetto?
-[22:05:44] *** Quits: ABCD (n=ABCD@gentoo/developer/abcd) (Read error: 104 (Connection reset by peer))
-[22:06:02] *** Joins: ABCD (n=ABCD@gentoo/developer/abcd)
-[22:07:24] *** Quits: |Francis| (n=kvirc@AGrenoble-152-1-48-33.w82-122.abo.wanadoo.fr) (Remote closed the connection)
-[22:07:35] <reavertm> wasn't it moved to friday? :P
-[22:08:02] <wired> scarabeus sent "correction" email
-[22:08:02] <wired> :p
-[22:09:06] <jmbsvicetto> oh, I was already here
-[22:09:08] <wired> yeah
-[22:09:11] <wired> didn't i hilight you?
-[22:09:18] <wired> :P
-[22:09:25] <spatz> scarabeus said he might not make it, who else is late?
-[22:09:25] <ABCD> I'm not sure how well my connection is going to hold up, so...
-[22:09:29] <jmbsvicetto> Yeah, but I had forgot I was around here
-[22:10:27] * jmbsvicetto makes mental note - win 76
-[22:10:29] <jmbsvicetto> Anyone logging?
-[22:10:37] <reavertm> everytbody
-[22:10:43] <wired> i am
-[22:10:55] <wired> yngwin won't be coming, scarabeus too
-[22:10:56] <jmbsvicetto> ok
-[22:11:02] <wired> we're missing patrick, tampakrap
-[22:11:11] <reavertm> and some more qt representatives
-[22:11:26] <wired> ayoy spatz and Pesa are here
-[22:11:33] <wired> hwoarang is on long devaway
-[22:11:36] <jmbsvicetto> Let's give them a few more minutes?
-[22:11:38] <ayoy> yngwin is away too
-[22:11:47] <spatz> we're waiting for bonsaikitten?
-[22:12:05] <wired> i pinged them
-[22:12:07] *** Joins: bonsaikitten (i=quassel@gentoo/developer/bonsaikitten)
-[22:12:08] <spatz> good, on his way :)
-[22:12:19] *** Joins: tampakrap (n=tuxicity@gentoo/developer/tampakrap)
-[22:12:29] <wired> good
-[22:12:43] <jmbsvicetto> So, who wants to chair this one?
-[22:13:01] <jmbsvicetto> I could use the break to get ready another thing I'm working on
-[22:13:34] <tampakrap> hello
-[22:14:14] <wired> jmbsvicetto: i'll do it
-[22:14:45] <reavertm> good, do we have decisive power?
-[22:14:46] <wired> lets get going, first topic, 4.3 stabilization
-[22:14:58] <jmbsvicetto> wired: thanks
-[22:15:04] <reavertm> to vote stuff and such? it's quite few of us
-[22:15:26] <tampakrap> wired: roll call first
-[22:15:47] <spatz> here
-[22:15:58] <jmbsvicetto> reavertm: I don't think we have much to vote today. It's more about getting processes started
-[22:16:02] <jmbsvicetto> here
-[22:16:04] <wired> that was done, but present yourselves for the record if you want :)
-[22:16:26] <tampakrap> here
-[22:16:38] <ayoy> here
-[22:16:46] <reavertm> i am
-[22:16:56] <reavertm> ok, wired, move on
-[22:17:20] <wired> first topic, kde 4.3 stabilization
-[22:17:26] <wired> are we still going with 4.3.1?
-[22:17:34] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
-[22:17:38] <ABCD> here
-[22:17:52] <reavertm> yaah, we're going with 4.3.1, I wanted to bring this topic to...
-[22:18:14] <reavertm> gather some manpower to fix blocker bugs (or talk about dropping some blockers)
-[22:18:38] <wired> are there any specific blocks we should focus on?
-[22:18:50] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=277868
-[22:18:50] <spatz> is there a list/tracker?
-[22:18:54] <reavertm> this is bug
-[22:19:09] <wired> btw meeting agenta: http://archives.gentoo.org/gentoo-desktop/msg_1abe5bf232579eabb51aadc3d80b397b.xml
-[22:19:15] <jmbsvicetto> wired: yes
-[22:19:18] <wired> in case you don't have the mail available
-[22:20:10] <wired> 12 bugs
-[22:20:18] <jmbsvicetto> One thing we need to do ASAP is adding the patches being sent to the packagers ml
-[22:20:28] <wired> i agree
-[22:21:14] <wired> if we could focus these 2 weeks ideally we could request stablereq right after the 1 month period
-[22:21:26] <reavertm> yes
-[22:21:38] *** Joins: [Enrico] (n=chiccoro@gentoo/contributor/Enrico)
-[22:21:49] <reavertm> I've already set java as default backend so one bug less (about redland crashing)
-[22:21:58] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
-[22:22:03] <wired> great
-[22:22:03] <reavertm> and there's postinst message
-[22:22:35] <wired> so guys please do your best so we can finally have kde4 in stable :D
-[22:22:43] <jmbsvicetto> We should also start opening stabilization bugs for deps: automoc, strigi, soprano, phonon. Anything else?
-[22:23:04] <wired> are we stabling the phonon snapshot?
-[22:23:22] <reavertm> yes, it works fine
-[22:23:30] <reavertm> (it has unstable API)
-[22:23:44] <wired> well it'll have to do if thats all we've got
-[22:23:58] <reavertm> it's known to work anyway
-[22:24:05] <wired> ok
-[22:24:08] <jmbsvicetto> what's the minimum working version?
-[22:24:25] * wired looks ar reavertm 
-[22:24:29] <wired> at
-[22:24:38] <jmbsvicetto> And we need to get it stable or there'll be no stable KDE-4.3.1
-[22:25:12] <reavertm> 4.3.1 should od
-[22:25:23] <reavertm> do
-[22:25:33] <reavertm> but... mplayerthumps would need changes
-[22:25:48] <jmbsvicetto> By the way, we're including KDE-4.3.1 in the 10.0 livedvd, so we should try to get it stable around October 4th
-[22:25:49] <reavertm> (disabling phonon backend - as it only works with latest phonon)
-[22:25:59] <reavertm> otherwise kde would pull mplayer...
-[22:26:22] <jmbsvicetto> reavertm: can 't we leave it out? (mplayerthumbs)
-[22:26:39] <reavertm> why should we? part of kdemultimedia
-[22:27:00] <wired> whats wrong with having mplayer as a dep (besides an extra dep)? is it not working ok?
-[22:27:44] <wired> reavertm?
-[22:27:45] <reavertm> I suppose it is, whatever if you like one could go with 4.3.1 phonon and that change in mplayerthumbs
-[22:28:08] <jmbsvicetto> reavertm: I mean if it's too much trouble to get it working with current deps, we can leave it out for now and get it marked stable later (perhaps even on 4.3.2 or later releaes)
-[22:28:11] <reavertm> I won't die for this cause, 4.4pre is just not worse than 43.1
-[22:28:34] <wired> jmbsvicetto: well we have tested the phonon snapshot extensively
-[22:28:47] <jmbsvicetto> wired: ok
-[22:29:04] <jmbsvicetto> as long as its an exception (snapshots) ;)
-[22:29:10] <reavertm> I even asked some kde devs about it :P
-[22:29:36] <wired> jmbsvicetto: is there an issue with stabling it
-[22:29:36] <wired> ?
-[22:29:43] <wired> ok
-[22:29:52] * wired kicks isp for lag
-[22:30:07] <wired> anyone else wanna say anything about stabilization?
-[22:30:25] <reavertm> apart from get to work? :)
-[22:30:30] <tampakrap> yeah
-[22:30:43] <tampakrap> it isn't possible to have it fully stabilized until october 4th
-[22:30:58] <bonsaikitten> well, we need more stable testers ...
-[22:31:42] *** Joins: alexxy (n=alexxy@gentoo/developer/alexxy)
-[22:31:48] <wired> alexxy :)
-[22:31:51] <alexxy> hi all!
-[22:31:53] <reavertm> bonsaikitten: I use stable system :P
-[22:31:59] <alexxy> sorry that i'm late
-[22:32:02] <bonsaikitten> ooh :)
-[22:32:14] <reavertm> (with exceptions for kde and its deps)
-[22:32:15] <alexxy> isnt meeting was schedulet for tommorow?
-[22:32:22] <reavertm> initially it was
-[22:32:24] <wired> alexxy: scarabeus sent a correction email
-[22:32:25] <tampakrap> the problem is that the one month period is beyond that date
-[22:32:28] <wired> he failed at the date
-[22:32:31] <reavertm> nevermind, you missed nothing
-[22:32:43] <tampakrap> not to mention the time that arch teams need
-[22:33:15] <wired> tampakrap: no its not, you added the ebuilds on sept 1st
-[22:33:15] <wired> the problem is getting archs to stable it in 3 days
-[22:33:15] <wired> assuming we have fixed bugs
-[22:33:33] <tampakrap> one month with no open bugs
-[22:33:50] <jmbsvicetto> wired: 4.4_pre? Preferably we should do 4.3.1 instead, but if 4.4_pre solves other issues, let's go with it
-[22:33:54] <tampakrap> i hope i'm wrong on this one...
-[22:34:16] <jmbsvicetto> tampakrap: sure, but we can start the work to get it marked stable asap
-[22:34:30] <wired> jmbsvicetto: 4.4_pre20090520 yeah, thats the one we have in ~testing now
-[22:34:50] <jmbsvicetto> tampakrap: we can file an "early request" bug
-[22:35:00] <jmbsvicetto> tampakrap: it's up to arch teams whether they want to mark it stable or not
-[22:35:02] <tampakrap> ah ok then
-[22:35:07] <wired> and we also have one extra motive
-[22:35:09] <jmbsvicetto> tampakrap: and for the livedvd we only need amd64/x86
-[22:35:10] <wired> livedvd
-[22:35:33] <tampakrap> ok let's hope this will work then
-[22:35:47] <wired> I recommend we do a mini meeting next week
-[22:35:56] <reavertm> may be
-[22:35:57] <wired> to check on the state of bugs
-[22:35:59] <jmbsvicetto> tampakrap: Besides, I think we're starting to have many amd64/x86 users on KDE-4
-[22:36:00] <tampakrap> nice idea
-[22:36:16] <jmbsvicetto> wired: good idea
-[22:36:49] <wired> same day next week? 24th?
-[22:37:20] <tampakrap> fine by me
-[22:37:35] <wired> great, i'll send the email, we can adjust if needed
-[22:37:36] <jmbsvicetto> wired: sure
-[22:37:57] <wired> lets do our best and close all bugs :D
-[22:38:07] <wired> ok enough with this then, lets proceed
-[22:38:17] <wired> kde3.5, kde-sunset
-[22:38:28] <wired> who's taking care of this and can give us an update?
-[22:38:33] <wired> tampakrap?/
-[22:38:41] <tampakrap> there is no progress in that subject
-[22:38:59] <tampakrap> apart from the fact that scarabeus created the overlay :P
-[22:39:01] <jmbsvicetto> On that spirit, I'd like to ask all of you interested in the livedvd to join #gentoo-ten get the ISOs, test them and fix any KDE bugs
-[22:39:06] <reavertm> so nobody is interested - good :)
-[22:39:19] <wired> reavertm: heh
-[22:39:20] <jmbsvicetto> I'm "owing" an email about it
-[22:39:28] <wired> jmbsvicetto: lol click send
-[22:39:48] <jmbsvicetto> The official email putting the "death seal" on KDE-3.5
-[22:39:51] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
-[22:39:55] <wired> ah that one
-[22:40:25] <wired> is anyone else interested in helping make the move to kde-sunset?
-[22:40:39] <wired> besides tampakrap? :P
-[22:40:45] <reavertm> no!
-[22:40:53] <reavertm> it should rot and die
-[22:40:56] <jmbsvicetto> hehe
-[22:40:56] <wired> reavertm: think positive, we'll get rid of it from the tree
-[22:40:58] <wired> :D
-[22:40:58] <tampakrap> i agree noone else is needed
-[22:41:07] <tampakrap> we just need to stabilize kde4 and kill 3
-[22:41:08] <jmbsvicetto> wired: I can help move the ebuilds there
-[22:41:22] <wired> great
-[22:41:34] <wired> not sure if we need scarabeus to give us access to it or if he added us all
-[22:42:03] <wired> ok, next item
-[22:42:06] <wired> kdeprefix
-[22:42:09] <tampakrap> wait
-[22:42:12] <tampakrap> about kde3
-[22:42:15] <wired> yeah?
-[22:42:26] <tampakrap> i have set some rules before moving ebuilds to kde-sunset
-[22:42:49] <wired> you should make Documentation/CODE
-[22:42:50] <tampakrap> i sent them in the previous meeting through scarabeus because i wasn't present then
-[22:42:55] <tampakrap> ah ok
-[22:43:05] <tampakrap> nice idea #2
-[22:43:25] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
-[22:43:29] <wired> OK
-[22:43:34] <wired> anyone else anything about kde3?
-[22:44:06] <wired> moving on then
-[22:44:08] <wired> kdeprefix
-[22:44:18] <wired> not sure what scarabeus had in mind when he added it to agenda
-[22:44:32] <wired> perhaps removing it completely?
-[22:44:49] <reavertm> I think there's no need to drop it from eclass
-[22:44:51] <reavertm> to much work :P
-[22:44:59] <alexxy> well its not usable in current state
-[22:45:06] <reavertm> and its masked
-[22:45:08] <alexxy> and it causes much more bugs
-[22:45:22] <jmbsvicetto> wired: I asked him to add this point to the agenda
-[22:45:25] <alexxy> so let it stay masked =)
-[22:45:33] <reavertm> we explicitly don't support any kdeprefixed installations
-[22:45:41] <wired> jmbsvicetto: ok, what did you have in mind?
-[22:46:09] <jmbsvicetto> The point is we should send an email letting those using kdeprefix of the new breakage and warning them they should really move out of +kdeprefix
-[22:46:25] <reavertm> I think we should still keep code in mind that it may be enabled as some point
-[22:46:25] <jmbsvicetto> +know
-[22:46:36] <reavertm> but this mail is needed
-[22:47:07] <wired> jmbsvicetto: ok, but they should know already, portage should have screamed when we masked it
-[22:47:28] <wired> but an email (and perhaps a blog post, i could do that) would help
-[22:47:42] <jmbsvicetto> That's all I'm after
-[22:47:44] <Pesa> a news item maybe?
-[22:47:50] <spatz> post a sticky in the forums, many go there
-[22:48:05] <reavertm> I think it is mentioned already
-[22:48:13] <reavertm> in stick in Desktop Environment
-[22:48:33] <wired> okay.. who wants to send the email?
-[22:48:52] <reavertm> Gentoo KDE Lead volunteered, no? :)
-[22:49:10] *** Parts: [Enrico] (n=chiccoro@gentoo/contributor/Enrico)
-[22:49:10] <jmbsvicetto> hehe
-[22:49:11] <wired> (jmbsvicetto) The point is we should send an email
-[22:49:16] <jmbsvicetto> I did
-[22:49:30] <wired> :)
-[22:49:31] <wired> ok
-[22:49:34] <wired> I'll write a blog post
-[22:49:57] <wired> anyone else have anything on kdeprefix?
-[22:50:18] * reavertm will add one quick point to agenda later
-[22:50:18] <wired> moving on
-[22:50:26] <wired> qt 4.5
-[22:50:43] <wired> some people (and some qt devs apparently?!) say its broken with gcc 4.4
-[22:50:54] <reavertm> is everyone aware of the problem? if not, then qt-4.5 may break with 4.4
-[22:50:58] <alexxy> wired: i dont see any breakages
-[22:51:00] <ayoy> do we have any evidence?
-[22:51:03] <alexxy> with gcc-4,4
-[22:51:07] <wired> not any im aware of
-[22:51:11] <reavertm> (apparently when strict aliasing is enabled)
-[22:51:36] <wired> well
-[22:51:39] <reavertm> gcc-4.4. is officially not supported (well, not listed in supported), for 4.5
-[22:51:57] <spatz> I remember someone reporting breakage with 4.4, and Sput confirming it's known to break, but I personally use it successfully
-[22:52:00] <tampakrap> isn't it in stabilization process though?
-[22:52:03] <jmbsvicetto> All I can say is that I haven't noticed any KDE-4.3.1 program crashing with qt-4.5.2 and gcc-4.4
-[22:52:06] <reavertm> and portage already spits QA warnings with gcc-4.3.2
-[22:52:11] <wired> does ANY of you have issues with qt 4.5 and gcc 4.4{,.1}?
-[22:52:11] <wired> cause so far its all blah blah blah
-[22:52:11] <wired> but no evidence
-[22:52:38] <wired> i say its FUD until proved otherwise by bug reports
-[22:53:07] <Pesa> no problem here, but gcc's warnings are quite scary
-[22:53:24] <ayoy> Pesa: what warnings? :)
-[22:53:27] <reavertm> I'll ask thiago about details and get back on next meeting (should have done it already..)
-[22:53:33] <Pesa> about strict aliasing
-[22:53:36] <wired> reavertm: alright
-[22:53:42] <wired> i still think we need proof of breakage
-[22:53:45] <ayoy> mhm
-[22:54:02] *** Quits: toralf (n=toralf@g224122197.adsl.alicedsl.de) (Client Quit)
-[22:54:23] <reavertm> ok, but...
-[22:54:34] <reavertm> if let's say it's horrible breakage, what then?
-[22:54:44] <reavertm> (and proven)
-[22:55:09] <Pesa> is it fixed in 4.6?
-[22:55:12] <jmbsvicetto> reavertm: The point is that if it's true, we can't get KDE-4.3.1 marked stable
-[22:55:16] <reavertm> who thinks we can hold back gcc-4.4 stabilization (with all those ricers around) until 4.6 is out? :P
-[22:55:22] <wired> well if its strick-aliases, can't we disable it?
-[22:55:30] <wired> strict*
-[22:55:40] <reavertm> jmbsvicetto: as of current stable gcc 4.3.2 we can
-[22:57:00] <reavertm> jmbsvicetto: it's not a matter of kde but qt4 (already stable :P)
-[22:57:19] <jmbsvicetto> hehe
-[22:57:28] <jmbsvicetto> qt? Who's that? ;)
-[22:57:39] <wired> jmbsvicetto: want to remove Qt from tree and see if kde works?
-[22:57:40] <wired> :D
-[22:58:25] <wired> anyway, we'll need to look into this
-[22:58:39] <reavertm> we need to work some procedures in case it's breakage :P
-[22:58:44] <wired> i wonder if enforcing something like -fno-strict-aliases would work, then again i have no idea of the problem or what causes it
-[22:59:14] <reavertm> can we filter flags for anything that builds against qt4?
-[22:59:34] <reavertm> I mean *anything*
-[22:59:40] <Pesa> nope 
-[22:59:42] <wired> not really
-[22:59:44] <reavertm> (with qt4 itself)
-[22:59:56] <wired> but maybe building the libs with that flag would be enough
-[23:00:01] <reavertm> so if anyone encounters random runtime failures ...
-[23:00:04] <wired> we really need more info and test cases
-[23:00:15] <Pesa> wired: nope, there are templates :)
-[23:00:21] <reavertm> unfortunately some code may be inline... templates
-[23:00:34] <Pesa> QVector for example
-[23:00:41] <wired> then we have to try to find more info and failure cases
-[23:01:00] <ABCD> the problem, I think, is in 2 headers installed by Qt; the flag would have to be added to every package that uses either header
-[23:01:05] <reavertm> and I think thiago talked about QVector suffering from aliasting for example
-[23:01:16] <wired> i suggest we look for info ( reavertm please ask like you said ) and we talk about this *important* issue on mini-meeting as well
-[23:01:26] <wired> even sooner in chat if we have updates
-[23:01:55] <jmbsvicetto> ok
-[23:01:58] <reavertm> on my TODO, next?
-[23:02:05] <wired> great
-[23:02:08] <Pesa> if the problem is limited to only some classes, is there a patch we can backport?
-[23:02:24] <wired> Pesa: well sput said that they're not willing to fix it
-[23:02:35] <Pesa> O_O
-[23:02:40] <reavertm> we can create one :P (with workaround maybe - like some gcc directive :P)
-[23:02:56] <wired> but this whole ordeal looks like fud to me, if its serious they will have to fix it
-[23:02:56] <wired> we can check other distros using gcc 4
-[23:02:56] <wired> 4.4
-[23:02:56] <wired> for custom patches
-[23:03:03] <reavertm> I think that's because there are too many changes 4.5<->4.6
-[23:03:20] <Pesa> i see
-[23:03:34] <wired> i'll try to see what other distros with gcc-4.4 (if any?! :P) do - if they do anything at all
-[23:03:44] <reavertm> they may not know
-[23:03:52] <wired> you never know
-[23:03:53] <reavertm> (kde devs may no know even)
-[23:04:00] <wired> or there might really be not issue at all
-[23:04:04] <wired> :)
-[23:04:17] <Pesa> next fedora and next ubuntu have gcc 4.4 afaik
-[23:04:35] <Pesa> maybe current fedora too
-[23:04:43] <wired> ok
-[23:04:43] <ayoy> wired: well, like you say, if was critical, they would have fixed it
-[23:04:52] <wired> ayoy: yes thats what i believe as well
-[23:04:52] <ayoy> and Qt 4.6 comes out ~December maybe
-[23:04:56] <alexxy> fedora has bleeding edge svn gcc version
-[23:05:06] <wired> they wouldn't leave their only stable release broken 
-[23:05:09] <wired> i hope
-[23:05:10] <alexxy> since its test ground for rhel 
-[23:05:14] <ayoy> exactly
-[23:05:21] <reavertm> ok, next please
-[23:05:27] <wired> right
-[23:05:28] <ABCD> it's QVector and QMap that are the issues, I think
-[23:05:28] <ABCD> /usr/include/qt4/QtCore/qmap.h:588: warning: dereferencing pointer 'y' does break strict-aliasing rules
-[23:05:28] <ABCD> /usr/include/qt4/QtCore/qvector.h:315: warning: dereferencing pointer 'pretmp.11332' does break strict-aliasing rules
-[23:05:29] <ayoy> btw, new OpenSuSE uses 4.4 iirc
-[23:05:46] <wired> we're dwlling on this, lets do our research and return 
-[23:05:49] <wired> dwelling
-[23:05:55] <wired> wtf is wrong with me today
-[23:06:10] <wired> next item
-[23:06:19] <reavertm> next topic - Qt 4.5.2 stab (ilization)
-[23:06:22] <wired> yeah
-[23:06:28] <reavertm> do it!
-[23:06:57] <reavertm> I mean - now - it fixes several issues with kde (including webkit crashes in quassel)
-[23:06:59] <wired> i don't see why not
-[23:07:14] <reavertm> also it makes kdevelop katepart faster (using raster)
-[23:07:18] <ayoy> is the exceptions flag issue fixed in the tree already?
-[23:07:25] <Pesa> no
-[23:07:32] <Pesa> and there's no issue with exceptions in 4.5
-[23:08:02] <wired> ayoy: is there a reason to touch exceptions in intree 4.5 ebuilds?
-[23:08:05] <Pesa> please leave 4.5 alone
-[23:08:26] <ayoy> well, what was the thing that we tested in overlay?
-[23:08:30] <reavertm> don't touch, cc arches :)
-[23:08:32] <ayoy> not 4.5-related?...
-[23:08:50] <wired> ayoy: you mean 4.6 tech preview 1?
-[23:09:03] <Pesa> i really don't know why we added that flag for 4.5
-[23:09:03] <ayoy> xml-patterns dependent on core w/exceptions
-[23:09:05] <ayoy> is it for 4.6?
-[23:09:08] <Pesa> yes
-[23:09:08] <wired> thats 4.6
-[23:09:11] <ayoy> aahhhh
-[23:09:12] <wired> 4.5 doesn't need it
-[23:09:13] <ayoy> sorry :)
-[23:09:28] <wired> any outstanding bugs in 4.5.2 im unaware of?
-[23:09:41] *** Joins: tkmorris (n=unknown@201-66-183-55.paemt704.dsl.brasiltelecom.net.br)
-[23:09:47] <reavertm> (how is sip/pyqt4 btw?)
-[23:09:48] <ayoy> i don't see any
-[23:10:25] <Pesa> reavertm: bug 284707
-[23:10:42] <wired> http://bugs.gentoo.org/show_bug.cgi?id=284707
-[23:11:15] <reavertm> very well
-[23:11:23] <alexxy> we need Wilkins here
-[23:11:56] <reavertm> ok, are we done iin this topic?
-[23:12:11] <wired> ok then who wants to open the stablereq bug?
-[23:13:00] <ayoy> wired: seems like you
-[23:13:05] <wired> heheh
-[23:13:08] <wired> alright
-[23:13:12] <wired> i'll do it
-[23:13:16] <wired> next item
-[23:13:24] <wired> eclass unitests
-[23:13:32] <reavertm> yeah, I think we could use some
-[23:13:39] <reavertm> in kde world at least
-[23:14:05] <reavertm> to verify blocks/dependencies,- in general kde-functions
-[23:14:41] <reavertm> just a general idea, what do you think
-[23:15:03] <ayoy> sounds interesting as for me
-[23:15:11] <wired> tests to make sure blocks/deps are correct?
-[23:15:16] <reavertm> yes
-[23:15:16] <Pesa> unit tests are usually a good idea for regression testing
-[23:15:26] <wired> sounds good
-[23:15:26] <reavertm> sto avoid further breakages in eclasses
-[23:15:54] <jmbsvicetto> sorry guys, I'm being swampped elsewhere. Please poke me if you need anything from me
-[23:16:01] <reavertm> sure
-[23:16:06] <wired> jmbsvicetto: np, whats your thought on unittests? :P
-[23:16:36] <wired> so.. reavertm you're on this?
-[23:16:45] <reavertm> I think nobody really objects, just someone will need to do it
-[23:16:54] <reavertm> i may start wriing simple tests
-[23:17:03] <wired> a headstart would be nice
-[23:17:08] <reavertm> ok, next item
-[23:17:14] <wired> great
-[23:17:15] <reavertm> jmbsvicetto: sets :)
-[23:17:16] <wired> sets
-[23:17:48] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=272488
-[23:17:56] <reavertm> I filed following bug ^
-[23:18:05] <reavertm> it's one of ways
-[23:18:16] <jmbsvicetto> wired: They're always a good idea
-[23:18:19] <jmbsvicetto> sets
-[23:18:30] <reavertm> i think it's generally accepted fact that current sets doesn't fit best
-[23:18:33] <jmbsvicetto> sorry, wired I meant about unittests
-[23:18:40] <jmbsvicetto> reavertm: agreed on that
-[23:18:46] <wired> jmbsvicetto: ok, reavertm will do the start
-[23:19:05] <wired> reavertm: yeah i've read that bug, its interesting
-[23:19:09] <jmbsvicetto> This is another email I'm "owing" us
-[23:19:10] <reavertm> so,I wanted to bring your attention on discussion about sets
-[23:19:12] <wired> but it seems the whole sets thing is "stale"
-[23:19:25] <wired> is anything being developed by zac/portage team?
-[23:19:46] <reavertm> wired: no interest - no need to make progress
-[23:20:13] <reavertm> if we present strong interest in some idea, zac may start coding
-[23:20:41] <reavertm> PROPERTIES=set has this nice feature that most of syntax is already there and may need a litlle work just to get it done
-[23:21:00] <reavertm> (with no operators supported - operators have been disabled from sets anyway)
-[23:21:21] <reavertm> s/a little/little/
-[23:21:42] <reavertm> so, please read this bug, form some opinion and comment on this bug
-[23:21:48] <reavertm> I think this is everything from me
-[23:22:12] <wired> anyone any ideas/comments?
-[23:22:22] <jmbsvicetto> reavertm: I think PROPERTIES="sets" has some interesting points and may be useful in some cases, but I still think the "original" sets are in general better for KDE
-[23:22:37] <Pesa> reavertm: very interesting idea
-[23:22:48] <reavertm> jmbsvicetto: only for live maybe
-[23:22:53] <reavertm> Pesa: it's zac idea :P
-[23:23:03] <jmbsvicetto> reavertm: I do need to write something about it and until I do, I should shut up as I'm not providing ideas for others to be able to comment on
-[23:23:21] <reavertm> jmbsvicetto: ;)
-[23:23:29] <wired> jmbsvicetto: you did have another idea, no? :)
-[23:23:59] <reavertm> properties set would only need us to maintain 'metapackages'
-[23:24:25] <reavertm> and i personally don't need anything else (even as a maintainer)
-[23:24:49] <jmbsvicetto> wired: my main point is that a list of package atoms can be more versatile
-[23:25:05] <reavertm> jmbsvicetto: USE flags?
-[23:25:10] <jmbsvicetto> wired: just to give you an example, I think that would be a clever way to fix the PDEPEND problem of QT
-[23:25:20] <reavertm> or dedicated USE_EXPAND variable?
-[23:25:26] <wired> jmbsvicetto: maybe instead of trying to write a spec, you could write a short comment @ reavertm's bug to get discussion going?
-[23:25:38] <jmbsvicetto> reavertm: I know what you mean and that's where optional deps would need to be supported by sets
-[23:25:41] <wired> (comment with a short description of what you're thinking)
-[23:26:11] <jmbsvicetto> wired: I'm not planning to write a spec, but I need to tie myself to a chair and write a few ideas before I can get people talking about them ;)
-[23:26:18] <wired> heheheh
-[23:26:28] <wired> you could trying the other way around
-[23:26:36] <wired> start a discussion and let it tie you to the chair to answer
-[23:26:38] <wired> :)
-[23:26:53] <reavertm> you mean trolling? :)
-[23:27:13] <wired> throwing ideas to each other isn't necessarilly trolling :)
-[23:27:44] <wired> reavertm: maybe you could ask zac to make a sample implementation of properties
-[23:27:48] <wired> if its easy to implement
-[23:28:21] <reavertm> for us to verify it's usefulness? :P
-[23:28:30] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
-[23:28:41] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
-[23:28:46] <wired> if its easy to implement yeah, itd be nice to have some hands on and might give us more ideas
-[23:29:24] <reavertm> wired: just imagine metapackage that pulls everything it's listed there even when uninstalled :P
-[23:29:31] <wired> some new portage guy could also do it for excersice :P
-[23:29:31] <wired> exercise
-[23:29:41] <jmbsvicetto> reavertm: That's what metapackages already do ;)
-[23:29:44] <reavertm> this is what properties=set is
-[23:29:54] <reavertm> jmbsvicetto: uninstalled...
-[23:30:04] <reavertm> or reemerged
-[23:30:20] <jmbsvicetto> reavertm: The new behaviour is for meta packages to pull all packages when they're already installed and or to remove all packages when uninstalling
-[23:30:37] <jmbsvicetto> reavertm: ok, you meant uninstalling
-[23:30:43] <reavertm> 'new behaviour'? never heard of it
-[23:31:25] <jmbsvicetto> reavertm: I mean that the goal of the PROPERTIES="set" proposal is to have the PM do that with those meta-packages - thus it's a new behaviour
-[23:31:27] <reavertm> yes, so it's easy to imagine how it works
-[23:31:36] <jmbsvicetto> sure
-[23:31:42] <reavertm> wired: ^ :P
-[23:31:52] <wired> :)
-[23:32:03] <wired> ok so we didn't get anywhere with sets
-[23:32:10] <reavertm> of course, for official implementation it will need GLEP and such
-[23:32:15] <jmbsvicetto> It doesn't address the optional deps (and I don't mean the use deps) and or set operations (math set operations)
-[23:32:34] <jmbsvicetto> which could be very useful
-[23:32:45] <reavertm> jmbsvicetto: what is 'optional deps'? USE_EXPAND variable wouldn't work?
-[23:32:58] <jmbsvicetto> let me give an example
-[23:33:05] <reavertm> operators - of course - we could use those
-[23:33:13] <reavertm> (but not really blocker for me :P)
-[23:33:27] <jmbsvicetto> let's say we want to have in the @kdebase set, kdebase-startkde as the only required dep (with all of its deps)
-[23:34:07] <jmbsvicetto> So anyone having @kdebase in their system could remove at will any package in the @kdebase set and the PM would respect it, except if it was kdebase-startkde or one of its deps
-[23:34:46] <jmbsvicetto> So emerge -uDav @kdebase would only update the installed packages - would work by default as emerge -uDav @kdebase/@installed
-[23:34:49] <reavertm> so 'install all by default' but allow uninstall
-[23:34:55] <jmbsvicetto> yes
-[23:35:20] <reavertm> please comment on bug :)
-[23:35:21] <jmbsvicetto> For instance, I might want to have the @kdenetwork set, but I really hate krfb and I don't want it around
-[23:35:25] <jmbsvicetto> hehe
-[23:35:34] <wired> how do you reemerge the whole set?
-[23:35:39] <wired> @kdebase/@all ?
-[23:35:45] <jmbsvicetto> wired: ^^ See, I'm already being asked to tie myself to chair ;)
-[23:35:53] <wired> jmbsvicetto: yeah, it worked
-[23:35:55] <wired> jmbsvicetto: :D
-[23:36:04] <wired> jmbsvicetto: keep going! =]
-[23:36:40] <jmbsvicetto> wired: That would need some discussion and documentation, but I could see emerge -uDav @<set> only updating the installed (and required deps) and emerge -av @<set> installing all packages in the set
-[23:36:43] <tampakrap> --keep-going
-[23:36:50] <reavertm> you can attach channel log :P
-[23:36:52] <jmbsvicetto> --jobs=5
-[23:36:58] <wired> -jobs=512
-[23:37:05] <reavertm> no @ oeprators
-[23:37:19] <reavertm> keep it simple and stupid :P
-[23:37:30] <wired> alright, so this should continue in bug, we should all ping jmbsvicetto once a day to tie him to the chair
-[23:37:33] <wired> :D
-[23:37:42] <jmbsvicetto> The tricky part is that the PM will need to store sets and need to use them for dep resolution
-[23:37:50] <jmbsvicetto> hehe
-[23:37:52] <reavertm> but is there. just needs attention
-[23:38:04] <reavertm> bug*
-[23:38:22] <jmbsvicetto> reavertm: another example - emerge -C @kdebase - 3 years from now when the sets are long gone ;)
-[23:38:50] <wired> EAPI="10" ? :)
-[23:39:06] <reavertm> but we should start to make people forget about '@' :P
-[23:39:38] <wired> alright
-[23:39:43] <reavertm> ok, anythig else
-[23:39:44] <wired> we're closing in 2 hours
-[23:39:52] <wired> reavertm: you wanted something extra to discuss about?
-[23:40:10] <reavertm> ah yes
-[23:40:18] <reavertm> versioning eclasses
-[23:40:35] <wired> I think we really need that
-[23:40:42] <reavertm> but just as 'stamp eclass version to be able to guess from 'environment' which eclass is really used
-[23:41:19] <reavertm> some EVERSION_kde4_base=number (incremented with every file.eclass commit) would work
-[23:41:27] <jmbsvicetto> reavertm: versioned eclasses were a good idea that never took off
-[23:41:37] <reavertm> I could be even posisble to do it as pre-commit hook
-[23:41:50] <jmbsvicetto> reavertm: that sounds doable
-[23:42:02] <jmbsvicetto> reavertm: hmm, let me check something
-[23:42:04] <reavertm> jmbsvicetto: I only would like to stamp version, not use for dependencies or such
-[23:42:18] <ayoy> reavertm: what for then?
-[23:42:25] <jmbsvicetto> reavertm: what you want is already there - # $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/kde/meeting-logs/Attic/kde-project-meeting-log-20090917.txt,v 1.1 2009/09/17 21:13:41 wired Exp $
-[23:42:44] <jmbsvicetto> reavertm: what we need is a way to put that in the environment.bz2
-[23:42:45] <reavertm> jmbsvicetto: but it's not in environmeny as varianle
-[23:42:52] <jmbsvicetto> yes, I understand
-[23:42:59] <jmbsvicetto> reavertm: but there might be a way to get it
-[23:43:35] <jmbsvicetto> reavertm: hmm, thinking a few more seconds about it, are you sure it's not there?
-[23:43:46] <jmbsvicetto> reavertm: iirc, the complete eclass is supposed to be in environment.bz2
-[23:44:15] <reavertm> with all comments stripped
-[23:45:06] <reavertm> export "EVERSION_${ECLASS//-/_}"=1
-[23:45:15] <reavertm> for simple manual approach
-[23:45:30] <wired> some quick thinking, could we have eclass wrappers loading "custom-versioned" eclasses based on ebuild PN/PVs?
-[23:45:32] <reavertm> (pre-commit hook would be more clever)
-[23:45:37] <jmbsvicetto> reavertm: right
-[23:45:46] <jmbsvicetto> reavertm: maybe we could ask Zac to keep the version in the file
-[23:45:57] <jmbsvicetto> reavertm: It seems to me it would be very useful for other cases as well
-[23:46:08] <reavertm> how would he gather such info?
-[23:46:14] <jmbsvicetto> He already does
-[23:46:33] <reavertm> i mean, eclass version
-[23:46:48] <reavertm> what he he does is checking some timestamp I suppose
-[23:46:49] <jmbsvicetto> environment.bz2 picks the used eclasses. Currently the comments are being stripped, but it seems it could be useful to keep the 3rd line in the eclass
-[23:47:23] <jmbsvicetto> reavertm: I'm going after a "simpler" solution
-[23:47:32] <spatz> avoid using anything CVS specific as we might want to move away from that one day
-[23:47:35] <reavertm> yeah, and may even be sufficient
-[23:47:53] <wired> if that was doable we could have kde4-meta in ebuilds, kde4-meta-1 and kde4-meta-2 for example and kde4-meta would inherit per case, wouldn't that be easy to implement and practical?
-[23:48:02] <reavertm> jmbsvicetto: actually it won't
-[23:48:17] <jmbsvicetto> reavertm: why not?
-[23:48:35] <reavertm> jmbsvicetto: or at least we should set out own header in pre-commit anyway
-[23:48:57] <jmbsvicetto> spatz: The current discussions include using the git md5 for similar purpose
-[23:49:00] <reavertm> (as overlay eclasses are usually copy-paste to tree, so don't have cvs version signature)
-[23:49:16] <jmbsvicetto> reavertm: but the minute you commit an eclass to the tree, it gets a version
-[23:49:32] <jmbsvicetto> reavertm: and we could be using commit hooks in the overlay for the same goal
-[23:49:33] <reavertm> jmbsvicetto: the point is I don't want to work it only with tree
-[23:49:49] <reavertm> yes, ^
-[23:50:08] <reavertm> "or at least we should set out own header in pre-commit anyway"
-[23:50:09] <jmbsvicetto> I'm not arguing against commit hooks, just saying that for the tree we already have it ;)
-[23:50:12] <wired> jmbsvicetto: reavertm is what im saying doable?
-[23:50:41] * reavertm reads
-[23:50:49] <jmbsvicetto> wired: I'm too tired to think about it and am I'm no expert, but I think invariancy rules don't allow that
-[23:50:57] <jmbsvicetto> -am
-[23:51:22] <reavertm> wired: but it includes some eclass dependencies
-[23:51:28] <jmbsvicetto> wired: or you'll have to use the "safe vars" to do that if/case
-[23:51:29] <reavertm> sure it's easy to be done
-[23:51:51] <wired> think eclass bumping, big version changes would not affect old ebuilds/eclasses if that worked
-[23:52:00] <wired> and we don't need to get eclass versioning in portage
-[23:52:29] <jmbsvicetto> anyway, are we done for tonight?
-[23:52:34] <reavertm> it's just a matter what inherit depending on PV
-[23:52:40] <reavertm> I think we are
-[23:52:43] <wired> reavertm: i know, i wonder if portage would like it
-[23:52:46] <wired> we are
-[23:52:50] <wired> unless anyone wants to add something
-[23:52:53] <jmbsvicetto> reavertm: PV is one of the "safe vars" ;)
-[23:53:14] <wired> its seems noone wants
-[23:53:19] <wired> dismissed
-[23:53:20] <reavertm> jmbsvicetto: it's not safe unless it's marked readonly :)
-[23:53:33] <jmbsvicetto> :)
-[23:53:34] <wired> meeting ends, until next thursday :)
-[23:53:49] <jmbsvicetto> wired: can you please upload the log to the kde project space?
-[23:53:56] <jmbsvicetto> I can do the summary in the weekend
-[23:54:35] <wired> jmbsvicetto: cvs? sure
-[23:58:48] *** Parts: ayoy (n=ayoy@gentoo/developer/ayoy)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090924.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090924.txt
deleted file mode 100644
index d82099cf2e..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090924.txt
+++ /dev/null
@@ -1,230 +0,0 @@
-[22:07:55] <wired> sooooo
-[22:07:59] <wired> who's here?
-[22:07:59] <ayoy> that would rock :)
-[22:08:16] <reavertm> meetings are quite understaffed recently :P
-[22:08:21] <wired> yeah i have a feeling
-[22:08:23] <Pesa> here
-[22:08:24] <dagger> blame scarabeus
-[22:08:26] <wired> we'll be missing a lot today
-[22:08:27] <ayoy> I'm here
-[22:08:35] <wired> ROLLCALL :D
-[22:08:52] * ABCD is here
-[22:08:57] * reavertm reporting
-[22:08:58] <nim_> <--tampakrap but due to family issues i may leave without notice
-[22:09:29] *** Joins: alexxy (n=alexxy@gentoo/developer/alexxy)
-[22:09:36] <alexxy> hi all
-[22:09:42] <reavertm> yo
-[22:09:44] <dagger> heya alexxy
-[22:09:46] <wired> hey alexxy 
-[22:09:50] <wired> shouting brings ppl
-[22:09:52] * wired is impressed
-[22:10:08] <reavertm> it's good you're here alexxy because I've planned last minute agenda topic that is sort of related to you :)
-[22:10:13] <wired> lol
-[22:10:23] <wired> he wont be happy
-[22:10:24] <wired> :p
-[22:10:33] <reavertm> I think in longer run he will
-[22:10:39] <reavertm> :)
-[22:10:39] <wired> hehe
-[22:10:46] <alexxy> omg =)
-[22:10:49] <wired> so lets wait 5 more minutes
-[22:11:09] <wired> maybe jmbsvicetto and bonsaikitten will show up
-[22:11:41] <wired> we're also missing spatz
-[22:12:53] * wired orders some food
-[22:13:38] <Pesa> btw i have a rather unstable internet connection these days, so i may disappear in the middle of the meeting :(
-[22:14:40] <bonsaikitten> jmbsvicetto mentioned to me he might not make it
-[22:14:59] <bonsaikitten> and I'm present, but not conscious
-[22:15:10] * reavertm slaps bonsaikitten
-[22:19:25] <wired> alright
-[22:19:30] <wired> lets begin
-[22:19:35] <jmbsvicetto> Hi
-[22:19:38] <wired> w00t
-[22:19:42] <wired> that's timing
-[22:19:42] <wired> :p
-[22:19:48] <Pesa> yeah
-[22:20:02] <wired> hey boss
-[22:20:14] <nim_> but i'll leave sorry
-[22:20:34] <wired> cya
-[22:20:59] <jmbsvicetto> Hi everyone
-[22:21:04] <wired> jmbsvicetto: :)
-[22:21:04] <dagger> hi :)
-[22:21:10] <jmbsvicetto> I'm also present, but not very "conscious"
-[22:21:33] <wired> maybe we should look into that, it seems to be spreading
-[22:21:33] <wired> :p
-[22:21:43] <reavertm> ok..
-[22:21:54] <wired> lets start with kde stabilization
-[22:22:07] <wired> can someone please outline the current bugs state?
-[22:22:26] <reavertm> there are a few left
-[22:22:57] <reavertm> two java (some hotspot issue with non-sun jvms) related, two grub issues (patch is attached to one of them)
-[22:23:14] <dagger> some deps are also pending stabilisation
-[22:23:42] <reavertm> I've eliminated two more today (one as test-request and second marked as not blocking stabilization)
-[22:24:15] <wired> anything we can't solve in the following days, or something we should focus on?
-[22:24:21] *** Parts: nim_ (n=nim@adsl14-107.lsf.forthnet.gr)
-[22:24:32] <reavertm> Pesa: one is probably yours? (consolekit and dbus related)
-[22:24:58] <Pesa> yep, it shouldn't block stabilization imho
-[22:25:07] <Pesa> it's not a regression afaik
-[22:25:11] <reavertm> one could try to applyt hat grub patch from bug 242736 and see whether it works
-[22:25:21] <wired> i'll try that
-[22:25:36] <jmbsvicetto> We need to apply all the patches sent to the packagers ml
-[22:25:44] <reavertm> jmbsvicetto: in overlay
-[22:25:44] <dagger> it's nice to see policykit went stable on x86/amd64
-[22:25:55] <jmbsvicetto> In particular the ones that prevent some kdepim packages from crashing and kmail from eating imap mails
-[22:26:04] <jmbsvicetto> reavertm: Great! Thanks
-[22:26:06] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=241638 - also sci team would need to add some pkg_postinst
-[22:26:13] <wired> nice
-[22:26:20] <reavertm> jmbsvicetto: only ldap. I yet to see imap crash patch posted
-[22:26:40] <jmbsvicetto> reavertm: hmm, I could swear I noticed an email about that
-[22:27:04] <reavertm> well, my 4.3.9999 branch is still crashing occasionally so it's not fixed
-[22:27:37] <jmbsvicetto> reavertm: <200909131956.22847.mcguire@kde.org> <- mailid
-[22:28:01] <reavertm> please someone slap sci team to add that pkg_postinst message about the possible need to reemerge cln and/or libqualculate in case some linking problems  appear
-[22:28:49] <jmbsvicetto> reavertm: I've forward the mail to you
-[22:28:56] <reavertm> jmbsvicetto: ah, that one, yeah
-[22:29:43] <alexxy> jmbsvicetto: i dont see any problems with kmail related to imap
-[22:29:55] * alexxy uses it on dayly basis
-[22:30:05] <wired> alexxy: its something about moving folders
-[22:30:07] <dagger> neither do I (use it all the time on 2 PCs)
-[22:30:08] <wired> and its ugly
-[22:30:09] <reavertm> it sometimes crashes kmail on exit
-[22:30:22] <wired> iirc you can lose a folder full of emails :P
-[22:30:26] <jmbsvicetto> alexxy: It's an upstream commit
-[22:30:39] <jmbsvicetto> (the patch)
-[22:30:39] <alexxy> hmm
-[22:30:56] <alexxy> my kmail can handle imaps folders with 100k+ mails
-[22:30:59] <dagger> the only problem I can see with kmail/kontact is that it sometimes lunches two instances on startup and when you close any of them it crashes
-[22:31:09] <reavertm> someone needs to bump doxygen 1.6.1 to fix bug https://bugs.gentoo.org/show_bug.cgi?id=282598
-[22:32:06] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=275326 can be probably maked as non-blocker since java is now enabled by default (and there's postinst message warning that redland is known to not work)
-[22:32:19] <reavertm> (btw it seems to be fixed in trunk soprano)
-[22:32:45] <wired> sounds good
-[22:33:05] <jmbsvicetto> reavertm: mind adding all the bugs you know about as blockers to the stabilization bug?
-[22:33:29] <reavertm> jmbsvicetto: I'm just reading this list
-[22:33:38] <wired> about doxygen - if nerdboy doesnt bump it in the next few days we can do it i guess
-[22:33:48] <reavertm> if there are some new 4.3.1 issues that should be maked as blockers, then wel...
-[22:33:53] <jmbsvicetto> Also, can anyone please open bugs for the KDE deps (automoc, strigi, soprano, phonon, etc), assign it to us and cc amd64 / x86?
-[22:34:34] <reavertm> I'll create stabilization list for 4.3.1
-[22:35:33] <wired> ok
-[22:35:35] <reavertm> separate bug for each dep?
-[22:35:49] <wired> jmbsvicetto?
-[22:35:53] <jmbsvicetto> In this case, we can have a single bug for all deps
-[22:36:54] <reavertm> I'd like someone (or more of you) to take a look at recent 4.3.1 bugs that may be considered blockers
-[22:36:55] <wired> alright
-[22:37:29] <reavertm> if you're bored that is :)
-[22:37:31] <wired> i'll have a look this weekend
-[22:37:47] <jmbsvicetto> reavertm: I want to start looking at some, but work is leaving me dead tired when I finally get home :\
-[22:38:03] <wired> jmbsvicetto++ i have the same issue and this weekend im working...
-[22:38:06] <wired> stupid deadlines
-[22:38:23] <reavertm> ok, I think that's it when it comes to kde stabilization, anything else here?
-[22:38:29] <wired> alright, anything else pending for stabilization?
-[22:38:43] <wired> lets move on to Qt
-[22:38:47] <wired> before we talk about gcc
-[22:38:53] <wired> quick update on stabilization
-[22:39:07] <wired> after talking with yngwin i pushed news item in -dev
-[22:39:13] <wired> about the use flag changes
-[22:39:26] <wired> i'll request stabilization after I've added the news item
-[22:39:38] <wired> probably on saturday
-[22:39:46] <wired> since i need to wait 72 hours
-[22:39:53] <Pesa> nice :)
-[22:39:55] <ayoy> cool
-[22:40:05] <wired> sooooo
-[22:40:21] <wired> did anyone get any info, crashes or anything else on qt 4.5 w/ gcc 4.4 combo?
-[22:40:26] <reavertm> gcc and qt4..
-[22:40:32] <ayoy> no!
-[22:40:39] <wired> ftr no crashes for me
-[22:40:47] <Pesa> nope
-[22:41:00] <dagger> nope. I'm using 4.4.1 and 4.5.2 and all is fine
-[22:41:02] <reavertm> it may not be that severe considering no other distros I looked into made any patches for aliasing
-[22:41:14] <wired> reavertm: did you talk with upstream?
-[22:41:16] <jmbsvicetto> wired: still no noticeable crashes here
-[22:41:35] <reavertm> anyway - it affects all template classes like QHash, QList, QMap, QVector and maybe some other
-[22:41:40] <alexxy> also no crasghes here with qt-4.5.x
-[22:41:46] <wired> well
-[22:41:51] <wired> if no one can replicate crashes
-[22:41:57] <wired> worksforme
-[22:42:02] <ayoy> :)
-[22:42:06] <reavertm> it may be enough to add -fno-strict-aliasing somewhere to make it even less severe
-[22:42:28] <wired> we could
-[22:42:31] <reavertm> other way (thiago asuggested) is to simply (providing it's simple) - backport those classes from 4.6
-[22:42:44] <wired> but why bother touching something
-[22:42:45] <wired> that works
-[22:42:48] <wired> keep in mind
-[22:42:52] <wired> that users are best testers
-[22:42:56] <wired> and we don't have bug reports :)
-[22:42:59] <wired> thats a good sign :P
-[22:43:05] * alexxy has several crashes with qt-4.6 and kde4 and amarok
-[22:43:21] <reavertm> well, yes, we may need to wait for some fireworks because maybe it's not really needed
-[22:43:41] <Pesa> where would you add -fno-strict-aliasing? remeber those classes are templates...
-[22:43:44] <jmbsvicetto> Oh, let me thank whoever has been doing the latest taglib{-extras} and amarok bumps
-[22:44:09] <wired> if we wake one morning and bugzilla is full of Qt4 crash duplicates we'll worry about it, but seriously this is fud, there's no way they wont fix it if it ever breaks
-[22:44:31] <Pesa> wired: fine with me
-[22:44:47] <reavertm> well, this may not be a fud, but we've seen several aliasing-related warnings on gentoo for multiple packages
-[22:44:59] <reavertm> so it's not a reason for panic
-[22:45:19] <wired> alright
-[22:45:28] <reavertm> so, let's wait for user/testers feedback, hmm?
-[22:45:31] <wired> thats settled until a storm comes then
-[22:45:39] <wired> :)
-[22:45:39] <reavertm> ok
-[22:45:44] <wired> reavertm: your floor :)
-[22:45:50] <reavertm> last (hidden) agenda item :)
-[22:46:00] <ABCD> I've had a couple of crashes that might be related, but I can't be sure
-[22:46:25] <reavertm> ABCD: gather coredumps and/or just backtraces then
-[22:47:06] <reavertm> last agenda item - stop shipping unstable svn snapshots - several reasons:
-[22:47:26] <reavertm> - they need to be repacked (not really an issue)
-[22:47:38] <reavertm> - they are known to be broken
-[22:48:10] <reavertm> - they somewhat distract users from using tagged packages in portage (4.3.1) and such
-[22:48:47] <wired> i dont really mind, but yeah, especially the early ones could be avoided
-[22:48:51] <wired> for users' sake
-[22:48:55] <reavertm> (of course we're not talking about dropping beta1, beta2, rc1, rc2 .. releases as those have some tagging involved, not just auto-tagging)
-[22:48:57] <dagger> what about providing only beta/rc version?
-[22:49:06] <dagger> lol nvm
-[22:50:07] <reavertm> alexxy: you used to bump them, what do you think about not doing it anymore? :)
-[22:51:37] <alexxy> well there some people who relay use them =)
-[22:52:03] <reavertm> alexxy: apart from yourself? :)
-[22:52:12] <alexxy> yep 
-[22:52:26] <jmbsvicetto> sorry, phone
-[22:52:33] <bonsaikitten> I say if someone wants to do them let's have snapshots
-[22:53:02] <wired> as long as we have alexxy to make em eh? :P
-[22:53:05] <reavertm> the point is, people come here and report that they are broken (like pykde4 + some temporary svn issues) and expect us to fix it
-[22:53:28] <reavertm> and I'd prefer kde devs were not bothered with this :P
-[22:53:57] <reavertm> oh, and they makes repoman full takes longer :)
-[22:54:18] <wired> we could add ewarn-that-no-one-reads to snapshot ebuilds *** NO SUPPORT ANYWHERE *** :P
-[22:54:21] <alexxy> reavertm: then simply add something like
-[22:54:22] <reavertm> (whatever this means in english :P)
-[22:54:35] <jmbsvicetto> reavertm: I agree with bonsaikitten, but we should add a note that may have been lost with time - let's add a pkg_postinst for those ebuilds telling users not to report bugs to Gentoo
-[22:54:42] <alexxy> snapshot is known to be broken so report all busg about them to bugs.kde.org
-[22:54:43] <alexxy> =)
-[22:54:46] <alexxy> to eclass
-[22:54:53] <reavertm> omg
-[22:55:03] <jmbsvicetto> something like that, yes
-[22:55:10] <wired> they'll come down to us with grenades man
-[22:55:11] <wired> lol
-[22:55:15] <reavertm> also - less versions - less synchronization work
-[22:55:17] <ABCD> okay with me, so long as it's conditional on [[ -z ${I_KNOW_WHAT_I_AM_DOING} ]] :)
-[22:55:28] <ABCD> (the message, that is :) )
-[22:55:31] <reavertm> I know not all of you do ebuild synchornization work but.... :)
-[22:55:58] <ABCD> and I don't mind dropping those versions, either :)
-[22:56:13] <reavertm> at least I'm not going to touch them anymore
-[22:56:59] <reavertm> and I don't want to see blocks involving 4.3.56 -> 4.3.57 changes in ebuilds :P
-[22:57:11] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
-[22:57:12] <wired> so lets leave it at "as long as someone is interested lets keep em and add a fat warning in eclass"
-[22:58:03] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
-[22:58:12] <wired> great
-[22:58:15] <reavertm> actually we should only provide blocks that involve versions that are going to be in tree
-[22:59:11] <reavertm> pesa [21:57:13] <wired> so lets leave it at "as long as someone is interested lets keep em and add a fat warning in eclass"
-[22:59:40] <Pesa> fine with me, thanks :)
-[22:59:57] <Pesa> i don't really use them
-[23:00:34] <ABCD> reavertm: why? if something has rdep "!<kde-base/kdelibs-4.3.65:4.4[...]", then you will *never* hit the blocker anyway, so long as you are only using in-tree ebuilds :)
-[23:01:14] <jmbsvicetto> so, anything else left for today?
-[23:01:18] <wired> i think we're good
-[23:01:22] <wired> assuming all goes well
-[23:01:35] <wired> next week we'll be ready
-[23:01:47] <reavertm> ABCD: it's about always increasing bloat and complexity of those blocks
-[23:01:48] <wired> whoever closes the last blocking bug should bug all the rest
-[23:02:06] <wired> and begin stab(ilization) procedures :)
-[23:02:29] <ABCD> reavertm: that's why I created a add_blocker function that takes care of all that stuff [except that I was told I shouldn't use it yet...]
-[23:02:39] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
-[23:02:52] <jmbsvicetto> ok, then I'm going to do something "stupid" like watching tv or playing a stupid psp game ;)
-[23:02:55] <reavertm> I know
-[23:03:23] <wired> jmbsvicetto: yay! heheh, i'll fire up my xbox :P
-[23:03:45] <jmbsvicetto> :)
-[23:03:48] <jmbsvicetto> later
-[23:03:53] <wired> meeting end!
-[23:04:00] <wired> jmbsvicetto: i'll add log same place :)
-[23:04:24] <jmbsvicetto> wired: thanks
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100225.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100225.txt
deleted file mode 100644
index 04fa9ddf30..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100225.txt
+++ /dev/null
@@ -1,612 +0,0 @@
-[21:27:14] <tampakrap> ok let's start
-[21:27:23] <tampakrap> roll call plz
-[21:27:26] <tampakrap> !herd kde
-[21:27:28] <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired
-[21:27:48] <ABCD> here
-[21:28:17] <reavertm> .
-[21:28:43] <wired> here
-[21:28:56] * alexxy here or there 
-[21:29:00] <wired> alexxy: indeed :P
-[21:30:19] <scarabeus> .
-[21:30:25] <tampakrap> Sput:  we need you for this one, present?
-[21:31:03] <scarabeus> lets start with kdepim
-[21:31:14] <scarabeus> jorge is going to be around in ~10 minutes
-[21:31:22] <alexxy> hmm
-[21:31:26] <scarabeus> so the relevant tasks even for him should be that way preserved :]
-[21:31:31] <tampakrap> 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] <tampakrap> ok about kdepim and enterprise useflag
-[21:32:32] <alexxy> also can we discuss snapshots for 4.5 pre alphas?
-[21:32:33] <alexxy> =)
-[21:32:50] <reavertm> ohnoes
-[21:32:51] <tampakrap> sure, along with this
-[21:33:11] *** Quits: j0hu (~quassel@quassel/contributor/j0hu) (Read error: Connection reset by peer)
-[21:33:19] <alexxy> also using lxc as testbead for testing kde builds
-[21:33:25] <tampakrap> 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] <alexxy> tampakrap: what issue?
-[21:34:01] <tampakrap> kmail is broken in current trunk, i tried to package the enterprise branch which is supposed to work
-[21:34:26] <reavertm> why we should care about trunk?
-[21:34:31] <wired> afaik the enterprise branch should be available for releases as well
-[21:34:39] <ABCD> reavertm: because that's what's going to be in 4.5
-[21:34:44] <scarabeus> enterprise branch should be availible for everything
-[21:35:01] <wired> 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] <scarabeus> we should just monthly generate our own kdepim tarball from that branch
-[21:35:27] <scarabeus> and be done with it
-[21:35:34] <scarabeus> maybe even forgot about non-enterprise :]
-[21:35:36] <wired> considering the [crappy] state of kdepin right now, thats a good idea
-[21:35:39] <tampakrap> two packages failed to compile from enterprise stuff, plus a flag isn't possible for trunk as ebuilds are different
-[21:35:40] <wired> kdepim*
-[21:36:28] <reavertm> 1) there is enterprise related cmake switch in cmakelists.txt - maybe it should be used  when bulding enterprise branch
-[21:36:47] <alexxy> am i right that kmail is broken because of mail storage migrartion to akonadi?
-[21:36:49] <reavertm> 2) still don't see why we should care :P
-[21:37:02] <wired> reavertm: enterprise should actually work OK 
-[21:37:08] <wired> and kde devs care about it not breaking
-[21:37:17] <wired> at least thats what we've been told
-[21:37:18] <wired> :p
-[21:37:22] <tampakrap> i agree with reavertm, too much work, maybe we should just wait
-[21:37:28] <tampakrap> too much work for nothing
-[21:37:29] <reavertm> problem is it does not follow kde release schedule
-[21:37:44] <scarabeus> it is released with each even release
-[21:37:51] <reavertm> especially if apparently they're going to merge it eventually?
-[21:38:40] <wired> no its not going to be merged
-[21:38:49] <reavertm> now, I've not tried to build it yet - is it possible to use our ebuilds?
-[21:38:59] <reavertm> or it differs too much so that it's impossible?
-[21:39:04] <tampakrap> 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] <tampakrap> it differs too much
-[21:39:21] <tampakrap> it's not impossible, it is way too much work
-[21:39:21] <jmbsvicetto> Hello
-[21:39:26] <wired> tampakrap: you are talking about trunk, we are talking about releases
-[21:39:28] <wired> hey jmbsvicetto 
-[21:39:34] <jmbsvicetto> sorry for being late
-[21:39:37] <tampakrap> i'm talking about enterprise itself
-[21:39:40] <jmbsvicetto> I confused the hour again :\
-[21:39:52] * spatz is back
-[21:40:16] <tampakrap> and my opinion is the same for the snapshots, way too broken to be provided to users
-[21:40:45] <tampakrap> i can announce it and blog it, whatever, that we can't provide them if you agree
-[21:40:49] <reavertm> other issue, how are we going to provide it? split like kdepim?
-[21:41:15] <tampakrap> yes, it needs different branch of ebuilds
-[21:41:44] <tampakrap> anyone willing to work on it?
-[21:41:54] <reavertm> and probably blocking kdepim...
-[21:42:01] <tampakrap> or just postpone it for next meeting?
-[21:42:03] <tampakrap> exactly
-[21:42:17] <scarabeus> ok i personaly cant promise i will devote time to it :/
-[21:42:30] <scarabeus> so it would need some maintainer, even non dev
-[21:42:39] <scarabeus> just in overlay so we see the potential
-[21:42:44] <scarabeus> and then we can put it into tree
-[21:42:48] <reavertm> agreed
-[21:42:50] <tampakrap> i could announce it
-[21:43:28] <scarabeus> 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] <scarabeus> tampakrap: so could you sent it to dev-anounce and desktop mls?
-[21:43:45] <tampakrap> although i doubt there will be someone willing to do so much work for nothing
-[21:43:47] <jmbsvicetto> I'm not interested in kdepim, so I won't be working on it
-[21:44:05] <tampakrap> yes, even blog the whole kdepim problem in trunk
-[21:44:34] <tampakrap> and thus i'm against providing the snapshots ( alexxy ) yet
-[21:45:02] <scarabeus> 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] <reavertm> .85 I would say even :P
-[21:45:21] <scarabeus> haha
-[21:45:25] <alexxy> no =)
-[21:45:27] <alexxy> .70
-[21:45:28] <scarabeus> .70 is enough for ricers :D
-[21:45:28] <reavertm> beta 1 :P
-[21:45:30] <wired> 4.5.1? :P
-[21:45:33] <alexxy> aka alpha0 
-[21:45:34] <alexxy> =)
-[21:45:36] <DrEeevil> btw, word of warning
-[21:45:45] <tampakrap> when kmail is ready i'd say
-[21:45:52] <DrEeevil> dev.ge.o will migrate to new hardware soon, so expect a day or two of confusion
-[21:46:02] <scarabeus> thats good to know :]
-[21:46:07] <tampakrap> thanks patrick
-[21:46:33] <scarabeus> ok i think we should get back on track with topic one :]
-[21:46:38] <tampakrap> i think we are ready on this (btw i'm writing summary as soon as we speak)
-[21:46:55] <scarabeus> so we dont jump over those carefully written numbered topics in chaotic order :]
-[21:47:08] <tampakrap> ok back to topic one: new leader elections
-[21:47:26] <tampakrap> candidates: jmbsvicetto, scarabeus, plz vote (devs only)
-[21:47:28] <reavertm> bring it on!
-[21:47:48] <DrEeevil> I vote yes ;)
-[21:47:52] <scarabeus> DrEeevil: you cant
-[21:47:53] <scarabeus> pick
-[21:47:55] <tampakrap> i vote scarabeus (sorry jorge :) )
-[21:48:11] <jmbsvicetto> DrEeevil: :P
-[21:48:12] <reavertm> I'd like to hear manifesto from both! ;)
-[21:48:17] * reavertm runs
-[21:48:22] <tampakrap> lol
-[21:48:23] <jmbsvicetto> tampakrap: no hurt feelings ;)
-[21:48:45] <scarabeus> not to break kde and keep it working for everyone of us :] and provide my qa tools for kde
-[21:48:49] <alexxy> i vote for scarabeus =)
-[21:48:53] <jmbsvicetto> scarabeus: nothing prevents us from having more than one lead, but let people choose
-[21:48:58] <scarabeus> note that this manifesto wont change for me if not voted for :]
-[21:49:03] <alexxy> hmm 
-[21:49:09] <reavertm> what qa tools?
-[21:49:11] <alexxy> or lets have two leads
-[21:49:12] <alexxy> =)
-[21:49:20] <alexxy> if its possible
-[21:49:22] <scarabeus> i have quite few scripts that checks x11 state
-[21:49:25] <wired> i like that idea too
-[21:49:26] <reavertm> no, just one to rule them all :)
-[21:49:32] <scarabeus> and i can adjust it for kde
-[21:49:38] <tampakrap> no, one leader is enough
-[21:49:39] <scarabeus> which i plan for month or so already :D
-[21:49:42] <wired> we are a large herd
-[21:50:00] <scarabeus> actualy multiple leads are weird, just pick guys
-[21:50:08] <scarabeus> it does not matter to jorge or me who wins :]
-[21:50:16] <scarabeus> we just comply to the 1 year election rule :]
-[21:50:21] <reavertm> how many members with voting power are here?
-[21:50:33] <wired> lets vote and find out
-[21:50:34] <wired> ;p
-[21:50:39] <tampakrap> 9
-[21:50:56] <tampakrap> sorry 10
-[21:51:12] <reavertm> what about 5:5 ?
-[21:51:22] <scarabeus> reavertm: that would not amuse me
-[21:51:36] <reavertm> ok, let's hear it
-[21:51:47] <tampakrap> 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] <jmbsvicetto> 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] <tampakrap> lol
-[21:52:23] <scarabeus> ok ok ok
-[21:52:23] <wired> nice
-[21:52:25] <scarabeus> i get it
-[21:52:38] <wired> like it or not you're lead
-[21:52:38] <wired> :p
-[21:52:39] * scarabeus votes for jmbsvicetto :]
-[21:52:39] <tampakrap> congrats now abuse your powah :P
-[21:52:40] <jmbsvicetto> I said before I would prefer to have someone else being lead ;)
-[21:52:47] <jmbsvicetto> scarabeus: No!!!! :P
-[21:52:48] * wired remembered
-[21:53:04] <jmbsvicetto> Congratulations Tomas
-[21:53:13] <wired> scarabeus: \o/ congrats :)
-[21:53:22] <scarabeus> Now everyone i guess we should drink something good in favor of our good benevolent now-ex lead. So on Jorge :]
-[21:53:38] <scarabeus> 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] <tampakrap> ok little girls you played enough for today, now let's move on
-[21:55:15] <tampakrap> Review work flow for KDE minor bumps and improve collaboration with arch teams
-[21:55:48] <scarabeus> 1) BUG
-[21:55:48] <scarabeus> 2) keywordlist
-[21:55:48] <scarabeus> 3) portage addition
-[21:55:48] <scarabeus> 4) profiles touching
-[21:56:00] <scarabeus> this should be workflow from now-on so we dont touch anyones toes
-[21:56:13] <jmbsvicetto> scarabeus: The Founder Power has been bestowed on you for #gentoo-kde ;)
-[21:56:22] * ssuominen votes scarabeus 
-[21:56:28] <ABCD> <CIA-58> abcd * gentoo/xml/htdocs/proj/en/desktop/kde/index.xml: We have a new lead!
-[21:56:36] <ssuominen> :P
-[21:56:57] <scarabeus> ssuominen: ha ha ha :D
-[21:57:10] <reavertm> all cards have been played already ;)
-[21:57:15] <jmbsvicetto> scarabeus: I propose something different
-[21:57:31] <scarabeus> jmbsvicetto: i just wrote this one after start with jer, and then i got distracted
-[21:57:38] <scarabeus> jmbsvicetto: how does your approach look?
-[21:57:43] <scarabeus> if its better just make it policy
-[21:57:44] <scarabeus> :]
-[21:58:01] <scarabeus> its once per 6 months, and it wont hurt to have written down somewhere in Documentation/
-[21:58:14] <tampakrap> good idea, whatever we decide on this should be forwarded as a global policy
-[21:58:23] <jmbsvicetto> 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] <jmbsvicetto> scarabeus: then your policy
-[21:59:06] <tampakrap> i don't like this approach
-[21:59:18] <jmbsvicetto> well, your 3) would be done before, so it could be 3) unmask in the tree
-[21:59:18] <tampakrap> what if they do something stupid while using the overlay?
-[21:59:56] <jmbsvicetto> 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] <jmbsvicetto> tampakrap: I'm not giving commit access
-[22:00:07] <scarabeus> jmbsvicetto: sounds sane
-[22:00:18] <scarabeus> altho i dont think about that snapshot into main tree
-[22:00:20] <tampakrap> i was not clear
-[22:00:26] <scarabeus> deps can go if released
-[22:00:28] <scarabeus> but not the kde
-[22:00:33] <reavertm> I don't like snapshots in tree either
-[22:00:33] <scarabeus> it is annoying 280 packages
-[22:00:38] <tampakrap> i meant what if they use other testing ebuilds while using the overlay?
-[22:00:42] <scarabeus> its 4 hours commit
-[22:00:47] <reavertm> (even if those are kde deps just)
-[22:00:58] <jmbsvicetto> 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] <scarabeus> but only for deps
-[22:01:32] <scarabeus> no touching of kde-base/ itself
-[22:01:35] <jmbsvicetto> I'm only talking about new deps
-[22:01:35] <reavertm> there is problem - we have no arch team members in kde team
-[22:01:40] <scarabeus> we have
-[22:01:42] <scarabeus> for amd
-[22:01:43] <scarabeus> :D
-[22:01:48] <reavertm> only ssuominen, but we would need some for other archs
-[22:01:58] <scarabeus> me stable for amd64 from time to time
-[22:02:00] <alexxy> i can keyword arm and mips
-[22:02:01] <alexxy> =)
-[22:02:09] <Philantrop> scarabeus: It's 30 minutes if you commit at category level.
-[22:02:38] <scarabeus> Philantrop: i know, but i managed to clash 3x already with someone else :]
-[22:02:42] <alexxy> if you commit in 10 threads then it takes about 5 minutes
-[22:02:45] <scarabeus> even when i announced it :D
-[22:02:46] <alexxy> to commit whole kde
-[22:02:54] <reavertm> and since keywording kde is quite a bottleneck .. kde dev (which clearly uses kde) could do it faster
-[22:02:56] <scarabeus> hmm i could thread bump tool indeed
-[22:03:13] <Philantrop> scarabeus: force commit and kick anyone interfering from the herd. That's what I did. :->
-[22:03:30] <alexxy> 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] <alexxy> working with 10 threds
-[22:03:48] <alexxy> *threads
-[22:04:05] <scarabeus> ok lets write out the rules on the Documentation
-[22:04:09] <scarabeus> and i will thread the bumptool
-[22:04:11] <scarabeus> its quite simple
-[22:04:44] <ssuominen> <- not a part of amd64, just have stable chroot for xfce/kde/xorg/base-system/media
-[22:05:05] <scarabeus> i also stable only when i have long night :D
-[22:05:19] <scarabeus> but people mostly dont complain if qa guys stable on archs they can test :]
-[22:05:53] <scarabeus> 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] <tampakrap> no problem in this, i just hope there will be something prepared until next meeting
-[22:06:59] <scarabeus> ok kde-4.3.5 then :]
-[22:07:01] <alexxy> i think we can use lxc containers instead of chroots
-[22:08:03] <scarabeus> so we are waiting on archies only, are there any issues with it?
-[22:08:35] <reavertm> what's advantage of lxc over chroot?
-[22:08:49] <reavertm> (which I can boot to natively as well)
-[22:08:58] <alexxy> it run separate system in separate namespace
-[22:09:10] <alexxy> so its more closer to vms
-[22:10:28] <alexxy> VM's
-[22:10:29] <alexxy> =)
-[22:10:38] <tampakrap> ok back to topic
-[22:10:46] <tampakrap> <scarabeus> so we are waiting on archies only, are there any issues with it?
-[22:11:25] <tampakrap> anyone?
-[22:11:35] <ABCD> not that I've seen, as an archie :D
-[22:11:55] <tampakrap> ok next one
-[22:12:03] *** Joins: aboow (house5@gateway/shell/bshellz.net/x-vhnffmhwlxzbhinj)
-[22:12:05] <Sput> tampakrap: won't be really online until in about 1 hour
-[22:12:06] <Sput> sitting in the train currently with shaky net
-[22:12:24] <scarabeus> 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] <scarabeus> if anyone gets remove ideas :P
-[22:12:35] <tampakrap> Sput: ok we can talk then
-[22:12:51] <tampakrap> kde 4.4 status
-[22:12:51] <wired> s/anyone/alexxy/
-[22:12:59] * alexxy has remove idea of old kde's
-[22:13:00] <reavertm> :)
-[22:13:01] <wired> :D
-[22:13:15] <Sput> 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] <Sput> as 4.4 kdepim is supposed to work with trunk kde
-[22:14:22] <tampakrap> 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] <tampakrap> back again to kde 4.4
-[22:14:46] <tampakrap> any known problems? blockers?
-[22:14:55] <scarabeus> yeah it is slightly flaky
-[22:14:57] <alexxy> archies =)
-[22:15:02] <scarabeus> i got few crashes in kwin and plasma
-[22:15:24] <Sput> also, congrats scarabeus :)
-[22:15:25] <Civil> few crashes in krunner and plasma
-[22:15:27] <tampakrap> me too, so i guess 4.4.1 will be the stable candidate
-[22:15:30] <scarabeus> also the virtuoso migration is not exactly funky working out of the box for some
-[22:15:36] <scarabeus> 4.4.1 or 4.4.2
-[22:15:41] <reavertm> 4.4.2 most likely
-[22:15:42] <scarabeus> we shall see after 4.4.1 release
-[22:15:51] <tampakrap> ok
-[22:15:51] <scarabeus> i would rather wait too
-[22:15:58] <reavertm> judging from the past...
-[22:15:59] <tampakrap> anything else on 4.4?
-[22:16:20] <tampakrap> i guess not
-[22:16:32] <tampakrap> jmbsvicetto: amarok and mysql 5.1 status
-[22:16:32] *** Joins: hwoarang (~mystical@gentoo/developer/hwoarang)
-[22:16:49] <reavertm> poor Jorge
-[22:17:03] <reavertm> oh wait, akonadi is indifferent...
-[22:17:26] <Sput> virtuoso migration failed for me
-[22:17:31] <alexxy> amarok works with mysql 5.1
-[22:17:33] <jmbsvicetto> ok
-[22:17:38] <alexxy> if it compiled with -FPIC
-[22:17:42] <jmbsvicetto> so, amarok and mysql-5.1
-[22:18:01] <jmbsvicetto> Fortunately it's way better than I feared when I added it to the agenda
-[22:18:32] <jmbsvicetto> 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] <ABCD> 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] <jmbsvicetto> A few people are still following the bug, but we can live with it as is
-[22:19:03] <jmbsvicetto> ABCD: exactly
-[22:19:52] <jmbsvicetto> 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] <jmbsvicetto> that is for amarok to work with mysql-5.1 - but that might cause serious issues "sooner than later"
-[22:20:56] <jmbsvicetto> 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] <scarabeus> :D
-[22:21:40] <tampakrap> thank you x-boss
-[22:21:47] <scarabeus> how about we stop supporting the embedded part :]
-[22:21:51] <scarabeus> and just force full amarok
-[22:21:58] <scarabeus> patch--
-[22:21:58] <scarabeus> ?
-[22:22:00] <reavertm> like akonadi does
-[22:22:01] <tampakrap> ^^!!
-[22:22:08] <reavertm> let them have it!
-[22:22:20] <reavertm> that should teach those bastards :P
-[22:22:30] <scarabeus> :D
-[22:22:38] <tampakrap> ok anything else? serious?
-[22:22:42] <scarabeus> ok lets go for koffice
-[22:22:47] <scarabeus> i guess i should answer that one
-[22:22:59] <scarabeus> problem with koffice is that expect graphic tools it is totaly unusable
-[22:23:00] * reavertm fixed kword recently
-[22:23:02] <tampakrap> go on
-[22:23:11] <scarabeus> and it needs all deps reviewed and updated based on cmakelists
-[22:23:36] <scarabeus> 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] <tampakrap> i will take this one but i may need your help
-[22:24:01] <scarabeus> query still works :]
-[22:24:19] *** Quits: aboow (house5@gateway/shell/bshellz.net/x-vhnffmhwlxzbhinj) (Disconnected by services)
-[22:24:49] <tampakrap> anything else?
-[22:24:57] <scarabeus> nop, nothing from me to add
-[22:25:13] <tampakrap> ok knetworkmanager
-[22:25:19] <jmbsvicetto> scarabeus: no harm in keeping embedded for now
-[22:25:25] <scarabeus> jmbsvicetto: oky
-[22:25:33] <scarabeus> ok we need snapshot
-[22:25:40] <scarabeus> and monthly refreshed snapshot probably
-[22:25:43] <jmbsvicetto> scarabeus: if I can get a patch for mysql, we can make it simple again
-[22:25:45] <tampakrap> knetworkmanager crashes plasma here, i didn't prepare a snapshot i just tested with live ebuild
-[22:25:46] <scarabeus> who is willing to take that one out :]
-[22:25:59] <scarabeus> tampakrap: well plasmoid can be disabled
-[22:26:07] <scarabeus> tampakrap: most people are interested in kcm module
-[22:26:22] <scarabeus> we need monthly refreshed snapshot from svn
-[22:26:23] <tampakrap> i didn't use the plasmoid
-[22:26:31] <tampakrap> only the system tray item
-[22:26:35] <scarabeus> the same thing
-[22:26:39] <tampakrap> sure
-[22:26:40] <scarabeus> kcm is in systemsettings
-[22:26:45] <alexxy> tampakrap: is it working?
-[22:26:53] <tampakrap> kcm wasn't working though :)
-[22:26:58] <scarabeus> ok
-[22:27:03] <scarabeus> so anyone uses NM these days
-[22:27:07] <scarabeus> or are we all on wicd?
-[22:27:16] <tampakrap> i guess i didn't have time to test it since it was crashing
-[22:27:43] <tampakrap> 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] <alexxy> 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] <scarabeus> tampakrap: ok just add it masked to main tree
-[22:28:25] <scarabeus> and lets ask users for testing and feedback :]
-[22:28:29] <tampakrap> anyone else? no?
-[22:28:50] <scarabeus> good question, there is quite few more team members :P
-[22:28:55] <scarabeus> who is willing to do this one? :]
-[22:29:36] <tampakrap> ABCD / reavertm?
-[22:29:51] <scarabeus> there is also DrEeevil whom enjoy the user feedback anyway :D
-[22:30:04] <ABCD> I don't use NM
-[22:30:19] <scarabeus> tampakrap: i got it
-[22:30:22] <scarabeus> tampakrap: coordinate with dagger
-[22:30:28] <scarabeus> tampakrap: afterall he is maintainer of NM
-[22:30:34] <tampakrap> ah yes
-[22:30:39] <tampakrap> ok next topic
-[22:30:45] * reavertm does have static network
-[22:31:14] <tampakrap> 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] <tampakrap> two issues though:
-[22:31:32] <tampakrap> 1) jmbsvicetto promised to clean up the member list
-[22:31:48] <scarabeus> which will be probably my task now :/
-[22:32:01] <tampakrap> 2) i have an open bug about xdm configuration which i don't like, i'd like your feedback
-[22:32:09] <scarabeus> i will sent mail to everyone who does not have 5 commits month into kde cat
-[22:32:13] <ABCD> scarabeus: I sorted it asciibetically for you (except your name is at the top) :D
-[22:32:34] <scarabeus> ABCD: lovely, you earn the big plus point :P
-[22:32:50] <tampakrap> http://bugs.gentoo.org/attachment.cgi?id=220755&action=view
-[22:33:08] <tampakrap> scarabeus: also plz remove qt members they are still there
-[22:33:34] <jmbsvicetto> tampakrap: yeah
-[22:33:44] <jmbsvicetto> tampakrap: I'll talk to scarabeus about that
-[22:33:46] <tampakrap> 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] <scarabeus> tampakrap: recommend dejavu and droid fonts for christ sake
-[22:34:26] <scarabeus> tampakrap: other than that you should point to x11 guide which should describe xdm config iirc
-[22:34:39] <tampakrap> cool
-[22:34:43] <tampakrap> i like that
-[22:35:26] <tampakrap> 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] <scarabeus> its only gnu_andrew
-[22:35:45] <scarabeus> and he will fill them anyway just to annoy us
-[22:36:05] <reavertm> heh
-[22:36:07] <tampakrap> 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] <reavertm> remove kdeprefix from docs
-[22:36:31] <reavertm> kde guide is way too red
-[22:36:45] <tampakrap> funny, i agree on that
-[22:36:51] <reavertm> friendly 'notes' everywhere
-[22:37:10] <reavertm> it's impossible to follow
-[22:37:11] <scarabeus> :D
-[22:37:22] <scarabeus> yeah just wipe out kdeprefix from docs is good idea
-[22:37:34] <jmbsvicetto> about kde3 and kde-sunset, my opinion is that we did one thing wrong
-[22:37:49] <reavertm> also maybe sets...
-[22:37:56] <jmbsvicetto> my initial goal was never to make kde-sunset a "dumping ground" to be mastered by users alone
-[22:38:01] <reavertm> info about sets - remove as well?
-[22:38:14] <tampakrap> reavertm: i think we can have a note about sets, but keep metas as the default option
-[22:38:27] <scarabeus> nah sets are weird
-[22:38:31] <scarabeus> they are bbd now
-[22:38:32] <ssuominen> jmbsvicetto: i'm sure everyone knows that, but you can't force devs to work on it :)
-[22:38:39] <tampakrap> jmbsvicetto: i'm still following the kde-sunset commits
-[22:38:43] <jmbsvicetto> 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] <wired> jmbsvicetto: well your idea assumes devs are interested
-[22:38:59] <jmbsvicetto> but now it's too late, so we'll have to live with it as is
-[22:38:59] <wired> jmbsvicetto: we have none of those
-[22:39:00] <wired> :p
-[22:39:15] * jmbsvicetto cries for sets
-[22:39:34] <scarabeus> jmbsvicetto: not in this implementation, sorry
-[22:39:34] <jmbsvicetto> I know (devs and KDE3)
-[22:39:55] <tampakrap> ok, i guess we are done
-[22:39:56] <scarabeus> pretty much all gentoo devs have commit access to that overlay..
-[22:40:48] <tampakrap> the following two topics are long time ideas i had
-[22:40:54] <tampakrap> drop prefixes from kde ebuilds (like kdeartwork etc)
-[22:40:59] <Sput> I use NM with the plasmoid and both work great
-[22:41:01] <Sput> trunk though.
-[22:41:22] <Sput> if anyone dares to remove the plasmoid from -9999 I will keel him
-[22:41:23] <Sput> :)
-[22:41:23] <ABCD> tampakrap: things like kdebase-data... you think it should just be "emerge data"?!
-[22:41:45] <tampakrap> well no
-[22:41:48] <reavertm> drop prefixes? no
-[22:41:51] <tampakrap> but for kdebase-startkde yes
-[22:41:56] <reavertm> add prefixes? more likely :P
-[22:41:58] <tampakrap> or for the artwork ones
-[22:42:01] <ssuominen> please no another dev-haskell/
-[22:42:09] <ssuominen> try emerge opengl or emerge x11
-[22:42:20] <ABCD> startkde makes sense
-[22:42:20] <ssuominen> or zlib for that matter
-[22:42:23] <reavertm> or chromium :)
-[22:42:29] <reavertm> same with emacs
-[22:42:35] <scarabeus> yeah i think it is not worth the gain
-[22:43:11] <reavertm> whatever I try to install, it tells me that I need to choose between sam app-emacs/XXX and <what_i_need>/XXX
-[22:43:15] <ssuominen> we dropped -plugin- from xfce-extra/'s for a long time, and I can tell you... it was, nothing but a pain
-[22:43:29] <ABCD> tampakrap: oh, and kdeartwork-kscreensaver can't be "kscreensaver", because kde-base/kscreensaver is kdebase-workspace
-[22:43:34] <reavertm> scarabeus: you wanted to add prefixes some time ago
-[22:43:41] <tampakrap> ok i got your point
-[22:44:04] <reavertm> to have module precede package name - like kdegames-sth
-[22:44:22] <scarabeus> reavertm: i thought of it bit more, and it would just take too much time :]
-[22:44:22] <tampakrap> reavertm: it's the same i guess, too much pain, doesn't worth it
-[22:44:29] <reavertm> so that one can easily know what module is this withour reading ebuild
-[22:44:41] <scarabeus> grep KMMODULE is simple :D
-[22:44:47] <scarabeus> or KMNAME
-[22:44:48] <scarabeus> :]
-[22:44:53] <reavertm> yest, misleading
-[22:44:55] <tampakrap> well, i don't want to emerge kdepim-kmail
-[22:45:04] <reavertm> module = kdepim, not subdir in kdepim
-[22:45:20] <reavertm> KMMODULE is a bit unfortunate name...
-[22:45:39] <tampakrap> never mind
-[22:45:43] <scarabeus> indeed, sadly i dont want to redesing the eclass again :D
-[22:45:52] <scarabeus> reavertm: i bet you dont want either
-[22:45:52] <reavertm> we have one convention already
-[22:46:01] <tampakrap> we all agreed i guess not to touch anything
-[22:46:06] <tampakrap> next?
-[22:46:21] <reavertm> for those that are in multiple module, we have plasma-apps, plasma-workspace, plasma-runtime
-[22:46:25] <reavertm> same with solid-
-[22:46:35] <reavertm> let's just keep it when needed
-[22:46:40] <tampakrap>  change kde-meta (and @kde-*) to include all modules (plus the developer specific ones)
-[22:46:44] <tampakrap> reavertm: sure
-[22:46:52] <scarabeus> i dont get what are you proposing with this topic :P
-[22:47:08] <scarabeus> it should include even kdesdk?
-[22:47:11] <scarabeus> thats baad idea
-[22:47:24] <scarabeus> 99% of users dont want it
-[22:47:31] <scarabeus> they just emerge kde-meta cause they are lazy
-[22:47:45] <tampakrap> that's what i'm proposing yes
-[22:47:54] <ABCD> -1
-[22:48:07] <tampakrap> and how is kdewebdev more useful?
-[22:48:23] <reavertm> on the other hand, we don't get bugreports for them because nobody is using this
-[22:48:25] <tampakrap> how about a developer something flag?
-[22:48:33] <tampakrap> exactly!
-[22:48:43] <reavertm> (less bugs -> more fun)
-[22:48:53] <krytzz> hm tampakrap useflag would be bad, not supported on sets right?
-[22:49:00] <reavertm> sorry -1 from me
-[22:49:00] <scarabeus> tampakrap: developer useflag could work on meta
-[22:49:03] <scarabeus> but what for sets
-[22:49:06] <scarabeus> its baad idea
-[22:49:15] <scarabeus> if user wants it he can merge kdesdk-meta
-[22:49:19] <scarabeus> or kdewebdev-meta
-[22:49:29] <tampakrap> kdewebdev is already in kde-meta
-[22:49:41] <krytzz> introduce a new set? kde-lazy? :p
-[22:49:47] <wired> kde-meta shouldn't be used by users
-[22:49:53] <reavertm> why?
-[22:49:59] <tampakrap> at least i think sets should include them all
-[22:50:01] <wired> +1 for tampakrap's proposal, we should have everything in there.
-[22:50:11] <wired> i except kde-meta to install everything
-[22:50:32] <reavertm> expect*
-[22:50:33] <ABCD> wired: I hope you "expect", not "except" :D
-[22:50:39] <wired> expect gr
-[22:50:43] <tampakrap> for me kde-meta is http://websvn.kde.org/trunk/KDE/
-[22:50:54] <wired> a "recommended" USE flag could be introduced to skip stuff not needed by users
-[22:50:55] <jmbsvicetto> ABCD: he uses qt with the "exceptions" use flag ;)
-[22:51:10] <reavertm> kdeexamples O_o?
-[22:51:23] <jmbsvicetto> if you add the kdebindings stuff to kde-meta, I'm sure we'll get a few interesting bug reports ;)
-[22:51:44] <jmbsvicetto> (wom 96
-[22:52:01] <tampakrap> ok then, i'll rephrase: how about a developer something use flag in metas and include everything in sets?
-[22:52:10] <scarabeus> we can have kdefull-meta
-[22:52:13] <scarabeus> or somethingl ike
-[22:52:14] <tampakrap> at least for sets it makes sence, users can create their own
-[22:52:17] <scarabeus> kde-burnmycomputer
-[22:52:27] <scarabeus> but not kde-meta
-[22:52:35] <scarabeus> it is full blown working kde desktop
-[22:52:37] <scarabeus> not full kde
-[22:52:44] <tampakrap> i still prefer the use flag idea
-[22:52:57] <scarabeus> lets discuss this on alias
-[22:53:06] <reavertm> well, we can have kde-meta installa all, but advice to use kdebase-meta instead
-[22:53:08] <tampakrap> in gentoo-desktop
-[22:53:14] <scarabeus> or that
-[22:53:23] <scarabeus> but there will be duncan
-[22:53:24] <tampakrap> ok let's discuss it in the mailing list, i'll start the thread
-[22:53:28] <scarabeus> and who is going to read that :D
-[22:53:32] <tampakrap> i won't
-[22:53:36] <tampakrap> i have work to do
-[22:53:43] <wired> you know
-[22:53:52] <wired> gmail used to automatically clasify duncan as spam
-[22:54:12] <tampakrap> cool next topic
-[22:54:14] <tampakrap>   13 - stabilization of misc kde apps
-[22:54:17] <wired> :P
-[22:54:25] <scarabeus> qa scripts can help with that
-[22:54:27] <tampakrap> wired promised a script :)
-[22:54:32] <tampakrap> for qt also
-[22:54:34] <scarabeus> but we have quite too much packages
-[22:54:39] <scarabeus> in kde
-[22:54:43] <scarabeus> it takes some time to compute
-[22:54:43] <scarabeus> L:D
-[22:54:48] <wired> oioi i had to do that for kde as well ^_^
-[22:54:57] <scarabeus> wired: okey your job :P
-[22:55:01] <wired> ok i'll repromise to the new lead as well
-[22:55:03] <scarabeus> show us cookies on next meeting :D
-[22:55:06] <wired> i have a todo file now!
-[22:55:08] <wired> :P
-[22:55:11] <tampakrap> next week plz
-[22:55:13] <tampakrap> max
-[22:55:20] <wired> scarabeus: kick him please :D
-[22:55:26] <tampakrap> last topic shut up
-[22:55:28] <tampakrap>   14 - patches of kde-packager
-[22:55:57] <tampakrap> i was kinda busy with exams last month i was not following the ml
-[22:56:08] <tampakrap> reavertm maybe knows anything?
-[22:56:19] <scarabeus> ABCD is suposed to apply kde-packager patches
-[22:56:22] <tampakrap> or jmbsvicetto i think he brought up the subject
-[22:56:28] <scarabeus> as was decided on one of the former meetings
-[22:56:42] <reavertm> well, there are some and they need to be applied as they appear....
-[22:57:00] <jmbsvicetto> yeah, there have been a few patches sent to the packagers ml that didn't go applied
-[22:57:00] <tampakrap> ABCD: will you handle it?
-[22:57:12] <reavertm> I lag here a bit (also due to limited time recently)
-[22:57:14] <tampakrap> anyone else willing to help on this?
-[22:57:15] <jmbsvicetto> I think there are 3 for 4.4 by now
-[22:57:26] <ABCD> I hadn't be able to get on the list until very recently, so I haven't seen those patches yet
-[22:57:50] <scarabeus> i am qute busy in x11 tracking so i cant do such pernament task for kde sadly :/
-[22:57:53] <jmbsvicetto> ABCD: I thought I had asked for everyone to be put in the ml
-[22:58:18] <jmbsvicetto> I'll try to follow the ml
-[22:58:29] <tampakrap> ok, jmbsvicetto / ABCD will you handle this?
-[22:58:34] <jmbsvicetto> in the least I can open a bug with the patch / patch link
-[22:58:42] <tampakrap> sure that too
-[22:59:15] <jmbsvicetto> scarabeus should be able to add new people to the ml, but in any case I can always poke rdeiter and the kde infra team to get it done
-[22:59:22] <ABCD> I'll look into it too
-[22:59:28] <tampakrap> great
-[22:59:39] <tampakrap> alexxy: what did you want to talk about?
-[22:59:46] <scarabeus> jmbsvicetto: thx for the hint, be sure i will ask anything i would not know how to do :]
-[22:59:58] <jmbsvicetto> scarabeus: any time you need
-[23:00:26] <tampakrap> alexxy: ping
-[23:00:47] <scarabeus> i have 1 thing: we need another kde HT lead, i cant do herd testers lately due to limited time, and it would be sad if we loose that nice recruit count, dont you think?
-[23:00:52] <scarabeus> anyone wants to pick that one up?
-[23:01:38] <tampakrap> which are the requirements?
-[23:02:00] <scarabeus> tampakrap: be on irc, actively follow the new recruits and help them
-[23:02:03] <scarabeus> and motivate them
-[23:02:09] <reavertm> like devrel said, a few children and 'mature' attitude ;)
-[23:02:11] <scarabeus> come on you saw me in action as one of the closest
-[23:02:18] <scarabeus> you know what i did :]
-[23:02:23] <tampakrap> ok i'm not good at it
-[23:02:39] *** Quits: willikins (~rbot@gentoo/bot/Willikins) (Read error: Operation timed out)
-[23:02:51] <tampakrap> i tend to insult ppl like wired three times per day before food
-[23:03:14] <scarabeus> good training is actualy teaching :]
-[23:03:29] <scarabeus> ok we keep it as-is and i will anounce on alias :]
-[23:03:40] <jmbsvicetto> reavertm: I'm on devrel ;)
-[23:03:47] <alexxy> tampakrap: pong 
-[23:03:48] <alexxy> =)
-[23:03:57] <tampakrap> alexxy: topics you wanted to discuss?
-[23:04:00] <scarabeus> ok /me has to disappear
-[23:04:02] <scarabeus> so have fun
-[23:04:03] <tampakrap> make it quick plz
-[23:04:06] <scarabeus> and dont break a shit
-[23:04:07] <scarabeus> :D
-[23:04:11] <jmbsvicetto> reavertm: I guess I'm "old enough" at least ;)
-[23:04:16] <reavertm> hehe
-[23:04:18] <alexxy> seems we already discussed them all
-[23:04:19] <alexxy> =)
-[23:04:24] <tampakrap> cool
-[23:04:27] <tampakrap> meeting closed
-[23:04:32] <tampakrap> i'll prepare the summary
-[23:04:32] <alexxy> yep
-[23:04:52] <tampakrap> it was cool to moderate you all, next time don't bring your dolls plz
-[23:05:55] * tampakrap joke fail
-[23:05:59] <jmbsvicetto> dolls? I didn't knew I had to bring mine!!
-[23:06:51] <wired> o_O
-[23:12:24] *** Quits: reavertm (~quassel@gentoo/developer/reavertm) (Remote host closed the connection)
-[23:15:20] *** Joins: reavertm (~quassel@bsb151.neoplus.adsl.tpnet.pl)
-[23:15:21] *** Quits: reavertm (~quassel@bsb151.neoplus.adsl.tpnet.pl) (Changing host)
-[23:15:21] *** Joins: reavertm (~quassel@gentoo/developer/reavertm)
-[23:22:53] *** Parts: spatz (~spatz@gentoo/developer/spatz)
-[23:23:37] <tampakrap> reavertm: ping
-[23:23:59] <reavertm> hmm?
-[23:24:23] <tampakrap> sorry for doing this, yngwin requested to add to topics the desktop profile split but i failed to push :P
-[23:24:45] <tampakrap> is there anything we should discuss (in ml i guess) or can we proceed on this?
-[23:24:53] <reavertm> no, please do
-[23:25:14] <reavertm> we voted on this already, no?
-[23:25:19] <tampakrap> yes
-[23:28:02] *** Quits: jmrk_ (~jmrk@dslb-088-064-075-227.pools.arcor-ip.net) (Quit: Konversation terminated!)
-[23:35:05] <yngwin> tampakrap: does this mean it is going to be implemented now, or?
-[23:35:13] <tampakrap> yes
-[23:35:19] <tampakrap> i will do it
-[23:35:22] <yngwin> ok, tnx
-[23:35:27] <tampakrap> i 'll write it in summary too
-[23:35:34] <tampakrap> so you can have proof :)
-[23:35:36] <yngwin> good :)
-[23:36:02] <yngwin> otherwise i will just remove the ridiculous mysql requirement from desktop profile myself ;)
-[23:36:04] <tampakrap> sorry for not bringing this up, i thought i pushed it
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100318.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100318.txt
deleted file mode 100644
index 52960de088..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100318.txt
+++ /dev/null
@@ -1,206 +0,0 @@
-[22:02:03] <tampakrap> alexxy / bonsaikitten / dagger / jmbsvicetto / lxnay / mrpouet / reavertm_ / scarabeus / spatz / wired
-[22:02:05] <tampakrap> meeting time
-[22:02:12] <tampakrap> http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2010-03-18;h=b056be61645fbd793cf07cb9d0eb968e961cb2c1;hb=HEAD
-[22:02:21] <tampakrap> who is here?
-[22:02:25] <dagger> mesa here
-[22:02:29] <spatz> me
-[22:02:39] <scarabeus> boss around
-[22:02:44] <spatz> although my connection is flaky
-[22:02:47] <leio> ping me when it gets to subprofile stuff I guess. Preoccupied 30 more mins
-[22:03:00] <tampakrap> leio: i was about to ping me
-[22:03:07] <tampakrap> ok let's skip it for now
-[22:03:12] <tampakrap> s/me/you
-[22:03:18] <leio> well, in that agenda it's last item anyway..
-[22:04:11] <tampakrap> let's wait another 10 mins, many ppl are away
-[22:04:31] -*- alexxy here ;)
-[22:05:54] <scarabeus> I will start with the lighter thing
-[22:06:00] <scarabeus> since there were no objections to new rules
-[22:06:01] --> willikins (~rbot@gentoo/bot/Willikins) has joined #gentoo-meetings
-[22:06:10] <tampakrap> woohaa bot is back
-[22:06:13] <tampakrap> !herd kde
-[22:06:16] <scarabeus> i will start enforcing them
-[22:06:36] <tampakrap> where is the draft first of all?
-[22:06:39] <scarabeus> so i will thin up team list probably
-[22:06:40] <tampakrap> and why isn't it in git?
-[22:06:52] <scarabeus> what for my rules?
-[22:06:55] <scarabeus> i sent you mail
-[22:07:06] <tampakrap> ok, commit it in git :)
-[22:07:36] <scarabeus> http://dev.gentoo.org/~scarabeus/kde-team-rules.html
-[22:08:04] <scarabeus> i would have to find that rst first :P
-[22:08:15] <jmbsvicetto> pong
-[22:08:28] <tampakrap> ok let's start now
-[22:08:29] <jmbsvicetto> I just need a minute to put my things down and I'll be back
-[22:08:34] <tampakrap> again who is here?
-[22:08:51] <scarabeus> scarab
-[22:09:09] -*- spatz ←
-[22:09:09] <tampakrap> !herd kde
-[22:09:26] <tampakrap> (it responds to pm at least)
-[22:09:36] <tampakrap> <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, tampakrap, tgurr, wired
-[22:09:57] -*- wired o/
-[22:10:25] -*- alexxy partialy there or here or somwhere else
-[22:11:09] <tampakrap> scarabeus: go on with the removal of members plz
-[22:11:18] <tampakrap> what's the news on this?
-[22:11:28] <scarabeus> well you didnt complain
-[22:11:35] <scarabeus> so i will put down a list, and clean up
-[22:11:46] <scarabeus> you had 1 month to write objections to my rules list :]
-[22:12:14] <scarabeus> just to note, it has nothing against the named developers, i just preffer that people know who is maintaining it
-[22:12:59] <jmbsvicetto> here
-[22:13:02] <tampakrap> anything else on this?
-[22:13:31] <scarabeus> only if you have questions
-[22:13:58] <tampakrap> questions? anyone?
-[22:14:52] <tampakrap> so, people are going to be removed from the team, i repeat: questions?
-[22:15:13] <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, tampakrap, tgurr, wired
-[22:15:38] <tampakrap> let's move on
-[22:15:46] <tampakrap> Review work flow for KDE minor bumps and improve collaboration with arch teams
-[22:15:49] <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, tampakrap, tgurr, wired
-[22:15:51] <tampakrap> scarabeus: ^^?
-[22:16:09] <scarabeus> it was written last time, wasn't it?
-[22:16:56] <tampakrap> we were going to continue the discussion today
-[22:17:10] <tampakrap> unless nothing new is going to be said
-[22:17:14] <tampakrap> jmbsvicetto: ^^?
-[22:17:39] <jmbsvicetto> tampakrap: iirc I had only one change and it was accepted
-[22:18:42] <tampakrap> ok
-[22:18:43] <tampakrap> next
-[22:18:54] <tampakrap> KDE-4.4 status
-[22:19:09] <tampakrap> 4.4.1 is out, you said that ppl reported problems with 4.4.0
-[22:19:14] <tampakrap> i didn't have any at least
-[22:19:22] <scarabeus> i saw few people working on bindings finaly in overlay
-[22:19:25] <scarabeus> which is great
-[22:19:41] <tampakrap> indeed
-[22:19:57] <tampakrap> can we have 4.4.1 as a stable candidate? regressions? blockers?
-[22:20:02] <jmbsvicetto> It's working great here
-[22:20:10] <jmbsvicetto> I don't have kdepim or kdebindings, though
-[22:20:28] <tampakrap> kdepim is great, kdebindings needs work
-[22:20:40] <dagger> I've got full kde-4.4.1 and it's good. I had problems migrating from 4.3.x with kmail, but it's all ok now
-[22:20:50] <tampakrap> i guess we should pay attention on this and if there are no further problems we can have it as a stable candidate
-[22:21:02] <spatz> schedule?
-[22:21:33] <wired> 4.4.1 works great here too - and on colleague's system as well (users are best test :P)
-[22:21:50] <tampakrap> i guess start of next month? scarabeus?
-[22:22:06] <scarabeus> ok, i saw no more issues too
-[22:22:18] <scarabeus> just check regressions against 4.3 -> 4.4 migration
-[22:22:19] <alexxy> фдыщ нуы
-[22:22:23] <scarabeus> and ok for 4.4.1 patch
-[22:22:24] <alexxy> yep
-[22:22:31] <alexxy> 4.4.1 works great
-[22:22:41] <alexxy> also we use it at university
-[22:22:45] <alexxy> as De for students
-[22:23:06] <tampakrap> scarabeus: start of next month is ok?
-[22:23:25] <scarabeus> yup
-[22:23:26] <spatz> meaning two weeks from now?
-[22:23:36] <tampakrap> no, stable bug
-[22:23:43] <tampakrap> sorry misread :P
-[22:23:44] <tampakrap> yes
-[22:24:14] <tampakrap> unless there aren't any other things here, we can move
-[22:24:21] --> dilfridge (~quassel@gateway.maximilianeum.mhn.de) has joined #gentoo-meetings
-[22:24:34] <tampakrap> enterprise useflag for kdepim stuff (a use flag to follow the enterprise branch of the kdepim repo, only for trunk)
-[22:24:54] <scarabeus> nobody sent any mail or word about working on it
-[22:24:58] <scarabeus> so we should move it to todo
-[22:25:04] <scarabeus> until someone feels motivated enough
-[22:25:04] <tampakrap> i lack the hardware to proceed on this, plus i asked for help, noone answered
-[22:25:19] <tampakrap> Sput: anything you want to say on this?
-[22:25:36] <dagger> i dont know anything about it, but would like to get some information. what's different in enterprise branch?
-[22:26:04] <dagger> does enterprise branch contain support for Openchange/libmapi?
-[22:26:27] <dagger> (that's required for propler M$ exchange 2003/2007/2010 support)
-[22:26:31] <tampakrap> enterprise branch for kdepim is the actual branch were kde developers care about
-[22:26:39] <tampakrap> since kdepim trunk is broken right now
-[22:26:47] <dilfridge> it's supposed to stay stable while everything else is being ported to akonadi (and broken in the meantime)
-[22:26:47] <scarabeus> dagger: it is the branch that is more stable/solid, developers care about that one, because they are payed for that branch
-[22:27:14] <dagger> so I guess it's not part of "default" kdepim right?
-[22:27:20] <tampakrap> ok, we'll move this topic for next meeting, since there is no progress
-[22:27:22] <tampakrap> right
-[22:27:50] <tampakrap> let's move
-[22:27:52] <tampakrap> koffice status
-[22:28:10] <tampakrap> new koffice is released, i did a simple rename, and it currently is in hilarious status
-[22:28:18] <tampakrap> some packages don't even compile
-[22:28:53] -*- scarabeus told you so
-[22:29:04] <tampakrap> i'll try to fix it, but i'll need help, anyone willing to help me is welcome
-[22:29:16] <wired> i might
-[22:29:25] <tampakrap> current ebuilds are hardmasked in overlay, tarball is not released yet
-[22:29:31] <wired> okie
-[22:29:55] <tampakrap> and we should be quick on this and try to have a schedule for stabilization too
-[22:30:17] <tampakrap> as it also new packages
-[22:30:34] <wired> btw i can help with quick-ish stabilization on amd64
-[22:30:42] <tampakrap> sure
-[22:30:47] <Sput> tampakrap: enterprise branch is based on pre-akonadi kdepim and supposedly works
-[22:30:56] <Sput> but a USE flag isn't gonna cut it, the packages are too different
-[22:31:20] <Sput> also we might have to check what they have outside of kdepim, I think they even ship a hacked kdelibs
-[22:31:26] <wired> o_O
-[22:31:33] <wired> kdelibs-lite!
-[22:31:34] <wired> ;p
-[22:31:37] <Sput> (but Paul Adams told me it should work fine with 4.5)
-[22:31:41] <tampakrap> yes, we need a different branch for this
-[22:32:01] <Sput> there was a mail recently on kde-scm-interest where steveire detailed how branches work
-[22:32:23] <Sput> kdepim is in the process of moving to git (as the rest of KDE)
-[22:33:05] <Sput> in any case, the enterprise5 branch is going to be based on KDE 4.5, the enterprise4 branch is based on KDE 4.4
-[22:33:47] <tampakrap> ok thanks i'm going to add those info in a mail and try to revive the issue to users
-[22:34:19] <tampakrap> moving to next one
-[22:34:19] <Sput> also, it seems like KDAB doubts that they manage to get kdepim fixed in time for KDE 4.5
-[22:34:34] <Sput> there will be a meeting in a few weeks where they are going to decide what to do
-[22:35:11] <Sput> one problem is that they got their branching all wrong and lost tons of commits for kmail trunk
-[22:35:25] <Sput> because people were comitting to the wrong branch...
-[22:35:45] <tampakrap> okie
-[22:35:50] <tampakrap> next one
-[22:35:56] <tampakrap> change kde-meta (and @kde-*) to include all modules (plus the developer specific ones)
-[22:36:12] <tampakrap> there were some ppl in the mail i send that liked my idea
-[22:36:21] <tampakrap> so i'd really like to move on this
-[22:36:24] <tampakrap> scarabeus: ^^?
-[22:36:29] <scarabeus> with useflag you can go ahead
-[22:36:29] <wired> im still in favor of this if we use a USE flag
-[22:36:31] <jmbsvicetto> I still don't like that
-[22:36:49] <jmbsvicetto> At least not in kde-meta without a use flag
-[22:36:51] <wired> dev || sdk
-[22:36:59] <wired> both are nice use flags :)
-[22:37:01] <scarabeus> jmbsvicetto: what i said above :P
-[22:37:05] <jmbsvicetto> :P
-[22:37:34] <tampakrap> ok, i'll add sdk useflag to kde-meta
-[22:37:47] <tampakrap> and leave sets as they are
-[22:37:52] <jmbsvicetto> not as IUSE default :P
-[22:37:54] <tampakrap> i don't care about sets anyway
-[22:37:58] <tampakrap> of course not
-[22:38:00] <wired> lol
-[22:38:02] <wired> +1
-[22:38:27] <tampakrap> sdk will contain bindings, kdewebdev and kdesdk? or should i leave bindings for now?
-[22:38:53] <wired> do they work?
-[22:39:03] <scarabeus> they do not mostly]
-[22:39:09] <wired> do they build?
-[22:39:12] <tampakrap> there are ppl working on them, so i guess they will in the near future
-[22:39:20] <dilfridge> scarabeus: which bindings do not work?
-[22:39:31] <scarabeus> csharp afaik
-[22:39:35] <wired> if they build i vote on adding them, get people's attention :)
-[22:40:11] <tampakrap> ok, i'll leave them out for now then, and add them later when they all build
-[22:40:24] <tampakrap> afaik we don't even have a meta for bindings
-[22:41:19] <tampakrap> thank you for this, next one is patches of kde-packager
-[22:41:32] <tampakrap> jmbsvicetto / ABCD(absent): any news on this?
-[22:42:18] <jmbsvicetto> tampakrap: sorry not yet
-[22:42:34] <tampakrap> so i guess you need help on this?
-[22:42:39] <jmbsvicetto> I'll focus on this for 4.4.1 onwards
-[22:42:40] <tampakrap> any more ppl willing to help?
-[22:43:07] <scarabeus> i have to work on something different, so i have to blob out, so enjoy the rest  of the meeting, i will reply to pongs, but wont read
-[22:43:07] <scarabeus> for latest topic i am with lieo (malformed for no highlight)
-[22:44:10] <tampakrap> no worries
-[22:44:15] <wired> scarabeus: is it something with leads that makes them be away all the time?
-[22:44:20] <wired> :D
-[22:44:27] <wired> j/k ofc, c ya later
-[22:44:46] <tampakrap> let's raise the topic in next meeting to see if there will be any progress then
-[22:45:05] <tampakrap> last topic and most important
-[22:45:10] <tampakrap> split of desktop profile
-[22:45:21] <tampakrap> leio / yngwin: your attention plz :)
-[22:45:47] <yngwin> :)
-[22:46:40] <tampakrap> leio: as i told you before, i really like the idea of mixed profiles and i am willing to work on it
-[22:47:08] <jmbsvicetto> I like that idea as well
-[22:47:11] <tampakrap> but i can't have an eta as i don't have a stable schedule atm and i don't even know how much time it wants to be finished
-[22:47:16] <yngwin> me too, but i expect that will take a while to implement
-[22:47:23] --> pesa (~Pesa@host124-126-dynamic.52-82-r.retail.telecomitalia.it) has joined #gentoo-meetings
-[22:47:27] <tampakrap> so i'd really like to proceed on commiting the patches i have prepared
-[22:47:50] <tampakrap> so any objections? something wrong with them before i commit?
-[22:48:48] <yngwin> no objections
-[22:49:38] <wired> i haven't tested them (and i don't use the desktop profile :p) but i really like the idea, +1
-[22:51:06] <-- pesa (~Pesa@host124-126-dynamic.52-82-r.retail.telecomitalia.it) has left #gentoo-meetings ("Konversation terminated!")
-[22:51:20] <tampakrap> leio seems away, so if you want you anything more you can pm me
-[22:51:38] <tampakrap> i'll commit it this sunday fyi, i'll be out of town the next two days
-[22:52:10] <leio> well, you know what I think
-[22:52:26] <leio> (was here at start, but had a phone call afterwards)
-[22:53:36] <tampakrap> cool, i'd take it as a :thumbup from the gnome team and proceed
-[22:53:42] <leio> we have had the single desktop profile situation for, what? four years? So even waiting 3 months more to get the better method implemented would sound fine in my book, but as I can't work on that myself, I can't well argue against more subprofiles meanwhile
-[22:55:00] <tampakrap> point taken
-[22:55:32] <tampakrap> i guess the meeting is over, I'd also like to inform you i have updated docs, please check for any issues
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100604.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100604.txt
deleted file mode 100644
index 3f12f31785..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100604.txt
+++ /dev/null
@@ -1,282 +0,0 @@
-[21:59:58] * scarabeus has changed topic for #gentoo-meetings to: "Gentoo meetings | KDE Team meeting | topics: http://paste.pocoo.org/show/222007/"
-[22:00:43] -*- ABCD is here
-[22:00:45] <scarabeus> lets get slowly started
-[22:00:51] <scarabeus> so step 0: roll call
-[22:00:51] -*- dilfridge is here
-[22:00:52] -*- wired suprizingly here
-[22:00:52] <scarabeus> who is around
-[22:01:02] --> krytzz (~quassel@quassel/user/krytzz) has joined #gentoo-meetings
-[22:01:17] <scarabeus> thats all?
-[22:01:22] <wired> lol
-[22:01:34] --> deathwing00 (~deathwing@gentoo/developer/Deathwing00) has joined #gentoo-meetings
-[22:01:37] -*- ABCD is here (again, because I said it before roll call started)
-[22:01:38] <deathwing00> w00t?
-[22:01:50] <dilfridge> wot?
-[22:01:52] <deathwing00> ok, before anyone brings up any topic
-[22:01:56] <deathwing00> let me say just one thing
-[22:02:39] <deathwing00> my commit access will be disabled starting this month June 2010 and will be re-enabled July 2011, as I will be doing an MBA that will take most of my time away, besides I was promoted to team leader in Flumotion and that adds me even more workload
-[22:02:48] <deathwing00> said that, good luck guys :)
-[22:02:58] <scarabeus> deathwing00: cheers, and happy birthday :]
-[22:03:01] <wired> you really think you won't have time for 1 commit? hehe
-[22:03:15] <dilfridge> good luck to you too :)
-[22:03:35] --> mschiff (~mschiff@d000042.adsl.hansenet.de) has joined #gentoo-meetings
-[22:03:37] <deathwing00> :)
-[22:03:38] <scarabeus> !herd kde
-[22:03:38] <deathwing00> thanks
-[22:03:38] <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, tampakrap, tgurr, wired
-[22:03:43] <scarabeus> wake up rest of you
-[22:03:47] <scarabeus> there is more than 10 people
-[22:04:16] <deathwing00> scarabeus: laters then :)
-[22:04:24] <deathwing00> I'll still be around in jabber ;)
-[22:04:25] <dilfridge> hmm... time for small talk...
-[22:04:27] <-- deathwing00 (~deathwing@gentoo/developer/Deathwing00) has quit (Quit: Leaving.)
-[22:04:47] <scarabeus> ok, lets get started, and i will kick their asses later
-[22:05:02] <scarabeus> so 4.4 and its stabilisation
-[22:05:08] <bonsaikitten> rrrrrrringdingding!
-[22:05:12] <scarabeus> the bug is not moving anyhow promisingly
-[22:05:36] <dilfridge> many things are there since 4.3.x times
-[22:06:10] <scarabeus> yes the main quesiton is
-[22:06:16] <scarabeus> how about we put 4.4.4 to main tree
-[22:06:21] <scarabeus> and ask for stabilisation in 1 week
-[22:06:25] <scarabeus> no matter what is left
-[22:06:43] <ABCD> sounds fine to me - 4.4.4 should just be bugfixes on 4.4.3, right? :D
-[22:06:46] <scarabeus> but basic thing i would like to say is that i would like to see designated team that would handle the stables
-[22:06:49] <dilfridge> probably not better nor worse than 4.4.3
-[22:06:52] <scarabeus> they will run the stable
-[22:07:05] <scarabeus> and will be responsible for proactively stabling and pestering us all for fixing stable bugs
-[22:07:12] -*- dilfridge hears some coconuts in the background
-[22:07:48] <dilfridge> well who else besides me runs 4.4.[34] here still?
-[22:08:15] <scarabeus> i have 4.4.3
-[22:08:16] <jmbsvicetto> sorry, got distracted
-[22:08:16] <scarabeus> :]
-[22:08:18] -*- ABCD doesn't because his hard drive broke
-[22:08:28] <scarabeus> jmbsvicetto: by accident you dont run stable huh? ;}
-[22:09:40] <jmbsvicetto> I runn 4.4.4
-[22:09:46] <dilfridge> also good
-[22:09:48] <scarabeus> So any other ideas how to handle this situation?
-[22:09:51] <jmbsvicetto> run*
-[22:10:09] <dilfridge> well the only other alternative would be to stable 4.4.3
-[22:10:10] <jmbsvicetto> scarabeus: about the 1 week we must be ready for arch teams to tell us they'll wait the usual month
-[22:10:31] <scarabeus> nah, they wont get to that bug before the month will come anyway
-[22:10:37] <jmbsvicetto> in any case, I think the most important issue is the deps. Are we sure all 4.4.4 deps are marked stable?
-[22:10:50] <scarabeus> expect amd64 and x86 which mostly will do what we ask them
-[22:10:52] <ABCD> did the deps change from 4.4.3?
-[22:11:17] <scarabeus> dependecies were not changed
-[22:11:22] <jmbsvicetto> ABCD: 4.4.3 isn't stable, right? iirc, the latest stable is 4.3.5
-[22:11:29] <dilfridge> yes
-[22:11:34] <jmbsvicetto> scarabeus: and no, I don't run stable
-[22:11:55] <jmbsvicetto> also, what about kdepim? Will that only affect 4.5?
-[22:11:58] <scarabeus> jmbsvicetto: i think our problem is that we all rock on ~ or even further
-[22:12:01] -*- dilfridge has a fully stable x86 chroot rotting somewhere
-[22:12:10] <scarabeus> jmbsvicetto: kdepim is affected only 4.5 and it is next topic :]
-[22:12:20] <ABCD> jmbsvicetto: it isn't, but if its deps were stable, then there shouldn't be much of an issue
-[22:12:21] <scarabeus> dilfridge: sadly you are not dev yet whom can fill those requests :]
-[22:12:30] <jmbsvicetto> scarabeus: that's to be expected
-[22:12:35] <jmbsvicetto> (us running ~)
-[22:12:41] <scarabeus> yes
-[22:12:49] <scarabeus> but then we would expect archies to fill stablerequests
-[22:12:56] <scarabeus> we have tons of various packages just in ~
-[22:13:00] <dilfridge> but anyway ~ is better than ~+pmasked
-[22:13:03] <scarabeus> because nobody ever bothered to fill the bugs
-[22:13:15] <jmbsvicetto> it's up to us to ask for packages to be marked stable, but it's up to arch teams to take care of it
-[22:13:31] <dilfridge> (and to wait for 30days...)
-[22:13:36] <scarabeus> yes, and who else would have better motivation to ask for stables than people running it
-[22:13:40] <jmbsvicetto> I'm planning to add a request for amarok soon
-[22:13:56] <jmbsvicetto> but I need to check the status of the deps
-[22:14:16] <jmbsvicetto> I'll probably go for 2.3.0.90 or 2.3.1 directly and then drop all the older versions
-[22:14:50] <scarabeus> sounds sane :]
-[22:14:56] <jmbsvicetto> I'm also likely to merge amarok and amarok-utils as I don't see any interest on amarok-utils
-[22:15:10] <scarabeus> so i guess my plan with arch team wont work since we dont have anyone interested in it :P
-[22:15:21] <scarabeus> so only question left is which version 4.4.3 or 4.4.4
-[22:15:31] <scarabeus> devs plz pick :]
-[22:15:35] <scarabeus> jmbsvicetto: sounds also sane :]
-[22:15:39] <jmbsvicetto> well, most of us already have the blessing to do the work for amd64
-[22:16:05] <ABCD> I'd say 4.4.4 if we can convince the archies to do it in 7 days instead of 30
-[22:16:06] <jmbsvicetto> at this point, we can probably target 4.4.4
-[22:16:16] <scarabeus> ok
-[22:16:28] <scarabeus> 3 out of 5 attending devs
-[22:16:32] <scarabeus> added to summary
-[22:16:37] <scarabeus> next topic then
-[22:16:40] <scarabeus> kdepim 4.5
-[22:16:45] <dilfridge> ugh
-[22:16:49] <jmbsvicetto> ABCD: past history has showed that it takes a bit more than 1 or 2 weeks since we plan to ask for a package to get marked stable and to the request get to the arch teams ;)
-[22:17:12] <wired> i also vote for 4.4.4
-[22:17:19] <wired> btw we can stable amd64 ourselves
-[22:17:26] --> raxas (~raxas@charybdis-1-pt.tunnel.tserv6.fra1.ipv6.he.net) has joined #gentoo-meetings
-[22:17:28] <jmbsvicetto> besides, has anyone hit any regression from 4.4.3 to 4.4.4?
-[22:17:28] <scarabeus> yes yes
-[22:17:33] <dilfridge> no
-[22:17:47] <dilfridge> one last thing before we move on to kdepim
-[22:17:48] <jmbsvicetto> I haven't, but I didn't check the kdm user thing yet
-[22:17:56] <Wizzleby> No regressions from 4.4.3->4.4.4 here
-[22:18:14] <dilfridge> we will probably be drowned in akonadi problems when 4.4.x gets stable
-[22:18:25] <scarabeus> dilfridge: aware of that :/
-[22:18:29] <jmbsvicetto> hmm, I did restart kdm on my desktop and it's working, so I don't think that's an issue afterall
-[22:18:41] <dilfridge> (i was always too lazy to file a bug, but on my 3 machines it never started working properly)
-[22:18:57] -*- scarabeus does not even have kdepim installed
-[22:19:00] <scarabeus> too big pile of...
-[22:19:06] <scarabeus> anyway
-[22:19:10] <scarabeus> we have 3 options at our hands
-[22:19:12] <dilfridge> I like(d) it...
-[22:19:15] <jmbsvicetto> dilfridge: if you mean about kdepim, I don't have it installed locally :P
-[22:19:22] <scarabeus> ship kdepim from trunk with 4.5 releases, our tarballs
-[22:19:30] <scarabeus> make 4.5 work with 4.4 kdepim
-[22:19:36] <scarabeus> or finaly package enterprise branch
-[22:19:48] <jmbsvicetto> scarabeus: Perhaps we should start by making 2 questions:
-[22:19:59] <jmbsvicetto> 1. Which devs care or want to "mess" with kdepim
-[22:20:06] <krytzz> second is probably the easiest, as all distros wil do that right?
-[22:20:32] <scarabeus> krytzz: second is indeed easiest
-[22:20:39] <jmbsvicetto> 2. and depending on that we can just start a vote on the forums/mls/* explaining the issue to the users and getting a "vote" on how to proceed
-[22:20:42] <dilfridge> jmbsvicetto: alexxy was interested but sadly is not here
-[22:20:55] <scarabeus> i am definitely not interested in kdepim
-[22:20:59] <scarabeus> if that part of kde disappeared
-[22:21:01] <scarabeus> i would be happy man
-[22:21:10] <scarabeus> among with semantic-desktop team
-[22:21:11] <scarabeus> :D
-[22:21:21] <jmbsvicetto> I don't plan to touch kdepim too
-[22:21:23] -*- dilfridge would probably skip that release then as he need kdepim
-[22:21:42] <scarabeus> dilfridge: pst, we switched to claws and thunderbird, they works
-[22:21:49] <dilfridge> hehe
-[22:22:01] <jmbsvicetto> I've always used FF and TB, so no change for me ;)
-[22:22:11] <scarabeus> ok so seems noone is interested in this topic
-[22:22:18] <scarabeus> so lets postrpone it, i will sent mail to alias
-[22:22:23] <scarabeus> and i will pray that someone reply
-[22:22:24] <jmbsvicetto> scarabeus: what about my proposal?
-[22:22:27] <krytzz> what about reavertm, he did some work with pim :p
-[22:22:37] <scarabeus> jmbsvicetto: the forums are good idea, but first we need to pass step 1
-[22:22:43] <jmbsvicetto> scarabeus: we could set a plan like the following:
-[22:23:09] <jmbsvicetto> 1. give developers one week to express what they feel about kdepim and to see if anyone volunteers to work on it
-[22:23:43] <jmbsvicetto> 2. if that fails or we can't find anyone willing to do it, make a public announcement about the issue, explain it and give a few options to users:
-[22:24:11] <jmbsvicetto> 2.1 have interested parties show up and work in the overlay to get it done - (what can be given as option to the community)
-[22:24:18] <scarabeus> ok
-[22:24:25] <jmbsvicetto> 2.2 have users vote for us to just ignore kdepim until it gets working
-[22:24:26] <krytzz> will 4.5 be released one month afterwards? in that case you could postpone the whole 4.5 release for 1 month?
-[22:24:26] <ABCD> from what I heard, kdepim may show back up in 4.5.1 or 4.5.2
-[22:24:28] <scarabeus> that sounds like nice sumup
-[22:24:37] <jmbsvicetto> 2.3 give the above 3 options for someone to work on
-[22:25:23] <scarabeus> ABCD: with shitload of bugs
-[22:25:40] <ABCD> that's beside the point :D
-[22:25:41] <scarabeus> jmbsvicetto: added your approach to summary, since it sounds like only sane :]
-[22:25:45] <dilfridge> that's what 4.5.3456 will be for
-[22:26:02] <scarabeus> koffice-2.2
-[22:26:09] <scarabeus> dilfridge: i saw you working on it :]
-[22:26:18] <dilfridge> yes and it works afaik
-[22:26:21] <jmbsvicetto> That's another thing I don't plan to work on
-[22:26:24] <scarabeus> so wanna be designated maintainer?
-[22:26:38] <dilfridge> puh... I'm not actively using it so bad choice...
-[22:26:53] <dilfridge> (whenever I tried ooo did the job better)
-[22:27:13] <dilfridge> but I can look after it a bit yes
-[22:27:33] <jmbsvicetto> scarabeus: we could perhaps use this chance to ask for volunteers to work on koffice and kdepim
-[22:27:50] <jmbsvicetto> (not that I expect a horde to show up)
-[22:28:19] <scarabeus> well we need 2.2.0 in main tree stabilised asap
-[22:28:26] <scarabeus> because 2.1 is seriously useless
-[22:28:29] <dilfridge> I'd rather volunteer for some kdepim stuff than koffice...
-[22:28:49] <scarabeus> :DDD
-[22:28:55] <-- brk (~brk@r9dq22.net.upc.cz) has quit (Ping timeout: 260 seconds)
-[22:28:57] <jmbsvicetto> dilfridge: s/and/and or/
-[22:29:00] <scarabeus> lets try same approach as for kdepim then
-[22:29:27] <scarabeus> NEEEXT :D
-[22:29:44] <scarabeus> so dagger sent me mail
-[22:30:01] <scarabeus> if we would accept pulse patches
-[22:30:01] <scarabeus> that makes it work in kmix
-[22:30:02] <scarabeus> for now on we have policy that we dont backport patches
-[22:30:41] <scarabeus> so lets vote about wheter to accept patches or be strictly what upstream sends
-[22:30:57] <jmbsvicetto> scarabeus: since when? we always tried to follow upstream as closely as possible, but if someone is willing to apply a back-port and to keep it working, why not?
-[22:31:03] -*- alexxy here =)
-[22:31:07] <scarabeus> just write upstream/distro-patches based on what you want (only devs)
-[22:31:15] <scarabeus> jmbsvicetto: acutaly we declined quite few backports
-[22:31:39] <scarabeus> jmbsvicetto: for konsole in example
-[22:31:42] <jmbsvicetto> as long as we don't want to do it and there's no one in the team willing to do it, it's ok by me
-[22:31:57] <jmbsvicetto> scarabeus: iirc, ssuominem applied that patch again
-[22:32:27] <jmbsvicetto> I don't follow commits closely, but by reading the bugzilla mail, I think a few have been applied
-[22:33:12] <scarabeus> so lets keep status "if you keep it backported and polished you can have it..."?
-[22:33:17] <wired> backports++ from me if they fix stuff ;)
-[22:33:32] <jmbsvicetto> scarabeus: together with the old "you break it, you fix it" ;)
-[22:33:43] <wired> jmbsvicetto thats a must :P
-[22:34:05] <scarabeus> ok added to summary
-[22:34:13] <scarabeus> now the topic that is quite important
-[22:34:23] <jmbsvicetto> oh and about pulseaudio, I no longer care!! /me is using phonon-vlc :)
-[22:34:37] <wired> lol
-[22:34:42] <scarabeus> so inactive people in team
-[22:34:45] <scarabeus> what the f**k is everyone doing
-[22:34:51] <scarabeus> there is 17 people in the team
-[22:34:54] -*- jmbsvicetto goes hidding in the back
-[22:34:55] <scarabeus> ...
-[22:34:56] <scarabeus> :D
-[22:35:14] <jmbsvicetto> scarabeus: I guess the other 16 guys are very active :P
-[22:35:14] <scarabeus> on this meeting we have star attendance of 5 developers
-[22:35:24] <scarabeus> very very active
-[22:35:24] <wired> well
-[22:35:40] <alexxy> he he =)
-[22:35:50] <wired> scarabeus: you're to blame for this instance
-[22:35:58] <wired> you chose FRIDAY EVENING
-[22:36:05] <wired> failday for meeting :p
-[22:36:09] <scarabeus> i dont mind attendance for meeting
-[22:36:11] <jmbsvicetto> scarabeus: talking for myself, I took a lot of work when things were stalled, then you guys all started doing so much, I got used not needing to do too much ;)
-[22:36:16] <alexxy> its beerday 
-[22:36:16] <alexxy> =)
-[22:36:24] <scarabeus> but there is almost no activity on tree or ovelray by team members in kde area
-[22:36:29] <krytzz> right... only people without friends are online now
-[22:36:38] <scarabeus> not counting few active ones
-[22:36:45] <jmbsvicetto> krytzz: thanks :P
-[22:36:48] <scarabeus> so since joining team is really simple
-[22:36:50] <wired> \o/
-[22:37:10] <scarabeus> i would like to ask all those who are not really into working at least bit on kde remove themselves from herd
-[22:37:17] <scarabeus> they are mostly active in other areas of gentoo
-[22:37:31] <jmbsvicetto> scarabeus: Now you know how fun it is to have the pointy hat ;)
-[22:37:36] <scarabeus> and it would at least show me list of people i can count in
-[22:37:56] <wired> scarabeus: thats not going to work, most of them aren't even here :P
-[22:38:11] <scarabeus> and i will forceremove everyone who dont have at least 1 commint in last 2 months
-[22:38:17] <scarabeus> wired: it will be on summary
-[22:38:36] <scarabeus> they can join in back and be active
-[22:38:51] <scarabeus> or just commit here and there with our permission as other nonteam devs do now
-[22:39:14] <scarabeus> bonsaikitten: that counts you too ;]
-[22:39:35] <jmbsvicetto> scarabeus: ok, let me be clear about my commitment: I plan to do amarok as long as no one takes it out of me, I'm interested in phonon-vlc for the moment, I also have an interest on kdenetwork. I try to look at bugs and I get interested on stuff sent to packagers. I do however have a few other areas where there aren't active people on, so they sometimes take priority
-[22:39:40] <-- ABCD (~abcd@gentoo/developer/abcd) has quit (Ping timeout: 265 seconds)
-[22:40:03] <scarabeus> jmbsvicetto: you do commits in packages that have herd kde
-[22:40:19] <scarabeus> jmbsvicetto: there are people that didnt do any commit in those 2 named months back any of that
-[22:40:21] <bonsaikitten> scarabeus: yeah, that's fine with me
-[22:40:23] <jmbsvicetto> yeah, but I know I don't do many commits
-[22:40:26] <scarabeus> (i did some research)
-[22:40:33] -*- alexxy plays with beta/rc/snaphsots stuff
-[22:40:34] <scarabeus> jmbsvicetto: but you do something :]
-[22:40:34] <bonsaikitten> I'm mostly honorific member ;)
-[22:40:51] <wired> the last thing i did was fix koffice 2.1.81
-[22:40:51] <wired> ;p
-[22:40:55] <scarabeus> there is thin line between something and nothing
-[22:41:27] -*- jmbsvicetto gives a swift kick in bonsaikitten's honorific *slacker* member :P
-[22:42:04] <bonsaikitten> jmbsvicetto: you sound fat!
-[22:42:08] <wired> you know I was looking at the slacker definition the other day and it said also known as bonsaikitten or patrick
-[22:42:11] <wired> ;p
-[22:42:12] <jmbsvicetto> bonsaikitten: :P
-[22:42:22] <jmbsvicetto> wired: hehe
-[22:42:31] <alexxy> =)
-[22:42:50] <scarabeus> ?D
-[22:42:52] <scarabeus> ok
-[22:42:58] <alexxy> =P
-[22:42:59] <jmbsvicetto> wired: He has a bit to learn to catch some champs ;)
-[22:43:00] <scarabeus> i guess that is all of mine topics
-[22:43:03] <wired> omg
-[22:43:04] <scarabeus> so
-[22:43:08] <scarabeus> you have something to discuss
-[22:43:19] <scarabeus> http://paste.pocoo.org/show/222014/
-[22:43:19] <jmbsvicetto> a 40 minutes meeting? O_O
-[22:43:23] <scarabeus> also here is current summary
-[22:43:25] <alexxy> my 50 cents about kdepim
-[22:43:29] <scarabeus> i planned 10 minutes for each
-[22:43:34] <scarabeus> we were faster
-[22:43:52] <alexxy> i plan to package tarballs for 4.5.0
-[22:43:54] <alexxy> =)
-[22:44:14] <dilfridge> nice
-[22:44:18] <scarabeus> alexxy: that is mostly too late :P now you will have to work with others over mail :
-[22:44:19] <scarabeus> ]
-[22:44:29] <jmbsvicetto> reavertm: what are you planning to do with the cmake-utils eclass and was there any reason for the revert?
-[22:45:52] <scarabeus> alexxy: also remember that people will want to kill you if you blow up their mail client :D
-[22:46:03] <scarabeus> 1 thingie, anyone did log?
-[22:46:06] <scarabeus> for the log...
-[22:46:07] <scarabeus> :]
-[22:46:12] <scarabeus> i have just summary
-[22:46:14] <dilfridge> sure
-[22:46:19] <alexxy> i have log
-[22:46:21] <alexxy> =)
-[22:46:45] <wired> so do i
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100902.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100902.txt
deleted file mode 100644
index 4da84bc07e..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100902.txt
+++ /dev/null
@@ -1,234 +0,0 @@
-[21:14:55] <tampakrap> roll call
-[21:15:02] <reavertm> 1
-[21:15:05] <spatz> 2
-[21:15:07] <dilfridge> 3
-[21:15:18] <spatz> we lost abcd
-[21:15:28] <ABCD> 4
-[21:15:34] <tampakrap> and i am number five
-[21:15:55] <tampakrap> i would like to have a small talk about amarok in the
-end if jmbsvicetto manages to find us
-[21:15:59] <tampakrap> either way:
-[21:16:02] <ABCD> not even a quorum (for most definitions of "quorum")
-[21:16:08] <tampakrap>
-http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2010-09-02;h=e5a2764f178127e3f04e3311c12563b68a1b8dbe;hb=HEAD
-[21:16:15] <tampakrap> here's the agenda
-[21:16:23] <tampakrap> 1) KDE-4.5 status and plans to put it in Portage
-[21:16:29] <tampakrap> reavertm: you can start
-[21:16:39] <reavertm> ok, here it is:
-[21:17:04] <reavertm> there are following issues I'd consider a blockers
-[21:17:26] <reavertm> (unless we say - screw you users - upstream)
-[21:17:53] <reavertm> https://bugs.kde.org/show_bug.cgi?id=230247
-[21:18:47] <dilfridge> hmm here everything works fine _since_ the upgrade to
-4.5.0
-[21:19:02] <reavertm> result - you need to start any akonadi-client app twice
-in order to use it (first start will make akonadi start bug won't detect that
-it started)
-[21:19:18] <dilfridge> but I'm not logging in/out very often
-[21:19:38] <reavertm> one blocker - kwin FBO bug has been fixed (commit
-reverted as I requested)
-[21:19:56] <reavertm> remaining ugly bugs: multiple plasma glitches in system
-tray
-[21:20:20] <tampakrap> plasma glitches were highly reduced in 4.5.1
-[21:20:31] <dilfridge> not seen for a while
-[21:20:37] <reavertm> https://bugs.kde.org/show_bug.cgi?id=246931
-[21:20:45] <tampakrap> if the akonadi bug is the only blocker i'd say let's
-put it in tree, and let the people know about it
-[21:20:46] <reavertm> no, they are still there
-[21:21:02] <reavertm> tampakrap: and spam out bugzilla for no reason?
-[21:21:20] <dilfridge> ah that yes that is still there... I got used to that
-bug...
-[21:21:27] <reavertm> https://bugs.kde.org/show_bug.cgi?id=247144 - another
-plasma glitch (folderview)
-[21:21:39] <reavertm> and most important - memory leaks in plasma-desktop
-[21:21:49] <reavertm> (minor leaks, but they are there)
-[21:22:19] <reavertm> dolphin tooltips issues as well as nepomuk related
-crashes seen to be gone at least
-[21:22:49] <tampakrap> i'd suggest let's put it in tree, but announce those
-bugs and make it clear that it's not going to be stabilized
-[21:22:50] <reavertm> oh, and one bug present in 4.4 alteady -
-https://bugs.kde.org/show_bug.cgi?id=247204
-[21:23:07] <tampakrap> i'm getting enough spam on IRC already, and i think it
-is usuable enough
-[21:23:21] <tampakrap> that's my opiniion, but it is your call mostly
-[21:23:24] <reavertm> with that state I don't think *any* 4.5 patch release is
-going to be stabilized, I won't allow it
-[21:23:31] <spatz> there are regressions in every major release but that's why
-we have testing. 4.5.1 seems good enough for tree
-[21:23:50] <dilfridge> seconded (I personally can work with it fine)
-[21:23:53] <reavertm> unless we clearly communicate - "we know it's broken -
-we reported bugs and they keep being ignored"
-[21:24:17] <tampakrap> reavertm: give me a list of the bugs, i can put them on
-the meeting summary
-[21:24:18] <spatz> 4.4 took a lot of time to be stabilized because of
-regressions too, that's how kde works, apparently
-[21:24:26] <tampakrap> and put the summary on my blog on planet gentoo and kde
-[21:24:32] <reavertm> I won't wrange any 4.5 bugs in our bugzilla, I want to
-make it clear :P
-[21:25:09] <reavertm> spatz: plasma devs utilized 'Broken Development Model"
-that's why
-[21:25:31] <spatz> I'm not pointing fingers, just stating facts :)
-[21:26:05] <tampakrap> ok, we made our points, reavertm: your call
-[21:26:13] <reavertm> tampakrap: fine, but you'll blog about it :) (with bug
-links there)
-[21:26:14] <tampakrap> since you fixed a couple of upstream bugs
-[21:26:23] <reavertm> aah, one more blocker
-[21:26:32] <reavertm> but on our side - handbooks handling
-[21:26:38] <dilfridge> yes that is true
-[21:26:51] <dilfridge> something is seriously broken there
-[21:27:01] <tampakrap> bug #?
-[21:27:28] <dilfridge> bug 296345
-[21:27:29] <reavertm> since 4.5 - docbooks are no longer bundled - so for
-every +handbook we need to pull docbook stuff like for kdelibs
-[21:27:30] <willikins> dilfridge: https://bugs.gentoo.org/296345 "kde 4.4.4:
-Compilation error when creating help search index - bad xslt pattern"; Gentoo
-Linux, KDE; NEW; ashl1future@gmail.com:kde@g.o
-[21:27:49] <dilfridge> ah different problem
-[21:27:52] <reavertm> err, i meant different handbook issue
-[21:28:40] <tampakrap> if there is no bug #, let's open one, fix that first
-and then put 4.5.1 to tree
-[21:29:12] <reavertm> I can fix it anyway (my handbook isse) - for instance by
-introducing KDE_HANDBOOK eclass variable instead of +handbook in IUSE (that
-could hold additional handbook dirs as well)
-[21:29:41] <tampakrap> ok
-[21:29:49] <tampakrap> anything else on this?
-[21:30:10] <reavertm> I think this is it wrt kde 4.5
-[21:30:29] <tampakrap> i have one more thing to say about it
-[21:30:36] <tampakrap> not so relevant
-[21:31:11] <reavertm> ?
-[21:31:12] <tampakrap> http://bugs.gentoo.org/show_bug.cgi?id=335123
-[21:31:43] <reavertm> hmm, works for me...
-[21:31:45] <tampakrap> these patches don't apply to kdepimlibs 4.5.0 and i
-don't know if by applying them to 4.4.5 only will break 4.5 as well
-[21:31:59] <tampakrap> i can reproduce here and the patches worked on my 4.4.5
-laptop
-[21:32:23] <tampakrap> so, any ideas?
-[21:32:36] <reavertm> does it affect only kde 4.5 + kdepim 4.4?
-[21:33:00] <reavertm> or it's some general bug?
-[21:33:01] <tampakrap> the patches are meant for 4.4.5 only, haven't tested to
-4.5
-[21:33:32] <tampakrap> but i don't want to introduce a new bug by applying the
-patches to kmail 4.4.5 and not to kdepimlibs 4.5.x
-[21:34:08] <reavertm> I'd prefer them to appear in svn..
-[21:34:13] <dilfridge> never had this problem here
-[21:34:51] <tampakrap> ah they are not taken from svn
-[21:34:54] <tampakrap> nice point
-[21:35:04] <tampakrap> ok thanks
-[21:35:10] <tampakrap> next issue i guess
-[21:35:20] <tampakrap> 2) KOffice 2.2 status
-[21:35:35] -*- reavertm shuts up
-[21:35:46] <tampakrap> i was away because of my thesis and vacations for too
-long, anyone knows the blockers of keeping this away from tree?
-[21:35:48] <dilfridge> needs bump to 2.2.2 (I had no time yet but that should
-not be difficult)
-[21:36:10] <dilfridge> there is a "workaround"
-[21:36:13] -*- reavertm disagrees, he saw multiple cmake changes and file/dir
-additions/removals
-[21:36:24] <dilfridge> ok have not checked yet
-[21:36:58] <dilfridge> considering kchart
-[21:37:10] <reavertm> I see when do svn update in koffice occassionally, it
-needs someone to closely follow up - and in our case when it's been abandoned
-for a while - full review from scratch likely
-[21:37:27] <dilfridge> The libraries do not link if kchart is not built at the
-same time, so what I did was
-[21:37:48] <dilfridge> do make a dummy ebuild for kchart for the meantime.
-[21:37:51] <reavertm> KMCOMPILECONLY can be used
-[21:38:06] <dilfridge> well it is done in koffice-libs
-[21:38:17] <dilfridge> but I wanted to keep something named kchart in portage
-[21:38:26] <dilfridge> so later upgrade remains painless
-[21:38:42] <reavertm> is it standalone app?
-[21:38:55] <dilfridge> so, now koffice-libs also installs kchart, and kchart
-does, well, nothing
-[21:39:13] <dilfridge> no I think only library
-[21:39:37] <tampakrap> i see
-[21:39:43] <dilfridge> apart from that nobody gave me negative feedback on
-2.2.1 yet
-[21:39:50] <tampakrap> i'd appreciate if there were more comments on the bug
-[21:39:56] <tampakrap> http://bugs.gentoo.org/show_bug.cgi?id=322147
-[21:39:59] <reavertm> then should be in koffice-libs imho - I'd like to avoid
-creating excessive libraries like used to be in kdepim
-[21:40:00] --> pesa
-(~Pesa@host169-125-dynamic.52-82-r.retail.telecomitalia.it) has joined
-#gentoo-meetings
-[21:40:02] <tampakrap> and i could help you with it
-[21:40:20] <tampakrap> i agree with that
-[21:40:48] <dilfridge> fine with me... but the plan is that kchart can be
-built separately again with 2.3
-[21:41:33] <tampakrap> is it already done in the live ebuilds?
-[21:41:47] <dilfridge> did not check yet
-[21:41:51] <tampakrap> ok
-[21:41:51] <reavertm> maybe they'll just add some host for that kpart, then
-kchart ebuilds will be justified, (but libkchart should still be in
-koffice-libs imho)
-[21:42:28] <reavertm> it can be embedded in any koffice app after all
-[21:43:07] <tampakrap> ok, i'm done with it, dilfridge any further comments?
-[21:43:15] <dilfridge> I'm kind-of-away from tomorrow for a week, so if
-anything should be done quickly I'm out
-[21:43:30] <dilfridge> but I guess its not that urgent
-[21:43:34] -*- reavertm needs to remember how it was decided - koffice-libs
-contains full functionality and kword for instance only word processor
-application (but kpart is provided by koffice-libs) - or installing kword
-makes kpart available
-[21:43:35] <tampakrap> indeed
-[21:44:08] <tampakrap> if the kpart is used by other ebuilds too it should be
-in koffice-libs
-[21:44:15] <tampakrap> else the split makes no sense
-[21:44:35] <dilfridge> we can find that out with the dependencies / linking
-[21:44:47] <dilfridge> since now all apps are for sure compiled after kchart
-[21:44:52] <reavertm> no, kparts are runtime-only things mostly
-[21:45:03] <dilfridge> ok true
-[21:45:20] <reavertm> (well, buildtime+runtime, but can be missing at runtime)
-[21:45:45] <dilfridge> i'd say we could give 2.2.1 a try
-[21:45:59] -*- dilfridge keeps fingers crossed
-[21:46:11] <tampakrap> ok
-[21:46:24] <tampakrap> next?
-[21:46:27] <reavertm> fine, but I'd suggest full review of them (for instance
-to check whether all koffice subdirs are packaged in ebuilds)
-[21:46:54] <dilfridge> reavertm: teach me how to do that, please! :) (in two
-weeks)
-[21:47:35] <tampakrap> ok next
-[21:47:49] <tampakrap> for next issue i would like alexxy but he seems not to
-be here
-[21:47:57] <reavertm> simple - take a look at koffice/ and check subdirs one
-by one against koffice ebuilds (KMEXTRA, KMCOMPILEONLY, KMEXTACTONLY)
-[21:48:25] <dilfridge> ok
-[21:48:48] <tampakrap> 3) KDEPIM beta packages are released
-[21:48:51] <tampakrap> i'll skip it
-[21:49:00] <tampakrap> and add a gentoo-desktop thread instead
-[21:49:05] <reavertm> we just want whole koffice covered (or some parts
-*intentionally* skipped)
-[21:49:14] <dilfridge> ok
-[21:49:27] <reavertm> skip it please
-[21:49:36] <reavertm> I don't want kdepim betas in overlay :P
-[21:49:47] <reavertm> (there are live ebuilds already)
-[21:50:11] <tampakrap> sebas stated in his blog that upgrade and downgrade
-would be easy since configs don't affect each other
-[21:50:50] <tampakrap> either way, we'll discuss it in gentoo-desktop
-[21:50:55] <tampakrap> 4) open floor
-[21:51:20] <dilfridge> about digikam
-[21:51:41] <dilfridge> the patches are cleaned up a lot, but it's not
-completely finished yet
-[21:52:02] <-- spatz (~spatz@gentoo/developer/spatz) has quit (Ping timeout:
-276 seconds)
-[21:52:23] <dilfridge> reavertm: if you want to have a look at it go ahead,
-but dont send anything upstream yet.
-[21:52:46] <dilfridge> at least 1.4.0 should now build fine
-[21:53:04] <dilfridge> I'll talk with the sci guys about clapack.
-[21:53:11] <reavertm> I'll wait
-[21:53:21] <tampakrap> i'm also going to unmask knerworkmanager very soon,
-please test
-[21:53:34] <tampakrap> i'm a bit worried about the versioning though
-[21:54:47] <reavertm> ah, as of open floor - I encourage people working with
-live and tagged ebuilds to use kde-misc/kde-overlay-servicemenus
-[21:55:07] <dilfridge> what does it do?
-[21:56:00] <reavertm> I've added simple Compare/Merge service menu - in
-dolphin select two files one by one to have them open in kompare (where you
-can interactively sync them)
-[21:56:15] <reavertm> to avoid manual copy paste
-[21:56:17] <tampakrap> w00t
-[21:56:19] <dilfridge> nice
-[21:56:43] <tampakrap> last issue, i'm going to remove a few inactive people
-from the team
-[21:57:14] <tampakrap> and if there is not anything else, i guess i should
-close the meeting
-[21:57:33] <reavertm> thanks
-[21:58:08] <tampakrap> meeting is over
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110210.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110210.txt
deleted file mode 100644
index 8adcf020c2..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110210.txt
+++ /dev/null
@@ -1,566 +0,0 @@
-[21:01:20] <scarabeus> lets roll
-[21:01:27] <scarabeus> rollcall lads
-[21:01:29] <scarabeus> !herd kde
-[21:01:29] <willikins> (kde) abcd, alexxy, dilfridge, jmbsvicetto, patrick, reavertm, scarabeus, spatz, tampakrap
-[21:01:32] <tampakrap> wait wait
-[21:01:43] <alexxy> ohhh
-[21:01:47] -*- jmbsvicetto hides
-[21:01:54] <alexxy> i completely forget about meeting
-[21:02:30] <scarabeus> tampakrap: sup
-[21:03:14] <tampakrap> need to ping more people
-[21:03:22] <reavertm> here
-[21:03:24] <scarabeus> so lets wait on tampy
-[21:03:53] <scarabeus> bonsaikitten: you are around?
-[21:04:01] <bonsaikitten> aye aye captain
-[21:04:11] <alexxy> he is square =)
-[21:04:26] <scarabeus> (not for much longer i hope)
-[21:04:41] <tampakrap> anyway, let's go
-[21:05:39] --> krytzz (~quassel@quassel/user/krytzz) has joined #gentoo-meetings
-[21:06:36] <scarabeus> so there are two guys whom can be lead
-[21:06:38] --> papillon81 (~papillon8@g230050057.adsl.alicedsl.de) has joined #gentoo-meetings
-[21:06:41] <scarabeus> bonsaikitten and tampakrap
-[21:06:45] <papillon81> greets
-[21:06:50] <scarabeus> so guys do you accept nomination?
-[21:07:14] <tampakrap> yes, and i nominate you and jmbsvicetto as well
-[21:07:21] <jmbsvicetto> no!!
-[21:07:33] -*- papillon81 nominates scarabeus, too, but knows he can't vote
-[21:07:46] -*- scarabeus humbly does not accept the nomination, cause he does not use this mess anymore :)
-[21:07:52] <papillon81> LOL
-[21:07:55] -*- reavertm nominates scarabeus
-[21:08:00] <scarabeus> GUYS!
-[21:08:20] -*- jmbsvicetto nominates scarabeus as well - just to be consistent
-[21:08:22] <tampakrap> ok i nominate reavertm
-[21:08:23] <bonsaikitten> lol
-[21:08:25] --> dilfridge (~quassel@gentoo/developer/dilfridge) has joined #gentoo-meetings
-[21:08:36] <tampakrap> i also nominate dilfridge
-[21:08:45] <tampakrap> because i like his hair style
-[21:08:48] <bonsaikitten> scarabeus: I guess we won't have a vote without a second candidate, so yes
-[21:09:26] <dilfridge> grr sorry having slight dsl problems
-[21:09:27] -*- alexxy also nominates scarabeus and tampakrap =D
-[21:09:30] <dilfridge> grr sorry having slight dsl problems
-[21:09:37] <dilfridge> err
-[21:09:37] <jmbsvicetto> ok, so we have nominations for: tampakrap, bonsaikitten, scarabeus, jmbsvicetto, reavertm and dilfridge. Anyone else?
-[21:09:47] <dilfridge> ah
-[21:10:01] <dilfridge> here
-[21:10:09] <jmbsvicetto> tampakrap and bonsaikitten accepted. I refused. Others?
-[21:10:30] <scarabeus> i refuse
-[21:10:32] -*- reavertm nominates alexxy for good behaviour and tree bumps
-[21:10:44] <alexxy> no!!!!!!
-[21:11:02] <jmbsvicetto> so, reavertm and dilfridge, do you accept your nominations?
-[21:11:10] <jmbsvicetto> alexxy: I'm counting you as refusing
-[21:11:19] <alexxy> yep =)
-[21:11:23] <scarabeus> jmbsvicetto: you write summary>?
-[21:11:28] <tampakrap> no, i will
-[21:11:29] <jmbsvicetto> scarabeus: NO!! :P
-[21:11:34] <scarabeus> ook i am
-[21:11:40] <jmbsvicetto> scarabeus: just helping to summarize points
-[21:11:48] <dilfridge> I'm not gonna refuse, but I'm not the best choice... I may drop offline for a while at any point because of real-life workload
-[21:11:50] <tampakrap> I WILL WRITE THE SUMMARY
-[21:11:53] <reavertm> well, I can accept but be advised I'm not active any more as I used to
-[21:12:04] <likewhoa> scarabeus: who's going to protect the children now that you won't be lead?
-[21:12:19] <jmbsvicetto> so it seem we have 4 candidates: tampakrap, bonsaikitten, reavertm and dilfridge
-[21:12:30] <jmbsvicetto> seems*
-[21:12:46] <tampakrap> so, how do we vote?
-[21:12:53] <jmbsvicetto> Should we open an "election window" so everyone in the team can cast their vote?
-[21:13:02] <scarabeus> nopes
-[21:13:03] <scarabeus> here
-[21:13:03] <dilfridge> huh?
-[21:13:04] <scarabeus> now
-[21:13:06] <scarabeus> attending
-[21:13:06] <jmbsvicetto> one way would be to vote to the kde alias or gentoo-desktop ml
-[21:13:11] <scarabeus> jmbsvicetto: dilfridge said no
-[21:13:28] <tampakrap> he said he is NOT going to refuse
-[21:13:29] <jmbsvicetto> scarabeus: I read it as "I'm not going to refuse"
-[21:13:39] <dilfridge> jmbsvicetto: correct
-[21:13:48] <scarabeus> ah
-[21:13:51] <jmbsvicetto> so 4 candidates
-[21:13:52] <tampakrap> ok, how do we vote? only one choice?
-[21:14:10] <likewhoa> poll?
-[21:14:10] <scarabeus> yeah one choice
-[21:14:16] <dilfridge> one choice
-[21:14:31] <jmbsvicetto> Do you want to vote by email / irc / votify? Do we want a public or private election?
-[21:14:39] <dilfridge> oh dear
-[21:14:43] <jmbsvicetto> just asking
-[21:14:55] <reavertm> I can vote now, by irc
-[21:14:57] <jmbsvicetto> I don't have any preference
-[21:15:08] <scarabeus> now over irc one person
-[21:15:08] <jmbsvicetto> Do we have enough KDE team members around to do it?
-[21:15:11] <scarabeus> kthx
-[21:15:13] <scarabeus> yes we do
-[21:15:14] <dilfridge> no preference here either
-[21:15:17] <jmbsvicetto> good
-[21:15:19] <alexxy> by irc =)
-[21:15:21] <scarabeus> i watch this stuff
-[21:15:29] <dilfridge> !herd kde
-[21:15:30] <willikins> (kde) abcd, alexxy, dilfridge, jmbsvicetto, patrick, reavertm, scarabeus, spatz, tampakrap
-[21:15:50] <dilfridge> please acknowledge your presence :)
-[21:15:51] <jmbsvicetto> to get elected someone needs to get 5 votes - at least on the first vote count. Agreed?
-[21:15:52] <tampakrap> abcd and spatz seem to be missing
-[21:15:54] <likewhoa> abcd and spatz missing or not active
-[21:16:15] <dilfridge> abcd present but inactive
-[21:16:32] <jmbsvicetto> 5 out of 9 - to get > 50%
-[21:16:38] <dilfridge> ok
-[21:16:56] <jmbsvicetto> so, shall we vote?
-[21:17:28] -*- reavertm present and active
-[21:17:34] <bonsaikitten> present
-[21:17:38] <dilfridge> present
-[21:17:42] <tampakrap> present
-[21:17:44] <alexxy> present
-[21:17:47] <scarabeus> present
-[21:18:02] <bonsaikitten> that's at least 7 as far as I can tell
-[21:18:19] <jmbsvicetto> present
-[21:18:37] <bonsaikitten> means we can do irc vote now
-[21:18:47] <bonsaikitten> public vote acceptable? I am indifferent
-[21:18:55] <scarabeus> just go public
-[21:18:58] <scarabeus> why to hide
-[21:19:03] <scarabeus> (come on as retiring one ic
-[21:19:04] <bonsaikitten> yes, any opposition?
-[21:19:09] <scarabeus> an just decide that)
-[21:19:11] <jmbsvicetto> not from me
-[21:19:14] <dilfridge> no opposition here
-[21:19:17] <tampakrap> public
-[21:19:24] <reavertm> go ahead public
-[21:19:30] <jmbsvicetto> so, votes?
-[21:19:41] <scarabeus> vote: tampakrap
-[21:19:42] -*- dilfridge votes tampakrap
-[21:19:54] -*- bonsaikitten votes for tampakrap
-[21:20:00] -*- tampakrap votes reavertm
-[21:20:05] -*- alexxy votes for tampakrap
-[21:20:06] -*- reavertm votes tampakrap
-[21:20:31] <jmbsvicetto> tampakrap:
-[21:20:39] -*- jmbsvicetto votes tampakrap 
-[21:20:43] <bonsaikitten> that's 6 for tampakrap already, which is a simple majority
-[21:20:46] <dilfridge> I guess that counts as a majority
-[21:20:56] <jmbsvicetto> tampakrap: Congratulations ;)
-[21:20:58] <scarabeus> yep
-[21:21:03] <tampakrap> thank you ladies
-[21:21:03] <reavertm> congrats
-[21:21:04] <bonsaikitten> I like efficiency :)
-[21:21:10] <tampakrap> i'm going to dissapoint you for sure
-[21:21:24] <reavertm> that's why we voted you ;)
-[21:22:01] <alexxy> =D
-[21:22:06] <dilfridge> which means 9% of the agenda is DONE! Yeah!
-[21:22:26] <tampakrap> ok i'm going to chair the rest of the meeting
-[21:22:35] <tampakrap> 1) status regarding hal
-[21:22:55] <tampakrap> it is dead, not needed in 4.6, i'm going to convert samuli's forum post to guidexml
-[21:22:59] <tampakrap> anything else to say here?
-[21:23:01] <dilfridge> anyone still running hal here?
-[21:23:01] <reavertm> well, when 4.5 is ouot, we won't need it anymore
-[21:23:18] <dilfridge> (and 4.4)
-[21:23:38] <tampakrap> ok
-[21:23:41] <tampakrap> anything else about it?
-[21:23:49] <reavertm> I'd say wait for 4.6.1 and then remove 4.5 from tree, then HAL can die
-[21:24:02] <tampakrap> discussion about the future of 4.6 is later in the list
-[21:24:10] <reavertm> ah, 4.4...
-[21:24:14] <scarabeus> ook we need to keep it until 5
-[21:24:17] <scarabeus> 4.6 is stable
-[21:24:22] <scarabeus> typo with the 5
-[21:24:36] <tampakrap> http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2011-02-10;h=3d4869e4043c080750c68b2c7da66cfaf10f3c0d;hb=298fad1df1839ec400a346a9c60036a96e0b440e
-[21:24:40] <tampakrap> topics here btw
-[21:24:51] <tampakrap> ok we're done with hal, next
-[21:24:56] <tampakrap>    5 2) should we try to form a "stable kde devs" team? meaning just call for volunteers on the dev ml?
-[21:25:01] <tampakrap> 2) should we try to form a "stable kde devs" team? meaning just call for volunteers on the dev ml?
-[21:25:07] <dilfridge> that was my idea
-[21:25:17] <reavertm> please elaborate
-[21:25:18] <dilfridge> basically many of us are running 9999
-[21:25:46] <dilfridge> and right now the distance between 9999 and stable is so huge that it can be difficult to test stable bugfixes
-[21:25:52] <tampakrap> my opinion is we don't need it, we usually stabilize fast, with the great exception of 4.5
-[21:26:03] <reavertm> by '9999' you mean 4.x.9999 as well?
-[21:26:07] <dilfridge> the problem may go away on its own with 4.6
-[21:26:08] <scarabeus> we dont sta le
-[21:26:12] <scarabeus> misc apps are slow
-[21:26:15] <scarabeus> seriously
-[21:26:24] <scarabeus> some of them were stabilised by me with the last cleanup
-[21:26:29] <tampakrap> who cares? i will stabilize them on user request
-[21:26:31] <scarabeus> other than that nobody bothers opening bugs
-[21:26:38] <tampakrap> and by me and dilfridge as well
-[21:26:48] <dilfridge> we may forget about this point if we get a 4.6 stable soonish
-[21:27:07] <alexxy> and if we drop older releases
-[21:27:13] <tampakrap> again, discussion about 4.6 future is later in the list, so let's skip this point for now
-[21:27:20] <tampakrap> dilfridge: agreed?
-[21:27:23] <dilfridge> but as long as we want to keep 4.4 still around, we should ask for some "stable testers" on the dev-ml
-[21:27:24] <dilfridge> yes
-[21:27:27] <dilfridge> agreed
-[21:27:29] <tampakrap> anything else here?
-[21:27:34] <dilfridge> no
-[21:27:43] <tampakrap> noone?
-[21:27:48] <tampakrap> ok, next:
-[21:27:52] <tampakrap> 3) kde-git/eclasses migration and status, move kdepim 4.6 beta in tree masked
-[21:28:13] <tampakrap> reavertm / Sput / scarabeus (i don't know who else) did some cleanings in the eclass
-[21:28:13] <scarabeus> ok i cleaned a mess we had in eclass
-[21:28:17] <scarabeus> now reaver is focused on it
-[21:28:21] <tampakrap> how is its status? can it be merged? ETA?
-[21:28:30] <scarabeus> sput is main person responsible for packages from my PoV
-[21:28:34] <scarabeus> aka he tests
-[21:28:42] <scarabeus> (but he is on date now)
-[21:28:46] <scarabeus> eta is upstream is insane
-[21:28:52] <scarabeus> cause it will take quite some time
-[21:28:52] <dilfridge> ?
-[21:28:54] <dilfridge> ok
-[21:29:03] <reavertm> we need git-2 in tree first (what else do you mean by 'merge'?)
-[21:29:15] <scarabeus> yeah git-2 is progressed as we speak
-[21:29:22] <tampakrap> migrate, not merge
-[21:29:23] <scarabeus> i need to talk with ulm a bout some variale names
-[21:29:48] <tampakrap> ok, so 1) git-2 in tree 2) review/test 3) move to tree
-[21:29:53] <tampakrap> can we have an ETA?
-[21:30:14] <tampakrap> and anything specific we should test?
-[21:30:20] <scarabeus> git2 14 days
-[21:30:29] <scarabeus> i want to hear if all features are implemented
-[21:30:34] <scarabeus> and if we lack something
-[21:30:40] <scarabeus> (i want to keep that mess minimal)
-[21:30:48] <scarabeus> i might to remove 2 cloning apoproaches and keep only one
-[21:30:52] <scarabeus> (the submodules one(
-[21:31:10] <reavertm> kde4-* seems to work - I don't think anyone will ever implement KMEXTRA-aware kde4-meta_src_unpack for git though
-[21:31:53] <dilfridge> has anyone tried koffice?
-[21:31:58] <tampakrap> yes
-[21:32:02] <tampakrap> it works
-[21:32:05] <likewhoa> dilfridge: wfm
-[21:32:19] <dilfridge> but with that calligra /&/&%(/& its prbably getting more complicated again
-[21:32:21] <scarabeus> i could complain about integration of tha tone shit
-[21:32:22] <dilfridge> ok good
-[21:32:26] <scarabeus> but go ahead
-[21:32:37] <dilfridge> we can get koffice out
-[21:32:47] <tampakrap> sure, do it
-[21:32:49] <dilfridge> actually I think that it should go out
-[21:32:56] <dilfridge> once I have the time...
-[21:33:01] <tampakrap> yes, i agree, i can help
-[21:33:07] <dilfridge> ok cool
-[21:33:08] <tampakrap> do you want to move the code to ebuilds directly?
-[21:33:29] <dilfridge> I have not made any plans at all
-[21:33:32] <dilfridge> so far
-[21:33:49] <dilfridge> but I think the only real issue is unpack/prepare
-[21:33:50] <tampakrap> anyway, moving the koffice bits out of the eclass is very wise thing to do
-[21:33:55] <tampakrap> reavertm: idea on how to do it?
-[21:34:09] <scarabeus> i already removed most bits sunshines
-[21:34:20] <tampakrap> of koffice?
-[21:34:20] <dilfridge> good
-[21:34:26] <scarabeus> yeah
-[21:34:30] <tampakrap> i didn't notice
-[21:34:34] <tampakrap> ok cool
-[21:34:36] <dilfridge> even better!
-[21:34:51] <tampakrap> so, ETA? scarabeus?
-[21:34:53] <tampakrap> a month?
-[21:34:55] <tampakrap> less?
-[21:35:19] <reavertm> there's still some koffice stuff in kde4-meta though
-[21:35:39] <scarabeus> i need to work on git-2 first
-[21:35:43] <scarabeus> so not sooner than month
-[21:35:58] <tampakrap> ok, if you can compile a list of todo for that we could help
-[21:36:03] <reavertm> I think deadlines would be unreliable anyway
-[21:36:12] <tampakrap> for the record mostly
-[21:36:17] <dilfridge> no deadlines just planning
-[21:36:36] <tampakrap> anyway, i think we are done here
-[21:36:46] <tampakrap> 4) Shall we drop useflags kdeenablefinal and/or kdeprefix to simplify code?
-[21:36:56] <tampakrap> shall we vote on this?
-[21:37:00] <scarabeus> no
-[21:37:05] <tampakrap> i really object
-[21:37:09] <scarabeus> the impementors should tell us
-[21:37:14] <scarabeus> kdeprefix - jorge
-[21:37:18] <tampakrap> we have about 10 bugs about kdeenablefinal, no big deal
-[21:37:19] <scarabeus> kdeenable - reaver
-[21:37:25] <dilfridge> my opinion: keep kdeenablefinal (it's upstream stuff), drop kdeprefix (it fills up our eclasses with cruft)
-[21:37:25] <tampakrap> and i want kdeprefix
-[21:37:27] <reavertm> please keep kdeenablefinal at least (it's cheap)
-[21:37:40] <scarabeus> kdeenable final should stay i agree
-[21:37:45] <tampakrap> the guy that filed the bugs for kdeenablefinal provided patches
-[21:37:46] <scarabeus> but kdeprefix i dont see anyone using it
-[21:38:00] <tampakrap> i plan to do it actually
-[21:38:21] <tampakrap> i want to switch back to live as my main desktop
-[21:38:31] <tampakrap> and i don't want a chroot as i did in the past
-[21:38:34] <reavertm> some packages cannot be kdeprefixed (bindings for instance)
-[21:38:41] <alexxy> hmm
-[21:38:42] <tampakrap> i plan to work on them
-[21:38:50] <reavertm> no, they can't
-[21:38:51] <alexxy> why we still need kdeprefix?
-[21:39:00] <alexxy> it will confuse end users
-[21:39:05] <tampakrap> it's a feature, we don't "need" it
-[21:39:13] <tampakrap> reavertm: why they can't?
-[21:39:18] <dilfridge> it makes our eclasses way too complicated
-[21:39:36] -*- reavertm doesn't think kdeprefix is complicated
-[21:39:52] <tampakrap> why can't they be prefixed? i haven't looked at the code yet
-[21:39:52] <reavertm> it definitely isn't like it used to be
-[21:39:57] <tampakrap> i suppose you did
-[21:39:59] <scarabeus> it is qutie clear
-[21:40:07] <scarabeus> but qutie few apps are not kdeprefix aware
-[21:40:09] <scarabeus> (misc one)
-[21:40:19] <scarabeus> and it has quite few bugs noone attendet to
-[21:40:25] <scarabeus> *ded
-[21:40:52] <tampakrap> ok then, give me time till the next meeting to test it and i'll report back
-[21:40:55] <reavertm> tampakrap: actually bindings may work but sip files needs to be slotted
-[21:41:08] <tampakrap> i plan to work on the misc apps and python packages
-[21:41:25] <reavertm> judge 1st it's worth your time
-[21:41:31] -*- reavertm thinks it isn't
-[21:41:37] <tampakrap> no, having to maintain a chroot is
-[21:42:12] <alexxy> well i use live on my laptop
-[21:42:22] <alexxy> and its only DE here
-[21:42:37] <tampakrap> anyway, do we all agree to keep kdeenablefinal and kdeprefix and bring the topic back again?
-[21:42:38] -*- dilfridge thinks a laptop can crash in more than one way anyway :D
-[21:43:05] <dilfridge> mumble... ok
-[21:43:44] <tampakrap> i see no objections, next:
-[21:43:51] <tampakrap> 5) Dropping of semantic-desktop useflag with guide update (mostly even kdebase needs it on now)
-[21:44:06] <tampakrap> i fixed it for plasma-workspace
-[21:44:09] <scarabeus> i would reat
-[21:44:13] <tampakrap> i had to write an upstream patch
-[21:44:16] <scarabeus> rather preffer it to be still availible
-[21:44:25] <scarabeus> virtuoso and semantic stuff is not something most might want
-[21:44:46] <tampakrap> our ebuilds are broken, upstream still has support for the useflag
-[21:45:11] <tampakrap> plasma-workspace along with libplasmaclock causes trouble with kdepimlibs due to our splitting
-[21:45:16] <tampakrap> i'll dig in more
-[21:45:16] <scarabeus> tampakrap: your fix suck
-[21:45:17] <dilfridge> does anyone know how this will develop for 4.7?
-[21:45:32] <scarabeus> tampakrap: i dont want libkdepim as harddep for it
-[21:45:38] <tampakrap> it doesn't, it was approved by aseigo
-[21:45:44] <tampakrap> what harddep?
-[21:45:49] <tampakrap> what are you talking about?
-[21:45:56] <reavertm> wait wait, libkepim != kdepimlibs
-[21:46:03] <dilfridge> and what happens when kdepim-4.6 goes in tree?
-[21:46:50] <tampakrap> https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/5701ee97f896bf25de5dfbcc2699695794f25b34
-[21:47:06] <tampakrap> this is the patch, where do you see a harddep?
-[21:48:11] <tampakrap> anyway, our affected ebuilds are plasma-workspace/libplasmaclock and kdeplasma-addons
-[21:48:19] <scarabeus> ah i am talking about plasma workspace
-[21:48:21] <scarabeus> :)
-[21:48:22] <tampakrap> i saw the code, the problem is in our side
-[21:48:27] <reavertm> first of all, libkdepim is from KDEPIM, and it's not kdepimlibs
-[21:48:33] <tampakrap> the patch is in plasma-workspace
-[21:48:59] <reavertm> anything else needs kdepimlibs?
-[21:49:11] <tampakrap> nothing needs it, it is still optional
-[21:49:30] <reavertm> why do we have this agenda item then? :P
-[21:50:00] --> dilfridge_ (~quassel@gentoo/developer/dilfridge) has joined #gentoo-meetings
-[21:50:01] <tampakrap> i have no idea, i am just pointing out that the item is invalid, the problem is in our side
-[21:50:06] <-- dilfridge (~quassel@gentoo/developer/dilfridge) has quit (Ping timeout: 240 seconds)
-[21:50:16] <scarabeus> ok in that case ebuilds need fixing
-[21:50:22] <scarabeus> before we can stable 4.6
-[21:50:26] <tampakrap> yes, we have open bugs and i am working on it
-[21:50:49] <tampakrap> 6) Making +consolekit and +policikit or removing the useflags as whole (non working stuff run-as is annoying)
-[21:51:00] <tampakrap> no idea about this one
-[21:51:12] <scarabeus> thats from me
-[21:51:26] <scarabeus> if those two are not around most of the user perms stuff is not working
-[21:51:31] <scarabeus> so users might complain a lot
-[21:51:31] <dilfridge_> I remember from some upstream bug report that one of them is now required
-[21:51:41] <scarabeus> so i would go and just make it required
-[21:51:42] <scarabeus> really
-[21:51:51] <dilfridge_> if not it is just broken (not supported anymore)
-[21:52:02] <-> dilfridge_ is now known as dilfridge
-[21:52:04] <-> dilfridge is now known as dilfridge_
-[21:52:06] <-> dilfridge_ is now known as dilfridge
-[21:52:37] <tampakrap> is it too much load if we make them harddeps?
-[21:52:42] <scarabeus> nope
-[21:52:45] <scarabeus> like 5 more deps
-[21:52:48] <tampakrap> sure then
-[21:52:49] <bonsaikitten> people will whine, as usual
-[21:53:04] <dilfridge> it kind of forces a more modern system, but makes debugging for us easier
-[21:53:04] <scarabeus> for sure
-[21:53:11] <reavertm> what about macos?
-[21:53:19] <reavertm> do they have different KAuth backend?
-[21:53:37] <tampakrap> http://techbase.kde.org/Development/Tutorials/KAuth/KAuth_Basics
-[21:53:47] -*- dilfridge thinks the weird guys should be handled later
-[21:54:19] <tampakrap> i don't see anything arch specific there
-[21:54:33] <reavertm> no, because it may determine we can't harddep them
-[21:54:43] <tampakrap> do we have them enabled by default?
-[21:54:48] <tampakrap> if not, can we do this instead?
-[21:55:40] <papillon81> people should know that they need some things as deps to have a DE like KDE run normally
-[21:55:47] <reavertm> tampakrap: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/show/kdecore/auth/backends
-[21:56:21] <tampakrap> yeah
-[21:56:38] <tampakrap> so, should we ask upstream?
-[21:56:47] <tampakrap> i could mail those guys listed in the changelog
-[21:56:59] <reavertm> no need
-[21:57:06] <tampakrap> or we could enable it by default for everything but mac
-[21:57:08] <reavertm> I'd add IUSE defaults
-[21:57:20] <dilfridge> reavertm: please not
-[21:57:30] <dilfridge> people WILL try to switch it off
-[21:57:42] <dilfridge> it does not help
-[21:57:45] <papillon81> yes
-[21:57:55] <reavertm> it doesn, then we can say - screw you, you disabled it
-[21:58:08] <tampakrap> yeah, elog
-[21:58:14] <papillon81> reavertm: it's a use flag so people think its optional
-[21:58:16] <tampakrap> endofstory
-[21:58:24] <dilfridge> and we have wasted time trying to find the problem and added additional cruft to the eclass
-[21:58:31] <tampakrap> and elog gives me the right to invalid their bug
-[21:58:38] <reavertm> it's also enabled by default which means there's some thinking behind it
-[21:59:12] <dilfridge> we may be in the land of infinite options but not in the land of infinite support manpower
-[21:59:37] <tampakrap> i agree with IUSE defaults ftr
-[21:59:50] <reavertm> maybe use.force :P
-[22:00:02] <scarabeus> god just drop it and let the 4 people complain
-[22:00:05] <dilfridge> reavertm: that's ok I guess
-[22:00:06] <reavertm> (someone can use.mask if one wants)
-[22:00:09] <scarabeus> come on we threw mysql their way
-[22:00:11] <scarabeus> and nobody whine
-[22:00:12] <scarabeus> d
-[22:00:15] <scarabeus> nowdays
-[22:00:16] <scarabeus> :D
-[22:00:19] <dilfridge> drop it!
-[22:00:51] <tampakrap> reavertm: your call :P
-[22:01:02] <tampakrap> i don't care much
-[22:01:40] -*- reavertm thinks the one who is going to do the job, should decide
-[22:02:37] <reavertm> I'm prefer not to drop use flags though
-[22:02:39] <scarabeus> reavertm: ok your call
-[22:02:52] <scarabeus> reavertm: tampakrap is the one who decide in the end nowdays :)
-[22:03:02] <reavertm> it's not really a harddep if one wants just kdelibs + misc stuff
-[22:03:13] <tampakrap> yeah i don't like dropping the useflag
-[22:04:04] <reavertm> does use.force have precedence over use.mask?
-[22:05:02] <reavertm> (I mean, is it possible for etc/portage/*/use.mask to disable use.forced flag?
-[22:05:17] <tampakrap> no idea
-[22:05:55] <tampakrap> anyway, it is taking too long, let's decide in the mailing list instead
-[22:06:02] -*- reavertm votes for use.mask
-[22:06:08] <reavertm> use.force*
-[22:06:11] <tampakrap> i'll send the mail, we can get some feedback from users as well
-[22:06:21] <reavertm> ok
-[22:06:30] <dilfridge> use.force is easily done and reversible
-[22:07:20] <reavertm> and should be hard enough for users to switch off
-[22:07:24] <tampakrap> dilfridge: agree to continue in the ml?
-[22:07:29] <dilfridge> ok
-[22:07:36] <tampakrap> thank you
-[22:07:39] <tampakrap> 7) AT/overlay/bugzie access policy
-[22:07:43] <tampakrap> this is mine
-[22:08:07] <tampakrap> scarabeus: i need a clear list on who has access to the overlay, who has editbugs privs and who is a KDE AT
-[22:08:11] <tampakrap> and compile a page
-[22:08:38] <tampakrap> and i need to define a rule for ATs, and get all those priviledges together
-[22:08:40] <scarabeus> tampakrap: ahem you have access to the list
-[22:08:41] <tampakrap> do you agree?
-[22:08:46] <scarabeus> i dont have it
-[22:08:53] <scarabeus> and i upgraded everyone to at already
-[22:08:56] <tampakrap> lol, i know, i'm just saying
-[22:08:58] <papillon81> who can potentially have elevated rights in bugzie?
-[22:09:04] <papillon81> only real devs?
-[22:09:11] <scarabeus> even users
-[22:09:19] <scarabeus> which we are watching
-[22:09:31] <dilfridge> "arch testers", "overlay committers"
-[22:09:32] <tampakrap> the one who has finished ebuild quiz, has gone through an AT/HT review session and someone is watching him
-[22:10:14] <tampakrap> so, define two groups of people in addition to ATs?
-[22:10:28] <dilfridge> hmm?
-[22:10:39] <dilfridge> what two groups?
-[22:12:14] <tampakrap> ATs, overlay commiters
-[22:12:20] <tampakrap> is that what you just said?
-[22:13:06] <dilfridge> nono I was just trying to make a point to papillon81
-[22:13:44] <tampakrap> ah k
-[22:13:53] <tampakrap> scarabeus: i need your idea on what to do here
-[22:14:03] <dilfridge> in effect, the two groups would be "overlay committers" and "bugedit", but I'm not sure if it would make sense to make just one group for that
-[22:14:08] <tampakrap> i have no idea how to clean up this mess
-[22:14:11] <dilfridge> simplifies things
-[22:14:25] <tampakrap> eg Sput refuses to become an AT, doesn't want ot finish ebuild quiz
-[22:14:40] <scarabeus> just have two groups, access ; access + bugedit which == AT
-[22:14:44] <tampakrap> we could have overlay commiters and full ATs but i don't like it
-[22:15:48] <tampakrap> anyway, i'll compile the list first and bring the topic up again
-[22:16:04] <tampakrap> who is going to be AT lead now? or should we drop the title?
-[22:16:15] <tampakrap> i find it a bit useless, like every lead position :P
-[22:16:45] <dilfridge> drop it
-[22:17:16] <tampakrap> no volunteers :P
-[22:17:23] <tampakrap> next:
-[22:17:25] <tampakrap> 8) livedvd issues
-[22:17:28] <reavertm> who knows, AT lead does more recruiting work imho
-[22:17:31] <tampakrap> likewhoa: anything to say here?
-[22:17:47] <tampakrap> reavertm: do you want the position then?
-[22:17:50] <likewhoa> nothing really just a few request made by users
-[22:18:11] <reavertm> tampakrap: hell no
-[22:18:27] <tampakrap> thought so :)
-[22:18:33] <likewhoa> i added an icon to the kde start menu and some users wanted to know if kde can make use of it, also some users wanted to know if there were any gentoo centric kde themes
-[22:18:37] <tampakrap> likewhoa: shoot now that we are all here :)
-[22:18:57] -*- dilfridge runs
-[22:19:06] -*- likewhoa pulls dilfridge back with some cookies
-[22:19:22] <tampakrap> well, tbh i need someone to do some graphics work if we are going to implement branding
-[22:19:33] <tampakrap> and i couldn't find anyone the last two years
-[22:19:49] <likewhoa> tampakrap: poke a3li
-[22:19:59] <tampakrap> he hates kde
-[22:20:11] <likewhoa> i can also do graphics but won't be available for that until mid march
-[22:20:30] <likewhoa> tampakrap: i made the wallpapers for the livedvd, not the one on the desktop but the others ones
-[22:20:37] <likewhoa> i think jmbsvicetto used one for FOSDEM
-[22:21:25] <tampakrap> well, if you are willing to help here i'm all in add it to the tree
-[22:21:29] <likewhoa> but a kde gentoo centric theme would be ideal and can be part of the branding USE flag
-[22:21:35] <tampakrap> sure
-[22:21:46] <tampakrap> let's do some work first and bring the topic back again
-[22:21:56] <likewhoa> ok
-[22:22:08] <tampakrap> anything else?
-[22:22:13] <likewhoa> no
-[22:22:19] <tampakrap> cool thanks
-[22:22:28] <tampakrap> please everyone test the dvd :)
-[22:22:31] <tampakrap> in #gentoo-ten
-[22:22:44] <likewhoa> use zsync so you don't waste bandwidth on new releases
-[22:22:51] <likewhoa> net-misc/zsync that is
-[22:23:03] <tampakrap> next:
-[22:23:06] <tampakrap> 9) documentation status
-[22:23:16] <tampakrap> pretty please everyone read the documentation
-[22:23:36] <tampakrap> help me to complete the tips and troubleshoot with 4.6 specific parts
-[22:24:09] <tampakrap> i wanted to say something more about this one but i forgot it
-[22:24:19] <tampakrap> anyway, i'll merge the last two topics:
-[22:24:26] <tampakrap> 10) 4.6 (and misc apps with 4.6) status
-[22:24:33] <tampakrap> 11) early discussion about 4.6 stabilization
-[22:25:03] <tampakrap> i'm listening, i vote early for 4.6.1 stabilization :)
-[22:25:16] <papillon81> stabilize 4.6 as quick as possible. 4.6.1
-[22:25:41] <tampakrap> i need more feedback about misc apps though
-[22:25:57] <dilfridge> stabilize early. 4.6.1 should be fine.
-[22:25:57] <tampakrap> for example, knetworkmanager is broken and i lack the hardware to test currently
-[22:25:58] <papillon81> knetworkmanager is waiting for ubuntu
-[22:26:12] <tampakrap> sorry?
-[22:26:27] <reavertm> 4.6... doesn't feel worse than 4.5
-[22:26:34] <papillon81> i talked with wstephenson about it yesterday
-[22:26:39] <papillon81> strange, I know
-[22:26:40] <dilfridge> do we want to wait for kdepim? if we say "stabilize fast" that means no
-[22:26:50] <tampakrap> i don't get you at all, sorry
-[22:26:56] <tampakrap> it is waiting for ubuntu to do what?
-[22:27:11] <reavertm> tarball release /me thinks
-[22:27:38] <tampakrap> well, let's wait for kdepim to get a proper release first :)
-[22:28:14] <papillon81> <wstephenson> kubuntu are 'a bit worried' that it will be before KNM is ported to 0.9
-[22:28:49] <papillon81> tampakrap: what exactly is broken in you opinion?
-[22:28:59] <tampakrap> i have no idea, i saw a bug report
-[22:29:07] <tampakrap> but my laptop is off now and i can't test
-[22:29:12] <tampakrap> something about kwallet i think
-[22:29:25] <tampakrap> i would like more to know though about this
-[22:29:35] <papillon81> well. i can look into it. also there are some nice patches from the pardus guys
-[22:29:36] <tampakrap> eg dilfridge: how is digikam/koffice in 4.6?
-[22:29:42] <dilfridge> fine
-[22:29:56] <tampakrap> reavertm: printing?
-[22:29:59] <tampakrap> any progress?
-[22:30:02] <dilfridge> 2.2.2 (stable) is broken but 2.3.1 is good
-[22:30:36] <reavertm> printing.. some people report it works
-[22:31:02] <dilfridge> since when is kde supposed to do printing? =)
-[22:31:09] <tampakrap> since 4.4
-[22:31:15] <tampakrap> "supposed"
-[22:31:27] <dilfridge> I thought that feature was disabled with 4.0 ...
-[22:31:40] <reavertm> I bump scp usually on time, scp-kde - I'd prefer it to be still in ~arch
-[22:32:00] <reavertm> the feature was not ported to kde4 at all, you're right
-[22:32:55] <tampakrap> anyway, we can discuss it next month after 4.6.1 gets a release
-[22:33:08] <tampakrap> i remembered what i wanted to say about documentation
-[22:33:10] <tampakrap> http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=Documentation;h=d7e234375abd5fc61c4d7dae47adaf57d9efcac1;hb=HEAD
-[22:33:12] <reavertm> nothing to discuss here, printing will not go stable
-[22:33:36] <tampakrap> i'm going to port them to guidexml (CODE, README etc) or merge them with the guide
-[22:33:47] <dilfridge> good idea
-[22:34:00] <tampakrap> i'll need feedback to the documentation though (pretty please)
-[22:34:15] <tampakrap> i think we are done
-[22:34:21] <tampakrap> *) open floor
-[22:34:32] <dilfridge> did anyone of you hear from the digikam guys?
-[22:34:45] <scarabeus> dilfridge: i am talking with will (suse)
-[22:34:54] <scarabeus> to shutup him abvout the opensuse argument
-[22:34:56] <scarabeus> so wait a bit
-[22:34:58] <dilfridge> ok... what's the general feeling there
-[22:35:00] <dilfridge> ok
-[22:35:01] <scarabeus> cross distro coord takes lot time
-[22:35:03] <tampakrap> what argument?
-[22:35:25] <reavertm> so opensuse doesn't mind slotting and bundled libs?
-[22:35:27] <scarabeus> tampakrap: "opensuse likes the libs bundled"
-[22:35:35] <tampakrap> yeah good idea
-[22:35:46] <dilfridge> https://bugs.kde.org/show_bug.cgi?id=265328#c6
-[22:35:57] <scarabeus> plus debian and others already agreed not to ship digikam2
-[22:36:05] <scarabeus> if the issue is not resolved
-[22:36:09] <reavertm> scarabeus: please bring svuorela to the table
-[22:36:19] <scarabeus> reavertm: he?
-[22:36:21] <scarabeus> ah
-[22:36:32] <reavertm> debian guy
-[22:36:43] <tampakrap> we met him in fosdem
-[22:36:49] <tampakrap> scarabeus: remember?
-[22:36:53] <scarabeus> yep
-[22:37:01] <scarabeus> that s why i said ah
-[22:37:07] <scarabeus> anyway will do so
-[22:37:07] <tampakrap> will anyone join me in desktop summit this year? :)
-[22:37:14] <tampakrap> aug 6th berlin
-[22:37:15] <scarabeus> where it is?
-[22:37:21] <tampakrap> http://www.desktopsummit.org/
-[22:37:29] <dilfridge> likely not me, other plans...
-[22:37:42] <tampakrap> if i make it (99% i will) i'll apply for a gentoo talk
-[22:37:53] <tampakrap> last year we were invited to do the talk
-[22:37:59] <papillon81> oh, Berlin. that's good
-[22:38:04] <scarabeus> berlin sounds good
-[22:38:15] <scarabeus> but i would need to couchsurf somewhere :)
-[22:38:27] <tampakrap> reavertm: how about you?
-[22:38:39] <reavertm> very unlikely
-[22:39:18] <reavertm> hmm, August... who knows..
-[22:40:05] <tampakrap> ok ladies, i think that's all
-[22:40:47] <reavertm> thanks
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110331.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110331.txt
deleted file mode 100644
index 84ecd70246..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110331.txt
+++ /dev/null
@@ -1,370 +0,0 @@
-[20:07:42] <tampakrap> !herd kde
-[20:07:42] <willikins> (kde) abcd, alexxy, dilfridge, jmbsvicetto, patrick, reavertm, scarabeus, spatz, tampakrap
-[20:07:43] -*- alexxy here
-[20:07:47] <tampakrap> roll call please
-[20:07:49] -*- dilfridge here
-[20:07:57] <jmbsvicetto> here
-[20:08:00] -*- scarabeus blurps
-[20:08:14] <tampakrap> dilfridge: wanna chair?
-[20:08:17] <tampakrap> for change
-[20:08:21] <dilfridge> uh oh
-[20:08:36] <dilfridge> err ok
-[20:09:01] <dilfridge> hehe the topic still links to last meeting
-[20:09:16] <dilfridge> so...
-[20:09:26] <dilfridge> let's look at the agenda.
-[20:09:42] <dilfridge> 1) kde-git/eclasses migration and status
-[20:09:58] <dilfridge> since I dont do live, what's the status?
-[20:10:23] <tampakrap> scarabeus: ^^ git eclass status?
-[20:10:47] -*- ABCD can't stay too long
-[20:10:48] <scarabeus> i got nice hint from exherbo guys and currently am attempting it to make bare checkouts even with submodules
-[20:10:57] <scarabeus> so if i manage to do that it would be epic
-[20:11:17] <dilfridge> oook, I remember the discussion on the ml
-[20:11:20] <scarabeus> but i didnt have time to focus on it lately
-[20:11:22] <tampakrap> can i get an option to use non-bare checkouts instead?
-[20:11:25] <scarabeus> as i blaged
-[20:11:42] <scarabeus> it is easy to override those commands as-is already
-[20:12:07] <dilfridge> i guess the more interesting question is does it still work then
-[20:12:34] -*- dilfridge can symlink /bin/echo to /usr/bin/portage
-[20:12:55] <dilfridge> but anyway
-[20:13:33] <dilfridge> the hard question: scarabeus: what's your guess how long this will take? very roughly?
-[20:13:52] <scarabeus> few days when i work on it so i can test everything
-[20:14:18] <tampakrap> afaik kde eclasses don't need anything, we are only waiting for git-2 to hit tree first
-[20:14:26] <tampakrap> correct me if i'm wrong
-[20:14:54] <scarabeus> if it is so it is quite easy to make them git.eclass dependant
-[20:15:17] <scarabeus> since there are no live ebuilds in main tree it does not affect anything by default
-[20:15:18] <dilfridge> meaning they would also work with current git.eclass?
-[20:15:32] <dilfridge> ah ok
-[20:15:51] <tampakrap> yeah, i'll prefer those eclasses to hit tree before 4.6.2
-[20:16:07] <tampakrap> so we can get proper testing from the stable candidate
-[20:16:07] <dilfridge> that could be pretty soon (today is official tagging day)
-[20:16:26] <tampakrap> yeah, this week
-[20:17:11] <dilfridge> do you want to selectively patch the main tree eclass or just copy everything from overlay (better)?
-[20:17:14] <tampakrap> can you paste us the link of the topics please?
-[20:17:38] <dilfridge> http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2011-03-31;hb=HEAD
-[20:17:48] <tampakrap> i'd like a quick review first, a patch in the alias or in -desktop would be preffered
-[20:18:03] <dilfridge> ok
-[20:18:22] <dilfridge> I'm asking because we "collect differences" between tree and overlay
-[20:18:46] <tampakrap> i would like to hear from reavertm before merging them
-[20:18:47] <dilfridge> at some point it would make sense to sort this out
-[20:18:50] <dilfridge> true
-[20:18:54] <scarabeus> we could ask for comments on -dev as is
-[20:19:01] <tampakrap> i don't know if he had any todo for the eclasses we are missing
-[20:19:07] <tampakrap> or that
-[20:19:09] <scarabeus> at least you others could work on the stuff people point out
-[20:20:01] <dilfridge> so, summarizing: we should do a review of the current overlay eclasses...
-[20:20:08] <scarabeus> yup
-[20:20:10] <dilfridge> * figure out what actually depends on git-2
-[20:20:15] <scarabeus> why
-[20:20:18] <scarabeus> that does not matter
-[20:20:26] <scarabeus> i can move it to git.eclass in 20 secs
-[20:20:32] <scarabeus> git-2 is not showstopper
-[20:20:35] <dilfridge> ok
-[20:20:40] <dilfridge> even better
-[20:21:20] <dilfridge> * collect a todo list (or make reavertm send us his)
-[20:21:37] <dilfridge> * and review the current differences between tree and overlay
-[20:21:53] <dilfridge> any volunteers? :D
-[20:22:28] <tampakrap> i'm not the eclass expert
-[20:22:39] <dilfridge> anyway
-[20:22:48] <dilfridge> back to teh agenda
-[20:23:01] <dilfridge> 2) move kdepim 4.6 beta in tree masked?
-[20:23:07] <dilfridge> opinions?
-[20:23:13] <tampakrap> no
-[20:23:18] <tampakrap> 1) it is outdated
-[20:23:24] <dilfridge> true
-[20:23:24] <ABCD> 2) it depends on updating eclasses first
-[20:23:27] <tampakrap> 2) there is no eclass support for it yet :P
-[20:23:30] <dilfridge> true
-[20:23:39] <tampakrap> but anyway, it is too outdated
-[20:23:49] <dilfridge> anyone in favour?
-[20:24:07] <tampakrap> and upstream kdepim will create new kdepim snapshots when a core kde developer asks to
-[20:24:13] <tampakrap> huge mess
-[20:24:22] <scarabeus> wtf
-[20:24:27] <scarabeus> they should release that shitz :D
-[20:24:28] <tampakrap> i could create our own snapshots, but i don't care enough to be honest
-[20:24:34] <dilfridge> I guess that answers the question
-[20:24:36] <scarabeus> most people are getting annoyed :)
-[20:24:47] <dilfridge> any news about an official release (schedule)?
-[20:25:14] <tampakrap> no
-[20:25:21] <dilfridge> :(
-[20:25:26] <jmbsvicetto> tampakrap: is there any kdepim version that can work with 4.5.5, 4.6* ?
-[20:25:28] <jmbsvicetto> kde*
-[20:25:28] <tampakrap> they said about an rc1 but apparently it didn't make it
-[20:25:35] <tampakrap> yes, 4.4.10
-[20:26:12] <jmbsvicetto> tampakrap: so we can use kdepim-4.4.10 with kde-4.5.5/4.6 to move forward?
-[20:26:32] <dilfridge> seems so
-[20:26:40] <jmbsvicetto> and sorry for anticipating the next point
-[20:26:42] <tampakrap> if you are talking about a stable candidate, yes, 4.4.10 is fine
-[20:26:55] <jmbsvicetto> yes
-[20:27:20] <dilfridge> ok... following the logical order of things instead of the numerical one...
-[20:27:32] <dilfridge> 5) 4.6 status / stabilization / important bugs
-[20:27:48] <tampakrap> apart from the blockers list on the tracker, no idea
-[20:27:53] <scarabeus> major is that akonadi integration in basic pkgs
-[20:28:01] <scarabeus> and i guess that tracker catched everything
-[20:28:05] <tampakrap> we have 5 or 6 major blockers, i am aware of all of them
-[20:28:13] <tampakrap> what akonadi integration?
-[20:28:28] <jmbsvicetto> given the current status with upstream about 4.6, anyone sees any reason to delay getting 4.5.5 marked stable instead of keep waiting for a possible 4.6 stable candidate?
-[20:28:30] <tampakrap> the -semantic-desktop failure bug?
-[20:28:33] <scarabeus> yep
-[20:28:57] <tampakrap> 4.5.5 is completely broken
-[20:29:23] <dilfridge> general question: how many of you get akonadi errors on login?
-[20:29:40] <tampakrap> i don't
-[20:29:49] <tampakrap> and i use kdepim and kdepimlibs master
-[20:30:03] <jmbsvicetto> tbh, I never checked
-[20:30:33] <dilfridge> I always get and have not been able to solve that... maybe I should start collecting info...
-[20:30:37] <dilfridge> ok
-[20:30:44] <jmbsvicetto> I use what I was forced to use with 4.6.1 (having to enable semantic-desktp)
-[20:30:56] <dilfridge> let's have a quick look at the blockers
-[20:31:19] <tampakrap> three of them are about -semantic-desktop and -kdepimlibs support
-[20:31:28] <tampakrap> one is about kdepim 4.4.10 translations
-[20:31:34] <tampakrap> i don't remember the others
-[20:31:42] <dilfridge> Bug 353048
-[20:31:44] <willikins> dilfridge: https://bugs.gentoo.org/353048 "kdebase/kwin-4.6 USE=-opengl does not compile"; Gentoo Linux, KDE; NEW; sefi:kde
-[20:31:51] <tampakrap> this is fixed upstream
-[20:32:05] <tampakrap> and the fix may be in 4.6.2 if it is backported in 4.6 branch
-[20:32:34] <dilfridge> Bug 353726
-[20:32:35] <willikins> dilfridge: https://bugs.gentoo.org/353726 "kde-base/plasma-workspace-4.6.0 should not depend on kdepimlibs"; Gentoo Linux, KDE; REOP; ikandros:kde
-[20:32:41] <tampakrap> yeah i mentioned that
-[20:32:56] <tampakrap> i'm on it
-[20:33:16] <dilfridge> Bug 353730
-[20:33:19] <willikins> dilfridge: https://bugs.gentoo.org/353730 "kdeplasma-addons-4.6.0 USE=-semantic-desktop fails to build without akonadi/semantic-desktop"; Gentoo Linux, KDE; REOP; KeithBHarrison:kde
-[20:33:23] <dilfridge> this is probably related
-[20:33:25] <tampakrap> and that
-[20:33:41] <dilfridge> Bug 357545
-[20:33:43] <willikins> dilfridge: https://bugs.gentoo.org/357545 "kde-l10n-4.6.1 wants to overwrite kde-misc/konq-plugins-4.4.0-r1 files"; Gentoo Linux, KDE; NEW; panard:kde
-[20:33:53] <tampakrap> no idea, scarabeus^^
-[20:33:56] <dilfridge> that should HOPEFULLY be fixed with 4.6.2
-[20:34:02] <dilfridge> as it is pretty trivial
-[20:34:11] <scarabeus> tampakrap: i told you that they have to use konq-plugins-4.6.1
-[20:34:19] <scarabeus> tampakrap: if they do so no clashes
-[20:34:28] <tampakrap> ok, so we should adjust deps
-[20:34:33] <tampakrap> dilfridge: plz2fix
-[20:34:34] <dilfridge> they got the release of 4.6.1 completely screwed up there
-[20:34:50] <dilfridge> later
-[20:35:03] <dilfridge> Bug 357959
-[20:35:04] <tampakrap> no blocker, remove it from the list please
-[20:35:05] <willikins> https://bugs.gentoo.org/357959 "kde-base/nepomuk-4.6.1: nepomuk service stub crashes after update"; Gentoo Linux, KDE; NEW; dilfridge:kde
-[20:35:09] <tampakrap> or lower severity
-[20:35:30] <dilfridge> done
-[20:35:41] <tampakrap> your nepomuk bug, can't reproduce
-[20:35:42] <dilfridge> that one is pretty annoying but an upstream problem
-[20:35:46] <tampakrap> a user reported something
-[20:36:09] <dilfridge> yes but I dont think it is gentoo-only
-[20:36:18] <tampakrap> hey, upstream says it is fixed
-[20:36:32] <dilfridge> yes 462
-[20:36:34] <dilfridge> good
-[20:37:40] <dilfridge> Bug 359979
-[20:37:41] <willikins> dilfridge: https://bugs.gentoo.org/359979 "media-libs/xine-lib crash with MKV WebM"; Gentoo Linux, Applications; ASSI; rezbit.hex:media-video
-[20:37:44] <dilfridge> a bit obscure
-[20:37:47] <tampakrap> huh?
-[20:37:52] <tampakrap> vlc is default
-[20:37:55] <dilfridge> kde upstream says it's a xine-lib bug
-[20:38:10] <dilfridge> probably this should not be a blocker either
-[20:38:15] <scarabeus> oh guys
-[20:38:16] <jmbsvicetto> I think we should close all phonon-xine bugs as CANTFIX
-[20:38:23] <scarabeus> i would make phonon-gstreamer default
-[20:38:26] <scarabeus> not the vlc
-[20:38:28] <dilfridge> blocker removed
-[20:38:35] <scarabeus> i find bit stupind to demand videoplayer
-[20:38:36] <scarabeus> for that
-[20:38:41] <jmbsvicetto> not phonon-gstreamer, please
-[20:38:46] -*- dilfridge bangs on the table... open floor is later :)
-[20:39:03] <dilfridge> ok back to the actuall agenda
-[20:39:05] <jmbsvicetto> dilfridge: open floor is for people outside the team ;)
-[20:39:17] <scarabeus> jmbsvicetto: so you rather pull in the vlc?
-[20:39:18] <scarabeus> :)
-[20:39:29] <scarabeus> xine does not work
-[20:39:34] <ABCD> scarabeus: I think that's what upstream expects us to use as default
-[20:39:40] <dilfridge> so do we agree we should consider 462 as "potential stable candidate"?
-[20:39:43] <ABCD> (I'm not sure though)
-[20:39:45] <jmbsvicetto> scarabeus: if you consider webkit part of the environment, then you'll need a video player ;)
-[20:39:47] <scarabeus> i didnt see it yet
-[20:40:02] <scarabeus> jmbsvicetto: gstreamer can manage over phonon
-[20:40:07] <scarabeus> jmbsvicetto: and i use mplayer
-[20:40:11] <jmbsvicetto> I don't think we should see 462 as a stable candidate
-[20:40:19] <scarabeus> jmbsvicetto: well we have to
-[20:40:22] <scarabeus> one magic word
-[20:40:23] <scarabeus> HAL
-[20:40:29] <tampakrap> why not?
-[20:40:30] <dilfridge> :|
-[20:40:33] <alexxy> +1
-[20:40:39] <scarabeus> that releases will be broken forewer
-[20:40:39] <alexxy> hal should be dropped
-[20:40:45] <scarabeus> just take look on what upstream does :)
-[20:40:52] <jmbsvicetto> because I don't believe they'll be able to "not break" kdegraphics on this release
-[20:40:55] <scarabeus> so we just have to bite it and sadly release somehow
-[20:40:58] <ABCD> +1, unless upstream breaks 4.6.2 even worse
-[20:41:09] <jmbsvicetto> It's not about "stability" or it working, but about KDE being able to package the release
-[20:41:33] <alexxy> well 4.6.1 works pretty well
-[20:41:37] <dilfridge> yes but I expect that the kde git migration will take another century or so
-[20:41:46] <jmbsvicetto> alexxy: minus the semantic-desktop stuff ;)
-[20:41:47] <dilfridge> (while we dont even start...)
-[20:41:53] <alexxy> yeah
-[20:42:02] <ABCD> I don't expect it to *ever* be completely done -- see kde-wallpapers
-[20:42:02] <alexxy> also we still need kdepim stuff
-[20:42:06] <tampakrap> hey, infra is busy
-[20:42:38] <dilfridge> oook
-[20:42:39] <jmbsvicetto> tampakrap: My only issue with 4.6.2 is that I expect us to get a broken release (packaging wise). If the regressions about akonadi/pimlibs get fixed, I have no issue with it being marked stable
-[20:42:40] <alexxy> and they again doing something with git,kde.org and projects.kde.org
-[20:42:46] <tampakrap> i said already kdepim 4.4.10 is fine along 4.6, don't make me repeat it in caps
-[20:42:58] <jmbsvicetto> I still antecipate we may get some "angry" users, but there's little we can do about it
-[20:43:15] <dilfridge> we'll always get some angry users
-[20:43:18] <tampakrap> those are issues with the sponsors, even we have those kind of issues
-[20:43:21] <scarabeus> actualy now i see how childish i was when i look on the tiny issues with 4.5 ;P
-[20:43:21] <tampakrap> don't confuse things
-[20:43:24] <tampakrap> anyway
-[20:43:32] <tampakrap> we can talk about that again in three weeks
-[20:43:35] <scarabeus> i could've stabled some of that :)
-[20:43:48] <dilfridge> yes.
-[20:43:50] <scarabeus> nah i would give it 14 days for the stablebug if everything works
-[20:44:06] <scarabeus> we are behind schedule for that stuff for freedesktop stuff
-[20:44:14] <tampakrap> 3 weeks is 1 week after tagging, 2 weeks after release
-[20:44:20] <scarabeus> yep works
-[20:44:23] <dilfridge> well given that kde-462 will take another week or so, we can for sure have another meeting before the stablebug filing
-[20:44:38] <dilfridge> ok
-[20:44:42] <tampakrap> we are not behind if samuli is acting like a maniac about hal without proper documentation / announcements
-[20:44:49] <dilfridge> true
-[20:44:53] <jmbsvicetto> <+willikins> New bug: https://bugs.gentoo.org/?????? Marked KDE-4.6.2 stable (URGENT) - HAL needs to die
-[20:44:57] <jmbsvicetto> scarabeus: ^^ ? ;)
-[20:45:08] <dilfridge> DIE DIE DIE
-[20:45:09] <scarabeus> jmbsvicetto: something like that
-[20:45:19] <scarabeus> btw we can smash in solid4.6
-[20:45:19] <scarabeus> :D
-[20:45:25] <scarabeus> and pretend everything is perfect xD
-[20:45:37] <dilfridge> so
-[20:45:41] <dilfridge> now for the optional stuff
-[20:45:45] <jmbsvicetto> scarabeus: you mean solid-4.5?
-[20:45:46] <alexxy> also there can be another issue
-[20:45:55] <alexxy> because of nm-0.9 stuff
-[20:45:59] <dilfridge> nm?
-[20:46:05] <alexxy> networkmanager
-[20:46:07] <tampakrap> what about it?
-[20:46:09] <scarabeus> jmbsvicetto: nah, hal is out since 4.6 :) so we can stable just solid :P
-[20:46:11] <scarabeus> new api
-[20:46:14] <scarabeus> totaly different
-[20:46:18] <scarabeus> but it does not matter
-[20:46:23] <alexxy> current solid will not work with it at all
-[20:46:23] <scarabeus> since knetworkmanager is already working on it
-[20:46:27] <scarabeus> and it wont use solid at all
-[20:46:43] <tampakrap> ok
-[20:46:46] <alexxy> i know
-[20:46:52] <jmbsvicetto> scarabeus: right, so you want to kill solid-4.5 :P
-[20:46:57] <alexxy> and they working on solid backend for it
-[20:47:11] <scarabeus> jmbsvicetto: 4.4
-[20:47:11] <alexxy> better to kill kde < 4.6
-[20:47:19] <scarabeus> jmbsvicetto: we talk about stable :D
-[20:47:38] <jmbsvicetto> what alexxy said
-[20:48:37] <dilfridge> so, summary: need some stable kde-4.6 in the near future, as the pressure is rising(tm)
-[20:49:08] <dilfridge> next point
-[20:49:16] <dilfridge> 3) Shall we drop useflag kdeprefix to simplify code?
-[20:49:16] <dilfridge>    "The problem is that bindings are not prefixed, and a possible fix (proposed 
-[20:49:16] <dilfridge>     by reavertm) would be to slot sip. tampakrap said he'll work on this, and bring 
-[20:49:16] <dilfridge>     the topic back in next meeting."
-[20:49:39] <dilfridge> any news?
-[20:49:41] <tampakrap> can i get another month please?
-[20:49:45] <tampakrap> busy with gsoc proposal
-[20:49:49] <alexxy> does any of us use kdeprefix?
-[20:49:58] <tampakrap> i started using it
-[20:50:05] <dilfridge> you're the boss, but does anyone actually use it?
-[20:50:05] <tampakrap> but i'm still stuck on my 4.6
-[20:50:08] <alexxy> hmm
-[20:50:26] <tampakrap> it's masked i don't see why you want to drop it
-[20:50:33] <alexxy> for testing better to use VMs
-[20:50:34] <ABCD> if we drop kdeprefix, we can simplify a *lot* of things -- including slotmoving everything to :4
-[20:50:38] <alexxy> like lxc or xen
-[20:50:52] <tampakrap> no it isn't better
-[20:50:53] <dilfridge> and the eclasses will be much simpler
-[20:50:55] <ABCD> alexxy: or even just a chroot
-[20:50:59] <tampakrap> i will have to maintain to boxes then
-[20:51:11] <alexxy> its simple
-[20:51:20] <alexxy> share binary packages across them
-[20:51:23] <jmbsvicetto> My feeling for a long time is that kdeprefix also needs to die
-[20:51:30] <tampakrap> it's not simple
-[20:51:34] <alexxy> use KSM to save your memory
-[20:51:36] <alexxy> and so on
-[20:51:38] <tampakrap> different use flags different configurations
-[20:51:46] <tampakrap> it's not a resource problem
-[20:51:57] <tampakrap> it'a a pain in the neck having to maintain an extra box
-[20:52:05] <jmbsvicetto> wait, sorry, I mean kdeenablefinal, not kdeprefix
-[20:52:08] <alexxy> its not too hard
-[20:52:30] <jmbsvicetto> I liked kdeprefix, but as it needs upstream work and we can't get their collaboration, I no longer object to killing it
-[20:52:30] <tampakrap> ok, let me disagree
-[20:52:45] <tampakrap> anyway, i want that useflag but if you guys want we can go on a vote
-[20:52:59] -*- alexxy running many VM's @works to test new stuff (like experimental gromacs patches and so on)
-[20:53:02] -*- ABCD votes to kill it
-[20:53:09] -*- alexxy also
-[20:53:12] -*- dilfridge votes to kill it
-[20:53:57] -*- jmbsvicetto abstains
-[20:54:29] <dilfridge> I'd say since that is less than 50% of the team we dont change anything for now.
-[20:54:43] <scarabeus> make vote over ml so everyone state the opinion
-[20:55:10] <dilfridge> for now decision postponed again
-[20:55:17] <dilfridge> next point
-[20:55:26] <dilfridge> 4) Making +consolekit and +policikit on by default or removing the useflags as whole (non working stuff run-as is annoying)
-[20:55:26] <dilfridge>    "No consensus was reached, the topic will be continued in the gentoo-desktop mailing list."
-[20:55:26] <dilfridge>    Mailing list query resulted in two user voices for "default on but still configurable"
-[20:55:30] <ABCD> I have to leave now, as I have a meeting in ~1 hour that's ~55 minutes away
-[20:55:38] <tampakrap> cya
-[20:55:41] <dilfridge> cu
-[20:55:44] <tampakrap> about the flags, people want them
-[20:55:59] <tampakrap> additionally people want udev deps optional as well
-[20:56:00] <dilfridge> yes but do we want to maintain them?
-[20:56:22] <tampakrap> i still support the profile/kde and use.force solution
-[20:56:33] <ABCD> udev deps at least have to be removed with USE=prefix
-[20:56:39] <alexxy> tampakrap: udev and policykit optional deps needed to have kde on kernels other than linux
-[20:56:58] <ABCD> and prefix can't do udev/polkit/consolekit
-[20:57:14] <jmbsvicetto> I don't see a point for the kde profile, but I just use linux/amd64/10.0
-[20:57:25] <alexxy> *bsd/solaris/hurd cant have udev
-[20:57:44] <alexxy> polkit may still work
-[20:58:16] <tampakrap> dilfridge: are the above sufficient to you?
-[20:58:22] <dilfridge> anyway. are there any objections to making +consolekit and +policykit on by default in the ebuilds, and forcing them in the kde profile?
-[20:58:28] <alexxy> so if we will have udev deps unconditional we should drop prefix/*bsd and all non native linux stuff
-[20:58:48] <jmbsvicetto> dilfridge: I don't have an issue with IUSE defaults and don't use the kde profile
-[20:58:59] <tampakrap> yeah no objections
-[20:59:01] <alexxy> dilfridge: its good idea
-[20:59:07] <dilfridge> ok
-[20:59:13] <jmbsvicetto> alexxy: I'd prefer to maintain prefix compatiblity, if possible
-[20:59:25] <dilfridge> then we go with that I'd say
-[20:59:32] <dilfridge> last point
-[20:59:35] <dilfridge> open floor
-[20:59:53] <dilfridge> anything else to discuss?
-[20:59:56] <alexxy> also gentoo prefix can be used instead of kdeprefix =D
-[21:00:10] <alexxy> well
-[21:00:28] <dilfridge> alexxy: that is actually interesting... gentoo on gentoo :)))
-[21:00:28] <alexxy> we again have problems with arches like x86-fbsd ppc*
-[21:00:45] -*- alexxy uses prefix on rhel4 cluster
-[21:01:09] <jmbsvicetto> alexxy: ppc is still recovering from their lost boxes
-[21:01:13] <tampakrap> what problems?
-[21:01:26] <alexxy> unkeyworded deps as usual
-[21:01:30] <jmbsvicetto> I need to resume my discussion from council with arch teams
-[21:01:42] <tampakrap> oh
-[21:01:50] <dilfridge> yeah but xarthisius is pretty helpful and responsive
-[21:01:52] <tampakrap> that's their problem, not ours
-[21:02:28] <alexxy> last time i masked some use flags or whole kde release on arm ppc ppc64 and x86-fbsd
-[21:02:28] <dilfridge> it's mainly about giving a friendly poke if something is really needed I think
-[21:03:17] <dilfridge> I dont know nothing about x86-fbsd
-[21:03:46] <alexxy> i dont know anybody who is using it
-[21:03:48] <dilfridge> ok
-[21:04:00] <alexxy> but kde has ~x86-fbsd keywords
-[21:04:03] <jmbsvicetto> dilfridge: aballier
-[21:04:29] <dilfridge> yes but aballier afaik was only contact to a user somewhere
-[21:04:45] <alexxy> !bug 357403
-[21:04:46] <willikins> https://bugs.gentoo.org/357403 "[KDE] Please keyword kde-4.6 deps to unmask needed useflags"; Gentoo Linux, Ebuilds; NEW; alexxy:kde
-[21:05:04] <jmbsvicetto> dilfridge: he lost his bsd boxes
-[21:05:06] <alexxy> well i can setup x86-fbsd VM
-[21:05:14] <dilfridge> ok
-[21:05:46] <dilfridge> If I find time to reconfigure my home network I can do arm at some point
-[21:05:48] <alexxy> i may already have one
-[21:05:49] <tampakrap> http://choqok.gnufolks.org/2011/03/choqok-is-going-to-leave-kde-for-gnome/
-[21:05:52] <jmbsvicetto> he would like to resume his work on bsd
-[21:06:04] <alexxy> dilfridge: what arm board do you have?
-[21:06:11] <dilfridge> openrd
-[21:06:57] <dilfridge> so, summary: about keywords nothing really changed :]
-[21:07:06] <dilfridge> anything else?
-[21:07:21] <dilfridge> or shall we call it a day?
-[21:08:14] -*- dilfridge takes this as "no, and yes"
-[21:08:26] <dilfridge> I'll post the log
-[21:08:33] <dilfridge> could one of you please make the summary?
-[21:08:40] <tampakrap> i'll handle the summary
-[21:08:43] <dilfridge> ok cool
-[21:08:46] <tampakrap> tomorrow, i'm about to pass out
-[21:08:49] <dilfridge> :)
-[21:09:16] <dilfridge> cheers and thanks for being here :D
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110602.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110602.txt
deleted file mode 100644
index 19ab44d4b0..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110602.txt
+++ /dev/null
@@ -1,553 +0,0 @@
-<tampakrap> ok let's start
-<tampakrap> !herd kde
-<willikins> (kde) abcd, alexxy, dilfridge, jmbsvicetto, patrick, reavertm,
-spatz, tampakrap
-<tampakrap> roll call
-<dilfridge> 1
-<alexxy> 2
--*- dilfridge hears bonsaikitten munching in the distance
-<ABCD> 3
-<tampakrap>
-http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2011-05
-<tampakrap> agenda ^^
-<tampakrap> jmbsvicetto: here?
-<tampakrap> until he shows up, anyone familiar with the status of 4.7 so far?
-<dilfridge> nope
-<jmbsvicetto> here
-<jmbsvicetto> so, 4.6.80
-<tampakrap> can you give us a brief summary of the betas please?
--*- alexxy here
-<jmbsvicetto> I think I got most of kdebase, kde-utils, kde-graphics,
-kde-games and kde-network working
-<jmbsvicetto> alexxy then bumped the rest
-<jmbsvicetto> about the status of the upstream tree / tarballs:
-<alexxy> most problematic is kdebindings
-<jmbsvicetto> I think no package is working
-<jmbsvicetto> status of upstream tree / tarballs:
-<dilfridge> about kdebindings... I vaguely remember an e-mail longtime ago
-when kde-4.7 was started, where the new split was explained
-<tampakrap> i recall that too
-<jmbsvicetto> kdebase was split on 3 tarballs - kdebase, kde-runtime and
-kde-workspace
-<tampakrap> do you think we should rename our metas?
-<jmbsvicetto> the info is available in the readme.modularization of the
-tarball
-<dilfridge> http://old.nabble.com/kdebindings-split-td30617636.html
-<jmbsvicetto> http://paste.pocoo.org/show/399690/
-<jmbsvicetto> The question is will they stick to the names or not
-<jmbsvicetto> at this point I think they haven't made up their minds yet
-<tampakrap> but they have the repos ready
-<tampakrap> don't they follow their repo naming schema?
-<jmbsvicetto> alexxy: ^^
-<jmbsvicetto> I'm not sure they're doing it consistently
-<dilfridge> >:|
-<jmbsvicetto> for example, smoke (which I think is a single repo) was split
-into 3 tarballs
---> Skiarxon (~quassel@ppp091138207078.dsl.hol.gr) has joined #gentoo-meetings
-<jmbsvicetto> smokegen, smokeqt, smokekde
-<tampakrap> sec
-<dilfridge> like in the deptree
-<tampakrap> can i have a list of the bindings tarballs?
-<jmbsvicetto> I'm not sure as I didn't had the time to go after the repos. I
-based my work in the existing tarballs and on the live ebuilds - which were in
-very good shape!!!
-<tampakrap> i'd like to compare with the repos right now
-<jmbsvicetto> I can give you the tarballs names for them. I still think
-there's a missing krosspython, but after 3 emails I've yet to get a proper
-reply
-<tampakrap> i follow the list, yes
-<jmbsvicetto> so as I said: smokegen, smokeqt and smokekde
-<ABCD> jmbsvicetto: I'd hope the live ebuilds were in good shape -- I use them
-myself :)
-<tampakrap> here are the repos for referrence:
-https://projects.kde.org/projects/kde/kdebindings
-<tampakrap> smoke is consistent so far
--*- alexxy also use live =) but now gonna switch to betas
-<jmbsvicetto> perlqt, perlkde, qtruby, qyoto, korundum, kimono and pykde4
-<jmbsvicetto> tampakrap: ok, then the live ebuilds need to be updated as well
-<dilfridge> perl is consistent
-<jmbsvicetto> should we pkgmove smoke to smokegen, or just add a block on
-smokegen to smoke?
-<tampakrap> everything is checked
-<ABCD> block, because we're not changing :4.4 and :4.6, I'd think :)
-<jmbsvicetto> the tarballs are consistent to the names in the
-README.MODULARIZATION file
-<dilfridge> ruby is consistent
-<tampakrap> ABCD: only 4.7 is involved
-<tampakrap> dilfridge: everything is
-<tampakrap> :)
-<ABCD> tampakrap: pkgmove moves *every* version unconditionally
-<jmbsvicetto> so, to get kdebinding we need to start by spliting smoke. I
-wasn't sure if the live ebuild was ok or not, so I didn't start that
-<ABCD> (you *cannot* use a versioned atom in that spot)
-<tampakrap> so, we follow upstream's repos for kdebindings since the tarballs
-and repos, do we all agree?
-<dilfridge> yes
-<tampakrap> ABCD: correct, i got you wrong
-<ABCD> yes
-<jmbsvicetto> seems a good idea
-<dilfridge> and I'm for blocker, not move
-<alexxy> also seems we need something to do with kross* modules
-<jmbsvicetto> If no one beats me to it, I'll work on it this weekend
-<tampakrap> blocker is one way
-<tampakrap> alexxy: what about them? where are the tarballs? :)
-<jmbsvicetto> tampakrap: no tarball for krosspython
-<dilfridge> mia
-<alexxy> tampakrap: dunno =)
-<tampakrap> if you want, prepare the live ebuilds then
-<jmbsvicetto> tampakrap: the README mentions the pykde4 tarball, but it no
-longer includes any code
-<tampakrap> i believe they'll follow the repo names as the rest of the module
-<dilfridge> this is about the only really crucial piece of binding because of
-plasma...
-<tampakrap> jmbsvicetto: sorry?
-<tampakrap> where is the pykde4 code then?
-<jmbsvicetto> sorry, I'm mixing tarballs
-<tampakrap> ok, we're done with bindings
-<tampakrap> jmbsvicetto: give us the modules that are monolithic please
-<tampakrap> kdepim is one of them, what else?
-<jmbsvicetto> kdegames
-<alexxy> kdeutils
-<alexxy> kdenetwork
-<tampakrap> those haven't migrated yet correct?
-<jmbsvicetto> kdenetwork
-<alexxy> kdemultimedia
--*- tampakrap checks
-<alexxy> kdetoys
-<ABCD> kate (kinda), kde-baseapps, kde-runtime, kde-workspace,
-kdeaccessibility, kdeadmin, kdeartwork, kdegames, [kdelibs], kdemultimedia,
-kdenetwork, kdepim, kdeplasma-addons, kdesdk, kdetoys, kdeutils, kdewebdev
-<alexxy> kdesdk
-<tampakrap> kdegames, kdeutils, kdenetwork, knemultimedia, kdesdk are still in
-svn
-<jmbsvicetto> oh yeah, kate was also fun
-<tampakrap> also kdetoys, kdeaccessibility, kdeadmin, kdeartwork
-<jmbsvicetto> kate is now the name of the module, so I had to update the
-eclass as we hadn't "predicted" that case and the src_unpack was failing
-<tampakrap> so, i'd say let's keep them as they are
-<jmbsvicetto> kdelibs is something we need to watch out. There's some doubt
-whether it'll be split kdelibs and kdelibs-experimental
-<tampakrap> one by one please
-<tampakrap> don't mix them
-<tampakrap> kdelibs-experimental is not going to be a tarball
-<tampakrap> it is an experimental repo
-<jmbsvicetto> yes, but kdelibs-4.6.80 had a dep on libs from it. Dirk ended up
-"smashing" it all together in kdelibs-4.6.80
-<ABCD> ...one that's currently *required* by kdelibs proper
-<ABCD> yeah
-<tampakrap> which was a mistake
---> devurandom (~devu@unaffiliated/devurandom) has joined #gentoo-meetings
-<jmbsvicetto> there was a discussion in the ml whether that dep was a mistake
-or not. I don't recall the conclusion
-<tampakrap> so, about the ones that haven't migrated yet
-<tampakrap> anyone knows if this will be done during 4.7?
-<ABCD> it's likely
-<tampakrap> causing more mess?
-<ABCD> of course :)
-<tampakrap> we're fsck'd then
-<tampakrap> oh well
-<dilfridge> probably with kde-5.0 they'll move to mercurial...
-<tampakrap> anyway
-<tampakrap> lol
-<tampakrap> what about the kde-* ones? should we change our metas?
-<tampakrap> kde-baseapps kde-runtime kde-workspace
-<jmbsvicetto> What's the name of the repos?
-<ABCD> the same
-<tampakrap> personally i'd prefer sticking to the repos name
-<tampakrap> and tarballs name of course
-<jmbsvicetto> in that case it would make sense - unless they decide to rename
-it again
-<tampakrap> no they won't
-<jmbsvicetto> we could perhaps wait for next beta release, just to be sure ;)
-<tampakrap> sure
-<ABCD> of course, that means we'll have to check for `has_version
-kde-base/kdebase-runtime-meta || has_version kde-base/kde-runtime-meta`
-everywhere
-<tampakrap> i think we covered all the monolithic/not converted yet tarballs
-so far
-<tampakrap> yes
-<tampakrap> it is a major change
-<jmbsvicetto> at this point I don't think krosspython will be fixed on this
-release (Dirk already said a kdepim issue would have to wait for next release)
-<tampakrap> ok
-<tampakrap> so, what about kate?
-<jmbsvicetto> it should be working now
---> ni1s (~ni1s@1-1-4-36a.dre.sth.bostream.se) has joined #gentoo-meetings
-<tampakrap> do you also fix the 4.7 lives?
-<-- ni1s (~ni1s@1-1-4-36a.dre.sth.bostream.se) has left #gentoo-meetings
-<jmbsvicetto> I actually forgot to test it on my test box :\
-<jmbsvicetto> I started by touching 4.6.80. I think ABCD and alexxy applied
-the changes to 9999 now
-<jmbsvicetto> I don't know anything about 4.7.9999
-<ABCD> there is no 4.7.9999 yet
-<ABCD> because upstream hasn't branched
-<tampakrap> lol?
-<tampakrap> they tagged from master?
-<ABCD> yeah -- just like they usually do for the betas :)
-<tampakrap> ok that sucks
-<tampakrap> so, how's 9999 then?
-<dilfridge> alexxy probably knows best
-<ABCD> 9999 is fine -- I forward ported most of the -4.6.80 changes so that we
-can bump 4.6.85 (or whatever) from 9999 -- note that okular-4.6.85 will be
-coming from its own tarball, not the "monolithic" kdegraphics-4.6.*.tarball
-<ABCD> (or it should be -- they just finished that split)
-<tampakrap> great, thanks
-<dilfridge> speaking of kdegraphics
-<tampakrap> so, anything else on monolithiks/no migrated yet
-<alexxy> heh. also i think we can drop eclass foo from all :live tarballs
-<tampakrap> before proceeding to the splitted/migrated ones?
-<dilfridge> the kdegraphics libs are tagged from the same branch as the ones
-distributed with digikam
-<alexxy> since we now know how they will be packaged
-<jmbsvicetto> alexxy: the if blocks?
-<dilfridge> meaning with 4.7 the incompatibilities will go away
-<jmbsvicetto> sure, I already did it for 4.6.80 ebuilds
-<alexxy> yeah
-<alexxy> so we should do it for :live
-<jmbsvicetto> ABCD: did you push those changes to 9999?
-<ABCD> alexxy: already done -- 4.6.9999 keeps it, though
-<ABCD> jmbsvicetto: yeah
-<alexxy> also i'm going to make universal ebuild for kde-l10n (that should
-support :live and regular tarballs)
-<tampakrap> good
-<tampakrap> dilfridge: yours
-<dilfridge> ?
-<tampakrap> you were saying that kdegraphics...
-<ABCD> fyi, if/when slotting gets dropped, 4.x.9999 will become something like
-4.x.49.9999 to keep versions in order
-<dilfridge> the kdegraphics libs are tagged from the same branch as the ones
-distributed with digikam
-<dilfridge> so our problems with digikam will go away
-<tampakrap> cool
-<tampakrap> ABCD: what do you mean?
-<tampakrap> slotmove everything back to 0?
-<ABCD> tampakrap: yeah
-<tampakrap> are you crazy??
-<dilfridge> not 4?
-<jmbsvicetto> tampakrap: that would seem to be the goal of dropping the
-slotting
-<tampakrap> i don't see a reason to do that
-<dilfridge> i think it makes sense
-<ABCD> the main reason we had slots to begin with was +kdeprefix -- kdeprefix
-will be gone as of Monday next week
-<jmbsvicetto> dilfridge: if we want to drop kdeprefix, we should drop the
-slots
-<dilfridge> jmbsvicetto: yes that is what I mean
-<dilfridge> we should definitely drop the slots
-<tampakrap> yeah, but 4.x.49.9999 doesn't
-<ABCD> dilfridge: I don't know if we should use :0 or :4 :)
-<jmbsvicetto> 0 or 4 is all the same
-<tampakrap> and why are slot 4 so bad?
-<dilfridge> not when 5 comes along :)
-<-- devurandom (~devu@unaffiliated/devurandom) has left #gentoo-meetings
-<jmbsvicetto> then you admit to introduce kdeprefix later? :P
-<dilfridge> 4.x.49.9999 makes actually a lot of sense
-<ABCD> tampakrap: 4.x.11 < 4.x.49.9999 < 4.x.80 (4.{x+1} beta 1)
-<ABCD> 4.x.80 (4.{x+1} beta 1) < 4.x.9999, which means that portage would see
-it as a downgrade
-<tampakrap> what is the big problem with slot 4 anyway?
-<jmbsvicetto> yes, 4.x.49.9999 sounds good, even though we could argue that
-4.x.49 would be the same
-<tampakrap> i don't understand
-<dilfridge> jmbsvicetto: given the differences between kde-3 and kde-4, I
-would not rule anything out with kde-5
-<jmbsvicetto> tampakrap: I don't have a problem with slot 4. I'm just saying
-that have slot=4 or slot=0 is all the same for the PMs
-<ABCD> tampakrap: the idea is to get the versions in some sort of order, such
-that 4.x.y, where y < 50 is KDE 4.x, and 4.x.y where y > 50 is KDE 4.{x+1}
-<jmbsvicetto> ABCD: I agree, but as I said, 4.x.49 would be as good as
-4.x.49.9999
-<jmbsvicetto> there should never be any 4.x.49 release - or they'll have to
-modify their release numbers ;)
-<dilfridge> except at some point maybe someone will introduce a 9999-magic in
-portage...
-<ABCD> jmbsvicetto: 4.x.49.9999 makes it a bit more obvious that it's live
-(and I think at least one PM assumes that it can't be a live ebuild if it
-doesn't have "9999" in the version)
-<jmbsvicetto> and the 9999 use is a "design" option, not a requirement
-<dilfridge> repoman does that similarly
-<jmbsvicetto> PMS doesn't acknowledge 9999 as special, afaik
-<jmbsvicetto> repoman is based on eclass inheritance, iirc
-<ABCD> I think paludis does (I remember hearing something about that)
-<ABCD> I know portage uses inherit() to determine what "live" is
-<jmbsvicetto> in any case I don't have anything against 4.x.49.9999
-<tampakrap> ok
-<tampakrap> i must admit i still don't understand
-<jmbsvicetto> I just fell 4.x.49 is smaller and if it works as well (which I
-think it should) we may want to use that
-<tampakrap> but since the rest of the team does, i step aside
-<ABCD> tampakrap: what part don't you understand?
-<jmbsvicetto> tampakrap: what don't you understand? The ordering?
-<tampakrap> 1) why slotmove a million ebuilds to 0 again 2) what is 49?
-<ABCD> tampakrap: why slotmove? it makes upgrading *much* easier (no more
-nasty blockers)
-<alexxy> well i think we still should have slots =)
-<dilfridge> please no slots anymore
-<alexxy> ok
-<dilfridge> it makes life so much simpler and without kdeprefix there is no
-real reason for it
-<alexxy> there will be kde5 next year
-<tampakrap> not sure
-<alexxy> so we should have at least one slot
-<jmbsvicetto> tampakrap: as we're dropping kdeprefix, there won't be any more
-reason to have different slots for each version
-<dilfridge> yes, that's ok
-<dilfridge> I'd go for "move everything to 4"
-<tampakrap> +1
-<ABCD> 2) what is 49? It's less than 50, which is the arbitrary cutoff used to
-determine if 4.x.y is part of KDE SC 4.x or KDE SC 4.{x+1}
-<jmbsvicetto> tampakrap: and if we put all packages in the same slot, we can
-simplify the eclasses
-<tampakrap> ok
-<jmbsvicetto> about slot=0 or slot=4, that is something that only has meaning
-to humans, not to the PM
-<tampakrap> put everything to 4 then?
-<tampakrap> quick vote
-<tampakrap> 0 or 4
-<jmbsvicetto> whatever slot you want to use
-<alexxy> +1 for :4  slot
-<dilfridge> 4
-<tampakrap> 4
--*- ABCD doesn't care
-<jmbsvicetto> I can live with both. 0 would be more "accurate" if we don't
-want to have kdeprefix anymore, 4 otherwise
-<tampakrap> i don't intend to slotmove all the kde-misc ebuilds again
-<jmbsvicetto> by dropping slots, we need to update all deps to use versions
-and not slots
-<ABCD> and we won't have kdeprefix (the actual flag might live for a short
-while longer, but if it does, it will just be to do pkg_setup() { use
-kdeprefix && die ....; ....; })
-<ABCD> jmbsvicetto: they already do -- except when USE=kdeprefix
-<tampakrap> ABCD: about 49, since 4.x.80 are 4.x+1, why not just use this?
-<tampakrap> and deal with an extra number?
--*- ABCD isn't sure what you're trying to say, tampakrap
-<jmbsvicetto> tampakrap: the idea is that the first release KDE will ever do
-of a new version is 4.x.50
-<jmbsvicetto> that's what they've written in their release "rules"
-<tampakrap> yes, but the tarballs are shown after 4.x.80
-<tampakrap> before that there is only live ebuilds
-<jmbsvicetto> sure, but since 4.x.50 is a new version, 4.x.49 should be used
-as the last version of a version
-<ABCD> tampakrap: they've released tarballs for alphas before, with lower
-numbers
-<tampakrap> they won't anymore though
-<jmbsvicetto> bah, terrible language :\
-<tampakrap> they said that interested parties can get the tarballs from
-redmine or gitweb
-<jmbsvicetto> tampakrap: why take the chance?
-<tampakrap> i don't think there is a chance here but anyway
-<tampakrap> 49 it is
-<jmbsvicetto> tampakrap: 4.x.50 should never be used for version 4.x -
-recently the most they've been getting is 4.x.7 anyway, right?
-<tampakrap> true
-<tampakrap> anyway, i think we all agree here
-<ABCD> and 49 is just an arbitrary number that is definitely between the last
-4.x release but before the first 4.{x+1} release (and I've hardcoded the
-4.x.50 assumption in other places)
-<tampakrap> ok
-<tampakrap> next
-<dilfridge> the "50 limit" is already in the eclass
-<tampakrap> jmbsvicetto / alexxy status of migrated/ split modules?
-<ABCD> yeah
-<tampakrap> do we follow upstream there? should we?
-<jmbsvicetto> besides the missing krosspython, everything else should be
-working
-<jmbsvicetto> I think we should
-<jmbsvicetto> (follow upstream)
-<alexxy> actualy most of migrated and splited modules has same spliting as we
-do
-<jmbsvicetto> on 4.6.80 we're already doing it
-<tampakrap> one by one
-<tampakrap> kde edu, check?
-<tampakrap> https://projects.kde.org/projects/kde
-<ABCD> kdeedu we are 100% following upstream
-<tampakrap> kde graphics, check?
-<jmbsvicetto> the split on our end is complete
-<jmbsvicetto> for both
-<tampakrap> kde base
-<ABCD> kdegraphics, they didn't finish splitting in time for 4.6.80, but
-should be done for 4.6.85
-<ABCD> (we might want to package the new mobipocket repo, though -- I'll look
-into that)
-<tampakrap> kdebase is consisted of three monolithic and two split repos as i
-see
-<tampakrap> so we're fine here
-- {Day changed to Fri Jun 3 00:00:00 2011}
-<ABCD> plus one more (kinda) monolithic repo: kate :D
-<ABCD> kwrite moved from kde-baseapps to kate
-<tampakrap> kdepim/kdepim-runtime is monolithic, check
-<tampakrap> yeah
-<tampakrap> how are we on that area?
-<alexxy> tampakrap: they may split it
-<tampakrap> kate/kwrite i mean
-<tampakrap> kdepim is NOT going to get split
-<tampakrap> and nothing that migrated is going to change
-<tampakrap> kdepimlibs/kdelibs are monolithic on both sides
-<tampakrap> last question:
-<tampakrap> is the bump ready from our side?
-<tampakrap> should i announce it? update docs?
-<dilfridge> bump of what?
-<tampakrap> 4.6.80
-<tampakrap> in general
-<jmbsvicetto> tampakrap: we should run more tests and still need to fix some
-stuff
-<alexxy> tampakrap: its NOT ready
-<tampakrap> what's missing please?
-<ABCD> tampakrap: upstream to release a kross-interpreters tarball :D
-<tampakrap> if you speak now you may get more help :P
-<tampakrap> yeah, apart from that :)
-<alexxy> kdebindings
-<alexxy> =)
-<jmbsvicetto> kdebase + kdegraphics + kdemultimedia + kdenetwork + kdeedu +
-kdegames + kdetoys + (most of) kdeutils, should work
-<jmbsvicetto> afaik kdebindings is broken. I don't know kdepim status
-<ABCD> assuming that you disable anything that needs krosspython (pykde4
-probably should work, I would think)
-<tampakrap> ok, so i suppose i should not recommend people to update to it at
-all
-<jmbsvicetto> pykde4 build on my test system. I haven't tested it though
-<alexxy> jmbsvicetto: kdepim should work
-<jmbsvicetto> not at this stage
-<jmbsvicetto> I'd wait for a krosspython release (probably next beta)
-<tampakrap> ok, so what's needed from our side?
-<jmbsvicetto> tampakrap: for the above list, I can say my testing system is
-running. I'm not using too many kde apps on it though
-<jmbsvicetto> I'm using it mostly as a build box, some browsing (FF), kwrite,
-kopete and general DE use
-<tampakrap> cool
-<tampakrap> thank you guys for handling it
-<tampakrap> good job
-<jmbsvicetto> I haen't tested the games or kdeedu apps yet
-<tampakrap> i don't have to say anything else on 4.7, if anyone has to say
-something speak now
-<jmbsvicetto> sorry for the commit noise, but I'm a "old grumpy" dev ;)
-<tampakrap> we'll kick your ass later
-<tampakrap> dilfridge: next topics are yours
-<dilfridge> ho hum
-<tampakrap> use flag defaults for kde subprofile (bug 365251)
-<willikins> tampakrap: https://bugs.gentoo.org/365251 "Use flag defaults for
-the desktop/kde profile"; Gentoo Linux, KDE; CONF; dilfridge:kde
-<dilfridge> ok... all that I listed were (as far as I remember) not in the
-desktop profile
-<dilfridge> maybe we just go quickly through use-flags and vote whether they
-should be enabled in the kde profile (NOT forced of course)
-<dilfridge> 1) cups - I think this is a clear usability improvement
-<tampakrap> isn't the system-config printer broken?
-<tampakrap> and hardmasked?
-<dilfridge> eww
-<dilfridge> possibly
-<jmbsvicetto> as I stated when the kde profile was created, I don't like the
-idea too much, but as I don't use it, I don't care
-<tampakrap> cups: no
-<dilfridge> we'll come back to that topic later ("open floor")
-<dilfridge> ok
-<dilfridge> 2) dri, xcomposite, xinerama
-<tampakrap> +1
-<dilfridge> since kwin heavily relies on all that stuff
-<dilfridge> 3) -gnome
-<tampakrap> no
-<dilfridge> this is to avoid problems like the recent glib-networking desaster
-<ABCD> don't need it -- I don't think desktop/ sets +gnome anyway :)
-<dilfridge> ok then not
-<tampakrap> true
-<dilfridge> 4) nsplugin
-<dilfridge> since konqueror provides a plugin container
-<tampakrap> no opinion
-<dilfridge> no strong opinion here either, so maybe lets forget about it
-<dilfridge> 5) semantic-desktop :)
-<tampakrap> yes!
-<dilfridge> as it is needed by kdepim
-<dilfridge> 6) xscreensaver
-<dilfridge> to provide more eyecandy
-<tampakrap> +1
-<alexxy> opengl
-<alexxy> gles
-<ABCD> -1 on gles, I think
-<ABCD> (unless I'm mistaken)
-<tampakrap> opengl +1, gles -1
-<ABCD> as I thought that gles was primarily for embedded, or something like
-that
-<ABCD> but +1 on opengl
-<alexxy> kwin will work with it better then with opengl
-<dilfridge> opengl is already in desktop
-<ABCD> there we go :)
-<alexxy> if you use gallium drivers
-<tampakrap> that's not a reason to force it in every kde user
-<dilfridge> ok that's it for me on this topic, I summarize:
-<ABCD> these are defaults, not forced :)
-<dilfridge> we add the following flags to the default use flags in the kde
-subprofile:
-<tampakrap> wait i want more
-<dilfridge> ok
-<tampakrap> qt, qt4
-<dilfridge> qt4 is in desktop
-<tampakrap> qt?
-<dilfridge> not
-<tampakrap> qt is old apparently
-<tampakrap> declarative
-<dilfridge> yes
-<tampakrap> kipi
-<dilfridge> yes
-<tampakrap> phonon?
-<tampakrap> is that enabled already?
-<dilfridge> no
-<dilfridge> we should add it
-<tampakrap> ok
-<tampakrap> and qt3support?
-<tampakrap> is this being dropped by upstream?
-<dilfridge> in desktop
-<tampakrap> i know
-<tampakrap> if it's being dropped of 4.7 we should consider dropping it from
-desktop
-<dilfridge> good question, I know they are working in that direction
-<tampakrap> ah and plasma
-<tampakrap> is that enabled?
-<dilfridge> no, I'll add it to the list. qt3support maybe worth a mail to the
-releaseteam
-<tampakrap> ok
-<tampakrap> that's all
-<dilfridge> "declarative dri kipi phonon plasma semantic-desktop xcomposite
-xinerama xscreensaver"
-<dilfridge> ^ any further comments?
-<dilfridge> ok then with your ok I'll add this later to the profile
-<tampakrap> no, i want to announce it first
-<dilfridge> ah ok
-<dilfridge> fine
-<tampakrap> anything else?
-<dilfridge> next topic would be kdeprefix status
-<tampakrap> we already discussed it i suppose
-<dilfridge> yes
-<dilfridge> ok next...
-<dilfridge> kde-4.6.3
-<tampakrap> should be fine, i don't see bugs :)
-<dilfridge> I would like to file a stablereq in a week or so (30days etc),
-just so stable keeps up
-<tampakrap> bug reports that is
-<dilfridge> ok... if there are any problems or if you have any objections,
-talk to me please :)
-<tampakrap> that's all?
-<dilfridge> from the agenda, yes
-<tampakrap> *) open floor
-<dilfridge> open floor- one point from me
-<tampakrap> shoot
-<dilfridge> i was kind of crazy enough to mail tgurr about cups-1.4
-stabilization
-<dilfridge> basically I can go ahead sorting the remaining bugs etc
-<dilfridge> this may take some time, but at some point I hope we'll have some
-news there
-<dilfridge> that's all
-<tampakrap> ok
-<tampakrap> and one point from me:
-<tampakrap> we lost scarabeus, we need new people
-<tampakrap> i mean, what comes next? losing jmbsvicetto?
--*- jmbsvicetto slips away
-<dilfridge> we should all move on to qa and recruit diego for kde :D
-<tampakrap> actually, he was a kde guy long ago
-<dilfridge> did not know that
-<jmbsvicetto> tampakrap: all I can say about that is that I'm trying to use my
-council hat to ensure we fix the issues that affected Tomas motivation
-<jmbsvicetto> Diego and Dan Armak started kde on Gentoo, I think
-<jmbsvicetto> if not, they maintained kde on gentoo for many years
-<tampakrap> we need scarabeus and ssuominen back
-<jmbsvicetto> at this point and unless people change, that seems unlikely
-<tampakrap> btw, meeting closed, thanks for coming
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110831.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110831.txt
deleted file mode 100644
index b935c55677..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110831.txt
+++ /dev/null
@@ -1,479 +0,0 @@
-[00:13:23] <tampakrap> !herd kde
-[00:13:23] <willikins> (kde) abcd, alexxy, dilfridge, jmbsvicetto, mschiff, patrick, reavertm, spatz, tampakrap, thev00d00
-[00:13:28] <tampakrap> meeting start
-[00:13:32] <tampakrap> First topic: KDE 4.7.0 stabilization (without kdepim)
-[00:13:43] <jmbsvicetto> +1
-[00:13:45] <dilfridge> +1
-[00:13:45] <tampakrap> dilfridge: reason to do so? we usually stabilize after the .0 release
-[00:13:50] <dilfridge> no bugs
-[00:13:57] <tampakrap> fyi i object, i have plenty
-[00:14:04] <dilfridge> the upgrade went perfectly smooth here
-[00:14:34] <dilfridge> and there are also no significand new things on bugzi
-[00:14:35] <jmbsvicetto> tampakrap: I haven't hit any more bugs than usual
-[00:14:39] <mschiff> but bugs is a general problem of kde not only 4.7.0, I am running 4.7.49.9999 here
-[00:14:42] <tampakrap> fwiw kdepim works fine here as well, why don't we stabilize this one as well?
-[00:14:53] <dilfridge> maybe with .2 `
-[00:14:55] <dilfridge> ?
-[00:15:09] <jmbsvicetto> I'll leave kdepim for those of you that actually use it :P
-[00:15:18] <dilfridge> i use kdepim-4.4
-[00:15:28] <tampakrap> kdepim 4.4 is obsolete, no bugfixes, no security updates
-[00:15:29] <mschiff> kdepim is special: I think there the newest version is better these days
-[00:15:35] <tampakrap> can't we keep them both and just notify users?
-[00:15:39] <dilfridge> sure
-[00:15:40] <tampakrap> and let them decide on what they want
-[00:15:41] <mschiff> (speaking of the *2 versions)
-[00:15:56] <tampakrap> but i still object on stabilizing .0, i have some plasma regressions
-[00:16:04] <dilfridge> like?
-[00:16:08] <tampakrap> and of course we don't get such bugs, since they are upstream
-[00:16:17] <tampakrap> i have problem on focus
-[00:16:17] <mschiff> I  guess .1 is not far away right?
-[00:16:24] <dilfridge> has there ever been a version without plasma regressions?
-[00:16:31] <tampakrap> another i have is that taskbar entries are not highlighted correctly
-[00:16:32] <dilfridge> tagging tomorrow, technically
-[00:16:44] <Thev00d00> release sept 6 isnt it?
-[00:16:50] <mschiff> I have som eprobs here too: a windows that had a notify, tends to keep that status in the window bar
-[00:17:04] <j0hu> but maybe messed up because of 2 migratet categories
-[00:17:22] <dilfridge> ok
-[00:17:26] <dilfridge> so 
-[00:17:29] <Thev00d00> mschiff: I have the same, sticky red quassel for example
-[00:17:39] <dilfridge> consensus seems to be more, stabilize 4.7.1
-[00:17:41] <tampakrap> my opinion is to stabilize .1 (after a meeting decision) WITH kdepim
-[00:17:46] <mschiff> Thev00d00: exactly, I think its what tampakrap also meant
-[00:17:52] <tampakrap> but let the users know first
-[00:17:59] <tampakrap> document everything etc
-[00:18:08] <dilfridge> news item maybe
-[00:18:08] <tampakrap> maybe even put a news item out as well
-[00:18:20] <dilfridge> ok fine with me
-[00:18:29] <alexxy> +1 for .1 with pim
-[00:18:38] <dilfridge> anyone else?
-[00:18:53] <mschiff> But 4.4 should stay in tree for some time
-[00:18:58] <dilfridge> yes
-[00:19:07] <dilfridge> I'll take care of it as good as possible
-[00:19:15] <Thev00d00> +1 for .1
-[00:19:24] <dilfridge> ok
-[00:19:32] <dilfridge> then
-[00:19:34] <tampakrap> ok, prepare a news item, and take care of the documentation then, and after next month's meeting we'll decide on 4.7.1
-[00:19:48] <tampakrap> anything else?
-[00:20:05] <mschiff> so not stabilize .1 as its available?
-[00:20:11] <dilfridge> next topic then
-[00:20:28] <tampakrap> no, after meeting
-[00:20:36] <jmbsvicetto> tampakrap: I'd try to decide the stabilization by email
-[00:20:53] <tampakrap> no problem
-[00:20:54] <dilfridge> mschiff: at earliest 30days after release, so we have lots of time
-[00:21:02] <tampakrap> anyway, next topic
-[00:21:06] <tampakrap> 2) Road towards KDE 5 - what news is there from the Desktop Summit?
-[00:21:16] <tampakrap> who was at the Desktop Summit?
-[00:21:20] <tampakrap> ah that was me!!
-[00:21:21] <dilfridge> you
-[00:21:44] <tampakrap> so, i learned there that Qt 4.8 is NOT going to be split
-[00:21:51] <tampakrap> Qt 5 will
-[00:21:58] <dilfridge> into what?
-[00:22:03] <tampakrap> and we have plenty of time to worry about KDE 5
-[00:22:09] <alexxy> into small parts
-[00:22:10] <alexxy> =)
-[00:22:14] <alexxy> even atoms
-[00:22:22] <tampakrap> even Thiago didn't tell me details
-[00:22:26] <dilfridge> oh dear, radiation alert
-[00:22:29] <bonsaikitten> I'd *really* like split tarballs
-[00:22:36] <alexxy> tampakrap: is there any eta for kde5?
-[00:22:39] <bonsaikitten> a 200M download when you need 10M is a bit sad
-[00:22:46] <alexxy> about a year or so?
-[00:22:51] <tampakrap> not yet, but we have plenty of time
-[00:22:52] <j0hu> work started in kdelibs
-[00:23:00] <j0hu> framework branch
-[00:23:07] <tampakrap> and they won't do big changes like the 3->4 transition
-[00:23:41] <tampakrap> that's what some core KDE developers (like Aaron Seigo and David Faure) said in their presentation
-[00:23:59] <dilfridge> will there be a kde 4.8?
-[00:24:03] <tampakrap> yes
-[00:24:11] <jmbsvicetto> but Alex has been talking about using the bump to get some ABI incompatible changes
-[00:24:31] <alexxy> also seems something is going to happen with nepomuk
-[00:24:33] <jmbsvicetto> that has been mentioned multiple times in the release ml
-[00:24:37] <tampakrap> that was the plan, it changed somewhere in the middle
-[00:24:45] <dilfridge> hmm
-[00:24:52] <tampakrap> unless you are talking about something else
-[00:25:15] <dilfridge> I heard some rumour about kdelibs basically remaining at 4.7?
-[00:25:46] <tampakrap> i also took part in a release team BoF along with Slackware, Fedora, openSUSE packagers and a GNOME release team guy
-[00:25:58] <tampakrap> chaired by Sebastian Krugler and Dirk Muller
-[00:25:59] <jmbsvicetto> Alex also worked on getting all KDE cmake files that were ok for kitware into 4.8.0 (?) and created the new cmake-extras packages
-[00:26:02] <jmbsvicetto> package*
-[00:26:20] <tampakrap> they talked about the splitting of modules, how to handle it and about future KDE releases
-[00:26:28] <jmbsvicetto> dilfridge: They've been saying there won't be a kdelibs-4.8
-[00:26:36] <dilfridge> ok
-[00:26:41] <tampakrap> so nothing big is expected
-[00:27:04] <tampakrap> are you talking about the superbuild package?
-[00:27:20] <jmbsvicetto> No, that was their "reply" to slackware
-[00:27:46] <tampakrap> no idea what you're talking about then
-[00:27:57] <tampakrap> afaik there will be kdelibs 4.8 and KDE SC 4.8
-[00:27:59] <jmbsvicetto> The cmake-extras package is a package that Alex has "sponsored" to have all cmake files that can't be accepted into cmake by kitware
-[00:28:09] <tampakrap> ah yes
-[00:28:13] <tampakrap> i recall now
-[00:28:18] <jmbsvicetto> tampakrap: that's not what has been talked in the kde relase ml
-[00:28:21] <tampakrap> what does have to do with us?
-[00:28:21] <dilfridge> Alex ?
-[00:28:33] <jmbsvicetto> but I haven't talked to anyone about this nor was I at the Desktop summit :P
-[00:28:33] <tampakrap> Alexander Neundorf, main buildsystem guy
-[00:28:35] <dilfridge> ah
-[00:28:50] <tampakrap> i follow the kde release team, never saw such thing :/
-[00:29:15] <jmbsvicetto> tampakrap: What I'm saying is that they've talked about doing incompatible changes. I hear from you that is not what they're going to do
-[00:29:36] <tampakrap> they were, but things changed in Qt, thus in KDE
-[00:29:42] <tampakrap> that's what i know so far
-[00:30:13] <jmbsvicetto> but they had also decided on not having KDE/<version> branches and just <version> branches and now in the kde-scm ml they're almost reverting that because of the talks other KDE devs had on kde-core-devel that appearantly didn't follow the kde-release or kde-scm mls
-[00:30:27] <jmbsvicetto> tampakrap: ok
-[00:30:49] <tampakrap> anyway
-[00:31:03] <tampakrap> if big changes are going to come we'll know them in time
-[00:31:07] <tampakrap> we always did
-[00:31:08] <dilfridge> true
-[00:31:44] <tampakrap> https://plus.google.com/photos/116381667574498856310/albums/5637225108859383905 <-- and here are the photos for those who haven't seen them, to make you jealous
-[00:31:50] <dilfridge> :D
-[00:31:59] <tampakrap> anything else here?
-[00:32:12] <dilfridge> not from me
-[00:32:29] <jmbsvicetto> or me
-[00:32:57] <dilfridge> ok
-[00:32:57] <tampakrap> 3) The NetworkManager-0.9 mess
-[00:33:03] <dilfridge> hehe
-[00:33:05] <tampakrap> no idea here
-[00:33:09] <dilfridge> the basic summary is
-[00:33:23] <dilfridge> A gnome-3 requires networkmanager-0.9
-[00:33:37] <dilfridge> B kde does not support networkmanager-0.9
-[00:33:52] <dilfridge> A seems to be set in stone
-[00:33:57] <alexxy> dilfridge: knetworkmanager works fine with nm09
-[00:34:04] <dilfridge> B is being worked on
-[00:34:07] <dilfridge> yes
-[00:34:14] <alexxy> and i use this combination on my laptop
-[00:34:16] <jmbsvicetto> dilfridge: wasn't the delay on solid?
-[00:34:27] <alexxy> also in git master of kdelibs there is a stub for nm09
-[00:34:33] <alexxy> for solid
-[00:34:38] <dilfridge> what alexxy is using and what we have in the tree now is the nm09 branch
-[00:34:38] <jmbsvicetto> I don't use knetworkmanager, nor networkmanager, so I don't know anything about it
-[00:35:00] <dilfridge> that is basically sponsored by fedora, as they have the same problem
-[00:35:04] <dilfridge> and it seems to work ok
-[00:35:13] <alexxy> it mostly works
-[00:35:16] <alexxy> excetp wimax
-[00:35:17] <alexxy> =)
-[00:35:34] <alexxy> so my cell modem and wifi + vpn works fine
-[00:35:43] <tampakrap> didn't someone put a masked knetworkmanager 0.9 compatible in tree?
-[00:35:46] <dilfridge> the only problem with it is that the knetworkmanager developers do not really support it but have different plans (or lack of motivation)
-[00:35:52] <dilfridge> tampakrap: yes me
-[00:36:04] <dilfridge> basically it is a fedora-fork
-[00:36:09] <alexxy> dilfridge: no
-[00:36:15] <alexxy> its different approcah
-[00:36:30] <alexxy> fedora has patched nm09 with nm08 compatibility layer
-[00:36:41] <dilfridge> nm or knm?
-[00:36:46] <alexxy> nm
-[00:36:52] <tampakrap> knetworkmanager developers were in summit, why didn't you tell me earlier to talk to them? :/
-[00:36:53] <dilfridge> strange
-[00:36:59] <dilfridge> anyway
-[00:37:01] <alexxy> and its own patched version of knm
-[00:37:21] <mschiff> oh dear :-/
-[00:37:21] <dilfridge> probably the best thing is to just stick to the nm09 branch
-[00:37:23] <alexxy> there 3 impletation of nm09 support in knm
-[00:37:34] <alexxy> first one is fedora
-[00:37:45] <alexxy> second nm09 branch from knm devs
-[00:37:52] <alexxy> and third libqtnm
-[00:38:00] <alexxy> that is worked on
-[00:38:08] <alexxy> we use second one
-[00:38:15] <alexxy> since its only working
-[00:38:15] <tampakrap> what's libqtnm?
-[00:38:34] <alexxy> i dont remember how its called correctly
-[00:38:40] <tampakrap> anyway
-[00:38:45] <alexxy> but they want to create qt lib fro nm
-[00:38:45] <dilfridge> alexxy: shall we continue using nm09 branch, what do you think?
-[00:38:45] <tampakrap> since it works, and it is in tree
-[00:38:49] <tampakrap> what is the problem?
-[00:39:02] <dilfridge> tampakrap: there is no real problem
-[00:39:08] <alexxy> dilfridge: i think that it will be best chois at this time
-[00:39:25] <dilfridge> the purpose was only to make people aware that this may become problem at some time
-[00:39:34] <dilfridge> but right now I agree with alexxy
-[00:39:42] <tampakrap> summarize the problem please, i'm confused
-[00:39:59] <alexxy> dilfridge: there will be no problems with migration
-[00:40:09] <alexxy> since nm settings are stored by nm
-[00:40:10] <dilfridge> chaotic situation, many different approaches, no clear upstream
-[00:40:15] <alexxy> and not by applet
-[00:40:47] <dilfridge> alexxy: ok
-[00:40:53] <dilfridge> so summary: no problem
-[00:40:57] <dilfridge> :D
-[00:40:57] <tampakrap> but we have something that works at the moment, so let's just wait for upstream to fix their mess
-[00:41:13] <dilfridge> ok 
-[00:41:16] <dilfridge> next point?
-[00:41:18] <tampakrap> next issue
-[00:41:31] <dilfridge> meh it's me again
-[00:41:34] <tampakrap> 4) Does anyone still have an overview of the glib-networking/libproxy problem?
-[00:42:05] <dilfridge> pacho was quite insistent that we have a look at this
-[00:42:15] <dilfridge> because it blocks a big fat sec bug
-[00:42:58] <tampakrap> i don't use that app at all
-[00:43:49] <dilfridge> it's pulled in eg by firefox
-[00:44:15] <dilfridge> I went through the >100 comments and tried to make sense of it yesterday
-[00:44:20] <jmbsvicetto> dilfridge: I can't help as I don't use it as well
-[00:44:30] <dilfridge> I never had the problem myself either
-[00:44:34] <tampakrap> which flag in firefox?
-[00:44:45] <dilfridge> dont remember sorry
-[00:44:57] <tampakrap> a guy put a summary there did you look at it?
-[00:45:14] <dilfridge> yes, me :]... I *believe* the problem is fixed
-[00:45:22] <dilfridge> but believing = not knowing
-[00:45:31] <dilfridge> does anyone else know anything?
-[00:45:54] <mschiff> I do not have it installed
-[00:45:58] <dilfridge> I recommend the gnome guys just go ahead...
-[00:46:04] <tampakrap> any dupes? any activity in the bug?
-[00:46:21] <dilfridge> not anymore for a while (that's why I think it's ok now)
-[00:46:42] <tampakrap> go on then
-[00:46:56] <dilfridge> ok I'll tell them to just go ahead
-[00:47:08] <tampakrap> next topic
-[00:47:21] <tampakrap> 5) Suggestion - splitting the Gentoo KDE Guide into two pages
-[00:47:21] <tampakrap> 1) main page: main tree, stable and ~arch things only
-[00:47:21] <tampakrap> 2) poweruser page: overlay, live ebuilds, sets, kde-sunset
-[00:47:31] <tampakrap> who added this topic?
-[00:47:33] <dilfridge> my suggestion 
-[00:47:38] <dilfridge> and I'd be willing to do it
-[00:47:45] <dilfridge> but only if you think it's good
-[00:47:47] <tampakrap> that's a no :)
-[00:48:02] <tampakrap> from the very beginning i wanted that guide to be monolithic
-[00:48:14] <tampakrap> else there will be a lot of duplication
-[00:48:40] <tampakrap> plus readers will be able to jump from one topic to another (eg see the existence of the overlay quickly, and maybe prefer the live ebuilds or snapshots)
-[00:49:01] <tampakrap> there are tags there as well, append #kde4_6 and similar
-[00:49:02] <mschiff> I think it should always be clear what the guides refers to: ~arch or stable
-[00:49:11] <tampakrap> it is
-[00:49:45] -*- dilfridge is slightly distracted by some dirndls walking past the window
-[00:49:47] <tampakrap> people don't go by branch, they go by KDE version
-[00:50:39] <tampakrap> anyway, anything else here?
-[00:50:42] <dilfridge> no
-[00:50:48] <j0hu> the guide needs update
-[00:51:09] <tampakrap> what kind of update?
-[00:51:15] <j0hu> hald
-[00:51:18] <j0hu> --
-[00:51:23] <dilfridge> the removal instructions
-[00:51:33] <j0hu> live branches
-[00:51:37] <j0hu> not correct
-[00:51:52] <tampakrap> true, give me a patch :)
-[00:52:08] <mschiff> I hald really still being used?
-[00:52:15] <j0hu> and maybe some info from the upgrade 4.4 guide
-[00:52:24] <dilfridge> mschiff: no
-[00:52:33] <tampakrap> j0hu: are you willing to update it?
-[00:52:45] <dilfridge> should we kill the upgrade guide and merge some info into the main guide?
-[00:52:50] <j0hu> will do after finishing the quizz
-[00:53:08] <tampakrap> merge info: yes, kill the upgrade guide: not yet
-[00:53:31] <tampakrap> anything else?
-[00:53:50] <j0hu> go ahead
-[00:53:59] <dilfridge> not here
-[00:54:11] <tampakrap> 6) Build system architecture bug
-[00:54:15] <tampakrap> +s
-[00:54:24] <tampakrap> bug 358059
-[00:54:26] <willikins> tampakrap: https://bugs.gentoo.org/358059 "cmake-utils.eclass PREFIX is not defined"; Gentoo Linux, Eclasses and Profiles; CONF; meka:kde
-[00:54:45] <dilfridge> no idea about the consequences
-[00:55:02] <dilfridge> I was kind of hoping that reavertm would turn up
-[00:57:06] <tampakrap> if it is defined either way
-[00:57:12] <tampakrap> why defining it earlier is a problem?
-[00:59:02] <mschiff> but wha does the patch kill the /usr default?
-[00:59:15] <dilfridge> I dont understand problem nor solution
-[00:59:28] <mschiff> I only looked at the patch
-[00:59:40] <dilfridge> mschiff: see line 7
-[01:00:01] <dilfridge> I'm more concerned about lines 32/33
-[01:00:29] <dilfridge> why suddenly add the prefix at a place where it was not needed before?!
-[01:01:20] <mschiff> hm, seems a bit strange to me
-[01:01:40] <tampakrap> this is wrong indeed
-[01:01:44] <mschiff> seems like $libdir must not be set this way
-[01:01:46] <tampakrap> the rest is fine imho
-[01:02:10] <mschiff> if it was set to /usr it will end up in /usr/usr/lib
-[01:02:45] <dilfridge> ok shall we kill the 32/33 chunk and test the rest in the  overlay?
-[01:03:03] <tampakrap> not sure
-[01:03:08] <dilfridge> me neither
-[01:03:08] <tampakrap> we need more eyes indeed
-[01:03:19] <tampakrap> CC scarabeus and reavertm there and ask them
-[01:03:22] <dilfridge> I'll try to persuade scarabeus
-[01:03:25] <dilfridge> yes
-[01:03:36] <dilfridge> next one
-[01:03:44] <mschiff> the rest ist nothing special
-[01:03:54] <mschiff> 32/33 is the only real change
-[01:04:07] <tampakrap> ok
-[01:04:09] <tampakrap> next
-[01:04:13] <tampakrap> bug 356681
-[01:04:15] <willikins> tampakrap: https://bugs.gentoo.org/356681 "Please remove media-libs/phonon dependency from kde-base/kdelibs"; Gentoo Linux, Ebuilds; CONF; hwoarang:kde
-[01:04:32] <tampakrap> i don't like this one, and i am not willing to work on this
-[01:04:45] <tampakrap> jmbsvicetto: is it a good solution to create a virtual/phonon?
-[01:05:41] <dilfridge> I fear that the number of problem sources could explode with more than one implementation :|
-[01:05:56] <jmbsvicetto> sorry, I was looking at the patch for the previous bug
-[01:06:01] <dilfridge> YEEEHAH
-[01:06:03] <tampakrap> can we hide it under a kde flag?
-[01:06:09] <jmbsvicetto> btw, the only "real change" in there seems to be the following:
-[01:06:10] <jmbsvicetto> -                SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output directory for libraries")
-[01:06:11] <ABCD> ...sorry I missed most of the meeting (I just got back from a family dinner, which I was rudely informed was more important than this :D)
-[01:06:11] <dilfridge> err sorry
-[01:06:13] <jmbsvicetto> +                SET (CMAKE_INSTALL_LIBDIR ${PREFIX}/${libdir} CACHE PATH "Output directory for libraries")
-[01:06:22] -*- dilfridge just read "CURRENT STATUS OF MANUSCRIPT: Editorially approved for publication"
-[01:06:53] <mschiff> jmbsvicetto: thats what I was saying
-[01:06:57] -*- alexxy still waits for similar resolution from jpcs
-[01:06:59] <jmbsvicetto> about phonon, are they compatible now?
-[01:07:00] <mschiff> and in the eclass:
-[01:07:04] <mschiff> # Eclass respects PREFIX variable, though it's not recommended way to set
-[01:07:04] <mschiff> # install/lib/bin prefixes.
-[01:07:04] <mschiff> # Use -DCMAKE_INSTALL_PREFIX=... CMake variable instead.
-[01:07:22] <jmbsvicetto> cause qt-phonon was behind phonon for a long time
-[01:07:39] <tampakrap> no idea about qt-phonon
-[01:07:43] <tampakrap> and i don't care tbh
-[01:07:56] <jmbsvicetto> I'll see what I can do about this one
-[01:08:14] <jmbsvicetto> I still think we should prefer media-libs/phonon to x11-libs/qt-phonon, though
-[01:08:15] <tampakrap> i'm asking if a virtual is fine, or if we can do this but introduce a kde useflag there so that media-libs/phonon is default
-[01:09:03] <dilfridge> we could say something like " kde? ( media-libs/phonon )  !kde? ( virtual/phonon ) "
-[01:09:17] <jmbsvicetto> dilfridge: kdelibs?
-[01:09:23] <dilfridge> f.ex.
-[01:09:31] <tampakrap> yes, in other kde apps as well
-[01:09:34] <dilfridge> if that is possible and even works
-[01:09:35] <tampakrap> i like it
-[01:09:46] <jmbsvicetto> dilfridge: if so, how's that any different from the current || ( media-libs/phonon x11-libs/qt-phonon ) ?
-[01:09:58] <tampakrap> anyone willing to work on these? (virtual/phonon AND qt-phonon for kdelibs)
-[01:10:15] <dilfridge> with !kde you can run kdelibs also with qt-phonon then
-[01:10:20] <dilfridge> not me
-[01:10:20] <tampakrap> a guy with -kde can get qt-phonon
-[01:10:22] <jmbsvicetto> tampakrap: I'll have to check, but we used to support qt-phonon on kdelibs. We just defaulted to phonon
-[01:10:37] <jmbsvicetto> I'll work on it
-[01:10:45] <dilfridge> ok cool
-[01:10:46] <jmbsvicetto> dilfridge: then someone dropped the old conditional
-[01:10:49] <tampakrap> ok, have a look at both the virtual and the kde flag
-[01:11:10] <jmbsvicetto> tampakrap: I don't know if we gain anything with the virtual (for KDE)
-[01:11:30] <tampakrap> i believe we are
-[01:11:41] <tampakrap> not only for kdelibs, but for other kde apps
-[01:12:00] <tampakrap> put virtual/phonon there instead of the conditional you pasted earlier
-[01:12:03] <tampakrap> seems cleaner
-[01:12:20] <jmbsvicetto> until you think how to prefer media-libs/phonon over x11-libs/qt-phonon
-[01:12:53] <tampakrap> that's for kdelibs (solved by the flag)
-[01:13:08] <tampakrap> other kde or non-kde apps don't need to prefer anything
-[01:13:08] <jmbsvicetto> I'll look at it and then talk to you
-[01:13:13] <tampakrap> sure
-[01:13:28] <tampakrap> bug 332829
-[01:13:30] <willikins> tampakrap: https://bugs.gentoo.org/332829 "Inconsistency between distro's KDE4WorkspaceConfig.cmake and the actual layout"; Gentoo Linux, Library; CONF; cheepeero:kde
-[01:13:50] <tampakrap> i talked about it with reavertm, someone needs to work on it
-[01:13:54] <tampakrap> 99% it will work
-[01:14:16] <dilfridge> tampakrap: tell me if you need chroot testing
-[01:14:33] <dilfridge> not sure if anyone wants to do this in his main system first
-[01:14:37] <tampakrap> i can't work on it, someone else has to do it
-[01:14:59] <tampakrap> volunteers?
-[01:15:08] <mschiff> whats this about?
-[01:15:28] <dilfridge> the internal configuration of the kde build variables is somehow messed up
-[01:15:53] <dilfridge> it makes problems for building apps outside portage
-[01:16:27] <dilfridge> that's about my whole understanding
-[01:16:42] <mschiff> so do we have some qt developer in the team?
-[01:16:54] <jmbsvicetto> dilfridge: that whole deal of building apps outside of portage, is something we should probably talk about again
-[01:16:57] <Sput> oh
-[01:17:03] -*- Sput forgot to check this channel
-[01:17:07] <tampakrap> ABCD: ^^ wanna work on it?
-[01:17:20] <dilfridge> Sput: do you use kdevelop?
-[01:17:23] <tampakrap> mschiff: that needs cmake understanding, not Qt
-[01:17:33] <tampakrap> it is easy to test, there is a patch there already
-[01:17:50] <jmbsvicetto> when we started with kde-4.X, we were clear that we supported portage and building packages with our ebuilds (we have ebuilds for all releases, snapshots and live) and that we wouldn't bother with supporting people that want to install software outside portage
-[01:17:57] <jmbsvicetto> I still think that should be our stance
-[01:18:06] <mschiff> tampakrap: yeah I meant someone who is gerneally developing something with qt or kde...
-[01:18:32] <dilfridge> jmbsvicetto: yes but if someone wants to use kdevelop?
-[01:18:40] <ABCD> dilfridge: RESO:CANTFIX; KDE4WorkspaceConfig.cmake can only be installed by one package (for hopefully obvious reasons), yet must change when other packages are installed (breaking checksums) :)
-[01:19:01] <dilfridge> like, use the application to program something?
-[01:19:11] <jmbsvicetto> dilfridge: if I understand the issue, get upstream to do a release
-[01:19:56] <jmbsvicetto> dilfridge: if the problem is with testing applications built with kdevelop, I'd say the real issue is cmake
-[01:20:00] <dilfridge> jmbsvicetto: no, I mean if upstream is using gentoo?!
-[01:20:15] <jmbsvicetto> dilfridge: I know how much KDE developers hated auto-tools, but this is a price you pay for using cmake
-[01:20:37] <dilfridge> well... it's not really my problem
-[01:20:55] <dilfridge> what I could do is feed the patch into a chroot and rebuild kde
-[01:21:00] <dilfridge> and look at the result
-[01:21:09] <tampakrap> ok
-[01:21:34] <dilfridge> do you think that would be enough testing?
-[01:21:46] <tampakrap> the package is libkworkspace, file is /usr/lib/cmake/KDE4Workspace/KDE4WorkspaceConfig.cmake
-[01:21:54] <tampakrap> and build kdevelop from source
-[01:21:55] <jmbsvicetto> dilfridge: I've talked with Diego about the next bug, and even though we shouldn't be setting RPATH to /usr (KDE), if I understood the issue correctly, that alone won't fix the issue as the other applications (kdevelop?) are setting RPATH themselves
-[01:22:34] <dilfridge> bug 380415
-[01:22:37] <willikins> dilfridge: https://bugs.gentoo.org/380415 "Qt and KDE libs and plugins should not have an RPATH"; Gentoo Linux, KDE; CONF; realnc:kde
-[01:22:49] <jmbsvicetto> we could also drop the /usr/qt4 RPATH for QT as it's part of LDPATH
-[01:22:56] <dilfridge> tampakrap: could this be fixed in qt?
-[01:23:04] <tampakrap> i can't decide
-[01:23:18] <dilfridge> hehe agenda topic for next qt meeting
-[01:23:27] <jmbsvicetto> One issue I talked to Diego but didn't understand is what kind of impact this might have for security
-[01:23:27] <tampakrap> sure, can you test beforehand?
-[01:23:31] -*- dilfridge pushes the pile of papers to the next guy
-[01:23:39] <Sput> just reading backlog... fwiw, I've been using nm09 with knetworkmanager and USE=nm09 for quite a while, it works fine
-[01:24:06] <dilfridge> if anyone tells me how to disable RPATH in qt, yes
-[01:24:27] <Sput> and there won't be a kdelibs-4.8 release (the master branch is frozen now, and people are working in the frameworks branch)
-[01:24:53] <jmbsvicetto> The user on that bug seems to want the QT/KDE libs built without RPATH so that if he builds and installs an app in /usr/local and (as I understand it), he adds a plugin to /usr/local the lib will "link" to that plugin - my question is won't that allow having system libs linking to user-controlled paths? That sounds dangerous
-[01:25:21] <dilfridge> jmbsvicetto: only if they are in LDPATH I guess
-[01:25:29] <ABCD> jmbsvicetto: the point with Qt's RPATH of /usr/lib*/qt4 is that the qt team was going to *drop* it from LDPATH as soon as was practical
-[01:25:35] <jmbsvicetto> The issue is that they are not in LDPATH
-[01:25:56] <jmbsvicetto> better put, that is the complaint and what Diego was pointing out. If it's not in LDPATH it won't "magically" work
-[01:26:00] <dilfridge> and if someone is adding a local dir to LDPATH before system dir, that is his own stupidity
-[01:26:25] <jmbsvicetto> ABCD: understood. That means the request cannot be fulfilled then
-[01:26:40] <jmbsvicetto> dilfridge: sure
-[01:27:04] <jmbsvicetto> dilfridge: but what they wanted was the libs to have no rpath so they could "link" to a lib anywhere - that's what sounds dangerous to me
-[01:27:22] <ABCD> dilfridge: the default actually puts /usr/local/lib first before everything else (note, /usr/local/lib64 isn't mentioned until after /lib64 and /usr/lib64)
-[01:27:32] <Sput> dilfridge: and I don't use KDevelop at the moment
-[01:27:39] <jmbsvicetto> dilfridge: even though, from what Diego told me, that won't work as without RPATH the system will only look under LDPATH
-[01:27:39] <dilfridge> /usr/local/lib is still root:root
-[01:27:41] <ABCD> see /etc/env.d/00basic
-[01:27:49] <ABCD> true :)
-[01:28:44] <dilfridge> ok I guess this is effectively going to be decided by the qt team
-[01:28:48] <jmbsvicetto> so I don't know enough about this, but hope any change we do won't open any unwanted "doors"
-[01:29:47] <dilfridge> any more thoughts about this?
-[01:29:52] <jmbsvicetto> dilfridge / tampakrap: No comments or objections from me to the next 2 (final) items
-[01:30:42] <dilfridge> the last two items are the simple ones
-[01:30:51] <tampakrap> no objections from me either
-[01:31:16] <dilfridge> my opinion: a) add libXkbfile globally, b) remove the useflag
-[01:31:43] <tampakrap> yes and yes
-[01:31:43] <ABCD> do the libs/progs with RPATH set also have RUNPATH set? If so, then LD_LIBRARY_PATH overrides it anyway, so... :D
-[01:32:56] <ABCD> (I think cmake uses the proper ld(1) options that make the linker set DT_RPATH *and* DT_RUNPATH)
-[01:32:56] <Sput> as for the Qt5/KDE5 thingy: Qt5 will be released next spring or so, KDE will take longer... work on kdelibs is going on in the framework branch
-[01:33:04] <dilfridge> >:|
-[01:33:24] <Sput> we need the qt herd to provide us with Qt5 ebuilds soonish (and I hope the eclasses still support proper slotting)
-[01:33:44] <ABCD> I think some eclass magic is needed to make kdefoo 4.8 depend on kdelibs >= 4.7.0
-[01:33:48] <dilfridge> Sput: argh... which gets back to the last issue
-[01:33:48] <tampakrap> Sput: i thought frameworks is going to be kdelibs 4.8
-[01:33:55] <dilfridge> ABCD: yes but that is doable
-[01:34:01] <Sput> tampakrap: no, frameworks is not going to be 4.8
-[01:34:10] <Sput> there won't be a kdelibs-4.8
-[01:34:10] <ABCD> dilfridge: that is "I think I'm going to have to write some eclass magic ..."
-[01:34:12] <tampakrap> and what is it going to be then?
-[01:34:46] <tampakrap> ABCD: or fakebump kdelibs to 4.8 :)
-[01:34:51] <Sput> well, probably what we call "KDE 5" although I'm sure the KDE promo team is going to come up with yet another naming scheme in time :P
-[01:34:54] <ABCD> tampakrap: too much work :D
-[01:35:07] <ABCD> Sput: there is no KDE 4, so how could there be a KDE 5? :)
-[01:35:11] <dilfridge> Sput: indeed
-[01:35:18] <tampakrap> ok let's wait then
-[01:35:22] <ABCD> KDE is a community, you can't attach a version number to something like that :)
-[01:35:22] <Sput> ABCD: exactly
-[01:35:22] <dilfridge> Bulshytt!
-[01:35:26] <jmbsvicetto> tampakrap: that's why last time there was a talk on #-kde about this I said we were going to have some fun like in the early KDE-4 days
-[01:35:56] <Sput> the frameworks branch ist going to be the next incarnation of kdelibs, currently they work on reorganizing/cleaning up/splitting kdelibs, as soon as Qt5 is released they'll port it over
-[01:36:01] <jmbsvicetto> tampakrap: we're going to have kde-4.8 depending on kdelibs-4.7 and we may even have kdeA-4.8, kdeB-4.9, etc
-[01:36:03] <Sput> the rest of KDE will follow suit only later
-[01:36:28] <tampakrap> jmbsvicetto: that's only assumptions, just wait for the release
-[01:36:29] <ABCD> if upstream slots things properly, I think we should slot; otherwise everything goes in :4 (which we might want to make :0 instead :D)
-[01:36:37] <Sput> there will be more kdelibs-4.7.x releases, but I don't think a 4.8 ever unless they changed plans again
-[01:36:50] <dilfridge> ABCD: nononono, what with :4 and :5 then? :O
-[01:37:11] <Sput> we certainly will have to slot Qt versions
-[01:37:14] -*- dilfridge thinks we cannot really predict the upcoming chaos
-[01:37:16] <jmbsvicetto> ABCD: no gain in moving to :0 again
-[01:37:17] <Sput> not sure about KDE
-[01:37:26] <jmbsvicetto> ABCD: besides, don't forget some people still use kde-3.5 ;)
-[01:37:44] <dilfridge> Enable auto-destruct sequence
-[01:37:50] <tampakrap> Sput: qt is slot 4, isn't that sufficient?
-[01:38:05] <j0hu> some people dont know how to remove 3.5 :P
-[01:38:05] <Sput> tampakrap: it is, if slotting still works in the eclasses
-[01:38:26] <tampakrap> it is, why shouldn't it? :)
-[01:38:35] <tampakrap> anyway, people, don't panic
-[01:38:43] <Sput> tampakrap: well, we've removed proper slotting support from the KDE eclasses
-[01:38:48] <Sput> who knows what the qt herd did :)
-[01:38:51] <tampakrap> you are all making assumptions here, just wait for the next release to show up
-[01:38:55] <jmbsvicetto> tampakrap: because it hasn't been tested in a long time ;)
-[01:39:06] <tampakrap> lol
-[01:39:15] <Sput> tampakrap: well, Qt5 is already under development (and I will start working with it in a few days), I'd love to be able to install it into Gentoo
-[01:39:23] <Sput> (without removing qt4 obviously)
-[01:39:46] <jmbsvicetto> Sput: unless we get ABI deps, I suspect you're going to have *great* pain trying that
-[01:40:07] <tampakrap> true, nothing's going to be so smooth for sure
-[01:40:09] <dilfridge> unless every binary sets the correct RPATH :P
-[01:40:14] <tampakrap> major versions ahead, red flag
-[01:40:34] <Sput> jmbsvicetto: well, used to be the case that just calling the correct qmake version would set everything up correctly...
-[01:41:01] <dilfridge> this is going nowhere
-[01:41:02] <Sput> I'm just saying, we need to be aware of Qt5 being right around the corner already
-[01:41:06] <dilfridge> let's just wait and see
-[01:41:12] <Sput> it's not something that'll hit us in a few years
-[01:41:18] <jmbsvicetto> tampakrap: no need for anyone to stuck his head in the ground, but it's probably wise to look over the ship's border in case a huge wave rocks the boat ;)
-[01:41:20] <tampakrap> dilfridge: this is open floor, of course it's not going nowhere :)
-[01:41:33] -*- dilfridge gets himself a drink
-[01:41:39] -*- Sput has a beer
-[01:41:49] -*- tampakrap drunk his already
-[01:41:52] <nirbheek> meetings are long, eh :)
-[01:41:57] -*- Sput has moar in the fridge
-[01:41:58] <tampakrap> and btw, MEETING IS OFF
-[01:42:08] <tampakrap> summary tomorrow
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120116.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120116.txt
deleted file mode 100644
index aa6bc0d9d6..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120116.txt
+++ /dev/null
@@ -1,630 +0,0 @@
-<tampakrap> meeting starts now
-<tampakrap> roll call again please: alexxy / ABCD / jmbsvicetto / dilfridge /
-johu / mschiff / Thev00d00
--*- johu here
-<jmbsvicetto> here
--*- alexxy here
--*- alexxy here again and again =D
-<dilfridge> here
--*- alexxy like quantum particle here and not here with non zero probability
-<tampakrap> first topic: elect new lead
-<tampakrap> nominations?
--*- johu nominates tampakrap
-<jmbsvicetto> Do we really want to do it at this meeting?
-<tampakrap> raise your complain please
-<jmbsvicetto> Nothing prevent us to anticipate the election, but that means
-the 2011 term had only 11 months and that for the future the election will
-happen before FOSDEM
-<dilfridge> we could vote whether we want to vote
-<dilfridge> or we could just vote by acclamation at fosdem :D
-<jmbsvicetto> When dilfridge mentioned this topic at IRC, I got the impression
-the point was to talk about the election, not to have it today
-<dilfridge> i dont care, maybe I just misunderstood
-<johu> me dont care too
-<jmbsvicetto> If no one has any reason to do it today, I'd have us wait 3
-weeks
-<dilfridge> lead is bad for your health anyway
-<tampakrap> ok, skipped for next meeting
-<jmbsvicetto> you guys can pick Theo at FOSDEM and then we can do a mail tally
-just to record it
-<dilfridge> hehe
-<alexxy> he he
-<tampakrap> next topic
--*- alexxy seems like cannot participate fosdem this year
-<jmbsvicetto> As in the past, I'll keep abstaining from kdepim issues :P
-<tampakrap> What shall we do with kdepim-4.4 (15 minutes)
-<tampakrap>    * Discuss/vote: At the moment KDEpim-4.4 is still fully
-functional, no known
-<tampakrap>    regressions. Functionality of KDEpim-4.7 is slowly stabilizing,
-with occasional
-<tampakrap>    pains. Do we want to keep KDEpim-4.4 in the main tree?
-<tampakrap> dilfridge: yours
-<dilfridge> well...
-<dilfridge> I'm happy with how it is now
-<dilfridge> means, keep 4.4 for the moment, but also keep stabilizing newer
-4.[78] versions
-<johu> i dont care about  kdepim 4.4 as long its work we can maintain it
-<dilfridge> right
-<dilfridge> at the moment it's zero work
-<dilfridge> to maintain it
-<dilfridge> it's just about giving people a choice
-<jmbsvicetto> It's up to you, but if that's what you think, I see no reason to
-change the status quo
-<tampakrap> if it's zero work, why remove it then?
-<johu> a note from upstream they want to change migration to import ...
-<tampakrap> rumors
-<johu> if this feature will come we can think about removing
-<dilfridge> hmm?
-<alexxy> dilfridge: how about use kde-4.[78] kde-l10n for old kdepim-4.4?
-<dilfridge> you'll have to explain why...
-<alexxy> to not keep separate kdepim-l10n
-<johu> alexxy: this doesnt work as i know
-<dilfridge> it partly works, some translations are broken afterwards
-<jmbsvicetto> alexxy: I don't think that'll work
-<jmbsvicetto> alexxy: the l10n of kdepim-4.4 and kdepim-4.7 is not compatible
-<alexxy> well then we should add kdepim-l10n to rdeps then
-<johu> and its not much work to create the kdepim-l10n
-<alexxy> ok =)
-<tampakrap> good
-<johu> any additions?
-<alexxy> then we should add kdepim-l10n to rdeps for all kdepim packages
-<tampakrap> final resolution: we keep it there, we'll have to create l10n
-though
-<alexxy> to make it pull kdepim-l10n
-<jmbsvicetto> alexxy: wasn't there a kdepim-base package?
-<jmbsvicetto> alexxy: that could be added there
-<Thev00d00> sorry very late guys, reading backlog
-<jmbsvicetto> Or did that become kdepimlibs?
-<dilfridge> kdepim-meta pulls kdepim-l10n with nls useflag
-<alexxy> http://paste.pocoo.org/show/535829/
-<dilfridge> same as kde-meta pulls kde-l10n with nls useflag
-<alexxy> dilfridge: i have this flag
-<tampakrap> can we make that nls flag global in kde packages then?
-<alexxy> and i dont have kdepim-l10n installed
-<dilfridge> ok
-<jmbsvicetto> tampakrap: why make it a use flag for all packages?
-<tampakrap> i mean, global like semantic-desktop, put it in every kde package
-<dilfridge> alexxy: we'll sort this out
-<tampakrap> because i for example want only konsole and am an xfce user
-<jmbsvicetto> tampakrap: I'd try to add it to a base package - like kdelibs
-for non-pim packages
-<tampakrap> but i also want translations of konsole
-<tampakrap> or that, kdelibs is also acceptable
-<alexxy> he he =)
-<alexxy> +1 for tampakrap
-<jmbsvicetto> alexxy: thanks :P
-<johu> +1 from me
-<tampakrap> dilfridge / jmbsvicetto: nls in kdelibs, acceptable?
-<dilfridge> we could do the following: have the eclass add kde-l10n and if
-needed kdepim-l10n to rdeps if any lingua is set
-<dilfridge> tampakrap: yes but that does not solve the kdepim-l10n problem
-<dilfridge> adding the rdep in the eclass is better
-<jmbsvicetto> tampakrap: that's what I suggested :P
-<alexxy> dilfridge: rdep via use flag
-<alexxy> =)
-<alexxy> =D
-<dilfridge> ok fine, add useflag to all kde packages: if "nls" is set, pull
-*-l10n
-<jmbsvicetto> dilfridge: Is there no base kdepim package that we could do the
-same as in kdelibs?
-<dilfridge> no, unfortunately not
-<jmbsvicetto> Please don't add it to all kde packages
-<jmbsvicetto> Why do we want a use flag to all packages when all it does is
-pull one dep?
-<dilfridge> kdepimlibs would be a candidate, but it's not really used by all
-afaik
-<dilfridge> well
-<jmbsvicetto> It would make sense to add it to all packages if the packages
-tarballs add the l10n stuff and we could enable/disable for each package
-<tampakrap> kdepimlibs is separate from kdepim
-<dilfridge> err
-<dilfridge> sorry
-<dilfridge> libkdepim
-<tampakrap> yes, that works
-<jmbsvicetto> Don't all kdepim packages depend on libkdepim?
-<tampakrap> so, kdelibs for kde-l10n and libkdepim for kdepim-l10n,
-acceptable?
-<dilfridge> let's try that, yes.
-<jmbsvicetto> s/add/had/
-<jmbsvicetto> tampakrap: yes
-<tampakrap> alexxy / johu ^^
-<alexxy> tampakrap: yep
-<tampakrap> good, i'll do it
-<dilfridge> excellent.
-<tampakrap> actually, i'll assign it to a non-dev to do it
-<dilfridge> :D
-<tampakrap> for practice
-<alexxy> he he
-<alexxy> for idella4?
-<tampakrap> anything else here?
-<alexxy> he is very active
-<alexxy> =)
-<tampakrap> no, i have a list of interested people, don't worry
-<idella4> he is indeed
-<alexxy> =)
-<idella4> never mind
-<tampakrap> anything else here?
-<tampakrap> next topic:
-<tampakrap> 4. kdeenablefinal revisited (15 minutes)
-<tampakrap>    * Discuss/vote: See last test run bug #353246. Should we
-provide this
-<tampakrap>    feature anymore? What is the purpose nowadays, in fact of
-upstream keep
-<tampakrap>    going split the huge packages (kde frameworks, kdepim)?
--*- johu had a kernel panic :-/
-<tampakrap> dilfridge: ^^ yours again
-<dilfridge> not mine
-<johu> no its mine
-<johu> i want get rid of this mess
-<tampakrap> well, add your names next to the topic next time people
-<willikins> tampakrap: https://bugs.gentoo.org/353246 "[Tracker]
-kdeenablefinal build failures"; Gentoo Linux, KDE; CONF; dilfridge:kde
-<jmbsvicetto> tampakrap: last time we agreed to let it be as esigra was doing
-all the work and we just left the bugs alone ;)
-<alexxy> tampakrap: is it still works?
-<alexxy> or do we still need this
-<johu> upstream do not maintain it active
-<johu> and it seams only one user uses it
-<tampakrap> most upstream devs don't even know about its existance
-<johu> and i do not see the purpose
-<jmbsvicetto> tampakrap: I still have no interest in it and won't shed any
-tears if we drop it
--*- dilfridge does not care either way
-<tampakrap> but anyway, it doesn't make much sense that now most packages are
-split in separate git repos
-<alexxy> so lets kill it
-<alexxy> =)
-<johu> yes!
-<alexxy> like we did for kdeprefix
-<alexxy> =)
-<tampakrap> ok, do it
-<johu> thanks
--*- Thev00d00 woops
-<dilfridge> hehe
-<tampakrap> anything else?
--*- dilfridge wants to close the bugs
-<johu> ok will purge it tomorrow
-<johu> and closes the bugs as well
-<tampakrap> next topic:
-<tampakrap> 5. phonon-xine removal (5 minutes)
-<tampakrap>    * Discuss/vote: Upstream declared it as dead. Already masked
-since 1. Dec
-<tampakrap>    2011. We have two other working and maintained backends.
-Current open bugs
-<tampakrap>    #359979, #397585.
-<tampakrap> who?
-<johu> i
-<tampakrap> write your name next time or i'll come to germany and choke you
-<alexxy> kill it =D
-<Thev00d00> eofl
-<Thev00d00> *rofl
-<dilfridge> is this still the latest? or are they resuming development since
-xine-1.2 is out?
-<Thev00d00> But yeah bitrot should be removed
-<jmbsvicetto> dilfridge: I was going to ask about it
-<johu> have a look at p.k.o
-<tampakrap> johu: did you ask any upstream devs about it?
-<jmbsvicetto> dilfridge: the reason for the p. mask was that we thought it was
-completely dead, but now it seems there are people working on t
-<jmbsvicetto> it*
-<tampakrap> i'm not aware of anything official
-<johu> tampakrap: it was announced as dead with kde 4.6.0
-<jmbsvicetto> johu: yes, but xine itself was considered to be dead. Now it
-seems it might not be
-<dilfridge> jmbsvicetto: well, 3 commits in 12 months...
-<tampakrap> we have to ask in #phonon
-<jmbsvicetto> I've moved to phonon-vlc a long time ago, so I have no direct
-interest in xine/phonon-xine
-<jmbsvicetto> dilfridge: hmm, that doesn't seem to active to me
-<dilfridge> * #phonon: Cannot join channel (+i) - you must be invited
-<jmbsvicetto> in any case, I think we should make sure before we kill it
-<johu> thats why we mask it
-<tampakrap> wait people
-<tampakrap> i'll ask apachelogger
-<jmbsvicetto> if xine is still dead, then let's kill phonon-xine. Otherwise,
-we can keep phonon-xine for a few more weeks / months to see if anything turns
-out of it
-<tampakrap> i asked apacheloger, depending on the answer i get we'll act
-accordingly
-<tampakrap> apacheloger = upstream phonon dev
-<tampakrap> acceptable?
-<johu> yes
-<dilfridge> I also asked on #kde-multimedia, let's see
-<jmbsvicetto> dilfridge: seems like #phonon is redirecting to #kde-multimedia
-<tampakrap> anything else here?
-<tampakrap> next:
-<tampakrap> 6. qt-4.8 (5 minutes)
-<tampakrap>    * Short discussion about potential problems.
-<tampakrap> i updated to 4.8, everything seemed fine apart from kdenlive
-<tampakrap> no glitches, no compilation failures
-<kokeroulis> !
-<dilfridge> anyone here who updated with kde-4.7.x ?
-<johu> i'll switch if it in tree
-<tampakrap> yes, i updated to qt 4.8 and kde 4.7.4
-<dilfridge> I updated 3 machines, no problems at all with kde-4.8 beta/rc
-<tampakrap> kokeroulis: if you want to speak just do it
-<kokeroulis> on Qt 4.8 there is an issue with the pointers
-<jmbsvicetto> dilfridge: I'm just running ~arch these days
-<kokeroulis> they are not killed
-<dilfridge> but updating a running kde-4.7.4 made all kde programs segfault in
-oxygen style until I rebuilt kstyles
-<kokeroulis> there is a post on plasma-devel ML
-<dilfridge> ok
-<dilfridge> let's see
-<tampakrap> johu: you could help us (qt) about it
-<tampakrap> wired should know better
-<tampakrap> and pesa
-<johu> tampakrap: you can ask me to join the herd :P
-<tampakrap> i'll send you an invitation
-<tampakrap> kokeroulis: how serious is that issue?
-<tampakrap> and how much does it affect us?
-<dilfridge> I suggest we make two revs of kstyles-4.7, one requiring qt-4.7,
-one requiring qt-4.8  ---> forces a rebuild, one problem solved
-<tampakrap> +1
-<johu> +1
-<ago> +1(external)
-<kokeroulis> tampakrap: it seems a alot. Because some upstream devs has
-mention that the KDE 4.8 should be shipped with Qt 4.8, so we will fix it
-until the major upgrade of the binary distros. Otherwise all the binary distro
-will ship KDE with this issue on their major version
-<jmbsvicetto> dilfridge: how are you going to manage the revision numbers?
-<dilfridge> jmbsvicetto: by hand... -r0 & -r10 ...
-<dilfridge> I'll figure somethign out
-<dilfridge> it only requires talking to qt
-<tampakrap> just put one in overlay until 4.8 is out
-<dilfridge> exactly
-<dilfridge> and mask it together with qt-4.8
-<jmbsvicetto> dilfridge: sure, but I meant the numbers. So we can use 9
-revisions for kde-4.7. OK :)
-<dilfridge> kokeroulis: do you have a link to the ml post?
-<kokeroulis> dilfridge:
-http://mail.kde.org/pipermail/plasma-devel/2012-January/018493.html
-<dilfridge> ook
--*- dilfridge librarian mode
-<jmbsvicetto> tampakrap: shall we move to RPATH ?
-<kokeroulis> there are more about this conversation but the web archives have
-some issue about that
-<kokeroulis> dilfridge: i found it.
-http://lists.kde.org/?t=132630064900003&r=1&w=2
-<tampakrap> jmbsvicetto: dunno
-<tampakrap> anyway, is it so important to discuss it now? can we continue the
-discussion in the mailing list or next meeting?
--*- wired is here :)
-<johu> next meeting^
-<dilfridge> tampakrap: wired: any plans to move qt-4.8 to the main tree (even
-masked)?
-<tampakrap> wired: issues with qt 4.8?
-<wired> dilfridge: unmasked, prolly sometime next week (near end), unless you
-kde guys have any serious issues with it
-<dilfridge> heh
-<johu> wired: no only kdenlive failed to build
-<dilfridge> that makes the priority a bit higher
-<Thev00d00> mmmmmm qt-4.8-y goodness
-<dilfridge> wired: afaik no serious problems
-<idella4> it appeared to be a tiny fixable problem
-<dilfridge> at least I'm running it
-<dilfridge> I have not hit the problem yet that kokeroulis mentioned
-<tampakrap> wired: issues/tracker to help?
-<dilfridge> omg
-<dilfridge> it's starting
-<tampakrap> what?
-<wired> tampakrap: hadn't had the time to do anything yet, no major issues
-afaik, just opportunities to fix things :)
-<dilfridge> [21:55:23] <CIA-4> ago * gentoo-x86/app-misc/strigi/
-(strigi-0.7.7.ebuild ChangeLog):
-<dilfridge> [21:55:23] <CIA-4> Stable for amd64, wrt bug #396359
-<dilfridge> [21:55:23] <CIA-4> (Portage version: 2.1.10.41/cvs/Linux x86_64)
-<dilfridge> [21:55:26] <willikins> CIA-4: https://bugs.gentoo.org/396359 "KDE
-4.7.4 and dependencies stabilization"; Gentoo Linux, Keywording and
-Stabilization; CONF; dilfridge:kde
-<willikins> https://bugs.gentoo.org/396359 "KDE 4.7.4 and dependencies
-stabilization"; Gentoo Linux, Keywording and Stabilization; CONF;
-dilfridge:kde
-<wired> lololol
-<johu> dilfridge: you will get a lot of highlights now
-<dilfridge> right.
-<kokeroulis> wired: i have not used the Qt 4.8, so i don't know if there is
-any big issue....
-<tampakrap> ok good
-<wired> kokeroulis: i've installed it on my two main workstations and it works
-fine, however I don't have KDE anywhere ^)
-<tampakrap> anything else here or shall we move?
-<dilfridge> move
-<johu> move it baby
-<dilfridge> wired: talk to me please before you bump qt
-<tampakrap> 7. Dropping RPATH from installed binaries (5 minutes)
-<tampakrap>    * Short discussion- any objections to testing this in the
-overlay eclasses and later
-<tampakrap>    moving it to the main tree if it works?
-<wired> dilfridge: sure, was planning to anyway :)
-<dilfridge> this is mine
-<dilfridge> we already removed the RPATH from qt libraries successfully
-<wired> with no real benefit probablhy
-<wired> ;p
-<dilfridge> it's possible because we add the qt library dir to /etc/ld.so.conf
-<johu> whats the purpose?
-<dilfridge> well, all binaries built by qmake not also have no RPATH
-<jmbsvicetto> dilfridge: I don't agree with dropping RPATH from binaries on
-Linux
-<dilfridge> I'd say simplifying things
-<johu> what can break?
-<dilfridge> we do not need two pointers to the lib dir
-<jmbsvicetto> dilfridge: and by dropping it from the Qt eclass we were
-supposely telling the linker to use what KDE defined - and not building
-binaries with empty RPATH
-<ago> dilfridge: just leave #gentoo-commits for a while :)
-<dilfridge> no, the plan was to get rid of the RPATH entirely
-<jmbsvicetto> dilfridge: the issue is that binaries with empty RPATH have an
-higher security sensitivity
-<dilfridge> err... why?
-<jmbsvicetto> dilfridge: the reason we set the RPATH is to ensure that a user
-is not able to "subvert" a legitimate binary by having it use libraries on a
-exploited dir
-<jmbsvicetto> dilfridge: if you have a binary A that uses library B and you
-allow the user to specify the library dirs in which A should check for B, you
-allow the user to add a "compromised" B library to a dir he controls and with
-that you allow A to be compromised
-<jmbsvicetto> dilfridge: at least that's my understanding. I might be wrong
-<dilfridge> LD_LIBRARY_PATH is ignored for setuid
-<dilfridge> and you could always copy a normal binary and set its RPATH
-<wired> jmbsvicetto: with LDPATH and LD_LIBRARY_PATH i wonder if RPATH is
-really preventing what you're talking about
-<jmbsvicetto> wired: but LDPATH is controlled by root, right?
-<wired> system files as well
-<jmbsvicetto> dilfridge / wired: in any case, if you guys are not sure, I
-think we should talk with the hardened team before dropping RPATH from
-binaries
-<dilfridge> and with the prefix team probably :|
-<wired> that has to happen before qt 48 goes to main tree
-<dilfridge> we should track down diego
-<jmbsvicetto> I'll try to talk with Diego about it
-<dilfridge> ah, he's coming to fosdem
-<wired> he's alive and kicking @twitter ^_^
-<tampakrap> anything else?
-<jmbsvicetto> I haven't caught him on jabber in a while :-\
-<tampakrap> move?
-<dilfridge> move, decision postponed
-<tampakrap> 8. To eselect Boost or not to eselect boost (10 minutes)
-<tampakrap>    We need to figure out what is actually the best desired
-behaviour :|
-<tampakrap> who?
-<dilfridge> dev-zero
-<dilfridge> :]
-<johu> newest info was that eselect goes away
-<johu> see comments in the bug
-<dilfridge> we need to discuss this on the mailing list
-<dilfridge> but boost maintainers seem to prefer always building against
-newest version
-<johu> so lets talk to dev-zero and if this not help dev ml
--*- tampakrap is confused
-<tampakrap> ok now i get it
-<tampakrap> so move?
-<johu> no move
-<johu> at least not to tree
-<tampakrap> move to next topic i mean
-<johu> yeah^
-<tampakrap>    * dev-util/cmake picks always the latest boost.
-<tampakrap>    * Fix in overlay since 13. Dec. Move to tree?
-<tampakrap>    https://bugs.gentoo.org/show_bug.cgi?id=335108
-<jmbsvicetto> I still think this should be moved to the gentoo-dev ml
-<johu> tampakrap: this is the same^
-<jmbsvicetto> This is far more involving that just kde, and can affect any
-package using cmake - like mysql-5.5 ;)
-<tampakrap>    * cmake-utils.eclass PREFIX is not defined, any progress?
-<tampakrap>    https://bugs.gentoo.org/show_bug.cgi?id=358059
-<tampakrap> johu: raise the topic in the ml then?
-<johu> tampakrap: seems that this my part
-<johu> @boost
-<dilfridge> [22:14:00] <tdfischer> dilfridge: pxine is dead
-<dilfridge> [22:14:09] <tdfischer> no plans to revive
-<jmbsvicetto> johu: the arguments from dev-zero about the use of boost should
-also be discussed as boost should be compared to gcc, python, ruby, etc
-<johu> dilfridge: so we can remove it
-<jmbsvicetto> fine with me
-<dilfridge> johu: I think so, yes
--*- johu will do this
-<johu> i will send a 10 days last rite
-<mschiff> hey guys I am very sorry, I slept away two hours ago... :-/
-<johu> " * cmake-utils.eclass PREFIX is not defined, any progress?"
-<johu> the last comment from this bug was that reavertm want to investigate,
-but nothing happend
-<jmbsvicetto> johu: use the usual 15 days, please
-<johu> jmbsvicetto: its masked since start of dec
-<jmbsvicetto> johu: otherwise someone will complain about it and we'll get in
-an argument that will likely be less useful than just waiting 15 days ;)
-<jmbsvicetto> johu: I know, but mask is not the same as last-rite and I
-believe it's more productive to wait 5 more days than get in an argument for
-not having followed policy
-<johu> jmbsvicetto: fine with me
-<tampakrap> move to next?
-<johu> see some lines above
-<johu> the cmake PREFIX bug
-<jmbsvicetto> johu: that one will require work with the prefix team, no?
-<johu> jmbsvicetto: it would be good if reavertm were here
-<johu> maybe he have infos about that
-<jmbsvicetto> johu: That won't be easy as grobian is not a fan of cmake and it
-does seem to have base flaws to support prefix
-<dilfridge> jmbsvicetto: not really afaik
-<dilfridge> that is not something related to "Gentoo prefix"
-<dilfridge> more like, cmake build magic
-<jmbsvicetto> dilfridge: sorry, then I must be thinking at another bug
-<johu> jmbsvicetto: yeah you think about the other cmake bug
-<johu> the macosx request
-<tampakrap> ok, can we skip that then for next meeting?
-<tampakrap> reavertm is not here today
-<jmbsvicetto> Ah, now I recall this bug
-<jmbsvicetto> I still don't see what that patch actually fixes
-<jmbsvicetto> That patch assumes prefix is defined and if it's empty it
-doesn't add /usr
-<johu> yes
-<jmbsvicetto> I still think that patch is wrong
-<jmbsvicetto> better still, that patch moves the definition of prefix to the
-start and then does the same as it was doing before
-<jmbsvicetto> so the only real change there is the following:
-<jmbsvicetto> -                SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH
-"Output directory for libraries")
-<jmbsvicetto> +                SET (CMAKE_INSTALL_LIBDIR ${PREFIX}/${libdir}
-CACHE PATH "Output directory for libraries")
-<jmbsvicetto> everything else is just a "format" change
-<johu> ok
-<jmbsvicetto> so the question is whether libdir should or should not be
-relative to prefix
-<jmbsvicetto> tampakrap: anyway, we can move to next bug :)
-<tampakrap> thank you
-<tampakrap>    * Remove hard dep on media-libs/phonon from kde-base/kdelibs
-<tampakrap>    https://bugs.gentoo.org/show_bug.cgi?id=356681
-<tampakrap>    https://bugs.gentoo.org/show_bug.cgi?id=388041
-<jmbsvicetto> Has upstream fixed the bug that made us add the hard dep?
-<tampakrap> no
-<jmbsvicetto> iirc, knotify would stuck if we didn't had phonon in the system
-<tampakrap> phonon still requires at least a backend to work
-<tampakrap> and taking out phonon from kdelibs is not possible
-<jmbsvicetto> so WONTFIX / UPSTREAM ?
-<johu> so we have to postpone this to kde frameworks?
-<dilfridge> can you build kdelibs against qt-phonon?
-<tampakrap> so, kdelibs still needs phonon and we can't substitute it with
-qt-phonon yet
-<tampakrap> no, we asked upstream already
-<tampakrap> dilfridge: and i think you did actually :)
-<dilfridge> I only asked if you need a backend to phonon
-<dilfridge> not if qt-phonon were a substitute to phonon
-<tampakrap> you are in the channel, ask them about it now then :)
-<jmbsvicetto> I would like us to be able to drop the phonon dep, but upstream
-doesn't allow us to present that choice to users :-\
-<johu> so resolution?
-<tampakrap> let's ask upstream first
-<tampakrap> but i'm 99,99% sure it's not possible
-<jmbsvicetto> and if not, close it as UPSTREAM
-<johu> ok move on
-<dilfridge> just did
-<tampakrap>    * Eclass problem with handbook without LINGUAS.
-<tampakrap>    https://bugs.gentoo.org/show_bug.cgi?id=372457
-<johu> idella4: do you have find something out?
-<dilfridge> that's an obscure one
-<johu> ^
-<idella4> ??
-<idella4> about this bug?
-<johu> yes
-<idella4> well you caught me on the hop
-<idella4> I seem to remember working it
-<idella4> I had it compile effectively without LINGUAS set from memory
-<idella4> but -handbook was causing the flaw
-<idella4> that must be around a week ago
-<idella4> maybe I left some good comment in the bug
--*- dilfridge gets a drink
-<tampakrap> ok, is there anything to discuss here?
-<johu> no
-<tampakrap>    * MacOSX request for cmake-utils.eclass:
-<tampakrap>    Remove force of CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE
-<tampakrap>    https://bugs.gentoo.org/show_bug.cgi?id=398437
-<tampakrap>    -> can easily be done, because the FORCE affects only prefix
-anyway
-<johu> jmbsvicetto: here we go^
-<tampakrap> jmbsvicetto: ^^ is that the one you confused earlier?
-<jmbsvicetto> no reason to drop that hard requirement
-<jmbsvicetto> yes
-<jmbsvicetto> bah, sorry. I meant to say, no reason *not* to drop that hard
-requirement
-<jmbsvicetto> so let's do what prefix asked
-<johu> thats sound reasonable
-<johu> move on?
-<jmbsvicetto> fine with me
-<dilfridge> we've reached kde-base/kcolorchooser by now
--*- johu is watching the chat monitor
-<tampakrap>    * Revise the change "semantic-desktop? -> semantic-desktop=".
-<tampakrap>    Why was the change needed.
-<tampakrap>    https://bugs.gentoo.org/show_bug.cgi?id=396491
-<jmbsvicetto> dilfridge: if you want, we can highlight you a bit on
-#gentoo-kde ;)
-<dilfridge> yeah well reavertm is still not here
-<dilfridge> hehe
-<johu> i am fine with dropping the '='
-<jmbsvicetto> so, I never liked that semantic-desktop? -> semantic-desktop=
-move, but it was done with the argument that we were getting strange and
-unexplicable bug reports and that it was causing issues in the upstream bug
-tracker
-<dilfridge> I dont see why we should allow "?"
-<dilfridge> because nobody gains from it
-<tampakrap> +1 @ dilfridge
-<dilfridge> once you have kdelibs with semantic-desktop, you have all the
-dependencies
-<jmbsvicetto> dilfridge: As I don't want semantic-desktop at all, being able
-to just enable it where I'm forced, would be a plus. But I think we should try
-to be consistent
-<dilfridge> but dont you need kdelibs[semantic-desktop] for any
-semantic-desktop enabled package? /me confused
-<tampakrap> can we skip it for next meeting?
-<johu> sure
-<dilfridge> yawn
-<tampakrap> good
-<tampakrap> OPEN FLOOR
-<jmbsvicetto> there were real reasons that we agreed with to have
-semantic-desktop= back then (we as in the kde team, even if I disagreed)
-<jmbsvicetto> dilfridge: ? allows that
-<dilfridge> yes
-<jmbsvicetto> dilfridge: the point with = was that I would have to had every
-kde package built with semantic-desktop if just a single one required
-semantic-desktop
-<dilfridge> scarabeus was the one to push that decision
-<johu> tampakrap: talk to scarabeus in office  about that
-<jmbsvicetto> tampakrap: I feel like were starting to have a "memory issue" in
-the KDE team. We got enough new people recently that some of the old issues
-are being raised again as the team (or a substantial part of the team) doesn't
-know the history behind them
-<tampakrap> jmbsvicetto: i believe that is reasonable though, things change,
-new decisions are taken
-<jmbsvicetto> tampakrap: that means we should probably start thinking about
-providing better documentation for decisions so that people know sometime
-later whey they were done
-<dilfridge> technically it should be in the meeting logs
-<tampakrap> i agree with the documentation, and it is entirely my fault
-<tampakrap> i'll do my best from now on though
-<johu> open floor: cleaning up herd?
-<tampakrap> again?
-<jmbsvicetto> tampakrap: I don't think it's a bad thing. I'm just stating that
-I've noticed it and that we should perhaps rethink a few things in how we
-operate ;)
-<tampakrap> i did that in less than a year :(
-<tampakrap> jmbsvicetto: +1
-<johu> !herd kde
-<willikins> (kde) abcd, alexxy, dilfridge, jmbsvicetto, johu, mschiff,
-patrick, reavertm, spatz, tampakrap, thev00d00
-<johu> spatz?
-<johu> patrick?
-<jmbsvicetto> tampakrap: Hey, at this point in time I'm the "oldest" kde dev
-around ;)
-<tampakrap> patrick is special
-<tampakrap> yes, let's kick jmbsvicetto out
-<dilfridge> meow
-<johu> :D
-<jmbsvicetto> tampakrap: hehe, "special" ;)
-<jmbsvicetto> tampakrap: I've told you at this point I only care about amarok
-and related packages :P
-<tampakrap> johu: i'll talk to spatz, ok
-<johu> can somebody make me wise?
--*- jmbsvicetto blesses johu with wiseness
-<johu> thx
-<jmbsvicetto> :)
-<idella4> Patrick I suspect is soon to wake up
-<tampakrap> another topic for open floor:
-<dilfridge> !time bonsaikitten
-<willikins> dilfridge: I don't know where bonsaikitten is, (s)he should use
-!time set <Continent>/<City> to let me know
-<jmbsvicetto> idella4: I can finally make fun of Patrick at some hours without
-risking him replying to me ;)
-<idella4> China
-<idella4> when the Cat's away
-<tampakrap> I'm doing a kde release party here in prague a week after fosdem,
-probably at suse office, you are all invited
-<jmbsvicetto> idella4: He used to be more time online than me :)
-<idella4> he is on-line alot
-<idella4> see he is in my timezone
-<jmbsvicetto> tampakrap: It seems I'm too "heavy" to catch the fiber optic to
-your office :P
-<dilfridge> tampakrap: travelling already that weekend, sorry
-<jmbsvicetto> tampakrap: otherwise I would take your invitation and go check
-the "blankets" ;)
-<tampakrap> you loose
-<tampakrap> oldies
-<tampakrap> anyway, meeting closed
-<tampakrap> i'll do the summary, someone upload the log please
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120322.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120322.txt
deleted file mode 100644
index 63e1ef79b4..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120322.txt
+++ /dev/null
@@ -1,282 +0,0 @@
-<johu> so let the party begin
-<johu> 1. Roll call
--*- tampakrap here
-<johu> ABCD, alexxy, bonsaikitten, dilfridge, jmbsvicetto, mschiff, scarabeus,
-tampakrap, Thev00d00 
--*- dilfridge here
--*- alexxy +1
--*- mschiff here
--*- johu of course too
-<scarabeus> yo
-<johu> ok lets move on
-<johu> 2. Electing a new team leader
--*- johu nominates tampakrap
-<tampakrap> I decline
-<johu> other proposals?
-<tampakrap> yes, dilfridge
-<dilfridge> why not
-<johu> scarabeus are you interested?
-<alexxy> he he
-<alexxy> may be scarebeus?
-<tampakrap> johu: are you interested?
-<alexxy> =D
-<scarabeus> are you guys insane
-<scarabeus> why the hell i would like to be lead :)
-<scarabeus> i would have to start actually care
-<johu> scarabeus: because you are veteran
-<alexxy> scarabeus: didnt you care? or you turned to m$ win camp?
--*- tampakrap nominates johu and dilfridge
-<johu> ok lets vote if no other proposals show up
-<alexxy> scarabeus: so you agree for nomination?
-<scarabeus> nop not accepting :)
-<scarabeus> let someone new do it
--*- johu votes for dilfridge
--*- dilfridge votes for johu
-<alexxy> hmm
--*- creffett stays out of this one
-<alexxy> cycle dependency?
-<dilfridge> :D
-<creffett> maybe we could recompile one with USE="-doc" to fix it
--*- tampakrap votes for dilfridge
-<alexxy> +1 for dilfridge
-<mschiff> +1 dilfridge
-<scarabeus> dilfridge++
-<johu> ok 5:1
-<johu> bless the new lead
-<scarabeus> (nothing against johu i just want to see dilfridge enjoy my post
-:P)
-<dilfridge> :P
-<tampakrap> the post is mine
-<johu> thx tampakrap for your work as lead
-<dilfridge> thanks guys
-<tampakrap> you are welcome
-<tampakrap> congrats dilfridge!!
-<mschiff> yeah thanks tampakrap
--*- tampakrap kicks dilfridge
-<dilfridge> ow
-<alexxy> =P
-<johu> 3. Dropping RPATH from installed binaries (5 minutes)
-<johu>  * Short discussion- any objections to testing this in the overlay
-eclasses and later 
-<johu>    moving it to the main tree if it works?
-<alexxy> ghmm
-<alexxy> may it hert someone?
-<scarabeus> dropped rpath should work as is, so do it
-<mschiff> +1
-<scarabeus> doesn't debian disable it too
-<dilfridge> I dont see any problems
-<alexxy> hmmm
-<alexxy> +1! then
-<johu> lets give the removal a try from me
-<dilfridge> it's basically a patch in kdelibs afaik
-<dilfridge> to one of the cmake files
-<dilfridge> I can prepare that, I've looked into the thing before
-<dilfridge> (but have not tested the result before)
-<johu> why was it introduced?
-<dilfridge> it's default in the kde buildsystem
-<dilfridge> and imho a bug in cmake
-<alexxy> i think it was here for sloted kde versions
-<dilfridge> the logic is:
-<dilfridge> * add a RPATH entry for every library dir that is not in the
-system library directories *
-<dilfridge> the cmake bug, in my opinion, is:
-<dilfridge> * directories in ld.conf are not automatically considered as
-system library dirs, but only some static list of dirs *
-<dilfridge> our qt4 is in a "non-default path", usr/lib(64)/qt4
-<dilfridge> so cmake adds it to the RPATH
-<dilfridge> but that's not needed because we add it already to ld.conf with an
-environment file
-<dilfridge> s/ld.conf/ld.so.conf/
-<johu> any objectiosn from the crowd?
-<tampakrap> fine by me
-<alexxy> kill it =D
-<johu> ok we move on
-<dilfridge> we can introduce the patch with 4.8.2 and move it to the main tree
-then
-<johu> 4. Bugs (30 minutes)
-<johu>  * Remove hard dep on media-libs/phonon from kde-base/kdelibs
-<johu>   https://bugs.gentoo.org/show_bug.cgi?id=356681
-<johu>   https://bugs.gentoo.org/show_bug.cgi?id=388041
-<johu> dilfridge: yes its next week
-<dilfridge> ok I'll make the patch for 481, it should apply just the same to
-482
-<johu> qt-phonon will be removed with qt5...
-<mschiff> or should it bee || x11-libs/qt-phonon ?
-<dilfridge> upstream says "technically you can replace phonon with qt-phonon,
-but that's just stupid because you lose functionality"
-<dilfridge> (kde upstream)
-<johu> reasonable^
-<mschiff> so maybe ewarn if qt-phonon is there but accept it
-<scarabeus> we should go the other way
-<dilfridge> i think we get into a lot of trouble with not much gain
-<scarabeus> remove qt-phonon if desired
-<scarabeus> but not the other way around
-<tampakrap> exactly, I believe we should keep phonon as is
--*- johu votes for as is
--*- dilfridge votes for as is and close bug as wontfix
-<mschiff> I mean if someone knows what he does and *wants* qt-phonon?
-<mschiff> I wonder why Markos added that bug...
-<tampakrap> find me one first
-<johu> alexxy: your opinion?
-<mschiff> otoh if it will be dropped soon... ok +1 for keep it as is
-<alexxy> i dont think its good idea
-<alexxy> we should keep it to make kdelibs functional
-<johu> ok i will take of the bug after meeting summary
-<johu> * Eclass problem with handbook without LINGUAS.
-<johu>   https://bugs.gentoo.org/show_bug.cgi?id=372457
-<johu> anybody had a deeper look in to this?
-<dilfridge> no... it's pretty confusing code
-<scarabeus> the handbook code is quite magic :)
-<scarabeus> you need reavertm to explain that
-<johu> we need reavertm in every team meeting :D
-<tampakrap> skip for next meeting? mail reavertm?
-<johu> dilfridge: your first lead task
-<dilfridge> hehe
-<dilfridge> I'll try
-<dilfridge> next bug
-<johu> * Revise the change "semantic-desktop? -> semantic-desktop=".
-<johu>   Why was the change needed.
-<johu>   https://bugs.gentoo.org/show_bug.cgi?id=396491
-<alexxy> dilfridge: Mission directive for you: Find reavertm and make him fix
-handbook =D
-<johu> was before my time
-<dilfridge> scarabeus: ^ that's for you
-<scarabeus> johu: the goal was to enforce it everywhere
-<scarabeus> it is ment to be global useflag only
-<scarabeus> so set in make.conf or not set at all
-<scarabeus> some packages rely on semantic-desktop capablities in other ones
-<scarabeus> and this was easiest way how to ensure that user wont fuckup
-<johu> and this is valid today
-<tampakrap> I approve that change
-<scarabeus> it should still be
-<johu> ok tampakrap you are the volunteer for that bug
-<tampakrap> ack
-<johu> 5. Open floor (15 minutes)
-<dilfridge> kwin does not build anymore without opengl support (or at least
-gles)
-<johu> yes
-<scarabeus> tampakrap: so what with the stabilisation
-<dMaggot> fwiw, I'll become upstream of kportagetray and hopefully
-plasma-emergelog, I'll work on those next week and probably will release stuff
-<johu> scarabeus: i would suggest 4.8.2
-<dilfridge> dMaggot: cool
-<tampakrap> what stabilization?
-<tampakrap> ah, kde sc
-<dilfridge> what's still bad in 481?
-<tampakrap> I would suggest 4.8.1 asap, it has tons of bugfixes
-<tampakrap> many crashes as well
-<tampakrap> I would stabilize it asap imho
-<dilfridge> I mean I'm running it and it seems to work finr
-<mschiff> 4.8.2 has some important fixes too
-<dilfridge> fine
-<scarabeus> each version have important fixes
-<johu> the keywords not restored so far
-<scarabeus> question is: are those regressions since 4.7
-<tampakrap> definitely not
-<alexxy> scarabeus: no =D
-<dMaggot> scarabeus: in kmail, I think
-<alexxy> it only features
-<tampakrap> and keywords is johu's job :D
-<dilfridge> no, kmail got much more stable again
-<scarabeus> tampakrap: and you have the query for the bugs :)
-<alexxy> kmail works with lkml imap dir
-<scarabeus> kmail 4.8.1 is already heaven comapred with 4.7.4
-<alexxy> with 300k+ mails
-<scarabeus> trust me i am runnig stable kde now
-<scarabeus> and sometimes it does interesting stuff
-<tampakrap> don't trust him, he is running opensuse
-<alexxy> scarabeus: stable?!
-<dMaggot> lol
-<scarabeus> see my stabling of akonadi-server :)
-<tampakrap> anyway
-<scarabeus> to solve some bugs
-<johu> https://bugs.gentoo.org/show_bug.cgi?id=407709
-<alexxy> ahh opensuse =D
--*- tampakrap votes for 4.8.1 with passion
-<alexxy> its not stable =D
--*- dilfridge votes for 4.8.1
--*- johu votes for 4.8.2
-<scarabeus> johu: see this is regression, if 4.8.1 goes stable just shovel the
-patch to 4.8.1
-<scarabeus> alexxy: i run stable gentoo , hardened stable gentoo
-<alexxy> +1 for 4.8.1
-<scarabeus> Linux arcarius 3.2.2-hardened-r1 #8 SMP Thu Mar 22 12:23:02 CET
-2012 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux
-<alexxy> scarabeus: hardened desktop?
-<scarabeus> alexxy: yep, same as dilfridge
--*- johu will prepare stabilisation
-<alexxy> hmmm
-<alexxy> i may try it on laptop =D
-<scarabeus> johu: lemme know when you have list, i can showel it to my desktop
-and test
-<dilfridge> though I dont use hardened kernel yet... but I'll change that soon
-<alexxy> scarabeus: did you enabled grsec? or you use only pax?
-<johu> any other topics in the open floor?
-<creffett> am I allowed to bring one up?
-<dilfridge> sure
-<creffett> (if it hasn't been discussed at a meeting previously), what to do
-about all of the dbus-related test failures?
-<dilfridge> sigh
-<alexxy> its open floor so anyone allowed
-<dilfridge> ignore them?
-<creffett> because with a lot of them, we're patching out tests to the point
-where the test suites are pointless
-<dilfridge> honestly I dont know what to do there
-<scarabeus> alexxy: both
-<dilfridge> many of the testsuites are not even used by upstream devs
-<dilfridge> my personal suggestion would be:
-<mschiff> which is really ssad
-<johu> the best solution for the test failures woold be to get virtual-dbus
-eclass running
-<dilfridge> * if only one test / two tests of many fails, disable with patch
-<creffett> I was looking at that
-<dilfridge> * otherwise restrict
-<dilfridge> if you can make it work, that would be great
-<dilfridge> but I've given up hope a bit
-<dilfridge> also,
-<creffett> the problem with virtual-dbus is that we'd have to dig into the kde
-eclasses
-<creffett> because you can't run a bash command in the virtual-dbus
-environment
-<dilfridge> dbus is a communication tool, so the tests need something to talk
-to (i.e. a kde desktop environment)
-<dilfridge> which means the tests may want to start up an entire desktop
-environment in the virtual session
-<dilfridge> :|
-<tampakrap> I also have a quick topic when you finish with the dbus tests
-<creffett> I haven't got anything else on the matter
-<dilfridge> creffett: if you get this to work, great...
-<tampakrap> OK my topic:
-<creffett> dilfridge: I'll keep poking, no promises :P
-<dilfridge> tampakrap: go ahead
-<tampakrap> welcome new members: creffett (he has open bug), kensington ( he
-has open bug as well), dastergon (he doesn't have open bug yet, but he has the
-priviledge to be my friend)
-<dastergon> :)
-<johu> and welcome to scarabeus
-<scarabeus> another ugly greek :P
-<dilfridge> :) welcome!
--*- creffett waves
-<mschiff> welcome ;)
--*- mschiff has another little one: I am a bit short of time working in kde
-herd because we are building our new home here... but this will calm down in
-May, so I hope to have more time again then...
-<dastergon> scarabeus: the greek community is growing fast !!
-<tampakrap> yeah, now that I left :(
-<johu> any other topics?
-<tampakrap> another short one
-<tampakrap> I'm going to stop doing kde things and spend 99% of my gentoo time
-in infra
--*- dilfridge sets linewidth in tampakrap's irc client to 20chars
-<tampakrap> since mentees are shortened out and I don't have the leader
-position any more
-<johu> sad
-<johu> :*{
-<dilfridge> hey we'll miss you!
-<tampakrap> not really, you don't need me
-<johu> scarabeus: kick him from me in the office
-<scarabeus> :D
-<johu> 3
-<johu> 2
-<johu> 1
-<johu> meeting is over
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120419.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120419.txt
deleted file mode 100644
index a8b0471e5b..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120419.txt
+++ /dev/null
@@ -1,169 +0,0 @@
-<dilfridge> ok that's 5min warning... so let's do quick roll call
-<alexxy> i didnt tryed ppc
-<alexxy> =)
-<dilfridge> !herd kde
-<willikins> (kde) abcd, alexxy, dilfridge, jmbsvicetto, johu, mschiff, patrick, reavertm, scarabeus, tampakrap, thev00d00
-<alexxy> arm and mips yes
-<dilfridge> roll call please :)
-<tampakrap> here
-<Thev00d00> here
-<dilfridge> here
-<scarabeus> ay for the captain
-<dilfridge> :P
--*- kensington waves
--*- alexxy hides in superstrings continium =d
-<dilfridge> oh dear
-<dilfridge> p-branes
-<Thev00d00> lol
-<dilfridge> ok... since we dont actually have much agenda...
-<dilfridge> 1) what do we do with kde-4.8.2? file stablerequest as soon as the 30days are done?
-<tampakrap> too much load for the arch teams, I'd suggest to skip one version
-<Thev00d00> Personally I think we may as well wait for .3
-<dilfridge> ok
-<Thev00d00> Is it still due May 1st?
-<dilfridge> I'm fine with both
-<dilfridge> yes
-<dilfridge> so next stabilization would be 483 end of may
-<dilfridge> and we can maybe add some patches to single packages if there are super-ugly bugs
-<dilfridge> ok
-<dilfridge> anyone against "next is 483"?
--*- johu is here
-<scarabeus> i would like to ask you to open bugs for misc apps
-<scarabeus> they are often working in testing and completely weird in stable
-<scarabeus> so please jump over our herd packages and fill stablereqs where fit
-<dilfridge> sounds reasonable
-<johu> scarabeus: volunteer?
-<dilfridge> how is euscan doing with the kde packages?
-<johu> working good
-<scarabeus> euscan is great
-<scarabeus> but iksaf still didnt include my request to differ between versions in testing and in stable
-<scarabeus> eg green only when latest is in stable
-<scarabeus> otherwise orange
-<dilfridge> get it
-<dilfridge> good idea, no volunteer so far, we'll all have to do a bit each
-<scarabeus> dilfridge: i do it every week on mo/tue
-<scarabeus> but i cheat
-<scarabeus> i dont open bugs
-<dilfridge> :D
-<scarabeus> i ahve stable boxes
-<scarabeus> so i stable right away
-<tampakrap> you can automate that
-<dilfridge> ok
-<dilfridge> there is one more question from me, and then I have all off my heart:
-<dilfridge> 3) is anyone against a stablereq for calligra-2.4.0 ? (after the magic 30days)
-<dilfridge> no bug reports so far
-<johu> NO please do it
-<johu> lets get rid of the koffice foo
-<dilfridge> and it would be awesome to get rid of koffce
-<tampakrap> is it dead?
-<scarabeus> koffice ist kaput
-<tampakrap> there were some discussions to move it to SC
-<dilfridge> it is life, Jim, but not as we know it...
-<johu> did you read in the last year any news update in koffice?
-<dilfridge> more like zombie
-<dilfridge> even the last blog posit of tzander was a year ago
-<dilfridge> tampakrap: that suggestion led to a lot of opposition, it was seen as some scheme to give koffice a more official status than calligra
-<dilfridge> but I stopped following the fuss at some point
-<dilfridge> ok seems like nobody opposes
-<dilfridge> anyone else has anything else?
-<johu> yes kde481 is table
-<johu> :)
-<dilfridge> hehe
-<johu> at least for amd64, x86
-<scarabeus> yeah pretty nice chair it is
-<johu> 4) arm stable in kde 49x?
-<tampakrap> is qt stable in arm?
-<johu> 472
-<johu> 474 in porgress
-<dilfridge> johu: I actually like the idea, but I dont have an arm machine that could run kde decently
-<johu> 48x not decided yet
-<johu> hm ok nvm
-<dilfridge> I mean, the number of arm gadgets will go up more and more
-<dilfridge> while ppc machines are falling apart
-<scarabeus> we can do this for sabayon folks
-<dilfridge> we could also think about packaging plasma-active
-<tampakrap> how about asking in a blog post for volunteers?
-<scarabeus> i dont see sane to run gentoo on arm machines right of the box now :)
-<dilfridge> scarabeus: at least kde runs pretty well, people say (with hw graphics accel)
-<dilfridge> tampakrap: what should the volunteers do exactly?
-<tampakrap> arch testing
-<tampakrap> obviously :)
-<dilfridge> ok
-<johu> dilfridge: do you got any answer from reavertm abouy the open issues/questions?
-<dilfridge> yeah well it's an idea
-<dilfridge> johu: no
-<johu> hm :-/
-<dilfridge> tampakrap: I'll ask the arm guys about this, if they like the idea I'll blog
-<dilfridge> ah yes I remember one more thing
-<scarabeus> what you guys want from Maciej?
-<dilfridge> 5) the ewarns about the tar commands, they are completely useless even for devs. can they go away again?
-<tampakrap> ask reavertm :)
-<johu> :)
-<scarabeus> they can go away
-<johu> scarabeus: most questions are eclass related
-<scarabeus> :D
-<scarabeus> poor you :P
-<scarabeus> but wait were there someone else with me working on that
-<scarabeus> i know, JORGE!
-<dilfridge> bug 358059
-<willikins> dilfridge: https://bugs.gentoo.org/358059 "cmake-utils.eclass PREFIX is not defined"; Gentoo Linux, Eclasses and Profiles; CONF; meka:kde
-<dilfridge> that is actually the only one left
-<dilfridge> all the rest is imho done
-<johu> linguas
-<johu> or i missed something?
-<dilfridge> kensington has found the problem I think
-<dilfridge> we just need to doublecheck the solution
-<scarabeus> dilfridge: ack on the patch
-<johu> ok
-<scarabeus> it actually fixes stuff i wrote there in first place :D
-<tampakrap> it was creffett
-<dilfridge> ok sorry
-<dilfridge> scarabeus: I'll try to understand it myself over the weekend, and then...
-<dilfridge> |:]
-<scarabeus> basically now the prefix is defined on 5 places
-<scarabeus> this defines it on one place
-<scarabeus> and then just uses such var
-<scarabeus> so it is correct
-<scarabeus> only weird line is this one:
-<scarabeus> -SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output directory for libraries")
-<scarabeus> +SET (CMAKE_INSTALL_LIBDIR ${PREFIX}/${libdir} CACHE PATH "Output directory for libraries")
-<scarabeus> "but when i think of it ; it looks correct
-<dilfridge> we can always test in overlay
-<scarabeus> nah rest of the patch is harmless
-<scarabeus> just check one package if it puts shit into /usr/usr/lib64
-<scarabeus> and if not it is correct
-<dilfridge> hehe
-<dilfridge> ok
-<dilfridge> anything else to discuss?
-<johu> 6) open floor
-<tampakrap> SLED will have kde4.8 "soon"
-<dilfridge> cough
-<dilfridge> cough
-<dilfridge> ok
-<dilfridge> that means they consider kdepim-4.8 stable enough?
-<tampakrap> isn't it? :)
-<dilfridge> on my work desktop it's ok
-<scarabeus> tampakrap: i dont think there is plan to build kdepim too :P
-<tampakrap> it's built already
-<tampakrap> the obs repo is linked from the opensuse 12.1 one
-<johu> suse ich will sie nicht nimm duse
-<dilfridge> lol
-<dilfridge> it
-<dilfridge> seems
-<dilfridge> like
-<dilfridge> we
-<dilfridge> can
-<dilfridge> close
-<dilfridge> the
-<dilfridge> meeting?
-<johu> next time i have to organize the meeting it seems
-<johu> :P
-<dilfridge> hehe thanks in advance!
-<tampakrap> no, give it to a new guy
-<johu> who writes summary?
-<dilfridge> whoever asks first :P
-<johu> go away
-<dilfridge> ok I'll do it
-<dilfridge> cheers & thanks everyone
-<johu> thx for chairing
-<scarabeus> byes
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120517.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120517.txt
deleted file mode 100644
index 6a8775782d..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120517.txt
+++ /dev/null
@@ -1,324 +0,0 @@
-<kensington> 1. roll call
-<kensington> !herd kde
-<willikins> (kde) abcd, alexxy, creffett, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, tampakrap, thev00d00
--*- johu is here
--*- dilfridge here
--*- creffett is somewhere around here
--*- kensington of course
-<kensington> 2. Add LINGUAS support to cmake-utils.eclass
-<alexxy> kensington: looks like itterative process which should coverage
-<dilfridge> hehe
--*- alexxy here
-<kensington> :P
-<dilfridge> err there's one more part for 1. :)
-<dilfridge> first of all a big welcome for our new team members kensington and creffet :D
--*- creffett waves
--*- johu applaudss
-<dilfridge> ok that was it from me :D
-<johu> kensington: what would your linguas implementation cover?
-<creffett> kensington, how did you forget to add "make everyone congratulate us" to the agenda?
-<kensington> creffett: I wrote that before we finished recruiting, so that's my excuse :P
-<kensington> basically, just copy straight out of qt4-r2, so need to stick an ugly loop adding linguas_X in packages that need them
-<kensington> *no need
-<kensington> for x in ${LANGS}; do
-<kensington>         IUSE+=" linguas_${x}"
-<kensington> done
-<johu> hm ok would reduce some ebuild code
-<kensington> any objectsion to that?
-<johu> is there an standard handling for the linguas handling planed?
-<dilfridge> no idea
-<kensington> it would be nice, but I do not know of any
-<dilfridge> but the code looks everywhere the same
-<dilfridge> just use a "safely unique" variable name for x and unset it afterwards again
-<kensington> do we need to send to -dev about it too?
-<johu> i have no objections
-<creffett> no objections
-<dilfridge> no objections... hic...
-<kensington> 3. Live KDE ebuilds are unconditionally test restricted
-<alexxy> btw may be we can write generic linguas.eclass?
-<johu> kensington: but gentoo-dev can not hurt
-<johu> alexxy: there was already a discussion about that on -dev?!
-<dilfridge> alexxy: nice idea but that needs to be bikeshedded on -dev
-<kensington> generic eclass would be nice, but I don't know if there's much beyond those three lines that are portable between build systems / packages ?
-<alexxy> johu: yep it was about a year ago
-<dilfridge> probably not.
-<dilfridge> ah ok, dont remember
-<creffett> re 3: I say leave them as restricted, because we have enough trouble already with the official release tests
-<dilfridge> well... anyway. I think whoever runs live kde with tests seriously needs some disruptions.
-<kensington> :D
-<dilfridge> but, from a practical point of view, creffett is right
-<alexxy> he he
-<alexxy> i use 9999 on my laptop
-<alexxy> but i didnt enabled tests =D
-<johu> i would say enable them with the magic var!
-<johu> its not a bug deal
-<dilfridge> I_REALLY_REALLY_KNOW_WHAT_I_AM_DOING
-<johu> big
-<creffett> haha
-<kensington> dilfridge: I like that idea :P
-<johu> ynauv
-<johu> yet not another useless variable^
-<dilfridge> how about we just add it to the usual I_KNOW_WHAT_I_AM_DOING ?
-<dilfridge> who sets this should be able to handle the fallout
-<johu> test enable on  I_KNOW_WHAT_I_AM_DOING
-<alexxy> dilfridge: better to use YEP_I_REALY_REALY_SURE_THAT_I_WANT_BIG_HEADACHE
-<dilfridge> ... AND_I_PROMISE_TO_NEVER_EVER_FILE_BUGS
-<johu> can we become serious? :)
-<dilfridge> Yessir. :)
-<reavertm> I_KNOW_WHAT_I_AM_DOING___SERIOUSLY
-<johu> <johu> test enable on  I_KNOW_WHAT_I_AM_DOING
-<dilfridge> agreed
-<kensington> I agree with johu
-<alexxy> +1
-<reavertm> sounds fine, +1
-<johu> reavertm nice to see you sir
-<johu> :)
-<kensington> 4. KDE 4.8 stabilization and powerpc
-<johu> ok thats my topic
-<johu> i added it because gcc47 was dep to keyword it
-<reavertm> elaborate on it please :)
-<johu> but JoseJX told me some hours ago that he will keyword it tonight
-<johu> it was a mistake with gcc47
-<dilfridge> cool
-<johu> but they need qt 481
-<johu> i think b) can be seen as obsolote
-<JoseJX> Hey
-<dilfridge> ok sounds good
-<JoseJX> I'm the PowerPC rep I guess
-<dilfridge> hey JoseJX :)
-<johu> but we should discuss if ppc64 make sense
-<JoseJX> I'd really like to not drop keywords if possible
-<johu> JoseJX: whats your opinion about that?
-<JoseJX> KDE still runs well on my G5
-<JoseJX> I can see the argument for dropping ppc64 from stable, but keeping unstable, since we don't really have the manpower to handle it.
-<JoseJX> There's also the fact that most of our users are not running ppc64, even on ppc64 machines
-<JoseJX> Most are set up with a 32bit userland (the ppc keyword)
-<dilfridge> I think that already happened some time ago, at the moment we only have stable "amd64 ppc x86"
-<johu> scarabeus said that ppc64 are serve machines
-<JoseJX> dilfridge: I think that's reasonable
-<dilfridge> but if the gcc-4.7 problem is gone, we should try to keep things as they are (ppc ~ppc64)
-<JoseJX> That's what I'm aiming for now
-<JoseJX> ppc/~ppc are definitely fine
-<johu> but makes ppc64 realy sense?
-<JoseJX> I'm still working on testing ~ppc64
-<johu> thats the first question we should find a answer
-<JoseJX> I do know that we might have some TOC issues, which might make this all moot anyway on ppc64
-<JoseJX> But those will be fixed when gcc-4.7/4.8 is ready
-<dilfridge> is there any ~1line summary for that? /me does not have a clue
-<JoseJX> I'll try to explain
-<JoseJX> ELF on ppc builds tables of function calls, but on ppc64, the tables get too big and the TOC runs out of space because the pointers are 2x bigger.
-<johu> but gcc-4.7 stable will hapen maybe 2013...
-<JoseJX> Basically linking > 32MB (I think that's the size) doesn't work on ppc64 because the jumps are too big
-<JoseJX> We can work around it with --minimal-toc and that's what we have been doing.
-<JoseJX> That's the short version
-<johu> JoseJX: are there lot of desktop systems with ppc64? 
-<dilfridge> ok... what's the problem with (for kde) global --minimal-toc ?
-<JoseJX> dilfridge: None that I'm aware, but ranger would be the better one to ask.
-<dilfridge> ok
-<JoseJX> johu: Honestly? No.
-<JoseJX> johu: I run it on my G5, but I'm sure I'm an edge case
-<johu> ok, makes no sense to me to keep ppc64 then
-<dilfridge> johu: but ~ppc64 is not really a problem...
-<JoseJX> I think that's where I'm at too
-<dilfridge> anyone else has an opinion?
-<JoseJX> I agree there's no need for stable keywords, but if possible, I'd like to keep the unstable ones.
-<johu> ok please vote on keep ~ppc64:
-<johu> -1
-<dilfridge> +1
-<alexxy> 0
-<kensington> 0
-<alexxy> or keep ~ppc64
-<alexxy> i dont currently have any ppc hw
-<creffett> 0
-<alexxy> so i cannot test
-<johu> meh
-<johu> seems we cant find a decision here so lets keep it...
-<JoseJX> Well, how about this. If everything is working when I do the ~ppc keywording later today, I'll also mark ~ppc64. If not, I'll let it drop.
-<kensington> +1
-<dilfridge> +1
-<johu> i will raise this issue again for sure ;)
-<alexxy> +1
-<alexxy> =D
-<reavertm> why not, +1
-<JoseJX> johu: That's fair. I don't see what dropping unstable keywords helps with though?
-<johu> JoseJX: because server systems != desktop systems
-<dilfridge> I've tried already to build a ppc/ppc64 qemu chroot but right now this fails because of a qemu-static bug
-<johu> and KDE is for sure a desktop/tablet env
-<JoseJX> johu: Only new ppc64 machines are server systems, but in the past, we had the PS3/G5 both which definitely were not server systems
--*- dilfridge thinks mips tablet and runs fast...
-<creffett> did someone say mips? :D
--*- creffett hands dilfridge a cobalt raq2
-<kensington> keywords all the archs!
-<johu> JoseJX: ok i think you can do your job tonight ;)
-<johu> JoseJX: and big thanks for that
-<JoseJX> Okay! Thanks guys. I have to get back to work, but I'll probably be doing the keywording around midnight EST.
-<JoseJX> Just for a heads up!
-<johu> JoseJX: if the work load is to big to stable 483 you can wait for 484
-<JoseJX> johu: No worries
-<JoseJX> When is 4.8.4 expected?
-<JoseJX> Would it be better for us to wait?
-<johu> 484 is tagged end may
-<dilfridge> it's always one month later
-<JoseJX> In either case, we need to go forward with the unstable keywords first, so that won't change
-<johu> so we will start with stable mid june
-<dilfridge> makes sense
-<JoseJX> Okay, we'll probably target 4.8.4 for stable on ppc then, figure one month in unstable gets us to June anyway
-<dilfridge> yes
-<JoseJX> As long as that's fine with you guys
-<johu> its totally finee
-<dilfridge> sure
-<JoseJX> Great!
-<kensington> :)
-<johu> JoseJX: thanks for being here
-<johu> kensington: procede pls
-<JoseJX> No worries, later!
-<kensington> 5. Bugs
-<kensington> bug #380899
-<willikins> kensington: https://bugs.gentoo.org/380899 "Trying to change full name in KDE System Settings results in error or crash"; Gentoo Linux, KDE; UNCO; gentoobugzilla:kde
-<kensington> there is a workaround that disables that feature from ubuntu, do we want to apply that? (looks like upstream doesn't care about the bug)
-<johu> kensington: i saw a other solution, fallback to nickname on reviewboard
-<johu> kensington: you have good connections to upstream try to talk to them
-<kensington> johu: if we are thinking of the same patch, it didn't work
-<kensington> still crashed
-<dilfridge> hmm
-<dilfridge> seems like the feature does not work, why not disable it
-<dilfridge> I suspect once the code is fixed our patch will not apply anymore and we will notice
-<johu> https://git.reviewboard.kde.org/r/104965/
-<johu> kensington: this one?^
-<kensington> johu: no, I was thinking of a different one, sorry
-<dilfridge> does that really fix the same problem?
-<johu> i am not realy sure
--*- dilfridge confused
-<kensington> I don't think so, the issue from the bug is systemsettings hangs because it can't talk with chfn properly
-<johu> i would suggest try to talk to upstream and if you get no good answer or proper response disable it
-<kensington> +1
-<johu> say 2 weeks time limit
-<dilfridge> ok who's going to do it?
-<kensington> ok I will
-<johu> ok next pls
-<kensington> bug #410347
-<willikins> kensington: https://bugs.gentoo.org/410347 "app-cdr/k3b: use media-libs/musicbrainz:3 instead of :1"; Gentoo Linux, Applications; CONF; pacho:kde
-<dilfridge> reavertm: you probably know more about this one
-<creffett> we can probably just drop musicbrainz altogether
-<reavertm> last time I checked there was no musicbrainz:3 support at all in k3b (but it was long time ago)
-<dilfridge> well k3b has not changed much lately
-<creffett> mhm, that's what the comments on the bug indicate
-<reavertm> (I mean, there's api difference between those two)
-<kensington> I agree with creffett, I couldn't find any evidence that musicbrainz is actually being used anymore
-<dilfridge> in gentoo terms k3b would be maintainer-needed
-<johu> :1 is obsolete
-<johu> drop it
-<dilfridge> ack
-<kensington> bug #405181
-<willikins> kensington: https://bugs.gentoo.org/405181 "dev-util/cmake: FindPythonLibs behaviour broken by Gentoo patches"; Gentoo Linux, KDE; CONF; gentoo-bug:kde
-<dilfridge> meh
-<johu> i hate it
-<dilfridge> the best way woudl be to
-<dilfridge> * remove the patches
-<dilfridge> * and force cmake onto a specific python version via commandline defines
-<dilfridge> that _should_ work
-<dilfridge> but I have not tried yet
-<kensington> sounds good, should we try that then?
-<dilfridge> yes, but no guarantees it'll work
-<kensington> bug #410139
-<willikins> kensington: https://bugs.gentoo.org/410139 "kde-misc/networkmanagement-0.9.0 and kde-misc/networkmanagement-0.8_p20110714 wrong doc dir specified"; Gentoo Linux, KDE; UNCO; gritoo:kde
-<johu> cant never reproduce this...
-<kensington> ditto
-<kensington> couldn't see how it might be run into, looking at the eclass :(
--*- creffett guesses funny user settings
-<dilfridge> we could ask for the environment and the eclass debug log
-<johu> maybe it was fixed with the eclass changes that we introduced?
-<dilfridge> but I dont have any other ideas
-<dilfridge> (maybe funny variables in make.conf?)
-<dilfridge> ok I can try to take care of this one, it's obscure enough to be interesting
-<johu> RESOLVE NEEDINFO
-<dilfridge> hehe
-<kensington> bug #383733
-<willikins> kensington: https://bugs.gentoo.org/383733 "kde-misc/interceptor - KDE4 Plasmoid - intercept (catch) the log info from the syslog"; Gentoo Linux, Ebuilds; CONF; fitzadam:maintainer-wanted
-<creffett> this one's mine
--*- johu dont need the package and have no interest in it :P
-<creffett> basically, it's a plasmoid that requires an init script and modifications to the system's syslog configuration
-<dilfridge> I also thinks it's overkill and potential security problem
-<creffett> and there's continuing trouble with using the FIFOs required
-<creffett> so, I suggest we resolve wontfix
-<dilfridge> but we could show it to recruiters as replacement for w...
-<kensington> haha
-<creffett> nah, it's not quite _that_ bad
-<johu> rating 65%
-<dilfridge> creffett: not talking about your ebuild, just about the general problem :D
-<kensington> wontfix, or just take us off cc and suggest sunrise?
-<dilfridge> latter
-<dilfridge> maybe someone will pick it up
-<kensington> bug #406353
-<willikins> kensington: https://bugs.gentoo.org/406353 "dev-util/cmake-2.8.6-r4 - stop Xvfb after failed test phase"; Gentoo Linux, KDE; UNCO; toralf.foerster:kde
-<dilfridge> good catch
-<kensington> if tests die, virtualx can't kill Xvfb it started
-<kensington> will be a problem too for virtualdbus (coming soon!)
-<johu> is there any phase we could use to clean it up?
-<dilfridge> i'm asking in #-portage
-<creffett> kensington: are you making any progress on virtualdbus?
-<creffett> I looked at it some, but couldn't figure out a way to make it work for bash commands
-<kensington> I had the same problem, but it seems to work by just exporting the appropriate envvars
-<creffett> oh?
-<creffett> I'll talk to you about it later, then, but I'd love to hear your progress
-<kensington> creffett: this is my work in progress http://dpaste.com/749504/ which is working reliably for the package I've been testing with, systemsettigns
-<creffett> cool, I'll have a look later
-<dilfridge> k
-<dilfridge> seems we might need some input from zmedico et al here
-<dilfridge> let's see if any of them responds
-<johu> next topic!
-<kensington> 5. open floor
-<johu> dilfridge: whats the arm state? You wanted to ask the guys
-<dilfridge> no really definite response yet
-<dilfridge> only people that replied did not have fast enough machine
-<johu> hm
-<dilfridge> (remember this is many gadgets and embedded stuff)
-<johu> ok postponed
-<kensington> my open floor is ^, I'll bring it up again when there's no more calls to ugly_hack()
-<dilfridge> hehe
-<kensington> anyone else?
--*- dilfridge hears the silence
-<johu> yes
-<dilfridge> kde-4.9 beta is coming out soon
-<johu> kde 483 stable and the last outstanding bug
-<johu> the dav foo!
-<dilfridge> right
-<dilfridge> anyone has a dav-based calendar server?
-<johu> do we want to stable -r2 which have the upstream "fix" but no positive feedback or just use r0 which is fucked up for sure
-<dilfridge> -r2 in case of doubt imho
-<dilfridge> someone will be unhappy either way
-<kensington> some feedback on the upstream bug saying it's still not fixed, but it might be a different but similar bug
-<johu> yes i read this too
-<johu> the other people have different problems
-<kensington> +1 on -r2 then
-<johu> so if noone raise objections i give ago the go tomorrow after keywording ppc/ppc64 is done...
-<dilfridge> awesome
-<kensington> cool, anything else?
--*- johu needs more beer
-<kensington> meeting over then :P
-<johu> organization question, who writes the  summary?
-<dilfridge> +1
-<dilfridge> always whoever asks first :D
-<johu> always johu i guess
-<johu> creffett: make a draft i review it!
-<dilfridge> next time creffett is chairing
-<dilfridge> :D
-<johu> dilfridge: if 7 days over i do it for sure on my own as last time with you lazy guy :P
-<creffett> dilfridge: out of contact at the time, sorry
-<dilfridge> hehe
-<dilfridge> creffett: ah yes have a great time, when does your trip start?
-<creffett> which reminds me: I'm disappearing from the 20th through june 15th
-<creffett> ^^
-<johu> creffett: set your devaway then please
-<creffett> I will
-<creffett> and I'll forward my gentoo mail to the email address I get to use on the boat which doesn't cost me money to use, but I won't be committing or anything
-<johu> enjoy your trip
-<creffett> I'll try
-<johu> and dont think about gentoo in this time
-<johu> we will save some bugs for you
-<creffett> thanks :P
-<kensington> s/save/make/
-<johu> 3
-<johu> 2
-<johu> 1
-<johu> end
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120621.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120621.txt
deleted file mode 100644
index f34603ee94..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120621.txt
+++ /dev/null
@@ -1,143 +0,0 @@
-[21:08:37] <dilfridge> !herd kde
-[21:08:39] <willikins> (kde) abcd, alexxy, creffett, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, thev00d00
-[21:08:40] <scarabeus> ok
-[21:08:41] <dilfridge> roll call
-[21:08:49] -*- alexxy 
-[21:08:52] -*- dilfridge 
-[21:08:56] -*- scarabeus 
-[21:09:00] -*- tampakrap :)
-[21:09:06] <dilfridge> :)
-[21:09:14] <alexxy> (:)
-[21:09:16] <scarabeus> dilfridge: so you have two lazy ex-leads :D
-[21:09:19] <dilfridge> hehe
-[21:09:31] <dilfridge> not counting those so lazy that they dont attend :D
-[21:09:46] <scarabeus> alexxy: btw summer camp looks intruging so far, working on convincing gf to go with me there :P
-[21:10:05] <tampakrap> scarabeus: I said I accept
-[21:10:08] <alexxy> scarabeus: if you need invitation i can create one
-[21:10:26] <scarabeus> tampakrap: wanna go to russia mid summer to see gentoo summer camp?; i forgot to ask ya at office
-[21:10:41] <scarabeus> tampakrap: and for the above sentence you can say goodbye to your left arm
-[21:10:47] <dilfridge> hehe
-[21:10:56] <dilfridge> ok let's do this quick and painless
-[21:11:04] <dilfridge> point 2)
-[21:11:10] <dilfridge> move 484 to tree
-[21:11:35] <alexxy> dilfridge: move it =) with reverted changes to kdelibs
-[21:11:37] <dilfridge> i suggest *revert the kdelibs commit that needs newer soprano, *move to tree, *stable as usual if nothing happens
-[21:11:39] <dilfridge> yes
-[21:12:06] <dilfridge> adn scarabeus said same, so basically we have 100% agreement
-[21:12:12] <dilfridge> cool
-[21:12:16] <dilfridge> next point
-[21:12:21] <dilfridge> 3) 490
-[21:12:31] <dilfridge> so far I'm really happy with 4.8.90
-[21:12:32] <alexxy> it should be in tree
-[21:12:35] <alexxy> as ~arch
-[21:12:37] <dilfridge> what do you think?
-[21:12:49] <alexxy> i'm running it on laptop
-[21:12:52] <dilfridge> me too
-[21:12:54] <scarabeus> we agreed to add last rcs only back
-[21:12:55] <alexxy> its pretty stable
-[21:13:15] <dilfridge> scarabeus: ? dont understand
-[21:14:18] <scarabeus> few year back we decided to add only last rc if desired
-[21:14:36] <dilfridge> scarabeus: nah I dont mean 4.8.90, but 4.9.0
-[21:14:57] <dilfridge> and that should be fine for sure
-[21:15:00] <scarabeus> ah sorry for the fuzz then
-[21:15:02] <scarabeus> yep
-[21:15:11] <dilfridge> ok that's 3 yes :)
-[21:15:11] <scarabeus> i can give ya spin on stable when you decide to roll that
-[21:15:19] <dilfridge> yeah
-[21:15:30] <dilfridge> next point
-[21:15:34] <dilfridge> 4) udisks2
-[21:15:53] <dilfridge> nothing really to decide yet, but please test
-[21:16:00] <dilfridge> 4.8.90 and later has the patch
-[21:16:13] <dilfridge> Philantrop says it has performance issues
-[21:16:17] <alexxy> it works (tm)
-[21:16:22] <dilfridge> ok
-[21:16:33] <dilfridge> worst case we revert that in 490
-[21:16:46] <alexxy> dilfridge: well if we ask pva to test, he will find tonns of bugs
-[21:16:48] <Philantrop> alexxy: Check your .X.errors or whatever it's called. Doesn't it have a *ton* of devices being listed?
-[21:16:50] <dilfridge> hehe
-[21:16:59] <alexxy> since he has funny karma
-[21:17:03] <dilfridge> devnum: 66305 dev file: "/dev/md127p2" 
-[21:17:03] <dilfridge> devnum: 64512 dev file: "/dev/dm-0" 
-[21:17:03] <dilfridge> devnum: 66306 dev file: "/dev/md127p3" 
-[21:17:03] <dilfridge> devnum: 64512 dev file: "/dev/dm-0" 
-[21:17:28] <dilfridge> Adding device "/org/freedesktop/UDisks2/block_devices/md127p3" 
-[21:17:28] <dilfridge> Adding device "/org/freedesktop/UDisks2/block_devices/md127p4" 
-[21:17:28] <dilfridge> Adding device "/org/freedesktop/UDisks2/block_devices/nbd0" 
-[21:17:28] <dilfridge> Adding device "/org/freedesktop/UDisks2/block_devices/nbd1" 
-[21:17:30] <dilfridge> and so on 
-[21:17:31] <Philantrop> dilfridge: Exactly. That stuff slows down file requesters pretty badly if you have more than a handful.
-[21:17:32] <alexxy> well i have all my lvm2 volumes listed
-[21:17:49] <alexxy> ~12 volumes
-[21:17:52] <alexxy> on my laptop
-[21:18:05] <Philantrop> dilfridge: That happens *every* time a file requesters is opened.
-[21:18:11] <alexxy> and i cant say that adding usb flash drive works slow
-[21:18:14] <dilfridge> let's hope the RH guys fix it up, they should be interested in it too
-[21:18:29] <dilfridge> I'll watch the fedora repo really hard
-[21:18:34] <Philantrop> alexxy: You don't notice any difference in performance?
-[21:18:59] <alexxy> Philantrop: yep i dont see any *visible* difference
-[21:19:10] <Philantrop> alexxy: Interesting. Which KDE version?
-[21:19:19] <alexxy> 4.8.90
-[21:19:26] <Philantrop> alexxy: Hm... 4.8.4 here...
-[21:19:42] <Philantrop> *4.8.3 actually.
-[21:19:57] <dilfridge> well... let's just test... but one user on #gentoo-kde also reported slowdown
-[21:19:59] <alexxy> 4.8.4 has same kdelibs
-[21:20:20] <Philantrop> alexxy: True. Are you guys applying any other special patches?
-[21:20:26] -*- dilfridge wonders what happens if you still have /dev/fd0
-[21:20:28] <alexxy> dilfridge: its like infamous kernel iowait bug
-[21:20:41] <alexxy> it may depend on hw
-[21:20:44] <dilfridge> not really, no, imho
-[21:20:52] <Philantrop> dilfridge: cannot access /dev/fd0: No such file or directory
-[21:20:59] <alexxy> Philantrop: yep i have some special patches in kernel
-[21:21:13] <alexxy> but they are for mm subsystem
-[21:21:20] <Philantrop> dilfridge: Do you notice any slowdown?
-[21:21:21] <alexxy> like memory deduplication
-[21:21:24] <alexxy> and so on
-[21:21:32] <Philantrop> alexxy: Ok, and for KDE?
-[21:21:45] <dilfridge> I only upgraded today, so the kile that I started with the agenda was the first app to use it...
-[21:21:49] <alexxy> kde from kde overlay
-[21:21:55] <alexxy> nothing special
-[21:22:20] <Philantrop> alexxy: Weird... I wonder what's causing it then.
-[21:22:27] -*- alexxy uses texmaker
-[21:22:33] <dilfridge> the list of patches for kdelibs looks harmless
-[21:23:10] <dilfridge> ok anyway
-[21:23:14] <dilfridge> next point
-[21:23:21] <dilfridge> 5) 
-[21:23:23] <dilfridge> bugs
-[21:23:33] <dilfridge> I think we should postpone this since kensington is not here
-[21:23:46] <dilfridge> any objections?
-[21:24:24] <dilfridge> seems not
-[21:24:47] <dilfridge> which brings us already to the very last point,
-[21:24:51] <dilfridge> 6) open floor
-[21:24:56] <dilfridge> anyone has anything to discuss?
-[21:25:04] -*- dilfridge gets a sandwich, brb
-[21:25:10] <tampakrap> yes
-[21:25:37] <tampakrap> don't forget the gentoo miniconf please, I desperatedly need speakers
-[21:25:58] <dilfridge> yeah
-[21:26:23] <dilfridge> is there already anything desktoppy?
-[21:26:49] -*- alexxy can talk something about hpc and clusters
-[21:26:50] <tampakrap> whatever you want
-[21:26:59] <alexxy> but i'm not sure if i will take part
-[21:27:03] <tampakrap> I'd prefer a workshop where people can participate
-[21:27:08] <tampakrap> but a talk is also fine
-[21:27:09] <dilfridge> i'll come, just not sure about time for preparation
-[21:27:12] <tampakrap> we have our own room
-[21:27:39] <alexxy> tampakrap: simple workshop - how to crate smal cluster with rm in 30 minuts
-[21:27:40] <alexxy> =)
-[21:27:46] <dilfridge> packaging plasmoids for fun and profit
-[21:28:30] <tampakrap> both sound awesome
-[21:29:09] -*- scarabeus haz to cook, cya laterz lads
-[21:29:19] <dilfridge> ok lets think about this a bit, but we will organize something for sure
-[21:29:50] <tomkap> alexxy: +1
-[21:30:15] -*- alexxy still not sure about visum
-[21:30:20] <dilfridge> or I could tell something about LinuxGPIB and lab device control with Perl, but that's not for participation, only coolness factor
-[21:30:44] <dilfridge> yeah the old problem :|
-[21:31:21] <alexxy> actualy its simple one =)
-[21:31:32] <dilfridge> ?
-[21:32:24] <dilfridge> anyway
-[21:32:27] <dilfridge> anything else?
-[21:33:08] -*- dilfridge listens to the silence
-[21:33:42] <dilfridge> perfect
-[21:33:47] <dilfridge> that's it then cheers!
-[21:34:02] <dilfridge> meeting closed
-[21:34:13] <dilfridge> i think we just made a new speed recoed
-[21:34:19] <dilfridge> :)
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120816.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120816.txt
deleted file mode 100644
index c6ea614a22..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120816.txt
+++ /dev/null
@@ -1,539 +0,0 @@
-<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
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120927.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120927.txt
deleted file mode 100644
index 256c308bc0..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20120927.txt
+++ /dev/null
@@ -1,260 +0,0 @@
-[21:02:16] <johu> http://wiki.gentoo.org/wiki/Project:KDE/Meeting/2012-09
-[21:02:21] <johu> !herd kde
-[21:02:22] <willikins> (kde) abcd, ago, alexxy, creffett, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, tampakrap, thev00d00
-[21:02:25] <johu> 1. roll call
-[21:02:26] <creffett> present
-[21:02:32] <ago> hello boys
-[21:02:33] -*- johu here too
-[21:03:56] --> scarabeus (~scarabeus@gentoo/developer/flyingspaghettimonster/scarabeus) hat #gentoo-meetings betreten
-[21:04:03] <scarabeus> so what is turnabout today?
-[21:04:20] <johu> 4 ppl as last time...
-[21:04:24] <creffett> nice cloak.
-[21:05:06] <johu> if i look to the herd member list there is something wrong
-[21:05:17] <creffett> I even announced it this time
-[21:05:22] <johu> iknow
-[21:05:29] <scarabeus> well some cant attend, like jorge
-[21:05:35] --> tampakrap (~tampakrap@gentoo/developer/tampakrap) hat #gentoo-meetings betreten
-[21:05:38] <tampakrap> ahoj
-[21:05:43] <scarabeus> nazdar
-[21:05:58] <tampakrap> nadrazi
-[21:06:16] <scarabeus> thats, railwaystation
-[21:06:20] <tampakrap> I know
-[21:06:23] <scarabeus> good
-[21:06:35] <tampakrap> pristi zastavka, nadrazi liben
-[21:06:45] <tampakrap> or pristi stanice
-[21:06:54] <tampakrap> never managed to separate them
-[21:07:12] --> B-Man (~aaron@108.171.119.130) hat #gentoo-meetings betreten
-[21:07:13] <scarabeus> they are synonyms
-[21:07:16] <scarabeus> so they are the same
-[21:07:23] <scarabeus> but mhd says zastavka
-[21:07:32] <tampakrap> the teacher told me that one is the subway station and the other is ground station (metro, bus)
-[21:07:57] <scarabeus> tehcnically stanice could be a building and zastavka something small like the box with the sign
-[21:07:59] <scarabeus> so yea
-[21:08:26] <tampakrap> and what does the metro say btw?
-[21:08:43] <scarabeus> fucking not sure
-[21:08:43] --> Thev00d00 (~v00d00@gentoo/developer/TheV00d00) hat #gentoo-meetings betreten
-[21:08:48] <Thev00d00> hello
-[21:08:50] <scarabeus> i ignore it for few years already
-[21:08:52] <scarabeus> hello Ian
-[21:08:55] <Thev00d00> sorry I'm late
-[21:09:00] <johu> Jsem černý řidič
-[21:09:02] <tampakrap> anastum?
-[21:09:13] <tampakrap> johu: nerozumim
-[21:09:45] <tampakrap> a nastup, found it
-[21:10:11] <scarabeus> johu: I am black driver? :D
-[21:10:18] <johu> scarabeus: yes
-[21:10:38] <johu> google translate
-[21:10:44] <tampakrap> Ukončete prosím výstup a nástup, dveře se zavírají
-[21:11:54] <scarabeus> i always wanted after this message see emergency hydraulic close as i seen on tank
-[21:12:01] <scarabeus> woosh, click, scream, blood, ... :D
-[21:12:23] <tampakrap> bullshit
-[21:12:43] <-- B-Man (~aaron@108.171.119.130) hat das Netzwerk verlassen (Quit: Konversation terminated!)
-[21:13:07] <scarabeus> but it closes so slowly :-)
-[21:13:30] --> mrueg (~mrueg@rueg.eu) hat #gentoo-meetings betreten
-[21:13:41] <johu> drunken ppl approved
-[21:15:00] <scarabeus> johu: i would say you wont get more people ;)
-[21:15:15] <johu> !herd kde
-[21:15:17] <willikins> (kde) abcd, ago, alexxy, creffett, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, tampakrap, thev00d00
-[21:15:20] <johu> 1. roll call
-[21:15:58] <creffett> present
-[21:16:04] <tampakrap> ahoj
-[21:16:04] <johu> .
-[21:16:07] <ago> here
-[21:16:34] <Thev00d00> !
-[21:16:38] <scarabeus> beep
-[21:16:48] <mschiff> hi
-[21:16:51] <johu> 2. Elect new herd lead
-[21:17:30] <creffett> cue question of how many herd leads to have
-[21:17:35] <johu> any nominees beside mee?
-[21:18:01] <scarabeus> johu: you still want to find someone else to do it huh? :D
-[21:18:27] <johu> scarabeus: sure!
-[21:18:29] <scarabeus> johu: If you want not much active lead I can do it, but be sure I wont be proactive :D
-[21:18:36] <creffett> not me.
-[21:18:54] <johu> ok second nominee scarabeus
-[21:19:04] <ago> scarabeus and johu  both lead would be awesome
-[21:19:05] <Thev00d00> I vote johu
-[21:19:16] <ago> how about have two leads?
-[21:19:24] <tampakrap> how about 6?
-[21:19:25] <Thev00d00> scarabeus is to old and grouchy
-[21:19:29] <tampakrap> we'll have plenty of backups
-[21:19:41] -*- johu votes for scarabeus
-[21:19:55] <scarabeus> ago: you need only one for the outside comunication, with devrel, recruiters, etc
-[21:20:30] <scarabeus> Thev00d00: the word is Grumpy :P
-[21:21:23] -*- tampakrap votes for johu
-[21:21:42] -*- tampakrap points out that scarabeus is saying *censored*, no leads are required actually
-[21:21:55] <johu> tampakrap: do you re-joined?
-[21:22:01] -*- creffett votes for johu
-[21:22:04] <scarabeus> tampakrap: only LEAD can approve new members for recruitement
-[21:22:14] <tampakrap> no idea, I was highlighted for the meeting :)
-[21:22:18] <scarabeus> tampakrap: and that is the reason why we started with leads :D
-[21:22:22] <tampakrap> plus I have nothing to do right now :)
-[21:22:28] <johu> tampakrap: ok your vote will be counted
-[21:22:30] <scarabeus> in 2k9 with jorge
-[21:22:37] <scarabeus> we didnt have one for like 2 years before :P
-[21:22:50] <tampakrap> I really have to disagree, even team members is vague
-[21:22:56] <johu> scarabeus / ago please vote
-[21:23:06] -*- scarabeus votes johu
-[21:23:15] -*- ago votes johu 
-[21:23:26] <scarabeus> johu: didn't help ya :P
-[21:23:29] <tampakrap> for example, you've been doing heavy kde work (eg wrote the cmake eclass) way before joining as official developer
-[21:23:31] <johu> i see
-[21:23:41] -*- mschiff votes johu
-[21:23:51] <tampakrap> how does your opinion in that state count less than any other (inactive?) member
-[21:24:20] <johu> ok vote finished
-[21:24:30] <johu> 3. KDE 4.9 stabilization (15 minutes)
-[21:24:40] <johu> Possible blocker, please discuss and vote:
-[21:24:45] <johu>  kde-base/konsole-4.9.0 - freezes on double-click (bug #430286)
-[21:24:46] <willikins> johu: https://bugs.gentoo.org/430286 ">=kde-base/konsole-4.9.0 freezes on double-click"; Gentoo Linux, KDE; UNCO; Martin.vGagern:kde
-[21:24:51] <johu> - kde-base/nepomuk-core-4.9.1 - constantly segfaults after login into kde (bug #435112)
-[21:24:52] <willikins> johu: https://bugs.gentoo.org/435112 "kde-base/nepomuk-core-4.9.1 constantly segfaults after login into kde"; Gentoo Linux, KDE; UNCO; bu9zilla:kde
-[21:24:56] <johu>  kde-base/kmail-4.9.1 - problems creating imap folder (bug #434156)
-[21:24:58] <willikins> johu: https://bugs.gentoo.org/434156 "kde-base/kmail-4.9.1: Problems creating imap folder"; Gentoo Linux, KDE; CONF; dilfridge:kde
-[21:25:18] <tampakrap> so vote finished without celebration?
-[21:25:22] <tampakrap> you must be kidding me
-[21:25:34] <johu> my gf will celebrate me
-[21:25:41] -*- tampakrap CONGRATULATES HIS MENTEE JOHU AND OPENS ANOTHER KOZEL!!!
-[21:25:54] <mschiff> congrats johu ;)
-[21:26:01] <johu> thanks
-[21:26:25] <johu> tampakrap: kozel means what?
-[21:26:27] <scarabeus> johu: we can give you a badge :P
-[21:26:31] <scarabeus> johu: beer brand
-[21:26:38] <scarabeus> johu: first two are blockers
-[21:26:47] <scarabeus> johu: the kmail is not critical even tho annoying
-[21:27:17] <johu> then i have 2 bad messages from upstream no progress on the 2 blockers for 492
-[21:27:36] <ago> johu: good luck as lead =)
-[21:27:51] <johu> ago: sure, i will need it
-[21:28:21] <ago> johu: so, I'd say to wait 493
-[21:28:50] <johu> ago: or wait for fix and backport to 492 if there is a solution in the meantime....
-[21:29:05] <ago> not a bad idea..
-[21:29:18] <scarabeus> well i would like 4.9 as it fixes few bugs i am experiencing
-[21:29:25] <ago> in all cases we need upstream fix before decide and do anything
-[21:29:41] <scarabeus> but not over everything, so the blockers could be backported but we should not proceed without them
-[21:30:20] <johu> scarabeus: 100% ack
-[21:30:56] <johu> ok, i will watch upstream and ping back if there is a fix
-[21:31:07] <mschiff> a cannot reproduce 430286 here
-[21:31:48] <johu> mschiff: me neither but its acked by arch users as well, happens from time to time
-[21:32:10] <johu> * Status report of kde stable subproject (ago / creffett )
-[21:32:39] <ago> well
-[21:32:51] <ago> the page project is up and appears complete
-[21:32:53] <ago> http://www.gentoo.org/proj/en/desktop/kde/kde-stable/index.xml
-[21:33:19] <ago> I asked via query feedback to johu creffett scarabeus tampakrap Thev00d00 and seems fine
-[21:33:45] <tampakrap> I want to raise two objections here though
-[21:33:48] <mschiff> And using current git kdepim (well two days old or three) and akonadi 9999 I cannot reproduce  434156
-[21:34:04] <ago> I will fix it time to time If I will notice there is e.g. the same thing not clear for more than one people
-[21:34:13] <tampakrap> 1) this subproject does NOT need a separate alias, it does NOT need an alias even, just use gentoo-desktop ml
-[21:34:47] <creffett> tampakrap: what is the "cost" associated with making a new alias?
-[21:35:01] <tampakrap> no cost, and I am not talking as infra now
-[21:35:08] <tampakrap> I'm talking as a guy interested in that stuff
-[21:35:09] <ago> tampakrap: this subproject can also ack on other kde-* stable request
-[21:35:30] <tampakrap> so, my opinion is that all the moves of those guys should be 100% public, thus ml is the best option here
-[21:35:57] <johu> (which is a principal of gentoo)
-[21:35:58] <tampakrap> ago: sorry, I don't understand what you mean
-[21:36:03] <tampakrap> or I don't see your point
-[21:36:22] <ago> tampakrap: if we have people interested in this stuff, why they must follow gentoo-desktop?
-[21:36:47] <ago> instead of read only the possible mail sent from bugzilla
-[21:36:54] <tampakrap> you see it totally wrong
-[21:36:57] <tampakrap> let me elaborate
-[21:37:15] <tampakrap> there is a number of guys interested in testing/doing basic qa in kde
-[21:37:26] <tampakrap> they can 1) follow the kde bugzilla account
-[21:37:36] <tampakrap> 2) coordinate their efforts in #gentoo-kde channel
-[21:37:50] <tampakrap> 3) communicate in gentoo-desktop mailing list
-[21:37:58] <tampakrap> this way you have the following advantages:
-[21:38:07] <tampakrap> 1) people follow the official gentoo-kde team work
-[21:38:23] <tampakrap> 2) people use the same communication means as the gentoo-kde team does
-[21:38:40] <ago> tampakrap: for first 1 you mean add them on kde@gentoo.org ?
-[21:38:46] <tampakrap> 3) people don't have private communication media, so all of their work is public
-[21:39:12] <tampakrap> having them to follow the official getnoo-kde work and media makes them closer to the team, thus closer to becoming full getnoo devs which is the goal
-[21:39:35] <tampakrap> and NO I am not talking about adding them to kde alias, following the kde bugzilla account is different than adding them to the kde alias
-[21:40:22] <tampakrap> that's all from me, flame on
-[21:41:07] <scarabeus> ago: i updated the page as we talked about the english
-[21:41:32] <ago> tampakrap: probably you know that the bureaucreacy in gentoo is not well at all. So the goal here is take advantage of the normal user that using kde and 1) don't like to become a dev 2)don't have the time or don't want follow the ML and IRC
-[21:42:11] <tampakrap> I strongly disagree here, the procedure in becoming a gentoo developer is one of the best things we have imho
-[21:42:26] <tampakrap> and I prefer it 100% to the one that for example upstream kde has
-[21:42:55] <ago> me too, but there are a lot of people that disagree with you and me
-[21:42:55] <tampakrap> and I still don't see your point, if they don't want to become full developers they won't, noone is pointing guns to heads
-[21:43:31] <ago> let me explain the point
-[21:44:02] <ago> if you want become a dev, usually you are interested to follow IRC, bugzilla, ML
-[21:44:33] <ago> if you are not interested to do it and we say: you must follow them, the response from the user will be: do it by yourself
-[21:45:28] <ago> and nobody will populate the subproject
-[21:45:46] <johu> from kde parent herd i want to get feedback of the subproject, if you can handle that i am fine with the non-standard communication
-[21:46:23] <tampakrap> I see it now, you are creating a project for people that are not interested in becoming gentoo developers
-[21:46:34] <ago> tampakrap: yes
-[21:46:38] <tampakrap> and with that project you don't want to motivate or change their mind
-[21:46:52] <tampakrap> then sorry but I will have to go on the other side an not support your project
-[21:47:12] <ago> who are interested to do it can start with arch tester or directly with dev
-[21:47:15] <tampakrap> if people don't care about becoming gentoo developers (which in my little blue eyes means "no interest in the distro")
-[21:47:21] <tampakrap> then I don't care about them either
-[21:48:00] <tampakrap> sorry, still disagree with that move
-[21:48:06] <ago> tampakrap: I'm thinks the same but you need to think at one point.
-[21:48:44] <ago> If I can 'devolve' to gentoo 2h per day, I can think to become a dev
-[21:49:12] <ago> If I have not time to do it, but I can help using everyday KDE unstable, I can contribute without lose time
-[21:50:01] <tampakrap> sorry, don't agree
-[21:50:19] <tampakrap> and I said why I don't agree, and I don't want to repeat myself
-[21:50:55] <ago> this is fine, but does not mean we will not do it
-[21:50:59] <tampakrap> so, good luck with that, I see your point of creating that project, but I am making it clear that I don't want to support it
-[21:51:19] <tampakrap> no, that means that you are going forward normally, and I will shut up
-[21:51:25] <johu> ok anything else, beside that?
-[21:52:54] <ago> tampakrap: we have a lot of way to join gentoo and go to become dev, this is the only one that will not do it. We will see what will happen, and in case change the rules or what is needed
-[21:53:00] <johu> lets see how this is working when we have the next stable candidate
-[21:53:30] <johu> 4. EAPI 5 eclass support (15 minutes)
-[21:53:41] <johu> Discuss the needed changes.
-[21:55:13] <johu> scarabeus: you are council member and have a good overview about the eclasses and the new features
-[21:58:21] <Thev00d00> sub slots and slot operator deps are new
-[21:58:22] <scarabeus> johu: you guys dont need to change much
-[21:58:58] <scarabeus> only the slot operators might be usefull and implemented
-[21:59:20] <scarabeus> but basically enhancing the eapi case for 5 will break nothing
-[21:59:50] <johu> ok i will enable it after 492 bump in overlay
-[22:00:36] <Thev00d00> is it implemented in portage yet?
-[22:00:42] <johu> is there an example of the slot operators?
-[22:00:46] <johu> Thev00d00: yes
-[22:01:32] <Thev00d00> I was looking at: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blobdiff;f=eapi-cheatsheet.tex
-[22:01:40] <johu> alpha130 and the appropiate ~version
-[22:02:49] <johu> 5 Bugs (10 minutes)
-[22:02:58] <johu> dev-util/cmake-2.8.6-r4 - stop Xvfb after failed test phase (bug #406353)
-[22:02:58] <johu> This occurs because VIRTUALX_COMMAND could be a bash function that dies, and virtualx.eclass does not use nonfatal.
-[22:02:58] <johu> Discuss the patch - could there be any fallout?
-[22:02:59] <willikins> johu: https://bugs.gentoo.org/406353 "dev-util/cmake-2.8.6-r4 - stop Xvfb after failed test phase"; Gentoo Linux, KDE; UNCO; toralf.foerster:kde
-[22:03:47] <johu> if you dont disaggree, i think this can be skipped was added by kensington and has already the ack from x11 herd and a user (Franz Fellner)
-[22:06:00] <johu> silence = ack for the patch?
-[22:06:39] <creffett> no opinion here, didn't look all that closely
-[22:07:26] <Thev00d00> looks sensible to me
-[22:08:51] <ago> same as creffett
-[22:09:04] <johu> kde-base/kdebase-pam should use system-local-login instead system-auth in their pam.d files (bug #422495)
-[22:09:04] <johu> User session is not created when using systemd
-[22:09:04] <johu> Discuss and vote on proposed changes in duplicated bug (bug #433173)
-[22:09:15] <willikins> johu: https://bugs.gentoo.org/422495 "kde-base/kdebase-pam should use system-local-login instead system-auth in their pam.d files"; Gentoo Linux, KDE; UNCO; egorov_egor:kde
-[22:09:17] <willikins> johu: https://bugs.gentoo.org/433173 "kde-base/kdebase-pam please enable systemd seat using system-local-login"; Gentoo Linux, KDE; RESO, DUPL; eulenreich:kde
-[22:09:52] -*- Thev00d00 has no opinion on this one
-[22:10:27] <mschiff> has anybody tested if there were any impacts when not using systemd?
-[22:10:58] <johu> the question is is anybody using systemd and can do the positive test?
-[22:14:02] <ago> mschiff: is not stable atm I'd say no
-[22:16:19] <johu> hm]
-[22:17:53] <johu> ok we will add this after 492 in overlay and ask for testing
-[22:18:05] <johu> any objections?
-[22:18:18] <-- creffett (~creffett@gentoo/developer/creffett) hat das Netzwerk verlassen (Ping timeout: 240 seconds)
-[22:19:19] <Thev00d00> sounds sensible. I guess the guys on the bug can report the positive, we can check without sysd
-[22:19:38] <scarabeus> go ahead
-[22:19:39] <ago> johu: no
-[22:19:44] <johu> ok
-[22:20:01] <johu> last but not least
-[22:20:02] <johu> Open floor (15 minutes)
-[22:20:11] <johu> 6
-[22:20:12] <ago> Thev00d00: we will found a way to test :=)
-[22:21:34] <scarabeus> and i rush for bed i wake up early tmrw
-[22:21:36] <scarabeus> so cya
-[22:21:45] <johu> sweet dreams
-[22:22:57] --> creffett (~creffett@gentoo/developer/creffett) hat #gentoo-meetings betreten
-[22:23:12] <johu> i will do the summary (first time in wiki)
-[22:23:29] <-- reavertm (~reavertm@gentoo/developer/reavertm) hat das Netzwerk verlassen (Ping timeout: 246 seconds)
-[22:23:52] <johu> will need feedback because we have to port the old summaries to the wiki after that too
-[22:24:48] <johu> anything else?
-[22:24:55] <Thev00d00> can't we just link to them? seems like wasted effort toporrt
-[22:25:01] <Thev00d00> to port
-[22:25:23] <Thev00d00> but nope
-[22:25:27] <johu> i dont want to have 2 places for that...
-[22:25:58] <Thev00d00> you don't, you have a current and an archive :-)
-[22:27:23] <johu> i will find a minio..eh volunteer for this work
-[22:28:35] -*- creffett volunteers kensington
-[22:28:51] <johu> last chance to raise your voice
-[22:29:46] <johu> ok next meeting in 3 weeks, maybe with a new stable candidate...
-[22:30:49] <johu> thanks all meeting is over
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20121108.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20121108.txt
deleted file mode 100644
index 2735ef77b5..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20121108.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-[20:02:21] <creffett> !herd kde
-[20:02:22] <willikins> (kde) abcd, ago, alexxy, creffett, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, thev00d00
-[20:02:26] <creffett> 1. roll call, first attempt
-[20:02:46] -*- creffett here
-[20:04:08] --> tampakrap (~tampakrap@gentoo/developer/tampakrap) hat #gentoo-meetings betreten
-[20:06:30] <creffett> well, that was successful.
-[20:06:36] <creffett> will try again at :15
-[20:06:49] <jmbsvicetto> hmm
-[20:07:11] <creffett> hmm indeed
-[20:09:11] <dilfridge> hmm
-[20:09:14] -*- dilfridge here
-[20:09:44] <hwoarang> you guys are falling apart :p
-[20:10:03] <creffett> our leader is MIA and I requested the meeting be moved up a week
-[20:10:17] <creffett> and nobody being here for meetings is pretty standard anyway
-[20:10:23] <hwoarang> :p
-[20:10:28] <dilfridge> looking at the bug numbers it's not so bad
-[20:10:43] <creffett> I'm surprised that I managed to get my time conversions right this time :P
-[20:10:49] <dilfridge> hehe
-[20:10:52] <dilfridge> I didn't
-[20:10:53] <kensington> we need to decide on a new time I think :p
-[20:10:59] <creffett> yeah, we do
-[20:11:15] <creffett> preferably not decided only by the people who can make the meetings :P
-[20:11:17] <jmbsvicetto> sorry guys, but I need to leave. Whatever you decide, I'm sure will be the best choice :)
-[20:11:28] <dilfridge> oh dear :D
-[20:11:38] <kensington> I'll vote on your behalf ;)
-[20:11:48] <jmbsvicetto> hehe, go ahead
-[20:11:54] -*- creffett decides to make kensington team leader and start a massive project to switch the backend of KDE to GTK+
-[20:12:02] <dilfridge> dastergon: congratulations!!
-[20:12:04] <jmbsvicetto> kensington: just let amarok hidden in a corner and we'll be fine ;)
-[20:12:41] <creffett> well, either way I'll be emailing kde@ with a request for opinions
-[20:12:53] <dastergon> thank you dilfridge :)
-[20:13:42] <kensington> mmmm, KDE/GTK+, nasty
-[20:14:05] <creffett> this is what happens when I'm in charge
-[20:15:36] <creffett> anyway, hopeful attempt at roll call, failing this we try again next week
-[20:15:41] <creffett> !herd kde
-[20:15:42] <willikins> (kde) abcd, ago, alexxy, creffett, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, thev00d00
-[20:15:57] <creffett> ^ guest starring dastergon
-[20:15:57] -*- kensington (maybe)
-[20:16:03] -*- dilfridge 
-[20:16:31] -*- creffett here
-[20:18:16] <creffett> ...sigh
-[20:18:26] <creffett> okay, meeting pushed to next week, I guess
-[20:18:28] <dilfridge> well
-[20:18:34] <dilfridge> what's actually on the agenda?
-[20:18:44] <dilfridge> or more precisely, 
-[20:18:49] <dilfridge> what is important / urgent?
-[20:18:53] -*- creffett checks
-[20:19:28] <dilfridge> I had bug 430286 for a while but it disappeared mysteriously
-[20:19:31] <willikins> dilfridge: https://bugs.gentoo.org/430286 ">=kde-base/konsole-4.9.0 freezes on double-click"; Gentoo Linux, KDE; UNCO; Martin.vGagern:kde
-[20:19:48] <creffett> 3 potential blockers to stabilizing 4.9, whether to stabilize 4.9.3, when to move cmake to the tree, and what to do about the polkit-kde-kcmodules fiddling with stuff in /usr
-[20:19:53] <dilfridge> I *think* after logging out and in, and it only happened during the in-place upgrade
-[20:19:54] <kensington> (I note that while our herd member list is large, not too many seem to have much time at the moment, so I don't think we'll get too much improved turnout at a later date)
-[20:20:22] <creffett> true
-[20:20:40] <dilfridge> yes
-[20:20:45] <kensington> I think we should move 4.9.3 to tree and stable it, too many fixes are waiting in stable
-[20:20:49] <kensington> s/stable/~arch/
-[20:20:53] <creffett> so, we have three potential blockers to stabilizing 4.9: https://bugs.gentoo.org/show_bug.cgi?id=430286, https://bugs.gentoo.org/show_bug.cgi?id=434156, https://bugs.gentoo.org/show_bug.cgi?id=438274
-[20:21:01] <dilfridge> bug 434156 is hard to debug without help from upstream
-[20:21:04] <willikins> https://bugs.gentoo.org/434156 "kde-base/kmail-4.9.1: Problems creating imap folder"; Gentoo Linux, KDE; CONF; dilfridge:kde
-[20:21:26] <creffett> the last one is tracking upstream
-[20:21:27] <dilfridge> and since upstream in this particular case usually does not care for gentoo...
-[20:22:08] <dilfridge> I'd say these are not really blockers (the first one would be but I have not seen it for a while)
-[20:22:16] <creffett> my thoughts are that the three aren't crucial enough to block stabilization, and the last one is upstreamed and we can backport a fix if/when it comes up
-[20:22:27] <dilfridge> ack
-[20:22:49] <dilfridge> mmhh where is ago?
-[20:23:04] <dilfridge> :|
-[20:23:09] <creffett> excellent question
-[20:23:47] <creffett> and then 4.9.3 will be our stable candidate
-[20:23:49] <dilfridge> what is the sec bug that ago was talking about?
-[20:24:10] <creffett> not sure
-[20:24:18] <kensington> !bug #438452
-[20:24:20] <willikins> kensington: https://bugs.gentoo.org/438452 "kde-base/konqueror : Multiple vulnerabilities (CVE-2012-{4512,4513,4514,4515})"; Gentoo Security, Vulnerabilities; IN_P; ago:security
-[20:25:02] <kensington> we did some investigating and all the fixes are in kdelibs
-[20:25:12] <dilfridge> ok
-[20:25:21] <kensington> in various versions, the last fixed in 4.9.3
-[20:25:24] <dilfridge> so either fast-stable 493 or backport
-[20:25:36] <creffett> fast-stable 493
-[20:25:47] <dilfridge> yeah why not
-[20:26:03] <kensington> there's quite a few bugs cropping back up that are fixed in ~arch, so++
-[20:26:18] <creffett> all right, that's settled
-[20:26:22] <creffett> when do we move 493 to the tree?
-[20:26:23] <kensington> eg. rich0 ran into stable build failure today
-[20:26:41] <dilfridge> searching for the cve numbers on bugs.kde.org gives no results :(
-[20:26:52] <dilfridge> creffett: now?
-[20:27:03] <creffett> dilfridge: fine with me
-[20:27:04] <dilfridge> with stabilization as soon as ago can do it?
-[20:27:08] <creffett> mhm
-[20:27:20] <kensington> ++
-[20:27:46] <creffett> I'll move it into the tree later today
-[20:27:50] <dilfridge> cool
-[20:28:09] <kensington> there's a list of misc apps in the overlay due for stabilisation too
-[20:28:18] <dilfridge> I'll be gone soon, need to be back at work 8 sharp...
-[20:28:19] <creffett> is there anything special to that beyond "copy everything into kde-base/"? I haven't actually done a move-kde-to-tree before :)
-[20:28:30] <creffett> okay, will discuss that later
-[20:28:45] <dilfridge> creffett: the bump script can do it 
-[20:28:49] <creffett> okay
-[20:29:20] <dilfridge> but in the past I've also done it with find and cp
-[20:29:36] <creffett> last two: cmake I say we bump and wait a week or so before moving to tree, and the polkit-kde-kcmodules let's throw a CONFIG_PROTECT in for now and we'll look at symlinking in KDE 4.10
-[20:29:41] <dilfridge> the only difficulty is not missing any patches
-[20:30:44] <dilfridge> cmake: ack
-[20:31:10] <dilfridge> polkit-... not sure what you want to achieve with CONFIG_PROTECT
-[20:31:40] <dilfridge> but all changes only become critical with 4.10 I guess, we probably dont want to make big adaptions within 4.9 series
-[20:32:08] <creffett> protecting /usr/share/polkit-1/actions because right now KDE modifies that and so it can be overwritten on upgrade
-[20:32:15] <dilfridge> ah ok
-[20:32:15] <dilfridge> yes
-[20:32:31] <dilfridge> CONFIG_PROTECT for now and moving it maybe with 4.10
-[20:32:48] <kensington> ++
-[20:32:52] <creffett> mhm, but the exact implementation can wait until we start getting pre-releases of 4.10\
-[20:32:56] <creffett> and that's all from me
-[20:32:57] <dilfridge> yes
-[20:33:21] <dilfridge> everything else is good for next meeting I think
-[20:33:35] <creffett> mhm, will go push them onto the agenda for next month
-[20:33:39] <creffett> thanks all
-[20:33:57] <dilfridge> thank you :)
-[20:35:19] <tampakrap> creffett: don't worry, you are doing great
-[20:35:43] <creffett> I'm not even supposed to be running these things, johu is
-[20:36:04] <tampakrap> not really
-[20:36:11] <tampakrap> team leader != meeting chairman
-[20:36:15] <creffett> he's the fearless leader
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20130117.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20130117.txt
deleted file mode 100644
index b01d24db5f..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20130117.txt
+++ /dev/null
@@ -1,212 +0,0 @@
-[19:58:11] * dilfridge has changed topic for #gentoo-meetings to: "Gentoo Meetings | FOSDEM talk -> #gentoo-fosdem ! |  KDE team meeting 17 Jan 1900 UTC http://wiki.gentoo.org/wiki/Project:KDE/Meeting/2013-1"
-[19:58:46] --> creffett (~creffett@gentoo/developer/creffett) hat #gentoo-meetings betreten
-[20:04:33] <creffett> (kde) abcd, ago, alexxy, creffett, dastergon, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, thev00d00
-[20:04:38] <creffett> 1. roll call
-[20:04:46] -*- dastergon is here 
-[20:04:51] -*- mschiff here
-[20:04:52] -*- dilfridge here
-[20:05:02] -*- creffett is here
-[20:05:50] -*- alexxy partialy here
-[20:06:05] <creffett> wow, we actually reached our minimum for a meeting
-[20:06:11] <creffett> I may faint.
-[20:06:35] <creffett> I'll give a couple more minutes for any stragglers, then we'll get started
-[20:08:41] -*- alexxy need some sleep, group theory is cool but...
-[20:08:49] <Thev00d00> I'm here and late :-)
-[20:09:04] <Thev00d00> also cooking ;-)
-[20:09:11] <creffett> good enough for me, let's get this show on the road
-[20:09:32] <creffett> 2. Keywords
-[20:09:59] <-- EM3RY (~quassel@204.12.167.10) hat das Netzwerk verlassen (Ping timeout: 248 seconds)
-[20:10:07] <creffett> we dropped ppc64, but do we want to add any stable/testing keywords?
-[20:10:36] -*- creffett would be interested in getting arm stabilized at some point
-[20:11:38] --> dMaggot (~user@201.227.175.3) hat #gentoo-meetings betreten
-[20:13:17] <dastergon> creffett: +1
-[20:15:23] <creffett> 3. CMake minimum requirement
-[20:15:35] <creffett> kdelibs-4.10 will require CMake 2.8.8 as a minimum. Should we bother enforcing this (given that 2.8.9 is already the lowest version in-tree)?  If so, where - kdelibs, KDE eclass, or even CMake eclass?
-[20:16:12] <dilfridge> err sorry got distracted
-[20:16:23] <dilfridge> arm is great
-[20:16:51] <dilfridge> re 3) I'd say kde eclass
-[20:16:54] <dilfridge> just to make sure
-[20:17:21] <Thev00d00> +1 for 3
-[20:17:48] <dilfridge> cmake-utils.eclass says CMAKE_MIN_VERSION="${CMAKE_MIN_VERSION:-2.8.4}"
-[20:17:58] <dilfridge> maybe it's reallly easiest there
-[20:18:09] <dilfridge> (change the default min version to 2.8.8)
-[20:19:01] <creffett> sounds good to me, I'll go make that change
-[20:19:03] <mschiff> +1
-[20:19:24] <dastergon> +1
-[20:19:44] <creffett> 4. Bugs
-[20:19:56] --> lmiphay (~lmiphay@86-45-44-228-dynamic.b-ras2.prp.dublin.eircom.net) hat #gentoo-meetings betreten
-[20:19:58] <creffett> x11-themes/oxygen-gtk: Rename x11-themes/oxygen-gtk to x11-themes/oxygen-gtk2. Import  x11-themes/oxygen-gtk3 from the overlay or we keep x11-themes/oxygen-gtk  with 2 slot and rename x11-themes/oxygen-gtk3 to x11-themes/oxygen-gtk.
-[20:20:21] <creffett> basically, split it or slot it?
-[20:21:07] <dilfridge> what does gnome team say?
-[20:21:21] <creffett> I don't know if we've asked gnome team
-[20:21:35] <dilfridge> they should know best
-[20:21:55] <creffett> okay, will ask them
-[20:21:55] <mschiff> x11-libs/gtk+ itself uses slots..
-[20:22:40] <creffett> I know that some packages have weird methods of handling gtk+ 2 vs. 3
-[20:22:57] <creffett> *shrug*
-[20:23:12] <creffett> we'll ask GNOME team about it
-[20:23:17] <creffett> media-libs/qt-gstreamer - split out QtGlib (bug #439198) discuss, vote
-[20:23:38] <dMaggot> I wrote upstream about that
-[20:23:53] <dMaggot> and another question I had (basically gstreamer 1.0 support)
-[20:24:02] <dMaggot> unfortunately haven't got a reply about it
-[20:24:09] <creffett> okay
-[20:24:19] <dMaggot> I actually have a similar problem
-[20:24:29] <dMaggot> I'm using gstreamer 1.0 from the gnome overlay
-[20:24:37] <dMaggot> and haven't been able to update telepathy ever since
-[20:25:00] <creffett> I personally am not in favor, my comments are on the bug but basically I think that it's making things needlessly complex and if upstream eventually does split it out we'll write an ebuild then
-[20:25:08] <dMaggot> can we differ this decision at least for a coumple of weeks?
-[20:25:18] <dMaggot> I'll try to ping upstream about this again in the weekend
-[20:25:32] <creffett> sounds good to me
-[20:25:41] <creffett> any further comments on this one?
-[20:25:50] <dMaggot> I'll take that item and will inform of any updates
-[20:26:11] <creffett> okay
-[20:26:19] <creffett> kde-misc/polkit-kde-kcmodules: Store polkit configuration changes to /etc instead of /usr (bug #438790)  Discuss/vote: long-term solution
-[20:26:24] -*- creffett shudders at this one
-[20:26:53] <dilfridge> here, the main question is "what does upstream think"
-[20:27:14] <dilfridge> there was a thread about it on the release list some time ago
-[20:27:18] <creffett> mhm
-[20:27:33] <creffett> there was no response on the upstream bug itself
-[20:27:51] <mschiff> imo nothing but the package manager should ever change anything in /usr
-[20:28:33] <creffett> I think I summarized the responses from the list a couple meetings ago, but the general idea was that a bunch of distros have their own custom patches to change things, and upstream basically said "uh, why are we still doing this if everyone patches it out"
-[20:29:41] <mschiff> and sometimes they learn from it and fix it
-[20:30:16] <creffett> and they said that in Frameworks 5 you'll be able to export XDG_CONFIG_DIRS to specify these things
-[20:30:32] <creffett> there are actually two issues here, since kdm does the same thing
-[20:31:33] <creffett> and for that, a number of distros just symlink /usr/share/config/kdm to /etc/kde/kdm
-[20:32:33] <creffett> that's because kdm doesn't use kconfig for its settings
-[20:33:00] --> toralf (~toralf@d227155.adsl.hansenet.de) hat #gentoo-meetings betreten
-[20:34:16] <-- toralf (~toralf@d227155.adsl.hansenet.de) hat das Netzwerk verlassen (Quit: Konversation terminated!)
-[20:34:35] <creffett> note that all of the proposed solutions were for main KDE, not polkit-kde-kcmodules, the general consensus on that one was "we're not shipping it"
-[20:34:41] <creffett> so...opinions on what to do?
-[20:36:30] <dilfridge> does it fix a bug?
-[20:36:48] <creffett> https://bugs.gentoo.org/show_bug.cgi?id=438790
-[20:37:50] <creffett> it has a temporary fix of CONFIG_PROTECT, but no long-term fix
-[20:38:36] <dilfridge> how about symlinking this to somewhere in /etc?
-[20:38:49] <creffett> could work
-[20:38:55] <creffett> I'll experiment with that and report back
-[20:39:19] <creffett> Change the default DB backend for app-office/akonadi-server (bug #441596)  Discuss/vote: there are some comments that the mysql backend brings improved stability/performance
-[20:40:03] <creffett> any input here? this seems like one that needs reavertm's input
-[20:40:36] <Thev00d00> I've found that mysql is much better
-[20:40:49] <Thev00d00> that is on a high power desktop
-[20:41:01] <Thev00d00> but stability wise much nicer
-[20:41:29] <mschiff> I am using postgres as backend... but I would not make that the default ;)
-[20:41:43] <dilfridge> you all know the kde wiki page about this?
-[20:41:50] <creffett> I don't
-[20:41:53] <dilfridge> moment
-[20:42:20] <dilfridge> http://techbase.kde.org/Projects/PIM/Akonadi/Database
-[20:43:50] <creffett> okay
-[20:44:00] <Thev00d00> hmm well I would say make mysql default
-[20:44:01] <dilfridge> only real problem with the "full databases" as mysql or postgresql is that e.g. a laptop crash (dead battery) may leave you with a broken database
-[20:44:14] <creffett> agreed
-[20:44:17] <dilfridge> but then, you basically only lose a cache, so why bother
-[20:44:24] <creffett> vote: make mysql the default backend?
-[20:44:25] <creffett> +1
-[20:44:27] <dilfridge> +1
-[20:44:35] <mschiff> not with goto settings, no
-[20:44:42] <mschiff> s/goto/good/
-[20:44:56] <dilfridge> mschiff: what do you mean?
-[20:45:06] <mschiff> YOu can configure postgres to be safe
-[20:45:25] --> tampakrap (~tampakrap@gentoo/developer/tampakrap) hat #gentoo-meetings betreten
-[20:45:26] <mschiff> to be protected agains broken database
-[20:45:33] <tampakrap> hi
-[20:45:37] <dilfridge> ah ok
-[20:45:40] <dilfridge> hi dad
-[20:45:43] <mschiff> because of battery problem etc
-[20:46:02] <mschiff> hi tampakrap
-[20:46:36] <dilfridge> mschiff: ok so you say, the crash problem is not fundamental
-[20:46:43] <mschiff> I had mysql running for quite a long time with akonadi on my laptop and never had an issue with it
-[20:46:46] <dilfridge> ok
-[20:46:48] <mschiff> right
-[20:47:23] <mschiff> and I *had* cases where it crashed or I had to switch it off the hard way
-[20:47:26] <dilfridge> so again
-[20:47:31] <dilfridge> <creffett> vote: make mysql the default backend?
-[20:47:37] <mschiff> +1
-[20:47:40] <dilfridge> +1
-[20:47:50] <creffett> +1
-[20:47:57] <dastergon> +1
-[20:48:00] <dilfridge> cool
-[20:48:16] <dilfridge> remember changing the default useflag settings in the ebuild...
-[20:48:23] <creffett> I'll note it on the bug
-[20:48:37] -*- dilfridge thinks this will improve our relations to the kdepim guys
-[20:49:05] <mschiff> is it that bad? 8-)
-[20:49:06] <creffett> dilfridge: and maybe with the improved relations you can do something about kmail? ;)
-[20:49:14] <dilfridge> sigh
-[20:49:20] <dilfridge> what do you want, a miracle?
-[20:49:39] <creffett> app-office/akonadi-server-1.9.0: add Qt 5 support (bug #450412)  How do we want to start rolling out qt5 support in general?
-[20:49:47] <dilfridge> I already thought of porting kmail-4.4 to kdepim-4.10
-[20:50:17] <mschiff> I am looking at the git logs of kdepim quite often... they are really doing a lot in fixing bugs since some time...
-[20:50:53] <dilfridge> our overlay has a kmail-4.4.11.1-r100.ebuild, that is my personal playground
-[20:51:03] <dilfridge> (does not build right now)
-[20:51:05] <creffett> as I understand it, qt4 versus qt5 has to be global, you can't have both at once
-[20:51:29] <dilfridge> bastards
-[20:51:52] <dMaggot> haven't tried qt5 yet (I masked it) but I don't think one blocks the other (in terms of ebuilds, don't know about builds)
-[20:52:17] <creffett> there are some comments in the bug about how you can't have, say, qt5 libs and a qt4 consumer
-[20:52:45] <creffett> question number 1: should we start adding qt5 support?
-[20:52:49] <dMaggot> right, that's the type of issues I would expect: you probably would have to rebuild everything to use one or the other
-[20:53:00] <-- ABCD (~quassel@gentoo/developer/abcd) hat das Netzwerk verlassen (Ping timeout: 245 seconds)
-[20:56:02] <creffett> any comments?
-[20:56:18] --> ABCD (~quassel@gentoo/developer/abcd) hat #gentoo-meetings betreten
-[20:56:38] <mschiff> how?
-[20:57:04] <creffett> adding the USE flag to packages that have support?
-[20:57:05] <dilfridge> what?
-[20:57:23] <mschiff> but KDE SC itself will not support qt5 right?
-[20:57:33] <mschiff> (4.xx)
-[20:57:53] <dilfridge> did qt team say anything how they want the useflags? eg. either qt4 or qt5, or only a qt5 useflag that disables qt4 support, or... ?
-[20:58:09] -*- creffett adds this one to the "talk to other teams" list
-[21:00:00] <creffett> 5. Open floor
-[21:00:05] <dilfridge> afterwards kde will need akonadi[qt4] or akonadi[-qt5]
-[21:00:07] <dilfridge> yeah
-[21:00:18] <dilfridge> someone please tell the qt guys not to be ridiculous
-[21:00:29] <dilfridge> a category "qt" is a joke
-[21:00:30] -*- creffett nominates kensington in his absence
-[21:00:43] <dilfridge> "qt-base" if anything :D
-[21:00:50] <creffett> no, the joke is suggesting dropping the qt-prefix
-[21:01:00] <Thev00d00> noooo at is much better
-[21:01:05] <dMaggot> bug 450818 is goint to bite our... well, you know, our feet
-[21:01:10] <Thev00d00> *qt
-[21:01:23] <creffett> qt/core, qt/dbus, etc., etc....sure, let's just drop a bunch of name collisions into the tree
-[21:01:33] <dMaggot> there's still no nswer fro teh qt team, from qt upstream, etc
-[21:03:43] <creffett> dMaggot: pesa's question should be answered (re: where is it from, has it been upstreamed)
-[21:04:47] <dilfridge> https://bugreports.qt-project.org/browse/QTBUG-29082
-[21:05:05] <-- ABCD (~quassel@gentoo/developer/abcd) hat das Netzwerk verlassen (Ping timeout: 245 seconds)
-[21:06:08] <creffett> works for me
-[21:06:42] <dMaggot> creffett: right, I should have updated the bug with that info
-[21:06:50] <dilfridge> dMaggot: just done
-[21:07:00] <creffett> what else do we have for open floor business?
-[21:07:26] <dilfridge> cookie distribution
-[21:07:36] <creffett> fine
-[21:07:40] <creffett> cookies to all who attended
-[21:07:56] -*- dilfridge munching
-[21:07:57] <dastergon> and some cookies for tampakrap's baby
-[21:08:10] <creffett> plasma-active is about half packaged in my local overlay so far
-[21:09:03] --> ABCD (~quassel@gentoo/developer/abcd) hat #gentoo-meetings betreten
-[21:09:27] <creffett> I'm still trying to figure out how to package "maliit", which is a dep of one of the packages which provides the input method framework (if anyone has a good example of a package that is configured by way of qmake, please let me know)
-[21:10:39] <dilfridge> eww
-[21:10:42] <creffett> but other than that it's nearly ready to hit the overlay, though I'm not going to package the patches until the next Active release because they don't apply to latest KDE and I really don't want to respin a few hundred line long patch
-[21:10:56] <creffett> I'll probably be putting it in category plasma-active
-[21:11:13] <dilfridge> push it! and then write to -dev and request kde-active category...
-[21:11:40] <creffett> it can wait until we've actually tested the packages :)
-[21:11:58] <dilfridge> plasma-active is less easier understood than kde-active I'd say...
-[21:12:09] <creffett> yeah, but the official name upstream is plasma active
-[21:12:20] <dilfridge> :|
-[21:12:27] <creffett> eh, we can bikeshed it once I'm finished packaging
-[21:12:28] <dilfridge> they are really branding specialists
-[21:12:48] <creffett> mhm
-[21:13:09] <creffett> any other business for open floor? we still have time
-[21:13:19] <mschiff> kde-plasma-active?
-[21:14:08] <mschiff> Is anybody else using the 49.9999 packges?
-[21:15:15] <dilfridge> mschiff: no but I'm already on .98
-[21:15:25] <mschiff> k
-[21:15:34] <mschiff> just for the record
-[21:15:58] <mschiff> I had a good time using 4.9.49.9999 and will keep to do so with 4.10 (already do)
-[21:15:58] <dilfridge> mschiff: kensington: btw the pykde4 patch that I added does not help, I still get a sandbox violation
-[21:16:08] <dilfridge> in pykde4-4.9.98
-[21:16:20] <dilfridge> there is one more commit that could cause it
-[21:16:28] <dilfridge> -> weekend or anyone else
-[21:16:59] <dilfridge> kensington is working on porting all python dependencies to python-r1.eclass btw
-[21:17:09] <Thev00d00> nice
-[21:19:39] <creffett> I don't envy him that
-[21:20:58] <creffett> nothing else? /me finds a gavel
-[21:21:17] <creffett> *bam* meeting adjourned
-[21:21:27] <dilfridge> yeah yeah yeah :)
-[21:21:46] <mschiff> ;)
-[21:21:53] * dilfridge has changed topic for #gentoo-meetings to: "Gentoo Meetings | FOSDEM talk -> #gentoo-fosdem !"
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20130321.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20130321.txt
deleted file mode 100644
index 98ea3da6e8..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20130321.txt
+++ /dev/null
@@ -1,368 +0,0 @@
-[20:02:32] <ago> !herd kde
-[20:02:32] <willikins> (kde) abcd, ago, alexxy, creffett, dastergon, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, thev00d00
-[20:02:41] <ago> roll call:
-[20:02:47] -*- ago obviously here
-[20:02:51] * dilfridge has changed topic for #gentoo-meetings to: "Gentoo Meetings | KDE team meeting Thu 21/Mar/2013 19:00 UTC, agenda http://wiki.gentoo.org/wiki/Project:KDE/Meeting/2013-03"
-[20:03:00] -*- dilfridge obviously here
-[20:03:08] -*- creffett here
-[20:03:11] -*- dastergon here
-[20:03:39] <ago> is needed a minimum number of people to start?
-[20:03:44] <creffett> 5, I think
-[20:03:52] <dilfridge> not really, more something like a minimum 5min waiting :D
-[20:03:57] <jmbsvicetto> Do you guys need anything from me?
-[20:04:09] <ago> ok, we are jmbsvicetto probably a vote for the lead
-[20:04:14] <ago> err
-[20:04:20] <ago> s/ok, we are//
-[20:04:24] <dilfridge> jmbsvicetto: nothing specific I think
-[20:04:32] <jmbsvicetto> Are we voting for a new lead?
-[20:04:44] <dilfridge> yes no maybe
-[20:04:47] <creffett> I guess so?
-[20:04:49] <jmbsvicetto> Shouldn't that have happened on last FOSDEM?
-[20:05:12] <ago> jmbsvicetto: no
-[20:05:14] <dilfridge> we should indeed reintroduce that tradition
-[20:06:20] <ago> ok, next roll call at 19:15
-[20:06:48] --> lmiphay (~lmiphay@86-45-45-142-dynamic.b-ras2.prp.dublin.eircom.net) hat #gentoo-meetings betreten
-[20:07:19] <ago> kensington, creffett: since you handle the announce of the meeting in the lists, please cc kde-stable next time.
-[20:07:29] <jmbsvicetto> well, I've been away for a long time, so you're all more qualified than me about the kde issues. I trust your opinion and will go with the majority vote
-[20:07:36] <dilfridge> lol
-[20:07:52] <creffett> ago: okay
-[20:08:10] --> scarabeus (~scarabeus@gentoo/developer/flyingspaghettimonster/scarabeus) hat #gentoo-meetings betreten
-[20:08:17] <scarabeus> pookaboo
-[20:08:24] -*- jmorgan1 here
-[20:08:31] <jmbsvicetto> whoaa, our flyping spaghetti monster is here? O_O
-[20:08:40] <jmbsvicetto> even the *flying* ;)
-[20:09:25] -*- creffett wonders why we always have such good turnout when someone besides me sends the email :P
-[20:09:26] <scarabeus> jmbsvicetto: and we too need to plan out delivery of your camera finaly :D i am still walking around it and puting it to various shelfs... it still does not fit into czech republic :D
-[20:09:50] <jmbsvicetto> scarabeus: hehe
-[20:09:52] <jmbsvicetto> scarabeus: sorry about that
-[20:10:11] <jmbsvicetto> scarabeus: If things go as well as I hope, I'll be asking you soon to send it to me ;)
-[20:10:20] <scarabeus> splendid :-)
-[20:11:27] <jmbsvicetto> anyway, I'm sorry guys but I need to leave now. Have a good meeting
-[20:13:32] <dastergon> ago: roll call no2 ?
-[20:14:17] <ago> dastergon: just wait another min
-[20:14:22] <dilfridge> i guess ago is waiting for the clock to strike 20:15 :]
-[20:14:52] <ago> http://www.portale.it/orario.php :D
-[20:14:58] <jmorgan1> im going to add myself to herd
-[20:15:05] <jmorgan1> any objections?
-[20:15:26] <ago> !herd kde
-[20:15:26] <creffett> go for it
-[20:15:26] <willikins> (kde) abcd, ago, alexxy, creffett, dastergon, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, thev00d00
-[20:15:30] <ago> 2° roll call:
-[20:15:30] <dilfridge> nope not here, go for it
-[20:15:36] -*- ago here
-[20:15:38] -*- dilfridge present
-[20:15:45] <scarabeus> jmorgan1: you can add, but still pretty female would make me more happy :D
-[20:15:46] -*- dastergon here
-[20:15:46] <ago> jmorgan1: you are welcome
-[20:15:50] -*- scarabeus around
-[20:15:51] <creffett> here
-[20:16:04] <-- ABCD (~quassel@gentoo/developer/abcd) hat das Netzwerk verlassen (Read error: Connection reset by peer)
-[20:16:21] --> ABCD (~quassel@gentoo/developer/abcd) hat #gentoo-meetings betreten
-[20:16:38] <ago> ok, we are 5, we can go ahead?
-[20:16:46] <dilfridge> ok we're 6, we go ahead
-[20:17:06] <ago> 1) Project lead (5 minutes)
-[20:17:30] <dilfridge> any volunteers?
-[20:17:32] <ago> Last time the vote was between johu_ and scarabeus....so is scarabeus available to do it?
-[20:17:38] <ago> is there someone else?
-[20:17:54] <dilfridge> well
-[20:18:04] <creffett> I could, I guess
-[20:18:42] <scarabeus> creffett: go for it, everyone deserves the hat from time to time :P
-[20:18:46] <dilfridge> if the only alternative is that the current situation continues, I could do it, but I'm not infinitely happy about it
-[20:19:05] <dilfridge> creffett: excellent!
-[20:19:18] <ago> ok, creffett for the lead is fine for me: +1
-[20:19:33] -*- dastergon votes creffett :)
-[20:19:37] <dilfridge> creffett++
-[20:20:07] <ago> jmorgan1: feel free to approve disapprove also if you are fresh here
-[20:20:38] <jmorgan1> i concure
-[20:20:40] <scarabeus> creffett: take my sentene as ++ for you :-)
-[20:20:51] <creffett> okay then.
-[20:20:53] <ago> jmbsvicetto: still here for the vote?
-[20:21:14] <dilfridge> that's a comfortable majority already
-[20:21:31] <dastergon> congrats creffett !
-[20:21:36] -*- creffett bows
-[20:21:40] <ago> autokick in -kde done :P
-[20:21:42] <dilfridge> cheers
-[20:22:09] <ago> next point
-[20:22:14] <ago> 2) KDE 4.10.1 stabilization (10 minutes)
-[20:22:46] <dilfridge> I'm all for it, it works nicely
-[20:22:49] <ago> this is a rapid bug search https://bugs.gentoo.org/buglist.cgi?quicksearch=4.10.1&list_id=1622108
-[20:23:05] <ago> dilfridge: vincent/peratu reports that does not work for him on ppc
-[20:23:20] <jmorgan1> i filed one bug on ppc64
-[20:23:22] <ago> and jmorgan1 reports a failure of rocs
-[20:23:24] <dilfridge> we should add the kwin (window unref) patch, it is in stable branch
-[20:23:26] <jmorgan1> ;)
-[20:23:52] <ago> ok, the ppc situation is a big regression
-[20:23:59] <dilfridge> the rocs problem, we cannot do much about it, it's a gcc ICE
-[20:24:16] <dilfridge> you should show it to vapier
-[20:24:18] <ago> https://bugs.kde.org/show_bug.cgi?id=316988
-[20:24:25] <jmorgan1> 4.9.5 works on ppc/ppc64
-[20:25:00] <dilfridge> jmorgan1: could you try gcc-4.7 ?
-[20:25:25] <jmorgan1> sure, for rocs failure?
-[20:25:28] <dilfridge> yes
-[20:25:29] <ago> jmorgan1: I usually saw this kind of error on machine with broken hw..how's the status of your?
-[20:25:31] <jmorgan1> ok
-[20:25:52] <ago> I will check too on my chroot
-[20:26:09] <jmorgan1> yes, i'll look into both hw and gcc-4.7
-[20:26:16] <ago> any progress for arm? is the time to do it?
-[20:26:55] <ago> jmorgan1: is this bug reproducible on ppc64? https://bugs.kde.org/show_bug.cgi?id=316988 you are able to use the session?
-[20:27:46] <dilfridge> eww
-[20:27:50] <dilfridge> I know that backtrace
-[20:28:17] <jmorgan1> ago: i'll take a look this evening
-[20:28:19] <dilfridge> dMaggot: ^ please have a look, does that look familiar to you too?
-[20:28:26] <dMaggot> dilfridge: checking...
-[20:28:38] <ago> dMaggot: you are upstream?
-[20:29:44] <dMaggot> ago: I fixed that crash in other archs
-[20:30:07] <dilfridge> the question is, why is it still around on ppc?
-[20:30:19] <dilfridge> or is it a similar but different problem?
-[20:30:26] <ago> ok, I merged 4.10.1 on 2 machines...looks ok for both...my vote is yes for amd64/x86 and not now for ppc/ppc64/arm
-[20:30:40] <creffett> +1
-[20:30:52] <dastergon> +1
-[20:30:57] -*- ABCD is alive (and forgets when meetings are because they always are when he's normally supposed to be at work)
-[20:31:04] <dilfridge> sounds good (after adding kwin patch), +1
-[20:31:07] <jmorgan1> +1
-[20:31:31] <ABCD> +1
-[20:32:02] <dilfridge> awesome.
-[20:32:03] <ago> scarabeus: ?
-[20:33:05] <dilfridge> next
-[20:33:18] <ago> wait
-[20:33:26] <ago> who will open and generate the list? =)
-[20:33:31] <ago> creffett: could you?
-[20:34:00] <creffett> ago: sure, I'll handle it tonight
-[20:34:17] <dilfridge> creffett: please also grab the kwin patch from git KDE/4.10 branch
-[20:34:20] <scarabeus> ah +1 from me
-[20:34:28] <scarabeus> i am still half page to the log :D
-[20:34:33] <ago> creffett: ok, please send me and I check it with repoman before open the bug
-[20:34:43] <creffett> will do
-[20:34:50] <ago> 3) Remove -Wl,--fatal-warnings ??? (5 minutes)
-[20:35:16] <dilfridge> that's mine
-[20:35:20] <ago> It gave problems?
-[20:35:30] <dilfridge> basically we get build failures every now and then
-[20:35:40] <dilfridge> not frequently, most are on arm
-[20:35:40] <creffett> there have been a couple bugs lately that come from that being enabled
-[20:35:56] <dilfridge> it will NOT be removed upstream
-[20:36:19] -*- dilfridge had a discussion with a couple of kde bigshots about it
-[20:36:49] <ago> dilfridge: how sounds enable it with a var?
-[20:36:49] <dilfridge> usually, the linker warning should be fixed in the package, not ignored
-[20:36:59] <ago> so who has problem is able to drop it
-[20:37:35] <dilfridge> not easy, because it is fixed in cmake files installed by kdelibs
-[20:38:45] <scarabeus> technically developer profile should enable it
-[20:38:52] <scarabeus> we should not enable it on desktop profile
-[20:38:54] <dilfridge> we could add some magic to the eclass that patches package cmake files and disables it on request, but that may be more pain than before
-[20:38:55] <ago> ok, I have not particular vote for it, if it is needed, do it
-[20:39:14] <dilfridge> scarabeus' idea sounds ok, the question is how to best do it
-[20:39:41] <dilfridge> easiest way would be to conditionally patch kdelibs with a useflag
-[20:39:50] <dilfridge> that applies to all kde packages then
-[20:42:01] -*- creffett is a bit nervous about conditional patching like that
-[20:42:04] <dilfridge> however that is not really elegant and does not do it "the Gentoo way"
-[20:42:24] <scarabeus> dilfridge: nope, just remove it from the cmake files
-[20:42:30] <scarabeus> and then append it in profile ldflags
-[20:42:38] <scarabeus> but discussion on -dev prior enabling it treewide
-[20:42:44] <scarabeus> all the linking issues are actual errors
-[20:42:49] <scarabeus> so fixing them is benefitical a lot
-[20:42:56] <dilfridge> makes sense
-[20:42:58] <dilfridge> +1
-[20:43:21] <ago> I vote with the majority
-[20:43:29] -*- dilfridge thinks we need diego back before we can ever enable it treewide
-[20:44:26] <ago> dilfridge: the tbox script are public :)
-[20:44:40] <dilfridge> ok, suggestion by scarabeus: remove -Wl,--fatal-warnings from cmake files and start a discussion to enable it in the dev profile treewide
-[20:44:43] <dilfridge> opinions?
-[20:44:47] <dilfridge> +1 from me
-[20:45:07] <ago> +1 with the majority (as I said)
-[20:45:13] <scarabeus> you can run tbox stuff yourself, just commit it to qa-reports git repo with proper script calls, the box is done it executes by-cron everything required
-[20:45:19] <jmorgan1> +1 sounds fine with me, disscussion is good
-[20:45:30] <jmorgan1> what is tbox?
-[20:45:49] <ago> tinderbox
-[20:45:59] <dilfridge> automated build test system
-[20:46:12] <dastergon> +1 from me
-[20:46:38] <dastergon> tinderbox the fear of the gentoo dev :P
-[20:46:47] <ago> creffett: ^
-[20:46:58] <jmorgan1> cool, i'll look into it
-[20:47:07] <creffett> ago: no opinion
-[20:47:09] <creffett> 0
-[20:47:57] <dilfridge> that's three yes and two "0", I guess that is a yes
-[20:48:06] <ago> ok, scarabeus's suggestion is approved
-[20:48:29] <ago> scarabeus: mind start the discussion on -dev?
-[20:49:37] <ago> there is just an update for the ppc crash: https://bugs.kde.org/show_bug.cgi?id=316988#c3
-[20:49:44] <jmorgan1> does anyone use the dev profile?
-[20:50:13] -*- dilfridge looks somewhere else
-[20:50:16] <ago> creffett: I will ask vincenti if works for him, if yes I can ask qt@ if we can stabilize that version and open the bug
-[20:50:40] <creffett> ago: okay
-[20:50:41] <ago> jmorgan1: I use default
-[20:50:53] <dilfridge> jmorgan1: not many, but still you can also add that to the default LDFLAGS in your make.conf
-[20:51:00] <ago> 4) [semantic-desktop=] (5 minutes)
-[20:51:08] <-- dMaggot (~user@201.227.175.3) hat das Netzwerk verlassen (Remote host closed the connection)
-[20:51:10] <jmorgan1> i'll test qtcore upgrade as well, i have both ppc, ppc64
-[20:51:47] <scarabeus> ago: no subscription to -dev
-[20:51:51] <scarabeus> ago: so i can't start the chat
-[20:51:55] --> dMaggot (~user@201.227.175.3) hat #gentoo-meetings betreten
-[20:52:13] <dilfridge> ago: scarabeus: I'll do it
-[20:52:34] <ago> scarabeus: subscriptions are open :P
-[20:52:47] <dilfridge> 4) [semantic-desktop=] (5 minutes)
-[20:53:03] <scarabeus> so the = on semantic desktop was because it was needed due to broken deps
-[20:53:10] <scarabeus> nowdays it is pointless as everything was fixed
-[20:53:14] <scarabeus> so you can switch to ?
-[20:53:20] <dilfridge> ok excellent
-[20:53:25] <dilfridge> anyone objecting?
-[20:54:03] <creffett> go for it
-[20:54:11] <dilfridge> maybe we do that with 4.10.2, so nothing big changes before the stabilization
-[20:54:11] <jmorgan1> sounds good
-[20:55:04] <ago> good
-[20:55:14] <ago> dilfridge: +1 you right
-[20:57:01] <jmorgan1> have to change rooms, brb
-[20:57:10] <ago> ok cu
-[20:57:12] <creffett> next on the agenda?
-[20:57:27] <dilfridge> 5) Remove obsolete news entries
-[20:58:12] <ago> fine for me. I'd say to leave at least the last 2011-05-22-kdeprefix
-[20:58:44] <creffett> if people haven't upgraded from kdeprefix by now...
-[20:58:47] <dilfridge> we should remove it, because getting kdeprefix news on a *NEW INSTALLATION* is stoopid
-[20:59:10] <ago> right to
-[20:59:14] <ago> o*
-[21:00:32] <dilfridge> besides kdeprefix use flag was masked since 2009
-[21:00:54] <dilfridge> +1 for removing the listed items
-[21:01:14] <ago> +1
-[21:01:26] <creffett> +1
-[21:02:47] <scarabeus> +1
-[21:03:01] <dilfridge> Like
-[21:03:56] <ago> dastergon: ^
-[21:05:17] <dastergon> +1 from me, cleaning old stuff sound fine
-[21:05:28] <dastergon> s/sound/sounds
-[21:05:44] <ago> ok, next point
-[21:05:54] <ago> Bugs (10 minutes)
-[21:06:08] <ago> x11-themes/oxygen-gtk opinion?
-[21:06:31] <dilfridge> do it the same way as gtk+, i.e. two slots
-[21:10:02] <ago> sorry I don't understand it at all
-[21:10:21] <ago> we already have 2 slots in tree, what we should import from the overlay?
-[21:10:28] <ago> Rename x11-themes/oxygen-gtk to x11-themes/oxygen-gtk2. Import x11-themes/oxygen-gtk3 from the overlay or we keep x11-themes/oxygen-gtk with 2 slot and rename x11-themes/oxygen-gtk3 to x11-themes/oxygen-gtk.
-[21:11:29] <dilfridge> indeed you are correct
-[21:11:59] <dilfridge> probably the only thing that should be done here is delete the live ebuild in the overlay
-[21:12:11] <dastergon> that bug it was also a topic in January's meeting
-[21:12:24] <ago> ok, probably we forgot to delete it
-[21:12:28] -*- creffett has to move buildings, back in 10 or so
-[21:12:55] <dilfridge> hmm when I move buildings that usually takes longer, need to find a forklift first...
-[21:16:18] <ago> ok, probably all of us is busy? I don't see an active partecipation, maybe we want discuss about bugs in the next meetings ?
-[21:16:23] <dilfridge> err
-[21:16:40] <dilfridge> ago: just keep pushing :)
-[21:16:44] <-- creffett (~creffett@gentoo/developer/creffett) hat das Netzwerk verlassen (Ping timeout: 255 seconds)
-[21:18:12] <dilfridge> kde-base/kde-meta ebuild improvement proposal (bug #456248, bug #460634) 
-[21:18:13] <willikins> dilfridge: https://bugs.gentoo.org/456248 "kde-base/kde-meta ebuild improvement proposal."; Gentoo Linux, KDE; RESO, WONT; voron1:kde
-[21:18:16] <dilfridge> opinions?
-[21:19:04] <ago> the attachment is not a diff :P
-[21:19:06] <ago> wth
-[21:19:31] <dilfridge> the question has been asked and silence has fallen
-[21:20:08] <dastergon> I agree with the quote "if you don't want all kde packages, you shouldn't use kde-meta".
-[21:20:32] <ago> ok, real diff for all: http://bpaste.net/show/85433/
-[21:20:37] <dilfridge> imho we could add (few, 1-2) useflags, as eg. "games"
-[21:21:00] <dilfridge> nah, too much
-[21:21:21] <dilfridge> ago: it makes sense if the useflag switches stuff off across several metas
-[21:21:24] <ago> I agree with jmbsvicetto, so leave as is for me
-[21:21:40] --> iamnr3 (~quassel@78.142.111.42) hat #gentoo-meetings betreten
-[21:21:40] <dilfridge> e.g. disables all games in all packages (not just kdegames)
-[21:21:50] <dilfridge> but just disabling one sub-meta makes not much sense
-[21:21:55] <dastergon> yeah
-[21:22:04] <dilfridge> so, maybe just leave it as it is now
-[21:22:10] <dastergon> +1
-[21:22:34] <dastergon> we can improve documentation to explain that
-[21:22:54] <dastergon> or not :D
-[21:23:17] <ago> scarabeus: ^ ?
-[21:23:28] --> creffett (~creffett@gentoo/developer/creffett) hat #gentoo-meetings betreten
-[21:24:07] -*- creffett back if meeting is still going on
-[21:24:29] <dastergon> we couldn't end the meeting without the lead :p
-[21:24:33] <dilfridge> creffett: it is... just talking about useflags in metas
-[21:24:34] <scarabeus> i dont like uses on this
-[21:24:37] <creffett> oh, this one
-[21:24:45] <scarabeus> but i let you guys pick whatever rocks on your day
-[21:24:53] <scarabeus> we should prolly just propagate custom sets
-[21:24:56] <creffett> what was our original rationale for "no uses in meta packages"?
-[21:25:01] <dilfridge> no sets please
-[21:26:53] <jmorgan1> back
-[21:27:20] <dilfridge> ok I think the best conclusion is "no additional useflags now"
-[21:27:43] <ago> yes
-[21:27:55] <jmorgan1> 5) +1 - remove old items
-[21:28:10] -*- dastergon agrees with dilfridge 
-[21:29:02] <creffett> +1 no useflags, I guess
-[21:30:33] <dilfridge> yo
-[21:30:34] <dilfridge> next
-[21:30:44] <dilfridge> Add 'app-arch/unzip natspec' to profiles/targets/desktop/kde/package.use (bug #457934) 
-[21:30:45] <willikins> dilfridge: https://bugs.gentoo.org/457934 "Add 'app-arch/unzip natspec' to profiles/targets/desktop/kde/package.use"; Gentoo Linux, Eclasses and Profiles; UNCO; wyatt.epp:kde
-[21:31:07] <dilfridge> makes sense imho
-[21:31:15] <creffett> go for it
-[21:31:22] <dilfridge> kensington is adding useflags there anyway
-[21:32:02] <dilfridge> any further opinions?
-[21:32:08] <dilfridge> 1,
-[21:32:11] <dilfridge> 2,
-[21:32:14] <dilfridge> 3,
-[21:32:17] <ago> yes
-[21:32:18] <dilfridge> seems not.
-[21:32:20] <jmorgan1> yes
-[21:32:41] <dilfridge> ok
-[21:32:45] <dilfridge> remaining bugs
-[21:32:47] <ago> dilfridge: is natspec enabled only for the kde profile?
-[21:33:09] <dilfridge> it would be only for the kde profile, yes, anything else needs discussion with more people
-[21:33:40] <ago> I guess it should be enabled when people use kde also with other profiles, what do you think ?
-[21:33:40] <dilfridge> 5 more bugs to go, then we're finished
-[21:34:04] <dilfridge> ago: well, if we depend anywhere on unzip, we could just depend on that useflag too
-[21:34:41] <dilfridge> but we don't
-[21:34:45] <dilfridge> not in kde-base
-[21:34:55] <jmorgan1> i think we should support kde profile not just kde use flag
-[21:35:26] <dilfridge> ok
-[21:35:27] <dilfridge> next bug
-[21:35:41] <dilfridge> Bug 435584 - kde-base/kdelibs - patch to fix directory icon breakage for NFS mounts since KDE 4.7.4
-[21:35:42] <willikins> dilfridge: https://bugs.gentoo.org/435584 "kde-base/kdelibs - patch to fix directory icon breakage for NFS mounts since KDE 4.7.4"; Gentoo Linux, KDE; UNCO; nitro:kde
-[21:36:03] <dilfridge> basically nfs and samba are treated as slow filesystems, and icon loading is turned off.
-[21:36:12] <dilfridge> use reqests to revert that commit
-[21:36:35] <dilfridge> no real opinion here
-[21:37:21] <ago> dilfridge: as said, maybe we can discuss this with more people partecipation
-[21:37:24] <ago>  :)
-[21:37:26] <dilfridge> ok
-[21:37:36] <creffett> in the grand scheme of thigns, I don't think this one matters enough to merit a patch
-[21:37:39] <ago> I have a proposal as open floor
-[21:37:52] <creffett> so...I'd say resolve wontfix and point out that we already do support epatch_user
-[21:37:59] <dilfridge> ago: slacker marks for kde meetings?
-[21:39:02] <ago> dilfridge: ahaha no. the herds contain 14 people, but in the meeting there are always few. So probably we can make a file where someone can say the time preference and in case we can review the meeting time ?
-[21:39:10] <ago> e.g. kensington is unable to partecipate
-[21:42:06] <dilfridge> ok shall we close the meeting and continue next month?
-[21:42:13] <jmorgan1> one more item
-[21:42:18] <dastergon> open floor ??
-[21:42:28] <jmorgan1> im looking to stable kde-4.9.5 on ppc64
-[21:42:34] <dilfridge> ok
-[21:42:48] <jmorgan1> i think  ppc is already stable
-[21:43:14] <jmorgan1> bugs can be assigned to me if needed
-[21:43:58] <jmorgan1> objections?
-[21:44:20] <ago> jmorgan1: do it to me :) I will handle as kde-stable
-[21:44:33] <ago> then since it will be stable, you are welcome as ppc64 member
-[21:44:40] <jmorgan1> ago: ok, cool
-[21:44:45] <jmorgan1> oh, to kde-stable?
-[21:45:06] <jmorgan1> you can add as x86_64 too then
-[21:45:19] <ago> jmorgan1: but, since we will stabilize 4.10.1 in few time and remove 4.9.5, make sense stabilize 495 now?
-[21:45:42] <jmorgan1> well, let me test qtcore upgrade to fix rocs issue
-[21:45:51] <jmorgan1> if that works, then no stable 4.9.5
-[21:45:54] <jmorgan1> just 4.10.1
-[21:46:14] <jmorgan1> i'll check in the next 24h or so
-[21:46:20] <ago> jmorgan1: ok....
-[21:46:21] <jmorgan1> have an answer
-[21:46:42] <jmorgan1> thx
-[21:46:55] <jmorgan1> dones
-[21:48:30] <dilfridge> anything else for open floor?
-[21:48:36] <dastergon> yeap
-[21:48:36] <creffett> nothing here
-[21:48:48] <dilfridge> dastergon: go ahead
-[21:48:58] <dMaggot> last weekend I put up somre repos for qt-gstreamer
-[21:49:06] <dMaggot> that split the qt-glib thing from qt-gstreamer
-[21:49:14] <dMaggot> kensington is following on the bug reports upstream
-[21:49:20] <dMaggot> no news from upstream yet
-[21:49:30] <dastergon> for those who didn't know I joined bugday team and I am trying to revive that day
-[21:49:59] <dastergon> I'd like to enable the bugday flag in any bugs that you think
-[21:50:23] <dastergon> it would be good
-[21:50:29] <dastergon> to close them that day
-[21:51:55] <dastergon> what do you think about some herd's bugs ?
-[21:52:44] -*- dilfridge thinks it's too late to think
-[21:52:56] -*- creffett thinks the same, and it's only 5PM here :)
-[21:53:30] <jmorgan1> i think its a good idea assuming the bugday team has reasources to resolve/track them
-[21:55:36] <jmorgan1> i have to drop off - next meeting
-[21:57:25] <dilfridge> anything else for open floor?
-[21:58:35] <dastergon> nope
-[21:59:12] <creffett> I'm good
-[21:59:12] <dilfridge> ago: wanna close the meeting?
-[22:01:21] <dilfridge> ok
-[22:01:28] -*- dilfridge bangs on the table
-[22:01:30] <dilfridge> meeting closed
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20130523.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20130523.txt
deleted file mode 100644
index 7048a7b038..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20130523.txt
+++ /dev/null
@@ -1,407 +0,0 @@
-[21:01:12] <jmbsvicetto> Hello
-[21:01:16] <ago> hola
-[21:01:17] <Thev00d00> I am here
-[21:01:23] <dilfridge> Hallihallo
-[21:01:26] --> scarabeus (~scarabeus@gentoo/developer/flyingspaghettimonster/scarabeus) hat #gentoo-meetings betreten
-[21:01:32] <scarabeus> sup
-[21:01:36] <Thev00d00> though I may be going soon, so lets get this party started :)
-[21:02:50] <johu> 1. roll call
-[21:03:01] <johu> !herd kde
-[21:03:01] <willikins> (kde) abcd, ago, alexxy, creffett, dastergon, dilfridge, jmbsvicetto, jmorgan, johu, kensington, mschiff, patrick, reavertm, scarabeus, thev00d00
-[21:03:07] <jmbsvicetto> here
-[21:03:12] <ago> here
-[21:03:15] <dilfridge> here
-[21:03:15] <Thev00d00> here
-[21:03:16] -*- johu here
-[21:03:18] -*- alexxy here
-[21:03:32] <ago> wow, 6 people :D
-[21:03:45] <johu> +scarabeus
-[21:03:53] <johu> 2. Optional semantic-desktop support
-[21:04:18] <johu> Some parts of KDE upstream no longer have optional support for semantic-desktop. We currently work around this by using ugly hacks but it is fragile causing bugs like bug #468104 and bug #465322. It is apparently easy to disable semantic-desktop features at runtime.
-[21:04:19] <willikins> johu: https://bugs.gentoo.org/468104 "kde-base/plasma-workspace-4.10.2 build error with Nepomuk2"; Gentoo Linux, KDE; CONF; christopher.smith:kde
-[21:04:24] <ago> the herd is populated by 15 people...I wondering if we need to talk about the hour preference of the meeting
-[21:04:29] <johu> Options:
-[21:04:29] <johu> Do nothing and add more fixes/hacks as bugs crop up
-[21:04:29] <johu> Track upstream more closely and support optional semantic-desktop only where supported by upstream (noting that find_package() can be controlled these days unless it explicitly has a REQUIRED)
-[21:04:30] <johu> Drop semantic-desktop USE flag completely
-[21:05:00] <johu> ago: wrong topic
-[21:05:08] -*- dilfridge suggests "drop useflag completely and focus efforts on more worthwhile issues"
-[21:05:09] -*- Thev00d00 votes for: Drop semantic-desktop USE flag completely
-[21:05:17] <ago> TBH, I have kde on my netbook because of -semantic-desktop, with semantic-desktop enabled it was too much slowly...so I'd like to see it as -is
-[21:05:35] <dilfridge> ago: just disable the file indexer, then you are fine
-[21:05:37] <johu> but you can disable it on runtime
-[21:05:43] <scarabeus> go with dropping
-[21:05:47] <scarabeus> nowdays it is not so broken
-[21:05:50] <johu> ok lets vote
-[21:05:52] <scarabeus> and the off switch finaly works
-[21:05:53] <dilfridge> I'm also not really using semantic-desktop
-[21:06:06] <johu> who is for drop?
-[21:06:11] -*- ago votes do nothing
-[21:06:12] -*- dilfridge is for drop
-[21:06:24] -*- johu +drop
-[21:06:48] <dilfridge> and clearly also scarabeus and Thev00d00 as seen above
-[21:06:59] <jmbsvicetto> do nothing
-[21:07:23] <jmbsvicetto> (better would be to kill semantic-desktop, but that isn't an option)
-[21:07:27] <johu> i guess kensington is for it too because he bring it up on the table
-[21:07:36] <ago> ok, so lets drop
-[21:07:49] <scarabeus> jmbsvicetto: the switch now really works, so you have it built but disabled :-)
-[21:07:50] <johu> ok whats the course of the action then?
-[21:07:59] <johu> do we need an news item?
-[21:08:06] <dilfridge> remove the useflag in -4.10.49.9999
-[21:08:15] <johu> no in 9999
-[21:08:18] <dilfridge> johu: no because no action on user part is required
-[21:08:29] <jmbsvicetto> scarabeus: yeah and I also should systemd when I build udev, but don't have to use it ...
-[21:08:37] -*- jmbsvicetto refrains from making more comments
-[21:08:58] -*- dilfridge does not want to hear the word systemd anymore today...
-[21:09:00] <johu> i would suggest to drop it with 4.11
-[21:09:16] <ago> ++
-[21:09:26] <dilfridge> we could blog about how to disable it at runtime
-[21:09:32] <johu> time enough to get the people informed by news item etcs
-[21:09:36] <ago> dilfridge: good idea
-[21:10:18] <johu> ok i will blog about it
-[21:10:48] <johu> we can decide on a news item in the next meeting (june)
-[21:11:49] <johu> any other actions we need to do for the drop?
-[21:12:21] <dilfridge> simplify code, afterwards
-[21:12:35] <dilfridge> check dependencies in external packages
-[21:12:54] <dilfridge> [semantic-desktop] -> [semantic-desktop(+)]
-[21:13:06] <dilfridge> (we can already do that now)
-[21:13:25] <johu> yes
-[21:13:47] <johu> 3. Drop oldpim?
-[21:14:12] <johu> yes / no / maybe
-[21:14:12] <johu> mask now immediately?
-[21:14:12] <johu> See also this link http://dilfridge.blogspot.de/2013/05/personal-experience-and-opinion-kmail2.html
-[21:14:12] <dilfridge> against
-[21:14:19] <ago> yes
-[21:14:20] <dilfridge> i.e. no
-[21:14:36] <jmbsvicetto> sorry, -EDON'TCARE
-[21:14:36] <dilfridge> we do not gain much by dropping it
-[21:14:47] -*- Thev00d00  -EDON'TCARE
-[21:14:57] <dilfridge> (the only real cruft is the -l10- splitting)
-[21:15:16] <johu> its not much effort to keep it in tree, so also EDON'TCARE
-[21:15:19] <dilfridge> impact on eclasses is 0
-[21:15:33] <ago> real question, is there someone that uses it?
-[21:15:42] <dilfridge> me :)
-[21:15:45] <johu> from the comments yes
-[21:15:57] --> reavertm (~reavertm@gentoo/developer/reavertm) hat #gentoo-meetings betreten
-[21:16:10] <johu> dilfridge: what is the state about the bugs you blogged before?
-[21:16:21] <dilfridge> kleopatra works fine again
-[21:16:26] <jmbsvicetto> ago: I don't use kdepim and only have parts of it installed because of semantic-desktop
-[21:16:34] <dilfridge> the other stuff still exists but is nonfatal
-[21:16:45] <ago> I meant if there is someone apart dilfridge
-[21:17:01] <dilfridge> only real bug is that you can't set sent mail folder per identity anymore
-[21:17:09] --> mschiff (~mschiff@gentoo/developer/mschiff) hat #gentoo-meetings betreten
-[21:17:16] <dilfridge> ^ ^ 
-[21:17:51] --> Guest43157 (46c082af@gentoo/developer/creffett) hat #gentoo-meetings betreten
-[21:17:54] <johu> i would suggest as everytime it comes on table, lets wait until its not working with new kde sc release
-[21:18:18] <johu> any objections, if not i move to the next topic
-[21:18:21] <johu> ?
-[21:18:41] <dilfridge> yep. postpone. if anything pops up, assign bug to me with kde in cc
-[21:18:46] <-> Guest43157 heißt jetzt creffett|mobile
-[21:19:04] <johu> 4. Handling of systemd patches
-[21:19:10] <johu> let's just agree on a consistent way of handling it (as long as noone from kde team runs systemd)
-[21:19:19] <ago> I run it
-[21:19:23] <dilfridge> :)
-[21:19:25] <dilfridge> Yay
-[21:19:25] -*- creffett|mobile is here, sorry. Dinner running late
-[21:19:40] <johu> i already run it on my netbook
-[21:19:43] <ago> If there is somthing to test, feel free to cc me everytime
-[21:19:43] <johu> BUT
-[21:20:20] <johu> what i miss in the whole discussion is the fact that systemd is about standardization
-[21:20:33] <johu> and not about boot time
-[21:20:36] <jmbsvicetto> My general opinion about systemd unit files is that we should wait / let it up to upstream
-[21:20:56] <johu> and if we add thousands of patches downstream the goal is totally failed
-[21:21:03] <jmbsvicetto> I personally am unwilling to work on it (kde or elsewhere on Gentoo)
-[21:21:19] <dilfridge> well
-[21:21:33] <johu> and we never add patches to add new features in kde packages...
-[21:21:45] <ago> I'd suggest also to forward upstrem the patch we see in the bugzilla
-[21:21:50] <johu> let kde upstream handle the stuff
-[21:21:53] <jmbsvicetto> I also don't like getting tons of bugs to add systemd support to X, Y, Z. Those wanting systemd should be convicing X, Y and Z to support it
-[21:22:06] <dilfridge> how about "feel free to add patches that have been accepted upstream"
-[21:22:50] <johu> whats the point to backport this when the release is in 8 weeks?
-[21:23:24] <jmbsvicetto> dilfridge: If the patch is going to be added by upstream, if someone else (not me) is doing that work and it doesn't break or affect those running openrc, no objection from me
-[21:23:56] <ago> jmbsvicetto: ++
-[21:24:24] <dilfridge> jmbsvicetto: well, that comment was intended as "reply to our systemd guys"
-[21:24:35] <creffett|mobile> But people will still complain "I gave you the file, it's trivial to add"
-[21:24:42] <Thev00d00> I use systemd
-[21:24:56] <Thev00d00> I am happy to support the systemd patches/unit files
-[21:25:03] <Thev00d00> possibly with ago
-[21:25:16] <dilfridge> I think we're running into the same trap as the dev ml
-[21:25:24] <ago> creffett|mobile: I think that we need to check if thservice start
-[21:25:27] <dilfridge> We should not worry too much about small support files
-[21:25:43] <ago> apart kdm do we have a lot of packages that installs an init script?
-[21:25:46] <dilfridge> but just add them if they are helpful and do not hurt otherwise.
-[21:25:49] <johu> we dont need to discuss the small unit files....
-[21:26:16] <dilfridge> the only thing worth discussing are significant patches for code
-[21:26:18] <johu> its already added in kde-base/kdm
-[21:26:45] <johu>  and i add the gentoo unit file in upstream bug
-[21:26:52] <ago> last kdm works for me
-[21:28:15] <johu> if we start to add not reviewed source code patches i will leave the herd for sure
-[21:28:38] <johu> its not about systemd, its about the correct way
-[21:29:04] <ago> johu: we suggest to add the code to kde codereview, if it is accepted then we will include
-[21:29:23] <creffett|mobile> ++
-[21:29:26] <dilfridge> ++
-[21:29:28] <johu> ago: thats what i have done in the bug
-[21:29:53] <dilfridge> ok let me try to summarize:
-[21:30:19] <Thev00d00> So this means we as a herd from now on will only apply patches that have been accepted upstream?
-[21:30:24] <ago> johu: and that's the correct way, so let's continue
-[21:30:41] <ago> but if our packages does not install a init script, we don't need to discuss anymore
-[21:31:32] <dilfridge> "Small support files as e.g. unit files that affect only systemd but do not interfere with other software can be added locally but should eventually be upstreamed. Patches for adding functionality should be accepted upstream first."
-[21:31:41] <dilfridge> sounds ok?
-[21:32:01] <Thev00d00> dilfridge: so long as this is not only for systemd
-[21:32:01] <johu> sound like music
-[21:32:01] <ago> yes
-[21:32:10] <creffett|mobile> good here
-[21:32:20] <dilfridge> Thev00d00: basically it's already the policy...
-[21:32:21] <johu> ++
-[21:32:47] <johu> refreshing a policy is a good thing
-[21:33:01] <johu> 5. Bugs
-[21:33:16] <johu> bug 438790
-[21:33:18] <willikins> johu: https://bugs.gentoo.org/438790 "kde-misc/polkit-kde-kcmodules: Store polkit configuration changes to /etc instead of /usr"; Gentoo Linux, KDE; IN_P; nikoli:kde
-[21:33:27] <dilfridge> sigh
-[21:33:58] <creffett|mobile> Nothing from upstream yet on that
-[21:34:31] <dilfridge> didn't other distros patch that? maybe we could attach someone's code to that bugreport...
-[21:34:39] <creffett|mobile> By the time they have a fix frameworks 5 will be out and this will be irrelevant
-[21:34:40] <johu> who was working on that bug, it was in my off time
-[21:34:47] <creffett|mobile> Me
-[21:34:57] <dilfridge> i think this is fixed in fedora
-[21:35:52] <dilfridge> there was a thread about it on the release-team ml I think (but I dont have my archive here)
-[21:36:21] <creffett|mobile> I believe so, but am not sure, and it worries me that most dostros said they don't ship that module
-[21:36:46] <johu> http://pkgs.fedoraproject.org/cgit/kdelibs.git/tree/kdelibs-4.6.90-kstandarddirs.patch
-[21:37:47] <dilfridge> err
-[21:37:53] <johu> that was the link posted in the ml thread
-[21:37:54] <johu> ...
-[21:37:54] <dilfridge> how do I get that page to show code?
-[21:38:33] <johu> maybe they have dropped it in the meantime
-[21:38:43] <dilfridge> http://pkgs.fedoraproject.org/cgit/kdelibs.git/tree/kdelibs-4.10.0-kstandarddirs.patch
-[21:38:46] <dilfridge> more useful
-[21:38:51] <creffett|mobile> I will try that patch when I return from vacation and we can include it in the next bump
-[21:39:22] <johu> is there an chance to get it upstreamed?
-[21:39:34] <dilfridge> we're just falling into our own trap :D
-[21:39:39] <dilfridge> creffett|mobile: ^
-[21:41:37] <creffett|mobile> Well yeah
-[21:41:42] <johu> when the bug is not in hurry we could try to get it in before 4.11
-[21:42:17] <dilfridge> actually that looks small enough so it's realistic
-[21:42:17] <creffett|mobile> But this is a fairly major issue
-[21:42:47] <creffett|mobile> And I repeat that most distros do not ship this module
-[21:43:01] <dilfridge> yes, which lets me wonder why
-[21:43:10] <dilfridge> (does fedora?)
-[21:43:13] <johu> yeah we could drop the package...
-[21:43:27] -*- Thev00d00 votes drop it
-[21:44:24] <creffett|mobile> I think it isn't officially released
-[21:45:21] <dilfridge> no opinion here
-[21:45:28] <creffett|mobile> I vote make it no longer a kdelibs dep
-[21:46:07] <johu> thats not a complete solution
-[21:46:21] <johu> either we fix it or we drop it
-[21:46:22] <dilfridge> what does the package actually do?
-[21:47:33] <dilfridge> ^ ^ 
-[21:47:33] <johu> i guess you can manage the polkit rules
-[21:47:37] <creffett|mobile> Not sure tbh
-[21:48:03] <dilfridge> so we're going through a lot of pain because of something buggy that noone uses or even knows what it's good for. awesome.
-[21:48:39] <dilfridge> lastrite?
-[21:48:51] <johu> vote!
-[21:49:11] <dilfridge> options?
-[21:49:31] <johu> 1. get fedora patch upstream
-[21:49:45] <dilfridge> (and patch polkit-kde-kcmodules as required for that)
-[21:50:17] <johu> 2. get rid of it
-[21:50:34] <johu> 3.?
-[21:50:53] <dilfridge> 3. drop it as kdelibs dependency and drop it to ~arch
-[21:51:03] -*- ago votes 1
-[21:51:04] <Thev00d00> 3
-[21:51:15] -*- dilfridge does not care
-[21:51:15] -*- johu votes 1
-[21:51:30] --> creffett (~creffett@gentoo/developer/creffett) hat #gentoo-meetings betreten
-[21:51:33] <creffett> there we go
-[21:51:36] <creffett> much better
-[21:51:59] <-- creffett|mobile (46c082af@gentoo/developer/creffett) hat das Netzwerk verlassen (Disconnected by services)
-[21:52:12] <johu> scarabeus, jmbsvicetto ?
-[21:52:24] <johu> alexxy?
-[21:53:00] <creffett> I reluctantly vote punt it, with the caveat that we should make sure that punting it doesn't completely hose KDE before we send the lastrite
-[21:53:31] <scarabeus> not for me to decide
-[21:53:38] <scarabeus> you guys just voted to have policy upstream first
-[21:53:39] <scarabeus> :D
-[21:53:45] <scarabeus> so you cant just rape it right away
-[21:53:47] <scarabeus> :D
-[21:54:00] <johu> it was never realy released :P
-[21:54:34] <creffett> ^^
-[21:54:41] <creffett> perhaps retire it to kde overlay only?
-[21:54:50] <scarabeus> thats option
-[21:54:56] <scarabeus> wipe it from stable ebuilds would work
-[21:54:58] <johu> bugs persists in overlay too
-[21:55:05] <creffett> people shouldn't have this in their world files to start with, the only thing pulling it in is kdelibs
-[21:55:22] <creffett> yes, but for most people it won't matter anymore
-[21:55:44] <johu> creffett: you started to work on the bug you can decide on you own as lead ;)
-[21:56:02] <johu> we will cover your decision with full force
-[21:56:04] -*- creffett puts his lead hat on
-[21:56:16] -*- creffett thinks that we need a nice pope hat or something to mail around between leads
-[21:56:18] <creffett> anyway
-[21:56:27] <johu> bug 444952
-[21:56:29] <willikins> johu: https://bugs.gentoo.org/444952 "Add KDE Plasma Active support"; Gentoo Linux, KDE; CONF; creffett:kde
-[21:57:02] <creffett> unless someone seriously objects, I say move polkit-kde-kcmmodules to overlay, remove kdelibs dep, and re-evaluate if and when they get their act together upstream
-[21:57:15] <dilfridge> creffett: the lead gets a beer stein on the head at fosdem...
-[21:57:25] <johu> whats the state? why we need to discuss this?
-[21:57:29] <creffett> plasma-active was added to the overlay under kde-active category
-[21:57:43] <scarabeus> why not kde-base/
-[21:57:48] <creffett> if anything needs to be discussed, it's basically "when and how to move it to tree"
-[21:58:05] <creffett> scarabeus: no real reason besides it not strictly being part of the KDE SC or whatever they call it these days
-[21:58:12] <dilfridge> scarabeus: because it's not strictly part of KDE SC?
-[21:58:19] <creffett> nice timing.
-[21:58:41] <johu> kde-frameworks wont be part of kde sc too....
-[21:58:44] <creffett> it's not really KDE is the thing, it's a plasma product
-[21:59:04] <creffett> (which is a sub-product of KDE, I know)
-[21:59:21] <dilfridge> the kde thing is going away anyway... we should already prepare renaming ourselves...
-[21:59:21] <scarabeus> well how many packages it is
-[21:59:28] <scarabeus> no new category unless it is more than 10
-[21:59:42] <creffett> ...9.
-[22:00:03] <creffett> next question, what's a more appropriate category? do we agree that it should go in kde-base?
-[22:00:15] <dilfridge> kde-active is fine.
-[22:00:28] <johu> creffett: you could package the telepathy active client...
-[22:00:38] <johu> then you would have 10
-[22:00:40] <dilfridge> hehe, then it's 10
-[22:00:53] <creffett> that's the other thing, it's not entirely ready because there are a lot of related products that aren't fully packaged yet
-[22:00:54] <scarabeus> okey you suckers are covered here
-[22:00:55] <scarabeus> :P
-[22:01:04] <scarabeus> lets keep it in testing in cvs
-[22:01:08] <scarabeus> more eyes more bugs
-[22:01:18] <creffett> not ready to be moved yet
-[22:01:36] <creffett> since I haven't had the time to go through all of the stuff on the website listed as "supporting plasma-active"
-[22:01:43] <creffett> oh, and I honestly haven't actually had the chance to test it :P
-[22:01:58] <johu> my proposal, keep it in overlay
-[22:02:08] <creffett> it completely screws up the display of my laptop, and I don't have a mobile device I can sacrifice to the cause
-[22:02:15] <johu> make an wiki article/howto and all is fine
-[22:02:29] <creffett> okay
-[22:02:39] <creffett> and maybe even put a little traffic on -desktop for once? :P
-[22:02:46] <creffett> email out a request for testing
-[22:02:50] <johu> yeah or blog about it
-[22:03:16] <johu> bug 456750
-[22:03:18] <willikins> johu: https://bugs.gentoo.org/456750 "kde-base/plasma-desktop[-rss] unintuitive dependency on kde-base/libplasmaclock[-holidays]"; Gentoo Linux, KDE; UNCO; alpine.art.de:kde
-[22:03:30] <jmbsvicetto> I need to leave. See you guys later
-[22:03:42] <johu> jmbsvicetto: thanks for your presence
-[22:03:48] <dilfridge> cu
-[22:04:19] <Thev00d00> I g2g in a minute also, anything else left on the agenda?
-[22:04:27] <johu> yes bugs
-[22:04:40] <johu> (and open floor)
-[22:04:48] <scarabeus> the use should be renamed
-[22:04:53] <scarabeus> i never understood why we call it rss :D
-[22:05:10] <johu> scarabeus: propose a name
-[22:05:22] -*- creffett has no idea what these use flags actually control
-[22:05:23] <scarabeus>                 $(cmake-utils_use_with rss KdepimLibs)
-[22:05:29] <creffett> aha!
-[22:05:33] <scarabeus> it enables fucking semantic desktop
-[22:05:41] <scarabeus> just bind it in
-[22:05:41] <dilfridge> lol
-[22:05:44] <johu> AHAHA old topic
-[22:05:51] <creffett> then yeah, calendar/semantic-desktop might be more appropriate
-[22:05:53] <dilfridge> call it semantic-desktop and hard-enable it in 4.11 :)
-[22:06:11] <scarabeus> just to more spam
-[22:06:13] <scarabeus>         rss? (
-[22:06:13] <johu> we get rid of it when we do -semantic-desktop
-[22:06:14] <scarabeus>                 $(add_kdebase_dep kdepimlibs 'semantic-desktop?')
-[22:06:16] <scarabeus>                 $(add_kdebase_dep libplasmaclock 'holidays')
-[22:06:17] <scarabeus>         )
-[22:06:19] <scarabeus>         !rss? ( $(add_kdebase_dep libplasmaclock '-holidays') )
-[22:06:20] <scarabeus> it was even automagic there :D
-[22:06:21] <creffett> why does holidays actually need a use flag?
-[22:06:25] <scarabeus> thats reasonf or the -
-[22:06:46] <scarabeus> creffett: it crashed when you had kdepimlibs without semantic and libplasmaclock and holidays
-[22:06:53] <creffett> ah.
-[22:06:55] <creffett> okay
-[22:07:06] <johu> ok we will solve it with 4.11 ;)
-[22:07:14] <johu> i will take of it
-[22:07:16] <johu> care
-[22:07:39] <johu> bug 461684
-[22:07:40] <willikins> johu: https://bugs.gentoo.org/461684 "kde-base/kwin: backport patch to remove tearing on Intel systems"; Gentoo Linux, KDE; UNCO; mike:kde
-[22:08:32] <Thev00d00> yeah do it
-[22:08:36] <creffett> we have this up for discussion because...
-[22:08:52] <dilfridge> ... because it's large and intrusive
-[22:08:57] <creffett> ah
-[22:09:07] <creffett> that is an absurdly long discussion upstream
-[22:09:09] <Thev00d00> also see https://bugs.kde.org/show_bug.cgi?id=307965
-[22:09:12] <johu> "I am not sure if this is a good idea since there is upstream discussion about specifically avoiding KDE/4.10 branch due to the invasive nature of the patch and potential for regressions." kensingtion
-[22:09:31] <johu> i would vote against it!
-[22:09:46] <dilfridge> we should just add it into the next 4.10.X release, and if there are problems we could always revbump without the patch again
-[22:10:03] <dilfridge> so it gets some time in ~arch for testing
-[22:10:11] -*- creffett has no opinion here
-[22:10:12] <Thev00d00> Its going to be in 4.11 so any issues will get to use soon enough
-[22:10:27] <dilfridge> no strong opinion here either
-[22:11:21] <scarabeus> stay with upstream
-[22:11:22] <johu> users can always use user patches with kde packages...
-[22:11:39] <dilfridge> ok let's leave it out then
-[22:11:50] <creffett> mm, true, and we do support userpatch
-[22:12:32] <johu> bug 468002
-[22:12:34] <willikins> johu: https://bugs.gentoo.org/468002 "kde-base/kdelibs-4.10.2 ELOG output includes Your homedir is set to ${HOME}/.kde4"; Gentoo Linux, KDE; CONF; rich0:kde
-[22:12:38] <johu> fast vote
-[22:12:40] <creffett> punt it
-[22:12:41] <dilfridge> can be removed
-[22:12:42] -*- johu ++
-[22:12:44] <Thev00d00> punt
-[22:12:48] <scarabeus> kill it
-[22:12:52] <johu> ok thanks
-[22:12:56] -*- Thev00d00 loves the word punt
-[22:13:02] <dilfridge> on second thought...
-[22:13:09] <dilfridge> nah, kill it. :)
-[22:13:12] <johu> bug 468894
-[22:13:14] <willikins> johu: https://bugs.gentoo.org/468894 "Please restore kde-base/plasma-workspace-4.10.1 because of a bug"; Gentoo Linux, KDE; UNCO; gentoo:kde
-[22:13:16] <johu> fast vote
-[22:13:18] <creffett> there is absolutely no reason for people to see that message anymore :P
-[22:13:27] <dilfridge> no
-[22:13:31] <johu> no
-[22:13:31] -*- creffett votes no
-[22:13:39] <dilfridge> NI!
-[22:13:41] <creffett> also looking forward to the KDE long-term support release :P
-[22:13:52] <johu> wrong topic :D
-[22:14:33] <creffett> eh, it's related, since it's talking about keeping older versions
-[22:15:09] <johu> the bug he mentioned was already in 4.9
-[22:15:23] <creffett> true
-[22:15:25] -*- creffett shrugs
-[22:15:39] <johu> 6. Open floor
-[22:15:57] <creffett> cmake-utils now has inlined patching support in overlay
-[22:16:27] <creffett> going to eapi-bump the last few EAPI < 2 packages myself soon since it's been plenty of time for the maintainers to do it
-[22:16:50] <johu> which reminds me to remind you to make a tracker out of the monolithic bug mess
-[22:17:08] <creffett> and that reminds me to say "meh, I'm bumping it all myself"
-[22:17:33] <johu> fine but in the future make TRACKER bugs..
-[22:17:38] <creffett> will do
-[22:18:04] <johu> i have at least 2 more topics
-[22:18:42] <johu> i dont like that kde-stable is not using our mail alias
-[22:19:33] <johu> all the things that tampakrap mentioned when the sub-projects are true in my opinion
-[22:20:10] <dilfridge> hmm? anything I missed?
-[22:21:03] <johu> you can read the log from last october again, its only my opinion no need for action at the moment
-[22:22:13] <johu> and additionally i had the feeling that the stabilization of 4.10.1 was to early for the 4.10
-[22:22:58] <johu> so enough bad vibrations:
-[22:23:27] <johu> as you may noticed i am back with full force as you may noticed in the last weeks
-[22:23:37] <creffett> who are you, again? ;)
-[22:24:50] <johu> kensington's offtopic: There is a prototype reviewboard instance setup for use with the KDE overlay[1]
-[22:25:01] <johu> http://astralcloak.net/~kensington/rb/
-[22:26:12] <scarabeus> i would rather see running gerrit gentoo instance for all projects
-[22:26:19] <scarabeus> *like to
-[22:27:02] <Thev00d00> gerrit++
-[22:27:33] <johu> we could ask kensington if he wants to host a test gerrit instance
-[22:27:40] <johu> to compare
-[22:27:43] <dilfridge> gerrit is overcomplicated
-[22:27:47] <dilfridge> imho
-[22:28:13] <dilfridge> patches of patches of patches
-[22:28:21] <scarabeus> dilfridge: not really
-[22:28:24] <scarabeus> worked with both
-[22:28:29] <scarabeus> and gerrit is actually easier
-[22:28:38] <scarabeus> for usage on both sides
-[22:28:41] <scarabeus> reviewer and submitter
-[22:28:48] <dilfridge> ok
-[22:28:53] <dilfridge> no opinion here
-[22:29:09] <scarabeus> in lo i just do "gerrit push" and "gerrit review id" if i feel like not using gui
-[22:29:22] <scarabeus> and on web interface i can inline comments and approve commits directly
-[22:29:28] <scarabeus> so i can do that even from tablet
-[22:30:21] <dilfridge> ok
-[22:30:29] <dilfridge> so who is setting up a test instance? :D
-[22:30:35] <johu> lets ask kensington to host a gerrit instance to test it and compare with reviewboard and then decide which we want to push into gentoo infra
-[22:30:57] <dilfridge> btw did anything come from that gitlab discussion?
-[22:31:05] <scarabeus> theo didnt mind if someone is willing to maintain it
-[22:31:58] <johu> hm he should care about his hom(i)e herd
-[22:32:24] <johu> any other topics?
-[22:32:28] <creffett> nothing here
-[22:33:04] <johu> FYI git kdenetwork migration is in progress
-[22:33:39] <johu> thank you all
-[22:33:42] <johu> meeting closed
-[22:33:52] <Thev00d00> g'nite
-[22:34:51] <scarabeus> nn
-[22:35:02] <creffett> 'night
-[22:35:02] <-- creffett (~creffett@gentoo/developer/creffett) hat #gentoo-meetings verlassen
-[22:35:39] <dilfridge> nite
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20140329.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20140329.txt
deleted file mode 100644
index d8a842a63d..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20140329.txt
+++ /dev/null
@@ -1,456 +0,0 @@
-<johu> 1. Roll call (5 minutes)
-<johu> !herd kde
--*- creffett|irssi here
-<willikins> (kde) ago, alexxy, creffett, dastergon, dilfridge, jcallen, jmbsvicetto, jmorgan, johu, kensington, mrueg, mschiff, patrick, reavertm, scarabeus, thev00d00
--*- scarabeus beeps
-<kensington> hi
-<mrueg> pong.
--*- johu here
-<johu> 2. EAPI 4 kde4.eclasses deprecation (10 minutes)
-<johu> - KDE overlay is fully migrated to EAPI 5 and all older EAPI's are banned
-<johu> - No issues known with EAPI 5
-<johu> - Discuss and vote
-<creffett|irssi> question: I know we've handled this in-overlay, but what's the state of packages in-tree?
--*- jcallen is here
-<johu> i bumped alot to EAPI 5
-<mrueg> let me check.
-<creffett|irssi> (would be nice if pkgcore worked enough to give us the EAPI-by-eclass breakdown)
-<johu> so its only a question of stable requests and some packages not maintained by us
-<kensington> pkgcore-9999 works good enough now
-<kensington> and it fixed on qa-reports I think
-<johu> yes qa-reports is fixed
-<creffett|irssi> really.
-<johu> thats why i started to do the tree EAPI 5 work
-<creffett|irssi> news to me
-<kensington> we should ban it in the overlay and in the tree once that's cleaned up
-<mrueg> kde-base: 21, kde-misc: 20 eapi 4 packages (eapi per cat)
-<creffett|irssi> so...bump the requirement in-overlay, news item on -dev or -dev-announce, file bugs?
-<kensington> http://qa-reports.gentoo.org/output/eapi-per-eclass/kde4-base.eclass/4.txt
-<johu> ^^ most of them have already EAPI 5 rev bumps
-<kensington> cool
-<scarabeus> then stablereq and request cleanup
-<creffett|irssi> yup
-<johu> around 20th april we can start mass stabilization and see whats left
-<mrueg> so eapi4 ban would mean drop kdepim 4.4.x, right?
-<kensington> mrueg: I wish
-<johu> nope
-<creffett|irssi> are those not EAPI 5?
-<johu> we just bump them to EAPI 5
-<creffett|irssi> yeah
-<johu> i poked dilfridge about it already and he wants to do it
-<creffett|irssi> probably no need for a revbump, tbh
-<mrueg> creffett|irssi: just checked for knotes still eapi=4
-<creffett|irssi> kk
-<kensington> creffett|irssi: it's stable packages
-<creffett|irssi> kensington: blarg
-<johu> anyone who wants to keep EAPI 4?
-<kensington> punt it
-<johu> ok vote:
-<mrueg> no need to keep, but what is the need to punt it?
-<creffett|irssi> I know it's stable, but I doubt the bump will actually change installed files, and those aren't using any eaapi features, afaik
-<mrueg> just progress?
-<creffett|irssi> +1 burnintae
-<creffett|irssi> *burninate
-<johu> +1
-<kensington> mrueg: for 4 -> 5 not much, but eg. it might let us assume subslot support for something in the future
-<scarabeus> should be fine for 4->5 so +1
-<johu> creffett|irssi: we have already subslots implement for kde-base in the eclass
-<creffett|irssi> johu: oh, right, forgot about those
-<creffett|irssi> revbump it is.
-<mrueg> kensington: i just wonder if ebuilds in overlays will fail because eclass disallows <eapi-5
-<kensington> in the past, dropping <3 let us clean up a lot of junk from the eclasses
-<mrueg> *non-kde
-<mrueg> overlays
-<creffett|irssi> mrueg: not our problem
-<kensington> they will, that's their problem, we will announce as per usual
-<creffett|irssi> we announce it
-<creffett|irssi> they fix their own
-<mrueg> okay sounds good. :)
-<mrueg> +1
-<kensington> I did a couple of the 'major' ones for the las ttime
-<johu> we make a tracker for the packages not maintained by us
-<creffett|irssi> yup; I can do that if you'd like
-<johu> creffett|irssi: lets do it after the mass stabilization
-<mrueg> it would be nice to get a repoman error if eapi is deprecated for used eclass
-<creffett|irssi> okay
-<creffett|irssi> mrueg: that would require eclasses have a DEPRECATED_EAPIS sort of variable
-<creffett|irssi> which would be nice, admittedly
-<johu> creffett|irssi: raise that topic in qa please
-<mrueg> yep 
-<johu> :)
-<creffett|irssi> johu: in portage, actually :P
-<creffett|irssi> mrueg: file a bug :)
-<mrueg> probably talk to TomWij
-<mrueg> or file a bug ;)
-<mrueg> will do.
-<johu> next topic
-<creffett|irssi> I would look into it if I had time in the next...two months.
-<johu> 3. KDE overlay contribution model (10 minutes)
-<creffett|irssi> mmkay
-<johu> - We have a github mirror, which offers pull requests, reviews and comments
-<johu> - Allows us to get more QA for user contributions
-<johu> - Proposal: Drop all user ssh keys from overlay and promote the github contribution model (for example with a overlay news item)
-<johu> - Discuss and vote
--*- creffett|irssi is in favor of switching to github/pullreq model and dropping users' keys
-<kensington> I am against dropping all user ssh keys
--*- mrueg wants to wait until infra deploys gitolite-3 on gogo
-<johu> mrueg: what offers gitolite-3?
-<mrueg> johu: easier mirroring
-<kensington> we should encourage pullreqs for more user contributions, but I think some users is fine to commit directly
-<creffett|irssi> kensington: hmm, that's valid
-<johu> kensington: but where you draw the border
-<creffett|irssi> that said, there have been a couple problematic commits as of late
-<johu> one user drop one not
-<kensington> I don't think we even have a list of who has access
-<johu> thats easy question for infra...
--*- creffett|irssi asks
-<mrueg> right now mirroring means someone with access to both repositories does this on git push and pull, right?
-<kensington> dastergon can probably help with that
-<kensington> mrueg: yes, no server automation is currently supported
-<creffett|irssi> so we come back to the question of who we want to have access
-<kensington> infra won't do a hook, and github need to contact their support to have them mirror
-<johu> kensington: please propose the criteria which user can proceed to commit and who not
-<johu> imho it should be consistent
-<creffett|irssi> the thing is that most commits I've seen have been devs; of non-devs, there have only been a couple committing regularly, and at least one of those has been subpar
-<creffett|irssi> iow, we don't have a high non-dev commit rate to start with I think
-<mrueg> we could allow only pushes to a non-master branch for users and merge it regularly
-<kensington> it's impossible to have a list of checkboxes
-<kensington> in general, makes enough patches that are good seems like a good rule, it worked in the past
-<scarabeus> nah just do it simple, they start with pull requests and if they are good they get the commit access directly, if they screw up they loose it
-<kensington> scarabeus++
-<creffett|irssi> good enough for me
-<kensington> that's what we used to do anyway, except with patch on bugzie instead of pull request
-<creffett|irssi> but do we keep everyone's access?
-<scarabeus> also *lose... :D
-<creffett|irssi> for those interested:
-<creffett|irssi> 13:28 <@a3li> hi creffett|irssi, I'd have this list of additional keys besides all developers for you: caleb christian civil creffett cryos dastergon dessa devurandom dmaggot eliasp genstef helgc
-<creffett|irssi>               idella4 johu kensington krytzz letharion lxnay mattepiu mrueg mschiff mva okias ronis_br skiarxon spatz sput terietor tgurr travlr wizzleby wohnout yngwin
-<creffett|irssi> I...uh..have no idea who half of those people are.
-<creffett|irssi> :P
-<kensington> and the other half is people that went on to be devs :p
-<creffett|irssi> yup
-<creffett|irssi> so do we want to keep all of those?
-<johu> i raised this topic to make the contribution easier for non-devs and as github is generally accepted i think this is the consistent way
-<johu> for example clean up wiki page with contribution info
-<johu> remove hackers file etc etc
-<creffett|irssi> yeah
--*- johu thinking in long term to a git migrated tree :D
-<mrueg> johu: heh. 
--*- creffett|irssi drinks
-<mrueg> can anyone add a instruction how to mirror both repositories? 
-<mrueg> last time i tried to merge a pull request on my own overlay, it went all mad.
-<creffett|irssi> so for the moment, any objections to leaving current contributors with access and switching to encouraging everyone else to use github pullreqs?
-<mrueg> ++
-<johu> fine by me
-<kensington> mrueg: I personally use github "merge on command line" instruction, then rebase and push
-<kensington> otherwise you can merge in github ui, pull, then push to gogo
-<johu> mrueg: you have to add another remote to you local git clone
-<creffett|irssi> kensington, scarabeus: any objections?
-<creffett|irssi> jcallen: and you
-<kensington> creffett|irssi: no, since this is the current process anyway :p
-<mrueg> kensington, johu: an example gitconfig would be nice. ;)
-<creffett|irssi> well, that's a majority
-<creffett|irssi> johu: your turn
-<kensington> mrueg: http://bpaste.net/show/195334/
-<johu> http://dpaste.com/1763251/
-<mrueg> thanks
-<mrueg> looks like i did something wrong here. http://bpaste.net/show/pqp20cn2F7hNvn7aQjWI/ ;)
-<johu> so please vote on the general plan
-<kensington> I have no problem with cleaning up at least some of the access list, I agree there have been some 'interesting' commits lately
-<johu> with the exception of not dropping keys at once
-<creffett|irssi> +1
-<johu> +1
-<kensington> +1
-<johu> ok i will prepare a news item and send it to kde
-<johu> @
-<johu> we can optimize it then
-<creffett|irssi> sounds good
-<johu> next topic
-<johu> 4. KDE Frameworks 5 (15 minutes)
-<kensington> yay!
-<johu> Overview: KDE Frameworks
-<johu> New kde-frameworks eclass needs internal review/feedback. It's not yet ready for -dev ml due to potential major changes for workspaces and applications.
-<johu> It appears (final strategy not confirmed yet) that rather than one SC as seen in KDE 4 there will be 3 groups released separately: frameworks, workspaces, and applications. We should consider how this should be categorised. kde-frameworks is currently approximately 60 packages, with the potential for future 30+ additional packages. Potential scheme which is consistent with existing categories (see gnustep for -libs precedent):
-<johu> frameworks -> kde-frameworks/kde-libs
-<johu> workspaces -> kde-base
-<johu> applications -> kde-apps
-<johu> See Naming scheme, Dicuss and vote
-<creffett|irssi> wheeeee
-<mrueg> what about kde-misc?
-<creffett|irssi> people are going to complain about us having three categories.
-<kensington> there's precedent, see gnustep
-<creffett|irssi> didn't say no precedent, said there will be complaining ;)
-<johu> i would follow naming scheme from upstream-> frameworks -> kde-frameworks
-<kensington> a lot of frameworks stuff is designed to be not so kde-specific, so I think they deserve their own category
-<creffett|irssi> that said, the suggested split sounds good to me
-<johu> -workspaces -> kde-workspaces
-<johu> -applications -> kde-apps
-<creffett|irssi> we also may want to consider doing something with kde-misc, but that's a different question for a different day
-<kensington> kde-misc stuff doesn't fit into any of those other categories
-<johu> kensington++
-<creffett|irssi> I mean more like there's a lot of cruft in there
-<creffett|irssi> that I doubt anyone uses
-<creffett|irssi> like I said, different question for a different day
-<kensington> yeah, it could use some testing, I last-rited a youtube package in there that is probably broken for years
-<mrueg> johu: that means for the mean time 5 categories, right?
-<mrueg> kde-apps, kde-base, kde-frameworks, kde-misc, kde-workspaces
-<kensington> I agree with johu, but I think we will get a lot of pushback on -dev
-<creffett|irssi> yup.
-<mrueg> i think it is a good idea to seperate the release groups 
-<johu> just move the two proposals to -dev
-<johu> and see how it turns outr
-<creffett|irssi> question: when is kde 4 set to stop getting releases
-<johu> creffett|irssi: when there is a stable kf5 based release
-<johu> kde-{workspaces,apps}
-<mrueg> creffett|irssi: maybe there's also a trinitiy project for that
-<mrueg> do we want to support kde sc 4 and kf 5 installed in parallel?
-<kensington> frameworks is about to hit beta, and workspaces is about to hit alpha
-<johu> kf5 is almost co-installable with kdelibs
-<kensington> kde-runtime will be co-installable, kde-workspace will not
-<creffett|irssi> well, at least we have time before the tree move to get flamed
-<johu> who raises the cat discusion to -dev
-<johu> ?
-<mrueg> just think about a package depending on kwin for example
-<kensington> I would like to have some team agreement, because the runtime/workspaces split is about to happen and I want to package asap
-<creffett|irssi> +1 from me
-<kensington> mrueg: kwin will not be co-installable, but not much depends on it anyway
-<johu> i have no objections, please dont re-introduce a kde-prefix again
-<creffett|irssi> also, I volunteer kensington for emailing the ML :P
-<mrueg> kensington: just thinking if we want to deal with slots or categories 
-<creffett|irssi> ooh!
-<creffett|irssi> kde-prefix!
-<mrueg> so kde-base/kwin:4 or kde-base/kwin because kwin:5 will be in kde-frameworks or somewhere else.
-<kensington> all kde5 stuff is already in slot 5
-<kensington> vote on: kde-frameworks, kde-workspaces, kde-apps
-<mrueg> +1 
-<johu> +1
-<johu> if -dev is against it we should go with kde-apps, kde-libs, kde-base
-<mrueg> kde-base for kde4, kde-misc for everything else
-<mrueg> probably eclass can use the category to decide which release group the package is
-<mrueg> so we don't need anything like TIER=1 inside of the ebuild
-<kensington> mrueg: it's all in split repos
-<kensington> TIER=foo was only for frameworks stuff when it was still in kdelibs
-<johu> ack
-<mrueg> kensington: ah okay
-<mrueg> didn't know that :)
-<johu> anything left to discuss for now on kf5?
-<mrueg> yup
-<mrueg> lately there was a discussion to merge qt-overlay and kde-overlay?
-<kensington> if anyone has a free moment, check the eclass, there are a few design decisions that could use a review
-<johu> what about the ebuild naming scheme?
-<johu> mrueg: i dont see the purpose, the split was decided with the herd split and thats totally fine
-<mrueg> johu: i don't know, can't both sides profit from a shared repository?
-<kensington> there's not much crossover
-<creffett|irssi> the only commonality, really, is qt5
-<johu> mrueg: there was a time where no qt herd exists and the qt stuff was maintained by kde
-<creffett|irssi> I actually did not know that
-<johu> and then the split was decided because of the reason that there is no much crossover
-<creffett|irssi> though that explains the large number of qt people in our repo's access list :P
-<mrueg> but what would be the drawbacks of a joint repository?
-<johu> because kde is just one consumer
-<kensington> the effort to merge it and people migrating to it I guess
-<johu> we have high kde commit rate because of the monthly releases and someone who dont want to have extra kde stuff but newest qt stuff is pushed to get all those changes...
-<mrueg> johu: probably we can work on seperate branches and with a joint master branch
-<kensington> naming scheme is important if we end up using kde-base for kde5 stuff
--*- johu is against a re-joined qt-kde repo
-<creffett|irssi> mrueg: eww
-<kensington> and if not it would be nice to not have to manually pin ebuilds to a branch they don't match
-<mrueg> okay :)
-<mrueg> i see we better stay at status-quo :)
-<johu> kensington++
-<kensington> so, we can either just update the sets (eg. kde-live pulls in kcalc-9999 and kwin-4.12.49.9999) or make fake versions like 4.9999
-<johu> sets sounds more reasonable
-<kensington> ++
-<creffett|irssi> ++
-<johu> but this decision is a little bit influenced by the cat discusion on -dev
-<kensington> yeah
-<creffett|irssi> yup
-<kensington> also, I think kde-workspaces will end up to be not many packages
-<johu> maybe kde-base fits here okayish
-<kensington> it's being split into 12 repos, probably only that many packages
-<johu> kensington: i would suggest to write the -dev mail as soon as possible and then do the reasonable move!
-<kensington> johu: I will wait 1 or 2 days until the split is done, to get an accurate number of packages
-<kensington> if 12 repos = 12 packages, a new category for that will be definitely be rejected
-<johu> we could discuss this per mail if it is realy urgent and needs a fast decision
-<mrueg> johu++
-<kensington> I will mail a draft to the alias depending on what happens upstream
-<creffett|irssi> ++
-<johu> ++
-<johu> anything left on kf5?
-<kensington> otherwise I guess it will just be kde-frameworks/libs + kde-base
-<johu> btw kensington thank you for your great work
-<creffett|irssi> mhm
-<kensington> btw, mimetypes is fixed upstream in case you didn't see :-)
-<creffett|irssi> kensington++
-<johu> 5. Bugs (15 minutes)
-<johu> bug 445392
-<willikins> johu: https://bugs.gentoo.org/445392 "kde-base/konsole-4.9.3, x11-terms/xterm: backgroundcolor is not reset when scrolling"; Gentoo Linux, Applications; UNCO; toralf.foerster:kde
-<creffett|irssi> RESO NOTOURBUG
-<kensington> ++
-<johu> c7
-<johu> ++
-<mrueg> ++
-<ago> hello
-<johu> i dont want to do upstream work
-<kensington> hi ago 
-<mrueg> hey ago
-<ago> sorry for the delay, I had a prob.
-<creffett|irssi> good enough, will mark it 
-<johu> bug 456360
-<willikins> johu: https://bugs.gentoo.org/456360 "kde-base/print-manager looking for org.fedoraproject.Config.Printing"; Gentoo Linux, KDE; CONF; kirelagin:reavertm
-<toralf> erm : bug 445392 vanished away / was solved in the mean while (at least with 4.12.3+4.11.7)
-<willikins> https://bugs.gentoo.org/445392 "kde-base/konsole-4.9.3, x11-terms/xterm: backgroundcolor is not reset when scrolling"; Gentoo Linux, Applications; UNCO; toralf.foerster:kde
-<kensington> toralf: that's good news
-<mrueg> johu: that bug confuses me.
-<johu> printer stuff needs gnome bla to get full working, so there was a proposal to split stuff up
-<johu> but i got lost by all those user comments
-<kensington> is reavertm around lately?
-<creffett|irssi> haven't seen reavertm, no
-<johu> in the last years not realy
-<kensington> I guess the real solution is to improve the splitting, we can see how other downstreams do it
-<mrueg> add a minimal useflag to system-config-printer-gnome and activate that in kde profile by default?
-<mrueg> minimal useflag triggers the patch
-<johu> mrueg++
-<johu> it would be cleaner to do the split
-<johu> but this would be more effort
-<johu> mrueg: volunteer?
-<mrueg> johu: maybe upstream accepts the patch
-<mrueg> if eta is 1 month + x, i can take a look at it
-<mrueg> otherwise, i'm short on time
-<kensington> it's all one package upstream I think?
-<johu> i guess yes
-<johu> bug 482652
-<willikins> johu: https://bugs.gentoo.org/482652 "[kde overlay] dev-db/virtuoso-server-7.0.0 fails to integrate with akonadi/nepomuk"; Gentoo Linux, KDE; CONF; johannes.hirte:reavertm
-<johu> do we realy need virtuoso-7?
-<kensington> nope
-<kensington> nepomuk is going away
-<mrueg> \o/
-<creffett|irssi> BOOM
-<johu> lets keep the bug open and then last rite virtuoso when nepomuk is gone...
-<creffett|irssi> +1 as virtuoso comaintainer :P
-<mrueg> does it work on x86 anyway?
-<kensington> nope
-<creffett|irssi> nope!
-<creffett|irssi> virtuoso upstream stoped caring about...pretty much anything
-<creffett|irssi> so I'm fine with burninating
-<kensington> we can close that bug, there's no new development of nepomuk obviously
-<creffett|irssi> 14:22 < johu> mrueg: volunteer?
-<creffett|irssi> oops, sorry
-<creffett|irssi> stupid putty paste buffer
-<johu> kensington: yeah but you will always get version bump requests even when it makes no sense
-<kensington> lets move on then
-<johu> but i am fine with it to drop the stuff
-<kensington> there's still the other bug about it open
-<johu> bug 490600
-<willikins> johu: https://bugs.gentoo.org/490600 "kde 4.11.3 missing oxygen theme after update"; Gentoo Linux, KDE; CONF; nikhatzi:kde
-<johu> this is re-occuring with kstyles/qt updates
-<creffett|irssi> what is there that we can do?
-<johu> how about to just add a einfo/ewarn?
-<mrueg> johu++
-<kensington> yeah
-<johu> we would need a eclass/portage mechanism to get this proper fixed
-<kensington> I'm still not sure exactly which package is triggering the breakage though
-<johu> i guess qtgui
-<johu> bug 497314
-<willikins> johu: https://bugs.gentoo.org/497314 "No standard directories created after login to KDE"; Gentoo Linux, KDE; UNCO; oldium.pro:kde
-<johu> kensington: whats to discuss there?
-<kensington> what (if anything) to do
-<mrueg> do we want to add a useflag for that?
-<kensington> if we do /etc/skel we have to coordinate with other desktops
-<johu> kensington: please do
-<johu> its the proper way
-<kensington> or we can copy the env thing from hnome
-<johu> copy & paste is dirty
-<johu> please do the skel way
-<kensington> what package do we put it in?
-<johu> kde-env
-<johu> ?
-<mrueg> sgtm
-<creffett|irssi> sure
-<kensington> we might as well just copy the gnome env file then, it's less copy-and-paste then manually creating a bunch of directories
-<kensington> /usr/portage/gnome-base/gnome-session/files/10-user-dirs-update-gnome-r1
-<johu> ok if you say its easier faster and not that dirty, "Just do it"
-<creffett|irssi> make it so!
-<johu> 6. Elect new lead (10 minutes)
-<mrueg> i'll have to leave now
-<johu> !herd kde
-<willikins> (kde) ago, alexxy, creffett, dastergon, dilfridge, jcallen, jmbsvicetto, jmorgan, johu, kensington, mrueg, mschiff, patrick, reavertm, scarabeus, thev00d00
-<johu> nominees
-<creffett|irssi> I will go again if nobody desperately wants the role
-<mrueg> creffett|irssi++
-<kensington> i nominate johu  too
-<johu> thanks accepted
-<ssuominen> Xfce has the same code as /usr/portage/gnome-base/gnome-session/files/10-user-dirs-update-gnome-r1 in startxfce4
-<ssuominen> at upstream level (where it really belongs)
-<dol-sen> creffett|irssi, but, but, I was hoping you'd be portage lead...;)
-<creffett|irssi> dol-sen: NOPE.
-<kensington> ssuominen: what is your opinion on what we should do, as the resident freedesktop expert :D
--*- dol-sen goes back into hiding in the corner
-<creffett|irssi> do we have any more nominees?
-<johu> i would nomintate dilfridge but i guess he has enough work with council
-<johu> and he is not here to dis-/agree
-<kensington> yeah
-<creffett|irssi> all right
-<johu> ok do we want to do this via mail?
-<creffett|irssi> then let's vote
-<creffett|irssi> I have no preference
-<johu> i have the feeling that to less people are here...
-<johu> mrueg just left the building
-<creffett|irssi> okay, then I'm good with email voting
-<kensington> ++, I have to go too
-<ssuominen> kensington: got nothing unexpected to say :)  I'd add the file like gnome has, but at the same time, also write a patch that does the same and file upstream ticket
-<johu> creffett|irssi: check please the kde mail alias with herd members...there are some not following the mails
-<creffett|irssi> johu: uh, I can't right now, but off the top of my head reavertm isn't on the list
-<creffett|irssi> and possibly dastergon?
-<johu> creffett|irssi: scarabeus too i guess
-<kensington> scarabeus isn't I think
-<johu> and mschiff maybe too
-<creffett|irssi> yeah
-<johu> so better check
-<kensington> ssuominen: ok, I'll go ahead with that, thanks
--*- creffett|irssi can't do that until tomorrow night
-<johu> creffett|irssi: yeah lets say let us do the vote within 10 days
-<creffett|irssi> kk
-<johu> 7. Open floor
-<creffett|irssi> nothing here
-<johu> kde 4.12.x target
-<ssuominen> kensington: the problem is that desktops have started relying upon these directories in very early start, so xdg-user-dirs upstream refused the xdg .desktop autostart file for it, with notes that it would then execute too late in the process
-<ssuominen> kensington: so thats why we are stuck at calling the executable like this... otherwise i would have added the .desktop file long time ago
-<kensington> johu: .3 then .5 later?
-<creffett|irssi> good enough for me
-<johu> just 5? :D
-<kensington> + whatever kde-workspaces it is
-<kensington> well, probably arch teams will struggle to do .4 as well
-<johu> do we have any serious blocker left for .3?
-<kensington> not afaik
-<kensington> keywording for minor archs :p
-<johu> as maintainer we can always decide to drop stable keywords
-<johu> the problem is we have no stastics who realy uses kde on ppc,ppc64
-<creffett|irssi> every time we try to drop we get a couple people complaining
-<johu> i dont think it is useless to have them stable, as the kde-stable team has no test plan just a OK and ago only makes build tests on it
-<kensington> I suggest we go ahead with kde-stable asap then CC archs in a week or so
-<johu> kensington: but the good question is which arches? :)
-<kensington> the current ones, we can discuss dropping them if they are still lagging when we want to remove 4.11
-<johu> i dont want to add kde-stable anymore
-<johu> there is no real benefit from the sub-project
-<kensington> I saw some conflict no previous stable bugs
-<kensington> in either case I think we should be good to CC archs ones the 30 days is up
-<kensington> it is working well here, and there have been no bug reprots
-<johu> will create a list
--*- johu when nobody cries at home
-<creffett|irssi> heh.
-<johu> anything left for open floor?
--*- creffett|irssi needs to get going, later folks
-<johu> thanks all
-<creffett|irssi> johu: thank you for running the meeting :)
-<kensington> don't forget to review kde-frameworks.eclass, or otherwise be stuck with my awful design until kde 6 :-)
-<johu> kensington: i always review commits
-<johu> kensington: kde-misc/akonadi-git-resource for kde overlay
-<kensington> johu: where does it display it?
-<johu> kensington: extra folder in the left tree view
-<kensington> interesting, I will check it out
-<kensington> oh, kmail...
-<johu> kensington: http://ctrlv.in/311477
-<kensington> I will try kmail again with baloo some time
-<johu> 9999 :)
-<johu> in my opinion we should rename 9999 to 666 :)
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20140810.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20140810.txt
deleted file mode 100644
index fde8e8a594..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20140810.txt
+++ /dev/null
@@ -1,389 +0,0 @@
-<johu> 1. Roll call
-<johu> !herd kde
-<willikins> (kde) alexxy, creffett, dastergon, dilfridge, jcallen, jmbsvicetto, jmorgan, johu, kensington, mrueg, mschiff, patrick, reavertm, scarabeus, thev00d00
--*- alexxy here 
--*- kensington here
--*- johu here too
-<mrueg> pong
-<scarabeus> me too
-<johu> good 5 is enough to start
-<johu> 2. kde4-*eclass GCC minimum version (10 minutes)
-<johu> Please discuss and vote on raising gcc minimum version to 4.7
-<johu> Open Bugs:
-<johu> bug #462550 - [4.6/ICE] sys-devel/gcc-4.6.3 Segmentation fault (program cc1plus) compiling kde-base/rocs-4.10.1 on ppc64
-<johu> bug #471770 - =kde-misc/homerun-1.0.0 - fails to build with <gcc-4.7
-<johu> bug #508324 - kde-base/kig-4.13.0 fails to build with <sys-devel/gcc-4.7
-<willikins> johu: https://bugs.gentoo.org/462550 "[4.6/ICE] sys-devel/gcc-4.6.3 Segmentation fault (program cc1plus) compiling kde-base/rocs-4.10.1 on ppc64"; Gentoo Linux, KDE; CONF; jmorgan:toolchain
-<willikins> johu: https://bugs.gentoo.org/471770 "=kde-misc/homerun-1.0.0 - fails to build with <gcc-4.7 (components/image.h:46:90: error: expected ‘;’ at end of member declaration)"; Gentoo Linux, KDE; UNCO; amak79:kde
-<willikins> johu: https://bugs.gentoo.org/508324 "kde-base/kig-4.13.0 fails to build with <sys-devel/gcc-4.7"; Gentoo Linux, KDE; UNCO; gentoo:kde
-<johu> 3rd bug is one of the stable blockers
--*- dilfridge|mobile here
-<kensington> we did it in kde5.eclass and already there was a complaint
-<mrueg> kensington: why do people complain?
-<johu> only one...
-<scarabeus> nah we do these rises quite periodically
-<kensington> mrueg: because it unconditionally required it for every package
-<scarabeus> and people complain
-<scarabeus> but still they should use latest-stable anyway
-<mrueg> kensington: okay, i don't consider that relevant.
-<dilfridge|mobile> do it
-<scarabeus> and gcc 4.7 is stable for >few months
-<mrueg> raise it
-<alexxy> its bare minimum
-<alexxy> so its good to raise it to 4.7
-<johu> ok official vote:
-<alexxy> or there are some arch that dont support it?
--*- alexxy vote for gcc 4.7 in deps
-<mrueg> +1
-<johu> +1
-<dilfridge|mobile> +1
-<johu> ok fine
-<johu> 2. KDE SC 4.13.3 stabilization (15 minutes)
-<johu> bug #517344 - KDE SC 4.13.3 + KDE Workspace 4.11.11 stabilization
-<johu> semantic-desktop refactoring (old semantic stack -> nepomuk use flag, new semantic stack -> semantic-desktop use flag): Are we happy with it? Do we need an news item?
-<johu> Baloo alternate KCM: Now that upstream provides an option to disable indexing in their KCM, do we still want to hack the alternate KCM into the baloo ebuild?
-<johu> Please discuss and vote to stabilize KDE SC 4.13.3
-<willikins> https://bugs.gentoo.org/517344 "KDE SC 4.13.3 + KDE Workspace 4.11.11 stabilization"; Gentoo Linux, Keywording and Stabilization; CONF; johu:kde
-<scarabeus> i would disable the hack otherwise +1
-<mrueg> ack with scarabeus
-<mrueg> not sure about news item
-<dilfridge|mobile> Same here
-<alexxy> if there is possibility to disable indexing using upstream kcm then there no need to hack alternative one
-<mrueg> can we do a news item conditional on installed with -semantic-desktop ? 
-<johu> i dont care about the alternate kcm
-<kensington> i want to punt alternate kcm hack from ebuild, it's still around if someone wants to install it himself
-<johu> fine by me^
-<alexxy> fine^^
-<johu> are we happy about baloo performance?
-<johu> only have ssd to test on laptop
-<kensington> it's improved over nepomuk
-<dilfridge|mobile> EDONTCARE
-<johu> any objections to 4.13.3?
-<kensington> no, it's a good target
-<dilfridge|mobile> No
-<johu> use flag refactoring was OK?
-<mrueg> sgtm
-<johu> ok first vote on the topic: 4.13.3 is our next stable candidate
-<kensington> refactor worked out well, i think everything was converted
-<kensington> ++
-<johu> +1
-<dilfridge|mobile> +
-<scarabeus> +
-<johu> ok now about the procedure
-<johu> kde-stable looks dead to me
-<johu> no mail after ago's reitrement
-<johu> so i will add arches directly
-<mrueg> so should we dissolve the project?
-<kensington> fine, it's been very quite release in ~arch anyway
-<johu> which leads to the question which arches @-dev mail about ppc/ppc64
-<mrueg> or can we reactivate them for kde5 somehow?
-<dilfridge|mobile> Talk to pl
-<dilfridge|mobile> ppc
-<dilfridge|mobile> Ask them
-<johu> who was elected to be lead of the 2 herds?
-<dilfridge|mobile> Imho we don't need ppc stable
-<dilfridge|mobile> But if they want...
-<mrueg> johu: jmorgan iirc
-<dilfridge|mobile> Gotta go, have fun...
-<johu> ok i will contact him when we have the stable list in place
-<johu> which will require some work to catch up all pkgs about the use flag refactoring
-<alexxy> ppc 32 bit is a dead arch
-<alexxy> its only exist in routers
-<kensington> don't they need to go stable at the same time anyway?
-<johu> yes thats why they have to be IN the list
-<mrueg> alexxy: ack
-<alexxy> so it may be safe to drop them
-<johu> i will ask them if they want to keep stable keywords 
-<alexxy> if x86 32bit somehow alive since some still use it
-<alexxy> even if there no processors which run only 32bit mode for 10 years
-<johu> yeah some ppl install still 32 env on 64 systems...
-<alexxy> however x86 32bit can be considered dead in quite near future 
-<johu> ok last question in this topic if there is no objections on this. Do we need a news item?
-<alexxy> johu: they still wann be paladins and play necromants games 
-<alexxy> +1 for news item 
-<kensington> ++
-<johu> +
-<mrueg> +1
-<kensington> there was some confusion about 2 use flags when it hit ~arch
-<johu> ok volunteer?
-<alexxy> users should know or they will scream 
-<johu> kensington: native speaker, you wanna do this?
-<kensington> sure
-<johu> ok fine, so in some weeks we will have a new stable kde
-<johu> next topic
-<johu> 4. KDM (5 minutes)
-<johu> jmbsvicetto suggested to rethink kde-base/kdm as a dependency in kde-base/kdebase-meta:4, as kdm will not exist after KDE 4 and users might have already migrated to something else. Do we want to add IUSE="+display-manager" with RDEPEND="display-manager? ( || ( x11-misc/lightdm-kde x11-misc/sddm kde-base/kdm ))"? If so, which order?
-<johu> Please discuss and vote to make kdm optional (and if yes on the proposed solution/order)
-<alexxy> kill'em =D
-<mrueg> make it optional, add display-manager IUSE, order: not sure about it.
-<johu> sounds reasonable -> RDEPEND="display-manager? ( || ( x11-misc/lightdm-kde x11-misc/sddm kde-base/kdm ))
-<alexxy> kde upstream supposed to use sddm?
-<alexxy> right?
-<kensington> for kde5+
-<alexxy> may be it good to create virtual/display-manager
-<kensington> for kde4 let's keep the default the same
-<johu> yeah the order for kde4 should be untouched
-<johu> and for :5 i would vote for sddm
-<johu> as upstream is heavily contributing to sddm
-<kensington> we can worry about :5 later, we don't even have meta packages for it yet
-<johu> kensington: is on my long todo list
-<alexxy> kensington: i'll create them =D
-<alexxy> i'm run it @work
-<johu> anything to add before vote?
-<kensington> tbh dm shouldn't even be pulled in kde 5 meta pacakge; we don't pull in xorg-server
-<alexxy> also sddm should work for wayland
-<alexxy> that i wanna give a try 
-<alexxy> on laptop
-<johu> OK please vote on making dm optional and keep current order untouched for :4
-<mrueg> +1
-<johu> +1
-<alexxy> +1
-<kensington> there is no current order, it's just kdm
-<scarabeus> just put there or with kdm first
-<johu> "s/current order/kdm default"
-<kensington> makes more sense kdm use flag then
-<kensington> since kdebase-meta is just a list of kdebase packages
-<johu> display-manager sounds more generic
-<kensington> and sddm isn't even stable
-<johu> we just need one stable in the RDEPEND options ;)
-<johu> thats not the problem
-<johu> any other opinion about the use flag name?
-<johu> ok, silence
-<johu> So please vote on use flag name: a) display-manager b) kdm
--*- kensington doesn't care about flag name
-<kensington> so let's go with display-manager
-<johu> fine
-<mrueg> does it mean kde:4 display-manager? ( kdm ) or display-manager? ( || ( kdm lightdm sddm ) )
--*- kensington votes for the first one
-<mrueg> i'd be okay with both
--*- creffett|irssi here
-<mrueg> and i think jmbsvicetto, too. 
-<creffett|irssi> display-manager
-<johu> i would say give freedom to the ppl: display-manager? ( || ( kdm lightdm sddm ) )
-<mrueg> iirc he just wanted an option to disable kdm there
-<johu> Gentoo is all about choices
-<kensington> don't use a meta package for pulling in kdebase packages then
-<johu> its outlined in our official guide
--*- creffett|irssi passes johu a drink
-<kensington> you can still choose what you want, but the kdebase-meta pulls in all kdebase-packages
-<kensington> wallpapers use flags pulls in kde-wallpapers, not || ( kde-wallpapers gnome-wallpapers )
-<johu> ok all arguements on the table?
-<johu> vote on a) only kdm controlled by the use flag b) even more options, like lightdm sddm gdm?
-<kensington> a
-<johu> b
-<mrueg> a
-<johu> all those sleeping birds
-<mrueg> creffett|irssi, alexxy, scarabeus?
-<creffett|irssi> b
-<alexxy> b
-<mrueg> lightdm[kde] or just lightdm? ;)
-<johu> come on scarabeus say a then we have a draw
-<kensington> suggest we do || ( kdm virtual/display-manager) then
-<johu> ++
-<creffett|irssi> +=
-<johu> last chance to object^
-<mrueg> there's no virtual/display-manager ?
-<johu> 5. Phonon backend (5 minutes)
-<johu> mrueg: thats an good argument
-<johu> kensington: where do you find it?
-<kensington> it doesn't exist yet, alexxy suggested to create it
-<johu> fine by me, but please do it fast as it needs to be stabilized too
-<johu> otherwise i would vote for kdm only
-<johu> and do the long track for 4.14
-<mrueg> sgtm
-<johu> ok next topic,
-<johu> 5. Phonon backend (5 minutes)
-<johu> The current default backend is gstreamer, the same as in Kubuntu, and has the greatest number of features. However, upstream now chooses VLC as the default. Should we switch or remain the same?
-<johu> Please discuss and vote on switching to vlc as default backend
-<mrueg> switch to vlc
-<kensington> vlc
-<johu> vlc
-<creffett|irssi> no opinion
-<johu> p-gstreamer has such a low commit rate
-<kensington> also 1 vlc is nicer than 100 gstreamer-badugly-foo
-<mrueg> btw. what about phonon-qt7?
-<mrueg> homepage is dead, last snapshot in tree is from 2011
-<alexxy> +vlc
-<johu> mrueg: if you want last rite it and see what happens
-<kensington> mrueg: i look forward to punting it along with all other unmaintained prefix kde stuff
-<mrueg> http://quickgit.kde.org/?p=phonon-quicktime.git looks deadish
-<mrueg> kensington: please do so :)
-<kensington> there was complaints last time i tried...but still nobody would even test it
-<kensington> so probably it will disappear when kde4 is gone
-<johu> kensington: try it again
-<johu> 6. KDE 5
-<johu> a) Categories (10 minutes)[edit]
-<johu> kde-frameworks has already been approved on gentoo-dev. Plasma 5 is currently 23 packages, should it go in its own category (kde-workspaces?)? If so, we would likely need a new category for applications (kde-apps?) and eventually remove kde-base (and kde-misc?).
--*- kensington doesn't know
-<mrueg> why not use kde-misc instead of kde-apps?
-<mrueg> kde-frameworks, kde-workspaces, kde-misc 
-<kensington> it will have official kde and third party applications in the same category then
-<johu> kde-plasma?
-<johu> its the official wording for the DE so why not following it for the category
-<johu> and then would make kde-apps sense to me
-<johu> otherwise i would stick to kde-base
-<johu> kensington: post pone this topic?
-<kensington> i guess
-<johu> b) Moving to tree (10 minutes)
-<johu> Qt 5 will be in the tree soon (masked). Are we happy to move KF5 / Plasma 5 after that's done?
-<alexxy> kde-workspaces looks better 
-<alexxy> its good to move
--*- johu is for KF5 tree, plasma 5 overlay when qt5 hits the tree
-<alexxy> at least releases 
-<alexxy> kf5 are nonsence without apps and plasma
-<alexxy> so its like all or nothing 
-<johu> its not the best user experience when almost all kde apps are not ported
-<alexxy> yeah
-<alexxy> but we can keep it masked
-<kensington> that's a feature, not a bug
-<johu> alexxy: wrong tomahawk already uses a kf 
-<alexxy> so if someone wanna use it they will
-<kensington> it's expected behaviour to use kde4 apps and porting will be slow
-<johu> i guess at christmas time big porting will happen
-<johu> arroundish
-<mrueg> will plasma-active get into the tree somewhere in the near future?
-<mrueg> oh sorry.
-<mrueg> nvm
-<johu> OK vote 1) When Qt5 hits the the KF5 will be added too
-<johu> tree
-<kensington> ++
-<johu> ++
-<alexxy> johu: kf5 + plasma 
-<alexxy> otherwise ++ 
-<mrueg> ++
-<mrueg> (without plasma)
-<johu> 2) When Qt5 hits the tree Plasma 5 will be added too
-<mrueg> -1
-<johu> -- 
-<kensington> ++
-<alexxy> ++ for plasma-5.1
-<johu> 4.0 was the same story
-<kensington> plasma is pretty stable though
-<johu> but the kde4 apps looking ugly
-<mrueg> kensington: is the package splitting done?
-<alexxy> kensington: +1 i use it as default DE @work
-<kensington> i didn't notice, maybe we have different themes
-<alexxy> only porblem is that it doenst work with 2 monitors
-<kensington> mrueg: which splitting?
-<johu> and there are a lot of usability issues unresolved
-<mrueg> kensington: dolphin:5 etc.?
-<johu> 2:2
-<kensington> mrueg: we didn't work on it yet, hoping upstream will split repos
-<kensington> there's not even release schedule yet so we've got some time
-<johu> i take my lead head on and say lets revisit the topic with 5.1 release
-<mrueg> kensington: i'd say get it into the tree, when this is done
-<johu> we have no hurry to rush at the moment
-<kensington> mrueg: applications are on a different release cycle to plasma
-<kensington> kcalc may well be released at a different time to dolphin eg.
-<johu> kensington / alexxy are you fine with postpone the plasma decision?
-<alexxy> yep
-<kensington> fine, probably 5.1 will be released before qt5 in tree anyway
-<alexxy> he he =D
-<kensington> or 6.1....
-<johu> 7. Bugs (15 minutes)
-<johu> first one: 456360
-<johu> bug 456360
-<willikins> johu: https://bugs.gentoo.org/456360 "kde-base/print-manager looking for org.fedoraproject.Config.Printing"; Gentoo Linux, KDE; CONF; kirelagin:reavertm
-<johu> was this discussed last meeting?
-<kensington> i think so, don't remember the outcome
-<johu> ok then we need to grep the last log and see what we are going to do
-<johu> bug 492434
-<willikins> johu: https://bugs.gentoo.org/492434 "lib-net/libnm-qt should depend on systemd or consolekit (was: kde-misc/plasma-nm should depend on kdm[consolekit])"; Gentoo Linux, KDE; UNCO; cruzki123:kde
-<kensington> not much we can do unless someone volunteers to do the package split
-<mrueg> i think it was me to check whats going on, but haven't found time for that
-<johu>  RESOLVED WONTFIX imho as networkmanager already provides those flags
-<kensington> which one actually requires it? libnm-qt or networkmanager
-<johu> plasma-nm is not useable without consolekit/systemd
-<johu> but it depends on libnm-qt which depends on networkmanager
-<johu> and networkmanager already provides the requested use flags...
--*- kensington no opinion
-<alexxy> its dependency chain
-<mrueg> as plasma-nm is the only consumer of libnm-qt 
-<alexxy> so libnm-qt should depend on nm with any of this use flags
-<mrueg> can't libnm-qt depend on || ( networkmanager[consolekit] networkmanager[systemd] )?
-<johu> yeah we can add that^
-<johu> fine RESOLVED FIXED soon (tm)
-<johu> bug 497314
-<willikins> johu: https://bugs.gentoo.org/497314 "No standard directories created after login to KDE"; Gentoo Linux, KDE; UNCO; oldium.pro:kde
-<johu> kensington: last comment from you
-<kensington> meh
-<kensington> do we even want to do something downstream?
-<johu> if its a hack no
-<johu> if its doable without hack fine by me
-<mrueg> kensington: what about comment 4?
-<johu> but at least some progress on this would increase user experienc
-<mrueg> sounds good.
-<kensington> mrueg: we can do it, it's kind of hacky but it works
-<johu> kensington: is this for plasma5 needed too? if yes i would vote for an upstream action!
-<johu> as we want to get rid of such things
-<kensington> yeah
-<kensington> samuli mentioned /etc/skel solution, i'll ask him about that too
-<johu> ok lets see if the bug is unresolved next meeting ;)
-<alexxy> I dont care about dirs acutaly 
-<johu> bug 497734
-<willikins> johu: https://bugs.gentoo.org/497734 "www-client/rekonq-2.4.0 should RDEPEND on kde-base/kdebase-kioslaves"; Gentoo Linux, KDE; CONF; rossi.f:kde
-<johu> kensington: last comment from user responded to your question, so whats left here to get a RESOLVED?
-<kensington> i could reproduce with my config, but not his
-<kensington> so we can 1) add the dep 2) too bad use runtime-meta 3) tell upstream not to use ioslaves to display a blank page
-<johu> 2)
-<johu> +3)
-<johu> or 1) 
-<johu> ok seems i have no opinion on that
-<mrueg> does kdebase-kioslaves add many dependencies?
-<mrueg> (if you're using gnome and want rekonq as a browser)
-<kensington> not much beyond kdelibs
-<mrueg> okay, then 1) + 3) 
-<johu> ^
-<johu> ++
-<johu> bug 511570
-<willikins> johu: https://bugs.gentoo.org/511570 "[kde overlay] KDE Frameworks requires gcc 4.5, not 4.8"; Gentoo Linux, KDE; UNCO; matthew:kde
-<johu> topic 2) revisited for KF5
-<mrueg> well we did raise it to gcc-4.7?
-<mrueg> (for kde-4)
-<kensington> 1. too bad 2. conditional on package type
-<kensington> yeah we did
-<johu> if we raise for kde4 to gcc47 its fine to have gcc48 for kf5
-<mrueg> Is there a need for 4.8?
-<johu> i guess we would get  a lot of bugs if we lower it to gcc45
-<mrueg> why not use 4.7 for both (if it works)
-<kensington> plasma 5 requires 4.8
-<mrueg> ah okay
-<mrueg> the 4.8 is fine
-<johu> thats the reason^
-<mrueg> (just asked because 4.7 is stable, 4.8 is testing)
-<johu> WONTFIX imho
-<alexxy> +1
-<alexxy> 4ю8 шы ашту
-<alexxy> sorry
-<alexxy> 4.8 is fine
--*- alexxy on 4.9 already
--*- johu too
-<johu> kensington: did you test kf with 4.5? :)
-<kensington> no, it's just the upstream claim
-<kensington> i don't even have 4.5 installed
-<alexxy> 4.5 is too old
-<johu> i guess nobody will test it from herd as we already on newer 
-<alexxy> newer version more interesting
-<johu> kensington: so thats a closing reason for it, we dont have the manpower to support such old setup 
-<johu> bug 514384
-<willikins> johu: https://bugs.gentoo.org/514384 "cmake-utils.eclass: please deprecate all those fancy cmake-utils_use_*"; Gentoo Linux, Eclasses and Profiles; CONF; mgorny:kde
-<kensington> yeah, it's less relevant anyway since we move to 4.7
-<kensington> --
-<kensington> no problem to add the function he wants, but a lot of the existing functions are useful
-<johu> kensington:++
-<johu> same opinion
-<kensington> maybe we can grep to see if there's some old unused function to remove
-<johu> and dilfridge already expressed his opinion in the bug
-<johu> yeah do it so
-<johu> 8 Open floor (15 minutes)
-<johu> kde member of the month: kensington for his great effort on KF5/Plasma5 and upstreaming
-<johu> cheers
-<johu> and next month it may be pesa to get Qt5 into the tree
-<kensington> i did a big reshuffle of cmake-utils in overlay, it tests ok locally for ages so i'd like to move that
-<kensington> it's mostly cosmetic
-<johu> we are almost done with EAPI4, do we need to announce it on -dev?
-<johu> <10 pkgs
-<kensington> don't think it's required, maybe some overlay users care
-<johu> ok i need to leave, my food is ready
-<johu> Thank you all
-<mrueg> johu++
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090212.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090212.txt
deleted file mode 100644
index 288437ca18..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090212.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-KDE PPLE AROUND:
-alexxy, tampakrap, wired, hwoarang, scarabeus, yngwin, Sput, jmbsvicetto, reavertm, krytzz,
-EXCUSED:
-cryos, deathwing00, tgurr
-NOT EXCUSED:
-the rest :P
-
-Review of previous:
-update for 4.2 went ok. Some minor issues :]
-there is missing review for pyqt/pykde and printing stuff, that will be deffered until somebody step up for the fixing/testing.
-
-This one:
-droping of 4.1. - tampakrap
-
-voting for leader -> jmbsvicetto, he get 7 voltes from devs (alexxy, tampakrap, hwoarang, scarabeus, yngwin, deathwing00) rest is not around so deal with it :]
-all hail to the new leader jmbsvicetto :P
-
-prefixing and using multiple versions of the kde in one prefix -> cooperation with upstream
-installing libs and things versioned and use eselect to pick the one we want...
-read the log around 21:30 and keep going for this one
-jmbsvicetto, reavertm, maybe somebody more
-
-3.5 - dropping the old .7 and .8
-poke archies about stabling and checking keywords on .9
-alexxy is going to do this one
-
-patches sharing with other distros
-new patching glep, help wanted and i welcome any critic on current state (on mail until i anounce on -dev).
-http://dev.gentoo.org/~scarabeus/patches-glep.html
-scarabeus
-
-pykde - needs love, unprefixing probably, who will do it?
-
-and more and more...
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090401.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090401.txt
deleted file mode 100644
index 168f528628..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090401.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Roll call:
-KDE devs: alexxy, bonsaikitten, cryos, hwoarang, jmbsvicetto, scarabeus, tampakrap, yngwin
-KDE ATs: krytzz, reavertm, wired
-
-Agenda for the meeting:
-- unprefixing misc stuff
-- moving plasmoids to the tree
-- kde3 state
-- moving printing to the tree
-- upstream responses on packaging snapshots
-- removing dead members
-- pykde fixing
-- handling kdeprefix for base... eselect?
-- koffice status / what is needed
-- moving meeting to another date (about 2 weeks before release of upstream so 
-we can talk about what is needed to be done for current release)
-- stable live status (if the guys working on it shows up ;])
-
- - Removing kdeprefix for apps not in kde-base
-   reavertm explained that the goal was to drop the kdeprefix use flag for all apps
-   outside of kde-base and that he already started the work for it (including a rewrite
-   of the eclasses) in the dropped-kdeprefix-on-non-kde-base branch in the kde-testing
-   overlay. This means deprecating NEED_KDE in favor of KDE_REQUIRED and KDE_MINIMAL, so
-   that packages are built not against the newest available KDE (when there's more than
-   1 version) but instead to the oldest - respecting KDE_MINIMAL.
-   There was a long discussion about kdeprefix, its purpose, benefits and alternatives.
-   The final consensus was to follow reavertm's solution.
-
- - KDE3 state
-   tampakrap explained the eclasses are ready to move all packages under /usr/kde/3.5.
-   He's still testing ebuilds and could use the help of 2 people to test kde-misc apps.
-   wired and jmbsvicetto offered to help. tampakrap will prepare a list of packages and
-   we're going to search for people through the page and a mail to the dev ml.
-   To start the work on getting KDE4 marked stable, we agreed to get this work done by
-   the end of the month - we'll be masking 3.5.9 monos as soon as we get 3.5.10 marked
-   stable.
-
- - Moving Plasmoids to the tree
-   Plasmoids were moved to kde-misc category and will be added when they're tested
-   with +kdeprefix
-
- - Adding printing packages to the tree.
-   We've decided to hold this until KDE-4.3.
-
- - Upstream response to the packaging snapshots mail
-   No reply again. As we're being ignored, we've decied to repackage the snapshots.
-
- - Removing dead members
-   jmbsvicetto will go over the retirement bugs and will send emails to the members
-   that are MIA. He will get the team membership cleaned before next meeting.
-
- - pykde fixing
-   There are some problems with having more than one pykde version with +kdeprefix
-   as it installs files outside the prefix. The solution might be to "unprefix" it
-   or to have a new package just with the python files. In any case, patrick was
-   "nominated" to work on this.
-
- - handling kdeprefix for base ... eselect
-   After some discussion we agreed eselect was not the solution
-
- - koffice status / what is needed
-   scarabeus informed the team that koffice-2.0 is going to be released at the end
-   of the month and asked what we should do about it. scarabeus suggested to have
-   the stable release hardmasked in the tree. We agreed to try to get one of the
-   rcs in the tree before that to allow users to test it.
-
- - moving meeting to another date
-   We decided to have KDE meetings at the 3rd Thursday of the month.
-
- - stable live status
-   We didn't discuss this topic.
-
-As a final note, jmbsvicetto reminded people that we still have a *few* open bugs
-and that we should all try to help get that number down.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090521.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090521.txt
deleted file mode 100644
index 8b52f4f5d4..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090521.txt
+++ /dev/null
@@ -1,182 +0,0 @@
-21.5.2009 - KDE Meeting
-Roll-call: wired, alexxy, scarabeus, dagger, hwoarang, tampakrap, bonsaikitten, krytzz, yngwin, civil, papillon81, reavertm, lxnay, cryos, jmbsvicetto
-
-Cryos legitimely excused from not attending much, new baby on the route. Grats to him! :]
-
-Doc handling
-- doc == aplication handbook or handbook, to be decided...
-- enable +doc/handbook by default for kde-base
-- aplication api documentation - scarabeus write mail asking for some global useflag for it on -dev
-- rename doc useflag to handbook with 4.3 again :D
-- make it more handleable by eclass rather than in the ebuilds
-- lxnay volunteer to do the packages update in overlay
-- so priority coruse is:
-  - mail to dev asking how to do it
-  - wait a bit and if nothing constructive comes up do the rename for 4.3
-
-kde3
-- kill arts, all misc apps needs it removed and be stabled before 3.5.10 stabling
-- stable 3.5.10, all kde related misc apps needs to be revbumped/verbumped and stabled before it
-- tampakrap starts handling 3.5.10 stabilisation - stable bug asap 15.6. deadline
-- writing doc about kde3/4 mixing - tampakrap
-
-kdeprefix
-- long discussion about support of kde4 +kdeprefix install in kde3 and gnome, will chat with reaver about it on aproperiate bug
-- add ewarn for user when installing with +kdeprefix so we assure he knows what he is messing with. (controled same like live warning)
-
-kde 4.3
-- libknotification already handled, pdepend for kdelibs.
-- policykit looks ok
-- so no much work for 4.3 itself
-
-kde/kde3 useflag
-we voted about it, result:
-kde - latest supported kde 4, 5, whatever
-kde3 - for now kde 3 series, when kde5 is out there will be kde4 useflag and so on,...
-as long as new version is expected to be highly experimental we will have kdeX where X is the version number. When proper support in portage arrives it mutate into kde and older kde mutate to kdeY where Y is X-1
-
-phonon
-- ship snapshot into the tree with kde 4.3
-- separating xine part to be able use qt-phonon instead of normal phonon with kde - probably reaver
-
-CODE:
-improve it, and add requirements we find out that are needed
-since next meeting the code will be considered final, and not folowing it will be punished
-
-relwithdebuginfo:
-deffered after some work on it, not worth efforts
-
-GUIDE:
-tampakrap promised to write the guide for kde3/4 mix that will cover also kde4 installing
-
-kdebindings:
-scarabeus + reaver: invent some logic there; delegate work to other HTs
-
-sabayon:
-discuss the topic more with joost_op at some other more convinient time
-so far done ->
-bugs from ppl with @sabayonlinux.org will be handled legitimely as our bugs
-and we will reflect them as HTs for kde team so we dont have recheck reported things (aka we trust sabayon devs :})
-
-------------------------------------------------
-Qt topics
-------------------------------------------------
-
-Rollcall Qt herd
-----------------
-
-- hwoarang, tampakrap, yngwin present
-- carlo absent
-- recruits wired, Pesa and spatz present
-
-
-Meeting length
---------------
-
-The KDE Project meeting was going on for too long, all agreed. It was suggested
-that it would be good to have more frequent and shorter meetings. Also, Qt
-topics could be discussed early in the meeting. Details will be discussed at
-another time.
-
-
-Phonon issues
--------------
-
-KDE herd has asked us to introduce a kde useflag for ebuilds depending on::
-	|| ( x11-libs/qt-phonon media-sound/phonon )
-so that media-sound/phonon can be preferred for KDE users, as a workaround for
-current portage shortcomings. yngwin will work out a proposal for affected Qt
-ebuilds.
-
-Also, the suggestion was offered to split the backends from phonon into
-separate packages (gstreamer from qt-phonon, and xine from kde's phonon), so we
-could have one phonon core package (most likely x11-libs/qt-phonon). It was
-decided that this is worth looking into.
-
-
-Recruits
---------
-
-As to the status of recruits for the Qt team: 
-
-- wired is done with the quizzes, so he only needs grilling by a recruiter and
-  can be expected to become a full dev within the next few weeks
-- Pesa has been very active already in contributing
-- spatz just joined us as newest recruit
-- sping is busy with GSoC and will continue recruitment process after that, he
-  is especially interested in Qt3/KDE3 maintenance
-
-
-Qt status in tree
------------------
-
-- bug 266201: 4.5.1 is going stable, but arches are taking their time (only
-  alpha and ppc so far)
-- bug 270475: bug in the eclass about the platform switch, which affects
-  chroots and some arches like ppc, a solution is being worked on in the 
-  overlay
-- bug 235685: webkit sigbus on sparc, we will try to get upstream to fix it, in
-  the meantime we can use a patch on sparc only (and maybe on other arches like
-  alpha)
-- bug 270769: ppc rendering fix will be fast-tracked for stabilization
-- bug 209626: make qt eclasses ready for eclass-manpages, hwoarang offered to
-  take care of this
-- bug 224951: qt4-qtruby has been hardmasked for a while, so we should fix or
-  remove the package; decided we'll work on it to see if it's fixable,
-  otherwise ask ruby herd to agree with removal; yngwin will commit his
-  intermediate work to overlay
-- bug 236341: Pesa and hwoarang will work on removing automagic deps from PyQt4
-- bug 43827: qvfb and related embedded ebuilds could be proxy-maintained, we
-  will approach users that might be interested
-
-
-Overlay
--------
-
-As mentioned during the discussion of the KDE overlay's CODE document, we
-should start using similar commit policies, especially starting the commit
-message with $PN.
-
-Both 4.5.9999 and 4.9999 versions of Qt ebuilds in overlay are actively
-maintained and used, so status is OK.
-
-A lot of packages are being moved from overlay to the official tree, so work
-there is progressing well. Pesa will work with ali_bush to get the latest
-version of qtjambi into the tree.
-
-
-Eclasses
---------
-
-There has been discussion on -dev ML about blocking mixed Qt versions. Paludis
-doesn't handle the blocks and dependencies the same way portage does, but it 
-was concluded that the proposal currently in overlay, which works fine with
-portage, is the best solution so far, so we will go ahead and implement that in
-the official tree as well.
-
-It was also decided to remove the custom-cxxflags useflag and the default
-strip-flags from the qt4-build.eclass, as testing has shown that Qt is not as
-sensitive to optimized flags anymore. We will let this change coincide with
-committing the 4.5.2 (next release) ebuilds into the official tree.
-
-There has been a lot of development going on in the qt4-edge.eclass (the
-overlay version of qt4.eclass). We have implemented additional default phases
-for src_configure and src_install, the eqmake4 function has seen a lot of
-improvements, and there is experimental functionality for handling translation
-files.
-
-We decided to add that as a new eclass to the official tree, once the ongoing
-work on eqmake4 and translations crystalizes. We will then mark the old eclass
-as deprecated and open a tracker bug for migration of packages to the new
-eclass. There was some brainstorming about naming the new eclass, but
-bikeshedding is to be continued outside of the meeting.
-
-
-Elected Qt team lead
---------------------
-
-As we are now a fast growing team, yngwin felt the need to bring up the issue
-of elections for a Qt team lead, as he assumed the position when no one was
-looking after qt herd. The decision was this is not needed, as the team members
-are unanimously happy with the current situation of yngwin being the de facto
-leader.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090618.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090618.txt
deleted file mode 100644
index 1a7b140ac1..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090618.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-Rollcall:
-yngwin, scarabeus, tampakrap (delayed), hwoarang, spatz, Pessa, alexxy, reavertm, wired, patrick, jmbsvicetto (late)
-Carlo: slackermark
-
-Topics:
-
-Formulate some kind of official policy for qt3 apps and their future
-- Qt3 apps will follow the KDE3 example and will share one overlay for the stuff with it. Users will maintain it.
-- Addition to main tree of new Qt3 apps is *highly* discouraged.
-- Qt3 useflag is being marked as discouraged (removal from profiles and so on) since NOW :]
-- A draft with ideas for it will be sent to the -dev ml by yngwin
-
-Solving the python issues within KDE4 - currently with +kdeprefix KDE 4.2 and 4.3 can't live next to each other due to packages installed into site-packages for python.
-- the issues running new pykde with old pykde using apps must be tested (pykde from 4.3 and python apps from 4.2)
-- if above test prove not working, KDE misc apps will be forced to look into slotted dir in site-packages folder
-- will be done by reavertm and patrick
-- this issue is a stabilisation blocker
-
-Solving the final question about kdeprefix.
-- voting about kdeprefix mask in profiles (users can still unmask it, but kde is not as solid as with -kdeprefix)
-For this vote our HT reavertm was allowed to vote since he is one of the few whom spent their time on it and are capable of handling kdeprefix.
-reavertm = mask
-scarabeus = mask
-jmbsvicetto = can live with mask
-patrick = abstain
-alexxy = mask
-- outcome was that it will be masked in profiles.
-- alexxy will add the mask and adjust the guide.
-
-Handle the PyQt3 qscintilla dependencies
-- it seems that the Qt team has not decided if there is an issue or not. :P
-- it will probably be mostly fixed by removal of Qt3 from profile. See topic no. 1.
-- amarok will have python useflag removed and needed scripts will be removed
-- introduce blocker between PyQt and PyQt4
-
-KDE 4 Stabilisation.
-- Jorge decided to target 4.2 for stabilisation.
-- stabilisation bug will have to be opened
-- tracking bug will have to be opened and bugs wrangled (volunteers??)
-
-Review the useflags we enable by default in Qt herd
-- rename gtkstyle to gtk in qt-gui
-- drop IUSE defaults for useflags enabled by desktop profiles
-
-Progress of KDE3 mess and way how anyone can help (here we call even for non-kdeteam devs)
-- KDE3 misc apps are slowly moving forward
-  mail to dev asking for help :]
-- arts flag removal is also slowly moving
-  (scarabeus will remove optional dep on arts by blocking it in eclass if scarabeus get some time, or anyone else can do it)
-  mail the dev ml announcing its death, and asking maintainers for cooperation.
-- mail the dev ml announcing we need some KDE3 dedicated dev
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090820.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090820.txt
deleted file mode 100644
index 280f93b026..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090820.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Roll-call:
-pesa - excused (no net)
-tampakrap - excused (family issues)
-scarabeus, ABCD, ayoy, patrick, dagger, jmbsvicetto, revartm, wired, yngwin
-
-KDE-3:
-- As discussed before, the KDE team is going to move all KDE3 ebuilds to an overlay. The new
-overlay hasn'te been named yet, but will probably be called kde-junk, kde-sunset or something
-similar as we plan to use it for KDE stuff that is removed from the tree.
-KDE3 is going to be moved to the overlay  either after KDE-4.4 is out if nothing evil happens,
-or after we get 2 KDE4 minor versions marked stable - which likely means around the end of
-the year.
-- We are still looking for KDE maintainers. It seems sping might be interested - yngwin will
-talk to him.
-- Due to the current state of the KDE3 tree source, the lack of support by upstream and the
-increasing security concerns, it's likely that we'll mask KDE3 soon. We're delaying the mask
-until we get a version of KDE4 marked stable - unless more security issues crop up.
-We plan to make an anouncement on Gentoo homepage and to write a news item about the status
-of the KDE3 tree and the security implications.
-We plan to keep KDE3 around in the tree until KDE-4.4 is released (but it will likely remain
-masked) until it's moved to the new overlay.
-- Before we remove KDE3 from the tree, we plan to have a news item, planet blog entries, forums
-thread and front page announcement about it so the kde3ers won't scream for help all over the
-place -  jmbsvicetto.
-
-KDE-4:
-- It was decided by a vote not to ask for 4.2.4 stabilization. It will be dropped from the tree.
-- Instead, the current plan is to get 4.3.1 marked stable. For that, we need to focus on the
-bugs in the tracker[1] and everyone needs to work on it.
-
-QT4-TNG eclass:
-Will be sent for review onto -dev in a week with the -tng name. No better name found out.
-
-Future projects:
-- Documentation polishing
-- Branding the KDE
-- Fix upstream buildsystem to allow install of different versions into a shared prefix
-
-Sets:
-. Adjust it as for bug #272488 or from the ground up for exact specs we need -
-jmbsvicetto (we need to poke him about it often so he won't forget to do it)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100225.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100225.txt
deleted file mode 100644
index 38e8cd46b2..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100225.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-1) New KDE Team Leader elections:
-Scarabeus is the new leader with the majority of votes, congratulations
-
-2) Review work flow for KDE minor bumps and improve collaboration with arch teams
-We decided to skip this topic for next meeting, after preparing some documentation
-on how arch teams can approach packages in the kde overlay.  For the record, scarabeus
-proposed this model: (1) BUG (2) keywordlist (3) portage addition (4) touching profiles
-while jmbsvicetto proposed first to ask arch teams to test new deps in the overlay, if
-they don't want to use the overlay, try to add a snapshot or an early release masked in
-tree and ask them to keyword it, then follow scarabeus' policy.
-
-3) KDE-4.3.5 stabilization
-The KDE team is ready on this, we are just waiting for arches to finish. When they
-do, we will remove both 4.3.3 and 4.3.4 from tree.
-
-4) KDE-4.4 status
-4.4.0 seems very unstable, people are hitting crashes with krunner and plasma, and 
-the virtuoso migration was not smooth for everyone. Thus, we agreed that 4.4.1 or 
-4.4.2 will be a stable candidate, depending of the status of 4.4.1.
-
-5) amarok / mysql-5.1 status
-jmbsvicetto reported that it seems to work for most people for the past three days as
-noone complained. Just amarok[embedded] needs a libmysqld.so as mysql-5.0 did. Jmbsvicetto
-said he resumed his work to get a working patch again.
-
-6) enterprise useflag for kdepim stuff (a use flag to follow the enterprise branch of the
-kdepim repo, only for trunk)
-The problem is that kdepim in trunk currently is broken, more specifically kmail as mail
-storage is being migrated to akonadi, and it seems it will stay broken for a while. Tampakrap
-tried to package the enterprise branch a week ago, but some packages failed to compile, so 
-it may need more work. There is also an enterprise switch in CMakeLists.txt, but since we are
-splitting the module, we need a new batch kdepim ebuilds that will block the current kdepim ones.
-This will allow us to have an always working kdepim though. It seems a lot of work that noone
-seemed interested to do, so we decided to announce it in gentoo-desktop mailing list and call 
-for help. Tampakrap will do it.
-Speaking of trunk, we also discussed about the 4.5 snapshots, and if we should provide them. We
-decided that since kdepim is broken, we won't package them yet, until version 4.4.70. Alexxy 
-will take care of them.
-
-7) koffice status
-Scarabeus said that current koffice needs review of its depedencies based on CMakeLists.txt. 
-Tampakrap will do it and bump it in tree.
-
-8) knetworkmanager status
-Tampakrap said that knetworkmanager seems crashy, but people want it, so we will ask dagger to
-create snapshot, as he is the networkmanager maintainer.
-
-9) documentation status
-Documentation seems fine, reavertm proposed to remove kdeprefix and maybe sets refference from
-the guide. Tampakrap will take care of it.
-Scarabeus with the help of jmbsvicetto will clean up the member list.
-
-10) drop prefixes from kde ebuilds (like kdeartwork etc)
-Noone agreed on this.
-
-11) change kde-meta (and @kde-*) to include all modules (plus the developer specific ones)
-Tampakrap proposed to have every single KDE module in kde-meta (including the developer ones
-like kdesdk and kdewebdev). Many members were opposed, so the idea of a developer USE flag
-for kde-meta was introduced. The discussion will be continued in gentoo-desktop mailing list.
-
-12) stabilization of misc kde apps
-Wired owes us a script that checks for stable candidates in tree.
-
-13) patches of kde-packager
-Jmbsvicetto and ABCD will take care of applying or opening bugs about patches that were
-announced in kde-packager mailing list and need to be applied.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100318.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100318.txt
deleted file mode 100644
index 1c4f5dbb0b..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100318.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-1) Removal of innactive KDE team members
-Since there were no objections last month for scarabeus' draft, he'll proceed in
-removing some members that don't follow the rules. The draft is at
-http://dev.gentoo.org/~scarabeus/kde-team-rules.html
-
-2) Review work flow for KDE minor bumps and improve collaboration with arch teams
-Nothing more was to be said from the last meeting, both scarabeus and jmbsvicetto's
-proposals were accepted.
-
-3) KDE-4.4 status
-4.4.1 seems to be a good release, with not many problems so far. Also, there were
-people working on the kdebindings which was suffering mostly. It will be a stable
-candidate, and the bug will be openned at start of next month.
-
-5) enterprise useflag for kdepim stuff (a use flag to follow the enterprise branch of the
-kdepim repo, only for trunk)
-The call for help didn't bring in any volunteers, so there was no progress on this. Sput told
-that this is very important to be fixed, as kdepim may not be ready for KDE 4.5. Tampakrap will
-try again to raise the issue in ml.
-
-7) koffice status
-KOffice still is in bad status, tampakrap and wired will work on this.
-
-8) change kde-meta (and @kde-*) to include all modules (plus the developer specific ones)
-Following last meeting's discussion on this, tampakrap opened a mail asking for people's
-opinion on this in the gentoo-desktop mailing list, and many people liked the idea. So,
-with scarabeus' permission, tampakrap will add this to kde-meta ebuilds. Kdebindings will
-stay out for now until they all compile.
-
-9) patches of kde-packager
-No actions were done on this, jmbsvicetto said he'll try to take care of it.
-
-10) Split desktop profile
-After a long discussion in gentoo-dev and gentoo-desktop mailing lists, and with the
-approval of the gnome and qt teams (the leads mostly, leio and yngwin), tampakrap
-will finally split the desktop profile to kde and gnome subprofiles. Leio raised the
-need of a better profile system that will support mixed profiles. Tampakrap liked the
-idea and is willing to work on this, but it is going to be long-term
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100604.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100604.txt
deleted file mode 100644
index dcd7c9bee2..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100604.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Meeting topics:
-0) roll-call
-ABCD, alexxy, dilfridge, wired, scarabeus, deathwing00, patrick, jmbsvicetto
-1) KDE 4.4 Stabilisation process. - creating stable team within kde team
-We will add 4.4.4 to main tree, and start the required processes 7 days from that point.
-No stable team since noone volunteer.
-2) KDE 4.5 KDEPIM approach
-  a. give developers one week to express what they feel about kdepim and to see if anyone volunteers to work on it
-  b. if that fails or we can't find anyone willing to do it, make a public announcement about the issue, explain it and give a few options to users:
-  b.1 have interested parties show up and work in the overlay to get it done - (what can be given as option to the community)
-  b.2 have users vote for us to just ignore kdepim until it gets working
-  b.3 give the above 3 options for someone to work on
-3) Koffice 2.2 and designated maintainer choice
-we shall try same approach as for kdepim to see if anyone is interested
-4) Accepting major patches that alter stable branch (pulseaudio) [vote]
-so lets keep status "if you keep it backported and polished you can have it..." together with the old "you break it, you fix it"
-5) People in the team and their inactivity
-Everyone in team is asked to reconsider their status. If they are not really active team members they should just remove themselves.
-Everyone with no evident work on kde packages for last 2 months will be removed from the team.
-Anyone who wants to join back or just join is welcome and just need to ask and be active.
-6) open floor
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100902.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100902.txt
deleted file mode 100644
index ff368dea9a..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100902.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-1) KDE 4.5 status and plans to put it in Portage
-
-We agreed that KDE 4.5.1 is suffering of some important bugs, and after
-a long discussion we decided to put it in portage, but it will never
-make it to stable branch. We are mentioning the upstream bugs, as we
-think that users should be aware of them before updating:
-
-- https://bugs.kde.org/show_bug.cgi?id=247144
-- https://bugs.kde.org/show_bug.cgi?id=246931
-- https://bugs.kde.org/show_bug.cgi?id=230247 <-The most important
-
-Also, keep in mind that KDE SC 4.5 lacks the KDEPIM suite, so users
-should use KDEPIM 4.4.5 instead, which is also stable in portage tree.
-In case of an update it should be smooth.
-
-2) KOffice 2.2 status
-
-There are a few issues with it. The bump to 2.2.2 won't be so easy,
-and most of the linking taking place in koffice-libs is not perfect.
-dilfridge and tampakrap will take care of it, but it may not happen soon.
-
-3) KDEPIM beta packages are released
-
-This was skipped as alexxy, our snapshots master, was absent. It will
-be discussed in gentoo-desktop mailing list
-
-4) Open Floor
-
-- dilfridge reported that digikam is almost ready, he cleaned up the
-patches a lot and will tell reavertm when to move them upstream
-- tampakrap reported that he is going to unmask knetworkmanager
-- reavertm encouraged people working with live and tagged ebuilds to use
-kde-misc/kde-overlay-servicemenus. It is a simple Compare/Merge service
-menu, to avoid manual copy paste.
-- tampakrap, as substitute leader, is going to remove some inactive team
-members, as there were a lot of notices in the past.
-
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20110210.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20110210.txt
deleted file mode 100644
index c38edf66bc..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20110210.txt
+++ /dev/null
@@ -1,107 +0,0 @@
-Present: alexxy, dilfridge, jmbsvicetto, scarabeus, tampakrap
-Absent: ABCD, spatz
-HTs: krytzz, papillon81
-
-0) Elect new lead
-
-nominees:
-Accepted: bonsaikitten, dilfridge, reavertm, tampakrap
-Refused: alexxy, jmbsvicetto, scarabeus
-
-results:
-scarabeus -> tampakrap
-dilfridge -> tampakrap
-bonsaikitten -> tampakrap
-tampakrap -> reavertm
-alexxy -> tampakrap
-reavertm -> tampakrap
-jmbsvicetto -> tampakrap
-
-tampakrap is the new KDE Team Lead
-
-1) Status regarding hal
-
-Since KDE SC 4.6 is out, we don't need it anymore. As soon as 4.6
-gets stable, hal can die.
-
-2) Should we try to form a "stable KDE devs" team? Meaning just call for volunteers on the dev ml?
-
-dilfridge stated that since most of the kde team members use ~arch,
-stable seems to lag behind. The problem is very obvious now, mainly
-because we haven't stabilized 4.4. The problem will go away as soon
-as 4.6 gets stable though.
-Apart from main kde, the misc apps are also slow in stabilization.
-We expect users to request for stabilizations in bugzilla.
-
-3) kde-git/eclasses migration and status, move kdepim 4.6 beta in tree masked
-
-reavertm, Sput, and scarabeus did a major cleanup in our eclasses
-and added git support to eclasses and ebuilds. In order to migrate
-the eclasses to tree we will need to get git-2.eclass in tree first
-(it is now in kde overlay as well). ETA: not less than a month. As a
-side note, we decided to remove koffice-specific codeout of the eclasses.
-
-4) Shall we drop useflags kdeenablefinal and/or kdeprefix to simplify code?
-
-First of all, both useflags are masked. We agreed to keep kdeenablefinal,
-since it is an upstream feature. About kdeprefix, the problem is that
-bindings are not prefixed, and a possible fix (proposed by reavertm)
-would be to slot sip. tampakrap said he'll work on this, and bring the
-topic back in next meeting.
-
-5) Dropping of semantic-desktop useflag with guide update (mostly even kdebase needs it on now)
-
-This entry is invalid, semantic-desktop is not needed by kdebase.
-The problem is in our ebuilds (plasma-workspace is semi broken,
-kdeplasma-addons is completely broken). We have open bugs for those,
-the problem is clearly in our side.
-
-6) Making +consolekit and +policikit or removing the useflags as whole (non working stuff run-as is annoying)
-
-scarabeus and dilfridge are in favour of dropping them, since it
-caused a lot of trouble debugging various user reports. reavertm
-prefers adding it to IUSE defaults. No consensus was succeeded,
-the topic will be continued in the gentoo-desktop mailing list.
-
-7) HT/overlay/bugzie access policy
-
-Since we don't have a clear list of who is an HT and who isn't, we
-decided to compile a list, and state what priviledges the HT has.
-(HT = Herd Tester). Some people don't have time/motivation to complete
-their ebuild quiz, thus we'll have two groups of people:
- * full HTs (overlay access, editbugs, access to ktown, IRC cloak)
- * overlay commiters
-We decided to drop the KDE HT Lead title, seems rather useless.
-
-8) LiveDVD issues
-
-LiveDVD comes with KDE SC 4.6 as default DE, and we called likewhoa
-(the guy behind it) to report any issues. He said that everything
-seems to be fine, but random users wanted the cool gentoo graphics
-to be applied to in-tree ebuilds as well. The KDE Team is willing
-to do that, likewhoa said he'll provide us some artwork and we'll
-discuss again the USE="branding" issue.
-
-9) documentation status
-
-There has been a major improvement in the guide, added some 4.6 specific
-tips and troubleshooting parts, we need to add a hal->udev migration
-guide, and migrate some texts that are in kde overlay to guidexml.
-
-10 & 11) 4.6 (and misc apps with 4.6) status , Early discussion about 4.6 stabilization
-
-KDE SC 4.6 is going fine, we all agreed that 4.6.1 could be a good
-candidate, we'll discuss it again after its release. About a 4.6
-KDEPIM version, no idea yet, we'll have to wait on upstream moves first.
-Most misc apps seem to be fine with 4.6 as well.
-
-*) Open floor
-
-One major issue is digikam, it comes with lots of bundled libraries,
-which violates the Gentoo QA Policy. We heard that Debian has same
-thoughts on the matter, we'll have to bring them to table. Relevant
-bug report: https://bugs.kde.org/show_bug.cgi?id=265328
-
-Desktop Summit! We were invited last year to Akademy to give a talk
-about Gentoo-KDE, noone made it. Some of us expressed interest for
-this year's event, which combines GUADEC and Akademy.
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20110602.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20110602.txt
deleted file mode 100644
index 772a2577e9..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20110602.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-rollcall
-ABCD, alexxy,dilfridge,tampakrap,jmbsvicetto
-
-1) KDE SC 4.6.80 bump
-
-jmbsvicetto and alexxy did a great job so far about it, with ABCD
-forward-porting the commits to the live ebuilds. It is not ready yet though,
-and we'd not recommended to users yet, unless they know what they are doing.
-Upstream split some of the tarballs in order to follow the repos for 4.7. We
-were very lucky so far, and upstream's split was very similar to ours, apart
-from kdebindings, which we'll have to re-package to follow them.
-
-2) Drop of kdeprefix useflag
-
-The kdeprefix USE flag is announced to be dropped this Monday. As a result,
-we'll have to move all ebuilds to slot 4. We could move them to 0 as well in
-order to drop the slotting entirely, but since most of them are already 4 it
-will prevent us from doing another massive slotmove.
-
-3) Useflags in kde profile
-
-It was decided these useflags to be added to the kde profile: declarative,
-dri, kipi, phonon, plasma, semantic-desktop, xcomposite, xinerama,
-xscreensaver
-
-4) KDE SC 4.6.3 stabilization
-
-First of all, dilfridge deserves congratulations for taking care the
-heavy job of doing the 4.6.2 stabilization, along with Qt 4.7 and a large
-number of other Qt and KDE applications. Keep in mind that this was a really
-hard job to do, since the previous stable version was 4.4.5. Things are now
-back in order now, with 4.6.2 fully stabilized and 4.4 completely removed
-(finally). 4.6.3 is the next stabilization target, to keep stable tree up to
-date.
-
-*)Open floor
-
-Andreas said he is interested in doing some cups work, which we hope to affect
-KDE and desktop users in general.
-
-We lost scarabeus, one of our top developers. Thus,
-we'd like to remind anyone that we always appreciate the help of new people.
-If you are one of the guys that already has access to the overlay, time to
-complete your ebuild and end quiz then!
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120116.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120116.txt
deleted file mode 100644
index bb34fcdf47..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120116.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-1. Roll call
-alexxy, jmbsvicetto, dilfridge, johu, mschiff, tampakrap, Thev00d00
-
-2. Electing a new team leader
-Since one year is not over yet, it will be skipped for the next meeting.
-
-3. What shall we do with kdepim-4.4
-KDEPIM 4.4 is not supported any more by upstream, but on the other hand
-KDEPIM2 is still too buggy. We had a discussion if we should remove it
-completely or if we should continue maintain it, despite the compatibility
-bugs that started to emerge with newer KDE versions. Final decision is that we
-will continue support it as long it works with newer KDE SC releases. We'll
-keep the kdepim-l10n split package to provide the translations for it.
-
-4. kdeenablefinal revisited
-Since upstream doesn't seem to care about it much, plus it doesn't make much
-sense now that there are many split tarballs, we decided to remove it the next
-day after the meeting.
-
-5. phonon-xine removal
-KDE upstream acknowledged that this is not maintained anymore. It's already
-masked since 2011/12/01. Will be last rited and removed 15 days afterwards.
-
-6. Qt 4.8
-We expect no big issues with it. Kdenlive is the only known application that
-does not build at the moment and will be patched. kde-base/kstyles-4.7.* needs
-to be rebuilt after the upgrade, which we'll solve with a combination of
-revbump/dependencies (otherwise KDE apps using oxygen style crash). 
-
-7. Dropping RPATH from installed binaries
-Postponed for next meeting, need more info from reavertm and/or hardened herd.
-
-8. To eselect Boost or not to eselect boost
-No final decision was taken, discussion will be moved to -dev mailing list.
-
-9. Bugs
-* dev-util/cmake picks always the latest boost.
-* Fix in overlay since 13. Dec. Move to tree?
-https://bugs.gentoo.org/show_bug.cgi?id=335108
-see 8.
-
-* cmake-utils.eclass PREFIX is not defined, any progress? 
-https://bugs.gentoo.org/show_bug.cgi?id=358059
-Postponed for next meeting
-
-* Remove hard dep on media-libs/phonon from kde-base/kdelibs
-https://bugs.gentoo.org/show_bug.cgi?id=356681
-https://bugs.gentoo.org/show_bug.cgi?id=388041
-Although it is possible to build kdelibs against qt-phonon, it is not
-recommended by upstream. Decision postponed for next meeting.
-
-* Eclass problem with handbook without LINGUAS.
-https://bugs.gentoo.org/show_bug.cgi?id=372457
-Needs more analysis. Postponed.
-
-* MacOSX request for cmake-utils.eclass:  Remove force of
-* CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE
-https://bugs.gentoo.org/show_bug.cgi?id=398437
-That was a request by the Gentoo Prefix team, and is accepted
-
-* Revise the change "semantic-desktop? -> semantic-desktop=".  Why was the
-* change needed.
-https://bugs.gentoo.org/show_bug.cgi?id=396491
-We had split opinions on this. Skipped for next meeting, as we need
-reavertm's input on this.
-
-10. Open floor
-Tampakrap will make a KDE SC 4.8 release party in Prague, more info coming soon.
-Qt meeting on Thursday 26th Jan.
-See you at fosdem :)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120322.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120322.txt
deleted file mode 100644
index 478887b5a4..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120322.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-1. Roll call

-alexxy, dilfridge, johu, mschiff, scarabeus, tampakrap

-

-2. Electing a new team leader

-

-nominees:

-Accepted: dilfridge, johu

-Refused: tampakrap, scarabeus

-

-results:

-johu -> dilfridge

-dilfridge -> johu

-tampakrap -> dilfridge

-alexxy -> dilfridge

-mschiff -> dilfridge

-scarabeus -> dilfridge

-----------------------

-dilfridge:5 - johu:1

-----------------------

-dilfridge is the new KDE team leader with the majority of votes.

-Congratulations!!!

-

-3. Dropping RPATH from installed binaries

-Add a RPATH entry for every library dir that is not in the system library

-directories in ld.conf are not automatically considered as system library

-dirs, but only some static list of dirs. 

-Everyone agreed on RPATH removal. We will introduce a patch with KDE SC 4.8.2

-to remove the RPATH and move it to the main tree.

-

-4. Bugs

-* Remove hard dep on media-libs/phonon from kde-base/kdelibs

-https://bugs.gentoo.org/show_bug.cgi?id=356681

-https://bugs.gentoo.org/show_bug.cgi?id=388041

-Upstream says "technically you can replace phonon with qt-phonon, but that's

-just stupid because you lose functionality". Another argument against it, is

-that qt-phonon will be removed with qt5. We wont fix the bug and keep phonon as

-hard dep. johu will take care of the bug after meeting summary is available.

-

-* Eclass problem with handbook without LINGUAS.

-https://bugs.gentoo.org/show_bug.cgi?id=372457

-The handbook eclass code is pretty confusing for all in meeting present

-members. It was written by reavertm. We decided that we will mail reveartm to

-fix handbook eclass code, because he has the most knowledge in it. dilfridge

-will take care of contacting him, it's his first lead task.

-

-* Revise the change "semantic-desktop? -> semantic-desktop=".

-https://bugs.gentoo.org/show_bug.cgi?id=396491

-Some packages rely on semantic-desktop capabilities in other ones. tampakrap

-is volunteers to take care of the bug.

-

-5. Open floor

-* KDE 4.8 stabilization

-KWin does not build anymore without opengl support. kde-base/kmail-4.8.1

-crashes, but upstream patch can be backported. KDE SC 4.8.1 has tons of

-bugfixes, compared to to 4.8.0. The majority votes for KDE 4.8.1 as stable

-candidate. johu will prepare stabilization. 

-

-* Test failures 

-creffett brought up dbus-related test failures. johu recommended to get

-virtual-dbus eclass running. dilfridge suggested if one or two test fails

-or restrict. The problems with virtual-dbus is that you can't run bash

-commands in it's environment. creffett will be responsible for this.

-

-* New members

-Welcome to three new members of the project: creffett, kensington and

-dastergon. They are in the process to become gentoo developer and mentored by

-tampakrap. creffett and kensington have already open 'new developer' bug.

-dastergon doesn't have an open bug yet.

-

-* Comeback

-scarabeus re-joined KDE herd. Welcome back!!!

-

-* Reduced work time

-mschiff mentioned that he will not have much time for the KDE herd due to

-real life priorities, he will be back in may. tampakrap will spent most of his

-time for gentoo infra team.

diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120419.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120419.txt
deleted file mode 100644
index 267ca5b292..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120419.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-1. Roll call
-alexxy, dilfridge, kensington, johu, scarabeus, tampakrap, thev00d00
-
-2. KDE SC 4.8.2 stabilization after it is 30 days in tree?
-KDE SC 4.8.1 is stable for amd64 and x86, ppc is still pending. We decided to
-skip the stabilization for KDE SC 4.8.2 to reduce the work load for the arch
-teams. Scarabeus suggested that we can stabilize other kde herd related
-packages in the meantime. No objections, so we will walk over the packages,
-search for candidates and file stable bug requests. 
-
-3. Calligra 2.4.0 stabilization after it is 30 days in tree?
-We are getting more and more bugs related to koffice. Calligra is the
-successor of koffice. Qt 4.8.1 stabilization will be needed before, as a build
-requirement for calligra. No arguments or objections against stabilization,
-which will end up in replacement of koffice with the normal last rite
-procedure.
-
-4. Do we want to stabilize KDE SC 4.9.x on arm?
-The number of arm gadgets will go up more and more, while ppc machines are
-falling apart. KDE SC should work on arm. Sabayon would benefit by
-stabilization too. We will need Qt 4.8.x stable on arm before. Unfortunately
-none of the kde herd members have the hardware to test it. So we will need
-volunteers/testers for that. Additionally we could think about packaging
-plasma-active too. Dilfridge will ask arm herd about the idea, if they like
-it, he will blog about it.
-
-5. Remove tar command ewarns in eclasses? 
-They are useless and anoying nowadays. Scarabeus acknowledged that they can be
-removed.
-
-6. Open bugs
-* Bug #358059 - cmake-utils.eclass PREFIX is not defined
-Scarabeus acknowledged that the patch is correct. We will test it in kde
-overlay first.
-
-* Bug #372457 - doc dir is not correctly disabled by kde4-functions.eclass if
-NOT kde-base and LINGUAS is unset
-Chris Reffet found a solution. We will test it in kde overlay first.
-
-7. Open floor
-* Tampakrap mentioned that SLES will have KDE 4.8 soon.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120517.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120517.txt
deleted file mode 100644
index 463ee86916..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120517.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-1. Roll call
-alexxy, creffett, dilfridge, johu, kensington, reavertm
-
-Welcome new developers kensington and creffett. Thanks to JoseJX for
-participating as member of the powerpc team.
-
-2. Add LINGUAS support to cmake-utils.eclass
-Agreed to add a loop like that in qt4-r2.eclass to reduce ebuild code. It
-expands the contents of LANGS to IUSE as linguas_*. A generic linguas handling
-is not planed yet. 
-
-3. Live KDE ebuilds have tests restricted
-The usefulness of tests on live ebuilds was brought into question, since there
-are enough problems with tests on normal releases. Agreed to enable tests when
-I_KNOW_WHAT_I_AM_DOING is set.
-
-4. KDE 4.8 stabilization and PowerPC
-The stabilization and keywording was pending up to the team meeting date,
-because of gcc47 as requirement to restore the keywords on ppc/ppc64. This
-blocker was mistaken added. PowerPC needs just Qt 4.8.1 to keyword KDE 4.8.
-So there are no reasons the discuss to drop the ppc support from kde-base.
-We never stabilized a KDE version on ppc64, because ppc64 has problems with
-the size of the table of contents for ELF function calls that will be fixed
-with gcc 4.7. johu ask for voting on dropping ppc64 at all. No real
-majority/opinions about it. JoseJX prefers that ~ppc64 not be dropped from KDE
-keywords. Agreed that JoseJX would keyword ~ppc, and if there were no problems
-would also keyword ~ppc64, topic will be revisited.
-
-5. Bugs
-* Trying to change full name in KDE System Settings results in error or crash
-https://bugs.gentoo.org/380899 
-There is an existing workaround to disable the change full name functionality.
-kensington will talk to upstream about the issue, and if there is no good
-response in 2 weeks' time, we will apply the workaround.
-
-* app-cdr/k3b: use media-libs/musicbrainz:3 instead of :1
-https://bugs.gentoo.org/410347
-Agreed that musicbrainz:1 is obsolete and that k3b does not appear to actually
-use musicbrainz even when enabled. Dependency on musicbrainz will be dropped.
-
-* dev-util/cmake: FindPythonLibs behaviour broken by Gentoo patches
-https://bugs.gentoo.org/405181 
-Dilfridge said that we should remove the patches and use command-line defines
-to force specific python versions, agreed to test that.
-
-* kde-misc/networkmanagement-0.9.0 and kde-misc/networkmanagement-0.8_p20110714 
-wrong doc dir specified - https://bugs.gentoo.org/410139
-Nobody has been able to reproduce the bug. Dilfridge suggested asking for more
-information and will investigate further.
-
-* kde-misc/interceptor - KDE4 Plasmoid - intercept (catch) the log info from
-the syslog - https://bugs.gentoo.org/383733 
-creffett suggested dropping this request because it requires too many big
-configuration changes for a plasmoid. Agreed to remove kde from CC list and
-suggest taking the ebuild to sunrise.
-
-* dev-util/cmake-2.8.6-r4 - stop Xvfb after failed test phase
-https://bugs.gentoo.org/406353
-Need input from gentoo-portage team about what phase could be used to clean up
-xvfb after test failures. Kensington mentioned that the same issue will affect
-virtualdbus.
-
-6. Open Floor
-* KDE 4.9 Beta
-Dilfridge reported that KDE 4.9 beta is coming out soon.
-
-* Groupdav calendar bug in kdepim-runtime
-Discussed whether to stabilize kdepim-runtime base version or -r2, which has a
-possible fix for https://bugs.gentoo.org/show_bug.cgi?id=415401 but no
-positive feedback. Agreed to go with -r2.
-
-* creffett away
-creffett will be out for a month on a trip with little internet access.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120621.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120621.txt
deleted file mode 100644
index 6f246e91e8..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120621.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-1. Roll call (4 minutes, 5 minutes planned)
-Present: alexxy, dilfridge, scarabeus, tampakrap
-
-2. Move KDE 4.8.4 to the tree, and in which variant? (1 minute, 5 minutes planned)
-   It seems that the problems have been solved with a) newer soprano or b) reverted commit.
-   Which way do we want to go?
-All in favour of reverting the commit in kdelibs and pushing 4.8.4 to the tree to work
-with "old" soprano.
-
-3. Once it's out, should we move KDE 4.9.0 to the tree? (3 minutes, 10 minutes planned)
-   Currently 4.8.90 looks quite solid, so this is a real option.
-All in favour of adding 4.9.0 to the main tree as ~arch
-
-4. Udisks2 (8 minutes, 5 minutes planned)
-   On request from Samuli I've added the Udisks2 patch from RedHat to kdelibs. This
-   *replaces* the udisks:0 solid backend with a new udisks:2 version. Has according 
-   to Wulf (Philantrop) still some issues.
-   Feedback? Experiences? Keep for 4.9.0 or (temporarily) ditch again?
-No decision, some discussion with alexxy and Philantrop about the problem. We'll keep
-watching Fedora's code and talk to the Fedora maintainers.
-
-5. Bugs (1 minute, 30 minutes planned)
-   * app-cdr/k3b: Excessive use of REQUIRED_USE (and wrong combination USE="lame"+"encode")
-    REQUIRED_USE was added, otherwise USE="-encode lame" does nothing
-    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)
-    https://bugs.gentoo.org/show_bug.cgi?id=417235    
-Postponed since the principal actors involved were absent.
-
-6. Open floor (10 minutes, 15 minutes planned)
-tampakrap asks for more speakers and workshop organizers at the Gentoo miniconf October in
-Prague. Some ideas are thrown around, nothing definite yet.
-
-[21:34:02] <dilfridge> meeting closed
-[21:34:13] <dilfridge> i think we just made a new speed recoed
-[21:34:19] <dilfridge> :)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120816.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120816.txt
deleted file mode 100644
index b68e32f639..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20120816.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-
-KDE team meeting summary
-
-
-1. Roll call
-KDE team members present: 
-ago, creffet, dilfridge, jmbsvicetto, johu, tampakrap, thev00d00
-
-
-2. KDE SC stabilization: discuss/vote on the following 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?
-
-After some discussion, a vote resulted in 5 votes for a), 1 vote for b). 4.8.5
-has two remaining (upstream) issues (da translation error and a missing theme
-for ksplashx) which will be locally addressed in time before stabilization.
-
-Ago suggested that we should follow the Kernel crowd, and only ever stabilize a
-late release in every KDE series ("x.x.7/8"). Most of the other team members
-were against that idea, since
-* we'd find Gentoo-specific problems only very late then (when the large crowd 
-  migrates)
-* and people will complain if we wait with stable upgrades too long.
-As a compromise we settled on "4.9.0 will never go stable, we talk about 4.9.1
-when it's out for a while".
-
-
-3. Solaris patches: 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?
-
-Nobody present had any opinion or cared about the solaris stuff. As a result it
-was decided to drop the patches. 
-
-On #gentoo-prefix this was ack'ed later by darkside for the prefix team. ryao
-noted there that Qt is broken on Prefix at the moment, and that the KDE patches
-could become relevant again after that is fixed.
-
-
-4. KDE stable subproject: Ago proposed a "KDE stable subproject" some time ago
-via mail. The idea is that the subproject members test KDE stable candidates on
-an otherwise completely stable system as soon as we decide on a stable
-candidate, to make fast and bug-free stabilization possible as soon as its
-30days in the tree.
-
-Discussion led to various points:
-* Ago is mainly thinking of Gentoo-specific stable candidate QA.
-* The "stable subproject" obsoletes the (dead) "herd testers" subproject which
-  we tried to start up some time ago.
-* No quiz required for participation.
-* Johu suggested a more upstream-oriented direction ("like kdepim bug day"), 
-  which however seems like a different endeavour.
-* In the end, there were no objections, Ago takes care of establishing that 
-  group of people and updates our site.
-
-
-5. Bugs
-
-5a. Bug 417235: app-cdr/k3b: Excessive use of REQUIRED_USE
-Majority decision was to keep the REQUIRED_USE, but rename lame -> mp3
-
-5b. Bug 430608: cmake-utils.eclass: add support for dev-util/ninja
-It was decided to apply the patch and make building with ninja possible; 
-however, if the build fails a message about using an unsupported backend
-should be logged (if possible).
-
-5c. Bug 427910: app-office/calligra-2.4.3: move fonts to separate packages
-and related bug 427914: www-client/rekonq-1.0: please move Nunito-Regular.ttf 
-to separate package
-Most people present did not really care. Consensus was
-* Find out if there is any license problem with the status quo.
-* If yes, talk to upstream and try to solve the problem with them.
-Nobody volunteered to research the license situation.
-
-5d. Bug 430858: net-libs/libkolabxml-0.8.0[php] fails
-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). Consensus
-was to provide upstream with a FindPHP5 module and ask for inclusion. 
-
-
-6. Open floor
-
-6a. Further discussion about the stable subproject
-Tampakrap notes that for recruiting devs a subproject with overlay access is not
-the most efficient way, since people tend to be happy with overlay access and 
-are reluctant to go through the actual recruiting process. We should try to 
-motivate people to become full developers. In addition he offers to mentor
-people.
-
-6b. Default KDE_SCM
-Johu proposes to switch this to git. Noone opposes.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-qt-projects-meeting-log-20091119.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-qt-projects-meeting-log-20091119.txt
deleted file mode 100644
index 7f1c17b579..0000000000
--- a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-qt-projects-meeting-log-20091119.txt
+++ /dev/null
@@ -1,959 +0,0 @@
-[20:45:05] <wired> toum toum
-[20:46:51] <yngwin> sssh
-[20:48:34] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: Upstream split packages (per kde-scm-interest mail i told you to read)'
-[20:52:39] *** Joins: zizo (n=Zizo@host214-182-dynamic.4-87-r.retail.telecomitalia.it)
-[20:52:59] *** Parts: zizo (n=Zizo@host214-182-dynamic.4-87-r.retail.telecomitalia.it)
-[20:56:35] *** Joins: PSYCHO___ (n=scarabeu@gentoo/developer/scarabeus)
-[20:56:35] *** ChanServ sets mode: +o PSYCHO___ 
-[20:57:05] <wired> darn 3g con
-[20:59:38] <wired> so... meeting time? :)
-[21:01:16] <yngwin> yup
-[21:01:19] <PSYCHO___> indeed
-[21:01:27] <PSYCHO___> anyone can record the histroy?
-[21:01:38] <PSYCHO___> i cant log, because quassel is not entirely cooperating right now
-[21:01:39] * wired logging
-[21:01:48] <PSYCHO___> for the log <- scarabeus
-[21:02:04] <PSYCHO___> ok so lets start with rollcall
-[21:02:05] <wired> even if I seem down my znc/bouncer will keep logging, im on a 3g connection right now (dsl is down)
-[21:02:33] *** Joins: spatz (n=spatz@gentoo/developer/spatz)
-[21:03:18] *** Joins: ayoy (n=ayoy@gentoo/developer/ayoy)
-[21:03:39] *** Joins: mrpouet (n=quassel@gentoo/developer/mrpouet)
-[21:03:45] <PSYCHO___> ok so anyone else here?
-[21:04:02] *** Joins: wohnout (n=wohnout@88.86.113.238)
-[21:04:02] <spatz> me
-[21:04:09] <tampakrap> you are so lame
-[21:04:11] <dagger> me
-[21:04:12] <tampakrap> !herd kde
-[21:04:13] <Willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired
-[21:04:13] * wired here
-[21:04:13] <mrpouet> and me
-[21:04:17] <tampakrap> !herd qt
-[21:04:18] <Willikins> (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin
-[21:04:18] <wohnout> PSYCHO___: stop talking and start working
-[21:04:19] <tampakrap> roll call
-[21:04:22] <yngwin> present
-[21:04:22] <PSYCHO___> :D
-[21:04:24] <ayoy> I'm here
-[21:04:27] <spatz> HERE
-[21:04:46] <spatz> only qt people
-[21:04:52] <PSYCHO___> spatz: it is required only to say it once
-[21:04:53] <DrEeevil> mostly present
-[21:04:58] <mrpouet> while(1) printf("HERE\n");   :D
-[21:05:03] <spatz> PSYCHO___: here :D
-[21:05:04] <mrpouet> okay ==> [ ]
-[21:05:34] <wired> some get kde 3.5 killer... errr.... ssuominen here as well! :P
-[21:05:43] <PSYCHO___> ok thats not exactly attendance i expected
-[21:06:10] <wired> scarabeus: lets wait at least 5 more minutes
-[21:06:42] <wired> im also worried that some people might show up in an hour or so...
-[21:06:46] <PSYCHO___> ok
-[21:06:59] <spatz> because of DST?
-[21:07:04] *** Joins: Sput (n=sputnick@quassel/developer/sput)
-[21:07:04] <wired> yeah
-[21:07:15] <wired> happened last time
-[21:07:23] <PSYCHO___> they can use date -u
-[21:07:29] <PSYCHO___> so thats not exactly excuse
-[21:07:45] <wired> no'ones trying to excuse them
-[21:07:47] <yngwin> dst stinks
-[21:07:47] <wired> :P
-[21:07:56] * spatz uses date -u
-[21:09:17] <ayoy> so?
-[21:09:28] <wired> so
-[21:09:28] <yngwin> agenda?
-[21:09:30] <wired> time's up, lets go!
-[21:09:42] <PSYCHO___> yngwin: agenda is on -desktop-ml in that mails
-[21:09:43] <wired> scarb has first item @ /topic
-[21:10:00] <PSYCHO___> i will put them onto the topic as we will be going
-[21:10:03] <yngwin> thats scattered
-[21:10:22] * wired fixes agenda
-[21:12:07] <wired> ok
-[21:12:09] <wired> agenda: http://dpaste.com/122485/
-[21:12:30] <yngwin> thanks
-[21:12:32] <wired> read it while i clean it up a bit
-[21:13:00] <ayoy> what about starting from Qt since KDE has a lot to talk about?
-[21:13:52] <PSYCHO___> Ingmar: btw are you around?
-[21:14:14] <wired> updated agenda: http://dpaste.com/122486/
-[21:14:36] <wired> ok lets roll
-[21:14:51] <wired> 21.15 already
-[21:14:58] <ayoy> true
-[21:15:03] <yngwin> PSYCHO___: are you presiding?
-[21:16:02] <PSYCHO___> ok so lets start
-[21:16:06] <PSYCHO___> i was smashing my net a bit
-[21:16:48] <wohnout> internet has swine flu
-[21:17:26] <PSYCHO___> yeah looks so
-[21:17:29] * wired whistles
-[21:17:36] <PSYCHO___> !herd kde
-[21:17:37] <Willikins> PSYCHO___: (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired
-[21:17:38] <mrpouet> aarfff dinner time :(
-[21:17:42] <PSYCHO___> so listen up
-[21:18:08] <PSYCHO___> anyone of you did read that mail from Ingmar? or you just idled like usual?
-[21:18:21] <tampakrap> yes we did
-[21:18:22] * spatz read it
-[21:18:25] * wired did read it 
-[21:18:27] <dagger> i did
-[21:18:36] <PSYCHO___> http://article.gmane.org/gmane.comp.kde.scm-interest/724
-[21:18:46] <PSYCHO___> there is my response to that mail thread
-[21:19:06] <tampakrap> give us a min to read
-[21:19:08] <PSYCHO___> it is how i imagine layout that would suit us packagesr best
-[21:20:29] *** Joins: j0 (n=quassel@g227216073.adsl.alicedsl.de)
-[21:20:29] <PSYCHO___> anyway the question that waits here: "Is anyone willing to work on this?"
-[21:21:15] <tampakrap> yes
-[21:21:26] <tampakrap> did you get any response from upstream?
-[21:21:33] <scarabeus> nope, this mail is last in that thread
-[21:22:16] <tampakrap> so we are waiting until upstream responds to that first, or not?
-[21:22:39] <scarabeus> actualy nope, i expect someone coordinate with ingmar and prepare full proposal to them
-[21:22:55] <scarabeus> because my 6 lines about layout are not exactly "full proposal"
-[21:23:00] <wired> upstream surely knew we have split kde
-[21:23:11] <tampakrap> yes they do
-[21:23:12] <wired> the real question is, do they really want to take this route?
-[21:23:40] <scarabeus> well some stated that they would like it, some otherwise
-[21:23:48] <tampakrap> i've also seen discussions about splitting in the past going nowhere (two at least) but never mind
-[21:24:10] <scarabeus> well this time they are migrating to another SCM so it might have better chance to win :]
-[21:24:18] <tampakrap> agreed
-[21:24:42] <tampakrap> does Ingmar (ping) have anything else to say in this topic? (apart from what you said in the mail?)
-[21:25:19] <scarabeus> well he is aparently not around, so the interested person will have to mail him or irc him at some better time
-[21:25:30] <spatz> do binary distros (pretty much everybody) have split packages or monolithic ones?
-[21:25:46] <wired> debian has them split
-[21:25:52] <wired> after compilation tho
-[21:25:56] <Ingmar> hello
-[21:26:05] <tampakrap> they compile them in monolithic way and ship them in split way
-[21:26:08] <wired> hey Ingmar 
-[21:26:09] <Ingmar> scarabeus, tampakrap hi
-[21:26:18] <tampakrap> hello
-[21:26:54] <spatz> doesn't matter how they do it, only whether they do it. if this change forces everybody to split their packages whereas now they have monolithic ones we might face some opposition
-[21:26:56] <Ingmar> scarabeus: as you said, i'd like to see upstream move to a buildsystem layout more similar to what xorg has
-[21:27:19] <Ingmar> scarabeus: i'm less interested in splitting out the libs, or base, but the debian packager i talked to found that more important than anything else
-[21:27:34] <tampakrap> spatz: other distros follow upstream's way, so they will be forced to change it
-[21:27:36] <Ingmar> presumably because they can easily split the rest after buil
-[21:27:39] <Ingmar> d
-[21:27:45] <Ingmar> s/can/can & already do/
-[21:28:21] <scarabeus> well from what we can say the initiative to do the thing will have to cover 2 areas) explaining what to do and how ) showing some example repo done that way
-[21:29:04] <Ingmar> yeah
-[21:30:04] <scarabeus> so ANY volunteers for this?
-[21:30:09] <tampakrap> yes
-[21:30:21] <tampakrap> and you?
-[21:30:29] <scarabeus> Ingmar: also i would like to see at least one relevant upstream guy acking that we are not just wasting our time
-[21:30:30] <Ingmar> I am, obviously :)
-[21:31:01] <Ingmar> well, let's start with a proof of concept for one module
-[21:31:04] <scarabeus> i myself will try to help
-[21:31:48] <Ingmar> i'd put together a proof of cencept first & see what they say on the relevant mailinglists
-[21:32:01] <scarabeus> ok that sounds reasonable
-[21:32:12] <scarabeus> splitting kdenetwork or kdeedu might be quite easy
-[21:32:24] <tampakrap> Ingmar: did you get any affirmative responses from other packagers (and more importantly) by any upstream developer?
-[21:32:51] <Ingmar> scarabeus: i was thinking kdenetworok, so yeah :)
-[21:33:09] <Ingmar> tampakrap: packagers yes (debian & gentoo, didn't ask anyone else), didn't ask any specific upstream devs
-[21:33:20] <tampakrap> ok
-[21:33:33] <scarabeus> Ingmar: also we should steal some irc channel to have it covered, i guess we cant chit-chat on g-kde or e-kde since its bit offtopic :]
-[21:33:36] <Ingmar> on the kde-scm-interest ml, some were in favor, and some where against
-[21:34:16] <scarabeus> any name ideas? :]
-[21:34:39] <wired> #kde-split
-[21:34:41] <Ingmar>  /j #kde-build-split :)
-[21:34:48] <scarabeus> ok
-[21:35:01] *** Parts: wohnout (n=wohnout@88.86.113.238)
-[21:35:23] <Ingmar> anything else on the subject?
-[21:35:36] <PSYCHO___> i would say that for meeting we covered it
-[21:35:46] <PSYCHO___> i personaly will try to motivate few more people
-[21:35:52] <PSYCHO___> but that is non-meeting subject :]
-[21:36:03] <tampakrap> Ingmar: apart from kde-scn-interest ml, any other mailing lists you'd like to see us subscribed?
-[21:36:55] <Ingmar> kde-buildsystem
-[21:37:08] <Ingmar> well, if you have more minions, you know where to send them :)
-[21:37:20] <tampakrap> okz
-[21:37:41] <tampakrap> ok i think we're done with this for now
-[21:37:48] <tampakrap> next topic plz?
-[21:37:54] <spatz> first topic plz :)
-[21:37:55] <scarabeus> tampakrap: now something qt i would say
-[21:38:00] <scarabeus> since there is more qters
-[21:38:09] <wired> scarabeus: lets just do the agenda?!
-[21:38:27] <scarabeus> as you wish
-[21:38:33] <scarabeus> ok documentation
-[21:38:41] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: Documentation'
-[21:38:43] <spatz> stabilization first
-[21:38:44] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 2: Documentation'
-[21:38:54] <wired> http://dpaste.com/122486/
-[21:38:56] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: stabilisation'
-[21:39:35] <PSYCHO___> ok so since only samuli is working on it with me has anyone looked on the bug
-[21:39:43] <PSYCHO___> or attempted to fix blocker bugs
-[21:40:04] <tampakrap> bug # plz?
-[21:40:15] * wired hasn't looked at kde 4.3.3 bugs lately, but will
-[21:40:25] <spatz> bgu 292455
-[21:40:26] <spatz> bug 292455
-[21:40:28] <Willikins> spatz: https://bugs.gentoo.org/292455 "KDE 4.3.3 stabilization request"; Gentoo Linux, Applications; NEW; ssuominen@g.o:kde@g.o
-[21:40:41] <PSYCHO___> bug 2: Documentation
-[21:40:43] <PSYCHO___> erm
-[21:40:43] <Willikins> PSYCHO___: https://bugs.gentoo.org/2 "How do I attach an ebuild."; Gentoo Linux, Ebuilds; RESO, FIXE; tneidt@fidnet.com:hallski@g.o
-[21:40:45] <PSYCHO___> damn this
-[21:40:49] <PSYCHO___> as spatz said
-[21:40:51] <wired> lolz
-[21:41:02] <spatz> lol
-[21:41:28] <wired> so 13 bugs
-[21:41:47] <wired> i can try to help this weekend
-[21:41:50] <PSYCHO___> i want each member of kde team to fix at least 1
-[21:42:28] <tampakrap> 12 bugs, 3 stable req and 1 keyword req
-[21:42:29] <PSYCHO___> also i want someone to look on current open bugs
-[21:42:40] <PSYCHO___> and decide which should be blocking the stabling
-[21:42:50] <PSYCHO___> and on this i want volunteer that will actualy do it
-[21:43:05] <tampakrap> and also close the remaining kde3 bugz
-[21:43:13] <spatz> we can't really do much with keyword/stable requests
-[21:43:43] <PSYCHO___> are still there are normal bugs, and not all bugs are now blocking the stabilisation even if they should
-[21:43:47] <PSYCHO___> so who will do it
-[21:45:13] <tampakrap> ok i'll do it since noone is interested
-[21:45:19] <tampakrap> meaning the bug wrangling
-[21:46:11] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 2: documentation'
-[21:46:12] <PSYCHO___> ok
-[21:46:19] <PSYCHO___> next topic
-[21:46:41] <PSYCHO___> as i stated
-[21:46:54] <PSYCHO___> I want devoted person focusing on updating our documentation with nedy
-[21:47:02] <mrpouet> as wired I can try to help this week end (I've an exam tomorrow and I've to finish a project)
-[21:47:04] <tampakrap> yes but i disagree with that
-[21:47:45] <PSYCHO___> tampakrap: so how would you do the documetnation
-[21:47:53] <tampakrap> everyone of us should just realize that documentation is *VERY* important and write two words before a major update or whatever
-[21:48:01] <tampakrap> apart from that i have another idea that you may like
-[21:48:31] *** Joins: ssuominen (n=ssuomine@gentoo/developer/ssuominen)
-[21:48:38] <PSYCHO___> speak up :]
-[21:48:43] <tampakrap> since guidexml requires gorg in order to have a fully rendered (human readable) doc
-[21:49:15] <tampakrap> i have created an svn repo in my home server that checks out through a hook to a gorg-accessible path
-[21:49:22] <tampakrap> so it can be read immediatelly
-[21:49:48] <tampakrap> i can give access to the team here to my home server so we can *ALL* (and i mean ALL, even HTs) develop the guide
-[21:49:56] <tampakrap> no excuses about permissions etc
-[21:50:13] <tampakrap> unless you can provide us such a hook, since you have access in overlays.g.o
-[21:50:14] <PSYCHO___> well that was done even on git server remember
-[21:50:16] <mrpouet> I agree, so +1
-[21:50:27] <PSYCHO___> i wrote complete guide in overlay as non-dev
-[21:50:59] <tampakrap> yes but i'm talking about an immediate co to an xml gentoo.org-like site
-[21:51:17] <tampakrap> which makes things easier
-[21:51:25] <yngwin> this once again shows the shortcomings of guidexml
-[21:51:42] <PSYCHO___> well ok
-[21:51:48] <PSYCHO___> tampakrap: you then write up something and enforce it
-[21:52:01] <tampakrap> well, i don't agree with that, it shows that noone cares about docs which is sad
-[21:52:38] <tampakrap> come on, i just stated something, we can proceed in voting i guess, or go in your way then
-[21:53:20] <PSYCHO___> well i am willing to use it, problem is that noone else will edit it, its the same problem as is now
-[21:53:36] <wired> we can give it a shot
-[21:53:37] <PSYCHO___> we can keep those guides in our public_html folders to see it right-away
-[21:53:39] <wired> until next meeting
-[21:53:42] <PSYCHO___> but noone edit it anyway
-[21:53:50] <tampakrap> that's not the same
-[21:53:56] <wired> but we should *also* have someone in charge
-[21:54:18] <PSYCHO___> well i wanted someone in charge
-[21:54:22] <PSYCHO___> so he can say
-[21:54:26] <wired> that someone would check other commits and will _in_time_ get closer to the docs team
-[21:54:30] <ABCD> sorry I'm late; I forgot about the time change :(
-[21:54:31] <tampakrap> i could be in charge of docs since i am the main editor a while now, but i don't like this idea
-[21:54:36] <PSYCHO___> You XY wrote module for AB but did not document it, so do it now.
-[21:55:12] <PSYCHO___> so actualy devs introducing something new will be somehow forced to do the docs
-[21:55:38] <PSYCHO___> because "anyone does docs and we are happy" simply is NOT working
-[21:55:43] <tampakrap> the problem is that we don't update the docs BEFORE the change (minor or major)
-[21:56:31] <PSYCHO___> well that would be responsibility of doc master, to point when and what needs to be changed
-[21:56:35] <tampakrap> and that won't change by itself, even if we could write the docs in speech-to-text app
-[21:57:22] <PSYCHO___> i dont expect the lead to do the work, but delegate to other devs, and if those wont document, i am even willing to remove them from team
-[21:57:31] <tampakrap> okay i could do that but i'd expect from the members to respect more the documentation part
-[21:58:31] <tampakrap> okay if noone has a problem with that then i'll take charge of this position
-[21:58:40] *** Quits: ayoy (n=ayoy@gentoo/developer/ayoy) (Remote closed the connection)
-[21:58:52] <wired> tampakrap++
-[21:58:53] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi)
-[21:58:53] <PSYCHO___> ok
-[21:59:06] <tampakrap> i'll also introduce my system to gentoo-desktop mailing list (i hope devs+HT's are subscribed there)
-[21:59:09] <mrpouet> PSYCHO___: huh ? remove them from team ? for that ? (I agree document is an important thing does not matter) ... but blame them instead
-[21:59:23] <wired> while we're on the docs subject, note that I'm taking care of Qt docs
-[21:59:27] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 3: upstream coordination'
-[21:59:32] <tampakrap> mrpouet: it is even more important that coding
-[21:59:42] <tampakrap> just recall what hapened when we masked kdeprefix
-[21:59:46] <mrpouet> I meant it's a bit....excessive
-[21:59:51] <PSYCHO___> mrpouet: its seriously important for users
-[21:59:56] <PSYCHO___> mrpouet: and we present our work to users
-[22:00:00] <mrpouet> tampakrap: I said that I was agree :]
-[22:00:02] <PSYCHO___> mrpouet: we need to be 100% covered there
-[22:00:22] <mrpouet> (document is important) but the consequence is.... excessive imho
-[22:00:41] <PSYCHO___> mrpouet: now noone cared, so i will be really evil until they start to care
-[22:00:52] <wired> well
-[22:00:55] <wired> i must say
-[22:01:04] <wired> docs have always been one huge strength of gentoo
-[22:01:08] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
-[22:01:13] <wired> and lately they're degrading fast
-[22:01:15] <mrpouet> PSYCHO___: sadistic :P
-[22:01:17] <wired> so I like this initiative
-[22:01:29] <wired> lets bring them back :)
-[22:01:42] <Pesa> hello :)
-[22:01:49] <PSYCHO___> ok so lets loko onto the next toppic
-[22:01:51] <wired> second late to the party
-[22:01:57] <wired> :D
-[22:02:01] <PSYCHO___> as i can see some people had really the problem with TZ
-[22:02:02] <PSYCHO___> :D
-[22:02:05] <spatz> Pesa: hi :)
-[22:02:12] <PSYCHO___> Pesa: or you know that you are 1h late? :P
-[22:02:17] <Pesa> uhm...
-[22:02:20] <Pesa> 1h :O
-[22:02:25] <wired> he does not
-[22:02:27] <wired> date -u
-[22:02:29] <wired> Pesa: ^^
-[22:02:32] <Pesa> damn! timezone :s
-[22:02:43] <ABCD> Pesa: I had the same issue :D
-[22:02:43] <Pesa> sorry 
-[22:02:50] <PSYCHO___> ok so lets get to the topic :]
-[22:02:56] <wired> you'll read logs, lets go!
-[22:03:09] <PSYCHO___> who is willing to track upstream patches, and apply them where required
-[22:03:10] <Pesa> yep
-[22:03:30] <mrpouet> wired: or do like me, have a linux clock setting up to UTC :D
-[22:03:43] <PSYCHO___> this requires also requesting backports from TRUNK to branch on upstream
-[22:04:50] <mrpouet> PSYCHO___: you meant a unique guy ? other devs can't import patches from upstream ?
-[22:05:03] <mrpouet> (it's ambigous)
-[22:05:11] <PSYCHO___> they can, but should coordinate with him
-[22:05:14] <mrpouet> (at least for me with my fuc*$*$$* english)
-[22:05:16] <PSYCHO___> it can be even more people
-[22:05:29] <PSYCHO___> the point is that we would have the patches applied where needed
-[22:05:34] <PSYCHO___> in both overlay/tree
-[22:05:57] <mrpouet> PSYCHO___: mhhh... personally I could be interested
-[22:06:01] <jmbsvicetto> Hello
-[22:06:05] <wired> boss!
-[22:06:06] <jmbsvicetto> sorry for being late
-[22:06:08] <mrpouet> jmbsvicetto: hi
-[22:06:09] <mrpouet> :)
-[22:06:09] <PSYCHO___> currently we mostly wait on upstream to release new version
-[22:06:11] <wired> welcome jmbsvicetto 
-[22:06:14] <PSYCHO___> hello boss
-[22:07:09] <jmbsvicetto> Hi everyone
-[22:07:16] <PSYCHO___> ok, come on guys, he is half gnome, at least one more volunteer ;]
-[22:07:20] <PSYCHO___> its not that hard job :]
-[22:07:30] <tampakrap> i could help but not that much
-[22:07:36] <tampakrap> because i am mostly trunk user
-[22:08:00] <jmbsvicetto> PSYCHO___: what's up?
-[22:08:08] <jmbsvicetto> :(
-[22:08:10] <mrpouet> PSYCHO___: it's not an argument :p
-[22:08:16] <wired> jmbsvicetto: you want log so far?
-[22:08:17] <jmbsvicetto> Am I 1 hour late?? :|
-[22:08:18] <PSYCHO___> i want someone to coordinate patches with upstream :]
-[22:08:20] <mrpouet> I'm half gnome... and ? :D
-[22:08:21] <PSYCHO___> someone dedicated :]
-[22:08:22] <wired> jmbsvicetto: you are :P
-[22:08:49] * jmbsvicetto failed to read UTC :\
-[22:09:05] <jmbsvicetto> wired: yes, please (logs)
-[22:09:30] <wired> jmbsvicetto: ok i'll wgetpaste then hold on
-[22:09:49] <tampakrap> PSYCHO___: reavertm and ABCD would be perfect for this i guess
-[22:09:49] <PSYCHO___> ABCD: how about you? dont want to do this? :]
-[22:10:02] <PSYCHO___> tampakrap: exactly my thinking, but reaver is not around now
-[22:10:47] <PSYCHO___> the silence after i ask someone something :D hilarious
-[22:11:12] <ABCD> PSYCHO___: that would mean I'd actually have to figure out if commits to trunk are relevant/apply on the 4.3 branch...
-[22:11:22] <ABCD> (which means more work :( )
-[22:11:26] <mrpouet> btw, after this topic, I've another one (tiny)
-[22:12:00] <tampakrap> trunk after .70 is 90% incompatible with current branch
-[22:12:19] <mrpouet> (I'm pretty sure you will agree, but I wanted to talk about that during meeting anyway)
-[22:12:28] <wired> jmbsvicetto: http://dpaste.com/122503/
-[22:12:30] <PSYCHO___> ABCD: i mean more watch what bugs they fix, and ask them to patch it for branch too
-[22:13:02] <PSYCHO___> something like "i know you fixed crash X for trunk, but the error is in branch too, so could you fix it too so others dont have to wait for 4 months?"
-[22:13:05] <jmbsvicetto> wired: thanks
-[22:13:28] <PSYCHO___> and second responsibility would be just applying what users add to bugzilla as patches from upstream
-[22:13:39] <PSYCHO___> deciding if it is worth or not and so on
-[22:13:45] <ABCD> PSYCHO___: so long as someone files a Gentoo bug, and mentions the upstream bug; otherwise I'd never find it :)
-[22:13:48] <PSYCHO___> i dont expect that person to review all commits
-[22:13:59] <PSYCHO___> ABCD: thats the idea :]
-[22:14:09] <PSYCHO___> i dont expect you to browse the upstream one ;]
-[22:14:20] <ABCD> in that case, it shouldn't be too difficult
-[22:14:58] <PSYCHO___> i know, i just want someone to do it
-[22:15:07] <PSYCHO___> so i wont meet 20 days open bug with patch from upstream
-[22:15:29] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 4: kde3 removal'
-[22:15:39] <PSYCHO___> ssuominen: around?
-[22:15:50] <PSYCHO___> ok as you might noticed kde3 is going away
-[22:15:56] <tampakrap> next topic, ssuominen is in progress of it :P
-[22:15:57] <PSYCHO___> its quite flawless i can say
-[22:16:04] * tampakrap points at #-commits
-[22:16:09] <PSYCHO___> http://dev.gentoo.org/~scarabeus/kde3almostgone.png
-[22:16:09] <wired> wave your hands while you still can
-[22:16:19] <wired> its going awayyyyyyyyyyyy
-[22:16:19] <PSYCHO___> this is what it did to our bugs
-[22:16:27] <PSYCHO___> so i want to hear one thing only here
-[22:16:34] <PSYCHO___> is something more required on that matter from us?
-[22:17:17] <wired> nothing i can think of
-[22:17:26] <PSYCHO___> me neither
-[22:17:30] <wired> ssuominen is really doing a great job with this
-[22:17:31] <PSYCHO___> thats why i wanted ask others
-[22:17:40] <ABCD> bye-bye bugs :D
-[22:17:57] <PSYCHO___> wontfix closing is fast :P but dont get used to it :D
-[22:18:10] <wired> :D
-[22:18:20] <wired> lets go to RDEPENDs
-[22:18:22] * tampakrap is waiting for kde5 - kde4-removal
-[22:18:41] <wired> tampakrap: go ahead and write kde5 then!
-[22:18:42] <PSYCHO___> jmbsvicetto: boss its your area
-[22:18:52] <PSYCHO___> jmbsvicetto: so elaborate why rdepend use deps are bad
-[22:19:30] *** Joins: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua)
-[22:19:36] <PSYCHO___> okeey, anyone else? :]
-[22:19:41] <wired> :P
-[22:19:51] <wired> i personally like use flags for rdepends
-[22:20:06] <wired> but i'd like to hear why they're bad from those who don't
-[22:20:13] * PSYCHO___ dont care, einfo was always enough for me
-[22:20:17] <PSYCHO___> wired: well it is poluting the ebuild
-[22:20:21] <PSYCHO___> they are not entirely required
-[22:20:27] <wired> its not pollution
-[22:20:31] <PSYCHO___> so einfo with install X for feature Y
-[22:20:42] <wired> its only a few words and its helping you do things pre-emerge
-[22:20:50] <PSYCHO___> wired: if you stabilise package, it is polution, if you have to wait on optional rdepend to be stabilised
-[22:21:07] <wired> in that case
-[22:21:12] <wired> lets work on a per case basis
-[22:21:41] <wired> for example, obvious or important rdepends could go in use flags, others in info
-[22:21:46] <PSYCHO___> that actualy might work
-[22:22:33] <wired> if an rdepend disables/enables half the package's functionality, it should definately have a USE
-[22:22:45] <wired> if its a hidden option in the 3rd menu from the right
-[22:22:53] <wired> it could live without it :P
-[22:22:56] *** Quits: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua) (Remote closed the connection)
-[22:23:35] <wired> but we *must* make sure we have einfo if we don't have USE
-[22:23:36] <wired> make it policy
-[22:23:41] <PSYCHO___> thats sound sane
-[22:24:05] <tampakrap> agreed
-[22:24:12] <tampakrap> add to CODE maybe?
-[22:24:15] <wired> yeah
-[22:24:27] <wired> oh sorry
-[22:24:30] *** Joins: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua)
-[22:24:30] <wired> yeah, *docs* man
-[22:24:40] <PSYCHO___> ok someone can grab it from summary later then
-[22:24:41] <wired> :D
-[22:24:41] <PSYCHO___> :]
-[22:24:41] <jmbsvicetto> sorry, reading backlog
-[22:24:51] <tampakrap> i would kick you now, but we are in meeting
-[22:25:04] <PSYCHO___> jmbsvicetto: not entirely smart thing to do during continuous meeting :D
-[22:25:16] <jmbsvicetto> PSYCHO___: It isn't that rdepend use flags are bad, it's just that there are too many
-[22:25:34] <jmbsvicetto> at least it used to be too many -> quanta was the best/worst(?) example
-[22:25:53] <tampakrap> yes, because we are following upstream
-[22:26:24] <PSYCHO___> jmbsvicetto: well thats why it is per decision basics
-[22:26:33] <PSYCHO___> svn plugin can be controled by svn useflag
-[22:26:34] <jmbsvicetto> wired / PSYCHO___: I'm not sure they cause so many issues when marking it stable
-[22:26:46] <jmbsvicetto> we can always have a use flag masked in a profile
-[22:26:50] <PSYCHO___> jmbsvicetto: I DO, i try to stable such package right now
-[22:27:05] <PSYCHO___> :P
-[22:27:09] <jmbsvicetto> PSYCHO___: I was trying to catch something ;)
-[22:27:16] <wired> i think what i said above is good as a rule of thumb
-[22:27:43] <wired> devs should decide per case depending on the importance of the deps
-[22:27:47] <wired> so we don't end up with 30 RDEPEND USE flags
-[22:27:48] <wired> :p
-[22:27:54] <jmbsvicetto> I don't have a problem with a case-by-case, but then we'll get a bug for each package that we don't provide a use flag :P
-[22:28:18] <tampakrap> wontfix, because that's how we want it
-[22:28:34] <tampakrap> or fix, because we did a second thought
-[22:28:38] * jmbsvicetto puts user cloak: I want use flag X for installing package Z when I install package Y!!!
-[22:28:46] <PSYCHO___> http://www.pastebin.cz/26457
-[22:29:06] <wired> jmbsvicetto: we already have wontfix bugs like that
-[22:29:08] <jmbsvicetto> Ingmar: I'll try to poke you later, but I'm also interested in upstream's work on splitting KDE
-[22:29:11] <PSYCHO___> its up to us, not user decision
-[22:29:16] <jmbsvicetto> yes, I know
-[22:30:28] <PSYCHO___> ok, i guess we covered our last point
-[22:30:34] <PSYCHO___> so lets move to qt issues :]
-[22:30:37] <wired> w8
-[22:30:39] <tampakrap> wait plz
-[22:30:49] <wired> mrpouet has sth to add
-[22:31:04] <PSYCHO___> hm?
-[22:31:11] <wired> or had :P
-[22:31:15] <wired> mrpouet: u here?
-[22:31:21] <tampakrap> i have to say something too
-[22:31:36] <PSYCHO___> tampakrap: then speak :]
-[22:31:38] <wired> go ahead
-[22:31:42] <tampakrap> i'll start since mrpouet is somewhere else :P
-[22:32:13] <tampakrap> recently i fixed a bunch of live ebuilds, reported issues, patches etc
-[22:33:07] <tampakrap> since i recompile kde and qt live packages very frequently, i would like your permission to create a doc which will track live ebuilds' upstream and downstream bugs, etc
-[22:33:15] <tampakrap> which are broken and need love etc
-[22:33:43] <tampakrap> if you think that a doc is not appropriate i could do a page in gentoo-wiki for example
-[22:34:11] <PSYCHO___> tampakrap: go ahead, try to motivate some non-team people to help you
-[22:34:18] <PSYCHO___> tampakrap: so you can recruit your minions ;P
-[22:34:30] <wired> on that note, we could create a script
-[22:34:31] <tampakrap> no way, you are the ht lead
-[22:34:34] <wired> that picks up your daily rebuild
-[22:34:44] <wired> and generates a webpage of what failed and what worked
-[22:34:45] <wired> :p
-[22:34:52] <PSYCHO___> you mean something like dirk-dashboard?
-[22:34:52] <ayoy> ;]
-[22:34:57] <ayoy> contonuous integration
-[22:34:57] <PSYCHO___> or something like bump-tool?
-[22:35:07] <PSYCHO___> http://dev.gentoo.org/~scarabeus/vystup.html
-[22:35:08] <spatz> something like buildbot?
-[22:35:27] <tampakrap> a script that takes logs and uploads them somewhere
-[22:35:29] <wired> something like that PSYCHO___ 
-[22:35:45] <wired> like the thing gnomies have
-[22:35:49] <PSYCHO___> tampakrap: well do it if you want it
-[22:35:55] <wired> i can create a custom script if we don't have something ready
-[22:36:03] <tampakrap> we don't
-[22:36:05] <tampakrap> ok ok
-[22:36:09] <tampakrap> covered
-[22:36:11] <wired> just give me the logs :P
-[22:36:28] <PSYCHO___> ok so lets moove to the qt since mrpouet is not around
-[22:36:36] <tampakrap> wait a minute
-[22:36:47] <tampakrap> it seems not covered
-[22:37:06] <tampakrap> wired: the script would be usuable if it could automatically take the build.logs from the failed packages
-[22:37:11] <tampakrap> and upload them somewhere
-[22:37:33] <PSYCHO___> tampakrap: its not entirely meeting material, and we have meeting already for 1h30minutes... just discuss this with wired on -kde afterwards :]
-[22:37:33] <wired> yeah
-[22:37:37] <tampakrap> and we can add a comment next to each one of them, like upstream bug or whatever
-[22:37:39] <wired> we'll talk about it off list
-[22:37:43] <wired> off meeting*
-[22:37:43] <tampakrap> ok ok
-[22:37:51] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 1: qt mono package'
-[22:37:58] <ayoy> !herd qt
-[22:38:00] <Willikins> (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin
-[22:38:14] <tampakrap> surprisingly i am here
-[22:38:21] <wired> one of our biggest issues
-[22:38:26] <wired> with the split ebuilds
-[22:38:29] <wired> the USE flag madness
-[22:38:31] <wired> is now solved
-[22:38:38] <wired> because anything < 4.5.3 is off the tree
-[22:38:41] <ayoy> \ö/
-[22:38:41] <tampakrap> lol, when?
-[22:38:54] <yngwin> i still see people struggling with it
-[22:39:03] <ayoy> because they are updating to 4.5.3, not?
-[22:39:11] <yngwin> yes
-[22:39:12] <ABCD> yay
-[22:39:19] <ayoy> once they update, we're done with this shit
-[22:39:29] <wired> so its solved from our side
-[22:39:50] <wired> the only thing left is the Qt update blocker madness
-[22:40:01] <wired> but i think people are beginning to understand that b blocks are autosolvable
-[22:40:05] <yngwin> but we'll still have to support latecomers for a long time
-[22:40:28] <spatz> we'll have to support latecomers no matter what
-[22:40:39] <wired> yngwin: agreed, but that doesn't really change anything if we merge splits into a monolithic
-[22:40:45] <wired> s/anything//
-[22:41:05] <yngwin> it would, but anyway
-[22:41:28] <wired> i mean, they'd still have to do some migration work
-[22:41:38] <ayoy> like update with no blockers
-[22:41:40] <ayoy> :)
-[22:42:06] <yngwin> yes, but that would be clearer than the current mess with blockers and useflags - portage is just not giving very clear feedback to users
-[22:42:20] <wired> i agree with the feedback thing
-[22:42:45] <wired> but with the useflags issue _mostly_ gone, do you feel the blockers are good enough a reason to change things?
-[22:42:52] <ABCD> well, we could say that that's a portage bug ;)
-[22:43:09] <yngwin> it is mostly a portage problem yes
-[22:43:16] <spatz> xorg packages, for example, don't have blockers for maximum versions, only minimal, so users see less blockers
-[22:43:18] <PSYCHO___> well portage should shut up about autosolved blocks
-[22:43:20] <yngwin> but we'll have to work with portage
-[22:43:29] <PSYCHO___> i dont understand why it writes them out
-[22:43:36] <spatz> qt has both maximum and minimum version blockers and that's creating weird issues
-[22:43:39] <PSYCHO___> most users get only confused
-[22:43:43] <wired> imo the right way to do this is fix portage
-[22:43:58] <wired> i really want to get into portage development but i just can't these days
-[22:44:01] *** Joins: tampakrap_ (n=tampakra@ppp-94-66-145-248.home.otenet.gr)
-[22:44:01] <Sput> why do we need maximum version blockers?
-[22:44:04] <wired> i am considering doing so in the future
-[22:44:16] <Sput> downgrading Qt isn't really supported anyway
-[22:44:31] <wired> Sput: you can't mix Qt versions
-[22:44:35] <spatz> Sput: to make sure user has exactly the same version of all packages
-[22:44:35] <ayoy> Sput: mixing versions anyhow is neither
-[22:44:36] <wired> period :P
-[22:44:46] <Pesa> wired: i'd like to too ;)
-[22:44:51] <Sput> yes, but the common case is upgrade, yes?
-[22:45:01] <spatz> again, see xorg use case
-[22:45:01] <yngwin> to my mind this shows why we need monolithic
-[22:45:06] <PSYCHO___> something like MDEPEND
-[22:45:07] <spatz> downgrading doesn't usually work either
-[22:45:08] <Sput> so minimum blockers would be enough to force all qt packages be updated if one is updated
-[22:45:12] <PSYCHO___> if package is around then require this version
-[22:45:16] <PSYCHO___> otherwise do not care
-[22:45:18] <PSYCHO___> so called
-[22:45:22] <PSYCHO___> MAGIC DEPENDENCY
-[22:45:29] <ayoy> :)
-[22:45:38] <spatz> with only minimum blocks users won't get blockers
-[22:45:49] <PSYCHO___> come on its exactly what you want, that might be actualy easy to do with current code
-[22:45:55] <PSYCHO___> it will just need new eapi :/
-[22:46:24] <wired> PSYCHO___: current code can't do it, i've tried to express it with complex bash but it still shells out blockers
-[22:46:27] <wired> we need new depend type
-[22:46:30] <yngwin> anyway, we said we'd discuss it on ML, which as far as i can see has not happened
-[22:46:43] <wired> it did not
-[22:46:44] <PSYCHO___> wired: i said so, new depend type MDEPEND
-[22:46:49] <wired> PSYCHO___++
-[22:46:57] <yngwin> who wants to start the ML discussion?
-[22:46:58] <PSYCHO___> and it is easy to adjust
-[22:47:00] <PSYCHO___> the portage code
-[22:47:04] <PSYCHO___> about this
-[22:47:13] <wired> yngwin: I can
-[22:47:19] <yngwin> great
-[22:47:22] <yngwin> next topic
-[22:47:35] <wired> status of qt-tng
-[22:47:42] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 2: Status of new qt-tng.eclass'
-[22:47:56] <ayoy> I've been reviewing it for last 1,5 hours
-[22:47:59] <yngwin> hwoarang said he couldnt continue with this because of circumstances
-[22:48:10] <yngwin> i think it's ready
-[22:48:12] <wired> yes so are we happy with it enough to post it in -dev?
-[22:48:26] <ayoy> provided that we remove prepare_translations?
-[22:48:45] <ayoy> this one seems not so handy
-[22:48:52] <ayoy> tries to address a common case
-[22:48:58] <yngwin> let's prepare the eclass for qt@ before sending it off to -dev
-[22:48:59] <ayoy> but the common case doesn't really exist
-[22:49:06] <Pesa> except there isn't a common case :)
-[22:49:14] <wired> so lets remove that
-[22:49:21] <ayoy> I will
-[22:49:23] <yngwin> yes, we already said that
-[22:49:38] <Pesa> ok
-[22:49:47] <yngwin> ok, ayoy, can you finalize the eclass and send it to qt@ ?
-[22:49:47] <ayoy> hey, btw
-[22:49:48] *** Quits: tampakrap (n=tuxicity@gentoo/developer/tampakrap) (Read error: 54 (Connection reset by peer))
-[22:49:56] <ayoy> yngwin: yes I can
-[22:50:15] <wired> great
-[22:50:18] <yngwin> then we can all have a look and comment if needed, then send it to -dev
-[22:50:21] <ayoy> are we all happy with the eclass name?
-[22:50:26] * ayoy is not
-[22:50:29] <yngwin> not really
-[22:50:36] <wired> ayoy: i talked with picard the other day, he said he liked it
-[22:50:36] <PSYCHO___> you already voted on it, but didnt decide anything
-[22:50:39] <Pesa> i am not but i don't really care
-[22:50:41] <ayoy> qt4-edge kicks testicals very hard, I like it
-[22:50:51] <wired> not -edge
-[22:50:54] <wired> we need that for overlay
-[22:51:03] <yngwin> qt4v2
-[22:51:03] <wired> else we'll have to start overriding and crap
-[22:51:11] <ayoy> wired: you mean that qt4-edge will stay in overlay?
-[22:51:17] <yngwin> we need eclass versioning dammit
-[22:51:26] <Pesa> yngwin++
-[22:51:31] <wired> ayoy: yes, we need to keep developing there, don't we? :P
-[22:51:37] <ayoy> we do
-[22:51:43] <wired> yngwin: indeed
-[22:51:44] <yngwin> indeed, wired is right
-[22:51:53] <spatz> I propose qt4-next :/
-[22:51:58] <PSYCHO___> qt42morow
-[22:51:58] <ayoy> better :)
-[22:52:03] <wired> qt4-v2
-[22:52:08] <PSYCHO___> read it ^
-[22:52:10] <ayoy> qt4evar
-[22:52:11] <PSYCHO___> in english
-[22:52:16] <wired> PSYCHO___: we did :P
-[22:52:33] <PSYCHO___> :]
-[22:52:41] <PSYCHO___> qt4-blesmrt
-[22:52:42] <PSYCHO___> :]
-[22:52:43] <wired> qt4-r2
-[22:52:45] <spatz> ok, let's not waste time on bikesheds
-[22:52:50] <wired> ^^ in the gentoo spirit
-[22:52:54] <spatz> lol
-[22:52:56] <ayoy> :)
-[22:53:09] <yngwin> i like that, wired
-[22:53:10] <spatz> this meeting is already taking 2 hours :/
-[22:53:16] <ayoy> let's move on
-[22:53:17] * spatz likes it too
-[22:53:23] <wired> :D
-[22:53:25] * ayoy too
-[22:53:25] <PSYCHO___> so name unchanged
-[22:53:27] <PSYCHO___> ?
-[22:53:28] <yngwin> ok, qt4-r2.eclass
-[22:53:30] <ayoy> no, changed
-[22:53:41] <yngwin> next topic
-[22:53:46] <wired> w00t, we got rid of startrek
-[22:53:47] <wired> ok 3.
-[22:53:50] <wired> #gentoo-qt
-[22:53:52] <wired> do we want it?
-[22:53:58] <tampakrap_> plz no
-[22:54:01] <spatz> no
-[22:54:02] <yngwin> i dont see the need
-[22:54:02] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 3: #gentoo-qt'
-[22:54:05] <ayoy> I'd say we rather need a separate meeting
-[22:54:09] <ayoy> than a separate channel
-[22:54:11] <wired> its already registered and when i was bored I added permissions
-[22:54:18] <wired> so if you ever feel like it
-[22:54:18] <wired> :)
-[22:54:24] <tampakrap_> ok, but plz no
-[22:54:26] <tampakrap_> :)
-[22:54:47] <wired> i think -kde is fine as well, but its there if we need it
-[22:54:50] <spatz> ok, so we all agree on 'no'
-[22:54:57] <tampakrap_> neeeext
-[22:55:01] <yngwin> let's keep it
-[22:55:01] <spatz> ok, we have a backup for a nuclear war or sth
-[22:55:06] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 4: einfo mess'
-[22:55:12] <wired> 4.
-[22:55:13] <yngwin> but we'll continue to use -kde for the time being
-[22:55:18] <spatz> it was already cleared out yesterday
-[22:55:23] <spatz> by wired
-[22:55:23] <wired> btw DONT RUSH
-[22:55:32] <wired> :D
-[22:55:37] <spatz> the messages only show for qt-core now
-[22:55:37] <ayoy> qt-core only
-[22:55:37] <ayoy> ?
-[22:55:38] <spatz> so I think it's better
-[22:55:41] <ayoy> awesome
-[22:55:41] <tampakrap_> tommy[d] complaint many times about this warning overload
-[22:55:48] <wired> tampakrap_: i already fixed it
-[22:55:51] <wired> confined it to qt-core
-[22:55:54] <yngwin> yes, change was committed yesterday
-[22:55:56] <ayoy> ok, I love it
-[22:56:02] <tampakrap_> cool
-[22:56:05] <spatz> we can (and should) shorten the text, but it's much less spam now
-[22:56:10] <wired> yeah
-[22:56:10] <yngwin> if any more cutting is needed, let us know
-[22:56:15] <wired> like 11 times less
-[22:56:18] <spatz> lol
-[22:56:19] <ayoy> :)
-[22:56:21] <spatz> great, so next
-[22:56:24] <wired> 5.
-[22:56:25] <wired> gitorious
-[22:56:30] <PSYCHO___> wait
-[22:56:32] <yngwin> we could look at the text again
-[22:56:38] <yngwin> see if it can be shortened
-[22:56:40] <spatz> only downside is no commit bot coolness
-[22:57:02] <wired> yngwin: i can do it
-[22:57:09] <yngwin> i also like the suggestion to put it in out docs and refer in einfo to our docs page
-[22:57:34] <yngwin> wired: ok, do it and let us know what you come up with
-[22:57:34] <wired> thats not bad either
-[22:57:38] <wired> k
-[22:57:41] <wired> will mail qt@
-[22:57:47] <tampakrap_> i'll do the docs btw
-[22:57:48] <spatz> oooh I like that
-[22:57:53] <yngwin> alright
-[22:57:53] <ayoy> ok then
-[22:57:55] <spatz> no one thought otherwise :)
-[22:57:57] <ayoy> why not github?
-[22:58:04] <yngwin> next topic
-[22:58:11] <wired> tampakrap_: i'll do the Qt docs
-[22:58:13] <spatz> many ppl don't have github accounts but want overlay access
-[22:58:17] <wired> keep it split so we actually do something
-[22:58:24] <ayoy> they can create
-[22:58:25] <ayoy> or die
-[22:58:37] <spatz> and gitorious is the new black, or something
-[22:58:45] <ayoy> oh
-[22:58:48] * ayoy checks
-[22:58:53] <yngwin> i like gitorious because you an have more people administer the repo
-[22:59:03] <yngwin> can*
-[22:59:06] <spatz> it's better in most ways, except cia.vc integration
-[22:59:12] <spatz> I like the bot we have in #-kde
-[22:59:13] <wired> the only real disadvantage is cia
-[22:59:17] <wired> do we care enough?
-[22:59:17] <yngwin> i am now the bus factor for github
-[22:59:18] <ayoy> yngwin: good point
-[22:59:38] <tampakrap_> no
-[22:59:40] <wired> i mean kde doesn't have cia either, big deal
-[22:59:41] <ayoy> I do only a bit 
-[22:59:58] <yngwin> not really, cia bot is nice, but there are other ways
-[23:00:04] <wired> i like the cia wow factor as well, but if gitorious is better/more reliable/more popular
-[23:00:09] <ayoy> like capslock
-[23:00:11] <tampakrap_> my commit number got too high because of qting-edge, i almost lost my gentoo/slacker cloak
-[23:00:13] <wired> lets go there and switch the hooks to keep github in sync
-[23:00:25] <ayoy> hey hey
-[23:00:26] <ayoy> btw
-[23:00:26] <ayoy> !
-[23:00:36] <ayoy> if we switch to gitorious
-[23:00:41] <ayoy> we still have github as a backup, no?
-[23:00:47] <ayoy> we still have the bot
-[23:00:50] <ayoy> period.
-[23:00:54] <wired> right
-[23:00:56] <tampakrap_> touche
-[23:00:58] <wired> ayoy++
-[23:00:58] <Pesa> heh right
-[23:01:00] <spatz> new ppl who only have gitorious access won't be able to push to github
-[23:01:02] <ayoy> lol
-[23:01:02] <ayoy> :)
-[23:01:10] <wired> spatz: no issues, we'll push for them
-[23:01:10] <spatz> so not really
-[23:01:13] <PSYCHO___> so vote for it
-[23:01:22] <yngwin> yes, vote
-[23:01:27] <PSYCHO___> as in topic it is named as voting for gitorious as main repo
-[23:01:28] <tampakrap_> gitorious
-[23:01:30] <wired> +1 gitorious
-[23:01:40] <spatz> ok then, +1 gitorious
-[23:01:46] <yngwin> gitorious
-[23:01:46] <ayoy> gitorious + github as backup
-[23:01:54] * spatz switches url order in .git/config
-[23:02:17] <yngwin> ABCD?
-[23:02:29] <ABCD> abstain
-[23:02:33] <yngwin> ok
-[23:02:37] <tampakrap_> btw can we do the same trick with kde-testing to get cia bot there as well?
-[23:02:53] <Pesa> lol
-[23:03:00] <wired> only if people actually push to gitorious as well
-[23:03:06] <wired> better poke PSYCHO___ to fix it
-[23:03:07] <wired> :p
-[23:03:08] <spatz> you mean github
-[23:03:12] <wired> yeah
-[23:03:13] <wired> :D
-[23:03:22] <spatz> if git.o.g.o has cia integration you don't have to
-[23:03:23] <PSYCHO___> ok last topic
-[23:03:25] <wired> s/gitorious/github/
-[23:03:26] <yngwin> so we need to make an announcement about that, to push to gitorious as main repo, and change layman url
-[23:04:05] <yngwin> any volunteers?
-[23:04:12] <wired> announcement in like -dev? qt2?
-[23:04:13] <wired> qt@?
-[23:04:21] <yngwin> qt@
-[23:04:27] <wired> i'll do it
-[23:04:30] <ayoy> no big deal :)
-[23:05:08] <wired> im Qt PR
-[23:05:09] <wired> :p
-[23:05:09] <PSYCHO___> last topic: removal of changelogs from overlay
-[23:05:15] <wired> that one was mine
-[23:05:17] <yngwin> also proj page
-[23:05:39] <wired> lets remove them, they keep breaking my nerves, git logs are enough!
-[23:05:48] <yngwin> NO
-[23:05:48] <spatz> wired++
-[23:05:58] <wired> seriously
-[23:06:02] <ayoy> why not?
-[23:06:05] <wired> i can't stand them, overlays shouldnt have changelogs
-[23:06:10] <wired> duplicate info
-[23:06:15] <yngwin> qting-edge is also a training area for new recruits / devs-to-be
-[23:06:35] <wired> yngwin: most overlays are
-[23:06:37] <yngwin> it's good practice to get used to using echangelog
-[23:06:43] <ayoy> yngwin++
-[23:06:44] <wired> yngwin: repoman will scream anyway
-[23:06:53] <PSYCHO___> repoman wont scream
-[23:06:57] <ayoy> it doesn't
-[23:06:58] <spatz> I think that's the least of the recruit's problems
-[23:07:01] <yngwin> yes, that is why my policy is to use echangelog in all overlays
-[23:07:02] <wired> spatz++
-[23:07:07] <spatz> it doesn't scream, it warns
-[23:07:10] *** Quits: nirbheek (n=nirbheek@gentoo/developer/nirbheek) ("Gone.")
-[23:07:10] <PSYCHO___> repoman ignores changelogs for distributed scms
-[23:07:14] <PSYCHO___> spatz: ^
-[23:07:17] <wired> PSYCHO___: i meant in cvs
-[23:07:20] <spatz> recruits should be taught to read repoman's warnings :)
-[23:07:22] <PSYCHO___> spatz: i wrote the code to portage, so i know about its behaviour
-[23:07:32] <spatz> I mean when they commit to the tree
-[23:07:36] <yngwin> as long as portage is using cvs and echangelog, i want us to use it in the overlay
-[23:07:47] <wired> i really don't like it, i forget it because this is the only overlay we use changelogs
-[23:07:47] <wired> from the ones i use
-[23:07:51] <yngwin> echangelog that is, not cs :p
-[23:07:55] <yngwin> cvs*
-[23:07:59] <spatz> lol
-[23:08:15] <spatz> can we vote or do you veto?
-[23:08:19] <tampakrap_> for the record i agree with wired
-[23:08:21] <PSYCHO___> :D
-[23:08:27] <wired> i'd like a vote for this
-[23:08:28] <wired> :)
-[23:08:40] <yngwin> also, for users who checkout the overlay, they may expect changelogs
-[23:08:45] <yngwin> i would, anyway
-[23:08:56] <spatz> no overlay has changelogs, so why would they?
-[23:08:57] *** Quits: krakonos (n=krakonos@kangaroo.kolej.mff.cuni.cz) (Client Quit)
-[23:09:07] <ayoy> I'm for changelogs in the overlay
-[23:09:09] <wired> yngwin: well users are educated to git log or visit gitweb these days, thanks to kde-testing :P
-[23:09:14] <yngwin> because portage does
-[23:09:47] <wired> besides, git log is blazingly fast, its not like you have to cvs log :p
-[23:10:02] <ayoy> echangelog in git is also fast
-[23:10:06] <ayoy> ;]
-[23:10:07] <yngwin> most users dont know how to handle git
-[23:10:20] <PSYCHO___> plz vote and end, i want to go to shower
-[23:10:23] <wired> ayoy: sure, but when you don't echangelog in most overlays
-[23:10:24] <spatz> they can use the gitorious web-ui
-[23:10:27] <wired> you tend to forget
-[23:10:37] <ayoy> wired: then add echangelogs to other overlays
-[23:10:39] <yngwin> PSYCHO___: s/vote/veto/
-[23:10:42] <ayoy> :)
-[23:10:56] <wired> meh
-[23:11:02] <PSYCHO___> yngwin: me dont care you are no longer subproject and you are lead, so it is up to you
-[23:11:17] <PSYCHO___> yngwin: 2 months ago i could veto your veto but now it is entirely up to you :D
-[23:11:22] <wired> lol
-[23:11:24] <ayoy> lol :D
-[23:11:35] <yngwin> i want better arguments than "I'm too lazy"
-[23:11:36] <tampakrap_> yngwin: we hate you
-[23:11:44] <wired> yngwin: its not im lazy
-[23:11:48] <yngwin> tampakrap_: i'm honoured
-[23:11:53] <tampakrap_> it's that i am lazy
-[23:11:54] <PSYCHO___> yngwin: fucked up 3way merge strategy
-[23:11:58] <wired> its dup info, no real advantages :)
-[23:12:03] <wired> anyway
-[23:12:12] <PSYCHO___> we dropped it because it breaks merges a lot
-[23:12:17] <spatz> it was invented to overcome VCS shortcomings we no longer have
-[23:12:27] <ayoy> who merges anything in qting-edge?
-[23:12:29] <yngwin> we still have in portage
-[23:12:34] <ayoy> I've seen it once maybe
-[23:12:39] <wired> yngwin: portage is cvs, we need it there
-[23:12:45] <tampakrap_> yes, better spend the echangelog time to help portage to move to git i'd say :P
-[23:12:45] <spatz> because it still has to deal with those shortcomings - we don't
-[23:13:09] <spatz> when the tree moves to git the changelogs would probably be thrown out the window
-[23:13:11] <yngwin> wired: yes, and i want the overlay to be similar
-[23:13:25] <ayoy> then we will remove them as well
-[23:13:27] <ayoy> ofc....
-[23:13:29] * PSYCHO___ throws the orange duck from one hand to another and looks on the clock
-[23:13:32] <tampakrap_> still, cvs commit progress is *very* different from git commit process
-[23:13:38] <spatz> PSYCHO___: it's yellow!
-[23:13:46] <PSYCHO___> not this one
-[23:13:49] <wired> yngwin: if recruits can't handle that difference between qting-edge and cvs, then they shouldn't be devs, really :P
-[23:13:51] <ayoy> it's Czech duck
-[23:14:10] <yngwin> hmm, there is something to that
-[23:14:13] <spatz> so it has weird dots and lines all over and above it?
-[23:14:58] <tampakrap_> ok i have to go, don't care that much about this subject :P
-[23:15:01] <spatz> ok, let's give yngwin time to think about this and wrap this party up
-[23:15:09] <PSYCHO___> yngwin: http://dev.gentoo.org/~scarabeus/0911-meeting_summary.txt fix the FIXME parts, me blobs to shower
-[23:15:10] <yngwin> yes, ok
-[23:15:10] <wired> alright
-[23:15:15] <wired> yngwin: its up to you, next meeting
-[23:15:17] <ayoy> let's continue this topic on ML! :D
-[23:15:19] <ayoy> yay!
-[23:15:31] <wired> wait!
-[23:15:35] <wired> you all FREEZE!
-[23:15:40] <tampakrap_> wut?
-[23:15:45] <yngwin> i'll think about it, and we can discuss it again later, ok?
-[23:15:48] <wired> lets discuss our project page a bit
-[23:15:50] <wired> yngwin: OK
-[23:15:50] <spatz> don't forget do update your qting-edge/.git/config to new pushurls :D
-[23:15:52] * PSYCHO___ does the squeek sound with his duck
-[23:16:05] <ayoy> spatz: send a mail to qt@ about it
-[23:16:07] <yngwin> can somebody shut up that PSYCHO?
-[23:16:10] <wired> lol
-[23:16:14] <PSYCHO___> he said freeze
-[23:16:29] <yngwin> if you need to go, you can go
-[23:16:44] <wired> i wrote up a first version, but I'd like feedback from all of you
-[23:16:49] <wired> stuff that should be there
-[23:16:51] <wired> stuff that should go
-[23:17:06] <spatz> we can continue discussing this after the meeting, we don't need to hold everybody up
-[23:17:11] <yngwin> i do want to ask qt devs if thet would prefer a separate meeting, as these combined meetings take long
-[23:17:19] <ayoy> ++
-[23:17:19] <tampakrap_> no
-[23:17:22] <ayoy> YES
-[23:17:34] <wired> if
-[23:17:38] <wired> we keep it to 2-3 hours combined
-[23:17:40] <wired> im fine
-[23:17:44] <tampakrap_> issues concern both teams usually
-[23:17:45] <ayoy> a pity is that half of the team will have just 2 meetings
-[23:17:47] <ayoy> kde and qt one
-[23:18:06] <wired> tampakrap++ 
-[23:18:28] <yngwin> i'll write a mail to kde@ and qt@ and we can discuss it then
-[23:18:38] <tampakrap_> or just desktop
-[23:18:40] <ayoy> if we started at 18 UTC or started with Qt stuff I'd be fine
-[23:18:42] <mrpouet> btw, okay to import my patch in phonon ? :]
-[23:18:43] <tampakrap_> desktop mailing list
-[23:18:54] <wired> mrpouet: good morning!
-[23:19:11] <yngwin> i'm not sure everyone is on desktop ml
-[23:19:11] *** Quits: ayoy (n=ayoy@gentoo/developer/ayoy) (Remote closed the connection)
-[23:19:19] <tampakrap_> should be
-[23:19:19] <mrpouet> wired: did you smoke something ? 
-[23:19:24] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi)
-[23:19:30] <wired> mrpouet: lol no i don't smoke ;) 
-[23:19:45] <mrpouet> :p
-[23:19:48] <tampakrap_> have to go bye
-[23:19:50] <ayoy> :/
-[23:19:52] <ayoy> bai
-[23:19:57] <yngwin> bye tampakrap_
-[23:20:00] <wired> cya
-[23:20:04] *** Quits: tampakrap_ (n=tampakra@gentoo/developer/tampakrap) (Remote closed the connection)
-[23:20:07] <mrpouet> wired: what your sentence has to do with my question ? :D
-[23:20:07] <yngwin> we're wrapping up anyway
-[23:20:31] <yngwin> wired: good job on the project page, I'm sure there will be improvements/additions over time
-[23:20:33] <wired> mrpouet: i asked you to talk about your issue a while back but you didn't respond :P
-[23:20:57] * mrpouet has a girl-friend :(
-[23:21:01] <wired> yngwin: indeed. thanks
-[23:21:11] <mrpouet> a girl friend is boring you know.. :D
-[23:21:17] <wired> mrpouet: so do I, but now its sacred... errr meeting time!
-[23:21:28] <ayoy> lol
-[23:21:43] <mrpouet> wired: aaarfff I know !! :(
-[23:22:28] <wired> i think we can wrap this up now
-[23:22:28] <wired> :p
-[23:22:38] <yngwin> ok, last call
-[23:22:40] <wired> mrpouet: tell em about your patch
-[23:22:45] <wired> before they all leave
-[23:22:45] <wired> :p
-[23:22:51] * mrpouet setups a sighandler for SIGGIRL-FRIEND
-[23:23:02] <ayoy> ...
-[23:23:09] <mrpouet> ohhh better
-[23:23:15] <mrpouet> ignore signal :D
-[23:23:23] <mrpouet> ==> [ ] 
-[23:23:25] <mrpouet> ^^
-[23:23:27] <yngwin> mrpouet: you have 2 minutes
-[23:23:58] <wired> 30s gone
-[23:24:07] <mrpouet> okay so, I wrote a patch in order to add a support for external subtitles (files)
-[23:24:07] <ayoy> lalala
-[23:24:39] <mrpouet> it works just fine, sandsmark approved it (on upstream)
-[23:24:56] <mrpouet> it would be nice then to patch kaffeine&dragon
-[23:25:10] <mrpouet> but before we need to import my patch in phonon
-[23:25:24] <mrpouet> see https://bugs.kde.org/show_bug.cgi?id=213710
-[23:25:31] <yngwin> m-s/phonon or qt-phonon or both?
-[23:25:33] <mrpouet> for technical details
-[23:25:40] <mrpouet> yngwin: m-s/phonon
-[23:25:46] <yngwin> ok
-[23:26:35] <mrpouet> currently we can :  auto-detect patch (recursively in the media directory), load a patch manually, setting up the subtitle encoding
-[23:26:47] <mrpouet> rrraaahhh !!!! fucking shit !!!
-[23:26:57] <mrpouet> auto-detect subs *
-[23:27:03] <wired> lol
-[23:27:06] <mrpouet> s/patch/subs
-[23:27:08] <mrpouet> o_O
-[23:27:15] * mrpouet stabs himself
-[23:27:39] <wired> you're putting quite a show 
-[23:27:47] <wired> :D
-[23:27:50] <mrpouet> :D
-[23:27:51] <yngwin> looks to me the patch has merit, but i'm not kde herd, and i think PSYCHO___ has left 
-[23:28:02] <wired> the patch work
-[23:28:02] <wired> s
-[23:28:08] <wired> pretty well
-[23:28:12] <mrpouet> :)
-[23:28:12] * wired tested it
-[23:28:30] <yngwin> so i suggest you open a bug and poke kde team
-[23:29:34] <mrpouet> there is already a bug :)
-[23:29:36] <yngwin> ok, meeting closed
-[23:29:38] <yngwin> -------------------------------------