14:03:28 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-10-12
14:03:28 <zodbot> Meeting started Tue Oct 12 14:03:28 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:36 <rdieter> #topic roll call
14:03:40 <rdieter> who's present today?
14:03:44 * ltinkl present
14:03:48 <rdieter> #meetingname kde-sig
14:03:48 <zodbot> The meeting name has been set to 'kde-sig'
14:03:51 * killefiz is around
14:03:51 * thomasj present
14:03:54 * rnovacek present
14:04:17 <rdieter> jreznik sends regrets
14:04:24 <Kevin_Kofler> Present.
14:04:29 * than present
14:04:40 <rdieter> #chair ltinkl killefiz thomasj rnovacek Kevin_Kofler than
14:04:40 <zodbot> Current chairs: Kevin_Kofler killefiz ltinkl rdieter rnovacek than thomasj
14:04:47 <rdieter> #info ltinkl killefiz thomasj rnovacek Kevin_Kofler than present
14:05:06 <rdieter> #topic build logs checking for errors (like missing optional deps for example)
14:05:17 <than> yes, jaroslav has a talk at local university
14:05:28 <rdieter> first topic was keeping closer tabs on build logs checking for errors, noting missing deps, etc...
14:05:43 <rdieter> a concrete example was a recent kdeedu update that lost libindi support
14:06:15 <rdieter> one option is to enable autoqa for more packages, it's rpmguard tool notes changes in provides/requires dependencies
14:06:25 <rdieter> any other suggestions?
14:06:55 <Kevin_Kofler> I'll have a look at whether we can have CMake (or rather, KDE's CMake macros) error if a dependency which is not explicitly disabled by a -D switch is missing.
14:07:22 <Kevin_Kofler> (There might be already a -D switch doing that, otherwise we could add one and try to get that upstreamed. I know Gentoo is asking for that, too.)
14:07:26 <rdieter> I like that too... and we can work to be more explicit about enabling such features with -D... options too
14:07:44 <Kevin_Kofler> The only thing is, it'd only help if macro_optional_find_package is used correctly,.
14:07:56 <Kevin_Kofler> Sadly, some stuff uses find_package (without REQUIRED) directly.
14:08:02 <Kevin_Kofler> That stuff needs to be fixed upstream.
14:08:06 <rdieter> sure
14:08:15 <Kevin_Kofler> It means the feature is not accountable for easily.
14:08:23 <Kevin_Kofler> For example, kdeedu does that for gpsd.
14:08:31 <Kevin_Kofler> It doesn't show up in the feature log.
14:08:33 <Kevin_Kofler> That's bad.
14:08:36 <rdieter> we can and should help get such things fixed, right.
14:08:40 <kalev> that's where Fedora packagers who notice this add REQUIRED and send patches upstream
14:08:50 <Kevin_Kofler> kalev: Adding REQUIRED is the wrong fix.
14:08:56 <Kevin_Kofler> It should use macro_optional_find_package.
14:09:05 <Kevin_Kofler> The feature should only be REQUIRED if it really _is_ required.
14:09:35 <thomasj> We could fix it to use macro_optional_find_package and upstream the patches. IF upstream is interested in that.
14:09:43 <rdieter> so... seeing find_package used without REQUIRED is a sign of something potentially bad?
14:09:49 <Kevin_Kofler> Yes.
14:09:53 <Kevin_Kofler> (in a KDE package)
14:09:54 <rdieter> ok, understood
14:10:00 <Kevin_Kofler> That's what macro_optional_find_package is for.
14:10:13 <kalev> why is it bad? I'm not arguing, just want to know.
14:10:20 <Kevin_Kofler> Using find_package directly means it doesn't show up in the log of found or not found dependencies.
14:10:31 <rdieter> is this something we should generally all start doing as best practice, or anything think we should task someone to lead an explicit effort to example all kde modules for such find_package usage?
14:10:35 <Kevin_Kofler> Plus, you can't explicitly enable or disable it.
14:10:39 <rdieter> or anyone...
14:10:54 <rdieter> to examine... (ugh, brain misfire)
14:11:33 <Kevin_Kofler> I guess it's something krazy2 could check. (Does it already look in CMakeLists.txt files for stuff or would that be the first such check?)
14:12:00 <rdieter> Kevin_Kofler: you want to research the options, and make some recommendations on how to move forward then?
14:12:15 <Kevin_Kofler> Yes, I'll look into this.
14:12:47 <rdieter> in the meantime, I'd suggest enabling autoqa for all kde core modules... (to benefit from rpmguard).  any objections?
14:12:55 <Kevin_Kofler> Both into having our RPM builds tell macro_optional_find_package to error if the feature is not explicitly disabled and into getting some automated checks done upstream for non-use of the macro.
14:13:34 <Kevin_Kofler> If you're happy being a guinea pig for alpha software… ;-)
14:13:59 <rdieter> I think we already have autoqa for f14+ on everything through kdebase-workspace at least.
14:14:01 <Kevin_Kofler> We can have a try and see how many false positives will show up.
14:14:17 <rdieter> so... enable all modules?  include f13 too ?
14:14:53 <rdieter> (might be interesting, considering a f13 kde-4.5.x update is hopefully coming soon)
14:14:59 <than> rdieter: i will say yes
14:15:22 <Kevin_Kofler> I'm not objecting either, at least until I get spammed with hundreds of bogus complaints. ;-)
14:15:25 <ltinkl> yup, let's see what it brings, we can always turn it back off if it proves unuseful
14:15:47 <Kevin_Kofler> ltinkl: Right.
14:15:56 <rdieter> #action Kevin_Kofler to research scripting/cmake options wrt optional dependencies
14:16:11 <Kevin_Kofler> Plus, sooner or later they want to make it yet another mandatory step for Bodhi updates, so it's better if we get it fixed by then. ;-)
14:16:15 <rdieter> #action rdieter to enable autoqa for all kde modules for f13+
14:16:33 <rdieter> anything else on the topic?
14:17:04 <than> move on please
14:17:28 <rdieter> #topic kde-4.5 update for f13
14:17:52 <rdieter> our blocker list is (essentially) clear, http://bugzilla.redhat.com/show_bug.cgi?id=kde-4.5
14:18:07 <ltinkl> let's pull the trigger :)
14:18:16 <Kevin_Kofler> Yay! So we're apparently out of fatal blockers… for now. ;-)
14:18:18 <rdieter> i will soon make a dist-f13-kde koji target to do the builds
14:18:21 <Kevin_Kofler> Let's get it into testing.
14:18:38 <Kevin_Kofler> Somehow I suspect more regressions will be found there, but maybe I'm too pessimistic.
14:18:53 <Kevin_Kofler> I don't see a good reason not to try to put it into testing in any case.
14:18:54 <rdieter> Kevin_Kofler: that's to be expected with more people using it
14:18:55 <thomasj> Get it out the door.
14:19:04 <Kevin_Kofler> Testing is what updates-testing is for. ;-)
14:19:10 <ltinkl> I don't see anything weird, having been running 4.5.2 the last 2 weeks or so
14:19:19 <rdieter> yeah, it's pretty solid.
14:19:29 <ltinkl> maybe except that clicking-https-link bug
14:19:40 <Kevin_Kofler> We already have a patch for that, don't we?
14:19:45 <than> Kevin_Kofler: yes
14:19:45 <ltinkl> ye, I think so
14:19:49 <rdieter> subtopic: making an *unofficial* kde-4.5.x update for f12
14:19:50 <rnovacek> ltinkl: Yes, this is fixed now
14:20:16 <ltinkl> rdieter: go for it as well, imho
14:20:19 <rdieter> I'v'e also pinged rel-eng about making a dist-f12-kde koji target for an unofficial update to be hosted @ kde-redhat, which will include ppc builds too.
14:20:20 * Kevin_Kofler would like to just make it an official update for F12 too… But everyone else was against it last time we discussed it.
14:21:03 <rdieter> I'll run that by FESCo asap, to make sure they're ok with it (I don't suspect any objections)
14:21:53 <rdieter> implementation wise, we can either to the f12 builds from the f13 branch in git, or we can make a separate f12/unofficial branch or something (I don't care either way really)
14:22:15 <Kevin_Kofler> f12/kde45 branch?
14:22:28 <rdieter> as long as the bikeshed is blue. :)
14:22:37 <than> rdieter: +1
14:22:51 <Kevin_Kofler> At least for some packages, we might need a separate branch.
14:22:57 <Kevin_Kofler> (e.g. kde-settings)
14:23:15 <Kevin_Kofler> Question: will the dist-git setup allow us to actually build from a non-master branch?
14:23:16 <rdieter> oh eww, hadn't considered kde-settings, well we can work out the details later
14:23:53 <rdieter> rel-eng tickets,
14:23:59 <rdieter> dist-f12-kde : https://fedorahosted.org/rel-eng/ticket/4196
14:24:13 <rdieter> dist-f13-kde : https://fedorahosted.org/rel-eng/ticket/4195
14:25:08 <rdieter> any other comments?
14:26:08 <rdieter> moving on...
14:26:15 <rdieter> #topic qca(2) renames
14:26:20 <rdieter> killefiz: ?
14:26:40 <killefiz> this is about the qca2 - rename
14:26:44 <rdieter> .bug 512000
14:26:46 <zodbot> rdieter: Bug 512000 rename qca-ossl -> qca2-ossl (or rename qca2 -> qca) - https://bugzilla.redhat.com/show_bug.cgi?id=512000
14:26:47 <rdieter> this one? ^^
14:26:51 <killefiz> you had talked about renaming qca2 -> qca
14:26:53 <killefiz> yep
14:27:13 <killefiz> I talked to upstream - and while they don't care much about the name we choose there are a couple of reasons for keeping qca2 as name
14:27:23 <killefiz> a) consistency (debian has qca2 too)
14:27:35 <killefiz> b) qcatool2 and qca2.pc are shipped in the package
14:27:47 <killefiz> so I would suggest keeping qca2
14:27:53 <rdieter> I'm ok with keeping qca2 too , so rename qca-ossl ?
14:27:57 <killefiz> and to rename the plugins
14:28:06 <killefiz> yes - there are a few more plugins
14:28:06 <Kevin_Kofler> Debian always uses suffixes even for the default version.
14:28:11 <Kevin_Kofler> Fedora usually doesn't do that.
14:28:28 <Kevin_Kofler> Distributions are different.
14:28:30 <rdieter> killefiz: I agree, I'd say 'just do it''
14:28:41 <Kevin_Kofler> (That said, some packages in Fedora do things differently, e.g. gtk2.)
14:29:00 <killefiz> sure - but then we would end up with the package qca shipping qcatool2 and -devel shipping qca2.pc - pretty confusing
14:29:12 <Kevin_Kofler> The rule of thumb around here is generally for default versions not to carry a version suffix, but then not all packages honor that.
14:29:20 <killefiz> there is qca-gnupg and qca-ossl
14:29:28 <Kevin_Kofler> I don't see it as being really confusing.
14:29:36 <Kevin_Kofler> We also have kdelibs-devel shipping several *4 executables.
14:29:41 <rdieter> I'd prefer to use common-sense, there's a lot of good reason to use qca2 here
14:29:47 <Kevin_Kofler> Even kdelibs has kded4.
14:30:00 <rdieter> Kevin_Kofler: we could've kept it named as kdelibs4  :)
14:30:00 <Kevin_Kofler> And qt-devel has qmake-qt4 etc.
14:30:10 <ltinkl> yes because kded might be running for kde3 apps :)
14:30:13 <Kevin_Kofler> But we didn't do it because Fedora doesn't work that way. :-)
14:30:23 <rdieter> and qt4-devel , and in some respects, would've reduced confusion
14:30:59 <rdieter> to this day, we still generally encourage everyone to use: BR: qt4-devel or kdelibs4-devel instead of qt-devel kdelibs-devel
14:31:01 <killefiz> also keeping qca2 should result in fewer required rebuilds
14:31:10 <rdieter> that too.
14:31:23 <Kevin_Kofler> killefiz: Have qca Provides: qca2 just like qt, kdelibs etc. do.
14:31:31 <Kevin_Kofler> Then only qca needs to be rebuilt.
14:31:54 <rdieter> ok, sounds like we have a difference of opinion here.  killefiz and I in favor of keeping qca2, Kevin_Kofler => renaming to qca.  anyone else ?
14:32:12 <ltinkl> indifferent
14:33:07 <rdieter> than, thomasj, foo* ?
14:33:08 <Kevin_Kofler> than: You were the one who pushed strongly for having qt4 renamed to qt, what do you think?
14:33:21 <thomasj> rdieter, keep qca2
14:33:25 * than doesn't like prefix here
14:33:34 <rnovacek> +1 for keeping qca2
14:33:36 <rdieter> actually, I recall caillon pushing for qt too (a bit ironic)
14:33:38 <Kevin_Kofler> I'd prefer qca for consistency, but I don't feel all that strongly as long as it works.
14:33:41 <than> +1 for qca
14:33:45 <Kevin_Kofler> rdieter: Right.
14:34:01 <Kevin_Kofler> Quite funny considering how they have gtk2 and now gtk3.
14:34:21 <rdieter> the prefix makes a lot of sense, if you're planning to have parallel-installable stuff for awhile
14:34:29 <rdieter> well, postfix, but whatever.
14:34:42 <Kevin_Kofler> rdieter: But here we already EOLed qca 1.
14:34:53 <Kevin_Kofler> Nothing was using it anymore.
14:35:07 <killefiz> qca3 or 2.1 isn't planned currently
14:35:18 <rdieter> qca2 calls itself qca2 internally all over the place.  calling it anything else is silly to me
14:35:50 <rdieter> so, we're torn.
14:35:57 <killefiz> rdieter: all over the place except in the tarball - that is called qca-2.0.2.tar.bz2
14:36:11 <rdieter> killefiz: pardon my ignorance, you a qca(2) (co)maintainer?
14:36:47 <killefiz> maintainer - I used to be the comaintainer but inherited it when it got orphaned
14:37:07 <ltinkl> +1 for keeping qca2
14:37:14 <rdieter> ok, then... I'd say leave the final call up to the maintainer(s) in question, how they best want to proceed.
14:37:15 <killefiz> I'm also the maintainer of qca-ossl and comaintainer of qca-gnupg (or maybe the other way around)
14:37:53 <killefiz> ok - I'll prepare updated qca2-ossl and qca2-gnupg packages and email the fedora-kde list when they're in for review
14:37:56 <rdieter> is that acceptable to everyone?
14:39:34 * rdieter takes that as a yes
14:39:39 <rdieter> #action killefiz, and fellow qca (co)maintainers, will work toward renaming existing qca plugins to use qca2- prefix
14:39:50 <Kevin_Kofler> Yeah, whatever. As long as you don't call some QCA 1 package qca2 (like Debian's kdelibs4c2a which is kdelibs 3), it doesn't bother me that much.
14:40:21 <rdieter> #topic putting k3b back on live image, minimizing k3b-common
14:40:48 <rdieter> Kevin_Kofler noticed yesterday we now have ~15mb space on kde live images, so we can consider adding something... he suggested k3b.
14:41:17 <rdieter> but it currently has a footprint of ~29mb (uncompressed)
14:41:36 <thomasj> We could add kde-partitionmanager and/or luckybackup
14:41:47 <nucleo> add konq-plugins
14:42:03 <Kevin_Kofler> K3b was what we removed last because we considered it most useful.
14:42:29 <rdieter> I agree, but only if we can make it fit of course.
14:42:34 <Kevin_Kofler> If we have space left after readding K3b, we can consider konq-plugins.
14:43:06 <rdieter> so, it'll take someone working to see if there's anything in k3b or k3b-common that can be safely excluded or split out.
14:43:09 <Kevin_Kofler> kde-partitionmanager, maybe, it'd make the live image usable for some rescue duties. Any idea how much space it needs?
14:43:33 <thomasj> Nope
14:43:54 <rdieter> on my box, it's ~2.4mb
14:44:02 <Kevin_Kofler> A problem is that it needs to be run as root for many tasks.
14:44:25 <Kevin_Kofler> It doesn't use KAuth nor services such as udisks where it'd make sense to do that.
14:44:37 <thomasj> Source has 570,8 KiB
14:44:45 <rdieter> who maintains kde-partitionmanager ?
14:44:51 <thomasj> me
14:45:00 <rdieter> (I ask, because I don't see it in comps at all, optional or otherwise... hint hint)
14:45:03 <Kevin_Kofler> luckybackup, hmmm, I'm not familiar with that tool at all.
14:45:10 <ltinkl> thomasj: hey :) here's a nice task for you, port it to KAuth
14:45:14 <thomasj> luckybackup is teh awesome
14:45:27 <thomasj> ltinkl, heh :)
14:45:42 <rdieter> thomasj: even if we don't put it on live image, we could still make it part of kde-desktop default
14:45:46 <ltinkl> thomasj: should be fairly easy, you can always poke rnovacek or jreznik for help :)
14:46:07 <rdieter> same for luckybackup, don't see that in comps anywhere either.
14:46:15 <Kevin_Kofler> Hmmm, luckybackup uses rsync, I'm not sure that's something an average user will like.
14:46:17 <thomasj> rdieter, right, i will add it to comps
14:46:22 <Kevin_Kofler> rsync is optimized for network operation.
14:46:36 <thomasj> Kevin_Kofler, it's a GUI for rsync
14:46:40 <Kevin_Kofler> If you sync to e.g. an external HDD, it's much slower than just erasing the disk and doing a recursive copy of everything.
14:46:48 <thomasj> Kevin_Kofler, and it's really nice. Try it once
14:47:04 <Kevin_Kofler> rsync is way too slow for backing up my huge mountains of data.
14:47:21 <Kevin_Kofler> cp -R to an external HDD is the only thing that works (and it takes hours).
14:47:35 <rdieter> ok, sounds like we have a bigger discussion to have regarding adding stuff to kde-desktop in comps', *then* whether or not to include any of these pieces on the live image
14:47:51 <thomasj> It works for the huge amounts of data here (well huge == 2TB)
14:47:59 <rdieter> can those interested either take that discussion onlist or back to #fedora-kde after meeting?
14:48:14 <thomasj> sure
14:48:14 <Kevin_Kofler> Another big problem is that rsync relies on checksums, so hash collisions can corrupt your backups.
14:48:37 <rdieter> thomasj: thanks.
14:48:45 <Kevin_Kofler> (but on the other hand, mirrors of GNU/Linux stuff get away with it)
14:49:09 <rdieter> in the meantime, I'd encourage everyone to doublecheck their (gui) app's entries in comps, to make sure they're at least present (optional)
14:49:18 <Kevin_Kofler> So in short, I'm really not sure whether luckybackup is a useful app to ship by default (neither convinced it is nor convinced it isn't).
14:49:42 <rdieter> #topic open discussion
14:50:07 <rdieter> we've got about ~10 minutes left.  anything else?  or can continue to the comps/what-to-put-on-live-image discussion
14:50:08 <Kevin_Kofler> Hmmm, have we made any decision on k3b?
14:50:42 <rdieter> [09:49] <rdieter> so, it'll take someone working to see if there's anything in k3b or k3b-common that can be safely excluded or split out.
14:50:53 <rdieter> ^^, ie, anyone able/interested in working on that?
14:50:55 <than> Kevin_Kofler: yes, we need someome to work on this
14:50:57 <Kevin_Kofler> If you want to just leave it open to anybody to split whatever they want, I can have a try, but then you might end up with finely chopped subpackages. ;-)
14:51:14 <than> who ist k3b maintainer?
14:51:14 <rnovacek> I can try it
14:51:26 <rnovacek> than: I'm
14:51:31 <Kevin_Kofler> (Because I'd put the priority on minimizing the stuff for the live image and splitting out everything optional.)
14:51:32 <than> ah ok :)
14:52:02 <rdieter> find what, if anything, can be excluded or split, and make proposals back to the group.
14:52:19 <Kevin_Kofler> My suggestions for splitting: -l10n (all the .mo files), -themes (all the non-default themes, especially since they're uncompressible PNGs), -extras (data for weird formats like Photo CD or CD-I which most people don't need).
14:52:33 <rdieter> bonus points for making a test live image with proposed changes, to ensure that it still fits
14:52:48 <Kevin_Kofler> (Most of the latter stuff is even in an "extra" subfolder of %{_kde4_appsdir}/k3b.)
14:53:17 <Kevin_Kofler> Splitting out l10n definitely makes sense, we don't ship any kde-l10n-* on the live image, nor koffice-l10n.
14:53:31 <Kevin_Kofler> (Well, IMHO it definitely makes sense.)
14:53:50 <rdieter> Kevin_Kofler: if locales to get split out, then we need to remember to add that subpkg to all the <lang>-support groups in comps
14:54:15 <rdieter> (which won't be fun)
14:54:53 <Kevin_Kofler> Hmmm, just a copy&paste job.
14:54:54 <rdieter> but it'll largely be a copy-n-paste operation all over
14:55:18 <Kevin_Kofler> Yeah. :-)
14:55:31 <rnovacek> ok, I'll look how k3b can be splitted
14:56:36 <rdieter> alright, any closing remarks before we end the meeting?
14:56:46 <rdieter> 60
14:57:11 <rdieter> 30
14:57:18 <Kevin_Kofler> #action rnovacek to look into splitting K3b
14:57:33 <rdieter> 10
14:57:43 <rdieter> Thanks everyone!
14:57:46 <rdieter> #endmeeting