[00:00] mbarnett: ok, that's not what i expected [00:00] mbarnett: which machines did you try it on? [00:00] sinzui: browser/team.py has an intersting thing [00:00] it looks up the action from the form [00:01] mwhudson: galapagos, pear, russkaya [00:01] but it doesn't seem to check that the action is *for* that row [00:02] !? [00:03] mbarnett: sorry if this is tedious, but can you pastebin the ~importd/.bazaar/bazaar.conf files from pear and russkaya? [00:05] mwhudson: I'll sort that mbarnett needs to go and en-cake-enate [00:05] Lifeless yeah. I am staring at the template. I think the message is adapted to a widget and it builds ids from the message id...we automatically discard duplicate message ids [00:05] jelmer: Did the bzr-svn on launchpad somehow just not ever try "discovering revprop revisions" before the last rollout? [00:05] maxb: it's always done that [00:05] huh [00:05] yes yes, cake levels dangerously low! [00:05] maxb: But we didn't do KDE imports until recently [00:06] Yes, but the KDE imports which ran before the rollout didn't "discover revprop revisions" [00:06] oh, wait, I'm getting my dates wrong. [00:07] sinzui: anyhow all tests are passing, except for [00:07] >>> find_tag_by_id(admin_browser.contents, 'batchnav_first')['class'] [00:07] Yes that will be an issue for a few more moments. I have a patch [00:08] sinzui: and I don't think the bug with POST there is any better or worse due to batching; if its buggy its always been buggy. [00:08] I agree [00:11] spm: cool, and good morning [00:11] lifeless: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/637654 has a proposed patch. It fixes the most common case of upper and lower. I image a page with two sets of BNs will continue to be broken [00:12] mwhudson: hmm. you may have hit the nail. pear doesn't have that file [00:12] sinzui: is this likely to cause other tests to fail ? [00:12] mwhudson: https://pastebin.canonical.com/37119/ <== russkaya [00:12] (I mean, will there be other fixups to do with that patch) [00:13] sinzui: could you commit that patch somewhere and push it? I'll pull it in [00:13] I bet not since there are no tests reporting that we have rubbish ids. I reported it as a separate bug because I think this issue is a separate concern from your branch now [00:13] * sinzui does [00:13] sinzui: it is a seperate concern, but either I leave the test out or I include your branch [00:14] spm: gar [00:14] mwhudson: I assume C&P from one t'other? [00:14] spm: does /home/importd/.bazaar/sign-vcs-import exist on pear? [00:14] nope [00:15] did pear get reinstalled at some point? [00:15] spm: can you look at /home/importd/.bazaar/sign-vcs-import on russkaya? [00:15] mwhudson: I'd assume it being a new machine; some things may have been missed :-( [00:15] it probably references something ridiculous like ~importd/hoover/keys/key.gpg [00:16] holy dooly [00:16] https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/SetUpCodeImportSlave -> "# Make sure ~importd/.bazaar/ and ~importd/botslave look like they do on a working slave. " [00:16] :( [00:16] mwhudson: exec /usr/bin/gpg --no-default-keyring --keyring /home/importd/botslave/gpg/vcs-imports@canonical.com.pub --secret-keyring /home/importd/botslave/gpg/vcs-imports@canonical.com.secret --default-key A60FA0E1 "$@" [00:17] spm: i was sure this was working at some point on pear :( [00:17] maybe not [00:17] it only affects cscvs imports i guess.... [00:17] I'm surprised it's working on russkaya.... [00:22] lifeless: lp:~sinzui/launchpad/batch-ids-0 There are no tests for these links. Nor can I find any tests for the existing of the upper or lower navs. All the tests for the BN are getting the Next link using TestBrowser [00:22] oulling [00:23] I checked for uses the the default BN. Subclasses like root search and bug do their own layouts [00:24] sinzui: so 'batchnav_first' is not what to look for [00:27] lifeless try 'upper-batch-nav-batchnav-first' but keep in mind the nav will not rendered if there is only one batch. We need 6 messages in the testrunner env or we add ?batch=1 to the url we are tesing to set the size to 1 message [00:30] and for the bottom lower-batch-nav-batchnav-first ? [00:30] yep [00:31] ?batch=1 doesn't do it [00:32] http://paste.ubuntu.com/493359/ [00:33] hmm [00:33] 1 is too small [00:34] moving it lower down [00:37] sinzui: doesn't appear to be rendering the nav links to me [00:39] Continue to hold the message, deferring\n your decision until later.\n \n \n\n \n [00:39] lifeless sorry, my screen was locked for a moment [00:39] sinzui: ^ thats with batch=1 and 2 messages [00:39] So, we have an issue with the OpenID identifier migration last week, causing incorrect accounts to be linked together... can someone poke around on staging to work out WTF is going on? [00:39] 2\n \n \n messages have\n been posted to [00:39] wgrant: sure, once I'm finished here. [00:40] lifeless: Thanks. [00:40] sinzui: only one message is shown [00:40] so the batch param worked [00:40] its the naviation bit that isn't [00:41] I am a bad advisor. you are on the first batch. We should be checking for upper--batch-nav-batchnav-next [00:42] no, you're fine [00:42] its no there [00:42] :( [00:42] after the advice [00:42] Discard - Throw the message aw [00:42] etc [00:42] your decision until later.\n \n \n\n
\n \n
Message detail [00:42] is whats in the browser.contents [00:43] the navigation bit is just awol [00:43] it should be after that [00:44] We suppress rendering of the lower if there is no additional batches, so maybe that template fragment is wrong [00:45] well there is an additional batch - batch=1 and two messages to moderate [00:45] the count on the page shows '2' so we know there are two there [00:45] and there is only one "approve" in the output, so we know only one got shown [00:47] lifeless, the upper template must rendered since there is clearly a batch. the view guards the rendering with this: ``if self.context.currentBatch():`` [00:47] * sinzui is looking at canonical/launchpad/webapp/batching.py [00:48] what is the context object going to be - held_messages ? [00:49] mwhudson: pear now has those dirs/files setup per russkaya [00:49] spm: great, thanks [00:50] lifeless: yes held_messages. we are adapting a BN [00:50] so I did this [00:50] +++ lib/canonical/launchpad/webapp/batching.py 2010-09-13 23:50:20 +0000 [00:50] @@ -40,7 +40,7 @@ [00:50] def render(self): [00:50] if self.context.currentBatch(): [00:50] return LaunchpadView.render(self) [00:50] - return u"" [00:50] + return u"not rendered" [00:50] not rendered was not included in the output [00:51] ? [00:51] * sinzui checks zcml [00:51] I wanted to see if that code path was shortcircuiting or something [00:54] * sinzui checks other batches with the hacked template [00:58] and this: [00:58] +++ lib/canonical/launchpad/webapp/batching.py 2010-09-13 23:52:07 +0000 [00:58] @@ -38,6 +38,7 @@ [00:58] css_class = "upper-batch-nav" [00:58] [00:58] def render(self): [00:59] + return u" fooo " [00:59] if self.context.currentBatch(): [00:59] return LaunchpadView.render(self) [00:59] return u"" [00:59] also doesn't show up in the output [00:59] right. I am not seeing my template change when testing https://blueprints.launchpad.dev/firefox?batch=2 [01:00] Or I could run the instance that I made the change in instead [01:00] and to cap it off,when I make that raise an Exception I don't get an error [01:01] oh.. I wonder. I see >>> admin_browser.reload() which has a history if being buggy [01:01] have a look at lib/lp/blueprints/templates/person-specworkload.pt [01:02] sinzui: I'm sure its not that, I made the view crash and the page rendered [01:02] I see my hack in specs now that I am running the right branch [01:06] I'm thoroughly confused [01:07] is there a sample data team w/list ? [01:08] lifeless me too, this always just works. Can you humour me by adding this link before we do the call the find_tag_by_id [01:08] >>> admin_browser.open( [01:08] ... 'http://launchpad.dev/~guadamen/+mailinglist-moderate') [01:08] of course [01:09] lifeless there are no mls in data. I have a make harness note about making them after a request in made in the UI [01:09] >>> admin_browser.open( [01:09] ... 'http://launchpad.dev/~guadamen/+mailinglist-moderate?batch=1') [01:09] >>> find_tag_by_id(admin_browser.contents, 'upper-batch-nav-batchnav-first')['class'] [01:09] first [01:09] >>> admin_browser.contents [01:09] thats what the story does [01:09] :( [01:10] whats weirded [01:10] I added a string literal and I can't see it [01:11] its almost like those divs are eaten [01:11] when I put a literal above it works [01:11] in the list of action descriptions [01:12] but when I add another div at the place we have the navigation ones it disappears [01:12] lifeless as a desperate act to to verify this we could add size=1 to the BN instantiation in the view to be certain that the URL is not being ignore [01:12] d [01:12] I'm certain its not [01:12] because only one "approve" action is in the contents [01:12] Ah, yes, that is what I did to be certain something showed up in my env [01:13] I suspect the metal:form stuf [01:14] I'm positive its simply not evaluation things without metal:fill-slot in that container [01:14] I think if we add a div around it it wil work, moving the widgets slot up [01:15] we are adapting the message in the same manner that we want to adapt the BN [01:15] yes, but the metal interpreter isn't evaluating things without slots [01:15] We can certainly move the navs out of the form to be sire it works [01:16] bet you that that is is [01:16] is it [01:16] yes [01:16] it was [01:16] I have this now [01:16] \o/ [01:16]