[00:06] jelmer, ping [00:15] spiv: 78->25 [00:15] lifeless: if you have the bandwitch available, your input on the above questions for loom and quilt would be appreciated [00:15] s/witch/width/ [00:16] bignose: hmm, thought there was a bug open; filing one [00:17] I want bzr send to generate a patch series [00:19] https://bugs.edge.launchpad.net/bzr-loom/+bug/336470 [00:19] Ubuntu bug 336470 in bzr-loom "bzr send should output a patch series (by default, overridable) when used with a loom" [Undecided,New] [00:19] lifeless: do you have any ideas about bug 336267? [00:19] Launchpad bug 336267 in bzr "bzrlib.errors.KnitCorrupt during branching" [Undecided,New] https://launchpad.net/bugs/336267 [00:21] poolie: something has mangled the actual error, but from its phrasing I'd guess at zlib [00:21] yes [00:21] poolie: (phrasing and being in the header parsing stage) [00:21] it seems like a very low-level error to be caused by us [00:21] I don't think its a bzr bug, though it might be. I'd instead be expecting bad data [00:21] i thought so too [00:22] its on the client side [00:22] and its in the pack repo code [00:22] so its using regular vfs methods; and spiv and I haven't done anything nasty to those [00:22] lifeless: thanks for the response, and the bug report [00:23] bignose: the send -r thread:..-1 loop is missing a 'bzr switch next-thread' in it, if you want to reproduce by hand [00:25] why would I choose ‘send’ over ‘diff’ in this case? [00:33] I realise its at my end, but please use plain ascii for this conversation, otherwise I can't read what you are typing. [00:33] I saw "why would I choose a over a in this case?" [00:38] Does anyone here use trac-bzr? Can anyone tell me if it is capable of working with multiple branches? [00:41] I get the feeling that it is supposed, to, but I'm only able to successfully browse the branch containing the most recent revision. [00:43] lifeless: why would I choose 'send' over 'diff' in this case? [00:43] bignose: if you're submitting to bzr users, use send. If you're submitting to non-bzr users, you can use send or diff [00:44] bignose: send includes the revision metadata and any dependent history to allow a normal merge to be done at the far end [00:47] okay. since in this instance I'm only generating the patch for use with quilt, I'll just use diff. [01:01] What is the correct workflow for maintaining two branches of a project with a "dev" and a release branch (eg: 1.0)? Do I commit to dev, then pull that commit from dev to the 1.0 branch somehow? or just commit to both separately (which would have the possibility of non-mergeable branches later, right? I might be wrong with this) [01:13] greg-g: definitely don't make unrelated commits to both [01:13] i'd consider having actually a branch per individual release on 1.0 [01:13] like 1.1, 1.2, etc [01:14] otherwise, either merge in to 1.0 and then do bzr ci -m "release 1.0.1" [01:14] or just pull [01:14] either would work [01:14] our 1.0 is the branch that we are going to release as 1.0 when we feel it is ready. basically a "stable" branch [01:14] the first will be better if you ever need to do little fixes directly in 1.0 to fix packaging bugs for examlpe [01:14] oh i see [01:14] so the other thing is, it's generally easier to merge from a more-stable branch into a less-stable [01:15] than vice versa [01:15] so i'd consider, for any work that will land in 1.0 [01:15] doing it in a branch based off 1.0 [01:15] then merging to 1.0, and then either merging all of that back to trunk, or merging the individual bits [01:15] this is not so much for technical reasons as just that as the software changes [01:16] it tends to be easier to update your 1.0 changes to fit other stuff than to backport your fixes [01:16] so for things that are more or less self-contained commits, put in 1.0, then merge to dev from there. but what about things that are partially implemented but we want to test with dev? [01:16] how do you mean partially implemented? [01:16] then later, when completed, merge only that feature into 1.0 [01:17] igc, btw thanks for fixing the status html; what was wrong? [01:17] igc, also, maybe i should change it to order bzr-dev first? [01:17] greg-g: ok i think i understand [01:17] i would: make a branch off 1.0, implement it there [01:17] and primarily test there [01:17] if, before you're finished, you also want to check how well it will mesh with dev [01:17] make *another* branch coming dev, merge your new features in to that [01:18] then when you're done, you merge those two work branches in to 1.0 and dev respectively [01:18] gotcha [01:19] would cherrypicking also be an acceptable way to handle that (cherrypick it from dev to 1.0)? [01:21] I saw there was something about bzr not tracking cherrypicked revisions. I'm too knew to understand where that will have an adverse effect in the future. [01:23] poolie: status html? you mean the colouring? [01:24] poolie: I think the first tool ought to be bzr-current, i.e. the currently released version [01:24] bzr.dev ought to be compared to that [01:24] poolie: I'm not sure looking at earlier versions (before bzr-current) buys much [01:25] poolie: the 3 interesting versions IMO are bzr-current bzr-dev bzr-brisbane [01:26] lifeless: bzr selftest groupcompress is failing because ... [01:27] 1. I haven't compiled the groupcompress_c stuff using pyrex [01:27] 2. some other issue [01:27] lifeless: it looks like the tests are *meant* to skip ... [01:27] the compiled tests if the compiled stuff isn't there? [01:28] no [01:28] I wonder if setUp() happens before tests_needs_feature? [01:28] (^ that was ) [01:28] * spiv & lifeless -> food [01:48] igc: possibly; for now, just build them :) [01:52] igc, i was thinking bzr-dev first because that's what we're more likely to change for good or ill [01:52] also i should check current is in fact current now :) [01:54] as we have a current now, that should be easier to maintain :) [01:54] greg-g: the adverse effect is fairly small and isolated. Its two things: [01:54] - you can't use bzr to report 'what has been cherrypicked' [01:55] - you may get spurious conflicts on subsequent merges if you change the line of code further [01:55] greg-g: what robert says is correct, but it's not so much about bzr capabilities [01:55] more that it's actually easier for you to write it in 90% of cases if you do not cherrypick [01:55] but keep it separate to start with [01:58] lifeless / poolie thanks! I think I've got it figured out now. [01:59] greg-g: anytime [02:11] poolie, spiv: could one of you make the tweaks you ask for for my "LockableFiles.__del__ must die" as you land it? [02:11] no promises but i'll try [02:12] thanks [02:21] jam: ping [02:32] abentley: BB is down [02:34] poolie: restarted [02:35] thanks [02:55] * igc food [03:59] Hi === abentley1 is now known as abentley [04:21] gar too much mail [04:22] I have some ideas on how to handle that. I'll send you an email about it... [04:26] Have a question for you guy, if anybody's around: [04:26] I'm currently using mercurial, but I've hit a brick wall, so seeing if bazaar can handle this better. [04:27] I have a repository with a subdirectory in it with code. When I started making the repository, I was the only one using it, so that was fine, but now I'm in another project that also needs that code. [04:28] How easy is it to have 2 bazaar repositories that share a common code-base? Ideally, I want that common code-base to be transparent to each repository - for my private repository, it looks and acts just like it always has, for the new repository there's no apparent difference whether it's in that repository or stored elsewhere. [04:28] (sorry for the lengthy msg there) [04:29] contingencyplan: there is a merge-into plugin that can join the two brances [04:39] Anyone know how to get the bzrbuildbot plugin working with a central bzr repository? [04:39] From what I can tell, each user needs to put it in their own plugins dir [04:42] * igc bbiab [04:46] lmiller: what hook does it use? [04:47] on change [04:48] post_change_branch_tip I believe [04:50] lmiller: that will run on the server [04:51] lmiller: as long as you're pushing with bzr 1.6 or so, and over bzr+ssh, not sftp or webdav. [04:51] lifeless: It requires a location.conf file, but I don't seem to have anywhere to place it on the server [04:51] where the server will find it I mean [04:52] lmiller: you can configure the same settings in branch.conf [04:52] in the branch you want to test [04:53] So, if I wanted to trigger the main branch, I would edit branch.conf inside the repos (eg /repos/main/proj/.bzr/branch/ )? [04:54] I'm coming from svn, so excuse me if I ask nervously about editing files inside the repository ... heh heh [04:54] yah, repos/main/proj/.bzr/branch/branch.conf, if your branch is bzr+ssh://host/repos/main/proj [04:54] its not ideal, we want a better answer here, but it will work :) [05:36] exceptions.NameError: global name 'failure' is not defined [05:36] Ah, I love programming [05:37] :P === chx is now known as chx_sleeping [05:48] flymake-mode ftw [05:52] so, it looks like bzr-svn really really really wants more than 360MB of RAM [05:57] lifeless: Thanks for that ... all working now [06:25] lmiller: cool [07:33] Hi all ! :-) [07:35] Wow, that's way too chipper. You obviously have coffee you need to share... [07:40] fullermd: hehe, no, same coffee as usual, but some days are better than others, just from the start (the opposite is also true...) [08:09] vila: hello, welcome! [08:16] * igc dinner [08:18] poolie: thanks :) [08:23] vila, want to talk? [08:23] poolie: with pleasure [08:24] could you call me here then? [08:25] sure [09:07] ok, stream branching collection of patches all landed [09:07] tomorrow, streaming from stacked [09:12] hi [09:12] way to go [09:22] vila, does bug 336582 look familar to you at all? [09:22] Launchpad bug 336582 in bzr "test hang in TestStackingConnections.test_open_stacked" [Undecided,New] https://launchpad.net/bugs/336582 [09:23] poolie: didn't Andrew mention that on the list today ? [09:24] it sounded familiar somehow [09:24] poolie: hmm, he mentioned hpss not sftp though [09:29] vila: yeah, my patch wouldn't affect sftp [09:30] tired -> good night all [09:31] Weird that the traceback involves SFTP, but the test doesn't run at all if FTPServer is missing. [09:32] I suspect the test is not granular enough... [09:33] gnight poolie [10:43] igc: ping [10:44] hi lifeless [10:45] so I've replied to your mail [10:45] short story though is that you need to be digging deeper, and I'd like to help you do that [10:47] * igc reads email [10:49] lifeless: thanks. I've got to run right now - might be back later [10:49] igc: ok, well I may be up; if I am, skype will know :P [10:52] igc: and if so, chat/call me on skype, I doubt I'll have irc in front of me === montywi|poker is now known as montywi [10:57] lifeless: still there? [10:57] yes [10:57] so no fast path is running [10:57] in log -v currently [10:58] well then :P [10:58] what routine are you thinking of? [10:58] CHKInventory._make_delta(aCHKInventory) [10:58] line 1709 in my copy of inventory.py [10:59] if you're not hitting that, then you're not seeing CHK delta generation, and it will blow chunks. [10:59] if you are seeing that, you're at least getting some of the work done by the CHK core [11:00] * igc pulls up profiling data [11:00] but unless you have an lsprof run, its going to be very hard to tell whats going on :) [11:01] lifeless: 77% of time in iter_changes() - inventory.py line 1655 [11:02] no calls to make_delta [11:02] ok [11:02] thats the CHKInventory fast path [11:02] so, I'd look at what its doing [11:03] (or it should be - is it CHKInventory.iter_changes?) [11:03] lifeless: oh, I know what's its doing ... [11:03] reo.get_delta_for_revisions() builds trees and calls tree.changes_from() -> delta._compare_trees -> iter_changes [11:03] s/reo/repo/ [11:04] lifeless: yes, CHKInventory.iter_changes() [11:05] ok, that all seems normal [11:05] so we're looking at the right code path [11:06] now, it may be doing duplicate work [11:06] it may be discarding one side of the trees, or things may not be getting kept in ram once loaded [11:06] I'd be inclined to instrument [11:06] finding duplicate CHK page reads, for instance [11:06] a cheap way of detecting this [11:06] is too look in the call graph [11:06] if you're doing (say) a 100 revision range [11:07] and you see 1M get_record_stream calls [11:07] then something suspect is going on [11:07] remember that there is nearly _no_ optimisation in here at the moment [11:07] assume that the core data structures are decent - John is tuning them, and they have passed all our design checks along the way [11:08] lifeless: ok, so 1000 revisions -> 15830 get_record_streams calls in groupcompress [11:08] 15 pages per revision [11:08] what project? [11:09] first 1k revisions of wordpress [11:09] how big is wordpress, files in the tree [11:11] lifeless: small, 142 files [11:11] so [11:12] we expect [11:12] 1 read to get the inventory, 1 to get the root of the dir map, 1 to get the root of the inventory entry map [11:12] (roughly) [11:12] so we can explain 3K reads [11:13] that leaves 12K reads to calculate the differences, but 142 entries isn't many [11:14] to get 15 reads per diff, I'd expect more files or many very large changes [11:14] so - I suggest using my patch for VersionedFileDecorator to whip up a little LoggingVersionedFile [11:14] and decorate the chk versioned file object on the repository [11:15] then dump the log to disk after the operation, and we can look for repeated requests [11:15] lifeless: interesting [11:15] you only need to care about get_record_stream, and the keys parameter [11:16] an interesting test would be diffing one revision [11:16] log -v 1..2 [11:16] yes [11:16] for instance [11:16] lifeless:I'll start digging deeper - thanks for your help [11:17] my pleasure [11:17] I'm oing to play computer games for a bit [11:17] I'll check back in a while [12:12] Is there anyone around who understands how to install from source (bzr-*.tar.gz) on linux, please? [12:15] <_MMA_> Ok. So it's 8hrs later and a upload to a branch I was working on is still locked. "bzr break-lock" does nothing and the recommended command to use when it tells me the branch is locked tells me: "bzr: ERROR: Unsupported protocol for url "lp-45955728:///~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio/.bzr/repository/lock" [12:18] Installing bzr from source is supposed to require only Python, right? So why does it fail trying to run gcc? [12:18] _MMA_: "bzr break-lock lp:~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio" [12:18] djr: it tries to build the C accelerators, if you don't have them then you can still just run from source [12:19] djr: but we recommend building them, it makes a big performance difference === UdontKnow is now known as root [12:20] <_MMA_> lifeless: Thanx man. I don't know whether I should file a bug. The suggestion it gives seems wrong. [12:21] _MMA_: there is one about the url it gives being bad,and another that we should auto-break in some situations [12:22] <_MMA_> Ok. I'll just hope it resolves itself. ;) [12:25] <_MMA_> lifeless: Maybe you can tell about one more. I have a bunch of older branches. So I'll get the "please use 'bzr upgrade' to get better performance" warning from time to time. So, I do. But then when going to upload after that, after upgrading, I get the warning again. Am I missing something? [12:26] _MMA_: you need to upgrade each instance - so you need to upgrade where you are pushing to [12:27] there is a bug/limitation in upgrade at the moment with launchpad; you need to use 'bzr upgrade sftp://bazaar.launchpad.net/~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio' rather than 'bzr upgrade lp:~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio' [12:28] <_MMA_> lifeless: Oh sure sure. Each branch. I didn't mean to imply that I wanted to do it once and it would be fixed for all. [12:28] :) [12:29] <_MMA_> I will upgrade a branch. Then on same branch, get the warning again. [12:29] _MMA_: do you have a shared repo? [12:30] <_MMA_> ~ubuntustudio-dev's yeah. [12:30] on your laptop/workstation I mean [12:30] launchpad doesn't have shared repos [12:31] <_MMA_> Oh Oh. ie: 2 machines that work on network shared folder? [12:32] <_MMA_> Both have access to some BZR work Im doing? [12:32] _MMA_: no, its a specific term in bzr, a 'shared repository', created by 'bzr init-repo' [12:32] <_MMA_> Ok. I remember now. No. [12:32] _MMA_: please run 'bzr info -v' on a branch where you are having this happen [12:32] <_MMA_> Gotcha [12:35] if you pastebin the output the next time it warns, I'd be delighted to help you [12:36] <_MMA_> lifeless: I'll be doing some more work later so Ill be sure to if it happens again. [12:36] djr: its possible we have a setup.py regression with installing without the extensions; if thats the case, please file a bug [12:37] djr: you can run bzr from source without installing it, as a work around - just symlink 'bzr' into your path, or add the source dir to your path [12:37] <_MMA_> lifeless: So when I run "bzr upgrade" it makes a "backup.bzr" folder. After doing "bzr add" it added that folder and now I look to be uploading that content. Can I either *not* create that backup or delete "backup.bzr" later? [12:37] you can't avoid the backup; just rm -rf backup.bzr once you've done the upgrade in a given branch [12:38] <_MMA_> lifeless: After or before a push to LP? [12:38] <_MMA_> Oh I see. [12:38] before you next commit ;) [12:39] if you've committed it, just uncommit [12:40] <_MMA_> Well I did. :( So now I've been sitting at: "[\ ] Transferring:Walking content. 1/1" since I broke the lock. [12:44] igc: deeper still :) [12:45] lifeless: in the morning, when I'm awake :-) [12:45] igc: sure [12:45] igc: are you starting to see the shape of the intent ? [12:46] beuno: do you know if loggerhead is supposed to generate relative links, instead of hardcoding the hostname in the href? [12:46] lifeless: I think so. just saw your reply ... [12:47] the root would change for a read-centric operation like log though [12:47] s/would/won't/ [12:47] igc: Nodes are immutable, so they will never change after being written; [12:47] igc: however the root will be different for every inventory unless the inventories are identical [12:48] sure [12:48] igc: so for log, we should be reusing the tree - first as child then as parent [12:54] lifeless: we do reuse the trees at the repo level *but* the code for iter_changes (tree.py line 928) always calls through to CHKInventory.iter_changes() [12:55] igc: right, that should be fine [12:55] oh, the variables you asked about, I was looking in inventory.py [12:56] I'll reply again tomorrow after I page this in [12:56] igc: _get_node would seem to be buggy, as it notes: does not update [12:57] igc: fixing that to actually update the items dict may be useful :) [12:57] :-) [12:57] igc: all the same [12:58] it kindof assumes that the differences from treeA to treeB will be similar to treeB to treeC [12:58] for that to matter [12:58] CHKMap is the code to own though [12:58] its the driving abstraction [12:58] gnight! [12:58] night (and thanks) [12:59] beuno: it seems loggerhead.apps.branch.url: request.construct_url(...) includes the hostname, so that is one piece were it is already broken [12:59] beuno: (for my use case at least, maybe there is a reason for this?) [12:59] <_MMA_> lifeless: http://paste.ubuntu.com/125256 [13:01] LarstiQ, old versions of paste/patedeploy? [13:01] beuno: python-paste 1.6, python-pastedeploy 1.3.1 [13:02] hrm, that seems correct [13:03] let me make sure I'm using loggerhead trunk [13:04] beuno: yeah, lp:loggerhead 288 [13:05] LarstiQ, it does use absolute URLs, but it should be generating them properly [13:05] you've got apache setup properly, etc? [13:06] beuno: well, how does it generate them? [13:06] LarstiQ, based on what apache tells it through pastedeploy [13:06] there's some stuff in the README about it [13:06] did you follow that? [13:07] beuno: my situation is (outerhost:4443 -> innerhost:80 -> localhost:8080) [13:07] * LarstiQ needs to look at how pastedeploy works then [13:09] beuno: the README.txt is very thin, but yeah I've got a ProxyPass setup like that. [13:09] LarstiQ, hrm... I don't really know. It's all mwhudson's magic [13:10] beuno: k, I'll go bother him then (and in fact already have a thread at bugs.launchpad.net) [13:10] beuno: thanks :) [13:11] night all [13:11] night igc [13:18] about installing bzr on linux, again. In the absence of gcc, once I have unpacked the tar.gz, what do I do? the InstallationFaq says link to ~bzr/bzr.dev/bzr, but I don't have that file/directory. [13:19] Is the bzr executable in the archive all I need? [13:20] djr: if you just run ./bzr from the unpacked source it should work [13:22] Indeed it does. I wasn't sure if maybe it was an illusion and wasn't working properly. Could someone who understands these things refresh InstallationFaq on the wiki? [13:27] beuno: fwiw, I stuck in: relative_url = urlparse.urlunparse(('', '') + urlparse.urlparse(absolute_url)[2:]) [13:28] beuno: and now it works, I'll followup with mwhudson [13:28] LarstiQ, ah, cool. Thanks :) [13:31] beuno: that does destroy the 'To get this branch, use bzr branch /loggerhead' bla, but ah well [13:31] LarstiQ, right. We're very bad with URLs in LH === barry-away is now known as barry [14:08] <_MMA_> lifeless: Man. "bzr upgrade" has never worked for me. :( I puled the branch new. (gave me the upgrade warning) Did "bzr upgrade" and removed "backup.bzr". Made a minor edit then committed/pushed to LP. Gave me the "bzr upgrade" warning again. :( [14:09] djr: It will work out of the archive, but there are some parts that can be compiled to give more performance [14:09] _MMA_: It may be warning about the branch on LP [14:13] awilkins: following the wiki seems to violate Principle of Least Surprise. It says 'all you need is Python', but by default tries to invoke gcc, and gives no guidance on how to proceed once it has failed. [14:13] <_MMA_> lifeless: Current output of "bzr info -v ": http://paste.ubuntu.com/125281 [14:20] _MMA_: that sounds like the _remote_ branch needs to be upgraded [14:21] <_MMA_> LarstiQ: Ahh.. Maybe that's what I'm hitting with alot of my branches. Is that something *I* can do? === chx_sleeping is now known as chx [14:22] _MMA_: ie, `bzr upgrade sftp://bazaar.launchpad.net/~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio` [14:22] _MMA_: yes [14:22] <_MMA_> Ah... [14:22] * _MMA_ tries. [14:26] lifeless: pong (if you are still awake) [14:27] <_MMA_> LarstiQ: That looks like it. Thanx man. [14:28] * _MMA_ goes to upgrade all his branches. [14:30] _MMA_: glad I could help [14:32] djr: doesn't it tell you that you can use "build_ext --allow-python-fallback" ? [14:35] Hi all [14:37] I'm having a strange error with bzr-rebase... http://pastebin.com/df38d43c [14:38] It tells me my tree is out of date although it isn't. [14:59] jam: no it doesn't. there is a long an noisy traceback that concludes "log.warn('\n Cannot build extensions.\n' TypeError: not all arguments converted during string formatting [14:59] djr: ok, our warning code has a typo in it. :( [15:00] to (mis)quote Etienne "I tried bzr once. It failed to install!" [15:01] Looking closer, it is the code trying to tell you '--allow-python-fallback', but it falls over at that time. [15:01] I'll make sure that is fixed for the next release [15:01] is that an additional option to 'setup.py install' ? [15:04] A: no, it's not an option that INSTALL recognises [15:04] djr: it is 'python setup.py install build_ext --allow-python-fallback' [15:11] hi all [15:12] it seems like bzr doesn't display a progress bar anymore when ran from inside a script [15:12] (for example from inside jhbuild) [15:12] is this a known issue ? [15:13] asabil: there have been some reports of the progress bar disappearing on win32, but I haven't heard anything about scripts [15:13] it may be the same root cause, though [15:14] hmm ok [15:15] it is possible that the code figuring out the 'terminal width' is somehow getting a width of 0 [15:15] or some other strang ebit [15:16] jam, it may be related to that [15:16] progress bars aren't resized for me anymore [15:16] they always stay small [15:16] jelmer: well we don't continually poll [15:16] we used to check on every update, I think [15:16] which isn't great either [15:16] the code has a comment about SIGWINCH [15:16] jam: thanks John, that's done the trick. I think that's a documentation fix as well as a code fix required? Or why not enable fallback by default, so that the first-time would-be user gets a working install even if not an optimum one? [15:16] but I don't see anything that uses a null progress bar anywhere [15:17] jam, well, they even stay small if I resize my terminal window *before* starting bzr [15:17] djr: because first-time users should know that they aren't getting an optimum one [15:17] jam, that used to work ok with the previous progress bars [15:18] jam: if you've triggered the fallback path you could tell them [15:18] jelmer: we never resize the progress bar itself [15:18] which is intentional [15:18] we *do* write more text off to the right [15:18] ah, ok [15:20] vila: are you around? [15:20] (bbiab, changing network connections) [15:22] ok, back [15:22] jelmer: you want me to file a new bug, and then you can mark it as dupe if that happens to be the case, right? [15:23] LarstiQ, please [15:23] jam: yup [15:30] jelmer: done [15:47] spiv (or anyone else): got a question for you [15:47] is there any way to move/copy/import code from a completely separate branch into a subdirectory of a different codebase and preserve the revision history of the original? === rocky1 is now known as rocky [15:54] oubiwann: yes [15:54] with a plugin I think [15:54] The word "join" is floating through my head [15:54] radix: awesome -- I'll google-dig and see what I can find, thanks :-) [15:56] oubiwann: lp:bzr-merge-into [15:56] should get you going [15:56] or https://edge.launchpad.net/bzr-merge-into if you want a bit more info [15:57] jam: thanks! [15:57] okay I guess I was wrong about join :) [15:57] radix: join works, but only in rich-root trees, etc, etc. [15:57] we're getting there :) [15:57] ah :) [16:06] jelmer: quick question about samba [16:06] I have a fairly old samba server running, and for some reason when I mount it, I can see the directories just fine [16:06] but if I try to read any *file* it aborts with a READ ERROR [16:06] Errno 13, Permission Denied (it would seem) [16:06] jam, how old is fairly old? [16:07] jelmer: 3.0.23a-1.fc4.1 [16:07] what is weird [16:07] is that it mounts just fine on my Vista machine [16:07] jam, doesn't sound familiar [16:07] jam, and on the client side? [16:08] $ smbclient --version [16:08] Version 3.0.28a [16:09] jam, The kernel version I mean [16:09] jam, (since the kernel module is not actually part of Samba) [16:09] client is Hardy, server is FC4 [16:09] 2.6.24-23-generic [16:10] hmm, that should work quite well [16:10] jam: are you using smbfs or cifsfs? [16:10] if you're not using cifsfs yet, you may want to give that a try [16:10] i'm guessing my FC4 server won't have cifsfs [16:11] but my client *is* using cifs [16:11] jam: It's the client for which it should matter [16:11] //192.168.2.10/jameinel on /home/jameinel/juju type cifs (rw,mand,nosuid,nodev,user=jameinel) [16:11] //192.168.2.10/jameinel on /home/jameinel/juju type cifs (rw,mand) [16:11] according to mount [16:11] why would there be 2 entries? [16:11] as the server doesn't need any kernel stuff [16:11] there shouldn't be two entries [16:12] jam, that may be the source of the problems [16:12] jelmer: well, after 1 umount, I have a single entry, but then it does: [16:12] $ sudo umount /home/jameinel/juju [16:12] This utility only unmounts cifs filesystems. [16:12] This utility only unmounts cifs filesystems. [16:12] How can I "bzr upload" with some uncommited changes? [16:13] To be clear: I want to upload the last commited revision, w/o working changes... [16:13] loffe: 'bzr shelve; bzr upload; bzr unshelve' ? [16:13] "bzr upload -r -1"? [16:14] jelmer: any idea of how to get it to unmount via something other than 'umount'? [16:14] jam: Well, umount.cifs but I think that's also what umount is invoking under the hood [16:14] jelmer: yeah, that gives the same error [16:15] as does 'smbumount' [16:15] though those only give the error 1 time [16:15] while 'umount' gives it twice [16:15]