[yocto] can not build yocto on NFS mounted NAS

[lothar at denx.de]

Am 2013-08-18 22:44, schrieb Robert Berger:
> Hi,
> 
> Just for the record I was able to remove the hard link with a small
> patch and now things look good (so far) - although it will consume more
> disk space.
> 
> diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py
> index faa0f61..3225993 100644
> --- a/meta/lib/oe/path.py
> +++ b/meta/lib/oe/path.py
> @@ -90,7 +90,7 @@ def copyhardlinktree(src, dst):
>          if not len(os.listdir(src)):
>              return
>          src = src + "/*"
> -    cmd = 'cp -al %s %s' % (src, dst)
> +    cmd = 'cp -a %s %s' % (src, dst)
>      check_output(cmd, shell=True, stderr=subprocess.STDOUT)
> 
>  def remove(path, recurse=True):
> 
> Regards,
> 
> Robert
> ..."But I have a slowly coagulating theory that the size of a project 
> is
> directly proportional to the possibility that significant bugs will 
> crop
> up. Exponentiate for each additional programmer involved." - Steven K.
> Halliburton
> 
> My public pgp key is available,at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
> 
> 
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Hi,
  I have just two points here to ask:

1) Wouldn't simply using SSTATE_MIRRORS be a better solution here, 
instead?

2) Patch: wouldn't it be nicer to try the cp -al, and catch the 
CalledProcessError Exception, if it is thrown, and then run the brute 
force cp -a? Perhaps even as a general approach?

[I didn't test it either practically, just, sometimes one may get the 
impression in yocto / bitbake, that a bit more exception handling and 
directly related error messages already are one of the worlds most 
expensive things to do.. pls, improve this situation!! ;) ]

BR,
Lothar