[11:13] Hi all === genii_ is now known as genii [15:27] good afternoon everybody [15:27] RikMills: If you have a few minutes I would like to discuss a few things about packaging/KA [15:27] santa_: ok [15:28] ok, so first of all, last time I checked there was an empty binary package for kdesignerplugin [15:29] http://tritemio-groomlake.duckdns.org/build-status/buildstatus_ubuntu-exp/ubuntu-exp_status_frameworks.html [15:29] ↑ I have inspected the thing and I think that empty binary package must be removed [15:30] it used to provide qt designer plugins, which are now located in the -dev packages of frameworks [15:30] yes [15:31] also, being a qt designer plugin package nothing should build depend on it, unless we did that by mistake [15:32] so, if you agree, I'm going to remove the bin package in question and proceed with yet another test rebuild of everything (just in case) [15:33] Reverse-Build-Depends [15:33] ===================== [15:33] * akonadi (for kdesignerplugin) [15:33] * akonadi (for kgendesignerplugin) [15:33] * kdelibs4support (for kdesignerplugin) [15:33] * kdelibs4support (for kgendesignerplugin) [15:33] * kpimtextedit (for kgendesignerplugin) [15:33] * plasma-workspace (for kgendesignerplugin) [15:33] * skrooge (for kgendesignerplugin) [15:33] so we must fix akonadi and kdelibs4support then [15:35] build depends originate in debian [15:36] it's like the intro of fallout [15:36] "Debian. Debian never changes." [15:37] that being said, if you agree, I would do this change locally and test rebuild all of plasma and applications, just in case [15:38] I could start tonight with that, as soon as my servers finish the current build of apps 19.08 [15:38] akonadi: find_package(KF5DesignerPlugin ${KF5_MIN_VERSION} CONFIG) [15:40] so the build depend was probably put there by their "wonderful" tooling [15:41] anyway that find_package will probably suceed without the kdesignerplugin binary package installed [15:42] because right now it doesn't install any files, and akonadi and kdelibs4support were sucessfully built, even against that empty binary package [15:44] any further comments? [15:44] bd on kgendesignerplugin as well, so probably succeeds on that [15:44] nope. if things still build, that is fine [15:44] yes, I think that's the one it should build depend on [15:45] ok, so I will test this change asap, probably tonight [15:45] next topic [y/n]? [15:46] please do test asap, as I would like to get fw 5.62 in as soon as possible [15:46] there is Qt 5.12.5 coming very soon! [15:46] ok ok [15:46] Y [15:47] ok, next thing is something which has been done the wrong[*] way for a long time in kubuntu, neon and debian [15:48] [*] wrong, wrong, wrong, very wrong, WRONG, WROOOOOONG [15:48] o_O [15:50] this may not be the best example, but: [15:50] https://packaging.neon.kde.org/kde/kactivities-stats.git/commit/?h=Neon/unstable&id=e5ff60a047a0845ae1537c42856fe945850ef520 [15:51] probably that file [15:51] /usr/share/qlogging-categories5/kactivities-stats.categories [15:51] should go into a -data package [15:52] I doubt very much that file path would change with an soversion bump [15:53] I thought about it, but deferred that to see what debian did [15:55] with 'debian' you mean the 'bright individual' in charge of kde packages [15:56] * RikMills shrugs [15:56] I was just thinking what sort of delta to fix would be the lesser of 2 evils to fix [15:56] * RikMills removes one fix there [15:58] this is probably how the guy works (note that incompetent people is difficult to predict): [15:59] - if he does the file addition, he will probably get it wrong [15:59] - if he merges from neon and it's wrong in neon, he will keep it wrong [16:00] - if he merges from neon and it's right in neon, he will probably keep it right [16:01] in any case, this is my general recommendation for you for this kind of file additions: [16:01] - get it right in neon [16:01] - see what debian's 'bright individual' doesn [16:01] I will keep that in mind [16:02] - if he does it wrong, file an RC bug against the package in debian [16:02] (yes, you can do that) [16:02] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#shared-library-support-files [16:02] it's a violation of a must policy [16:03] last time I checked that qualifies for an RC bug [16:04] and if he refuses to fix it, as far as I know, you can call debian's technical committee [16:04] that seems a tad much [16:06] just FYI [16:07] understood [16:07] in any case he already uploaded fw 5.61 to experimental, so he will probably do the file addition himsels, so he will probably do it wrong [16:07] s/himsels/himself/ [16:10] anyway, maybe it's a bit late to fix kactivities-stats since the official release of 5.62 is going to be soon [16:10] but please keep this in mind in the future [16:11] and if they refuse to fix it in debian, please slap the debian policy 8.2 in their faces [16:11] they don't even respect their own policy [16:13] ok [16:13] so... [16:13] move to the next topic [y/n]? [16:15] y [16:16] ok, now KA [16:16] last time we talked we discussed some changes about ubuntu_info.py [16:17] I was able to make one of the changes and the other one was a circular impossibility so I couldn't make it [16:17] anyway the result isn't bad imho [16:17] what I could do is moving the ubuntu releases and versions map, which is now in ka-metadata [16:18] specifically in ubuntu-release-info.json [16:19] what I couldn't do is having the :ubuntu-devel: thing in the configuration file [16:19] so for each ubuntu release we would have to update that JSON file in ka-metadata and the default config file [16:20] but we don't have to alter the code, so it's already much better than what we had imho [16:20] fair enough [16:21] last but not least, for 2.4 and above I made a draft of a new data file, which would take over some config variables [16:22] this one: https://git.launchpad.net/~kubuntu-packagers/ka/+git/ka-metadata/commit/?id=5e32f28620e7e743b6aa20e2d0d42be62ba501c3 [16:23] I think that way is going to be much easier to add new package sets [16:24] keep in mind that we could have new 'release types' in the future [16:25] such as 'frameworks6' 'kde-req' 'kde-extra'... [16:25] so I have the impression it will be easier to manage it that way [16:26] sounds that way [16:26] so to sum up, for new ubuntu releases: [16:27] 2.3 -> update default config and ubuntu-release-info.json [16:28] >= 2.4 -> update default config, git-remotes.json and default branches @ ubuntu-release-info.json [16:29] any questions? [16:30] don't think so [16:32] ok, thank you very much for your attention and you time, I will try to test the kdesginerplugin thing asap [16:33] santa_: thank you for all that :) [16:33] no prob [19:16] mamarley @DarinMiller have you tested frameworks 5.62 ins staging? [19:16] RikMills: Yep, no problems here. Thanks for the hard work! [19:17] great. hopefully that will be ok for a FFE [19:18] If you want me to post my experience on the request somewhere, I would be happy to. [19:20] mamarley: LP: #1843866 [19:20] Launchpad bug 1843866 in plasma-framework (Ubuntu) "[FFe] KDE Frameworks 5.62.0 into Eoan archive" [Undecided,New] https://launchpad.net/bugs/1843866 [19:20] :) [19:20] not even released yet, but I am getting ready! [19:21] Done :) [19:22] TY :D [21:30] Are there openconnect 8 Builds for 18.04 anywhere?