[01:36]  * mwhudson shoves branching-ubuntu into ec2 land (at last!) and goes to lunch
[01:37] <james_w> \o/
[01:37] <james_w> thanks mwhudson
[01:38] <mwhudson> james_w: you can see the diff at https://code.edge.launchpad.net/~mwhudson/launchpad/branching-ubuntu/+merge/13269 if you want
[01:38] <mwhudson> james_w: shouldn't you be asleep?
[01:38] <james_w> I should
[01:38] <james_w> so I will look tomorrow
[01:40] <mwhudson> cool
[02:22] <mwhudson> thumper: didn't i worry at you about which zcml was executing in scripts vs the webapp?
[02:23] <mwhudson> thumper: looking at the errorreportingutility lookup failures
[02:23] <thumper> mwhudson: yes you did
[02:23] <mwhudson> oh well, use globalErrorReportingUtility and don't worry over much i guess :/
[02:24] <thumper> mwhudson: my branch adds the registration of the utility for scripts
[02:24] <thumper> mwhudson: after talking with flacoste_afk
[02:24] <mwhudson> thumper: ah cool, that's a better solution
[02:24] <thumper> mwhudson: the code should be moved from c.l.webapp to lp.services.error
[02:24] <thumper> but hey
[02:25] <mwhudson> thumper: world hunger also needs fixing
[02:26] <thumper> mwhudson: :)
[02:26] <thumper> my desire to file bugs about ubuntu drops significantly as soon as things work again, even if intermittantly
[02:37] <mwhudson> hmm
[02:37] <mwhudson> the commit message area in https://code.edge.launchpad.net/~mwhudson/launchpad/branching-ubuntu/+merge/13269 looks seriously ugly
[02:39] <thumper> mwhudson: yes it does
[02:39]  * thumper has a cunning plan
[03:54] <thumper> mwhudson: https://pastebin.canonical.com/23283/
[03:54] <thumper> https://code.edge.launchpad.net/~andrea-bs/launchpadlib/fix-set_data_store/+merge/619
[03:54] <thumper> has a null date review requested
[03:54] <thumper> causing the oops
[03:54] <thumper> now how the hell did that happen?
[03:54] <mwhudson> thumper: that's really olkd
[03:54] <mwhudson> old
[03:55] <thumper> 619? yeah
[03:55] <thumper> I wonder if it slipped through early before we knew what we were doing
[03:55] <thumper> ...
[03:58] <thumper> rejected the proposal and now we have a working active reviews again
[03:58] <thumper> should look into that at some stage
[03:59] <thumper> maybe add a DB constraint
[04:05] <thumper> mwhudson: http://pastebin.ubuntu.com/292816/ ideas?
[04:05] <mwhudson> thumper: apt-get install python-boto ??
[04:05] <thumper> what is boto?
[04:06] <mwhudson> like launchpadlib is to launchpad, boto is to amazon web services
[04:06] <mwhudson> thumper: have you run ec2 on this laptop yet?
[04:06] <thumper> just about to
[04:07] <thumper> mwhudson: does land have --dry-run?
[04:07] <mwhudson> thumper: yes
[04:07] <thumper> heh, it tells me the mp is not approved :)
[04:07] <thumper> if I approve it does that make it r=me or you?
[04:08] <mwhudson> thumper: it looks at the votes
[04:08] <mwhudson> thumper: finish autoapprove already :-)
[04:08] <thumper> mwhudson: help me come up with the db schema and we can land it this cycle
[04:20]  * thumper needs to copy across aws credentials
[05:50] <mwhudson> sigh
[05:51] <mwhudson> so it turns out that writing a simulator for a confusingly concurrent situation is, in and of itself, confusingly concurrent
[05:52] <stub> Can mocker help?
[05:53] <mwhudson> stub: several processes involved so maybe not
[06:10] <mwhudson> hmmm straage, two successive calls to acquireBranchToPull are returning the same branch
[06:32] <mwhudson> well, that's a bug to fix i guess
[06:54] <mwhudson> argh
[06:55] <mwhudson> there's no way to tell the difference between a branch which failed last time that the puller is currently working on and one that failed last time :(
[06:56] <mwhudson> i can think of various stupid ways that you could encode this, but maybe we should just use jobs
[06:59] <mwhudson> right *now* however, i'm going to the pub
[08:21] <adeuring> good morning
[09:15] <mrevell> morning
[09:27] <wgrant> bigjools: I think I am attempting the impossible (establishing the matching publication for a deb's ddeb).
[09:28] <bigjools> wgrant: it should be possible
[09:28] <bigjools> you need to join via the BPR
[09:29] <wgrant> bigjools: I know, but there is no way to identify which of the potentially several BPPHs matches (think overrides).
[09:29] <bigjools> wgrant: the ddeb should not be overridden differently
[09:29] <noodles775> wgrant: let me know if you've got any improvements for bug 450124
[09:29] <mup> Bug #450124: Improvements to IBuilder.findBuildCandidate() <soyuz-build> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/450124>
[09:29] <ubot3`> Malone bug 450124 in soyuz "Improvements to IBuilder.findBuildCandidate()" [High,In progress] https://launchpad.net/bugs/450124
[09:29] <mup> Bug #450124: Improvements to IBuilder.findBuildCandidate() <soyuz-build> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/450124>
[09:29] <mup> Bug #450124: Improvements to IBuilder.findBuildCandidate() <soyuz-build> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/450124>
[09:29] <bigjools> GAH
[09:30] <wgrant> bigjools: Matching based on overrides sounds horribly fragile.
[09:30] <bigjools> who keeps putting bots in here
[09:30] <wgrant> And it's not been donebefore.
[09:30]  * wgrant hunts out jussi01.
[09:30] <bigjools> it's not an override, it's a matching publication in the same series, component and pocket
[09:31] <wgrant> But there's nothing unique about that.
[09:31] <bigjools> apart from the archive
[09:32] <wgrant> I mean, I can easily have duplicate (bpr, archive, distroseries, pocket, component, section)
[09:33] <jussi01> wgrant: just get one of your ops to quiet it for now is probably the best course of action
[09:33] <jussi01> wgrant: I dont have access to ubot3, thats nalioth, but if you just quiet it, it sits here and isnt a problem
[09:33] <wgrant> jussi01: ubot3 says you own it :(
[09:34] <jussi01> wgrant: unfortunately thats because it syncs the factoids from ubottu
[09:34] <wgrant> jussi01: Ahh.
[09:34] <bigjools> wgrant: well yes any model code can screw up the DB, but if it's encapsulated properly and the rules are self-contained then I don't see a problem
[09:35] <wgrant> bigjools: I have a deb and ddeb, in universe. I promote them to main, then demote them again.
[09:35] <wgrant> Now there are three publications for each, but two are duplicates.
[09:35] <wgrant> I now remove the deb, and it tries to drag along the ddeb.
[09:35] <wgrant> But how does it know whihc publication is the right one?
[09:36] <bigjools> wgrant: the one that's PUBLISHED
[09:36] <wgrant> bigjools: But I did all three override changes semi-accidentally in a single publication cycle.
[09:36] <bigjools> or the one with the most recent ID
[09:36] <wgrant> (it has happened)
[09:37] <bigjools> then you need to supersede old publications if you find inconsistencies
[09:37] <wgrant> Inconsistencies?
[09:37] <bigjools> gimme 10 I need to have a call
[09:37] <wgrant> Sure.
[09:49] <jml> hello
[09:50] <maxb> Hi, has anyone else seen failures on    lib/canonical/launchpad/pagetests/webservice/xx-wadl.txt ?
[09:52] <jml> hmm
[09:52] <wgrant> That name is familiar. What sort of failure?
[09:52] <maxb> wadl_schema.validate(wadl) returning False
[09:52] <noodles775> maxb: passes here locally (r9691 on karmic)
[09:53] <maxb> noodles775: How "interesting" :-)
[09:56] <BjornT> maxb: the wadl file is generated automatically, so my guess is that something went wrong generating it
[09:56] <jml> maxb, I get that failure when running the test on the stable branch.
[09:57] <jml> updating download-cache & running 'make build'
[09:59] <jml> still get the error
[10:00] <bigjools> wgrant: ok back
[10:00] <bigjools> so, you just need to take the publication with the most recent ID
[10:00] <bigjools> the publisher should supersede the others
[10:01] <wgrant> bigjools: Even if the latest one is no longer active? That sounds convenient.
[10:01] <wgrant> Although still a bit ew.
[10:01] <bigjools> yeah
[10:02] <bigjools> which makes me think, you might want to check that the publisher will work with debug archives :)
[10:02] <wgrant> Actually, this isn't safe.
[10:02] <wgrant> deb_bpph.supersede() should also supersede the corresponding ddeb.
[10:03] <bigjools> yes
[10:03] <wgrant> This is to handle the case that a package ceases to produce a ddeb.
[10:03] <wgrant> But what if it doesn't cease to produce it?
[10:03] <wgrant> Hmm.
[10:03] <wgrant> I guess it should be safe as long as we only look within the build.
[10:04] <wgrant> Yeah, I guess that will work.
[10:04] <bigjools> I don't quite follow this case
[10:05] <wgrant> I wasn't thinking properly. There is no problem.
[10:05] <bigjools> ok :)
[10:05] <wgrant> It is guessing, but very safely.
[10:05] <bigjools> if we assume the publisher will deal with old publications, taking the most recent one is always safe
[10:06] <wgrant> Right. I had forgotten about other restrictions on the search.
[10:07] <wgrant> Maybe it's not safe. How I hate guessing.
[10:08] <wgrant> I have a deb and ddeb, both with Published publications. I promote them, giving them a new Pending publication each.
[10:08] <wgrant> The publisher runs.
[10:08] <wgrant> It sees that the deb is superseded, and calls deb_bpph.supersede()
[10:08] <wgrant> The Pending ddeb publication screams and dies.
[10:08] <wgrant> This is not correct behaviour.
[10:09] <wgrant> s/deb_bpph/deb_old_bpph/
[10:10] <jml> bigjools, are there docs anywhere describing how the buildmaster works?
[10:10] <wgrant> Ha ha ha.
[10:10] <wgrant> jml, this is Soyuz.
[10:10] <bigjools> ROFL
[10:11] <jml> fair point.
[10:11] <noodles775> buildd-dispatching.txt ?
[10:11] <jml> wgrant, do _you_ have docs describing how the buildmaster works?
[10:11] <bigjools> thge buildmaster was oringally hacked up by the early LP devs (daniel etc) and more recently re-written by Celso in a hurry
[10:11] <bigjools> yes, the doctest is the closest we have
[10:11] <wgrant> jml: Although I know it internally fairly well now, I only have docs on how to run it.
[10:11] <jml> yeah, I remember him being in a hurry. :)
[10:12] <bigjools> when wasn't he? :)
[10:13] <bigjools> jml we have a plan on how to generalise the buildmaster side but it was written before the re-write of the scanner
[10:13] <wgrant> bigjools: Any ideas on the above example?
[10:13]  * bigjools missed that, just a sec
[10:13] <jml> bigjools, is the plan written down?
[10:13] <wgrant> https://dev.launchpad.net/Soyuz/Specs/BuilddGeneralisation
[10:13] <jml> I might have a poke around the code once I do today's CHR duties & finish off this damn imports branch and review al-maisan's branch.
[10:13] <jml> I guess that means tomorrow.
[10:14] <jml> wgrant, thanks.
[10:14] <bigjools> wgrant: why would it scream and die?
[10:14] <maxb>     <wadl:method name="PUT" id="HostedFile-put"/>
[10:14] <maxb>     <wadl:method name="DELETE" id="HostedFile-put"/>
[10:14] <maxb> ^ Well, oops :-)
[10:15] <wgrant> bigjools: Because it has the latest ID, so gets superseded.
[10:15] <bigjools> jml: the code is pretty bad, most of it was written before we had real coding standards.  Feel free to hassle me to explain stuff.
[10:15]  * al-maisan takes a peek at lp:~jml/launchpad/upload-permission-joy
[10:16] <bigjools> wgrant: ok I see
[10:18] <bigjools> wgrant: if the last publication is pending then it should be clever enough to go to the previous one
[10:19] <wgrant> bigjools: This is getting more and more into inaccurate guess territory, and sounds like it will go horribly wrong if there are multiple pending publications at once.
[10:19] <jml> bigjools, I remember someone asking me for a generic sftp server based on the one we have in codehosting...
[10:19] <maxb> I'd like one of those too :-)
[10:19] <jml> bigjools, I guess that's for a different thing
[10:20] <bigjools> jml: yeah we could do with replacing poppy
[10:20] <jml> maxb, remind me to actually put license text in txsshserver one of these days.
[10:21] <bigjools> wgrant: there is already code like this in the publisher
[10:21] <maxb> jml: Your verification of the xx-wadl.txt failure was on jaunty/karmic? py2.4?
[10:21] <bigjools> wgrant: I suggest we try and map out all of the operations that can happen like this, and work through them carefully
[10:22] <jml> maxb, karmic.
[10:22] <jml> maxb, ./bin/test -1cvvt xx-wadl.txt in stable branch
[10:23]  * maxb wonders if this is a mysterious jaunty vs. karmic oddity
[10:23] <jml> maxb, I'm deleting the unversioned files in lib/canonical/launchpad/apidoc and running the test again.
[10:23] <maxb> jml: the wadl tested in the test is generated on the fly
[10:24] <jml> maxb, ... as my experiment just demonstrated :)
[10:25] <maxb> I'll have to dig out a jaunty system and retest there
[10:27]  * bigjools laughs a lot at https://answers.launchpad.net/soyuz/+question/85773
[10:29] <bigjools> jml --^
[10:33] <maxb> How does the wadl generation actually work? There is stuff in the comments in the wadl which I don't find by grepping anywhere in the source?!
[10:36] <jml> bigjools, heh heh.
[10:36] <jml> bigjools, what's the blueprint URL?
[10:36] <wgrant> maxb: Possibly stuff in lazr.restful(client)?
[10:36] <bigjools> jml: I haven't done one yet, I will sort it out soon
[10:38] <jml> bigjools, no worries.
[10:38] <bigjools> jml: I cleaned up the buildd manager one yesterday as that's more important to me right now :)
[10:39] <maxb> Hmm... looks like the bugged wadl is copied verbatim from wadl-root.py in lazr.restful
[10:39] <jml> bigjools, ahh sure.
[10:39] <jml> bigjools, I can just register the blueprint and link it to the already-written spec
[10:40] <bigjools> jml: I can do it, it's on my list of things to do anyway
[10:41] <jml> bigjools, ok.
[10:41]  * jml would really love to scrub the launchpad-code blueprints at some point
[10:41] <jmux> Hi - is there a good way to debug traversal errors? I'm getting a backtrace from base-layout-macros.pt for "json" and I didn't really find a way to find the original error.
[10:43] <jml> hmm
[10:43] <jml> jmux, nothing leaps to mind.
[10:43] <jml> https://dev.launchpad.net/Debugging might help.
[10:44] <maxb> eww. lazr.restful has no tags :-(
[10:44] <james_w> does logger.exception in LP log sys.exc_info() or similar?
[10:45] <jml> james_w, it really depends.
[10:46] <james_w> 258	+ except:
[10:46] <james_w> 259	+ ok = False
[10:46] <james_w> 260	+ self.logger.exception(
[10:46] <james_w> 261	+ "Unexpected error checking %s!", db_branch)
[10:46] <jml> james_w, that behaviour comes standard in Python :)
[10:46] <james_w> I'd like to know that this logs the exception, otherwise we are going to be scratching our heads when something goes wrong
[10:46] <jml> james_w, http://www.python.org/doc/2.4.4/lib/node341.html
[10:47] <james_w> ah, so it does
[10:47] <wgrant> eg. try to catch an exception and call logging.exception("blah")
[10:47] <jml> james_w, I'll need more context
[10:47] <james_w> thanks, will be useful in future
[10:47] <jml> james_w, because it's the log _handlers_ that really make the difference
[10:47] <james_w> I'm looking at https://code.edge.launchpad.net/~mwhudson/launchpad/branching-ubuntu/+merge/13269
[10:47] <james_w> def checkNewBranches(self):
[10:48] <james_w> so in this case logger comes from LaunchpadScript
[10:49] <jml> james_w, which in turn uses canonical.launchpad.scripts.logger.logger
[10:49] <jml> james_w, which uses a default Python StreamHandler
[10:50] <jml> which is fine.
[10:51] <james_w> cool, thanks for checking
[10:52] <jml> np
[10:52] <jml> thanks for asking :)
[11:12] <wgrant> bigjools: http://williamgrant.id.au/f/1/2009/ddeb-supersedure-cases.html describes most supersedure cases, I think.
[11:15] <bigjools> wgrant: ok, thanks, I'll look through it in a bit
[12:37] <jml> bigjools, the buildd-generalizing spec is for running arbitrary jobs, right
[12:37] <bigjools> jml: yes
[12:38] <jml> bigjools, is there another spec for generalizing across machine type? (physical machine, local vm, ec2 instance etc)
[12:38] <bigjools> there's a bug
[12:38] <bigjools> well
[12:39] <bigjools> there's a bug for building any type of arch/virtual on the existing builders
[12:39] <bigjools> there's no spec for going as far as what you say there
[12:39] <jml> ok, thanks.
[12:40] <bigjools> which I think is slightly crazy BTW :)
[12:40] <jml> perhaps it is.
[12:41] <jml> what I'm actually worried about is build capacity
[12:41] <bigjools> yes, me too
[12:41] <jml> s/worried/thinking/
[12:41] <bigjools> we'll need a lot more builders
[12:41] <jml> yeah.
[12:41] <bigjools> we'll also need some more optimisation done to the buildd-manager
[12:41] <bigjools> because finished builds are uploaded synchronously
[12:42] <jml> oh right, I remember talking to cprov about that.
[12:42] <bigjools> it's a very hard problem to solve
[12:42] <elmo> err, why?
[12:42] <bigjools> error conditions mainly
[12:43] <bigjools> I forgot the exact details
[12:43] <elmo> mmk
[12:43] <elmo> I may be overlooking something, but Debian has done uploads asynchronously for over a decade
[12:43] <jml> bigjools, ISTR it as more being a case of getting round to it.
[12:44] <bigjools> well don't let me stop you fixing the buildd-manager then ;)
[12:44] <elmo> it just means the extra section of the state machine where a package can be either 'uploaded' or 'installed' (i.e. the upload completed successfully) and you just have to make sure nothing stays in 'uploaded' for overly long
[12:44] <elmo> also, why are we worried about capacity?
[12:44] <bigjools> ah I remember more about this now
[12:44] <jml> dammit. etsu lunch again.
[12:44] <bigjools> the upload processor is single-threaded
[12:44] <wgrant> But it's run in a subprocess.
[12:45] <bigjools> with a lock
[12:45] <wgrant> Oh. Right.
[12:45] <bigjools> and no, it's not a subprocess when uploading binaries
[12:45] <wgrant> Then why does the builddmaster have a config option for the command to run to upload the binaries?
[12:45] <bigjools> NFI
[12:46] <wgrant> It spawns process-upload.py.
[12:46] <wgrant> This is why it takes /forever/.
[12:46] <bigjools> hmmm last time I looked it didn't do that
[12:47] <bigjools> but anyway, it's still has a bunch of issues that prevent it running more than one copy at once
[12:47] <jml> I am full of unhappiness and empty of food.
[12:47] <jml> brb.
[12:47] <bigjools> and there are other issues with the buildd-manager just dumping the binary in an upload queue - for example how to deal with upload failures
[12:47] <wgrant> bigjools: lp.buildmaster.buildergroup.BuilderGroup.buildStatus_OK certainly seems to spawn a subprocess.
[12:54] <jml> bigjools, how do you deal with them now?
[12:54] <bigjools> it marks the build as failed
[12:56] <jml> bigjools, I see.
[12:56] <bigjools> which the upload processor can't do, since it doesn't know about the build
[12:57] <wgrant> It does, actually.
[12:57] <jml> bigjools, you could write the builder asynchronously
[12:57] <wgrant> The upload processor sets the build to Successfully Built, and attaches the binaries.
[12:57] <wgrant> If it completes successfully, the buildmaster attaches the build log, sets the finish time, unassigns the builder, deletes the buildqueue.
[12:58] <wgrant> If it fails, it attaches the upload log and marks the build as Failed to Upload.
[12:58] <wgrant> But the upload processor does (and has to) know about the build.
[13:11] <bigjools> wgrant: of course, you're right.  I think I need more coffee.
[14:33] <sinzui> EdwinGrubbs: barry: bac: standup in two minutes
[14:39] <EdwinGrubbs> sinzui: standup?
[14:55] <barry> reviewers, interested developers, and lurkers: ameu reviewers meeting -> #launchpad-meeting in 5m
[15:00] <barry> ameu reviewers meeting -> #launchpad-meeting
[15:04] <barry> abentley: -> #launchpad-meeting.  i'm about to talk about pipelines :)
[15:48] <Fox_1_> hi all
[15:49] <Fox_1_> people do you know the place where I can get documentation about putting Launchpad on Debian
[15:49] <Fox_1_> ?
[16:00] <sinzui> Fox_1_: you are in unexplored territory. I am not aware is has been done, let alone documented
[16:01] <sinzui> bac: ready for our call?
[16:01] <bac> yes
[16:46] <jml> leonardr, were you making a trusted client for the API?
[16:46] <leonardr> jml: yes, it is on my list of things to do, but pretty far down the list
[16:46] <leonardr> i can point you to the bug if you want to take over
[16:47] <jml> leonardr, what if I don't want to take over but just want to leer speculatively, one day dreaming of having enough time to want to take over?
[16:48] <leonardr> i think pointing you to the bug would still be appropriate
[16:48] <leonardr> it might not be as difficult as you think, i did write the client, i just didn't write the tests for it
[16:48] <jml> heh.
[16:49] <jml> leonardr, in that case, please point me to the bug report.
[16:49] <jml> I'm actually planning on working with launchpadlib on Canonical time during the Bazaar sprint in November.
[16:49] <jml> so I might do trusted client work on the plane or something. maybe.
[16:52] <leonardr> jml: https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/387297
[16:52] <mup> Bug #387297: manage-credentials should not ask for Launchpad password directly <ubuntu-dev-tools (Ubuntu):Triaged> <https://launchpad.net/bugs/387297>
[16:52] <ubot3`> Malone bug 387297 in ubuntu-dev-tools "manage-credentials should not ask for Launchpad password directly" [Medium,Triaged]
[16:52] <leonardr> https://code.launchpad.net/~leonardr/launchpadlib/trusted-client
[16:52] <mup> Bug #387297: manage-credentials should not ask for Launchpad password directly <ubuntu-dev-tools (Ubuntu):Triaged> <https://launchpad.net/bugs/387297>
[16:53] <jml> I thought we asked ubot3 to leave. :(
[16:53] <jml> leonardr, thanks.
[17:06] <intellectronica> bigjools: halp. i don't know anything about upload permissions. can you give me some pointers? do you know how the driver permission for a distroseries is calculated?
[17:06] <bigjools> intellectronica: I don't know that, I only know about upload permissions
[17:08] <jml> intellectronica, for a distroseries?
[17:08] <jml> hm
[17:08] <jml> wait. I'm focusing.
[17:08] <intellectronica> jml: nm, i think i just found out
[17:08] <jml> intellectronica, glad to hear it.
[18:04] <mrevell> night all
[19:21] <barry> danilos: ping
[19:27] <Ursinha> barry: danilos is ill today, and it's pretty late for him, I don't think he'll answer in a reasonable time :)
[19:28] <barry> Ursinha: okay, thanks.  danilos hope you feel better soon!
[21:05]  * jgay attempts to install launchpad. 
[21:10] <jgay> Does anybody know if I will likely get a successful build and install on intrepid?
[21:11] <mwhudson> jgay: unlikely
[21:11] <mwhudson> jgay: nothing fundamental, but some of the packages needed haven't been built for intrepid i think
[21:12] <jgay> mwhudson: ok, thanks. I'll see how far I get before things start to breakdown.
[21:16] <rockstar> mwhudson, abentley, who's hosting today?
[21:16] <mwhudson> rockstar: good question!
[21:16] <rockstar> mwhudson, would you like me to?
[21:16] <abentley> rockstar: Go for it.
[21:16] <mwhudson> rockstar: sure
[21:30] <rockstar> The windmill tests don't run concurrently as threads, do they?
[21:41] <barry> rockstar, mwhudson thumper's off line today.  do you still want to meet today?
[21:41] <rockstar> barry, yeah, abentley said today was pretty exciting.
[21:41] <barry> rockstar: okay cool.  i'll update the minutes and we can meet in 19m
[21:42] <rockstar> barry, ack
[21:42] <mwhudson> barry: ok
[22:01] <barry> rockstar, mwhudson, wgrant  -> #launchpad-meeting
[22:12]  * rockstar goes on a short walk
[22:50] <wgrant> intellectronica: jml refactored the upload permission stuff recently, so it should be pretty easy to remove the duplicated logic from the bug nomination permissions.