15:14:06 #startmeeting KDE SIG Meeting 15:14:06 Meeting started Tue Feb 12 15:14:06 2013 UTC. The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:14:06 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:14:12 #meetingname kde-sig 15:14:12 The meeting name has been set to 'kde-sig' 15:14:19 #topic Roll call 15:14:28 So, who's present? 15:14:40 present 15:15:02 * mbriza . 15:15:41 lukas cannot attend the meeting today 15:16:00 here partially 15:16:01 present 15:16:59 jreznik_? 15:17:28 * jreznik is around 15:17:59 #chair jgrulich mbriza than rdieter jreznik 15:17:59 Current chairs: Kevin_Kofler jgrulich jreznik mbriza rdieter than 15:18:23 #info Kevin_Kofler, jgrulich, mbriza, than, rdieter (partially), jreznik present. 15:19:42 rdieter: Do we start with the kdegames split packaging update or should we do other stuff first? 15:19:55 I can, sure 15:19:58 get it out of the way 15:20:08 #topic kdegames split packaging update 15:20:31 rdieter: Your turn. :-) 15:20:36 ok, all split kdegames packaging is ready for review and built for f18 kde-unstable 15:20:51 http://rdieter.fedorapeople.org/rpms/kdegames/ 15:21:23 stuff needed for kdegames-minimal (kpat, kmines, kjahjongg) reviews submitted so far 15:21:53 will continue submitting the rest throughout the day 15:21:57 OK 15:21:59 rdieter: kmimes's review is done 15:22:14 great 15:22:28 rdieter: please add us to cc for review 15:22:56 so everyone of us can work on review 15:23:02 us = who exactly? (is adding to kde-4.10, kde-review trackers enough? doing more for > 40 packages will take more time) 15:23:36 It's possible to do mass changes from https://bugzilla.redhat.com/showdependencytree.cgi?id=656997&hide_resolved=1 15:23:49 rdieter: kde-review trackers is enough 15:23:51 I'm adding myself to the CC of those that are already there, whom else should I add? 15:24:02 k, thx 15:24:12 that's all from me (so far, for now) 15:24:14 Kevin_Kofler: me, lukas 15:24:24 OK 15:24:44 Kevin_Kofler: thanks 15:25:15 I'll do it for the new ones after rdieter submits them, too. 15:25:53 ok 15:26:10 Kevin_Kofler: next topic 15:27:01 #topic KDE 4.10 for F17? 15:27:36 So, we agreed that we'll do 4.10 for F18, do we want to do it for F17 too? 15:28:58 we can avoid backport fixes if we push 4.10 for f17 15:29:21 it's big benefit 15:29:53 and maintain only one kde version 15:29:55 OTOH, we'll actually need to kludge at least libkdcraw for the jpeg_mem_src mess, unless we can get libjpeg-turbo updated in F17 too. 15:30:10 I can see what I can do for libkdcraw though. 15:30:22 (if everyone agrees that we want the update). 15:30:23 * rdieter thought there might be 1-2 other depedencies f17 didn't have yet, but can't remember offhand 15:30:57 The systemd-logind1 suspend patch needs to be conditionalized on >= 18. 15:31:04 Kevin_Kofler: it already is 15:31:08 no worries there 15:31:11 There might be other hidden trouble though. 15:31:19 switching to udisks2 for F17? 15:31:29 nucleo: no 15:31:29 we have to check depedencies and make sure that the KDE update won't break 15:31:38 nucleo: udisks1 15:31:38 AFAIK, we haven't tried to build this thing for F17 at all yet. :-( 15:31:48 proposal: move forward tentatively with f17/kde-4.10, in the meantime, I'll try to work on doing some kde-unstable builds to see if there's any "gotchas" 15:32:03 i can try to build 4.10 for f17 15:32:17 rdieter: That makes sense. 15:32:30 than: ok, not sure when I'll have time 15:32:30 rdieter: +1 15:32:49 rdieter: i will help you 15:32:52 still makes me a little nervous though, but I won't -1 the plan either 15:33:47 than: I need to work on doing some of these builds using the new copr infrastructure sometime soon too. :) 15:33:55 maybe now is as good as any 15:35:40 * than has not used copr 15:37:14 any objection to include kde-4.10 for f17? 15:38:06 No objection from me. 15:38:42 no objection (as said, not thrilled about the idea, but I won't -1 either) 15:39:09 Oh, one thing is the printer applet stuff. 15:39:25 4.10 ships the new one. 15:39:49 oh yes 15:39:55 IMHO, that shouldn't be a problem because it's hard to suck more than s-c-p-kde did. 15:40:25 But if we don't want to enforce the migration, we need the old stuff built separately. 15:40:38 (I think one of the pieces was already a separate tarball, but the other wasn't.) 15:41:37 Kevin_Kofler: does it mean we still push the s-c-p-kde with 4.10.x? 15:41:44 the old one 15:42:22 I guess so. 15:42:47 or ship both and maybe make them Conflict 15:42:53 but that's icky 15:43:09 As I said, we'd have to build it from separate SRPMs or it'll get lost in the updates repo. 15:44:05 oh, right. 15:44:29 let's tentatively *not* include kde-print-manager for now then 15:44:30 And we already ship both, but kde-print-manager currently ships disabled by default. 15:45:11 oh right, forgot that. nevermind 15:45:19 I think we do want to include kde-print-manager (and enable the makedefault toggle). 15:45:21 we'll just continue with that (not enable it by default) 15:45:56 Kevin_Kofler: it's ok with me 15:46:14 the only reason that works for f18+, is because we Obsoletes: the older s-c-p-kde stuff 15:46:34 but if we're shipping both, then I don't think it's a good idea to goggle kde-print-manager on 15:46:42 Yes, that's what I'd put on F17 too (it's part of the makedefault magic :-) ). 15:46:43 s/goggle/toggle/ 15:47:02 If we don't want to do that, we need to package a new system-config-printer-kde SRPM from kdeadmin-4.9.5. 15:47:07 so do Obsoletes in f17 too then? 15:47:12 kde-printer-applet is already a separate tarball, that one could just stay. 15:47:33 I can do a split s-c-p-kde package if you really want it. 15:48:23 Or we could do the kind of hacks I did in the past and just sneak the 4.9.5 tarball into the kdeadmin-4.10.x SRPM and copy the s-c-p-kde dir in. 15:48:55 (Advantage: one less review, drawback: yuck!!!) 15:50:19 s-c-p-kde does suck, I guess I can support any plan that kills it sooner rather than later :-/ 15:50:27 (Remember the F9 kjots hack? :-) kjots from kdepim-4.1 built as part of kdeutils.spec, where it used to be until 4.0.) 15:50:45 (and 4.2) 15:50:49 actually, it's the kde-printer-applet piece too (from kdeutils?) 15:51:06 kde-printer-applet is built from kde-printer-applet-4.9.5-1.fc17.src.rpm 15:51:11 kdeutils has split tarballs. 15:51:20 kdeadmin still doesn't. 15:52:01 So it's only the kdeadmin piece which is the mess. 15:52:03 so just continue to ship the old kde-printer-applet ? s-c-p-kde can die for all I care 15:52:27 I suppose we install it by default in comps, eh? 15:52:44 * rdieter confirmed, yes 15:53:04 So kde-print-manager Obsoletes s-c-p-kde, but not kde-printer-applet, and the kde-print-manager applet stays disabled by default in F17? 15:53:04 er, make that s-c-p-kde 15:53:28 does anything Obsoletes kde-printer-applet ? 15:53:28 kde-print-manager does in F18+. 15:53:54 any objection to killing both s-c-p-kde and kde-printer-applet in favor of kde-print-manager in f17 too then? 15:53:55 (and there's a Plasma update script to enable the plasmoid) 15:54:28 I'm fine with that, actually. So, let's sum up the 3 proposals: 15:54:53 Proposal 1: kde-print-manager replaces both s-c-p-kde and kde-printer-applet. 15:55:13 (1 is like f18 then, right?) 15:55:26 Right. It'd mean do on F17 what we already did on F18+. 15:55:32 gotcha 15:55:40 Proposal 2: kde-print-manager replaces s-c-p-kde only, the plasmoid stays disabled by default on F17, and kde-printer-applet remains untouched. 15:56:02 (and for "replaces", read "Obsoletes:") 15:56:37 2 might be a little safer though. 15:56:42 Proposal 3: kde-print-manager remains disabled by default in F17 (no Obsoletes), package s-c-p-kde from separate SRPM so it doesn't get lost, kde-printer-applet stays as is. 15:57:16 Kevin_Kofler: s-c-p-kde is part of kdeadmin? 15:57:20 than: yes 15:57:34 included in kdeadmin-4.9 (no longer in 4.10) 15:58:36 proposal 3 is safe solution 15:58:42 * rdieter tenatively prefers option 2. 1 is ok too, but introduces users to more churn and change. 3. the least preferable 15:58:58 but i don't objectionn for proposal 1 i 15:59:03 I'd do 1. or maybe 2., 3. sounds like extra work for probably little benefit. 16:00:05 Kevin_Kofler: yes, but it's safe 16:00:35 2. does need some adjustments to kde-print-manager packaging, but I think I can do it in a fairly straightforward way (and it should also not break on upgrades to F18, because we'll just not ship the Plasma update scripts in F17, so they'll be new in F18 and thus get run as usual). 16:00:36 can't imagine any users' who actually like and prefer s-c-p-kde 16:01:16 16:01:34 I don't object to 3. if I don't have to do the work. ;-) 16:02:16 One thing both 2. and 3. are going to suffer from is the l10n issue though. 16:02:28 oh.. ick, that too. 16:02:29 The l10n stuff is obviously not going to be in kde-l10n-4.10. 16:02:31 Kevin_Kofler: oh yes 16:02:38 ok, die die die, option 1. :) 16:03:04 but just having this conversation makes me like the idea of kde-4.10 on f17 even less, though 16:03:11 Of course, the l10n thing is fixable too ((ab)use releaseme), but it's again extra work. 16:04:05 I'd like to table the idea, until we can get more feedback from folks not here today 16:04:20 Though it might need a hacked releaseme to use an old l10n revision, ugh… 16:04:53 jgrulich, mbriza, jreznik, dvratil : i don't recall seeing any opinions from you yet? 16:04:53 I'd just go with kde-print-manager, it's part of upstream 4.10 after all. 16:05:06 (and ltinkl isn't here today) 16:05:16 Kevin_Kofler: maybe discuss more onlinst? 16:05:22 sorry, I'm busy right now... 16:05:44 Maybe, and table for next week. 16:05:50 We're already out of time. 16:06:03 np, I just don't think we have a good enough consensus yet 16:06:19 than: OK with deferring this "4.10 for F17" to next week? 16:06:44 but more on rdieter side - not a big fan of 4.10 for f17 16:06:47 ok with me 16:07:16 #agreed deferred to next week, discussion is taking too long 16:07:31 #topic Open Discussion 16:07:39 Anything else? Or can I close the meeting? 16:07:45 (We're already over time.) 16:08:33 I guess that's all then. Thanks! 16:08:36 #endmeeting