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