| === Ursinha is now known as Ursinha-afk | ||
| _habnabit | http://www.habnabit.org/bzr-graph3.png <- out of curiosity, why is it that most of the merged revisions are numbered 85.[1-5].X? Merging from trunk (which is what it's clustered around) doesn't seem to reset it. | 01:40 |
|---|---|---|
| _habnabit | I'm unclear on how revision numbers are assigned from a merge. | 01:40 |
| _habnabit | (My guess it it's using the earliest shared parent revision contained in the branch.) | 01:45 |
| maxb | _habnabit: <mainline revno branched from>.<sequential numbering of branches off that mainline point>.<position on that branch> | 01:47 |
| _habnabit | maxb, so the only way to reset the first number is to make a new branch? | 01:48 |
| maxb | yes.... though it's just an arbitrary number, does it matter? | 01:48 |
| _habnabit | I'm just curious. | 01:48 |
| _habnabit | I don't care about it. | 01:48 |
| lifeless | _habnabit: if you pull from trunk, it will reset all your local revnos to be identical to those in trunk | 01:50 |
| _habnabit | Aha. | 01:50 |
| lifeless | but you can only do that after trunk has merged from you | 01:50 |
| _habnabit | Right. | 01:50 |
| maxb | wtf, we have an intermittent test failure in bzr 2.3b4 in bzr-beta-ppa :-( | 01:56 |
| spiv | maxb: :( | 01:56 |
| maxb | list emailed | 02:02 |
| maxb | I'm baffled | 02:02 |
| jubei__ | is there a way to check if there are changes to a repository before running bzr pull ? | 03:25 |
| bob2 | bzr missing | 03:26 |
| jubei__ | awesome, thanks | 03:33 |
| rocky | is it possible to create branch X from a subdir in mybranc? say mybranch has subdirs sd1 and sd2 and i want to produce a branch that only consists of sd1 stuff... | 03:58 |
| bob2 | you can branch, delete, move. or there's the split stuff, but I don't know how usable that is atm | 03:59 |
| spiv | maxb: replied; known issue, fixed upstream and workaround just landed in lp:bzr | 04:08 |
| maxb | gosh | 04:12 |
| maxb | how obscure | 04:12 |
| spiv | maxb: on the plus side, it wasn't our fault ;) | 04:14 |
| vila | hi all | 07:22 |
| vila | poolie: hey ! the poolie_droid sounded like a definitive SSD failure :-} | 07:31 |
| vila | maxb: fix landed, I filed bug #686008 as soon as I saw the daily builds failures, sorry I didn't think to warn you explicitly | 07:33 |
| ubot5 | Launchpad bug 686008 in Bazaar "TypeError: 'member_descriptor' object is not callable" [Medium,In progress] https://launchpad.net/bugs/686008 | 07:33 |
| vila | maxb: ... obscure it not fair for this, it's far worse than that (and my English is not good enough to find the fait word there ;) | 07:35 |
| vila | s/fait/fair/ | 07:35 |
| vila | maxb: even knowing what was happening and why I couldn't write a *reliable* reproducing test :-/ See https://code.edge.launchpad.net/~vila/bzr/686008-spurious-https-failure/+merge/42969 for details | 07:37 |
| vila | poolie: ping | 07:59 |
| poolie | hi vila | 08:01 |
| vila | poolie: was your _droid suffix related to your SSD issues ? :-} | 08:02 |
| poolie | haha | 08:02 |
| poolie | not right at the moment | 08:02 |
| fullermd | vila: (brief moment of lucidity) I pulled in your changes and did somsethingorother yesterday. | 08:29 |
| vila | fullermd: yup, I saw that ! Thanks ! Take care | 08:30 |
| * fullermd tries to get another 2 hour block of sleep... | 08:30 | |
| ronny | hi | 09:24 |
| ronny | where is bzrlib.bzrdir gone? | 09:24 |
| vila | ronny: it seems to be present in all my bzr branches, may be you can be more specific ? | 09:26 |
| ronny | vila: im testing agains what is pip/easy_install-able | 09:29 |
| ronny | it recently broke | 09:29 |
| ronny | its quite annoying that bzr breaks the anyvc builds every few weeks in such unexpected ways | 09:29 |
| vila | I can understand your frustration but I still have no idea what failure you're talking about | 09:30 |
| vila | bzrlib/bzrdir.py is quite a significant piece and it won't disappear without notice | 09:31 |
| ronny | vila: the testing process currently download whatever bzr version is pip installable, and tests agaist that | 09:32 |
| ronny | (there is no way to sanely link to older ones) | 09:32 |
| vila | I have no idea what pip installable means but I can give you links for many bzr versions including the stable ones | 09:33 |
| ronny | vila: its quite useless if pip install bzr==version does not work | 09:33 |
| vila | ... | 09:33 |
| vila | you're talking chinese as far as I'm concerned | 09:34 |
| mgz | it's one of those setuptools based html scraping things. | 09:34 |
| mgz | because installing stuff from random bits downloaded over http is always such a great idea. | 09:35 |
| vila | ronny: are you telling that you don't have a bzrlib/bzrdir.py file ? | 09:35 |
| vila | ronny: if that's the case, the way you acquire bzr is seriously broken | 09:36 |
| vila | ronny: being the bzr release manager these days, I can assure you that *all* recently releases version *includes* this file | 09:37 |
| ronny | hmm, it actually exists | 09:37 |
| vila | ha, we're making progress | 09:37 |
| ronny | vila: well, why the hell is NONE of them propperly availiable on pypi | 09:37 |
| ronny | pretty much everything else i use just does that, and i can just get any version i want by package==version | 09:37 |
| ronny | only bzr makes me work extra | 09:38 |
| ronny | like always | 09:38 |
| vila | may be we can focus on concrete problems and how to solve them rather than ranting ? | 09:38 |
| ronny | ok, sorry | 09:38 |
| * ronny finishes the local reproducing | 09:40 | |
| vila | what OS are you using ? I maintain quite a few flavours but *NONE* of them requires to use easy_install and I'm not familiar with how this works | 09:40 |
| ronny | vila: im using tox to create virtualenvs with all requirements for the test runs | 09:41 |
| ronny | its using pip to grab the requirements | 09:41 |
| ronny | (and falls back to easy_install if necessary) | 09:41 |
| vila | what is pip and what is tox ? | 09:41 |
| vila | bah, nvm | 09:41 |
| vila | where are you getting bzr and in which form ? tar.gz ? .deb ? | 09:42 |
| ronny | tarball, installing it in a virtualenv after all | 09:42 |
| vila | where is this tarball coming from ? | 09:43 |
| vila | and what OS are you using (no, really) ? | 09:43 |
| ronny | im on the latest ubuntu, the test box is on a gentoo, its all linux | 09:44 |
| ronny | the thing pip currenly grabs is bzr-2.3b4.tar.gz | 09:44 |
| vila | so both of them provides stable releases AFAIK | 09:44 |
| mgz | vila, as I was saying, it scrapes html, and has broken in the past from <https://launchpad.net/bzr/+download> changing format. | 09:44 |
| vila | ronny: if you're using betas instead, then you are *expected* to encounter problems and give us feedback, that's the point of betas | 09:45 |
| ronny | vila: well, the issue for me is simple - bzr cannot propperly be installed by the python package installer | 09:45 |
| vila | ronny: this is as useful as bug reports saying: 'Does not work' | 09:46 |
| mgz | it just gets the first likely link on that page. | 09:46 |
| ronny | vila: i requested pushing all releases to pypi as well some times now | 09:47 |
| vila | ronny: afaik the python installer is used in Ubuntu and there is even *daily* builds exercising it, so surely you encounter something more specifi | 09:47 |
| vila | ronny: right, may be you teach us how to do that then | 09:47 |
| ronny | vila: python package installers are pip and easy_install | 09:48 |
| spiv | ronny: python package installers are "python setup.py install", really. | 09:48 |
| vila | ronny: don't they rely on setup.py ? | 09:48 |
| ronny | vila: yes, but they have to grab the package from soemwhere first | 09:48 |
| ronny | and in bzr's case, the only link they ever can get is the latest tarball out | 09:48 |
| spiv | Or did pip/easy_install get integrated into the standard Python distribution since I last checked? | 09:49 |
| vila | ronny: is there a way to fix that on http://pypi.python.org/pypi/bzr ? | 09:49 |
| ronny | the usual way is to just push the tarballs there | 09:49 |
| spiv | (I agree it would be nice to work well with pip etc, though) | 09:49 |
| ronny | usually people upload after a sdist | 09:49 |
| vila | ronny: as far as I know, the instructions say: 'python setup.py register' which I did for 2.2.2 | 09:50 |
| mgz | I'm not even sure that's enough, because bzr has build dependencies that it doesn't declare using the setuptools machinary. | 09:50 |
| ronny | vila: that only tells pypy there is a project with that version | 09:50 |
| mgz | so virtualenv installs may break even if tarballs get uploaded. | 09:51 |
| vila | ronny: that's why I mention it, what should be done is what I'm asking | 09:51 |
| ronny | mgz: tarballs ship with c files, dont they? | 09:51 |
| mgz | ah, so they do. | 09:51 |
| ronny | vila: upload after sdist | 09:51 |
| vila | upload | 09:51 |
| vila | -bash: upload: command not found | 09:51 |
| mgz | and I guess you don't care about running selftest. | 09:51 |
| ronny | vila: its a distutils command | 09:52 |
| vila | distutils upload | 09:52 |
| vila | -bash: distutils: command not found | 09:52 |
| mgz | as in setup.py vila. | 09:53 |
| vila | python setup.py upload | 09:54 |
| vila | running upload | 09:54 |
| vila | error: No dist file created in earlier command | 09:54 |
| mgz | +setuptools specifc. | 09:54 |
| vila | and yes, I'm in the right directory from which 2.2.2 was released | 09:54 |
| mgz | basically, the problem is we don't use setuptools. | 09:55 |
| mgz | which I think isn't something we want to change. | 09:55 |
| vila | ronny: here it goes ^ | 09:55 |
| ronny | vila: doesnt matter | 09:56 |
| vila | ronny: if you care about it, a patch against bzr making your life easier will certainly be considered, failing that, may be you should think of a better way to select your bzr source | 09:56 |
| ronny | vila: pip/easy_install force setuptools on any setup.py | 09:56 |
| ronny | vila: just upload the dam tarballs to pypi | 09:57 |
| ronny | pip/easy_install will do the rest | 09:57 |
| vila | ronny: one last time: I don't know how to do that nor do I have the time to investigate, you obviously know better and are certainly in a better position to propose a patch which can be as little as explaining which commands need to be run when | 09:59 |
| ronny | vila: python setup.py sdist upload | 10:01 |
| spiv | ronny: i.e. a patch to our doc/developers/releasing.txt | 10:01 |
| spiv | Anyway, this really doesn't sound like the cause of your bzrlib.bzrdir problem. | 10:01 |
| spiv | Can you give more details about that? | 10:01 |
| vila | ronny: done. test and feedback welcome and for an additional bonuses a merge proposal updating the document spiv mentioned above | 10:03 |
| spiv | Because there's nothing about grabbing the 2.3b4 tarball rather than the 2.2.2 tarball that seems relevant to that. | 10:03 |
| ronny | hmm, seems likepip still prefers the latest ones, but i think i can fix that | 10:05 |
| mgz | I'm curious about that too spiv, but reckoned setuptools was just breaking something else. | 10:05 |
| mgz | vila: I think one upshot of putting a tarball up there is breaking anyone on windows trying to easy_install bzr (if it worked before, that is) | 10:07 |
| vila | hmm and this command doesn't seem to include the generated C files, so most likely the result will not be the expected one | 10:07 |
| vila | nor the docs ones | 10:07 |
| vila | ronny: and how do we remove this broken tarball now ? | 10:08 |
| ronny | vila: pypi has a web ui for that | 10:08 |
| vila | done | 10:09 |
| mgz | I'm failing to find any documentation on how to actually interface with pypi to upload stuff we want from our build scripts. | 10:10 |
| vila | the web page allowing removing the tarball seems to allow manual upload too | 10:10 |
| ronny | mgz: distutils includes a uploader | 10:10 |
| mgz | no, ronny, no, it doesn't. | 10:10 |
| mgz | *setuptools* does. | 10:10 |
| vila | ronny: which produces the bogus behaviour above | 10:10 |
| mgz | which as vila just found, is broken. | 10:11 |
| ronny | mgz: distutils includes one for sure, setuptools is not required | 10:12 |
| mgz | hm, ported across in some version. | 10:14 |
| ronny | starting with 2.5 | 10:15 |
| vila | ronny: I've update the Download URL at pypi, can you try again ? | 10:17 |
| vila | s/update/updated/ | 10:17 |
| ronny | pip tries http://launchpad.net/bzr/2.2/2.2.2/+download/bzr-2.2.2.tar.gz, gets a http 404, then grabs the rest of the download list and grabs the latest one | 10:20 |
| vila | it shouldn't get a 404 since that's the url *all* packagers are using | 10:21 |
| ronny | it would be appreciated if the redirect target wouldnt trick browsers into display as text | 10:23 |
| vila | https://edge.launchpad.net/bzr/+download clearly states that 662 people succeeded to download it with this link | 10:23 |
| vila | ronny: file a bug | 10:25 |
| vila | ronny: but try to focus on your actual problem, we've been at it for an hour now and you still haven't explained what the problem was about bzrlib.bzrdir | 10:26 |
| ronny | it missing was in part caused by the venv getting messed up | 10:27 |
| ronny | i did a messy fox for the build issue, to get it propper i need to kill the problems with grabing specific bzr versions as source tarballs | 10:28 |
| vila | ronny: does this means updating the Download URL on pypi doesn't address your problem then ? | 10:30 |
| vila | mgz: does the proper tarball on pypi address your concern about windows people ? | 10:31 |
| ronny | it should, right now pip/easy_install still select thr wrong one for reasons unknown to me | 10:31 |
| ronny | (weird stuff only happens for stuff thats not propperly uploaded to pypi) | 10:31 |
| vila | ronny: we're back to 'does not work' being useless to make progress | 10:32 |
| ronny | vila: im trying t figure why pip fails to take the download link into account, but i cant exactly give a detailed description i dont have | 10:33 |
| vila | ronny: right, that's exactly my point: there is nothing we can't fix if we don't know what we do wrong | 10:34 |
| ronny | vila: im working on the details, but the basics are your tarballs are at locations that are awfully inaccessible for pip/easy_install | 10:36 |
| vila | s/awfully/standard http but/ | 10:36 |
| vila | ronny: why you insist on getting around packaged versions provided by the OSes you use while not wanting to use a source *branch* despite working with DVCS tools is a bit behind my understanding though... | 10:39 |
| vila | But that probably explain why you're the first one to report such problems... | 10:39 |
| vila | ronny: gentoo for example backported a patch from our trunk to the 2.2.2 stable branch which you will never get by working with tarballs | 10:40 |
| vila | ronny: if you're using python-2.7 (targeted by the backported patch) you're on your own | 10:41 |
| vila | mgz: did I mention I uninstalled launchpadlib from the 10.6 babune slave ? Leading to 3 remaining failures | 10:45 |
| ronny | vila: these day thats the common way to set up isolated python envs for test runs | 10:45 |
| vila | ronny: GIGO (garbage in, garbage out), if your test inputs are wrong, so do your tests outputs | 10:48 |
| vila | ronny: if you're interested about how bzr is tested: http://babune.ladeuil.net:24842/ | 10:49 |
| vila | this is a hudson setup that use the bzr trunk on various platforms | 10:49 |
| ronny | time to drop the bzr variation of my CI i guess | 10:58 |
| === Ursinha is now known as Ursinha-brb | ||
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3b4 is officially out ! (rm vila) | ||
| didrocks | hey | 14:43 |
| didrocks | so, I'm trying to merge between two branches, I have conflicts. (a lot of them). When trying to bzr resolve --take-others --all, I get: | 14:44 |
| didrocks | bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')] | 14:44 |
| jelmer | didrocks: hi | 15:06 |
| jelmer | didrocks: I believe there's an open bug about that | 15:06 |
| vila | didrocks: bzr version ? | 15:06 |
| vila | jelmer: hey :) | 15:07 |
| vila | jelmer: remind where I should check in debian to see if bzr-2.3b4 is there ? | 15:07 |
| vila | s//me/ ! | 15:07 |
| jelmer | vila: Good arvo | 15:07 |
| jelmer | vila: http://qa.debian.org/bzr | 15:08 |
| jelmer | sorry, http://packages.qa.debian.org/bzr | 15:08 |
| jelmer | I haven't packaged/uploaded b4 yet | 15:08 |
| didrocks | vila: Bazaar (bzr) 2.3b3 | 15:08 |
| didrocks | jelmer: is it fixed in trunk? I can't do the unity release because of it right now | 15:08 |
| vila | bug #646691 | 15:09 |
| ubot5 | Launchpad bug 646691 in Mahara "Blog account settings still available when blog disabled" [Low,Confirmed] https://launchpad.net/bugs/646691 | 15:09 |
| vila | bug #646961 | 15:09 |
| ubot5 | Launchpad bug 646961 in Bazaar 2.2 "resolve --take-other produces AttributeError" [High,Fix released] https://launchpad.net/bugs/646961 | 15:09 |
| didrocks | I found that weird, right :) | 15:09 |
| vila | hmm | 15:10 |
| didrocks | ok, fixed in trunk then | 15:10 |
| vila | not sure it's the same one but... | 15:10 |
| didrocks | oh right, doesn't seem | 15:10 |
| vila | didrocks: where did you get your bzr ? ppa ? | 15:10 |
| didrocks | vila: lp:~unity-team/nux/nux and lp:~unity-team/nux/packaging | 15:11 |
| didrocks | vila: you can try without merge-upstream, just merge nux in packaging. We get a whole bunch of conflicts | 15:11 |
| didrocks | (not sure why btw… It's just a one-line change in most of files) | 15:12 |
| vila | didrocks: I meant where is your bzr-2.3b3 coming from ? source ? ppa ? | 15:12 |
| didrocks | I assume there was something with merge-upstream and missing file in tarball | 15:12 |
| didrocks | vila: oh, from natty | 15:12 |
| vila | didrocks: #638451 | 15:15 |
| vila | bug #638451 | 15:15 |
| ubot5 | Launchpad bug 638451 in Bazaar " bzr resolve --take-other bzr: ERROR: Tree transform is malformed [('duplicate', None, 'new-1', None)] " [High,Fix released] https://launchpad.net/bugs/638451 | 15:15 |
| vila | didrocks: more like it no ? | 15:16 |
| didrocks | vila: exactly :) so I should definitively pull trunk | 15:16 |
| didrocks | vila: do I have to mess up with PYTHON_LIBRARY path? | 15:16 |
| vila | didrocks: feedback *highly* appreciated there | 15:16 |
| vila | didrocks: not sure what you mean, but if you run the right *bzr* script, the right bzrlib should be selected (or file a bug) | 15:17 |
| didrocks | vila: ok, let's see how it goes | 15:17 |
| vila | didrocks: if you run from source, don't forget to run 'make' first | 15:17 |
| vila | didrocks: note that you're using a quite recent addition there that will handle the *text* conflicts by *forcing* the OTHER version (with --take-other) | 15:18 |
| vila | didrocks: i.e. all changes that could be otherwise merged cleanly are thrown away | 15:19 |
| jelmer | didrocks: alternatively you can use the nightly builds | 15:19 |
| vila | didrocks: make sure you read 'bzr help conflict-types' there | 15:19 |
| vila | jelmer: I read the emails related to the failures, but not always the associated logs, is there a place which summarizes the status of the builds ? | 15:20 |
| jelmer | vila: https://code.launchpad.net/~bzr/+recipes has a list of all the recipes, each recipe has an overview of the resulting builds | 15:21 |
| vila | jelmer: ha, 2.3b4 not yet packaged, ok | 15:21 |
| jelmer | vila: there's also https://code.launchpad.net/~bzr/+archive/daily/+packages | 15:21 |
| vila | jelmer: thanks, I keep forgetting +packages | 15:23 |
| vila | meh, didrocks, don't leave without feedback !!! | 15:23 |
| vila | . o O (reboot did he ?) | 15:23 |
| vila | jelmer: should https://code.launchpad.net/~bzr/+recipe/bzr-daily mention beta5 instead of beta4 ? | 15:30 |
| jelmer | vila: no, as we're using "beta4+bzr" - note the + which means this version comes /after/ beta4 | 15:31 |
| vila | jelmer: %-} ooook | 15:31 |
| jelmer | vila: Alternatively we could use beta5~bzr if we knew we were going to do a beta5 | 15:31 |
| jelmer | (~ sorts before empty string, + sorts after empty string) | 15:31 |
| vila | right, so you did this change at freeze or at release time ? | 15:32 |
| jelmer | vila: yep | 15:32 |
| vila | a or b: yes... :D | 15:32 |
| vila | any ? | 15:33 |
| vila | yeah, any, sorry, thinking aloud ;D | 15:33 |
| vila | haaa, he's back :D | 15:34 |
| vila | didrocks: so ? | 15:34 |
| didrocks | vila: sorry, seeems that I was disconnected :/ | 15:34 |
| didrocks | 16:25:42 didrocks | vila: are you sure it's taking the right bzrlib? like if I try ~/sandbox/bzr/bzr resolve --all --take-other (~/sandbox/bzr is where I branched bzr from) | 15:34 |
| didrocks | 16:26:23 didrocks | oh right bzrlib: /home/didrocks/sandbox/bzr/bzrlib | 15:34 |
| didrocks | 16:26:32 didrocks | so ok… it's not fixed :/ | 15:34 |
| didrocks | I have 2.3.0dev5 from --version | 15:34 |
| vila | file a bug | 15:35 |
| didrocks | vila: what do you need as needed info in addition to the branch and the error output? | 15:36 |
| jelmer | vila: Sorry :-) I changed it after the release | 15:36 |
| vila | didrocks: reproducing recipe | 15:36 |
| didrocks | vila: can I workaround in some way (downgrade or such)? I think that I can't delay the unity release anymore :) | 15:36 |
| vila | didrocks: try resolving in several steps | 15:37 |
| didrocks | there are 50 conflicts… will write a shell script then | 15:37 |
| vila | didrocks: meh, is that a private branch ? | 15:38 |
| didrocks | vila: it's not, you can't check it out? | 15:38 |
| vila | no, got not a branch | 15:38 |
| didrocks | let me check, I maybe made a typo | 15:39 |
| vila | s!/nux!/trunk! ? | 15:39 |
| didrocks | vila: oh sorry, the trunk is at trunk, right | 15:39 |
| didrocks | or lp:nux | 15:40 |
| vila | yup, better | 15:40 |
| didrocks | the packaging branch is good :) | 15:40 |
| vila | ouch, 62 conflict | 15:41 |
| vila | ouch, 62 conflicts | 15:41 |
| didrocks | vila: yeah, I'm not sure why there are there… upstream just changed the email in every files | 15:41 |
| didrocks | vila: so I think something happened between bzr merge-upstream / the tarball / trunk | 15:41 |
| didrocks | well, we try to ship every files in the tarball to avoid conflicts as we had at some point | 15:42 |
| vila | no, there are a bunch of content conflicts which means different file-ids probably so parallel import ? | 15:42 |
| didrocks | vila: weird, bzr merge-upstream did that? | 15:42 |
| vila | no idea | 15:42 |
| didrocks | like it added other file ids? | 15:42 |
| didrocks | filed as bug #688101 | 15:46 |
| vila | didrocks: I'm digging the history of both branches | 15:47 |
| ubot5 | Launchpad bug 688101 in Bazaar "bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')]" [Undecided,New] https://launchpad.net/bugs/688101 | 15:47 |
| didrocks | vila: thanks, it will be way easier for you I guess to find what happened than I ;) | 15:47 |
| vila | didrocks: hopefully :-} | 15:48 |
| didrocks | (I was the CSM administrator in my previous company, so I digged a lot in that to support developers, I don't want to do that anymore :p) | 15:49 |
| vila | didrocks: so far the only suspicious bit is revno 138 (New upstream release _ cherry pick latest commit) | 15:49 |
| vila | didrocks: di you change your workflow somehow between now and then ? | 15:50 |
| didrocks | vila: I've already done that in the past for unity itself. I just bzr merge from trunk what's interested | 15:51 |
| didrocks | so it should pick upstream file-id if there are new, isn't it? | 15:51 |
| vila | didrocks: if you started your packaging branch from trunk ,yes | 15:51 |
| didrocks | vila: right, it is started from trunk | 15:52 |
| vila | and that seems to be the case (revno 113) | 15:52 |
| didrocks | that's all the benefit of merge-upstream and this workflow, cherry-picks :) | 15:52 |
| didrocks | (no more debian/patches/…) | 15:52 |
| didrocks | and it went well in the past in bamf/unity/dee… (I'm used to do that since May I would say) | 15:53 |
| vila | right, so comparing the inventories on both tips, sounds fine, all common files have the same file-ids, but it seems the conflicting ones are new in trunk... weird | 15:56 |
| didrocks | vila: not only the new ones (it can't add the directory it seems), but also ones where the email name was changed, isn't it? | 15:58 |
| vila | didrocks: hmm, doing 'bzr qlog trunk packaging' shows that you *never* merged since 0.9.1 | 16:04 |
| vila | no wrong | 16:05 |
| didrocks | vila: is that what bzr log trunk packaging tells me? | 16:05 |
| === beuno is now known as beuno-lunch | ||
| didrocks | bzr: ERROR: Path "/home/didrocks/work/unity/nux/ubuntu" is not a child of path "/home/didrocks/work/unity/nux/nux" | 16:06 |
| vila | of course you never merge packaging in trunk, you do the opposite, sorry | 16:06 |
| didrocks | right :) | 16:06 |
| vila | *q*log | 16:06 |
| didrocks | didn't know that command, it's coming from which package/plugin? | 16:06 |
| vila | qbzr | 16:06 |
| didrocks | no gtk equivalent? ;) | 16:07 |
| vila | best way to look at branch histories (especially to see how they interact) | 16:07 |
| vila | bzr viz, but I don't remember if it accepts multiple branches | 16:07 |
| didrocks | I've always used with once, let's see how it work with 2 | 16:07 |
| vila | well, yes it does, but it still lacks the ability to hide merges | 16:08 |
| vila | a good chunk of the qlog backend is in a mp for bzr, once it lands, viz could reuse it | 16:08 |
| didrocks | oh nice, yeah, it's easier to see the history this way | 16:08 |
| vila | didrocks: eeerk, never ever use 'resolve --all' all this does is deleting the conflicts file | 16:13 |
| vila | didrocks: on the other hand, I just did that and that may be shortcut you're after... | 16:13 |
| didrocks | vila: well, I haven't done that. I just noticed it this time | 16:13 |
| didrocks | vila: on bzr resolve --all --take-other should take all .OTHER, isn't it? | 16:14 |
| vila | didrocks: no, that's a bug, --all and --take-other shouldn't be allowed together | 16:14 |
| didrocks | vila: oh ok :) | 16:14 |
| vila | didrocks: try 'bzr resolve --all' alone and look at the result but don't commit ! | 16:15 |
| fullermd | Yeah, 'resolve --all' is a "mark that things are done", "--take-whatever" is a "do things". Kinda a wart that one command does both. | 16:15 |
| didrocks | fullermd: oh right! | 16:15 |
| didrocks | vila: yeah, confirmed | 16:15 |
| vila | didrocks: if you're happy with the result: do 'bzr revert --forget-merges' and then and only then commit | 16:15 |
| vila | didrocks: if you weren't in a hurry I won't recommend that *at all* | 16:16 |
| vila | ha, bah, no good, bunch of .OTHER all over the place | 16:17 |
| didrocks | vila: hum, so what should I use? bzr merge && bzr revert --forget-merges? but that will prevent me taking new upstream version, isn't it? | 16:17 |
| vila | didrocks: no, that would be a huge cherry-pick | 16:17 |
| vila | didrocks: but forget it, bad idea | 16:17 |
| didrocks | vila: ok, I still have some time :) | 16:18 |
| vila | jam: ping | 16:19 |
| vila | jam: I don't have news from gary and we still haven't installers for bzr-2.2.2, can you help ? | 16:20 |
| === zyga is now known as zyga-food | ||
| LeoNerd | bzr add silently adds container directories. This is helpful. bzr mv doesn't add new path containers, gets upset. Possibly it should? | 16:26 |
| LeoNerd | Well, not silently. Automatically. | 16:26 |
| LeoNerd | Strikes me if 'add' does it, so should 'mv' | 16:27 |
| fullermd | Devil's advocate: You call mv to move a file from one place to another; having it also add stuff is unexpected. | 16:28 |
| LeoNerd | Devil's Counter-advocate; You call add to include one new file; having it also add other stuff is unexpected. | 16:28 |
| vila | didrocks: ok, the problems started at revno 139 in trunk | 16:29 |
| LeoNerd | Or make it non-default? bzr mv --add-parents oldname newname | 16:29 |
| vila | LeoNerd, fullermd: very good, put that in a bug ! | 16:29 |
| LeoNerd | Then people who want it can just alias | 16:29 |
| didrocks | vila: looking | 16:29 |
| fullermd | Perhaps, but it's at worst "do more than expected", not "do something else too". I'd be shocked at 'add' moving stuff around; perhaps less so, but still somewhat, at 'mv' adding stuff. | 16:29 |
| fullermd | We're not ready for a bug, we're still rehearsing! | 16:30 |
| LeoNerd | Well.. currently it complains and dies | 16:30 |
| * Torne is more surprised by mv failing just because he didn't add the directory | 16:30 | |
| didrocks | vila: weird, it's modified but the whole file content is removed and then added | 16:31 |
| didrocks | vila: oh "fix end of line" -> \r\n -> \n ? | 16:31 |
| vila | yeah, so the file-ids shouldn't be modified then | 16:32 |
| didrocks | right | 16:33 |
| Torne | fullermd: bzr add adds the parent directories because otherwise the operation would have to fail, and failing an operation with a perfectly logical intent would be silly. I don't think that mv is different just because "mv" and "add" are different commands. | 16:34 |
| jam | hi vila, I might be able to dig something out, but I honestly haven't worked closely with Garyvdm on the last couple of builds | 16:36 |
| vila | jam: :-/ do you know if he at least pushed its last related branches ? | 16:36 |
| jam | he should have, but no, I don't know that for sure | 16:37 |
| didrocks | vila: so, do you have any suggestion? I can drop the packaging branch and setup one again… but that will be a pity :/ | 16:56 |
| vila | didrocks: whatever works for you :-/ I'm still digging and won't have a fix shortly sry :-/ | 16:57 |
| didrocks | vila: ok, can you keep the branch somewhere? I'll surely --overwrite | 16:57 |
| vila | didrocks: but my feeling is that the prolem is in merge not in resolve, the later being a symptom | 16:57 |
| vila | didrocks: I have both branches there | 16:58 |
| didrocks | vila: ok, I'll maybe scratch them then. Hope that the use case can be solvable for you :) | 16:58 |
| vila | me too | 16:59 |
| === deryck is now known as deryck[lunch] | ||
| vila | didrocks: that's the first time you're using 'bzr resolve --take-other' right ? | 17:21 |
| vila | didrocks: there seems to be mutiple bugs there when the same file is involved in several conflicts | 17:22 |
| vila | didrocks: the workaround seem to be to resolve the conflicts manually | 17:23 |
| didrocks | vila: I never used it before, right | 17:23 |
| vila | didrocks: I'm halfway | 17:23 |
| vila | didrocks: ha good, so I think it will not have give you the expected result | 17:23 |
| vila | didrocks: is NuxGraphics/GraphicsDisplayWin.h windows specific ? | 17:23 |
| didrocks | vila: yeah, Nux is multi-plateform | 17:24 |
| vila | didrocks: and you deleted it from the packaging branch. Using --take-other means take it again | 17:24 |
| didrocks | vila: no, it was not disted in make dist tarball | 17:25 |
| didrocks | vila: so bzr merge-upstream deleted it | 17:25 |
| vila | didrocks: meh, I didn't use merge-upstream | 17:26 |
| didrocks | vila: I mean, that's why some files were deleted there in some commits | 17:29 |
| vila | didrocks: right, anyway, that's why you have Content Conflicts (one side deleted, the other modified) | 17:31 |
| didrocks | vila: yes, just a pity there is no way to solve that in one command :) | 17:32 |
| vila | didrocks: indeed | 17:32 |
| vila | didrocks: but your specific use case here is tricky, you want a mix of --take-this and --take-other | 17:33 |
| vila | well, not even, you don't want --take-other, you want to keep your deletions and cleanly merge the rest I think | 17:34 |
| didrocks | vila: exactly :/ in any case, there are some workflow issues with merge-upstream for such cases | 17:34 |
| didrocks | right | 17:34 |
| vila | didrocks: any way, summary: | 17:34 |
| vila | - thanks for the bug, I should fix it, | 17:35 |
| vila | - --take-other is not what you want: you need to resolve them in smaller chunks but not at all once, one by one in the worst case | 17:35 |
| vila | - merging more often will help, as usual :D | 17:36 |
| didrocks | vila: I'm merging once a week :) | 17:36 |
| didrocks | vila: but yeah, this use-case is an issue with merge-upstream workflow | 17:37 |
| didrocks | at least, we know why there are conflicts, which is good | 17:37 |
| vila | didrocks: well, more often can also mean merging less revisions (which is what I'm doing) | 17:41 |
| === beuno-lunch is now known as beuno | ||
| vila | didrocks: I'm lost now, revno 144 produces 58 conflicts and I have no clue about how to resolve them | 17:45 |
| didrocks | vila: right, but with 25 upstream branch without making a release… once a week is already a lot :) | 17:45 |
| vila | didrocks: of course, that's a bug, I'm only talking about workarounds here, the last item had a smiley ;D | 17:46 |
| didrocks | right :) | 17:46 |
| vila | and when I say one.. probably several | 17:47 |
| vila | didrocks: bactracking to your ', it was not disted in make dist tarball' where is this defined ? | 17:50 |
| didrocks | vila: sorry, I'm currently on the unity release, hard to be responsive :) | 17:59 |
| vila | didrocks: no worries, am I right if I guess from Mafile.am files ? | 17:59 |
| didrocks | vila: this is definied in the dist target of all the Makefile.am | 17:59 |
| didrocks | yeah | 17:59 |
| didrocks | (there are multiple) | 17:59 |
| vila | to yeah, this is taking shape, you're suddenly confronted with a bunch of conflicts (deleted/modified), so what you really want is some way to attach merge options to files or directories | 18:00 |
| vila | and this became more obvious *because* a change was made to *all* files | 18:01 |
| === deryck[lunch] is now known as deryck | ||
| === Meths_ is now known as Meths | ||
| === zyga-food is now known as zyga | ||
| === Ursinha is now known as Ursinha-brb | ||
| poolie | hi jam | 20:56 |
| spiv | Good morning. | 22:10 |
| poolie | hi spiv | 23:09 |
| === zyga is now known as zyga-afk | ||
| === Ursinha-brb is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
