=== michaelh is now known as michaelh|away [00:42] wgrant: factory.makeAccessPolicyGrant() is giving me ClassInfoError: .__storm_table__ missing [00:45] StevenK: How're you calling it? [00:45] self.factory.makeAccessPolicyGrant( [00:45] policy=ap, grantee=subscriber, grantor=product.owner) [00:46] StevenK: Can I see the whole test? [00:48] wgrant: http://pastebin.ubuntu.com/1137210/ [00:50] StevenK: line 22 [00:50] [ap] = [00:50] Rather than ap = [00:50] find returns a resultset. [00:50] Ah! === michaelh|away is now known as michaelh [01:08] wgrant: https://code.launchpad.net/~cjwatson/launchpad/publishinghistory-show-copier/+merge/118223 is worth looking at again now, I think. [01:09] It's a bit longer in terms of LoC, but I have more credit now anyway :) [01:10] mm [01:10] you know the goal is overall reduction not stasis [01:10] I know, but I'm well over 4000 down, I'm making considerably more net progress than most Launchpad developers ;-) [01:12] (At least on this metric) [01:13] \o/ [01:14] thats excellent [01:14] we're what, 1% of the way there [01:14] About -0.4%. [01:14] http://people.canonical.com/~cjwatson/tmp/loc-cum.png [01:31] cjwatson: Looking at your MP [01:35] Blast. Anyone want to hazard a guess as to why r15769 hasn't produced an improved oops notification on https://qastaging.launchpad.net/~cjwatson/+archive/ppa/+packages [01:35] ? [01:37] It may be wise to confirm that gandwana's up to date [01:37] I believe that it sometimes lags an update behind asuka [01:37] But I've never been able to confirm it [01:38] cjwatson: ^^ [01:38] I was going to look at https://devpad.canonical.com/~wgrant/production-revnos but it's showing a Python traceback. [01:38] cjwatson: That also doesn't show staging stuff [01:38] Since they're deployed by an entirely separate system, for not very good reasons [01:39] In fact, by two entirely separate systems. [01:39] Yeah, I thought it might not, but also that you might want to know about the traceback :) [01:39] Indeed, thanks. [01:41] Ah [01:41] cron-control on the frontends is breaking it [02:29] wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/redirect-unsub-private-branch/+merge/118859 [03:27] StevenK: sorry, was having lunch, looking now [03:35] r=me [03:43] wallyworld_: Thanks! [03:43] * StevenK tosses it at ec2. [04:07] wgrant: Can you make sense of bug 834370? [04:07] <_mup_> Bug #834370: factory.makeSPPHForBPPH is incomplete < https://launchpad.net/bugs/834370 > [04:10] StevenK: I am confuse. [04:15] wgrant: Oh? [04:15] StevenK: It doesn't make sense. [04:15] SPPHs don't have arches... [04:16] Right. [04:16] Maybe bigjools knows. [04:16] it wasn't me. [04:16] I'm tempted to just rip out the method. It has exactly one callsite. [04:16] what was the question [04:16] bigjools: bug 834370 [04:17] <_mup_> Bug #834370: factory.makeSPPHForBPPH is incomplete < https://launchpad.net/bugs/834370 > [04:17] ummm [04:17] without looking at code, s/architectures/archives/ ? [04:18] It respects bpph.archive [04:18] bug description fail [04:19] I'm sure it was valid at the time but no memory is being jogged [04:19] builds? [04:19] It references bpr.build.spr [04:19] I dunno then [04:20] Yeah [04:20] It all looks pretty sensible to me. [04:20] So I don't get it. [04:20] maybe it got fixed [04:20] Still tempted to rip it out [04:20] and the bug was not updated [04:20] * bigjools continues with maas bugs === michaelh is now known as michaelh|away === michaelh|away is now known as michaelh === michaelh is now known as michaelh|away [04:36] StevenK, wallyworld_: https://code.launchpad.net/~wgrant/launchpad/noro/+merge/118867 ← 1369 lines (+19/-889) 22 files modified [04:37] I already approve [04:39] wgrant: r=me [04:41] Thanks. [04:53] StevenK: https://code.launchpad.net/~wgrant/launchpad/noro-config/+merge/118869 [04:55] https://code.launchpad.net/~lifeless/lp-dev-utils/ppr/+merge/118870 [04:55] wgrant: ^ while you wait for StevenK :) [04:55] 114 - database_name = ConnectionString(dbconfig.rw_main_master).dbname [04:55] 115 + database_name = ConnectionString(dbconfig.main_master).dbname [04:55] wgrant: ^ Que? [04:56] StevenK: Observe the comment above it. [04:56] StevenK: It was avoiding the usual main_master property, since it always wanted RW [04:57] lifeless: Did you just like make lp-dev-utils depend on all of ZTK? [04:57] wgrant: pretty much [04:57] lifeless: And turn what was previously an innocent little piece of code into a horrid Zope egg? [04:58] wgrant: zservertracereport is used to pull out stuff from the log files, and it pulls in ZOMG [04:58] diminishing returns to avoid that. [04:58] lifeless: Right [04:58] That probably means we shouldn't use zservertracereport to pull out stuff from the log files :) [04:58] but I didn't migrate anything else, so most folk can just ignore it. [04:58] Since if we do then it won't be useful to anyone else. [04:58] its no less useful to anyone. [04:59] lifeless: Hmm? [04:59] ImportError: No module named testbrowser [04:59] :-( [04:59] lifeless: You're adding an insane amount of bloat that will probably be removed the first time someone touches it [04:59] lifeless: Since I doubt $person wants to use it for Zope stuff [05:00] wgrant: they're going to make it more pluggable [05:00] we still need it for our logs. [05:00] I don't know what your point is. [05:00] My point is that lp-dev-utils is presently sane and usable. [05:01] And its no less so. [05:01] And doesn't have this bootstrap.py lets-copy-it-everywhere-because-screw-good-ideas madness [05:01] All the existing scripts have exactly the same overheads they had before. [05:03] It looks sensible, apart from the code and build infrastructure being trainwrecks. [05:03] So OK, I guess. [05:04] the existing code is the existing code; I copied in our custom option parser as a stopgap. [05:04] The build infrastructure is no worse than what we use elsewhere, which for all its flaws has the massive advantage of actually working. [05:04] wgrant: do I get a vote on the MP from you ? [05:05] And the massive disadvantage of having all the vileness of Python upstream's distribution attitude combined with the vileness of Zope's. [05:05] Sure [05:05] But I would like to register my extreme distaste :) [05:06] Sure, I feel the same way; but can't affort to spit the dummy - we'd end up having to write a stupidly large stack. [05:06] starting with the way packages are imported from disk and working out from there. [05:06] Right. [05:06] But I was hoping to sort of keep the infection contained. [05:07] it is contained, it doesn't affect php or ruby. [05:07] lp-dev-utils is one of the last bastions of sanity. [05:07] Ruby has their own mess [05:07] And PHP is their own mess [05:09] % bzr di versions.cfg | grep '^\+\w' [05:09] +mechanize = 0.2.5 [05:09] +zope.app.testing = 3.10.0 [05:09] +zope.testbrowser = 4.0.2 [05:09] FEAR [05:09] StevenK: What have you done to who and why? [05:13] wgrant: http://pastebin.ubuntu.com/1137400/ [05:15] StevenK: There's a nuclear winter in our future. [05:15] wgrant: That good? [05:15] So much fallout. [05:16] 'make' works, so WCPGW, right? [05:16] Shipit! [05:16] Haha [05:16] HAHAHAHA [05:16] Is that an evil mad nuclear physicist cackle? [05:16] Yes, at your ShipIt reference. [05:17] I was going to toss it at ec2 and sob like wallyworld_ and propose if ec2 doesn't send hate mail. [05:17] Sounds good [05:17] But the big zope.app.testing bump is a bit scary [05:18] Although I'm still trying to get the last reference of bug=98437 out [05:33] wgrant: or StevenK: I suck, I haven't ec2 enabled myself again yet. Could you land https://code.launchpad.net/~lifeless/launchpad/ppr-move/+merge/118873 ? [05:33] per favor [05:34] Fail. [05:42] Hm [05:45] StevenK: is that 'sure thing' ? [05:46] It is not. [05:47] ec2: ERROR: Branch doesn't have linked bugs and doesn't have no-qa option set. Use --no-qa, or link the related bugs to the branch. [05:47] lifeless: ^ no-qa is fine? [05:48] StevenK: yeah [06:06] stub: hey; can we do a catchup @ uhm, 2h from now? [06:07] lifeless: ok [06:08] cool,t hanks [07:40] wallyworld_: How do I see the bug title? [07:41] ECONTEXT [07:41] If it's ellipsised in the only place it's displayed, how do I see it? [07:41] if it's too long then too bad [07:41] or words to that effect [07:42] But the font is huge and you can fit like nothing in one line [07:42] In terms of bug title [07:42] For projects it might be reasonable. [07:42] the bugtitle issue was the one mentioned as needing fixing. perhaps a longer allowed title is required [07:43] maybe we allow 2 lines or something [07:50] good morning [07:56] okay, some let's play writing some debbugs tests [07:56] mgz: Hahahahaha === michaelh|away is now known as michaelh [09:09] Hi launchpadders. Right now source packages from the extras.ubuntu.com archives are not available in Launchpad through https://launchpad.net/ubuntu/+source/ - could someone tell me (roughly) what would be needed to get source packages from extras show up in Launchpad? [09:15] From Launchpad's point of view, extras.ubuntu.com is just another PPA. [09:16] So they do show up there, but only under the "untrusted archives" expander (e.g. https://launchpad.net/ubuntu/+source/alg3py). [09:20] Hm [09:20] Why should they show up under Ubuntu? [09:20] They're not part of or maintained by Ubuntu. [09:32] that's a good point. I was thinking in terms of were to report bugs, but hadn't considered the fact that they're not really part of Ubuntu [09:39] wgrant, but you can still report bugs against e.g. https://bugs.launchpad.net/ubuntu/+source/alg3py right? So what do you think could be the best approach to report bugs against extras applications in LP? [09:41] dpm: Hm, I thought we used to hide the link. It nowadays seems to let you into the form, but won't let you submit. [09:41] So no, you can't actually file bugs. [09:41] It just tempts you to do it [09:42] I'm not sure what the best solution is [09:42] But forcing them under Ubuntu like partner is probably not it. [09:42] where do the debbugs things live on disk? could do with looking at some real data to see if my tests are valid [09:42] config has /srv/bugs-mirror.debian.org/ but don't know what server, or the process that creates the files [09:44] ok, thanks wgrant [09:46] mgz: http://www.debian.org/Bugs/Access "Accessing the raw bug data" [09:47] ah, so we have a full mirror rsynced? [09:47] do you know where that lives? [09:47] No [09:48] But it's easy enough to rsync at least a fragment of it for yourself [09:48] right, I just need to try and get a reasonable fragment without killing this http connection :) [09:49] (specifically I want some bugs with non-ascii characters in headers, just to check) [09:49] I suspect that these days any 1% of the active spool would do, so pick a subdirectory ... [09:49] It used to be on macquarie then synced to loganberry, but the former copy moved recently, AIUI [09:58] mgz: the network diagram ops have lists the machine name I believe. [09:59] loganberry works for me [10:11] lifeless: Have you fixed the crontab for the PPR move? [10:12] wgrant: no, I didn't think it was on autodeploy [10:12] wgrant: fairly sure its manually updated. [10:14] Ah, probably true,. [10:16] so I was going to completely ignore it and wait for screams, if any. === michaelh is now known as michaelh|away [12:48] anyone have advice for https://answers.launchpad.net/launchpad/+question/205338 [12:49] I can see that https://launchpad.net/ubuntu/+source/openconnect is definitely not the same project as https://launchpad.net/openconnect [12:49] However, I don't see the former as being imported anywhere. [12:49] i'm also hesitant to rename an existing project and import something new in its place. [12:49] Thoughts? [12:54] jam: you have a reasonable fix now, from the question? [12:55] mgz: I think so [13:01] seems unexpected success in the lp test suite doesn't count as a failure? [13:05] gmb: what did you do previously to make the launchpad test runner understand other test results? [13:06] mgz, I'm sprinting today so I can't give you a good answer right now... Is this under Python 2.6 or 2.7? [13:06] er, I'm testing in precise, so 2.7, but that's a good point [13:07] mgz: LP's test suite doesn't have any expected failures. [13:08] How're you trying it? [13:08] ah, so I shouldn't use that feature at all... [13:08] it derives from testtools so appears to work, but the zope runner is ignorant [13:09] We make tests pass instead :) [13:10] I'm (sometimes) in the habit of committing tests, then fixing the bug and flipping the expectedFailure clause [13:10] but I can just not do that. [13:12] also have some assertions that are not currently unused code that I guess can just be deleted, like [13:12] + name, email = tracker.getBugReporter("1") [13:12] + self.expectFailure("No decoding on headers done", [13:12] + self.assertThat, name, Not(Equals("=?UTF-8?Q?Jes=C3=BAs?="))) [13:13] + self.assertThat((name, email), [13:13] + Equals((u"Jes\xfas", "jesus@example.com"))) [13:39] morning... I am having a problem bootstrapping lp-dev-utils. "pkg_resources.DistributionNotFound: zc.buildout==1.5.2" (I have python-zc.buildout 1.52 installed globally) .... stack trace of make output: http://paste.ubuntu.com/1137808/ [13:39] anyone have an idea? === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [13:48] I'm trying to go to: https://launchpad.net/projects/+review-licenses but now it is generally timing out [13:48] I think it succeeded 1 time in about 8 [13:48] (It worked a bit ago, but then I reviewed a bunch of projects, so maybe there is a data-bug where one of the new projects to review is causing the timeout?) === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: 4.0*10^2 [14:36] cgoldberg, hey. Does a plain `make` not work? I expect it's something to do with lp-dev-utils expectations about there being a download-cache. [14:38] deryck, plain `make` does nothing (Nothing to be done for `all'.) [14:38] hmmm [14:39] `make bin/buildout` and calling bootstrap.py directly gives same error as my paste [14:39] i've tried with, and without zc.buildout installed system-wide [14:39] cgoldberg, ok, looking at my copy now..... [14:39] deryck, kk thanks [14:40] i've also tried running bootstrap.py with -t and -d options [14:43] cgoldberg, what are you trying to do? I didn't even realize we needed a Makefile in there. It used to just be a collection of scripts. [14:44] deryck, right... so lifeless moved pageperformancereport (prr) into there from lp:launchpad. i'm trying to run the tests: test_pageperformancereport.py [14:44] deryck, the README is updated... look at the last part of it [14:45] i'm not sure if he added the bootstrap/make stuff or that was there already.. but seems it's needed [14:46] cgoldberg, ah. reading the makefile, I suspect you need `make download-cache && make eggs` before `make bin/buildout`. [14:46] deryck, i'll try [14:47] ok [14:47] deryck, "make: `download-cache' is up to date." ... same for eggs [14:48] cgoldberg, do you have a download-cache directory in the tree? [14:48] deryck, yup [14:49] cgoldberg, hmmm, I'm not sure then. Maybe check with lifeless when he is around. [14:49] with a ton of tarballs/zips under /dist [14:49] deryck, yea.. fraid i'll have to.. was hoping to get through this before he arrives later [14:49] cgoldberg, I would think if you had buildout in the download cache, or system wide, either one. it should work. [14:50] deryck, me too :) [14:50] cgoldberg, assuming the version is indeed 1.5.2 [14:50] right.. which it is [14:50] deryck, well.. thanks for looking anyway! [14:51] cgoldberg, np! sorry I couldn't help. [14:53] cgoldberg, either remove the global installation, or run the bootstrap in a --no-site-packages virtualenv (which can then be deleted I think) [14:54] buildout bootstrap fails if there is a system-wide install of the same version as the desired one [14:59] james_w, ahh..i tried removing my system-wide buildout.. didn't help. I'll try in a virtualenv [15:02] adeuring, let's use the standup hangout. [16:03] ocr: please take a look at === deryck is now known as deryck[lunch] === cjwatson_ is now known as cjwatson [20:32] rick_h_, no hurry, but let's use the standup hangout again when you're ready [20:32] ok, jumping in [21:10] sinzui: o/ [21:10] deryck: hi [21:10] both of you just got mail [21:10] deryck: we were going to do a call this morning, but neither of us put it into google calendar. [21:10] lifeless, dang, dude. I completely forgot. *sigh* [21:11] lifeless, I need to go pick up the dog too. [21:11] lifeless, shall we calendar something for my monday afternoon, your Tuesday morning? [21:12] sure [21:13] thanks, really sorry about dropping that again. [21:13] lifeless, I'm not sure what time for me works for you, so feel free to calendar me for a time that works for you. [21:13] i'll be around whenever then. [21:13] sinzui, thanks for the mail. I'll need some time tonight to get it all in my head, but it's nice to have a good list like that. [21:14] deryck: I cannot say that is in my head. That might be a fiction about what was done [21:15] well, I don't mean it will stay in my head. :) [21:15] Get my head around it, might be a better way to say it. [21:17] gary_poster, ping [21:17] Hey Ergo^ [21:20] sinzui: your 12 step program is short a step [21:21] So is my head [21:23] :> [21:24] wgrant: online? [21:25] jcsackett: 0724 for him. [21:25] * lifeless expresses doubt about onlineness [21:25] lifeless: fair. we do standup in 30 min, wondered if he might be online early. [21:26] oh definitely worth checking [21:26] never know your luck in the big penal colony [21:26] * jcsackett laughs [21:27] well, without wgrant, sinzui. i am *finally* able to focus on that banner branch today and i think discussions from last night are wrong. [21:28] sinzui: IPrivacy, in this instance at least, would only be used for display of the banner...which is a very different thing from who all can *see* it. [21:28] yes. [21:28] and the rules we agreed to adapt are all about seeing. i think the archive being private is enough to say show the banner. [21:30] jcsackett: it is a start certainly. But is two people look at the same build. One gets a 403, so ask the other to look and he sees it. the page might as well show the privacy banner so that user to can tell person one that is the case [21:31] I think the ambiguity of the bug is that user know that not everyone can see the page and have a reason in their head that something might be private... [21:31] and per you decision, the archive is going to leap to the user's mind [21:32] what i'm saying is that i think that's the case. the archive being private is the first check for 'View'. so if it's private, the build is private. so someone else goes to look at it and gets in b/c they match another rule. but they'll see it's private. [21:32] e.g. I don't think there's a reason you get a 403 looking for it when the archive is public. [21:36] okay [21:37] I think that fixes jml's concern === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 [21:37] ok. [22:07] jcsackett: The build archive being private is required, but not sufficient. [22:08] I can copy the source+binaries to the Ubuntu primary archive [22:08] Then it is no longer private. [22:08] rick_h_: http://paste.ubuntu.com/1138589/ + http://paste.ubuntu.com/1138605/ - a WIP [22:09] rick_h_: imbrandon is hacking the js bits together [22:11] wgrant: but in terms of viewing the build, shouldn't we still display the banner? b/c there is still private info on the build (e.g. the existence of the archive), right? [22:12] jcsackett: But the build is publicly available, therefore the existence of the archive is disclosed. === heroux_ is now known as heroux [23:00] wallyworld_: My X201 is 1280x800 [23:00] wow, that's sad [23:01] in 2000 i would expect that, not 2012 [23:01] wallyworld_: It also weighs 1.4kg and has 8 hours battery life? [23:01] mine weighs about the same, battery is only 4h [23:02] but i hardly ever run on battery [23:40] lifeless: why do the iframe if it's a GET request anyway? [23:41] and are we thinking more than one per page? because the instances can clobber in this plain object fashion vs creating a new instance of an oops [23:41] but I guess there's not much to change atm since things like action/etc aren't populated [23:42] rick_h_: its existing code imbrandon is using [23:42] ah gotcha [23:47] wgrant: An awful lot of the failures are NoReferrerError: No value for REFERER header [23:47] rick_h_: #juju is where we are talking about this [23:47] StevenK: Ah [23:47] StevenK: I guess people might be posting forms directly [23:47] Right [23:47] StevenK: Rather than properly submitting them [23:48] In which case you'll need to either properly submit them or forge a referer [23:48] wgrant: browser.submit() , isn't it? [23:48] Right [23:48] Maybe [23:48] It may be on the form [23:48] Can't remember. [23:49] admin_browser.getControl('Delete').click() [23:49] That's wrong? [23:50] That should work. [23:52] wgrant: http://pastebin.ubuntu.com/1138729/ [23:52] StevenK: Do other things work? [23:53] Perhaps the new testbrowser doesn't send a referer at all