[PATCH 0/2] remote-helpers: test fixes

[PATCH 0/2] remote-helpers: test fixes

[Felipe Contreras]

Hi,

I've setup a project in Travis CI for continuous integration with very good
results, however, I had to apply a couple of fixes.

I'm not sure if this is v1.8.3 material, but here they are.

https://travis-ci.org/felipec/git/builds/7262886

Felipe Contreras (2):
  remote-helpers: tests: use python directly
  remote-hg: tests: fix hg merge

 contrib/remote-helpers/test-bzr.sh       |  2 +-
 contrib/remote-helpers/test-hg-bidi.sh   |  2 +-
 contrib/remote-helpers/test-hg-hg-git.sh | 11 ++++++-----
 contrib/remote-helpers/test-hg.sh        |  2 +-
 4 files changed, 9 insertions(+), 8 deletions(-)

-- 
1.8.3.rc2.542.g24820ba

[PATCH 1/2] remote-helpers: tests: use python directly

[Felipe Contreras]

These remote helpers use 'env python', not PYTHON_PATH, so that's where
we should check for the extensions. Otherwise, if 'python' is not
PYTHON_PATH (e.g. /usr/bin/python: Makefile's default), there will be a
mismatch between the python libraries actually accessible to the remote
helpers.

Suggested by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/test-bzr.sh       | 2 +-
 contrib/remote-helpers/test-hg-bidi.sh   | 2 +-
 contrib/remote-helpers/test-hg-hg-git.sh | 4 ++--
 contrib/remote-helpers/test-hg.sh        | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/contrib/remote-helpers/test-bzr.sh b/contrib/remote-helpers/test-bzr.sh
index 5dfa070..2c89caa 100755
--- a/contrib/remote-helpers/test-bzr.sh
+++ b/contrib/remote-helpers/test-bzr.sh
@@ -12,7 +12,7 @@ if ! test_have_prereq PYTHON; then
 	test_done
 fi
 
-if ! "$PYTHON_PATH" -c 'import bzrlib'; then
+if ! python -c 'import bzrlib'; then
 	skip_all='skipping remote-bzr tests; bzr not available'
 	test_done
 fi
diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh
index f569697..2c693d0 100755
--- a/contrib/remote-helpers/test-hg-bidi.sh
+++ b/contrib/remote-helpers/test-hg-bidi.sh
@@ -15,7 +15,7 @@ if ! test_have_prereq PYTHON; then
 	test_done
 fi
 
-if ! "$PYTHON_PATH" -c 'import mercurial'; then
+if ! python -c 'import mercurial'; then
 	skip_all='skipping remote-hg tests; mercurial not available'
 	test_done
 fi
diff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh
index 8440341..fbad2b9 100755
--- a/contrib/remote-helpers/test-hg-hg-git.sh
+++ b/contrib/remote-helpers/test-hg-hg-git.sh
@@ -15,12 +15,12 @@ if ! test_have_prereq PYTHON; then
 	test_done
 fi
 
-if ! "$PYTHON_PATH" -c 'import mercurial'; then
+if ! python -c 'import mercurial'; then
 	skip_all='skipping remote-hg tests; mercurial not available'
 	test_done
 fi
 
-if ! "$PYTHON_PATH" -c 'import hggit'; then
+if ! python -c 'import hggit'; then
 	skip_all='skipping remote-hg tests; hg-git not available'
 	test_done
 fi
diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh
index 8de2aa7..ce03fa3 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -15,7 +15,7 @@ if ! test_have_prereq PYTHON; then
 	test_done
 fi
 
-if ! "$PYTHON_PATH" -c 'import mercurial'; then
+if ! python -c 'import mercurial'; then
 	skip_all='skipping remote-hg tests; mercurial not available'
 	test_done
 fi
-- 
1.8.3.rc2.542.g24820ba

[PATCH 2/2] remote-hg: tests: fix hg merge

[Felipe Contreras]

Let's specify a merge tool, otherwise mercurial might open one and hang
our tests waiting for user input.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/test-hg-hg-git.sh | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh
index fbad2b9..f18e26f 100755
--- a/contrib/remote-helpers/test-hg-hg-git.sh
+++ b/contrib/remote-helpers/test-hg-hg-git.sh
@@ -103,11 +103,12 @@ setup () {
 	git config --global receive.denycurrentbranch warn
 	git config --global remote-hg.hg-git-compat true
 
-	HGEDITOR=/usr/bin/true
+	HGEDITOR=true
+	HGMERGE=true
 
 	GIT_AUTHOR_DATE="2007-01-01 00:00:00 +0230"
 	GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"
-	export HGEDITOR GIT_AUTHOR_DATE GIT_COMMITTER_DATE
+	export HGEDITOR HGMERGE GIT_AUTHOR_DATE GIT_COMMITTER_DATE
 }
 
 setup
@@ -197,7 +198,7 @@ test_expect_success 'merge conflict 1' '
 	echo C > afile &&
 	hg ci -m "A->C" &&
 
-	hg merge -r1 || true &&
+	hg merge -r1 &&
 	echo C > afile &&
 	hg resolve -m afile &&
 	hg ci -m "merge to C"
-- 
1.8.3.rc2.542.g24820ba

Re: [PATCH 1/2] remote-helpers: tests: use python directly

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> These remote helpers use 'env python', not PYTHON_PATH, so that's where
> we should check for the extensions. Otherwise, if 'python' is not
> PYTHON_PATH (e.g. /usr/bin/python: Makefile's default), there will be a
> mismatch between the python libraries actually accessible to the remote
> helpers.

What I am reading here is that what the "helper" uses and what the
"test" checks to see if it can use the "helper" were different; and
this patch fixes that misalignment by testing what the "helper"
actually uses.

So it is a right thing to do in that sense.

I however am having this nagging feeling that I may be missing
something subtle here.  Comments from others are very much welcome.

Will queue but the result will be on tomorrow's pushout.

Thanks.

> Suggested by: Torsten Bögershausen <tboegi@web.de>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  contrib/remote-helpers/test-bzr.sh       | 2 +-
>  contrib/remote-helpers/test-hg-bidi.sh   | 2 +-
>  contrib/remote-helpers/test-hg-hg-git.sh | 4 ++--
>  contrib/remote-helpers/test-hg.sh        | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/contrib/remote-helpers/test-bzr.sh b/contrib/remote-helpers/test-bzr.sh
> index 5dfa070..2c89caa 100755
> --- a/contrib/remote-helpers/test-bzr.sh
> +++ b/contrib/remote-helpers/test-bzr.sh
> @@ -12,7 +12,7 @@ if ! test_have_prereq PYTHON; then
>  	test_done
>  fi
>  
> -if ! "$PYTHON_PATH" -c 'import bzrlib'; then
> +if ! python -c 'import bzrlib'; then
>  	skip_all='skipping remote-bzr tests; bzr not available'
>  	test_done
>  fi
> diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh
> index f569697..2c693d0 100755
> --- a/contrib/remote-helpers/test-hg-bidi.sh
> +++ b/contrib/remote-helpers/test-hg-bidi.sh
> @@ -15,7 +15,7 @@ if ! test_have_prereq PYTHON; then
>  	test_done
>  fi
>  
> -if ! "$PYTHON_PATH" -c 'import mercurial'; then
> +if ! python -c 'import mercurial'; then
>  	skip_all='skipping remote-hg tests; mercurial not available'
>  	test_done
>  fi
> diff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh
> index 8440341..fbad2b9 100755
> --- a/contrib/remote-helpers/test-hg-hg-git.sh
> +++ b/contrib/remote-helpers/test-hg-hg-git.sh
> @@ -15,12 +15,12 @@ if ! test_have_prereq PYTHON; then
>  	test_done
>  fi
>  
> -if ! "$PYTHON_PATH" -c 'import mercurial'; then
> +if ! python -c 'import mercurial'; then
>  	skip_all='skipping remote-hg tests; mercurial not available'
>  	test_done
>  fi
>  
> -if ! "$PYTHON_PATH" -c 'import hggit'; then
> +if ! python -c 'import hggit'; then
>  	skip_all='skipping remote-hg tests; hg-git not available'
>  	test_done
>  fi
> diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh
> index 8de2aa7..ce03fa3 100755
> --- a/contrib/remote-helpers/test-hg.sh
> +++ b/contrib/remote-helpers/test-hg.sh
> @@ -15,7 +15,7 @@ if ! test_have_prereq PYTHON; then
>  	test_done
>  fi
>  
> -if ! "$PYTHON_PATH" -c 'import mercurial'; then
> +if ! python -c 'import mercurial'; then
>  	skip_all='skipping remote-hg tests; mercurial not available'
>  	test_done
>  fi

Re: [PATCH 1/2] remote-helpers: tests: use python directly

[David Aguilar]

On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> These remote helpers use 'env python', not PYTHON_PATH, so that's where
>> we should check for the extensions. Otherwise, if 'python' is not
>> PYTHON_PATH (e.g. /usr/bin/python: Makefile's default), there will be a
>> mismatch between the python libraries actually accessible to the remote
>> helpers.
>
> What I am reading here is that what the "helper" uses and what the
> "test" checks to see if it can use the "helper" were different; and
> this patch fixes that misalignment by testing what the "helper"
> actually uses.
>
> So it is a right thing to do in that sense.
>
> I however am having this nagging feeling that I may be missing
> something subtle here.  Comments from others are very much welcome.

Yes, this is correct.  Another way to skin this cat would be to do
search/replace in a Makefile to burn in the PYTHON_PATH similar to how
we do for the .sh scripts and other .py files in the main Makefile.
The remote helpers are in contrib/ so they do not go through the main
Makefile, which is the root cause.

Longer-term, it would be good to treat these uniformly, but this is no
worse for now.

> Will queue but the result will be on tomorrow's pushout.
>
> Thanks.
>
>> Suggested by: Torsten Bögershausen <tboegi@web.de>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>  contrib/remote-helpers/test-bzr.sh       | 2 +-
>>  contrib/remote-helpers/test-hg-bidi.sh   | 2 +-
>>  contrib/remote-helpers/test-hg-hg-git.sh | 4 ++--
>>  contrib/remote-helpers/test-hg.sh        | 2 +-
>>  4 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/contrib/remote-helpers/test-bzr.sh b/contrib/remote-helpers/test-bzr.sh
>> index 5dfa070..2c89caa 100755
>> --- a/contrib/remote-helpers/test-bzr.sh
>> +++ b/contrib/remote-helpers/test-bzr.sh
>> @@ -12,7 +12,7 @@ if ! test_have_prereq PYTHON; then
>>       test_done
>>  fi
>>
>> -if ! "$PYTHON_PATH" -c 'import bzrlib'; then
>> +if ! python -c 'import bzrlib'; then
>>       skip_all='skipping remote-bzr tests; bzr not available'
>>       test_done
>>  fi
>> diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh
>> index f569697..2c693d0 100755
>> --- a/contrib/remote-helpers/test-hg-bidi.sh
>> +++ b/contrib/remote-helpers/test-hg-bidi.sh
>> @@ -15,7 +15,7 @@ if ! test_have_prereq PYTHON; then
>>       test_done
>>  fi
>>
>> -if ! "$PYTHON_PATH" -c 'import mercurial'; then
>> +if ! python -c 'import mercurial'; then
>>       skip_all='skipping remote-hg tests; mercurial not available'
>>       test_done
>>  fi
>> diff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh
>> index 8440341..fbad2b9 100755
>> --- a/contrib/remote-helpers/test-hg-hg-git.sh
>> +++ b/contrib/remote-helpers/test-hg-hg-git.sh
>> @@ -15,12 +15,12 @@ if ! test_have_prereq PYTHON; then
>>       test_done
>>  fi
>>
>> -if ! "$PYTHON_PATH" -c 'import mercurial'; then
>> +if ! python -c 'import mercurial'; then
>>       skip_all='skipping remote-hg tests; mercurial not available'
>>       test_done
>>  fi
>>
>> -if ! "$PYTHON_PATH" -c 'import hggit'; then
>> +if ! python -c 'import hggit'; then
>>       skip_all='skipping remote-hg tests; hg-git not available'
>>       test_done
>>  fi
>> diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh
>> index 8de2aa7..ce03fa3 100755
>> --- a/contrib/remote-helpers/test-hg.sh
>> +++ b/contrib/remote-helpers/test-hg.sh
>> @@ -15,7 +15,7 @@ if ! test_have_prereq PYTHON; then
>>       test_done
>>  fi
>>
>> -if ! "$PYTHON_PATH" -c 'import mercurial'; then
>> +if ! python -c 'import mercurial'; then
>>       skip_all='skipping remote-hg tests; mercurial not available'
>>       test_done
>>  fi
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
David

Re: [PATCH 1/2] remote-helpers: tests: use python directly

[Felipe Contreras]

On Fri, May 17, 2013 at 9:51 PM, David Aguilar <davvid@gmail.com> wrote:
> On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> These remote helpers use 'env python', not PYTHON_PATH, so that's where
>>> we should check for the extensions. Otherwise, if 'python' is not
>>> PYTHON_PATH (e.g. /usr/bin/python: Makefile's default), there will be a
>>> mismatch between the python libraries actually accessible to the remote
>>> helpers.
>>
>> What I am reading here is that what the "helper" uses and what the
>> "test" checks to see if it can use the "helper" were different; and
>> this patch fixes that misalignment by testing what the "helper"
>> actually uses.
>>
>> So it is a right thing to do in that sense.
>>
>> I however am having this nagging feeling that I may be missing
>> something subtle here.  Comments from others are very much welcome.
>
> Yes, this is correct.  Another way to skin this cat would be to do
> search/replace in a Makefile to burn in the PYTHON_PATH similar to how
> we do for the .sh scripts and other .py files in the main Makefile.
> The remote helpers are in contrib/ so they do not go through the main
> Makefile, which is the root cause.
>
> Longer-term, it would be good to treat these uniformly, but this is no
> worse for now.

Yeap, I initially thought it would be tricky to implement in the
rather minimal Makefile, but it seems it wouldn't. Whoever, I still
find it useful that I don't have to run 'make' to test these, and I
think it's nice that people can download directly as the final name
('git-remote-hg'), and don't have to rename. And since these aren't
installed with 'make install' anyway, I don't see any big hurry.

Cheers.

-- 
Felipe Contreras

Re: [PATCH 1/2] remote-helpers: tests: use python directly

[Junio C Hamano]

David Aguilar <davvid@gmail.com> writes:

> On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> So it is a right thing to do in that sense.
>>
>> I however am having this nagging feeling that I may be missing
>> something subtle here.  Comments from others are very much welcome.
>
> Yes, this is correct.  Another way to skin this cat would be to do
> search/replace in a Makefile to burn in the PYTHON_PATH similar to how
> we do for the .sh scripts and other .py files in the main Makefile.
> The remote helpers are in contrib/ so they do not go through the main
> Makefile, which is the root cause.
>
> Longer-term, it would be good to treat these uniformly, but this is no
> worse for now.

Ahh, so my "nagging feeling" was that remote-helpers could in theory
be updated to follow the PYTHON_PATH like the rest of the system and
matching these two in that direction is the better longer-term fix?

Ok, with that in mind, I still think the patch under discussion is
an immediate solution that is fine as-is.

I somehow thought that there were valid reasons that we could not do
so for some technical reason (e.g. the instalation of python used to
run hg and/or bzr via these remote helpers and the installation of
python we use may need to be different?).  As long as the right
longer-term direction is not "we cannot fundamentally unify them",
then I am very happy.

I was worried that we might end up having to define random fine
gained knobs like PYTHON_FOR_HG_PATH to allow tuning these.

Thanks for a clarification.

Re: [PATCH 1/2] remote-helpers: tests: use python directly

[Felipe Contreras]

Junio C Hamano wrote:
> David Aguilar <davvid@gmail.com> writes:
> 
> > On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >
> >> So it is a right thing to do in that sense.
> >>
> >> I however am having this nagging feeling that I may be missing
> >> something subtle here.  Comments from others are very much welcome.
> >
> > Yes, this is correct.  Another way to skin this cat would be to do
> > search/replace in a Makefile to burn in the PYTHON_PATH similar to how
> > we do for the .sh scripts and other .py files in the main Makefile.
> > The remote helpers are in contrib/ so they do not go through the main
> > Makefile, which is the root cause.
> >
> > Longer-term, it would be good to treat these uniformly, but this is no
> > worse for now.
> 
> Ahh, so my "nagging feeling" was that remote-helpers could in theory
> be updated to follow the PYTHON_PATH like the rest of the system and
> matching these two in that direction is the better longer-term fix?

Indeed, and I already have patches for that. FTR, the Makefile does loop
through the main Makefile, which is what made implementing this so easy.

> I somehow thought that there were valid reasons that we could not do
> so for some technical reason (e.g. the instalation of python used to
> run hg and/or bzr via these remote helpers and the installation of
> python we use may need to be different?).  As long as the right
> longer-term direction is not "we cannot fundamentally unify them",
> then I am very happy.

I didn't think of that, and it might actually be a problem: I don't think
Mercurial works with python 3, and Bazaar probably never will.

But I don't think the current situation of always using 'python' helps either
way.

Cheers.

-- 
Felipe Contreras

Re: [PATCH 0/2] remote-helpers: test fixes

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Hi,
>
> I've setup a project in Travis CI for continuous integration with very good
> results, however, I had to apply a couple of fixes.
>
> I'm not sure if this is v1.8.3 material, but here they are.

Thanks; I'll queue them at the tip of fc/remote-hg to graduate soon
after 1.8.3, then.

>
> https://travis-ci.org/felipec/git/builds/7262886
>
> Felipe Contreras (2):
>   remote-helpers: tests: use python directly
>   remote-hg: tests: fix hg merge
>
>  contrib/remote-helpers/test-bzr.sh       |  2 +-
>  contrib/remote-helpers/test-hg-bidi.sh   |  2 +-
>  contrib/remote-helpers/test-hg-hg-git.sh | 11 ++++++-----
>  contrib/remote-helpers/test-hg.sh        |  2 +-
>  4 files changed, 9 insertions(+), 8 deletions(-)

Re: [PATCH 0/2] remote-helpers: test fixes

[Felipe Contreras]

On Mon, May 20, 2013 at 5:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Hi,
>>
>> I've setup a project in Travis CI for continuous integration with very good
>> results, however, I had to apply a couple of fixes.
>>
>> I'm not sure if this is v1.8.3 material, but here they are.
>
> Thanks; I'll queue them at the tip of fc/remote-hg to graduate soon
> after 1.8.3, then.

No, they should be graduated first. The tip of fc/remote-hg is in pu,
no? I have rebased that branch and squashed some fixes so every commit
works on all versions of Mercurial. I will resend all the patches, the
only reason I haven't done so is that I didn't want to create more
noise before v1.8.3, and you said I was the one taking the decision
when to merge remote-helper stuff to master.

So this should go to master, the rest of fc/remote-hg should be
dropped, I can resend any time, and I suppose after v1.8.3 is the best
time.

-- 
Felipe Contreras

Re: [PATCH 0/2] remote-helpers: test fixes

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Mon, May 20, 2013 at 5:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> Hi,
>>>
>>> I've setup a project in Travis CI for continuous integration with very good
>>> results, however, I had to apply a couple of fixes.
>>>
>>> I'm not sure if this is v1.8.3 material, but here they are.
>>
>> Thanks; I'll queue them at the tip of fc/remote-hg to graduate soon
>> after 1.8.3, then.
>
> No, they should be graduated first. The tip of fc/remote-hg is in pu,
> no? I have rebased that branch and squashed some fixes so every commit
> works on all versions of Mercurial. I will resend all the patches, the
> only reason I haven't done so is that I didn't want to create more
> noise before v1.8.3, and you said I was the one taking the decision
> when to merge remote-helper stuff to master.

Then is this v1.8.3 material?  Please do not stay "I'm not sure" for
very long.  I do not think we want -rc4 only for a contrib/ stuff.

For today's integration run I didn't want to wait so tentatively
they are queued at the tip of fc/remote-hg, and it is too late to
redo everything I did today, but I can requeue them for 'master' in
the tomorrow's cycle if you want.

Re: [PATCH 0/2] remote-helpers: test fixes

[Felipe Contreras]

On Mon, May 20, 2013 at 6:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Mon, May 20, 2013 at 5:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> Hi,
>>>>
>>>> I've setup a project in Travis CI for continuous integration with very good
>>>> results, however, I had to apply a couple of fixes.
>>>>
>>>> I'm not sure if this is v1.8.3 material, but here they are.
>>>
>>> Thanks; I'll queue them at the tip of fc/remote-hg to graduate soon
>>> after 1.8.3, then.
>>
>> No, they should be graduated first. The tip of fc/remote-hg is in pu,
>> no? I have rebased that branch and squashed some fixes so every commit
>> works on all versions of Mercurial. I will resend all the patches, the
>> only reason I haven't done so is that I didn't want to create more
>> noise before v1.8.3, and you said I was the one taking the decision
>> when to merge remote-helper stuff to master.
>
> Then is this v1.8.3 material?  Please do not stay "I'm not sure" for
> very long.  I do not think we want -rc4 only for a contrib/ stuff.

I think this could very well fit into v1.8.3, but there's no rush, it
can wait until after.

> For today's integration run I didn't want to wait so tentatively
> they are queued at the tip of fc/remote-hg, and it is too late to
> redo everything I did today, but I can requeue them for 'master' in
> the tomorrow's cycle if you want.

I think 'next' is fine, they could go into 'master' to improve the
testing of what's already there, but it probably won't matter much.
Moreover, it's not fixing test regressions; the issues have been there
pretty much since day one, and if nobody has found them by now it
probably won't change anything for v1.8.3.

My main motivation is that with these patches I could test a pristine
'master' branch directly into travis-ci.

-- 
Felipe Contreras