[07:17] <soee> good morning
[08:16] <lordievader> Good morning.
[08:39] <sitter> Riddell: do we have a log for the qca build fail in tests you patched out?
[09:31] <Riddell> sitter: probably not
[09:33] <sitter> Riddell: how do you know it failed then?
[09:34] <sitter> and how is one supposed to fix it :S
[09:34] <sitter> and why does it not fail in the ci ppa :S
[09:36] <Riddell> sitter: remove it then and see what breaks, but file watches are funny things so it may well be occational only
[09:37] <sitter> unless we get metrics there is no way this could ever be fixed
[10:10] <Sick_Rimmit> Morning folks..
[10:12] <soee> hi Sick_Rimmit
[10:12] <soee> some can helpsven_123 on #kubuntu ?
[11:00] <Riddell> tsdgeos: where's trunk for oxygen-icons if branch is in http://websvn.kde.org/branches/Applications/14.12/oxygen-icons/ ?
[11:01] <Riddell> someone in debian has done a weird packaging rule to workaround an icon being in the wrong place
[11:01] <tsdgeos> http://websvn.kde.org/trunk/kdesupport/oxygen-icons/
[11:01] <Riddell> thanks
[11:19] <debfx> sitter and wrap-and-sort, a long lasting relationship based on pure love ;)
[11:22] <Riddell> it's like batman and the joker, they define each other
[11:23] <sitter> one day we will wake up and it will be rewritten
[11:23] <sitter> just like launchpadlib
[11:24] <sitter> Riddell: y u no copy builddeps for konsole :'<
[11:24] <sitter> now ci is red
[11:26] <Riddell> sitter: I'll take a look
[11:26] <sitter> Riddell: nah, already on it
[11:27] <sitter> Riddell: btw,  i think we might want to split the kpart for konsole5 as well
[11:27] <sitter> otherwise we might have the same problem come konsole6
[11:28] <Riddell> we might
[11:28] <Riddell> would be good if it became a proper library
[11:28] <sitter> it is a proper plugin :P
[11:45] <Mirv> Riddell: did you have any input to the "which Qt for 15.04" question? I had assumed Kubuntu would put pressure on getting 5.4 early, but last week we discussed here that actually you might want to stick with 5.3.2 for 15.04 because of upstream having chosen so? I'm preparing for 5.4 anyhow, seems there will be a lot to fix: http://is.gd/jAUhah
[11:45] <Mirv> it's good to have fixes regardless of vivid Qt version, since the fixes will be needed sooner or later
[11:46] <Riddell> Mirv: alas we are still pretty unsure
[11:47] <Mirv> Riddell: ok. it doesn't hurt much, as long as there is common understanding before feature freeze.
[11:47] <sitter> I think even if it isn't a strict build requirement we'll need to have 5.4 for experience reasons
[11:47] <Riddell> upstream Plasma 5.2 releases in January and we're unsure upstream if we want the new version.  it's not a long time after qt 5.4 release (which may slip) but then it has nice new features
[11:47] <sitter> e.g. there was a bugfix yesterday that only works with changes in 5.4
[11:49] <Riddell> but of course kubuntu is in april so it would be a shame to go with the old qt version, but meh
[11:53] <Riddell> so I guess what I want is for Plasma 5.2 to support both so weren't not in any rush to update Qt in the archive but it'll still work when we do
[11:53] <Riddell> but that's something the Plasma developers aren't too keen on
[11:55] <Mirv> supporting both would be the best. KDE at least has a sensible amount of private header usage (just two packages), although I don't know how it'd look in practice if one just upgrades to 5.4 without any other changes.
[11:56] <Mirv> Ubuntu has a lot of #if QT_VERSION < QT_VERSION_CHECK(5, 4, 0) style code for 5.1, 5.2, 5.3, 5.4 nowadays, but also mostly because of more private headers use
[11:56] <Mirv> well, not a huge amount I guess, but some in 5-10 packages
[11:58] <sitter> I found that a bit disconcerting
[11:58] <sitter> what annoys me about kde's private header usage is that apparently upstream doesn't consider it a problem...
[11:59] <sitter> and then you have other people from kde argue that their 'private' public libs don't need to be stable because no one is using them anyway
[11:59] <sitter> hypocracy at its best
[12:12] <sitter> hmm
[12:13] <sitter> yofel: shouldn't libkeduvocudocument recommen kdeedu-kvtml-data?
[13:04] <Riddell> tsdgeos: ksnakeduel/ktron/kdesnake seems to have mixed identity with three different names, would it work if I submitted a patch to drop two names and use ksnakeduel?
[13:23] <BluesKaj_> Hiyas all
[13:23] <soee> hi BluesKaj_
[13:24] <BluesKaj_> hey soee
[13:44] <sgclark> Riddell: I have been requested to apply https://bugs.kde.org/show_bug.cgi?id=341483 to our kdev-python packaging and backport, any reason I shouldn't?
[13:47] <Riddell> sgclark: ask kdevelop dudes I'd say, apol will be back online when he's finished playing table tennis
[14:31] <Riddell> sgclark: did you get hold of him?
[14:32] <Riddell> sgclark: or maybe scummos is the best person for kdev-python
[14:43] <sgclark> think I might wait for release
[15:08] <yofel> sitter: IMO not. README.packagers in kdeedu-data lists which packages should depend/recommend kdeedu-kvtml-data
[15:10] <Riddell> yofel: I've just packaged parley which build-depends on libkeduvocdocument-dev
[15:10] <Riddell> should it also depend on kdeedu-kvtml-data ?
[15:12] <yofel> Riddell: it should recommend it - going from http://paste.ubuntu.com/9345839/
[15:13] <Riddell> yofel: why not just have that recommends on libkeduvocudocument ?
[15:14] <yofel> then you'll have to make that a dep if you want to include Kanagram and Khangman.
[15:14] <yofel> I guess we could do that... but it's not really semantically correct
[15:15] <sitter> also sounds good enough :P
[15:15] <sitter> seems like overly cumbersome and errorprone packaging to have it on an application level rather than a library level, even more so considering kdeedu-data is the only supplier of suitable data assets
[15:18] <yofel> if you say so... you might as well just make kdeedu-data depend on it which the libs should already depend on
[15:18] <sitter> oh oh
[15:18] <sitter> parley needs integration
[15:18] <Riddell> integration?
[15:18] <sitter> ciing
[15:19] <Riddell> sitter: so will lots of things on https://notes.kde.org/p/kubuntu-ninjas
[15:25] <sitter> not really, we only integrated kf5
[15:25] <sitter> of which my whiteboard says we are missing: khangman, okteta, parley and kalgebra
[15:25] <sitter> all of which because there is no kf5 packaging yet AFAIK
[15:28] <Riddell> ah I see
[15:28] <Riddell> well yes parley is probably done but I've not uploaded it to ninjas yet to test it there
[15:28] <Riddell> sitter: marble as well?
[15:28] <Riddell> the marble devs seem unsure if we should package qt4 or qt5 version
[15:29] <sitter> Riddell: I was not aware that is part of 14.12
[15:29] <sitter> but if it is then I guess so
[15:30] <Riddell> sitter: marble has always been part of kde sc and is now part of kde applications
[15:30] <Riddell> but the version in applications now has two versions
[15:58] <Riddell> meh, dput not working :(
[16:01] <Riddell> wgrant:  ftp ppa.launchpad.net  broken?
[16:14] <Riddell> wgrant: yay, fixed
[16:26] <Riddell> yofel, sgclark: uploaded all the rest to kubuntu-ninjas, just whatever tidying up left then we can upload to vivid
[16:26] <Riddell> let me know if you can see what tidying up there is to be done
[16:27] <Riddell> various build failures, I'm looking at kdepim-dev rdepends now
[16:31] <sgclark> well looks good in regards to the tidying, but the changelogs seem void of said changes, wasn't this a big thing debian wanted?
[16:31] <sgclark> Riddell: ^
[16:31] <Riddell> sgclark: shouldn't be, got an example?
[16:31] <sgclark> any of my changelogs have all the changes in the entry
[16:31] <Riddell> I missing out lots of "merge with debian, no changes" lines right enough
[16:31] <sgclark> was an easy copy paste
[16:32] <sgclark> and the changes to maintainer/vsc/watch should be noted, no?
[16:33] <Riddell> maybe, we don't note ubuntu changes to the maintainer in changelogs (an ubuntu rule) but I guess this is a debian change to maintainer
[16:33] <Riddell> and by maybe, I mean "yes" :)
[16:36] <sgclark> Riddell: also since it was a merge I did not muck about much with breaks/replaces, but "applications" will be the only kde in vivid right? aka not kde sc, so the breaks/replaces froom old packages could go?
[16:36] <sgclark> would be a nice cleanup
[16:36] <sgclark> next release
[16:37] <Riddell> sgclark: they should stay generally, the source and resulting binary packages are mostly the same
[16:40] <sgclark> so we are also bring kde-sc to vivid? most of the breaks/replaces are from that era of binaries. meh was just a thought.
[16:41] <Riddell> no kde applications replaces kde-sc but they're 90% the same thing
[16:45] <sgclark> right, this was a version thing, but discard everything I said.  
[16:48] <yofel> Riddell: the ubuntu Vcs entries should be dropped
[16:49] <Riddell> yofel: where do you see them?
[16:49] <yofel> parley
[16:49] <sgclark> yeah, ones I looked at were dropped
[16:49] <sgclark> good catch
[16:49] <yofel> and changing the URLs for watch and Vcs should be noted in the changelog
[16:50] <sgclark> yeah I mentioned that :)
[16:50] <yofel> and are we really going to go with this?
[16:50] <yofel> Maintainer: Debian/Kubuntu/Ubuntu Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
[16:50] <yofel> X-Ubuntu-Maintainer: Kubuntu Developers <kubuntu-devel@lists.ubuntu.com>
[16:50] <Riddell> fixed
[16:51] <Riddell> I'll go over all the patches to check the Vcs, Maintainer, watch, changelog entries
[16:52] <sgclark> that does not look right
[16:52] <Riddell> what doesn't?
[16:52] <yofel> the maintainer
[16:52] <Riddell> Maintainer: Debian/Kubuntu Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
[16:52] <Riddell> is what we agreed with debian to use
[16:52] <sgclark> that looks right
[16:52] <yofel> Riddell: right, look at parley
[16:53] <Riddell> I just pushed a fix
[16:53] <yofel> oh
[16:53] <yofel> right, fixed :)
[16:54]  * BluesKaj_ wonders when virtual desktops will get the option to use different wallpapers for each
[16:57] <sgclark> BluesKaj_: I found that functionality when I switched Desktop to Folder in the top option
[16:59] <BluesKaj_> sgclark, thanks , I'll check that out
[17:05] <Riddell> out for the day, will hopefully we can get applications uploaded to vivid tomorrow
[17:06] <BluesKaj_> sgclark, afraid not, still get the same wallpaper for all desktops with folder settings
[19:21] <murthy> Anyone interested in reproducing this bug, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1389847
[19:58] <soee> hiho
[21:08] <soee> valorie: ping
[21:26] <valorie> hi soee
[21:36] <soee> valorie: do you remember nick of a person who is workign on new kubnut.org website ?
[21:38] <yofel> soee: looking for bukai?
[21:39] <valorie> yes, that was bukai
[21:39] <soee> yes, thank you :)
[21:39] <valorie> sorry, keyboard stopped working, and restarting plasma didn't fix, so I restarted
[21:39] <soee> :D
[21:39] <valorie> I've not encountered that before.....
[21:40] <soee> btw on the page im working @homepage there will be graphilac navigation and text nav on subpages: http://kubuntu.dev.soee.pl/
[21:42] <valorie> dang it, I lost my scrollback on this chan
[21:42] <valorie> grrrr
[21:43] <soee> woot ?
[21:44] <valorie> when I restarted
[21:44] <valorie> I have it in the logs
[23:01] <valorie> btw sitter, re our discussion yesterday, since the restart today, no more xdgdir errors
[23:01] <valorie> knock on wood
[23:02] <valorie> ah, Sick_Rimmit, you missed that
[23:02] <valorie> btw sitter, re our discussion yesterday, since the restart today, no more xdgdir errors
[23:02] <Sick_Rimmit> I missed something ?
[23:02] <valorie> had to restart the laptop for other reasons, but that seems fixed now
[23:03] <valorie> the statement above
[23:03] <Sick_Rimmit> xdgdir errors ?
[23:03] <valorie> weren't you getting those too?
[23:04] <valorie> plasma freezing, then restarting it, then those errors?
[23:04] <Sick_Rimmit> Ah I think I see that
[23:04]  * Sick_Rimmit reviews IRC logs
[23:05] <valorie> I know I wasn't alone; there were many many commenters on the bug report
[23:06] <Sick_Rimmit> Yes.. lordievader suggested I use Alt+Tab and this works on most occassions. Today I had a freeze free day, and I've been hammering my work laptop..
[23:07] <Sick_Rimmit> But, so far I haven't really found any pointers as to what is happening, or why
[23:07] <Sick_Rimmit> I'm trying to get back on top of my schedule so I can do some more packaging with sgclark
[23:08] <sgclark> hiyas
[23:08] <Sick_Rimmit> I think, I might be able to get on to some of that next week
[23:08] <sgclark> no worries, my SoK project has taken over much of my time :(
[23:08] <valorie> I lost my scrollback, so I couldn't see the CI meeting, sgclark -- how did it go?
[23:08] <Sick_Rimmit> sgclark: Hi Scarlet
[23:08] <sgclark> valorie: great
[23:08] <valorie> excellent
[23:09] <valorie> I'm happy to see so much interest in quality
[23:09] <sgclark> yes
[23:10] <Sick_Rimmit> I'd like to kn ow more about your SoK sgclark, got any links ? 
[23:11] <sgclark> scarlettgatelyclark.com has my first post, another one will come so9on when I get Windows build to work...
[23:11] <sgclark> s/so9on/soon/
[23:11] <kubotu> sgclark meant: "scarlettgatelyclark.com has my first post, another one will come soon when I get Windows build to work..."
[23:11] <sgclark> just as I thought I was rid of Windows! heh
[23:37] <Sick_Rimmit> sgclark: Very exciting work you're doing with Jenkins and the CI stack, when does you SoK term end ?
[23:37] <sgclark> hmm good question
[23:37] <valorie> it ends Jan 31
[23:38] <sgclark> ty
[23:38] <valorie> we had lots of complaints about lack of feedback from the students and too much fuzziness on the completion time
[23:38] <Sick_Rimmit> Ooo well it's looking good
[23:39] <valorie> so I set it up with monthly blogs required and a firm end date
[23:39] <ScottK> No fuzziness here though.  Not while valorie is supervising ....
[23:39] <valorie> fuzzy beginning instead
[23:39] <valorie> ScottK: lol
[23:39] <sgclark> lol
[23:39] <valorie> deadlines can be productive
[23:39] <sgclark> I am making good progress with mine
[23:40] <valorie> really, I think this is one of Ubuntu's strengths
[23:40] <valorie> there is a calendar with freezes, and releases
[23:40] <valorie> the lack of that with Debian has held it back, IMO
[23:41] <Sick_Rimmit> Yes, I agree Ubuntu Sprints set a focus and goal.
[23:41] <sgclark> looking at the ML debian is falling apart at the seams. I am sure it isn't just appears that way 
[23:42] <Sick_Rimmit> We use this in our own dev team, I sight Kubuntu to those guys, and I keep bigging up TDD, and Jenkins CI too 
[23:42] <valorie> not enough focus on the community IMO
[23:42] <keithzg> If Debian falls apart, though, *buntu falls apart . . . but yeah, the voices that have the most greivances are the loudest, so whenever there's drama the MLs of a project like Debian will give the impression of the apocalypse.
[23:43] <Sick_Rimmit> I have a SysAdmin at our place, whose been talking to me about this, he pointed me to devuan.org earlier today
[23:43] <sgclark> yeah
[23:44] <sgclark> ahh yeah the sysinit spin
[23:44] <sgclark> or fork rather
[23:44] <Sick_Rimmit> I think this is not good.. We need to unite more, not separate and divide
[23:45] <Sick_Rimmit> I'd prefer to see debian offer a sysinit version, perhaps like the KFreeBSD spin they were doing
[23:45] <sgclark> well, the fight between init and systemd has been going on a long time, and Debian being universal I am not entirely surprised it had the biggest explosion there
[23:46] <Sick_Rimmit> I posted a note on this to my G+ stream earlier, and it was an instant flame up
[23:46] <sgclark> yeah I stay out of those these days lol
[23:46] <sgclark> I don't have the "thick skin" pre-req
[23:47] <Sick_Rimmit> I'm just not knowledgable enough about either to make a valuable contribution to that debate
[23:47] <sgclark> that too
[23:47] <Sick_Rimmit> But I do think that it's a mistake to depart from Unix Coding Zen..
[23:47] <valorie> it is too easy to divide, and rather more difficult to put our heads together and make a solution which everyone can sign off on
[23:48] <valorie> in the case of systemd, those devels aren't at the table for the discussion
[23:48] <valorie> so it becomes "take it or leave it"
[23:48] <valorie> neither being the best option, perhaps
[23:48] <Sick_Rimmit> I said that to my chap today, I said listen "It's critical if you feel that way, that you get involved, but in a positive way"
[23:49] <valorie> would have been good for the debian devels to have engaged with them long ago
[23:49] <sgclark> yeah
[23:49] <valorie> when systemd was still forming up
[23:49] <valorie> too late for that now
[23:49] <sgclark> but it sounds like they never had any intention to accep[t it
[23:50] <valorie> Sick_Rimmit: yes, it is a bit of a borg cube to swallow
[23:50] <valorie> lots of edges that cut
[23:50] <valorie> some did want it, some never would
[23:50] <valorie> I hate to see a split that big in debian
[23:51] <valorie> of course some saw Ubuntu as a big split like that
[23:51] <valorie> sooooo......
[23:51] <Sick_Rimmit> It's hard to see debian fork being succesful..
[23:51] <sgclark> true
[23:51] <Sick_Rimmit> With that being the exception,
[23:51] <Sick_Rimmit> but of course a heavily funded exception
[23:52] <Sick_Rimmit> However, all we can do it try to keep contributing in a positive way
[23:53] <sgclark> yes, I have not seen any craziness on the debian/kde side which is what we deal with
[23:54] <sgclark> so we are good in that sense
[23:55] <Sick_Rimmit> Well like you sgclark I think I found a home here in Kubuntu, had to put up with alot of RTFM Bigots along the way to find you folks though
[23:55] <valorie> we don't see ourselves as a fork, though
[23:55] <valorie> rather as a derivative
[23:55] <sgclark> Sick_Rimmit: lol yeah
[23:55] <sgclark> rough road getting here, but I am home safe and sound
[23:55] <valorie> I don't think mark ever saw Ubuntu as a fork either
[23:56]  * Sick_Rimmit grins
[23:56] <sgclark> right, I agree more of a derivative, I see that with the merges we do
[23:58] <Sick_Rimmit> Well friends, I'm done in, time for bed for me.. I'll catch you folks tomorrow, thanks for chatting
[23:59] <valorie> niters Sick_Rimmit
[23:59] <valorie> sweet dreams
[23:59] <sgclark> night!
[23:59] <Sick_Rimmit> ttfn
[23:59]  * Sick_Rimmit Out