14:02:14 <rdieter> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-27
14:02:14 <zodbot> Meeting started Tue Jul 27 14:02:14 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:18 <rdieter> #meetingname kde-sig
14:02:18 <zodbot> The meeting name has been set to 'kde-sig'
14:02:42 <rdieter> #chair jreznik Kevin_Kofler ltinkl than thomasj SMParrish
14:02:42 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl rdieter than thomasj
14:02:47 <rdieter> #topic roll call
14:02:51 <rdieter> who's present today ?
14:02:52 <Kevin_Kofler> Present.
14:02:53 * thomasj is here
14:03:15 * jreznik is here
14:03:22 <rnovacek> \me present
14:03:28 * rnovacek present
14:03:30 * SMParrish here
14:03:32 <rnovacek> better
14:03:46 * ltinkl is here
14:04:07 <rdieter> #info rdieter Kevin_Kofler thomasj jreznik rnovacek SMParrish ltinkl present
14:04:13 <rdieter> alrighty
14:04:18 <rdieter> #topic agenda
14:04:35 <rdieter> not much of an agenda today, which I don't mind, but... anything else to add?
14:04:48 * than is present
14:05:10 <rdieter> #info than present as well
14:05:30 <than> kde-4.5rc3 status
14:05:42 <rdieter> ok, worth mentioning
14:05:54 <Kevin_Kofler> Any news from upstream about kdepim-4.5 status?
14:07:02 <thomasj> BTW kdepim status.. New grantlee is out, will package it today.
14:07:06 <than> kbattleship and ktron trademarks still in handbook
14:07:10 <rdieter> nothing new, except a couple more testamonials from folks who've tried what available now, and that it's not very good
14:07:31 <Kevin_Kofler> than: Volunteer to clean up kde-l10n? :-)
14:07:35 <rdieter> Kevin_Kofler: we can discuss that at the end if we have time
14:07:41 <than> Kevin_Kofler: it seems so
14:07:48 <rdieter> #topic kde sc 4.5 rc3
14:07:53 * Kevin_Kofler has been aware of that for a while, but hoped nobody would notice, to be honest.
14:08:14 <Kevin_Kofler> Those names are all over the translated manuals. :-(
14:08:17 * rdieter covers ears la la la
14:08:32 <than> Kevin_Kofler: ktron theme still includes Ktrom
14:08:53 <than> which i already fixed in latest rebased patch
14:09:02 <Kevin_Kofler> Good, thanks. :-)
14:09:59 <than> Kevin_Kofler: or just drop the translation for both games ;-)
14:11:08 <than> i really tend to do drop  the translation
14:11:23 <than> s/do drop/drop
14:11:25 <Kevin_Kofler> Only the manuals are the problem.
14:11:35 <Kevin_Kofler> For the strings, the translations are keyed to the English strings.
14:11:47 <Kevin_Kofler> So if we patch the English strings, we won't get the unmodified translations anyway.
14:12:41 <than> Kevin_Kofler: yes, however we have to rebuild kde-l10n
14:14:19 <Kevin_Kofler> Right.
14:14:58 <than> i will take care of it
14:15:37 <than> move on please
14:15:45 <rdieter> I'm of a mind that we're approaching a level of inconvenience that it may be worth just omitting the games altogether (and consider moving them unaltered to rpmfusion), but... if you continue to be willing to invest the time and energy to continue making things work in fedora, so be it.
14:16:36 <rdieter> otherwise, per /topic, kde-4.4.95 (4.5rc3) is all in rawhide, and kde-unstable repos for testing
14:16:42 <Kevin_Kofler> I think removing the translated manuals shouldn't be that big of a problem.
14:17:08 <Kevin_Kofler> Patching them all sounds not doable though.
14:17:36 <than> rdieter: it's fine with me jusr to omit these games
14:17:59 <Kevin_Kofler> Well, I think it's not worth it.
14:18:00 <than> and move them to rpmfussion
14:18:47 <than> Kevin_Kofler: it doesn't make sense to patch all translations
14:18:53 <rdieter> Kevin_Kofler: what's not worth it?
14:18:57 <Kevin_Kofler> And I still hope we can get upstream to solve the problem by 4.6.
14:18:57 <than> it's huge work
14:19:01 <Kevin_Kofler> rdieter: Omitting the games entirely.
14:19:05 <jreznik> yes, it's huge work
14:19:25 <jreznik> but it's for KDE good - and other distros too...
14:19:35 <rdieter> it's certainly less work to omit (and consider move to rpmfusion) than it is to continually rebase -trademark patches
14:19:39 <ltinkl> entirely? what about splitting the package and put the rest to rpmfusion
14:20:09 <rdieter> ltinkl: right
14:20:15 <than> ltinkl: no, only games which cause trademark problems
14:20:26 <ltinkl> than: yup, that's what i thought
14:20:38 <rdieter> oh
14:20:41 <rdieter> yes.
14:21:05 <than> Kevin_Kofler: is it ok for you?
14:21:17 <jreznik> I would ask kdegames maintainers again and adriaan as he's responsible for legal stuff
14:21:33 <rdieter> sorry, didn't mean to suggest dropping everything, just the -trademark stuff
14:22:08 <Kevin_Kofler> than: If you really think we should do that…
14:22:23 <Kevin_Kofler> I'd rather ship the games renamed as we're currently doing.
14:22:38 <thomasj> Asking Adrian and the Maintainers, give them two weeks deadline for an answer. If no answer within the next two weeks about what will come, split it.
14:23:16 <than> thomasj: +1
14:23:29 <jreznik> thomasj: yep! +1
14:23:39 <rdieter> there's no reason to wait, any proposed change at this point won't happen until 4.6 anyway
14:23:43 <ltinkl> sounds good
14:23:43 <jreznik> it should be fixed by 4.5 as it's legal issue
14:24:13 <rdieter> unless we leverage the legal angle I guess
14:24:16 <jreznik> it's not a good for KDE to oversight all legal issues
14:24:24 <Kevin_Kofler> jreznik: They're unlikely to rush renames into 4.5.
14:24:39 <Kevin_Kofler> It affects all the translations, including manuals as than noticed.
14:25:08 <rdieter> who want this task, to contact kdegames maintainers and kde legal ?
14:25:34 <rdieter> I'll be leaving on vacation soon, so can't (at least until I get back)
14:25:41 <jreznik> rdieter: I'll do it
14:25:48 <jreznik> I talked with Adrian a little about it
14:26:13 <rdieter> #action jreznik to contact kde legal and kdegames maintainers about trademark issues
14:26:37 <rdieter> moving on...
14:26:41 <jreznik> than: could you point me to all places where it's not fixed yet?
14:26:50 <than> jreznik: sure
14:27:15 <than> jreznik: i will send you it per email
14:27:23 <jreznik> than: thanks
14:27:28 <than> jreznik: np
14:27:32 <rdieter> #topic Sebastian Trueg recommends to set /proc/sys/fs/inotify/max_user_watches to very high value for Nepomuk
14:27:56 <jreznik> just reading mails... currently we have 8192
14:28:08 <rdieter> before we go proposing any change, I'd like to know more about the pros/cons about doing this or not.
14:28:30 <rdieter> which trueg didn't explain, afaict.
14:28:42 <jreznik> "something like 524288 might be good"
14:29:03 <Kevin_Kofler> Does the kernel actually support values that high?
14:29:09 <than> we new to know why
14:29:25 <than> the values seems very hight to me
14:29:30 <rdieter> i figure at least there's a potential increased memory cost to this
14:30:16 <Kevin_Kofler> Certainly.
14:30:17 <jreznik> 8192 is not a very big number if you consider how many files could be watched by Nepomuk
14:30:33 <rdieter> questions off the top of my head:
14:30:34 <Kevin_Kofler> But Nepomuk probably wants to watch a metric crapton of files. :-)
14:30:35 <jreznik> question is - there's probably reason why it's set to 8192
14:31:01 <rdieter> what's the downside of using a small (8192) value wrt nepomuk?
14:31:25 <rdieter> and how does a higher value help?  (and the already mentioned, what cost/downside does this encure?)
14:31:44 <Kevin_Kofler> Ask trueg for details, I'd suggest…
14:32:15 * jreznik is googling and looks like beagle is suffering too too low value
14:32:16 <than> yes, we need more details
14:32:28 <mjg59> The number reflects the maximum number of watches you can have per user. If the number of files or directories you're trying to monitor is larger than that then you'll miss change notifications.
14:32:58 <rdieter> mjg59: thanks (that was close to my suspicions)
14:33:12 <Kevin_Kofler> Silently? What a messed up API?
14:33:32 <mjg59> Kevin_Kofler: No, it'll give a failure
14:33:49 <mjg59> You simply won't get a watch handle
14:34:02 <jreznik> or it has to loop over directories to watch changes
14:34:26 * ltinkl commits another batch of solid-devicekit
14:34:31 <rdieter> so, who wants this followup task ?
14:34:33 <rdieter> ltinkl: woo!
14:34:47 <jreznik> ltinkl: great!
14:34:50 <mjg59> I don't think increasing the value increases memory usage in itself, but it does increase the amount of kernel resources a user can allocate
14:34:55 <jreznik> here is explanation for beagle http://beagle-project.org/Troubleshooting
14:35:02 <mjg59> It's probably justifiable to increase it
14:35:05 <ltinkl> rdieter, jreznik: next topic is just that :)
14:35:07 <jreznik> "Using additional watches does increase the amount of memory used inside the kernel, but increasing the number does not affect the amount of memory if they aren't used. "
14:35:49 <ltinkl> understandable but it means Nepomuk's memory usage could be even bigger that now
14:35:57 <ltinkl> and users are already complaining about that :)
14:36:01 <Kevin_Kofler> So can this be increased per spin somehow? Or would this necessarily be a global Fedora decision?
14:36:18 <Kevin_Kofler> And if the latter, where would it need to be changed? kernel? initscripts?
14:36:19 <rdieter> ltinkl: those same users probably ought to be disabling strigi indexing then
14:36:43 <ltinkl> this is something that should be asked on fedora-devel imho
14:36:44 <rdieter> Kevin_Kofler: good question, though anything not global feels very wrong
14:36:53 <mjg59> Kernel would be simplest. The alternative would be to add it to the default sysctl.conf
14:36:58 <than> it should be globol
14:37:23 <mjg59> I'd have no objection to it being increased in-kernel, but doing it in initscripts reduces the number of patches we'd need to carry
14:37:35 <mjg59> The alternative would be to make it a kernel config option and get that upstream
14:38:46 <rdieter> coolness
14:39:23 <jreznik> it looks like desktops needs bigger number and does not depend if nepomuk/beagle etc... so maybe it's worth trying it in kernel upstream
14:39:35 <Kevin_Kofler> Yeah.
14:41:03 <rdieter> ok, sounds like we all generally agree this is a good idea then, perhaps the need to get answers from trueg is less urgent.
14:41:25 <rdieter> so, then take this to fedora devel/kernel folks for comment?  who wants that job then?
14:41:35 <Kevin_Kofler> Right, I think our questions have already been answered, thanks to mjg59. :-)
14:41:37 <rdieter> (I can in ~2 weeks, if no one else does in the meantime)
14:42:57 <jreznik> it needs someone with diplomatic skills to convince others we need it :)
14:44:20 <rdieter> ok, guess it's me, feel free to usurp the job anyone, if you feel the need in the meantime
14:44:49 <rdieter> #action rdieter to contact fedora devel/kernel folks about raising /proc/sys/fs/inotify/max_user_watches
14:44:59 <jreznik> rdieter: ok, I can reply to the trueg's mail...
14:45:08 <rdieter> jreznik: cool, thanks
14:45:29 <rdieter> #topic open floor
14:45:47 <rdieter> that's it for agenda, ltinkl, you hinted about a solid status update ?
14:46:11 <ltinkl> yes just a quick note that I resumed my work on devicekit Solid backend recently
14:46:16 <Kevin_Kofler> So, do we have any news from the kdepim folks re. 4.5? (If not, it's no use discussing it any further.)
14:46:23 <ltinkl> the long term plan is to have this upstream in kdelibs for KDE 4.6
14:46:25 <Kevin_Kofler> ltinkl: Great.
14:47:04 <rdieter> ltinkl: in the meantime?  possibly usable for f14 ?
14:47:06 <jreznik> ltinkl: is it possible to implement needed hal functionality by devicekit?
14:47:08 <Kevin_Kofler> It's time we get away from being locked into HAL.
14:47:38 <ltinkl> rdieter: as F14 will have KDE 4.5, it is unlikely
14:47:47 <ltinkl> maybe F15
14:47:50 <Kevin_Kofler> (And then people wonder why KDE abstracts abstraction layers… ;-) )
14:48:15 <ltinkl> jreznik: what do you mean?
14:49:29 <rdieter> I think he was wondering about the missing pieced we'd previously mentioned in https://fedoraproject.org/wiki/DeviceKit_versus_SolidHAL
14:49:34 <jreznik> ltinkl: is it possible to implement solid backend with current devkit? so everything is in place? I think it was the problem when you tried it for the first time
14:50:04 <ltinkl> jreznik: yes, except some raraly used stuff
14:50:09 <ltinkl> rarely *
14:50:42 <ltinkl> I am currently working on getting the "content type" out of optical disks
14:51:02 <ltinkl> something that the current mime-info spec implements but KDE doesn't support unfortunately
14:51:25 <ltinkl> other missing stuff is:
14:51:28 <ltinkl> - xD cards
14:51:37 <ltinkl> not really important, never seen one :)
14:51:49 <ltinkl> - no Floppy detection
14:51:53 <Kevin_Kofler> Is Solid finally going to support LVM with udisks?
14:51:57 <ltinkl> who cares about floppies these days :)
14:52:13 * Kevin_Kofler still has a floppy drive in his desktop…
14:52:43 <ltinkl> well it knows about floppies for sure but it just doesn't "detect" them
14:52:54 <ltinkl> like CD's for example
14:53:13 * jreznik saw floppy in tbzatek's gnome cubicle :D
14:53:14 <Kevin_Kofler> Yeah, it should poll them, but udisks doesn't want to poll anything. :-(
14:53:44 <ltinkl> as for the LVM, udisks supports that I think (as of recently) but Solid doesn't; something to ask ervin (the Solid maintainer)
14:55:00 <jreznik> ltinkl: we don't need complete LVM support, just to see filesystems inside LVM
14:55:47 <ltinkl> jreznik: I know, it is doable I think, just not on the top of my TODO at the moment
14:56:07 <ltinkl> help is definitely welcome with this once I get solid-devicekit upstreamed
14:56:26 <rdieter> #info ltinkl working on solid-devicekit, targeting kde-4.6
14:56:38 <jreznik> ltinkl: LVM support should be on top of TODO for us (as Fedora defaults to use LVM)... remember kio_sysinfo hack :D
14:56:49 <ltinkl> I know :)
14:59:03 <rdieter> before we run out of time, I'd like to throw out a tease that there's a good chance we'll be bringing a good qt/kde presence to fudcon zurich , pending some financial/logistical details
14:59:38 <rdieter> otherwise, time is up for today, thanks everybody!
14:59:50 <rdieter> #endmeeting