summaryrefslogtreecommitdiffstats
path: root/results/classifier/111/review/838974
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/111/review/838974')
-rw-r--r--results/classifier/111/review/83897443
1 files changed, 43 insertions, 0 deletions
diff --git a/results/classifier/111/review/838974 b/results/classifier/111/review/838974
new file mode 100644
index 00000000..b9ec19d2
--- /dev/null
+++ b/results/classifier/111/review/838974
@@ -0,0 +1,43 @@
+semantic: 0.246
+other: 0.152
+network: 0.150
+device: 0.078
+files: 0.047
+graphic: 0.047
+performance: 0.040
+PID: 0.040
+debug: 0.039
+socket: 0.035
+KVM: 0.034
+vnc: 0.033
+permissions: 0.030
+boot: 0.029
+network: 0.240
+debug: 0.163
+semantic: 0.159
+other: 0.112
+files: 0.078
+PID: 0.046
+device: 0.043
+socket: 0.032
+performance: 0.029
+boot: 0.027
+KVM: 0.023
+permissions: 0.020
+graphic: 0.015
+vnc: 0.013
+
+Confusing error report for missing vde support
+
+The error that appears in qemu 0.15 is "parameter 'type' expects a network client type" when trying to use vde for networking as if the parameter is wrong, but the problem is that the executable was compiled without vde support.
+
+Thanks for reporting this bug.
+
+That certainly could be confusing. However, practically speaking, since qemu was compiled without that support, it becomes more difficult for qemu to tell the difference between a unsupported but otherwise-valid type, and an invalid type.
+
+Perhaps upstream would accept a (trivial) patch changing the message to always say "expects a valid network client type". Even more helpful would be for that message to be followed by a list of valid, supported network types.
+
+I think this has been fixed by this commit here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d139e9a6cf01b8c31f59
+... so closing this ticket now.
+