|
Re: [layerindex-web] [PATCH] layerindex/utils.py: Add to baseconfig=True for bb.parse.handle()
Robert Yang
On 12/21/22 00:39, Tim Orling wrote:
On Mon, Dec 19, 2022 at 11:26 PM Robert Yang <liezhi.yang@... <mailto:liezhi.yang@...>> wrote:Glad to see that layerindex is back to active. I've also sent you another 3 patches just now: utils.py: Prefer the one which matches branchname for depends layer recipeparse.py: Checkout deplayerbranch before parsing util.py: Fix for removing non-existed dependencies I think that I had sent them before, but not get merged, layerindex may not work well without these fixes. // Robert Signed-off-by: Robert Yang <liezhi.yang@... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH 1/3] util.py: Fix for removing non-existed dependencies
Robert Yang
The previous code didn't work when there is no deps or recs, it would return
immediately without removing the on-existed dependencies, this patch fixes the problem. Signed-off-by: Robert Yang <liezhi.yang@...> --- layerindex/utils.py | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/layerindex/utils.py b/layerindex/utils.py index 9d94015..4b6aeca 100644 --- a/layerindex/utils.py +++ b/layerindex/utils.py @@ -109,6 +109,18 @@ def get_dependency_layer(depname, version_str=None, logger=None): return None +def remove_layerdeps(layer_name, need_remove, logger): + if need_remove: + import settings + remove_layer_dependencies = getattr(settings, 'REMOVE_LAYER_DEPENDENCIES', False) + if remove_layer_dependencies: + logger.info('Removing obsolete dependencies "%s" for layer %s' % (need_remove, layer_name)) + need_remove.delete() + else: + logger.warn('Dependencies "%s" are not in %s\'s conf/layer.conf' % (need_remove, layer_name)) + logger.warn('Either set REMOVE_LAYER_DEPENDENCIES to remove them from the database, or fix conf/layer.conf') + + def add_dependencies(layerbranch, config_data, logger=None): _add_dependency("LAYERDEPENDS", 'dependency', layerbranch, config_data, logger=logger) @@ -124,10 +136,15 @@ def _add_dependency(var, name, layerbranch, config_data, logger=None, required=T if layerbranch.collection: var_name = layerbranch.collection - dep_list = config_data.getVar("%s_%s" % (var, var_name), True) + need_remove = LayerDependency.objects.filter(layerbranch=layerbranch).filter(required=required) + if not dep_list: + # The need_remove contains all of the deps or recs according to + # required is True or False, remove deps or recs immediately if + # there are no deps or recs in conf/layer.conf + remove_layerdeps(layer_name, need_remove, logger) return try: @@ -136,7 +153,6 @@ def _add_dependency(var, name, layerbranch, config_data, logger=None, required=T logger.debug('Error parsing %s_%s for %s\n%s' % (var, var_name, layer_name, str(vse))) return - need_remove = LayerDependency.objects.filter(layerbranch=layerbranch).filter(required=required) for dep, ver_list in list(dep_dict.items()): ver_str = None if ver_list: @@ -177,15 +193,7 @@ def _add_dependency(var, name, layerbranch, config_data, logger=None, required=T layerdep.required = required layerdep.save() - if need_remove: - import settings - remove_layer_dependencies = getattr(settings, 'REMOVE_LAYER_DEPENDENCIES', False) - if remove_layer_dependencies: - logger.info('Removing obsolete dependencies "%s" for layer %s' % (need_remove, layer_name)) - need_remove.delete() - else: - logger.warn('Dependencies "%s" are not in %s\'s conf/layer.conf' % (need_remove, layer_name)) - logger.warn('Either set REMOVE_LAYER_DEPENDENCIES to remove them from the database, or fix conf/layer.conf') + remove_layerdeps(layer_name, need_remove, logger) def set_layerbranch_collection_version(layerbranch, config_data, logger=None): layerbranch.collection = get_layer_var(config_data, 'BBFILE_COLLECTIONS', logger) -- 2.37.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH 3/3] utils.py: Prefer the one which matches branchname for depends layer
Robert Yang
The meta-xilinx was mata-xilinx/meta-xilinx-bsps, and now upstream has changed
it to mata-xilinx/meta-xilinx-core, but get_dependency_layer always returns the first one (mata-xilinx/meta-xilinx-bsps) found, which causes errors like: $ ./update.py -b master-wr -l meta-xilinx-bsp ERROR: Dependency meta-xilinx of layer meta-xilinx-bsp does not have branch record for branch master-wr And for build: Layer 'wr-xilinx-zynqmp' depends on layer 'xilinx', but this layer is not enabled in your configuration Prefer the one which matches branchname to fix the problem Signed-off-by: Robert Yang <liezhi.yang@...> --- layerindex/utils.py | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/layerindex/utils.py b/layerindex/utils.py index 4b6aeca..a1f689d 100644 --- a/layerindex/utils.py +++ b/layerindex/utils.py @@ -75,7 +75,7 @@ def is_deps_satisfied(req_col, req_ver, collections): # Return False when not found return False -def get_dependency_layer(depname, version_str=None, logger=None): +def get_dependency_layer(depname, layerbranch, version_str=None, logger=None): from layerindex.models import LayerItem, LayerBranch # Get any LayerBranch with a layer that has a name that matches depmod, or @@ -87,13 +87,20 @@ def get_dependency_layer(depname, version_str=None, logger=None): if not res: return None - # If there is no version constraint, return the first one found. + # If there is no version constraint: if not version_str: + # Prefer the one which matches branchname + required_branchname = layerbranch.branch.name + for lb in res: + if required_branchname == lb.branch.name: + return lb.layer + + # Or return the first one found. return res[0].layer (operator, dep_version) = version_str.split() - for layerbranch in res: - layer_ver = layerbranch.version + for lb in res: + layer_ver = lb.version # If there is no version in the found layer, then don't use this layer. if not layer_ver: @@ -105,7 +112,7 @@ def get_dependency_layer(depname, version_str=None, logger=None): raise vse if success: - return layerbranch.layer + return lb.layer return None @@ -159,7 +166,7 @@ def _add_dependency(var, name, layerbranch, config_data, logger=None, required=T ver_str = ver_list[0] try: - dep_layer = get_dependency_layer(dep, ver_str, logger) + dep_layer = get_dependency_layer(dep, layerbranch, ver_str, logger) except bb.utils.VersionStringException as vse: if logger: logger.error('Error getting %s %s for %s\n%s' %(name, dep. layer_name, str(vse))) -- 2.37.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH 2/3] recipeparse.py: Checkout deplayerbranch before parsing
Robert Yang
Fixed:
$ ./update.py -b hardknott,master ERROR: Variable PREMIRRORS_append contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake. This is because it doesn't checkout master branch when parse it, this patch fixed the problem. Signed-off-by: Robert Yang <liezhi.yang@...> --- layerindex/recipeparse.py | 1 + 1 file changed, 1 insertion(+) diff --git a/layerindex/recipeparse.py b/layerindex/recipeparse.py index 6202745..6f2da0a 100644 --- a/layerindex/recipeparse.py +++ b/layerindex/recipeparse.py @@ -124,6 +124,7 @@ def setup_layer(config_data, fetchdir, layerdir, layer, layerbranch, logger): logger.warning('Recommends %s of layer %s does not have branch record for branch %s - ignoring' % (dep.dependency.name, layer.name, layerbranch.branch.name)) continue deplayerdir = os.path.join(deprepodir, deplayerbranch.vcs_subdir) + utils.checkout_layer_branch(deplayerbranch, deprepodir, logger) utils.parse_layer_conf(deplayerdir, config_data_copy) config_data_copy.delVar('LAYERDIR') return config_data_copy -- 2.37.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Error creating recipe for Perl DBI for postgresql in Kirkstone
On Tue, Dec 20, 2022 at 12:28 PM Fernando Luiz Cola <ferlzc@...> wrote:
There are several layers of problems here. If you look at https://metacpan.org/release/TURNSTEP/DBD-Pg-3.16.0/source/Makefile.PL#L42 you can see that we could set export POSTGRES_INCLUDE="${STAGING_INCDIR}" export POSTGERS_LIB="${STAGING_LIBDIR}" But, even with that, do_config will fail to find the postgres version. It depends on https://metacpan.org/pod/App::Info::RDBMS::PostgreSQL to find it, and we do not have a recipe for that? (even if we did it is probably going to be wrong... not cross-compilation). There is another variable POSTGRES_DATA, but it is not clear what the structure/value of that should be. Also, there is no native version/recipe of postgresql. In theory you could use that to be able to run /usr/bin/pg_config, but there are likely to be cross-compilation errors elsewhere. (The lack of postgresql-native also means BBCLASSEXTEND = "native" in your libdbd-postgresql-perl recipe is a lie). Short answer: this is not cross-compilation friendly |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Error creating recipe for Perl DBI for postgresql in Kirkstone
Hello, I'm trying to write a recipe a Perl DBI for postgresql. I'm follwing the same recipe found in:
https://layers.openembedded.org/layerindex/recipe/192563/ and https://layers.openembedded.org/layerindex/recipe/190989/ Howover I'm having errors regarding db_config path, which cannot be found during the do_configure
here is my following recipe: https://gist.github.com/ferlzc/9234ccd5c5a084f958ff52c7a08899a9 - I'm using Yocto Kirkstone
Any help is highly appreciated!
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [layerindex-web] [PATCH] layerindex/utils.py: Add to baseconfig=True for bb.parse.handle()
On Mon, Dec 19, 2022 at 11:26 PM Robert Yang <liezhi.yang@...> wrote: Bitbake's api has been changed via: Merged. Thank you! Signed-off-by: Robert Yang <liezhi.yang@...> |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Status 20 December 2022 (WW51)
Stephen Jolley
Current Dev Position: YP 4.2 M2 Next Deadline: 23th January 2023 YP 4.2 M2 Build
Next Team Meetings:
Key Status/Updates:
Ways to contribute:
YP 4.2 Milestone Dates:
Upcoming dot releases:
Tracking Metrics:
The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC
The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-4.0.6.rc1)
Jing Hui Tham
Hi All,
toggle quoted message
Show quoted text
QA for yocto-4.0.6.rc1 is completed. This is the full report for this release: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high milestone defects. No new issue found. Thanks, Jing Hui -----Original Message----- |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Issue with accessing network from a recipe
Gärding Antti
Hi,
I noticed that the another question was probably due to my own mistake: Accessing network from do_fetch seems to work, but I hadn’t noticed that I had left commands requiring network into do_compile even though I had moved those of them that were in do_configure to do_fetch.
Best regards, Antti Gärding
From: Gärding Antti <Antti.Garding@...>
Sent: Tuesday, December 20, 2022 9:42 To: Martin Jansa <martin.jansa@...> Cc: yocto@... Subject: Re: [yocto] Issue with accessing network from a recipe
Hi,
Thanks! That helped my team find out a solution or at least a work-around: setting do_configure[network] and do_compile[network] to "1" in local.conf.
I would have another related questions, though: Should the commands requiring network access work if they are invoked from do_fetch? I tried that and it didn't work.
Best regards, Antti Gärding |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-zephyr][master][langdale][PATCH] zephyr-kernel/3.1: update to latest commit
Naveen Saini
Recent commits have CVE-2022-2741 fixed.
Also backported CVE-2022-2993 fix. Signed-off-by: Naveen Saini <naveen.kumar.saini@...> --- ...ix-SMP-local-keys-check-when-startin.patch | 51 +++++++++++++++++++ .../zephyr-kernel/zephyr-kernel-src-3.1.0.inc | 3 +- 2 files changed, 53 insertions(+), 1 deletion(-) create mode 100644 meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch diff --git a/meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch b/meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch new file mode 100644 index 0000000..68650c3 --- /dev/null +++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch @@ -0,0 +1,51 @@ +From 74d26b70f080a5dc60c6a1aa2bfec38043ee30d4 Mon Sep 17 00:00:00 2001 +From: Joakim Andersson <joakim.andersson@...> +Date: Fri, 5 Aug 2022 10:50:47 +0200 +Subject: [PATCH] Bluetooth: host: Fix SMP local keys check when starting + encryption + +Fix SMP check of existing local keys when attempting to start security +with required security mode 1 level 4. The logic for checking the +conditions was wrong, leading to a situation where encryption would be +attempted to be started by the central instead of initiating a new +pairing procedure. This would fail when the connection was encrypted and +the connection would be disconnected. + +Upstream-Status: Backport [https://github.com/zephyrproject-rtos/zephyr/commit/83d5402fe830973f943bde085d80f0d3643e811a] +https://github.com/zephyrproject-rtos/zephyr/pull/52947/files +CVE: CVE-2022-2993 + +Signed-off-by: Joakim Andersson <joakim.andersson@...> +Signed-off-by: Naveen Saini <naveen.kumar.saini@...> +--- + subsys/bluetooth/host/smp.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +diff --git a/subsys/bluetooth/host/smp.c b/subsys/bluetooth/host/smp.c +index 02a847f97d..555f09fefd 100644 +--- a/subsys/bluetooth/host/smp.c ++++ b/subsys/bluetooth/host/smp.c +@@ -357,15 +357,15 @@ static bool smp_keys_check(struct bt_conn *conn) + return false; + } + +- if (conn->required_sec_level > BT_SECURITY_L2 && ++ if (conn->required_sec_level >= BT_SECURITY_L3 && + !(conn->le.keys->flags & BT_KEYS_AUTHENTICATED)) { + return false; + } + +- if (conn->required_sec_level > BT_SECURITY_L3 && +- !(conn->le.keys->flags & BT_KEYS_AUTHENTICATED) && +- !(conn->le.keys->keys & BT_KEYS_LTK_P256) && +- !(conn->le.keys->enc_size == BT_SMP_MAX_ENC_KEY_SIZE)) { ++ if (conn->required_sec_level >= BT_SECURITY_L4 && ++ !((conn->le.keys->flags & BT_KEYS_AUTHENTICATED) && ++ (conn->le.keys->keys & BT_KEYS_LTK_P256) && ++ (conn->le.keys->enc_size == BT_SMP_MAX_ENC_KEY_SIZE))) { + return false; + } + +-- +2.25.1 + diff --git a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc index 68016e4..b3feb6a 100644 --- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc +++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc @@ -2,7 +2,7 @@ SRCREV_FORMAT = "default" -SRCREV_default = "2ddd73feafd3316af2c547c34d6969bea637d5c6" +SRCREV_default = "a7d946331f4f9361d1531984524dd8f151ae20b0" SRCREV_canopennode = "53d3415c14d60f8f4bfca54bfbc5d5a667d7e724" SRCREV_chre = "0edfe2c2ec656afb910cfab8ed59a5ffd59b87c8" SRCREV_civetweb = "094aeb41bb93e9199d24d665ee43e9e05d6d7b1c" @@ -109,6 +109,7 @@ SRC_URI_ZSCILIB ?= "git://github.com/zephyrproject-rtos/zscilib;protocol=https" SRC_URI_PATCHES ?= "\ file://0001-3.1-cmake-add-yocto-toolchain.patch;patchdir=zephyr \ file://0001-3.1-x86-fix-efi-binary-generation-issue-in-cross-compila.patch;patchdir=zephyr \ + file://0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch;patchdir=zephyr \ " SRC_URI = "\ -- 2.25.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Issue with accessing network from a recipe
Gärding Antti
Hi,
Thanks! That helped my team find out a solution or at least a work-around: setting do_configure[network] and do_compile[network] to "1" in local.conf.
I would have another related questions, though: Should the commands requiring network access work if they are invoked from do_fetch? I tried that and it didn't work.
Best regards,
Antti Gärding
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[layerindex-web] [PATCH] layerindex/utils.py: Add to baseconfig=True for bb.parse.handle()
Robert Yang
Bitbake's api has been changed via:
afb8478d3 parse: Add support for addpylib conf file directive and BB_GLOBAL_PYMODULES The conf file won't be parsed without baseconfig=True: bb.parse.ParseError: ParseError at /path/to/oe-core/meta/conf/layer.conf:132: unparsed line: 'addpylib ${LAYERDIR}/lib oe' Signed-off-by: Robert Yang <liezhi.yang@...> --- layerindex/utils.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/layerindex/utils.py b/layerindex/utils.py index 6566710..9d94015 100644 --- a/layerindex/utils.py +++ b/layerindex/utils.py @@ -314,7 +314,10 @@ def is_branch_valid(layerdir, branch): def parse_conf(conf_file, d): if hasattr(bb.parse, "handle"): # Newer BitBake - data = bb.parse.handle(conf_file, d, include=True) + if hasattr(bb.parse.parse_py.ConfHandler, "__addpylib_regexp__"): + data = bb.parse.handle(conf_file, d, include=True, baseconfig=True) + else: + data = bb.parse.handle(conf_file, d, include=True) else: # Older BitBake (1.18 and below) data = bb.cooker._parse(conf_file, d) -- 2.37.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW51
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW50!
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Current high bug count owners for Yocto Project 4.2
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Newcomer & Unassigned Bugs - Help Needed
Stephen Jolley
All,
The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.
Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 414 unassigned or newcomer bugs.
We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “4.2”, “4.3”, "4.99" and "Future", the more pressing/urgent issues being in "4.2" and then “4.3”.
Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Issue with accessing network from a recipe
Martin Jansa
Hi, that is intentional, recipes should fetch sources with bitbake fetcher (which respects MIRROR/PREMIRROR/DL_DIR etc) in do_fetch and network shouldn't be used in other tasks (unless explicitly enabled in well explained exceptions). bitbake can now restrict network access in various tasks based on "network" flag as implemented in: https://git.openembedded.org/bitbake/commit/?id=0746b6a2a32fec4c18bf1a52b1454ca4c04bf543 https://git.openembedded.org/bitbake/commit/?id=9d6341df611a1725090444f6f8eb0244aed08213 and oe now enables network mostly only in do_fetch and few special tasks as implemented in: https://git.openembedded.org/openembedded-core/commit/?id=7ce1e88a3ad85bbb925bb9f7167dc0a5fd1c27f4 Regards, On Mon, Dec 19, 2022 at 2:02 PM Gärding Antti via lists.yoctoproject.org <Antti.Garding=etteplan.com@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue with accessing network from a recipe
Gärding Antti
Hi,
I am having an issue with a recipe whose do_configure requires network connections and I wonder if this issue could be related to Yocto so that this list would be the correct place to ask for ideas.
The problem appears when trying to build dotnet-hello-world which comes with meta-dotnet (https://github.com/jeremy-prater/meta-dotnet). I am not the only one having this issue, but many people, including the layer's author, also report having no problems. Googling gives a lot of suggestions, but as this is related to .NET, all of them are related to Windows / Visual Studio environment and I don't know how to apply them using Yocto.
In short, do_configure for dotnet-hello-world invokes the .NET SDK's tool dotnet as a host tool to fetch what is needed to build and run the program. As a part of that, it uses NuGet, the package manager for .NET, which says "error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json".
If I modify the recipe so that it tries to curl that file, I get "Could not resolve host: api.nuget.org". If I do the same but use numeric address, I get "Couldn't connect to server".
If I run the commands in the recipe manually in the same environment I use for Yocto builds, using .NET SDK I have installed manually, they work.
My build environment is Ubuntu 20.04 run inside a Docker container.
Best regards, Antti Gärding |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: rust issue for armv6 in mainline poky
Mirza Krak
Den mån 21 nov. 2022 kl 13:37 skrev Alexander Kanavin <alex.kanavin@...>: Can you try the tip of master please? Also came across this issue. Tip of master works just fine. / Mirza |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|