[00:04] wallyworld, hey, thanks for that review! would you mind landing it for me as well as I don't have ec2-utils setup? [00:04] salgado: np. will do it today. thanks for doing the work :-) [00:07] StevenK, after looking at formlibs processing of the form, visibility is excluded from the data because the input == false. So while the widget got input that we recognise as valid, it is ignored because of this "input" flag. I think "input" means the field is read-only [00:09] sinzui: I set readonly=true in the visibility attribute [00:09] I remember Zope de-praming its toys if it wasn't [00:10] correct, but I think out mutator rules are in conflicts with form lib [00:11] We may need to check the state of the widget ourselves, or as we have done before...copy a writeable field into the ITeamCreation schema [00:11] sinzui: I've just removed readonly=True, let's see what Zopes does. [00:12] StevenK, mutator will kill startup [00:12] Indeed [00:12] TypeError: Only a read-only field can have a mutator method. [00:12] StevenK, We know at the time of creation, we can do what we want because there is no mutation [00:12] Ah, yes, that's right. [00:12] You need to override the readonlyness in setUpFields [00:13] wgrant, StevenK I see the widget got the value and it was valid. are you saying setupfields did something else to say do a lot of work, but I intend to ignore it later [00:13] ? [00:14] * sinzui must eat [00:14] sinzui: Thanks for the pointer [00:14] wgrant: How do I do that? [00:15] StevenK: See BugSecrecyEditView for a way to do it without customising setUpFields [00:15] The copy_field business [00:16] I'm tempted to do it in conditionallyOmitVisibility() [00:16] Then everything gets it [00:16] It's not appropriate to do it there. [00:17] class schema? Wow, really? [00:17] ? [00:18] That's what under BugSecrecyEditView does copy_field() [00:18] Yes. [00:18] I'm just wondering why you question it. [00:18] Seems like a horrid hack :-P [00:19] It's a horrid problem with a not particularly horrid solution. [00:19] Hmm, but TeamAddView already defines schema = ITeamCreation [00:20] Yay, top OOPS fixed. [00:22] That was Product:+index? [00:22] No, loggerhead's DownloadUI [00:22] Product:+index rarely times out now, it's just 30% slower than it needs to be. [00:22] And that fix is not on production yet. [00:23] Or even qas? [00:23] Correct [00:23] ValueError: ('Duplicate name', 'visibility') [00:23] :-( [00:27] Oh, that fixed oops #5 too [00:27] wgrant: so the question is where folk were getting bad links from [00:28] lifeless: I would tend to suspect spiders, but loggerhead OOPSes don't contain any info. [00:28] The access logs might. [00:28] * wgrant hunts. [00:28] spiders don't make up urls though [00:29] so if its spiders, something is broken [00:29] somewhere [00:29] Why? [00:29] These are referring to fileids in head: [00:29] That easily linkrots. [00:29] true [00:29] downloadUI is quite new though [00:29] that one in particular... [00:29] DownloadTarballUI is now [00:29] DownloadUI isn't, is it? [00:29] s/now/new/ [00:29] ah, right right [00:31] Interesting. [00:32] There's far fewer requests in the logs than there are OOPSes. [00:33] All the problematic requests are from Android [00:33] So I wonder if the app is looking at that URL for updates. [00:34] wgrant: the garbo job change landed? [00:34] wgrant: I take it we're doing a one-off ? [00:35] wgrant: hah, an android app updating from loggerhead. Aieee!!!! !! [00:35] lifeless: No, just the DB patch so far. [00:35] oh phew [00:35] Will be deployed on Monday [00:35] \o/ [00:35] Oh, blah. [00:36] This is going to take forever to branch. [00:36] Because it has Java disease. [00:36] Dozens of embedded jars. [00:36] head-spike [00:36] Perhaps we can alter the LP ToS [00:36] To state that if you embed dependencies, your forfeit your access to LP [00:39] alert, alert [00:39] We are in the green for criticals in the last week :/ [00:40] Isn't that a good thing? [00:42] It can only mean one thing: our OOPS reporting system is broken. [00:54] how wrong is it to call functions via exec function.__code__ in custom_globals [00:55] That ranks at roughly 11/10 evil points [00:57] it is sad when language docs need to say things like: [00:57] In some cases, a fruitful optimization is to assign the attribute to a local variable and call that local variable. [00:58] anyhow, func_code is the support attribute. win. [00:58] It is sad when the project is 10MB but the branch is 150MB because of the jars. [00:58] collectionista-library/res/values/strings-versioncheck.xml: http://bazaar.launchpad.net/%7Epjv/collectionista/trunk/download/head:/collectionista_versi-20110605182324-0nll835704egr1kc-219/collectionista_versions.xml?file_id=collectionista_versi-20110605182324-0nll835704egr1kc-219 [00:58] woot [01:00] headdesk deskhead [01:00] It's a reasonably strategy. [01:00] not with that url [01:00] Strategy, not implementation :) [01:27] * StevenK stabs NFS, and then twists the knife. [01:42] its a bit disappointing that the vm bypasses __getitem__ [01:54] Grar [01:54] Too many bug statuses [01:55] * wgrant becomes murderous. [01:59] win 3658 OOPS-11d83b82cd4d682e6c5cd63a9326e9db Unknown [01:59] It's always in the top 5 [02:00] top today [02:00] With a count like that I would certainly hope so :) [02:04] Ah, process-apport-blobs [02:04] Hmm [02:05] I think it may have a somewhat serious bug. [02:05] 3658 queries, 3200 of which are made up of two massively duplicated librarian reads. [02:06] Ah, possibly it's chunked. [03:00] lifeless: So, simply realising the join removes the Ubuntu FTI issue. [03:01] I have most sensible orders with FTI pretty fast now, even on DF. [03:01] I wonder if I can make a guess at how many rows there are and disable insane orders if there are too many. [03:43] aaaaah launchbag [03:45] Kill it, it's moving! [04:08] I have to say, it is somewhat pleasing to see dogfood reliably faster than production. [04:12] Oh no :( [04:12] My launchpad shared repo is now tainted. [04:13] I accidentally branches collectionista into it, so it's now covered in revolting embedded jar residue :( [04:53] lifeless: How are we looking for bug index bloat? [04:54] Oh, blah. [04:54] Nevermind. [04:54] The massive PPR regression is the bug listings release. [04:56] However, we have a serious xmlrpc-private regression start on the 26th and escalating since then. [04:58] Hm, unless it actually started on the 30th, when the session DB was put through pgbouncer. [04:58] But it seems to have been going slightly badly since the 27th. [05:29] is it just me or is js calling conventions a tad idiosyncratic [06:34] StevenK: can't recall your previous issue exactly, but i can't create_initialized_view for a team with a rootsite specified eg https://blueprints.launchpad.dev/~teamname and have it render correctly [06:34] is that something you ran into before? === benji is now known as Guest38136 === wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 === nhandler_ is now known as nhandler === almaisan-away is now known as al-maisan === statik is now known as 64MAAQOA7 === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugtasks: 4*10^2 === al-maisan is now known as almaisan-away [11:24] morning [11:43] hey rick_h [11:52] hello [11:52] I have a couple of questions: [11:53] Is there an IRC bot that can announce when new MPs are up on Launchpad (for a user-defined set of projects) [11:53] jml: I think Landscape has one. [11:53] Would it be OK if I amend an existing IRC bot to do this? Are there any guidelines for the inevitable polling that I will have to do? [11:53] jml: Rabbit FTW [11:54] stub: Rule Britannia. [11:54] jml: txlongpoll + rabbit if not running in our DC [11:55] stub: do you mean that I can actually set something up today that wait for events from Launchpad and not run in the DC? [11:56] jml: It is used by the merge proposal page at the moment to load the diff as soon as it is available, so all the pieces are in place. [11:56] stub: I don't see that behaviour... [11:57] It's restricted to ~launchpad until it's ready. [11:57] stub: also, that sounds suspiciously like a "No, not yet" [11:57] jml: It means in theory yes, in practice ask the people who implemented it :) [11:57] stub: heh, ok. [11:58] wgrant: ok. I'll make a note to come back and ask about this some time in the future. [11:58] wgrant: I feel a bit stupid for asking, but, any guess on when it'll be opened up to a broader group? [11:59] jml: There's one current show-stopping bug which I might get bored and illicitly fix at some point. [12:02] wgrant: ok, thanks. [12:09] In fact, why don't I try to fix that now. [12:09] * wgrant fixes. === mrevell_ is now known as mrevell [12:13] hey guys, I replied to a merge proposal by email but my reply didn't show up in the web ui. should I have signed the email? === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Firefighting: - | Critical bugtasks: 4*10^2 [12:36] hello adeuring === benji___ is now known as benji [12:37] matsubara: i did the same yesterday with this MP: https://code.launchpad.net/~frankban/charms/oneiric/buildbot-slave/02-09/+merge/92340 . you'll see my second comment showed up just fine. the email was unsigned. [12:38] but i wondered as i hit 'send' [12:39] how strange. In any case I copy and pasted my reply into the MP === StevenK_ is now known as StevenK [12:44] morning bac [12:49] rick_h: O hai. You agree with my Evil Plan? [12:53] StevenK: your plan works for me I believe [12:54] and I can start landing fixes like a mad man once that's there and we get some testers [12:54] rick_h: One thing I'd love for you to look at is why the AJAX drop-down doesn't work. [12:55] orly? ok, where is this? [12:55] is there a bug to look at? [12:55] rick_h: On any page, it's the green "AJAX log" next to your name. [12:56] oh that, ok. I'll peek [12:56] rick_h: It's only shown for us, but it hasn't worked since our fixes from the epic were deployed [12:56] rick_h: I'm guessing it's something trivial [12:56] StevenK: ok, I had hoped it was part of the single LPJS thing [12:56] So had I [12:56] It wasn't. :-( [12:56] if it's still broken today, then I'll peek at it [12:56] rick_h: I'm not sure if there is a bug. wgrant may have filed one. [12:57] k, I'll look, thanks for the heads up [12:57] rick_h: Do you also want to prod sidnei to review my convoy branch? :-) [12:58] ah ok, I haven't peeked over there. Will do. [12:58] StevenK: he's in Brazil so should be mid day now I tink [12:58] think* [13:06] StevenK: ok, didn't see a bug, so added one and got the card on the board [13:07] rick_h: I'd be very curious to find out what the issue was. [13:10] what's the best way to check if a call exercises the database again? [13:11] In a test? [13:11] StevenK: yep [13:11] I'm testing to see if something that's supposed to cache will actually cache [13:12] jelmer: Right, we have an existing pattern for that. Have a grep for StormStatementRecorder [13:13] StevenK: I don't recall seeing that before, is it new? [13:13] StevenK: either way, that seems to be exactly what I'm looking for - thanks! [13:13] I think it's been around for a little while [13:13] StevenK: sidnei is +1'ing your MP [13:14] rick_h: Sweet. Feel free to merge it in [13:14] will do [13:14] Then we should automagically get a new version of convoy in the PPA. [13:14] StevenK: awesome [13:18] jelmer, hi. Congrats on colocated branches! Where do we read about how to use them? [13:22] gary_poster: Hi [13:22] gary_poster: they're not really prime-time material yet; most of the documentation there is can be found in my last post on them to the bazaar mailing list [13:23] jelmer, ok. So should we not try to rely on them? [13:23] gary_poster: their format is stable, but the support in the UI is still a bit awkward [13:24] jelmer, hm, ok. I'll review the post and see if we can give it a whirl. I'm guessing testers would be good. :-) [13:25] thank you [13:26] gary_poster: yep, definitely - thanks :) [13:26] gary_poster: see also the list of bugs tagged 'colocated' in bzr [13:28] jelmer: colocated branches are not new are they? i've been using branches switching between a single working tree ever since i started [13:29] lp is too large to do anything else imo [13:29] plus it suits modern IDE's === ayan_ is now known as ayan [13:30] wallyworld_: colocated branch support in bzr itself is new [13:30] wallyworld_: perhaps you mean bzr-colo? [13:31] yes, i think that's what i meant === almaisan-away is now known as al-maisan [13:41] wallyworld_: jelmer: bzr switch I suspect? [13:41] bigjools: yes, i use bzr switch [13:41] me also [13:41] with a single working tree, and no-tree branches [13:42] i'm not 100% sure what colocated branch support is, have to rtfm [13:56] wallyworld_: switching a single working tree between multiple branches has been supported for a long time [13:56] this is just the support for having the branches live in the same location as the tree [13:56] rather than having to have a separate shared repo with the branches elsewhere [13:57] ah, ok. i follow now. thanks for the extra explanation. [13:57] hi adeuring, bac [13:57] although for my use, i want the branches and working tree separate [13:57] hi jelmer [13:57] hi jelmer [13:57] would either of you have time for the review of a small branch? [13:57] https://code.launchpad.net/~jelmer/launchpad/branchjob-cache-authors/+merge/92470 [13:58] jelmer: sure [13:58] wallyworld_: why do you need to have them separate? [13:58] adeuring: thanks! [14:00] jelmer: i like the working tree to be "pure" and not have extra VCS directories in it like with svn or cvs. but i guess if they are hidden then it's ok [14:01] jelmer: so now i have a lp-branches dir, and all my branches are directories named after the branch containing .bzr etc, and my working tree sandbox is nicely uncluttered [14:02] wallyworld_: that's still the case with colocated branches, they all live under .bzr/branches [14:02] ah, ok. then that sounds cool :-) [14:03] although now i can ls to see what my branches are easily [14:03] and use ls -lort to see what the most recently checked out one is [14:03] jelmer: r=me [14:04] adeuring: merci :) [14:05] wallyworld_: the difference once it's set up is quite small [14:05] wallyworld_: we have a 'bzr branches' command that can list all branches and pinpoint which one is active at the moment [14:05] wallyworld_: the main advantage in colocated branches vs the the traditional setup with a lightweight checkout and shared repository, is that it requires less setup [14:06] wallyworld_: you can just go "bzr branch lp:foo" and then run "bzr switch -b newbranch" in the resulting directory [14:08] makes sense. atm i just go "bzr switch ../foo" to changes branches so i guess it comes down to what you are used to [14:09] the setup was a one time thing, not too onerous from memory [14:09] but anything to make it easier is good :-) [14:10] the reason i like ls -lort is that sometimes i need to recall what the last few branches were that i worked on because i need to switch back to one and can't recall it's name === Ursinha is now known as Ursinha-lunch [14:28] adeuring, abentley, rick_h -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup [14:28] superspeed standup today. [14:28] deryck: ok === soren_ is now known as soren [14:28] I'm stuck waiting on plugin in FF. switching === matsubara is now known as matsubara-lunch [15:21] abentley, adeuring, rick_h -- I'm back now. [15:21] ack [15:22] deryck: Cool. [15:22] deryck: yay [15:26] rick_h, hey, so just to be clear, you don't need reviews from me now, thanks to wallyworld_ right? [15:28] deryck: not for those two, I'm making the changes there and will put up the next set for you :) [15:28] rick_h, rockin'! :) [15:29] deryck: 3 is up, 4 says conflicts to looking into that === Ursinha-lunch is now known as Ursinha\ === Ursinha\ is now known as Ursinha [16:00] deryck: talk in 2 minutes? [16:01] abentley, yup. firing up a hang out now. [16:01] abentley, actually, warming coffee. but here's the link…. https://plus.google.com/hangouts/extras/talk.google.com/go-for-deryck === matsubara-lunch is now known as matsubara [16:28] deryck: ok, branch 4 is fixed and pushed as well and setup for review === al-maisan is now known as almaisan-away === Ursinha_ is now known as Guest25821 === Guest25821 is now known as Ursula === Ursula is now known as Ursinha === Ursinha` is now known as Ursinha [17:11] rick_h, I'm working on them now. [17:13] deryck: let me know where to send the beer to in payment [17:14] rick_h, not necessary. :) It's actually easy to review this stuff to me. [17:14] hah, you say that now! I know my steam is slowing down in writing it, I'll bet the review does as well :P [17:16] rick_h, r=me for #3 branch. [17:16] deryck: ty much [17:17] rick_h, it helps that I'm a really fast reader anyway, and I know these tests really really well. :) [17:18] I like to remind myself that the worst I can do is cause a test failure because I broke it really [17:24] rick_h, yup. it's really a very safe change, despite the diff size. r=me on #4. [17:24] deryck: ok thanks. [17:24] deryck: since 5 is just the html files getting a lot more files into there, still working. Almost done with /bugs/ [17:25] so I'll be back! bwuhahahaha [17:25] lol, there's a 'test_me_too.js' never noticed that one === deryck is now known as deryck[lunch] [18:19] bac, do you have time to review changes to commercial subscription rules: https://code.launchpad.net/~sinzui/launchpad/apply-commercial-subscription/+merge/92547 [18:19] sinzui: yes [18:19] * james_w curses incompatible bson libraries [18:25] rick_h, hi there. when you have a minute, we could do with another review on https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-model-classes/+merge/92174 :) [18:26] salgado: loading up === deryck[lunch] is now known as deryck [18:47] so [18:47] this new thing of not changing the URL when a merge proposal is files [18:48] *filed [18:48] and it still being +register-merge [18:48] is tehre a bug yet? [18:51] salgado: looks good, passed onto jcsackett for final ok [18:51] salgado: thanks for both of you for the updates to the storm way vs sqlobject way. [18:52] rick_h, thank you for the reviews! :) [18:58] james_w: patches... [19:00] lifeless, unpossible! [19:01] I think we'll just have to cut oops-* over to pymongo everywhere [19:02] james_w: I'm no particular objection to that [19:02] yeah [19:03] I'm just not sure how for the tendrils will stretch yet [19:03] everywhere. [19:03] muhhahahhahhahahha [19:03] for instance, we may end up deleting the rfc serializer as part of the change [19:04] why ? [19:05] I mean, no great loss IMO, but why? [19:05] because this will change the semantics of what you get back from oopses [19:05] how so ? [19:05] pymongo always returns naive datetimes [19:06] what?! [19:06] thats totally bogus [19:06] also error prone [19:07] do they have a fixed point of reference? or does stuff build on mongo vary by the tz of your server? [19:07] so, ok, I do have an objection. [19:07] *this* [19:08] everything in the serialized form is UTC [19:08] with the rule that you can't put a naive datetime with a non-UTC tz as input [19:10] naive has no tz [19:10] so that rule doesn't make sense to me [19:11] it has an unrecorded tz [19:11] you *can't tell* if someone is messing up if you accept naive tz's [19:11] "everyone that decodes the bson will assume that datetimes are UTC, so don't break that assumption for them" [19:11] hahahahahaha [19:12] so we're back to... [19:12] * james_w curses incompatible bson libraries [19:12] if they were here, I would say to the authors: "There is a way to do that in python, its called tz aware datetimes" [19:12] I mean really, it is astonishingly bad [19:13] lifeless, you do realise that the bson library already in use does pretty much the same thing? [19:13] it just returns non-naive datetimes [19:14] http://paste.ubuntu.com/836939/ [19:14] yes, thats the right way [19:15] strict on emission, broad on acceptance but tell folk they are being daft [19:15] they just add a warning, and return a non-naive datetime with the same assumptions [19:15] yes [19:15] the wire protocol is defined as being utc [19:15] which is great [19:16] so, we could warap pymongo, we could give them a patch providing an option for folk that want nicer coding environmens [19:18] aha [19:18] there's an option [19:22] cool [19:27] https://code.launchpad.net/~james-w/python-oops-datedir-repo/bson-compat/+merge/92560 [19:28] amqp coming soon I presume ? [19:34] already done [19:34] \o/ [19:34] james_w: wait, what? :) [19:34] https://code.launchpad.net/~james-w/python-oops-amqp/bson-compat/+merge/92389 [19:55] flacoste, I must be living in the past because it says this policy was approved 17th Feb 2012.. https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts :) [20:05] lol [20:05] timrc: nah, it's only lifeless living in the future [20:06] flacoste, that oddly makes sense.. [20:06] :) [20:06] but he's usually only one day ahead [20:06] i think he must have made a breakthrough in his timewarp machine === matsubara is now known as matsubara-afk [20:22] sinzui: done. sorry for the delay [20:23] That okay, I almost have my next branch complete [20:29] bah no [20:29] its me confounding dates [20:54] The cursing and screaming upstairs in English, German, and Japanese, can mean onyl two things. Firstly, I taught my daughter well, and secondly, she has reached the mind-f**k ending of Evangelion You Shall Not Advance. [20:59] sinzui: :) [21:00] I just advanced the film to the closing scene after the credits. She at lease knows that world will not end. [21:04] sinzui: :) [21:05] Hey, is this right place to ask questions about the API usage, or is that better suited for #launchpad [21:06] i'm trying to copy from a PPA into another from a jenkins job, a python script seems best (but if there's a better way please let me know!) [21:14] lamalex: #launchpad [21:48] bac: I think you are about to EOD, but if you have time I have a branch that could be reviewed: https://code.launchpad.net/~sinzui/launchpad/contact-team/+merge/92589 [21:50] sinzui: probably. otp atm [21:59] sinzui: i don't understand this comment in the MP [21:59] ADDENDUM: I cannot 'hit' the cancel link. I do not think the cancel [21:59] is a verb and suffices. [21:59] sinzui: can you clarify? [22:01] bac The text instructs me to "hit" "cancel" [22:01] ohhh [22:01] bac https://launchpad.net/~lifeless/+contactuser [22:01] ^ We might have had a Cancel button in the past [22:01] it should read 'hit lifeless' ? [22:02] sinzui: thanks. that makes sense now. [22:02] I press keys and tap buttons. maybe I should tap lifeless [22:05] hmm, maybe not [22:05] sinzui: done [22:06] sinzui: my stupid irc client won't let me edit the topic. would you remove abel and me from the topic, please, while i go search for a less dumb client? === sinzui changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 [22:08] done [23:28] rick_h: ola! [23:39] * wgrant glares at the Web. [23:39] But I think I have three ways of inter-tab communication that cover all major browsers except maybe IE... [23:40] s/cover/together cover/ [23:42] wgrant: sweet [23:42] wgrant: evil. But sweet. [23:43] wgrant: and if you are around; I have some js questions; up for a [briefish] voice call ? [23:43] lifeless: Well, since we can't reasonably maintain one connection per tab, there's not much other choice. And only one of the ways is evil. [23:43] Sure [23:44] hangout invite sent [23:45] I've not used one before, but let's see how it goes... [23:46] ah, you'll be a minute installing the binary blob plugin then [23:46] (yes, twitch) [23:46] wtf [23:47] Do invites show up somewhere? [23:47] I don't have an email. [23:47] Ah [23:47] In the unified Google bar of stupidity. [23:48] "Installing Google voice and video chat will add the Google voice and video chat repository so your system will automatically keep Google voice and video chat up to date." [23:48] wtf is this shit [23:48] its the HTML5 web [23:48] I wonder if I can apparmor this to death. [23:48] wtf plain http download link [23:49] if you do, submit a patch to the ubuntu apparmour config! [23:49] Aha, there's one on the wiki already. [23:50] internal? [23:51] Yeah :( [23:54] Firefox has hung twice, but it seems to be loading... [23:57] wgrant: anything in dmesg ? [23:58] wgrant: also check top; precise has a horrible habit of *not killing hung things*