[libvirt] [PATCH] tests: Fix the build failure on s390
The build works fine on other architectures with commit 0b4f76fc5, but for s390: TEST: virscsitest 1) test1 ... OK 2) test2 ... libvirt: error : SCSI device '1:0:0:0': could not access /builddir/build/BUILD/libvirt-1.1.1/tests/virscsidata/sg8: No such file or directory FAILED It's caused by the "patch" on the s390 system either doesn't create the "empty files", or removed them after the patch was applied. Anyway, this patch is to fix it by simply adding useless numbers to the 2 test input files. --- tests/virscsidata/sg0 | 1 + tests/virscsidata/sg8 | 1 + 2 files changed, 2 insertions(+) diff --git a/tests/virscsidata/sg0 b/tests/virscsidata/sg0 index e69de29..573541a 100644 --- a/tests/virscsidata/sg0 +++ b/tests/virscsidata/sg0 @@ -0,0 +1 @@ +0 diff --git a/tests/virscsidata/sg8 b/tests/virscsidata/sg8 index e69de29..45a4fb7 100644 --- a/tests/virscsidata/sg8 +++ b/tests/virscsidata/sg8 @@ -0,0 +1 @@ +8 -- 1.8.1.4
On Mon, Feb 10, 2014 at 21:35:18 +0800, Osier Yang wrote:
The build works fine on other architectures with commit 0b4f76fc5, but for s390:
TEST: virscsitest 1) test1 ... OK 2) test2 ... libvirt: error : SCSI device '1:0:0:0': could not access /builddir/build/BUILD/libvirt-1.1.1/tests/virscsidata/sg8: No such file or directory FAILED
It's caused by the "patch" on the s390 system either doesn't create the "empty files", or removed them after the patch was applied. Anyway, this patch is to fix it by simply adding useless numbers to the 2 test input files.
This is pretty strange. AFAIK no patch binary creates empty files although git does that. If the build failed just because of that, it should have failed on other archs too. Jirka
On 10/02/14 21:48, Jiri Denemark wrote:
On Mon, Feb 10, 2014 at 21:35:18 +0800, Osier Yang wrote:
The build works fine on other architectures with commit 0b4f76fc5, but for s390:
TEST: virscsitest 1) test1 ... OK 2) test2 ... libvirt: error : SCSI device '1:0:0:0': could not access /builddir/build/BUILD/libvirt-1.1.1/tests/virscsidata/sg8: No such file or directory FAILED
It's caused by the "patch" on the s390 system either doesn't create the "empty files", or removed them after the patch was applied. Anyway, this patch is to fix it by simply adding useless numbers to the 2 test input files. This is pretty strange. AFAIK no patch binary creates empty files although git does that. If the build failed just because of that, it should have failed on other archs too.
It's depended on the version of *patch*, for example, the attached patch creates two files, file "aaa" is not empty, "bbb" is empty: % cat aaa Hello, World! % cat bbb *On Fedora 19:* % patch -p1 < 0001-Funny-empty-files.patch patching file aaa % ls aaa bbb ls: cannot access bbb: No such file or directory aaa % patch --version | head -1 patch 2.6.1 *On RHEL7.0:* % patch -p1 < 0001-Funny-empty-files.patch patching file aaa patching file bbb % ls aaa bbb aaa bbb % patch --version | head -1 GNU patch 2.7.1 Note that on Fedora 19, the output of the patch command only says "patching file aaa", for the empty file "bbb", nothing was happened, this is what exactly I saw in the build.log from your scratch build (the failed one, sorry for that, btw). Osier
On 10/02/14 22:31, Osier Yang wrote:
On 10/02/14 21:48, Jiri Denemark wrote:
On Mon, Feb 10, 2014 at 21:35:18 +0800, Osier Yang wrote:
The build works fine on other architectures with commit 0b4f76fc5, but for s390:
TEST: virscsitest 1) test1 ... OK 2) test2 ... libvirt: error : SCSI device '1:0:0:0': could not access /builddir/build/BUILD/libvirt-1.1.1/tests/virscsidata/sg8: No such file or directory FAILED
It's caused by the "patch" on the s390 system either doesn't create the "empty files", or removed them after the patch was applied. Anyway, this patch is to fix it by simply adding useless numbers to the 2 test input files. This is pretty strange. AFAIK no patch binary creates empty files although git does that. If the build failed just because of that, it should have failed on other archs too.
It's depended on the version of *patch*, for example, the attached patch creates two files, file "aaa" is not empty, "bbb" is empty:
% cat aaa Hello, World!
% cat bbb
*On Fedora 19:*
% patch -p1 < 0001-Funny-empty-files.patch patching file aaa
% ls aaa bbb ls: cannot access bbb: No such file or directory aaa
% patch --version | head -1 patch 2.6.1
*On RHEL7.0:*
% patch -p1 < 0001-Funny-empty-files.patch patching file aaa patching file bbb
% ls aaa bbb aaa bbb
% patch --version | head -1 GNU patch 2.7.1
Note that on Fedora 19, the output of the patch command only says "patching file aaa", for the empty file "bbb", nothing was happened, this is what exactly I saw in the build.log from your scratch build (the failed one, sorry for that, btw).
We have other empty empty files too (the test input files, the only ones which are empty in the source, except ChangeLog and AUTHORS): % find tests -type f -empty tests/fchostdata/fc_host/host4/vport_delete tests/fchostdata/fc_host/host4/vport_create tests/fchostdata/fc_host/host5/vport_delete tests/fchostdata/fc_host/host5/vport_create tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-address-clash.args tests/xencapsdata/xen-ppc64.cpuinfo tests/qemuhelpdata/qemu-kvm-0.12.3-device tests/qemuhelpdata/qemu-0.12.1-device But since all of above are not created by the *.patch, instead, they are in the tarball (libvirt-$version.tar.gz), so the problem was hidden Osier
On 02/10/2014 06:35 AM, Osier Yang wrote:
The build works fine on other architectures with commit 0b4f76fc5, but for s390:
TEST: virscsitest 1) test1 ... OK 2) test2 ... libvirt: error : SCSI device '1:0:0:0': could not access /builddir/build/BUILD/libvirt-1.1.1/tests/virscsidata/sg8: No such file or directory FAILED
It's caused by the "patch" on the s390 system either doesn't create the "empty files", or removed them after the patch was applied. Anyway, this patch is to fix it by simply adding useless numbers to the 2 test input files. --- tests/virscsidata/sg0 | 1 + tests/virscsidata/sg8 | 1 + 2 files changed, 2 insertions(+)
Why are we modifying upstream? This sounds like a downstream issue with patch application, so downstream should come up with alternative ways to create empty files into existence when applying patches, without modifying the content of the empty file upstream. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 11/02/14 00:48, Eric Blake wrote:
The build works fine on other architectures with commit 0b4f76fc5, but for s390:
TEST: virscsitest 1) test1 ... OK 2) test2 ... libvirt: error : SCSI device '1:0:0:0': could not access /builddir/build/BUILD/libvirt-1.1.1/tests/virscsidata/sg8: No such file or directory FAILED
It's caused by the "patch" on the s390 system either doesn't create the "empty files", or removed them after the patch was applied. Anyway, this patch is to fix it by simply adding useless numbers to the 2 test input files. --- tests/virscsidata/sg0 | 1 + tests/virscsidata/sg8 | 1 + 2 files changed, 2 insertions(+) Why are we modifying upstream? This sounds like a downstream issue with
On 02/10/2014 06:35 AM, Osier Yang wrote: patch application, so downstream should come up with alternative ways to create empty files into existence when applying patches, without modifying the content of the empty file upstream.
Hacking the way of applying the patch works for downstream, but I don't think it's guraranteed same problem must not happen for upstream release. Osier
On Tue, Feb 11, 2014 at 11:10:16AM +0800, Osier Yang wrote:
On 11/02/14 00:48, Eric Blake wrote:
The build works fine on other architectures with commit 0b4f76fc5, but for s390:
TEST: virscsitest 1) test1 ... OK 2) test2 ... libvirt: error : SCSI device '1:0:0:0': could not access /builddir/build/BUILD/libvirt-1.1.1/tests/virscsidata/sg8: No such file or directory FAILED
It's caused by the "patch" on the s390 system either doesn't create the "empty files", or removed them after the patch was applied. Anyway, this patch is to fix it by simply adding useless numbers to the 2 test input files. --- tests/virscsidata/sg0 | 1 + tests/virscsidata/sg8 | 1 + 2 files changed, 2 insertions(+) Why are we modifying upstream? This sounds like a downstream issue with
On 02/10/2014 06:35 AM, Osier Yang wrote: patch application, so downstream should come up with alternative ways to create empty files into existence when applying patches, without modifying the content of the empty file upstream.
Hacking the way of applying the patch works for downstream, but I don't think it's guraranteed same problem must not happen for upstream release.
IIUC, there is no way why this should not work upstream. Therefore if any downstream has problems with back-porting such patches, they should make sure their patch usage works with such patches, for example by using 'patch -E' in building scripts, '%patch -E' in spec-file, etc. Martin
Osier
On 11/02/14 18:21, Martin Kletzander wrote:
On Tue, Feb 11, 2014 at 11:10:16AM +0800, Osier Yang wrote:
On 11/02/14 00:48, Eric Blake wrote:
The build works fine on other architectures with commit 0b4f76fc5, but for s390:
TEST: virscsitest 1) test1 ... OK 2) test2 ... libvirt: error : SCSI device '1:0:0:0': could not access /builddir/build/BUILD/libvirt-1.1.1/tests/virscsidata/sg8: No such file or directory FAILED
It's caused by the "patch" on the s390 system either doesn't create the "empty files", or removed them after the patch was applied. Anyway, this patch is to fix it by simply adding useless numbers to the 2 test input files. --- tests/virscsidata/sg0 | 1 + tests/virscsidata/sg8 | 1 + 2 files changed, 2 insertions(+) Why are we modifying upstream? This sounds like a downstream issue with
On 02/10/2014 06:35 AM, Osier Yang wrote: patch application, so downstream should come up with alternative ways to create empty files into existence when applying patches, without modifying the content of the empty file upstream.
Hacking the way of applying the patch works for downstream, but I don't think it's guraranteed same problem must not happen for upstream release.
IIUC, there is no way why this should not work upstream. Therefore if any downstream has problems with back-porting such patches, they should make sure their patch usage works with such patches, for example by using 'patch -E' in building scripts, '%patch -E' in spec-file, etc.
Okay, I'm fine with hacking downstream, with hoping the patch set for "shareable" SCSI host device won't be backported much. Btw, "patch -E" removes the empty files after the patch is applied, this is what I'm trying to avoid, the right way is to use "patch --posix". Osier
participants (4)
-
Eric Blake -
Jiri Denemark -
Martin Kletzander -
Osier Yang