[00:08] is it possible to merge into a branch if there already is an ongoing merge? [00:09] I believe it is these days, it's certainly possible for there to be more than two parents. [00:09] not actually tried it recently though. [00:09] GungaDin: bzr merge --force [00:11] If I recall correctly - Bzr has been able to do that from pre 0.17 days - if not the beginning [00:11] they're not really done from the same machine. [00:11] ha, clearly I didn't try hard enough last time then. [00:12] thanks Gary. [00:12] GungaDin: then I think I we miss understand you - Could you try describe in more detail what you are wanting to do? [00:13] there's a branch stored in a shared on machine S. there are 2 checkouts of it on machine A & B. both users on A & B want to merge something into this branch. [00:14] GungaDin: Yes - person A commits - cause it's a check out it gets pushed to the master branch. [00:15] One should merge and commit. The other should then update, merge and commit [00:15] then person b ties to commit - It wont let him/her because of person a's commit [00:16] so b must update before he commits [00:16] and the update will merge a's changes with b's changes [00:16] I'm talking about the situation before anyone commits. [00:17] one has started a merge... can the other one start his now? [00:17] GungaDin: merges don't happen in branches, they happen in working copies. [00:17] or is that branch locked until the commit of the first one? [00:18] There is no locking, but if they both start simultaneously, one will have to update before committing, and may have to resolve conflicts as a result [00:19] hi guys [00:19] i'm going to be at uds next week so i'll be offline a bit [00:19] and i have been busy a bit this week getting ready [00:21] GungaDin: a merge is basically just another kind of uncommitted edit you can make to a checkout, like modifying or adding files. [00:21] GungaDin: and the branch isn't affected by uncommitted changes until they are committed. [00:24] mgz: see revno 4825.1.1 in bzr.dev [00:25] ...appears to be doc fixes from nmb? [00:25] mgz: hint - count the parents :-) [00:27] ah, I see what you mean. [00:29] I had a script to find octopus merges, but I've lost it. There are others... [00:32] * KombuchaKip is very much enjoying the soundtrack to The Fountain by Kronos Quartet. Every time he sees their name on a soundtrack, he's confident it will be stellar. [01:55] hi there spiv [02:13] Hey [02:21] sorry i haven't piloted much [02:21] having one of those about-to-go-away weeks [02:21] the lp-dev review thread is interesting, isn't it [02:21] it reminds me how much easier things seem to flow for us compared to a few years ago [02:22] Yeah, definitely [02:23] It's partly also that they have such a large team, so naturally there's a little more divergence in understanding of the norms and rationales for reviewing. [02:23] Such a large review team, that is. [02:24] We actually have a pretty large set of people generating merge proposals, really :) [02:29] mm === Ursinha is now known as Ursinha-afk [02:40] i think launchpad and bazaar are really quite different projects [02:40] in ways that i can't quite put my finger on [02:56] probably [02:57] hm, gmail seems to be down? [02:57] not for me [02:57] but then the way that sort of thing works, partial outage is hardly surprising [02:59] On another channel I'm on someone else had gmail be down just for them for a while this morning. [02:59] Or more facetiously, http://downforeveryoneorjustme.com/gmail.com [02:59] hm, maybe this is a good chance to get something done :) [03:00] Hah [03:08] hm the docs are indeed broken by danilo [03:09] by his name occurring in a tex document [03:09] spiv what did you change there? [03:10] Nothing much I would have thought... [03:10] Where does his name occur? In release-notes? [03:12] in bzr-en-release-notes [03:14] I didn't look at the tex generation at all [03:14] I believe that's done by sphinx? So in theory nothing significant has changed there... [03:16] Yeah, nothing obvious... will look again after lunch if you're still having trouble. [03:22] i can reproduce it locally [03:22] and yes, it does seem to be produced by sphinx [03:27] whats the bzr of eqivalent of gitosis and gitolite [03:27] I think that's Sphinx issue 432, fixed 5 months ago in http://bitbucket.org/birkenfield/sphinx/changeset/28e9f10c1f34 [03:27] gilaniali: what do those do? [03:28] dash: they help in managing a gitserver by providing an easy way to add user users, manage group permissions and such [03:29] gilaniali: i believe there is a fork of gitosis that runs bzr, bzrosis or something [03:29] jbowtie: i don't think it is that issue ,but thanks [03:31] poolie: sorry, correct URL is http://bitbucket.org/birkenfeld/sphinx/changeset/28e9f10c1f34 [03:32] mm, i found it, but that's not the error i'm getting [03:32] i'll file a bug [03:37] Hm, Maverick still has 0.6.6, bug was fixed in 0.6.7 but it could be down to latex version being used I suppose. [03:51] https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/39115 skirts around it [03:51] jbowtie: but the one i get is an error during pdflatex, not while producing the tex [03:52] i suspect the bug if anywhere is in their tex templates but i really don't want to dig into that now [04:01] Oh, that might be the moving arguments bug in pdflatex. I'll have a closer look over the weekend when I push my documentation bug fixes. [04:01] great [04:02] do you want to rubberstamp in the interim? [04:02] i'd be happy to leave the bug open [04:46] poolie: Yes, just did so. [04:46] thanks [04:47] Hmm...apparently I'm 'community'. Is that a new launchpad feature? [04:48] i think it means you're not in the team of reviewers for the target branch? [04:49] Maybe. I just requested bzr-core membership. Already in bzr-qa and bzr-doc [04:51] I would have thought that would have been within the purview of bzr-doc anyhow. [04:51] mm [04:51] bzr-core is just the default reviewer and i didn't change it [04:51] it's totally fine as it is [05:00] Is bug 388249 still an issue? [05:00] Launchpad bug 388249 in Bazaar "2a format doesn't support Revision.message = None (affected: 1, heat: 8)" [High,Confirmed] https://launchpad.net/bugs/388249 [05:01] poolie: bzr-core is not merely the default reviewer, it is the designated review team for that branch. Anyone doing a review for that branch who's not a member of that team is "(community)". [05:33] poolie: http://bzr.bz/ [05:39] wow [05:39] nice domain [05:40] Ooh, some excellent lightning and thunder where I am atm. [05:42] "It's not launchpad.net"? [05:43] mm me too [05:43] apparently not === MTecknology is now known as AFWEG43y6t23yt2t === AFWEG43y6t23yt2t is now known as MTecknology [06:38] lifeless: what an interesting thing that is [06:39] indeed [06:48] i can understand the sentiment slightly [06:49] it'd be very nice to get something simpler to play with than launchpad for hosting bzr projects [06:49] having said that... i wouldn't trust that place from teh looks of it with my code ;) [07:11] i think it's nice to have an alternative that is seems to be taking a very kind of dry approach [07:11] in fact it's good to have alternatives full stop [07:21] has anyone else tested bzr from maverick-proposed? [07:28] Hmm, I have the bzr from bzr-beta-ppa, haven't tried maverick-proposed. [07:29] do you have maverick ? [07:29] 'you' should talk to marjo about getting testers [08:09] hi all [08:10] that would be good [08:10] lifeless: what do you mean? [08:10] the ubuntu qa folk are discussing how to attract testers at themoment [08:10] mainly for iso testing I think [08:10] ok, maybe i'll see him next week [08:10] but SRU is pretty important, I would be surprised if they aren't thinking about it [08:12] spiv, can you downgrade and test that, and then comment on the bug? or vila? [08:13] hmm... I've got so many different configurations flying around that the main problem will be to find the right one where I can be sure to test the right bzr 8-) [08:14] poolie: on the other hand, I've *already* tested it one way or the other... [08:14] vila actually if we have room to spare, an infrequent babune job that checks bzr selftest from maverick-proposed, and other things where it should be green, would be good [08:15] i should add babune to my 'poll' bookmarks [08:15] i wonder too if we can separate them into 'should be green' and 'not yet'? [08:15] or maybe you already did? [08:15] poolie: you know there are news feeds there [08:15] mm, i don't really believe in rss though [08:16] poolie: toying around with ppas or other things requiring root access is outside babune capacities so far (and will remain for the foreseeable future) [08:16] even in a vm? [08:16] poolie: the focus is on running from branches, not toying with system setups [08:17] another maverick vm then or may be I should instead look into *not* running from source [08:17] I haven't looked from this angle yet [08:18] on the whole i would say source is a higher prioirity [08:18] (hi vila :) ) [08:18] babune slaves requires an available bzr, whatever it is, just a running one [08:18] since we can change it much faster [08:18] peitschie: hey :) [08:18] poolie: +1 [08:19] vila i see for instance http://babune.ladeuil.net:24842/job/selftest-jaunty/321/ failed [08:19] with a subunit 'connection broken' message [08:19] which is not much of a message at all [08:19] what does that mean? [08:19] poolie: now, it's conceivable to run an hudson job without tying it to a bzr branch and look into configuring the vms with -proposed [08:19] poolie: shudder [08:19] poolie: replied to your bug 653307 comment: I think we are closer to a diagnosis now [08:19] Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys (affected: 1, heat: 7)" [Critical,In progress] https://launchpad.net/bugs/653307 [08:19] right, just do it every day or every few days [08:20] oh good [08:20] poolie: you don't like rss? [08:20] poolie: unfortunately, it involves the word "stacking" :( [08:20] lifeless: i just tend to find i don't want to read a whole bunch of news mashed together [08:20] that's the remaining pain point with subunit/testtools/hudson: random failures, not reproducible at will, unknown cause [08:20] i check different things at different intervals [08:20] poolie: I do quite like google reader [08:21] i know [08:21] poolie: best guesses includes: hangs or.... whatever can make a selftest subprocess die... no traces, go figure [08:21] lifeless: this is one of my grumbles about subunit; it tends to fail opaquely in practice [08:21] poolie: :( [08:21] vila i wonder if it crashed in C, or ran out of memory, or something like that [08:21] very good in other ways mind you, and i'm sure this is tractable [08:22] vila is it possible to see the raw streams? [08:22] poolie: for a while I just hit delete and re-run, now I keep them but still re-run [08:23] poolie: could be, but it hasn't reach the top of my TODO list yet (and I suspect it won't for quite some time ;) [08:23] just wondering [08:23] poolie: my gut feeling is more around timing issues than OOM or crashes [08:24] poolie: could also be virtualbox related [08:24] in some cases if unexpected output gets into the noise subunit will disconnect [08:24] that too [08:25] there are a couple or network bugs randomly occurring here and there even at boot time for karmic/lucid/maverick where the eth0 interface is not properly configured/initialized including avahi failing or dhcp or goat or chicken [08:26] and sometimes the network connection is lost or the autofs fail or... [08:26] you know, the kind of bug that disappear as soon as you try to look at them ? [08:26] just like them [08:27] anyway, to come back to the initial question: I don't feel qualify to test '-proposed', there are too many reasons that my tests won't be representative [08:28] imbw [08:28] by the way, natty is not yet installable right ? [08:29] I mean, with a reasonable effort [08:29] like: download a bootable iso or tweak an apt sources files on a maverick vm :) [08:31] hmm, so looking a bit at my vm configs: the idea is to test whatever is packaged by the distro, except for ubuntus where I add the stable ppa [08:32] and this rule is not fully enforced for windows and osx (but well, I'm just adding osx to the mix) [08:32] this is partly due to hudson requiring a system-wide available bzr to bootstrap the jobs [08:33] so I'm not super keen on introducing possible failures there... and setting up alternative install of bzr kind of defeat the purpose of testing -proposed, so this will require different vms... [08:35] said otherwise: there are ways to inject -proposed in babune but any failure there will induce significant fallouts [08:35] which may be a good thing... or not at all [08:37] ok [08:37] well, maybe we should wait for the existing ones to stabilize more [08:38] what do you mean ? [08:38] Ok, I should finish work for the day. Happy weekend (and happy travelling if appropriate)! [08:38] to get all the existing jobs continuously green [08:38] Hey, hey, I'm in bzr-core! I feel happy! [08:39] thanks spiv, have a good weekend, thanks for the updates on the bugs [08:39] keep status-ing :) [08:39] congrats! [08:39] poolie: ha right, yes, that why I just added osx now that windows is close to green [08:40] vila, so i think the thing to do is: boot a vm that's configured to use maverick-proposed; aptitude upgrade; run bzr selftest; see what happens [08:40] poolie: I had a hudson plugin that was re-running some failures automatically but it stopped working, I didn't find the time to disagnose that one [08:40] i don't know how hard this is to put into hudson but it's only a few shell commands so it seems it shouldn't be all that hard [08:41] oh, *that* shouldn't be hard, right, but that's indeed adding other vm [08:42] poolie: But I did this test manually... can't remember when [08:42] they're pretty cheap though [08:42] at least if they can be shut down when they're not actually running [08:42] which test? [08:43] running selftest from a ppa installed bzr [08:43] you make me doubt now... [08:44] ha no, -proposed not a ppa, meh [08:47] ah, you've tested 2.2.1 that way? [08:47] then you should say so on the bug... [08:51] poolie: no, I did test from the stable ppa not from the -proposed pocket [08:52] poolie: sry for the confusion [08:53] poolie: meh, bug you already did the test yourself if I read bug 636930 correctly right ? [08:53] Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 10, heat: 92)" [High,Triaged] https://launchpad.net/bugs/636930 [08:54] oh, you want one more verification [08:58] right [08:59] why didn't you start with that ? :-p [09:00] sorry :) [09:00] hehe, kidding [09:06] hrm [09:06] today's maverick package update just failed because of bzr whoami [09:06] which would presumably be because I have etckeeper installed [09:06] have we managed to yet convince people that requiring identity to commit is bad, harmful and wrong? [09:07] Ng: To fix I did : [09:07] sudo -i [09:07] poolie: grumble, subunit/testtools bugs, can't run -proposed on hudson [09:07] Ng: have we managed to yet get etckeepr to take care of setting one for you? ;) [09:07] bzr whoami "Root " [09:08] spiv: my laptop having a failed apt transaction suggests not [09:08] Which is a work around... [09:08] and you question answers mine that we continue to fail :( [09:09] please change bzr's behaviour, this is madness [09:10] Ng: Is that not bug #616878 ? [09:10] Launchpad bug 616878 in Bazaar "bzr commit error because of no identity (affected: 3, heat: 60)" [Medium,Confirmed] https://launchpad.net/bugs/616878 [09:10] jpds: it very likely is [09:10] You can't keep everybody happy :-/ [09:11] Ng: what do you think will be faster: issuing 'bzr whoami "junk "' or getting an updated bzr in maverick ? [09:11] even a change in behaviour to s/error/warn/ for id 0 would be something [09:11] Or more precisely perhaps bug 647475 [09:11] Launchpad bug 647475 in bzr (Ubuntu) "etckeeper with bazaar stopped working for the update manager on upgrade to maverick (affected: 3, heat: 135)" [Undecided,New] https://launchpad.net/bugs/647475 [09:11] I suggest grabbing poolie at UDS [09:12] Ng: not that we shouldn't *refuse* to change bzr behaviour, just proposing you a workaround to address your problem *now* [09:13] vila: sure, a workaround is no problem for me at all, but tools that build on bzr, like etckeeper, are very likely to be used by people who don't understand (or indeed care) the ins and outs of this, which is why I asserted that changing the behaviour in this way is bad, harmful and wrong [09:14] it probably seems very correct from a perspective of develoeprs working on code where every bzr interaction is human driven, but that's not the full reality of bzr's usage [09:15] I will gladly talk to pooli e about it at UDS :) [09:15] Ng: I indeed use bzr unattended and find it good to know where a commit is coming from [09:16] vila: I use bzr more with robots than people and username@hostname was fine for me [09:19] ng, i may even fix it on the plain [09:19] especially if you tell me what you think a good tradeoff would be [09:19] s//plane [09:19] Ng: then I suggest you contribute to bug #647475 or bug #616878 both of which give a good summary of the issues [09:19] i guess you want to go back to just no check, no warning? [09:19] Launchpad bug 647475 in bzr (Ubuntu) "etckeeper with bazaar stopped working for the update manager on upgrade to maverick (affected: 3, heat: 135)" [Undecided,New] https://launchpad.net/bugs/647475 [09:19] Launchpad bug 616878 in Bazaar "bzr commit error because of no identity (affected: 3, heat: 62)" [Medium,Confirmed] https://launchpad.net/bugs/616878 [09:19] would it be reasonable to rely on /etc/mailname being set? [09:22] poolie: so ultimately the limit of my real caring is breaking automated root committing, so I'd be happy if it would notice it was running as uid 0 and just warn, then go with root@hostname [09:22] erroring for users is, I think, a bit annoying, but it's way less likely to break critical things like package transactions [09:24] Why isn' etckeeper setting the proper default ? Istm we're bikeshedding about what bzr default should be with a conflict between protecting unaware users of the consequences and third-party tools on top of bzr using it in an unusual way (running as root) [09:25] vila: it's not bikeshedding dude, bikeshedding is arguing about trivial details, this is me advocating for people whose critical systems are being broken by a significant change of behaviour [09:26] Ng: the fix was about addressing a problem seen as critical by other users, so I still call it bikeshedding as far as different users want different defaults [09:32] vila: I think your characterisation of bug #549310 is misleading, it's not described as critical, it was not assigned a critical bug status and the requested just asked for a warning to be printed [09:32] Launchpad bug 549310 in Bazaar "bzr should not try to guess username but require setting it with whoami (affected: 1, heat: 1)" [Wishlist,Fix released] https://launchpad.net/bugs/549310 [09:35] Ok - this is really bike sheading: For a new qlog option: --show-wt or --show-trees? [09:35] --show-iterables [09:35] GaryvdM: --show-trees [09:41] garyvdm: +1 for show trees [09:42] Ng: well, this has been discussed in other places than here, and I was the one setting it to Wishlist at first. Nobody changed its status but it's hardly relevant now. Can we focus on what the problem is and the various ways it could be addressed ? [09:44] Ng: critical for bzr is only used for bugs that should block a release (including data loss for example), *not* for that kind of problems which could be addressed by explicitly setting a default with a single bzr command [09:44] vila: I think my suggestion for handling uid=0 cases takes care of the most obviously dangerous scenarios [09:45] I'd be happy to repeat that suggestion as bug commentary [09:45] Ng: thanks [09:46] :) [09:49] ng hang on, you're saying we shouldn't have fixed 5493 [09:49] 549310 [09:49] because it's not critical? [09:49] thanks for talking about this btw [09:49] oh, nm, i see you're disputing vila calling it critical [09:50] poolie: indeed, I'm all for encouraging users to set good metadata, I just think the fix went too far [09:52] perhaps bzr could notice that it's not attached to a terminal and not error, but that sounds like a potential rats nest of fragility [09:56] Ng would a warning rather than an error be ok? [09:57] poolie: I think at one point james expressed a preferences for it to warn once only. Wearing an ubuntu user hat, if a warning stops things like etckeeper commits from failing, then yes [10:05] Two more bug fixes and bzr-tfs should be good enough to use with codeplex, should make jelmer happy. [10:09] nice one [10:09] good night all [10:10] Night poolie. Travel well, and enjoy uds! [10:10] poolie: night ! [10:15] poolie: Good night. === Ursinha is now known as Ursinha-afk [13:20] when using the command api, is there any point to calling cleanup_now() ? [13:50] when moving around between versions is there any advantage of doing "bzr revert -r " instead of "bzr update -r "? with revert "bzr version-info" doesn't get updated, while it does with update. [14:14] gthorslund: revert is primarily useful if you wanted to commit the old tree state as a new revision, e.g. to back out changes [14:15] update is normally more useful for inspecting previous tree states, plus it will retain local modifications in your tree whilst you traverse through history [14:18] maxb: so for a plugin like bzr-bisect it would make more sense to use update then? appears it's using revert now and then version-info fails. [14:18] Indeed. [14:19] AFAIK, bisect uses revert purely because 'bzr update -r' was not implemented until recently [14:19] maxb: thx. I'm looking at that plugin anyway. I'll look at writing a bug report + patch later. [14:19] have to go now [14:24] How do you fix a Conflicting tags error? [14:25] I have established that the tag is wrong in my branch, correct in the parent [14:26] So I want to pull the tag from the parent. [14:28] GaryvdM: pull --overwrite will do it, if you're happy for all that entails [14:28] otherwise, locally delete the selected tags you don't want, then pull [14:28] erm [14:28] s/don't want/know to be wrong/ [14:29] maxb: thanks - --overwrite did the trick. === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann === Ursinha-afk is now known as Ursinha [15:42] jam, does history_db use PQM or should I just push to trunk? [15:42] abentley: just push trunk [15:43] jam, what happens if I specify a history_db, but that db doesn't have any information about my branch? [15:43] it gets populated [15:45] jam, is history-db-create optional? [15:45] jam, or is it needed to create the database if it doesn't exist? [15:45] abentley: yes, but faster for the initial import [15:45] I'm not sure what happens if the file itself doesn't exist [16:36] what is bzr+ssh exactly? how does it work exactly? [16:36] It ssh's to the server, and runs 'bzr serve' as a remote command over SSH [16:37] bzr serve, not bzr ? === pynonoir is now known as Guest58983 === beuno is now known as beuno-lunch === pynonoir_ is now known as pynonoir [16:42] Correct.. [16:42] E.g. if you bzr branch bzr+ssh://.... there's no point running bzr branch on the server, because the new workspace needs to be written on the client. [16:43] So, it ssh's to the server, and runs bzr serve which acts as a remote agent for the (local) bzr to talk to; taking commands on stdin, issuing responses on stdout. [16:51] complicated... [16:52] It's a fairly simple way to do it, really. A lot of tools do things this way. svn's ssh support did that. My own IPC::PerlSSH does that; it ssh's to the server and runs "perl" to accept a program on STDIN [16:52] It means you only have to open the ssh port, and most servers already have that, and the ssh server itself doesn't have to understand anything special. It already has all the user auth, for example. [16:58] I definitely don't understand, it may be easier but I don't get it :( [16:59] Maybe someday I'll see step by step or so, but now...I just can't grok it [17:00] I use putty on windows and my private key is protected by password, ssh on Linux doesn't have password protection, besides it'd be necessary to export the ppk to ssh format, creating two files for the same thing [17:01] I'd like to use putty on linux exactly the same way I do on windows, or at least use the ppk on linux (some other program to load it after asking passowrd) [17:07] i'm not very familiar with putty's private key handling, but does adding a passphrase to your private key on linux not do what you want? [17:08] does ssh on linux support protecting the key with a password? In putty, I just click over the file and it shows a dialog asking the password, and in linux, how is that? [17:09] ssh-keygen -p -f I think [17:11] It's called a passphrase. [17:11] But yes, either supply one when you generate the key, or you can alter an existing one as maxb suggests [17:15] And frankly, I blame Putty for not supporting openssh's key format [17:15] Yeah. It's very annoying. I had to jump thruogh many hoops to put a PuTTY SSH key on my phone [17:16] maxb: so when I do bzr push lp:project it will ask me the password in the terminal? [17:17] passphrase. Perhaps. Depends if you're using an agent, and if it's loaded into it [17:17] But this is now just a general "how to use SSH" question, and not directly the fault or control of bzr itself [17:18] I assume so. Personally I've never tried it that way. I always load my key into ssh-agent so I don't have to enter the passphrase once per connection [17:18] Yeah.. it gets very tedious very quickly :) [17:18] how to tell bzr to use "the ssh agent"? In windows it's BZR_SSH=plink for putty's agent [17:18] (though, less so in bzr because e.g. the branch is still local..) [17:18] It should just happen automatically [17:19] automatically? bzr guesses it's meant to use ssh? [17:19] RenatoSilva: bzr on linux (but tell us which one you use if you want more precise answers) relies on openssh. Configuring the ssh agent there is... generally taken into account by your distro [17:20] sorry for the offtopic but just one more question? does "ssh-agent" / ubuntu have a GUI interface for loading keys? [17:21] ok will reboot to linux, brb... [17:21] ssh-add without a tty ought to do that, but easier just to run ssh-add [17:21] Recent Ubuntu will run a GNOME reimplementation of the ssh agent which does have all manner of GUI nonsense [17:22] However, I like the CLI much better, so can't tell you much about that :-) [17:22] Also, the CLI has much less cope for a security attack [17:22] If "some GUI box" pops up and asks for your passphrase, and you neter it... how did you know it wasn't a Javascript box on some webpage, or whatever? [17:22] LeoNerd, maxb: You mean you use 'ssh-add ' only ? [17:22] If you see it in the very xterm you ran 'ssh-add' from, there's a much greater chance of it being legit [17:23] vila: Yes. See my reason above [17:23] vila: Well, no, I mean my .bash_profile does stuff for me :-) [17:23] maxb: your.... where do you get the passphrase from ? smart card ? [17:24] * vila keep for himself that he just add some 'ssh-add' for passwordless keys in a cron job :D [17:25] My .bash_profile inspects .ssh/* and builds a list of keys, and invokes eval `keychain --eval $keys` [17:25] keychain then ensures an agent is available and invokes ssh-add [17:25] I then get prompted either on the console or via pinentry-gtk for the passphrase [17:26] what is keychain ? [17:26] not installed here apparently [17:26] keychain is a manager for ssh-agent [17:27] an equivalent to seahorse then ? [17:27] It will inherit a running ssh-agent from the environment, or start a new one if not found, and then write the necessary envvars to a file, so that future invocations of keychain can then reload the environment in another session [17:27] So basically "find me my running ssh agent or make a new one if necessary" [17:28] plus, inspect the ssh-agent for what keys are loaded, and load any that are missing [17:29] oh, right, synaptic is telling me about it, thanks for the pointer [17:30] hmmm, so that allows you to run cron jobs under password protected keys [17:31] maxb: I have a corner case that isn't covered here: I need to start a daemon on reboot, so there is noone to type the passphrase... any idea ? (I've gove with passwordless keys but...) [17:33] right, no other solution there [17:33] ideally the passwordless keys will have forced command restrictions on the other end [17:34] hmm [17:36] hey all. [17:38] mgz: hey ! [17:39] maxb: anyway, I will re-think about it now that I see what keychain offer [17:41] vila, does look okay to you? [17:42] argh, totally forgot about this one [17:42] also, a second review on and I'll land that as well. [17:43] hmm, I think I'm vaguely uncomfortable splitting the command in its own file instead of digging a bit more for lazy loading but... so little time [17:45] importing bzrlib.tests.script will import bzrlib.tests because that's how packages work [17:45] and bzrlib.tests *can't* lazy import testtools [17:45] it needs it for class definitions and such like. [17:46] mgz: thanks, that's the bit I wanted to check [17:47] mgz: pff, tell what you want, a good regexp for the jared patch will be *far* clearer :-p [17:49] :D [17:52] mgz: we need a commit message for the jared patch, I can't summarize the fix there... my english fails :-/ [17:52] I'm doing it. [17:53] well, let's be honest, the patch is too small for me to understand where this is used ;-) === beuno-lunch is now known as beuno [17:58] done done done, thanks vila. [17:59] and thanks to you both [18:00] jbunting: hey ! Thanks for the fix :) [18:49] Hi, I have a bzr-svn checkout that I am having trouble with - the file contents doesn't match an svn checkout of the same trunk. [18:50] I assume I am having trouble pulling the latest changes from the server. I have been using bzr pull === oubiwann is now known as oubiwann-away [19:44] mornin all :) [20:34] mgz: sorry, I was on other subjects this week and couldn't find the time to discuss about the transport hook. I just saw you put in mp into wip, does this mean you get new ideas ? [20:34] s/in mp/your mp/ [20:35] vila: decided to think about the testcase collection branch first, then come back to it [20:36] I still need to absorb jam's post on the mailing list [20:36] :-/ [20:36]