15:08:24 <Kevin_Kofler> #startmeeting KDE SIG Meeting 15:08:24 <zodbot> Meeting started Tue Oct 14 15:08:24 2014 UTC. The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:08:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:08:30 <Kevin_Kofler> #meetingname kde-sig 15:08:30 <zodbot> The meeting name has been set to 'kde-sig' 15:08:33 <Kevin_Kofler> #topic Roll call 15:08:37 * Kevin_Kofler is present, who else? 15:08:45 * jgrulich is present 15:08:47 * heliocastro present 15:09:10 * jreznik is here but not feeling very well, probably will leave soon 15:09:12 * rdieter waves 15:09:44 <than> present, i'm not feeling well, probably will leave soon 15:09:57 <tosky> hi 15:10:29 <Kevin_Kofler> #chair jgrulich heliocastro jreznik rdieter than tosky 15:10:29 <zodbot> Current chairs: Kevin_Kofler heliocastro jgrulich jreznik rdieter than tosky 15:10:54 <pino|work> me too 15:12:12 <Kevin_Kofler> #chair pino|work 15:12:12 <zodbot> Current chairs: Kevin_Kofler heliocastro jgrulich jreznik pino|work rdieter than tosky 15:12:21 <Kevin_Kofler> #info Kevin_Kofler, jgrulich, heliocastro, jreznik, rdieter, than, tosky, pino|work present. 15:12:25 <Kevin_Kofler> #topic Agenda 15:12:38 <Kevin_Kofler> So, let's get to the point, if there is even one. 15:13:41 <Kevin_Kofler> I could bring up the missing comps support in Apper again, but mostly it'd just be a call for help. A month pretty much went by and I didn't really get anything done, I just didn't have any time to spend on this issue. :-( 15:14:20 <rdieter> you got a development environment going (or close to going) :) 15:14:42 <Kevin_Kofler> Yeah, and other than that, all I really have is a 3-line or so configure.ac patch to make libhif look for libcomps. 15:15:03 <heliocastro> What apper need to do ? 15:15:20 * heliocastro doesn't know the issue, need just clarify 15:15:21 <Kevin_Kofler> Actually, it's not Apper that needs improvement, but PackageKit-hif. 15:15:47 <Kevin_Kofler> The issue is that PackageKit's new backend in F21 does not support comps groups, and thus Apper has no categories to browse. 15:16:42 <Kevin_Kofler> It shows the default hardcoded PackageKit "groups", but those aren't browsable either because there's nothing implementing that: It would also have to map those PackageKit groups to comps groups. 15:17:15 <rdieter> .bug 1098735 15:17:16 <Kevin_Kofler> But what Apper really wants is what PackageKit calls "dynamic categories", which are comps groups fetched at runtime from comps. 15:17:18 <zodbot> rdieter: Bug 1098735 apper: PackageKit-hif (hawkey) backend missing comps group support - https://bugzilla.redhat.com/1098735 15:17:19 <rdieter> some background ^^ 15:17:26 <Kevin_Kofler> rdieter: Thanks for digging up the link. 15:17:40 <Kevin_Kofler> #topic Bug 1098735 apper: PackageKit-hif (hawkey) backend missing comps group support - https://bugzilla.redhat.com/1098735 15:17:47 <Kevin_Kofler> Let's officially make this the topic. 15:18:33 <Kevin_Kofler> #info Kevin_Kofler tried to work on this, but so far only has a configure.ac patch to make libhif look for libcomps and no actual code. 15:19:55 <heliocastro> Is KDE/Qt specific of affects more than that ? 15:20:45 <Kevin_Kofler> heliocastro: It does not affect gnome-software, which uses only AppStream data these days. 15:20:56 <heliocastro> Ok 15:21:02 <Kevin_Kofler> It never used the dynamic categories and they also don't use the hardcoded PackageKit categories anymore. 15:21:21 <Kevin_Kofler> Whether there is any other PackageKit client that is affected, I don't know, but in Fedora, Apper seems to be the only thing that cares. 15:21:49 <Kevin_Kofler> To be clear, there are 2 group APIs in PackageKit: 15:23:06 <Kevin_Kofler> 1. static groups: A hardcoded list of groups, defined by PackageKit (actually, the backend, but they all basically define the same thing ;-) ). The backend needs to provide a way to enumerate the packages from there. In Fedora, that means mapping them to (lists of) comps groups and enumerating those. Thus, this doesn't work in PackageKit-hif right now because it doesn't process comps. 15:23:55 <Kevin_Kofler> 2. dynamic categories: In Fedora, those come directly from comps, i.e. a category IS a comps group. There too, the backend needs to provide a way to enumerate the packages from there. Needless to say, these don't work at all in PackageKit-hif because they're entirely comps-based. 15:24:43 <Kevin_Kofler> Most important for Apper would be 2. (Apper only falls back to the static groups (1.) if enumerating the categories fails for some reason, e.g., if the backend is busy), but making 1. work too is probably relatively easy once everything is set up for 2. 15:25:57 <Kevin_Kofler> What happens right now is that Apper shows the static groups (because the dynamic categories are entirely unavailable), and then trying to click on one of those just leads to an error message ("not implemented yet"). 15:26:05 <Kevin_Kofler> So the only way to install a package is to search for it by name. 15:26:19 <Kevin_Kofler> (At least that works, we tested that.) 15:27:06 <Kevin_Kofler> Another important clarification: What comps calls a "group" is the same as what PackageKit calls a "category". 15:27:23 <heliocastro> humm, is marked as blocker 15:27:40 <Kevin_Kofler> The reason for that is historical: PackageKit originally only supported the static groups, so they used the known name "groups", then they had to come up with a new term for the dynamic ones. 15:27:57 <Kevin_Kofler> Blocker for Final, yes, it was rejected as a blocker for Beta. 15:28:21 <Kevin_Kofler> Whether it will really withstand the Final Blocker reviews is also not sure, because technically you CAN install packages, if you know the name. 15:28:38 <Kevin_Kofler> In the end, it will probably depend on how important it is to US. 15:28:53 <danofsatx> oh, btw folks, I'm here, just busy. sorry if I missed any votes so far :( 15:29:12 <danofsatx> now that I've read the backlog, hi! 15:29:31 <Kevin_Kofler> danofsatx: Nope, we've been discussing only this Apper/PackageKit issue right now, and there's nothing to vote on there really. 15:29:38 <danofsatx> I see that ;) 15:29:54 <Kevin_Kofler> Except if you propose a vote to withdraw the proposal for Blocker. I don't think that's a good idea. 15:30:02 <Kevin_Kofler> #chair danofsatx 15:30:03 <zodbot> Current chairs: Kevin_Kofler danofsatx heliocastro jgrulich jreznik pino|work rdieter than tosky 15:31:51 <Kevin_Kofler> What this really needs is developer time, for which you are not a candidate. :-) 15:34:29 <heliocastro> where is the git/svn code for the backend ? 15:35:00 <Kevin_Kofler> It's all on github, let me dig up the links: 15:35:23 <Kevin_Kofler> https://github.com/hughsie/PackageKit β PackageKit including the backends 15:35:36 <Kevin_Kofler> https://github.com/hughsie/libhif β the underlying library 15:36:06 <Kevin_Kofler> Then there are the libraries libhif itself uses: hawkey, librepo, libsolv, and we'll want to add libcomps to the mix. 15:36:21 <Kevin_Kofler> https://github.com/akozumpl/hawkey 15:36:44 <Kevin_Kofler> https://github.com/Tojaj/librepo 15:37:11 <Kevin_Kofler> https://github.com/openSUSE/libsolv β Yes, this comes from the green reptilian competition. ;-) 15:37:34 <Kevin_Kofler> https://github.com/midnightercz/libcomps 15:37:39 <rdieter> s/competition/collborators/ :0 15:37:59 <Kevin_Kofler> but you can also just rebuild those from the F21 SRPMs. 15:38:06 <Kevin_Kofler> You shouldn't have to modify anything below libhif. 15:40:01 <Kevin_Kofler> And so that you don't have to fight the autocrap yourself: http://repo.calcforge.org/temp/0001-configure.ac-Add-checks-for-libcomps.patch 15:41:21 <heliocastro> Thanks 15:42:34 <rdieter> looks like libcomps uses cmake, but provides neither pkgconfig files or cmake config files (yet) 15:43:15 <Kevin_Kofler> The idea is to download the comps XML using librepo, then to feed it to libcomps, and then to convert the resulting custom C object tree to a GObject tree. 15:43:25 <Kevin_Kofler> Then, in PackageKit-hif, work with that tree. 15:43:51 <Kevin_Kofler> Technically, it would be possible to pass the comps objects directly out of libhif, but I think hughsie would not like that. 15:44:51 <Kevin_Kofler> (The libhif API shouldn't really expose libcomps internals, and everything is GLib-based, so it should use GObjects.) 15:49:47 <Kevin_Kofler> (And yes, I'd rather use QSharedData than GObject, but libhif is not about to grow a dependency on QtCore any time soon. ;-) Too bad. :-( ) 15:53:03 <Kevin_Kofler> (Even plain C++ objects would not be welcomed, the code is all plain C. GNOME-style object-oriented C, of course.) 15:54:12 <Kevin_Kofler> So, heliocastro, can I put in the meeting summary that you are looking into this issue? 15:54:46 <heliocastro> Kevin_Kofler: I will look 15:54:55 <Kevin_Kofler> #action heliocastro will look into this issue. 15:55:13 <heliocastro> But can't promiss anything until i take a closer look. I need understand all libs and need to do on off time 15:55:16 <heliocastro> Thanks 15:55:25 <Kevin_Kofler> Good luck, I hope you'll get farther than me. If you need any help that you think I can give you, just ping me on IRC. 15:56:47 <Kevin_Kofler> (but if you need some information about GObject internals, better ask the G* developers, I have only limited knowledge of GObject, and only really from the side of the user of the object) 15:57:51 <Kevin_Kofler> #topic Open discussion 15:58:03 <Kevin_Kofler> So I think that was all on this bug / missing feature. 15:58:13 <Kevin_Kofler> Is there anything else to discuss? 15:58:14 <drago01> https://developer.gnome.org/gobject/stable/ 15:59:03 <Kevin_Kofler> drago01: Uhm yeah, at least that has nonempty documentation. :-) Thanks for the link! 15:59:16 <drago01> np 16:00:05 <Kevin_Kofler> heliocastro: By the way, unfortunately, hawkey etc. have very incomplete documentation. What really helps is the test suite, that often tells you 1. how to call the functions correctly and 2. what behavior you can expect from them in corner cases. 16:00:31 <Kevin_Kofler> Those libraries all have in common that they have a better test suite than documentation. 16:01:07 <Kevin_Kofler> Also, sometimes there is better documentation for the Python bindings than for the actual C code, but some of it also applies to the native C API. 16:01:29 <Kevin_Kofler> So, in short, you have to look for the documentation in non-obvious places. 16:02:14 <heliocastro> Kevin_Kofler: Non obvious places -> CODE 16:02:20 <Kevin_Kofler> :-) 16:02:22 <heliocastro> Life of open Source Programmer 16:02:35 <Kevin_Kofler> The test suite is easier to understand than the actual source code though, just a hint. 16:03:03 <heliocastro> Hah, could name a blog L.O.S.P., and a logo that looks like Lost tv show logo 16:03:10 <Kevin_Kofler> It'd be great if those RH-developed libs had at least as decent documentation as GLib/GTK+, ideally as decent as Qt, but alas, that apparently wasn't a requirement from RH management. 16:03:11 <heliocastro> ItΕ kind of the same 16:03:31 <Kevin_Kofler> You'd expect company projects to have decent documentation. 16:03:55 <heliocastro> I expect a lot of things, now, i expect my pasta been done in a few minutes :-) 16:04:07 <Kevin_Kofler> (And yes, I implied that Qt has better documentation than G*, that was intentional. :-) ) 16:04:57 <Kevin_Kofler> So, we're out of time, I think we're done for today, or is there anything else? 16:06:05 <Kevin_Kofler> OK, thanks all for coming! 16:06:07 <Kevin_Kofler> #endmeeting