6 files changed, 0 insertions, 83 deletions
diff --git a/results/classifier/deepseek-1/reasoning/vnc/1414222 b/results/classifier/deepseek-1/reasoning/vnc/1414222
deleted file mode 100644
index 1e6ceb83..00000000
--- a/results/classifier/deepseek-1/reasoning/vnc/1414222
+++ /dev/null
@@ -1,15 +0,0 @@
-<think>
-Okay, so I need to classify this bug report into one of the given categories. Let me read through the details carefully.
-
-The user provided a bug report where using the command `qemu-system-i386 -vnc localhost:0,to=99,id=default` results in an error: "Invalid parameter 'to'". The git bisect points to a specific commit by Gerd Hoffmann from 2014, which switched VNC handling to use QemuOpts and allowed multiple servers. 
-
-Looking at the problem, it's related to the VNC configuration in QEMU. The error message mentions an invalid parameter 'to', which suggests that the way VNC options are being parsed or handled might have changed incorrectly after the commit.
-
-The bug reporter also provided context about a patch fixing issues where not configuring VNC caused a crash and corrections to missing properties, especially changing the type for QEMU_OPT_BOOL. This indicates that there were changes in how VNC parameters are processed, leading to this bug.
-
-Given the categories, I should consider which one fits best. Since it's related to VNC configuration parameters, the most appropriate category is 'vnc'. The issue isn't about mistranslation, assembly, or any other listed areas but specifically pertains to VNC options handling.
-</think>
-
-The bug report relates to an invalid parameter in the VNC configuration within QEMU, which was introduced after a change to how VNC options are handled. This falls under the 'vnc' category.
-
-**Answer:** vnc
\ No newline at end of file
diff --git a/results/classifier/deepseek-1/reasoning/vnc/1455912 b/results/classifier/deepseek-1/reasoning/vnc/1455912
deleted file mode 100644
index 7001bf4b..00000000
--- a/results/classifier/deepseek-1/reasoning/vnc/1455912
+++ /dev/null
@@ -1,11 +0,0 @@
-<think>
-Okay, I need to classify the given bug report into one of the specified categories for QEMU. The possible categories are mistranslation, assembly, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
-
-The bug report mentions issues with the VNC websocket option not being parsed correctly when running on the command line. The user is experiencing errors like "address resolution failed for tor:on" and notes that removing the websocket part makes it work. They also mention a commit that caused this regression and another patch that fixed it in version 2.9.0.
-
-Looking at the categories, the issue clearly relates to VNC functionality within QEMU. The problem is with parsing command-line options specific to VNC, particularly involving websockets. This points directly to the 'vnc' category since it's about how VNC server parameters are handled.
-</think>
-
-The bug report pertains to issues with parsing the VNC websocket option in QEMU, which falls under the 'vnc' category.
-
-**Answer: vnc**
\ No newline at end of file
diff --git a/results/classifier/deepseek-1/reasoning/vnc/1484925 b/results/classifier/deepseek-1/reasoning/vnc/1484925
deleted file mode 100644
index bb158b9b..00000000
--- a/results/classifier/deepseek-1/reasoning/vnc/1484925
+++ /dev/null
@@ -1,11 +0,0 @@
-<think>
-Alright, let's break down how I classify this bug report. The user is encountering a segfault when using a custom VNC client (noVNC) with their Citrix XenServer setup. They mentioned that the issue only occurs with their custom PHP-based noVNC client and the nodejs package from Xen Orchestra, but works fine with the stock client. 
-
-The error message shows a SIGSEGV due to a memory access issue, specifically at address 0xb28000. The QEMU process is segfaulting, which suggests a problem within the QEMU code or its interaction with external components.
-
-Looking at the possible categories: 'vnc' seems directly related since the issue arises when using VNC clients. Other categories like 'network' or 'hypervisor' could be considered, but the root cause here is tied to the VNC connection handling in QEMU.
-</think>
-
-The bug report involves a segfault occurring during interaction with a custom noVNC client, pointing towards issues in VNC handling within QEMU.
-
-vnc
\ No newline at end of file
diff --git a/results/classifier/deepseek-1/reasoning/vnc/1661176 b/results/classifier/deepseek-1/reasoning/vnc/1661176
deleted file mode 100644
index a465920e..00000000
--- a/results/classifier/deepseek-1/reasoning/vnc/1661176
+++ /dev/null
@@ -1,15 +0,0 @@
-<think>
-Alright, I'm looking at this bug report where the user is having trouble accessing the monitor via VNC in QEMU after an upgrade from version 2.6.2 to 2.8.0. Specifically, pressing CTRL-ALT-2 used to bring them to the monitor, but now it's going to serial0 console instead. They also mention that other shortcuts like CTRL-ALT-1 and -3 are not working as expected anymore.
-
-First, I need to figure out which category this bug falls into from the provided list: mistranslation, assembly, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
-
-The issue is related to VNC behavior, specifically how keyboard shortcuts are handled for switching between different consoles. The user is no longer able to access the monitor using the expected key combinations. This seems like a problem with how QEMU's VNC server handles these shortcut keys, which might be part of the device or peripheral interaction.
-
-I'm leaning towards 'vnc' as the category because it's directly about the VNC functionality and how keyboard events are processed within that context. However, another possibility is 'device' if it's related to input handling for devices like the keyboard or console redirection.
-
-But considering the primary function affected is the VNC interface and its key mapping, 'vnc' seems more appropriate.
-</think>
-
-The issue relates to VNC shortcuts not functioning as expected after an upgrade. The problem lies within how QEMU handles keyboard shortcuts in the VNC interface, making 'vnc' the most fitting category.
-
-vnc
\ No newline at end of file
diff --git a/results/classifier/deepseek-1/reasoning/vnc/1828207 b/results/classifier/deepseek-1/reasoning/vnc/1828207
deleted file mode 100644
index 16fe3fea..00000000
--- a/results/classifier/deepseek-1/reasoning/vnc/1828207
+++ /dev/null
@@ -1,15 +0,0 @@
-<think>
-Okay, so I need to classify this bug report into one of the given categories. Let me read through the details carefully.
-
-The user is talking about adding log reports for authentication failures in the built-in VNC server of QEMU. They mention that without logs, it's hard to analyze brute force attacks and integrate with automated systems like fail2ban. They suggest logging something like "QEMU VNC Authentication failed" along with IP addresses.
-
-They also note that using the built-in VNC-auth scheme is a security flaw, especially on public-facing services, and recommend using VeNCrypt with TLS and SASL for better security. There's a discussion about whether to deprecate or remove the feature because it's insecure but necessary for protocol compatibility.
-
-The categories I have are: mistranslation, assembly, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
-
-Looking at the issue, it's specifically about VNC authentication and logging. The main problem is that there are no logs for failed authentications, making it hard to detect brute force attacks. They're suggesting adding a log message, which relates directly to VNC functionality. There's also a mention of security concerns but the primary request is about enhancing logging.
-
-So the category should be 'vnc' because it's focused on the VNC server in QEMU and its authentication features.
-</think>
-
-vnc
\ No newline at end of file
diff --git a/results/classifier/deepseek-1/reasoning/vnc/1871267 b/results/classifier/deepseek-1/reasoning/vnc/1871267
deleted file mode 100644
index ab1e1e58..00000000
--- a/results/classifier/deepseek-1/reasoning/vnc/1871267
+++ /dev/null
@@ -1,16 +0,0 @@
-<think>
-Alright, I need to classify this bug report into one of the given categories: mistranslation, assembly, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
-
-Looking at the bug report, the user is experiencing multiple keystrokes when using macOS as a guest on Windows with QEMU. They mention that this happens with both gtk (which I think relates to SPICE) and VNC. The issue doesn't occur when running the same setup under Linux KVM, which suggests it's specific to how QEMU handles input in certain environments.
-
-The user also provided some additional info about CPU options and TSC settings, but that seems more related to hardware emulation and timekeeping within the VM, which might affect performance or timing but not directly the input handling issue described. The main problem is with repeated keystrokes when using graphical remote access (VNC or SPICE).
-
-The categories I'm considering: 
-- **network**: Because it's related to how the host communicates with the guest, especially over a network protocol like VNC.
-- **vnc**: Since the issue occurs when using VNC as one of the affected interfaces.
-- **other**: If none of the specific categories fit.
-
-But since the problem is specifically about input via graphical remote access (VNC), it's more precise to classify it under 'vnc' rather than a broader category like 'network' or 'other'.
-</think>
-
-vnc
\ No newline at end of file