| spiv | Good morning | 00:00 |
|---|---|---|
| poolie | hi spiv, all | 00:30 |
| === med_out is now known as med | ||
| === med is now known as medberry | ||
| === poolie1 is now known as poolie | ||
| === medberry is now known as med_out | ||
| RenatoSilva | what's the purpose of bzr PPA if there's bzr available in ubuntu already? | 03:45 |
| poolie | RenatoSilva: a few things | 03:46 |
| poolie | basically they have later bzr releases than you would get from ubuntu | 03:46 |
| poolie | eg there's a nightly ppa | 03:46 |
| poolie | also there are ppas with updated bzrs for historic ubuntu releases | 03:46 |
| RenatoSilva | so just a matter of most updated versions? | 03:47 |
| poolie | pretty much | 03:47 |
| poolie | you can get the current stable release, the current beta, or a nightly | 03:48 |
| poolie | also the corresponding plugins | 03:48 |
| poolie | whereas historic ubuntu releases will only get bugfix updates | 03:48 |
| poolie | (and even there there is some lag as they're qa'd before getting into -updates) | 03:48 |
| RenatoSilva | ok thanks, will deactivate the PPA for now | 03:49 |
| === vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | ||
| vila | hi all ! | 06:51 |
| spiv | Hey vila | 06:53 |
| vila | _o/ | 06:53 |
| poolie | hi vila, spiv | 06:55 |
| maxb | Morning all :-) | 07:15 |
| maxb | spiv: As you may have seen from u-d-d@, when I went to revert append-revisions-only I discovered it was trapping a genuine case of concern :-/ | 07:16 |
| poolie | hullo maxb | 07:18 |
| maxb | Hi poolie | 07:19 |
| poolie | did i understand your point? | 07:20 |
| spiv | maxb: yeah, I saw | 07:20 |
| poolie | i didn't get around yet to looking at the specific failures to see how they line up | 07:20 |
| spiv | maxb: makes me a little happier that I did it ;) | 07:20 |
| maxb | On a different matter, I reopened bug 524173 | 07:20 |
| ubot5 | Launchpad bug 524173 in Ubuntu Distributed Development "package-import uses james_w credentials" [High,Confirmed] https://launchpad.net/bugs/524173 | 07:20 |
| poolie | i saw | 07:21 |
| poolie | i can't win :/ | 07:21 |
| poolie | i havent' gone back to it yet | 07:21 |
| maxb | Third time's the charm? :-) | 07:21 |
| maxb | I think it'll really be dead this time | 07:22 |
| maxb | I think you did understand what I was saying about append-revisions-only - to paraphrase, it's not right that 0.1.2ubuntu1 revisions start showing up in Debian branches unless they're actually in the changelogs uploaded to Debian | 07:23 |
| maxb | vila: I've now worked through my backlog of PPA uploads :-) | 07:26 |
| vila | maxb: \o/ | 07:27 |
| * maxb ponders backporting natty's debhelper to maverick and lucid in the support of reduced deltas in the daily-ppa | 07:33 | |
| poolie | could be good | 07:34 |
| poolie | it should perhaps go in a more general purpose ppa? | 07:34 |
| poolie | i wonder if someone already did it actually | 07:34 |
| jelmer | g'morning poolie | 07:34 |
| poolie | hi there | 07:34 |
| maxb | https://launchpad.net/ubuntu/+ppas?name_filter=debhelper --> 221 results | 07:38 |
| maxb | of which bzr-builddeps is the first :-) | 07:38 |
| jam1 | morning all | 07:44 |
| jelmer | hey jam | 07:46 |
| mrevell | ning | 08:08 |
| vila | hey jam, don't forget to write a pp report email | 08:10 |
| jam1 | ugh, still called jam1 | 08:11 |
| === jam1 is now known as jam | ||
| jam | vila: can you try to ping again | 08:11 |
| vila | hey jam, don't forget to write a pp report email | 08:12 |
| jam | yay | 08:12 |
| jam | vila: I'm spinning up ec2 now to build the 2.3.4 installers | 08:12 |
| jam | vila: technically, I was only assisting Riddell for doing PP | 08:12 |
| vila | jam: oh right, keep assisting him then :) | 08:13 |
| vila | hey Riddell, don't forget to write a pp report email | 08:13 |
| vila | :D | 08:13 |
| jam | I don't think Riddell is online yet | 08:15 |
| spiv | Hmm, my attempt at a concise description of the conditions for bug 806348 still ended up as a screenful of text :/ | 08:17 |
| ubot5 | Launchpad bug 806348 in Ubuntu Distributed Development "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [High,In progress] https://launchpad.net/bugs/806348 | 08:17 |
| spiv | jam: If you have the time, I'd love it if you can look at that bug and my comments and tell me if there's an obvious fix I'm failing to se | 08:18 |
| spiv | *see | 08:18 |
| jam | spiv: off-hand the big question I have is why can we fetch "[D, A]" rather than always having to do "[D, (A,C)]" | 08:20 |
| spiv | What's the (A,C) notation mean there? | 08:21 |
| jam | well, I assume [D, A] is fetch D excluding A | 08:21 |
| spiv | Ah, no. | 08:21 |
| jam | so it would be Fetch D excluding C and A | 08:21 |
| spiv | It's a list of heads | 08:21 |
| spiv | Ah, actually, it's a list of revs in this context :) | 08:21 |
| maxb | Is it significant that various of the UDD BzrCheckErrors refer to different kinds of missing keys? | 08:21 |
| jam | maxb: different kinds? probably. missing texts is a very different issue than missing chk pagse | 08:22 |
| jam | at least, very different logic involved (usually) | 08:22 |
| jam | Morning Riddell | 08:22 |
| spiv | (In the case of the [D,A] example the initial set of heads to fetch is also the set of revisions fetched from the first stacked repo) | 08:22 |
| jam | spiv: I'm not quite sure how you get a "fetch [D, A]" because of tags? | 08:22 |
| spiv | jam: right | 08:23 |
| Riddell | good morning jam | 08:23 |
| jam | spiv: so does this not happen without your tags logic? | 08:23 |
| jam | Riddell: vila would like to remind you to write a Patch-pilot summary email | 08:23 |
| Riddell | actually I'm just starting my patch pilot week | 08:23 |
| jam | Riddell: well, you and I worked on it a bit last week, and I went ahead and scheduled vila for this week, because he's gone again next week | 08:24 |
| spiv | jam: I have a suspicion this can also happen without starting with multiple heads, not only out of general paranoia rather than evidence | 08:24 |
| jam | but you can partner with him. | 08:24 |
| jam | spiv: "but only" ? | 08:24 |
| spiv | jam: yes, sorry :) | 08:25 |
| jam | spiv: I'm just suspicious because we didn't really see this before your patch landed. We saw it for bzr-svn but because bzr-svn was rewriting inventories. | 08:25 |
| spiv | Right. | 08:25 |
| jam | and we saw it when chk pages collapsed, because one of our "optimizations" accidentally forgot to actually rewrite the tree | 08:25 |
| spiv | Like I say, no evidence, so I'm happy to discount the possiblity for now: if it does happen, it's clearly not happening much. | 08:26 |
| jam | spiv: so in reading your write-up, it isn't clear to me what the content is in various branches, where the stacking boundaries are, etc. | 08:26 |
| spiv | (But at the same time, I feel like the theoretical foundations of the logic used here aren't as solid as they should be, hence my general suspicion.) | 08:26 |
| jam | also, yeah, we could certainly have edge cases in the fetch code, that are just being provoked by new fetch requests. | 08:26 |
| spiv | jam: ok, in that case perhaps skip the English and read the failing test in the branch :/ | 08:27 |
| spiv | It's bzrlib.tests.per_repository_reference.test_fetch.TestFetchFromRepoWithUnconfiguredFallbacks.test_parent_inventories_with_identical_contents(RemoteRepositoryFormat-default) that fails. | 08:27 |
| spiv | maxb: FWIW, I think at least some of those bugs are the same, or at least closely related, possibly even including the missing texts | 08:32 |
| spiv | maxb: the simplest way to find out is likely to be fix the test that's failing in lp:~spiv/bzr/stacked-fetch-same-chks and seeing how many failures that fixes :) | 08:33 |
| * spiv -> EOD | 08:34 | |
| poolie | cheerio spiv | 08:34 |
| jam | maxb: python-bzrlib.tests got installed, btw | 08:47 |
| jam | have a good night spiv | 08:47 |
| jam | poolie: I was bringing up desolation again, and I was thinking, how do we know how much data we're using in S3? It seems a bit confusing since everything gets stored as 100s of 10MB chunks. | 08:56 |
| jam | so while I deregister old AMIs that we don't want to use anymore | 08:56 |
| jam | I don't know if that actually frees the S3 space | 08:56 |
| poolie | the short answer is that in the last few months the usage has cost so little i have not bothered claiming it | 08:56 |
| poolie | something like $8/m | 08:56 |
| poolie | including run itme | 08:56 |
| poolie | *time | 08:56 |
| jam | actually, looking at ec2.bazaar-vcs.org it looks like we have "desolation-2010-07-27" still on there. | 08:56 |
| poolie | when it was running continuously it was more significant | 08:57 |
| jam | poolie: yeah, I've been pretty good about not even letting it run overnight | 08:57 |
| poolie | thanks for that | 08:57 |
| jam | as I can bring it up, bootstrap it, build and shut it down | 08:57 |
| poolie | jam, re "caught before production deployment" etc, see my later mail with the timeline from robert | 08:57 |
| poolie | it was a bit confusing before | 08:57 |
| jam | yeah | 08:57 |
| jam | and as you say, it does, indeed, cost almost as much to break in QA as it does in prod | 08:58 |
| jam | at least human-time wise | 08:58 |
| jam | I guess, rolling back appservers takes more losa time | 08:58 |
| jam | since they have to kick off a script to rollback each one | 08:58 |
| jelmer | jam: evolution has recently started displaying your emails as only having a signature and an empty body. has something changed in your setup recently? | 09:01 |
| jelmer | As in, the last couple of days. | 09:02 |
| jelmer | If not, perhaps I've hit a bug in evolution in oneiric | 09:02 |
| jam | jelmer: nothing changed on my Laptop, a couple times I respond via my phone, but that wouldn't have a signature | 09:02 |
| jam | I think you have a bug in oneiric | 09:02 |
| jelmer | I'll report it - thanks for confirming | 09:03 |
| * jam => lunch, bbiab | 09:19 | |
| gour | morning...i plan to contribute to github project using bzr-git...i did a small test...forked repo, pulled from it with bzr branch, edit, commit, dpush back and it looks ok...is bzr-git adequate for such a work where i'd fork, make small change, dpush back and launched 'pull request' to upstream? | 09:44 |
| jelmer | gour: yeah, I've been doing that with dulwich itself for a while | 09:45 |
| gour | jelmer: cool...i'm really hesitant to use git (it's way too complex for my taste distracting from the main work)..btw, thanks a lot for bzr-git...what would be required for 'git push'? lot of work? | 09:46 |
| jelmer | gour: you mean 'bzr push' to a git repo? | 09:46 |
| gour | jelmer: yep | 09:46 |
| jelmer | gour: we need to be able to represent all data that is present in the bzr branch in git | 09:47 |
| jelmer | so file ids, revision properties, etc need to all be stowed in the git revisions somewhere | 09:47 |
| gour | will 2.4 help in that regard? | 09:47 |
| jelmer | gour: this wouldn't require any bzr changes, just bzr-git changes | 09:48 |
| jelmer | there is some initial work done in bzr-git towards this, but it's unfinished | 09:48 |
| gour | jelmer: ok...otoh, for the above scenario, bzr-git is great...much better than forcing oneself to git | 09:48 |
| gour | bzr-hg is behind git plugin? | 09:49 |
| jelmer | gour: behind in what sense? | 09:51 |
| gour | jelmer: functionality...is it possible to use 'bzr dpush' ? | 09:52 |
| jelmer | gour: ah | 09:52 |
| jelmer | gour: it's possible, but more experimental in bzr-hg | 09:52 |
| gour | ok | 09:53 |
| * jam => back | 10:34 | |
| === JoeMaverickSett is now known as MavJS | ||
| vila | Riddell: If you want to keep co-piloting this week, I'm happy to help | 12:26 |
| Riddell | vila: maybe we could pair on it tomorrow? | 12:29 |
| vila | Riddell: perfect | 12:30 |
| jam | vila: poke with a blunt stick | 12:46 |
| jam | question about: https://code.launchpad.net/~jameinel/bzr/2.4-no-open-master/+merge/67689 | 12:47 |
| jam | does it need a test before we can land it? | 12:47 |
| jam | I'm not 100% sure how to write one easily | 12:47 |
| odony | Hi everyone, I'm trying 2.4b5, and so far so good, except now I'm trying to push on an existing LP branch, and this single commit push is taking ages and uploading lots of stuff | 12:57 |
| odony | it's saying "Fetching revisions:Inserting stream:Estimate 12467/12570" and the max numbers keeps increasing... any way to find out what's happening? | 12:58 |
| odony | with 2.3 pushing to that branch was always very fast, the repo/branch format did not change AFAICS... bzr push -v does not give me any more info | 12:59 |
| vila | jam: my concerns here are two-folds: 1) You get read of the remote access, a test should guard that we don't regress | 13:04 |
| vila | 2) by not doing the access you open the url-slightly-broken cases we encounter in that other bug | 13:05 |
| spiv | odony: 2.4 pushes revisions named by tags (if they aren't already present) | 13:05 |
| spiv | odony: perhaps you have some strange tags? | 13:06 |
| jam | odony: yeah, I'm guessing you have tags in the branch that are meant to be present in the development focus branch | 13:06 |
| odony | hmm yes that might be the case | 13:07 |
| odony | out CI system tags build failures, and this is the dev focus branch indeed | 13:07 |
| spiv | jam: or potentially even irrelevant tags from a failed 'bzr merge' from an unrelated branch :/ | 13:07 |
| odony | is there a way to disable this? I'm concerned of locking our main dev branch for so long... been uploading for 30+ minutes uninterrupted | 13:08 |
| jam | odony: this only happens once, but no, there isn't a specific way to disable it. | 13:09 |
| odony | any idea how much overhead we are talking about here? this branch has a few thousands revisions, but probably only a few hundreds of them have tags | 13:10 |
| jam | odony: the specific issue is that we fetch revisions which were tagged, that were not already present. | 13:10 |
| jam | it sounds like you might have a tag that points at unrelated history. | 13:10 |
| odony | last time I killed it upload had stalled after 50Mb+ | 13:10 |
| jam | eg, a bzr-svn branch that has a tag pointing at a bzr revision | 13:11 |
| odony | jam: I think I see what you mean... is there an easy way to find out if that's the case? I don't think we have any imported revisions | 13:13 |
| jelmer | odony: if "bzr tags" reports revisions with "?" as the revision | 13:14 |
| spiv | It might be an interesting little project to write a plugin to identify which tags are least related to your current tip. | 13:14 |
| jelmer | odony: any revisions with a revision number reported by "bzr tags" are part of the tips ancestry | 13:14 |
| odony | jelmer: thanks, let's see... | 13:14 |
| spiv | Legitimate tags can be like that, e.g. tags of releases. | 13:14 |
| spiv | (When the release branch diverged at least a little from the trunk) | 13:15 |
| jelmer | ah, sorry - yes | 13:15 |
| spiv | But certainly any tag with a revno is definitely ok :) | 13:15 |
| jelmer | odony: What I described will report any revisions that are now tagged that previously weren't, not necessarily only revisions that are unrelated to your current branch | 13:15 |
| odony | "bzr tags|wc -l" gives 1758 tags, and "bzr tags|grep '?$' |wc -l" 146 tags | 13:16 |
| odony | jelmer: I'm not sure I'm following, many of the ? tags are release tags coming from other branches, and some look like valid tags added by our QA system, but still they don't have a revision | 13:18 |
| jelmer | odony: they will only have a revision if they are part of the history of your current branch | 13:20 |
| jelmer | if they are related but not in the history they will still show "?" because you can't use a revision number to refer to them | 13:20 |
| odony | jelmer: I see, but why would they be in the branch if they're not related to its history? Is that because it's the dev focus branch? | 13:22 |
| jelmer | odony: the tags would be pulled in by e.g. a "bzr merge" which was reverted, or manual "bzr tag" commands for revisions that weren't in the history | 13:23 |
| odony | jelmer: oh I see, merges that were reverted are probably common patterns here.. didn't know that would leave unused tags in your branch | 13:24 |
| jelmer | odony: it's a bug in bzr that that happens, but it's pretty hard to fix with the current way tags work (since tags are unversioned) | 13:26 |
| odony | jelmer: alright, makes sense now :-) so I guess removing all those tags with bzr tag --delete would be safe? (assuming they're not bound to any revision, they're mostly useless?) | 13:28 |
| jelmer | odony: they're bound to a revision, but that revision can't be addressed using a short revno | 13:28 |
| spiv | You can see the revision-id with 'bzr tags -v' | 13:29 |
| jelmer | odony: you can indeed safely remove them, "bzr tag --delete" only deletes tags, never history | 13:29 |
| spiv | er, | 13:29 |
| spiv | bzr tags --show-ids, anyway :) | 13:29 |
| odony | spiv: ah yes, --show-ids works, great | 13:30 |
| spiv | But yes, if you don't think the tags should be on that branch, then removing those tags from that branch sounds like a good idea :) | 13:30 |
| odony | spiv: well, they're not very important, but I'd rather keep them if it doesn't help speeding up the push ;-) | 13:32 |
| odony | so jam was saying that these tags might further slow the push? that's because they need a long revision id to work, so possible require the upload of a side branch along with the main one? | 13:33 |
| odony | s/possible/possibly | 13:33 |
| jam | odony: the most likely issue is that these revisions are present on your local machine (for whatever reason) | 13:33 |
| jam | but never got pushed into the dev focus's repository | 13:34 |
| jam | so *right now* you are pushing them there, correct? | 13:34 |
| jam | at which point, all future branches based off of this dev focus | 13:34 |
| jam | won't try to include them | 13:34 |
| jam | (as they'll already be in the dev focus) | 13:34 |
| odony | jam: I'm not supposed to have any of these tags only on my machine, because they're mostly added by our QA system externally | 13:35 |
| odony | so if they're somewhere, it shouldn't be on my machine only... I almost never manually tag | 13:35 |
| odony | does that make sense? | 13:35 |
| odony | (btw, my current branch is part of a shared repo with other branches, don't know if they are shared between them) | 13:37 |
| jam | vila: http://paste.ubuntu.com/646517/ | 13:46 |
| jam | we should have had effort tests long ago | 13:46 |
| jam | that is "bzr switch --create-branch -d checkout new-feature" | 13:46 |
| jam | which, in theory, should open checkout, and then create new-feature, and switch to it. | 13:46 |
| jam | It calls "Branch.open()" for checkout 10 times | 13:47 |
| jam | master 2 times | 13:47 |
| jam | and feature 3 times | 13:47 |
| jam | ugh | 13:47 |
| jelmer | ouch | 13:47 |
| vila | hehe, err :-/ | 13:47 |
| jam | my patch reduces that a bit | 13:47 |
| jam | and, of course, you can't pdb in run_bzr... :( | 13:48 |
| vila | yeah, painful | 13:48 |
| vila | Last time I suffered from this I wondered if it may possible to patch pdb to use sys.stdin/sys.stdout (the original) to stay immune from redirections | 13:49 |
| jam | vila: we explicitly patch sys.stdin/stdout. I think we could instead have a "run_bzr(no_redirect=True)" or something like that | 13:50 |
| jam | to avoid the monkeypatching | 13:50 |
| jam | hmm... it seems we do legitimately open the master branch, because we want to check if the local heavyweight branch has any commits that aren't in master, before we let you switch away (and lose them, in theory) | 13:50 |
| jam | (i'm not 100% sure about the validity that we would lose them...) | 13:51 |
| jam | I suppose the test is if this is heavyweight | 13:51 |
| jam | and you are going to point it at another branch | 13:51 |
| jam | you don't want to lose commits you had locally, that hadn't been pushed to master | 13:51 |
| jam | since you can 'bzr switch' bound branches. | 13:51 |
| jam | anyway | 13:51 |
| jam | I'm guessing we're also running into caching issues. As in, master branch is supposed to be cached, but isn't because we don't lock things correctly. | 13:52 |
| jam | anyway, I don't need to fix all of that right now | 13:52 |
| vila | no, no, we don't want no_redirect, at least almost never, but python keep track of the originals somewhere and pdb should use them (unless we want to have pdb redirected for a given test) | 13:52 |
| jam | I can still assert that my patch is better than it was | 13:52 |
| jam | vila: I mean "no_redirect" as a way to debug manually | 13:52 |
| jam | not something you leave in the test suite | 13:52 |
| jam | but somethingthat "I just want to debug this" | 13:53 |
| vila | jam: I've tried patching the redirection a few times to debug, never worked well :-/ | 13:53 |
| jam | well, that I don't doubt | 13:53 |
| jam | you can't make assertions about the output if we don't collect it | 13:53 |
| jam | etc | 13:53 |
| vila | yup | 13:54 |
| vila | jam: I'm happy for you to land with this test added | 13:54 |
| vila | jam: as a rule, I'd prefer an ugly test revealing issues than no test at all, and here, the test doesn't look ugly (the result on the other hand... ;) | 13:55 |
| vila | jam: I thought branch provides different transports including one with at the branch base which may avoid the double strip | 13:56 |
| vila | user_transport as opposed to control_transport or something ? | 13:56 |
| jam | vila: it is certainly possible to avoid creating a new SSH connection, etc. In fact, master_branch is cached as a Branch attribute | 13:58 |
| jam | but caches only live as long as the branch is locked | 13:58 |
| jam | and creating 10 Branch.open() of 'checkout' indicates we are probably not sharing branches where we think we are | 13:59 |
| jam | jelmer: did you update the bzr-rewrite plugin to not use "bzrlib.trace.info" ? | 14:03 |
| jam | I'm getting "ImportError: cannot import name info" on the latest bzr | 14:03 |
| jam | of course, my plugin is called "rebase" so it is probably really old | 14:03 |
| jam | (yeah, I think the latest version is fine) | 14:03 |
| jam | jelmer: do you have time to chat about :https://code.launchpad.net/~jameinel/bzr/2.5-up-to-date-609187/+merge/67844 | 14:04 |
| jam | specifically the ~ubuntu-branches stuff | 14:04 |
| jam | because if we use a short URL, we won't see "~ubuntu-branches",but also the package importer doesn't always use ~ubuntu-branches | 14:05 |
| jam | (At least, there was a recent thread about people making their own branch the official package import, which the importer would then overwrite as needed.) | 14:05 |
| jam | which may be a bit wonky | 14:05 |
| jelmer | jam: one sec, let me check (wrt bzr-rewrite) | 14:06 |
| jam | (bzr-rewrite seems to be correct now, I'm not getting the warning with trunk, i was just being lazy) | 14:06 |
| jelmer | jam: are you pulling from lp:bzr-rewrite? | 14:07 |
| jelmer | jam: Ah, cool | 14:07 |
| jam | jelmer: yeah, just an old 'bzr-rebase' branch. | 14:07 |
| jelmer | jam: also, I'm happy to chat about 2.5-up-to-date-609187 now or later, whatever works best for you | 14:07 |
| jelmer | I think it would be really confusing to get warnings on branches that the importer doesn't take care of | 14:08 |
| jelmer | jam: how/where would we setup things to allow pushing to a different branch? | 14:09 |
| jelmer | I imagine we would still have to set up launchpad to know what the canonical branch is, if it's not the ~ubuntu-branches branch | 14:11 |
| jam | jelmer: so I don't really know. I'm going off of what i've gleaned from conversations in the past | 14:11 |
| jam | but AIUI, "lp:ubuntu/foo" may not be "lp:~ubuntu-branches/ubuntu/oneiric/foo/oneiric" | 14:12 |
| jam | though in most cases it is. | 14:12 |
| jam | anyway, I would be fine changing the regex to... | 14:13 |
| jam | *if* there is a ~, then it must match ~ubuntu-branches | 14:13 |
| jam | otherwise don't warn | 14:13 |
| jelmer | jam: I guess it would be another roundtrip to check if the branch that was specified is the canonical packaging branch? | 14:13 |
| jam | jelmer: is that good enough for your concern? | 14:13 |
| jelmer | jam: that's fine with me | 14:14 |
| jam | jelmer: something like that. I'm not really sure how to do the query. | 14:14 |
| jelmer | jam: Anyway, nice work on that one. Sorry we didn't end up pairing on it. | 14:16 |
| jam | yeah, you were out of town, and I made some headway, so I figured I'd push it through | 14:18 |
| odony | thanks jam, jelmer, spiv: I finally managed to finish pushing my branch, after deleting many ? tags and being more patient :-) | 14:27 |
| jam | jelmer: you have: <<<<<<< TREE | 15:07 |
| jam | * Fix i18n use when no environment variables are set. (Jelmer Vernooij, #810701) | 15:07 |
| jam | in bzr.dev | 15:07 |
| jam | but it shows up in bzr-2.4.txt | 15:07 |
| jelmer | hhh/win 81 | 15:07 |
| jam | shouldn't it be in bzr-2.5.txt? | 15:07 |
| jam | (It just conflicted trying to merge lp:bzr/2.4 into lp:bzr, and I wanted to understand why) | 15:08 |
| jelmer | jam: ah, thanks | 15:08 |
| jelmer | yep | 15:08 |
| jam | jelmer: I'll clean it up and land it | 15:09 |
| jam | I just wasn't sure whether you meant to land it on lp:bzr/2.4, etc. | 15:10 |
| jam | Its easy to do | 15:10 |
| jam | and certainly NEWS/release-notes is a pain point in genreal | 15:10 |
| jam | general | 15:10 |
| jelmer | 2.5 is fine I think - thanks for doing the cleanup | 15:12 |
| jelmer | I wonder if we should file a bug about making fetching all revisions referred to by tags optional | 15:13 |
| jelmer | for 2.4, that is | 15:13 |
| odony | I have another interesting issue when pushing a (different) branch with 2.4: ErrorFromSmartServer: Error received from smart server: ('error', "Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:32b5964d29924e611fc4b50e92ca0aeed58c2cea',)]") | 15:14 |
| jelmer | odony: that's a known bug, let me find the bug | 15:15 |
| jelmer | was this a branch imported with bzr-svn? | 15:16 |
| odony | jelmer: I don't think so | 15:16 |
| jelmer | it could be bug 718723 ? | 15:17 |
| ubot5 | Launchpad bug 718723 in Launchpad itself "fetch from merge directive to stacked branch unable to fill in chk pages" [Critical,Triaged] https://launchpad.net/bugs/718723 | 15:17 |
| odony | jelmer: I was reading it, but it's not clear... it happened during a regular push of a single commit, something that I used to do on that branch everyday with 2.3 | 15:19 |
| jelmer | odony: please file a bug, that sounds worrying | 15:19 |
| odony | it somehow seems to be related with 2.4 (perhaps the uploading of tagged revisions, as that was another branch with hundreds of tags) | 15:20 |
| odony | jelmer: I clicked on "report problem" when the crash report came, so I think apport may have created it on launchpad (but not sure where) | 15:21 |
| odony | jelmer: hmm no of course "this is not a genuine Ubuntu package", so apport didn't report it, I will do it manually | 15:25 |
| jelmer | odony: thanks! | 15:44 |
| odony | jelmer: FYI, that's bug 812385 ;-) | 16:01 |
| ubot5 | Launchpad bug 812385 in Bazaar "[2.4b5] push sometimes fails with "missing referenced chk root keys"" [Undecided,New] https://launchpad.net/bugs/812385 | 16:01 |
| jelmer | odony: thanks again | 16:09 |
| === deryck is now known as deryck[lunch] | ||
| jezuz | how do i pull from a readonly source? | 16:17 |
| jezuz | its telling me it cant lock it but it shouldnt be trying to | 16:17 |
| jelmer | jezuz: hi | 16:21 |
| jezuz | hello | 16:21 |
| jezuz | im having trouble :( | 16:21 |
| jelmer | jezuz: is the branch you are trying to pull into perhaps bound? | 16:22 |
| jezuz | bound? | 16:22 |
| jelmer | jezuz: ("bzr info" should tell you) | 16:22 |
| jezuz | ok | 16:22 |
| jelmer | if it was created with "bzr checkout", it will be bound | 16:22 |
| jezuz | what am i looking for? | 16:23 |
| jezuz | it says checkout | 16:23 |
| jezuz | i did change the location in the config to bzr+ssh | 16:23 |
| jezuz | i did this before, but i cant remember what i did | 16:23 |
| jezuz | since it was an http transport before... | 16:23 |
| jelmer | jezuz: if you're trying to update a bound branch (a checkout), use "bzr up" rather than "bzr pull" | 16:25 |
| jezuz | is there a flag to overwrite local changes too? or is that default? | 16:25 |
| jelmer | local changes in the working tree? | 16:27 |
| jezuz | yeah | 16:27 |
| jelmer | you can use "bzr revert" after the "bzr up" command | 16:27 |
| jezuz | k | 16:27 |
| jezuz | thanks | 16:28 |
| === beuno is now known as beuno-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| === charlieS_ is now known as charlie | ||
| === charlie is now known as charlieS | ||
| quotemstr | Is there an equivalent to git commit --amend? | 20:30 |
| luks | bzr uncommit | 20:31 |
| luks | bzr commit | 20:31 |
| === yofel_ is now known as yofel | ||
| === med_out is now known as med | ||
| === med is now known as medberry | ||
| poolie | hi all | 22:43 |
| poolie | o/ maxb | 23:13 |
| maxb | hello | 23:13 |
| poolie | i think i'll file a bug for doing the package imports in topological order and then we can see if it's feasible to change | 23:14 |
| === medberry is now known as med_out | ||
| === 64MAAWTQK is now known as wallyworld | ||
| quotemstr | Say I've made commits A, B, and C. How can I go back, change A to A', then apply B and C again? | 23:52 |
| quotemstr | bzr uncommit will destroy B and C, yes? | 23:52 |
| maxb | More like "remove from this branch's history" than "destroy", but essentially yes | 23:53 |
| quotemstr | Basically, something like quilt(1) would be nice. | 23:53 |
| maxb | There's a couple of options, branch A, B, C to another temporary branch, uncommit, commit A', then merge B, commit, merge C, commit | 23:54 |
| quotemstr | Won't those then show up as merge commits instead of real commits? | 23:54 |
| maxb | Or, bzr-rewrite has a 'bzr replay' command for doing mostly that with less typing | 23:55 |
| maxb | They wouldn't show as merge commits if you were effectively cherrypick merging them | 23:55 |
| maxb | i.e. bzr merge -c-2 ../temp-branch | 23:55 |
| quotemstr | Ah. | 23:56 |
| quotemstr | That works. | 23:57 |
| quotemstr | Hrm, loom looks interesting too. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!