[00:53] fullermd: in any case… i have my ssh keys set up now, and it's still complaining :/ [01:01] this guy has the same issue: [01:01] https://answers.launchpad.net/bzr/+question/190008 [01:01] jelmer: any thoughts? [01:05] heeeeelp [01:14] fullermd: ? [01:16] Well, if it's still complaining about ssh auth, your ssh keys aren't all setup ;p [01:16] fullermd: they clearly are [01:16] Try just ssh'ing in and track from there. [01:16] heh [01:16] fullermd: what do i ssh to? [01:17] I dunno. The thing with the thing. code maybe? [01:17] fullermd: URL :P [01:17] bazaar.launchpad.net [01:17] ok [01:17] that's better. thanks [01:18] fullermd: just get permission denied for some reason [01:18] That way you can toss some -v's into the process to see what's offered and refused and suchlike. [01:18] okay [01:18] fair enough [01:21] fullermd: okay it's not offering my alternative ssh key for some reason :/ [01:22] == messed up ~/.ssh/config [01:24] okay [01:25] so i want a config file [01:25] bob2: empty more like :P [01:25] which is fine with id_rsa [01:25] but not with my alternate i guess [01:25] Empty config file? How silly. Then you're just wasting the m4 invocation to generate it! [01:26] what [01:26] ssh isn't going to offer random keys that you didn't tell it about [01:30] m4 huh? [01:31] anyway [01:31] bob2: i found two online posts saying all i had to do was put it in .ssh [01:31] grr [01:31] ssh -i .ssh/whocares bazaar.launchpad.net [01:31] yeah, ignore forums [01:31] evidently [01:31] heh [01:31] people don't know what they're talking about there [01:32] Yeah, you'll never get good advice on the internet. [01:34] fullermd: except IRC of course :P [01:34] bob2: get further now, except: http://pastie.org/4275243 [01:39] fullermd: does bzr require a special config or something? [01:47] No, bzr just calls ssh. So if it does {,not} work with just ssh it will {,not} work with bzr. [01:49] fullermd: you misunderstand. i mean the bzr servers [01:49] on launchpad [01:49] or in general [01:49] i have Host, HostName, IDentityFile, User set in my config [01:49] that should eb enough [01:49] but i get "roaming not allowed" [01:49] :/ [01:50] That last paste you had had it trying the id_rsa key, and then nothing else. [01:50] (I think the "trying private key" line for id_dsa is what it says when a file doesn't exist...) [01:51] fullermd: not true [01:51] debug1: Found key in /Users/alex/.ssh/known_hosts:1 [01:51] fullermd: ^ [01:51] That's the host key. [01:51] If I add [01:51] Host bazaar.launchpad.net [01:51] . IdentityFile ~/.ssh/id_nonexistent [01:51] to my ssh config, I get [01:51] hm [01:51] debug1: Next authentication method: publickey [01:51] debug1: Trying private key: /home/fullermd/.ssh/id_nonexistent [01:51] debug1: No more authentication methods to try. [01:51] Permission denied (publickey). [01:52] i have [01:52] Host LaunchpadBazaar [01:52] HostName bazaar.launchpad.net [01:52] IdentityFile ~/.ssh/alexreg-dev [01:52] User alexreg [01:53] Are you ssh'ing to LaunchpadBazaar? [01:53] no to bazaar.launchpad.net [01:53] hence the HostNAme [01:53] Well, there you go. [01:53] HostName determines what host ssh looks up to do the connection. [01:53] The host you give you ssh on the command line is matched to the Host line. [01:53] http://nerderati.com/2011/03/simplify-your-life-with-an-ssh-config-file/ [01:54] how come that then? [01:54] that has non- domain names for Host [01:54] He has "Host dev", and then he runs "ssh dev". [01:54] He doesn't run "ssh dev.example.com", and expect it to pick up that section. [01:54] ok [01:54] so what do i need it as for bzr to pick it up? [01:54] So just change your Host to bazaar.launchpad.net. [01:55] k [01:55] (and drop the HostName. Or not, I guess; it's redundant, but I don't think it'll hurt anything if it's present) [01:59] ok [02:00] fullermd: working now ta [02:00] the ssh config stuff is slightly arcane [02:00] but oh well [02:03] Eh, I never found it particularly so. Though there are some impressive warts, like the stuff around IdentityFile. [02:06] fullermd: it's poorly written. the english is obtuse and turgid, and far from practical in most cases [02:07] but then, that's common to most unix man pages i've seen so far. [02:07] it's rarely (if ever) to the point [02:07] what can one expect, with programmers writing it though [02:07] they're not hired for their literacy [02:08] Mmm. I never tried reading it end to end. I always just skimmed the list of directives to find something I wanted or get the details for one I knew. [02:08] fullermd: that's fair enough. i can imagine they would be useful as a quick reference/reminder for something one already understands! [02:08] just not to learn from... [02:53] hmm [02:53] why don't all commands appear in bzr help commands? [02:54] which ones are not ? [02:54] We use it to keep the hoi polloi out of the cool stuff. [02:58] fullermd: ha! [02:58] lifeless: lp-submit for example [03:03] its an alias [03:03] of lp-propose-merge [03:03] oh okay [03:03] my bad [03:03] lifeless: is there any way to display all the commands for a givne plugin? [03:04] I don't think we preserve that structure, so no. [03:04] many plugins have good help though [03:04] bzr help plugins/launchpad [03:04] for instance [03:04] fair enough [03:04] The info's there, since it has the tags on the end. [03:04] yeah [03:04] Nothing in the ui to filter on 'em though. [03:04] so what's the diff between bzr help launchpad and bzr help plugins/launchpad? [03:05] grep isn't really an answer; falls over and goes splat soon as things wrap. [03:05] lifeless: also, you seem to preserve which command belongs to which plugin [03:05] it seems a given command can be handled by multiple plugins though? [03:05] hm [03:07] yes [03:07] possibly doable via a small patch [03:07] I'd show it in help plugins/XXXX [03:07] indeed [03:07] lifeless: or help commands [plugin] maybe? [03:08] nope :) [03:08] hmm [03:08] rephrase [03:08] you could [03:08] but it would be more code [03:08] was "yes" to "we do preserve command-plugin mappings" or "a given command can be handled by multiple plugins" ? [03:08] and you'd be adding a new place for people to look to find tings [03:08] lifeless: it would be more intuitive for me, perhaps :) [03:08] yes to both I think. [03:08] i see [03:09] I've no objection per se to help commands plugin working [03:09] so at the moment, if multiple plugins are responsible for command xyz, does help xyz merge their helps? [03:09] just noting that that thing itself won't be discoverable [03:09] that's good. [03:09] depends on the way the plugins collaborate [03:09] they can introspect and merge [03:09] thing? [03:09] or replace entirely. [03:09] i see [03:10] thing -> help commands pluginname [03:10] lifeless: it could be documentable in "help commands" maybe… but i see your point! [03:10] like a one-line notice at the top [03:10] *srug* [03:10] *shrug* [03:11] question: how often do you notice one-liners ? :) [03:11] I mean, yes, you'd definitely want to point it there. [03:12] And like I say, I've no objection to it existing and working, but perhaps putting it in the current plugin help (bzr help pluginname which defaults to showing what is in bzr help plugins/pluginname) might be both sufficient and helpful [03:17] lifeless: rarely when things behave how i want, but quite often when i'm "stuck" :) [03:18] lifeless: actuall bzr help plugins/pluginname commands may make the most sense! [03:18] oh yes. and what is the diff between help pluginname and help plugins/pluginname semantically? [03:21] help pluginname shows the first help topic from any of the help subject areas that matches the title [03:21] help plugins/pluginname selects plugins as the subject area. [03:22] For a plugin that doesn't have a command named the same as the plugin, nor a generic help text named the same, help pluginname and help plugins/pluginname will show the same thing. [03:22] ah right [03:23] lifeless: "commands", "topics", "plugins" being the three subject areas? [03:23] IIRC yes. [03:23] its extensible, of course. [03:25] indeed [03:25] as is everything in bzr ;) [03:25] lifeless: help topics/foo doesn't work though hmm. [03:25] commands/foo does though [03:26] lets see [03:27] the section/term syntax is sensible, but the documentation on that is non-existent too alas [03:28] blame me for that [03:28] heh [03:28] there are dev docs [03:28] api docs I mean [03:29] indeed [03:29] lifeless: so is the absence of bzr help topics/foo a slight oversight then? [03:30] neither [03:30] topics isn't a section provider [03:30] one sec [03:30] neither :/ [03:30] ok [03:31] sounds it like it should be though heh [03:31] bzrlib.help.HelpIndices [03:32] ah right [03:33] >>> bzrlib.help.HelpIndices().search_path [03:33] lifeless: so my proposal is 1) make topics and "help index", 2) document the bzr help index/foo syntax in `bzr help` [03:33] you probably know better than me, but that's one way i would be happy with [03:33] just to put it out there! [03:33] >>> bzrlib.help.HelpIndices().search_path[0].prefix [03:33] '' [03:34] and 3) `bzr help plugins/foo commands` to list all commands exposed by a plugin [03:35] well index is also a command [03:35] from bzr-search [03:37] .. [03:40] lifeless: well, you have my 3 suggestions at least :) [03:40] i must be off to bed now if i'm not to collapse... [03:40] but i'll be around to discuss things! [03:40] so yeah, you're welcome to ping me if i don't get around to it first [03:40] night [03:43] Noldorin: I'd start with 3) [03:43] its the key thing you needed [03:43] indeed [03:43] there are already links to e.g. plugins/launchpad [03:43] in the see-also [03:43] the other two are semi-important convenience/doc features [03:43] topics/foo needs to work though i think [03:43] meh [03:44] *drowsily wanders off* [03:44] cheers for discussing though [08:34] morning [08:34] hello === zyga is now known as zyga-afk === zyga-afk is now known as zyga [11:29] hi all, I was wondering whether there's an equivalent for bzr checkout --lightweight for people who have only read access to a repo. (the goal is for them to download the tip only of the repo) [11:30] get a tarball? [11:31] getting a tarball is not really an option [11:31] ugo: lightweight checkouts should work if you have only read access [11:32] jelmer: so this is not linking against the branch? [11:32] they're simply as bad as getting a full branch unless both server and client (?) are on 2.5 [11:33] ugo: it does link to the branch, why is that a problem? [11:33] well, will error if they try to commit I guess. [11:33] jelmer I thought it would fail if you don't have write access as it linked it [11:33] mgz ok [11:34] mgz what do you mean that there as bad as full branch? The lightweight option would pull only the tip, not the whole revisions, no? (anyway clients and servers should be 2.5 in my case) [11:35] anyway, if it's working without write access, it's all I needed to know. Thanks a lot for your lightning fast help :) [11:35] ugo: because this isn't rsync, you're assuming bzr just copies files, but that's not the case [11:37] mgz a lightweight checkout of my tree takes 2min instead of 20 for full branching on my computer [11:37] it accesses the repository, and over http that means to get just the latest files you'll end up downloading a large chunk (several times, if the repo doesn't fit in the 50MB cache) of all the data to get the latest bit of the history all the files [11:37] with local disk access it's sensible. [11:37] mgz the repo is on launchpad [11:37] and with 2.5 some issues where it was assuming no one sane would be trying to do this remotely have been fixed, so it's less pathalogical [11:38] mgz ok [11:40] you're probably using bzr+ssh though, so not having the same experience as someone with read-only access over http [11:41] ho ok [11:41] yes using bzr+ssh [11:42] Anyway, the guy who keeps pestering about bzr because branching the full tree is "stupid" will see that he's downloading tip only so that should be enough to make him happy ;) [11:42] yeah, worth pointing out he can do that (though bug him about using 2.5 as well) [11:43] will do [11:43] thanks [12:10] hello everyone! I was wondering if anyone would have a hint about how to "fix" a branch that is crashing on bzr st. Full traceback is: https://pastebin.canonical.com/70279/, I'm running bzr Installed: 2.5.1-0ubuntu2 [12:11] hi nessita [12:11] hi jelmer [12:12] jelmer: I'm not sure what went wrong with this branch, I was using pipelines in it, and when I run bzr pump --from-submit, the command finished with no errors, but next bzr st crashed [12:12] nessita: any chance you can repost that on pastebin.ubuntu.com, if it doesn't contain anything private ? [12:13] sure [12:13] unfortunately 2 factor auth seems to be failing here ("No matching endpoint found..") [12:13] it's a borked dirstate [12:13] jelmer: http://pastebin.ubuntu.com/1098196/ [12:14] nessita: run `bzr repair-workingtree` [12:14] you'll lose any pending file additions +x bit changes but otherwise it's harmless [12:19] nessita: the entry in .bzr.log for the pump command might be interesting if that's what caused the issue (generally it's the filesystem screwing up due to poweroff, but this might be a pipeline bug) [12:20] mgz: trying the fix and looking for the log [12:20] `bzr version` will tell you where [12:26] mgz: http://pastebin.ubuntu.com/1098211/. And bzr repair-workingtree says: [12:26] bzr: ERROR: The tree does not appear to be corrupt. You probably want "bzr revert" instead. Use "--force" if you are sure you want to reset the working tree. [12:26] shall I use (the) force? [12:27] if someone is interested, I've written a little plugin-joke that takes user photo during commit and stores it in commit metadata: http://bit.ly/M8OvOs [12:27] Code is available via lp:~torkvemada/+junk/bzr-cimage [12:43] nessita: let me just check [12:44] trkv: neat, will have a look in a sec [12:45] mgz: it only requires my patch to hooks, that isn't merged to trunk yet [12:46] so, bug 613066 [12:46] Launchpad bug 613066 in Bazaar "IndexError in dirstate _process_entry when running bzr status" [High,Invalid] https://launchpad.net/bugs/613066 [12:46] lp:~torkvemada/bzr/commit_hooks — it can easy be applied to ubuntu's default 2.5.1 bzr [12:47] is not encouraging, not normal dirstate corruption [12:47] nessita: I'd make a copy of the dirstate file and try --force [12:47] mgz: will do [12:51] mgz: that seemed to work, and bzr st is not failing anymore [12:51] mgz: thanks! [12:58] how do I set up locations.conf such that colocated branches will push to the right place by default? [12:59] e.g. For currently active $BRANCH in ~/src/$PROJECT, have bzr push go to lp:~jml/$PROJECT/$BRANCH [12:59] right now I do: bzr push ~jml/$PROJECT/`bzr nick` (manually entering the project). It's a pain, and makes things like lp-propose less useful. [13:00] jml: IIRC abentley added something that allows you to reference the local nick name in locations.conf [13:01] I'm not sure what happened to it, and whether it actually landed [13:02] speak of the devil! [13:04] jml: this is what I use since 2009 (perhaps is outdated?) https://pastebin.canonical.com/70335/ [13:05] nessita: I think that's for branch-per-directory? [13:05] jml: ah, yes. You want something more magical? :-) [13:05] jml: if you find it, let me know! I would make good use of it [13:06] abentley: jelmer says you might be able to help me with setting up my locations.conf so that colocated branches are pushed to the right location [13:06] nessita: well, I use colocated branches [13:06] jml: oh, and now I feel silly, cuz I have no idea what those are :-) [13:07] nessita: it's a not-quite-ready thing in bzr where there's one directory which contains the repo, a bunch of branches and a working tree for one active branch [13:07] jml: We can't configure a particular colocated branch (yet), but we can configure a group of colocated branches. [13:08] abentley: how would I do that? [13:08] group = all the colocated branches in a repo? [13:09] jml: You use the {branchname} substitution variable. [13:09] bob2: No, all the branches under a given location. [13:09] abentley: e.g. push_location = bzr+ssh://bazaar.launchpad.net/~jml/pkgme-service/${branchname} ? [13:10] jml: right, but without the '$' [13:10] abentley: ta. [13:11] jml: np [13:12] abentley: what version of bzr would I need? [13:12] abentley, ah, thanks [13:12] jml: let me see... [13:15] abentley: or rather, I have that and then 'bzr push' tries to push to literal ~jml/pkgme-service/{branchname} in bzr 2.5.1 [13:15] jml: So, I believe you need 2.6b1 [13:20] is there a PPA w/ 2.6b1 in it? https://launchpad.net/~bzr/+archive/daily has 2.6.0~bzr6524.6234~ppa4038~precise1 – is that the same thing? [13:20] jml: I think that should work [13:21] 6524 is fairly recent [13:21] jelmer: thanks. [13:21] * jml tries. [13:22] bzr: ERROR: Option branchname is not defined while expanding "bzr+ssh://bazaar.launchpad.net/~jml/pkgme-service-python/{branchname}". [13:23] that's different, at least. [13:23] jml: I think it's actually b2. [13:24] jelmer: I've looked into supporting colo branch configuration in locations.conf and it's a pain. file:// urls in locations.conf get converted to paths, which discards branch names, of course. [13:25] abentley: the mixing of paths and URLs is confusing in the config :( [13:26] abentley: vila might have some thoughts on that [13:28] jelmer: I think the only option is to canonicalize to file:// urls. But this will change the way appendpath and location-based config vars work. [13:29] jelmer: Doing colocated branches differently from the bzr-colo and pipeline plugin has some significant disadvantages, in that it needs special support and breaks old assumptions. [13:30] jelmer: like the assumption that a file:// url converts losslessly to a path. [13:31] abentley: it was bzr-colo that did things differently from the core colocated branch support [13:33] abentley: the assumption that file URLs convert one-to-one to file paths is wrong anyway; there are several other bugs related to it in the config code [13:34] jelmer: I was just using bzr-colo as an example of the approach. [13:37] abentley: I don't really see your point [13:37] abentley: bzr-colo needs special support from e.g. bzr-pipeline too [13:37] jelmer: otp [13:57] elmer: What I mean is: when colocation is implemented in the bzr-colo style, switch and switch -b just work, location.conf just works, nicknames just work, and all recent versions of bzr can access the branches. [13:57] jelmer: ^^ [14:00] abentley: it also duplicates control directories for each branch, doesn't support non-bzr colocated branches, or provide an API for colocated branches [14:00] abentley: switch and switch -b should work for the builtin colocated branches [14:01] jelmer: Using the bzr-colo layout doesn't prevent you from having an API for colocated branches. [14:01] abentley: ... and it means branch URLs actually depend on format internals (/home/foo/.bzr/branches/bar) [14:02] jelmer: Sure, switch and switch -b work *now*, and so do nicknames, but they all required special support. [14:03] abentley: bzr-colo style branches have a fair amount of overhead, especially when you have a nontrivial amount of branches [14:03] abentley: that makes them a bad idea to put into the core [14:05] jelmer: Well, it's good to understand some of the advantages, because up to now, I couldn't understand why you'd taken that approach. === frankoid_ is now known as frankoid [15:24] help request involving pipes: I have a pipeline and I would like to remove a branch that already was merged into trunk, but when running bzr remove-pipeline, I get "bzr: ERROR: Branch is not connected to a pipeline". Full output, along with bzr pipes output, is here: http://pastebin.ubuntu.com/1098454/ [15:24] Any hints? [15:26] nessita: try switching to highway-91 and running pipes again. Does it still say it's connected to the others? [15:26] abentley: nopes :-. [15:26] :-/ [15:26] abentley: hum, shall I use switch or switch-pipes for that test? [15:27] nessita: either should do. [15:27] then no, is not connect3ed [15:27] $ bzr pipes [15:27] * highway-91 [15:27] $ [15:28] nessita: So, the-devil-wears-prada.0 thinks it's linked to highway-91, but highway-91 doesn't agree. [15:28] abentley: so, did I screw that up somehow? :-) [15:29] nessita: Hard to say whether it's user error or a bug. Did you try adding highway-91 to another pipeline or anything? [15:29] nessita: Anyhow, the fix is to remove the reference to highway 91 manually. [15:30] abentley: thanks, will do that then [15:30] those are some amusing pipe names. [15:31] mgz: some time ago, I've decided to use movie titles as branch names, but is not working that well... I thought it would be easier/funnier :-) [15:31] nessita: I think this will work: bzr switch the-devil-wears-prada.0 && bzr configure --scope=branch prev_pipe='' [15:31] abentley: running [15:32] nessita: Oh, it' [15:32] abentley: am I missing a plugin perhaps? bzr: ERROR: unknown command "configure" [15:32] s "bzr config", not "bzr configure". [15:32] ah! [15:33] abentley: that removed highway-91 from the pipes listing, thanks! [15:33] nessita: np. === deryck is now known as deryck[lunch] === jordan___ is now known as jordan === Daviey_ is now known as Daviey [19:40] * maxb writes script to assess bzr PPA uptodateness; shudders in trepidation [20:10] maxb: ah, I take it you saw the email about hardy packages then? [20:11] jelmer: no? [20:13] ah... I wondered if that was in way of response as well [20:14] I think I'm missing something [20:14] I *sent* an email about hardy packages [20:14] maxb: someone sent an email using launchpad to... ~bzr? asking for updated bzr in hardy ppa [20:14] maxb: somebody emailed ~bzr (using the contact team thing on Launchpad) about updated hardy packages in the PPA [20:14] can forward it to you [20:14] maxb: yesterday, I think [20:15] Subject: "bzr ppa advancement"? That was about lucid [20:15] ugh, bzr.debian.org seems to have stopped responding to ssh [20:18] maxb: it will lock you out for a while if you fail to authenticate a couple of times [20:20] hm... I'm not failing to authenticate, but it's probably not the first ssh key in my ssh-agent. [20:20] I wonder if the ssh keys it tries on the way to finding the right one are counting against me [20:22] try ssh -vvvv bzr.debian.org? [20:22] tells you what its doing [20:23] yeah, looks like it's a poorly written fail2ban thing [23:00] hey jelmer. === wgrant_ is now known as wgrant [23:14] hi Noldorin [23:16] jelmer: just installed the bzr bash-completion plugin yesterday. noticed the project seems to be defunct. [23:17] jelmer: maybe canonical could take it over though? i've got a fix for it already :) [23:22] Noldorin: there is a bash completion plugin in bzr itself [23:23] jelmer: there is? :O [23:23] who would ever know [23:23] haha [23:23] do tell [23:23] Noldorin: it's part of the main bzr code [23:24] Noldorin: bzrlib/plugins/bash_completion [23:28] jelmer: okay nice. so that's the version of his that was merged in evidently... [23:28] i just patched the original project [23:28] oh well [23:28] that should really ahve a notice :P [23:29] Noldorin: I'm not sure if what was merged in was the same project that you patched [23:29] jelmer: yes, it is [23:29] i am sure [23:29] it says so in the README [23:29] and it corresponds with the cut-off in activity of that project [23:30] okay [23:30] jelmer: so it would be nice if this plugin were publicised more [23:30] it's pretty esoteric at the moment [23:31] sure, no objection here [23:31] jelmer: not sure how would be best, but yeah… :) [23:31] doesn't turn up on google even. well, only the old/obsolete version does