On 9/9/2024 4:33 AM, Alexander Kanavin wrote:
On Thu, 5 Sept 2024 at 23:10, Ryan Eatmon <reat...@ti.com> wrote:
2) The uri for a sources entry in the json file automatically adds in
protocol=git even though I specified protocol=https on the line. We
prefer to always use the https for git repos and not the git protocol.
I modified the code to not do this so my testing could continue.
This is not the case. If the entry in the json starts with https://
then the tool will use protocol=https. Basically it needs to convert
URI that can be given to git on the command line into an SRC_URI type
string that can be given to bitbake's git fetcher.
You are correct. I assumed that the string was the same format as the
SRC_URI. This might be a little confusing for users as that means we
have two different interpretations for repo strings.
3) If we specify a unique key for each of the sources, why do we need to
then also specify a path to place the downloaded sources into? Why not
just use the same key value to reduce what all is needed to specify. We
can still support "path" for those that want it, but if it is left out I
would default it to the unique key for the repo.
Here I had simply followed the layer configuration schema that makes
path mandatory. Requiring a parameter has its advantages, you don't
have to ensure that the default is documented, standardized and all
tools follow the standard. You also don't lock yourself into the
default value that must be followed until the end of time.
Then what good is the key value for? The current patch does not use
r_name except to look up the value under layers. Should we just make
the JSON have this as an array of repos instead of a named hash?
Or is there some planned thing coming later that might make use of this key?
6) The code loops through the layers looking for scripts/oe-setup-build.
What would happen if I shipped a rogue layer with that file in it and
included it as the last layer in the sources?
I guess it would run that instead? If you include a rogue layer into
the config, there's lots of other rogue things it can do when bitbake
starts, but maybe you have a suggestion?
Ideally this would be locked to oe-core as that is what is intended.
But I'm not sure how best to do that.
Side topic, would it make sense to allow for the existence of a config
file in the repos that would allow them to "register" features that can
processed by bitbake-setup to configure various things that the layer
requires/offers? Right now we do this kind of thing for the
oe-setup-build script. But I could see the framework being useful for
this kind of thing.
7) I'm getting an error when running the setup-build script:
File "/scratch/builds/bitbake-setup-test/layers/setup-build", line
107, in setup_build_env
subprocess.run(cmd, shell=True, executable=os.environ['SHELL'])
File "/usr/lib/python3.10/os.py", line 679, in __getitem__
raise KeyError(key) from None
KeyError: 'SHELL'
SHELL is set to /bin/sh so I'm at a loss to see why this would be
failing. But because of this I never get a build.sh script.
For this I would really appreciate if you can get to the bottom of.
I'll take a look today and try to track it down.
Thanks,
Alex
--
Ryan Eatmon reat...@ti.com
-----------------------------------------
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2047):
https://lists.openembedded.org/g/openembedded-architecture/message/2047
Mute This Topic: https://lists.openembedded.org/mt/108293734/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
