[05:34] moin === smb` is now known as smb [07:20] * smb moans [07:21] infinity, ...and no Xen sponsoring still... while I am in the right mood === fmasi_afk is now known as fmasi [08:14] * smb gets more tea... === ghostcube_ is now known as ghostcube [09:18] jodh, Are you around? Just wondered how your are doing with the autopkgtest. Sorry I ded not get back earlier. [09:20] smb: not currently working on it. Had to move on to other things. Once I've finished the next upstart upload will start looking at it again. [09:22] jodh, Ah ok. So probably more for reference, right now it looks like having any first level (the one provisioning) on a 64bit userspace Raring [09:22] is the more stable combination [09:22] (is that 64bit containing 64bit containing any bits) [09:23] apw: Moshi moshi? [09:23] smb: do we know yet what is causing the instability in saucy though? aiui, in the jenkins env, we'll have host=precise, and then 2 saucy vms. [09:23] Good morning! [09:23] I can only guess about canonistack, but I would believe hosts are 64bit (cpu+user-space) Precise [09:24] And then run a 64bit (cpu is given) user-space raring in that [09:26] jodh, one suggestion to try (to get you working) would [09:26] jodh, I think some of it seems in a subtle way something that happened between R and S (but that is 3 kernel versions) [09:26] be to remove kvm in your second level, so you use straight qemu for third [09:27] so you can at least get the method working [09:28] apw, You mean do not -enable-kvm and run non-accelerated emultation [09:28] indeed i mean that :) [09:43] ls [09:55] not found --- stale file handle === ghostcube_ is now known as ghostcube === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi [13:05] * henrix -> lunch === dduffey_afk is now known as dduffey [13:42] ppisati, are ti-omap4 sru kernels on your todo list? [14:09] bjf: yep [14:52] ** [14:52] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [14:52] ** [14:58] jsalisbury, Are you sure? [14:59] With vUDS going on [14:59] smb, hmm, right. maybe we should cancel [15:00] Yeah, I suppose most of us won't be able to pay much attention. Just had not the brains to realize this overload yesterday [15:01] smb, yeah, just checked with rtg and we'll probably cancel [15:04] ** [15:04] ** CANCELLED - Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - Next meeting is Sept 3rd [15:04] ** === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues September 3rd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [16:27] Not sure if this is a known bug. But when building a linux-lts-{raring,quantal} package in a PPA the linux-tools-common binary package doesn't seem to get built [16:27] apw: rtg bjf ^^^ not sure if there is already a bug for this [16:27] arges, its not a bug [16:28] ... yet? [16:28] right it should be using the common one for that release [16:28] ie the one from the archive [16:28] for example [16:28] https://launchpad.net/~canonical-kernel-team/+archive/ppa/+sourcepub/3442339/+listing-archive-extra [16:28] why does this not contain linux-tools-common [16:28] while [16:29] this one does: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+sourcepub/3440251/+listing-archive-extra [16:29] arges, i would expect the main release to generate one, and the backports not [16:30] else they would clash [16:30] and they only contain manuals and jump scripts [16:30] apw: but doesn't linux-tools-$version dep on linux-tools-common of the same version? [16:30] arges, no [16:31] so you get the latest one from the main kernel, which is not perfect, but close enough for our purposes === fmasi is now known as fmasi_afk [18:36] sforshee, i'm kinda blocked on bug 1195803, any ideas on this? [18:36] Launchpad bug 1195803 in powerd "powerd on phablet not reliably picking up screen timeout and dim settings" [Undecided,New] https://launchpad.net/bugs/1195803 [18:36] cking: no ideas -- I don't really know the gsettings stuff, but any time I tried to reproduce the problem it worked fine for me [18:37] sforshee, nice that it works for you, i'm ssh'd into the device, how did you try to reproduce? [18:37] cking: I also haven't been in a big hurry to fix it as ultimately unity is supposed to handle the timeout, not powerd [18:37] cking: run the gsettings command to modify the value and restart powerd [18:38] cking: I was probably using adb, but I can't imagine why that would make a difference [18:38] sforshee, as phablet user or root? [18:38] root [18:38] are you using sudo? [18:38] I _would_ expect that the command needs to be run as root [18:39] sforshee, sudo dbus-launch gsettings set com.canonical.powerd activity-timeout 20 ; sudo dbus-launch gsettings set com.canonical.powerd dim-timeout 10; sudo initctl restart powerd [18:40] cking: and that fails? [18:40] sforshee, all the time [18:40] i'm now blocked on this on my power testing :-( [18:41] cking: any reason why you change the screen timeout instead of using powerd-cli to keep the screen on? [18:42] sforshee, because that's the magic I was told to use a while ago ... what's the powerd-cli way of doing it? the documentation is sketchy [18:42] powerd-cli display on [18:43] if you want the screen to stay at full brightness you also need to append 'bright' [18:43] cking: the documentation printed by 'powerd-cli help' should always be up-do-date [18:43] sforshee, ah, I was looking for a man page ;-) [18:44] * kamal points finger at cking and giggles [18:44] cking: I have to guess that the gsettings problem has to do with something in the environment when run as sudo, but I don't know what that would be [18:44] "a man page" . . . hahahaha [18:45] kamal: better than that info crap :-P [18:45] sforshee, agreed :-) [18:47] sforshee, so it asmes me to press ctrl-c to exit, how do I avoid that? [18:48] *askes me [18:49] cking: you can't, if powerd-cli terminates then powerd automatically releases its requests [18:49] cking: you can background it then send it SIGINT I suppose [18:50] sforshee, ok, I'll go down that route [18:50] cking: I know it's a bit of a pain, but better than letting crashy software kill your battery ;-) [18:51] sforshee, it's not too bad, I just need to re-work my tests, but that OK since I abstracted all this out so its easy to figure out [18:56] sforshee, the help states: "The first argument represents the state of the display.. On, Off, or Don't Care (dc).". powerd-cli display on and powerd-cli display dc work fine,. powerd-cli display off doesn't work [18:57] cking: d'oh. Off has never been an option. [18:57] sforshee, so the help is misleading just like the non-existent man page ;-) [18:57] cking: more misleading. At least the missing man page doesn't make claims that don't work ;-) [18:58] * cking needs to grok the source methinks [18:58] ..and then write a man page ;-) [18:58] cking: beware, the powerd-cli source is pretty ugly right now [18:59] I want to improve it, just haven't had time [19:28] My machine locks up solid on a fairly regular basis - Ubuntu 13.10 and up-to-date, unresponsive to keypresses, and not listening to the network. I think this might be a kernel thing because once I happened to be on a virtual console when it happened and got a bunch of lines saying "BUG: soft lockup - CPU#n stuck for 23s! [some-process:12345]" (with n in 0, 1, 2, 3). I don't know how to further diagnose, because [19:28] it's locked up -- I have to powercycle to get the machine back, by which time logs and so on are gone, so I don't know how to file a bug about it. What should I do? [19:45] * rtg -> EOD [20:43] aquarius: I had a hard lockup exactly once last week (for the first time in a very, very long time). Sadly, I got nothing useful to debug out of it. [20:44] aquarius: Not that this helps you any, but maybe you can enjoy a feeling of solidarity. [20:44] infinity, yeah. If it happened once, I'd shrug, which is exactly what I did do when it happened the first time. However, it's now happening a few times a day. And I am not quite wealthy enough to just say "probably a hardware fault" and throw my laptop in a bin and buy a new one :) [20:45] aquarius: Well, I've only had the once, so my data's useless to you. Your laptop's probably still at fault. :P [20:46] I feel consoled. :) [20:46] aquarius: If my frequency kicks up, I'm sure I'll notice. [20:46] aquarius: What sort of laptop? [20:46] Lenovo ultrabook, about 18 months old [20:47] Sandy, Ivy? [20:47] sandy. Ivy wasn't out when this was released, I don't think :) [20:47] Kay. So similar vintage to mine. [20:48] If I see it again, we'll have to come up with some way to compare notes and dig deeper. Could be something sandy specific. [20:48] what worries me is that the "hey! spend money on a new laptop!" demon is seeing this and salivating. [20:48] Like every other bug with this bastard stepchild of a silicon revision. :/ [20:48] aquarius: That demon's been nipping at my heals ever since a week after I bought this laptop and they released the Ivy replacement. [20:49] there are many hits for the error, but they all seem related to virtualisation stuff, I think [20:49] heels* [20:49] * aquarius laughs. My demon was born when Jono Lange bought the same laptop but in this cool burnt orange colour rather than the plain metal that mine is :) [20:51] aquarius: Fanboy. [20:51] it's not *quite* Ubuntu orange, but I was still impressed :) [20:52] the idea of being able to run Ubuntu on kit that looks nice, rather than kit that looks like it should be on blocks in front of someone's trailer, is still quite new to me as a concept ;) [20:53] Well, talk to me when I can get a laptop in Hoary brown. [20:53] None of this orange and purple nonsense. [20:53] Vive la brun! [21:52] infinity: ++ === dduffey is now known as dduffey_afk