[11:03] *** Kevin_Kofler sets the channel topic to "KDE SIG Meeting - SIGs/KDE/Meetings/2008-06-24 - Init". [11:03] <Kevin_Kofler> KDE SIG Meeting start. Who's present? [11:03] <gbcox> here [11:03] * SMParrish here [11:03] * ltinkl is here [11:04] <Kevin_Kofler> than: ping [11:04] <than> here [11:04] <Kevin_Kofler> As said on #fedora-kde, rdieter is currently busy with work stuff, so I guess that's all of us for now. [11:04] *** Kevin_Kofler sets the channel topic to "KDE SIG Meeting - SIGs/KDE/Meetings/2008-06-24 - Agenda?". [11:05] <Kevin_Kofler> First topic to discuss: Where are the topics? ;-) [11:05] <Kevin_Kofler> If we have nothing to discuss, we can close the meeting right now, but somehow I doubt that's the reason the wiki page is empty. ;-) [11:05] <Kevin_Kofler> So does anybody have anything to discuss? [11:06] <SMParrish> how about how long are we planning on supporting qt3 kde3 apps [11:06] <Kevin_Kofler> SMParrish: For a long time to come. [11:06] <Kevin_Kofler> I think it's too soon to discuss this by at least 3 years, maybe more. [11:06] <SMParrish> lol [11:06] <Kevin_Kofler> There's lots of stuff still using qt3 and kdelibs3. [11:07] <than> SMParrish: qt3/kde3 will be supported in F10 [11:08] <than> in F11 we only provide compat libs [11:08] <Kevin_Kofler> qt3/kde3 libs, you mean, not the desktop, I hope. :-) [11:08] <ltinkl> one item from me: include kdepim 4.1 as an update to F9? (we spoke about it briefly at #fedora-kde) [11:08] <Kevin_Kofler> We don't support the KDE 3 desktop even in F9. [11:09] <Kevin_Kofler> And I don't know of any sane way to parallel-install it. [11:09] <than> Kevin_Kofler: yes i mean qt3/kde3 [11:09] <ltinkl> there are distros that ship both KDE3/4 in parallel but that's not the question [11:09] <Kevin_Kofler> As for "in F11 we only provide compat libs", huh? Isn't that what we're already doing? [11:10] <Kevin_Kofler> If you mean dropping the -devel packages, that's not an option. [11:10] <Kevin_Kofler> Lots of FTBFS packages. [11:10] <SMParrish> reason I asked was there are a few projects which have yet to start qt4 ports, wasn't sure how long we would support them [11:10] <Kevin_Kofler> And IMHO it just generally doesn't make sense to support a library for binaries and not for building from source. [11:11] *** Kevin_Kofler sets the channel topic to "KDE SIG Meeting - SIGs/KDE/Meetings/2008-06-24 - qt3/kdelibs3 lifetime". [11:11] <Kevin_Kofler> GTK+ 1 is still in Fedora. [11:11] <Kevin_Kofler> I don't see why Qt 3 would be any different. [11:11] <Kevin_Kofler> Nor kdelibs3 and kdebase3 as long as they're needed. [11:12] <Kevin_Kofler> I think it's way too early to even think of dropping support for them. [11:12] <than> Kevin_Kofler: is there GTK+ 1 devel still in fedora? [11:12] <rdieter> hiya [11:12] <Kevin_Kofler> Yes. [11:12] <Kevin_Kofler> How do you think xmms is built? [11:13] <XulChris> yea, but there is no need for xmms with audacious [11:13] <Kevin_Kofler> GTK+ 1 might be EOL soon, but that'll still mean it had years of lifetime in Fedora. [11:13] <Kevin_Kofler> And that's normal. [11:14] <Kevin_Kofler> For big API changes like that, apps take a long time to get ported or replaced. [11:14] <rdieter> my take, support kde3 dev/runtime as long as kde.org upstream does (or at least for another release or 2, then re-evaluate) [11:14] <than> Kevin_Kofler: ok, it's still early to make decision [11:14] <Kevin_Kofler> EOLing the libraries too soon doesn't help anyone. [11:14] <shawn_work> hullo [11:14] <ltinkl> definitely, let's move on :) [11:14] <Kevin_Kofler> If kde.org upstream doesn't update the libraries anymore, that just means we'll have less work maintaining them. ;-) [11:15] <Kevin_Kofler> As for the suggestion of dropping the -devel package, here's why it's a bad idea: [11:15] <Kevin_Kofler> A compat library without a -devel package is entirely useless for software which is built from source, like Free Software normally is. [11:16] <Kevin_Kofler> It's also useless for software in Fedora, because packages are supposed to be rebuildable from source in the latest Rawhide. [11:16] <Kevin_Kofler> At "best", it only helps proprietary software (if you even consider that a good thing), at worst, it doesn't help at all. [11:17] <Kevin_Kofler> We really need the -devel packages as long as we support the compat libs. [11:18] <Kevin_Kofler> Anything else or let's move on? [11:18] *** Kevin_Kofler sets the channel topic to "KDE SIG Meeting - SIGs/KDE/Meetings/2008-06-24 - kdepim for F9". [11:18] <rdieter> move on++ [11:19] <Kevin_Kofler> OK, next topic: kdepim for F9. Stay with 3.5 or update to 4.1? [11:19] <Kevin_Kofler> I think we should stay with 3.5 in F9 (and of course F10 will have 4.1). [11:19] <rdieter> I think the resounding conclusion here is 3.5 [11:20] <Kevin_Kofler> kdepim 4 breaks dependencies of other apps (which had to be rebuilt in Rawhide with reduced functionality) and there are also some user complaints about regressions in kdepim itself. [11:20] <than> Kevin_Kofler: we should stay with 3.5 [11:20] <rdieter> my notion to consider kdepim4 was based on post-FUDCon giddie [11:20] <than> kdepim-4.1 is not much tested [11:21] <Kevin_Kofler> rdieter: I guess you can (continue) offer(ing) kdepim 4.1 in kde-redhat unstable. [11:21] <than> it's risky to have it in F9 update [11:21] <than> it's fine with F10 [11:22] <Kevin_Kofler> than: +1 [11:22] <shawn_work> stay with 3.5 [11:22] <shawn_work> +1 [11:22] <rdieter> +1 [11:23] <Kevin_Kofler> OK, I think we can move on. :-) [11:23] *** Kevin_Kofler sets the channel topic to "KDE SIG Meeting - SIGs/KDE/Meetings/2008-06-24 - cmake 2.6". [11:23] <Kevin_Kofler> Next one: cmake 2.6. 2 questions: [11:24] <shawn_work> I am using CMake 2.6 right now from a koji install (2.6RC i think) [11:24] <Kevin_Kofler> 1. Is 2.6 really needed for 4.1? I don't see any documentation saying that's supposed to be the case. [11:24] <shawn_work> well, you need a newer CMake or KDE won't build, at least it did not let me use 2.5 [11:24] <Kevin_Kofler> and 2. If yes, has anybody talked to the cmake maintainers about an F9 update yet? [11:25] <Kevin_Kofler> I really don't want to be hacking CMakeLists.txt files all over the place in our F9 KDE 4.1 update! [11:25] <rdieter> I share shawn's experience, kde-4.1 doesn't currently build with cmake < 2.6. I can ping the cmake folks for an update. [11:25] <shawn_work> you could try to compile trunk w/ 2.5 [11:25] <than> shawn_work: i still have old cmake and can build kde-4.1 without any problem [11:25] <shawn_work> than: you didnt get an error saying CVS builds of cmake aren't supported or such? [11:26] <rdieter> than: what arch? (my x86_64 builds failed) [11:26] <shawn_work> 32bit for me [11:26] <than> shawn_work: i didn't see this error [11:26] <Kevin_Kofler> shawn_work: 2.5 is a CVS build, 2.4 is a stable version. [11:26] <Kevin_Kofler> 2.4 is what we have in F8 and F9 now. [11:26] <than> rdieter: it's 32bit [11:27] <shawn_work> ah yes 2.5 wasn't 'released' [11:27] <shawn_work> Kevin_Kofler: 2.4 does not have checks to see if files got installed or not previously [11:27] <Kevin_Kofler> If we really need 2.6, we'd probably also need an update in F8 to update the development platform + Dolphin packages. [11:27] <rdieter> than: nod, my 32bit builds were fine too. seems something related to lib64 [11:27] <shawn_work> 2.5/2.6 added significant improvements to installations where you reinstall over another install :) [11:27] <Kevin_Kofler> rdieter: If it's only that, it's probably a bug and can be fixed. [11:28] <than> Kevin_Kofler: +1 [11:28] <Kevin_Kofler> shawn_work: But we never do that when packaging. :-) [11:28] <rdieter> shrug, I'd rather be fixing kde bugs, and if a cmake update is all it takes... [11:28] <shawn_work> Kevin_Kofler: yep, so its a moot feature [11:29] <Kevin_Kofler> rdieter: Well, the thing is, if 4.0 builds and 4.1 doesn't, then why are you so sure it isn't a KDE bug? [11:29] <Kevin_Kofler> Anyway, I guess we need some build logs. [11:29] <Kevin_Kofler> I could try building things on my x86_64 laptop, it's running F9 + updates, so it has cmake 2.4. [11:30] <rdieter> personally, if a fix (cmake-2.6) is available, I'd rather spend my time on other more worthwhile stuff, that's all. [11:30] <than> Kevin_Kofler: if kde-4.1 needs new feature in cmake >2.5, then we have to upgrade to new version [11:30] <rdieter> if someone else feels motivated, go for it. [11:31] <Kevin_Kofler> than: Yes, but if it builds on 32-bit and not 64-bit, that doesn't sound like it simply needs a new feature. :-) [11:31] <than> Kevin_Kofler: it seems a bug here [11:31] <Kevin_Kofler> I'd like to see this also fixed upstream, if 2.4 is supposed to be supported, then it should actually be. [11:31] * shawn_work checks KDE Build wiki [11:33] <Kevin_Kofler> rdieter: Do you remember what package failed to build? [11:33] <shawn_work> does not say what version [11:33] <rdieter> Kevin_Kofler: low in the stack, phonon, kdepimlibs (I think) [11:33] <shawn_work> Linux From Scratch: CMake: KDE-4 and many supporting libraries use CMake. Install the latest version from cmake.org [11:34] <shawn_work> they dont say what version [11:34] <rdieter> Kevin_Kofler: some/most stuff couldn't find phonon and/or automoc [11:34] <shawn_work> wget http://www.cmake.org/files/v2.4/cmake-2.4.6.tar.gz [11:34] <shawn_work> 2.4 should work with trunk apparently still [11:34] <ltinkl> I'm using 2.4.8 to build the trunk locally [11:35] <shawn_work> ltinkl: that should be ok then [11:36] <than> shawn_work: it's not needed to update to nnew version for F9 if trunk build with cmake-2.4.8 [11:36] <shawn_work> then we're ok with 2.4.x [11:37] <shawn_work> so -1 to moving to 2.6 for Fedora 9 backport [11:37] <rdieter> umm... try it in mock, cmake-2.4 + kde-4.1 fails (at least on x86_64), it did for me anyway. [11:37] <Kevin_Kofler> Well, we'll let the cmake maintainers decide then, and we should fix the build failures (upstream, as build fixed should be). [11:38] <shawn_work> is 2.4 still supported? [11:38] <shawn_work> yeah 2.4.8 was last [11:40] <Kevin_Kofler> So I suggest this plan: [11:40] <Kevin_Kofler> 1. figure out where the build failure is [11:40] <Kevin_Kofler> 2. figure out what causes it [11:40] <Kevin_Kofler> 3a. if it's a KDE bug or something easily workaroundable in KDE, fix it in KDE upstream, we'll get it in the next KDE snapshot/RC/whatever [11:41] <Kevin_Kofler> 3b. if it's a cmake bug, talk to the cmake maintainers about upgrading to 2.6 or fixing 2.4 [11:41] <Kevin_Kofler> Any objections to this plan? [11:41] <shawn_work> <shawn_work> Question; BUilding KDE 4.1 requires which version of CMake? [11:41] <shawn_work> <tsdgeos> 2.4 or 2.6 [11:41] <shawn_work> <tsdgeos> not 2.5 [11:41] <rdieter> nope, looks like a winner. [11:42] <than> Kevin_Kofler: looks good to me [11:42] <Kevin_Kofler> Now who has the fastest x86_64 build machine? ;-) [11:43] <Kevin_Kofler> I can try debugging things on my Core 2 Duo laptop. [11:44] <rdieter> I've got a Xeon box, if you get desperate. can give you a remote shell. [11:45] <rdieter> err, I only have a f9-i386 vm running there at the moment (host is centos5/x86_64) [11:45] <rdieter> or you could use mock. [11:45] <Kevin_Kofler> I think my Core 2 Duo will be good enough anyway. [11:46] *** Kevin_Kofler sets the channel topic to "KDE SIG Meeting - SIGs/KDE/Meetings/2008-06-24 - Open discussion". [11:46] <Kevin_Kofler> So I think that's all from our ad-hoc agenda. [11:46] <Kevin_Kofler> So it's time for open discussion. [11:46] <rdieter> any good, recent bugs worth mentioning ? [11:47] *** Kevin_Kofler sets the channel topic to "KDE SIG Meeting - SIGs/KDE/Meetings/2008-06-24 - Recent bugs". [11:47] <Kevin_Kofler> Oh, the file conflicts maybe? [11:47] <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=452391#c2 [11:47] <buggbot> Bug 452391: low, low, ---, Ngo Than, ASSIGNED , File conflicts with kde-i18n [11:47] <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=452392 [11:47] <buggbot> Bug 452392: low, low, ---, Ngo Than, NEW , File conflicts with libkipi [11:48] <rdieter> I can work on the kipi-related ones. [11:48] <Kevin_Kofler> Should both be EasyFix, though I'm surprised there aren't more conflicts in the i18n/l10n ones: are there no kdepim translations in kde-l10n-4.1? [11:50] <Kevin_Kofler> rdieter: OK [11:50] <Kevin_Kofler> I'll clean up the one obvious conflict in the i18n/l10n packages. [11:50] <rdieter> looks like than's been working on some of that this morning already. [11:51] <Kevin_Kofler> The knetattach one is still there. [11:51] <Kevin_Kofler> than: If you want to fix it, go ahead. [11:51] <Kevin_Kofler> Otherwise I'll do it. [11:52] <than> Kevin_Kofler: it will fix it [11:52] <than> s/it/i [11:52] <Kevin_Kofler> than: OK, go ahead. [11:52] <rdieter> oh, had we discussed/considered intruducing a kdepim3 pkg for rawhide? [11:52] <Kevin_Kofler> Any other recent bugs worth mentioning? [11:53] <Kevin_Kofler> What would kdepim3 contain exactly? libkcal? [11:53] <than> rdieter: for what do we need kdepim3 in rawhide? [11:53] <Kevin_Kofler> That's what the apps which want kdepim 3 want to use, except for basKet which wants to integrate into Kontact, which simply can't work with kdepim 4. [11:53] <rdieter> Kevin_Kofler: pretty much (plus any other useful dev/runtime bits) [11:54] <Kevin_Kofler> libkipi (KDE 3 version), taskjuggler and tellico want to use libkcal. [11:54] <rdieter> come to think of it, there aren't all that many kdepim(3) deps anyway, maybe best course would be try squash them, and only consider kdepim3 as a later resort. [11:54] <Kevin_Kofler> I had to patch taskjuggler to build without libkcal because the support for building without kdepim was incomplete. [11:55] <Kevin_Kofler> There aren't any kdepim3 deps in Rawhide now because we disabled kcal support in the 3 affected packages. [11:55] <rdieter> problem solved! :) [11:56] <Kevin_Kofler> The other 2 were basKet (Kontact integration, not fixable in any sane way) and libopensync-plugin-kdepim (had to be upgraded to the KDE 4 port, already done). [11:57] <Kevin_Kofler> (basket lost its basket-kontact subpackage in Rawhide, the app itself is still there, it only needs kdelibs3.) [11:58] <Kevin_Kofler> Oh, some more bugs: [11:58] <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=452607 [11:58] <buggbot> Bug 452607: low, low, ---, Ngo Than, NEW , Embedded Konsole broken in kdevelop [11:58] <Kevin_Kofler> That's a missing dep on kdebase3, should that be added? [11:58] <Kevin_Kofler> Or do we consider KonsolePart support optional? [11:58] <rdieter> wasn't there some other kde3 app that wanted/needed the konsole-part ? [11:59] <rdieter> ah, kile has the same issue, currently includes: Requires: kdebase3 [12:00] <Kevin_Kofler> I think KDevelop should get that too. [12:00] <rdieter> I'd say, add the Requires: kdebase3 [12:00] <Kevin_Kofler> Users expect to have an embedded console there. [12:00] <rdieter> kdebase3 is pretty big, consider a -konsolepart subpkg? [12:01] <Kevin_Kofler> I'm a bit worried that we'll end up in subpackage hell. :-( [12:01] <rdieter> ok, it's only 2 apps so far, probably not worth it. [12:01] <Kevin_Kofler> If we have a subpackage for each part of kdebase3 some app needs, we'll have a ton of them and a big mess. [12:01] <Kevin_Kofler> We already have the one for kdepim which was a hack to make the F9 live image fit on a CD. [12:02] <Kevin_Kofler> Then there's this one (just FYI; I fixed it this week): https://bugzilla.redhat.com/show_bug.cgi?id=452054 [12:02] <buggbot> Bug 452054: high, low, ---, Kevin Kofler, MODIFIED , Use of the Symbol Viewer plugin crashes kate [12:02] <rdieter> and neither of these apps are candidates for including on the live image [12:02] <Kevin_Kofler> That was fixed upstream in 4.1 4 months ago, but they forgot to backport it. :-( [12:02] <Kevin_Kofler> So I did and pushed out a new kdesdk. [12:03] <rdieter> rock [12:04] <Kevin_Kofler> OK, we're 4 minutes over time already? [12:04] <Kevin_Kofler> Anything so urgent that it has to be discussed right now? Otherwise we'll end the meeting here. [12:05] <rdieter> close up shop [12:05] <Kevin_Kofler> OK, that was all for today, as usual, we can followup on #fedora-kde if needed.