[00:00] jam: got an error☺incomplete request for that. [00:00] * AfC waves to jam [00:01] morning [00:01] * jam waves at AfC [00:01] jam: I just got an OK for the request... the problem was \r\n on win [00:02] brilliantnut: ah, ok [00:02] yeah, you need plain '\n' [00:02] so, the bzr smart server *is* up at that url [00:02] Good morning, Australasians. [00:03] Good morning. [00:05] brilliantnut: you can try something like: [00:05] echo -ne "BzrDir.find_repository\001.\n" | POST ... [00:06] It an return: norepository [00:06] or: ok☺☺no☺no [00:06] It *can* return one or the other [00:06] ok☺..☺no☺no [00:06] or even: error☺Not a branch: ... [00:07] brilliantnut: so we can find the repository.... [00:07] right. [00:07] brilliantnut: what path did you POST to, btw [00:07] Since it seems to say that the repository is found in ".." [00:07] http://@/bzr/HEAD/.bzr/smart [00:08] vila: have you seen https://bugs.edge.launchpad.net/bzr/+bug/230223 ? [00:08] Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Confirmed] [00:08] without HEAD it gives ok☺☺no☺no [00:10] jam: that does make sense though... we did init-repo is /home/tech-admin/data/bzr/ and then init in /home/tech-admin/data/bzr/HEAD [00:11] brilliantnut: right, that is what I thought you did [00:11] I'm trying to understand the other error, then [00:13] bzr log bzr+http://@/bzr/ gives "Not a branch:" [00:14] and bzr log bzr+http://@/bzr/HEAD gives "No repository present:" [00:14] brilliantnut: well I would expect the "Not a branch" since HEAD is the branch, "bzr/" is the repository [00:14] I' don't know why you are getting the other error [00:14] so, when I'm accessing the branch, it wants a repository, and vice versa :( [00:14] brilliantnut: well, it can find the repository from the branch, which is why it is confusing [00:15] can you paste the output of ~/.bzr.log if you run [00:15] bzr log -Dhpss -Dhttp bzr+http://..../bzr/HEAD [00:15] brilliantnut: and unfortunately, it is now time for me to spend with my family, but maybe spiv will peek his head in here and help [00:15] morning Odd_Bloke [00:15] jam: thanks for your help. [00:17] good morning [00:18] hi markh [00:20] hi poolie [00:20] output of .bzr.log after bzr log -Dhpss -Dhttp bzr+http://..../bzr/HEAD http://paste.ubuntu.com/12151/ [00:20] http://paste.ubuntu.com/12151/ [00:21] spiv: jam said you might be able to help with our problem... [00:25] brilliantnut: I'll take a look [00:27] I have a question regarding embedding bazaar's api's in my C code. I am getting fairly familiar with the python C api but I don't know enough about Python in general to understand what I am missing. Without all of the details I am trying to load a working tree object by... http://pastebin.com/m5abe9728 Now it says 'No module names workingtree' and that is where not knowing much about python is hurting me. I am unsure if I am supposed to d [00:27] o some special linking in my makefile to link to the bzrlib or where to look for information. === mwhudson_ is now known as mwhudson [00:30] brilliantnut: strange, it repeatedly tries to do BzrDir.find_repositoryV2 in HEAD, rather than in bzar. [00:30] brilliantnut: that looks like a bug in the client to me. Which version of bzr is that? [00:31] libwilliam: the module is called "bzrlib.workingtree" [00:31] libwilliam: or rather, the workingtree module is in the bzrlib package. [00:32] spivl, I'm on 1.6 dev (latest checkout of bzr.dev), deepjoy is on 1.5rc1, and we've also tried using 1.3 earlier with identical results. The server is 1.3 (from fedora EPEL) [00:32] spiv: ^^^^ [00:32] brilliantnut: ok, thanks [00:32] brilliantnut: looks like bug report time :( [00:32] The server appears to be working correctly, at least from that snippet. [00:33] I'll file a bug report, I'll try to deal with it soon. [00:33] It looks pretty severe to me. [00:33] spiv: thanks, im building right now to try it out. So as long as bazaar is installed using bzrlib.workingtree should work do I have to specify to link against it(im new) [00:33] libwilliam: no, you can't "link" Python modules. [00:34] You need to import python code, as you're doing. [00:35] You might want to read the python tutorial, especially the section about modules and packages: http://docs.python.org/tut/node8.html [00:35] The background information that gives you should help you make sense of the C APIs. [00:35] spiv: alright, im only used to using c and the makefile pain so not sure how anything python related words. [00:35] spiv: im looking at it now, thanks for the help [00:35] spiv: This is similar happened to us when we last tried it after 1.0 released, and apparently there was a patch underway to fix this or something... unfortunately, we only got time to get back to this now... [00:36] brilliantnut: yeah, this is definitely supposed to be working now :( [00:36] spiv: do you need further information from us to help fix this? [00:38] brilliantnut: I don't think so at this stage [00:39] deepjoy and I have access on both the server and client... we could give you test credentials to our repository, if it would help. [00:39] brilliantnut: I'll tell you the bug number in a moment, if you could subscribe to that in case we do need more information, that would be good. [00:44] brilliantnut: bug #230550 [00:44] Launchpad bug 230550 in bzr "bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2" [Undecided,New] https://launchpad.net/bugs/230550 [00:44] brilliantnut: thanks very much for reporting this [00:52] spiv: subscribed. [01:05] spiv: is this fallout from your "post to the same URL" patch? [01:05] I think the client thinks it is doing [01:05] transport.clone('..') [01:05] but then it ends up posting to the same URL [01:05] spiv: just a guess, though [01:06] certainly RemoteBzrDir has been stupid about opening a containing repo for a long time [01:06] it has the RPC's to just open it directly, but it still does a VFS walk [01:11] jam: it seems likely to be involved, yeah [01:38] spiv: one more thing, there is an inconsistency in the documentation section 10.4 (the part we were referring to). 10.4.1 (example) says /srv/example.com/www/code/, but the code snippets in section 10.4.3 have /srv/example.com/code (missing www) [01:46] also, the modpywsgi link is broken [02:08] I have a question, I can convert it into a project svn to bzr? [02:09] I have a question, I can convert it a project into svn to bzr? [02:10] hersonls: bzr-svn. [02:11] Peng: what is this? [02:12] Peng: bzr plugin? [02:12] hersonls: one-way conversion (never to go back) is do-able and pretty easy. [02:13] hersonls: Yes, it's a plugin. [02:13] hersonls: on the other hand, if you need to _continue_ to interact with the old central Subversion repository, then that is also possible. [02:13] hersonls: in both cases, the 'bzr-svn' plugin will help you do this. [02:13] hersonls: http://bazaar-vcs.org/BzrForeignBranches/Subversion [02:14] :D [02:14] hersonls: there are also other tools that can do the first [02:14] tanks [02:14] * AfC wonders if svn2bzr is still maintained. [02:15] AfC: Dunno. With bzr-svn, I don't really care. [02:15] Peng: granted, but bzr-svn can be quite difficult to get to run. If all you're after is a never-look-back one-time conversion, then other tools are worth considering. [02:16] True. [02:16] abentley: be gets a shoutout in lwn this week [02:17] bob2: Whowhat? [02:17] bob2: wow. [02:17] And I thought nobody cared. [02:19] you were just like two years ahead of the world [02:19] http://pastebin.com/m686a55f Now I am coming across a problem with trying to specify a directory of where to open a working tree from. Looking at the pastebin link I specify /home/will/bzrtest but no it tries to open the directory I am currently in /home/will/apps/svn/anjuta [02:20] Peng: www.bugseverywhere.org [02:20] Peng: be= Bugs Everywhere, a distributed bugtracker I wrote for use with Arch and Bazaar. [02:20] Oh. [02:20] Oh! [02:20] I misread "be" as "he". As in "him". [02:20] I really need to sleep. [02:20] Congratulations. :) [02:21] It has a domain name now too? Nifty. [02:22] haha, with rcs support [02:23] * Peng goes to bed. [02:31] libwilliam: hmm, strange [02:32] libwilliam: maybe an odd interaction with the fact that WorkingTree.open is a staticmethod? [02:32] I wouldn't expect that to be the case. [02:33] when I directly pass in "/home/will/bzrtest" into the method instead of converting to a py_string it correctly tries that directory but with the screwed up characters No such file: u'/home/will/bzrtest/\x01' [02:33] Oh, right. [02:33] The "s" format means a C string, not a PyObject [02:34] (see "Parsing arguments and building values" in the Python/C API Reference Manual) [02:35] alright I brought it up, thanks again [02:39] hersonls: hello [02:39] poolie: hi [02:39] poolie: Bazaar is reflected in some other vcs to be build as is currently? [02:41] i don't understand, can you restate the question? [02:41] yeah [02:41] sorry for my english [02:41] have any influence of another vcs, in the building bazaar? [02:44] poolie: you understand now? [02:45] yes [02:45] bzr takes ideas from several places: monotone, arch, baz, svn, git [02:47] poolie: bazaar have news? [02:48] ( reminding you these questions are for an article ) [02:57] oh i see [02:58] hersonls: yes, see for example http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar-first-edition.html [03:25] haha "Launchpad developer and wanted criminal" [03:25] hmm, re: http://jam-bazaar.blogspot.com/2008/05/creating-new-launchpad-project-redux.html , are you supposed to use bazaar as the super-project for all plugins? [03:50] * ig1 lunch [04:18] igc, ig1, i approved your "for 1.5" patch; if you want me to read anything else in particular please let me know [04:19] thanks poolie. The only tweak I want to do is to move Miscellaneous Topics ahead of the plugin tour. [04:20] That will mean a minor rewording of the 'port 2' intro as well [04:20] s/port/part/ === ig1 is now known as igc [04:22] poolie: I'd like your opinion on the Zen doc patch as well but it can wait if you're busy on other things [04:24] i suspect people are keen for me to finish their raise recommendations :) [04:24] * fullermd could use one while you're at it. [04:25] sure :-) === pickscrap1 is now known as pickscrape [05:01] Any ideas on this? [05:01] bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository [05:01] Got that while pulling. [05:13] TFKyle: you certainly don't have to, I do it because then you can see them all as part of the project [05:46] * igc pick up kids [06:31] spiv: yes, I've seen bug #230223, a bit short of time though, I agree with you that it may be related to error handling but I also suspect some bad interaction with connection sharing, also bug #229076 is weird, pycurl works while urllib got a connection reset so early I wonder why... [06:31] Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Confirmed] https://launchpad.net/bugs/230223 [06:31] Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Confirmed] https://launchpad.net/bugs/229076 [06:42] vila: that is odd [06:42] spiv: pfew such a relief, I'm glad you share the feeling :-) [06:43] vila: thanks for taking a look. I was asking just in case you knew the answer instantly :) [06:44] spiv: I had a look a few days ago at #230223 and -Dhttp revealed that the POST failed for unclear reasons and then a new connection is issued 90 seconds later (sounds like sone timeout) which made me suspect some bad reuse of the connection, but I didn't have time to dig further [06:45] so my first reaction is to suspect some bad handling of the socket when POST errors, but I may be wrong [06:47] and again, I really really want to be able to apply some parts of the test suite against a real server, that's my #1 TODO since it will simplify a lot of other tasks (https for urllib, list_dir for webdav, just to name a few) [06:49] regarding #229076, a telnet session under wireshark gives only a few packets, but I'm not expert in diagnosing at that level and some help here will be very appreciated [06:49] * gour is preparing to adopt bzr's terminology - {standalone,shared} branch, {shared} repository, checkout, tree etc. which, afaics, differs a bit from darcs' lingo [06:49] I just blogged about my experience using Bazaar to import and then publish a mirror of GTK. Hopefully that will be of some interest in GNOME land. [06:50] url? [06:52] otoh, i don't know why, but i simply love/like bzr. git was never serious candidate and hg did not penetrate my mind when playing with it [07:02] ahh, found GTK post... [07:11] gour: i'm glad you like it === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | [07:12] poolie: i really does === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.5rc1, May 9 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [07:13] it looks svn-1.5 (containing reqs for bzr-svn) should be soon out? [07:13] gour: seems like it, it's at -rc5 atm [07:14] poolie: now that the topic is up-to-date, do you have a few seconds to inspect a wireshark trace ? Like the one #229706 can produce ;-) [07:14] soon, we can try bzr-svn without patching [07:17] AfC: cool note at the end of your blog post ;) [07:19] hey, bzr viz is really cool! [07:19] visualize++ [07:19] :) [07:20] * TFKyle wonders if bzr isn't supposed to work with py 2.6/trunk or if it's just something with the gzip stuff on his windows machine [07:20] * gour is sold. visualize will impress his windoze friends [07:20] vila, sure, url? [07:21] vila, really #229706 "gobuntu-desktop installation does not remove non-free software"? [07:21] #229076 [07:22] grrr, damn typos ! [07:22] back in ~30 mins, daughter to school time [07:22] vila, happy to look at it [07:23] maybe just attach it to that bug? [07:27] am i right in understanding that i'm supposed to do bzr branch 'repo', then create 'working copy, hack in there, pull to 'repo' to keep it update and then bzr merge 'cause, according to docs for pull, "This command only works if your local (destination) branch is either an older copy of the parent branch with no new commits of its own, or if the most recent commit in your local branch has been merged into the parent branch." while in [07:27] e.g. darcs i can select patches while pulling and resolve potential conflicts? [07:38] gour: if you have diverged from the branch you are pulling from, you need to merge [07:41] jamesh: right. darcs' can pull no matter of adding new stuff [07:41] gour: yep. Darcs has a different model to Bazaar [07:42] gour: I guess you'd have to do something to resolve conflicts in Darcs if the two diverged branches changed the same sections of code though [07:42] true. it presents branch as set of patches...otoh, bazaar avoids with its model, some scalability problems [07:43] jamesh: sure...darcs will mark conflicts [07:44] but, afaiu, bzr does not allow to pull even if there are no conflicts, right? [07:44] gour: Bazaar is snapshot oriented rather than delta oriented [07:45] gour: provided the deltas can be applied on top of each other Darcs doesn't consider there to be a conflict [07:45] yes. it's just the other model, as in hg, but, somehow, hg did not appeal to me as much as bzr [07:46] gour: in contrast, combining the changes in Bazaar results in a new tree snapshot (and revision). [07:46] there are pros and cons to both systems [07:47] right, darcs allows fine cherrypicking, the other model is more robust & safe [07:47] a Bazaar revision represents a particular tree state, so you can do things like verify that a test suite passes before accepting a commit [07:48] in contrast, you can only make those sort of assertions in Darcs against the entire set of deltas in the branch [07:49] well, in darcs you can do that as well with --pre-hook switch while darcs record [07:49] ... on the other hand, extracting small and/or unrelated changes out of the middle of a branch and applying them to another branch is something that Bazaar's current UI doesn't help very much with. [07:49] That's fine, except that I know that a number of us feel the desire to do this sort of thing quite frequently, and so hopefully someday Bazaar will evolve some capabilities to help smooth the way in such scenarios. [07:50] pulling one branch into another won't necessarily leave you with a tree with all the tests passing, even if both branches passed before hand [07:50] (not all conflicts are textual) [07:50] AfC: cherry picking has been on the todo list for a long time :() [07:50] yeah well [07:50] that should have been :( [07:51] jamesh: if you tag then you know that all the patches before have to pass [07:52] and darcs record --pre-hook will do the right thing, check new patch(es) before commit [07:52] gour: well, a pull could insert patches into that existing sequence, right? [07:52] gour: maybe it would help you if I were to point out that most of the people working on Bazaar are world class experts in the version control field; notably, most of them used Darcs at one point or another. You don't really need to explain what it does here. [07:52] ok [08:05] is improving speed the main concern of bzr-dev atm? [08:10] * gour is reading user-guide [08:26] poolie: wireshark traces added to bug #229076 for a failing telnet session (7 packets) and a succeeding pycurl session (only the first 52 packets) [08:26] Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Confirmed] https://launchpad.net/bugs/229076 [08:27] gour: I'd say it's the main one, yes. That said, there's feature work happening too. [08:28] Our speed is already good enough in lots of cases, though. We're just trying to make sure it's good enough for even more cases :) [08:33] I was thinking about speed earlier today... [08:33] vila: that is weird [08:35] spiv: trying to tie 'vila', 'odd' and 'weird' in your comments when fullermd is around is naughty... [08:35] :-) [08:36] vila isn't odd. 2 vowels, 2 consonants; that's an even number of evens, adding and summing to the same even. Total non-odd. [08:36] Which is weird, when you think about it. [08:37] * vila hopes google doesn't index IRC logs... [08:38] seriously, is anyone able to reproduce the telnet session ? [08:41] i'm noticing some ambiguity while reading docs. any preferred pastebin i should use to write the details? [08:41] !paste [08:41] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [08:42] ta [08:45] Speedwise: * /src - Convert Time: ~6h20m, Git Repo Size: 495M (before repack 2.2G, repack time ~18hours), CVS Repo Size: 2.3G [08:45] * fullermd is guessing a bzr conversion wouldn't even get a significant way through in 24 hours... [08:45] vila, thanks [08:45] fullermd: don't most things add and sum to the same thing? [08:46] jamesh: Yes, but they don't multiply and sum, which is totally what I wrote if you disregard my fingers and go straight to my mind :P [08:48] * igc dinner [08:50] ok, here it is: http://paste.ubuntu.com/12203/ anyone can comment on it? [08:53] how do I set up a remote repository (well via mount) and then make the directory I am in be a lightweight bound checkout of that remote repo, without changing the files in this directory or creating a copy? [08:54] I can create the remote repo or branch [08:55] but what do I say in my tree of stuff to say: create me a .bzr dir here that contains info for a bound lightweight checkout of that remote branch over there? [09:02] i've another 'doc-bug' report, but let's hear the feedback on the first one 1st [09:07] ok, here is the other one if someone bothers to look at http://paste.ubuntu.com/12204/ [09:22] uniscript: "bzr reconfigure" is probably what you're after [09:22] for the last bit [09:22] so bzr init, bzr bind, bzr reconfigure? [09:23] (in outline) [09:23] oh --bind-to [09:24] thanks [09:28] I would have thought the bzr documentation would be in a bzr branch somewhere, but I can't find it off the cuff. [09:34] Most of it's in with bzr... [09:41] Ah, of course. [10:05] lo AfC [10:06] Someone about to join who is attempting to get the GTK branch I blogged about today at http://research.operationaldynamics.com/blogs/andrew/#bzr-branch-of-gtk [10:06] but is getting... ah, there he is :) [10:06] john@cocacola:~/gnome/gtk+$ bzr branch http://www.gnome.org/~afcowie/bzr/gtk+/trunk [10:06] bzr: ERROR: Connection error: while sending GET /%7Eafcowie/bzr/gtk%2B/trunk/.bzr/branch-format: (104, 'Connection reset by peer') [10:06] I already asked what version he was using [10:06] Ahem, please excuse me. [10:06] :) [10:06] I assume John to be a him, sorry [10:07] you are correct ;) [10:07] ... and he indicated trouble with bzr both 1.3.1 and 1.5rc1 [10:07] Let me try branching raw [10:08] Isn't that the thing vila was just looking at? [10:08] whoops, its 1.3-1 (debian package version) not 1.3.1 [10:10] yup, something is weird here, *server* log may help, from here it looks like the server just close the connection, so I'm a bit short of info to understand [10:10] especially when using pycurl (instead of the urllib based http client imlpementation) just works... [10:10] vila: hi, you were looking at gnome.org in that bug report weren't you? [10:10] I don't have access to the HTTP server logs, sorry [10:11] james_w: hi, see bug #229076 for details [10:11] Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Confirmed] https://launchpad.net/bugs/229076 [10:11] (it's just a public_html directory in a user account on the server that GNOME hackers can use. [10:11] Not a server I control) [10:11] Jc2k: installing python-pycurl will probably get you moving. [10:11] AfC: and do you know someone who can look at those logs ? [10:12] james_w: will try now [10:12] There's certainly something weird with the server. [10:12] AfC: and can you tell me me how you upload that branch ? Do you use pycurl ? [10:12] % ( echo 'GET / HTTP/1.0' ; echo 'host: www.gnome.org' ; echo ) | nc www.gnome.org 80 [10:12] vila: Yes, but that's a pretty bloody busy server, and the GNOME sys admin team is in over their heads today (as are most sysadmins on the planet) [10:12] just dumps me right back at the prompt (i.e., closed connection with no data passed back) [10:13] vila: I uploaded with bzr+ssh [10:13] fullermd: thanks for confirming that [10:13] Presumably it's doing one of those weird "detect if the far end is a 'real' browser by random connection fingerprint stuff, else ignore" things that's all the rage. [10:13] AfC: Huh ? There is a smart server there ??? [10:14] the POST command got a 404 when bzr probes for it... [10:14] * AfC has a normal `bzr branch http://` running on his URL right now, and it's 2/5 inventory texts and 17 MB in [10:14] vila: what are you talking about? [10:15] fullermd: how can it do that ? You can try again without the 'host' header and get the same behavior [10:15] * Jc2k installed python-pycurl and its working \o/ [10:15] Jc2k: ahpy for you :) [10:15] vila: I would (on a normal day) have SSH access to that machine. So once I got Olav to install Bazaar on it, I just pushed a branch up there with bzr push bzr+ssh://... [10:15] vila: it's got a smart server accessible over ssh, but it's not set up for bzr+http:// [10:15] should the package depend on python-pycurl? [10:15] vila: I don't recall offhand. But it apparently can be done with some degree of accuracy, by details of the timing and packet structure and whatnot. At least, as long as you only care about Mozilla/IE/Opera/etc. [10:16] james_w: ghaaa, of course [10:16] AfC: james_w is obviously right :) [10:16] Jc2k: it would seem so. It's an optional "does something different at runtime if found" dependency. [10:17] Jc2k: we would like to move away from pycurl, however there are two things to fix, one is the couple of bugs that have been found in the last week or so, and the other is doing something with SSL certificates. [10:17] fullermd: my my my, are we getting bitten because we are too slow between connectin and sending the GET ? I can hardly believe it >-/ [10:17] Jc2k: though there could be a dependency in the meantime. [10:18] fullermd: I thought about something like that but discarded it as too 4th-dimension-y [10:18] and why on earth would they want to do that ??? [10:18] The theory is to avoid robots/scrapers/etc. [10:19] I don't know much about it; just seen some references in passing. [10:19] anyway, if that's the case, we need to at least check with them and try to find a solution [10:19] Can't coax anything out of google in a little trying. [10:19] does anybody knows one of those gnome sysdamins ? [10:20] AfC: I should have missed something but why all admins of the planet are so busy today ? [10:20] vila: AfC does, but as he said they will be very busy today [10:20] vila: http://www.ubuntu.com/usn/usn-612-1 [10:21] http://lists.debian.org/debian-security-announce/2008/msg00152.html [10:21] james_w: oh, that one, I think I applied the update a couple of days ago already [10:23] vila: http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html and http://mail.gnome.org/archives/devel-announce-list/2008-May/msg00002.html [10:23] Erich's blog post was excellent reading. [10:27] AfC: thanks, read both, I should check *when* I created my ssh keys, the good news is that I kept *all* of them under bzr ;-) [10:28] james_w: that includes keys uploaded to lp I presume, time to update them ? [10:28] Hi ! gtk masters, 'Graph' object has no attribute 'iter_ancestry' is gtk related ? [10:29] vila: they all got killed anyway [10:30] its bzr 1.4.0 and olive -r 486 (tagged as 0.94.0) ? [10:31] that sounds a lot more like a bzr thing than a gtk thing [10:31] bob2: the keys uploaded on lp ? [10:36] vila: yes, though my DSA key was still there yesterday, so it might have been a selective deletion. [10:37] matkor: yeah, I think that's a bzr thing. [10:40] james_w, bob: Where are docs around graph: Graph(KnitParentsProvider(KnitVersionedFile(file:///home/users/matkor/.bzr/repository/revisions))) ? [10:41] I'm not sure [10:41] when not using lockstep dev, checkouts are not required? [10:41] http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.graph.Graph.html [10:42] does bzr do clever things with its output? (where "clever" is some magic I can't clearly define) [10:42] gour: yes, if you're not doing lockstep then checkouts are not what you want [10:42] on hardy, doing "bzr diff | pastebinit" doesn't work [10:42] but something like "echo foo | pastebinit" does [10:42] james_w: Thank you very much [10:42] gour: though you can use commit --local, but I'd recommend using a branch [10:42] hi Ng [10:43] hey :) [10:43] "doesn't work"? [10:43] pastebinit gives an error which its author tells me means it didn't receive any input [10:43] wow, yeah [10:43] james_w: thanks [10:45] Ng: bzr diff exits with 0 when piped to pastebinit, so it's not looking for the changes correctly, and I guess outputting nothing to match the "no changes" status [10:45] 'sup [10:45] hi lifeless [10:45] hello lifeless [10:45] just leaving now [10:45] night all [10:45] hi poolie [10:45] good night [10:45] enjoy Prague [10:46] thanks. [10:46] I hear it's Pragmatic :) [10:46] badabing [10:46] boo [10:47] are there any 'Cons' in using shared repos? [10:47] hi, i'm suffering from some kind of strange corruption pushing a branch [10:47] when i look at the pushed branch, only the last few revision seem to be there [10:47] james_w: I get this whether there are changes or not, but even 'echo "" | pastebinit' works. I guess I'm wondering if bzr should notice that stdout isn't a terminal and just send text, but I'm guessing wildly ;) [10:48] and one i try to branch from it, i get the error NotLefthandHistory: Supplied history does not follow left-hand parents [10:48] Ng: yeah, but "bzr diff | cat" works [10:48] it reminds me of dunedin [10:49] Ng: utf8 is text :P [10:49] james_w: sure, and | less. so is the conclusion here that pastebinit is broken somehow? [10:49] that would be my first guess [10:50] intellectronica: that is strange. You should only get the branch error message on push. [10:50] intellectronica: is this a public branch? [10:50] although at some point, bzr merge --preview failed to work with |less, so I'm not entirely convinced you guys aren't to blame somehow ;) [10:50] james_w: it isn't, srry [10:50] ess [10:50] Ng: could be, I don't know if it does anything funny with stdin. [10:50] intellectronica: there was a bug [10:51] intellectronica: use an older, or newer bzr and it should go away [10:51] lifeless: older than 1.5rc1, you mean? [10:51] there is no newer packaged version, afaik [10:53] Ng: pastebinit is at least a little broken [10:53] Ng: "list index out of range" [10:54] yeah, a quick read of the code for stdin suggests it calls .read() on stdin twice [10:54] content=l_r[0][0].read() [10:54] quite why that works with some stuff and not with others, I don't know, but is seems like a highly suspect thing to do, to me [10:55] hmm, maybe not [10:55] * Ng shrugs, I'm not going to start debugging this right now ;) [10:55] "When the time-out is reached without a file descriptor becoming ready, three empty lists are returned. " [10:56] so something bzr is doing means that pastebinit's stdin is not ready [10:56] (sleep 2; echo a) | pastebinit [10:57] lifeless: no, downgrading to 1.3.1 doesn't seem to help [10:57] interewsting [10:58] it may be something else I guess [10:58] I'm a little shell shocked - just ogt off th eplane [10:58] i have 6277 revisions locally, but when i push i get only the last 167 branches [10:58] lifeless: ah, are you doing the prague thing? [10:59] james_w: ooh, good catch [10:59] yes [10:59] cool [10:59] Anyone know a better way to know if stdin is going to have data for you than "select.select([sys.stdin],[],[],0)" ? [11:00] if you're non blocking, no - other than to say 'use twistd ffs' [11:02] james_w: the FIONREAD ioctl? [11:02] I guess what it should do is first look for filename arguments, rather than looking for stdin [11:02] that would allow you to run "pastebinit" and type what you want. It does have the same problem as "patch patch_filename" though. [11:09] Ng: bug 230649 if you care enough to subscribe. [11:09] Launchpad bug 230649 in pastebinit "Fails to read from stdin if the process producing data is slow to start" [Undecided,New] https://launchpad.net/bugs/230649 [11:12] I'm not sure why it wants to be nonblocking anyway [11:14] james_w: cool thanks :) [12:01] Who is now responsible for merging bugfixes for olive-gtk ? Jelmer Vernooij ? Szilveszter Farkas ? I have one pretty straightforward typo fix in https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ... [12:01]