[00:15] <valorie> hi folks, someone posted this link in #kubuntu the other day: http://www.ryananddebi.com/2015/07/13/linux-getting-find-working-in-dolphin-on-kde-linux-mint-and-kubuntu/
[00:16] <valorie> and I wonder if we can test and fix whatever the problem is, or at least file bugs on the appropriate places?
[00:16] <valorie> I don't know where to start
[00:35] <sgclark> valorie: hmm I cannot reproduce
[00:35] <keithzg> valorie: Well, I can tell you at least that I can repro the problem on my 14.04 install at work.
[00:36] <keithzg> (as in, I hadn't realized it was more than just me, heh)
[00:36] <sgclark> oh I see
[00:36] <sgclark> because I have baloo installed...
[00:36] <valorie> ah, that's trusty, right?
[00:36] <keithzg> valorie: Yup.
[00:36] <keithzg> And yeah, baloo not installed.
[00:37] <sgclark> so dolphin or in the case of trusty kdebase-apps needs a depends on baloo
[00:37] <sgclark> I can fix that
[00:37] <valorie> the one thing that didn't ring quite right to me is that we didn't have baloo installed by default
[00:37]  * sgclark goes to fix
[00:37] <keithzg> Ehhh should we really be doing that? I don't *want* baloo installed on this machien.
[00:37] <sgclark> oh?
[00:37] <sgclark> ok I am confused then
[00:38] <keithzg> And as the post points out, Dolphin doesn't actually need baloo to run searching, it's just one of the possible ways it can.
[00:38] <valorie> but I hadn't heard about that problem before, and it sounds like it is a linked set of problems, not the lack of baloo
[00:38] <valorie> which is why I raised the issue here
[00:38]  * sgclark finishes reading
[00:49] <sgclark> well, it certainly does appear to be an issue brought up in various forums and the like. Surprised it is my first of hearing it. Heh. Definately needs to be brought up upstream I think. If indeed baloo should not be required.
[00:57] <sgclark> well I do not even have the settings manager bit for desktop-search so I cannot reproduce any of it :( but I know it is a valid problem out there. SAdly I do not see any bugs reported at bug.kde.org so I am also not sure how to procedd here.
[00:59] <sgclark> Closest I found https://bugs.kde.org/show_bug.cgi?id=347916
[00:59] <ubottu> KDE bug 347916 in search "Search does not work when performed from $HOMEDIR/$USER" [Normal,Unconfirmed]
[01:00] <sgclark> asked the reporters to see if their issue was close to the blogs
[01:00] <sgclark> guess that is a start.
[01:00] <sgclark> anyway I need a break, off till tomorrow
[01:30] <keithzg> Closest I found wasn't very close either, https://bugs.kde.org/show_bug.cgi?id=348902
[01:30] <ubottu> KDE bug 348902 in General "search is broken - searching in the status bar forever and never finds anything" [Normal,Confirmed]
[01:32] <keithzg> It does mention that to manually search in Dolphin you use either  baloosearch:/ (Baloo package) or filenamesearch:/ (kio-extras package), 
[01:34] <keithzg> and I can confirm that manually searching with baloosearch:/ results in an identical-appearing error while filenamesearch:/ appears to work (never actually returns any results, mind you, but I really don't know the syntax so that's not necessarily a surprise).
[07:47] <soee> hiho, firefox 42 in updates today
[09:23] <_Ridgewing> Morning everyone \o/ (stretches to the ceiling)
[09:39] <_Ridgewing> sick_rimmit: Are you not well, today ?
[10:37] <ovidiu-florin> yofel, Riddell sitter, or whomever, I don't have admin on the Kubuntu Romania Trello Board. 
[10:38] <ovidiu-florin> either please give me rights, or archive the board
[10:38] <Riddell> ovidiu-florin: done, I think
[10:38] <ovidiu-florin> thank you
[10:57] <clivejo> yofel: regarding ksuperkey, what are the plans for it?
[11:13] <clivejo> oooo a new version of Kubuntu is available!
[11:40] <mparillo> clivejo: yofel: I thought NetRunner used ksuperkey, but when I asked Riddell about it maybe a couple of months ago, he said upstream recommended against it.
[11:40] <Riddell> both of those things may be true :)
[11:41] <clivejo> Riddell: only maybe?
[11:42] <Riddell> the second one is, I know nothing about netrunner
[11:42] <clivejo> why do upstream recommend against it?
[11:45] <Riddell> because it messes up key bindings
[11:45] <Riddell> he gets lots of bug reports which are just caused by it being installed
[11:55] <clivejo> Riddell: would it not make sense to have it as part of plasma?
[11:55] <BluesKaj> 'Morning all
[11:55] <clivejo> hi BluesKaj
[11:56] <BluesKaj> hey clivejo
[11:56] <Riddell> clivejo: no, poor martin hates it
[11:56] <Riddell> ask him yourself if you like
[11:58] <clivejo> mgraesslin: why do you hate the superkey (windows key)?
[12:06] <mgraesslin> clivejo: if you phrase it like that you can be sure that you won't get an answer. Be constructive!
[12:11] <clivejo> mgraesslin: taking into account many keyboards have a superkey and many users try to install ksuperkey in order to make use of this pesky wee button, surely it makes sense to be able to use it in plasma, without the use of 3rd party code which may/or may not cause unforeseen proplems with debugging etc
[12:11] <mgraesslin> clivejo: please stop. I'm now no longer in any mood to discuss that
[12:12] <clivejo> I can see many advantages of having such a feature and Im interested in hearing the disadvantages
[12:12] <mgraesslin> and I'm not interested in explaining them
[12:13] <clivejo> I feel that went well
[12:14] <Riddell> uh oh
[12:14] <Riddell> so aye, an emotive issue
[12:16] <clivejo> I’m genuinely interested on hearing why not :/
[12:18] <clivejo> is it political, religious, have to rely on proprietary drivers or code?
[12:36]  * clivejo goes to find something more constructive to do
[13:03] <sgclark> morning
[13:11] <jmux> Riddell: do you have any news from the guy, whose student wanted to write a KF5 backend for LibreOffice? I remember he wanted to come back after two weeks, but that was 4 weeks ago...
[13:12] <Riddell> jmux: nope, not heard anything
[13:13] <Riddell> it was Dani Gutiérrez Porset and his student Iñigo Carrera
[13:14] <Riddell> jmux: I've e-mailed asking for an update
[13:15] <jmux> Riddell: thanks
[13:58] <sitter> sgclark valorie are you joining hangout?
[13:59] <sgclark> uhh just woke up.
[13:59] <sgclark> not fit for human consumption but sure without video
=== rdieter_work is now known as rdieter
[14:09] <Riddell> jmux: the student replied! first time I've heard from him
[14:10] <Riddell> jmux: he asks for a meeting on monday, are you about?
[14:25] <jmux> Riddell: Sure depends on the time. CET 14:00+ I'll have time. 
[14:28] <jmux> Where do we meet? #libreoffice-design again?
[14:54] <ovidiu-florin> shadeslayer: https://www.kdevelop.org/frameworks/kdevelop-master-now-depends-kde-frameworks-5
[14:54] <ovidiu-florin> sgclark sitter ^
[14:54] <ovidiu-florin> that was a long time ago
[14:55] <shadeslayer> ovidiu-florin: https://anonscm.debian.org/cgit/pkg-kde/kde-std/kdevelop.git/ < create kubuntu_unstable branch
[14:55] <sgclark> very aware, time.. is a factor here
[14:55] <shadeslayer> then adjust packaging
[14:55] <shadeslayer> ovidiu-florin: then add to https://anonscm.debian.org/cgit/pkg-kde/ci-tooling.git/tree/data/projects.json  under kde-std
[14:55] <sgclark> thanks you two, great jb
[14:56] <sgclark> job
[14:56] <sitter> <3
[14:56] <shadeslayer> sgclark: hope that explains a bit of the CI :)
[14:56] <sitter> rather long winded rambling I feel :P
[14:56] <sitter> CIs are shit to talk about
[14:56] <shadeslayer> :D
[14:56] <shadeslayer> it was quite long
[14:56] <sgclark> I still have alot to learn lol. 
[14:57] <ovidiu-florin> who has to create the branch?
[14:57] <shadeslayer> sitter: https://anonscm.debian.org/cgit/pkg-kde/frameworks/kconfig.git/commit/?h=kubuntu_unstable
[14:57] <ovidiu-florin> or, who can?
[14:57] <shadeslayer> ovidiu-florin: someone who has commit rights to the repos
[14:57] <shadeslayer> you can ask in #debian-qt-kde for access
[14:57] <sitter> shadeslayer: I think the problem is that -dev deps -bin while it should dep -bin-dev
[14:57] <ovidiu-florin> so that branch is needed in the upstream repo?
[14:57] <sitter> although foreign also helps :P
[14:57] <sitter> ovidiu-florin: on git.debian there needs to be a kubuntu_unstable branch
[14:57] <shadeslayer> ^^ :O
[14:58] <shadeslayer> :P
[14:58] <shadeslayer> though I guess yeah we can drop the -bin dependency
[14:59] <kfunk> you could also ship kdevelop-4.7.2 -- contains a nice bunch of bug fixes
[14:59] <shadeslayer> sitter: I'm having permission issues when cleaning workspaces
[14:59] <shadeslayer> ( build artifacts apparently have screwed up uid/gid ? )
[14:59] <sitter> shadeslayer: that's because some of the mobile scripts don't chown
[14:59]  * sgclark pulls her hair out looking at her to-do list
[14:59] <sitter> or rather. that's because docker still doesn't have proper subuid support QQ
[15:00] <shadeslayer> sitter: ok, lets fix the chown'ing ?
[15:00] <shadeslayer> or well, how do we fix the chown'ing
[15:00] <sitter> just needs the exit handler from builder.rb copied all over the place
[15:00] <shadeslayer> xD
[15:00] <shadeslayer> ok
[15:00] <shadeslayer> sitter: btw you should install the project manager plugin 
[15:00] <sitter> to resolve the existing problem you should simply root chown I guess
[15:00] <shadeslayer> for atom
[15:00] <sitter> shadeslayer: I think I had it, and I think I hated it
[15:00] <shadeslayer> why :O
[15:00] <sitter> can't recall
[15:01] <sitter> in fact, I'd be perfectly alright with kate if it supported ruby a bit better :P
[15:02] <shadeslayer> didn't kdevelop have a ruby plugin
[15:02] <kfunk> it does
[15:02] <sgclark> oh we have releases up as well. oh my
[15:02] <sgclark> hmm
[15:02] <sitter> now someone just needs to teach me how to kdevelop :P
[15:02] <kfunk> sitter: so, you know this apt-get thing?
[15:02] <sitter> kfunk: isn't it experimental?
[15:02] <kfunk> maybe you've heard of it
[15:02] <kfunk> :)
[15:02] <sitter> I totally think it was experimentally broken last I looked at it
[15:03] <shadeslayer> sitter: FileUtils.chown_R('jenkins', 'jenkins', @workspace_path, verbose: true) < that needs to be jenkins-slave ?
[15:03] <sitter> ruby support, not kdevelop that is :P kdevelop just has too many buttons for my puny mind XD
[15:03] <shadeslayer> does the container know about jenkins-slave?
[15:03] <sitter> shadeslayer: oh yes. that is probably why I didn't want them to use jenkins-slave :P
[15:04] <kfunk> sitter: it shouldn't be totally broken. at least the KDE4-branch
[15:04] <sitter> shadeslayer: what if a build runs on master? on master the user is called jenkins :P
[15:04] <shadeslayer> ok what then :P
[15:04]  * kfunk didn't try for a long time
[15:04] <sitter> shadeslayer: dunno. needs figuring out
[15:04] <sitter> I am saying it's not straight forward because of name difference
[15:05] <shadeslayer> yeah
[15:05] <shadeslayer> what uid are the slaves
[15:05] <shadeslayer> if the GID is the same on all slaves, then we can just set the GID
[15:06] <shadeslayer> as well as chown to jenkins
[15:06] <shadeslayer> or perhaps if the jenkins and jenkins slave UID's are the same ...
[15:06] <sitter> oh actually
[15:06] <sitter> shadeslayer: isn't the user jenkins inside the container no matter what?
[15:06] <shadeslayer> it is
[15:07] <shadeslayer> but we build as root
[15:07] <sitter> shadeslayer: yaeh but the containers have a user
[15:07] <sitter> that's why chef coerces a GID to begin wiht
[15:08] <sitter> https://github.com/blue-systems/pangea-tooling/blob/master/deploy_in_container.rake#L88 && https://github.com/blue-systems/pangea-kitchen/blob/master/site-cookbooks/jenkins-slave/recipes/default.rb#L22
[15:09] <shadeslayer> yes we do have jenkins inside docker
[15:09] <sitter> so on the slaves it is hardcoded to 100k and inside the docker it is also hardcoded to 100k
[15:09] <sitter> that's why the chown works to begin with 
[15:09] <sitter> name doesn't matter anyway, the uid needs to be the same, which it is due to the hardcoding
[15:12] <shadeslayer> ok
[15:12] <shadeslayer> so just chown to jenkins then
[15:12] <shadeslayer> got it
[15:28] <sitter> ovidiu-florin: ps1 and vim and so forth https://powerline.readthedocs.org/en/latest/
[15:40] <pursuivant> muon (master) v5.4.2-166-g7755c65 * Aleix Pol: discover/qml/UpdatesPage.qml
[15:40] <pursuivant> Use correct icon
[15:40] <pursuivant> http://commits.kde.org/muon/7755c65c67f9bdfa17e1e509e340b542a5418d63
[15:40] <pursuivant> muon (master) v5.4.2-167-gca1ed9b * Aleix Pol: libmuon/backends/DummyBackend/DummyBackend.cpp
[15:40] <pursuivant> Report ratings as soon as we get them
[15:40] <pursuivant> http://commits.kde.org/muon/ca1ed9be6acf63d807021182c25e0a64e9780a23
[15:40] <pursuivant> muon (master) v5.4.2-168-g5d86c61 * Aleix Pol: discover/qml/ApplicationDescription.qml
[15:40] <pursuivant> Show the application rating
[15:40] <pursuivant> http://commits.kde.org/muon/5d86c610f63ee5e5c0de3508311d61b388880d58
=== mck182__ is now known as mck182|brb
=== palasso_ is now known as palasso
[15:53] <pursuivant> muon (Plasma/5.4) v5.4.2-13-g456c5a0 * Aleix Pol: libmuon/backends/PackageKitBackend/PKTransaction.cpp
[15:53] <pursuivant> Fix package resolution after un/installing
[15:53] <pursuivant> Thanks a lot to Elia Devito for the patch!
[15:53] <pursuivant> BUG: 354562
[15:53] <pursuivant> http://commits.kde.org/muon/456c5a03b5397f58a4915c40eca3e5ca7225f794
[15:53] <ubottu> bug 339148 in gnome-app-install (Ubuntu) "duplicate for #354562 gnome-app-install crashed with ValueError in _refilter()" [High,Fix released] https://launchpad.net/bugs/339148
[15:53] <pursuivant> muon (master) v5.4.2-172-g4d83be1 * Aleix Pol: libmuon/backends/PackageKitBackend/PKTransaction.cpp
[15:53] <pursuivant> Merge branch 'Plasma/5.4'
[15:53] <pursuivant> # Conflicts:
[15:53] <pursuivant> #CMakeLists.txt
[15:53] <pursuivant> http://commits.kde.org/muon/4d83be1a3faa1672deb93d3a8731906cf27cdf2b
[16:08] <sgclark> oh good grief everything being tagged today it seems
[16:08]  * sgclark drowns
[16:17]  * mamarley throws sgclark the torpedo buoy.
=== mck182|brb is now known as mck182__
=== mck182__ is now known as mck182___
=== adrian is now known as alvesadrian
=== palasso_ is now known as palasso
=== detrout_ is now known as detrout
=== who_da_fly is now known as superfly
=== Squt is now known as Sput
[19:01] <marco-parillo> I subscribed to the trello board. I assume an admin would need to make me a member before I can comment on any cards. If so, could an admin add me?
[19:22] <sgclark> mparillo: added
[19:23] <sgclark> mparillo: to 16.04 . Seems I am not even a part of kubuntu team haha
[19:27] <soee> hiho
[19:27] <sgclark> hiyas
=== tazz_ is now known as tazz
[19:51] <clivejo> sgclark: I dont really know how to use bzr :(
[19:52] <sgclark> it isn't a whole ton different from git
[19:52] <sgclark> hmm
[19:53] <clivejo> sgclark: I tried to move the calligra packaging to debian - http://anonscm.debian.org/cgit/pkg-kde/kde-std/calligra.git/
[19:54] <sgclark> clivejo: if you are interested in helping with kdevelop you can apt-get source it and then upload to your ppa and then I can grab and bzr it.
[19:54] <clivejo> but to be honest Im not sure if Im doing it right
[19:58] <clivejo> I can grab from bzr, just dont know how to push my changes back to it
[19:58] <soee> are there 5.4.3 tars already ?
[19:58] <clivejo> on depot yes
[20:01] <clivejo> soee: they are on depot, but not sure if QT is ready to build them 
[20:01] <soee> clivejo: why ?
[20:02] <soee> it is just bugfix release so why QT can be not ready ?
[20:02] <clivejo> you mean for wily or xenial?
[20:02] <sgclark> clivejo: bzr push :parent
[20:02] <clivejo> sgclark: are you working on calligra?
[20:03] <sgclark> soee: I am fixing CI builds to prepare and then I will work in it
[20:03] <sgclark> clivejo: no, my plate is ffull, over full
[20:03] <soee> clivejo: wily, is there any point building it for xenial ?
[20:04] <soee> xenial will ship with 5.5 that is going to be releaed (beta) in 2/3 weeks
[20:04] <clivejo> would you be able to point me in the right direction? 
[20:04] <soee> so imo. building it for xenial than for wily is wast of time :)
[20:04] <clivejo> I checked out bzr and moved it to debian git
[20:05] <sgclark> clivejo: for calligra? no not in the immediate future. it would be better to knock out stuff we can actually do fast right now and work on the beasts later
[20:05] <sgclark> soee: no it is not, that is the workflow
[20:06] <sgclark> development -> backports.
[20:06] <clivejo> I think I can manage calligra, just nned a bit of help with the bring it over to git part
[20:06] <soee> sgclark: yes but it will be replace in xenial soon with 5.5
[20:07] <sgclark> ok I have got to get back to work, not enough time in the world to get this all done
[20:09] <sgclark> clivejo: kubuntu_unstable branch is there, I don't understand what is wrong. 
[20:10] <sgclark> soee: 5.5 what are you  talking about? qt5? that has nothing to do with 5.4.3.
[20:11] <sgclark> also debian merges need to done, hmm
[20:12] <soee> sgclark: Plasma 5.4.3 will be released soon, than you said it first will be build for Xenial than Wily. What i'm thinking is that Plasma 5.5 beta is planed soon also (2/3 weeks ?) so it will replace 5.4.3 in Xenial anyway so what is the point building 5.4.3 for Xenial :)
[20:12] <sgclark> think I will wait and get with yofel to come up with a real plan.
[20:12] <sgclark> soee: ahh I see. yes that makes sense
[20:13] <sgclark> I can run it for wily then. 
[20:24] <clivejo> do we still have access to weegie for QA?
[20:33] <ahoneybun> we should have a blog post like this: http://www.whizzy.org/2015/09/big-bug-bonanza-16-04-lts/
[20:41] <sgclark> clivejo: weegie?
[20:42] <clivejo> isnt that the name of the machine - http://qa.kubuntu.co.uk/ppa-status/plasma/ ?
[20:43] <sgclark> oh. Yes I suppose that is being taken away as well. So no, not that I am aware of.
=== rdieter is now known as rdieter_work
[21:03] <mparillo> sgclark: Thank you for adding me
[23:10] <valorie> well, effing hell, I totally forgot the CI session
[23:10] <valorie> my apologies sitter, sgclark
[23:48] <sgclark> heh, I barely rolled out of bed in time, I suspect it was way early for your sleep schedule
[23:59] <santa_> yofel, sgclark, clivejo: now the automation-ng scripts are almost ready, I just need to add a couple of scripts to add/remove the ppa version suffix
[23:59] <santa_> https://gitlab.com/jmsantamaria-papers/kubuntu-automation-design/blob/master/kubuntu_automation_design.pdf
[23:59] <santa_> ↑ updated pdf with the design
[23:59] <sgclark> oooh, think it will be ready for a test run tomorrow santa_ ?