[06:50] <Tehdastehdas> apw, I didn't get the part about the machine not being representative of its kind, as many machines in the original slow fan bug report comments are claimed to run their fans faster and CPUs cooler in the fan control disengaged mode. I haven't tried tweaking thermald, as reading this https://wiki.ubuntu.com/Kernel/PowerManagement/ThermalIssues , my thermal-conf.xml and its manual page I can't understand how to redefine fan
[06:50] <Tehdastehdas> speeds so that 'disengaged' mode would be the new highest speed.
[07:07] <Tehdastehdas> "Currently, the Linux kernel thermal ACPI module implements these controls. So, based on the validity of configuration data, this can be a very efficient method for thermal controls. But, it was observed that many systems don’t have this configuration data or have invalid data, preventing the kernel module from taking timely action." https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon
[07:17] <Tehdastehdas>  Which channel should I go to for thermald support?
[09:36] <rbasak> Is smb on holiday? Any idea when he's back?
[10:19] <apw> rbasak, yes, and err ...
[10:19] <apw> rbasak, is this about dpdk, if so arges may be in the loop
[10:30] <Tehdastehdas> I wrote about the Lenovo slow fan bug to the thermal_daemon (thermald) mailing list.
[10:40] <rbasak> apw: yeah, dpdk. Thanks. I wanted to clarify some bits about upstream's build system that smb would know, but I can look or wait until next week.
[10:40] <apw> Tehdastehdas, sound like a plan
[10:41] <apw> rbasak, arges was involved in deep review so if you have queries, do ask
[11:35] <jpds> apw: You seen https://askubuntu.com/questions/670106/igb-detected-tx-unit-hang ?
[11:37] <apw> jpds, nope, kamal henrix a nice regression in stable for you ...
[12:19] <henrix> apw: looking
[12:21] <henrix> oh joy
[12:54] <henrix> jpds: are you able to reproduce this igb bug?
[12:56] <jpds> henrix: Nope, I saw some people in #ubuntu-server complaining about it
[12:58] <henrix> jpds: ah, thanks.  i'll try to get a test kernel built (still looking at the bug).  i'll just add a link to that kernel in the bug (bug #1492146)
[12:59] <jpds> henrix: Asked the person to join here
[12:59] <henrix> jpds: cook, thanks
[13:02] <bananapie> Is there a page somewhere that lists the differences between Ubuntu's kernel and vanilla kernel?
[13:05] <rozie> I was hit by kernel bug http://askubuntu.com/questions/670106/igb-detected-tx-unit-hang can I expect it to be fixed in next kernel release?
[13:06] <rozie> right now I downgraded to 3.16.0-46-generic (Ubuntu 14.04 LTS). have spare machine for tests.
[13:07] <henrix> rozie: i'm looking at that bug (bug #1492146), and i'll try to have a test kernel built in a bit
[13:07] <henrix> rozie: would you be able to test it, to see if it actually fixes the issue?
[13:11] <rozie> henrix: which solution exactly?
[13:12] <henrix> rozie: looks like a bad backport in one of the patches in the 3.16.0-48.64 kernel
[13:13] <henrix> rozie: there were a bunch of hyper-v related patches in this kernel; the test kernel will simply revert them, as i suspect that one of these patches is incorrect
[13:13] <henrix> (incorrect = bad backport)
[13:26] <henrix> rozie: i've uploaded a test kernel here: http://people.canonical.com/~henrix/lp1492146/v1/amd64/
[13:26] <henrix> rozie: i've also included in that URL the patches i'm reverting.  i believe the 'bad' one is the first one, so i had to revert them all :-/
[13:27] <henrix> rozie: if you could give it a spin would be great
[13:27] <henrix> rozie: i'll also add this URL (and request for testing) in the bug
[13:29] <rozie> OK, installing http://people.canonical.com/~henrix/lp1492146/v1/amd64/linux-image-3.16.0-48-generic_3.16.0-48.64~14.04.1~lp1492146v1_amd64.deb and http://people.canonical.com/~henrix/lp1492146/v1/amd64/linux-image-extra-3.16.0-48-generic_3.16.0-48.64~14.04.1~lp1492146v1_amd64.deb right now
[13:30] <henrix> rozie: awesome, thanks!
[13:36] <rozie> booting... I have about 1 hour left, so it would be great if we manage to fix/test it in this time
[13:37] <rozie> henrix: booted. looks stable
[13:40] <henrix> rozie: awesome, thanks.  if you're not able to reproduce the issue with this kernel, then i guess you're done for now ;)
[13:40] <henrix> rozie: we'll eventually respin this kernel again (probably today), and i'll eventually ask in the bug for people to re-test again before releasing
[13:41] <henrix> (2 'eventually' in the same sentence...)
[13:41] <rozie> I'll be probably available tomorrow around 9AM UTC
[13:43] <rozie> feel free to give specific version to test. the good thing is I have spare machine and independent access ;-)
[13:43] <rozie> if you need anything, I'm available for 45 min more today
[13:45] <henrix> rozie: awesome, thanks.  i'll ping you if i have a final version ready tomorrow
[13:58] <rozie> :-)
[14:27] <jpds> rozie: Do you have an askubuntu account to update the page?
[14:29] <rozie> jpds: I have lauhchpad, but noscript blocks CSS for askubuntu. works fine for ask.openstack
[14:30] <jpds> Hmm
[14:31] <rozie> I know, it's another channel thing ;)
[14:33] <rozie> used another browser
[14:33] <rozie> jpds: can you tak a look? any other info needed?
[14:34] <jpds> rozie: I think henrix has an eye on the ball
[15:21] <jsalisbury> **
[15:21] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:21] <jsalisbury> **
[16:12] <willcooke> hi mjg59 - I was reading this the other day:  http://mjg59.dreamwidth.org/34868.html  -  did your patches get in to the kernel?
[16:45] <mjg59> willcooke: Still working on reverse engineering the Intel driver so I can figure out the blacklisting
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[16:57] <cristian_c> jsalisbury: hi
[16:59] <jsalisbury> cristian_c, hi, I never got a response from upstream.  I'll ping them again and cc the bug
[16:59] <cristian_c> jsalisbury: ok
[17:11] <rtg> henrix, kamal: ad1ed2a9dd4c435d6a3ce470211db9a8d107c3e0 should be added to the 3.19 stable kernel
[17:12] <henrix> rtg: wow! that patch has enough context to see the bug :)
[17:13] <rtg> henrix, yeah, it seems like a no brainer
[17:14] <kamal> rtg, henrix: jesus you're not kidding!  ack, I'll pick it up
[17:14] <kamal> rtg, do we know when it got broken?
[17:15] <rtg> kamal, the driver was added in 3.19, the locking fix came in 4.0
[17:15] <kamal> rtg, good.  thanks.
[17:18] <psivaa> cking: hello,
[17:18] <psivaa> Not sure if you're still interested in health-check results in http://ci.ubuntu.com/smokeng/trusty/desktop/i386/20150908/13806/health-check/
[17:18] <cking> psivaa, i'll just have a look...
[17:19] <cking> psivaa, \o/, excellent!
[17:19] <psivaa> cking: There were a couple of failures in the last couple of days and since we moved the hosts the VM installation takes place, we're wondering if the failures have anything to do with the VM host migration
[17:20] <psivaa> cking: one of such failures is https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-amd64-smoke-health-check/321/artifact/utah-810-trusty-amd64_master.run_2015-09-07_12-09-29.yaml/*view*/
[17:20] <cking> psivaa, are the failures still occurring?
[17:20] <psivaa> cking: they appear to be 'flaky'. i.e a rerun passes
[17:21] <cking> hrm, yep, the failure on the URL shown above is probably a sporadic memory allocation that skewed the rates
[17:22] <psivaa> the failed ones on https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-amd64-smoke-health-check/ have all the same test failure, but as i said they pass on reruns
[17:23] <cking> i'll eyeball those in a while, I've got some food waiting for me to be eaten..
[17:23] <psivaa> cking: sure, we'll be happy to leave that to see if that settles down. Please feel free to ping us back if you think that the host migration being any reason
[17:40] <cking> psivaa, let's see if it settles down, if not, then lets dig into it deeper
[17:41] <psivaa> cking: sounds good


[02:03] <Lutin> sabdfl: thanks :)
[02:24] <lbm> any lp admins online?
[02:48] <Lutin> sabdfl: btw, could you also change my mail adress from<EMAIL_ADDRESS>to<EMAIL_ADDRESS>please ?
[02:55] <Hobbsee> Lutin: it's suggested you file a support request for such things...
[03:05] <Lutin> Hobbsee: I did, and he changed my lp nick but seems to have forgotten the mail change ;)
[03:06] <Hobbsee> Lutin: ah.  not sure if they autosync.
[03:07] <Lutin> Hobbsee: I think they don't, given LaserJock's mail adress
[03:07] <Hobbsee> ah
[03:11] <Lutin> heh, need some sleep. see you alter guys
[03:41] <Ubugtu> New bug: #89360 in launchpad "Font color does not have enough contrast" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89360
[05:30] <Ubugtu> New bug: #89375 in launchpad "LP beta: Missing navigation links on translation page." [Undecided,Unconfirmed]  https://launchpad.net/bugs/89375
[05:45] <Ubugtu> New bug: #89376 in launchpad "LP beta: Opera doubles down on "Help"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89376
[07:30] <SEJeff> Can anyone help me figure out why launchpad isn't letting me file bugs against the kernel image package? Especially since I'm trying to report an oops
[07:38] <BjornT> SEJeff: sure. on which page are you trying to file the bug?
[07:39] <SEJeff> https://launchpad.net/ubuntu/feisty/i386/linux-image-2.6.20-9-generic/2.6.20-9.16
[07:46] <BjornT> SEJeff: hmm. it really should be easier to file a bug from that page, atm it's not intuitive.
[07:46] <BjornT> SEJeff: the thing is that the bug should be filed on the corresponding source package in ubuntu.
[07:47] <BjornT> SEJeff: so you have to start with following the link to the feisty source package on the bottom of the page
[07:47] <SEJeff> BjornT: Seriously, it doesn't make sense. A UI that is so unintuitive, a non-newb can't figure out how to file a bug is kind of stupid
[07:47] <SEJeff> How does the lp team expect newbies to file bugs? </launchpad-rant>
[07:48] <BjornT> SEJeff: from there you have to follow the link to the linux-source-2.6.20 package on the top of the page, and there you should have a "report a bug" link on the left
[07:48] <LaserJock> generally you wouldn't start from that page though
[07:48] <BjornT> SEJeff: how did you end up at that page to begin with?
[07:49] <SEJeff> package search for linux-image
[07:49] <LaserJock> generaly you'd start from launchpad.net/ubuntu/+filebug or the source package page
[07:50] <SEJeff> Actually, wouldn't a new user start at launchpad.net and then click ubuntu to file a bug against "ubuntu"? Or am I incorrect?
[07:50] <SEJeff> LaserJock: But thanks, I'll bookmark that
[07:50] <LaserJock> yes, exactly
[07:50] <LaserJock> that's what the url above is
[07:50] <LaserJock> that's what you get when you start at launchpad and click on the file a bug against ubuntu
[07:52] <SEJeff> LaserJock: I see it now. My workflow was: Go to lp.net, see "The Ubuntu Distro" click, search for packages, ...
[07:52] <LaserJock> right, but you still should have been ok
[07:52] <SEJeff> I skipped over the bugs link at the top left
[07:52] <SEJeff> Thanks
[07:53] <BjornT> SEJeff: i agree that it should be possible to file a bug using your workflow as well.
[07:53] <LaserJock> it is though, he just went too far :-)
[07:54] <BjornT> that's one way of looking at it :)
[07:54] <SEJeff> LaserJock: Is there a RFE page for launchpad?
[07:54] <SEJeff> Because that seems like something a normal user would do
[07:55] <LaserJock> BjornT: it would only make sense really to have a link where he was if it was "File a bug against this version"
[07:55] <LaserJock> BjornT: which would be cool
[07:56] <LaserJock> becuase filing a bug from that page would indicate you are interested in a particular version
[07:56] <BjornT> SEJeff: for small features like this it's easiest to file a bug at https://launchpad.net/malone/+filebug
[07:56] <SEJeff> I understand that apport + the kernel patches and core_pattern are all supposed to be magic, but when it doesn't work, that is a pain
[07:56] <SEJeff> I was really hoping that apport would catch the oops and report it, but it caught something and then killed itsself
[07:57] <LaserJock> how is it a pain?
[07:58] <BjornT> LaserJock: yeah, it could be useful to include the package version there.
[08:00] <SEJeff> LaserJock: Because a fairly straightforward workflow leads to an insensitive Bugs link. I almost decided to not even report the oops because of that actually
[08:00] <LaserJock> I don't really understand
[08:01] <LaserJock> you just overlooked the filebug link
[08:01] <SEJeff> ok. When glancing over lp.net, I missed bugs
[08:01] <SEJeff> Correct
[08:01] <SEJeff> And saw the most prominent Ubuntu Distribution on the page
[08:01] <SEJeff> So of course, I want to file a bug against Ubuntu, so I click it
[08:01] <SEJeff> But that leads to a dead end
[08:03] <BjornT> LaserJock: i think the thing is that SEJeff thought that he should file a bug on the specific version of the package. and it's easy to overlook the filebug link if you have your mind set on navigating to the binary package.
[08:03] <SEJeff> Well when you are using feisty and a previous kernel didn't break... you *should* file against a specific version
[08:03] <SEJeff> Or am I again wrong in thinking like this?
[08:03] <SEJeff> It seems logical
[08:04] <LaserJock> yep, we don't file against versions
[08:04] <SEJeff> ok, thanks
[08:04] <LaserJock> we file against a source package and that's pretty much it
[08:04] <SEJeff> Im used to bugzilla
[08:04] <LaserJock> I'd *love* to see the ability to file against a specific version
[08:05] <LaserJock> I'm not sure what would happen if the bug applied to more than one version
[08:06] <BjornT> LaserJock: once upon a time we tried to cover that by using something called "infestations", but we removed it since it was too complicated
[08:06] <SEJeff> LaserJock: I'm perplexed that it doesn't support a feature so obvious for a BTS
[08:07] <BjornT> SEJeff: it has been discussed quite a lot of times. and so the the outcome has been, that the version information should be put in the bug description
[08:07] <BjornT> we might consider adding a specific version field, though.
[08:08] <BjornT> s/so/so far/
[08:08] <SEJeff> BjornT: Launchpad is a good idea and will probably be pretty good. I've heard decent things about the beta, but that it is really slow
[08:09] <LaserJock> SEJeff: it's pretty much the same for me
[08:09] <BjornT> SEJeff: yeah, we're currently working on trying to make it faster.
[08:10] <SEJeff> BjornT: Sure. Writing code is always the easy part. Debugging / Optimizing is always the hard part
[08:10] <LaserJock> for me LP works best when URL driven
[08:10] <SEJeff> BjornT: Do you develop lp? If so I have a question
[08:10] <LaserJock> so maybe I don't notice the speed
[08:11] <BjornT> yeah. and the thing is, the speed problem isn't a problem with the code, it's mostly a problem that several small files need to be fetched by the browser for each page over ssl (which means that most browser won't cache the files)
[08:12] <BjornT> SEJeff: yeah, i'm an lp developer.
[08:12] <SEJeff> BjornT: People always gripe about lp being non OSS, but no-one ever says a word (because they are too ignorant) about Redhat Network.
[08:13] <SEJeff> Mark's grand scheme seems to be towards Ubuntu / Canonical sustaining itsself
[08:13] <SEJeff> Is lp, or some restricted feature of it, your equivalent of RHN
[08:13] <SEJeff> As in value added features to customers such as management, inventory, etc
[08:15] <BjornT> SEJeff: well, we do intend to release lp as open source one day, but it will probably take a while, and it will probably be done in steps, so that we release one bit at a time.
[08:16] <SEJeff> BjornT: Really!?
[08:16] <LaserJock> seems more like seperate project rather than value added
[08:16] <SEJeff> lp seems like it could actually give Canonical an edge in smoe areas
[08:16] <LaserJock> SEJeff: yes, Mark said that from the beginning I think
[08:16] <SEJeff> being a "meta-bts"
[08:17] <SEJeff> Of course it is his choice, but why keep it closed at all then? Surely the code isn't that ugly
[08:17] <BjornT> SEJeff: yeah, it's even in the faq: https://launchpad.net/faq
[08:17] <LaserJock> part of it, IMO, is that we really don't want a bunch of Launchpads floating around
[08:17] <LaserJock> the idea was to pull together projects
[08:18] <LaserJock> so many distros and software projects use Launchpad
[08:18] <SEJeff> LaserJock: That will always happen in OSS unless the project has a clear direction and encourages participation. Inkscape is a perfect example of fostering a community
[08:18] <SEJeff> But you guys have people like Jono working for you. He knows much more about communities than I do
[08:19] <LaserJock> right, but we are seeing it already, some of it might be because LP isn't OSS
[08:19] <BjornT> yeah, LaserJock is right. the main reason at this time is that we don't other launchpad's popping up, since it's designed so that everything should be in the same database.
[08:21] <SEJeff> Fair enough
[08:21] <SEJeff> You should poke mark into saying that directly so the free software nazis will stop complaining
[08:22] <SEJeff> Because that is perfectly valid
[08:22] <LaserJock> BjornT: are there any plans on making +filebug-advanced more ... advanced?
[08:27] <BjornT> LaserJock: no specific plans atm, but i do agree that it should be more "advanced", otherwise it's not much different from the normal filebug page. what would you like to see on it?
[08:28] <BjornT> it might be that we get rid of that page eventuall, and integrate it into the normal filebug page
[08:29] <LaserJock> BjornT: well, Version: would certainly be one that'd probably get used
[08:29] <SEJeff> BjornT: LaserJock Thanks for answering my questions
[08:29] <LaserJock> certainly ... probably
[08:30] <LaserJock> I need to stop redoing my sentence half way through
[08:30] <LaserJock> SEJeff: np
[08:30] <LaserJock> BjornT: perhaps being able to subscribe or assignee directly from there
[08:31] <LaserJock> BjornT: perhaps Release: but that might not be as helpful as Version:
[08:32] <LaserJock> BjornT: mostly I'd love to see package-specific text when filing a bug. I've seen a few bugs floating around for that
[08:33] <LaserJock> but that'd probably be more appropriate for the simple +filebug
[08:34] <BjornT> yeah, the package specific text should be on the normal +filebug page.
[08:34] <LaserJock> oh, another one could be which binary package
[08:35] <LaserJock> for source package that produce quite a few binaries sometimes it's not obvious which one the user is talking about
[08:35] <LaserJock> but that might be confusing if you have to put in source package then binary package
[08:36] <Ubugtu> New bug: #89392 in launchpad "+addpackage form makes no sense" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89392
[08:36] <BjornT> LaserJock: yeah. we used to fields for both binary and source package, but we ended up removing the binary one to make things simpler to understand.
[08:36] <LaserJock> how is that handled now? if a person puts in a binary package (when binary package != source package) does it automatically find the source package?
[08:36] <BjornT> LaserJock: yeah. and the entered binary package gets added to the description.
[08:36] <LaserJock> yeah, I think I remember that
[08:37] <LaserJock> oh sure
[08:38] <LaserJock> ok, then scratch that suggestion
[08:39] <LaserJock> BjornT: what about being able to add and attachment from there?
[08:39] <LaserJock> *an
[08:40] <BjornT> LaserJock: yes, that's planned. but it will be possible to add an attachment also from the simple +filebug.
[08:41] <LaserJock> well, hmm
[08:42] <LaserJock> it would seem like you could indeed fold them together and then have an "Advanced" drop-down for a few "extras"
[08:44] <BjornT> yeah, i think that would be better actually.
[08:51] <Ubugtu> New bug: #30856 in malone "would like to be able to add attachment(s) while filing the bug" [Medium,Confirmed]  https://launchpad.net/bugs/30856
[09:56] <sabdfl> Lutin: that's a different group
[04:21] <Ubugtu> New bug: #89476 in malone "busted permissions: cannot unsubscribe ubuntu-security when private" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89476
[04:30] <lbm> any lp admins online?
[05:22] <kiko> lbm, yeah?
[05:33] <lbm> kiko: let me pm you
[08:40] <Rinchen> ping danilos
[08:40] <Rinchen> or Ping Kiko
[08:43] <Rinchen> if either of you happen to be working, I've been looking at a translate issue with a package.  The reporter is working with the maintainer but the assigned to (etc) needs some loving.  82506 and 75337
[08:43] <Rinchen> Not sure myself how best to set it.  Thanks.
[08:44] <Rinchen> maintainer says it's an upstream issue. yippee
[11:30] <pochu> heya effie_jayx :)
[11:30] <effie_jayx> hey :D


[16:52] <OvenWerks> Eickmeyer: https://www.mattlayman.com/blog/2015/i18n/
[16:53] <OvenWerks> I would suggest we try installer first... oh, maybe not, thats not python.
[20:01] <Eickmeyer> OvenWerks: I know the idea was to eventually convert installer to python, but that would obviously have to happen first.
[20:06] <OvenWerks> I was looking at the example in the link above... it looks pretty complex.
[20:07] <OvenWerks> Also, it doesn't say anything about dealing with a *glade file
[20:08] <Eickmeyer> If I knew anything about Python I'd probably form an opinion. :/
[20:09] <Eickmeyer> My knowledge is rather limited to C64 BASIC and bash scripts. :P
[20:13] <OvenWerks> It seems we are supposed to have (already) /usr/bin/application /usr/lib/app-name/libs.py /usr/lib/app-name/locale/lang/*.po
[20:14] <OvenWerks> though I have also seen them in /usr/share/app-name/locale
[20:16] <OvenWerks> The problem is that from my limited understanding so far, the only way I could figure this out would be to not add any text in the glade file but add it after (which would double the work and size of our executable)
[20:17] <OvenWerks> I am sure there is a better way :)
[20:32] <OvenWerks> The outcome is that I am not ready to do translations at this point. It looks like translation would be about the same amount of work I have already done over again. I hope I am exagerating :P
[20:43] <Eickmeyer> That's fine. I will pass the word.
[23:11] <OvenWerks> and then I fell asleep... maybe that is why I was grouchy