Re: [yocto] Dealing with go dependencies in recipes - native docker-compose

2022-10-11 Thread Bruce Ashfield 
On Tue, Oct 11, 2022 at 2:51 PM Konstantin Kletschke <
konstantin.kletsc...@inside-m2m.de> wrote:

> Today I realized, that the docker-compose in the meta-virtualization
> layer is the old python3 based one and a native solution is available. I
> tried to make a recipe for it to get rid of python3 (no other packages
> uses it in our setup) and the current python3-docker-compose is broken:
>
>
> https://lore.kernel.org/yocto-meta-virtualization/49660ea1-cd22-40db-98c7-c43f38a72...@ieee.org/


Adding the missing setuptools does get things working.



>
>
> I tried to build the native solution proposed in
> https://github.com/docker/compose/tree/v2.11.2.
>

I actually have a prototype recipe for this that I was working on before
ELCe, but I didn't get it into meta-virtualization yet, as it had a few
rough edges.

If you give me a few days, I can post it to the meta-virtualization list,
but I'm on the road right now and don't have access to all my build
machines.

>
> So my current recipe docker-compose_2.11.2.bb looks like this:
>
> LICENSE = "Apache-2.0"
>
> inherit go
> inherit go-mod
>
> GO_IMPORT = "github.com/docker/compose"
>
> SRC_URI = "git://${GO_IMPORT};protocol=https;branch=v2"
> # v2.11.2
> SRCREV = "616777eb4ad4d1101622d6727d9b7adaeb7943bb"
>
> # S = "${WORKDIR}/git"
>
> DEPENDS = "docker-ce"
> RDEPENDS:${PN} = "docker-ce-cli"
>
> With this I run into the issue, that go want's to download stuff while
> compiling. Which is forbidden and breaks the reliable build proposal.
> Totally understandable. Looks similair to this:
>
> dial tcp: lookup proxy.golang.org: Temporary failure in name resolution
>
> I read about a proposal allowing this by adding do_compile[network] =
> "1" to meta/classes/go.bb:
>
> https://lore.kernel.org/all/20220228235433.3948994-1-and...@gherzan.com/
>
> Of course, if this works, the reliable build thingy is gone, but while
>

Right, it works, but would never make it into core due to it bypassing many
of the fetcher properties.



> trying I discovered go loads external stuff, compiles it too.
> In my case (I have kirkstone with go-1.17) I run into modules demanding
> a go more recent:
>
> ASH[build k8s.io/client-go/applyconfigurations/autoscaling/v2beta2]:
> "file containerresourcemetricsource.go Mas4-HIX5lGBEQNTIo58\n"
> # github.com/docker/compose/v2/pkg/utils
> pkg/utils/slices.go:23:6: missing function body
> pkg/utils/slices.go:23:14: syntax error: unexpected [, expecting (
> note: module requires Go 1.19
> HASH[build k8s.io/client-go/applyconfigurations/certificates/v1beta1]
> HASH[build k8s.io/client-go/applyconfigurations/certificates/v1beta1]:
> "go1.17.13"
>
> which could be worked around by moving to landsdale release. Which
> bothers me, because I too want to keep my build reliable. And I do not
> want to mess around outside our meta layer in the distribution!
> How do I do this properly?
> I see people pulling in each dependency by individual golang.org-x.bb
> recipes, how could such a recipe look like?
>

There are many different discussions about how to generate go recipes, as
well
as similar discussions for ruby/rust, etc, you can find them on the
openembedded-core
and openembedded-architectures lists.

I also did a presentation at the yocto summit about "modern languages".

So I won't try and summarize all those discussions here, since they are
archived
and do a much better job than I could here.

But to answer the specific question .. you can't really handle the
individual
go dependencies as recipes. They are far too sensitive to versions and
individual git hashes.  Plus you'll end up with thousands of recipes of
varying
versions.

There have been several proposals about how to generate go recipes to deal
with
the dependencies. Some prototypes have been posted, but there hasn't
been a lot of traffic on that topic for several months now.

You can see the approach that I take for this in the k3s and nerdctl recipes
in meta-virtualization. My new docker-compose recipe is of similar format.


>
> I read
>
> https://lore.kernel.org/all/8132db85-5881-636e-c091-d84c47efe...@gmail.com/T/
> where Mike is not happy with this appraoch either and comes up with a
> working recipe I don't get why this could work at all.
>
> What am I missing here where is the missing link I did not get yet?
>
> Also, I am jealous about the buildroot guys sometimes, how do they do
> this in a 22 lines makefile including comments:
>
>
> https://git.busybox.net/buildroot/tree/package/docker-compose/docker-compose.mk
>
>
If we just bypass the fetcher, offline builds, some of licensing and SBOM
and reproducible builds .. you can have a simple recipe like that as well :)

Bruce



>
> Regards
> Konstantin
>
> --
> INSIDE M2M GmbH
> Konstantin Kletschke
> Berenbosteler Straße 76 B
> 30823 Garbsen
>
> Telefon: +49 (0) 5137 90950136
> Mobil: +49 (0) 151 15256238
> Fax: +49 (0) 5137 9095010
>
> konstantin.kletsc...@inside-m2m.de
> http://www.inside-m2m.de
>
> Geschäftsführung: Michael Emmert, Ingo

[yocto] # honister #systemd attempting to run script on boot...

2022-10-11 Thread Monsees, Steven C (US) via lists.yoctoproject.org 

I am trying to make use of system to run a test script at boot...
I can exercise my test_script/test_script.service manually using systemctl 
commands and it appears to work as expects.

I created a recipe based on this, it builds clean (no errors/warnings), but it 
doesn't appear to set things up correctly.
I have only recently begun working with honister, and new to systemd...

Could someone have look at my recipe & service file and see if they can spot 
anything ?

My recipe:

#
# This file is the my_test_script recipe.
#

SUMMARY = "Simple my_test_script application"
SECTION = "apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

inherit systemd

SRC_URI = "file://test_script.sh \
   file://test_script.service"

S = "${WORKDIR}"

SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE_${PN} = "test_script.service"
SYSTEMD_AUTO_ENABLE:${PN} = "enable"

do_install() {
 install -d ${D}${bindir}
 install -m 0755 ${S}/test_script.sh ${D}${bindir}

 install -d ${D}${systemd_system_unitdir}
 install -m 0644 ${S}/test_script.service 
${D}${systemd_system_unitdir}
}

FILES_${PN} = "${bindir}"
FILES_${PN} += "${systemd_system_unitdir}"

REQUIRED_DISTRO_FEATURES="systemd"
---
My test script service file:

[Unit]
Description=Configure test

[Service]
Type=oneshot
ExecStart=/usr/bin/test_script.sh start
StandardOutput=journal+console

[Install]
WantedBy=multi-user.target
---
My test script:

#!/bin/bash
# description: Description comes here

echo "***"
echo "START: Hello PetaLinux World :)"
date +"%m/%d/%Y %H:%M:%S $HOSTNAME"
echo "***"

Thanks,
Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58324): https://lists.yoctoproject.org/g/yocto/message/58324
Mute This Topic: https://lists.yoctoproject.org/mt/94267158/21656
Mute #systemd:https://lists.yoctoproject.org/g/yocto/mutehashtag/systemd
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Dealing with go dependencies in recipes - native docker-compose

2022-10-11 Thread Konstantin Kletschke 
Today I realized, that the docker-compose in the meta-virtualization
layer is the old python3 based one and a native solution is available. I
tried to make a recipe for it to get rid of python3 (no other packages
uses it in our setup) and the current python3-docker-compose is broken:

https://lore.kernel.org/yocto-meta-virtualization/49660ea1-cd22-40db-98c7-c43f38a72...@ieee.org/

I tried to build the native solution proposed in
https://github.com/docker/compose/tree/v2.11.2.

So my current recipe docker-compose_2.11.2.bb looks like this:

LICENSE = "Apache-2.0"

inherit go
inherit go-mod

GO_IMPORT = "github.com/docker/compose"

SRC_URI = "git://${GO_IMPORT};protocol=https;branch=v2"
# v2.11.2
SRCREV = "616777eb4ad4d1101622d6727d9b7adaeb7943bb"

# S = "${WORKDIR}/git"

DEPENDS = "docker-ce"
RDEPENDS:${PN} = "docker-ce-cli"

With this I run into the issue, that go want's to download stuff while
compiling. Which is forbidden and breaks the reliable build proposal.
Totally understandable. Looks similair to this:

dial tcp: lookup proxy.golang.org: Temporary failure in name resolution

I read about a proposal allowing this by adding do_compile[network] =
"1" to meta/classes/go.bb:

https://lore.kernel.org/all/20220228235433.3948994-1-and...@gherzan.com/

Of course, if this works, the reliable build thingy is gone, but while
trying I discovered go loads external stuff, compiles it too.
In my case (I have kirkstone with go-1.17) I run into modules demanding
a go more recent:

ASH[build k8s.io/client-go/applyconfigurations/autoscaling/v2beta2]: "file 
containerresourcemetricsource.go Mas4-HIX5lGBEQNTIo58\n"
# github.com/docker/compose/v2/pkg/utils
pkg/utils/slices.go:23:6: missing function body
pkg/utils/slices.go:23:14: syntax error: unexpected [, expecting (
note: module requires Go 1.19
HASH[build k8s.io/client-go/applyconfigurations/certificates/v1beta1]
HASH[build k8s.io/client-go/applyconfigurations/certificates/v1beta1]: 
"go1.17.13"

which could be worked around by moving to landsdale release. Which
bothers me, because I too want to keep my build reliable. And I do not
want to mess around outside our meta layer in the distribution!
How do I do this properly?
I see people pulling in each dependency by individual golang.org-x.bb
recipes, how could such a recipe look like?

I read
https://lore.kernel.org/all/8132db85-5881-636e-c091-d84c47efe...@gmail.com/T/
where Mike is not happy with this appraoch either and comes up with a
working recipe I don't get why this could work at all.

What am I missing here where is the missing link I did not get yet?

Also, I am jealous about the buildroot guys sometimes, how do they do
this in a 22 lines makefile including comments:

https://git.busybox.net/buildroot/tree/package/docker-compose/docker-compose.mk


Regards
Konstantin

-- 
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen

Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010

konstantin.kletsc...@inside-m2m.de
http://www.inside-m2m.de 

Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58323): https://lists.yoctoproject.org/g/yocto/message/58323
Mute This Topic: https://lists.yoctoproject.org/mt/94264665/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How to create symlink while installing binary in recipe?

2022-10-11 Thread Khem Raj 
On Tue, Oct 11, 2022 at 9:36 AM Sourabh Hegde  wrote:
>
> Hello All,
>
> I have a simple recipe in which a binary is installed to /usr/bin/. Now, I 
> want to establish a symlink to same binary also. I am using hardknott release
>
> do_install () {
> install -d ${D}${bindir}/
> install -m 0755 ${WORKDIR}/test.sh ${D}${bindir}/test
> lnr ${D}/usr/bin/test ${D}/usr/bin/test-x
> }
>
> Is this the correct approach? Or is there any better method?
>

Looks ok perhaps you want to double check using lnr we have dropped
its usage in master but I am not sure if hardknott needs it or not. I
would simily use

ln -sf test ${D}/usr/bin/test-x

and avoid using the lnr wrapper.

> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58322): https://lists.yoctoproject.org/g/yocto/message/58322
Mute This Topic: https://lists.yoctoproject.org/mt/94263004/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] How to create symlink while installing binary in recipe?

2022-10-11 Thread Sourabh Hegde 
Hello All,

I have a simple recipe in which a binary is installed to /usr/bin/. Now, I want 
to establish a symlink to same binary also. I am using hardknott release

do_install () {
install -d ${D}${bindir}/
install -m 0755 ${WORKDIR}/test.sh ${D}${bindir}/test
lnr ${D}/usr/bin/test ${D} /usr/bin/test-x
}

Is this the correct approach? Or is there any better method?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58321): https://lists.yoctoproject.org/g/yocto/message/58321
Mute This Topic: https://lists.yoctoproject.org/mt/94263004/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Status 11 October 2022 (WW41)

2022-10-11 Thread Stephen Jolley 
Current Dev Position: YP 4.1 M4 (In TSC Review)

Next Deadline: 28th October 2022 YP 4.1 Release 

 

Next Team Meetings:

*   Bug Triage meeting Thursday October 13th 7:30 am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Weekly Project Engineering Sync Tuesday October 11th at 8 am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See  
https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

* Richard Purdie is
actually on holiday and expects to return on the 24th October.
*   Patches for master are welcome on the mailing list and will be
reviewed/tested, but will not be merged until RP has returned.
*   YP 4.1 rc2 is now out of QA and will be reviewed by the TSC later
today. Release is scheduled for the 28th but may happen earlier if the
documentation is finalized.
*   A bug related to the Extensible SDK has been found in YP 4.1 but
this is potentially not a release blocker, and can be fixed in the first
point release.
*   Steve Sakoman to maintain Langdale (YP 4.1 - not an LTS)
*   At release we released the core layer was still advertising
kirkstone so this was removed. This did mean some simple changes were needed
to layers to mark compatibility with the new release, we'll aim to do this
earlier in the next release.
*   YP 3.1.20 rc2 has been built and is in QA now.
*   YP 4.2 Proposed Timeline document is at:

https://docs.google.com/document/d/1X5KM_3BiEsIrHBO93ULvYHQJ72NqS5U5jjwWo5bx
TiY/edit?usp=sharing
*   Help is very much welcome in trying to resolve our autobuilder
intermittent issues. You can see the list of failures we're continuing to
see by searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT. In
particular there is a long-standing qemuppc failure which needs
investigating ( 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14824)

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 4.1. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.1_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.
*   Help us resolve CVE issues:
 CVE metrics 

 

YP 4.1 Milestone Dates:

*   YP 4.1 M4 is back from QA and in TSC Review
*   YP 4.1 M4 Release date 2022/10/28

 

Upcoming dot releases:

*   YP 3.1.20 built and in QA
*   YP 3.1.20 Release date 2022/10/21
*   YP 4.0.5 build date 2022/10/31
*   YP 4.0.5 Release date 2022/11/11

 

Tracking Metrics:

*   WDD 2409 (last week 2404) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1217 (last week 1217)
*   Patches in the Pending State: 311 (26%) [last week 311 (26%)]

*
https://autobuilder.yocto.io/pub/non-release/patchmetrics/

 

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...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messag

Re: [yocto] [meta-zephyr][kirkstone][PATCH] nrf52840-mdk-usb-dongle.conf: Add new machine from makerdiary

2022-10-11 Thread Naveen Saini 
Hi Philippe,

nrf52840-mdk-usb-dongle board is not supported in Zephyr 3.0 [in Kirkstone]. 
It's available in Zephyr 3.1 onwards.
https://github.com/zephyrproject-rtos/zephyr/commit/b94fe6315870f938d759076a57cd3311ab0a0c06

Error log:
| -- Board: nrf52840_mdk_usb_dongle
| No board named 'nrf52840_mdk_usb_dongle' found.

Regards,
Naveen

> -Original Message-
> From: yocto@lists.yoctoproject.org  On
> Behalf Of philippe.co...@astrolabe.coop
> Sent: Friday, October 7, 2022 4:57 PM
> To: yocto@lists.yoctoproject.org
> Cc: philippe.coval.pro+meta-zephyr-lists.yoctoproject@gmail.com;
> Philippe Coval ; Philippe Coval
> ; Jon Mason ;
> Saini, Naveen Kumar 
> Subject: [yocto] [meta-zephyr][kirkstone][PATCH] nrf52840-mdk-usb-
> dongle.conf: Add new machine from makerdiary
> 
> From: Philippe Coval 
> 
> It was tested with zephyr-openthread-rcp along Oniro's IoT gateway
> blueprint
> 
> For the record deployment was done manually:
> 
> - Click on device button
> - uf2conv.py "zephyr.hex" -c -f 0xADA52840
> - and then copy to mounted "/dev/disk/by-label/MDK-DONGLE"
> 
> Support of unfree flashing tools might be added later (once double verified)
> 
> Forwarded: https://lists.yoctoproject.org/g/yocto/message/58142
> Relate-to: https://gitlab.eclipse.org/eclipse/oniro-blueprints/transparent-
> gateway/meta-oniro-blueprints-gateway/-/issues/6
> Relate-to: https://wiki.makerdiary.com/nrf52840-mdk/zephyr/
> Relate-to: https://gitlab.eclipse.org/pcoval/oniro-presentations/-
> /wikis/openthread
> Signed-off-by: Philippe Coval 
> Tested-by: Jon Mason 
> Signed-off-by: Naveen Saini 
> Signed-off-by: Philippe Coval 
> ---
>  meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf | 7
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-
> dongle.conf
> 
> diff --git a/meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf
> b/meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf
> new file mode 100644
> index 000..67e407a
> --- /dev/null
> +++ b/meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf
> @@ -0,0 +1,7 @@
> +#@TYPE: Machine
> +#@NAME: nrf52840-mdk-usb-dongle
> +
> +#@DESCRIPTION: Machine configuration for makerdiary's
> +nrf52840-mdk-usb-dongle
> +
> +require conf/machine/include/nrf52.inc
> +ARCH:nrf52840-mdk-usb-dongle = "arm"
> --
> 2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58319): https://lists.yoctoproject.org/g/yocto/message/58319
Mute This Topic: https://lists.yoctoproject.org/mt/94175586/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.1.rc2)

2022-10-11 Thread Jing Hui Tham 
Hi All,

QA for yocto-4.1.rc2 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-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Saturday, 1 October, 2022 6:50 AM
> To: yocto@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder
> build (yocto-4.1.rc2)
> 
> 
> A build flagged for QA (yocto-4.1.rc2) was completed on the autobuilder and
> is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.1.rc2
> 
> 
> Build hash information:
> 
> bitbake: 074da4c469d1f4177a1c5be72b9f3ccdfd379d67
> meta-agl: e7e9216ccead73fdf6054301e68396ab04710c6f
> meta-arm: aa89fe3f08cb8406f9f1082c683bd71cd04628fb
> meta-aws: 729928fb7ce4a74546b68dd31390a3f6057ab92c
> meta-intel: 940218bd438776026398617033e09f288dae0137
> meta-mingw: b0067202db8573df3d23d199f82987cebe1bee2c
> meta-openembedded: 0782ea454af5b88cd686ac572c397d92e5912de4
> meta-virtualization: 3fe3e0971d7d14cbd06f54cad942fa2ed86c5048
> oecore: 744a2277844ec9a384a9ca7dae2a634d5a0d3590
> poky: 5200799866b92259e855051112520006e1c0
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58318): https://lists.yoctoproject.org/g/yocto/message/58318
Mute This Topic: https://lists.yoctoproject.org/mt/94254308/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-