[yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: generate md5sums for buildtools

2016-08-12 Thread Bill Randle
Md5sum files were not being generated for the buildtools artifacts. Also,
ignore files with a .md5sum extension when doing the sum.

Signed-off-by: Bill Randle 
---
 .../autobuilder/buildsteps/PublishArtifacts.py | 27 ++
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
index f9ff4f6..1a938fc 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
@@ -112,9 +112,11 @@ class PublishArtifacts(ShellCommand):
 os.path.join(self.tmpdir, 
"deploy/images/*.zip") + \
 " " + DEST + "/" + BA_PUBLISH_DIR + ";"
 elif artifact == "buildtools-tarball":
+artifact_name, deploy_image_dir = 
self.getDeployNames(artifact, buildername)
+command=command+self.generateMD5cmd(artifact, 
deploy_image_dir)
 command=command+"mkdir -p " + DEST + "/buildtools;"
 command=command+"cp -R --no-dereference --preserve=links " 
+ \
-os.path.join(self.tmpdir, 
"deploy/sdk/*buildtools*") + \
+os.path.join(deploy_image_dir, 
"*buildtools*") + \
 " " + DEST + "/buildtools;"
 elif artifact == "rpm":
 command=command+"mkdir -p " + os.path.join(DEST, 
RPM_PUBLISH_DIR) + ";"
@@ -144,22 +146,26 @@ class PublishArtifacts(ShellCommand):
 else:
 command=command+"echo 'Skipping copy of sstate, 
PUBLISH_SSTATE not set.';"
 elif artifact == "toolchain":
+artifact_name, deploy_image_dir = 
self.getDeployNames(artifact, buildername)
+command=command+self.generateMD5cmd(artifact, 
deploy_image_dir)
 command=command+"mkdir -p " + os.path.join(DEST, 
X86TC_PUBLISH_DIR) + ";"
 command=command+"cp -R --no-dereference --preserve=links " 
+ \
-os.path.join(self.tmpdir, 
"deploy/sdk/poky-*i686-core-image*.sh ") + \
+os.path.join(deploy_image_dir, 
"poky-*i686-core-image*.sh ") + \
 os.path.join(DEST, X86TC_PUBLISH_DIR) + ";"
 command=command+"mkdir -p " + os.path.join(DEST, 
X8664TC_PUBLISH_DIR) + ";"
 command=command+"cp -R --no-dereference --preserve=links " 
+ \
-os.path.join(self.tmpdir, 
"deploy/sdk/poky-*x86_64-core-image*.sh ") + \
+os.path.join(deploy_image_dir, 
"poky-*x86_64-core-image*.sh ") + \
 os.path.join(DEST, X8664TC_PUBLISH_DIR) + 
";"
 elif artifact == "uninative":
+artifact_name, deploy_image_dir = 
self.getDeployNames(artifact, buildername)
+command=command+self.generateMD5cmd(artifact, 
deploy_image_dir)
 command=command+"mkdir -p " + os.path.join(DEST, 
X86TC_PUBLISH_DIR) + ";"
 command=command+"cp -R --no-dereference --preserve=links " 
+ \
-os.path.join(self.tmpdir, 
"deploy/sdk/i686-nativesdk-libc* ") + \
+os.path.join(deploy_image_dir, 
"i686-nativesdk-libc* ") + \
 os.path.join(DEST, X86TC_PUBLISH_DIR) + ";"
 command=command+"mkdir -p " + os.path.join(DEST, 
X8664TC_PUBLISH_DIR) + ";"
 command=command+"cp -R --no-dereference --preserve=links " 
+ \
-os.path.join(self.tmpdir, 
"deploy/sdk/x86_64-nativesdk-libc* ") + \
+os.path.join(deploy_image_dir, 
"x86_64-nativesdk-libc* ") + \
 os.path.join(DEST, X8664TC_PUBLISH_DIR) + 
";"
 elif artifact == "oe-toolchain":
 command=command+"mkdir -p " + os.path.join(DEST, 
X86TC_PUBLISH_DIR) + ";"
@@ -209,7 +215,7 @@ class PublishArtifacts(ShellCommand):
  os.path.join(self.basedir, "conf/") + \
  "/* " + DEST + "/" + MACHINE_PUBLISH_DIR 
+ "/" + artifact_name + "/conf;"
 elif artifact == "md5sums":
-command = command + "echo 'MD5sums are generated and 
deployed from the image artifact';"
+command = command + "echo 'MD5sums are generated and 
deployed from the image or toolchain artifact';"
 elif artifact == "None":
 command=command+"echo 

[yocto] [ANNOUNCEMENT] Yocto Project 2.1.1 (Krogoth 15.0.1) Released

2016-08-12 Thread Tracy Graydon
Hello,

The latest release of the Yocto Project 2.1.1 (krogoth-15.0.1) is now available 
for download at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.1.1/poky-krogoth-15.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.1.1/poky-krogoth-15.0.1.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.1.1/RELEASENOTES

Full pass test report is available at:

https://wiki.yoctoproject.org/wiki/WW32_-_2016-08-01_-_Test_Cycle_2.1.1_rc2

Thanks go out to everyone for all their hard work during this release!

Sincerely,

Tracy Graydon
Yocto Project
Build and Release


---
yocto-2.1.1 Errata
---

Release Name: eclipse-poky-kepler-krogoth-15.0.1
Branch: kepler/krogoth
Tag: kepler/krogoth-15.0.1
Hash: f402f9a24114f26c9a057a74206bdca87473367b
md5: cc6705706304b9bef56bfafe4d5cffcf
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.1.1/eclipse-poky-kepler-krogoth-15.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.1.1/eclipse-poky-kepler-krogoth-15.0.1.tar.bz2

Release Name: eclipse-poky-luna-krogoth-15.0.1
Branch: luna/krogoth
Tag: luna/krogoth-15.0.1
Hash: 155aefbdd7ea776504dedeb7468db2ecd4228629
md5: 81ccc03dad94d04496189322f72d78d6
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.1.1/eclipse-poky-luna-krogoth-15.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.1.1/eclipse-poky-luna-krogoth-15.0.1.tar.bz2

Release Name: eclipse-poky-mars-krogoth-15.0.1
Branch: mars/krogoth
Tag: mars/krogoth-15.0.1
Hash: 9b10b9eeaa87580c2126f18d74fe2ff9c8eaf951
md5: c58b98e9ac742f7283e3b06068ff7c21
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.1.1/eclipse-poky-mars-krogoth-15.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.1.1/eclipse-poky-mars-krogoth-15.0.1.tar.bz2

Release Name: meta-qt3-krogoth-15.0.1
Branch: krogoth
Tag: krogoth-15.0.1
Hash: 7d958b928a4a38a186746fabbc0d8169dd8bb3a6
md5: 43fe89220ce1c1efa4b1f176562649bb
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.1.1/meta-qt3-krogoth-15.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.1.1/meta-qt3-krogoth-15.0.1.tar.bz2

Release Name: meta-qt4-krogoth-15.0.1
Branch: krogoth
Tag: krogoth-15.0.1
Hash: 92a72a790a427af5f85ce86fea4fce86a72c7b58
md5: 55ba7c7f0c99a6541c983bb3a4cf98ec
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.1.1/meta-qt4-krogoth-15.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.1.1/meta-qt4-krogoth-15.0.1.tar.bz2

Release Name: poky-krogoth-15.0.1
Branch: krogoth
Tag: krogoth-15.0.1
Hash: f5da2a5913319ad6ac2141438ba1aa17576326ab
md5: 891932438c5a89e757a1e9a9f3e0084a
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.1.1/poky-krogoth-15.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.1.1/poky-krogoth-15.0.1.tar.bz2



 Known Issues


Bug #9362: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9362
Failed to run and debug a project to qemux86 in Eclipse
Fix is on master. Commit: 6deadf5498d091462b92a261e5467f2f754d4921


Security Fixes

foomatic-filters: Security fixes CVE-2015-8327
foomatic-filters: Security fix CVE-2015-8560
glibc: Security fix for CVE-2016-4429
glibc: Security fix for CVE-2016-3706
libpcre: Fix CVE-2016-3191
gcc: Security fix CVE-2016-4490
gcc: Security fix CVE-2016-2226
gcc: Security fix CVE-2016-4489
gcc: Security fix CVE-2016-4488
qemu: Security fix CVE-2016-2858
qemu: Security fix CVE-2016-2857
busybox: Security fix CVE-2016-2147
busybox: Security Fix CVE-2016-2148
openssh: Security Fix CVE-2016-3115
tiff: Security fixes CVE-2015-8665 and CVE-2015-8683



Fixes

build-appliance-image: Update to krogoth head revision
libproxy: use snapshot.debian.org for SRC_URI
libaio: use snapshot.debian.org for SRC_URI
blktool: use snapshot.debian.org for SRC_URI
linuxdoc-tools: use snapshot.debian.org for SRC_URI
docbook-xml-dtd4: use snapshot.debian.org for SRC_URI
netbase: use snapshot.debian.org for SRC_URI
serf: use snapshot.debian.org for SRC_URI
mailx: use snapshot.debian.org for SRC_URI
ossp-uuid: use snapshot.debian.org for SRC_URI
apmd: use snapshot.debian.org for SRC_URI
at: use snapshot.debian.org for SRC_URI
dpkg: use snapshot.debian.org for SRC_URI
oeqa/recipetool: update recipe test to pass SHA
grub: Fix build with gcc-6
oeqa/devtool: update recipe test as libmatchbox changed
nss: fix build for gcc-6
tzcode-native: update to 2016f
tzdata: update to 2016f
gcc-5.3: fix build for gcc-6
openjade-native: work around bug exposed by GCC 6
binutils: disable werror on native build
glib-2.0: Ignore useless warning found with gcc-6
rpm: Fix build with gcc6
elfutils: Fix build for gcc-6
elfutils-0.148: Fix build with gcc6
pkgconfig: Fix build with gcc-6
binutils: backport fix for TLSDESC relocations with no 

Re: [yocto] Is There a easy way to check which version of GCC was been used to a package

2016-08-12 Thread Daniel.
Try executing libc. It shows the version of gcc that was used to be
compiled. Here is a sample output from *my workstation*.

[geckos@localhost ~]$ /lib/libc-2.24.so
GNU C Library (GNU libc) stable release version 2.24, by Roland McGrath et
al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 6.1.1 20160802.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
.
[geckos@localhost ~]$




2016-08-12 7:07 GMT-03:00 Richard Zhang :

> Hi all
>
>
>
> After use yocto build linux distro , how could I check the toolchain’s
> version?
>
> Is there a version description?
>
>
>
>
>
>
>
>
>
> Best Regard.
>
>
>
> Richard Zhang
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
*"Do or do not. There is no try"*
  *Yoda Master*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta-swupd][PATCH] swupd-image: Fix files ownership if IMAGE_BASENAME is not default

2016-08-12 Thread Joshua G Lock
On Thu, 2016-08-11 at 14:27 +0200, Piotr Figiel wrote:
> From: Piotr Figiel 
> 
> In case IMAGE_BASENAME is set on image recipe level the files
> ownership on
> target rootfs is incorrect for recipes inheriting swupd-
> image.bbclass.
> Depending on the context swupd-image.bbclass used either PN (PN_BASE)
> or
> IMAGE_BASENAME when generating path to pseudo shared state directory.
> This
> seems correct only when IMAGE_BASENAME is not set as it defaults to
> PN.
> 
> This patch resolves above problem.
> 
> Addresses [YOCTO #10108].

Good catch, thanks! Patch pushed to meta-swupd master.

Joshua

> 
> Signed-off-by: Piotr Figiel 
> ---
>  classes/swupd-image.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/classes/swupd-image.bbclass b/classes/swupd-
> image.bbclass
> index 08ab3f5..ed9bd24 100644
> --- a/classes/swupd-image.bbclass
> +++ b/classes/swupd-image.bbclass
> @@ -81,7 +81,7 @@ python () {
>  # Because real image building via SWUPD_IMAGES can happen
> also after
>  # the initial "bitbake " invocation, we have to
> keep that
>  # pseudo database around and cannot delete it.
> -pseudo_state = d.expand('${TMPDIR}/work-
> shared/${PN_BASE}/pseudo')
> +pseudo_state = d.expand('${TMPDIR}/work-
> shared/${IMAGE_BASENAME}/pseudo')
>  d.setVar('PSEUDO_LOCALSTATEDIR', pseudo_state)
>  
>  # Non mega virtual images must depend on the mega image
> having been
> -- 
> 1.9.1
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta][PATCH v2] python-3.4-manifest: Add some missing RDEPENDS

2016-08-12 Thread Kyle Russell
Ok, thanks!  Sorry about that, not sure what happened.

On Fri, Aug 12, 2016 at 10:00 AM, Burton, Ross 
wrote:

>
> On 11 August 2016 at 22:14, Kyle Russell  wrote:
>
>> In case anyone is interested, I posted an update for both the script and
>> .inc to openembedded-core (which now has master at python 3.5), but it
>> doesn't seem to have gone anywhere yet.
>>
>
> Sorry that got stalled because the patch was mangled by your mailer so I
> had to fix the patch by hand.  I've applied it to my staging branch, thanks.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta][PATCH v2] python-3.4-manifest: Add some missing RDEPENDS

2016-08-12 Thread Burton, Ross
On 11 August 2016 at 22:14, Kyle Russell  wrote:

> In case anyone is interested, I posted an update for both the script and
> .inc to openembedded-core (which now has master at python 3.5), but it
> doesn't seem to have gone anywhere yet.
>

Sorry that got stalled because the patch was mangled by your mailer so I
had to fix the patch by hand.  I've applied it to my staging branch, thanks.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] can one use "ASSUME_PROVIDED += mono-native" to avoid compiling?

2016-08-12 Thread Burton, Ross
On 12 August 2016 at 11:50, Robert P. J. Day  wrote:

>   built mono for the first time, and a significant amount of time was
> spent compiling mono-native. if i already have mono on my build host,
> is it worth checking if i can take advantage of it?
>

sstate obviously means if it doesn't change then you won't be rebuilding it
again for a while, but yeah you can look at that.  Obviously it's your
responsibility if the host mono isn't good enough (too old, missing
patches, etc) but before I got a faster machine I put a fair number of
tools in ASSUME_PROVIDED for this reason.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Access Control List (ACL) permissions attributes not getting preserved in rootfs

2016-08-12 Thread Joshua G Lock
On Fri, 2016-08-12 at 12:33 +, Kumar, Shrawan wrote:
> Hello All,
>  
> I am  using  poky “ jethro”  , and  though  one of my recipe, I have
> created user1 & user2 and then trying to set ACL rules  on
> “helloworld” bin as below :
>  
>  
> do_install() {
>     install -d ${D}${bindir}
>     install -m 0700 helloworld ${D}${bindir}
>     install -d ${D}/lib/systemd/system
>     install -m 0700 hello.service
> ${D}/lib/systemd/system/
>     chown    user1:group1 ${D}${bindir}/helloworld
>        setfacl -m u:user2:r-- ${D}${bindir}/helloworld
> }
>  
>  
> è When I see   on the devshell ( bitbake HelloWorld –c devshell)  :
> poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld    , I could see
> that ACL permissions are set correctly as below :
> -    # file: helloworld
> -    # owner: user1
> -    # group: group1
> -    user::rwx
> -    user:user2:r--
> -    group::---
> -    mask::r--
> -    other::---
>  
> However, It does not seems to be getting preserved in rootfs. :
> /poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld
> # file: helloworld
> # owner: user1
> # group: group1
> user::rwx
> group::---
> other::---
>  
> quick help  here would be highly appreciated

This is due to the fact that we don't currently have a mechanism to
preserve xattr through to image construction[1].

The largest barrier for doig so is that the package managers (certainly
dpkg and rpm) don't have any support for xattrs in packages (an image
is populated via the package manager).

To the best of my knowledge the only option for adding some xattr/ACL
is to use a postinst[2] to set the attributes after the package has
been installed.

Regards,

Joshua

1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9858
2. http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#new-
recipe-post-installation-scripts

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Access Control List (ACL) permissions attributes not getting preserved in rootfs

2016-08-12 Thread Kumar, Shrawan
Hello All,

I am  using  poky " jethro"  , and  though  one of my recipe, I have created 
user1 & user2 and then trying to set ACL rules  on "helloworld" bin as below :


do_install() {
install -d ${D}${bindir}
install -m 0700 helloworld ${D}${bindir}
install -d ${D}/lib/systemd/system
install -m 0700 hello.service ${D}/lib/systemd/system/
chownuser1:group1 ${D}${bindir}/helloworld
   setfacl -m u:user2:r-- ${D}${bindir}/helloworld
}



è When I see   on the devshell ( bitbake HelloWorld -c devshell)  : 
poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs/usr/bin#
 getfacl helloworld, I could see that ACL permissions are set correctly as 
below :

-# file: helloworld

-# owner: user1

-# group: group1

-user::rwx

-user:user2:r--

-group::---

-mask::r--

-other::---

However, It does not seems to be getting preserved in rootfs. :
/poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs/usr/bin#
 getfacl helloworld
# file: helloworld
# owner: user1
# group: group1
user::rwx
group::---
other::---

quick help  here would be highly appreciated


Thanks & Regards
Shrawan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] can one use "ASSUME_PROVIDED += mono-native" to avoid compiling?

2016-08-12 Thread Robert P. J. Day

  built mono for the first time, and a significant amount of time was
spent compiling mono-native. if i already have mono on my build host,
is it worth checking if i can take advantage of it?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Is There a easy way to check which version of GCC was been used to a package

2016-08-12 Thread Richard Zhang
Hi all

After use yocto build linux distro , how could I check the toolchain's version?
Is there a version description?




Best Regard.

Richard Zhang
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] if else blocks in recipes(bitbake)

2016-08-12 Thread Burton, Ross
On 12 August 2016 at 09:46,  wrote:

>
> If have a simple problem. On one system a program is started as a daemon
> and on the other one not. In my recipe the program is build. by using
> update-rc.d I create the init script for systemV. The code looks like:


The easy solution here is to build two packages, one with the app in and
another that just contains the init script.  Then systems where you just
want the applications can install just the application, and systems where
you want the init script too can install both.

Or, always build with the init script and use a rootfs post-image hook to
remove it.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] if else blocks in recipes(bitbake)

2016-08-12 Thread S . Jaritz
Hej

If have a simple problem. On one system a program is started as a daemon 
and on the other one not. In my recipe the program is build. by using 
update-rc.d I create the init script for systemV. The code looks like:
##
SUMMARY = "myApp"
SECTION = "myApp"
LICENSE = "CLOSED"

DEPENDS = "dbus glibmm libsigc++-2.0 libconfig"
RDEPENDS_${PN} = "bash initscripts"

inherit cmake update-rc.d

SRCREV = "${AUTOREV}"
SRC_URI = "gitsm://myServer/myApp;protocol=http;branch=develop"

PVBASE := "${PV}"
PV = "${PVBASE}.${SRCPV}"

S = "${WORKDIR}/git/"

INITSCRIPT_PARAMS = "start 95 2 3 4 5 . stop 01 0 1 6 ."
INITSCRIPT_NAME = "myAppD.sh"

CONFFILES_${PN} += "${sysconfdir}/init.d/myAppD.sh"
##
Would like to that(pseudo-code):
##
BUILDVAR = "yes"

if BUILDVAR == "yes" then
INITSCRIPT_PARAMS = "start 95 2 3 4 5 . stop 01 0 1 6 ."
INITSCRIPT_NAME = "myAppD.sh"
 
CONFFILES_${PN} += "${sysconfdir}/init.d/myAppD.sh"
endif
##

How to tell this bitbake? 

Regards!

Stefan Jaritz


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto