[00:00] hmm any ideas? [00:00] nekohayo: something about that machine [00:00] and I don't think I have access to it [00:00] jam: wow, you're damn right, on my Ubuntu box I see: [00:00] lifeless, pool? [00:00] poolie: ? [00:00] ...vice.LaunchpadServiceTests.test_unknown_service OK 0ms [00:00] jam, what machine? [00:00] nekohayo: the PQM machine [00:01] things seem to run fine locally, but running very slow on our merge bot [00:01] https://pqm.bazaar-vcs.org/ [00:01] no I meant for http://ecchi.ca:8000/bzr-question-spiced-ham.htm :) [00:01] (unless this is related?) [00:01] nekohayo: sorry, completely unrelated, I didn't see your IRC post at all [00:01] jam, hi [00:02] hi poolie [00:02] (that is a big question that I wrote as a html page to avoid spamming :) [00:02] nekohayo: can you post it to the list instead, it looks like it will take some thinking about [00:02] nekohayo: what do you mean by "specto used cvs, svn, and bazaar, all with branches that lost history between the switches" [00:02] ? [00:02] jam, I mean that specto, across its lifetime as a project, used 3 different version control systems [00:02] and each time, we did not keep the history [00:03] nekohayo: converting from svn and converting from CVS do not generate conversions that are compatible [00:03] hence why you saw the big set of conflicts. [00:03] jam: uh? but the merge of the bzr-svn branch into the cvs one only created 4 minor conflicts (I think) [00:04] jam, poolie: A new request arrived on pqm, but that's the only change, still at the same test... puzzling [00:04] nekohayo: well, if you can post to the list, I agree with poolie, it is going to take a bit of thinking [00:04] merging the specto-woutc bzr branch into the new cvs+svn branch did the big conflicts though [00:04] ok [00:04] if you can give some details about what is *in* the different branches, it would help. [00:04] we have a phone call right now [00:05] vila: different processes [00:06] jam: I guess so. Well, time to sleep then, I'll see how it goes tomorrow :) [00:24] jam: ? [00:32] Hi, I was using bzr ftp:// [00:32] and it seams to use directories relative tot he root of the file system [00:32] i don't have any great ideas about pqm performance [00:32] i am seeing some tests failing inside pycurl [00:32] this is odd [00:33] but how does it manage that , when I login using ftp myself I dont see the root of the file system [00:33] keithy: can you cd / when you login using a ftp client? [00:34] ah.. it it appears so [00:34] duh [00:34] keithy: i think you can use //host/~/foo [00:34] if you wish [00:34] hello bob2 [00:34] ty [00:37] jam: I have a test for your bug, sending it to the list [00:43] the machine is not dedicated solely to bzr [00:43] its possible there is some other load [00:44] 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] lifeless: further, pqm seems a bit wedged [00:44] It has been showing the same step of Vincent's patch for ~1hr [00:44] spiv: thanks [00:45] spiv, i feel like we ought to have a coding standard about isinstance vs type etc [00:45] if only to avoid it being rehashed in every review [00:45] maybe also to document which one is fastest [00:46] spiv: bb:approve [00:46] poolie: That sounds good to me. [00:48] top - 00:48:14 up 220 days, 4:25, 1 user, load average: 0.07, 0.06, 0.07 [00:48] jeez firefox is flakey recently [00:48] lifeless: that's pqm? [00:48] yes [00:49] its running just the bzr test at the moment, no other things interfering [00:49] hmm, bb over IRC, interesting [00:54] TFKyle: please no [01:07] 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] yes [01:14] the machine's entirely idle; it's not blocking on io [01:14] 1 0 5392 122888 130552 1489500 0 0 0 0 102 22 0 0 100 0 [01:14] 1 0 5392 122888 130552 1489500 0 0 0 0 103 26 0 0 100 0 [01:14] ^-- vmstat output [01:16] thanks elmo [01:16] that's a bit fucked then... === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | bzr 1.4rc2 up for testing, 1.4final today [01:19] spiv: ping [01:19] could either of you maybe strace the process to get some idea of what it is doing? [01:19] 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] lifeless: ah-hah. I was just looking over that code yesterday to get a sense for what was coming :) [01:20] lifeless: So I'm happy to review that. [01:23] poolie: strace says it's in a futex and not much more [01:58] hello, can I break a lock on a repo? [01:59] Yep, "bzr break-lock PATH" [01:59] ty [02:04] elmo: thanks [02:26] * igc food [02:34] has anyone else seen bug 225020? [02:35] poolie: I have [02:36] 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] 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] (I only upgraded to hardy a month ago) [02:38] poolie: "echo raise ImportError > pycurl.py" in the root of your bzr checkout is a workaround, of sorts. [02:38] :/ [02:38] also, why didn't the robot link that bug, i wonder? [02:39] Is the robot in the channel? [02:39] I see ubuntulog, but not ubotu or whatever it is called. [02:39] ubugtu? [02:41] ubotu is currently gone, I think that work is being done on replacements. [02:41] Ref: https://lists.ubuntu.com/archives/ubuntu-irc/2008-April/000443.html [02:41] spiv, btw last night i started work on deprecating LockableFiles from a different direction and it went quite well [02:41] it may be i just haven't got to the hard part yet [02:42] poolie: oh, great! [02:43] bimberi: thanks for the reference, that's kind of unfortunate though [02:45] 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] i don't know many of the people in that thread but it's an unfortunate sounding situation [03:04] spiv, maybe it only happens with -Werror and it actually reflects an error in the server code? [03:06] poolie: where do we stand with bzr 1.4? [03:06] 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] 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] Ah, I think I still have the straces somewhere. [03:08] The straces also showed no error return from poll(2) either, IIRC. [03:09] "Should be represented as XXX"? [03:09] poolie: http://rafb.net/p/dlbvkD76.html [03:09] abentley: d'oh. [03:11] 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] abentley: what are you quoting? [03:12] poolie: but the server behaved correctly (and as expected), that test server does not allow POST [03:12] poolie: I'm quoting a comment from spiv's patch for #214894 [03:12] My test had a half-written comment. [03:13] oh ok [03:13] abentley: pqm seems unreasonably slow today for unclear reasons [03:13] not sure if you saw before [03:13] :/ [03:13] No, I wasn't sure what you guys were stracing. [03:14] i was going to put this text at the head of the release [03:14] http://rafb.net/p/JNXf7H59.html [03:17] spiv, my shelves turned up so after i send off this merge i will head to hornsby if that suits you [03:17] will probably lunch here first [03:17] 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] poolie: sounds good [03:17] spiv: heh! [03:17] abentley: thanks for catching that :) [03:17] spiv: no problem. [03:18] I wish I'd had the option a few days ago when I accidentally merged the wrong branch. [03:18] Hmm, PQM isn't so much slow as wedged, AFAICS. [03:39] poolie: ping [03:41] pong [03:41] lifeless: pong [03:41] I'm trying to figure out store url escaping [03:41] k [03:41] I seem to be getting double escaping [03:43] ok [03:43] sorry to interrupt you but pqm seems to be barely making progress at all [03:43] it is according to the web still working on the same job it was when i started this morning [03:44] its hung on a futex [03:44] oh, hung as opposed to just spending lots of time in futexes? [03:45] pqm@balleny:~$ strace -p 16075 [03:45] Process 16075 attached - interrupt to quit [03:45] futex(0x1a30e90, FUTEX_WAIT, 0, NULL [03:45] Process 16075 detached [03:45] maybe we should kill it and let the next job through then? [03:45] done [03:45] thanks [03:46] so back to your escapism [03:46] test_escaped_store [03:46] has a test_weave in it [03:46] as far as I can tell, it should be double escaping with bzr.dev [03:48] not sure what you're asking me - to check your logic, if this is a bug, why it is this way, ...? [03:49] lifeless: wrt MutableTree.put_file_bytes_non_atomic, why "non_atomic" as a suffix? [03:50] because its not atomic [03:50] igc, it means "don't do the rename-into-place thing" [03:50] people reading the file may see it half-written [03:50] could be good to put that in the developer guide [03:51] poolie, lifeless: ah - ok [03:52] the wt.put_file_bytes_non_atomic docstring refers to the MutableTree one but the latter doesn't exist [03:52] I'll add it [03:54] poolie: I'm trying to figure out what is going on [03:54] poolie: e.g. store.filename(' ') -> '88/%2520' [03:54] poolie: but the test looks for '88/%20' successfully [03:54] my replacement mapper code returns the same result from filename [03:55] but the test fails (because the file on disk is 88/%2520.weave) [03:56] ah I think I have found it [05:18] is there a recommended way to use bzr to track a cvs repo? would cvsps work? [05:21] 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] launchpad [05:21] or cscvs which is what launchpad uses [05:21] well, yeah, launchpad could work if it was up-to-date [05:21] it tries hard to handle just about any stupidity people do to cvs [05:21] but it frequently lags [05:22] maybe the best would be to just keep a close eye on the LP import and keep poking [05:24] * igc food [05:24] LaserJock: which import? [05:24] the one I want to track is about 5 months behind or so :/ [05:25] mwhudson: https://code.launchpad.net/~vcs-imports/gchemutils/trunk [05:25] it's just difficult to have to keep track of LP [05:25] I end up tacking the CVS anyway just to make sure I'm not missing stuff [05:27] oh and gah, we lost all the code imports log files earlier on today [05:27] * mwhudson gives the import a kick [05:27] 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] it's also the only one that is CVS, which may explain it [05:28] LaserJock: it's https://bugs.edge.launchpad.net/launchpad-cscvs/+bug/120977 :( [05:28] so it's not going to start working again until we get some time to fix that [05:29] (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] bummer :/ [05:29] yar [05:30] that's the one I especially would love to work with in bzr [05:30] as I can't make head or tails of CVS to save my life [05:30] but the project is very important to me [05:30] so I struggle on ;-) [05:31] right now I'm using git-cvs to track it [05:31] which works pretty well, but I'm trying to convert all my git stuff to bzr [05:32] mwhudson: is it possible to just start the import later? [05:32] LaserJock: if you run cscvs by hand maaaybe [05:33] this is one thing I keep running into with DVCS [05:33] I would verrrry rarely need to go to revision 1 [05:33] but often times if something breaks somewhere in history the whole thing is screwed [05:34] it would be nice to just say "gimme the stuff from the last year" [05:34] if that makes any sense :-) [05:36] 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] 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] LaserJock: well, the "Last imported: 28 weeks ago" on https://code.edge.launchpad.net/gchemutils/trunk is a pretty large clue [05:37] yeah, for that one sure [05:37] but there's nothing like a failure flag or something? [05:37] this should, and soon-ish will be, on the branch page [05:37] hm, no [05:38] probably should be though [05:38] LaserJock: file a bug about that? [05:38] ok [05:38] I'm just concerned [05:38] because when somebody says "are you building from HEAD?" I need to be able to confidently reply [05:39] not, "well let me go poke around to make sure LP is up-to-date" [05:40] I guess it's good enough for users [05:41] well, i can't really see how you can be sure [05:41] but if you're hacking on irc with fellow developers it's not really gonna work [05:41] i mean, the imports lag by a few hours on average [05:41] well, that's sort of my point [05:42] well, how can launchpad know it's out of date? [05:42] well [05:42] it can't exactly [05:42] there is a sort of plan floating around where launchpad should be able to subscribe to a commits mailing list [05:42] and will update whenever it receives a mail [05:42] but I wonder if you could somehow give a time since last import [05:43] but i don't think it's even written down, never mind scheduled [05:43] https://edge.launchpad.net/drupal/main -> "Last imported: 28 minutes ago" [05:43] bottom line though, LP vcsimports are not really designed for developers methinks [05:43] lifeless: hi, are transactions meant to be getting removed? [05:44] ie the control_files.get_transaction and so on? [05:44] yah [05:44] I didn't break api but I stopped their use in stores in 1.4 [05:44] branch may still use them [05:44] ok [05:44] as i may have said yesterday [05:45] i think removing LockableFiles is becoming more important, to enable improvements in Remote [05:45] so if less stuff uses them, and we can either just delete them or at least have less to update [05:45] all the better [05:46] 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] spiv: yes [05:46] spiv: it's on the cards [05:49] mwhudson: bug filed [05:49] Hey all... are there docs somewhere about how to log to .bzr.log? I'm trying to debug bzr-email. [05:52] awmcclain: "from bzrlib.trace import mutter; mutter('this goes to the log file')" [05:52] awmcclain: see the bzrlib.trace module in general [06:56] poolie: I think having less stuff use them is good [07:07] lifeless: i want to bounce a testing idea off you [07:07] 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] eventually we want similar assertions on smaller levels [07:08] such tests are one of the things I had in mind with the lock hooks [07:08] 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] me too [07:08] great [07:13] lifeless, was that actually merged yet? [07:14] abentley: BB is down :? [07:21] poolie: dunno [07:33] \o/ [07:34] bug 225020 [07:34] Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [Undecided,New] https://launchpad.net/bugs/225020 [07:44] spiv: how did my branch look? [07:50] lifeless: Haven't looked yet, I've been pairing with poolie [07:50] lifeless: I expect to do it tonight and first thing tomorrow, though. [07:51] cool [07:54] poolie: I have the mapping code looking good; was rather confused by the apparent double-escaping [07:54] 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] and with that, its halt() time for me. See you tomorrow. [07:58] hi sabdf1, bye sabdfl :) [08:46] night lifeless === sabdf1 is now known as sabdfl === Af1 is now known as AfC === mrevell is now known as mrevell-bbl [12:58] 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] 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? === mrevell-bbl is now known as mrevell [13:42] james_w: I think so. [13:43] spiv: thanks. [13:45] 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] lamby: Thanks! [13:45] jelmer: I did manage to patch a few other problems, which almost certainly need to go upstream. [13:45] lamby: Shiny log being "bzr viz" ? :-) [13:46] Indeed. To be clear, it only breaks when you load it via olive-gtk. [13:46] ahh, ok. I don't use olive so that must be why I've missed it [13:47] The other patches are in debian/patches on our alioth repo. Enjoy o/ [13:47] lamby: Cool, thanks again :-) [14:02] jelmer: Confirm that "bzr viz" doesn't work via olive [14:03] jelmer: I meant to put a bug up for it... [14:05] What is abentley doing to the main BB server? It's always down... [14:06] awilkins: I'm trying to fix it. [14:06] I suppose that's logical ;-) [14:09] 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] 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] Yeah, that could be an attempt to treat something as a merge directive that is really a bundle or a patch. [14:22] I ran into that a while back, but I can't remember whether I fixed it. [14:24] jelmer: are you up-to-date with my changes? [14:24] 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] Looks like I fixed it in revno 242 [14:30] It would be a merge request *without* a patch, actually. [14:35] crap, updating actually broke bundlebuggy altogether [14:43] jelmer: I've changed the way mail is handled in BB, to deal with the fact that BB's been unstable. [14:43] Now procmail delivers mail to a mail_queue directory, and BB checks for new mail there. [14:46] jelmer: But it looks as if your problem is you haven't updated the database schema. [14:47] The migrate script should do that for you. [18:11] abentley, thanks [18:12] jelmer: np [18:18] 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] vila: No, sorry. [18:20] 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] abentley: Did you improve performance in bb by any chance? [18:21] it seems significantly faster to me [18:21] jelmer: Yes, I have done some optimization. [18:59] 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] abentley: it still redirects to localhost:8089 after voting using the web interface [19:07] jelmer: that uses the application root. If you've got that configured correctly it should take you to the correct place. [19:08] jelmer: try configuring server.webpath [19:11] abentley: it's the host name that it doesn't get right, the path in the request is fine [19:12] is there an option for that? [19:12] yes. [19:12] I use: base_url_filter.on = True [19:12] base_url_filter.use_x_forwarded_host = True [19:13] You can also specify the base url yourself. [19:13] Are you running using dev.cfg or prod.cfg? [19:13] Wait, when using bzr+ssh, autopacking isn't done by the server? [19:14] Peng: Correct. [19:14] Peng, no, autopacking is always done client-side, AFAIK [19:14] Oh. [19:14] I thought it was done by the server. [19:14] Maybe someone said that it was a possibility (which it is), and I misinterpreted it. [19:14] That's how we'd like it to work, not how it works right now. [19:17] Yeah. [19:17] Huh. [19:18] * Peng leaves. [19:40] 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] 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] s/only/ only cause/ [19:43] Grr, I hate blind debugging :-( [20:25] Ack, now push-and-update is getting DeprecationWarnings in bzr.dev. [20:25] Thanks to install_hook. [20:36] Think it's worth enabling the "bzr://" smart protocol on a server? [21:01] Peng: push-and-update should be fixed for install_named_hook [21:01] as should bzr-email === ja1 is now known as jam [21:01] well, at least once my commit finishes [21:01] Yay. [21:06] Wait, when does push-and-update's hook come into effect? [21:06] Peng: it has to register itself at plugin load time [21:06] so it is calling install_hook all the time [21:07] the hook isn't being called, but it needs to be installed [21:07] Yeah, but when does it actually do its thing? On every push? [21:08] 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] Huh. [21:08] 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] I didn't know that. [21:09] I think I also included a hacky workaround to get it to not complain about "this transport does not update the WT" [21:10] Yes, you did. [21:39] jam: Do you know where I can find how pqm run the test suite ? [21:39] vila: make check [21:39] vila: so "Makefile" has the details [21:39] jam: grrr, thanks a lot ;-) [21:40] it should be something like "python -O -Werror ./bzr selftest" and "LANG=C ..." [21:41] lol, import docutils [21:41] ImportError: No module named docutils [21:41] :-) [21:41] Bad vila [21:48] 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] metameme: I believe we added a specific hook for it in bzr 1.4, if not, it will be in 1.5 [21:52] prior versions didn't quite have enough info [21:52] ATM, bzr-email is not directly able to do it, because the hook is newer [21:52] jam: Okay, thanks. It'll be a great feature to have. [21:53] metameme: I believe someone already put together code with the older format, which runs as a cron script [21:53] and just detects new revisions and emails them out [22:05] abentley, how do I know whether I'm using dev.cfg or prod.cfg? [22:11] jelmer, jam: did you run test-gtk lately ? One test is failing: test_diff_view [22:12] vila: I don't think jelmer ever runs test-gtk, and I haven't done any hacking on it for a while [22:12] the bzr-gtk project is *not* TDD [22:12] bbiab [22:12] hmm, bad Jelmer :) [22:13] 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] 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] If you are getting lots of stuff spewed to the console, you are running dev.cfg. [22:15] abentley: Looks like I'm using dev.cfg then :-) [22:15] The base_url bits you mentioned seem to work, thanks! [22:15] No problem. [22:16] it would be nice if these two settings were mentioned in the example dev.cfg for new bundlebuggy users.. [22:16] vila: Well, GUI unit testing is kinda hard [22:17] jelmer: no worries, just joking, what about the other points ^ [22:17] vila: Which ones? [22:17] 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] One test is failing: test_diff_view [22:19] and, about the po files, how are you handling them ? [22:19] abentley: Should mail_queue_location point to a mbox or maildir ? [22:19] I tried genpot.sh but it broke and seems old [22:19] vila: phanatic is handling all of the i18n stuff [22:19] vila: We still need a PQM to make sure we don't get regressions like that [22:19] lifeless, ping [22:20] phanaric: ping (arf, not even online :) [22:21] phanatic: ping (arf, not even online, but not a reason to typoed his nick :) [22:25] jelmer: It should point to a directory, not a maildir in particular. [22:26] You can point it at the maildir/new, if you like. [22:29] jelmer: Heh, fastest upstream merge evarr. (Thanks) === mwhudson_ is now known as mwhudson === BasicPRO is now known as BasicOSX [22:48] jelmer: hi [22:48] jelmer: pqm right? [22:48] lifeless: you can read minds :-) [22:57]