[poky] Write-protect $DL_DIR

[Gary Thomas]

On 12/22/2010 07:51 AM, Gary Thomas wrote:
> On 12/21/2010 03:34 PM, Gary Thomas wrote:
> ... snip
>>
>> I've tried your changes and they solve my problem well, thanks.
>>
>
> I have had a problem with this (after more testing). Originally,
> I had DL_DIR="/work/misc/Poky/sources/", using it somewhat like
> a mirror. With your changes yesterday, I added these lines to
> my distro.conf:
>
> # Provide pre-staged sources
> PREMIRRORS_append = "\
> bzr://.*/.* file:///work/misc/Poky/sources/ \n \
> cvs://.*/.* file:///work/misc/Poky/sources/ \n \
> git://.*/.* file:///work/misc/Poky/sources/ \n \
> hg://.*/.* file:///work/misc/Poky/sources/ \n \
> osc://.*/.* file:///work/misc/Poky/sources/ \n \
> p4://.*/.* file:///work/misc/Poky/sources/ \n \
> svk://.*/.* file:///work/misc/Poky/sources/ \n \
> svn://.*/.* file:///work/misc/Poky/sources/ \n"
>
> MIRRORS_append = "\
> ftp://.*/.* file:///work/misc/Poky/sources/ \n \
> http://.*/.* file:///work/misc/Poky/sources/ \n \
> https://.*/.* file:///work/misc/Poky/sources/ \n"
>
> require conf/distro/include/my-fixed-revisions.inc
> require conf/distro/poky.conf
>
> I also disabled DL_DIR in local.conf, falling back to using
> "downloads" in my build tree (/work/local/new_p60).
>
> As you can see, my distro uses Poky as its base, just overriding
> and/or adding some features for our environment.
>
> With this setup, the build for gconf-dbus_svn fails in the
> unpack stage, with this error:
> NOTE: Unpacking /work/local/new_p60/downloads/trunk_developer.imendio.com_.svn.gconf-dbus_705_.tar.gz to
> /work/local/new_p60/tmp/work/armv7a-poky-linux-gnueabi/gconf-dbus-2.16.0+svnr705-r0/
> tar: /work/local/new_p60/downloads/trunk_developer.imendio.com_.svn.gconf-dbus_705_.tar.gz: Cannot open: No such file or directory
>
> Did I set this up incorrectly?

I've tracked down why this happens, but I've no idea how
to best fix it.

It seems that in bitbake/lib/bb/fetch/__init__.py, the PREMIRRORS
are used by the function go() to figure out where to find a file.
In the case of the SVN: URL used by the gconf-dbus_svn recipe,
this could be a staged tar file representing the SVN tree, which
does exist in my local mirror.  During the 'fetch' phase, all
works properly and fetch decides that the file is available
from the mirror as above.

The problem comes during unpack which is run as a separate step.
All the decisions about where to find the file that were computed
in fetch have been lost (new step, new context?) and unpack goes
looking for the file in downloads where it assumed fetch left it.
The confusion seems to only happen with URLs that need PREMIRROR
support.

Does this make any sense?


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------