[12:13] <BradB> sabdfl: Hm...I know we spent a while discussing this, so it might seem like a crazy idea, but I almost wonder if it's cheaper (less time, less cost) to simply forget about merging assignments into one table, leave them as is, and do bare SQL to speed up the bug listing when needed. That's really the one and only problematic screen by having them in two separate tables.
[12:13] <sabdfl> there is another big advantage to the consolidation
[12:13] <sabdfl> we can potentially allow people to refer directly to the id of the BugAssignment table
[12:13] <sabdfl> upload package foo1.1.1-1 fixes assignment#3134532
[12:13] <BradB> sabdfl: we can do that now
[12:13] <sabdfl> no we can't
[12:13] <BradB> we'd just combine bug id + ass id
[12:13] <sabdfl> yuck
[12:13] <BradB> 1-12
[12:13] <BradB> 1-13
[12:13] <BradB> no?
[12:13] <sabdfl> 3536563-345365633632
[12:13] <sabdfl> ?
[12:13] <BradB> heh
[12:13] <sabdfl> will the second number refer to a packageassignment or productassignment?
[12:13] <sabdfl> what if the numbers don't match?
[12:13] <BradB> sabdfl: er, yeah, hmph
[12:13] <sabdfl> i.e.
[12:14] <sabdfl> ok
[12:14] <BradB> ok, i'll keep paring down this pg_dump output
[12:14] <sabdfl> so there is the idea of the "bug number" and the "work number"
[12:14] <BradB> yeah
[12:14] <sabdfl> it's not ideal, because people *will* get confused between them
[12:14] <sabdfl> "but i closed bug #23234234"
[12:14] <sabdfl> "no you didn't you closed the *assignment* #..."
[12:15] <sabdfl> but malone has that extra layer, not much we can do about it
[12:15] <sabdfl> *potentially* we could make the assignment #'s much more visible, so that they are the only numbers people think of
[12:15] <BradB> yeah. but once we have the cross-distro patching, they'll love us.
[12:15] <BradB> yeah
[12:15] <sabdfl> a number then correclates to a specific piece of work for a specific bug
[12:16] <sabdfl> and if you really want to refer to a bug, you can give it a name and use that
[12:17] <sabdfl> i have a working patch for products-without-projects
[12:17] <sabdfl> daf: good work on the page-template-title test idea
[12:17] <daf> sabdfl: thanks!
[12:17] <sabdfl> good thnking: spot the systemic problem, add a verbose check for it, initially in bleat mode
[12:18] <sabdfl> thank YOU!
[12:18] <daf> :)
[12:21] <sabdfl> carlos: i'm seeing the POExportTestCase failure here
[12:51] <carlos> sabdfl: as I said, ./test_on_merge.py canonical pass
[12:51] <carlos> there should be something wrong with make check
[01:10] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: add SQL patch to merge *BugAssignment tables into one BugAssignment table (patch-924)
[01:10] <Kinnison> g'night
[01:48] <daf> spiv: ping
[01:48] <carlos> spiv: here is better
[01:48] <carlos> :-D
[01:55] <spiv> carlos: pong
[01:55] <carlos> spiv: we are having problems with initzopeless and cached values
[01:55] <carlos> we have a daemon script that runs outside launchpad
[01:56] <carlos> that process a queue of po files to import
[01:56] <carlos> and when we add new files from launchpad to the queue, the daemon does not see them anymore
[01:56] <carlos>  /s/anymore/ever/
[01:56] <carlos> SteveA suggested to use: sqlos.connection.connCache.clear()
[01:56] <carlos> after the commit
[01:57] <carlos> but it does not changes anything
[01:57] <daf> our importer calls calls initZopeless when it's instantiated
[01:57] <daf> and commits transactions as it goes
[01:57] <daf> carlos: correct?
[01:57] <carlos> daf: yes
[01:58] <daf> and the problem is fixed if it calls initZopeless for each transaction
[01:58] <daf> but of course, that's not really a good solution (we don't think)
[01:58] <spiv> daf: No, I don't think so either :)
[01:58] <daf> am I right in thinking that initZopeless returns something called a transaction manager?
[01:59] <spiv> carlos: That specification of how to reproduce sounds remarkably close to something that could be turned into a test case... ;)
[01:59] <carlos> daf: I think so, and we use it for the commits
[01:59] <spiv> daf: Yep.
[01:59] <carlos> spiv: excuse me?
[02:00] <spiv> carlos: What if you do a rollback immediately after a commit?
[02:00] <daf> carlos: spiv wants you to write a test case for him :)
[02:00] <spiv> (As a dodgy way to try resync the connection to the database)
[02:00] <carlos> spiv: the connection is working
[02:00] <carlos> spiv: the postgres log shows new transactions
[02:01] <carlos> the start and end with the commit
[02:01] <carlos> and I get data instead of an error
[02:01] <daf> are these transactions subtransactions?
[02:01] <spiv> Oh, I misread the description.
[02:01] <carlos> daf: don't think so
[02:01] <daf> ok
[02:01] <carlos> daf: all them have a start and an end
[02:01] <carlos> before the other starts
[02:02] <carlos> sure I could write a test case
[02:02] <carlos> spiv: where should It be stored?
[02:02] <spiv> carlos: The test case?
[02:02] <carlos> yes
[02:03] <spiv> If it depends on rosetta bits, initially I'd put it in rosetta, and aim to reduce it to something more minimal and move it to canonical.database later (when we know exactly what's going on).
[02:03] <spiv> (And obviously give it a comment saying so)
[02:03] <carlos> ok
[02:04] <carlos> spiv: any suggestion to fix it? :-D
[02:04] <daf> in theory, the same problem will happen with any table, not just Rosetta-specific ones
[02:05] <carlos> One thing I don't understand is that the Postgres log shows some queries
[02:05] <carlos> so it's not caching everything
[02:07] <daf> weird
[02:07] <daf> some queries, but not all?
[02:09] <spiv> carlos: Not yet.  :/
[02:10] <stub> carlos: I think you are seeing transaction isolation in action.
[02:10] <spiv> Ok, there's two possibilities:
[02:10] <spiv>  1. sqlobject is caching objects
[02:10] <spiv>  2. the transaction is isolated, as stub just said.
[02:10] <stub> carlos: If you close and reopen your connecction, you should see the changes launchpad has made.
[02:10] <spiv> I've been assuming 2 was likely, so I think we've been talking a cross-purposes slightly.
[02:11] <stub> carlos: If you want to avoid this (there is no real overhead doing it, as psycopg caches connections I believe), you can explicitly set the isolation level.
[02:11] <carlos> Don't know if it's related...
[02:11] <carlos> 2004-12-02 01:45:23 [19630]  LOG:  statement: BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
[02:12] <spiv> carlos: just to confirm, you've seen launchpad commit its transaction?
[02:12] <carlos> spiv: yes
[02:12] <daf> carlos: hmm, that looks suspicious to me :)
[02:12] <stub> That is psycopg starting the transaction and setting the default isolation level, so it won't see any changes made to postgres until it is committed or rolledback
[02:12] <carlos> and launchpad sees the changes from the script without restarting 
[02:13] <carlos> stub: that's ok
[02:13] <carlos> but it does not sees the changes after the commit
[02:13] <daf> stub: oh, so it shouldn't be causing this problem, then
[02:13] <spiv> So, hypothesis:
[02:14] <carlos> statement: END
[02:14] <stub> it will if I open a psycopg connection, I won't see database changes until *my connection* has been committed or rolled back. 
[02:14] <spiv> Actually, hmm.
[02:14] <daf> stub: I know transactions are committed/rolled back -- I didn't know that connections are
[02:15] <stub> connections get implicit transactions, as per the DB-API
[02:16] <daf> oh, I see
[02:16] <daf> but we cache connections, don't we?
[02:16] <stub> (The implcit transaction is probably done when you execute the first bit of SQL on it, or when you create a curor. It isn't defined)
[02:17] <daf> so if you reuse an old connection, it might be in the middle of an old transaction that is hiding new data
[02:17] <stub> daf: psycopg caches connections, but handles this stuff for you so you don't have to worry. If you have higher level caches, you end up with trouble (which is why we nuke the SQLOS connection cache every request)
[02:18] <daf> spiv: gosh -- it's that bad? :)
[02:19] <carlos> from the logs, seems like all queries are executed into postgres, so it should get fresh data...
[02:19] <stub> spiv: nobody has ever successfully provided a rational as to why it is bad to the DB-SIG, and it won't change unless somebody bothers to. I know I have no problem with it and think it is fine.
[02:20] <spiv> stub: No-one has ever explained to me why it's good, either ;)
[02:21] <stub> spiv: Because requiring con.begin_transaction() would be a dead chicken
[02:21] <kiko> implicitly-created transactions are convenient
[02:21] <stub> spiv: And not all database backends support the notion
[02:21] <spiv> Unless you didn't want to run the statement in a transaction...
[02:22] <stub> spiv: Which is strongly discouraged by everyone except MySQL users
[02:23] <spiv> Heh.  At the time I was an MS SQL Server user :P
[02:23] <stub> (Well.. actually it causes me some grief since I sometimes run wierd postgresql commands like 'create database' that can't be executed inside a transaction....)
[02:23] <dilys> New Malone bug #113: "Write a test case for the cache problem with initzopeless", submitted by Carlos Perell Marn
[02:23] <dilys> https://dogfood.ubuntu.com/malone/bugs/113
[02:25] <stub> Kiko: we were in the middle of a conversation when my ADSL dropped out.
[02:25] <kiko> stub, oh. I thought you reckoned it wasn't a pleasant and just pulled the plug!
[02:25] <stub> kiko: You were bitchi^h^h^h^h^h^hdiscussing plpythonu usage
[02:25] <kiko> I assume too much, it appears.
[02:26] <kiko> well.
[02:26] <kiko> here's the issue
[02:26] <carlos> daf: malone does not likes you, the person search does not see you...
[02:26] <kiko> is the plpythonu cr^hode going as far as requiring zope and launchpad?
[02:26] <kiko> if so, I need to budget some hours for server work
[02:27] <carlos> stub: so, do you think that creating a new connection with initZopeLess is a good solution?
[02:27] <stub> No. Anything I import will be dead simple, only requiring stuff like re
[02:27] <kiko> stub, it would be nice if you could skip True/False for the time being, then. or give us a workaround
[02:28] <kiko> I know that sounds horrible. 
[02:28] <stub> carlos: Sure. Connections are cheap for us.
[02:28] <carlos> spiv: test case filed in malone, will do it tomorrow
[02:28] <carlos> ok
[02:28] <carlos> daf: do you agree?
[02:28] <spiv> carlos: Thank you :)
[02:28] <carlos> could I commit that change?
[02:28] <kiko> but level with me -- I run a debian woody server. we have only one server with disks. 15ish people use it every day. I don't want to break people's work.
[02:28] <daf> carlos: agree? what?
[02:28] <stub> kiko: No problem. I assume you need python2.1 compatibility for any plpythonu code until further notice?
[02:28] <kiko> right.
[02:29] <carlos> daf: to use your workaround calling initZopeLess with every transaction
[02:29] <kiko> I can upgrade the server, but it's an effort that if avoided makes everybody happy
[02:29] <kiko> if you can do that, stub, well, I'm adding to that eternal debt i'm running with you
[02:30] <kiko> now
[02:30] <kiko> stub, there's yet *another* matter 
[02:30] <kiko> it is now impossible to initialize a postgresql server remotely
[02:31] <kiko> it used to be possible using PG_HOST or -h
[02:31] <kiko> but now because you require some sql-fu for the fulltext indexing, I believe, it's no worky
[02:31] <stub> carlos: It is because the system searches on 'words', and daf's name is dafydd in the database. We would need customize our stemmer to make the full text stuff match 'dafydd' if you query for 'daf'. 
[02:31] <carlos> but it worked some days ago
[02:31] <kiko> but who would want to do that?!
[02:32] <carlos> and dafydd is not working
[02:32] <carlos> in the popup window
[02:32] <stub> kiko: ok. That was me being lazy - I had assumed developers were running with their databases on localhost.
[02:32] <carlos> the form accepts it directly
[02:32] <carlos> but the search popup fails to search "daf" or "dafydd"
[02:32] <kiko> stub, I realize; we have an "office" setup here, which is ironically unusual here ;)
[02:32] <stub> carlos: oh - the form also does a substring search on person.name, so that should work...
[02:33] <stub> Kiko: I used to work in an office where we developed on our laptops with not a server in sight ;)
[02:33] <kiko> that's not real work!
[02:33] <kiko> you need a coffee machine and a server room
[02:34] <stub> kiko: We had the coffee machine, and lack of server let us justify kick arse laptops :-)
[02:34] <daf> carlos: oh, sure
[02:34] <carlos> daf: thanks ;-)
[02:35] <kiko> stub, I really appreciate any help you can provide to make my life easier.
[02:35] <kiko> maintaining this whole crapola is a serious effort!
[02:40] <carlos> good night
[02:40] <dilys> Malone bug #77 fixed for product The Rosetta Translation Portal: Implement a potemplate form handler
[02:40] <dilys> https://dogfood.ubuntu.com/malone/bugs/77
[02:49] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fixed the cache problem with the import daemon as daf and stub suggested (patch-925)
[02:53] <kiko> time to run off
[02:54] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Python 2.1 compatibility in plpythonu for Team Brazil's antique system (patch-926)
[10:17] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: relax source defaults and add tags and cscope to precious - closing #3112 (patch-7)
[10:17] <ddaa> bob2: lifeless: so, what is going to be the name the new project to put all the little products in?
[10:18] <stub> spiv: ping
[10:34] <Kinnison> Morning
[10:41] <spiv> stub: pong
[10:42] <daf> psycopg.ProgrammingError: ERROR:  could not find tsearch config by locale
[10:42] <daf> :-/
[10:43] <SteveA> daf: aha, same problem as Kinnison had
[10:43] <daf> did Kinnison manage to fix it?
[10:43] <SteveA> you're obviously using a deviant locale on your machine... maybe CY
[10:43] <daf> I tried changing that
[10:43] <Kinnison> stub and I fixed it
[10:43] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: Removing extraneous file-diffs command in help (patch-8)
[10:43] <Kinnison> but it did involve reinitialising the database from scratch
[10:43] <daf> perhaps I need to explicitly set the locale to C in the configuration file
[10:44] <daf> oh
[10:44] <Kinnison> daf: It's not that easy :-)
[10:44] <daf> grumble
[10:44] <SteveA> wow -- I'm not wearing my glasses and I read that as "ritualising the database"
[10:44] <SteveA> dead chickens anyone?
[10:44] <Kinnison> daf: Do you have data you can't bear to lose or can you reinit your entire pg database?
[10:45] <daf> actually, no, resetting the DB is ok right now
[10:45] <Kinnison> okay, is stub around, or shall I walk you through i?
[10:45] <Kinnison> s/i.$/it?/
[10:45] <Kinnison> Since I need to do it on my laptop too
[10:45] <SteveA> dude, don't rubber chicken me.  <span style="hale and pace">I am "the management".</span>
[10:46] <Kinnison> SteveA: Not even 'da management' can save you from the rubber chicken
[10:47] <SteveA> better stop there.  a bit cold to bury all my clothes.
[10:47] <Kinnison> Heh
[10:48] <Kinnison> stub: ping?
[10:48] <Keith> hi, I'm keith
[10:48] <Kinnison> stop pretending
[10:49] <SteveA> spiv: tell me about how the shipit demo is going
[10:56] <spiv> SteveA: I sent a mail to the admins a while ago about getting apache to point to it, otherwise it should be ready.
[10:57] <sabdfl> morning all
[10:57] <sabdfl> stub: have a patch for ya
[10:57] <daf> Kinnison: what exactly did you do to fix your DB?
[10:58] <stub> Yo
[10:58] <Kinnison> daf: can you wait until I've finished this upgrade? Install postgresql-contrib for now if you haven't already and set up the search path as per stub's mail
[10:59] <daf> Kinnison: done that
[10:59] <sabdfl> anybody else seeing a test failure on POExportTestCase?
[10:59] <Kinnison> daf: right. given that stub appears to not be around, here goes
[10:59] <Kinnison> daf: stop postgresql
[11:00] <daf> ok
[11:00] <stub> spiv: What do I pass to the authservers createUser method as the loginID? 
[11:00] <Kinnison> daf: cd into /var/lib/postgres
[11:00] <Kinnison> daf: mv data data.before-kinni-fucked-it-up
[11:00] <SteveA> spiv: can you cc me into the mail to admins next time?  that allows me to see that things have progressed, but are waiting for the admins to act, without needing to remember to ask you about it.
[11:00] <spiv> SteveA: Oops, yes, good idea.
[11:01] <daf> Kinnison: ok
[11:01] <Kinnison> sudo -u postgres initdb --locale=C --debian-conffile --encoding=UNICODE
[11:01] <daf> hrm: "sudo: initdb: command not found"
[11:02] <Kinnison> sudo su - postgres
[11:02] <spiv> stub: an email address.  I should rename that parameter I guess...
[11:02] <Kinnison> initdb --l......
[11:02] <daf> You must identify the directory where the data for this database system
[11:02] <daf> will reside.  Do this with either the invocation option -D or the
[11:02] <daf> environment variable PGDATA.
[11:03] <Kinnison> add -D /var/lib/postgres/data
[11:03] <Kinnison> to the cmdline
[11:03] <daf> right
[11:03] <daf> /usr/lib/postgresql/bin/initdb: line 648: /etc/postgresql/6328: Permission denied
[11:03] <daf> :_/
[11:03] <daf> s/_/-/
[11:04] <Kinnison> erm, blergh
[11:04] <Kinnison> hold on, my upgrade has almost finished then I'll try
[11:06] <stub> daf: Your -D option didn't take effect - it is trying to create the database in /etc/postgresql
[11:06] <daf> oh
[11:06] <daf> curious
[11:06] <daf> it's having some effect, because it's no longer complaining about the missing option
[11:06] <stub> Oh... hmm..
[11:08] <Kinnison> Do it again without the --debian-conffile option
[11:08] <Kinnison> then cd into /var/lib/postgres/data
[11:09] <Kinnison> ln -sf /etc/postgresql/postgresql.conf
[11:09] <Kinnison> then back as root, run /etc/init.d/postgresql start
[11:09] <Kinnison> and then try a 'make' in database/schema
[11:11] <Kinnison> daf: Oh yeah, su back to postgres and create yourself first
[11:11] <daf> yeah, just tripped over that :)
[11:12] <Kinnison> :)
[11:12] <daf> ok, make -C database/schema:
[11:12] <daf> psycopg.ProgrammingError: ERROR:  relation "pg_ts_cfg" does not exist
[11:16] <Kinnison> Did you make the symlink as I said? Did you update postgresql.conf as per stub's mail like I asked?
[11:16] <daf> the symlink is there
[11:16] <daf> I modified postgresql.conf when I installed postgresql-contrib
[11:17] <daf> I just didn't realise at the time that I'd have to totally nuke all my postgres data
[11:17] <Kinnison> you wouldn't have if your system locale when postgres was installed had been 'C'
[11:18] <daf> I didn't know that it would be a problem when I installed it last year :-/
[11:18] <stub> I'd assumed all the Ubuntu and Debian installs would have had the C locale
[11:18] <Kinnison> stub: poor assumption :-)
[11:19] <daf> perhaps the priority of that debconf question is lower now
[11:19] <stub> daf: It seems to come up regularly on the mailing lists
[11:19] <Kinnison> daf: psql -d launchpad_dev -c show\ search_path
[11:19] <daf>  search_path  
[11:19] <daf> --------------
[11:19] <daf>  $user,public
[11:20] <Kinnison> The search path hasn't been updated
[11:20] <daf> but my postgresql.conf says
[11:20] <daf> search_path = '$user,public,ts2'
[11:20] <Kinnison> and /var/lib/postgres/data/postgresql.conf is a symlink to /etc/postgresql/postgresql.conf ?
[11:20] <daf> yes
[11:21] <Kinnison> restart postgres once more
[11:21] <daf> done, search path is still the same
[11:22] <stub> Add 'this is a syntax error' to your postgresql.conf
[11:22] <stub> And bounce
[11:22] <stub> (The postgresql server, not you)
[11:22] <daf> oop!
[11:22] <daf> s!
[11:24] <Kinnison> daf: ?
[11:25] <daf> symlinked into /var/lib/postgres rather than /var/lib/postgres/data
[11:25] <daf> things seem fine now
[11:25] <stub> So simple even a programmer can do it
[11:26] <Kinnison> stub: See, I even remembered the process :0)
[11:26] <daf> thanks!
[11:30] <sabdfl> so nobody else is seeing the test failure on POExportTestCase
[11:31] <Kinnison> sabdfl: I'm just updating to check
[11:34] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: use the current project tree archive by default in archive-mirror fixes bug #4115 (patch-9)
[11:40] <kiko> stub, you are a riot
[11:41] <Kinnison> as fast as baz can be, goddamn it takes ages to star-merge a week's changes
[11:41] <kiko> want a t-shirt?
[11:44] <kiko> the new t-shirt should say MAKE BAZ FAST 
[11:44] <kiko> but I refrained from political issues this time around
[11:44] <Kinnison> to be fair on baz, it is being squeeeeeeezed through a tiny tiny pipe right now thanks to Kamion chewwing all his available bandwidth
[11:44] <kiko> can't he ease up on the pr0n just for your star-merge?
[11:45] <stub> What do you think he is star merging?
[11:47] <stub> Preparing the artwork for the HumanNG theme ;)
[11:49] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: user creation and authentication tests (patch-928)
[11:51] <SteveA> um, i think you mean "testing the artwork for the HumanNG theme"
[11:53] <kiko> how would one test that artwork 8)
[11:54] <sabdfl> Kinnison: try star-merge -t for three-way merges, MUCH faster on my machine
[11:54] <Kinnison> sabdfl: -t ?
[11:54] <sabdfl> three way merge
[11:54] <Kinnison> I was doing a fairly clean merge anyway I think, but I'll bear that in mind
[11:54] <Kinnison> sabdfl: what was taking the time was downloading 69 changesets over a choked link
[11:55] <sabdfl> ah
[11:55] <Kinnison> It only took ca. 30 seconds to star-merge once it had the patches
[11:58] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: Quieter deltas (patch-10)
[11:58] <Kinnison> Librarian meeting time?
[11:58] <SteveA> it is almost time for us to talk about the librarian
[11:59] <kiko> and I am here
[11:59] <kiko> but first, SteveA, debonzi and I have a question
[11:59] <kiko> can I steal a few minutes of your time
[11:59] <kiko> say yes
[12:00] <SteveA> okay
[12:00] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: do not allow newlines in archive locations passed to make-archive and register-archive (bug #3590) (patch-11)
[12:01] <sabdfl> hrmph
[12:01] <daf> why do I see:
[12:01] <daf> /home/daf/src/canonical/dists/launchpad/lib/canonical/database/sqlbase.py:90: UserWarning: Something tried to set a _connection.  Ignored.
[12:01] <daf> ?
[12:01] <daf> (this is when using scripts which use initZopeless)
[12:01] <sabdfl> who changed the layout of the project / product search page?
[12:02] <SteveA> daf: maybe you used initZopeless twice
[12:02] <daf> spiv: ?
[12:02] <sabdfl> i've seen that too
[12:02] <daf> SteveA: don't think so
[12:02] <SteveA> daf: can you reproduce it?
[12:02] <daf> it seems to happen every time I run such a script
[12:02] <SteveA> that's great.  email me about it and I'll find out what is going on.
[12:03] <SteveA> kiko: what's the question?
[12:03] <daf> SteveA: what additional information can I give you?
[12:03] <SteveA> tell me exactly how to do what you did
[12:03] <kiko> SteveA, the question is in what cases are classmethods an acceptable way to obtain a collection of objects?
[12:03] <spiv> daf: It's a warning because I wasn't sure if it would happen, and if it did, I wasn't sure if it would necessarily be a real problem or not.  Probably making it a warning is too conservative, because it looks like it happens harmlessly inside SQLObject.
[12:04] <kiko> SteveA, I use the rule of thumb, if there's no container, a classmethod on the class itself is acceptable
[12:04] <spiv> I might be able to detect a harmless occurance, actually, in which case I could suppress the spurious warnings.  Hmm...
[12:04] <daf> spiv: ah
[12:04] <daf> "LP_DBNAME=launchpad_dev python lib/canonical/rosetta/scripts/show-projects.py" is enough to replicate it here
[12:04] <SteveA> kiko: class methods are a pain in the arse for security.  I'd rather avoid them where possible.
[12:05] <kiko> SteveA, fair enough. How do I get a collection of sourcepackages? 
[12:05] <spiv> Yeah, virtually any script with initZopeless is.  I figured it was better to have the warning than not, at least initially :)
[12:05] <SteveA> they make for confusing code, because you can get to them from an instance or from the class.
[12:05] <SteveA> kiko: write a SourcePackageSet class, I suggest.
[12:06] <SteveA> Kinnison: please say when you have your coffee
[12:06] <kiko> and how do I get an instance of SourcePackageSet?
[12:06] <Kinnison> SteveA: the machine is gurgling enthusiastically
[12:06] <kiko> SteveA, if you can answer that then I think we are gold
[12:07] <SteveA> kiko: getUtility(ISourcePackageSet).  register it as a utility.
[12:08] <SteveA> or, from a script, directly import it and use it, seeing as scripts don't register utilities yet
[12:08] <kiko> use it how? sps = SourcePackageSet()
[12:08] <kiko> sps.getPackages("XXX")
[12:08] <SteveA> this way, collections of database things are a lot like other database things
[12:08] <kiko> or sps = SourcePackageSet("XXX")
[12:08] <SteveA> we have the implementation class, and the interface
[12:08] <kiko> sps.getPackages()
[12:09] <SteveA> sps = getUtility(ISourcePackageSet)
[12:09] <SteveA> sps.getPackage()
[12:09] <SteveA> sps.getPackagesMatching('foo')
[12:09] <SteveA> or whatever you need
[12:09] <Kinnison> SteveA: I now have coffee as black as night, as strong as a hero and as kick-arse-wakeup-goddamnit as a bunch of over-excited geeks at a free-hardware convention
[12:10] <SteveA> so, you're ready to talk librarian.
[12:10] <SteveA> let's talk about the librarian.
[12:10] <SteveA> yesterday, we talked about thel librarian-wrapper thing
[12:11] <SteveA> for making a bunch of files appear as a package layout for serving by apache
[12:11] <SteveA> it is not clear to everyone why such a wrapper is needed
[12:11] <SteveA> also, we talked about how the librarian is to be deployed
[12:11] <Kinnison> you've conflated two concepts right there
[12:11] <Kinnison> The wrapper is nothing to do with laying out packages
[12:11] <Kinnison> :-)
[12:11] <SteveA> whether it serves the outside-world directly, or whether it is served via apache
[12:12] <SteveA> ok, that's my inaccurate introduction done ;-)
[12:12] <SteveA> go ahead, Kinnison
[12:12] <Kinnison> Okay, so cprov has been working on something called the librarian-wrapper which is to be used by lucille
[12:12] <Kinnison> It's purpose is to provide a way to optimise disk-usage and network consumption for archives
[12:12] <Kinnison> Basically it's a local-cache of files uploaded to the librarian. Which can be blown away if needed
[12:13] <Kinnison> The idea is that it should speed up publishing and provide us with a good basis for using hardlinks to optimise disk consumption when we have piles of derivative distributions
[12:13] <spiv> Why isn't it called librarian-cache then? <wink>
[12:13] <Kinnison> Because the cache is only one bit of its functionality as far as lucille is concerned
[12:14] <SteveA> I don't understand "local-cache".  To understand this, I need to understand how this stuff is deployed.
[12:14] <Kinnison> I think that particular explanation will be best performed in a room with everyone present and a whiteboard
[12:14] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: Quieter deltas (patch-12)
[12:14] <Kinnison> it's very hard to draw diagrams and arrows on IRC
[12:15] <kiko> indeed
[12:15] <kiko> Kinnison, just give us a use case for this demon
[12:15] <Kinnison> spiv: you can't rsync the librarian
[12:16] <kiko> why would you need to?
[12:16] <Kinnison> because of archives
[12:16] <spiv> Ok.  Perhaps we should start by discussing archives?
[12:16] <Kinnison> the issue here is more that the launchpad team don't understand debian on-disk archives
[12:16] <Kinnison> Good plan
[12:16] <kiko> go
[12:16] <Kinnison> elmo: stop me if I get any of this wrong
[12:16] <Kinnison> There are two major portions to each archive
[12:16] <Kinnison> the pool and the dists tree
[12:17] <Kinnison> the pool contains all the source packages and binary packages in the distributions
[12:17] <Kinnison> s/s$//
[12:17] <Kinnison> the dists tree contains the Packages/Sources/Release files for each distroarchrelease/distrorelease in the distribution
[12:17] <Kinnison> A single distribution is in a single archive
[12:17] <Kinnison> so ubuntu has one dists/ tree and one pool/
[12:18] <SteveA> let's give this discussion 10 more minutes.  if it isn't clear by then, we'll defer until we meet in person around a whiteboard.
[12:18] <Kinnison> Are you all reasonably happy about this so far?
[12:18] <spiv> I think so.  Effectively, the dists tree has references to files in the pool?
[12:19] <Kinnison> indeed
[12:19] <kiko> so far no news
[12:19] <Kinnison> but if two distroreleases contain the same package (version) then they both point at the same file in the pool
[12:19] <Kinnison> Now, in terms of mirroring etc, this is a very good situation
[12:19] <Kinnison> So we want to present on-disk archives in this format for http, ftp, rsync access
[12:20] <Kinnison> This is what all the lucille publishing stuff is for
[12:20] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: Forgot to commit extra file-diffs in cmds.c before merging (patch-13)
[12:20] <Kinnison> Now. When we have 100 derivative distributions; all of which share most of the same stuff with ubuntu, you'd imagine that the simplest thing to do would be to give each one their own pool/ and dists/
[12:21] <Kinnison> and that is exactly what we want to do
[12:21] <SteveA> so, you need something that takes information from the database, plus files from the librarian, and puts them out into files and directories ?
[12:21] <Kinnison> SteveA: yes. That's what canonical.lucille.Publisher does
[12:21] <SteveA> okay
[12:21] <SteveA> what part of this does librarian-wrapper do?
[12:22] <Kinnison> SteveA: The librarian-wrapper's job is to make sure that when we publish ubuntu, kubuntu, gnubuntu, magix, wibblix and fooble-linux, they continue to share on-disk files which are identical.
[12:22] <Kinnison> This is done by hardlinks
[12:22] <Kinnison> Do you see why this is needed?
[12:23] <spiv> Ok, I think I see.
[12:23] <kiko> I still don't get the "cache" part, but I think I'm close
[12:23] <Kinnison> kiko: The cache works as follows
[12:23] <spiv> In theory, the librarian could be taught to serve files over http in the layout expected for this.  But that doesn't help with the requirements of serving ftp and rsync as well.
[12:23] <Kinnison> kiko: I upload a foo 1.0-1
[12:24] <Kinnison> kiko: lucille uploads the files to the librarian
[12:24] <Kinnison> kiko: it also caches a copy locally on the archive machine
[12:24] <spiv> So a cache of real files on disk makes sense, so we can use the usual (and well-tested) tools for those jobs.
[12:24] <Kinnison> kiko: when it comes to publishing, it doesn't have to re-download the file from the librarian again
[12:24] <Kinnison> kiko: and considering the size of archives, this is well worth it
[12:25] <kiko> hmmm
[12:25] <kiko> would be nicer if the librarian offered a mountable filesystem UI
[12:25] <kiko> i.e. with real filesystem semantics
[12:25] <SteveA> I think I see.  it is a wapper that is used only by lucille's publisher, of the librarian's interface to our software.
[12:26] <Kinnison> kiko: I don't think that's a viable target
[12:26] <Kinnison> SteveA: yes
[12:26] <Kinnison> SteveA: hence it's canonical.lucille.LibrarianWrapper
[12:26] <kiko> I'd have to ask why not
[12:26] <Kinnison> kiko: when was the last time you wrote a filesystem?
[12:27] <spiv> Kinnison: There's actually a fairly nice python library to do that, I think.
[12:27] <spiv> Possibly worth investigating.
[12:27] <kiko> Kinnison,  http://www.freenet.org.nz/python/lufs-python/
[12:27] <Kinnison> spiv: that exposes for rsync too?
[12:27] <kiko> it's not really that hard
[12:27] <SteveA> ok, I'm happy that I understand what I need to understand right now.  The rest, we can leave until mataro.
[12:27] <SteveA> Kinnison: can you write up a few notes from this to the lucille part of the wiki?
[12:27] <Kinnison> SteveA: I will do
[12:28] <sabdfl> thanks Kinnison
[12:28] <SteveA> the thing I missed yesterday was that this was a wrapper only for use by lucille
[12:28] <kiko> Kinnison, also sort out that crazy mess that is the lucille part of the wiki? 8-)))
[12:28] <Kinnison> kiko: crazy mess?
[12:28] <spiv> Kinnison: I was referring to a library to write a filesystem in python -- it binds to user-space filesystem kernel module, iirc.  So it'd be a "real" filesystem, hence rsync would work.
[12:28] <sabdfl> B-)
[12:28] <spiv> Whether that sort of thing is mature enough to use for this, I don't know :)
[12:28] <kiko> that is one scary wikipage dude
[12:28] <Kinnison> spiv: ergh
[12:29] <kiko> Kinnison, it's the lufs-python thing I said, and it's damned cool
[12:29] <kiko> a guy wrote a gmail filesystem using it
[12:29] <spiv> kiko: Have you used it?  I haven't had a chance to play with it yet.
[12:29] <kiko> yeah, it's pants
[12:29] <Kinnison> SteveA: actually; can I leave updating the wiki until we chat about this in mataro?
[12:29] <SteveA>  B-)
[12:29] <SteveA> |3-)
[12:29] <SteveA>  B-)
[12:29] <SteveA> 
[12:29] <spiv> kiko: Good pants or dirty smelly underpants? :)
[12:29] <kiko> spiv, good smelly pants
[12:29] <spiv> Awesome.
[12:30] <kiko> seriously
[12:30] <kiko> gmailfs is bizarre crack, but it works
[12:30] <SteveA> Kinnison: okay.  I'll write up the essentials of this meeting.
[12:30] <spiv> I hoped it was, but it's one of those things that sounds too good to be true :)
[12:30] <kiko> http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html
[12:30] <kiko> except it uses fuse, not lufs
[12:30] <kiko> http://fuse.sourceforge.net/
[12:31] <SteveA> I support the lucille team keeping things simple, in the sense of making something complex out of simple well-known parts. 
[12:31] <Kinnison> SteveA: thanks dude.
[12:31] <sabdfl> SteveA: are the lists still on rince?
[12:31] <Kinnison> kiko: No, I thought about it and decided that the right idea was to wait until we could distill the information into something people would find useful to read
[12:31] <SteveA> This may well be more resiliant than making one complex thing to do a complex job. 
[12:31] <SteveA> sabdfl: um... were last I used the admin interface to them.
[12:32] <kiko> I only meant to tease my precioussss
[12:33] <SteveA> sabdfl: think we should move them onto a canonical machine?
[12:33] <sabdfl> SteveA: at some time, yes
[12:33] <stub> Meanies! Nobody pinged me :-(
[12:33] <kiko> stub, dude, you made me wake up at 7am
[12:35] <kiko> I didn't mean it that way!
[12:35] <kiko> ah, well, time to do something productive
[12:36] <Kinnison> stub: I take it my pinging you broke things?
[12:36] <stub> Kinnison: You crashed gaim
[12:36] <Kinnison> stub: r0xx0r
[12:36] <Kinnison> stub: I was pinging you with http://users.pepperfish.net/dsilvers/mp-ping.wav
[12:37] <kiko_bz> evil
[12:37] <stub> re: librarian filesystems, the web server needs to remain lean and mean - I suspect any virtual filesystem stuff would be the real of other daemons (like this librarian-cache thingy in fact)
[12:39] <sabdfl> SteveA: we need a malone user mailing list
[12:39] <SteveA> Kinnison: this is served with a content type of text/plain
[12:39] <sabdfl> why not just use the existing private malone list, but make it open?
[12:39] <Kinnison> SteveA: it is? eww
[12:40] <sabdfl> alternatively, we could create a malone-users list
[12:40] <sabdfl> as for rosetta
[12:40] <SteveA> when do we need this by?  we could create a new list, in the place where we want lists to live on a canonical server.
[12:41] <sabdfl> no, let's leave the list admin and movement stuff to elmo et al
[12:41] <sabdfl> i'll create a malone-users list in the current location
[12:41] <SteveA> by "we" I meant "ask elmo etc. to do it"
[12:42] <Kinnison> SteveA: updated to audio/x-wav
[12:43] <sabdfl> erk, it's not loving me
[12:45] <Kinnison> what isn't?
[12:47] <carlos> morning
[01:29] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: Fix #3555. (patch-14)
[01:42] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: allow test suites to synthesis a test uid, in case one is not set - bug #3107 (patch-15)
[01:53] <kiko_bz> SteveA, stub?
[01:54] <stub> Yo
[01:54] <kiko_bz> stub, salgado and I have a question about subscribers
[01:54] <kiko_bz> we would consider using it for karma events
[01:54] <kiko_bz> but there's something we are fuzzy about
[01:55] <stub> Its probably the best approach, but go on
[01:55] <kiko_bz> we'd like each callsite that triggers a karma event specify an argument (how much karma to give)
[01:55] <kiko_bz> I'm not sure if that is possible
[01:55] <stub> ( BradB did the event stuff for Malone emails, so probably knows more than me btw )
[01:56] <kiko_bz> or alternatively if we could use a mapping from event to karma points that would be used 
[01:56] <stub> If I remember correctly, events are just objects that implement a particular interface - stick in data to your hearts content.
[01:58] <stub> (this is all from memory from a while ago). I think you just implement an IKarmaEvent inheriting from the relevant interfaces that defines whatever extra info you need. The code then publishes that event and zope shuffles it off to your subscriber.
[01:59] <kiko_bz> salgado, sound doable?
[02:00] <salgado> yep
[02:03] <stub> Brad has created ISQLObjectModifiedEvent which should give you an example - grep should get you started if you just want to see the code.
[02:05] <salgado> stub, i've seen the code yesterday. it looks pretty simple to register new subscribers. 
[02:05] <kiko_bz> goodie
[02:08] <stub> kiko_bz: That plpythonu code happier now? I haven't got a Python2.1/PostgreSQL server to test it on.
[02:08] <salgado> stub, another question... what do you think of distributing tsearch2.sql inside (maybe) database/schema?
[02:08] <kiko_bz> salgado, check out stub's merge on anthem for us when you have a moment
[02:08] <kiko_bz> thanks stub
[02:08] <salgado> I'll check
[02:09] <stub> salgado: I believe tsearch2.sql creates a load of external C server side functions - won't work unless you have the library installed too, and in the location that tsearch2.sql says it is at.
[02:12] <salgado> stub, the problem is when we're creating the database remotely (via PGHOST), and don't have postgres-contrib installed. 
[02:12] <salgado> we don't have it locally, but it's installed on the server
[02:12] <salgado> so, we only need the tsearch2.sql file localy, cause we can't read it from the server
[02:14] <stub> ok. So you copy tsearch2.sql from your server to the location that fti.py expects to find it. I wouldn't want to put it in database/schema because your tsearch2.sql may not be the same as other peoples.
[02:15] <stub> Which reminds me of the other problem kiko mentioned - that I neglected to allow people to specify the port.
[02:15] <stub> erm - hostname
[02:17] <stub> Nope - it should allow specification of a remote host, but has not been tested.
[02:17] <salgado> I think it's easyer if we just use PGHOST. is there any problem with this approach?
[02:21] <stub> The script uses canonical.lp.dbhost and canonical.lp.dbname to connect to the database. canonical.lp.dbname uses LP_DBNAME and LP_DBHOST environment variables to override the default (which is what the makefile does)
[02:22] <stub> (Although I just noticed the makefile is only setting the LP_DBNAME environment variable to pass to fti.py - not the LP_DBHOST one. That should be a quick fix)
[02:24] <stub> 'env LP_DBHOST=myserver make' should propogate it through right now and work
[02:25] <salgado> stub, it should work when creating the database, but not when running lp. 
[02:26] <salgado> when running lp, we need to change package-includes/launchpad-configure-normal.zcml.
[02:26] <salgado> if we use PGHOST, then we don't have to change anything else
[02:27] <stub> A better way is to create a file override-includes/+mydbsetup.zcml with all the configuration, which will override the defaults (using ZCML magic stuff designed for this)
[02:28] <stub> SteveA wants us to break all this junk out into a single configuration file, which will make rollout to production servers simpler and safer.
[02:29] <Kinnison> re
[02:29] <stub> But using the override-includes method works now, and you could add a new rule to the makefile so 'make async-run' or whatever copies that file into the directory and runs
[02:30] <kiko_bz> make async-run is so sweet
[02:32] <SteveA> https://wiki.canonical.com/LaunchpadProcessConfig
[02:32] <SteveA> can you take a look at that list, and add anything else which needs to be configured per-process ?
[02:32] <SteveA> that is, configuration for running the server, not configuration of the software itself
[02:33] <SteveA> when it is implemented, that page will change to a guide on how to use this configuration
[02:33] <stub> make async-run; run-async, run!
[02:47] <SteveA> BradB: got a minute?
[02:48] <SteveA> Kinnison: got a minute?
[02:48] <Kinnison> yep
[02:48] <SteveA> I'm filling in the monthly report to the canonical directors
[02:48] <SteveA> what significant happened on lucille over the last month or so?
[02:49] <Kinnison> Gosh
[02:49] <Kinnison> Give me a sec to summarise
[02:49] <SteveA> okay
[02:49] <SteveA> not looking for much depth
[02:49] <SteveA> just an idea of where we're at in the big picture of getting lucille integrated and deployed and used
[02:50] <Kinnison> Most of the side processes are done. I.E. the publishing stuff, the domination stuff. The database has been through loads of changes to bring it up to scratch
[02:50] <Kinnison> I've dedicated a hell of a lot of my time to getting gina working well too. Perhaps almost 50% of the last month of work for me
[02:51] <Kinnison> We're aiming to have lucille tracking katie as well as we can by the end of es-conf
[02:52] <Kinnison> Where 'We' is myself and cprov (and probably lamont for the buildd stuff)
[02:52] <SteveA> what does that give us?
[02:52] <SteveA> this is basically lucille and katie running in parallel?
[02:54] <Kinnison> yes
[02:55] <Kinnison> there will be things we need to add to lucille and the most effective way to find them out is to try to get lucille to shadow katie
[02:57] <SteveA> what's a succinct definition of "publishing" and "domination" ?
[02:57] <SteveA> lucille is into P+D
[02:58] <SteveA> (I did just check the wiki pages)
[02:58] <Kinnison> The ProjectGlossary carries short definitions of P & D
[02:58] <Kinnison> Are they insufficient?
[02:59] <SteveA> a bit technical.  seems to me that publishing is making a coherent set of packages available that an operating system can install.  
[02:59] <SteveA> domination is clear
[03:00] <Kinnison> Okay, yes that's a reasonable less-technical summary of P
[03:00] <Kinnison> Will you drop it into the glossary?
[03:01] <SteveA> done
[03:01] <SteveA> will we be using lucille with the real live katie next month?
[03:01] <Kinnison> lucille will be tracking katie
[03:01] <SteveA> when we do an actual deployment of soyuz to the golden servers / databases
[03:02] <Kinnison> I'm not sure
[03:02] <Kinnison> I imagine that can only be answered by sabdfl and only after we see where we are at the end of es-conf
[03:02] <SteveA> okay
[03:03] <SteveA> thanks Kinnison
[03:25] <BradB> morning all
[03:26] <sabdfl> SteveA: gina needs some tweaks so that it can run both debian and hoary simultaneously
[03:27] <sabdfl> then we can bring it up in production
[03:27] <sabdfl> i hope during mataro
[03:27] <sabdfl> carlos: i am still eeing the poexport test failure, it's preventing a commit to rf for me
[03:28] <sabdfl> Error in test testPoExportAdapter (canonical.rosetta.ftests.test_poexport.POExportTestCase)
[03:28] <sabdfl> Traceback (most recent call last):
[03:28] <sabdfl>   File "/home/mark/projects/ubuntu/launchpad/lib/canonical/rosetta/ftests/test_poexport.py", line 156, in testPoExportAdapter
[03:28] <sabdfl>     project = Project.selectBy(name = 'gnome')[0] 
[03:28] <sabdfl>   File "../../lib/sqlobject/main.py", line 1238, in __getitem__
[03:28] <sabdfl>   File "../../lib/sqlobject/main.py", line 1242, in __iter__
[03:28] <sabdfl>   File "../../lib/sqlobject/dbconnection.py", line 520, in iterSelect
[03:28] <sabdfl>   File "../../lib/sqlobject/dbconnection.py", line 448, in __init__
[03:28] <sabdfl>   File "/home/mark/projects/ubuntu/launchpad/sourcecode/zope/src/zope/app/rdb/__init__.py", line 308, in cursor
[03:28] <sabdfl>     return ZopeCursor(self.conn.cursor(), self)
[03:28] <sabdfl> InterfaceError: already closed
[03:28] <sabdfl> any suggestions?
[03:28] <SteveA> do you get the same error if you run just that test?
[03:28] <sabdfl> spiv, carlos, SteveA, any pointers where i can look for a solution to this?
[03:28] <SteveA> python test.py -f canonical.rosetta.ftests
[03:29] <SteveA> if you get the same error, that's good because the test is isolated enough so that it fails when run on its own
[03:30] <sabdfl> mark@hagrid:~/projects/ubuntu/launchpad$ PYTHONPATH=./lib/ python lib/canonical/rosetta/ftests/test_poexport.py
[03:30] <sabdfl> .
[03:30] <sabdfl> ----------------------------------------------------------------------
[03:30] <sabdfl> Ran 1 test in 14.238s
[03:30] <sabdfl> OK
[03:30] <sabdfl> Exception exceptions.TypeError: <exceptions.TypeError instance at 0x4112736c> in <bound method Transaction.__del__ of <sqlobject.dbconnection.Transaction object at 0x41091b6c>> ignored
[03:30] <SteveA> if you do not, it means that some transaction context is not being cleaned up properly from a previous test
[03:30] <SteveA> the __del__ thing isn't important.  just some bogosity in how sqlobject does something. 
[03:31] <SteveA> sabdfl: what do you run to get the problem?  just make check?
[03:33] <carlos> sabdfl: if make check fails but test_on_merge.py works, don't worry, pqm will accept your commit
[03:33] <carlos> I think that it's a problem with other tests that are executed with make check but are not executed with test_on_merge.py
[03:33] <SteveA> the problem is that you can't check things yourself properly before sending to pqm
[03:34] <carlos> SteveA: I do it with test_on_merge.py canonical
[03:34] <SteveA> if the problem doesn't occur for sabdfl for running 'python test_on_merge.py canonical', then that is interesting
[03:36] <SteveA> I'm getting rather cold at home, so I'm going to go and work from a cafe for a while, shortly.
[03:38] <carlos> SteveA: Do you have any priority task for Rosetta before Matar?
[03:38] <carlos> I'm going to work fixing the statistics so they are useful and also improving the import code to handle errors better
[03:38] <carlos> any other task I should look at as a priority?
[03:40] <sabdfl> SteveA: i do get the problem with test_on_merge
[03:41] <carlos> sabdfl: could you send me the output of test_on_merge.py canonical 2>&1 > test-log.txt?
[03:42] <carlos> sabdfl: and disable the test (again)
[03:44] <SteveA> sabdfl: disable the test.  I think I'll have to add some extra checking to the test runner to detect what the problem is.
[03:45] <SteveA> carlos: you have the emails from daf.  He's been going through the workflow of "I'm demonstrating rosetta to an audience of thousands", which happens to be very similar to the workflow that a regular translator would use.
[03:45] <SteveA> go through the same workflow, maybe with different pot / po files.
[03:46] <SteveA> check for links that appear, but don't actually work as advertised
[03:46] <carlos> yeah, my tasks are to improve that process
[03:46] <SteveA> check for confusing text or not enough text or too much text
[03:46] <SteveA> make sure each page says clearly what it expects of the user, or what it is showing the user
[03:47] <carlos> ok
[03:47] <SteveA> sabdfl: can I borrow you for a second, as a "regular launchpad programmer"?  Did you read my email about page titles?
[03:48] <SteveA> I want to know whether you find it better to include the page title as filling in a metal:fill-slot in each page,
[03:48] <sabdfl> erm... i've just spent a bit of time adding them to malone pages... and no, not yet
[03:48] <SteveA> or if you'd rather use zcml in the browser:page directive to give them
[03:48] <sabdfl> in some cases the title is easy, for example the addforms
[03:48] <sabdfl> "Add a New Product"
[03:49] <sabdfl> but even there, it would be nice sometimes to be able to customise the title
[03:49] <SteveA>   <page
[03:49] <SteveA>     for="canonical.launchpad.interfaces.IBug"
[03:49] <SteveA>     name="+frobnicate"
[03:49] <SteveA>     permission="launchpad.Edit"
[03:49] <SteveA>     template="../templates/bug-frobnicate.pt"
[03:49] <SteveA>     title="Frobnicate bug ${context/name}"
[03:49] <SteveA>     />
[03:49] <sabdfl> "Add a Project to the Mozilla Project"
[03:49] <SteveA> my proposal is to allow simple tales string: expressions in a "title" attribute in your zcml
[03:49] <sabdfl> ok, if you can ${context/foo} then that might be fine
[03:49] <SteveA> so, this can be a plain string
[03:50] <sabdfl> what about l10n
[03:50] <SteveA> I'm wondering more about whether zcml is the right place to put these things in
[03:50] <SteveA> we can handle i18n in this case
[03:51] <SteveA> that just becomes a standard thing to be replaced
[03:51] <SteveA> personally, I don't mind using metal:this-and-that in pages
[03:51] <SteveA> but I think it does complicate things a bit
[03:51] <SteveA> using more than one slot all the time
[03:57] <SteveA> hmm... a page's title is somewhat like its name in a URL.  that is, you'd expect them to be related.
[04:08] <sabdfl> def ProductBugAssignmentFactory(context, **kw):
[04:08] <sabdfl>     return ProductBugAssignment(bug=context.context.bug, **kw)
[04:08] <sabdfl> bradb: around?
[04:08] <BradB> yes
[04:09] <sabdfl> if you don't specify a class (viewclass) on an addform, how is the content_factory called?
[04:09] <sabdfl> i'm trying to make sense of the above code and decide if I want to follow that patter or do something different
[04:09] <BradB> sabdfl: By the default AddView class
[04:09] <sabdfl> and the default AddView passes the context like that?
[04:10] <BradB> yes
[04:11] <sabdfl> seems to me that a database-class Factory should not be aware of "context" issues
[04:11] <BradB> There was a time at which I understood the context.context part...it's failing to come to mind at the moment. /me thinks.
[04:11] <sabdfl> malone/bugs/CONTEXT/productassignments/+new
[04:11] <BradB> sabdfl: The context could be something like a container though, I think, so that's why it should know.
[04:11] <sabdfl> context.context.bug...
[04:12] <sabdfl> seems to me i want to be able to use a ProductFactory to create a product with or without a project
[04:12] <sabdfl> if i'm doing it in a project, then use it, if not, don't
[04:12] <BradB> oh! i think context is a view actually.
[04:12] <sabdfl> context.context... would break under different usage patters
[04:13] <sabdfl> it make the db stuff view-sensitive
[04:13] <sabdfl> yuck... a context that is a view? that's nice and readable
[04:13] <sabdfl> sounds like z3 breakage
[04:13] <BradB> that's why it has a context attrib.
[04:14] <sabdfl> i think addview / editview / form could be turned into something simpler and more generic
[04:14] <BradB> sabdfl: yep, i filed a bug on that a long time ago.
[04:15] <BradB> sabdfl: stevea's going to do something about it in mataro i think/hope
[04:15] <BradB> because until it's genericized, it's slowing us down.
[04:16] <BradB> we want a browser:form directive, where you can provide a thing as input and then do something with the submitted values.
[04:17] <BradB> yeah, the factory is bound to the view with self._factory(*args, **kw) in AddView.create, I believe.
[04:23] <sabdfl> hmm... there must be a better way
[04:23] <BradB> sabdfl: Hm, skimming through Z3 sources, they seem to use classes as the content_factory
[04:24] <sabdfl> i think i'm going to write a custom view, then call the factory directly
[04:25] <BradB> sabdfl: you can use keyword_arguments in your addform too
[04:26] <BradB> the be explicit about what gets passed for the kw args to your factory
[04:26] <BradB> I'd prefer an approach that avoids writing code, so that we don't have to maintain it.
[04:27] <BradB> sabdfl: Or you could write your own content_factory if you're creating the content in that much of a different way. Writing a new view is a fair bit of effort (relatively speaking, i.e. thinking of if we consistently added new views in this way, we'd have a ton of extra code to maintain.)
[04:30] <sabdfl> the existing machinery is fine if you are adding  or  editing a class that maps directly and exclusively to a table
[04:30] <sabdfl> and if everything in that page can be made into a nice widget
[04:30] <BradB> sabdfl: BugFactory does something that doesn't map onto a table.
[04:30] <sabdfl> we stretch that with "owner" where we want a field to be derived from the request/principal info
[04:31] <sabdfl> then we stretch it really HARD when we want to add something and also touch a bunch of other tables
[04:32] <sabdfl> BradB: to use BugFactory to "add a bug to an existing product"  I had to create a custom View class
[04:32] <BradB> sabdfl: Hitting the request directly in a content_factory is nasty. Hitting more than one table is fine though, I think. There's no explicit or implied relationship between content_factory and (only one) table.
[04:32] <BradB> sabdfl: at worst, you would have had to create a new content_factory.
[04:32] <sabdfl> that View class knows the principal, and knows the Product, so it can call the content fctory with the correct parameters
[04:33] <sabdfl> i would prefer to have one factory and multiple views, than one view and multiple factories
[04:33] <sabdfl> and if you think about it, that's what you've wanted too
[04:33] <sabdfl> that's why you kept urging me to make my code use the BugFactory, which i did
[04:33] <sabdfl> that way, all the notification logici is in one place
[04:34] <sabdfl> basically, the View is by definition sensitive to the specific setting of that request
[04:34] <BradB> If you want something built in a different way, you send it to a different factory to be built.
[04:34] <sabdfl> no you don't
[04:34] <sabdfl> you call the factory in a different way
[04:34] <sabdfl> which means a custom view class
[04:34] <BradB> sabdfl: You can do that in ZCML though
[04:34] <sabdfl> not very well
[04:34] <BradB> sabdfl: no! you can do that in ZCML.
[04:35] <sabdfl> dude, get context.context.bug OUT of a database factory class, then we can talk
[04:36] <BradB> sabdfl: you're doing the same type of thing though, but instead writing a whole new view to achieve that.
[04:36] <BradB> sabdfl: We need to get at a newly created bug's id somehow.
[04:36] <BradB> And that's not yet available in the request.
[04:37] <sabdfl> "a whole new view"
[04:37] <sabdfl> a view should be as simple as:
[04:37] <BradB> sabdfl: a content_factory is a simple little function
[04:38] <sabdfl> class ProjectAddProductView(AddView):
[04:38] <sabdfl>    def addmethod(self, **kw):
[04:38] <sabdfl>         return factory(**kw)
[04:39] <sabdfl> nothing more
[04:39] <sabdfl> of course, you can add some other processing in the addmethof
[04:39] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: cmd-delta is much smarter/looser now. You can now pass ., revision, version or package (patch-16)
[04:39] <sabdfl> to set things up right for the factory
[04:40] <BradB> sabdfl: okay, maybe i'm being retarded, but BugFactory doesn't do context.context.bug.
[04:41] <sabdfl> (15:08:29) sabdfl: def ProductBugAssignmentFactory(context, **kw):
[04:41] <sabdfl> (15:08:29) sabdfl:     return ProductBugAssignment(bug=context.context.bug, **kw)
[04:43] <BradB> sabdfl: let's face it though, that 3 line class you show above reaks of boiler plate. surely there's a way to do it in zcml.
[04:44] <BradB> sabdfl: i dunno, we shouldn't spend too too much time on this. if you want to do it your way, go ahead. if i figure out a better way (i.e. no code), i'll fix it and tell you what i did.
[04:45] <BradB> s/reaks/reeks/
[04:49] <BradB> Overriding the constructors of the relevant content classes would also be a useful thing, and reduce the number of places to find out how a Foo is constructed to just one: Foo.__init__.
[04:50] <BradB> (override to perhaps take optional args and create other db objects closely related to the thing being created when it makes sense to do so: e.g. default Cc'er on a bug, spname/distro assignment, etc.)
[05:03] <dilys> New Malone bug #114: ""See the bugs assigned to you" doesn't work correctly", submitted by Andrew Bennetts
[05:03] <dilys> https://dogfood.ubuntu.com/malone/bugs/114
[05:08] <dilys> New Malone bug #115: ""my todo list" page generates broken links to bugs", submitted by Andrew Bennetts
[05:08] <dilys> https://dogfood.ubuntu.com/malone/bugs/115
[05:12] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: Copyright fix. (patch-17)
[06:32] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: Really dont get pristines on get if specified (patch-18)
[06:34] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: Handle register-archive with urls with % in them (patch-19)
[06:38] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: fix lock-revision to generate txn ids, and to work when passed a version - bug #3747 (patch-20)
[06:51] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: Fixed a print to stdout instead of stderr in make-archive (patch-21)
[07:10] <sabdfl> BradB|out: yes, the three-liner was boilerplate, if that's all you are doing then you would use zcml
[07:11] <sabdfl> but if you want to fiddle with the form results, THEN call the factory, this is the way to do it
[07:15] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.1: cmd-apply-delta now smart enough to hunt out the tree root (patch-22)
[07:17] <dilys> Merge to rocketfuel@canonical.com/pyarch--production--1.5: fixes for baz format archives (patch-1)
[07:38] <salgado> BradB, we don't have a notify() for a comment added event, right?
[07:47] <BradB> salgado: notify is always there, and yes, there's definitely one for a comment.
[07:48] <BradB> I'm adding a bunch more subscribers today for bug activity tracking.
[07:50] <salgado> BradB, I don't see the registered subscriber ( notify_bug_comment_added) being called when a new comment is added. 
[07:53] <BradB> Ah, I think it's because of Mark's refactoring of bug message.
[07:53] <BradB> it's registered like:
[07:53] <BradB> <subscriber
[07:53] <BradB>    for="canonical.launchpad.interfaces.IBugMessage
[07:53] <BradB>         zope.app.event.interfaces.IObjectCreatedEvent"
[07:53] <BradB>    factory="canonical.launchpad.mailnotification.notify_bug_comment_added" />
[07:53] <BradB> Maybe the thing that gets created is different now (and thus that subscription doesn't get notified.) I'm not sure of the details offhand though.
[07:54] <BradB> I have a feeling that if it were reg'd for IMessage it would work again.
[07:54] <BradB> sabdfl: Sound about right? :)
[07:56] <BradB> eh, it's not obvious though, hm, I'll wait
[08:14] <sabdfl> BradB: yes, i think that would be about right
[08:14] <sabdfl> i'm not sure if the message on its own is enough though
[08:15] <BradB> Nope, that's where the "not obvious though" part comes in.
[08:15] <sabdfl> you probably want to catch the BugMessage, so you can notify people of the creation of a specific message for a specififc bug
[08:15] <BradB> notify() has to be called with the correct object
[08:15] <sabdfl> stevea: am getting an odd permission problem traceback
[08:15] <BradB> It must now be being called with an IMessage
[08:15] <sabdfl> TypeError: ('Not enough context information to get parent', <canonical.launchpad.webapp.authentication.LaunchpadPrincipal object at 0x445bb4cc>)
[08:16] <sabdfl> BradB: but creating the Message doesn't tell you what it's been created *for*
[08:16] <sabdfl> it's the BugMessage that gives it context
[08:16] <sabdfl> for example, without the BugMessage, you would have no idea who to notify ;-)
[08:17] <BradB> sabdfl: that's why I'm saying it has to be called with the IBugMessage. Currently, it must be being called with an IMessage.
[08:17] <BradB> "it" being notify(), of course
[08:19] <salgado> BradB, do you see any problems in passing the request to SQLObjectModifiedEvent?
[08:21] <BradB> salgado: It's cleaner to avoid depending on it in the subscribers. Why do you want the request in a subscriber?
[08:23] <salgado> BradB, I'm subscribing functions to assign karma for people that change bugassignments, and I want to know who changed it
[08:24] <salgado> can I get this information from somewhere else?
[08:26] <BradB> salgado: I think you should be able to create your own event type, IKarmaEvent, that stores the person who's earned the karma. Your subscriber would then subscribe to the object type, SQLObjectModifiedEvent and IKarmaEvent.
[08:27] <sabdfl> cheers
[08:27] <Kinnison> c'y'all tomorrow
[08:28] <Kinnison> sabdfl: I took a chunk of this afternoon to do an emergency IP switch. I'll make it up by doing work while travelling to Mataro if that's okay with you
[08:28] <BradB> salgado: Or IKarmaEarnedEvent, or whatever seems like a good name for it.
[08:31] <BradB> I think I'll create a canonical.launchpad.subscribers hierarchy, because we're starting to accumlate subscribers and it'd be nice to be able to point a newbie to one place to find out everything they need to know about who's listening.
[08:31] <BradB> s/hierarchy/namespace/
[08:32] <carlos> hi
[08:32] <salgado> BradB, looks good, but I don't see how to store the logged in user in IKarmaWhateverEvent
[08:32] <BradB> salgado: In the view, you'd grab it from the request.
[08:32] <BradB> salgado: An event can be any Python object remember.
[08:33] <salgado> BradB, ok, but then I'll have to change all callsites to notify() for my event?
[08:34] <BradB> salgado: Anywhere that generates karma, yep.
[08:34] <BradB> salgado: In doing so, you'll communicate a lot better to the maintainer of the code.
[08:35] <BradB> If an event modifies an sqlobject and generates karma, I want to see notify(sqlobject_modified, karma_earned) in the code.
[08:38] <salgado> BradB, good point. I'll do this
[08:39] <BradB> cool
[08:42] <BradB> I'm merging the namespace now, just so you have it.
[08:43] <sabdfl> Kinnison: not great, wrok-while-travel isn't optimal but if that's the best case situation then thanks for letting me know
[08:47] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: add a canonical.launchpad.subscribers Python package, in which everything that listens for event notifications should be put (patch-929)
[09:32] <salgado> BradB, now that I looked closer to the problem, there's one thing I want to point out.
[09:33] <salgado> when you call notify(SomeEvent), you're not able to tell what will be the consequences of that event (as you don't know that the SQLObjectModifiedEvent will trigger a mail notification)
[09:34] <salgado> to know what is triggered by any event, you must look to that event subscribers.
[09:34] <BradB> salgado: Yeah, that's the point. :)
[09:35] <salgado> and also, don't look sane to me having a KarmaEvent, cause the assignment of a Karma is the consequence of an event.
[09:37] <BradB> salgado: when something modifies an sql object, an ISQLObjectModifiedEvent is generated. When something generates karma, an IKarmaEvent is generated.
[09:37] <BradB> not all sqlobject mods gen karma, not all karma is tied to modifying an sql object
[09:40] <salgado> the same is true for mail notification, and we don't have a IMailNotificationEvent, cause it's a consequence of the real event. you see my point?
[09:41] <kiko_bz> BradB, I'm not really in favor of having salgado mess with callsites to add karma
[09:42] <kiko_bz> we already have the event system set up
[09:42] <kiko_bz> why not take advantage of it?
[09:42] <BradB> salgado: Yeah, you could avoid it I guess.
[09:43] <salgado> cool!
[09:44] <BradB> salgado: but then you return to the not-having-the-principal problem
[09:45] <BradB> Maybe you have to add a bit of fu to an ISQLObjectModifiedEvent.
[09:45] <kiko_bz> leave that to us! :)
[09:45] <kiko_bz> fu is my middle name
[09:45] <kiko_bz> kiko fu bar
[09:45] <BradB> kiko_bz: As long as you don't pass the request to the subscribers!
[09:47] <kiko_bz> we'll see we'll see
[09:49] <salgado> BradB, can you explain why storing the request in the event would be evil? SteveA, do you have an opinion?
[09:50] <SteveA> it depends
[09:52] <sabdfl> SteveA: have you tried this permissions voodoo?
[09:53] <SteveA> on phone, brb
[09:53] <sabdfl> i got a variety of colourful errors and then reverted to launchpad.AnyPerson (a.k.a. wikimode)
[09:56] <BradB> salgado: I can't give you a specific reason off the top of my head, other than that coupling the request with that event type seems evil, when all you really want to store is the principal. (e.g. what if you then come along and write code in event handlers that starts pulling other things out of the request? and then other event handlers want those same values, but are getting called in places where they're gotten from somewhere 
[09:56] <BradB> /other/ than the request?)
[09:57] <BradB> If you store exactly what you need as attributes of the event, that works everywhere, because I can read the Interface of that Event and know exactly what I have access to when it's fired off.
[09:59] <salgado> BradB, what if I store only principal in the SQLObjectModifiedEvent?
[10:00] <BradB> salgado: yeah, that was the "bit of fu" I mentioned earlier. :) that would be a reasonable thing to include with a modified event, I think.
[10:01] <BradB> SteveA: Has there ever been any discussion about how we could use the factory subdirective to help us survive mass-refactorings?
[10:03] <SteveA> right...
[10:03] <SteveA> storing the request in an event is not really all that good, unless the event is a UI event
[10:03] <SteveA> storing the principal, or the "current person" is a better idea
[10:04] <SteveA> as it is being specific, and giving just the information that is pertinent to the event
[10:04] <SteveA> otherwise, it becomes a bit like using a global all the time -- hard to see what's going on; what the interrelationships are
[10:04] <BradB> ...and can't be (accurately) documented in an interface :)
[10:05] <SteveA> pay attention to the semantics of events: there is no problems with making one event fire off another event 
[10:05] <SteveA> it is quite natural to have a FooAddedEvent, and have that (under certain circumstances) cause a KarmaReceivedEvent
[10:05] <SteveA> keep the events semantically distinct
[10:05] <BradB> that was my first suggestion :)
[10:06] <SteveA> BradB: I've never particularly found a use for the factory subdirective.  I've found utilities more useful.  However, if you have some ideas about it, it's something we should talk about in spain.
[10:07] <SteveA> sabdfl: can I see more of the traceback, or get a patch that would reproduce it for me?
[10:07] <SteveA> I'm a bit confused by the part you pasted above, and I think I need a bit more context.
[10:07] <sabdfl> SteveA: try refueling, and checking if you have checkPermission on database.Product
[10:08] <sabdfl> then try set the permission on the product/+edit page to launchpad.Edit
[10:08] <sabdfl> and you'll see it
[10:08] <sabdfl> the problem is that it appears to think the connection is Anonymous
[10:08] <SteveA> okay.  refueling.
[10:08] <BradB> SteveA: In brief: if we provide factories with IDs, we can get at them via the zope api, instead of directly importing the content classes. Then when we shuffle the content classes around, creating objects doesn't break. But yeah, Spain perhaps.
[10:09] <SteveA> BradB: I understand that, but I'm not sure the indirection is worth the effort.  definitely something to chat about in spain, though.
[10:09] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: projectless products and slicker project/product add/edit forms (patch-930)
[10:09] <BradB> ok
[10:14] <SteveA> however... the factories can be made smart about events and permissions
[10:14] <SteveA> so, it might be a good trade-off
[10:14] <SteveA> need to sketch it out better to see, though
[10:15] <SteveA> sabdfl: I did actually use the permissions stuff.  So, I'm surprised that this is giving an error.  Not sure what's different about this case yet.
[10:16] <SteveA>             if self.id == principal.id:
[10:16] <SteveA>                 return True
[10:16] <SteveA>             else: return False
[10:17] <SteveA> evil syntax
[10:17] <SteveA> the return should be indented on the line under the else:
[10:18] <kiko_bz> right
[10:24] <SteveA> sabdfl: I can see what is going on now.  I'm logged in, but I'm not the product's owner, so I don't have rights to edit the product.  So, the system is trying to prompt me for HTTP Basic Authentication, as I might have another login that would work in this case.  (This is the normal web behaviour).  However, prompting for basic auth is failing, because it only works in launchpad when you are anonymous.
[10:24] <sabdfl> ok
[10:25] <SteveA> The reason it only works when you're anonymous is down to a slightly odd bogosity in the part of zope3 that is doing this.  Basically, I'll naed to make LaunchpadPrincipals conform to an undocumented API.
[10:25] <SteveA> I'll do this shortly, and then it will work as it should do.
[10:26] <SteveA> I'll also need to add this to my list of slightly-off things I need to chase up in zope3.
[10:28] <SteveA> we'll need to consider how to present this when we do more advanced permissions stuff.
[10:28] <SteveA> it may be a reasonable assumption that each person has just one login to launchpad
[10:29] <SteveA> so, you're either logged in, or you're not.
[10:29] <SteveA> there is no sense in which you'd want to log in as someone else to do a particular action.
[10:30] <SteveA> so, when you view the product page as anonymous, you should see an "[Log in to]  edit" link.  (the [Log in to]  might be an icon, indicating that this link may be available if you log in)
[10:30] <SteveA> when you view the product page logged in, but as someone who can't edit, there's no point offering them to edit it, or to log in to edit it.
[10:31] <SteveA> when you view the product page, and you are logged in as the right person to edit it, then you obviously want a link to edit it.
[10:32] <sabdfl> would it be possible to do a tal:condition="context/permission/Edit" ?
[10:32] <BradB> How do I commit just one *new* file with baz? baz commit -s "blah" -- thefile gives me: make-changeset-files: file missing from ORIG tree (database/schema/pending/bradb-allow-bugactivity-nulls.sql)
[10:33] <sabdfl> BradB: best ping lifeless on that
[10:33] <BradB> ok
[10:33] <salgado> BradB, I think it's commit -s "foo bar" -- file1 file2
[10:34] <salgado> oops
[10:34] <SteveA> argh, ctags -R . doesn't work in the "launchpad" directory
[10:34] <salgado> didn't read the whole line
[10:34] <SteveA> sabdfl: it will be possible to do basically that, yes
[10:35] <sabdfl> BradB: did you baz add that file first?
[10:36] <BradB> sabdfl: yep:
[10:36] <BradB> bradb@oxygen:~/launchpad $ baz tree-lint
[10:36] <BradB> bradb@oxygen:~/launchpad $
[10:37] <BradB> it shows up A'd in baz changes
[10:37] <BradB> I've committed just one file or two before, but I don't remember if I've ever done that op with brand new files before.
[10:37] <BradB> and i don't think i've tried that op in anyway with baz
[10:38] <salgado> BradB, this don't work for new files, it's in tla docs.
[10:38] <BradB> salgado: I'm not using tla. :)
[10:38] <salgado> but this is something baz inherited from tla 
[10:39] <BradB> salgado: Where is it in the tla docs though? It's certainly well-hidden, wherever it is.
[10:39] <salgado> BradB, http://www.gnu.org/software/gnu-arch/tutorial/selected-files-commits.html#Selected_Files_Commit
[10:39] <SteveA> BradB: if this isn't fixed yet in baz, I'm pretty certain it is on the "to fix" list.  Don't know if there is a bug on it though.
[10:40] <SteveA> fwiw, both the bugs I submitted for baz were fixed today.  definitely more responsive than under the tla regime.
[10:41] <SteveA> you can also type: baz archive-mirror  to mirror the current tree.
[10:42] <SteveA> sabdfl: fixed in my tree.  merge request sent to pqm 
[10:43] <SteveA> you can also say "baz lint" now instead of "baz tree-lint"
[10:44] <BradB> SteveA: Yeah, I saw that. I didn't update though.
[10:45] <BradB> I'm really happy that the do proper unlocks on incorrect GPG p/w's now. :)
[10:45] <BradB> s,the do,they do,
[10:45] <SteveA> yeah, me too
[10:45] <BradB> I've got bash complete going, so there's no diff between baz tree-lint and baz lint :)
[10:46] <salgado> I'm almost sure they removed tree-lint
[10:47] <BradB> Yeah, I think so, but I'm just saying it doesn't really save me any typing.
[10:49] <SteveA> it is a small difference in how much I have to think about it 
[10:49] <SteveA> I want to lint.  So I needed to think "oh, that's tree-lint".  And backwards too, when reading a baz/tla command.
[10:50] <SteveA> oh, maybe I want sock-lint instead today
[10:50] <SteveA> how many kinds of lint were planned for in tla?
[10:50] <SteveA> hey dilys?
[10:51] <SteveA> talk to me dylis
[10:51] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix bug in launchpad auth system where there would be an error if you're asked to re-authorize when you are logged in already.  Also, made product/+edit page require launchpad.Edit permission. (patch-931)
[10:51] <SteveA> thanks babe
[10:51] <BradB> heh
[10:52] <SteveA> ok, must get some food now.  I'll check in a tales permission-checky-helper tomorrow.
[10:53] <SteveA> hmm.. should have included "sabdfl" in the message to pqm, so that mark's "kibo alarm" would sound.
[10:54] <sabdfl> SteveA: thankee muchly
[10:54] <sabdfl> so, now we need a good answer to the "launchpad.Admin" team
[10:54] <sabdfl> better, clearly than my "hardcode a list in python somewhere" plan ;-)
[10:57] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: add a small db patch to allow nulls on oldvalue/newvalue for BugActivity since, logically, the old or newvalue of something that changed might be null (patch-932)
[10:58] <carlos> sabdfl: should I move code as I update it from rosetta/browser.py to launchpad/browser/foo.py?
[10:58] <sabdfl> carlos: yes please!
[10:58] <carlos> you asked me to wait for the zcml cleanup you were doing
[10:58] <carlos> ok
[10:59] <sabdfl> carlos: zcml cleanup should all be committed now
[10:59] <sabdfl> check out rosetta/*.zcml ;-)
[10:59] <carlos> sabdfl: I know ;-)
[11:00] <sabdfl> carlos: i've got a db patch which allows a product to be free, and have no project
[11:00] <sabdfl> i will setup rosetta so that rosetta/products/$Product.name/ goes straight to the product, if i haven't already done so
[11:00] <carlos> hmm, that could break rosetta...
[11:00] <sabdfl> yes, it will
[11:01] <sabdfl> i will do a little testing but there isn't much sample data to work with in rosetta
[11:01] <sabdfl> if i have a potemplate and a pofile handy, can i test out the new upload / import process?
[11:01] <carlos> sabdfl: but we said that we could have two products with the same name, how will you handle it?
[11:01] <carlos> sabdfl: sure
[11:01] <carlos> sabdfl: daf did it already
[11:01] <sabdfl> pending/mark-project-refactor.sql ;-)
[11:02] <sabdfl> is it obvious how to do that?
[11:02] <carlos> and i'm improving the process now
[11:02] <carlos> sabdfl: more or less
[11:02] <carlos> you create a new project
[11:02] <carlos> then a new product
[11:02] <kiko_bz> sabdfl, debonzi's almost got soyuz under control tonight but collapsed under load, will finish up tomorrow -- nice patch
[11:02] <carlos> then you have a chance to create a template
[11:02] <carlos> and also a link to upload files
[11:02] <kiko_bz> sabdfl, and I just saw salgado's karma displayed on the person view, woot
[11:02] <carlos> sabdfl: I could forward you all steps daf did 
[11:03] <carlos> sabdfl: you have them in your inbox now
[11:07] <sabdfl> nice!
[11:07] <sabdfl> congrats salgado
[11:14] <carlos> Did you saw the "funny" UI bug we have in our forms? every time you click over a button, the page content expands itself using the spare space
[11:23] <carlos> SteveA: ping?
[11:38] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Subscribers for Bug events to do karma-gathering. (patch-933)
[11:48] <carlos> anyone knows how works the file upload feature in Zope3/launchpad?
[11:54] <BradB> carlos: Are there places near BCN that I can pick up Cisco wireless cards?
[11:54] <carlos> BradB: I suppose it
[11:54] <carlos> BradB: http://informatica.elcorteingles.es or http://www.fnac.es
[11:55] <carlos> if you see it there, you will be able to buy it at Barcelona
[11:55] <carlos> hmm
[11:55] <sabdfl> lifeless: are you adding the products at the moment? someone is adding them without descriptions, please put good descriptions in, copy from their home pages if needed
[11:55] <sabdfl> also, need home pages :-)
[11:55] <carlos> I'm not sure if they have an english version... let me check it for you :-)
[11:55] <sabdfl> carlos: yes, that bug is driving me nuts
[11:56] <carlos> sabdfl: I saw a way to expand it as much as I want without submit the form :-P
[11:56] <carlos> a kind of eastern egg :-)
[11:58] <kiko_bz> carlos, visit www.lecto.com.br and type foobar into the text entry
[11:58] <kiko_bz> *that's* an easter egg :)
[11:59] <sabdfl> lifeless: i'm not going to approve items like gstream and gst-plugins that have such terse summary and description. make them count!
[11:59] <carlos> kiko_bz: X-)
[12:00] <carlos> BradB: don't see it there but I have seen cisco wireless card in Spain, so it should not be a problem