[yocto] Ignoring Fetch errors for optional source.

[Beth 'pidge' Flanagan]

I've an odd use case that I wonder if anyone has a work around/way of
doing it.

I've a client who has contractors who can't have access to a certain
segment of the code base. So for example, a recipe will have a SRC_URI
for the main bit that everyone has access to, but an extra src_uri that
some people won't have access to.

I want to be able to just ignore any fetch/unpack errors if that extra
src is unfetchable. Thoughts on how to achieve this?

-b

[Burton, Ross]

Post by Beth 'pidge' Flanagan
I've an odd use case that I wonder if anyone has a work around/way of
doing it.
I've a client who has contractors who can't have access to a certain
segment of the code base. So for example, a recipe will have a SRC_URI
for the main bit that everyone has access to, but an extra src_uri that
some people won't have access to.
I want to be able to just ignore any fetch/unpack errors if that extra
src is unfetchable. Thoughts on how to achieve this?

One solution would be to have a global variable I_AM_SPECIAL which the
recipes can use:

SRC_URI = "http://public.com/tarball.tar.gz
${@oe.types.boolean(d.getVar("I_AM_SPECIAL")) and '
http://private.com/tarball.tar.gz'}"

That might work, and also add determinism.

Ross

[Beth 'pidge' Flanagan]

On 7 December 2016 at 13:00, Beth 'pidge' Flanagan

Post by Beth 'pidge' Flanagan
I've an odd use case that I wonder if anyone has a work around/way of
doing it.
I've a client who has contractors who can't have access to a
certain
segment of the code base. So for example, a recipe will have a SRC_URI
for the main bit that everyone has access to, but an extra src_uri that
some people won't have access to.
I want to be able to just ignore any fetch/unpack errors if that extra
src is unfetchable. Thoughts on how to achieve this?

One solution would be to have a global variable I_AM_SPECIAL which
SRC_URI = "http://public.com/tarball.tar.gz
'http://private.com/tarball.tar.gz'}"

Yeah, unfortunately, people don't neccessarily know they're special if
you get my meaning.
One way we've been trying this is like so:
    try:
        fetcher = bb.fetch2.Fetch(extra_uri, d)
        fetcher.download()
    except:
        pass
But this doesn't seem to be catching the fetch error.
-b

Post by Beth 'pidge' Flanagan
That might work, and also add determinism.
Ross

[Andre McCurdy]

On Wed, Dec 7, 2016 at 5:13 AM, Beth 'pidge' Flanagan

Yeah, unfortunately, people don't neccessarily know they're special if you
get my meaning.
fetcher = bb.fetch2.Fetch(extra_uri, d)
fetcher.download()
pass
But this doesn't seem to be catching the fetch error.

Even if it did work, how is sstate etc going to handle the effective
SRC_URI not being known until after you've tried to fetch all the
sources?

Perhaps better to run a test for "specialness" and set an
"I_AM_SPECIAL" variable from (a wrapper for) oe-init-build-env.

-b
That might work, and also add determinism.
Ross
--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--

[Khem Raj]

Post by Beth 'pidge' Flanagan
I've an odd use case that I wonder if anyone has a work around/way of
doing it.
I've a client who has contractors who can't have access to a certain
segment of the code base. So for example, a recipe will have a SRC_URI
for the main bit that everyone has access to, but an extra src_uri that
some people won't have access to.
I want to be able to just ignore any fetch/unpack errors if that extra
src is unfetchable. Thoughts on how to achieve this?

You can append them via bbappends in a layer of its own. and control the access
to that layer. If the layer does not exist in bblayers then those repos dont bother fetching

if there is a case where these additional stuff is must have then define

SRC_URI += “${ADDITIONAL_URIS}”
ADDITIONAL_URIS ? = “”

and let the layers fill this variables via bbappend and if it turns out to be empty in the end
you can raise parse errors,

basically look into RDK, there are several examples of such cases.

Post by Beth 'pidge' Flanagan
-b
--
www.toganlabs.com
--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--