[04:43] <pitti> Good morning
[05:50] <tvoss_> pitti, ping
[05:50] <pitti> hey tvoss_
[07:00] <dholbach> good morning
[08:55] <darkxst> slangasek, you are patch piloting today?
[08:58] <Laney> I doubt
[08:58] <Laney> he'll be around for several hours yet
[08:59] <darkxst> Laney, oh right, I still cant work out all the timezones ;)
[08:59] <Laney> I just type "Time in XXX" into google :P
[09:01] <xnox> I have a few locations in my datetime indicator: a couple across usa, utc, a couple in europe and beijing. =) and steve is west coast.
[09:05] <xnox> What is the standard location: http://ports.ubuntu.com/ubuntu-ports/ or http://ports.ubuntu.com/ ? they seemed to be the same...?
[09:06] <cjwatson> d-i prefers the former
[09:07] <xnox> ok, thanks.
[12:23] <hyperair> pitti: hid-generic 0005:045E:0762.0019: input,hidraw3: BLUETOOTH HID v0.13 Keyboard [Microsoft Bluetooth Mobile Keyboard 6000 <-- this keyboard has nothing in /sys/class/power_supply/ and nothing in upower --dump
[12:24] <pitti> hyperair: ah, too bad; thanks anyway! I got three responses for the sysfs dump now, should be enough to construct a test case
[12:25] <hyperair> :)
[12:25] <hyperair> okay good
[13:12] <doko> kees, hardening defaults ping
[13:18] <pitti> FourDollars: hey, still here?
[13:24] <pitti> FourDollars: I'm afraid I need some more data for bug 1153488, I followed up there with a question
[14:00] <FourDollars> pitti: ack
[14:01] <pitti> FourDollars: I only became aware that you determine mouse vs. keyboard from the "bluetooth" parent device, and the dumps didn't include those
[14:02] <FourDollars> pitti: Yes.
[14:02] <FourDollars> I will collect the data for you. Wait a minute.
[14:03] <pitti> FourDollars: no hurry; thanks!
[14:05] <Ampelbein> Hmm: "internal compiler error: Segmentation fault" on armhf and powerpc in the same source file. But not on amd64/i386. Who to contact to get this investigated?
[14:06] <xnox> Ampelbein: usually you should have pre-processed source file available and together with it you can file a bug against e.g. gcc-4.8
[14:06] <xnox> Ampelbein: without pre-processed source file there is little to get investigated. Do you have it?
[14:06] <Ampelbein> xnox: But I have neither armhf and powerpc.
[14:07] <xnox> Ampelbein: so where did you get the failure?
[14:07] <Ampelbein> xnox: This happens on the build-servers (https://launchpad.net/ubuntu/+source/mrpt/1:1.0.2-1/)
[14:08] <Ampelbein> So I would need someone (from canonical?) to copy the preprocessed source out of the build-chroot?
[14:08] <xnox> Ampelbein: it's gone and destroyed.
[14:10] <Ampelbein> Hmm, ok.
[14:10] <xnox> Ampelbein: same is happening in debian https://buildd.debian.org/status/package.php?p=mrpt thus a FTBFS bug can be filed there as well. And on debian there are porters / porter boxes that a few people have access to to re-run builds.
[14:11] <FourDollars> pitti: There is no output from `grep -r . /sys/class/power_supply /sys/class/bluetooth`. Change it to `grep -r . /sys/class/power_supply/*hci* /sys/class/bluetooth/*hci*`?
[14:12] <Ampelbein> xnox: Ok, will file a bug in Debian, thank you.
[14:15] <knocte> Cimi: ping
[14:20] <pitti> FourDollars: hm, should be necessary
[14:20] <pitti> FourDollars: are you running saucy?
[14:20] <pitti> FourDollars: in that case, it might be easiest and best to install umockdev and do "umockdev-record --all > /tmp/out.txt" and attach that
[14:21] <FourDollars> pitti: no. I run Ubuntu 12.04.
[14:21] <pitti> FourDollars: this will provide a complete dump of all devices
[14:21] <pitti> FourDollars: ah, ok
[14:22] <pitti> FourDollars: ah, perhaps this:
[14:22] <pitti> grep -r . /sys/class/power_supply/* /sys/class/bluetooth/*
[14:24] <FourDollars> ok
[14:28] <FourDollars> pitti: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/1153488/comments/23
[14:30] <pitti> FourDollars: splendid, thank you!
[14:30] <FourDollars> pitti: no problem. :)
[14:47] <slangasek> darkxst_: yes, what's up?
[14:53] <JoshStrobl> fwd from #ubuntu-quality:  Would this be the right place to go if I wanted to propose a particular application be removed from USC?
[14:57] <tedg> ev, Reading your mail about high CPU usage services.
[14:57] <tedg> ev, Seems to me that we could make it opt-in.  Then "bringing it to the desktop" would be a service by service thing.
[14:57] <tedg> ev, Perhaps by adding a stanza to the upstart job config?
[14:58] <tedg> ev, Something similar to the respawn limits
[14:58] <ev> tedg: so the whitelist approach was discussed but the worry was that we wouldn't catch things like the ueventd bug
[14:58] <ev> because we couldn't anticipate them going proper mental
[14:59] <tedg> ev, The whitelist would be "everything on phone" where the set is smaller, no?  I mean we could grep for it and generate bugs.
[15:01] <ev> tedg: hm? I mean in the general sense, going with a whitelist approach on the desktop means that we'll miss whatever we don't anticipate spinning out of control
[15:01] <ev> unless I misunderstand what you're suggesting?
[15:02] <tedg> ev, Sure, on the desktop.  But I think that it's an unbounded problem to watch everything.  You don't want to kill my SETI@Home.
[15:02] <pitti> or totem or the flash plugin, etc. (this has already been discussed via mail)
[15:02]  * tedg has a prime refactorting botnet.  No reason.
[15:03] <pitti> tedg: hah, recovered your lost secret GPG key yet? :-)
[15:03] <ev> true, so whitelist rather than blacklist might be best
[15:03] <ev> tedg: would you mind following up to the ML post with this? :)
[15:03] <tedg> ev, Heh, sure.
[15:03] <pitti> would "everything that provides a D-BUS service" be a good first bite into teh whitelist?
[15:04] <tedg> pitti, No, but I have kees' so we're good, mine isn't as useful.
[15:04] <tedg> pitti, +1
[15:05] <tedg> Perhaps we could detect the case and generate a recoverable error for folks not in the whitelist.
[15:18] <hallyn_> jamespage: hey, are you around still?
[15:18] <jamespage> hallyn_, yes
[15:18] <hallyn_> jamespage: was wondernig if you'd had any thoughts on the likewise-open bug situation
[15:20] <jamespage> hallyn_, I've not look at it hard yet
[15:20] <jamespage> but I reckons there are a load of bugs that can be duped up
[15:20] <jamespage> I'm assuming that ubuntu-server was not a bug subscriber until recently right?
[15:20] <hallyn_> jamespage: ok.  I will probably take an overly broad brush and do that, and beg the reporters' forgiveness if I err.
[15:20] <hallyn_> that's my assumption too :)
[15:21] <hallyn_> all the old bug will drown out new, valid ones, so i'd like to just mark them invalid actually
[15:21] <hallyn_> and ask the reporters to respond and re-set to new if they still have the problem
[15:21] <pitti> hallyn_: you could set them to "incomplete" with "does this still happen in saucy?" and let them time out
[15:22] <jamespage> pitti, alot of them look like dist-upgrades to lucid
[15:22] <jamespage> so I'd rather not do that
[15:22] <pitti> not for those where this quetsion obviously doesn't make sense, of course :)
[15:23] <hallyn_> jamespage: so if a dist-upgrade to lucid failed on likewise-open, is it fair to assume that the reporter must've gotten past it by now?
[15:23] <hallyn_> i.e. mark invalid and ask to re-open?
[15:23] <hallyn_> any which were not dis-tupgrades, set to incomplete?
[15:23] <jamespage> sounds reasonable
[15:24]  * jamespage worries about the state of likewise-open in distro
[15:24] <jamespage> it does not get much love anymore
[15:24] <hallyn_> pitti: thanks for the suggestion, will do that for a bunch
[15:24] <hallyn_> jamespage: yeah i've considered spending a day to try it out so i can be better able to look over it
[15:24] <hallyn_> wasn't kirkland at one point our resident expert? :)
[15:24] <jamespage> maybe - I'm not sure
[15:25] <jamespage> I'm not 100% clear why its in the supported seed
[15:25] <hallyn_> i just .. have *never* used it.
[15:25] <hallyn_> yeah
[15:25] <hallyn_> Daviey: ^ do you know how that showed up?
[15:25] <kirkland> hallyn_: jamespage: likewise?  I think that was dendrobates' doing
[15:26] <kirkland> hallyn_: jamespage: I think dendrobates, soren, or ttx might remember
[15:27]  * jamespage is slightly embarresed he had to lookup who dendrobates whas
[15:27] <jamespage> (sorry)
[15:27] <kirkland> jamespage: heh :-)
[15:27] <hallyn_> kirkland: i meant it showing up in server supported seed
[15:27] <kirkland> jamespage: hallyn_: yeah, looking at likewise-open's debian/changelog, it was dendrobates (Rick Clark) that packaged it originally;  I think he pushed the MIR as well
[15:28] <Sweetshark> no seb128 today?
[15:28] <kirkland> hallyn_: https://bugs.launchpad.net/ubuntu/+source/likewise-open/+bug/201537
[15:28] <kirkland> hallyn_: oh, that one is zul's :-)
[15:28] <jamespage> oh zul... deary me
[15:28] <ttx> kirkland: at those times, integration with AD was seen as a key feature
[15:29] <zul> what did i do now?
[15:29] <ttx> and likewise-open was basically the component that was supposed to allow us doing it
[15:29] <ttx> so it was more of a product management thing
[15:29] <kirkland> ttx: :-)
[15:29] <kirkland> ttx: so let's blame nijaba, then :-)
[15:29] <jamespage> I can see the context - thanks for clearing that up ttx
[15:29] <ttx> always blame nijaba
[15:29] <kirkland> ttx: howdy, btw!
[15:29] <ttx> howdy!
[15:42] <dendrobates> jamespage: lol
[15:42] <jamespage> dendrobates, sorry :-)
[15:43] <dendrobates> no worries
[17:39]  * kees looks forward to tedg's impersonation of him
[18:17]  * tedg does his best kees: "Oh, look, I've got a goatee and all my IP traffic is coming from Siberia"  ;-)
[18:17]  * tedg probably shouldn't quit his day-job
[18:42] <kees> tedg: hehe, A++ would be impersonated again