鍦?2021/1/13 17:29, Peter Krempa 鍐欓亾:
On Wed, Jan 13, 2021 at 09:19:19 +0000, huangy81@xxxxxxxxxxxxxxx wrote:
Firstly, please don't CC libvirt developers directly, since we are
subscribed to the list, and we don't need a copy of your patches in our
inbox. In this case it's namely, me, Daniel Berrange, and Jan Tomko.
Thank you for remainding me. Now, I've seen the Authors.rst.in file and
do not try it anymore : )
From: Hyman <huangy81@xxxxxxxxxxxxxxx>
The test file disk-backing-chains-noindex.x86_64-latest.args has
'No newline at end of file', this patch rewrite it in case unexpected
behavior bewteen diffrent platform. See the details:
https://www.redhat.com/archives/libvir-list/2021-January/msg00626.html
See below.
Signed-off-by: Hyman <huangy81@xxxxxxxxxxxxxxx>
---
...sk-backing-chains-index.x86_64-latest.args | 169 +++++++++++++++++-
1 file changed, 168 insertions(+), 1 deletion(-)
mode change 120000 => 100644 tests/qemuxml2argvdata/disk-backing-chains-index.x86_64-latest.args
diff --git a/tests/qemuxml2argvdata/disk-backing-chains-index.x86_64-latest.args b/tests/qemuxml2argvdata/disk-backing-chains-index.x86_64-latest.args
deleted file mode 120000
index 549eb65512..0000000000
--- a/tests/qemuxml2argvdata/disk-backing-chains-index.x86_64-latest.args
+++ /dev/null
@@ -1 +0,0 @@
-disk-backing-chains-noindex.x86_64-latest.args
\ No newline at end of file
So this means that the
'tests/qemuxml2argvdata/disk-backing-chains-index.x86_64-latest.args'
file is a symlink to
'disk-backing-chains-noindex.x86_64-latest.args'.
Your patch removes the symlink and generates the contents.
That is fine, but the commit message is wrong in describing what's
happening.
Looking at what the patchset does, this actually is not required and I
presume that it's an artifact of the manual/scripted conversion process
you did on the '.args' files where the symlink was replaced by full
contents.
Indeed, the shell script handing the '.args' files doesn't take the
symlink into account. Thank you for helping me figure this out.
Since both files will most likely have the same contents even after your
patchset, we don't need to replace the symlink by a full copy of the
output so this patch can be dropped.
I have dropped the patch in the next version of patchset and extract the
first two patch into one merge request.
