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