[00:09] mthaddon: i think i will ping the losas tomorrow to help with the mailing list archive regen. hope the rollout goes smoothly! [00:10] barry: rollout is now done, and wasn't smooth :-) [00:10] spm: oh noes [00:10] spm: would you like to try converting one mailing list archive with me then? [00:11] spm, /topic or it didn't happen :) [00:12] jml: don't tempt me to make it not happen :-) [00:12] haha [00:12] spm: can you make it unhappen? [00:12] "launchpad unreleased, uptime was ten minutes. have a nice day" [00:13] jml: Its still giving me out http://paste.ubuntu.com/225202/ any ideas? [00:13] barry: technically we did :-( [00:13] jml: that should read: downtime was negative 10 minutes. i think einstein proved negative downtime is equivalent to positive uptime [00:13] spm: :( [00:14] Shane_Fagan, 'sudo make install' [00:14] leonardr: bug 387487. i'm going to uninvalidate it because this is exactly my problem [00:14] Malone bug 387487 in lazr.restful "Allow a subordinate entry resource under a resource where there would normally be a field" [Undecided,Invalid] https://launchpad.net/bugs/387487 [00:14] um [00:14] openid doesn't seem very happy [00:14] spm: OpenID discovery error: HTTP Response status from identity URL host is not 200. Got status 404 [00:15] bleh [00:15] https://login.launchpad.net/ is, indeed, 404in [00:15] g [00:15] !!! [00:17] sudo make install what? [00:18] Shane_Fagan, in the Launchpad tree (~/launchpad//lp-branches/devel by default, I think), run 'sudo make install' on the command line. [00:19] Nope still didnt work and that folder is empty [00:19] hmm. [00:20] I think the prob is that launchpad went into read only mode when I was branching the first time and then bzr seg faulted [00:20] Shane_Fagan, I need more context for the error message. [00:20] Shane_Fagan, that's quite likely. [00:20] So this is the second time I tried it [00:21] pkern: You just need to add an ArchivePermission to add an uploader - there's even a webservice API to do it. [00:22] Give me a sec and ill pastebin the whole lot [00:22] Shane_Fagan, thanks. [00:22] jml: http://paste.ubuntu.com/225231/ [00:23] ahh, I see. [00:24] Shane_Fagan, so this was from your second attempt, right? [00:24] Yep [00:24] And it got past it the first time [00:24] Shane_Fagan, that makes sense. [00:24] Shane_Fagan, the underlying bug is that rocketfuel-setup is pretty bad at recovery... [00:24] Ah [00:25] http://paste.ubuntu.com/225243/ [00:25] Shane_Fagan, that's the snippet from rocketfuel-setup [00:25] you see line 12? [00:26] Shane_Fagan, because 'devel/' exists, the script assumes you've got a full branch of Launchpad [00:26] Ah so can I remove it ? [00:26] Shane_Fagan, yeah, just the devel/ directory [00:26] Shane_Fagan, then try running the script again. it just might work. [00:26] Ill remove lp-branches too [00:27] Shane_Fagan, if you'd like, you probably don't have to though [00:27] and you might save some time by not removing it. [00:27] Ah that worked [00:28] Shane_Fagan, glad to hear it. [00:28] Maybe we can fix the rocketfuel-setup to be a little more flexible [00:29] Shane_Fagan, that would be wonderful. [00:29] Shane_Fagan, I can help you get a patch ready, if you'd like [00:29] Well first I want to hack something up for apturl because I want that for answers [00:29] *nod* [00:30] * Shane_Fagan loves apturl [00:30] I've got to head afk for a bit now. [00:30] Sure thanks for the help [00:30] no worries. [00:31] Shane_Fagan, I look forward to seeing your apturl patch. there are a few Canonical Launchpad devs around for the next few hours, so just ask if you need a hand. [00:31] * jml afk [00:34] sinzui: still around per chance? [00:36] jml, mwhudson: do either of you know of a documentation place in the new lp tree for general doctests? Especially general pagetests? [00:36] I'm wanting to put some readable docs about the ++oops++ stuff [00:37] thumper: i guess all that stuff is still in canonical/launchpad [00:38] mwhudson: hmm... [00:38] mwhudson: that is where I have it now [00:38] mwhudson: I'd love to get it moved [00:38] thumper: canonical/launchpad/webapp doesn't have a new home yet [00:38] afaik [00:38] mwhudson: perhaps the build engineer has some work to do :) [00:38] it belongs with that code really i guess [00:38] heh === spm changed the topic of #launchpad-dev to: Launchpad Development Channel | https://dev.launchpad.net/ | Please use #launchpad for support. | https://launchpad.net/~launchpad-dev | Get it: https://dev.launchpad.net/Getting | http://people.canonical.com/~herb/ | http://paste.ubuntu.com/ [00:56] oh FFS [00:56] why are our pagetests so sucky [00:56] because they are doctests? [00:57] because doing integration tests with sample data is a really bad idea? [00:58] because they test the wrong thing [00:58] thumper: I have some ideas about the OOPS stuff [00:58] d) all of the above! [00:58] jml: I've got it sorted now [00:58] thumper: Common denominator: Because. [00:58] but I have to go, because my flatmate's student has turned up 50 mins early! [00:58] * jml relocating [00:59] Changing page layouts /could/ break lots of tests. I propose we replace them instead of fix them [00:59] sinzui: hey [00:59] hi lifeless [00:59] sinzui: I would like to see bugs and blueprints be less different [00:59] sinzui: as in, I love bugs, but hate blueprints :) [00:59] lifeless: issue type? [00:59] * sinzui feels the same [01:00] sinzui: I agree, by and large, in a "it's one in the morning what the hell am I doing in #launchpad-dev" kind of way. [01:00] (about the tests, that is) [01:00] * gmb heads to bed. [01:00] good night gmb [01:00] sinzui: I'd like to be able to say to a bug, 'depends on other bug' [01:01] and, 'I think this is a 5 hour problem' [01:01] and finally, get reports with that data [01:01] lifeless: +1 on those [01:01] but thats all - the approval process stuff and so on isn't something we use in any of the projects I contribute to [01:01] anyone know BeautifulSoup well? [01:02] I want the second last html comment in the body [01:02] thumper: http://www.crummy.com/software/BeautifulSoup/documentation.html [01:02] sinzui: thanks [01:04] lifeless: I don't hack on bugs, I sometimes hack on blueprints on my own time. I l want better dependency handling on both apps. I want to qualify the dependency as essential, expected, or optional [01:05] I'd actually like blueprints to fade away, into a cleaner single app. But I know that isn't a universal viewpoint [01:05] hmm, why do you need a type on the dependency? [01:06] lifeless: I suggested that on more than one occasion. I was that was not likely to ever happen and that I should instead focus on common behaviour [01:07] lifeless: When I plan a big project, I want to say features 100% implemented. We cannot say that about our specs, not even if we break them into atomic parts because the dependency is absolute [01:08] * thumper is almost finished with the oops on demand branch [01:08] lifeless: Many stories depend on common features (other stories), but the feature might be essential one and optional in another [01:09] sinzui: if its optional in the other, is it really a dep? [01:09] sinzui: I don't object to an optional type flag [01:09] I want a library of ideas that I can define features from using better dependancies [01:09] I just don't really get it :) [01:11] lifeless: I was toying with the idea of showing bugs linked by blueprint in an alternate view of the milestone page...I expect to have a week off next month [01:12] * thumper afk for a while [01:12] sinzui: that would be interesting. It still causes duplication though, which is my major objection to blueprints [01:13] yes. I really want to solve that. I really don't want 4.0 stories to be all in a wiki, but I cannot bring myself to use blueprints [01:13] yup [01:13] and I don't believe its a matter of polish [01:23] back [01:25] So any canonical devs around I just have to ask a question [01:25] always just ask :) [01:25] questions are free :) [01:26] Oh ok I thought I should ask first [01:26] Ok so I want to handle apt:// just like the way http:// is handled so where should I be looking? [01:27] where do you want to handle apt:// [01:27] answers [01:27] apturl would be a lot easier than going go sudo apt-get install package [01:29] Because then it takes the scary command line away from new users [01:29] do you mean "I want text typed into answers with apt:// urls to get rendered as , like happens for http://"? [01:30] Yep [01:30] Thats exactly what I mean [01:31] It uses fmt:email-to-html. [01:31] * wgrant finds that. [01:31] ooh, I changed this code quite recently [01:32] canonical.launchpad.webapp.tales.FormattersAPI.text_to_html and above. [01:33] That's a nice regex. [01:34] Shane_Fagan, tests are in lib/canonical/launchpad/doc/displaying-paragraphs-of-text.txt [01:34] Oh good [01:35] './bin/test -cvvt displaying-paragraphs-of-text.txt' will run the tests [01:35] * jml puts on his best Captain Planet voice, [01:35] "The power is yours!" [01:36] Good, its a feature I really want [01:41] jml: do you think it would be useful? [01:42] * wgrant does. [01:42] Shane_Fagan, I reckon so. [01:42] Its something I complained a lot about myself because I couldnt see why it wasnt used [01:44] But I suppose ye have a lot better things to be hacking [01:44] subjectively better, perhaps. [01:44] So anyway ill go and make it. Oh and congrats on the open sourcing [01:45] Shane_Fagan, thanks :) [01:48] sinzui: There seems to be a bug in your bug closing script - you apparently just released Launchpad sinzui, not Launchpad 2.2.7. [01:52] wgrant: your are correct. I will look into it [02:08] The test suite makes my laptop unhappy :( [02:09] the test suite makes everything unhappy [02:09] but laptops particularly, yes [02:09] wgrant, unhappy how? select at least two from: morbid, maudlin, melancholic, stressed, depressed, upset, troubled, vexed [02:10] using ec2test [02:10] jml: All of the above. [02:10] * wgrant likes the look of the 3.0 project page. [02:10] Interestingly, it seems to be returning to the 1.0 project group page style [02:11] lifeless: we haven't granted non-canonicalers access to the ec2test image yet aiui, and it currently still requires access to devpad aiui [02:11] i guess this should all change... [02:12] well, all the code to create an image is out there, isn't it? :) [02:12] uh, i _guess_ ... [02:12] We also don't have the code. [02:12] hell, bzr's ec2test uses stock images [02:13] wgrant: you don't? [02:13] lifeless, bzr has fewer dependencies and requires less system configuration [02:13] :P [02:13] letse play spot the troll [02:13] lifeless, `but I agree, it's probably possible to make an ec2test.py replacement with currently public code. [02:13] <- the troll [02:14] lifeless: The ec2test stuff is in lp-dev-utils, which is still in the proprietary realm. [02:14] ah [02:15] * mwhudson stares at buildbot's estimate for the end of this build [02:16] buildbot is also still private :( [02:17] i don't know if there are any good reasons for that [02:18] * wgrant wonders what is so special about the tests in lp.bugs.browser.tests.special [02:18] jml: i don't completely understand your email about soyuz permissions [02:18] (surprise!) [02:19] mwhudson, me neither. [02:19] mwhudson, how /what can I clarify it? [02:19] in particular i don't understand how latest_published helps get a sensible archive [02:20] my understanding is that the archives are: primary, partner and a bunch of ppas [02:20] (is an archive tied to a distro?) [02:20] and primary has a bunch of components (main, universe, etc) [02:21] (ppas sort of pretend everything is in main?) [02:21] PPAs override everything to main. [02:21] partner only has stuff in parter. [02:21] primary can have stuff in anything. [02:22] wgrant: partner is a component as well as an archive? [02:22] mwhudson: Yes. It's very broken. [02:22] man, the crack must have been good in 2004 [02:22] mwhudson, an Archive has a Distribution [02:22] Partner is a new thing. [02:22] true [02:22] well [02:22] new, as in 3 years or so, right? [02:22] Two or three years, yes. [02:22] mwhudson, a Distribution also refers to a main_archive, so assume it's one Distribution to many Archives. [02:22] What version of postgres do you need? [02:23] Shane_Fagan, 8.3 [02:23] mwhudson, a publication has a component and an archive [02:23] mwhudson, whether the archive is sensible for these purposes is beyond my ability to judge. [02:23] jml: if i ask something about pockets, will i regret it? [02:24] bigjools suggested last night that it wasn't sensible, IIRC. [02:24] mwhudson, oh crap, I knew I forgot something. [02:24] jml: it seems to _me_ (and what do i know?) that for an official source package branch, the archive you care about is the primary archive [02:25] wgrant, I derived from: [02:25] add a new property to it, latest_published (trivial, just return self._getFirstPublishingHistory [02:25] then you have in your hands a component and an archive [02:25] jml: and on the face of it, i don't see why latest_published might not refer to a ppa [02:26] mwhudson, in my relative ignorance, I'm inclined to agree with you. [02:26] bug 347768 [02:26] Malone bug 347768 in launchpad-code "Allow anyone with upload rights to write to a package branch" [High,In progress] https://launchpad.net/bugs/347768 [02:26] mwhudson: Because they'll be excluded. [02:26] * jml has only had a chance so far to ask the question and type up the summary. [02:26] * mwhudson reads [02:26] It's already done in lots of places already. [02:28] ISourcePackage.latest_publishing would use ISourcePackage._getFirstPublishingHistory, which only gets it from the distro's official archives. No PPAs. [02:30] * mwhudson chases things around a big [02:30] bit [02:32] wgrant: i see you are right [02:33] but ehhh [02:33] It's all a bit strange. [02:33] I really think that verify_acl should be turned into a function that takes a person ('signer'), an archive and a sourcepackage. [02:33] jml: Pocket! [02:33] wgrant, it doesn't use pocket right now. [02:34] isn't there something about the release pocket being read only after, well, the release? [02:34] or is that done at a different level? [02:35] UploadPolicy.checkUpload, apparently [02:39] i wonder if there's a way to kick off a build of the bzr builder without waiting for 22.5 hours [03:05] cprov, hi [03:05] jml: hi, give me one minute, I need coffee. [03:05] cprov, np [03:05] http://paste.ubuntu.com/225594/ -- diff against db-stable [03:06] but that's got a dependent branch [03:06] I'll split the diff up. [03:06] ICanHasLinkedBranch. Nicely done. [03:07] jml: k [03:07] wgrant, :D [03:08] wgrant: there is also IHasLinkedBranch, which is _entirely_ different [03:08] http://paste.ubuntu.com/225599/ -- that's the new branch, official [03:08] mwhudson, yeah, we need to fix that. [03:09] jml: right, you already have 'suite_sourcepackage' which is SP (SPN + DS) + Pocket [03:09] http://paste.ubuntu.com/225601/ -- that's the ubuntu-packages branch, which makes lp:ubuntu/package work. [03:09] cprov, yes. [03:10] cprov, I want two things: [03:10] jml: for upload ACL purposes we theoretically also need IArchive [03:10] a function from (suite_sourcepackage, person) -> boolean, "can this person upload" [03:10] and a way of granting a person upload permissions, to be used in the tests [03:11] I think the second is much more straightforward than the first [03:13] cprov, so where do we get the archive from? [03:13] jml: okay, having a SomenthingMeaningful.canUpload(person) available is more valuable for testing and doesn't exclude the possibility of it bound to the lp.Append permission on the object later, for UI purposes. [03:13] +1 [03:15] jml: as mwhudson pointed we can safely assume PRIMARY (distribution.main_archive) for all DSP not published in the 'partner' component. [03:15] ok. [03:15] jml: it's never overridden. [03:16] jml: I don't see this assumption making ppa-package-branches any harder to implement in the future. Do you ? [03:17] * jml has less than 20 minutes of battery life left [03:18] cprov, I don't. [03:19] jml: once you have an suitable archive available (or assumed) you can figure out the current component (archive.getPublishedSources(spn, series)[0].component ... please make it elegant :)) [03:20] cprov, so, I'm really very strongly thinking of refactoring verify_acl into a function that takes archive, a person (signer), and a SuiteSourcePackage. [03:20] cprov, and raises exceptions instead of calling reject() [03:20] cprov, would this be appropriate to use (probably together with some checkUpload() equiv.) [03:20] for package branch permissions. [03:21] * jml has less than 10 minutes of battery life left [03:22] jml: we can to that, but it's very likely that it will be something else than the current spread checks. [03:22] why would it be different? [03:22] jml: in a way we would port nascentupload to use this new thing too [03:22] cprov, right. [03:23] cprov, it would be making verify_acl call a function that embodies all the logic of 'can this person upload to this pocket of this package in this archive' [03:23] jml: right [03:23] I'm kind of surprised you don't have a function like this already, tbh. [03:24] cprov, anyway, if you think that's a good idea, I'll make it happen. [03:24] it's definitely a good idea and you can count on our help. [03:24] cool. [03:24] I'm going to move to a power point. back in 10 [03:27] It would be useful to have on the dev wiki a list of who is in which team, and in which timezone they reside. [03:30] cprov: soyuz, sleep is for the weak standard time [03:32] mwhudson: I confess sleeping is more tempting at home, but not that much ;) [03:33] back. [03:36] let's try that again. [03:37] cprov, are there any tests for verify_acl? [03:38] jml: yes, blackbox-style, though [03:39] jml: lib/lp/archiveuploader/tests/test_uploadprocessor.py [03:39] thanks. [03:40] jml: one of the advantages of extracting and encapsulating that code would be allowing us to have quick and beauty unittests [03:40] yes, I was just thinking thta. [03:40] this is big enough for another branch, I think. [03:42] * cprov nods [03:55] jml: can i get you to review a branch? [03:55] i'm not quite sure if i've got enough tests, but i guess you can tell me that when you review it :) [03:56] mwhudson, sure thing. [04:00] jml: https://code.launchpad.net/~mwhudson/launchpad/puller-job-scheduling/+merge/9174, you should have mail [04:02] * wgrant has today developed a particularly strong dislike for tests that rely on dict ordering. [04:03] OMG! [04:04] we're getting a sysadmin guy in Wellington [04:04] spm: You'll have someone to hit up locally now :) [04:04] oh fun, more kiwis [04:05] wgrant, you haven't found them in Launchpad, I hope. [04:05] \o/ [04:05] thumper: who is it/ [04:06] lifeless: Paul Collins, starting 10 Aug [04:06] excellent name :) [04:06] thumper: heh, you take longer to get through your email than me [04:06] jml: I have. It's not directly printing a dict, but rather generating a list of bug notification emails based on dict order. [04:06] :( [04:06] thumper: aye [04:06] mwhudson: :) [04:07] wgrant, I'll gladly review a patch to fix that. [04:07] wgrant: any chance of a patch to fix it? :) [04:07] I attempted to change the dict keys (previously strings) to Storm objects, and they hash differently each time... [04:07] * wgrant will attempt to fix this. [04:07] wgrant: compare two dicts [04:07] But it's a very very long doctest. [04:07] wgrant: or use sorted() on both sides [04:07] lifeless: Right, I plan to use sorted. [04:08] Then I have to reorder a thousand lines of doctest. [04:08] welcome to doctest [04:08] have I told you what I think of them? [04:08] wgrant: you are aware of the "shame" motivation for not open sourcing, i presume? :) [04:08] I think I saw you complaining about them in here recently. [04:08] mwhudson: Heh. [04:09] wgrant: oh, I don't complain, unless I'm forced to touch em. [04:09] Some of the Soyuz doctests were good explanations. [04:09] Heh. [04:09] But bugnotification-sending.txt is ... not. [04:13] we do have a helper for testing dicts in doctests [04:13] I think [04:13] I've forgotten what it's called. [04:14] it's not that helpful then? [04:14] It's not a dict when the doctest gets hold of it. [04:14] That would be too easy. [04:14] It's a list of strings which happens to have been created by iterating through a dict. [04:14] wgrant: lib/lp/code/doc/branch.txt is particularly terrible [04:15] wgrant: this is the part about email_notifications in there? [04:16] ajmitch: There's a lot more than one of those, but yes. [04:17] ajmitch, I don't write many doctests. [04:19] mwhudson: are you suggesting wgrant cleans up our crappy tests? [04:20] not really [04:21] * jml back to package-permission-love [04:22] cprov, any thoughts on which module this code should live in? [04:22] it's interesting that https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel disappears from the default view as it's set as merged now [04:23] ajmitch, oh, that's easy enough to fix [04:23] * jml fixes [04:23] grr [04:23] which sort of makes sense, but I was briefly wondering why it disappeared :) [04:23] jml: can you create a devel series for launchpad? [04:23] thumper, I think so. [04:23] jml: I looked but couldn't figure out how [04:24] that way lp:launchpad/devel will work [04:24] ajmitch: it is the branch scanner being clever :) [04:24] ajmitch: it doesn't update series branches [04:25] jml: I guess archiveuploader is the right place. [04:25] cprov, thanks. [04:25] thumper, https://edge.launchpad.net/launchpad/devel [04:26] jml: just out of interest, where is the link to create a new series? [04:26] thumper, https://edge.launchpad.net/launchpad "Register a series" [04:27] also I noticed that konqueror formats code review comments like FF3.5, with a non-wrapping proportional font [04:31] which python has class decorators? [04:31] 2.6? [04:31] * jml tests [04:31] spm: a question [04:32] mwhudson: an answer [04:32] yeah 2.6 [04:32] spm: i'd like to produce some data inside the internal xmlrpc server that i'd like to end up on a graph [04:32] mwhudson: 42 [04:32] spm: any idea how to do that? [04:32] mwhudson: sure - point us at a way of getting the numbers, or numberise? [04:33] spm: of course, i should simply dump the data into our separate-from-main-database *cough* [04:33] spm: i'm thinking more where to store the data [04:33] oh [04:33] is this something we'd ping on a regular basis? [04:34] mmf maybe it can wait until we use the job system properly, then we can pull it from the database [04:34] * jml is curious [04:34] spm: to be specific [04:34] spm: there's this method, acquireBranchToPull, that returns a branch that's waiting to be pulled [04:35] spm: i'd like to log somewhere how long it's been waiting [04:35] right now there's not really anywhere in the db to log this [04:36] mwhudson: hmmm [04:36] i think using a BranchJob probably really is the right answer [04:36] jml: is this making sense to you? [04:36] is this logged anywhere? request/start/fin times? [04:36] mwhudson, yeah. [04:37] spm: currently, no [04:37] mwhudson, 'how long it's been waiting for' is interesting, but it's not ultimately the value we'd like to optimize. [04:37] jml: which is what? how long from request until completion? [04:38] mwhudson, for hosted branches, it's how long from push finished until pulled&scanned. [04:38] jml: that's less under our control though [04:38] jml: for example, jelmer's open office branch was always going to take ages [04:39] jml: from my pov as an integrator, i think all i can do is squeeze on the time spent not working [04:40] mwhudson, well, I don't mean to say it's either / or. [04:40] jml: ok [04:45] jml: to throw the question back at you - if you know that inro (push fin'ed to pull/scan) what action(s) would you expect to take given that info? [04:45] s/inro/info/ [04:46] spm: if that were all the information I had, I'd ask for more numbers :) [04:46] jml: heh [04:47] spm: but it is the number that we ultimately care about [04:47] is a serious question tho - the difference between reporting vs analysis. the numbers are useless in and of themselves in a report. it's the actions those numbers drive that matters. Else it's so much "Gee Whiz" [04:48] spm: in this case, because there are so many parts to the system, and because the design for quite a few of those parts is changing, it makes sense to have an overall thing that measures what we value [04:48] certainly. so we can? add more servers? speed up the code? [04:48] spm: we know the problem fairly well, so we are unlikely to do a local optimization that causes a global sub-optimization, but it's still worth being careful of it [04:48] both :-D [04:49] spm: a particular knob to tune is how many branches we pull in parallel [04:49] spm: see the impact of bzr upgrades, see the impact of branches moving to a new format, see how database changes affect the scanner etc. === Ursinha is now known as Ursinha-afk [04:50] coolio. I wasn't objecting btw, just asking in a way to help drive a foxus on what you *really* need, vs want. if you ken. :-) [04:50] damn firebug! [04:50] spm: I understand. [04:50] foxus. sigh. focus :-) [04:50] it lies! [04:50] spm: I've been wanting to do it for a very long time :) [04:50] firebug tells me it is using white-space: pre-wrap [04:50] but konq view source tells me no [04:50] (and the source code itself) [04:51] thumper: "computer say no"? [04:51]