| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| jam | vila: different processes | 00:05 |
| vila | jam: I guess so. Well, time to sleep then, I'll see how it goes tomorrow :) | 00:06 |
| lifeless | jam: ? | 00:24 |
| 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:32 |
| 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:33 |
| 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:34 |
| spiv | jam: I have a test for your bug, sending it to the list | 00:37 |
| lifeless | the machine is not dedicated solely to bzr | 00:43 |
| lifeless | its possible there is some other load | 00:43 |
| 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:44 |
| 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:45 |
| jam | spiv: bb:approve | 00:46 |
| spiv | poolie: That sounds good to me. | 00:46 |
| 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:48 |
| lifeless | its running just the bzr test at the moment, no other things interfering | 00:49 |
| TFKyle | hmm, bb over IRC, interesting | 00:49 |
| abentley | TFKyle: please no | 00:54 |
| 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:07 |
| 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:14 |
| poolie | thanks elmo | 01:16 |
| poolie | that's a bit fucked then... | 01:16 |
| === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | bzr 1.4rc2 up for testing, 1.4final today | ||
| 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:19 |
| 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:20 |
| elmo | poolie: strace says it's in a futex and not much more | 01:23 |
| keithy | hello, can I break a lock on a repo? | 01:58 |
| spiv | Yep, "bzr break-lock PATH" | 01:59 |
| keithy | ty | 01:59 |
| poolie | elmo: thanks | 02:04 |
| * igc food | 02:26 | |
| poolie | has anyone else seen bug 225020? | 02:34 |
| spiv | poolie: I have | 02:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:41 |
| spiv | poolie: oh, great! | 02:42 |
| poolie | bimberi: thanks for the reference, that's kind of unfortunate though | 02:43 |
| 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:45 |
| poolie | i don't know many of the people in that thread but it's an unfortunate sounding situation | 02:48 |
| poolie | spiv, maybe it only happens with -Werror and it actually reflects an error in the server code? | 03:04 |
| 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:06 |
| 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:07 |
| 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:08 |
| abentley | "Should be represented as XXX"? | 03:09 |
| spiv | poolie: http://rafb.net/p/dlbvkD76.html | 03:09 |
| spiv | abentley: d'oh. | 03:09 |
| 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:11 |
| 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:12 |
| 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:13 |
| poolie | i was going to put this text at the head of the release | 03:14 |
| poolie | http://rafb.net/p/JNXf7H59.html | 03:14 |
| 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:17 |
| 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:18 |
| lifeless | poolie: ping | 03:39 |
| 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:41 |
| 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:43 |
| lifeless | its hung on a futex | 03:44 |
| poolie | oh, hung as opposed to just spending lots of time in futexes? | 03:44 |
| 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:45 |
| 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:46 |
| poolie | not sure what you're asking me - to check your logic, if this is a bug, why it is this way, ...? | 03:48 |
| igc | lifeless: wrt MutableTree.put_file_bytes_non_atomic, why "non_atomic" as a suffix? | 03:49 |
| 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:50 |
| igc | poolie, lifeless: ah - ok | 03:51 |
| 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:52 |
| 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:54 |
| lifeless | but the test fails (because the file on disk is 88/%2520.weave) | 03:55 |
| lifeless | ah I think I have found it | 03:56 |
| LaserJock | is there a recommended way to use bzr to track a cvs repo? would cvsps work? | 05:18 |
| 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:21 |
| LaserJock | maybe the best would be to just keep a close eye on the LP import and keep poking | 05:22 |
| * 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:24 |
| 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:25 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| LaserJock | mwhudson: is it possible to just start the import later? | 05:32 |
| mwhudson | LaserJock: if you run cscvs by hand maaaybe | 05:32 |
| 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:33 |
| LaserJock | it would be nice to just say "gimme the stuff from the last year" | 05:34 |
| LaserJock | if that makes any sense :-) | 05:34 |
| 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:36 |
| 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:37 |
| 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:38 |
| LaserJock | not, "well let me go poke around to make sure LP is up-to-date" | 05:39 |
| LaserJock | I guess it's good enough for users | 05:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:49 |
| 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 | 05:52 |
| lifeless | poolie: I think having less stuff use them is good | 06:56 |
| 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:07 |
| 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:08 |
| poolie | lifeless, was that actually merged yet? | 07:13 |
| poolie | abentley: BB is down :? | 07:14 |
| lifeless | poolie: dunno | 07:21 |
| bimberi | \o/ | 07:33 |
| bimberi | bug 225020 | 07:34 |
| ubottu | Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [Undecided,New] https://launchpad.net/bugs/225020 | 07:34 |
| lifeless | spiv: how did my branch look? | 07:44 |
| 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:50 |
| lifeless | cool | 07:51 |
| 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:54 |
| lifeless | and with that, its halt() time for me. See you tomorrow. | 07:58 |
| lifeless | hi sabdf1, bye sabdfl :) | 07:58 |
| sabdf1 | night lifeless | 08:46 |
| === sabdf1 is now known as sabdfl | ||
| === Af1 is now known as AfC | ||
| === mrevell is now known as mrevell-bbl | ||
| 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? | 12:58 |
| === mrevell-bbl is now known as mrevell | ||
| spiv | james_w: I think so. | 13:42 |
| james_w | spiv: thanks. | 13:43 |
| 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:45 |
| 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:46 |
| lamby | The other patches are in debian/patches on our alioth repo. Enjoy o/ | 13:47 |
| jelmer | lamby: Cool, thanks again :-) | 13:47 |
| awilkins | jelmer: Confirm that "bzr viz" doesn't work via olive | 14:02 |
| awilkins | jelmer: I meant to put a bug up for it... | 14:03 |
| awilkins | What is abentley doing to the main BB server? It's always down... | 14:05 |
| abentley | awilkins: I'm trying to fix it. | 14:06 |
| awilkins | I suppose that's logical ;-) | 14:06 |
| 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:09 |
| 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:20 |
| abentley | Yeah, that could be an attempt to treat something as a merge directive that is really a bundle or a patch. | 14:21 |
| abentley | I ran into that a while back, but I can't remember whether I fixed it. | 14:22 |
| 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:24 |
| * jelmer checks for missing revs | 14:25 | |
| abentley | Looks like I fixed it in revno 242 | 14:28 |
| abentley | It would be a merge request *without* a patch, actually. | 14:30 |
| jelmer | crap, updating actually broke bundlebuggy altogether | 14:35 |
| 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:43 |
| abentley | jelmer: But it looks as if your problem is you haven't updated the database schema. | 14:46 |
| abentley | The migrate script should do that for you. | 14:47 |
| jelmer | abentley, thanks | 18:11 |
| abentley | jelmer: np | 18:12 |
| 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:18 |
| abentley | vila: No, sorry. | 18:19 |
| 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:20 |
| jelmer | it seems significantly faster to me | 18:21 |
| abentley | jelmer: Yes, I have done some optimization. | 18:21 |
| 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. | 18:59 |
| jelmer | abentley: it still redirects to localhost:8089 after voting using the web interface | 19:00 |
| abentley | jelmer: that uses the application root. If you've got that configured correctly it should take you to the correct place. | 19:07 |
| abentley | jelmer: try configuring server.webpath | 19:08 |
| jelmer | abentley: it's the host name that it doesn't get right, the path in the request is fine | 19:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| Peng | Yeah. | 19:17 |
| Peng | Huh. | 19:17 |
| * Peng leaves. | 19:18 | |
| 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:40 |
| 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:42 |
| vila | Grr, I hate blind debugging :-( | 19:43 |
| Peng | Ack, now push-and-update is getting DeprecationWarnings in bzr.dev. | 20:25 |
| Peng | Thanks to install_hook. | 20:25 |
| Peng | Think it's worth enabling the "bzr://" smart protocol on a server? | 20:36 |
| ja1 | Peng: push-and-update should be fixed for install_named_hook | 21:01 |
| ja1 | as should bzr-email | 21:01 |
| === ja1 is now known as jam | ||
| jam | well, at least once my commit finishes | 21:01 |
| Peng | Yay. | 21:01 |
| 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:06 |
| 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:07 |
| 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:08 |
| jam | I think I also included a hacky workaround to get it to not complain about "this transport does not update the WT" | 21:09 |
| Peng | Yes, you did. | 21:10 |
| 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:39 |
| jam | it should be something like "python -O -Werror ./bzr selftest" and "LANG=C ..." | 21:40 |
| vila | lol, import docutils | 21:41 |
| vila | ImportError: No module named docutils | 21:41 |
| vila | :-) | 21:41 |
| vila | Bad vila | 21:41 |
| 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:48 |
| jam | metameme: I believe we added a specific hook for it in bzr 1.4, if not, it will be in 1.5 | 21:51 |
| 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:52 |
| 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 | 21:53 |
| jelmer | abentley, how do I know whether I'm using dev.cfg or prod.cfg? | 22:05 |
| vila | jelmer, jam: did you run test-gtk lately ? One test is failing: test_diff_view | 22:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| vila | One test is failing: test_diff_view | 22:18 |
| 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:19 |
| vila | phanaric: ping (arf, not even online :) | 22:20 |
| vila | phanatic: ping (arf, not even online, but not a reason to typoed his nick :) | 22:21 |
| abentley | jelmer: It should point to a directory, not a maildir in particular. | 22:25 |
| abentley | You can point it at the maildir/new, if you like. | 22:26 |
| lamby | jelmer: Heh, fastest upstream merge evarr. (Thanks) | 22:29 |
| === mwhudson_ is now known as mwhudson | ||
| === BasicPRO is now known as BasicOSX | ||
| lifeless | jelmer: hi | 22:48 |
| lifeless | jelmer: pqm right? | 22:48 |
| jelmer | lifeless: you can read minds :-) | 22:48 |
| vila | lifeless: read my mind too, you'll find pqm :-/ | 22:57 |
| lifeless | vila: no idea about your patch sorry | 22:58 |
| vila | lifeless: how about an interrupt to at least have a starting point on where it hangs ? | 22:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| vila | right, I will do that anyway, but if it fixes the problem, I'll be really surprised | 23:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:15 |
| lifeless | :) | 23:17 |
| lifeless | back in a few minutes, shave & breakfast | 23:17 |
| 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:25 |
| lifeless | spiv: when you arise, review ping | 23:32 |
| mwhudson | spiv: me too! | 23:34 |
| mwhudson | :) | 23:34 |
| 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:45 |
| lifeless | pam? | 23:55 |
| lifeless | if you mean pqm, its running dapper | 23:55 |
| * Peng looks at the topic. | 23:56 | |
| Peng | Today today? Cool. | 23:56 |
| bob2 | it said that yesterday, too ;) | 23:56 |
| Peng | The topic was set 23 hours ago. | 23:57 |
| vila | lifeless: s/azerty/qwerty/ :) yes pqm, python2.4 ? | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!