14:04:25 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-20
14:04:25 <zodbot> Meeting started Tue Jul 20 14:04:25 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:31 <rdieter> #meetingname kde-sig
14:04:31 <zodbot> The meeting name has been set to 'kde-sig'
14:04:37 <rdieter> #topic roll call
14:04:43 <rdieter> who's present today?
14:05:09 * rnovacek here
14:06:14 <rdieter> than, Kevin_Kofler, jreznik, SMParrish : ping
14:06:25 <Kevin_Kofler> Present.
14:06:28 * than is present
14:06:43 * SMParrish here
14:07:25 <rdieter> #chair Kevin_Kofler than SMParrish rnovacek
14:07:25 <zodbot> Current chairs: Kevin_Kofler SMParrish rdieter rnovacek than
14:07:37 <rdieter> #info rdieter rnovacek Kevin_Kofler than SMParrish present
14:07:46 * jreznik is here
14:07:57 <rdieter> #info jreznik also present
14:08:02 <rdieter> #chair jreznik
14:08:02 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik rdieter rnovacek than
14:08:07 <rdieter> #topic agenda
14:08:21 <rdieter> I threw a few items on https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-20#Agenda
14:08:25 <rdieter> anything else for today?
14:08:42 * rdieter fetches some coffee quick
14:12:20 <rdieter> ok, guess that means nothing else. :)
14:12:34 <rdieter> #topic F-14: to kdepim-4.5 or not to kdepim-4.5
14:13:05 <rdieter> Kevin_Kofler: I figure you want to try to make the case to include this again?  let's here it. :)
14:13:37 <than> i thought we already made decision here!
14:13:37 <Kevin_Kofler> I think Fedora is about shipping current stuff.
14:13:53 <rdieter> than: we decided last week to defer for a week, now's the time
14:13:56 <Kevin_Kofler> And sure it's not stable yet, but neither are we, there are 3 months until release.
14:13:56 <jreznik> Kevin_Kofler: but not broken one
14:14:22 <Kevin_Kofler> We can only fix the issues if we actually have the software packaged and tested by Rawhide users.
14:14:22 <jreznik> ok, anyone asked upstream for clear conclusion? without it - we can argue for nothing
14:14:34 <Kevin_Kofler> Otherwise they'll never get fixed.
14:14:40 <than> jreznik: +1
14:14:51 <Kevin_Kofler> Plus, IMHO migration is not a showstopper for a new Fedora (only for updates to an existing release).
14:14:57 <Kevin_Kofler> Sure, it's bad if migration doesn't work.
14:15:22 <than> Kevin_Kofler: we can upload kdepim 4.5 to redhat-kde!
14:15:33 <than> why is the problem?
14:15:35 <Kevin_Kofler> But sometimes upstream just breaks it and there must be a place to do a nonmigratable update or we'll be stuck with the old version forever.
14:15:46 <jreznik> Kevin_Kofler: PIM is about data - if you loose data - it's bad... and not only migration - but what if we ship some beta that will have problems with data migration to stable version
14:15:55 <than> people who want to test it can download from there
14:17:40 <jreznik> with clear statement from upstream (release schedule), promise not to break data with newer version - I'm +1 (at least for Rawhide, we can pull it back)
14:17:41 <Kevin_Kofler> Fedora is not RHEL.
14:17:56 <Kevin_Kofler> What's the point of Fedora if we stop shipping current software.
14:18:21 <jreznik> Kevin_Kofler: there's big difference - current software and unstable software
14:18:36 <than> Kevin_Kofler: we just avoid to ship unstable software
14:18:40 <SMParrish> Kevin_Kofler: we need to ship reliable software.  If upstream says they cant guarantee stability and no data loss we cant ship it
14:18:43 <rdieter> There's not much new information than from last week, except that heliocastro tried it, and found it pretty bad still
14:19:23 <rdieter> upstream's recommendation is still that it's not ready, and I'm of a mind to follow their advice.
14:19:27 <kalev> Is the data format stable now? i.e. have they said that they aren't going to change the way they save data during the beta 4.5.x releases?
14:20:37 <rdieter> good question
14:20:51 <rnovacek> I tried it too and I was unable to fetch my gmail mailbox... it used a lot of CPU and it didn't finish in about an hour
14:20:57 <rdieter> I'd venture the answer is a qualified yes (format stable)
14:21:53 <than> we will follow upstream's advice.
14:22:00 <rdieter> seems support for inclusion is limited to Kevin_Kofler, so I think this isn't going to happen.  Kevin_Kofler, unless you want a formal vote or have more to add, let's move on
14:22:37 <than> move on please
14:23:19 <jreznik> I'm for closely watching current status of kdepim - but I don't believe it's going to be ready by f14
14:23:41 <kalev> I have no clue about this particular package, but I'm all for keeping rawhide usable. With the new stable updates release vision, I think more and more people will (and should) start using rawhide. If lots of people are saying that it doesn't work at all ...
14:24:02 <rdieter> #agreed kde-sig (majority) agrees to not include kdepim-4.5 in F-14
14:24:17 <rdieter> #topic include both plasma-nm and nm-applet on kde spin?
14:24:38 <Kevin_Kofler> Sigh, nobody wants to ship current software in Fedora anymore. :-(
14:24:55 <Kevin_Kofler> Are we "Fubuntu" now? Or Fedora Enterprise Linux? :-/
14:25:06 <rdieter> moving on... I added nm-applet to spin-kickstarts, but this seems to have been a bit controversial
14:25:15 <rdieter> per on-list conversation.
14:25:23 <Kevin_Kofler> jreznik's proposal doesn't make sense either, we can't wait any longer, if we want it, we need it imported NOW.
14:25:30 <rdieter> at least 2 suggestions were even made to switch to nm-applet by default
14:25:32 <Kevin_Kofler> There's the feature freeze and we also need testing.
14:25:53 <Kevin_Kofler> rdieter: Shipping nm-applet is entirely useless because there's no obvious way to turn it on.
14:26:02 <Kevin_Kofler> We're just wasting space we don't have.
14:26:13 <Kevin_Kofler> We need to ship one default applet (kde-plasma-networkmanagement) and stick to it.
14:26:19 <rdieter> tis true, it takes a bit of manual futzing to use it
14:26:44 <Kevin_Kofler> People won't know how.
14:26:54 <Kevin_Kofler> If they can get to the net to look up instructions, they can also fetch the package.
14:27:17 <rdieter> which is worse, provide no options for those folks who find plasma-nm non-functional or provide nm-applet which is a bit hard to use
14:27:53 <rdieter> how can they fetch any package, if they have no network?
14:28:10 <rdieter> oh ok, instructions = package, fair nuf
14:29:12 <rdieter> any other opinions?  comments?
14:29:15 <Kevin_Kofler> If they have no network, how are they to figure out the manual steps to enable nm-applet? It's not like those are easy for the average user.
14:29:26 <Kevin_Kofler> It's just going to sit there and waste space we don't have.
14:29:40 <rdieter> Kevin_Kofler: the logical conclusion there is to just use nm-applet, that 'just works'
14:29:41 <jreznik> one or another one but not both
14:29:52 <SMParrish> I would prefer shipping the plasma applet but only if its a fully functional replacement for nm-applet
14:29:54 <Kevin_Kofler> rdieter: Ugh…
14:30:12 <jreznik> nm-applet is broken too quite a lot...
14:30:19 <Kevin_Kofler> What are you missing from the plasmoid?
14:30:22 <rdieter> SMParrish: we're back to defining a minimal set of functionalities then or defining "fully functional"
14:30:38 <Kevin_Kofler> Full support for mobile broadband? I can try to backport the stuff that's under development now.
14:30:57 <rdieter> Kevin_Kofler: good vpn support for one
14:31:16 <SMParrish> rdieter: still minimal,  wpa2, vpn etc
14:31:23 <rdieter> mobile broadband I (still) consider non-essential, but still nice to have
14:31:43 <rdieter> so, do we consider vpn support a blocker or not?
14:31:48 <Kevin_Kofler> Uh, WPA just works, at least in knetworkmanager.
14:32:04 <Kevin_Kofler> I can try the plasmoid if you think it might have trouble there.
14:32:18 <rdieter> Kevin_Kofler: yes, please do test it out
14:32:24 <rdieter> would be nice to have more data
14:32:35 <Kevin_Kofler> Do we have a current snapshot in F13 now?
14:32:45 <rdieter> but, it should function almost identical to knm, since they share a common backend
14:32:49 <than> i don't think vpn support is a blocker
14:32:51 <Kevin_Kofler> (It's not very useful to test old stuff.)
14:33:04 <rdieter> Kevin_Kofler: f13 has a relatively new snapshot, yes
14:33:13 <rdieter> (matching what's in rawhide atm, I believe)
14:34:04 <rdieter> so, revert the change I made, drop nm-applet from the spin ?
14:34:28 <than> shipping both nm-applets and plasma-applet doesn't make sense
14:34:31 <Kevin_Kofler> +1
14:35:05 <than> rdieter: is plasma applet a fully functional replacement for nm-applet?
14:35:19 <rdieter> than: define "fully functional"
14:35:21 <Kevin_Kofler> Making it too easy to use nm-applet also means we won't get testing feedback if the plasmoid doesn't work.
14:35:38 <rdieter> if "fully functional" = supports *all* nm-applet features, then the answer is no
14:35:39 <Kevin_Kofler> We can reconsider if we get closer to the release and have space left to spare.
14:35:46 <jreznik> vpn support would be nice
14:35:48 <than> network/modem/dsl and mobil should work
14:36:12 <than> of course wlan
14:36:36 <rdieter> and arguments were made onlist about plasma-nm's UI, it's a bit more complicated and less streamlined than nm-applet
14:37:17 <rdieter> I believe that was dgilmore who made that comment
14:37:20 <than> it's basic things which should work in plasma-nm
14:37:21 <Kevin_Kofler> Well, it's more powerful/flexible than GNOME's minimalist UIs. :-)
14:37:56 * dgilmore is going to lunch
14:37:58 <rdieter> oh, and apparently it's support for configuring static ip/dns either doesn't work or is lacking (I've heard complaints, not verified)
14:38:13 <dgilmore> but connecting to a new wireless network is not simple and is full of bugs
14:38:53 * rdieter thinks new wireless setup is fairly simple. ?
14:39:02 <Kevin_Kofler> Please send your complaints upstream…
14:39:09 <rdieter> click applet -> show more
14:39:10 <jreznik> task for all kde siggers - test, test and test knm, plasma-nm
14:39:16 <Kevin_Kofler> It's not our job to improve the UI unless it's really broken.
14:39:22 <Kevin_Kofler> (And even then the fix should be made upstream.)
14:39:38 <rdieter> though I think nm-applet announces new networks proactively
14:39:42 <Kevin_Kofler> jreznik: The plasmoid is what needs most testing.
14:39:49 <Kevin_Kofler> KNM is deprecated AFAIK.
14:40:08 <Kevin_Kofler> rdieter: s/proactively/annoyingly/
14:40:22 <rdieter> #agreed revert recent change to spin-kickstarts, do not include nm-applet on kde spin
14:40:28 <jreznik> from my observations all three are broken completely and it's shame for us (linux desktop)
14:40:47 <Kevin_Kofler> I don't want to be offered some random neighbor's WLAN just because the one I want to connect to has a short hickup.
14:41:05 <rdieter> #help kde-sig'ers test test test plasma-nm
14:41:18 <dgilmore> rdieter: not when it displays info for other networks when you try and do it
14:41:30 <dgilmore> Kevin_Kofler: i sent them upstream. they were silent
14:42:07 <Kevin_Kofler> Then they probably think their UI is just fine. :-)
14:42:32 <nucleo> is there IPv6 support in knetworkmanager?
14:42:36 <rdieter> as usual, there's a downside including this (similarly for kpk) when we have no fedora developers involved in the project
14:42:37 <dgilmore> it doesnt work  so its not fine
14:42:40 <dgilmore> anyways im going
14:43:11 <rdieter> we're captive to their whims.
14:43:34 <rdieter> vs. including stuff that's developed and supported within fedora, by fedora developers
14:44:01 <Kevin_Kofler> The disconnect between Fedora and upstream on KDE can be a problem indeed.
14:44:13 <Kevin_Kofler> On the other hand, it's how an upstream-distro relationship usually works.
14:44:47 <Kevin_Kofler> And it also means we're not subject to conflicts of interest when Fedora's goals and upstream's conflict (see e.g. the Mozilla trademark issues).
14:44:57 <rdieter> I'll bring up the topic of what to do with kpk next week
14:45:03 <jreznik> rdieter: ok
14:45:21 <rdieter> moving on...
14:45:24 <rdieter> #topic cmake macros: drop -DBUILD_SHARED_LIBS:BOOL=ON (by default)?
14:45:39 <rdieter> floated that around onlist awhile, are we ready to implement this now?
14:46:00 <Kevin_Kofler> I'd like to try to get more involved upstream, but I'm already doing a poor job (at least according to my own standards) with Kompare, so I don't think trying to get into even more upstream projects is doable. :-(
14:46:19 <rdieter> orion had a concern about stuff breaking (pkgs that build shlibs now, that would change)
14:46:36 * Kevin_Kofler shares his concerns.
14:46:46 <Kevin_Kofler> (As already said previously on IRC.)
14:46:48 <rdieter> but as long as we communicate the change clearly, as well as ways to revert to the old behavior, I think that's manageable
14:47:42 <Kevin_Kofler> I pretty much agree with what Orion said: "Fedora strongly encourages shared libraries as shared libraries are good.
14:47:43 <Kevin_Kofler> If a package really wants a static library it should explicitly state it."
14:48:03 <Kevin_Kofler> FWIW, I think %configure should include --enable-shared, too, but that's not our decision to make.
14:49:06 * rdieter thinks shlibs for convenience libraries is a wee bit silly, wasteful (esp since it forces one to deal with multilib'ing)
14:49:41 <rdieter> now, for projects that provide shlibs, headers, api, all for that
14:50:30 <than> i agree with Kevin, SHARED_LIBS should stay default
14:51:51 <rdieter> ok, looks like a no-go
14:52:24 <rdieter> #agreed (majority) NACK'd cmake proposal to drop -DBUILD_SHARED_LIBS:BOOL=ON
14:52:39 <Kevin_Kofler> At the very least we should know what breaks before making that change in Rawhide.
14:52:53 <Kevin_Kofler> (e.g. do local mass rebuilds or so)
14:52:54 <kalev> sorry, I was in another window. I also agree with Kevin, I think we should instead write up a guide how to deal with convenience libs which doesn't have explicit STATIC in add_libraries() call.
14:53:13 <rdieter> #topic fedora-kde-icon-theme : Inherits=oxygen not working as expected (https://bugzilla.redhat.com/615621)
14:53:21 <rdieter> kalev: volunteering? :)
14:53:21 <Kevin_Kofler> But IMHO stuff which wants STATIC should explicitly state it.
14:53:30 <jreznik> Kevin_Kofler: +1
14:53:46 <kalev> rdieter: yeah, I'm stumped at work right now, but I'm planning to do it eventually
14:53:58 <rdieter> had several reports recently about mimetypes with '?' icons
14:54:13 <Kevin_Kofler> Bug in the MIME type icon loading code?
14:54:18 <rdieter> with problems going away if one switches fedora-kde -> oxygen
14:54:35 <Kevin_Kofler> If the Inherits works for everything else, but not that code, that sounds like a bug in that code.
14:54:38 <rdieter> dunno, interesting that this problem wasn't noticed until very recently
14:54:56 <Kevin_Kofler> What DE and version were the reports with?
14:55:05 * rdieter verified with kde-4.4.5
14:55:05 <Kevin_Kofler> I assume KDE, but was it only 4.5 maybe? Or also 4.4?
14:55:28 <rdieter> original reporter was using 4.4.92 I believe, but I can double-check
14:55:46 <Kevin_Kofler> So 4.4.5 has the problem? What about 4.4.4? 4.4.3?
14:56:01 <Kevin_Kofler> We need to figure out when it started, unless it was always there.
14:56:04 <than> perhaps regression in 4.4.5 ?
14:57:02 <than> however i cannot reproduce this issue on my machine with 4.4.5
14:57:02 * rdieter suspects kdebase-runtime-4.1.1-iconthemes-inherit.patch may have something to do with it
14:57:12 <rdieter> than : oh?  interesting
14:57:20 <rdieter> fwiw, than, what's that old patch for ?
14:59:01 <than> it fixes the inherit issue in old kde 4.1
14:59:10 <rdieter> preferences: 1. if it's a genuine issue, upstream it.  2.  if not upstreamable, please document what it does, why we're carrying it, and why it's not upstreamable
15:00:11 <jreznik> we're out of time
15:00:14 <Kevin_Kofler> Speaking of patch documentation, I noticed that the RHEL 6 Beta 2 specfiles have comments added for some patches, please also add those comments to the Fedora specfiles.
15:00:29 <rdieter> jreznik: indeed.
15:00:38 <rdieter> let's wrap up, thanks everyone
15:00:40 <rdieter> #endmeeting