[09:09] <cjwatson> infinity: I notice you're using subprocess.check_output in buildrecipe now.  Doesn't launchpad-buildd need to stick to features that were in Python 2.5 until we upgrade off lucid?
[09:09] <cjwatson> Er, hardy I mean
[09:09] <cjwatson> lucid had 2.6; subprocess.check_output is new in 2.7
[09:13] <cjwatson> infinity: Also, did you intentionally drop the "apt-get clean" from debian/launchpad-buildd.cron.daily?  The commit message didn't mention it.
[09:56] <infinity> cjwatson: Oh, I didn't realize check_output was new.  Bother.
[09:57] <infinity> cjwatson: And yes, I dropped the pointless apt-get clean.  lp-buildd has no business dealing with the host's apt.
[09:58] <infinity> cjwatson: Do you have a pre-2.7 recommendation for check_output-like functionality?
[10:02] <infinity> cjwatson: Hrm, os.popen.read, perhaps?
[10:05] <cjwatson> God, no, don't use os.popen.
[10:06] <infinity> cjwatson: *smirk*
[10:06] <cjwatson> subprocess.Popen(stdout=subprocess.PIPE).communicate()[0] is probably the best answer
[10:06] <infinity> cjwatson: I'm just looking for a quick-n-dirty backtick equivalent, not the most robust and complex subprocess control setup evar.
[10:07] <cjwatson> Though it wouldn't hurt to assign the Popen object to a variable so that you can check .returncode after calling .communicate.
[10:09] <infinity> Python amuses me.  The number of times I hear "oh god, don't use that method", when something shinier comes along, why don't they just rewrite the old to use the new, rather than point and laugh at you for using the wrong thing? :P
[10:09] <cjwatson> So maybe something along the lines of http://paste.ubuntu.com/5928451/, entirely untested.
[10:10] <cjwatson> Well, it's more that os.popen is lower-level.
[10:10] <infinity> That's certainly more unreadable.  Progress. ;)
[10:10] <infinity> cjwatson: I'm struggling to see what's wrong with low-level.  What could be lower-level than forking another process and checking its output?
[10:11] <infinity> Pretty sure that $() isn't all that fancy and high-level.
[10:11] <cjwatson> The above paste really is wrong.  One moment.
[10:11] <infinity> But, meh.
[10:11] <infinity> (I was going to just use os.popen and comment out the "this should actually be this, when we have 2.7+" line)
[10:12] <cjwatson> http://paste.ubuntu.com/5928455/ - better.
[10:12] <cjwatson> infinity: You're saying this to the guy who got fed up of doing that in C and wrote libpipeline ...
[10:14] <infinity> I wish I hadn't deleted all my hardy chroots.
[10:14] <infinity> But I don't wish that hard enough to recreate them.
[10:14] <cjwatson> I suspect the real reason os.popen is deprecated rather than fixed is a combination of (a) hard to make cross-platform (b) interfaces that take strings as commands rather than lists are fundamentally evil
[10:15] <cjwatson> (Although maybe (a) is wrong since the documentation says it works on Windows.)
[10:15] <infinity> cjwatson: A string is perfectly reasonable if you're passing it to "sh -c", but that returns to the "not cross-platform".
[10:16] <infinity> Maybe there's a cmd.exe -c equivalent (or some functionality provided by rundll or something)
[10:16]  * infinity shrugs.
[10:17] <cjwatson> Interfaces that take strings are the root of many security holes.
[10:17] <infinity> Programmers who don't do input validation are the root of many security holes.
[10:18] <infinity> Anyhow.  Doesn't matter to me either way.  And I'm too sick to have religious debates.
[10:19] <infinity> cjwatson: If that pastebinned diff works as a quick copy-and-paste-and-replace-the-chroot-path-with-a-string snippet, commit away.
[10:20] <infinity> And given the hasty addition of PIPE to your import in the second try, I assume you did actually test it. ;)
[10:22] <infinity> cjwatson: I actually started out with basically that (since Popen was already imported), got lost when various stdout=PIPE examples blew up in my face, and never get to the point of learning until now that PIPE was a thing I needed to import.
[10:22] <infinity> s/get/got/
[10:28] <cjwatson> I usually spell it subprocess.PIPE, which is clearer, but I was going with the prevailing style here.
[10:28] <cjwatson> Committed.
[17:09] <phillw> Hi folks, just a quick note to say that the links at http://iso.qa.ubuntu.com/qatracker/milestones/254/builds/37582/downloads are reporting 404
[17:09] <cjwatson> That's hardly surprising
[17:10] <cjwatson> We only keep daily builds around for a couple of days
[17:11] <cjwatson> iso.qa.ubuntu.com is not a persistent way to get at images after they've finished their testing cycle
[17:11] <cjwatson> Ubuntu 12.04.2 server amd64 is here: http://releases.ubuntu.com/12.04.2/
[17:14] <phillw> cjwatson: thanks colin, I need to re-grab it.