[12:05] <carlos> ok, I detected an error in my code, reruning the tests ...
[12:12] <daf> what was the problem?
[12:16] <carlos> daf: a cosmetic change I did
[12:16] <carlos> it broke the python syntaxis
[12:16] <carlos> and seems like I forgot to test it
[12:17] <carlos> the tests work now
[12:17] <daf> ah, good :)
[12:17] <daf> you'll be submitting a merge request, then?
[12:17] <carlos> but it's weird that it caused that big problem...
[12:17] <carlos> yes
[12:22] <carlos> request sent
[12:32] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Preliminar po/pot import from the web and added a missing FROM (patch-916)
[12:32] <carlos> daf: there you have
[12:33] <carlos> daf: do you need anything from me?
[12:33] <daf> not right now
[12:33] <daf> thanks
[12:33] <carlos> ok
[12:34] <carlos> daf: I know that the current code does not catchs any error. It's a know "feature" ;-)
[12:34] <carlos> I planned to fix it tonight, but the test error took more time that it should
[12:34] <carlos>  /s/that/than/
[12:36] <daf> do we have a bug open for it?
[01:05] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: add a confirmation message showing bug id after adding a bug (fixes #94) (patch-917)
[01:11] <dilys> Malone bug #94 fixed for package malone: No confirmation of bug ID or success when a bug is filed
[01:11] <dilys> https://dogfood.ubuntu.com/malone/bugs/94
[01:50] <Kinnison> <transformation type="pumpkin"/>
[01:50] <Kinnison> Night all
[09:14] <lifeless> morning
[09:14] <lifeless> stub: hey hey hey
[09:14] <lifeless> production update time ?
[09:14] <stub> eh?
[09:15] <lifeless> Are there any pending db changes for production? I need to pick a bunch of code updates, would be easier to do a full drop than cherry pick.
[09:16] <stub> Just the Karma table and some Rosetta po-whatsit table constraints. 
[09:17] <lifeless> so,.. shall we ?
[09:17] <stub> Unless the production code needs those changes (doubtful), I'd rather leave the production database at the same patchlevel.
[09:18] <lifeless> so, I don't know if the production code will be affected. in production we hae project, product, buttress, sourcesources, so anything theat the UI touches from there will be impacted.
[09:20] <lifeless> anyway, you pung.
[09:20] <stub> Shouldn't be a problem with the tables I mentioned. However - are you using the Z3 auto generated forms, and in particular any of the 'popup' widgets (select-a-person, select-a-product,select-a-sourcepackage)
[09:21] <stub> (If so, a rollout will be more difficult because the current trunk has a load of full text stuff with scarey database changes, as well as needing a new .deb installed on emperor)
[09:22] <lifeless> ah. ok, I'll cherry pick the specific commits I need.
[09:22] <SteveA> stub: did you see Kinnison's problems with the locale of the full text seach stuff ?
[09:23] <SteveA> stub: also, how's the deployment of roundup going?
[09:23] <stub> I know nothing about Kinnison's problems
[09:24] <stub> I haven't heard back from Elmo re: somewhere to install roundup
[09:24] <lifeless> roundup ??
[09:25] <stub> issue tracker until we develop our own
[09:25] <lifeless> like malone ?
[09:25] <lifeless> or bugzilla ?
[09:25] <stub> malone is a bug tracker
[09:26] <lifeless> so - you pinged me for something ?
[09:27] <stub> I was wondering about the cacherevs in the rocketfuel archive and mirroring (in particular, there appear to be two undocumented options in 'baz archive-mirror' that would speed up mirroring). Also about how baz determines what archive format to use, since 'baz make-archive --mirror-from' appears to use tla-format.
[09:30] <lifeless> baz make-archive should be creating baz format. does for me.
[09:30] <lifeless> dpkg -l bazaar ?
[09:31] <stub> ii  bazaar         1.0            arch revision control system
[09:31] <stub> (updated from own-built today, as per launchpad@ instructions)
[09:32] <lifeless> ok. cat .archive-version for the new archive you've made 
[09:38] <stub> Yup - your are right. I repeated the procedure and the .archive-version is baz this time. User error.
[09:56] <SteveA> stub: Kinnison was getting an error "ERROR: Can't find tsearch config by locale".  I think this is because postgres was running with the locale en_GB.
[09:56] <SteveA> stub: the error is described here.  http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/docs/tsearch-V2-intro.html
[09:59] <stub> On a side note, you seem to get all sorts of crazy things happening if you don't run PostgreSQL as locale C (since it starts using locale aware sorting'n'stuff and things go all pear shaped)
[10:00] <daf> isn't it the encoding that makes more difference than the language?
[10:03] <stub> encoding describes the stored data, so PostgreSQL can validate that the data is correct (yes - this is valid UTF8), and convert to whatever encoding the client requests.
[10:04] <stub> The locale alters the results of functions like sort (I think )
[10:04] <stub> So those crazy germans get their stuff sorted the way they like it
[10:07] <stub> I'll need to go into more depth on this - consensus seems to be 'stick to locale C, and this should have really been the default even if your system locale is set differently', so the fix might be to enforce that rather than have the tsearch2 gumf cope with different locales
[10:07] <stub> (It crops up on the mailing lists regularly, with the normal end result being some poor sod has to blow away their database, recreate and reload from backup
[10:07] <daf> won't a UTF-8 locale use Unicode collation order, though?
[10:08] <stub> Different locales sort the same string differently - in particular, german collates a-z differently to english locales
[10:09] <daf> ah
[10:10] <daf> well, as long as the shared testing/production databases uses the correct locale, we shouldn't have any problem, right?
[10:11] <stub> Using different locales introduces a new variable into the unit tests.
[10:12] <daf> oh, of course
[10:45] <Kinnison> Morning
[10:45] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: page template improvements; add page template title check (patch-918)
[10:53] <elmo> BradB: ?
[10:54] <Kinnison> brad is unlikely to be around until ca. 12.30
[11:32] <Kinnison> So, anyone here know lots about our use of sqlobject and can tell me where to find an example of how to join two tables where table B has a column A which is a foreign key to A's id column?
[11:35] <spiv_pants> Kinnison: I can probably answer that.
[11:44] <Kinnison>     sources = MultipleJoin('DistroReleaseQueueSource')
[11:44] <Kinnison>     builds = MultipleJoin('DistroReleaseQueueBuild')
[11:44] <Kinnison> look right?
[11:45] <spiv_pants> Yep.
[11:45] <spiv_pants> Sorry, getting distracted by my home ADSL being down :/
[11:45] <kiko> morning
[11:47] <spiv_pants> You can do TableB.select("TableB.columnA = TableA.id", clauseTables=[TableA] )
[11:48] <Kinnison> being able to get at queueitem.sources will do me nicely :-)
[11:55] <SteveA> spiv_pants: tell me about how shipit is going
[11:57] <Kinnison> Morning cprov 
[11:58] <kiko> hey celsn
[11:58] <Kinnison> cprov: with respect to the 'performance' angle, we can store a view in the database to extract all the information we want from the logevents table
[12:03] <cprov> Kinnison: kiko: morning 
[12:04] <Kinnison> cprov: another comment. Make the table name singular since the class name in the app will be the table name and an instance of the class is a single row of the table
[12:04] <Kinnison> cprov: In general table names should be singular
[12:04] <kiko> Kinnison, uhhhh, that's not agreed upon
[12:04] <Kinnison> kiko: No?
[12:04] <cprov> Kinnison: of course we can, but views cannot perform miracles :), anyway I understand your point
[12:05] <kiko> in my book (SQL FOR SMARTIES) tables are always plural. 
[12:05] <Kinnison> cprov: Hopefully the indexes can perform the miracles
[12:05] <kiko> I'm just contesting the "in general" portion
[12:05] <kiko> you could say "in launchpad" and I could agree
[12:05] <Kinnison> kiko: I was thinking "in general within the company" okay, "in launchpad...."
[12:06] <cprov> Kinnison: about the singular table name, in our context, I agree
[12:06] <Kinnison> kiko: You prefer plural table names?
[12:06] <spiv_pants> SteveA: Well.  The script to sync up ids in the shipit db to the launchpad db is close to working as well as it can.  That leaves the tool to make the report scripts continue to work as the only other major task.
[12:07] <kiko> Kinnison, yes, certainly
[12:07] <spiv_pants> Right at this second I'm frustrated by my home DSL suddenly being down (I'm at jdub's atm).
[12:07] <kiko> and joe celko knows better
[12:07] <Kinnison> kiko: I can see arguments either way on the plural vs. singular argument
[12:07] <SteveA> spiv_pants: what about the shipit code?  what about having a "new shipit alpha test" server running on mawson?
[12:08] <SteveA> singular singular singular
[12:08] <spiv_pants> The shipit code is looking good.
[12:08] <spiv_pants> My testing has run out of problems.
[12:08] <Kinnison> SteveA: glad we agree on this :-)
[12:08] <Kinnison> spiv_pants: you're not testing hard enough then :-)
[12:08] <SteveA> spiv_pants: I want to see a demonstration of it running on mawson.  That way, mako and jane and lu can use it
[12:09] <cprov> Kinnison: any other remarks on "Log System" ? 
[12:09] <spiv_pants> SteveA: Agreed.
[12:09] <SteveA> spiv_pants: now?
[12:09] <kiko> Kinnison, cprov: did you make any headway into getting the publishing tables merged?
[12:11] <SteveA> kiko, Kinnison: it really depends if you see a table as a collection of things or as representing a class of things.  Collections can be either singular or plural; plural if they are "countable" things, singular if they are things that you'd commonly refer to by quantity.  Classes of things should always be singular.
[12:11] <Kinnison> kiko: merged?
[12:12] <Kinnison> SteveA: I always see a table as a class. But then I'm off the OO school of database design
[12:12] <kiko> (which is crackheaded)
[12:12] <kiko> Kinnison, well, yes. we want to fix the status section of sourcepackage.
[12:12] <lifeless> nope, few do.
[12:12] <SteveA> Because we are writing an OO application with a relational storage, then our tables "serve" the application, and should be named with the singular. 
[12:12] <Kinnison> kiko: Eh?
[12:13] <SteveA> there is much more code in the application than in the database or in database queries.
[12:13] <Kinnison> lifeless: Which I think is a pity :-)
[12:13] <cprov> kiko: merged ? do you mean the [DBA]  request ? there's nothing to merge yet 
[12:14] <Kinnison> SteveA: I'd rather you didn't. I use both
[12:14] <Kinnison> lu.
[12:14] <kiko> Kinnison, well. 
[12:14] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: merge in brown-paper bag baz archive format support (patch-70)
[12:16] <kiko> Kinnison, never mind. I was hoping we had a schema laid down for publishing that could be merged at this point..
[12:16] <Kinnison> kiko: the publishing schema is already fairly much done
[12:16] <Kinnison> kiko: Or do you mean inheritance policy?
[12:16] <SteveA> Kinnison: it is simple really.  Everyone should be using emacs.  Except when using vi.  Unless they're using both at once.
[12:17] <Kinnison> SteveA: oooh *illuminated*
[12:17] <kiko> I am not really sharp on the details of what is necessary schema-wise (your master plan is obscure to me) but I *would* like us to be able to say that source package A has release X pending
[12:17] <Kinnison> You don't know what you mean by "pending" though
[12:17] <Kinnison> I can tell, because noone knows yet
[12:17] <Kinnison> This is one of the things we need to discuss very early in Mataro
[12:17] <kiko> we're on the same page :)
[12:18] <Kinnison> All I do know is that inheritance policy is very very different from publishing
[12:18] <Kinnison> pending is not and will never be in the publishing tables
[12:18] <kiko> can you afford giving me the "dummy" explanation?
[12:18] <kiko> these terms are just collections of letters to me with no semantic
[12:19] <Kinnison> visit https://wiki.canonical.com/Lucille_2fBraindump
[12:19] <kiko> that's not the dummy explanation hopefully
[12:19] <Kinnison> search for "Thoughts on the derivative distro process"
[12:19] <kiko> I've visited it a number of times
[12:19] <Kinnison> then read "Derivative distro crack"
[12:19] <Kinnison> and "Use cases for Derivative distributions"
[12:20] <Kinnison> That is all I know about it because that's the results of talking with sabdfl about it :-)
[12:21] <kiko> I don't *entirely* grasp why this is a problem for "pending". is it the point that you can not tell if a certain distro will *inherit* a certain package from another?
[12:21] <kiko> okay, here's a concrete question that is "dummies"
[12:21] <kiko> does the upload system handle uploads of packages to specific distros?
[12:22] <Kinnison> An upload is zero or one sources plus zero or more binary package builds uploaded to a distrorelease (and plausibly a distroarchrelease within that distrorelease)
[12:23] <kiko> okay.
[12:23] <kiko> so if you upload a package to a certain distro, is that package not in some visible status "pre-pending, pre-approval, etc"?
[12:23] <stub> Kinnison: OO databases will always be fringe tech until a standard query language is standardized and widely adopted. The closest I'm aware to this goal is Enterprise Java Beans.
[12:24] <Kinnison> when a package is uploaded it does into the queue as "unchecked"
[12:24] <Kinnison> when the package passes preliminary checks it moves into either "accepted" or "new" (or various other states which are unimportant right now)
[12:24] <Kinnison> an upload in "accepted" gets published and passes into "done"
[12:25] <kiko> Kinnison, would it be reasonable to display "unchecked" on a package page?
[12:25] <Kinnison> That transition happens within a single run of the queue
[12:25] <Kinnison> If you really want to work through the queue for a distrorelease then sure.
[12:25] <Kinnison> IMO it's pretty pointless though
[12:25] <kiko> is it pointless giving feedback that a package is still  unchecked in the queue?
[12:25] <cprov> Kinnison: let's have a real case, I'm an pkg uploader, how can I keep track of my just-uploaded package ? tell me the steps til it becomes a current Ubuntu-Hoary-i386 package
[12:26] <Kinnison> kiko: You can display packages in the publishing tables in "Pending" state
[12:26] <kiko> AN ANSWER!
[12:27] <Kinnison> kiko: That means that the package has been accepted into the distrorelease (I.E. is for publishing) but has yet to be published into the distro
[12:27] <Kinnison> But currently there's no way to know if a package is pending acceptance into a distrorelease
[12:27] <Kinnison> E.g. from inheritance or a fresh upload
[12:29] <Kinnison> Okay, so my multiple joins fail
[12:29] <Kinnison> nup :-(
[12:30] <Kinnison>     sources = MultipleJoin('DistroReleaseQueueSource')
[12:30] <Kinnison>     builds = MultipleJoin('DistroReleaseQueueBuild')
[12:30] <Kinnison> what is wrong with those?
[12:30] <Kinnison> They cause:
[12:30] <Kinnison> AttributeError: 'LaunchpadStyle' object has no attribute 'tableReference'
[12:31] <Kinnison> https://chinstrap.warthogs.hbd.com/~dsilvers/queue.py is the entire file
[12:31] <Kinnison> very very very simple stuff
[12:33] <kiko> Kinnison, could we handle the upload 50% at this point?
[12:34] <Kinnison> kiko: ?
 But currently there's no way to know if a package is pending acceptance into a distrorelease
 E.g. from inheritance or a fresh upload
[12:35] <kiko> could we handle at least the upload case?
[12:35] <Kinnison> kiko: assume I am a small child and need things explaining to me. What do you mean by "handle the upload 50% at this point" ?
[12:36] <Kinnison> sorry for the noise
[12:36] <kiko> well
[12:37] <kiko> did I misread the comments you made above?
[12:37] <kiko> Kinnison, it would clarify a lot if you exercised answering cprov's question..
[12:37] <Kinnison> The database can represent uploads, yes
[12:38] <Kinnison> give me a moment to commit this pqm merge
[12:39] <cprov> Kinnison: btw, haven't you defined the joinColumn=' ' on MultipleJoin ?
[12:41] <Kinnison> cprov: see my utterance from 5 minutes ago ;-)
[12:41] <Kinnison> Right, okay, please bear with me as I go through this process..
[12:41] <Kinnison> 1. Ubuntu developer builds the source package
[12:42] <Kinnison> 2. Ubuntu developer uploads it to the lucille upload server
[12:42] <Kinnison> 3. this triggers the UploadHandler to take the new upload; validate it and import it into the database and librarian.
[12:42] <Kinnison> 4. This creates a queue/unchecked entry for the upload
[12:42] <Kinnison> That is the upload process
[12:42] <Kinnison> Then we have the queue process
[12:42] <Kinnison> 1. queue/unchecked is checked and validated.
[12:43] <Kinnison> 2. The accepted item is moved to queue/accepted
[12:43] <Kinnison> 3. queue/accepted items have their publishing records made and marked 'pending'
[12:43] <Kinnison> 4. more housekeeping occurs which is unimportant right now
[12:43] <Kinnison> That is the queue process
[12:43] <Kinnison> Now we have the publishing process
[12:43] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: merge in brown-paper bag baz archive format support test suite fixes (patch-71)
[12:43] <Kinnison> 1. The pending publication records are scanned
[12:43] <Kinnison> 2. The pending files are copied into the archive from the library
[12:44] <Kinnison> 3. the pending records are marked as published
[12:44] <Kinnison> 4. The published records are scanned
[12:44] <Kinnison> 5. Any no-longer-needed records are marked superceded
[12:44] <Kinnison> 6. The superceded records are scanned
[12:44] <Kinnison> 7. Any utterly unreferenced records are moved to PendingRemoval and are given a time-to-live
[12:44] <Kinnison> 8. Any PendingRemoval entries which are now dead are removed
[12:45] <Kinnison> 9. The on-disk archive files are updated
[12:45] <Kinnison> That is the publication process
[12:45] <Kinnison> So the three processes together form the end-to-end chain of events
[12:45] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Queue tables for Lucille (patch-919)
[12:45] <Kinnison> The first is triggered by the upload
[12:45] <Kinnison> the second is a regular event (perhaps every 5 minutes)
[12:45] <Kinnison> the third is a less often regular event (30 minutes for ubuntu, perhaps every hour, or every day or whatever for other distros)
[12:46] <Kinnison> Does that make sense to people?
[12:46] <kiko> I'm still reading
[12:46] <kiko> so U4 is a step we could provide feedback on (package has been uploaded but not checked)
[12:47] <SteveA> daf: I've read through your recent rosetta emails.  great stuff.  can you put together the list of the things you need to do next, to improve the translation process?
[12:47] <Kinnison> U4 is kinda a limbo state
[12:47] <Kinnison> Particularly the package may get rejected at that stage
[12:47] <kiko> then Q2 perhaps. and Q3 certainly
[12:47] <kiko> well, U4 is nice for keeping track of the upload rate
[12:47] <Kinnison> After Q3 you can report
[12:48] <Kinnison> U4 will include making a LogEntry to say about the upload
[12:48] <kiko> that could go into a notices thing?
[12:48] <Kinnison> Plausibly
[12:48] <Kinnison> cprov and I will be discussing the LogEntry stuff today
[12:48] <kiko> Px is very very hazy to me
[12:49] <kiko> Kinnison, is Q3 the same as saying the source package is Accepted in the source package page?
[12:49] <kiko> or are we confusing concepts
[12:49] <Kinnison> Imagine that most of the queue states are entirely housekeeping and you don't tend to see them
[12:49] <Kinnison> particularly things may pass through many states in a single transaction
[12:50] <Kinnison> What matters in Q3 is that the publishing record is created and marked as pending
[12:50] <kiko> ah. accepted in the queue. not a packaged accepted in the distro. right?
[12:51] <Kinnison> Indeed
[12:51] <kiko> s/ged/ge
[12:51] <kiko> THANKS!
[12:51] <Kinnison> The queue really is just for lucille to track uploads
[12:51] <kiko> where in Px does the inheritance issue show itself
[12:51] <Kinnison> Nowhere
[12:51] <Kinnison> inheritance is separate
[12:52] <Kinnison> (or rather not yet discussed in enough depth to be integrated)
[12:55] <lifeless> ok, 1.0.1 baz release should fix the problems reported yesterdayu.
[12:56] <Kinnison> lifeless: debs ready?
[12:58] <SteveA> meeting in 3 mins
[12:59] <lifeless> Kinnison: ya-huh
[01:00] <Kinnison> SteveA: workrave wants me to rest-break, I may be a minute or two late :-)
[01:00] <SteveA> okay
[01:00] <SteveA> I should probably do the same
[01:03] <kiko> has anyone seen these?
 DatabaseException: ERROR: current transaction is aborted, commands ignored until end of transaction block SELECT COUNT(*) FROM EmailAddress WHERE email = 'foo.bar@canonical.com'
[01:03] <SteveA> that doesn't look good
[01:03] <SteveA> meeting time
[01:04] <SteveA> all present, say "aye!" or "@1e!" if you're 1337
[01:04] <debonzi> aye
[01:04] <spiv_pants> aye!
[01:04] <kiko> @le
[01:05] <carlos> aye!
[01:05] <stub> urp
[01:05] <SteveA> lifeless: can you look in on the meeting occassionally?
[01:05] <lifeless> sure
[01:06] <SteveA> elmo: can you also look in on the meeting occassionally?
[01:06] <SteveA> BradB: ?
[01:06] <SteveA> daf: ?
[01:06] <SteveA> cprov: ?
[01:06] <SteveA> salgado sends apologies.  he has an important final exam right now.
[01:07] <SteveA> BradB will be around in 25 mins or so
[01:07] <elmo> SteveA: err, as much as I can - I'm in the DC and my connectivity isn't assured.. 
[01:07] <SteveA> elmo: I'd think that being in the DC you'd have more connectivity than you can handle!
[01:07] <lifeless> no connectivity in the DC ?!?!?
[01:07] <kiko> SteveA, as in *final*, last exam of his undergrad career
[01:07] <stub> debonzi: Sounds like my fault. Got a traceback to email me?
[01:07] <debonzi> stub, sure
[01:08] <SteveA> Ok, let's start with Baz.
[01:08] <debonzi> stub, Ill sent you an email
[01:08] <SteveA> Is anyone not yet using Baz?
[01:08] <elmo> SteveA: I can only use my laptop in certain places and sometimes I have to get out of the way of the contractors in here trying to do their work
[01:08] <kiko> stub, a lot is your fault, based on my experience from yesterday :)
[01:09] <SteveA> ok, cool.  everyone is using baz.
[01:09] <cprov> SteveA: here
[01:09] <SteveA> hi celse
[01:09] <SteveA> hi celso
[01:09] <kiko> I'm using bazoo
[01:09] <lifeless> heh, with rocketfuel changed, you are *all* using baz :)
[01:10] <kiko> no choice but ;)
[01:10] <kiko> alias tla=baz
[01:10] <SteveA> next, roundup and the issue tracking application.
[01:10] <kiko> roundup?
[01:10] <stub> lifeless: Do we have a script to run to convert our local archives to the new format?
[01:11] <lifeless> stub: nope, but I'll do one up.
[01:11] <SteveA> stu will be leading the making of an issue tracking / trouble-ticket tracking application.  this starts with deploying roundup for this purpose, and integrating roundup's concept of logged in users with launchpad
[01:11] <SteveA> elmo is sorting out somewhere to host this roundup instance.
[01:12] <stub> The roundup end of things will be doing the minimum required to handle commercial and non-commercial support requests.
[01:12] <SteveA> I'd like to be able to give jane a decent estimate of when roundup will be running.  Any ideas stub and elmo?
[01:12] <stub> Friday
[01:13] <SteveA> what can we expect to see on friday?
[01:13] <SteveA> or would it be by the end of friday?
[01:13] <kiko> you guys have crazy schedules
[01:13] <stub> Roundup running, accepting issues, login using the auth server.
[01:13] <SteveA> kiko: stub has been working on this before today
[01:13] <stub> And a flag for commercial support
[01:14] <SteveA> stub: we'll want it to look like it is part of the ubuntu site too
[01:14] <SteveA> or at least, have the right logo and colours
[01:14] <sabdfl> hiya
[01:14] <SteveA> hi mark
[01:15] <SteveA> ok, next, shipit
[01:15] <stub> SteveA: This time friday
[01:15] <spiv_pants> I'm working on setting it up on mawson at the moment.
[01:15] <SteveA> spiv_pants: you're installing the "new shipit that authenticates using a launchpad authserver" on mawson
[01:15] <SteveA> stub: thanks.  please keep me up to date with how it's going.
[01:16] <SteveA> spiv_pants: what exactly are you setting up?
[01:16] <spiv_pants> That should be done tonight, connectivity allowing.  (my home dsl is down, but I'm at jdub's atm, but it's starting to get late)
[01:17] <SteveA> do you need to get mysql onto mawson?
[01:17] <SteveA> so you need any help from elmo to get this running on there?
[01:17] <spiv_pants> An authserver for the shipit web app to talk to, and then install the shipit cgis somewhere and get the admins to get apache somewhere pointing at that.
[01:17] <spiv_pants> It uses postgres.
[01:17] <sabdfl> why are we moving shipit?
[01:18] <SteveA> we're not
[01:18] <spiv_pants> sabdfl: This is a test instance, for the new launchpad-enabled code.
[01:18] <SteveA> this is a place to test that the new shipit works as intended
[01:18] <sabdfl> ok
[01:18] <stub> What postgresql server is shippit talking to, and is it being backed up?
[01:18] <SteveA> stub: you mean, the real one?
[01:18] <stub> yes
[01:19] <SteveA> spiv_pants: do you know?
[01:19] <spiv_pants> I don't know much about the production shipit -- I know mako has some dumps in his home dir on chinstrap.
[01:20] <spiv_pants> So I suspect the answer is "not as well as it could be".
[01:20] <spiv_pants> mako's the guy to ask, I think.
[01:20] <SteveA> spiv_pants: can you find out from mako, and take charge of arranging what is necessary
[01:20] <stub> Yup
[01:20] <spiv_pants> Ok.
[01:21] <SteveA> thanks.  please keep me informed about how this is going, and how getting the demo ship-it running is going
[01:21] <SteveA> next: auth server
[01:21] <SteveA> stub: did we have a problem last week with the auth server going insane when it was disconnected from the database?
[01:22] <stub> It stopped authing and elmo bounced it. I don't know if it crashed, hung, or what but elmo might.
[01:23] <SteveA> spiv_pants: can you get whatever logs you need from elmo, or get them yourself if you have login rights, and try to reproduce the problem?
[01:23] <stub> There is a bug in Malone, which I think spiv has grabbed already
[01:23] <spiv_pants> stub: Yeah, I have.
[01:23] <SteveA> ok, great
[01:23] <SteveA> spiv_pants: have you made any progress on it so far?
[01:24] <spiv_pants> Well, I have it using some newer code backed ported from SVN Twisted that in theory fixes the problem deployed, and frustratingly it made no difference :/
[01:25] <SteveA> can we live with "we need to restart the auth server when restarting the golden database" for now?
[01:25] <spiv_pants> I think the next simplest thing to try is probably to make a simple wrapper for psycopg that does the reconnection transparently -- I think stub had a use for that as well?
[01:26] <SteveA> because I'd like spiv_pants to concentrate on shipit until that is done.
[01:26] <stub> SteveA: Sure. Just means someone who can bounce the authserver needs to be around during maintenance - PostgreSQL and emperor have been reliable.
[01:26] <spiv_pants> (If we did make that wrapper, it would probably solve the similar problem in launchpad itself as well)
[01:27] <SteveA> okay, let's look at that wrapper when we're together in mataro.
[01:27] <SteveA> spiv_pants: can you annotate the bug in malone accordingly?
[01:27] <spiv_pants> Sounds good.  I will.
[01:27] <SteveA> great.
[01:27] <SteveA> soyuz and lucille next
[01:28] <SteveA> Kinnison: what's been happening with your work?
[01:28] <Kinnison> Right
[01:28] <Kinnison> Personally I've been working on Gina and then on the lucille queue stuff
[01:29] <Kinnison> Once the dogfood updates happen today; mawson will be in a position to cron-run the script I have to get gina importing hoary into dogfood everyd ay
[01:29] <kiko> also explaining to us numbskulls how it works
[01:29] <stub> Kinnison: Dogfood update has happened
[01:29] <Kinnison> kiko: Aww, I do that for fun :-)
[01:29] <Kinnison> stub: In that case, later today I'll get gina cronned and running
[01:29] <cprov> Kinnison: aha
[01:30] <spiv_pants> SteveA, stub: I can't update the bug, the page on dogfood is broken :/
[01:30] <Kinnison> The lucille queue stuff is coming along slowly but surely. I've been refining my ideas of the queue processing and also helping cprov through getting to grips with the rest of lucille
[01:30] <spiv_pants> Oh, no, just the link.
[01:30] <Kinnison> I've committed to rocketfuel the sqlobject classes and interfaces for the queue so people can start to interrogate it
[01:30] <Kinnison> (although nothing puts stuff in the queue yet)
[01:31] <Kinnison> I did a quick explanation of the end-to-end for uploading through to publication for kiko earlier. It's in the irclog for this channel and also on the Lucille page of the wiki
[01:31] <Kinnison> cprov: would you like to tell what you've done on lucille (you can cover your non-lucille stuff when stevea asks)
[01:32] <cprov> Kinnison: sure
[01:32] <BradB> morning
[01:32] <cprov> I've been working on Librarian Wrapper, it is able to locally cache the files when we run librarian in anoter location
[01:33] <SteveA> hi brad.  you haven't missed anything you absolutely need to know about
[01:33] <BradB> ok
[01:33] <cprov> it works, but still missing some FS lock to avoid multiple instances
[01:33] <SteveA> cprov: what is the librarian wrapper to be used for?
[01:34] <cprov> SteveA: it caches the files locally on LP machine, so we are able to have links to them 
[01:35] <SteveA> does the librarian server files via apache, or on its own?
[01:36] <stub> cprov: What is the use case for that?
[01:37] <cprov> Librarian server by its own on a twisted.web server, the wrapper able us to serve by apache
[01:38] <cprov> stub: the Librarian will run hiden inside your network, and we will keep the package archive under apache and organized as a true archive
[01:39] <SteveA> I think we need some docs that explain how a full Launchpad must be deployed.
[01:39] <kiko> indeed
[01:39] <SteveA> This is becoming rather complex, and I don't feel comfortable that I understand it all.
[01:40] <spiv_pants> SteveA: I need to leave jdub's shortly so I can get the last train back home.  Is there anything else you need from me for this meeting?
[01:40] <stub> Mmm... I originally thought the librarian was to serve the files directly to everyone that needed them, to keep it light and high performance.
[01:40] <Kinnison> SteveA: the librarian wrapper's purpose is to allow lucille to cache archive-related files on the publication machines. This will give us all sorts of space-saving and mirror-saving benefits wrt. hardlinking and so on.
[01:40] <cprov> stub: the Librarian URL for a file would be mawson:8080/1/1/alien.deb, we turn it in mawson/dists/ubuntu/a/alien.deb, or something like it 
[01:40] <SteveA> spiv_pants: that's fine.  please read the summary of the meeting that I'll post later, and ask questions if you need to.
[01:41] <stub> cprov: The librarian URL can be whatever we want it to be - we wrote it and we can change it.
[01:41] <spiv_pants> SteveA: Thanks.  I will.
[01:42] <kiko> Kinnison, can you elaborate on that?
[01:42] <kiko> I, like stub, thought we would serve files directly from the librarian
[01:42] <cprov> stub: I'm not sure if we can really change Librarian to reproduce archive structure as we want, so the wrapper can 
[01:43] <Kinnison> the librarian will serve to the outside world *some* of the files
[01:43] <SteveA> I don't want this meeting to drag on, so let's talk about the librarian particularly at a meeting tomorrow.
[01:43] <Kinnison> SteveA: okay
[01:43] <Kinnison> SteveA: 12:00 UTC?
[01:43] <cprov> SteveA: ok
[01:44] <Kinnison> SteveA: If we can make it 13:00 UTC I'd be happier
[01:44] <SteveA> stub: your call on a later time
[01:44] <kiko> (why did you suggest 12UTC first then? <wink>)
[01:44] <Kinnison> kiko: because I didn't think quickly enough
[01:44] <kiko> you need dual pipelining
[01:44] <stub> I'd be happier with 12:00 - I'm at UTC+11 remember
[01:45] <Kinnison> How about 11:00 UTC then?
[01:45] <SteveA> kiko and cprov?
[01:45] <Kinnison> 12:00 is irritating on a thursday due to having to go buy lunch
[01:45] <stub> Good for me - I think that is Team Brazil's call
[01:45] <kiko> I'm fine with it
[01:45] <kiko> 9am here
[01:45] <stub> (I can do later, I just get fuzzier)
[01:45] <cprov> fine, too
[01:45] <stub> Woohoo... early meeting. 10pm!
[01:45] <SteveA> okay, 11:00 UTC tomorrow, librarian meeting
[01:46] <Kinnison> Cool
[01:46] <SteveA> I mentioned earlier that I'm finding it hard to understand how a full launchpad is deployed
[01:46] <SteveA> We need a document with diagrams that explains this
[01:46] <SteveA> Who is well-placed to produce this?
[01:46] <Kinnison> SteveA: I'd recommend we sit together in Mataro and draw it on paper to begin with
[01:47] <kiko> yeah
[01:47] <SteveA> that's a good point, Kinnison.
[01:47] <cprov> yep
[01:47] <SteveA> spiv_pants: catch that train!
[01:47] <spiv_pants> :)
[01:48] <spiv_pants> See you tomorrow!
[01:48] <SteveA> okay, that can go on the mataro agenda, as one of the first things we need to do.
[01:48] <SteveA> other soyuz business?
[01:48] <SteveA> celso: you had some other things to talk about
[01:49] <cprov> yes
[01:49] <kiko> salgado's hacking karma right now
[01:49] <cprov> I'm working also in Lucille Log System
[01:49] <kiko> we are being bothered by the changes in the pgsql server side of things
[01:49] <kiko> (because we are diskless and run the server on a woody box)
[01:50] <kiko> salgado will bring that up with stub today
[01:50] <kiko> via email
[01:50] <kiko> debonzi's just landed in switzerland
[01:50] <kiko> will be doing polishing on soyuz itself
[01:50] <SteveA> okay.  the only other problem I've heard about with the new stuff is with locales and the full-text search stuff
[01:50] <Kinnison> Yeah, I can't get 'make check' to pass on my desktop
[01:51] <Kinnison> this is *REALLY ANNOYING*
[01:51] <cprov> Every Help on it, please read: https://wiki.canonical.com/Lucille_2fLoggingNotes
[01:51] <Kinnison> because I can't test things before commits
[01:51] <SteveA> stub: you proposed to make postgresql ignore the local and just be in the C locale, right?
[01:52] <stub> btw. Nobody except steve has mentioned any problems, and steve was just relaying a second hand report
[01:52] <carlos> Kinnison: ./test_on_merge.py canonical
[01:52] <Kinnison> I hit it yesterday and was waiting for the meeting to bring it up
[01:52] <SteveA> I'm set to the US and posix locale
[01:52] <carlos> Kinnison: make check seems to have some problems
[01:52] <sabdfl> ok
[01:52] <SteveA> it is possible that the guys in brazil would hit the same problem if they are set to a BR locale
[01:52] <sabdfl> i'm also a bit confused about "running the librarian in another location"
[01:52] <stub> SteveA: Is your *database* set to that?
[01:53] <stub> psql -d template1 -c 'show lc_ctype'
[01:53] <Kinnison> dsilvers@petitemort:~$ psql -d template1 -c 'show lc_ctype'
[01:53] <SteveA> stub: C
[01:53] <Kinnison>  en_GB.UTF8
[01:53] <kiko> stub, that's because we JUST WOKE UP :)
[01:53] <Kinnison> Which will become more and more common as we move to utf8-by-default on hoary
[01:53] <Kinnison> sabdfl: We'll discuss tomorrow
[01:53] <Kinnison> sabdfl: relax for now :-)
[01:53] <stub> Firstly, the postgresql docs explicitly state 'don't use a locale unless you have to'.
[01:54] <SteveA> sabdfl: there is a meeting tomorrow at 11:00 UTC specifically on the librarian
[01:54] <stub> Secondly, it is considered wrong that PostgreSQL defaults the locale to whatever LC_??? is set to when you run initdb, instead of locale C. People have problems, and often have to rebuild their DB with the correct locale. This is a common issue on the postgresql mailing lists, but I havn't followed the details too closely.
[01:55] <stub> Setting the locale to not-C has no effect for english locales afaik except slowing your system down (as it calls the locale aware sort functions etc. instead of the fast ones)
[01:56] <SteveA> we need it to be so that each launchpad developer can run their database so that it is like the dogfood database.
[01:56] <kiko> I can't run the database right now
[01:56] <SteveA> this should not require changing a system-wide setting
[01:57] <kiko> it requires python 2.2 and, well, we're tied to 2.1 because of the postgresql backport we use.
[01:57] <SteveA> kiko: why are you stuck on woody for your server?
[01:57] <kiko> it's mainly an issue on swapping True for 1
[01:57] <stub> SteveA: locale under postgresql is set when you do initdb and affects all databases in that installation. To change it requires blowing it away and recreating. This is because locale change change sort order and affects indexes.
[01:57] <kiko> SteveA, because the server is used by the whole company, and upgrading it is not a trivial undertaking.
[01:58] <SteveA> kiko: try: True except: NameError; False, True = 0, 1
[01:58] <kiko> SteveA, is it okay for me to start doing this sort of change in out python-sql functions?
[01:58] <SteveA> kiko: co-ordinate with stub on that
[01:58] <kiko> I know exactly how to fix it, but I want to get buy-in on the idea
[01:59] <SteveA> it is fine by me, but I think you need to plan to upgrade that server
[01:59] <stub> kiko: What is the result of psql -d template1 -c 'show lc_ctype'
[01:59] <SteveA> at some point in the future
[01:59] <kiko> stub, C, that's not an issue for me.
[01:59] <kiko> SteveA, easier said than done; are we going to move towards 2.2-functionality in pypgsql or are we staying fairly restrained?
[02:00] <SteveA> stub: Can we assume that people can blow their postgres databases away, or dump and restore them if there are precious databases?  Can you give Kinnison instructions on how to re-initialize his databases?
[02:01] <Kinnison> I just want to be able to make check
[02:01] <SteveA> Kinnison, stub: sort it out, mail the list with what you had to do so others can do so if needed in the future.
[02:01] <Kinnison> SteveA: *nod*
[02:02] <SteveA> kiko, stub: work out whether we can live with an old subset of python on the server, mail the list, comment the files, or come back to me if you can't come to an agreement. 
[02:02] <SteveA> Next, Malone.
[02:02] <kiko> thanks.
[02:02] <SteveA> BradB: can you kick off with recent happenings in malone?
[02:03] <BradB> Well, recently I've been trying to work on making life as easy as possible for users.
[02:03] <BradB> I've added the "one-click" actions; accepting, rejecting and fixing bugs can all be done really quickly in the UI now.
[02:04] <BradB> And things to make finding what you're looking for as simple as possible.
[02:04] <BradB> And, when a new dogfood is deployed, the message saying "Successfully added bug # N", which a few people have mentioned really needing.
[02:05] <BradB> We've got a few important issues to solve between now and the time that Ubuntu developers can use this.
[02:05] <SteveA> what are those issues?
[02:05] <BradB> And they involve me being able to sit down with sabdfl for a good 30 mins on IRC.
[02:05] <BradB> Or in Spain.
[02:05] <BradB> SteveA: There's a few things:
[02:06] <BradB> 1. The bug listing is too wide (bug filed). We need to get creative to find a way to present the information as effectively, but in a smaller space.
[02:06] <SteveA> daf: why are you so late for the meeting?
[02:06] <BradB> 2. The bug listing is too slow. It's starting to really slug as more and more bugs get added, and will probably keep doing that until:
[02:06] <Kinnison> lu.
[02:07] <BradB> 3. We need a better DB design for the *BugAssignment tables.
[02:07] <Kinnison> BradB: won't indexes help enough?
[02:07] <daf> SteveA: timezome confusion again :(
[02:07] <BradB> Kinnison: Nope, that's not the issue here.
[02:07] <Kinnison> BradB: oh?
[02:08] <BradB> Kinnison: I haven't gone back yet and really nailed down what's causing it, but there's just plain and simple way too many queries hitting the DB on the bug listing screen.
[02:08] <SteveA> daf: buy a cheap digital travel clock, and keep it on UTC.
[02:08] <Kinnison> BradB: views?
[02:08] <daf> SteveA: yeah, I'm clearly no good at the math
[02:08] <BradB> Kinnison: already been discussed, nope, that won't help either here.
[02:08] <Kinnison> BradB: suck :-(
[02:08] <BradB> Kinnison: It comes down to designing better tables, which we've been discussing in IRC and on list.
[02:09] <BradB> And the /last/ two big things that I see:
[02:09] <kiko> BradB, I can sit with you through some optimizations at mataro, doing this sort of thing on IRC is very hard for me
[02:09] <SteveA> okay, perhaps another issue for early in mataro.
[02:09] <BradB> kiko: Sure...I expect Spain will be a really productive time for Malone. :)
[02:09] <kiko> I have two weeks of usefulness :)
[02:10] <BradB> 4. integrating with BugActivity (keeping a history on what changed on a bug)
[02:10] <BradB> 5. super select widgets
[02:10] <BradB> 6. messages on assignments
[02:10] <BradB> (okay, that was three things)
[02:10] <SteveA> lifeless: how is the progress on getting Zope 3 into arch going?
[02:11] <SteveA> (This is related to us upgrading zope 3 for launchpad, and getting Sources)
[02:11] <BradB> I've been really needing some input from sabdfl, because we don't have time for me to go off implementing something where sabdfl "I didn't want it done /that/ way." :)
[02:11] <BradB> s/sabdfl/sabdfl says/
[02:11] <SteveA> BradB: do you still have productive things to do before going to spain?  Or, are you totally blocked on talking with mark?
[02:12] <BradB> SteveA: I've been fixing other bugs as reported in the collector, which are smaller, yet fairly important details too.
[02:12] <BradB> e.g. adding CVE refs is broken
[02:12] <BradB> fixing that, fixing things here and there.
[02:13] <lifeless> SteveA: not at all, until I get the new pysvn packages elmo was arranging for
[02:13] <elmo> I asked doko to do that, and he's agreed, I didn't realise  it was blocking stuff tho
[02:13] <SteveA> we need this stuff before mataro
[02:14] <SteveA> BradB: is there one significant thing you can have a phone call with mark about, and be able to make good progress on over the next few days?
[02:15] <BradB> SteveA: yeah, definitely
[02:15] <SteveA> what is that?
[02:15] <BradB> 4 and 6 from above (they're somewhat related)
[02:16] <SteveA> okay.  lets get you and sabdfl talking on the phone today.
[02:16] <BradB> ok
[02:16] <SteveA> lifeless, elmo: can you keep me in the loop on getting the pysvn stuff ready and getting zope3 syncing?
[02:17] <SteveA> Rosetta
[02:17] <elmo> SteveA: you realise there's 2 working days left till mataro, right?
[02:17] <SteveA> daf, carlos: where is rosetta at?  
[02:17] <daf> well, it works
[02:17] <carlos> :-)
[02:18] <daf> you add a project and translate it
[02:18] <daf> all through the web
[02:18] <SteveA> elmo: I've been asking for a new Zope 3 for over a week.
[02:18] <lifeless> SteveA: zope3 before mataro is not realistic, not for a full import. sorry, but its not.
[02:18] <lifeless> IF it works first time, sure.
[02:18] <SteveA> lifeless: then, can we find some other way to get a recent Zope 3 into rocketfuel for use with launchpad?
[02:19] <lifeless> sure, I'm happy to do that today.
[02:19] <lifeless> they are very different problems.
[02:19] <daf> there's lots of room for polish, but all the essential operations are there
[02:19] <lifeless> SteveA: paste me the svn url to checkout please.
[02:19] <SteveA> ok, thanks.  I'll send you a FQ SVN revision id to use when I've run some tests on it.
[02:20] <SteveA> daf: you have recently been going through a particular scenario of use with rosetta
[02:20] <daf> SteveA: right
[02:21] <SteveA> and checking that it does what it should do, and seeing what areas need work and polish
[02:21] <daf> namely demonstrating Rosetta to a live audience
[02:21] <SteveA> can you briefly outline that scenario, and say what works
[02:21] <SteveA> (I expect we'll wrap up this meeting in under 15 minutes)
[02:22] <daf> ok
[02:22] <daf> the scenario is that you add a new project to Launchpad
[02:22] <daf> create the project, product, template
[02:22] <daf> import the template
[02:22] <daf> do some translation
[02:22] <daf> and export a PO file
[02:23] <daf> this demonstrates that you can translate a free software program 100% through the web
[02:24] <SteveA> ok.  so that means rosetta works.  well done rosetta team.
[02:24] <carlos> thanks
[02:25] <kiko> cool
[02:25] <SteveA> carlos: you are working on a script to do the time-consuming imports one-after-another
[02:25] <SteveA> how is that going?
[02:25] <carlos> just wake up on time for the meeting, nothing still done
[02:26] <carlos> will do it today
[02:26] <SteveA> okay, good
[02:26] <SteveA> to wrap up, I have a few launchpad things to talk about
[02:26] <SteveA> permissions: anyone used them yet?
[02:27] <carlos> nothing outside launchpad.AnyPerson
[02:27] <SteveA> when you go to a link that requires authentication, then currently you are invited to authenticate using HTTP basic auth
[02:28] <SteveA> I want to make launchpad prompt you with a form for cookie auth in this case
[02:28] <SteveA> however, this conflicts with keeping basic auth alive for page tests.  So, what I'm going to do is make basic auth run only when you access launchpad on port 8086 (the "debug layer" port)
[02:29] <SteveA> accessing launchpad on 8085 (the public production port) will use only cookie auth
[02:30] <SteveA> "place" object that knows about URL context and absolute urls and breadcrumbs.  I didn't get around to fixing this last week.  It is next on my list, as this is very important for the usability of launchpad.
[02:30] <stub> SteveA: I realized that at some point we will need a View permission (for private bugs)
[02:31] <SteveA> stub: okay, can we chat about that tomorrow or in mataro?
[02:31] <kiko> SteveA, sounds like a plan
[02:31] <stub> SteveA: Note that dogfood is running the debug layer so we can get tracebacks
[02:32] <SteveA> hmm... maybe we need a port that offers tracebacks but also does basic auth. 
[02:32] <SteveA> perhaps I'll have an explicit "basic auth" layer
[02:32] <SteveA> that gets turned on separately
[02:32] <SteveA> I'll think about this a bit
[02:32] <Kinnison> SteveA: can you put something like ++basic++/ at the start of a url to allow basic auth or something?
[02:32] <SteveA> I'd rather use a separate port
[02:33] <SteveA> or separate configuration in launchpad.conf
[02:33] <daf> SteveA: I think launchpad.conf might be a good way to do it
[02:33] <SteveA> which brings me on to launchpad.conf
[02:33] <Kinnison> How about "accept basic auth if provided, otherwise do cookie auth" ?
[02:33] <kiko> launchpad.conf!
[02:33] <daf> or some way of passing in a parameter which controls which authentication method to use
[02:33] <kiko> readable in a vanilla python2.1 installation!
[02:33] <SteveA> Kinnison: perhaps I can do that with a tweak of what is currently there.
[02:34] <BradB> kiko: is that a good thing? :P
[02:34] <SteveA> so, we'll work on making more use of launchpad.conf at mataro
[02:34] <kiko> YES
[02:34] <SteveA> status messages: brad did some work on these, and has started using something very simple
[02:34] <SteveA> BradB: please send a message to the list saying what you are doing, and how it works
[02:35] <BradB> SteveA: ok
[02:35] <stub> SteveA: basic auth and fallback to cookie would be good for XML-RPC support
[02:35] <SteveA> by "status messages" I mean "Bug 666 has been added. thanks." messages
[02:35] <BradB> SteveA: It was simplish to use, but turned out to be fairly annoying to find out how to do it. :)
[02:35] <SteveA> stub:  I don't want the server to do XMLRPC on the same port as it does normal browser stuff.
[02:36] <dilys> Merge to 	rocketfuel@canonical.com/launchpad--production--1.5: cherry pick arch support fix from devel (patch-6)
[02:36] <SteveA> page titles: daf implemented a "page title checker", as most or all of our pages should have a meaningful title.
[02:36] <SteveA> I've proposed some ZCML that may make writing page titles easier.  I'd welcome some feedback on the proposal.
[02:37] <SteveA> browser:form directive.  We'll work on this at mataro.
[02:37] <BradB> w00t!
[02:37] <stub> Mataro Z3 Sprint
[02:37] <BradB> is there one!?
[02:37] <SteveA> no
[02:38] <stub> Yer - we are it ;)
[02:38] <BradB> heh
[02:38] <SteveA> I don't think forms will take three days.  so it will be a very short sprint.
[02:38] <SteveA> one more thing: almost everyone turned up to the meeting on time.
[02:38] <SteveA> thank you for that.
[02:38] <kiko> thanks SteveA 
[02:39] <SteveA> one of the things that keeps a distributed company such as ours working effectively is when people keep each other informed about what is going on, and keep to the things they have said they'd do
[02:40] <kiko> SteveA, I do with we used the mailing list and the Wiki more, though. IRC is very stressful for me
[02:40] <SteveA> such as doing things that they agreed to do in meetings, or turning up to talk with people at agreed times.
[02:40] <BradB> kiko: /stressful/? Interesting word to describe IRC. :)
[02:40] <SteveA> kiko: feel free to suggest more of that, when you think it is appropriate.
[02:40] <SteveA> have you seen the film "Bill and Ted's excellent adventure" ?
[02:41] <kiko> I think we fast-spec a lot on IRC, but it's never consolidated into a document
[02:41] <kiko> I miss that a lot
[02:41] <SteveA> kiko: good point
[02:41] <kiko> knowledge isn't being kept structured
[02:41] <carlos> SteveA: dude, you should distribute it with hoary CDs :-D
[02:41] <kiko> and that makes it *hard* to keep up
[02:41] <kiko> I'm living this out with Kinnison's publishing workflow
[02:41] <Kinnison> kiko: I copied the workflow onto the wiki
[02:41] <SteveA> in the film, bill and ted are accidental founders of an advanced civilisation built on the principle "be excellent to each other"
[02:41] <kiko> there is a text, but try making sense of it in 1 hour -- non-trivial
[02:41] <Kinnison> kiko: quite deliberately ;-)
[02:42] <SteveA> I think we need to adopt that meme.
[02:42] <kiko> it's not a take on Kinnison, just that we need an architect that keeps track of docs and helps us edit them
[02:42] <kiko> we lack a person with those skills and time today
[02:42] <kiko> and I miss it.
[02:42] <SteveA> Thanks for the meeting everyone!  I'll write up a summary a little later.
[02:42] <Kinnison> kiko: having someone who dedicates time to documenting things would be excellent
[02:42] <SteveA> kiko: I'll note what you've just said in the meeting summary.
[02:42] <kiko> thanks
[02:42] <daf> would following up everything significant that happens on IRC with mails to the list help us be excellent?
[02:42] <BradB> thanks all
[02:43] <SteveA> be excellent to each other.
[02:43] <daf> (FSVO "significant", of course)
[02:43] <stub> Does anyone else feel that we would be better off keeping docs in arch rather than the wiki?
[02:43] <Kinnison> The wiki is a convenient place to build information up
[02:43] <Kinnison> Canonicalising it (sic) into documents in arch might be useful though
[02:43] <daf> stub: yes
[02:43] <daf> stub: for some docs at least
[02:43] <kiko> stub, not really
[02:44] <stub> So is a directory full of files is too, provided you have a script that builds an index and renders to hypertext
[02:44] <kiko> the wiki makes it a lot more accessible, and it controls history
[02:44] <kiko> I can't see why local files would be better than a wiki
[02:44] <kiko> no, I think the problem is a people issue, not a tool issue.
[02:44] <daf> I'm in favour of it for very detailed documents which should be in lockstep with the code
[02:44] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: merge in 1.0.1 (patch-2)
[02:45] <Kinnison> daf: Indeed
[02:45] <kiko> I don't think it's a detail issue either
[02:45] <Kinnison> A lot of the info I produce is mostly braindump so that I don't forget
[02:45] <kiko> or else it becomes a chore
[02:45] <Kinnison> That goes well on the wiki and would suck (IMO) in arch
[02:45] <Kinnison> Once *reality* is documented, that should go into arch
[02:45] <kiko> I really do think it's a launchpad documentation wiki we're missing, and an editor for it
[02:46] <kiko> Kinnison, reality changes; the wiki is good at that
[02:46] <kiko> the essence of software is constant change
[02:46] <Kinnison> kiko: but reality changes in arch, if the docs change in lockstep that's good
[02:46] <daf> kiko: a separate wiki?
[02:46] <stub> I feel the wiki UI is much clunkier than 'your favourite editor', and in the repository you work with every day more accessible. It also gives us more control to build tools and workflow to manage it (eg. assign each document and owner, and warn if a doc hasn't been updated in 4 weeks asking the owner to review it for currentness)
[02:46] <kiko> stub, we could just activate wiki UIs
[02:47] <elmo> oh, btw, could we add that 'enable an external editor' thing to our wiki?  that'd rock
[02:47] <kiko> hyperlinking helps a *LOT*
[02:47] <kiko> and the wiki makes producing a hyperlinked doc much easier
[02:47] <kiko> elmo: seconded, it would probably help stub's concern
[02:47] <Kinnison> elmo: install the mozex extension
[02:47] <kiko> I agree the wiki editor is clunky and I use it less because of it
[02:47] <kiko> but
[02:47] <Kinnison> mozex.mozdev.org
[02:47] <Kinnison> it rocks
[02:48] <kiko> I feel launchpad in general has a tendency to undercommunicate its design and policies
[02:48] <Kinnison> (caution: may need other extensions to access old-style prefs windows)
[02:48] <stub> kiko: I wouldn't want to migrate to a fs based system unless it took the strengths of what we have (hyperlinking etc) and improved on it. Indeed - it would probably resemble a local wiki.
[02:48] <kiko> I don't like detailed documentation at all -- I think that's Python.
[02:48] <kiko> what I do miss is *organized* documentation that gives you the pointers in most of the areas
[02:49] <kiko> i.e. a general idea of publishing workflow
[02:49] <stub> Mmm.... indexed and current.
[02:49] <kiko> built in a conceptual hierarchy that someone that needs the information can come and look
[02:49] <kiko> now moin does have indexes and history
[02:49] <kiko> I like it a lot
[02:50] <kiko> but I feel that unless we have someone that is in charge or organizing it and overseeing the changes and evolution..
[02:50] <kiko> fred brooks argues for this figure in TMMM.
[02:50] <kiko> and now
[02:50] <kiko> enough hand waving
[02:50] <kiko> that is my personal opinion. :)
[02:51] <stub> I think you are right, and that it could be considered a hole in the team. The other hole atm is limi which we will need to address at some point (we need to apoint a CSS nazi at a minimum)
[02:51] <kiko> stub, I'm working on getting a replacement for the second item, we shall see soon if it works out
[02:52] <Kinnison> I can also find my css guide if it'll help
[02:52] <kiko> but the documentation editor is still missed
[02:53] <stub> Kinnison: it is more needing someone to keep it maintainable - if nobody is resposible, it will collapse under a weight of small task-specific hacks.
[02:53] <Kinnison> stub: Hmm yes
[02:53] <kiko> our wiki is an example of stub's last phrase
[02:53] <kiko> it has good content but none of it is organized 
[02:54] <kiko> and what was current is now outdated and a lot of it is rubbish now
[02:55] <stub> I think every document needs an owner, and every document needs to be reviewed by its owner once a month, and we need technology to remind us because this isn't natural and none of us will do it without prompting.
[02:55] <stub> (which is the micro end)
[03:01] <kiko> stub, having someone concerned with the big picture is my concern; we can all keep track of individual docs, but the hierarchy, page size, linking needs a global concern.
[03:04] <SteveA|lunch> kiko, stub: all noted.  I agree.  another goal for mataro: sort out the docs and who is going to hold the big picture.
[03:05] <kiko> thanks.
[03:26] <stub> kiko:  There should be no problem installing both Python and PostgreSQL in a non-standard location and have two PostgreSQL servers running simultaneously - we would just need to start specifying 'port' in the various connection strings.
[03:36] <kiko-afk> stub, what's the long-term plan for pypgsql?
[03:38] <kiko-afk> in terms of features and compatibility?
[03:38] <stub> plpythonu you mean? More of it if anything. Ideally, database constraints will do 'from canonical.validators import foo; foo(data)'
[03:39] <stub> Or do you mean the database driver pypgsql?
[03:43] <kiko-afk> sorry, I mean plpython, of course.
[03:43] <kiko-afk> trying to do too many things at once.
[03:43] <kiko-afk> so you forsee it depending on zope, for instance?
[03:46] <kiko-afk> stub, your answers directly reflect on my stress level for today :)
[04:16] <SteveA> lulu__: ping
[04:17] <lulu__> SteveA:here.
[04:18] <SteveA> what's the email problem?
[04:19] <lulu__> we are having many returns from creating accounts on the site. There seem to be 3 problems that Andrew has identified:
[04:19] <lulu__> 1) bad email addresses
[04:19] <lulu__> 2) bad server config
[04:20] <lulu__> 3) DNS - adelie.warthogs.hbd.com not having a reverse DNS record.
[04:21] <SteveA> is adelie the machine that is running plone?
[04:21] <lulu__> Nope - gentoo.
[04:22] <elmo> adelie's the mail relay for the LAN
[04:22] <elmo> I'm working on it's reverse
[04:22] <elmo> [it requires me to fill in a M$ Word document that crashes Warty's OpenOffice...] 
[04:22] <elmo> [away, phone] 
[04:23] <SteveA> abiword?
[04:23] <SteveA> ok, so elmo is dealing with number 3
[04:24] <lulu__> SteveA: I had another 6 returns today.
[04:24] <SteveA> what about the second point?  what is bad about the server config?
[04:25] <lulu__> SteveA: server config - I assume that's from their side...but this seems to be an abnormally high amount of registration returns.
[04:26] <BradB> props to mozilla for arbitrarily deciding to ignore my kb input
[04:26] <lulu__> SteveA:how should we deal with these returns going forward. Do I need to try and resend them if it's a valid email address?
[04:27] <SteveA> mozilla does that to me from time to time
[04:27] <SteveA> I think it is to do with modal dialogs
[04:27] <BradB> i just gave gdm a kick and things are back to normal now
[04:29] <BradB> my gf was giving me some flack on linux..."on ne peut plus couter des dvds??"..."ben...on peut sauf que c'est pas mal illgal t'se"
[04:33] <SteveA> lulu__: I read through some of the returned messages
[04:34] <lulu__> SteveA:yes
[04:34] <SteveA> one thing that occurs to me: I think some people have the idea that we are giving them a *new* email address.
[04:34] <SteveA> that would explain the people who think they have email addresses @ubuntu.org and @ubuntulinux.org
[04:34] <SteveA> so, we should make it clear that we want their existing email address
[04:34] <SteveA> that they are not getting a new email address
[04:35] <lulu__> SteveA: yes - but we have many who have submitted normal addresses.
[04:35] <SteveA> and maybe disallow any email addresses @ubuntu.org, ubuntu.com, ubuntulinux.org
[04:35] <SteveA> lulu__: one thing at a time
[04:35] <lulu__> good point.
[04:36] <lulu__> SteveA: I will write a short registration FAQ to assist.
[04:37] <SteveA> okay.  as for the rest of the emails you forwarded, they are just people who have not entered their email address properly, or where their mail server has fallen off the network or is misconfigured.
[04:37] <SteveA> not much we can do about that.  i met that all the time when I was doing work for securicor/group4
[04:37] <SteveA> corporate mail servers just aren't well maintained, on the whole
[04:38] <SteveA> the more complex their systems, the worse they're maintained, it seems
[04:39] <SteveA> I wonder what the right point to disallow @ubuntu.com and @ubuntulinux.org addresses is... plone?  auth server?  database?
[04:40] <SteveA> or indeed if it is such a good idea
[04:40] <lulu__> we can place a link to a registration FAQ in the Join_form.
[04:40] <BradB> SteveA: We could validate the email before registering, no?
[04:40] <BradB> i.e. by doing a user lookup
[04:40] <SteveA> you mean within plone?
[04:41] <carlos> in fact, launchpad have already the needed bits to do it
[04:41] <BradB> sure
[04:41] <carlos> we have a field to know if the email is validated or not
[04:41] <lulu__> yes - on submit we validate for @ and . in the email address - can we do it on form submission in the same way?
[04:41] <carlos> we could reject any login from unvalidated emails
[04:41] <SteveA> BradB: that would catch the places where people sign up through plone.  we can expect people who sign up through launchpad to be more clueful.
[04:42] <SteveA> carlos: that won't help
[04:42] <carlos> SteveA: why?
[04:42] <SteveA> carlos: they won't have the password anyway, as it will have been sent to the wrong place
[04:43] <carlos> but we could remove the bad accounts using a postprocess check, of course, the user will not know that they did a mistake
[04:43] <SteveA> BradB: can you do this on the plone server?  I think we should disallow only @ubuntu.com and @ubuntulinux.org
[04:44] <SteveA> ubuntu.org doesn't belong to us, so it doesn't seem right restricting that.  maybe the guys who have that domain would want to sign up to use Ubuntu.
[04:45] <SteveA> carlos: it really doesn't matter if we have un-claimed accounts in the system
[04:46] <SteveA> provided someone doesn't DOS the server by registering thousands of email addresses
[04:46] <carlos> ok
[04:46] <BradB> SteveA: Just curious, why do we want to allow addresses that don't validate on a user lookup?
[04:47] <BradB> Maybe that breaks with catchall email address, I'm not sure.
[04:47] <SteveA> BradB: I don't know.  I haven't thought of that.  Just, this doesn't help with the issue under discussion.
[04:47] <SteveA> BradB: have you arranged to talk with mark on the phone?
[04:48] <BradB> SteveA: It would prevent users with invalid addresses from signing up, which was what I thought was the issue under discussion. :)
[04:48] <BradB> SteveA: not yet, I'm writing an email to lp@ about status messages
[04:48] <SteveA> BradB: I don't get it.  I think I'm being very slow this afternoon.
[04:49] <BradB> SteveA: sender address verification, or whatever the RFC-compliant name for it is.
[04:49] <BradB> SteveA: foo@bar.com => "bar.com, is foo a valid account?"
[04:50] <BradB> I think Plone might actually do this by default, but perhaps our custom-fu circumvents it.
[04:55] <SteveA> BradB: I don't think that works for 99% of email addresses out there anyway.
[04:55] <BradB> I was worried that might be the case (though I don't quite understand why.)
[04:55] <BradB> SteveA: I can hack it to prevent reg's from ubuntu.com and ubuntulinux.org in any case, I was just hoping for a solution that prevents people signing up with email addresses that bounce.
[04:57] <SteveA> BradB: I think the only reasonable way to do that is to have a machine-read envelope return address on the mail, and have software that receives the bounce, links it up with the RFC message id of the email that was sent, and invalidates the sign-up request.
[04:57] <SteveA> We could do that with a custom mail sending / processing tool.  I think we'll want that eventually for launchpad, but it isn't a priority.
[04:58] <SteveA> the guys at POV are working on such a thing for one of their commercial projects I think, so perhaps they can be persuaded to make it open source, or license it to canonical or whatever.
[04:58] <SteveA> or, we might want to re-implement it anyway.
[04:58] <SteveA> but, later
[04:58] <BradB> yeah
[04:59] <BradB> SteveA: Is this email validation change something that should be done today?
[04:59] <SteveA> if it is a quick thing, sure
[04:59] <SteveA> and if it has a low risk of screwing up due to plone's complexity
[05:00] <BradB> Okay. It shouldn't be difficult, I'll take a look after lunch.
[05:00] <SteveA> thanks brad
[05:01] <SteveA> lulu__: once elmo has sorted out the reverse dns, and brad has made this change, and you have updated the docs, then I think that will at least reduce the number of bounced messages.
[05:01] <SteveA> we should maybe change the text on the sign-up page to make it clear that this is your own current email address.
[05:01] <lulu__> Have just done so :o)
[05:01] <SteveA> an email address that you can receive email at
[05:01] <SteveA> great.
[05:02] <lulu__> and am writing an FAQ atm
[05:02] <lulu__> elmo and Steve and Brad, thanks for your time.
[05:02] <SteveA> I expect elmo will be doing this soon, as it is an important thing for all our systems running at the data centre
[05:03] <carlos> SteveA: I'm having problems using the getUtility method from the import daemon and initZopeless
[05:03] <carlos> File "./import-daemon.py", line 22, in run
[05:03] <carlos>     for project in getUtility(IProjectSet):
[05:03] <carlos>   File "/home/carlos/Work/dists/launchpad/sourcecode/zope/src/zope/component/__init__.py", line 77, in getUtility
[05:03] <carlos>     return getService(Utilities, context=context).getUtility(interface, name)
[05:03] <carlos>   File "/home/carlos/Work/dists/launchpad/sourcecode/zope/src/zope/component/__init__.py", line 69, in getService
[05:03] <SteveA> you will have
[05:03] <carlos>     return getServices(context).getService(name)
[05:03] <carlos>   File "/home/carlos/Work/dists/launchpad/lib/zope/component/service.py", line 109, in getService
[05:03] <SteveA> because initZopeless does not read in the zcml
[05:03] <carlos>     raise ComponentLookupError(name)
[05:03] <carlos> zope.component.exceptions.ComponentLookupError: 'Utilities'
[05:03] <carlos> 
[05:03] <SteveA> and does not register any utilities
[05:03] <SteveA> so, we cannot use utilities in these scripts
[05:04] <SteveA> rather than use adapters and utilities, you need to use the classes directly
[05:04] <carlos> ok
[05:04] <SteveA> this is something we'll fix eventually
[05:04] <SteveA> by making initZopeless load in a subset of the zcml
[05:05] <SteveA> like, just adapters and utilities and such
[05:05] <SteveA> but not pages
[05:05] <SteveA> it isn't a priority, though
[05:06] <carlos> SteveA: don't worry, it's already changed
[05:06] <carlos> so it's not a problem there
[05:07] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: forward-compatibility for functional test machinery (patch-920)
[05:09] <ddaa> lifeless: can you please remind me where I can find the source code for the company-internal tla?
[05:10] <lifeless> ddaa: people.nny.com/~robertc/rbtcollins@hotmail.com
[05:10] <lifeless> or more easily, in my home dir on chinstrap
[05:11] <ddaa> I meant the namespace, the location is already registered in my stuff.
[05:11] <lifeless> just grab the tarball
[05:26] <BradB> lulu__: ping!
[05:27] <lulu__> BradB: hey Brad!
[05:27] <BradB> lulu__: hi :) i'm about to make the email validation change. have a min to test in about 2 mins?
[05:27] <lulu__> sure Brad
[05:29] <SteveA> lifeless: mailed you the zope svn details
[05:29] <BradB> lulu__: ok, it's changed, you can go ahead and try it out.
[05:29] <BradB> it prevents @ubuntu.com and @ubuntulinux.org addresses
[05:29] <lulu__> BradB: ok.
[05:29] <SteveA> what does it do if you use one of those?
[05:30] <SteveA> same as if you don't include an "@" ?
[05:30] <BradB> SteveA: yes
[05:30] <SteveA> great
[05:30] <carlos> SteveA: I have the basic daemon done
[05:30] <SteveA> carlos: great
[05:30] <carlos> but I'm having problems with cached data
[05:30] <carlos> first import is done
[05:30] <carlos> but if I add a new one from launchpad
[05:31] <carlos> the daemon does not see it
[05:31] <lulu__> BradB: vaildation check: error msg = The email address you specified is already in use or is not valid. Please choose another one.
[05:31] <lulu__> looks fine on my side.
[05:31] <BradB> cool. did you reg with a normal address too?
[05:31] <BradB> just to be doubly sure.
[05:32] <lulu__> BradB: I have one spare mailing address to test :o)
[05:32] <lulu__> will do...
[05:32] <BradB> thanks
[05:32] <SteveA> carlos: can I see the code?  mail it to me, perhaps
[05:32] <carlos> sure
[05:33] <BradB> sabdfl: ping
[05:34] <SteveA> BradB: you might need to actually phone mark
[05:34] <carlos> SteveA: sent
[05:34] <lifeless> marks in a meeting just now
[05:34] <BradB> ok
[05:35] <SteveA> carlos: module names should not contain a hyphen
[05:35] <carlos> right, I forgot it
[05:35] <carlos> will change it before commit
[05:35] <SteveA> also...
[05:36] <SteveA> no bare except: without a comment
[05:36] <SteveA> and usually, you'll want to log a message, so use the logging api and set up a logger
[05:36] <SteveA> use the logger api rather than printing things
[05:37] <carlos> SteveA: those prints are for debug 
[05:37] <carlos> the code is not final
[05:37] <SteveA> to see an example of the logger api, look in lib/canonical/lucille/uploader/server.py
[05:37] <carlos> ok
[05:37] <carlos> thanks
[05:37] <SteveA> split the run method up into various other methods -- at least one method for what is inside the loop
[05:38] <SteveA> perhaps
[05:38] <SteveA> maybe not -- I think the print statements make it harder to follow, reading it
[05:38] <SteveA> yeah, I think having a method called inside the inner for loop would help readability
[05:39] <carlos> SteveA: if you want I could finish the daemon and then you could read it.. (with comments and excepts...)
[05:39] <carlos> SteveA: I was thinking on move that code inside launchpad/database/pofile.py
[05:40] <carlos> so more or less is the same
[05:40] <lulu__> BradB: ok - when I tried to join with a different full name and a current address (already used) it gave me "Our apologies " 404 error. Does our validation go on a combination of Full name and email address? to create a unique user?
[05:40] <SteveA> it is good style that you wrote it using a small amount of code in the "if __name__ == '__main__':" part, and made it instantiate a class, rather than using many functions. 
[05:40] <carlos> something like pofile.doRawImport() and potemplate.doRawImport()
[05:41] <BradB> lulu__: you login with an email address, so that's as unique as it gets
[05:41] <SteveA> carlos: also, don't sleep after importing
[05:41] <SteveA> do you remember the control flow I wrote down in our meeting?
[05:42] <carlos> SteveA: yeah, but I need to change the code to be able to do it
[05:42] <SteveA> while True:
[05:42] <SteveA>     if file_to_import:
[05:42] <SteveA>         import_file()
[05:42] <SteveA>     else:
[05:42] <SteveA>         sleep(1 minute)
[05:42] <SteveA> this way, there is no unnecessary sleeping
[05:42] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: fix apply-changeset with no target parameter, bug #3584 (patch-3)
[05:43] <lulu__> BradB: yes - so it doesn't matter about display name field at all then. - so the vaildation error should not have been 404 error, it should have been the "this user already exists"....
[05:44] <BradB> lulu__: yes, that's a problem with the auth server though, i believe
[05:44] <carlos> ok
[05:45] <lulu__> BradB: ok. I will need spiv to clear out my test addresses - do you have others u can test?
[05:45] <BradB> lulu__: lulu@bbnet.ca :) (I have a catchall email so anything@bbnet.ca works :)
[05:47] <SteveA> carlos: the zopeless transaction manager needs to clear the cache and maybe join the transaction on a new transaction, that is, after a commit or an abort
[05:47] <SteveA> lifeless: is this what you had to do in your scripts?
[05:47] <SteveA> I think we should change the zopeless transaction manager to do this, and not do this in the scripts.
[05:48] <carlos> SteveA: If I don't force the commit, the transaction is aborted by default
[05:48] <carlos> so that should be also changed
[05:48] <SteveA> no
[05:48] <SteveA> that is good
[05:49] <SteveA> a commit is serious business
[05:49] <lifeless> SteveA: what ?
[05:49] <SteveA> you don't want that happening without saying so
[05:49] <SteveA> lifeless: there was bob2's script that wasn't doing things right on the second transaction
[05:49] <SteveA> you / he fixed it
[05:49] <lifeless> I fixed it.
[05:49] <SteveA> do you think the fix should move into the zopeless transaction manager
[05:49] <SteveA> ?
[05:49] <lifeless> it wasn't joined the connection data adapter to the new transaction.
[05:49] <lifeless> *joining*
[05:50] <lifeless> it is in the zopeless transaction manager.
[05:50] <SteveA> your fix is in the zopeless transaction manager?
[05:51] <SteveA> okay, I see it in there
[05:51] <SteveA> maybe we need to nuke the sqlos cache as well
[05:51] <SteveA> thanks lifeless
[05:53] <carlos> SteveA: how could I nuke it?
[05:56] <SteveA> carlos: with some evil code
[05:56] <SteveA> I need to look into it a bit
[05:56] <carlos> ok
[05:58] <lifeless> SteveA: wouldn't have been muhc point patching around the problem ...
[06:00] <BradB> cprov: ping
[06:09] <dilys> New Malone bug #111: "Functional doctest diff output is incorrect", submitted by Brad Bollenbach
[06:09] <dilys> https://dogfood.ubuntu.com/malone/bugs/111
[06:10] <cprov> BradB: pong
[06:11] <BradB> cprov: can you take a look at bug # 111 please? i fear the diff output situation is worse now. :/
[06:11] <cprov> BradB: sure
[06:11] <BradB> thanks
[06:14] <cprov> BradB: do you mean malone ? it returns http://notready.ubuntu.com/
[06:15] <cprov> BradB: btw, what is this ?
[06:16] <BradB> cprov: the URL is above
[06:18] <cprov> BradB: yep, I see ... is the launchpad.com obsolete ?
[06:19] <BradB> cprov: Yes, it has been for at least a week, I think.
[06:23] <cprov> BradB: ok, I'm aware of this bug related to <BLANKLINE>, I've added myself in CC list and will wrok on it til ES-Conf
[06:25] <BradB> cprov: The only bug related to <BLANKLINE> that I know if is if you go into a test, and replace a <BLANKLINE> with a ..., the test will fail (last I tried that.) This behaviour is something I've definitely never seen before. :)
[06:27] <carlos> SteveA: what does __used_for__ inside a class?
[06:28] <cprov> BradB: I mean a bug inside my difflib patch, the test is correct, it should failed as it did, just the presented diff is wrong, did you get my point ?
[06:29] <SteveA> carlos: it is for documentation
[06:29] <carlos> ok
[06:29] <SteveA> it tells you what its self.context is supposed to be like
[06:29] <BradB> cprov: ok
[06:33] <kiko> BradB, cprov: I reposted to python-dev
[06:33] <kiko> I forgot to CC: you though :-(
[06:35] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: rename tree-lint to lint (patch-4)
[06:41] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: when suggesting files be added, do not suggest taglines, closes bug #4257 (patch-5)
[06:55] <dilys> Merge to rocketfuel@canonical.com/pyarch--devel--0.5: revision-files support baz and tla archive formats (patch-55)
[07:07] <carlos> SteveA: ping
[07:19] <ddaa> lifeless: since I expect you are not going to read the description of the bugzilla bug I just created, I tell it to you directly. The version string of baz devel builds should contain additional information (e.g. the patchlevel) for user support.
[07:19] <lifeless> ddaa: dude, I read all the baz bugs.
[07:19] <ddaa> Even those you already know about?
[07:20] <ddaa> description != summary
[07:39] <lifeless> ddaa: dude, yes.
[07:39] <lulu__> night all :o)
[08:06] <BradB> Anyone know why source package name + distro doesn't uniquely identify a source package? Is SP + DR required to uniquely identify an SP?
[08:08] <elmo> err, yes
[08:08] <elmo> dpkg has two versions in ubuntu, one in warty, one in hoary
[08:09] <elmo> for example
[08:10] <BradB> ok
[08:16] <BradB> What do we lose if an SP points to a DR instead of merely a D?
[08:18] <BradB> elmo: Is SPR + D unique?
[08:18] <elmo> oh, blah, sorry I'm being confused by mark's insane terminology
[08:18] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: unlock the revision in commits if gpg signature fails, to prevent later errors. fixes bug #3482 (patch-6)
[08:18] <elmo> SP+D probably is unique
[08:19] <BradB> elmo: It isn't though. :/
[08:19] <elmo> SPR +D isn't
[08:19] <elmo> BradB: isn't in practice, or isn't in the SQL?
[08:19] <BradB> It isn't in practice.
[08:19] <elmo> err, xample?
[08:21] <BradB> I can't give you a very good answer, because I'm still trying to understand why this db schema is sane, but here's a blurb from a mail Mark sent to lp@ not long ago, related to how to figure out how a user can pick the correct sourcepackage to report a bug on in a distro:
[08:21] <BradB> > Breakage isn't really *required*. We could let the user enter the source
[08:21] <BradB> > package name, and assign it to the "obvious choice" which would be the
[08:21] <BradB> > source package with that name *last uploaded to that distribution*. The
[08:21] <BradB> > maintainer would then be in a good position to reassign the bug to the
[08:21] <BradB> > "other" sourcepackage with the same name, since the maintainer is going
[08:21] <BradB> > to be painfully aware of its existence, since that will be what he has
[08:21] <BradB> > forked off or what has forked off him.
[08:21] <sabdfl> jbailey's salary reqs?
[08:21] <sabdfl> oww ;-)
[08:22] <BradB> sabdfl!
[08:22] <BradB> sabdfl: got a few minutes to discuss a few things?
[08:24] <sabdfl> yes, what's your number?
[08:26] <BradB> +1.514.963.2567
[08:27] <elmo> DUDE, that is an EXCESSIVE salary req
[08:32] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: No more stuff in soyuz.browser. All classes has been moved too launchpad.browser (package.py and distro.py). The zcmls was also changed to import the view class from the right place. (patch-921)
[08:42] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Added the raw po/pot import daemon (patch-922)
[08:51] <sabdfl> so sp +d is not unique in reality
[08:51] <sabdfl> say for example in hoary we start the dev process using package foo from debian
[08:51] <sabdfl> then at some stage we upload our own version
[08:51] <sabdfl> these are *different* sourcepackages
[08:51] <sabdfl> with the same name
[08:51] <sabdfl> in the same distro
[08:51] <sabdfl> e voila
[08:51] <sabdfl> same goes for sp + dr
[08:52] <sabdfl> reality is just ugly, there is no way to work around it
[08:54] <sabdfl> BradB: incoming call
[08:57] <BradB> ok
[08:59] <BradB> SPR + DR
[08:59] <BradB> If /that's/ not unique, we're all doomed.
[09:00] <BradB> Behind the scenes, Malone would be smart enough to create the assignment and the infestation. Afterall, getting bugs reported without having any clue about affected versions is just a pain.
[09:01] <sabdfl> yes, that's unique
[09:02] <sabdfl> but not realistic to expect users to know it for, eg, filing bug reports
[09:02] <sabdfl> BradB: what's your canonical email?
[09:02] <BradB> brad.bollenbach
[09:02] <BradB> for your phone's address book? :P
[09:03] <sabdfl> yes :-)
[09:03] <BradB> heh
[09:06] <BradB> gah!
[09:06] <BradB> i lost network for a bit, sorry
[09:06] <BradB> sabdfl: ^
[10:43] <dilys> New Malone bug #112: "Functional doctest generator breaks on cve ref add test", submitted by Brad Bollenbach
[10:43] <dilys> https://dogfood.ubuntu.com/malone/bugs/112
[10:58] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: reconnect the wires so that CVE ref adding and editing works again after the web link/cve ref refactoring that happened not too long ago (patch-923)
[11:10] <BradB> sabdfl: You said it's expected that the maintainer of foo has to go in and mark resolved all bugs that his brand new foo package upload fixes, right?
[11:10] <sabdfl> yes
[11:10] <sabdfl> so if ubuntu/hoary has a package foo inherited from somewhere else, with bugs
[11:10] <sabdfl> and the maintainer uploads a new package
[11:11] <sabdfl> then he can mark those bugs fixed
[11:13] <BradB> it gets a bit weird if a user files a bug-with-patch using the older source package of the same name, but i guess the maintainer'll realize that such things will happen when they upload a newly created package for foo
[11:39] <sabdfl> yes
[11:39] <sabdfl> basically, because life is shit, we can't have it perfect every time
[11:39] <sabdfl> if there was a law saying nobody could repeat a source package name, then this would be easy
[11:39] <sabdfl> but there isn't
[11:39] <sabdfl> and besides, if that law existed, then a bunch of things would be very difficult for the distro team
[11:40] <sabdfl> every time they wanted to inherit a package they would have to give it a new name
[11:40] <BradB> yeah, i can see why
[11:40] <BradB> yeah
[11:50] <SteveA> there are many times in different pieces of software I'd like a "disambiguate" function.  If there's just one of something, it shows you it as simply as possible.  If there are several, it shows you the most appropriate distinguishing feature.
[11:50] <SteveA> This is a problem in schooltool, for example, when you have several students who share the same names.
[11:52] <BradB> SteveA: the biggest problem is that user's generally aren't literate enough to be able to choose a precise version on which to file the bug. if they were able to do that, all would be well.
[11:55] <SteveA> this will improve when we get more OS integration
[11:56] <SteveA> you know, the "report a bug on this app" that goes into the issue tracker, and might make its way to the bug tracker
[11:56] <SteveA> I missed the word "menu item" in there
[11:56] <BradB> :)
[11:56] <BradB> yeah, that'd be really neat
[11:57] <SteveA> we'll be doing that
[11:57] <SteveA> ubuntu will be the best supported os out there