14:04:18 <rdieter> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-08-24
14:04:18 <zodbot> Meeting started Tue Aug 24 14:04:18 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:05:01 <rdieter> #meetingname kde-sig
14:05:01 <zodbot> The meeting name has been set to 'kde-sig'
14:05:21 <rdieter> #chair thomasj_ than ltinkl Kevin_Kofler
14:05:21 <zodbot> Current chairs: Kevin_Kofler ltinkl rdieter than thomasj_
14:05:26 <rdieter> #topic roll call
14:05:30 <Kevin_Kofler> Present.
14:05:30 <rdieter> who's present today?
14:05:34 <ltinkl> present
14:05:42 * thomasj_ 
14:05:43 * than is present
14:06:12 <rdieter> #info rdieter thomasj_ Kevin_Kofler ltinkl than present
14:07:11 <rdieter> #topic agenda
14:07:24 <Kevin_Kofler> KDE 4.5 status
14:07:32 <rdieter> ltinkl offered to give an update on solid and udisks/upower
14:07:52 <ltinkl> shall I start? this will be very quick :)
14:07:56 <rdieter> f14 livecd issues (size, etc...)
14:08:04 <rdieter> ok
14:08:19 <rdieter> #topic solid and udisks/upower ( ltinkl )
14:08:24 <rdieter> ltinkl: it's all yours
14:08:43 <ltinkl> udisks and upower backends are currently imported into kdelibs trunk
14:08:52 <ltinkl> which means they will be intergal part of KDE 4.6
14:09:04 <Kevin_Kofler> Great.
14:09:07 <rdieter> yay
14:09:12 <Kevin_Kofler> Should we try to backport them for F14?
14:09:25 <Kevin_Kofler> But given the timing, I guess it's better not to.
14:09:33 <ltinkl> however, they do not fully cover (yet) the funtionality of the HAL backend
14:09:48 <Kevin_Kofler> What's missing?
14:09:52 <ltinkl> for that, we need a (third) generic udev backend
14:10:04 <rdieter> the stuff that needs to be re-implemented I assume
14:10:12 <ltinkl> which would implement classes as Processor, Button, etc.
14:10:21 <ltinkl> cf. http://api.kde.org/4.x-api/kdelibs-apidocs/solid/html/index.html
14:10:36 <Kevin_Kofler> Shouldn't we have one u* backend which uses (lib)udev, udisks and upower all together?
14:10:49 <ltinkl> in other words, currently only disk-related and power management features are implemented
14:11:13 <ltinkl> no, the idea that the current Solid in trunk uses is to split the backends
14:11:26 <Kevin_Kofler> They're used together on up-to-date distros, and where they aren't, it's because they use HAL, so they can keep using the HAL backend.
14:11:30 <ltinkl> the Solid framework can use several backends at once
14:11:50 <Kevin_Kofler> Well, I don't really see the need for a split in this case.
14:11:55 <Kevin_Kofler> But I guess it can't hurt, either.
14:12:18 <ltinkl> it has the advantage of writing "specialized" backends, like the recent upnp
14:12:22 * SMParrish sorry I'm late
14:12:36 <rdieter> #info SMParrish present too
14:12:38 <rdieter> SMParrish: hi!
14:12:50 <ltinkl> anyway, that was the kdelibs part
14:13:25 <ltinkl> the fun began when we (with jreznik and rnovacek) found out last week there are other pieces of Solid, living in kdebase-workspace
14:13:27 <rdieter> #info udisks and upower backends are currently imported into kdelibs trunk (so will be included with KDE 4.6)
14:13:43 <Kevin_Kofler> ltinkl: I see the point for specialized backends, but udev is exactly the opposite of specialized. :-)
14:14:00 <Kevin_Kofler> But whatever, it's an implementation detail and I'll trust you to know what you're doing. :-)
14:14:17 <ltinkl> the part in kdebase-workspace extends that, mainly for power management (and networking)
14:14:35 <ltinkl> PowerDevil uses that for example
14:14:51 * jreznik is sorry - waiting for a friend with van to move my old furniture...
14:15:02 <ltinkl> so, we will need to write another module for kdebase-workspace which will replace the current HAL one
14:15:16 <rdieter> fun
14:15:16 <jreznik> ah hal mess as topic
14:15:26 <rdieter> #info jreznik present too
14:15:28 <ltinkl> jreznik: yup :)
14:16:02 <ltinkl> there is one problem tho, the HAL module needs root priviledges for some stuff, like changing brightness
14:16:30 <rdieter> ltinkl: how much work will kdebase-workspace/hal be? any ideas yet?
14:16:31 <ltinkl> and currently, this is not possible with upower (which deals with battery/ac only)
14:16:51 <ltinkl> so again, we might have to resort to using udev directly
14:16:55 <ltinkl> which sux :)
14:17:14 <ltinkl> jreznik: any idea on this? :)
14:17:34 <ltinkl> rdieter: well the plan is to persuade the upower author to add what we need
14:17:49 <Kevin_Kofler> For screen brightness, I think you're supposed to use XRandR these days.
14:17:51 <ltinkl> don't even ask how it's done in Gnome, we checked :)
14:17:53 <jreznik> ltinkl: it's the only way... a) ask upower people to support what we need, b) write our own power management lib
14:18:06 <Kevin_Kofler> At least that's what gnome-power-manager supposedly does.
14:18:25 <Kevin_Kofler> The problem being that proprietary drivers don't implement the required interface at this time.
14:18:29 <ltinkl> HAL might be a dumping ground, but this way we will duplicate most stuff from it
14:18:40 <Kevin_Kofler> But I wouldn't give a darn about that, to be honest. :-)
14:18:43 * rdieter isn't hopeful, knowing how well the hal vs *kit business has gone so far
14:19:11 <ltinkl> Kevin_Kofler: nope :p not xrandr, the answer is /sys/devices/virtual/backlight/acpi_video0
14:19:41 <Kevin_Kofler> I think there's an XRandR interface they at least used to use.
14:20:20 <Kevin_Kofler> They might have added that magic file because of the graphics drivers which don't support the XRandR interface.
14:20:41 <Kevin_Kofler> IMHO you should just use the XRandR interface if it's still there and screw the proprietary drivers.
14:20:52 <ltinkl> yup, but for that you need root permissions (to write into those files)
14:21:01 <Kevin_Kofler> XRandR doesn'T need root.
14:21:13 <ltinkl> I know, talking about those dev files
14:21:25 <Kevin_Kofler> As for the drivers, either they support current XRandR interfaces or they won't work well with KDE, it has always been like that.
14:21:39 <Kevin_Kofler> I don't see why we should add crude workarounds because of them.
14:21:45 <ltinkl> Kevin_Kofler: what is the interface btw?
14:22:08 <rdieter> how about we discuss the details after meeting?
14:22:12 <Kevin_Kofler> I don't know, check gnome-power-manager history, I'm almost sure they used it at some point.
14:22:18 <rdieter> let's not get bogged down
14:22:29 <ltinkl> so to conclude this topic, half of the worj is kinda done (minus polishing and bug squashing), the other half is in the planning stage
14:22:56 <ltinkl> rdieter: yup, details after meeting
14:23:17 <rdieter> #info half of the work done (minus polishing and bug squashing), the other half (kdebase-workspace/hal) is in the planning stage
14:23:19 <rdieter> thanks
14:23:32 <rdieter> #topic kde 4.5 status
14:23:50 <rdieter> Re: f14, our batched kde-4.5.0 update just went stable
14:24:22 <rdieter> Re: f13, I did a new batch of kde-4.5.0 builds against qt-4.6.x
14:24:38 <rdieter> I was thinking of throwing these into our kde-testing repo soon
14:24:57 <ltinkl> rdieter: great, I will surely test those F13 builds
14:24:57 <Kevin_Kofler> rdieter: For F14, there's a new kdeedu with matching libindi and avogadro builds.
14:24:58 <than> rdieter: please upload it our kde-testing repo
14:24:58 <rdieter> though... kde-4.5.1 will be tagged real soon, not sure if it's worth waiting for
14:25:11 <thomasj_> 4.6.x.. Hrm.. Looks like i have to downgrade Qt again..
14:25:22 <Kevin_Kofler> I haven't pushed the stuff anywhere so far, wasn't sure what the status was.
14:25:26 <rdieter> thomasj_: no, you can still use whatever qt you want
14:25:30 <ltinkl> rdieter: if you have the builds, upload what you have imho
14:25:31 <thomasj_> cool
14:25:46 <Kevin_Kofler> thomasj_: Stuff built against 4.6 will work with 4.7, but the other way round won't work.
14:25:48 <rdieter> thomasj_: that's the point, the prior builds required qt47 hardcoded
14:25:57 <rdieter> Kevin_Kofler: +1
14:25:59 <thomasj_> I know, we talked about it
14:26:03 <rdieter> ok :)
14:26:10 <thomasj_> Though, for testing
14:26:24 <thomasj_> I guess i should downgrade to have what others have as well..
14:26:25 <rdieter> #info rdieter has some kde-4.5.0 builds prepped for kde-testing, will announce and push to repos later today
14:26:29 <Kevin_Kofler> I haven't checked what the maintainer did to libindi, if it's in testing already.
14:26:48 <Kevin_Kofler> I should push kdeedu and avogadro to F14 testing.
14:26:54 <rdieter> I hacked some libindi avogadro builds myself for that, but we should get some official builds too
14:27:07 <rdieter> Kevin_Kofler: right, +1
14:27:12 <Kevin_Kofler> Feel free to do official builds of avogadro, it's my package. :-)
14:27:12 <rdieter> please do
14:27:28 <rdieter> ok, I'll do avogadro
14:27:59 <rdieter> I'll leave f12 for now, can revisit that after kde-4.5.1 and if I/we have time
14:28:03 <Kevin_Kofler> For libindi, should we nag the maintainer or should we just do it? I mean, it's a point release, KStars is the main (only?) user of it and it needs the update.
14:28:18 <rdieter> as usual, we still have our fun kde-4.5 tracking bug
14:28:24 <rdieter> Kevin_Kofler: nag +1
14:28:44 <rdieter> (then resort to helping later if need be)
14:29:07 <rdieter> anything else 4.5-wise ?
14:29:16 <Kevin_Kofler> He updated Rawhide and F14 so far, I'd like him to also update at least F13 (but I also want to do F12, really).
14:29:28 <rdieter> <nod>
14:30:03 <Kevin_Kofler> (I guess that, if we want to push 4.5 to F12, we COULD hack the few F12 builds of kdeedu we'll do to build with the old libindi by reverting stuff, but I'd rather just upgrade libindi!)
14:31:05 <rdieter> alrighty, moving on...
14:31:16 <rdieter> #topic f14 livecd oversized
14:31:30 <than> there's security vulnerability in okular
14:31:35 <thomasj_> yep
14:31:42 <rdieter> than: ah, yes, let's discuss that next
14:32:03 <than> we should add the patch into our kdegraphics
14:32:07 <rdieter> our kde live image is oversized, would anyone be able to look at that ?
14:32:23 <than> rdieter: i will try
14:32:28 <rdieter> (I'll probably have some time next week, otherwise)
14:32:33 <rdieter> than: thanks
14:32:52 <than> rdieter: np
14:32:56 <Kevin_Kofler> I wish we could throw out more gnomish stuff, but it's all dragged in by Anaconda and friends somehow. :-(
14:33:03 <rdieter> #action than to look into oversized live image
14:33:17 <Kevin_Kofler> One of the big dep chain offenders is Metacity, which is dragged in by firstboot and now also anaconda.
14:33:26 <rdieter> #topic kdegraphics (okular) security issue
14:33:36 <Kevin_Kofler> (It's not even actually needed for liveinst, but it's still an anaconda dep, and it's also dragged in through firstboot anyway.)
14:33:50 <thomasj_> public disclosure is tomorrow
14:34:10 <rdieter> kde-packagers were sent a patch for okular, any volunteer(s) to apply patches, and issue updates?
14:34:18 <than> yes,it's set for the 25th
14:34:19 <rdieter> you know you want to, it's just so fun
14:34:28 <rdieter> :)
14:35:25 <than> i will take care of it
14:35:40 <rdieter> than: thanks again (busy day)
14:35:58 <rdieter> #action than will give kdegraphics(okular) some security patch love
14:36:18 <rdieter> #topic open discussion
14:36:22 <rdieter> anything else for today ?
14:36:27 <thomasj_> yup
14:36:40 <thomasj_> jreznik, any progress on the BluDevil packages?
14:36:51 <thomasj_> And to all, do we get it maybe into F14?
14:37:29 <thomasj_> If they're ready in time (depneds on the time left to get it in)
14:37:34 <rdieter> .bug 624020
14:37:36 <zodbot> rdieter: Bug 624020 Review Request: libbluedevil - A Qt wrapper for bluez - https://bugzilla.redhat.com/show_bug.cgi?id=624020
14:37:39 * rdieter found ^^
14:37:53 <thomasj_> Yes, i'm waiting for the rebuilds
14:37:59 <rdieter> thomasj_: looks like you're reviewing?  cool.
14:38:05 <thomasj_> yep :)
14:38:54 <rdieter> jreznik: I can help with initial packaging, if you need any.
14:39:10 <thomasj_> rdieter, is there a chance we can get bludevil into F14?
14:39:15 <rdieter> thomasj_: I think so
14:39:19 <thomasj_> cool!
14:40:14 <Kevin_Kofler> Uhm, %doc HACKING, really? Usually, HACKING is a document on how to develop the package itself, not useful for users of the package. Or is this one a (badly-named) document on how to develop WITH the library?
14:40:15 <thomasj_> That's all i had.
14:40:29 <rdieter> looks like we may have lost jreznik, we can poke him more after meeting
14:40:37 <rdieter> anything else ?
14:40:43 <Kevin_Kofler> I'll add my comment to the review.
14:41:07 <thomasj_> Kevin_Kofler, he's not yet ready with it.
14:42:36 * rdieter will end meeting in 30 seconds, if there's nothing else...
14:43:14 <Kevin_Kofler> Oh…
14:43:19 <Kevin_Kofler> I have one more thing.
14:43:22 <Kevin_Kofler> The QCH apidocs.
14:43:39 <Kevin_Kofler> I tried to build QCH apidocs for kdelibs, so far with limited success.
14:44:01 <Kevin_Kofler> I do get QCH files out of the apidocs script with the poorly documented switch which does it, but they have several issues.
14:44:59 <Kevin_Kofler> I'll try to either fix / work around them, or try the kdesdk script and see what issues I get with that one (which is rather simplistic compared to the one in kdelibs), or write my own modified script / heavily patch the upstream-provided ones.
14:45:27 <Kevin_Kofler> Rawhide has what I have so far, but the stuff doesn't work well, e.g. it doesn't work at all in KDevelop.
14:46:01 <rdieter> can you contact upstream, and coordinate efforts there too ?  (ie, get feedback, and to get fixes upstreamed, etc...)
14:46:36 <Kevin_Kofler> Hmmm, whom upstream should I talk to?
14:46:50 <Kevin_Kofler> One of the MLs? (Which?)
14:47:01 <rdieter> start with kdecore-devel I guess
14:47:10 <than> Kevin_Kofler: kdecore-devel
14:48:22 <Kevin_Kofler> I also think that to have properly functioning links to Qt documentation, we need to build the apidocs twice (once for HTML, once for QCH) or at least make a copy of the HTML docs to edit the links in.
14:48:52 <Kevin_Kofler> The QtHelp system needs a special syntax to refer to Qt docs in links.
14:48:53 <rdieter> yeah, that's a pain too
14:49:12 <Kevin_Kofler> FWIW, if I use the kdesdk script, that automatically means building the apidocs twice anyway. (It's one of the issues with that script.)
14:49:34 <Kevin_Kofler> The kdelibs script's switch, on the other hand, is not documented anywhere except for one line in the script's --help output.
14:49:53 <Kevin_Kofler> So it seems to have been added as a quick hack and to not be really maintained or supported.
14:50:17 <Kevin_Kofler> (which also explains the bugginess)
14:50:48 <rdieter> Kevin_Kofler: thanks for the update
14:52:39 <rdieter> let's wrap up then, thanks everyone.
14:52:48 <rdieter> #endmeeting