[12:01] <elmo> SteveA: what on earth do you want me to do about this?
[12:01] <cprov> sabdfl: send me an email if you want ... I'll be away for 40 min .. nicole is running on zhongshan
[12:01] <sabdfl> cprov: so nicole is creating productreleases? cool
[12:01] <sabdfl> i'll keep going with my code, then we'll merge later
[12:01] <elmo> I'm not lifeless and I don't have the time, energy or skills to debug it - I can kill it and move your merge request out of the way if you want?
[12:01] <SteveA> elmo: no idea.  can you kill 11951 or 11878 ?
[12:02] <elmo> sure, I can kill 11951
[12:02] <elmo> Process 11951 attached - interrupt to quit
[12:02] <elmo> write(1, "ALTER TABLE\n", 12
[12:02] <elmo> fyi, that's the strace
[12:03] <SteveA> this kind of thing happens when some other process is accessing that database
[12:03] <SteveA> I wish there was a way of telling postgres to fail rather than block in these situations
[12:03] <elmo> killed
[12:04] <SteveA> can you kill 11877 too?
[12:05] <elmo> now make can't notice it's children dieing? :P
[12:07] <elmo> oh, for christ's sake, every child up is hanging on writes to 1
[12:08] <SteveA> thanks for playing the grim reaper
[12:08] <SteveA> I need to leave the office now.  I'll talk to people about this tomorrow, try to get something sane sorted out.
[12:39] <lifeless> Kinnison: turns out that a local test-pserver is actually easy to do
[12:39] <lifeless> a 2 line bash script made executable, and nc, and voila
[12:41] <Kinnison> lifeless: cute
[12:49] <lifeless> jblack: did you or someone end up helping limi out ?
[01:01] <lifeless> how can I get my username from python?
[01:02] <lifeless> is os.getEnv('USER') reliable enough ?
[01:02] <Kinnison> getent stuff?
[01:02] <elmo> os.getlogin() ?
[01:02] <lifeless> elmo: bingo, thanks
[01:03] <lifeless> yay, one automagic pserver passwd file for the test suite
[01:09] <cprov> sabdfl: yes, now nicole is running and creating productreleases.
[01:10] <sabdfl> great work cprov
[01:10] <cprov> sabdfl: btw, I'm just running through main and restricted packages (1009) rather than universe, I think it's enough for test proposes 
[01:11] <Kinnison> flippin 'eck, it's 00:11 again
[01:11] <Kinnison> c'y'all tomorrow
[01:32] <lifeless> more pythno foo - how do I wait say a half second ?
[01:38] <jblack> lifeless: Sorry. Just got home. The neighbor was really sick, so I had to take care of her and her *four* kids all day.
[01:38] <lifeless> ouch
[01:38] <lifeless> no need to be sorry, I just needed to know if Limi was helped or not, theres no mail showing that he was.
[01:38] <jblack> Not by me he hasn't. Didn't know until now he had a problem.
[01:53] <debonzi> why dbschema.PackagePublishingStatus.PROPOSED does not exists anymore?
[01:54] <debonzi> should I replace it for something else?
[02:00] <sabdfl> debonzi: was changed as part of Kinnison's work
[02:01] <sabdfl> best leave it as it is for the moment, and discuss with him tomorrow
[02:02] <debonzi> sabdfl, nice, Ill comment the template to do not break the page for while. Thanks
[02:03] <sabdfl> ok
[02:31] <sabdfl> lifeless: how can i see the diff from a previous revision?
[03:01] <lifeless> sabdfl: in your tree?
[03:01] <lifeless> tla changes --diffs patch-34
[03:02] <sabdfl> lifeless: thanks
[03:02] <lifeless> np
[03:04] <sabdfl> lifeless:
[03:04] <sabdfl> changes: illegal revision name: patch-253
[03:04] <lifeless> sabdfl: oh bah.
[03:04] <lifeless> use this idiom
[03:04] <lifeless> tla changes --diffs $(tla tree-version)--patch-253
[03:05] <lifeless> which is a nonsense, I'll file a bug for that.
[03:25] <lifeless> anyone seen spiv around?
[10:29] <sabdfl> morning all
[11:14] <lifeless> hey
[12:03] <lifeless> ddaa: still got that keyboard huh ?
[12:04] <ddaa> Yes, it's cool. There is a hidden way of quitting gaim too...
[12:04] <ddaa> Curiously, that shit only happen to me in chat clients.
[12:05] <ddaa> lifeless: about buildbot
[12:05] <ddaa> I assume, to have 5 successes a day, I need to run several jobs in parallel
[12:05] <lifeless> yes
[12:05] <ddaa> What's the catch? Use several slaves?
[12:05] <lifeless> one slave.
[12:06] <lifeless> its threaded.
[12:06] <ddaa> Mh. okay...
[12:06] <ddaa> It's probably going to complicate debugging, but for the working cases it's okay.
[12:07] <lifeless> you could do several slaves if you want, but I'd be wary of spending a bunch of time only to find issues. (such as how to allocate the jobs appropriately)
[12:07] <ddaa> Note that my cpu is not too fast (PIII 600MHz) so it's prolly going to be a bottleneck at some point.
[12:07] <lifeless> sure.
[12:08] <lifeless> go for the low hanging fruit during the day :)
[12:08] <ddaa> Yeah. I'd like to postpone the multiple-slave issues as long as I can.
[12:08] <lifeless> set things like xserver off when you go to bed :)
[12:08] <ddaa> ?
[12:08] <lifeless> it would be easier to do parallel buildbots with the same database - dual master + dual slave - for now.
[12:09] <lifeless> well small jobs finish quickly
[12:09] <ddaa> Good idea.
[12:09] <ddaa> I see. I thought you were suggesting to stop X when going to be to release resources :-)
[12:47] <Kinnison> (unless it's public now)
[12:48] <ddaa> lifeless: I knew I was forgetting something at the meeting.
[12:49] <lifeless> Kinnison: cscvs is public, always has been. what we are doing with it though..
[12:49] <ddaa> I wanted to poke you about patchlogs which are permanently missing from rocketfuel versions.
[12:49] <lifeless> ddaa: arh
[12:49] <Kinnison> lifeless: I was under the impression the new stuff still wasn't public
[12:49] <lifeless> Kinnison: the code isn't yet no. I have the ok to release it, in step with our archives.
[12:50] <ddaa> For example the reverted patch from launchpad, or the pre-tag history of soyuz.
[12:50] <lifeless> anyhoo, dod you see the bug ?
[12:50] <lifeless> ddaa: the pre-tag history of soyuz isn't missing, it was merged in when soyuz was merged in.
[12:50] <Kinnison> lifeless: Unlikely unless you pointed it to me
[12:50] <ddaa> it's annoying because it breaks "missing" and probably "replay".
[12:50] <lifeless> ddaa: copy that patch in as a merge, fine by me.
[12:51] <ddaa> Okay. So there is no good reason why there are patchlogs permanently missing?
[12:51] <lifeless> Kinnison: '/foo/bar' became ':local:foo:/bar'
[12:51] <lifeless> ddaa: which ones ?
[12:51] <Kinnison> lifeless: Eww
[12:51] <ddaa> lifeless: wait a min
[12:51] <Kinnison> lifeless: Oopsie :-P
[12:51] <lifeless> :] 
[12:51] <ddaa> rocketfuel@canonical.com/launchpad--devel--0--patch-422
[12:51] <lifeless> it now uses the cvs protocol for local repositories :)
[12:52] <lifeless> ddaa: lifeless> ddaa: copy that patch in as a merge, fine by me.
[12:52] <ddaa> rocketfuel@canonical.com/soyuz--devel--0--base-0..patch-29
[12:52] <lifeless> ddaa: you shouldn't be replaying in that branch anyway, ignore that.
[12:53] <ddaa> Bad answer. Missing is a useful command and replay is significantly faster than update here, where for some reason it always uses the apply-delta algorithm.
[12:54] <lifeless> ddaa: the soyuz branch is not used.
[12:54] <lifeless> its a perfectly good answer because of that.
[12:54] <lifeless> because missing and replay don't look at that branch.
[12:54] <ddaa> It's used by the pqm config.
[12:54] <lifeless> ddaa: eh?
[12:55] <ddaa> tlash dists> cat configs/canonical.com/pqm/development | head -1
[12:55] <ddaa> ./pqm	rocketfuel@canonical.com/soyuz--devel--0
[12:56] <lifeless> ok, thats interesting and all.
[12:56] <lifeless> when I next hack on pqm, I'll update the config.
[12:56] <ddaa> Okay.
[01:16] <sabdfl> lifeless: phwoar, big changes on cscvs i see, how's that coming?
[01:17] <lifeless> very close to having the default branch support finished
[01:17] <lifeless> all the db & parser changes are done, am onto the scanning of tla to recreate what the parser won't tell us.
[01:18] <lifeless> I'm hoping to run my first test-on actual data saturday.
[01:18] <lifeless> the ProjectProductSetup page is idling though - can you please please please push through the unsconded ones there?
[01:21] <sabdfl> lifeless: thought we switched to doing this by email? i'm way behind on email
[01:22] <lifeless> sabdfl: you were going to finish the current page... otherwise I'm just mailing it to you again.
[01:22] <sabdfl> are you using the new project/project creation pages, and the links to setup sourcesource there?
[01:22] <lifeless> but I can copy the current page and mail to you if you like.
[01:22] <lifeless> sabdfl: when they go into launchpad, yes.
[01:22] <sabdfl> i'll work on it in the wiki
[01:23] <lifeless> david is working on the research for this too now, so we'll be putting some volume up I hope.
[01:23] <lifeless> would you like me to have him mail you & me rather than adding to the wiki page ?
[01:23] <sabdfl> hmm.. looks to me like a bunch were added after i thought we switched to email
[01:23] <lifeless> sabdfl: nope.
[01:23] <lifeless> onest injin
[01:24] <sabdfl> lifeless: we have a script which will pull details from freshmeat and sourceforge
[01:24] <sabdfl> celso has been working on that
[01:24] <lifeless> sabdfl: cool. I presume we still need to determine the mapping tho.
[01:25] <lifeless> What I'd love is to get you off the critical path - so I can go 'hey, xyzlib worked in test, goto launchpad, and just do it'
[01:25] <sabdfl> yes, what i'm really saying is that there are going to be about 300 projects / products setup automatically
[01:25] <lifeless> that will help enormously.
[01:25] <sabdfl> we are just running some tests this week and next week, then we can put it into production
[01:25] <lifeless> the gnome ones helped too, as as they go good we can just make them.
[01:27] <sabdfl> hmm... project db methinks should be libdb
[01:27] <lifeless> berkely database is more than a lib
[01:27] <lifeless> the lib is what most folk use is all.
[01:28] <sabdfl> "db" is confusing, what about berkeleydb
[01:28] <lifeless> sure.
[01:28] <sabdfl> i don't mind the product name
[01:28] <sabdfl> is libdb1-compat part of the same project?
[01:28] <lifeless> IIRC no.
[01:29] <lifeless> someone wrote it because they needed it
[01:29] <lifeless> I did check that when doing the page.
[01:29] <sabdfl> if we edit the names in the db, will it break the sync process?
[01:29] <sabdfl> or does the sync remember what it was told to use when it started?
[01:30] <lifeless> once I put the sync gold, the name is set forever, until I go change it
[01:30] <lifeless> the project name can vary wildy, it won't care.
[01:31] <lifeless> spiv: sqlos patch applied
[01:31] <spiv> lifeless: Thanks.
[01:31] <spiv> Hmm, #1922 just struck again.
[01:31] <spiv> 3rd time today.
[01:31] <spiv> (after two days nothing)
[01:31] <sabdfl> and if you change it, does it tag into a new archive/cat-branch-version from the old one?
[01:32] <dilys> Bug 2005 resolved: Cache prevents to use new users without restarting launchpad
[01:32] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2005
[01:32] <lifeless> sabdfl: yes, changing involves a manual tag at the moment, and change the sync in launchpad. after that the sync carries on automatically.
[01:32] <sabdfl> ok
[01:32] <lifeless> that is partly by design, partly optimising for the common case.
[01:33] <lifeless> the design bit is - we don't want these things randomly changing all over the place. so until we have a well articulated policy, that I can put into code, I don't want the code to have that 'feature'.
[01:33] <lifeless> Kinnison: here's an example:
[01:33] <lifeless> ':pserver:anonymous@127.0.0.1:/home/robertc/source/canonical/buildbot/launchpad/sourcecode/cscvs/,,repoCatalog' != ':pserver:anonymous@127.0.0.1:/srv/importdtest/buildbot/launchpad/sourcecode/cscvs/,,repoCatalog'
[01:34] <lifeless> oh, bah.
[01:34] <lifeless> thats just me being brain dead, nm, carry on, etc etc
[01:40] <lifeless> Kinnison: this is it (its still happening...)
[01:40] <lifeless> print CVS.protocol.CVSRoot('/srv/importdtest/botslave/buildbot-jobs/autoconf-HEAD-import.job/autoconf@arch.ubuntu.com/autoconf--MAIN--0/cvs_temp_repo')
[01:40] <lifeless> :local:/srv/importdtest/botslave/buildbot-jobs/autoconf-HEAD-import.job/autoconf@arch.ubuntu.com:/autoconf--MAIN--0/cvs_temp_repo
[01:40] <lifeless> I haven't quite fixed it :[
[01:40] <Kinnison> lifeless: Aah it's not liking the @ inside the path
[01:40] <lifeless> the earlier bug was allowing / in the hostname
[01:40] <Kinnison> lifeless: Dunno how you'll fix that except to disallow / inside users and passwords in the regexp
[01:41] <lifeless> Kinnison: probably break it into ()|() 
[01:41] <Kinnison> possibly
[01:41] <lifeless> I'm not sure that the @ is the problem yet
[01:42] <Kinnison> it smells like it to me
[01:42] <lifeless> ok, now I'm sure.
[01:42] <lifeless> z.username ->
[01:42] <lifeless> /srv/importdtest/botslave/buildbot-jobs/autoconf-HEAD-import.job/autoconf
[01:42] <Kinnison> yeppers
[01:44] <lifeless> thankfully, your test suite is comprehensive enough to catch me being an idiot regression wise :)
[01:45] <lifeless> username can't have / can it ?
[01:45] <Kinnison> I sincerely hope not
[01:45] <lifeless> that fixes it trivially.
[01:46] <lifeless> ^:([^:] +):(?:(?:([^:/] +)(?::([^:/] +))?@)?([^:/] +)(?::(\\d+))?:?)?(/.*)$
[01:46] <lifeless>     method        username   password    hostname     port        path    
[01:46] <Kinnison> yep
[01:47] <lifeless> possibly wrong to put the / in the password bit, but hey, cross that bridge when the bug report lands
[01:47] <Kinnison> aye
[01:47] <lifeless> this should finally allow me to not get booted off the kde anonymous server.
[01:47] <lifeless> so we can do kdelibs as soon as spiv makes me proud
[01:48] <Kinnison> hurrah
[01:48] <lifeless> (fingers crossed etc etc etc)
[01:48] <spiv> lifeless: :)
[01:48] <lifeless> have I mentioned how great it is to have this native facility ? 
[01:50] <lifeless> you might find looking at the current protocol / Protocol / pipes interesting
[01:51] <lifeless> you had a design flaw - using a list of handles isn't sufficient to do cleanups properly.
[01:52] <Kinnison> oh?
[01:52] <sabdfl> lifeless: ok, project is xiph, product is paranoia, productseries is Paranoia-III
[01:52] <lifeless> productseries ?
[01:52] <sabdfl> yes, name for a set of releases
[01:52] <sabdfl> like "head"
[01:52] <lifeless> ah. 
[01:52] <sabdfl> or "2.0"
[01:52] <lifeless> ok, thats not in production yet.
[01:52] <sabdfl> or "Paranoia-III"
[01:52] <sabdfl> lifeless: no, it's last night's work, though the db stuff has been there for a while
[01:53] <lifeless> ok
[01:53] <sabdfl> creating a productrelease will require specifying a series for that release shortly
[01:53] <sabdfl> this allows us to do better magic when we have intermingled releases of, say:
[01:53] <sabdfl> apache 1.3
[01:53] <sabdfl> no, better example would be:
[01:53] <sabdfl> gimp1.3
[01:53] <sabdfl> gimp2.0 and
[01:53] <sabdfl> gimp-cvs
[01:54] <sabdfl> (2.1)
[01:54] <ddaa> lifeless: where do the buildbot bugs live?
[01:54] <sabdfl> create three series, and for each release just tell it which series it belongs to
[01:54] <lifeless> ddaa: bugzilla.canonical.com or bugzilla.warthogs.hbd.com - the original main bugzilla
[01:54] <lifeless> sabdfl: so a series is roughly a branch :)
[01:54] <sabdfl> roughly, yes
[01:54] <ddaa> I was redirected to bugzilla.no-name-yet.com...
[01:54] <lifeless> ddaa: yeah. let me give you a direct url
[01:55] <lifeless> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2005
[01:55] <lifeless> thats in the right system.
[01:55] <lifeless> I think we may need to take out the python tar module, it appears to be slightly crackful.
[01:57] <ddaa> thanks
[01:59] <sabdfl> lifeless: i think keybuk uses that heavily for sourcerer
[01:59] <lifeless> sabdfl: he was saying it had really bad problems
[01:59] <lifeless> which I filed to look into later
[01:59] <sabdfl> k
[01:59] <ddaa> so, the public name of buildbot is Hoover, right?
[02:00] <lifeless> yes
[02:00] <lifeless> out install of buildbot sucks.
[02:00] <lifeless> s/out/our/
[02:00] <lifeless> :)
[02:00] <sabdfl> cprov: around?
[02:03] <lifeless> Kinnison: got a few minutes ?
[02:03] <lifeless> got a change in behaviour from cvs external rlog to the native implementation.
[02:04] <lifeless> https://chinstrap.warthogs.hbd.com/importd/devel-status/libbonobo-HEAD-import.job/events/289/log (if you have time)
[02:06] <cprov> sabdfl: yes
[02:06] <cprov> sabdfl: I'm testing the new dump including productreleases
[02:06] <ddaa> Just to be sure I grok bugzilla right, there are currently 4 bugs for Hoover whose status is anything but "closed"?
[02:06] <lifeless> https://chinstrap.warthogs.hbd.com/importd/devel-status/kdelibs-HEAD-import.job/events/273/log for folk that like to give browsers a hernia
[02:06] <sabdfl> stub: what's the correct way of doing something like this:
[02:06] <sabdfl>  * SELECT pg_catalog.setval('schema_id_seq', pg_catalog.select(SELECT max(id) FROM Schema"), true);
[02:06] <lifeless> ddaa: sounds about right.
[02:07] <sabdfl> cprov: could you point me at that too please? want to see how it looks
[02:07] <elmo> lifeless: is this a hint that I should enforce mod_deflate? :P
[02:07] <sabdfl> cprov: do you use the ProductRelease object from canonical.launchpad.database or a custom Soyuz one?
[02:07] <lifeless> elmo: wink wink nudge nudge
[02:07] <stub> sabdfl: Dunno - what are you trying to do?
[02:08] <lifeless> elmo: I think that would actually make browsers less happy, not more.
[02:08] <sabdfl> i was looking to merge your code now if it's still Soyuz*
[02:08] <stub> Looks like you are trying to reset the primary key sequence to the next highest value?
[02:08] <sabdfl> stub: trying to be able to add rows of sampledata then reset the serial counter to the max current
[02:08] <sabdfl> correct
[02:08] <lifeless> sabdfl: mailed you a high-priority mapping - kdelibs.
[02:08] <cprov> sabdfl: I'm using custom one, since we aren't use SQLO in those scripts
[02:09] <sabdfl> cprov: oh, ok
[02:09] <sabdfl> that's probably fine then
[02:09] <sabdfl> why not use SQLO?
[02:09] <sabdfl> DISTINCT etc?
[02:09] <elmo> lifeless: that's just a big ass file, right?
[02:09] <sabdfl> sane queries etc?
[02:09] <cprov> sabdfl: in zhongshan:/home/cprov/ lp_dump-productreleases-mr.sql
[02:09] <sabdfl> random failures etc?
[02:09] <elmo> lifeless: buildd.d.o has those too and .bz2's them by default - the browser seems to cope okay
[02:09] <sabdfl> right, those reasons.
[02:10] <lifeless> elmo: dynamic, scrolls as you wait
[02:10] <stub> sabdfl: Not sure - I've only used alter sequence which won't let you embed a SELECT in it
[02:11] <sabdfl> stub: no worries, just thought i'd play "throgh crackful queries at the BDBA and see how he handles" today :-)
[02:12] <cprov> sabdfl: yes, many simple feature are harder to do using SQLO, maybe my fault, but using simple "pg" the things shows up faster, same strategy used by elmo and Kinnison 
[02:12] <sabdfl> works for me
[02:12] <stub> sabdfl: select setval('bug_id_seq', (select max(id)+1 from bug));
[02:13] <sabdfl> let's help spiv and bradb by telling them wat tweaks would make sqlo more useful in scripts though
[02:13] <sabdfl> stub: nice, thanks :-)
[02:14] <cprov> sabdfl: ERROR: column "productseries" does not exist SELECT id FROM ProductRelease WHERE productseries = 466 ?
[02:14] <sabdfl> elmo: should i be able to scp off zhongshan using my normal ssh keys?
[02:14] <lifeless> ok, I'm going to crash, started at 7am :|
[02:14] <lifeless> spiv: mail me anything you'd like me to investigate. 
[02:15] <lifeless> ddaa: good luck, please mail me for info etc.
[02:15] <sabdfl> cprov: there's an sql patch which went in today for that
[02:15] <lifeless> I'm seeing RMS speak tomorrow, so will not be around all that much - will be working offline mostly.
[02:15] <sabdfl> it was in the pending queue for a day or two
[02:15] <lifeless> night all.
[02:15] <sabdfl> night robert
[02:15] <ddaa> lifeless: you have hint about the tarfile error?
[02:15] <ddaa> i seem to get that one for everything
[02:15] <lifeless> ddaa: oh.
[02:15] <lifeless> what ones specifically ?
[02:16] <lifeless> if its the X.org ones, its cause that module can't hack the 800MB tarball.
[02:16] <ddaa> so far: zenity, yelp, xrestop
[02:16] <lifeless> (or, that the URL for the tarball is wrong)
[02:16] <lifeless> hmm, dunno offhand. pdb is your friend I think
[02:17] <ddaa> lifeless: what i was planning to ho
[02:17] <lifeless> run the slave with twistd -nf buildbot.tap
[02:17] <lifeless> and throw an import pdb;pdb.set_trace() at the appropriate place.
[02:17] <ddaa> ack, I had put that one into a sticky note a few days ago :-0
[02:17] <lifeless> ok, I'm out... 
[02:17] <lifeless> great.
[02:17] <lifeless> night!
[02:17] <cprov> sabdfl: yep, I see,  we have now productseries... uhmm it crashes my dump entirely
[02:17] <ddaa> sweet dreams
[02:18] <elmo> sabdfl: if you have the .ssh/config set up right, yes
[02:18] <sabdfl> what's the voodoo for that?
[02:18] <elmo> Host *.ubuntu.com
[02:18] <elmo>     ProxyCommand ssh mark@chinstrap.warthogs.hbd.com nc -q0 %h %p
[02:18] <elmo> add that to the other stuff
[02:18] <sabdfl> for the zhongshan host only?
[02:19] <elmo> do it for *.ubuntu.com, then you get the other ubuntu.com hosts for free as we migrate
[02:20] <cprov> sabdfl: anyway, using that I pointed you, you can see productseries 
[02:20] <sabdfl> can I have separate entries for *.ubuntu.com
[02:20] <sabdfl> and zhongshan
[02:20] <sabdfl> ?
[02:21] <sabdfl> cprov: so your code created productseries entries, and productrelease entries?
[02:21] <sabdfl> but didn't know about the new field to tell a productrelease what productseries it is part of?
[02:23] <elmo> sabdfl: err, sure if you want, can't imagine why you'd want to tho?
[02:24] <cprov> sabdfl: yes, I missed the field productseries in table Productrelease, so it is almost unuseful :(, sorry
[02:32] <ddaa> spiv: is there some magic to prevent twistd from decorating the output of the buildbot? The "2004/10/14 14:31 CEST [Broker,client] " prefix breaks the integration of emacs with pdb.
[02:35] <sabdfl> elmo: wow that was exciting
[02:35] <sabdfl> just DOS'd myself with a bad .ssh/config
[02:38] <sabdfl> want to try this at home?
[02:38] <sabdfl> Host zhongshan
[02:38] <sabdfl>         compression yes
[02:38] <sabdfl>         HostName zhongshan.ubuntu.com
[02:38] <sabdfl> Host *.ubuntu.com
[02:38] <sabdfl>         ProxyCommand ssh mark@chinstrap.ubuntu.com nc -q0 %h %p
[02:38] <sabdfl> elmo: was hoping to be able to put the proxycommand in a *.ubuntu.com entry
[02:38] <sabdfl> and then use separate entries to map host to ubuntu.com
[02:40] <cprov> Kinnison: what do I need from librarian to run gina now ?
[02:43] <elmo> sabdfl: turn on tab completion
[02:43] <Kinnison> cprov: You need a running librarian
[02:44] <elmo> then it's just zhon<tab>, rather than zhonghan or zhongshan.ubuntu.com
[02:44] <sabdfl> elmo: still not working, even if I specify things completely
[02:44] <sabdfl> Host *.ubuntu.com
[02:44] <sabdfl>         compression yes
[02:44] <sabdfl>         ProxyCommand ssh mark@chinstrap.ubuntu.com nc -q0 %h %p
[02:44] <elmo> sabdfl: chinstrap.warthogs.hbd.com dude
[02:44] <elmo> sabdfl: yes, I know the half and half things sucks, sorry
[02:44] <limi> sabdfl: 20K entries is what we are expecting for packages, roughly?
[02:45] <cprov> Kinnison: do you have it zhongshan, in a easy way that I can copy?
[02:45] <Kinnison> You edit lib/canonical/librarian/server.tac to set a path to the storage and to choose a port for it
[02:46] <Kinnison> then you run (from the level where you'd make run for launchpad) twistd -noy lib/canonical/librarian/server.tac
[02:46] <Kinnison> If you don't have it already; then prefix that twistd command with 'PYTHONPATH=lib '
[02:47] <cprov> Kinnison: ok
[02:48] <Kinnison> cprov: It's important to remember that the database and filesystem path combination work together for the librarian
[02:48] <Kinnison> so if you blow the db away; remember to blow the filesystem it created away
[02:48] <Kinnison> Also if you copy the DB, copy the filestore too
[02:48] <sabdfl> limi: for a single distro that would be the max for now, yes
[02:48] <limi> ok
[02:48] <Kinnison> cprov: *or* mod gina to make the librarian interface optional :-)
[02:49] <cprov> Kinnison: I thinking in this possibility now :)
[02:54] <ddaa> ew
[02:54] <ddaa> the tarfile error is caused by getting a 401 from chinstrap...
[02:54] <ddaa> (auth required)
[02:55] <ddaa> in zenity.info:
[02:55] <ddaa> CvsTarFile: http://chinstrap.warthogs.hbd.com/~jdub/cvsballs/zenity.tar.bz2
[02:57] <ddaa> So... what would be the magic trick to make that work from my workstation?
[02:57] <ddaa> elmo: any idea?
[03:01] <Kinnison> cprov: eh?
[03:04] <cprov> Kinnison: yep, It will take so long to mod gina to work w/o librarian and I'll take the risc of kill you work, I've just perform some surgery on my DB and recover the previous generated gina data
[03:05] <cprov> Kinnison: but I'll  be glad if you can do the modularization of gina :)
[03:05] <Kinnison> cprov: Maybe when I've sorted this poolbuilder
[03:07] <cprov> Kinnison: thanks, enjoy you lunch !
[03:09] <limi> :)
[03:26] <cprov> sabdfl: so, now it is ok, nicole is generating correct productreleases and I modified it in the way that you can take partial dumps when it still running to have a kind of DB snapshot
[03:27] <cprov> sabdfl: I have one im my home with ~10 projects ...if you want you can do you own now (~30)
[03:44] <ddaa> Looks like it works...
[04:03] <sabdfl> cprov: could you do a dump for me please, and point me at it?
[04:04] <cprov> sabdfl: of course, just a second
[04:05] <sabdfl> limi: figured out how to make javascript fly?
[04:05] <cprov> sabdfl: scp zhongshan.ubuntu.com:/home/cprov/lp_dump-productrelease-partial.sql.gz
[04:07] <sabdfl> cprov: thanks!
[04:07] <sabdfl> do I just drop my db and then use this to recreate it?
[04:07] <limi> sabdfl: "not fly", as the case may be - the conclusion is that we should use XML-RPC with an inline search widget to do this server-side - with a fallback on the button to do a traditional search if you don't have JS
[04:07] <Kinnison> dropdb foo; createdb -E UNICODE foo; zcat bar.sql.gz | psql foo
[04:07] <limi> Javascript just won't handle 20K items (tested with 5K)
[04:08] <sabdfl> limi: absolutely no way to do this client side?
[04:09] <limi> nope, too many entries - but it is client-side in the sense that you don't leave the form
[04:10] <BradB> stub: Can we drop the dependence on plpython? The security concerns it adds don't seem worth it for 10 lines of Python validation code.
[04:10] <cprov> sabdfl: dropdb XXX; createdb -E UNICODE XXX, psql -f <dump> XXX
[04:10] <stub> What is the security concern?
[04:11] <BradB> The fact that pqm has to run as a superuser on the DB for us to checkin changes ;)
[04:12] <BradB> I don't think that actually works yet, but it was supposed to yesterday, until we hit that roadblock.
[04:12] <stub> a postgres superuser, although I'm discussing this with steve on habber atm. Why is that a problem?
[04:12] <BradB> stub: It's a big risk to take if the production database is on the same machine as a non-production one.
[04:13] <BradB> And, well, it's 10 lines of Python. :)
[04:13] <stub> I wasn't aware we had that situation anywhere.
[04:14] <BradB> I'm sure elmo could provide a more detailed explanation of the risks involved though.
[04:14] <stub> It will be more one day. It is trivial to redo it in pl/pgsql so I'm not fussed about the current code but it is more for future expansion.
[04:15] <stub> It means that pqm has write access as the postgres user, so they can trash all the postgres databases on that server if they want.
[04:15] <BradB> yep, that's the most obvious risk. there are probably other things though too.
[04:16] <stub> It isn't a problem on a single database server, since they can trash that single database anyway by dropping tables.
[04:16] <SteveA> stub: I'd like to get pagetests running on pqm today.
[04:18] <BradB> Is there a smoother way to run the page tests yet?
[04:18] <SteveA> what needs to happen in the set-up scripts for the launchpad_test database to make it so that they can be run by pqm?
[04:19] <stub> The tests I had did everything - built the database etc. I have no idea what other people are trying to do in their tests.
[04:20] <sabdfl> cprov: shortdesc seems to be picking up parts of sentences
[04:20] <sabdfl> for example:
[04:20] <sabdfl> AbiWord is a cross-platform Open Source word processor. The goal
[04:20] <sabdfl> why does it get "The goal" at the end?
[04:21] <sabdfl> fm has the summary and description fields, which should map to our shortdesc and description
[04:21] <sabdfl> BradB: should the tests all be passing now?
[04:22] <BradB> sabdfl: The page tests; there doesn't seem to have been much done yet to make the UT and FT's pass though.
[04:22] <sabdfl> how do i run just the page tests?
[04:23] <BradB> sabdfl: I run them like this: bradb@ozone:~/launchpad/lp$ PYTHONPATH=~bradb/launchpad/lp/lib python lib/canonical/ftests/test_pages.py
[04:23] <SteveA> stub: I need to know what I can hook into my page-test-runner to set up the database 
[04:23] <cprov> sabdfl: shortdesc is always unexpectable (it should cut on first dot), I'll request it to Morgan 
[04:23] <SteveA> stub: right now, it runs "make" in database/schema
[04:23] <SteveA> stub: but, pqm can't do that
[04:24] <stub> Can pqm create and drop databases?
[04:24] <SteveA> yes
[04:24] <stub> so the only problem is plpythonu?
[04:24] <SteveA> yes
[04:24] <elmo> err, no
[04:24] <SteveA> no?
[04:24] <elmo> I gave pqm createuser last night
[04:25] <elmo> and it already had createdb -> it's postgres superuser
[04:25] <daf> are we going to need to change things on Mawson to get plpgsql to work?
[04:25] <SteveA> guys, my requirement is to get pqm to be able to set up the launchpad_test database with appropriate contents and constraints etc., like it would be in production.
[04:26] <stub> so there shouldn't be any problems then. Running make does that.
[04:27] <sabdfl> cprov: alsa got a project but not a product. why?
[04:27] <carlos> hi
[04:27] <daf> hi Carlos
[04:28] <elmo> stub: the problem is, requiring superuser in postgres is insane.  if, for example, anyone wants to run a launchpad type instance anywhere near the machine running katie, I'm just going to point and laugh at them
[04:28] <SteveA> stub, elmo: so I can re-enable running "make" in database/schema on merge?
[04:28] <elmo> even on chinstrap, there's more than pqm using postgres
[04:28] <elmo> SteveA: AFAIK, yes
[04:28] <daf> carlos: could you update the StaffCalendar page with your new working hours?
[04:28] <carlos> yes
[04:28] <SteveA> elmo: is this a temporary hack, or how it will be?
[04:29] <elmo> SteveA: *shrug* I dunno, if none of the other postgres users on chinstrap mind, then it can probably stay, but I'm trying to point out that it's not a sane long term solution IMO
[04:30] <cprov> sabdfl: cause the product algorithm seems to failed to look for alsa-driver, alsa-tools, etc, since nothing is returned with these names from Morgan lib 
[04:30] <stub> ok - then we have to drop using embedded python procedures. I wasn't aware we had that many production databases to worry about.
[04:30] <SteveA> carlos, daf: Can we have a rosetta team meeting on #canonical-meeting, now?
[04:30] <carlos> SteveA: yes
[04:30] <elmo> stub: it's not just embedded python - it's the whole drop the db and recreate it - even with just 'createdb' the pqm instance could, f.e.  drop the buttress database
[04:31] <cprov> sabdfl: I'm modifying it now to insert default projects either it hasn't a respective SF/FM product
[04:31] <elmo> maybe I'm being over paranoid, and maybe there really isn't a better way to do it in postgres
[04:31] <stub> elmo: That can be fixed, although it is much more likely to hang.
[04:31] <SteveA> elmo: suid script to set up the database we need in the way we need it ?
[04:32] <stub> The butress database is running on chinstrap???
[04:32] <SteveA> (I know "suid script" doesn't make sense...)
[04:32] <elmo> there's a 'buttress' db on chinstrap - I don't know whether it's the master or what
[04:35] <stub> createdb/dropdb shouldn't be a problem if we don't mix production and dev on the same server (and neither should plpythonu).
[04:46] <stub> SteveA: So it sounds like at the moment at least, just running 'make' should be fine for PQM to build the launchpad_test database
[04:46] <SteveA> ok, I'm going to try turning this on again.
[04:47] <stub> elmo: Can you let me know if I need to remove the dependancy on plpythonu on the server, and if PQM needs to lose the ability to drop databases.
[04:47] <BradB> Already fixing Malone bugs that were spotted quickly with page tests. :)
[04:48] <stub> Losing plpythonu isn't a problem at the moment, but just restricts us a bit. 
[04:48] <stub> (for future work)
[04:48] <stub> PQM can lose the ability to drop and create databases, but it might cause deadlocks on occasion if a previous run didn't close connections to the database cleanly
[04:51] <BradB> SteveA, daf: Are the page tests docs going to be released today? I'd like somewhere that I can read about how to actually document the page tests (i.e. inside the .txt file itself), and a point of reference showing me how to fix common problems I might encounter (like the IOError and tabs vs. spaces thing from last night)
[04:52] <SteveA> BradB: yes.  And, I'd like to see if you can reproduce the tabs vs spaces thing with the new system.
[04:53] <BradB> me too :)
[04:53] <SteveA> BradB: I need to see instructions on how to reproduce an IOError.  Can you file a bug on it, with instructions on how to reproduce it?
[04:53] <stub> Are we using webunit or something for page tests, or something home brewed?
[04:54] <BradB> SteveA: sure
[04:54] <SteveA> stub: the thing from zope3
[04:56] <stub> I'm actually working on a better postgresql test harness at the moment so tests are better isolated (without having to use the existing harness that builds the database every single test)
[04:56] <SteveA> how would that work?
[04:57] <stub> By making connection.commit() a noop, meaning I can rollback all changes since the start of the test. It will screw tests that span zope transactions though if they expect an exception to rollback database changes (in some cases)
[04:58] <dilys> Bug 2049 resolved: Link from source package release to binary package release is not displaying version
[04:58] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2049
[05:02] <SteveA> this won't work well for page tests I think.
[05:02] <SteveA> but, should work okay for smaller-scope functional tests
[05:04] <ddaa> how comes the buildbot test suite breaks because of some code in cscvs which relies on a contract in pyarch which has changed months ago...
[05:04] <ddaa> bob2: any insight?
[05:07] <sabdfl> ddaa: how long does it typically take to get a new import up to syncing status?
[05:08] <ddaa> sabdfl: no idea, still working on my first new import.
[05:08] <sabdfl> morgs we have your code up and running in "nicole", celsos script
[05:08] <sabdfl> seems to be a good start, thank you
[05:09] <ddaa> If you mean the time of the initial import, in my testing environment, it's of the order of one small hour (slow cpu here).
[05:09] <cprov> morgs: welcome
[05:09] <sabdfl> how do I do an orderBy in a MultipleJoin?
[05:10] <morgs> Chatting with Celso on jabber too... I'll continue here
[05:10] <sabdfl> descending, to be cute?
[05:10] <sabdfl> ddaa: goal is to get the import process to the point where the package maintainer can mostly drive it
[05:10] <spiv> sabdfl: things = MultipleJoin('Thing', orderBy='foo'), I belive.
[05:10] <morgs> cprov: just starting the RSS stuff, I was adding savannah.gnu.org repository but it doesn't have as much detail as sourceforge
[05:10] <sabdfl> spiv: and descending?
[05:11] <sabdfl> morgs: rss?
[05:11] <spiv> Ohk, orderBy='foo DESC' :)
[05:11] <stub> "-foo"
[05:11] <ddaa> spiv: initial import of zenity up to the breakage in taxi.py: 25mins
[05:11] <sabdfl> spiv: thanks
[05:11] <spiv> Or orderBy='-foo'
[05:12] <spiv> ddaa: I'm still having trouble makinga testcase for taht :(
[05:12] <ddaa> spiv: maybe you should ask bob2... he's the one who wrote it iirc.
[05:13] <ddaa> sabdfl: hu see message to spiv 2 mins ago.
[05:14] <morgs> sabdfl: xml feeds
[05:14] <sabdfl> morgs: ah, ok, thanks
[05:14] <morgs> brb
[05:15] <cprov> morgs: great, I supose it will be easier to grab all the fields than HTML parser 
[05:17] <morgs> any advice on xml parsing? I think there is a .deb...
[05:21] <SteveA> libxml2 is very full of features, but rather awkward to use from python
[05:21] <SteveA> but, you can do xpath with it, which is a very simple way of getting data from xml.
[05:21] <SteveA> otherwise, use minidom
[05:21] <SteveA> that's in the standard python library
[05:22] <SteveA> use the dom methods to get to where you need to be in the tree
[05:22] <SteveA> more verbose than xpath, but should be pretty understandable and quick to implement
[05:22] <morgs> SteveA: Great, that should get me what I need.
[05:22] <stub> elementtree is less verbose than using a DOM, and has primative xpath support now.
[05:22] <SteveA> There's a project to wrap libxml2 more pythonically, but it is being done in a couple of people's spare time, and it isn't really progressing.
[05:23] <SteveA> what's elementtree ?
[05:23] <SteveA> (my dear watson?)
[05:23] <stub> effbot's XML library
[05:24] <stub> http://effbot.org/zone/element-index.htm
[05:26] <spiv> There's also beautifulsoup, but it's more intended for HTML scraping.
[05:26] <spiv> No reason why it wouldn't work for XML, though...
[05:26] <morgs> spiv: I'm doing some HTML scraping... what/where is beautifulsoup?
[05:27] <stub> http://www.crummy.com/software/BeautifulSoup/
[05:27] <spiv> http://www.crummy.com/software/BeautifulSoup/
[05:27] <spiv> stub: Drat :)
[05:27] <morgs> Thanks, I'll check it out.
[05:28] <stub> I've had recommendations for it from people who I trust, but haven't used it personally.
[05:28] <spiv> Heh: "Beautiful Soup defines two parsers: BeautifulSoup, which parses HTML with just enough smarts to be dangerous, and BeautifulStoneSoup, which doesn't try at all to be smart and is therefore well-suited for parsing XML documents and pseudo-HTML with made-up tag names."
[05:28] <dilys> Bug 2051 resolved: Use apt_pkg (from python-apt) to parse dependency lists
[05:28] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2051
[05:29] <spiv> stub: Yeah, I suggested it to Anthony Baxter for TWFY, although I'd never used it, and he came back saying how wonderful it was :)
[05:33] <ddaa> cscvs test suite blows on the first test...
[05:34] <dilys> Bug 2018 resolved: Complete information for binary package release.
[05:34] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2018
[05:35] <dilys> Bug 2010 resolved: Build pages need to be defined for a binary package release
[05:35] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2010
[05:51] <sabdfl> erm, how do i make a select a dropdown listbox?
[05:51] <SteveA> size="1" or something like that iirc
[05:52] <sabdfl> that's obvious, why didn't i think of it?
[05:52] <SteveA> and, make sure it isn't a multiple select
[05:53] <SteveA> BradB: the pagetests are now running on merge.  That is, a merge will be rejected if a pagetest fails.  Next, I want to talk through it with daf.  Daf will update the docs he wrote, and post them to the list.  Meanwhile, if you don't mind, I'll move all your (and others') existing page tests into the new location.
[05:55] <BradB> SteveA: By the looks of things, you've removed utilities/page-test-helper, in favour of ./makepagetest.py, right?
[05:55] <SteveA> um... removing page-test-helper was sort of an accident
[05:55] <SteveA> I wanted to remove it, but not so soon
[05:55] <SteveA> but, yes
[05:56] <SteveA> hang in there, we'll be out of the tunnel in an hour or so
[05:56] <BradB> great, just in time for me to return from lunch :)
[05:56] <BradB> I'm really happy that we won't be able to merge unless the page tests pass, since if it had been like that before, I'd be looking for other tasks to do, instead of fixing stuff that had already been working in Malone. :)
[05:57] <SteveA> ok, have a good lunch
[05:58] <sabdfl> kidding
[06:15] <elmo> huh?
[06:16] <ddaa> would you prefer pwd.getpwuid(os.getuid())[0]  ?
[06:16] <elmo> AFAIK that's what os.getlogin() does if LOGNAME fails - why wouldn't it fail with the same IOError if you're really missing /etc/passwd
[06:16] <sabdfl> SteveA: about those clearer debugging messages
[06:16] <sabdfl> try this one
[06:17] <sabdfl> here's the last bit of the traceback:
[06:17] <sabdfl>     Module zope.app.traversing.adapters, line 167, in traversePathElement    Module zope.app.traversing.adapters, line 52, in traverse
[06:17] <sabdfl>  __traceback_info__: (<Product at 0x442a418c>, 'releases', [] )  NotFoundError: (<Product at 0x442a418c>, 'releases')
[06:17] <sabdfl> looks fairly clear
[06:17] <sabdfl> but releases is in both the interface, and the object definition
[06:17] <sabdfl> hmm
[06:17] <sabdfl> further digging:
[06:17] <ddaa> os.getlogin raises an IOError in the cscvs test suite for some unfathomable reason, but...
[06:18] <daf> sabdfl: looks like a traversal directive is missing
[06:18] <sabdfl> (Pdb) print subject
[06:18] <sabdfl> <Product at 0x442a422c>
[06:18] <sabdfl> (Pdb) subject.id
[06:18] <sabdfl> 4
[06:18] <sabdfl> (Pdb) subject.name
[06:18] <sabdfl> u'firefox'
[06:18] <sabdfl> (Pdb) subject.releases
[06:18] <sabdfl> *** AttributeError: 'ProductRelease' object has no attribute 'datecreated DESC'
[06:18] <sabdfl> (Pdb)
[06:18] <sabdfl> noo....
[06:18] <ddaa> elmo: thanks for making me think, I should investigate more on what happens in the debugger
[06:19] <sabdfl> really the problem is with an SQLObject that is not mentioned ever in the traceback
[06:20] <daf> right, so Zope is trying to traverse from the firefox product to its releases
[06:20] <daf> and when it tries to do this, it gets a AttributeError
[06:20] <sabdfl> it dies during the join, yes
[06:20] <daf> which it translates into a NotFoundError
[06:20] <sabdfl> very helpfully
[06:21] <SteveA> why does dieing during the join lead to an AttributeError?
[06:21] <ddaa> elmo: so, os.getlogin fails, but the latter does work...
[06:21] <SteveA> rather than a database error?
[06:21] <ddaa> for some unfathomable reason.
[06:22] <daf> "dying during the join"?
[06:22] <daf> how did we work that out?
[06:22] <sabdfl> daf: look at the pdb output
[06:22] <daf> something is trying to access a non-existant attribute 'datecreated DESC'
[06:23] <SteveA> sabdfl: ideally, what would you like the error to be in this case?
[06:23] <daf> the problem is with SQLObject, not Zope
[06:23] <sabdfl> the output of the AttributeError told me exactly what the problem was
[06:23] <sabdfl> spiv told me to use orderBy="foo DESC" which i did
[06:24] <daf> I think it's quite reasonable to turn an AttributeError into something not being found
[06:24] <sabdfl> but i used datecreated
[06:24] <sabdfl> and the fieldname is actually datereleased
[06:24] <sabdfl> what was perverse is that the context/releases thing works FINE if there are no releases
[06:24] <sabdfl> because the orderBy never is used
[06:24] <sabdfl> it was a fun 20 minutes :-)
[06:25] <SteveA> ah... was it a "deeper" attribute error?
[06:25] <sabdfl> I don't know under what circumstances an AttributeError is generated, but
[06:25] <sabdfl> a failed JOIN is not "attribute not found"
[06:25] <SteveA> that is, the traversal code is interested in an "immediate" attribute error -- that is, the attribute it is trying to get does not exist 
[06:25] <sabdfl> SteveA: yes
[06:25] <SteveA> okay... that's really a python limitation
[06:25] <sabdfl> SteveA: it exists though
[06:26] <SteveA> there's a hack to work around it, though.  but it ain't pretty
[06:26] <daf> I'm pretty sure this is a bug in SQLObject
[06:26] <daf> which results in a misleading exception
[06:26] <sabdfl> so zope can't tell the difference between trying to access an attribute which does not exist, and an AttributeError raise by an attribute which DOES exist?
[06:26] <SteveA> what *should* happen is that the traversal code should be interested in an "immediate" attribute error only, and should just pass on a "deeper" attribute error
[06:27] <SteveA> Python can't tell the difference.
[06:27] <SteveA> this is one of python's "the snake bites you on the arse when you aren't expecting it" situations
[06:27] <sabdfl> ok
[06:27] <SteveA> the hack involves examining the depth of traceback
[06:27] <daf> Zope can't tell the difference between an AttributeError that was raised by the object it was looking at directly, and an AttributeError raised by code that runs when accessing an attribute that does exist
[06:27] <SteveA> compared to the current stack frame
[06:27] <sabdfl> is "productrelease" a sane default for traversal past product?
[06:28] <sabdfl> in doap, at least?
[06:28] <daf> releases is a magical attribute which runs code when it is accessed
[06:28] <daf> when that code raises an AttributeError, it looks to Zope like that attribute doesn't exist
[06:28] <daf> so the problem is with the code run when the property is accessed
[06:28] <sabdfl> what if SQLObject raised a differnet exception?
[06:29] <daf> I don't know
[06:29] <daf> but if you fix SQLObject to do the orderBy properly, the exception shouldn't occur
[06:30] <daf> doing the exception-depth magic is a longer-term solution to getting better error messages from Zope
[06:38] <Kinnison> spiv: ping?
[06:39] <sabdfl> spiv: orderBy='foo DESC' definitely doesn't work
[06:40] <sabdfl> but orderBy='-foo' seems to work ok
[06:42] <carlos> sabdfl: but what happens if foo is not a number?
[06:44] <SteveA> I'm going to see if I can improve this for traversal in zope3, and thusly for launchpad
[06:45] <SteveA> should be a reasonably quick thing to hack up
[06:51] <daf> carlos: 'foo' is an attribute name
[06:52] <daf> carlos: i.e. in a string
[06:52] <daf> sabdfl: I suspect what might have happened is that support for 'blah DESC' was removed in SQLObject 0.6
[06:52] <carlos> daf: I know, but if the Attribute is not a number, the "-foo" thing will not work, right?
[06:53] <ddaa> the cscvs test suite that the $HOME of lifeless hardcoded...
[06:53] <daf> carlos: SQLObject translates the '-' into a 'DESC' in the SQL
[06:54] <carlos> daf: ohh, I see
[06:54] <carlos> that's not too userfriendly but if it works... :-P
[06:54] <Kinnison> spiv: reping
[06:57] <SteveA> how do I remove a directory in my arch tree?
[06:57] <SteveA> can I just remove it, and commit?
[06:57] <Kinnison> yep
[06:58] <SteveA> hmm, it tells me it is not empty.  It contains a .arch-ids directory.
[06:58] <carlos> daf: are you working on https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2036 ?
[06:58] <ddaa> rm -rf
[06:58] <Kinnison> SteveA: yeah; all dirs contain one
[06:59] <ddaa> The .arch-ids dir contains the explicit ids of the directory and files at the top-level.
[06:59] <SteveA> ddaa: I'd prefer just rm -r
[06:59] <ddaa> SteveA: as you wish
[07:00] <SteveA> thanks ddaa and Kinnison
[07:00] <Kinnison> SteveA: the idea is that you can mv a dir; and arch knows you renamed it rather than deleted a whole pile of shit and re-added it
[07:25] <sabdfl> limi: how do i add a picture to a page on the web site?
[07:25] <SteveA> we'll need a way of testing emails as well as pages.
[07:25] <limi> sabdfl: in HTML or Structured Text?
[07:25] <sabdfl> either?
[07:25] <ddaa> Yay! I have finally beaten the cscvs test suite into passing!
[07:25] <sabdfl> how do i make the image available in the first place?
[07:26] <limi> "This is image description":img:someimage.jpg
[07:26] <limi> oh
[07:26] <limi> just add Image from the pulldown
[07:26] <sabdfl> cool, thanks
[07:27] <limi> it will keep its name by default, but you can change it afterwards if you need to
[07:28] <Kinnison> spiv: Is there a good reason why I can't retrieve a file from the librarian by aliasid alone?
[07:31] <sabdfl> limi: can i set the size of it in StructuredText?
[07:31] <limi> sabdfl: no, STX is only for semantic markup in a way - you have to use HTML for layout changes
[07:31] <limi> but you can mix them
[07:32] <limi> so use STX, and display the image using <img src="..." height=" /> etc
[07:37] <sabdfl> limi: how do I put a 1-pixel border around an image?
[07:37] <sabdfl> baby steps again..
[07:37] <limi> hehe
[07:37] <limi> style="border: 1px solid black;"
[07:38] <Kinnison> limi: or better.. class="borderedImage" and then define the class in the CSS ?
[07:38] <Kinnison> limi: Or am I abstracting too much?
[07:38] <limi> Kinnison: well, Mark is making a simple one-instance change here :)
[07:38] <limi> hehe
[07:38] <Kinnison> abstraction alert
[07:39] <limi> it would be the right thing to do throughout a site, yes
[07:39] <limi> but "borderedImage" is not really a useful name, to be nitpicky - 2 months down the line you decide to use a different visual effect for it
[07:40] <Kinnison> yep; well said
[07:40] <Kinnison> limi: eww
[07:40] <limi> or, my favorite <h2 class="header">
[07:40] <Kinnison> limi: I may not be good at chosing css class names; but at least I'm not that bad :-)
[07:40] <limi> ;)
[07:40] <SteveA> class="greenBorder normalSize"
[07:41] <Kinnison> or <span class="nav2">
[07:41] <sabdfl> (18:40:25) limi: or, my favorite <h2 class="header">
[07:42] <sabdfl> <h3 class="subHeader"> was all over the show, and i was copying it too
[07:42] <limi> sabdfl: yes, it's what the DocBook stuff produces, I believe
[07:42] <sabdfl> nice
[07:42] <limi> it's pretty insane :] 
[07:42] <sabdfl> and good citizenship means alt="descriptivetext" for images right?
[07:42] <Kinnison> sabdfl: yep
[07:42] <Kinnison> sabdfl: and title="popup titley text" if you want that
[07:42] <limi> descriptive text is title= - alt is for "alternative representation
[07:43] <sabdfl> ah
[07:43] <Kinnison> sabdfl: remember that alt is for screenreaders and the like
[07:43] <limi> slightly different ;)
[07:43] <Kinnison> sabdfl: read http://diveintoaccessibility.org/ it's great
[07:43] <Kinnison> because it lacks a tla undo --keep
[07:43] <sabdfl> limi: it would be great if i could just link to the image in plone and it automatically used the title and description from the object...
[07:44] <limi> sabdfl: it does if you use Kupu or Epoz
[07:44] <debonzi> hi Kinnison, why dbschema.PackagePublishingStatus.PUBLISHED does not exists anymore?
[07:44] <limi> but as Mozilla has bugs that make them unusable at the moment...
[07:44] <limi> :(
[07:44] <debonzi> sory
[07:44] <Kinnison> debonzi: It doesn't?!?!
[07:44] <debonzi> sorry... PROPOSED
[07:44] <sabdfl> ah
[07:44] <Kinnison> aah; because sabdfl and I agreed that in its original state, that field confused publishing with queues with policy
[07:45] <Kinnison> package proposals will need to come in via a different route
[07:45] <Kinnison> the publishing tables are *purely* for publishing with in a distro{arch,}release
[07:46] <ddaa> is pqm offline or something?
[07:47] <debonzi> Kinnison, uhmmm because I was showing in the sourcepackage page the proposed sourcepackage version. Should it not exists anymore.... or for while?
[07:47] <SteveA> pqm seems to be waiting for instructions
[07:48] <Kinnison> debonzi: when mark and I work out how the whole derivative distributions malarky will work; we will be able to put it back. For now; I guess commenting it out will do
[07:48] <debonzi> Kinnison, right.. thanks
[07:57] <carlos> sabdfl, SteveA: Which one was the final policy about the Tables/Attributes names? all the same as in the database?
[07:57] <Kinnison> SQLObject gurus.. Do I have to do something magical in order to select by the ID field of a table?
[07:58] <ddaa> SteveA: for some reason i do not seem to receive its ack messages...
[07:58] <carlos> Kinnison: object.get()
[07:58] <sabdfl> carlos: meaning? do you need to keep the SQLObject the same as the db? yes
[07:58] <sabdfl> Kinnison: glad that bit you too
[07:58] <carlos> sabdfl: yes, that's what I mean
[07:58] <carlos> sabdfl: and the attributes all in lowercase?
[07:58] <Kinnison> sabdfl: I'm glad you're glad I got bitten
[07:58] <sabdfl> Kinnison: Product.selectBy(ownerID=1)
[07:58] <carlos> dateChanged or datechanged?
[07:59] <sabdfl> carlos: datechanged
[07:59] <carlos> ok
[07:59] <Kinnison> sabdfl: LibraryFileAlias.selectBy(ID=aliasid) is what I want
[07:59] <sabdfl> Kinnison: nothing altruistic about it :-)
[08:00] <BradB> Kinnison: you shouldn't be doing selects on id's
[08:00] <Kinnison> BradB: whyever not?
[08:00] <SteveA> ddaa: you mail perhaps not being sent out with a valid return addresss?
[08:01] <BradB> Kinnison: LibraryFileAlias(id) instead
[08:01] <Kinnison> BradB: aah, I had LibraryFileAlias.get(id) thanks to carlos
[08:01] <debonzi> sabdfl, SteveA : is it ok to changes stuff like IWikiName, IJabberID, IIrcID from ikiko to interfaces/person.py or whould exist a better place to it?
[08:01] <Kinnison> BradB: your way give: exceptions.TypeError: __init__() takes exactly 1 argument (2 given)
[08:02] <BradB> bah
[08:02] <BradB> i guess that faded away in 0.6
[08:02] <Kinnison> Is there a useful way to force an SQLObject to stop being lazy?
[08:02] <ddaa> hu... my /etc/email-addresses is correct...
[08:02] <Kinnison> I want to do foo = somequery; print foo
[08:02] <Kinnison> but that doesn't seem to work
[08:03] <BradB> Kinnison: with 0.6, indeed .get is the right method.
[08:05] <Kinnison> >>> LibraryFileAlias.get(1)
[08:05] <Kinnison> <LibraryFileAlias at 0x40c1aa6c>
[08:05] <Kinnison> fairly useless
[08:05] <Kinnison> how can I force that to show me the tuple?
[08:06] <kiko> what tuple?
[08:06] <Kinnison> the row from the table
[08:06] <Kinnison> BradB: bored?
[08:06] <ddaa> Ha... indeed... exim seems to ignore /etc/email-addresses...
[08:06] <kiko> Kinnison, you don't want to use SQLObject for that AFAICS
[08:06] <BradB> Kinnison: You don't want a tuple, you evil DB-API'er
[08:07] <BradB> unless you do
[08:07] <kiko> Kinnison, you want to do a direct connection query. ask cprov, I've done it with him.
[08:07] <Kinnison> BradB: I just wanna see that the select worked
[08:07] <BradB> it did
[08:07] <Kinnison> BradB: is there some .allColumns or something?
[08:07] <ddaa> What's the right way to clobber the From: header of mail sent by local users using exim?
[08:07] <Kinnison> ddaa: exim rewrites usually
[08:08] <BradB> Kinnison: if it didn't find the object having that ID, it would have raised something like an SQLObjectNotFoundError (dunno if it's still called that though)
[08:08] <ddaa> Kinnison: is there an answer which would help me get it to work in a few minutes w/o reading any significant documentation?
[08:08] <Kinnison> ddaa: what version of exim? 3 or 4?
[08:09] <ddaa> Huuuu
[08:10] <ddaa> ha it's postfix actually... the ubuntu basic...
[08:10] <Kinnison> sudo dpkg-reconfigure postfix
[08:10] <Kinnison> answer the first question with the domain for outgoing mail
[08:10] <Kinnison> then things should work
[08:11] <ddaa> mh... okay... that'll work... not the cleanest solution ever... but will work. Thanks.
[08:13] <Kinnison> If anyone can answer the question "How do I make postfix send mail to a smarthost using authenticated SMTP" in a way which works (google doesn't seem to be helpful here) I'd be grateful, but for now I'm not too bothered
[08:14] <cprov> Kinnison: simply: apt-get install exim4 <wink>
[08:14] <dilys> New bug 2102 for Launchpad/Soyuz: Go away with ikiko.py and dkiko.py
[08:14] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2102
[08:15] <Kinnison> cprov: that's what I did; but then ubuntu-base complains because it depends on postfix
[08:16] <cprov> Kinnison: it "conflics", doesn't it ? 
[08:16] <cprov> Kinnison: not depends ...
[08:17] <Kinnison> cprov: yeah; exim works fine; but I have to remove ubuntu-base because ubuntu-base depends on "postfix, postfix-tls"
[08:17] <Kinnison> otherwise on upgrades it tries to replace exim with postfix
[08:17] <cprov> Kinnison: really I didn't get it here (sounder9)
[08:19] <cprov> Kinnison: I've just installed last weekend and replaced postfix by exim4, yesterday I did upgrade and it was ok 
[08:20] <Kinnison> perhaps I broke my setup somehow
[08:21] <cprov> Kinnison: :) Crazy Debian Developers ...
[08:21] <Kinnison> w00p w00p!
[08:22] <Kinnison> dsilvers@petitemort:~$ curl http://localhost:18000/byalias?alias=1
[08:22] <Kinnison> /1/1/3dchess_0.8.1-11.dsc
[08:22] <Kinnison> Now the librarian supports get-by-alias :-)
[08:25] <kiko> coool
[08:27] <Kinnison> >>> from canonical.librarian.client import FileDownloadClient
[08:27] <Kinnison> >>> c = FileDownloadClient('localhost',18000)
[08:27] <Kinnison> >>> c.getFileByAlias(1).read()
[08:27] <Kinnison> <big string>
[08:29] <sabdfl> kiko: would you recommend person.py or separate files for IWikiName etc in response to debonzi?
[08:30] <sabdfl> Kinnison: p = Person.get(id)
[08:30] <sabdfl> p.name
[08:30] <sabdfl> p.givenname
[08:30] <sabdfl> p.familyname
[08:30] <sabdfl> etc
[08:31] <Kinnison> sabdfl: Yeah, I kinda want p.allColumns() to give me { "name": "blah".... }
[08:31] <Kinnison> sabdfl: no matter; I've worked around it
[08:32] <kiko> sabdfl, person.py, really. if it gets too fat we'd use person_properties or something, but ideally not.
[08:32] <sabdfl> i'd prefer separate files myself
[08:32] <jblack> limi, you happen to be around ?
[08:32] <jblack> Hi boss
[08:32] <sabdfl> hey jblack
[08:33] <jblack> This weekend I'll write up a proposal which I'll feed to lifeless, then to you, then to the community, that covers having a user driven version of arch.
[08:33] <jblack> roadmap, etc.
[08:33] <sabdfl> great jblack
[08:33] <sabdfl> we really need this
[08:33] <sabdfl> and now is the time!
[08:34] <jblack> Oh, I absolutely positively agree.
[08:34] <cprov> sabdfl: to be precise I'd preffer all person_related operation should be proxied by FOAF environment, so Person will be part of FOAF
[08:34] <SteveA> jblack: I have two tla gripes I'd like to add to the manifesto.  Perhaps you can point me to the best place to add them? 
[08:34] <sabdfl> cprov: agreed
[08:34] <sabdfl> but that doesn't mean they all ned to be in person.py
[08:34] <jblack> stevea: Sure thing. Throw them up at manifesto.gnuarch.org
[08:34] <cprov> sabdfl: I mean CreatePerson(), CreateTeam(), etc
[08:34] <jblack> That's where I'm going to be doing the feature planning.
[08:35] <limi> jblack: yes, I'm here
[08:35] <SteveA> jblack: yes, but where? 
[08:35] <jblack> limi: Have some free time boss? I was hoping that we could talk.
[08:35] <SteveA> you want me to stick them on the front page?
[08:35] <jblack> SteveA: That would be fine, though if you're willing to build some organizational structure, you're welcome to do that as well. 
[08:35] <limi> jblack: maybe over the weekend, I really need to finish my work for today (it's close to nine in the evening here :)
[08:36] <jblack> limi: Ok. Understand. Arch giving you too much of a problem right now? 
[08:36] <kiko> sabdfl, now I'm slightly confused. what are you proposing we place in person.py?
[08:36] <SteveA> jblack: okay -- that explains why I couldn't find a suitable place for them
[08:36] <limi> jblack: not after I got rid of it and set up subversion, no ;)
[08:36] <sabdfl> i'm not proposing we put anything in person.py
[08:36] <jblack> limi: Oh, really? Ok.
[08:36] <cprov> sabdfl: no, they should have table/system related names, definitily 
[08:36] <jblack> I understand.
[08:36] <sabdfl> debonzi was asking where to put class WikiName
[08:37] <limi> jblack: since we're in a hurry these days, I normally just mail my changes and have others commit them
[08:37] <jblack> stevea: Yeah, the swarm of people I hoped for hasn't arrived, so I need to put more effort into it.
[08:37] <sabdfl> i was preferring wikiname.py, but wanted to see what you though
[08:37] <sabdfl> t
[08:37] <sabdfl> limi: what's the right way to do align=right on an image?
[08:37] <jblack> limi: There anybody as else that's as frustrated as you, that I might still be able to save? 
[08:37] <sabdfl> seems to fail in i.e.
[08:38] <limi> sabdfl: style="float: right"
[08:38] <limi> jblack: I believe BradB is a good candidate, but he's probably on top of it technically
[08:39] <limi> but he's probably good to probe for feedback
[08:39] <jblack> Ok. I'll get with him. 
[08:39] <limi> oh, and kiko has a lot of good thoughts on how to improve arch
[08:39] <limi> from a user perspective
[08:39] <BradB> jblack: my main issue with tla/arch on OS X is the speed. i'm not sure that can be remedied without a tremendous amount of work though; more than would be justified, perhaps.
[08:40] <SteveA> jblack: http://manifesto.gnuarch.org/moin.cgi/ArchWarts
[08:40] <jblack> Good name
[08:40] <jblack> Brad! Hi there. Nice to meet you.
[08:40] <BradB> ditto :)
[08:40] <jblack> BradB: I've heard about it. I'm saving up for a osX machine so that I can debug the issues. 
[08:40] <SteveA> after amk's "python warts" http://www.amk.ca/python/writing/warts.html
[08:42] <debonzi> sabdfl, I know they are related with person, but I also whould prefer to dont have it inside person.py. But I also don't know if it is a good idea to have one file just for IWikiName another one for IJabberID and so on.
[08:42] <jblack> BradB: That's really the bulk of it, right? Really sucky performance on OsX ? 
[08:43] <SteveA> jblack: one reason people may not have added anything is that it is not clear where one should add things. 
[08:43] <kiko> sabdfl, wikiname.py? how many interfaces will live in it? sounds rather specific
[08:43] <debonzi> sabdfl, may be one file for this stuff whould be nice.. like persondata.py 
[08:44] <sabdfl> debonzi: separate files are easier to find
[08:44] <SteveA> jblack: you could remedy this by having a page where you encourage people to just add stuff -- better to add it in the wrong place than to not add it at all 
[08:44] <sabdfl> and revision control is easier if files are smaller and focused on specific things
[08:44] <jblack> I gotcha. So a short "Welcome, please hack" paragraph on the front page? 
[08:44] <SteveA> jblack: you can remove that page once the wiki has some more structure and content
[08:44] <BradB> jblack: That's the critical one, for me. There are other things I can think of, but from an OS X user's perspective they're petty compared to the speed problem (and they're probably already listed on the cited ArchWarts page)
[08:44] <jblack> Telling people that they're welcome to hit the structure.
[08:45] <BradB> jblack: The speed thing is the one that makes tla/arch unusable on OS X, let's put it that way.
[08:45] <jblack> bradb: How much can I get a cheap osx box for? 
[08:45] <jblack> (contradiction in terms asside) 
[08:45] <BradB> Hm, they're not cheap. :)
[08:45] <jblack> Ok. Are you doing anything to work around the issue?
[08:46] <debonzi> sabdfl, right, I'll put then in separated files... thanks
[08:46] <jblack> Such as setting up a crontab to populate your library while you're sleeping? 
[08:46] <SteveA> jblack: I don't think that would work, as that assumes people want to think about structure.  That's your job.  Perhaps just add two pages "ArchProblems" and "ArchImprovements" and text "Why not add your comments to ArchProblems and ArchImprovements"
[08:46] <sabdfl> debonzi: great
[08:46] <SteveA> jblack: that way, there's a clear place to put 90% of the comments
[08:46] <jblack> SteveA: Ok. Good advice. 
[08:46] <jblack> I'll do that today.
[08:46] <SteveA> great
[08:47] <BradB> jblack: well, I have to try to time things right, but there's not too much i can do about it other than minimizing the amount i star-merge per day. i could annoy other people to check in my changes, but that's no help to anyone, i don't think.
[08:47] <jblack> (btw, thanks) 
[08:47] <kiko> I had thought of persondata as well.. 
[08:47] <kiko> but really, the file can grow up to a couple hundred lines, it's not a problem.
[08:48] <jblack> bradb: Ok. When you have free time (I presume you're busy), do some vmstats (or equivilant) for me while arch is bottlenecked? 
[08:49] <BradB> I could send you the output of fs_usage.
[08:49] <jblack> Sounds good. That way, I have an idea of how far the ide bus is going before it sops out.
[08:51] <BradB> I'll send one later today then, the next time I star-merge (and for tla changes, which takes a lot of time too...tla commit takes a long time too, but not as bad as tla changes and tla star-merge)
[08:52] <jblack> Are you mirroring rocketfuel locally? 
[08:53] <jblack> Between mirroring rocketfuel locally, and using greedy, sparse revision libraries, we could probably speed you up *quite* a bit
[08:55] <BradB> I've got the revision library configured like that already. I don't think local mirroring of rf would add much, since the network isn't the bottleneck (I don't think.)
[08:56] <SteveA> https://wiki.canonical.com/LaunchpadPageTests
[08:56] <BradB> woo
[08:57] <jblack> Hmmm. Is there an ssh for OSX? 
[08:58] <BradB> Yes. :)
[08:58] <Kinnison> BradB: did you do a SourcepackagePublishing and PackagePublishing SQLObject in the end?
[08:58] <BradB> Kinnison: Nope, I was only writing SQLObjects that I needed.
[08:58] <jblack> Ohhh. so perhaps with enough begging and bribery, I could look at this problem more closely without shelling out X*10^y 
[08:58] <Kinnison> BradB: okies; I'll write 'em now then :-)
[08:59] <SteveA> "without shelling out X*10^y", but nonetheless shelling out
[08:59] <limi> :D
[08:59] <Kinnison> sabdfl: is canonical.launchpad.database.publishing a good place for SourcepackagePublishing and PackagePublishing classes?
[08:59] <limi> secure shelling out
[08:59] <jblack> Hey! That's a valid equation! 
[08:59] <BradB> jblack: Yeah, we could look into that...is this something you're interested in doing a bit on the weekend?
[08:59] <jblack> BradB: Sure. I work weekends usually.
[09:00] <BradB> jblack: What TZ are you?
[09:00] <jblack> GMT-4
[09:00] <BradB> sweet
[09:00] <BradB> i'm GMT-5
[09:00] <jblack> (but I'm a nyteowl)
[09:00] <BradB> ah
[09:00] <sabdfl> Kinnison: perfect
[09:01] <Kinnison> sabdfl: coolie; off I go to smoke the SQLObject pipe
[09:01] <jblack> bradb: Yeah, if you're using greedy nonsparse revision libraries, then locally mirroring wouldn't make a big difference.
[09:01] <Kinnison> sabdfl: and you want the files 'tla add'ed rather than with arch ids?
[09:01] <jblack> Actually, it could still help
[09:02] <sabdfl> yes please Kinnison
[09:03] <limi> "<jblack> Hmmm. Is there an ssh for OSX?" - it's BSD, dude ;)
[09:03] <BradB> jblack: What would be a good time on Saturday to revisit tla/arch OS X optimization?
[09:04] <jblack> When's good for you? 
[09:04] <jblack> You pick a time, and I'll be there. :) 
[09:04] <BradB> Mmm...maybe 10:00 (GMT-5) to at least get you setup to login here.
[09:04] <BradB> as in 10:00 AM ;)
[09:04] <jblack> Ok. Thats 11am here. Its a date.
[09:05] <jblack> You bring the flowers, I'll bring the skirt. =)
[09:05] <BradB> Sure, I'll bring the wine.
[09:05] <BradB> haha
[09:09] <Kinnison>     # XXX Mark Shuttleworth 08/10/04
[09:09] <Kinnison> ....
[09:09] <Kinnison>     #     remove after 16/20/04
[09:09] <Kinnison> lib/canonical/launchpad/interfaces/person.py
[09:09] <jblack> lol
[09:09] <jblack> 16/20, eh? 
[09:09] <Kinnison> that mythical 20th month
[09:16] <Kinnison> BradB: you did do a SourcepackageRelease though yes? (or was is SourcePackageRelease ?)
[09:17] <sabdfl> SourcepackageRelease till further notice
[09:17] <Kinnison> sabdfl: why blushing?
[09:17] <dilys> New bug 2103 for Launchpad/Launchpad: links on Launchpad tabs/footer have bad contrast with background
[09:17] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2103
[09:17] <BradB> it's SourcePackageRelease right now
[09:18] <Kinnison> BradB: Hmm, it *ought* to be SourcepackageRelease :-(
[09:18] <Kinnison> BradB: the capitalisation is on conceptword. Sourcepackage is one conceptword
[09:19] <BradB> Yeah, I know...the concept thing seemed incorrect though.
[09:19] <BradB> Feel free to name it back, if you guys want to.
[09:19] <daf> I prefer WordWord
[09:19] <BradB> WordWord is canonical.
[09:20] <Kinnison> ConceptwordConceptword is Canonical though :-)
[09:20] <Kinnison> (sic)
[09:20] <BradB> And very ambiguous
[09:20] <Kinnison> Not my decision ultimately :-)
[09:22] <SteveA> sabdfl: I've worked out how to fix the "hiding deep exceptions" problem upstream.  Message to jim and zope3-dev list bcc-ed to launchpad list, in case you are (or anyone else is) interested
[09:24] <sabdfl> SteveA: awesome! thanks!
[09:24] <sabdfl> Kinnison: i agree on the ambiguity so will have it changed to SourcePackageRelease in due course
[09:24] <sabdfl> am just holding off on that one for the moment because i think it's something that could be done in one patch when things have settled a bit
[09:24] <sabdfl> the moving around needs to get done now
[09:25] <Kinnison> sabdfl: Okay; I'll plan to have to change when you do it
[09:25] <sabdfl> Kinnison: np
[09:27] <Kinnison> All my RAM are belong to postgresql :-(
[09:29] <BradB> SteveA: You verified that a failing test causes the merge request to fail, right?
[09:33] <BradB> Hm, seems like the problem may be that make check failed on trying to reinit the DB (as told by the error message: AssertionError: 512 != 0)
[09:34] <SteveA> hmm
[09:35] <BradB> I think it has to do with createlang; just a guess.
[09:35] <BradB> I always comment that part out of the Makefile, then uncomment it back when I go to commit
[09:35] <SteveA> which part?
[09:36] <BradB> Lines 24-30 that install plpython
[09:36] <SteveA> in lib/canonical/launchpad/ftests/test_pages.py, line 26,
[09:36] <SteveA> copy that line, comment out the original, and amend the copy so that it isn't sending everything to /dev/null
[09:37] <SteveA> then try re-submitting the merge request
[09:37] <SteveA> it should give you more information as to why it won't merge
[09:37] <BradB> That's not a problem I was having.
[09:37] <SteveA> if there's a problem with setting up the database
[09:37] <BradB> The problem was just that I star-merged, then I had failing tests.
[09:37] <SteveA> um
[09:37] <SteveA> I'm confused 
[09:37] <BradB> (i.e. all locally)
[09:37] <SteveA> I thought you were saying that pqm wouldn't merge for you
[09:38] <BradB> Nope, just that I star-merge and have failing tests now.
[09:38] <SteveA> if you star-merge into your tree, then you could well have failing testes
[09:38] <SteveA> um, tests
[09:38] <BradB> how?
[09:38] <BradB> mm, yeah, i get it
[09:38] <BradB> n/m
[09:38] <SteveA> because you don't necessarily have what is in rocketfuel
[09:38] <SteveA> k
[09:39] <SteveA> I must go home and get some food and sleep.  Want to start early tomorrow. 
[09:39] <SteveA> night all.
[09:39] <BradB> see ya tomorrow, bright and early! (for me, at least)
[09:40] <sabdfl> night SteveA
[09:44] <sabdfl> --- orig/lib/canonical/launchpad/interfaces/bugassignment.py
[09:44] <sabdfl> +++ mod/lib/canonical/launchpad/interfaces/bugassignment.py
[09:44] <sabdfl> @@ -7,6 +7,8 @@
[09:44] <sabdfl>  from zope.app.form.browser.interfaces import IAddFormCustomization
[09:44] <sabdfl>  from canonical.lp import dbschema
[09:44] <sabdfl> +from canonical.launchpad.vocabularies.dbschema import BugStatusVocabulary, \
[09:44] <sabdfl> +     BugPriorityVocabulary, BugSeverityVocabulary
[09:44] <sabdfl>  class IProductBugAssignmentContainer(Interface):
[09:44] <sabdfl>      """A container for IProductBugAssignment objects."""
[09:44] <sabdfl> @@ -37,9 +39,9 @@
[09:44] <sabdfl>      id = Int(title=_('ID'), required=True, readonly=True)
[09:44] <sabdfl>      bug = Int(title=_('Bug ID'), required=True, readonly=True)
[09:44] <sabdfl>      product = Choice(title=_('Product'), required=True, vocabulary='Product')
[09:44] <sabdfl> -    bugstatus = Choice(title=_('Bug Status'), vocabulary='BugStatus')
[09:44] <sabdfl> -    priority = Choice(title=_('Priority'), vocabulary='BugPriority')
[09:44] <sabdfl> -    severity = Choice(title=_('Severity'), vocabulary='BugSeverity')
[09:44] <sabdfl> +    bugstatus = Choice(title=_('Bug Status'), vocabulary=BugStatusVocabulary)
[09:44] <sabdfl> +    priority = Choice(title=_('Priority'), vocabulary=BugPriorityVocabulary)
[09:44] <sabdfl> +    severity = Choice(title=_('Severity'), vocabulary=BugSeverityVocabulary)
[09:44] <sabdfl>      assignee = Choice(title=_('Assignee'), required=False, vocabulary='Person')
[09:44] <sabdfl> hmmm
[09:44] <sabdfl> i thought we decided to do these all using 'names' instead of direct imports and class references?
[09:45] <BradB> I just fixed those vocab bugs
[09:45] <BradB> They're meant to be used directly
[09:45] <BradB> Because they're not factories.
[09:45] <BradB> Thus the directive isn't appropriate.
[09:46] <sabdfl> ok
[09:46] <sabdfl> this makes circular imports a lot harder to resolve
[09:46] <sabdfl> is there a way to get these vocabularies "named"?
[09:47] <BradB> I think they'd need to be made things that produce vocabularies (i.e. factories), rather than actually being vocabularies.
[09:48] <BradB> I can look into this, but since these changes just removed some regression bugs from Malone, it might be spinning our wheels to worry about now.
[09:48] <sabdfl> ok
[09:48] <sabdfl> what was that foo to run the page tests again?
[09:48] <BradB> make check
[09:48] <sabdfl> oh!
[09:48] <BradB> :)
[09:48] <sabdfl> doesn't that run all of the tests? Or just the page ones
[09:49] <BradB> Just the page tests, I think.
[09:49] <SteveA|way> just the page tests (for now)
[09:49] <SteveA|way> we should have a make pagetests just for page tests I guess
[09:49] <sabdfl> hmm... and does it print something useful if a test fails?
[09:49] <BradB> yes
[09:49] <sabdfl> just hummed and then stopped
[09:49] <sabdfl> cool!
[09:49] <BradB> it prints nothing if all went well
[09:50] <sabdfl> merge time!
[09:50] <sabdfl> s'fast, too
[09:50] <sabdfl> good work SteveA|way
[09:51] <SteveA|way> "make check" is run by pqm.  It relies on exit code being non-zero for a problem.
[09:51] <SteveA|way> there's a few more things I want to add to make pagetests nicer to run
[09:51] <sabdfl> am nearly ready to hand doap over to spiv
[09:51] <sabdfl> promise
[09:51] <SteveA|way> like, being able to run a particular page test, and have all "earlier" ones run first for you
[09:51] <SteveA|way> remember voltaire!
[09:51] <SteveA|way> "the best is the enemy of the good"
[09:57] <Kinnison> the naming conventions in canonical.launchpad.database.distro are abysmal
[10:08] <kiko-afk> Kinnison, yeah, needs to be cleaned up outright
[10:08] <Kinnison> kiko-afk: If I did that as part of this massive db patch I'm doing would that be good?
[10:09] <Kinnison> kiko-afk: it's internally inconsistent even
[10:09] <Kinnison> E.g. class Release [distrorelease]  and class SoyuzDistroArchRelease [distroarchrelease] 
[10:09] <kiko-afk> Kinnison, ideally separate -- and the Soyuz* is stuff still needing cleanup.
[10:12] <Kinnison> kiko-afk: bum; I'll work around this mess for now then
[10:13] <kiko-afk> SoyuzFoo is leftovers
[10:13] <kiko-afk> cprov, debonzi should be moving that out in short notice
[10:14] <Kinnison> cool
[10:19] <BradB> s,needed,needing,
[10:21] <carlos> dinner time
[10:21] <carlos> later
[10:22] <Kinnison> kiko: Any chance tidying distro.py could be made a priority? I'm kinda stuck right now :-(
[10:23] <kiko> yeah.
[10:23] <kiko> cprov?
[10:27] <daf> spiv: around?
[10:38] <kiko> Kinnison, I need to get hold of cprov, but I will
[10:40] <cprov> here
[10:42] <cprov> Kinnison: Can you specify again what you want in distros.py ?
[10:54] <Kinnison> cprov: Soyuz* needs cleaning up
[10:54] <Kinnison> Release needs calling DistroRelease
[10:54] <Kinnison> etc.
[10:54] <Kinnison> basically naming the classes after the tables :-)
[10:54] <Kinnison> cprov: So I stand a chance of joining the publishing stuff in properly
[10:57] <Kinnison> cprov: are you good to do that?
[11:00] <cprov> Kinnison: not today, but I can give it high priority for tomorrow, is it ok for you ?
[11:01] <dilys> Bug 2102 resolved: Go away with ikiko.py and dkiko.py
[11:01] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2102
[11:03] <kiko> thanks cprovo
[11:05] <Kinnison> cprov: should be okay. I'm kinda blocked on testing any of this code until I can instantiate the objects though :-)
[11:05] <BradB> daf: ping
[11:06] <BradB> Or, well, anyone really:
[11:06] <BradB> I'm trying to generate a functional doctest for /foo
[11:06] <BradB>  /foo is protected, and I'm already auth'd on port 9000
[11:06] <BradB> So I start recording, and go to /foo, then ^C to stop recording and write the test
[11:07] <limi> whee, SearchWidget spec complete
[11:07] <limi> e.org/Members/limi/tests/ubersearchwidget
[11:07] <BradB> But then, the test always fails, with results like this:
[11:07] <limi> argh
[11:07] <BradB> Differences (unified diff with -expected +actual):
[11:07] <BradB>     @@ -1,4 +1,3 @@
[11:07] <BradB>      HTTP/1.1 200 Ok
[11:07] <BradB>     -Connection: close
[11:07] <BradB>      Content-Length: 9119
[11:07] <BradB>      Content-Type: text/html;charset=utf-8
[11:07] <limi> http://plone.org/Members/limi/tests/ubersearchwidget
[11:07] <BradB> What's the deal with Connection: close there?
[11:11] <daf> BradB: pong!
[11:11] <dilys> New bug 2104 for Project Admin/General: early response from PQM
[11:11] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2104
[11:11] <BradB> daf: any idea on the above problem?
[11:12] <daf> that's an interesting one
[11:12] <daf> is the authentication gubbins included properly in the request?
[11:12] <BradB> yes
[11:12] <BradB> i don't that's related
[11:12] <BradB> i get all the output back correctly
[11:12] <BradB> the /only/ thing that's different is that Connection: header
[11:13] <BradB> why does it say "close the connection" to the proxy, but doesn't do so in the test? hmm..
[11:14] <daf> interesting
[11:15] <sabdfl> limi: neat work
[11:15] <limi> thanks
[11:15] <sabdfl> the "select" buttons could be links instead of buttons?
[11:15] <daf> BradB: so Zope is saying "Connection: close" to the proxy, but not when the test is running?
[11:15] <BradB> yes
[11:15] <limi> of course
[11:15] <limi> this is just a minimal spec
[11:15] <limi> the layout isn't finalized
[11:16] <limi> it probably won't look like this
[11:16] <limi> I just used existing elements to illustrate
[11:16] <limi> will take a while to implement properly, but is very reusable
[11:17] <sabdfl> great
[11:17] <limi> should work for any large set of objects and selection of one or more of them
[11:17] <daf> two possilbities come to mind: (1) ftesting.zcml is affecting Zope's use of "Conenction: close", (2) the TCP proxy affects Zope's use of the header somehow
[11:18] <daf> SteveA seems like the person to ask, but I'll wager he's retired for the night
[11:18] <BradB> yeah, I'll have to bug^Wask him tomorrow, I guess
[11:18] <daf> or file a bug tonight
[11:18] <BradB> Even better.
[11:19] <daf> go for it
[11:20] <dilys> Bug 2036 resolved: Rosetta database classes should be moved to canonical.launchpad.database
[11:20] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2036
[11:22] <BradB> daf: Where's the correct place to report this sort of thing though? In our Bugzilla, or in Zope Corp's? The latter seems like the obvious choice, but maybe there's a policy used here that I'm not aware of, that says I should use our Bugzilla.
[11:22] <BradB> But then, it's using Steve's script too...urgh.
[11:22] <daf> convention is that we file bugs in our Bugzilla, and the appropriate person takes it upstream if it's appropriate
[11:23] <BradB> oh, ok
[11:23] <daf> so SteveA is our interface to Zope, Spiv our interface to SQLObject and SQLOS, etc.
[11:37] <dilys> New bug 2105 for Launchpad/Launchpad: Functional doctest generator adding "Connection: close" header
[11:37] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2105
[11:38] <spiv> daf, BradB: Hmm, I'm a bit confused about why the page doctests even care about the headers?
[11:39] <daf> they are potentially very significant
[11:39] <daf> most headers aren't, of course
[11:40] <spiv> Well, I guess it's a functional test, but it feels a bit funny to me to be testing HTTP like this as well... it means the tests are fragile if the headers are reordered, for instance.
[11:40] <spiv> Right, things like Content-type matter.
[11:40] <BradB> The response code matters too :)
[11:40] <spiv> BradB: True :)
[11:41] <daf> BradB: good point
[11:41] <Kinnison> spiv: Can you look over my patch to the librarian (merged already) and let me know if it's really horrible?
[11:41] <spiv> Kinnison: Ok :)
[11:41] <Kinnison> spiv: mail me direct if there's anything negative to say. Feel free to praise me on lists if it's good :-)
[11:41] <spiv> I think it's partly that I'm used to thinking about trying to test the smallest possible unit of functionality, and that's not what functional tests are about :)
[11:42] <spiv> Heh.