add 18th iteration of classifier

1 files changed, 462 insertions, 0 deletions

diff --git a/results/classifier/118/all/636315 b/results/classifier/118/all/636315
new file mode 100644
index 000000000..e0d6705f8
--- /dev/null
+++ b/results/classifier/118/all/636315
@@ -0,0 +1,462 @@
+semantic: 0.971
+permissions: 0.964
+register: 0.957
+assembly: 0.953
+PID: 0.950
+device: 0.948
+arm: 0.947
+graphic: 0.947
+architecture: 0.944
+virtual: 0.940
+debug: 0.939
+performance: 0.930
+kernel: 0.925
+user-level: 0.921
+socket: 0.913
+peripherals: 0.911
+mistranslation: 0.911
+risc-v: 0.907
+hypervisor: 0.903
+boot: 0.903
+i386: 0.890
+TCG: 0.889
+vnc: 0.888
+network: 0.884
+files: 0.880
+KVM: 0.877
+ppc: 0.852
+VMM: 0.846
+x86: 0.843
+
+configure and build errors on Solaris 10 due to /bin/sh usage
+
+Running `LANG=C LC_ALL=C ./configure --prefix=... --install=/usr/ucb/install` on Solaris 10 amd64 results in the following errors:
+
+./configure: bad substitution
+./configure: !: not found
+./configure: curl-config: not found
+./configure: curl-config: not found
+
+Error: invalid trace backend
+Please choose a supported trace backend.
+
+
+Unfortunately it doesn't print the line numbers of the errors. It must be somewhere after the check for `install`.
+
+The first few can be resolved by running `bash ./configure ...` instead. 
+
+The "check if trace backend exists" hardcodes `sh "$source_path/tracetool" ...` in configure. Replacing sh with bash makes it work.
+
+`gmake` complains "Makefile:331: no file name for -include", which is a filter for *.d files.
+`create_config` gets the 'bad substitution' error as well. Replacing sh with bash in rules.mak works.
+etc.
+
+To sum it up,
+a) there are shell script incompatibilities with Solaris 10's /bin/sh shell, and
+b) hardcoding 'sh' in configure or Makefiles seems like a bad idea.
+
+QEMU Git 73d7434279e3905164afd02360eebe4b43c7fa (ESP: fix ESP DMA access...)
+
+$ uname -a
+SunOS sonnengoettin 5.10 Generic_142901-03 i86pc i386 i86pc
+
+# No banner output for /bin/sh
+
+$ bash --version
+GNU bash, version 3.00.16(1)-release (i386-pc-solaris2.10)
+Copyright (C) 2004 Free Software Foundation, Inc.
+
+On Sun, Sep 12, 2010 at 11:26 AM, Andreas Färber
+<email address hidden> wrote:
+> Public bug reported:
+>
+> Running `LANG=C LC_ALL=C ./configure --prefix=...
+> --install=/usr/ucb/install` on Solaris 10 amd64 results in the following
+> errors:
+>
+> ./configure: bad substitution
+> ./configure: !: not found
+> ./configure: curl-config: not found
+> ./configure: curl-config: not found
+>
+> Error: invalid trace backend
+> Please choose a supported trace backend.
+
+What is the output of "sh ./tracetool --nop --check-backend"?
+
+>
+>
+> Unfortunately it doesn't print the line numbers of the errors. It must be somewhere after the check for `install`.
+>
+> The first few can be resolved by running `bash ./configure ...` instead.
+>
+> The "check if trace backend exists" hardcodes `sh
+> "$source_path/tracetool" ...` in configure. Replacing sh with bash makes
+> it work.
+>
+> `gmake` complains "Makefile:331: no file name for -include", which is a filter for *.d files.
+> `create_config` gets the 'bad substitution' error as well. Replacing sh with bash in rules.mak works.
+> etc.
+>
+> To sum it up,
+> a) there are shell script incompatibilities with Solaris 10's /bin/sh shell, and
+
+I fixed one in 2184d75b4a6a253e8b1e002b3dbcc85c20ba6041 and now
+Milax's /bin/sh is happy.
+
+Am 12.09.2010 um 19:22 schrieb Blue Swirl:
+
+> On Sun, Sep 12, 2010 at 11:26 AM, Andreas Färber
+> <email address hidden> wrote:
+>> Error: invalid trace backend
+>> Please choose a supported trace backend.
+>
+> What is the output of "sh ./tracetool --nop --check-backend"?
+
+./tracetool: syntax error at line 51: `$' unexpected
+
+On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <email address hidden> wrote:
+> Am 12.09.2010 um 19:22 schrieb Blue Swirl:
+>
+>> On Sun, Sep 12, 2010 at 11:26 AM, Andreas Färber
+>> <email address hidden> wrote:
+>>>
+>>> Error: invalid trace backend
+>>> Please choose a supported trace backend.
+>>
+>> What is the output of "sh ./tracetool --nop --check-backend"?
+>
+> ./tracetool: syntax error at line 51: `$' unexpected
+
+Does this patch fix the problem?
+
+diff --git a/tracetool b/tracetool
+index 534cc70..c7582bf 100755
+--- a/tracetool
++++ b/tracetool
+@@ -48,7 +48,8 @@ get_argnames()
+ {
+     local nfields field name
+     nfields=0
+-    for field in $(get_args "$1"); do
++    args=get_args "$1"
++    for field in "$args"; do
+         nfields=$((nfields + 1))
+
+         # Drop pointer star
+
+Am 12.09.2010 um 19:47 schrieb Blue Swirl:
+
+> On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <<email address hidden> 
+> > wrote:
+>> Am 12.09.2010 um 19:22 schrieb Blue Swirl:
+>>
+>>> What is the output of "sh ./tracetool --nop --check-backend"?
+>>
+>> ./tracetool: syntax error at line 51: `$' unexpected
+>
+> Does this patch fix the problem?
+>
+> diff --git a/tracetool b/tracetool
+> index 534cc70..c7582bf 100755
+> --- a/tracetool
+> +++ b/tracetool
+> @@ -48,7 +48,8 @@ get_argnames()
+> {
+>     local nfields field name
+>     nfields=0
+> -    for field in $(get_args "$1"); do
+> +    args=get_args "$1"
+> +    for field in "$args"; do
+
+This part yes. (I took the liberty of adding args to the local line  
+above)
+
+>         nfields=$((nfields + 1))
+
+Next error is here:
+./tracetool: syntax error at line 53: `nfields=$' unexpected
+
+On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> wrote:
+> Am 12.09.2010 um 19:47 schrieb Blue Swirl:
+>
+>> On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <email address hidden>
+>> wrote:
+>>>
+>>> Am 12.09.2010 um 19:22 schrieb Blue Swirl:
+>>>
+>>>> What is the output of "sh ./tracetool --nop --check-backend"?
+>>>
+>>> ./tracetool: syntax error at line 51: `$' unexpected
+>>
+>> Does this patch fix the problem?
+>>
+>> diff --git a/tracetool b/tracetool
+>> index 534cc70..c7582bf 100755
+>> --- a/tracetool
+>> +++ b/tracetool
+>> @@ -48,7 +48,8 @@ get_argnames()
+>> {
+>>    local nfields field name
+>>    nfields=0
+>> -    for field in $(get_args "$1"); do
+>> +    args=get_args "$1"
+>> +    for field in "$args"; do
+>
+> This part yes. (I took the liberty of adding args to the local line above)
+>
+>>        nfields=$((nfields + 1))
+>
+> Next error is here:
+> ./tracetool: syntax error at line 53: `nfields=$' unexpected
+
+That looks like fully standards compliant, so Solaris' /bin/sh is not.
+Can you try what happens with /usr/xpg4/bin/sh?
+
+Am 12.09.2010 um 23:05 schrieb Blue Swirl:
+
+> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <<email address hidden> 
+> > wrote:
+>> Am 12.09.2010 um 19:47 schrieb Blue Swirl:
+>>>        nfields=$((nfields + 1))
+>>
+>> ./tracetool: syntax error at line 53: `nfields=$' unexpected
+>
+> That looks like fully standards compliant, so Solaris' /bin/sh is not.
+> Can you try what happens with /usr/xpg4/bin/sh?
+
+Works fine! Must've done something wrong when testing that earlier  
+today.
+
+configure, create_config and tracetool with your fix are silent when / 
+usr/xpg4/bin is in the $PATH.
+If you commit it, we can close this ticket. Thanks for your help, Blue.
+
+Build still fails, in qemu-nbd.c due to err.h, but that's unrelated  
+to /bin/sh.
+After disabling the tools in configure, sparc-softmmu builds fine again.
+
+Am 13.09.2010 um 10:49 schrieb Michael Tokarev:
+
+> 13.09.2010 01:05, Blue Swirl wrote:
+>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <<email address hidden> 
+>> > wrote:
+>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl:
+>>>
+>>>> diff --git a/tracetool b/tracetool
+>>>> index 534cc70..c7582bf 100755
+>>>> --- a/tracetool
+>>>> +++ b/tracetool
+>>>> @@ -48,7 +48,8 @@ get_argnames()
+>>>> {
+>>>>   local nfields field name
+>>>>   nfields=0
+>>>> -    for field in $(get_args "$1"); do
+>>>> +    args=get_args "$1"
+>>>> +    for field in "$args"; do
+>>>
+>>> This part yes. (I took the liberty of adding args to the local  
+>>> line above)
+>
+> Um.  Are you sure it works as expected?
+
+No, I'm not sure. It's Dark Magic to me and happened to unbreak  
+configure; I'll try out your suggestions the next days.
+
+Thanks,
+Andreas
+
+>  I'm not at all shure.
+> There are 2 errors in the above patch:
+>
+> +    args=get_args "$1"
+>
+> After this line, variable $args will contain one word: "get_args".
+> Shell will try to execute a command or call a shell function which
+> name is stored in $1, if it is assigned.  If it is not, at least
+> bash will complain that it can't execute command "".
+>
+> The proper way is to add backticks:
+>
+> +    args=`get_args "$1"`
+>
+> In the second line:
+>
+> +    for field in "$args"; do
+>
+> the double quotes ensure that all words in $args are
+> processed as single word, all at once.  So the for loop
+> will be executed exactly one time, no matter how many
+> arguments are given (even if there's none).
+>
+> So the right solution is to drop double quotes.
+>
+> JFYI.
+>
+> /mjt
+>
+
+
+On Sun, Sep 12, 2010 at 10:02 PM, Andreas Färber <email address hidden> wrote:
+> Am 12.09.2010 um 23:05 schrieb Blue Swirl:
+>
+>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden>
+>> wrote:
+>>>
+>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl:
+>>>>
+>>>>       nfields=$((nfields + 1))
+>>>
+>>> ./tracetool: syntax error at line 53: `nfields=$' unexpected
+>>
+>> That looks like fully standards compliant, so Solaris' /bin/sh is not.
+>> Can you try what happens with /usr/xpg4/bin/sh?
+>
+> Works fine! Must've done something wrong when testing that earlier today.
+>
+> configure, create_config and tracetool with your fix are silent when
+> /usr/xpg4/bin is in the $PATH.
+> If you commit it, we can close this ticket. Thanks for your help, Blue.
+
+Does /usr/xpg4/bin/sh work without the patch?
+
+On Mon, Sep 13, 2010 at 8:49 AM, Michael Tokarev <email address hidden> wrote:
+> 13.09.2010 01:05, Blue Swirl wrote:
+>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> wrote:
+>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl:
+>>>
+>>>> On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <email address hidden>
+>>>> wrote:
+>>>>>
+>>>>> Am 12.09.2010 um 19:22 schrieb Blue Swirl:
+>>>>>
+>>>>>> What is the output of "sh ./tracetool --nop --check-backend"?
+>>>>>
+>>>>> ./tracetool: syntax error at line 51: `$' unexpected
+>>>>
+>>>> Does this patch fix the problem?
+>>>>
+>>>> diff --git a/tracetool b/tracetool
+>>>> index 534cc70..c7582bf 100755
+>>>> --- a/tracetool
+>>>> +++ b/tracetool
+>>>> @@ -48,7 +48,8 @@ get_argnames()
+>>>> {
+>>>>    local nfields field name
+>>>>    nfields=0
+>>>> -    for field in $(get_args "$1"); do
+>>>> +    args=get_args "$1"
+>>>> +    for field in "$args"; do
+>>>
+>>> This part yes. (I took the liberty of adding args to the local line above)
+>
+> Um.  Are you sure it works as expected?  I'm not at all shure.
+> There are 2 errors in the above patch:
+>
+>  +    args=get_args "$1"
+>
+> After this line, variable $args will contain one word: "get_args".
+> Shell will try to execute a command or call a shell function which
+> name is stored in $1, if it is assigned.  If it is not, at least
+> bash will complain that it can't execute command "".
+>
+> The proper way is to add backticks:
+>
+>  +    args=`get_args "$1"`
+>
+> In the second line:
+>
+>  +    for field in "$args"; do
+>
+> the double quotes ensure that all words in $args are
+> processed as single word, all at once.  So the for loop
+> will be executed exactly one time, no matter how many
+> arguments are given (even if there's none).
+>
+> So the right solution is to drop double quotes.
+
+Do you see any bug with the original?
+
+If the problem is in fact that Solaris' /bin/sh is not standards
+compliant, we shouldn't fix the script but instead make sure that the
+shell used to run tracetool is the compliant one.
+
+Am 14.09.2010 um 18:34 schrieb Blue Swirl:
+
+> On Sun, Sep 12, 2010 at 10:02 PM, Andreas Färber <<email address hidden> 
+> > wrote:
+>> Am 12.09.2010 um 23:05 schrieb Blue Swirl:
+>>
+>>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <<email address hidden> 
+>>> >
+>>> wrote:
+>>>>
+>>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl:
+>>>>>
+>>>>>       nfields=$((nfields + 1))
+>>>>
+>>>> ./tracetool: syntax error at line 53: `nfields=$' unexpected
+>>>
+>>> That looks like fully standards compliant, so Solaris' /bin/sh is  
+>>> not.
+>>> Can you try what happens with /usr/xpg4/bin/sh?
+>>
+>> Works fine! Must've done something wrong when testing that earlier  
+>> today.
+>>
+>> configure, create_config and tracetool with your fix are silent when
+>> /usr/xpg4/bin is in the $PATH.
+>> If you commit it, we can close this ticket. Thanks for your help,  
+>> Blue.
+>
+> Does /usr/xpg4/bin/sh work without the patch?
+
+No.
+
+On Tue, Sep 14, 2010 at 8:37 PM, Andreas Färber <email address hidden> wrote:
+> Am 14.09.2010 um 18:34 schrieb Blue Swirl:
+>
+>> On Sun, Sep 12, 2010 at 10:02 PM, Andreas Färber <email address hidden>
+>> wrote:
+>>>
+>>> Am 12.09.2010 um 23:05 schrieb Blue Swirl:
+>>>
+>>>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden>
+>>>> wrote:
+>>>>>
+>>>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl:
+>>>>>>
+>>>>>>      nfields=$((nfields + 1))
+>>>>>
+>>>>> ./tracetool: syntax error at line 53: `nfields=$' unexpected
+>>>>
+>>>> That looks like fully standards compliant, so Solaris' /bin/sh is not.
+>>>> Can you try what happens with /usr/xpg4/bin/sh?
+>>>
+>>> Works fine! Must've done something wrong when testing that earlier today.
+>>>
+>>> configure, create_config and tracetool with your fix are silent when
+>>> /usr/xpg4/bin is in the $PATH.
+>>> If you commit it, we can close this ticket. Thanks for your help, Blue.
+>>
+>> Does /usr/xpg4/bin/sh work without the patch?
+>
+> No.
+
+How about with the attached patch? If yes, does it work even with /bin/sh?
+
+
+Am 14.09.2010 um 22:53 schrieb Blue Swirl:
+
+> How about with the attached patch? If yes, does it work even with / 
+> bin/sh?
+
+LC_ALL=C /usr/xpg4/bin/sh ./tracetool --nop --check-backend
+
+works fine,
+
+LC_ALL=C sh ./tracetool --nop --check-backend
+./tracetool: bad substitution
+
+The shell-based tracetool has been replace in commit 650ab98d1d9551f0ca21 with a script that has been implemented in Python, so I think we can close this bug nowadays.
+