[00:44] <jml> mwhudson_, you around?
[00:44] <mwhudson_> jml: yeah
[00:44] <jml> mwhudson_, I'd like to bounce an idea off you
[00:44] <mwhudson_> jml: listening to rusty be silly
[00:44] <mwhudson_> jml: ok
[00:45] <jml> mwhudson_, I want to make launchpad use subunit trunk
[00:45] <jml> mwhudson_, but it's in 2a and ours is in 1.6 or something
[00:45] <mwhudson_> jml: gragh
[00:45] <jml> mwhudson_, if I make update-sourcecode just blow away old versions in the case of format errors?
[00:46] <mwhudson_> jml: talk to spm i guess
[00:46] <jml> mwhudson_, will that work on production?
[00:46] <jml> or will I need to talk to spm
[00:46] <jml> hmm.
[00:46] <spm> jml: ?
[00:46] <jml> spm,  I want to make launchpad use subunit trunk
[00:46] <mwhudson_> spm: i think deployment doesn't use update-sourcecode
[00:46] <jml> spm, but it's in 2a and ours is in 1.6 or something
[00:46] <jml> spm, which means a simple 'pull' won't work.
[00:46] <spm> oh yukness
[00:47] <spm> yeah...
[00:47] <jml> (thanks bzr!)
[00:48] <jml> spm, so what should I do?
[00:48] <spm> jml: how urgent is this? ie MUST be in the release next week?
[00:49] <jml> spm, no, it's entirely optional.
[00:50] <spm> jml: oki; I'd submit an RT asking for the branch we use to be upgraded RSN, such that when you push - stuff should "just work"; tho it'd be nice is bzr did that for us automagically (dig dig dig)
[00:50] <spm> we may need to verify what/where that branch is etc. but that's details you don't need to worry about.
[00:51] <jml> spm, well, I'd also like us to use a different branch. I'm not entirely sure why we have our own pqm-managed fork of subunit anyway
[00:51] <spm> Ah. that gets mildly more complicated - will need to config-manager update - you should be able to fix that one yourself. the branch in Q is open to ya'll
[00:52] <spm> well - partially fix - we still need to fix our local copy of.
[00:52] <jml> hmm. hmm. hmm.
[00:52] <jml> this is all too hard.
[00:52] <spm> welcome to our world! :-)
[00:52] <jml> I'm going to trick gary into walking me through making this an egg.
[00:52] <mwhudson_> why is that hard?
[00:52] <jml> mwhudson_, subunit uses autotools!
[00:53] <jml> yay
[00:53] <mwhudson_> oh riiiiiiiiiight
[00:53] <mwhudson_> yay indeed
[00:54] <spm> ??? why is that hard? isn't the idea of autotools to make this stuff easy?
[00:54] <wgrant> jml: Do you think we can reasonably get bug #507751 done this release?
[00:54] <mup> Bug #507751: New ISourcePackageRecipeBuild fields <wellington> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/507751>
[00:54] <wgrant> spm: Not for making eggs...
[00:54] <jml> spm, and the idea of eggs is that they also make this stuff easy
[00:54] <jml> spm, but in a completely different way!
[00:55] <spm> oh yay. more wheel reinventions. lovely.
[00:55] <ajmitch> only the tip of the iceberg
[00:55] <jml> wgrant, I'm not going to do it.
[00:56] <jml> wgrant, but there's probably time if someone were keen. :)
[00:56] <wgrant> jml: It's trivial except for the contention around SourcePackageRecipeBuildJobUpload.
[00:56] <wgrant> bigjools thinks that it should exist.
[00:56] <wgrant> I don't think anybody else does.
[00:58] <jml> wgrant, well, I'm basically reserving my opinions until I can see the whole thing.
[01:01] <wgrant> jml: What whole thing?
[01:01] <jml> wgrant, "building stuff on the build farm"
[01:01] <jml> wgrant, that thing. :)
[01:01] <wgrant> An explanation of everything?
[01:01] <jml> wgrant, yeah, but more just having the whole thing in my head. (which probably is going to require me writing a doc).
[01:02] <wgrant> Possibly.
[01:02] <wgrant> But it would be nice to not have to land everything on db-devel next cycle.
[01:03] <jml> wgrant, sure. so just do things the way bigjools says, and then we can fix it the cycle after next  :)
[01:04] <wgrant> It's unclear how the bigjools model is meant to work.
[01:04] <jml> wgrant, ahh, I see.
[01:05] <wgrant> Basically, we currently don't use the SPRBJUpload at all. It is there so you can upload the result of one build to multiple archives.
[01:05] <wgrant> Rather than copying from one archive to the rest.
[01:05] <jml> oh right.
[01:06] <wgrant> It is not clear that uploading it to multiple places is going to work, has many useful applications, or is better than copying.
[01:06] <wgrant> It's also much harder, both UI- and code-wise.
[01:07] <jml> indeed.
[01:07] <jml> OK, I'm going to call yagni on this.
[01:08] <jml> let's worry about SPRBJUpload when we have a use-case
[01:08] <wgrant> Right.
[01:08] <wgrant> We can easily migrate to it later if we need.
[01:08] <jml> yeah.
[01:09]  * wgrant JFDIs.
[01:13] <mwhudson> heh
[01:13] <mwhudson> i tried to call yagni way back when
[01:14] <jml> mwhudson, sorry, I should have listened harder.
[01:15] <mwhudson> np
[01:15] <jml> hmm.
[01:16] <jml> can I somehow get subunit trunk into pack-0.92 so I can just pqm-submit this change?
[01:16] <wgrant> Doesn't the rich root barrier make that impossible?
[01:16] <jml> yeah, it looks like it
[01:17] <wgrant> Hmm, I see that process-upload.py doesn't actually link the produced SourcePackageRelease to the SourcePackageRecipeBuild :(
[01:18] <jml> huh what?
[01:18] <jml> that sucks.
[01:19] <wgrant> It's unclear how that would best be done (link on the PackageUpload, or the PackageUploadSoure, or the SPRelease, or the SPRB).
[01:20] <wgrant> But that can be fixed laaaater.
[01:33] <wgrant> mwhudson: Do you happen to know why SourcePackageRecipeData has a reference back to SourcePackageRecipe, rather than the other way around?
[01:33] <jml> wgrant, what are the issues?
[01:33] <mwhudson> sourcepackagerelease has a sourcepackagebuild column now
[01:33] <wgrant> jml: Nothing. It just seems like a very strange way of doing things.
[01:34] <mwhudson> wgrant: you can write more useful constraints that way around
[01:34] <wgrant> mwhudson: Oh, so it does.
[01:34] <jml> oh sorry, I must have missed something
[01:34] <jml> carry on.
[01:34] <mwhudson> (stub made me do it)
[01:34] <wgrant> mwhudson: OK.
[03:48] <jml> wgrant, I'm looking at ec2test-remote.py
[03:48] <jml> wgrant, which is the thing that would have to be screwing up in order for the emails to not be sent.
[03:49] <wgrant> jml: You didn't get an email for this one either?
[03:49] <jml> wgrant, which one?
[03:50] <jml> wgrant, I'm looking at the code trying to make it attach a subunit log to the mails it sends.
[03:50] <wgrant> jml: The one that landed late last night.
[03:50] <jml> wgrant, no, I didn't.
[03:50] <wgrant> Aha.
[03:52] <wgrant> jml: There are conflicts between your branch and db-devel again.
[03:52] <jml> fuck
[03:52] <wgrant> And you should probably revert the move of BuildBase.build_log_url
[03:52] <jml> why
[03:53] <wgrant> Because it is really implemented on BuildBase now.
[03:53] <wgrant> (and it will be used by view code RSN)
[03:54] <jml> wgrant, ok.
[03:55] <jml> I'm very angry that the delay in reviewing my branch has caused me to do all of this work that would have been unnecessary were it reviewed promptly.
[03:55] <jml> Sadly, I don't think I can fairly direct this anger to any one person.
[03:55] <jml> (or even any set of people)
[03:55] <mwhudson> it's society that's to blame!
[03:55] <rockstar> mwhudson, do you have a second?
[03:56] <mwhudson> rockstar: yes
[03:56] <rockstar> mwhudson, this is my test: http://pastebin.ubuntu.com/360426/
[03:57] <mwhudson> rockstar: ok
[03:57]  * wgrant finds more gaps in the implementation.
[03:57] <rockstar> The only change that has occurred is the contextManager calling get_scanner_server instead of get_multi_server - When I create the branch and pdb into it, it reports as lp-mirrored:///blah but when I actually try and run the job, I get an NotABranch oops.
[03:58] <rockstar> mwhudson, I'm not sure where the disconnect is.
[03:59] <mwhudson> rockstar: which url does the BranchScanJob try to open?
[03:59] <rockstar> mwhudson, I'm assuming the lp-mirrored one, since that's what oopses on the NotABranch error.
[03:59] <mwhudson> hm
[04:00] <rockstar> The BranchScanJob basically just instantiates a BzrSync instance with the db branch instance as it's only argument.
[04:00] <mwhudson> oh
[04:00] <mwhudson> i have memories of terrible things marching out of my hind brain
[04:00] <rockstar> mwhudson, that makes me sad.
[04:00] <mwhudson> rockstar: can you check config.codehosting.internal_branch_by_id_root in the test?
[04:01] <rockstar> Sure, one sec.
[04:03] <mwhudson> rockstar: i think it will be file:///var/tmp/bzrsync/
[04:03] <rockstar> mwhudson, yeah, I seem to remember seeing an error like that as well.
[04:03] <rockstar> file:///var/tmp/bzrsync/
[04:04] <mwhudson> rockstar: try changing it to file:///var/tmp/bazaar.launchpad.dev/mirrors ?
[04:08] <rockstar> mwhudson, this is where I do the config pushing stuff, right?
[04:08] <mwhudson> rockstar: i'd just change it in lib/configs/testrunner/launchpad-lazr.conf
[04:08] <rockstar> mwhudson, okay.
[04:11] <rockstar> mwhudson, that worked.
[04:11] <mwhudson> rockstar: yay
[04:11] <rockstar> I have no idea why it worked, but it did.
[04:11] <mwhudson> rockstar: oh
[04:11] <mwhudson> rockstar: i can explain the details i guess, but then you'll want to kill yourself
[04:12] <mwhudson> rockstar: run the lp.codehosting.test.test_rewrite tests, they might need updating
[04:15] <rockstar> mwhudson, okay.
[04:17] <rockstar> mwhudson, so is this a permanent config change?
[04:18] <mwhudson> rockstar: i think it causes a small decrease in overall insanity
[04:19] <rockstar> mwhudson, okay.
[07:39] <nigel_nb> barry, ping
[07:40] <nigel_nb> I'm looking for some guidance with launchpadlib with regard to connecting the subscribers/commentors of a bug with the bug
[07:56] <nigel_nb> flacoste, got a minute?
[09:13] <mrevell> hi
[09:14] <nigel_nb> hi mrevell
[09:23] <nigel_nb> mrevell, do you have a min? I have a doubt in launchpad lib
[09:24] <mrevell> Hi nigel_nb, I'm probably not the best person to help with launchpad_lib. But let's talk and, if I can't help directly, I'll find someone who can :)
[09:24] <nigel_nb> mrevell, I have been struggling for the past 3 hours
[09:25] <nigel_nb> I'm trying to build a script that will list all the bugs that I have commented or subscribed and are incomplete
[09:25] <nigel_nb> I have a sort of beginning point here http://paste.ubuntu.com/360520/
[09:25] <nigel_nb> I dont know how to search all ubuntu bugs, i.e., all bugs in a distribution
[09:26] <nigel_nb> I've been playing with launchpad.distributions['ubuntu'].searchTasks
[09:26] <nigel_nb> but it just prints and object and I dont know how to actually perform a search... any clue?
[09:27] <wgrant> launchpad.distributions['ubuntu'].searchTasks(bug_subscriber=launchpad.me, status='Incomplete')
[09:27] <nigel_nb> wgrant, thank you!
[09:28] <wgrant> Actually, you might need status=['Incomplete'], but one of those should work.
[09:28] <nigel_nb> so how does searchtasks work?
[09:29] <nigel_nb> you use ( bracks and then sub-criteria inside '['?
[09:31] <bigjools> jml: still there?
[09:33] <wgrant> bigjools: He's probably still at the Penguin Dinner or associated events.
[09:33] <wgrant> nigel_nb: The parentheses are just Python function call syntax.
[09:33]  * bigjools boggles at what a penguin dinner could be
[09:34] <wgrant> bigjools: The final dinner for professional LCA delegates.
[09:34] <bigjools> ah so they're not eating penguins
[09:34] <wgrant> Sadly not.
[09:35] <nigel_nb> wgrant, oh okay.  I've ben wondering how to pass args to searchTasks :)
[09:35]  * nigel_nb high fi's wgrant :)
[09:47] <wgrant> bigjools: Do you still feel strongly that we want SPRBUpload?
[09:47] <bigjools> yes
[09:47] <wgrant> Argh.
[09:47] <wgrant> I discussed it with jml earlier.
[09:47] <wgrant> And he seems to think that we don't.
[09:47] <bigjools> it has parallels with PackageUpload
[09:49] <wgrant> Why do we want that?
[09:49] <wgrant> Binaries have nothing like it.
[09:50] <bigjools> PackageUploadBuild ...
[09:50] <wgrant> And PackageUploadSource.
[09:50] <wgrant> PackageUpload(Build|Source) just tie things together.
[09:51] <wgrant> They serve a different purpose from SPRBU
[09:51] <bigjools> true
[09:51] <bigjools> but I want it to stay
[09:51] <bigjools> because from experience I just know that in the future we'll be doing more with this stuff
[09:51] <wgrant> Why would we ever want to do that rather than copy?
[09:52] <wgrant> You say that copying is bad, but I haven't seen a concrete reason.
[09:52] <bigjools> I didn't say that at all
[09:52] <bigjools> I said I wanted to retain options
[09:53] <wgrant> Hmmm.
[09:54] <wgrant> Have you ever had a similar need for binary uploads to multiple places?
[09:54] <wgrant> What do SPRBUs mean?
[09:54] <wgrant> How on earth does this make it into the UI?
[09:55] <wgrant> Isn't it going to be easier to split the data out later rather than try to badly wire in this ill-defined concept now?
[09:56] <bigjools> uploading is an orthogonal action to building, conflating the two in the model is ridiculous
[09:57] <bigjools> and not everything needs a direct UI mapping
[09:57] <wgrant> It's barely orthogonal.
[09:57] <wgrant> A build finishes by uploading.
[09:57] <wgrant> There is no such thing as a non-volatile un-uploaded build result.
[10:02] <wgrant> The upload is represented by the PackageUpload.
[10:11] <bigjools> wgrant: so explain to me what the problem is right now with having the table?
[10:13] <wgrant> bigjools: We must either start using it now, and therefore work out what it actually means, or we need to put some of its columns on SPRB.
[10:14] <bigjools> so there's no problem as such, it's a philosophical issue?
[10:15] <wgrant> It is a problem, in that the code needs one of those solutions nowish. The second solution will probably not be accepted whilst SPRBU still exists, and the first means working an over-complicated data model into code that cannot handle it and probably never will.
[10:17] <bigjools> "over-complicated data model" is an opinion.  Why "code that cannot handle it" ?
[10:18] <wgrant> There has been no use-case given for this model, AFAICT. The code will need quite some work to support uploading to multiple places.
[10:19] <wgrant> And the migration from the everything-in-SPRB model to the SPRBU model is near-trivial, if somebody eventually desires to implement it.
[10:20] <wgrant> So involving SPRBU is probably unnecessary complexity.
[10:24] <bigjools> well there is a use case :)
[10:25] <wgrant> Is there?
[10:25] <bigjools> bug 235064 to some extent and bug 245594
[10:25] <mup> Bug #235064: Implement multi-release support for packages <ppa> <soyuz-upload> <Soyuz:Triaged by cprov> <https://launchpad.net/bugs/235064>
[10:25] <mup> Bug #245594: Rebuilds of binary packages without source changes <feature> <motu> <Soyuz:Triaged> <https://launchpad.net/bugs/245594>
[10:25] <bigjools> it's not a complete solution but it would be one way
[10:25] <bigjools> however
[10:25] <wgrant> I don't think that's a reasonable solution (even partial) to either.
[10:26] <bigjools> it's not a solution
[10:26] <bigjools> it's a model
[10:26] <bigjools> that would support a solution
[10:26] <wgrant> I don't see what it has to do with either.
[10:27] <bigjools> https://bugs.edge.launchpad.net/soyuz/+bug/245594/comments/5
[10:27] <mup> Bug #245594: Rebuilds of binary packages without source changes <feature> <motu> <Soyuz:Triaged> <https://launchpad.net/bugs/245594>
[10:27] <wgrant> We need to either change the source version, or do a binNMU and just change the binary version.
[10:27] <wgrant> Neither situation is helped by allowing multiple uploads of the same source.
[10:27]  * wgrant reads.
[10:28] <wgrant> Right, that's the first solution.
[10:28] <wgrant> And since it involves changing the source, and thus a new SPRB, multiple SPRBUs are not useful here.
[10:29] <bigjools> well, again, it depends how it's done
[10:30] <wgrant> And since we don't know how it is going to work, I don't think we should be unnecessarily complicating the model in ways that might not assist, and even if they do will still need alteration.
[10:31] <bigjools> you seem to feel strongly about it
[10:31] <bigjools> so I will talk more with jml when he's back
[10:34] <wgrant> Not a bad idea, although he probably won't be around for a couple of days.
[10:35] <bigjools> well, that's the weekend then :)
[10:35] <wgrant> True.
[10:36]  * bigjools is going to an FA Cup game tomorrow
[11:14] <bigjools> wgrant: so that build has no Job row
[11:14] <bigjools> err BQ row
[11:14] <wgrant> It must.
[11:14] <wgrant> It has two builders.
[11:14] <wgrant> And it is being repeatedly dispatched.
[11:15] <wgrant> And it had a logtail, which is stored on buildqueue.
[11:15] <wgrant> Although it is all gone now. Was it superseded deliberately?
[11:16] <bigjools> nope
[11:18] <bigjools> it's gone because he uploaded a new one, darn
[11:18] <bigjools> which explains the lack of BQ
[11:18] <wgrant> There wasn't a DB dump in the meantime that will land on staging tomorrow?
[11:19] <wgrant> There was a > 7 hour window.
[11:19] <bigjools> stub, what time is the dump for staging done?
[11:19] <wgrant> You've confirmed that cesium is still appropriately patched?
[11:19] <bigjools> yes it us
[11:19] <wgrant> Arrrrrgh.
[11:20] <bigjools> there's a weirdo in the data I did see. one sec
[11:20] <bigjools> http://pastebin.ubuntu.com/360597/
[11:21] <stub> bigjools: Finishes on wildcherry about 05:30 UTC
[11:22] <bigjools> stub: ah cool
[11:22] <stub> Starts at 0100 UTC if that is what you are asking
[11:22] <wgrant> How long does it take?
[11:22] <wgrant> Ah.
[11:22] <wgrant> It will have probably just been too early :(
[11:22]  * bigjools looks
[11:22] <bigjools> yeah it's not there
[13:37] <mars> BjornT or mrevell, around?  Did you have a chance to try that patch?
[13:38] <mrevell> mars, I merged from RF again and the test-suite passed for me last night.
[13:38] <mars> mrevell, \o/
[13:38] <mrevell> :) Just need PQM to come out of RC mode now :)
[13:39] <mars> I wonder if rockstar's branch merged my patch?
[13:40] <mars> no, it did not get merged
[13:56] <bac> sinzui: monring
[13:57] <bac> sinzui: that's apropos...
[14:20] <flacoste> nigel_nb: i have now
[14:26] <jml> hello
[14:26] <jml> db-devel has been broken by a bugs test.
[14:27] <jml> anyone fixing it?
[14:27] <flacoste> jml: seems that no one fixed it yet
[14:28] <flacoste> jml: stub reported the failure, but didn't claim he was fixing it, and there was no [testfix] landing
[14:29] <jml> flacoste, ok, thanks.
[14:29] <jml> flacoste, my taxi arrives in 15 mins, so I probably shouldn't start fixing it.
[14:29] <jml> but I really want to land this branch. :\
[14:30] <jml> maybe when I get to Sydney.
[14:31]  * jml is off.
[15:05] <sinzui> bac: Here is some info about hacking the button slot in a form: http://pastebin.ubuntu.com/360696/
[15:18] <bac> thanks sinzui
[15:25] <intellectronica> sorry everyone for the db_lp failure. not quite sure how that happened, fixing now
[15:35] <rockstar> BjornT, yes, I merged your branch into mine, landed it.
[15:36] <rockstar> Er, mars ^^
[15:37] <mars> rockstar, ok. I have an emergency fix to land then :)
[15:37] <rockstar> mars, oh?
[15:38] <mars> rockstar, yep, check line 826 of https://code.edge.launchpad.net/~mars/launchpad/unroll-mochikit/+merge/17870
[15:39] <mars> (we should link those diff line numbers)
[15:39] <mars> rockstar, missing 'replace="nothing"', so the comment shows up on every page as a result.
[15:39] <rockstar> mars, ah.  Well, the fix is only on db-devel.
[15:39] <mars> for now, yes :)
[15:40] <rockstar> I thought that with a risky patch like that, we probably want to test it a lot.
[15:40] <mars> yep.  wait, rockstar, db-devel only?  Not devel?
[15:40] <rockstar> mars, well, after today, we'll only be merging into db-devel.
[15:40] <rockstar> mars, yes, only db-devel.
[15:40] <mars> ok
[15:40] <mars> so, was staging updated...
[15:40] <mars> nope
[15:42] <rockstar> mars, yeah, I tried to get it updated, but it ended up being really complicated.
[15:43] <sinzui> EdwinGrubbs: how goes your packaging branch and secured vocab fix?
[15:45] <EdwinGrubbs> sinzui: I'm getting pretty close with the vocab fix.
[15:45] <sinzui> I will review it. We appear to be missing reviewers
[15:45] <sinzui> I think I will do some reviews instead of start a new branch to give some people a chance to land their work
[15:47] <rockstar> mars, db-devel 8911 is where your patch is at.
[15:47] <mars> rockstar, ok, thanks
[15:48] <dobey> hey all
[15:49] <mars> hey dobey
[15:49] <dobey> do the unit tests for lp use mechanize and the zope testbrowser stuff, and alter the User-Agent to test output changes?
[15:50] <mars> gary_poster, the Zope wizard, ^ ?
[15:51] <gary_poster> dobey: yes to the first half, not sure to the second.
[15:54] <dobey> hrmm. i'm wondering, because i'm trying to implement some user-agent dependent code in u1, and the "documented" way to do it doesn't seem to be working for me :-/
[15:56] <mars> rockstar, care to review this patch? https://code.edge.launchpad.net/~mars/launchpad/unroll-mochikit-patch-hardening/+merge/17894
[15:56] <gary_poster> dobey, I've dug pretty deep in there in the past but I'm afraid I don't have the knowledge at hand.  One thing that has made a big difference in the past for edge-case usages is to make sure you have the newest versions of testbrowser and mechanize, but you may already be up-to-date, and it might not make a diff.  If you send me an isolated example I can try to take a look at it today
[15:57] <rockstar> mars, r=rockstar
[15:57] <mars> rockstar, thanks
[15:58] <mars> rockstar, any special flags needed to land on db-devel?
[15:59] <rockstar> mars, bzr pqm-submit -m '[r=kermit][ui=none] Fix the frobnob.' --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel
[15:59] <mars> rockstar, nope, thanks!
[16:03] <mars> gary_poster / Release Manager, would you happen to know when the next staging roll will be, so we may commence QA?
[16:06] <rockstar> gary_poster / Release Manager - is it possible we could bump the staging roll?
[16:06] <rockstar> (I'm actually on leave today, but so excited to do my QA!)
[16:06] <mars> lol
[16:07] <gary_poster> mars, rockstar, after intellectronica gets his branch in, we are out of testfix, I land lp:~stub/launchpad/pending-db-changes , and I've asked the losas to kick staging.  My hope is within 2 hrs
[16:07] <rockstar> gary_poster, woo hoo.
[16:07] <mars> gary_poster, cool, thanks
[16:10] <EdwinGrubbs> sinzui: do you want to review my tiny patch? http://pastebin.ubuntu.com/360736/
[16:11] <dobey> gary_poster: hrmm, a bit more poking and i figured it out. the documentation is wrong :)
[16:12] <sinzui> EdwinGrubbs: is there already a test for ICountableIterator?
[16:21] <EdwinGrubbs> sinzui: I don't think there is a specific test case for this, but now it will blow up if you try to use a subclass without the right permission, whereas previously it could mostly work because __getslice__ wasn't called that often.
[16:22] <sinzui> How do we know this fixes the oopes in the two vocab?
[16:22] <sinzui> Are the two vocabs subclasses of ICountableIterator
[16:25] <EdwinGrubbs> sinzui: the SourcePackageName uses the SourcePackageNameIterator that subclasses ICountableIterator.
[16:27] <sinzui> EdwinGrubbs: And the same is true for canonical.launchpad.database.binaryandsourcepackagename.BinaryAndSourcePackageNameIterator ?
[16:27] <EdwinGrubbs> sinzui: yes
[16:27] <sinzui> EdwinGrubbs: okay. r=me
[16:28] <EdwinGrubbs> sinzui: thanks
[17:20] <nigel_nb> flacoste, thanks, but I got it solved.  I was playing around with launchpadlib and got stuck :)
[17:20] <flacoste> nigel_nb: ok, nice to know it got solved!
[17:20] <nigel_nb> :)
[18:35] <sinzui> deryck: I am looking at bug 182830. It looks like it is inline with out goals. Is there a tag or milestone I can use to keep it in your sight?
[18:35] <mup> Bug #182830: Linking package to bug report doesn't suggest checking upstream <Launchpad Bugs:New> <https://launchpad.net/bugs/182830>
[19:25]  * deryck looks at bug
[19:25]  * deryck was out lunch
[19:29] <deryck> sinzui, story-bug-a-and-a would work well for ones like that.  I've tagged that one since I was on it.
[19:30] <sinzui> okay thanks
[19:48] <intellectronica> deryck, sinzui: story-bug-q-and-a?
[19:48] <deryck> heh
[19:48] <sinzui> I like ask and answerd
[19:48] <deryck> intellectronica, yeah, sorry.  sinzui -- me typoed.  See intellectronica's correction.
[19:50] <deryck> bug 182830
[19:50] <mup> Bug #182830: Linking package to bug report doesn't suggest checking upstream <bugwatch> <story-bug-q-and-a> <ubuntu-upstream-relations> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/182830>
[19:50] <deryck> at least the bug is right :-)
[19:56] <kfogel> intellectronica: https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report
[19:56] <kfogel> intellectronica: https://bugs.launchpad.dev/ubuntu/+patches
[19:57] <kfogel> intellectronica: https://bugs.launchpad.dev/patches-view-test/+patches
[19:57] <kfogel> intellectronica: in the above, ubuntu is a distro obviously, patches-view-test is a product we created.  I had to create a bunch of bugs and give them patch attachments and bugtasks and stuff, naturally.
[20:31] <wgrant> sinzui: If you're around, could you land that branch for me please?
[20:31] <sinzui> I will
[20:32] <wgrant> Thanks.
[21:01] <gary_poster> deryck, rockstar, mars, et al: OK, (finally) you have through r8904 (devel r10208) running on staging.  We're starting another update now since buildbot has just blessed r 8913 (devel r10215) so you will have that in about 1.5 hours.
[21:01] <mars> gary_poster, ok, thanks
[21:01] <rockstar> gary_poster, yea, I need the latter.  Thanks for shepherding this.
[21:01] <rockstar> (today is technically my day off)
[21:03] <deryck> gary_poster, excellent.  many thanks!
[21:22] <deryck> gary_poster, should staging be available now?  I get "please try again" error.
[21:23] <deryck> gary_poster, ohnever mind
[21:23] <deryck> gary_poster, I see, another update message now
[21:49] <jamalta> hm... i just got a buildbot failure but i'm not sure which branch it is for :(
[21:49] <jamalta> or why
[21:51] <gary_poster> jamalta: looking
[21:52] <gary_poster> jamalta: it was a failure to update dependencies.  Don't worry about it.  I'll restart.
[21:52] <gary_poster> IOW it was a breakage in our testing system, not the branch
[21:53] <jamalta> gary_poster: oh ok, thanks :)
[22:17] <kfogel> deryck: https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report
[22:18] <deryck> got it
[22:18] <gary_poster> To Whom It May Concern, the glaring XXX on staging is already addressed in r8915.  It should be gone Monday.
[22:19] <gary_poster> Also, deryck, fwiw, staging is at 8913, which is as far as we'll get till Sunday/Monday
[22:19] <deryck> gary_poster, great, thanks for the update.
[22:19] <gary_poster> np
[22:52] <Ursinha> mars: hi
[22:53] <Ursinha> mars: are you around? if so, is that XXX on the top of every page in staging on purpose?
[22:57] <mars> Ursinha, no
[22:57] <mars> Ursinha, staging was cut two revisions too soon :)
[22:57] <mars> Ursinha, the fix is in db-devel r8915, staging has r8913 deployed
[22:58] <Ursinha> mars: oh, I see :)