[00:01] Ronnie: I've pushed the result of those three merges to lp:~maxb/loco-directory/710969-example in case an example is helpful [00:02] yes, an example could be very usefull [00:02] ill have a look [00:05] When I said: [00:05] < maxb> So, at some point in the past, you merged your 570613 branch into your 611304 branch. Then, on your 570613 branch, you reverted most of the changes. Later, the 570613 branch got merged into the upstream branch [00:05] I got some of the numbers wrong [00:05] I should have said: [00:05] So, at some point in the past, you merged your 570613 branch into your 611304 branch. Then, on your 611304 branch, you reverted most of the changes. Later, the 611304 branch got merged into the upstream branch [00:11] vila: I didn't know that, thanks for mentioning it. I don't *think* there's any obviously relevant bug fixes since then, but it's possible... [00:20] maxb: i had difficulties to read the log (history viewer from a nautilus plugin) but i think i get it. but i dont know what commands to use te revert it [00:21] i normally only work with the branch, merge, status commands, and sometimes the resolve [00:21] Ronnie: I would very much recommend installing bzr qlog [00:22] maxb: do you have a link, branch for that? [00:22] Ronnie: ubuntu? [00:22] yep [00:22] 'apt-get install qbzr' [00:23] And yes, it will probably want to install megabytes of libqt*, but I find it to be worth it, for the ease with which it lets you understand complex merging [00:23] nah, i had already the qt libs [00:26] Ronnie: I've appended the commands I used to bug 710969 [00:26] Launchpad bug 710969 in Bazaar "Merge did not work as expected" [Undecided,Invalid] https://launchpad.net/bugs/710969 [00:28] maxb: is ci a shortcut for commit [00:28] yes [00:28] ah, thx [00:29] hmm, i did not find qlog more informative than bzr-gtk history viewer (did you ever try that one?) [00:30] It's an abbreviation for "Check In" - which is actually quite silly, as it's a hold-over from the dark ages of locking VCS, but people still use it because it's short :-) [00:30] I have used bzr viz. I found bzr qlog quite superior, due to its flexible expanding and contracting of branches [00:33] maxb: at the command: "bzr merge -r revid:peter.puk@gmail.com-20101219212501-141eds74nzwexdlt ../0.2/" it shows some errors. should i resolve these now, or do all the other commands first? [00:35] hmm. It did not show errors for me [00:35] * maxb rechecks [00:37] oh, conflicts, not errors [00:37] The next command "bzr revert ." will get rid of them [00:37] maxb: yea, conflicts [00:37] http://paste.ubuntu.com/560793/ [00:37] oh, ok [00:42] maxb: thx it works like expected [00:53] np [05:31] lifeless, did you already reset loggerhead trunk to 1.18? [05:31] no [05:31] was waiting on the 2a update to pthe pqm branch [05:32] which happened just recently [05:32] i couldn't sensibly push/compare etc before then [07:41] hi all ! [07:45] * fullermd flops at vila. [07:46] ;) [07:51] hi there vila, fullermd [07:51] hey poolie ! [08:03] vila, i should stop for the day i guess [08:03] how are things with you? [08:04] poolie: fine, setting up a local package importer, going through the hidden dependencies, should be usable today (with its associated ppa) [08:04] ah, good [08:04] it's already in a ppa, or you're going to make one? [08:04] i looked a bit at https://bugs.launchpad.net/loggerhead/+bug/701329 [08:05] and we learned a bit, though not yet what the final answer is [08:05] I just created a new one to stop misusing my own (still private to me so far but allowing to track the precise versions) [08:06] vila, actually can you give me a quick call at home? [08:06] sure [08:07] gha, phone battery empty, just a sec [08:08] Battery? But, phones get all their power from the 4 little copper wires going into them... [08:35] fullermd: 4 ? We do fine with 2 around here... :D [08:35] damn, totally missed this one, 2 for power and 2 for line which is why it failed >-) [08:40] Well, OK, only 2 technically needed for single-line basic working. But I don't remember the last time I saw a 2-conductor cable going into 6P2C connectors, so... [08:46] connectors... we still have old phone plugs with 8 wires here (but rj11 is 6 right ?) [08:48] 6P4C as a rule. [08:49] Though now that I double check, my desk phone actually has an integral cable that's 6P2C. Cheap bastiches. [08:52] can't you just settle on international standards for once... :-P [08:53] Hey, we adopted International Morse over American. What more do you want? :p [08:53] metric system ? [08:54] I tried drinking 473 cc's of beer once. Didn't taste near as good as a pint. [08:56] Oh I don't mind pints, but mphs are a booby-trap, I keep trying to jump out of cabs at 30... [08:58] You just gotta roll. [09:25] hi, I am confused a bit. [09:25] I have a bzr tree, let's call it /tree1 [09:25] I also have another tree /somewhere/tree2 [09:26] I want to reach /somewhere/tree2/tree1 [09:26] when all history from tree2 and tree2 are preserved. [09:26] how do I translate this into bzr operations ? [09:26] is it possible ? what possible problems may occur ? [09:27] cd /somewhere/tree1 ; bzr branch /tree1 ; bzr join tree1 ; bzr commit [09:27] That's basically equivalent to cd /somewhere/tree2 ; bzr merge -r0..-1 /tree1 ; [move all files into tree1/ subdir] ; bzr ci [09:28] fullermd: you've confused tree1 and tree2. [09:28] (not exactly, but conceptually it gets you in the right territory) [09:28] fullermd: I understood yer 1st remark. [09:29] I got lost on the 2nd. [09:29] if I am merging tree2 into an empty tree1 ... what am I achieving ? [09:30] I mean you suggest to create a copy of the tree /somewhere/tree2, in /somewhere/tree2/tree1 ? [09:30] Mmm. If I'm backward on tree1 and tree2, I don't understand what you're saying... it certainly sounds like you're wanting to put tree1 (and all its history) in a subdir of tree2. [09:30] true. [09:31] Then... oh, I typo'd "/somewhere/tree1" for tree2 right at the start there. [09:31] * fullermd blames vila. [09:31] let's make is easier in naming: /1 is a tree. /d/2 is a tree. I want to have: /d/2/1/ [09:31] fullermd: what is vila. [09:32] An evil spirit that inhabits #bzr and screws with my typing. [09:32] well, for my defense, I'd point out that sobersabre also confused 1 and 2 in: " when all history from tree2 and tree2 are preserved." :-D [09:32] vila: true :) [09:32] so, if I translate it: [09:32] It's in your defense that you're screwing with HIS typing as well as mine? :p [09:33] well, let say I'm quite generous and love to share my tyops [09:33] cd /somewhere/tree2 ; bzr branch /tree1; bzr join tree1; bzr ci -m "join-a-tree" [09:34] vila: I've never seen your tyop. can you share ? [09:34] Yes. 'join' is roughly equivalent to 'merge' into a subdir. [09:36] sobersabre: you're new here right ? Just you wait and you'll see my tyops soon enough ;) [09:36] So you wind up with a merge commit, with the whole history of tree1 off on the RHS. Except that from tree2's perspective, it all happens inside '$ROOT/tree1' instead of '$ROOT' [09:37] hm. [09:37] I did an experiment. [09:37] I WANT the history of tree1 [09:39] so I rephrase: I have /path/tree1, /path/tree2. I want to have /path/tree2/tree1 so that now have both files from /path/tree1 in /path/tree2/tree1, AND the history of /path/tree1 is inside the history of /path/tree2 (if I run bzr log) [09:39] Yes, that's why you're join'ing. [09:40] oh, I see. [09:40] If I run bzr log -n0, THEN I see merged stuff. [09:40] cool [09:40] very nice. [09:41] sobersabre: give a try to 'bzr qlog' from the qbzr plugin too [09:42] * fullermd always wonders if he should pronounce that "cube-zor"... [09:46] fullermd: call it 'cuby' [09:47] q b [09:47] cude-zor sounds right, but then, I'm not a native speaker so me and accents... [09:48] It brings to mind many long hours wasted playing Q*bert. [10:00] maxb: hi [10:00] maxb: what does that recent MP change exactly? [10:05] jelmer: You asked for some added docstrings [10:06] Oh, wait. bzr MP or bzr-svn MP ? [10:09] maxb: bzr-svn mp [10:09] maxb: I don't see any new docstrings in the MP email [10:10] hmm. I pushed... I thought. Let me check [10:11] They're on LP [10:12] but for some reason it's not representing my additional pushed revision in-line in the comment flow of the MP [10:14] maxb: there is probably a bug around that, I notice it randomly [10:27] maxb: got it now, thanks [10:27] vila: There have been some bugs related to file id rewriting in working trees after dpush recently [10:28] vila: it uses tree transform, which is still a bit obscure to me. I was wondering if you could have a look to double-check I'm using the API correctly? [10:29] jelmer: urgh, yeah, I can try, but I've been notoriously bad at that myself (though I learned a few tricks in the process) [10:29] jelmer: where should I look ? [10:30] vila: bzrlib/foreign.py, function update_workingtree_fileids() [10:30] in trunk ? [10:30] yep [10:30] though it hasn't changed since 2.1 I believe [10:32] jelmer: Oh, btw, i have an Approved dulwich MP, is that just wsiting for next time you do work on dulwich, or do you need amything more from me there? [10:34] maxb: I'll have a look [10:34] * jelmer wished there was a good way to see all the MPs he was involved with [10:34] maxb: that's already been merged [10:35] huh [10:35] silly lp, then [10:36] I'm really surprised LP doesn't have that [10:36] jelmer: so, f, p, c, v, d, n, k, e is a bit obscure :) But more seriously, the doc string says update the file-ids, but I don't see how you acquire the file-ids from the other tree, [10:36] maxb: the revision was dpushed, so it can't use the revision id to see when the MP was merged [10:36] ah [10:37] * jelmer should put some more time into proper roundtripping support in bzr-git [10:38] jelmer: oh, 'f' is the file-id, so target_tree.iter_changes() should provide them [10:38] vila: Aaron wrote that code originally, and it's worked fine before [10:38] vila: I'm not entirely sure how then :) [10:38] vila: ah :) [10:39] btw in the dulwich case I filed a bug on, some revision ids hadn't been dpushed either [10:39] jelmer: so, this code looks correct to me, but often with tt, combining multiple operations is where the problems start, do you have a specific one problem with this code ? Or when it's used in conjunction with some other operations ? [10:40] jelmer: the tt seems to be local to the function though [10:40] yeah, it's all in this function [10:40] vila: bug 707761 [10:41] Launchpad bug 707761 in Bazaar "'versioning no contents' tree transform error during dpush" [High,Triaged] https://launchpad.net/bugs/707761 [10:41] haaa [10:44] jelmer: right, so based on tt.new_file(), you probably need a tt.create_file(contents, trans_id) in *some* cases [10:44] emphasis on some, hilarity ensues [10:46] jelmer: "some" may be when the newly versioned file doesn't exist under the right? path in wt [10:46] ? [10:47] ah, hmm [10:47] jelmer: you will need more tests for update_workingtree_fileids() it seems :-/ [10:47] vila: thanks [10:47] jelmer: sounds likely ? [10:48] vila: yeah, somewhat [10:48] ok [10:50] is there a bzr equivalent of svn:externals? If I check out one bzr repository, it automatically checks out another? [10:50] pfarrell: not in the core (yet). there are some plugins that provide similar functionality, such as bzr-externals [10:51] jelmer: oh, right, thanks. [10:55] hmm, http://launchpadlibrarian.net/63287267/buildlog_ubuntu-hardy-lpia.pristine-tar_1.11ubuntu1~pkgimport1_MANUALDEPWAIT.txt.gz [10:55] fails on debhelper(inst 6.0.4ubuntu1 ! >= wanted 7.0.50) [10:56] I suspect I'm running into an issue known by maxb... Is https://launchpad.net/~bzr/+archive/builddeps part of the asnwer ? [10:56] answer [10:56] except the later includes only debhelper-7.0.13 [10:56] vila: is there any reason you actually need debhelper 7.0.50 ? [10:57] as opposed to an older version, I mean [10:57] jelmer: no idea, this is required by pristine-tar, do you suggest I should try to lower the requirement and see ? [11:04] jelmer: hardy has debhelper 6.0.4, -backports has 7.0.13 as does bzr-builddeps, so lowering to 7.0.13 and add bzr-builddeps as a ppa dependency ? [11:06] vila: most dh7 stuff does actually require 7.0.50 [11:07] look for override_* targets in rules [11:07] they are the most common reason [11:08] maxb: two occurrences for pristine-tar: override_dh_auto_configure and override_dh_auto_clean [11:08] right, so you do need a later debhelper than backports provides [11:09] maxb: can debhelper be upgraded >= 7.0.50 in https://launchpad.net/~bzr/+archive/builddeps ? [11:09] maxb: I'm pretty sure I'll have to add it as as dependency to https://launchpad.net/~vila/+archive/pkgimport anyway === wgrant_ is now known as wgrant [11:10] ah so we've stopped trying to sru pristine-tar for jubany? [11:11] maxb: that's different, I'm trying to setup a local package importer and doing so track what is needed [11:11] maxb: I thought prisitine-tar has been upgraded on jubany anyway, I didn't know about an sru for it... [11:12] you can find a suitable debhelper in mercurial-ppa/builddeps [11:15] maxb: could you copy it to bzr.builddeps ? [11:15] maxb: could you copy it to bzr/builddeps ? [11:15] maxb: or will it break everything there ? [11:17] I think it should be pretty safe [11:17] The only reason I did not before was that I did not have a need [11:18] * maxb blinks at bzr-package-importer being a package [11:18] Doesn't it just run from the branch in production? [11:18] maxb: blame me [11:19] maxb: I'm creating it right now to track what is ~used in production [11:19] maxb: it is *not* used by jubany [11:20] ok [11:21] Well, I don't have any specific objections to copying debhelper 7.0.52 to bzr/builddeps - except that there's been no requirement for it for anything built in the ~bzr PPA so far. Perhaps you could just copy it to vila/pkgimport directly? [11:22] maxb: yup. I was going to do exactly that [11:22] Although, wouldn't your project be easier, and more representative of production, if you based on lucid? [11:22] maxb: well, jubany is hardy right now... [11:22] *blink* [11:23] I am confused. Or perhaps I misunderstood. I thought the whole point of considering SRUing pristine-tar to lucid was to get it to jubany [11:23] I don't think there is any intent to do a SRU? [11:23] meh, no idea, as I said, I'm not aware of the SRU, any pointer ? [11:26] Somewhere there was a mention by (I think) james_w that we should do a backport. I filed a backport request bug, which got declined on the basis that it should be a SRU instead [11:27] oh, it's in an import failure bug [11:27] * maxb looks [11:27] maxb: jubany currently uses 1.11ubuntu1~0.IS.8.04 [11:28] maxb: are you sure that's for the package importer? [11:28] Oh. That's recent, then [11:28] maxb: yes, less than 24h [11:28] Evidently someone got tired of waiting and did an IS backport instead [11:28] maxb: jam will know the details [11:28] bug 695108 [11:28] Launchpad bug 695108 in lucid-backports "Backport pristine-tar 1.11ubuntu1" [Undecided,New] https://launchpad.net/bugs/695108 [11:29] bug 653301 [11:29] Launchpad bug 653301 in Ubuntu Distributed Development "Packages failing due to pristine-tar not being able to reconstruct their tarball" [High,Triaged] https://launchpad.net/bugs/653301 [11:29] maxb: right, so s/24/13/ [11:29] maxb: right, so s/24h/13h/ [11:35] ah, so it affects general bzr-builddeb as well [11:36] as a related note, should add bzr-builddeb to the bzr ppa(s?) ? [11:36] s/add/we add/ [11:36] yeah, probably [11:38] *blinks* [11:38] It *is* in bzr/ppa but for jaunty/karmic/lucid only... [11:59] vila: That typically means that maverick+ is already at the latest upstream release [11:59] it's about time we do another bzr-builddeb release [12:00] maxb: of course, silly me ! Thanks [12:00] Oh, and it's not there for hardy because we're have to backport python-debian, and it didn't seem worthwhile [12:02] maxb: very good exercise for me :) [12:02] meh, hardy is ancient [12:03] I wonder when PPAs are discontinue support for Jaunty [12:03] ^ going to [12:04] maxb: but that's what jubany uses *today*, on the other hand may be I should check what is the target for migrating jubany (probably lucid) and just works from there... [12:04] What does the importer need builddeb for? [12:08] maxb: it uses a bunch of the tarball importing code from bzr-builddeb [12:08] ah [12:08] oh, duh, I should have remembered that === oubiwann is now known as oubiwann_ [12:14] ok, confirmed, so I'll target lucid instead and see how it goes [12:19] hi all! I'm evaluating how to best use bzr for revision control at my company. We have a medium sized Visual Studio Project that depends on a few binary files, which seldom change. Is there a way to just copy the files on branch/merge (direction depending on timestamp) commands , without having them version controlled ? Thanks! === oubiwann_ is now known as oubiwann [12:34] hi deepestthought42 [12:34] deepestthought42: from my research, no current dvcs has "good" handling of large, versioned binary files [12:40] spiv: are you *sure* 2.1.1 is not relevant when bug #522637 has been fixed in 2.1.3 ? [12:40] Launchpad bug 522637 in Bazaar 2.0 "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Fix released] https://launchpad.net/bugs/522637 [13:05] mwahaha, bzr-builddeb package imported failed leading to out-of-date branches on lp which I use to create my own [13:05] hehe [13:10] I feared as much , but thanks anyway. We'll probably end up putting them under vc. [13:11] deepestthought42: what do you call large (# and size of the largest) ? [13:19] vila: I do not think I said how large they are ;) but the complete build folder has about 350 MB (Debug, release builds etc.) -- the real "problem" is that changed binaries crop up in the status/diff/merge and they probably slow the system down (not sure on that), [13:21] oh right, sry, but why don't you *ignore* the binaries (via 'bzr ignore') i.e. don't version them and they won't appear in status/diff/merge [13:23] not all of them need to be build (and can be by all developers) every time but need to be present.; so a copy would suffice for them; we probably will have a folder for the stable binaries and version them and ignore the unstable ones [13:26] ha... Well, your call, but mixing production and version control has known deficiencies, keep in mind that bzr will change the timestamps of the files it modify so rebuilding an old version should only rebuild the files related to the modified files [13:27] In practive, devs will have to build the whole project once and then rebuild only the needed parts, even when working on old versions [13:42] vila: you're right, this solution is not without problems -- but when completely ignoring the binaries, we would have to copy them by hand on every branch etc. [13:44] deepestthought42: you want to try 'bzr switch' then so you can reuse the same working tree for several branches [13:45] deepestthought42: but you're the judge, just mentioning some different ways to address the issue [14:02] vila: i know and thank you for your help :) === oubiwann is now known as oubiwann_ [14:37] Could someone give me good guide on howto set up a bazaar server over http on linux? [14:45] fenrig: do you mean "just access a branch over HTTP" or the magic bzr+http integration? [14:46] AfC: uhm bzr+http is where bzr doesn't get whole files but just the diff lines? [14:46] no [14:48] :o uhm okay [14:48] fenrig: bzr always does that (sic) regardless. [14:48] fenrig: ie, it Does The Right Thing™ as it should. You rarely need to second guess it. [14:49] fenrig: have you got SSH access to the web server in question? [14:49] AfC: ow okay I compare GIT a lot with BZR. [14:49] AfC: I have yes :) [14:49] fenrig: if so, just push your branch there via bzr+ssh:// [14:49] fenrig: and then you can just point people at http://... [14:50] [there's also a sftp:// for pushing if you can't install Bazaar on the server] [14:50] but then http acts like a read only branch? [14:52] AfC: Do u guys have a super good guide, so I can try it out on a VM? [14:53] fenrig: yes [14:54] AfC: :p could you please give it to me :D [14:55] I said yes to "read only" [14:56] maxb, vila: you rang? [14:56] Maybe someone else could lend this person a hand? Rumour has it Bazaar has good documentation, but apparently they haven't been able to find it :( === AfC is now known as AfC|zzz [14:56] jam: morning jam, maybe, long ago, let me check :) [14:56] jam: There was a discussion about pristine-tar for jubany, but I think we got everything clarified in the end. [14:56] ha, yeah, pristin... what maxb says :) [14:56] maxb: lamont was kind enough to backport the natty pristine-tar and install it on jubany [14:56] it didn't fix everything, but it fixed a lot of them [14:57] fenrig: Please clarify: you want to do write-access to branches over http? You want to browse branches like you see at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev ? [14:58] maxb: no with loggerhead is fine :) but then I need to have ssh+bzr to commit changes? [14:58] fenrig: there is nothing to configure for bzr+ssh except for the ssh access [14:59] vila: looks like it went from ~92 to 14 failing packages [14:59] fenrig: Many people prefer bzr+ssh for commit because a ssh-agent is often a more convenient way to cache your authentication safely than a password [14:59] fenrig: not even a vm, you can try with bzr+ssh://localhost [14:59] jam: yup, well done, I didn't look closely but had a ~60 rough estimate [15:00] :D okay maybe someone could point me to a good guide on how I have to do this (and please don't give a ubuntu specific cause I use arch linux) [15:01] fenrig: just try: 'bzr push bzr+ssh://localhost/~/a-new-shiny-one' [15:01] vila: I mean how to setup a server :p [15:01] fenrig: I meant: just try [15:02] fenrig: there is no server to set up ! [15:02] If you have a running sshd, and bzr installed, that's all you need. [15:02] Does anyone fancy dispatching https://code.launchpad.net/~maxb/bzr/ppa-doc-update-2/+merge/48101 to PQM? (it's already approved) [15:03] so let us say :) just to understand i do :o [15:03] bzr push bzr+ssh://root:localhost/~/a-new-shiny-one [15:03] maxb: done [15:03] thanks [15:03] where does the folder goes to? [15:03] in /root/a-new-shiny-one? [15:03] root:locahost ? You mean root@localhost ? [15:04] vila: yeah sorry XD [15:04] fenrig: hmm, don't use root for that, just try with your regular user [15:04] yeah I know using root bad idea, but it's for understanding the semantics :o where does the repo folder go to? [15:05] ~ is replaced with the user home directory yes [15:06] jelmer is launching a DoS on my inbox... [15:06] fenrig: the *branch* is created there, creating a new repository or re-using an existing one (you may want to read http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief) [15:06] mgz: hey ! [15:06] vila: so i could find all the source code files in "/root/a-new-shiny-one"? [15:06] mgz: yeah, it's a new kind of Ddos: single attacker, multiple targets :) [15:07] :) [15:07] fenrig: no, you won't find the working tree, only the history (branch [+ repository]) [15:08] maybe I should blame launchpad instead, does it really need to send me email for tag changes. [15:08] vila: how do you mean (your url says: "page does not exist,...") [15:08] fenrig: most of the time working trees are useless on servers, if you need a working tree there, look for the bzr-push-and-update or bzr-upload plugins depending on your use case [15:08] fenrig: try again, I copied the URL from my browser [15:09] vila: there was a ")" behind it sorry xD [15:10] argh, sry for that [15:13] vila: don't mind it :D [15:17] bzr is easier to setup than git isn't it? [15:20] yes [15:20] mostly [15:20] and easier to work with mostly === beuno is now known as beuno-lunch [16:08] cbz: the "bzr whoami" command gives you a name on your client :) so If I and my friend use diff whoami's but we use the same ssh user there should still be a difference in bzr? [16:16] fenrig: whoami is used at commit times, not at push time [16:17] :o so the diff will we marked with the whoami? [16:17] fenrig: yes, whoami set the committer [16:24] I'm following thui [16:25] *this guide: and he creates a user like this => useradd --create-home --home-dir /var/local/bzr --shell /usr/lib/sftp-server bzr (on ubuntu) [16:25] why is he setting the home-dir to be /var/local/bzr? [16:25] http://wiki.flexion.org/BazaarServer.html [16:26] fenrig: no idea, but given he mentioned hardy and doesn't use the smart server, I'll forget about it [16:27] vila: :o where do I have to find a proper guide then? [16:27] fenrig: you can use bzr over sftp, but you don't have to. [16:28] nowhere [16:28] there is no guide to setup an ssh smart server because there is no setup [16:28] as maxb said earlier: install sshd and bzr and you're done [16:28] yeah okay :o [16:29] but I want to make one bzr ssh user for this :o [16:29] from there it's only ssh config, nothing specific to bzr (at least to start with) [16:29] called (tadam) bzr [16:29] jfdi [16:29] it's not a bad idea as you will be able to set its .ssh/authorized_keys to control who can push there === Meths_ is now known as Meths [16:48] when doing "bzr push bzr+ssh://bzr@192.168.56.101/~/a-new-shiny-thingy-one" [16:49] gives me a : "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if ..." [16:49] but loggin in with [16:49] ssh bzr@192.168.56.101 works perfectly :o [16:49] fenrig: try 'ssh -vv bzr@192.168.56.101' to debug ssh issues [16:50] ha, hmm [16:53] vila: ssh -vv bzr@192.168.56.101 works :o logging in and all :o [16:54] vila: but I'm using a modified "shell" => /usr/lib/ssh/sftp-server [16:55] don't do that then [16:55] bzr will send the right ssh command, you're getting in its way here [16:55] vila: what's the command to change the shell of a user XD [16:56] how did you modify the shell ? [16:56] u configured it using adduser [16:56] *I [16:56] (sorry) [16:57] by following the guide I told you was wrong ? :D [16:58] I only followed it on the adding bzr user :$ [16:58] dunno the specific command on your os, *I*'d modify it by editing /etc/passwd [16:58] or you can delete the user and re-create it or create another one [16:59] vila: change it to /bin/bash? [16:59] whatever is the default on your system === beuno-lunch is now known as beuno [17:08] vila, fenrig: the command is often just "chsh" for change shell [17:08] You often can run chsh without needing root [17:08] jelmer: are you retagging all of the bugs? [17:09] jml: I'm tagging the ones that haven't been tagged yet and closing/duping where possible [17:09] jelmer: ahh, ok. [17:10] jml: Sorry about the mail. I'm sure you get plenty already ;) [17:10] . o O (Yeah, that's the idea, bounce them all to jml !) [17:11] jelmer: no worries. it's just an unusually high number today [17:12] vila: at least he's somebody who can make sure that launchpad bug notifications get fixed :) [17:13] jelmer: you get the idea ;) [17:13] james_w: ping [17:13] hi vila [17:14] james_w: hey ! wow, that was fast ;) [17:14] I've been sitting here all day waiting for your ping [17:14] I've set up a local package importer (with --no-push), and I'm trying to add some packages to it [17:14] :) [17:15] I tried add_import_jobs.py but it timeouts [17:15] times out doing what? [17:15] so my question is: is there another way to add a package (a single one to start with :) [17:15] ./requeue_package.py should do it [17:16] it says package has not failed, oh, --force ? [17:16] yeah [17:16] yeah ! [17:16] james_w: thanks, I'm unblocked [17:17] how can I branch a project in launchpad on system that doesn't have any access to bazaar.launchpad.net? if I can access the system by ssh, can I push a local branch to the system in a way that can be merge on the same remote system later? [17:17] cool [17:21] cr3: if you have an ssh access to a system that have an ssh access to b.l.n, why not set up an ssh tunnel ? [17:22] vila: I did that once, I was hoping for another solution :) [17:23] vila: changing shell worked :D [17:23] cr3: hehe :) [17:23] fenrig: finally ! [17:23] cr3: so, anyway, as long as you do the merge on 'system' you can still push there from wherever works for you [17:25] cr3: you don't need a working tree in the branch you're pushing to as long as you have one where you merge this branch [17:25] s/you don't need/don't use/ [17:32] ssh -g -R 50022:bazaar.launchpad.net:22 system; bzr branch bzr+ssh://localhost:50022/... [17:47] james_w: add_imports_jobs.py is the canonical way to bootstrap the importer or something else ? [17:47]