[00:00] <slangasek> thumb mode, perhaps?
[00:00] <infinity> That was my guess.
[00:01] <infinity> That said, the compiler is meant to auto-guess the right thumbiness based on -march/-mcpu
[00:06]  * infinity spins up a local build.
[09:28] <cjwatson> bjf: Always installable - you're missing a "from alpha-1 onwards" there
[09:30] <cjwatson> bjf: Until we have MUCH better tool support for -proposed, it's not realistic to expect consistent installability before that
[10:48] <doko> cjwatson: component-mismatches doesn't seem to look for armel. is this expected?
[10:56] <doko> promoted to main on armel: gcc-4.7-multilib g++-4.7-multilib gfortran-4.7-multilib
[10:59] <cjwatson> doko: it's supposed to - maybe if you hadn't worked around it I could have investigated ;-)
[11:01] <cjwatson> doko: Oh, nothing to do with that actually, it just doesn't notice when packages are out of sync between architectures
[11:01] <cjwatson> doko: However, http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt is for this very purpose
[11:02]  * cjwatson promotes libopencc-dbg/powerpc while he's there
[11:10] <doko> ahh, good to know
[12:29] <Laney> can haskell-hjsmin please be copied precise-proposed → quantal?
[12:31] <cjwatson> You can do that yourself with Archive.copyPackage
[12:31] <cjwatson> lp-shell production devel
[12:31] <Laney> that's the recommended way now?
[12:32] <cjwatson> ubuntu = lp.distributions["ubuntu"]
[12:33] <cjwatson> ubuntu.main_archive.copyPackage(from_archive=ubuntu.main_archive, source_name="haskell-hjsmin", version="whatever", include_binaries=True, to_series="quantal", to_pocket="Release")
[12:33] <cjwatson> or something like that
[12:33] <cjwatson> we could use an ubuntu-archive-tools command for it
[12:33] <cjwatson> well, generally I prefer self-service over something that ubuntu-archive has to do
[12:33] <cjwatson> I think the above only requires upload privileges
[12:34] <Laney> yeah, I did it. I wasn't aware that it had been delegated down.
[12:35] <cjwatson> I think because normally we only do it after verification, and in that case sru-release -d deals with it
[12:35] <cjwatson> but if people explicitly want to copy from -proposed to ease testing, shrug
[12:36] <Laney> wfm
[15:51] <phillw> hi, could someone pop me the link up for the change in how 12.04 deals with 'admin' users. I'm a long way from my laptop and want to do a bit of digging about several 'paper-cuts' that seem to be becoming a theme. thanks.
[19:26] <slangasek> ScottK: fyi, the mumble qt regression I never got around to filing a report on is the bug that was just fixed in SRU ;)
[19:26] <ScottK> slangasek: Excellent.  Proves once again that procrastination pays.
[19:37] <infinity> ScottK: Hah.
[19:38] <ScottK> You act like I'm kidding.
[19:38] <infinity> I'm pretty sure you're not. ;)
[19:39] <ScottK> OK.
[20:19] <Laney> infinity: are you planning on putting your vim 'quantal' change into precise?
[20:20] <infinity> Laney: Hadn't planned on it, no.
[20:21] <stgraber> Laney: not running quantal yet? precise is SO last week ;)
[20:21] <Laney> I'd like it. Would you accept an SRU?
[20:21] <Laney> stgraber: It stole my lunch money :(
[20:21] <micahg> devscripts also doesn't seem to recognize quantal
[20:22] <infinity> SRUing for syntax hilighting seems a bit silly, but I guess for an LTS, it makes some sense.  But yeah, we'd want/need to touch everything that doesn't know about Q.
[20:23] <infinity> Traditionally, we don't do this, we just expect people to develop on the latest release. :P
[20:23] <Laney> The more painful this is, the more we can try and make sure it doesn't happen again :P
[20:23] <Laney> traditionally the name is known far enough in advance, no?
[20:23] <infinity> Laney: Sure, but that only solves the +1 issue.  If people want to SRU so P knows about Q, wouldn't they also want it to know about R and S?
[20:24] <micahg> that's why distro-info was created :)
[20:24] <infinity> But, no, traditionally we don't do this all in advance.
[20:24] <infinity> The last cycle might have been special for some packages, I dunno.
[20:24] <infinity> But vim (for instance) has traditionally always been the "first merge of the cycle", and included the syntax change.
[20:25] <tumbleweed> micahg: that's why distro-info was created, but we haven't been able to persuade enough people to use it yet...
[20:26] <Laney> at least for precise, oneiric and natty it was done before release.
[20:26] <tumbleweed> this is the first time the code name came so late
[20:26] <Laney> I think we would only want to encourage people developing to be on n-1.
[20:26] <Laney> So needn't worry about taking this stuff back too far
[20:26] <micahg> or a current LTS
[20:27] <Laney> well, I don't even know about that
[20:27] <Laney> certainly the current stable
[20:28] <micahg> developers are entitled to stability too :)
[20:28] <ogra_> thats why they gain weight all the time ;)
[20:29] <Laney> I guess if someone is willing to do the work I wouldn't mind, but I'm no SRU member.
[20:30] <infinity> File an umbrella bug about all the bits that need to know WTF a "quantal" is and start making appropriate precise tasks for each package, and we'll go from there?
[20:30] <infinity> Most of it's no-brainer 1-line backports.
[20:31] <infinity> Of course, by the time we get it all fixed, it shouldn't matter, because once the archive is stable, I do expect actual developers to be running Q.
[20:35] <Laney> bug #994208
[20:35] <ubot2> Launchpad bug 994208 in vim "Needs to know about quantal" [Undecided,New] https://launchpad.net/bugs/994208
[20:36]  * mdeslaur learns about "distro-info"
[20:52] <Laney> bah, all in main
[20:52]  * Laney adds self to core-dev.
[20:52] <infinity> Hah.
[20:52] <infinity> Just attach a bunch of debdiffs.  They must almost universally be 1-or-2-line patches.
[20:52] <infinity> I pilot tomorrow, you can beg me to sponsor them all then!
[20:53] <Laney> hardly seems worth the effort, like a debdiff for a no-change rebuild
[20:53] <infinity> Oh, for no-change ones, just note that's what's required. :P
[20:53] <infinity> (Err, they should all need changes, mind you)
[20:53] <Laney> they do, I'm just likening the two :P
[20:53] <Laney> noddy changes.
[20:54]  * infinity nods.
[21:17] <infinity> Laney: There, everything's fixed in Q (except clang, which I'm working on for other reasons), I'll put the 5 minutes into doing the same for P later. :P
[21:18] <Laney> oh, you did it?
[21:18]  * Laney just pull-lp-sourced everything
[21:18] <Laney> nice :-)
[21:33] <ScottK> tumbleweed: This is the same distro-info that made pbuilder-dist break as soon as quantal was released?
[21:33] <ScottK> It doesn't seem like much of a win.
[21:33] <infinity> Picky, picky. ;)
[21:34] <tumbleweed> ScottK: seeing as I ended up involved in it, I'm open to suggestions on reliability improvements
[21:35] <tumbleweed> we could put dummy r-series entries in, but that'll cause different confusion
[21:35] <tumbleweed> or we make it download data from somewhere, but then you've got another source of stale data...
[21:35] <infinity> Dummy entries don't seem like much help, when the real codename is what things need.
[21:36] <Laney> it was the immediate crashing in out of date data
[21:36] <infinity> People just need to be on top of updating it ASAP.
[21:36] <infinity> (And make it more robust, apparently)
[21:36] <tumbleweed> programs using it with slightly more error-handling would avoid blowups like the things ScottK is complaining about
[21:36] <Laney> pbuilder-dist really didn't need to unconditionally die then
[21:36] <tumbleweed> yeah
[21:36] <ScottK> tumbleweed: From my glance at the code it was trying to find out if something was the development release and add extra repos if not.  Rather than exploding if it can't find a development release, it could just assume adding the extra repos is OK.
[21:36] <tumbleweed> that was just due to API deficciencies
[21:37] <tumbleweed> ScottK: agreed
[21:37] <ScottK> But from a user POV, it's distro-info's fault.  If pbuilder-dist hadn't been improved to use it, all would have been fine.
[21:38] <tumbleweed> also in the worst case scenario, it could suggest what package needs updating and where to look
[21:38] <infinity> slangasek: If you want to put on an SRU hat for a couple of minutes and look at my 4 uploads in precise-proposed, that would be snazzy.  (They're bit-for-bit identical to my quantal uploads, except for changelog/version)
[21:54] <cjwatson> infinity: the text of your SRU acceptance messages suggests that perhaps you don't know about sru-accept.py in ubuntu-archive-tools (or else you need to commit your wording changes ;-) )
[21:54] <infinity> cjwatson: It suggests that I didn't use sru-accept in that case, yes. ;)
[21:57] <cjwatson> just checking ...
[21:57] <infinity> cjwatson: I'm (re-)learning all the SRU processes as I go. :P
[21:58] <infinity> My god, lintian's testsuite is more comprehensive than gcc's.
[21:59] <tumbleweed> blame nthykier