[04:27] <pitti> Good morning
[05:02] <pitti> ScottK: thanks :) at least I can now say that only half of my raring FFEs were controversial :)
[08:09] <dholbach> good morning
[08:09] <kris-away> mornin pardner
[08:52] <aquarius> erm. Doing a dist-upgrade today, and basically all the packages that it wants to install can't be authenticated. Did the archive key change or something and I didn't update?
[08:54] <aquarius> (am on raring. these are not coming from a ppa: apt-cache policy shows the new version of packages (such as compiz-plugins-main) are from raring/universe)
[08:54] <kris-away> You've been hekked boy.
[09:00] <cjwatson> aquarius: any errors from apt-get update?
[09:00] <cjwatson> aquarius: (if not, try the dist-upgrade again)
[09:01] <aquarius> ha!
[09:01] <aquarius> there were, and I didn't notice. I got the "something wicked" error when resolving security.ubuntu. Re-updated and now all is fine.
[09:01] <aquarius> On the other hand...that's a bit weird.
[09:02] <cjwatson> Some kind of temporary resolver failure, perhaps
[09:02] <cjwatson> Did it give any specifics?
[09:02] <cjwatson>             return _error->Error(_("Something wicked happened resolving '%s:%s' (%i - %s)"),
[09:02] <cjwatson>                                  Host.c_str(),ServStr,Res,gai_strerror(Res));
[09:03] <cjwatson> kris-away: FWIW: that can be the case but it isn't necessarily helpful to leap to it first
[09:07] <aquarius> cjwatson,   Something wicked happened resolving 'security.ubuntu.com:http' (-11 - System error), unhelpfully. :)
[09:07] <aquarius> I assume my string-and-chewing-gum LAN decided to throw some sort of a benny.
[09:07] <cjwatson> Hm.  I should make apt print strerror(errno) in that case.
[09:08] <aquarius> anyway, we're good now, I think
[09:08] <aquarius> mildly weird that it caused a key verify error, though. I mean, key verify errors are "colour the screen in red and print 'something is very wrong'" level :)
[09:09] <cjwatson> I suspect that the error was in retrieving an intermediate step in the chain from the host
[09:09] <aquarius> k, restarting to enjoy the new loveliness :)
[09:44] <jamespage> anyone got any ideas on where this build is stalled?
[09:44] <jamespage> https://launchpad.net/ubuntu/+source/glance/1:2013.1~rc1-0ubuntu1/+build/4384118
[09:46] <jamespage> that appears to be right at the end of the package build process; but I can repro locally...
[09:46] <jamespage> can't rather
[09:47] <ogra_> lool, hmm
[09:48] <ckpringle> ps
[09:48] <ogra_> lool, are you sure its a clever idea to make the sdk packages recommends (optional) instead of hooking them in with a hard dep ? i fear we will end up with ton of bugs where the sdk misbehaves
[09:51] <cjwatson> jamespage: there was chatter on #launchpad-ops overnight about buildd-manager taking mysteriously long to download build results
[09:52] <cjwatson> mind you, I'm not sure that's what's up here
[09:53]  * cjwatson peers
[09:53] <jamespage> cjwatson, hmm - well I can repro locally but that package is also doing something similar in the openstack CI lab
[09:53] <jamespage> dpkg-buildpackage: binary only upload (no source included)
[09:53] <jamespage> Build killed with signal TERM after 150 minutes of inactivity
[09:53] <cjwatson> nothing relevant in buildd-manager logs
[09:53] <cjwatson> so I think it's before it starts trying to reap the build
[09:55] <jamespage> cjwatson, would a process hanging around from test suite execution cause this sort of thing?
[09:55] <cjwatson> let me check
[09:55] <cjwatson> that's the last thing dpkg-buildpackage does
[09:56]  * dholbach relocates to Laney's
[09:56] <Laney> party time
[09:57] <cjwatson> Right, so yes, it's quite possible - in particular, a process that didn't disconnect from dpkg-buildpackage's stdout
[09:57] <cjwatson> It's just the usual pipe semantics
[09:57] <jamespage> cjwatson, OK _ lemme dig again - I actually skipped the tests when trying to repro locally
[09:57] <jamespage> but the lab runs them in full
[09:57] <cjwatson> Reading from a pipe will block as long as there's a process with the other end of the pipe open for writing
[09:58] <jamespage> it started happening in the lab with https://github.com/openstack/glance/commit/9a01d5389ac3235279f75256815e23e49ebc0c6a
[09:58] <cjwatson> And sbuild reads from dpkg-buildpackage's output until it gets EOF
[09:59] <cjwatson> This is launchpad-buildd's sbuild, but the relevant part of modern sbuild is structurally similar enough that it should do the same thing
[10:09] <jamespage> cjwatson, "python setup.py test" was hanging around
[10:09] <cjwatson> Right
[10:09]  * jamespage pokes that a bit more
[10:11] <lool> ogra_: No, I don't like the recommends either; note that they are only for optional plugins apparently, but I intended to bring that up indeed
[10:12] <lool> ogra_: these were introduced between .136 and .137 and I hadn't noticed this in -proposed, so I copied them wholesale (like the rest), but would rather we convert them to depends
[10:12] <ogra_> ah, i didnt know they were optional ... i just see that even today people moan about missing plugins
[10:12] <ogra_> (or qt-creator does and they report it)
[10:12] <ogra_> yeah ... depends++
[10:16] <vibhav> britney is responsible for handling debian->ubuntu package copying, right?
[10:17] <cjwatson> No
[10:17] <vibhav> ah wait, britney is for the autopkgtest things
[10:17] <cjwatson> Still no
[10:17] <cjwatson> britney is the name of the tool that drives the proposed-migration process, so copies from raring-proposed to raring when conditions are sufficient
[10:18] <cjwatson> It will be hooked up to autopkgtest as well but isn't yet
[10:18] <vibhav> cjwatson: conditions as in?
[10:18]  * vibhav always thought certain tests included autopkgtests
[10:18] <cjwatson> vibhav: https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036043.html
[10:20] <cjwatson> As for Debian->Ubuntu copies, if you mean the mass sync process that happens between archive opening and Debian import freeze, that's https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/auto-sync
[10:21] <vibhav> cjwatson: So britney is reposible for unstable->testing, while a modified version of britney in ubuntu is used for raring-proposed->raring?
[10:21] <cjwatson> Correct
[10:22] <cjwatson> On the whole I prefer not to call it britney, because I don't particularly like the "famous women's names for archive tools" naming scheme
[10:23] <cjwatson> But that's fairly unambiguously the name for it in Debian testing, at least
[10:23] <vibhav> heh
[10:23] <vibhav> I never realized that anyway
[10:24] <vibhav> cjwatson: thanks
[10:24] <cjwatson> np
[10:32] <cjwatson> aquarius: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703603
[10:41] <jamespage> cjwatson: will that build ever time out? if not who do I request to kill it...
[10:43] <cjwatson> jamespage: It's meant to time out after IIRC 150 minutes of inactivity.  Failing that, #webops on internal IRC
[10:44] <jamespage> cjwatson, ack
[10:47] <aquarius> cjwatson, cool, thank you
[11:09] <cousteau> texlive-latex-extra installed.  Tried to make a pdf using the moderncv class; I got this error: http://tex.stackexchange.com/questions/4264/latex-error-file-marvosym-sty-not-found
[11:10] <cousteau> installing texlive-fonts-recommended fixed the problem.  Shouldn't this have been installed by default when installing texlive-latex-extra since it's needed for the moderncv class?
[11:44] <zyga> roadmr: 5162
[11:44] <roadmr> zyga: wow that's a lot
[11:44] <zyga> roadmr: wrong place :)
[11:44] <roadmr> zyga: haha
[11:57] <tvoss> mpt, ping
[11:57] <tvoss> mpt, do you want to sync up? I have nothing urgent
[11:58] <mpt> tvoss, nothing from me.
[11:59] <tvoss> mpt, ack
[12:03] <mitya57> jamespage: hi, any chance you can look at bug 1157421?
[12:03] <mitya57> looks like we only need to backport https://github.com/mcclurmc/blktap-dkms/commit/d33302b91d
[12:04] <jamespage> hey mitya57
[12:04] <jamespage> gah - more kernel 3.5 fallout
[12:05] <mitya57> yeah, it breaks a lot
[12:06] <jamespage> mitya57, is that commit backwards compat with 3.2 as well?
[12:06] <mitya57> I'm not sure, that's why I asked you :)
[12:13] <mitya57> jamespage: looks like no :(
[12:13] <mitya57> I can find vm_mmap definition in http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=blob;f=include/linux/mm.h
[12:13] <mitya57> but can't in http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=blob;f=include/linux/mm.h
[12:14] <jamespage> mitya57, OK _ so can you make a patch that is conditional on kernel version?
[12:14] <jamespage> that would make life easier
[12:14] <jamespage> (doing it with dkms compat patches is a real headache imho)
[12:15] <mitya57> jamespage: maybe later today (but I really didn't want to do that myself :P)
[12:28] <caribou> seb128: ping
[12:28] <seb128> caribou, howdy
[12:28] <caribou> seb128: hope you're doing fine.
[12:29] <seb128> caribou, I am, thanks! you?
[12:29] <caribou> seb128: Fine, thanks. I got some issue with the rsyslog corruption bug SRU
[12:29] <seb128> oh?
[12:29] <caribou> https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1059592
[12:30] <caribou> seb128: the bug is hard to reproduce, so the SRU fix is difficult to confirm
[12:30] <caribou> seb128: I've been running the unfixed one in loops all morning and didn't see any corruption
[12:30] <caribou> seb128: even with proposed templates in the upstream bug report
[12:31] <seb128> caribou, in those cases it's usually fine to stress test the new version and confirm it stills work without regression
[12:31] <seb128> caribou, if the bug is not really fixed that's still ok, as long as we are sure we don't break anything
[12:31] <seb128> caribou, so just stress test the new version and if it's fine add a comment saying so in the bug
[12:31] <caribou> seb128: ok, I can do that. I looked at arges's merge and it only replaces Unlock by Locks in a few places
[12:32] <caribou> seb128: fine, I'll do that & report in the bug. I'd hate to see arges's work lost
[12:32] <caribou> seb128: thanks
[12:32] <arges> caribou: thanks again for the help.
[12:33] <seb128> caribou, thanks for the efforts! yeah, me too, it's annoying when we go through all the process, have people working on a fix, sponsors review/uploading, SRU team getting it in ... to then fail to verify and loose all the work
[12:33] <caribou> arges: np. I got another rsyslog bug on my plate anyway
[13:13] <jibel> dobey, hey, could you have a look at bug 1158290 ?
[13:51] <dobey> jibel: failing where? version.py is a generated file (generated by setup.py build)
[13:53] <jibel> dobey, autopkgtest https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-software-center/117/ARCH=amd64,label=adt/artifact/results/dsc0t-run-tests-stdout
[14:24] <esing> Hi
[14:24] <esing> Why does Ubuntu change the volume control not automatically when setting a new default audio device?
[14:32] <Laney> @pilot in
[14:32] <Laney> zoom zoom
[14:34] <seb128> Laney, happy piloting!
[14:36] <Laney> :-)
[14:36] <Laney> directhex: so you're hoping I'll SRU this patch to Q, yes?
[14:38] <directhex> Laney, sorta!
[14:38] <directhex> Laney, would be nice if my mail client didn't keep crashing whilst i'm testing our groupware install
[14:39] <Laney> aye aye
[14:39] <Laney> cyphermox: how goes the 3.6.4 update?
[14:40] <cyphermox> I couldn't get back to it yet
[14:40] <cyphermox> like i said before, evo-data-server is done
[14:40] <cyphermox> evolution not so much
[14:41] <seb128> just upload the one that's ready to start ;-)
[14:41] <cyphermox> but it's really just because I had to put it aside, and the importer couldn't make it a bzr branch either :/
[14:41] <cyphermox> sure ;)
[14:41] <Laney> I'll backport the patch but it might also be an option to upload .4 to Q under the MRE
[14:41] <cyphermox> bad habit... I usually try to upload both evo and eds together
[14:42] <cyphermox> Laney: MRE is probably simpler... there's quite a few bug fixes
[14:42] <seb128> Laney, I wouldn't spend too much time on Q at this point
[14:42] <seb128> so depends how easy is the update to do/test
[14:42] <Laney> indeed
[14:42] <Laney> the backport should be easy enough
[14:50] <stgraber> jodh: thanks for updating gnome-session! I was just done testing my own implementation when I applied some updates here and saw you did it already ;)
[14:50]  * dholbach hugs Laney
[14:53] <cyphermox> Laney: as soon as it comes out of sbuild I'm uploading
[14:53] <Laney> you beast
[14:53] <Laney> you mean the SRU or Raring or both?
[14:54] <cyphermox> for raring
[14:54] <Laney> nod
[14:54] <cyphermox> I can fix that up for quantal too
[14:54] <Laney> ok, it's bug #1158018
[14:55] <Laney> slow bot is slow
[14:55] <cyphermox> my system is kind of slow too
[14:55] <cyphermox> I guess copying the entire aosp tree + our android tree takes a bit of juice from my disk :/
[14:57] <cyphermox> I'm going to need to add another entry to changelog, I didn't catch this bug since it was filed 15 hours ago
[15:00] <Laney> argh
[15:00] <Laney> evolution broke my maildirs
[15:00] <cyphermox> huh
[15:00]  * Laney glares at directhex
[15:00] <cyphermox> oh, this is fixed in evolution, not eds
[15:01] <cyphermox> Laney broke how?
[15:01] <Laney> seems to have deleted all the mail in them
[15:02] <cyphermox> bad evolution, bad!
[15:02]  * Laney resyncs
[15:04] <cyphermox> Laney: uploaded eds to raring
[15:04] <cyphermox> should I be holding off for quantal?
[15:05] <Laney> feel free if you think all the changes between .3 and .4 are ok
[15:05] <cyphermox> it's all bugfix
[15:05] <Laney> go for it
[15:05] <cyphermox> hmm
[15:07] <Laney> you'll want to file some SRU bug and say that it goes in under the GNOME MRE so testing each specific bug isn't required
[15:10] <cyphermox> yeah
[15:11] <Laney> GunnarHj: what's left to do on https://bugs.launchpad.net/lightdm/+bug/952185 openssh?
[15:14] <GunnarHj> Laney: Uploading the patch.
[15:15] <gema_> awe_: can you give me the link to all the BPs that cover the wifi/networking work?
[15:17] <Laney> cjwatson: ^ maybe you could look at the openssh patch there
[15:18] <gema_> lool: or maybe yourself, wifi/networking ongoing BPs?
[15:18] <cjwatson> Laney: yes, it's already on my to-do list
[15:18] <Laney> ok
[15:18] <Laney> I'll remove from the queue then
[15:18] <cjwatson> I'll get it done before raring
[15:19]  * Laney nod
[15:21] <jodh> stgraber: thanks - I didn't upload though :)
[15:21] <stgraber> jodh: someone did :)
[15:21] <Laney> le RAOF
[15:29] <jodh> following on from a discussion on #upstart-desktop, I'd like to understand the expected semantics of apport hooks that have to handle potentially sensitive files. For ProblemType 'Bug', we should ask the user (if there is a ui), and for 'Crash' we could auto-attach any files as (a) we can't ask the user and (b) all 'Crash' bugs are private. But how best to handle sensitive files for other ProblemTypes?
[15:30] <Laney> zul: are you uploading for https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1119248 ?
[15:31] <zul> laney: its been delayed
[15:31] <Laney> yeah?
[15:31] <Laney> is it part of a regular SRU cycle or something?
[15:31] <Laney> IOW does ubuntu-sponsors need to be involved?
[15:32] <lool> gema_: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-converged-network-stack
[15:32] <awe_> gema_, that only really cover the fact that we're going to use ofono for mobile data support
[15:32] <awe_> there's no real change to how wifi works
[15:32] <gema_> awe_, lool ack
[15:32] <gema_> awe_: is there any past BP that defines how wifi works that is worth mentioning/taking into account?
[15:33] <awe_> that said, what you'll really need to work with are probably the design specs for indicators/settings
[15:33] <awe_> https://wiki.ubuntu.com/Networking
[15:33] <awe_> ^^ is a good overview of how networking is supposed to work on desktop
[15:33] <gema_> awe_: ack, do we have something similar for mobile?
[15:34] <awe_> there was a design spec published internally for touch, but AFAIK it's no longer available ( even internally w/in Canonical )
[15:34] <awe_> you probably should ask mpt or ivanka
[15:34] <lool> gema_: I was hoping aruiz would have an indicator spec to complement this -- pinged him just before his holidays last week about the WI there, but he's on leave this week, will ping again this week -- and also that we'd have a wifi testing subblueprint or at least some more detailed workitems
[15:34] <gema_> awe_: ack
[15:35] <mpt> gema_, I will be adding phone stuff to it soon.
[15:35] <awe_> one other doc which is super preliminary is: https://wiki.ubuntu.com/SystemSettings
[15:35] <gema_> lool: yep, I am also waiting for aruiz to be back
[15:35] <awe_> there's a meeting on monday to discuss
[15:35] <gema_> mpt: ok, sounds good
[15:35] <awe_> mpt, that would be super helpful...  the sooner the better, as there some holes in the spec that touch was originally based on
[15:36] <gema_> awe_, mpt +1000
[15:36] <awe_> ( i.e. no connection info, no way to forget a network/change a password, ... )
[15:36] <mpt> I see
[15:36] <gema_> mpt: that'll pretty much drive our testing use cases
[15:36] <awe_> gema_, bingo
[15:37] <mpt> awe_, gema_: To be fair, the PC spec is riven with holes too. :-) It dates from the days when we were flirting with ConnMan, and when we returned to the arms of NM, I stopped work on it
[15:38] <gema_> mpt: then we'll have to complete it
[15:38] <mpt> yes indeed
[15:39] <mpt> awe_, gema_: aruiz is working on the PC UI
[15:40] <awe_> mpt, re: aruiz, yes... I know.  I exchanged an email with larsu about indicators and specifically networking/telephony next week.  Looks like plans are starting to shape up a bit.  I think we'll have a chance to re-sync at the settings mtg on monday
[15:40]  * Laney prods xnox to look at / upload https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/831768
[15:41] <Laney> (from #122 I gather that you reviewed the patch)
[15:43] <xnox> Laney: only briefly... be my guest to upload it =)
[15:43] <Laney> /quit
[15:59] <bdmurray> jodh: I think there are only 2 other problem types "Package" and "KernelOops".  For Package I think we should ask and for KernelOops may be a type of crash so private?  However, when we have server-side hooks setup for errors I think it'll be moot.
[15:59] <jamespage> do the launchpad builders set HOME to something sensible?
[16:00] <tkamppeter> OdyX, I have release cups-filters 1.0.31 to fix a bug and quickly uploaded it to Ubuntu (due to the FF, to get as much testing time as possible). Please merge it also back into Debian.
[16:01] <vibhav> Laney: /j #launchpad
[16:01] <vibhav> oops
[16:01] <vibhav> sorry Laney
[16:01] <Laney> I DON'T WANNA
[16:02] <vibhav> Laney: Now since I (accidently) pinged you, is it considered nice to delete a merge proposal and start afresh with a new one?
[16:02] <Laney> it loses the history
[16:02] <vibhav> https://code.launchpad.net/~vibhavp/ubuntu/raring/thoggen/fix-format-string-warning/+merge/150969
[16:03] <Laney> I'd just fix it and push some new commits
[16:03] <Laney> then set back from WIP to Pending or whatever it is in the global status
[16:03] <jodh> bdmurray: the source also mentions KernelCrash, and Hang so a non-kernel hook seems to have to handle Bug, Crash, Hang and Package.
[16:03] <mlankhorst> \
[16:04] <mlankhorst> oops
[16:05] <jodh> jamespage: see https://launchpadlibrarian.net/126054368/buildlog_ubuntu-raring-amd64.procenv_0.19-1_BUILDING.txt.gz (search for HOME=)
[16:05] <bdmurray> jodh: ah, I'd forgotten about hang - that is rather new
[16:05] <OdyX> tkamppeter: I have too much pain with bzr to be able to push it fast to Debian, but I'll do it soon, yes.
[16:05] <jamespage> jodh, interesting - that is different to a stock sbuild environment locally
[16:06] <jamespage> jodh, I can simulate that tho
[16:06] <jodh> bdmurray: have we got some doc on this or a skeleton hook maybe to handle all the scenarios?
[16:07] <bdmurray> jodh: I don't think so
[16:07] <jono> hey didrocks - testing the scopes PPA - should the server be sending correct results back now?
[16:07] <jodh> jamespage: I've put links to all the environments I can get to non-locally at the top of https://launchpad.net/procenv/.
[16:07] <jono> I am finding the filtering is buggy
[16:07] <jono> wasnt sure if I should file a bug
[16:09] <didrocks> jono: not correct results
[16:09] <didrocks> jono: all scopes should start
[16:09] <didrocks> they don't have real recommendations yet
[16:09] <jamespage> jodh, weird - anyway - I updated my sbuildrc to set a HOME
[16:11] <didrocks> jono: re filters: yeah, there are not all ready yet
[16:17] <cjwatson> jamespage: it's a bug to ever rely on HOME during a build
[16:17] <cjwatson> (and yes, I think launchpad-buildd currently differs from packaged sbuild)
[16:17] <jamespage> cjwatson, I don't disagree - I was just observing different behaviour between sbuild and launchpad buildd
[16:17] <cjwatson> jamespage: the intent is to upgrade launchpad-buildd to modern packaged sbuild, but lack of time
[16:18] <jamespage> cjwatson, ack - I'll push a fix into the offending package so it does not break in future
[16:18] <cjwatson> Soyuz folks do know that there are plenty of differences :)
[16:18] <cjwatson> At least some Debian buildds will be running with something much more recent
[16:49] <cjwatson> plars: https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1162 - with any luck this will turn out not to be total doom
[16:49] <seb128> jodh, stgraber: hey, do you have any spec you are using for the upstart work scheduled for post raring? is the gsettings bridge on there?
[16:50] <seb128> jodh, stgraber: I was pondering opening a client spec of "make use of session jobs" ... does that make sense or is there an existing spec that matches that?
[16:50] <seb128> Laney, ^ fyi
[16:50] <stgraber> seb128: I don't think we have a spec specifically for using the features we implemented, so I guess that'd be good to have
[16:51] <stgraber> seb128: the gsettings/dconf bridge currently isn't upstream but jodh asked me to poke at it again and it may make the next release still
[16:51] <seb128> stgraber, ok, good, do you need help from our side to figure where to plug/listen for dconf/gsettings changes?
[16:51] <stgraber> seb128: it was difficult to test before as we didn't have the user sessions but now that we do, it should be fairly easy to get my code into good enough shape that it can get in upstart and people can start using it
[16:52] <stgraber> seb128: the current implementation simply sends even for any change happening in the dconf database, I think it's a good first step. In the future we'll want to add extra syntax so we can depend on existing keys and not only keys changing value
[16:53] <seb128> stgraber, how do you "watch for changes"? look at dbus calls?
[16:54] <stgraber> seb128: yep, my bridge connects to dbus and listens for the dconf signals
[16:54] <seb128> stgraber, ok, great, thanks
[16:55] <seb128> stgraber, I got some new ideas of things that could make use of session jobs today once we have that bridge
[16:55] <seb128> I will register the a client spec to list those ;-)
[16:55] <stgraber> so you can easily start/stop a job when a value changes. The thing you can't do at this point and will need a fair bit of work in the bridge is have a start condition that checks for a specific key to be set to a specific value
[16:59]  * cjwatson fixes up test failures from that last cdimage change, whoops
[17:01] <bdmurray> there are 2 uploads of gvs in quantal-proposed
[17:02] <bdmurray> one looks like a point release and the other is a bug fix https://errors.ubuntu.com/bucket/?id=%2Fusr%2Flib%2Fgvfs%2Fgvfsd-gphoto2%3A***%20glibc%20detected%20***%20%2Fusr%2Flib%2Fgvfs%2Fgvfsd-gphoto2%3A%20double%20free%20or%20corruption%20%28fasttop%29%3A%20ADDR%20***
[17:02] <bdmurray> with 55k reports
[17:16] <Laney> @pilot out
[17:16] <Laney> will do some more tomorrow - got distracted debugging something
[17:33] <jodh> pitti/mpt/bdmurray: Could you review my changes to https://wiki.ubuntu.com/Apport/DeveloperHowTo ? Maybe we could also add advice on how to handle interactive questions post-release?
[17:37] <mpt> jodh, as above, I don't mind interactive questions for Crash, if they're useful, just so long as Apport suppresses them post-release. Relying on individual package developers to remember those rules won't work so well.
[17:46] <dholbach> haha... https://twitter.com/politbuntu
[17:54] <mpt> jodh, pro tip for the future: for less than one line of monospace you can use backticks, e.g. `Crash`
[18:02] <mitya57> dholbach: :)
[18:21] <bdmurray> seb128: do you have an opinion on the 2 gvfs uploads in quantal-proposed?
[18:21] <seb128> bdmurray, let me have a look
[18:21] <bdmurray> thanks
[18:23] <seb128> bdmurray, reject 1.14.0-0ubuntu6.1 from Laney
[18:23] <seb128> bdmurray, the new version includes that patch (as well as other fixes)
[18:25] <bdmurray> seb128: will do thanks
[18:26] <seb128> bdmurray, thank you!
[21:36] <roadmr> hello folks, we found a bug when accessing (udevadm --walk) /sys/devices/tegradc.0 on a nexus 7 running the phablet image, what'd be a good place/package to report this against?
[21:42] <hallyn> cjwatson: hm, when i try to install from 12.04.2 desktop livedvd with ovmf bios, i get plugininstaller.p becoming defunct
[21:52] <cjwatson> hallyn: um, dunno, would need logs I guess ...
[22:09] <hallyn> cjwatson: oh hey, 30 mins later it finished.  dunno waht it was doing...  oh, though i did kill -9 the defunct task, lessee if it reboots
[22:10] <hallyn> http://paste.ubuntu.com/5635411
[22:10] <cjwatson> err - yeah, that's not so informative
[22:11] <cjwatson> anything in syslog?
[22:13] <hallyn> hm, no
[22:14] <hallyn> well i can do a fresh install tonight and note what time the defunct process was hanging and look through /var/log
[22:17]  * hallyn back later 
[22:55] <cjwatson> plars: so, I think I'm pretty much there now - I just need to bug IS a bit more re firewall holes, but the SSH trigger is in place aside from that.  Do you think we can get together tomorrow and deploy this?