15:03:34 <rdieter> #startmeeting kde-sig
15:03:34 <zodbot> Meeting started Tue Dec  9 15:03:34 2014 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:38 <rdieter> #meetingname kde-sig
15:03:38 <zodbot> The meeting name has been set to 'kde-sig'
15:03:43 <rdieter> #topic roll call
15:03:51 * pino|work o/
15:03:56 <rdieter> hello all, friendly kde-sig meeting, who's present today?
15:04:04 <jgrulich> hello
15:04:45 <than> present
15:05:00 <tosky> hi
15:05:17 <Corey84-> .fas corey84
15:05:18 <zodbot> Corey84-: corey84 'Corey84' <sheldon.corey@gmail.com>
15:05:29 * rdieter summons dvratil, ltinkl
15:05:56 <dvratil> hi
15:05:58 <Corey84-> rdieter, seeding and in -admin and the other -meeting too so i may be slow ot reply fyi
15:06:08 <Kevin_Kofler> Present.
15:06:28 <Corey84-> aka the arm one
15:06:36 <rdieter> #info rdieter pino|work jgrulich than tosky Corey84- dvratil Kevin_Kofler present
15:06:47 <rdieter> #chair pino|work jgrulich than tosky Corey84- dvratil Kevin_Kofler
15:06:47 <zodbot> Current chairs: Corey84- Kevin_Kofler dvratil jgrulich pino|work rdieter than tosky
15:07:00 <rdieter> #topic agenda
15:07:05 <rdieter> what to discuss today?
15:07:27 * rdieter has "kde applications 14.12-rc status update"
15:07:40 <rdieter> short version: its a bit of a mess
15:08:22 * dvratil will be updating KF5 5.5.0 tomorrow
15:10:35 <rdieter> #topic kf5 5.5.0
15:10:37 <rdieter> dvratil: ?
15:11:38 <dvratil> I have experimentally built KF5 5.5.0 (to be released on Thursday most probably) in COPR, everything looks OK so I'll be building tomorrow for Fedora (I hoped to do it today, but was held back by other things)
15:12:42 <dvratil> that's it pretty much :)
15:12:59 <dvratil> don't KDE Applications depend on 5.5.0 btw?
15:13:07 <rdieter> dvratil: I don't think so
15:13:18 <dvratil> good then
15:13:27 <rdieter> the few kf5 apps I've hit, build ok on my f20 box with 5.4
15:13:31 <rdieter> (so far)
15:13:55 <tosky> I forgot what was the decision: how are we going to ship translations, in Frameworks packages directly?
15:14:11 <Kevin_Kofler> Applications still comes with kde-l10n as always.
15:14:20 <Kevin_Kofler> There are just subdirectories named "4" and "5".
15:14:33 <rdieter> thanks for the update, fyi everyone else, the f21-kde and f20 koji buildroots are in place (for the kf5 5.5.0 stuff), in case you need it
15:14:53 <Kevin_Kofler> So some of our specfile scripting may need updating (especially the parts that sed CMakeLists.txt).
15:15:07 <Kevin_Kofler> But otherwise, kde-l10n is still the state of the art.
15:15:13 <rdieter> s/f20/f20-kde/
15:16:13 <Kevin_Kofler> Frameworks 5 and Plasma 5 now bundle their translations (so we ship them that way), but Applications still uses kde-l10n.
15:16:46 <Kevin_Kofler> That makes me wonder, are translations for kdelibs 4 and kde-workspace still in kde-l10n? I guess not…
15:17:00 <rdieter> we'll see
15:17:07 <rdieter> good question
15:17:32 <rdieter> #topic kde applications 14.12-rc
15:17:35 <tosky> they are still on the stable translation branches, Albert put them back to avoid problems
15:17:41 <Kevin_Kofler> OK.
15:17:41 <tosky> oh, ok, switch topic
15:17:42 <rdieter> speaking of which ...
15:17:53 <rdieter> (its kinda the same topic :) )
15:17:53 <Kevin_Kofler> We'll definitely need kdelibs 4 translations, and if we push 14.12 to F20/F21, also kde-workspace ones.
15:18:36 <rdieter> the biggest problem I see with 14.12 is the mixture of kde4/kf5 stuff
15:18:49 <rdieter> I've been focussing mostly on the simple updates of kde4 applications so far
15:19:12 <rdieter> for kf5, I'm not sure how best to handle that for < f22
15:19:44 <rdieter> we obviously want to ship the latest in f22+ (with plasma5)
15:20:31 <rdieter> not excited about considering updating any f20/f21 kde4 apps to kf5 counterparts
15:20:49 <Kevin_Kofler> Upstream considers this mixed kdelibs4 / KF5 stuff a "feature".
15:21:10 <Kevin_Kofler> Technically, there's nothing preventing using KF5 stuff on KDE 4.
15:21:17 <rdieter> I should have contributed to the kde release team discussions on the matter
15:21:27 <Kevin_Kofler> We'll want plasma-oxygen pushed and dragged in by Requires from somewhere though.
15:21:33 <rdieter> and urged some sort of kde4/kf5 separation, but too late for that now
15:21:35 <tosky> rdieter: what are your concerns about updating them? Possible Integration issues?
15:21:36 * marcdeop missed the first part of the meeting :S
15:21:58 <rdieter> tosky: that's my primary concern, yes, it's a non-trivial change
15:22:06 <rdieter> #info marcdeop present
15:22:06 <Kevin_Kofler> Oh, and for the KParts thing, that would have hit us sooner or later anyway (think also non-SC apps).
15:22:09 <rdieter> marcdeop: hello
15:22:26 <Kevin_Kofler> We'll need both versions at least of the common KParts.
15:22:43 <rdieter> one specific complication I ran into:  kate is kf5 now, but we still have many items in the distro that depend on kde4 kate (part)
15:22:43 <Kevin_Kofler> KatePart of course, almost certainly also KonsolePart, maybe some more.
15:23:23 <rdieter> so we'll need to create some kde4/compat packages
15:23:29 <rdieter> (or something like that)
15:24:13 <tosky> wasn't this discussed a bit one or two days ago on #fedora-kde? (I remember dvratil)
15:24:29 <rdieter> tosky: I mentioned it yesterday
15:25:30 <rdieter> which do folks prefer:  1.  have "kate" track latest/kf5, and create some sort of kde4-kate compat pkg   2.  have "kate" continue to track kde4, and create some new kf5-kate pkg , or 3.  some better idea?
15:26:05 * rdieter leaning toward 1, but that means most existing packages that Requires: kate-part, will likely need modification
15:26:45 <rdieter> I didnt have the foresight to name kate-part in a safer way
15:26:45 <dvratil> -1 to kf5-kate - applications should not use the kf5- prefix
15:27:13 <marcdeop> +1 for 1
15:27:15 <rdieter> dvratil: or some other bikeshed'y way to signify that it is a kf5-based
15:27:54 <Kevin_Kofler> I'd say use kate-kde4 and/or kate-kf5 suffixes.
15:28:02 <dvratil> well, we could make use of this and create a future-proof naming for parts (kate-part-qt5), and keep kate-part for KDE 4
15:28:03 <tosky> more for 1
15:28:08 <dvratil> this would require no changes to existing packages
15:28:11 <Kevin_Kofler> Both should exist at least as virtual Provides.
15:28:20 <tosky> were names changed from KDE3->KDE4?
15:28:22 * rdieter likes dvratil idea
15:28:33 <rdieter> tosky: we never had a kde3 kate-part
15:28:40 <rdieter> (since the part was included in kdelibs then)
15:28:40 <Kevin_Kofler> We did, still do.
15:28:43 <Kevin_Kofler> It's in kdelibs3.
15:28:50 <Kevin_Kofler> The KDE 3 KParts are all in kdelibs3 or kdebase3.
15:28:52 <tosky> ok, so this is just for parts
15:28:56 <tosky> not for apps I guess
15:29:41 <Kevin_Kofler> The main KDE 3 compatibility KParts we shipped are KatePart (kdelibs3, now separate), KHTMLPart (kdelibs3, still in kdelibs 4) and KonsolePart (kdebase3, now separate).
15:29:41 <rdieter> any comment/objection to dvratil's suggestion of using something like kate-part-qt5 ?
15:29:53 <jgrulich> I'm fine with that
15:30:15 <Kevin_Kofler> We're going to have KHTML of course as part of kdelibs4, but we'll want the KDE 4 KatePart and KonsolePart, too.
15:30:26 <rdieter> <nod>
15:30:34 <rdieter> Kevin_Kofler: +1
15:30:54 <Kevin_Kofler> kate-part-qt5 is OK, I think -kf5 may make more sense than -qt5, but then maybe not, not sure…
15:31:12 <rdieter> good point, I think I'd like -kf5 suffix a little better too
15:31:43 * rdieter doesn't care as long as there is a '5' in there somewhere
15:31:53 <rdieter> heh, maybe just:  kate-part-5 ?
15:31:56 <dvratil> ka5 (kde-applications-5) :D
15:32:16 <jgrulich> definitely not -ka5
15:32:23 <dvratil> :)
15:32:55 <jgrulich> -kf5 seems to me the best option
15:33:00 <marcdeop> why would you use -qt5 if it's based on kf5 rather than on qt5?
15:34:16 <Kevin_Kofler> "-ka5" doesn't make sense because there's no KDE Applications 5 release.
15:34:27 <Kevin_Kofler> It's either -kf5 or -qt5.
15:34:28 <rdieter> ok, proposal: for new kf5 kparts that would otherwise conflict with existing kde4 ones, use naming -part-kf5 suffix convention
15:34:41 <Kevin_Kofler> +1
15:34:42 <jgrulich> +1
15:34:54 <dvratil> yep, -kf5 makes more sense  i this case, +1
15:35:08 <rdieter> (so far, that will include at least:  kate-part-kf5, konsole-part-kf5)
15:35:15 <rdieter> +1
15:36:18 <rdieter> and for kde4 compat package naming?  I was initially suggesting using a kde4- prefix, and Kevin_Kofler offered a -kde4 suffix, which probably makes more sense
15:36:44 <rdieter> proposal 2: kde4 compat package naming, use a -kde4 suffix
15:36:54 <dvratil> +1
15:36:58 <jgrulich> +1
15:37:00 <ltinkl> +1
15:37:03 <rdieter> +1
15:37:49 <rdieter> ok, as I work my way through 14.12-rc stuff more, with only kf5 stuff left, I'll get to work creating the compat packages, and submit reviews
15:38:11 <rdieter> once compat pkgs are reviewed/imported, then will update their kf5-counterparts at the same time
15:39:02 <rdieter> #topic open discussion
15:39:12 <rdieter> I think thats about wrapped, up , anything else for today?
15:39:28 <Kevin_Kofler> +1 to the -kde4 suffix, for the record (of course – it was my idea :-) ).
15:39:29 <rdieter> oh, theres this F21 Release day thing. congrats and thanks everyone
15:40:08 <Kevin_Kofler> I queued Calamares for F21 updates-testing now.
15:41:00 <Kevin_Kofler> Most of the glitches and packaging issues are resolved, but EFI support is still incomplete/experimental, and there's one packaging thing I'd like to fix:
15:41:32 <Kevin_Kofler> Right now I copied the hack used by Anaconda's liveinst, where the .desktop file is set to NoDisplay=true and enabled only in the live kickstart.
15:41:36 <heliocastro> Here
15:41:43 <rdieter> #info heliocastro present
15:41:55 <pjones> Kevin_Kofler: is there anything I can do to help you move forward on efi stuff?  Is there anything specifically lacking?
15:42:08 <Kevin_Kofler> A better solution is to enable the .desktop file and have Calamares remove itself from the installed system, which is how other distros are doing it.
15:42:31 <Kevin_Kofler> So I'll need to update that.
15:43:21 <bitlord> Kevin_Kofler, is it possible to create live images (locally) for testing? (easily as it is possible now with anaconda?)
15:43:53 <bitlord> no (u)efi, but regular system(s) here
15:43:57 <rdieter> another fyi, I'll be chatting/collaborating with aseigo soon about possibly merging kolab-related stuff (as much as possible) into fedora's kdepim packaging
15:44:43 <rdieter> (not sure exactly what that means, until we meet and get nitty-gritty details)
15:45:00 <rdieter> dvratil: ^^ did you get any clues that the recent sprint?
15:45:09 <rdieter> s/that the/at the/
15:45:23 <rdieter> (iirc, there was a kdepim spring recently)
15:45:27 <Kevin_Kofler> pjones: Calamares is an installer like Anaconda's liveinst, that I'm trying to package as an alternative. For EFI, it should be creating the EFI System Partition during autopartitioning and setting its partition type before installing grub2-efi. It currently doesn't. We (Calamares upstream and me) know what needs to be done, it just has to be done.
15:45:30 <rdieter> ack, sprint!
15:45:32 <dvratil> no, we havent' discussed that much. The problem is that their kolab  stuff is not really compatible with upstream KDE PIM
15:45:44 <Kevin_Kofler> pjones: And Calamares also does not know about shim so far.
15:45:51 <rdieter> dvratil: ok, thanks, I guess I'll wait-n-see
15:45:55 <pjones> Kevin_Kofler: okay.
15:46:47 <Kevin_Kofler> bitlord: Calamares cannot CREATE live images (there are other tools for that), but you can easily create a live image with livecd-creator and put calamares on it.
15:47:19 <rdieter> Kevin_Kofler: havent you been making such live images already?
15:47:26 <Kevin_Kofler> Just write "calamares" into the kickstart. For now, you'll also have to add the Kannolo Copr unless you do a Rawhide kickstart, the official F21 update is underway.
15:47:43 <Kevin_Kofler> Yes, I have a kickstart that you can use.
15:47:56 <Kevin_Kofler> http://svn.calcforge.org/viewvc/kannolo/trunk/kickstart/
15:48:11 <rdieter> Kevin_Kofler: you're welcome to put that into the fedorahosted svn repo too
15:48:29 <rdieter> in kde-settings or whatever
15:48:47 <Kevin_Kofler> It's also possible to just "yum install calamares" on an existing live image (again, if the correct repo is enabled).
15:48:57 <Kevin_Kofler> But right now you have to run "kdesu calamares" manually.
15:49:18 <Kevin_Kofler> Getting rid of the NoDisplay=true hack is the main packaging improvement on my agenda.
15:49:41 <Kevin_Kofler> (I just need to enable the removal of Calamares during the installation then, I don't want it to show up on installed systems.)
15:50:17 <Kevin_Kofler> heliocastro: Any updates on the PackageKit stuff?
15:50:33 <Kevin_Kofler> hughsie asked you to fix some stuff in your patch, did you have a look at it?
15:50:53 <bitlord> Kevin_Kofler, thanks, that is what I used to create updated live images for me (livecd-creator)
15:51:26 <heliocastro> Kevin_Kofler: Yes, but i didn't have time to finish
15:51:38 <Kevin_Kofler> heliocastro: I agree that the formatting / coding style of the patch as you submitted it is a real mess, and his other change requests also make sense.
15:52:08 <heliocastro> formatting ok, real mess not that much. The other parts needed some redesign
15:52:18 <heliocastro> But i can escape from some globals
15:52:31 <heliocastro> Or get back to libxml parser
15:52:43 <heliocastro> I can't be blamed by the design og glib xml parser
15:52:55 <Kevin_Kofler> I also manage to mess up the coding style sometimes when I write code for projects with unfamiliar coding styles (and honestly, 90-99% are unfamiliar in one way or the other :-p), but upstreams are very picky about these things.
15:53:20 <heliocastro> anyway, that part i fixed already
15:53:35 <heliocastro> I just need to get rid od the globals as much i can
15:53:41 <Kevin_Kofler> It's just annoying to read something like this (your patch had similar constructs): my_function (x, y ) ← unbalanced spacing
15:54:11 <Kevin_Kofler> Of course it happens, but regexes are very effective at finding and fixing such things. :-)
15:54:44 <Kevin_Kofler> For the globals, don't the callbacks take a userdata pointer?
15:54:54 <Kevin_Kofler> GLib normally always uses that.
15:55:06 <heliocastro> Yes, there's one way out. But still, not sure about that
15:55:08 <Kevin_Kofler> Your globals need to go in a structure that you pass along as userdata.
15:55:23 <Kevin_Kofler> That's how this is intended to be done in GLib.
15:55:48 <heliocastro> If was me i would rewrite everything in c++ and done :-P
15:55:50 <Kevin_Kofler> In C++ you'd work with classes, but GLib has only that C way of state handling.
15:56:40 <Kevin_Kofler> Even if you do C++ with GLib, you typically work by having your class as userdata, and having a wrapper that calls ((my_class *)userdata)->my_method(…).
15:56:57 <Kevin_Kofler> In C, you don't normally do something like that (though you could, with a GObject).
15:56:59 <heliocastro> I mean *everything*
15:57:19 <rdieter> heliocastro: you can dream :)
15:57:26 <Kevin_Kofler> The typical C way is to just use a POD struct as userdata.
15:57:27 <heliocastro> But ok, i will finnish this in a few days, time is clearing up
15:57:49 <heliocastro> free time i mean
15:58:28 <heliocastro> and i can deal with dynamic groups as well
15:58:41 <heliocastro> That's all for me about packagekit
16:00:56 <Kevin_Kofler> OK, thanks.
16:02:22 <rdieter> alright, our hour is about up, and I think we ran out of stuff to talk about.. thanks everyone
16:02:33 <rdieter> #endmeeting