| awmcclain | Done. | 00:07 |
|---|---|---|
| jelmer | awmcclain: thanks :-) | 00:12 |
| ubotu | New bug: #216542 in bzr "unable to do merge on windows" [Undecided,New] https://launchpad.net/bugs/216542 | 00:15 |
| ubotu | New bug: #216541 in bzr "bzr mv dies when using a checkout over http://" [Undecided,New] https://launchpad.net/bugs/216541 | 00:16 |
| Linnk | Hey guys, I'm using Bazaar on Ubuntu 7.10. I'm trying to use the gui (Olive) to view a diff of a file, but the diff window simply shows up blank | 00:29 |
| jelmer | Linnk: how are you using it exactly? | 00:29 |
| Linnk | I click the file I want to see a diff for and click the Diff button in the toolbar | 00:30 |
| Linnk | I figured that I would then be asked which versions to diff, but apparently not | 00:31 |
| jelmer | Linnk: I think that just checks what changes there are in the working tree | 00:36 |
| jelmer | so on a fresh checkout it's correct the window is empty | 00:36 |
| Linnk | ah yeah, that explains why it suddenly works now that I've changed some files | 00:37 |
| Linnk | so I'll have to use the terminal for diff's between revisions? | 00:38 |
| jelmer | Linnk: You can use "bzr viz" to find a revision to show the diff for | 00:47 |
| Linnk | jelmer: Ok, thanks a lot :) | 00:48 |
| antoranz | Guys! How do I change the "remembered location" of a branch so I don't have to specify it on every "bzr merge" call? | 01:28 |
| jelmer | awmcclain: use --remember | 01:30 |
| jelmer | s/awmcclain/antoranz/ | 01:30 |
| jelmer | antoranz: or edit .bzr/branch/branch.conf | 01:31 |
| antoranz | what does bzr bind do? | 01:31 |
| antoranz | jelmer: what you said worked. Thanks | 01:32 |
| bob2 | binds a local branch to a remote one | 01:33 |
| bob2 | making it a checkout (ie commits go to both immediately) | 01:33 |
| antoranz | ok | 01:36 |
| ubotu | New bug: #216586 in bzr "annotate removed-revision feature" [Undecided,New] https://launchpad.net/bugs/216586 | 02:06 |
| awmcclain | I'm really at a loss here... I cannot get the bzr-email plugin to work for the life of me. No log entries, nothing. I'm flummoxed. | 02:10 |
| jelmer | awmcclain: What did you do to set it up? | 02:19 |
| awmcclain | jelmer: I've installed the plugin into my site packages. I've verified that it shows up until the bzr commands | 02:27 |
| awmcclain | ... | 02:27 |
| awmcclain | and | 02:27 |
| awmcclain | I've set the post_commit_to config variable in the branch.conf, and in ~/.bazaar/.bazaar.conf | 02:28 |
| jelmer | awmcclain: it shows up in "bzr plugins" you mean? | 02:30 |
| awmcclain | correct | 02:30 |
| awmcclain | i can also do bzr help email | 02:31 |
| jelmer | what os are you on? | 02:31 |
| awmcclain | ubuntu gutsy | 02:31 |
| awmcclain | it iddn't work in 1.2, and still doesn't work on 1.4r1 | 02:31 |
| awmcclain | what should my config file look like, do you know? | 02:32 |
| awmcclain | i have | 02:32 |
| awmcclain | [DEFAULT] | 02:32 |
| awmcclain | post_commit_to = admin@fluther.com | 02:32 |
| jelmer | yeah, that should be sufficient I think | 02:34 |
| jelmer | running bzr commit doesn't trigger it? | 02:34 |
| ubotu | New bug: #181534 in bzr-svn "Discards credentials specified in URL" [Medium,Fix committed] https://launchpad.net/bugs/181534 | 02:46 |
| schmichael | if i have bzr 1.3 installed what repo format should i use? | 03:54 |
| schmichael | it seems to default to pack | 03:54 |
| bob2 | the default, unless you have some special requirement (e.g. working with branches from svn) | 03:54 |
| schmichael | bob2: thanks! | 03:54 |
| ubotu | New bug: #216614 in bzr "should not immediately abort of .bzr/format can't be opened" [Undecided,New] https://launchpad.net/bugs/216614 | 03:55 |
| AfC | there is an annotation cache, right? | 03:59 |
| AfC | does it get corrupted? if so, how do you force it to be regenerated? | 03:59 |
| spiv | AfC: not (yet) for pack formats. | 04:00 |
| === BasicMac is now known as BasicOSX | ||
| matid | jelmer: Hi there. Any news on the issue with svn+https and bzr? | 05:51 |
| awmcclain | jelmer: No, running bzr commit doesn't trigger it. At all. | 06:30 |
| awmcclain | Are there any hidden log files I should check? | 06:30 |
| spiv | awmcclain: ~/.bzr.log, maybe try "bzr -Dhooks commit ..." too. | 06:32 |
| awmcclain | hrm | 06:35 |
| awmcclain | the -D switch is complaining | 06:35 |
| awmcclain | oh oh,never mind | 06:36 |
| awmcclain | A ha! Ok. It seems like the email only works if I commit ON the machine, not through SSH | 06:38 |
| awmcclain | Why would it not work over bzr+ssh://? Is there a different way to configure the post_commit_to? | 06:43 |
| === mwhudson_ is now known as mwhudson | ||
| pygi | morning | 10:24 |
| wildfire | is their a bzr equivalent of 'git add -i' (it allows you to select particular hunks of a file to add) | 12:45 |
| oleavr | wildfire: check out the interactive plugin at http://bazaar-vcs.org/BzrPlugins | 12:47 |
| asabil | wildfire: git add is different from bzr add | 12:47 |
| asabil | the interactive plugin adds a -i to commit | 12:47 |
| asabil | thanks for the advertisement oleavr :D | 12:48 |
| oleavr | asabil: "uncle software, coming to a store near you" ;D | 12:49 |
| asabil | lol | 12:49 |
| bob2 | shelve kinda does the opposite | 12:51 |
| * asabil needs to implement bzr revert -i when he gets free time and motivation | 12:53 | |
| wildfire | oleavr, and I just copy the *.py into ~/.bazaar/plugins/ and it'll work? | 12:54 |
| oleavr | wildfire: copy the directory in there, yes | 12:55 |
| asabil | wildfire: cd ~/.bazaar/plugins | 12:55 |
| asabil | bzr branch lp:bzr-interactive interactive | 12:56 |
| asabil | wildfire: you will need to have a subfolder inside plugins | 12:56 |
| wildfire | asabil, thanks - that branch command seemed to do the trick | 12:58 |
| asabil | great | 13:00 |
| asabil | let me know if there is any problem with it | 13:02 |
| wildfire | asabil, *** Bazaar has encountered an internal error. | 13:11 |
| wildfire | wildfire@muspell:/etc/bind$ sudo bzr record-patch | 13:12 |
| wildfire | bzr: ERROR: bzrlib.patches.MalformedHunkHeader: Malformed hunk header. Does not match format. | 13:12 |
| wildfire | 'Binary files postfix/virtual.db\t2008-04-04 01:58:00 +0000 and postfix/virtual.db\t2008-04-10 09:06:09 +0000 differ\n' | 13:12 |
| asabil | can you paste the traceback somewhere please | 13:12 |
| wildfire | asabil, http://pastebin.com/m15c6399a | 13:14 |
| wildfire | hmm, when recording the changes I have to give it a patch-name | 13:14 |
| asabil | never tried with bzr 1.0.0 actually | 13:15 |
| asabil | and record-patch is a different thing than commit -i | 13:15 |
| asabil | both bzr commit -i and record-patch are working here | 13:16 |
| asabil | using bzr 1.3.1 | 13:16 |
| asabil | they also worked with 1.1 and 1.2 iirc | 13:17 |
| matthewlmcclure | does bazaar support perforce foreign branches? | 13:17 |
| bob2 | as in actual perforce branches, or something like them? | 13:17 |
| asabil | matthewlmcclure: you can try bzr-fastimport, but never tested it myself | 13:18 |
| === mario_ is now known as pygi | ||
| matthewlmcclure | an actual perforce branch | 13:18 |
| asabil | wildfire: ?? can you upgrade bzr ? | 13:18 |
| matthewlmcclure | asabil: i saw that, but i'm unclear how to provide input to bzr-fastimport | 13:19 |
| asabil | matthewlmcclure: http://bazaar-vcs.org/BzrFastImport/FrontEnds | 13:20 |
| matthewlmcclure | one of the wiki pages recommends git-p4, but it looks like that tool is hardcoded to git | 13:20 |
| dato | if git-p4 outputs in git-fast-import format, bzr-fastimport should do (or attempt to) do something useful with it | 13:21 |
| asabil | right | 13:21 |
| dato | but I think that'll be for importing only, not to work with them as foreign branches (like bzr-svn does with subversion's) | 13:21 |
| asabil | dato: seems like git-p4 runs git commands | 13:21 |
| dato | aha | 13:21 |
| asabil | proc = subprocess.Popen(["git", "rev-parse", branch], ... | 13:21 |
| asabil | matthewlmcclure: git-p4 can be a good starting point for hacking a bzr-p4 | 13:22 |
| matthewlmcclure | asabil: that's what i thought; thanks for confirming | 13:22 |
| asabil | matthewlmcclure: but as dato said, fastimport is only about importing | 13:23 |
| asabil | I don't know if that's enough for you | 13:23 |
| matthewlmcclure | right, i'd really prefer two-way foreign branch support | 13:23 |
| asabil | someone needs to step up and implement it then | 13:23 |
| matthewlmcclure | i'm looking for an interesting project to hack on, so i may give it a shot | 13:24 |
| asabil | great :) | 13:24 |
| wildfire | asabil, I'm not sure what version of ubuntu this machine is running | 13:24 |
| wildfire | asabil, and this is a server | 13:25 |
| asabil | :/ | 13:25 |
| wildfire | asabil, so an upgrade needs to be co-ordinated amongst a larger set of people than just me | 13:25 |
| asabil | I understand | 13:25 |
| asabil | but isn't it for your own usage ? | 13:26 |
| asabil | I mean, why would you need to install bzr on the server ? | 13:26 |
| asabil | wildfire: you don't really need bzr on the server | 13:28 |
| wildfire | we do if we manage /etc with it | 13:29 |
| asabil | wait wait | 13:30 |
| asabil | you seem to have called record patch on a binary file | 13:30 |
| asabil | that's a bug in bzr-interactive I guess | 13:31 |
| asabil | let me try to fix | 13:31 |
| matid | Hi there. | 13:37 |
| matid | A quick question - what does bzr up do on an unbound branch? | 13:37 |
| asabil | updates the working tree | 13:40 |
| asabil | this is useful when you push to a server | 13:41 |
| asabil | you can run update on the server to update the working tree | 13:41 |
| matid | So it's only useful if someone pushes code to my branch, right? | 13:41 |
| asabil | yep | 13:42 |
| asabil | for unbound branches of course | 13:42 |
| matid | Yeah, I know. | 13:42 |
| matid | And would bzr pull on an unbound branch be any different from bzr up on a checkout or a bound branch? | 13:43 |
| matid | (svn convert here, still failing to grasp all the differences ;)) | 13:43 |
| asabil | it may be different if you pull from a different url | 13:46 |
| asabil | and a pull may not work if the branches have diverged | 13:46 |
| asabil | (in which case you need to merge) | 13:47 |
| matid | You may need to merge with bzr up too, right? | 13:47 |
| asabil | didn't use bzr up extensively, but I think it will merge automatically | 13:48 |
| asabil | it would work as in svn | 13:48 |
| asabil | if you see what I mean | 13:48 |
| matid | OK, thanks. | 13:48 |
| matid | I kinda get it now ;) | 13:48 |
| asabil | whereas bzr pull fails even when there are no conflicts | 13:48 |
| asabil | it fails simply because the code has diverged and requires a merge | 13:49 |
| matid | Ahh... So up would be like pull + merge in case pull fails. | 13:49 |
| asabil | something like that | 13:49 |
| asabil | *I think* | 13:49 |
| matid | asabil: Thanks a lot. | 13:50 |
| asabil | you're welcome | 13:50 |
| dwt | Guys, can somebody help me with this? I'm trying to update a repository to a specific tag, but I don't get how to do this. What seems obvious to me (bzr up -r tagname) doesn't seem to be the way to do this | 15:21 |
| dwt | And I'm lost finding this in the docs - though it has to be something easy. :/ | 15:23 |
| asabil | dwt: can you give more details ? | 15:27 |
| asabil | is it a checkout or a branch ? | 15:28 |
| dwt | I'm a bit new, I think its a branch, i.e. it has full history | 15:28 |
| dwt | If thats what you meant. | 15:28 |
| asabil | and what do you mean to update to a specific tag ? | 15:28 |
| asabil | yes that's what I meant :) | 15:28 |
| dwt | :-) | 15:29 |
| asabil | so you branched from somewhere | 15:29 |
| dwt | Jes. | 15:29 |
| asabil | and you want to rollback to a specific tag ? | 15:29 |
| dwt | Well, I am playing around with bzr-svn and have a checkout of the 0.4 branch | 15:29 |
| dwt | yes! | 15:29 |
| asabil | bzr help revert | 15:30 |
| asabil | :) | 15:30 |
| dwt | ahhhh | 15:30 |
| asabil | or you can crate a new branch from that one | 15:30 |
| asabil | (that's generally better) | 15:30 |
| dwt | So the best way would be to move this directory aside | 15:30 |
| asabil | bzr branch -r tag:mytag . ../branch-mytag | 15:30 |
| dwt | branch from it, and only get revision up to the tag from the revision | 15:31 |
| asabil | yep | 15:31 |
| dwt | Why exactly is that better? I mean, I don't want to start developing on this checkout just yet | 15:31 |
| dwt | (and probably never) | 15:31 |
| asabil | so that you don't need to checkout again too many revisions | 15:32 |
| asabil | if you want to go ahead | 15:32 |
| asabil | if you see what I mean | 15:32 |
| dwt | So revert really removes the revisions from the repository? | 15:32 |
| dwt | uh, thats nastsy. | 15:32 |
| asabil | from your local branch | 15:32 |
| dwt | Is there not a simpler way to just go back in the history to a specific time? | 15:32 |
| dwt | While still retaining all the revisions in the repository? | 15:33 |
| asabil | actually I am not sure if revisions are removed from the branch | 15:35 |
| * dwt is currently reading the revert docs | 15:35 | |
| dwt | I'l look this up a bit and come back to tell what I found. | 15:36 |
| asabil | oki | 15:36 |
| dwt | Thansk anyway for the help so far. :) | 15:36 |
| dwt | asabil: Well, the documentation in in bzr help revert is not completely clear on this, but <http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#undoing-mistakes> says that it only throws away local commits. | 16:30 |
| dwt | I'm not sure what I should make of this | 16:31 |
| dwt | anyway for my usecase revert seems like the right thing for me | 16:31 |
| asabil | k | 16:31 |
| radix | revert only modifies your working tree | 16:35 |
| radix | so it won't delete revisions | 16:35 |
| dwt | so also local commits are not deleted? | 16:35 |
| dwt | thanks for the clarification radix! | 16:36 |
| radix | sure thing | 16:36 |
| dwt | ok, thanks and cu! | 17:37 |
| rocky | anyone know if there is an equivalent to tag_svn_revision for bzr in setup.cfg (ala python setuptools) ? | 18:25 |
| cr3 | if I have a remote machine from which I need code updated from a bzr repository, but the machine only has incoming traffic and no outgoing traffic, can I update the remote machine from my local machine using push or somesuch? | 19:22 |
| cr3 | when I actually did try push, I get the error that the remote machine does not have a .bzr directory, which kinda makes sense because it's not a repository | 19:22 |
| cr3 | I wonder if I need the bzr-push-and-update plugin, but I think there's a way to make this work somehow | 19:25 |
| matid | jelmer: Hi there! | 20:27 |
| matid | jelmer: I've got a question regarding bzr-svn, got a minute? | 20:27 |
| jelmer | matid: sure | 20:28 |
| jelmer | matid: I posted a patch to the subversion development list that fixes the https issue, btw | 20:28 |
| matid | jelmer: Oh, cool. | 20:29 |
| matid | jelmer: Thanks a lot. | 20:29 |
| matid | jelmer: The question is - what is a preferred way of dealing with diverged branches in svn? | 20:29 |
| jelmer | matid: There is no preferred way; it's up to you, what do you like best? | 20:30 |
| jelmer | matid: You can merge and push, but that may potentially change your existing revision history in svn | 20:30 |
| jelmer | matid: Some people prefer rebasing before pushing | 20:30 |
| matid | jelmer: Let's say, I branch some code, work with it, but in the meantime someone updates svn. I did bzr pull but I asked me to merge. And so did I, but after a push a strange commit appeared in svn. | 20:30 |
| matid | jelmer: It was a duplicate of the commit that was done in between my branch and the push. | 20:31 |
| matid | jelmer: And to be honest with you I don't even know how subversion will cope with it. If it's diff based then it should simply ignore it. | 20:32 |
| matid | jelmer: So I was supposed to rebase, right? | 20:32 |
| matid | jelmer: Oh, in fact it reverted the changes, it's not the same. | 20:34 |
| matid | jelmer: Eh, it's the same after all. I don't get it... | 20:40 |
| jelmer | matid: "bzr push" will push the current mainline in your bzr branch | 20:54 |
| matid | jelmer: Let's say with got a situation like this: | 20:55 |
| ubotu | New bug: #216924 in bzr "Push failed using (bzr push lp:). On windows machine" [Undecided,New] https://launchpad.net/bugs/216924 | 20:55 |
| jelmer | matid: That may involve changing the current mainline in Subversion | 20:55 |
| matid | jelmer: I branch the svn code at revision 154. Now another person submits revision 155 and 156 to svn, whereas I make one commit in my bzr branch. | 20:56 |
| matid | jelmer: Now what I did was a bzr merge followed by bzr commit and bzr push. | 20:57 |
| matid | jelmer: Which resulted in a new svn revision containing duplicated 155, 156 and my bzr changes. | 20:57 |
| matid | jelmer: Is this expected behaviour? | 20:57 |
| jelmer | matid: Yes, because that's what's in your local bzr mainline | 20:59 |
| jelmer | matid: If you want to push something on top of what's in svn, use rebase | 20:59 |
| matid | jelmer: Is there a change what I just did (bzr merge and push) broke something? | 21:00 |
| matid | jelmer: Or is it just an innocent duplication? | 21:01 |
| jelmer | matid: It still contains the same data as is in your local bzr branch | 21:01 |
| matid | jelmer: But well, if I did a merge before I pushed it should also contain all the changes that were made in svn in the meantime, right? | 21:02 |
| jelmer | matid: yes | 21:02 |
| matid | jelmer: Which means that bzr pushed a some diffs which applied to svn trunk simply didn't do a thing, am I right? | 21:02 |
| matid | jelmer: I'm not really used to this kind of behaviour :) | 21:03 |
| jelmer | you'll notice the same revisions are in the svn branch as are output by "bzr log --line" | 21:03 |
| jelmer | matid: Not sure I understand what you mean by "Which means that bzr pushed a some diffs which applied to svn trunk simply didn't do a thing, am I right?" | 21:04 |
| matid | Hmm... | 21:05 |
| matid | jelmer: It seems like bzr log --line shows some differences between svn and bzr. | 21:05 |
| jelmer | can you be more specific? | 21:05 |
| matid | jelmer: I mean, there's one extra commit in svn between the moment I branched the code and the moment I pushed it. | 21:06 |
| matid | jelmer: This is a commit that I merged in bzr by using `bzr merge` | 21:06 |
| jelmer | matid: and it's still there if you use "svn log" on the full branch url? | 21:06 |
| matid | jelmer: Eee... It disappeared... How come? | 21:07 |
| jelmer | matid: it's not part of the mainline | 21:07 |
| matid | jelmer: You can't delete changesets in plain svn, or can you? | 21:08 |
| jelmer | matid: it's part of the right hand side history. You'll see if you run "bzr log" on the remote svn branch it'll show up indented | 21:08 |
| jelmer | matid: Nope, it's still part of the repository, just not part of the mainline history of that branch | 21:08 |
| matid | jelmer: Guess I've never stumbled upon this kind of thing in svn... | 21:10 |
| matid | jelmer: Which means that both solutions (rebase and merge&push) are going to result in the same code state in svn. | 21:11 |
| matid | jelmer: Yet push will rearrange the revision history. | 21:11 |
| jelmer | matid: After rebase, you still have to push | 21:12 |
| matid | jelmer: Yeah, it's not going to change anything in svn though. Just append new changesets, right? | 21:12 |
| jelmer | matid: yep | 21:12 |
| matid | jelmer: I guess I'll use rebase then. | 21:12 |
| matid | jelmer: I mean for me it makes no difference, but other people are not going to frown upon some strange things going on in svn :) | 21:13 |
| jelmer | matid: :-) | 21:15 |
| matid | jelmer: It's kinda strange since it looks like I committed changes someone else made earlier. | 21:15 |
| jelmer | matid: It matches the behaviour of merge, commit and push for native bzr branches | 21:16 |
| jelmer | and that's what bzr-svn tries to do | 21:16 |
| matid | jelmer: To me it looks like I'm trying to make others' changesets look like mine :D | 21:17 |
| jelmer | matid: the same thing will happen if you use svn merge with a subversion branch | 21:18 |
| matid | jelmer: Hm... It's just that in svn I used to do it the other way round. | 21:18 |
| matid | jelmer: Work on a branch, then merge changes into trunk and commit there. | 21:19 |
| matid | jelmer: I think this would also be possible if I simply kept one clean checkout of svn trunk and merge other bzr branches into it, right? | 21:19 |
| lifeless | abentley: ping | 21:23 |
| lifeless | morning y'all | 21:23 |
| abentley | lifeless: pong | 21:23 |
| lifeless | I'm trying to get BB up and running again on squid-cache.org | 21:24 |
| lifeless | I'm a little confused by your response to the bug I filed | 21:24 |
| jelmer | matid: yes - but if you do that, each merged bzr branch will only show up as a single commit in svn | 21:24 |
| jelmer | matid: (since a bzr merge puts only one revision on mainline) | 21:24 |
| abentley | I understood you were running TG 1.02 and SQLAlchemy 0.4.4. Is that right? | 21:24 |
| lifeless | did you mean that if I downgrade sqlalchemy somehow, it will fix the error, or that 1.0.4.3 is a hard dependency now | 21:25 |
| matid | jelmer: That's what I'd do in svn, but it seems like using rebase is a better solution. | 21:25 |
| jelmer | matid: yeah, rebase makes snese in this case | 21:25 |
| lifeless | abentley: yes, thats what freebsd ships | 21:26 |
| matid | jelmer: Cool. Is there any case in which bzr-like merge and push will prove superior to rebase? | 21:26 |
| abentley | lifeless: for revno 249 and later, 1.0.4.x is a hard dependency. | 21:27 |
| jelmer | matid: It will probably give better results combining two branches | 21:27 |
| jelmer | matid: Rebase simply does diff + patch for each of the revisions you have that aren't in upstream | 21:27 |
| lifeless | abentley: you wouldn't happen to know if loggerhead is compatible with 1.0.4.x ? | 21:27 |
| abentley | At least, in my experience, TG 1.0.2 did not work properly with SQLAlchemy 0.4 | 21:28 |
| matid | jelmer: OK. Which means that in case of not-so-complicated merges it should work the same. | 21:28 |
| abentley | lifeless: Sorry, I don't know that. | 21:28 |
| lifeless | thats ok, wishful thinking :P | 21:29 |
| lifeless | I find myself thinking unpleasant thoughts towards the turbogears maintainers | 21:29 |
| lifeless | the dependency tree seems unpleasant | 21:30 |
| abentley | I'm quite disheartened about the whole thing. | 21:30 |
| abentley | Especially that SQLAlchemy managed to ship two releases which had blatent bugs that my measly test suite caught. | 21:30 |
| lifeless | tests FTW | 21:30 |
| lifeless | mwhudson: ping | 21:31 |
| mwhudson | lifeless: hi | 21:31 |
| abentley | This was stupid stuff where they failed to import a symbol they used. | 21:31 |
| lifeless | !!! | 21:32 |
| lifeless | thats apalling | 21:32 |
| abentley | you've got that right. | 21:32 |
| lifeless | I do want to talk about the tension that bubbled out on thursday; however sunday morning I woke up with a head cold | 21:36 |
| jelmer | matid: yeah | 21:36 |
| lifeless | I'd rather be at my best when debugging important things | 21:37 |
| lifeless | abentley: welcome back | 21:43 |
| abentley | thanks. Last thing I saw was "I'd rather be at my best when debugging important things" | 21:43 |
| lifeless | abentley: that was the last thing I wrote | 21:43 |
| abentley | Cool. | 21:44 |
| lifeless | aarrgghh | 21:59 |
| lifeless | abentley: you'll love this. I'm trying to update the turbogears package for freebsd | 22:00 |
| lifeless | 1.0.4.3 wants turbojson 1.1.2 | 22:00 |
| lifeless | there is no egg for 1.1.2 | 22:00 |
| abentley | That's nutsy | 22:01 |
| lifeless | http://files.turbogears.org/eggs/ is where the package is looking | 22:01 |
| abentley | 1.1.2 is available on PyPI, though. It doesn't fall pack to that? | 22:02 |
| abentley | s/pack/back | 22:02 |
| lifeless | no | 22:02 |
| abentley | Strange. I thought it did. | 22:03 |
| lifeless | easyinstall may | 22:03 |
| abentley | Oh. | 22:04 |
| abentley | Yes, that's what I was talking about. | 22:04 |
| lifeless | I'm really not sure what to do at this point | 22:05 |
| threeve | I'm trying to get bzr-svn going on Windows using Python 2.5(.2). I have svn 1.4.6 installed, an have installed bzr 1.3 and bzr-svn 0.4.9 using the binary installers, and installed the updated svn 1.4.6 python bindings. `bzr version` now crashes for me. Have I missed something I need to install? | 22:06 |
| wildfire | lifeless, i think going back to linux is the answer ;-) | 22:08 |
| lifeless | wildfire: this machine has never been linux :( | 22:09 |
| lifeless | squid-cache.org | 22:09 |
| jelmer | threeve: How did you install svn 1.4.6 ? | 22:09 |
| threeve | jelmer: windows binary installer from Tigris, iirc. | 22:09 |
| cr3 | interesting coincidence, I'm installing squid as we speak | 22:10 |
| wildfire | lifeless, ahh, right. well that's nothing a chroot couldn't solve if you get really stumped | 22:10 |
| lifeless | wildfire: but even if I did that, this points out a generic problem for folk that are not on development editions of linux | 22:10 |
| jelmer | threeve: You can't use a stock subversion 1.4. You need either the one with the patches linked from the bzr-svn wiki page or Subversion 1.5. | 22:10 |
| wildfire | lifeless, i don't think developers will ever be 'generic folk' personally. Most people never miss the 'new' | 22:11 |
| lifeless | wildfire: EPARSE ? | 22:12 |
| threeve | jelmer: Okay, I thought that might be the case but I thought maybe only the patched bindings were necessary. Building a new Subversion now. Thanks | 22:13 |
| lifeless | cr3: :P | 22:13 |
| wildfire | lifeless, most people are not neophiliac's like you and I and most other developers. People who are not on development editions will never, generally, run into the issue since "shiny" isn't what they care about - they are 'generic folk'. | 22:16 |
| wildfire | Therefore the problems of generic folk and development folk are not normally intertwingled. | 22:16 |
| jelmer | wildfire: I think more people care about "shiny" than just a couple of developers :-) | 22:17 |
| lifeless | wildfire: for this discussion, I'm wearing the hat of generic folk | 22:17 |
| lifeless | wildfire: I don't want a shiny bb, I want a working bb. | 22:17 |
| lifeless | wildfire: dependency issues between components used by bb have forced bb to require versions that are not available on freebsd; either by being too old, or once fixed, by being too new. | 22:18 |
| wildfire | lifeless, with my (slight-tipsy) sysadmin hat on, I'd suggest the best thing would be a specific python chroot devoted to have the right dependancies for tg, sqlalchemy and bb all installed at the specific versions | 22:21 |
| wildfire | s/to have/to having/ | 22:21 |
| wildfire | once they OS has the appropriate ones you can always migrate it back out of the chroot | 22:21 |
| lifeless | wildfire: I don't want to sysadmin this service :P. So I'm simply punting the problem to the -noc team there | 22:22 |
| Pretto | hi all | 22:25 |
| mwhudson | this is strange, right: | 23:08 |
| mwhudson | mwh@grond:debian-packaging$ cat .bzr/branch/last-revision | 23:08 |
| mwhudson | 2 ted@canonical.com-20080401051631-3zsnbir02j3c0ihp | 23:08 |
| mwhudson | mwh@grond:debian-packaging$ bzr revision-history | wc -l | 23:08 |
| mwhudson | 30 | 23:08 |
| mwhudson | ? | 23:08 |
| jelmer | mwhudson: yeah, that's very weird | 23:08 |
| lifeless | the cached revcount would appear to be wrong | 23:13 |
| mwhudson | sure looks like it | 23:14 |
| mwhudson | i can try and grab ted and ask what he did i guess | 23:15 |
| mwhudson | (it's this branch) | 23:15 |
| mwhudson | https://code.edge.launchpad.net/~ted-gould/gnome-power/debian-packaging | 23:15 |
| lifeless | abentley: so the api I proposed in my new stream doco doesn't work | 23:15 |
| abentley | I guess we're all a bunch of boobs, then. | 23:16 |
| lifeless | abentley: I think it will work better if rather than returning the bytes, I return a factory object that can return as_knit, as_fulltext, etc. | 23:16 |
| lifeless | I mean, it works ok in the common case | 23:16 |
| lifeless | but isn't able to handle the iter_rev_trees thing. I tink that the small change above will. | 23:17 |
| lifeless | so I'm doing a hallway test :P | 23:17 |
| lifeless | breakfast | 23:18 |
| abentley | I don't get it. Isn't this just for fetch? | 23:20 |
| lifeless | its for fetch including the case of plain -> rich roots | 23:22 |
| lifeless | I have a call in ~8 minutes with thumper and an errand to run first, back to chat after that | 23:23 |
| igc | morning | 23:53 |
| jelmer | Hi Ian! | 23:54 |
| igc | hi jelmer - I'm back from holidays | 23:55 |
| igc | fiji was awesome | 23:55 |
| jelmer | :-) | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!