[12:08] <sabdfl> mpt: any progress on the main template, with facets-as-tabs?
[12:09] <mpt> sabdfl: I haven't had time to do that yet, I've been working on the Rosetta copy-and-paste buttons
[12:09] <sabdfl> mpt: ok cool
[12:09] <sabdfl> can you make that next on your list?
[12:09] <sabdfl> night all
[12:10] <mpt> ok, though I'm not that keen on something which will make them take up more space
[12:10] <mpt> 'night
[12:10] <bradb> later sabdfl 
[12:10] <Nafallo> night sabdfl :-)
[12:12] <mpt> ugh
[12:21] <Keybuk> These files violate naming conventions:
[12:21] <Keybuk> examples/.arch-ids/\(U+E2)\(U+99)\(U+AA)\(U+E2)\(U+99)\(U+AC).id
[12:21] <Keybuk> examples/\(U+E2)\(U+99)\(U+AA)\(U+E2)\(U+99)\(U+AC)
[12:21] <Keybuk> -- 
[12:22] <Keybuk> they do ?!  it shouldn't afaict
[12:23] <Keybuk> lifeless: ?
[12:26] <bradb> fmt:approximateduration is in spiv's review queue, later all
[12:27] <carlos> stub, I have an update to the migration script already but I cannot merge it yet, I have there other changes, can you merge to stagging to test it?
[12:27] <stub> carlos: Sure
[12:27] <carlos> stub, carlos.perello@canonical.com--2004/launchpad--devel--0
[12:28] <carlos> stub, the other changes should not affect that script
[12:29] <stub> Are the changes you care about only in the script? if so, I don't have to worry about merging. 
[12:29] <stub> carlos: ^^^
[12:29] <carlos> stub, the needed changes to get the script running is only in the script, the branch touches other files
[12:30] <carlos> but those changes are not related, it belongs to other changeset
[12:36] <carlos> stub, do you need anything else to test it?
[12:36] <stub> Nop
[12:36] <stub> e
[12:37] <carlos> ok, thanks
[12:37] <carlos> good night
[01:58] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=salgado]  Make EnumCol work with default=DEFAULT.  Fixes bug 1659. (patch-2263: andrew.bennetts@canonical.com)
[03:05] <stub> spiv: Where you going to stop the librarian accepting files with evil filenames? (eg. containing / or \0) If so, can you update Bug388 with characters you deem as evil?
[03:06] <spiv> stub: The only characters I'm inclined to deem as evil are / and \0.
[03:06] <spiv> But part of me feels that it's not the librarian's problem ;)
[03:06] <stub> Once the DB constaints are in place, it won't get as far as the Librarian.
[03:08] <jamesh> are characters that look like "/" evil too?
[03:08] <spiv> What's the use case for disallowing them?  (I admit I don't really have one for allowing them either0
[03:08] <spiv> )
[03:09] <spiv> jamesh: The reason to disallow / and \0 are because they're invalid in posix filenames (although / is of course valid in a pathname).
[03:10] <spiv> But I'm struggling to see any way that it actually matters.
[03:10] <spiv> I guess the database column being called "filename" rather than "pathname" is one argument.
[03:10] <stub> spiv: Because broken clients can upload a file with filename 'c:/foo/bar.txt', which then can't be downloaded in any sane fashion.
[03:10] <jamesh> spiv: I suppose the web browser would replace them anyway, if a user is downloading and saving them
[03:10] <spiv> stub: Why can't they be downloaded?
[03:11] <jamesh> stub: on Windows, I think that would get downloaded as c__foo_bar.txt
[03:11] <stub> spiv: Because they are invalid and look like a hacking attempt (eg. what should firefox do if you ask it to download a file called ~/.bashrc ? )
[03:11] <jamesh> been a while since I've checked though
[03:11] <spiv> stub: Probably save it do $downloaddir/.bashrc
[03:11] <jamesh> it's pretty easy to test for though
[03:12] <stub> spiv: But we don't know that, and we shouldn't let invalid data get into the system in the first place.
[03:12] <spiv> If you can convince me that it's invalid, I'll be much happier :)
[03:13] <stub> It would probably be specified in the MIME rfc under the filename attibute to the mimetype
[03:14] <spiv> I am leaning slightly towards disallowing them, but I'd really like to have a strong reason other than a vague feeling that it's probably better.
[03:14] <spiv> If only so that I can put a more useful comment in the code than "Disallow / and \0, just in case" ;)
[03:15] <spiv> See section 2.3 of RFC 2184
[03:15] <spiv> Er,
[03:15] <spiv> 2183
[03:16] <spiv> Although it's discussing MUAs rather than HTTP clients.
[03:18] <stub> actually, MIME is a red herring. These filenames are served up as part of URLs, which IIRC can include anything if properly UTF-8 encoded and quoted
[03:18] <stub> But clients might still have issues, and I'm not going to test all the clients ;)
[03:19] <spiv> http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1
[03:20] <stub> I'm inclined to disallow anything that indicates the client uploading the file is screwed, because we really don't want data from that source ;)
[03:20] <spiv> Arbitrary restrictions have a way of biting you in the arse unexpectedly six months later :)
[03:21] <stub> Does the Librarian actually set that header?
[03:21] <stub> Or not bother, since the filename is the final component of the URL?
[03:21] <spiv> Your example of c:/foo/bar.txt inclines me to not bother disallowing anything -- I'm interested in learning how to make "safe" filenames for every OS out there.
[03:22] <spiv> It doesn't send it, no.
[03:22] <stub> My example is actually based from real world experiance with broken windows clients that tended to upload filenames such as c:\foo\bar.txt
[03:22] <spiv> Which is a 100% valid posix filename.
[03:24] <stub> 'safe' can be defined as ASCII and not containing / \ : or \0 , which is probably a bit strict now days (we could extend that to UTF-8 and not containing / \ : or \0
[03:24] <stub> Indeed - c:\foo\bar.txt is 100% valid, but is totally broken. Users report it as a bug, so you shouldn't let it get in the first place.
[03:25] <stub> The only use case I can think of for allowing a filename like that is so you can laugh at the silly person still using IE4 (or whatever it was)
[03:26] <jamesh> stub: on Windows, you'll get in trouble with *, ? and a few others
[03:26] <stub> I tend to not like \0 and it tends to break C code unexpectedly
[03:27] <stub> true. Anyway, I would really only bother disallowing 
[03:27] <spiv> Sure, and filenames longer than a certain length might trigger buffer overflows in some C code too ;)
[03:27] <Keybuk> the fun ones are filenames with \n in them <g>
[03:27] <spiv> Right, whitespace can break badly written shell scripts...
[03:27] <stub> ... / and \0 , because the first indicates the client is screwed and the second is scary
[03:27] <Keybuk> and libtool
[03:28] <Keybuk> / and \0 are the only invalid characters in a POSIX filename :-/
[03:28] <Keybuk> ^G in them is fun
[03:29] <spiv> Ok, so the two reasonable choices are 1) free for all, 2) everything except / and \0.
[03:29] <spiv> Trying to restrict more than that is the path to madness, as we try to guess what breaks windows and whatnot.
[03:30] <Keybuk> utf-8 filenames are certainly "normal" in linux now
[03:30] <spiv> Well, the librarian stores filenames as unicode.
[03:31] <stub> Keybuk: Is that now 'standard', or is it still the filename is assumed to be in the encoding being used by the terminal?
[03:31] <spiv> There's no guarantee clients won't upload encoded names, though.
[03:31] <Keybuk> there's nothing in the filesystem to force it (unless your fs=fat)
[03:31] <stub> spiv: If it aint a valid UTF-8 sequence, PostgreSQL will barf
[03:32] <spiv> And I don't think HTTP has any standard way to serve non-ASCII filenames.
[03:32] <Keybuk> so how you read filenames is how they're displayed
[03:32] <spiv> stub: Well, it'd be double-encoded would be the issue.
[03:32] <spiv> But we can't do much about people uploading garbage except serve that garbage back at them :)
[03:32] <stub> spiv: Can't happen - the filename is decoded on upload
[03:33] <jamesh> Keybuk: JFS also wants unicode filenames, iirc
[03:33] <spiv> stub: By "client" I don't mean the librarian client, I mean Joe Bloggs with his dodgy Web Browsez0r 0.9.
[03:33] <Keybuk> really? sweet
[03:35] <spiv> stub: (once I fix a bug) The librarian client always sends filenames utf-8 encoded, and the librarian server utf-8 decodes them into unicode objects, which of course are then re-encoded for insertion into the database.
[03:35] <spiv> The librarian server already barfs on non-utf-8 filenames.
[03:36] <stub> OS-X is UTF-8 -- it becomes necessary to define the encoding when you have a Unicode aware filesystem browser. And Win32 is all Unicode apis so I don't think the encoding is even exposed to developers. I assume the existing Linux ones all just break if the filenames arn't encoded the way they expect :-(
[03:39] <jamesh> stub: on Windows, there are two APIs for pretty much everything: the unicode one and the "ANSI" one
[03:40] <jamesh> where the ANSI one is the legacy encoding
[03:41] <jamesh> so you can create files with the unicode API that apps using the ANSI API can't read
[04:10] <mdz> so now that my duplicate launchpad users are all sorted, is there a way for me to change 'name93' to 'mdz'?
[04:11] <spiv> mdz: Currently only by asking stub, I think :/
[04:11] <spiv> I'm not sure what's left to stop us from letting users edit that.
[04:12] <spiv> https://wiki.launchpad.canonical.com/WhatNamesCanBeChanged says it ought to be allowed.
[04:14] <mdz> does stub read scrollback?
[04:14] <mdz> stub: ^^^
[04:14] <mdz> who's responsible for the code of conduct signing stuff?
[04:15] <spiv> stub reads scrollback afaik, yeah.
[04:20] <spiv> cprov, iirc.
[04:32] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  only-one-ubuntu-wikiname constraint and people merge patch to cope (patch-2264: stuart.bishop@canonical.com)
[05:46] <stub> mdz: Updated
[05:46] <mdz> stub: thanks
[08:10] <spiv> stub: thanks for fixing #1313!
[08:11] <stub> Just karma whoring
[08:11] <spiv> :)
[08:12] <spiv> Well, that's probably fair enough, given that it was probably our most frequently reported dupe.
[08:27] <lifeless> 1212 ?
[08:28] <lifeless> bah
[08:28] <lifeless> ignore me
[08:28] <lifeless> win 18
[10:41] <carlos> morning
[10:48] <carlos> stub, hi, how was the whitespace script test? still running?
[11:36] <stub> carlos: still running
[11:37] <carlos> that's good
[11:37] <carlos> means the bug would  be fixed
[12:11] <sabdf1> stub: could you tell me which upstream apps have the most bugs filed against them? just top 5 or 10
[12:24] <sabdfl> stub: ping
[12:43] <sabdfl> lifeless: ping
[12:44] <lifeless> sabdfl: pong, just talking about you :0
[12:45] <lifeless> (jdub is giving his oscon talk to debsig)
[12:45] <sabdfl> lifeless: coolio :-)
[12:45] <sabdfl> lifeless: could you give me read-only access to the staging db please? i have accounts on mawson and asuka
[12:46] <lifeless> mawson is staging right ?
[12:46] <sabdfl> asuka, i think
[12:47] <sabdfl> not sure which db it is
[12:47] <Kinnison> mawson is dogfood, asuka is staging
[12:47] <sabdfl> stub and salgado might know
[12:47] <sabdfl> Kinnison: db names?
[12:47] <lifeless> bah, don't have the right keys with me, I can do it when I get home if stub hasn't surfaced by thenm
[12:48] <sabdfl> ok, cool, thanks
[12:51] <Kinnison> sabdfl: people seem to use: psql -h asuka.ubuntu.com -U ro -d launchpad_staging
[12:51] <Kinnison> sabdfl: from mawson
[12:52] <carlos> sabdfl, ^^ that's what daf and I use
[12:52] <sabdfl> psql: FATAL:  no pg_hba.conf entry for host "82.211.81.131", user "ro", database "launchpad_staging", SSL off
[12:53] <lifeless> sabdfl: if you have access to asuka/mawson, you should have sudo access to the launchpad use
[12:53] <carlos> sabdfl, from mawson
[12:53] <lifeless> *user*
[12:53] <lifeless> thats what we usually give people who are working with those machines
[01:22] <stub> yo
[01:25] <sabdfl> hey stubarooney
[01:26] <stub>          name         | count
[01:26] <stub> ----------------------+-------
[01:26] <stub>  malone               |   304
[01:26] <stub>  launchpad            |   281
[01:26] <stub>  bazaar               |   246
[01:26] <stub>  rosetta              |   159
[01:26] <sabdfl> think you can let me see staging read-only, from mawson or asuka?
[01:26] <stub>  foaf                 |    51
[01:26] <stub>  hct                  |    14
[01:26] <stub>  soyuz                |     6
[01:26] <stub>  sympa                |     4
[01:26] <stub>  ubp-hoary-unofficial |     3
[01:26] <stub>  ubuntu               |     3
[01:26] <stub>  bluefish             |     2
[01:26] <stub>  blender              |     2
[01:26] <stub>  buildd               |     2
[01:26] <stub>  fdclock              |     2
[01:26] <sabdfl> thats plenty
[01:26] <stub>  gnomebaker           |     2
[01:27] <stub> sabdfl: You should be able to connect to launchpad_staging on asuka as the ro user now (from your mawson account, using the command given before)
[01:28] <sabdfl> mark@mawson:~ $ psql -h asuka.ubuntu.com -U ro -d launchpad_staging
[01:28] <sabdfl> psql: FATAL:  no pg_hba.conf entry for host "82.211.81.131", user "ro", database "launchpad_staging", SSL off
[01:28] <sabdfl> nup
[01:28] <sabdfl> did you see jdub's presentation?
[01:28] <stub> argh... username mark, not sabdfl :-(
[01:29] <sabdfl> :-)
[01:29] <stub> sabdfl: ok - try again
[01:29] <sabdfl> rocking, thanks
[01:31] <sabdfl> very exciting
[01:33] <sivang> sabdfl: what was his presentation about?
[01:39] <sabdfl> sivang: aiui it was his oscon presentation, replayed. 
[01:40] <sabdfl> stub: i'm [trivial] 'ing a two-liner that lets you exclude dbschemas from the vocabs
[01:42] <sabdfl> it might be better to have dbschema items be markable as deprecated, so they don't show up
[01:42] <sabdfl> the use case for this is the debbugs tracker, we only know of one, we don't want people registering more
[01:43] <stub> sounds sane. A deprecated flag doesn't sound appropriate for your use case though - the way you are doing it seems to be the best option.
[01:58] <carlos> see you later
[02:17] <lifeless> nofht all
[02:17] <lifeless> bah
[02:17] <lifeless> night all
[02:20] <BjornT> stub: do i need your approval if want to edit security.cfg? (add delete to bugsubscription)
[02:21] <stub> BjornT: Nope - as long as I know about it.
[02:21] <BjornT> stub: cool
[02:25] <ondrej> mm all
[02:26] <ondrej> is there a plan to do cleanup in rosetta breezy target?  so f.e. glib2.0 is not list 7x times?
[02:31] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  polish home pages (patch-2265: mark.shuttleworth@canonical.com)
[02:39] <sabdfl> carlos: ^^ q from ondrej
[02:41] <ondrej> sabdfl: feeling better today? heard you were/are sick (yesterday)...
[02:42] <sabdfl> ondrej: yes, much better today thanks. lurgie from brazil had me nailed yeterday
[02:43] <ondrej> :-) that's good...  hope to see you on next CC meeting...
[03:00] <kiko> hey ho
[03:01] <sivang> yo kiko 
[03:02] <sabdfl> kiko: is salgado around?
[03:02] <sabdfl> any idea why we don't have a Person.karma cache?
[03:02] <mpt> We're not sure where he is, sabdfl
[03:02] <mpt> We think he might be at classes
[03:02] <kiko> I am sure where he is
[03:02] <kiko> he's at classes
[03:04] <sabdfl> kiko: please could you ask him to do the following:
[03:04] <sabdfl>  - add a karma field to the Person table
[03:04] <sabdfl>  - replace Person.karma() with that field
[03:05] <sabdfl>  - make update-stats.py also update karma
[03:05] <sabdfl> so we have the karma value cached, and can index and query it
[03:05] <kiko> sabdfl, could you file a bug? :)
[03:05] <ondrej> suggestion for rosetta: there should be simple way how to use suggested translation: copy & paste is not very efficient...  simple javascript could be implemented, so you can just click and have it prefilled in input box...
[03:06] <sabdfl> product? foaf does not exist
[03:06] <mpt> ondrej: I'm working on that at the moment
[03:06] <kiko> ondrej, yeah, known trick it's in the pipeline
[03:06] <kiko> sabdfl, launchpad
[03:06] <mpt> sabdfl: It was renamed to ex-foaf, with its bugs etc rolled into launchpad
[03:06] <kiko> there are only three lp products now -- launchpad, malone, rosetta
[03:06] <ondrej> ok, thanks for info
[03:07] <sabdfl> kiko: https://launchpad.net/malone/bugs/1794
[03:08] <kiko> sabdfl, thanks, I'll make sure it's done
[03:09] <sabdfl> ondrej: https://wiki.launchpad.canonical.com/TranslationReview
[03:09] <sabdfl> though, that spec does not reflect what i asked for in Brazil. MPT?
[03:09] <sabdfl> i didn't want radio buttons...
[03:11] <ondrej> nice, I like those scanned paper notes :-)
[03:13] <ondrej> btw, from https://wiki.ubuntu.com/Calendar Sep 1st - StringFreezy - does this mean that *upstream* (from translation teams POV) strings are freezed and L10N teams can start work on translations?
[03:13] <mpt> sabdfl: Should you eventually get karma if your suggestion gets accepted? If so, there needs to be some way of identifying whose suggestion is being accepted. And as the radiobuttons copy into the field just like the copy buttons do, in case you want to tweak one of them.
[03:14] <mpt> It's much simpler than the previous version of the spec :-)
[03:15] <ondrej> I was also asked this question: how and when are translations from rosetta propagated to Ubuntu? It makes sense not only to translate some *random* strings in rosetta, but also to test them inside live system.
[03:16] <kiko> ondrej, the translations are exported into language packs, which are then rolled into the distribution, so indeed they are used
[03:17] <WaterSevenUb> ondrej: but the documentation string freeze is only Sep 8th
[03:17] <ondrej> kiko: so every new release of language-pack contains up-to-data translations from rosetta?
[03:17] <kiko> that is correct
[03:22] <ondrej> is there a way how to review translations in one language and all packages? I have team member who is not so sure of his translations, and marks all as "Need Review", so I would like to review all of them in one big batch (601 translation strings suggested)
[03:22] <ondrej> and if not it would be nice thing to have
[03:25] <kiko> there is a review interface planned
[03:26] <ondrej> just didn't see this suggestion in TranslationReview wiki page, so I thought it would be usefull to mention it :-)
[03:27] <kiko> yeah, it's a great suggestion -- mpt, which spec covers the mass-review UI?
[03:27] <bradb> morning
[03:28] <ondrej> err, https://wiki.launchpad.canonical.com/RosettaSpecification page broken: ImportErrorCannot load macro ListSpecifications
[03:28] <kiko> ondrej, agh.
[03:28] <kiko> elmo?
[03:29] <elmo> what?
[03:29] <kiko> elmo, I wrote a couple of macros to automate some queries our moin instance
[03:30] <kiko> s/our/on our
[03:30] <kiko> elmo, what would be a good way to install them and allow me to update them as I go?
[03:30] <elmo> send them to me
[03:30] <kiko> okidok
[03:31] <mpt> kiko: I hadn't heard of the mass-review idea before
[03:32] <kiko> elmo, sent
[03:32] <mpt> I don't think we have a spec for it
[03:32] <mpt> ondrej, perhaps you would like to write the spec? :-)
[03:32] <kiko> mpt, in capetown we discussed it -- it would be across potemplates
[03:32] <bradb> spiv: ping
[03:33] <mpt> Well, if we do, I don't think it's one I was involved in
[03:33] <mpt> either that or I have a bad memory
[03:34] <kiko> or too many drugs
[03:35] <mpt> yeah, that must be it
[03:35] <mpt> pink mushrooms
[03:37] <spiv> bradb: pong
[03:37] <spiv> bradb: want that review done?
[03:37] <bradb> spiv: yes please!
[03:37] <bradb> if possible, of course
[03:40] <kiko> there were beautiful
[03:42] <ddaa> sabdfl: do the tables "changesetfilename", "changesetfile" and "changesetfilehash" have any future? They are going to require additional work to support with import-archivelocation and they are quite arch-specific in design (assume on-disk changeset-based storage).
[03:43] <ddaa> I'd rather have them ignored now (no longer updated) and delete at the first oppurtinity.
[03:44] <ondrej> mpt: err, I am not good at writing specifications :-)
[03:45] <ondrej> but I can try :-)
[03:48] <mpt> ondrej: So you are wanting to review all the translations made by a particular person?
[03:53] <carlos> ondrej, It needs some manual changes, I'm doing it from time to time, but it's a bit hard. Will fix glib now.
[03:56] <ondrej> https://wiki.launchpad.canonical.com/TranslationMulti
[03:57] <mpt> excellent, thanks ondrej
[03:57] <ondrej> carlos: ok, thanks...  I guess this will settle down with StringFreezes?
[03:58] <carlos> ondrej, it should not affect StringFreezes... usually is the same but from different versions that our automatic system was not able to handle
[04:00] <ondrej> I mean - you will do one big manual cleanup at that time...?
[04:00] <jblack> ddaa: ping
[04:01] <ddaa> jblack: sir?
[04:01] <jblack> Good morning! (afternoon for you). 
[04:01] <jblack> Do you have time for an interview this morning? 
[04:01] <ddaa> hu?
[04:02] <ddaa> Who are we interviewing?
[04:02] <jblack> I'm interviewing you. dislodging data, dependancies, etc. 
[04:02] <jblack> this is for a nice solid roadmap
[04:03] <jblack> iirc, you're doing the lp part of the supermirror. 
[04:03] <carlos> ondrej, if I have time, yes
[04:03] <ddaa> I'm only on usual overload, not overloaded overload, so I guess I have the time :)
[04:03] <carlos> ondrej, but I'm a bit busy atm with jordi and daf out
[04:03] <jblack> Ok. Whats a good offset from now to start? 
[04:04] <ddaa> jblack: not sure if I can tell you anything though. I did not have time even to touch the LP things I'm supposed to do.
[04:04] <ondrej> carlos: ok, I will ping you if something as glib2.0 is there again...
[04:05] <jblack> This is just in the context of building a raodmap. 
[04:05] <carlos> ondrej, there are more, I know, but I will try to fix the ones people ask for first
[04:05] <ddaa> "Whats a good offset from now to start?" I do not understand your question.
[04:06] <jblack> now + 0 min, now + 1 hour, six hours from now, after you've had a cup of wine.... 
[04:06] <ddaa> jblack: let's do it now.
[04:06] <jblack> Great.
[04:08] <jblack> I'm that pink number on the bottom.
[04:38] <carlos> ondrej, done: https://launchpad.net/distros/ubuntu/breezy/+sources/glib2.0/+translations 
[04:39] <carlos> ondrej, next week the deprecated entries will disappear
[04:43] <bradb> spiv: will you have a chance to do that review today?
[04:44] <ondrej> carlos: thanks
[04:46] <carlos> spiv, can I merge the last branch you reviewed? or do you need anything else after my last answers?
[04:47] <spiv> bradb: In your mail now.  That should keep you busy ;)
[04:49] <spiv> carlos: Your devel branch?
[04:49] <bradb> spiv: cool, thanks
[04:49] <carlos> spiv, yeah
[04:49] <carlos> spiv, I think the only open issue is related with the new Interface you suggested
[04:50] <spiv> carlos: Hmm, I don't see a reply to it, and my review had a few questions.
[04:50] <carlos> spiv, I answered them...
[04:50] <jblack> spiv: You're up! Will you be up in a little bit? 
[04:50] <carlos> spiv, when did you get my last email?
[04:51] <spiv> jblack: Unlikely, it's past my bedtime.  You might get lucky though ;)
[04:51] <spiv> carlos: The 12th, I think.
[04:52] <carlos> spiv, my laptop's email server went down
[04:52] <spiv> carlos: I've definitely seen no answers to my review of your devel branch...
[04:52] <bradb> spiv: how much longer will you be around? i'm hoping to fix this up and land today, if possible.
[04:52] <carlos> it should go out now
[04:53] <spiv> bradb: About to crash, sorry.
[04:53] <bradb> ok, no worries, thanks for the review
[04:54] <spiv> bradb: But if the changes you make are all more or less as proposed in the review (and you make all the changes required by the review), you can merge.
[04:54] <spiv> I guess that's technically merge-conditional rather than needs-reply.
[04:54] <spiv> Except that I want to review the changes after merge in that case, just in case :)
[04:55] <spiv> The nice thing about having that huge list of tests is that we can be confident it actually works, even if it's ugly.
[04:55] <bradb> yep, i live by that motto
[04:55] <spiv> Yeah, I'll mark it merge-conditional on the wiki for you.
[04:55] <bradb> thanks
[04:56] <spiv> carlos: ok.
[04:56] <kiko> carlos, I hate POParser already
[04:57] <carlos> kiko, ok, now we are three, should we create a club? :-P
[05:00] <kiko> I might be able to fix it somewhat
[05:00] <kiko> I'm trying
[05:01] <kiko> carlos, would it make sense to strip() all lines in a pofile?
[05:01] <carlos> kiko, daf has a new parser that should be compatible with current one, I don't think you should expend too much time with it, we should move either to daf's one or fix gettext's one
[05:01] <jblack> kiko: Glad you're here.
[05:01] <jblack> spiv: Still around? 
[05:02] <spiv> carlos: Also, update the wiki when you reply to a review, to mark it needs-review again.
[05:02] <carlos> kiko, before or after remove msgid "" and msgstr "" ?
[05:02] <carlos> spiv, ok
[05:02] <spiv> carlos: That way I only need to look at one place to know if I have review work to do.
[05:03] <kiko> carlos, in general, I mean -- should trailing whitespace be taken into account?
[05:03] <kiko> carlos, a new parser? wow, where?
[05:03] <carlos> kiko, he sent me it a while ago, but still has some bugs
[05:03] <spiv> jblack: Yes, but only barely.
[05:03] <jblack> Do you have time to look at an email and add 3 lines to it? 
[05:04] <spiv> If you're quick ;)
[05:04] <jblack> What email address to you prefer for sending? 
[05:04] <spiv> andrew@canonical.com
[05:04] <carlos> kiko, if you do it before any file parsing, that's ok
[05:04] <mpt> Anyone know what that means?
[05:04] <mpt> cprov?
[05:05] <kiko> code of conduct
[05:05] <kiko> is that the question?
[05:06] <mpt> I know what a CoC is
[05:06] <mpt> (though I'm going to change that to "Code of Conduct" here anyway)
[05:06] <cprov> mpt: yes, this actions is documented in the spec, consists in a approval of a not digitally signature of CoC by a CC member (aka LP Admin)
[05:06] <mpt> but what does "Acknowledge" mean in this context?
[05:07] <mpt> cprov: Sorry, "approval of a not digitally signature" ...
[05:07] <Nafallo> sounds like Approve to me
[05:07] <mpt> cprov: So someone signs the Code
[05:07] <mpt> or someone says they agree to it
[05:07] <mpt> but doesn't digitally sign it?
[05:07] <bradb> spiv: btw, bisect.bisect appears to return the index that would be the insertion point for the item, so 1. it will always be one greater than the position of the item that interests us, 2. it's not documented to raise an IndexError at all, as best i can tell
[05:07] <mpt> cprov: And then an admin has to say "yes, this is equivalent to a real signature"?
[05:07] <jblack> kiko: Will you be here in ~ 20 minutes? 
[05:08] <kiko> hmm
[05:08] <kiko> I shouldn't be
[05:08] <cprov> mpt: sorry, typed bad english ... yes, in fact it could be a REAL signature sent by fax to a member  
[05:08] <kiko> jblack, in 2h?
[05:08] <jblack> in 2h, for up to 2h ? 
[05:08] <mpt> cprov: So this is something an admin does
[05:08] <mpt> all right
[05:09] <kiko> cprov, "could" or "will be"?
[05:09] <kiko> jblack, sure
[05:09] <cprov> mpt: exactly, the page is restricted
[05:09] <spiv> bradb: https://chinstrap.ubuntu.com/~dsilvers/paste/fileuPFG4M.html
[05:09] <jblack> Its a date. I'll wear my prettiest dress.
[05:09] <cprov> kiko: it is ;)
[05:10] <spiv> bradb: Note the (seconds, '') trick, which perhaps should be more prominently commented.
[05:10] <mpt> cprov: How about "Register Someone's Signature"?
[05:11] <kiko> cprov: huh? "could" or "will be"?
[05:12] <cprov> mpt: sound sane, but is it intuitive for the CC members ? maybe "Approve CoC Signature", I'm not sure about the name "Acknowledge", but it was approved by Mako in AU
[05:14] <mpt> Well, you only need to do it if it wasn't an automatic signature
[05:16] <cprov> mpt: yes, if the candidate has no GPG yet, or whatever everything but the normal COC GPG signed.  
[05:17] <mpt> so I think "Register" makes more sense for something that Launchpad didn't know about
[05:17] <mpt> previously
[05:17] <mpt> "Approve" would be for something that's already in Launchpad
[05:19] <cprov> mpt: indeed, but if you think the process itself (apart of register a new CoC signature) means you are *approving* a new member of the UBUNTITES super-team, my suggestion still reasonable 
[05:21] <mpt> cprov: Do people still need to be approved separately even if they sign the Code digitally?
[05:22] <mpt> cprov: Offhand, do you know which file generates the portlet on /codeofconduct ?
[05:22] <cprov> mpt: no, digitally signature automatical promote the user as UBUNTITE
[05:23] <mpt> ok, so this is more about their signature than it is about approving them.
[05:23] <cprov> mpt: right, it makes sense
[05:23] <bradb> spiv: i think the algorithm that uses bisect.bisect is broken
[05:24] <bradb> e.g.
[05:24] <bradb> (Pdb) bisect.bisect(representation_in_seconds, (1.5, ''))
[05:24] <bradb> 0
[05:24] <cprov> mpt: portlet-codeofconduct[set] -actions.pt depends where you are
[05:24] <bradb> spiv: it should be 1, in that case.
[05:24] <mpt> cprov: At /codeofconduct the portlet is empty
[05:24] <mpt> and none of the relevant portlets seem to have launchpad permissions stuff, so I'm not sure where the problem is
[05:24] <spiv> bradb: print representation_in_seconds[0] 
[05:25] <cprov> mpt: should I update the CodeOfConduct spec to accomplish this decision
[05:25] <spiv> bradb: Oh, 1.5, I misread.
[05:25] <cprov> mpt: you are not Admin 
[05:25] <spiv> (I'm clearly up too late now)
[05:25] <spiv> bradb: So, one hack is s/''/'z'/
[05:26] <bradb> spiv: ew!
[05:26] <spiv> bradb: the second element of that tuple is the tie-breaker, you see.
[05:26] <bradb> yeah :)
[05:26] <spiv> You could also do:
[05:26] <bradb> we need an always-higher tiebreaker, but 'z' is, ahem.
[05:27] <spiv> class BiggerThanAnything: def __cmp__(self, other): 1; bta = BiggerThanAnything()
[05:27] <bradb> right
[05:30] <spiv> bradb: An alternative may be to sort the list in descending order.
[05:31] <bradb> spiv: I could create a temp list that holds just the seconds, perhaps?
[05:31] <bradb> (and bisect that)
[05:31] <bradb> i'll do a quick example
[05:32] <spiv> Actually, that's better, yeah: bisect([secs for (secs, text) in rep_in_seconds] , seconds)
[05:32] <spiv> (except with less bad var names)
[05:32] <bradb> right
[05:33] <spiv> Or more cutely: bisect(zip(*representation_in_seconds)[0] , seconds)
[05:34] <spiv> Probably better to do representation_in_seconds = [ ... ] ; maximums, labels = zip(*representation_in_seconds); ... ; bisect(maximums, seconds)  # etc
[05:34] <spiv> You'll figure something out ;)
[05:35] <bradb> spiv: how crack is this? https://chinstrap.ubuntu.com/~dsilvers/paste/fileUoA1mp.html
[05:36] <bradb> (i'm trying to *not* be clever, because clever is hard to maintain ;)
[05:36] <spiv> Well, it's either that, or second_boundaries, display_values = zip(*representation_in_seconds) :)
[05:36] <bradb> right, i'll use zip. i knew there had to be a shorthand
[05:37] <spiv> Which may be too clever.  Just because *I* know that zip(*matrix) inverts a matrix doesn't mean the next person will :)
[05:37] <spiv> I'm happy with your judgement there.
[05:38] <spiv> Well...
[05:38] <spiv>         if matching_element_index in range(len(second_boundaries)):
[05:38] <spiv>             return display_values[matching_element_index] 
[05:38] <spiv> What's that about?
[05:39] <spiv> I'd rather an "if seconds <= second_boundaries[-1] :" than that.
[05:40] <spiv> Hmm, and the way you have it atm will raise IndexError on seconds > 90 I think.
[05:41] <spiv> bradb: https://chinstrap.ubuntu.com/~dsilvers/paste/filegOhPc7.html
[05:41] <bradb> spiv: https://chinstrap.ubuntu.com/~dsilvers/paste/file83r1Jy.html
[05:41] <bradb> it doesn't raise an exception, all the tests pass
[05:42] <bradb> the -1 thing is interesting too, mind
[05:42] <spiv> Hmm.
[05:42] <spiv> Oh, right, I see.
[05:42] <spiv> "matching_element_index in range(len(second_boundaries))" looks ugly to me.
[05:44] <spiv> And the direct test on seconds explains the purpose better.
[05:44] <spiv> And hopefully is more consistent with the other changes I proposed.
[05:44] <spiv> But I'm getting too fuzzy headed...
[05:49] <bradb> spiv: https://chinstrap.ubuntu.com/~dsilvers/paste/fileOta8iB.html seems to have hit the sweet spot
[05:54] <carlos> will be back later today
[05:54] <carlos> see you
[05:56] <mpt> cprov: Sorry, lunch was urgent
[05:57] <mpt> cprov: I should never see an empty portlet, no matter what my permissions are
[05:57] <mpt> it just looks wrong
[06:00] <mpt> so in that case launchpad.Admin should be around the entire portlet, not the single item inside it.
[06:05] <sabdfl> you can put that permission inside the portlet
[06:05] <sabdfl>  <div tal:condition="" class="portlet"> etc
[06:05] <mpt> right
[06:06] <mpt> ok, so I want "is an admin or is not logged in at all"
[06:08] <mpt> (because they might be a logged-out admin)
[06:21] <mpt> spiv: got a minute?
[06:25] <sabdfl> ddaa: you can safely delete those for the moment
[06:26] <ddaa> sabdfl: what do you mean by "for the moment"?
[06:26] <ddaa> either it's deemed useful, or not...
[06:26] <sabdfl> well, forever, unless we decide to resurrect them :-)
[06:27] <sabdfl> there's currenlty quite a lot of data in there
[06:27] <ddaa> sure, for every imported revision we published
[06:27] <sabdfl> as i recall, we want to store some information about each revision, but not the actual files, right?
[06:28] <sabdfl> we want to store, for example, which other revisions got merged into a given revision, don't we
[06:29] <ddaa> That's about how it ended up after we talked you out of storing archive fulltext in the database. But the data we are talking about implementation specific: the name and checksums of individual files in the changeset storage of Arch archives.
[06:30] <ddaa> The only reason I can see to have this data there is to have a "backup" in case the mirror gets compromised. IMO the database is not the right place for that. Otherwise, I'm pretty sure this changesetfile data is useless.
[06:30] <ddaa> Also, these tables are completely irrelevent with bzr, which use a completely different storage.
[06:30] <cprov> mpt: ehe,  no problem
[06:31] <cprov> mpt: you are right about the portlet, my decision produce a strange result
[06:31] <ddaa> sabdfl: these tables store no semantic informations about the revisions.
[06:31] <sabdfl> ddaa: ok, drop those tables
[06:31] <sabdfl> could you draw up a spec for a Revision table, for me?
[06:32] <sabdfl> it may involve a second table, or more, for the semantic richness, such as "revisions merged into a given revision"
[06:32] <sabdfl> call the latter table Merge
[06:32] <sabdfl> unless mpool has a better name for it
[06:33] <ddaa> I could probably do it. But after I get up to speed with the specs you guys have written in br, and after I've cleared the (large) current backlog of very urgent things I have to do.
[06:34] <ddaa> So, if you want it before september I'm afraid you would have to ask someone else, or move some of my load on somebody else.
[06:35] <ddaa> Anything that does not involve fixing current or imminent breakage is way down my todo stack.
[06:36] <ddaa> Right now I'm trying to fix a disconnection problem with the native cvs client so I can reproduce the python import problem...
[06:36] <ddaa> Anytime I touch cscvs or importd, that turns into a recursive descent to hell.
[06:39] <sabdfl> well, you guys wrote that code, and you had months to do it, so little sympathy from here ;-)
[06:40] <sabdfl> strip out the changesetfilehash stuff so at least you can clean all of that out
[06:40] <cprov> mpt: continuing about the "Ack CoC" details, do you want me to work on it ? Does it needs  a quick look of someone from CC ? 
[06:40] <sabdfl> when are you going to come here? we'll spend a few days pair programming on the bits i want done
[06:41] <ddaa> sabdfl: lemme see, I'm currently trying to rent a flat
[06:41] <mpt> cprov: I've used "Register Someone's Signature", with a + icon
[06:41] <ddaa> then on sep. 10 I will attend the marriage of a childhood friend
[06:41] <mpt> cprov: It's in mpt@canonical.com/launchpad--deactionizing--0508 if you want to look (though there's a lot of non-CoC stuff in there)
[06:42] <cprov> mpt: uhm, have you already fixed ?  great, you should change also the URL 
[06:42] <ddaa> sabdfl: depending on how the appartment plans unfold, I may be able to come starting sep. 12.
[06:44] <mpt> cprov: ok, will do
[06:44] <ddaa> I cannot commit to anything right now, as it's all in a state of flux. I might very well be moving to the new appt on the sep. 12 week.
[06:44] <cprov> mpt: thank you for help me on this ;)
[06:45] <mpt> cprov: It's ok, fixing wording is part of my job
[06:46] <sabdfl> ddaa: i am away sep 16-30
[06:46] <ddaa> that's going to be tricky
[06:47] <ddaa> Next week is not possible, as I have an appt visit, and I might be signing the rent for an appt I already visited.
[06:48] <ddaa> (actually, I stand a pretty good chance, so it's a small "might")
[06:49] <ddaa> I'll try to get one week at some point before sep. 9
[06:58] <sivang> sabdfl: what is that revision table going to be used ? to track revisions of upstreams sources that get imported into launchpad's baz repo?
[07:03] <sabdfl> yup
[07:03] <cprov> mpt: do you have time for a quick view on what 've already done for buildd UI ? http://hillary:8086/buildfarm/ ...
[07:04] <ddaa> sivang: yup, at first. Then it will also track revisions of bazaar branches uploaded to the supermirror.
[07:11] <mpt> cprov: ok, so this is what you had before the ABUI spec?
[07:27] <mpt> If a system error occurs at an URL that nothing links to, is that still a bug?
[07:29] <ddaa> duh... it's only a puny 214M, come on you lazy bastard emacs!
[07:30] <kiko> vim rocks
[07:31] <jblack> Yeah. go vim. :)
[07:31] <ddaa> less is faster
[07:33] <jblack> jdub: ping
[07:33] <jblack> duh. its middle of the night for him
[07:35] <sabdfl> is the guess-your-country stuff working again?
[07:36] <sabdfl> no, it's not
[07:43] <ddaa> Apparently, guido likes to add comments in the cvs files after committing...
[07:43] <ddaa> no wonder it cause import tools to blow
[07:44] <kiko> spiv, I am rumbling python-dev about deprecating id(), hee hee
[07:46] <philiKON> was launchpad or rosetta updated to a new version recently?
[07:47] <philiKON> the new translation progress indicators aren't half as useful as the old ones were.
[07:47] <philiKON> they try to look fancier but in fac tthey look goofier
[07:47] <philiKON> and some times don't even work correctly
[07:48] <kiko> philiKON, take it up with mpt 
[07:48] <kiko> there is the issue that they are partially broken
[07:49] <kiko> mpt, can you ask stub to cherry-pick your fix?
[07:49] <philiKON> e.g. when i look at https://launchpad.net/products/zope/+series/zope3.1/+translations, the german and russian bars are broken
[07:50] <philiKON> plus, why do they have to be a gradient now? it makes them harder read (for me)
[07:50] <philiKON> what added value does it have compared to a solid colour?
[07:53] <mpt> philiKON: They were always a gradient. I had to make some of them lighter so that color-blind people could read them.
[07:54] <philiKON> blind
[07:54] <philiKON> :)
[07:54] <philiKON> never looked like gradients to me before
[07:55] <mpt> kiko: I haven't heard back from PQM yet
[07:55] <kiko> uhm
[07:55] <philiKON> i don't mind the weirdly bright colours, but i find the vertical gradient very disturbing
[07:55] <philiKON> anyway, supper
[07:55] <philiKON> bbl
[07:55] <mpt> ok, fair point
[07:55] <mpt> "PQM Queue: 0 scripts"
[08:00] <ddaa> cannot parse this shit
[08:00] <ddaa> it makes no sense
[08:01] <ddaa> mhh... maybe it does... there are extraneous revisions, but they are all merges
[08:01] <ddaa> Keybuk: help!
[08:01] <Keybuk> 'sup?
[08:02] <ddaa> In the python-main rlog
[08:02] <ddaa> for /cvsroot/python/python/dist/src/Lib/test/test_mailbox.py,v
[08:02] <mpt> kiko: Actually, this might be a side-effect of moving to an Async machine
[08:02] <ddaa> rlog says: total revisions: 14;\tselected revisions: 14
[08:02] <ddaa> However
[08:03] <kiko> mpt, ask salgado 
[08:03] <ddaa> there seems to be 16 revisions!
[08:03] <sabdfl> kiko: is there a bug on the request-country-guessing stuff being broken in production?
[08:04] <ddaa> revisions 14, 15 and 16 are 1.3.4.1, 1.8.10.2 and 1.8.10.1
[08:04] <ddaa> and they are all merges
[08:04] <ddaa> (there's some other weirdness that suggests that the ,v files was manually edited by GvR)
[08:04] <kiko> sabdfl, let me find it so you can evaluate
[08:04] <ddaa> Keybuk: can you make any sense out of that?
[08:04] <mpt> sabdfl: yes
[08:05] <kiko> sabdfl, is it https://launchpad.net/malone/bugs/1730
[08:05] <kiko> ?
[08:05] <ddaa> Keybuk: maybe you'd like a command to get the problematic rlog?
[08:05] <Keybuk> please
[08:05] <sabdfl> thanks, yes
[08:06] <kiko> mpt?
[08:06] <kiko> ask salgado to assist you
[08:06] <mpt> yes, he just has
[08:07] <ddaa> holy shit
[08:07] <jblack> kiko: Did you get a chance to read that email? 
[08:07] <ddaa> cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/python rlog python/dist/src/Lib/test/test_mailbox.py
[08:07] <kiko> yes jblack 
[08:08] <kiko> jblack, but the roadmap, while an excellent idea, is missing the launchpad side of things AFAICT
[08:08] <jblack> That's what I was hoping to talk about. I'd love to get you into a datadump mode, and do beautiful things to that. 
[08:08] <jblack> kiko: Yeah. Exactly. Thats why I'm chasing you, and stevea when he gets back. :)
[08:09] <ddaa> Keybuk: I think I have figured it out. Revision 1.1.2.1 contains the log of two other revisions, verbatim, you can tell from the revision numbers.
[08:09] <Keybuk> yeah, was about to say just that
[08:09] <Keybuk> I count 14 revisions, one of which contains the log messages of two others
[08:09] <ddaa> I know exactly what I should do to fix it. There's a todo in the code about the issue.
[08:10] <ddaa> I do not know _HOW_ I should fix it, though.
[08:10] <ddaa> Keybuk: thanks for your help.
[08:11] <ddaa> Keybuk: is there any garantee on the ordering of revisions in rlog?
[08:11] <jblack> kiko: So, when you get a chance, I'd love to "sit down" with you, and add what you know to this document. :)
[08:11] <ddaa> I think that could give a pretty useful heuristic...
[08:12] <ddaa> (after all, that's how the human figures it out)
[08:14] <jblack> kiko? 
[08:14] <kiko> jblack, I'm in a meeting, will be with you after
[08:14] <jblack> Ok. Cool.
[08:21] <ddaa> Mh... actually, what I thought is not going to work.
[08:21] <ddaa> Need to get magic.
[08:21] <ddaa> Keybuk: I need your suggestions about how we could parse that.
[08:23] <Keybuk> I'm not sure I have any useful suggestsions
[08:23] <ddaa> Right now, the parser synchronises at "---"... separators. There's an option to ignore one if it's preceded by a blank line (not enabled, the todo is about trying it that way if it fails when not ignoring), but that would not work here because there are two revisions, and the transition between them looks right.
[08:24] <ddaa> I'm thinking we might be able to do magic with "this revision number _cannot_ happen here, it must be part of the log message", but I need to know the ordering garantees we can expect.
[08:24] <ddaa> making sense?
[08:28] <Keybuk> I don't know if there are any
[08:30] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  more homepage love (patch-2266: mark.shuttleworth@canonical.com)
[08:31] <ddaa> Keybuk: do you know who would know that I could ask?
[08:31] <Keybuk> not off-hand
[08:35] <Keybuk> afaik, the defacto upstream response to problems parsing rlog like this is "don't"
[09:09] <sabdfl> carlos: do we have language packs rocking?
[09:12] <mpt> jblack?
[09:12] <sabdfl> bradb: how's that bug tracker looking?
[09:12] <sabdfl> mpt: how's my new main_template coming along?
[09:12] <jblack> mpt: Right here
[09:13] <mpt> jblack: baz crashed during a switch. It thinks it's in the TO branch, but all the code (checked by diffing against mainline) is still in FROM state. What to do?
[09:13] <mpt> sabdfl: I'll get to it once baz starts cooperating :-)
[09:14] <jblack> Best thing to do would be to file a bug, put the tree off to the side until lifeless gets back on Monday, and do a fresh get.
[09:15] <mpt> jblack: Is that just "baz get rocketfuel@canonical.com/launchpad--devel--0" in-place?
[09:16] <jblack> That should do fine for you, yes.
[09:16] <mpt> ok, ta
[09:16] <jblack> You'll want to give a directory name of course. :) 
[09:16] <mpt> as in, "."
[09:17] <jblack> baz needs to plop it into a subdirectory.
[09:17] <jblack> I'd cd .., rename the broken tree out of the way (mv brokendir ~/brokendir-for-lifeless), then baz get rocketfuel@.... olddir
[09:17] <mpt> ok, thanks
[09:20] <mpt> hmm, that means doing my bugfix again
[09:20] <bradb> sabdfl: working on the bugtask assignee widget review finally. response to spiv's review of my implementation of the other half of PresentingLengthsOfTime is awaiting spiv's confirmation to merge tomorrow. MaloneSearchResults implementation depends on it.
[09:20] <mpt> nm, it was only 2 lines
[09:22] <bradb> sabdfl: there also remains: finishing up the menus, distrorelease CVE report, changing the URLs (again), turning +bugs on distro in a triage page, changing the distro release +bugs page into something else, and probably other things.
[09:23] <sabdfl> source pacakge bugs list?
[09:23] <kiko> landed!
[09:23] <bradb> i landed that a few days ago
[09:23] <sabdfl> cool
[09:24] <bradb> just need to add a couple more portlets (but i confirmed with kiko that it was okay to first check it in a bit minimal on portlets, to keep the size of the diff smaller)
[09:24] <bradb> i landed distro release targeting a few days ago too, which is a huge usability improvement, IMHO
[09:24] <sabdfl> ok
[09:24] <sabdfl> dudes, check out the NEW HOME PAGE!
[09:25] <sabdfl> kiko: as soon as we get sane karma cacheing, we get a list of top hax0rs on the home page too
[09:26] <bradb> sabdfl: nice improvements on the homepage
[09:26] <mpt> cprov: I'm working on ABUI now ... Is a speedy-index something a human will enter manually?
[09:26] <bradb> easier to jump right in
[09:27] <cprov> mpt: yes, it will be. It should be something sane from which we can calculate ETA in the future
[09:27] <mpt> cprov: Can you give an example? I've still got no idea what it is
[09:28] <sabdfl> ABUI?
[09:28] <bradb> BjornT_: I often have a problem creating page tests for pages that involve saving a change on the task page, which then redirects to the bug page. After I'm redirected to the bug page and hit Ctrl-C to stop recording, I get things like:
[09:28] <bradb>   File "/home/bradb/launchpad/lib/zope/app/tests/dochttp.py", line 97, in dochttp
[09:28] <bradb> any idea why?
[09:28] <bradb>     assert (request and response) or not (request or response)
[09:28] <bradb> AssertionError
[09:28] <cprov> sabdfl: AutoBuildUserInterface spec
[09:28] <mpt> sabdfl: AutoBuildUserInterface spec (while waiting for baz)
[09:30] <cprov> mpt: I'm not sure yet, something from 0 til 10 should be enough to represent the performance scale, don't you think
[09:30] <mpt> cprov: I don't know, what do you mean by "performance scale"?
[09:31] <sabdfl> don't sweat this minor stuff guys, get the basics in place
[09:31] <sabdfl> use a number, if theres a number in the db
[09:31] <sabdfl> just get it up
[09:31] <sabdfl> polish can come later
[09:31] <sabdfl> mpt: spend less time perfecting on paper
[09:31] <cprov> mpt: how fast a machine can build a "default" job 
[09:31] <sabdfl> get the data represented natively
[09:31] <mpt> cprov's already implementing it, sabdfl
[09:31] <sabdfl> fine
[09:31] <cprov> sabdfl: indeed
[09:32] <mpt> I just want to know what the field means, coz I had no clue
[09:32] <sabdfl> ok
[09:32] <mpt> I thought it was something for searching
[09:33] <BjornT_> bradb: look in page-test.something directory. in there are a bunch of foo.response and foo.request. but for some foo:s a response is probably missing
[09:34] <bradb> hm
[09:34] <bradb> that sounds like a lot of effort
[09:35] <BjornT_> bradb: if you remove the foo.request with the missing foo.response you can run lib/zope/app/tests/dochttp.py page-test.something > page-test.txt
[09:35] <BjornT_> bradb: yes, it should just work.
[09:37] <BjornT_> bradb: what does the foo.request file contain?
[09:40] <bradb> BjornT_: 
[09:40] <bradb>   File "/home/bradb/launchpad-two/lib/zope/app/tests/dochttp.py", line 97, in dochttp
[09:40] <bradb>     assert (request and response) or not (request or response)
[09:40] <bradb> AssertionError
[09:40] <bradb> bradb@oxygen:~/launchpad-two $ ls /tmp/page-test.-qogHJ/
[09:40] <bradb> watch0001.request  watch0001.response  watch0002.request  watch0002.response
[09:41] <bradb> both .request files look like normal requests to me
[09:42] <BjornT_> hmm, strange.... is any of the .response empty?
[09:42] <bradb> no
[09:43] <bradb> bradb@oxygen:~/launchpad-two $ python lib/zope/app/tests/dochttp.py /tmp/page-test.-qogHJ/ > xx-bugtask-assignee-widget.txt
[09:43] <bradb> Traceback (most recent call last):
[09:43] <bradb>   File "lib/zope/app/tests/dochttp.py", line 197, in ?
[09:43] <bradb>     main()
[09:43] <bradb>   File "lib/zope/app/tests/dochttp.py", line 97, in dochttp
[09:43] <bradb>     assert (request and response) or not (request or response)
[09:43] <bradb> AssertionError
[09:44] <bradb> i'll debug it
[09:46] <bradb> hm, response is None
[09:48] <BjornT_> what's request.path?
[09:49] <bradb> (Pdb) request.path
[09:49] <bradb> '/++resource++treeExpanded.gif'
[09:49] <bradb> one of the request files has two GETs in it. not sure if that matters.
[09:50] <bradb> i.e. watch0002.request
[09:50] <bradb> the corresponding .response has only one HTTP/1.1 200 Ok
[09:51] <bradb> i'll try cutting on the second GET
[09:52] <bradb> darn, that appears to have worked
[09:57] <mpt> When (as instructed on RocketFuelSetup) I enter "baz build-config configs/canonical.com/launchpad/development" I get "arch_pfs_fs_connect: failed to get the dir for configs/canonical.com/launchpad/". Should that be "baz build-config configs/default/launchpad.conf" instead?
[10:03] <mpt> hmm, no, that doesn't work either
[10:05] <mpt> ah, I see what I did wrong
[10:10] <sabdfl> mpt: i really want the main_template we described in brazil to land with the next production update
[10:10] <sabdfl> is that feasible?
[10:14] <mpt> ...
[11:15] <ddaa> Keybuk: actually, I think I found a way to make rlog parsing reliable. I need to talk about it with lifeless, but I think that's the way to go. But it's going to be a lot of work to set up.
[11:15] <bradb> BjornT_: I've got another take on the BugTaskAssigneeWidget on its way shortly...
[11:18] <bradb> BjornT_: btw, IInputWidget.applyChanges appears to have an undocumented requirement to return True or False.
[11:37] <jblack>  You're still in brazil? 
[11:38] <mpt> yup
[11:50] <bradb> BjornT_: I followed up to your review of the bugtask assignee widget. Do you have time to take a look?
[11:54] <ddaa> mpt: I suggest you use rsync instead of archive-mirror
[11:54] <ddaa> that should alleviate some of the pain
[11:55] <mpt> ddaa: I'm in the middle of build-config
[11:55] <mpt> actually, probably nearly finished it
[11:57] <mpt> done 12 out of the 14 LP trees
[12:00] <bradb> yeah, but isn't it an elegant design?
[12:00] <jblack> I usually grab a mirror of everything I could want before I go.
[12:01] <mpt> ddaa: ok, let's try that rsync method
[12:01] <ddaa> 14 trees??
[12:01] <mpt> gnarly, pybaz, hct, pytz, pygettextpo, etc
[12:01] <jblack> mpt: Are you sitting near kiko, by any chance? 
[12:02] <mpt> jblack: he's in earshot
[12:02] <ddaa> mpt: have a look at the rocketsync script
[12:02] <jblack> would you mind asking him if he's going to make the meeting he and I planned a couple hours ago for an hour ago? :) 
[12:03] <mpt> ddaa: I currently have all my stuff in launchpad/launchpad
[12:03] <mpt> ddaa: If I could just work out how to make that launchpad, I'd probably have a working tree
[12:03] <ddaa> mpt: I do not understand. Maybe I lack context.
[12:04] <jblack> ddaa: I think he means that he's got a wedged tree (switch broke on him) and he needs to make it something useful
[12:05] <mpt> ddaa: Context: After following the RocketFuelSetup instructions, ~/ubuntu/launchpad/launchpad/{configs,Makefile,{arch},etc} and ~/ubuntu/launchpad/{configs,Makefile,{arch},etc}both exist.
[12:06] <mpt> (the launchpad/launchpad/ one is the one containing all the code.
[12:06] <jblack> hey! 
[12:06] <jblack> check .arch-cache. that should be close to a partial archive
[12:06] <ddaa> mpt: do you realize that one of those is actually the "dists"
[12:07] <mpt> oh crapitude
[12:07] <jblack>  also, if you have a revision library, you have working trees that you can cp out.
[12:07] <ddaa> maybe some dope told to do something like "baz get rocketfuel@canonical.com/dists--devel--0 launchpad" but it's just utterly confusing.
[12:07] <mpt> dists is supposed to be in ~/ubuntu/
[12:07] <ddaa> ???
[12:07] <ddaa> what does that have to do with ubuntu?
[12:07] <ddaa> whatever... it's just names
[12:08] <mpt> yes
[12:08] <ddaa> so, I'm positive
[12:08] <ddaa> nah
[12:09] <ddaa> dists/configs and launchpad/configs... how confusing :(
[12:09] <mpt> ~/ubuntu/launchpad is a direct result of RocketFuelSetup
[12:09] <mpt> "mkdir ~/ubuntu; cd ~/ubuntu;" etc
[12:10] <mpt> ah, I see what I did wrong
[12:10] <mpt> I did the dists get from inside launchpad/ instead of inside ubuntu/
[12:11] <ddaa> well, you're not supposed to have a launchpad/ dir before checking out dists