On Sat, 28 Dec 2019 at 00:52, Kent Dorfman <[email protected]
<mailto:[email protected]>> wrote:
On 12/27/19, Josef Holzmayr <[email protected]
<mailto:[email protected]>> wrote:
> Hello Kent!
thanks for the followup!
> "close" is really somewhat relative here. The words that trigger my
> alarm here are "mission critical" and "aerospace". Anything that
I will
> write below is no legal advice, and not fit for any form of
> certification or audit. If these are your requirements, then
there are
> companies in the Yocto ecosystem that are willing to offer their
> services.
yeah...no legal advice is expected online...just a forum to vent
in, sometimes.
> BSPs are a constant cause of pain for us giving Yocto support
too. If
> a board vendor screws up, we get to pick up the pieces too many
times.
Yup...been there, done that.
> Little to add, besides... that it might have been a bad choice or
> negotiation, if you're only now learning that they want to
charge you
> additionally. Thats something we obviously can't help you with.
Yes, very bad choice in a field with no notably good choices.
> If they are not willing to hand out all sources plus metadata
layers,
> then thats a total red flag. Yet again, not something we could
change.
OK, to be clear, I have access to meta-layers, but a large percentage
of the BB files point to private git repos, and they don't volunteer
the gitshallow for a repo unless I know enough to specifically ask
them for that repo, and assuming it's not something they are claiming
is IP.
> Sorry, I mean... didn't you request at least some form of eval
kit? Demo
> boards? To actually understand what you are buying?
bad decisions were made before I came on-board, and I did ask them for
access to the SDK before we took dilivery of hardware, and they balked
at that idea...which justifiably left me with an uneasy feeling. Of
course I would have denied delivery if I had seen the state of their
reference SDK beforehand.
> Up to this point, yes, I can feel your frustration, but there's
little
> to say other than that you probably have a bad partnership by now.
Oh yeah, I think we're about to head into the "grudgingly conformant"
phase of the relationship.
> The cleanest without throwing away the whole build that you can
do is
> remove everything in the build directory besides "conf". Yet
there are
> probably two sides to your actual question. a "bitbake -c clean
> $YOURRECIPE" is the perfect equivalent to make clean, "bitbake
> $YOURRECIPE" equivalates to "make". Wiping tmp and sstate cache is
> pretty close to a full clean rebuild of the whole system, and no, it
> shall not break. If it does, there is either something wrong
with your
> build setup (can happen) or you hit a bug (happens less often, but
> happens too). The second side is actually running a full system
rebuild,
> which includes the complete build setup. Actually there is no
> Yocto-inhernt way to do it, as different people have different
needs -
> and nobody managed a one size fits all solution until now. You
can look
> at the autobuilder as provided by the Yocto Project, and at the
various
> approaches here [1];
I empty the conf/ sstate_cache/ and tmp/ directories and try to do a
devtool build-image, but failures ensue based on it trying to load
from private git repos, and some jibberish about locked signatures not
matching. I just need to know that I'm reverting to a source level
build "the right way".
>> 2) related to above, yocto needs a much better description of the
>> expected directory tree within a project.
>
> Within a project? Could you please elaborate?
They provided and "ark" embedded SDK, that was presumably generated
from yocto. I'm not differentiating between projects because there is
only one, so I'm mean within the SDK directory tree.
> bitbake and devtool can and should be used side by side. Running
bitbake
> manually, as you put it, is the definitively primary way of doing
> things. So if that eeks out for, there is probably something strange
> with your setup. If you can provide a more extensive log or error
> message, we will happily...erm, at least honestly try to help.
Thanks. bitbake fails when run manually, telling me that there is a
"." or null path element when I know for a fact that there is not one.
Apparently when devtool calls bitbake it sets up the path correctly,
but when it is called manually (it's not in the shell path), it
doesn't like the PATH var. There are some online references to this
problem but no authoritative solution or description of why.
>> 5) a big area that seems to be lacking is the ability to
inquire in a
>> yocto build as to what is included in it. This is especially
>> important if the responsible party didn't actually create the
build,
>> as is our case. We're left with trying to guess what the OEM
did, and
>> why.
>
> Now this is certainly not true. Even in the utmost default setup, a
> manifest file will be created along the image which tells you which
> packages including version and license that went into it.
A manifest shows packages, not layers/recipes/packages, nor a
breakdown of what is included as a consequence of what layers or
recipes it exists in. This makes trying to modify a build that
someone else has created, more difficult.
> bitbake -g $TARGETOFYOURCHOICE will give you a dot file to
inspect the
> complete dependency graph of your chosen target. This is a bit
too much
> in-depth at times, but extremely powerful.
TARGETOFYOURCHOICE? What is the glue between "target-name" and
available meta-layers and recipes?
> And last but not least, its a good practise to have buildhistory
enabled
> [2]. This offers extremely detailed information about each and every
> package and dependency that went into your build, down to each
single
> file, package size,...
Agreed. I think their SDK has it enabled by default but I need to
check.
> Including pre-produced blobs in a Yocto build is not pretty, but
often
> handy or impossible to avoid. Please see [3] for the
documentation on
> it.
Well, unless they give us git access I don't see any way around it.
> In a nutshell: whenever somebody hands you a binary build,
without the
> corresponding set of sources and metadata, then you are out of
luck and
> in for a lot of pain. That exactly the way of how to NOT use
yocto when
> selling hardware. Some do, and unfortunately we, as the Yocto
community
> can't do much about it, other than try and help the folks who
struggle
> with it. And go buy our hardware in another place.
I wish I did have options, but if you know business, they are all
about free, as long as it doesn't pose any encumberance on them. I
need to see just how far the OEM is will to go, and if not far enough,
then I've to evaluate other options.
> With that, I hope I could give a somewhat helpful but certainly
> honest answer.
Gracias, Amigo!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#47827):
https://lists.yoctoproject.org/g/yocto/message/47827
Mute This Topic: https://lists.yoctoproject.org/mt/69288358/1686489
Group Owner: [email protected]
<mailto:yocto%[email protected]>
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected] <mailto:[email protected]>]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#47828): https://lists.yoctoproject.org/g/yocto/message/47828
Mute This Topic: https://lists.yoctoproject.org/mt/69288358/3618653
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
