1 files changed, 67 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1859989 b/results/classifier/zero-shot/108/other/1859989
new file mode 100644
index 000000000..01e294632
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/1859989
@@ -0,0 +1,67 @@
+semantic: 0.814
+graphic: 0.792
+permissions: 0.769
+other: 0.759
+debug: 0.739
+performance: 0.701
+device: 0.690
+vnc: 0.676
+boot: 0.672
+network: 0.669
+PID: 0.667
+socket: 0.631
+files: 0.613
+KVM: 0.571
+
+qemu-img has broken output with large snapshot names
+
+On Qemu 4.1.1 the output of snalshots breaks if the chosen state name is too long:
+
+# qemu-img snapshot -l /mnt/local/some_image.qcow2
+Snapshot list:
+ID        TAG                 VM SIZE                DATE       VM CLOCK
+1         online_provider_with_dhcp747 MiB 2020-01-15 12:05:01   00:00:45.873
+
+Prior to 4.1.1 this used to work with extra tabs for the VM SIZE values. The collision is also disabling us from using a regex on top of this input to detect the snapshot.
+
+Hi,
+
+When did this work last for you?  I tried every .0 release down to 2.12.0, and all showed this kind of broken output.  (I wasn’t able to compile 2.11.0 and earlier.)
+
+Here was my test case:
+
+$ ./qemu-img create -f qcow2 foo.qcow2 64M
+Formatting 'foo.qcow2', fmt=qcow2 size=67108864 cluster_size=65536 lazy_refcounts=off refcount_bits=16
+$ ./qemu-img snapshot -c foofoofoofoofoofoofoofoofoofoo foo.qcow2
+$ ./qemu-img snapshot -l foo.qcow2 
+Snapshot list:
+ID        TAG                 VM SIZE                DATE       VM CLOCK
+1         foofoofoofoofoofoofoofoofoofoo      0 2020-01-17 10:53:17   00:00:00.000
+$ ./qemu-img --version
+qemu-img version 2.12.0 (v2.12.0)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+Max
+
+I’ve just seen that launchpad collapses the spaces in the snapshot...  All I can say is that diff tells me the output from 2.12.0 and 4.1.1 is exactly the same, with only one difference: 2.12.0 prints the VM SIZE as “0” (without a unit), whereas 4.1.1 prints “0 B”.
+
+But now I just realized you probably mean that there is no space between the snapshot name and the VM state size in your example.  OK, I thought you meant the fact that the headers are not aligned to the table body columns.
+
+That seems to be because the size is printed in a 7-wide field, which isn’t sufficient for three-digit sizes with unit prefixes; so “747 MiB” is not prefixed by a space.  I think de38b5005e9 is to blame which which (from what I can tell) effectively changed the output from using SI prefixes to IEC prefixes (which requires one more character), adds a space before and a “B” after the prefix (another two additional characters), and by always printing three digits, which may require a decimal point (so another character).  But it didn’t grow the field width.  So I think we should do that.
+
+Max
+
+Hi Max,
+
+It last worked in (previous version we used):
+[root@c15 ~]# qemu-img --version
+qemu-img version 3.1.1 (qemu-3.1.1-2.fc30)
+Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
+
+Yes, unfortunately Launchpad doesn't seem to support any literal formatting which is why I tried to use the ``` to signal this. I will attach some images from both version to counter this effect and make it clearer to you where the problem is which is indeed in the clash between the state name and the size. The IEC prefixes were something new and we could handle that but not the lack of space which is new in this version we tried.
+
+Sent a patch: https://lists.nongnu.org/archive/html/qemu-block/2020-01/msg00376.html
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=804359b8b90f
+