14:03:30 <rdieter> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-11-23 14:03:30 <zodbot> Meeting started Tue Nov 23 14:03:30 2010 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:03:33 <rdieter> #meetingname kde-sig 14:03:33 <zodbot> The meeting name has been set to 'kde-sig' 14:03:52 <rdieter> #chair Kevin_Kofler than jreznik 14:03:52 <zodbot> Current chairs: Kevin_Kofler jreznik rdieter than 14:03:55 <rdieter> #topic roll call 14:04:02 <rdieter> who's present today? 14:06:11 <Kevin_Kofler> Present. 14:06:19 * than is present 14:07:33 <rdieter> hmm... well, ok, a slow day it seems. :) 14:07:35 <rdieter> #topic agenda 14:07:52 <than> jaroslav cannot attend the meeting today 14:07:54 <rdieter> #info +kde-4.5.80 topic 14:08:11 <rdieter> anything else agenda-worthy? 14:08:25 * ltinkl is a bit late 14:08:32 <rdieter> ltinkl: hi! 14:08:43 <rdieter> #info Kevin_Kofler than rdieter ltinkl present 14:08:45 <rdieter> #chair ltinkl 14:08:45 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter than 14:09:12 <rdieter> well, let's move on to what we *do* have... 14:09:22 <rdieter> #topic kde-4.5.80 (4.6beta1) status 14:09:45 <Kevin_Kofler> So we should have everything building now. 14:09:59 <Kevin_Kofler> kde-l10n is built. 14:10:10 <rdieter> yay, I'll help cleanup rawhide broken deps 14:10:13 <Kevin_Kofler> kdesdk is building now, the previous build choked only on the file list, so it should be good now. 14:10:27 <Kevin_Kofler> For kdelibs, upstream's tarball respin contains a broken "build fix". :-/ 14:10:36 <rdieter> Kevin_Kofler: so the xml problem is gone now? 14:10:41 <Kevin_Kofler> Jonathan Riddell posted a fix for the fix to kde-packager, so I'm building that now. 14:10:50 <Kevin_Kofler> The XML problem is a separate issue, it's not a fatal error. 14:10:56 <rdieter> oh, ok 14:11:06 <Kevin_Kofler> kdesdk had several issues with antlr: 14:11:10 <Kevin_Kofler> * missing Requires jpackage-utils 14:11:14 <Kevin_Kofler> * missing Requires java 14:11:30 <Kevin_Kofler> * GIJ 4.5.1 is broken: running antlr under it generates junk C++ output 14:11:31 <rdieter> Kevin_Kofler: antlr in rawhide does (or should!) depend on those already. 14:11:41 <Kevin_Kofler> (so now I use BR java >= 4.6) 14:11:44 <Kevin_Kofler> rdieter: No. 14:11:52 <Kevin_Kofler> antlr hasn't been touched at all since the dist-git conversion. 14:11:53 <rdieter> it does in git, though I didnt see if it was actually built, perhaps not 14:12:04 <rdieter> ugh 14:12:23 <Kevin_Kofler> You may be looking at antlr3, which is not the same thing as antlr. 14:12:27 <Kevin_Kofler> kdesdk is using antlr. 14:12:34 <rdieter> I looked at antlr 14:12:52 <Kevin_Kofler> Maybe they fixed it only in a branch? 14:12:58 <Kevin_Kofler> I checked master and there's nothing there. 14:13:04 <rdieter> I checked antrl/master 14:13:13 <Kevin_Kofler> WTF 14:13:40 <Kevin_Kofler> In any case, the package in Rawhide is clearly missing deps, since adding the BRs worked. 14:13:44 <rdieter> ok 14:13:47 <rdieter> sure 14:13:56 <rdieter> it doesnt hurt anything to add them explicitly for now 14:14:12 <rdieter> I'll have to go find the bug I filed on that and re-open it 14:14:28 <Kevin_Kofler> I see "dist-git conversion" on the top of the antlr/master history. 14:14:47 * nucleo here 14:14:47 <Kevin_Kofler> Nothing newer than antlr-2.7.7-10.fc14. 14:15:22 <rdieter> 2.7.7-10 main pkg, includes: 14:15:26 <rdieter> Requires: jpackage-utils 14:15:27 <rdieter> Requires: java 14:16:03 <Kevin_Kofler> But the main package is not a dep of what we use! 14:16:09 <Kevin_Kofler> We get only -devel and -c++. 14:16:28 <rdieter> ah, just antlr-tool , gotcha 14:17:52 <Kevin_Kofler> We should work on getting the new optional dependencies for 4.6 packaged. 14:20:25 <than> Kevin_Kofler: is it only in kdesdk or do we have deps issue in other kde packages? 14:20:34 <rdieter> nod, I was going to start compiling a todo list for f15/kde46 14:20:50 <rdieter> I'll post onlist later 14:21:05 <than> rdieter: it's great 14:22:06 * rdieter goes to flex provenpackager to fix antlr 14:22:06 <Kevin_Kofler> than: The antlr mess only affects kdesdk. 14:22:14 <Kevin_Kofler> It's now worked around by added BRs there. 14:22:38 <Kevin_Kofler> New optional deps not yet in Fedora are all across KDE (and I think kdesdk actually isn't one of the affected packages). 14:23:28 <Kevin_Kofler> FYI, kdesdk built. 14:24:50 <than> i think it makes sense to rebuild all packages which need kde 14:24:55 <rdieter> .bug 595504 14:24:57 <zodbot> rdieter: Bug 595504 antlr: non-functional, missing deps? - https://bugzilla.redhat.com/show_bug.cgi?id=595504 14:25:08 <rdieter> that's the one 14:27:18 <rdieter> found when doing f14 builds, that kdebindings requires a newer sip (4.11.0+) 14:27:35 <Kevin_Kofler> OK 14:27:58 <Kevin_Kofler> BTW, the current kdebindings.spec is waiting for kdesdk-devel in the buildroot, then it'll probably also need file list adjustments. 14:28:03 <Kevin_Kofler> (I enabled the kdesdk-devel BR.) 14:29:32 <than> Kevin_Kofler: kdebindings-4.5.80-3.fc15 build failed 14:29:43 <Kevin_Kofler> than: I know. 14:29:49 <Kevin_Kofler> kdesdk-devel wasn't in the buildroot yet. 14:29:57 <than> ok 14:30:02 <Kevin_Kofler> That's what I was just saying. 14:30:14 <Kevin_Kofler> -2.fc15 (without the kdesdk-devel BR) built fine. 14:30:54 <than> off course, No Package Found for kdesdk-devel >= 4.5.80 14:31:11 <Kevin_Kofler> When I did the kdebindings change, I thought kdesdk had already been sorted out. 14:31:16 <Kevin_Kofler> Otherwise I'd have done kdesdk first. 14:32:10 <than> rdieter: do you want to update new sip in f14? 14:32:23 <rdieter> than: if we want kde-4.6 in f14, we'll need it, yeah 14:32:49 <Kevin_Kofler> That or some old-sip patch/hack. :-) 14:33:01 <rdieter> I can perhaps try to come up with some sip-compat pkg scheme, to avoid rebuilding the sip world 14:33:07 <rdieter> (the new sip has a new abi) 14:33:20 <Kevin_Kofler> Ugh, compat packages are a PITA. 14:33:31 <rdieter> sure. 14:33:34 <Kevin_Kofler> I'd rather hack kdebindings to build with the old SIP if it comes to that. 14:33:42 <than> Kevin_Kofler: +1 14:33:46 <rdieter> ltinkl: while we're at it, mind to give a bried summary of your halsectemy efforts? 14:33:53 <rdieter> brief... even 14:33:59 <ltinkl> yup 14:34:17 <ltinkl> I added 2 patches, 1 to kdelibs, 1 to kdebase-workspace 14:34:46 <ltinkl> which disable building of Solid HAL and PowerDevil backends 14:35:16 <Kevin_Kofler> But… You can't do that, Dave! ;-) 14:35:30 <Kevin_Kofler> HAL be gone! 14:35:30 <rdieter> so... to be clear, is kde hal-free now? 14:35:32 <ltinkl> we should probably look around for more HAL remnants 14:35:42 <ltinkl> basically, yes :) 14:36:04 <ltinkl> some specific KDE apps, like k3b, might still depend on it 14:36:23 <rdieter> #info ltinkl performed successful halsectemy surgery, core kde packaging should be free of hal-related deps now 14:36:23 <Kevin_Kofler> AFAIK, K3b stopped depending on it with the KDE 4 port. 14:36:50 <ltinkl> but I don't know whether k3b uses HAL directly or Solid to perform the hardware checks 14:37:06 <Kevin_Kofler> I think it got ported to Solid. 14:37:22 <rdieter> ltinkl: for testing purposes at least, you think it worthwhile to make our kde-unstable f14 builds be hal-free too? 14:37:28 <ltinkl> amarok might have some of this funtionality as well, for the portable media stuff 14:37:37 <than> Kevin_Kofler: as i know it still uses hal directly 14:38:08 <Kevin_Kofler> Then it's missing a dependency. :-) 14:38:11 <Kevin_Kofler> Because there is none. 14:38:30 <ltinkl> Kevin_Kofler: yup, probably it got it thru kdelibs 14:38:43 <ltinkl> I will check k3b and amarok now 14:38:45 <rdieter> there is set(ENABLE_HAL_SUPPORT 1) in k3b's CMakeLists.txt 14:39:11 <ltinkl> rdieter: yup, better add it back explicitely in k3b for now 14:39:34 <Kevin_Kofler> We should really fix the code, if we can… 14:39:40 <rdieter> #info k3b packaging needs to be reviewed for hal'isms 14:39:47 * jreznik is here, sorry, red hat duties... 14:39:58 <rdieter> jreznik: hi! 14:40:00 <ltinkl> rdieter: k3b and others 14:40:04 <ltinkl> jreznik: hi :) 14:40:30 <nucleo> kwebkitpart is not installed as dependency of kdebase and kdenetwork 4.6. It needs to be added to comps. Should we add kwebkitpart as default or optional to comps? 14:40:43 <than> ltinkl: or it's better to fix k3b not to use hal 14:40:49 <Kevin_Kofler> What we'd need for debugging is a fake HAL which listens to HAL's D-Bus interface and complains loudly each time an app sends a request to it. :-) 14:41:03 <ltinkl> than: I will see how much of HAL it uses, but yes, that's the plan :) 14:41:22 <Kevin_Kofler> nucleo: IMHO, optional. 14:41:26 * rdieter sees org.freedesktop.Hal.Device.Storage (at least) in k3b 14:41:31 <ltinkl> than: same for amarok and maybe a few other apps 14:41:35 <Kevin_Kofler> nucleo: KDE works perfectly without it. 14:41:47 <than> ltinkl: great 14:41:47 <rdieter> #info amarok to be reviewed for hal'isms as well 14:41:51 <Kevin_Kofler> It's just redundant, there's already KHTML in kdelibs. 14:42:11 <rdieter> ok, subtopic: to install kwebkitpart by default or not. 14:42:29 <ltinkl> +1 for installing it by default 14:42:32 <rdieter> I'd advocate yes, it's nice functionality, with a minimial footprint 14:42:37 * Kevin_Kofler wonders why those apps don't use Solid? Is Solid's API not complete enough? 14:42:42 <ltinkl> yup, gives users the choice 14:42:51 <Kevin_Kofler> ltinkl: -1 from me. 14:42:55 <Kevin_Kofler> rdieter: It's duplicate functionality. 14:43:01 <ltinkl> Kevin_Kofler: yup, most probably, remember k3b is older than Solid 14:43:04 <Kevin_Kofler> What's the point of installing 2 KParts doing the same thing by default? 14:43:05 <nucleo> kdewebkit is in kdelibs even if kwebkitpart not installed 14:43:18 <ltinkl> Kevin_Kofler: freedom of choice 14:43:34 <Kevin_Kofler> Yeah, let's stick GNOME on the KDE spin too, then. :-/ 14:43:36 <Kevin_Kofler> WTF? 14:43:38 <rdieter> it's similar to the shipping 2 phonon backends situation 14:43:39 <rdieter> imo 14:43:50 <ltinkl> idd 14:43:52 <Kevin_Kofler> rdieter: I think that's also quite silly and useless. 14:43:52 <rdieter> sometimes one works better than the other for some users 14:43:58 <jreznik> I like KHTML but I have to agree - I have to use webkitpart a lot of time (as a backup solution) 14:44:21 <ltinkl> definitely, webkit works better for me, most of the times 14:44:27 <rdieter> than ? 14:44:32 <nucleo> kwebkitpart only gives possibility to use kdewebkit code from kdelibs 14:44:35 <Kevin_Kofler> We're already short enough of space without redundant stuff. 14:44:44 <than> if the user want webkit they can install it manually 14:44:44 <jreznik> rdieter: problem is - sometimes is better one, sometimes another... we can choose the best one... 14:44:52 <than> i prefer khtml as default 14:44:57 * Kevin_Kofler wonders if libkwebkit could be subpackaged out, too. 14:45:16 <rdieter> than : kthml will be used by default regardless, this is only a matter of installing kwebkitpart by default 14:45:18 <than> kwebkitpart optional 14:45:22 <ltinkl> than: yup, but this is about installing webkitpart as well 14:45:57 <than> rdieter: kwebkitpart should not be installed by default 14:46:00 <ltinkl> to be clear, khtml still stays the default 14:46:09 <ltinkl> than: why? 14:46:22 <rdieter> ok, so we have a difference of opinion here. 14:46:31 <than> ltinkl: most users use khtml 14:46:32 <rdieter> jreznik: to be clear, were you +1 or -1 14:46:54 <rdieter> or yet undecided? :) 14:47:04 <Kevin_Kofler> Upstream worked hard to fully support it as an optional add-on without dragging it in when not used, through those new abstract interfaces in 4.6. 14:47:17 <Kevin_Kofler> So there's no point in forcing it on everyone. 14:47:18 <rdieter> in favor: rdieter, ltinkl , opposed: Kevin_Kofler, than 14:47:26 <jreznik> khtml as default one, but undecided on webkit (I agree with Kevin_Kofler on the other hand - KHTML is unusable for example for RH internal tools) 14:47:48 <nucleo> people who use KDE < 4.6 have can select between WebKit and KHTML but after update to 4.6 only KHTML will be available so this is will be loss of functionality. 14:47:50 <jreznik> Kevin_Kofler: it's not too big - we already have qtwebkit in... 14:48:04 <Kevin_Kofler> nucleo: It won't be lost on upgrades. 14:48:10 <Kevin_Kofler> This only affects new installs. 14:48:14 <rdieter> nucleo: for < f15, we'll have to pull it in via deps somehow, we're discussing f15 here atm 14:48:24 <jreznik> I'm +1 to ship it... it's really regression... lot of people do not upgrade but reinstalls 14:48:26 <Kevin_Kofler> rdieter: Uh, no, we don't. 14:48:43 <Kevin_Kofler> If users had it installed (through deps), the package is there, so it will still be there even if nothing Requires it. 14:48:47 <rdieter> Kevin_Kofler: ok, perhaps not, we'll see 14:48:53 <Kevin_Kofler> So no, please don't add bogus deps. 14:48:55 <rdieter> point is, we're discussing f15 14:49:52 <ltinkl> Kevin_Kofler: you want people to switch away to Firefox if Konqueror fails on them? 14:49:53 <Kevin_Kofler> Well, reinstalling means you get a new package set, by definition. 14:50:34 <rdieter> SMParrish: ping, you around ? 14:50:44 <jreznik> ltinkl: that's another point - it's better to have people using qt tech than switching to firefox 14:50:54 <rdieter> we're at +3/-2 so far then 14:50:58 <jreznik> thanks to qtwebkit I don't have to use ff most of time 14:51:52 <ltinkl> this is about the default KDE web browser, which is Konqueror 14:51:55 <Kevin_Kofler> Well, I guess I don't care that strongly, so if you want to ship this by default, let's ship it. :-/ 14:52:15 <Kevin_Kofler> I think it's quite useless to ship this kind of stuff which isn't even used by default, but as long as we have the space. 14:52:17 <rdieter> Kevin_Kofler: does that mean, you change your mind/vote? 14:52:28 <ltinkl> arora and rekonq are different stories 14:52:41 <tibbs> Can you guys ping me if you open the floor? 14:52:43 <rdieter> neither of those we ship by default either, mind you 14:52:47 <ltinkl> I wouldn't be too surprised if Rekonq became the default web browser for KDE 4.7 14:52:51 <rdieter> tibbs : sure 14:52:59 <Kevin_Kofler> Yuck! 14:53:13 <Kevin_Kofler> Rekonq totally sucks. 14:53:18 <Kevin_Kofler> No menu, no features. 14:53:22 <than> Kevin_Kofler: +1 14:53:45 <rdieter> #info discussed shipping kwebkitpart by default in f15, a bit contentious, +3/-2 , will continue discussion onlist. 14:53:45 * jreznik is using rekonq :) 14:53:46 <Kevin_Kofler> At least WebKitPart is only partially crippled. (Still, it's missing features compared to KHTML, in particular, no "Stop animations"!). 14:54:04 <rdieter> #topic open discussion 14:54:06 <ltinkl> for youngters/newbies, the minimal approach aka chrome/safar/rekonq is the preferred one 14:54:07 <rdieter> let's move on... 14:54:13 <rdieter> tibbs : go ahead 14:54:21 <nucleo> what state of qt-4.7.1 update? 14:54:29 <tibbs> Is there a tracker bug for KDE-related package reviews? 14:54:38 <tibbs> Or do you guys coordinate package review work at all? 14:54:45 <rdieter> tibbs : no, but that would be a good idea. I'll make one 14:54:57 <tibbs> There are a few really old KDE-related package reviews that I'd hope to get someone to look into. 14:55:06 <jreznik> tibbs: usually it's the best to ping someone on #fedora-kde 14:55:18 <tibbs> Sure, I can do that. 14:55:24 <rdieter> #task rdieter to make a tracker bug for kde-related package reviews 14:55:31 <jreznik> so packages we are working on are get reviewed really fast 14:55:48 <tibbs> Some of these are nearly a year old. 14:56:02 <tibbs> rdieter: If you make that bug, ping me and I'll add these reviews to it. 14:56:05 <jreznik> tibbs: do you have a list? I don't remember any now... 14:56:10 <rdieter> tibbs : ok, thanks 14:56:12 <jreznik> tibbs: thanks 14:56:23 <tibbs> .bug 551274 14:56:25 <zodbot> tibbs: Bug 551274 Review Request: akonadi-googledata -Akonadi resources to sync google calendar events and contacts - https://bugzilla.redhat.com/show_bug.cgi?id=551274 14:56:35 <Kevin_Kofler> Some of those are submitted by people who aren't #fedora-kde regulars, so we tend to forget about them. :-( 14:56:36 <tibbs> .bug 553606 14:56:41 <zodbot> tibbs: Bug 553606 Review Request: kde-plasma-birthday-reminder - Birthday Reminder Plasmoid - https://bugzilla.redhat.com/show_bug.cgi?id=553606 14:56:42 <Kevin_Kofler> We use IRC for most communication. 14:56:45 <tibbs> There are a few others. 14:57:13 <Kevin_Kofler> If people don't come to IRC, they won't get in touch with us effectively, unfortunately. 14:57:32 <tibbs> That's why I propose a tracker; in case someone doesn't do IRC, you can still see their reviews without having to scan the list. 14:57:34 <Kevin_Kofler> Some of those reviews, I don't even know about, tbh. 14:57:54 <Kevin_Kofler> Well, will they know to put stuff on the tracker? 14:57:59 <tibbs> I will do it. 14:58:06 <jreznik> if they don't do IRC, than they probably miss tracker too... 14:58:17 <jreznik> Kevin_Kofler: exactly... 14:58:28 <tibbs> The alternative is just to have me ping your channel with a list occasionally. 14:58:36 <tibbs> I don't care, as long as someone looks at the tickets. 14:59:13 <tibbs> I don't expect package submitters to know about all the trackers, but I add appropriate trackers when I see the tickets. 14:59:22 <tibbs> Works fine for the Java folks. 14:59:31 <Kevin_Kofler> I wish the submitters would take care of pinging us themselves. :-( 14:59:40 <rdieter> sure, a tracker isn't magic, but it's certainly an incremental improviement 14:59:40 <Kevin_Kofler> Sadly, some of them aren't very communicative. :-( 14:59:45 <jreznik> tibbs: but yes, good idea 14:59:52 <Kevin_Kofler> I think it makes sense to have a tracker. 14:59:53 <tibbs> Not everyone uses IRC; it's not a requirement for anyone. 15:00:02 <Kevin_Kofler> I think it should be, but that's just me. 15:00:14 * rdieter wants a unicorn while we're at it 15:00:25 <jreznik> rdieter: +1 15:00:27 <Kevin_Kofler> It's much more effective to communicate over IRC than over mail, even more so if they read mails only once every blue moon (which is something some IRC haters do, too). 15:00:47 <jreznik> ok, we're out of time 15:00:52 <Kevin_Kofler> I have a FYI: 15:00:54 <Kevin_Kofler> https://admin.fedoraproject.org/updates/xsettings-kde-0.11-2.fc14 15:00:55 <tibbs> Thanks, folks. 15:00:55 <Kevin_Kofler> https://admin.fedoraproject.org/updates/xsettings-kde-0.11-2.fc13 15:01:01 <Kevin_Kofler> "This update makes GTK+/GNOME applications display icons in menus when running in a KDE (Plasma) session, as Qt/KDE applications do. 15:01:01 <Kevin_Kofler> You will have to restart your session (log out and log back in) or manually restart xsettings-kde for the change to take effect." 15:01:35 <Kevin_Kofler> In F13, /etc/gtk-2.0/gtkrc was changed to set gtk-menu-images=0 (and gtk-button-images=0, but xsettings-kde already overrides that). 15:01:52 <Kevin_Kofler> So this makes xsettings-kde tell GTK+ apps to not hide those icons under KDE. 15:01:59 <Kevin_Kofler> It's now in updates-testing. 15:04:32 <rdieter> ok, thanks. 15:04:36 <rdieter> #endmeeting