[12:03] bah, spewer only logs what happens in the main thread... [12:03] ddaa: see my email... [12:03] all the interesting stuff in buildbot happens in the extra threads. [12:04] spiv: yes, that's your mail I'm referring to. [12:06] Maybe the syncqueue should not be blocking though... [12:07] Unfortunately, it doesn't log non-main threads. You can hack this in [12:07] yourself by putting these lines at the top of [12:07] twisted.python.threadpool.ThreadPool._worker: [12:07] ... [12:07] From my email :) [12:07] Ha sorry... really need to go bed... [12:07] :) [12:07] Do that :) [12:07] It'll save time in the long run, I suspect :) [12:08] lol... yeah... makes sense... I'll file a bug about that ;-) === spiv boggles at the latest daily wtf. [12:09] New bug 2137 for Launchpad/Rosetta: Add sample data for Recently Translated Projects [12:09] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2137 === ddaa recalls he completely forgot the .close method that is needed for the blocking queue to make sense === ddaa larts ddaa === ddaa will discuss the issues involved tomorrow [12:13] Good night :) [12:15] lifeless: just try making the queue puts unblocking in arch._twisted.ProcessProtocol [12:20] hu... does not make sense... the queue size is unlimited anyway [12:20] please disregard. === ddaa implements the ShutUpAndSleep strategy === ddaa [~ddaa@nemesis.xlii.org] has left #launchpad [] [12:39] spiv: howdy [12:39] any progress on the bug that's holding back the arch team? [01:08] spiv committed is last night [01:09] so in theory we are not held back, I plan to verify that today, amongst other juggles. [01:09] lifeless: what was the bug? [01:10] the details I'm not sure - but there were bits in launchpad, sqlos & buildbot that all fitted together. === kiko_ [~kiko@200-206-134-238.async.com.br] has joined #launchpad [01:41] how do i regenerate the allowed-tags file? [01:43] "does -> lib/sqlobject" mean the modification time was changed? and where to i find what all those change symbols mean? [01:44] s/"does /does "/ [01:46] BradB: can you copy the line literally ? [01:46] i did [01:47] I'm a little confused on what it was :| [01:47] the quoted part above: "-> lib/sqlobject" [01:48] window goto #ubuntu [01:52] hey lunch people [01:53] justdave, ping? [01:53] BradB: there isn't a '-> changeset detail [01:54] lifeless: heh heh [01:54] BradB: there is 'M->' and 'C->'... [01:54] who's our database admin apart from dave? [01:54] Merge to rocketfuel@canonical.com/launchpad--devel--0: add docs for new add/edit form buffing (patch-688) [01:55] lifeless: http://paste.husk.org/1865 [01:56] ah, changes, not apply-changeset. [01:57] thats a modified symlink [01:57] yeah, so in other words it means the modification time was changed, right? [01:58] it's pointing to the same dir [01:58] no, the target [01:58] tla changes --diffs should show you change [02:01] Bug 2095 resolved: Use Sourcepackage() instead of SoyuzSourcepackage() [02:01] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2095 [02:01] dilys: you rock! [02:02] need to teach the bitch to show some gratitude for the praise [02:05] New bug 2139 for Launchpad/Rosetta: Rosetta link (portlet?) for Soyuz Source Package index [02:05] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2139 [02:10] BradB: i'm getting a bad response from https://mawson... [02:10] should it be up? [02:10] i' keen to walk mdz through malone [02:12] New bug 2140 for Launchpad/Soyuz: Implement build log summary page [02:12] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2140 [02:12] sabdfl: https://launchpad.ubuntu.com/ [02:14] rock [02:14] bradb thanks! [02:15] no prob :) [02:15] cprov, elmo, can we get an archive on mawson for gina loving into that db? [02:15] BradB: is that launchpad-dev on that pgsql? [02:15] cprov, elmo, this db will also need to be backed up daily, it's our dogfood db [02:15] or is it laucnhpad-dogfood? [02:16] either way, need a run of gine and nicole against that db, and against hoary as it opens up [02:16] launchpad_test [02:16] because the app isn't setup to properly change DB names [02:17] (i.e. to have just one place to do so) [02:17] BradB: erk, guess we need that ability asap [02:17] yep, i've filed the bug already [02:17] otherwise a single make check would blow away our dogfood db [02:18] yeah, unfortunately [02:18] hmm... and need to get stub into the mode of daily backup+code+schema updates to launchpad-dogfood too [02:18] because it doesn't have my shiny updates [02:21] indeed [02:21] speaking of your shiny updates (slick...slick), where did the edit pba/spba UI go? [02:24] sabdfl, can I get an opinion on something? [02:24] kiko_ go ahead [02:24] bradb doh did i break something? [02:24] well [02:25] is there a test? [02:25] ah, i think it's still there, we just broke the linking in installing all the eye candy [02:25] sabdfl, for a source package page, what's a good way to display or link to build logs? [02:26] sabdfl: i think you intentionally removed it.. [02:26] sabdfl, currently we are planning on a separate page (see bug 2140 reported above) [02:26] sabdfl, but we could just stuff the links inline on that page and live with it [02:26] kiko: maybe have a tab on the sourcepackagerelease page, listing builds of it [02:26] sabdfl: i guess you wanted to aggregate package/product assignments into one list? [02:26] sabdfl, on the source package release, sure, but in the source *package*? [02:26] BradB: sort of [02:27] that's more or less a "package maintainer console" [02:27] so it would be nice to have one-click access to logs [02:27] for "context-important" ones we'll put them in the headline [02:27] so, say you are in the gentoo distro [02:27] then bug assignments to a gentoo package should be at the top of the bug [02:27] all the others in a portlet [02:28] i'd like to decorate the request object with a LaunchpadContext thingamabob which would assist in those determinations [02:29] heh, yeah, that'd be useful [02:29] kiko_: seems like it could be a portlet, showing links to the latest builds on all architectures [02:29] night all, i'm packing it in [02:30] see ya tomorrow [02:32] sabdfl, yeah, except it can be a damned long page. [02:42] sabdfl: I can't create DB on mawson, I already asked elmo but postgres present an strange behavior [03:01] elmo! [03:01] New bug 2141 for Launchpad/Soyuz: Implement Source Package Tracking System [03:01] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2141 [03:07] Merge to rocketfuel@canonical.com/buildbot--devel--0: improve tla tagging methods for Xorg and kde (patch-64) [03:14] cprov: eh, that should be fixed now [03:15] elmo, was it just a pgsql-superuser-issue? [03:15] no [03:15] AFAICT, it's a postgres doesn't like HT when using NPTL/2.6/something issue [03:16] the launchpad user has superuser, it's nothing to do with that [03:24] interesting. === BradB catches up a bit on plone-developers, learns about more gaping security holes in zope/plone [03:37] BradB, yeah, the GET thingy :) [03:37] there's been a rage about this here today [03:39] the other one, of course, being the thing that stub fixed for us [03:40] as someone who spends most of his time doing zope/plone consulting work, the propsect of "oh, by the way, almost every zope/plone site out there has at least two well-known and trivial to exploit hacks which could easily turn your site into rubble." is pretty shite [03:44] how do I choose the database now ? [03:44] (I just updated my local code, so I can check for a new production update) [03:49] kiko_: sometimes i really think TdR's got it all figured out [03:50] except that obsd doesn't run on ppc last i checked [03:51] BradB, well, I don't think obsd could have prevented plone from being hacked. Plone would never be included in obsd by default, right? :) [03:51] exactly :) [03:52] oh my, obsd does run on ppc === BradB looks into when that was added === kiko_ wonders if bradb means he wants to go unemployed :) === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad [03:54] stud: ping [03:55] lifeless: pong [03:55] kiko_: yeah, no kidding eh :) [03:55] 2 questions [03:55] 1) how do a simulate a production database update - do we have that schema magic yet - on my local db. [03:55] 2) how to I tall launchpad to use launchpad_test ? [03:57] 1) The update procedure is manual and documented in database/schema/README.txt. There is no automated method, as so far I've been more comfortable with the manual process. The dogfood servers will change this since I believe database schema updates are going to be rolled out a few times a week on all the dogfood databases. [03:58] I'm hopinh to do a new production update this week. that cool with you ? [04:00] 2) The two places the database-to-use is configured is hardcoded in lib/canonical/lp/__init__.py and package-includes/launchpad-sql-configure-normal.zcml [04:01] Hmm.... lib/canonical/lp/__init__.py should be pointing to launchpad_dev.... need to fix that and update the test harness to cope... [04:01] is that zcml under rev ctl ? i.e. will I break users if I change my one to use _test ? [04:01] lifeless: Sure. Give me the day and time when you have it narrowed down [04:01] stud: thinking friday [04:02] lifeless: Yes - it will break others. You can try copying the file to override-incudes/+my-database-confugure-normal.zcml and altering it there. [04:02] That is supposed to work [04:03] (the master .zcml will pick it up if it ends with -configure.zcml or -configure-normal.zcml. Use -configure-normal.zcml in this case so the test harness doesn't use it for functional tests) [04:03] There is a bugzilla bug open discussing simple configuration of this stuff btw. It needs to be easier to configure. [04:05] lifeless: Will the database changes include ddaa's fixes to the dirty data that got into the production database? [04:06] stud: that is a script that I'll run separately. [04:06] Its not precisely dirty data, but rather duplicate data. [04:28] New bug 2143 for Launchpad/Soyuz: Add link to bugs for a certain source package release [04:28] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2143 [04:28] maybe I should file some more bugs for kicks [04:29] yeah! [04:29] any idea on this: [04:29] hmm, actually, I'll dig a little more first [04:29] kiko_: I noticed that some of the portlets I dropped on the floor appear to have been picked up and implemented by somebody? [04:30] stud, that's debonzi hacking around you ;) [04:31] kiko_: Do you know if I'm still needed for it then, or can I just leave it to Team Brazil? [04:34] well, hum hum [04:34] stud, leave it open as low-priority, I guess. we still need your guidance and you can steal our code for the portlet later if you like [04:34] I've got some other requests [04:35] stud, can I discover bugs that only apply to a certain binary package? and binary package release? [04:38] SourcepackageBugAssignment *may* be linked to a BinarypackageName. I can't remember why it was changed from pointing to Binarypackage (hmm... or maybe I never understood...). Does that help you think? [04:39] hmmm [04:39] how does that relate to BugInfestation? :) [04:39] err BugPackageInfestation [04:40] BradB, you can come guess too! [04:43] stud: override-includes doesn't support -normal.zcml [04:43] only configure.zcml [04:45] lifeless: Bah. Fix that if you want - it just needs the love in site.zcml. [04:46] heh, bottom of the todo list [04:46] kiko_: I need to sort out my diagramming tools - pita chasing these linkages through in psql :-P [04:46] love the infestation name [04:46] ooh ohh ohh, lunchtime [04:47] stud, it scares me. I understand zilch of the malone-related tables [04:48] BugInfestation -> CodeRelease -> SourcepackageRelease (or ProductRelease if you rather) [04:49] what about BugPackageInfestation? [04:51] Hmm... I suspect BugInfestation is a decoy, it having been split into BugPackageInfestation and BugProductInfestation === stud goes and checks his email archive [04:52] a red herring? why is it still there? [04:53] hmmm [04:54] Yes - buginfestation was supposed to have been dropped. I must have left it out of the patch. [04:56] So you have bugpackageinfestation and sourcepackagebugassignment [04:56] (love that consistent naming!) [04:58] it's not meant to be confusing, it just turned out that way [04:58] oh crap, forgotten the test user. [04:58] foo.bar@canonical.com ? pw testing ? [04:59] I can never remember myself === stud hasn't actually used it [05:09] sabdfl: likes the bug prefix [05:09] lifeless: p/w test [05:10] the buginfestation table might have been my fault. ISTR adding a table that was just for statuses, not yet knowing about the dbobjects vocabs. [05:11] last i spoke to sabdfl about it (in london) we were dropping the idea of a code release too, but that might not be doable [05:11] BradB: I got a patch from you on the buginfestation stuff, and the first line was 'drop table buginfestation'. [05:11] woo, yay me! [05:11] :P [05:12] I think I missed it when I put it into a database schema patch === BradB is now known as BradB|out [05:22] agh [05:35] sl1p! === kiko [~kiko@200-206-134-238.async.com.br] has left #launchpad [] === BradB|out is now known as BradB|zzz [06:23] hmmm [06:23] where is NotFoundError: (, u'linkTransparent.gif') [06:23] ? [07:08] Looks like someone used a relative URL that doesn't exist - it would be on the page you are trying to view? === lifeless doesn't know [07:11] its triggered by the sourcesource-index [07:12] Is there an

there? If not, it would be in one of the files included from there (such as the standard templates... whoops...) [07:12] not in the template itself [07:14] Looks like the evil is in plone.css [07:14] do I need to file a bug report ? === lifeless hopes not === stud does a more thorough grep [07:18] Hmm... yeah. If it is plone.css, then it is a deeper problem because it looks it is referencing ++resource++linkTransparent.gif [07:21] Merge to rocketfuel@canonical.com/launchpad--devel--0: added more edit notifications and fixed so that bugs can be added again (patch-689) === jblack smacks himself upside the head. [07:52] lifeless: I just figured out why adding revisions to the library is so slow. [07:52] for launchpad related things. [07:54] oh? [07:55] part of it. [07:57] One part is searching for an ancestor revision takes about 1 second per revision to search the library. [07:57] omg, no way! [07:58] hush. I'm getting to a point. [08:00] It also looks like that while your'e searching for an ancestor revision in the library, there's calls being made via sftp [08:01] why would I be making sftp calls while searching for an ancestor revision ? [08:02] Merge to rocketfuel@canonical.com/launchpad--devel--0: update importd (sourcesource) ui to be fully functional again (patch-690) [08:04] oh. I bet I know what its doing. [08:09] jblack: checking for missing revisions ? [08:10] Yup. [08:10] but I definitely found a problem with patchlogs. [08:10] stating 2000 patchlogs doesn't sound like much. [08:10] but you have to do it for every revision. [08:11] For if you have to build 100 revisions, that's 200,000 lstat64s right there. [08:11] gotta have it in scale though [08:11] there's also 100* stats of the sources. [08:12] anyway, abently has addressed this in the backbuilder. [08:12] it doesn't re-inventory as it goes. [08:17] I don't understand why we're not just statting the appropriate dir in the revision library, and seeing what the latest stored revision is. [08:17] and then just start building from there. [08:18] never mind. [08:19] we only stat the latest revision :) [08:19] not true. [08:20] We're doing the equivilant of stat of pfs, because we're downloading every single checksum file in between what we've got and current in order to find cached revisions. [08:27] again, the backbuilder has improvements for this. [08:27] I mean - its good to know that its a fairly stock tuning problem for tla. [08:27] and I think this should be one of the early targets for canonical arch. [08:31] I've thrown together a strawman interface spec for a better-imho-cli for tla/tla-ng. You want it on a wiki or emailed somewhere? [08:31] Lets try email first. [08:31] launchpad@ or private? [08:32] I'm not on launchpad, actually, so I guess private [08:38] Ok. here we go. In order to add stuart.bishop@canonical.com/launchpad--devel--0--patch-332 to my library, it took 2,392,551 lstat64s of which 1,661,899 were for patch logs. [08:38] :) [08:38] Cool - I never knew I was that productive! [08:41] lifeless: By removing all but the first 25 patchlogs from each version, I cut star-merge from just over one minute to ten seconds. [08:42] oh. never mind. empty delta [08:44] stud: wiki - link from CanonicalArch page please [08:45] stud: Did you see the new tla help in 1.2.3rc1 ? [08:46] Nope - I'm just using the warty default atm [08:46] The help is broken down into functional categories. [08:46] each section is very short, and includes subjects such as "using arch for the first time" [08:47] jblack: thats fine, it simply demonstrates the quantitive amelioration thing [08:47] I heard about that - seems like an improvement. My attempt is to just remove most of the tla commands that are unnecessary for my personal use cases :-) [08:47] I'd much rather address it qualitatively. [08:47] which abentlies work goes a long way to doing [08:48] I don't see how the backbuilder helps that much. Many (most?) of the archives I've seen don't have cached revisions at all. [08:49] the backbuilder has a bunch of other changes supporting it [08:50] any reason they can't be broken up? [08:51] none at all [08:52] do you see my point though? trimming our logs is -at most- a breathing room thing, not a solution [08:52] which is why I'm not interested in pursueing it. [08:53] ok [08:53] because, it forcing people to think about the mechanics. [08:53] and that is the whole thing we want to avoid *except when its useful* [08:57] Ok then. MOving on to other jobs. [08:58] Jivera plans to take up to a week to merge about 5% of the 1.2.2rc3 and 1.2.3rc1 patches. [08:58] He's only taking the most vital ones at this time. [09:01] so what do you want to do with thelove? [09:06] what we planned yesterday [09:06] I'll be tagging shortly [09:06] and then we'll put in anything we think is an improvement [09:18] start with the profile enabling patch please. just in a public branch, tagged from gnu-arch--2004 [09:18] Ok boss. [09:20] stud: you can do better than asasad :) [09:20] My personal protest against mandatory comments ;) [09:21] perhaps it refers to an unhappy mozilla qa person === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad [10:03] stud: so, have you heard of sealed branches ? [10:03] vaguely [10:04] they are hidden by default in rbrowse. [10:04] the branch thing you mention, is directly a corollary of storing changesets rather than tree-snapshots. [10:04] that, and the code organisation namespace being disjoint from the code storage namespace [10:05] we can layer ui glue there trivially, but I'd like you to propose some use cases in that Gripe, so that we make useful decisions for you [10:05] Yup. So sealing is a partial solution. [10:06] The use case depends on being able to look at a snapshot-in-time of the whole archive, which I suspect is not possible? [10:06] stud: its pretty meaningless, to be honest. [10:07] we can certainly calculate what was present in july 4 2003, and only show those branches & changesets. [10:07] but snapshot-in-time isn't the english-use case. [10:08] by use case I mean something like 'I want tla to show me the branches of my project that existed at Jul 4 2004. [10:09] and 'I need a means to tell tla that a branch should be considered deleted - that is, that query tools won't show it by default, and that queries for 'now' for the branches will not show it' [10:09] Yes - I'm thinking about the Zope development methadology, where every small change is done in a branch, tests run, and merged into the trunk. I'm wondering if sealing is a good enough solution to that (although it might have trouble if the same branch name is used in the future, eg. 'unicode-fix' branch might be created and sealed several times in a project lifetime) [10:10] stud: honestly, I think we use more branches than zope would... and we do many branches. And so far, at least for me, its not been an issue at all. [10:10] don't think about implementation. Just think about the use case. === limi [~count@212.80-202-72.nextgentel.com] has joined #launchpad [10:11] morning, y'all === stud is now known as stub [10:14] yo === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad [10:17] Morning [10:18] lifeless: ok. I think the concept of 'sealing' the version actually suits the use case better (branching from trunk to do a small fix, then merging the changes from that branch back into the trunk and several 'release' branches') [10:26] morning all [10:34] stub: around? [10:34] yu [10:34] p [10:35] kiko: infestations are what track a bug relative to a specific release [10:36] lifeless: did you solve this:05:23:40) lifeless: where is NotFoundError: (, u'linkTransparent.gif') === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:36] looks like you need a resource for the image file [10:38] sabdfl: not solved, I've no idea whats causing it - my template doesn't have a linkTransparent.gif reference. [10:41] lifeless: probably in the CSS === limi will have a look [10:42] this is in Launchpad, right? [10:42] yep === limi grabs his mail and CSS and heads for the train [10:43] back in a bit :) [10:44] lifeless: it's easy to fix [10:45] lifeless: put the following in your zcml file: [10:45] name="linkTransparent.gif" file="../launchpad/images/linkTransparent.gif" /> [10:46] which zcml file (I haven't created any) [10:46] of course make the path correct relative to that zcml file [10:46] stevea around for a catch up? [10:52] --- orig/lib/canonical/launchpad/zcml/bugwatch.zcml [10:52] +++ mod/lib/canonical/launchpad/zcml/bugwatch.zcml [10:52] @@ -22,6 +22,7 @@ [10:52] name="+edit" [10:52] schema="canonical.launchpad.interfaces.IBugWatch" [10:52] + class="canonical.launchpad.browser.editview.SQLObjectEditView" [10:52] label="Change Bug Watch" [10:52] permission="launchpad.AnyPerson" [10:52] template="../templates/default-editform.pt" [10:52] stub: that yours? [10:52] lifeless: you can actually use any zcml file [10:53] they all seem to get parsed at startup and any file affects the global namespace [10:53] sabdfl: a bit later today would suit me better -- getting the wiki site conversions finished now [10:54] SteveA: ok, ping me when ready [10:54] k [10:54] stub: around? [10:55] pong [10:56] Nope - that was Brads I think. [10:57] Looks like he wants to add some behaviour to the view so the template or widgets can do funkier stuff. [10:57] lifeless: is this yours: [10:57] -class xSoyuzProduct(object): [10:57] +class SoyuzProduct(object): [10:57] ? [10:57] or ddaa? [10:57] sabdfl: me. [10:57] it broke stuff. [10:58] I'm in the process of migrating the code it broke to not need it. [10:58] rather than resurrecting old code, which we are trying to get rid of, can you please integrate with the new code [11:02] sabdfl: are there any wiki pages on the new ZWiki site that you want to keep the contents of? [11:03] SteveA: yes, most of it [11:05] SteveA: in fact, all of it to be safe [11:05] ok. I'm going to copy it elsewhere, and then copy it back after the old site has been moved over. [11:05] UbuntuReleases HoaryHedgehog HoaryGoals HoaryKickoffMeeting HoaryMergeProcess HoaryReleaseSchedule [11:06] these have had quite a lot of work done too [11:07] ok, I'll make sure those are preserved [11:07] SteveA: http://www.ubuntulinux.org/wiki/WikiWishlist [11:07] could you point the zwiki guy at that? [11:09] sure. The bullet points in moin format work for me [11:10] as in moin, you have to ensure you write " * item" not "* item" [11:12] right [11:12] i'm not comfortable making ReST the default recommended format [11:12] it's way too picky about stuff that seems trivial [11:13] i end up spending ages trying to get rid of all the warnings on the page [11:13] SteveA: how do we regenerate the allowed-tags file? === stub has just been deleting lines out of it as appropriate [11:15] you run the script python checkarchtag.py [11:15] python checkarchtag.py check checks the tags [11:15] python checkarchtag.py create creates the allowed-tags.txt file [11:16] running it with "check" tells you what files with implicit tags have been added, moved, or deleted [11:17] sabdfl: so, the problem with ReST is not the format, but the implementation of the parser. [11:26] SteveA: is there a better implementation we can point the zwiki guy at? [11:26] not that I know of. [11:26] whoa! just merged rocketfuel and have a gazillion test failures [11:26] yeah; I've got that [11:26] there may be a better way to use the current implementation, though [11:26] which sucks a bit [11:26] so ReST is "a great format with no good implementations" [11:27] sabdfl: although a second run-through the tests seems to pass [11:27] there may be a "be tolerant, we're only human" switch for the current implementation [11:27] I'll ask sm when he's online [11:28] SteveA: saying the problem is not in the format but in the implementation, when there are no good implementations, sounds highly suspect to me [11:28] who came up with ReST and what makes you think its a good format if there are no good implmentations? [11:28] that sounds like saying that "Arch is good it's just tla that sucks" [11:29] until someone actually does a good implementation we don't know that, we can only speculate [11:29] there is a detailed specification for the ReST format. the implementation of it is good, but intolerant of people who edit it without sticking to the spec. [11:29] note that the errors you see are "warnings" [11:30] I think it is possible to suppress the warnings, or have them in a status message [11:30] the warnings are to tell you, the author, that your intentions were conveyed ambiguously to the software [11:31] so, probably what needs to improve is the integration of the ReST parser into ZWiki === limi [~limi@sparkit.easynet.no] has joined #launchpad [11:45] hi limi [11:50] Anyone making page tests atm? [11:53] stub: regarding the dogfood server [11:53] we need that to be a daily drop of schema+code [11:54] well, backup + schema + code [11:54] maybe arrange with elmo for backup of that db every six hours? [11:54] Oohh... saying backup just gave me an idea on how that process can be much easier.. [11:56] sabdfl: I'm just using pg_dump from cron on emperor (and hoping that the disk is being backed up regularly...) [11:57] I'll need to write that script that stores the database schema revision and only runs new patches. [11:58] Could a brazillian translate this please: [11:58] if not build: [11:58] # LA VARZEA [11:58] return [11:58]