=== jamalta is now known as jamalta-afk [00:44] mwhudson_, you around? [00:44] jml: yeah [00:44] mwhudson_, I'd like to bounce an idea off you [00:44] jml: listening to rusty be silly [00:44] jml: ok [00:45] mwhudson_, I want to make launchpad use subunit trunk [00:45] mwhudson_, but it's in 2a and ours is in 1.6 or something [00:45] jml: gragh [00:45] mwhudson_, if I make update-sourcecode just blow away old versions in the case of format errors? [00:46] jml: talk to spm i guess [00:46] mwhudson_, will that work on production? [00:46] or will I need to talk to spm [00:46] hmm. [00:46] jml: ? [00:46] spm, I want to make launchpad use subunit trunk [00:46] spm: i think deployment doesn't use update-sourcecode [00:46] spm, but it's in 2a and ours is in 1.6 or something [00:46] spm, which means a simple 'pull' won't work. [00:46] oh yukness [00:47] yeah... [00:47] (thanks bzr!) [00:48] spm, so what should I do? [00:48] jml: how urgent is this? ie MUST be in the release next week? [00:49] spm, no, it's entirely optional. [00:50] 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] we may need to verify what/where that branch is etc. but that's details you don't need to worry about. [00:51] 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] 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] well - partially fix - we still need to fix our local copy of. [00:52] hmm. hmm. hmm. [00:52] this is all too hard. [00:52] welcome to our world! :-) [00:52] I'm going to trick gary into walking me through making this an egg. [00:52] why is that hard? [00:52] mwhudson_, subunit uses autotools! [00:53] yay [00:53] oh riiiiiiiiiight [00:53] yay indeed [00:54] ??? why is that hard? isn't the idea of autotools to make this stuff easy? [00:54] jml: Do you think we can reasonably get bug #507751 done this release? [00:54] Bug #507751: New ISourcePackageRecipeBuild fields [00:54] spm: Not for making eggs... [00:54] spm, and the idea of eggs is that they also make this stuff easy [00:54] spm, but in a completely different way! [00:55] oh yay. more wheel reinventions. lovely. [00:55] only the tip of the iceberg [00:55] wgrant, I'm not going to do it. [00:56] wgrant, but there's probably time if someone were keen. :) [00:56] jml: It's trivial except for the contention around SourcePackageRecipeBuildJobUpload. [00:56] bigjools thinks that it should exist. [00:56] I don't think anybody else does. [00:58] wgrant, well, I'm basically reserving my opinions until I can see the whole thing. [01:01] jml: What whole thing? [01:01] wgrant, "building stuff on the build farm" [01:01] wgrant, that thing. :) [01:01] An explanation of everything? [01:01] wgrant, yeah, but more just having the whole thing in my head. (which probably is going to require me writing a doc). [01:02] Possibly. [01:02] But it would be nice to not have to land everything on db-devel next cycle. [01:03] wgrant, sure. so just do things the way bigjools says, and then we can fix it the cycle after next :) [01:04] It's unclear how the bigjools model is meant to work. === mwhudson_ is now known as mwhudson [01:04] wgrant, ahh, I see. [01:05] 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] Rather than copying from one archive to the rest. [01:05] oh right. [01:06] 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] It's also much harder, both UI- and code-wise. [01:07] indeed. [01:07] OK, I'm going to call yagni on this. [01:08] let's worry about SPRBJUpload when we have a use-case [01:08] Right. [01:08] We can easily migrate to it later if we need. [01:08] yeah. [01:09] * wgrant JFDIs. [01:13] heh [01:13] i tried to call yagni way back when [01:14] mwhudson, sorry, I should have listened harder. [01:15] np [01:15] hmm. [01:16] can I somehow get subunit trunk into pack-0.92 so I can just pqm-submit this change? [01:16] Doesn't the rich root barrier make that impossible? [01:16] yeah, it looks like it [01:17] Hmm, I see that process-upload.py doesn't actually link the produced SourcePackageRelease to the SourcePackageRecipeBuild :( [01:18] huh what? [01:18] that sucks. [01:19] It's unclear how that would best be done (link on the PackageUpload, or the PackageUploadSoure, or the SPRelease, or the SPRB). [01:20] But that can be fixed laaaater. [01:33] mwhudson: Do you happen to know why SourcePackageRecipeData has a reference back to SourcePackageRecipe, rather than the other way around? [01:33] wgrant, what are the issues? [01:33] sourcepackagerelease has a sourcepackagebuild column now [01:33] jml: Nothing. It just seems like a very strange way of doing things. [01:34] wgrant: you can write more useful constraints that way around [01:34] mwhudson: Oh, so it does. [01:34] oh sorry, I must have missed something [01:34] carry on. [01:34] (stub made me do it) [01:34] mwhudson: OK. === jamalta-afk is now known as jamalta === abentley1 is now known as abentley === jamalta is now known as jamalta-eee === abentley1 is now known as abentley === mwhudson_ is now known as mwhudson [03:48] wgrant, I'm looking at ec2test-remote.py [03:48] wgrant, which is the thing that would have to be screwing up in order for the emails to not be sent. [03:49] jml: You didn't get an email for this one either? [03:49] wgrant, which one? [03:50] wgrant, I'm looking at the code trying to make it attach a subunit log to the mails it sends. [03:50] jml: The one that landed late last night. [03:50] wgrant, no, I didn't. [03:50] Aha. [03:52] jml: There are conflicts between your branch and db-devel again. [03:52] fuck [03:52] And you should probably revert the move of BuildBase.build_log_url [03:52] why [03:53] Because it is really implemented on BuildBase now. [03:53] (and it will be used by view code RSN) [03:54] wgrant, ok. [03:55] 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] Sadly, I don't think I can fairly direct this anger to any one person. [03:55] (or even any set of people) [03:55] it's society that's to blame! [03:55] mwhudson, do you have a second? [03:56] rockstar: yes [03:56] mwhudson, this is my test: http://pastebin.ubuntu.com/360426/ [03:57] rockstar: ok [03:57] * wgrant finds more gaps in the implementation. [03:57] 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] mwhudson, I'm not sure where the disconnect is. [03:59] rockstar: which url does the BranchScanJob try to open? [03:59] mwhudson, I'm assuming the lp-mirrored one, since that's what oopses on the NotABranch error. [03:59] hm [04:00] The BranchScanJob basically just instantiates a BzrSync instance with the db branch instance as it's only argument. [04:00] oh [04:00] i have memories of terrible things marching out of my hind brain [04:00] mwhudson, that makes me sad. [04:00] rockstar: can you check config.codehosting.internal_branch_by_id_root in the test? [04:01] Sure, one sec. [04:03] rockstar: i think it will be file:///var/tmp/bzrsync/ [04:03] mwhudson, yeah, I seem to remember seeing an error like that as well. [04:03] file:///var/tmp/bzrsync/ [04:04] rockstar: try changing it to file:///var/tmp/bazaar.launchpad.dev/mirrors ? [04:08] mwhudson, this is where I do the config pushing stuff, right? [04:08] rockstar: i'd just change it in lib/configs/testrunner/launchpad-lazr.conf [04:08] mwhudson, okay. === jamalta-eee is now known as jamalta-afk [04:11] mwhudson, that worked. [04:11] rockstar: yay [04:11] I have no idea why it worked, but it did. [04:11] rockstar: oh [04:11] rockstar: i can explain the details i guess, but then you'll want to kill yourself [04:12] rockstar: run the lp.codehosting.test.test_rewrite tests, they might need updating [04:15] mwhudson, okay. [04:17] mwhudson, so is this a permanent config change? [04:18] rockstar: i think it causes a small decrease in overall insanity [04:19] mwhudson, okay. [07:39] barry, ping [07:40] I'm looking for some guidance with launchpadlib with regard to connecting the subscribers/commentors of a bug with the bug [07:56] flacoste, got a minute? === henninge changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.01 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/ [09:13] hi [09:14] hi mrevell [09:23] mrevell, do you have a min? I have a doubt in launchpad lib [09:24] 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] mrevell, I have been struggling for the past 3 hours [09:25] I'm trying to build a script that will list all the bugs that I have commented or subscribed and are incomplete [09:25] I have a sort of beginning point here http://paste.ubuntu.com/360520/ [09:25] I dont know how to search all ubuntu bugs, i.e., all bugs in a distribution [09:26] I've been playing with launchpad.distributions['ubuntu'].searchTasks [09:26] but it just prints and object and I dont know how to actually perform a search... any clue? [09:27] launchpad.distributions['ubuntu'].searchTasks(bug_subscriber=launchpad.me, status='Incomplete') [09:27] wgrant, thank you! [09:28] Actually, you might need status=['Incomplete'], but one of those should work. [09:28] so how does searchtasks work? [09:29] you use ( bracks and then sub-criteria inside '['? [09:31] jml: still there? [09:33] bigjools: He's probably still at the Penguin Dinner or associated events. [09:33] nigel_nb: The parentheses are just Python function call syntax. [09:33] * bigjools boggles at what a penguin dinner could be [09:34] bigjools: The final dinner for professional LCA delegates. [09:34] ah so they're not eating penguins [09:34] Sadly not. [09:35] wgrant, oh okay. I've ben wondering how to pass args to searchTasks :) [09:35] * nigel_nb high fi's wgrant :) [09:47] bigjools: Do you still feel strongly that we want SPRBUpload? [09:47] yes [09:47] Argh. [09:47] I discussed it with jml earlier. [09:47] And he seems to think that we don't. [09:47] it has parallels with PackageUpload [09:49] Why do we want that? [09:49] Binaries have nothing like it. [09:50] PackageUploadBuild ... [09:50] And PackageUploadSource. [09:50] PackageUpload(Build|Source) just tie things together. [09:51] They serve a different purpose from SPRBU [09:51] true [09:51] but I want it to stay [09:51] because from experience I just know that in the future we'll be doing more with this stuff [09:51] Why would we ever want to do that rather than copy? [09:52] You say that copying is bad, but I haven't seen a concrete reason. [09:52] I didn't say that at all [09:52] I said I wanted to retain options [09:53] Hmmm. [09:54] Have you ever had a similar need for binary uploads to multiple places? [09:54] What do SPRBUs mean? [09:54] How on earth does this make it into the UI? [09:55] 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] uploading is an orthogonal action to building, conflating the two in the model is ridiculous [09:57] and not everything needs a direct UI mapping [09:57] It's barely orthogonal. [09:57] A build finishes by uploading. [09:57] There is no such thing as a non-volatile un-uploaded build result. [10:02] The upload is represented by the PackageUpload. [10:11] wgrant: so explain to me what the problem is right now with having the table? [10:13] 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] so there's no problem as such, it's a philosophical issue? [10:15] 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] "over-complicated data model" is an opinion. Why "code that cannot handle it" ? [10:18] 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] 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] So involving SPRBU is probably unnecessary complexity. [10:24] well there is a use case :) [10:25] Is there? [10:25] bug 235064 to some extent and bug 245594 [10:25] Bug #235064: Implement multi-release support for packages

[10:25] Bug #245594: Rebuilds of binary packages without source changes [10:25] it's not a complete solution but it would be one way [10:25] however [10:25] I don't think that's a reasonable solution (even partial) to either. [10:26] it's not a solution [10:26] it's a model [10:26] that would support a solution [10:26] I don't see what it has to do with either. [10:27] https://bugs.edge.launchpad.net/soyuz/+bug/245594/comments/5 [10:27] Bug #245594: Rebuilds of binary packages without source changes [10:27] We need to either change the source version, or do a binNMU and just change the binary version. [10:27] Neither situation is helped by allowing multiple uploads of the same source. [10:27] * wgrant reads. [10:28] Right, that's the first solution. [10:28] And since it involves changing the source, and thus a new SPRB, multiple SPRBUs are not useful here. [10:29] well, again, it depends how it's done [10:30] 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] you seem to feel strongly about it [10:31] so I will talk more with jml when he's back [10:34] Not a bad idea, although he probably won't be around for a couple of days. [10:35] well, that's the weekend then :) [10:35] True. [10:36] * bigjools is going to an FA Cup game tomorrow === matsubara-afk is now known as matsubara [11:14] wgrant: so that build has no Job row [11:14] err BQ row [11:14] It must. [11:14] It has two builders. [11:14] And it is being repeatedly dispatched. [11:15] And it had a logtail, which is stored on buildqueue. [11:15] Although it is all gone now. Was it superseded deliberately? [11:16] nope [11:18] it's gone because he uploaded a new one, darn [11:18] which explains the lack of BQ [11:18] There wasn't a DB dump in the meantime that will land on staging tomorrow? [11:19] There was a > 7 hour window. [11:19] stub, what time is the dump for staging done? [11:19] You've confirmed that cesium is still appropriately patched? [11:19] yes it us [11:19] Arrrrrgh. [11:20] there's a weirdo in the data I did see. one sec [11:20] http://pastebin.ubuntu.com/360597/ [11:21] bigjools: Finishes on wildcherry about 05:30 UTC [11:22] stub: ah cool [11:22] Starts at 0100 UTC if that is what you are asking [11:22] How long does it take? [11:22] Ah. [11:22] It will have probably just been too early :( [11:22] * bigjools looks [11:22] yeah it's not there === Ursinha_ is now known as Ursinha [13:37] BjornT or mrevell, around? Did you have a chance to try that patch? [13:38] mars, I merged from RF again and the test-suite passed for me last night. [13:38] mrevell, \o/ [13:38] :) Just need PQM to come out of RC mode now :) [13:39] I wonder if rockstar's branch merged my patch? [13:40] no, it did not get merged [13:56] sinzui: monring [13:57] sinzui: that's apropos... === matsubara is now known as matsubara-lunch [14:20] nigel_nb: i have now [14:26] hello [14:26] db-devel has been broken by a bugs test. === jamalta-afk is now known as jamalta [14:27] anyone fixing it? [14:27] jml: seems that no one fixed it yet [14:28] jml: stub reported the failure, but didn't claim he was fixing it, and there was no [testfix] landing [14:29] flacoste, ok, thanks. [14:29] flacoste, my taxi arrives in 15 mins, so I probably shouldn't start fixing it. [14:29] but I really want to land this branch. :\ [14:30] maybe when I get to Sydney. [14:31] * jml is off. [15:05] bac: Here is some info about hacking the button slot in a form: http://pastebin.ubuntu.com/360696/ === matsubara-lunch is now known as matsubara [15:18] thanks sinzui [15:25] sorry everyone for the db_lp failure. not quite sure how that happened, fixing now [15:35] BjornT, yes, I merged your branch into mine, landed it. [15:36] Er, mars ^^ [15:37] rockstar, ok. I have an emergency fix to land then :) [15:37] mars, oh? [15:38] rockstar, yep, check line 826 of https://code.edge.launchpad.net/~mars/launchpad/unroll-mochikit/+merge/17870 [15:39] (we should link those diff line numbers) [15:39] rockstar, missing 'replace="nothing"', so the comment shows up on every page as a result. [15:39] mars, ah. Well, the fix is only on db-devel. [15:39] for now, yes :) [15:40] I thought that with a risky patch like that, we probably want to test it a lot. [15:40] yep. wait, rockstar, db-devel only? Not devel? [15:40] mars, well, after today, we'll only be merging into db-devel. [15:40] mars, yes, only db-devel. [15:40] ok [15:40] so, was staging updated... [15:40] nope [15:42] mars, yeah, I tried to get it updated, but it ended up being really complicated. [15:43] EdwinGrubbs: how goes your packaging branch and secured vocab fix? [15:45] sinzui: I'm getting pretty close with the vocab fix. [15:45] I will review it. We appear to be missing reviewers [15:45] 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] mars, db-devel 8911 is where your patch is at. [15:47] rockstar, ok, thanks [15:48] hey all [15:49] hey dobey [15:49] do the unit tests for lp use mechanize and the zope testbrowser stuff, and alter the User-Agent to test output changes? [15:50] gary_poster, the Zope wizard, ^ ? [15:51] dobey: yes to the first half, not sure to the second. [15:54] 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] rockstar, care to review this patch? https://code.edge.launchpad.net/~mars/launchpad/unroll-mochikit-patch-hardening/+merge/17894 [15:56] 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] mars, r=rockstar [15:57] rockstar, thanks [15:58] rockstar, any special flags needed to land on db-devel? [15:59] 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] rockstar, nope, thanks! [16:03] gary_poster / Release Manager, would you happen to know when the next staging roll will be, so we may commence QA? [16:06] gary_poster / Release Manager - is it possible we could bump the staging roll? [16:06] (I'm actually on leave today, but so excited to do my QA!) [16:06] lol [16:07] 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] gary_poster, woo hoo. [16:07] gary_poster, cool, thanks [16:10] sinzui: do you want to review my tiny patch? http://pastebin.ubuntu.com/360736/ [16:11] gary_poster: hrmm, a bit more poking and i figured it out. the documentation is wrong :) [16:12] EdwinGrubbs: is there already a test for ICountableIterator? [16:21] 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] How do we know this fixes the oopes in the two vocab? [16:22] Are the two vocabs subclasses of ICountableIterator [16:25] sinzui: the SourcePackageName uses the SourcePackageNameIterator that subclasses ICountableIterator. [16:27] EdwinGrubbs: And the same is true for canonical.launchpad.database.binaryandsourcepackagename.BinaryAndSourcePackageNameIterator ? [16:27] sinzui: yes [16:27] EdwinGrubbs: okay. r=me [16:28] sinzui: thanks === beuno is now known as beuno-lunch [17:20] flacoste, thanks, but I got it solved. I was playing around with launchpadlib and got stuck :) [17:20] nigel_nb: ok, nice to know it got solved! [17:20] :) === beuno-lunch is now known as beuno [18:35] 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] Bug #182830: Linking package to bug report doesn't suggest checking upstream [19:25] * deryck looks at bug [19:25] * deryck was out lunch [19:29] 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] okay thanks [19:48] deryck, sinzui: story-bug-q-and-a? [19:48] heh [19:48] I like ask and answerd [19:48] intellectronica, yeah, sorry. sinzui -- me typoed. See intellectronica's correction. [19:50] bug 182830 [19:50] Bug #182830: Linking package to bug report doesn't suggest checking upstream

[19:50] at least the bug is right :-) [19:56] intellectronica: https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report [19:56] intellectronica: https://bugs.launchpad.dev/ubuntu/+patches [19:57] intellectronica: https://bugs.launchpad.dev/patches-view-test/+patches [19:57] 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. === EdwinGrubbs is now known as Edwin-lunch === matsubara is now known as matsubara-afk [20:31] sinzui: If you're around, could you land that branch for me please? [20:31] I will [20:32] Thanks. [21:01] 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] gary_poster, ok, thanks [21:01] gary_poster, yea, I need the latter. Thanks for shepherding this. [21:01] (today is technically my day off) [21:03] gary_poster, excellent. many thanks! [21:22] gary_poster, should staging be available now? I get "please try again" error. [21:23] gary_poster, ohnever mind [21:23] gary_poster, I see, another update message now === Edwin-lunch is now known as EdwinGrubbs [21:49] hm... i just got a buildbot failure but i'm not sure which branch it is for :( [21:49] or why [21:51] jamalta: looking [21:52] jamalta: it was a failure to update dependencies. Don't worry about it. I'll restart. [21:52] IOW it was a breakage in our testing system, not the branch [21:53] gary_poster: oh ok, thanks :) [22:17] deryck: https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report [22:18] got it [22:18] To Whom It May Concern, the glaring XXX on staging is already addressed in r8915. It should be gone Monday. [22:19] Also, deryck, fwiw, staging is at 8913, which is as far as we'll get till Sunday/Monday [22:19] gary_poster, great, thanks for the update. [22:19] np [22:52] mars: hi [22:53]