[00:18] <soniah> thanks ScottK
[00:18] <ScottK> soniah: You're welcome.  Thank you for contributing.
[00:19] <xnox> ScottK: about bug 1040900
[00:19] <ScottK> xnox: Yes?
[00:20] <xnox> ScottK: I think the intention is to get it into precise as soon as possible.
[00:20] <xnox> ScottK: and to me 2xSRU + upload in R is more expensive than 1xSRU and upload in Q
[00:21] <ScottK> xnox: As long as all goes well, yes.  This isn't about efficiency, it's about risk reduction.
[00:21] <ScottK> The bug's been there since August, so I think we're past it being something critical that needed immediate response.
[00:23] <xnox> ScottK: well yeah, there was load issue for stockachu, as he was not getting all his other uploads SRU'ed quickly enough.
[00:24] <xnox> ScottK: that is sponsored and/or accepted into -proposed.
[00:25] <ScottK> Right, but it's been a month and a half already, so I am highly skeptical that a bug that has existed for four years can wait a couple of weeks.
[00:25] <ScottK> Please spend time fixing serious problems before release.  There's no shortage of those.
[00:25] <xnox> ok.
[00:26] <xnox> bcmwl (source) 5.100.82.38+bdcom-0ubuntu4.1	restricted	admin	low	kubuntu netbook ubuntu-desktop	Proposed	2012-05-31
[00:26] <xnox> oneiric-proposed unapproved
[00:26] <xnox> *heh* nobody cares about oneiric....
[00:27] <xnox> is there a report for *all* queue?
[00:56] <doko_> Laney, how did your -gstabs experiments end up?
[02:26] <infinity> Laney: Your -gstabs test would probably work a lot better if you'd also exported CXXFLAGS.
[08:28] <Laney> infinity: better than what? It worked where it failed before and the remaining armel failure is unrelated
[08:28] <Laney> doko_: still building
[08:41] <Laney> infinity: (because we build with CXXFLAGS="$(CFLAGS)")
[17:11] <infinity> Laney: Erm, I was watching the log go by, and it sure didn't look like CXXFLAG=CFLAGS (as in, there was plenty of "-g -O2 ...")
[17:12] <infinity> Laney: If it succeeded where previous builds failed, I suspect that was because of something entirely unrelated, like it was building on a different kernel.
[17:16] <cjwatson> tumbleweed,barry: for that apt_pkg.size_to_str thing with the release upgrader - I'm very wary of changing python-apt, because that's an API change
[17:17] <cjwatson> tumbleweed,barry: also, I couldn't get size_to_str to actually emit a string that required the thousands separator, because it just changed units instead - any suggestions on a specific value that exposes the problem at that level?
[17:18] <cjwatson> oh, there we go, enormous values do it
[17:19] <cjwatson> ... but no.  sufficiently enormous values produce data corruption, not anything containing the thousands separator
[17:19] <cjwatson> >>> apt_pkg.size_to_str(99000000000000000000000000000)
[17:19] <cjwatson> '`tE\xf7\t\xbf\xf57\x8c'
[17:19] <cjwatson> >>> apt_pkg.size_to_str(99000000000000000000000000000)
[17:19] <cjwatson> '`tE\xf7\t\xbf\xf57\x8c'
[17:19] <cjwatson> oops, sorry
[17:27] <tumbleweed> cjwatson: the easy option is droppnig the non-breaking space from the locale
[17:27] <tumbleweed> it seems to be a fairly unusual thing to have as a thousands separator
[17:27] <tumbleweed> (and is an ubuntu-only patch, because the locale maintainer hasn't signed off on it yet)
[17:31] <cjwatson> tumbleweed: No, I'd rather not do that.  There are quite a few locales with NBSP in the thousands separator.  Besides, it indicates a type problem, which we should certainly fix.
[17:31] <cjwatson> I would really like a smaller reproduction case at the python-apt level than "run an upgrade", though.
[17:32] <infinity> Is there a bug for this that shows the problem?
[17:32] <cjwatson> It's on the -tracking list.
[17:32] <cjwatson> Bug 1031882.
[17:32] <cjwatson> But it doesn't say what downloadSize is.
[17:33] <tumbleweed> when I first ran into it, I assumed it was something that would hit other people, so just filed it and moved on
[17:33] <cjwatson> Anyway, I suspect that apt_pkg.size_to_str returns str regardless of Python version - that is, bytes for Python 2 and text for Python 3.  We shouldn't go changing that now.  Instead, the upgrader code should deal with it.
[17:33] <cjwatson> I just wanted to be able to actually reproduce it in a smallish test before changing anything.
[17:34] <tumbleweed> decoding it as utf-8 when in utf-8 locales seems straightforward enough
[17:34] <cjwatson> Eh, you have to be careful though because this code is polyglot 2/3.
[17:35] <cjwatson> It's probably if isinstance(foo, bytes): foo = foo.decode() territory.
[17:36] <cjwatson> I'll probably hit it with that stick on Monday if nobody's beaten me to it.
[17:37] <cjwatson> Hm, in Python 3 for enormous values you get "OverflowError: Python int too large to convert to C long", which I think may be the subject of another -tracking bug ...
[17:38] <cjwatson> *that*'s probably a python-apt bug
[17:38] <tumbleweed> are sizes larger than a C long likely to be an issue?
[19:55] <TheLordOfTime> if there's a bug about the images for 12.10 and the beta and what not, are those supposed to go here?
[19:56] <TheLordOfTime> or questions thereof...]
[21:09] <xclaesse> are there known issues with jack detection in quantal ?
[21:10] <xclaesse> I often cannot ear anything from the speakers but connecting headset in the jack works