| caravel | BlazingSun: I'm researching this since I may have the same issue -- we're really off-topic now, we'll be kicked out soon :) | 00:02 |
|---|---|---|
| caravel | BlazingSun: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434 | 00:02 |
| BlazingSun | caravel: yeah i found that too, but i cant find where to change the umask | 00:33 |
| BlazingSun | caravel: i think bzr+ssh and bzr over sftp are different, not 100%sure thou | 00:35 |
| * caravel didn't know about the bzr+ssh prefix ^^ and -- finally, understands BlazingSun ^^ | 00:35 | |
| caravel | BlazingSun: well, my little brain can't see how else that could work | 00:36 |
| caravel | have you tried the Subsystem command ? found another one for more recent version of openssh, hold on | 00:37 |
| caravel | (since 5.4p1) Subsystem sftp /usr/lib/openssh/sftp-server -u 022 | 00:38 |
| caravel | BlazingSun: found this too http://forums.debian.net/viewtopic.php?f=30&t=59365#p344998 | 00:40 |
| caravel | BlazingSun: but really, I think you should ask on #debian :) | 00:40 |
| BlazingSun | caravel: yeah if i dont find whats wrong i will probably do | 00:41 |
| caravel | BlazingSun: look at /etc/login.def still, see my last link | 00:41 |
| caravel | Could anyone confirm everybody, how bzr+ssh works ? Can hardly find any doc about smartserver on official doc, and that's two of us who are interested. Does this not result in using sftp ? | 00:43 |
| BlazingSun | caravel: changing umask in login.def didnt change anything | 00:43 |
| BlazingSun | caravel: everything working fine, except creating new branches :( | 00:44 |
| caravel | BlazingSun: did you try Subsystem and restart sshd ? | 00:45 |
| BlazingSun | caravel: not yet | 00:45 |
| BlazingSun | caravel: but sftp isnt ssh, as far as i know it only uses the permissions of ssh | 00:45 |
| fullermd | sftp is a protocol that runs over ssh. | 00:49 |
| fullermd | bzr+ssh doesn't use sftp at all, it just talks to bzr. | 00:49 |
| caravel | thanks fullermd: I couldn't find anything about how the "smart server" mode works, from what I read there are basically two instances of bzr talking to each other, hence "optimizing" transfers by doing as much server side work as possible -- so I take it as similar to rsync, right ? | 00:50 |
| caravel | is there ANY doc avail any where ? been digging the whole of canonical, yet (I believe !) | 00:51 |
| fullermd | Well, insofar as you've got bzr talking to bzr, like rsync talking to rsync. The protocols don't have any resemblance to each other... | 00:51 |
| fullermd | At the protocol level? I think there are some (probably outdated) docs in the tree... it's mostly just in the code. | 00:51 |
| BlazingSun | fullermd: you have any idea how to get bzr+ssh to work? the write-permission doesnt get set right when creating a new branch. not directly bzr relatet | 00:53 |
| BlazingSun | *related | 00:53 |
| caravel | fullermd: sure. so who's writing on disk, is this the bzr executable on the server side, and doing the entire rsync-like file combination ? or is it just telling the bzr client what files to upload over sftp ? | 00:53 |
| fullermd | No, it's all bzr-bzr. There's no sftp involved in bzr+ssh. | 00:54 |
| fullermd | BlazingSun: What's "not right"? | 00:54 |
| caravel | fullermd: ok thanks | 00:54 |
| BlazingSun | fullermd: i want to have several users that can access the same branch, but when i create the branch with one, the write-permission for the group does not get set | 00:56 |
| BlazingSun | fullermd: so the other users cant push | 00:56 |
| BlazingSun | fullermd: seems umask-related | 00:56 |
| caravel | fullermd so BlazingSun may face a bzr issue, right ? bzr is the process receiving the user perms from ssh login, and applying them wrongly when writing ? | 00:56 |
| fullermd | Creating a new branch follows umask. You'd need to reset it after creating for group write or the like. | 00:56 |
| fullermd | Well, "wrongly" is a matter of perspective. It's certainly inconvenient in this case. | 00:57 |
| BlazingSun | fullermd: i am using debian6 but setting the umask in login.def doesnt change anything | 00:58 |
| BlazingSun | fullermd: and cant find any other place, that may overwrite the setting there | 00:58 |
| caravel | BlazingSun: tried it first over simple ssh login ? | 00:58 |
| BlazingSun | sure | 00:59 |
| BlazingSun | same problem | 00:59 |
| BlazingSun | everything working, only the w-flag doesnt get set | 00:59 |
| fullermd | Got me. I always just use shell rc files. | 01:00 |
| caravel | BlazingSun: look at this : Another solution to set the permissions would be to use dnotify. Create /usr/local/sbin/dnotify_handler-reset_perms.sh script with the following | 01:04 |
| caravel | http://serverfault.com/questions/127658/how-do-i-set-permissions-structure-for-multiple-users-editing-multiple-sites-in/127686#127686 | 01:04 |
| caravel | BlazingSun: fullermd's rc files sound a bit, well, lighter ^^ | 01:07 |
| fullermd | But not without ugliness. You probably wouldn't want to permanently wire umask that far open. | 01:07 |
| fullermd | At least if the account is used for anything other than bzr. | 01:07 |
| caravel | fullermd: right | 01:08 |
| BlazingSun | hmm yeah, i only want to have files ctreated in my bzr-repository have rw-flags for the group | 01:08 |
| BlazingSun | and i dont want to change them manually for every new branch | 01:09 |
| BlazingSun | (changing manually works) | 01:09 |
| BlazingSun | i just want that everyone is h his groupable to create new branches and share them wit | 01:09 |
| BlazingSun | i just want that everyone is able to create new branches and share them with his group | 01:10 |
| caravel | then dnotify may help, again you should ask #debian what to do better, but that should work | 01:10 |
| fullermd | As ugly hacks go, you could just setup a chmod in cron to whack it every hour or something. | 01:11 |
| caravel | fullermd: ^^ I'll go now, can you confirm there is no official doc about the "SmartServer" mode ? | 01:11 |
| BlazingSun | then it wouldnt be instantly | 01:11 |
| fullermd | I'm not sure what sort of doc you want... | 01:11 |
| caravel | fullermd: user doc for a start | 01:12 |
| fullermd | "Use bzr+ssh://whatever and have bzr installed on the server" | 01:12 |
| fullermd | 's about all there is... | 01:12 |
| caravel | fullermd: right -- so it's just executed by the ssh user, no daemon whatsover running on the host ? | 01:13 |
| BlazingSun | not really :( | 01:13 |
| fullermd | Yes. | 01:13 |
| BlazingSun | hm you dont have to set anything up, but setting permissions right seems a little bit complicated | 01:14 |
| fullermd | Much like CVS :ext: mode, etc. | 01:14 |
| BlazingSun | im no expert but still have some knowledge and im trying for a few hours now... | 01:14 |
| caravel | fullermd: thanks a lot, gotta go now. Bye & BlazingSun, good luck ^^ | 01:15 |
| BlazingSun | hmm maybe acl would be a solution | 01:16 |
| BlazingSun | caravel: gn8 | 01:16 |
| spiv | [5~[6~[6~[6~ / .http://doc.bazaar.canonical.com/latest/en/admin-guide/simple-setups.html#smart-serverhttp://doc.bazaar.canonical.com/latest/en/admin-guide/simple-setups.html#smart-server is the doc | 01:17 |
| spiv | Ugh, bad connection. | 01:17 |
| BlazingSun | the doc doesnt mention anything that would help setting up a bzr-system with multiple users | 01:17 |
| BlazingSun | over ssh | 01:19 |
| === james_w` is now known as james_w | ||
| caravel | spiv: thanks! I wonder how I could miss it. Before I left I had found this doc also, a bit closer to my search http://wiki.bazaar.canonical.com/Specs/SmartServer Also, BlazingSun's issue would deserve being documented here http://wiki.bazaar.canonical.com/Bzr_and_SSH ...but isn't either. Night' | 03:26 |
| spiv | Woo, I have bzr-loom passing tests with bzr.dev and fetching all threads in one operation. | 04:49 |
| spiv | Only slightly nasty hackery required :/ | 04:50 |
| lifeless | spiv: \o/ | 04:52 |
| lifeless | thats -awesome- | 04:52 |
| lifeless | spiv: would you like a job working on bzr ?:) | 04:52 |
| spiv | lifeless: right now I'd settle for a working car and less bouts of gastro being brought home by my son... do you think you can arrange that? :) | 04:59 |
| spiv | It was a bit thornier to do than I expected, actually. | 05:00 |
| lifeless | spiv: let me wave my magic wand | 05:00 |
| lifeless | spiv: good test case for the API though, right? ;) | 05:00 |
| spiv | It mostly went smoothly, more code deleted than added, etc. | 05:00 |
| spiv | Yeah, it was, the API will need a small tweak :) | 05:00 |
| spiv | But then the hpss acceptance tests broke... | 05:01 |
| spiv | The tension is that we'd like to ask the remote side which heads to fetch: for built-in formats it's tip + tags, but for loom it's different, so we need the ability for loom to give a different answer there. | 05:02 |
| spiv | But ideally without adding in an extra round-trip that we didn't need before (for the built-in formats0. | 05:03 |
| spiv | So it's easy to add a heads_to_fetch RPC, but usually we don't want to call it because it'll be an extra roundtrip. | 05:05 |
| spiv | At the moment I have an ugly hack that looks at the branch format, and if it's a metadir format then it checks the _branch_class.heads_to_fetch, and if it's the same as the base Branch.heads_to_fetch, it just uses that. | 05:07 |
| spiv | Otherwise it asks the remote instance. | 05:07 |
| spiv | I'm not especially happy with that. Somehow our layering isn't working so nicely for us: the caching of the tags dict and last-revision-info etc isn't completely automatically accelerating everything that would use them. | 05:10 |
| spiv | There's also the aspect where we aren't very clear about where exactly the division of responsibility is for local vs. remote. Is it up to the client to calculate the heads to fetch by itself, or should the server always be in control? | 05:11 |
| spiv | Anyway, I've hacked around this case. Hopefully we don't need many more like it :) | 05:12 |
| lifeless | spiv: why would the receiver know the tags | 06:00 |
| lifeless | spiv: I mean - surely the server should be determining the heads | 06:00 |
| lifeless | optionally constrained by the client - 'Oh, and I want X also, kthanxfetch' | 06:01 |
| lifeless | or 'but not tags today' | 06:01 |
| spiv | Well, all of branch/pull/merge fetch tags already today. | 06:03 |
| spiv | (And after recent fixes they fetch the revisions those tags refer to as well) | 06:03 |
| lifeless | which is great | 06:04 |
| spiv | So, currently in lp:bzr, there's no 'heads_to_fetch' RPC or anything like that: it's entirely up to the client to inspect the branch and decide what heads to fetch based on that. | 06:05 |
| lifeless | sure | 06:07 |
| spiv | I have a branch now that adds a heads_to_fetch method and RPC, and a branch of bzr-loom to override that to add in the threads' heads... | 06:07 |
| lifeless | I'm just riffing on the long term concepts | 06:07 |
| lifeless | this is great stuff | 06:07 |
| spiv | ...but my issue today is that actually using that RPC unconditionally regresses the HPSS call count tests. | 06:07 |
| fullermd | That sounds... oddly backward to my uninformed speculation... | 06:07 |
| spiv | fullermd: which part? | 06:08 |
| fullermd | Well, the whole 'heads_to_fetch' concept/workflow. | 06:09 |
| fullermd | I mean, from the cheap seats (they're very comfortable, thank you) it seems like it's just a single request/response: "I want branch XYZ, here are the heads I already have" "OK, your new head is X, and here's a stream of the revs you need to get there" | 06:10 |
| fullermd | (I guess even the 'your new head is' bit is technically redundant, but...) | 06:10 |
| spiv | There's a couple of issues there. | 06:10 |
| fullermd | Jumping through a "what heads should I fetch?" "OK, now I'll fetch 'em" sounds like a long way to carry the water. | 06:10 |
| spiv | One is that "here are the heads of my repo" isn't a cheap operation | 06:10 |
| fullermd | Yeah. But you need to do it anyway (or just accept potentially fetching more than you need; and you could do that in this case too) | 06:11 |
| spiv | Arguably it should be, but it isn't and we haven't decided to make the format changes necessary to maintain an up-to-date cache of current heads. | 06:11 |
| spiv | Also, sending the remote side "here are all my heads" doesn't necessarily help you at all if the remote side has none of those revisions. | 06:12 |
| spiv | e.g. if you are pushing a new revision. | 06:12 |
| spiv | Anyway, I think this is actually a bit tangential to the original topic | 06:13 |
| spiv | You're talking about how to implement "I want the data for X, and I already have Y" | 06:13 |
| spiv | I'm talking about how you determine what X is in the first place. | 06:13 |
| spiv | It's not (necessarily) a single revision. | 06:14 |
| fullermd | Well, if you're pushing, you're not pulling :) I hold dark thoughts about the utility of turning that sort of conceptual symmetry into codepath symmetry. | 06:15 |
| fullermd | In my sense, X is the branch, not a rev; passing whatever that calls for can be known by the client saying what it has. A second pass may be needed to fill in unknown tag revs, but that's a 1% (if that) case that I'd be perfectly happy to punt to extra RTT's when needed. | 06:17 |
| spiv | Also, it's not hard to construct plausible scenarios where two repos have 99% of their graph in common, but have zero overlap in their heads. | 06:17 |
| fullermd | But yeah, it's all tangential. | 06:18 |
| spiv | It might be nice to have RPCs that work along those lines. | 06:20 |
| spiv | Stacking would complicate it somewhat. | 06:20 |
| fullermd | That falls into "what cases do you optimize for". Anyway. It just Seems To Me(tm) that having the client try and grab both graphs and combine them is a lot of indirection, compared to both sides talking graph subsets at each other until one or the other finds a common point. | 06:21 |
| spiv | (Not to mention the friction with the current bzrlib APIs, although perhaps that will change) | 06:21 |
| fullermd | Especially since the 90% (99%?) case of pull would be right there when the client first says 'hey, here's my current head'. | 06:21 |
| spiv | Both sides do talk graph subsets to each other, take a look at the get_parent_map RPC. | 06:22 |
| fullermd | That, too. This is where us non-OO personages leave the train :p | 06:22 |
| spiv | And we already cope with the 9x% case of pull just fine :P | 06:22 |
| === chx is now known as chx_sleep | ||
| jelmer | maxb: bzr-svn should be compatible with older versions of bzr | 10:21 |
| jelmer | maxb: if it's not, that's a bug | 10:21 |
| maxb | jelmer: hmm? | 10:21 |
| jelmer | maxb: Also, do you know about debian/update-deps.py ? | 10:22 |
| maxb | jelmer: Ah, you're referring to my packaging branch commit? My *intention* was to add 2.4 as compatible in debian/control, not disown compatibility with previous versions | 10:23 |
| maxb | I did not know about debian/update-deps.py, though I appear to have updated manually to the same end result | 10:27 |
| jelmer | yeah, it does things like preserve ordering | 10:33 |
| vila | wow, I thought it was due to some bug but we really have an import consuming 4.6GB :-/ (nexuiz-data) | 10:58 |
| vila | no time to investigate now | 10:58 |
| jelmer | that's a very large package | 10:59 |
| jelmer | the binary package alone is a couple of hundred Mb | 10:59 |
| vila | jelmer: if we the host replacing jubany has less memory, we'll have a serious problem | 11:07 |
| jelmer | vila: It's unfortunate some things scale with the size of the tree at the moment :-( | 11:09 |
| vila | jelmer: could be, but I suspect there is more than the tree size involved here | 11:12 |
| jelmer | vila: it doesn't seem coincidental that this is one of the largest source packages in Debian/Ubuntu that's causing us problems | 11:14 |
| vila | right, as I said in bug #724890, this needs more investigations than I can provide right nwo | 11:15 |
| ubot5 | Launchpad bug 724890 in Ubuntu Distributed Development "excessive memory consumption for nexuiz-data" [Critical,Confirmed] https://launchpad.net/bugs/724890 | 11:15 |
| jelmer | the size of the compressed tree is 1G | 11:16 |
| * jelmer comments on the bug | 11:16 | |
| vila | jelmer: thanks ! | 11:17 |
| vila | jelmer: may be worth bubbling up to the losas, the migration is planned for 1st March and I'll be in vacations starting in a few hours, I'd like to concentrate on filing bugs about what I've seen yesterday experimenting with the new driver | 11:18 |
| jml | what's the difference between switch and update? | 11:20 |
| jml | or, actually what I mean is, | 11:21 |
| jml | a friend of mine has pushed a feature branch over the top of trunk rather than merging it in, he wants to get trunk back... | 11:21 |
| jml | I'm telling him to use 'bzr heads' to get the revid of the trunk tip | 11:21 |
| jml | and now I'm about to tell him to run something with that revid | 11:21 |
| jml | but I don't know whether that should be 'switch' or 'update' | 11:22 |
| jml | (also, is there a FAQ for this? it seems like a common rookie mistake) | 11:22 |
| * jelmer waves to jml | 11:22 | |
| jml | jelmer: hi | 11:22 |
| jelmer | jml: I'm not aware of an FAQ for it, but you're right that there probably should be one. | 11:23 |
| jelmer | "bzr update -r" seems like the right solution now | 11:23 |
| jml | jelmer: thanks. | 11:23 |
| jelmer | I've always used "bzr pull --overwrite -r<revid> ." previously | 11:23 |
| jelmer | but that's not really intuitive | 11:23 |
| jml | so many ways to do what feels like the same thing. | 11:24 |
| jelmer | jml: "echo revid > .bzr/branch/last-revision" ? :) | 11:25 |
| jml | :) | 11:25 |
| maxb | jml: update: change the revno of a working tree; switch: change the branch and revno of a working tree | 12:01 |
| jml | maxb: I guess that means switch is a superset of update | 12:01 |
| maxb | yes | 12:01 |
| jelmer | not entirely, "bzr up" without arguments will update the working tree | 12:02 |
| jelmer | I don't think if you give switch the current revision it will touch the working tree, even if it is out of date | 12:02 |
| maxb | If a feature branch has been pushed (without --overwrite) into trunk then `bzr heads` will not help, as the old head of trunk will no longer be a head | 12:02 |
| jelmer | maxb: "bzr heads --dead" should still show it | 12:03 |
| jelmer | ah, sorry | 12:03 |
| * jelmer should learn to read | 12:03 | |
| jelmer | maxb: Sorry, that's the second time this morning. | 12:03 |
| maxb | :-) | 12:04 |
| maxb | More coffee needed? | 12:04 |
| jelmer | I guess so :) | 12:04 |
| jml | maxb: so how do I figure it out then? | 12:06 |
| maxb | I'd fire up qlog | 12:08 |
| maxb | And locate the second parent of the last merge from trunk into the feature branch. | 12:09 |
| vila | jelmer: I've got a fix up for review regarding the import driver getting killed by an exception from a import thread | 12:14 |
| vila | jelmer: I would love to leave for vacations (RSN now ;) with such a fix landed on jubany | 12:15 |
| vila | jelmer: but no pressure really ;D | 12:15 |
| jelmer | vila: hehe | 12:15 |
| jelmer | vila: happy to have a look | 12:15 |
| jelmer | we really should make udd a part of the "bazaar" superproject.. | 12:15 |
| vila | https://code.launchpad.net/~vila/udd/724898-driver-catch-importer-exceptions/+merge/51284 | 12:15 |
| vila | jelmer: for the reviews you mean ? Cos' I'm thinking about turning it into a bzr plugin too... ;) | 12:21 |
| jelmer | vila: yeah - my life is driven by http://code.launchpad.net/bazaar/+activereviews | 12:21 |
| vila | I was suspecting that and I think we should change the patch pilot instructions to switch to that page too | 12:22 |
| vila | if only to be aware of the mp we're missing therre otherwise | 12:22 |
| jelmer | vila: Yeah, I think that'd be useful | 12:24 |
| vila | jelmer: Thanks for the review ! | 12:37 |
| vila | jelmer: I've landed it on jubany but I feel bad asking for a restart while nexuiz-data has already run for 165 mins CPU | 12:38 |
| vila | jelmer: could you check it once in a while (while == day will be enough) and ask a losa to restart it then ? | 12:39 |
| jelmer | vila: ok | 12:39 |
| vila | jelmer: 1e6 thanks :) | 12:39 |
| jelmer | :) | 12:39 |
| jelmer | vila: I guess it'll be quiet early next week then :-/ | 12:45 |
| vila | jelmer: hmm, yeah, forgot to mention that: you're the house keeper, so please don't forget the spider webs in the attic :-D | 12:46 |
| jelmer | hehe | 12:46 |
| vila | jelmer: and here are some votes for your mps: +1 +1 +1 +1 +1, use them wisely ;D | 12:47 |
| jelmer | vila: lol :) | 12:47 |
| montywi | vila: after 2600 minutes, I got this from bzr check: http://monty.pastebin.com/zZRryR4R | 12:59 |
| montywi | (internal error) | 12:59 |
| vila | montywi: that's just ... file a bug please :-( I don't remember off-hand if the check order has changed in more recent versions but I suspect this one could reported far earlier | 13:16 |
| vila | the revision seems a bit old, tht's even more worrying | 13:17 |
| vila | it's even from the initial migration, how odd | 13:17 |
| vila | montywi: but above all check shouldn't fail with an internal error :-( | 13:18 |
| vila | montywi: I won't be able to do anything, I'm leaving for a one week vacation but keep this repo safe | 13:19 |
| montywi | will do | 14:06 |
| montywi | thanks | 14:06 |
| burli | hi | 14:27 |
| burli | I want to use Bazaar on Lauchpad, but I have problems to setup launchpad and my computer | 14:39 |
| alf | burli: What exactly is the problem? | 14:40 |
| burli | ok, I have a launchpad account and I add an OpenPGP and SSH Key | 14:40 |
| burli | But if I try to create a branch I got just something that starts with /+junk/ | 14:42 |
| burli | like this https://code.launchpad.net/~mb-embedit/+junk/mystock | 14:42 |
| alf | burli: +junk is the prefix for personal branches (not associated with a project), so this is normal | 14:44 |
| alf | burli: https://code.launchpad.net/~mb-embedit/+junk/mystock is empty though, have you pushed something to it? | 14:45 |
| burli | alf, right | 14:45 |
| burli | I want to push something into it | 14:46 |
| burli | what is my user id?? | 14:46 |
| burli | bzr launchpad-login userid | 14:47 |
| alf | burli: mb-embedit | 14:47 |
| burli | ah, without ~ | 14:47 |
| burli | damn | 14:47 |
| burli | what can I do if I use different computers or make a new installation? | 14:51 |
| burli | Can I take the keys with me? Or Import the Keys? | 14:52 |
| burli | I don't really understand the concept of OpenPGP or SSH Keys | 14:52 |
| alf | burli: yes, you can copy the keys if you like, but you can also register multiple keys in Launchpad, too | 14:56 |
| burli | Its a little bit confusing for me | 14:56 |
| burli | brb | 14:59 |
| burli | alf, I think it works now | 15:07 |
| alf | burli: great :) | 15:08 |
| burli | alf, another question. I want to fork a project and I want to merge changes from the original project. I create a clone, run "bzr pull" in the original project and than "bzr merge" in my fork. Now I have some conflicts. | 15:16 |
| jelmer | vila: we need a Debian GNU/kFreeBSD vm in babune :) | 15:16 |
| * jelmer was just made aware of some test failures | 15:16 | |
| burli | I have now some files like *.BASE, *.in, *.OTHER and *.THIS | 15:17 |
| burli | what should I do now? | 15:17 |
| burli | ah, resolve | 15:18 |
| jelmer | burli: resolve the conflicts by editing the file/overwriting it with one of the *.{BASE,OTHER,THIS} files and then run bzr resolved | 15:19 |
| burli | jelmer, thx. done | 15:20 |
| alf | burli: yes, and note that *.in is a normal source file, not produced by the conflict | 15:20 |
| burli | I guess, I got it.... I hope so | 15:21 |
| === deryck is now known as deryck[lunch] | ||
| === beuno is now known as beuno-lunch | ||
| === chx_sleep is now known as chx | ||
| === chx is now known as chx_sleep | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| === Ursinha is now known as Ursinha-lunch | ||
| cr3 | what's the proper way to merge diffs between releases from one branch to an unrelated branch, like lp:foo to lp:ubuntu/foo for example. I keep doing something like (cd /path/to/foo; bzr diff -r1..2) | patch -p0, but that's aweful :( | 17:09 |
| jelmer | cr3: hi Marc | 17:11 |
| jelmer | cr3: Unfortunately if the branches don't have any related history we don't really have any better alternatives at the moment. | 17:11 |
| cr3 | jelmer: darn, using patch is unfortunately error prone, like permissions not being preserved and so forth | 17:12 |
| jelmer | cr3: We're aware of the problem and would really like to fix it (it's common in the UDD use case, where upstream, debian and ubuntu all have different imports of essentially the same data) | 17:13 |
| cr3 | jelmer: I'm sure if it's not implemented yet there's a good reason, like very complicated problem to solve :) I wish you best of luck solving that problem then! | 17:15 |
| jelmer | it's a very hard problem to solve right, but we could at least provide you some tools to make it a bit less painful | 17:17 |
| burli | can I make a private bazaar branch on launchpad? | 17:31 |
| jelmer | burli: only with a commercial launchpad subscription | 17:31 |
| burli | hm | 17:31 |
| burli | is it possible to install my own bazaar server? I have one project, that is not public, but I want to use bazaar for versioning | 17:34 |
| jelmer | burli: yes, you can run your own server using bzr itself and set up a web interface using loggerhead | 17:37 |
| briandealwis | hi jelmer. Is there a bzr-svn newer than 1.0.4? bzr 2.3.0 complains about api versions with 1.0.4 | 17:37 |
| jelmer | briandealwis: there is going to be a 1.1.0, but it's not out yet | 17:37 |
| briandealwis | ahok | 17:37 |
| burli | jelmer, is there a documentation/tutorial how to install/setup such a server? | 17:38 |
| briandealwis | burli: see the docs. http://doc.bazaar.canonical.com/latest/en/user-guide/server.html | 17:38 |
| burli | briandealwis, thx | 17:39 |
| burli | is there any problem if I use different versions of bzr? My server is running Maverick and on some computers I run Natty | 17:40 |
| * jelmer heads off for some weekend | 17:44 | |
| maxb | hrm | 17:59 |
| maxb | subvertpy appears to be repeatably segfaulting in its tests on maverick/amd64 | 17:59 |
| mgz | jam or someone, does this diff actually make any sense? | 18:07 |
| mgz | http://www.physics.drexel.edu/~wking/code/git/gitweb.cgi?p=be.git;a=commitdiff;h=1e0967ab82d8541413e1dfe4d2e78f1008aa9c5b;hp=6eeb62d99a40f8644ac0840ac1291ef92b3d836f | 18:07 |
| mgz | as the path is always inside the repo, won't the base_tree and tree always be the same, so he *could* just omit the 'file_ids_from' param? | 18:08 |
| mgz | ...there is no jam. | 18:09 |
| === Ursinha-lunch is now known as Ursinha | ||
| === chx_sleep is now known as chx | ||
| mgz | ...that doesn't make any sense, why did I type that... | 19:09 |
| lifeless | the shadow knows | 19:12 |
| mgz | meh, I've never known the c standard that well anyway. | 19:17 |
| === Ursinha is now known as Ursinha-afk | ||
| burli | hm, what's wrong? I created on my server a new bzr project with bzr init. I can create a branch on different computers, can pull and push. everything works. But the project folder on the server is empty | 21:16 |
| Peng | burli: It's not empty; it has a .bzr directory full of data. It just doesn't have a working tree. | 21:19 |
| burli | Peng, ah, ok, thx | 21:34 |
| === Ursinha-afk is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!