[12:04] <carlos> I don't think that template fits that definition
[12:04] <flacoste> ok
[12:05] <carlos> at least that's what I understand from that README
[12:05] <carlos> flacoste: if you have doubts, send an email to launchpad mailing list
[12:05] <flacoste> ok, will do
[12:05] <carlos> anyway, I suppose it would be quite similar to the specificationtarget one
[12:07] <LarstiQ> also, 'some arch branch' seems to indicate that is a very old readme
[12:08] <mpt> carlos, I think blue clothespegs should be banned -- they always break before the other colors do
[12:09] <mpt> What are you talking about? :-)
[12:10] <carlos> * flacoste wondered if ../templates/person-spec.pt (which seems unused now) has been obsoleted by specificationtarget-specs.pt
[12:10] <carlos> mpt: ^^^
[12:11] <carlos> mpt: I know you already removed some templates that were not used
[12:11] <carlos> or at least I remember that you complained about them
[12:11] <mpt> yes, I've deleted templates before, and I will do so again
[12:12] <LarstiQ> mpt: there is no stopping you ;)
[12:12] <mpt> The GTK filepicker takes 10~15 seconds to load the contents of templates/, so I'm biased towards reducing their number
[12:13] <mpt> flacoste, delete it, see if all the tests pass, and if they do, land it
[12:14] <flacoste> mpt: ok, will do...
[12:14] <mpt> if anything breaks, blame it on insufficient test coverage ;-)
[12:14] <flacoste> lol
[12:14] <flacoste> ...but that's an item for tomorrow
[12:15] <mpt> LarstiQ, it would be easier to understand if the places list was a drop-down menu, I think
[12:15] <flacoste> good evening Launchpadders
[12:15] <mpt> One of the great advances from Windows 3.1 to Windows 95 was that the filepickers changed from two pane to one pane
[12:15] <LarstiQ> mpt: the thing I don't understand is why it has to block, the typeahead doesn't work like this
[12:16] <mpt> then ten years later, we start getting two-pane filepickers again
[12:16] <mpt> LarstiQ, doesn't work like what?
[12:17] <LarstiQ> mpt: say you want to pick a different application to handle a file from the web, you typeahead /usr/bin/xmms<enter> and then you have to wait 10 seconds before it does anything
[12:17] <carlos> flacoste: mpt is right, is not our fault if you break something if it's due its lack of testing
[12:18] <carlos> flacoste: unless is your own code... ;-)
[12:18] <kiko> good ole carlos 
[12:18] <carlos> kiko: hi dude!
[12:18] <flacoste> carlos: well, that shouldn't be a problem, i'm new here and i'm a write-the-test first kind of guy
[12:20] <mpt> LarstiQ, oh, yes, I have that problem too, I write the entire filename while I'm waiting for the list, but if I press Enter before the list loads, it's a no-op
[12:20] <carlos> flacoste: hmmm, I think you understood my sentence... but just in case, it's supposed to be 'It's not your fault if you break....'
[12:21] <flacoste> carlos: I did! my comment was about your 'unless is your own code' addition :-)
[12:22] <carlos> ok ;-)
[12:35] <kiko> carlos, I'm going to send you a diff
[12:36] <kiko> carlos, it doesn't work, and it will be some work to get it working, but see why I did it and you'll notice that the design for POMsgSetView and co. needs a serious refactoring!
[12:36] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/fileMZu8Sa.html
[12:36] <carlos> ok
[12:37] <mpt> kiko, there's two possible ways to fix bug 2537 and others like it
[12:37] <Ubugtu> Malone bug 2537 in blueprint "Spec index page is chock full of non-information" [Medium,Confirmed]  http://launchpad.net/bugs/2537
[12:37] <mpt> kiko, one is to put the tal:condition in the callsite
[12:38] <mpt> the other is to put the tal:condition in the outermost element for the portlet template itself
[12:38] <carlos> kiko: hmm, it's a big diff... I don't think I will be able to do the review tonight, I will add it to my todo list for tomorrow. Do you mind?
[12:38] <mpt> The former will make Launchpad a little faster
[12:38] <carlos> kiko: I see that you are fixing several know bugs there
[12:39] <mpt> kiko: while the latter will ensure that the portlet never shows up when it shouldn't (preventing portlet whack-a-mole games)
[12:39] <carlos> kiko: do you have the list of bugs you are trying to fix?
[12:39] <mpt> kiko: Do you have any opinion?
[12:39] <kiko> carlos, no, I'm mostly going to refactor the translation views.
[12:39] <carlos> kiko: btw, I don't think is a good idea to switch alternative language submit from POST to GET....
[12:40] <kiko> carlos, why not?
[12:40] <kiko> mpt, I do the latter.
[12:40] <carlos> kiko: exactly because your comment at:
[12:40] <carlos> +        # Two different variables are used to capture the alternative
[12:40] <carlos> +        # language being displayed. field.alternative_language indicates
[12:40] <carlos> +        # whether we submitted the form containing the alternative
[12:40] <carlos> +        # language. The alt variable indicates an alternative language
[12:40] <carlos> +        # that was selected in another request and has been preserved
[12:40] <carlos> +        # through navigation and _redirect().
[12:40] <kiko> carlos, that can also be fixed.
[12:40] <kiko> carlos, the current design is very very broken.
[12:41] <kiko> that was just a band-aid
[12:41] <carlos> kiko: sure, if you fix it is ok, but don't leave it that way using GET, please ;-)
[12:41] <kiko> it's better to leave it as a GET that way
[12:41] <kiko> than to leave it as a POST with the code as it was.
[12:41] <kiko> the current code is very broken
[12:41] <carlos> so you want to have alt and field.language at the same time??
[12:42] <carlos> I know we already have them
[12:42] <kiko> carlos, well, everything should just use field
[12:42] <carlos> but only 'alt' is visible by the user
[12:42] <kiko> but given that the current code uses alt
[12:42] <kiko> that band-aid is acceptable
[12:42] <kiko> however that diff merges things the way they should be
[12:42] <carlos> ok
[12:42] <carlos> I will take a close look tomorrow
[12:43] <kiko> a) having a view for /just/ the pomsgset
[12:43] <kiko> b) having a view for the pomsgsetpage
[12:43] <kiko> c) having a view for the pofilepage
[12:43] <kiko> d) having a base view for b) and c) which are almost identical
[12:43] <kiko> that would be the proper design for this
[12:43] <kiko> it avoids the is_pofile hack
[12:43] <kiko> and merges a /lot/ of duplicated code
[12:44] <kiko> anyway, I won't have time for this tonight so I will land a lovely bandaid in a second :)
[12:45] <carlos> kiko: you will land???
[12:45] <carlos> kiko: shouldn't you get a review first? (not from me, but from a reviewer)
[12:51] <kiko> carlos, not /that/ patch
[12:51] <kiko> but a simple patch
[12:52] <carlos> ok
[12:54] <kiko> that patch doesn't even work yet!
[01:00] <carlos> that's why I was a bit scared that you wanted to merge it ;-)
[01:00] <carlos> good night!!!
[04:40] <mpt> lifeless, ping
[06:13] <mpt> lifeless, ping
[06:18] <jamesh> mpt: assuming he's still in Paris, it is 5am
[06:31] <mpt> bother
[07:06] <jamesh> spiv: found a bug in SelectResults.__contains__
[07:10] <spiv> jamesh: Ooh
[07:10] <jamesh> spiv: results = Table.select("condition1 OR condition2")
[07:11] <jamesh> spiv: someobject in results
[07:11] <jamesh> the query issued will be of the form "SELECT ... FROM Table WHERE condition1 OR condition2 AND Table.id = NNN"
[07:11] <spiv> Right, it needs parens.
[07:11] <spiv> Nasty bug :(
[07:12] <spiv> Should be doing 'clause = "(%s) AND %s.%s = %d" % (self.clause, ...)
[07:12] <spiv> '
[07:12] <spiv> Rather than what it's currently doing.
[07:14] <spiv> jamesh: I'm amazed we've had that bug for so long without anyone noticing.
[07:23] <jamesh> spiv: filed as https://launchpad.net/bugs/50743
[07:23] <Ubugtu> Malone bug 50743 in launchpad "sqlobject SelectResults.__contains__ generates bad SQL for some conditions" [Untriaged,Unconfirmed]  
[07:25] <spiv> jamesh: thanks
[09:03] <lifeless> kiko-zzz: no
[09:03] <lifeless> mpt__: pong
[09:06] <lifeless> asdasdfgh
[09:12] <SteveA> morn
[09:22] <lifeless> hi SteveA 
[09:23] <SteveA> hello lifeless 
[09:23] <mpt__> lifeless, I've sent mpt/launchpad/trivial to PQM twice today, and it's silently failed both times
[09:25] <mpt__> (it appeared on pqm.launchpad.net both times)
[09:28] <lifeless> mpt__: I'll look for an error now. be 5 - 10 minutes for my mail to sync
[09:28] <mpt__> thanks
[09:39] <lifeless> mpt__: hmm, no sign
[09:42] <sivang> morning all
[09:42] <mpt__> odd
[09:44] <mpt__> ok, it's in the queue again
[10:02] <Yannig> Hello everybody :)
[10:05] <carlos> Yannig: hi
[10:06] <Yannig> carlos> Thanks for the Occitan mailing-list, we do have one now :)
[10:06] <carlos> Yannig: yeah, jdub told me it ;-)
[10:07] <carlos> Yannig: sorry for the long delay
[10:08] <Yannig> It's solved now :)
[10:09] <mpt> lifeless, it just disappeared from the queue with no e-mail again
[10:11] <SteveA> stub: morning.  what shall we do about dooming transactions rather than aborting them?
[10:12] <stub> Assuming this is the reason EditForm is calling abort() (I haven't looked yet), then we need to push this upstream and fix it there I think.
[10:13] <SteveA> stub: http://mail.zope.org/pipermail/zodb-dev/2004-January/006414.html
[10:15] <lifeless> spiv, is it ok if I give you another review to do ?
[10:16] <stub> SteveA: We have a concrete use case here. At the moment there is a bug either in EditForm or in zope.rdb, and I don't think we can fix it without doom()
[10:17] <stub> (Well... I haven't looked at EditForm like I said)
[10:17] <SteveA> i think also that zope's forms may be encouraging bad data to be added upstream
[10:17] <SteveA> when people process the form and also do other stuff
[10:18] <SteveA> we can fix this by having a doom API to the publication that tells the publication to treat the transaction as doomed
[10:18] <SteveA> that's a minimal launchpad-only fix
[10:18] <stub> Why is publication involved?
[10:18] <stub> Ahh
[10:18] <spiv> lifeless: ok
[10:18] <stub> I think the correct fix is transaction.doom(), which makes transaction.commit() a noop until transaction.begin() is called.
[10:18] <SteveA> the best fix i think is to have a doom API for the transaction
[10:19] <stub> Which should be trivial to someone familiar with that code.
[10:19] <SteveA> and that makes transaction.commit() fail with a DoomedTransaction exception
[10:19] <SteveA> the publisher will know to expect this
[10:19] <stub> If an exception is raised, then the publication machinery needs to catch it.
[10:19] <stub> yup
[10:19] <lifeless> spiv: thanks. its the scanner patch from jamesh
[10:19] <SteveA> a transaction.commit() that doesn't should not pass silently
[10:20] <stub> I'd like to get it fixed properly rather than a launchpad specific hack, as that would involve diverging our zope code needlessly.
[10:20] <stub> Especially if you can convince Jim to do it for you ;)
[10:20] <mpt> hrmmmmmm
[10:20] <SteveA> we'll have to do the work
[10:21] <mpt> I haven't received any launchpad-related mail in the last 11 hours and 57 minutes
[10:21] <mpt> or ubuntu-related...
[10:21] <lifeless> mpt: well then. 
[10:21] <carlos> jordi: around?
[10:22] <mpt> lifeless: indeed.
[10:23] <stub> SteveA: Adding doom() looks trivial - 5 or 6 lines to _transaction.py
[10:23] <stub> Plus interface changes and defining the exception
[10:23] <SteveA> i'm opening a collector issue to document this
[10:25] <stub> I've never worked out how to use the collector
[10:30] <stub> Is it ok. to call foo.sync() in a method because one of the call sites requires it? Or should the callsite need to load the object that needs syncing and sync() it?
[10:32] <mpt> bradb!
[10:33] <SteveA> The changes would be:
[10:33] <SteveA>  * Add transaction.doom() to the API.
[10:33] <SteveA>  * Calling transaction.commit() on a doomed transaction will cause a DoomedTransaction exception to be raised.
[10:33] <SteveA>  * The publication code catches this exception from its call to commit(), and handles it by aborting the transaction.
[10:33] <SteveA> stub: is that all the changes needed upstream?
[10:33] <SteveA> there are other changes implied by this, of course, like updating interfaces etc.
[10:34] <stub> Document that calling abort() is a bug inside a zope transaction (wording is wrong, but you know what I mean)
[10:34] <stub> Fix the bug in EditForm now that it has been defined as a bug
[10:35] <stub> And other places that are calling abort() if there are any
[10:36] <stub> Why doesn't committing an aborted transaction raise an exception?
[10:37] <SteveA> you can't do that
[10:37] <SteveA> because a new transaction is implicitly begun
[10:38] <SteveA> so you can't get an aborted transaction and try to commit it
[10:38] <SteveA> you'd just be commiting a new transaction
[10:38] <SteveA> that's another issue, though
[10:38] <stub> So this wouldn't just be a zope.rdb issue - the same problem could bite someone in a purely zodb world too.
[10:38] <SteveA> yes
[10:38] <SteveA> i believe so
[10:39] <SteveA> i think the "implicitly begin a new transaction" thing is a mistake
[10:39] <SteveA> there should be a state "no transaction in progress"
[10:39] <SteveA> when shit fails to work
[10:39] <stub> Do we know why we are making database modifications when the form validation has failed?
[10:39] <jamesh> spiv: running "make" (as opposed to "make check") in the twisted dir runs its test suites
[10:39] <SteveA> i don't know why that is.
[10:39] <jamesh> spiv: and "make run" in a launchpad tree will run "make" on sourcecode/twisted before starting the app server ...
[10:39] <SteveA> stub: it is just an assumption that these aborts() are to blame
[10:39] <stub> So we still probably have a bug we can fix in Launchpad.
[10:40] <SteveA> stub: to find out, we'd need to record a stack trace on a ROLLBACK in the db adapter oops logger
[10:40] <stub> If the abort() in EditForm is the culprit, then we should be able to reproduce it.
[10:40] <SteveA> oddly, i looked through the launchpad code
[10:40] <SteveA> and could not find where it would use EditForm or similar
[10:40] <SteveA> so this could be a separate issue
[10:41] <SteveA> so, i think we should definitely add some code that looks to see where transaction.abort() was called for a given ROLLBACK
[10:43] <bradb> mpt: hey
[10:43] <stub> Yes. We already wrap the adapter, so we can add an api to enable and disable canning commit or abort, and raise an exception if any code tries doing it at the wrong time.
[10:43] <mpt> bradb, did you change "newest first" to "newest" and "oldest first" to "oldest"?
[10:43] <SteveA> stub: http://www.zope.org/Collectors/Zope3-dev/655
[10:44] <stub> Small change, although I suspect there will be fallout in the test suite that could cause complications
[10:44] <bradb> mpt: yeah
[10:44] <spiv> jamesh: Hmm, I'll fix that.
[10:44] <SteveA> stub: i'm proposing just logging code, not actually changing any behaviour
[10:44] <mpt> bradb, why?
[10:45] <jamesh> spiv: adding another phony makefile target (e.g. all) before the check target fixes the problem
[10:45] <stub> SteveA: An exception would be good, as this case will either cause an exception later or corrupt data.
[10:46] <stub> SteveA: So making the exception happen sooner will identify the cause of the problem and shouldn't worsen the user experience.
[10:46] <bradb> mpt: it was a bad idea.
[10:46] <SteveA> we can't have truely corrupt data, we have an RDB ;-)
[10:46] <bradb> mpt: When you change it back, feel free to improve "recently changed" too :P
[10:46] <mpt> ooh, now there's a challenge
[10:46] <bradb> "by last modified"?
[10:47] <SteveA> so, the way i'd do that is to make the database adapter wrapper aware of request start and ends (it already is, more or less, for timeout logging)
[10:47] <SteveA> and then for it to notice ROLLBACKs during a request, but not at the end
[10:47] <stub> Good idea to reuse those hooks.
[10:47] <spiv> jamesh: right.
[10:47] <stub> Might as well check for commit during a request too, which would be just as bad.
[10:47] <SteveA> and then to allow the publisher to ask the adapter "were there any commits or rollbacks"
[10:48] <SteveA> and let the publisher decide what to do about it
[10:48] <stub> Nah - we lose the callsite information then.
[10:48] <SteveA> so, the adapter's responsibility is just in recording these things
[10:48] <SteveA> the publisher would ensure it aborts and not commits
[10:48] <stub> We are in exactly the same situation we are now - something is screwing up majorly and we don't know where it is.
[10:48] <SteveA> then we make the adapter record a stacktrace against each commit / rollback recorded
[10:48] <stub> I don't see the point
[10:49] <SteveA> see, the rollback or commit isn't harmful provided there is no writing after it
[10:49] <SteveA> until the end of the request
[10:49] <stub> We raise an exception when it occurs, or we continue processing and raise an exception at the end using much more complex code.
[10:49] <stub> It *might* be harmful in the future.
[10:49] <SteveA> how can reading by harmful?
[10:50] <SteveA> so, you're proposing having the db adapter raise an exception
[10:50] <SteveA> if a commit or abort is received that is not from the publisher
[10:50] <stub> Because the code might be updated in the future so that it doesn't just read. Or the write might occur only one in 1000 transactions.
[10:50] <stub> Exactly.
[10:50] <SteveA> we can do that by having three notifications from the publisher to the adapter
[10:50] <SteveA>  - request starts
[10:50] <SteveA>  - request processing ended
[10:50] <SteveA>  - request ends
[10:51] <SteveA> commits and aborts are forbidden between "starts" and "processing ended"
[10:51] <SteveA> but allowed between "processing ended" and "ends"
[10:51] <SteveA> and that latter time is when the publisher does its commit or abort
[10:51] <stub> Yes. And we might need a hack to support the existing editform behavior if that is a problem. That might balls things up.
[10:52] <SteveA> i think that hack is implementing doom()
[10:52] <stub> Mmm... yup.
[10:52] <SteveA> EJBContext.setRollbackOnly();
[10:53] <SteveA> is the ejb version according to a google search
[10:53] <stub> Indeed. Why use one word when three will do?
[10:53] <SteveA> well
[10:53] <SteveA> Doom has religious overtones
[10:53] <stub> setRollbackOnlyAndDontEvenThinkAboutCommitting
[10:54] <SteveA> might offend christ knows who
[10:54] <stub> religious?
[10:54] <stub> armageddon maybe. Doom is just an english word.
[10:54] <mpt> Carmackian
[10:55] <stub> Nothing religious in my dictionary except a quote from a pope
[10:56] <SteveA> i think transaction.armageddon() would require more implementation
[10:56] <stub> Oh... it is a euphamism for the day of judgment.
[10:56] <SteveA> like doomesday
[10:57] <SteveA> DOOM
[10:57] <SteveA>      Decentralised Object Orientated Machine
[10:57] <stub> Anyway - religious usages of doom are all for the english meaning. If there is an argument against it it is because doom has lots of negative connotations like convictions, executions etc.
[10:58] <SteveA> and abort doesn't
[10:58] <mpt> ha!
[10:58] <mpt> just what I was going to say
[10:58] <mpt> not to mention killing child processes
[10:58] <stub> doom is a good name anyway
[10:58] <SteveA> reaping child zombies
[10:59] <mpt> and segmentation violations
[10:59] <SteveA> is that like fucking an earthworm?
[11:01] <mpt> I don't know why you think I'd know the answer to that question
[11:02] <jamesh> stub: with the integer printed in the SQL statement logs, do you think it would be useful to use the postgres transaction ID rather than the memory location of the connection?
[11:03] <SteveA> jamesh: why would the postgres transaction ID be more useful?
[11:03] <jamesh> SteveA: it changes when you run connection.commit()
[11:03] <stub> jamesh: There is no PostgreSQL transaction id I can access. I would need to create a sequence and make connections get a new value in order to generate one, and that is overkill since I doubt we want that information in there long term.
[11:04] <jamesh> stub: from a bit of googling, it seems that "select transaction from pg_locks where pid = pg_backend_pid();" will give it
[11:04] <stub> Also, it is recursive, as issuing a db call to find the transaction id would log the sql which would issue a db call to find the transaction id
[11:05] <mpt> lifeless, apologies, the problem was with mail.canonical.com, not with PQM
[11:06] <stub> I hate page tests
[11:06] <stub> But only when they fail
[11:06] <SteveA> mpt: look in the mail archives
[11:07] <SteveA> stub: i think we'd not log that particular select
[11:19] <SteveA> jamesh: so, using the postgres id would give us some insight into how individual connections are re-used 
[11:19] <SteveA> simply making that query once per request would allow us to match up connection id to pg transaction id
[11:20] <SteveA> we'd get a log like "/* 12345678 */ SELECT transaction FROM pg_locks WHERE pid = pg_backend_pid();"
[11:20] <SteveA> well, we'd have to log the result too
[11:20] <SteveA> so the next line would be the result, also logged against the python object id
[11:21] <SteveA> i'm still not sure what problems it would help out with, though
[11:21] <stub> I don't see that it informs us of anything new. We can already tell if commit is being called because we are logging that. It might make it a bit more obvious, but we don't want this logging in long term anyway (it is noisy - we just need it to track down this particular problem).
[11:21] <stub> Mmm... nap time.
[11:22] <jamesh> SteveA: I was thinking of logging the PG transaction ID instead.
[11:22] <jamesh> SteveA: so issue the above query once at beginning of the request (i.e. in ConnectionWrapper.__init__, commit and rollback), and then include that ID in the logs
[11:22] <jamesh> s/request/transaction/
[11:23] <Kinnison> Dear whoever it was who made 'make -C sourcecode build' run the twisted tests. Please die in a great big chemical fire. Love, Daniel
[11:24] <lifeless> stub: I am about to draft a spec, I'd like you to eyeball for db performance..
[11:24] <lifeless> stub: if we could have a phone call first it might save some time
[11:24] <jamesh> Kinnison: I just mentioned that to spiv ~ 40 minutes ago :)
[11:24] <Kinnison> make  226.17s user 17.91s system 60% cpu 6:44.53 total
[11:24] <Kinnison> :-(
[11:26] <spiv> Kinnison: The fix is being run by PQM already.
[11:26] <Kinnison> spiv: phew
[11:26] <Kinnison> spiv: How did you not notice this?
[11:26] <carlos> stub: hi, staging is broken again, but this time seems like it misses a dependency
[11:26] <spiv> Kinnison: If you're impatient, merge from sftp://chinstrap.ubuntu.com/home/warthogs/archives/spiv/twisted/makefile-tweak
[11:26] <carlos> stub: https://chinstrap.ubuntu.com/~dsilvers/paste/fileE7poHk.html
[11:26] <spiv> Kinnison: jamesh told me
[11:26] <Kinnison> aah
[11:27] <Kinnison> otherwise life will be bad
[11:27] <spiv> Kinnison: I don't run "make run" often enough, clearly :)
[11:27] <Kinnison> :-)
[11:27] <Kinnison> or 'make clean; make'
[11:31] <SteveA> carlos: that looks like staging hasn't been compiled
[11:31] <carlos> SteveA: I executed the build target
[11:32] <carlos> but it executed tests and failed importing openssl modules. I thought it was unrelated...
[11:32] <carlos> let me do a manual make build...
[11:32] <lifeless> carlos: edit sourcecode/twisted/Makefile
[11:32] <lifeless> carlos: make the first target in the make file be something like :
[11:32] <lifeless> all:
[11:32] <lifeless> 
[11:33] <lifeless> [11:33] <lifeless> that will ix it
[11:33] <lifeless> s/ix/fix
[11:33] <carlos> ok
[11:35] <spiv> carlos: see what I said to Kinnison
[11:36] <carlos> spiv: ok, I will apply lifeless workaround in the mean time. Thanks
[11:50] <carlos> SteveA: would you have some time today to talk with me about the meeting with danilo?
[12:04] <SteveA> carlos: ok
[12:06] <jordi> carlos: I'm here
[12:07] <carlos> jordi: hi
[02:07] <lifeless> Kinnison: how much work is the 'capture debian/branch content' patch to soyuz ?
[02:15] <carlos_> spiv: I was scared that you just switched jobs... 
[02:15] <carlos_> spiv: planet.ubuntu.com is evil
[02:18] <salgado> SteveA, around?
[02:21] <SteveA> salgado: about to go do lunch things
[02:23] <salgado> SteveA, is there a way to specify a default value in a non-huge vocabulary?
[02:24] <SteveA> i don't know.  i could look into it later.
[02:25] <salgado> SteveA, okay. I asked because I was planning to fix bug 50018
[02:25] <Ubugtu> Malone bug 50018 in malone "Linux Distribution field should be a neutral default" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50018
[02:26] <salgado> another way of fixing that would be to do something like we've done for shipit, that is, use a custom DropdownWidget implementation whose first value is always a 'Choose one' string
[02:27] <salgado> I can see use cases for both, but for bug 50018 I think it'd be better to have a sane default
[02:50] <lifeless> SteveA: ping
[02:50] <ddaa> Kinnison: ping
[02:50] <Kinnison> lifeless: Umm, assuming it's just "this spr said this" then I would say it's probably 2 days with tests
[02:50] <Kinnison> ddaa: yes?
[02:51] <ddaa> Kinnison: you said you wanted to have sunday's meeting on saturday
[02:51] <ddaa> any progress on that front?
[02:51] <Kinnison> ddaa: I said it'd be nice to have it split over the two days
[02:51] <Kinnison> ddaa: E.g. we wander into town around midday, we have lunch+meetings. If we're not done by dinner, we have dinner+meetings, we wander back to hotel. If we weren't done on saturday, we have sunday meetings too
[02:52] <ddaa> care to elaborate? I need some time of my own this week-end, at least to get some clean laundry from mom's before leaving to travel.
[02:53] <Kinnison> Okay, how about we say "meetings are on saturday, starting with lunch in Paris somewhere"
[02:53] <Kinnison> Do we need internet connectivity? Or even laptops?
[02:53] <ddaa> otoh, we might meet and have dinner at my mom's if you do not mind vegan food :)
[02:53] <Kinnison> I don't mind, Celso might
[02:54] <ddaa> mh...
[02:55] <ddaa> I'll ponder that for a few minutes
[02:57] <Kinnison> http://news.bbc.co.uk/1/hi/talking_point/5109366.stm
[02:59] <ddaa> Kinnison: it would be really nice if we could hammer out some sort of vaguely working prototype this week-end
[03:00] <ddaa> but then I probably do not need the both of you for that.
[03:00] <lifeless> also simon law is about to start doing something similar.
[03:00] <ddaa> lifeless: what do you mean?
[03:01] <lifeless> network of machines running tests
[03:01] <ddaa> are you suggesting we set up a double-pair workshop with Simon?
[03:02] <lifeless> I'm suggesting he shuld be in the loop
[03:04] <lifeless> ddaa: https://wiki.ubuntu.com/MultiMachineTestingInfraSpec
[03:04] <ddaa> lifeless: what's his nickname?
[03:06] <ddaa> that does have some overlap
[03:06] <ddaa> but it's mostly different to buildd on an orthogonal axis
[03:06] <ddaa> much closer to buildbot in spirit
[03:08] <ddaa> Kinnison: I'd prefer if we have a single-day workshop. I could pair with celso next week if we need to do more.
[03:09] <Kinnison> Right. If we're workshopping, where are we gonnna do that
[03:09] <lifeless> its closer to buildd in spirit I think
[03:12] <ddaa> Kinnison: practicality would dictate either at the hotel or at my parents (it's halfway between Paris and the hotel)
[03:12] <Kinnison> If we're workshopping, here is more comfortable, but Paris has better cheaper food
[03:12] <Kinnison> I refuse to spend 35 on lunch tomorrow
[03:13] <ddaa> if you guys like paris better, we could even go to my appt, but it's quite minuscule, and seriously out of the way.
[03:13] <ddaa> about 30 mins from Chatelet-Les-Halles
[03:16] <Kinnison> ddaa: Couldn't we find somewhere to eat in the centre?
[03:17] <ddaa> sure, either good or cheap :)
[03:18] <kiko-zzz>    1 AttributeError: 'DummyPOFile' object has no attribute 'getPOTMsgSetUntranslated'
[03:18] <kiko-zzz>     0% from search bots, 100% referred from local sites                              
[03:18] <kiko-zzz>        1                                               
[03:18] <kiko-zzz> +https://launchpad.net/distros/ubuntu/dapper/+source/gcc-3.3/+pots/gcc-3.3/ar/+translate
[03:18] <kiko-zzz>         OOPS-173A469
[03:18] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/173A469
[03:18] <kiko-zzz> matsubara, carlos: seen this?
[03:18] <ddaa> probably saturday will be better, since that would give us the option to work later and/or go for dinner
[03:18] <ddaa> while sunday would be more tricky for travel
[03:18] <ddaa> phone...
[03:19] <matsubara> kiko-zzz: yes, I'm aware of it.
[03:19] <carlos> kiko-zzz: yeah, There is a bug for it already and I think the patch you show me yesterday would fix it... (haven't time to see it carefully)
[03:19] <carlos> kiko-zzz: also you commented on that bug...
[03:19] <matsubara> bug 44860
[03:19] <Ubugtu> Malone bug 44860 in rosetta "Crash when we try to pass a query string to a POFile that doesn't exist yet." [Medium,Confirmed]  http://launchpad.net/bugs/44860
[03:19] <carlos> it's the one related to DummyPOFile not implementing IPOFile 
[03:20] <lifeless> SteveA: around ?
[03:20] <kiko-zzz> aha!
[03:20] <kiko-zzz> carlos, if you are lucky I can try fixing that on the plane
[03:21] <carlos> kiko-zzz: could you send me the list of bugs you are fixing? I was planning to do some work on some of those bugs between today and next week
[03:21] <kiko-zzz> carlos, I have no idea what bugs will be fixed by that refactoring. my suggestion: STAY AWAY FROM browser/ :)
[03:21] <carlos> and I don't want to duplicate what you are doing atm
[03:22] <Kinnison> lifeless: can I read that spec yet?>
[03:22] <carlos> kiko-zzz: how long would take that refactoring?
[03:22] <lifeless> Kinnison: no
[03:22] <carlos> if you tell me you would get it done next week, that's fine
[03:22] <carlos> if it would take much more time
[03:22] <carlos> perhaps I could take care of it
[03:22] <carlos> based on what you gave me yesterday
[03:23] <carlos> perfect, he lost his Internet link....
[03:23] <carlos> :-(
[03:27] <SteveA> lifeless: kind of
[03:28] <lifeless> SteveA: I have a spec I would like you to eyeball - its for deploying an hct component in production
[03:28] <SteveA> ok
[03:30] <lifeless> https://launchpad.net/products/launchpad-bazaar/+spec/tracking-versions
[03:30] <lifeless> its pending approval. I'd like you to either say who should approve it, or read and approve/bounce it yourself.
[03:30] <ddaa> Kinnison: I still need to phone to get proper permission, but I think what we'll do will be:
[03:30] <ddaa> * meet at aulnay sous bois tomorrow morning
[03:31] <ddaa> * go to my parents place to dump stuff and start working
[03:31] <ddaa> * go for lunch in aulnay center, there are cheap places there
[03:32] <ddaa> dinner TBD
[03:32] <ddaa> my appt would be too small for 5 people
[03:33] <spiv> carlos: Heh.  The blog software I use got upgraded, and it changed its URLs, so apparently planet thinks they're new entries despite the dates in the RSS feed.
[03:34] <carlos> yeah
[03:39] <Kinnison> ddaa: Sure, just make sure the final answer is mailed
[03:40] <flacoste> spiv: thanks for the review, i'll do the suggested changes and land this
[03:41] <spiv> flacoste: not a problem.
[04:12] <siretart> what has happened to https://wiki.launchpad.net/PackageSourceManagement? the linked launchpad entry is dead, as well as the 'launchpad-upload-and-queue' product.
[04:56] <flacoste> LarstiQ: ping
[04:57] <flacoste> i'll fill a bug report right now
[05:03] <flacoste> actually, it seems like that bug was already reported (bug #4663)
[05:03] <Ubugtu> Malone bug 4663 in bzr "bzr log does not work on merged revisions" [Medium,Confirmed]  http://launchpad.net/bugs/4663
[05:12] <lifeless> fixed in bzr.dev
[05:34] <flacoste> lifeless: you mean that bug is fixed in bzr.dev?
[05:35] <lifeless> yes
[05:35] <flacoste> should I use bzr.dev?
[05:35] <flacoste> and if yes, how can I do that?
[05:36] <lifeless> current policy is for lp devs to run bzr from dapper
[05:38] <flacoste> ok, that answers my question, tnx!
[05:41] <carlos> see you !!
[06:07] <flacoste> should I change links in Launchpad specifications that point to wiki.launchpad.canonical.com?
[07:01] <SteveA> spiv: ping