15:03:34 <jreznik> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-01-24
15:03:34 <zodbot> Meeting started Tue Jan 24 15:03:34 2012 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:42 <jreznik> #meetingname kde-sig
15:03:42 <zodbot> The meeting name has been set to 'kde-sig'
15:03:50 <jreznik> #topic roll call
15:04:08 <jreznik> who's here today? waiting for coffee people :)
15:04:11 * rnovacek is here
15:04:21 <rdieter> here
15:04:24 * than is here
15:04:32 * rdieter considers divorce, wife left him with no coffee. :-/
15:05:01 <Kevin_Kofler> Present.
15:05:14 * jreznik does not have any relations issue connected to amount of coffee
15:05:29 <jreznik> #info jreznik rnovacek rdieter than Kevin_Kofler present
15:05:36 <jreznik> #chair jreznik rnovacek rdieter than Kevin_Kofler present
15:05:36 <zodbot> Current chairs: Kevin_Kofler jreznik present rdieter rnovacek than
15:06:04 * ltinkl present
15:06:14 <jreznik> #info ltinkl present too (I can hear you!)
15:06:21 <jreznik> #topic Agenda
15:06:25 * ltinkl typing and sipping
15:07:05 <jreznik> apidocs added
15:07:27 <jreznik> kde 4.8 status :)
15:07:34 <rdieter> yeah
15:08:04 <jreznik> also how far is that fake 4.7.5 effort?
15:08:04 <than> jreznik: gcc-4.7 build status
15:08:52 <rdieter> jreznik: we have a rebuild based in kdelibs-4.7.97 I believe so far
15:09:34 <jreznik> rdieter: but did we issued update?
15:09:43 <rdieter> only in kde-testing I think
15:09:55 <jreznik> ah, ok... so let's start
15:10:02 <jreznik> #topic 4.8.0 status
15:10:22 <Kevin_Kofler> So how about trying to push 4.8 as an official F16 update?
15:10:39 <rdieter> * Tue Jan 03 2012 Lukas Tinkl <ltinkl@redhat.com> - 4.7.4-3 , - update kdelibs to 4.8 RC2 (branded as a 4.7.4 respin)
15:10:40 <Kevin_Kofler> There isn't anything like the big kdepim change last time.
15:11:12 <Kevin_Kofler> The kdelibs update was kinda useless the way it was executed. As I had said back then, it should have gone out as an official update and should already be stable now!
15:11:19 <Kevin_Kofler> We want to push 4.8.0 now, not that.
15:11:36 <Kevin_Kofler> (the whole KDE SC 4.8.0!)
15:11:47 <rdieter> so, looks like 4.8.0 is all imported, mostly built in rawhide, sans kdesdk (antlr problem).  anything else with issues?
15:11:53 * ltinkl checks bodhi
15:12:18 <jreznik> #info 4.8.0 is all imported, mostly built in rawhide, missing kdesdk due antlr problem
15:12:27 <jreznik> #action jreznik to fix kdesdk issue
15:12:45 <rdieter> https://bugzilla.redhat.com/showdependencytree.cgi?id=765955&hide_resolved=1
15:12:50 <rdieter> kde-4.8 blocker ^^
15:13:20 <rdieter> I guess we can remove the kimpanel thing, thats f17+ only
15:13:35 <jreznik> apidocs are next topic...
15:13:48 <Kevin_Kofler> We can also remove the apidocs review from the tracker.
15:13:52 <Kevin_Kofler> That's no requirement for 4.8 at all.
15:14:03 <ltinkl> Kevin_Kofler: you are right, I think we could try to push 4.8 as an F16 update
15:14:10 <Kevin_Kofler> And IMHO the review should just be closed NOTABUG, but that's the next topic. Either way, it's unrelated to 4.8.
15:14:16 <rdieter> apidocs is more of a nice-to-have, sure
15:14:29 <jreznik> rdieter: yep
15:14:38 <Kevin_Kofler> The configuration migration issues are the only blockers left.
15:14:41 <ltinkl> so what do others think about KDE 4.8 -> F16?
15:14:52 <jreznik> for 4.8 and f16 - there are some package renames, some more splits...
15:15:02 <rdieter> its doable, though there's a lot of packaging changes
15:15:08 <Kevin_Kofler> I think we should build it now, get it out to testing, and work out some configuration update scripting for the 2 blockers.
15:15:41 <rdieter> personally, the old fogey in me says wait for 4.8.1
15:15:43 <jreznik> let's aim on f17 & 4.8.0 - later we can see if we want the burden with f16 update or not
15:15:55 <Kevin_Kofler> I don't see a lot of packaging changes… kdeutils got split, but it was already split into subpackages, they're just built separately now.
15:16:06 <than> we need to test well (because of many changes in rename7splitting) if we want to update KDE 4.8 fot f16
15:16:09 <Kevin_Kofler> kdeaccessibility, OK, but most people don't even have that installed.
15:16:16 <rdieter> and pkg renames
15:16:24 <Kevin_Kofler> And besides the splits are not a big change now that other stuff is split, too.
15:16:27 <rdieter> kde-baseapps, kde-runtime, kde-workspace
15:16:35 <rdieter> pykde4
15:16:39 <Kevin_Kofler> Well, those, we should have already done in F16 GA really.
15:16:53 <Kevin_Kofler> (They were already renamed upstream in 4.7. So the renaming is a bugfix. :-p )
15:17:00 <jreznik> it's really not a big
15:17:38 <ltinkl> I'm for seeing 4.8.x in F16 definitely
15:17:39 <Kevin_Kofler> I don't see any practical reason for waiting (and even less for not updating at all).
15:17:50 <rdieter> so, compromise short-term, similar to how we did a f15/kde47 repo, I'll make a f16/kde48 one
15:17:58 <ltinkl> after thorough testing, maybe with 4.8.1
15:18:13 <rdieter> ltinkl: yeah
15:18:13 <ltinkl> but I wouldn't want to wait for F17
15:18:16 <Kevin_Kofler> kdepim, and KMail in particular, is supposed to be a lot better in 4.8 than 4.7.
15:18:24 <ltinkl> Kevin_Kofler: yup
15:18:36 <ltinkl> if only for the kdepim improvements
15:19:08 <rnovacek> Kevin_Kofler: that's right, kmail is usable (for me) in 4.8
15:19:20 <rdieter> while we're on the 4.8 topic, anyone know how ksecrets-4.8.0 fits in packaging-wise ?
15:19:30 <ltinkl> f16/kde48 repo sounds like a good compromise, later targetting official updates with 4.8.1
15:19:32 <rdieter> I meant to poke upstream yesterday, but didn't
15:19:39 <than> ltinkl: +1
15:19:45 <Kevin_Kofler> So let's vote: Proposal 1: get 4.8.0 into testing ASAP, decide based on testing feedback how to proceed. Proposal 2: Wait for 4.8.1. Proposal 3: No official update, kde48 repo only.
15:19:51 <Kevin_Kofler> My preference is 1 > 2 > 3.
15:20:00 <rdieter> 2 +1
15:20:04 <ltinkl> 2 +1
15:20:17 <Kevin_Kofler> Any concrete reasons for waiting?
15:20:18 <than> 2 +1
15:20:30 <than> Kevin_Kofler: need more time for testing
15:20:40 <Kevin_Kofler> The 2 config migration blockers, I doubt upstream will care (sadly), it's our job to fix those, and we can do that while it's in testing.
15:20:41 <ltinkl> Kevin_Kofler: I think the upgrade issues and pkg renaming warrant some testing
15:20:51 <jreznik> I don't see a reason to wait, 4.8 is ok (except the migration problem)
15:20:56 <jreznik> so I'm +1 for both 1 and 2
15:21:00 <rnovacek> 1 +1
15:21:02 <Kevin_Kofler> than, ltinkl: Testing is what updates-testing is for.
15:21:15 <rnovacek> and wait only if something goes wrong
15:21:16 <ltinkl> uhm, ye, not totally opposed :)
15:22:18 <ltinkl> otoh, if we put it into updates-testing: no extra work with separate repo
15:22:32 <jreznik> #agreed to import kde 4.8.x to F16 (proposal 1: 4.8.0 and fix blockers, 2: wait for 4.8.1)
15:22:35 <ltinkl> and we can withdraw it from there if needed or wait until we fix the issues
15:22:42 <rdieter> ltinkl: it won't be much work, the hard part is doing the builds, which are already done and in kde-unstable
15:22:58 <jreznik> ltinkl: it can block 4.7 fixes while in bodhi and updates-testing
15:23:11 <ltinkl> right
15:23:50 <Kevin_Kofler> It's possible to build emergency fixes from a git branch, but getting them through Bodhi can be a mess with the auto-obsoletion crap (which sadly got reenabled because of idiot packagers who push ancient versions to stable after the latest).
15:24:32 <jreznik> so I'd prefer not to mess bodhi at least before we're sure it's nearly shippable state
15:25:09 <Kevin_Kofler> (fedpkg didn't work to build from a git sub-branch last I checked, but running the Koji command-line directly did :-p )
15:26:38 <rdieter> at this point, i would be way too nervous to drop 4.8.0 into f16 updates-testing, I'm a semi-firm :)   -1 to prop 1
15:26:42 <Kevin_Kofler> (Koji takes any git hash you pass it, it doesn't care what branch it comes from. :-p )
15:28:40 <Kevin_Kofler> How about proposal 1.5: get 4.8.0 built completely for Rawhide, wait a couple days for feedback, then decide about F16 updates-testing?
15:29:04 <jreznik> +1
15:29:29 <rdieter> I'd only consider it after the blockers are cleared
15:29:37 <rnovacek> +1
15:29:53 <rdieter> so, conditional +1 I guess
15:30:03 <jreznik> especially that migration ones
15:30:30 <jreznik> than: ?
15:30:33 <rdieter> I'll retest the powerdevil thing, I'm hoping that's fixed now
15:30:46 <ltinkl> +1
15:30:50 <ltinkl> rdieter: what issue?
15:30:51 <rdieter> fun, getting to downgrade back to 4.7.x , and restore my old profile.
15:30:57 <Kevin_Kofler> Yeah, I guess we need to look into these. I'll have a look, no promises though. If you can come up with a fix, don't wait for me. :-)
15:31:31 <rdieter> ltinkl: my power settings were weird and not all working after upgrading to 4.7.97 initially.  most notably, closing laptop lid => nothing. it was supposed to sleep
15:31:55 <jreznik> so I think we agreed on the roadmap for update
15:31:58 <than> Kevin_Kofler: +1 for 5
15:32:52 <rdieter> would be nice for someone to advertise/blog about our roadmap and plans here.
15:33:01 <jreznik> #agreed to to build 4.8.0 completely for rawhide, wait until it settles down/testing + fix migration issues and then do the final decision if we want to proceed
15:33:20 <jreznik> rdieter: I'll put it to minutes, I can blog about it too
15:33:29 * rdieter will try too
15:33:49 <Kevin_Kofler> OK, next topic please?
15:33:52 <jreznik> yep
15:33:57 <jreznik> #topic apidocs
15:34:40 <Kevin_Kofler> So one more thing I thought of today: If the API documentation is licensed under the GPL or LGPL (and I think it is, being derived from (L)GPL code), we must ship the exact corresponding source code to comply with the license.
15:34:47 <rdieter> .bug 783483
15:34:49 <rdieter> related
15:34:49 <zodbot> rdieter: Bug 783483 Review Request: kdelibs-apidocs - KDELibs API documentation - https://bugzilla.redhat.com/show_bug.cgi?id=783483
15:35:00 <Kevin_Kofler> So repackaging pregenerated documentation which may or may not match the source tarballs we ship does not comply.
15:35:28 <rdieter> apidocs is GFDL
15:35:58 * rdieter admits to not being familiar with gfdl
15:36:24 <Kevin_Kofler> Sure? If it is, it's probably fine to ship them as is, the FDL doesn't have a notion of "source code", but of a "transparent format", which HTML undoubtedly is.
15:36:48 <jreznik> #link http://en.wikipedia.org/wiki/GNU_Free_Documentation_License
15:36:50 <rdieter> not 100%, just going off http://techbase.kde.org/Policies/Licensing_Policy
15:37:11 <rdieter> about Documentation.  not 100% if that applies to apidocs or not
15:37:45 <rnovacek> those qchs are sqlite I think
15:37:51 <rdieter> should I ask for clarification ?
15:38:00 <jreznik> #info the concerns are - what's the license of api documentation? in case of gpl/lgpl there's the problem with source redistribution
15:38:12 <jreznik> rdieter: probably the best approach to ask for clarification
15:38:20 <rdieter> ok
15:38:32 <than> rdieter: yes should ask for clarification
15:38:41 <jreznik> #action rdieter to ask upstream for clarification
15:38:42 <Kevin_Kofler> rnovacek: The QCH is fine because there's corresponding HTML shipped.
15:38:44 <rdieter> Kevin_Kofler: we do ship all the sources though, what's theproblem ?
15:39:14 <Kevin_Kofler> rdieter: The GPL doesn't allow shipping binaries of version X with sources of version Y.
15:39:24 <Kevin_Kofler> The binaries must match the sources exactly.
15:39:54 <Kevin_Kofler> (And that's exactly what packaging the apidocs separately doesn't guarantee, and why I don't like the idea.)
15:40:03 <rdieter> I mean, if that's a problem really, no one could redistribute what api.kde.org provides.
15:40:17 <rdieter> which would in the least, be silly
15:40:59 <rdieter> but I'll ask regardless
15:41:14 <rdieter> Kevin_Kofler: were there other concerns?
15:41:56 <Kevin_Kofler> I already voiced my other concerns on the chan…
15:42:28 <Kevin_Kofler> Oh, well, one more: If upstream uses a buggy Doxygen, we can't just fix Doxygen, we have to get upstream to rebuild their stuff with a fixed Doxygen too…
15:42:40 <rdieter> so, anything else you'd like to document in the meeting minutes?
15:43:04 <Kevin_Kofler> We depend on upstream for fixing, which is really the same thing as with binary drivers or other binaries. :-/
15:43:36 <rdieter> we can always keep the option to rebuild -apidocs ourselves, in need be.
15:44:04 <Kevin_Kofler> The other concerns: Qt documentation links don't point to the local Qt docs (but that's broken in our current kdelibs-apidocs builds too, and the upstream ones could be fixed with sed), backports are not reflected in the docs (but some of you said that's a feature).
15:44:26 <Kevin_Kofler> And I had some doubts about the compliance of this with Fedora guidelines, but it seems it is compliant.
15:44:59 <Kevin_Kofler> So, any vote: do we want to package *-apidocs from upstream tarballs?
15:45:05 <Kevin_Kofler> And I vote -1, i.e. no.
15:45:39 <rdieter> ok, we can do so formally.
15:45:44 <rdieter> +1
15:46:00 <rnovacek> +1
15:46:02 <Kevin_Kofler> (I should clarify: from upstream pregenerated tarballs. Building from upstream source tarballs is what we did so far and I'm fine with that. ;-) )
15:46:43 <jreznik> what about that options to build it by ourselves when needed?
15:47:11 <rdieter> jreznik: that's basically the 'apidocs' macro 0/1 set in kdelibs/kdepimlibs so far
15:47:13 <Kevin_Kofler> jreznik: I guess the proposal there is to just run Doxygen by hand and tar it up…
15:47:56 <rdieter> but could do it Kevin_Kofler's way too, implementation probably doesn't matter at this point
15:48:22 <Kevin_Kofler> Oh sure, we could also reenable the apidocs flag when we feel like it, and thus create a "dual-homed" package like what Perl is doing for some modules shipped with upstream Perl now, but IMHO that's a very ugly hack.
15:48:40 <rdieter> Kevin_Kofler: I didn't say it would be pretty.
15:48:48 <Kevin_Kofler> A given package name should not be produced by different SRPMs at the same time, that's quite silly.
15:49:26 <rdieter> but I'd still argue the implementation on how to do it doesn't really matter.  Point is, doing it ourselves is still an option if needed
15:49:57 <rdieter> when/if the time comes, we can decide then on how best to do it
15:50:21 <Kevin_Kofler> So? than, ltinkl, jreznik? For or against rdieter's plan?
15:50:51 * than votes -1 for this plan
15:51:34 * jreznik is really not sure, I understand the reason behind it...
15:51:49 * rdieter knows why Kevin_Kofler is -1, why than?
15:51:56 <rdieter> same reasons?
15:52:11 <jreznik> rdieter: let's check the license first
15:52:18 <than> 1 licese is not clear
15:52:20 <jreznik> then we can finally decide
15:52:38 <rdieter> ok, voting is premature then.  licensing is obviously a blocker
15:52:56 <than> 2. upstream api-doc is out of date
15:53:07 <jreznik> #info licensing is a blocker for formal vote
15:53:38 <rdieter> than: fyi, upstream apidocs get regenerated fresh almost daily.
15:54:27 <than> rdieter: and if it's broken
15:55:01 <rdieter> besides, apis (for stable) releases, should hardly ever change.
15:55:02 <than> and we cannot fix it from ourself
15:55:42 <rdieter> but lets move on, we'll decide later when licensing is sorted out
15:56:05 <Kevin_Kofler> Right, next topic please.
15:56:59 <rdieter> fwiw, it would appear debian also uses upstream apidocs (and doesn't generate them)
15:57:48 <jreznik> #topic gcc 4.7 fixing status
15:58:35 <Kevin_Kofler> So, legacy stuff (*3) is hit badly, I'm going to look into it.
15:58:50 <Kevin_Kofler> Some non-legacy stuff is also broken.
15:59:09 <jreznik> #info gcc 4.7 template subst. regression already fixed
15:59:21 <than> Kevin_Kofler: kdelibs3 build is done
16:00:02 <than> do we have a list of packages which have gcc-4.7 build issue?
16:00:46 <rdieter> kdebase3
16:00:48 <than> qtwebkit is fixed and still bulding in koji
16:00:56 <rdieter> kdepim3
16:00:58 <Kevin_Kofler> PyKDE (3) is also broken.
16:01:18 <rdieter> might be a good excuse to retire PyKDE(3)
16:01:33 <Kevin_Kofler> I'll try to fix them all.
16:01:33 <than> rdieter: +1 for retire PyKDE(3)
16:01:38 <rdieter> only the venerable kflickr uses it
16:01:53 <rdieter> Kevin_Kofler: go for it if you want. :)
16:01:58 <Kevin_Kofler> I think it shouldn't be too hard to get it to work.
16:02:16 <Kevin_Kofler> So far we haven't even excluded that it's a bug in the non-obsolete sip. :-)
16:02:53 <Kevin_Kofler> Oh, and here's the complete list of failures (including non-KDE stuff too, obviously): http://ausil.fedorapeople.org/f17-failures.html
16:03:18 <jreznik> so try it and we can remove in case of fixing difficulties
16:03:24 <jreznik> we are over time :)
16:03:28 <than> Kevin_Kofler: yes i already saw it
16:03:39 <jreznik> -> #fedora-kde
16:03:45 <jreznik> thanks guys
16:04:03 <jreznik> #endmeeting