[12:04] <BradB> SteveA: Sources seem pretty cool, but indeed it turns out that some things break with an upgrade (7 tests fail.) Do we battle through an upgrade, or reimplement sources in our Z3?
[12:05] <sabdfl> let's stay closer to upstream if possible
[12:06] <BradB> I'd like to too.
[12:14] <BradB> sabdfl: Should I proceed ahead with this locally upgraded Z3, and hold off committing until my changes are ready and jblack/lifeless get the newest Z3 imported?
[12:14] <BradB> proceed ahead as in spend time fixing what's broken in Malone
[12:15] <sabdfl> BradB: your call
[12:17] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: introduce buttress (patch-833)
[12:26] <BradB> SteveA: ping
[12:32] <carlos> BradB: he went to sleep about one hour ago
[12:48] <BradB> now up to 41 failures and 2 errors. ugh.
[12:49] <BradB> does anything special have to be done to upgrade the zope version? i just made sourcecode/zope a symlink to ~/Zope3
[12:49] <BradB> seems like many of these errors are just not finding names.
[02:03] <Kinnison> nighty
[02:29] <BradB> stub: yo
[02:30] <BradB> stub: i'm trying to upgrade Z3 locally. to do that i simply moved sourcecode/zope aside and made a symlink to my ~/Zope3 checkout.
[02:30] <BradB> but now when i visit a URL, e.g. http://localhost:8086/, I get a Error type: zope.publisher.interfaces.NotFound
[02:31] <BradB> NotFound: Object: <canonical.publication.RootObject object at 0x30d0c090>, name: u'index.html'
[02:31] <BradB> any obvious alarms going off as to why that may be?
[02:32] <BradB> (zope starts up without incident, and if i put an error in the directive that defines that page, zope craps out, so i know it's still loading that confi)
[02:32] <BradB> config, even
[02:32] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Rosetta project view improvements (patch-834)
[02:34] <stub> Morning
[02:35] <BradB> hi
[02:36] <BradB> I'm thinking it's *possible* that the publishing internals have changed, and a Z3 upgrade b0rks our publisher.
[02:36] <BradB> (I'm wanting to upgrade so that I can use ISource et al.)
[02:37] <stub> I think for you to get that error message, lib/canonical/configure.zcml is not being loaded
[02:38] <BradB> dude, it is
[02:38] <stub> Try introducing an obvious XML error?
[02:38] <stub> oh
[02:38] <BradB> i mentioned that already
[02:39] <stub> And root index contains no TAL, so it isn't something else raising a NotFound
[02:40] <stub> I'm not sure if we still have local patches against our Z3 tree. You would need to ask SteveA or lifeless
[02:43] <stub> You could be right about our publisher - if I remember it tries to lookup a few things regarding our custom suburl directives and whatnot before falling back to a normal view, and the KeyError or AttributeError could be caused in there. Need pdb to trace it.
[02:45] <stub> I think we should ask lifeless to get the Z3 SVN repository mirrored at arch.ubuntu.com - we could then trivially upgrade since we could specify any revision we like.
[02:47] <BradB> As sabdfl mentioned earlier, I think it's definitely a good idea for us to try to keep as close to upstream as possible, perhaps particularly in this still relatively early stage. The last thing we want is to end up wedged in on a non-release version of Zope 3. So yeah, the easier it is to upgrade, the better.
[05:20] !alindeman:*! One of our main rotation servers just split from the network there.  We're working to mitigate further effects.  Thanks for using freenode and sorry for any inconvenience.
[08:29] <SteveA> BradB: So, you can't upgrade Zope3 at the moment, because some stuff breaks when you do.
[08:32] <SteveA> stub: definitely a good idea to get the Zope 3 SVN repo mirrored.
[08:32] <SteveA> stub, BradB: we have no local patches against the Zope 3 SVN tree.
[08:34] <SteveA> it sounds to me like a problem with layers and skins.  I can take a look at this a bit later on today.
[08:34] <SteveA> BradB: probably not worth you spending much time on it.  I can imagine it would be easy to lose hours looking at it.
[09:33] <sabdfl> morning all
[09:33] <sabdfl> stub: i took some liberties in grabbing 4-14, is that ok?
[09:56] <stub> Bad Mark, but I'll retroactively approve it since we had already discussed this change ;)
[10:30] <Kinnison> Marning
[10:38] <lulu> kinnison:morning :o)
[10:40] <Kinnison> lulu: I'm happier this morning
[10:40] <lulu> kinnison: glad to hear it mate :o)
[10:41] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: show buttress in launchpad (patch-835)
[10:52] <lifeless> can someone give bob2 a hand debugging why launchpad doesn't let him add projects ?
[11:02] <stub> bob2: I can have a look, but I'm not familiar with that code. Whats up?
[11:08] <bob2> stub: I don't seem to have some of the needed tables, like project and person.
[11:08] <bob2> (after a "make" in the db schema dir)
[11:09] <Kinnison> bob2: You're missing the ability to create plpythonu or plpgsql in your db
[11:09] <Kinnison> bob2: either make yourself a postgres superuser or add them to template1
[11:09] <bob2> gah
[11:09] <bob2> which is easier?
[11:09] <Kinnison> your own box?
[11:09] <bob2> yup
[11:09] <Kinnison> the former
[11:10] <Kinnison> sudo -u postgres psql template1
[11:10] <Kinnison> alter user bob2 with createdb createuser;
[11:10] <bob2> ok
[11:15] <bob2> hrm, did that, then re-made the db, and I seem to be getting a similar error
[11:16] <Kinnison> oh?
[11:19] <bob2> hwo can I make sure I'm a superuser?
[11:20] <stub> psql -d template1
[11:20] <stub> select * from pg_user;
[11:20] <bob2>  usename  | usesysid | usecreatedb | usesuper | usecatupd |  passwd  | valuntil | useconfig 
[11:20] <bob2>  rob      |      100 | t           | t        | t         | ******** |          |
[11:21] <stub> So that isn't the problem
[11:22] <stub> psql -d launchpad_dev
[11:22] <stub>  >   \d person
[11:22] <bob2> template1=# \d person
[11:22] <bob2> Did not find any relation named "person".
[11:23] <stub> \i trusted.sql
[11:23] <stub> (after running psql -d launchad_dev in the database/schema directory)
[11:24] <stub> Any errors? (ignore the SET: lines)
[11:26] <bob2> erk, it says the db doesn't exist
[11:27] <bob2> shouldn't the schema Makefile make it?
[11:27] <stub> Erm... launchpad_dev, not launchad_dev.
[11:27] <bob2> hah, right
[11:27] <bob2> no errors
[11:28] <stub> So it isn't a plpythonu problem
[11:28] <stub> select valid_name('hello');
[11:28] <stub> (still in psql)
[11:29] <bob2>  valid_name 
[11:29] <bob2> ------------
[11:29] <bob2>  t
[11:30] <stub> You will need to email me the output of 'make' in database/schema
[11:30] <bob2> sure
[11:31] <bob2> stuart@?
[11:31] <stub> stuart.bishop@canonical.com
[11:32] <stub> Or one of those paste site thingies
[11:35] <bob2> http://chinstrap../~rweir/make.txt
[11:37] <Kinnison> stub: next pqm merge from me contains another db patch
[11:43] <stub> bob2: According to that output, everything worked just fine. No errors in the create tables, the sample data loaded just fine, and the comments were added.
[11:46] <bob2> m
[11:47] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Multiarch gina (stage1) and a db patch for binarypackage constraints (patch-836)
[11:49] <Kinnison> stub: if you fancy an easy task; the patch in that merge is a two line constraint change ;-)
[11:50] <stub> yup. In a tick
[11:50] <Kinnison> bob2: is sabdfl around?
[11:51] <bob2> Kinnison: he's out atm
[11:51] <stub> bob2: psql -d launchpad_dev
[11:51] <Kinnison> bob2: okay; ta
[11:51] <bob2> stub: can you reproduce it on rocketfuel@canonical.com/launchpad--devel--0--patch-834
[11:51] <bob2> ?
[11:51] <stub> bob2: Then 'select current_database();'
[11:51] <bob2>  current_database 
[11:51] <bob2> ------------------
[11:51] <bob2>  launchpad_dev
[11:52] <stub> \d person
[11:52] <bob2> lots of stuff
[11:52] <stub> Ok - it is there now. 
[11:53] <stub> Perhaps the first time you ran make, another process was still connected to launchpad_dev so the final stage of the makefile failed.
[11:54] <bob2> hrm
[11:55] <bob2> the doap and malone stuff still throws exceptions
[11:55] <bob2> "make" in the schema dir then "make build run" in the root should be enough, right?
[11:59] <stub> Yup
[11:59] <stub> What exceptions are you seeing?
[11:59] <stub> bob2: Table not found ones?
[12:00] <bob2>   File "/home/rob/projects/warthogs/launchpad/launchpad/lib/canonical/publication.py", line 88, in publishTraverse
[12:00] <bob2>     raise NotFound(self.context, name)
[12:00] <bob2> exception.txt on chinstrap
[12:02] <stub> bob2: Ignore that one - it is just saying some browser requested favicon.ico and it isn't there.
[12:02] <stub> (Just a 404 error)
[12:02] <bob2> er, wrong one, sorry
[12:03] <bob2>     *  Module zope.publisher.publish, line 132, in publish
[12:03] <bob2>       publication.beforeTraversal(request)
[12:03] <bob2>     * Module canonical.publication, line 238, in beforeTraversal
[12:03] <bob2>       p = prin_reg.authenticate(request)
[12:03] <bob2>     * Module canonical.launchpad.webapp.authentication, line 91, in authenticate
[12:03] <bob2>       return self._authenticateUsingBasicAuth(credentials)
[12:03] <bob2>     * Module canonical.launchpad.webapp.authentication, line 65, in _authenticateUsingBasicAuth
[12:03] <bob2>       principal = login_src.getPrincipalByLogin(login)
[12:03] <bob2>     * Module canonical.launchpad.webapp.authentication, line 184, in getPrincipalByLogin
[12:03] <bob2>       person = getUtility(IPersonSet).getByEmail(login)
[12:03] <bob2>     * Module canonical.launchpad.database.person, line 132, in getByEmail
[12:03] <bob2>       return results[0] .person
[12:03] <bob2>     * Module sqlobject.main, line 1194, in __getitem__
[12:03] <bob2>       return list(self.clone(start=start, end=start+1))[0] 
[12:03] <bob2>     * Module sqlobject.main, line 1198, in __iter__
[12:03] <bob2>       return conn.iterSelect(self)
[12:03] <bob2>     * Module sqlobject.dbconnection, line 507, in iterSelect
[12:03] <bob2>       select, keepConnection=True))
[12:03] <bob2> (when hitting http://localhost:8086/doap/projects/+new)
[12:08] <stub> You are missing the actual exception (that is just the traceback). That page works for me with that revision from rocketfuel.
[12:08] <bob2> TypeError: iteration over non-sequence
[12:08] <bob2> erk, sorry
[12:08] <stub> At a guess, there is no entry in the database for the email address you are attempting to log in as (you need to exist in the sampledata), and that case isn't being handled correctly.
[12:09] <bob2> hmm
[12:09] <bob2> I wasn't logged in
[12:09] <stub> psql -d launchpad_dev,   'select * from emailaddress where email ='stuart.bishop@canonical.com' except with your email address
[12:09] <bob2> foo.bar@canonical.com/test, right?
[12:11] <stub> Think so. The email address is right anyway
[12:12] <stub> baz switch rocks ;)
[12:12] <stub> baz switch rocketfuel@canonical.com/launchpad--devel--0--patch-834 just worked ;)
[12:14] <bob2> hah, nice
[12:14] <bob2> ok, I get an error while logging in, too
[12:14] <bob2>     *  Module canonical.launchpad.database.person, line 132, in getByEmail
[12:14] <bob2>       return results[0] .person
[12:14] <bob2>     * Module sqlobject.main, line 1194, in __getitem__
[12:14] <bob2>       return list(self.clone(start=start, end=start+1))[0] 
[12:14] <bob2>     * Module sqlobject.main, line 1198, in __iter__
[12:14] <bob2>       return conn.iterSelect(self)
[12:14] <bob2>     * Module sqlobject.dbconnection, line 507, in iterSelect
[12:14] <bob2>       select, keepConnection=True))
[12:14] <bob2> TypeError: iteration over non-sequence
[12:15] <stub> That vaguely reminds me of an exception I would expect to see if you had an outdated release of sqlobject
[12:16] <bob2> oh god
[12:16] <stub> rocketfuel@canonical.com/sqlobject--test--0.6
[12:17] <bob2> yeah
[12:17] <bob2> the config is still broken
[12:18] <lifeless> stub: so did you roll out the db upgrade ?
[12:19] <stub> Nope
[12:19] <lifeless> could you please ?
[12:19] <stub> Sure
[12:21] <bob2>     *  Module sqlobject.dbconnection, line 194, in _executeRetry
[12:21] <bob2>       return cursor.execute(query)
[12:21] <bob2>     * Module zope.app.rdb, line 258, in execute
[12:21] <bob2>       return self.cursor.execute(operation)
[12:21] <bob2> ProgrammingError: ERROR: relation reference "potemplate" cannot be used as a select-list entry HINT: Write "potemplate".* to denote all the columns of the relation. SELECT POTemplate.id, POTemplate.changeset, POTemplate.owner, POTemplate.description, POTemplate.copyright, POTemplate.title, POTemplate.priority, POTemplate.branch, POTemplate.product, POTemplate.messagecount, POTemplate.path, POTemplate.name, POTemplate.license, POTemplate.datecreated, POTemplate.iscur
[12:34] <stub> Do we have someone who can restart the authserver if it doesn't survive the db bouncing?
[12:38] <lifeless> stub: dunno.
[12:38] <SteveA> Good question.  I think only andrew has restarted it before.  When it didn't survive a restart last time, andrew added code to make it survive the next time.
[12:38] <SteveA> I think elmo would be able to find out.
[12:39] <dilys> Merge to rocketfuel@canonical.com/buildbot--devel--0: set the product link in imported branches (patch-74)
[12:40] <stub> We need to start setting up procedures for the production systems. And I thought I'd gotten out of all that sysadmin shit ;)
[12:40] <SteveA> out of the old shit, and into some that is shiny and new
[12:43] <carlos> stub: when do you sync dogfood server with latest launchpad code?
[12:43] <carlos> (morning)
[12:43] <stub> It depends. Last one was yesterday morning (about 34 hours ago).
[12:45] <carlos> we need to do small fixes to rosetta and a sync will be needed so the betatesting server is fixed 
[12:45] <stub> lifeless: I assume you want that patch in now? I might just apply yours since I don't want to risk taking down the authserver.
[12:45] <stub> carlos: I'll be doing an update shortly (after I've sorted lifeless and Kinnison)
[12:46] <carlos> stub: ok, could you ping me before that, I'm going to finish the needed bits before your sync
[12:46] <lifeless> stub: I'll be doing a full code drop
[12:46] <lifeless> so ...
[12:47] <lifeless> I'd much rather the lot.
[12:47] <lifeless> can elmo bounce the authserver ?
[12:47] <stub> elmo: ping
[12:53] <dilys> New Malone bug #64: "Nagios authserver plugin", submitted by Stuart Bishop
[12:53] <dilys> https://launchpad.ubuntu.com/malone/bugs/64
[12:58] <stub> BradB: Did you change the Product vocabulary back to use the id as the token rather than '$project.name $product.name' ?
[01:01] <bob2> stub: hrm, seems to have just been the wrong sqlobject; after a rebuild it works great now
[01:01] <bob2> stub: thanks for your help
[01:02] <lifeless> what does 'fogo na bomba' mean ?
[01:03] <kiko> lol
[01:03] <kiko> fire in the hole more or less
[01:04] <carlos> SteveA: how could I know from rosetta if they are visiting the site from launchpad.ubuntu.com or rosetta.shuttleworthfoundation.org/ ?
[01:04] <lifeless> so its not like, forget the bombs?'
[01:04] <carlos> SteveA: the PATH_INFO is the same
[01:05] <carlos> HTTP_HOST?
[01:07] <lifeless> stub: is that done ?
[01:08] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: update the arch model to allow setting the project link in Branch from imports (patch-837)
[01:17] <stub> lifeless: No - waiting on elmo or someone who knows about the authserver to arrive
[01:17] <SteveA> carlos: look in the request.URL
[01:18] <carlos> SteveA: request.URL? don't see it
[01:18] <carlos> CHANNEL_CREATION_TIME: 1101211740.29 GATEWAY_INTERFACE: CGI/1.1 HTTP_ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_ACCEPT_ENCODING: gzip,deflate HTTP_ACCEPT_LANGUAGE: es,en-gb;q=0.7,en;q=0.3 HTTP_HOST: localhost:9020 HTTP_MAX_FORWARDS: 10 HTTP_REFERER: https://launchpad.ubuntu.com/ HTTP_USER_AGENT: Mozilla/5.0 (X11
[01:18] <carlos> ; U; Linux ppc; en-US; rv:1.7.5) Gecko/20041116 Epiphany/1.5.1 (Ubuntu) (Ubuntu package 1.0-2ubuntu3) HTTP_VIA: 1.1 launchpad.ubuntu.com HTTP_X_FORWARDED_FOR: 80.33.181.69 HTTP_X_FORWARDED_HOST: launchpad.ubuntu.com HTTP_X_FORWARDED_SERVER: launchpad.ubuntu.com PATH_INFO: /++vh++https:launchpad.ubuntu.com:443/++/rosetta REMOTE_ADDR: 127.0.0.1 REQUEST_METHOD: GET SCRIPT_NAME: SERVER_NAME: rosetta SERVER_PORT: 9020 SERVER_PROTOCOL: H
[01:18] <carlos> TTP/1.1 SERVER_SOFTWARE: zope.server.http (DebugLayerHTTP)
[01:19] <carlos> SteveA: I was thinking on use request.HTTP_X_FORWARDED_SERVER
[01:21] <SteveA> use request.getURL() 
[01:21] <carlos> let me try..
[01:22] <SteveA> I guess you can use PATH_INFO too
[01:22] (elmo/#launchpad) stub: hmm?
[01:23] <carlos> SteveA: yes, I just noticied the difference between launchpad and rosetta servers
[01:24] (elmo/#launchpad) does the authserver still need restarted?
[01:25] <stub> elmo: No - just wanted to make sure someone who could restart it was around before I bounced postgres to do a db upgrade
[01:25] (elmo/#launchpad) oh, ok
[01:26] <stub> I'll take postgres@emperor down now
[01:28] (elmo/#launchpad) shout when I should apply the big hammer
[01:35] <stub> lifeless: Done
[01:36] <stub> elmo: In theory, it is now working. It is a just in case thing because it is an important service and we havn't pulled the rug out from under its feet enough times to trust it yet ;)
[01:51] <stub> elmo: I don't see any connections...
[01:52] (elmo/#launchpad) ... restart it?
[01:53] (elmo/#launchpad) yeah, it's screwed
[01:53] (elmo/#launchpad) restarted
[02:01] <dilys> New Malone bug #65: "Production authserver not surviving database outages", submitted by Stuart Bishop
[02:01] <dilys> https://launchpad.ubuntu.com/malone/bugs/65
[02:03] <carlos> stub: I just requested a merge of the needed fixes from Rosetta
[02:10] <carlos> lunch time
[02:10] <carlos> later!
[02:24] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Ugly hack to fix the rosetta betatesting template (patch-838)
[02:31] <lifeless> stub thanks
[02:33] <stub> carlos: eh?
[02:38] <carlos> stub: from rosetta we need to apply some changes to dogfood code base to fix the links at https://rosetta.shuttleworthfoundation.org/
[02:39] <carlos> the changes are now at rocketfuel and it's interesting to have them merged into dogfood server as soon as possible so our betatesting server is useful for our users
[02:49] <stub> Ahh... this is the stuff you want rolled out to dogfood ;)
[02:55] <sabdfl> me refuels... love my daily code fix
[02:55] <sabdfl> erm, /me
[02:56] <carlos> stub: yes ;-)
[03:03] <kiko> sabdfl, SteveA, salgado was asking me about our plan for moving person-related code into FOAF
[03:03] <kiko> do you have some minutes to discuss this with me?
[03:03] <sabdfl> sounds good
[03:03] <kiko> with us, more properly
[03:03] <sabdfl> fire away
[03:03] <kiko> currently the login service is inside webapp
[03:03] <kiko> and create new person is (AFAICT) limited to soyuz
[03:03] <kiko> we display person-related information in all applications
[03:04] <kiko> and check permissions in all applications
[03:04] <kiko> we also have application-implemented preferences interfaces 
[03:04] <kiko> what would we like to see centralized in FOAF? note that this could mean FOAF as infrastructure, not just UI, if we like.
[03:08] <kiko> sabdfl, do you have an idea of at least a set of pages we'd like in FOAF?
[03:08] <kiko> I was thinking of moving the Soyuz Person branch *entirely* into FOAF
[03:08] <kiko> but that needs some approval.
[03:08] <sabdfl> kiko: can you give me a url to check out the SoyuzPerson stuff?
[03:08] <kiko> that could mean bringing down soyuz one level, in fact
[03:08] <kiko> sure.
[03:09] <sabdfl> i've found the skins mechanism to be a*very* nice way to integrate foaf / doap with the other web apps
[03:09] <kiko> https://launchpad.ubuntu.com/soyuz/people
[03:09] <kiko> ah?
[03:10] <sabdfl> for example, I use skins to show all the bugs related to a project, and a product
[03:10] <sabdfl> here's how it works
[03:10] <sabdfl> the standard setup is for a ProjectSet to traverse to Project, which traverses to Product
[03:10] <sabdfl> and each of these objects has a page called +index with a corresponding template
[03:10] <sabdfl> that template shows the object "neutrally"
[03:11] <sabdfl> then I create another page on the object, called +malone-index
[03:11] <kiko> okay
[03:11] <sabdfl> and I add a defaultView *for the Malone skin* of +malone-index
[03:11] <sabdfl> then, inside Malone, I just traverse to a ProjectSet
[03:11] <sabdfl> but now you don't see the neutral page, you see the +malone-index
[03:12] <sabdfl> and that template renders the same object from a bugs perspective
[03:12] <kiko> that's awesome
[03:12] <sabdfl> (it actually shows a list of products and a summary of the new/accepted/rejected/fixed bugs in different severities)
[03:12] <sabdfl> now, i think foaf should work the same way
[03:12] <sabdfl> define a core person object, with different defaultviews
[03:12] <sabdfl> but the basic traversal stuff would remain the same for a Person object
[03:13] <kiko> cool
[03:13] <sabdfl> this allows you to get rid of DoapPerson and SoyuzPerson and MalonePerson
[03:13] <sabdfl> you just have a Person
[03:13] <kiko> so this must mean you agree to moving the person branch into foaf, and having soyuz just skin it?
[03:13] <sabdfl> which you will display differently based on the skin
[03:15] <BradB> morning
[03:16] <BradB> SteveA: Have you had a chance to look at upgrading Z3? I think it's something about our custom publisher that may now be b0rked with the upgrade.
[03:20] <sabdfl> hiya BradB
[03:20] <BradB> hi
[03:21] <BradB> sabdfl: we were going to walkthrough the dump this morning. when do you want to do that?
[03:21] <sabdfl> now is good
[03:21] <BradB> ok, reloading it, one sec
[03:23] <Kinnison> does python have the ? :  operator?
[03:24] <BradB> Kinnison: nope, it was specifically rejected after lengthy debate :)
[03:24] <Kinnison> poo
[03:24] <Kinnison> what's the python idiom for a?b:c then?
[03:25] <BradB> if/else
[03:25] <salgado> Kinnison, a and b or c
[03:25] <Kinnison> salgado: what if b evaluates to falsehood in a logical context?
[03:25] <Kinnison> (lua has this same issue)
[03:25] <BradB> Kinnison: it's just if/else.
[03:26] <Kinnison> BradB: thanks dude
[03:26] <salgado> Kinnison, in this case this didn't work
[03:27] <Kinnison> I was tempted to try and add an infix structure to lua to do it. Of the form: "b if a else c" but that interfered horribly with statement parsing
[03:27] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: New database schema baseline from production and binarypackage constraint fix for Kinnison (patch-839)
[03:32] <Kinnison> thanks stub
[03:34] <BradB> sabdfl: ok, had to do a bit of tla undo'ing and linking back to our older version of Z3. ready to go now.
[03:35] <sabdfl> i'm sort of in the same boat
[03:35] <BradB> sabdfl: you tried upgrading
[03:35] <BradB> ?
[03:36] <sabdfl> ok
[03:37] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: add production-4 config (patch-33)
[03:40] <sabdfl> i turned add_missing_from on in my db and now it's crashing ;-)
[03:40] <sabdfl> ok
[03:40] <BradB> oh, heh
[03:41] <stub> sabdfl: I'll give people plenty of warning before switching that to an error  :-)
[03:41] <sabdfl> well, debonzi's been working at in in Soyuz i thought i'd do the same for malone
[03:41] <stub> BradB: Did you update the Product vocabulary to use integers for tokens again? Or have I lost that work somewhere?
[03:42] <kiko> sabdfl, so do you say yea, on with the person-branch-move?
[03:42] <BradB> stub: yeah, i think i did, because product names aren't unique
[03:42] <sabdfl> person-branch?
[03:42] <sabdfl> ok bradb let's start i'll fix these things as they occur
[03:42] <BradB> ok
[03:42] <kiko> sabdfl, soyuz/person -> foaf/person ?
[03:43] <sabdfl> product names are unique within a project, projects are unique
[03:43] <stub> BradB: It was using project name + product name, which is unique. If that was the only problem, I'll switch it back
[03:43] <BradB> stub: it was? oh.
[03:43] <stub> (With a short circuit if the projectname == product name, just to be confusing ;)
[03:43] <BradB> stub: IDs are what everything else uses, why be different?
[03:44] <sabdfl> kiko: yes go ahead
[03:44] <kiko> sabdfl, you da man!
[03:44] <sabdfl> kiko: no, YOU rock
[03:44] <kiko> salgado, we got signal
[03:44] <salgado> kiko, fogo na bomba
[03:44] <stub> BradB: Because it makes the UI sucky. When I put it back, you can just type 'launchpad' into the text box and it will work. Or you can type 'gnome' into the text box and you get a select when the page reloads. So you don't have to use the popups at all.
[03:45] <BradB> stub: eek :) the other selects already uses IDs though, as i say.
[03:45] <sabdfl> BradB: i'd rather expose project/product than id
[03:46] <sabdfl> BradB: let's do this walkthrough
[03:46] <BradB> i'm ready whenever you are :)
[03:46] <stub> Sourcepackage is still under debate (it needs to be fixed - we just havn't worked out how), and the others are selects so it isn't exposed. I want to fix binarypackage selector next.
[03:46] <sabdfl> ok, /malone/packages/
[03:46] <sabdfl> stub: sourcepackage is the bitch
[03:47] <sabdfl> because id is the *only* unique way to refer to it
[03:47] <kiko> sabdfl, I have a surprise for our fellow lunchpadders this mataro session
[03:47] <kiko> just you wait
[03:47] <SteveA> BradB: I haven't looked at the zope3 yet.  I'll look at it a bit later.  I think it is to do with registering views for layers, and which is considered the default layer, but I can't be sure yet.
[03:48] <stub> Which we need to fix, either by not refering to it or sorting out constraints so we can. Something for the conference.
[03:48] <BradB> SteveA: ok, that'd be great. without being able to upgrade, i don't have a clear path with how to proceed on implementing what we want for filtering vocabs.
[03:48] <BradB> sabdfl: heh, yeah, that screen needs paging :)
[03:49] <BradB> sabdfl: and, well, searching, of course
[03:49] <sabdfl> stub: yes, well, we also have to reflect the reality out there ;-)
[03:49] <sabdfl> bradb yes
[03:49] <sabdfl> go to mpg321
[03:49] <BradB> this'll be another application of the super widget
[03:50] <BradB> sabdfl: ok, there
[03:50] <sabdfl> looks pretty good to me
[03:50] <sabdfl> would be nice to see # of bugs
[03:50] <sabdfl> also, i think we need to be able to filter bugs by status, severity
[03:50] <BradB> sabdfl: like "10 bugs found", you mean?
[03:50] <sabdfl> need a one-click accept / reject
[03:50] <sabdfl> yes
[03:51] <BradB> sabdfl: actually, this would take the user to the main search screen
[03:52] <BradB> sabdfl: by which i mean it should, but doesn't yet.
[03:52] <sabdfl> main search screen?
[03:52] <sabdfl> i disagree
[03:52] <BradB> sabdfl: yeah, the main bug listing.
[03:52] <sabdfl> i don't think we want a one-size-fits-all search page
[03:52] <BradB> sabdfl: why duplicate effort?
[03:52] <sabdfl> because different people will use malone differently
[03:52] <BradB> sabdfl: you can see all this information on the main search screen
[03:52] <BradB> sabdfl: i'm referring specifically to this functionality though.
[03:52] <sabdfl> yes, but then you end up with bugzilla
[03:53] <sabdfl> too many damn options to search on
[03:53] <BradB> sabdfl: this is simple though. we just filter on the package assignment.
[03:53] <sabdfl> yes
[03:54] <BradB> sabdfl: and when we decide there's another thing that needs to be included on a bug listing, you only have to pay a developer to do it once, instead, of, say 3 times
[03:54] <sabdfl> but think of having bits of malone embedded INSIDE Soyuz and Doap
[03:54] <sabdfl> in other words, i'm looking at a package, and click, now i see its bugs
[03:54] <sabdfl> this page will end up inside soyuz
[03:55] <BradB> sabdfl: sure, that's different from talking about not duplicating effort on this specific page.
[03:56] <BradB> sabdfl: what you're talking about involves ensuring we have a good, modular set of templates, to make it easy to reuse bits in other apps (e.g. expose macros for soyuz geeks to easily do bug listings on what are otherwise soyuz-like pages)
[03:56] <sabdfl> ok
[03:57] <BradB> and the links *will* have to point to real bugs, even in soyuz.
[03:57] <sabdfl> i *really* don't like the idea of a big search page, the way the "show all bugs" page is headed
[03:57] <sabdfl> the reality is that malone is many bug systems, aggregated
[03:57] <sabdfl> trying to show a god view of ALL the bugs is just going to blow people's minds
[03:58] <BradB> sabdfl: why don't you like having just one place to go to find out what you need to know about bugs?
[03:58] <BradB> sabdfl: seeing the god view will be extremely rare.
[03:58] <BradB> sabdfl: you only see 20 bugs at a time, and they'll always be filtered relative to your context. you'll only see them all if you say "show me ALL the bugs".
[03:59] <BradB> sabdfl: e.g. it might be mind-blowing that each of the 10 bugs assigned to you have also be assigned to four other packages, which would make for a huge listing, but you won't care, because you'll know nothing about those other assignments, because they'll be automatically filtered
[04:01] <sabdfl> BradB: i'm debating changing the bugsourcepackageassignment to assign to a tuple of ( sourcepackagename, distro )
[04:01] <sabdfl> on the basis that (a) these are pieces of information any user would be able to figure out
[04:01] <BradB> sabdfl: i mentioned this to you in london. you said not to bother, because at the start we'll just have ubuntu :)
[04:02] <sabdfl> yes, now we are starting to deal with it because I'm playing with the debbugs sync
[04:02] <BradB> (spn, distro) is an inevitable change.
[04:03] <sabdfl> the problem is, it's not exactly accurate
[04:03] <sabdfl> sourcepackage is in fact more accurate
[04:03] <sabdfl> because you might get two different sourcepackages in the same distro with the same name, and different bugs
[04:03] <sabdfl> and (spname, distro) does not allow you to differentiate
[04:04] <sabdfl> you might also get the same package in TWO distro's, but spname on its own does not allow you to filter it
[04:04] <sabdfl> the truest system would be ( sourcepackage, distro )
[04:04] <BradB> yeah
[04:05] <stub> Is sourcepackage actually that accurate? If you want accuracy you need to specify a sourcepackagerelease.
[04:06] <BradB> stub: not for an assignment dude
[04:06] <BradB> stub: there may be some automagic to pick the affected version which auto-creates the relevant infestation though.
[04:07] <BradB> stub: additionally, we've also talked about having it so that when a new /infestation/ is added, there's a little checkbox that says "notify the maintainer of this package", which'll automagically add an assignment, if there wasn't already one, so you're covered on both ends.
[04:08] <salgado> sabdfl, person related pages should be inside foaf/ or foaf/people/ ?
[04:08] <sabdfl> foaf/
[04:08] <sabdfl> actually, foaf/people/ gives you more room for other things
[04:08] <sabdfl> so run with that
[04:09] <salgado> sabdfl, ok. 
[04:10] <stub> With infestations, I think the (sourcepackagename,distro) is a good option. There is no way for a user to specify the sourcepackage to assign to - the only information they have is the name. If they specify the sourcepackagename, we can spawn the relevant infestations for maintainers to trim.
[04:11] <BradB> er, sorry, the "automagic" i referred to in picking the affected version; i meant that the user would pick the affected version and we'd automatically add the infestation.
[04:11] <BradB> i.e. we'd modify the bug add form to allow choosing a relevant version number
[04:12] <carlos> stub: is there any problem with carlos-launchpad-language-preference.sql? I'm asking because it's not applied yet to the database
[04:12] <sabdfl> the issue with name + distro, is that we need to know how to deal with bugs when the source package changes
[04:12] <stub> carlos: Oh. I applied a similar fix quite some time ago I think (after the discussion on the mailing list).
[04:12] <sabdfl> but... in many cases, name + distro will be canonical
[04:12] <sabdfl> and in fact, in many cases it will be the best way to tell people where t  find the fix
[04:12] <BradB> there's still a lot more metadata we're missing through. e.g. when a bug is reported on a product, we keep no information about the environment in which the user is able to reproduce the problem, which'll make life much harder for the people trying to fix it.
[04:13] <sabdfl> "ah, it's fixed in ubuntu / apache2"
[04:13] <sabdfl> BradB: that almost needs to be a set of data around the assignment
[04:13] <carlos> stub: hmm, didn't saw it :-P
[04:14] <stub> carlos: Check '\d person' and confirm
[04:14] <carlos> stub: yes, it's there
[04:14] <BradB> sabdfl: yeah, a set of data around something very soonish, that's for sure :)
[04:14] <carlos> stub: I'm going to kill the patch then. Thanks
[04:15] <BradB> sabdfl: though i could see the environment in which a bug is reproducable be /different/ for different versions (e.g. bug shows up on ppc and i386 in 1.17, but only on ppc by 1.20)
[04:16] <sabdfl> BradB: i think that will be described in the messages
[04:16] <sabdfl> i don't want to try to get too deeply into modelling every permutation and combination
[04:16] <BradB> sabdfl: that's not very useful though, because you can't search for stuff like that.
[04:16] <sabdfl> people love debbugs despite its lack of structure, perhaps because of it
[04:16] <sabdfl> seacrhing for arcane permutations and combinations is hugely overrated
[04:17] <BradB> it's not a major concern right now. time will tell.
[04:17] <sabdfl> can you click on one of the sync'd bug messages?
[04:18] <sabdfl> let's check out the display of the bug
[04:18] <BradB> eeeg, i really dislike the formatting of bug messages :/
[04:18] <carlos> sabdfl: I have a patch for the raw po/pot files as you requested, could you confirm you agree with it before I ask for the database merge?
[04:18] <BradB> sabdfl: what do you mean by click on one of the messages though?
[04:19] <BradB> i'm looking at one of the sync'd bugs, if that's what you meant
[04:22] <sabdfl> right
[04:22] <sabdfl> we need to clean up the message display
[04:22] <sabdfl> we need to figure out how best to store messages on a bug where the message is genuinely an email message
[04:23] <BradB> sabdfl: it was clean before, save for the formatting-of-incoming-email-reports issue.
[04:23] <sabdfl> cprov, Kinnison: are there functions in Gina to create a person given an email address? "sdfsfd sdfsdf <dsfsd@dfsd.com>" ?
[04:24] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Second try to be able to store raw po/pot files into our database (patch-840)
[04:25] <stub> For the record, Roundup is using pre because "people have tried all sorts of wierd ways of formatting the issues, but the only thing that works consistently is <pre>"
[04:26] <sabdfl> this is outside my knowledge of html etc
[04:26] <sabdfl> i need to confirm that we are happy just to put the full email (headers and body and attachments) in the "contents" field of Message table
[04:27] <sabdfl> thereafter i'll leave it to bradb and stub to figure out display issues
[04:27] <BradB> sabdfl: as long as we have some way of identifying type, yeah, i'd want to dump the whole message in there.
[04:28] <kiko> sabdfl, yes, there are.
[04:28] <kiko> sabdfl, (functions in gina)
[04:28] <kiko> sabdfl, (to create a new person -- I should know, I wrote it!)
[04:28] <sabdfl> ok
[04:28] <kiko> stub, <pre> is really the only way to go with comments.
[04:28] <stub> Do you actually have a real email message from debbugs, or something munged? Character encoding issues would mean you can't just dump the raw email-as-received onto a webpage.
[04:28] <kiko> otherwise you can't do ASCII art.
[04:28] <kiko> and ASCII art is mandatory
[04:29] <kiko> (seriously)
[04:29] <stub> kiko: (_0_)
[04:29] <BradB> stub: not onto the web page; into the db
[04:29] <kiko> stub, 3:|>
[04:30] <kiko> lol
[04:30] <kiko> thanks for the consideration
[04:31] <BradB> sabdfl: anything else? are you satisified with our idea of having a "google" in malone?
[04:32] <BradB> actually, google integration would be pretty cool too. top 5 google links for the bug title or something.
[04:32] <BradB> configurable portlets, etc. but i digress...
[04:33] <sabdfl> BradB: i also want to find one of these reports where the title is so long it makes the table bigger than the screen
[04:33] <sabdfl> wider
[04:33] <BradB> sabdfl: yeah, we'll do eliding there.
[04:33] <sabdfl> can you do that in TAL?
[04:34] <BradB> "a huge problem that will entirely destroy your machine if you..."
[04:34] <BradB> sabdfl: i doubt TALES is that helpful. should be easily done with a bit of python though.
[04:41] <stub> It would be trivial to add the eliding formatter to the fmt: namespace - checkout webapp/tales.py
[04:42] <stub> tal:content="whatever/title/fmt:elide80" or tal:content="whatever/title/fmt:shorten/40" or something similar
[04:43] <sabdfl> that would be perfect
[04:43] <sabdfl> BradB: other than that i think we're in good shape
[04:43] <BradB> cool
[04:46] <BradB> SteveA: any news on upgrading Z3? if not, i think it's more effective for me to return bug-fixing, in the hopes that we'll have this problem solved by the end of todayish.
[04:53] <sabdfl> stub: can i send you a fragment of sql to strip cve ref's into a separate table?
[04:54] <SteveA> BradB: I'm still working on other stuff right now.  I will look at it today.
[04:54] <BradB> ok, thanks
[04:56] <stub> sabdfl: send away.
[04:56] <sabdfl> so guys, if i strip CVE references into a separate table, what's a good name for the BugExternalRef table if it's just URL's?
[04:56] <stub> I think the name is fine
[04:57] <sabdfl> stub: yowser, though you'd be in dreamland by now!
[04:57] <sabdfl> BugExternalRef stays that?
[04:57] <stub> yup
[04:57] <sabdfl> ok
[04:57] <SteveA> is there a bug filed on the fmt:shorten/60 idea?
[04:57] <sabdfl> but can i at least rename the "data" to "url" at this point?
[04:58] <stub> Nope, but somebody should do it before I do the dogfood codedrop...
[04:58] <stub> sabdfl: Sure
[04:58] <sabdfl> and description to title?
[04:58] <BradB> sabdfl, stub: did one of you guys undo my change to "expand" the comment add widgets by default?
[04:59] <SteveA> stub: when are you doing the dogfood codedrop?
[04:59] <stub> Yes. Description makes no sense. One day we might want a shortdesc, but it is probably WHUI
[04:59] <sabdfl> WHUI?
[04:59] <stub> BradB: Not me
[04:59] <SteveA> we haven't use it
[04:59] <stub> Erm... YAGNI
[04:59] <sabdfl> BradB: yes, i did
[04:59] <SteveA> what a yagni becomes if you allow it into the code
[04:59] <BradB> sabdfl: urgh, why? :)
[04:59] <stub> I'm getting ahead of my self ;)
[04:59] <sabdfl> because the form is ugly, and most people don't comment on bugs they browser
[04:59] <BradB> sabdfl: yeah, that's why i moved it to the bottom
[05:00] <sabdfl> BradB: erm... it needs to be at the top
[05:00] <BradB> sabdfl: why?
[05:00] <sabdfl> everyone hates having to scroll to the bottom of bugzilla to comment
[05:00] <sabdfl> and at the top, it's in the "most recent" position
[05:00] <kiko-fud> it does help make sure people read comments though.
[05:00] <stub> SteveA: As soon as my last patch filters through pqm I was hoping to drop. There will be another tomorrow too.
[05:00] <sabdfl> comments should start with the most recent
[05:00] <kiko-fud> but there's always food for thought there
[05:00] (elmo/#launchpad) heh, debbugs use to do that and changed
[05:01] <SteveA> stub: I can do this in 10 mins.
[05:01] (elmo/#launchpad) it's the classic no-win situation, some people hate most-recent-at-the-top, others love it
[05:01] <BradB> I expect tree widgets to be used for trees, but oh well.
[05:01] <sabdfl> bradb and i have been in a dance, moving it top to bottom and back, and collapsed and back
[05:02] <sabdfl> i don't want a threaded display there, at least not for a while
[05:02] <stub> Ohh... I see user preferences comming sooner rather than later. <div tal:condition="user/comment_box_up_top_dammit">...</div>
[05:02] <BradB> sabdfl: me neither.
[05:02] <stub> page test that!
[05:02] <sabdfl> elmo: i suspect most of the people who love it at the bottom do so because they want to change other people's behaviour
[05:03] <kiko-fud> well, indeed. they want people to read comments instead of ignore them :)
[05:03] <sabdfl> let's just sit tight where it is, we can make these sorts of changes much later
[05:04] <BradB> the way it is currently i've got to click my mouse an extra time and do a bit more pointer-fu to get what i want. perhaps i'm just that lazy that i notice extra-effort-required like that.
[05:04] <BradB> okie doke
[05:04] <kiko-fud> dokie
[05:05] <BradB> i wonder why i didn't put next and back links on the paging. i'll have to change that now so i can close the paging bug.
[05:07] <BradB> dilys: @#*$@&
[05:10] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: IHugeVocabulary vocabs should have human readable tokens for funky UI goodness (patch-841)
[05:10] <sabdfl> BradB: most people who view a bug do not comment on it
[05:11] <sabdfl> those who do, have to do pointer-fu in any event
[05:11] <sabdfl> BradB: looks like she's listening to you
[05:11] <BradB> she's not telling me about bugs that have been fixed though
[05:18] <dilys> New Malone bug #66: "Distro sourcepackage search navigation broken", submitted by Brad Bollenbach
[05:18] <dilys> https://launchpad.ubuntu.com/malone/bugs/66
[05:26] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: added fmt:shorten/60 feature to tales (patch-842)
[05:38] <dilys> New Malone bug #67: "Bug assignments search too slow", submitted by Brad Bollenbach
[05:38] <dilys> https://launchpad.ubuntu.com/malone/bugs/67
[05:40] <BradB> daf: ping
[05:46] <carlos> SteveA: pong
[05:47] <SteveA> hi carlos.  how's the work on po and pot importing over the web going?
[05:47] <stub> Kinnison: I'm about to kill the librarian.
[05:48] <carlos> SteveA: new database proposal in rocketfuel
[05:48] <carlos> waiting for mark's review
[05:48] <Kinnison> stub: on zhongshan?!
[05:48] <carlos> SteveA: daf started yesterday the submit form
[05:48] <stub> Kinnison: Oh - sorry ;)
[05:48] <stub> Kinnison: Mawson ;)
[05:48] <Kinnison> stub: *grin*
[05:49] <Kinnison> stub: I'd be everyone's least favourite coder if I were doing these tests on mawson
[05:49] <Kinnison> I keep wedging the database for a start
[05:49] <carlos> and I'm going to look at the final import script/process, but need to discuss somethings with daf
[05:50] <SteveA> will the new database stuff go into stubs next dogfood drop?
[05:50] <Kinnison> although the good news is that I almost have gina to the stage we need her at for continual dogfooding of all of hoary
[05:50] <carlos> SteveA, sabdfl: well, I could also ask you about it, what should import the pot/po from the raw field in the database? a cron like script or from a website by hand?
[05:51] <carlos> SteveA: if mark agrees it should
[05:51] <SteveA> right now, just write it so that there is a URL to go to that processes one item from the queue
[05:51] <SteveA> once you have all this working, we can talk about the exact mechanics of making it work
[05:53] <sabdfl> cron like script
[05:53] <sabdfl> Kinnison: rock
[05:53] <sabdfl> SteveA, carlos, there isn't really a queue is there?
[05:53] <sabdfl> just a list of potemplates and pofiles which have an unprocessed uploaded file
[05:53] <carlos> sabdfl: right
[05:53] <carlos> the queue is the answer of a query
[05:53] <sabdfl> carlos: is your db patch in rf?
[05:53] <carlos> sabdfl: yes
[05:53] <sabdfl> cool
[05:53] <SteveA> essentially, that's a queue.  we want to take one item from it at a time.
[05:53] <Kinnison> sabdfl: I wanted to ask you. How's Oscar?
[05:53] <SteveA> the order of it doesn't really matter
[05:54] <Kinnison> sabdfl: I'm starting to think of useful tests for him to do
[05:54] <carlos> sabdfl:  carlos-raw-po-pot-files.sql
[05:54] <carlos> at launchpad/database/schema/pending
[05:54] <daf> BradB: pong
[05:54] <daf> SteveA: pong
[05:54] <SteveA> hi daf
[05:54] <SteveA> how's the upload forms going?
[05:55] <sabdfl> guys, we are going to ROCK the Mataro Sessions ;-)
[05:55] <daf> hi Steve
[05:55] <SteveA> need any help with the forms?
[05:56] <daf> not yet
[05:56] <carlos> sabdfl: yeah!
[05:56] <BradB> daf: when will dilys tell us when bugs are fixed again?
[05:56] <dilys> Malone bug #44 fixed for product Malone: Bad destination after editing a bugassignment
[05:56] <dilys> https://launchpad.ubuntu.com/malone/bugs/44
[05:57] <BradB> heh
[05:57] <daf> dilys didn't know about product assignements, only package assignments
[05:57] <daf> and she didn't know about fixed bugs, only closed ones
[05:57] <daf> s/bugs/assignments/
[05:58] <BradB> she might also want to know about rejected bugs
[05:58] <stub> carlos: drop done
[05:59] <sabdfl> stub: doh, there's a silly bug in that fragment
[05:59] <carlos> SteveA: any URL suggestion for the moderation queue form?
[05:59] <sabdfl> i need to DELETE FROM bugexternalref WHERE bugreftype = 1;
[05:59] <SteveA>  rosetta/+uploadqueue 
[05:59] <sabdfl> so we get rid of the CVE things from BugExternalRef after we've created them in CVERef
[05:59] <carlos> stub: perfect, thanks!!!
[06:00] <carlos> SteveA, daf: The dogfood server is now 100% functional like the old alpha server
[06:00] <SteveA> cool
[06:00] <carlos> (or it should) :-P
[06:00] <daf> excellent
[06:02] <carlos> daf: and your UI improvements are soooo cool :-P
[06:02] <daf> thanks :)
[06:02] <sabdfl> stub: should send you an updated copy, with comments?
[06:10] <stub> sabdfl: Or just check it into the pending directory. With comments of course.
[06:10] <sabdfl> stub: the pending dir always gets me stuck
[06:11] <sabdfl> because i can't commit it once i start working on the code that will use
[06:11] <sabdfl> it
[06:11] <sabdfl> right now, i can't commit to rf, because my code expects the new structure CVE / ext ref
[06:11] <sabdfl> the tests will fail, unless that patch is in the schema/patch- file
[06:12] <stub> ok. And you can't just commit a file you just added, which will hopefully be fixed in baz sometime sooner rather than later
[06:12] <SteveA> that's the point of using a branch.  but, branches are hassle.
[06:12] <daf> stub: I thought that bug had been fixed
[06:12] <daf> I'm sure I did that recently
[06:13] <stub> 'baz switch' should make it much nicer now. 'baz tag -S launchpad--dbpatches--0; baz switch launchpad--dbpatches--0'
[06:13] <stub> Ooh... coolies.
[06:13] <sabdfl> if i was really smart i would know in advance what db changes i'll need :-)
[06:14] <sabdfl> but alas, i'm not that smart
[06:14] <sabdfl> and nonetheless, if the db change requires the existing code to change  you have the catch22
[06:14] <SteveA> you can end up writing dodgy "if" statements all over...
[06:14] <SteveA> but that is obviously bad news
[06:17] <stub> sabdfl: Those comments on the way, or do you promise to update comments.sql?
[06:17] <dilys> Merge to rocketfuel@canonical.com/buildbot--devel--0: dont conflict on _branch in versions (patch-75)
[06:17] <sabdfl> stub: updated one in mail in 30 seconds.
[06:17] <sabdfl> includes the delete from
[06:19] <Kinnison> sabdfl: did you see my question about Oscar?
[06:19] <sabdfl> Kinnison: nope?
[06:19] <Kinnison> sabdfl: I asked how it was going because I have started coming up with ideas for tests I want oscar to run
[06:20] <sabdfl> Kinnison: in sooth, i've not begun
[06:20] <sabdfl> stub: on the wire
[06:20] <sabdfl> stub: how best to handle this one?
[06:20] <Kinnison> sabdfl: Heh, I guessed you were way busy by the huge number of changes coming from your camp ;-)
[06:20] <sabdfl> if you approve it and give me a patch number, i'll move it in and commit it at the same time as the code to handle the changes
[06:23] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: dont conflict on _branch in versions (patch-843)
[06:26] <dilys> Merge to 	rocketfuel@canonical.com/launchpad--production--1.4: cherry pick _branch overload fix (patch-1)
[06:27] <stub> sabdfl: Approved. patch-5-02-0.sql.
[06:27] <sabdfl> stub: great! any changes?
[06:28] <sabdfl> stub: lifeless says it's all good
[06:28] <stub> sabdfl: Need sample data regenerated unless you want me to handle that post commit
[06:28] <sabdfl> stub: could you?
[06:28] <sabdfl> hmm... i will
[06:29] <sabdfl> no prob
[06:30] <stub> sabdfl: Are CVE's integers or text? I thought they were integers.
[06:31] <sabdfl> ive kept them as text just in case, am happy to change them now
[06:32] <stub> I think integer would be better - it is easier to make it text later if necessary than vice-versa.
[06:32] (elmo/#launchpad) they're not integers?
[06:32] (elmo/#launchpad) they're {CVE,CAN}-[0-9] {x4}-[0-9] {x4}
[06:33] (elmo/#launchpad) in some madeup pseudo glob, pseudo regex
[06:33] <Kinnison> sabdfl: Looks like I got my first correct from-scratch import of warty main,restricted for i386,powerpc,amd64 with proper shared arch:all stuff
[06:33] <sabdfl> great work Kinnison
[06:33] <Kinnison> sabdfl: I'm knackered. Gina is a tough mistress
[06:33] <stub> elmo: Ta.
[06:34] <sabdfl> like takiing a 16 year old to a mature escort...
[06:34] <stub> sabdfl: so scrap the integer, but feel free to comment BugExternalRef if you have your editor open ;)
[06:34] <Kinnison> sabdfl: If you say so. *sir* :-)
[06:34] <sabdfl> stub: willdo
[06:34] <Kinnison> Sounds like the best way to do CVE validation will be a nice python function
[06:37] <dilys> New Malone bug #69: "Need a CVE id validator", submitted by Stuart Bishop
[06:37] <dilys> https://launchpad.ubuntu.com/malone/bugs/69
[07:14] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix huge-select search result default option (patch-844)
[07:15] <carlos> stub: dude, how many hours your days have?
[07:16] <carlos> hmm
[07:40] <carlos> SteveA, sabdfl,daf : ping
[07:40] <sabdfl> carlos: hi
[07:40] <carlos> how could we handle the development of the po/pot import until the database changes are applied to rocketfuel?
[07:40] <carlos> because we need some changes to databas/pofile.py
[07:40] <carlos> but if we change that file without changing the database launchpad will be broken
[07:41] <carlos> and both, daf and I need those changes to do the work
[07:42] <sabdfl> that's the glitch in our dba method at the moment
[07:42] <sabdfl> in theory, make a branch, work on the branch
[07:42] <daf> I'm planning to temporarily use the ZODB
[07:42] <sabdfl> daf: please don't
[07:42] <daf> why not?
[07:42] <sabdfl> because it will just require more fiddling to get running properly
[07:43] <sabdfl> carlos: let me look at the db patch
[07:43] <sabdfl> i can probably make a few comments, then stub can approve it first thing in his morning
[07:43] <sabdfl> and you can commit tomorrow
[07:43] <sabdfl> are you and daf both going to be working on the same codebase?
[07:43] <lulu> night all :o)
[07:43] <carlos> to work from a branch I suppose daf or I should tag from our personal archive to prevent the star break, right?
[07:44] <sabdfl> yes
[07:44] <carlos> sabdfl: daf will do the submit part
[07:44] <carlos> and I will do the final import part
[07:44] <sabdfl> ok
[07:44] <carlos> two different forms
[07:44] <sabdfl> if daf makes the core change (sql patch, interface and db objects), then
[07:45] <sabdfl> you tag off daf into a new working branch / dir
[07:45] <sabdfl> then you can work on separate aspects of the problem
[07:45] <sabdfl> daf can merge your work regularly
[07:45] <sabdfl> when you are ready, daf commits
[07:45] <carlos> ok
[07:46] <carlos> hope arch works as it should ;-)
[07:46] <sabdfl> daf, does that sound workable?
[07:46] <daf> it sounds possible
[07:46] <sabdfl> the main thing will be that when daf merges from carlos, daf must merge from the NEW BRANCH
[07:46] <daf> I suspect it might be overkill
[07:47] <carlos> sabdfl: perhaps we could wait some days to implement this feature
[07:47] <sabdfl> the problem is that to get started on this you both need the same set of changes
[07:47] <carlos> until the database change is done....
[07:47] <sabdfl> carlos: yes, if you can wait till tomorrow, then we can get the db stuff squared away
[07:47] <carlos> daf: what do you think?
[07:47] <carlos> is just that I thought it's a big priority task
[07:48] <carlos> that's why I asked
[07:48] <daf> is there anything stopping you from working on the database code in your own archive?
[07:48] <carlos> daf: the pofile.py changes
[07:48] <carlos> to use the new database rows
[07:48] <carlos> I suppose you need it also, right?
[07:49] <daf> yes, I will need it
[07:50] <carlos> so you decide, I tag from your archive and go ahead with this or wait for stub and mark's review tomorrow
[07:51] <daf> ok, let's try branching
[07:51] <carlos> ok
[07:52] <carlos> will you work on your main archive ?
[07:52] <daf> yes
[07:52] <carlos> ok
[08:04] <carlos> wow, it's still tagging your archive..
[08:05] <daf> making the base-0, I expect
[08:05] <daf> perhaps I should put cacherevs in my archive
[08:06] <carlos> it's checking the gpg sign of all your patches 
[08:07] <carlos> done
[08:16] <carlos> this is insane
[08:16] <carlos> 20 minutes and it's still tagging the archive
[08:17] <carlos> daf: what does cacherevs exactly?
[08:17] <daf> pristine revisions in an archive, I think
[08:18] <daf> saves on the patching
[08:18] <carlos> and consumes more harddisk, right?
[08:18] <daf> yep :)
[08:18] <carlos> I just understood the need of fooo--2004
[08:19] <daf> :)
[08:19] <daf> yeah, doing a lot of tagging once every year is not so bad
[08:19] <carlos> daf: the problem is when someone else needs to tag your archive :-)
[08:20] <carlos> at the end of the year
[08:20] <daf> true
[08:20] <carlos> and we have only less than 6 months of work...
[08:20] <daf> I wonder how you deal with that...
[08:20] <carlos> I cannot imagine it at the end of 2005....
[08:21] <daf> lifeless: thoughts?
[08:21] <carlos> in fact, I don't want to imagine it ;-)
[08:22] <carlos> "only" 99 patches to go...
[08:24] <carlos> daf: wait for the patch-300, it's prettier
[08:24] <carlos> :-)
[08:24] <daf> :)
[08:24] <daf> actually, I could have commit hook that automatically makes a cacherev if patch % 50 == 0
[08:26] (mdz/#launchpad) BradB: here?
[08:26] <BradB> mdz: yeah
[08:26] <carlos> daf: feel free to share it with me ;-)
[08:27] (mdz/#launchpad) BradB: I'd like for pitti to start using Malone to track security bugs, if you're up for it
[08:27] (mdz/#launchpad) BradB: should be a reasonable small-scale real-world test
[08:27] <daf> hi Martin :)
[08:27] <pitti> Hi daf!
[08:27] (mdz/#launchpad) BradB: should we set up a separate instance for that, or what?
[08:27] <pitti> Now I finally know where all the other guys are hanging out :-)
[08:27] <BradB> mdz: sure...does this involve us having to import anything?
[08:28] <BradB> mdz: i think we should use the same instance.
[08:28] <BradB> which is still tinyish, gragh
[08:28] (mdz/#launchpad) BradB: we can start with an empty db, should be fine
[08:29] (mdz/#launchpad) pitti can import a couple of things by hand if he has open issues to track
[08:29] <BradB> ok
[08:29] (mdz/#launchpad) we just ran into a situation where we released an advisory, and then a new cross-reference appeared
[08:29] <pitti> can I import Debian bugs?
[08:29] (mdz/#launchpad) and we don't have anyplace to record that information
[08:29] <pitti> or shall I create new ones?
[08:29] (mdz/#launchpad) pitti: sabdfl was talking about that, I think we have that capability
[08:29] <carlos> we are invaded by Ubuntu!!!
[08:30] <sabdfl> mdz, pitti, we'll bring this on stream for production use during es-conf
[08:30] <pitti> sabdfl: a very good idea. Can we have kind of a tutorial for the distro folks?
[08:30] <BradB> pitti: do you know how to access malone and all that then?
[08:30] <pitti> BradB: as I said, I never saw it
[08:30] <pitti> BradB: do I have/need an account?
[08:31] <BradB> pitti: you have one
[08:31] (mdz/#launchpad) sabdfl: does this sound OK as an alpha test?
[08:31] <BradB> pitti: whatever your ubuntulinux.org u/p is
[08:31] <pitti> ah, nice
[08:31] <BradB> pitti: you also need the client certificate
[08:31] <BradB> pitti: the url is https://launchpad.ubuntu.com/malone/bugs
[08:31] <sabdfl> mdz: sure
[08:32] <BradB> pitti: the client cert was mailed to the list a while back, called launchpad.p12, i think
[08:32] <pitti> BradB: hmm, 403
[08:32] <BradB> pitti: you need the cert :)
[08:32] <pitti> BradB: to which list?
[08:32] <BradB> lp@ i think
[08:33] <pitti> BradB: http://lists.ubuntu.com/archives/lp does not exist
[08:33] <pitti> BradB: can you please simply mail me the cert?
[08:33] <carlos> pitti: launchpad
[08:33] <BradB> pitti: what's your email?
[08:33] <pitti> BradB: martin.pitt@canonical.com
[08:34] <BradB> sent
[08:35] <pitti> BradB: got the mail now
[08:36] <carlos> lifeless, daf: wow. 40 minutes took the tag!!
[08:36] <pitti> BradB: sorry for sounding dumb, but what shall I do with this file now?
[08:37] <kiko> Kinnison!
[08:37] (mdz/#launchpad) pitti: point firefox at it
[08:37] (mdz/#launchpad) pitti: or perhaps go into the certificate preferences and import it there
[08:37] <pitti> mdz: hmm, it offers me to download it
[08:37] <pitti> mdz: I already looked for a cert pref dialog
[08:38] <daf> carlos: :-(
[08:38] <pitti> ah, here
[08:38] (mdz/#launchpad) pitti: preferences, advanced, certificates, manage certificates
[08:38] <pitti> mdz: yeah, got it
[08:39] <pitti> BradB: I set my own password, now it asks me for the password that was used to encrypt this certificate
[08:39] <BradB> lunchpad
[08:39] <pitti> oh, that wasn't a typo :-)
[08:39] <pitti> seems to work
[08:40] <BradB> cool
[08:40] <pitti> BradB: thanks
[08:40] <BradB> no prob
[08:41] <BradB> pitti: if you find bugs in malone, you can report them against the malone product
[08:41] <pitti> okay
[08:41] <pitti> I just got the bug confirmation from Debian
[08:41] <pitti> can I import this bug or shall I create a new one?
[08:41] <kiko> pitti, dude, that is ONE BIG FRIGGIN PATCH
[08:41] <kiko> can't you escape the autotools crud?
[08:41] <pitti> kiko: mysql?
[08:41] <kiko> yeah
[08:41] <pitti> autotools?
[08:42] <BradB> pitti: there's no debian import support
[08:42] <BradB> pitti: there will be, but there isn't yet.
[08:42] <pitti> kiko: the mysql debdiff does not touch autotools files
[08:42] <kiko> --- mysql-dfsg-4.0.20.orig/bdb/dist/configure
[08:42] <kiko> +++ mysql-dfsg-4.0.20/bdb/dist/configure
[08:43] <kiko> oh.
[08:43] <pitti> kiko: however, every hunk is present twice, due to the "odd" build system
[08:43] <kiko> sorry, I looked at the wrong file.
[08:43] <pitti> kiko: debdiff mysql-dfsg_4.0.20-2ubuntu1.dsc mysql-dfsg_4.0.20-2ubuntu1.1.dsc|lsdiff | grep configure
[08:43] <pitti> kiko: empty
[08:44] <pitti> BradB: hmm, I tried with my u.o website login, does not work
[08:44] <pitti> BradB: I do not get any error, just the login page agein
[08:46] <BradB> pitti: have you changed your p/w recentlyish?
[08:46] <pitti> kiko: maybe now you have an idea why the update is pending for so long :-)
[08:46] <pitti> BradB: recently == about a month ago
[08:46] <kiko> pitti, it's scary
[08:46] <BradB> pitti: you'll have to use the older one
[08:46] <pitti> kiko: agreed :-)
[08:46] <pitti> kiko: not the patches I'm used to for other packages
[08:47] <pitti> kiko: however, this fixes some design flaws,  three-liners don't work there
[08:47] <pitti> BradB: argh, after registering to plone I immediately changed it to my own
[08:47] <pitti> BradB: I don't know the original one
[08:47] <pitti> BradB: I'll look into my mail archives
[08:48] <BradB> pitti: can you confirm that your login works on ubuntulinux.org right now too?
[08:49] <pitti> it did an hour ago
[08:49] <pitti> BradB: yes, confirmed
[08:49] <BradB> hm, well, if you're positive it doesn't work on the dogfood site, then yeah, i'd try the older one.
[08:52] <pitti> BradB: I found my original password, but it doesn't work neither :(
[08:52] <kiko> yeah, I admire you for it, but ooof
[08:52] <BradB> pitti: you've only had those two p/w's on ul.org ever?
[08:53] <pitti> BradB: yes
[08:53] <pitti> BradB: the autogenerated one after registering
[08:53] <pitti> which I immediately changed to my own
[08:53] <BradB> I dunno, you'll have to ask stub then, unfortunately.
[08:53] <pitti> BradB: can you reset it somehow?
[08:53] <pitti> okay
[08:53] <pitti> darn
[08:54] <BradB> pitti: you've got mail dude
[08:55] <BradB> let's try this
[08:55] <pitti> not yet arrived
[08:55] <pitti> ah, now
[08:55] <BradB> i'm not sure if the link is correct in that email, but you should be able to figure out the correct one if it isn't
[08:56] <pitti> hey, what's this?
[08:56] <pitti> " Sorry, there has been a problem in resetting your password. Please try again, using the Forgotten password  form"
[08:57] <BradB> what url?
[08:57] <pitti> I just used the form to try again
[08:57] <pitti> I used the URL you sent me
[08:57] <BradB> what url?
[08:57] <pitti> https://www.ubuntulinux.org/forgottenpassword/5brqqfj0059xnk4kfbns854gdsr5gxvfdnr9lzqm
[08:58] <BradB> as i say, the url might be incorrect
[08:58] <BradB> and it is
[08:58] <pitti> I just got a new one
[08:58] <pitti> http://www.ubuntulinux.org/forgottenpassword/bxdn426v2738fm1lchs3ctg2s0hp6hd12x1ghsmf
[08:58] <BradB> dude!
[08:58] <BradB> you don't want to touch that
[08:58] <pitti> okay
[08:58] <BradB> change the link in the first email you go to launchpad.ubuntu.com
[08:58] <pitti> " A system error occurred."
[08:59] <BradB> oh yeah? crap, i was worried that it still hadn't been fixed. :/
[08:59] <pitti> well, this error was for the u.o link
[08:59] <pitti> I'm trying the launchpad one now
[09:00] <pitti>  Error type: zope.publisher.interfaces.NotFound
[09:00] <pitti> NotFound: Object: <canonical.publication.RootObject object at 0x41002b4c>, name: youforgottenpassword'
[09:00] <sabdfl> SteveA: around?
[09:00] <daf> that's a 404 in Zopespeak :)
[09:00] <daf> what's the URL?
[09:00] <pitti> https://launchpad.ubuntu.com/forgottenpassword/5brqqfj0059xnk4kfbns854gdsr5gxvfdnr9lzqm
[09:00] <sabdfl> daf, bradb, we're converting code from somewhere else to work in zope3
[09:01] <BradB> pitti: https://launchpad.ubuntu.com/ubuntulinux/forgottenpassword/5brqqfj0059xnk4kfbns854gdsr5gxvfdnr9lzqm
[09:01] <sabdfl> and seeing the problem where NONE of the object attributes are visible to Z3
[09:01] <sabdfl> I have an interface, which seems correct
[09:01] <sabdfl> a content declaration in the zcml
[09:01] <pitti> this gives a right plone form
[09:01] <daf> hmm, I've seen some problems writing to attributes, but not with viewing them
[09:01] <pitti> I enter my stuff and then
[09:02] <sabdfl> permission=zope.Public AND set_schema=interfacename
[09:02] <pitti>  Error type: exceptions.NameError
[09:02] <pitti> Traceback (innermost last):
[09:02] <pitti>     * Module zope.publisher.publish, line 138, in publish
[09:02] <pitti>       result = publication.callObject(request, object)
[09:02] <pitti> sorry, dudes :-/
[09:02] <pitti> NameError: global name 'getUtility' is not defined
[09:02] <daf> hmm, interesting
[09:02] <BradB> pitti: eck, yeah, that is really unfortunate to see on a near-production machine. :/
[09:03] <pitti> ack
[09:03] <BradB> sabdfl: yeah, you saw me mention that right/
[09:03] <BradB> ?
[09:03] <pitti> BradB: do you want the full trace?
[09:03] <BradB> sabdfl: that's what i spend a couple hours trying to figure out yesterday, to no avail
[09:03] <BradB> pitti: no, i can see it here
[09:04] <BradB> pitti: you'll have to ask stub to get your p/w sorted out then
[09:04] <pitti> I will
[09:04] <pitti> he's not online now, I try it tomorrow morning
[09:04] <pitti> i. e. in about 10 hours
[09:04] <BradB> sounds good, thanks
[09:04] <pitti> thanks to you, too
[09:04] <pitti> nice to be an alpha tester :-)
[09:05] <BradB> sabdfl: SteveA was going to look into it today.
[09:05] <pitti> mdz: I'm afraid this experiment has to wait until tomorrow, then
[09:05] <daf> BradB: pitti's looks like a missing import to me
[09:05] <sabdfl> BradB: where did you see this?
[09:05] <daf> * pitti's error
[09:06] <sabdfl> hold on, can one of us not just reset pitti's passwd to something simple for the purposes of this run, on dogfood?
[09:07] <BradB> daf: yes
[09:07] <BradB> sabdfl: when i tried upgrading zope 3 locally
[09:07] <kiko> it's a missing import, surely.
[09:09] <pitti> go, BradB, go! :-)
[09:09] <sabdfl> BradB: i haven't done any z3 update
[09:10] <BradB> oh, i misread your earlier comment
[09:11] <sabdfl> ive seen this before
[09:11] <sabdfl> spend hours staring at it
[09:12] <sabdfl> it turns out to be a tiny bit of zcml somewhere
[09:12] <sabdfl> basically, the zope security proxy is not allowing ANY reading of the attriutes
[09:13] (mdz/#launchpad) pitti: ok
[09:18] <BradB> pitti: your email in the system is martin@piware.de
[09:19] <BradB> pitti: anyway, i've reset your p/w for now. i'll /msg you
[09:20] <pitti> hey, now it shows "You're logged in" :-)
[09:20] <pitti> thanks, BradB
[09:21] <pitti> mdz: I'm in
[09:21] (mdz/#launchpad) great
[09:21] <pitti> mdz: so now I create a new report, tag the CAN stuff at it
[09:21] <BradB> pitti: cool
[09:21] <pitti> mdz: then I close it again and mark the versions?
[09:21] (mdz/#launchpad) do we have a way to add references to USNs?
[09:21] <BradB> sabdfl: what error are you seeing exactly?
[09:21] (mdz/#launchpad) pitti: sounds appropriate
[09:21] <sabdfl> ForbiddenAttribute
[09:22] <sabdfl> mdz: we have a general URL link
[09:22] <sabdfl> we could easily add a USN
[09:22] <BradB> sabdfl: that's almost surely a missing interface declaration.
[09:23] <BradB> sabdfl: e.g.
[09:23] <BradB>     <content class="canonical.launchpad.database.Bug">
[09:23] <BradB>         <allow interface="canonical.launchpad.interfaces.IBug" />
[09:23] <BradB>         <require permission="zope.View" set_schema="canonical.launchpad.interfaces.IBug" />
[09:23] <BradB>     </content>
[09:23] <sabdfl> <content class="canonical.launchpad.database.Branch">
[09:23] <sabdfl>         <allow interface="canonical.launchpad.interfaces.IBranch" />
[09:23] <sabdfl>         <require
[09:23] <sabdfl>             permission="zope.View"
[09:23] <sabdfl>             set_schema="canonical.launchpad.interfaces.IBranch"
[09:23] <sabdfl>         />
[09:23] <sabdfl>     </content>
[09:23] <BradB> what's the attribute that's forbidden?
[09:23] <sabdfl> all of them
[09:24] <sabdfl> dir(subject) gives [] 
[09:24] <sabdfl> id in particular
[09:24] <daf> what's the difference between zope.View and zope.Public?
[09:25] <BradB> sabdfl: you're positive that config's getting loaded? e.g. what if you change it to IBranchadljasdfj?
[09:25] <sabdfl> hmm...
[09:26] <sabdfl> i think bradb just hit the nail on the head
[09:26] <sabdfl> BradB: big, big, big brownie points
[09:26] <BradB> ;)
[09:27] <pitti> mdz: I just had a second look
[09:27] <pitti> mdz: the new CAN-2004-1015 does not apply to the Ubuntu and Debian versions
[09:29] (mdz/#launchpad) pitti: heh, ok
[09:30] (mdz/#launchpad) pitti: thinking of it, we should probably have a way to represent that information
[09:30] (mdz/#launchpad) like Debian's nonvulns list
[09:30] (mdz/#launchpad) sabdfl, BradB: is this possibly a Malone thing, or part of a hypothetical security database app?
[09:30] <pitti> mdz: right now I wrote into the changelog that we aren't vulnerable to CAN-2004-1011
[09:31] <BradB> mdz: if it's an important external source related to a bug (e.g. an id that links to something on a security site) we probably want to integrate it into malone...if that's what you're asking. :)
[09:32] <BradB> mdz: like CVEs
[09:33] <dilys> New Malone bug #70: "several exploitable buffer overflows", submitted by Martin Pitt 
[09:33] <dilys> https://launchpad.ubuntu.com/malone/bugs/70
[09:33] (mdz/#launchpad) BradB: what we're describing is the bit of information which says "I investigated the vulnerability referred to by this CVE name, and it doesn't apply to source package versions x, y and z"
[09:33] (mdz/#launchpad) BradB: I guess that's a separate bug, with its own CVE reference, and affected version informatino
[09:33] (mdz/#launchpad) information
[09:34] <pitti> just submitted a#70
[09:35] <pitti> s/a//
[09:35] <BradB> hm, you'd have to clarify the semantics of CVEs with sabdfl. he's in the midst of doing some data-model-fu with it, so he'd be more familiar with how that's intended to work.
[09:35] <pitti> and triggered another exception when searching for bugs :-(
[09:36] <sabdfl> pitti: i'm just splitting out the cve stuff from other references
[09:36] <sabdfl> i think we could easily build in an CVE-unaffected list
[09:36] <sabdfl> so malone could track who is affected *and* who is not affected
[09:36] <pitti> argh
[09:36] <pitti> https://launchpad.ubuntu.com/malone/bugs/createdby?owner=martin
[09:37] <pitti>  Error type: exceptions.ValueError
[09:37] <pitti> ValueError: invalid literal for int(): createdby
[09:37] <BradB> pitti: that screen's getting crufty and going away soonish
[09:37] <pitti> I cannot search for ubuntu bugs neither
[09:37] <BradB> pitti: by adding another search widget to the main bug listing, so everything's in front of you at once.
[09:37] <BradB> pitti: they're all ubuntu bugs :)
[09:38] <BradB> but yeah, i think i know what you mean, and hm, i'm not sure if there's a way to do that easily yet
[09:38] <pitti> BradB: is there a reason why #70 appears in the list twice?
[09:39] <pitti> https://launchpad.ubuntu.com/malone/bugs/+index?batch_start=40&batch_end=50 has two entries for #70
[09:39] <BradB> pitti: each row you're seeing is an assignment to a package or a product.
[09:40] <BradB> pitti: in that case, you should have only filed the bug against the package, not the "ubuntu" product
[09:41] <pitti> BradB: ah; bugzilla requires to specify both, that's why I did that
[09:41] <BradB> pitti: currently, it's implicit that a package belongs to ubuntu
[09:41] <BradB> pitti: we'll need to improve this UI though, of course, but for now that's how it works.
[09:42] <BradB> pitti: you can "Reject" the assignment to ubuntu to clean things up, if you want
[09:43] <pitti> BradB: I clicked on source package infestation; however, cyrus21-imapd does not exist :-(
[09:44] <pitti> BradB: rejected
[09:45] <pitti> BradB: nice, "Martin Pitt" appears twice in the Assignee list
[09:47] <pitti> darn, it rejects assigning to BinaryPackageValue cyrus21-imapd (although I selected it from the list)
[09:51] <BradB> pitti: can you file a bug if there are releases missing that prevent you from filing the appropriate infestation?
[09:52] <pitti> BradB: in fact I only see one release
[09:52] <BradB> pitti: also for the duplicate assignee thing
[09:52] <pitti> BradB: 2.1.16-10
[09:52] <pitti> BradB: but the warty, warty-security and the latest Hoary releases are missing
[09:52] <BradB> pitti: and the binarypackagevalue thing
[09:52] <pitti> okay
[09:52] <BradB> thanks
[09:56] <pitti> BradB: product malone and no source package?
[09:57] <pitti> "canonical malone", that is?
[09:57] <pitti> btw, the product selection could be a bit easier
[09:57] <BradB> just the product malone, and yes, i'm working on improve the selects (though waiting on getting Z3 upgraded before continuing)
[09:58] <dilys> New Malone bug #71: "available source versions missing", submitted by Martin Pitt 
[09:58] <dilys> https://launchpad.ubuntu.com/malone/bugs/71
[09:59] <pitti> ^^ is this automated somehow?
[10:00] <BradB> yes, somehow :)
[10:10] <dilys> New Malone bug #72: "cannot assign #70 to cyrus21-imapd", submitted by Martin Pitt 
[10:10] <dilys> https://launchpad.ubuntu.com/malone/bugs/72
[10:10] <pitti> yay
[10:13] <dilys> New Malone bug #73: ""Martin Pitt" is in the assignee list twice", submitted by Martin Pitt 
[10:13] <dilys> https://launchpad.ubuntu.com/malone/bugs/73
[10:14] <pitti> new Pitti bug #1: "Martin Pitt submits too many bug reports", submitted by the caretaker
[10:21] <BradB> gargh i wish bug assignments had one main table, with only the columns that differ per assignment type stored in the child tables. batching assignment results is exceedingly complicated.
[10:22] <BradB> which means that batching any kind of aggregate results set like assignments is going to be exceedingly complicated.
[10:22] <bob2> pants!
[11:37] <SteveA> sabdfl, BradB|lunch: still here
[11:37] <sabdfl> hey SteveA
[11:38] <sabdfl> we had a long dig for a problem with interface permissions
[11:38] <sabdfl> bradb finally asked if we were oading the zcml
[11:38] <sabdfl> which we weren't :-)
[11:38] <sabdfl> problem solved
[11:38] <SteveA> holger and armin wanted to pay their "rent" for staying at my and aiste's place during the pypy sprint, so we and the rest of the pypy folks just went out for dinner.
[11:39] <SteveA> hmm
[11:39] <SteveA> was this in a script?
[11:39] <SteveA> oh, you mean you didn't include the zcml from another zcml file?
[11:40] <SteveA> I really need to improve the "forbidden" page.  I know how to make it give decent disgnostics.  Sorry I didnt get round to it so far -- could have saved you some time.
[11:41] <SteveA> I'd like to chat about this in london -- see if I can see what error you were getting, and what it would have been good to show you.
[11:41] <SteveA> daf: don't use zope.View
[11:42] <SteveA> the only permissions we should be using at the moment are zope.Public and launchpad.AnyPerson
[11:42] <SteveA> (I keep trying to get zope.Public changed to just "public", but Jim doesn't agree with me on that one_
[11:44] <daf> SteveA: I'm not, I just noticed that sabdfl was
[11:44] <sabdfl> since it's late and i'm highly medicated for this flu...
[11:44] <SteveA> sabdfl: don't use zope.View.  Use only zope.Public and launchpad.AnyPerson.
[11:44] <sabdfl> daf, is that lp:url code still alive somewhere?
[11:44] <sabdfl> stevea: got you, will update my zcml
[11:44] <SteveA> cool
[11:44] <SteveA> what does lp:url do?
[11:45] <daf> I don't know
[11:45] <SteveA> what would you like lp:url to do?
[11:46] <SteveA> sabdfl: not good about the flu.  Want me to bring some russian vodka with me?  it's one of the local cures, I think
[11:47] <sabdfl> global cures ;-)
[11:47] <sabdfl> da! spasibo!
[11:47] <sabdfl> i'm thinking of cross-referencing the lp:url list from daf with the pagetests to get a report of pages we don't test
[11:48] <sabdfl> madness?
[11:49] <SteveA> when I saw lp:url, I was thinking of a TALES extension
[11:49] <SteveA> getting a report of untested pages would be cool.  a bit like a code coverage report
[11:50] <SteveA> oh, I see, lp:url in zcml files
[11:50] <SteveA> I'd forgotten about that, for some reason
[11:50] <BradB> if it printed out the titles of the pages that weren't being tested that would be like AI...
[11:50] <SteveA> AI ?
[11:51] <BradB> Artificial Intelligence!
[11:51] <BradB> Things you're not testing:
[11:51] <SteveA> we might be better off loading the zcml, and looking for page directives
[11:51] <BradB>   - Bug Listing
[11:51] <BradB>   - Product Search Page
[11:51] <BradB>   - etc...
[11:51] <SteveA> like, the "foo.html" page for an IBug
[11:53] <BradB> SteveA: you remember how i vouched for having parent/child tables in London? i.e. one "parent" table that holds all the common columns, and then child tables for each thing that has to store something slightly specialized.
[11:54] <BradB> SteveA: i can give you one example of a very good reason why.
[11:54] <SteveA> yeah, I'm familiar with the pattern
[11:54] <BradB> here's why we we're hurting without it in launchpad:
[11:54] <BradB> bug listing => batching results
[11:54] <BradB> bug listings are a list of assignments
[11:55] <BradB> there are two kinds of assignments: product and package
[11:55] <BradB> each has their own table
[11:55] <BradB> so, we need a special batching class that knows how to batch *two* different result sets into one thing
[11:55] <BradB> so, imagine:
[11:55] <SteveA> daf: ping
[11:56] <BradB> packages is a SelectResults containing 3000 packages, products is the same, but for products
[11:56] <BradB> assignments *must* be aggregated and order by bug id
[11:56] <daf> SteveA: pong
[11:56] <BradB> so, the user wants to see results 100-120....how in the /heck/ do you return that? :)
[11:57] <SteveA> daf: I want to make a change to rosetta/configure.zcml, but I'm not sure if it is right.  Also, I want you to look at mark's XXX comment in there, and see if it is still pertinent.
[11:57] <BradB> s,return that,batch that,
[11:57] <SteveA> BradB: sorry, can't pay attention just now, as I'm working on the zope3 upgrading
[11:57] <SteveA> can you email it?
[11:57] <SteveA> maybe to the whole list?
[11:57] <sabdfl> BradB: that's why my report separated these thiings out
[11:57] <daf> SteveA: I'm not sure if that comment is still extant
[11:58] <SteveA> if it is not pertinent, please remove it
[11:58] <SteveA> there is always kudos available for removing XXX comments
[11:58] <SteveA> I want an XXX report to run on checkins
[11:59] <BradB> sabdfl: one sec, i'll tell you why that's no good either, but i'm on the phone :)
[11:59] <SteveA> or maybe a daily run, sending results to the mailing list, along with "blame" for the XXXes
[11:59] <SteveA> we should not really have XXXs in production code.
[12:00] <sabdfl> ok