[03:38] Currently dl'ing the xenial daily download. Last couple days the install script has been broken. [03:40] The install did not progress past the network connect menu (python error on line 494). Anybody else see the issue? [04:16] DarinMiller, I have not tried any daily image for xenial at all [04:17] OK, creating bootable usb now, will report shortly.... [04:17] thanks for the testing DarinMiller [04:35] The xenial-desktop-amd64.iso produces error when clicking Continue from the Prepare screen of the installer. [04:38] File "/usr/lib/ubiquity/frontend/kde_ui.py, line 1068 in on_next_clicked. self.dbfilter.ok_handler() .... [04:40] .../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] 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] 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] ! [05:22] switched to konversation as the web page format was hard on the eyes. :) [05:24] So with the successful build, are the daily downloads automatically updated? [05:47] Found the issue with the installer. [05:49] On the live iso, i unsquashfs'd the /casper/filesystem.squahfs file from 16.04 and 16.10. [05:52] 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] I will attempt this tomorrow.... [06:00] 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:00] Launchpad bug 1529450 in ubiquity (Ubuntu) "AttributeError: 'PageKde' object has no attribute 'get_secureboot_key'" [Critical,Triaged] [06:42] good morning [07:28] yofel: i'v tested Plasma 5.5.3 - all good [08:04] I don't know the answer for this: https://plus.google.com/u/0/108568659824829381419/posts/V4mDQw272E2 [08:26] good question, those are somewhere.. [08:37] grml grml [08:38] 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] sitter: and the reason for that change is? [08:41] I won't have time until the evening, but maybe someone else can do the paperwork [08:41] people complain to me that it is not fixed in kubuntu [08:41] like that's my fault :'< [08:42] well duh, yeah [08:42] 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] FYI ^^ [08:42] ack [08:42] you may want to drop it from archive when landing 5.5 [08:43] sitter: you still haven't said what that qca change actually fixes ^^ [08:45] yofel: oh, FTBFS unless a qca user actually includes QIODevice first [08:45] /usr/include/Qca-qt5/QtCrypto/qca_basic.h:325:14: error: ‘QIODevice’ has not been declared [08:45] Good morning. [08:49] yofel: any opinion on making software-properties-kde recommends instead of depends for libdiscover? [08:50] reason being we don't have pyqt5 compiled against qt5.5 for mobile and hence discover fails to install [08:50] and build pyqt5 seems to be mess [08:53] 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] okay then, /me will make change.. [08:56] I am currently making it recommends for libdiscover and will change it to muon-discover after asking apol [08:59] yofel: for this dep change, I don't have to bump version in kubuntu_unstable right? [08:59] bshah: no [09:00] ok [09:26] mamarley: did you solved the kwallet problem ? [10:00] On Plasma 5.5.3, I need to re-enter my WEP password every time I boot. [10:01] there is some problem with kwallet [10:01] it simply does not work :) [10:03] So my problem is probably related? Earlier versions of network manager managed to store WEP passwords without kwallet. [10:04] hmm, i'm not sure how it works atm. :) [10:04] AFAIK they only do that if you mark the connection as a "System connection" [10:04] otherwise the connection is bound to your session and the PW is handled by kwallet [10:15] yofel: apps 15.12 are still wip right ? [10:15] yes [10:15] ok [10:16] yofel: can I just .phoney autotests in step for the time being? [10:16] yes [10:17] 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] wait, why is dolphin looking for kio-dev (>= 15.15.0) [10:20] that looks rather wrong [10:20] shouldnt that be 5.18? or less? [10:21] it should [10:21] now thats weird! [10:26] and apparently I did that ! [10:26] * clivejo raps own knuckles [11:04] LP seems to be under pressure :/ [11:06] https://www.youtube.com/watch?v=a01QQZyl-_I [11:08] 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] yofel: can we somehow fix it ^ ? [11:10] mamarley: removing pam_kwallet5.so from /etc/pam.d/sddm is probably a better workaround [11:10] soee: if you tell me how, sure [11:11] kwallet getting started by sddm is what's *supposed* to happen [11:11] otherwise you loose unlock-at-login [11:11] 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] mamarley: so how many processes should we have running by default ? [11:12] both kwalletd and kwalletd5 or single one ? [11:12] My system has "kwalletd5" and "kwalletd". [11:12] 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] For me the wallet kept working fine after the SDDM 0.13 update and failed only after the Frameworks 5.18 update. [11:13] but the problem started after upgrade to frameworks 5.18 [11:13] ah right, nvm [11:18] mamarley: ping [11:19] soee: Switching sonar to active! PONGPONGPONGPONG! [11:19] mamarley: are you on machine with those latest framewroks ? [11:19] I am. [11:19] can you please go System Settings -> User Account [11:20] and see if it needs long time to load it due to kwallet section ? [11:20] Yes, it does. (But only before I applied the workaround.) [11:21] hmm we should than check what changes were made in kwallet-kf5 in 5.18 version [11:22] mamarley: side task: can you check if Discover works for you ? [11:22] soee: muon-discover? I don't even have that installed. [11:23] oh [11:24] 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] hmm [11:30] yofel: is it anything important: [11:30] http://paste.ubuntu.com/14437217/ [11:32] well, that's obviously some broken dbus service. Nice that it doesn't tell you WHAT doesn't respond [11:33] it does, the dbus didnt respond! [11:34] looks like a naming issue though? [11:35] oh? [11:35] and sddm not handing over to the correct daemon? [11:38] 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] that might cause some problems? [11:41] although my box is still xenial archive and I see kwalletd5 running in the background [11:41] and Im on the new sddm version [11:42] that'll run fine, only FW 5.18 messes stuff up [11:49] same messages shows up when i try to run kwalletmanager [11:49] + this message: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) [12:56] Howdy folks [13:00] yofel: where are we up to on okular? Theres load of new symbols there [13:01] dolphin and step are now green :) [13:02] I havent even looked at PIM, it confuses the hell outta me [13:02] oh, pim need pimlibs fixed first (symbols refresh, the missin ones are ok) [13:02] actually let me do that, I just never committed it.. [13:03] did it build locally? [13:04] didn't try, it does build until the gensymbols errors out, so it should be ~fine [13:04] your libokularcore7.symobls talk about the wrong lib [13:04] -libokularcore.so.6 libokularcore6 #MINVER# [13:04] spot the error [13:04] also, the control file needs fixing [13:04] dh_sameversiondep: cannot continue because the reference package libokularcore6 could not be found in debian/control or dpkg status [13:04] there was a lib ABI break something or other [13:05] and now I wonder what symobls are.. [13:05] yeah, and you generally did the right thing, you just didn't finish the job [13:05] and I was leaving it for you to sort out [13:05] :P [13:06] just do it yourself, you're almost there, you just missed a couple occurences of "6" [13:07] is it lib 6 or 7? [13:07] well, is the filename called so.6 or so.7 [13:07] which actually reminds me, I never answered your question about the lib version suffixes... [13:08] too much distraction [13:08] so, a common linux shared object usually comes with 3 files [13:08] -- Installing: /«PKGBUILDDIR»/debian/tmp/usr/lib/libokularcore.so.7 [13:08] the actual binary with the current library version, e.g. libfoo.so.5.3.993939 [13:09] so just update the line in symbols file to libokularcore.so.7 libokularcore7 #MINVER# [13:09] ? [13:09] then a symlink with the SOVERSION as suffix, that points to the actual binary [13:09] e.g. libfoo.so.9 -> libfoo.so.5.3.993939 [13:10] 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] e.g. libfoo.so -> libfoo.so.9 [13:10] and yes, you're right [13:11] hm [13:11] 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] note how kdelibs5-dev was changed but shouldn't have been [13:12] looks automatic [13:12] via the staging script [13:12] yeah, that was automatic [13:12] yofel: why is it twiddling kdelibs5-dev though? [13:13] I fixed similar thing in breeze [13:13] because it now updates deps of all things it tracks [13:13] not quite sure if that's the right thing to do [13:13] teething issues with santa's ammendents? [13:13] already shot me in the foot a couple days ago with that [13:13] hm [13:13] yofel: I think that needs layering [13:14] kf5 < plasma < apps [13:14] it's done by the new stuff santa added, which is somewhat incomplete [13:14] so, kf5 autobumps kf5. plasma autobumps deps on other plasmas AND kf5. apps autobumps deps on apps AND plasma AND KF5 [13:14] 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] although arguably perhaps they should really just autobump within their set [13:15] mh [13:15] you know what [13:15] scratch what I said [13:15] I think autobumps should only bump within their respective set [13:15] so kf5 bumps other kf5s but nothing else, plasma bumps other plasmas but nothing else [13:15] .. [13:16] not realy, plasma deps on frameworks, so it should dep on the FW version we want [13:16] the only problematic parts are cyclic deps [13:16] yofel: no, it should dep on the kf5 it needs [13:16] well, we would need a cmake parser for that [13:16] it FTBFS when it doesn't have the kf5 it needs [13:17] * yofel -> lunch, bbiab [13:17] 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] 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] sitter: for plasma not sure, but for everything it is calling for trouble - right [13:36] currently that script really just goes kde-sc-dev-latest and does everything [13:38] meh, santa put all of that into one file [13:47] sddm update again ? [13:48] or is it the one yofel pushed few days ago ? [13:48] no, this is about making the X scripts conffiles, so changes don't get silently overwritten [13:48] dunno why sddm puts those in /usr [13:49] 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] feel free to downgrade versions in CI if they block you [13:50] cheers [14:33] yofel: now okular is FTBFS due to build deps ! [14:33] oh [14:33] I forgot that there's transitions going on [14:33] dangit [14:34] let me throw up a kdelibs rebuild [14:35] lets see what else uses qca2 [14:38] kdelibs, kget, kopete and ksirk uploaded [14:44] and here comes the moment when I realise that clivejo probably didn't understand half of what I just said [14:44] clivejo: what's a transition? ^^ === perezmeyer is now known as lisandro [15:12] morning [15:16] hiho sgclark [15:27] * genii makes a fresh pot of coffee and passes the mugs around [15:35] 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:35] Launchpad bug 1532157 in Kubuntu Website "Link to release notes Kubuntu-Trusty throws 404" [Low,In progress] https://launchpad.net/bugs/1532157 [15:39] marco-parillo: I believe ovidiu-florin will need to help you there. [15:40] yofel: clivejo let me know how I ccan help. Been busy with my kde hat. [15:41] 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] but that's probably different than what you did [15:41] it was mostly a manual mess [15:42] nothing that would represent a procedure [15:42] ah ok, so my notes are probably as much as we have [15:42] OTOH, backporting frameworks was like really easy :D [15:42] it needs to be improved hah [15:42] cool [15:42] stuff is still finishing building, but had to fix like.. nothing [15:43] *we had [15:43] where are we at? [15:43] sorry been out of the loop, life and stuff [15:44] we still have merges that need doing right? [15:45] xenial: fW done, plasma done, apps WIP and unmerged [15:45] wily: fw WIP, rest todo [15:45] according to trello, yes [15:46] I would like to finish apps, then merge all of them in one go [15:46] ok, I will work on apps. [15:46] or you can merge stuff that's already been done [15:46] wip I assume the script has run, just needs fixes? [15:46] now with 15.12 we can do breaks << 15.12~ for the merge file moves [15:47] apps is in the ppa, right [15:47] ok, on it [15:48] ooh the new pim, ugly [15:49] oh right, fun [15:50] I also only fixed pimlibs today, so logs are a bit outdated there [15:51] ahh [15:52] I think we need a newer akonadi [15:52] unddefined reference fail [15:53] nm we have newest [15:53] yofel: have you run retry since you fixed libs? [15:53] no [15:53] ok will run that then [15:54] sgclark: please bump the akonadi build-dep to >= 15.12.0~ on the package where you found the reference fail [15:54] I only did that for akonadi search so far [15:54] should be done for all packages with that error [15:55] so look through the logs before you retry everything [15:55] yofel: ok [16:17] clivejo: okular retried, should build now [16:17] * clivejo crosses fingers [16:18] and frameworks finally finished building for wily. Stupid build queue [16:18] any prgress on kwallet? [16:18] no, will look into it later [16:21] ask the KDE folks? [16:23] feel free to [16:33] * clivejo Is in and out at the moment [16:33] and any previous questions have gone unanswered, so Ill just leave it [16:39] regarding? [16:48] holy missing ysmbols batman [16:49] lol, where? [16:55] kpimtextedit [16:55] public too [16:55] needs investigation. setting aside for now [16:56] the last I asked about kdepimlibs, pim team response was: We give no ABI guarantees -.- [16:56] so either we just make sure to rebuild everything, or we go DebianAbiManager crazy [16:58] I vote rebuild [16:58] ack [16:59] pim stuff is broken in various ways all the time anyway. Nobody will notice a couple crashes more [17:01] sadly yeah I have not been able to rely on my beloved kmail for awhile. hopefully it get sorted soon [17:02] 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] 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] I have talked to the pim crew and they have no answers for me :( [17:09] oh yeah, I can imagine that :/ [17:10] thunderbird or web client :) [17:10] urgh, ok. I'm debugging that muon crash right now [17:10] also Owncould offers some ail integration [17:10] and in version 9.0 shoudl be pretty cool [17:10] you stupid thing have managed to annoy me enough to go on a killing spree [17:10] lol [17:15] where's apol when you need him [17:16] yofel: do we have some kwallet-kf5 build fro master ? [17:16] the CI probably has one [17:16] [18:15] soee: can you try master? [17:16] so i would like to check if it fixes the problem with kwallet [17:18] I love the muon codebase. It makes me want to run away within the first 5 minutes of reading it [17:18] ApplicationNotifier::parseUpdateInfo(), first line: #warning why does this parse stdout and not use qapt, wtf... [17:19] :D [17:22] meh, I need to file a bug for this, I'm like ?!?!? when reading this [17:24] yofel: kwallert-kf5 master also has the same issue [17:24] do you by chance have the 5.17 package in your apt cache? [17:25] oh, I do actually [17:25] ? [17:25] libkf5wallet5_5.17.0-0ubuntu1~ubuntu16.04~ppa2_amd64.deb [17:25] ah [17:25] just curious if downgrading helps [17:31] soee: https://bugs.kde.org/show_bug.cgi?id=357704 [17:31] KDE bug 357704 in general "Muon notifier crashes on apt package list updates" [Crash,Unconfirmed] [17:32] yofel: version 5.17 also desn't work now :/ owncloud cant connect at startup [17:33] so it might not be kwallet itself that's broken [17:33] kwallet-pam might be it btw.. [17:34] but there were people that said it worked with 5.5.2 until they updated to 5.18 [17:34] so, hm.. [17:36] yofel: [18:34] soee: kdbusaddons [17:36] ill try this one to downgrade [17:36] let me try to disable auto-login so I can join in on the debugging [17:37] why do I have a german config window. My system language is not german -.- [17:37] that it's only half-german only makes this more broken [17:41] and I'm seeing what you mean with excessive screen flickering... [17:42] Congratulations guys for getting 5.5.3 in xenial :D [17:42] downgrading dbusaddons didn't help [17:42] I see there still are a few apps failing [17:42] which one should I take a look at? [17:43] clivejo yofel ^ [17:43] ovidiu-florin: what ever you think you can fix ! [17:44] sgclark is working on PIM [17:44] anything to be done for frameworks? [17:44] there a re a few orange [17:45] some oranges can be ignored [17:45] those can all be ignored [17:45] ok [17:45] 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] so we can coordinate [17:45] more the merrier [17:45] I'll start with okular [17:46] * clivejo gulps [17:46] okular is almost done [17:47] ovidiu-florin: have you done symbols before? [17:47] it depends on what that means [17:47] who is working on it? [17:47] yofel: ^ [17:47] there's no note of someone [17:47] clive was, so work with hiim [17:47] https://pkg-kde.alioth.debian.org/symbolfiles.html [17:48] for symbol stuff [17:48] yofel: full downgrade frameworks to 5.17 and it works fine [17:48] it was just us 2 working on stuff, so we made no notes [17:48] I dunno if thats a good idea, Im not fully understanding of symbols myself [17:49] here all that's left is a file refresh [17:49] and ovidiu-florin asks a lot of questions! [17:49] as the SOVERSION changed, any symbol changes are OK [17:50] just a batchpatch and removing #MISSING ? [17:50] right [17:51] yofel: so who is working on okular? [17:51] you said it's almost done [17:51] ovidiu-florin: I was [17:51] was? [17:51] past thense? [17:51] yes, the last issue yofel had to fix some other packages first [17:52] well please use the pad now, several of us [17:52] and how's that going? [17:52] it rebuilt a few hours ago and I havent had time to get back to it [17:52] Im not working on anything at the moment [17:52] 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] I was doing some OSM jobs [17:53] clivejo: so will you continue with that and I'll take something else? [17:53] or? [17:53] no, you do it [17:53] ok [17:53] if you look at the buildlog, it is building and installing fine [17:53] but failing on symbols [17:54] clivejo: in the future, let's try to follow sgclark and write down in the notes what is being worked on [17:54] even if it's in pause because of something [17:54] sure, I agree [17:54] and mentio why it's in pause [17:54] clivejo: I see the CMake output cries a lot [17:54] but its just been yofel and I so we just co-originated on here [17:55] do you see where the problem is? [17:55] I didn't find the symbols issue yet [17:55] clivejo: can you give me a line number? [17:55] scroll close to bottom [17:56] or do a text search for "gensymbols" [17:56] search for dpkg-gensymbols [17:57] what yofel said :P [17:57] dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below [17:57] dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below [17:57] dpkg-gensymbols: warning: debian/libokularcore7/DEBIAN/symbols doesn't match completely debian/libokularcore7.symbols [17:57] the buildlog actually contains a diff [17:59] so first thing, grab a clone of okular packaging [17:59] xenial archive branch [18:04] okular still depends on kde 4.6...... [18:09] 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] hi ho [18:24] there's some kde related packages for update on my system, but I am a little bit scaried... [18:25] ovidiu-florin: how you getting on? [18:26] I know what symbols are [18:26] but I didn't know that they could be stored outside of the binary [18:26] in their own file [18:28] I'm currently reading on https://pkg-kde.alioth.debian.org/symbolfiles.html and related links [18:29] ok, Ill let you read [18:29] Ill go find food [18:30] I assume wily backports are not going to be very quick? [18:30] * clivejo ties soee down [18:31] ? [18:31] soee: to keep you in the channel [18:31] in and out, in and out [18:32] yup, testing packages. this will happen a few more minutes :) [18:33] 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] so nothing stable for a while unless you don't mind some breakage [18:34] I don't mind breakage. [18:34] kwallet breakage [18:34] Just have 2 machines to upgrade due to vivid going EOL [18:35] I'm so good at breaking stuff that I managed to give sddm-greeter a window frame... [18:35] and was debating on holding with wily or just putting both on xenial [18:35] how's that even possible [18:36] actually, let me take a break from breaking stuff and upload plasma === yofel changed the topic of #kubuntu-devel to: Kubuntu - Friendly computing | Plasma 5.4.3: W/PPA 5.5.3: X/LANDING W/WIP, Apps 15.08.3: W/PPA, 15.12.0: X/WIP, FW 5.18: X/LANDING W/WIP | https://trello.com/kubuntu | http://qa.kubuntu.co.uk/ | Package Docs (WIP) https://notes.kde.org/p/kubuntu-packaging | plasma 5.5 in kubuntu-ppa/ppa-landing for xenial [18:42] why are there symbols in the okular package? [18:42] aren't they sypposed to be in okular-dbg? [18:43] we are talking about the okular source package, that includes all binary packages [18:43] the actual symbols are for the libokularcore7 binary package [18:46] in http://qa.kubuntu.co.uk/ppa-status/applications/build_status_15.12.0_xenial.html I see just okular [18:46] not okular-scr [18:46] src* [18:46]