15:09:55 <rdieter> #startmeeting kde-sig
15:09:55 <zodbot> Meeting started Tue Oct 30 15:09:55 2012 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:09:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:09:59 <rdieter> #meetingname kde-sig
15:09:59 <zodbot> The meeting name has been set to 'kde-sig'
15:10:08 <rdieter> #topic roll call
15:10:20 <dvratil> present
15:10:25 <rdieter> hi folks, who's ready to rock?!?
15:10:51 <rdieter> or have a meeting, whatever. :)
15:10:57 <Kevin_Kofler> Present.
15:11:15 <rdieter> than, jreznik : ping
15:11:26 * jreznik is here
15:11:35 <than> present
15:11:44 <rdieter> #info rdieter dvratil Kevin_Kofler jreznik than present
15:11:50 <rdieter> #chair dvratil Kevin_Kofler jreznik than
15:11:50 <zodbot> Current chairs: Kevin_Kofler dvratil jreznik rdieter than
15:12:06 <rdieter> #topic agenda
15:12:18 <jreznik> blocker bug
15:12:46 <rdieter> noted (the apper can't update one)
15:13:11 <rdieter> kde-runtime splitting
15:13:32 <Kevin_Kofler> To split or not to split, that is the question? ;-)
15:14:34 <jreznik> :D
15:15:17 <rdieter> let's get started then...
15:15:27 <rdieter> #topic blocker bugs (apper, et al.)
15:15:35 <rdieter> .bug 866486
15:15:39 <zodbot> rdieter: Bug 866486 Apper: cannot perform system update - https://bugzilla.redhat.com/show_bug.cgi?id=866486
15:15:57 <Kevin_Kofler> So that's a big problem.
15:15:58 <rdieter> unfortunately, no news from dannti over the weekend
15:16:08 <dvratil> looks like a problem in yum backend
15:16:16 <svuorela> try ximion if dantti is inaccessible
15:16:25 <Kevin_Kofler> It's a very bad blocker for Beta and we don't have any news there.
15:16:31 <rdieter> in my own testing, with recent snapshots, install/remove works, just update operatins fail
15:16:36 <Kevin_Kofler> I also suspect it's lower in the PackageKit stack, not in Apper.
15:16:42 <jreznik> dvratil: reason you think so? does it affect gpk/pk too?
15:16:59 <rdieter> gpk-update-viewer works (for me)
15:16:59 <Kevin_Kofler> That's the big question, does it affect gnome-packagekit, and if not, why not?
15:17:05 <dvratil> I tried running packagekitd --verbose from console, there was always message like "Backend reports finished, closing"
15:17:12 <dvratil> also packagekitd crashes after that
15:17:21 <jreznik> dvratil: could you retry with gnome one?
15:17:28 <Kevin_Kofler> Somebody claimed pkcon also reproduces it.
15:17:38 <dvratil> I was able to update packages via pkcon
15:17:39 <Kevin_Kofler> But I think that was pkcon with the Apper services running.
15:17:45 <dvratil> jreznik, I'll try after meeting
15:17:52 <rdieter> hughsie imported/built pk-0.8.5, so I'll refresh our snapshot for rawhide at least
15:17:57 <Kevin_Kofler> It might be a problem with (or triggered by) the update checking service of Apper.
15:18:11 <Kevin_Kofler> Especially because disabling the automatic update checks is reported to "fix" it.
15:18:12 <jreznik> that's one thing...
15:19:20 * jreznik is pinging hugsie on #fedora-devel
15:21:40 <rdieter> it *may* be worth advocating 1. not consider this bug a beta blocker, 2. be evil and ship gpk-update-viewer instead temporarily
15:22:20 <jreznik> rdieter: qa would scream - 2 is possibility
15:22:33 <Kevin_Kofler> 2 is a bad solution.
15:22:41 <rdieter> status quo is worse. :-/
15:22:48 <Kevin_Kofler> If it's like in the past, we'll end up stuck with it for several releases.
15:23:07 <Kevin_Kofler> Because then people will argue that Apper doesn't do XYZ which GPK does and so switching back is a "regression" etc.
15:23:08 <rdieter> blocking indefinitely sucks
15:23:16 <Kevin_Kofler> We've had that mess before!
15:23:23 <Kevin_Kofler> See e.g. the NM applet.
15:23:50 <Kevin_Kofler> And is GPK even fully usable outside of GNOME anymore? It has hard deps on gnome-settings-daemon these days.
15:23:51 <jreznik> we are going to slip, seems like there's a big chance because of fedup...
15:23:51 <rdieter> f18 has been delayed enough, thank you.
15:24:10 <Kevin_Kofler> I know the Xfce and LXDE spins have switched from GPK to Yumex because of the GNOME deps in GPK.
15:24:32 <Kevin_Kofler> Using GPK is not practical.
15:24:37 <Kevin_Kofler> We need Apper fixed.
15:25:08 <rdieter> jreznik: oh?  ugh, ok, may as well keep trying to bribe dannti (or ximion)
15:25:19 <jreznik> Kevin_Kofler: of course Apper fixed is main objective
15:25:32 <rdieter> i refresh, and test things more after meeting
15:25:37 <jreznik> rdieter: yep :( fedup... and these two blocker bugs
15:25:46 <Kevin_Kofler> AFAIK, GPK depends on both gnome-settings-daemon and gnome-control-center these days.
15:25:51 <rdieter> #action rdieter will refresh apper snapshot for pk-0.8.5, and do more testing
15:25:53 <jreznik> hugsie is going to take a look, he can't promise anything...
15:25:56 <Kevin_Kofler> gnome-settings-daemon doesn't even RUN in KDE.
15:26:15 <jreznik> [16:25] <hughsie> jreznik, looking at that pkmon output it looks like everything is working correctly
15:26:19 <Kevin_Kofler> (xsettings-kde takes the XSettings lock instead, and that's a good thing. GNOME doesn't support running gnome-settings-daemon outside of GNOME.)
15:26:51 <rdieter> stop the FUD, gpk-update-viewer runs just fine
15:27:03 <Kevin_Kofler> Try using the whole thing.
15:27:07 <Kevin_Kofler> Automatic update checks, in particular.
15:27:33 <rdieter> i did
15:27:35 <Kevin_Kofler> If you're going to not care about those, we can just ship Apper with the checks disabled, which is reported to work.
15:27:48 <jreznik> first - we really need working Apper, second - we really need a backup plan, where first is primary - so let's try to solve it :)
15:28:17 <jreznik> Kevin_Kofler: depends if it will pass beta requirements
15:28:18 <rdieter> backup:  1. use alternative tools: yumex, yum/pkcon ?
15:28:24 <Kevin_Kofler> I don't see how GPK can possibly have full functionality in KDE when parts of the code are right there in gnome-settings-daemon.
15:29:25 <rdieter> Kevin_Kofler: so, what would you propose as a backup plan?
15:29:35 <Kevin_Kofler> Slip.
15:29:40 <Kevin_Kofler> There's no other solution.
15:29:56 <Kevin_Kofler> Or downgrade the whole PackageKit stack to what shipped in F17.
15:29:58 * rdieter disagrees
15:30:23 <rdieter> anyone else feel that slipping is better than finding alternatives?
15:31:04 <dvratil> can't we just run yum update from cron?
15:31:08 <dvratil> :)
15:31:41 <Kevin_Kofler> No.
15:31:51 <Kevin_Kofler> No way to prompt for the updates from cron.
15:31:58 <Kevin_Kofler> Just automatically doing them is a no go.
15:32:19 <Kevin_Kofler> Especially because then the user WILL accidentally shut down while the update is running… boom!
15:34:10 <jreznik> Kevin_Kofler: slip is not an aswer - it can just give us a week...
15:34:35 <Kevin_Kofler> Slip 2-3 times at least.
15:34:41 <Kevin_Kofler> Or downgrade the whole PK stack.
15:34:55 <Kevin_Kofler> After all, the stable version is still the 0.7 one!
15:35:02 <rdieter> yes, we know what you think, I want to hear others opinions
15:36:24 <Kevin_Kofler> PackageKit is a core component in Fedora, we need a version that works.
15:37:03 <Kevin_Kofler> So either we wait (as long as necessary, maybe 1 week, maybe 5) for 0.8.x to actually work, or it needs to be reverted to 0.7.x which definitely does work.
15:37:35 <Kevin_Kofler> I'm so fed up of shipping cheap but crappy workarounds just to meet some arbitrary deadline.
15:37:40 <rdieter> packagekit works just fine, it's apper the doesn't (in my testing)
15:38:17 <rdieter> pkcon update  works, gpk-update-viewer works, apper (current snapshot is weird, sometimes works sometimes not)
15:38:19 <dvratil> any idea where the automatic updates are in Gnome?
15:39:27 <jreznik> rdieter: yep, it's definitely apper issue and if we are unable to make it working, then we have to ship different option or take more activity in upstream and help dantti
15:39:50 <rdieter> jreznik: +infinity
15:40:23 <rdieter> I can/will spend a few hours later today on this, I invite others to do so too, if able
15:40:24 <Kevin_Kofler> A KDE spin with gnome-packagekit instead of Apper is like a GNU/Linux distribution with FreeBSD instead of Linux. It's no longer a KDE spin!
15:40:36 <rdieter> best tool for the job
15:40:49 <rdieter> but let's not get into that argument
15:40:59 <Kevin_Kofler> And again, I'd be surprised if there were NOT any hidden issues with using GPK.
15:41:17 <Kevin_Kofler> As I said, the other non-GNOME spins shipped away from it because it did NOT work for them.
15:41:24 <Kevin_Kofler> *switched away
15:41:50 <than> i don't see any problem to ship other option as backup plan
15:42:32 <Kevin_Kofler> than: Rushed in during Beta freeze, when we don't even know whether it will work (and in fact I have good reasons to believe it won't, at least not completely)?
15:42:33 <rdieter> ok, any other *constructive* comments, or should be move on?
15:42:46 <rdieter> we move move on, that is.
15:42:48 <Kevin_Kofler> It's just not an option.
15:43:29 <jreznik> rdieter: thanks, if you could work with hugsie on it, dvratil if you could help too - #fedora-devel channel
15:43:36 <dvratil> sure
15:43:45 <rdieter> next fun topic... :)
15:43:50 * Kevin_Kofler joined #fedora-devel.
15:43:51 <jreznik> and I hope we will be able to join upstream too as it's core package and we need it working
15:44:00 <rdieter> #topic kde-runtime splitting
15:44:09 <rdieter> .bug 855930
15:44:15 <zodbot> rdieter: Bug 855930 kde-runtime too many dependencies (on a GNOME desktop) - https://bugzilla.redhat.com/show_bug.cgi?id=855930
15:44:20 <rdieter> I'd brainstormed a few ideas to help with ^^
15:44:34 <rdieter> some turned out to be bad, some I think are still worth considering
15:44:44 <Kevin_Kofler> I think all the splits are bad.
15:44:53 <rdieter> duly noted
15:44:53 <Kevin_Kofler> All the stuff in kde-runtime is there for a reason.
15:45:00 <Kevin_Kofler> That's why it is in kde-runtime.
15:45:08 <Kevin_Kofler> I also think the removed Requires are bad.
15:45:29 <Kevin_Kofler> htdig is needed for search to work in KHelpCenter, no matter whether on KDE workspaces or not!
15:45:37 <Kevin_Kofler> So it belongs as a dep of kde-runtime.
15:45:55 <rdieter> so the *general* idea was to pull out some non-critical pieces out, still be installed by default on kde spin
15:46:09 <Kevin_Kofler> And we found a better solution for the biggest dependency bloat (DrKonqi → kdepimlibs): we split out the one lib from kdepimlibs DrKonqi needs (the XMLRPC client).
15:46:29 <rdieter> Kevin_Kofler: can I please lay out the proposal first, *then* you can criticise it? :)
15:47:01 <Kevin_Kofler> So lay it out. :-)
15:47:37 <rdieter> 1.  drop hard-coded htdig dependency (used for khelpcenter searches, I think, still need to fully test what works and not with and without it present)
15:48:08 <rdieter> 1.  ~3mb savings
15:49:09 <rdieter> 2. -kio-smb subpkg (ie, makes pulling out libsmbclient possible), ~3mb savings (plus any libsmbclient dependencies)
15:50:13 <rdieter> 3. -drkonqi subpkg, saves pulling in ~8mb kdepimilbs.  though, an alternative solution was found to split out  kdepimlibs-kxmlrpcclient instead
15:51:02 <rdieter> side benefit to 3 is that certain pkg maintainers of rhel kde packages may opt to not ship that piece. :)
15:51:11 <rdieter> Kevin_Kofler: ok, flame away
15:51:58 <Kevin_Kofler> So for 1., that breaks functionality of almost all KDE apps.
15:52:19 <Kevin_Kofler> Almost all KDE apps ship documentation, their functionality will be degraded if you remove KHelpCenter dependencies.
15:52:49 <Kevin_Kofler> For 2., it means all KIO-using apps won't be able to access Samba shares out of the box anymore, again, that's most KDE apps.
15:53:19 <Kevin_Kofler> And for 3., it means users either cannot file bug reports, or worse, will file them to us through ABRT and we'll get swamped by them.
15:53:24 <rdieter> for the record, gnome doesn't pulling gvfs-smb via hard dependencies either, also installed by default via comps
15:53:41 <rdieter> same as what I'm proposing we do
15:53:56 <Kevin_Kofler> In all 3 cases, the broken functionality affects KDE apps running under other workspaces too, those are NOT only workspace dependencies.
15:54:03 <Kevin_Kofler> (Otherwise they'd be in kde-workspace, not kde-runtime.)
15:54:50 <Kevin_Kofler> For DrKonqi, while it makes sense to not ship it in RHEL (because AFAIK RHEL's kdelibs doesn't even spawn it), that can be done with a RHEL conditional. And besides, it's not our job in Fedora to do RHEL packaging. ;-)
15:55:16 <Kevin_Kofler> But there's really no need for a subpackage for that purpose, a conditional to just not ship it is the solution there.
15:55:53 <Kevin_Kofler> And DrKonqi itself and kxmlrpcclient are really small.
15:56:12 <Kevin_Kofler> We fixed the dependency bloat where it is really bloat, i.e. dragging in the whole kdepimlibs.
15:56:25 * rdieter is trying to test khelpcenter, I no longer see how one is supposed to use the htdig-enabled search
15:56:40 <rdieter> there used to be a search tab or something
15:57:24 <rdieter> there's "Find", but that just searches the contents of what's currently displayed
15:57:39 <than> htdig was used in kde3 but i'm not sure if we can drop it in requirement
15:57:53 <than> we need to investigate
15:58:30 <dvratil> afaik the longterm plan is to move all documentation to community.kde.org anyway
15:58:45 <rdieter> there's still references to it in the code, not sure if it's actually used anymore or not
15:59:04 <than> dvratil: +1
15:59:07 <Kevin_Kofler> It might be that the code needs fixing, e.g. it doesn't actually find it.
15:59:38 <Kevin_Kofler> Yeah, looks like htdig support is not working anymore, grrr…
15:59:57 <Kevin_Kofler> The fact that nobody noticed makes me think that we can drop the dep even if we can fix it, sigh…
16:00:25 <jreznik> well, then drop
16:00:32 <than> Kevin_Kofler: drop it
16:00:51 <rdieter> drop as in : don't install via comps either anymore?
16:01:02 * jreznik has to leave now...
16:01:35 <Kevin_Kofler> rdieter: If KHelpCenter isn't actually using it, I guess we don't need it in comps either. We need to investigate what's going on there.
16:02:03 <rdieter> ok, we can add it back later, if investigations are fruitful
16:02:12 <rdieter> and item 2, -kio-smb ?
16:02:54 <than> rdieter: +1 for 2 and 3
16:03:18 <Kevin_Kofler> -1 to 2 and 3.
16:03:29 <Kevin_Kofler> Especially DrKonqi needs to stay!
16:03:42 <rdieter> what's in git right now, is -drkonqi subpkg, but it's pulled in via Requires:
16:03:50 <Kevin_Kofler> How much size does it still use, after the libkxmlrpcclient split?
16:04:05 <Kevin_Kofler> I think it's negligeable.
16:04:09 <rdieter> I figure that Requires: can/will get wrapped with 0%{?fedora}
16:04:13 <rdieter> Kevin_Kofler: true
16:04:28 <Kevin_Kofler> I'm not sure what the purpose of a mandatory subpackage is.
16:04:40 <rdieter> kinda the same as kde-runtime-flags
16:05:43 * rdieter has to go soon, seems there no consensus yet, and jreznik left without commenting on them
16:06:21 <rdieter> bigger picture thing, is that I noticed kioslaves are not all multilib'd
16:06:43 <rdieter> some are, since they're packaged along with shlibs, some aren't
16:06:59 <Kevin_Kofler> jreznik said yesterday on #fedora-kde that DrKonqi should stay as a dep.
16:07:13 <jgrulich> sorry I'm late
16:07:14 <Kevin_Kofler> He didn't comment on kio_smb.
16:07:28 <Kevin_Kofler> jgrulich: 1 hour and 4 minutes late. :-)
16:08:07 <Kevin_Kofler> Meeting times are in UTC, which doesn't change depending on the season.
16:08:22 <Kevin_Kofler> If we want to adjust for DST, we need to decide that explicitly.
16:08:29 <Kevin_Kofler> I'm fine either way.
16:08:32 <dvratil> (that's why DST is evil)
16:08:36 <Kevin_Kofler> I just need to know. :-)
16:08:42 <Kevin_Kofler> dvratil: +1000000 ;-)
16:08:45 <dvratil> anyway - short update: looks like we have Apper updating again
16:08:58 <Kevin_Kofler> Good news!
16:09:07 * rdieter has to go now, item under discussion is whether or not kde-runtime kio-smb should be pulled in via hard dependencies or if simply installing by default via comps is good enough (that latter is now gvfs-smb is handled, for what it's worth)
16:09:14 <jgrulich> shame on me
16:09:26 * rdieter waves
16:10:21 <Kevin_Kofler> As for the non-multilib kioslaves issue, that's something I already noticed eons ago, but back then we couldn't agree on how to handle it.
16:10:51 <Kevin_Kofler> In principle, kioslaves should be multilibbed, in fact ALL the plugins in kde-runtime probably ought to, and even things like KCMs should in principle be multilibbed.
16:11:08 <Kevin_Kofler> (Apps can embed KCMs.)
16:11:52 <Kevin_Kofler> What's clear is that if you have a non-multilibbed ioslave, 32-bit apps on a 64-bit system cannot use that ioslave at all. :-/
16:12:34 * ltinkl giggles at the apper (rather PK) bugfix
16:13:57 <Kevin_Kofler> One character swap and we almost ended up dropping Apper because of it! :-/
16:14:09 <Kevin_Kofler> See why the goal should ALWAYS be to fix things rather than working around them?
16:14:28 <dvratil> :))
16:14:40 <Kevin_Kofler> As for the multilib issue, congratulations to rdieter for reopening that can of worms big enough to feed a swarm of piranhas. ^^
16:19:57 <Kevin_Kofler> For the htdig issue: https://bugs.kde.org/show_bug.cgi?id=122437
16:20:04 <Kevin_Kofler> I guess that ancient issue is still current.
16:20:16 <Kevin_Kofler> The path is hardcoded, it probably doesn't like the location in Fedora.
16:25:36 <Kevin_Kofler> My proposal is to fix it and then readd the hard dep. :-) But since nobody noticed it not working, I can see why we'd not want it as a hard dep…
16:26:04 <Kevin_Kofler> But on the other hand, if nobody notices it missing, that means nobody will think of installing htdig to get the functionality, too. :-(
16:26:18 <dvratil> I think no one really uses the manuals
18:47:28 <rdieter> Kevin_Kofler: the paths look right
18:47:55 <rdieter> grep htdigbin /usr/libexec/kde4/*htdig*  => my $htdigbin = "/usr/bin";
18:48:04 <rdieter> my $ret = system( "$htdigbin/htdig", "-s", "-i", "-c", $conffile );
18:48:20 <Kevin_Kofler> Hmmm, this needs further investigation then.
18:48:23 <Kevin_Kofler> But shouldn't we officially close the meeting? ;-)
18:48:35 <Kevin_Kofler> It's been "ongoing" for over 3 hours now.
18:48:41 <rdieter> #endmeeting