[07:26] Good morning [09:28] Riddell: Thanks for all your great work and leadership with Kubuntu during the past decade (?), it is much appreciated by lots of people whom you've never met :-) [09:28] Riddell: Good luck with your future endeavors, I'm sure you'll do many more great things! [09:29] hi - is this bug -> https://bugs.kde.org/show_bug.cgi?id=354230 The cause of a really slow login to kde on 15.10 ? [09:29] KDE bug 354230 in general "Blocking calls from PlasmaNM to BlueZ for 30s" [Normal,Resolved: fixed] [09:30] takes about 30 - 40 secs to get a usable desktop from login on 15.10 (didn;t happen on 15.04) [09:30] just wanted to ensure it was this bug (as that looks fixed upstream) [09:31] yossarianuk: I have that bug, and it depends on what you mean by login.... [09:32] yossarianuk: it happens after the actual login screen, when some of the other stuff already appaers (including partial panel) [09:32] i.e after logging in to sddm [09:32] yossarianuk: but then it hangs for ~50 secs (in my case) until the panel is completely drawn and responsive [09:32] until its fully loaded the taskbar locations of clock, etc are wrong also [09:32] sounds very similar. [09:32] so yes, it's probably that [09:32] there's more than one reason for a slow plasma login, but in ~2h or so I could wrap up a test package with above fix [09:33] I assume the fix will be in the normal updates at some point? [09:33] yofel: I'll happily test the package (when im back home) [09:34] so far though the slow login is the only real issue with 15.10, apart from that it seems better than 15.04. [09:34] the fix is in Plasma/5.4, so it should be part of 5.4.3 [09:34] yofel: any idea when that will be released and available in kubuntu updates? [09:35] .3 is due in ~3 weeks [09:35] we can cherry-pick that patch before that if it really does help === tazz_ is now known as tazz [09:42] yofel: personally I don't log in/out too often, so a 3 weeks wait is fine. I'd think the ubiquity bug that causes the upgrade to 15.10 to crash is far more critical. [09:44] erm, what bug? (ubiquity is the live-installer, and has nothing to do with upgrading) [09:45] yofel: oh, then someone pointed me to report a bug in the wrong place, perhaps [09:45] yofel: login bug - its not exactly critical however would give bad impressions to someone checking out how plasma5 is getting along. maybe add to known 15.10 issues on the release notes ? [09:46] amichair: I guess update-manager would be more correct. I think I remember someone talking about a crash there [09:47] yossarianuk: hm, we could maybe add a generic message about that. There seems to be at least the bluez issue and an issue with akonadi that cause that [09:47] yofel: bug #1509655 [09:47] bug 1509655 in ubiquity (Ubuntu) "installer crashed on custom configuration file dialog" [Undecided,New] https://launchpad.net/bugs/1509655 [09:48] yofel: there was also bug #1509653 which was scary (saw it on two systems), but doesn't actually prevent the upgrade from succeeding, so not that critical [09:48] bug 1509653 in ubiquity (Ubuntu) "kdeinit5 crashes during upgrade to 15.10" [Undecided,New] https://launchpad.net/bugs/1509653 [09:49] yofel: but the former bug just crashed the upgrade and left people with a broken system. discussed it with two other guys on #kubuntu the other day who also suffered from it. [09:50] yeah, I know about the kdeinit5 one. But no idea what to do about that [10:01] yossarianuk: allee was thinking that the loading system lag problem could be caused by akonadi [10:03] I think he pretty much proved that his problem is akonadi [10:04] * yofel wonders if the pyqt5 API changed... [10:04] Yes. Unfortunately dvratil could not reproduce with master :-( [10:05] yofel: is there a description how to pick e.g. only KDEPIM from CI (to test if the problem goes away with master pkgs) [10:06] no, your best bet would be to add the repository and selectively upgrade the packages you're interested in [10:49] 'Morning folks [10:57] morning [11:01] o/ [11:03] nothing in the pipe for 4 days , that's unusual for a new release, still plenty of unsolved issues [11:17] can you guys look at https://bugs.launchpad.net/ubuntu/+source/plasma-nm/+bug/1509334 I've linked to a patch, if you could backport it, that'd probably be useful [11:17] Launchpad bug 1509334 in plasma-nm (Ubuntu) "KDE/Plasma very slow to launch (Kubuntu 15.10)" [Undecided,Confirmed] [11:23] d_ed: on my todo list, thanks for the bug link [11:24] d_ed: cheers - thats affecting me [11:24] it's in 5.4.3, which is ETA mid Nov [11:26] * ahoneybun has a ssd so he is not feeling that [11:26] actually, you have bluetooth so you're not feeling that [11:27] we just sit idle for 30s doing nothing [11:27] ? [11:27] yeah , but removing NM from the panel is not a solution here, since I use vpn a lot , and I have no intentions of trying to configure openvpn and server in network interfaces [11:28] well, that's why we fixed it :D [11:30] d_ed, I must be missing a repos because nothing upgrades here [11:31] ah.. When I say "we" I mean KDE upstream [11:31] I'm here liasoning. [11:36] yofel: seems to be on the case :) [11:44] yofel: do you create a quilt patch for plasma-nm and put it in the packaging? [11:45] to patch libs/handler.h and libs/handler.cpp [11:45] clivejo: yes, do you want do prepare the SRU? I probably won't get to it until the evening [11:46] yofel: never done it before so unsure of the process [11:46] trying to follow what you do to fix it [11:46] hm, then it'll have to wait until later. Then I can tell you what needs to be done [11:47] does the patch go into debian git? [11:47] and if so what branch, now that wily is release? [11:48] yes, but you also need to branch of kubuntu_xenial_archive, put the patch there first, then prepare a similar upload with different version in kubuntu_wily_archive, update the bug with the SRU information and get things uploaded [11:48] eak [11:49] the prepare wily version is were I think you lose me [11:50] version numbers still confuse me [11:50] yofel: maybe give me a shout when you are free, Id like to go through it with you if thats ok [11:51] well, here it's easy. Say you have -0ubuntu1 in wily now, xenial would get -0ubuntu2, wily-updates -0ubuntu1.1 [11:51] sure, will have to wait until after work, so in ~6h [11:52] is there a script you run to start all the new xenial branches? [11:53] or are they done manually as needed? [11:53] good question.. no idea right now. I think manually is fine for now [11:54] Riddell: what was the process for vivid->wily back then? ^ [11:55] sitter had a script somewhere I think [11:55] manually is also fine [11:57] Riddell: would you show me the script? [11:57] when I say somewhere it's because I don't remember where :) [11:58] where is sitter these days, havent seen him about? [11:59] Riddell: how is that docs.kubuntu.co.uk server? [11:59] when does development on xenial official start? [12:00] once the toolchain upload is done. There'll be an announcement somewhere (ubuntu-devel ML I think?) [12:01] sitter said he was away on friday, I guess he's taking a long weekend [12:01] ahoneybun: still doing fine :) [12:02] Riddell: could you update it :) [12:02] ahoneybun: update what about it? [12:02] saw something about the toolchain for Oct 29th [12:02] the content? [12:03] https://github.com/ahoneybun/kubuntu-manual [12:03] make it like this: http://192.254.78.155/ [12:04] oh, that came out really nice :) [12:05] thanks yofel :) [12:05] * ahoneybun flys off to work [12:06] and me to lunch [12:06] bbl [12:06] ahoneybun: feel free to update it, not my responsibility any more I'm afraid [13:04] hi, does anyone here involved in plasma mobile want to host a session talking about it for the convergence track of UOS 15.11? [14:16] clivejo: actually, I just noticed that #ubuntu-devel says "Archive: open" - so xenial is already open for dev [14:18] yofel: Im trying to find the scripts sitter used [14:19] not having much luck [14:19] shadeslayer: do you know where those are ^ [14:19] Riddell: suggested the channel logs [14:20] but cant find anything yet [14:20] he may have just put it in a pastebin [14:20] not sure I would find anything there either. I believe the CI repo is on Alioth, but I don't remember how it's called [14:20] OTOH, scripting creation of a branch in all repos is something you can do with a 5-line bash script or so.. [14:21] I been looking at logs after the 23rd April 2015 [14:21] would hardly be done before it? [14:22] very unlikely, right [14:24] http://anonscm.debian.org/cgit/pkg-kde/applications/amor.git/log/?h=kubuntu_wily_archive [14:24] does it log when the wily archive was started? [14:25] that period of time looks like sgclark was working on it [14:30] ach it's just one command, just do it by hand [14:37] considering our workflow, santa_'s new scripts should probably have a failsafe check that makes sure the branch exists before it tries to check it out [14:38] so just leave it for now and just create the branch you need by hand [15:11] muon (master) v5.4.2-137-gcdc24d3 * Aleix Pol: discover/qml/PageHeader.qml [15:11] Fix margins in the page header [15:11] Only leave them on the side [15:11] http://commits.kde.org/muon/cdc24d3516b565bbdbe906147ee6cdd8480ccd0b [15:12] muon (master) v5.4.2-138-g1e8f40a * Aleix Pol: discover/qml/SourcesPage.qml [15:12] Fix sources page display [15:12] http://commits.kde.org/muon/1e8f40a82e577dfb9428579e817132936d75426b [16:25] clivejo: all by hand, I did not have a magic script. [16:32] I noticed that Telepathy auth for Google Hangouts has been changed, so now you have to login with your google account and than it justs uses the auth token [16:33] but the problem is that it doesn't work [16:33] after I login into google without any errors, when I try to go online it doesn't work [16:33] tries for a few seconds and than it stops without any errors [16:33] I'm on 15.10 [16:33] upgraded today [16:49] kustodian: Can you go to you GMail, and see if you have an e-mail about some kind of insecure, deprecated access attempt? [16:49] sgclark: wow, you must be very patient! [16:51] you may imagine a world without the automation scripts :P [16:51] heh yes [16:51] also had to do all the debian merges at the same time [16:52] hm, we have to do those too, right.. [16:52] yeah [16:52] * yofel imagines a 300-or-so long todo list [16:52] someone motivate me... [16:52] I am working on trusty and vivd backports right now, can after though. [16:52] yofel, clivejo: what you are trying to do? creating new branches for xenial? [16:53] santa_: that was the original topic, yes [16:53] yes, automatically [16:53] for frameworks/plasma/apps for example? [16:53] all of them [16:54] FWIW, as scarlett said, we have to do that anyway when we merge, so the point is moot in some sense [16:55] clivejo, yofel: give me a couple of minutes and I will send a terminator to the rescue [16:55] actually an early version of its firmware [16:55] XD [16:56] marco-parillo: I didn't receive an email like that [16:57] I checked in the list of allow applications and "KDE Online Accounts" is there and it has access to a lot of stuff [17:09] yofel: https://gitlab.com/kubuntu-clones/kubuntu-automation [17:09] in the automation-ng branch I have the first version of git-clone-all and do-all [17:10] so you can do this [17:10] $ mkdir ~/kde-all/ [17:10] $ cd ~/kde-all/ [17:11] $ git-clone-all [17:11] $ do-all "git checkout kubuntu_wily_archive" [17:11] $ do-all "git branch kubuntu_xenial_archive" [17:12] $ do-all "git push origin kubuntu_xenial_archive" [17:12] and I think that should do the thing if that's what you want to do [17:12] that page says 504, gitlab, what's wrong with you.. [17:13] sigh [17:13] let me create a clone in github then [17:18] yofel: https://github.com/jmsantamaria/kubuntu-automation-work [17:19] thanks, I'll try it out when I'm home [17:19] ~2h [18:06] yofel: will you please have a wee look at https://launchpad.net/~clivejo/+archive/ubuntu/wily/+build/8193598 when you get time [18:06] or even santa_ ^^ [18:13] think the version number is wrong :( [18:14] needs to be 4:5.4.2-0ubuntu1.1 for wily? [18:15] BluesKaj: ping [18:19] yes use 1.1 for wily-updates [18:19] Riddell: cant you check that over for me please :) [18:19] can you [18:23] I used the xenial packaging, to test build and upload to my PPA, do I need to push in wily archive too, with a different version number? [18:25] sorry I'm about to go out, but yes push it to wily_archive with the 1.1 version [18:25] with the 1.1 version number [18:25] yes [18:25] thanks :) [18:31] clivejo, pong [18:31] fancy testing plasma-nm for me? [18:40] clivejo: this build contains teh fix for the 30 sec lag [18:40] ? [18:40] or it was related to different package ? [18:40] I believe so [18:40] if I have done it right [18:41] ;D [18:41] but the version number is wrong [18:41] Im trying to fix that now [18:51] eak, 1.1 version is pending for 2 hours [19:22] clivejo: thanks for preparing plasma-nm, a few comments though [19:23] - please always commit with UNRELEASED unless the version has been uploaded to the primary archive [19:23] - the patch is either kubuntu_* -> origin: vendor, OR upstream_* -> origin: upstream. In this case, you'll want latter [19:25] - The changelog message is actually rather good, but slightly wrong: [19:25] "will be applied upstream" is "from upstream" - it's already been committed. [19:25] The parentheses around the patch name don't really make sense. [19:26] you indicate an upload fixing a bug with: LP: #0000000 - which is usually at the end of your changelog message. (That will then auto-close the bug once uploaded) [19:47] yofel: is it save to test it https://launchpad.net/~clivejo/+archive/ubuntu/wily/+build/8193870 ? [19:48] soee: yes [19:50] rebooting [19:51] back [19:51] yofel: interesting, system loads now in ~8 sec [19:51] so no lag as before [19:52] ok, so you did have the bluez issue. At least we know that it works fine :) [19:52] thanks for testing [19:52] yofel: one more reboot, just to be sure [19:53] yup, confirmed [19:53] system loads in ~ 8 sec now [19:54] clivejo: gret work with the package [19:54] allee: so in my case the lag was caused by bluez [19:55] yofel: what bug numer/link was it ? [19:55] lp 1509334 [19:55] Launchpad bug 1509334 in plasma-nm (Ubuntu) "KDE/Plasma very slow to launch (Kubuntu 15.10)" [Undecided,Triaged] https://launchpad.net/bugs/1509334 [20:03] yofel: just poted small info about it on G+, hope it wasn't to early :) [20:04] now there are 2 annying bugs left imo. [20:05] first: missing plasma-pa icon in systray [20:05] second: baloo indexer crash after system boot [20:05] I don't have the second, but I've seen the first one - but it's a bit random.. [20:10] yofel: http://paste.ubuntu.com/12973455/ [20:17] oh and: https://plus.google.com/+JakobHarz/posts/h39zc6U85hc [20:26] yofel: thanks, nice to know all those [20:26] so kubuntu_ patch is only for something affecting us? [20:27] is only for stuff either created by us or stuff specific to us [20:27] I see, I thought it was for a patch added by the kubuntu packagers [20:28] I commited xenial as UNRELEASED and wily with WILY, is that wrong? [20:30] regarding the patch name, should it be upstream_redhat_* to show where the patch came from? [20:30] no, just upstream_ [20:30] unless you got that from some RHEL repository or so [20:30] KDE commit [20:31] I used quilt import *.diff [20:31] right, so just upstream_ (i.e. it came from the repository that the source itself came from) [20:32] so at the end of my changelog I should put "* Fixes LP: #1509334" and LP will mark it as fixed? [20:32] Launchpad bug 1509334 in plasma-nm (Ubuntu) "KDE/Plasma very slow to launch (Kubuntu 15.10)" [Undecided,Triaged] https://launchpad.net/bugs/1509334 [20:33] drop the "* Fixes" [20:33] a) it belongs the the message above, b) the syntax already says that it fixes it [20:35] https://plus.google.com/110954078302330754910/posts/EYpzxwHXPG8 [20:35] should I make those changes in git? [20:35] yofel: also, have I broken KCI ? [20:36] please do the changes [20:36] as for CI, it's been rather red lately... haven't looked at it [20:40] do I put LP: #000000 on a new line? [20:41] that's up to you.. I usually only do that if the line gets too long [20:42] and my patch file should be .patch? [20:42] that again doesn't matter, just keep what you have now [20:43] regarding UNRELEASED, always use that unless you uploaded to the primary archive (or the target one) [20:43] doesn't matter if it's dapper or xenial [20:43] can I ommit an extension? [20:43] just call it - upstream_fix_making_bluez_asynchronous [20:43] I believe yes, but that's rather unusal.. [20:43] what is usual standard [20:44] have to change the name anyways, might as well get it right :) [20:44] I think .diff is what I've seen most, but I also saw .patch or nothing [20:45] Ill use .diff [20:51] okay, what do you actually want from us... [20:52] oh right, the patch will cause a build failure [20:52] ;] [20:52] oh? [20:53] well, you took a patch from upstream git, now you're building upstream git and applying an already applied patch -> BOOM [20:56] ah, that makes sense [20:56] how does one fix that? [20:56] remove the patch in git? [20:57] yes, in the _unstable branch once we're done [20:57] ok I pushed those changes [20:57] thanks [20:57] has the package been tested? [20:58] the one in my PPA? [20:58] soee said that it fixed his problem [20:58] clivejo: yup, rebooted twice to confirm it. system loads now in ~8seconds (before it was ~ 30) [20:58] should I redo a ppa2 with the new changelog? [20:59] would be useful yes, then we can copy that to the updates ppa once it's done building [20:59] then we can point people there [21:02] ok, now let me upload that and fill out the paperwork [21:03] yofel: can you explain? [21:03] !sru [21:03] Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [21:03] see "Procedure" [21:04] you have to write an essay on why the update should go into the archive? [21:05] yep [21:05] hence "paperwork" :P [21:06] the procedure comes from the very early ubuntu days where some X11 "quick fix" broke most of the user systems as an update [21:09] is it public? can I have a read, just for curiosity? [21:09] what? [21:09] the paperwork you submit [21:09] sure, it goes into the bug description [21:09] but I'll do that after the upload [21:10] which comes after I testbuild - which I do once my xenial chroot creation is done ^^ [21:10] all the stuff you have to do to fix stuff - that's why you don't break it in the first place :P [21:14] only way I learn is to do it :) [21:14] and that usually means breaking it and then trying to fix it [21:15] so you are currently building for xenial? [21:16] yep [21:18] I guess I should create a xenial pbuilder-dist image [21:18] and a xenial PPA [21:18] not sure why you need a seperate PPA, but the chroot you should do [21:18] or well, create it when you need it [21:21] http://tanglu.org/blog/2015/10/tanglu-40-dasyatis-kuhlii-alpha-released/ [21:27] xenial uploaded [21:28] yipppeee [21:29] wily uploaded [21:31] any idea if there are some decisions for Martin's proposal @ Plasma bugfix releases ? [21:42] don't we already have those? [21:42] or what do you mean? [21:43] clivejo: so, done updating the bug [21:43] now we have to wait [21:43] wait on what? [21:43] for it to land in main archive? [21:44] for someone from ~ubuntu-sru to approve the update and an archive admin to accept the upload [21:44] then the package has to be tested and tagged verification-done [21:45] once that's done and at least 7 days have passed the update can go into -updates [21:51] yofel: Martin proposed on #plasma releases like: 1 week, 1 week, 2 weeks , 4 weeks etc. [21:51] eakk [21:51] to get faster bug releases for users [21:51] such a load of fafff [21:52] have you put it in a kubuntu_testers PPA? [21:52] [11:12:40 CET] Riddell: I was thinking about how we can get our bug fixes faster to the user and had the idea of doing fibonaci releases [21:52] [11:13:01 CET] that is: 1 week, 1 week, 2 weeks, 3 weeks and then depending whether we have bug fixes even more [21:53] hm... that does make sense actually.. [21:53] so I wouldn't mind