[12:03] <ddaa> bah, spewer only logs what happens in the main thread...
[12:03] <spiv> ddaa: see my email...
[12:03] <ddaa> all the interesting stuff in buildbot happens in the extra threads.
[12:04] <ddaa> spiv: yes, that's your mail I'm referring to.
[12:06] <ddaa> Maybe the syncqueue should not be blocking though...
[12:07] <spiv> Unfortunately, it doesn't log non-main threads.  You can hack this in
[12:07] <spiv> yourself by putting these lines at the top of
[12:07] <spiv> twisted.python.threadpool.ThreadPool._worker:
[12:07] <spiv> ...
[12:07] <spiv> From my email :)
[12:07] <ddaa> Ha sorry... really need to go bed...
[12:07] <spiv> :)
[12:07] <spiv> Do that :)
[12:07] <spiv> It'll save time in the long run, I suspect :)
[12:08] <ddaa> lol... yeah... makes sense... I'll file a bug about that ;-)
[12:09] <dilys> New bug 2137 for Launchpad/Rosetta: Add sample data for Recently Translated Projects
[12:09] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2137
[12:13] <spiv> Good night :)
[12:15] <ddaa> lifeless: just try making the queue puts unblocking in arch._twisted.ProcessProtocol
[12:20] <ddaa> hu... does not make sense... the queue size is unlimited anyway
[12:20] <ddaa> please disregard.
[12:39] <sabdfl> spiv: howdy
[12:39] <sabdfl> any progress on the bug that's holding back the arch team?
[01:08] <lifeless> spiv committed is last night
[01:09] <lifeless> so in theory we are not held back, I plan to verify that today, amongst other juggles.
[01:09] <sabdfl> lifeless: what was the bug?
[01:10] <lifeless> the details I'm not sure - but there were bits in launchpad, sqlos & buildbot that all fitted together.
[01:41] <sabdfl> how do i regenerate the allowed-tags file?
[01:43] <BradB> "does -> lib/sqlobject" mean the modification time was changed? and where to i find what all those change symbols mean?
[01:44] <BradB> s/"does /does "/
[01:46] <lifeless> BradB: can you copy the line literally ?
[01:46] <BradB> i did
[01:47] <lifeless> I'm a little confused on what it was :|
[01:47] <BradB> the quoted part above: "-> lib/sqlobject"
[01:48] <lifeless> window goto #ubuntu
[01:52] <kiko_> hey lunch people
[01:53] <kiko_> justdave, ping?
[01:53] <lifeless> BradB: there isn't a '-> changeset detail
[01:54] <BradB> lifeless: heh heh
[01:54] <lifeless> BradB: there is 'M->' and 'C->'...
[01:54] <kiko_> who's our database admin apart from dave?
[01:54] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: add docs for new add/edit form buffing (patch-688)
[01:55] <BradB> lifeless: http://paste.husk.org/1865
[01:56] <lifeless> ah, changes, not apply-changeset.
[01:57] <lifeless> thats a modified symlink
[01:57] <BradB> yeah, so in other words it means the modification time was changed, right?
[01:58] <BradB> it's pointing to the same dir
[01:58] <lifeless> no, the target
[01:58] <lifeless> tla changes --diffs should show you change
[02:01] <dilys> Bug 2095 resolved: Use Sourcepackage() instead of SoyuzSourcepackage()
[02:01] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2095
[02:01] <sabdfl> dilys: you rock!
[02:02] <sabdfl> need to teach the bitch to show some gratitude for the praise
[02:05] <dilys> New bug 2139 for Launchpad/Rosetta: Rosetta link (portlet?) for Soyuz Source Package index
[02:05] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2139
[02:10] <sabdfl> BradB: i'm getting a bad response from https://mawson...
[02:10] <sabdfl> should it be up?
[02:10] <sabdfl> i' keen to walk mdz through malone
[02:12] <dilys> New bug 2140 for Launchpad/Soyuz: Implement build log summary page
[02:12] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2140
[02:12] <BradB> sabdfl: https://launchpad.ubuntu.com/
[02:14] <sabdfl> rock
[02:14] <sabdfl> bradb thanks!
[02:15] <BradB> no prob :)
[02:15] <sabdfl> cprov, elmo, can we get an archive on mawson for gina loving into that db?
[02:15] <sabdfl> BradB: is that launchpad-dev on that pgsql?
[02:15] <sabdfl> cprov, elmo, this db will also need to be backed up daily, it's our dogfood db
[02:15] <sabdfl> or is it laucnhpad-dogfood?
[02:16] <sabdfl> either way, need a run of gine and nicole against that db, and against hoary as it opens up
[02:16] <BradB> launchpad_test
[02:16] <BradB> because the app isn't setup to properly change DB names
[02:17] <BradB> (i.e. to have just one place to do so)
[02:17] <sabdfl> BradB: erk, guess we need that ability asap
[02:17] <BradB> yep, i've filed the bug already
[02:17] <sabdfl> otherwise a single make check  would blow away our dogfood db
[02:18] <BradB> yeah, unfortunately
[02:18] <sabdfl> hmm... and need to get stub into the mode of daily backup+code+schema updates to launchpad-dogfood too
[02:18] <sabdfl> because it doesn't have my shiny updates
[02:21] <BradB> indeed
[02:21] <BradB> speaking of your shiny updates (slick...slick), where did the edit pba/spba UI go?
[02:24] <kiko_> sabdfl, can I get an opinion on something?
[02:24] <sabdfl> kiko_ go ahead
[02:24] <sabdfl> bradb doh did i break something?
[02:24] <kiko_> well
[02:25] <sabdfl> is there a test?
[02:25] <sabdfl> ah, i think it's still there, we just broke the linking in installing all the eye candy
[02:25] <kiko_> sabdfl, for a source package page, what's a good way to display or link to build logs? 
[02:26] <BradB> sabdfl: i think you intentionally removed it..
[02:26] <kiko_> sabdfl, currently we are planning on a separate page (see bug 2140 reported above) 
[02:26] <kiko_> sabdfl, but we could just stuff the links inline on that page and live with it
[02:26] <sabdfl> kiko: maybe have a tab on the sourcepackagerelease page, listing builds of it
[02:26] <BradB> sabdfl: i guess you wanted to aggregate package/product assignments into one list?
[02:26] <kiko_> sabdfl, on the source package release, sure, but in the source *package*?
[02:26] <sabdfl> BradB: sort of
[02:27] <kiko_> that's more or less a "package maintainer console"
[02:27] <kiko_> so it would be nice to have one-click access to logs
[02:27] <sabdfl> for "context-important" ones we'll put them in the headline
[02:27] <sabdfl> so, say you are in the gentoo distro
[02:27] <sabdfl> then bug assignments to a gentoo package should be at the top of the bug
[02:27] <sabdfl> all the others in a portlet
[02:28] <sabdfl> i'd like to decorate the request object with a LaunchpadContext thingamabob which would assist in those determinations
[02:29] <BradB> heh, yeah, that'd be useful
[02:29] <sabdfl> kiko_: seems like it could be a portlet, showing links to the latest builds on all architectures
[02:29] <sabdfl> night all, i'm packing it in
[02:30] <BradB> see ya tomorrow
[02:32] <kiko_> sabdfl, yeah, except it can be a damned long page.
[02:42] <cprov> sabdfl: I can't create DB on mawson, I already asked elmo but postgres present an strange behavior
[03:01] <kiko_> elmo!
[03:01] <dilys> New bug 2141 for Launchpad/Soyuz: Implement Source Package Tracking System
[03:01] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2141
[03:07] <dilys> Merge to rocketfuel@canonical.com/buildbot--devel--0: improve tla tagging methods for Xorg and kde (patch-64)
[03:14] <elmo> cprov: eh, that should be fixed now
[03:15] <kiko_> elmo, was it just a pgsql-superuser-issue?
[03:15] <elmo> no
[03:15] <elmo> AFAICT, it's a postgres doesn't like HT when using NPTL/2.6/something issue
[03:16] <elmo> the launchpad user has superuser, it's nothing to do with that
[03:24] <kiko_> interesting.
[03:37] <kiko_> BradB, yeah, the GET thingy :)
[03:37] <kiko_> there's been a rage about this here today
[03:39] <BradB> the other one, of course, being the thing that stub fixed for us
[03:40] <BradB> 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] <lifeless> how do I choose the database now ?
[03:44] <lifeless> (I just updated my local code, so I can check for a new production update)
[03:49] <BradB> kiko_: sometimes i really think TdR's got it all figured out
[03:50] <BradB> except that obsd doesn't run on ppc last i checked
[03:51] <kiko_> 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] <BradB> exactly :)
[03:52] <BradB> oh my, obsd does run on ppc
[03:54] <lifeless> stud: ping
[03:55] <stud> lifeless: pong
[03:55] <BradB> kiko_: yeah, no kidding eh :)
[03:55] <lifeless> 2 questions
[03:55] <lifeless> 1) how do a simulate a production database update - do we have that schema magic yet - on my local db.
[03:55] <lifeless> 2) how to I tall launchpad to use launchpad_test ?
[03:57] <stud> 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] <lifeless> I'm hopinh to do a new production update this week. that cool with you ?
[04:00] <stud> 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] <stud> 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] <lifeless> is that zcml under rev ctl ? i.e. will I break users if I change my one to use _test ?
[04:01] <stud> lifeless: Sure. Give me the day and time when you have it narrowed down
[04:01] <lifeless> stud: thinking friday
[04:02] <stud> 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] <stud> That is supposed to work
[04:03] <stud> (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] <stud> There is a bugzilla bug open discussing simple configuration of this stuff btw. It needs to be easier to configure.
[04:05] <stud> lifeless: Will the database changes include ddaa's fixes to the dirty data that got into the production database?
[04:06] <lifeless> stud: that is a script that I'll run separately.
[04:06] <lifeless> Its not precisely dirty data, but rather duplicate data.
[04:28] <dilys> New bug 2143 for Launchpad/Soyuz: Add link to bugs for a certain source package release
[04:28] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2143
[04:28] <kiko_> maybe I should file some more bugs for kicks
[04:29] <lifeless> yeah!
[04:29] <lifeless> any idea on this:
[04:29] <lifeless> hmm, actually, I'll dig a little more first
[04:29] <stud> 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] <kiko_> stud, that's debonzi hacking around you ;)
[04:31] <stud> kiko_: Do you know if I'm still needed for it then, or can I just leave it to Team Brazil?
[04:34] <kiko_> well, hum hum
[04:34] <kiko_> 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] <kiko_> I've got some other requests
[04:35] <kiko_> stud, can I discover bugs that only apply to a certain binary package? and binary package release?
[04:38] <stud> 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] <kiko_> hmmm
[04:39] <kiko_> how does that relate to BugInfestation? :)
[04:39] <kiko_> err BugPackageInfestation
[04:40] <kiko_> BradB, you can come guess too!
[04:43] <lifeless> stud: override-includes doesn't support -normal.zcml
[04:43] <lifeless> only configure.zcml
[04:45] <stud> lifeless: Bah. Fix that if you want - it just needs the love in site.zcml.
[04:46] <lifeless> heh, bottom of the todo list
[04:46] <stud> kiko_: I need to sort out my diagramming tools - pita chasing these linkages through in psql :-P
[04:46] <lifeless> love the infestation name
[04:46] <lifeless> ooh ohh ohh, lunchtime
[04:47] <kiko_> stud, it scares me. I understand zilch of the malone-related tables
[04:48] <stud> BugInfestation -> CodeRelease -> SourcepackageRelease (or ProductRelease if you rather)
[04:49] <kiko_> what about BugPackageInfestation?
[04:51] <stud> Hmm... I suspect BugInfestation is a decoy, it having been split into BugPackageInfestation and BugProductInfestation
[04:52] <kiko_> a red herring? why is it still there?
[04:53] <kiko_> hmmm
[04:54] <stud> Yes - buginfestation was supposed to have been dropped. I must have left it out of the patch.
[04:56] <stud> So you have bugpackageinfestation and sourcepackagebugassignment
[04:56] <stud> (love that consistent naming!)
[04:58] <kiko_> it's not meant to be confusing, it just turned out that way <tm>
[04:58] <lifeless> oh crap, forgotten the test user.
[04:58] <lifeless> foo.bar@canonical.com ? pw testing ?
[04:59] <kiko_> I can never remember myself
[05:09] <BradB> sabdfl: likes the bug prefix
[05:09] <BradB> lifeless: p/w test
[05:10] <BradB> 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] <BradB> 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] <stud> BradB: I got a patch from you on the buginfestation stuff, and the first line was 'drop table buginfestation'.
[05:11] <BradB> woo, yay me!
[05:11] <BradB> :P
[05:12] <stud> I think  I missed it when I put it into a database schema patch
[05:22] <kiko_> agh
[05:35] <kiko_> sl1p!
[06:23] <lifeless> hmmm
[06:23] <lifeless> where is  NotFoundError: (<SourceSource at 0x417d5eac>, u'linkTransparent.gif')
[06:23] <lifeless> ?
[07:08] <stud> Looks like someone used a relative URL that doesn't exist - it would be on the page you are trying to view?
[07:11] <lifeless> its triggered by the sourcesource-index
[07:12] <stud> Is there an <img src="linkTransparent.gif"> there? If not, it would be in one of the files included from there (such as the standard templates... whoops...)
[07:12] <lifeless> not in the template itself
[07:14] <stud> Looks like the evil is in plone.css
[07:14] <lifeless> do I need to file a bug report ?
[07:18] <stud> Hmm... yeah. If it is plone.css, then it is a deeper problem because it looks it is referencing ++resource++linkTransparent.gif
[07:21] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: added more edit notifications and fixed so that bugs can be added again (patch-689)
[07:52] <jblack> lifeless: I just figured out why adding revisions to the library is so slow.
[07:52] <jblack> for launchpad related things.
[07:54] <lifeless> oh?
[07:55] <jblack> part of it.
[07:57] <jblack> One part is searching for an ancestor revision takes about 1 second per revision to search the library.
[07:57] <lifeless> omg, no way!
[07:58] <jblack> hush. I'm getting to a point.
[08:00] <jblack> 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] <jblack> why would I be making sftp calls while searching for an ancestor revision ? 
[08:02] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: update importd (sourcesource) ui to be fully functional again (patch-690)
[08:04] <jblack> oh. I bet I know what its doing.
[08:09] <lifeless> jblack: checking for missing revisions ?
[08:10] <jblack> Yup.
[08:10] <jblack> but I definitely found a problem with patchlogs.
[08:10] <jblack> stating 2000 patchlogs doesn't sound like much.
[08:10] <jblack> but you have to do it for every revision.
[08:11] <jblack> For if you have to build 100 revisions, that's 200,000 lstat64s right there.
[08:11] <lifeless> gotta have it in scale though
[08:11] <lifeless> there's also 100* stats of the sources.
[08:12] <lifeless> anyway, abently has addressed this in the backbuilder.
[08:12] <lifeless> it doesn't re-inventory as it goes.
[08:17] <jblack> 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] <jblack> and then just start building from there.
[08:18] <jblack> never mind.
[08:19] <lifeless> we only stat the latest revision :)
[08:19] <jblack> not true.
[08:20] <jblack> 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] <lifeless> again, the backbuilder has improvements for this.
[08:27] <lifeless> I mean - its good to know that its a fairly stock tuning problem for tla.
[08:27] <lifeless> and I think this should be one of the early targets for canonical arch.
[08:31] <stud> 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] <jblack> Lets try email first.
[08:31] <stud> launchpad@ or private?
[08:32] <jblack> I'm not on launchpad, actually, so I guess private
[08:38] <jblack> 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] <jblack> :)
[08:38] <stud> Cool - I never knew I was that productive!
[08:41] <jblack> 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] <jblack> oh. never mind. empty delta
[08:44] <lifeless> stud: wiki - link from CanonicalArch page please
[08:45] <jblack> stud: Did you see the new tla help in 1.2.3rc1 ? 
[08:46] <stud> Nope - I'm just using the warty default atm
[08:46] <jblack> The help is broken down into functional categories.
[08:46] <jblack> each section is very short, and includes subjects such as "using arch for the first time" 
[08:47] <lifeless> jblack: thats fine, it simply demonstrates the quantitive amelioration thing
[08:47] <stud> 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] <lifeless> I'd much rather address it qualitatively.
[08:47] <lifeless> which abentlies work goes a long way to doing
[08:48] <jblack> 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] <lifeless> the backbuilder has a bunch of other changes supporting it
[08:50] <jblack> any reason they can't be broken up? 
[08:51] <lifeless> none at all
[08:52] <lifeless> do you see my point though? trimming our logs is -at most- a breathing room thing, not a solution
[08:52] <lifeless> which is why I'm not interested in pursueing it.
[08:53] <jblack> ok
[08:53] <lifeless> because, it forcing people to think about the mechanics.
[08:53] <lifeless> and that is the whole thing we want to avoid *except when its useful*
[08:57] <jblack> Ok then. MOving on to other jobs.
[08:58] <jblack> Jivera plans to take up to a week to merge about 5% of the 1.2.2rc3 and 1.2.3rc1 patches.
[08:58] <jblack> He's only taking the most vital ones at this time.
[09:01] <jblack> so what do you want to do with thelove? 
[09:06] <lifeless> what we planned yesterday
[09:06] <lifeless> I'll be tagging shortly
[09:06] <lifeless> and then we'll put in anything we think is an improvement
[09:18] <lifeless> start with the profile enabling patch please. just in a public branch, tagged from gnu-arch--2004
[09:18] <jblack> Ok boss.
[09:20] <lifeless> stud: you can do better than asasad :)
[09:20] <stud> My personal protest against mandatory comments ;)
[09:21] <SteveA> perhaps it refers to an unhappy mozilla qa person
[10:03] <lifeless> stud: so, have you heard of sealed branches ?
[10:03] <stud> vaguely
[10:04] <lifeless> they are hidden by default in rbrowse.
[10:04] <lifeless> the branch thing you mention, is directly a corollary of storing changesets rather than tree-snapshots.
[10:04] <lifeless> that, and the code organisation namespace being disjoint from the code storage namespace
[10:05] <lifeless> 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] <stud> Yup. So sealing is a partial solution.
[10:06] <stud> 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] <lifeless> stud: its pretty meaningless, to be honest.
[10:07] <lifeless> we can certainly calculate what was present in july 4 2003, and only show those branches & changesets.
[10:07] <lifeless> but snapshot-in-time isn't the english-use case.
[10:08] <lifeless> 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] <lifeless> 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] <stud> 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] <lifeless> 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] <lifeless> don't think about implementation. Just think about the use case.
[10:11] <limi> morning, y'all
[10:14] <stub> yo
[10:17] <Kinnison> Morning
[10:18] <stub> 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] <sabdfl> morning all
[10:34] <sabdfl> stub: around?
[10:34] <stub> yu
[10:34] <stub> p
[10:35] <sabdfl> kiko: infestations are what track a bug relative to a specific release
[10:36] <sabdfl> lifeless: did you solve this:05:23:40) lifeless: where is  NotFoundError: (<SourceSource at 0x417d5eac>, u'linkTransparent.gif')
[10:36] <sabdfl> looks like you need a resource for the image file
[10:38] <lifeless> sabdfl: not solved, I've no idea whats causing it - my template doesn't have a linkTransparent.gif reference.
[10:41] <limi> lifeless: probably in the CSS
[10:42] <limi> this is in Launchpad, right?
[10:42] <lifeless> yep
[10:43] <limi> back in a bit :)
[10:44] <sabdfl> lifeless: it's easy to fix
[10:45] <sabdfl> lifeless: put the following in your zcml file:
[10:45] <sabdfl>     <browser:resource
[10:45] <sabdfl>         name="linkTransparent.gif" file="../launchpad/images/linkTransparent.gif" />
[10:46] <lifeless> which zcml file (I haven't created any)
[10:46] <sabdfl> of course make the path correct relative to that zcml file
[10:46] <sabdfl> stevea around for a catch up?
[10:52] <sabdfl> --- orig/lib/canonical/launchpad/zcml/bugwatch.zcml
[10:52] <sabdfl> +++ mod/lib/canonical/launchpad/zcml/bugwatch.zcml
[10:52] <sabdfl> @@ -22,6 +22,7 @@
[10:52] <sabdfl>      <browser:editform
[10:52] <sabdfl>          name="+edit"
[10:52] <sabdfl>          schema="canonical.launchpad.interfaces.IBugWatch"
[10:52] <sabdfl> +        class="canonical.launchpad.browser.editview.SQLObjectEditView"
[10:52] <sabdfl>          label="Change Bug Watch"
[10:52] <sabdfl>          permission="launchpad.AnyPerson"
[10:52] <sabdfl>          template="../templates/default-editform.pt"
[10:52] <sabdfl> stub: that yours?
[10:52] <sabdfl> lifeless: you can actually use any zcml file
[10:53] <sabdfl> they all seem to get parsed at startup and any file affects the global namespace
[10:53] <SteveA> sabdfl: a bit later today would suit me better -- getting the wiki site conversions finished now
[10:54] <sabdfl> SteveA: ok, ping me when ready
[10:54] <SteveA> k
[10:54] <sabdfl> stub: around?
[10:55] <stub> pong
[10:56] <stub> Nope - that was Brads I think.
[10:57] <stub> Looks like he wants to add some behaviour to the view so the template or widgets can do funkier stuff.
[10:57] <sabdfl> lifeless: is this yours:
[10:57] <sabdfl> -class xSoyuzProduct(object):
[10:57] <sabdfl> +class SoyuzProduct(object):
[10:57] <sabdfl> ?
[10:57] <sabdfl> or ddaa?
[10:57] <lifeless> sabdfl: me. 
[10:57] <lifeless> it broke stuff.
[10:58] <lifeless> I'm in the process of migrating the code it broke to not need it.
[10:58] <sabdfl> rather than resurrecting old code, which we are trying to get rid of, can you please integrate with the new code
[11:02] <SteveA> sabdfl: are there any wiki pages on the new ZWiki site that you want to keep the contents of?
[11:03] <sabdfl> SteveA: yes, most of it
[11:05] <sabdfl> SteveA: in fact, all of it to be safe
[11:05] <SteveA> ok.  I'm going to copy it elsewhere, and then copy it back after the old site has been moved over.
[11:05] <sabdfl>        UbuntuReleases     HoaryHedgehog     HoaryGoals     HoaryKickoffMeeting      HoaryMergeProcess          HoaryReleaseSchedule         
[11:06] <sabdfl> these have had quite a lot of work done too
[11:07] <SteveA> ok, I'll make sure those are preserved
[11:07] <sabdfl> SteveA: http://www.ubuntulinux.org/wiki/WikiWishlist
[11:07] <sabdfl> could you point the zwiki guy at that?
[11:09] <SteveA> sure.  The bullet points in moin format work for me 
[11:10] <SteveA> as in moin, you have to ensure you write " * item" not "* item"
[11:12] <sabdfl> right
[11:12] <sabdfl> i'm not comfortable making ReST the default recommended format
[11:12] <sabdfl> it's way too picky about stuff that seems trivial
[11:13] <sabdfl> i end up spending ages trying to get rid of all the warnings on the page
[11:13] <sabdfl> SteveA: how do we regenerate the allowed-tags file?
[11:15] <SteveA> you run the script python checkarchtag.py
[11:15] <SteveA> python checkarchtag.py check   checks the tags
[11:15] <SteveA> python checkarchtag.py create   creates the allowed-tags.txt file
[11:16] <SteveA> running it with "check" tells you what files with implicit tags have been added, moved, or deleted
[11:17] <SteveA> sabdfl: so, the problem with ReST is not the format, but the implementation of the parser.
[11:26] <sabdfl> SteveA: is there a better implementation we can point the zwiki guy at?
[11:26] <SteveA> not that I know of.
[11:26] <sabdfl> whoa! just merged rocketfuel and have a gazillion test failures
[11:26] <Kinnison> yeah; I've got that
[11:26] <SteveA> there may be a better way to use the current implementation, though
[11:26] <Kinnison> which sucks a bit
[11:26] <sabdfl> so ReST is "a great format with no good implementations"
[11:27] <Kinnison> sabdfl: although a second run-through the tests seems to pass
[11:27] <SteveA> there may be a "be tolerant, we're only human" switch for the current implementation 
[11:27] <SteveA> I'll ask sm when he's online
[11:28] <sabdfl> 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] <sabdfl> who came up with ReST and what makes you think its a good format if there are no good implmentations?
[11:28] <sabdfl> that sounds like saying that "Arch is good it's just tla that sucks"
[11:29] <sabdfl> until someone actually does a good implementation we don't know that, we can only speculate
[11:29] <SteveA> 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] <SteveA> note that the errors you see are "warnings"
[11:30] <SteveA> I think it is possible to suppress the warnings, or have them in a status message
[11:30] <SteveA> the warnings are to tell you, the author, that your intentions were conveyed ambiguously to the software
[11:31] <SteveA> so, probably what needs to improve is the integration of the ReST parser into ZWiki
[11:45] <sabdfl> hi limi
[11:50] <stub> Anyone making page tests atm? 
[11:53] <sabdfl> stub: regarding the dogfood server
[11:53] <sabdfl> we need that to be a daily drop of schema+code
[11:54] <sabdfl> well, backup + schema + code
[11:54] <sabdfl> maybe arrange with elmo for backup of that db every six hours?
[11:54] <stub> Oohh... saying backup just gave me an idea on how that process can be much easier..
[11:56] <stub> sabdfl: I'm just using pg_dump from cron on emperor (and hoping that the disk is being backed up regularly...)
[11:57] <stub> I'll need to write that script that stores the database schema revision and only runs new patches.
[11:58] <Kinnison> Could a brazillian translate this please:
[11:58] <Kinnison>         if not build:
[11:58] <Kinnison>             # LA VARZEA
[11:58] <Kinnison>             return
[11:58] <stub> (which is being done manually on emperor due to paranoia)
[11:59] <limi> Kinnison: Brazil is still asleep (at the wheel? ;)
[11:59] <stub> SteveA: I'm about to commit a patch that gives us 'stories' in our page tests, where all the existing ones are a single story. Each story is run with a fresh instance of the database, so we can easily get isolation when we need it.
[11:59] <Kinnison> limi: *shrug* this is in gina :-)
[12:09] <ddaa> I see that spiv's fix for taxi.py contains an hardcoded instance of "launchpad_test"...
[12:10] <ddaa> lifeless: spiv: does that make sense to you? My buildbot test environment is using launchpad_dev atm... I'm confused.
[12:10] <lifeless> ddaa: thats a bug, should use the valu from canonical.lp
[12:11] <spiv> Yeah, it should.
[12:11] <ddaa> yeah... makes sense... I have modified my botmaster config so it sets launchpad.lp.dbname to 'launchpad_dev' before doing anything.
[12:11] <spiv> ddaa: Where are you looking?
[12:11] <stub> Hmm... should I fix the Makefile so launchpad_test is deleted next time I check something in through pqm, or is someone online who has access to nuke it on chinstrap?
[12:11] <ddaa> spiv: I'm looking at rocketfuel@canonical.com/buildbot--devel--0--patch-63
[12:12] <spiv> ddaa: That line is commented out.
[12:12] <ddaa> since I'm critically dependent on what goes in buildbot those days, I'm auditing the changes...
[12:12] <spiv> (And probably should be deleted altogether)
[12:13] <ddaa> Oh... yes, my bad...
[12:13] <spiv> But then, bob2 tells me that entire functions in that code need to be deleted altogether.
[12:13] <ddaa> I'm reading a reverse patch and forgot to reverse it mentally...
[12:14] <ddaa> Makes much more sense when read in reverse :-)
[12:14] <ddaa> I mean, in the right direction.
[12:14] <spiv> :)
[12:16] <ddaa> Actually I have still not yet found a satisfying way to audit changes as they come in...
[12:16] <spiv> ddaa: Put that on the ArchGripes page ;)
[12:17] <ddaa> I feel a bit lazy...
[12:17] <stub> Mmm.... I really like diff output included in my commit-notification emails
[12:17] <ddaa> btw
[12:17] <ddaa> I looks like pqm is not honoring the Reply-To header.
[12:17] <ddaa> So I am _still_ stuck with not receiving the pqm feedback...
[12:17] <stub> (or at least a link to a web page that shows me the diff, such as a URL to ArchZoom)
[12:18] <ddaa> lifeless: any advice to get the pqm feedback again?
[12:18] <lifeless> ddaa: your from should be correct.
[12:19] <sabdfl> stub: optimistic to think the disk is being backed up
[12:19] <ddaa> lifeless: I was unable to find how to customize the From with mailx, or the default from generated by postfix.
[12:19] <spiv> ddaa: I think I can help with the latter.
[12:20] <ddaa> Except by changing the mail name of the machine, but then that cause my root mail to be routed by my isp....
[12:20] <spiv> ddaa: I have a "canonical" (damn overloaded words...) map file that says this:
[12:20] <spiv> $ cat /etc/postfix/canonical
[12:20] <spiv> andrew  andrew-bounce@puzzling.org
[12:20] <lifeless> ddaa: ask lamont
[12:20] <lifeless> he knows all
[12:21] <spiv> ddaa: You'll need to run some magic command to make it turn that into a canonical.db file, and then add "canonical_maps = hash:/etc/postfix/canonical" to your main.cf
[12:21] <sabdfl> stub: any reason not to have updated the dogfood server to fresh code today?
[12:21] <stub> Then you just need 'canonical_maps = hash:/etc/postfix/canonical' added to /etc/postfix/main.cf
[12:21] <ddaa> NO CARRIER
[12:21] <spiv> ddaa: You may also need to read the documentation, in case I'm misunderstanding how all this works :)
[12:22] <sabdfl> i'm keen to get us actually dogfooding malone
[12:22] <ddaa> dude... exim is so easy... just put stuff in /etc/email-addresses... I'm getting angry at postfix....
[12:22] <sabdfl> as far as i could tell bradb brought the code up talking to launchpad_test
[12:22] <stub> sabdfl: Can't think of any reason why not, except that if I'm supposed to be doing it I guess I need to chase elmo for an account and relevant rights.
[12:23] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: 'stories' for pagetests (patch-691)
[12:23] <sabdfl> stub: ok, let's chase elmo!
[12:23] <ddaa> So, is there a archzoom or viewarch for rockefuel somewhere?
[12:23] <spiv> ddaa: https://chinstrap.warthogs.hbd.com/archzoom
[12:24] <ddaa> spiv: thanks
[12:28] <ddaa> spiv: Who is admining this thing?
[12:28] <ddaa> It needs to get signing set up.
[12:29] <ddaa> And probably a greedy-nonsparse revlib too.
[12:30] <stub> https://chinstrap.warthogs.hbd.com/archzoom/stuart.bishop@canonical.com/plone--secureauth--2.0.4--patch-1/CMFCore/CookieCrumbler.py.diff?diff
[12:30] <stub> :-(
[12:30] <ddaa> exactly, look at the "debug mode".
[12:31] <stub> oh - thought that was something the admin had to turn on - not a hyperlink :-)
[12:31] <ddaa> I reckon that the link does not stand out...
[12:31] <sabdfl> stub: just spoke with elmo
[12:32] <sabdfl> he'll be back online and have you setup within an hour, is that ok to get a first code update done today?
[12:32] <sabdfl> i think we'll need to hook the dogfood server up to something other than launchpad_test
[12:32] <stub> As long as there are no glitches that should be doable
[12:32] <sabdfl> great
[12:33] <sabdfl> he tells me that he *is* backing up your emperor backups but when he's online please verify with him that this is the case
[12:37] <ddaa> spiv: more buildbot questions
[12:37] <ddaa> I want buildbot to listen only to localhost.
[12:38] <spiv> That can be done.  Lemme see...
[12:38] <ddaa> I hardcoded that into the code, but lifeless reversed it and asked that it be done in master.cfg. However I hardcoded it because there is no option plumbing to do it.
[12:38] <spiv> Oh, it's using mktap, hmm...
[12:38] <ddaa> I actually looked at the code for that. The feature is missing.
[12:39] <ddaa> Can you do what is necessary to make that configurable from master.cfg... it would take you like 1/4 of the time it would take me.
[12:40] <ddaa> That was request 1.
[12:40] <ddaa> Now, request 2:
[12:40] <spiv> Well, using the plugins.tml/mktap system buildbot currently uses, the right way is to use Twisted's "strports" feature to allow specifying this on the mktap command line.
[12:41] <spiv> A better idea would be to not use mktap at all, and just use .tac files, but that's more work.
[12:41] <elmo> stub: you already have access to mawson and the 'launchpad' user which is superuser in postgres
[12:41] <elmo> stub: what more did you need?
[12:41] <stub> ok. I didn't know about that :-)
[12:42] <ddaa> In the waterfall status display, the width of columns is effectively set by the name of the job, because that tends to be a very long string (like 20-30 chars). I would like to have narrower columns so I can fit more data on a screen.
[12:42] <spiv> (Although it doesn't look like most of the options are exposed in via mktap anyhow..?)
[12:42] <elmo> there's a mirror on mawson:/srv/archive.ubuntu.com/ubuntu
[12:42] <elmo> I'm cron-ing it's update now - once a night is fine, I guess ?
[12:42] <stub> elmo: Mark wanted me to confirm that the database dumps on emperor are being backed up elsewhere.
[12:43] <spiv> Oh, yuck, it does it in the master.cfg... that's a bit of a nasty mess.  I wonder if upstream buildbot has tidied this up yet.
[12:43] <stub> What is the full dns name of mawson?
[12:43] <elmo> stub: yeah, they are
[12:43] <ddaa> My initial hack was to mangle the job names for display, introducing zero-width-space character around hyphen-minus chars. But lifeless reverted it because it makes it hard to tell actual spaces that could be in the job name.
[12:43] <elmo> stub: mawson.ubuntu.com
[12:43] <elmo> don't forget to add .ssh/config magic, i.e.
[12:44] <elmo> Host *.ubuntu.com
[12:44] <elmo>     ProxyCommand ssh stub@chinstrap.warthogs.hbd.com nc -q0 %h %p
[12:44] <carlos> morning
[12:45] <ddaa> So, request2 is: what do you think should be done to have the job names wrap, even though they contain no whitespace char? I guess something could be done using css or something to force the column width, but i like to keep the default layout where column width is automagically guessed. 
[12:46] <ddaa> spiv: nasty messes are welcome, I just do not want something listening out to the wide world with trivial login/pass on my machine.
[12:46] <spiv> ddaa: I understand that :)
[12:47] <ddaa> I could just hack it in back in the code, but that will cause grief because I will surely forget to back it out before commiting at one point.
[12:47] <spiv> There's actually a nice-ish fix for 1.
[12:48] <ddaa> please fire by e-mail.
[12:48] <spiv> Backwards compatible to.
[12:48] <spiv> too, rather.
[12:48] <spiv> I'm just making the patch...
[12:49] <lifeless> ddaa: if your machine is open-to-the-net, may I suggest iptables -A INPUT -m conntrack -state INVALID,NEW -j REJECT
[12:49] <lifeless> oh, with a -i eth0 in there
[12:49] <lifeless> buildbot has to run over the net, thats how it runs in production
[12:50] <ddaa> lifeless: I used to have a firewall-for-dummies. But since Ubuntu ships none i thought I might as well follow the policy and avoid needless world-listening services.
[12:51] <ddaa> I'm really reluctant to make my system any more complex than absolutely neede.
[12:51] <lifeless> sure.
[12:52] <ddaa> And I never took the time to learn all that is required to write a decent firewall config.
[12:52] <lifeless> if you hook in via master.cfg, I'm more than happy for your interface-specific patch
[12:52] <spiv> ddaa: Ok, this patch should help andrew.bennetts@canonical.com/buildbot--devel--0--patch-16... with that, you can now set a port number of e.g. "tcp:8008:interface=127.0.0.1"
[12:52] <spiv> (And it should be backwards compatible, too)
[12:52] <ddaa> spiv: thanks, I'll look at it right now.
[12:53] <ddaa> Well, right asaap
[12:53] <spiv> twisted.application.strports is where that magic happens.
[12:53] <ddaa> That sounds like love.
[12:54] <ddaa> I'm about to have to leave for lunch. Do you have a hint about improving the waterfall table layout?
[12:54] <spiv> Not really.
[12:54] <lifeless> ddaa: whats wrong with it ?
[12:54] <spiv> I'll let you know if I do.
[12:54] <ddaa> lifeless: the job names are too long and cause the columns to be needlessly wide.
[12:55] <lifeless> I don't think you mean the waterfall view
[12:55] <lifeless> Are you sure you don't mean the summary ?
[12:55] <spiv> ddaa: Perhaps name.replace('-', '&shy;') ?
[12:55] <ddaa> Hu... yes warterfall summary.
[12:55] <spiv> (soft hyphen)
[12:56] <ddaa> spiv: it's a mess
[12:56] <lifeless> I'd rather - gosh - change the job names
[12:56] <lifeless> we don't depend - anywhere - on the name not having spaces, AFAIK.
[12:57] <lifeless> but - I don't see any problem on my screen :|
[12:57] <spiv> lifeless: Sounds like a sane approach :)
[12:57] <lifeless> spiv: thats what my commit log said :)
[12:57] <ddaa> spiv: so, you are okay to update the database to have saner names? Using space instead of dash as a joiner?
[12:57] <lifeless> ddaa: not automated.
[12:57] <ddaa> Why not?
[12:57] <lifeless> I'm completely happy as they are.
[12:58] <lifeless> and not interested in futzing with the production database in an automatic sense.
[12:58] <lifeless> the production jobs, as they get approved, get a human decided name.  
[12:58] <lifeless> So far, I haven't managed to think of a consistent, /correct/ policy for that. So automation is right out.
[12:59] <ddaa> Bah. I can always futz the name in one more post-processing script in my job-importing stuff...
[12:59] <spiv> ddaa: style="overflow: auto;" in the HTML?
[12:59] <ddaa> lifeless: the job names are generated automatically from multiple parts joined by dash. Just replacing that with space would be reasonably sane.
[01:00] <ddaa> spiv: I can look at that, but I expect that it will not do the right thing for the table layout.
[01:01] <ddaa> Highest probability of not being rejected by lifeleless.
[01:11] <stub> Well that was fun
[01:12] <stub> elmo: Any hints on how to log into mawson without wedging my system so badly I need to power cycle?
[01:14] <SteveA> stub: what does your .ssh/config say for hosts with "canonical.com" in them?
[01:14] <SteveA> see bottom of https://wiki.canonical.com/MachineOverview
[01:16] <elmo> stub: paste me your .ssh/config
[01:16] <stub> Think I've got it - wildcard hell
[01:17] <elmo> oh, yeah, you have some prehistoric, and probably highly vulnerable ssh, don't  you?
[01:18] <stub> elmo: I'm running Ubuntu, so hopefully not.
[01:18] <Kinnison> How easy is it to do a 'like' comparison in a select using sqlobject?
[01:18] <elmo> oh, yay, you upgraded
[01:18] <stub> Had to give the mac back
[01:18] <Kinnison> Can I do something like FooTable.selectBy(barcolumn LIKE 'pattern%') ?
[01:19] <stub> Kinnison: yes, but the syntax is different.
[01:20] <stub> from sqlobject import OR, LIKE, CONTAINSSTRING, AND
[01:20] <stub> self.results = SourcePackage.select(AND(
[01:20] <stub>                 SourcePackage.q.sourcepackagenameID == SourcePackageName.q.id,
[01:20] <stub>                 OR(
[01:20] <stub>                     CONTAINSSTRING(SourcePackageName.q.name, s),
[01:20] <stub>                     CONTAINSSTRING(SourcePackage.q.shortdesc, s),
[01:20] <stub>                     CONTAINSSTRING(SourcePackage.q.description, s)
[01:20] <stub>                     )
[01:20] <stub>                 ))
[01:21] <Kinnison> so LIKE(Footable.q.barcolumn, 'pattern') ?
[01:25] <ddaa> lifeless: still here?
[01:25] <lifeless> no
[01:25] <ddaa> Good.
[01:25] <ddaa> How are you handling files~ in imported archives.
[01:26] <lifeless> Look in JobStrategy
[01:26] <lifeless> search for tagging
[01:26] <lifeless> it should be clear
[01:26] <ddaa> If you alter the tagging method to make *~ source files, that's going to play badly with "untagged-source unrecognized"
[01:26] <lifeless> Folk who tag can change the tagging method.
[01:26] <lifeless> our mandate is a clean import.
[01:27] <ddaa> lifeless: they will not. And they will complain.
[01:27] <ddaa> I'd rather vote for something much more specific.
[01:27] <ddaa> Like a .arch-inventory file that exists only for as long as the file~ exists.
[01:27] <lifeless> add that a enhancement for the future and move on.
[01:28] <lifeless> there are plenty of things that folk *will need to tune* after we do the import.
[01:28] <ddaa> I am really concerned that "tuning" issues like that will reflect very badly on Arch.
[01:29] <lifeless> oh, if you populate job.tagging_rules, its per import.
[01:29] <lifeless> and I think that ~ is probably a good candidate for per-import tuning.
[01:30] <ddaa> I understand it's per import. But that effectively going make the import unusable out of the box for tagging.
[01:30] <lifeless> ddaa: I understand your point. I'm not disagreeing. But we have a much more serious problem - import volume.
[01:31] <ddaa> Okay. Can we agree to postpone the imports that contain file~ then?
[01:31] <lifeless> no.
[01:31] <ddaa> Better to focus on what will work right.
[01:31] <lifeless> but we can change the tagging file in them after the import.
[01:32] <lifeless> in the import-branch.
[01:32] <ddaa> You mean creating a revision in the import branch which is not a match for a cvs revision?
[01:32] <lifeless> yes
[01:32] <lifeless> we'd be doing that if we dynamically add and remove .arch-inventory files anyway.
[01:33] <ddaa> Well... that's only half brain-damaged.
[01:33] <ddaa> With .arch-inventory, we can (and should) fold those changes with the related cvs change.
[01:33] <lifeless> file a bug, we can discuss the detail later.
[01:34] <lifeless> this should not be process blocker.
[01:34] <ddaa> But okay. Fixing the tree later is reasonably useful.
[01:34] <ddaa> But I fear it's going to bite our arse some day.
[01:35] <lifeless> depends on the use case for the branch.
[01:35] <ddaa> Exactly.
[01:35] <ddaa> For tag-on-latest it's not a problem.
[01:36] <ddaa> The issue is when someone will come up with a unexpected use case.
[01:36] <lifeless> the expected use cases are:
[01:36] <lifeless> a) project tags, and runs their official branch from this
[01:36] <lifeless> b) sourcerer tags, and runs its branches from this.
[01:37] <ddaa> None are really critical on the history.
[01:38] <ddaa> Actually, none really depend on history at all.
[01:38] <lifeless> well they do - projects usually have at least one member with a strong focus on the history.
[01:39] <lifeless> and our onoing syncs depend on the history processing being effective, because todays sync becomes tomorrows history.
[01:39] <ddaa> yup. This my reluctance for putting uneditable trees in the history.
[01:39] <ddaa> *Thus my...
[01:40] <lifeless> Now you have lost me completely.
[01:40] <lifeless> Let me short circuit this.
[01:40] <lifeless> what project are we talking about 
[01:40] <lifeless> ?
[01:41] <ddaa> E.g. w3c-wwwlib
[01:41] <lifeless> what date was the last commit in CVS ?
[01:41] <ddaa> Or any project that contains a file~ in the CVS. That's more of a general design problem.
[01:41] <limi> lunchtime
[01:41] <lifeless> (cscvs log -P MAIN..
[01:41] <lifeless> ddaa: do not generalise on me here.
[01:42] <lifeless> we've got a sample size of >> 50 projects that I've personally inspected during the various tests, and only this one has this file.
[01:42] <lifeless> its not a general problem if /one/ repo has it.
[01:42] <lifeless> yes - we might be able to do better -in general-. But - will it be good enough *for this project*.
[01:42] <lifeless> When we have 2, or 3, we can seriously consider writing a general solution.
[01:43] <lifeless> But a general solution for an outlier is /how we got the tla ui/
[01:43] <ddaa> Ok. I assumed that was actually happening in other projects and the moving *~ out of the backup and into the source regex.
[01:43] <lifeless> no, I don't allow ~ in all projects.
[01:43] <ddaa> ... was the solution you used routinely.
[01:43] <lifeless> depends on the file.
[01:43] <lifeless> I make a per project call.
[01:43] <SteveA> hi elmo
[01:44] <ddaa> So, since the problem only occurs with ONE project, we can postpone making a decision. If the issue pops up in other projects, a more general solution will be devised. So at this point we do not want to have broken imports out.
[01:44] <ddaa> *at this point we will not want
[01:44] <elmo> SteveA: ?
[01:44] <SteveA> hi elmo
[01:45] <SteveA> shortly, I'll be running a script that copies wiki pages from wiki.ubuntu.com to ubuntulinux.org/newwiki
[01:45] <ddaa> I think I have made my point through to you.
[01:45] <ddaa> Then it's your call.
[01:45] <SteveA> when that is done, and newwiki doesn't look too bad, i'll be merging ubuntulinux.org/wiki and newwiki
[01:46] <SteveA> after I've done this, I'd like the old wiki site to be made read-only
[01:46] <elmo> eh, is this a good idea, considereding we don't have the caching problems fixed?
[01:46] <SteveA> except perhaps for a few people like me and mark and lu
[01:46] <SteveA> and also...
[01:47] <SteveA> I'd like /wiki excluded from the "ignore cacheing directives" rule
[01:47] <SteveA> on ubuntulinux.org
[01:47] <SteveA> is that possible?
 and also...
 I'd like /wiki excluded from the "ignore cacheing directives" rule
 on ubuntulinux.org
 is that possible?
[01:47] <ddaa> elmo: can you create tla signing rules and a non-sparse revlib for archzoom? Pleas.
[01:48] <thom> SteveA: cache-control headers are respected
[01:48] <thom> SteveA: if you mean, you don't want it cached at all, that's doable too
[01:48] <lifeless> ddaa: I've made my call. 
[01:49] <SteveA> thom: I thought on www.ubuntulinux.com, for all pages, cache-related headers are not respected
[01:49] <elmo> ddaa: no, not if that's all you've got to say.  if you give me working, step by step instructions, then sure
[01:49] <SteveA> and on site-edit.ubuntlinux.org (read .org above too please), nothing is cached
[01:49] <thom> SteveA: #       CacheIgnoreCacheControl On # Disabled - Thom - 20/10/2004; no longer necessary
[01:50] <ddaa> elmo: okay, I'll gather more information on what is needed when I have some spare cycles...
[01:50] <SteveA> why was it no longer necessary?
[01:50] <thom> however, plone still doesn't send Last-Mod (but prolly will by end of play today)
[01:51] <thom> SteveA: cos they fixed the totally broken cache-control headers they (upfront) had set up
[01:51] <SteveA> why will plone do that by end of play today?
[01:51] <thom> because i'm planning to fix it
[01:51] <SteveA> you do know that someone is being contracted at the moment to sort out cacheing on our plone site properly?
[01:52] <thom> ...
[01:53] <SteveA> back to the wiki stuff.  I'm running a script that takes wiki pages from wiki.ubuntu.com, and copies them to ubuntulinux.org/newwiki
[01:53] <SteveA> then I'll be merging newwiki with wiki on ubuntulinux.org
[01:53] <SteveA> when that's done, I'd like the wiki site on wiki.ubuntu.com made read-only, except for certain people such as me and mark and lu
[01:54] <SteveA> I was concerned that the cacheing on ubuntulinux.org/wiki would be too broken to start using that
[01:54] <SteveA> but, if that's fixed now, that's all good.
[01:56] <SteveA> thom: viktorija zaksiene is working on makeing our plone sites work well with cacheing.  she has a copy of the ubuntulinux.org plone site, and the apache configs.  she is on irc as "ryzaja" if you want to chat about what she is doing.
[01:57] <carlos> SteveA: Tags have been removed:
[01:57] <carlos> c7271ec2-c8e7-4bd0-a78c-6337e9111989 database/sampledata/rosetta-alpha.sql
[01:57] <carlos> You should re-generate the allowed-tags file.
[01:57] <carlos> where should I fix it?
[01:57] <thom> SteveA: k, thanks
[01:58] <SteveA> does my wiki-moving plan sound okay?
[01:58] <SteveA> carlos: python checkarchtag.py create
[01:58] <carlos> SteveA: thanks
[02:05] <Kinnison> Okay; how do I get the database harness working in this newly unified config thing?
[02:23] <stub> So anyone know how the launchpad instance on mawson is supposed to be upgraded without doing a complete reinstallation? I can't find a relevant config file in rocketfuel@canonical.com/dists--devel--0, or any suitable launchpad branches in rocketfuel, so I suspect there is no actual process setup?
[02:25] <lifeless> stub: the devel config should be suitable for dogfooding
[02:25] <ddaa> lifeless: btw, I see now way to clobber the backup regexp per-project in order to make it more restrictive.
[02:26] <ddaa> And backup is matched before source.
[02:26] <ddaa> Therefore, the issue is blocker for w3c-wwwlib
[02:26] <lifeless> ddaa: good point. you'll need to do an enhancement for that - but as its in the same pattern as the current facility, that should be easy.
[02:26] <stub> lifeless: It aint going to be until we rename the database then :-(
[02:26] <ddaa> lifeless: filing an extensive bug right now.
[02:27] <lifeless> please add a new bug for 'cannot tune backup tagging method'
[02:27] <lifeless> and make w3m-... depend on it
[02:27] <lifeless> assign to you, qa contact me.
[02:28] <ddaa> I'm writing "cscvs should be smart at versioning backup~ files" with a thorough design for .arch-inventory handling. I will file that additional bug you request, but I would like to make the w3c-wwwlib sync bug depend on that bug I'm writing too.
[02:29] <lifeless> depend on both
[02:29] <lifeless> .arch-inventory handling is already written in hct.
[02:29] <ddaa> Ok.
[02:29] <lifeless> we'd be better off leveraging that rather than designing something new.
[02:29] <ddaa> Oh, I hope it matches the design I just came up with :-)
[02:29] <lifeless> but that will require the ok to move that code into pyarch.
[02:30] <ddaa> The remove condition needs to be different from the add condition.
[02:30] <lifeless> ddaa: try hct add & hct delete someday.
[02:30] <ddaa> I intend to.
[02:32] <ddaa> inventory-classification and .arch-inventory parsing and mutation are on the todo list.
[02:32] <ddaa> The specific ways to leverage those are application-specific imo.
[02:33] <lifeless> for now though, please focus on the low hanging fruit approach. identify and move along.
[02:33] <ddaa> yessir, that's my intention when suggesting to postpone w3c-wwwlibs
[02:34] <lifeless> yep, I'm agreeing to that as the ~ cannot be per-project tuned
[02:35] <stub> lifeless: So in your experience, should I do a checkout and build-config in my home directory, copy the checkout to /srv/launchpad.ubuntu.com/whatever, chown and swap it with the previous installation? Or can the launchpad user do the checkout directly, possibly though a mirror of the rocketfuel archive stored locally?
[02:36] <lifeless> stub: on galapagos & macquarie, the user just accesses the rocketfuel archive directly, by sshing in with a separate ssh key on my user
[02:36] <lifeless> on chinstrap
[02:38] <stub> So the account on chinstrap is accessible to anyone with access to the account on galapagos/macquarie? Hmm...
[02:39] <lifeless> my account on chinstrap is very limited in access
[02:39] <lifeless> anyhoo, its what elmo said to do in oxford.
[02:39] <lifeless> so...
[02:42] <cprov> lifeless: please, "arch_commit: unable to acquire revision lock (could not rename file.)" how is wrong in this case ?
[02:42] <cprov> s\how\what
[02:43] <stub> I might be able to use ssh-agent to do it sanely, but the launchpad user doesn't have a home directory so ~/.ssh can't be created :-(
[02:44] <lifeless> cprov: tla lock-revision -b <revision that its trying to commit to>
[02:44] <lifeless> stub: ssh-agent is a real whole...
[02:44] <lifeless> hole I mean. bwah
[02:44] <lifeless> much worse than a throwaway ssh key 
[02:45] <lifeless> with a throwaway key, a compromise gets at chinstrap, and only there.
[02:45] <lifeless> with ssh-agent, a compromise gets to use /your/ key as it wishes.
[02:46] <lifeless> now, a throwaway key can easily have a passphrase on it, to mitigate the window-of-opportunity
[02:48] <ddaa> lifeless: any request before I go out to get proposals for a thinkpad?
[02:48] <lifeless> feedback on spivs taxi changes
[02:49] <stub> lifeless: I suspect we need a local copy of the rocketfuel archive then to do this sanely. The code update needs to be push-a-button or done via cron since the dogfood instance needs to be updated so often.
[02:50] <ddaa> lifeless: that's a big chunk... (ponders)
[02:50] <lifeless> my throwaway keys are passphraseless..
[02:50] <lifeless> talk to daf, hes got a auto updating server
[02:51] <lifeless> ddaa: at least start such a run before you go ///
[02:51] <cprov> lifeless: thank you very much, TLA seems to lost itself when the commit was broken by poweroff . was it expected ?
[02:51] <lifeless> you had a poweroff during a commit ?ouch
[02:52] <ddaa> cprov: yes, that is expected :-)
[02:52] <lifeless> yes, this is expected behaviour in that case - the transaction isn't rolled back so you can analyse the failure.
[02:53] <ddaa> cprov: the Law according to lifeless, is "do not release the lock in case of undiagnosable failure". Power-off falls nicely in the "undiagnosable failure" :-)
[02:53] <cprov> ddaa: lifeless: the nicest thing about it is, simple command and it is working pretty fine again :)
[02:55] <lifeless> ddaa: it will auto-kick in at the end of the importd
[02:55] <lifeless> run
[02:57] <ddaa> I need to import new infos to test that... so I first need to fix the importer to run on the update launchpad and so on...
[02:58] <lifeless> whats brokern with launchpad ?
[02:58] <lifeless> (don't you have a running config at all times?)
[02:58] <ddaa> type object 'SQLBase' has no attribute 'initZopeless'
[02:58] <ddaa> Trivial fix.
[03:05] <ddaa> ../lib/canonical/database/sqlbase.py:82: UserWarning: Something tried to set a _connection.  Ignored.
[03:05] <ddaa> Then nothing gets modified in the db... hints?
[03:06] <lifeless> in fact 0 you go, and chat with spiv when you return :)
[03:06] <lifeless> I'm sure spiv will have some thoughts
[03:06] <ddaa> Okay.
[03:07] <Kinnison> Can anyone tell me how to get harness.py working again?
[03:07] <Kinnison> I need to override it to use launchpad_dsilvers instead of launchpad_ftest
[03:09] <carlos> stub, SteveA: The test check that is run with make check at launchpad (and with every commit) is missing some unittest
[03:09] <carlos> make check pass
[03:09] <carlos> but python test.py -u canonical fails
[03:09] <spiv> ddaa: Ignore it, it's a new warning for an old problem ;)
[03:10] <spiv> ddaa: It's unlikely to be a real problem.
[03:10] <lifeless> spiv: sop why aren't things being modified ? 
[03:10] <lifeless> ddaa: is this in your updater ?
[03:10] <lifeless> if so, you need to commit the transaction.
[03:10] <ddaa> nah, it's a problem in infoImporter.
[03:11] <ddaa> Ha... that must be the missing bit.
[03:11] <lifeless> you are re-importing ?
[03:11] <ddaa> I'm importing jobs on-demand.
[03:11] <ddaa> And removing old jobs which are no longer needed.
[03:11] <lifeless> ohkay
[03:12] <lifeless> night all
[03:17] <Kinnison> dbname = "launchpad_ftest"
[03:17] <Kinnison> in lib/canonical/lp/__init__.py
[03:17] <Kinnison> meh?
[03:27] <Kinnison> kiko: please don't CC me on list mails if you can avoid it :-)
[03:28] <kiko> I forget. 
[03:29] <sabdfl> SteveA: i'm getting mixed messages on the plone cacheing front
[03:29] <sabdfl> one half are saying that plone is dumb and we need a new product installed which is what Viktoria is working on
[03:29] <kiko> Kinnison, I'm confused
[03:30] <sabdfl> another are saying that zope and plone are fine if setup correctly and that upfront made some mistakes in the setup
[03:30] <Kinnison> kiko: ?
[03:30] <kiko> Kinnison, we know the current packages because we just need to look at publishing and package tables, right?
[03:30] <Kinnison> yes
[03:30] <sabdfl> thom, SteveA, please comment ^^
[03:30] <kiko> what's the issue with proposed, then? can't it just be a special status in publishing?
[03:31] <Kinnison> because "proposed" is nothing to do with publishing
[03:31] <Kinnison> mark and I spent quite a while making sure we weren't combining concepts into the same tables where the concepts were wildly different
[03:31] <Kinnison> package proposals are clearly a policy thing. the publishing tables belong entirely to the publishing side of lucille really
[03:33] <kiko> fair enough, but this being up in the air blocks us (in the relevant places)
[03:33] <kiko> can you have multiple releases proposed for a single distro release?
[03:33] <Kinnison> then get onto mark about starting to design the derived distro policies
[03:34] <Kinnison> I'm currently blocked on fixing gina's build stuff because she can't import into the current database design
[03:34] <cprov> Kinnison: btw, haven't you decided about porposed yet ? another doubt: is there only one proposed version for one architecture ?  
[03:34] <kiko> yeah, cprov's question is mine as well
[03:35] <Kinnison> package proposals are the domain of the *DERIVED DISTRO POLICY* and thus have not been given any space in the db (dunno about thought on sabdfl's part, but I got the impression at the launch party that sabdfl and I and several others are probably going to have to have a meeting to design this)
[03:35] <cprov> Kinnison: I mean, if the build fails on it (for all archs) it should be replaced by the new uploaded packages with the correction ?
[03:36] <kiko> hmmmm
[03:36] <Kinnison> cprov: build fails for what when where how?
[03:37] <cprov> Kinnison: I understand this as Policy question only, too 
[03:37] <Kinnison> cprov: there is too much undefined currently for me to give answers right now
[03:37] <kiko> I still haven't grasped why a certain package being proposed for a certain release can't be simply indicated in publishing as a "not ready" state. Maybe I'm thick <wink> 
[03:38] <kiko> then the policy can hide behind that interface; as a decision is made the status is updated as a consequence.
[03:38] <Kinnison> publishing == package(and files) are somewhere going into or coming out of the archive which goes onto disk
[03:38] <kiko> I'm aware of my naivet but please enlighten us because nobody here knows.
[03:39] <Kinnison> For a record to be in the publishing tables implies that the distrorelease's ftpmasters have already accepted the upload in some way; which could only be done automatically via a policy which says "accept <some spec>" or something
[03:40] <kiko> hmmm
[03:41] <kiko> and so you feel an "incomplete", "pending" or whatnot status there would be "bad"? why?
[03:41] <Kinnison> the publishing tables used to confuse the issues of policy-based-proposal, the upload queue and also the publishing statemachine. I've managed to clean it out to just the publishing state machine. I feel adding proposals back in will just confuse the hell out of the entire system
[03:42] <kiko> it does seem to simplify things significantly on our side, however. :)
[03:43] <Kinnison> So we should fuck the database normalisation over because it makes things easier for the UI?
[03:44] <kiko> Kinnison, I just want to understand the issue clearly here. If we had pending in the publishing table, does that mean we would be duplicating data that will live elsewhere (and that is trivially obtainable)?
[03:44] <kiko> Kinnison, I'm not saying fuck database normalization, 
[03:45] <Kinnison> kiko: I don't know how easily available the proposals will be; because noone has written any tables for it
[03:45] <Kinnison> kiko: However putting proposals into the publishing state machine is plainly wrong to me
[03:45] <kiko> fair enough.
[03:46] <Kinnison> kiko: What we really need is for sabdfl to have time to look into how to do proposals properly :-)
[03:46] <kiko> the astroman's spread too thin as it is
[03:46] <Kinnison> I know; but derivative distributions and the policy governing them really is his baby
[04:00] <cprov> sabdfl: hi, what do you mean w/ " represent the state of an archive" ?
[04:01] <BradB> morning
[04:01] <Kinnison> hey brad
[04:01] <BradB> hi
[04:08] <sabdfl> don't worry abut how to get the packages in, or get them out
[04:08] <sabdfl> just present, on the web, the state of those tables
[04:08] <BradB> SteveA: sure
[04:08] <sabdfl> we ARE NOT YET TRYING TO SOLVE THE WORKFLOW
[04:08] -dmwaters(dmwaters@dmwaters-gentoo.staff.freenode)- {global notice} Hi all! It appears that one of our hubs is having some major routing problems. I'm working on working around this problem, and any further messages will be given in wallops
[04:08] <sabdfl> k?
[04:08] <cprov> sabdfl: I see
[04:10] <kiko> sabdfl, sure. otoh we would like to present releases pending for a certain source package and we are unable to. 
[04:10] <kiko> this is driven stricly by a soyuz completeness review
[04:10] <SteveA> BradB: https://chinstrap.warthogs.hbd.com/~stevea/zwiki-2004-10-26.tar.gz
[04:11] <cprov> sabdfl: where should came this new releases from ? fake ones ?
[04:11] <kiko> cprov, huh?
[04:11] <SteveA> sabdfl: any objection to giving simon micheal management rights in the wiki folder on ubuntulinux.org?  He's keen to help get things working nicely.
[04:12] <cprov> kiko: if we want to show unpublished data, we should have some unpublished data ...
[04:12] <SteveA> s/micheal/michael/
[04:13] <kiko> cprov, yes. I suspect sabdfl wants us to just ignore this for now, though.
[04:13] <kiko> (the uppercasing is a big hint)
[04:17] <cprov> kiko: then I don't understand the issue on this ... is something like "keep it as it is" ? since we just have "published" packages now ...
[04:18] <kiko> cprov, yes, I guess we'll just have published packages displayed for sourcepackages, and pending will live as a bugzilla issue.
[04:19] !dmwaters:*! Hi all! Looks like sprint is to blame for our routing problems this morning. I've worked around the problem for now, but hopefully, it'll clear up soon
[04:21] <cprov> kiko: ok, what I see is that is impossible to have PROPOSED packages for Warty anyway, since it is frozen, It'll come just with hoary imports using gina in update mode .
[04:23] <kiko> yeah
[04:25] <Kinnison> sqlobject select stuff...
[04:25] <SteveA> BradB: please tell me when you've updated ZWiki and restarted plone
[04:25] <Kinnison> How do I select in the form: foo=1 and bar like '%thing' ?
[04:26] <spiv_> Table.select("foo=1 and bar like '%thing'")
[04:26] <Kinnison> eww; okay
[04:26] <cprov> kiko: ok, now more than "New Features" approach we should concentrate ourself in get Soyuz working on mawson soon, do we have any news about postgres issue on mawson ?
[04:27] <Kinnison> there's no 'EQUAL()' like there is 'LIKE()' ?
[04:27] <spiv_> Oh, you're using the Table.q.foo hack?
[04:27] <kiko> cprov, elmo solved it.
[04:27] <Kinnison> spiv_: well, I'll use whatever is recommended
[04:27] <spiv_> Table.q.foo=1, etc.
[04:27] <cprov> kiko: I'm verifying ...
[04:28] <spiv_> I'm ambivalent.  There are nice aspects to using Table.q.foo, but it still feels a bit dirty to me.
[04:29] <spiv_> (But not having to worry about properly quoting values is a pretty big plus)
[04:29] <Kinnison> What I want is effectively: AND(PublishedSourcePackageFile.q.distribution=1, LIKE(PublishedSourcePackageFile.q.libraryfilealiasfilename,'%dsc')) which gives: SyntaxError: keyword can't be an expression
[04:30] <stub> ==, not =
[04:30] <sabdfl> SteveA: none, go ahead with simon micheal
[04:31] <SteveA> k
[04:31] <sabdfl> kiko: the "pending" mechanism in soyuz is (a) unspecified and (b) completely different to the Katie equivalent
[04:31] <spiv_> What stub said
[04:31] <spiv_> (Bizarre syntax error text, though)
[04:31] <Kinnison> AssertionError: Database None unknown
[04:31] <sabdfl> so we can't easily represent meaningful data there until we spec and implement the workflow, because we can't easily pull that data from a katie db
[04:32] <sabdfl> what i'm focused on tis week is getting soyuz, malone and doap all running on mawson, with a db that represents useful info
[04:32] <BradB> SteveA: it's updated and restarted
[04:32] <SteveA> thanks brad
[04:32] <elmo> stub: oh i thought you were like, asleep
[04:32] <BradB> no prob
[04:32] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: scripts updates and sourcepackage buildlog (patch-692)
[04:32] <sabdfl> in the case of soyuz, that means that the db would reflect the state of the warty, warty-updates, warty-security, and hoary repositories
[04:32] <stub> elmo: Will be in a tick
[04:33] <elmo> stub: sabdfl wants read only access to lp-df - can you arrange for a group of your choosing to be granted read?  
[04:33] <sabdfl> this we obtain by (a) rsync and katie dump, (b) gina & nicole magic
[04:33] <sabdfl> run daily
[04:33] <sabdfl> cprov, kiko, bradb we need to get this dogfood server bedded down today
[04:33] <sabdfl> elmo: do we have the archive rsync in place to mawson for gina and nicole?
[04:34] <elmo> yeah
[04:34] <sabdfl> elmo: also, can we get a dumpt of the katie db along with that archive rsync?
[04:34] <stub> elmo: I don't understand
[04:34] <sabdfl> stub: i have a mark@mawson account, and want to be able to psql launchpad_dogfood
[04:34] <sabdfl> i want to be able to debug the dogfood server
[04:35] <sabdfl> but don't want superuser rights in that db
[04:35] <elmo> sabdfl: yeah, doing that now
[04:35] <stub> ok
[04:35] <sabdfl> great
[04:35] <sabdfl> cprov, Kinnison, today, please let;s get gina and nicole running against the mawson archive so that we start to populate the dogfood server with real data
[04:35] <sabdfl> or real-looking data
[04:36] <sabdfl> stub will give us a daily code update and schema update
[04:36] <sabdfl> so from tomorrow we will be able to point our good friends the hoary team at mawson and say "see what we are building for you"
[04:37] <elmo> dump's in /srv/archive.ubuntu.com/projectb.dump
[04:37] <sabdfl> over the next few weeks we'll add to it the buildd management, and the workflow, so that we can hopefully switch to using soyuz to manage our archive during es-conf
[04:37] <sabdfl> from then on, the ubuntu archive will be totally in your hands
[04:37] <BradB> sabdfl: The dogfood server already is bedded down. It's running; it can be used.
[04:38] <stub> sabdfl: daily code update has work to be done - I've sketched out a strategy on launchpad@.
[04:38] <BradB> If you mean it needs an update though, well, that too can be done quickly enough.
[04:38] <cprov> sabdfl: ok, I just depends on Kinninson help for run Librarian
[04:38] <Kinnison> sabdfl: gina will have to be running with a librarian also since for now lucille doesn't have the cache logic in her
[04:39] <stub> BradB: The existing setup can't be updated that I can see, and it is talking to the launchpad_test database which from what people are saying is incorrect (I've heard people here say launchpad_dogfood, and other saying launchpad_dev).
[04:39] <sabdfl> BradB: yes, it does need an update, please go ahead and exercise stub's strategy :-)
[04:39] <stub> (Well.. updated apart from a manual process)
[04:40] <sabdfl> ok, well let's get a librarian up and running
[04:40] <sabdfl> i prefer launchpad_dogfood
[04:40] <BradB> stub: Why can't it be updated? I /think/ we can pretty much blow away whatever's there, because I don't think we yet have data worth keeping.
[04:40] <sabdfl> because it identifies a single specific db instance
[04:40] <BradB> stub: If you're meaning that you don't have a smooth, stylin, adminish way of doing it, I'm not sure how much I'm involved in making that happen.
[04:41] <Kinnison> Could someone tell me how to log into mawson then?
[04:41] <sabdfl> there's nothing there right now that I want to keep, i don't think rosetta has anything in there either
[04:41] <stub> BradB: Ok. I meant some sort of automated update (ie. without running diffs to see what local mods have been made and reapplying)
[04:41] <sabdfl> elmo: Kinnison needs to be able to work on mawson too
[04:41] <sabdfl> guys this is our mission for the day
[04:42] <sabdfl> i want to be able to walk mdz through malone this evening
[04:42] <sabdfl> and it has to be early because i've a freaking early start tomorrow to a keynote in frankfurt
[04:43] <elmo> created an account
[04:43] <stub> BradB: I'm happy to look into the automated update stuff tomorrow - I suspect the arch team might have some input to my thoughts, so a manual update should be fine for today.
[04:43] <BradB> sabdfl: Warning: Malone will be broken.
[04:43] <sabdfl> bradb where, why?
[04:43] <BradB> sabdfl: The UI changes have made certain things not be there anymore, namely editing product/package assignments.
[04:43] <sabdfl> ok i can fix that i'm sure
[04:43] <Kinnison> elmo: ta
[04:43] <BradB> I can work on fixing those, of course, but I'm not sure how much work's involved.
[04:44] <sabdfl> let me look at it
[04:44] <BradB> sabdfl: Do I need to care about any of the automated update stuff? If not, I can start checking in fixes right now instead.
[04:44] <sabdfl> Kinnison: please verify that you have what you need to get your side into production
[04:44] <BradB> sabdfl: ok
[04:44] <Kinnison> sabdfl: I'm not entirely convinced I know what my "side" is apart from the librarian
[04:44] <sabdfl> bradb; no, stub can take care of the backup / update process tomorrow
[04:44] <sabdfl> Kinnison: gina, nicole, i thought those transferred to you too
[04:45] <sabdfl> i'd like to be able to show soyuz with real data
[04:45] <BradB> Okay, I'll get back to finishing the edit notifications + fixing whatever else I see broken along the way.
[04:45] <sabdfl> and file bugs on real pacakges
[04:45] <Kinnison> sabdfl: I was under the impression that I was helping with gina; but not with nicole and that I didn't actually own either
[04:45] <sabdfl> BradB: let's plan for a code drop to mawson in two hours
[04:45] <sabdfl> cprov: is nicole still your baby?
[04:46] <cprov> sabdfl: I think so ..
[04:46] <sabdfl> if so, elmo, cprov needs mawson too
[04:46] <elmo> cprov has mawson
[04:46] <cprov> sabdfl: I'm there
[04:46] <stub> elmo: I suspect the launchpad@mawson user will need a home directory at some point. I will also need to know if the code should be pulled or pushed from chinstrap.
[04:46] <sabdfl> cprov: we need gina and nicole running on Kinnison's db and librarian today on mawson
[04:46] <elmo> stub: no, it doesn't, use /srv/launchpad.ubuntu.com or some other appopriate dir under /srv
[04:46] <carlos> SteveA: did you saw my comment about the test checks on commit?
[04:46] <sabdfl> stub: pull
[04:46] <cprov> sabdfl: ok
[04:46] <sabdfl> and manually, daily
[04:46] <SteveA> carlos: no
[04:46] <carlos> SteveA: it's not running all checks
[04:47] <sabdfl> stub: backup, pull, schema update, fire!
[04:47] <carlos> yesterday I broke one test and it did not detected it
[04:47] <SteveA> carlos: a pagetest?
[04:47] <BradB> sabdfl: ok
[04:47] <sabdfl> SteveA: why have we disabled page tests?
[04:47] <Kinnison> spiv_: Can I ask you to update server.tac in the librarian to use the new database choosing logic etc please?
[04:47] <carlos> no, doctests
[04:47] <spiv_> Kinnison: I'll take a look.
[04:47] <carlos> SteveA: make check from launchpad does not detect the error 
[04:47] <stub> elmo: I'm mainly concerned about ~/.ssh/authorized_keys and known_hosts
[04:47] <SteveA> sabdfl: are pagetests disabled?
[04:47] <Kinnison> spiv_: also a command-line way to change the ports/fatsam dir would make life way easier
[04:48] <carlos> there are still some tests failing since long ago that are only detected with "python test.py -u canonical"
[04:48] <elmo> stub: meh
[04:48] <spiv_> Kinnison: That's trickier :/
[04:48] <elmo> if anyone puts anything else in /home/launchpad, I'll hurt them
[04:49] <Kinnison> spiv_: or env vars or something so I don't have to maintain a patch against server.tac for mawson
[04:49] <spiv_> Env vars would work.
[04:49] <spiv_> The point of that tac is that it's a configuration file, it's supposed to vary for different deployments ;)
[04:49] <SteveA> carlos: "make check" is what pqm runs before merging.  It should run all pagetests.  If it runs anything else, that's a bonus.
[04:50] <carlos> only pagetests?
[04:50] <Kinnison> spiv_: It'd be really convenient if we could override it easily though (for now)
[04:50] <spiv_> (It's got a little too much non-config stuff in it atm)
[04:50] <carlos> I thought it was running unittests and doctest
[04:50] <SteveA> that's how I left it.  I recall that someone (I'd need to look up exactly who) said they were going to make it run other tests too.
[04:50] <SteveA> I haven't checked that this was done.
[04:51] <spiv_> Oh, I understand.  Just explaining why it is how it is :)
[04:51] <Kinnison> spiv_: aye
[04:51] <stub> as a quick hack, can we just have lib/config.py as a poor mans config file?
[04:51] <carlos> SteveA: it's not done, or it's not working correctly
[04:52] <sabdfl> SteveA: please can you also set the tags-check to display the numberof tags in the system, so we can notice if anyone adds any
[04:52] <spiv_> Kinnison: So, server.tac already calls canonical.lp.initZopeless...
[04:52] <SteveA> sabdfl: the tags check will forbid a checkin if anyone adds any.  unless they cheat by making a new allowed-tags.txt file.
[04:53] <Kinnison> spiv_: it does?
[04:53] <sabdfl> SteveA: precisely
[04:53] <Kinnison> spiv_: then the checkout on mawson is out of date :-(
[04:53] <sabdfl> that's why i want it to print the number of tags, in case someone cheats, not realising why that's there
[04:53] <Kinnison> spiv_: or I'm looking at the wrong place
[04:54] <sabdfl> stevea:
[04:54] <sabdfl> # Run all tests. test_on_merge.py takes care of setting up the
[04:54] <sabdfl> # database.
[04:54] <sabdfl> ./test_on_merge.py canonical
[04:54] <sabdfl> Tags have been removed:
[04:54] <sabdfl> c7271ec2-c8e7-4bd0-a78c-6337e9111989 database/sampledata/rosetta-alpha.sql
[04:54] <sabdfl> You should re-generate the allowed-tags file.
[04:54] <sabdfl> Running tests.
[04:54] <sabdfl> Traceback (most recent call last):
[04:54] <sabdfl> # Run the pagetests.  Ensure that launchpad is not running using
[04:54] <sabdfl> # the launchpad_test database, and that nothing else is using that
[04:54] <sabdfl> # database, or the tests will hang until these processes exit.
[04:54] <sabdfl> #./test_on_merge.py -f canonical.launchpad.ftest
[04:54] <sabdfl> note the last line
[04:55] <spiv_> Kinnison: Yeah, it does.  Line 16.
[04:55] <SteveA> sabdfl: who did that!
[04:55] <sabdfl> i didn't
[04:55] <sabdfl> arch blame, anyone?
[04:56] <Kinnison> dsilvers@rosetta:/srv/launchpad.ubuntu.com/launchpad-dogfood $ cat -n lib/canonical/librarian/server.tac | grep 16
[04:56] <Kinnison>     16  application = service.Application('Librarian')
[04:56] <kiko> ehe
[04:56] <Kinnison> spiv_: methinks mawson is out of date then
[04:56] <SteveA> what's the point of having tests if someone goes and disables them...
[04:57] <kiko> sabdfl, arch blame doesn't exist.
[04:57] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fixed some tests I broke yesterday (patch-693)
[04:57] <stub> The Makefile appears fine here...
[04:58] <spiv_> sabdfl: stub did it in patch-675, apparently.
[04:58] <stub> SteveA: Check the makefile. That commented out (the #). The tests are run a few lines above
[04:58] <cprov> elmo: how to transfer files from zhongshan to mawson ?
[04:58] <elmo> cprov: err, scp?
[04:58] <SteveA> my arch is still churning on star-merge
[04:59] <BradB> SteveA: yeah, i'm not sure what the problem is, based on what sabdfl pasted above, that looks like it runs all the tests
[04:59] <cprov> elmo: asks for pass ?
[05:00] <kiko> heh
[05:01] <elmo> cprov: echo "Please change my Debian password" | gpg --clearsign | mail chpasswd@db.warthogs.hbd.com
[05:01] <SteveA> my tla has finally given me the latest source
[05:01] <SteveA> so, yes, tests are all being run.
[05:02] <SteveA> there is a confusing comment left in the makefile
[05:02] <stub> That would be my decoy :-)
[05:03] <elmo> cprov: (assuming you've forgotten your password)
[05:03] <carlos> sabdfl: I fixed the  allowed-tags already
[05:03] <SteveA> carlos: have you made it print the number of tags? 
[05:03] <carlos> nope
[05:03] <carlos> SteveA: the rosetta-alpha.sql removal
[05:05] <cprov> elmo: if I should use the pass I wouldn't like to use something like this 'x@(&*%^*' <wink>
[05:05] <carlos> I mean, I did not disable anything, I just removed a file with an arch tag (yesterday) and today I asked you about how to fix that warning, it should be fixed in rocketfuel as soon as pqm accepts my last merge request
[05:06] <elmo> cprov: once you get a pass, you can change it via the web interface https://db.warthogs.hbd.com/ when you've logged into mawson or chinstrap
[05:06] <carlos> hmm, it's now at rocketfuel.
[05:09] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Some general kiko changes (patch-694)
[05:10] <cprov> elmo: no lynx on mawson, so no access to https://db.warthogs.hbd.com/
[05:10] <elmo> blah, there is on chinstrap
[05:12] <SteveA> elmo, can I get a log in to gentoo for a while to check some plone configs?
[05:14] <elmo> SteveA: enabled your account there
[05:15] <SteveA> thanks
[05:15] <SteveA> where's the ldap thinggie to change passwords etc.?
[05:16] <elmo> see scroll back
[05:16] <elmo> tho, you should really use ssh pub keys
[05:16] <elmo> i.e. 'cat .ssh/id_rsa.pub | gpg --clearsign | mail change@db.warthogs.hbd.com'
[05:16] <SteveA> I do.  at least, I do on chinstrap
[05:17] <SteveA> ta
[05:17] <SteveA> is that on a wiki page anywhere?
[05:19] <sabdfl> stevea, bradb: update on the cacheing situation
[05:19] <SteveA> cacheing?
[05:19] <sabdfl> yes
[05:19] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Now with arch-tags count (patch-695)
[05:19] <sabdfl> i know viktroia is working on this but expect we are going to be pissing in the wind
[05:20] <sabdfl> if we try to wait for a perfect solution to the integration of plone and apache
[05:20] <sabdfl> clearly, SOMEONE out there would have solved this cleanly, and documented it, if it was easy
[05:20] <BradB> sabdfl: That's who I recommended to do the job. :)
[05:20] <SteveA> right now, I'm trying to work out why moin mode in our plone does not like non-ascii characters
[05:20] <sabdfl> i see no reason why we should not just use https://www for authenticated connections
[05:20] <sabdfl> BradB: SOMEONE? they declined
[05:20] <sabdfl> and leave that entirely uncached
[05:21] <BradB> sabdfl: Nope, they were much more expensive.
[05:21] <SteveA> they also documented it, and i expect vika is following those documents
[05:21] <sabdfl> the main site on http://www. can remain cached
[05:21] <sabdfl> we just need to set things up so that the "log in" button switches you to https and keeps you there
[05:22] <sabdfl> and the "log out" button takes you back to http
[05:22] <sabdfl> thom has already set it up so that https is uncached
[05:22] <sabdfl> and http is cached
[05:22] <sabdfl> we just need to sort out the login, logout interaction
[05:22] <sabdfl> which should be trivial
[05:22] <SteveA> I expect the way to do that is for the plone standard template to redirect to https if there is a user logged in
[05:23] <SteveA> and it is on http
[05:23] <sabdfl> stevea: simpler even: just redirect to https for the login, and don't redirect back
[05:23] <sabdfl> and send the cookie to https://www. rather than http://www
[05:23] <SteveA> I don't think that would work effectively
[05:23] <sabdfl> the browser will then only send te cookie to https://www.
[05:23] <sabdfl> why not?
[05:24] <SteveA> cookies don't care if they are on http or https, do they?
[05:24] <BradB> sabdfl: Why not see what happens first from Vika working on this though?
[05:24] <BradB> I'm trying to fix some things in Malone atm before the code drop, and would have thought my time is better spent doing that atm.
[05:24] <sabdfl> bradb: i need a sensible answer yesterday, which is when i agreed to open up the web site
[05:24] <sabdfl> we have been faffing around for more than a month on auth and it is still not working
[05:24] <sabdfl> i'm trying to find the simplest solution that will work today
[05:25] <sabdfl> this is bs
[05:25] <SteveA> as soon as someone follows a link to the site, they'll be getting a confused cached page saying perhaps that they are logged in, perhaps that they are not.
[05:25] <BradB> yeah, i know it's bad. i guess vika hasn't had time to start on it yet.
[05:26] <lulu> BradB: vika is onto it - deadline is tomorrow.
[05:26] <sabdfl> steve: no, because the only cached pages will be not logged in
[05:26] <sabdfl> and the only logged in pages are on https and won't be cached
[05:26] <sabdfl> only question is whether or not the cookie will be sent to the http site
[05:27] <Kinnison> spiv_: have you made those changes for the librarian?
[05:27] <Kinnison> sabdfl: How do we update the codebase for launchpad-dogfood?
[05:27] <sabdfl> in which case we should get the proxy to auto-redirect to https for connections with the cookie
[05:27] <sabdfl> Kinnison: you commit to you rocketfuel before 18:00 UK time
[05:28] <Kinnison> sabdfl: So I have to wait until 18:00 before I start the librarian?
[05:29] <SteveA> elmo: I've mailed change@db.  but I'm still prompted for a password to get into gentoo
[05:30] <sabdfl> in future, stub will do a daily update of the codebase to dogfood, probably during his morning, our night
[05:30] <elmo> one sec
[05:30] <sabdfl> Kinnison: is the code you need already in rf?
[05:30] <Kinnison> sabdfl: apparently; yes
[05:31] <Kinnison> sabdfl: I'm just waiting for spiv to confirm
[05:31] <sabdfl> was it in rf over the w/e?
[05:31] <Kinnison> well; it's not in /src/launchpad.ubuntu.com/
[05:31] <sabdfl> bradb: can we do an earlier pull of the code and schema so that Kinnison can start bringing the librarian up?
[05:31] <elmo> SteveA: just propagation time, I've forced it through
[05:32] <sabdfl> bradb: i've "fixed" assignment editing (links work but the process and semantics need work)
[05:32] <BradB> sabdfl: the earlier you pull the code, the more bugs will be in it. i'm working on fixing what's broken, but there's still more to do.
[05:32] <SteveA> sabdfl: just checked the cookie spec.  so, we could mark the cookie as "secure"
[05:32] <SteveA> then it would be sent only over ssl
[05:32] <sabdfl> SteveA: perfect
[05:32] <SteveA> elmo: still asks me for a password
[05:32] <elmo> try logging in with the right user name?
[05:33] <elmo> i.e. 'stevea' not 'steve'
[05:33] <sabdfl> :-)
[05:33] <kiko> heh
[05:33] <SteveA> ah -- I misunderstook .ssh/config
[05:34] <SteveA> thanks elmo
[05:35] <SteveA> I have no idea if zope / average browser implements that part of the cookie spec, though.  I'll see if I can find out. 
[05:35] <stub> Standalone cookie crumber sets the secure flag automatically if the URL is https:, but Plone distributes the old CMFCore release. The relevant function is defaultSetAuthCookie if you want to backport it to Plone. I have the relevant code in my repository.
[05:40] <Kinnison> elmo: how do I become launchpad on mawson?
[05:41] <Kinnison> sabdfl: is the database we're working against called launchpad_dogfood then?
[05:41] <lulu> SteveA: how soon can the short term cacheing solution be implemented? and who will be  doing it?
[05:41] <elmo> Kinnison: 'sudo su - launchpad'
[05:41] <Kinnison> elmo: eww :-)
[05:42] <Kinnison> elmo: what ever happend to 'sudo -u launchpad -s' ? :-)
[05:42] <sabdfl> Kinnison: yes, i believe so
[05:42] <Kinnison> sabdfl: cool
[05:43] <elmo> you can probably do that to, 'sudo -l' and see if you care
[05:43] <sabdfl> stub: you are a machine
[05:45] <stub> A machine who is going to bed now...
[05:45] <spiv_> Kinnison: Sorry, was busy emailing my travel agent...
[05:45] <Kinnison> spiv_: fair enough :-)
[05:45] <spiv_> Kinnison: The initZopeless change is already in rocketfuel.
[05:45] <spiv_> Or was there something else you wanted?
[05:46] <Kinnison> spiv_: If you can get those fixes in within the next 1h15m then I will be clear to go :-) (the envvar stuff for overriding db name, disk root, ports etc)
[05:46] <spiv_> Oh, the environment variables.  Ok, I can do that now, that's fast.
[05:46] <Kinnison> thanks
[05:46] <stub> urp... canonical.lp.dbname == launchpad_ftest. Will fix tomorrow :-(
[05:46] <sabdfl> BradB: how do i use the OwnerWidget?
[05:47] <Kinnison> stub: yeah; that's buggering up running the db harness which I use for testing my lucille code :-(
[05:47] <sabdfl> does it basically allow me to get an owner added to an edit or add page without offering a listbox?
[05:47] <stub> sabdfl: Check IBug and the .zcml for its add form. It is an invisible widget that always sets the ownerid to the currently authed user
[05:48] <sabdfl> stub: before you crash
[05:48] <sabdfl> what's the status on the bugwatches?
[05:48] <sabdfl> are you happy it's ready?
[05:48] <sabdfl> for prime time?
[05:48] <sabdfl> do we have the "link any project to any bug tracker" stuff in place?
[05:48] <SteveA> stub, BradB: can you talk to each other about getting a cookie crumbler that sends secure-flagged cookies onto the ubuntulinux.org plone? 
[05:48] <stub> Working fine last I looked a few days ago. No support for authentication though, so might be a problem if we want to watch the canonical bugzilla.
[05:49] <stub> The code is hooked into the unittests so should have survived any recent changes.
[05:49] <sabdfl> ok, next week in that department could you add support for authentication, and the sourceforge bugtracker?
[05:51] <sabdfl> stub: thanks and g'night
[05:51] <BradB> sabdfl: The quickest person to ask would be the person who wrote it, but it looks like a widget you use like any other, but it's custom-tailored to suit a field you want to modify whose value is an ownerID.
[05:51] <BradB> SteveA: Added to tomorrow's todo list.
[05:51] <sabdfl> BradB: i'm trying to set it up so "add a subscription" basically only lets you add yourself
[05:51] <stub> sabdfl: I'm not sure of the best way of proceeding on the auth - it will make the bugtracker stuff much more complex if we want to support anything more complex than our own bugzilla. We either need to add columns to the table to store the credentials, or encode it in the URL which might be naughty.
[05:52] <sabdfl> stub: columns in the db is sensible
[05:52] <BradB> sabdfl: we don't want any kind of edit form for that
[05:52] <sabdfl> bradb: or do we want to work on the basis that you CAN subscribe someone else?
[05:53] <sabdfl> SteveA: wiki people are wanting to know what the status is
[05:53] <sabdfl> they are continuing to edit the old wiki but worried their content will be lost
[05:53] <stub> sabdfl: Would it be acceptible to turn off requiring basicauth from our IP addresses? or will elmo punch me for suggesting that?
[05:53] <BradB> sabdfl: if that's how it is currently (which i think it is) then i'd say yes. fish, bigger to, fry, etc. I think there's more valuable changes that can be done to Malone presently.
[05:53] <spiv_> Kinnison: Merge request sent.
[05:54] <Kinnison> spiv_: fantastic
[05:54] <Kinnison> sabdfl: filelist files for apt-ftparchive successfully built
[05:54] <SteveA> sabdfl: I'm working with simon m. on why pages with non-ascii characters are not working.
[05:54] <Kinnison> sabdfl: I'm writing a test apt.conf which assuming it works will generate the packages files etc for us
[05:54] <BradB> SteveA: are reST pages still not working with utf-8?
[05:54] <SteveA> once that's working, I can run my import script, and it will import without errors.
[05:55] <SteveA> BradB: this is a different problem, specific to moin formatting
[05:55] <BradB> ok
[05:55] <sabdfl> bradb: its potentially a trivial change, it's more a question of how we want malone to behave than how hard it is to get it there
[05:55] <SteveA> BradB: one more ZWiki bugfix coming up
[05:55] <sabdfl> Kinnison: super, thanks, what's next?
[05:56] <BradB> woo
[05:56] <sabdfl> SteveA: ok, so no conversion has been done?
[05:57] <SteveA> I have a script that pulls things across.  I've been running it in a test folder, noting problems, and getting them fixed.
[05:57] <BradB> sabdfl: then i'd say it's best for the user to decide if they want to be subscribed. if anything, subscribing anyone else can be a func for priv'd users later on
[05:57] <SteveA> when all important problems are fixed, I'll run the script one final time
[05:57] <Kinnison> sabdfl: once I'm happy that I can do an apt.conf to generate the packages files etc; I need to write something to pull config out of the lucilleconfig columns we added to the distrorelease and distribution tables and generate the bits to tack on the side. then I should be in a position to have a script which when invoked can publish an archive to disk
[05:57] <sabdfl> stevea: can we announce to the wiki team that their changes will not be lost?
[05:57] <Kinnison> sabdfl: then I need to sit back; take stock; and decide which direction to push at next
[05:57] <sabdfl> this means that before you run the script canonically, we LOCK the old wiki, for good
[05:58] <sabdfl> and the wiki system is down while we bring up the new one
[05:58] <SteveA> sabdfl: their changes will not be lost
[05:58] <SteveA> they can keep working on the old site
[05:58] <SteveA> until it is closed to forbid more work
[05:58] <sabdfl> ok, so you will lock it before the final run?
[05:58] <SteveA> shortly after it is closed, I'll go through the RecentChanges page, and make sure we've got everything
[05:58] <sabdfl> how long do you think it will take?
[05:59] <SteveA> from now -- depends if we've fixed all the important bugs in zwiki moin mode
[05:59] <sabdfl> i'd rather we locked it, then ran the script, so there's no arsing about with recent changes
[05:59] <sabdfl> :-)
[05:59] <SteveA> that means I'll have to do two "final" runs, but that's okay
[05:59] <SteveA> I still need to check recent changes before the final final, to make sure I have any newly added pages
[06:00] <SteveA> but anyway -- no changes are going to be lost
[06:00] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Allow librarian settings to be overriden by environment variables (patch-696)
[06:02] <SteveA> BradB: https://chinstrap.warthogs.hbd.com/~stevea/zwiki-2004-10-26b.tar.gz
[06:02] <Kinnison> spiv_: looks good; thanks
[06:03] <Kinnison> so the clear initZopeless() call uses canonical.lp.dbname?
[06:05] <SteveA> BradB: please ping me when ZWiki is updated
[06:06] <spiv_> Yes.
[06:08] <Kinnison> spiv_: which means launchpad_ftest unless I override it in server.tac ?
[06:08] <BradB> SteveA: updated, restarted.
[06:09] <spiv_> Yes.
[06:09] <Kinnison> spiv_: So much for avoiding editing server.tac :-(
[06:09] <Kinnison> spiv_: Thanks for those env changes though; they'll be way useful :-)
[06:11] <spiv_> Yeah, that was my thinking.
[06:11] <Kinnison> Right
[06:12] <spiv_> 15:46 < stub> urp... canonical.lp.dbname == launchpad_ftest. Will fix tomorrow :-(
[06:13] <Kinnison> I thought sabdfl wanted something running by tonight though :-(
[06:15] <dilys> Bug 2136 resolved: Translation of new pofiles is broken since the table split
[06:15] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2136
[06:16] <SteveA> thanks BradB
[06:16] <BradB> Kinnison: we can do an update on mawson, but two things will not happen: 1. a shiny way of updating the code, 2. keeping any of the existing data. sabdfl can probably confirm that this doesn't matter yet.
[06:17] <BradB> the db will still be launchpad_test as well, because it's too error prone to think of changing yet, imho.
[06:18] <Kinnison> but after the update, canonical/lp/__init__.py will likely say launchpad_ftest
[06:19] <BradB> why not change it?
[06:22] <SteveA> BradB: did you restart the plone site?
[06:22] <BradB> right before i said i did, yep
[06:23] <SteveA> can you do so again, please?
[06:24] <BradB> done
[06:24] <SteveA> thanks
[06:26] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Added a missing constraint from to a POMsgSet query that caused the bug #2136 (patch-697)
[06:26] <sabdfl> bradb, Kinnison we can blow away the db today
[06:28] <carlos> spiv_: I'm executing one of the rosetta scripts and I get:
[06:28] <carlos> psycopg.OperationalError: FATAL:  database "launchpad_ftest" does not exist
[06:28] <carlos> ; used connection string 'dbname=launchpad_ftest'
[06:28] <carlos> It's using canonical.lp.initZopeless()
[06:28] <carlos> to connect to the database
[06:43] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: added package infestation edit notification (patch-698)
[06:45] <elmo> SteveA: btw, irregular reminder about the upload stuff ...
[06:47] <SteveA> thanks
[06:54] <SteveA> BradB: got a minute to chat?
[06:56] <BradB> SteveA: sure
[07:06] <SteveA> BradB: was going to ask your opinion on a horrid hack.  But it turns out there's no need for that.  There will be a new new ZWiki shortly that should fix the remaining i18n bugs
[07:07] <BradB> ok
[07:08] <Kinnison> Is everyone happy for me to update the launchpad checkout in /srv/launchpad.ubuntu.com on mawson?
[07:08] <daf> carlos: meeting time?
[07:08] <cprov> Kinnison: fine
[07:10] <debonzi> If one SourcePackage has no product/project, can I assume also that there is no translations for it?
[07:10] <carlos> daf: phone
[07:10] <BradB> SteveA: did you say there was going to be a meeting tomorrow morning, btw?
[07:10] <debonzi> s/there is/there are
[07:10] <BradB> i'm sure you did after the last one
[07:11] <SteveA> yeah.  there should be a meeting tomorrow.
[07:12] <BradB> there was no mail about it
[07:12] <SteveA> darn.  I didn't send the mail.
[07:16] <SteveA> debonzi, cprov: can you guys make a meeting tomorrow?
[07:16] <debonzi> SteveA, wich time is good for you?
[07:16] <SteveA> 13:00 UTC ?
[07:16] <Kinnison> If I hear no "please don't do that"s before 18:20 my time (5 minutes from now) I'll update the launchpad checkout
[07:16] <debonzi> SteveA, it is better to me after 16:00 UTC, but if its not ok for you Im ok with 13:00 UTC
[07:16] <SteveA> BradB: https://chinstrap.warthogs.hbd.com/~stevea/zwiki-2004-10-26c.tar.gz
[07:16] <carlos> daf: I'm ready
[07:16] <cprov> SteveA: of course, 13:00 UTC
[07:16] <SteveA> debonzi: any later is bad for stub
[07:16] <SteveA> daf, carlos: 1300 UTC meeting tomorrow?
[07:16] <debonzi> SteveA, ok its fine 13:00 UTC
[07:16] <SteveA> daf: how did the bug triage go?
[07:16] <SteveA> thanks debonzi
[07:16] <debonzi> SteveA, you are welcome
[07:16] <carlos> SteveA: it's ok for me
[07:17] <carlos> SteveA: I think we have about 5-7 bugs left to finish the review
[07:18] <SteveA> can you finish it before the meeting?  then you can give a report on the remaining rosetta bugs.
[07:22] <daf> you're proposing two meetings?
[07:22] <BradB> Kinnison: on mawson?
[07:22] <daf> one for bug triaging and one general one?
[07:22] <SteveA> daf: I'm asking you and carlos to finish the bug triaging
[07:22] <SteveA> and then to report from that to the all-launchpad meeting
[07:22] <daf> oh ok
[07:22] <daf> I was proposing a daily meeting for today
[07:22] <SteveA> great
[07:22] <daf> a Rosetta meeting
[07:22] <daf> carlos: #canonical-meeting?
[07:22] <carlos> daf: sure, let me make a call of 5 minutes
[07:22] <Kinnison> BradB: yes
[07:22] <Kinnison> BradB: doing it now 
[07:22] <Kinnison> BradB: unless you complain in the time it takes me to grab a drink; I'm suddenly very thirsty
[07:22] <BradB> nah, go for it
[07:22] <daf> carlos: ok
[07:23] <Kinnison> I go for it; I get 'archive not registered'
[07:23] <SteveA> BradB: zwiki update?
[07:23] <BradB> yeah, just did it :) updated and restarted.
[07:24] <BradB> Kinnison: you'll have to build-config on your machine dude
[07:24] <Kinnison> brad: sux2beme
[07:24] <SteveA> thanks
[07:24] <BradB> Kinnison: unless you feel like putting your private keys and such on mawson :)
[07:24] <Kinnison> BradB: y'know; naah
[07:24] <BradB> heh
[07:25] <SteveA> looks like the moin non-ascii issue is fixed
[07:25] <BradB> woo
[07:25] <SteveA> next, to try a full upload of pages again
[07:25] <BradB> SteveA: any more updates expected in the next little while? i have some hunting and gathering to do (i.e. lunch)
[07:25] <SteveA> to check there's no breakago
[07:25] <SteveA> BradB: hopefully not.
[07:26] <Kinnison> elmo: can we have bzip2 installed on mawson please?
[07:28] <elmo> done
[07:28] <dilys> New bug 2147 for Launchpad/Rosetta: We are not setting the iscomplete flag when a translation has all needed strings
[07:28] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2147
[07:29] <Kinnison> elmo: ta
[07:30] <debonzi> SteveA, If I want to use a rosetta view class in one soyuz page but the context is diferent is it right to use another view class (SourcePackageView) to give to it the right context?
[07:32] <SteveA> I don't quite understand
[07:32] <sabdfl> SteveA: so are we ready for the wikiwikibangbang?
[07:33] <debonzi> SteveA, ok by steps :)
[07:34] <debonzi> I want to have an instance of ViewProduct inside one soyuz page
[07:34] <SteveA> sabdfl: I'm doing a dry run now
[07:34] <sabdfl> ok, with rocketfuel later?
[07:34] <Kinnison> Okay, /srv/launchpad.ubuntu.com/ updated
[07:35] <debonzi> but IFAIK I cant set it in a zcml as I view class for my page because de context is diferent from the one that ViewProduct expect
[07:35] <debonzi> is it right to use another view class, that returns ViewProduct with the right context as an argument?
[07:37] <debonzi> SteveA, is it totally no sense?
[07:38] <SteveA> yep, fully fueled later
[07:38] <SteveA> I just added a few recently-created pages to the list
[07:39] <SteveA> debonzi: by "inside one soyuz page" do you mean like a URL: onepage/insidepage, or do you mean like a portlet -- an area inside that page ?
[07:40] <debonzi> SteveA, like a portlet
[07:42] <debonzi> SteveA, to have on the template something like "view/product" that is an ViewProduct instance
[07:44] <SteveA> well, view/product/+someview should work.  so, maybe try  <div tal:contents="structure view/product/@@+someview"> view portlet </div>
[07:46] <debonzi> SteveA, ok.. Ill check it. thanks
[07:48] <ddaa> spiv_: (or anybody awake) is it required to use .begin() before .commit() in ZopelessTransationManager, or does creating the the connection implicitly opens a transaction?
[07:49] <spiv_> The latter.
[07:52] <ddaa> thanks
[07:52] <spiv_> ddaa: I'm in Prague atm.
[07:52] <spiv_> bob2 keeps strange hours, though.
[07:53] <ddaa> (scratch eye and raise eyebrow) you are on vacation or something? As to bob2, he brags about living on a 30 hours cycle. Even if we keep telling him that is not healthy...
[07:54] <Kinnison> Would someone do the database initialisation for mawson please and then let me know when it's done
[07:55] <spiv_> I'm not on holiday, but my gf is, and I'm travelling with her.  If that makes sense.
[07:55] <ddaa> Definitely.
[07:55] <spiv_> So I haven't been home since I left for Oxford.
[07:55] <daf> debonzi: you assigned https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2139 to Rosetta -- do you need some help from us on this?
[07:55] <spiv_> And I probably won't be until after the Barcelona conf.
[07:56] <ddaa> Prague is a beautiful city. Have a beer at "Klub jezd" and think of me. I love this place.
[07:56] <ddaa> It's at the jezd tram station.
[07:56] <spiv_> Gar, something about screen and/or irssi ate the first char of that name.
[07:56] <daf> encoding problem, I think
[07:56] <ddaa> Sorry... my system is on latin1 still...
[07:57] <ddaa> It's \'Ujezd
[07:57] <spiv_> So it's looks like "<square>jzed" ;)
[07:57] <spiv_> Ah, ok.
[07:58] <ddaa> They have fantastic beer there, I'm no expert but I believe it's a kind of ale. When they serve it, it looks like _milk_ until the gas bubbles up.
[07:59] <spiv_> Ooh :)
[07:59] <spiv_> That doesn't look to hard to get to.  Just the other side of the river.
[07:59] <daf> zjed?
[08:00] <daf> er, jezd
[08:00] <ddaa> Prague is probably the city in the world where you have the greatest variety of beer by square kilometer.
[08:01] <ddaa> The natives are a bit weird, though...
[08:01] <ddaa> I believe that has something to do with some slavic depressive temper...
[08:02] <spiv_> That's ok, they seem to be outnumbered by the tourists ;)
[08:08] <debonzi> daf, maybe Ill need, but for while am ok.. thanks :)
[08:08] <daf> debonzi: ok, can I reassign it from Rosetta to Soyuz then?
[08:09] <debonzi> daf, yes.. no problem
[08:10] <daf> debonzi: great -- let me know if you have any questions
[08:11] <debonzi> thanks daf
[08:12] <daf> de nada
[08:24] <BradB> Kinnison: ping
[08:49] <sabdfl> hi guys
[08:57] <sabdfl> BradB: can i ask you to do another pull of code to dogfood?
[08:57] <sabdfl> in a minute once i've committed to rf?
[08:59] <BradB> sure...i was about to checkin fixes a couple more things too (both in about 10-15 mins, hopefully), but...
[09:01] <limi> sabdfl: I assume you saw my mail - I will be working on some simple Javascript code to enhance the Rosetta editing experience tonight - unless you have special tasks you want to get done by tomorrow.
[09:04] <dilys> New bug 2148 for Launchpad/Rosetta: We should add fuzzy strings as suggestions
[09:04] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2148
[09:29] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: fixed product infestation edit link (patch-699)
[09:39] <sabdfl> limi: sounds good
[09:43] <sabdfl> BradB: hope our respective patches don't conflict :-)
[09:45] <SteveA> BradB: how do you admin plone?  su to user zope ?
[09:45] <BradB> SteveA: yes
[09:45] <BradB> well, sudo -u zope -s
[09:45] <BradB> sabdfl: we'll find out nowish. ;)
[09:45] <SteveA> elmo: can I have rights to su to user zope on gentoo?
[09:47] <sabdfl> SteveA: thanks for the tags count on testing :-)
[09:47] <SteveA> going down?
[09:47] <sabdfl> no, just having the number now is nice
[09:47] <sabdfl> can hopefully watch it tend to zero
[09:48] <sabdfl> BradB: i think it will merge fine, i just refueld and got no patches so i must have got your when i refueled just before launching
[09:48] <SteveA> phew -- the latest test run of wiki conversion seems to have worked. simon and one of the docs guys are looking at it to check for problems.
[09:48] <sabdfl> when dilys says it's in, please could you update mawson?
[09:48] <sabdfl> i'd like to walk mdz through malone
[09:48] <BradB> sure
[09:49] <sabdfl> think it will be ready in about 30 mnutes?
[09:49] <BradB> sabdfl: can i get my last patch in there too? it's done, but i'm just waiting for tla changes
[09:49] <sabdfl> BradB: as you wish, but i have a deadline of having it up in 30
[09:50] <BradB> ok. i'm not sure if i can create and scp a tarball that quickly, but i'll try.
[09:50] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: commit cleanups for dogfood (patch-700)
[10:02] <BradB> sabdfl: I'd plan for it to be ready in an hour from now, if possible.
[10:03] <BradB> If you want to speed up the process, you doing a build-config and scp'ing up the tarball into your homedir may speed up the process by 15-20mins
[10:03] <BradB> (homedir on mawson, that is)
[10:07] <SteveA> BradB: got a few minutes?
[10:07] <BradB> sabdfl: n/m, i think it'll be okay now. i had to grab my dists folder from my old machine, but my build config has started.
[10:09] <BradB> SteveA: not at the moment, sorry
[10:09] <SteveA> k
[10:11] <BradB> SteveA: i'm bottlenecked by tla, so i do now. :)
[10:12] <limi> BradB: how is tla on the new 'book?
[10:13] <BradB> limi: still quite a bit slower than ext3 i'm sure, but certainly a major, major improvement over the other lappy with jaguar.
[10:13] <limi> yup
[10:13] <limi> but it's bearable now?
[10:13] <BradB> oh yeah, i'd say so.
[10:14] <BradB> in general, it's excellent. tla/arch is the one and only app where i go "oh. my. god."
[10:14] <limi> hehe
[10:15] <limi> even Plone is snappy ;)
[10:15] <limi> in debug mode
[10:16] <BradB> cool
[10:17] <BradB> sabdfl: i'm still waiting on the build-config. then gotta tar it up, then scp it up to mawson, then reset the db, then replace the source code, then restart. should be another half hour or so.
[10:17] <SteveA> BradB: cacheing.  stub said he had some patch for cookiecrumbler to make it send secure cookies
[10:18] <SteveA> can you apply this to the code for ubuntulinux.org's plone?
[10:18] <sabdfl> ok, i'm out of time
[10:20] <BradB> SteveA: sure, when i have the patch, i can apply it.
[10:20] <BradB> sabdfl: sorry, but i'll continue to work on getting it up on mawson as fast the software lets me.
[10:20] <SteveA> did you get stu's archive for the last cookie-crumbler stuff?
[10:21] <BradB> oh yeah, i was thinking that'd he'd be sending me an email with a patch in there, but yeah, i can check that archive.
[10:25] <SteveA> sabdfl: here's an update on the wiki conversions.
[10:26] <SteveA> one of the docs guys looked at it and seems reasonably happy.  there is some fixing up to do, but not too much.
[10:26] <sabdfl> ok
[10:26] <SteveA> simon michael has helped out a great deal.
[10:26] <sabdfl> is it ready for the big red button?
[10:26] <SteveA> he's just been changing the wiki folder for a different one that is more scalable (accepts more pages, without slowing down)
[10:26] <sabdfl> ok
[10:27] <SteveA> there have been no edits on wiki.ubuntu.com in a while
[10:27] <SteveA> unfortunately, thom and elmo aren't around to make it read-only
[10:28] <sabdfl> that's unusual
[10:28] <sabdfl> where are they?
[10:28] <SteveA> dunno.  I pinged them on irc.  both are away on jabber
[10:28] <sabdfl> ok
[10:28] <SteveA> kamion offered to sms thom
[10:28] <sabdfl> ok
[10:29] <sabdfl> is the ubuntu wiki on rince?
[10:29] <SteveA> but, I said maybe later -- let's see what the plam is first
[10:29] <sabdfl> ok
[10:29] <SteveA> I don't know where it is
[10:29] <sabdfl> ok
[10:29] <SteveA> I'm somewhat confused as to the situation with cacheing.  Did thom set things up so that ssl works for any page on ubuntulinux.org ?
[10:29] <sabdfl> if it has to roll to tomorrow, that's ok just get them to work with you on it first thing in the morning
[10:29] <sabdfl> i believe so
[10:30] <sabdfl> and that is uncached
[10:30] <elmo> I was eating dinner
[10:30] <SteveA> ok, so if brad can locate the patched cookiecrumbler from stu, we can have secure cookies
[10:30] <sabdfl> we need the "login" page not to redirect to http
[10:30] <sabdfl> we need the logout page to go to http
[10:30] <SteveA> I might be able to do that.  I'm a bit nervous of playing with plone, because I don't particularly know what I'm doing.
[10:30] <sabdfl> then with the cookiecrumbler we are ok
[10:31] <sabdfl> then let's not rush
[10:31] <SteveA> brad could do it reliably, I'm sure
[10:31] <sabdfl> i will be offline most of tomorrow, at frankfurt linuxworld, keynot
[10:31] <sabdfl> e
[10:31] <sabdfl> then i am off to sa to help the govt go open source and hopefully launch ubuntu to the sa media
[10:31] <sabdfl> also, dad's 60th
[10:32] <sabdfl> back monday 8th
[10:32] <SteveA> ok.  Interestingly, Jim Fulton was asking me a few questions about our experience with a distributed company.  I think zope corp are having trouble hiring good people who want to live in fredericksburg.
[10:32] <SteveA> got time for a quick call now?
[10:32] <sabdfl> that is interesting
[10:32] <sabdfl> stevea no i have a 5am start and a 45 minute speech to write :-)
[10:33] <SteveA> ok.  anything from you for the lp meeting tomorrow?
[10:33] <sabdfl> DOGFOOD!
[10:33] <SteveA> k
[10:33] <sabdfl> as soon as malone is up i'd like to say that new bugs should be filed there only
[10:33] <SteveA> I'll get the rosetta team started with i18n in launchpad
[10:36] <SteveA> elmo: Can I get "su to zope" privs on gentoo?
[10:37] <elmo> done
[10:38] <SteveA> elmo: also, I'd like to make the wiki.ubuntu.com moinmoin thing read-only tomorrow morning.  any idea what time you expect to be around?  or thom's usual getting up time?
[10:38] <SteveA> cheers
[10:40] <elmo> dunno, depends when I go to bed - if I'm not up and you need me, just ring me
[10:40] <elmo> err, do you know how to make moinmoin read only btw?
[10:40] <elmo> short of chattr +I :)
[10:40] <SteveA> I have no idea
[10:41] <elmo> I'm not sure wiki's have a 'read-only' switch, but I'll check the docs
[10:42] <SteveA> or, can we forbid logging in?
[10:42] <SteveA> did you get a new phone number?  or did you get the old one back?
[10:43] <elmo> old one back
[10:46] <BradB> SteveA: hm, i have no idea where stub's patch is.
[10:47] <BradB> i've looked through his archive, but nothing that i've seen appears to be a fix that secures cookies
[10:49] <SteveA> ok.  I'll send an email
[10:59] <BradB> elmo: did you have a chance to do what celso's requested for soyuz dogfooding?
[10:59] <elmo> BradB: err, no, where did he mail?
[10:59] <BradB> lp@
[10:59] <elmo> meh
[11:00] <sabdfl> https://launchpad.ubuntu.com/doap/projects/canonical
[11:01] <sabdfl> bradb, stevea, i've created sample products for malone, soyuz and rosetta for the dogfooding
[11:01] <sabdfl> so we can assign bugs to them
[11:01] <sabdfl> so bradb, no more blowing away that db
[11:02] <BradB> sabdfl: then we probably won't get a new version going today.
[11:02] <sabdfl> bugger
[11:03] <BradB> because i have no idea what the diff in the schema is between then and now + any needed data migration.
[11:03] <sabdfl> bradb ok blow it away
[11:03] <sabdfl> could you print out the project / product pages there and recapture those three?
[11:03] <sabdfl> shouldn't take 2 minutes
[11:04] <elmo> okay, locking down Moin is easy enough
[11:04] <BradB> sabdfl: sure
[11:08] <SteveA> elmo: ok, we'll do that tomorrow morning.
[11:12] <SteveA> BradB: what do you do to restart plone/zope ?
[11:13] <BradB> cd ~zope/instances/ubuntu; bin/zopectl restart
[11:14] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: added product infestation notification, normalized subject lines, and made sure that edit notifications only go out when something actually changed. (patch-701)
[11:14] <elmo> 'crontab -l' if you forget ;-)
[11:15] <BradB> heh heh...gragh, that sucks
[11:15] <SteveA> must get zeo going on there
[11:15] <SteveA> then, no need to restart the storage server so often
[11:15] <SteveA> and fast restarts of the client
[11:17] <BradB> ok, here we go, time to do some blowing away of data
[11:18] <SteveA> argh -- same dinner almost 6 nights running -- except going out for food one night
[11:19] <SteveA> I'm trying to use archism -- for example double-dashes -- in everyday sentences
[11:22] <BradB> sabdfl, SteveA: any objection if i make the dogfood db launchpad_dev for the moment? that appears to be the new default.
[11:22] <BradB> any other name takes longer and is more error prone
[11:23] <SteveA> that's the other name?
[11:23] <BradB> launchpad_test
[11:23] <BradB> which is arse too
[11:24] <SteveA> launchpad_dog?
[11:24] <BradB> does it matter yet though?
[11:24] <sabdfl> bradb: i'd rather the name was something distinct
[11:24] <BradB> hm
[11:24] <sabdfl> otherwise, a script ight just accidentally nail the wrong one.
[11:25] <BradB> ok, i'll name it launchpad_dogfood then, if there's no objections
[11:25] <sabdfl> perfect
[11:28] <BradB> shit
[11:28] <BradB> there's already a db with that name
[11:29] <BradB> daf: is that you?
[11:31] <BradB> sabdfl: is this the only dogfooding app on this machine, or are there other lp instances that i should care about not blowing up?
[11:33] <daf> BradB: yes
[11:33] <BradB> you're running off launchpad_dogfood, you mean?
[11:33] <daf> no
[11:33] <daf> sorry
[11:33] <daf> not me
[11:33] <sabdfl> bradb: yes, there is only one dogfood
[11:33] <sabdfl> the rosetta alpha will migrate to that in due course
[11:34] <sabdfl> night - thanks for the setup bradb. email all happy?
[11:34] <daf> sabdfl: the rosetta alpha code will not work with the current DB schema
[11:35] <sabdfl> in due course
[11:35] <sabdfl> migrate the po files
[11:35] <sabdfl> and the users
[11:35] <sabdfl> when you are ready
[11:38] <BradB> https://launchpad.ubuntu.com
[11:51] <ddaa> I'd like a launchpad Quake theme...
[11:51] <ddaa> With dreadful monsters.
[11:51] <ddaa> Made of gleaming metal.
[11:51] <ddaa> With flashing leds all over.
[11:52] <ddaa> Sparking electric blue.
[11:52] <ddaa> Which tend to duplicate.
[11:52] <ddaa> But have a probability to just freeze and stand still, helpless.
[11:53] <ddaa> BUILDBOTS!!!
[11:53] <ddaa> Rocket launcher might come in handy...
[11:58] <BradB> https://launchpad.ubuntu.com/doap/projects/canonical # purina puppy chow
[11:59] <ddaa> BradB: 403
[12:00] <BradB> ddaa: you need to install the client cert
[12:00] <BradB> as seen on lp@
[12:00] <ddaa> keyword?
[12:00] <BradB> launchpad.p12