[yocto] [yocto-autobuilder2][yocto-autobuilder-helper]Updated the Stand-alone Installation details
Modified the README-Guide.md.
See thread "[yocto-autobuilder-helper] Replaced hardcoded BASE_HOMEDIR
directory"
--
Marco
From 30ed13445a01a2af759791cb39526437b43906c0 Mon Sep 17 00:00:00 2001
From: Marco Cavallini
Date: Mon, 21 Oct 2019 18:38:22 +0200
Subject: [PATCH] README-Guide.md: Updated the Stand-alone Installation details
according to the yocto-autobuilder-helper patch
5ba152e55688b27c745a787a5ca968bb058ebf25
Now is no longer needed to manually modify config.json.
Signed-off-by: Marco Cavallini
---
README-Guide.md | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/README-Guide.md b/README-Guide.md
index 70f1433..e8f74a1 100644
--- a/README-Guide.md
+++ b/README-Guide.md
@@ -53,8 +53,7 @@ Next, if you do not want to edit the original `yocto-autobuilder-helper/config.j
Here are some suggestions for the sake of :
- 1. In the original `config.json`, find all instances of whatever `BASE_HOMEDIR` was set to, for example `/home/pokybuild3`. Copy those variables to your `config-local.json` replace `/home/pokybuild3` with `${BASE_HOMEDIR}`. These will be variables like `BUILDPERF_STATEDIR` and `EXTRAPLAINCMDS`.
-Set `BASE_HOMEDIR` should be your build user's home directory. (There are shell scripts where this is assumed.)
+ 1. Customization can be done by copying the variable to be overriden from the original `config.json` to your `config-local.json`, for example like `BUILDPERF_STATEDIR` and `EXTRAPLAINCMDS`. _NOTE:_ In this document and by default `BASE_HOMEDIR` is set as pokybuild3 and should be the Autobuilder2 user's home directory.
2. Add `BASE_SHAREDDIR` and `BASE_PUBLISHDIR` such that they are subtrees of your `BASE_HOMEDIR`, e.g., `${BASE_HOMEDIR}/srv/autobuilder.yoursite.com`.
3. Change your `WEBPUBLISH_URL` to match your `config.py` definition for `buildbotURL`.
4. In order for this to work, you must export `ABHELPER_JSON="config.json config-local.json"` into the environment of the controller and janitor services (the example service scripts included below already have this).
@@ -281,4 +280,4 @@ Group=nogroup
[Install]
WantedBy=multi-user.target
-```
\ No newline at end of file
+```
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-autobuilder-helper] Replaced hardcoded BASE_HOMEDIR directory
Replaced hardcoded BASE_HOMEDIR directory.
Please apologize the missing send-email on my machine.
--
Marco
From 90f9ec8460e7054e67e74f7d0d54179e15c1c9bd Mon Sep 17 00:00:00 2001
From: Marco Cavallini
Date: Fri, 18 Oct 2019 18:40:43 +0200
Subject: [PATCH] config.json: Replaced occurrencies of /home/pokybuild with
${BASE_HOMEDIR}
Signed-off-by: Marco Cavallini
---
config.json | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/config.json b/config.json
index 88795b7..1493ab5 100644
--- a/config.json
+++ b/config.json
@@ -16,8 +16,8 @@
"WEBPUBLISH_DIR" : "${BASE_SHAREDDIR}/",
"WEBPUBLISH_URL" : "https://autobuilder.yocto.io/;,
-"BUILDPERF_STATEDIR" : "/home/pokybuild/buildperf",
-"BUILDPERF_RESULTSDIR" : "/home/pokybuild/buildperf-results",
+"BUILDPERF_STATEDIR" : "${BASE_HOMEDIR}/buildperf",
+"BUILDPERF_RESULTSDIR" : "${BASE_HOMEDIR}/buildperf-results",
"defaults" : {
"NEEDREPOS" : ["poky"],
@@ -141,7 +141,7 @@
"SSTATEDIR_RELEASE" : ["SSTATE_DIR ?= '${HELPERBUILDDIR}/sstate'"],
"PACKAGE_CLASSES" : "package_rpm",
"EXTRAPLAINCMDS" : [
-"${SCRIPTSDIR}/build-perf-test-wrapper -r ${BUILDPERF_RESULTSDIR} -E yocto-p...@yoctoproject.org -d ${BUILDPERF_STATEDIR}/downloads -w /home/pokybuild/build-perf-test -p ${HELPERRESULTSDIR}/${HELPERTARGET} -R ${HELPERREPONAME} -b ${HELPERBRANCHNAME} --push g...@push.yoctoproject.org:yocto-buildstats"
+"${SCRIPTSDIR}/build-perf-test-wrapper -r ${BUILDPERF_RESULTSDIR} -E yocto-p...@yoctoproject.org -d ${BUILDPERF_STATEDIR}/downloads -w ${BASE_HOMEDIR}/build-perf-test -p ${HELPERRESULTSDIR}/${HELPERTARGET} -R ${HELPERREPONAME} -b ${HELPERBRANCHNAME} --push g...@push.yoctoproject.org:yocto-buildstats"
],
"extravars" : [
"BB_NUMBER_THREADS = '24'",
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project new features survey
Hello, Yocto Project/Openembedded can nowadays be considered the 'de facto' standard among the automated generation systems of embedded linux distributions. Experienced users appreciate the features offered by Yocto Project and its complete customization that allows to adapt it to any specific requirement. However, from the beginner's point of view, the situation is a bit more complicated due to the Yocto Project's particularly steep learning curve. The tools that can support the development with Yocto Project are Toaster, that allow the configuration of the builds through a web interface, and the 'extended SDK' (eSDK), based on Devtool which allows the system to be tuned or extended without editing configuration files. Probably anyone who has tried to use Yocto Project will certainly have had the desire at least once to have a feature not available. For this reason it might be interesting to discuss it together. - What aspects of Yocto Project you consider not useful or misleading? - What functionality would you like to have in Yocto Project? - What do you think is missing? Take part to the survey at this link: http://bit.ly/2kXvdsd and let's continue this discussion at OEDAM and Yocto Project Summit 2019 P.S. if you think that can make sense to cross post this to OE mailing lists, feel free to share. If you think this is off-topic or doesn0t comply to any YP(OE ML polici, please ignore it and apologize me. -- Marco -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] PREFERRED_VERSION ignored
Hello, using Yocto version 'rocko' I have a custom layer defining a new recipe and a distro. I have a recipe openssl_1.0.1u.bb in my meta-custom layer. My meta-custom layer.conf has BBFILE_PRIORITY_meta-custom = "9" In my meta-custom layer I have a distro configuration saying PREFERRED_VERSION_openssl = "1.0.2o" so I expected to build 1.0.2o but when I build bitbake openssl is always selected the 1.0.1u Same problem if I set PREFERRED_VERSION_openssl = "1.0.2o" in the local.conf Is there an issue or am I doing something wrong? -- Marco -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Wanted: Volunteers and demos for OpenEmbedded FOSDEM stand
Il 04/12/18 18:19, Paul Barker ha scritto: Hi all, We've got an OpenEmbedded stand again at FOSDEM this year! The event will be held on 2nd & 3rd Feb 2019 at the usual location of ULB Campus du Solbosch in Brussels. I'll be present most of each day to run the stand but we need some additional volunteers to help out. Ideally we need 3-4 volunteers for each day so that we can load balance a bit and have chance for breaks and coffee runs. If you're interested in volunteering could you reply to this email for now, we'll probably get a list up on the OE wiki nearer the event. We also need some demos to show off. I don't really have much myself this year sadly. Demos should show off the benefits of OpenEmbedded (such as building the same image for multiple machines). Ideally we would have a couple of hardware devices to show off along with a demo of Toaster, the layer index and other visual parts of the tooling on a laptop. Demos may include commercial hardware but please remember that we have limited stand space and want to show off the OpenEmbedded project and related open source technologies - a sales demo of a proprietary product isn't appropriate. If you've got some form of demo to bring along then please let me know by email reply. Cheers, Hello, I just added the dedicated page in the website, please update it with your name. https://www.openembedded.org/wiki/FOSDEM_2019 Cheers, -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded software engineering Phone:+39 035-255.235 http://KoanSoftware.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OEDEM in Edinburgh in 2 weeks
Il 04/10/2018 14:20, Philip Balister ha scritto: OEDEM is basically full at this time. https://www.openembedded.org/wiki/OEDEM_2018 We have had the room rearranged to seat 45 people and I am not sure how we would handle anyone over this. If you know you can't make it, could you please remove your name from the attendee list. We'd like to get a better idea of how many people on the waiting list we can accommodate. There are some long time contributors on the wait list we'd like to get in. Philip Hi Philip, if I can participate remaining standing, will be a pleasure to leave my seat to one of the long time contributors on the wait list ;-) Let me know. Cheers, -- Marco Cavallini -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] SSTATE_DIR not working with multi user environment
Hi this is a follow up to another thread called "Unclear sstate-cache dir permissions" I am trying to share a sstate-cache between two (or more) users in a shared directory. Although I set the directory owner, group and permissions I face to a weird condition that I don't understand and seems to point out a bitbake/class problem. Problem description I have a shared area with the following permissions (g+ws) set up at before the builds ls -al /opt/yocto drwxrwsrwx 4 tux yocto 20480 set 28 14:47 downloads drwxrwsrwx 259 tux yocto 4096 set 28 15:33 sstate-cache This is the common local.conf DL_DIR ?= "/opt/yocto/downloads" SSTATE_DIR ?= "/opt/yocto/sstate-cache" 1. workspace1 with user1 (tux) generates the first build using bitbake core-image-minimal /opt/yocto/sstate-cache (content excerpt) drwxr-xr-x 2 tux yocto 4096 set 28 14:44 94 drwxr-sr-x 2 tux yocto 4096 set 28 14:45 95 drwxr-xr-x 2 tux yocto 4096 set 28 14:46 96 2. build on workspace2 using user2 (devel) faces to the following problem Permission denied: '/opt/yocto/sstate-cache/95/sigtask' because the permissions of directory '95' is 'drwxr-sr-x' $ bitbake core-image-minimal Build Configuration: BB_VERSION= "1.34.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal-4.8" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "qemuarm" DISTRO= "poky" DISTRO_VERSION= "2.3.2" TUNE_FEATURES = "arm armv5 thumb dsp" TARGET_FPU= "soft" meta meta-poky meta-yocto-bsp= "pyro:30613467d864130202d90e8460f7bbfa4db98397" Initialising tasks: 100% || Time: 0:00:04 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: core-image-minimal-1.0-r0 do_image_ext4: Execution of event handler 'sstate_eventhandler' failed Traceback (most recent call last): File "/home/devel/yocto-pyro-qemuarm2/poky/bitbake/lib/bb/siggen.py", line 356, in dump_this_task(outfile='/opt/yocto/sstate-cache/95/sstate:core-image-minimal:qemuarm-poky-linux-gnueabi:1.0:r0:qemuarm:3:95da4ea64e782dcc0c8dfb4b9b7c0099_image_ext4.tgz.siginfo', d=): referencestamp = bb.build.stamp_internal(task, d, None, True) >bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile:" + referencestamp) File "/home/devel/yocto-pyro-qemuarm2/poky/meta/lib/oe/sstatesig.py", line 184, in SignatureGeneratorOEBasicHash.dump_sigtask(fn='/home/devel/yocto-pyro-qemuarm2/poky/meta/recipes-core/images/core-image-minimal.bb', task='do_image_ext4', stampbase='/opt/yocto/sstate-cache/95/sstate:core-image-minimal:qemuarm-poky-linux-gnueabi:1.0:r0:qemuarm:3:95da4ea64e782dcc0c8dfb4b9b7c0099_image_ext4.tgz.siginfo', runtime='customfile:/home/devel/yocto-pyro-qemuarm2/poky/build/tmp/stamps/qemuarm-poky-linux-gnueabi/core-image-minimal/1.0-r0'): return >super(bb.siggen.SignatureGeneratorBasicHash, self).dump_sigtask(fn, task, stampbase, runtime) File "/home/devel/yocto-pyro-qemuarm2/poky/bitbake/lib/bb/siggen.py", line 300, in SignatureGeneratorOEBasicHash.dump_sigtask(fn='/home/devel/yocto-pyro-qemuarm2/poky/meta/recipes-core/images/core-image-minimal.bb', task='do_image_ext4', stampbase='/opt/yocto/sstate-cache/95/sstate:core-image-minimal:qemuarm-poky-linux-gnueabi:1.0:r0:qemuarm:3:95da4ea64e782dcc0c8dfb4b9b7c0099_image_ext4.tgz.siginfo', runtime='customfile:/home/devel/yocto-pyro-qemuarm2/poky/build/tmp/stamps/qemuarm-poky-linux-gnueabi/core-image-minimal/1.0-r0'): >fd, tmpfile = tempfile.mkstemp(dir=os.path.dirname(sigfile), prefix="sigtask.") try: File "/usr/lib/python3.4/tempfile.py", line 409, in mkstemp(suffix='', prefix='sigtask.', dir='/opt/yocto/sstate-cache/95', text=False): >return _mkstemp_inner(dir, prefix, suffix, flags) File "/usr/lib/python3.4/tempfile.py", line 339, in _mkstemp_inner(dir='/opt/yocto/sstate-cache/95', pre='sigtask.', suf='', flags=131266): try: >fd = _os.open(file, flags, 0o600) return (fd, _os.path.abspath(file)) PermissionError: [Errno 13] Permission denied: '/opt/yocto/sstate-cache/95/sigtask._nk80whe' ERROR: core-image-minimal-1.0-r0 do_image_ext4: Build of do_image_ext4 failed ERROR: core-image-minimal-1.0-r0 do_image_ext4: Traceback (most recent call last): File "/home/devel/yocto-pyro-qemuarm2/poky/bitbake/lib/bb/build.py", line 644, in exec_task return _exec_task(fn, task, d, quieterr) File "/home/devel/yocto-pyro-qemuarm2/poky/bitbake/lib/bb/build.py", line 618, in _exec_task event.fire(TaskSucceeded(task, logfn, localdata), localdata) File "/home/devel/yocto-pyro-qemuarm2/poky/bitbake/lib/bb/event.py", line 211, in fire fire_class_handlers(event, d) File "/home/devel/yocto-pyro-qemuarm2/poky/bitbake/lib/bb/event.py", line 134, in fire_class_handlers execute_handler(name, handler, event, d)
[yocto] Unclear sstate-cache dir permissions
Hello, I am trying to share a sstate-cache between two (or more) users in a shared directory. Although I set the directory owner, group and permissions I face to a weird condition that I don't understand. Particularly why some directories don't have the group write permisisons that drive me to a buld failure for mambers of the group. I wonder if I am doing something wrong or I have an unexpected issue. koan@kmobile:sstate-cache$ ll totale 1028 drwxrwxr-x 2 koan devgroup 4096 set 14 15:32 00 drwxrwxr-x 2 koan devgroup 4096 set 14 14:37 01 ... drwxr-xr-x 2 koan devgroup 4096 set 14 15:31 1d drwxrwxr-x 2 koan devgroup 4096 set 14 15:31 1e ... drwxr-xr-x 2 koan devgroup 4096 set 14 15:32 27 drwxrwxr-x 2 koan devgroup 4096 set 14 15:32 28 ... etc... Any help would be greatly appreciated. Thank you -- Marco 'mckoan' -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SELinux with Busybox on morty
Hi Joe & Shrikant,
Many thanks for your response. It was good to know that busybox can
function with SELinux enforcing enabled.
Sorry not to mention the policy we're currently using. It's:
refpolicy-targeted
||/ NameVersion Architecture
Description
+++-===---
ii refpolicy-targeted git-r0 amd64
SELinux targeted policy
We'll build policy based on 2.20151208 and give it a try to see how it
behaves.
It appears to me that policy itself is responsible for semanage not
functioning. When I try:
semanage -v port -l
I see errors like this:
1088. 07/24/17 07:29:46 semanage
unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 2 dir write
system_u:object_r:lib_t:s0 denied 1095
1089. 07/24/17 07:29:46 semanage
unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 2 dir write
system_u:object_r:lib_t:s0 denied 1096
or
time->Mon Jul 24 07:29:46 2017
type=PROCTITLE msg=audit(1500881386.907:1101):
proctitle=2F7573722F62696E2F707974686F6E002D4573002F7573722F7362696E2F73656D616E616765002D7600706F7274002D6C
type=SYSCALL msg=audit(1500881386.907:1101): arch=c03e syscall=2
success=no exit=-13 a0=7ddf20 a1=2c1 a2=81a4 a3=5640003640100 items=0
ppid=496 pid=1201 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts0 ses=1 comm="semanage" exe="/usr/bin/python2.7"
subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1500881386.907:1101): avc: denied { write } for
pid=1201 comm="semanage" name="sepolgen" dev="vda" ino=6091
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023
tcontext=system_u:object_r:lib_t:s0 tclass=dir permissive=0
The majority of the errors however are related to start_getty:
142. 07/24/17 06:14:04 start_getty system_u:system_r:getty_t:s0 4 dir
search system_u:object_r:default_t:s0 denied 149
time->Mon Jul 24 07:34:21 2017
type=PROCTITLE msg=audit(1500881661.906:1160):
proctitle=2F62696E2F7368002F62696E2F73746172745F676574747900313135323030007474795330
type=SYSCALL msg=audit(1500881661.906:1160): arch=c03e syscall=59
success=no exit=-13 a0=6fca60 a1=6fcc40 a2=6faf90 a3=59a items=0 ppid=1244
pid=1246 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="start_getty" exe="/bin/bash"
subj=system_u:system_r:getty_t:s0 key=(null)
type=AVC msg=audit(1500881661.906:1160): avc: denied { search } for
pid=1246 comm="start_getty" name="sbin" dev="vda" ino=7236
scontext=system_u:system_r:getty_t:s0
tcontext=system_u:object_r:default_t:s0 tclass=dir permissive=0
I've applied an appropriate context to start_getty, but that didn't prevent
the errors:
ls -alZ /bin/start_getty
-rwxr-xr-x. 1 root root system_u:object_r:getty_exec_t:s0 99 Jul 21 02:55
/bin/start_getty
start_getty is a shell script that points back to /sbin/getty which is a
symlink to /usr/lib/busybox/sbin/getty
So I applied a context to /usr/lib/busybox/sbin/getty without it
preventing the above mentioned errors:
ls -alZ /usr/lib/busybox/sbin/getty
-rwxr-xr-x. 1 root root system_u:object_r:getty_exec_t:s0 21 Jun 9 03:39
/usr/lib/busybox/sbin/getty
I'm keen to see how policy based on 2.20151208 will look.
Additional to trying 2.20151208 if you have any suggestions or advice I'd
be grateful to hear it.
Cheers,
Marco
On 22 July 2017 at 05:46, Joe MacDonald <joe_macdon...@mentor.com> wrote:
> Hi Justin / Marco,
>
> [Re: SELinux with Busybox on morty] On 17.07.19 (Wed 16:05) Justin
> Clacherty wrote:
>
> > Hi Joe,
> >
> > Is this something you or one of the other meta-selinux devs are able
> > to help out with or is it more of an upstream question?
>
> I'll see if I can give this a shot. :-)
>
> >
> > Cheers,
> > Justin.
> >
> >
> > > On 17 Jul 2017, at 4:57 pm, Marco Ostini <ma...@ostini.org> wrote:
> > >
> > >
> > > Hi All,
> > >
> > > At the moment I'm attempting to prepare a VM of morty with SELinux
> > > running well in enforcing mode. Once bedded down this will be
> > > running on an embedded system.
> > >
> > > We use Busybox to keep the environment slim.
> > >
> > > As you may be aware the file contexts of
> > > /etc/selinux/targeted/contexts/files/file_contexts don't include
> > > appropriate paths (/sbin + /usr/lib/busybox/sbin/) and relative file
> > > contexts for commands provided by Busybox. The /sbin files provided
> > > by Busybox are symlinks to their counterparts in
> > > /usr/lib/busybox/sbin/.
> > >
> > > I've attempted to
[yocto] SELinux with Busybox on morty
Hi All, At the moment I'm attempting to prepare a VM of morty with SELinux running well in enforcing mode. Once bedded down this will be running on an embedded system. We use Busybox to keep the environment slim. As you may be aware the file contexts of /etc/selinux/targeted/contexts/files/file_contexts don't include appropriate paths (/sbin + /usr/lib/busybox/sbin/) and relative file contexts for commands provided by Busybox. The /sbin files provided by Busybox are symlinks to their counterparts in /usr/lib/busybox/sbin/. I've attempted to use semanage to apply file contexts and look up login contexts. Any time I use semanage I receive this message: Error: Failed to read //etc/selinux/targeted/policy/policy.30 policy file In an attempt to mitigate this error I ran semodule --build and while it did rebuild the policy file, it didn't mitigate the error message generated by semanage. At the moment I'm applying temporary file contexts with chcon. My questions are: 1. Is it possible to run Busybox (providing init, getty, syslog ...) in SELinux enforcing. If so, where's the policy files? 2. Is there some documentation somewhere on reference builds of Morty with SELinux enforcing ? Kind regards, Marco -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dynamic PV version in recipe
Hello , sorry for previous mail.
I tried with
python do_package_prepend() {
d.setVar('PKGV', d.getVar("JENKINS_VERSION", True))
}
and in do_compile :
{
VERSION= get from bash parsing.
"${@d.setVar("JENKINS_VERSION","$VERSION"}"
}
but doesn't work... it only work if i put a static string in version.
any help?
thanks
____
Da: Marco Garzola
Inviato: venerdì 17 giugno 2016 12.59.32
A: Christopher Larson
Cc: yocto@yoctoproject.org
Oggetto: Re: [yocto] Dynamic PV version in recipe
hello again,
I tried adding :
python do_package_prepend() {
d.setVar('PKGV', d.getVar("JENKINS_VERSION", True)) print d.getVar('PKGV',True)
Da: yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> per conto
di Marco Garzola <marco.garz...@tecniplast.it>
Inviato: giovedì 16 giugno 2016 22.11.25
A: Christopher Larson
Cc: yocto@yoctoproject.org
Oggetto: Re: [yocto] Dynamic PV version in recipe
Hi Christopher,
PKGV seems very interesting to me. is there out there any example to follow ?
if I add something like that at the end of do_compile task should it work?
do_compile(){
#. do stuff and get in myVersion the revision
{@setVar("PKGV","${myVersion}")}
}
Thanks .
Marco
Da: kerg...@gmail.com <kerg...@gmail.com> per conto di Christopher Larson
<clar...@kergoth.com>
Inviato: giovedì 16 giugno 2016 21.51.26
A: Marco Garzola
Cc: yocto@yoctoproject.org
Oggetto: Re: [yocto] Dynamic PV version in recipe
On Thu, Jun 16, 2016 at 8:11 AM, Marco Garzola
<marco.garz...@tecniplast.it<mailto:marco.garz...@tecniplast.it>> wrote:
I got a problem, maybe someone could help me.I have a recipe that takes from a
jenkins server via json API a binary file with a version that i know only after
do_compile task. the question is : is there any way to tell bitbake that $PV
should change dynamically , maybe in do_install task ? My goal is to create
the package with the revision read from jenkins.
PV has to be set at parse time, up front, so bitbake can use it in stamps to
help determine when tasks need to be run, as well as including it in WORKDIR
and whatnot.
If all you want is to change the version in the emitted binary packages, you
can dynamically set PKGV, i.e. add a prefunc before do_package which reads the
PKGV. Of course, making sure it re-runs the appropriate tasks when that value
changes is rather less trivial, since bitbake generates signatures/checksums at
parse time.
Alternatively, would it be possible to contact the server via the json API at
parse time as long as BB_NO_NETWORK isn't set? Of course, unless there's a way
to support the BB_NO_NETWORK case, that would be problematic as well.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dynamic PV version in recipe
hello again,
I tried adding :
python do_package_prepend() {
d.setVar('PKGV', d.getVar("JENKINS_VERSION", True)) print d.getVar('PKGV',True)
Da: yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> per conto
di Marco Garzola <marco.garz...@tecniplast.it>
Inviato: giovedì 16 giugno 2016 22.11.25
A: Christopher Larson
Cc: yocto@yoctoproject.org
Oggetto: Re: [yocto] Dynamic PV version in recipe
Hi Christopher,
PKGV seems very interesting to me. is there out there any example to follow ?
if I add something like that at the end of do_compile task should it work?
do_compile(){
#. do stuff and get in myVersion the revision
{@setVar("PKGV","${myVersion}")}
}
Thanks .
Marco
Da: kerg...@gmail.com <kerg...@gmail.com> per conto di Christopher Larson
<clar...@kergoth.com>
Inviato: giovedì 16 giugno 2016 21.51.26
A: Marco Garzola
Cc: yocto@yoctoproject.org
Oggetto: Re: [yocto] Dynamic PV version in recipe
On Thu, Jun 16, 2016 at 8:11 AM, Marco Garzola
<marco.garz...@tecniplast.it<mailto:marco.garz...@tecniplast.it>> wrote:
I got a problem, maybe someone could help me.I have a recipe that takes from a
jenkins server via json API a binary file with a version that i know only after
do_compile task. the question is : is there any way to tell bitbake that $PV
should change dynamically , maybe in do_install task ? My goal is to create
the package with the revision read from jenkins.
PV has to be set at parse time, up front, so bitbake can use it in stamps to
help determine when tasks need to be run, as well as including it in WORKDIR
and whatnot.
If all you want is to change the version in the emitted binary packages, you
can dynamically set PKGV, i.e. add a prefunc before do_package which reads the
PKGV. Of course, making sure it re-runs the appropriate tasks when that value
changes is rather less trivial, since bitbake generates signatures/checksums at
parse time.
Alternatively, would it be possible to contact the server via the json API at
parse time as long as BB_NO_NETWORK isn't set? Of course, unless there's a way
to support the BB_NO_NETWORK case, that would be problematic as well.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dynamic PV version in recipe
Hi Christopher,
PKGV seems very interesting to me. is there out there any example to follow ?
if I add something like that at the end of do_compile task should it work?
do_compile(){
#. do stuff and get in myVersion the revision
{@setVar("PKGV","${myVersion}")}
}
Thanks .
Marco
Da: kerg...@gmail.com <kerg...@gmail.com> per conto di Christopher Larson
<clar...@kergoth.com>
Inviato: giovedì 16 giugno 2016 21.51.26
A: Marco Garzola
Cc: yocto@yoctoproject.org
Oggetto: Re: [yocto] Dynamic PV version in recipe
On Thu, Jun 16, 2016 at 8:11 AM, Marco Garzola
<marco.garz...@tecniplast.it<mailto:marco.garz...@tecniplast.it>> wrote:
I got a problem, maybe someone could help me.I have a recipe that takes from a
jenkins server via json API a binary file with a version that i know only after
do_compile task. the question is : is there any way to tell bitbake that $PV
should change dynamically , maybe in do_install task ? My goal is to create
the package with the revision read from jenkins.
PV has to be set at parse time, up front, so bitbake can use it in stamps to
help determine when tasks need to be run, as well as including it in WORKDIR
and whatnot.
If all you want is to change the version in the emitted binary packages, you
can dynamically set PKGV, i.e. add a prefunc before do_package which reads the
PKGV. Of course, making sure it re-runs the appropriate tasks when that value
changes is rather less trivial, since bitbake generates signatures/checksums at
parse time.
Alternatively, would it be possible to contact the server via the json API at
parse time as long as BB_NO_NETWORK isn't set? Of course, unless there's a way
to support the BB_NO_NETWORK case, that would be problematic as well.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Dynamic PV version in recipe
Hi all, I got a problem, maybe someone could help me.I have a recipe that takes from a jenkins server via json API a binary file with a version that i know only after do_compile task. the question is : is there any way to tell bitbake that $PV should change dynamically , maybe in do_install task ? My goal is to create the package with the revision read from jenkins. Thanks anyone for the help Marco -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Create uncompressed rootfs
You could mount the .ext3 image on a partition using -o loop or find/customize a different solution using IMAGE_TYPES (i.e. when IMAGE_FSTYPES contains "live") http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering http://www.KoanSoftware.com 2015-11-02 6:20 GMT+01:00 Roberto <ramat...@gmail.com>: > Hi, > > > > I apologise if this is not the right channel for asking the following > question. If so, please advise me on a more appropriate support channel. > > > > I am looking for the quickest workflow for debugging a recipe. I basically > need to modify a recipe, deploy the entire distribution to the target board > and test it. > > > > have come to the conclusion that the quickest way is to boot the target > board through TFTP for the kernel and then mount the rootfs via NFS. > > > > In my view, the only issue of this workflow is that when I bitbake the image > it creates a compressed rootfs that then I have to uncompress in order to > provide the rootfs to the target board via NFS. > > > > Is there any way to avoid bitbake compressing the rootfs but rather having > it uncompressed in some folders under tmp/deploy ? > > > > Regards, > > > > Roberto > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] No rule to make target `Makefile.in' SITE files ['endian-little', 'bit-32', 'arm-common', 'common-linux', ...]
Hello,
I'm trying to create a recipe rdesktop_1.8.3.bb but I get an error
hard to understand.
With Yocto 'daisy' the same recipe worked without complaining.
To avoid any temporary misconfiguraton I deleted the sstate and tmp
and rebuilt core-image-minimal from scratch and then rdesktop but the
error is always present.
I'd like to know what is wrong with inherit autotools now using
'dizzy' and what is this DEBUG: SITE files ['endian-little', 'bit-32',
'arm-common', 'common-linux', 'common-glibc', 'arm-linux',
'arm-linux-gnueabi', 'common']
Thank you
This is my recipe:
$ cat rdesktop_1.8.3.bb
-
DESCRIPTION = Rdesktop rdp client for X
HOMEPAGE = http://www.rdesktop.org;
SECTION = x11/network
LICENSE = GPL
LIC_FILES_CHKSUM = file://COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949
SRC_URI = ${SOURCEFORGE_MIRROR}/rdesktop/rdesktop-${PV}.tar.gz
inherit autotools
EXTRA_OECONF = --with-openssl=${STAGING_EXECPREFIXDIR}
--disable-credssp --disable-smartcard
SRC_URI[md5sum] = 86e8b368a7c715e74ded92e0d7912dc5
SRC_URI[sha256sum] =
88b20156b34eff5f1b453f7c724e0a3ff9370a599e69c01dc2bf0b5e650eece4
And I get this error:
$ bitbake rdesktop
Build Configuration:
BB_VERSION= 1.24.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = Ubuntu-12.04
TARGET_SYS= arm-poky-linux-gnueabi
MACHINE = imx6solosabresd
DISTRO= poky
DISTRO_VERSION= 1.7.2
TUNE_FEATURES = arm armv7a vfp neon callconvention-hard cortexa9
TARGET_FPU= vfp-neon
meta
meta-yocto
meta-yocto-bsp= dizzy:9c4ff467f66428488b1cd9798066a8cb5d6b4c3b
meta-oe = dizzy:5b6f39ce325d490fc382d5d59c5b8b9d5fa38b38
meta-fsl-arm = dizzy:db1571f40c375a398a8cdbb42de4c4f272ab0cd1
meta-fsl-arm-extra = dizzy:794e46e0b0a3e7e270a2f3c217d8fe5751a6b2c6
meta-mh = dizzy:9c4ff467f66428488b1cd9798066a8cb5d6b4c3b
...
ERROR: Function failed: do_compile (log file is located at
/home/mc/yocto-fsl-dizzy/poky/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/rdesktop/1.8.3-r0/temp/log.do_compile.3066)
ERROR: Logfile of failure stored in:
/home/mc/yocto-fsl-dizzy/poky/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/rdesktop/1.8.3-r0/temp/log.do_compile.3066
Log data follows:
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
'common']
| DEBUG: Executing shell function do_compile
| NOTE: make -j 8
| make: *** No rule to make target `Makefile.in', needed by `Makefile'. Stop.
| ERROR: oe_runmake failed
| WARNING:
/home/mc/yocto-fsl-dizzy/poky/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/rdesktop/1.8.3-r0/temp/run.do_compile.3066:1
exit 1 from
| exit 1
| ERROR: Function failed: do_compile (log file is located at
/home/mc/yocto-fsl-dizzy/poky/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/rdesktop/1.8.3-r0/temp/log.do_compile.3066)
ERROR: Task 6
(/home/mc/yocto-fsl-dizzy/poky/meta-mh/recipes-connectivity/rdesktop/rdesktop_1.8.3.bb,
do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 545 tasks of which 544 didn't need to
be rerun and 1 failed.
No currently running tasks (522 of 554)
Summary: 1 task failed:
/home/mc/yocto-fsl-dizzy/poky/meta-mh/recipes-connectivity/rdesktop/rdesktop_1.8.3.bb,
do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
--
Marco
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-toolchain not always relocatable
Hi, I am facing to a very odd behaviour installing the resulting meta-toolchain. I launch poky-glibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.7.1.sh If I install in the default directory or in /opt/poky/test it works as expected, but if I install in /opt/poky/1.7.1-cortexa9hf there is a problem. Using YP older that dizzy it worked with a charm. $ ./poky-glibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.7.1.sh Enter target directory for SDK (default: /opt/poky/1.7.1): /opt/poky/1.7.1-cortexa9hf You are about to install the SDK to /opt/poky/1.7.1-cortexa9hf. Proceed[Y/n]? Extracting SDK...done Setting it up...done SDK has been successfully set up and is ready to be used. Now I can't use it calling the env setup as usual $ . /opt/poky/1.7.1-cortexa9hf/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi the reason is that the resulting path is incorrect $ env | grep PATH PATH=/opt/poky/1.7.1-cortexa9hf-cortexa9hf/sysroots/i686-pokysdk-linux/usr/bin:/opt/poky/1.7.1-cortexa9hf-cortexa9hf/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi:. -- Marco -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-xilinx-community] How to build for MicroZed board?
Good Morning, I am new to Yocto, but I need to create an embedded system on board MicroZed, based on processor Zynq from Xilinx. From what I understand the support form my board is provided by layer xilinx-meta-community; from the README file associated with this layer I see that the mailing list of reference is this, with the constraint of using [meta-xilinx-community] as a subject prefix. In doubt if this is the correct mailing list, I am also writing to meta-xil...@yoctoproject.org. If I'm writing to the correct mailing list, I would write of a problem: I would like to generate the configuration core-image-minimal, with MACHINE ??= microzed-zynq7, with the sources aligned to version daisy. I cloned repositories related to poky, meta-xilinx and meta-xilinx-community with the following commands: - git clone -b daisy git://git.yoctoproject.org/poky.git - git clone -b daisy git://github.com/Xilinx/meta-xilinx - git clone -b daisy git://git.yoctoproject.org/meta-xilinx-community - git clone -b daisy git://github.com/openembedded/meta-oe I then modified my file local.conf specifying parallelism and the variable MACHINE ??= ZedBoard-zynq7 I also changed the file bblayers.conf changing layers included as follows: BBLAYERS ?= \ /data/axel/YoctoMicroZed/poky/meta \ /data/axel/YoctoMicroZed/poky/meta-yocto \ /data/axel/YoctoMicroZed/poky/meta-yocto-bsp \ /data/axel/YoctoMicroZed/poky/meta-xilinx-community \ /data/axel/YoctoMicroZed/poky/meta-xilinx \ /data/axel/YoctoMicroZed/poky/meta-oe/meta-oe \ The problem is that running the command bitbake core-image-minimal, after the download phase and the execution of some tasks, the process stops with the following error: Function failed: do_configure (log file is located at /data/axel/YoctoMicroZed/poky/build/tmp/work/microzed_zynq7-poky-linux-gnueabi/linux-xlnx/3.14-xilinx+git2b48a8aeea7367359f9eebe55c4a09a05227f32b-r0/temp/log.do_configure.11742) Before going to analyze the nature of the error I'd like to know if the version of the various sources is updated - in the sense: there are archives of sources, tested such that it is possible to successfully execute the build for this system? Or I have to refer to particular sources on git commit? Thank you in advance for any suggestion Kind regards Marco Tessore -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-atmel] automatic bootloaders generation
please find attached patches for
- automatic bootloaders generation
https://github.com/linux4sam/meta-atmel/pull/16
Ciao
--
Marco Cavallini | KOAN sas | Bergamo - Italia
embedded and real-time software engineering
Phone:+39-035-255.235 - Fax:+39-178-22.39.748
http://www.KoanSoftware.com
From cc08f5529a08498b07482f80cd0d99a391af034d Mon Sep 17 00:00:00 2001
From: Marco Cavallini m.cavall...@koansoftware.com
Date: Mon, 12 May 2014 17:32:24 +0200
Subject: [meta-atmel 1/2] Added bootloaders to the recipe of every machine
* Include file with
* EXTRA_IMAGEDEPENDS += at91bootstrap u-boot
Signed-off-by: Marco Cavallini m.cavall...@koansoftware.com
---
conf/machine/at91sam9rlek.conf | 1 +
conf/machine/at91sam9x5ek.conf | 1 +
conf/machine/include/bootloaders.inc | 2 ++
conf/machine/sama5d3_xplained.conf | 8 +---
conf/machine/sama5d3xek.conf | 1 +
5 files changed, 6 insertions(+), 7 deletions(-)
create mode 100644 conf/machine/include/bootloaders.inc
diff --git a/conf/machine/at91sam9rlek.conf b/conf/machine/at91sam9rlek.conf
index 6ed6f81..4a41b19 100644
--- a/conf/machine/at91sam9rlek.conf
+++ b/conf/machine/at91sam9rlek.conf
@@ -3,6 +3,7 @@
#@DESCRIPTION: Machine configuration for Atmel's evaluation board
require conf/machine/include/tune-arm926ejs.inc
+require conf/machine/include/bootloaders.inc
MACHINE_FEATURES = kernel26 apm alsa ext2 ext3 usbgadget screen touchscreen ppp
diff --git a/conf/machine/at91sam9x5ek.conf b/conf/machine/at91sam9x5ek.conf
index 5308536..de5598a 100644
--- a/conf/machine/at91sam9x5ek.conf
+++ b/conf/machine/at91sam9x5ek.conf
@@ -3,6 +3,7 @@
#@DESCRIPTION: Machine configuration for Atmel's evaluation board
require conf/machine/include/tune-arm926ejs.inc
+require conf/machine/include/bootloaders.inc
MACHINE_FEATURES = kernel26 apm alsa ext2 ext3 usbhost usbgadget screen camera can touchscreen ppp
KERNEL_DEVICETREE = ${S}/arch/arm/boot/dts/at91sam9g25ek.dts \
diff --git a/conf/machine/include/bootloaders.inc b/conf/machine/include/bootloaders.inc
new file mode 100644
index 000..162b7a1
--- /dev/null
+++ b/conf/machine/include/bootloaders.inc
@@ -0,0 +1,2 @@
+# Add bootloaders to the images of every machine
+EXTRA_IMAGEDEPENDS += at91bootstrap u-boot
diff --git a/conf/machine/sama5d3_xplained.conf b/conf/machine/sama5d3_xplained.conf
index dcbcedb..24fe2a2 100644
--- a/conf/machine/sama5d3_xplained.conf
+++ b/conf/machine/sama5d3_xplained.conf
@@ -3,6 +3,7 @@
#@DESCRIPTION: Machine configuration for Atmel's evaluation board
require conf/machine/include/tune-cortexa5.inc
+require conf/machine/include/bootloaders.inc
MACHINE_FEATURES = kernel26 apm alsa ext2 ext3 usbhost usbgadget screen camera can touchscreen ppp wifi
KERNEL_DEVICETREE = \
@@ -34,10 +35,3 @@ UBI_VOLNAME = rootfs
UBOOT_MACHINE = sama5d3xek_nandflash_config
UBOOT_ENTRYPOINT = 0x20008000
UBOOT_LOADADDRESS = 0x20008000
-
-EXTRA_IMAGEDEPENDS += at91bootstrap u-boot-at91
-
-module_autoload_atmel_usba_udc = atmel_usba_udc
-module_autoload_g_serial = g_serial
-
-ROOTFS_POSTPROCESS_COMMAND += sama5d3_xplained_rootfs_postprocess;
diff --git a/conf/machine/sama5d3xek.conf b/conf/machine/sama5d3xek.conf
index 65487be..07d967d 100644
--- a/conf/machine/sama5d3xek.conf
+++ b/conf/machine/sama5d3xek.conf
@@ -3,6 +3,7 @@
#@DESCRIPTION: Machine configuration for Atmel's evaluation board
require conf/machine/include/tune-cortexa5.inc
+require conf/machine/include/bootloaders.inc
MACHINE_FEATURES = kernel26 apm alsa ext2 ext3 usbhost usbgadget screen camera can touchscreen ppp
KERNEL_DEVICETREE = \
--
1.8.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-atmel] Unified IMAGE_POSTPROCESS_COMMAND in image recipes
please find attached patches for
- Unified IMAGE_POSTPROCESS_COMMAND in your image recipes
https://github.com/linux4sam/meta-atmel/pull/11
Ciao
--
Marco Cavallini | KOAN sas | Bergamo - Italia
embedded and real-time software engineering
Phone:+39-035-255.235 - Fax:+39-178-22.39.748
http://www.KoanSoftware.com
From 0050a6a7fa34930f587c07b1c7ae9a73b4c3ba91 Mon Sep 17 00:00:00 2001
From: Marco Cavallini m.cavall...@koansoftware.com
Date: Mon, 12 May 2014 17:34:20 +0200
Subject: [meta-atmel 2/2] Unified usba_udc and g_serial setting for all
atmel-xplained-*-image.bb
* Moved common parts in atmel-demo-image.inc
Signed-off-by: Marco Cavallini m.cavall...@koansoftware.com
---
recipes-core/images/atmel-demo-image.inc | 18 ++
recipes-core/images/atmel-xplained-demo-image.bb | 12
recipes-core/images/atmel-xplained-lcd-demo-image.bb | 12
3 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/recipes-core/images/atmel-demo-image.inc b/recipes-core/images/atmel-demo-image.inc
index 3101e20..394bebe 100644
--- a/recipes-core/images/atmel-demo-image.inc
+++ b/recipes-core/images/atmel-demo-image.inc
@@ -35,3 +35,21 @@ inherit core-image
# we don't need the kernel in the image
ROOTFS_POSTPROCESS_COMMAND += rm -f ${IMAGE_ROOTFS}/boot/*Image*;
+
+# Unified usba_udc and g_serial
+module_autoload_atmel_usba_udc = atmel_usba_udc
+module_autoload_g_serial = g_serial
+
+sama5d3_xplained_rootfs_postprocess() {
+curdir=$PWD
+cd ${IMAGE_ROOTFS}
+
+# autoload needed modules
+cd etc
+echo atmel_usba_udc modules
+echo g_serial modules
+
+cd $curdir
+}
+
+ROOTFS_POSTPROCESS_COMMAND += sama5d3_xplained_rootfs_postprocess;
diff --git a/recipes-core/images/atmel-xplained-demo-image.bb b/recipes-core/images/atmel-xplained-demo-image.bb
index 5a88add..59b4572 100644
--- a/recipes-core/images/atmel-xplained-demo-image.bb
+++ b/recipes-core/images/atmel-xplained-demo-image.bb
@@ -8,15 +8,3 @@ IMAGE_INSTALL += \
packagegroup-base-3g \
packagegroup-base-usbhost \
-
-sama5d3_xplained_rootfs_postprocess() {
-curdir=$PWD
-cd ${IMAGE_ROOTFS}
-
-# autoload needed modules
-cd etc
-echo atmel_usba_udc modules
-echo g_serial modules
-
-cd $curdir
-}
diff --git a/recipes-core/images/atmel-xplained-lcd-demo-image.bb b/recipes-core/images/atmel-xplained-lcd-demo-image.bb
index cecd4c3..6cda1c3 100644
--- a/recipes-core/images/atmel-xplained-lcd-demo-image.bb
+++ b/recipes-core/images/atmel-xplained-lcd-demo-image.bb
@@ -15,15 +15,3 @@ IMAGE_INSTALL += \
tslib-tests \
tslib-calibrate \
-
-sama5d3_xplained_rootfs_postprocess() {
-curdir=$PWD
-cd ${IMAGE_ROOTFS}
-
-# autoload needed modules
-cd etc
-echo atmel_usba_udc modules
-echo g_serial modules
-
-cd $curdir
-}
--
1.8.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [RFC] Upgrade to a package with all its dependency without network
Hello, I need to be able to upgrade to a package with all its dependency chain on a target system that does not have access to the network. I'm trying to understand what may be the best and also the simplest solution. Perhaps there is already this functionality in OE/Yocto? I thought to implement a new opkg feture so that I can to generate the list of dependencies of a package and then extract the packages from OE/Yocto using a script or an application. Another possibility would be to extend the operation of bitbake so I pull out the package and dependencies putting them in a dedicated directory to be moved on the target for the update. For now I'm just analyzing what may be the possibilities and I'd love to have any comments or advice from someone more experienced than me on this topic. Thanks -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] (Embedded) Java 7 or 8 support
Il 22/03/2014 08:30, Marco ha scritto: Il 22/03/2014 00:02, Guy Dillen ha scritto: Hi, I'm new to Poky/Yocto. Can I make a Poky/Yocto Linux build for the Atmel SAMA5D3 Xplained (Cortex-A5 microprocessor)? Thanks. Hi, yes you can. We at KOAN are testing it this week. Basically you need a Yocto build environment plus meta-atmel https://github.com/linux4sam/meta-atmel Build Configuration: BB_VERSION= 1.20.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-12.04 TARGET_SYS= arm-poky-linux-gnueabi MACHINE = sama5d3xek DISTRO= poky DISTRO_VERSION= 1.5.1 TUNE_FEATURES = armv7a vfp thumb callconvention-hard cortexa5 TARGET_FPU= vfp meta meta-yocto meta-yocto-bsp= dora:d63a5f557d5fa4cb6637bf75f1b9d21a5c109b55 meta-oe meta-networking = dora:40e0f371f3eb1628655c484feac0cebf810737b4 meta-atmel= master:db3fae9bc539ace7ecbda6ae94547136b5577883 ... NOTE: Tasks Summary: Attempted 3486 tasks of which 1356 didn't need to be rerun and all succeeded. -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Atmel third party consultant Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com http://www.KaeilOS.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] (Embedded) Java 7 or 8 support
Il 22/03/2014 00:02, Guy Dillen ha scritto: Hi, I'm new to Poky/Yocto. Can I make a Poky/Yocto Linux build for the Atmel SAMA5D3 Xplained (Cortex-A5 microprocessor)? Thanks. Hi, yes you can. We at KOAN are testing it this week. Basically you need a Yocto build environment plus meta-atmel https://github.com/linux4sam/meta-atmel -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Atmel third party consultant Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com http://www.KaeilOS.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build qemuarm compatible with freescale i.MX6
Il 03/03/2014 10:09, Federico Vitali ha scritto: Thank you Marco! What is the best pratice for application developement purposed? Should I use a qemuarm arch or a qemux86 is better for performance reasons debugging on a x86_64 machine? Thank you again IMHO Depends on what is you goal. Just my 2 cents -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build qemuarm compatible with freescale i.MX6
Il 28/02/2014 11:03, Federico Vitali ha scritto: Goodmorning, I'm new to yocto project, I would like to know if there is the possibility to build a qemuarm kernel compatible with fsl i.MX6. I'm developing with a sabre SD board and I would like to run the same filesystem both on the real target and via qemu emulation on my PC for application developement purposes. Thank you in advance to anyone who wants to contribute! Federico, AFAIK the kernel can't be the same and moreover iMX6 generated system will use hw graphic acceleration, so probably couldn't be the same. You can use a generic ARM kernel on qemuarm and a specific one on iMX6 with the same image type though. Ciao -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build qemuarm compatible with freescale i.MX6
Il 28/02/2014 15:54, Federico Vitali ha scritto: Thank you Marco. so I can run a generic arm qemu kernel with the image created for my sabre sd card? I suppose I have to make a qemu armv7 kernel, am I wrong? In that case how can I configure my local.conf to make a qemu armv7 kernel? Thank you again Federico, The kernel and image you create for iMX6 is cortexa9hf the one created for qemuarm is arm926ejs You can do tests with quemuarm but the binaries aren't compatible. So returning to your original question, no you can't run the same filesystem both on the real target and via qemu emulation. Ciao -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-java compilation failure
Il 16/02/2014 07:09, Khem Raj ha scritto: On Feb 15, 2014, at 4:03 AM, Ashish Dalela ashish.dal...@gmail.com mailto:ashish.dal...@gmail.com wrote: checking where jni_md.h is installed... /usr/local/classpath/include checking /usr/local/classpath/include/jni_md.h usability... no checking /usr/local/classpath/include/jni_md.h presence... no checking for /usr/local/classpath/include/jni_md.h... no configure: error: cannot find jni_md.h Configure failed. The contents of all config.log files follows to aid debugging It seems to me that cacao is missing patch for supporting openjdk7, can you check if it has this patch applied in sources http://www.complang.tuwien.ac.at/hg/cacao/rev/a567bcb7f589 if not then you have to apply it -Khem I have the same problem here with meta-java (branch master and dora are the same) The patch above looks already applied to the original sources m4/java-runtime-library.m4 used by cacao_1.6.1 Do you have any other idea? TIA -- Marco ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux with Xenomai support
Il 30/08/2013 12:34, Asier ha scritto: Hello all, I've just started studying the Yocto project, so I beg your pardon if this question has been already solved or it's just too easy (RT*M). I've got a working embedded system running Xenomai v2.5.5. The user interface has been developed with Qt Embedded. The kernel has been compiled using the ELinOS Embedded Linux distribution. Now, I want to change that interface to X11 so that I can use a desktop manager as well as some other X11 applications. The ELinOS distribution has an XServer, but it lacks a way of easily adding any desktop manager. Thus, I’m thinking about using another Linux distribution. That is how I have found the Yocto project. I think this can be the best solution for my new system. Is there any Linux distribution based on the Yocto project that lets me configure my embedded kernel with Xenomai? If not, has anybody got any experinece in adding Xenomai to the Yocto project? I'm using an Atom N270 chipset. Thanks in advance, best regards, Asier Dear Asier, As Yocto project participant and thanks to our experience with Xenomai (and RTAI) we at Koan can help you migrating or integrating any hard real time requirement into Yocto or as custom stand-alone solution creating or adapting a linux distribution with Xorg, and a desktop manager. Feel free to contact me privately. Cheers -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Hello world package error
Il 21/05/2013 13:08, Paul Barker ha scritto: On 21 May 2013 12:02, Zafrullah Syed zafrullahme...@gmail.com wrote: If you run into a missing dependency, search for it on layers.openembedded.org: http://layers.openembedded.org/layerindex/recipes/?q=devmem Does your bblayers.conf point to the relevant layers? I'm just guessing here, I'd advise including the beginning of your bitbake output in any error report as that tells us what layers and versions your using, what the target and host platforms are, etc. Add in bblayers.conf BBLAYERS ?= \ ... /home/siguser/yocto/poky/meta-bebot \ Cordiali Saluti / Kindest Regards / Mit freundlichen Grüßen -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with core-image-sato at init
Il 06/03/2013 16:32, Satya Swaroop Damarla ha scritto: Hey Guys, Hi Rudy, Hi Hans As promised I am coming with the problem again.. I successfully made core-image-minimal working and boot after chnaging the boot parameters... but my core-image-sato is hanging at the boot. I looked in the init files of core-image minimal and core-image-sato and they are the same. Here is the output where it logs I tried to find the error with my little yocto experience but so far no success. I would request your professional suggestions in this problem [3.240408] VFS: Mounted root (ext2 filesystem) on device 179:1. [3.273397] devtmpfs: mounted [3.276615] Freeing init memory: 236K INIT: version 2.88 booting Cheers, Satya ___ Hi, I have the same problem here: VFS: Mounted root (nfs filesystem) on device 0:9. Freeing init memory: 144K ... more than 60 waiting with no messages nor splashscreen ... Poky 8.0 (Yocto Project 1.3 Reference Distro) 1.3+snapshot-20130315 ttyS0 login: Any hint would be appreciated. TIA -- Marco ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with core-image-sato at init
Il 15/03/2013 18:08, Satya Swaroop Damarla ha scritto: Actually the problem is with splash. I solved it by removing it in the init. Go to /etc/rc5 and either disable the splash or remove it. Then your image may run. Try this and let me know :) Nope, looks like none of the daemons in /etc/rc5 start However they start if I do manually init 2 and then init 5 -- M.C. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Slides from the Yocto Developer Day
Il 13/11/2012 08:01, Scott Garman ha scritto: On 11/12/2012 11:52 AM, Anna Dushistova wrote: Hi All, Are the slides available somewhere? Thanks! Anna. Hi Anna, Attached are the slides and lab packet I used for the intro hands-on lab in PDF format. Hi all, would be available slides and worksheet for the other YDD-2012 labs? - Hands on kernel lab by Darren Tom - YP eclipse plugin and HOB by Jessica - Yocto Project Layer for In-Vehicle Infotainment FYI many presentations don't have a link available here: https://www.yoctoproject.org/tools-resources/presentations Cheers -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake -c devshell option
2012/12/9 Bruce Ashfield bruce.ashfi...@gmail.com:
As Chris said, this way should still work, and it does work here for me.
There's
one thing that you may notice with kernel's that have split source/build
dirs
(like linux-yocto), is that once you have gone through the configure phase
and drop into the devshell you may not have KBUILT_OUTPUT set to the
build directory, and end up dropping files in the source dir .. which causes
you
mrproper and build issue.
I have a local append to devshell that sets:
d.setVar(KBUILD_OUTPUT, ${B})
To make sure things work. If you need something like this as well, or have
problems with linux-yocot, I can arrange to have something like this added
by default. But since no one else has asked about it, I assumed no one else
is either using devshell, or they haven't run into it.
Cheers,
Bruce
Dear Bruce,
I'd like to have the same behaviour as before, so what you suggested
would suit me.
Could you please tell me where to add that line?
Fileneme and function.
Thank you
--
Marco Cavallini
2012/12/9 Bruce Ashfield bruce.ashfi...@gmail.com:
On Sun, Dec 9, 2012 at 3:05 PM, Marco koansoftw...@gmail.com wrote:
Hello,
I was used to work with oe-classic.
When I used oe-classic, often I used the 'devshell' option to try to
compile (make uImage) the kernel with the entire environment set up
correctly.
Now if I do the same procedure with Yocto 8 Danny it does not work.
For example I'm using a default configuration below:
1st step
---
MACHINE=beagleboard bitbake -c devshell virtual/kernel
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = beagleboard
DISTRO= poky
DISTRO_VERSION= 1.3
TUNE_FEATURES = armv7a vfp neon cortexa8
TARGET_FPU= vfp-neon
meta
meta-yocto
meta-yocto-bsp= danny:09031ac2fc0f30ec577ee823fc61ff0e5d852e21
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 912 tasks of which 912 didn't need to be
rerun and all succeeded.
2nd step just after 1st
MACHINE=beagleboard bitbake -c devshell virtual/kernel
- Devshell starts in a new screen
$ pwd
~/yocto-8-danny/poky/build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.4.11+git1+a201268353c030d9fafe00f2041976f7437d9386_1+449f7f520350700858f21a5554b81cc8ad23267d-r4.3/linux
- lauch a kernel build (as I was used to do)
$ make
scripts/kconfig/conf --silentoldconfig Kconfig
***
*** Configuration file .config not found!
***
*** Please run some configurator (e.g. make oldconfig or
*** make menuconfig or make xconfig).
***
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** No rule to make target `include/config/auto.conf', needed by
`include/config/kernel.release'. Stop.
I would like to find out whether you can still do this and what is the new
way to go
As Chris said, this way should still work, and it does work here for me.
There's
one thing that you may notice with kernel's that have split source/build
dirs
(like linux-yocto), is that once you have gone through the configure phase
and drop into the devshell you may not have KBUILT_OUTPUT set to the
build directory, and end up dropping files in the source dir .. which causes
you
mrproper and build issue.
I have a local append to devshell that sets:
d.setVar(KBUILD_OUTPUT, ${B})
To make sure things work. If you need something like this as well, or have
problems with linux-yocot, I can arrange to have something like this added
by default. But since no one else has asked about it, I assumed no one else
is either using devshell, or they haven't run into it.
Cheers,
Bruce
TIA
--
Marco Cavallini
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Thou shalt not follow the NULL pointer, for chaos and madness await thee at
its end
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] bitbake -c devshell option
Hello, I was used to work with oe-classic. When I used oe-classic, often I used the 'devshell' option to try to compile (make uImage) the kernel with the entire environment set up correctly. Now if I do the same procedure with Yocto 8 Danny it does not work. For example I'm using a default configuration below: 1st step --- MACHINE=beagleboard bitbake -c devshell virtual/kernel Build Configuration: BB_VERSION= 1.16.0 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beagleboard DISTRO= poky DISTRO_VERSION= 1.3 TUNE_FEATURES = armv7a vfp neon cortexa8 TARGET_FPU= vfp-neon meta meta-yocto meta-yocto-bsp= danny:09031ac2fc0f30ec577ee823fc61ff0e5d852e21 NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 912 tasks of which 912 didn't need to be rerun and all succeeded. 2nd step just after 1st MACHINE=beagleboard bitbake -c devshell virtual/kernel - Devshell starts in a new screen $ pwd ~/yocto-8-danny/poky/build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.4.11+git1+a201268353c030d9fafe00f2041976f7437d9386_1+449f7f520350700858f21a5554b81cc8ad23267d-r4.3/linux - lauch a kernel build (as I was used to do) $ make scripts/kconfig/conf --silentoldconfig Kconfig *** *** Configuration file .config not found! *** *** Please run some configurator (e.g. make oldconfig or *** make menuconfig or make xconfig). *** make[2]: *** [silentoldconfig] Error 1 make[1]: *** [silentoldconfig] Error 2 make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. I would like to find out whether you can still do this and what is the new way to go TIA -- Marco Cavallini ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Howto use yocto meta-toolchain?
Il 03/12/2012 18:46, Zhang, Jessica ha scritto: Hi Marco, Can you filed a bug about this in bugzilla? Also, you don't need to sudo to run the install script, if you choose the default location which is /opt/poky/1.3, it'll prompt you for the password, or you can specify a directory under your $HOME dir. In your bug, can you provide some detail how you build the toolchain, e.g. the local.conf file changes, etc.? Jessica, thank you for answering. Bugzilla classification is different from its documentation. Where do you suggest to place my bug? https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking Actually if I don't sudo to run the install script it doesn't work: $ tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh Enter target directory for SDK (default: /opt/poky/1.3): You are about to install the SDK to /opt/poky/1.3. Proceed[Y/n]? Error: Unable to create target directory. Do you have permissions? -- Marco ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Howto use yocto meta-toolchain?
Il 04/12/2012 13:37, Laurentiu Palcu ha scritto: script it doesn't work https://bugzilla.yoctoproject.org/show_bug.cgi?id=3532 -- Marco ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Howto use yocto meta-toolchain?
Hi, after build meta-toolchain (for beagleboard, for example) I have this script 15:32 koan@quad:~/yocto-8-danny/poky/build $ ll tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh -rwxr-xr-x 1 koan koan 16143 2012-12-03 15:25 tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh Then I argued I had to launch it to install the Yocto toolchain, but I get an error 15:32 koan@quad:~/yocto-8-danny/poky/build $ sudo tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh [sudo] password for koan: Enter target directory for SDK (default: /opt/poky/1.3): You are about to install the SDK to /opt/poky/1.3. Proceed[Y/n]? Extracting SDK...done Setting it up...find: `/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/lib': No such file or directory SDK could not be set up. Relocate script failed. Abort! What's wrong? I wasn't able to find any document about it in YP website. TIA -- Marco ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Help in building an ad-hoc qte image
Hi Paul,
thanks for your reply.
If I understand correctly in that you have more than one machine and you
need
gstreamer on ANOTHERBOARD and all other machines don't need it,
let me rephrase for the sake of clearness.
This part of recipe:
RDEPENDS_${PN}-base_ANOTHERBOARD = \
libqt-embeddedphonon4 \
qt4-embedded-plugin-phonon-backend-gstreamer \
has the ultimate goal of adding phonon + gstreamer backend
for ANOTHERBOARD only to the rootfs.
It appears ok. We normally do not get indeed phonon + gstreamer backend.
The issue is that we get contents of
meta\recipes-multimedia\gstreamer\gstreamer_0.10.36.bb
(see original post for listing) in the rootfs and do not get what pull
them in.
We see that gstreamer is set as DEPENDS for qte (rif. qt4.inc) thus
correctly built together
with qt4-embedded.
But our task-qt4e-xyz recipe defines qt4-embedded as DEPENDS instead of
RDEPENDS.
Shouldn't be this enough to ask bitbake for building qte but not install
other than what specified in RDEPENDS to the rootfs?
Thanks in advance for your help. Regards.
Marco Monguzzi
RD Department
Exor International S.p.A.
Via Monte Fiorino,9
I-37057 San Giovanni Lupatoto (VR)
Phone:+390458774809 - Fax:+390458779023
Mobile:+393400884433
marco.mongu...@exorint.it - www.exorint.net - www.exorint.it
ATTENZIONE: Privacy Policy – D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica sono di
carattere privato e confidenziale ed esclusivamente rivolte al destinatario
sopra indicato. Nel caso aveste ricevuto questo messaggio di posta elettronica
per errore, vi comunichiamo che ai sensi del suddetto decreto è vietato l’uso,
la diffusione, distribuzione o riproduzione da parte di ogni altra persona.
Siete pregati di segnalarlo immediatamente rispondendo al mittente e di
distruggere quanto ricevuto (compresi i file allegati) senza farne copia o
leggerne il contenuto.
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help in building an ad-hoc qte image
Hi Paul and Andrea
thanks for your reply. I did some testing (including splitting task recipe
per each target and including PACKAGE_ARCH = ${MACHINE_ARCH})
but with no success.
Even removing this from task recipes:
RDEPENDS_${PN}-base_append_ANOTHERBOARD = \
libqt-embeddedphonon4 \
qt4-embedded-plugin-phonon-backend-gstreamer \
pulls in gstreamer. I guess some other qt lib (other than phonon
gstreamer plugin) do introduce some shlibdeps to gstreamer
as Paul indicated.
thanks for your help. Regards.
Marco Monguzzi
RD Department
Exor International S.p.A.
Via Monte Fiorino,9
I-37057 San Giovanni Lupatoto (VR)
Phone:+390458774809 - Fax:+390458779023
Mobile:+393400884433
marco.mongu...@exorint.it - www.exorint.net - www.exorint.it
ATTENZIONE: Privacy Policy – D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica sono di
carattere privato e confidenziale ed esclusivamente rivolte al destinatario
sopra indicato. Nel caso aveste ricevuto questo messaggio di posta elettronica
per errore, vi comunichiamo che ai sensi del suddetto decreto è vietato l’uso,
la diffusione, distribuzione o riproduzione da parte di ogni altra persona.
Siete pregati di segnalarlo immediatamente rispondendo al mittente e di
distruggere quanto ricevuto (compresi i file allegati) senza farne copia o
leggerne il contenuto.
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
