[12:01] <daf> I'm talking about global notifications
[12:02] <daf> i.e. no global notification will get sent for new bugs that don't have owners
[12:03] <BradB> as i say, all bugs do have owners currently
[12:03] <BradB> in any case, there's no point thinking much about this, it's a bug of a sort (e.g. that it shouldn't be special-cased) and i'm fixing it with my next checkin.
[12:04] <daf> ok :)
[12:04] <daf> next question:
[12:05] <daf> notify_bug_added seems to get called with a MaloneBugAddForm rather than a bug as the first parameter
[12:05] <BradB> yep
[12:06] <daf> so how do I get the bug itself?
[12:06] <BradB> hence all that context.context.bug crap
[12:06] <BradB> ("crap" i.e. in several places in the codebase)
[12:07] <daf> does the bug exist when the notification is called?
[12:07] <BradB> yes
[12:07] <daf> is there some way of getting hold of it?
[12:08] <daf> MaloneBugAddForm has no attribute 'id', y'see
[12:08] <BradB> at worst, you can do event.object
[12:08] <daf> that doesn't sound too bad
[12:09] <BradB> the first param'll have to be renamed to describe whatever it is
[12:09] <daf> why does the notification get the form rather than the object itself?
[12:09] <daf> (Pdb) event.object
[12:09] <daf> <canonical.launchpad.database.bug.MaloneBugAddForm object at 0xb37e020c>
[12:09] <spiv> carlos: I suspect it's not needed, but I'm not usre.
[12:10] <spiv> sure, rather.
[12:10] <carlos> spiv: also, I'm having problems with a test class with two tests, the second one gives me an error because the connection is already closed
[12:11] <carlos> spiv: the tests seems to be working (after commenting the commits, so seems like they are not needed, but I will activate the postgres debug info to be sure)
[12:12] <BradB> daf: dunno.
[12:12] <BradB> you'd have to debug AddView to get the exact answer
[12:13] <daf> scary
[12:13] <daf> perhaps I should leave the new bug notifications unchanged for now, then
[12:13] <BradB> :)
[12:13] <BradB> i can do it. possibly tonight.
[12:14] <daf> where does AddView live?
[12:15] <BradB> M-.
[12:15] <BradB> AddView<RET>
[12:15] <BradB> :P
[12:15] <daf> I'm not familiar with all this notification stuff
[12:15] <BradB> zope.app.form.browser.add
[12:15] <daf> oh, you mean :tag AddView<RET> :)
[12:15] <BradB> heh
[12:17] <daf> hmm, the relevant line seems to be: notify(ObjectCreatedEvent(content))
[12:17] <BradB> yep
[12:17] <BradB> events are dead simple, to be honest
[12:20] <BradB> looks like it's the fault of the custom factory someone wrote
[12:20] <BradB> BugContainer.add
[12:21] <BradB> last line is "return ob", but i think "return bug" would behave more sanely
[12:21] <daf> groovy, shall I change it?
[12:21] <BradB> you can see if it works. there's a chance all hell'll break loose too (but i'm kind of doubting that :P)
[12:22] <daf> hmmmm
[12:22] <daf>         return ob # Return this rather than the bug we created from it,
[12:22] <daf>                   # as the return value must be adaptable to the interface
[12:22] <daf>                   # used to generate the form.
[12:22] <daf> that doesn't mean much to me
[12:22] <BradB> eh, a bug should be adaptable to that interface, since the generated form is *for* a bug.
[12:23] <daf> yeah, that would make sense
[12:24] <daf> hmm, that didn't seem to change anything
[12:26] <daf> where's the view for creating a bug kept?
[12:27] <BradB> it would be that MaloneBugAddForm
[12:27] <daf> interesting
[12:27] <daf> the tal calls view/update
[12:28] <BradB> that's canonical
[12:28] <daf> which MaloneBugAddForm doesn't appear to have
[12:28] <daf> it's mixed in from somewhere?
[12:28] <BradB> no, but AddView does
[12:29] <BradB> hm, the ZCML says this addform is for schema="canonical.launchpad.interfaces.IMaloneBugAddForm", which I find bizarre
[12:30] <daf> why's that?
[12:30] <BradB> I would have thought it'd be for schema IBug :)
[12:32] <BradB> if instead it were for IBug, you'd be getting an IBug surely (for the params)
[12:32] <daf> I'll try that
[12:32] <BradB> and return bug would be The Right Thing
[12:33] <daf> hmm, expolosion
[12:34] <daf> zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/home/daf/src/canonical/dists/launchpad/site.zcml", line 5.4-5.35
[12:34] <daf>     ZopeXMLConfigurationError: File "/home/daf/src/canonical/dists/launchpad/lib/canonical/configure.zcml", line 78.4-78.45
[12:34] <daf>     ZopeXMLConfigurationError: File "/home/daf/src/canonical/dists/launchpad/lib/canonical/launchpad/configure.zcml", line 4.2-4.48
[12:34] <daf>     ZopeXMLConfigurationError: File "/home/daf/src/canonical/dists/launchpad/lib/canonical/launchpad/zcml/configure.zcml", line 18.4-18.31
[12:34] <daf>     ZopeXMLConfigurationError: File "/home/daf/src/canonical/dists/launchpad/lib/canonical/launchpad/zcml/bug.zcml", line 118.4
[12:34] <daf>     ValueError: ('Field name is not in schema', u'sourcepackage', <InterfaceClass canonical.launchpad.interfaces.bug.IBug>)
[12:38] <BradB> ah yeah, now i know why they did that
[12:38] <BradB> because there's stuff on the add form that isn't part of IBug (e.g. package and product assignments)
[12:45] <daf> right
[12:46] <daf> it wouldn't be a problem if you could get the bug from the view class, but it doesn't seem possible
[12:48] <carlos> spiv: ping
[12:48] <spiv> pong
[12:50] <carlos> spiv: seems like the current functional test status does not let you execute two tests inside the same class
[12:51] <carlos> a class with two tests fails because the second one tries to drop the database but it's already open 
[12:51] <spiv> That's bizarre.
[12:51] <carlos> then the tests fails
[12:51] <spiv> setUp and tearDown are supposed to be run for each test method.
[12:51] <daf> BradB: any ideas, or shall I just leave it for now?
[12:52] <spiv> You've tried running the second one alone (e.g. by commenting out the first)?
[12:52] <carlos> no, let me try it
[12:52] <carlos> it will take sometime...
[12:53] <carlos> spiv: it's running and it was able to drop and recreate the database
[12:54] <carlos> hmm, wait, I think I got the problem..
[12:54] <carlos>  def tearDown(self):
[12:54] <carlos>         super(LaunchpadFunctionalTestCase, self).tearDown()
[12:54] <carlos>         FunctionalTestSetup().tearDown()
[12:55] <carlos> Should I call the super method after the FunctionalTestSetup()tearDown()?
[12:58] <carlos> daf: should we talk about the rosetta alpha move to the dogfood server?
[01:06] <BradB> daf: i'd say leave it for now. if you tla undo i'll look at it, but more likely tomorrow.
[01:07] <carlos> spiv: no that's not the problem, same error
[01:08] <elmo> is there some way to get screen width in python without resorting to ncurses?
[01:08] <elmo> num of chars I mean by width, not pixels or anything
[01:08] <carlos> the postgres log shows lots of messages like: 
[01:08] <carlos> 2004-11-10 01:04:27 [9019]  LOG:  statement: BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
[01:08] <carlos> 2004-11-10 01:04:27 [9019]  LOG:  statement: ABORT TRANSACTION
[01:08] <carlos> 2004-11-10 01:04:27 [9019]  LOG:  statement: DROP DATABASE launchpad_ftest
[01:08] <carlos> 2004-11-10 01:04:27 [9019]  ERROR:  database "launchpad_ftest" is being accessed
[01:08] <carlos> by other users
[01:08] <carlos> 2004-11-10 01:04:27 [9019]  LOG:  statement: ABORT
[01:08] <carlos> 2004-11-10 01:04:27 [9019]  WARNING:  there is no transaction in progress
[01:08] <daf> BradB: I'll leave new bugs using simple_sendmail now, and finish off the others tonight, I think
[01:08] <carlos> and the second test fails with this trace:
[01:09] <carlos> Traceback (most recent call last):
[01:09] <carlos>   File "./lib/canonical/rosetta/ftests/test_poimport.py", line 28, in testTemplateImporter
[01:09] <carlos>     project = Project.selectBy(name = 'gnome')[0] 
[01:09] <carlos>   File "/home/carlos/Work/dists/launchpad/lib/sqlobject/main.py", line 1238, in __getitem__
[01:09] <carlos>     return list(self.clone(start=start, end=start+1))[0] 
[01:09] <carlos>   File "/home/carlos/Work/dists/launchpad/lib/sqlobject/main.py", line 1242, in __iter__
[01:09] <carlos>     return conn.iterSelect(self)
[01:09] <carlos>   File "/home/carlos/Work/dists/launchpad/lib/sqlobject/dbconnection.py", line 516, in iterSelect
[01:09] <carlos>     select, keepConnection=True)))
[01:09] <carlos>   File "/home/carlos/Work/dists/launchpad/lib/sqlobject/dbconnection.py", line 444, in __init__
[01:09] <daf> elmo: $COLUMNS?
[01:09] <carlos>     self.cursor = rawconn.cursor()
[01:09] <carlos>   File "/home/carlos/Work/dists/launchpad/sourcecode/zope/src/zope/app/rdb/__init__.py", line 308, in cursor
[01:09] <carlos>     return ZopeCursor(self.conn.cursor(), self)
[01:09] <carlos> InterfaceError: already closed
[01:11] <elmo> daf: hmm, I remembered that but env(1) didn't show it.. I guess it's a shell variable
[01:11] <elmo> anyway, thanks
[01:11] <daf> yeah, I'm not sure what sets it
[01:12] <daf> probably the shell
[01:12] <elmo> yeah, and it doesn't work in any spawned process, like python, :(
[01:13] <elmo> >>> os.getenv("COLUMNS")
[01:13] <elmo> >>> 
[01:13] <daf> suck
[01:19] <spiv> carlos: Hmm :/
[01:20] <spiv> carlos: So I guess that means the other test isn't related (which is good)
[01:21] <carlos> hmmm
[01:22] <carlos> spiv: that error is from the first test :-O
[01:22] <carlos> but it makes no sense 
[01:22] <carlos> the line where it fails is the start of the test
[01:23] <carlos> and it executes lots of queries...
[01:23] <carlos> is it possible that they are executed in reversed order?
[01:24] <carlos> hmm, that sucks, that functional test is not working as it should
[01:24] <spiv> They're executed in an arbitrary order.
[01:25] <carlos> but that's not a justification for the error
[01:25] <spiv> Most likely dependent on the order they pop out of the dict of the test case.
[01:25] <carlos> I mean, the functional test is not running as it was wrote, but it should not fail
[01:26] <carlos> so I will care about it later, when the error is gone (the first should be executed first)
[01:26] <spiv> Sorry, you mean the tests depend on being run in a certain order?
[01:28] <carlos> spiv: that was the way it was designed, yes. Don't ask :-), those tests suck and needs  lot of love
[01:28] <spiv> Ok :)
[01:28] <carlos> one imports a file into the database (a .pot file) and the second one imports another file (a po file) related to the first
[01:29] <carlos> with the current test database the functional tests have changed the objective of this functional test
[01:30] <carlos> spiv: if you can tell me for sure that multiple functional tests should work, I could disable those test for now and write new ones that really work
[01:30] <carlos> and forget this error
[01:31] <spiv> Well, they *should* work, yeah :)
[01:31] <carlos> ok, I believe you :-)
[01:31] <carlos> I will "poke" you if the problem appears again :-P
[01:31] <spiv> And, I think they even do work ;)
[01:32] <spiv> A quick grep shows other places run them too.
[01:32] <spiv> (canonical.mail, canonical.lp.placelessauth, canonical.ftests.test_sqlos)
[01:33] <carlos> perhaps the problem is with LaunchpadFunctionalTestCase
[01:33] <carlos> I didn't found a functional tests that uses it
[01:34] <carlos> I will review tomorrow If I really need the Utilities and Adapters from Zope or I could move to LaunchpadTestCase
[01:34] <spiv> A grep finds a couple of places that use it for me...
[01:35] <spiv> (as mentioned above)
[01:35] <carlos> hmm
[01:35] <BradB> daf: ok (re: doing id's for all but bug adding)
[01:35] <carlos> spiv: could you point me to a concrete file, please?
[01:35] <spiv> "grep -Irn class.*LaunchpadFunc"
[01:36] <carlos> ok
[01:36] <spiv> lib/canonical/ftests/test_sqlos.py
[01:36] <stub> LaunchpadFunctionalTestCase was going to be first used in the page test stuff, but I found it wasn't needed - so it may be broken.
[01:36] <BradB> tags? :)
[01:36] <spiv> lib/canonical/lp/placelessauth/ftests/test_launchpadloginsource.py
[01:36] <spiv> :)
[01:36] <spiv> BradB: Ok, so my full command line is actually "grep -Irn class.*LaunchpadFunc . | grep -v tags:" :P
[01:37] <BradB> heh
[01:37] <stub> test_sqlos is a decoy, currently disabled
[01:38] <carlos> spiv: then I don't have an example that works :-)
[01:38] <stub> and test_launchpadlogingsource is doing its own provideUtility so might work just as well wth LaunchpadTestCase
[01:38] <carlos> spiv: the test_launchpadloginsource.py only have a test inside the class
[01:39] <carlos> stub: I'm having problems with LaunchpadFunctionalTestCase and a class with more than a test
[01:39] <carlos> the second one fails
[01:39] <daf> carlos: I'll write an email to the mailing list tonight
[01:39] <carlos> daf: ok
[01:40] <stub> carlos: That is not surprising - LaunchpadFunctionalTestCase does not appear to be calling its superclass' setUp and tearDown methods :-P
[01:40] <carlos> stub: I fixed it already
[01:40] <carlos> it's in my local archive
[01:41] <carlos> will merge it tonight :-)
[02:35] <carlos> grr
[02:35] <carlos> spiv: I'm not able to commit my changes
[02:35] <carlos> Ran 57 tests in 74.651s
[02:35] <carlos> FAILED (errors=1)
[02:35] <carlos> Exception psycopg.InterfaceError: 'already closed' in <bound method Transaction.__del__ of <sqlobject.dbconnection.Transaction object at 0x41c8c6cc>> ignored
[02:35] <carlos> ---- end test stderr ----
[02:35] <carlos> make: *** [check]  Error 1
[02:35] <carlos> pqm rejects them because that
[02:52] <stub> carlos: I didn't think make check was looking at stderr to see if things succeeded or failed? That bug needs to be fixed upstream, and I thought existing tests were already triggering it
[02:54] <carlos> stub: seems like I'm getting an error in any tests but I'm not sure about which one is it:
[02:54] <carlos>   File "/home/pqm/arch/queue/workdir/rocketfuel@canonical.com/rocketfuel@canonical.com---launchpad--devel--0/launchpad/lib/zope/app/rdb/__init__.py", line 308, in cursor
[02:54] <carlos>     return ZopeCursor(self.conn.cursor(), self)
[02:54] <carlos> InterfaceError: already closed
[02:54] <carlos> it's not too much descriptive
[02:55] <stub> ok. I think that was the area I tried fixing and I thought BradB had finally nailed ;-(
[02:57] <carlos> I know the functional test I'm chaning are broken, but they were already broken before any change from my part, so I don't understand why the system is complaning now about it
[02:58] <carlos>  /s/chaning/changing/
[02:58] <stub> You might be able to get better output running 'python test.py canonical' instead of 'make check'
[02:59] <stub> fwiw, you might find the test runs happily standalone (python test.py test_powhatever), but fails if run in a batch. If this is the case, it is a bug in the setup/teardown stuff because a previous test is leaving the system in a bad state.
[03:01] <carlos> ok, I will look at it tomorrow then, 3:00AM is too late to deal with them 
[03:01] <carlos> thanks
[03:01] <carlos> and night!!
[03:09] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: added bug submitter to Cc list when new bug is added (patch-754)
[06:44] <stub> sabdfl: Do teams have karma?
[07:06] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Database updates (patch-755)
[09:37] <sabdfl> stub: hmm.... good question
[09:37] <sabdfl> nothing in the data model to prevent that
[09:37] <sabdfl> but since teams can't log in, i guess we want to collect karma around the individual
[09:37] <sabdfl> lifeless: around?
[10:37] <Kinnison> Morning
[10:41] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Make subject lines in Malone notification emails contain bug IDs (patch-756)
[12:01] <Kinnison> Morning cprov
[12:03] <cprov> Kinnison: morning 
[12:10] <Kinnison> so we have nice up-to-date dogfood for today
[12:13] <Kinnison> gina running...
[12:16] <cprov> Kinnison: great !
[12:38] <Kinnison> Meeting is in 55 minutes yes?
[12:38] <SteveA> yes
[12:38] <Kinnison> cool
[12:41] <stub> Dogfood was updated yesterday. Do another drop now?
[12:41] <Kinnison> codebase drop?
[12:42] <Kinnison> can it wait until gina has finished running?
[12:42] <stub> Sure
[12:42] <Kinnison> otherwise you'll be stuck unable to frobble the db or the librarian codebase :-)
[12:42] <Kinnison> spiv: ping?
[12:43] <Kinnison> spiv: this is why I thought we were multithreaded:
[12:43] <Kinnison> 2004/11/10 11:02 GMT [FileUploadProtocol,0,127.0.0.1]  Enabling Multithreading.
[12:44] <sabdfl> stub: i'm seeing odd test failures where the "bounty" table cannot be found
[12:44] <sabdfl> but it seems very much integrated in patch 4-05
[12:44] <sabdfl> any idea what i'm doing wrong?
[12:45] <stub> have you restarted launchpad after applying the patch?
[12:45] <sabdfl> i'm just running make in database/schema
[12:45] <sabdfl> then running make check at the top level
[12:45] <stub> that should be fine... hmm...
[12:47] <sabdfl> launchpad_dev=# select * from launchpaddatabaserevision;
[12:47] <sabdfl>  major | minor | patch
[12:47] <sabdfl> -------+-------+-------
[12:47] <sabdfl>      4 |     5 |     0
[12:47] <sabdfl> (1 row)
[12:47] <stub> Urgh... bad patch. Made two mistakes! (with the first masking the second!)
[12:47] <sabdfl> ok
[01:01] <spiv> Kinnison: Hmm.
[01:03] <Kinnison> cprov: gina is up to openoffice
[01:04] <spiv> Kinnison: storing files is properly threaded, 
[01:05] <Kinnison> spiv: including writing to the db?
[01:05] <spiv> Well, only writing to the db :)
[01:05] <spiv> The writing to a temp file isn't threaded, because it doesn't need to be.
[01:05] <Kinnison> So if upload is threaded; why would it be hard to thread download?
[01:06] <spiv> It's not hard.
[01:06] <Kinnison> aah
[01:06] <elmo> is there a more idiomatic way to split the last work off a string than: ' '.join(s.split()[:-1] )
[01:06] <Kinnison> I got the impression you had decided it was
[01:06] <spiv> It just a Simple Matter Of Programming :)
[01:06] <elmo> +?
[01:06] <spiv> Well, it's annoying more than anything else.
[01:06] <elmo> s/work/word/
[01:07] <SteveA> elmo: no
[01:07] <cprov> Kinnison: fine, I'm trying to set a small librarian upload_client locally, librarian starts ok, but when I try to upload some file I get: canonical.librarian.client.UploadFailed: Server said: 500 Internal server error, any idea ?  do I need to create the DB entires for sourcepackagereleasefile by hand ?
[01:08] <spiv> cprov: Look in the log file.
[01:08] <spiv> (For the server)
[01:08] <Kinnison> cprov: yeah; the log file should contain a traceback
[01:08] <Kinnison> cprov: you most likely haven't given it a dir to write the files into
[01:08] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix bad database patch (patch-757)
[01:09] <SteveA> elmo: you could make it very explicit, like this:
[01:09] <SteveA> >>> s = "foo bar baz"
[01:09] <SteveA> >>> words = s.split()
[01:09] <SteveA> >>> words.pop()
[01:09] <SteveA> 'baz'
[01:09] <SteveA> >>> s = ' '.join(words)
[01:09] <SteveA> >>> s
[01:09] <SteveA> 'foo bar'
[01:09] <SteveA> >>>
[01:10] <cprov> spiv: yep, sqlobject/dbconnect.py lineline 507, in iterSelect | select, keepConnection=True)) | exceptions.TypeError: iteration over non-sequence
[01:10] <ddaa> SteveA: is there a particular policy that all "make check" test should be run with a PYTHONPATH which include launchpad/lib?
[01:10] <elmo> SteveA: hmm, ok, thanks
[01:10] <SteveA> ddaa: the stuff that I have added to make check arranges its own sys.path
[01:10] <ddaa> SteveA: that is forcing an annoyingly trivial delta between the canonical and public versions of PyArch, which does not depend on anything else in launchpad.
[01:10] <SteveA> in general, stuff that you run as a script, or that is invoked directly by a makefile, can set sys.path properly
[01:11] <SteveA> what exactly is forcing the difference?
[01:11] <spiv> cprov: Do you have the latest SQLObject? (rocketfuel@canonical.com/sqlobject--test--0.6--patch-4)
[01:11] <ddaa> -PYTHONPATH=$(PWD)/../../lib:$(PWD)
[01:11] <ddaa> +PYTHONPATH=$(PWD)
[01:11] <ddaa> That's the delta between Canonical and public.
[01:11] <ddaa> I am not too sure why I added in the first place, but there might have been a good reaon.
[01:12] <SteveA> ddaa: running make check from the 'launchpad' directory does not need a special pythonpath to be set
[01:12] <cprov> spiv: I must verify, maybe not, just a minute
[01:12] <ddaa> SteveA: actually, that's to run make check from the sourcecode/pyarch directory
[01:12] <spiv> cprov: Otherwise, I'll need to see more of the traceback...
[01:12] <ddaa> But that's needless, since it does not depend on anything there...
[01:13] <ddaa> Just want to be sure removing that would not break some policy.
[01:13] <SteveA> I don't see why we should be using a separate version of pyarch, seeing as it lives in launchpad/sourcecode/
[01:13] <stub> 'make check' shouldn't need python path manipulation being done, because I hacked test.py  to add lib into the path
[01:19] <dilys> Merge to rocketfuel@canonical.com/pyarch--devel--0.5: merge test suite refactoring (still incomplete) (patch-52)
[01:20] <SteveA> hi carlos
[01:20] <carlos> hi
[01:20] <SteveA> carlos: there is still a stub.{py,zcml} in rosetta
[01:20] <SteveA> and comments refering to sql in configure.zcml
[01:21] <carlos> should stub.* files be removed?
[01:21] <cprov> spiv: my tree (sourcecode/sqlobject) is up to date, please look in http://jeffsblog.info/pastebin/pastebin.php?show=240
[01:21] <SteveA> and various obselete crap in the Makefile
[01:21] <SteveA> absolutely
[01:21] <carlos> I think daf wanted to preserve them (not sure if it's still valid after the big movement of files...)
[01:21] <SteveA> let's get rid of them
[01:21] <carlos> ok
[01:22] <SteveA> if stuff isn't being used, we should remove it
[01:22] <SteveA> if stuff isn't being tested, we should write tests for it, or remove it.
[01:22] <SteveA> it will always be available in the archive's history
[01:22] <Kinnison> elmo: can you refresh the archive on mawson?
[01:23] <Kinnison> elmo: I think you caught it mid-xorg upload
[01:23] <SteveA> it is important to have clean code, clean source directories, and up to date comments
[01:23] <carlos> ok
[01:23] <Kinnison> IOError: [Errno 2]  No such file or directory: '/srv/archive.ubuntu.com/ubuntu//pool/main/x/xorg/xfree86-common_6.8.1-1ubuntu1_all.deb'
[01:23] <SteveA> did you and daf look at the i18n information I sent to you before I went on vacation?
[01:23] <spiv> cprov: Hmm, there's something funny going on.
[01:24] <carlos> SteveA: daf was looking on it, not sure its current status at this moment
[01:24] <cprov> spiv: what :)
[01:24] <elmo> Kinnison: nah, the archive probably was actually like that
[01:24] <spiv> cprov: line 507 of lib/sqlobject/dbconnection.py seems to wrong.  Are you *sure* it's up to date? :)
[01:24] <elmo> but i'll update it anyway
[01:25] <Kinnison> elmo: thanks dude.
[01:25] <SteveA> carlos: we need to move along with this.  rosetta needs to lead the way in being internationalized
[01:25] <SteveA> then, we'll be able to dogfood on rosetta as well as alpha testing it with a few volunteers
[01:26] <cprov> spiv: not sure, tla update in sourcecode/sqlobject says that
[01:26] <spiv> cprov: What's the tree-version?
[01:27] <cprov> rocketfuel@canonical.com/sqlobject--test--0.5.1
[01:27] <spiv> That's not up to date?
[01:27] <spiv> I mean,
[01:27] <spiv> That's not up to date :)
[01:27] <carlos> SteveA: hmm, something is going really bad in the alpha server
[01:27] <spiv> We're using --0.6 now.
[01:27] <carlos> I get system error with every url I try to visit
[01:27] <cprov> spiv: ehe, so can you drive me to update it ...
[01:28] <spiv> cprov: Do you have baz installed?
[01:28] <cprov> spiv: no yet
[01:29] <spiv> cprov: If so, you should just be able to run "baz switch rocketfuel@canonical.com/sqlobject--test--0.6" in sourcecode/sqlobject
[01:29] <spiv> cprov: I recommend it :)
[01:29] <spiv> "baz diff" is much easier to type than "tla changes --diffs" :)
[01:30] <SteveA> is baz in hoary?
[01:30] <carlos> SteveA: not yet (or I don't see it)
[01:30] <cprov> spiv: ok, I will install it, then do "switch" to --0.6 ... just some minutes :)
[01:31] <SteveA> meeting time folks!
[01:31] <spiv> SteveA: I use deb http://bazaar.canonical.com/packages/debs ./
[01:32] <SteveA> all not present say "nay!"
[01:32] <carlos> nay!
[01:32] <spiv> n-- oh. :)
[01:32] <SteveA> I can see you here, carlos
[01:32] <SteveA> ok, all present, please say something
[01:32] <carlos> X-)
[01:32] <carlos> I didn't saw the "not" :-P
[01:33] <spiv> Damn trick questions :)
[01:33] <BradB> meep
[01:33] <cprov> here
[01:33] <cprov> spiv: we can talk briefly about the sqlobject update after meeting, ok ?
[01:33] <SteveA> stub: ?
[01:33] <SteveA> daf: ?
[01:33] <SteveA> sabdfl: ?
[01:33] <sabdfl> im here
[01:34] <spiv> cprov: Sure.
[01:34] <stub> Greetings
[01:34] <SteveA> let's get started
[01:35] <SteveA> item 1: UI widgets that cope with people and projects etc.
[01:36] <SteveA> what should we do about this?
[01:36] <SteveA> there are a couple of different options.
[01:36] <sabdfl> this is now critical to get malone usable
[01:36] <sabdfl> bradb, would you agree?
[01:36] <BradB> yes
[01:36] <sabdfl> we have a couple of options
[01:37] <sabdfl> on the people front, we could use a well-sorted dropdown listbox that only lists people with passwords
[01:37] <sabdfl> so you could only assign a bug to someone with a password in the system
[01:37] <sabdfl> that would reduce the list dramatically
[01:37] <sabdfl> and make a dropdown sufficient
[01:37] <SteveA> this will still be an interim measure, as we expect to grow a lot
[01:38] <sabdfl> can anyone think of cases where such a measure would fail us?
[01:38] <sabdfl> for example, where you want to assign a bug to someone who is NOT a canonical user?
[01:38] <BradB> yeah
[01:38] <stub> Product bug assignments will get assigned to the developers
[01:39] <stub> I think we need to cope with thousands of options, just like the other problem widgets
[01:39] <SteveA> isn't it a bit rude to assign someone a bug when they can't log into the system?
[01:40] <BradB> SteveA: it's a bit practical
[01:40] <BradB> it doesn't seem out of the realm of possibility to me
[01:40] <carlos> SteveA: but they will be able to log into it if they activate their account, right?
[01:40] <sabdfl> stub: sure, we need t be able to handle the full case, i'm just trying to find a way to get malone usable by the warty team asap
[01:41] <sabdfl> hoary team, really
[01:41] <sabdfl> for packages and products, i don't thnk a straight dd-listbox would be workable
[01:42] <SteveA> what are our options?  1. reduce the number of people we need to select from (as an interim measure)  2. use a cached javascript datastructure (slightly longer term interim measure)  3. fancy javascript HTTP stuff to dynamically search people on a single page
[01:42] <stub> sabdfl: Short term the dropdown should be fine then.
[01:42] <sabdfl> for people, yes
[01:43] <SteveA> 4. type in thing like in bugzilla
[01:43] <carlos> I like the current Bugzilla solution
[01:43] <Kinnison> is that not a cached javascript thing?
[01:44] <sabdfl> stevea: limi did some tests on the current bugzilla code
[01:44] <sabdfl> it doesn't scale beyond about 2,000 items
[01:44] <BradB> sabdfl: surely it can be made to be though.
[01:44] <sabdfl> it also does not really allow you to search for anything other than a flat namespace
[01:44] <sabdfl> BradB: not easily
[01:44] <sabdfl> you end up downloading a huge page (which takes time) and then get---a---very-----jerky-----typing----experience
[01:45] !lilo:*! Hi all.  Reminder, if you're in the US and you want to attend the second day of the FTC's email authentication summit by phone, it begins in about 45 minutes, and the conference info is here: http://www.ftc.gov/bcp/workshops/e-authentication/ .... thanks!
[01:45] <carlos> I'm talking about the entry that is submitted and then in a new form shows you the people that match that name, not the product thing
[01:45] <BradB> depending on the definition of "not easily" a good combo box is definitely something that would be music to users' ears
[01:45] <sabdfl> i would really like to have something slick using lucene client side, but we dont have the skills inhouse to tackle that
[01:45] <kiko> carlos, that's user matching, and it works in a quite ingenious fashion.
[01:45] <elmo> [it doesn't scale as it is now - reporting a bug is painful - it loads > 500kb of crap just so you can enter the component field] 
[01:46] <stub> 4. Use popup search dialogs
[01:46] !lilo:*! And please feel free to join us on ##ftc-summit (please note the two #'s).... thanks!
[01:46] <stub> c/4/5
[01:46] <SteveA> I think for the people field, we've agreed that limiting people to those who can log in is sufficient for right now.
[01:46] <sabdfl> limi's recommendation was to do an xmlrpc query in javascript
[01:47] <sabdfl> SteveA: agreed
[01:47] <spiv> carlos: Yes, I like that too.
[01:47] <sabdfl> who knows JavaScript around here?
[01:47] <SteveA> (technical issue: easier to do an HTTP GET, better for authentication and sessions, requires less javascript, and achieves the same end.)
[01:48] <sabdfl> spiv, carlos, where can i see the bugzilla example?
[01:48] <spiv> carlos: Although it's not very discoverable :/
[01:48] <SteveA> I know a bit.  It is a bit rusty, but I've done this kind of dynamic stuff before.
[01:48] <sabdfl> stevea: so the JS does an HTTP GET or POST, to a known URL?
[01:48] <carlos> sabdfl: add someone to the CC field of any bug
[01:48] <SteveA> the bugger is always in the cross-browser testing
[01:49] <spiv> sabdfl: Add "Daniel" as an assignment or CC, it should then prompt on the next page.
[01:49] <carlos> sabdfl: and type just "Mark" 
[01:49] <carlos> sabdfl: it will give you a list of users with that name
[01:49] <spiv> (Or any ambiguous name.  If there's only one match, it'll pick it automatically though)
[01:49] <SteveA> sabdfl: yes, that's right.  and it returns something the js can handle.  either an xml doc, or some text, or some js. 
[01:49] <SteveA> the known url might be relative to the current one, for example.
[01:50] <sabdfl> this sounds quite manageable
[01:50] <sabdfl> need to design the query interface
[01:50] <sabdfl> and the response data structure
[01:50] <sabdfl> and then make it look relatively good
[01:51] <sabdfl> would xml be the best structured data format for JS to parse?
[01:51] <kiko> not really.
[01:51] <kiko> the best structured data format would be, well, a JS array.
[01:51] <sabdfl> what would you recommend, kiko?
[01:52] <sabdfl> ok, so we can send back an actual JS datastructure?
[01:52] <SteveA> depends.  if it is just a list of names, or names and email addresses, then some js or space delimited text is best
[01:52] <kiko> sure, we could just return a .js file and eval it.
[01:52] <sabdfl> for people, would be browsername, name and email addresses
[01:53] <sabdfl> eval... is that how you would return a JS array?
[01:53] <SteveA> that's how you get returned JS from the server incorporated into the JS runtime of the page
[01:53] <SteveA> so that you can use it in the page
[01:53] <sabdfl> ok
[01:53] <SteveA> then you need to do some DOM stuff to make the UI display change
[01:54] <sabdfl> right
[01:54] <Kinnison> I take it that we're not able to wait for hoaryconf for implementing this? Otherwise I'd offer to bring my javascript and dhtml references to the conference
[01:54] <sabdfl> so, should we divide this problem up between us, or assign it all to one person
[01:54] <SteveA> it is pretty straightforward, so long as you don't try to do asynchronous stuff
[01:55] <sabdfl> this is something we really need asap
[01:56] <sabdfl> SteveA: how do you want to organise this to get it done
[01:57] <SteveA> let's make a one-page prototype of it, to prove the concept in launchpad
[01:57] <sabdfl> ok
[01:57] <SteveA> if no-one else feels particularly attracted to the task, I'll take it on.  Volunteers who know some javascript welcome, though.
[01:58] <sabdfl> ok
[01:58] <sabdfl> bradb, can you make the "person" dropdown limit itself to people with passwords?
[01:58] <SteveA> ok, I'll do it.
[01:58] <carlos> SteveA: I need to learn javascript first, long ago since last time I used it
[01:58] <BradB> sabdfl: yes
[01:58] <sabdfl> great
[01:59] <SteveA> how many different browsers do we have available to test this with? 
[01:59] <sabdfl> firefox and ie
[01:59] <carlos> SteveA: I can test it with explorer for mac, safari
[01:59] <stub> I've got a Windows partition
[01:59] <carlos> and also explorer 5 and 6
[02:00] <carlos> and of course firefox/mozilla :-)
[02:00] <SteveA> I don't know whether the HTTP stuff in javascript works outside of mozilla and IE-based browsers
[02:00] <SteveA> it didn't a while ago.
[02:00] !lilo:*! l-fy tells us that after 5 months of hard work, YATE 0.8.4 is now out.... YATE is Yet Another Telephony Engine .... for more information, see http://yate.null.ro/pmwiki/ .... thanks!
[02:00] <kiko> there is indeed a client-side concern
[02:00] <sabdfl> kiko: what's that?
[02:00] <Kinnison> what if they user has javascript disabled?
[02:01] <Kinnison> or set to disallow outgoing javascript connections?
[02:01] <stub> Safari doesn't have xml/xmlrpc stuff. I think it is fine for HTTP stuff.
[02:01] <SteveA> they'd have to type in email addresses from memory, perhaps
[02:01] <kiko> whether the browser supports the JS we want to use. we can sniff and disable it, but we need to take into account that some people won't be able to use it (lynx users, anyone?)
[02:01] <kiko> that's fine if it works. just need to ensure it does.
[02:02] <sabdfl> the other way to do this would be with wizards
[02:02] <sabdfl> where the form has to be submitted several times to get what you want
[02:02] <stub> I think fallback to no-js browsers should be a secondary consideration - we need a system *some* people can use at least, and can work on a system *everyone* can use later.
[02:03] <sabdfl> has anybody got experience with zope3 wizards?
[02:03] <SteveA> there will always be the HCT-style tools for non-JS folks
[02:03] <SteveA> who really want to use the command line
[02:03] <stub> I wrote the Z3 wizard code, which may still work, but I don't think it is what you want in this situation.
[02:04] <sabdfl> ok
[02:05] <SteveA> Are we done on large-collections-of-things-selectors?
[02:05] <BradB> SteveA: will your demo include multi-selection?
[02:06] <SteveA> I'll do a proof-of-concept dynamic JS thing, Brad can make a list of people who can log in
[02:06] <stub> SteveA: Let me know if it is going to be a slow job. I can rip out the 'popup search' logic from Roundup if necessary.
[02:06] <stub> (which is a suckier UI, but simpler to implement)
[02:07] <SteveA> BradB: is this stuff a reasonable target for what you want?  http://plone.org/Members/limi/tests/ubersearchwidget
[02:07] <sabdfl> should we just use popup for the moment, if it's much simpler?
[02:07] <sabdfl> we have longer to get it right, need to get it out there sooner
[02:08] <BradB> SteveA: i commented on that to the list last week. i'm not a huge fan of the way it's described in that page. it seems that what we've just discussed is a different, more usable approach.
[02:08] <sabdfl> that early draft looked crap. alex did a lot of work on it while he was here
[02:08] <SteveA> where is alex's latest work on that?
[02:08] <sabdfl> BradB: you mean, the http get approach?
[02:09] <BradB> sabdfl: no, the layout and selection of the results is really cumbersome.
[02:09] <kiko> it's a lot of real estate.
[02:09] <SteveA> stub: can you get the pop-up stuff working soon?
[02:09] <stub> sabdfl: I'll try knocking something up quickly tomorrow - if it works happily the popup idea man be useful in the future even after the JS version replaces it for the product/sourcepackage selects
[02:10] <sabdfl> BradB: i agree if you are saying the ubersearchwidget looks cumbersome
[02:10] <BradB> yep, that's what i'm saying :)
[02:10] <SteveA> I think if we get something like what alex proposed, we can mess around with the UI of it later.  it is the "workflow" if it that I'm most concerned about getting to work.
[02:12] <sabdfl> ok
[02:12] <sabdfl> would this all be inside a form field in the actual form?
[02:13] <SteveA> the dynamic stuff?  yes, although the JS for it would probably live in a file included in the standard page header
[02:13] <kiko> this is precisely my and Brad's point -- do we need to redesign the pages to accomodate for this search form?
[02:13] <kiko> oh. that's something else :)
[02:14] <SteveA> the search form to select a person ought to be just one rather large widget
[02:14] <SteveA> as far as zope forms are concerned
[02:14] <sabdfl> did we establish if there's a way to pass information to widgets to help them display themselves?
[02:15] <BradB> SteveA: eeg, i hope not :) that takes way too much effort.
[02:15] <sabdfl> canyou have forms within forms?
[02:15] <sabdfl> that sounds nasty
[02:15] <Kinnison> sabdfl: IIRC no you can't nest <form>s
[02:15] <SteveA> BradB: that doesn't mean that you *have* to use it that way.  But, that it can be used that way.
[02:15] <BradB> SteveA: considering that when you add a bug you currently have three values that need choosing from large lists.
[02:15] <kiko> Kinnison, you are indeed correct.
[02:15] <sabdfl> BradB: so, do you think it should be a wizard?
[02:16] <BradB> sabdfl: no. wizards are meant for things that are done rarely enough that one needs handholding to complete the process. they hurt power users.
[02:16] <BradB> i like the popup idea for this.
[02:16] <sabdfl> so...
[02:16] <sabdfl> ok
[02:16] <sabdfl> popups are going to be hated on principle
[02:17] <SteveA> browsers handle this kind of pop up fairly well -- they are directly initiated from a mouse click
[02:17] <kiko> well, unless we get the w3c to speed up and the feature implemented in at least FF...
[02:17] <BradB> it seems to take the silver medal to a combo box
[02:17] <SteveA> so mozilla knows they are legitimate
[02:17] <stub> We implemented the popup stuff for Roundup at Common Ground - seems to be quite well accepted. People are aware that there might be slicker ways of doing it, but are happy using the popups.
[02:18] <sabdfl> ok, let's go with popups for the first round
[02:18] <spiv> I've never had the roundup one break due to mozilla's popup blocking.
[02:18] <sabdfl> that at least keeps the form tight
[02:18] <kiko> I think it's the only realy solution that is cheap on real estate and familiar enough to use.
[02:18] <sabdfl> because it doesn't take a log of space to display the person, product or package that has been selected
[02:19] <SteveA> does gmail have any tricks we can "borrow" ?
[02:19] <sabdfl> i shudder at thinking about bending zope3 auto-form widgetry to our will on this
[02:19] <sabdfl> is it not better to have some Python code that generates the HTML that we can call?
[02:20] <SteveA> the HTML of the pop-up?
[02:20] <BradB> sabdfl: the deliverable should be a new kind of Z3 widget. once we've figured out how to solve this in a prototype, it should be easy to genericize as a Z3 widgete.
[02:20] <BradB> widget, even
[02:20] <sabdfl> then have a <div tal:replace="structure view/makeWidget">
[02:20] <SteveA> that would be a separate view altogether, as it is a page on its own
[02:21] <SteveA> sabdfl: we can do that, if it is easier.
[02:21] <BradB> it'll be the same as any other Z3 widget really (except it'll take different init params, of course)
[02:22] <SteveA> I'd like us to review what we have decided about people and package selectors, and then move on.
[02:22] <sabdfl> i'm talking about the forms that have these selectors on them
[02:22] <sabdfl> are we going to try to make them work well with the autogenerated forms?
[02:23] <BradB> sabdfl: yeah, that's what i'm saying. this'll be a widget like any other. (why wouldn't it be, afterall?)
[02:23] <SteveA> it isn't hard -- they take the same input from a browser as any other widget that handles the same kind of data
[02:23] <SteveA> this is just overriding the presentation of the data
[02:23] <SteveA> as far as the code is concerned
[02:23] <BradB> yep
[02:23] <sabdfl> hello?
[02:24] <sabdfl> SteveA: let's pick up the pace of this meeting
[02:24] <SteveA> the complex icky parts of a widget are those that handle form data sent by the browser
[02:24] <SteveA> I'd like us to review what we have decided about people and package selectors, and then move on.  (restated)
[02:24] <SteveA> 1. brad will make a people-who-can-log-in selection
[02:24] <SteveA> 2. stub will work on a pop-up people/packages selector
[02:25] <sabdfl> ok, some net weirdness, y'all disappeared
[02:25] <SteveA> 3. steve will do a proof-of-concept-js thing
[02:25] <SteveA> all done?
[02:25] <stub> yup
[02:25] <BradB> yes
[02:25] <kiko> right
[02:25] <sabdfl> ok
[02:26] <SteveA> dogfood:  how is it going?
[02:26] <SteveA> all new bugs shoudl be filed in dogfood malone now, right Brad?
[02:26] <Kinnison> can dogfood malone email people now?
[02:26] <BradB> SteveA: *have* to be :) i got jdub to disable the lp product in bugzilla
[02:26] <BradB> Kinnison: yes
[02:26] <SteveA> yay
[02:26] <carlos> kiko: yes, I got already some mails
[02:26] <kiko> nice
[02:26] <Kinnison> Excellent.
[02:26] <kiko> are we migrating bugs from bz?
[02:27] <BradB> dilys integration should happen todayish
[02:27] <sabdfl> do we have the bug watch updater running on mawson?
[02:27] <BradB> kiko: i filed a bug for that. it's probably a topic for the next or next-next meeting
[02:27] <sabdfl> so we can set watches on bugzilla bugs?
[02:28] <stub> No - I pinged elmo about basic auth but didn't chase it through.
[02:29] <stub> Watches are up and running, but our own bugzilla is problematic because of security (erm... not basic auth... SSL certificate I think?)
[02:29] <SteveA> can we not allow things based on ip address in this case?
[02:29] <elmo> stub: huh?
[02:29] <SteveA> mawson has an "intranet" ip address wrt the bugzilla
[02:30] <BradB> bugzilla watching is of very low priority to be honest. we're dogfooding, so even if it worked perfectly, you wouldn't know.
[02:30] <stub> elmo: mawson needs to access the canonical bugzilla without a client certificate or basic auth.
[02:30] <BradB> of high priority is bug resolution workflow, because people are going to go in and fix bugs that i've already fixed.
[02:31] <stub> SteveA: Oh - if "intranet" access means no cert or basic auth required, it should be working right now.
[02:32] <elmo> stub: it doesn't use client cert or basic auth (via apache), the auth is done on the bugzilla side?
[02:33] <SteveA> stub: I'm making a suggestion that mandatory authentication in bugzilla could be turned off for requests originating at mawson.
[02:33] <BradB> are we sure we want to discuss bugzilla watching in this meeting? :)
[02:33] <SteveA> yes.  can we have bugzilla watching soon?
[02:33] <sabdfl> watching is a neat way to transition to malone
[02:33] <SteveA> I'm not really too bothered about the details
[02:34] <stub> elmo: bugzilla.warthogs.hbd.com is publicly available?
[02:34] <kiko> AFAIK it is
[02:34] <SteveA> how about stub and elmo and brad can sort out bugzilla watching after the meeting?
[02:34] <sabdfl> elmo: the goal is for malone on mawson to be able to check the status of bugzilla bugs without needting to do client cert or basic auth
[02:35] <sabdfl> next?
[02:35] <SteveA> daf: ping
[02:35] <elmo> stub: yes - but bugzilla won't let you see anything until you login
[02:35] <daf> SteveA: pong
[02:35] <sabdfl> hiya daf
[02:35] <stub> eek.... how embarassing... all those bugs are open to the world ;)
[02:35] <daf> sabdfl: hi
[02:35] <BradB> SteveA: it was something i wasn't planning to think about until a week from now. my time is probably better spent making it possible to resolve bugs, right? :)
[02:35] <stub> ok. Watches should be available right now on our internal bugzillas, and if it don't work it is a bug and should be reported!
[02:36] <SteveA> daf and carlos: would you talk about getting rosetta to use the dogfood system?
[02:36] <sabdfl> bradb - can you not resolve a bug by editing the assignment to mark it "closed"?
[02:36] <Kinnison> <interjection style="prof. farnsworth">Good news people! Gina just completed an update to today's hoary</interjection>
[02:36] <daf> SteveA: sure
[02:36] <sabdfl> Kinnison: rock
[02:36] <carlos> yep
[02:37] <BradB> sabdfl: kind of...there's no filtering though, so it doesn't buy you a heck of a lot (the amount of effort to actually find if something you're about to report has already been reported, and then from there already been resolved is enough to call it unusable.)
[02:38] <elmo> stub: eh, which bugzilla are you looking at?
[02:38] <BradB> sabdfl: and also, what if the bug is "closed", but there's still two package infestations saying "affected"? do we still show the package maintainer those in the bug listing?
[02:38] <SteveA> BradB: I wasn't clear.  By "sort out bugzilla watching", I meant "sort out how we're going to go about it, and write a message to that effect to the mailing list"
[02:38] <sabdfl> bradb good point
[02:39] <BradB> SteveA: ok
[02:39] <SteveA> I'd like to defer discussion particular to malone to a malone meeting sometime after this meeting
[02:39] <SteveA> as we are rather dragging on today
[02:39] <sabdfl> BradB: mdz wanted a "pending upload" state
[02:39] <sabdfl> for the assignment
[02:40] <sabdfl> maybe we should change "closed" to "pending upload"
[02:40] <BradB> SteveA: the sanity of bug workflow though depends on the people that are using it, so we need input not only "also", but rather "especially" from not-malone people. :)
[02:40] <sabdfl> then add a field to point at the "fixed" package
[02:40] <sabdfl> so "pending upload" is basically "closed" without a fixing package
[02:41] <sabdfl> SteveA: ok
[02:41] <BradB> sabdfl: we need closed though.
[02:41] <sabdfl> yes
[02:41] <SteveA> BradB: sure, but we can continue that after the other stuff in this meeting
[02:41] <SteveA> daf and carlos
[02:41] <BradB> SteveA: sure
[02:41] <sabdfl> but you're right, there is a problem with a bug marked "closed" without a package that closes it
[02:42] <SteveA> what are you going to do to get rosetta on the dogfood system?
[02:42] <SteveA> what help do you need from others?
[02:42] <SteveA> how long will it take?
[02:42] <carlos> after the launchpad's mails we can assume then that our alpha testers will use the dogfood sytem, right?
[02:42] <SteveA> when you're done movingn it, yes
[02:43] <SteveA> although, the domain name they use will be the same as it is now
[02:43] <sabdfl> same db, same code, different domain
[02:43] <carlos> ok
[02:43] <sabdfl> need to (a) move user accounts, (b) move PO/POT files
[02:43] <SteveA> I need a list of the things that are "particular" to the rosetta alpha system
[02:43] <daf> the trickiest bit as far as I can see, is hiding Malone and Soyuz from the testers
[02:44] <daf> perhaps we can do this using layers
[02:44] <SteveA> such as having a custom front page, or whatever
[02:44] <sabdfl> we need to solve that problem anyhow
[02:44] <sabdfl> maybe we should solve it properly now
[02:44] <stub> Can we just run multiple launchpad instances talking to the same database?
[02:44] <SteveA> daf: I think that should be as simple as using the correct virtual hosting proxy rule
[02:44] <SteveA> stub: we can, but I'd rather not do so if they are to have different code on them.
[02:45] <SteveA> the code should be exactly the same
[02:45] <daf> SteveA: really?
[02:45] <daf> SteveA: how will it know to hide the tabs?
[02:45] <stub> SteveA: Sure. A code drop would mean updating two codebases rather than one.
[02:45] <SteveA> daf: get me the list of what is significantly "forked" in the code, and we'll work through it
[02:45] <daf> I think it's mainly the main template
[02:46] <SteveA> stub: we'd need to start thinking about ZEO if there was a round-robin/load balancing involved.  For different domains, no problem with our current use of ZODB.
[02:46] <SteveA> daf: ok, we can fix that with layers.
[02:46] <sabdfl> would it be easier if we just publish everything at launchpad.ubuntu.com?
[02:46] <SteveA> then fix it properly when I've done the context stuff discussed yesterday
[02:47] <carlos> sabdfl: then all alpha testers will have access to all applications, is that what we want?
[02:47] <SteveA> sabdfl: that doesn't make anything easier
[02:47] <sabdfl> use some sort of client-cert bsaed filtering to block access to directories other than /rosetta/ for the rosetta testers
[02:47] <sabdfl> SteveA: ok, will leave it in your hands
[02:48] <SteveA> daf: so, as a matter of priority, make the appropriate change on the rosetta layer of the main launchpad code
[02:48] <sabdfl> i'm wondering whether we want to have people think of them each as distinct, or as a single system
[02:48] <SteveA> daf: is there anything else in the code that needs changing ?
[02:48] <daf> SteveA: other than that, it's changing the database and the ports used, I think
[02:48] <sabdfl> for example, for an upstream project foo.org, do we want them to just setup launchpad.foo.org and get bugs/bounties/translations/packages/support all in one
[02:48] <sabdfl> or do we want them to setup rosetta.foo.org and malone.foo.org etc.
[02:49] <SteveA> daf: ok.  Can you do the template change today, and start working on the moving of user accounts and product imports and po/pot export-import ?
[02:50] <SteveA> daf: please stick up a wiki page with the list of tasks for getting rosetta using the dogfood system, estimate them, then start them
[02:50] <carlos> SteveA: do we have a cron jobs policy?
[02:50] <carlos> SteveA: we will need something like that to feed the database
[02:50] <carlos> with updated translations
[02:50] <daf> carlos: but we don't need that yet, do we?
[02:51] <carlos> launchpad dogfood server has lots of products already
[02:51] <SteveA> do you have that on rosetta alpha already?
[02:51] <carlos> and if we want to add their translations.. I hope we don't do it by hand
[02:51] <carlos> not yet
[02:51] !lilo:*! Hi all.  Reminder, if you're in the US and you want to attend the second day of the FTC's email authentication summit by phone, it begins in about 45 minutes, and the conference info is here: http://www.ftc.gov/bcp/workshops/e-authentication/ .... and please stop by ##ftc-summit (note two #'s).... thanks!
[02:51] <SteveA> so it is a separate task, after getting rosetta alpha running on the dogfood system
[02:51] !lilo:*! Actually, the conference has started now, please check the url for information on how to connect
[02:51] <carlos> but the script is almost ready (need to do some code refactoring)
[02:51] <kiko> sabdfl, launchpad.foo.org makes things a lot easier, IMO, and preserves the "launchpad brand"
[02:51] <SteveA> it should not delay getting rosetta to use the dogfood system
[02:51] <stub> sabdfl: If they have malone.foo.org and rosetta.foo.org, they will also need foaf.foo.org (or else foaf would have to be available under both malone.foo.org and rosetta.foo.org)
[02:51] <carlos> ok
[02:51] <kiko> I would love not having a soyuz virtualhost.
[02:52] <kiko> (because that means a virtualhost for each service)
[02:52] <daf> carlos: well, updating translations by cron job is not the same as importing
[02:52] <SteveA> daf: let me know when the wiki page is done, okay?
[02:52] <kiko> virtualhosts could be used to redirect into lp.../soyuz/ if the client wanted so
[02:52] <carlos> daf: the update can also do the import automatically
[02:52] <sabdfl> ok, and launchpad.foo.org we could get working a LOT sooner
[02:52] <sabdfl> also simplifies URL's, since everything is then in a fixed structure
[02:53] <kiko> YES!
[02:53] <sabdfl> and if we needed the separate virtual host thing, we can develop it later
[02:53] <kiko> well
[02:54] <daf> SteveA: sure
[02:54] <SteveA> so long as there is an easy API to get the public URL of something, it should be easy to change our minds later
[02:54] <kiko> as I said, it complicates URLs significantly; I'd rather soyuz.launchpad.org -> www.launchpad.org/soyuz automagically. and *that* be sold as the vhosting solution.
[02:54] <daf> carlos: hmm, is an update really the same as the import?
[02:54] <carlos> sabdfl: what happens with our current alpha test domain? a forward to launchpad.shuttleworthfoundation.org/ ?
[02:54] <Kinnison> kiko: I agree
[02:54] <SteveA> I suggest to keep the rosetta alpha as it is, from the outside
[02:54] <kiko> because you also need to consider
[02:55] <kiko> what if the person doesn't want a foaf.foo.org?
[02:55] <carlos> daf: as we are not creating new products/projects and we use soyuz information, yes
[02:55] <kiko> or rosetta.foo.org?
[02:55] <sabdfl> kiko: what complicates url's?
[02:55] <kiko> virtualhosting projects independently, sabdfl
[02:55] <kiko> (even if it is in the future)
[02:55] <daf> carlos: we still need to create PO templates
[02:55] <sabdfl> projects being.... rosetta, malone, or projects being the upstream domains?
[02:56] <kiko> rosetta, malone and soyuz and foaf and doap and ... (you get the picture :)
[02:56] <sabdfl> but you are ok with an upstream project being able to create launchpad.upstream.org and have us handle that
[02:56] <kiko> sabdfl, yes, definitely, that's perfect.
[02:57] <sabdfl> the answer seems to be different for soyuz
[02:57] <carlos> daf: true, is it a problem to create it if needed on update time?, a module could add a new domain so we will need to create a new template for an old product
[02:57] <sabdfl> i mean, soyuz WANTS to have a distro context
[02:57] <stub> sabdfl: It means that if someone jumps from launchpad.upstream.org to  launchpad.ubuntu.com, they will need to login a second time since the cookies cannot be shared cross domains.
[02:58] <kiko> sabdfl, but soyuz links to rosetta and malone internally. and then?
[02:58] <dilys> Bug 1949 resolved: first input field should be focused when translation page loads
[02:58] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1949
[02:58] <SteveA> stub: the single-sign-on stuff can fix that easily enough.  it would be a couple of instant re-directs on going to the new site.
[02:58] <sabdfl> stub: we do have a solution to that, i think
[02:58] <sabdfl> nice work daf
[02:58] <stub> sabdfl: It also complicates the issue of what URL to put in emails - launchpad.upsteam.org/malone/bug/65 or launchpad.ubuntu.com/malone/bug/65
[02:58] <daf> sabdfl: the code will work for any form that uses tabindexes correctly
[02:59] <sabdfl> ok
[02:59] <sabdfl> stub: good point
[02:59] <daf> carlos: I'm not sure -- is there any extra information needed?
[03:00] <stub> SteveA: Sucky because you have to use javascript redirects
[03:00] <SteveA> stub: no, not javascript redirects
[03:00] <stub> SteveA: Also doesn't scale if we end up with a few hundred virtual hosted launchpads.
[03:00] <carlos> daf: don't think so, we could use names like "main-1, main-2, main-3...." and rename it later by hand and get them based on their path inside the source code
[03:01] <SteveA> stub: don't see why not.  but, I think we're talking about different things.
[03:01] <carlos> daf: or we could even try to get the domain name for that po directory
[03:01] <SteveA> do we have a decision on what to do about choosing virtual hosts for the present?
[03:01] <daf> carlos: hmm, that's a bit smelly
[03:02] <daf> carlos: let's add a form for creating new templates, and use that
[03:02] <carlos> daf: I know it's not perfect
[03:02] <sabdfl> SteveA: lets discuss it, you and i, after this meeting
[03:02] <SteveA> k
[03:02] <SteveA> I'd like to move on to karma
[03:02] <carlos> will you add by hand all templates we have in hoary/warty?
[03:02] <SteveA> there was a discussion about karma yesterday
[03:02] <carlos> that's a huge work load...
[03:02] <SteveA> and adding this kind of thing to the database
[03:02] <SteveA> how's that all going?
[03:03] <sabdfl> carlos: we can't try to scale up rosetta till we can automate large amounts of it
[03:03] <sabdfl> the arch guys have made some good progress with getting code syncing
[03:03] <sabdfl> in december we can plan how to hook that automatically into rosetta
[03:04] <sabdfl> so once an upstream is syncing to arch, we can easily add it to rosetta
[03:04] <carlos> sabdfl: I have solved (more or less) the lack of arch archives
[03:04] <sabdfl> ok
[03:04] <sabdfl> how?
[03:04] <carlos> so that's not the problem
[03:04] <carlos> with python-apt (or whatever it's called)
[03:04] <sabdfl> que?
[03:05] <carlos> and now, using soyuz data
[03:05] <carlos> I get the information from where I can download the orig.tar.gz + diffs + .dsc 
[03:05] <carlos> I download it and extract it
[03:06] <carlos> and I'm ready to find the .po/.pot directories 
[03:06] <carlos> and import them into rosetta
[03:06] <SteveA> I'm hoping for an email to the list outlining the plan for karma stuff, as this will touch various parts of launchpad in due course.
[03:06] <sabdfl> neat
[03:07] <Kinnison> carlos: are you extracting those from the librarian?
[03:07] <carlos> It needs to add the distribution archives by hand, but more or lees it's a help until we finish the arch part
[03:07] <SteveA> Cookie auth should be working by tomorrow.  I'm not wholy sure how this will affect page tests, so for now, page tests will continue to use basic auth.
[03:07] <SteveA> Any other things to discuss at this launchpad meeting? 
[03:07] <carlos> Kinnison: not yet, in fact I'm starting moving from apt-get to soyuz
[03:07] <SteveA> If not, let's finish.
[03:08] <Kinnison> carlos: when you want to use the librarian; let me know
[03:08] <carlos> Kinnison: is there any documentation about it? :-P
[03:08] <Kinnison> SteveA: I just want to ask if elmo could open port 8000 up to the outside world for us?
[03:08] <Kinnison> carlos: Not yet :-)
[03:08] <sabdfl> spiv: whats the current position on having a status field on project / product?
[03:08] <Kinnison> carlos: If I can gather some use-cases from you and the others; I could write some
[03:08] <daf> SteveA: so cookie auth will work in addition to basic auth rather than replacing it?
[03:08] <SteveA> daf: yes, at least for now
[03:09] <Kinnison> SteveA: so soyuz can provide links directly to the librarian instead of having to act as a proxy to download from it
[03:09] <carlos> Kinnison: ok
[03:09] <daf> carlos: for now, I think you'll just have to probe Kinnison's brain
[03:09] <Kinnison> mmmm cranial probage
[03:09] <SteveA> Kinnison: can we do a proxy pass thing so that /downloads/... on the server is for the librarian?
[03:09] <Kinnison> SteveA: yes; but then soyuz will have to manipulate the URLs it gets from the FileDownloadClient instance
[03:10] <carlos> sabdfl: ouside the meeting scope, I have some questions about launchpad, I will give a speech tomorrow that will mention it and I'm not sure what should be said and what should not 
[03:10] <SteveA> I expect it will have to do so anyway, in reality
[03:10] <carlos> daf: :-)
[03:10] <Kinnison> SteveA: in that case; it'd be fine to do it proxy_pass
[03:10] <sabdfl> carlos: go ahead and make your own judgement
[03:11] <SteveA> Kinnison: I think that's the kind of url we'd want to present to the outside world, rather than a port 8000 thing
[03:11] <sabdfl> carlos: you can speak freely
[03:11] <Kinnison> SteveA: ack.
[03:11] <carlos> sabdfl: ok, and about the "prize" of it? I mean, I don't know if it will be free of charge for all people or only to the community, etc... 
[03:11] <Kinnison> SteveA: Should I add a getURIForAlias() method then? To only return the URI
[03:11] <Kinnison> SteveA: then soyuz can composite that with its url to form the full url for download
[03:11] <carlos> there will be many people working on local distributions in Spain
[03:11] <SteveA> Kinnison: you mean the path?
[03:11] <sabdfl> rosetta, malone will be free of charge for any project to use
[03:12] <Kinnison> SteveA: yes
[03:12] <SteveA> getPathForAlias or getURLPathForAlias ?
[03:12] <Kinnison> The former I think I prefer
[03:12] <SteveA> k
[03:12] <Kinnison> It'll be very short
[03:12] <carlos> sabdfl: ok
[03:12] <SteveA> and we can have a convention that it will always be /downloads/... on any virtual host
[03:12] <SteveA> or /files/ or whatever you think is best
[03:13] <Kinnison> that's up to the web-app guys :-)
[03:13] <SteveA> wrapping up the meeting?  Same time next week -- wednesday 12:30 UTC ?
[03:14] <sabdfl> ok
[03:14] <carlos> SteveA: ok
[03:14] <Kinnison> ack.
[03:14] <daf> yep
[03:14] <SteveA> thanks everyone.  I'll send a mail about the next meeting.
[03:15] <daf> thanks, Steve
[03:16] <carlos> daf: do we need to talk about anything urgent now?
[03:17] <daf> carlos: we need to talk about the move, but it can wait for a few hours
[03:17] <carlos> ok
[03:17] <carlos> I need to have lunch and go out for a while
[03:17] <carlos> as soon as I'm back I will ping you, ok?
[03:17] <carlos> (I think that will be in about 2 hours or so)
[03:18] <daf> ok
[03:18] <Kinnison> Well; this patch to the librarian compiles
[03:18] <Kinnison> (which is always a good start)
[03:18] <carlos> ok, later
[03:20] <Kinnison> >>> fdc = FileDownloadClient("launchpad.ubuntu.com", 8000)
[03:20] <Kinnison> >>> fdc.getPathForAlias(1)
[03:20] <Kinnison> '/1/1/3dchess_0.8.1-11.dsc'
[03:20] <Kinnison> SteveA: would that do?
[03:20] <Kinnison> SteveA: then the webapp can put 'https://....../download' on the front of that as appropriate and we can proxypass the result
[03:23] <elmo> uh
[03:24] <elmo> maybe I misunderstanding something, but you realise you're going to have to present a traditional archive layout too, right ?
[03:24] <Kinnison> elmo: that's an entirely separate thing
[03:24] <elmo> ok - what's this for then?
[03:24] <SteveA> the webapp can just make the url an abs url as <a href="/downloads/1/1/3dchess_0.8.1-11.dsc">3dchess_0.8.1-11.dsc</a>
[03:24] <elmo> 'cos serving up an archive via https makes me want to run into a wall
[03:24] <Kinnison> elmo: this is to allow the soyuz webapp to generate urls to specific files in the librarian
[03:25] <Kinnison> elmo: It is not a generic archive-exposing thing
[03:25] <Kinnison> SteveA: yeah; that's do
[03:25] <Kinnison> elmo: remember the librarian will also have build-logs and stuff in it
[03:25] <SteveA> and, if the url scheme is https, then apache can perm redir to http same url under /downloads/
[03:26] <SteveA> if we want to save https stuff.  hmm, I guess that involves the same set-up cost, though
[03:26] <SteveA> do clients generally do pipelining of requests for https ?
[03:26] <elmo> for stuff in an archive, shouldn't the webapp generate to the URL to the archive, not a librarian-specific URL ?
[03:26] <stub> Why are we trying to munge the URL's the librarian is giving us? It should be returning the one  true URL for that file.
[03:26] <Kinnison> stub: for dogfood we don't want to expose the librarian directly
[03:27] <Kinnison> elmo: When we have a useful place to put the archive; then yes it should
[03:27] <stub> Kinnison: Then the librarian should be returning the correct URL rather than localhost:8080 or some port that is internal only
[03:27] <daf> Kinnison: it should expose itself to the public?
[03:27] <elmo> we don't want to expose the librarian URLs period, IMO
[03:28] <daf> oh, a prudish librarian
[03:28] <Kinnison> I was just supplying a solution as asked :-)
[03:29] <Kinnison> SteveA: dunno; but they can do session-restart to save the asymmetric crypto
[03:33] <Kinnison> Should I commit this patch or not then?
[03:34] <daf> SteveA: https://wiki.canonical.com/RosettaToDogfood
[03:41] <SteveA> daf: write the main template layer first
[03:42] <SteveA> that way the code is ready
[03:42] <SteveA> and you just need to get the data transfered
[03:42] <SteveA> it shouldn't be "write a layer that overrides the main template", but "override the main template for the rosetta layer"
[03:42] <daf> hmm
[03:45] <daf> don't we want the layer only to be used by testers?
[03:46] <SteveA> do it for the whole of rosetta now
[03:46] <SteveA> when we have the context code done (fairly soon), we'll be able to be more selective
[03:47] <daf> context?
[03:47] <daf> what's "context" in this context?
[03:47] <SteveA> object that allows you to see what applicaiton, package, product, whatever you're in
[03:47] <SteveA> and allows you to get an appropriate URL to present for a given object
[03:54] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Add getPathForAlias to librarian client (patch-758)
[03:54] <Kinnison> thanks babe.
[04:04] <sabdfl> dilys rocks
[04:05] <Kinnison> She's certainly very handy
[04:05] <Kinnison> sabdfl: What's your favourite backup media format?
[04:05] <sabdfl> why?
[04:06] <Kinnison> Trying to choose a backup method for ca. 200 gigs of data
[04:06] <Kinnison> (for home)
[04:06] <Kinnison> I can't choose between tape or disk for a start
[04:07] <Kinnison> I figured since I remembered some mumbling about your backups at home you might have a preference :-)
[04:10] <ddaa> The Warty python does not seem to have the guts to get a traceback out of gdb...
[04:11] !lilo:*! Reminder, if you're in the US and you want to attend the second day of the FTC's email authentication summit by phone, it's in progress and the conference info is here: http://www.ftc.gov/bcp/workshops/e-authentication/ .... and please stop by ##ftc-summit (note two #'s).... thanks!
[04:14] <sabdfl> Kinnison: a second hard drive :-)
[04:14] <Kinnison> sabdfl: feh; I already have RAID-1 going on :-)
[04:15] <Kinnison> sabdfl: Will the timings i put in that mail be okay for next wednesday?
[04:15] <sabdfl> yup
[04:16] <ddaa> Mh... python 2.4 does not seem to be in hoary yet...
[04:16] <Kinnison> sabdfl: excellent
[04:19] <sabdfl> daf, carlos, is the alpha testing system supposed to be giving errors all over the show?
[04:30] <Kinnison> rehi debonzi 
[04:30] <debonzi> Kinnison, yo
[04:31] <cprov> spiv: librarian works w/ sqlo--0.6, thanks
[04:32] <cprov> Kinnison: do you have any dump of dogfood db ? those stored in mawson look a bit strange, they have binary code inside or were corrupted .. am I missing something about dumps ?
[04:32] <Kinnison> cprov: erm; you want a dump of the dogfood db? just make one yourself. (you have sudo right?)
[04:35] <Kinnison> cprov: sudo -u launchpad pg_dump launchpad_dogfood | bzip2 -c > ~/lp-dump.bz2
[04:37] <stub> The nightly dumps are in pg_dump's custom format, which can be used by pg_restore to reload. Lets you do partial loads and reordering load order and stuff (because pg_dump is TOO STUPID to get the dump order correct).
[04:38] <Kinnison> yeah
[04:38] <Kinnison> I guess
[04:39] <Kinnison> nighty stub
[04:40] <stub> Have to work on these late nights - I've started ranting on mailing lists. Never a good sign ;)
[04:42] <cprov> stub: thanks, I'll try this on with pg_restore
[04:44] <sabdfl> stub: i'd NEVER be  one to suggest beauty sleep
[04:44] <sabdfl> however, you shouldn't have accepted that patch from me without comments
[04:44] <sabdfl> will commit a comments fragment now
[04:45] <BradB> meta constraints, as it were
[04:45] <Kinnison> we'd get piles of crap comments if we enforced that
[04:45] <BradB> Kinnison: which would mean piles of scolding email, i guess :P
[04:45] <Kinnison> hehe
[04:46] <Kinnison> seems easier to persuade stub to not accept poorly commented patches
[05:00] <BradB> SteveA: ping
[05:18] <BradB> Anyone know offhand if the test runner is smart enough to treat .txt files as documentation/test code (i.e. doctests :)?
[05:19] <BradB> I want to test code in dir foo/, and so I want demonstration in foo/README.txt to get run as doc tests.
[05:19] <BradB> s/demonstration/demonstration code/
[05:24] <carlos> sabdfl: no, I saw it this morning but I don't understand why it does it if the code is not changing nor the database... daf is looking at it already
[05:55] <sabdfl> ok
[06:13] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: bring bounty tests on stream (patch-759)
[06:50] <SteveA> BradB|lunch: no, it isn't.  you have to explicitly say in a test_something.py module that a particular text file is a test.  There is a test_pages.py module that does that for all .txt files in canonical/launchpad/pagetests/
[06:50] <SteveA> I wouldn't like to have just any .txt file treated as a test
[07:02] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Rosetta functional tests disabled, they were not working and we should improve them (patch-760)
[07:15] <kiko-afk> BradB|lunch, question for you in bug 2167.
[08:15] <BradB> SteveA: I want to test that my changes to the PersonVocabulary work. I started writing this as doctest, then realized I sort of need the zope machinery running (e.g. to register an IZopeDatabaseAdapter) to test this. How would you recommend I write a simple test like that? (I could shoehorn it as a page test, but it's nothing near a functional test; all I'm testing is that PersonVocabulary returns the terms I expect.)
[08:15] <BradB> kiko-afk: ?
[08:15] <kiko-afk> yes BradB?
[08:16] <BradB> 	<kiko-afk>	BradB|lunch, question for you in bug 2167.
[08:16] <kiko-afk> BradB, right, there's a question -- two actually -- for you, in bug 2167. 
[08:16] <kiko-afk> :)
[08:16] <BradB> heh
[08:16] <BradB> ok, /me reads
[08:17] <SteveA> BradB: why do you need to register an IZopeDatabaseAdapter?  Can't you just register an IPeople or IPersons utility?
[08:18] <SteveA> that's half the point of using utilities here -- to make this kind of test more straightforward
[08:18] <BradB> SteveA: It's a vocab that hits the DB.
[08:19] <BradB> SteveA: this test is only effective if it proves that noone broke the change i made to only return people who have passwords
[08:20] <SteveA> if the vocab were to use IPersonSet...
[08:20] <SteveA> then you'd just need to test that it uses the correct IPersonSet api
[08:20] <BradB> yeah
[08:20] <SteveA> otherwise, you need to write a functional test
[08:20] <SteveA> to live in .../ftests
[08:20] <BradB> darn
[08:20] <BradB> oh well
[08:24] <SteveA> daf: can you add time estimates to here https://wiki.canonical.com/RosettaToDogfood   or link to malone bugs, if there are any ?
[08:29] <daf> sure
[08:30] <SteveA> thank you
[08:30] <daf> carlos: what's the ETA on that SQL script?
[08:30] <carlos> work in progress
[08:31] <daf> estimated time?
[08:32] <carlos> phone
[08:32] <daf> >>> int("phone")
[08:32] <daf> ValueError: invalid literal for int(): phone
[08:34] <carlos> :-P
[08:37] <carlos> daf: I think it will take about 1:30
[08:37] <carlos> ideally, only one hour
[08:38] <daf> ok
[08:38] <daf> thanks
[08:38] <BradB> kiko-afk: i replied. that should give you enough to get started, i think.
[08:55] <carlos> daf: we only have 4 people doing alphatesting...
[08:55] <carlos> the others don't have selected a language...
[08:56] <daf> carlos: hmm, that explains why everyone has been quiet
[08:57] <carlos>  Philipp von Weitershausen, Dwayne Bailey, Dinu Gherman and Denis Jacquerye
[08:57] <carlos> ok, my friends suck a lot :-(
[08:57] <carlos> none tested it
[08:57] <daf> heh
[08:59] <SteveA> did you mail godefroid?
[09:00] <daf> I ahven't
[09:00] <daf> I have two people to add to the testers
[09:01] <daf> I'm now planning to add them after we make the move
[09:01] <SteveA> godefroid was keen to have a look.  it is good to respond promptly to keen people
[09:02] <SteveA> otherwise their keenness tends to evaporate
[09:02] <daf> true
[09:04] <sabdfl> daf: how difficult is it to get a new POT and set of PO files into rosetta?
[09:04] <daf> sabdfl: not very
[09:05] <sabdfl> can it be user driven at this stage?
[09:05] <daf> no
[09:05] <sabdfl> hmmm.... 
[09:05] <daf> that would be useful
[09:05] <daf> the current model is "you ask for a project and the admins create it for you"
[09:05] <sabdfl> how long does it take you to do it currently?
[09:06] <sabdfl> how many projects have been asked for?
[09:06] <daf> perhaps we should move towards a "you can do it and the admins will fix it if you mess it up"
[09:06] <daf> nobody has explicitly asked for projects
[09:06] <sabdfl> right, then let's stick with that till it becomes too much of a bottleneck
[09:07] <SteveA> is zope3 in there yet?
[09:07] <SteveA> I asked for that
[09:07] <SteveA> is plone in there yet?
[09:08] <sabdfl> in where?
[09:09] <SteveA> in rosetta
[09:09] <SteveA> in the alpha
[09:09] <SteveA> in reply to "nobody has explicitly asked for projects"
[09:09] <sabdfl> ah, right
[09:14] <sabdfl> ok, how do i jump to the *next* matching tag
[09:14] <sabdfl> ctrl-} gets me to the first
[09:14] <sabdfl> but that's not the one I want
[09:14] <sabdfl> ] 
[09:14] <sabdfl> sorry
[09:14] <sabdfl> i want another one
[09:15] <sabdfl> how do I get the next one?
[09:15] <SteveA> I just use tjump, and select from there
[09:15] <SteveA> I've never needed anything more fancy for long enough to find out how
[09:17] <sabdfl> tjump?
[09:17] <SteveA>  while on a tag, :tjump
[09:23] <spiv> sabdfl: :ts  (for tag select)
[09:23] <sabdfl> thanks guys
[09:48] <sabdfl> spiv: is there such a thing as an IntervalCol?
[09:48] <sabdfl> DateTimeCol *sort of* works
[09:48] <sabdfl> if you don't push it
[09:50] <spiv> Hmm, I think I had some work on this somewhere.
[09:53] <spiv> Ah, it's already integrated.
[09:53] <spiv> sabdfl: Sadly, no, although it would be nice to fix it.
[09:54] <sabdfl> so using DateTimeCol and restricting it to days hours minutes seconds works best?
[09:55] <sabdfl> oh bugger that doesn't work either
[09:56] <sabdfl> unless you also limit it to a value less than one month
[09:56] <sabdfl> because as soon as the interval is greater than one month, datetimecol freaks out
[09:58] <carlos> spiv: I'm having some problems using initZopeless from an script
[09:59] <carlos> spiv: It's does all work but it's never committed to the database
[10:00] <carlos> spiv: If I don't use begin/commit explicity I get:
[10:00] <carlos> /home/carlos/Work/launchpad/lib/canonical/database/sqlbase.py:85: UserWarning: Something tried to set a _connection.  Ignored.
[10:00] <carlos>   warnings.warn("Something tried to set a _connection.  Ignored.")
[10:00] <spiv> carlos: Are you calling .commit on the transaction manager?
[10:00] <carlos> and if I add the begin/commit I get an error
[10:01] <carlos> same warning and then:
[10:01] <carlos> Traceback (most recent call last):
[10:01] <carlos>   File "./import_users.py", line 168, in ?
[10:01] <carlos>     ztm.commit()
[10:01] <carlos>   File "/home/carlos/Work/dists/launchpad/lib/canonical/database/sqlbase.py", line 214, in commit
[10:01] <carlos>     self.manager.get().commit(sub)
[10:01] <carlos>   File "/home/carlos/Work/dists/launchpad/sourcecode/zope/src/transaction/_transaction.py", line 293, in commit
[10:01] <spiv> I should probably turn that warning off, it never seems to be a real problem.
[10:01] <carlos>     self._commitResources(subtransaction)
[10:01] <carlos>   File "/home/carlos/Work/dists/launchpad/sourcecode/zope/src/transaction/_transaction.py", line 340, in _commitResources
[10:01] <carlos>     rm.tpc_vote(self)
[10:01] <carlos>   File "/home/carlos/Work/dists/launchpad/sourcecode/zope/src/transaction/_transaction.py", line 629, in tpc_vote
[10:01] <carlos>     self._datamanager.prepare(transaction)
[10:01] <carlos>   File "/home/carlos/Work/dists/launchpad/lib/sqlos/transaction/__init__.py", line 146, in prepare
[10:01] <carlos>     raise TypeError('Already prepared')
[10:01] <carlos> TypeError: Already prepared
[10:01] <spiv> Oh!
[10:01] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: still doing soyuz/people improve and preparing for debonzi's soyuz cleanup (patch-761)
[10:01] <spiv> Can I look at the script, please? :)
[10:02] <carlos> sure
[10:02] <spiv> I tried to pin down this problem for lifeless earlier, but it disappeared before I could.
[10:02] <spiv> And I can't figure out how to reproduce it intentionally :0
[10:02] <carlos> sent by mail
[10:02] <sabdfl> spiv: who does psycopgda?
[10:03] <carlos> daf: the script is ready
[10:03] <spiv> sabdfl: I'm not sure.  It lives in Zope's repo somewhere, I think.
[10:03] <carlos> but with the problem I'm asking spiv
[10:03] <spiv> carlos: Great, thank you :)
[10:04] <carlos> spiv: another thing I was not able to do is use lanchpad_dev directly without using the external env var: LP_DBNAME=launchpad_dev 
[10:05] <daf> carlos: ok, cool
[10:05] <carlos> the dbname='launchpad_dev' seems like it's ignored
[10:05] <carlos> daf: and just in time :-) 1:30 minutes
[10:05] <daf> carlos: I suppose we need to send it to whoever's maintaining the dogfood server
[10:05] <carlos> daf: you don't have access to the database?
[10:05] <carlos> hmm
[10:05] <carlos> ok
[10:05] <daf> carlos: care to update the wiki?
[10:06] <carlos> makes sense
[10:06] <carlos> forget that
[10:06] <daf> carlos: I'm not sure
[10:06] <carlos> :-)
[10:06] <sabdfl> spiv: ok, the bug appears to be in psycopgda.adapter
[10:06] <carlos> daf: will do it now, I will commit the script also inside rosetta/scripts is that ok for you?
[10:07] <daf> carlos: I'm not sure
[10:07] <sabdfl> line 195
[10:07] <daf> carlos: if it's a general script, sure
[10:07] <carlos> not really
[10:07] <carlos> it has the data inside the script
[10:07] <carlos> it's specific for this task
[10:07] <sabdfl> who can i get to commit a fix there?
[10:07] <carlos> I will send you it by mail now so you can review it
[10:08] <carlos> spiv: do you need me in the next 30 minutes?
[10:08] <sabdfl> bradb: banged my head on that one too
[10:08] <BradB> heh
[10:08] <spiv> carlos: Don't think so.
[10:08] <carlos> spiv: ok, thanks
[10:08] <daf> BradB: I think I might have filed a bug on that
[10:09] <sabdfl> spiv: is there a way to get postgres to report a month as "month" instead of "mon"?
[10:09] <sabdfl> psycopgda is expecting "month" or "months" from the interval, and postgres is delivering "mon" or "mons"
[10:09] <sabdfl> why, i don't know
[10:10] <sabdfl> everything else is sane: day(s), week(s), mon(s), year(s)
[10:10] <daf> making it mon(th)(s) would fix it
[10:10] <dilys> Bug 2159 resolved: Remove soyuz/projects
[10:10] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2159
[10:12] <spiv> sabdfl: maybe it can be changed with "set datestyle", I'm looking at the docs now.
[10:12] <carlos> daf: I have a question inside the script about what should we do if the user already exists, should we change the password or leave it as it's now?
[10:12] <carlos> daf: sent by mail
[10:12] <carlos> grrrr
[10:12] <dilys> Bug 2074 resolved: Create the Postgresql Views for Soyuz App
[10:12] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2074
[10:12] <carlos> I should stop using Jabber
[10:13] <daf> carlos: print a warning and do nothng, I think
[10:13] <dilys> Bug 2090 resolved: Add Brad's nickname.py lib and CreatePerson() method to FOAF
[10:13] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2090
[10:13] <carlos> ok
[10:13] <carlos> will fix it and update the wiki after dinner
[10:13] <carlos> later
[10:14] <daf> later
[10:14] <daf> carlos: you can probably remove Limi also
[10:15] <carlos> ok
[10:16] <daf> other than that, it looks good
[10:17] <spiv> sabdfl: I can't seem to find a setting to change that :/
[10:17] <sabdfl> ok, so it's a bug
[10:18] <sabdfl> works fine for me if i change the code
[10:18] <sabdfl> but i cant commit to psycopgda
[10:20] <daf> I think we should fix it locally and send a patch upstream
[10:27] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Big soyuz clean up and organization. Everything seems to be very cleaner now. (patch-762)
[10:34] <cprov> night all
[10:37] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: temp fix for the person vocab, reducing the people returned to only those that can login (i.e. have passwords) (patch-763)
[10:50] <carlos> ok, I'm back
[11:20] <daf> carlos: great
[11:20] <daf> carlos: I'm going to leave soon to give a talk
[11:20] <carlos> daf: I'm going to leave soon to sleep
[11:21] <carlos> I should wake up in less than 6 hours to drive to Madrid...
[11:22] <carlos> ok, good night
[11:22] <daf> night
[11:22] <carlos> daf: If you need anything from me next days, just send me an email and I will try to be online as soon as possible
[11:22] <daf> carlos: sure
[11:23] <carlos> night!