[05:41] <pitti> Good morning
[05:41] <pitti> bdmurray: I am now; I was on a sprint last week. Today and tomorrow I'm only here half-day, though
[05:54] <highvoltage> pitteah
[07:50] <dholbach> good morning
[08:15] <smb> mdeslaur, thanks
[09:08] <LocutusOfBorg1> dholbach, can you please sponsor the patch in #1292118 ?
[09:09] <LocutusOfBorg1> more than 238 bugs for this problem
[09:09] <LocutusOfBorg1> :(
[09:10] <dholbach> LocutusOfBorg1, hum, I don't have a precise box/vm for testing, but I can upload a test build to a ppa and let people test that first?
[09:10] <LocutusOfBorg1> I can do that
[09:11] <LocutusOfBorg1> I'm the maintainer ;)
[09:11] <LocutusOfBorg1> however I'm pretty sure the fix works, it is a plain cherry-pick from upstream, and the same usual stuff as always when a new kernel is released
[09:12] <dholbach> minor nit-pick it should be "precise-proposed" as opposed to "precise" in the changelog entry
[11:22] <cjwatson> dholbach: no, "precise" (etc.) has been auto-translated to "precise-proposed" (etc.) since the end of 2013 or so
[11:22] <cjwatson> it's acceptable to use that
[11:22] <dholbach> ok
[11:22] <cjwatson> sorry, I mean the end of 2012 or so
[11:23] <cjwatson> that's what I get for trying to do release → date conversion in my head
[11:24] <dholbach> I knew it did that for the development release, I wasn't quite sure about stable releases :)
[11:24] <infinity> We did it for all for consistency and prettiness.
[11:25] <dholbach> right, makes sense
[11:25] <infinity> I haven't had -proposed in a .changes since that day.
[11:26] <cjwatson> To be honest, I think it was initially an oversight but one that turned out to be the right thing to do.
[11:27] <cjwatson> Or maybe it was just fewer lines of code. :-)
[11:27] <infinity> cjwatson: I vaguely recall arguing specifically for the behaviour, but maybe that was after we discovered it already did that.  Old man brain, can't say for sure.
[11:27] <cjwatson> Yeah, I know we discussed it, can't be bothered to go back and look up when :-)
[11:40] <sil2100> mitya57: hey! I'm not following KDE development too much, where can I get some information about KDE's own QPA platform theme?
[11:40] <xnox> ScottK: what do you think about gnupg 2.1 as the gnupg2 package in Vivid?
[11:41] <sil2100> @pilot in
[11:41] <xnox> it seems safe enough across the board, however kubuntu does use it as the default implementation.
[11:43] <Riddell> sil2100: frameworkintegration: /usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes/KDEPlatformTheme.so ?
[12:17] <sil2100> Riddell: not sure if that's what mitya57 had in mind, since this one has been around since like forever
[12:20] <mlankhorst> @pilot in
[12:34] <sil2100> @pilot out
[12:34]  * sil2100 goes to lunch
[13:36] <sil2100> @pilot in
[14:00] <cyphermox> good morning!
[14:01] <Riddell> hi cyphermox
[14:01] <mitya57> sil2100: what Riddell pointed to
[14:02] <sil2100> Morning!
[14:02] <mitya57> Morning!
[14:02] <sil2100> mitya57: ok, then I'll have to check the source then
[14:02] <mitya57> It was not in KDE4, it's new in KDE5 (I think)
[14:02] <sil2100> Anyway, I'll try to review your branch today as well - if all goes fine we can try landing all those approved changes this week
[14:02] <mitya57> Thanks!
[14:04] <sil2100> Ah, indeed! I mischecked then, it got introduced around utopic
[14:05] <sil2100> That would explain why I didn't see it when creating appmenu-qt5 - not sure how much it was actually used in KDE around that time though
[14:05] <mitya57> sil2100: the KDE code for AppMenuPlatform{Menu,MenuItem,SystemTrayIcon} is in
[14:05] <mitya57> https://projects.kde.org/projects/frameworks/frameworkintegration/repository/revisions/master/changes/src/platformtheme/kdeplatformsystemtrayicon.cpp
[14:05] <mitya57> I meant "for QPlatform{Menu,MenuItem,SystemTrayIcon}"
[14:42] <ScottK> xnox: No opinion.
[14:50] <xnox> ScottK: you mentioned you don't run ubuntu servers, anymore. Is it no longer your responsibility or switched to another distro?
[14:56] <TheNumb> xnox: haven't you heard? Arch GNU/Linux is the new Ubuntu.
[14:56] <TheNumb> ;-)
[14:56] <mlankhorst> @pilot out
[14:59] <sil2100> @pilot out
[15:01] <gQuigs> So libnss-ldap seems dead upstream..  been waiting on versions 266 for 5 years..   I'm curious if I should push to remove it from main (for vivid+), or try to fix bugs one at a time (they say they've been committed upstream but I can't find a public SVN/CVS/etc)..
[15:01] <gQuigs> example bug: http://bugzilla.padl.com/show_bug.cgi?id=414
[15:03] <teward> is the DMB still meeting today per the agenda...?
[15:03] <Laney> dmb?
[15:03] <Laney> ha
[15:03] <Laney> !dmb-ping
[15:04] <xnox> Laney: lucky that i'm not at lunch.
[15:04] <bdrung_work> Laney, wrong channel?
[15:05] <Laney> bdrung_work: partially
[15:05] <Laney> xnox: lucky? you know when the meeting is!
[15:35] <hallyn> xnox: hey, pushed a new (trivial) netcf merge to mentors.debian.net.  something went wonky actually with the 0.2.4 experimental package (which you had taken part in) and it never showed up in debian... do you mind sponsoring the 0.2.6 version?
[15:35] <hallyn> i'm pretty sure symbols are wrong, i'll look at thta in a bit
[15:37] <xnox> hallyn: ack.
[15:49] <hallyn> xnox: but ok, i don't understand the last line in the symbols file you had created:  *@NETCF_PRIVATE_0.2.4 0 1 .  what do the '0 1' mean?
[15:53]  * hallyn tries an automated way to update
[15:53] <hallyn> based on http://pkg-kde.alioth.debian.org/symbolfiles.html
[15:55] <hallyn> fail
[15:58] <dobey> gQuigs: have you tried contacting PADL about how to check out the nss_ldap code from CVS? (based on what's in the tarball it seems they do use CVS)
[16:02] <gQuigs> dobey: nope, would we want to just pull a new (let's say vivid package) one straight from CVS?
[16:06] <dobey> gQuigs: well you were saying you couldn't find a repository. you could ask for a new tarball too, as it seems the latest is 265 and the bug talks about 266.
[16:07] <gQuigs> dobey: true, can't hurt to try pinging them..
[16:07] <gQuigs> thanks :)
[16:07] <dobey> gQuigs: indeed, my point was "try asking upstream" :)
[16:33] <hallyn> xnox: I also don't understand why you put the "| libnetcf1 (>> 1:0.2.4), libnetcf1 (<< 1:0.2.5)" in there.  why the << 1:0.2.5?
[16:33] <xnox> hallyn: sorry was out, let me look.
[16:35] <xnox> hallyn: so by default all public symbols get 1:0.2.2 as the minimal version
[16:36] <xnox> hallyn: that is all that are versioned @NETCF_1.*
[16:36] <xnox> hallyn: however, symbols that are marked @NETCF_PRIVATE_0.2.4 generate alternative depedency which is far more strict
[16:36] <xnox> libnetcf1 (>> 1:0.2.4), libnetcf1 (<< 1:0.2.5)
[16:37] <xnox> hallyn: thus if one uses public symbols only -> one gets a very lax libnecf1 (>> 1:0.2.2) dependency
[16:37] <xnox> hallyn: if one sues any of the private symbols, one will get a strict " libnetcf1 (>> 1:0.2.4), libnetcf1 (<< 1:0.2.5)" thus forcing libraries to recompile on every new major upstream release
[16:38] <xnox> (this implies that debian/ubuntu patches do not change abi of any public or private symbols
[16:38] <xnox> )
[16:38] <xnox> this is similar to libc, where you get lax dependency if one uses old symbols, but a very strict one if any of private symbols are used.
[16:39] <xnox> hallyn: so all you need to do is s/0.2.5/0.2.6/ and s/0.2.4/0.2.5/
[16:39] <xnox> hallyn: and good to go.
[16:40]  * xnox off to lucnh
[16:40] <hallyn> xnox: gotcha, thanks.  (I think - I understand what to do, but will look a bit more to see if i can avoid asking you stupid questions enxt time :)
[16:40] <xnox> hallyn: any more questions can be directed to infinity
[16:40] <hallyn> thanks, i'l lhave an update when you get back
[16:41] <xnox> hallyn: the syntax of the .symbols file is aweful, i give you that.
[16:41] <xnox> hallyn: especially the | for alternative "template" which has different structure to the "main" one and the cryptic "0 1" to switch to a different template which suddently is no longer #MINVER# variable....
[16:42] <Laney> .
[16:43] <hallyn> heh
[17:04] <hallyn> xnox: (update posted)