#bzr 2008-05-01 <nekohayo> hmm any ideas? <jam> nekohayo: something about that machine <jam> and I don't think I have access to it <vila> jam: wow, you're damn right, on my Ubuntu box I see: <jam> lifeless, pool? <jam> poolie: ? <vila> ...vice.LaunchpadServiceTests.test_unknown_service OK 0ms <nekohayo> jam, what machine? <jam> nekohayo: the PQM machine <jam> things seem to run fine locally, but running very slow on our merge bot <jam> https://pqm.bazaar-vcs.org/ <nekohayo> no I meant for http://ecchi.ca:8000/bzr-question-spiced-ham.htm :) <nekohayo> (unless this is related?) <jam> nekohayo: sorry, completely unrelated, I didn't see your IRC post at all <poolie> jam, hi <vila> hi poolie <nekohayo> (that is a big question that I wrote as a html page to avoid spamming :) <poolie> nekohayo: can you post it to the list instead, it looks like it will take some thinking about <jam> nekohayo: what do you mean by "specto used cvs, svn, and bazaar, all with branches that lost history between the switches" <jam> ? <nekohayo> jam, I mean that specto, across its lifetime as a project, used 3 different version control systems <nekohayo> and each time, we did not keep the history <jam> nekohayo: converting from svn and converting from CVS do not generate conversions that are compatible <jam> hence why you saw the big set of conflicts. <nekohayo> jam: uh? but the merge of the bzr-svn branch into the cvs one only created 4 minor conflicts (I think) <vila> jam, poolie: A new request arrived on pqm, but that's the only change, still at the same test... puzzling <jam> nekohayo: well, if you can post to the list, I agree with poolie, it is going to take a bit of thinking <nekohayo> merging the specto-woutc bzr branch into the new cvs+svn branch did the big conflicts though <nekohayo> ok <jam> if you can give some details about what is *in* the different branches, it would help. <jam> we have a phone call right now <jam> vila: different processes <vila> jam: I guess so. Well, time to sleep then, I'll see how it goes tomorrow :) <lifeless> jam: ? <keithy> Hi, I was using bzr ftp:// <keithy> and it seams to use directories relative tot he root of the file system <poolie> i don't have any great ideas about pqm performance <poolie> i am seeing some tests failing inside pycurl <poolie> this is odd <keithy> but how does it manage that , when I login using ftp myself I dont see the root of the file system <bob2> keithy: can you cd / when you login using a ftp client? <keithy> ah.. it it appears so <keithy> duh <poolie> keithy: i think you can use //host/~/foo <poolie> if you wish <poolie> hello bob2 <keithy> ty <spiv> jam: I have a test for your bug, sending it to the list <lifeless> the machine is not dedicated solely to bzr <lifeless> its possible there is some other load <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 <jam> lifeless: further, pqm seems a bit wedged <jam> It has been showing the same step of Vincent's patch for ~1hr <jam> spiv: thanks <poolie> spiv, i feel like we ought to have a coding standard about isinstance vs type etc <poolie> if only to avoid it being rehashed in every review <poolie> maybe also to document which one is fastest <jam> spiv: bb:approve <spiv> poolie: That sounds good to me. <lifeless> top - 00:48:14 up 220 days, 4:25, 1 user, load average: 0.07, 0.06, 0.07 <poolie> jeez firefox is flakey recently <poolie> lifeless: that's pqm? <lifeless> yes <lifeless> its running just the bzr test at the moment, no other things interfering <TFKyle> hmm, bb over IRC, interesting <abentley> TFKyle: please no <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 <lifeless> yes <elmo> the machine's entirely idle; it's not blocking on io <elmo> 1 0 5392 122888 130552 1489500 0 0 0 0 102 22 0 0 100 0 <elmo> 1 0 5392 122888 130552 1489500 0 0 0 0 103 26 0 0 100 0 <elmo> ^-- vmstat output <poolie> thanks elmo <poolie> 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 <lifeless> spiv: ping <poolie> could either of you maybe strace the process to get some idea of what it is doing? <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 <spiv> lifeless: ah-hah. I was just looking over that code yesterday to get a sense for what was coming :) <spiv> lifeless: So I'm happy to review that. <elmo> poolie: strace says it's in a futex and not much more <keithy> hello, can I break a lock on a repo? <spiv> Yep, "bzr break-lock PATH" <keithy> ty <poolie> elmo: thanks * igc food <poolie> has anyone else seen bug 225020? <spiv> poolie: I have <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) <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. <spiv> (I only upgraded to hardy a month ago) <spiv> poolie: "echo raise ImportError > pycurl.py" in the root of your bzr checkout is a workaround, of sorts. <poolie> :/ <poolie> also, why didn't the robot link that bug, i wonder? <spiv> Is the robot in the channel? <spiv> I see ubuntulog, but not ubotu or whatever it is called. <poolie> ubugtu? <bimberi> ubotu is currently gone, I think that work is being done on replacements. <bimberi> Ref: https://lists.ubuntu.com/archives/ubuntu-irc/2008-April/000443.html <poolie> spiv, btw last night i started work on deprecating LockableFiles from a different direction and it went quite well <poolie> it may be i just haven't got to the hard part yet <spiv> poolie: oh, great! <poolie> bimberi: thanks for the reference, that's kind of unfortunate though <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. <poolie> i don't know many of the people in that thread but it's an unfortunate sounding situation <poolie> spiv, maybe it only happens with -Werror and it actually reflects an error in the server code? <abentley> poolie: where do we stand with bzr 1.4? <poolie> it looks like we want to merge #214894 into it, i'm reading that and will do final today with only that change? <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. <spiv> Ah, I think I still have the straces somewhere. <spiv> The straces also showed no error return from poll(2) either, IIRC. <abentley> "Should be represented as XXX"? <spiv> poolie: http://rafb.net/p/dlbvkD76.html <spiv> abentley: d'oh. <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. <poolie> abentley: what are you quoting? <spiv> poolie: but the server behaved correctly (and as expected), that test server does not allow POST <abentley> poolie: I'm quoting a comment from spiv's patch for #214894 <spiv> My test had a half-written comment. <poolie> oh ok <poolie> abentley: pqm seems unreasonably slow today for unclear reasons <poolie> not sure if you saw before <poolie> :/ <abentley> No, I wasn't sure what you guys were stracing. <poolie> i was going to put this text at the head of the release <poolie> http://rafb.net/p/JNXf7H59.html <poolie> spiv, my shelves turned up so after i send off this merge i will head to hornsby if that suits you <poolie> will probably lunch here first <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. <spiv> poolie: sounds good <abentley> spiv: heh! <spiv> abentley: thanks for catching that :) <abentley> spiv: no problem. <abentley> I wish I'd had the option a few days ago when I accidentally merged the wrong branch. <spiv> Hmm, PQM isn't so much slow as wedged, AFAICS. <lifeless> poolie: ping <poolie> pong <poolie> lifeless: pong <lifeless> I'm trying to figure out store url escaping <poolie> k <lifeless> I seem to be getting double escaping <poolie> ok <poolie> sorry to interrupt you but pqm seems to be barely making progress at all <poolie> it is according to the web still working on the same job it was when i started this morning <lifeless> its hung on a futex <poolie> oh, hung as opposed to just spending lots of time in futexes? <lifeless> pqm@balleny:~$ strace -p 16075 <lifeless> Process 16075 attached - interrupt to quit <lifeless> futex(0x1a30e90, FUTEX_WAIT, 0, NULL <unfinished ...> <lifeless> Process 16075 detached <poolie> maybe we should kill it and let the next job through then? <lifeless> done <poolie> thanks <poolie> so back to your escapism <lifeless> test_escaped_store <lifeless> has a test_weave in it <lifeless> as far as I can tell, it should be double escaping with bzr.dev <poolie> not sure what you're asking me - to check your logic, if this is a bug, why it is this way, ...? <igc> lifeless: wrt MutableTree.put_file_bytes_non_atomic, why "non_atomic" as a suffix? <lifeless> because its not atomic <poolie> igc, it means "don't do the rename-into-place thing" <poolie> people reading the file may see it half-written <poolie> could be good to put that in the developer guide <igc> poolie, lifeless: ah - ok <igc> the wt.put_file_bytes_non_atomic docstring refers to the MutableTree one but the latter doesn't exist <igc> I'll add it <lifeless> poolie: I'm trying to figure out what is going on <lifeless> poolie: e.g. store.filename(' ') -> '88/%2520' <lifeless> poolie: but the test looks for '88/%20' successfully <lifeless> my replacement mapper code returns the same result from filename <lifeless> but the test fails (because the file on disk is 88/%2520.weave) <lifeless> ah I think I have found it <LaserJock> is there a recommended way to use bzr to track a cvs repo? would cvsps work? <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 <lifeless> launchpad <lifeless> or cscvs which is what launchpad uses <LaserJock> well, yeah, launchpad could work if it was up-to-date <lifeless> it tries hard to handle just about any stupidity people do to cvs <LaserJock> but it frequently lags <LaserJock> maybe the best would be to just keep a close eye on the LP import and keep poking * igc food <mwhudson> LaserJock: which import? <LaserJock> the one I want to track is about 5 months behind or so :/ <LaserJock> mwhudson: https://code.launchpad.net/~vcs-imports/gchemutils/trunk <LaserJock> it's just difficult to have to keep track of LP <LaserJock> I end up tacking the CVS anyway just to make sure I'm not missing stuff <mwhudson> oh and gah, we lost all the code imports log files earlier on today * mwhudson gives the import a kick <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 <LaserJock> it's also the only one that is CVS, which may explain it <mwhudson> LaserJock: it's https://bugs.edge.launchpad.net/launchpad-cscvs/+bug/120977 :( <mwhudson> so it's not going to start working again until we get some time to fix that <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) <LaserJock> bummer :/ <mwhudson> yar <LaserJock> that's the one I especially would love to work with in bzr <LaserJock> as I can't make head or tails of CVS to save my life <LaserJock> but the project is very important to me <LaserJock> so I struggle on ;-) <LaserJock> right now I'm using git-cvs to track it <LaserJock> which works pretty well, but I'm trying to convert all my git stuff to bzr <LaserJock> mwhudson: is it possible to just start the import later? <mwhudson> LaserJock: if you run cscvs by hand maaaybe <LaserJock> this is one thing I keep running into with DVCS <LaserJock> I would verrrry rarely need to go to revision 1 <LaserJock> but often times if something breaks somewhere in history the whole thing is screwed <LaserJock> it would be nice to just say "gimme the stuff from the last year" <LaserJock> if that makes any sense :-) <LaserJock> mwhudson: is there a way for users to see if a vcsimport is out of sync without having to get the original repo? <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 <mwhudson> LaserJock: well, the "Last imported: 28 weeks ago" on https://code.edge.launchpad.net/gchemutils/trunk is a pretty large clue <LaserJock> yeah, for that one sure <LaserJock> but there's nothing like a failure flag or something? <mwhudson> this should, and soon-ish will be, on the branch page <mwhudson> hm, no <mwhudson> probably should be though <mwhudson> LaserJock: file a bug about that? <LaserJock> ok <LaserJock> I'm just concerned <LaserJock> because when somebody says "are you building from HEAD?" I need to be able to confidently reply <LaserJock> not, "well let me go poke around to make sure LP is up-to-date" <LaserJock> I guess it's good enough for users <mwhudson> well, i can't really see how you can be sure <LaserJock> but if you're hacking on irc with fellow developers it's not really gonna work <mwhudson> i mean, the imports lag by a few hours on average <LaserJock> well, that's sort of my point <mwhudson> well, how can launchpad know it's out of date? <LaserJock> well <LaserJock> it can't exactly <mwhudson> there is a sort of plan floating around where launchpad should be able to subscribe to a commits mailing list <mwhudson> and will update whenever it receives a mail <LaserJock> but I wonder if you could somehow give a time since last import <mwhudson> but i don't think it's even written down, never mind scheduled <mwhudson> https://edge.launchpad.net/drupal/main -> "Last imported: 28 minutes ago" <LaserJock> bottom line though, LP vcsimports are not really designed for developers methinks <poolie> lifeless: hi, are transactions meant to be getting removed? <poolie> ie the control_files.get_transaction and so on? <lifeless> yah <lifeless> I didn't break api but I stopped their use in stores in 1.4 <lifeless> branch may still use them <poolie> ok <poolie> as i may have said yesterday <poolie> i think removing LockableFiles is becoming more important, to enable improvements in Remote <poolie> so if less stuff uses them, and we can either just delete them or at least have less to update <poolie> all the better <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. <mwhudson> spiv: yes <mwhudson> spiv: it's on the cards <LaserJock> mwhudson: bug filed <awmcclain> Hey all... are there docs somewhere about how to log to .bzr.log? I'm trying to debug bzr-email. <spiv> awmcclain: "from bzrlib.trace import mutter; mutter('this goes to the log file')" <spiv> awmcclain: see the bzrlib.trace module in general <lifeless> poolie: I think having less stuff use them is good <poolie> lifeless: i want to bounce a testing idea off you <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 <poolie> eventually we want similar assertions on smaller levels <lifeless> such tests are one of the things I had in mind with the lock hooks <poolie> but since people sometimes add "oh and also" code to the cmd_ it might be good to cover it at a high level <poolie> me too <poolie> great <poolie> lifeless, was that actually merged yet? <poolie> abentley: BB is down :? <lifeless> poolie: dunno <bimberi> \o/ <bimberi> bug 225020 <ubottu> Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [Undecided,New] https://launchpad.net/bugs/225020 <lifeless> spiv: how did my branch look? <spiv> lifeless: Haven't looked yet, I've been pairing with poolie <spiv> lifeless: I expect to do it tonight and first thing tomorrow, though. <lifeless> cool <lifeless> poolie: I have the mapping code looking good; was rather confused by the apparent double-escaping <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 <lifeless> and with that, its halt() time for me. See you tomorrow. <lifeless> hi sabdf1, bye sabdfl :) <sabdf1> night lifeless <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? <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? <spiv> james_w: I think so. <james_w> spiv: thanks. <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) :'( <jelmer> lamby: Thanks! <lamby> jelmer: I did manage to patch a few other problems, which almost certainly need to go upstream. <jelmer> lamby: Shiny log being "bzr viz" ? :-) <lamby> Indeed. To be clear, it only breaks when you load it via olive-gtk. <jelmer> ahh, ok. I don't use olive so that must be why I've missed it <lamby> The other patches are in debian/patches on our alioth repo. Enjoy o/ <jelmer> lamby: Cool, thanks again :-) <awilkins> jelmer: Confirm that "bzr viz" doesn't work via olive <awilkins> jelmer: I meant to put a bug up for it... <awilkins> What is abentley doing to the main BB server? It's always down... <abentley> awilkins: I'm trying to fix it. <awilkins> I suppose that's logical ;-) <abentley> Unfortunately, there appear to be bugs in the visitor tracking part of Turbogears that are threading bugs that I can't reproduce locally. <jelmer> abentley: btw, do you have any idea what could cause this: http://bundlebuggy.vernstok.nlrodriguezcrystal@example.org%3E <abentley> Yeah, that could be an attempt to treat something as a merge directive that is really a bundle or a patch. <abentley> I ran into that a while back, but I can't remember whether I fixed it. <abentley> jelmer: are you up-to-date with my changes? <jelmer> I'm running my own branch, which has the RSS support but may not be up to date * jelmer checks for missing revs <abentley> Looks like I fixed it in revno 242 <abentley> It would be a merge request *without* a patch, actually. <jelmer> crap, updating actually broke bundlebuggy altogether <abentley> jelmer: I've changed the way mail is handled in BB, to deal with the fact that BB's been unstable. <abentley> Now procmail delivers mail to a mail_queue directory, and BB checks for new mail there. <abentley> jelmer: But it looks as if your problem is you haven't updated the database schema. <abentley> The migrate script should do that for you. <jelmer> abentley, thanks <abentley> jelmer: np <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) <abentley> vila: No, sorry. <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... <jelmer> abentley: Did you improve performance in bb by any chance? <jelmer> it seems significantly faster to me <abentley> jelmer: Yes, I have done some optimization. <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. <jelmer> abentley: it still redirects to localhost:8089 after voting using the web interface <abentley> jelmer: that uses the application root. If you've got that configured correctly it should take you to the correct place. <abentley> jelmer: try configuring server.webpath <jelmer> abentley: it's the host name that it doesn't get right, the path in the request is fine <jelmer> is there an option for that? <abentley> yes. <abentley> I use: base_url_filter.on = True <abentley> base_url_filter.use_x_forwarded_host = True <abentley> You can also specify the base url yourself. <abentley> Are you running using dev.cfg or prod.cfg? <Peng> Wait, when using bzr+ssh, autopacking isn't done by the server? <abentley> Peng: Correct. <beuno> Peng, no, autopacking is always done client-side, AFAIK <Peng> Oh. <Peng> I thought it was done by the server. <Peng> Maybe someone said that it was a possibility (which it is), and I misinterpreted it. <abentley> That's how we'd like it to work, not how it works right now. <Peng> Yeah. <Peng> Huh. * Peng leaves. <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 :-/ <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... <vila> s/only/ only cause/ <vila> Grr, I hate blind debugging :-( <Peng> Ack, now push-and-update is getting DeprecationWarnings in bzr.dev. <Peng> Thanks to install_hook. <Peng> Think it's worth enabling the "bzr://" smart protocol on a server? <ja1> Peng: push-and-update should be fixed for install_named_hook <ja1> as should bzr-email <jam> well, at least once my commit finishes <Peng> Yay. <Peng> Wait, when does push-and-update's hook come into effect? <jam> Peng: it has to register itself at plugin load time <jam> so it is calling install_hook all the time <jam> the hook isn't being called, but it needs to be installed <Peng> Yeah, but when does it actually do its thing? On every push? <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' <Peng> Huh. <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 <Peng> I didn't know that. <jam> I think I also included a hacky workaround to get it to not complain about "this transport does not update the WT" <Peng> Yes, you did. <vila> jam: Do you know where I can find how pqm run the test suite ? <jam> vila: make check <jam> vila: so "Makefile" has the details <vila> jam: grrr, thanks a lot ;-) <jam> it should be something like "python -O -Werror ./bzr selftest" and "LANG=C ..." <vila> lol, import docutils <vila> ImportError: No module named docutils <vila> :-) <vila> Bad vila <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? <jam> metameme: I believe we added a specific hook for it in bzr 1.4, if not, it will be in 1.5 <jam> prior versions didn't quite have enough info <jam> ATM, bzr-email is not directly able to do it, because the hook is newer <metameme> jam: Okay, thanks. It'll be a great feature to have. <jam> metameme: I believe someone already put together code with the older format, which runs as a cron script <jam> and just detects new revisions and emails them out <jelmer> abentley, how do I know whether I'm using dev.cfg or prod.cfg? <vila> jelmer, jam: did you run test-gtk lately ? One test is failing: test_diff_view <jam> vila: I don't think jelmer ever runs test-gtk, and I haven't done any hacking on it for a while <jam> the bzr-gtk project is *not* TDD <jam> bbiab <vila> hmm, bad Jelmer :) <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 ? <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. <abentley> If you are getting lots of stuff spewed to the console, you are running dev.cfg. <jelmer> abentley: Looks like I'm using dev.cfg then :-) <jelmer> The base_url bits you mentioned seem to work, thanks! <abentley> No problem. <jelmer> it would be nice if these two settings were mentioned in the example dev.cfg for new bundlebuggy users.. <jelmer> vila: Well, GUI unit testing is kinda hard <vila> jelmer: no worries, just joking, what about the other points ^ <jelmer> vila: Which ones? <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 ? <vila> One test is failing: test_diff_view <vila> and, about the po files, how are you handling them ? <jelmer> abentley: Should mail_queue_location point to a mbox or maildir ? <vila> I tried genpot.sh but it broke and seems old <jelmer> vila: phanatic is handling all of the i18n stuff <jelmer> vila: We still need a PQM to make sure we don't get regressions like that <jelmer> lifeless, ping <vila> phanaric: ping (arf, not even online :) <vila> phanatic: ping (arf, not even online, but not a reason to typoed his nick :) <abentley> jelmer: It should point to a directory, not a maildir in particular. <abentley> You can point it at the maildir/new, if you like. <lamby> jelmer: Heh, fastest upstream merge evarr. (Thanks) <lifeless> jelmer: hi <lifeless> jelmer: pqm right? <jelmer> lifeless: you can read minds :-) <vila> lifeless: read my mind too, you'll find pqm :-/ <lifeless> vila: no idea about your patch sorry <vila> lifeless: how about an interrupt to at least have a starting point on where it hangs ? <vila> Note that it is currently hanging for around 5 hours... <lifeless> the hang I saw it was waiting on a futex <lifeless> is it hung again? <vila> yes <lifeless> killed <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 :-( <lifeless> it runs within cron <lifeless> I can't pdb it when it hangs <vila> I see :( <lifeless> I can gdb but that is fiddly and much less useful <lifeless> it was waiting on futex <lifeless> that means its probably a server shutdown or some such <lifeless> this is your test-ids patch? <vila> the one changing test_suite() to load_tests() <vila> the only side-effect I see is that some tests are not run in the same order now, other than that.... <lifeless> thats entirely possible to cause such an effect <lifeless> if we have an isolation bug <vila> I tried running all tests in isolation (i.e. one by one with --load-list) and so far nothing serious popped out <lifeless> I don't think you should ignore basic_tests ever <vila> basic_tests ? <lifeless> + # since this module doesn't define tests, we ignore basic_tests <lifeless> suite = doctest.DocFileSuite(*scripts) <lifeless> anyhow, assume that its ordering. You need to run two tests minimum to display an ordering problem <lifeless> one easy way to show such a thing is to invert the entire test order <lifeless> vila: also <vila> hmmm, pqm is running make check, running make check is ok... <lifeless> basic_tests is a suite <lifeless> you don't ever have to do <lifeless> suite = loader.suiteClass() <lifeless> suite.addTests(basic_tests) <lifeless> just use basic_tests directly. <lifeless> bb:tweak :) <lifeless> you'll save lots of code <vila> right, I will do that anyway, but if it fixes the problem, I'll be really surprised <lifeless> this for loop <lifeless> + for test in tests.iter_suite_tests(standard_tests): <lifeless> + result.addTests(adapter.adapt(test)) <lifeless> seems to be cropping up multiple times <vila> :-) <vila> Yup, I didn't want to stretch the patch, but I noticed it <lifeless> ok, I've read the patch end to end <lifeless> those are my comments; I can't see anything to cause a random hang. <lifeless> there are two causes i can think of: <lifeless> - test ordering <lifeless> - test parameterisation <lifeless> if its an ordering bug, one would expect that running the entire test suite in opposite order would *probably* show it <lifeless> so a simple patch that adds reversed(list(iter_suite_tests(test_suite))) to the end of bzrlib.test_suite() <lifeless> or just before the runner <lifeless> might be enough to trigger and show the problem <vila> I'll try that. Can you elaborate on the parameterisation cause ? <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. <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) <vila> Granted, number of tests was a simple metric, but <vila> no but <lifeless> :) <lifeless> back in a few minutes, shave & breakfast <vila> arf, arf, false hope: <vila> FAIL: test_selftest.TestTestIdList.test_test_suite <vila> not equal: <vila> a = ['bzrlib.tests.blackbox.test_branch.TestBranch.test_branch', <vila> 'bzrlib.tests.test_selftest.TestTestIdList.test_test_suite', <vila> 'bzrlib.tests.test_transport_implementations.TransportTests.test_abspath(LocalURLServer)', <vila> 'bzrlib.timestamp.format_highres_date'] <vila> b = ['bzrlib.timestamp.format_highres_date', <vila> 'bzrlib.tests.test_transport_implementations.TransportTests.test_abspath(LocalURLServer)', <vila> 'bzrlib.tests.test_selftest.TestTestIdList.test_test_suite', <vila> 'bzrlib.tests.blackbox.test_branch.TestBranch.test_branch'] <lifeless> spiv: when you arise, review ping <mwhudson> spiv: me too! <mwhudson> :) <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 ?). <lifeless> pam? <lifeless> if you mean pqm, its running dapper * Peng looks at the topic. <Peng> Today today? Cool. <bob2> it said that yesterday, too ;) <Peng> The topic was set 23 hours ago. <vila> lifeless: s/azerty/qwerty/ :) yes pqm, python2.4 ? #bzr 2008-05-02 <lifeless> 2.4.2 <ig1> morning <vila> lifeless: bingo ! I can reproduce it with python-2.4.4 <lifeless> cool <vila> not accpepting interrupts though :) <lifeless> spiv: ping <spiv> lifeless: hi, just about to dive into your review <lifeless> spiv: thanks <lifeless> I have an updated deprecations patch <lifeless> and I missed a couple of trivial uses of vf.join() <bob2> http://blog.red-bean.com/sussman/?p=90 <lifeless> spiv: if you want to talk about the branch I'm happy to do a clal <igc> lifeless: thanks for the detailed response to my filtering brain dump <lifeless> igc: eh, that was just a off the cuff :) <igc> np - I'm reviewing jam's patch right now and I'll digest your wisdom after that :-) <lifeless> igc: I haven't had time to give a proper analysis, but its a complex problem to do really well which is why I was so keen for us to layer it with the minimum <igc> lifeless: Agreed. I'll move the conversation to the mailing list so others can chime in as well. <poolie> igc, i think it may be ok to not worry right now about how to reapply all your filters to the tree <poolie> perhaps it does need to be fixed before we really announce it <igc> poolie: ok. I'll send an email anyway to give people time to think about it how it ought to work <poolie> mm <poolie> i should probably not think about it today, have too much more urgent stuff <igc> poolie: np - I can't implement a solution till next Tues at the earliest anyway <lifeless> poolie: igc: I think we need *a* method to reset a tree to the current filtered contents <lifeless> if 'bzr revert' did nothing, it would be most frustrating for people :) <poolie> i agree <poolie> lifeless: but things like update that normally do a 3way merge will be more difficult - they don't have the output from the old filter to merge against afaics <poolie> lifeless: re your patch <poolie> removing deprecated code <poolie> is there a current equivalent to MultipleRevisionSources? <poolie> like if we wanted to fix the problem of missing doing a fetch, is that easy with the current apis? <lifeless> poolie: 'update' should be fine as long as you reset the tree to match the filters before you update <lifeless> poolie: because it will always be merging the canonical forms <lifeless> poolie: MultipleRevisionSources is already unused <lifeless> and deprecated <lifeless> graph.ParentsProvider has cleaner functionality <igc> lifeless, poolie: email sent to the list now on this topic <igc> I need to focus on reviewing jam's patch right now so I'll digest everyone's input next week <poolie> lifeless: yes i saw it was deprecated <lifeless> spiv: updated patch sent; trivial changes <spiv> lifeless: thanks <lifeless> spiv: how is it looking ? <spiv> Pretty good. <spiv> No fundamental "wtf" issues :) <spiv> So far, anyway ;) * poolie changed the topic of #bzr to: Bazaar version control system | * poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | bzr-1.4 out, May 2 <hersonls> poolie: New bazaar version now? <hersonls> :D <spiv> poolie: hooray! <spiv> poolie: I'm about to head off to your place... should we meet for lunch? <poolie> spiv, sure, call me when you get to the station <poolie> hersonls: yes <poolie> spiv, i may not be able to work on hpss right away but come on anyhow <hersonls> poolie: Good :D <spiv> poolie: ok <lifeless> spiv: review is done ? <spiv> lifeless: not yet, will continue on the train <lifeless> ok <abentley> lifeless: spent any time in Dunedin? <lifeless> abentley: born and bred <abentley> I'll be there on Sunday. Anything I should see and/or do? <lifeless> the city gardens are beautiful <lifeless> they have some of the rare and endangered bird species there <lifeless> mmm winter, won'y suggest sandfly bay <poolie> abentley: when i was there i went out on the peninsula south of town <lifeless> the albatross colony might be open though, thats well worth a visit; and if you like beaches head out to the spit <abentley> Sandfly bay? That sounds kinda ominous. <poolie> they have penguin and albatross nests <poolie> and giant sheep <lifeless> poolie: thats NE of town :) <poolie> maybe it moved :P <abentley> Cool. Thanks for the suggestions. <lifeless> there are a number of nice lookouts, the one back of the quarry has a particularly good view of the city <lifeless> heading up mt cargill can be nice too <lifeless> its a uni town, I'm totally positive you'll be able to find an open mic as wlel <abentley> Hehe. <lifeless> really, I think its something like 10% population is floating students <lifeless> the whole place ebbs and flows to the university holiday schedule <mwhudson> it's like the last week of term i think <mwhudson> (at least it is at massey) <abentley> Hmm. Yeah, I guess the only real university town I've been to is New Haven, Connecticut. Toronto and Montreal have universities, but they're also big cities. <lifeless> oh,if the mei wah fish and chip shop is open, or the golden sun beside it, try some. One if unforgettably terrible, and one unforgettably good (or was 12 years ago). <lifeless> I won't tell you which is which :) <abentley> poolie: congrats on the 1.4ness <poolie> thanks, sorry for the delay <poolie> now for pqm toil <poolie> fortunately it is getting more automated each time - i just sent a patch deleting more steps from teh RM guide <abentley> lifeless: I'm a bit surprised common_ancestor is deprecated. I believe I'm still using it in graph-ancestry. <lifeless> abentley: deprecated in 1.4 <abentley> Ah, I'm actually using node_distances and select_farthest. <lifeless> :) <poolie> abentley: have a good trip btw <abentley> poolie: Thanks. <poolie> abentley: if by any chance you're still here: what was the case with lp push or pull that was slow for you? <lifeless> poolie: bzr branch <the code of launchpad itself> <lifeless> poolie: over hpss <lifeless> poolie: I think his mail didn't discriminate enough between using lp, and being lp :) <lifeless> spiv and I are aware of this and have both done some analysis <poolie> into an empty repo? <lifeless> poolie: no repo <lifeless> poolie: call ? <poolie> ok <abentley> poolie: It was branch <abentley> poolie: I'm in the middle of repeating it for you. <abentley> But the whole process takes > 1 hour * igc lunch and pick up kids -bbl <abentley> lifeless: I'm a bit lost on how to change ReconcilePacker to update sha1s. <lifeless> abentley: indeed <lifeless> abentley: it needs to override the revision bulk copy and have it occur after the inventory copy; during the inventory copy you'll need to determine what the correct sha1s are <lifeless> a subclass for the case where this is needed may be appropriate <abentley> In order to update the sha1s, I need to know the correct serializer, so I need the repository. Which seems like a layering violation. <lifeless> well the repository chooses the reconciler etc <lifeless> so it can pass in the serializer (though isn't the sha1 on disk always the correct one now ?) <lifeless> oh! it needs the revision serialiser <lifeless> I definitely think a subclass is appropriate here <abentley> Though perhaps if I need the repo anyway, I should be using repo methods. <abentley> lifeless: Is there any easy way of reading/writing fulltexts from a PackCollection? <lifeless> yes <lifeless> one sec <lifeless> you instantiate a KnitVersionedFile on the pack and a GraphIndex (for revisions|signatures|inventories|knits) <abentley> I can do that on a single pack, not the PackCollection? <lifeless> to read the old revisions I would do use the existing repositories iter_revisions or whatever <lifeless> you can, but there is no guarantee that you can read a given uncompressed text from a single pack <lifeless> basis texts may well be in different packs <lifeless> For reading revisions I would use the repositories methods <lifeless> for writing them serialising and adding is probably cleanest (see the output_knit variable around line 1062) <abentley> Not important for this case, since revisions are not (supposed to be) delta'd. <lifeless> the existing reconcile code does 'repo.weave_store.get_weave(file_id, transaction) to read texts <lifeless> that is by far the simplest way <abentley> Okay, thanks. <spiv> lifeless: review heading your way <lifeless> thanks <spiv> Hmm, or at least it will be once I sort out my mail delivery... <lifeless> :P <jrydberg> morning you hackers. <lifeless> where, where? <jrydberg> there, there. <jrydberg> sup robert? <lifeless> spiv: short story, is it tweak? bounce? approve? <spiv> lifeless: tweak <rockstar_> Morning? It's 2300 here! :) <lifeless> jrydberg: VersionedFiles is taking shape <lifeless> rockstar_: wait 46 minutes <poolie> starting ppa rebuild of 1.4 <spiv> lifeless: but if you want to bounce up and down, I won't stop you ;) <jrydberg> lifeless: Finally. <lifeless> jrydberg: well, there was a bunch of prep work to do :) <lifeless> jrydberg: how are you, haven't chatted in -ages- <jrydberg> lifeless: hehe. <jrydberg> lifeless: i'm fine, i'm fine. just trying to use computers are little as possible in my spare time. noticed that it helps my rodriguezcrystal@example.org. <poolie> jrydberg: heh, me too :) <poolie> or at least i am trying to be careful of that effect <jrydberg> i've turned to photography instead. <jrydberg> equally geeky, less computers. <lifeless> well thats 8 hours poolie <lifeless> poolie: so I'm calling it till Monday <lifeless> jrydberg: this is my solution, to be self strict about work | hobby time <spiv> lifeless: you should have that mail now <spiv> abentley: thanks for that log <abentley> spiv: No problem. <lifeless> well, I'll reply first :) <lifeless> then call the day <poolie> lifeless: can you read this one mail i'm going to send first? :) <poolie> about PPAs <lifeless> I think beta is overkill <lifeless> just use snapshot for betas <lifeless> IMO * lifeless waves <igc> night all - have a good weekend <igc> back Tuesday for me <vila> ok, I narrowed down my pqm hanging scenario, reproduced on gutsy with: <vila> python2.4 bzr selftest bzrlib.tests.test_strace.TestStrace.test_strace_callable_is_called bzrlib.tests.test_strace.TestStrace.test_strace_callable_result bzrlib.tests.blackbox.test_serve.TestBzrServe.test_bzr_connect_to_bzr_ssh <vila> any advice greatly appreciated while the diagnosis continues ;-) * fullermd has none whatosoever. <vila> fullermd: thanks for the warm moral support :-P * fullermd is helpful like that :] <fullermd> strace does sound like a good candidate for twisting up a machine, though. <vila> the puzzling bit is that I submitted a patch that first glance has strictly nothing to do with strace :) Neither at second glance FWIW <vila> and to make it funnier I can reproduce it on a single machine only while, still at first glance, the two are gutsy installs :) <fullermd> With strace installed? <fullermd> I know the tests skip without it (I don't have it installed) <vila> fullermd: excellent idea ! But both have the same version installed <vila> both says 'tests passed' (i.e. really late, nearly before exiting) but one hang after that <fullermd> Well, maybe strace isn't standard-installed, but one has it chosen as additional. <fullermd> I could believe that strace enables something that runs at cleanup time, so that could cause a late hang. <fullermd> (of course, I'm in pure speculation mode here, so I could well be making it up as I go along too :) <vila> I don't remember if I installed them myself, but that was through synaptic anyway, so both installs should be correct, but looking at the code I suspect something related to 'import subprocess' since these tests use that, there may be some weird interaction <vila> I think my patch just revealed a latent bug <vila> test_bzr_connect_to_bzr_ssh has several 'XXX' anyway <vila> spiv: are you still around by chance ? <fullermd> Great, you broke him. <vila> fullermd: damn :) <fullermd> That's talent. You exposed a latent bug in bzr _and_ spiv at the same time ;) <vila> fullermd: lol, I will meditate about that during lunch :) <jsled> I've a shared repo, with a branch 'trunk'. I've done `bzr branch trunk local`. Now, I'd like to rename 'local' to something else. Is it just "mv local something-else", or does bzr need to get involved, and if so, by what command? <james_w> jsled: "mv local something-else" is fine <james_w> jsled: bzr would need to get involved for something like "mv local /somewhere/else/entirely" <james_w> as long as you stay within the shared repo you should be ok. <jsled> thanks. :) <james_w> (assuming you don't move something inside another branch, or a repo in repo or similar) <visit0r> hi, is there someone using the bzr-hookless-email? for some reason it seems to hang and leak memory like crazy. <visit0r> File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 1520, in deserialise_inventory <visit0r> probably that's the hanging function <jelmer> dato: ping <jelmer> dato: your upload of bzr 1.3.1-1 doesn't appear to be in the bzr branch on alioth <chadmiller> Hi all. Has anyone tried reviewboard with Bazaar? It seems to have gotten some of Bazaar support lately. * chadmiller doesn't know how deep it goes. <jelmer> chadmiller: I think statik was the person who did most of the work on that <jelmer> statik, ^ <chadmiller> From the log, "Patch from Henrik Hedberg to add basic support for the Bazaar SCM." <chadmiller> That ain't statik. <jelmer> hmm, must be another branch than https://code.launchpad.net/~statik/reviewboard/bazaarsupport then that got merged.. <chadmiller> A related question: That patch has some questionable choices in it. Instead of importing bzrlib, it runs "bzr" with arguments and catches stdout. Is that as silly as I think it is? Do you consider the internal bzr APIs stable? <chadmiller> Or, rather, /is there/ a public API for bzr? <jelmer> ah, ouch <jelmer> there is a public API for bzr in Python (in which reviewboard is also written) <jelmer> that does indeed seem like a very questionable choice * lamont struggles to remember how to import a cvs tree into bzr <lamont> and finds it <surfous> I've got a local branch that is a checkout of a branch hosted in Launchpad... I've just done a bzr upgrade to upgrade the format. What's the proper way to get my remote master branch upgraded as well? It still appears to be of format BzrBranch5 <beuno> surfous, bzr upgrade sftp://rodriguezcrystal@example.org... <beuno> upgrading it through sftp on LP <beuno> but, be warned, it takes a while <surfous> beuno: Thanks for the info - I fear it's sending me on a tail-chase, though... <surfous> What prompted me to do this was trying to tag my branch. I got the following error: <surfous> bzr: ERROR: Tags not supported by BzrBranch5('bzr+ssh://rodriguezcrystal@example.org/%7Epyax/pyax/release/'); you may be able to use bzr upgrade --dirstate-tags. <surfous> I did a bzr upgrade which brought my format up to pack-0.92 <surfous> local format, that is <surfous> trying to upgrade the remote branch tells me: bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. <surfous> So one operation tells me I'm out of date, and the other tells me I'm up to date, when ultimately, I'm just confused. <jelmer> surfous, try upgrading over sftp rather than bzr+ssh <beuno> surfous, what does "bzr info -v" on the remote branch tell you? <surfous> jelmer: Cool, that seems to be doing more than what I had before... I'll see where that lands me. <surfous> beuno: surf@fischer:~/src/pyax/release$ bzr info -v bzr+ssh://rodriguezcrystal@example.org/%7Epyax/pyax/trunk <surfous> Standalone branch (format: unnamed) <surfous> Location: <surfous> branch root: bzr+ssh://rodriguezcrystal@example.org/%7Epyax/pyax/trunk/ <surfous> Format: <surfous> control: bzr remote bzrdir <surfous> branch: Remote BZR Branch <surfous> repository: bzr remote repository <surfous> Branch history: <surfous> 51 revisions <surfous> 4 committers <surfous> 371 days old <surfous> first revision: Thu 2007-04-26 10:50:37 -0700 <surfous> latest revision: Thu 2008-05-01 14:17:23 -0700 <surfous> Repository: <surfous> 63 revisions <surfous> 324 KiB <surfous> beuno: I know I referenced my release branch before, any this is on my trunk, but the problem was the same on each <beuno> surfous, right, for some reason, that's very uninformative, but upgrading through sftp is the way to go <surfous> beuno: And it does indeed take a while as you'd warned, but I've no problem waiting. <surfous> Thanks a lot for your help, beuno and jelmer! <beuno> surfous, :) <jelmer> abentley, hi <lamont> given a bzr 1.3.1 tree, bzr log says that the current revision is '47'. is there any trivial way to get that out of bzr short of resorting to perl/awk/sed/grep foolery? <beuno> lamont, bzr revno? <lamont> I knew there had to be something. thanks <beuno> :) <lamont> "version" and "revision" didn't give me what I wanted, so I decided that asking would be quicker. thanks again <beuno> nothing better then taking advantage of random knowledge on IRC! <beuno> *ignore me* #214825 <matkor_> Hi !. Is is possible to ignore all ".svn" dirs regardless how deep they are ? <james_w> does "bzr ignore .svn" not work? <matkor_> let me see ... <matkor_> james_w: Works, thank you very much <james_w> no problem <trepca> i have two branches ... trunk and branch1, people commit to trunk and also tag commits <trepca> how could i diff these two and only limit on tagged commits <james_w> I'm not sure that's possible <trepca> ok, thanks :) <james_w> you want to diff two branches but only show the changes that were introduced in one by certain commits? <trepca> trying to implement a code review <trepca> when people close a bug, they commit with a tag containing the bug id <trepca> laterz <trepca> night #bzr 2008-05-03 <dato> jelmer: oops, you're right. I guess I forgot to commit, and I can't find the branch now <dato> jelmer: so, I guess I'll create a commit and merge it tomorrow. I don't think you should've pushed, though, but never mind. <jelmer> dato: Well, it should be trivial to merge your commit into the current branch. I haven't uploaded anything yet <jelmer> dato: Mind if I just import-dsc the 1.4.1 release? <dato> so, a couple things <dato> are you interested in dm-upload-allowed: yes maintain it? <jelmer> dato: I'm interested in contributing to the maintainance of the bzr package <jelmer> i.e. doing uploads now and then if I have the time and nobody else is doing it <jelmer> not sure if that's what you're asking :-) <dato> ok <dato> so due to my fuck-up, I really think I should push --overwrite you... I would really dislike the idea of having a 1.4 in the branch that does not include the 1.3.1 changelog, what do you think? <jelmer> dato: oh, yes - I agree <dato> so it seems I've lost the commit, if it ever existed <dato> so I'll create a 1.3.1 commit, and push --overwrite <jelmer> k <dato> jelmer: done, going to bed. <jelmer> dato: thanks, goodnight <dato> jelmer: so, I'll upload bzr 1.4; I'll add the dm-upload bit <emgent> morning <matkor> Hmm, recent repo olive-gtk: <matkor> from bzrlib.plugins.gtk import icon_path <matkor> ImportError: cannot import name icon_path <matkor> ? <jelmer> dato: COol, thanks <dato> jelmer: I'm in a conference, just need to find a spot to do it :) <fullermd> jelmer: Are you working up to a bzr-gtk release? <jelmer> dato: k :-) <jelmer> fullermd, yep <fullermd> jelmer: May want to look at
{'channel': 'bzr', 'month': 5}