[21:14:55] roll call [21:15:02] 1 [21:15:05] 2 [21:15:07] 3 [21:15:18] we lost abcd [21:15:28] 4 [21:15:34] and i am number five [21:15:55] i would like to have a small talk about amarok in the end if jmbsvicetto manages to find us [21:15:59] either way: [21:16:02] not even a quorum (for most definitions of "quorum") [21:16:08] 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] here's the agenda [21:16:23] 1) KDE-4.5 status and plans to put it in Portage [21:16:29] reavertm: you can start [21:16:39] ok, here it is: [21:17:04] there are following issues I'd consider a blockers [21:17:26] (unless we say - screw you users - upstream) [21:17:53] https://bugs.kde.org/show_bug.cgi?id=230247 [21:18:47] hmm here everything works fine _since_ the upgrade to 4.5.0 [21:19:02] 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] but I'm not logging in/out very often [21:19:38] one blocker - kwin FBO bug has been fixed (commit reverted as I requested) [21:19:56] remaining ugly bugs: multiple plasma glitches in system tray [21:20:20] plasma glitches were highly reduced in 4.5.1 [21:20:31] not seen for a while [21:20:37] https://bugs.kde.org/show_bug.cgi?id=246931 [21:20:45] 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] no, they are still there [21:21:02] tampakrap: and spam out bugzilla for no reason? [21:21:20] ah that yes that is still there... I got used to that bug... [21:21:27] https://bugs.kde.org/show_bug.cgi?id=247144 - another plasma glitch (folderview) [21:21:39] and most important - memory leaks in plasma-desktop [21:21:49] (minor leaks, but they are there) [21:22:19] dolphin tooltips issues as well as nepomuk related crashes seen to be gone at least [21:22:49] 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] oh, and one bug present in 4.4 alteady - https://bugs.kde.org/show_bug.cgi?id=247204 [21:23:07] i'm getting enough spam on IRC already, and i think it is usuable enough [21:23:21] that's my opiniion, but it is your call mostly [21:23:24] 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] 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] seconded (I personally can work with it fine) [21:23:53] unless we clearly communicate - "we know it's broken - we reported bugs and they keep being ignored" [21:24:17] reavertm: give me a list of the bugs, i can put them on the meeting summary [21:24:18] 4.4 took a lot of time to be stabilized because of regressions too, that's how kde works, apparently [21:24:26] and put the summary on my blog on planet gentoo and kde [21:24:32] I won't wrange any 4.5 bugs in our bugzilla, I want to make it clear :P [21:25:09] spatz: plasma devs utilized 'Broken Development Model" that's why [21:25:31] I'm not pointing fingers, just stating facts :) [21:26:05] ok, we made our points, reavertm: your call [21:26:13] tampakrap: fine, but you'll blog about it :) (with bug links there) [21:26:14] since you fixed a couple of upstream bugs [21:26:23] aah, one more blocker [21:26:32] but on our side - handbooks handling [21:26:38] yes that is true [21:26:51] something is seriously broken there [21:27:01] bug #? [21:27:28] bug 296345 [21:27:29] since 4.5 - docbooks are no longer bundled - so for every +handbook we need to pull docbook stuff like for kdelibs [21:27:30] 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] ah different problem [21:27:52] err, i meant different handbook issue [21:28:40] if there is no bug #, let's open one, fix that first and then put 4.5.1 to tree [21:29:12] 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] ok [21:29:49] anything else on this? [21:30:10] I think this is it wrt kde 4.5 [21:30:29] i have one more thing to say about it [21:30:36] not so relevant [21:31:11] ? [21:31:12] http://bugs.gentoo.org/show_bug.cgi?id=335123 [21:31:43] hmm, works for me... [21:31:45] 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] i can reproduce here and the patches worked on my 4.4.5 laptop [21:32:23] so, any ideas? [21:32:36] does it affect only kde 4.5 + kdepim 4.4? [21:33:00] or it's some general bug? [21:33:01] the patches are meant for 4.4.5 only, haven't tested to 4.5 [21:33:32] 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] I'd prefer them to appear in svn.. [21:34:13] never had this problem here [21:34:51] ah they are not taken from svn [21:34:54] nice point [21:35:04] ok thanks [21:35:10] next issue i guess [21:35:20] 2) KOffice 2.2 status [21:35:35] -*- reavertm shuts up [21:35:46] 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] needs bump to 2.2.2 (I had no time yet but that should not be difficult) [21:36:10] there is a "workaround" [21:36:13] -*- reavertm disagrees, he saw multiple cmake changes and file/dir additions/removals [21:36:24] ok have not checked yet [21:36:58] considering kchart [21:37:10] 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] The libraries do not link if kchart is not built at the same time, so what I did was [21:37:48] do make a dummy ebuild for kchart for the meantime. [21:37:51] KMCOMPILECONLY can be used [21:38:06] well it is done in koffice-libs [21:38:17] but I wanted to keep something named kchart in portage [21:38:26] so later upgrade remains painless [21:38:42] is it standalone app? [21:38:55] so, now koffice-libs also installs kchart, and kchart does, well, nothing [21:39:13] no I think only library [21:39:37] i see [21:39:43] apart from that nobody gave me negative feedback on 2.2.1 yet [21:39:50] i'd appreciate if there were more comments on the bug [21:39:56] http://bugs.gentoo.org/show_bug.cgi?id=322147 [21:39:59] 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] and i could help you with it [21:40:20] i agree with that [21:40:48] fine with me... but the plan is that kchart can be built separately again with 2.3 [21:41:33] is it already done in the live ebuilds? [21:41:47] did not check yet [21:41:51] ok [21:41:51] 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] it can be embedded in any koffice app after all [21:43:07] ok, i'm done with it, dilfridge any further comments? [21:43:15] I'm kind-of-away from tomorrow for a week, so if anything should be done quickly I'm out [21:43:30] 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] indeed [21:44:08] if the kpart is used by other ebuilds too it should be in koffice-libs [21:44:15] else the split makes no sense [21:44:35] we can find that out with the dependencies / linking [21:44:47] since now all apps are for sure compiled after kchart [21:44:52] no, kparts are runtime-only things mostly [21:45:03] ok true [21:45:20] (well, buildtime+runtime, but can be missing at runtime) [21:45:45] i'd say we could give 2.2.1 a try [21:45:59] -*- dilfridge keeps fingers crossed [21:46:11] ok [21:46:24] next? [21:46:27] fine, but I'd suggest full review of them (for instance to check whether all koffice subdirs are packaged in ebuilds) [21:46:54] reavertm: teach me how to do that, please! :) (in two weeks) [21:47:35] ok next [21:47:49] for next issue i would like alexxy but he seems not to be here [21:47:57] simple - take a look at koffice/ and check subdirs one by one against koffice ebuilds (KMEXTRA, KMCOMPILEONLY, KMEXTACTONLY) [21:48:25] ok [21:48:48] 3) KDEPIM beta packages are released [21:48:51] i'll skip it [21:49:00] and add a gentoo-desktop thread instead [21:49:05] we just want whole koffice covered (or some parts *intentionally* skipped) [21:49:14] ok [21:49:27] skip it please [21:49:36] I don't want kdepim betas in overlay :P [21:49:47] (there are live ebuilds already) [21:50:11] sebas stated in his blog that upgrade and downgrade would be easy since configs don't affect each other [21:50:50] either way, we'll discuss it in gentoo-desktop [21:50:55] 4) open floor [21:51:20] about digikam [21:51:41] 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] reavertm: if you want to have a look at it go ahead, but dont send anything upstream yet. [21:52:46] at least 1.4.0 should now build fine [21:53:04] I'll talk with the sci guys about clapack. [21:53:11] I'll wait [21:53:21] i'm also going to unmask knerworkmanager very soon, please test [21:53:34] i'm a bit worried about the versioning though [21:54:47] ah, as of open floor - I encourage people working with live and tagged ebuilds to use kde-misc/kde-overlay-servicemenus [21:55:07] what does it do? [21:56:00] 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] to avoid manual copy paste [21:56:17] w00t [21:56:19] nice [21:56:43] last issue, i'm going to remove a few inactive people from the team [21:57:14] and if there is not anything else, i guess i should close the meeting [21:57:33] thanks [21:58:08] meeting is over