[12:00] <sabdfl> the one(s)  that also have overrides and other tables...
[12:01] <sabdfl> i'm trying to keep files to have t-4 closely related classes max
[12:01] <sabdfl> 1-4
[12:01] <Kinnison> oh
[12:01] <Kinnison> I'm going to end up with large numbers of classes for the views Lucille uses for publishing
[12:01] <Kinnison> I'll have to think about how to split them up
[12:01] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: added portlets and images (patch-644)
[12:11] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Fixed the sequence number when reusing the same import object, it should be reset to zero again (patch-645)
[12:31] <ddaa> hey lifeless!
[12:31] <ddaa> hitting a problem I know well with zenity.
[12:33] <ddaa> It seems that "cvs update -p" is sometimes yield corrupt data when the file is a binary file (e.g. a png) but the cvs repo does not sets its keyword expansion to -kb.
[12:34] <ddaa> The corruption translates into a totla.ValidationFailed for several binay files in zenity.
[12:36] <ddaa> lifeless: I had the same problem with texmacs. I had worked around it by adding a judicious -kb in one of the the cvs commands. What are the choices of cscvs regarding keyword expansion. Are you aware of that issue? How do you handle it?
[12:37] <carlos> SteveA: ping
[12:40] <BradB> i want to perform the trivial, 5 second task of committing just one file on a commit. i tla add filename, tla commit -s "something with filename" -- filename, and get: make-changeset-files: file missing from ORIG tree (filename). How do i perform this trivial task with tla?
[12:40] <BradB> i read the relevant part of the wiki, didn't understand was daf's note meant, and just went ahead with the above, but apparently Guessed Wrong.
[12:40] <BradB> s/was daf's/what daf's/
[12:41] <carlos> BradB: I suppose you should add also the id for that file
[12:41] <lifeless> ddaa: we do whatever cvs repo does.
[12:41] <carlos> BradB: from .arch-ids
[12:41] <BradB> carlos: ew, yeah, that sounds like a nasty bug :)
[12:42] <ddaa> iirc the pb is the cvs repo is inconsistent
[12:42] <carlos> BradB: well, you should add the id inside the file, instead of using tla add :-)
[12:42] <BradB> carlos: but hmm, tla tree-lint doesn't show it.
[12:42] <BradB> carlos: ew, no thanks :)
[12:42] <lifeless> if we don't, then there is no way for someone coming across to tell what cvs revision that file patch-level came from.
[12:42] <carlos> uuidgen
[12:42] <ddaa> that would need some testing, but I remember that the problem only appears with the -p option... so regular cvs users never see it.
[12:43] <carlos> BradB: it does not show it because add did the job, you need to add the id file to the commit command
[12:43] <carlos> BradB: so you commit both files at the same time
[12:43] <BradB> ouch, that sounds nasty
[12:43] <ddaa> lifeless: I'm surprised that you never ran into that issue befor.
[12:44] <lifeless> you mean -P or -p
[12:44] <lifeless> ?
[12:44] <ddaa> -p, output to stdout instead of file
[12:44] <lifeless> well, we don't use that at all
[12:44] <lifeless> we talk CVS natively now.
[12:44] <ddaa> you so do
[12:44] <lifeless> its there if we fall back to invoking cvs
[12:45] <ddaa> you are using cvs when talking to remote repos, right?
[12:45] <lifeless> no, native implementation
[12:45] <ddaa> in cscvs/modules/CVS/__init__.py
[12:46] <ddaa> Mhh... that woush explain why my old trustworthy fix did nothing...
[12:46] <lifeless> see getFileRevisionStat in Module
[12:46] <lifeless> what repo is getting corrupted this way ?
[12:46] <ddaa> the one that needed fixing was getFileRevision
[12:46] <ddaa> but as I said that fix does not seem to work anymore...
[12:47] <ddaa> lifeless: zenity, during the sync
[12:47] <ddaa> several changed png file
[12:47] <ddaa> I check that the first one does not have the -kb bit.
[12:47] <ddaa> *checked
[12:49] <lifeless> ddaa: ok, so the first thing would be to (via interactive python, for ease) try getFileRevisionStat on the file and see if that works better
[12:49] <ddaa> How do I know the relevant revision?
[12:50] <ddaa> I know, that's the revision of the file in the cvsworking...
[12:50] <lifeless> well, when did you see the error? at the end ?
[12:50] <ddaa> a fatal error, by definition, is always at the end.
[12:50] <lifeless> during the cross-check phase I mean ?
[12:51] <ddaa> cscvs.cmds.totla.ValidationFailed
[12:51] <lifeless> oh, now thats plain silly
[12:51] <ddaa> I see only one place where that's raised, and that's the cross-check
[12:51] <lifeless> foo.original is caught by tlas .orig matching.
[12:51] <lifeless> thats a BUG
[12:51] <lifeless> ddaa: ok, in which case the revision is just the latest on HEAD - which will be the one in cvsworking
[12:53] <ddaa> I cated both files, and the cvs one has some extra junk at the end.
[12:53] <lifeless> which the tla one lost ?
[12:53] <lifeless> ok. can you try:
[12:53] <lifeless> import CVS
[12:53] <ddaa> No, that looks like premium junk.
[12:53] <lifeless> tree=CVS.tree(cvsworking)
[12:53] <ddaa> that makes gimp complain.
[12:53] <ddaa> etc.
[12:53] <lifeless> so the cvs one is corrupt, not the tla one ?
[12:54] <ddaa> Yeah. Now, lemme check I get the correct one with a plain cvs update...
[12:54] <lifeless> (we are not meant to write to the cvsworking tree at all, that should be what was checked out)
[12:55] <ddaa> My point is that sometimes we do not get what would be checked out by the usual means.
[12:55] <lifeless> yeah, I get that
[12:55] <lifeless> I'm trying to help you track down where the bug is
[12:58] <lifeless> I think we can disable the mode cache completely with the improvements we've had since it was first put in
[12:58] <lifeless> I'm going to test without it..
[12:58] <ddaa> Interesting... plain update and checkout gives the same corrupted crap.
[12:58] <lifeless> right
[12:58] <lifeless> so thats whats in cvs.
[12:58] <lifeless> thats what we bring to tla.
[12:58] <lifeless> so the bug is that we dropped that crap.
[12:58] <ddaa> wait a min,,,
[12:59] <ddaa> ha, mea culpa
[01:00] <ddaa> according to the gimp, the corrupted one is the tla one
[01:00] <ddaa> so the world makes sense again
[01:00] <ddaa> huhu... that might be a discrepancy between the cvstarball and the remote cvs repo...
[01:01] <lifeless> well, for now.. we want tla to accurately represent the cvs tarbal contents.
[01:01] <lifeless> if thats corrupt, its a separate issue.
[01:01] <lifeless> so, you've found a path that leads to data mismatch.
[01:02] <ddaa> that's the fact
[01:02] <lifeless> there are two possibilities that could be happening.
[01:02] <lifeless> 1) the file has a default branch.
[01:02] <lifeless> 2) the data is being mangled
[01:02] <lifeless> lets check one first.
[01:02] <lifeless> is there a 'branch: ...' statement in the log for that file?
[01:02] <ddaa> the data mismatch is some missing bytes at the end of the file, so probably 2.
[01:02] <lifeless> (just run cvs log)
[01:02] <daf> carlos: I'd like to review first
[01:02] <daf> carlos: but you think it's ready?
[01:03] <ddaa> lifeless: nope
[01:03] <ddaa> I mean yes, but it's empty.
[01:03] <carlos> daf: yes
[01:03] <lifeless> in which case its two.
[01:03] <carlos> daf: all tests pass
[01:03] <carlos> daf: I was adding the comments as stub asked me yesterday
[01:03] <lifeless> ddaa: can you now try
[01:03] <lifeless> import CVS
[01:03] <carlos> so it's ready to comment
[01:04] <lifeless> tree=CVS.tree('cvsworkingpath')
[01:04] <cprov> good night all
[01:04] <carlos> just detected a funny bug with the sample data script that will break the sample data when it's regenerated :-(
[01:04] <lifeless> data=tree.getFileRevision(filename, revisionstring)
[01:04] <carlos> potmsgsets are imported after pomsgsets
[01:04] <carlos> and pomsgsets need potmsgsets...
[01:04] <lifeless> file=open(tempname, 'w')
[01:04] <lifeless> file.write(data)
[01:04] <carlos> I will mail now to launchpad about it
[01:04] <lifeless> file.close()
[01:04] <lifeless> and see if that is corrupt
[01:04] <daf> carlos: a bug on your branch or for the main branch or both?
[01:05] <lifeless> then try a second time, but get the data via
[01:05] <ddaa> lifeless: note that my cvsworking, created from scratch by the sync job is clean.
[01:05] <carlos> daf: it's not a bug with our code but with pg_dump
[01:05] <ddaa> That's the content of the tla archive which seems corrupt.
[01:05] <carlos> or the schema's Makefile
[01:05] <daf> carlos: both then?
[01:05] <lifeless> data=tree.module().getFileRevisionStat(filename, revisionstring)[0] 
[01:06] <ddaa> So the bug occured at some point in the past and was not caught. In addition that file has exactly one revision.
[01:06] <carlos> daf: yes
[01:06] <lifeless> sure.
[01:06] <ddaa> ok
[01:06] <carlos> daf: but it's an external bug...
[01:06] <lifeless> look in StorageLayer.py _get and _get_file_with_perms to see the two code paths.
[01:06] <lifeless> I'm /right now/ making that one code path.
[01:06] <daf> carlos: what I wanted to know was which branches it was causing problems on
[01:07] <carlos> daf: only in mine
[01:07] <carlos> because the new table
[01:09] <carlos> daf: all my changes are mirrored now at chinstrap
[01:11] <daf> carlos: cool
[01:11] <ddaa> mh... I do not understand, but I'll do what you ask,
[01:14] <lifeless> I'm /right now/ making that one code path.
[01:14] <lifeless> bah
[01:14] <lifeless> ddaa: so, what I'm asking you to do is to verify which of the two means of getting the file is causing the corruption
[01:15] <ddaa> okay (placing my bets)
[01:16] <lifeless> I'm sure you are right. but we can't easily write a test until we know what the precise cause is.
[01:16] <lifeless> and we sure ain't fixing this without a test.
[01:24] <ddaa> lifeless: I won my bet
[01:25] <ddaa> The answer is "none", the file is correct using both methods.
[01:25] <ddaa> i.e. the file is what is in the cvsworking but not in the tlaworking
[01:25] <lifeless> ok, what do you think is the problem then? because those two methods are how the file gets to tlaworking
[01:26] <ddaa> mh...
[01:26] <ddaa> wait a min, maybe it has been using my fix or something...
[01:26] <lifeless> yeah, please do do it with the untouched code :)
[01:26] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: added a generic way to send mail in LP and the beginnings of event handling for bugs, including notifications going out when a comment is added to a bug (patch-646)
[01:27] <ddaa> lifeless: I have undone, but I'm not absolutely sure I did so before starting python.
[01:27] <lifeless> lol
[01:30] <ddaa> Hehe
[01:30] <ddaa> My fix was indeed correct :-)
[01:30] <lifeless> ddaa: what was your fix ?
[01:30] <ddaa> the problem is with tree.getFileRevision
[01:31] <lifeless> module.getFileRevisionStat's legacy code path probably suffers too
[01:31] <ddaa> add -kb to the cvs update if the name of the file ends in .png
[01:31] <lifeless> oh man
[01:31] <ddaa> There might be better ways...
[01:31] <lifeless> thats not a fix.
[01:31] <ddaa> That was a testing hack...
[01:31] <lifeless> does getFileRevisionStat() work ?
[01:32] <lifeless> if so, we'll change _get to use that
[01:32] <ddaa> It seems too.
[01:32] <lifeless> because that is a fix.
[01:32] <ddaa> *it seems to work
[01:32] <lifeless> ok, please make it use that, in whatever way is easiest.
[01:33] <ddaa> okay.
[01:33] <ddaa> btw, your "native" implementation is a python reimplementation of the cvs client functionality we need?
[01:33] <lifeless> yes
[01:34] <ddaa> routing around damage...
[01:34] <lifeless> written in oxford
[01:35] <ddaa> Well, the 5 imports/day target it still far, but given time they will be assimilated [:-] 
[01:36] <ddaa> I am buildbot of canonical. Resistance is futile. You will be imported. Your specificity will enrich our archives.
[01:37] <ddaa> Ok. Will do tomorrow. Time to sleep.
[03:37] <stub> SteveA: ping
[03:47] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Rename vocabulary -> vocabularies for consistency. Consolidate PackageReleaseVocabulary (patch-647)
[04:00] <stub> BradB: Can you confirm if the latest Makefile changes will keep Limi running for the time being?
[04:14] <BradB> stub: What am I checking? :)
[04:16] <stub> That 'createlang plpythonu' failing won't kill the entire process mainly, and extra points if 'select valid_name('hello')' doesn't blow up.
[04:33] <BradB> The former seems to work okay; how do I test the latter?
[04:34] <BradB> launchpad_test=> select valid_name('hello');
[04:34] <BradB> ERROR:  function valid_name("unknown") does not exist
[04:34] <BradB> HINT:  No function matches the given name and argument types. You may need to add explicit type casts.
[05:03] <stub> Poo
[05:15] (dilys/#launchpad) Merge to rocketfuel@canonical.com/cscvs--devel--1.0: fix occasional data corruption due to cvs stdout being broken (patch-34)
[05:37] <stub> Bah.... works here :-(
[09:00] <SteveA> stub: ping
[09:01] <SteveA> or rather, pong
[09:01] <stub> Yo.
[09:02] <stub> I was just wondering if you knew how to extract the source code of a function off the top of your head
[09:10] <stub> thefunction.func_code.co_firstlineno and thefunction.func_code.co_filename get me most of the way there
[09:11] <stub> (in fact, all of the way in my use case, but there might be a nicer way)
[09:24] <SteveA> don't know what else you can do
[09:24] <SteveA> I just took a skim through the code to apidoc, but that doesn't do anything fancy
[09:25] <SteveA> hmm
[09:25] <SteveA> inspect module
[09:25] <SteveA> http://docs.python.org/lib/inspect-source.html
[09:25] <SteveA>  getsourcelines(  	object)
[09:25] <SteveA>     Return a list of source lines and starting line number for an object. The argument may be a module, class, method, function, traceback, frame, or code object. The source code is returned as a list of the lines corresponding to the object and the line number indicates where in the original source file the first line of code was found. An IOError is raised if the source code cannot be retrieved. 
[09:25] <SteveA> 
[10:17] <sabdfl> morning all
[10:19] <lulu> alentlesstramps
[10:20] <sabdfl> thanks lulu, hope you don't really feel that way about us
[10:21] <sabdfl> thomming continues apace
[10:21] <stub> SteveA: Excellent
[10:48] <SteveA> looking at that api gives me an idea for improving pages for exceptions in launchpad
[10:50] <SteveA> unless that's what you're doing evil stub
[10:52] <stub> SteveA: Nope. I'm looking at creating data vaidation functions and database constraints from the same source.
[10:55] <SteveA> ok,  thanks for the idea anyway
[11:09] <carlos> morning
[11:11] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Give external bug watches some luvin' (patch-648)
[11:13] <SteveA> carlos: you pingged earlier
[11:14] <carlos> SteveA: it was yesterday night, don't worry, I was able to talk with daf so I don't need to ask you anything now :-)
[11:16] (spiv/#launchpad) SteveA: As far as improving exception pages in launchpad, there's also cgitb.
[11:33] <sabdfl> do we have a favicon?
[11:34] <sabdfl> stub: do you overlap with bradb usually?
[11:37] <stub> Not sure - recenly I've been online for loong hours so I've seen him around. Not sure if we will meet now I'm trying to get back to more sane working hours.
[11:38] <sabdfl> i'd like to have a malone update meetng today, could you holler if you notice you are both online at the same time?
[11:41] <SteveA> a good way to arrange it in future is to ask Brad to be at a meeting that is early in his timezone, say 1100 UTC or 1200 UTC 
[11:41] <stub> I think Brad went to bed about 5 hours ago, so he might get online in about 4 hours or so.
[11:42] <stub> Indeed - arranging in future is good.
[11:42] <SteveA> talking of which, how does Friday sound for a launchpad general meeting?
[11:43] <stub> Don't care - just tell me when
[11:50] <sabdfl> SteveA: sounds good
[11:52] <sabdfl> SteveA: favicon, should i add one?
[11:54] <SteveA> sure.  I'm not sure what the rules are for looking up a favicon.
[11:54] <SteveA> do we need one in the root of launchpad (to stop it complaining), and then favicons for each application?
[11:54] (spiv/#launchpad) SteveA: The rules are browser dependent, but generally something like this:
[11:54] <SteveA> are the pages supposed to have a <link> element in the header refering to the favicon? (I recall reading that somewhere)
[11:54] (spiv/#launchpad) If there's a <link rel="shortcut" ...> in the <head>, use that.
[11:55] <sabdfl> lifeless, bob2: ping
[11:55] (spiv/#launchpad) Otherwise, guess at /favicon.ico (i.e. the top-level of the domain).
[11:56] (spiv/#launchpad) The open source browsers at least are happy with .png files as favicons, I'm not sure about IE.
[11:56] <sabdfl> we need to add one at /favicon.ico
[11:56] <SteveA> hmm, actually, it isn't wholey straightforward to add an image as a view in zcml
[11:56] <SteveA> I'll add favicon to today's todo list.  sabdfl: do you have an image you'd like to use?
[11:57] (spiv/#launchpad) sabdfl: Wouldn't adding a <link rel="shortcut" ...> to our HTML header be sufficient?
[11:57] <sabdfl> spiv: don't think that will catch every browser. we should do both
[11:57] (spiv/#launchpad) sabdfl: Yeah, both is probably best.
[11:58] <sabdfl> guys, the arch-tag thing is a mess, please don't create any new ones
[11:59] <SteveA> you mean, carlos doing a bunch of work on a branch?
[11:59] <carlos> :-?
[12:00] <SteveA> ah -- using arch-tag: in files rather than tla add
[12:00] <SteveA> carlos: getting stuck on a branch is a mess for different reasons ;-)
[12:01] <SteveA> jblack: ayt?
[12:01] <carlos> SteveA: :-D
[12:05] <SteveA> ddaa: I think I may have asked this before, but is there a reasonable way of converting files that contain an arch-tag: line into having their identifier managed by tla in its metadata files?
[12:05] <ddaa> SteveA: No.
[12:06] <ddaa> taglines and explicit tags use distinct namespaces.
[12:06] <sabdfl> ddaa: is there a way we can get pqm to reject commits that use arch-tag for new files?
[12:07] <SteveA> ddaa: so, we'd have to essentially remove them and then add them again, losing history?
[12:07] <ddaa> sabdfl: I can imagine a shell script doing that.
[12:07] <sabdfl> SteveA: seems so
[12:07] <ddaa> SteveA: correct, or patch tla.
[12:07] <sabdfl> so best bet is to grandfather the existing ones and prevent checkins of new ones
[12:08] <ddaa> I'm not sure would would be the right way to do it. There has been discussion for a feature to go explicit->tagline but not to go the other way around.
[12:08] <carlos> breakfast time, see you later
[12:09] <ddaa> TBH I find that a surprising requirement, I find taglines are more convenient.
[12:09] <SteveA> there are 120 files in launchpad using arch-tag
[12:10] <SteveA> ddaa: http://manifesto.gnuarch.org/moin.cgi/ArchWarts
[12:10] <ddaa> They are more robust in many way. The only issue is when copying files, but that requires a deliberate user action and generally is accompanied by a lot of editing, so changing the tagline in the new file is not a big burden.
[12:11] <SteveA> my problem with it is having two ways of telling arch about a file
[12:11] <SteveA> so, whenever I need to move a file, or copy a file, I first need to look inside it to see if it has an arch-tag
[12:11] <SteveA> it is one more thing to have to remember
[12:12] (spiv/#launchpad) Doesn't "tla mv" do the right thing either way?
[12:12] (spiv/#launchpad) Copying a file is obviously a problem, though :)
[12:12] <SteveA> tla rm certainly doesn't
[12:12] <SteveA> see ArchWarts
[12:13] <ddaa> tla inventory -s --ids | cut -d "`echo -e "\t"`" -f2 | grep ^i_
[12:13] <ddaa> mhhh a bit more...
[12:14] <ddaa> tla inventory -s --all --ids | cut -d "`echo -e "\t"`" -f2 | grep ^i_
[12:15] <ddaa> will show all ids generated by taglines, and exit1 if none are found.
[12:16] <ddaa> Okay I looked at archwarts...
[12:16] <SteveA> I just added a new wart
[12:16] <ddaa> the tla rm problem is indeed annoying
[12:17] <ddaa> but if you people can bear with it a little bit, it can be easily worked around in a wrapper, and it should certainly be fixed in tla.
[12:17] <ddaa> at least, it should be fixed in tla imho.
[12:18] <ddaa> about the wrapper, bob2 should open hct for testing by the arch team soon, so if you can suffer the issue a bit longer, we could work around it in hct (if not already done)
[12:18] (spiv/#launchpad) The output of "tla rm -H" implies that it should work.
[12:18] (spiv/#launchpad) So if it doesn't, it is a bug, I think :)
[12:18] <SteveA> either a bug in the docs or a bug in the code
[12:18] (spiv/#launchpad) Right.
[12:20] <ddaa> okay, I can reproduce the pb with tla 1.2rc2
[12:22] <ddaa> Neither fai nor aba work around this one.
[12:22] <ddaa> I dunno about hct. Yet.
[12:22] <ddaa> Now you have all the elements to take a project management decision.
[12:23] <ddaa> And my opinion as an extra.
[12:23] (spiv/#launchpad) ddaa: Wow... so tla doesn't have a test-case for tla rm?  Eek :)
[12:24] <ddaa> tla's test suite is very... limited...
[12:25] (spiv/#launchpad) ddaa: And tom's worried about getting a perfect release process and voting system?  Sheesh.
[12:25] <sabdfl> you can't do releases by vote
[12:26] <ddaa> The voting system is more about governance if I understand correctly.
[12:27] <ddaa> And voters would be co-opted arch devels.
[12:27] <sabdfl> ddaa: i'll be interested to see how it goes
[12:27] <SteveA> how many voters are there?
[12:27] <sabdfl> will you keep me posted?
[12:28] <ddaa> SteveA: dunno, that's probably something like 5 persons... tom, asuffield, lifeless, jblack, abentley, jivera, maybe talli, etc.
[12:28] <ddaa> This information is not authoritative.
[12:29] <ddaa> sabdfl: okay, I've been told it's good to assume new responsibilites :-) But tbh the arch community mess is rather pissing me off those days.
[12:30] <ddaa> sabdfl: I will keep you posted on significant release/governance events in the arch community.
[12:30] <sabdfl> ddaa: thanks
[12:30] <SteveA> ddaa: tom lord is spending time sorting out a voting system for about 7 people to use?
[12:31] <ddaa> SteveA: *shrug* something like that... I have not been following that very closely up to now.
[12:31] <SteveA> how about Thursday, 1200 UTC for a launchpad meeting instead.  (That's tomorrow.)
[12:31] <lulu> SteveA: sounds good to me :o)
[12:32] <ddaa> It has mostly been vapor to this point. I'm waiting for something concrete before making an opinion.
[12:33] <SteveA> in most communities, 7 is easily within the size that you can make decisions by consensus.
[12:33] <ddaa> SteveA: it seems it's difficult to achieve consensus with tom even at two people.
[12:34] <ddaa> Most of the few times I got feedback from him, I classified it as "nonsense or not specific enough to be useful".
[12:35] <ddaa> Even if he often sounds like he has a pretty clear idea of what he means.
[12:35] <ddaa> But I'm not the best kid in town for communication.
[12:35] <ddaa> e.g. I was impressed my lifeless abilities in that dept.
[12:36] <ddaa> In handling the jblack's integration branch crisis.
[12:39] <ddaa> actually, at the time I did not classify the feedback that way.
[12:39] <ddaa> I thought "I'm probably not smart enough to figure out what he means"
[12:40] <SteveA> talking with jim fulton is often like that, but he's always happy to explain further and to listen to other points of view.
[12:41] <ddaa> Since that time my position has changed a bit. Now I consider communication skills essential to project lead, and failure to communicate a blame for the leader.
[12:41] <ddaa> Probably that position is caused by my pissed of state... the right attitude should certainly me something intermediate.
[12:42] <SteveA> communication skills are almost always more important than technical wizardry for a project leader
[12:43] <SteveA> consider the architypal example: linus and the linux kernel
[12:43] <SteveA> I'm sure he knows what he's doing with kernels.  However, his communication to his peers stands out more than his code.
[12:50] <ddaa> "okay, the 2.6 vm system is broken, broken, broken. I'm rewriting it all in one swoop and will do something that works." And indeed that worked...
[12:51] <ddaa> There are several examples like that, when he does what nobody else was able to do...
[12:53] <SteveA> that's more a case of having the knowledge and ability to do it, and also having the time and resources to do it.  Someone else could have done so, if they met the prerequisites, and offered it to linus for incorporation into his tree.
[01:10] <ddaa> Would be nice if you people added your nick and a date when writing to the wiki.
[01:11] <ddaa> The nick is useful to know how to talk to if necessary, and the date is useful to have a clue of how current is the comment. Wiki tend to grow a lot of stale data, timestamping comment make it easier to sort out the current from the ancient.
[01:13] <sabdfl> ddaa: which kernel did he do that for?
[01:13] <ddaa> Mh... nah, that was in the 2.4 series...
[01:14] <sabdfl> SteveA: given that we have a way to list the known arch-tag files, could you add a test to the pre-merge check which barfs on new arch-tag files?
[01:16] <SteveA> sabdfl: I suppose it would have to record not the filenames but the arch-tag ids, because files get moved.
[01:20] <sabdfl> ddaa: problem is that not all files can have an arch tag
[01:20] <sabdfl> so there is inevitable inconsistency
[01:21] <sabdfl> so we will eliminate arch tags
[01:21] <sabdfl> i'm in fascist mode
[01:24] <ddaa> sorry, cannot find the relevant kernel release, it's back before the the earliest data in the lwn search database.
[01:26] <sabdfl> stub: from your latest changes it seems i broke some pages
[01:26] <sabdfl> sorry
[01:26] <sabdfl> would have fixed them if there were page tests
[01:26] <sabdfl> please could you add page tests for the bugtracker pages?
[01:26] <sabdfl> thanks
[01:30] <SteveA> we really should get the arch-tag lines out of the page templates.  it is not nice to serve these things up as comments in the pages' html.
[01:38] <limi> SteveA: do you have time to look at the search/selection widget (making a single-template version now) later, and tell me how we can turn it into a widget? (This one, just without the JS for now: http://plone.org/Members/limi/tests/ubersearchwidget )
[01:39] <SteveA> limi: probably.  mail me when you're done, perhaps
[01:39] <limi> ok
[01:40] <limi> I assume stub knows how to do it too
[01:41] <ddaa> mh... actually it seems my reporting of the kernel history was inaccurate...
[01:41] <ddaa> That was a big merge from the Andrea's Arcangeli's VM work in 2.4.10
[01:42] <SteveA> for some reason, I cannot make a pagetest of .txt / text/plain files.
[01:42] <ddaa> Human memory is tricky like that...
[01:47] (spiv/#launchpad) ddaa: 2.4.9/2.4.10, iirc.
[01:49] <ddaa> http://lwn.net/2001/0927/kernel.php3
[02:09] <limi> SteveA: where is the best place to define (in ZCML) a template that should be globally available (the thing that will become a widget) - I just need to test it with TAL enabled :)
[02:10] <limi> maybe we should have a "testing" dir that uses that attribute of ZCML that we use on images - so that everything there is made globally available inside launchpad?
[02:13] <sabdfl> everything is globally available in launchpad
[02:14] <sabdfl> if it's zcml please put it in lib/canonical/launchpad/zcml/
[02:14] <sabdfl> SteveA: why would tests be failing to merge, when they pass on my machine and i'm fully merged to rocketfuel?
[02:22] <Kinnison> sabdfl: About splitting up publishing.py... I do have concerns that I'll be creating arbitrary divisions without any useful purpose if I start splitting these up. I'm not convinced that I'm going to end up with many more views for publishing (Indeed I expect I may end up with no more at all) so it seems fairly pointless to split the classes out since I'll end up with 'publishing.py' and 'publishingviews.py' or something and it kinda seems od
[02:23] <ddaa> sabdfl: maybe because the configuration of the system running pqm is different than yours. If it's not in the tree, it's outside the tree...
[02:23] <ddaa> *different from yours
[02:28] <Kinnison> feh; sqlobject can't be subscripted
[02:29] <Kinnison> there goes my neat [ rec[x]  for x in columns ] 
[02:38] <limi> how can I get my page just to show up, not associating it with a particular class etc?
[02:38] <limi> daf, SteveA, stub?
[02:40] <stub> You can add them as views on everything - like you would add a page to an object except specify '*' as the interface.
[02:41] <limi> how do I do that? my current ZCML is: http://paste.plone.org/1795
[02:42] <stub> add a 'for="*"' attribute to the page directive
[02:42] <limi> so close ;)
[02:43] <stub> Alteratively, it might be neater to add it only as a view to the root folder (for="IRootContainer" or something - I'd need to look it up)
[02:43] <sabdfl> morning BradB
[02:43] <BradB> sabdfl: hi
[02:43] <stub> yo
[02:43] <sabdfl> while we have you and stud together, can we have a quick malone catch-up and status check?
[02:44] <sabdfl> erm
[02:44] <sabdfl> sorry
[02:44] <sabdfl> slip of the finger
[02:44] <Kinnison> sabdfl: is there something you're not telling us about you?
[02:44] <BradB> sabdfl: The email notifications are working, but they aren't all working yet (because there's about 16 that have to happen.)
[02:44] <sabdfl> BradB: is there a standard way to send email to a person in launchpad?
[02:45] <BradB> The thing that hung me up last night was displaying the "title" of fields that are from vocabs. i.e. I don't want the email to say "Status: 1", I want it to say "Status: New".
[02:45] <stub> So we are using events for the email notices? (I had been toying with the idea of using triggers to fill the audit log, and a cron job to send the emails but it was going to get real messy...)
[02:45] <BradB> sabdfl: Yes, I wrote something yesterday for that.
[02:45] <BradB> stub: Yes.
[02:45] <stub> BradB: There is a bug in bugzilla for that - SteveA was going to implement if for Limi a last week...
[02:46] <BradB> The one other thing that was non-obvious to me was how to hook into edits
[02:46] <BradB> Adds are easy, of course, because you just publish an event in the factory.
[02:46] <stub> Oh... hang on - I think you can do that one right now.
[02:51] <BradB> stub: what's the bug number?
[02:53] <stub> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2101
[02:53] <stub> (Although this is for TAL... don't know if it is appropriate for your email stuff?
[02:54] <BradB> nope, I know about the TAL stuff. I need an equiv for plain Python code.
[02:57] <BradB> SteveA: Can you remind me what the ":" says in foo/bar/lp:BugStatus? I seem to remember it having something to do with adaptation.
[02:57] <BradB> It might give me a hint about how I achieve the same thing in plain Python.
[02:58] <stub> BugSeverity.items[10] .title
[02:59] <BradB> ah
[02:59] <stub> With tests in canonical/lp/test_dbschema.py for examples
[02:59] <BradB> I noticed that items attrib last night, but didn't expect it would do that.
[03:00] <stub> I've forgotten why it was necessary - I think it might have been because we couldn't define the __getitem__ method on a class, only an instance?
[03:01] <BradB> AttributeError: 'SimpleVocabulary' object has no attribute 'items'
[03:01] <elmo_> stub: drugs are bad, mmkay\
[03:02] <stub> Erm.. you won't have much luck getting it out of a Vocabulary (but you could use it to get the index to put in BugWhatever[x] )
[03:02] <BradB> Ah, I think I'm using the wrong vocab object.
[03:02] <BradB> I want the thing that inherits from DBSchema, I suppose.
[03:02] <BradB> (i.e. the not-vocab object)
[03:02] <stub> Yup
[03:03] <stub> I don't think Vocabularies are much use for anything except sending to the Z3 form machinery... icky interface
[03:04] <BradB> stub: They could be though, with getTerm and getTermByToken. Tried that last night though and got NotFoundError's.
[03:04] (spiv/#launchpad) stub: You can define __getitem__ on a class, it just requires a metaclass...
[03:04] <stub> NA NA NA CAN"T HEAR YOU NA NA NA
[03:05] (spiv/#launchpad) :)
[03:06] <cprov> stub: nice strategy !
[03:06] <BradB> stub: Yeee, that worked, thanks.
[03:06] <ddaa> spiv: ? I just define __getitem__ as plain instance method...
[03:07] <ddaa> What's wrong with that?
[03:08] <stub> The things in dbschema are not instances, they are actually classes (generated on the fly from docstrings, because SteveA is a sick, sick person)
[03:08] (spiv/#launchpad) (pasted example in privmsg, to avoid spamming channel)
[03:18] <ddaa> my opinion is that subscriptable classes are very likely wrong.
[03:18] <ddaa> As I said to spiv, using a metaclass here is just moving the instanciation into the language instead of using explicit code.
[03:19] <BradB> stub: Are you still gonna be around in 2.5-3.5 to test Malone?
[03:19] <BradB> (hours, that is :)
[03:20] <carlos> stub: could you review my db change request from this morning? I need it to continue with my work
[03:20] (spiv/#launchpad) ddaa: The code in question is lib/canonical/lp/dbschema.py in launchpad, if you're curious.
[03:20] <ddaa> I'm curious but I have to focus on imports.
[03:20] <stub> Hopefully not - I'm trying to get back to more normal hours (Nights is fine for a while, but then it really starts to drag...)
[03:20] <sabdfl> SteveA: any progress on zwiki moin format support?
[03:21] <sabdfl> our wiki is exploding and will get more and more difficult to integrate
[03:21] (spiv/#launchpad) ddaa: :)
[03:22] <sabdfl> stub, bradb, i'm sucked into the release vortex (announcement in 40 minutes) so am unlikely to be able to meet properly
[03:22] <sabdfl> sorry
[03:25] <BradB> stub, sabdfl: What plan is there for moving this to the dogfood server? We could do so now, but just not all the notifications are implemented yet (that's what I'm planning to finish off over the next few hours.)
[03:25] <sabdfl> "this"?
[03:26] <BradB> Malone. :)
[03:26] <stub> Plan?
[03:26] <BradB> heh
[03:26] <BradB> sabdfl: Is this something that gets decided in the meeting tomorrow morning?
[03:27] <stub> I was thinking we make the soyuz dudes do it since they already have stuff on there :-)
[03:29] <stub> BradB: We should be able to use events to fill the audit table too, shouldn't we?
[03:29] <BradB> yes
[03:29] <BradB> Auditing won't be part of the first dogfooding though, at least, it shouldn't be.
[03:30] <stub> Yup
[03:30] <stub> limi: That .zcml working they way you need?
[03:31] <limi> yup
[03:31] <limi> excellent, thanks
[03:34] <stub> limi: Just try not to pollute the namespace too much :-) If it looks like there is going to be a lot of them, we can do 'context/widgets/searchselection' instead of 'context/widgets-searchselection'
[03:36] <SteveA> sabdfl: I'll ask about ZWiki.  Simon Michael appears to be online.
[03:36] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: added notifications when a bug is assigned to a new product (patch-649)
[03:38] <SteveA> as in "ye olde malone" ?
[03:40] <ddaa> me watches buildbot munching his cpu
[03:40] <limi> stub: yes, it's only one template right now ;)
[03:41] <Kinnison> SteveA: It's commonly accepted that the 'th' digraph represents the thorn character
[03:42] <SteveA> yay -- compose th does it
[03:43] <Kinnison> yep
[03:43] <ddaa> at's fun!
[03:43] (spiv/#launchpad) SteveA: Try Ctrl+Shift+D,E
[03:45] <SteveA> ???
[03:45] <Kinnison> that's another way to compose a thorn character
[03:48] <ddaa> Ho, that Ctrl-shift composition is fun... but really inconvenient on dvorak where d anh e are on different hands.
[03:50] <ddaa> oh... that's a "input that hexadecimal char" chord...
[03:51] <ddaa> Won't input null, though.
[03:52] <morgs> cprov: I have a quick question on the sourceforge api...
[03:55] <ddaa> limi: "mark impersonates me in his spare time"
[03:55] <ddaa> Which is the bugtracker to file "mark has still some spare time"? ;-)
[03:55] <limi> hehe
[03:56] <daf> Kinnison: [ getattr(rec, x) for x in columns ]  ?
[03:56] <Kinnison> daf: yeah
[03:56] <Kinnison> daf: I was there not long after
[03:56] <limi> daf: checking in a new color scheme shortly ;)
[03:56] <Kinnison> daf: not as cute as rec[x]  though
[03:59] <daf> limi: oo
[04:00] <cprov> morgs: hi, say it 
[04:01] <morgs> cprov: hi
[04:01] <morgs> cprov: the project summary you want for the short description: I am getting something into 'description' at the moment.
[04:01] <morgs> cprov: Is that different from what you want?
[04:02] <morgs> cprov: Could you give me an example (URL)?
[04:03] <cprov> morgs: I was think in a real human-typed Sumary, but I'm affraid there isn't something like that in SF
[04:03] <cprov> morgs: let's see ..
[04:04] <morgs> cprov: For example, if you go to http://sourceforge.net/projects/python, you will see a description "The Python programming language, an object-oriented scripting and rapid application development language."
[04:05] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Fixed up the search-selection, made the Launchpad colors be more distinct. (patch-650)
[04:05] <limi> daf: ^^
[04:05] <morgs> cprov: Then if you go: d = sourceforge.getProjectSpec('python','sf') and then d['description'] , then the description is what you get.
[04:06] <daf> limi: great, thanks!
[04:07] <morgs> cprov: A different example: for 'mysql-python', the description is 'MySQL support for Python. MySQL versions 3.22, 3.23 and 4.0; and Python versions 1.5.2-2.3 are supported. MySQLdb is the Python DB API-2.0 interface. _mysql is a low-level API similiar to the MySQL C API. ZMySQLDA is a Database Adapter for Zope.'
[04:08] <cprov> morgs: it is too long for a Short description :)
[04:08] <limi> daf: better?
[04:09] <morgs> cprov: OK, I will look for something better
[04:10] <cprov> morgs: now, i'm just cutting the description in the first "." and using it as shortdesc, but it isn't that good, since in many cases isn't Impacting words 
[04:11] <morgs> cprov: looks like SF doesn't have anything better.
[04:11] <cprov> morgs: for example, looks like python hasn't a good description on SF, this description looks like a good shortdesc
[04:12] <cprov> morgs: yes, it's difficult to fit them without human interaction 
[04:12] <morgs> cprov: OK, I see what you mean. Some projects have short descriptions anyway, and some have long descriptions.
[04:13] <morgs> cprov: Unfortunately the RSS feed doesn't have anything better either.
[04:13] <morgs> cprov: I've got my arch login details now, must set it up. Can we do a run-through on Friday?
[04:14] <BradB> sabdfl, stub: We'll finalize a dogfood server during the meeting tomorrow then; sound good?
[04:14] <cprov> morgs: I see, but, anyway, RSS helps you a look for get the available data in a easy way than parse HTML 
[04:14] <ddaa> cprov: in your ARCH.png, I find the text is almost unreadable small.
[04:14] <daf> limi: it's easier to read
[04:14] <daf> limi: perhaps it's a little bit harsh
[04:15] <cprov> daad: sorry, you can grab a .dia in the same URI
[04:16] <BradB> SteveA: Any update on when the page test generator will be fixed? This continues to cause delays in Malone development, by allowing code to be checked in that breaks things that were already working.
[04:16] <ddaa> cprov: thanks but that was also a suggestion to compress the layout a bit or make the image bigger.
[04:18] <cprov> ddaa: I'll do so ... Do you have any suggestion about the Arch topology itself ?
[04:22] <cprov> morgs: send me an email with some news or questions (if you think necessary), thanks for you good work and good luck with Rocketfuel Setup
[04:22] <morgs> cprov: OK, I'll do that.
[04:22] <cprov> ddaa: please, send me (or LP) an email with suggestions or advices about the ARCH diagram, thank for your help
[04:23] <cprov> time to go ...
[04:27] <SteveA> BradB: write some pagetests by hand, using lots of "..."
[04:27] <SteveA> BradB: at least you can catch errors rendering a page that way
[04:28] <sabdfl> BradB: what's wrong with the page test generator?
[04:30] <sabdfl> cprov: that's not too long for a short description
[04:30] <sabdfl> short description is a single paragraph
[04:31] <SteveA> sabdfl: the page test generator is giving errors on a few pages.  I do not yet know why.
[04:31] <sabdfl> 'k
[04:32] <SteveA> but, this should not prevent writing a simple page test by hand, that just proves that the page exists
[04:32] <BradB> sabdfl: #2105, #2114, #2115, #2116.
[04:33] <sabdfl> BradB: thanks
[04:46] <BradB> SteveA: In some cases, that's ok; in others, it isn't (e.g. it would have prevented the breakage seen in adding source package assignments, but wouldn't have prevented the fact that product release infestations are no longer showing the name of the product, only the version number.)
[04:52] <Kinnison> dir1 == my tree, star-merged up to the top of rocketfuel
[04:52] <Kinnison> dir2 == a fresh 'get' of rocketfuel
[04:52] <Kinnison> there are diffs
[04:52] <Kinnison> (and no; I don't have any unmerged commits)
[04:52] <sabdfl> Kinnison: that's normal
[04:53] <Kinnison> sabdfl: normal enough that I get freaky changes when I try and merge in my other tree?
[04:53] <Kinnison> sabdfl: I'm hitting 'conflicts' when I should be gaining one modification only
[04:53] <sabdfl> not sure, but i'm told it's normal :-)
[04:53] (spiv/#launchpad) Kinnison: It's possible you've crossed the streams...
[04:53] <Kinnison> it's normal to lose diff hunks?
[04:54] (spiv/#launchpad) s/streams/star-merges/
[04:55] <daf> Kinnison: that seems counter-intuitive to me
[04:56] <Kinnison> daf: aye
[04:57] <Kinnison> daf: it's as though I missed some conflicts or something
[04:57] <Kinnison> but the tree linted
[04:58] <daf> if you do a fresh tla get from your archive, does it differ from either of dir1 or dir2?
[05:00] <BradB> Kinnison: maybe it has to do with limi's checkin
[05:00] <BradB> That mixed a merge + adding of something.
[05:00] <BradB> completely random guess though.
[05:00] <Kinnison> daf: I'm just re-doing the merge; then I'll look
[05:06] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Fixed up the search/selection widget, ready for Zopification now. (patch-651)
[05:11] <jblack> stevea: ping 
[05:14] <jblack> bradb: Would you mind if I hit your machine (rather hardly) today? 
[05:14] <jblack> I'd like to strace tla on your box
[05:16] <BradB> jblack: You could over lunch, but that's in about 1 - 1.5 hours. If you want, I can let you know.
[05:17] <jblack> Would it be possible to get more time, if I do it after you go to bed? 
[05:17] <BradB> You can do it 1. over lunch, 2. after about 18:00 - 18:30ish local time
[05:18] <jblack> I'll go with 2, so that I can actually strace a star-merge, library building, etc
[05:18] <jblack> btw, thank you very much for loaning me the account.
[05:20] <BradB> jblack: Sure, no prob. I'll give you the go ahead later today. (by the way, you might find fs_usage to be useful during a star merge.)
[05:20] <BradB> And in OS X, it's ktrace, not strace...we have to be different.
[05:21] <jblack> does fs_usage feel the same as vmstat? I.E. it can print recurring reports? 
[05:23] <BradB> jblack: It just barfs out everything that's going on on the fs. You save it to a log and then write a little script to make something useful out of what it told you.
[05:23] (spiv/#launchpad) BradB: Can I bounce an SQLObject idea off you?
[05:23] <BradB> spiv: sure
[05:23] (spiv/#launchpad) BradB: Should SQLObject.sync do "if self._SO_obsolete: return" before doing anything else?
[05:26] <BradB> spiv: I'd expect sync to sync.
[05:26] (spiv/#launchpad) Or is calling sync on a deleted object a sign that something else is broken?
[05:26] <BradB> That if statement doesn't do a sync.
[05:27] <BradB> hm
[05:27] (spiv/#launchpad) BradB: But if destroySelf has been called, what is there to sync?
[05:27] (spiv/#launchpad) Either sync should check for _SO_obsolete, or I think there's a bug in sqlos's handling of deletes...
[05:29] <BradB> yeah, i can see now that _SO_obsolete means that the object has been deleted; that if statement makes sense then.
[05:30] (spiv/#launchpad) Ok :)
[05:30] (spiv/#launchpad) I guess I should work on a test-case then..
[05:31] <BradB> spiv: I wouldn't if sync()'ing a dead object should raise an exception?
[05:32] (spiv/#launchpad) BradB: Well, that's what currently happens :)
[05:33] (spiv/#launchpad) e.g. sqlobject.main.SQLObjectNotFound: The object ArchNamespace by the ID 27 has been deleted
[05:33] <BradB> yeah, i see the code here now
[05:33] (spiv/#launchpad) Is there anywhere I can look to see where assumptions about this sort of thing are documented? :)
[05:34] (spiv/#launchpad) But I think that exception is more designed to catch errors where someone has issued a DELETE behind SQLObject's back.
[05:35] <BradB> spiv: http://sqlobject.org/docs/News.html#interface-changes seems about as much as you'll find
[05:35] <BradB> ...which isn't much
[05:36] (spiv/#launchpad) Hmm.
[05:36] (spiv/#launchpad) I wonder if there's a seperate bug here.
[05:36] (spiv/#launchpad) Which is that .destroySelf doesn't respect _lazyUpdates.
[05:37] (spiv/#launchpad) Or perhaps that's out-of-scope for _lazyUpdates.
[05:38] <BradB> you mean for cascading deletes?
[05:39] (spiv/#launchpad) I haven't even considered cascading deletes ;)
[05:40] <BradB> i thought you might be meaning that if foo.bar was 1 in the sqlobject, but 2 in the DB, that destroySelf would cascade delete on the 2, instead of the 1.
[05:40] <BradB> otherwise, why does destorySelf care about if the object updates lazily or not?
[05:40] (spiv/#launchpad) I don't think it does.
[05:40] (spiv/#launchpad) I was just thinking stupid thoughts out loud ;)
[05:41] <BradB> heh
[05:42] (spiv/#launchpad) So, as far as I can see, either sync needs to check _SO_obsolete, or sqlos needs to hook destroySelf to unregister the object from the datamanger.
[05:43] (spiv/#launchpad) The former option seems to be less work (a nice simple two-liner).
[05:45] <BradB> spiv: What does it get you by adding that if statement? (Other than being slightly faster, some of the time?) An exception should be raised no matter what, I think.
[05:46] <BradB> (i.e. I get the impression that you're not liking the current, exception-raising behaviour.)
[05:46] <BradB> I think sqlobject has to assume that things might be done behind its back, unfortunately.
[05:47] <BradB> well, no, not unfortunately, but rather because that's the Right Thing
[05:47] <BradB> because a well-known property of storing stuff in a DB is that many different systems can more easily access it
[05:49] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Rewrote the way the suburls work to fix serious bug in it that revealed itself when I added robots.txt files.  Added robots.txt files.  Removed IHasSuburls dead chickens. (patch-652)
[05:50] (spiv/#launchpad) BradB: I'm happy with the test for things behind its back.
[05:50] (spiv/#launchpad) But this isn't behind SQLObject's back.
[05:50] <Kinnison> SteveA: Why are we moving away from arch-tag ?
[05:51] <BradB> spiv: IOW, you're looking for a slightly speed gain, presumably?
[05:51] (spiv/#launchpad) BradB: No.
[05:51] <BradB> a not-exception?
[05:52] (spiv/#launchpad) I'm looking for "Blah.destroySelf()" ... time passes... "transaction ends" to work.
[05:52] <BradB> where a .sync happens during "time passes"?
[05:52] (spiv/#launchpad) .sync happens at "transaction ends".
[05:52] (spiv/#launchpad) As part of committing the transaction.
[05:53] (spiv/#launchpad) sqlos hooks SQLObject.dirty to keep track of things that need syncing.
[05:54] (spiv/#launchpad) But it currently has no way of knowing not to call sync on something that has been destroyed.
[05:54] (spiv/#launchpad) I'm happy to entertain the possibility this is an sqlos problem :)
[05:55] (spiv/#launchpad) It's possible that sqlos should be using the SQLObject connection cache.
[05:55] (spiv/#launchpad) It's possible that sqlos should be using the SQLObject connection's cache of objects, rather.
[05:56] <sabdfl> (16:50:27) elmo_: mark@hbd.com - k3yring
[05:56] <sabdfl> doh
[05:56] <elmo_> LOL
[05:56] <sabdfl> shhh
[05:56] <elmo_> sabdfl: you ARE Thom May, and I claim my five pounds
[05:56] <sabdfl> thom might be looking
[05:58] <SteveA> Kinnison: replied by email, and to the list.
[05:58] <sabdfl> RELEASE ANNOUNCEMENT: Ubuntu 4.10 "The Warty Warthog Release" is DONE!
[05:58] <sabdfl> Read the full announcement at http://wiki.ubuntulinux.org/WartyWarthog_2fFinalReleaseAnnouncement?action=raw
[06:01] <SteveA> "under way" should be "underway"
[06:02] <BradB> spiv: Can this same kind of behaviour be written as a failing unit test against sqlobject itself?
[06:03] <BradB> If not, I'd punt it to Sidnei et al.
[06:05] (spiv/#launchpad) BradB: It can, but I'm not sure the test makes sense :)
[06:06] (spiv/#launchpad) I guess that's really what I'm asking: what is the intended result of "Foo.destroySelf(); Foo.sync()"?
[06:06] <BradB> I'd expect an exception.
[06:06] (spiv/#launchpad) I think I'll mail sqlobject-discuss.
[06:07] (spiv/#launchpad) At the very least, destroySelf could use a more useful docstring that "# Kills this object.  Kills it dead!" :)
[06:08] <Kinnison> SteveA: thanks for that
[06:08] (spiv/#launchpad) Thanks for your help.
[06:19] <BradB> spiv: hehe, no prob. :)
[06:24] (spiv/#launchpad) BradB: Thinking about it a little more, I'm inclined to think that the SQLObject behaviour is reasonable.  I've mailed the list anyway, to be certain.
[06:26] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: added another half dozen or so notifications for things that are added to bugs (e.g. a product release infestation.) (patch-653)
[06:29] <limi> SteveA: did the shorthand for "add everything in this directory as a resource" in ZCML make it into Zope 3?
[06:29] <limi> (or stub, if you know :)
[06:32] <sabdfl> SteveA: am still seeing failure messages to pqm messages when tests run fine on my machine, and am fully merged
[06:32] <sabdfl> any ideas?
[06:34] <limi> the IA64 boxes are here
[06:34] <limi> now I can tell my kids "I touched the Itanium"
[06:43] <limi> false alarm
[06:43] <limi> it was only boring, normal servers ;)
[06:44] <jblack> I heard the itanium can do a three minute egg in two minutes
[06:46] <limi> ooh
[06:46] <limi> gotta get me one of those
[06:46] <limi> think of all the time I will save!
[06:47] <sabdfl> BradB|lunch: thanks for the merge :-)
[06:50] <jblack> limi, when's a good time to steal about 10-15 minutes from you? I'd like to dive into your arch world, and see what's going on with those 7 minute merges
[06:50] <limi> heh
[06:50] <limi> maybe in an hour or so?
[06:51] <jblack> would an hour and a half be ok as well? 
[06:51] <limi> yup
[06:51] <jblack> Ok. Its a deal
[06:51] <limi> I'm not going anywhere ;)
[06:51] <limi> (except for dinner)
[06:51] <limi> you need a login on this box?
[06:55] <sabdfl> BradB|lunch: actually, just as well i had to do it, because I've broken malone/browser.py into ten files and you would have not enjoyed finding the pieces :-)
[06:55] <sabdfl> they are in all the right places, but still
[07:04] <sabdfl> SteveA: what happened to IHasSubURL's?
[07:22] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: restructure malone and doap (patch-654)
[07:47] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Moved stuff around a bit, made the portlets more sexy, lots of CSS tweaks. (patch-655)
[07:49] <kiko> sexy portlets!
[07:59] <limi> yes!
[07:59] <limi> mostly for Malone
[07:59] <limi> icons and fluff
[08:06] <BradB> sounds like i got stuff in just in time. ;)
[08:12] <limi> what, are you suggesting that arch does a less than stellar job with conflicts? ;)
[08:19] <kiko> BradB, you now get invited to barbecues at Jim's place
[08:20] <limi> hehe
[08:20] <BradB> woo
[08:47] <sabdfl> BradB: see my comments above?
[08:47] <sabdfl> malone/browser.py is in database/ and browser/ now
[08:47] <sabdfl> in pieces related to class
[08:49] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Trivial pixel change in the CSS to test the new commit script :) (patch-656)
[08:50] <BradB> sabdfl: Yep, ok, I'm in the midst of star-merging your changes.
[08:58] <kiko> bbias
[09:05] <SteveA> sabdfl: IHasSubURLs is no longer needed for things that have suburls
[09:05] <sabdfl> great!
[09:05] <sabdfl> thanks
[09:06] <SteveA> there was a bug in how it handled certain kinds of pages under certain circumstances.
[09:06] <SteveA> the solution to it involved making the whole thing simpler to use
[09:11] <SteveA> limi: I think the shorthand for "add everything in this directory as a resource" did make it into zope3
[09:11] <SteveA> we should have that now in our snapshot in rocketfuel
[09:11] <limi> ok
[09:11] <limi> I would like that for the images dir
[09:11] <SteveA> sabdfl: did you sort out your odd differences where tests would pass in pqm but not for you?
[09:11] <limi> it gets really boring to declare security for image files ;)
[09:12] <SteveA> resources should be public by default
[09:13] <limi> well, they don't show up unless I put them in the ZCML
[09:14] <limi> and with 50 icons, that gets boring ;)
[09:15] <SteveA> let me see if I can find the name of that directive
[09:17] <limi> I believe Jim said he added it (since I asked him directly about it)
[09:18] <BradB> limi: browser:resourceDirectory
[09:18] <BradB> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Book/resource.html
[09:20] <sabdfl> SteveA: i think it was just timing of refuels vs pqm commits
[09:21] <sabdfl> would be great to have a web page which showed the pqm queue status
[09:22] <SteveA> thanks brad
[09:39] <BradB> no prob
[09:47] <BradB> so the deal with site-edit is that it points to the same site (of course), but simply respects the no-cache header?
[09:47] <BradB> (I'm about to move up the CC patch again, at Lu's request.)
[10:36] <kiko> SteveA <- da man
[10:37] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Added browser:favicon directive. (patch-657)
[11:39] (dilys/#launchpad) Bug 2094 resolved: Change the queries inside Soyuz App Components to the properly SQLObject
[11:39] (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2094
[11:42] (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Soyuz sql.py cleanup. No more sql queries inside this file. Closes bug #2094 (patch-658)
[11:47] <BradB> How do I remove a directory with tla?
[11:47] <BradB> bradb@ozone:~/launchpad/lp/lib/canonical/launchpad$ tla rm events 
[11:47] <BradB> attempt to remove directory events
[11:47] <BradB> bradb@ozone:~/launchpad/lp/lib/canonical/launchpad$ ls events/
[11:47] <BradB> bradb@ozone:~/launchpad/lp/lib/canonical/launchpad$
[11:47] <BradB> :)
[11:48] (spiv/#launchpad) BradB: tla delete events; rmdir events 
[11:49] (spiv/#launchpad) Looks like tla rm is really broken :/
[11:49] <BradB> bradb@ozone:~/launchpad/lp/lib/canonical/launchpad$ tla delete events/
[11:49] <BradB> attempt to remove non-existent id for events/
[11:50] <BradB> i already removed its .arch-ids dir
[11:50] <jblack> spiv: No, not broken. Just confusing
[11:50] (spiv/#launchpad) Ah, then that'll do it to.
[11:50] <BradB> (by hand, after removing the two files in the dir.)
[11:50] (spiv/#launchpad) jblack: Then the docs are broken.
[11:50] <BradB> yeah, one or the other is definitely broken :)
[11:50] <jblack> show me a project in which docs aren't. :) 
[11:50] (spiv/#launchpad) jblack: $ tla help | grep "rm :"
[11:50] (spiv/#launchpad)                           rm : remove a file (or dir, or symlink) and its explicit inventory tag (if any)
[11:50] (spiv/#launchpad) jblack: There's broken docs, then there's broken front-line help on the command-line :)
[11:51] <BradB> jblack: there's "inadequate" docs and then there's "docs that say one thing when the software does something else" :)
[11:51] <BradB> spiv: so i should just rmdir now then?
[11:51] (spiv/#launchpad) BradB: If "tla id events" doesn't know about it, then go for it.
[11:51] (spiv/#launchpad) (Also, tla tree-lint is useful, and even seems to work as advertised ;)
[11:52] <BradB> it's an "untagged file", so i guess that means it doesn't have an idea
[11:52] <BradB> s/idea/id/
[11:52] (spiv/#launchpad) jblack: I'd be more sympathetic if it were some obscure wiki page we're talking about, rather than the output of tla help :)
[11:52] (spiv/#launchpad) jblack: tla rm -h is equally misleading.