[03:38] <DarinMiller> Currently dl'ing the xenial daily download.  Last couple days the install script has been broken.
[03:40] <DarinMiller> The install did not progress past the network connect menu (python error on line 494).   Anybody else see the issue?
[04:16] <ahoneybun> DarinMiller, I have not tried any daily image for xenial at all 
[04:17] <DarinMiller> OK, creating bootable usb now, will report shortly....
[04:17] <ahoneybun> thanks for the testing DarinMiller 
[04:35] <DarinMiller> The xenial-desktop-amd64.iso produces error when clicking Continue from the Prepare screen of the installer. 
[04:38] <DarinMiller> File "/usr/lib/ubiquity/frontend/kde_ui.py, line 1068 in  on_next_clicked. self.dbfilter.ok_handler() ....
[04:40] <DarinMiller> .../plugins/ubi-prepare.py line 344 in ok_handler secureboot key = self.ui.get_secureboot_key() Attribute error: "PageKDE" object has no attribute 'get_secureboot_key'
[04:42] <DarinMiller> Last 3 daily iso's exhibit this error. no 64bit alt iso available to test.  I will poke a round in the 15.10 install scripts to compare to 16.04's...
[05:02] <vishalrao> hello. i saw the "care to help test?" item on kubuntu news/wire site... do i just get the latest daily live image off cdimages.ubuntu.com ? or is there a alpha1 release somewhere?
[05:04] <DarinMiller> !
[05:22] <DarinMiller> switched to konversation as the web page format was hard on the eyes. :)
[05:24] <DarinMiller> So with the successful build, are the daily downloads automatically updated?
[05:47] <DarinMiller> Found the issue with the installer. 
[05:49] <DarinMiller> On the live iso, i unsquashfs'd the /casper/filesystem.squahfs file from 16.04 and 16.10.  
[05:52] <DarinMiller> the /usr/lib/ubiquity/plugins/ubi-prepare.py file in 16.04 has several secure boot modules that were not in 15.10.  I will try rebuidling 16.04 filesystem.squashfs with 15.10  /usr/lib/ubiquity/plugins/ubi-prepare.py file to see if I can proceed with the install as I do not see how to fix the 16.04 ubi-prepare.py file.
[05:53] <DarinMiller> I will attempt this tomorrow....
[06:00] <DarinMiller> Nevermind bug has already been reported and triaged.  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1529450 four days ago.  Hmmm. Wonder when the fix will roll down to the daily builds.
[06:42] <soee> good morning
[07:28] <soee> yofel: i'v tested Plasma 5.5.3  - all good
[08:04] <ovidiu-florin> I don't know the answer for this: https://plus.google.com/u/0/108568659824829381419/posts/V4mDQw272E2
[08:26] <yofel> good question, those are somewhere..
[08:37] <sitter> grml grml
[08:38] <sitter> yofel: do you think anyone could find a minute to SRU a fix into qca-qt5 https://quickgit.kde.org/?p=qca.git&a=blobdiff&h=e0c6cbbf09e4a1cb586534a65176d45ed01c45a7&hp=42808c55846791a611b9da8e634c1b90027b9764&hb=7207e6285e932044cd66d49d0dc484666cfb0092&f=include%2FQtCrypto%2Fqca_basic.h
[08:41] <yofel> sitter: and the reason for that change is?
[08:41] <yofel> I won't have time until the evening, but maybe someone else can do the paperwork
[08:41] <sitter> people complain to me that it is not fixed in kubuntu
[08:41] <sitter> like that's my fault :'<
[08:42] <yofel> well duh, yeah
[08:42] <sitter> also, I am dropping kubuntu ci branches from oxygen-fonts, as that bugger is no longer part of plasma and in fact unmaintained
[08:42] <sitter> FYI ^^
[08:42] <yofel> ack
[08:42] <sitter> you may want to drop it from archive when landing 5.5
[08:43] <yofel> sitter: you still haven't said what that qca change actually fixes ^^
[08:45] <sitter> yofel: oh, FTBFS unless a qca user actually includes QIODevice first
[08:45] <sitter>  /usr/include/Qca-qt5/QtCrypto/qca_basic.h:325:14: error: ‘QIODevice’ has not been declared
[08:45] <lordievader> Good morning.
[08:49] <bshah> yofel: any opinion on making software-properties-kde recommends instead of depends for libdiscover?
[08:50] <bshah> reason being we don't have pyqt5 compiled against qt5.5 for mobile and hence discover fails to install
[08:50] <bshah> and build pyqt5 seems to be mess
[08:53] <yofel> bshah: +1 I think, and maybe even make it a recommends of muon-discover instead. I think that's the only thing that actually uses it
[08:55] <bshah> okay then, /me will make change..
[08:56] <bshah> I am currently making it recommends for libdiscover and will change it to muon-discover after asking apol
[08:59] <bshah> yofel: for this dep change, I don't have to bump version in kubuntu_unstable right?
[08:59] <yofel> bshah: no
[09:00] <bshah> ok
[09:26] <soee_> mamarley: did you solved the kwallet problem ?
[10:00] <mparillo> On Plasma 5.5.3, I need to re-enter my WEP password every time I boot.
[10:01] <soee> there is some problem with kwallet
[10:01] <soee> it simply does not work :)
[10:03] <mparillo> So my problem is probably related? Earlier versions of network manager managed to store WEP passwords without kwallet.
[10:04] <soee> hmm, i'm not sure how it works atm. :)
[10:04] <yofel> AFAIK they only do that if you mark the connection as a "System connection"
[10:04] <yofel> otherwise the connection is bound to your session and the PW is handled by kwallet
[10:15] <soee> yofel: apps 15.12 are still wip right ?
[10:15] <yofel> yes
[10:15] <soee> ok
[10:16] <clivejo> yofel: can I just .phoney autotests in step for the time being?
[10:16] <yofel> yes
[10:17] <clivejo> while I understand the problem now, making a patch to fix said problem is proving too challeging, maybe in time Ill learn how to do that
[10:19] <clivejo> wait, why is dolphin looking for kio-dev (>= 15.15.0)
[10:20] <yofel> that looks rather wrong
[10:20] <clivejo> shouldnt that be 5.18? or less?
[10:21] <yofel> it should
[10:21] <clivejo> now thats weird!
[10:26] <clivejo> and apparently I did that !
[10:26]  * clivejo raps own knuckles
[11:04] <clivejo> LP seems to be under pressure :/
[11:06] <soee> https://www.youtube.com/watch?v=a01QQZyl-_I
[11:08] <mamarley> soee: I didn't fix it, but I did find a workaround.  If you set "killall kwalletd5" to run on KDE startup, the next time an application tries to access the KDE wallet it will restart and work fine.
[11:08] <soee> yofel: can we somehow fix it ^ ?
[11:10] <yofel> mamarley: removing pam_kwallet5.so from /etc/pam.d/sddm is probably a better workaround
[11:10] <yofel> soee: if you tell me how, sure
[11:11] <yofel> kwallet getting started by sddm is what's *supposed* to happen
[11:11] <yofel> otherwise you loose unlock-at-login
[11:11] <mamarley> yofel: Ah, thanks!  I figured there was some better way to do it, but I didn't know where that file would be.
[11:12] <soee> mamarley: so how many processes should we have running by default ?
[11:12] <soee> both kwalletd and kwalletd5  or single one ?
[11:12] <mamarley> My system has "kwalletd5" and "kwalletd".
[11:12] <yofel> hm, come to think of it, the sddm merge did drop pam_kwallet.so from there, but that should be just the qt4 wallet...
[11:13] <mamarley> For me the wallet kept working fine after the SDDM 0.13 update and failed only after the Frameworks 5.18 update.
[11:13] <soee> but the problem started after upgrade to frameworks 5.18
[11:13] <yofel> ah right, nvm
[11:18] <soee> mamarley: ping
[11:19] <mamarley> soee: Switching sonar to active! PONGPONGPONGPONG!
[11:19] <soee> mamarley: are you on machine with those latest framewroks ?
[11:19] <mamarley> I am.
[11:19] <soee> can you please go System Settings -> User  Account
[11:20] <soee> and see if it needs long time to load it due to kwallet section ?
[11:20] <mamarley> Yes, it does. (But only before I applied the workaround.)
[11:21] <soee> hmm we should than check what changes were made in kwallet-kf5 in 5.18 version
[11:22] <soee> mamarley: side task: can you check if Discover works for you ?
[11:22] <mamarley> soee: muon-discover?  I don't even have that installed.
[11:23] <soee> oh
[11:24] <yofel> soee: I already looked out of curiosity, not much: (v.5.17.0 -> v.5.18.0-rc1) http://paste.ubuntu.com/14437177/
[11:25] <soee> hmm
[11:30] <soee> yofel: is it anything important:
[11:30] <soee> http://paste.ubuntu.com/14437217/
[11:32] <yofel> well, that's obviously some broken dbus service. Nice that it doesn't tell you WHAT doesn't respond
[11:33] <clivejo> it does, the dbus didnt respond!
[11:34] <clivejo> looks like a naming issue though?
[11:35] <soee> oh?
[11:35] <clivejo> and sddm not handing over to the correct daemon?
[11:38] <soee> clivejo: and the build log  doesn't report any important warnings https://launchpadlibrarian.net/233280784/buildlog_ubuntu-xenial-amd64.kwallet-kf5_5.18.0-0ubuntu1~ubuntu16.04~ppa3_BUILDING.txt.gz
[11:38] <soee> that might cause some problems?
[11:41] <clivejo> although my box is still xenial archive and I see kwalletd5 running in the background
[11:41] <clivejo> and Im on the new sddm version
[11:42] <yofel> that'll run fine, only FW 5.18 messes stuff up
[11:49] <soee> same messages shows up when i try to run kwalletmanager
[11:49] <soee> + this message: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
[12:56] <BluesKaj_> Howdy folks
[13:00] <clivejo> yofel: where are we up to on okular?  Theres load of new symbols there
[13:01] <clivejo> dolphin and step are now green :)
[13:02] <clivejo> I havent even looked at PIM, it confuses the hell outta me
[13:02] <yofel> oh, pim need pimlibs fixed first (symbols refresh, the missin ones are ok)
[13:02] <yofel> actually let me do that, I just never committed it..
[13:03] <clivejo> did it build locally?
[13:04] <yofel> didn't try, it does build until the gensymbols errors out, so it should be ~fine
[13:04] <yofel> your libokularcore7.symobls talk about the wrong lib
[13:04] <yofel> -libokularcore.so.6 libokularcore6 #MINVER#
[13:04] <yofel> spot the error
[13:04] <yofel> also, the control file needs fixing
[13:04] <yofel> dh_sameversiondep: cannot continue because the reference package libokularcore6 could not be found in debian/control or dpkg status
[13:04] <clivejo> there was a lib ABI break something or other
[13:05] <yofel> and now I wonder what symobls are..
[13:05] <yofel> yeah, and you generally did the right thing, you just didn't finish the job
[13:05] <clivejo> and I was leaving it for you to sort out
[13:05] <clivejo> :P
[13:06] <yofel> just do it yourself, you're almost there, you just missed a couple occurences of "6"
[13:07] <clivejo> is it lib 6 or 7?
[13:07] <yofel> well, is the filename called so.6 or so.7
[13:07] <yofel> which actually reminds me, I never answered your question about the lib version suffixes...
[13:08] <yofel> too much distraction
[13:08] <yofel> so, a common linux shared object usually comes with 3 files
[13:08] <clivejo> -- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/libokularcore.so.7
[13:08] <yofel> the actual binary with the current library version, e.g. libfoo.so.5.3.993939
[13:09] <clivejo> so just update the line in symbols file to libokularcore.so.7 libokularcore7 #MINVER#
[13:09] <clivejo> ?
[13:09] <yofel> then a symlink with the SOVERSION as suffix, that points to the actual binary
[13:09] <yofel> e.g. libfoo.so.9 -> libfoo.so.5.3.993939
[13:10] <yofel> and a development symlink wihtout any version suffix that scripts and build systems can actually find without knowing the version, that points to the soversioned link
[13:10] <yofel> e.g. libfoo.so -> libfoo.so.9
[13:10] <yofel> and yes, you're right
[13:11] <sitter> hm
[13:11] <sitter> clivejo, yofel: was that change there automated or done manually? http://anonscm.debian.org/cgit/pkg-kde/plasma/oxygen.git/commit/?id=56971c52c03861bd12439f7d3d719a63adeb6f06
[13:11] <sitter> note how kdelibs5-dev was changed but shouldn't have been
[13:12] <clivejo> looks automatic
[13:12] <clivejo> via the staging script
[13:12] <yofel> yeah, that was automatic
[13:12] <sitter> yofel: why is it twiddling kdelibs5-dev though?
[13:13] <bshah> I fixed similar thing in breeze
[13:13] <yofel> because it now updates deps of all things it tracks
[13:13] <yofel> not quite sure if that's the right thing to do
[13:13] <clivejo> teething issues with santa's ammendents?
[13:13] <yofel> already shot me in the foot a couple days ago with that
[13:13] <sitter> hm
[13:13] <sitter> yofel: I think that needs layering
[13:14] <sitter> kf5 < plasma < apps
[13:14] <yofel> it's done by the new stuff santa added, which is somewhat incomplete
[13:14] <sitter> so, kf5 autobumps kf5. plasma autobumps deps on other plasmas AND kf5. apps autobumps deps on apps AND plasma AND KF5
[13:14] <yofel> it does. The thing where it shot me in the foot it that it made kwallet build-dep on apps 15.12 which we don't have yet
[13:14] <sitter> although arguably perhaps they should really just autobump within their set
[13:15] <sitter> mh
[13:15] <sitter> you know what
[13:15] <sitter> scratch what I said
[13:15] <sitter> I think autobumps should only bump within their respective set
[13:15] <sitter> so kf5 bumps other kf5s but nothing else, plasma bumps other plasmas but nothing else
[13:15] <sitter> ..
[13:16] <yofel> not realy, plasma deps on frameworks, so it should dep on the FW version we want
[13:16] <yofel> the only problematic parts are cyclic deps
[13:16] <sitter> yofel: no, it should dep on the kf5 it needs
[13:16] <yofel> well, we would need a cmake parser for that
[13:16] <sitter> it FTBFS when it doesn't have the kf5 it needs
[13:17]  * yofel -> lunch, bbiab
[13:17] <sitter> if you bump in a layered fashion you essentially force yourself to do layered staging. until all the latest kf5 are staged you can't stage plasma you can't stage apps
[13:19] <sitter> which may be a worthwhile thing to do with kf5 (i.e. have kf5 deps always bumped regardless of actual requirements), but plasma <-> apps seems like its calling for trouble
[13:36] <yofel> sitter: for plasma not sure, but for everything it is calling for trouble - right
[13:36] <yofel> currently that script really just goes kde-sc-dev-latest and does everything
[13:38] <yofel> meh, santa put all of that into one file
[13:47] <soee> sddm update again ?
[13:48] <soee> or is it the one yofel pushed few days ago ?
[13:48] <yofel> no, this is about making the X scripts conffiles, so changes don't get silently overwritten
[13:48] <yofel> dunno why sddm puts those in /usr
[13:49] <yofel> sitter: splitted stuff for now. I'm not too happy with the logic around that anyway so I'll be reworking that at some point again
[13:50] <yofel> feel free to downgrade versions in CI if they block you
[13:50] <sitter> cheers
[14:33] <clivejo> yofel: now okular is FTBFS due to build deps !
[14:33] <yofel> oh
[14:33] <yofel> I forgot that there's transitions going on
[14:33] <yofel> dangit
[14:34] <yofel> let me throw up a kdelibs rebuild
[14:35] <yofel> lets see what else uses qca2
[14:38] <yofel> kdelibs, kget, kopete and ksirk uploaded
[14:44] <yofel> and here comes the moment when I realise that clivejo probably didn't understand half of what I just said
[14:44] <yofel> clivejo: what's a transition? ^^
[15:12] <sgclark> morning
[15:16] <soee> hiho sgclark
[15:27]  * genii makes a fresh pot of coffee and passes the mugs around
[15:35] <marco-parillo> I fixed the high-priority part of Launchpad Bug #1532157, but how can I join the editors of the new Kubuntu.org website to address the second part?
[15:39] <sgclark> marco-parillo: I believe ovidiu-florin will need to help you there.
[15:40] <sgclark> yofel: clivejo let me know how I ccan help. Been busy with my kde hat.
[15:41] <yofel> sgclark: it would be nice if you could put whatever backport procedure you used into the README. I wrote kubuntu-batch-backport-git as a note collection for now after figuring things out myself yesterday
[15:41] <yofel> but that's probably different than what you did
[15:41] <sgclark> it was mostly a manual mess
[15:42] <sgclark> nothing that would represent a procedure
[15:42] <yofel> ah ok, so my notes are probably as much as we have
[15:42] <yofel> OTOH, backporting frameworks was like really easy :D
[15:42] <sgclark> it needs to be improved hah
[15:42] <sgclark> cool
[15:42] <yofel> stuff is still finishing building, but had to fix like.. nothing
[15:43] <yofel> *we had
[15:43] <sgclark> where are we at?
[15:43] <sgclark> sorry been out of the loop, life and stuff
[15:44] <sgclark> we still have merges that need doing right?
[15:45] <yofel> xenial: fW done, plasma done, apps WIP and unmerged
[15:45] <yofel> wily: fw WIP, rest todo
[15:45] <sgclark> according to trello, yes
[15:46] <yofel> I would like to finish apps, then merge all of them in one go
[15:46] <sgclark> ok, I will work on apps.
[15:46] <yofel> or you can merge stuff that's already been done
[15:46] <sgclark> wip I assume the script has run, just needs fixes?
[15:46] <yofel> now with 15.12 we can do breaks << 15.12~ for the merge file moves
[15:47] <yofel> apps is in the ppa, right
[15:47] <sgclark> ok, on it
[15:48] <sgclark> ooh the new pim, ugly
[15:49] <yofel> oh right, fun
[15:50] <yofel> I also only fixed pimlibs today, so logs are a bit outdated there
[15:51] <sgclark> ahh
[15:52] <sgclark> I think we need a newer akonadi
[15:52] <sgclark> unddefined reference fail
[15:53] <sgclark> nm we have newest
[15:53] <sgclark> yofel: have you run retry since you fixed libs?
[15:53] <yofel> no
[15:53] <sgclark> ok will run that then
[15:54] <yofel> sgclark: please bump the akonadi build-dep to >= 15.12.0~ on the package where you found the reference fail
[15:54] <yofel> I only did that for akonadi search so far
[15:54] <yofel> should be done for all packages with that error
[15:55] <yofel> so look through the logs before you retry everything
[15:55] <sgclark> yofel: ok
[16:17] <yofel> clivejo: okular retried, should build now
[16:17]  * clivejo crosses fingers
[16:18] <yofel> and frameworks finally finished building for wily. Stupid build queue
[16:18] <clivejo> any prgress on kwallet?
[16:18] <yofel> no, will look into it later
[16:21] <clivejo> ask the KDE folks?
[16:23] <yofel> feel free to
[16:33]  * clivejo Is in and out at the moment
[16:33] <clivejo> and any previous questions have gone unanswered, so Ill just leave it
[16:39] <yofel> regarding?
[16:48] <sgclark> holy missing ysmbols batman
[16:49] <yofel> lol, where?
[16:55] <sgclark> kpimtextedit
[16:55] <sgclark> public too
[16:55] <sgclark> needs investigation. setting aside for now
[16:56] <yofel> the last I asked about kdepimlibs, pim team response was: We give no ABI guarantees -.-
[16:56] <yofel> so either we just make sure to rebuild everything, or we go DebianAbiManager crazy
[16:58] <sgclark> I vote rebuild
[16:58] <yofel> ack
[16:59] <yofel> pim stuff is broken in various ways all the time anyway. Nobody will notice a couple crashes more
[17:01] <sgclark> sadly yeah I have not been able to rely on my beloved kmail for awhile. hopefully it get sorted soon
[17:02] <yofel> it does work most of the time for me, if you don't mind the occasional misbehavior. At least akonadi has no data-loss bugs that affect me
[17:09] <sgclark> my problem is my internet is quite crappy and falls off all the time, akonadi then proceeds to crash and I have to constantly restart it. Then kmail filters get cranky and is stupid slow.
[17:09] <sgclark> I have talked to the pim crew and they have no answers for me :(
[17:09] <yofel> oh yeah, I can imagine that :/
[17:10] <soee> thunderbird or web client :) 
[17:10] <yofel> urgh, ok. I'm debugging that muon crash right now
[17:10] <soee> also Owncould offers some ail integration
[17:10] <soee> and in version 9.0 shoudl be pretty cool
[17:10] <yofel> you stupid thing have managed to annoy me enough to go on a killing spree
[17:10] <sgclark> lol
[17:15] <yofel> where's apol when you need him
[17:16] <soee> yofel: do we have some kwallet-kf5 build fro master ?
[17:16] <yofel> the CI probably has one
[17:16] <soee> [18:15] <mck182> soee: can you try master?
[17:16] <soee> so i would like to check if it fixes the problem with kwallet
[17:18] <yofel> I love the muon codebase. It makes me want to run away within the first 5 minutes of reading it
[17:18] <yofel> ApplicationNotifier::parseUpdateInfo(), first line: #warning why does this parse stdout and not use qapt, wtf...
[17:19] <soee> :D
[17:22] <yofel> meh, I need to file a bug for this, I'm like ?!?!? when reading this
[17:24] <soee> yofel: kwallert-kf5 master also has the same issue
[17:24] <yofel> do you by chance have the 5.17 package in your apt cache?
[17:25] <yofel> oh, I do actually
[17:25] <soee> ?
[17:25] <yofel> libkf5wallet5_5.17.0-0ubuntu1~ubuntu16.04~ppa2_amd64.deb
[17:25] <soee> ah
[17:25] <yofel> just curious if downgrading helps
[17:31] <yofel> soee: https://bugs.kde.org/show_bug.cgi?id=357704
[17:32] <soee> yofel: version 5.17 also desn't work now :/ owncloud cant connect at startup
[17:33] <yofel> so it might not be kwallet itself that's broken
[17:33] <bshah> kwallet-pam might be it btw..
[17:34] <yofel> but there were people that said it worked with 5.5.2 until they updated to 5.18
[17:34] <yofel> so, hm..
[17:36] <soee> yofel: [18:34] <mck182> soee: kdbusaddons
[17:36] <soee> ill try this one to downgrade
[17:36] <yofel> let me try to disable auto-login so I can join in on the debugging
[17:37] <yofel> why do I have a german config window. My system language is not german -.-
[17:37] <yofel> that it's only half-german only makes this more broken
[17:41] <yofel> and I'm seeing what you mean with excessive screen flickering...
[17:42] <ovidiu-florin> Congratulations guys for getting 5.5.3 in xenial :D
[17:42] <soee> downgrading dbusaddons didn't help
[17:42] <ovidiu-florin> I see there still are a few apps failing
[17:42] <ovidiu-florin> which one should I take a look at?
[17:43] <ovidiu-florin> clivejo yofel ^
[17:43] <clivejo> ovidiu-florin: what ever you think you can fix !
[17:44] <clivejo> sgclark is working on PIM
[17:44] <ovidiu-florin> anything to be done for frameworks?
[17:44] <ovidiu-florin> there a re a few orange
[17:45] <clivejo> some oranges can be ignored
[17:45] <yofel> those can all be ignored
[17:45] <ovidiu-florin> ok
[17:45] <sgclark> fix anything that looks red/orange till we have all green, please use https://notes.kde.org/p/kubuntu-ninjas to note packages you are working on though
[17:45] <sgclark> so we can coordinate
[17:45] <sgclark> more the merrier
[17:45] <ovidiu-florin> I'll start with okular
[17:46]  * clivejo gulps
[17:46] <yofel> okular is almost done
[17:47] <clivejo> ovidiu-florin: have you done symbols before?
[17:47] <ovidiu-florin> it depends on what that means
[17:47] <ovidiu-florin> who is working on it?
[17:47] <ovidiu-florin> yofel: ^
[17:47] <ovidiu-florin> there's no note of someone
[17:47] <yofel> clive was, so work with hiim
[17:47] <yofel> https://pkg-kde.alioth.debian.org/symbolfiles.html
[17:48] <yofel> for symbol stuff 
[17:48] <soee> yofel: full downgrade frameworks to 5.17 and it works fine
[17:48] <yofel> it was just us 2 working on stuff, so we made no notes
[17:48] <clivejo> I dunno if thats a good idea, Im not fully understanding of symbols myself
[17:49] <yofel> here all that's left is a file refresh
[17:49] <clivejo> and ovidiu-florin asks a lot of questions!
[17:49] <yofel> as the SOVERSION changed, any symbol changes are OK
[17:50] <clivejo> just a batchpatch and removing #MISSING ?
[17:50] <yofel> right
[17:51] <ovidiu-florin> yofel: so who is working on okular?
[17:51] <ovidiu-florin> you said it's almost done
[17:51] <clivejo> ovidiu-florin: I was
[17:51] <ovidiu-florin> was?
[17:51] <ovidiu-florin> past thense?
[17:51] <clivejo> yes, the last issue yofel had to fix some other packages first
[17:52] <sgclark> well please use the pad now, several of us
[17:52] <ovidiu-florin> and how's that going?
[17:52] <clivejo> it rebuilt a few hours ago and I havent had time to get back to it
[17:52] <clivejo> Im not working on anything at the moment
[17:52] <sgclark> and it is actually a good idea to always use the pad, we never know when folks will suddenly have time to help
[17:52] <clivejo> I was doing some OSM jobs
[17:53] <ovidiu-florin> clivejo: so will you continue with that and I'll take something else?
[17:53] <ovidiu-florin> or?
[17:53] <clivejo> no, you do it
[17:53] <ovidiu-florin> ok
[17:53] <clivejo> if you look at the buildlog, it is building and installing fine
[17:53] <clivejo> but failing on symbols
[17:54] <ovidiu-florin> clivejo: in the future, let's try to follow sgclark and write down in the notes what is being worked on 
[17:54] <ovidiu-florin> even if it's in pause because of something
[17:54] <clivejo> sure, I agree
[17:54] <ovidiu-florin> and mentio why it's in pause
[17:54] <ovidiu-florin> clivejo: I see the CMake output cries a lot
[17:54] <clivejo> but its just been yofel and I so we just co-originated on here
[17:55] <clivejo> do you see where the problem is?
[17:55] <ovidiu-florin> I didn't find the symbols issue yet
[17:55] <ovidiu-florin> clivejo: can you give me a line number?
[17:55] <yofel> scroll close to bottom
[17:56] <yofel> or do a text search for "gensymbols"
[17:56] <clivejo> search for dpkg-gensymbols
[17:57] <clivejo> what yofel said :P
[17:57] <clivejo> dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
[17:57] <clivejo> dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below
[17:57] <clivejo> dpkg-gensymbols: warning: debian/libokularcore7/DEBIAN/symbols doesn't match completely debian/libokularcore7.symbols
[17:57] <clivejo> the buildlog actually contains a diff
[17:59] <clivejo> so first thing, grab a clone of okular packaging
[17:59] <clivejo> xenial archive branch
[18:04] <ovidiu-florin> okular still depends on kde 4.6......
[18:09] <sgclark> ovidiu-florin: README in kubuntu-automation has the command you need to batchpatch symbols. Run c++filt on any MISSING symbols. Then you need to look up the result on KDE API and see if it is a public symbol. If it is ( this is where I cry to someone more knowledgable like yofel)
[18:24] <vip> hi ho
[18:24] <vip> there's some kde related packages for update on my system, but I am a little bit scaried...
[18:25] <clivejo> ovidiu-florin: how you getting on?
[18:26] <ovidiu-florin> I know what symbols are
[18:26] <ovidiu-florin> but I didn't know that they could be stored outside of the binary
[18:26] <ovidiu-florin> in their own file
[18:28] <ovidiu-florin> I'm currently reading on https://pkg-kde.alioth.debian.org/symbolfiles.html and related links
[18:29] <clivejo> ok, Ill let you read
[18:29] <clivejo> Ill go find food
[18:30] <acher88> I assume wily backports are not going to be very quick?
[18:30]  * clivejo ties soee down
[18:31] <soee> ?
[18:31] <clivejo> soee: to keep you in the channel
[18:31] <clivejo> in and out, in and out
[18:32] <soee> yup, testing packages. this will happen a few more minutes :)
[18:33] <yofel> acher88: well, I think we could have a plasma backport over the weekend. But we're hitting few issues with the new plasma and frameworks right now
[18:33] <yofel> so nothing stable for a while unless you don't mind some breakage
[18:34] <acher88> I don't mind breakage.
[18:34] <clivejo> kwallet breakage
[18:34] <acher88> Just have 2 machines to upgrade due to vivid going EOL
[18:35] <yofel> I'm so good at breaking stuff that I managed to give sddm-greeter a window frame...
[18:35] <acher88> and was debating on holding with wily or just putting both on xenial
[18:35] <yofel> how's that even possible
[18:36] <yofel> actually, let me take a break from breaking stuff and upload plasma
[18:42] <ovidiu-florin> why are there symbols in the okular package?
[18:42] <ovidiu-florin> aren't they sypposed to be in okular-dbg?
[18:43] <yofel> we are talking about the okular source package, that includes all binary packages
[18:43] <yofel> the actual symbols are for the libokularcore7 binary package
[18:46] <ovidiu-florin> in http://qa.kubuntu.co.uk/ppa-status/applications/build_status_15.12.0_xenial.html I see just okular
[18:46] <ovidiu-florin> not okular-scr
[18:46] <ovidiu-florin> src*
[18:46] <ovidiu-florin> I dont' understand something
[18:46] <ovidiu-florin> some info is missing here for me
[18:47] <ovidiu-florin> how does okular get split in okular-dbg -src -dev ..... etc...
[18:47] <ovidiu-florin> ?
[18:47] <ovidiu-florin> when? where? by whom?
[18:47] <yofel> there is no -src package, the source package is what you make yourself by hand and upload to launchpad
[18:48] <yofel> the thing that consists of the .orig.tar + .debian.tar + .dsc
[18:48] <yofel> the binary packages are then created from information inside the control file, and information from the various .install etc. files in the debian/ folder
[18:49] <yofel> ovidiu-florin: I really recommend that you read https://www.debian.org/doc/debian-policy/
[18:50] <yofel> that's in some sense the technical specification how the packages are structured, and what each of the files in debian/ is for and all the files in them etc.
[18:50] <yofel> at least the first 5 chapters are elemental knowledge
[18:54]  * yofel monkey-patches kwallet in the meantime
[18:56] <BluesKaj> monkey-patches?
[18:56] <yofel> https://en.wikipedia.org/wiki/Monkey_patch
[18:56] <soee> yofel: o you reverts to what was in 5.17 ?
[18:57] <yofel> well ok, technically it's just a patch
[18:57] <yofel> soee: well, that one commit
[18:57] <soee> yup
[18:57] <soee> but i think mck182 might add valid patch soon
[18:58] <yofel> probably, but maybe he can then also respin the tarball before tomorrow
[18:58] <soee> ah o
[18:58] <soee> ok
[18:58] <yofel> although we're rather close to release
[19:07] <mck182> ok I found the exact line
[19:07] <mck182> but I don't understand why
[19:11] <yofel> oh, I just figured out why my kwallet doesn't work on my desktop
[19:11] <yofel> libkf5wallet-bin isn't installed - how is that even possible
[19:13] <yofel> oh, it's a recommends, great...
[19:14] <BluesKaj> yofel: it's installed here on xenial with plasma 5.5.3
[19:19] <sgclark> yofel: odd, I could have sworn that was fixed.
[19:19] <sgclark> perhaps debian merge reintroduced it
[19:20] <yofel> sgclark: I'm on wily here, so pre-merge packages
[19:20] <yofel> well, good to know it's fixed 
[19:20] <sgclark> ahh ok
[19:21] <sgclark> I made the leap to xenial
[19:21] <yofel> wtf, breeze-gtk has a watch file that points to kde-config-gtk o.O
[19:21]  * yofel corrects
[19:24] <ovidiu-florin> I have to go
[19:24] <ovidiu-florin> I'll see you guys tomorrow
[19:24] <ovidiu-florin> if anyone is here
[19:24] <yofel> likely wil be
[19:24] <yofel> enjoy the evening
[19:25] <ScottK> We did make some changes to avoid circular Depends.
[19:26] <yofel> that would explain it..
[19:26] <ScottK> The symbols file ought to cause an extra Depends, so once the rdepends are rebuilt it should be fine.
[19:26] <ScottK> (Assuming that change got merged correctly)
[20:09] <mck182> yofel: patch ready at https://git.reviewboard.kde.org/r/126681/
[20:10] <yofel> mck182: thanks
[20:11] <yofel> mck182: will you ask for a tarball respin?
[20:12] <mck182> well I could shoot a mail to dfaure
[20:12] <mck182> but no guarantees
[20:13] <yofel> ok
[20:16] <yofel>  /usr/include/Qca-qt5/QtCrypto/qca_basic.h:325:14: error: 'QIODevice' has not been declared
[20:17] <yofel> now I know hat sitter was talking about.................
[20:17] <yofel> well, be happy that discover forces me to take some action
[20:19] <BluesKaj> akregator doesn't launch, "akregator: symbol lookup error: /usr/lib/x86_64-linux-gnu/libKF5AkonadiCore.so.5: undefined symbol: _ZTIN7Akonadi8Protocol7CommandE"
[20:20] <yofel> yes, don't use the apps 15.12 packagees
[20:20] <yofel> we didn't finish kdepim there
[20:20] <BluesKaj> ok 
[21:44]  * genii notices sddm-kcm in there
[21:54] <clivejo> kubuntu-ci you are depressing me :(
[22:00] <yofel> hm, so muon-discover should be renamed to plasma-discover
[22:00] <yofel> might as well do that tomorrow
[22:00] <clivejo> yofel, just got the announcement about 15.12.1 is that a bug fix?
[22:01] <yofel> yes, just leave it alone till tuesday
[22:01] <yofel> I wouldn't bother with it until uscan starts failing on us
[22:02] <clivejo> with them being still in staging, would now not be a good time to stage them too?
[22:03] <clivejo> I see you have kwallet fix on the way :)
[22:03] <yofel> the watch files only work for stuff on the public server, so working on frameworks was actually a bit annoying the last few days
[22:04] <yofel> lets not do the same with apps when we still have tons of work left
[22:04] <clivejo> oh, I see what you mean now
[22:04] <clivejo> I didnt have that because I staged them, so I have all the tarballs locally?
[22:05] <yofel> yes
[22:05]  * clivejo penny dropped
[22:05] <yofel> to work reasonably I first had to manually rsync everything myself
[22:05] <yofel> that needs to be a seperate script really..
[22:06] <yofel> anyway, muon-discover renamed to plasma-discover in the tooling, I'll do the packaging rework tomorrow
[22:06] <clivejo> so you have applied a patch to kwallet?
[22:06] <clivejo> and asked upstream to respin a tarball
[22:07] <yofel> I fully reverted the commit. Lets see what david does tomorrow and either take the new tarball or use the new patch
[22:07] <clivejo> do KDE work weekends?
[22:07] <yofel> he said he would release stuff on saturday, so I guess he does ^^
[22:10] <clivejo> sgclark: kpimtextedit is orange now, looks like symbols need updating
[22:13] <sgclark> clivejo: okies dokies, only have an hour or so before I head out for the evening. Will try to get to it though.
[22:13] <clivejo> I can do it if you want
[22:13] <clivejo> just dont want to be stepping on your toes
[22:14] <clivejo> is ovidiu-florin coming back to okular?
[22:15] <yofel> lets leave that to him so he can learn from it
[22:16] <clivejo> looks like something broke in KCI
[22:16] <sgclark> clivejo: if I have ppa* up in the notes and it still needs work after that is is fair game
[22:17] <sgclark> just note that you are now working on it
[22:18] <clivejo> yofel sgclark with kimap the 386 build seems ok, therefore if I feed the batch patch script with only one buildlog, will it remove the 386 references?
[22:21] <yofel> no, you *always* have to give it both buildlogs
[22:21] <yofel> otherwise it'll do something stupid
[22:27] <clivejo> yeah, I noticed that
[22:27] <clivejo> LOL
[22:27] <clivejo> step builds and the rest are failing
[22:27]  * clivejo rolls eyes
[22:35] <sgclark> clivejo: yofel kimap seems to be an issue with one symbol did nt have epoch, is that an app without an epoch?!
[22:42] <clivejo> sgclark: changelog doesnt mention an epoch :/
[22:42] <clivejo> and the buildlog doesnt have one, how did it get one?
[22:43] <clivejo> there was a commit earier today - http://anonscm.debian.org/cgit/pkg-kde/applications/kimap.git/commit/?h=kubuntu_xenial_archive&id=a27e46d9270938506a5bb71234ca064a70b35a47
[22:44] <clivejo> maybe passed the wrong -v to batchpatch command?
[22:45] <sgclark> yeah that would be me, oops
[22:46] <clivejo> I hate epochs :(
[22:48] <valorie> epochs should be eschewed
[22:50] <clivejo> some people seem to like them  :P
[22:51] <valorie> lol
[22:51] <yofel> they are an emergency measure, and should be handled carefully like that
[22:51] <sgclark> yeah that was my bad, so many apps have them..
[22:51] <clivejo> easily done
[22:51] <valorie> oops, bbiab
[22:53] <clivejo> if anyone gets to libkinsane can you explain how you fix it please?
[22:54] <clivejo> its driving me f'kinsane
[23:42] <BlueProtoman> I'm trying to install the "KDE Service Menu PDF" Dolphin Add-on on Kubuntu 15.10, but even though it successfully installs I don't see any new context menu items.  Is it not compatible with the latest version of Dolphin?
[23:48] <valorie> BlueProtoman: you might have to add the items you want to the menu
[23:48] <valorie> do you remember what the packagename was?
[23:48] <valorie> I'll try to install and test
[23:48] <valorie> however, let's do this in #kubuntu
[23:49] <valorie> this chan is not for support