[12:00] <carlos> spiv: interesting, I did not know that
[12:00] <spiv> Try select * from emailaddress where emailaddress.person = person.id;
[12:00] <carlos> daf: hmmm
[12:00] <carlos> daf: put it inside sql.py :-P
[12:01] <spiv> (or select emailaddress.* from emailaddress inner join person on (emailaddress.person = person.id); :)
[12:01] <daf> carlos: I could do, but...
[12:01] <carlos> daf: It was a joke
[12:01] <spiv> And EXPLAIN claims they're identical.
[12:01] <carlos> spiv: ok
[12:02] <carlos> spiv: so the inner join and the from tablea, tableb... will be always the same?
[12:02] <carlos> we don't get any improvement?
[12:03] <spiv> I'm getting identical query plans according to EXPLAIN ANALYZE, with the same speeds.
[12:03] <spiv> (on a ridiculously small dataset, though)
[12:04] <spiv> Anyway, you can specifiy INNER JOIN explicitly with SQLObject if you want to, it's just a bit evil:
[12:04] <carlos> don't worry
[12:04] <carlos> I will do some performance test before without sqlobject
[12:04] <spiv> EmailAddress.select('', clauseTables='select emailaddress.* from emailaddress inner join person on (emailaddress.person = person.id)'), I think ;)
[12:05] <spiv> Oh, actually, I think that'll put an extra comma in, breaking it.  Damn.  Oh well :)
[12:05] <carlos> that's really ugly :-D
[12:05] <spiv> Er, I mean:
[12:05] <spiv> EmailAddress.select('', clauseTables='inner join person on (emailaddress.person = person.id)'), I think ;)
[12:05] <spiv> Silly copy & paste.
[12:06] <spiv> Anyway, it's probably worth checking all our uses of clauseTables to make sure we haven't made the same mistake everywhere :)
[12:07] <carlos> spiv: I'm fixing Rosetta ones
[12:07] <daf> spiv: wow, nice hack :)
[12:07] <spiv> carlos: Great :)
[12:12] <daf> carlos: looks like you're King of PQM again :)
[12:12] <carlos> daf: I know :-(
[12:12] <carlos> daf: seems like my postfix problem broke it again
[12:12] <daf> oh, how did that happen?
[12:13] <carlos> daf: I have as relay host my home machine
[12:13] <carlos> and I'm not in my home now
[12:13] <carlos> so all my requests were rejected 
[12:13] <carlos> and I notice it after a day
[12:14] <carlos> thus, I sent merge requests and star-merge before the merge was done
[12:14] <spiv> After sending a merge request, aren't you supposed to wait for a rejection/success message from PQM before doing a merge from rocketfuel to $myarchive?
[12:15] <daf> carlos: I don't understand -- if the emails didn't go anywhere, how can they have affected things?
[12:16] <carlos> daf: I think they do anything to my local archive
[12:16] <carlos> spiv: the problem is that I sent it before going to sleep
[12:16] <carlos> and I did the star-merge when I woke up
[12:16] <carlos> without checking it
[12:17] <spiv> carlos: Ah.  I see :)
[12:17] <carlos> daf: if that's not the case, It's not my fault then :-D
[12:18] <spiv> The submit-arch-merge script doesn't touch your local archive.
[12:19] <carlos> then it's not my fault
[12:19] <spiv> It simmply sends a gpg-signed message saying "tla star-merge $mytree rocketfuel@canonical.com"
[12:22] <dilys> Bug 2003 resolved: Implement edit personal information
[12:28] <carlos> cprov: did you reused the code we have in rosetta to edit the people personal information? (name, displayname, password, etc...)
[12:37] <carlos> daf: I sent a merge request with some sqlobject changes so some queries should be faster
[12:40] <daf> carlos: cool
[12:40] <cprov> carlos: no !
[12:40] <carlos> cprov: :-(
[12:40] <cprov> carlos: should I use ? 
[12:41] <carlos> cprov: If you are changing those fields..
[12:41] <cprov> carlos: i know this is really bad ! 
[12:43] <cprov> carlos:  maybe we need to have a brief meeting soon, about reusable code produced by rosetta continuos Sprint , what do you think?
[12:45] <carlos> cprov: well, we don't have much more code to share (outside our Rosetta sqlobjects )
[12:46] <cprov> carlos: anyway, what you just said to me about Edit Person is interesting
[12:47] <carlos> but I talked about that already (not sure if you were present, I suppose you were not)
[12:47] <spiv> daf: Btw, I've attached a patch to 2030
[12:47] <cprov> carlos: what i have implemented is poor, untested, quick&dirty solution and so far from what should be a good component 
[12:48] <carlos> cprov: my code is not the best one out there but works :-)
[12:48] <carlos> rosetta/prefs
[12:48] <carlos> (but launchpad is now broken to see it)
[12:48] <carlos> cprov: is something like the bugzilla form to change the user data + password
[12:48] <cprov> carlos: the same as mine, i just suggesting that if there was just one it could be much better :)
[12:48] <carlos> spiv: night
[12:49] <cprov> carlos: I see 
[12:49] <carlos> cprov: we know that we only need one, but for the alpha we need it inside rosetta
[12:49] <cprov> spiv: night 
[12:50] <cprov> carlos: of course, the rosetta team is feeling the Release Pain for a long <wink>
[01:01] !lilo:*! Happy big 24, Matt. :)
[01:05] <cprov> carlos: daf : see you later, good night 
[01:20] <carlos> good night
[01:51] <sabdfl> night all
[04:31] <kiko> man
[04:31] <kiko> I need sleep
[05:22] <dilys> New bug 2031 for Launchpad/Launchpad: PQM success or failure messages being bounced?
[05:47] <dilys> New bug 2032 for Project Admin/General: Broken functionality at lists.ubuntu.com
[09:13] <SteveA> hi stub
[09:14] <stub> Morning
[09:14] <stub> lifeless was interested in auth stuff too
[09:17] <SteveA> lifeless was going to write up his requirements for auth
[09:18] <stub> ok. I'm mainly interested in what permissions we are using (zope.Public, zope.View? canonical.Foo?) and recommended ways for running the dev environment at this time (add some principals to principals.zcml that happen to match rows in the Person table?)
[09:19] <SteveA> right now, we're using two permissions: zope.Public (the pass-through always public permission) and launchpad.AnyPerson
[09:20] <SteveA> launchpad.AnyPerson is granted to any Person in the database
[09:20] <SteveA> you need to run the database to run the dev environment
[09:20] <SteveA> you need to be using Persons that are in the database in your dev environment
[09:20] <SteveA> there is a script to add a person to the database
[09:21] <SteveA> don't use principals.zcml
[09:22] <SteveA> soon (most likely at the sprint that starts next week), we'll be adding a more interesting security system that allows permissions to be granted based on the contents of the database
[09:23] <stub> ok - so for right now nothing more granular than those two permissions. 
[09:23] <stub> I think that is pretty much all I need for now - I'll give it a go :-)
[09:23] <SteveA> ok
[09:24] <SteveA> with developing malone, right now, you're getting it working properly given the changes to launchpad while you've been away.
[09:24] <SteveA> you mentioned that you'd done some stuff on the "bug assignment" changes
[09:25] <SteveA> can we talk a bit about what the state of malone is, and what you intend to do next?
[09:26] <SteveA> we also need to talk about portlets
[09:33] <stub> Yo
[09:34] <stub> re: BugAssignments - a SourcepackageBugAssignment and a ProductBugAssignment now has an assignee, which will default to the owner of the Sourcepackage or the Product.
[09:35] <SteveA> I suppose we'll need a UI to change assignments
[09:36] <SteveA> and, this is a point where being able to mail out would be good
[09:36] <stub> Yup - the existing edit pages for the bug assignments will pick up the new field. I just need to update the tempates to display it.
[09:36] <stub> Oh... and a widget to select an assignee (like the existing sourcepackage selector and product selectors).
[09:37] <stub> I think the next thing is the email interface - I might do the soyuz portlets first since they should be quick.
[09:37] <SteveA> doing the soyuz portlets next would be good, because of the sprint next week
[09:38] <SteveA> we'll be doing serious work on the soyuz ui
[09:38] <stub> At least outgoing notifications. Handling replies and embedded commands are not an absolute requirement for the functionality.
[09:38] <SteveA> yep.  I'd like outgoing mail to be done transactionally, using the maildir stuff in zope3
[09:38] <stub> If you get some sort of a widget that lets you efficiently select a sourcepackage from a list of 1000, I'll be happy.
[09:38] <SteveA> as it doesn't make sense to send out mail on a failed transaction
[09:39] <stub> Yup - nice I don't have to implement transactional email like I did on the last project :-)
[09:40] <SteveA> 1000 isn't all that much to store, hidden, in a webpage
[09:41] <SteveA> so, some simple javascript should help there
[09:41] <SteveA> if we need 10000, then we'll need to consider fancy javascript-does-web-request kind of things
[09:41] <stub> Rendering 1000 items using tal takes time though.
[09:41] <SteveA> don't render them with tal
[09:41] <SteveA> use python
[09:42] <stub> ok. Doing it that way should plug in happily to the Malone forms (so I shouldn't have to worry about efficient controls for now).
[09:43] <SteveA> yeah.  It would be good to have a list of the controls in the application that will need some scalability work
[09:44] <stub> We are going to need something more complex than that eventually though. I have pages where you select the 'product', and from that it should restrict the allowed 'sourcepackage' values to something reasonable. And the selected 'sourcepackage' should restrict the binarypackage. And the binary package should restrict the binarypackage.version.
[09:44] <SteveA> hmm... co-dependent widgets
[09:44] <stub> But for now I won't worry about that.
[09:45] <SteveA> I can *imagine* the kind of javascript that would allow a bunch of widgets to collaborate like that, with a shared context object
[09:45] <SteveA> it feels like it is do-able
[09:47] <SteveA> with outgoing mail, where will mail templates be put?
[09:47] <SteveA> will they be text files with %{varname}s replacement in them, then re-wrapped?
[09:48] <SteveA> in one of my own projects, emails have replacements in ALL CAPITAL LETTERS, but that's for mails that are editable by end-users.
[09:49] <stub> Hmm... last time I implemented something like this I just sent HTML mail and used page templates
[09:50] <stub> I think text files with %(foo)s substitution is a good start.
[09:50] <SteveA> I'm pretty sure a lot of our target audience will hate HTML mail
[09:50] <stub> It would be funny but :)
[09:50] <SteveA> there's a textwrap library (by greg ewing iirc) in python 2.3
[09:51] <SteveA> so, I have malone tasks so far as:
[09:51] <SteveA> 1. security: make malone with with zope.Public and launchpad.AnyPerson
[09:51] <SteveA> 2. malone portlets for soyuz
[09:51] <SteveA> 3. transactional outgoing mail for malone
[09:51] <SteveA> 4. bug assignee stuff
[09:51] <SteveA> what's next?
[09:51] <SteveA> stuff so that we can use it for dogfood with launchpad perhaps?
[09:51] <stub> Bug assignee needs to be simultaneuous with 1 - it is a mandatory field so forms won't work without it.
[09:52] <stub> I think that is it pretty much
[09:52] <SteveA> is there a notion of dependency between bugs in malone?
[09:53] <stub> Yes. It is not being used for any of the rendering or searches though.
[09:53] <stub> You can enter the information, but it ain't used for anything.
[09:53] <SteveA> a simple text page listing the bugs that a bug depends on would be useful for launchpad
[09:54] <stub> Yup - that and all the other useful reports :-)
[09:54] <SteveA> I think we'd be able to start using it for launchpad then, but I'll need to check the wiki page
[09:55] <SteveA> I'm not sure that the other reports are so essential.  Well, other than "what bugs are assigned to me"
[09:55] <stub> Hmm... now that I think of it... the current schema only supports a bug being dependent on one other :-(
[09:55] <stub> Might need to scrap the existing dependant column and add a new table if out use of Bugzilla is anything to go by
[09:56] <stub> c/out/our
[09:56] <SteveA> what about attachments -- is malone up to date with the new way of representing attachments and messages?
[09:56] <SteveA> can attachments be added TTW ?
[09:57] <stub> No. No attachments at the moment. I've got some bugs in Bugzilla about that. The first dependancy was 'migrate librarian to launchpad' which has been done. 
[09:57] <stub> So I guess that is another item for the list.
[09:58] <SteveA> do you know the bug number?
[09:59] <SteveA> I suppose we need to work out how to do the librarian stuff in a development environment
[09:59] <stub> Bugs # 1921 - 1924
[09:59] <stub> (although they are actually issues ;) )
[09:59] <SteveA> 1921, 1922, 1923 and 1924 ?
[09:59] <stub> Yup
[10:00] <stub> I submitted the bugs in sequence :-)
[10:00] <SteveA> any ideas about making librarian work in a dev environment?
[10:00] <SteveA> I'm getting worried about the weight of the dev environment
[10:01] <stub> Yup - we define the high level interface and don't use it.
[10:01] <SteveA> is there a way to make a dependency on librarian optional for launchpad?
[10:01] <stub> Erm... we define the high level interface and don't use librarian... just a stub.
[10:01] <SteveA> I suppose when I hook up zodb, zodb can be used as a librarian for development
[10:02] <SteveA> does that sound sensible or not?
[10:02] <SteveA> (haha, stub said "stub")
[10:02] <stub> We have setfile, getfile, geturl etc. Just need to make them store the files somewhere (fs is fine), and generate URL's that launchpad serves
[10:02] <SteveA> ok, fs sounds ok
[10:03] <SteveA> can I add that to the malone work, or do you want spiv to do that?
[10:03] <stub> We then cross our fingers and hope the real librarian works the same way in production (or perhaps we should test ;) )
[10:03] <stub> I'm happy to do it, since I have what is needed in my head. If someone else has time though it would be great.
[10:04] <SteveA> ok, I have you on the hook for writing a spec for the stub librarian
[10:04] <stub> I don't think any other launchpad stuff is using it except for Malone?
[10:04] <SteveA> well, buttress
[10:05] <SteveA> and soyuz will eventually I guess
[10:05] <SteveA> but malone first of all, sure
[10:06] <SteveA> so...
[10:06] <SteveA> 
[10:06] <stub> ok. People should have a look at the bug and add any thoughts before it is coded.
[10:06] <SteveA> 1. security: make malone with with zope.Public and launchpad.AnyPerson
[10:06] <SteveA> 2. bug assignee stuff
[10:06] <SteveA> 3. malone portlets for soyuz
[10:06] <SteveA> 4. transactional outgoing mail for malone
[10:06] <SteveA> 5. make attachments work properly, #1921 #1922 #1923 #1924
[10:06] <SteveA> 6. write spec for a stub librarian that uses the fs for the dev environment
[10:06] <SteveA> 7. maybe implement stub librarian spec
[10:06] <SteveA> 8. making a bug dependent on many others
[10:06] <SteveA> 9. dependency report
[10:06] <SteveA> 
[10:06] <SteveA> does that get us to the point where we can use malone for dogfood?
[10:07] <SteveA> we may want justdave to cook up a script to import open bugs
[10:07] <stub> I think 5,6,7 are in the wrong order
[10:07] <SteveA> what's a good order?
[10:07] <stub> 6,7,5 (where 7 is done if 6 looks simple)
[10:08] <SteveA> ok
[10:11] <SteveA> what else before starting project dogfood?
[10:11] <stub> Nothing I can think of, but I've said that before...
[10:12] <stub> Oh... private stuff
[10:12] <SteveA> ok.  I'll add this list to a bugzilla bug.
[10:12] <SteveA> we don't need private stuff to dogfood on launchpad
[10:12] <stub> Is that needed for dogfood, or post dogfood?
[10:12] <stub> k
[10:12] <SteveA> that's needed for when we use the golden database
[10:17] <stub> Other stuff is more general launchpad issues such as bug 2005
[10:18] <dilys> New bug 2033 for Launchpad/Malone: Tasks that get us to eating our own dogfood
[10:18] <stub> I take it dilys is a bot :-)
[10:19] <SteveA> dilys: say hi to stub.
[10:19] <SteveA> I think dilys only has advanced AI features when daf is awake and at his keyboard ;-)
[10:21] <SteveA> stub: please add whatever dependencies make sense on that bug, and add comments to track progress / issues / whatever
[10:21] <stub> ok
[10:25] <SteveA> https://www.warthogs.hbd.com/ScalableWidgets
[10:26] <SteveA> I've noted the requirements you mentioned, and also that the Malone source-package widget needs some of this
[10:26] <SteveA> Please add to this page for what you know about malone, maybe being a bit more specific about the requirements for the widgets than I have been
[10:33] <dilys> New bug 2034 for Launchpad/Launchpad: allow 'count' method of SelectResults in SQLOS
[10:37] <stub> oops.... https://bugzilla.warthogs.hbd.com/bugzilla/showdependencygraph.cgi?id=2033
[10:37] <stub> justdave: Known bugzilla probem?
[10:46] <SteveA> argh... what a scam
[10:47] <SteveA> nominet, the .*.uk monopoly introduced new terms a few months ago.  they now want 35 quid to transfer any .uk domain names.
[11:06] <justdave> wow, that's a funky graph
[11:06] <justdave> no, haven't seen it do that before.
[11:09] <lalo> printk("Help, too many green dots!")
[11:10] <justdave> heh.  was just going to ask, is that like every bug in the system on that chart? :)
[11:11] <carlos> morning
[11:11] <sabdfl> hey carlos
[11:14] <lalo> morning carlos, sabdfl
[11:28] <spiv> Moaning, er, morning ;)
[12:10] <dilys> SteveA: hi to stub
[12:10] <daf> (morning)
[12:11] <stub> I think dilys is a little slow
[12:11] <carlos> X-)
[12:12] <daf> well, those advanced AI features cost a lot of processing time
[12:15] <carlos> hmm
[12:15] <carlos>     ConfigurationError: ('No such file', '/home/carlos/Work/dists/launchpad/lib/canonical/soyuz/templates/person-join.pt')
[12:17] <carlos> should I comment the reference and commit?
[12:17] <daf> yeah
[12:18] <daf> it would be nice to find who's responsible so you can chastise them :)
[12:24] <carlos> daf: I suppose it was Celso 
[12:25] <carlos> daf: he was working yesterday on it
[01:28] <carlos> stub: do you want that I execute the import test with the new indexes you sent to the mailing list?
[01:28] <carlos> to generate a new report
[01:30] <stub> carlos: If you have time it would be great. Saves me some research, and empirical data is probably better anyway ;)
[01:31] <carlos> ok
[01:31] <carlos> stub: I can work in other things at the same time
[01:40] <carlos> hmm
[01:41] <carlos> seems like some changes I did yesterday broke rosetta :-?
[01:41] <carlos> sqlobject.main.SQLObjectNotFound: The RosettaPOMessageID by alternateID msgid=u'_About' does not exist
[01:42] <carlos> spiv: we had it as RosettaPOMessageID.selectBy(msgid=u'_About')
[01:42] <carlos> and we check later if it's empty or not, is there an easy way to do it with the alternateID without catching the exception?
[01:43] <carlos> well, I suppose that it's the "normal" way to do it now...
[01:44] <spiv> Yeah, it is.
[01:44] <spiv> For the same reason that Foo.get(id) should raise an exception if there is no row with that ID.
[01:45] <carlos> hmm, the code looks cleaner now, catching this exception :-)
[01:45] <daf> bonus :)
[01:45] <carlos>      def poTemplate(self, name):
[01:45] <carlos> -        results = RosettaPOTemplate.byName(name)
[01:45] <carlos> -        count = results.count()
[01:45] <carlos> -
[01:45] <carlos> -        if count == 0:
[01:45] <carlos> +        try:
[01:45] <carlos> +            return RosettaPOTemplate.byName(name)
[01:45] <carlos> +        except SQLObjectNotFound:
[01:46] <carlos>              raise KeyError, name
[01:46] <carlos> -        elif count > 1:
[01:46] <carlos> -            raise RuntimeError("Duplicate PO file name.")
[01:46] <carlos> -        else:
[01:46] <carlos> -            return results[0] 
[01:46] <spiv> That looks much better :)
[01:47] <daf> definitely :)
[01:47] <daf> we have lots of similar code
[01:47] <carlos> daf: I'm fixing it now
[01:48] <daf> where is byName defined?
[01:48] <spiv> daf: by setting alternateID in the column def.
[01:48] <spiv> carlos: You haven't updated the SQLObjectGuide?  I can do that now if you like?
[01:48] <daf> aha
[01:48] <carlos> spiv: no, It's a pending task
[01:49] <carlos> spiv: I'm busy now, so if you can do it now, it's yours
[01:49] <spiv> Ok, I will.
[01:49] <daf> I think there's some code which follows the old pattern which can't be changed so easily
[01:49] <daf> because the uniqueness is conditional
[01:50] <carlos> daf: I only added the alternateID when it's unique in the database
[01:50] <daf> carlos: of course
[01:50] <carlos> hmmm and I did a mistake with poTemplate (we have a bug with the old code also) a template name is not unique 
[01:51] <daf> I'm just saying that we can't fix all our code in the same way
[01:51] <carlos> it's only unique inside a product
[01:51] <daf> true
[01:53] <carlos> daf: the database has it still incorrectly
[01:53] <daf> thanks
[01:56] <carlos> stub: could you apply this?: ALTER TABLE POTemplate DROP CONSTRAINT potemplate_name_key;
[01:59] <stub> Can I put that in with the indexes?
[01:59] <carlos> stub: sure
[01:59] <carlos> I will send you the final list
[02:00] <carlos> daf: could I remove xxxRosetta... classes?
[02:08] <daf> please do
[02:10] <carlos> ok
[02:32] <carlos> stub: a new import of a po file (all rows are inserted) with your indexes took about 4 extra minutes than with the indexes I sent :-O, I need to do more testing to get an average
[02:34] <stub> Don't worry - I think that answers my question. It is trivial to change indexes later anyway since there are no dependancies outside postgresql.
[02:35] <stub> I'll stick in the indexes and the dropped key in a minute.
[02:35] <carlos> stub: wait, I'm doing more tests
[02:35] <carlos> stub: that's the time needed to create new rows
[02:35] <carlos> I'm doing now the tests using those indexes
[02:35] <stub> oic
[02:36] <carlos> daf: rocketfuel has now the needed patch so the alternateID works now as it should
[02:42] <daf> cool
[02:45] <ddaa> hi spiv
[02:45] <ddaa> I got started on the twisted process handling thing.
[02:45] <spiv> Going well, I hope?
[02:46] <ddaa> I'm doing the simple case right now, running  a command whose exit status is expected to be 0, and which yields no interesting output.
[02:46] <ddaa> I'm mostly putting up the infrastructure at this point...
[02:47] <ddaa> So, the plan is the codes which calls pyarch expects to be in a thread, that thread will sleep until the process is finished.
[02:47] <ddaa> Process handling is done in the reactor of course.
[02:48] <ddaa> The process can terminate  two ways:
[02:48] <ddaa> 1. Everything's okay, unblock the thread.
[02:48] <ddaa> 2. Something went wrong, raise ExecProblem in the thread.
[02:49] <ddaa> Do you have hints about the right way to do that?
[02:51] <ddaa> Sounds like a job for Deferred. What concerns me is that I am not sure that twisted provides any way to blocking communication...
[02:52] <ddaa> I might just pass the exit status out to the thread through a synchronized queue, but there might be something more twistedish.
[03:00] <carlos> lalo: canonical.rosetta.pofile.DEBUG does not exists
[03:00] <lalo> carlos: indeed
[03:00] <lalo> oh, I'll be damned, I didn't commit the patch that removes that reference
[03:01] <carlos> lalo: also, the poparser is broken now
[03:01] <carlos> and this morning was working
[03:01] <lalo> broken?
[03:01] <carlos>     transl = self.translation_factory(header=self.header,
[03:01] <carlos>   File "/home/carlos/Work/dists/launchpad/lib/canonical/rosetta/pofile_adapters.py", line 412, in __call__
[03:01] <carlos>     raise POInvalidInputError
[03:01] <carlos> canonical.rosetta.pofile.POInvalidInputError: Po file: invalid input on entry at line 277
[03:01] <carlos> lalo: I was timing it and the only difference between executions is a star-merge
[03:02] <carlos> gnome-applets-2.0.pot
[03:02] <ddaa> spiv: hints? Do you think a synchronized queue is the way to go? Can you think of a better way?
[03:04] <carlos> #: battstat/battstat_applet.c:391
[03:04] <carlos> #, c-format
[03:04] <carlos> msgid "%d minute (%d%) remaining"
[03:04] <carlos> msgid_plural "%d minutes (%d%) remaining"
[03:04] <carlos> msgstr[0]  ""
[03:04] <carlos> msgstr[1]  ""
[03:04] <carlos> lalo: the line #277 is the c-format
[03:11] <daf> "The rosetta-users@lists.ubuntu.com mailing list has -1 request(s) waiting for your consideration" - ?!?
[03:12] <SteveA> daf: we don't need the ProxyPassReverse configuration, just the ProxyPass configuration
[03:13] <SteveA> Zope 3 itself takes care of the ProxyPassReverse stuff
[03:13] <carlos> daf: who is using it already? :-P
[03:13] <SteveA> but, it does no harm
[03:13] <spiv> ddaa: just a sec
[03:14] <spiv> ddaa: Yeah, getting the thread to block on a Queue.Queue is the simplest way.
[03:14] <lalo> carlos: I'm looking into it, let me merge
[03:15] <ddaa> spiv: thanks
[03:15] <spiv> Deferreds aren't something you'd want to pass between threads, btw.
[03:16] <ddaa> I'll keep that in mind... but do not believe i understand most of what I say when I speak twisted... :-)
[03:16] <spiv> There has been some discussion on the mailing list about better facilities for interacting with threads, but nothing in the code yet, and I'm not sure it would help this particular case anyway.
[03:17] <spiv> Or rather, I don't think it would offer significant benefits over using the standard Queue module in this case ):
[03:17] <spiv> er, :)
[03:17] <ddaa> I'm going to have more elaborate requirements soon.
[03:18] <ddaa> Next step is passing one chunk of output in addition to the status.
[03:18] <spiv> ddaa: fwiw, I get the feeling that you think Twisted is more complex than it really is (which is a pretty common reaction), but that's just a guess :)
[03:18] <spiv> (Of course, my perspective on the complexity of twisted is somewhat biased, I guess)
[03:18] <ddaa> Then multiple chunks... I will end up with  a simple type-based protocol through the queue.
[03:19] <spiv> Right, a queue definitely sounds like the right thing, then.
[03:19] <carlos> lalo: ok, thanks
[03:19] <ddaa> Twisted is a big chunk. I'm beginning to grok it, but I ask you in case I'm missing some useful facilities.
[03:20] <spiv> The main thing I think you might be missing about Twisted atm is Deferreds.  They are actually really simple, although it seems hard to explain this to people ;)
[03:21] <ddaa> he, that's why I was asking "would a Deferred be more appropriate"
[03:21] <spiv> Right :)
[03:22] <ddaa> Ho btw, how can I know what are the reserved names in ProcessProtocol?
[03:23] <ddaa> atm I'm making all the instance variable privates to be safe, but that's almost certainly overkill.
[03:24] <ddaa> The twisted API doc seriously lacks documentation for instance variables...
[03:24] <spiv> Just connected and transport, I think.
[03:24] <spiv> (aside from the actual method names, of course ;)
[03:25] <ddaa> Is there a particular convention in Twisted for "instance variable names which are safe to use in subclasses"?
[03:25] <spiv> Nope.
[03:26] <spiv> It hasn't proven to be a problem, which I find interesting.
[03:26] <carlos> daf: the canonical wiki is moving to wiki.canonical.com
[03:27] <daf> carlos: I didn't know that
[03:27] <carlos> daf: that's why I tell you it :-)
[03:29] <carlos> daf: the draft is ok for me
[03:29] <carlos> see you later!!
[03:29] <daf> later :)
[04:31] <dilys> Bug 2030 resolved: After authenticate, launchpad fails with a system error
[04:35] <carlos> stub: psycopg.ProgrammingError: ERROR:  date/time value "current" is no longer supported
[04:35] <carlos> UPDATE POMsgIDSighting SET inlastrevision = 't', datelastseen = 'CURRENT_TIMESTAMP AT TIME ZONE ''UTC''' WHERE id = 79
[04:36] <stub> Yup - looks like SQL object is quoting it as a string. 
[04:38] <stub> I recall trying it too and failing - it will need a patch to do properly, unless someone works out a string that postgresql parses as 'current time in utc'
[04:38] <spiv> Maybe try sqlobject.sqlbuilder.SQLConstant, or something like that?
[04:39] <stub> Sounds promising - I'm not very well read in the sqlobject api. I couldn't see anything in the postgres docs that would help before, but another pair of eyeballs is good.
[04:40] <spiv> Or else:
[04:41] <spiv> class NowUTC:
[04:41] <stub> Oh... soyuz had a similar issue and they are just passing datetime.utcnow() (with XXX: comments to fix later)
[04:41] <spiv>     def __sqlrepr__(self): return "CURRENT_TIMESTAMP AT TIME ZONE 'UTC'"
[04:41] <spiv> ?
[04:41] <spiv> (untested!)
[04:42] <spiv> But that's ok, I'll bet that banana is untested too ;)
[04:42] <stub> You wouldn't want it after I've tested it ;)
[04:42] <carlos> then ? datetime.utcnow()?
[04:43] <stub> carlos: Try spiv's approach
[04:43] <carlos> should I create that class? or where is it defined?
[04:44] <lalo> carlos: gnome-applets imports correctly for me
[04:44] <stub> carlos: You would have to create it (canonical.database somewhere I guess). Pass an instance of it through in the constructor and see if it works.
[04:45] <carlos> lalo: I'm fixing a bug I introduced to be able to test it
[04:45] <lalo> ok
[04:45] <carlos> stub: I prefer if you suggest me a place instead of choose one random place under database :-P
[04:46] <stub> canonical.database.__init__.py ?
[04:47] <carlos> ok
[04:47] <spiv> I'd vote for canonical.database.constants, but that's just because I tend not to put code in __init__.py files...
[04:48] <stub> We probably want a single instance of it as a module global rather than having to construct an instance of it every time.
[04:48] <stub> spiv: Sounds good. I'm not fussed :-)
[04:51] <carlos> then? canonical.database.constants?
[04:51] <carlos> and how could be done the single instance?
[04:51] <daf> a singleton?
[04:52] <carlos> daf: ?
[04:54] <daf> actually, a singleton isn't necessary
[04:54] <kiko> morning
[04:54] <daf> hi kiko!
[04:54] <kiko> https://rosetta.ubuntulinux.org/projects/gnome/gnome-panel
[04:54] <kiko> raises an error, daf :)
[04:54] <daf> yeah, it does
[04:55] <carlos> kiko: morning
[04:55] <kiko> how are you guys doing?
[04:55] <kiko> daf, the only comment on the release would be having something about bugreporting in the Caveat section, but since you already have a Bug section there..
[04:56] <daf> kiko: hmm, maybe I could amalgamate those two
[04:57] <daf> carlos: the single instance could be done just with having "nowUTC = NowUTC()" in the module
[04:58] <carlos> daf: so, it's a global var
[04:58] <daf> carlos: module global
[04:58] <daf> carlos: canonical.database.constants.nowUTC
[04:58] <daf> (not sure if my terminology is correct here)
[04:58] <carlos> and I will need to do from canonical.database.constants import nowUTC
[04:58] <carlos> ok
[04:59] <daf> actually
[04:59] <daf> I think you might as well just stick it in canonical.database
[04:59] <kiko> daf, I don't think it's critical, rock and roll it
[04:59] <daf> kiko: I'm not sure whether I should push the Big Red Button without getting sabdfl's stamp of approval
[05:00] <kiko> daf, you should wait for mark, really. give him a call?
[05:00] <daf> kiko: sure, I could do, but it would be nice to have him look at the doc
[05:01] <spiv> (I'd call the class _NowUTC, and the instance NowUTC)
[05:01] <kiko> daf, calling him is a good way of getting attention :)
[05:01] <daf> kiko: his ADSL is down
[05:01] <daf> kiko: and probably will be until tomorrow
[05:01] <kiko> daf, fax it.
[05:01] <daf> :D
[05:01] <daf> I don't have a fax :(
[05:01] <kiko> but your neighbor does
[05:02] <daf> they do?!
[05:02] <daf> they never told me
[05:04] <kiko> just print it out and bike down to the print shop, or have your kid sister do it
[05:05] <daf> I think I'm going to reorganise the server, so we may experience a little turbulence
[05:07] <carlos> daf: :-)
[05:08] <kiko> soyuz team fastens seatbelts
[05:09] <daf> I'll do rosetta.w.h.c first
[05:20] <daf> ddaa/lifeless: "tla changes" is not printing permissions changes -- is this normal?
[05:20] <ddaa> Looks like there is a bug in tla.
[05:21] <ddaa> You need to touche the files for the perms change to be detected.
[05:21] <daf> ewwwww
[05:21] <ddaa> Assuming of course you are not using a hardlinked-to-revlib tree.
[05:21] <daf> I might be
[05:21] <daf> how do I find out?
[05:22] <ddaa> Check the link count of files in your tree with "ls -l"
[05:22] <daf> ok, I'm not
[05:22] <ddaa> But if you do not know, you are probably not.
[05:22] <ddaa> That's a dangerous feature,but useful because it really boosts change detection.
[05:22] <daf> dangerous?
[05:23] <ddaa> Can corrupt the revlib.
[05:23] <daf> because you can inadvertantly change the revlib
[05:23] <daf> right
[05:23] <ddaa> In addition, perms changes in the revlib are not detected, so that can cause inconsistent permission info to be put in the archive.
[05:24] <ddaa> These are relatively trivial and well known bugs.
[05:24] <daf> if they're trivial, why are they not fixed? :)
[05:24] <daf> let me guess:
[05:24] <ddaa> Same reason as usual :-)
[05:24] <daf> because the release process is f*cked?
[05:24] <spiv> daf: touchy subject ;)
[05:24] <ddaa> Ho, that's not the specific reason.
[05:24] <ddaa> Here it's "because no one has bothered yet".
[05:25] <daf> grumble
[05:26] <ddaa> daf: feel free to step up.
[05:26] <ddaa> This stuff is amply documented in the mailing list archives.
[05:27] <daf> I don't think I have the time to tackle it right now
[05:27] <ddaa> Essentually, the trick would be to change the inode-sigs to account for permissions.
[05:28] <daf> if I took the time to read the mailing list archives and get up to speed on the code, I might be able to fix it
[05:29] <ddaa> daf: I not you volunteering as stable release manager :-P
[05:29] <ddaa> *I note your
[05:29] <SteveA> spiv: pig
[05:29] <SteveA> spiv: piNg
[05:30] <lifeless> ddaa: that was already done in a patch IIRC
[05:30] <spiv> SteveA: pog :)
[05:30] <lifeless> might be in the buggoo
[05:30] <SteveA> did you update your interface in the authserver?
[05:30] <spiv> SteveA: Oh, hmm!
[05:30] <spiv> Oops, no.
[05:31] <SteveA> also, it should state the contents of a user dictionary
[05:32] <ddaa> lifeless: good news, I'm getting somewhere with the twisted process handling. I will probably not finish before I leave, but then it's going to be mostly a matter of filling the blanks.
[05:32] <spiv> Ok, I'll fix that now.
[05:33] <SteveA> also, what does createUser do if the email address is already taken?
[05:37] <spiv> Return {}
[05:40] <spiv> (it relies on the db constraints to enforce that; it will catch the resulting error, rollback the transaction and fire the error callback which returns {})
[05:43] <SteveA> ok, that needs to be in the interface
[05:43] <SteveA> it just said TBD
[05:43] <daf> ddaa: I tried an amateur analysis of the current PQM confusion with carlos' launchpad--devel--0-patch-183..186, but couldn't work out why it was happening
[05:43] <daf> ddaa: most of my analysis consisted of running "tla missing"
[05:44] <spiv> Right, because I wasn't sure I wanted that to be the final behaviour :)
[05:44] <spiv> (Hence the discussion of error handling in the bug)
[05:44] <spiv> (TBD == To Be Defined in this case, which I realise now is not necessarily clear)
[05:44] <ddaa> daf: the trick to unwedge the merge is to:
[05:45] <ddaa> 1. tla revisions, write down the latest revision R in rocketfuel
[05:45] <lifeless> ddaa: this isn't a wedged merge
[05:45] <ddaa> ?
[05:45] <ddaa> Something new?
[05:45] <lifeless> this is rocketfuel log-for-merges being wedgified.
[05:46] <lifeless> grab rocketfuel
[05:46] <lifeless> do a star-merge with your branch, or anyones
[05:46] <lifeless> log-for-merge will show carlo's patches.
[05:46] <lifeless> If carlos has new patches, try merging them in, that might unwedge it.
[05:46] <ddaa> I thought that issue was fixed...
[05:47] <lifeless> ddaa: hahahahaha
[05:47] <lifeless> if it doesn't, then I can sync-tree with those patches manually.
[05:47] <lifeless> which I've had to do 3 times now.
[05:47] <lifeless> I would love to have the time to sit down and do the forensics on the cause.
[05:47] <spiv> This is seperate to the crossing-the-streams issue?
[05:48] <lifeless> yes
[05:48] <lifeless> AFAICT
[05:48] <ddaa> I bet carlos is unwedging merges with --skip-present and do not do sync-tree
[05:48] <ddaa> That would explain the missing patchlogs.
[05:48] <daf> carlos: accusations are being made!
[05:48] <carlos> ddaa: I did the sync-tree yesterday
[05:48] <lifeless> well, I'm not aking bets until I do the forensics.
[05:48] <lifeless> carlos: you should not need to sync tree ever.
[05:48] <carlos> lifeless: I did the --skip-present
[05:49] <lifeless> why?
[05:49] <carlos> because my repository was broken
[05:49] <carlos> but I'm sure I did not a star-merge before the merge request ended
[05:49] <lifeless> asctually, tell ddaa. Its 2am on friday night, I'm not up to this.
[05:50] <spiv> lifeless: G'night :)
[05:50] <daf> lifeless: enjoy your weekend :)
[05:51] <carlos> lifeless: night
[05:53] <ddaa> carlos, care to describe what was your problem and what you did to fix it?
[05:53] <ddaa> Not pretending I'll give you a better solution, but that will help me figure out what's going on.
[05:54] <carlos> ddaa: the problem is the same you help me fixing in Oxford
[05:54] <carlos> and I fixed it in the same way, but the sync-tree command was new for me and I executed it after lalo suggestion
[05:55] <carlos> so it was one or two days after the break
[05:55] <ddaa> okay
[05:55] <ddaa> You are aware of the racy nature of that command?
[05:55] <ddaa> and how you should always use it with a fqrev when syncing against a shared branch?
[05:56] <carlos> ddaa: no, could you explain it to me?
[05:56] <lifeless> OH GOD NO.
[05:56] <lifeless> Please guys.
[05:56] <lifeless> DO NOT share 'FIXES' amongst the team.
[05:56] <lifeless> thats like going to a friend who had a broken leg and asking for help with your sore stomach.
[05:56] <ddaa> lifeless: people are doinh that anyway already
[05:56] <lifeless> Ask ddaa/me/jblack/bob2
[05:57] <ddaa> better tell them the whole story so they are not going to shoot their foot
[05:57] <lifeless> PLEASE.
[05:57] <lifeless> your scheduled analysis can now resume, thank you for your attention.
[05:57] <ddaa> Okay...
[05:58] <carlos> lifeless: well, the --skip-present solved my problem as the arch team told me, I thought the sync-tree was to help with the logs errors, sorry about that
[05:58] <kiko> lifeless, it's very hard to know what is and what isn't appropriate to do when fixing a tree.
[05:58] <lifeless> carlos: you should not perform any 'fix' without someone from the arch team.
[05:58] <ddaa> carlos: that's essentially right. But sync-tree is dangerous.
[05:58] <lifeless> kiko: ^^^
[05:58] <kiko> sure, but somebody has deadlines to meet and a broken repo means delays.
[05:59] <lifeless> kiko: we're working to reduce the number of problems you have, by introducing better procedures & workflow.
[05:59] <daf> kiko: anything other than what you would do during the normal development cycle is suspect
[05:59] <ddaa> What it does: get all the patchlogs from the given REVISION  and put them into the tree.
[05:59] <carlos> lifeless: then, the is it ok if I execute --skip-present if I get this kind of break or should I ask always arch team?
[05:59] <lifeless> carlos: do not execute skip-present.
[05:59] <lifeless> its not the merge operator we use.
[05:59] <kiko> I'm just saying you can't reasonably expect the developer to do whatever he can to get things fixed, so it's something to watch out for.
[05:59] <daf> carlos: if in doubt, ask
[05:59] <kiko> I understand
[06:00] <lifeless> kiko: we have roughly 24x7 coverage: GMT +10 -> GMT - 8
[06:00] <carlos> lifeless: I only execute it when arch tries to apply again the same patch I already have in my tree
[06:00] <ddaa> If this adds some patchlogs for a revision that you have not yet merged, what get effectively recorded in "star-merge perspective" is "applied the patches then reverted the changes".
[06:00] <lifeless> carlos: it won't do that if you follow the star-merge rules published a fortnight back.
[06:00] <lifeless> but please, chat with ddaa.
[06:00] <carlos> lifeless: ok
[06:01] <ddaa> So a later star-merge into rocketfuel will remove from rocketfuel the changes you skipped.
[06:01] <lifeless> I wanted to get the point in that: *what fixes lalo's tree is likely to break carlos' tree. Unless you understand the cause, choosing the solution is impossible'.
[06:01] <carlos> ddaa: then, I broke any patch from rocketfuel?
[06:02] <carlos> :-(
[06:02] <ddaa> not saying that
[06:02] <daf> lifeless: go to bed!
[06:02] <ddaa> sayinh that using sync-tree is dangerous
[06:02] <carlos> ok
[06:02] <ddaa> and that you have to be aware of the danger before usinh it
[06:03] <ddaa> What is safe to do, and that hopefully you did, is to sync-tree to a revision you are up to date to.
[06:04] <ddaa> wait a min please
[06:06] <carlos> spiv: class NowUTC:
[06:06] <carlos>     def __sqlrepr__(self, dbName):
[06:06] <carlos>         return "CURRENT_TIMESTAMP AT TIME ZONE 'UTC'"
[06:06] <carlos> nowUTC = NowUTC()
[06:07] <spiv> carlos: ...and does it work? :)
[06:07] <carlos> spiv: __sqlrepr__ asked for a second argument
[06:07] <spiv> Oh, right.
[06:07] <carlos> python does not fails :-)
[06:07] <spiv> Ignoring that is fine for us :)
[06:09] <carlos> hmmm
[06:09] <carlos> the select from psql gives me the date in my UTC+0200
[06:09] <carlos> daf: how was the command to change the zone?
[06:10] <carlos> LC_TIMEZONE=UTC foo ?
[06:10] <spiv> TZ?
[06:10] <carlos> TZ=UTC ?
[06:11] <spiv> Probably.
[06:11] <spiv> $ TZ=UTC date
[06:11] <spiv> Fri Sep 24 16:10:57 UTC 2004
[06:11] <carlos> hmm
[06:11] <carlos> then it's not working
[06:11] <carlos> or psql does not cares about that env var
[06:14] <daf> I'd suspect the latter first
[06:14] <carlos> hmm
[06:14] <carlos> ok, it's postgresql which should be restarted with TZ=UTC...
[06:15] <daf> hmm
[06:16] <carlos> no
[06:16] <carlos> I get always the same date
[06:16] <carlos> and I executed tzconfig
[06:16] <carlos> changing my timezone to UTC
[06:16] <carlos> and restarted postgresql
[06:17] <carlos> and I got the same date that I'm sure is not UTC
[06:17] <carlos> because now it's 16:18 UTC
[06:17] <carlos> and the date is 17:10
[06:17] <carlos> so that's impossible
[06:18] <carlos> but it's not a sqlobject problem
[06:18] <carlos> UPDATE POMsgIDSighting SET inlastrevision = 't', datelastseen = CURRENT_TIMESTAMP AT TIME ZONE 'UTC' WHERE id = 1359
[06:19] <carlos> that's the query that it's executed
[06:22] <spiv> looks ok here...
[06:26] <spiv> carlos: show TimeZone;  ?
[06:26] <carlos> from psql?
[06:26] <spiv> Yeah.
[06:27] <carlos>  TimeZone
[06:27] <carlos> ----------
[06:27] <carlos>  unknown
[06:27] <carlos> (1 row)
[06:28] <SteveA> stub: hi
[06:28] <SteveA> just been chatting with mark, then with jim, about sessions of various kinds
[06:30] <SteveA> I want to put some kind of cookie-based auth into launchpad soonish
[06:31] <stub> carlos: Are you getting localtime in the database, or some sort of random time?
[06:31] <carlos> stub: local time
[06:31] <SteveA> mark wants to talk about doing session-based auth for xml-rpc clients.  Personally, I'd prefer that they authenticated on each request.  cookie auth in the browser is for usability (nice login forms) and so that you can authenticate across domains.
[06:32] <stub> SteveA: Cookie based auth should be doable by simply storing the authenticated username in the standard session implementation (either using the ZODB or the Memory implementation as appropriate).
[06:32] <SteveA> in jim's "client stores last access time" model, the session id held by the client changes on each request.  You need to trust the client to do this right, but if they don't, they can only make their session expire sooner.
[06:33] <SteveA> stub: yep, i guess so.
[06:33] <stub> SteveA: I've never quite worked out how Jim's model is supposed to work. Because the client stores the last access time, the server doesn't have it when it needs to clean up.
[06:33] <SteveA> I've done that for a zope3 application before.  it was okay.  I had to implement various parts of the session stuff iirc, as they weren't implemented in zope3.
[06:34] <SteveA> the server doesn't need it when it needs to clean up.
[06:34] <SteveA> the server cleans up regardless
[06:34] <stub> Yup - which means it might clean up an active session
[06:34] <SteveA> the server and its GC says "Your session will last at least 48 hours.  I'll clean up some time after 48 hours."
[06:35] <SteveA> the app can look at the session of a request and say "this session expires in under 1 hour.  I'd better make a new session and copy the old data to it."
[06:37] <stub> ok - that makes sense. The Z3 API doesn't have to change to accommodate that either.
[06:37] <SteveA> it was the component that stores the data
[06:39] <stub> SteveA: Actually, with that model there is a race condition. The browser is sending 4 requests simultaneously. All will be dealing with the old session data (as no fresh token has been returned yet). Only one of the new sessions will take effect.
[06:40] <stub> And any changes made in 3 of those 4 requests to the old-session will be lost.
[06:41] <SteveA> hmm
[06:41] <SteveA> yeah
[06:41] <SteveA> well, what if you put a "see new" pointer in the old session?
[06:42] <stub> It would work if we just kept the same session alive, updating a the expiry time. Which is pretty much what we have implemented already.
[06:42] <stub> Just change the defaults from a 1 hour expiry with a precision of 5 minutes to a 48 hour expiry with a precision of a few hours.
[06:43] <stub> (Or a precision of 48 hours even)
[06:47] <ddaa> Mh... indeed something is borked on rocketfuel
[06:47] <kiko> ddaa, ouch.
[06:47] <ddaa> i mean, regarding the missing patchlogs
[06:48] <ddaa> nothing serious
[06:50] <daf> ddaa: you've worked it out?
[06:50] <ddaa> not yet... and I'm going to have to leave soon.
[06:50] <ddaa> I'll check when I come back.
[06:50] <daf> no worries
[06:58] <ddaa> that's it...
[06:59] <ddaa> in patch-394, the patch-369 was removed
[06:59] <ddaa> patch-394 is the merge from carlos immediately following patch-369
[07:00] <carlos> ddaa: O:-)
[07:00] <carlos> ddaa: then, did I reverted a patch?
[07:01] <ddaa> I guess not...
[07:02] <ddaa> I have not checked that.
[07:02] <ddaa> When did you use sync-tree, btw?
[07:02] <carlos> hmm
[07:02] <carlos> I'm not sure, I think it was on Wednesday
[07:03] <ddaa> archer do not have calendars, they count time in patchlogs ;-)
[07:04] <carlos> ddaa: but I suppose we could see it from the time for that patch
[07:04] <carlos> a 'ls' in chinstrap
[07:04] <ddaa> patch dates are not accurate they are set by the client ;-)
[07:05] <carlos> ddaa: I can certify you that my computer clock is correct, I'm using ntp to sync it
[07:05] <carlos> :-)
[07:05] <ddaa> is it set on UTC or on GMT?
[07:06] <carlos> UTC+0200
[07:06] <ddaa> are you sure your computer's clock is not set to GMT+0200?
[07:07] <daf> ddaa: seriously, the difference between UTC and GMT should not be affecting our use of Arch...
[07:07] <ddaa> daf: :-D yeah, I was just havinh some fun... that thread on gau was stupid.
[07:07] <daf> ddaa: phew, I thought you were being serious :D
[07:08] <spiv> daf: it's affecting your use of archers ;)
[07:08] <carlos> ddaa: isn't it the same?
[07:08] <carlos> :-P
[07:08] <ddaa> carlos: there's a whole thread on gau about the difference between UTC and GMT
[07:08] <daf> carlos: yes and no :)
[07:08] <carlos> ok, it's the same, I prefer to live in the ignorance
[07:08] <carlos> :-D
[07:09] <daf> :)
[07:09] <stub> So UTC isn't just GMT after the French got through with it?
[07:09] <ddaa> That mostly matter if you are interested in unnatural acts involving insects.
[07:13] <ddaa> merge request on the way
[07:15] <ddaa> carlos are you using a local mirror?
[07:15] <ddaa> for rocketfuel?
[07:16] <carlos> ddaa: yes
[07:16] <ddaa> when do you update it?
[07:16] <carlos> a revision-library
[07:16] <carlos> I suppose it's done automatically
[07:16] <ddaa> Pardon?
[07:19] <ddaa> So, you are not using a local mirror?
[07:19] <ddaa> A revision library is a different thing....
[07:20] <ddaa> rats... gotta go now.
[07:22] <carlos> ok
[07:22] <carlos> so it's not a local mirror
[07:24] <ddaa> care to send me the output of "tla archives | grep rocketfuel" privately?
[07:25] <carlos> ok
[08:53] <carlos> daf: Could I assume that rosetta will be announced after the weekend?
[09:03] <carlos> we have  a regression with the poimporter
[09:06] <daf> a regression?
[09:06] <daf> which bug?
[09:07] <dilys> New bug 2035 for Launchpad/Rosetta: PO parser broken (again)
[09:07] <carlos> well, I filed a new bug because I'm not sure if it's the same
[09:07] <daf> ok
[09:07] <carlos> it's the generic parser error
[09:07] <carlos> and breaks any .po file import
[09:07] <carlos> the .pot file works
[09:07] <spiv> gnu-arch-users has been, uh, entertaining recently.
[09:08] <daf> carlos: do you know which line is causing the error?
[09:09] <daf> carlos: do the PO file test cases pass?
[09:11] <carlos> make check pass
[09:11] <daf> can you find out the smallest PO file that exhibits the error?
[09:12] <carlos> #: charpick/GNOME_CharpickerApplet.server.in.in.h:2
[09:12] <carlos> msgid "Charpicker Applet Factory"
[09:12] <carlos> msgstr "Ffatri Rhaglennig Dewis Nodau"
[09:12] <carlos> it fails in that msgstr
[09:12] <daf> ?!
[09:12] <carlos> I don't see any thing different there...
[09:12] <carlos> daf: will investigate it
[09:12] <daf> there must be something like that in our unit tests
[09:13] <daf> try adding a unit test with just that message set and see if it still fails
[09:14] <daf> I mean, if it still passes
[09:14] <daf> well, I suppose you can look at it either way: either the unit tests still succeed, or that message still fails
[09:17] <carlos> daf: ok
[09:18] <daf> I've just tried that, and it worked for me
[09:18] <carlos> daf: so the problem is not that msgset
[09:19] <spiv> carlos, daf: I've uploaded a patch to that bug that might help diagnosis slightly.
[09:19] <carlos> spiv: thanks
[09:22] <daf> carlos: or the adapters are causing it to fail in some mysterious way
[09:22] <daf> carlos: which file are you testing with?
[09:22] <carlos> I was testing the import of all gnome-applets .po files
[09:22] <carlos> and all failed
[09:23] <daf> ok
[09:23] <spiv> (Incidentally, both KeyError and IndexError inherit from LookupError, so that except clause could be slightly simpler)
 :)
[09:23] <daf> spiv: patches welcome :)
[09:23] <carlos> the ones without a plural expression had a warning that it's not available but the exception was raised and the ones with the plural forms expression only raised the exception
[09:26] <daf> carlos: try seeing if you can replicate the same error without the importer?
[09:27] <carlos> daf: without the importer?
[09:27] <carlos> ooh only with the parser
[09:27] <carlos> good idea
[09:30] <carlos> what????
[09:30] <carlos> daf: it worked now
[09:30] <spiv> carlos: Eek.
[09:30] <carlos> the only change I did was spiv's patch
[09:30] <carlos> it makes no sense...
[09:37] <spiv> TemplateImporter and POFileImporter have a scary amount of duplicated (and nearly duplicated) code.
[09:39] <carlos> spiv: are more or less same code
[09:40] <carlos> so it's normal that the code is duplicated, if it's a way to improve it... ask lalo
[09:43] <spiv> Well, it's just an impression I get from glancing at it, not an informed opinion :)
[09:47] <carlos> daf: I think that it's related with the header and the database
[09:48] <carlos> daf: first time you try to import the .po file fails
[09:48] <carlos> seconde try success
[09:48] <carlos>  /s/seconde/second/
[09:48] <SteveA> spiv: do you know if there are any important passwords in the golden database yet?
[09:49] <carlos> I should leave now, Will look at it later
[09:53] <carlos> spiv: I don't see any extra information with your patch...
[09:53] <carlos> File "/home/carlos/Work/launchpad/lib/canonical/rosetta/pofile.py", line 461, in append
[09:53] <carlos>     transl = self.translation_factory(header=self.header,
[09:53] <carlos>   File "/home/carlos/Work/launchpad/lib/canonical/rosetta/pofile_adapters.py", line 505, in __call__
[09:53] <carlos>     raise POInvalidInputError, e
[09:53] <carlos> canonical.rosetta.pofile.POInvalidInputError
[09:54] <carlos> ok, I got the wrong patch :-P
[10:00] <carlos> later
[10:48] <spiv> carlos: Oops :)
[10:51] <spiv> SteveA: Doesn't look like it.
[10:53] <spiv> SteveA: The only people in the DB so far are Mark Shuttleworth, Robert Collins, Roche Compaan, Roche Compaan, Andrew Test, Steve rle Alexander testing, apasto, Roche TestX7 -- and the first two don't have pards.
[10:53] <spiv> s/pards/passwords/
[11:28] <SteveA> ok.  Any idea how hard it would be to discard existing passwords, and increase the size of the salt in the passwords for code that touches the golden database?
[11:28] <SteveA> We can change the code in the plone product easily enough, and send roche a patch
[11:28] <SteveA> we can change the code in launchpad easily enough
[11:28] <spiv> delete from person where password is not null; is pretty easy ;)
[11:29] <spiv> Actually, you'd need to delete the emailaddress entries too, but that's still not hard.
[11:31] <SteveA> do you still have access to the plone server code?
[11:36] <spiv> You mean the authserver on macquarie?
[11:36] <spiv> (if so, the answer is yes)
[11:44] <SteveA> no, I meant the plone website code
[11:45] <carlos> SteveA: night
[11:46] <spiv> I've never had access to that.