| maxb | Could I have a copy of jubany:/srv/package-import.canonical.com/new/logs/packages/libfile-touch-perl please? | 00:00 |
|---|---|---|
| james_w | maxb, http://paste.ubuntu.com/626940/ | 00:12 |
| maxb | thanks | 00:12 |
| * maxb stares at the log and wonders what changed that it now errors | 00:16 | |
| poolie | hi amanica | 00:22 |
| maxb | Hmm. I'm totally failing to be able to reproduce the "727 packages failed with key AssertionError:<module>:main:find_unimported_versions" issue | 00:33 |
| maxb | Is UDD's meta.db small enough that I could download a copy? | 00:33 |
| poolie | i'll look | 00:58 |
| spiv | Hi maxb | 00:59 |
| poolie | hi spiv! | 00:59 |
| maxb | Hi | 00:59 |
| spiv | Thanks for digging into those failures, it's a shame to have slipped so far backwards :( | 00:59 |
| poolie | maxb: 153MB; so probably yes | 00:59 |
| maxb | poolie: Great - maybe you could copy it into the www directory? | 00:59 |
| poolie | yup | 01:00 |
| maxb | or symlink could work too, I guess | 01:00 |
| poolie | done | 01:00 |
| maxb | downloading | 01:02 |
| maxb | got it | 01:04 |
| maxb | Grr. It works fine here | 01:19 |
| maxb | Given the importer queue is empty, I propose a ./requeue_package.py --all-of-type libfile-touch-perl - even though a previous single requeue failed again, the importer might as well be exhaustively checking each failure still fails again, given I'm totally unable to reproduce the failure, even having supposedly used identical data | 01:20 |
| spiv | maxb: ok, I'll kick that off | 01:38 |
| spiv | maxb: if that fails, I guess we start narrowing down version differences and the like :/ | 01:39 |
| * maxb crosses fingers and hopes the problem disappears as mysteriously as it arrived | 01:39 | |
| spiv | (in the software on jubany, that is) | 01:39 |
| spiv | Requeued, let's see what happens. | 01:40 |
| maxb | Hmm... this is odd. I see a different testament sha in the DB to what bzr testament reports | 01:44 |
| maxb | but that still should not be able to cause this failure modoe | 01:47 |
| poolie | thanks for the reviews gz | 01:50 |
| poolie | hi spiv; can you comment on my mp about del methods? | 01:50 |
| spiv | maxb: huh | 01:50 |
| spiv | maxb: so some of those failures are indeed clearing :/ | 01:50 |
| spiv | e.g. “Success libfile-touch-perl: Nothing new” | 01:51 |
| spiv | poolie: sure | 01:51 |
| james_w | maxb, workaround-fix merged and rolled out, thanks for the fix | 01:56 |
| maxb | thanks | 01:58 |
| maxb | spiv: Hmm. Mysterious indeed. I can only conjecture that my first broken version of the workaround managed to trigger some insanely counter-intuitive behaviour | 01:59 |
| poolie | spiv, thanks for that | 02:08 |
| spiv | np | 02:09 |
| poolie | i'm surprised bug 659590 could be reliably fixed by relying on del | 02:09 |
| ubot5 | Launchpad bug 659590 in bzr (Ubuntu Lucid) "[SRU] dput sftp upload hangs after all files successfully uploaded" [Undecided,Triaged] https://launchpad.net/bugs/659590 | 02:09 |
| poolie | perhaps it's an object that's only ever refcounted at present | 02:09 |
| poolie | perhaps i should revert that one change, and then file a separate bug to deterministically close them? | 02:10 |
| spiv | I think that would be safest. | 02:10 |
| spiv | If this were the start of the 2.5 release cycle rather than near the end of the 2.4 cycle I'd be more tempted to land it and see what the fallout is | 02:11 |
| spiv | I'm not sure that removing that __del__ would necessarily cause a regression along those lines, but given that we have had surprises in this area before my instinct is to be a little conservative. | 02:12 |
| poolie | really that bad? | 02:12 |
| poolie | hm | 02:13 |
| poolie | i'm glad i asked then | 02:13 |
| spiv | Hmm, it may be interesting to note that bzrlib.transport.ssh has something similar, but with weakref callbacks | 02:14 |
| spiv | i.e. makes sure to try kill the SSH subprocess when the corresponding object is GCed (if it hasn't already) | 02:16 |
| poolie | hm | 03:57 |
| === wallyworld___ is now known as wallyworld | ||
| Kamping_Kaiser | hi all. trying to update a pakage with bzr merge-upstream and it tells me i haven't got a tag on the branch upstream-0.2011. how can i tag that branch? help on branches/branch/tag/tags didn't clear it up for me | 05:27 |
| KombuchaKip | Is there any way to get the branch revision number, e.g. just 43, as opposed to something like 43 kip@thevertigo.com-20110612001024-3tncb5tbxh30d7zx when one runs bzr revision-info? | 05:33 |
| Kamping_Kaiser | bzr revno? | 05:34 |
| KombuchaKip | Kamping_Kaiser: Thank you. I didn't see that switch. | 05:36 |
| Kamping_Kaiser | KombuchaKip: np | 05:36 |
| spiv | Kamping_Kaiser: 'bzr tag -r REV TAG_NAME' sets a tag on a branch | 05:36 |
| spiv | Kamping_Kaiser: specifically it sounds like bzr merge-upstream is looking for a tag called "upstream-0.2011" | 05:37 |
| Kamping_Kaiser | spiv: the error implies i have multiple branches. could that be the case, or is it just fooling with me? | 05:37 |
| spiv | I think you may be misreading the error | 05:38 |
| Kamping_Kaiser | quite possible. full message is 'bzr: ERROR: Unable to find the tag for the previous upstream version, 0.20110614, in the branch: upstream-0.20110614'. i don't know how to tell if i'm in that branch; bzr info doesn't tell me | 05:40 |
| spiv | Kamping_Kaiser: Right. I see the confusion. | 05:42 |
| spiv | Kamping_Kaiser: "upstream-0.20110614" is the tag name it is looking for | 05:42 |
| spiv | (Which would be the tag corresponding to upstream version 0.20110614) | 05:42 |
| Kamping_Kaiser | spiv: thanks for clarifying. have to say, thats a rather confusing message :/ | 05:43 |
| spiv | Apparently so! | 05:44 |
| spiv | I'll file a bug about that. | 05:44 |
| Kamping_Kaiser | spiv: thanks. if you could let me know the number that would be great :) | 05:45 |
| spiv | bug 797518 | 05:47 |
| ubot5 | Launchpad bug 797518 in bzr-builddeb "Confusing error from merge-upstream when upstream tag is not found" [Undecided,New] https://launchpad.net/bugs/797518 | 05:47 |
| Kamping_Kaiser | thnks | 05:48 |
| Kamping_Kaiser | *thanks | 05:48 |
| Kamping_Kaiser | hi all, another merge-upstream question. while using merge-upstream it deleted my debian/ directory. is this, uh, normal? http://paste.debian.net/119879/ am i missing more tags? (bzr help merge-upstream doesn't mention tags at all) | 06:29 |
| spiv | Kamping_Kaiser: I don't think that's normal, but I don't know enough about bzr-builddeb to suggest how to debug :( | 06:44 |
| Kamping_Kaiser | spiv: np. i'll hang around, hopefully someone else will wander by | 06:45 |
| spiv | Kamping_Kaiser: hmm, although a quick guess might be that the debian/ directory is incorrectly part of the previous upstream-* version? | 06:45 |
| Kamping_Kaiser | spiv: let me try retagging to check | 06:47 |
| spiv | Kamping_Kaiser: or just inspect the contents (e.g. with 'bzr qlog')? | 06:47 |
| Kamping_Kaiser | spiv: qlog doesn't appear to be a bzr command | 06:49 |
| spiv | Kamping_Kaiser: it's part of the qbzr plugin | 06:49 |
| spiv | ('bzr viz' from the bzr-gtk plugin is nearly as good) | 06:50 |
| Kamping_Kaiser | ah, don't have that plugin | 06:51 |
| Kamping_Kaiser | spiv: looks like you are correct - it wants the upstream release tagged, not the package release. | 06:55 |
| spiv | Kamping_Kaiser: yes, the upstream-* tags are for tagging upstream versions | 06:55 |
| spiv | (Although I think normally you'd rely on merge-upstream or import-upstream to create those revisions and tags for you) | 06:56 |
| Kamping_Kaiser | spiv: its probably because i crated the repo with dh-make manually, instead of bzr dh-make (which i just discovered) | 06:57 |
| vila | morning all ! | 08:03 |
| fullermd | What, again? We just survived the last one... | 08:32 |
| jam | morning all | 08:38 |
| mgz | will try to find some time for coding today, about to go offline though | 08:52 |
| Riddell | spiv: can't hear you | 09:05 |
| * jelmer waves | 09:05 | |
| spiv | Software. It's marvellous. | 09:05 |
| jelmer | should we try skype? | 09:06 |
| Riddell | jelmer: mumble still not happy for you? | 09:06 |
| Riddell | is vila around? | 09:07 |
| vila | errk, here I come | 09:07 |
| jelmer | Riddell, not really, trying the audio wizard setup again.. | 09:08 |
| jelmer | \o/ | 09:09 |
| maxb | james_w: Do you remember what the "sleeping to stack" thing the UDD importer does is for? (Sleep for 5 minutes after pushing a dev-focus branch if the push created a new remote branch) Is it, as speculated in the code, obsolete now launchpad doesn't have separate read / write branch areas? | 09:37 |
| spiv | maxb: sounds highly plausible | 09:38 |
| spiv | jelmer, Riddell, vila, jam: g'night! | 09:38 |
| vila | spiv: cu ! | 09:38 |
| jelmer | Riddell, one of the bugs associated with it is bug 465517 | 09:42 |
| ubot5 | Launchpad bug 465517 in bzr (Ubuntu Natty) "'bzr push' copies the entire repository if there is a BzrDir but not a Branch" [High,In progress] https://launchpad.net/bugs/465517 | 09:42 |
| Riddell | jelmer: unapproved queue is fairly long, hasn't been processed in a week, I guess you can try politely pinging members of ~ubuntu-sru | 09:48 |
| jelmer | Riddell: thanks - just pinged pitti in #ubuntu-devel | 09:48 |
| vila | jelmer: I forgot to ask, which bzr versions did you deploy on lp ? | 10:19 |
| jelmer | vila: 2.3.3 | 10:45 |
| vila | jelmer: thks | 10:45 |
| jelmer | vila: I'm looking forward to the day we can deploy 2.4 | 10:47 |
| vila | yeah, happens every 6 months ;) | 10:48 |
| === hunger_ is now known as hunger | ||
| james_w | maxb, experimentation showed that if it slept for about the latency of copying branches between the two areas they still failed to stack | 14:43 |
| james_w | maxb, no-one had any explanation for why it was happening, so I left it at 5 minutes which seemed to avoid the issues | 14:43 |
| === zyga is now known as zyga-food | ||
| spiv | james_w: so now that there's no copying to wait for that sleep is probably unnecessary then? | 15:05 |
| james_w | spiv, the conjecture at the time was that it wasn't the split that was causing it, but no alternative explanations were forthcoming | 15:06 |
| spiv | james_w: hmm. Still tempting to try removing it and see if the bug and/or trigger is no longer present... | 15:08 |
| james_w | yeah | 15:09 |
| spiv | Or maybe it if it still fails it might be more obvious why | 15:09 |
| spiv | And with that optimistic thought I'm off to bed! | 15:10 |
| === zyga-food is now known as zyga-afk | ||
| achiang | hello, looking for some help on how to recover from a pretty bad mistake. :-/ i had 2 branches, A and B. for a long time, i've been making changes in A, and then merging/pulling into B. i just made a mistake of pulling B back into A, and want to undo that. | 15:33 |
| achiang | even worse is that both A and B are committed and pushed into LP. | 15:34 |
| maxb | This doesn't sound too bad | 15:50 |
| maxb | The potentially slightly tricky part is that you will have to identify the old tip of A by browsing the revision history and figuring it out | 15:51 |
| maxb | Are A and B public? Sometimes it's easier to explain by just saying "look at these branches" | 15:52 |
| achiang | no, A and B are not public, unfortunately. | 15:54 |
| maxb | Alright. | 15:54 |
| maxb | First thing is - we need to be clear on whether you pulled/pushed B into A, or merged it | 15:55 |
| maxb | Second, are you familiar with qbzr and "bzr qlog" ? | 15:55 |
| jam | have a good night everyone | 15:56 |
| achiang | i definitely did a 'bzr pull B', so i do not have a clean merge point. :( | 15:56 |
| maxb | OK, so, start "bzr qlog", and look back in the history for the last merge of A into B - this should allow you to identify the revision that should be the correct tip of A | 15:58 |
| achiang | maxb: ah, what i do have is good versioning | 15:58 |
| maxb | james_w: Thanks - do you know if it has been revisited at all since the "two areas" design was changed to a single area? It seems likely that this behaviour could be removed now, for significant simplification of the code. | 15:59 |
| achiang | so, my A version string looks like: 0.4~bzr457 | 15:59 |
| achiang | and my B version string looks like 0.4~bzr457versionB | 15:59 |
| james_w | maxb, it has not been revisited | 16:00 |
| achiang | so, i think that r457 in A is the last time i branched off B | 16:00 |
| achiang | or rather, r457 in A is the last time i merged it into B | 16:00 |
| maxb | achiang: Ok, that will help in confirming that you have found the right revision, but you'll still need to hunt through the history. If you start "bzr qlog", and look back through the merge commits, it should hopefully be reasonably easy to locate revisions which are intended to be part of A | 16:01 |
| achiang | maxb: hm, actually life is a little easier -- on another machine, i have a good copy of A before my mistake | 16:08 |
| maxb | achiang: OK, so once you have convinced yourself that it is not missing any revisions that should be there, you can just "bzr push --overwrite" it to other places where it needs to be | 16:11 |
| achiang | maxb: ok, i'll try that | 16:13 |
| achiang | maxb: is there a way to diff branches at the revision level? | 16:16 |
| vila | achiang: bzr qlog branchA branchB | 16:21 |
| vila | achiang: or bzr qlog branchB branchA | 16:21 |
| vila | generally you put the most inclusive one first (trunk) | 16:22 |
| achiang | hm, thanks | 16:23 |
| maxb | Some of the older UDD branches are... not very pretty | 17:00 |
| maxb | scala has somehow managed to end up with separate (though related) upstream revisions in ubuntu and debian, and three separate revisions for each version, one in unstable, one in testing, and one in ubuntu | 17:01 |
| maxb | Despite never having had an ubuntu delta | 17:01 |
| * jelmer waves | 17:20 | |
| apw | can anyone explain why bzr moves things to .moved when merging? | 17:26 |
| vila | apw: bzr help conflict-types | 17:27 |
| vila | apw: but in a nutshell, I suspect you're running into a parallel import ? | 17:28 |
| vila | apw: i.e. do you have a few .moved files or a huge number of them ? | 17:28 |
| apw | i have a world of them, and the importer is somehow making the kind of mess which reintroduces the collission for every upstream merge, and it is getting on my nerves | 17:29 |
| vila | :-/ | 17:29 |
| apw | vila, is there some way i can say ... these files are the same file really, treat them as a textual collission | 17:30 |
| vila | apw: so, the root issue is that bzr use file ids to track renames and that works well except... when the "same" files received different IDs | 17:30 |
| vila | apw: not yet no, sorry, but it's a know issue for udd and we should fix it (and will) | 17:31 |
| apw | vila, so i should be using git to do my merge then, git-bzr or something, as that will not make the same mistake | 17:31 |
| vila | known | 17:31 |
| apw | vila, anyhow thanks for the info that is helpful | 17:31 |
| vila | I don't know how bzr-git handle that | 17:31 |
| apw | well git doesn't track files, so its merge would be what i want, just texttual | 17:32 |
| vila | apw: but yes, git doesn't have this problem | 17:32 |
| vila | yup | 17:32 |
| vila | apw: what is the package you're having an issue with ? | 17:33 |
| jelmer | bzr-git won't help with that | 17:33 |
| apw | vila, module-init-tools | 17:33 |
| apw | jelmer, i atually meant git-bzr in that context | 17:33 |
| apw | jelmer, as in check it out in git, merge it there with its dumber merge, and push it back into bzr | 17:34 |
| vila | maxb: does module-init-tools ring a bell ? | 17:34 |
| jelmer | apw: Ideally bzr's merge would support per-path merging | 17:34 |
| apw | jelmer, well indeed, but as right now what it does is hose my working directory and break my poor mind ... | 17:35 |
| maxb | I have not looked at module-init-tools | 17:35 |
| jelmer | apw: it shouldn't actually be that hard to implement, there just never has been a lot of reasons to implement it | 17:35 |
| apw | vila, so in my problem case the merge seems to have merged some files, ie noticed they are ok, then moved them aside, such that if i take the 'other' side i won't actually get the other side i'll get only like 2 files | 17:36 |
| maxb | Unfortunately I think quite a few of the UDD imports have ended up with differing Ubuntu vs. Debian file-ids | 17:36 |
| apw | maxb, and thats insoluable? as the merge side of things just doesn't work at all when they are like that | 17:36 |
| vila | apw: I don't follow, how do you take the 'other' side ? | 17:37 |
| maxb | It's a tractable problem, but it's most easily solved by throwing away the mangled import and reimporting if there are no non-importer revisions | 17:37 |
| gour | is 2.4 going according to the schedule? | 17:38 |
| apw | maxb, that seems fine, what i don't get is once i have merged them why it doesn't know they are then the same | 17:38 |
| vila | gour: so far, yes | 17:38 |
| vila | 'once I have merged them' How ? | 17:38 |
| apw | vila, i have a tests directory with some files, i merge in a near identicle directoy with the same conents different file id's | 17:38 |
| apw | vila, and i end up with tests/ with one directory in with the one new file from the merge, and everything else in tests.moved. i then say "bzr resolved --action=take-other which to my reading should give me whats in what i am merging and nothing from my local | 17:39 |
| fullermd | But you haven't _merged_ the files, you've just picked one or the other. | 17:39 |
| maxb | OK, so in the module-init-tools case, the problem is that we have the existing oneiric branch which is derived from an import of upstream's git - whereas the existing debian branches are derived from tarball imports | 17:39 |
| apw | vila, but what i get is exactly one file from the other side and nothing else. that seems like a completely erronius resolution | 17:40 |
| vila | apw: argh | 17:40 |
| apw | fullermd, well indeed, but picking the ones from the right place aught to sort out the wrong file ids in my world | 17:40 |
| vila | apw: 1) 'bzr resolve --take-other' *with no path specified* has bugs | 17:40 |
| maxb | So in this case it is uncovering the problem that UDD cannot work for merging changes from Debian if the ubuntu side is tracking one representation of upstream but the debian side is tracking a different one | 17:41 |
| apw | vila, quality software | 17:41 |
| vila | apw: well, I just fixed one today, 'cause I had a bug report ;) | 17:41 |
| vila | apw: what version are you using ? | 17:41 |
| apw | maxb, and i can't fix it can i, not even by careful use of merging | 17:41 |
| apw | vila, whatever version is in natty | 17:42 |
| apw | vila, its hard to know whats a bug and whats meant to work that way when i am in such a pickle | 17:42 |
| vila | 'bzr version' but that's probably 2.3.1 (2.3.3 is currently SRUed) | 17:42 |
| vila | apw: I know | 17:42 |
| maxb | apw: Well, you could, but if you "fixed" the use case of merging from Debian, you would have introduced the equivalent problem for merging from upstream's bzr-git import. | 17:42 |
| vila | apw: I know :-( | 17:42 |
| apw | 2.3.1 indeed | 17:42 |
| vila | apw: there are no known bugs if you use 'bzr resolve --take-other FILE' (at least in trunk) | 17:43 |
| apw | maxb, i assume the problem persists because of how the importer pushed down new versions ... now if i push my branch to the import branch before i upload, it shouldn't stand on my branch at all should it ? | 17:43 |
| maxb | The root cause of failure here is that we have allowed official package branches to be used with non-UDD-importer upstream sources, without realizing and documenting how this breaks the merge workflow | 17:44 |
| apw | maxb, might that let me fix the ids ? | 17:44 |
| gour | vila: good luck with release...it looks it might be an important one | 17:44 |
| apw | maxb, i think module-init-tools was a very early adopter of bzr and so very very likley all the horrors you suspect have happened to it | 17:45 |
| maxb | apw: The importer will honour tagged revisions pushed before uploading if it assesses their content to be essentially the same as the upload | 17:45 |
| apw | so then its down to what 'essentially the same' means ... as i have watched it wack my tagged revisions before | 17:46 |
| maxb | apw: Basically the problem is that someone decided to make lp:ubuntu/oneiric/module-init-tools be a branch derived from upstream's vcs (which is a good idea in general) but without knowing the consequence that it is incompatible with merging from a Debian UDD-imported branch | 17:47 |
| apw | maxb, i suspect it actually was joined there before the importer existed even | 17:47 |
| apw | maxb, so no magic bullet ... just slog t | 17:49 |
| apw | through the conflicts every time, papering over the bugs in resolved ... | 17:49 |
| maxb | Well. If I was doing this merge, I would disregard lp:debian/module-init-tools completely | 17:50 |
| apw | maxb, ok, is there somewhere else i can get the 'contents' and apply it? | 17:50 |
| maxb | I would import the debian .dsc into a local branch and merge that | 17:50 |
| apw | maxb, ok will give that a go, it cannot possibly be any harder | 17:51 |
| apw | maxb, any idea where i'd find that | 17:51 |
| maxb | If we want to continue this style of package maintenance, I'd probably take the opportunity to disentangle from the unwanted debian import whilst we still can, first. | 17:52 |
| maxb | Ah, so is this package maintained in bzr in debian? Looks like it | 17:53 |
| maxb | Right OK | 17:53 |
| apw | maxb, could be, i have managed to merge the package in the sense that i know the real differences from debian and its back to a small set thereof | 17:54 |
| apw | maxb, the plan was to try and push it back to being related in the 'normal way' when i started out | 17:54 |
| maxb | So the nice and tidy way to manage this would definitely be to remove the painful messy 3.13-1ubuntu1 revision before we build any more history on top of it | 17:54 |
| apw | maxb, whatever you think is appropriate | 17:55 |
| maxb | So, here is what I'd do: | 17:56 |
| maxb | * Have a local copy of lp:ubuntu/module-init-tools | 17:57 |
| maxb | * Have a local copy of the Debian packaging branch which Debian is actually using - *not* lp:debian/module-init-tools | 17:58 |
| maxb | * In the ubuntu branch, uncommit the painful merge of 3.13-1ubuntu1 ("bzr uncommit") | 17:58 |
| maxb | * Reconstruct that revision with different ancestry, by first merging the appropriate revision from Debian's bzr ("bzr merge -r 3.13-1 ../local-debian-branch"), then removing all the files, unpacking Ubuntu's .dsc into the tree, and committed | 18:00 |
| maxb | committing | 18:00 |
| maxb | At that point, I'd be well placed to merge 3.16-1 from Debian with bzr helping, rather than fighting me | 18:00 |
| apw | that sounds at least sane | 18:01 |
| apw | so i need to find their upstream branch, | 18:01 |
| apw | hopefully that is in their package | 18:01 |
| apw | maxb, i'll have a go at that and publish something for review | 18:02 |
| maxb | I can try to do what I just described and post exact commands | 18:03 |
| maxb | Hmm, their debian/control lacks Vcs-* fields - naughty | 18:03 |
| apw | maxb, yeah i think i grok your intent and indeed why it makes sense, its finding the debian one which will challenge one | 18:04 |
| maxb | Ask Scott James Remnant? | 18:04 |
| apw | maxb, well i don't think he is maintining the debian side, we have been deviant from them for the longest time | 18:05 |
| maxb | Oh yikes, I have misinterpreted somewhat | 18:05 |
| maxb | "3.12-1" was deceptively a direct upload to maverick apparently, not via debian | 18:06 |
| apw | ahh yes, there was much badness done in the packages history | 18:06 |
| maxb | oh, yuck | 18:06 |
| maxb | erm, right | 18:06 |
| maxb | oh | 18:07 |
| maxb | there's no Debian history in this branch at all | 18:07 |
| apw | whats annoying is i know how to un-fook self here with git, i'd just take the debian import, drop our files on it, merge the history from the current mess branch without taking any files at all and push the result | 18:07 |
| maxb | just Ubuntu history mislabelled with debianlike revisions | 18:07 |
| apw | maxb, yeah this branch is an utter mess, i wonder if i rm'd all the files in the ubuntu one and merged it into a new checkout of the debian one | 18:08 |
| apw | would i get a clean debian one with the ubuntu history still attached but not affecting me ? | 18:08 |
| apw | ie all my files would be the right id's from the import side | 18:09 |
| maxb | Vaguely - I am currently trying to remember how I solved one of these before | 18:09 |
| apw | well perhaps i will go try that | 18:10 |
| apw | and see what bzr vis does after | 18:10 |
| maxb | apw: I think I know what to do now | 18:11 |
| maxb | bzr branch -r 3.13-1 existing-ubuntu-branch reconcile-fileids | 18:11 |
| maxb | cd reconcile-fileids | 18:11 |
| maxb | bzr merge ../existing-ubuntu-branch # which is at 3.13-1ubuntu1 | 18:12 |
| maxb | bzr revert . # Note the final . character in the command | 18:12 |
| maxb | Delete everything but the .bzr dir | 18:13 |
| maxb | Copy in the content from 3.13-1ubuntu1 | 18:13 |
| maxb | bzr diff, briefly check the output looks like the existing ubuntu delta | 18:14 |
| maxb | bzr ci -m "Committing existing Ubuntu 3.13-1ubuntu1 with fileids from Debian UDD branch>" | 18:14 |
| maxb | done | 18:14 |
| apw | maxb, why do i get ids from debian there? as i never mentioned it anywhere? | 18:15 |
| apw | or is that 3.13-1 the real debian one in that case | 18:15 |
| maxb | Yes, that's correct | 18:15 |
| apw | ok will give it a go and see if we can unfook this mess | 18:16 |
| apw | maxb, thanks | 18:16 |
| maxb | I will try these commands too and make sure they actually do what I claim :-) | 18:17 |
| apw | maxb, well it looks sane enough in bzr vis, will try merging it up as well | 18:22 |
| apw | as there is anohter upstream version to merge to as a test | 18:22 |
| maxb | It does appear to have done something approximately sensible | 18:24 |
| apw | maxb, thats doing much more what one might expect, exactly one conflict, where i'd expect one | 18:25 |
| apw | maxb, awsome thank you, that revert . thing is essentially what i would have done in git too | 18:26 |
| maxb | There really ought to be a way to do this without deleting and manually replacing the tree, but I'm having trouble thinking of one right now | 18:26 |
| apw | maxb, but as the history is still attached i can still find everything so i think its ok | 18:27 |
| apw | maxb, and the merge to 3.16-1 has gone exactly as i would expect not just the odd conflict nice ... thanks | 18:43 |
| === zyga-afk is now known as zyga | ||
| === yofel_ is now known as yofel | ||
| dash | i'm getting a lovely 'checksum mismatch' error when trying to pull from an svn repository. anything i can do to diagnose/work around this, or is cloning a fresh branch outside the shared repo my best bet? | 22:56 |
| poolie | dash, hi, i suggest you file a bug with details and then branch into a different repo to see if that helps | 23:03 |
| maxb | dash: A fuller view of the error message would help a useful answer | 23:03 |
| dash | thanks | 23:03 |
| dash | it's just "bzr: ERROR: checksum mismatch: '0fa285e09d5f0258f68f2bd3c95474af' != '3f62e97923e50d938a211951ff56e753' in mysvndir/trunk:22246" | 23:04 |
| dash | no traceback | 23:04 |
| maxb | Please check your ~/.bzr.log - I think the traceback will be saved there | 23:04 |
| poolie | hi maxb | 23:07 |
| maxb | hello | 23:08 |
| * Riddell politely reminds spiv to review his bzr-explorer merges sometime today | 23:46 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!