=== BradB [~bradb@george.kkhotels.co.uk]  has joined #launchpad
=== lalo [~lalo@201.3.135.118]  has joined #launchpad
=== limi [~limi@159.80-202-72.nextgentel.com]  has joined #launchpad
[12:43] <limi> so, where are all the resources hidden at the moment? want to move the declarations out of lp/resources.zcml, where should I put them?
[12:44] <limi> daf: you aren't really idling ;)
[12:44] <daf> no, I'm not
[12:44] <daf> but I'm not working :)
[12:45] <limi> figured it out ;)
[12:45] <limi> I'll just keep them in lp for now
[12:48] <limi> wow, it actually worked :] 
=== limi upgrades his Z3 zen
[12:49] <daf> :)
[12:52] <lalo> z3 is full of fnords
[12:53] <daf> yeah?
[12:53] <lalo> heh. that would be a nice slogan - "the OS with no fnords". Too bad the joke would be a bit obscure.
=== cprov_ [~cprov@george.kkhotels.co.uk]  has joined #launchpad
[01:03] <limi> stub: there?
=== BradB is now known as BradB|away
=== justdave [~dave@24.247.63.44.gha.mi.chartermi.net]  has joined #launchpad
=== npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net]  has joined #launchpad
=== stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au]  has joined #launchpad
[08:01] <stub> justdave: ping
[09:58] <SteveA> morning
[09:59] <SteveA> brb -- rebooting
=== debonzi [~debonzi@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
=== BradB [~bradb@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
=== elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
=== cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
=== Kinnison [~dsilvers@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
[10:05] <Kinnison> Morning
=== SteveA [~steve@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
=== sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
[10:14] <stub> Yo
=== lulu [~lu@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
[10:27] <sabdfl> hey stub
[10:27] <sabdfl> i have code for remote bug systems
[10:27] <sabdfl> committing shortly
[10:28] <stub> cool.
[10:28] <stub> justdave: ping
[10:30] <daf> stub: there seems to be some agreement and no objections on the removal of schema owners -- shall we go ahead with it?
[10:31] <sabdfl> daf: please don't
[10:32] <stub> sabdfl: Can I make owner nullable then?
[10:32] <sabdfl> schemas are not actually meant to be used the way rosetta is currently using them
[10:32] <sabdfl> stub: not for the moment
[10:32] <stub> oic
[10:33] <sabdfl> the longer term plan for schemas is to have someone able to say "i want to create a new schema"
[10:33] <sabdfl> then they can add labels to that schema etc
[10:33] <sabdfl> and they would of course own that schema
[10:37] <stub> So does rosetta need a table(s) to replace Schema that it can use instead?
[10:38] <daf> sabdfl: ok
[10:38] <daf> sabdfl: we discussed this on the mailing list, and there were no objections, so I thought there was agreement
[10:39] <daf> so the thing to do is to create a new table for the thing we're using schemas for
[10:42] <SteveA> daf: if the schema isn't going to be edited in the application while it is running, then we shouldn't be using a schema.
[10:43] <SteveA> lifeless: thanks for merging the zope.
=== carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net]  has joined #launchpad
[11:15] <carlos> morning
[11:17] <cprov> carlos: morning
=== stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au]  has joined #launchpad
=== stu1 [~stub@dsl-246.248.240.220.dsl.comindico.com.au]  has joined #launchpad
=== stu1 is now known as stub
[11:56] <stub> Is there an easy way to see pqm status atm?
[11:57] <elmo_> you mean "is it inf looping" oir something more useful?
[11:57] <stub> I want to see if my pqm request got to the queue before my machine locked up.
[11:57] <stub> Doh... i should check my mail log :-)
[11:57] <elmo_> the queue dir (if not the files) is world readable in /home/pqm/arch/queue/
[11:58] <elmo_> combined with 'ps auxfw' it's fairly easy to see what it's doing
[12:03] <sabdfl> lifeless: ping, again
[12:51] <sabdfl> stub: just sent pqm mail for merging bugsystem adding / editing
[12:51] <stub> Ta
[12:52] <sabdfl> stub: am trying to figure out what if anything will break if we update the production environment to current rocketfuel
[12:52] <stub> justdave: ping
[12:52] <sabdfl> i need the bugsystem add/edit stuff in place so justdave can capture his top100 bugzillas
[12:53] <sabdfl> also, need the new project/product setup in place, which is working in rocketfuel
[12:53] <stub> Which we need lifeless for I guess, since it is his baby that is currently running live
[12:53] <sabdfl> yes, need to figure out what will break if we update
[12:53] <stub> Time for a staging server?
[12:54] <sabdfl> could be :-)
[12:54] <stub> I can easily create a duplicate of the database on emperor - just need to decide on where to run a staging instance of rocketfuel for testing
[12:55] <stub> SO WHO LEFT A PRINT STATEMENT SOMEWHERE I CAN'T FIND MAKING THE TEST OUTPUT UNREADABLE!
[12:55] <sabdfl> the harder bit is figurering out which parts to test
=== stub hopes it wasn't him
[12:56] <SteveA> I'd really like us to have a staging server
[12:56] <SteveA> like, soon
=== limi [~limi@212.80-202-72.nextgentel.com]  has joined #launchpad
[12:58] <SteveA> hi alex
[12:58] <stub> For launchpad at least, it doesn't need a dedicated box although the box it runs on *will* need access to emperor
[12:58] <SteveA> really?
[12:58] <SteveA> I thought the staging server would work on a recent copy of emperor's database
[12:59] <stub> Emperors database might get rather large, so I suspect it would be impractical (in the long term - now it is fine)
[12:59] <SteveA> hmm
[01:00] <stub> Although strictly speaking that is a nono, in case the staging server does nasty things to the database that cause the production systems to become unresponsive
[01:00] <SteveA> right
[01:00] <SteveA> how large is too large?
[01:01] <stub> That question can only be answered in hindsight :-)
[01:01] <spiv> stub: Let's get some hindsight then ;)
[01:01] <SteveA> in a sense, that would be nice problem to have
[01:01] <SteveA> it means we've got enough data to kick ass
[01:01] <stub> I guess we should just run with a local instance and cross the other bridge when we come to it
[01:01] <stub> I had some hindsight, but I've forgotten where I put it.
[01:02] <limi> hi Steve
[01:03] <limi> and stub :)
[01:03] <stub> limi: Morning
[01:03] <limi> and spiv :)
[01:03] <daf> SteveA: ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/apidoc', u'rootModule')
[01:03] <daf> SteveA: (when trying to run Launchpad with an updated Zope)
[01:03] <SteveA> daf: update RF
[01:06] <stub> SteveA: Hmm... Z3 doesn't like sqlobject storing a connection cache - the test suite complains about garbage for every single test :-(
[01:06] <SteveA> can we junk the cache?
[01:06] <daf> SteveA: ok, it starts now
[01:06] <SteveA> does it really gain us anything?
[01:09] <SteveA> also, perhaps the connection cache should be registered with the placelesssetup's teardown
[01:09] <SteveA> that way, we can trash the cache on each test
[01:10] <stub> SteveA: We already junk the cache - just at transaction start rather than end :-)
[01:10] <SteveA> hmm
[01:16] <carlos> SteveA: I think the zope migration broke something here: http://localhost:8085/++skin++Debug/rosetta/prefs
[01:17] <carlos> it was working yesterday
[01:18] <carlos> The problem is when it lists all languages we have in the database:
[01:18] <carlos> def languages(self):
[01:18] <carlos>         return getUtility(ILanguages)
[01:19] <carlos>     *  Module zope.app.traversing.adapters, line 52, in traverse
[01:19] <carlos>       raise NotFoundError(subject, name)
[01:19] <carlos>       __traceback_info__: (<Language at 0x31ee88d0>, 'name', [] )
[01:19] <carlos> NotFoundError: (<Language at 0x31ee88d0>, 'name')
[01:19] <SteveA> carlos: I'll take a look shortly'
[01:20] <carlos> ok, thanks
[01:24] <stub> SteveA: placelesssetup won't help - it is all tests (not just the ones using placeless setup). Which means it isn't sqlos but sqlobject...
[01:26] <limi> sabdfl: ok, changes checked in, want to update and have a look?
[01:26] <sabdfl> limi: will do
[01:29] <daf> carlos: are there any other pages which exhibit the same problem?
[01:29] <carlos> daf: not sure
[01:30] <daf> ok, you don't know of any
[01:30] <sabdfl> limi: did you get the pqm success message?
[01:30] <limi> not yet, it seems
[01:31] <sabdfl> limi: ping me when you do, i can't fetch your patches till that's done
[01:31] <carlos> daf: seems like the problem is only with the getUtility(Languages)
[01:31] <sabdfl> stub: just updated the malone dia to include assignee on both sourcepackagebugassignment and productbugassignment
[01:31] <limi> sabdfl: yup, thought it was pretty much instant these days
[01:32] <carlos> daf: we have also a problem with the http://localhost:8085/rosetta/projects/gnome/evolution/ template, it does not lists anymore the list of resources to translate, so the navigation is broken
[01:32] <daf> carlos: right, we know about the navigation problem
[01:32] <sabdfl> stub: we need to change SourcepackageBugAssignment.binarypackage to SourcepackageBugAssignment.binarypackagename and of course point it at the correct table
[01:32] <daf> carlos: Steve has a pending fix for that which should be merged soon
[01:32] <stub> sabdfl: Ta. Should I be keeping them up to date? (I thought we were not going to worry)
[01:32] <carlos> ok
[01:32] <daf> carlos: why do you think that getUtility(ILanguages) is involved?
[01:32] <sabdfl> stub: it's nice to see the system as a whole, visually, but it's low priority, renice the task :-)
[01:33] <carlos> daf: because it's what the template is using
[01:34] <stub> sabdfl: I don't understand why we would want to link the assignment to the binarypackagename rather than the binarypackage
[01:34] <carlos> we have:
[01:34] <carlos> <div metal:fill-slot="main"
[01:34] <carlos>      tal:define="languages view/languages">
[01:34] <carlos> and then:
[01:34] <carlos> <option tal:repeat="language languages"
[01:34] <carlos>                             tal:content="language/name"
[01:34] <carlos>                             tal:attributes="name language/code" />
[01:34] <carlos> and view/languages is a call to getUtility
[01:34] <carlos> the other option is that tal is broken
[01:35] <daf> Steve and I are debugging it, and it seems to us that there's a problem with authentication
[01:37] <sabdfl> stub: binarypackage *used to* be a virtual thing
[01:37] <sabdfl> now it's basically a single deb
[01:37] <sabdfl> on a single architecture
[01:37] <sabdfl> built for a specific processor
[01:37] <sabdfl> for a single versioned releasre
[01:38] <sabdfl> so...
[01:38] <sabdfl> what you want to be saying is "this bug is in that sourcepackage, but it shows up in the binary package called foo"
[01:38] <daf> sabdfl: in that case, it's a confusing table name :)
[01:39] <sabdfl> in the previous iteration of the dbschema for this stuff i had a "binarypackge" which was name/title/description, and "binarypackagebuild" which was the deb
[01:39] <sabdfl> daf: whats a better one?
[01:39] <daf> sabdfl: not sure
[01:39] <sabdfl> ping when you are :-)
[01:39] <daf> when you say "binary package", I think of it in the abstract
[01:39] <stub> sabdfl: So why do you want to link a sourcepackagebugassignment to a set of binarypackages that happen to have the same name?
[01:39] <daf> not a specific file
[01:39] <limi> sabdfl: arch is happy
[01:40] <daf> sabdfl: I think "BinaryPackageBuild" was a better name
[01:41] <limi> +1
[01:41] <sabdfl> daf: unfortunately, that is confusing too
[01:41] <sabdfl> because we actually record builds as well
[01:41] <limi> :] 
[01:41] <sabdfl> so we can tell you information about how long, when etc the package was built
[01:42] <sabdfl> limi: i see some patches from you, will have a look now
[01:43] <limi> btw, is Lurker running on top of Mailman, or are they independent?
[01:44] <stub> sabdfl: I thought the user would report the specific binarypackage (version, platform etc.), which we could then use to create a confirmed buginfestation (the binarypackage that was reported), and whole heap of possible bug infestations (earlier builds, later builds)
[01:44] <sabdfl> limi: mailman handles all the mailing list traffic
[01:44] <sabdfl> it then passes a copy of each message to lurker
[01:45] <limi> aha, so it's independent
[01:45] <sabdfl> yes
[01:45] <limi> ok
[01:45] <limi> just curious :)
[01:45] <sabdfl> so we need skins for the mailman registration, deregistration pages
[01:45] <sabdfl> for the rest we will just use lurker i think
=== limi was talking to Barry Warsaw about using ZPT for Mailman 3 earlier
[01:45] <sabdfl> stub: yes, that data goes into buginfestation
[01:45] <sabdfl> not bugassignment
[01:46] <sabdfl> assignment is all about "who's going to fix it"
[01:46] <sabdfl> infestation is all about "what was affected"
[01:47] <sabdfl> limi: ok, nice work, thank you
[01:48] <stub> sabdfl: So why is the sourcepackagebugassignmented linked to a binarypackagename at all then? Are we unable to infer the binarypackage infestation stuff from the sourcepackage?
[01:48] <sabdfl> it has nothing to do with infestation, and more to do with organising who fixes it
[01:48] <sabdfl> for example, the XFree86 source package produces a zillion binary packages
[01:48] <sabdfl> and different people care about different parts of it more
[01:48] <sabdfl> same with gnome, etc
[01:49] <sabdfl> so they have a bunch of ways to organise the bugs assigned to "xfree86-server"
[01:49] <sabdfl> priority and severity are obvious
[01:49] <sabdfl> binarypackage is also useful in the packaging context
[01:50] <sabdfl> because maintainer teams tend to organise themselves that way
[01:50] <stub> sabdfl: Ok. That all makes sense to me now :-)
[01:50] <sabdfl> we also give them the "assignee" field so they can actually say "bob will fix this"
[01:50] <sabdfl> later on, i want to add the ability for them to create their own schema and organise that way
[01:51] <sabdfl> for example, they might have some bugs which are "doc", some "branding", some "code", some "build"
[01:51] <sabdfl> they could create that schema, and organise the bugs assigned to their product or source package accordingly
[01:51] <sabdfl> spiv: i think your scrapeddata table idea might actually have been a winner
[01:52] <spiv> sabdfl: Heh.  Why's that? :)
[01:52] <stub> Grrr....
[01:52] <sabdfl> because sf blocked this IP as soon as we started testing the script
[01:53] <spiv> Ah.
[01:54] <spiv> How many IPs do we have? ;)
[01:54] <elmo_> 128 ;-)
[01:54] <Kinnison> mmmm loadbalanced DoS
[01:54] <stub> I assume that we can't just ask sf for a dump of the information we want?
=== ddaa [~david@nemesis.xlii.org]  has joined #launchpad
[01:55] <sabdfl> stub: good assumption
[01:55] <stub> Just roll out the scraper with the ubuntu gold - 60,000 distributed scrapers :-)
[01:56] <sabdfl> make that 175,000
[01:58] <limi> sabdfl: ok, want to go through the Malone changes quickly, or should we talk after lunch?
[01:59] <sabdfl> limi: can give some feedback right away
[01:59] <limi> ok
=== limi brings out the note pad
[01:59] <sabdfl> let's pass on nested followups till we have strong demand for it
[02:00] <sabdfl> that means we can flatten things out and just have a single follow-up section
[02:00] <sabdfl> let's order comments "newest first"
[02:00] <sabdfl> and put the followup form above the comments, but default closed
[02:01] <sabdfl> limi?
[02:01] <limi> ok
[02:01] <sabdfl> the "people" portlet
[02:01] <sabdfl> ised to link to a page which let you edit the subscription, please restore the link
[02:01] <sabdfl> used to, sorry
[02:01] <limi> ok
[02:02] <limi> I have no people data that I can see
[02:02] <limi> that's probably why it's missing ;)
[02:02] <sabdfl> the sample data does include some, are you working with that?
[02:03] <sabdfl> limi: ^?
[02:03] <sabdfl> the previous version did include the link
[02:03] <limi> yes, I believe I am
[02:03] <limi> what issue has people?
[02:03] <limi> I have one issue about Firefox SVG
[02:03] <limi> and one about deletion
[02:04] <limi> none of those seem to have people associated
[02:04] <sabdfl> ok, I will add some people, dump the db and commit it. 'sec
[02:04] <limi> great
[02:04] <limi> I assume I can add my own too
[02:06] <stub> I was wondering it the People portlet should be renamed 'Subscribers' or 'Nosy' 
[02:06] <stub> limi: Yup
[02:06] <limi> ok, anything else I should know? there are some remaining things like colorization of status etc that are not done yet, and I plan on fixing after lunch
[02:07] <BradB> stub: oh yeah, it looks like we'll need ignore for, as mark noted, cases where the sourcepackage maintainer changes
[02:07] <sabdfl> limi: yes, you can
[02:07] <limi> ok, then it should be easy to fix :)
[02:07] <sabdfl> limi: external references
[02:08] <sabdfl> for CVS types we want the following:
[02:08] <limi> yes, wondered a bit about that - can I create categories?
[02:08] <sabdfl> CVE:data
[02:08] <sabdfl> which is a link to the correct url (i think it's right, thanks)
[02:08] <stub> BradB: Is this so if the sourcepackage maintainer changes they don't have to go and subscribe to all the open bugs?
[02:08] <sabdfl> and the mouseover should give you the description
[02:08] <sabdfl> for URL's:
[02:08] <limi> but it should have something like "CVE:<number>" as title?
[02:08] <BradB> stub: yeah, so that we don't have to un and resubscribe a person to bugs in this scenario
[02:09] <sabdfl> limi not title, the visible text in the portlet should just be "CVE:data" where data is from the data field
[02:09] <limi> ok
[02:09] <sabdfl> that text should be a link to the CVE page, as it is crrently
[02:09] <sabdfl> and when you mouse over the link, the tooltip should be the full description
[02:10] <limi> yup
[02:10] <BradB> stub: and the point is, well, if you're a sourcepackage maintainer then tough, you're responsible for getting annoyed^Winformed about bugs reported and can't turn that off for now :)
[02:10] <sabdfl> for URL type, we want a different handling
[02:10] <sabdfl> the text in the portlet should be the URL for the moment (we will get a title to replace this with)
[02:10] <sabdfl> that url text should be a link to the... url :-)
[02:11] <limi> (surprise!)
[02:11] <limi> :)
[02:11] <limi> ok, that's what confused me - because I had no proper title to show there
[02:12] <sabdfl> and again the mouseover tooltip should be the description
[02:12] <sabdfl> we'll get one
[02:12] <limi> yes
[02:12] <limi> great
[02:12] <limi> as long as everything has title and description, I'm a happy UI designer :] 
[02:13] <limi> makes everything much easier to represent sanely
[02:13] <sabdfl> well, we want to change it to title and shortdesc, but i'll leave the interface in place so you don't need to change it
[02:13] <limi> also added some explanatory text to the headings of portlets, see if you like that approach
[02:14] <limi> Bug Watches is an example
[02:14] <sabdfl> where do i see the text?
[02:14] <limi> hover
[02:14] <limi> not all portlets have it yet
[02:15] <limi> just testing it on Bug Watches
[02:15] <sabdfl> ok, i don't see it on BugWatches
[02:15] <sabdfl> can we make the people list more compact?
[02:15] <limi> when hovering the header?
[02:15] <sabdfl> nope
[02:15] <limi> sabdfl: yes, as I have no people, I haven't had a chance to look at that properly yet :)
[02:16] <sabdfl> ok, is that enough feedback till this afternoon?
[02:16] <limi> strange, should be there - it's a normal title attribute - which browser are you on?
[02:16] <sabdfl> firefox 1.0
[02:16] <limi> yes, I believe so - I have some web site stuff to fix for Lu too
[02:16] <sabdfl> ok, thanks
[02:16] <limi> ok, Firefox 1.0 here too
[02:16] <sabdfl> lu gets two hours a day from you per my deal with her :-)
[02:16] <limi> yes ;)
=== limi feels like his soul is being bargained with ;)
[02:17] <limi> "you can have two hours of limi time if I get..." ;9
[02:17] <limi> ;)
[02:18] <limi> ok, thanks for the feedback - we still have to come up with something good for the Product/SourcePackage assignments, not entirely happy with those
[02:18] <limi> see you in a bit
[02:22] <SteveA> carlos: I have found a bug
[02:22] <SteveA> rosetta-preferences.pt:                            tal:content="language/name"
[02:22] <carlos> SteveA: where?
[02:22] <SteveA> a Language object does not have a name attribute
[02:24] <SteveA> that is the bug
[02:24] <carlos> :-?
[02:24] <carlos> let me check
[02:24] <SteveA> if I change that to language/englishName, the prefs page works
[02:24] <SteveA> so, it is not a change in zope
[02:24] <carlos> hmm
[02:24] <carlos> true
[02:25] <carlos> sorry, I did assume that the template was right
=== ddaa [~david@nemesis.xlii.org]  has joined #launchpad
[02:28] <stub> BradB: canonical/lp/z3batching - is that our code or Zope corps?
[02:29] <BradB> zope corp
[02:30] <BradB> written by stephan, i think
[02:30] <BradB> batching.py is what I did to extend it for our uses.
[02:32] <stub> ok. it should probably live in lib/z3batching rather than lib/canonical/lp/z3batching then (although not urgent). 
[02:33] <carlos> archzoom is sloooooooe
[02:33] <carlos> archzoom is slooooooow
[02:37] <carlos> SteveA: are you fixing the template or should I do it?
[02:39] <SteveA> please do it
[02:40] <carlos> ok
[02:40] <daf> BradB: is this something which should be pushed upstream?
[02:40] <SteveA> um
[02:40] <SteveA> I don't think we want it in lib/z3batching particularly
[02:40] <SteveA> I mean, it does no harm there I suppose
[02:40] <daf> if it's Canonical-specific, shouldn't it be in lib/canonical?
[02:41] <stub> Woohoo... found the test suite litterer 
[02:41] <SteveA> cool
[02:46] <carlos> limi: where are now the account settings ?
[02:47] <carlos> to change name, surname and password?
=== ddaa [~david@nemesis.xlii.org]  has joined #launchpad
[02:56] <dilys> New bug 2077 for Launchpad/Librarian: Librarian test suites disabled
[02:56] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2077
=== kiko [~kiko@200-206-134-238.async.com.br]  has joined #launchpad
[03:04] <SteveA> hey kiko
[03:04] <SteveA> good flight back?
[03:05] <sabdfl> stub: ping (brad here on mark's machine)
[03:06] <stub> sabdfl: pong
[03:07] <sabdfl> so, we're having a problem with vocabularies. when a vocabulary is named (i.e. specified as a string), the value gets saved to the database, however it does not get displayed in the widget properly on rerendering. i'm told you're the guy who might have the quickest answer as to why that might be.
[03:08] <stub> So the select box has integers or something stoopid instead of nice text?
[03:09] <stub> (There were some changes recently made in Z3 making the vocabularies better, which will be the cause of this)
[03:11] <cprov> sabdfl: w3.sf.net has just unblocked our IP, do you have time to see some previous results of *nicole* ?
[03:11] <elmo_> cprov: sabdfl's wandered off - he's on the phone to lifeless
[03:11] <cprov> elmo_: aha :)
=== daf wonders who Nicole is
=== lalo [~lalo@201.3.135.209]  has joined #launchpad
[03:14] <carlos> daf: something like dilys? a.k.a. a bot :-P
[03:14] <kiko> hey st
[03:14] <kiko> hey SteveA
[03:14] <kiko> yeah, was okay (slept all 11h of it, unsurprisingly)
[03:14] <cprov> daf: ask elmo_, but in our context is a script to grab info about sourcepackages names on SF and FM and insert it in DOAP system
[03:15] <sabdfl> stub: no, as in, it's loaded properly, but it's not selecting the correct option (i.e. the one we just chose and saved)
[03:17] <kiko> fala cprov, debonzi
[03:17] <stub> Oh - the default value is not correctly selected when the form is loaded? I've got a bugzilla bug open on that one. I had a quick look when I was doing that but couldn't see the problem. Don't know if it is a Z3 bug or mine.
[03:17] <kiko> hey sabdfl, BradB, elmo_
[03:17] <sabdfl> yo kiko
[03:17] <kiko> how's the good life
[03:17] <daf> cprov: ah
[03:17] <elmo_> sabdfl: impostor
[03:17] <sabdfl> heh
[03:18] <cprov> kiko: !
[03:18] <kiko> fala big cprov
[03:18] <sabdfl> stub: not the default value; the one we just saved
[03:18] <elmo_> kiko: cprov and debonzi have like totally slacked off since you left dude.. it's terrible.. they're like out the door at 5 and stuff.. in the pub the rest of the vening
[03:18] <cprov> elmo_: lol
[03:18] <kiko> elmo_, thanks for the feedback. I'm going to turn off their oxygen allowance for wednesday
[03:19] <debonzi> kiko, opa
[03:19] <stub> sabdfl: Yes - I think we are talking about the same thing. It didn't seem a show stopper so I dumped it from short term memory straight into bugzilla, and thus can't quite remember the details :-)
[03:19] <sabdfl> it seems like a showstopper to me
[03:20] <sabdfl> to the user, it makes it look like the value they just selected didn't get saved
[03:21] <stub> sabdfl: At the time, the users were just going to be us. Now Mark wants it more public so the priority has changed on it I guess ;)
[03:21] <stub> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1904
=== limi [~limi@193.71.38.142]  has joined #launchpad
[03:23] <stub> daf: is it trivial to make dilys pull the subject from an arch commit email and echo it here?
[03:24] <daf> stub: should be
=== limi is still annoyed by the fact that PQM doesn't include the check-in message when you get a success notice
[03:24] <daf> stub: spiv has been threatening to do this for a while
[03:24] <daf> stub: the code is in daf@muse.19inch.net--2004/dilys--devel--0
[03:24] <limi> hard to know which commit failed
[03:24] <daf> limi: file a bug :)
[03:24] <limi> ;)
[03:24] <daf> seriously
[03:24] <limi> is there a dedicated tracker for that?
[03:24] <daf> there's a place for filing them
[03:25] <carlos> daf: could you help me to understand some code you wrote?
[03:25] <daf> judging by https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1899, it's the LP bug tracker
[03:25] <limi> in relation to canonical, or gnu arch?
[03:25] <daf> carlos: sure
[03:25] <carlos> well, it's only to check if I'm understanding it correctly
[03:25] <limi> aha
[03:26] <carlos> browser.py line #880 the for sentence
[03:26] <daf> limi: PQM is lifeless' fault
[03:26] <carlos> well, the whole for block
[03:26] <limi> ok ;)
[03:26] <daf> carlos: it says "continue"
[03:26] <daf> :)
[03:27] <carlos> :-?
[03:27] <carlos> do we have the same file ?
[03:27] <carlos> :-D
[03:27] <carlos> rosetta/browser.py
[03:27] <daf> oops, sorry
[03:27] <daf> vim was confusing me
[03:27] <daf> for index in new_translations:
[03:27] <daf> ?
[03:27] <carlos> yes, that one
[03:28] <daf> new_translations is a dictionary
[03:28] <daf> mapping plural forms to translations
[03:28] <stub> daf: you got a sftp: line for that archive or something?
[03:28] <daf> stub: http://muse.19inch.net/~daf/arch/
[03:28] <carlos> ok, but you are not setting the old translation as noncurrent or something like that
[03:29] <daf> that should happen in makeTranslationSighting, shouldn't it?
[03:30] <carlos> daf: true
[03:31] <daf> if the code is not clear, perhaps it should be changed
[03:32] <carlos> daf: no, don't worry, I think this time I'm the problem here :-P
[03:34] <carlos> lunch time
[03:34] <carlos> see you later
[03:35] <daf> later
[03:35] <sabdfl> stub: i (brad) am going to write a unit test for TitledTableVocabulary to hopefully expose the problem behind this bug, and accidentally write down how to use vocabularies
[03:36] <stub> ok. That code is a bit of a mess due to some column changes so feel free to refactor it :-)
[03:36] <sabdfl> ok :)
[03:38] <SteveA> well -- let's get a unit test for it first
[03:38] <sabdfl> stub: so first off (writing the doctest) what is a TitledTableVocabulary?
[03:39] <SteveA> brad -- change your nick!
=== sabdfl is now known as bradb_
[03:39] <stub> ;-P
[03:39] <bradb_> i enjoyed being a cosmonaut for a while there
[03:39] <SteveA> there we were thinking mark could type on irc while on an intense phone call waving his arms around
[03:40] <elmo_> I told y'all he was an impostor
[03:40] <stub> A TitledTableVocabulary is an IIterableVocabulary that pulls its items from a database table with a 'title' column.
[03:40] <stub> Which is a stupid name now that the tables don't have title columns...
[03:40] <SteveA> stub: did you see the zope3 vocab refactorings?
[03:40] <SteveA> they aren't so severe really
[03:40] <SteveA> mainly, getQuery is gone (hurrah)
[03:40] <stub> SteveA: Haven't looked yet - doesn't seem to have affected us
[03:41] <SteveA> and the vocabulary interfaces have a better hierarchy
=== SteveA tries to spell heirarchy
[03:41] <stub> SteveA: I never bothered to wrap my brain around the query stuff
[03:42] <daf> stub: hierarchy
[03:42] <daf> s/stub/SteveA/
[03:43] <SteveA> daf: yes, I know
[03:43] <SteveA> but I tend to type it before I remember how to spell it
[03:43] <bradb_> stub: IOW a TTV is a listing of the values in the column "title" of a table, keyed by, well, the PK (probably called id, or some such), right?
[03:44] <stub> bradb_: Pretty much. Z3 terminology might be a bit different (tokens and whatnot)
=== ddaa [~david@nemesis.xlii.org]  has joined #launchpad
=== limi [~limi@193.71.38.142]  has joined #launchpad
[04:09] <Kinnison> spiv: ping?
[04:11] <kiko> bradb_, did you check out my changes cprov landed to paging?
=== carlos is back
[04:38] <limi> stub: can we fix it so that the list of comments show latest first, and so that I have a comment # to print in the header?
[04:38] <stub> limi: Sure
[04:39] <limi> I want to be able to say "This is comment #3" etc
[04:39] <limi> that way I can generate anchors too
[04:39] <limi> which is useful :)
[04:43] <stub> If I could find anything... 
[04:44] <daf> stub: you too, eh?
[04:45] <stub> Everything seems scattered :-( zcml in canonical/malone which references templates somewhere else... urgh...
[04:47] <SteveA> templates are all in one place
[04:47] <SteveA> for all else, use ctags :-)
[04:47] <kiko> stub, I hand-hacked some ../s into your code, I apologize up-front
[04:47] <limi> yes, the moving of all templates to one dir could have been handled better ;)
=== limi has added ../ too
[04:48] <carlos> daf: I will leave in about 15 minutes for about two hours, do you need anything from me? (I think I will be able to close #2065 before leaving)
[04:48] <kiko> I would rather templates be gradually migrated back to app-specific locations 
[04:48] <kiko> after the mass duping is fixed
[04:48] <daf> carlos: don't think so
[04:48] <carlos> ok
[04:49] <limi> stub: what is the correct expression to edit a subscription? I seem to have deleted it by accident when I did the portlet rewrite
[04:49] <stub> erm - the url to the edit page you mean?
[04:50] <stub> kiko: I don't see what the templates had to do with duping at all 
[04:50] <limi> stub: yes
[04:51] <limi> it is probably a TAL expression to get the correct subscription etc
[04:51] <limi> I don't know how to retrieve an older version of the template with arch
[04:52] <daf> limi: you can do tla get launchpad--devel--0--patch-NNN if you know the NNN
[04:52] <limi> I don't ;)
[04:52] <daf> limi: of course, the problem is knowing NNN :)
[04:52] <limi> exactly
[04:52] <daf> I think there's a tool which could help
[04:52] <limi> we don't have anything like ViewCVS or svn history?
[04:52] <daf> la-file-log
[04:53] <daf> tla-file-log
[04:53] <daf> limi: ArchZoom is a bit like ViewCVS
[04:53] <limi> URL for archzoom?
[04:53] <daf> I don't know how to use ArchZoom to view the history a file
[04:53] <limi> oh, ok
[04:53] <daf> https://chinstrap.warthogs.hbd.com/archzoom/
[04:54] <daf> https://chinstrap.warthogs.hbd.com/archzoom/alexander.limi@canonical.com--2004/launchpad--devel--0 is probably where you want to start looking
[04:56] <stub> limi: $bug.id/watches/+new
[04:56] <kiko> stub, well, basically, templates that implemented the same thing were duped, but they were hardly the main issue.
[04:56] <kiko> we can move them back..
[04:57] <stub> limi: Sorry - that is for a new one. $bug.id/watches/$watch.id/+edit
[04:57] <limi> thanks
[04:58] <stub> limi: ignore that. it isn't watches.
[04:58] <limi> ;)
[04:58] <stub> people
[04:59] <stub> $bug.id/people/+new and $bug.id/people/$subscriber.id/+edit
[04:59] <limi> renamed the People portlet to Subscribers, btw
[05:01] <stub> SteveA: So you would advocate just sticking *everything* in a single directory? Thats about as central as we can get! :-)
[05:02] <stub> Hmm... arch handles symlinks... this might be fixable...
[05:04] <limi> stub:                tal:attributes="href string:$bug.id/people/$subscriber.id/+edit" doesn't work, I assume there are some qualifiers missing?
[05:04] <stub> Oh... that wasn't tal I read out...
[05:05] <limi> well, TAL is the only thing that works here ;)
[05:05] <daf> limi: ${bug.id}/people/${subscriber.id}/+edit ?
=== limi tests
[05:06] <stub> probably not - simplest to pull it out of arch zoom, or wait until I can find the relevant class that will tell me the answer
[05:08] <limi> archzoom makes no sense to me
[05:08] <elmo_> ZOOM ZOOM ZOOM
[05:08] <elmo_> (mazda stole my brain)
[05:09] <daf> bradb_: can I ask you a quick question about BatchNavigator?
[05:09] <bradb_> sure
[05:09] <daf> I have to do this:
[05:10] <daf> BatchNavigator(Batch(foo, 0, 20), self.request)
[05:10] <limi> stub: would be nice if you could find it, so I can check this in and move on to work on the website stuff - this is the last piece I'm missing :)
[05:10] <daf> it would be really nice to have a convenience method which makes the Batch for me
[05:10] <daf> since I have to look at paramters to work out the start and end
[05:11] <daf> i.e. magicBatchNavigatorMaker(foo, self.request)
[05:15] <stub> limi: I can't do the message sorting until the codereorg is done. Put it in bugzilla if you don't want it lost. You should be able to get the message id right now though by just doing tal:content="message/id" inside the tal:repeat="message context/messages"
[05:17] <BradB> daf: Okay...I used to have them be the same object, but I intentionally split them apart.
[05:18] <BradB> daf: Because it doesn't make sense for a BatchNavigator to behave like a Batch.
[05:18] <stub> limi: oh - might be able to do the sort
[05:18] <daf> BradB: fair enough -- I just want the BatchNavigator stuff to do the grubbing aroudn in the parameters for me :)
[05:19] <limi> stub: the watch edit link is the most important right now :)
[05:19] <daf> BradB: you wouldn't necessarily modify BatchNavigator, just add a canonical.lp.batching.convenienceFunction
[05:25] <daf> BradB: something like this:
[05:25] <daf> def navigatorMaker(list, request):
[05:25] <daf>     if 'batch_start' in request.form:
[05:25] <daf>         start = request.form['batch_start'] 
[05:25] <daf>     else:
[05:25] <daf>         start = 0
[05:25] <daf>     if 'batch_end' in request.form:
[05:25] <daf>         end = request.form['batch_end'] 
[05:26] <daf>     else:
[05:26] <daf>         end = start + 20
[05:26] <daf>     return BatchNavigator(Batch(list, start, end), request)
[05:27] <limi> so there is really no way to say "give me the previous 5 versions of this template" in arch?
[05:31] <daf> limi: shrug
[05:31] <daf> that would be really useful
[05:33] <limi> you think? ;)
[05:33] <limi> as a feature that every other versioning system has... yes.
[05:34] <limi> stub: can't get message/id to work
[05:34] <limi> Module zope.app.traversing.adapters, line 52, in traverse
[05:34] <limi> raise NotFoundError(subject, name)
[05:34] <limi> __traceback_info__: (<BugMessage at 0x387f590>, 'id\n name message', ['id'] )
[05:34] <limi> NotFoundError: (<BugMessage at 0x387f590>, 'id\n name messag
[05:34] <stub> limi: https://chinstrap.warthogs.hbd.com/archzoom/rocketfuel@canonical.com/launchpad--devel--0--patch-400/lib/canonical/malone/templates/bug-people-portlet.pt
[05:34] <limi> thanks
[05:35] <limi> how did you find it?
=== limi is utterly confused by the archzoom UI
[05:35] <stub> first select the 'rocketfuel' archive at the top level
[05:36] <stub> Then the project (launchpad)
[05:36] <stub> (or actually the '0' under launchpad)
[05:36] <stub> Find a 'patch' that corresponds to the date you want to go back to. 
[05:37] <stub> (so no you can't see 'the previous version' as far as I know, which sucks)
[05:38] <stub> click on, say 'patch-400'
[05:39] <stub> browse the tree till you find the file you want
[05:41] <stub> limi: message/id works for me - I suspect a tal error? I just replaced 'message/title' with 'message/id' in my copy and it worked.
[05:42] <limi> hm
=== limi double checks 
[05:44] <limi> yup, missing semi-colon
=== limi is used to python ;)
[05:47] <stub> justdave: ping
[05:51] <limi> stub: can you enlighten me on the bug reference stuff? Mark said he wanted CVE:data in there, how do I get hold of that?
[05:51] <spiv> Kinnison: pong
[05:54] <stub> So if it is a CVE reference you want to do tal:content="string:CVE:{ref/data}" ?
[05:54] <dilys> Bug 2001 resolved: soyuz/distros/ubuntu has inconsistent use of +s
[05:54] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2001
[05:57] <dilys> Bug 1988 resolved: Personal information missing
[05:57] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1988
[06:00] <Kinnison> spiv: The librarian....
[06:01] <Kinnison> spiv: It gives me a file id and an alias id when I upload a file
[06:01] <Kinnison> spiv: what are they; what's the difference; do I need both to retrieve a file; what about the filename I give it; etc.
[06:06] <spiv> Ah, right.
[06:06] <spiv> The file id is a unique identifier for a particular blob of data.
[06:07] <spiv> The alias id is a name and mime type for a file id, because the same blob could potentially have many names.
[06:09] <spiv> (Or rather, the alias id is a unique identifier for the name & mime type...)
[06:11] <spiv> Btw, have you seen bugs #1921 and #1922?
[06:11] <Kinnison> so the fileid is the ref to the data, the aliasid is the ref to the (name,mimetype) tuple?
[06:12] <spiv> Right.
[06:12] <spiv> And at the moment, we require both to access the data.
[06:13] <Kinnison> right
=== Kinnison may come back to you about things later; but for now I'm elsewhere doing utility stuff for lucille
[06:13] <spiv> Ok :)
[06:14] <Kinnison> thanks for the explanantion though; it'd be cool if some use-cases were documented in there
[06:14] <spiv> Yeah, it would...
[06:15] <spiv> Librarian currently suffers from being code that isn't actually used yet ;)
[06:16] <dilys> New bug 2078 for Launchpad/DOAP: Product doesn't match IProduct
[06:16] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2078
=== Kinnison imagines it'll start getting used a lot soon; what with malone and lucille surging forward
[06:16] <spiv> daf: Ta :)
[06:16] <daf> spiv: welcome :)
[06:17] <daf> spiv: any better way of getting the total number of projects than Project.select().count()?
[06:18] <spiv> daf: Nope.
[06:18] <daf> ok
[06:18] <spiv> Well... you could add a count = property(lambda self: self.select().count()) to the class definition ;)
[06:19] <spiv> I'm not sure that that would be "better", though.
[06:25] <stub> limi: What times do you need me tomorrow?
=== stub just read the email sent 2.5 hours ago
[06:32] <daf> spiv: well, in this case, it's for a __len__ definition
[06:32] <spiv> daf: I'd leave it as Project.select().count(), I think :)
[06:36] <stub> daf: So I should create that table as specified in your last email?
[06:38] <stub> daf: Or should I do it tomorrow morning after there has been more discussion?
[06:42] <dilys> New bug 2079 for Launchpad/Launchpad: x[y:z]  implicitly calls __getslice__ rather than __getitem__
[06:42] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2079
[06:42] <daf> stub: it can wait until tomorrow
[06:53] <limi> stub: my core time is 09:00-17:00 UTC
[06:53] <limi> so anytime during that
[06:56] <stub> ok. I seem to be 03:00UTC onwards at the moment
=== stub goes to bed
[06:58] <limi> good night
[06:58] <limi> see you tomorrow
=== npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net]  has joined #launchpad
[07:08] <daf> spiv: I'm getting an error on POST to /doap/projects/+new
=== spiv looks
[07:09] <daf> https://rosetta.warthogs.hbd.com/doap/projects/+new
[07:09] <daf> actually
[07:09] <daf> https://rosetta.warthogs.hbd.com/++skin++Debug/doap/projects/+new
[07:09] <kiko> spiv, how's the beach?
[07:09] <spiv> kiko: very nice :)
[07:10] <spiv> I suddenly realised how pale my skin had become from three weeks in the UK ;)
[07:11] <spiv> I didn't realise this apartment would be so ridiculously close to the beach (about 5-10 mins walk)
[07:12] <daf>     *  Module canonical.doap.browser, line 69, in newproject
[07:12] <daf>       homepageurl = self.form['homepageurl'] 
=== spiv is very happy in Mallorca atm.
[07:15] <daf> is the beach in range of the wireless? :)
[07:15] <daf> spiv: I think Mark wants this code working ASAP so he can demo it to someone
[07:23] <spiv> daf: Found it -- the template was calling that input 'url', rather than 'homepageurl'.
[07:23] <spiv> Fix in the works.
[07:23] <daf> ah, I've also foudn it
[07:24] <daf> found it
[07:24] <daf> :)
[07:25] <spiv> :)
[07:26] <daf> I've applied a temporary fix
[07:26] <spiv> Cool.
[07:27] <justdave> stub: pong
[07:29] <cprov>  spiv: have you seen bug #2007 ? can you give me some instructions ...
[07:30] <stub> justdave: Are you happy with the check-watches.py code? I haven't tested it myself so I am unsure if it needs loving or not. Mark is keen to get this live with everything else.
[07:31] <justdave> I would bet it's probably broken right now, I haven't touched it in a few weeks and I think I remember seeing some of the stuff it was depending on getting moved around (where the libraries are in the archive, etc)
[07:32] <justdave> Mark mentioned it to me last night, I was going to try to make sure it works again this afternoon
[07:32] <stub> I don't think the migration stuff is comlete yet :-/
[07:33] <stub> It would be good if you can test it. I don't think the database definitions it would be using have changed, but I suspect you are correct about the libraries.
[07:36] <spiv> cprov: I'll comment in the bug.
[07:36] <cprov> spiv: tks
=== stub goes to bed, for real this time
[07:37] <daf> spiv: DatabaseException: ERROR: new row for relation "project" violates check constraint "$2"
[07:42] <justdave> yeah, all that's in there that I'm positive was working at one point is the code to actually pull the data out of Bugzilla.  Seems like the code to loop through the watch list and actually update the bug watches was only partially complete.
[07:43] <justdave> that should be easy enough to polish off this afternoon though
[07:43] <spiv> daf: Check constraints:
[07:43] <spiv>     "$2" CHECK (name = lower(name))
[07:45] <daf> spiv: weird
[07:45] <daf> spiv: that check should be passing
[07:47] <spiv> (use \d tablename in psql to see that)
=== kiko is now known as kiko-fud
[07:47] <daf> ah, cunning
[07:48] <daf> hmm, something seems to be uppercasing the name somewhere
[07:49] <daf>                 <input type="text" name="name" size="30"
[07:49] <daf>                        value="" style="text-transform: lowercase" />
[07:49] <daf> :-/
[07:50] <Kinnison> that's only render-style though yes?
[07:50] <spiv> There's no guarantee that the browser will support that style attribute -- we need to handle this case more gracefully.
[07:50] <daf> the problem was this:
[07:51] <daf> I'd typed O
[07:51] <daf> but it was displaying it as o
[07:51] <daf> the code should convert it to lowercase, I think
[07:51] <daf> it was still being submitted as O
[07:51] <spiv> I see.  That's almost certainly valid behaviour for a browser to have :)
[07:51] <daf> https://rosetta.warthogs.hbd.com/++skin++Debug/doap/projects/ovofrob
[07:51] <daf> yes, I agree
=== lulu [~lu@host217-37-231-28.in-addr.btopenworld.com]  has left #launchpad [] 
[07:53] <spiv> daf: Similarly, we don't handle duplicate names gracefully either.
[07:53] <daf> right, error reporting is a more general problem
[07:54] <daf> it would be nice if it said "This project has no products." rather than "This project has the following products:" when there are no products
[07:55] <spiv> Also yes :)
[07:56] <daf> bugs! bugs! :)
[08:16] <BradB> stub: Why is the constraint for productbugassignment.product: "$2" FOREIGN KEY (product) REFERENCES sourcepackage(id)?
[08:16] <BradB> It should be s/sourcepackage/product/ no?
=== carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net]  has joined #launchpad
=== daf leaves
=== kiko-fud is now known as kiko
=== BradB [~bradb@george.kkhotels.co.uk]  has joined #launchpad
=== elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com]  has joined #launchpad
=== ddaa [~ddaa@nemesis.xlii.org]  has joined #launchpad
[10:53] <kiko> spiv, --> bbaetz (~bbaetz@c211-30-0-2.wavrl1.nsw.optusnet.com.au) has joined #mozwebtools
[10:53] <kiko> :)
[10:53] <spiv> kiko: :)
=== ddaa [~david@nemesis.xlii.org]  has joined #launchpad
=== dda1 [~ddaa@nemesis.xlii.org]  has joined #launchpad
=== ddaa [~ddaa@nemesis.xlii.org]  has joined #launchpad
=== ddaa [~ddaa@nemesis.xlii.org]  has joined #launchpad
=== debonzi [~debonzi@george.kkhotels.co.uk]  has joined #launchpad
=== kiko is now known as kiko-afk
=== bradb_ is now known as sabdfl