[02:04] <pursuivant> muon (master) v5.4.2-139-g886f3a8 * Aleix Pol: discover/IconColors.cpp
[02:04] <pursuivant> Make it possible to build with Qt 5.5
[02:04] <pursuivant> http://commits.kde.org/muon/886f3a8193f388555fa98cfdb5e8054592a40371
[02:47] <sgclark> I do believe the red is stemmed from a lack of qt 5.5
[08:07] <lordievader> Good morning.
[09:28] <Riddell> ? http://fridge.ubuntu.com/2015/10/26/joint-statement-kubuntu-council-community-council/
[09:28] <Riddell> "both councils collaborated and resolved any tensions together" they bully me so I feel I have to leave and that's resolved?
[09:29] <Riddell> they still claim restrictions on ubuntu software which do not exist and which are contrary to ubuntu policy
[09:31] <sitter> count as resoled tension in my book
[09:31] <allee> Riddell: I was also confused when I read the blog post
[09:31]  * sitter can't type nomo
[09:34] <lordievader> Reads a bit like a cover up story, pretending everything is fine...
[09:35] <allee> Only MHO of course: I think as long a  ubuntu CC does not state that in the future they promise coordinate from the begining with Kubuntu CC before any action against kubuntu members nothing is resolved. 
[09:36] <Riddell> that's the UCC preferred way of resolving tension... I'm speachless
[09:38] <allee> Riddell: does this mean the post had not the blessing of k cc?
[09:39] <Riddell> I've no idea
[09:40] <sitter> doesn't seem to have been proof read anyway :P
[09:43]  * Riddell posts http://jriddell.org/2015/10/27/resolving-tension/
[10:36] <clivejo> good morning ladies and gents
[10:38] <lordievader> o/
[11:08] <yofel> Riddell: your tension is not resolved I guess, and I doubt it ever will if you keep holding a grudge against the CC. 
[11:09] <yofel> allee: well, lets say we decided to regularly talk to each other so this doesn't happen again in the first place. How well that will turn our has to be seen
[11:09] <yofel> *turn out
[11:09] <Riddell> I'll keep doing that while they support claims that go against ubuntu policy and upstream licences
[11:10] <yofel> I still don't get how you expect them to say that it's against the policy if even the SFLC cannot easily say that.
[11:11] <yofel> Sure, the issue isn't resolved, but I think we managed to get to a point where both councils are not throwing insults at each other anymore
[11:11] <yofel> hence "tension resolved"
[11:11] <lordievader> Not throwing insults at each other is good.
[11:12] <yofel> so lets get back to a CoC compliant way of working together and improve things
[11:13] <BluesKaj> Hiyas all
[11:23] <Riddell> yofel: the ubuntu policy is that packages in main "Must allow modification and distribution of modified copies under the same licence." canonical and the canonical staff on the UCC are claiming that binaries can not be freely copied
[11:24] <Riddell> the SFLC only cared about the copyright licence which is different from the ubuntu policy
[11:37] <yofel> that's another great sentence that says nothing in reality. If the license itself isn't explicit about the modification rights, then you still "only" have the rights implied by the license, plus additional conditions if the license allows that. 
[11:37] <yofel> so if you want I can quote rohan for the Xth time that this is rather unclear when it comes to permissive licenses.
[11:39] <Riddell> all licences in ubuntu are clear that they allow modification and distribution of modified copies under the same licence, else they would not get into ubuntu
[11:39] <Riddell> no additional restrictions are put onto them
[11:40] <Riddell> and to do so would be against that ubuntu policy
[11:43] <yofel> okay, I didn't read far enough..
[11:43] <yofel> it does say below "You, the user, must be able to pass on any software you have received from Ubuntu in either source code or compiled form."
[12:14] <clivejo> yofel: how do I include the kernel dev packages in a control file?
[12:14] <yofel> clivejo: er, what exactly are you trying to do?
[12:14] <clivejo> package ktoshiba
[12:14] <clivejo> needs kernel developer packages
[12:15] <clivejo> for TOSHIBA_ACPI_SCI
[12:15] <yofel> okay, so that's a kernel module?
[12:15] <TJ-> clivejo: for building the package? build-depends linux-headers-$FLAVOUR
[12:16] <TJ-> clivejo: if it's a DKMS module, a regular depends instead
[12:16] <clivejo> I believe so, requires Kernel 4.3+
[12:17] <TJ-> Oh, actually, for DKMS it just needs to depend on dkms itself
[12:21] <clivejo> how do I specify which kernel version
[12:21] <clivejo> Ive tried just using linux-headers
[12:30] <TJ-> clivejo: it shouldn't be tied to a particular version, but maybe a >= is suitable
[12:30] <TJ-> Are you making a DKMS package? That's the way to deal with out-of-tree kernel modules
[12:31] <clivejo> TJ-: I dont know
[12:31] <clivejo> just messing about, trying to package this http://kde-apps.org/content/show.php/KToshiba?content=18621
[12:32] <sitter> KToshiba from SVN :O
[12:32] <clivejo> sitter: ??
[12:33] <clivejo> I have a Toshiba laptop and spotted it on the RSS feed and thought Id have a go
[12:33] <TJ-> That looks like a GUI/userspace application. Does it include a kernel module too? If so, the kernel module should be be separated into a <package>-dkms package
[12:33] <clivejo> TJ-: no idea :/
[12:34] <sitter> TJ-: it's not a module, apparently it just needs a new enough kernel due to ioctl request id helper TOSHIBA_ACPI_SCI
[12:34] <sitter> https://github.com/torvalds/linux/blob/master/include/uapi/linux/toshiba.h only introduced jul 24
[12:34] <clivejo> error: ‘TOSHIBA_ACPI_DEVICE’ was not declared in this scope
[12:34] <clivejo>      m_file.setFileName(TOSHIBA_ACPI_DEVICE);
[12:34] <clivejo> gets to 10%
[12:35] <sitter> yeah, I am not sure we hav ea new enough kernel in wily TBH
[12:35] <yofel> we don't
[12:35] <TJ-> sitter: clivejo then there's no need to specify a package dependency on a kernel version, maybe add code to check for the IOCTL at run-time and report if the kernel doesn't support it
[12:35] <clivejo> ah that would be the problem then!
[12:36] <TJ-> clivejo: alternatively, do the IOCTL check in the postinst - but that doesn't help where a system has multiple kernel versions available. Run-time check is best
[12:36] <clivejo> The System Settings module now requires toshiba_acpi driver version 0.23, which is included in kernel 4.3, if you don't want to upgrade your kernel, see the file README.toshiba_acpi
[12:36] <sitter> clivejo isn't the author
[12:36] <sitter> neither am I
[12:36] <TJ-> It doesn't take much to add a patch to check for the IOCTL
[12:36] <clivejo> Im running 4.2.0-17-generic
[12:36] <sitter> it does take author approval
[12:36] <sitter> and seeing as the author hasn't made it optional I doubt we'd get that
[12:37] <TJ-> The patch can be applied in the packaging
[12:37] <sitter> we do not apply patches that aren't approved
[12:37] <sgclark> morning
[12:38] <sitter> sgclark: おはようございますo/
[12:42] <TJ-> sitter: why is that?
[12:44] <clivejo> I might install Kernel 4.3
[12:44] <clivejo> anyone else using it?
[12:45] <TJ-> clivejo: Yes
[12:46] <clivejo> any issues?
[12:46] <TJ-> clivejo: There always are - its software!
[12:48] <clivejo> no 64bit for 4.3RC ?
[12:52] <TJ-> clivejo: Yes, of course there is
[13:00] <yofel> clivejo: http://kernel.ubuntu.com/~kernel-ppa/mainline/
[13:00] <yofel> use with caution
[13:17] <TJ-> clivejo: Oh, if you mean the Ubuntu mainline builds - there's a bug in the build scripts causing failures for the amd64 builds
[13:23] <TJ-> Apparently apw has fixed that in the last 24 hours and amd64 builds should start to appear shortly
[13:37] <pursuivant> muon (master) v5.4.2-140-g0a71afd * Aleix Pol: libmuon/backends/DummyBackend/tests (3 files)
[13:37] <pursuivant> Fix tests
[13:37] <pursuivant> They weren't adapted to delayed run of the dummy backend.
[13:37] <pursuivant> http://commits.kde.org/muon/0a71afdc539cdcc34a7f95f43657f53edf7b6412
[13:38] <yofel> TJ-: how come there is an amd64 build for rc7 if those are broken o.O?
[13:38] <yofel> or do you mean they're unfunctional?
[13:41] <TJ-> yofel: For the past week the amd64 builds were failing due to a ZFS issue; apw fixed the build scripts  so builds are now happening. versions such as v4.2.4-unstable still don't have amd64 kernel builds
[13:41] <yofel> ah ok
[15:11] <pursuivant> muon (master) v5.4.2-141-g9727e82 * Aleix Pol: libmuon (3 files in 3 dirs)
[15:11] <pursuivant> Improve test coverage of ReviewsModel test
[15:11] <pursuivant> And fix the problems while at it. :)
[15:11] <pursuivant> http://commits.kde.org/muon/9727e822df6d5c670a7cee1db4e965b611f2438b
[15:14] <pursuivant> muon (master) v5.4.2-142-g0706e9e * Aleix Pol: libmuon/backends/DummyBackend/tests/DummyTest.cpp
[15:14] <pursuivant> Use ModelTest with the UpdatesModel test in Dummy
[15:14] <pursuivant> http://commits.kde.org/muon/0706e9ec41e410eaea255776ffedd77356e499be
[15:47] <genii> Odd behaviour on 15.04, windows open by default on secondary display ( previously the primary ) until after automatic update check finishes, then they open on the primary as would be the expected behaviour. Seems like system settings for primary/secondary are not applied until after update check is finished
[16:03] <mck182> can I make the oom_killer more effective?
[16:03] <mck182> currently it's really useless
[16:03] <mck182> it goes swapping for 10 minutes and most of the times does not recover ever
[16:19] <kfunk> mck182: swapoff -a :)
[16:19] <mck182> kfunk: but I have no swap :(
[16:19] <kfunk> then it can't swap
[16:20] <mck182> well I assume that's what kswapd does
[16:20] <mck182> when the laptop gets into the oom state, you can see kswapd taking most of the cpu..I dunno what it's doing
[16:21] <mck182> all I would like to have is the oom_killer going "oh, we are about to run out of memory here, let me just kill something so you system does not become unusable for the next 15 minutes"
[16:21] <mck182> I did set some oom_killer setting
[16:21] <kfunk> never seen that
[16:22] <kfunk> oom_killer "does its job" here
[16:22] <mck182> I have /always/ seen that on all my machines...sigh
[16:22] <mck182> I have ~50 chromium tabs opened, kdevelop and typing make -j4 brings it down
[16:22] <mck182> always.
[16:22] <kfunk> bad RAM / bad kernel? try googling a bit. I'm sure the behavior of your machine is untypical
[16:22] <mck182> I had this consistenly on 3 different machines tho
[16:22] <mck182> so I assumed it's a general problem
[16:23] <mck182> it also brings down a powerful machine with 16gb ram and an ssd disk
[16:31] <yofel> FWIW, I've seen the same thing here. Memory gets like 95% full, but instead of swapping kswapd goes mental and locks the system up (no idea what it does as the system is frozen)
[16:31] <yofel> I tried playing with memory pressure settings and stuff, but didn't really help
[16:31] <yofel> with recent kernels it's a bit better..
[16:33] <mck182> there is this: http://askubuntu.com/questions/398236/oom-killer-not-working
[16:33] <mck182> it does help a bit
[16:33] <mck182> but not in all cases
[17:01] <pursuivant> muon (master) v5.4.2-143-g82c6063 * Aleix Pol: discover (4 files in 2 dirs)
[17:01] <pursuivant> Make it possible to show flat tool buttons on the UI
[17:01] <pursuivant> http://commits.kde.org/muon/82c6063a93f5c16a32842a8d4a2a98c1f0ed005d
[17:56] <marco-parillo> Thanks to yofel and team: My kinfocenter reports Kubuntu 16.04
[18:46] <santa_> yofel: did you have time to test the things we have so far in automation-ng?
[18:55] <alvin> Is it me, or is bugs.kde.org extremely slow? I have been loading https://bugs.kde.org/show_bug.cgi?id=316153 for the past 7 minutes and it's not yet there.
[18:55] <alvin> While this bot gets it immediately....
[18:57] <marco-parillo> It is you (unless you have very high standards).
[18:57] <alvin> Still loading. Wel, it depends. It's a 240Mbit connection. Can't have all sites at that speed, but this is ridiculous
[18:59] <marco-parillo> Between the time you asked, I hit BKO for the first time ever on this VM, Logged In, and returned a list of all the bugs I follow before I replied to you.
[19:00] <alvin> Whoa. Well, I can do that on Launchpad, but not on bugs.kde.org. Still not loaded. I can see some of the text, but no layout yet
[19:01] <marco-parillo> Of course, I am the last person left using rekonq, so maybe it is your browser ;-)
[19:02] <alvin> I'm starting to think it's IPv6 that's the problem. Not sure though
[19:05] <alvin> Confirmed. It certainly IS IPv6.
[19:07] <clivejo> yofel santa_ : "Kubuntu'ers, can you help merging these to your kubuntu_unstable branch so I can use it for the Plasma Phone?" on the mailing list, what needs merging and can I help?
[19:07] <alvin> ok. Voted. My wife is a bit annoyed. She can no longer erase her mail. Neither can I, but I'm using webmail to erase them. Kmail in Kubuntu 15.10 can no longer do this. When will there be a new version?
[19:10] <alvin> I'm starting to think that this isn't the bug that was originally reported. People added comments about 'since Kubuntu 15.10 at the end, but it was reported in 2013 and I can also only confirm on 2 Kubuntu 15.10 machines'
[19:12] <santa_> clivejo: I would leave that one for more experienced people
[19:12] <clivejo> santa_: no problem
[19:13]  * clivejo goes back to fixing the inverter
[19:14] <yofel> santa_: not yet, was busy with other things
[19:14] <santa_> ok
[20:09] <mhall119> hi everyone, I'm still looking for someone who can show off and talk about Plasma Mobile at Ubuntu Online Summit next week, can someone here help me out?
[20:14] <soee> mhall119: isn't #plasma channel better place to ask ? :)
[20:17] <mhall119> soee: might be, given that the device images are based on Ubuntu touch/Kubuntu I was hoping to get someone from here
[20:21] <mhall119> ok, mobile aside, does anybody want to run Kubuntu related sessions?
[20:21] <mhall119> they can be presentations, demos, orplanning sessions
[20:22] <yofel> mhall119: a planning session would be good, where does one ask for sessions?
[20:23] <yofel> ahoneybun: do you plan something for the documentation?
[20:23] <sgclark> yeah we could use some planning 
[20:23] <mhall119> yofel: http://summit.ubuntu.com/uos-1511/propose_meeting/
[20:23] <yofel> thanks
[20:24] <mhall119> yofel: the "convergence" track has kind of consumed mobile and desktop topics
[20:24]  * sgclark goes back to her backports
[20:24]  * mhall119 wants to find a better track name for next UOS
[20:24] <yofel> mhall119: "consumed"?
[20:24] <mhall119> yofel: there used to be a dedicated "Desktop" track
[20:24] <yofel> aah
[20:25] <mhall119> but last UOS and this one, rather than having a separate "Mobile" track, we combined it with desktop and changed the name
[20:25] <yofel> ok, thanks. Then I know what to select there :)
[20:26] <yofel> mhall119: do I need to add something for those URLs? I thought the Pad is auto-generated for a session?
[20:27] <yofel> I should at least make a wiki page though..
[20:27] <mhall119> you don't need to, but they're there if you want them
[20:28] <yofel> ok
[20:28] <mhall119> pad is auto-generated based on the title, yeah, but can be overwritten
[20:28] <mhall119> wiki is mostly a leftover from the UDS days and before Blueprints had useful whiteboards and work item tracking
[20:28] <mhall119> I'm not sure anybody uses it anymore
[20:30] <yofel> okay
[20:31] <yofel> mhall119: where does that participant list come from?
[20:33] <mhall119> yofel: people who have registered as attending the UOS
[20:34] <mhall119> via http://summit.ubuntu.com/uos-1511/registration/
[20:34] <yofel> aaaah, I should probably do that ^^
[20:34] <ahoneybun> yofel: mhall119 it would maybe be a showcase with Sphinx?
[20:36] <mhall119> ahoneybun: ??
[20:36] <ahoneybun> mhall119: documentation tool
[20:36] <mhall119> ahoneybun: I know what sphinx is, I'm just not sure what the context of your question was
[20:37]  * mhall119 feels like he's missing have a conversation
[20:37] <ahoneybun> showcase of what can be done with sphinx maybe
[20:37]  * ahoneybun has to finish his blog post and his talk...
[20:37] <mhall119> ahoneybun: are you proposing a session?
[20:37] <mhall119> for UOS or UbuCon?
[20:38] <ahoneybun> both?
[20:38]  * mhall119 won't say 'no' to that :)
[20:39]  * ahoneybun keeps pushing "Update" on his N4 for working mouse pointer
[20:39] <mhall119> yofel: if you have a particular day and time you'd like your session let me know
[20:39] <mhall119> ahoneybun: do you have a mouse connected?
[20:39] <ahoneybun> I've had one but with no pointer
[20:39] <ahoneybun> the new rc-proposed image should fix that
[20:40] <yofel> mhall119: is the scheduling automatic? I won't be able to participate on thursday, so it would be nice if it would get scheduled on 3./4.
[20:40] <mhall119> yofel: no, it's all manual now, so myself or cimi from the desktop team can do it
[20:41] <mhall119> yofel: would earlier (for Europe) or later (for west-coast US) be better?
[20:41] <yofel> later would be better I believe
[20:42]  * ahoneybun votes for later
[20:43] <mhall119> 1900 UTC on the 3rd is available, or we have 1800 or 1900 on the 4th
[20:43] <yofel> then lets take 1900 on the 3rd
[20:44] <ahoneybun> 1900 UTC
[20:44] <ahoneybun> ?
[20:44] <yofel> yep
[20:45] <mhall119> yofel: you got it :)
[20:45] <yofel> mhall119: thanks!
[20:46] <yofel> I'll tell the others on the ML and come back to you if it doesn't work out. But at least we have a date to plan for now, so thanks for the UOS reminder.
[20:46] <mhall119> FYI, there's a session on Qt in 16.04 immediately before that, at 1800 UTC, so that would probably lead nicely into yours
[20:46] <ahoneybun> that works 3pm in my TM
[20:46] <ahoneybun> TZ
[20:47] <ahoneybun> crap
[20:47] <ahoneybun> nm
[20:47] <ahoneybun> Podcast is on the 4th
[20:47] <yofel> wasn't that supposed to be on the 7th?
[20:47] <ahoneybun> it is on the first weds of the month
[20:47] <ahoneybun> which is the 4th
[20:48] <yofel> hmkay, well, this way you'll at least be able to tell the public something :)
[20:51] <sgclark> err that is 11am for me, how can it be 3 for you ahoneybun? it is 2 I think..
[20:51] <ahoneybun> 1900 uTC?
[20:51] <sgclark> I guess I need to register
[20:51] <sgclark> aye
[20:51] <ahoneybun> google says 3pm
[20:51] <sgclark> says 11 for me! hmm
[20:54] <mhall119> ahoneybun: sgclark: we have a DST change this coming weekend, remember
[20:55] <sgclark> blech
[20:55] <sgclark> ok
[20:55] <sgclark> I lived in Az for too long, still can't get used to that
[20:55] <mhall119> so 1900 UTC today is going to be different than 1900 UTC next week :)
[20:55] <mhall119> fun times
[20:55] <sgclark> hahahah
[20:55] <mhall119> DST is by far one of humanities worse ideas
[20:55] <sgclark> well I registered, likely ffor the wrong time
[20:56]  * yofel didn't know that the DST switch days differed around the world...
[20:56] <yofel> we already did the switch here
[20:57] <sgclark> umm how do I become an attendent?
[20:58] <BluesKaj> George Bush  switched it to the weekend after Hallowe'en in the US..most sensible thing he ever did as president :-)
[20:58] <sgclark> nm I am blind
[20:59] <BluesKaj> ok, got 16.04 working from the daily ...seems ok so far 
[21:00] <BluesKaj> anyway that's it for today ...later
[21:00] <soee> :D
[21:01] <santa_> aaaaahhhhhhh
[21:01] <sgclark> ?!
[21:01] <santa_> I can't log into wiki.ubuntu.org
[21:01] <santa_> darn
[21:02] <santa_> * .com
[21:02] <yofel> uh, try it like a dozen times. If you're lucky it'll work eventually
[21:03] <santa_> so it hangs for you too?
[21:03] <santa_> I never logged in before, but I have the ubuntu one account
[21:03] <santa_> which works for launchpad, but not for the wiki right now
[21:03] <yofel> I try to never log out, but yeah, I usually get the same hangs from the wiki
[21:04] <yofel> one of the reasons why we use the kde wiki for most of our stuff
[21:05] <santa_> :O it seems it logged in now
[21:05] <santa_> I left the browser like 30 min ago doing the thing
[21:37] <mhall119> I've been involved in Ubuntu for like 8 years now, and the wiki has always been like that
[21:56] <yofel> in some sense that's also a way of spam protection... 
[22:31] <valorie> lol, what an upside, yofel