[03:11] <kiko> heya spiveroo
[03:15] <spiv> kiko: Hello!
[03:48] <kiko> time to run home
[03:48] <kiko> laters!
[10:18] <sabdfl> morning everyone
[11:02] <Kinnison> Morning
[11:17] <salgado> lifeless, around?
[11:20] <lifeless> yah
[11:20] <sabdfl> carlos: around?
[11:22] <salgado> lifeless, I'm still not able to register my archive. ('Failed to verify signature'). any idea why?
[11:25] <lifeless> nope
[11:26] <lifeless> pub  2048R/A5FBC4EB 2004-11-23 Guilherme Luis R. Salgado <salgado@async.com.br>
[11:26] <lifeless> sub  2048R/920ED5CA 2004-11-23
[11:26] <lifeless> thats you right ?
[11:28] <salgado> lifeless, this key is somewhat "broken". this is not the one I sent to you by mail, is it?
[11:30] <salgado> lifeless, the right one is this: pub  1024D/9C75C4A6 2004-11-23 Guilherme Luis R. Salgado <salgado@async.com.br> / sub  1024g/2EB270F0 2004-11-23
[11:36] <bob2> erm, LP crashes if you enter a project name that has spaces in it
[11:37] <bob2> erm, fuck
[11:41] <lifeless> salgado: garh. it *needs* to be in the keyservers.
[11:41] <lifeless> and the one you emailed me matched tghe fingerprint for that one, so yes, it was the one you sent me.
[11:44] <salgado> lifeless, sorry for sending you the wrong key. is it possible to register the 1024 bits key?
[11:45] <lifeless> salgado: send me another email
[11:45] <lifeless> and I'll do it.
[11:47] <sabdfl> do we have a SELECT DISTINCT capability in SQLobject?
[11:48] <salgado> lifeless, just sent. thanks again.
[11:56] <stub> lifeless: I appear to be blocked on this PQM thing. If I send debug, I don't get the actual output from the test runner. If I don't send debug, I only get the last 20 lines (which seems to be fairly pointless - I'm always interested in the first failures, not the fallout)
[11:56] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: use baz by default in rocketsync (patch-896)
[11:57] <lifeless> stub - you can check out rocketfuel on chinstrap, and run ./test.py yourself, can't you ?
[11:57] <stub> lifeless: Doh! Now I get an email with all the right stuff in it.
[12:05] <stub> Ahh dammit....
[12:06] <stub> elmo: ping
[12:10] <dilys> New Malone bug #101: "test_on_merge.py needs DB sanity checking", submitted by Stuart Bishop
[12:10] <dilys> https://dogfood.ubuntu.com/malone/bugs/101
[12:11] <stub> lifeless: It would be problematic, as I can't create databases
[12:12] <stub> Anyway - I think I found the problem - just need a line added to postgresql.conf and a reload
[12:29] <sabdfl> hey carlos
[12:29] <carlos> morning
[12:42] <Kinnison> Hmm, I may have to tune workrave to a shorter timespan. a weekend with my laptop and my wrists are a bit achey again
[12:50] <elmo> stub: ?
[12:51] <sabdfl> is anyone else seeing oddness in their functional tests this morning?
[12:51] <Kinnison> I don't think I was
[12:51] <stub> elmo: I emailed you a request just now. I need a line added to postgresql.conf on chinstrap and mawson, and a pg_ctl reload done
[12:52] <stub> elmo: I've got merges I can't merge, and I only just realized why ;)
[12:52] <Kinnison> The allowed-tags file appears to be out of date
[12:55] <sabdfl> i've patched the allowed-tags file in my archive
[12:55] <sabdfl> will commit as soon as i understand what i've broken in the rosetta test suite
[12:55] <Kinnison> make check runs for me okay
[12:56] <Kinnison> I merged today at about 10am
[12:56] <sabdfl> Kinnison: are you fully refueled?
[12:56] <carlos> sabdfl: which error are you getting?
[12:56] <sabdfl> carlos: an error on test_poexport
[12:56] <Kinnison> sabdfl: As I said, I merged this morning
[12:56] <carlos> hmmm
[12:56] <carlos> sabdfl: hmm, I thought it was fixed...
[12:57] <sabdfl> i don't think the error is there
[12:57] <carlos> sabdfl: We had a problem with it because it said the connection was already closed
[12:57] <carlos> is it?
[12:57] <sabdfl> i think some previous error affects the state of the db
[12:57] <sabdfl> yes, exactly
[12:57] <carlos> sabdfl: stub was looking at it
[12:57] <sabdfl> so some previous error affects the state of the db, then the later test fails
[12:57] <carlos> and the tests worked here
[12:57] <carlos> I thought It was fixed
[12:57] <sabdfl> could it be a clauseTables issue?
[12:57] <carlos> and that's why I reenabled it...
[12:58] <carlos> hmmmm
[12:58] <carlos> could be, let me reenable the check
[12:58] <carlos> and will tell you
[12:58] <dilys> Malone bug #101 fixed for product The Launchpad: test_on_merge.py needs DB sanity checking
[12:58] <dilys> https://dogfood.ubuntu.com/malone/bugs/101
[12:58] <sabdfl> well it must have passed on the main server because it got into the main archive
[12:58] <elmo> is it safe to restart postgres randomly on mawson?
[12:58] <stub> carlos: I haven't looked at that yet sorry.
[12:59] <carlos> stub: I thought you did...
[12:59] <carlos> sabdfl: then, that's the problem
[12:59] <kiko> morning
[12:59] <carlos> sabdfl: just rename it to disabled_foo
[12:59] <carlos> sabdfl: just rename it to disabled_poexport.py
[12:59] <carlos> I will take care of it as soon as it's fixed
[12:59] <stub> elmo: Hmm... doubtful. I can handle the librarian and launchpad instance - if there is other stuff, it can wait (although I can't update the launchpad dogfood server until it is done)
[01:00] <elmo> Kinnison: is running something - I don't know if it's using the DB
[01:00] <elmo> s/://
[01:01] <Kinnison> She'll be about another 10-15 mins if you can wait that long
[01:01] <Kinnison> Otherwise I can restart her afterwards
[01:01] <sabdfl> carlos: ok
[01:02] <dilys> New Malone bug #102: "Fix test_poexport.py", submitted by Stuart Bishop
[01:02] <dilys> https://dogfood.ubuntu.com/malone/bugs/102
[01:02] <Kinnison> elmo: should I stop her or can you wait to restart pg?
[01:04] <carlos> stub: yes, that's a better way to remember it
[01:04] <elmo> stub: I'm not fussed
[01:04] <carlos> :-)
[01:05] <stub> elmo: Bounce it when Kinnison says gina is done please, and chinstrap now if it hasn't already
[01:06] <sabdfl> carlos: it's not a clauseTables problem, the test still fails if I set add-missing_from=true
[01:07] <carlos> hmm, it passed here on Saturday
[01:07] <carlos> and it worked also in chinstrap :-P
[01:07] <carlos> and it worked also in chinstrap 
[01:08] <elmo> I did chinstrap already
[01:09] <Kinnison> gina is onto amd64 publishing
[01:09] <Kinnison> won't be long now
[01:11] <Kinnison> elmo: okay; she's done
[01:11] <sabdfl> Kinnison: let's have a quick run down of gina / soyuz / lucille
[01:11] <sabdfl> is the upload piece working? elmo?
[01:12] <elmo> stub: done
[01:12] <sabdfl> can people upload a package without a chinstrap account, and is that funcionality part of lucille?
[01:12] <Kinnison> sabdfl: well I spent last week really hammering on gina
[01:12] <elmo> sabdfl: it's working for katie
[01:12] <Kinnison> people can upload using the new uploader for katie. That code is in lucille ready for us to use with soyuz
[01:12] <sabdfl> elmo: ok, so there's an upload queue for hoary, people just need a key in the keyring?
[01:13] <sabdfl> cool
[01:13] <sabdfl> check
[01:13] <elmo> sabdfl: yes
[01:13] <sabdfl> check
[01:13] <Kinnison> Gina now imports main/restricted across all three archs properly including sharing arch:all packages properly and various other fixes
[01:13] <Kinnison> you've seen the pqm merges
[01:13] <Kinnison> I have a couple of small tweaks which I completed this morning and gina has just finished an updating import of hoary on mawson
[01:13] <carlos> sabdfl: the tests are working here
[01:14] <carlos> sabdfl: do you have a new test in your local tree?
[01:14] <carlos> sabdfl: what are you using to run the tests?
[01:14] <sabdfl> Kinnison: super, so when we bring gina up on the production server, we will have instant view on the hoary archive?
[01:14] <sabdfl> carlos: make check
[01:14] <sabdfl> carlos: i might have broken something
[01:15] <sabdfl> i've been rewiring bits of rosetta to bring it more into line with the rest of the Launchpad
[01:15] <Kinnison> sabdfl: Yes. The first import won't be perfect by a long stretch. But as time goes on; it will get better as it gets more ready
[01:15] <sabdfl> also, to use Project instead of RosettaProject etc
[01:15] <carlos> sabdfl: then, don't remove the test, it seems to be working now
[01:15] <sabdfl> Kinnison: does it import the packages themselves perfectly?
[01:15] <carlos> stub: any idea about why it's working now? :-)
[01:15] <sabdfl> i don't mind if there are publishing glitches, because we nuke those tables anyhow
[01:16] <Kinnison> sabdfl: Everything it can match up properly to the constraints in the db is imported perfectly
[01:16] <sabdfl> so what's an example of something that would not import well?
[01:16] <Kinnison> a binary which is hanging around without a source package due to a new upload which hasn't built yet would be one thing
[01:16] <stub> carlos: nope
[01:16] <Kinnison> Or a binary where gina can't work out what the source version should be
[01:16] <sabdfl> carlos: i've already committed the changes, with the disabled test
[01:17] <carlos> sabdfl: ok, will merge as soon as reach rocketfuel
[01:17] <sabdfl> carlos: please could you refuel when dilys announces the merge, and see if you can reproduce the problem
[01:17] <carlos> and execute the tests
[01:17] <carlos> yep
[01:17] <sabdfl> i'll buy you a tall cold beer in Mataro if it's my bug :-)
[01:18] <ddaa> lifeless: I'm considering adding a Archive.version property. I'm not sure whether it should just give the version string, or whether it should parse it and return an ArchiveVersion object with properties .type and .number properties. The .type property would be "baz" or "hackerlab" and the .number property would be... the version number...
[01:18] <sabdfl> is there any way to get the test harnes to print output from each test as it executes them?
[01:18] <ddaa> and probably a __str__ method too, to give the actual version string.
[01:18] <sabdfl> because I get a couple of DB-type errors, which don't result in test failures so i don't see which tests caused them
[01:19] <lifeless> sabdfl .test.py --verbose
[01:19] <lifeless> ddaa: too complex, we'll be splitting pybaz off shortly anyway. so keep it /real simple.
[01:19] <ddaa> ack
[01:20] <ddaa> then Archive.version_string
[01:20] <ddaa> will leave .version free for something smarter.
[01:21] <sabdfl> lifeless: that gives me dots. i'd like to see the actual test name, so when i see exceptions i know where they were generated
[01:21] <sabdfl> Running FUNCTIONAL tests at level 1
[01:21] <sabdfl> Running FUNCTIONAL tests from /home/mark/projects/ubuntu/launchpad/lib
[01:21] <sabdfl> Parsing ftesting.zcml
[01:21] <sabdfl> ..................../home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/webapp/authorization.py:30: UserWarning: zope.Public being used raw on object <zope.app.pagetemplate.simpleviewclass.SimpleViewClass from /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/templates/launchpad-editform.pt object at 0x413b192c>
[01:21] <sabdfl>   warnings.warn('zope.Public being used raw on object %r' % object)
[01:21] <sabdfl> /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/webapp/authorization.py:30: UserWarning: zope.Public being used raw on object <zope.app.pagetemplate.simpleviewclass.SimpleViewClass from /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/templates/launchpad-editform.pt object at 0x41e1682c>
[01:22] <sabdfl>   warnings.warn('zope.Public being used raw on object %r' % object)
[01:22] <sabdfl> ...Exception psycopg.InterfaceError: 'already closed' in <bound method Transaction.__del__ of <sqlobject.dbconnection.Transaction object at 0x41e1692c>> ignored
[01:22] <sabdfl> ................Exception psycopg.InterfaceError: 'already closed' in <bound method Transaction.__del__ of <sqlobject.dbconnection.Transaction object at 0x41f46bac>> ignored
[01:22] <sabdfl> ...........................
[01:22] <lifeless> oh, try --debug
[01:22] <Kinnison> sabdfl: -vv may help too
[01:23] <sabdfl> -vv is the trick! THANKS Kinnison
[01:24] <Kinnison> y'welcome
[01:26] <sabdfl> ok, i think this is where things are going awry:
[01:26] <sabdfl> test_tearDownDatabase (canonical.launchpad.ftests.test_pages.EndStory) ... ok
[01:26] <sabdfl> test_simple_sendmail (canonical.launchpad.mail.ftests.test_stub) ... ok
[01:26] <sabdfl> testPoExportAdapter (canonical.rosetta.ftests.test_poexport.POExportTestCase) ...
[01:26] <sabdfl> Error in test testPoExportAdapter (canonical.rosetta.ftests.test_poexport.POExportTestCase)
[01:27] <sabdfl> seems like the pagetest stories each setup and teardown the db
[01:27] <sabdfl> then the rosetta test_poexport tries to access the db
[01:28] <stub> The launchpad_ftest database should be created by tests that use it - if tests assume it is there, they only work by accident (if at all)
[01:35] <carlos> the rosetta test_poexport should recreate the database before use it
[01:35] <carlos> when I was looking at it
[01:35] <carlos> it failed because the database was being used so it was not able to recreate it
[01:35] <sabdfl> there seem to be a bunch of "already closed" errors during the tests
[01:35] <sabdfl> in most cases these are just "ignore"
[01:35] <sabdfl> d
[01:36] <carlos> sabdfl: spiv said it's not a problem
[01:36] <sabdfl> but in the poexport case it cases the test suite to fail and halt
[01:37] <carlos> sabdfl: if you run that test directly, it works
[01:37] <carlos> sabdfl: the problem comes when it's executed with more tests
[01:37] <sabdfl> how do i run a test dirctly?
[01:37] <carlos> execute it from launchpad
[01:37] <carlos> ./lib/canonical/rosetta/ftests/test_poexport.py
[01:37] <carlos> hmm
[01:37] <carlos> add python 
[01:37] <carlos> python ./lib/canonical/rosetta/ftests/test_poexport.py
[01:38] <carlos> that should do it
[01:39] <sabdfl> Traceback (most recent call last):
[01:39] <sabdfl>   File "./canonical/rosetta/ftests/disabled_test_poimport.py", line 6, in ?
[01:39] <sabdfl>     from canonical.launchpad.ftests.harness import LaunchpadFunctionalTestCase
[01:39] <sabdfl> ImportError: No module named canonical.launchpad.ftests.harness
[01:39] <sabdfl> carlos: that's what i see
[01:39] <sabdfl> although canonical/launchpad/ftests/harness.py does exist
[01:39] <carlos> sabdfl: you need to export your PYTHONPATH
[01:40] <carlos> PYTHONPATH=your_launchpad_path/lib/ python ./lib/canonical/rosetta/ftests/test_poexport.py
[01:40] <sabdfl> ah
[01:40] <sabdfl> nope, fails here
[01:41] <carlos> which error?
[01:41] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: substantial rosetta navigation cleanups banishing RosettaProject (patch-897)
[01:41] <sabdfl> erm, sorry, that was test_poimport
[01:41] <sabdfl> will check poexport now
[01:42] <sabdfl> ok, it passes
[01:42] <carlos> yeah, the import is broken
[01:42] <sabdfl> also has the connection closed errror, but it's ignored
[02:02] <carlos> sabdfl: I don't have any problem with it 
[02:02] <carlos> sabdfl: could you execute ./test_on_merge.py canonical  from launchpad top directory?
[02:02] <carlos> I think it's a problem with make check (not sure why)
[02:18] <lifeless> salgado: done
[02:18] <salgado> lifeless, thanks!
[02:18] <lifeless> you should issue a revoke certificate for the other key if its stuffed
[02:20] <kiko> lifeless, it's not exactly stuffed, but it won't be shared properly by non-subkey-supporting keyservers, which makes it impractical..
[02:20] <kiko> is this the case of keeping an extra key or revoking it?
[02:20] <salgado> lifeless, that key is ok, the only problem is that because it's a 2048 bits RSA key, I need one key for signing and other for crypting, and some keyservers don't support it
[02:26] <lifeless> kiko: subkeys.pgp.net. just use that.
[02:31] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix a broken query in PeopleSearchView and adding foaf page tests (patch-898)
[02:33] <sabdfl> spiv: so is there any way to get a select distinct result?
[02:42] <spiv> sabdfl: Not directly with SQLObject at the moment.  You could do SQLBase.connection.queryAll("SELECT DISTINCT etc etc") directly, I guess.
[02:44] <sabdfl> spiv: didn't we sort this out at oxford?
[02:45] <spiv> I had an experimental patch at oxford, but iirc it's still sitting in a branch unmerged.
[02:47] <spiv> Yeah, not merged yet.  The problem with the oxford patch is it solves one, fairly narrow, use-case for DISTINCT, but doesn't help other situations.
[02:49] <sabdfl> as i recall, it would at least result in distinct objects from a single table, but only in the sense that you only got a given row once, not in the sense that you could limit the results set to only one row with a given set of values in a specific set of fields
[02:49] <spiv> (i.e. it effectively only does SELECT DISTINCT *, but you often want to be able to DISTINCT only a subset of a table's columns)
[02:49] <sabdfl> right
[02:49] <sabdfl> well that would be a useful piece of functionality for me right now
[02:50] <sabdfl> can we merge that patch to our branch, and push it upstream?
[02:50] <spiv> Ok.  It's probably worth merging then, and -- yeah :)
[02:50] <sabdfl> Table.select(query, clauseTables=ct, distinct=True)?
[02:52] <spiv> Yep.
[02:52] <spiv> The branch is andrew.bennetts@canonical.com/sqlobject--distinct-feature--0.5.1
[02:52] <spiv> I wonder if that still merges cleanly...
[02:53] <lifeless> spiv: IIRC I opened that branch for merges, following stubs request, so you can:
[02:53] <lifeless> tag from 0.6, merge in your 0.5.1 and tid up if needed, then send a merge requeest.
[02:53] <spiv> lifeless: Oh, sweet.  Thanks :)
[02:58] <spiv> Blah, there are some conflicts.
[03:09] <stub> Ooh... I thought that didn't happen for some reason I can't now remember :-)
[03:14] <spiv> Looks like the conflicts are largely harmless... I'll merge it tomorrow morning when I'm less sleepy.
[03:19] <BradB> morning
[03:19] <BradB> welcome back spiv!
[03:21] <spiv> BradB: Thanks :)
[03:21] <spiv> And g'night!
[03:21] <BradB> heh, later :)
[03:29] <sabdfl> carlos: i'm busily renaming englishName to enlishname for consistency everywhere
[03:29] <sabdfl> same for nativeName, pluralForms and pluralExpression
[03:29] <sabdfl> we're keeping fielnames alllowercase
[03:29] <sabdfl> fieldnames
[03:29] <carlos> sabdfl: yeah, I was fixing some of those sometime ago
[03:30] <carlos> that's from pre-Oxford
[03:30] <carlos> before you asked us to move to lowercase
[03:30] <carlos> the new additions have been all lowercase
[03:32] <kiko> lifeless, yeah, I know -- it's just, as I said, a bit inconvenient.
[04:03] <carlos> daf: morning
[04:18] <Kinnison> wot no dilys ?
[04:18] <Kinnison> cprov: I'll look at those tests later if you want
[04:29] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix db code for new layout. (patch-901)
[04:29] <dilys> Merge to rocketfuel@canonical.com/pyarch--devel--0.5: Archive.version_string (patch-54)
[04:29] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Gina changes for partial publishing and associated bits (patch-900)
[04:30] <cprov> Kinnison: of course I want, I'll appreciate your help on it .BTW, You can delegate new tasks to me ...
[04:30] <Kinnison> cprov: Right; let me ponder for a moment on what would be best for you to tackle next
[04:31] <cprov> Kinnison: ok, I'm spending time revising Soyuz Permission 
[04:31] <Kinnison> Okay; let me know when you're done with that since I know it's important to the webapp team. Then we'll talk a bit about the domination and superceding processes and how they need to change.
[04:31] <cprov> Kinnison: as you could see dilys doesn't like me :)
[04:32] <kiko> hey cprov 
[04:32] <kiko> no luck with the network, eh?
[04:32] <Kinnison> cprov: dilys is a picky girl
[04:32] <cprov> kiko: not yet, any news about your friends from CONSAVE ?
[04:32] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Unittests for Librarian Wrapper (patch-899)
[04:33] <Kinnison> cprov: perhaps she was simply saving the best for last?
[04:33] <kiko> cprov, no, actually, I didn't ask them. what do you want from them, support, or just tips?
[04:34] <cprov> Kinnison: ohh... it would be nice if it was true at all 
[04:34] <cprov> kiko: tips about equipments, prices, usage and suplliers would be nice
[04:36] <bob2> is the 'arch target' block on the rcs signup page supposed to work?
[04:38] <kiko> hmmm
[04:43] <Kinnison> how do I run just the functional tests?
[04:46] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: fix regression in baz tag. Bad bobo. (patch-66)
[04:48] <BradB> Kinnison: I usually run them with python test.py -vvf.
[04:48] <Kinnison> BradB: ta
[04:49] <BradB> kiko, cprov: Has your sane diff output patch landed?
[04:50] <BradB> It seems like the diff output has changed, and in the process become much harder than it already was to work with.
[04:51] <kiko> BradB, not on the python-dev side, tim's ignoring me
[04:51] <BradB> kiko: I don't think waiting for python-dev is a good idea. ;)
[04:51] <kiko> I'm not suggesting it is, but I'd like an opinion on how to fix the design of the patch
[04:52] <sabdfl> BradB: CA mindset?
[04:52] <BradB> kiko: Can you guys get something working today? This is going to cost me a lot (more) time today, in its absense.
[04:52] <BradB> sabdfl: CA == Component Architecture.
[04:53] <BradB> sabdfl: One of the major reasons for the complete rewrite of Z3 was to make it possible to use "normal" Python code in Z3, instead of having classes that inherit from all kinds of things from the framework itself.
[04:54] <BradB> sabdfl: So the idea now is, a content class is *just* a content class. Almost everything is done with adapters, so that you can extend the behaviour of the content class without actually altering the class itself (that's the whole thing about "making diverse pieces of software work together in interesting ways" thing that Steve often says about Zope3. :)
[04:58] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: languages portlet (patch-902)
[05:02] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: *really* fix db code for new layout. (patch-903)
[05:05] <BradB> lulu: What do you mean that howto's are showing the main nav section? I don't see them there.
[05:05] <kiko> BradB, dude, I have no idea what's wrong, can you launchpad-mail it
[05:06] <BradB> kiko: Has your patch landed then? I'm still not clear on whether what I'm looking it is the result of your patch or not. :)
[05:07] <kiko> it's not my patch, it's cprov's, and I suspect no :)
[05:07] <BradB> Oh, well there's no point on me remailing it then, since cprov, SteveA and I already went through what the problems were.
[05:08] <BradB> I just want something that works though. :) As long as the licensing isn't problematic, doing what we've done elsewhere (e.g. with batching) by simply checking the modified difflib into LP would be a useful step forward.
[05:09] <BradB> As long as sabdfl and SteveA agree that that's sane.
[05:14] <lulu> BradB:same probelm as before - in the nav section of the Documentation (Plone Help Centre)
[05:15] <BradB> Which docs?
[05:21] <lulu> BradB: in edit mode - https://www.ubuntulinux.org/support/documentation/howto/howtofolder_view...........
[05:21] <lulu> BradB: check FAQs to see the difference (and how it should be) - the FAQs don't show up in the nav bar - https://www.ubuntulinux.org/support/documentation/faq/faqfolder_view
[05:24] <BradB> lulu: Can you give me an example of a specific doc you're seeing, that you don't think you should see, and which user you're logged in as?
[05:29] <carlos> elmo: could we solve this?: https://chinstrap.warthogs.hbd.com/archzoom/rocketfuel@canonical.com/launchpad--devel--0--patch-895/lib/canonical/launchpad/zcml/pofile.zcml.diff?diff?debug
[05:35] <cprov> BradB: and kiko-fud: for me should be pretty simple, just decide to keep our own difflib, don't need to fight with python-dev people neither block canonical developers on it 
[05:36] <cprov> at least, avoids fights and blocks just for now ...
[05:38] <BradB> cprov: That's the best way to go, AFAIC.
[05:44] <lulu> BradB: will send over an email with all the info - thanks.
[05:45] <BradB> lulu: ok, thanks
[05:48] <dilys> Merge to rocketfuel@canonical.com/buildbot--devel--0: make the waterfall display show queuing more sensibly. (patch-80)
[06:09] <Kinnison> cprov: ping?
[06:14] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: added functional tests for the bug listing quick searches (patch-904)
[06:15] <cprov> Kinnison: here
[06:15] <Kinnison> cprov: I just wanted to suggest that you learn about the unit test setup/teardown routines you can add
[06:16] <Kinnison> cprov: Otherwise /tmp/archive and /tmp/cache don't get cleaned up properly
[06:16] <Kinnison> cprov: which could irritate people on shared dev platforms trying to run the tests
[06:17] <cprov> Kinnison: sure, can you briefly describe them ? how can I setup and destroy my required ENV ?
[06:17] <Kinnison> Sure
[06:18] <Kinnison> open test_publisher.py
[06:18] <Kinnison> Then check out def setUp(self) and tearDown(self)
[06:18] <Kinnison> setUp() is called before each test....() and tearDown() is called after each one
[06:18] <cprov> ok
[06:18] <Kinnison> it's a good way to ensure each test runs in a completely clean environment
[06:19] <Kinnison> Also; Note how that test makes all its test dirs under the datadir()
[06:19] <Kinnison> it's worthwhile in case of shared dev boxes
[06:19] <cprov> I see ... I'll try something on it 
[06:19] <Kinnison> Okay. Just when you have time. For now it's okay
[06:20] <cprov> Kinnison: should do it now, otherwise I will forget :) in a half hour ...
[06:20] <Kinnison> okay
[06:22] <cprov> Kinnison: setUp() and tearDown() are called automatically ? just define my ones will be enough ?
[06:22] <Kinnison> yep
[06:23] <cprov> Kinnison: ok, doing it
[06:23] <kiko> cprov, it's not a matter of fighting -- the design of the patch could be much improved, just that
[06:33] <BradB> kiko: something that works right now is more valuable to us than an elegant design though :) when the relevant people respond, some housecleaning could possibly be in order, of course, but...
[06:34] <kiko> but nothing, I agree wholeheartedly. if you want to find a place for it to live, be my guest :)
[06:34] <BradB> lib/
[06:34] <kiko> lib/difflib.py?
[06:35] <BradB> er, well, probably though. anything else means modifying more code which won't be quick to modify.
[06:37] <BradB> of course, there's the problem that this would be the first .py directly in lib/, but it would work, in any case.
[06:37] <cprov> kiko: I understand perfectly this, what I don't understand is why it's still blocking people inside canonical, IMO it should be used as it is (private) and keep the discussion about insert int or not in python-dev in a forked process
[06:37] <BradB> cprov: Is it possible for your solution to inherit from a class in difflib? Maybe the changes you're proposing aren't necessarily something that should be in the std difflib (but then, maybe they are; I don't know what mods you made.)
[06:38] <BradB> eh, but even inheriting would mean changing code, so probably not good anyway
[06:39] <BradB> i'm guessing SteveA makes the judgement call here, unless sabdfl jumps in with a JFDI
[06:39] <cprov> BradB: it can be done in that way, we will have a "canonicaldifflib" module somewhere ...
[06:40] <BradB> cprov: Which would mean modifying the Z3 bits that import difflib directly, which is a situation we probably don't want to be in.
[06:42] <cprov> BradB: right
[06:43] <kiko> cprov, BradB: not even inheriting is easy because of the way difflib is put together, unfortunately. it would be a simple mod to difflib, but still.
[06:43] <kiko> can you customize the class easily in Zope?
[06:45] <BradB> It would be a bad idea. We don't want to run a custom-hacked Z3 unless there's an amazingly convincing reason to do so. :)
[06:45] <BradB> i.e. No
[06:45] <cprov> BradB: heh
[07:06] <kiko> meh
[07:06] <kiko> pythonpath hacking?
[07:07] <carlos> how could i get a char's ascii code  in python?
[07:07] <BradB> kiko: Yeah, there's that option too. We still need to have a difflib.py somewhere in our tree though, it looks like. :)
[07:19] <kiko> no argument there
[07:19] <kiko> you can't pythonpath-hack something that isn't on-disk :)
[07:22] <kiko> carlos, chr()?
[07:22] <carlos> kiko: I got it already, thanks
[07:23] <carlos> but with curses. It's only for debug 
[07:24] <kiko> ah.
[07:24] <kiko> carlos, is there a good place to buy stuff mailorder in spain?
[07:24] <kiko> a website?
[07:25] <carlos> kiko: it depends on what do you want
[07:25] <carlos> we don't have anything like amazon
[07:25] <kiko> hardware
[07:26] <carlos> http://informatica.elcorteingles.es
[07:26] <carlos> http://www.fnac.es
[07:26] <carlos> but I think it's better to just go to the stores at Barcelona directly
[07:26] <carlos> both have shops there
[07:27] <kiko> cheap? like the place we got the wrt56g from?
[07:28] <carlos> you have also http://www.tecnologia.carrefour.es/
[07:28] <carlos> kiko: I got the router from my brother's company, he has license to buy/sell hardware
[07:28] <carlos> kiko: usually I ask him anything I need
[07:29] <carlos> but he does not have an online store nor sells to the public
[07:30] <carlos> if you have a concrete need I could ask him like we did with the router
[07:30] <kiko> I see
[07:30] <carlos> but I think it's too late to get it in time for Matar
[07:30] <kiko> I was considering getting a gigbit switch
[07:30] <kiko> 16-port would do
[07:30] <kiko> 110v
[07:30] <kiko> but if it's too late, I can shop for it
[07:31] <Kinnison> What voltage is spain?
[07:31] <carlos> I could ask, will tell you it tomorrow
[07:31] <carlos> 220
[07:31] <kiko> thanks
[07:31] <kiko> what's with the font-size in simply?
[07:31] <carlos> but usually, the power adaptors handle 220 and 110 
[07:32] <carlos> kiko: sorry, I don't understand you
[07:32] <kiko> simply.co.uk
[07:32] <kiko> busted fonts
[07:33] <carlos> kiko: I don't have problems with it
[07:33] <kiko> http://www.simply.co.uk/productinformation/45668/WW/LINKSYSCISCO_24-PORT_10100_+_1-PORT_GIGABIT_SWITCH_+_1_MINIGBIC/index.htm
[07:33] <kiko> http://www.simply.co.uk/productinformation/47225/WW/D-LINK_16-PORT_101001000MBPS_GIGABIT_SWITCH/index.htm
[07:34] <kiko> http://www.simply.co.uk/productinformation/45284/WW/Netgear_24x_10100_Smart_Switch_+_2_Gigabit_Ports/index.htm
[07:34] <kiko> any of those would do
[07:34] <carlos> ok
[07:39] <lulu> night all :o)
[07:47] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: add functional tests to prove that the bug search widgets work, that the vocabs are sane and fix the product search along the way (patch-905)
[07:59] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Bug Fixing on Unittest Librarian Wrapper (patch-906)
[10:02] <dilys> New Malone bug #103: "Write a unit test using unicode with our po parser and make it pass", submitted by Carlos Perell Marn
[10:02] <dilys> https://dogfood.ubuntu.com/malone/bugs/103
[10:14] <daf> BradB: agreed
[10:31] <kiko> BradB, seconded. that needs to be fixed
[10:40] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: slightly improve bug listing row clickability by taking the user directly to the assignment edit screen (patch-907)
[10:47] <dilys> New Malone bug #104: "Move from file objects to strings for the po importer", submitted by Carlos Perell Marn
[10:47] <dilys> https://dogfood.ubuntu.com/malone/bugs/104
[10:50] <BradB> sabdfl: ping
[10:53] <BradB> darn we really need integration with BugActivity too, so that we can present to the user useful info about what changed, when, by whom and with a note attached.
[10:53] <BradB> but i need to confirm with sabdfl!
[11:11] <dilys> New Malone bug #105: "Add the option to upload a po template when we create it", submitted by Carlos Perell Marn
[11:11] <dilys> https://dogfood.ubuntu.com/malone/bugs/105
[11:57] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: add a functional test for the bug id/text search widget (patch-908)
[11:59] <BradB> lifeless: Is this fixed? https://dogfood.ubuntu.com/malone/bugs/82
[12:00] <lifeless> BradB: yes, thats what I fixed saturday