| === r0bby_ is now known as robbyoconnor | ||
| jnl | hi, when i pipe bzr log --line to a pager the lines gets chopped off to 78 with (with a "..." at the end), can i avoid this? | 07:57 |
|---|---|---|
| mgz | morning | 08:13 |
| bialix | hi all | 08:14 |
| bialix | hi jelmer | 08:14 |
| jnl | n/m, looks like bug in old version (2.0) | 08:22 |
| matttbe | Hello | 08:41 |
| matttbe | Recently, I wanted to update the version of Cairo-Dock in Ubuntu. | 08:41 |
| matttbe | I updated my branch to be synced with the main branch (bzr uncommit -r 25; bzr revert; bzr pull # => now on rev 26) and used merge-upstream option (bzr mu --version "3.0.2" --distribution=quantal). | 08:41 |
| matttbe | On Launchpad, I can see that the previous rev (26) has the same rev ID on my new branch (lp:~cairo-dock-team/ubuntu/quantal/cairo-dock/3.0.2) and on the main branch (lp:ubuntu/cairo-dock). | 08:41 |
| matttbe | But if someone tries to merge my new branch into the ubuntu branch, it seems there is a conflict. => https://code.launchpad.net/~cairo-dock-team/ubuntu/quantal/cairo-dock/3.0.2/+merge/111020 | 08:41 |
| matttbe | Note that on rev 26, there is a patch (in debian/patches) which was applied but the diff (available in LP) seems correct except that if you have a look to the conflict, it seems the previous patched was unapplied before merging: | 08:41 |
| matttbe | This is what I can find in src/gldit/cairo-dock-callbacks.c: | 08:41 |
| matttbe | <<<<<<< TREE | 08:41 |
| matttbe | if (pDock->iSidTestMouseOutside == 0 && pEvent) //(...) | 08:41 |
| matttbe | ======= | 08:41 |
| matttbe | if (pDock->iSidTestMouseOutside == 0 && pEvent && ! pDock->bHasModalWindow) // (...) | 08:41 |
| matttbe | >>>>>>> MERGE-SOURCE | 08:41 |
| matttbe | But we can find this diff on rev 26: | 08:41 |
| matttbe | - if (pDock->iSidTestMouseOutside == 0 && pEvent) // (...) | 08:41 |
| matttbe | + if (pDock->iSidTestMouseOutside == 0 && pEvent && ! pDock->bMenuVisible) // (...) | 08:41 |
| matttbe | Should I have to remove my previous patches, commit and then use bzr merge-upstream? | 08:42 |
| mgz | matttbe: have you had any luck getting an answer? | 09:47 |
| matttbe | mgz: no | 09:48 |
| matttbe | mgz: but if we use 'bzr pull' instead of 'bzr merge', we don't have this bug because it seems patches are unapplied just before: | 09:48 |
| matttbe | > Unapplying quilt patches to prevent spurious conflicts | 09:48 |
| mgz | right, my guess would be one branch was done with the quilt plugin enabled and the other wasn't | 09:49 |
| mgz | but I don't understand from yuor description if your branch or lp:ubuntu/cairo-dock has the quilt patches applied in tree | 09:50 |
| matttbe | yes, lp:ubuntu/cairo-dock has quilt patches applied in tree | 09:50 |
| matttbe | and these patches are removed in the new one | 09:51 |
| mgz | in the diff I see the patches are completely removed, right? | 09:51 |
| matttbe | yes | 09:51 |
| mgz | were they merged upstream? | 09:51 |
| mgz | or just dropped? | 09:52 |
| matttbe | merged upstream | 09:52 |
| mgz | okay | 09:52 |
| * mgz ponders | 09:52 | |
| matttbe | but it seems the problem is that they are merge upstream but the same line has been modified too | 09:52 |
| mgz | so, either you can play with the quilt options in bzr-builddeb and see if one of them helps, | 09:56 |
| mgz | or just do the merge locally, resolve the conflict and push it? | 09:56 |
| mgz | jelmer may have better ideas. | 09:56 |
| matttbe | note that in lp:ubuntu/cairo-dock, there is a patch (which is applied in tree) to remove one line in: src/gldit/cairo-dock-keybinder.h | 09:56 |
| matttbe | Now this patch is no longer needed (merged upstream) but if we use 'bzr merge', the line is still there | 09:56 |
| matttbe | yes, I merge it locally, resolve conflict, revert the wrong change in src/gldit/cairo-dock-keybinder.h and push it on another branch | 09:57 |
| * jelmer reads up on the last few minutes of converstaion.. | 10:02 | |
| matttbe | but if we use 'bzr pull' we don't have any problem (but if the sponsor want to merge this branch just to modify the ubuntu version in debian/changelog and push only one rev, it's not so easy and he has to check that all files are corrects) | 10:02 |
| matttbe | maybe it can be interesting to unapply patches just before merging (if it's possible) | 10:02 |
| jelmer | matttbe: bzr-builddeb can do that | 10:02 |
| matttbe | jelmer: but who has to do that? the sponsor? | 10:03 |
| jelmer | matttbe: matttbe whoever does the merge | 10:04 |
| matttbe | ok, thank you! | 10:04 |
| jelmer | matttbe: the bzr-builddeb has some documentation; you'll need a newer version of bzr-builddeb | 10:06 |
| matttbe | jelmer: I've the version 2.8.4 from Ubuntu Quantal repos | 10:08 |
| jelmer | that should be new enough | 10:11 |
| === jml is now known as jml_ | ||
| === jml_ is now known as jml | ||
| matttbe | jelmer: but what should the sponsor has to use? I used 'bzr merge-upstream' and everything was ok for me (but not for the sponsor) | 10:21 |
| === zyga-afk is now known as zyga | ||
| matttbe | I see that now 'bzr mu' unapplied patches and it's great but then, the sponsor has to use 'bzr pull', or is there another solution? | 10:22 |
| jelmer | matttbe: if you've done the merge then the sponsor shouldn't have to do it again | 10:24 |
| === yofel_ is now known as yofel | ||
| matttbe | jelmer: except if he want to do modifications, no? e.g. the current Ubuntu version in debian/changelog is set as UNRELEASED (or should I've to set modify it but I thought that it had to be done by the sponsor) | 10:28 |
| jelmer | matttbe: sure, but he shouldn't get conflicts that you (or bzr-builddeb for you) resolved earlier | 10:35 |
| matttbe | yes but he doesn't have this conflicts if he uses 'bzr pull' because 'quilt pop -a' command is automatically launched. This is why I wonder why patches are not automatically unapplied if we use 'bzr merge'. | 10:40 |
| matttbe | But if you say that the sponsor has to use 'bzr pull' and not 'bzr merge', I can understand. Now I know what the sponsor has to do with my branch ;) | 10:40 |
| jelmer | matttbe: I'm not sure I follow - 'bzr merge' already should be automatically unapplying patches for '3.0 (quilt)' during a merge | 10:41 |
| matttbe | jelmer: yes, you're right, sorry. But if it removes patches, it will not see that patches have been removed and then the diff is wrong. | 10:46 |
| matttbe | jelmer: Or is it maybe simply because patches shouldn't be applied in tree? | 10:46 |
| jelmer | matttbe: What do you mean with "But if it removes patches, it will not see that patches have been removed and then the diff is wrong" ? | 10:46 |
| jml | I'm using 'bzr branch lp:foo' in an automated environment. Is there any way to shut up the warning about launchpad-login? | 10:47 |
| jml | I guess I can just specify the http url. | 10:47 |
| jelmer | jml: specifying the http URL is probably easiest | 10:48 |
| jelmer | there might me some warning suppressing config option too, though I'm not sure about the name.. | 10:48 |
| jelmer | jml: no, doesn't look like we have a way to silence that message~ | 10:48 |
| jml | jelmer: thanks. | 10:49 |
| matttbe | jelmer: on lp:ubuntu/cairo-dock, there is a patch (applied in tree) which removes one line in one file. With the new version, we can remove this patch (merged upstream). On my branch, 'bzr mu' has unapplied this patch and I've removed it (with 'quilt delete -r'). | 10:57 |
| matttbe | But if the sponsor merge my branch, the line has not been removed. | 10:57 |
| matttbe | It's maybe because if this patch is unapplied just before merging, the line is still in the tree (ok) and then, if we merge this branch with no applied patches with my new branch, this line will remain because on my branch, I don't have changed this file (if we have a look to the diff file, we don't see any modification about this line because I don't modify between the two revisions) | 10:57 |
| matttbe | Sorry, I'm not sure that it's understandable :) | 10:57 |
| matttbe | (and I don't know how bzr works to do the merge) | 10:57 |
| jelmer | matttbe: is the change also gone from the working tree, and from the .pc directory (quilt should take care of that) | 11:10 |
| matttbe | after the merge (my new branch => lp:ubuntu/cairo-dock), the '.pc' directory is empty and debian/patches only contain 'series' (which is empty) | 11:12 |
| matttbe | in fact, I guess I'll have the same result if I do that: | 11:16 |
| matttbe | quilt pop -a ## Now the line is reverted back in the corresponding file | 11:16 |
| matttbe | bzr commit ## just to do the merge or I have to use bzr merge --force | 11:16 |
| matttbe | bzr merge my_new_branch ## the line is still there | 11:16 |
| matttbe | (yes, I confirm I've the same problem if I launch these commands) | 11:18 |
| === jelmer is now known as Guest22079 | ||
| === jdobrien is now known as webm0nk3y | ||
| === webm0nk3y is now known as jdobrien | ||
| alf_ | james_w: jelmer_: Hi! I am trying to merge a new version of a package with merge-upstream, but it complains that "bzr: ERROR: Upstream version 2012.06 has already been merged." . I had previously merged 2012.06 and commited, but then reverted/uncommitted the changes. | 13:42 |
| james_w | alf_, run bzr tags and you will see an upstream-2012.06 tag? | 13:43 |
| james_w | "bzr tag --delete upstream-2012.06" and you should be good to merge again | 13:43 |
| alf_ | james_w: Right, "upstream-2012.06 ?" . I did that and now I am getting: bzr: ERROR: Unable to find the tag for the previous upstream version, 2012.06, in the branch: upstream-2012.06 | 13:45 |
| james_w | alf_, hmm | 13:45 |
| james_w | alf_, do you have a 2012.06 tag hanging around as well? | 13:46 |
| alf_ | james_w: no | 13:46 |
| james_w | alf_, hmm | 13:46 |
| james_w | alf_, and I guess debian/changelog has no mention of 2012.06 any more? | 13:47 |
| alf_ | james_w: aha, I made an intermediate commit to update the debian/ dir and have a 2012.06 entry in the debian changelog as UNRELEASED. | 13:48 |
| james_w | alf_, that will be it then | 13:49 |
| alf_ | james_w: ok, so how do I get around that? Do I have to uncommit? | 13:51 |
| james_w | alf_, if you remove that entry from the changelog and commit then it should work | 13:51 |
| alf_ | james_w: so 1. remove that entry, commit, then 2. merge-upstream ? | 13:52 |
| james_w | alf_, I think so | 13:52 |
| alf_ | james_w: it worked, thanks! | 13:53 |
| jam1 | james_w: I replied to jml's message about upgrading jubany. I imagine we'll want both you and vila around if/when we deploy to Jubany. | 13:55 |
| jam1 | What time do you usually start in the AM? | 13:55 |
| jam1 | (utc) | 13:55 |
| === jam1 is now known as jam | ||
| james_w | jam, 1300 | 13:56 |
| jam | james_w, so about 1hr ago, right? | 13:56 |
| james_w | jam, yeah | 13:57 |
| vila | jam: huh ? | 13:57 |
| jam | vila: see the thread about upgrading udd | 13:58 |
| jam | I think it is reasonable to try to roll out storm again, and if it fails, just roll it back. | 13:58 |
| jam | But we don't have to be afraid of that step, as long as we can catch it and roll it back quickly if it starts failing. | 13:58 |
| * vila blinks | 13:58 | |
| jam | and if we get it working, then we can think more sanely about a next step. | 13:58 |
| jam | vila: why do you think it is unsafe to *try* a storm rollout? | 14:00 |
| vila | because it failed at last attempt ? | 14:00 |
| vila | corrupting the db ? | 14:01 |
| vila | maxb knows the details, I've just read his emails | 14:01 |
| jam | vila, james_w: did it actually corrupt the db? I realize some bits got deadlocked. | 14:01 |
| jam | and it wouldn't be rolling out the exact code, it would be with an update to avoid the increased isolation level. | 14:01 |
| jam | I don't see a point to rolling out the exact thing we know was failing. | 14:01 |
| james_w | it did write some bad data due to the db due to storms behaviour regarding str/unicode | 14:02 |
| jam | james_w: was that part of the fixes from max? | 14:02 |
| james_w | but I plan to fix the instance Max found and do another pass looking for other cases | 14:02 |
| jam | (fixes unrelated to locking to quote you) | 14:02 |
| james_w | jam, we haven't yet fixed the last instance he found | 14:02 |
| james_w | but we fixed some other things before rolling back | 14:02 |
| jam | so that would be a blocker, certainly. | 14:02 |
| james_w | yep | 14:03 |
| === zyga is now known as zyga-food | ||
| jam | james_w: so another possible transition plan would be to wait until we get some sort of staging system setup. | 14:04 |
| vila | +1e6 | 14:04 |
| jam | I feel like the timeline on that is a bit... unbounded | 14:04 |
| vila | I thought a basic test was conducted on ec2 ? | 14:05 |
| jam | if it isn't, then it 'races' with finishing the unicode/str fixes | 14:05 |
| jam | if we can get a staging set up first, or close to the same time, then doi t | 14:05 |
| jam | it | 14:05 |
| vila | not to mention the pristine-tar failures ? | 14:05 |
| jam | vila: isn't pristine-tar 100% orthogonal to this? | 14:05 |
| vila | when it comes to deployment, no | 14:06 |
| james_w | a staging system that would do everything except push the branches back? | 14:06 |
| jam | james_w: something like that | 14:06 |
| jam | I would have some concern that 'doing work but throwing it away' might thrash (if say the primary is stopped for a while) | 14:06 |
| jam | james_w: but we really need a place we can test things that isn't prod | 14:06 |
| james_w | yes | 14:07 |
| vila | james_w: as long as you start with a copy of the dbs | 14:07 |
| vila | james_w: pushing does some more db updates but.. well, if the rest is ok, you'll know what to expect | 14:08 |
| jam | james_w: do you have any idea of a timeline for the unicode fixes? I imagine if you felt there was no way to get the code deployed, it wasn't worked on as a priority. :) | 14:08 |
| jam | vila, james_w: So if we feel there is a reasonable recovery step (snapshot the dbs first, know exactly what to roll back to), it feels like we can at least start to get forward momentum. And if we can get things moving, then we can *improve* stuff. | 14:09 |
| jam | jelmer_: are you still doing up-merges? | 14:11 |
| james_w | vila, what bd operations does the push do? | 14:11 |
| james_w | db | 14:11 |
| jelmer_ | jam: nope, I'm done | 14:11 |
| james_w | it won't test things like filing merge proposals, or the push code | 14:11 |
| jam | jelmer_: how are the lp branches coming? | 14:11 |
| james_w | and makes the bookeeping a bit off | 14:11 |
| james_w | is that an issue? | 14:11 |
| vila | james_w: I thought the revids were recorded after pushing ? (That's a gut feeling not from reading the code) | 14:12 |
| jelmer_ | jam: I was struggling with some tests yesterday, am currently reviewing | 14:13 |
| jam | jelmer_: as in doing reviews for others? Or getting the branches reviewe | 14:13 |
| jam | d? | 14:13 |
| james_w | vila, ah yes, sorry, I was reading the wrong bit | 14:13 |
| vila | james_w: at least when I test locally, doing the same import without pushing seems to redo the same steps | 14:13 |
| james_w | yeah | 14:13 |
| james_w | I see what jam means about thrashing now | 14:14 |
| james_w | jam, indeed, I hadn't done the fixes because it wasn't clear what the plan was | 14:14 |
| jelmer_ | jam: reviewing for others | 14:14 |
| james_w | jam, they are just a couple of hours work though | 14:14 |
| jam | anyway, I'm at EOD (have to go take my son to swimming), but I'd like us to hash out a quick 'next steps' and see what can get the ball moving again. | 14:18 |
| james_w | I'll followup on the mailing list | 14:26 |
| === zyga-food is now known as zyga | ||
| === jordan_ is now known as jordan | ||
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| LeoNerd | FSCKING REBASE! | 18:26 |
| LeoNerd | Can anyone tell me why I have to 'bzr unbind' before it'll actually work? I hate having to do this | 18:26 |
| LeoNerd | Otherwise it immediately claims that bzr: ERROR: Bound branch BzrBranch6(file:///home/leo/src/perl/IO-Async.TASKS/) is out of date with master branch RemoteBranch(bzr+ssh://cel/var/bzr/leo/perl/IO-Async.TASKS/). | 18:27 |
| jelmer_ | LeoNerd: why would you want to use rebase with a checkout? | 18:30 |
| LeoNerd | Because I never do anything that isn't in a checkout | 18:30 |
| LeoNerd | I don't trust my ability not to lose my laptop or crash its disk, so everything is backed up on my server | 18:30 |
| LeoNerd | Currently I bzr unbind; bzr rebase ..... bzr bind :bound; bzr push --overwrite :bound | 18:31 |
| jelmer_ | LeoNerd: generally you would make a checkout of the master branch | 18:38 |
| jelmer_ | LeoNerd: and it's pretty uncommon to rewrite branches in the main project branch | 18:38 |
| LeoNerd | Hrm? It's not the main branch. It's a feature branch | 18:39 |
| jelmer_ | anyway, what you're trying to do isn't really wrong but it's not very common either | 18:39 |
| LeoNerd | I rebase it after every main release | 18:39 |
| === zyga is now known as zyga-afk | ||
| CodeNinjaSD | Does bazaar support E-mail messages to one or more addresses should be generated when a change is committed. Format of e-mail may change (e.g., doc committer committing to src tree) | 18:56 |
| CodeNinjaSD | What about sthe ability to attach searchable/annotated tags, other than revision number to code artifacts | 19:00 |
| gour | /c | 19:03 |
| psusi | I have noticed that I made a slight error a few commits back. With git, I would fix the error, commit it, then rebase -i to sqash that commit back into the previous one. How can I do this with bzr? | 19:16 |
| psusi | or maybe pop the last few commits off the branch into patch files, fix the errored commit, then reapply the patches | 19:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!