Re: [yocto] force a factory-preset sdk to quemu

2018-11-02 Thread Kosta Zertsekel 
On Fri, Nov 2, 2018, 10:28 Zolee K wrote:

> I got my board with Yocto based SDK but there is no quemu in the
> configfile by default. Is it possible to add quemu capability manually to
> factory-preset sdk?
>
If Yocto SDK you have is actually Yocto eSDK (extended SDK), you can try
the below:
$ MACHINE=qemux86 bitbake build-image

--- Kosta Z

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

Re: [yocto] [PATCH] nginx: module: add ngx-http-auth-pam-module

2018-11-01 Thread Kosta Zertsekel 
Guys,

I sent the commit to discuss if this is the right way to include NGINX
module in the customization layer.
It actully compiles OK and works in run-time on target.
But, again, I'm looking for the **right** way to do it.
I'll be happy to get some feedback.

Thanks,
--- Kosta Z
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] nginx: module: add ngx-http-auth-pam-module

2018-11-01 Thread Kosta Zertsekel 
NGINX support adding third-party modules.
These modules are created and maintained by members of the NGINX community.
NGINX, Inc. provides support for some of these modules.

Each module is developed as a separate git project, but can be compiled
only as part of NGINX compilation using `--add-module` parameter.

Signed-off-by: Kosta Zertsekel 
---
 recipes-httpd/nginx/nginx_%.bbappend  |  5 
 .../ngx-http-auth-pam-module_git.bb   | 24 +++
 2 files changed, 29 insertions(+)
 create mode 100644 recipes-httpd/nginx/nginx_%.bbappend
 create mode 100644 
recipes-ngx-http-auth-pam-module/ngx-http-auth-pam-module/ngx-http-auth-pam-module_git.bb

diff --git a/recipes-httpd/nginx/nginx_%.bbappend 
b/recipes-httpd/nginx/nginx_%.bbappend
new file mode 100644
index 000..d3ed1bf
--- /dev/null
+++ b/recipes-httpd/nginx/nginx_%.bbappend
@@ -0,0 +1,5 @@
+DEPENDS += "ngx-http-auth-pam-module"
+
+EXTRA_OECONF += " \
+--add-module=${STAGING_DIR_TARGET}/ngx-http-auth-pam-module \
+"
diff --git 
a/recipes-ngx-http-auth-pam-module/ngx-http-auth-pam-module/ngx-http-auth-pam-module_git.bb
 
b/recipes-ngx-http-auth-pam-module/ngx-http-auth-pam-module/ngx-http-auth-pam-module_git.bb
new file mode 100644
index 000..8f13c3f
--- /dev/null
+++ 
b/recipes-ngx-http-auth-pam-module/ngx-http-auth-pam-module/ngx-http-auth-pam-module_git.bb
@@ -0,0 +1,24 @@
+LICENSE = "Unknown"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=1eccc8f95bc958cb0e1569c433286a22"
+
+SRC_URI = "git://github.com/sto/ngx_http_auth_pam_module;protocol=https"
+
+PV = "1.5+git${SRCPV}"
+SRCREV = "d9286fc7b52e1a3584da2cb20423f912ec99169f"
+
+S = "${WORKDIR}/git"
+
+SYSROOT_DIRS += "/${PN}"
+
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+# Nginx module is compiled as part of nginx build using --add-module,
+# hence, just copy the sources here to be picked up by nginx later.
+do_install () {
+   cd ${S}
+   git checkout-index -a --prefix=${D}/${PN}/
+   cd -
+}
+
+FILES_${PN} = "${PN}/*"
-- 
2.17.1

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

Re: [yocto] Help with Nano Recipe

2018-10-30 Thread Kosta Zertsekel 
> It is very unusual to implement a recipe this way , and you should
> rely on base classes to do that for you. For reference there is a
> recipe for 'nano' in meta-oe already.
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/nano/nano_3.0.bb?h=master

And if you find anything amiss in this ``nano_3.0.bb`` recipe, you should have 
definitely begun with ``devtool``.
For example:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#using-devtool-in-your-sdk-workflow

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

Re: [yocto] How to update YP kernel image (run-time)

2018-10-30 Thread Kosta Zertsekel 
On Tuesday, 30 October 2018 4:23 Raymond Yeung wrote:
> Let's say I've a working run-time system running 2016 April release (Krogoth) 
> Poky image.
> I've it installed previously from a USB thumb drive onto a much bigger SSD 
> with all partitions setup.
> I don't need to change the partition from here onward.
> Is there an easy way to replace it with, say 2017 Oct release (Rocko) Poky 
> image (and vice versa)?
> E.g. by replacing just one file (e.g. bzImage)?
> Or is there a script that would take care of it?
> What happens to all the existing directories, e.g. /etc, /bin etc.?

The question has no connection to a specific Yocto release at all.
If I rephrase the question it becomes "How do I upgrade my Linux system at 
all?".
Take a look at ResinOS partition scheme here:
https://www.balena.io/docs/reference/OS/overview/2.x/#image-partition-layout
May be it can shed a bit of a light.

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

Re: [yocto] Sumo distro problem with dhcp packet?

2018-10-17 Thread Kosta Zertsekel 
I suggest trying other reference image.

For example, core-image-minimal.

If it does not help, then core-image-full-cmdline.

Let's get the working reference first with one of these images.


--- Kosta Z.


From: Zoran Stojsavljevic 
Sent: Wednesday, 17 October 2018 11:37:38
To: Kosta Zertsekel; Yocto Project
Subject: Re: [yocto] Sumo distro problem with dhcp packet?

Hello Kosta and others,

I am a bit behind on a schedule on this one. Albeit I followed the
advise, This does work for compiling and adding all these packages to
the ROOTFS. I see that after I added all them, I see the
initramfs.tar.xz expanded in
...poky/build/tmp/deploy/image/beagleboneblack/ directory.

But after I do the testing with initramfs, with all these packages
added. I do not find anything in the ROOTFS even what it should be
lookalike DHCP.

After trying # which dhclient, or # which dhcp-client, or # which
dhcp... It finds nothing!

Then, the next step was to find /etc/dhcp/ or similar. There is
nothing lookalike dhcp/ or dhcp* in /etc, which shows that these lines
in dhcp.inc recipe are not executed:

do_install_append () {
   install -d ${D}${sysconfdir}/init.d
   install -d ${D}${sysconfdir}/default
   install -d ${D}${sysconfdir}/dhcp
   install -m 0755 ${WORKDIR}/init-relay ${D}${sysconfdir}/init.d/dhcp-relay
   install -m 0644 ${WORKDIR}/default-relay
${D}${sysconfdir}/default/dhcp-relay
   install -m 0755 ${WORKDIR}/init-server
${D}${sysconfdir}/init.d/dhcp-server
   install -m 0644 ${WORKDIR}/default-server
${D}${sysconfdir}/default/dhcp-server

   rm -f ${D}${sysconfdir}/dhclient.conf*
   rm -f ${D}${sysconfdir}/dhcpd.conf*

In addition, when I execute: $ bitbake -c cleanall dhcp, it says that
it executes thee tasks, and none of them are actually executed (0
executed).

I also recompiled form scratch the whole sumo BBB build, but this did
NOT solve the problem.

Any hint how I should proceed?

Thank you,
Zoran
___

On Thu, Oct 11, 2018 at 1:40 PM Zoran Stojsavljevic
 wrote:
>
> Hello Kosta,
>
> > For example, you can do the below:
> > CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp-client dhcp-server cmake... 
> > "
>
> I added to this example dhcp-relay, just to test the whole build, and
> it does work. Actually, I need only dhcp-client for the target (since
> I have dhcp-server on the ETH interface on the opposite (VM) side).
>
> Thank you for the help!
> Zoran
> ___
> On Wed, Oct 10, 2018 at 5:57 PM Kosta Zertsekel
>  wrote:
> >
> > You need to take a look at the available dhcp packages
> > for dhcp recipe here:
> > https://git.yoctoproject.org/clean/cgit.cgi/poky/tree/meta/recipes-connectivity/dhcp/dhcp.inc#n100
> >
> > PACKAGES += "dhcp-libs dhcp-server dhcp-server-config dhcp-client 
> > dhcp-relay dhcp-omshell"
> >
> > For example, you can do the below:
> > CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp-client dhcp-server cmake... 
> > "
> >
> > Thanks,
> > --- Kosta Z
> > 
> > From: yocto-boun...@yoctoproject.org  on 
> > behalf of Zoran Stojsavljevic 
> > Sent: Wednesday, 10 October 2018 16:29:05
> > To: Yocto Project
> > Subject: [yocto] Sumo distro problem with dhcp packet?
> >
> > Hello.
> >
> > I need on my test initramfs YOCTO image to add dhcp package (both dhcp 
> > server and client).
> >
> > For the beginning, I traced it, where it is:
> > .../poky/meta/recipes-connectivity/dchp
> >
> > and decided to test it adding it to ...poky/build/conf/local.conf for the 
> > starters:
> > CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp cmake... "
> >
> > But it produced the following error:
> > [user@fedora28-ssd conf]$ bitbake -k core-image-base
> >
> >[snap]
> >
> > ERROR: Nothing RPROVIDES 'dhcp' (but 
> > /home/user/projects2/beaglebone-black/sumo/poky/meta/recipes-core/images/core-image-base.bb
> >  RDEPENDS on or otherwise requires it)
> > NOTE: Runtime target 'dhcp' is unbuildable, removing...
> > Missing or unbuildable dependency chain was: ['dhcp']
> > ERROR: Nothing RPROVIDES 'core-image-base'
> > No eligible RPROVIDERs exist for 'core-image-base'
> > NOTE: Runtime target 'core-image-base' is unbuildable, removing...
> > Missing or unbuildable dependency chain was: ['core-image-base']
> >
> > I added another package, dhcpcd, which is located in the another layer:
> > CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcpcd cmake... "
> >
> > so this one worked/was integrated seamlessly.
> >
> > What is the catch 22 here?
> >
> > Thank you,
> > Zoran
> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Force rebuild to regenerate .ko

2018-10-13 Thread Kosta Zertsekel 
Please add more details.


For example, where ixgbe.ko resides (what layer)?

If it is in Linux kernel (linux-yocto package), then just:

$ bitbake linux-yocto -c cleanall

$ bitbake linux-yocto


--- Kosta Z.



From: yocto-boun...@yoctoproject.org  on behalf 
of Raymond Yeung 
Sent: Friday, 12 October 2018 6:29:44
To: yocto@yoctoproject.org
Subject: [yocto] Force rebuild to regenerate .ko

I've a Intel Ethernet driver, ixgbe.ko.  I made some changes (debug logs) to 
the source file.  How do I force the .ko to be regenerated within yocto 
environment, without rebuilding the entire yocto code base?

I tried to do bitbake of the image name earlier, but bitbake decides that 
there's nothing to be done.  This is even after I'd removed the cache and 
sstate directories.

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

Re: [yocto] Sumo distro problem with dhcp packet?

2018-10-10 Thread Kosta Zertsekel 
You need to take a look at the available dhcp packages
for dhcp recipe here:
https://git.yoctoproject.org/clean/cgit.cgi/poky/tree/meta/recipes-connectivity/dhcp/dhcp.inc#n100

PACKAGES += "dhcp-libs dhcp-server dhcp-server-config dhcp-client dhcp-relay 
dhcp-omshell"

For example, you can do the below:
CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp-client dhcp-server cmake... "

Thanks,
--- Kosta Z

From: yocto-boun...@yoctoproject.org  on behalf 
of Zoran Stojsavljevic 
Sent: Wednesday, 10 October 2018 16:29:05
To: Yocto Project
Subject: [yocto] Sumo distro problem with dhcp packet?

Hello.

I need on my test initramfs YOCTO image to add dhcp package (both dhcp server 
and client).

For the beginning, I traced it, where it is:
.../poky/meta/recipes-connectivity/dchp

and decided to test it adding it to ...poky/build/conf/local.conf for the 
starters:
CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp cmake... "

But it produced the following error:
[user@fedora28-ssd conf]$ bitbake -k core-image-base

   [snap]

ERROR: Nothing RPROVIDES 'dhcp' (but 
/home/user/projects2/beaglebone-black/sumo/poky/meta/recipes-core/images/core-image-base.bb
 RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'dhcp' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['dhcp']
ERROR: Nothing RPROVIDES 'core-image-base'
No eligible RPROVIDERs exist for 'core-image-base'
NOTE: Runtime target 'core-image-base' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['core-image-base']

I added another package, dhcpcd, which is located in the another layer:
CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcpcd cmake... "

so this one worked/was integrated seamlessly.

What is the catch 22 here?

Thank you,
Zoran

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

Re: [yocto] gRPC: grpc_cpp_plugin is not included in host sysroot for standard sdk

2018-08-28 Thread Kosta Zertsekel 
I think it is a very sensible approach to first check in the latest branch.

If it is supported in the latest branch - then port it.

So - is this thing supported in the latest poky branch?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Porting rtc-pcf85363.c file

2018-08-28 Thread Kosta Zertsekel 
>> I need to port rtc-pcf85363 driver to older version of linux.

What version exactly?

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

Re: [Yocto-bsp] PHP in Yocto using Apache2

2018-08-01 Thread Kosta Zertsekel 
>> There is some accidental bug in Krogoth PHP git code - in php.inc.
>> Tried using master git code changes from this. Not working.
>> Please suggest any other changes I need to do.
I suggest to do the whole thing first (adding Apache **and** PHP) using
Yocto 2.5 (Sumo).
When it works in Yocto 2.5 you have a reference!
Then you can find the fixes and port them back to Yocto Krogoth...

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

Re: [yocto] Fix 'PACKAGES' in net-snmp recipe

2018-03-19 Thread Kosta Zertsekel 
On Monday, March 19, 2018 9:38 AM Huang, Jie (Jackie) wrote:
> It was changed for two reasons referred to the commit 5eec0615e:
>
> """
> - Change to use append for PACKAGES so that:
>   * ptest package is added from ptest bbcalss
>   * the PN is back, allow empty and add rdepends on net-snmp-client
> in case the user try to add net-snmp to the image
> """
>
> 1) The 'PACKAGEs = ...' will override the definition from bbclass like 
> ptest.bbclass
> 2) We had customers assume that the ${PN} package for each recipe always 
> exist so when they wanted to
> use net-snmp clients, they tried to install net-snmp but failed.
>
> If you don't like the solution, you can use _remove operation to remove PN 
> from PACKAGES.
>
> Other default packages like ${PN}-doc and ${PN}-locale, them are also empty 
> for many other recipes,
> I don't think it's an issue, so no need to re-define the PACKAGES or remove 
> them with _remove operation.

Ok. Agree. Non-issue.
Thank you guys a lot for the explanation!

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

Re: [yocto] Fix 'PACKAGES' in net-snmp recipe

2018-03-19 Thread Kosta Zertsekel 
> are there specific issue you are seeing besides the packages being empty ?
> I would suggest to apply _remove operation to remove the empty packages
> if needed from PACKAGES variable

No any other specific issues are seen.

> I agree, I don't think it's an issue that the packages
> being empty, and actually they're handled properly with:
>
> ALLOW_EMPTY_${PN} = "1"
> ALLOW_EMPTY_${PN}-server = "1"
>
> RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'perl', 
> 'net-snmp-perl-modules', '', d)}"
> RDEPENDS_${PN} += "net-snmp-client"
> RDEPENDS_${PN}-server += "net-snmp-server-snmpd net-snmp-server-snmptrapd"
>
> So you can assume that "net-snmp" = "net-snmp-client" ( plus 
> 'net-snmp-perl-modules'
> if 'perl' packgeconfig is enabled ), and "net-snmp-server" = " 
> net-snmp-server-snmpd"
> +"net-snmp-server-snmptrapd "

So, you mean that 'PACKAGEs = ...' was changed to 'PACKAGES += ...' in order
to create the default packages (${PN}, ${PN}-doc, ${PN}-locale, etc.) that are
empty? Is there a chance it was done to satisfy a default dependencies in
bitbake.conf? I just fail to see the original meaning...


--- Kosta Z.


From: Huang, Jie (Jackie) <jackie.hu...@windriver.com>
Sent: Monday, March 19, 2018 3:56:28 AM
To: Khem Raj; Kosta Zertsekel
Cc: yocto@yoctoproject.org; Enache, Catalin; Zhou, Li
Subject: RE: [yocto] Fix 'PACKAGES' in net-snmp recipe



> -Original Message-
> From: Huang, Jie (Jackie)
> Sent: Monday, March 19, 2018 09:51
> To: 'Khem Raj'; Kosta Zertsekel
> Cc: yocto@yoctoproject.org; Enache, Catalin; Zhou, Li
> Subject: RE: [yocto] Fix 'PACKAGES' in net-snmp recipe
>
>
>
> > -Original Message-
> > From: Khem Raj [mailto:raj.k...@gmail.com]
> > Sent: Monday, March 19, 2018 05:54
> > To: Kosta Zertsekel
> > Cc: yocto@yoctoproject.org; Huang, Jie (Jackie); Enache, Catalin; Zhou, Li
> > Subject: Re: [yocto] Fix 'PACKAGES' in net-snmp recipe
> >
> > On Sat, Mar 17, 2018 at 11:46 PM, Kosta Zertsekel
> > <kzertse...@advaoptical.com> wrote:
> > > Hi guys,
> > >
> > >
> > > As for now (master branch) 'PACKAGES' variable in net-snmp equals to:
> > >
> > > ```
> > >
> > > $ bitbake -e net-snmp | grep "^PACKAGES="
> > >
> > > PACKAGES="net-snmp-dbg net-snmp-staticdev net-snmp-dev net-snmp-doc
> > > net-snmp-locale  net-snmp net-snmp-libs net-snmp-mibs net-snmp-server
> > > net-snmp-client net-snmp-server-snmpd net-snmp-server-snmptrapd "
> > > ```
> > >
> > > This seems to be wrong as many built packages from 'packages-split'
> > > directory of net-snmp are empty:
> > >
> > > ```
> > > $ du -a --max-depth=1 . | sort -n
> > > 4./net-snmp
> > > 4./net-snmp-client.shlibdeps
> > > 4./net-snmp-doc
> > > 4./net-snmp-libs.shlibdeps
> > > 4./net-snmp-locale
> > > 4./net-snmp-server
> > > 4./net-snmp-server-snmpd.shlibdeps
> > > 4./net-snmp-server-snmptrapd.shlibdeps
> > > 4./net-snmp-staticdev
> > > 48./net-snmp-server-snmptrapd
> > > 72./net-snmp-server-snmpd
> > > 1208./net-snmp-dev
> > > 1480./net-snmp-client
> > > 1812./net-snmp-mibs
> > > 2872./net-snmp-libs
> > > 15308./net-snmp-dbg
> > > ```
> > >
> > > Well, the culprit commit is 5eec0615e548f58ecdfadfc45af5805eeb58f69c where
> > > the below change has happened:
> > > ```
> > > -PACKAGES = "${PN}-dbg ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-static
> > > ${PN}-libs \
> > > -${PN}-mibs ${PN}-server ${PN}-client ${PN}-server-snmpd
> > > ${PN}-server-snmptrapd"
> > > +PACKAGES += "${PN}-libs ${PN}-mibs ${PN}-server ${PN}-client
> > > ${PN}-server-snmpd ${PN}-server-snmptrapd"
> > > ```
> > >
> > > This new 'PACKAGES' variable is wrong IMHO, because it contains
> > > the 'net-snmp' package and other empty packages.
> > >
> > >
> > > Please review (and apply if ok) the attached commit that fixes it.
> > >
> >
> > are there specific issue you are seeing besides the packages being empty ?
> > I would suggest to apply _remove operation to remove the empty packages
> > if needed from PACKAGES variable
>
> I agree, I don't think it's an issue that the packages being empty, and 
> actually they're handled properly with:
>
> A

[yocto] Fix 'PACKAGES' in net-snmp recipe

2018-03-18 Thread Kosta Zertsekel 
Hi guys,


As for now (master branch) 'PACKAGES' variable in net-snmp equals to:

```

$ bitbake -e net-snmp | grep "^PACKAGES="

PACKAGES="net-snmp-dbg net-snmp-staticdev net-snmp-dev net-snmp-doc 
net-snmp-locale  net-snmp net-snmp-libs net-snmp-mibs net-snmp-server 
net-snmp-client net-snmp-server-snmpd net-snmp-server-snmptrapd "
```


This seems to be wrong as many built packages from 'packages-split' directory 
of net-snmp are empty:

```
$ du -a --max-depth=1 . | sort -n
4./net-snmp
4./net-snmp-client.shlibdeps
4./net-snmp-doc
4./net-snmp-libs.shlibdeps
4./net-snmp-locale
4./net-snmp-server
4./net-snmp-server-snmpd.shlibdeps
4./net-snmp-server-snmptrapd.shlibdeps
4./net-snmp-staticdev
48./net-snmp-server-snmptrapd
72./net-snmp-server-snmpd
1208./net-snmp-dev
1480./net-snmp-client
1812./net-snmp-mibs
2872./net-snmp-libs
15308./net-snmp-dbg
```

Well, the culprit commit is 5eec0615e548f58ecdfadfc45af5805eeb58f69c where the 
below change has happened:
```
-PACKAGES = "${PN}-dbg ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-static 
${PN}-libs \
-${PN}-mibs ${PN}-server ${PN}-client ${PN}-server-snmpd 
${PN}-server-snmptrapd"
+PACKAGES += "${PN}-libs ${PN}-mibs ${PN}-server ${PN}-client 
${PN}-server-snmpd ${PN}-server-snmptrapd"
```

This new 'PACKAGES' variable is wrong IMHO, because it contains
the 'net-snmp' package and other empty packages.


Please review (and apply if ok) the attached commit that fixes it.


Thanks,

--- Kosta Z.
From d5711e279d95307aa8bb2bbdd0bb311207287e62 Mon Sep 17 00:00:00 2001
From: Kosta Zertsekel <kzertse...@advaoptical.com>
Date: Sun, 18 Mar 2018 08:43:11 +0200
Subject: [PATCH] Fix PACKAGES for net-snmp to create only the correct net-snmp
 packages

As for now (master branch) 'PACKAGES' variable in net-snmp equals to:
```
$ bitbake -e net-snmp | grep "^PACKAGES="
PACKAGES="net-snmp-dbg net-snmp-staticdev net-snmp-dev net-snmp-doc \
  net-snmp-locale  net-snmp net-snmp-libs net-snmp-mibs \
  net-snmp-server net-snmp-client net-snmp-server-snmpd \
  net-snmp-server-snmptrapd"
```

This seems to be wrong as many built packages from
'packages-split' directory of net-snmp are empty:
```
$ du -a --max-depth=1 . | sort -n
4./net-snmp
4./net-snmp-client.shlibdeps
4./net-snmp-doc
4./net-snmp-libs.shlibdeps
4./net-snmp-locale
4./net-snmp-server
4./net-snmp-server-snmpd.shlibdeps
4./net-snmp-server-snmptrapd.shlibdeps
4./net-snmp-staticdev
48./net-snmp-server-snmptrapd
72./net-snmp-server-snmpd
1208./net-snmp-dev
1480./net-snmp-client
1812./net-snmp-mibs
2872./net-snmp-libs
15308./net-snmp-dbg
```

Well, the culprit commit is 5eec0615e548f58ecdfadfc45af5805eeb58f69c
where the below change has happened:
```
-PACKAGES = "${PN}-dbg ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-static ${PN}-libs \
-${PN}-mibs ${PN}-server ${PN}-client ${PN}-server-snmpd ${PN}-server-snmptrapd"
+PACKAGES += "${PN}-libs ${PN}-mibs ${PN}-server ${PN}-client ${PN}-server-snmpd ${PN}-server-snmptrapd"
```

This new 'PACKAGES' variable is wrong IMHO, because it contains
the 'net-snmp' package and other empty packages.

Signed-off-by: Kosta Zertsekel <kzertse...@advaoptical.com>
---
 meta-networking/recipes-protocols/net-snmp/net-snmp_5.7.3.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-networking/recipes-protocols/net-snmp/net-snmp_5.7.3.bb b/meta-networking/recipes-protocols/net-snmp/net-snmp_5.7.3.bb
index 3c05874..bb113a8 100644
--- a/meta-networking/recipes-protocols/net-snmp/net-snmp_5.7.3.bb
+++ b/meta-networking/recipes-protocols/net-snmp/net-snmp_5.7.3.bb
@@ -165,7 +165,7 @@ net_snmp_sysroot_preprocess () {
 fi
 }
 
-PACKAGES += "${PN}-libs ${PN}-mibs ${PN}-server ${PN}-client ${PN}-server-snmpd ${PN}-server-snmptrapd"
+PACKAGES = "${PN}-dbg ${PN}-dev ${PN}-libs ${PN}-mibs ${PN}-client ${PN}-server-snmpd ${PN}-server-snmptrapd"
 
 # perl module
 PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'perl', '${PN}-perl-modules', '', d)}"
-- 
2.7.4

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

[yocto] Building safplus 6.1 with Yocto 2.4 Rocko

2017-11-21 Thread Kosta Zertsekel 
Hi guys,


I'm trying to build safplus 6.1 with Yocto 2.4 Rocko branch.

But after running "bitbake safplus" (right after git clone is finished) it 
fails...


My `conf/bblayers.conf` file is as below:


```
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/mrv/My/MRV/yocto_all/rocko_all/poky/meta \
  /home/mrv/My/MRV/yocto_all/rocko_all/poky/meta-poky \
  /home/mrv/My/MRV/yocto_all/rocko_all/poky/meta-yocto-bsp \
  /home/mrv/My/MRV/yocto_all/rocko_all/poky/meta-openembedded/meta-python \
  /home/mrv/My/MRV/yocto_all/rocko_all/poky/meta-openembedded/meta-networking \
  /home/mrv/My/MRV/yocto_all/rocko_all/poky/meta-openembedded/meta-oe \
  /home/mrv/My/MRV/yocto_all/rocko_all/poky/meta-openclovis \
  /home/mrv/My/MRV/yocto_all/rocko_all/poky/meta-intel \
```


Then I do "bitbake safplus" and get the below error:


```
'...build/tmp/work/core2-32-poky-linux/safplus/6.1-r0/safplus-6.1/src/SAFplus/COPYING'
ERROR: safplus-6.1-r0 do_populate_lic: QA Issue: safplus:
LIC_FILES_CHKSUM points to an invalid file: 
.../build/tmp/work/core2-32-poky-linux/safplus/6.1-r0/safplus-6.1/src/SAFplus/COPYING
 [license-checksum]
```


But, then I check the content of 
"tmp/work/core2-32-poky-linux/safplus/6.1-r0/safplus-6.1" directory and ... it 
is **empty**!


Did anyone see that problem?

Do you have any clues?


Thanks,

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

Re: [yocto] Yocto for NFS/SDN networking product

2017-06-05 Thread Kosta Zertsekel 
Khem,


Fully agree that Yocto has is good, 'cause it supports cross-build, has a wide

industry support and actually it has **the version** (meaning, all the packages

are taken with specific git commit id unlike debian/ubuntu binaries).


But then, I'm confused in the other respect...


I'm looking at the OpenSwitch build system (part of Open Compute project

under Linux Foundation) and I see that is uses yocto as a subsystem. It's really

confusing because yocto is supposed to have "meta-XYZ" for OpenSwitch

support.


So, when choosing a build system for OpenSwitch-based products - do one

still has to use yocto or just go with the build system provided by OpenSwitch?


Thanks,

--- KostaZ


From: Khem Raj <raj.k...@gmail.com>
Sent: Sunday, January 31, 2016 5:56 PM
To: Kosta Zertsekel
Cc: yocto@yoctoproject.org; Ran Wainstein
Subject: Re: [yocto] Yocto for NFS/SDN networking product

Kosta

Yocto project is developed by many volunteers and people sponsored by 
corporations,
all development happens in opensource. The community supports the project. There
are also lot of commercial OS vendors which use Yocto project to build their 
products,
so you can always go to them if you are looking for commercial support.

For advantages, it can build a small footprint since it builds bottom up. So 
you can really get only needed
packages for your custom image. It will create a source based distribution for 
you where you have control
over every part of the OSS stack. You can really tailor your solution to your 
needs.

It builds in cross-build environment, supports many CPU architectures and 
machines

The community is very welcoming and helpful. You can easily contribute to the 
project
and fulfill your needs by doing so. The learning curve might be a bit steeper. 
But then
you do have trainings available offerred by professionals.

Thanks
-Khem
On Sun, Jan 31, 2016 at 4:22 AM, Kosta Zertsekel 
<kzertse...@mrv.com<mailto:kzertse...@mrv.com>> wrote:

Hi dear Yocto community,


I'm trying to evaluate Yocto as the candidate to create Linux distro

for NFS/SDN networking product. Through Google I get an impression

that there is a race between Yocto, CentOS (RedHat) and 6WIND

Linux distributions to get most of NFV/SDN Linux distro market.


Can you please help to find cons and pros of using Yocto for

NFV/SDN networking product?


I google over NFV/SDN part of www.etsi.org<http://www.etsi.org> but couldn't 
make up

my mind what specific distro got the traction.


I see that Yocto has NFV/SDN layers 
(reference<http://events.linuxfoundation.org/sites/events/files/slides/YP_and_OpenStack_LinuxCon2014.pdf>):

```
git clone 
git://git.yoctoproject.org/meta-cloud-services<http://git.yoctoproject.org/meta-cloud-services>
git clone 
git://git.openembedded.org/meta-openembedded<http://git.openembedded.org/meta-openembedded>
git clone --branch icehouse 
git://git.yoctoproject.org/meta-virtualization<http://git.yoctoproject.org/meta-virtualization>
git clone 
git://git.openembedded.org/openembedded-core<http://git.openembedded.org/openembedded-core>
 oe-core
```


Are these layers officially supported by Intel?

Does Intel provide the NFV/SDN support?


Thanks,

--- KostaZ

[E-Banner]<http://www.mrv.com/blog>


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to whom they are addressed and may contain 
confidential and/or privileged information. If you are not the intended 
recipient, immediately advise the sender, delete this message and any 
attachments and note that any distribution, or copying of this message, or any 
attachment, is prohibited.

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


[http://50.57.127.206/images/Banner.jpg]<https://goo.gl/0NNSWr>


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to whom they are addressed and may contain 
confidential and/or privileged information. If you are not the intended 
recipient, immediately advise the sender, delete this message and any 
attachments and note that any distribution, or copying of this message, or any 
attachment, is prohibited.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Which Toolchain is being used to build Yocto ?

2016-02-03 Thread Kosta Zertsekel 
Mark,


>> I notice there is a meta/recipes-devtools  -  I assume this pulls in from 
>> build/downloads

>> - so gcc-5.2.0.tar.bz2 for example. Does the tool-chain comprised of these 
>> recipes get

>> built by /usr/bin/gcc before being used to compile Yocto?


You can easily check it by moving temporary /usr/bin/gcc aside.

BTW, provide the result of this test to the mailing list - so all of us can be 
synced.


--- KostaZ

[E-Banner]


MRV Communications is a global supplier of packet and optical solutions that 
power the world's largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to whom they are addressed and may contain 
confidential and/or privileged information. If you are not the intended 
recipient, immediately advise the sender, delete this message and any 
attachments and note that any distribution, or copying of this message, or any 
attachment, is prohibited.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto for NFS/SDN networking product

2016-01-31 Thread Kosta Zertsekel 
Hi dear Yocto community,


I'm trying to evaluate Yocto as the candidate to create Linux distro

for NFS/SDN networking product. Through Google I get an impression

that there is a race between Yocto, CentOS (RedHat) and 6WIND

Linux distributions to get most of NFV/SDN Linux distro market.


Can you please help to find cons and pros of using Yocto for

NFV/SDN networking product?


I google over NFV/SDN part of www.etsi.org but couldn't 
make up

my mind what specific distro got the traction.


I see that Yocto has NFV/SDN layers 
(reference):

```
git clone git://git.yoctoproject.org/meta-cloud-services
git clone git://git.openembedded.org/meta-openembedded
git clone --branch icehouse git://git.yoctoproject.org/meta-virtualization
git clone git://git.openembedded.org/openembedded-core oe-core
```


Are these layers officially supported by Intel?

Does Intel provide the NFV/SDN support?


Thanks,

--- KostaZ

[E-Banner]


MRV Communications is a global supplier of packet and optical solutions that 
power the world's largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to whom they are addressed and may contain 
confidential and/or privileged information. If you are not the intended 
recipient, immediately advise the sender, delete this message and any 
attachments and note that any distribution, or copying of this message, or any 
attachment, is prohibited.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Image SDK Generation With QT5

2016-01-31 Thread Kosta Zertsekel 
Hi Charles,

>> I've created an image for the Raspberry Pi 2 which includes Qt5 and
>> the WiringPi library and it runs great on the device. However, when
>> I run the command 'bitbake myQtImage -c populate_sdk' I get the
>> Pi sysroot with everything in it but I don't get the x86-64 qmake
>> I need to cross compile on my desktop. When I run meta-toolchain-qt5
>> I get the x86-64 qmake I want but the wiringPi library isn't included
>> in the Pi sysroot.  What do I need to do to generate an SDK that
>> includes both the wiringPi library in the Pi sysroot and the x86-64 qmake?

Please provide your git link for people to clone and review.

Thanks,
--- KostaZ


From: yocto-boun...@yoctoproject.org  on behalf 
of Charles Werther 
Sent: Sunday, January 31, 2016 4:40 PM
To: yocto@yoctoproject.org
Subject: [yocto] Image SDK Generation With QT5

All,

I've created an image for the Raspberry Pi 2 which includes Qt5 and the 
WiringPi library and it runs great on the device. However, when I run the 
command 'bitbake myQtImage -c populate_sdk' I get the Pi sysroot with 
everything in it but I don't get the x86-64 qmake I need to cross compile on my 
desktop. When I run meta-toolchain-qt5 I get the x86-64 qmake I want but the 
wiringPi library isn't included in the Pi sysroot.  What do I need to do to 
generate an SDK that includes both the wiringPi library in the Pi sysroot and 
the x86-64 qmake?

Thanks,
Charles
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[E-Banner]


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.


The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to whom they are addressed and may contain 
confidential and/or privileged information. If you are not the intended 
recipient, immediately advise the sender, delete this message and any 
attachments and note that any distribution, or copying of this message, or any 
attachment, is prohibited.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto