=== maxb_ is now known as maxb [00:13] jml: could you enlighten me to how it's hocked up? [00:14] thumper, IBranchSet is exported as a collection, getByUniqueName is a read operation on that collection [00:14] gotcha [00:14] jml: thanks [00:14] thumper, np [00:18] mwhudson: when is good for you? [00:19] thumper: argh [00:19] thumper: about an hour? [00:19] mwhudson: ok [00:19] i haven't had lunch yet [00:19] mwhudson: at least it'll timebox our discussion [00:19] mwhudson: I have to go get the girls at 3 [00:19] thumper: ok === jamalta is now known as jamalta-afk [00:27] * mwhudson lunches [00:50] sinzui: ping [01:06] thumper: hello [01:06] mwhudson: hi [01:07] thumper: ready for a call now, but if you can wait a few minutes more you won't have to listen to me eating my lunch :-) [01:07] mwhudson: I can wait a few minutes :) [01:20] mwhudson: now? [01:20] thumper: yep [01:31] thumper: https://code.edge.launchpad.net/~vcs-imports/pydoctor/trunk [01:33] https://edge.launchpad.net/ubuntu/+source/gwibber/2.29.90-0ubuntu1 [01:35] https://edge.launchpad.net/~gwibber-daily/+archive/ppa [01:38] https://edge.launchpad.net/~gwibber-daily/+archive/ppa/+build/1514631 [01:40] thumper: https://edge.launchpad.net/builders/ [01:43] thumper: https://edge.launchpad.net/~launchpad/+archive/ppa/+build/1056751 [02:18] did abentley or anyone write a script that will automatically feed approved reviews to pqm? [02:18] or semiautomatically? [02:18] poolie, not that I know of. [02:19] maybe i will then [02:19] poolie, however, Tarmac behaves that way. [02:19] it automatically pulls? [02:19] do you think we should switch? [02:19] It automatically merges approved merge proposals and commits. [02:19] right [02:20] I think we should switch. [02:20] so presumably one should only use status:Approved if you really mean 'approved with no further changes' [02:20] not conditionally approved [02:20] poolie, true. [02:21] poolie, when we get a chance to work on merge queues again, that will be less of a concern. [02:22] i think it's ok, as long as people use it that way [02:22] it's probably a good idea anyhow [02:22] in piloting i find myself wanting a state that's not "in progress" but not "needs review" [02:22] like, it needs a pp to fix it [02:22] somewhere in between [02:24] poolie, if we can generalize it sufficiently, cool. [02:24] poolie, another option was to assign merge proposals to people. [02:24] i don't think adding another state is precisely right [02:24] maybe that's it [02:24] because actually i want to distinguish 'the author is going to go away and fix this' from 'i will' [02:40] so maybe assignment is right [02:47] sounds like a bug [02:57] lifeless, what sounds like a bug? [02:57] something that gets assigned to someone to do, and wanting to track that [02:58] yeah, but it's one of those vague difficult bugs [02:58] lifeless, ah. I thought you meant the discussion suggested a bug was present. [02:58] it's questionable to file it until you can make it concrete imo [02:59] poolie: I guess I'm saying that maybe merge proposals lie on the same spectrum as specs and bugs [02:59] oh i see [02:59] IAssignable [02:59] while I'd like to see be less crisp about what they are, and more malleable about what we want them to do [03:00] s/while/which/ === bjf is now known as _bjf [03:49] grr what's locking bugbranch [03:49] oh probably the scanner [04:01] lifeless: i was interested by the idea of using rpc signing rather than https [04:01] http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1928 [04:01] "use ssl if at all possible though it is slower" [04:01] poolie: yes [04:02] so i think we should fix lplib (or lazr or whatever) to hold the connection [04:02] poolie: you still get to avoid round trips though - and note that more and more corporates are deploying SSLBump and equivalents [04:02] poolie: ofh for sure. [04:03] 'still get to' how? [04:04] poolie: using message signing [04:04] using message signing and http? [04:04] yes [04:04] it's kind of a shame it's not enough [04:12] can you upload files to the librarian without a database connection? [04:13] hm [04:30] * mwhudson eods [07:36] gah [07:36] can't get balsamiq to start [07:36] :( [08:08] good morning [09:07] Morning [10:29] * wgrant is surprised to see the product/project rename actually happening! [11:01] Morning, all. [11:04] morgen [11:06] morning deryck [12:13] hey guys, I've at last a LP checkout working in a karmic VM. I'm tried to export and import GPG key from the launchpad API (cf bug #389872). Following jml's explanation, I have added the export_read… export_write… decorator to function but I don't have any idea of other stuff to add. For the attribute, appart from adding exported() to them, same thing, quite lost [12:13] Bug #389872: GPG keys not exposed in API [12:13] is there any doc or help I can get? :) [12:21] didrocks, there is https://dev.launchpad.net/API/ImplementingAPIs which explains how doing such things, [12:22] thekorn: sweet, it seems to be what I need, let get it a try :) [12:22] thanks [12:22] didrocks, did you push your code somewhere? [12:23] thekorn: not yet, I'll try to get it working first and check locally before pushing [12:23] aha, ok [12:23] It's not the easiest export. [12:24] Because there's no URL yet. [12:25] right, this part is missing on the wiki page I mentioned above [12:25] So you'll need to add a new method to PersonNavigation, and you'll need a browser:url directive in lib/lp/registry/browser/configure.zcml [12:53] wgrant: hem, I'm already fighting to do the right thing, seems more difficult then :) [12:54] (and I need to do the same for ssh) === bigjools is now known as bigjools-lunch === lionel_ is now known as lionel [13:32] well, I pushed my branch into ~didrocks/launchpad/devel but it still needs work and I'm unsure to know understand enough the documentation for the decorators handling === mrevell is now known as mrevell-lunch [13:36] adeuring, gmb, kfogel -- just a reminder to update the kanban board before the standup, to make walking the board quicker. [13:36] OK, I'll try it... [13:37] matsubara -- the qa burndown seems not to be updating any longer for 10.02. [13:37] Assuming I'm still looking at the right page. [13:37] deryck, I'll take a look [13:38] matsubara, thanks! [13:56] adeuring or gmb -- could I get one of you to review a branch for me? [13:56] deryck: sure [13:56] I need a bugs dev to make sure I haven't missed something that exists somewhere else. [13:56] adeuring, thanks! https://code.edge.launchpad.net/~deryck/launchpad/enable-tracking-link-perms-512378/+merge/19600 [13:57] adeuring, feel free to ping me in #launchpad-review to follow up. [14:10] deryck: r=me [14:10] adeuring, excellent, thanks! [14:11] deryck: why don't you check whether the user has edit permission for the project? [14:12] BjornT, because I'm dumb. :-) [14:12] BjornT, this is why I wanted someone from bugs. I felt I was missing something obvious. [14:12] but I guess that's obvious beyond bugs even. [14:13] deryck: you can do a tal:condition on something like context/required:launchpad.Edit [14:14] BjornT, ah, cool. I never knew that actually. [14:15] much simpler, too. === mrevell-lunch is now known as mrevell [14:23] i just came across bug #139855. is there any drive from canonical to resolve the bug, or in the short term is the easiest way to track usage by mirroring a PPA off-site where you have your own access.log to parse? [14:23] Bug #139855: Display stats about PPA usage === mup_ is now known as mup [14:26] adeuring, BjornT -- updated: https://code.edge.launchpad.net/~deryck/launchpad/enable-tracking-link-perms-512378/+merge/19600 [14:26] adeuring, BjornT -- look good? === bigjools-lunch is now known as bigjools [14:27] deryck: yes [14:27] directhex: it's not a priority at the moment, although we'd love to do it at some point [14:28] adeuring, gmb, kfogel -- call, in two? [14:28] yep [14:29] deryck: yup [14:30] bigjools, the post by jml presents an action list. how much of that list can be worked on by normal plebs without secret canonical web server access? [14:30] deryck: looks good [14:30] BjornT, thanks! [14:30] directhex: most if not all of it [14:31] directhex: some work was done already to scan logs [14:31] bigjools, i'll take a look then. my cpu/ram seem to be on fire, courtesy of "bzr branch lp:launchpad". [14:32] yeah it's a big branch [14:33] 243M launchpad/ [14:33] right, there we go === Chex_ is now known as ChEx === ChEx is now known as Chex === salgado is now known as salgado-lunch [14:47] bigjools, as i read this source, a thought occurs. how exactly do i *test* my changes? [14:47] directhex: depends on what you want to implement, there's a lot of work to do [14:47] UI, backend, database schema etc [14:48] bigjools, the UI is the kind of easy bit i could probably do, but unfortunately the backend stuff is a prerequisite [14:48] most of the existing testing is done in the test suite, unit tests or doc tests [14:49] well you could start by proposing some schema changes, we'll get those done, and then you can poke values in locally when doing the UI [14:49] the scanning part is a separate task [14:54] bigjools, is the bug report the best place to discuss my thoughts? [14:59] directhex: yes, absolutely [15:01] hi [15:02] i need some help setting up launchpad in my machine, anybody that want to give a hand with it? [15:03] well, I managed to install it and make it work, but the thing that i don't get is the cronscripts [15:04] i couldn't find info about how to i should run them [15:04] thanks in advance === matsubara is now known as matsubara-lunch [15:15] deryck, burndown is up to date [15:16] matsubara-lunch, thanks! [15:16] mrevell, call time? [15:16] jelmer: ping [15:16] sinzui, hi [15:17] bug 523844 does not look like a bug, it looks like a question, and I think it is one should should be able to answer yourself. [15:17] Bug #523844: experimental Debian distroseries [15:17] jelmer: do you see the Add series link: https://edge.launchpad.net/debian [15:18] sinzui: Ah, yep [15:18] jelmer: I think you have a better understanding about creating a debian series than myself. [15:19] sinzui: I hadn't realized I could do that sort of thing myself now. :-) [15:19] sinzui: I'd like to double-check that experimental isn't missing by intention though, who should I talk to about that? [15:20] jelmer: No idea. I can fix the code, but distroseries were designed for Ubuntu. Launchpad really ignores all other distros [15:21] * sinzui tries to edit lenny to see if experimental exists [15:22] Experimental does not appear to be supported [15:22] but I think that is because series cannot go backwards [15:23] jelmer: try creating the series on staging, the editing it to fix the status [15:23] jelmer: you may need to hack the URL because only losas are really offered the link [15:23] msg deryck I'll get Skype up and running [15:24] heh [15:24] jelmer: I just confirmed that you can hack the url for +edit ti set a active series to experimental [15:25] sinzui: ah, thanks [15:26] sinzui: I'll see if I can confirm that it's ok to create an experimental distroseries and then I'll give it a try. I'll close the bug. [15:26] jelmer: the missing series status sounds familiar, I think this is a bug that also affects projects [15:27] sinzui: In particular I'd like a distroseries named experimental, I'm not too worried about having its status set to Experimental [15:39] erm, https://edge.launchpad.net/debian/experimental [15:39] is that not what you are looking for [15:39] ? === Ursinha-1fk is now known as Ursinha === Ursinha is now known as Guest50427 [15:49] gmb, ping [15:49] deryck: Hi === Ursinha_ is now known as Ursinha === beuno is now known as beuno-lunch === matsubara-lunch is now known as matsubara === salgado-lunch is now known as salgado === sinzui1 is now known as sinzui [16:03] rockstar, you around? [16:35] deryck: terminology question: do we have a name for a not-yet-filled-in-by-separate-javascript-request portlet? Do we call the raw, unfilled portlet a "base" or a "template" or a "raw" portlet or anything like that? [16:36] kfogel, you mean the name of the template file itself? [16:36] deryck: well, no, I have that. I mean a word for the unfilled portlet (except I don't know if "unfilled" is what we'd use). [16:37] like if you were writing a test, and one phase of your test examined the unfilled portlet, and another phase pulled the real contents and examined those, what would be the words to describe each phase? [16:38] gmb: did you had time to put this branch for ec2 test https://code.edge.launchpad.net/~adiroiban/launchpad/bug-522188/+merge/19395 ? [16:38] kfogel, in just the test comment or doc portion? In plain English not code, is that what you mean? [16:39] deryck: well, in a doc comment, but also in the names of two methods I'm abstracting out of xx-bugs-statistics-portlet.txt (I'm moving them to pages.py, because they're needed in multiple tests now). [16:39] deryck: right now, they're called, respectively, print_portlet() and print_portlet_contents(). === beuno-lunch is now known as beuno [16:39] kfogel, ah, ok. yeah, I'm not aware of any convention for that. Those names seem fine to me. Or print_empty_portlet for the first? [16:40] deryck: the first of those names is unclear on its own; then if you see the second name it makes more sense, but I'd like to avoid that window of confusion. I'll probably go with "unfilled" and "filled" (as "empty" implies no content at all, which isn't the case). [16:40] deryck: I just wanted to check that there wasn't already a term in use within Launchpad for these two states. [16:41] kfogel, not that I'm aware of, no. [16:41] deryck: ok, thx [16:42] np [16:46] adiroiban: Strange, I thought that branch had landed; let me check [16:50] gmb: I have not received any email from buildbot. Same for this branch https://code.edge.launchpad.net/~adiroiban/launchpad/bug-340664/+merge/18452 [16:51] adiroiban: Hmm. I'll look into that. [16:51] I am not sure how buildbot is sending notification... as some of my branch did land without a notification from buildbot [16:52] adiroiban: How did only some of it land? That doesn't make sense. [16:52] I mean that for some of my branch that landed [16:52] i received an email from buildbot [16:52] others were landed without a notification from buildbot [16:53] jtv: saw the characters displayed correctly in my email from your review response. yes, they're right :-) [16:54] kfogel: different chars this time. Got the full text from google translate. Is that last character the same one I hear in the polite version of "hello"? [16:55] jtv: yup -- it means "you' [16:55] "you" [16:55] In the polite form, right? I always thought it sounded more like níŋ [16:56] adiroiban: Ah, looks like your branches were submitted close to the same time but we were in testfix mode so they didn't land and I subsequently forgot to resubmit. Apologies; I'll do so now. [16:57] gmb: no problem. thanks === deryck is now known as deryck[lunch] === henninge is now known as henninge-afk === gary_poster is now known as gary-lunch === deryck[lunch] is now known as deryck [18:37] adiroiban: See my answer to your question. I want to know if you see what I see [18:39] sinzui: http://bayimg.com/eaKPPAAcJ [18:39] this is whay I see [18:39] only „Reactivate ML” [18:40] :( [18:40] adiroiban: I will purge and report a bug [18:40] thanks! [18:41] deryck: just fyi, jcastro and I are having this conversation over in the community channel (and are about to turn it into a phone call): http://paste.ubuntu.com/379256/ [18:41] adiroiban: It is purged [18:41] deryck: it's a dicey UI question w.r.t. the bugs-with-patches stats. your opinion welcome. [18:41] * deryck looks [18:41] sinzui: yep. Many thanks! [18:43] sinzui: (you might be interested in above two comments addressed to deryck too) [18:43] adiroiban: this may not be time to celebrate: bug 471274 [18:43] Bug #471274: No option to purge list archives when purging a mailing list

[18:43] kfogel, simple fix -- just have the X bugs with patches be inclusive of closed bugs OR have +patches exclude closed by default and add filter by status. [18:44] deryck: I think I like the former, actually. Since people can sort by state once they get to the +patches page anyway. [18:45] sinzui: that's ok. we didn't have top secret stuff there :) [18:45] deryck: thanks. [18:45] kfogel, sure [18:49] jelmer: i'd like to upgrade dulwich & bzr-git so i can get my changes to do partial imports landed, will lp:dulwich and lp:bzr-git be ok? [18:49] i guess lp:bzr-git is required :-) [18:49] jelmer: thanks for merging my branch btw [18:54] bac: ping [18:55] EdwinGrubbs: ping [19:00] hi [19:01] sinzui [19:03] bac: look at https://edge.launchpad.net/ubuntu/lucid/+source/alacarte The "Unspecified" is a db hit, and when you list a lot of projects on a page, it is a costly repeat [19:04] bac: I have never liked this this ambiguous, possibly pathetic attempt to say the license is unknown. Do you want to argue for this feature's continued existence? [19:04] sinzui: not i [19:04] mwhudson, yeah, both trunks should be fine [19:05] sinzui: but that lookup is no more costly than anything else, is it? getting rid of it b/c it is ugly is one thing but i can't see how it is hammering us more than any other attributte [19:06] sinzui: advice -- I've abstracted out two functions that were formerly in a .txt test file. Now they live in pages.py -- see http://paste.ubuntu.com/379268/ . But, the code refers directly to "http://bugs.launchpad.dev/", because the functions are specific to the bugfilters portlet. I think that's okay, but I also notice this is the only .py code in that directory that hardcodes a service URL. Is this ok? [19:07] bac: true, but if +packaging shows 20 of these packages, we are doing repeat queries for the license, plus the bug supervisor, tracker, branch, and translations. I care about the last four items, but the license is a formatter quirk, and the only person who can change the license if the project owner [19:09] kfogel: I see. I think both helpers are kind of bogus because they are making assumptions about the markup or host. They break every year [19:10] kfogel: as long as the bug team is willing to do the maintenance, there is no problem [19:12] sinzui: well, I think we are (will check with the team). my question is really about the host aspect -- whether that's likely to break ever. But if you think it's no worse than any of the other assumptions in that test, then I'll leave it. [19:12] s/test/test function/ [19:15] The host is less brittle then the markup. I would question why the test helper is going into 1) a deprecated module, and 2) a module used by by non-bugs apps. I think the tests should be in lp.bugs.tests.bug [19:16] kfogel: ^ [19:17] kfogel: actually, lp.bugs.tests.bug is exactly where the helpers belong. doctests. stories, and unittests can import them as needed [19:17] sinzui: thx, will move [19:17] * sinzui wonders why lp.bugs.pagetests exists [19:17] * kfogel wonders how one is supposed to know it's deprecated [19:18] kfogel: it is canonical.launchpad. we build in lp. === gary-lunch is now known as gary_poster [19:19] kfogel: everything in canonical.launchpad was left behind during the open source apocalypse [19:20] sinzui: ahhh. Yes, I remember that, but as I wasn't developing at the time, I didn't have a reflexive understanding of it. got it [19:21] oh dear, as I feared lp.pagetests do not work because that is not a legitimate directory [19:27] deryck: ping [19:29] hi sinzui [19:30] lp.bugs.pagetests should not exist. The tests in those directories are not played by the test runner. They should be moved to lp.bugs.stories [19:30] I was about to report a bug [19:32] deryck: just doing a move to the stories directory should make the command work [19:32] ./bin/test -vvc -t cve-pages -t xx-bug-text-pages [19:33] sinzui, oh, wow. Didn't realize we had anything in pagetests still. [19:34] deryck: since this came up as I was adding some test infrastructure, if there's a simple rearrangement/move to do, I can just do it on my branch here... [19:34] sinzui: ^^ [19:34] sinzui, I'll move them this evening or tomorrow am. [19:34] ah [19:34] deryck: lib/canonical/launchpad/testing/pages.py is the file I was adding to, when sinzui noticed [19:35] kfogel, ok, you could move the tests under lp.bugs.pagetests to lp.bugs.stories if you don't mind. [19:35] kfogel, see the command above sinzui gave. it should run after the move. [19:35] kfogel, but I don't mind doing this tomorrow AM first thing if you don't want to mess with it. [19:36] deryck: I think this is an issue where someone found some tests in the old location, and tried to move them to the now location, but created a bad directory in the process. [19:36] deryck: I don't -- nearly complete non-understanding of the totality of this issue, now that I look carefully at the commands and paths above, coupled with a desire to close out my WIP, makes me defer to you :-). [19:36] sinzui, ah, right. that would make sense. [19:37] kfogel, sure. it's trivial for me. So happy to do it. [19:37] deryck: kfogel: The tests are pre-3.0. they might not pass [19:37] gah! [19:37] right [19:37] ? [19:37] they haven't been running this long rm -rf anyone? :-) [19:37] * deryck ducks [19:38] sinzui, kfogel -- I'll sort it out proper tomorrow. I have another test to fix, so no worries. [19:38] deryck: thx [19:39] deryck: you have my rs to delete any test that duplicates the authority of another test. [19:39] sinzui, will do. thanks. [19:53] hmm [19:53] jelmer: do you have any clever ideas about managing ~/.bazaar/svn-cache on the import slaves [19:54] jelmer: these directories are about 7 gigs on the slaves already [19:54] mwhudson: do we need clever ideas? [19:54] mwhudson: ah [19:54] mwhudson: are those sizes really a problem? [19:54] and as we add more slaves, each slave is going to have to do the work to rebuild the cache [19:55] which seems pretty wasteful [19:55] jelmer: well, it depends how much more it grows, i guess [19:55] 10 gigs isn't really a problem, i guess [19:55] 100 gigs we'd need to know about [19:55] 1000 would be a definite problem [19:55] mwhudson: it'll be a while before you'd hit 100 gigs I think [19:56] we should have a better mechanism in place in bzr to store this sort of cache data before that I hope [19:56] mwhudson, alternatively, we could see if we could turn off the cache for bzr-svn and see how much extra bandwidth that requires [19:56] mwhudson: since lp only does pulls we might be able to get away with that [19:58] jelmer: hmm [19:59] jelmer: the "determining revisions to fetch" step takes a considerable amount of time for large repos [19:59] jelmer: isn't that the step that the cache helps with? [19:59] mwhudson, I wonder why that is, it is much quicker locally [20:00] jelmer: f'ex https://code.edge.launchpad.net/~timmie/grass6/grass_trunk [20:00] looks like "determining revisions to fetch" too 7 hours here (!) [20:00] *took [20:00] whoa [20:01] * jelmer tries locally [20:01] mwhudson, does a lot of terminal out cause the slave process to hang perhaps? [20:01] terminal outPUT [20:01] and copying revisions took 5 [20:01] jelmer: i don't think so, it's only outputting one line a minute [20:02] it's possible the machine was slammed while this was happening [20:02] mwhudson: I've seen it with more importants so I don't think this was a glitch [20:02] *imports [20:02] man, my brain is sleeping [20:03] mwhudson, I'll see if I can reproduce it here locally doing a pull. If not, I wonder how we can profile the problems on the lp slaves.. [20:06] other things we can do are preserve the svn-cache between runs like we do the git.db [20:06] or maybe just gzip the caches, they seem to compress pretty well === salgado is now known as salgado-afk [20:06] jelmer: the reason i'm asking is because i've been asked about how much disk space to give new code import slaves [20:07] mwhudson: the svn-cache is not preserved between runs, the home directory of the slave is cleared? [20:07] jelmer: uh no [20:08] that's not what i meant [20:08] we currently preserve git.db files by copying them from the imported branch onto escudero, and fetching them before updating the import [20:09] we *could* copy the ~/.bazaar/svn-cache/$foo directory to and from escudero after and before an import in the same way [20:09] with some trickery to know which file to get, i guess [20:14] I don't think that's worth the effort to be honest [20:14] unless the "fetching revision info" step is taking too much time [20:15] oh right [20:15] that step seem to hardly be taking any time [20:16] hm, but maybe the cache already existed for that branch [20:17] seems like it took 10 minutes for that repo in fact [20:17] that's more than you'd want to spend on every import, for sure [20:17] but i guess once per slave isn't that bad [20:17] mwhudson: it'll only happen once per slave per repo [20:17] after that it should be seconds [20:17] jelmer: but it's not really about time, it's about disk space [20:18] right now anyway [20:18] if we preserve them somewhere else, we can only have the ones on the slave that are running at a given time [20:18] if it's about disk space we can look at whether we actually need the cache [20:19] mwhudson, there's definitely something wrong on launchpad [20:19] "determing revisions to fetch" for the branch you just linked to took less than a minute here [20:19] !! [20:20] ooi, why isn't "determining revisions to fetch" the equivalent of a single "svn log" operation? [20:20] jelmer: is this a clue? [20:20] 2010-02-16 21:43:44 WARNING Upgrade to svn 1.5 or higher for faster retrieving of revision properties. [20:20] maxb: if you're not using the cache, it is [20:20] Shouldn't 'svn log' be fast enough to make a cache pointless? [20:20] maxb: there's more you can do on a svn repo than svn log [20:20] maxb: more than bzr pull I mean [20:21] jelmer: the slaves seem to be on subversion 1.4.6dfsg1-2ubuntu1.1 [20:21] mwhudson: Hmm, I don't get that here [20:22] mwhudson: Ah, it might be useful to upgrade the version of subversion on the slaves [20:22] mwhudson: but it also looks like we're hitting a very slow code path when we're using svn 1.4, so we should probably fix that anyway [20:24] jelmer: last time i talked about upgrading svn apart from as part of a distro upgrade i was told it was impossible [20:24] mwhudson: I'll see if I can reproduce the issue in a dapper vm [20:25] jelmer: hardy should be fine... [20:25] mwhudson: interesting, was a reason given? [20:25] maxb: cscvs uses both python-subversion and pysvn [20:26] That sounds merely slightly complex, not impossible [20:26] and at least one of those is really hard to build [20:26] well [20:26] maybe we didn't ask you :-) [20:26] anyway, it might be better now [20:26] I've built pysvn on Slackware 10.0, I'm sure I can build it on hardy [20:27] :-) [20:27] backporting from say feisty to dapper might have been more awkward than karmic -> hardy [20:28] sinzui: several days in a row now, my machine has gradually slowed down to a crawl, becoming more and more unusable; running lp tests seems to be the cause, though I'm not 100% sure yet. 'top' indicates that python2.5 consumes most of the CPU. Have you experienced anything similar? [20:30] kfogel: the testrunner does take most of one cpu, but all is better when the test completes [20:30] sinzui: the "all is better" part doesn't always seem to happen for me [20:31] kfogel: I never run into swap, so I think memory may be important. I have 2 gigs @ 32 bit usually allocated to development [20:34] sinzui: well, up to several seconds just to switch virtual desktops, maybe 1/2 second keystroke delay now. I'm rebooting. back in a bit === EdwinGrubbs is now known as Edwin-lunch === matsubara is now known as matsubara-afk [21:11] deryck: in a searchTasks() query, is there a recommended way to get the search to include all statuses? If you do status=None, it reverts to default statuses, which don't include (e.g.) BugTaskStatus.FIXRELEASED. [21:11] deryck: should I just do status=any(*UNRESOLVED_BUGTASK_STATUSES, *RESOLVED_BUGTASK_STATUS) or something? [21:12] Is anyone with postgress guruness awake? [21:12] deryck: (well, that syntax may be wrong but you get the idea) [21:12] sinzui: sorry, no guruness, but if you ask I'll look and see if I know the answer off the top of my head. [21:13] kfogel, yes, the idea is right, but not the syntax. Pass in a single combined list. [21:13] deryck: will do [21:14] I'm out. Later all. [21:16] kfogel: we have bad data in production that I though we fixed in November. patch-2207-09-0.sql drops packaging_uniqueness and adds packaging__distroseries__sourcepackagename__key which is a more restrictive UNIQUE rule. But I do not see this patch applied when I look at the db [21:16] * sinzui thinks he needs to email stub and jtv to understand the screwup [21:16] sinzui: I think so -- this is probably more about lp db patching process than about postgresql per se [21:17] I also need to find the query that identified the insane data too [21:36] sinzui: do you need to "drop index" not "drop constraint" ? [21:36]