15:05:02 #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-11-22 15:05:02 Meeting started Tue Nov 22 15:05:02 2011 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:05:08 #meetingname kde-sig 15:05:08 The meeting name has been set to 'kde-sig' 15:05:16 #topic roll call 15:05:23 * ltinkl is present 15:05:23 Present. 15:05:34 hello kde fans! who's all here? 15:06:14 are you ready to rock! (wait, we missed the opening act...) 15:06:28 * rnovacek is here 15:06:46 * jreznik is here 15:06:59 and rocking :) 15:07:02 #info rdieter ltinkl Kevin_Kofler rnovacek jreznik present 15:07:24 \o/ 15:07:40 #topic meeting time, move a little earlier 15:08:05 fyi, project board wanted to try meeting a wee bit earlier, but that'd bump into our meeting here. 15:08:24 -1, as I wrote on #fedora-kde, I don't think I can reliably make it any earlier. 15:08:28 hoped we could get by with doing 14:30 UTC (or earlier) for a little while until the board elections finish 15:09:03 How long do those Board meetings usually take? 15:09:04 rdieter: we can try to have it together with half hour overlap... not sure how it will work but will see 15:09:12 Kevin_Kofler: 1.5h 15:09:20 i.e. could we possibly have the meeting AFTER the Board meeting? 15:09:28 Or is that too late for others? 15:09:36 well, it's supposed to be < 1 hr, but we're not all that good at managing the meeting to make that happen sometimes 15:10:13 (For me later would work even better than the current 15:00 UTC time for this semester (i.e. until the end of January).) 15:10:16 Kevin_Kofler: at least as temporary solution it works for me, long term I prefer earlier time 15:10:56 jreznik: +1, same for me 15:11:03 looks like 16:00 slot is open on https://fedoraproject.org/wiki/Fedora_meeting_channel 15:11:08 I thought QA used to come after us, did they move? 15:11:30 adamw: ? ^^ 15:11:46 The problem is, 16:00 would step right on the Board meeting anyway, wouldn't it? 15:11:54 oh duh, right 15:12:01 we'd have to move later than that 15:12:37 looks like there aren't any open slots in primary #fedora-meeting, though we could use #fedora-meeting-1 15:12:45 17:00 would make most sense, but we'd probably need to use another chan (#fedora-meeting-1?). 15:12:47 17:00 UTC ? 15:12:57 any problems with that? 15:13:24 np for me 15:13:49 +1 to 17:00 UTC 15:13:59 how about I'll post onlist after meeting, and if there are no objections within a day or 2, we'll go with that. 15:14:28 and fallback to jreznik/I multitasking at our usual time slots if we have to for awhile 15:14:40 let's move on 15:14:59 #topic kde 4.8 beta1 status (jreznik) 15:15:01 jreznik: ? 15:15:03 rdieter: ok 15:15:43 rdieter: quite a busy but some kdelibs/kdepimlibs are built, kdebase* imported and building right now 15:15:53 and I'm importing the rest of the stuff 15:16:11 there was quite a lot of rebasing in kdebase-workspace - hope I solved it correctly... 15:16:14 so far so good 15:16:17 then? 15:16:56 we do carry a lot of -workspace baggage/patches, I'd really like to redouble efforts to minimize and upstream more of that if at all possible 15:17:03 most of active stuff was already in 4.8, classic like hal and startkde patches etc., a problem with Kevin_Kofler's pkgkit-plasma patch 15:17:19 rdieter: yep, exactly what I felt while doing it 15:17:58 jreznik: Yes, they added some new dependency reduction things to make things optional… 15:18:01 * rdieter will commit to working toward that before f17 15:18:14 Strictly speaking, the hunk of the patch which you had to rebase can be omitted entirely for our purposes. 15:18:22 cool, anything else, or move on? 15:18:33 We don't care about crippled builds anyway, especially not ones without PackageKit… ;-) 15:18:51 Kevin_Kofler: ok, I'll take a look - I didn't want to touch it too much and was waiting for KK patchbot review :) 15:19:04 but I saw it there 15:19:53 #chair ltinkl jreznik Kevin_Kofler rnovacek 15:19:53 Current chairs: Kevin_Kofler jreznik ltinkl rdieter rnovacek 15:19:57 (almost forgot) 15:20:01 Given that kdelibs 4.7.80 is basically the same as 4.7.3-4, we'll probably have to use the rebased patch for the 4.7.4 builds too, or just drop it there (it's disabled by conditionals for Fedora < 17 anyway). 15:20:54 cool, we can sort that out over the coming days... 15:20:55 I'm going to check the rebased patches to verify nothing got lost. 15:21:05 #topic plasma active status (jreznik) 15:21:17 moving on to plasma active status 15:21:19 (Please don't drop things if you aren't 100% sure it's not needed anymore.) 15:21:37 * rdieter helped do a pkg review or 2: plasma-mobile in particular 15:21:38 (All our patches are there for a reason. :-) ) 15:22:08 another reason to better document what the patches are for, and what they do. 15:22:24 Kevin_Kofler: thanks for review, I was hoping for it - removed only stuff that there already in (and checked it), same for missing parts of patches I checked upstream why they removed it and if it was intentional 15:22:34 (which we're doing better at, but still remove for improvement) 15:22:35 but you know - it's patchwork and mistakes happens... 15:22:46 we still need contour package review 15:22:47 still room for.. that is. eek 15:23:02 jreznik: I can be a review-bot today 15:23:34 and share-like-connect package - I'll need a little bit help there as can't get it build... 15:23:48 jreznik: I can take a look 15:24:06 first I'd like to finish 4.8 and build it on top of it without the hastle of patches in 4.7 (at least in rawhide) 15:24:18 another thing is - how do we want to ship it??? 15:24:29 that's a good question. 15:24:32 as active conflicts quite a lot with plasma desktop 15:24:46 like file associations, different active applications 15:25:14 we could setup a custom active-settings with XDG_DATA_DIRS and such (a little work) 15:25:36 rdieter: how do you mean it? 15:25:40 Different kde-settings with a different profile, and then we need some kludge to set the profile to use depending on what Plasma is being used. 15:25:43 how about switch in login screen (session or how is it called) 15:26:27 (Can we set the profile in an environment variable? If not, we have to patch kdelibs to allow that.) 15:26:44 it's also candidate for another spin :) fedora active one... as now the target device is completely different, different set of apps (it's nonsense to ship desktop apps with active etc.) 15:27:03 Then we can have a kde-settings-active with its own profile and a startkde-active which sets the required environment variables. 15:27:08 jreznik: well, my first idea was to make plasma-active use some sort of custom login session from kdm 15:27:24 rdieter: it's not in workspace selection kcm... 15:27:36 rdieter: I think that's a good plan. 15:27:37 jreznik: it could be, if we wanted to. :) 15:28:04 Create a custom session which starts up some startkde-active script, which might just be a wrapper around startkde setting some environment variables first. 15:28:10 but it's something we should collarate with upstream on, see what their intentions/plans are on how it should be deployed 15:28:11 rdieter: that's what I'm not sure 15:28:15 And then patch things to load different settings based on the environment. 15:28:26 I'd rather not do something that's not upstreamable 15:28:38 rdieter: yep, probably better to ask #plasma guys first, I'll do it 15:28:43 We'll just have another kde-settings profile. 15:28:51 That's what profiles are for. 15:29:00 Kevin_Kofler: it's a natural fit, yes 15:29:44 We just need an envvar override for /etc/kde/kde4rc. 15:29:52 Shouldn't be hard to patch that into the code. 15:30:14 Then set the variable in a startkde-active wrapper. 15:30:25 #info jreznik to contact #plasma active upstream about deployment issues 15:30:35 #topic open discussion 15:30:53 XDG_DATA_DIRS could be set directly there, anything else needing different profiles can be tweaked on a case by case basis. 15:30:59 jreznik/I will be multitasking here and #fedora-board-meeting for the next 30 min, fyi. 15:31:04 anything else to discuss today? 15:31:24 phonon-backend-gstreamer's dependency on PackageKit-gstreamer-plugin, reloaded… 15:31:35 rdieter: and 4.8 builds, active stuff etc. :D multi-multi-tasking :) 15:31:39 It got disabled in Rawhide because PK was broken, it should be reenabled there IMHO. 15:31:58 Kevin_Kofler: yup 15:32:04 Unless we agree to drop the dep. 15:32:13 Kevin_Kofler: ah. on the other hand, I'm of a mind now to leave it as-is (without the hard dep) 15:32:23 I still think we should keep it, for the same reason as last time we discussed this. 15:32:31 It's required for the automatic codec installation to work. 15:32:41 the bugs associated with it being absent are gone now (for awhile) 15:32:52 and it'll still get pulled in by default via comps 15:33:10 Now there are showstopper bugs in the automatic codec installation, but disabling the dependency which makes it work isn't going to help getting it fixed. 15:33:51 (I really hope that MP3 codec Provides issue can be sorted out! The GStreamer maintainers aren't as cooperative as I'd expect them to be there!) 15:33:56 so, we'll make those are really don't want it happy, and still have it get installed by default. I think everyone wins in that scenario 15:34:09 What in comps will pull it in? 15:34:19 @kde-desktop currently 15:34:38 but we can also sprinkle in some conditional ones in other groups (like @sound-and-video) 15:34:53 Uhm, it's already in Sound and Video, but that's littered with GNOME apps, so no KDE user will enable that… 15:35:33 I think that's about the best we can do, short of revamping/reorganizing comps 15:35:58 (ie, creating some kde-centric groups, to avoid the problems assicated with sound-and-video not being tailored for our needs) 15:36:21 So mmaslano wants the dep dropped (see the bug she filed), as did someone earlier. But I don't think anything has changed, we wanted the dep back then and we still want it now. 15:36:52 we were primarily concerned folks may not get the dep installed (esp on upgrades). 15:37:00 * jreznik talked to marcela about it today :) 15:37:01 Though, actually… something has changed: phonon-backend-gstreamer is now the default, which allowed us to add the dep in comps. 15:37:08 but now that we've included it by default (esp via hard dep) for a few releases... that's no longer a problem 15:37:57 Hmmm, right, comps will pull it in for new installs, and upgrades already have it due to the hard dep… 15:38:09 So I guess we can really drop it now. 15:38:14 anyway, that's my thoughts on the matter. if the consensus is till to keep it, ok. 15:38:20 still... 15:38:57 rdieter: You convinced me, I'm also for dropping the hard dep now. 15:38:57 ltinkl, rnovacek : what do you think then? 15:39:32 drop it, the reasons above make sense 15:40:07 OK, I'll reopen the bug then. 15:40:22 Kevin_Kofler: or just mark it resolved->rawhide instead 15:40:58 (I suppose we could drop the dep in subsquent f16 updates too... ?) 15:41:30 I think if we really want to drop it, we can indeed drop it in F16 too. 15:41:53 though... I didn't add it to f16 comps (yet). 15:42:02 Though OTOH, people upgrading from F14 and skipping a release might still have only phonon-backend-xine and thus no PackageKit-gstreamer-plugin. 15:42:06 probably should if we follow through on that. 15:42:30 (and even upgrading through F15, it didn't necessarily pull in the -gstreamer stuff) 15:42:34 upgraders don't have f16-updates enabled by default, do they? 15:42:51 With preupgrade or direct yum, they do. 15:42:55 rdieter, not normally 15:42:58 With the DVD, they don't. 15:43:32 hrm... ok, it's balancing act then. how serious do we care about that upgrade case, and the possible loss of the dep 15:44:17 dvd upgrade case should be the default imho 15:44:26 Also note that people might STILL have only phonon-backend-xine even AFTER upgrading to F16, as long as https://bugzilla.redhat.com/show_bug.cgi?id=752513 is not resolved in stable updates. 15:44:30 (someone feel free to take over #chair duties here for the remainder of the meeting... fyi. 15:44:54 Kevin_Kofler, does it resolve itself with 'yum distro-sync' ? 15:44:56 Southern_Gentlem: Upgrades without updates included are totally broken by design, it totally sucks that the website lists that as the recommended method. 15:44:58 Kevin_Kofler: well, those 2 issues will get resolved simultaneously 15:45:25 rdieter: That's kinda the problem, that way they won't get PackageKit-gstreamer-plugin dragged in. 15:45:26 once the newer phonon/phonon-gst builds do finally go stable 15:45:46 I think the safe thing is to keep the hard dep until Fedora 19 (!). 15:45:57 (Well, until 18, drop it in 19.) 15:46:18 lol, ok, let's play it safe for now, and make it f17+ only then (ie, stick with the status quo) 15:46:18 KK and when everything else is beyound a crap shoot i will agree with you 15:46:24 People who upgraded from F14 to 16 GA and then again to 18 without ever applying F16 updates are a supported use case. 15:46:29 (in theory) 15:46:49 Kevin_Kofler, no, not really. only if they used DVD. 15:47:03 Kevin_Kofler, with preupgrade and yum, it is required to apply updates first. 15:47:12 So 19 is the earliest version we can drop the hard Requires in, because 17 is the earliest version we can rely on users having phonon-backend-gstreamer in. 15:47:32 fenrus02: Yet another reason why the DVD is broken for upgrades. ;-) 15:47:43 no argument from me 15:47:44 Southern_Gentlem: Direct yum always just works for me. 15:48:08 Using the DVD to upgrade is just ASKING for EVR issues. 15:48:22 If you're lucky, your system will work again after doing a "yum update" in console mode. 15:48:24 Kevin_Kofler, but DVD upgrades work with preupgrade fails miserably 15:48:30 If you're unlucky, even yum will be broken. 15:48:30 KK good we will call you to help the one that it doesnt work for 15:48:32 and 'yum distro-upgrades' are unsupported. 15:48:41 (see Fedora 11) 15:49:04 Kevin_Kofler, with a DVD upgrade? no, yum will be in sync with py and it should work. DVD upgrades force NVR and break deps 15:49:05 F10 updates' yum had a newer EVR than F11 GA's, but was built against the wrong Python, ouch! 15:49:13 I had to fix a system broken by that, it was not fun. 15:49:36 (I ended up downloading the F11 updates yum RPM with the command-line ftp client and applying it with rpm -Uvh, yuck!) 15:49:57 f11 had issues. 15:50:06 (KDE was broken too, due to the same kind of EVR issues. The command-line ftp was one of the few things that worked.) 15:50:25 DVD upgrades do not downgrade packages. 15:50:47 So if you already have a newer package from Fn-1 updates, it will NOT downgrade it. 15:51:02 Unless that changed very recently. 15:51:37 And so if the package from Fn-1 updates was built against the wrong libraries, it will crash and burn. 15:51:54 When what's hit is yum (which was the case in F11), good luck fixing your system! 15:56:40 https://bugzilla.redhat.com/show_bug.cgi?id=694169#c24 15:57:17 (That's the summary of the meeting decision.) 15:57:46 #agreed Drop Requires: PackageKit-gstreamer-plugin from phonon-backend-gstreamer in Rawhide, keep in F16- at this time. 15:59:02 Anything else to discuss? 15:59:08 Otherwise I'll close the meeting. 16:00:55 #endmeeting