On 05/15/2014 11:35 AM, Markus Armbruster wrote:
>
> The root stupid idea is to run stuff in the source tree. Since a source
> tree can have many build trees, finding the correct build tree can't be
> automated.
>
> If you run stuff in the build tree, there is exactly one source tree,
> and put
On 15.05.2014 19:35, Markus Armbruster wrote:
Max Reitz writes:
On 15.05.2014 08:52, Markus Armbruster wrote:
Max Reitz writes:
On 14.05.2014 14:33, Markus Armbruster wrote:
Max Reitz writes:
Currently, QEMU's iotests rely on /usr/bin/env to start the correct
Python (that is, at least
Max Reitz writes:
> On 15.05.2014 08:52, Markus Armbruster wrote:
>> Max Reitz writes:
>>
>>> On 14.05.2014 14:33, Markus Armbruster wrote:
Max Reitz writes:
> Currently, QEMU's iotests rely on /usr/bin/env to start the correct
> Python (that is, at least Python 2.4, but not 3
On 15 May 2014 18:29, Max Reitz wrote:
> On 15.05.2014 19:08, Peter Maydell wrote:
>>
>> On 15 May 2014 17:56, Max Reitz wrote:
>>>
>>> I think I'll go with Fam's proposal, which is making common.config look
>>> for
>>> python itself, which then can be overwritten by an environment variable.
>>
>
On 15.05.2014 19:08, Peter Maydell wrote:
On 15 May 2014 17:56, Max Reitz wrote:
I think I'll go with Fam's proposal, which is making common.config look for
python itself, which then can be overwritten by an environment variable.
That sounds wrong to me. We already have a way for the user
to t
On 15 May 2014 17:56, Max Reitz wrote:
> I think I'll go with Fam's proposal, which is making common.config look for
> python itself, which then can be overwritten by an environment variable.
That sounds wrong to me. We already have a way for the user
to tell us what python to use, which is the c
On 15.05.2014 08:52, Markus Armbruster wrote:
Max Reitz writes:
On 14.05.2014 14:33, Markus Armbruster wrote:
Max Reitz writes:
Currently, QEMU's iotests rely on /usr/bin/env to start the correct
Python (that is, at least Python 2.4, but not 3). On systems where
Python 3 is the default, th
Markus Armbruster writes:
[...]
> The problem is including generated bits, namely results of configure,
> into source files.
>
> The Autoconf way is to substitute placeholders in FOO.in producing FOO.
>
> When you want to limit .in contents as much as possible, you factor out
> the stuff that nee
Max Reitz writes:
> On 14.05.2014 14:33, Markus Armbruster wrote:
>> Max Reitz writes:
>>
>>> Currently, QEMU's iotests rely on /usr/bin/env to start the correct
>>> Python (that is, at least Python 2.4, but not 3). On systems where
>>> Python 3 is the default, the user has no clean way of makin
On Thu, 05/15 01:41, Max Reitz wrote:
> On 14.05.2014 14:33, Markus Armbruster wrote:
> >Max Reitz writes:
> >
> >>Currently, QEMU's iotests rely on /usr/bin/env to start the correct
> >>Python (that is, at least Python 2.4, but not 3). On systems where
> >>Python 3 is the default, the user has no
On 14.05.2014 14:33, Markus Armbruster wrote:
Max Reitz writes:
Currently, QEMU's iotests rely on /usr/bin/env to start the correct
Python (that is, at least Python 2.4, but not 3). On systems where
Python 3 is the default, the user has no clean way of making the iotests
use the correct binary
Max Reitz writes:
> Currently, QEMU's iotests rely on /usr/bin/env to start the correct
> Python (that is, at least Python 2.4, but not 3). On systems where
> Python 3 is the default, the user has no clean way of making the iotests
> use the correct binary.
>
> This commit makes the iotests use t
Am 03.05.2014 um 16:47 hat Max Reitz geschrieben:
> Currently, QEMU's iotests rely on /usr/bin/env to start the correct
> Python (that is, at least Python 2.4, but not 3). On systems where
> Python 3 is the default, the user has no clean way of making the iotests
> use the correct binary.
>
> This
On Mon, May 05, 2014 at 06:25:38PM +0200, Max Reitz wrote:
> On 05.05.2014 14:26, Stefan Hajnoczi wrote:
> >On Sat, May 03, 2014 at 04:47:08PM +0200, Max Reitz wrote:
> >>@@ -56,22 +57,22 @@ for IMGOPTS in "compat=0.10" "compat=1.1"; do
> >> echo === Create image with unknown header extension
On 05/05/2014 10:25 AM, Max Reitz wrote:
>> The code generally uses the older `` notation instead of $(). Please
>> use ``.
>
> If I'd send a v2 with ``, Eric would probably want me to send a v3 with
> $(). ;-)
I won't make you resend if you are consistent with other code in the
same file. But
On 05.05.2014 14:26, Stefan Hajnoczi wrote:
On Sat, May 03, 2014 at 04:47:08PM +0200, Max Reitz wrote:
@@ -56,22 +57,22 @@ for IMGOPTS in "compat=0.10" "compat=1.1"; do
echo === Create image with unknown header extension ===
echo
_make_test_img 64M
-./qcow2.py "$TEST_IMG" a
On 05/05/2014 06:26 AM, Stefan Hajnoczi wrote:
>> -[ ! -x $seq ] && chmod u+x $seq # ensure we can run it
>> +
>> +if [ "$(head -n 1 $seq)" == "#!/usr/bin/env python" ]; then
>> +run_command="$PYTHON $seq"
>
> The code generally uses the older `` notation instead of $(
On 5 May 2014 13:26, Stefan Hajnoczi wrote:
> On Sat, May 03, 2014 at 04:47:08PM +0200, Max Reitz wrote:
>> @@ -56,22 +57,22 @@ for IMGOPTS in "compat=0.10" "compat=1.1"; do
>> echo === Create image with unknown header extension ===
>> echo
>> _make_test_img 64M
>> -./qcow2.py "
On Sat, May 03, 2014 at 04:47:08PM +0200, Max Reitz wrote:
> @@ -56,22 +57,22 @@ for IMGOPTS in "compat=0.10" "compat=1.1"; do
> echo === Create image with unknown header extension ===
> echo
> _make_test_img 64M
> -./qcow2.py "$TEST_IMG" add-header-ext 0x12345678 "This is a test
Currently, QEMU's iotests rely on /usr/bin/env to start the correct
Python (that is, at least Python 2.4, but not 3). On systems where
Python 3 is the default, the user has no clean way of making the iotests
use the correct binary.
This commit makes the iotests use the Python selected by configure
20 matches
Mail list logo
