[05:10] <infinity> TheMuso: Ahh, indeed, thanks for the pointer.  Re-promoting it, then.
[10:21] <alessio> hi all
[11:42] <surak> I have a question about the bug reports submitted by apport. Every time I send such reports, my bugs are automatically marked as "invalid", as apport is aparrently unable to extract enough debug information, and the stack trace, for instance, always comes out blank. What to do?
[11:43] <infinity> surak: Upgrade.
[11:43] <surak> It is upgraded daily
[11:43] <infinity> Well, generally, the retracers only have a hissy fit if they can't find the debug symbols for your binaries.
[11:44] <surak> indeed. Are quantal's packages  compiled with debug symbols? Are there two versions of the repositories?
[11:44] <surak> This happens since 12.04
[11:45] <infinity> Example bug?
[11:45] <surak> 1033478
[11:45] <infinity> There's only one "version" of the archive, but if you're using a really laggy mirror, this could happen.
[11:46] <surak> deb http://archive.ubuntu.com/ubuntu quantal main restricted
[11:46] <infinity> Or, in this case, looks like the issue is the inverse.
[11:47] <surak> 1029420 and 1028863 too
[11:47] <surak> pardon?
[11:47] <infinity> The retracer is failing to find new symbols.  Perhaps ddebs.u.c is having problems.
[11:48] <surak> The oldest I still have here is the 1028863, 2 weeks ago - but it surely happened before that.
[11:48] <infinity> I know it ran out of disk space recently.
[11:48] <infinity> And there's been work on fixing that.
[11:49] <infinity> So, it could just be a temporary gap in coverage.
[11:51] <surak> Well... It has been like that for quite a while (more than quantal, for sure)
[11:52] <infinity> "like that" doesn't mean much.
[11:52] <infinity> It hasn't been just like this particular error at all times, I'm sure.
[11:52] <surak> Ok - it has been invaliding apport submissions for as long as I can remember
[11:52] <infinity> In this case, the ddebs are outdated compared to the packages on your system.
[11:53] <debfx> hm why do the lp buildds don't consider installing libsocket-perl when the package build-deps on "libsocket-perl (>= 1.95) | perl (>= 5.15.6)"?
[11:53] <debfx> https://launchpadlibrarian.net/112033772/buildlog_ubuntu-quantal-i386.libio-async-perl_0.51-2_MANUALDEPWAIT.txt.gz
[11:53] <Chipzz> infinity: sounds to me like the bug being marked invalid is a bug; shouldn't the retracer try again later?
[11:53] <infinity> debfx: There's a bug open for that.  sbuild misfeature.
[11:53] <seb128> surak, infinity: the versions you are using are weird
[11:53] <debfx> ok
[11:53] <seb128> surak, looking at bug #1029420
[11:54] <seb128>  Package: unity-2d-shell 5.12.0-0ubuntu2
[11:54] <surak> seb128: it was the version of the day.
[11:54] <yaffs> !ops
[11:55] <infinity> unity-2d-shell | 5.12.0-0ubuntu3 |       quantal | amd64, armel, armhf, i386, powerpc
[11:55] <yaffs> !ops
[11:55] <Pici> yaffs: ?
[11:55] <infinity> ^-- seb128 What's weird about bug 1033478
[11:56] <infinity> seb128: He has 5.12.0-0ubuntu3 (the latest) installed, ddebs.ubuntu.com is just lagging horribly, probably due to ENOSPC issues, and pitti's scripts falling over.
[11:56] <seb128> infinity, surak: seems like those unity-2d versions got bitten by the ddeb ENOSPACE
[11:57] <seb128> infinity, well, I think pitti told me last week at GUADEC that he made space
[11:57] <seb128> but it's likely part of the ddebs got lost
[11:57] <infinity> seb128: Yeah, IS cleared up some space for us.
[11:57] <Laney> ..
[11:58] <Laney> Funny looking terminal, this.
[11:58] <infinity> seb128: But this unity-2d build is a week old, so could have just been at the wrong time.
[11:58] <seb128> yeah
[11:58] <infinity> I guess we really need to look at moving this all to the librarian ASAP, so we stop losing things. :/
[11:59] <surak> Probably a bad time for upgrade. Last friday somehow the dist-upgrade ate my xorg.
[12:00] <infinity> debfx: sbuild misfeature aside, it's probably easier to just fix the build-dep for now.  The only reason that's a valid build-dep in Debian is pure fluke (because perl just happens to be in the buildd chroots, despite only transitively being build-essential)
[12:01] <infinity> surak: Are you running quantal-proposed...?
[12:02] <infinity> surak: Cause that's where all the xorg mangling has been happening.  And you really shouldn't have proposed enabled for a devel release, unless you expect/want it to break. :P
[12:02] <surak> yep - I like reporting bugs :)
[12:03] <infinity> Well, we use proposed specifically to break things.
[12:03] <infinity> I really wouldn't recommend running it.
[12:03] <infinity> Seriously.
[12:03] <surak> ok
[12:22] <tjaalton_> surak: probably lost the nvidia blob there, since -proposed doesn't have it yet
[12:23] <surak> This machine uses some onboard intel crap
[12:24] <surak> that's why unity-2d
[12:25] <tjaalton_> intel should work fine
[12:26] <surak> it always fails when I switch ports on the external screen
[12:26] <surak> but I never managed to make apport send this bug correctly
[12:34] <debfx> infinity: why would the build-dependency be invalid otherwise?
[12:35] <infinity> debfx: Because Debian ignores alternate build-deps unless they're already installed.  So, it only works in experimental (where it was meant to work) because perl happens to be there.
[12:36] <infinity> debfx: I'm not saying this isn't a bug in Ubuntu (it is, because our buildds don't ignore alternates, so they're clearly misbehaving here), but it's not a widespread issue either.
[12:37] <infinity> debfx: Anyhow, we do have a bug filed about it, and if I believe mterry was meant to be testing a fix.
[12:38] <infinity> debfx: It still might be faster to just alter the build-deps on that one package, though. :P
[12:39] <debfx> there are two packages with that build-dep ;)
[12:40] <infinity> (The other "solution" would be to force a perl transition... *cough*)
[12:58] <ogasawara> @pilot out
[13:32] <stgraber> @pilot in
[13:44] <mpt> ev, is bug 1033471 related to bug 989800?
[13:45] <ev> mpt: ah, they are the same issue
[13:45] <ev> apologies
[13:46] <ev> I didn't think to look for an existing bug first
[15:08] <ogra_> stgraber, you clearly need more CPU for apport :P
[15:09] <stgraber> ogra_: hehe, yeah ;) it's not too bad on my laptop, but it's a huge pain when happening on the panda or my netbook...
[15:09] <ogra_> yeah, same for me on the ac100
[15:09] <ogra_> on my desktop i dont notice apoport in the bg at all
[15:09] <ogra_> only the annoying popups that steal focus in the middle of typing a sentence
[15:10] <stgraber> I think what I'd actually love in my case would be some kind of "internal" whoopsie server on my network. Have all the machines always collect any needed data, shoot the result to my whoopsie server, then let me get a nice view of all the crashes on my network on a per day/machine view and then let me forward stuff to the public whoopsie
[15:11] <stgraber> that way no machine that I manage would ever prompt the user, I'd get more data on what's going on on the machines I care about and would be able to forward more crashes to the main whoopsie server
[15:12] <ogra_> yeah, but my mom wouldnt like me to set up an additional machine in her wlan to collect the crashes from the laptop :)
[15:13] <stgraber> ogra_: that's what VPNs are for ;)
[15:13] <ogra_> haha
[15:15] <ogra_> i would actually vote for leaving whoopsie on and getting seb128 30 new team members to deal with it ;)
[15:15] <seb128> ogra_, I would sign for that
[15:33] <infinity> stgraber: I wouldn't be against a tickbox for "silently report all errors; don't include sensitive data".
[15:33] <infinity> stgraber: Then I'd never see a dialog again, and never care.
[15:34] <infinity> stgraber: (This would have to be on the apport "report a problem" dialog, mind you, with a "how do you want to treat further errors?" heading, since if it's in some deep, dark settings thing somewhere, normal people will never know there's a "stop bugging me" option)
[15:44] <stgraber> infinity: yeah, I think it'd be a reasonable way to get all the data we want with a clear opt-in system that people would likely prefer to just not sending anything
[15:45] <infinity> stgraber: It's been a long time since I've used Windows and seen a drwtsn32 popup, but don't they do a similar "just automatically report shit after this one, please" thing?
[15:45] <infinity> stgraber: I honestly think that's the only way you can get a decent flow of data wihtout pissing off and/or confusing "regular people".
[15:46]  * ogra_ thought you couldnt disable drwatson
[15:46] <ogra_> iirc that annoyed the hell out of me with win 2000 ... though i havent touched win much afterwards
[15:48] <infinity> ogra_: Well, if Dr Watson annoyed the hell out of you, welcome to us having reinvented your pain. ;)
[15:48] <ogra_> yeah, i thought of it recently actually ...
[15:48] <infinity> (I'd have to go find a Windows desktop and force a page fault, but I'm fairly sure that even if you can't "disable" it completely, you can make it silent, which is really what we want here)
[15:49] <ogra_> though i really could live with the popups if they wouldnt just blkindly steal focus
[15:49] <ogra_> i find their behavior  way worse than their frequency
[15:49] <infinity> Yes, but you know what they mean.
[15:49] <ogra_> yes
[15:49] <infinity> Every time my parents get ANY sort of popup on their computer, they phone me.
[15:50] <ogra_> lol
[15:50] <infinity> Or when their mail client says something they've never seen.
[15:50] <infinity> Or, or, or...
[15:50] <ogra_> my mom still runs lucid :)
[15:50] <infinity> My parents run Win7, for irritating reasons.
[15:50] <ogra_> i only get occasional calls ... because she cant find the icon anymore or some such
[15:50] <infinity> But this isn't OS-specific, by any means.
[15:50] <ogra_> indeed
[16:31] <LoT> is there a determination between "core" and "non-core" packages used by the devel team(s)?
[16:31] <LoT> we're trying to figure out in Bug Squad how we got "core" and "non-core" determinations for importance, and I'm wondering if we're inheriting that from some devel-related thing.
[16:32] <micahg> LoT: I don't think those 2 are compatible
[16:32] <LoT> micahg: any idea where the terms came from then?  (see bugsquad emails)
[16:33] <LoT> actually... *disappears back to -bugs*
[16:37] <cjwatson> LoT: That sounds very vague.
[16:37] <LoT> cjwatson: if you're in -bugs, micah and i moved the discussion there
[16:37] <cjwatson> LoT: We have a few definitions of "core" depending on context, but who knows what it means in bugsquad terms :-)
[16:37] <cjwatson> I'm not
[16:38] <LoT> cjwatson: https://wiki.ubuntu.com/Bugs/Importance defines "core" and "non-core"
[16:38] <micahg> I jumped a little here, it could be compatible, I was conflating core and minimal
[16:38] <LoT> the issue here is that that documentation we use doesnt point to any definition of core or non-core
[16:39] <LoT> so part of this is finding out *where* we get those from, and if they don't exist already, well..
[16:39] <LoT> either define it or remove that distinction for BugSquad
[16:39] <cjwatson> LoT: That could mean anything - hard to tell.
[16:39]  * LoT wasnt sure if we get that from the dev team's distinction of what is core.
[16:39] <cjwatson> I doubt it.
[16:39] <LoT> indeed, that's what micahg and i determined during UDS
[16:39] <cjwatson> It certainly doesn't correspond to e.g. ubuntu-core.
[16:39] <cjwatson> Because most desktop applications aren't in that.
[16:40] <LoT> so if we don't get that from the dev team's definition of "core", then BugSquad needs to have a clear definition.
[16:40] <cjwatson> Sorry, I mean: no desktop applications are in that.
[16:40] <cjwatson> It's probably a deliberately vague term intended to allow judgement ...
[16:41] <cjwatson> But you might consider things like: applications that are installed by default; applications that are in main; applications that are popular
[16:47] <brendand> LoT - i'm pretty sure 'core' refers to being in the base installation (i.e. on the CD)
[16:48] <brendand> LoT - non-core means something installed later by the user
[16:48] <brendand> LoT - e.g. Shotwell = core, Skype = non-core
[16:49] <micahg> brendand: core is highly ambiguous with different definitions per-context
[16:50] <brendand> micahg, i'm 99% sure this is what it means in this case. it's meant to give precedence to the applications users are more likely to use
[16:51] <brendand> micahg, though certainly it could be clarified on the page
[16:52] <brendand> micahg, and even though i'm pretty sure that's what the definition was intended to be, it might be that we want to revisit it
[18:54] <slangasek> seb128: hmm, your new fontconfig is very spammy on stderr
[18:57] <seb128> slangasek, is it? :-(
[18:58] <slangasek> seb128: at least on my system, it is... http://paste.ubuntu.com/1133039/
[18:58] <Laney> me too: http://paste.debian.net/182434/
[18:59] <slangasek> checking those files, at least some of them appear to still be part of the default install in quantal
[19:00] <seb128> slangasek, Laney: thanks, I don't have those installed but my install is not a recent one, I might have uninstalled stuff over time
[19:00] <micahg> as well as grammatical issues :)
[19:00] <seb128> but it doesn't seem like a but in the fontconfig update
[19:00] <seb128> but->bug
[19:00] <Laney> I suspect it's a new warning and the wrongness was always wrong
[19:01] <seb128> rather a bug in the config shipped by those which triggers a warning in the new fontconfig
[19:01] <slangasek> yep, that may be the case
[19:01] <seb128> I will have a look at fixing those
[19:01] <slangasek> seb128: thanks much!
[19:01] <seb128> slangasek, Laney: thanks for pointing them!
[19:21] <lifeless> bug 974509
[20:15] <seb128> slangasek, http://launchpadlibrarian.net/84736369/popt_1.16-1_1.16-1ubuntu1.diff.gz
[20:15] <seb128> slangasek, "* Build-depend on gettext:any instead of just gettext, for cross-compilation support." ... do you know if that has been sent to Debian and if not if there is a reason to not to? that's the only diff we have
[20:15] <slangasek> seb128: the reason not to is the Debian autobuilders don't support it.
[20:16] <seb128> slangasek, ok, so we need to keep a delta for that? :-(
[20:16] <slangasek> yes
[20:16] <seb128> thanks
[20:16] <seb128> slangasek, it would be nice to put some rational in the changelog in those case, glad that you replied, it was not obvious from the diff
[20:19] <slangasek> seb128: sorry, I disagree, I'm not going to put rationale in the changelog explaining why any given change isn't in Debian yet
[20:20] <seb128> slangasek, I guess the merges should be let to be done by those who have the knowledge of the changes then...
[20:21] <slangasek> that's an option :)
[20:21] <seb128> it's not optimal though
[20:21] <seb128> I'm not against it, but it practice those merges just don't get done apparently
[20:26] <slangasek> well, merging new Debian revisions of libraries is a low priority as far as I'm concerned.  There's not many ways that a Debian maintainer *can* improve such a package that matter to us
[20:26] <slangasek> this one looks like it's potentially relevant because of hardening, at least
[20:57] <soren> mdz, kees, pitti, stgraber, cjwatson: TB meeting in 2½ minutes.
[21:00] <seb128> soren, pitti is on holidays so I doubt he will be around (just for info)
[21:00] <soren> seb128: Thanks!
[21:01] <mdz> soren, hi
[21:01] <cjwatson> ack
[21:09] <ScottK> superm1: I think you're wanted in #ubuntu-meetings.
[21:09] <ScottK>  -meeting
[21:09] <superm1> ScottK: sure i can pop in there
[21:09] <stgraber> ScottK: thanks
[21:09] <ScottK> You're welcome.
[21:16] <roaksoax> jbicha: thanks for filing the bug report on rhcs
[21:16] <roaksoax> jbicha: i was just about to sync it myself
[21:17] <roaksoax> jbicha: but i;ll make sure it gets removed from the blacklist before syncing it
[23:57] <SpamapS> ScottK: so, how far behind are you guys on precise-backports?