14:01:03 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-06
14:01:03 <zodbot> Meeting started Tue Jul  6 14:01:03 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:07 <rdieter> #meetingname kde-sig
14:01:07 <zodbot> The meeting name has been set to 'kde-sig'
14:01:13 <rdieter> #topic roll call
14:01:19 <rdieter> who's present today?
14:01:21 * jreznik is here
14:01:32 * SMParrish here
14:02:39 <Kevin_Kofler> Present.
14:02:58 <rdieter> #chair jreznik SMParrish Kevin_Kofler
14:02:58 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik rdieter
14:03:11 <rdieter> #info jreznik SMParrish Kevin_Kofler rdieter present today
14:03:19 <rdieter> #topic akademy report
14:03:30 <rdieter> jreznik: who goes akademy? !
14:03:36 <rdieter> how goes even...
14:04:01 <jreznik> my last day
14:04:16 <jreznik> today we had "branding qa for distros" by troy
14:04:24 <jreznik> expect big changes
14:04:38 <jreznik> no kde sc anymore but rebranding to plasma
14:05:04 <jreznik> sc is only internal release team name
14:05:09 <rdieter> yay and ugh.  hopefully this will be the last of any major rebranding.
14:05:10 <rdieter> :)
14:05:23 <jreznik> so no more KDE - at least for product
14:05:26 <Kevin_Kofler> Well, Plasma is the workspace, i.e. the actual desktop environment.
14:05:40 <Kevin_Kofler> As long as they'll release the whole thing together, we'll refer to the whole thing as something.
14:05:47 <jreznik> we should rename "Fedora Plasma Desktop"/"Fedora Plasma Netbook" etc...
14:05:57 <meGenius> so, kde today applied the kde community theory
14:05:58 <Kevin_Kofler> And if they don't want us to call it KDE SC anymore, we will just go back to calling it KDE. :-p
14:06:03 <kalev> at least this name is readable, not like "KDE SC" which I can't pronounce
14:06:12 <jreznik> Kevin_Kofler: no more KDE for product
14:06:37 <Kevin_Kofler> Again, I can call things how I want.
14:06:47 <meGenius> Kevin_Kofler+1
14:06:52 <Kevin_Kofler> It's not their choice as to how we refer to the stuff.
14:07:02 <meGenius> people will keep - for some time at least - calling it KDE
14:07:04 <jreznik> Kevin_Kofler: it is
14:07:11 <Kevin_Kofler> We could even just call it "desktop" and they couldn't do anything about it.
14:07:12 <meGenius> even it will be renamed to plasma desktop
14:07:18 <Kevin_Kofler> Just look at what our GNOME team does to GNOME.
14:07:43 <rdieter> let's not spend any time discussing details, since we currently lack them.
14:07:44 <jreznik> Kevin_Kofler: you would like calling "Fedora KDE" "SUSE KDE"
14:07:55 <jreznik> rdieter: I have all details :)
14:07:59 <rdieter> jreznik: anything else good and juicy to report?
14:08:07 <jreznik> I'll send it to ML
14:08:09 <meGenius> jreznik: summary then :P
14:08:10 <jreznik> my notes
14:08:12 <rdieter> jreznik: yes, please +1
14:08:21 <jreznik> it's just an hour ago
14:08:51 <jreznik> I talked to Lubos Lunak about what's he working on
14:09:01 <jreznik> kdm/ksplash/plasma integration etc...
14:09:14 <jreznik> and he's awesome kde obs generator
14:09:18 <Kevin_Kofler> jreznik: When I file a grouped update for kde*, I need to refer to it somehow, what do they expect me to write in the update notes?
14:09:19 <jreznik> and his sorry
14:09:39 <jreznik> Kevin_Kofler: we should have two groups -
14:09:49 <jreznik> one "Plasma Desktop" with bare system
14:09:57 <jreznik> and "KDE Applications"
14:10:02 <Kevin_Kofler> "This update contains the Plasma desktop 4.n.m and version 4.n.m of several packages released by the KDE project which all happen to have names starting with kde*, but which we cannot call "KDE"."? ^^
14:10:14 <jreznik> Kevin_Kofler: yes
14:10:18 <jreznik> similar
14:10:22 <Kevin_Kofler> This is getting ridiculous.
14:10:36 <jreznik> and it involves packaging splits - as upstream wants to promote apps separately
14:10:42 <jreznik> and ship separetely
14:10:54 <jreznik> I'll try to summarize it
14:10:59 <meGenius> jreznik: what about the group name, will it be plasma desktop, or KDE??
14:11:02 <rdieter> sounds more sane than the "SC" thing to me, but I'll reserve judgement until I see/read the whole thing
14:11:04 <Kevin_Kofler> Upstream just wants to make our work harder. :-/
14:11:39 <meGenius> Kevin_Kofler: it's about the social dimension of KDE ;)
14:11:59 <jreznik> Yrvin Knut shouted to Troy, it was quite stresfull meeting full of emotions
14:12:22 <rdieter> challenged him to a dance-off.
14:12:28 <rdieter> lol, kidding. :)
14:12:35 * drago01 didn't really follow the discussion but thinks that throwing a well known brand away like that is just wrong but well ...
14:12:47 <jreznik> it makes sense but it's also risky to go away with KDE brand and replacing with Plasma
14:12:56 <Kevin_Kofler> I think everyone will still call it KDE.
14:13:16 <Kevin_Kofler> Even that "SC" thing hasn't really caught on, only pedants use it (and I'm also a pedant, so I occasionally use it too even though I hate it).
14:13:18 <jreznik> it's similar to "Microshit Windows 7" -> "KDE Plasma 4.5"
14:13:52 <jreznik> we need product that is done by KDE community
14:14:13 <jreznik> because KDE was/is heavily overloaded
14:14:14 <rdieter> jreznik: so, is there anything that we can use from lubos?
14:14:30 <jreznik> rdieter: I really like his obs kde package builder
14:14:40 <jreznik> now it depends on opensuse build service
14:14:51 * rdieter was thinking more about the branding stuff, kdm,ksplash,wallpaper
14:14:52 <jreznik> but it creates SPEC files from CMake
14:15:26 <Kevin_Kofler> But do those spec files even come close to conforming to our guidelines? I doubt it.
14:15:34 <jreznik> he's still working on better KDM/KSplash/WP integration, he'd like to have the same code
14:15:39 <Kevin_Kofler> So far all the autogenerated specfiles I've seen have been crap.
14:15:43 <jreznik> Kevin_Kofler: it's remplate based
14:15:50 <jreznik> template
14:16:12 <jreznik> it works for easy packges like packages from kde-apps etx
14:16:22 <rdieter> jreznik: thanks, anything else?  or can we move on?
14:16:39 <jreznik> it has mappings from opensuse packages to fedora/debian... it's crossdistro
14:16:50 <jreznik> rdieter: that's all for now
14:17:01 <jreznik> and yes - qt rulez and everywhere
14:17:08 <rdieter> #topic qt-4.6.3 update status
14:17:09 <jreznik> everyone is hiring qt devels
14:17:37 <rdieter> than told me someone was going to submit a qt update near the end of last week, but it seems to not have happened.
14:18:07 <rdieter> jreznik: you know anything?  or who was going to do that?
14:18:10 * jreznik was busy travelling to tmp (and I saw new build before) so I wasn't sure
14:18:23 <rdieter> than: ping ?
14:18:28 <jreznik> could someone do it?
14:18:51 <rdieter> jreznik: yes, I suppose.  I think I have the link for the security update still
14:18:55 <jreznik> or maybe after meeting but I have to start packing, our flight departures in the night
14:19:21 <rdieter> jreznik: don't worry about it, you're busy enought today.
14:19:45 <rdieter> #
14:19:54 <rdieter> #action rdieter will work to submit qt update after meeting
14:19:57 <Kevin_Kofler> The build I submitted was just to clean up the translations mess.
14:20:05 <Kevin_Kofler> It should be safe to include in the security update.
14:20:13 <rdieter> Kevin_Kofler: right, that latest one is what I indend to submit
14:20:17 <Kevin_Kofler> The Qt translations now conform to packaigng guidelines.
14:20:19 <rdieter> intend even
14:20:23 <Kevin_Kofler> *packaging
14:21:04 <rdieter> the paranoid thing would be to submit the build with security fixes only to stable, and the later build to -testing
14:21:07 <jreznik> ah, ok
14:21:15 <Kevin_Kofler> (BTW, can we at least call Qt Qt for the foreseeable future? Or is that also being rebranded, to Nokia's Awesome Portable Toolkit or something like that? ;-) )
14:21:33 <rdieter> the later fixes seem small and safe, and it's been sitting in kde-testing awhile
14:21:34 <jreznik> it's mess too
14:21:54 <jreznik> as "Nokia Qt SDK" and "Qt SDK" are two different products!!!
14:22:02 <Kevin_Kofler> LOL WTF…
14:22:30 <jreznik> Nokia Qt SDK is Qt SDK + Qt Mobility + Qt Creator in one package
14:23:19 <rdieter> moving on...
14:23:33 <rdieter> #topic cmake guidelines update
14:23:37 <rdieter> http://lists.fedoraproject.org/pipermail/kde/2010-June/007462.html
14:24:03 <rdieter> lots of little things there, but the big one is dropping -DBUILD_SHARED_LIBS:BOOL=ON (by default)
14:24:45 <rdieter> will make sure to make it easy to turn that back on if we do make a change (probably with an rpm macro too)
14:25:08 <rdieter> and it will be rawhide (f14+) only
14:25:10 <Kevin_Kofler> I think a lot of stuff is going to end with stuff built static that way. :-/
14:25:19 <Kevin_Kofler> I think it's a bad idea to turn that off by default.
14:25:22 <rdieter> Kevin_Kofler: maybe
14:25:51 <rdieter> but if upstream intends stuff not to be shlibs (and convenience libs only), all we're doing is making packaging/multilib harder
14:25:52 <Kevin_Kofler> We also use --enable-shared in %configure.
14:26:02 <Kevin_Kofler> I don't see why %cmake should not do the same.
14:26:10 <rdieter> %configure doesn't have --enable-shared !
14:26:15 <Kevin_Kofler> Oh, it doesn't?
14:26:19 <rdieter> no
14:26:30 <Kevin_Kofler> But pretty much every package has it. ;-)
14:26:37 <rdieter> true
14:26:55 <Kevin_Kofler> IMHO, if upstream intends stuff to be always static, they're supposed to explicitly mark it STATIC.
14:27:11 <rdieter> honestly, as cmake is relatively new, most of the stuff that will chance is where upstreams didn't specify shlibs or static libs
14:27:16 <kalev> pretty much every _upstream_ autotools packaging enables shared by default; most specs don't pass --enable-shared to configure
14:27:16 <rdieter> will change...
14:27:37 <Kevin_Kofler> I guess we can try the change and see what breaks.
14:27:54 <Kevin_Kofler> I just think that it's the wrong fix. Stuff which must always be static must be marked STATIC explicitly.
14:28:01 <kalev> Exactly!
14:28:13 <kalev> Maybe we should somehow state that in the guidelines
14:28:18 <rdieter> Kevin_Kofler: that too (and likewise for stuff that should be shlibs)
14:28:35 <Kevin_Kofler> Well, the idea is that most libraries should be configurable by the user as static or shared!
14:28:54 <Kevin_Kofler> So if a package works as intended, if you don't enable shared libs, EVERYTHING will be static.
14:29:24 <Kevin_Kofler> That said, the package should probably default BUILD_SHARED_LIBS to ON like most autotools upstream programs do.
14:29:34 <Kevin_Kofler> But I guess most packages follow the CMake default.
14:30:05 <rdieter> anyway, any suggestions on changing, improving the proposal, please make onlist
14:30:25 <jreznik> ok
14:30:34 <rdieter> As we don't' seem to have full consensus yet, I'll wait to implement any changes until we do
14:30:46 <kalev> How about the rest of the changes?
14:30:49 <Kevin_Kofler> A lot of stuff probably forces SHARED explicitly, which isn't that great a solution, but which we're encouraging if we default to static.
14:31:30 <rdieter> kalev: imo, the rest of the changes should be non-controversial
14:32:04 <rdieter> #info take further discussion about cmake guidelines/macros proposal onlist
14:32:14 <Kevin_Kofler> The building in a subdir part? I'm not sure why it's required. Pretty much all packages build just fine in the source dir.
14:32:17 <kalev> Can we split it into two, as in get the rest of the changes in and think about the BUILD_SHARED_LIBS change longer?
14:32:21 <Kevin_Kofler> (Just one or two core KDE packages reject that.)
14:32:38 <Kevin_Kofler> And some packages might even build ONLY in the source dir.
14:32:52 <kalev> CMake upstream suggests to use build dir, so I think it's make sense if we suggested sensible defaults too
14:32:56 <rdieter> Kevin_Kofler: that should be the exception though
14:33:03 <Kevin_Kofler> (But that's a bug. And IMHO rejecting building in the source dir like those KDE packages do is a bug too.)
14:33:08 <kalev> It's not like people can't keep using in-source builds: only our example default will get changed.
14:33:23 <Kevin_Kofler> (I don't see why they can't make it work instead of going through the trouble of rejecting it.)
14:34:04 <Kevin_Kofler> The good question is, what's the advantage of an out of source build in a RPM specfile.
14:34:22 <Kevin_Kofler> I can see how it's useful not to pollute your source dir when you build by hand.
14:34:37 <Kevin_Kofler> Is the idea here to allow installing -debuginfo as multilib?
14:34:43 <rdieter> except for developers who build/test rpm builds... by hand. :)
14:34:49 <Kevin_Kofler> (The %{_target_platform} use hints at that.)
14:34:56 <rdieter> no, this shouldn't affect -debuginfo
14:35:03 <rdieter> afaik, anyway
14:35:11 <rdieter> but if it does, bonus
14:35:36 <Kevin_Kofler> rdieter: Well, I think Bison/Flex output and other generated code ends up in the build dir and can end up in the debuginfo.
14:36:02 <kalev> I think it does affect debuginfo. Our debuginfo packages install source files into /usr/src/debug/
14:36:02 <Kevin_Kofler> I think I've seen debuginfo with that %{_target_platform} dir in it.
14:36:13 <kalev> However, some of the source files are _generated_ during build
14:36:17 <kalev> And those will conflict.
14:36:34 <Kevin_Kofler> They won't conflict if they're in target-specific dirs. :-)
14:36:39 <Kevin_Kofler> So that's a good reason to use this construct.
14:36:44 <kalev> Yeah
14:37:22 <rdieter> neat, never paid much particular attention to that before.
14:38:01 <kalev> The con of this change is that it makes spec slightly longer
14:38:45 <kalev> The pro is that KDE CMake guidelines and non-KDE CMake guidelines would look pretty much the same after the change (only %cmake vs %kde_cmake macro difference)
14:38:59 <Kevin_Kofler> I think we should go for the change.
14:40:42 <Kevin_Kofler> I'm usually the lazy person who builds in the source dir, but I can see how the build dir helps in some special cases (people trying to debug RPM builds, people trying to install multilib debuginfo) and doesn't really hurt anything.
14:40:55 <rdieter> me too, I'll forward the link on to cmake-owner@fedoraproject.org too, and if we see no objections, will make the change in a day or 2
14:41:10 <rdieter> #topic open discussion
14:41:13 <rdieter> anything else for today?
14:41:45 * Kevin_Kofler suggests a new name for the KDE software compilation: Formerly Used to be Called KDE. :-)
14:42:34 * rdieter seconds the motion :)
14:42:52 <rdieter> now we need to come up with some odd symbol instead
14:43:16 <Kevin_Kofler> Just use the acronym. ;-)
14:43:24 <rdieter> lol
14:43:30 <jreznik> inappropriately called KDE
14:43:45 <jreznik> lol too
14:44:18 <rdieter> ok, sounds like things are going downhill, and probably signals near end of meeting
14:44:47 <rdieter> thanks everyone
14:44:51 <Kevin_Kofler> FYI, I updated qt-assistant-adp in Rawhide.
14:44:59 <Kevin_Kofler> New source tarball, translations packaged properly.
14:45:04 <rdieter> Kevin_Kofler: yay
14:45:10 <Kevin_Kofler> Other than that, I'm also out of topics to discuss. ;-)
14:45:36 <rdieter> #info Kevin_Kofler updated qt-assistant-adp in Rawhide with new source tarball, translations packaged properly
14:45:47 <rdieter> #endmeeting