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.

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).

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.

On Tue, Feb 11, 2014 at 11:10:16AM +0800, Osier Yang wrote: > On 11/02/14 00:48, Eric Blake wrote: >> 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. >> > 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.