[00:39] <valorie> http://pastebin.kde.org/pdtbrlrdb
[00:43] <valorie> gotta go, but i'll look for hints for what I did wrong/forgot
[01:04] <claydoh> Mamarok: sorry for the delay, just finishing a vacation. I can't find the email in question, but a note to him might be advisable. 
[01:04]  * claydoh catches up on the list
[01:09]  * claydoh needs to get back into the swing of things
[01:13]  * jalcine wants to get into the swing of things
[01:35] <ahoneybun> hey valorie 
[01:35] <ahoneybun> oh
[04:11] <manchicken> apachelogger: Thanks for the help
[04:18] <manchicken> apachelogger: I've got a working build again, now I'm just chasing down a series of crashes. The scenario you found a while back when you cancel immediately after starting the program is still happening, and I'm having all sorts of fun chasing it around.
[04:20] <ScottK> debfx: Just import the latest.
[05:16] <claydoh> Mamarok: perhaps the basil situation has cleared itself ? I don't think that we should worry about chatter of other distros, for example they do discuss us in  the english opensuse list, not necessarily in a negative fashion.
[05:20] <claydoh> That thread was far too confusing, I think I could have summed it up in a short, clear paragraph lol
[06:54] <Mamarok> claydoh: well, it did not, as this idiot now makes a mess about it
[06:56] <claydoh> Mamarok: "Bas, I can see that Felix has offered his expertise to help you out with 
[06:56] <claydoh> your requirements so I will let him do just that if that's all right 
[06:56] <claydoh> with you."
[06:56] <Mamarok> read all the mails, including those to -owner...
[06:56] <claydoh> bas = bas roufs, not basil chupin, that part confused me for  a sec
[06:57] <Mamarok> I did send him a private mail with copy to -owner, which only we moderators receive, but he managed to think this was a public mail and sent a copy of it to the list
[06:57] <Mamarok> *headdesk*
[06:58] <claydoh> Oh, well it's done for the time being. 
[06:59] <claydoh> and to think I may in the future move to Australia and be in clser proximity to him
[07:00] <Mamarok> you may? Interesting :)
[07:01] <claydoh> a redhead is involved :D
[07:03] <claydoh> she just went back from a visit here, now to save for a trip there
[07:07] <Mamarok> congratulations in order?
[07:26] <claydoh> Mamarok: not yet, still have to scrape money up to finally get the divorce. The Ex left, but doesn't want to foot any bills lol
[08:06] <lordievader> Good morning.
[08:44] <benvantende> morning people
[08:56] <Peace-> guys i have a very big problem with usb 
[08:56] <Peace-> they work for some time then they are dead
[08:56] <Peace-> #kernel ?
[09:04] <Peace-> reboot
[10:21] <apachelogger> oh right
[10:21] <apachelogger> Riddell, shadeslayer, ScottK: so ... yay or nay to the mail?
[10:22] <apachelogger> also I remembered that we shoudl slap a thread on kubuntuforums
[10:35] <Riddell> apachelogger: yay
[12:20] <BluesKaj> 'Morning all
[13:59] <shadeslayer> apachelogger: looks good to me
[14:02] <shadeslayer> Riddell: and it's fine for GPL code to depend on a package that is LGPL and links to openssl?
[14:02] <shadeslayer> ( GPL code doesn't link to openssl code )
[14:03] <Riddell> shadeslayer: hmm, maybe not
[14:03] <Riddell> what's the case?
[14:03] <shadeslayer> see ktp mailing list
[14:04] <shadeslayer> auth handler needs qca2 + ssl plugin
[14:04] <apachelogger> *plugin*
[14:05] <apachelogger> if $thing works without $plugin then there is no license tie between $thing and $plugin
[14:07] <apachelogger> $thing *linking* against $plugin *linking* against openssl, $thing would not work without openssl thus there is a license tie
[14:07] <shadeslayer> https://mail.kde.org/pipermail/kde-telepathy/2013-November/010409.html
[14:07] <Riddell> yes (as long as you can argue it's not a derived work)
[14:08] <apachelogger> ^ it's definitely not derived as long as A works without B, B is however a derived work of A when B is a plugin for A
[14:10] <apachelogger> if B is not a plugin for A there's also not tie there (e.g. when A would dlopen B and manually resolve symbols - as long as A still works without B)
[14:10] <apachelogger> really the question you have to ask is "does A work without B"
[14:17] <shadeslayer> As documented by the thread, A does not work without B
[14:17] <shadeslayer> causes crashes
[14:18] <apachelogger> claydoh: http://www.kubuntuforums.net/showthread.php?64098-Installing-Kubuntu-13-10-on-UEFI-SecureBoot-Systems you may want to sticky that or something
[14:20] <apachelogger> shadeslayer: well, depends on why it crashes
[14:20] <apachelogger> but if it crashes because it tries to load the plugin and can't find it then one could very likely argue for dervied work
[14:21] <d_ed> hey, I was summoned?
[14:21] <shadeslayer> yep
[14:21] <apachelogger> if it however crashes because there simply is no plugin then it's rather hard to argue for dervied work
[14:22] <apachelogger> d_ed: why does qca make apps crash without the openssl plugin?
[14:22] <apachelogger> is it because it must find it or because there is no plugin in general
[14:22] <d_ed> if you ever call QCA::fromDER() it explodes. 
[14:22] <shadeslayer> d_ed: I wish I had detachable ears
[14:22] <d_ed> we have a runtime guard from 0.6.3 onwards
[14:23] <d_ed> but then it will just not work instead of crashing
[14:23] <d_ed> which isn't exactly better
[14:24] <apachelogger> d_ed: what's the bt though
[14:26] <d_ed> https://bugs.kde.org/show_bug.cgi?id=326948
[14:29] <apachelogger> creepy codez
[14:30] <apachelogger> d_ed: that seems like a bug in qca though ;)
[14:30] <d_ed> well... part of the code it's using is missing.
[14:30] <apachelogger> shadeslayer: no derived work ... it crashes because it has no keycontext provider, not specifically because it has no openssl plugin
[14:32] <shadeslayer> 'keycontext provider" ?
[14:32] <apachelogger> plugin interface type it appears
[14:33] <apachelogger> if I write a plugin that implements a keycontext it would not crash
[14:33] <apachelogger> so it is not derived work of openssl
[14:34] <apachelogger> it is however badly written code because it crashes :P
[14:35] <d_ed> well, I want it to stop crashing.
[14:37] <shadeslayer> and it seems like a run time dependency to me, so I'm curious as to whether or not we can add it to Recommends
[14:37] <d_ed> or the depends.
[14:37] <d_ed> because it depends on it to run
[14:39] <apachelogger> d_ed: that's a bug IMO
[14:39] <apachelogger> shadeslayer: recommends probably is an option
[14:39] <apachelogger> OTOH
[14:40] <apachelogger> there are more pluing interfaces than that one so recommends may be excessive from a QCA pov
[14:40] <apachelogger> i.e. if you don't need the key interface rubbish you don't need openssl specifically
[14:41] <apachelogger> it's as if libphonon recommended libphononqml
[14:41] <apachelogger> well not really, but equally excessive :P
[14:41] <apachelogger> shadeslayer: IMHO the recommends ought to be on auth-handler
[14:41] <apachelogger> in fact there it can be a depends
[14:41] <shadeslayer> that's what I'm proposing
[14:41] <apachelogger> ah, I thought for QCA
[14:41] <shadeslayer> but I was unsure of the legalese
[14:42] <shadeslayer> no, see my original question
[14:42] <shadeslayer> GPL code depends on LGPL package that depends on openssl
[14:42] <apachelogger> packaging has no implications on legal here :P
[14:42] <apachelogger> shadeslayer: no it doesn't
[14:42] <shadeslayer> okay
[14:42] <Riddell> Mamarok: anything I need to do with this pesky Basil chap?
[14:43] <apachelogger> if there wasn't a bug in QCA it would not crash, so ktp would not crash so there is no argument for dervied work
[14:43] <apachelogger> ktp doesn't specifically require openssl
[14:43] <shadeslayer> right
[14:43] <apachelogger> it requires a QCA plugin that implements the keycontext plugin such that fromDER does something useful
[14:44] <d_ed> and is there anything apart from openssl that actually does that?
[14:44] <apachelogger> whether that plugin is openssl or mylittlepony doesn't matter to KTP
[14:44] <apachelogger> d_ed: dunno, from a legal pov it doesn't matter though
[14:44] <d_ed> as I understand it, it's like us depending on phonon - but only phonon-gstreamer existing..with no-one pulling it in.
[14:44] <apachelogger> d_ed: if you had no phonon backend you would still work
[14:45] <apachelogger> you would not produce sound or whatever
[14:45] <apachelogger> but you would not crash
[14:45] <apachelogger> so not a derived work
[14:45] <Mamarok> Riddell: no, I hope he understood the problem by now...
[14:46] <apachelogger> d_ed: but as I said, ktp-auth depending/recommending openssl is fine because of the status quo that you *want* it so that the user is happy
[14:46] <apachelogger> you don't actually *need* it to work
[14:51] <Riddell> Mamarok: thanks for handling it
[14:51] <Mamarok> Riddell: that's the least I can do :)
[14:52] <shadeslayer> apachelogger: which is why I was saying a recommends will be fine as well?
[14:53] <apachelogger> yeah well
[14:53] <apachelogger> I'd go depends TBH
[14:53] <shadeslayer> fine with me either way
[14:54] <apachelogger> supposedly there is no GUI message explaining why a feature does not behave as expected by the user, so I'd simply avoid that alltogether
[14:55] <gnumdk> Is there any reason kubuntu ship an older version of phonon?
[14:55] <shadeslayer> d_ed: Canon Rock
[14:59] <Riddell> gnumdk: it ships 4.6.0 which was the newest version when we released
[15:00] <gnumdk> ok
[15:01] <gnumdk> Cool :)
[15:01] <gnumdk> Because 4.7 is broken with pulseaudio :)
[15:01] <gnumdk> Backporting to 4.6 on arch fix my issue, going to report bug
[15:04] <apachelogger> gnumdk: what be the issue?
[15:05] <gnumdk> volume isn't changed 
[15:05] <gnumdk> from amarok or dragonplayer
[15:05] <apachelogger> you have to update phonon-gstreamer/phonon-vlc as well
[15:06] <gnumdk> https://bugs.kde.org/show_bug.cgi?id=327279
[15:07] <gnumdk> apachelogger: using ArchLinux so up to date ;) As i was sure Kubuntu was not broken, i tried to downgrade phonon
[15:31] <lordievader> Good afternoon.
[16:46] <shadeslayer> Riddell: ScottK ktp-auth-handler awaiting approval in the SRU queue
[16:49] <shadeslayer> bug 1249014
[17:39] <Riddell> shadeslayer: Test Case TBD?
[17:41] <shadeslayer> Riddell: yes, waiting on d_ed
[17:42] <shadeslayer> ktp contactlist still connects without the ssl plugin
[17:42] <shadeslayer> though it should throw a warning dialog 
[17:57]  * Riddell wanders off to barcelona
[18:01] <shadeslayer> Riddell: :D
[18:26] <ovidiu-florin> how does the kubuntu packaging take place?
[18:44] <shadeslayer> magically?
[18:45] <shadeslayer> yofel: should I run the script for 4.12
[18:45] <shadeslayer> or do we want to merge thingums from debian first
[18:46] <yofel> shadeslayer: well, apachelogger and me talked about it yesterday and pretty much decided not to *merge*
[18:46] <yofel> we can look for packaging fixes later
[18:46] <shadeslayer> cool
[18:46] <shadeslayer> running scripty then
[18:46] <yofel> so go ahead
[18:47] <shadeslayer> it's not funny how muon has very obvious bugs
[18:47] <shadeslayer> for eg. the package states are flags everywhere except in muonstrings.cpp where it's treated as a enum causing weird issues in the ui
[18:48] <shadeslayer> then someone forgot to document the Package::Held enum as a string
[18:48] <shadeslayer> causing empty strings in the dialog that shows you what's going to be committed
[18:51] <shadeslayer> yofel: which files does one usually copy for a new release?
[18:52] <shadeslayer> kdesc-packages-foo and kdesc-dev-latest-foo ?
[18:52] <yofel> kde-sc-dev-latest-saucy.txt, you generate kdesc-packages-trusty.txt with kdesc-package-names
[18:53] <shadeslayer> cool
[19:05] <shadeslayer> :S
[19:05] <shadeslayer> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/libkomparediff2/".
[19:06] <shadeslayer> we should make kubuntu-initial-upload gracefully fail for new packages
[19:27] <shadeslayer> yofel: fwiw I see alot of debcommit: unable to determine commit message using bzr
[19:27] <shadeslayer> Try using the -m flag.
[19:28] <shadeslayer> okay, I have to leave
[19:29] <shadeslayer> yofel: plz be running the script :)
[20:29] <ahoneybun> hello
[21:53] <kubotu> ::qt-bugs:: [1249094] qt4-designer segfaults in QMetaObject::indexOfSignal @ https://bugs.launchpad.net/bugs/1249094 (by SimonW)