[03:02] <FourDollars> Hi, I have a bug. It just needs to rebuild the package to solve.
[03:02] <FourDollars> How can I do that for Ubuntu quantal?
[03:04] <FourDollars> https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1028746
[03:55] <tjaalton> hallyn: yes, the ubuntu branch
[04:07] <pitti> Good morning
[06:49] <dholbach> good morning
[07:00] <dholbach> tjaalton, happy birthday! :)
[07:01] <tjaalton> dholbach: thx :)
[07:01] <didrocks> happy birthday tjaalton ;)
[07:02] <tjaalton> didrocks: :)
[08:23] <Daviey> jtaylor: hey, did you investigate what pwlib used to be used for?
[08:38] <xnox> FourDollars: if you want a no-change rebuild, please subscribe ubuntu-sponsors to the bug.
[08:39] <FourDollars> xnox: Thank you. :)
[08:39] <xnox> FourDollars: is it just your package that needs rebuilding or a wider set of packages? everything that depends on particular versions of ibus?
[08:39] <FourDollars> xnox: Not sure.
[08:39] <FourDollars> xnox: I am only sure for ibus-chewing.
[08:40] <xnox> FourDollars: ideally we want package uninstallable if there was an api/abi bump. Or a proper transition in place for all rdeps of ibus....
[08:40] <xnox> FourDollars: that's ok.
[08:41] <FourDollars> xnox: IIRC, there is no such mechanism in Ubuntu archives. Right?
[08:41] <xnox> FourDollars: sure there is.
[08:42] <xnox> FourDollars: tick good on this page http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
[08:42] <xnox> FourDollars: or see this in progress transition http://people.canonical.com/~ubuntu-archive/transitions/gnutls28.html
[08:42] <FourDollars> xnox: Thanks for your information.
[08:43] <xnox> we also have uninstallation reports and other bits and bobs ;-)
[08:43] <cjwatson> Or just do it if it's a small number
[08:43] <FourDollars> xnox: I don't see any ibus relative under http://people.canonical.com/~ubuntu-archive/transitions/ .
[08:44] <xnox> FourDollars: either it's small, not done/setup, or ibus had incompatible changes without bumping shlib depends/soname.
[08:45] <FourDollars> OK.
[10:22] <gsedej_work> hi! I am trying ubuntu 12.10. Where is "logout", i wish to choose some other DE
[10:23] <mitya57> gsedej_work: support is in #ubuntu
[10:23] <gsedej_work> ubuntu 12.10 beta?
[10:23] <ogra_> for 12.10 i think its rather #ubuntu+1
[10:24] <gsedej_work> oh, sorry, i didn't see it in channel list
[10:24] <mitya57> well, the logout button didn't change in 12.10 :)
[10:24] <gsedej_work> sorry for bothering
[11:48] <mpt> ev, the #100 crash in 12.10 is in worldofgoo
[11:48] <ev> nice
[11:49] <mpt> The first sign of importance for giving access to independent upstreams
[11:49] <ev> yeah, we can't possibly retrace those at the moment
[11:50] <ev> but great that we're actually getting them
[11:51] <cjwatson> The number of people still installing beta-1 is a little scary
[11:51] <infinity> The number of people who install milestones more than a few days after we release them scares me. :/
[11:52] <infinity> But, I guess if you have the ISO lying around.
[11:52] <mpt> and https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1 gives no clue that beta 2 is out, that I can see
[11:52] <infinity> mpt: Why would it?
[11:52] <cjwatson> That's more understandable; it's only relatively recently that daily builds have been worth bothering with
[11:52] <infinity> mpt: Do the oneiric release notes point to precise?
[11:53] <cjwatson> mpt: Ah, now that at least is readily fixable, although the question presupposes a charming belief that users read the tech overview ...
[11:53] <mpt> infinity, why wouldn't it?
[11:53] <cjwatson> I think it's reasonable for milestone notes to point forward
[11:53] <mpt> infinity, for people who have heard that beta 1 has been released, and haven't heard that beta 2 has also
[11:53] <infinity> mpt: I'm not saying that obsolescence notes on release notes might not be a cool idea, just that we've never done it before that I know of, hence my wondering at your wondering. :)
[11:54]  * cjwatson adds a bold-face note to the top
[11:55] <infinity> cjwatson: And the alphas!
[11:55] <mpt> cjwatson, good -- is there also a checklist for "things to do when a beta/final is released" to which that step can be added?
[11:55] <cjwatson> Probably ought to but have other things to do
[11:55] <cjwatson> mpt: BetaProcess.  But I'm not bothering since I hear milestones may not be happening next cycle
[11:56]  * infinity isn't quite sure why we have one set of notes per milestone at all, rather than just a cumulative document for Q that ends up being the final notes.
[11:56] <mpt> Two eminently plausible ways to solve the problem
[11:56] <cjwatson> Wouldn't hurt to archive some more of the beta-1 images, either
[11:56] <cjwatson> I'll do that later today
[11:58] <doko> cyphermox, yubiserver ftbfs
[12:27] <doko> cjwatson, a lot of the amd64 only build failures (found now 7) seem to be caused by changed dpkg-dev behaviour. all have in common that either the install target is called in the build step, or that there are missing dependencies for the build-arch target. these build failures are not seen in unstable
[12:31] <cjwatson> well, unstable or not, they are surely bugs
[12:32] <cjwatson> I don't see any obviously-relevant changes in dpkg on either side, although I've only checked changelogs
[12:32] <cjwatson> But at this point I'd rather fix those packages than change dpkg anyway
[12:35] <doko> looking through the amd64 only ftbfs now
[12:37] <xnox> I had something like that with addons, e.g. dh_sphinxdoc -a fails
[12:38] <cjwatson> That doesn't sound related.
[12:38] <xnox> so I had to make dh_sphinxdoc call only in binary-indep
[12:38] <cjwatson> Unless DH_OPTIONS is wrong as a result of the above.
[12:39] <xnox> oh and that one was reproducible in sid, so different problem.
[12:43] <buxy> kees: Next meeting is 2012-19-15 %-)
[12:52] <smoser> cyphermox, do you think i'm way off assuming bug 1058517 and bug 1058987
[12:52] <smoser> are related
[13:07] <cyphermox> smoser: not necessarily
[13:08] <cyphermox> it looked weird too, since I could have sworn that piece of code (in NM to stop dnsmasq) used to work, and certainly didn't change significantly enough to cause this
[13:08] <smoser> and in the cloud imageswhere i see this, i have no network manager
[13:08] <smoser> but do have dbus
[13:09] <smoser> (and this was in precise)
[13:09] <cyphermox> ok
[13:09] <cyphermox> I'm still going to look at dnsmasq/NM closely to be sure
[13:09] <cyphermox> (since the reporter days they can avoid this by removing dnsmasq-base)
[13:10] <smoser> cyphermox, right. that didn't make much sense to me either.
[13:10] <smoser> i'm not even sure how i became aware of your bug.
[13:11] <cyphermox> hehe
[13:12] <cyphermox> fwiw, I don't understand because dnsmasq is reportedly no longer running, otherwise things would hang earlier and get caught by report_unkillable in sendsigs
[13:13] <cyphermox> or at the very least I should always be able to see it on all my systems
[13:14] <smoser> cyphermox, well, any thoughts you have, i'd be interested in.
[13:14] <smoser> because this is pretty serious a regression in precise
[13:14] <cyphermox> smoser: "Also, doing a fully up-to-date netinstall works fine until I install network-manager-gnome (which pulls in dnsmasq-base). That's when this bug starts to show up."
[13:14] <Laney> @pilot in
[13:14] <cyphermox> also, this is a bug in quantal, not precise
[13:14] <cyphermox> maybe it's really two different things
[13:14] <smoser> cyphermox, right.
[13:27] <mpt> Hm, the #1 crash for Ubuntu users overall right now <http://launchpad.net/bugs/821233> is from software that is unmaintained <https://answers.launchpad.net/weather-indicator/+question/209454>
[13:33] <doko> pitti, https://launchpadlibrarian.net/118057586/buildlog_ubuntu-quantal-amd64.vala-0.10_0.10.4-1ubuntu1_FAILEDTOBUILD.txt.gz
[13:34] <doko> this is the same error as for ubuntu-drivers-common ...
[13:34] <pitti> not for the same service, though; but yes, timed out while waiting for a service to get activated
[13:35] <doko> but I can't see how this connects to a swap space issue
[13:36] <pitti> swapping makes everything grind to a halt, so everythingthat does I/O (that includes d-bus service activation) just takes ages
[13:36] <pitti> or at least slow enough to trigger some race conditiosn
[13:36] <pitti> but this is amd64, not arm
[13:36] <doko> pitti: do you know it is swapping? I doubt it
[13:36] <pitti> so apparently this is a different problem
[13:37] <doko> the arm build is only 12min, so it doesn't like to be a timeout
[13:37] <cjwatson> Damn, rebootstrapping eclipse-mylyn didn't fix eclipse-egit
[13:37] <cjwatson> Wonder what's going on there
[13:37] <pitti> doko: well, it's "slowness"; I just parrot infinity when he said that since the upgrade our arm builders have to do a lot more swapping
[13:38] <doko> pitti: but here I can't see any reason for that
[13:38] <pitti> doko: right; pitti | so apparently this is a different problem
[13:40] <doko> cjwatson, I think I did address all binary-arch issues, maybe uw-imap is another one
[13:55] <Laney> infinity: would you like to take care of https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1000498 ?
[13:55] <infinity> Laney: Yeah, it's on my TODO today, since I need to re-do my SRU upload ANYWAY.
[13:55] <infinity> (Thanks, security team)
[13:55] <infinity> (I'm not bitter)
[13:56] <Laney> Pfft, security, what do we need THAT for?
[13:59] <cjwatson> jamespage: I could use help with the eclipse-egit build failure; it's not making a lot of sense to me, as those plug-ins do seem to exist.  But I'm not sure where Eclipse might be looking.
[14:01] <jamespage> cjwatson, looking now
[14:03] <jamespage> cjwatson, ergh - that looks like osgi terror - lemme see if I can dig out the DM
[14:08] <nikitis> Where can one apply for steam linux beta?
[14:09] <cjwatson> jamespage: Hmm, some dependencies were dropped between Debian and Ubuntu
[14:10] <barry> jodh: ping
[14:12] <cjwatson> jamespage: Aha, installing those missing dependencies did it.  So eclipse-mylyn has misbuilt
[14:13]  * cjwatson hopes this wasn't the result of his bootstrapping attempt
[14:13] <jamespage> cjwatson, not sure I understand - I would suspect some sort of odd bootstrap sequence to get this stuff working in Debian from scratch so that might make sense
[14:13] <infinity> cjwatson: What did you do to break it? :)
[14:14] <cjwatson> Installed eclipse-egit from Debian
[14:14] <cjwatson> The -mylyn build log has stuff like:
[14:14] <cjwatson> jh_installeclipse: Cannot determine the package providing /usr/share/java/httpclient.jar.
[14:14] <cjwatson> Which looks possibly relevant
[14:14] <infinity> Missing build-deps?
[14:15] <cjwatson> libhttpclient-java is there
[14:15] <cjwatson> JDK 6 vs. 7?
[14:15] <infinity> That seems likely.
[14:17] <cjwatson> But it just uses dpkg -S for that check
[14:17] <jodh> barry: howdi
[14:18] <barry> jodh: hi!  sorry about crossing signals on that bug.  i tried to find you on irc but i think it was past your eod
[14:18] <infinity> cjwatson: Which would imply the files don't exist...
[14:18] <cjwatson> And yet.
[14:18] <jodh> barry: np!
[14:18] <barry> jodh: did you see the patch and test i uploaded?  i wonder if it makes sense to pull those into your mp for lp:python-apt?
[14:20]  * infinity scratches his head...
[14:20] <cjwatson> Trying to construct a matching build locally now.
[14:21] <jodh> barry: I think mvo has already taken both your + my code and put it into the ubuntu branch.
[14:22] <Laney> please can someone reject https://code.launchpad.net/~schumski-deactivatedaccount-deactivatedaccount/ubuntu/quantal/kmess/1045090/+merge/122427 per the comment there
[14:22] <barry> jodh: great!  i still have a few comments about the mp, so i'll just follow up there and let mvo dtrt.
[14:22] <stgraber> Laney: marked as work-in-progress
[14:23] <Laney> stgraber: if that gets it off the list, cool
[14:23] <Laney> (I could have done that too)
[14:23]  * dholbach hugs Laney
[14:23] <stgraber> Laney: no you can't do that yourself, you need to be in ~ubuntu-branches (so basically be a TB member)
[14:23] <Laney> I get the option
[14:23] <Laney> Work in progress, Needs review, Merged
[14:23]  * xnox too
[14:24] <stgraber> oh, is that new?
[14:24] <xnox> that is not "Rejected" though.
[14:24] <stgraber> anyway, yes, work in progress will get it off the report
[14:24] <xnox> and sounds nicer =)
[14:25] <mvo> barry: I merged a bunch of stuff this morning, I did not see a MP from you though? did I miss that? (just from from jodh)
[14:25] <infinity> cjwatson: I bet it's just sketchy parsing of "dpkg -l" in perl that the new dpkg may have broken.
[14:25] <cjwatson> It's possible.  I should be able to tell once I get far enough through the build (unfortunately it's a bit slow).
[14:26] <barry> mvo: no, i didn't get around to doing the mp.  was going to do that today, but i think i won't need to.  you grabbed the package patch i applied for LP: #1030278 right?
[14:28] <Laney> jodh: would you care to continue reviewing https://bugs.launchpad.net/ubuntu/+source/zabbix/+bug/1047837 ?
[14:29] <barry> jodh, mvo i added a few comments to https://code.launchpad.net/~jamesodhunt/python-apt/test-for-size_to_str/+merge/127435
[14:30] <infinity> cjwatson: Or not.  A simple copy-and-paste reduced test case from javahelper spits out package and version just fine.
[14:30] <cjwatson> It's not locale-dependent or something, is it?
[14:31] <cjwatson> (I do wish eclipse* didn't have 100MB-plus build-deps from universe.)
[14:31] <infinity> LANG=C seems to behave fine too.
[14:31] <cjwatson> C.UTF-8?
[14:31] <infinity> cjwatson: Installing just libhttpclient-java is small.
[14:32] <cjwatson> Yeah, but since that apparently doesn't reproduce the problem ...
[14:32] <jodh> Laney: comment added.
[14:32] <infinity> Well, yes.  But I'm stumped, cause it clearly has the right string there.
[14:32] <Laney> ty
[14:32] <infinity> Which it then passes to the sub that I copied verbatim.
[14:32] <infinity> And it works.
[14:32] <infinity> >:(
[14:32] <mvo> barry: thanks, I'm in a call now wil comment in a bit
[14:33] <jodh> barry: thanks.
[14:38] <infinity> cjwatson: Any chance those strings could be null-terminated or something wonky?
[14:38] <infinity> cjwatson: That would asplode the dpkg -S
[14:39] <cjwatson> Yeah, not sure yet
[14:42] <mfisch> Riddell: ping
[14:42] <Riddell> hi mfisch
[14:43] <mfisch> Riddell: hey, I'll test my deb in a bit here and let you know in the defect
[14:44] <Riddell> mfisch: point me at it and I can test too
[14:44] <mfisch> Riddell: okay, need to finish up a phone call first
[14:48] <ev> ugh, yes python-apt, what I really mean by "extract this deb" is "create a lot of empty directories for each symlink you encounter."
[14:51] <ogra_> oh, that fix to bug 390247 looks tempting
[14:51]  * ogra_ wonders if there are any drawbacks using udev rules like that
[14:53] <xnox> ogra_: hmm... is the scheduler per drive? what if I have one rotational and one SSD ?
[14:53] <Laney> jcastro_: do you know when the HP cloud trial finished/finishes?
[14:53] <ogra_> yes, it is
[14:53] <xnox> ogra_: that's ok then. Upload on day one or r-series?
[14:54] <ogra_> xnox, well i wonder if it could help with bug 864051 as well somehow
[14:55] <xnox> ogra_: I like the bug 390247 solution better. If we can enable trim/ change scheduler on the fly the better.
[14:55] <mfisch> Riddell: it will be built in a bit, I haven't tried it yet: https://launchpad.net/~mfisch/+archive/testing/+packages
[14:56] <mfisch> Riddell: it's looking like it will be a few hours before I can install it
[14:56] <xnox> ogra_: the caveat here, if we get it wrong we may wear one of the other out.
[14:56] <xnox> s/of/or/
[14:56] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ cat /sys/block/sdd/queue/scheduler
[14:56] <ogra_> [noop] deadline cfq
[14:56] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ cat /sys/block/sda/queue/scheduler
[14:56] <ogra_> noop [deadline] cfq
[14:56] <ogra_> wrt your first question
[14:57] <jcastro_> Laney, they have not given me an exact date.
[14:57] <jcastro_> Laney, basically, keep an eye on it, lmk if they start charging you.
[14:57] <Laney> jcastro_: OK, I'm kind of scared to use it any more for this reason
[14:57] <ogra_> xnox, hmm, i thought if the HW doesnt support TRIM it simply wont be used
[14:57] <jcastro_> you're an employee, we have a cloud policy you can expense.
[14:58] <Laney> heh
[14:58] <xnox> ogra_: but schedulers are available for all drives?
[14:58] <ogra_> xnox, the question is, can we tell it somehow through sysfs to use TRIM or is that only possible as mount option
[14:58] <jcastro_> And that would enable us to know if they did start charging us so I can tell community members to either stop or keep going.
[14:58] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ ls /sys/block/sd*/queue/scheduler
[14:58] <ogra_>  /sys/block/sda/queue/scheduler  /sys/block/sdb/queue/scheduler  /sys/block/sdc/queue/scheduler  /sys/block/sdd/queue/scheduler
[14:58] <ogra_> grmpf ... IRC
[14:58] <lfaraone|sh> jcastro_: let me know, too, haha. they also ended their 50% discount on cloud usage.
[14:59] <xnox> jcastro_: Laney: don't they invoice monthly with no updates and that means, if they do invoice it's too late...
[14:59] <ogra_> xnox, at least for all sdX ones
[14:59] <jcastro_> xnox, yes, exactly
[14:59] <Laney> well, you'll then have to claim it back
[14:59] <Laney> as long as random usage is covered by this policy then it's cool by me
[14:59] <ogra_> ah, also for sr0 loop and ram devices that i have here
[14:59] <Laney> like, I'll use it now to do this patch piloting since my PC sucks
[15:00] <jcastro_> Laney, don't take my word for it, please read the internal cloud policy document (I don't have it handy)
[15:00] <xnox> Laney: didn't you brag about your new i7 on facebook?!
[15:00] <Laney> yeah but I'm working
[15:00] <Laney> can't be building PCs now can I :P
[15:00] <jcastro_> I am kind of hoping they just love Ubuntu and leave the accounts open and free for the benefit of the project. :)
[15:02] <ogra_> xnox, hah !
[15:02] <ogra_> xnox, http://lwn.net/Articles/515790/
[15:04] <Laney> jcastro_: yeah just read it, seems like it would clearly be fine
[15:04] <ogra_> so seems trim/discard should be tweakable through sysfs too with that patch
[15:04] <Laney> I'll give it a go then, thanks
[15:04] <xnox> ogra_: lol =) interesting.
[15:05] <jcastro_> Laney, yeah, unfortunately I have no way of finding out when/if they shut it off, I figure it's better for us to find out than having a community member stuck with a bill
[15:05] <jcastro_> xnox, did you ever do the rebuild thing on HP cloud?
[15:08] <xnox> jcastro_: i did do recompress https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-dpkg-xz
[15:08] <xnox> for that blueprint
[15:08] <xnox> of amd64, all, dbgsym packages.
[15:08] <xnox> using hadoop cluster on top of HPCloud.
[15:09] <Laney> isn't there a problem with using xz in the base system, or something?
[15:09]  * Laney can't remember exactly
[15:09] <Laney> something to do with debootstrap maybe
[15:10] <cjwatson> There certainly was at one point, and may still be.
[15:10]  * lfaraone|sh is reducing his usage to ~3 XS instances, as a precaution. 
[15:13] <xnox> Laney: cjwatson: but it is awesome for -dbgsym packages =)
[15:13] <cjwatson> infinity: Argh.  eclipse-mylyn got the right dependencies when built locally.
[15:13] <Laney> yeah, I'm sure the ddeb archive will thank you
[15:13] <cjwatson> xnox: You could fix -dbgsym easily independently, in pkg-create-dbgsym.
[15:13] <xnox> cjwatson: yes.
[15:14] <infinity> cjwatson: ...
[15:14] <cjwatson> (And no errors from jh_installeclipse.)
[15:15] <infinity> cjwatson: Well, that fits with my by-hand unit-test of test.pl, but that's pretty unhelpful.
[15:15] <cjwatson> I might try another build in a PPA to see if it's cosmic rays.
[15:15] <infinity> cjwatson: That's some serious cosmic rays...
[15:15] <infinity> cjwatson: I guess filesystem corruption could have thrown a null in the perl script... Somehow?
[15:15] <xnox> cjwatson: and then we can discuss if we fill flip the xz switch elsewhere e.g. (amd64, i386, all, armel, armhf, powerpc) x (debs, ddebs, udebs) x (lamba function of your choice)
[15:16] <cjwatson> xnox: Personally I'm not interested in doing this independently of Debian.
[15:16] <cjwatson> Too much hassle for too little gain.
[15:16] <xnox> ok.
[15:16] <cjwatson> Debian seems to be showing signs of wanting to do it in the near future anyway.
[15:17] <cjwatson> So if we do it ourselves, that's potentially a non-trivial amount of work that might well be superseded in not very long anyway ...
[15:17] <infinity> Indeed, it was hotly discussed at Debconf.
[15:17] <ogra_> pitti, any opinion about bug 390247 ? i think we shoudl ship it, but i'm not sure where to add it, udev or udisks ...
[15:17] <cjwatson> So why not contribute our effort to making it work right in Debian, if that's what we want to do
[15:17] <infinity> Though, mostly just from the POV of twiddling debhelper's defaults.
[15:17] <infinity> (And their defaults may still end up not being what we want, given that people think "slow arches" don't deserve good compression, so we'll see)
[15:18] <infinity> I tried to fight that mentality as hard as I could.
[15:18] <xnox> or look at the stats and identify packages that are not gaining anything from compression, and e.g. initiate fixing those pre-compressed packages.
[15:19] <infinity> xnox: Yeah, a lot of compressed stuff shouldn't be.
[15:20] <infinity> xnox: And some stuff should be gz instead of xz, and, and.. But the per-package tweaks are orthogonal to picking a sane default.
[15:20] <xnox> infinity: especially after we already optimise our pngs for example.
[15:20] <cjwatson> I realise there are some sub-block files where it makes no difference; but "fixing" many others might well entail making the installed system bigger.
[15:20] <cjwatson> Which isn't a good side-effect.
[15:21] <infinity> cjwatson: We're talking debs specifically, hard to make the installed system bigger by changing compression of debs...
[15:21] <infinity> (At least, I think we are)
[15:21] <xnox> cjwatson: how would the installed size change?
[15:21]  * xnox agrees with infinity 
[15:22] <cjwatson> "fixing those pre-compressed packages" - any pre-compression is going to be individual files inside those .debs, surely.
[15:22] <infinity> cjwatson: When I talk about "some stuff shouldn't be compressed", I literally mean some data.tar.gz components should be data.tar (openclipart is a great example).
[15:22] <cjwatson> Oh, I see
[15:23] <cjwatson> Apparently nobody's doing that right now since LP doesn't support it
[15:23] <infinity> Yeah, we noticed that in the BOF. ;)
[15:23] <cjwatson> So you might want to fix that first
[15:23] <infinity> dak supports it because they tore out the component filename check a while ago.
[15:24] <infinity> soyuz should likely just do the same.
[15:24] <cjwatson> Probably.
[15:24] <infinity> (Or maybe you pulled it out when you decided it was crusty and unnecessary...?)
[15:24] <infinity> I dunno, I don't have a checkout in front of me.
[15:25] <xnox> should I upload at tar compressed package to a ppa?
[15:25] <xnox> or does it need to be archive?
[15:25] <infinity> xnox: PPA would explode the same way.  But I'm not sure I care deeply to test this morning, and finding the relevant bit of code is minimal effort. :P
[15:26]  * xnox goes to make coffee instead =)
[15:26] <ogra_> coffee !
[15:28] <Laney> slangasek: If you need any more debugging info on that mountall bug, shout soon because this system is going to be flattened tonight
[15:39] <slangasek> Laney: flattened?
[15:39] <Laney> slangasek: replaced
[15:40] <slangasek> Laney: so one thing I noticed in the output was /media/debian/var/lib/schroot/union/overlay mounted before /var/lib/schroot/union/overlay, which looks like it's probably wrong, but I'm not sure
[15:41] <cjwatson> infinity: Search for verifyFormat (at least)
[15:41] <slangasek> Laney: would be interested to know if you get different results when commenting out either or both of that mount point, and the non-standard /cgroup one
[15:41] <Laney> OK, can do that
[15:41] <cjwatson> Probably ought to run dpkg-deb -I or something
[15:41] <Laney> no clue where the second overlay came from
[15:42] <infinity> cjwatson: Yeah, I feel like we've had this conversation before.
[15:42] <cjwatson> It's not impossible
[15:42] <infinity> cjwatson: Cause I remember verifying that dpkg-deb -I exits non-zero on broken archives.
[15:43] <infinity> cjwatson: Of course, that approach also requires making sure soyuz's dpkg always support the latest and greatest deb formats, but I suspect that's a sane thing to require anyway.
[15:46] <cjwatson> infinity: ICBW but I think I landed something else a while back which means that it has to nowadays.
[15:49] <slangasek> Laney: I presume that schroot did some session recovery and mounted it within a chroot for you?  But it looks like it's doing this too early
[15:50] <Laney> /media/debian is an installation of sid on another partition
[15:51] <Laney> I can't remember how I set this up :P
[15:52] <brendand_> who's in charge of errors.ubuntu.com?
[15:53] <stgraber> brendand_: ev
[15:53]  * ev hides
[15:53] <brendand_> ev, who can have access? there's an upstream maintainer who wants to access it
[15:54] <brendand_> ev, at least they say they are
[15:54] <mitya57> that's me actually :)
[15:54] <brendand_> mitya57, i'm sure you are :)
[15:54] <mitya57> I'm Ubuntu maintainer, not only upstream
[15:54] <ev> brendand_: at the moment it's only people in ~canonical or ~ubuntu-bugcontrol
[15:55] <ev> so getting into the latter group would be my suggestion. :)
[15:55] <ev> we do want to open it up to a wider audience, but there are serious privacy concerns
[15:55] <ev> as anything at all can be in the crashes
[15:56] <mitya57> I definitely plan to do that, but I want to become a Ubuntu member first, which won't be possible until November :(
[15:56] <pitti> ogra_: I don't have an opinion about this, I'm afraid; I know nothing about schedulers :(
[15:56] <pitti> ogra_: I do know that linux sucks while doing heavy I/O, especially on my rather fast SSD
[15:56] <ogra_> pitti, no, but you know where device rules usually live :=
[15:56] <pitti> so maybe this alleviates it a bit
[15:56] <ogra_> :)
[15:56] <brendand_> mitya57, no reason to do it that way around. i was in bug-control first and then only after ubuntu-members
[15:56] <brendand_> mitya57, in fact bug-control membership can be valuable collateral for your application
[15:56] <ogra_> pitti, the rule is correct ... its just about where to put it
[15:57] <pitti> ogra_: well, if you mean that, a rule like this would never go into udev itself; it's a workaround for bad kernel defaults (if it is a bad default)
[15:57] <pitti> at least not upstream
[15:57] <ogra_> its not
[15:57] <ogra_> its something the kernel cant detect (yet)
[15:57] <pitti> so if the kernel can't detect it, how can userspace?
[15:57] <pitti> but anyway, if you want to put rules into udev, you know where the bzr tree lives :)
[15:57] <ogra_> theoretically the kernel shoudl just notice the device is an SSD and set the right default scheduler
[15:57] <mitya57> brendand_: ok, so I'll apply when I have some time, can you still show me that crash?
[15:58] <ogra_> well, the kernel exposes the feature to userspace ... but doesnt do any proper automated handling of it yet
[15:58] <smagoun> Hi, would someone review this bug and (hopefully) mark it public? Apport has identified it as the master bug for an issue, I'd like to see the master bug. https://bugs.launchpad.net/bugs/883615
[15:58] <ogra_> pitti, so rather udev than udisks ?
[15:58] <ogra_> (that was my actual question ;) )
[15:59] <brendand_> mitya57, anyway i have the screenshot here (of the python stack trace). i'm pretty sure there's nothing confidential/private shown so unless ev wants to veto it i can post the link here...
[15:59] <pitti> rather "fix the kernel", I'd say, but it's a nasty workaround rule no matter where it lives :)
[15:59] <stgraber> smagoun: done
[16:00] <smagoun> stgraber: thank you!
[16:00] <ev> brendand_: presumably you mean paste the text or put up a pastebin url of the contents - you shouldn't be able to get to the stack trace without going through open ID
[16:00] <ev> but I don't mind if you share the contents :)
[16:00] <ogra_> pitti, whats nasty about it ? i prevents your SSD from wearing out and increases performance :)
[16:01] <pitti> ogra_: I mean having userspace rules to fix broken defaults (that's why it wouldn't go upstream)
[16:01] <ogra_> andi agree it should be fixed in kernel eventually
[16:01] <xnox> ogra_: i'd stick it into hdparam package or something like that.
[16:01] <ogra_> well, its not defaults, but rather missing handling of them
[16:02] <pitti> ogra_: so for packaging, I guess it's fine to put it into udev, as that has an ubuntu specific packaging anyway, so doesn't introduce a delta; but I don't mind much which package it ends up in
[16:02] <ogra_> xnox, hmm, i think that would add a depends on udev, no ?
[16:02] <ogra_> pitti, thanks :)
[16:02] <pitti> no, it's just shipping a file
[16:02] <pitti> if udev isn't installed, the rule wouldn't work anyway
[16:02] <brendand_> ev, heh - pastebin would be even better :) assuming mitya57 is only interested in the stack trace?
[16:02] <pitti> but then again, you can't uninstall udev
[16:03]  * pitti waves good night
[16:03] <pitti> need to run now
[16:03] <brendand_> mitya57, http://paste.ubuntu.com/1256228/
[16:03] <mitya57> thanks brendand_!
[16:03] <ogra_> ciao pitti and thanks again
[16:05] <brendand_> mitya57, and do get bug-control sooner rather than later :) make your life easier
[16:05] <mitya57> brendand_: sure
[16:08] <davidcalle> jbicha, hi. I'd like to have your advice on https://bugs.launchpad.net/unity-lens-photos/+bug/1049090. It's a OEM team request to change a lens shortcut (Super+P to Super+C).
[16:11] <davidcalle> jbicha, is this shortcut documented?
[16:14] <ev> pitti: any objections to depending on python3-debian? I had to rework that merge
[16:14] <ev> python-debian is in main
[16:14] <ev> I'll need to work out a MIR for python3-debian
[16:15] <cjwatson> No, you don't
[16:15] <ev> ORLY
[16:15] <cjwatson> MIRs are by source package
[16:15] <ev> oh, right
[16:15] <ev> cheers
[16:15] <cjwatson> python3-debian can be promoted as soon as something depends on it
[16:15] <ev> woohoo
[16:16] <cjwatson> (Or just in advance, if that's more convenient - but not too much in advance so that we don't spend too long with junk in component-mismatches)
[16:17] <jbicha> davidcalle: yes http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-docs/quantal/view/head:/ubuntu-help/C/unity-dash-photos.page
[16:20] <smoser> slangasek, i'm guessing that this is fallout of the mountall change
[16:20] <smoser> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1060296
[16:21] <jbicha> but Super+P as a video out shortcut isn't in ubuntu-docs
[16:24] <davidcalle> jbicha, I see. It's apparently a standard for some OEM.
[16:24] <slangasek> smoser: please get me the boot-time output of mountall --verbose
[16:25] <smoser> slangasek, isnt it clear this is a fallout?
[16:25] <jbicha> davidcalle: we might be able to sed replace it, do different languages have different keyboard shortcuts?
[16:25] <jbicha> on the other hand, the Ubuntu Manual is almost string-frozen too
[16:25] <smoser> i can do that though.
[16:25] <slangasek> smoser: knowing that it's fallout doesn't tell me how to fix it
[16:25] <davidcalle> jbicha, no, same shortcut.
[16:26] <smoser> well, mountall is trying to write stuff to /etc/mtab before / is rw
[16:26] <smoser> because we told it to mount other stuff before / is rw
[16:26] <slangasek> smoser: I need the debugging output from the machine where this is happening
[16:26] <smoser> :)
[16:29] <jbicha> davidcalle: ok, I guess it's fixable with a text replacement, but...
[16:29] <Laney> @pilot out
[16:30] <jbicha> currently all the lenses are ordered alphabetically in English, and photo lens or even picture lens sounds better than camera lens
[16:30] <davidcalle> jbicha, I know, that's why I'm worried about this. The new shortcut has been decided on this morning, the comment timeline on the report is... well, let's say it could have been fixed a long time ago. :/
[16:30] <jbicha> so changing the shortcut would make other stuff more inconsistent
[16:31] <davidcalle> jbicha, I agree.
[16:32] <davidcalle> jbicha, but Super+P is an OEM blocker.
[16:32] <jbicha> davidcalle: while you're here, my wife really hates that there aren't tooltips to let people know what the different lenses are
[16:33] <jbicha> I need to bug the designers about that since it's a wife blocker ;)
[16:33] <davidcalle> jbicha, I thought the social bird was pretty clear ;-)
[16:34] <jbicha> I don't know, it hasn't landed yet... the applications icon isn't clear at all though
[16:38] <davidcalle> jbicha, it isn't. About tooltips I think it would be nice to experiment with it, or to redesign the lens bar completely to accomodate icons + text.
[16:41] <mvo> barry: had a bit of a busy afternoon, please merge from lp:~mvo/python-apt/debian-sid-mirror that will contain some of your suggestions :)
[16:41] <jbicha> davidcalle: let's see, GNOME Shell & Android both use a bunch of squares to represent "All Applications"
[16:46] <jbicha> davidcalle: anyway, the keyboard shortcut change could get an UIFe, it's just less clear that it's the right change to make
[16:46] <davidcalle> jbicha, they both use it in the same context as other app icons, i'm not sure it would work here.
[16:50] <davidcalle> jbicha, could you make this comment on the report, to have it seen by design? Anything I need to do to make it a proper UIFE request?
[16:54] <jbicha> davidcalle: https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
[16:55] <davidcalle> jbicha, ty
[16:55]  * cjwatson swears at Python 2.  It can't die quickly enough
[16:55] <cjwatson> Stupid bytes.decode() default encoding
[16:58] <Laney> slangasek: so commenting out those entries indeed made it boot with 2.41
[16:59] <Laney> turns out /var/lib/schroot is a symlink to /media/debian/var/lib/schroot/
[17:01] <Laney> and it works if I change the mount point to the real path rather than going through the symlink
[17:02] <slangasek> Laney: thanks, useful to know - can you mention that in the bug (if you haven't already)?
[17:03] <Laney> yeah, pasting it in now
[17:07] <smoser> anyone seen this: http://paste.ubuntu.com/1256365/
[17:08] <infinity> smoser: Which part?
[17:08] <smoser> the failure
[17:08] <smoser> i've never seen thnat fail
[17:08] <smoser> (well, not like that)
[17:08] <infinity> Oh, I didn't notice that was fatal.
[17:08] <infinity> Is /home/ubuntu writeable?
[17:09] <smoser> yeah
[17:09] <smoser> actually, just creating that dir made it exit success
[17:09] <smoser> but still loud
[17:09] <infinity> Though, you'd think after going to all the trouble to make a tmpdir and put keyrings in it, it would also set the gpghome to that.
[17:09] <roaksoax> howdy! So i have a question regarding upgrades. So we had older maas install several files, including maas-celery.upstart. Now, in quantal, maas has simply become a virtual package. maas-celery.upstart no loonger exists anywhere
[17:09] <roaksoax> so on upgrade, maas-celey.upstart remains there
[17:10] <smoser> yeah.
[17:10] <roaksoax> any ideas of how to force the removal of those files that previous 'maas' package installed, when upgrading to new 'maas' (virtual) package?
[17:10] <smoser> and worse, if I create that directory, now i have root owned content in there.
[17:11] <infinity> roaksoax: Are you sure you mean virtual package, not metapackage?
[17:11] <infinity> roaksoax: I certainly see a "mass" package in quantal...
[17:11] <roaksoax> infinity: err yeah, metapackage :)
[17:11] <roaksoax> infinity: this is the new stuff that hasn't yet been uploaded to archives
[17:11] <infinity> roaksoax: man dpkg-maintscript-helper, see rm_conffile
[17:12] <roaksoax> infinity: cool thanks!
[17:18] <smoser> mvo, i'm guessing this is regression:
[17:18] <smoser> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1060335
[17:20] <infinity> Ahh, yeah, this calling GPG thing is shiny and new.
[17:22] <cjwatson> infinity: https://launchpadlibrarian.net/118143204/buildlog_ubuntu-quantal-i386.eclipse-mylyn_3.8.0-1%2Bppa1_BUILDING.txt.gz hmmmm
[17:22] <cjwatson> Same symptom
[17:23] <cjwatson> Any bright ideas?  I don't care about that PPA so I can push arbitrary debugging nonsense into it
[17:25] <infinity> smoser: Can you try editing ppa.py to add '"--homedir", tmp_keyring_dir' to GPG_DEFAULT_OPTIONS?
[17:25] <cjwatson> dpkg -S must be saying something since otherwise it wouldn't try dpkg -l.
[17:26] <cjwatson> I guess I could try PERLDB_OPTS='NonStop=1 AutoTrace' perl -d /usr/bin/jh_installeclipse
[17:26] <infinity> cjwatson: Oh weird.  That's pretty bizzarely not what I was expecting.
[17:27] <infinity> cjwatson: This is probably where I'd upload a custom javahelper with random print()s in that subroutine to try to figure out WTF dpkg -S is returning.
[17:27] <infinity> cjwatson: Or why it things pkg is unset.
[17:28] <infinity> cjwatson: Cause I can't even fathom why that's failing in production but not here.
[17:30] <infinity> smoser: Is that on quantal?
[17:31] <infinity> smoser: It looks to me like the precise upload DTRT, and quantal has an incomplete forward-port.
[17:31] <cjwatson> infinity: Check.  Stupidly verbose javahelper coming up.
[17:33] <smoser> infinity, quantal, yes.
[17:36] <infinity> cjwatson: It could still be dpkg -S not finding it, if it's just piping the output and ignoring the return.
[17:37] <infinity> cjwatson: Then you'd get a dpkg -l for "dpkg-query", which would return null.
[17:37] <cjwatson> It doesn't get into the dpkg -l unless dpkg -S returned some actual output.
[17:38] <cjwatson> On stdout.
[17:38] <cjwatson> "dpkg-query: no path found matching pattern /foo/bar" goes to stderr, so that won't get matched.
[17:39] <cjwatson> I think what actually happened is that something decided I didn't have enough odd puzzles.
[17:44] <bdmurray> slangasek: bug 1060249 is receiving a few duplicates now
[17:48] <infinity> cjwatson: Yeah, it almost certainly failed for your benefit.  Way to fight off dementia.
[18:06] <slangasek> cjwatson: ^^ any idea about this debconf crash?  looks like a new problem with the gnome frontend :/
[18:07] <ogra_> oh, that really has a few dups
[18:07] <cjwatson> No, but surely a libglib-perl/libgtk2-perl bug ...
[18:08] <cjwatson> Probably doesn't help that libgtk2-perl currently fails to build
[18:08] <slangasek> ah fun
[18:11] <cjwatson> slangasek: Every single one of the dups has been marked Invalid, presumably by apport due to lack of retraceability :-(
[18:11] <slangasek> score
[18:12] <cjwatson> So ... I have no idea.  rls-q-incoming it I guess ...
[18:12] <cjwatson> Oh, it's already targeted
[18:15] <jtaylor> Riddell: you did the new taglib version?
[18:15] <jtaylor> Riddell: tfile.h includes a nonexistant file (tiostream.h) which breaks mediatomb
[18:23] <mvo> smoser: yeah, what infinity said earlier :/
[18:25] <infinity> mvo: I'll be committing/uploading in a moment, don't worry about it.
[18:26] <infinity> mvo: (And don't read my POC patch, it was clearly broken)
[18:27] <barry> mvo: will look, thanks
[18:33] <infinity> mvo: Okay, fix uploaded and committed.
[18:33] <infinity> smoser: Done with the instance, thanks.
[18:35] <cjwatson> Huh.  https://launchpadlibrarian.net/118149510/buildlog_ubuntu-quantal-i386.eclipse-mylyn_3.8.0-1%2Bppa2_BUILDING.txt.gz
[18:36] <cjwatson> Not being printed by 'dpkg -l | grep -E ^ii'.
[18:36] <cjwatson> I'll have to finish up now and look again tomorrow though.
[18:37] <mvo> infinity: weeh, thanks!
[18:37] <infinity> cjwatson: You weren't kidding about cranking the verbosity to ridiculous...
[18:38] <cjwatson> I'm going to dump out raw dpkg -l next.
[18:38] <mvo> infinity: I will commit a simplification to trunk soonish as python-apt has apt.auth.add_key_from_keyserver() now (since ~yesterday) that performs the same verification
[18:40] <infinity> mvo: Heh, fair enough.
[18:41] <mvo> infinity: but thanks for taking care of this it means I can call it a day and worry about this later
[18:41] <infinity> mvo: NP.
[19:01] <clahey> Hey all.
[19:02] <clahey> I've got an internal bug assigned to me that points out that when I go to the Open With tab of the Properties dialog of a vmx file, it doesn't list vmware-player and vmware as options.
[19:02] <clahey> They're both there in the right click menu "Open With VMware Player" and "Open with VMware Workstation"
[19:02] <clahey> I'm curious how that dialog makes its list so that I can fix this.
[19:03] <Daviey> Gah, please can someone give me n00b lessons on the differnece between Reply and Reply-All. Seems i suck.
[19:03] <ogra_> Daviey, ??
[19:04] <clahey> Daviey: I have that issue sometimes.  I've decided to have the default be Reply All since that's almost always what I want, but when it's not, it can be pretty embarrassing.
[19:04] <Daviey> ogra_: ubuntu-devel, intended to send an offlist reply :)
[19:05] <ogra_> use reply-to-list then :)
[19:05] <ogra_> vs reply
[19:05]  * ogra_ never uses reply-all ...
[19:06]  * Daviey notes he didn't have this problem with telnet as a mail client :)
[19:08] <ogra_> heh
[19:25] <soren> Daviey: It also never happens with carrier pigeons.
[19:25] <soren> Daviey: Just saying.
[19:30] <clahey> soren: Are you saying you've never sent a flock of carrier pigeons when you meant to send only one?  That happens to me ALL THE TIME.
[19:31] <dead_inside> thats why i keep a shotgun at my desk clahey
[19:31] <dead_inside> kill them before they reach everyone
[19:31] <clahey> dead_inside: Tou ché.
[19:47] <arges> infinity, hello. I finally got access to AMD hardware to verify pad.lv/979003. Any other verification you'd like to see on the hardware while rtg  lets me use it?
[19:49] <infinity> arges: Nope, but I'll need to reupload all over again later tonight, cause the security update reverted it all.
[19:50] <infinity> arges: So, if Tim's going to let you have access to it for a day or two, I'll ping you as soon as I get a fresh upload in (probably by tomorrow).
[19:50] <arges> infinity, yea saw that,I was able to apply the diff cleanly on top, so it shouldn't be too bad
[19:50] <arges> infinity, ok perfect
[19:50] <infinity> arges: Yeah, it'll not be much effort.  I want to nail one or two more bugs while I'm at it, though, since I have to re-upload anyway.
[19:51] <infinity> arges: Anyhow.  I'll poke you about it tomorrow.  I've been up for ~30h, it might be time for a nap.
[19:52] <arges> infinity, wow... yea sounds good
[19:59] <TheBurrito> Anyone have tips for getting Ubuntu Core running on an Odroid-X? I've gotten Android 4.0.4 running, as well as the linaro image that hardkernel links to. I'm now using the original boot partitions with ubuntu-core as the root fs. I have copied all of the modules over from the linaro image to accompany the kernel with this new rootfs. I get serial consol output all the way up to fsck running. Is ubuntu core setup to run a serial
[19:59] <TheBurrito>  console?
[20:01] <ogra_> ubuntu core is intended for people who build images out of it (or as a cheap chroot if you are to lazy to debootstrap), its extremely minimal and totally unconfigured
[20:02] <ogra_> you need to create a serial upstart job to make it start a getty on serial
[20:03] <cjwatson> infinity: ahahahahahaha bonk
[20:03] <cjwatson> pi  libhttpclient-java                  4.1.1-2ubuntu1                    all          HTTP/1.1 compliant HTTP agent implementation
[20:04] <cjwatson> thanks, ... something
[20:06] <TheBurrito> I've tried that wihtout success. I followed the post at www.omappedia.com/wiki/OMAP_Ubuntu_Core to no avail. I was hoping to get a lightweight rootfs to create a robotics platform. perhaps i'll get the server rootfs and start from there until my linux-fu is stronger.
[20:06] <arges> micahg, hi. I have a backport that should be a no-change now.  is there anything I need to change to get it on to the backports queue? pad.lv/943502  .. thanks
[20:14] <stgraber> TheMuso: heya. I'm looking at the casper bugs, any progress on bug 122024?
[20:29] <TheBurrito> ogra_: I'm in. thanks for the pointer to upstart/getty.
[20:31] <tjaalton> hallyn: -qxl 0.1.0 needs spice-protocol 0.12.2 to build
[20:31] <tjaalton> bad upstream for not bumping the dep on configure.ac..
[20:33] <hallyn> tjaalton: drat
[20:34] <tjaalton> so just update it :)
[20:35] <hallyn> tjaalton: there is no 0.12.2 release, only 0.12
[20:35] <tjaalton> it's tagged in git
[20:36] <hallyn> do we care about risking having different .orig.tar.gz than debian?  or do we just stick git commit int he version #?
[20:37] <hallyn> well anyway, i'll put my best guess up at ppa:serge-hallyn/virt
[20:37] <tjaalton> http://spice-space.org/download/releases/ has the tarball
[20:39] <hallyn> tjaalton: I'm perhaps missing something. a re you suggesting i use 0.12.0 tarball and push the patches on top?
[20:41] <tjaalton> no, update the package
[20:41] <tjaalton> bump it to 0.12.2
[20:42] <tjaalton> oh it's in collab-maint
[20:43] <tjaalton> doesn't matter
[20:44] <hallyn> oh.  feh.  i was looking at spice.  spice-protocl does indeed have a 0.12.2. tarball. <slap>
[20:44] <tjaalton> hehe :)
[20:45] <tjaalton> pushed -qxl git, just use the current one on the ubuntu branch
[20:48] <hallyn> tjaalton: ok so i tried that last night and got stuck - where should i get the tarball so i can debuild -S?
[20:48] <hallyn> there didn't seem to be a rule in debian/rules to make it
[20:49] <tjaalton> tarball for what?
[20:49] <tjaalton> use uscan --download-current
[20:49] <hallyn> (meanwhile, new spice-protocol pushed to ppa:serge-hallyn/virt)
[20:49] <hallyn> huh
[20:49] <hallyn> ok, will do, thx
[20:50] <tjaalton> also, I just deleted the files that diff-ignore tries to ignore but fails
[20:50] <tjaalton> to build the source package for my tests
[20:51] <tjaalton> hallyn: once you're satisfied, please upload if you think it's worth it. you know this spice stuff better than I do :)
[20:51] <hallyn> tjaalton: i don't believe i have the perms to push any of it :)
[20:51] <hallyn> but i'll test and ping you tomorrow if that' sok
[20:51] <tjaalton> ahh, ok then I can push it
[20:51] <tjaalton> sure thing
[20:51] <tjaalton> I'll get up in ~7h
[20:52] <hallyn> tjaalton: cool then i'll try to finish befor ebed :)  thanks again, ttyl
[20:52] <tjaalton> hallyn: great
[20:53] <melodie> hello
[20:54] <melodie> I have searched in several places where to ask for more info about blueprints, what can be done in this matter and what belongs elsewhere (for 2 ideas I would like to communicate) but didn't find yet a place where I can get adviced. Is there someone here who could tell me about it ?
[21:35] <barry> tumbleweed: i requested your review on the mp for my branch for bug 935516.  i'm not sure the fix is right, or whether we should wait a little longer to hear from upstream.  comments are welcome.
[21:39] <zyga> pitti: ping
[21:39] <zyga> pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1007826
[21:39] <zyga> pitti: I just reproduced that on quantal
[21:40] <zyga> pitti: shall I repen it or file a new one (it was filed and fixedc on 2.2.4-0ubuntu1 and I have 2.6.1-0ubuntu1)
[21:54] <hallyn> tjaalton: works like a charm!
[21:58] <tumbleweed> barry: yeah, I never did it myself, because I wasn't entirely sure wha tthe best solution was. But that seems appropriate for Ubuntu
[21:59] <barry> tumbleweed: cool.  unless you disagree, i'll upload that fix and we can always back it out, or resync to debian later
[22:00] <tumbleweed> sounds fine
[22:00] <barry> thx
[22:12] <bryceh> anyone with NVIDIA graphics on precise want to help me test something real quick?
[22:12] <ion> bryceh: sure
[22:13] <bryceh> ion, thanks, I'll PM you the directions
[22:18] <bryceh> thanks ion!
[22:18] <ion> np
[23:04] <melodie> gn
[23:25] <Laney> Did something change to make me get mail for openstack-ubuntu-packagers?
[23:25] <Daviey> Laney: someone reviewed the moderated mail queue