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