3 files changed, 168 insertions, 0 deletions
diff --git a/results/classifier/118/none/603 b/results/classifier/118/none/603
new file mode 100644
index 00000000..b65a6a2a
--- /dev/null
+++ b/results/classifier/118/none/603
@@ -0,0 +1,31 @@
+device: 0.758
+architecture: 0.682
+performance: 0.572
+graphic: 0.477
+network: 0.461
+permissions: 0.432
+x86: 0.431
+i386: 0.339
+debug: 0.331
+mistranslation: 0.324
+files: 0.321
+peripherals: 0.320
+virtual: 0.309
+semantic: 0.303
+boot: 0.274
+register: 0.265
+hypervisor: 0.252
+arm: 0.246
+PID: 0.228
+user-level: 0.192
+VMM: 0.176
+TCG: 0.166
+vnc: 0.114
+kernel: 0.098
+ppc: 0.084
+socket: 0.084
+risc-v: 0.083
+assembly: 0.074
+KVM: 0.012
+
+Unable to use mps2-an386 machine with qemu-6.0.0 version code
diff --git a/results/classifier/118/none/603872 b/results/classifier/118/none/603872
new file mode 100644
index 00000000..5c9e764e
--- /dev/null
+++ b/results/classifier/118/none/603872
@@ -0,0 +1,80 @@
+performance: 0.720
+graphic: 0.657
+device: 0.632
+PID: 0.576
+ppc: 0.544
+architecture: 0.526
+vnc: 0.521
+arm: 0.492
+hypervisor: 0.478
+files: 0.477
+semantic: 0.467
+VMM: 0.465
+network: 0.452
+i386: 0.431
+TCG: 0.421
+KVM: 0.418
+x86: 0.417
+kernel: 0.415
+user-level: 0.392
+debug: 0.371
+register: 0.369
+peripherals: 0.361
+assembly: 0.341
+permissions: 0.328
+socket: 0.326
+mistranslation: 0.319
+risc-v: 0.308
+virtual: 0.252
+boot: 0.237
+
+[Feature request] qemu-img image conversion does not show percentage
+
+It will be nice if qemu-img will be able to show percentage of completition and average speed of conversion and compress ratio (if converting to compressed qcow or qcow2)
+
+qemu-img convert -p does show a percentage completion (but not avg speed or compression ratio) so this is at least partially done.
+
+Incomplete patch.
+
+Usecase: `qemu-img convert` with -p now shows the write speed.
+
+1. I'm calculating the speed using the time taken to run the for(;;)
+at qemu-img.c:1477. I figured that every time this loop runs, n1
+sectors are converted, and so I calculate the write_speed
+accordingly. Is this correct?
+
+2. I have changed qemu-progress.c:qemu_progress_print() to take in a
+speed parameter, thinking that it would be the best option. Should I
+do it some other way instead (maybe write another function to print
+just speed)?
+
+On Mon, Nov 18, 2013 at 03:55:45PM -0000, Varad wrote:
+> Incomplete patch.
+> 
+> Usecase: `qemu-img convert` with -p now shows the write speed.
+> 
+> 1. I'm calculating the speed using the time taken to run the for(;;)
+> at qemu-img.c:1477. I figured that every time this loop runs, n1
+> sectors are converted, and so I calculate the write_speed
+> accordingly. Is this correct?
+> 
+> 2. I have changed qemu-progress.c:qemu_progress_print() to take in a
+> speed parameter, thinking that it would be the best option. Should I
+> do it some other way instead (maybe write another function to print
+> just speed)?
+> 
+> ** Patch added: "[PATCH/RFC]"
+>    https://bugs.launchpad.net/qemu/+bug/603872/+attachment/3911803/+files/0001-qemu-img-show-image-conversion-speed.patch
+
+Patches attached on the bug tracker are not reviewed, they should be
+sent to the qemu-devel mailing list instead.
+
+If you want to link to a submitted patch from launchpad, please post a
+mailing list archive link.  For example:
+http://article.gmane.org/gmane.comp.emulators.qemu/242109
+
+
+Progress printing had been added here:
+https://gitlab.com/qemu-project/qemu/-/commit/6b837bc4a4d
+So I think it should be fine to close this ticket now.
+
diff --git a/results/classifier/118/none/603878 b/results/classifier/118/none/603878
new file mode 100644
index 00000000..8fd629ff
--- /dev/null
+++ b/results/classifier/118/none/603878
@@ -0,0 +1,57 @@
+graphic: 0.742
+semantic: 0.676
+mistranslation: 0.625
+device: 0.548
+performance: 0.509
+register: 0.449
+vnc: 0.402
+ppc: 0.383
+network: 0.374
+files: 0.364
+architecture: 0.344
+permissions: 0.332
+socket: 0.329
+PID: 0.323
+user-level: 0.298
+x86: 0.274
+hypervisor: 0.269
+peripherals: 0.268
+virtual: 0.243
+kernel: 0.235
+TCG: 0.231
+risc-v: 0.220
+debug: 0.217
+VMM: 0.197
+KVM: 0.137
+i386: 0.137
+assembly: 0.134
+boot: 0.131
+arm: 0.122
+
+[Feature request] qemu-img option about recompressing
+
+Suppose I have a fresh compressed qcow2 image. After some time the data were recorded without compression. I decide to make "QEMU-IMG convert" for that image to reduce its size.
+
+I want a new option, which selects between the two algorithms overdriven images:
+1. extract all / compress again when converting images (in the current implementation)
+2. compress only uncompressed blocks and just copy the compressed blocks without re-compression.
+
+This option is only needed when converting compressed image to compressed and the compression algorithm is the same.
+
+(text was translated by translate.google.com)
+overdriven=re-compressing
+recorded=written
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/81
+
+