15:01:26 <rdieter_work> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-03-01
15:01:26 <zodbot> Meeting started Tue Mar  1 15:01:26 2011 UTC.  The chair is rdieter_work. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:31 <rdieter_work> #topic roll call
15:01:48 * jreznik is here
15:01:53 * ltinkl is here
15:01:56 <Kevin_Kofler> Present.
15:01:59 * rnovacek is present
15:02:02 <rdieter_work> hi ho, who's present today?  than, than_home, thomasj_, SMParrish, kde*foo: ping
15:03:36 <rdieter_work> #info rdieter_work, jreznik, ltinkl, Kevin_Kofler, rnovacek present
15:03:43 <rdieter_work> #chair jreznik ltinkl Kevin_Kofler rnovacek
15:03:43 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter_work rnovacek
15:03:58 <rdieter_work> #topic agenda topics
15:04:14 <rdieter_work> I threw kde-4.6.1/qt-4.7.2 on the agenda, anything else to hit today?
15:04:35 * rdieter_work will reserve time for kdepim-4.6.x if cwickert stops by
15:06:07 <jreznik> nothing from me, so let's start
15:06:10 <ltinkl> I'd start with the Qt update
15:06:23 <rdieter_work> ok
15:06:39 <rdieter_work> #topic Qt 4.7.2
15:07:12 * thomasj_ here, late, sorry
15:07:16 <rdieter_work> jreznik did some initial import work, and I cleaned up a few things, and it's ready to build now.  I'll push it and get a rawhide building soonish
15:07:24 <ltinkl> http://qt.nokia.com/developer/changes/changes-4.7.2/
15:07:28 <ltinkl> FYI
15:07:58 <jreznik> rdieter_work: thanks, sorry for the mess :) fuzz fixed in my .rpmmacros
15:08:22 <rdieter_work> a topic I brought up in #fedora-kde a bit earlier, was that I was thinking of simplifying the .spec a bit, and first item was removing the option to build with qt's internal copy of phonon.
15:08:39 <jreznik> #info jreznik and rdieter imported qt 4.7.2, it's ready to build
15:08:47 <Kevin_Kofler> Any news from the KDE patches side? AFAIK, the KDE Qt copy was moved to git.kde.org, but I have no idea whether there's anything new there.
15:08:49 <rdieter_work> by all accounts, qt 4.8's modularization will likely remove that anyway
15:09:22 <rdieter_work> Kevin_Kofler: afaik, there's no kde patches currently (from overhearing some discussion on #kde-devel the other day)
15:09:24 <jreznik> and open governance is one of 4.8 targets (finally)
15:09:48 <thomasj_> wow, most fixed bugs are for symbian
15:10:59 <Kevin_Kofler> Re dropping support for builtin Phonon, IMHO that's fine.
15:10:59 <jreznik> rdieter_work: if you can work on it - go for
15:11:15 <Kevin_Kofler> But yes, it could make bootstrapping secondary arches harder.
15:11:48 <Kevin_Kofler> But you know how much I care about those… (not at all, considering none of them has anything remotely current to release, after several months).
15:11:49 <rdieter_work> ah, bootstrapping, I'm pretty sure one can do an initial bootstap by omitting phonon (and webkit) support, then do phonon, then rebuild against that
15:12:16 <rdieter_work> but I'll take care of that mess when/if it ever happens]
15:13:00 <rdieter_work> oh nvm, I think even if we don't include phonon, it gets built anyway (we just don't package it)
15:13:19 <rdieter_work> either way, shouldn't be a problem. :)
15:14:02 <rdieter_work> #action rdieter_work will queue qt-4.7.2 builds after meeting
15:14:49 <rdieter_work> #action rdieter_work will work on .spec cleanup/simplification, first up: drop option to package qt/internal phonon
15:15:06 <rdieter_work> anything else?
15:15:54 <ltinkl> are we planning to put this into F14?
15:16:02 <Kevin_Kofler> Yes.
15:16:10 <Kevin_Kofler> F14 shipped with 4.7.x, it's a bugfix release.
15:16:22 <jreznik> yep, F14
15:16:23 <rdieter_work> I'd think so, let's plop it into kde-testing for a bit first
15:16:28 <thomasj_> +1
15:17:01 <rdieter_work> ltinkl: were you just curious, or do you have any reservations?
15:17:10 <ltinkl> no, ust being curious
15:17:11 <Kevin_Kofler> Why not into updates-testing directly?
15:17:18 <rdieter_work> Kevin_Kofler: probably can
15:17:18 <Kevin_Kofler> Testing is what updates-testing is for!
15:17:29 <ltinkl> agree, straight to updates-testing
15:17:47 <rdieter_work> with big stuff like this, I often feel better testing the build on a box or 2 of my own first, but meh.
15:18:09 <rdieter_work> alright, moving on...
15:18:14 <rdieter_work> #topic KDE 4.6.1
15:18:15 <thomasj_> I'm for a couple days in kde-testing first. just make sure no show-stopper is waiting
15:18:21 <jreznik> rdieter_work: but that's updates-testing is something for :)
15:18:40 <Kevin_Kofler> thomasj_: What do you think updates-testing is for? :-)
15:19:07 <thomasj_> Kevin_Kofler, for testing stuff. But as a maintainer i test it first on my box. therefore kde-testing +1
15:19:27 <Kevin_Kofler> So jriddell is warning on kde-packager that kfind (the "Find files/folders" feature) is missing from 4.6.1. :-/
15:19:36 <rdieter_work> I think we've got most of KDE 4.6.1 imported, built.  there's still a few problems with the kdebase tarball by the looks of it (it includes konq-plugins, and omits kfind), and kdesdk (omits lokalize)
15:20:15 <ltinkl> what about the wallpapers? previously in kdebase-workspace
15:20:15 <rdieter_work> and kde-l10n, than was working on that, not sure if it got built yet or not
15:20:23 <rdieter_work> wallpapers are present
15:20:28 <ltinkl> ok
15:20:53 <jreznik> are there rawhide builds? I see only f15 ones
15:21:00 <rdieter_work> so, probably want to wait for the tarball issues to be sorted out before doing any f14 builds
15:21:07 <rdieter_work> jreznik: I just did f15
15:21:31 <rdieter_work> mostly to save cpu/space for koji
15:22:11 <rdieter_work> if that's a problem, can certainly do rawhide builds too
15:22:32 <jreznik> I'd like to have rawhide builds
15:22:39 <Kevin_Kofler> I think we should really be doing Rawhide builds after the mass branch.
15:23:04 <Kevin_Kofler> Especially for things like this where the F15 ones may take a while to go stable.
15:23:07 <rdieter_work> ok, will do so for future builds
15:23:12 <jreznik> or I can downgrade to clean f15 - just 4.6.1 should bring the patch I need to finish kde systemd agent
15:23:33 <ltinkl> :)
15:23:34 <rdieter_work> reminds me, need to setup f15 kde-redhat repos
15:23:55 <jreznik> ltinkl: I hope it's there :)
15:23:59 <jreznik> btw. thanks
15:24:03 <ltinkl> jreznik: how's the system agent coming along?
15:25:05 <jreznik> ltinkl: it should be easy to finish it now
15:25:20 <jreznik> I spent a lot time trying to figure out why the hell it does not work :)
15:25:24 <rdieter_work> anything else wrt kde-4.6.1 ?
15:25:30 <ltinkl> Lennart's systemd presentation at the Redhat/Fedora Devel Conf last week turned into a disaster :D
15:25:53 <rdieter_work> oh noes
15:26:43 <rdieter_work> moving on...
15:26:49 <ltinkl> yup
15:26:51 <rdieter_work> #topic open discussion
15:27:16 <jreznik> ltinkl: but his presentation won the internal poll for best talk:)
15:27:33 <rdieter_work> fyi, I've been doing some side-work getting kde-4.5.5 built for f13/arm
15:27:47 <Kevin_Kofler> What went wrong there? (I missed that presentation.)
15:28:10 <ltinkl> ye I'm sure everyone had fun... dunno how will people feel when systemd hits F15
15:28:12 <rdieter_work> it's slow going, but making good progress, hit the qreal != double problem that #kubuntu folks mentioned (using a patch of theirs for PyQt4)
15:28:45 <rdieter_work> kdeedu seems to have a similar problem, that's still a todo item
15:29:39 <Kevin_Kofler> It's quite silly to have ARM use a different floating point precision than the rest of the world. :-/
15:29:41 <rdieter_work> ltinkl: my brain hurts everytime packaging committee reviews the systemd packaging guidelines
15:29:53 <Kevin_Kofler> No wonder this breaks apps all over the place.
15:30:16 <ltinkl> Kevin_Kofler: arm does have some floating precision at all?
15:30:16 <rdieter_work> Kevin_Kofler: true, but the problem here is that it's exposing apps that mix-n-match qreal and double (ie, use one *or* the other consistently)
15:30:48 <Kevin_Kofler> ltinkl: Well, AFAIK, double is done in software, float is sometimes supported in hardware, sometimes in software.
15:31:01 <Kevin_Kofler> (And even when it's in software, it's faster because there's less to compute.)
15:31:39 <Kevin_Kofler> rdieter_work: Well, with Qt APIs using qreal and the rest of the world using double, what do you expect?
15:32:00 <Kevin_Kofler> All the math software around uses double, at least by default.
15:32:14 <rdieter_work> the breakage so far has been code all internal to kde apps/bindings
15:32:43 <rdieter_work> I'm sure there's probably other places...
15:33:19 <thomasj_> I tested kdepim (especially kmail2 & co) yesterday and today. I still think it's the right decision to have 4.4.x in F15. No matter what cwickert might have to report. Update from 4.4.x to 4.5.94 fails miserable here. Means it's needed to remove rc' to get it running after the update.
15:33:29 <thomasj_> Might of course be just here on my box, though..
15:33:32 <rdieter_work> #info rdieter_work been working slowly getting kde stack going for seconary arch f13/arm
15:34:07 <Kevin_Kofler> thomasj_: If I understood correctly, cwickert said migration has just been implemented in master and will be in the next prerelease.
15:34:17 <thomasj_> Another thing is the huge icon problem not fixed yet.
15:34:23 <rdieter_work> #info cwickert offered to report back to kde-sig about recent kdepim meetnig, about 4.6.x viability and release schedule
15:34:24 <thomasj_> knode ^^
15:34:26 <Kevin_Kofler> i.e. it's expected that it doesn't work in 4.5.94, it should work in the next prerelease.
15:34:58 <Kevin_Kofler> (which will be a RC rather than a Beta, IIRC)
15:35:09 <ltinkl> I still think it'd be safer to wait with this for F16
15:35:11 <rdieter_work> #info jreznik working on a kde systemd agent
15:35:46 <thomasj_> Yeah, kdepim-4.7 better with F16
15:36:06 <Kevin_Kofler> I think it'll end up like K3b where all the other distros will be shipping the new kdepim and we'll be the only ones stuck on the old one. :-(
15:36:23 <Kevin_Kofler> What happened to our "First" principle?
15:36:23 <thomasj_> Then we will have the only happy users ;)
15:36:30 <rdieter_work> Kevin_Kofler: :(  hopefully kdeipm won't give us mixed messages this time
15:36:31 <Kevin_Kofler> I miss Fedora 9!
15:37:30 <Kevin_Kofler> rdieter_work: Well, they already are, aren't they? ;-(
15:37:52 <rdieter_work> Kevin_Kofler: my converstations with upstream have always been fairly consistent (4.6 isn't ready)
15:37:56 <Kevin_Kofler> Somebody at kdepim upstream told you to ship 4.4, now other folks told cwickert that we should ship 4.6.
15:38:03 <rdieter_work> so far, at least until cwickert dropped in the other day
15:38:08 <cwickert> hi
15:38:12 <ltinkl> xD
15:38:13 <thomasj_> IMAP acts still a little strange. Popup' about strange errors.. There's a lot to do.
15:38:18 <Kevin_Kofler> cwickert: Hi.
15:38:23 <thomasj_> hi cwickert
15:38:24 <rdieter_work> hi!
15:38:41 <rdieter_work> cwickert: do you have a moment give a report about the recent kdepim meeting?
15:38:49 <cwickert> sure
15:38:55 <rdieter_work> #topic kdepim meeting
15:38:57 <rdieter_work> thanks
15:39:22 <cwickert> ok, the kdepim meeting was both a lot of fun and work
15:39:40 <cwickert> my primary question was what they think about kdepim 4.6
15:39:55 <cwickert> the rc is going to be released on march 2nd
15:40:03 <cwickert> and the final on april 5th
15:40:13 <cwickert> together with kde 4,6,2 IIRC
15:40:26 <Kevin_Kofler> March 2nd is tomorrow.
15:40:35 <cwickert> yes
15:40:53 <cwickert> so IHMO it should be possible to include kdepim 4.6 in Fedora, although the schedule is tight
15:41:06 <cwickert> especially as april 5th is our beta release
15:41:19 <cwickert> regarding stability
15:41:24 <rdieter_work> #info kdepim 4.6 rc release planned for mar 2, final apr 15 (approx same time as kde 4.6.2)
15:41:40 <cwickert> 5th, not 15th
15:41:47 <rdieter_work> #undo
15:41:47 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2b025cc7edd0>
15:41:56 <rdieter_work> #info kdepim 4.6 rc release planned for mar 2, final apr 5 (approx same time as kde 4.6.2)
15:41:58 <rdieter_work> better. :)
15:42:00 <cwickert> :)
15:42:17 <Kevin_Kofler> Looks like rdieter was already pessimisticly adding some slip time. ;-)
15:42:23 <cwickert> from the stability POV kmail 2 is better than any kmail one release
15:42:30 <cwickert> the big question is the data migration
15:42:40 <cwickert> there is a migration path and it works
15:42:49 <cwickert> migration should work in 95% of all cases
15:43:10 <cwickert> but some corner cases might not work, e.g. if sombody interrupts the migration
15:43:27 <cwickert> you can still have your old data around if you like
15:43:37 <cwickert> it will be shown as a separate account
15:43:58 <cwickert> there will be another akonadi provider for maildir then
15:44:09 * rdieter_work likes the sound of that
15:44:22 <cwickert> so if we make this behavior the default, we should be on the save side
15:44:47 <cwickert> but nevertheless, there will be some people, that will complain that the data migration failed for them
15:45:00 <cwickert> this requires a paragraph in the release notes
15:45:12 <cwickert> ok, questions?
15:45:37 <thomasj_> I don't trust the sound of that. I want to test the RC first :)
15:45:37 <ltinkl> what about the other kdepim apps? knode, kaddrbook
15:45:57 <ltinkl> how does korganizer work with akonadi?
15:46:00 <rdieter_work> cwickert: on the topic of stability, was the response generally unanimous?
15:46:21 <rdieter_work> last I spoke with awinterz, he had some serious reservations...
15:46:29 <cwickert> rdieter_work: yes, they all are very convinced of the new stuff
15:46:34 <Kevin_Kofler> The main problem we have is that we just reverted the Alpha to 4.4, because everyone except me thought there'd be no way it'd be ready in time.
15:46:40 <rdieter_work> but that was mostly about data migration...
15:47:01 <rdieter_work> yeah, the timing is a bit unfortunate.
15:47:08 <cwickert> ltinkl: AFAIK it does work fine, I'm using an e5 build and have no problems
15:47:15 <ltinkl> I don't see the need to rush it in
15:47:35 <rdieter_work> cwickert: I thought the e5 builds generally weren't akonadi'ized yet?  has things changed?
15:47:37 <Kevin_Kofler> ltinkl: Fedora is about shipping leading-edge stuff first.
15:47:56 <ltinkl> not bleeding tho
15:47:58 <Kevin_Kofler> If there's a new release from upstream, and it sounds like it'll really be released in time, we should ship it.
15:47:58 <thomasj_> leading-edge != breaking-edge ;)
15:48:19 <rdieter_work> cwickert: on the enterprise topic, is there any recommendation or interest in us shipping enterprise builds?
15:48:39 <cwickert> rdieter_work: e5 is fully akonadi'ized, it's trunk except it doesn't build against kdelibs from trunk but the latest stable versions and it has some enterprise buid options, e.g. for outlook compatibility
15:49:31 <cwickert> ltinkl: it doesn't eat your mail or calendar any longer, if this is what you call bleeding
15:50:05 <cwickert> rdieter_work: sure, I as a kolab systems person would like to see the whole world using enterprise builds ;)
15:50:20 <jreznik> do we have current builds? I can try it on my imap folder :)
15:50:41 <rdieter_work> cwickert: ok, mind if we talk a bit more about that after the meeting? if you have time...
15:50:42 <cwickert> if Fedora is not shipping kdepim 4.6.0, Kolab Systems will
15:50:50 <ltinkl> I'd say put it in kde-unstable and let the interested people test it
15:50:50 <Kevin_Kofler> I think the big problem with the "ask upstream whether they think their stuff is ready" approach is that the answer you get depends on whom you ask, what you ask and when you ask.
15:51:08 <cwickert> rdieter_work: pretty busy, I need to release kolab 2.3 today because it's CeBIT
15:51:28 <rdieter_work> cwickert: ok, any other time is fine, ping me when you have a chance then.
15:51:30 * than is now present
15:51:34 <cwickert> rdieter_work: ok
15:51:35 <Kevin_Kofler> Re the "when", I think people tend to be more positive at development meetings than on end-user-oriented mailing lists.
15:51:40 <ltinkl> than: hi :)
15:51:41 <Kevin_Kofler> Even if it's the same developer…
15:51:53 <cwickert> Kevin_Kofler: sure
15:51:54 <Kevin_Kofler> It's weird, but it's not the first time I observe this.
15:52:11 <cwickert> well, everybody was very enthusiastic
15:52:25 <cwickert> but again, we are already using this stuff
15:52:26 <rdieter_work> ltinkl: I agree, when kdepim-4.6rc becomes available, let's get some test builds asap, and reserve judgement for ourselves
15:52:36 <ltinkl> rdieter_work: definitely
15:52:39 <cwickert> and many developers say that we need a public test now
15:52:40 <rdieter_work> if it truly does work as well as reported, then yay.
15:52:47 <Kevin_Kofler> In any case, my vote is for undoing the reversion.
15:52:57 <cwickert> in fact they already want a big public test since october last year
15:53:07 <Kevin_Kofler> If we do that, we'll have bumped Epoch needlessly, but at least we won't be shipping obsolete crap.
15:53:12 <ltinkl> let's go with the conservative kdepim 4.4 and see how 4.6rc works out
15:53:31 <rdieter_work> Kevin_Kofler: at least the epoch-related bugs are fixed now. :)
15:53:35 <Kevin_Kofler> ^^
15:53:35 <cwickert> come on, Fedora is supposed to be leading edge
15:53:53 <cwickert> even if kdepim is broken, people will remember F15 for the broken GNOME desktop ;)
15:53:59 <thomasj_> I want to see 4.6rc first as well
15:54:00 <rdieter_work> lol
15:54:00 <jreznik> cwickert: :)
15:54:03 <ltinkl> cwickert: fine with that, we just don't want to ship something that's broken :)
15:54:08 <Kevin_Kofler> We should really get the 4.6 RC into Rawhide immediately after release and into F15 ASAP (i.e. as soon as we get it through the Bodhi bureaucracy).
15:54:21 <cwickert> ltinkl: I understand your concerns
15:54:31 <ltinkl> Kevin_Kofler: fine with putting it into rawhide
15:54:35 <jreznik> cwickert: but last time we called people to test it, it was disaster
15:54:36 <cwickert> +1
15:54:38 <Kevin_Kofler> ltinkl: As I said, at least it'd get us some press. :-)
15:54:39 <rdieter_work> Kevin_Kofler: something close to that sure.  get some intermediate testing in between rawhide and f15, and we agree.
15:54:45 <ltinkl> that's where bleeding edge belongs to imho
15:54:59 <cwickert> if we do it, we really need to test is. perhaps even do a test day
15:55:13 <rdieter_work> for press, all we need to do is ban some $random pkg from fedora . :)
15:55:29 <jreznik> rdieter_work: kernel?
15:55:33 * ltinkl points at jreznik
15:55:35 <ltinkl> :D
15:55:50 <rdieter_work> cwickert: good idea, will look to do so
15:55:51 <cwickert> ok, then how about: bring 4.6 to rawhide ASAP and test it, but *really* test it I mean
15:56:06 <rdieter_work> cwickert: agreed 100%
15:56:13 <ltinkl> cwickert: question is, who's gonna test rawhide?
15:56:14 <jreznik> cwickert: what does it mean "really test it"?
15:56:28 <jreznik> ltinkl: kde-* repos works here
15:56:30 <cwickert> I mean, I'd like to test it too, otherwise you'll always blame me. I am just the messenger here
15:56:32 <rdieter_work> testing = rawhide users, + test kde-unstable builds
15:56:48 <ltinkl> fine with kde-unstable
15:56:55 <jreznik> cwickert: as I said - we had several "test calls"
15:57:01 <ltinkl> those who want can enable it
15:57:05 <cwickert> jreznik: we should have all of us using it and we need to collect data on if the migration worked etc.
15:57:14 <cwickert> jreznik: I must have missed them
15:57:25 <jreznik> cwickert: and we weren't happy with it (not test days)
15:57:32 <jreznik> with results
15:57:44 <rdieter_work> #info when kdepim-4.6rc is release, will import into rawhide, and do f14/f15 builds for kde-unstable too, and *test* *test* *test*
15:57:46 <cwickert> ltinkl: why not rawhide?
15:57:50 <jreznik> maybe it's time for another round
15:57:54 <rnovacek> https://fedoraproject.org/wiki/SIGs/KDE/F15Features/KDEPIM46QA
15:57:59 <Kevin_Kofler> Rawhide should definitely have 4.6.
15:58:08 <Kevin_Kofler> F16 is not going to ship 4.4 for sure!
15:58:09 <rdieter_work> rawhide already has it, fyi.
15:58:13 <ltinkl> cwickert: I meant both, rawhide and kde-unstable
15:58:25 <ltinkl> Kevin_Kofler: yup
15:58:41 <cwickert> ltinkl: I see
15:58:47 <jreznik> rnovacek: thanks, these are only a few results, other can be found in ml
15:58:49 <rdieter_work> cwickert: thanks for the report and feedback
15:59:00 <cwickert> rnovacek: thanks for sharing that link. we should repeat the same with more testers
15:59:05 <cwickert> np rdieter_work
15:59:18 <ltinkl> time is closing in
15:59:30 <rdieter_work> sure, our time's up, thanks everyone!
15:59:36 <rdieter_work> #endmeeting