[00:00] <nekohayo> hmm any ideas?
[00:00] <jam> nekohayo: something about that machine
[00:00] <jam> and I don't think I have access to it
[00:00] <vila> jam: wow, you're damn right, on my Ubuntu box I see:
[00:00] <jam> lifeless, pool?
[00:00] <jam> poolie: ?
[00:00] <vila> ...vice.LaunchpadServiceTests.test_unknown_service   OK                   0ms
[00:00] <nekohayo> jam, what machine?
[00:00] <jam> nekohayo: the PQM machine
[00:01] <jam> things seem to run fine locally, but running very slow on our merge bot
[00:01] <jam> https://pqm.bazaar-vcs.org/
[00:01] <nekohayo> no I meant for http://ecchi.ca:8000/bzr-question-spiced-ham.htm :)
[00:01] <nekohayo> (unless this is related?)
[00:01] <jam> nekohayo: sorry, completely unrelated, I didn't see your IRC post at all
[00:01] <poolie> jam, hi
[00:02] <vila> hi poolie
[00:02] <nekohayo> (that is a big question that I wrote as a html page to avoid spamming :)
[00:02] <poolie> nekohayo: can you post it to the list instead, it looks like it will take some thinking about
[00:02] <jam> nekohayo: what do you mean by "specto used cvs, svn, and bazaar, all with branches that lost history between the switches"
[00:02] <jam> ?
[00:02] <nekohayo> jam, I mean that specto, across its lifetime as a project, used 3 different version control systems
[00:02] <nekohayo> and each time, we did not keep the history
[00:03] <jam> nekohayo: converting from svn and converting from CVS do not generate conversions that are compatible
[00:03] <jam> hence why you saw the big set of conflicts.
[00:03] <nekohayo> jam: uh? but the merge of the bzr-svn branch into the cvs one only created 4 minor conflicts (I think)
[00:04] <vila> jam, poolie: A new request arrived on pqm, but that's the only change, still at the same test... puzzling
[00:04] <jam> nekohayo: well, if you can post to the list, I agree with poolie, it is going to take a bit of thinking
[00:04] <nekohayo> merging the specto-woutc bzr branch into the new cvs+svn branch did the big conflicts though
[00:04] <nekohayo> ok
[00:04] <jam> if you can give some details about what is *in* the different branches, it would help.
[00:04] <jam> we have a phone call right now
[00:05] <jam> vila: different processes
[00:06] <vila> jam: I guess so. Well, time to sleep then, I'll see how it goes tomorrow :)
[00:24] <lifeless> jam: ?
[00:32] <keithy> Hi, I was using bzr ftp://
[00:32] <keithy> and it seams to use directories relative tot he root of the file system
[00:32] <poolie> i don't have any great ideas about pqm performance
[00:32] <poolie> i am seeing some tests failing inside pycurl
[00:32] <poolie> this is odd
[00:33] <keithy> but how does it manage that , when I login using ftp myself I dont see the root of the file system
[00:33] <bob2> keithy: can you cd / when you login using a ftp client?
[00:34] <keithy> ah.. it it appears so
[00:34] <keithy> duh
[00:34] <poolie> keithy: i think you can use //host/~/foo
[00:34] <poolie> if you wish
[00:34] <poolie> hello bob2
[00:34] <keithy> ty
[00:37] <spiv> jam: I have a test for your bug, sending it to the list
[00:43] <lifeless> the machine is not dedicated solely to bzr
[00:43] <lifeless> its possible there is some other load
[00:44] <jam> lifeless: I was wondering if you would have an idea why the PQM machine is taking 100+ ms for a test that runs here in <3ms
[00:44] <jam> lifeless: further, pqm seems a bit wedged
[00:44] <jam> It has been showing the same step of Vincent's patch for ~1hr
[00:44] <jam> spiv: thanks
[00:45] <poolie> spiv, i feel like we ought to have a coding standard about isinstance vs type etc
[00:45] <poolie> if only to avoid it being rehashed in every review
[00:45] <poolie> maybe also to document which one is fastest
[00:46] <jam> spiv: bb:approve
[00:46] <spiv> poolie: That sounds good to me.
[00:48] <lifeless> top - 00:48:14 up 220 days,  4:25,  1 user,  load average: 0.07, 0.06, 0.07
[00:48] <poolie> jeez firefox is flakey recently
[00:48] <poolie> lifeless: that's pqm?
[00:48] <lifeless> yes
[00:49] <lifeless> its running just the bzr test at the moment, no other things interfering
[00:49] <TFKyle> hmm, bb over IRC, interesting
[00:54] <abentley> TFKyle: please no
[01:07] <poolie> lifeless: so it seems like the test must be wasting time if it's running but the load avg is so low, like it's blocking on io or sleeping a lot
[01:07] <lifeless> yes
[01:14] <elmo> the machine's entirely idle; it's not blocking on io
[01:14] <elmo>  1  0   5392 122888 130552 1489500    0    0     0     0  102    22  0  0 100  0
[01:14] <elmo>  1  0   5392 122888 130552 1489500    0    0     0     0  103    26  0  0 100  0
[01:14] <elmo> ^-- vmstat output
[01:16] <poolie> thanks elmo
[01:16] <poolie> that's a bit fucked then...
[01:19] <lifeless> spiv: ping
[01:19] <poolie> could either of you maybe strace the process to get some idea of what it is doing?
[01:19] <lifeless> spiv: I would like you to be the reviewer for http://bundlebuggy.aaronbentley.com/request/%3C1209531548.29242.542.camel%40lifeless-64%3E if you would
[01:20] <spiv> lifeless: ah-hah.  I was just looking over that code yesterday to get a sense for what was coming :)
[01:20] <spiv> lifeless: So I'm happy to review that.
[01:23] <elmo> poolie: strace says it's in a futex and not much more
[01:58] <keithy> hello, can I break a lock on a repo?
[01:59] <spiv> Yep, "bzr break-lock PATH"
[01:59] <keithy> ty
[02:04] <poolie> elmo: thanks
[02:26]  * igc food
[02:34] <poolie> has anyone else seen bug 225020?
[02:35] <spiv> poolie: I have
[02:36] <spiv> poolie: I spent a while digging into without making much progress (except that I suspect libcurl is doing dumb things, like confusing actual errors with notifications about the exceptfds you can pass to select)
[02:37] <spiv> poolie: at the time, no-one else seemed to have heard of it, so I just assumed that my freshly-upgraded hardy system had something strange going on.
[02:37] <spiv> (I only upgraded to hardy a month ago)
[02:38] <spiv> poolie: "echo raise ImportError > pycurl.py" in the root of your bzr checkout is a workaround, of sorts.
[02:38] <poolie> :/
[02:38] <poolie> also, why didn't the robot link that bug, i wonder?
[02:39] <spiv> Is the robot in the channel?
[02:39] <spiv> I see ubuntulog, but not ubotu or whatever it is called.
[02:39] <poolie> ubugtu?
[02:41] <bimberi> ubotu is currently gone, I think that work is being done on replacements.
[02:41] <bimberi> Ref: https://lists.ubuntu.com/archives/ubuntu-irc/2008-April/000443.html
[02:41] <poolie> spiv, btw last night i started work on deprecating LockableFiles from a different direction and it went quite well
[02:41] <poolie> it may be i just haven't got to the hard part yet
[02:42] <spiv> poolie: oh, great!
[02:43] <poolie> bimberi: thanks for the reference, that's kind of unfortunate though
[02:45] <bimberi> poolie: np. And yes it is.  I've noticed an 'ubottu' in some other channels.  I guess #ubuntu-ops would be a good place to ask.
[02:48] <poolie> i don't know many of the people in that thread but it's an unfortunate sounding situation
[03:04] <poolie> spiv, maybe it only happens with -Werror and it actually reflects an error in the server code?
[03:06] <abentley> poolie: where do we stand with bzr 1.4?
[03:06] <poolie> it looks like we want to merge #214894 into it, i'm reading that and will do final today with only that change?
[03:07] <spiv> poolie: I think I saw the pycurl problem without -Werror.  I used strace and didn't see any sign of a problem on the server side, IIRC.
[03:08] <spiv> Ah, I think I still have the straces somewhere.
[03:08] <spiv> The straces also showed no error return from poll(2) either, IIRC.
[03:09] <abentley> "Should be represented as XXX"?
[03:09] <spiv> poolie: http://rafb.net/p/dlbvkD76.html
[03:09] <spiv> abentley: d'oh.
[03:11] <spiv> poolie: that paste is part of an strace of a test run.  Straight after that it starts re-reading .py files to build the traceback for the exception raised by pycurl.
[03:11] <poolie> abentley: what are you quoting?
[03:12] <spiv> poolie: but the server behaved correctly (and as expected), that test server does not allow POST
[03:12] <abentley> poolie: I'm quoting a comment from spiv's patch for #214894
[03:12] <spiv> My test had a half-written comment.
[03:13] <poolie> oh ok
[03:13] <poolie> abentley: pqm seems unreasonably slow today for unclear reasons
[03:13] <poolie> not sure if you saw before
[03:13] <poolie> :/
[03:13] <abentley> No, I wasn't sure what you guys were stracing.
[03:14] <poolie> i was going to put this text at the head of the release
[03:14] <poolie> http://rafb.net/p/JNXf7H59.html
[03:17] <poolie> spiv, my shelves turned up so after i send off this merge i will head to hornsby if that suits you
[03:17] <poolie> will probably lunch here first
[03:17] <spiv> abentley: I've fixed the XXX in the docstring in my branch, and thanks to PQM being so slow the corrected version will be merged.
[03:17] <spiv> poolie: sounds good
[03:17] <abentley> spiv: heh!
[03:17] <spiv> abentley: thanks for catching that :)
[03:17] <abentley> spiv: no problem.
[03:18] <abentley> I wish I'd had the option a few days ago when I accidentally merged the wrong branch.
[03:18] <spiv> Hmm, PQM isn't so much slow as wedged, AFAICS.
[03:39] <lifeless> poolie: ping
[03:41] <poolie> pong
[03:41] <poolie> lifeless: pong
[03:41] <lifeless> I'm trying to figure out store url escaping
[03:41] <poolie> k
[03:41] <lifeless> I seem to be getting double escaping
[03:43] <poolie> ok
[03:43] <poolie> sorry to interrupt you but pqm seems to be barely making progress at all
[03:43] <poolie> it is according to the web still working on the same job it was when i started this morning
[03:44] <lifeless> its hung on a futex
[03:44] <poolie> oh, hung as opposed to just spending lots of time in futexes?
[03:45] <lifeless> pqm@balleny:~$ strace -p 16075
[03:45] <lifeless> Process 16075 attached - interrupt to quit
[03:45] <lifeless> futex(0x1a30e90, FUTEX_WAIT, 0, NULL <unfinished ...>
[03:45] <lifeless> Process 16075 detached
[03:45] <poolie> maybe we should kill it and let the next job through then?
[03:45] <lifeless> done
[03:45] <poolie> thanks
[03:46] <poolie> so back to your escapism
[03:46] <lifeless> test_escaped_store
[03:46] <lifeless> has a test_weave in it
[03:46] <lifeless> as far as I can tell, it should be double escaping with bzr.dev
[03:48] <poolie> not sure what you're asking me - to check your logic, if this is a bug, why it is this way, ...?
[03:49] <igc> lifeless: wrt MutableTree.put_file_bytes_non_atomic, why "non_atomic" as a suffix?
[03:50] <lifeless> because its not atomic
[03:50] <poolie> igc, it means "don't do the rename-into-place thing"
[03:50] <poolie> people reading the file may see it half-written
[03:50] <poolie> could be good to put that in the developer guide
[03:51] <igc> poolie, lifeless: ah - ok
[03:52] <igc> the wt.put_file_bytes_non_atomic docstring refers to the MutableTree one but the latter doesn't exist
[03:52] <igc> I'll add it
[03:54] <lifeless> poolie: I'm trying to figure out what is going on
[03:54] <lifeless> poolie: e.g. store.filename(' ') -> '88/%2520'
[03:54] <lifeless> poolie: but the test looks for '88/%20' successfully
[03:54] <lifeless> my replacement mapper code returns the same result from filename
[03:55] <lifeless> but the test fails (because the file on disk is 88/%2520.weave)
[03:56] <lifeless> ah I think I have found it
[05:18] <LaserJock> is there a recommended way to use bzr to track a cvs repo? would cvsps work?
[05:21] <LaserJock> most of the tools I've seen seem to be made for one shot conversion, where I want to be able to track a CVS repo
[05:21] <lifeless> launchpad
[05:21] <lifeless> or cscvs which is what launchpad uses
[05:21] <LaserJock> well, yeah, launchpad could work if it was up-to-date
[05:21] <lifeless> it tries hard to handle just about any stupidity people do to cvs
[05:21] <LaserJock> but it frequently lags
[05:22] <LaserJock> maybe the best would be to just keep a close eye on the LP import and keep poking
[05:24]  * igc food
[05:24] <mwhudson> LaserJock: which import?
[05:24] <LaserJock> the one I want to track is about 5 months behind or so :/
[05:25] <LaserJock> mwhudson: https://code.launchpad.net/~vcs-imports/gchemutils/trunk
[05:25] <LaserJock> it's just difficult to have to keep track of LP
[05:25] <LaserJock> I end up tacking the CVS anyway just to make sure I'm not missing stuff
[05:27] <mwhudson> oh and gah, we lost all the code imports log files earlier on today
[05:27]  * mwhudson gives the import a kick
[05:27] <LaserJock> although in looking at the 4 imports that I'd use on a daily basis gchemutils is the only one that's not up-to-date
[05:28] <LaserJock> it's also the only one that is CVS, which may explain it
[05:28] <mwhudson> LaserJock: it's https://bugs.edge.launchpad.net/launchpad-cscvs/+bug/120977 :(
[05:28] <mwhudson> so it's not going to start working again until we get some time to fix that
[05:29] <mwhudson> (or someone else fixes it, cscvs is open source after all, but people who know enough about cvs are probably a bit thin on the ground)
[05:29] <LaserJock> bummer :/
[05:29] <mwhudson> yar
[05:30] <LaserJock> that's the one I especially would love to work with in bzr
[05:30] <LaserJock> as I can't make head or tails of CVS to save my life
[05:30] <LaserJock> but the project is very important to me
[05:30] <LaserJock> so I struggle on ;-)
[05:31] <LaserJock> right now I'm using git-cvs to track it
[05:31] <LaserJock> which works pretty well, but I'm trying to convert all my git stuff to bzr
[05:32] <LaserJock> mwhudson: is it possible to just start the import later?
[05:32] <mwhudson> LaserJock: if you run cscvs by hand maaaybe
[05:33] <LaserJock> this is one thing I keep running into with DVCS
[05:33] <LaserJock> I would verrrry rarely need to go to revision 1
[05:33] <LaserJock> but often times if something breaks somewhere in history the whole thing is screwed
[05:34] <LaserJock> it would be nice to just say "gimme the stuff from the last year"
[05:34] <LaserJock> if that makes any sense :-)
[05:36] <LaserJock> mwhudson: is there a way for users to see if a vcsimport is out of sync without having to get the original repo?
[05:36] <LaserJock> mwhudson: I think the value of LP code hosting goes way down if users can't be assured that they're getting the latest revision
[05:36] <mwhudson> LaserJock: well, the "Last imported: 28 weeks ago" on https://code.edge.launchpad.net/gchemutils/trunk is a pretty large clue
[05:37] <LaserJock> yeah, for that one sure
[05:37] <LaserJock> but there's nothing like a failure flag or something?
[05:37] <mwhudson> this should, and soon-ish will be, on the branch page
[05:37] <mwhudson> hm, no
[05:38] <mwhudson> probably should be though
[05:38] <mwhudson> LaserJock: file a bug about that?
[05:38] <LaserJock> ok
[05:38] <LaserJock> I'm just concerned
[05:38] <LaserJock> because when somebody says "are you building from HEAD?" I need to be able to confidently reply
[05:39] <LaserJock> not, "well let me go poke around to make sure LP is up-to-date"
[05:40] <LaserJock> I guess it's good enough for users
[05:41] <mwhudson> well, i can't really see how you can be sure
[05:41] <LaserJock> but if you're hacking on irc with fellow developers it's not really gonna work
[05:41] <mwhudson> i mean, the imports lag by a few hours on average
[05:41] <LaserJock> well, that's sort of my point
[05:42] <mwhudson> well, how can launchpad know it's out of date?
[05:42] <LaserJock> well
[05:42] <LaserJock> it can't exactly
[05:42] <mwhudson> there is a sort of plan floating around where launchpad should be able to subscribe to a commits mailing list
[05:42] <mwhudson> and will update whenever it receives a mail
[05:42] <LaserJock> but I wonder if you could somehow give a time since last import
[05:43] <mwhudson> but i don't think it's even written down, never mind scheduled
[05:43] <mwhudson> https://edge.launchpad.net/drupal/main -> "Last imported: 28 minutes ago"
[05:43] <LaserJock> bottom line though, LP vcsimports are not really designed for developers methinks
[05:43] <poolie> lifeless: hi, are transactions meant to be getting removed?
[05:44] <poolie> ie the control_files.get_transaction and so on?
[05:44] <lifeless> yah
[05:44] <lifeless> I didn't break api but I stopped their use in stores in 1.4
[05:44] <lifeless>  branch may still use them
[05:44] <poolie> ok
[05:44] <poolie> as i may have said yesterday
[05:45] <poolie> i think removing LockableFiles is becoming more important, to enable improvements in Remote
[05:45] <poolie> so if less stuff uses them, and we can either just delete them or at least have less to update
[05:45] <poolie> all the better
[05:46] <spiv> mwhudson: if launchpad had an API for "please mirror now", a 3rd-party could arrange for that to happen for themselves without waiting for the launchpad feature.
[05:46] <mwhudson> spiv: yes
[05:46] <mwhudson> spiv: it's on the cards
[05:49] <LaserJock> mwhudson: bug filed
[05:49] <awmcclain> Hey all... are there docs somewhere about how to log to .bzr.log? I'm trying to debug bzr-email.
[05:52] <spiv> awmcclain: "from bzrlib.trace import mutter; mutter('this goes to the log file')"
[05:52] <spiv> awmcclain: see the bzrlib.trace module in general
[06:56] <lifeless> poolie: I think having less stuff use them is good
[07:07] <poolie> lifeless: i want to bounce a testing idea off you
[07:07] <poolie> that is that we should make use of the lock taken/released events to assert that less than N locks are acquired in the blackbox test for push
[07:07] <poolie> eventually we want similar assertions on smaller levels
[07:08] <lifeless> such tests are one of the things I had in mind with the lock hooks
[07:08] <poolie> but since people sometimes add "oh and also" code to the cmd_ it might be good to cover it at a high level
[07:08] <poolie> me too
[07:08] <poolie> great
[07:13] <poolie> lifeless, was that actually merged yet?
[07:14] <poolie> abentley: BB is down :?
[07:21] <lifeless> poolie: dunno
[07:33] <bimberi> \o/
[07:34] <bimberi> bug 225020
[07:44] <lifeless> spiv: how did my branch look?
[07:50] <spiv> lifeless: Haven't looked yet, I've been pairing with poolie
[07:50] <spiv> lifeless: I expect to do it tonight and first thing tomorrow, though.
[07:51] <lifeless> cool
[07:54] <lifeless> poolie: I have the mapping code looking good; was rather confused by the apparent double-escaping
[07:54] <lifeless> poolie: turns out we return urls not paths from the public interface, even though it talks paths. This will get cleared up by my following work
[07:58] <lifeless> and with that, its halt() time for me. See you tomorrow.
[07:58] <lifeless> hi sabdf1, bye sabdfl :)
[08:46] <sabdf1> night lifeless
[12:58] <james_w> If I'm creating ghosts as part of an import I just add extra parents when needed correct? I don't need to add ghost records of any sort?
[12:58] <james_w> Also, just generating a new random revid is fine, as I can just look up the needed revid when I come to create the ghost later?
[13:42] <spiv> james_w: I think so.
[13:43] <james_w> spiv: thanks.
[13:45] <lamby> jelmer: I've just packaged (and pushed) bzr-gtk 0.94.0rc1 but the shiny log is now broken (and I don't know how to fix it) :'(
[13:45] <jelmer> lamby: Thanks!
[13:45] <lamby> jelmer: I did manage to patch a few other problems, which almost certainly need to go upstream.
[13:45] <jelmer> lamby: Shiny log being "bzr viz" ? :-)
[13:46] <lamby> Indeed. To be clear, it only breaks when you load it via olive-gtk.
[13:46] <jelmer> ahh, ok. I don't use olive so that must be why I've missed it
[13:47] <lamby> The other patches are in debian/patches on our alioth repo. Enjoy o/
[13:47] <jelmer> lamby: Cool, thanks again :-)
[14:02] <awilkins> jelmer: Confirm that "bzr viz" doesn't work via olive
[14:03] <awilkins> jelmer: I meant to put a bug up for it...
[14:05] <awilkins> What is abentley doing to the main BB server? It's always down...
[14:06] <abentley> awilkins: I'm trying to fix it.
[14:06] <awilkins> I suppose that's logical ;-)
[14:09] <abentley> Unfortunately, there appear to be bugs in the visitor tracking part of Turbogears that are threading bugs that I can't reproduce locally.
[14:20] <jelmer> abentley: btw, do you have any idea what could cause this: http://bundlebuggy.vernstok.nl/bzr-gtk//request/%3C9a9b41cb0804111344p82ce7d5o6f819346e9eb4349@mail.gmail.com%3E
[14:21] <abentley> Yeah, that could be an attempt to treat something as a merge directive that is really a bundle or a patch.
[14:22] <abentley> I ran into that a while back, but I can't remember whether I fixed it.
[14:24] <abentley> jelmer: are you up-to-date with my changes?
[14:24] <jelmer> I'm running my own branch, which has the RSS support but may not be up to date
[14:25]  * jelmer checks for missing revs
[14:28] <abentley> Looks like I fixed it in revno 242
[14:30] <abentley> It would be a merge request *without* a patch, actually.
[14:35] <jelmer> crap, updating actually broke bundlebuggy altogether
[14:43] <abentley> jelmer: I've changed the way mail is handled in BB, to deal with the fact that BB's been unstable.
[14:43] <abentley> Now procmail delivers mail to a mail_queue directory, and BB checks for new mail there.
[14:46] <abentley> jelmer: But it looks as if your problem is you haven't updated the database schema.
[14:47] <abentley> The migrate script should do that for you.
[18:11] <jelmer> abentley, thanks
[18:12] <abentley> jelmer: np
[18:18] <vila> abentley: do you have access to the pqm machine ? It looks like my last submission make it hang again >-/ (It did this morning lifeless killed it I guess)
[18:19] <abentley> vila: No, sorry.
[18:20] <vila> too bad, do you  remember *how* it run the test suite ? And/Or what its config is, I'm totally puzzled about what can cause this...
[18:20] <jelmer> abentley: Did you improve performance in bb by any chance?
[18:21] <jelmer> it seems significantly faster to me
[18:21] <abentley> jelmer: Yes, I have done some optimization.
[18:59] <abentley> jelmer: Also, you should find that your hacks to place BB's root at a sub-url are no longer necessary.  Please let me know if there's anything I've missed.
[19:00] <jelmer> abentley: it still redirects to localhost:8089 after voting using the web interface
[19:07] <abentley> jelmer: that uses the application root.  If you've got that configured correctly it should take you to the correct place.
[19:08] <abentley> jelmer: try configuring server.webpath
[19:11] <jelmer> abentley: it's the host name that it doesn't get right, the path in the request is fine
[19:12] <jelmer> is there an option for that?
[19:12] <abentley> yes.
[19:12] <abentley> I use: base_url_filter.on = True
[19:12] <abentley> base_url_filter.use_x_forwarded_host = True
[19:13] <abentley> You can also specify the base url yourself.
[19:13] <abentley> Are you running using dev.cfg or prod.cfg?
[19:13] <Peng> Wait, when using bzr+ssh, autopacking isn't done by the server?
[19:14] <abentley> Peng: Correct.
[19:14] <beuno> Peng, no, autopacking is always done client-side, AFAIK
[19:14] <Peng> Oh.
[19:14] <Peng> I thought it was done by the server.
[19:14] <Peng> Maybe someone said that it was a possibility (which it is), and I misinterpreted it.
[19:14] <abentley> That's how we'd like it to work, not how it works right now.
[19:17] <Peng> Yeah.
[19:17] <Peng> Huh.
[19:18]  * Peng leaves.
[19:40] <vila> lifeless: If (and/or when) you look at pqm, can you try to have a look at *where* selftest is hanging, I really have no clue on how to debug this :-/
[19:42] <vila> The only I can think about that can explain is a test order dependent bug since I changed the overall test suite order when merging in a single list the modules that were defining test_suite()  and those what were using LoadTestsFromModule...
[19:42] <vila> s/only/ only cause/
[19:43] <vila> Grr, I hate blind debugging :-(
[20:25] <Peng> Ack, now push-and-update is getting DeprecationWarnings in bzr.dev.
[20:25] <Peng> Thanks to install_hook.
[20:36] <Peng> Think it's worth enabling the "bzr://" smart protocol on a server?
[21:01] <ja1> Peng: push-and-update should be fixed for install_named_hook
[21:01] <ja1> as should bzr-email
[21:01] <jam> well, at least once my commit finishes
[21:01] <Peng> Yay.
[21:06] <Peng> Wait, when does push-and-update's hook come into effect?
[21:06] <jam> Peng: it has to register itself at plugin load time
[21:06] <jam> so it is calling install_hook all the time
[21:07] <jam> the hook isn't being called, but it needs to be installed
[21:07] <Peng> Yeah, but when does it actually do its thing? On every push?
[21:08] <jam> Peng: on every push it checks if the remote has a working tree, if it does, it then does 'ssh host bzr update path'
[21:08] <Peng> Huh.
[21:08] <jam> Peng: so it won't create WTs that aren't there, but if there is one, it tries to keep it up to date
[21:08] <Peng> I didn't know that.
[21:09] <jam> I think I also included a hacky workaround to get it to not complain about "this transport does not update the WT"
[21:10] <Peng> Yes, you did.
[21:39] <vila> jam: Do you know where I can find how pqm run the test suite ?
[21:39] <jam> vila: make check
[21:39] <jam> vila: so "Makefile" has the details
[21:39] <vila> jam: grrr, thanks a lot ;-)
[21:40] <jam> it should be something like "python -O -Werror ./bzr selftest" and "LANG=C ..."
[21:41] <vila> lol,     import docutils
[21:41] <vila> ImportError: No module named docutils
[21:41] <vila> :-)
[21:41] <vila> Bad vila
[21:48] <metameme> I'm new to bzr and my organization is switching to it from svn.  When using a centralized workflow, is it possible to have a post-commit hook like bzr-email be set up entirely on the server side, with zero client configuration?
[21:51] <jam> metameme: I believe we added a specific hook for it in bzr 1.4, if not, it will be in 1.5
[21:52] <jam> prior versions didn't quite have enough info
[21:52] <jam> ATM, bzr-email is not directly able to do it, because the hook is newer
[21:52] <metameme> jam: Okay, thanks.  It'll be a great feature to have.
[21:53] <jam> metameme: I believe someone already put together code with the older format, which runs as a cron script
[21:53] <jam> and just detects new revisions and emails them out
[22:05] <jelmer> abentley, how do I know whether I'm using dev.cfg or prod.cfg?
[22:11] <vila> jelmer, jam: did you run test-gtk lately ? One test is failing: test_diff_view
[22:12] <jam> vila: I don't think jelmer ever runs test-gtk, and I haven't done any hacking on it for a while
[22:12] <jam> the bzr-gtk project is *not* TDD
[22:12] <jam> bbiab
[22:12] <vila> hmm, bad Jelmer :)
[22:13] <vila> anyway I'm hacking again on the '_' related problem, trying to implement it as _i18n as the last mail on the subject suggested, is that still the consensus ?
[22:14] <abentley> jelmer: If you use the bundled init script or do start-bundlebuggy prod.cfg or run start-bundlebuggy for an installed copy, you are using prod.cfg.
[22:15] <abentley> If you are getting lots of stuff spewed to the console, you are running dev.cfg.
[22:15] <jelmer> abentley: Looks like I'm using dev.cfg then :-)
[22:15] <jelmer> The base_url bits you mentioned seem to work, thanks!
[22:15] <abentley> No problem.
[22:16] <jelmer> it would be nice if these two settings were mentioned in the example dev.cfg for new bundlebuggy users..
[22:16] <jelmer> vila: Well, GUI unit testing is kinda hard
[22:17] <vila> jelmer: no worries, just joking, what about the other points ^
[22:17] <jelmer> vila: Which ones?
[22:17] <vila> anyway I'm hacking again on the '_' related problem, trying to implement it as _i18n as the last mail on the subject suggested, is that still the consensus ?
[22:18] <vila>  One test is failing: test_diff_view
[22:19] <vila> and, about the po files, how are you handling them ?
[22:19] <jelmer> abentley: Should mail_queue_location point to a mbox or maildir ?
[22:19] <vila> I tried genpot.sh but it broke and seems old
[22:19] <jelmer> vila: phanatic is handling all of the i18n stuff
[22:19] <jelmer> vila: We still need a PQM to make sure we don't get regressions like that
[22:19] <jelmer> lifeless, ping
[22:20] <vila> phanaric: ping (arf, not even online :)
[22:21] <vila> phanatic: ping (arf, not even online, but not a reason to typoed his nick :)
[22:25] <abentley> jelmer: It should point to a directory, not a maildir in particular.
[22:26] <abentley> You can point it at the maildir/new, if you like.
[22:29] <lamby> jelmer: Heh, fastest upstream merge evarr. (Thanks)
[22:48] <lifeless> jelmer: hi
[22:48] <lifeless> jelmer: pqm right?
[22:48] <jelmer> lifeless: you can read minds :-)
[22:57] <vila> lifeless: read my mind too, you'll find pqm :-/
[22:58] <lifeless> vila: no idea about your patch sorry
[22:59] <vila> lifeless: how about an interrupt to at least have a starting point on where it hangs ?
[23:00] <vila> Note that it is currently hanging for around 5 hours...
[23:00] <lifeless> the hang I saw it was waiting on a futex
[23:00] <lifeless> is it hung again?
[23:00] <vila> yes
[23:00] <lifeless> killed
[23:01] <vila> first time I thought it may have been the pqm, but now I'm really... killed ? Ghaa, how can I hope to debug it then :-(
[23:01] <lifeless> it runs within cron
[23:01] <lifeless> I can't pdb it when it hangs
[23:02] <vila> I see :(
[23:02] <lifeless> I can gdb but that is fiddly and much less useful
[23:02] <lifeless> it was waiting on futex
[23:02] <lifeless> that means its probably a server shutdown or some such
[23:02] <lifeless> this is your test-ids patch?
[23:03] <vila> the one changing test_suite() to load_tests()
[23:03] <vila> the only side-effect I see is that some tests are not run in the same order now, other than that....
[23:03] <lifeless> thats entirely possible to cause such an effect
[23:03] <lifeless> if we have an isolation bug
[23:04] <vila> I tried running all tests in isolation (i.e. one by one with --load-list) and so far nothing serious popped out
[23:04] <lifeless> I don't think you should ignore basic_tests ever
[23:05] <vila> basic_tests ?
[23:05] <lifeless> +    # since this module doesn't define tests, we ignore basic_tests
[23:05] <lifeless>      suite = doctest.DocFileSuite(*scripts)
[23:05] <lifeless> anyhow, assume that its ordering. You need to run two tests minimum to display an ordering problem
[23:05] <lifeless> one easy way to show such a thing is to invert the entire test order
[23:06] <lifeless> vila: also
[23:06] <vila> hmmm, pqm is running make check, running make check is ok...
[23:06] <lifeless> basic_tests is a suite
[23:06] <lifeless> you don't ever have to do
[23:06] <lifeless> suite = loader.suiteClass()
[23:07] <lifeless> suite.addTests(basic_tests)
[23:07] <lifeless> just use basic_tests directly.
[23:07] <lifeless> bb:tweak  :)
[23:07] <lifeless> you'll save lots of code
[23:08] <vila> right, I will do that anyway, but if it fixes the problem, I'll be really surprised
[23:09] <lifeless> this for loop
[23:09] <lifeless> +    for test in tests.iter_suite_tests(standard_tests):
[23:09] <lifeless> +        result.addTests(adapter.adapt(test))
[23:10] <lifeless> seems to be cropping up multiple times
[23:10] <vila> :-)
[23:10] <vila> Yup, I didn't want to stretch the patch, but I noticed it
[23:10] <lifeless> ok, I've read the patch end to end
[23:10] <lifeless> those are my comments; I can't see anything to cause a random hang.
[23:11] <lifeless> there are two causes i can think of:
[23:11] <lifeless>  - test ordering
[23:11] <lifeless>  - test parameterisation
[23:11] <lifeless> if its an ordering bug, one would expect that running the entire test suite in opposite order would *probably* show it
[23:12] <lifeless> so a simple patch that adds reversed(list(iter_suite_tests(test_suite))) to the end of bzrlib.test_suite()
[23:12] <lifeless> or just before the runner
[23:12] <lifeless> might be enough to trigger and show the problem
[23:13] <vila> I'll try that. Can you elaborate on the parameterisation cause ?
[23:13] <lifeless> test parameterisation - if the patch actually does change the semantics of one or more parameterised tests its possible that you're just causing a bug, but I didn't spot such a thing when I read the patch.
[23:15] <vila> Since the branch had a long live, I was paranoid about each merge and always checked that I got the same number of tests (that was one reason to keep that last patch in its own loom thread)
[23:15] <vila> Granted, number of tests was a simple metric, but
[23:15] <vila> no but
[23:17] <lifeless> :)
[23:17] <lifeless> back in a few minutes, shave & breakfast
[23:25] <vila> arf, arf, false hope:
[23:25] <vila> FAIL: test_selftest.TestTestIdList.test_test_suite
[23:25] <vila>     not equal:
[23:25] <vila> a = ['bzrlib.tests.blackbox.test_branch.TestBranch.test_branch',
[23:25] <vila>  'bzrlib.tests.test_selftest.TestTestIdList.test_test_suite',
[23:25] <vila>  'bzrlib.tests.test_transport_implementations.TransportTests.test_abspath(LocalURLServer)',
[23:25] <vila>  'bzrlib.timestamp.format_highres_date']
[23:25] <vila> b = ['bzrlib.timestamp.format_highres_date',
[23:25] <vila>  'bzrlib.tests.test_transport_implementations.TransportTests.test_abspath(LocalURLServer)',
[23:25] <vila>  'bzrlib.tests.test_selftest.TestTestIdList.test_test_suite',
[23:25] <vila>  'bzrlib.tests.blackbox.test_branch.TestBranch.test_branch']
[23:32] <lifeless> spiv: when you arise, review ping
[23:34] <mwhudson> spiv: me too!
[23:34] <mwhudson> :)
[23:45] <vila> lifeless: selftest reversed just complete, except for the one test whose failure is understandable, nothing.   I'll dig the basic_tests route a bit just to check but if you can provide me with some data on pam, that may helps too (os/python versions, plugins ?).
[23:55] <lifeless> pam?
[23:55] <lifeless> if you mean pqm, its running dapper
[23:56]  * Peng looks at the topic.
[23:56] <Peng> Today today? Cool.
[23:56] <bob2> it said that yesterday, too ;)
[23:57] <Peng> The topic was set 23 hours ago.
[23:58] <vila> lifeless: s/azerty/qwerty/ :) yes pqm, python2.4 ?