add 18th iteration of classifier

1 files changed, 52 insertions, 0 deletions

diff --git a/results/classifier/118/network/806656 b/results/classifier/118/network/806656
new file mode 100644
index 000000000..925bfd977
--- /dev/null
+++ b/results/classifier/118/network/806656
@@ -0,0 +1,52 @@
+network: 0.889
+vnc: 0.865
+graphic: 0.853
+mistranslation: 0.816
+semantic: 0.799
+socket: 0.760
+device: 0.751
+files: 0.733
+performance: 0.715
+ppc: 0.654
+register: 0.654
+user-level: 0.651
+PID: 0.638
+architecture: 0.629
+kernel: 0.627
+virtual: 0.578
+permissions: 0.568
+x86: 0.557
+risc-v: 0.526
+KVM: 0.515
+i386: 0.513
+arm: 0.493
+boot: 0.474
+peripherals: 0.452
+debug: 0.452
+assembly: 0.444
+VMM: 0.436
+TCG: 0.422
+hypervisor: 0.366
+
+Tight PNG VNC encoding is sent even when --disable-vnc-png is set
+
+This bug exists in 0.14.1 and also in 9312805d33e8b (Jun 17, 2011) in the master git repo.
+
+The "Tight PNG" encoding is a derivative of the "Tight" encoding that replaces zlib encoded rects with PNG encoded data instead. However, when the "Tight PNG" encoding is disabled (--disable-vnc-png), the server will send frame buffer updates that are marked as "Tight PNG" but in fact contain zlib encoded regions (i.e. it's really "tight" protocol).
+
+The "Tight PNG" encoding should only be used when --enable-vnc-png is set.
+
+
+
+The patch looks right, maybe you should send it directly to the qemu mailing list.
+
+Using noVNC and kvm in SLES 11 we have hit this bug as well. 
+
+Joel, would you like to send your patch to the qemu mailing list?
+
+I sent the patch on May 16 (http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg02373.html). I haven't seen any response.
+
+Patch had been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=fe3e7f2dc05225cdd2ba
+... so I'm closing this ticket now.
+