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

[Huang, Jie (Jackie)]

> 
> 
> From: Kosta Zertsekel [mailto:kzertse...@advaoptical.com] 
> Sent: Monday, March 19, 2018 14:17
> To: Huang, Jie (Jackie); Khem Raj
> Cc: yocto@yoctoproject.org; Enache, Catalin; Zhou, Li
> Subject: Re: [yocto] Fix 'PACKAGES' in net-snmp recipe
> 
> > 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

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.

Thanks,
Jackie



> 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) 
> 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
> > >  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

Re: [yocto] How to Skip recipes ?

[Aravindhlal G . S . S]

Thanks Khem. Got it working now !

-Aravindh

-Original Message-
From: Khem Raj  
Sent: Saturday, March 17, 2018 8:48 PM
To: Aravindhlal G.S.S 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to Skip recipes ?

On Fri, Mar 16, 2018 at 10:22 PM, Aravindhlal G.S.S 
 wrote:
> Yocto Gurus,
>
>
>
> I am trying to Skip running a recipe for a particular machine 
> configuration and I am using the below statement in recipe to 
> accomplish it, however I am getting the below errors.
>
>
>
> python () {
>
> if :
>
> raise bb.parse.SkipRecipe("Message")
>
> }
>


this will skip it however you have to ensure that there are no other recipes 
needing it otherwise they will break, seems that is whats happening

>
>
> Errors:
>
> NOTE: Runtime target 'arris-kmod-headers-dev' is unbuildable, removing...
>
> Missing or unbuildable dependency chain was: 
> ['arris-kmod-headers-dev']
>
> ERROR: Nothing RPROVIDES 'arris-kmod-headers' (but 
> /export/asantharam/ws_xb6/syndication/cox/meta-rdk-oem-arris-intel-gw-
> xb6/meta-arrisxb6-arm/recipes-arris/arris-kmod/arris-kmod-headers.bb
> RDEPENDS on or otherwise requires it)
>
> ERROR: No eligible RPROVIDERs exist for 'arris-kmod-headers'
>
> NOTE: Runtime target 'arris-kmod-headers' is unbuildable, removing...
>
> Missing or unbuildable dependency chain was: ['arris-kmod-headers']
>
> ERROR: Nothing RPROVIDES 'mibleaf-docsis' (but 
> /export/asantharam/ws_xb6/syndication/cox/meta-rdk-oem-arris-intel-gw-
> xb6/meta-arrisxb6-arm/recipes-docsis/docsis/mibleaf-docsis.bb
> RDEPENDS on or otherwise requires it)
>
> ERROR: No eligible RPROVIDERs exist for 'mibleaf-docsis'
>
> NOTE: Runtime target 'mibleaf-docsis' is unbuildable, removing...
>
> Missing or unbuildable dependency chain was: ['mibleaf-docsis']
>
> ERROR: Nothing RPROVIDES 'mibleaf-docsis-dev' (but 
> /export/asantharam/ws_xb6/syndication/cox/meta-rdk-oem-arris-intel-gw-
> xb6/meta-arrisxb6-arm/recipes-docsis/docsis/mibleaf-docsis.bb
> RDEPENDS on or otherwise requires it)
>
> ERROR: No eligible RPROVIDERs exist for 'mibleaf-docsis-dev'
>
> NOTE: Runtime target 'mibleaf-docsis-dev' is unbuildable, removing...
>
> Missing or unbuildable dependency chain was: ['mibleaf-docsis-dev']
>
> ERROR: Nothing RPROVIDES 'arris-pcable-headers-dev' (but 
> /export/asantharam/ws_xb6/syndication/cox/meta-rdk-oem-arris-intel-gw-
> xb6/meta-arrisxb6-arm/recipes-bin/voice/arris-pcable-headers.bb
> RDEPENDS on or otherwise requires it)
>
> ERROR: No eligible RPROVIDERs exist for 'arris-pcable-headers-dev'
>
> NOTE: Runtime target 'arris-pcable-headers-dev' is unbuildable, removing...
>
> Missing or unbuildable dependency chain was: 
> ['arris-pcable-headers-dev']
>
> ERROR: Nothing RPROVIDES 'arris-pcable-headers' (but 
> /export/asantharam/ws_xb6/syndication/cox/meta-rdk-oem-arris-intel-gw-
> xb6/meta-arrisxb6-arm/recipes-bin/voice/arris-pcable-headers.bb
> RDEPENDS on or otherwise requires it)
>
> ERROR: No eligible RPROVIDERs exist for 'arris-pcable-headers'
>
> NOTE: Runtime target 'arris-pcable-headers' is unbuildable, removing...
>
> Missing or unbuildable dependency chain was: ['arris-pcable-headers']
>
> ERROR: Nothing RPROVIDES 'libarris-rf-ds-calibration-headers' (but 
> /export/asantharam/ws_xb6/syndication/cox/meta-rdk-oem-arris-intel-gw-
> xb6/meta-arrisxb6-arm/recipes-arris/libarris-rf-ds-calibration/libarri
> s-rf-ds-calibration-headers.bb
> RDEPENDS on or otherwise requires it)
>
> ERROR: No eligible RPROVIDERs exist for 'libarris-rf-ds-calibration-headers'
>
> NOTE: Runtime target 'libarris-rf-ds-calibration-headers' is 
> unbuildable, removing...
>
> Missing or unbuildable dependency chain was:
> ['libarris-rf-ds-calibration-headers']
>
> ERROR: Nothing RPROVIDES 'libarris-rf-ds-calibration-headers-dev' (but 
> /export/asantharam/ws_xb6/syndication/cox/meta-rdk-oem-arris-intel-gw-
> xb6/meta-arrisxb6-arm/recipes-arris/libarris-rf-ds-calibration/libarri
> s-rf-ds-calibration-headers.bb
> RDEPENDS on or otherwise requires it)
>
> ERROR: No eligible RPROVIDERs exist for 
> 'libarris-rf-ds-calibration-headers-dev'
>
> NOTE: Runtime target 'libarris-rf-ds-calibration-headers-dev' is 
> unbuildable, removing...
>
> Missing or unbuildable dependency chain was:
> ['libarris-rf-ds-calibration-headers-dev']
>
> ERROR: Nothing RPROVIDES 'libarris-extswt' (but 
> /export/asantharam/ws_xb6/syndication/cox/meta-rdk-oem-arris-intel-gw-
> xb6/meta-arrisxb6-arm/recipes-arris/libarris-extswt/libarris-extswt.bb
> RDEPENDS on or otherwise requires it)
>
> ERROR: No eligible RPROVIDERs exist for 'libarris-extswt'
>
> NOTE: Runtime target 'libarris-extswt' is unbuildable, removing...
>
> Missing or unbuildable dependency chain was: ['libarris-extswt']
>
> ERROR: Nothing RPROVIDES 'libarris-extswt-dev' (but 
> /export/asantharam/ws_xb6/syndication/cox/meta-rdk-oem-arris-intel-gw-
> xb6/meta-arrisxb6-arm/recipes-arris/libarris-extswt/libarris-extswt.bb
> RDEPENDS on or otherwise requires it)
>
> ERROR: No eligible RPROVIDERs e

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

[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

[yocto] Installing setup.py after cmake build in one recipe

[Patryk Łaś]

Hi,

Since few days I am dealing with problem in compiling my recipe in which I
am downloading git repositories patch them, compiling (via cmake) and
finally running setup.py. I have to do it in mentioned order because cmake
gives me *.so library which is required by setup.py instalator. Python
setup.py is located inside repository like: "${S}/python/setup.py" where
S=${WORKDIR}/git.

Recipe compiles fine (bitbake my_recipe) but it does not included in final
system image (added entry to add recipe into main image). What is more
there is not site-packages for build in tmp but setup.py seemd to be
invoked.

My recipe:

LICENSE = "CLOSED"
BB_STRICT_CHECKSUM = "0"
SECTION = "devel/python"
PV = "1.0"
DEPENDS = "boost udev swig-native python python-setuptools python-native
python-setuptools-native python-distutils-extra-native"

SRC_URI = " \
git://github.com/myrepo1;protocol=https;name=A \
git://github.com/myrepo2;protocol=https;name=B \
file://0001-patch1.patch \
"
SRCREV_A = "404ff3eeff0d79c15cbfdbc126c4bff2996baea6"
SRCREV_B = "5e883c2a3f5373dbd1ea34e6095f9433bea2b0b3"

S = "${WORKDIR}/git"


PARALLEL_MAKEINST = ""

DISTUTILS_INSTALL_ARGS +=
"--install-lib=${libdir}/${PYTHON_DIR}/site-packages"

inherit cmake

FILES_${PN} += "${libdir}/${PYTHON_DIR}/*"

do_compile_prepend() {
export STAGING_LIBDIR=${STAGING_LIBDIR}
export STAGING_INCDIR=${STAGING_INCDIR}
}

do_install() {
export STAGING_LIBDIR=${STAGING_LIBDIR}
export STAGING_INCDIR=${STAGING_INCDIR}
${STAGING_BINDIR_NATIVE}/python-native/python ${S}/python/setup.py
install
}

-- 

*Patryk Łaś*

Embedded Specialist

+ 48 503 165 819


*patryk@slabs.pl *

Dworska 1A/1U

30-314 Kraków

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

[yocto] Issue with gcc6

[sarayu]

Hi , 

 

I was trying to setup yocto on my debian VM and pulled the latest yocto fido
and tried to compile the core_image_sato. 

I am getting the below error in the base build.

 

/home/sarayu/code/yocto-sample/poky/build/tmp/work/x86_64-linux/elfutils-nat
ive/0.161-r0/elfutils-0.161/libebl/eblinitreg.c:50:26: error: nonnull
argument 'ebl' compared to NULL [-Werror=nonnull-compare]

|return ebl == NULL ? 0 : ebl->frame_nregs;

|   ^~

| cc1: all warnings being treated as errors

| Makefile:529: recipe for target 'eblinitreg.o' failed

| make[2]: *** [eblinitreg.o] Error 1

 

 

Can you please let me know if a patch or fix is already available for the
same. 

Thanks in advance for your help.

 

Thanks and Regards

Sarayu

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

Re: [yocto] How can I check "shared-library-to-package mapping"

[ikjn]

On Thu, Mar 15, 2018 at 11:37 AM, Khem Raj  wrote:

>
> On Wed, Mar 14, 2018 at 8:50 AM ikjn  wrote:
>
>> Hi.
>>
>> My recipe 'A' installs pre-built shared libraries, but I get file_rdeps
>> error on
>> 'B' recipe's package_qa task, which has runtime dependency on A's so
>> files.
>>
>
> Yes however it depends on SONAME being added to the shared objects when
> they are linked otherwise shlibs code is not able to auto detect the
> dependency
>

Thank you, now I got it!
I thought only file name is used for run time dependency matching between
packages.
SONAME matching is also executed in build time dependency check when
DEPENDS_xxx is given?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Issue with gcc6

[Burton, Ross]

Fido is almost three years old, isn't supported, and doesn't support gcc6
hosts.

Either:
1) move to a release which is supported, such a Rocko
2) use a supported host distro for Fido
3) fix the problems yourself.  In this case the warning is showing you a
line which would crash if executed.

Ross


On 16 March 2018 at 04:48,  wrote:

> Hi ,
>
>
>
> I was trying to setup yocto on my debian VM and pulled the latest yocto
> fido and tried to compile the core_image_sato.
>
> I am getting the below error in the base build.
>
>
>
> /home/sarayu/code/yocto-sample/poky/build/tmp/work/
> x86_64-linux/elfutils-native/0.161-r0/elfutils-0.161/libebl/eblinitreg.c:50:26:
> error: nonnull argument 'ebl' compared to NULL [-Werror=nonnull-compare]
>
> |return ebl == NULL ? 0 : ebl->frame_nregs;
>
> |   ^~
>
> | cc1: all warnings being treated as errors
>
> | Makefile:529: recipe for target 'eblinitreg.o' failed
>
> | make[2]: *** [eblinitreg.o] Error 1
>
>
>
>
>
> Can you please let me know if a patch or fix is already available for the
> same.
>
> Thanks in advance for your help.
>
>
>
> Thanks and Regards
>
> Sarayu
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing setup.py after cmake build in one recipe

[Burton, Ross]

On 14 March 2018 at 22:31, Patryk Łaś  wrote:

> Recipe compiles fine (bitbake my_recipe) but it does not included in final
> system image (added entry to add recipe into main image). What is more
> there is not site-packages for build in tmp but setup.py seemd to be
> invoked.
>

Simply building a recipe won't add it to an image.  Read the section on
customising images in the documentation.

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

[yocto] Yocto Project Status WW12’18

[Jordan, Robin L]

Current Dev Position: YP 2.5 M3 final close out.

Next Deadline: YP 2.5 M3 cut off was 2/19/18

*** FEATURE FREEZE for 2.5 has passed ***


SWAT lead is currently Ross.

SWAT team rotation: Armin -> Ross on March 23, 2018

SWAT team rotation: Ross -> Juro on March 30, 2018

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

  *   YP 2.4.2 was released: 
https://lists.yoctoproject.org/pipermail/yocto/2018-March/040282.html
  *   Meta-intel 8.1 was released: 
https://lists.yoctoproject.org/pipermail/meta-intel/2018-March/005261.html
  *   We’ve realised we were going to run into problems with distros adopting 
glibc 2.27, if not now, during the next release cycle. We therefore decided to 
head off this problem and try and fix the issues now. Unfortunately, due to 
locale changes in 2.27, it also breaks our eSDK in the current and all previous 
releases. We have fixes in master for this (thanks Ross!) and backports ready 
for rocko and pyro in the -next branches. Morty is proving harder to fix. We 
believe it is likely better to fix these issue even if the changes are invasive 
(they are at least mostly contained to the SDKs).

  *   The gcc 6.x changes were merged into rocko/pyro/morty which means point 
releases are now unblocked by that issue.
  *   The performance issue reported last week was tracked down to a kernel 
change which was reverted.
  *   The new buildbot autobuilder instance is working with basic 
functionality. We therefore plan to run the M3 release build on that 
infrastructure with a view to using it for the main 2.5 release. It was great 
to be able to report an issue upstream and be using their latest code! The 
autobuilder functionality is improved in at least two significant ways already 
which benefit the maintainers.
  *   We really do need to roll M3 now, our current plan is to test the final 
changes in mut and then run M3 with this. It is not a perfect set of features, 
many things simply haven’t made it in as the people doing review are 
overloaded. We’re too far past the freeze deadline to realistically make any 
further progress with this though.
  *   ELC was productive and there was a lot of good discussion between the 
people there about many different things. In particular we have some ideas for 
improving the project’s build infrastructure to allow more builds including 
other layers. More info will follow as we build the plans to make that happen.


Planned upcoming dot releases:

YP 2.3.4 (Pyro) will be built after 2.5 M3

YP 2.2.4 (Morty) will be built after 2.5 M3 once the glibc 2.27 issue is fixed

YP 2.4.3 (Rocko) is planned for post YP 2.5.


Key YP 2.5 Dates are:

YP 2.5 M3 is in feature freeze.  See status above.

YP 2.5 M3 was scheduled for release 3/2/18

YP 2.5 M4 cut off of 4/2/18

YP 2.5 M4 release of 4/27/18


Tracking Metrics:

WDD 2673 (last week 2673)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]





Robin Jordan

Yocto Project Program Manager

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

[yocto] Quick hack for compiling old and outdated YOCTO Jethro for Renesas iwg20m

[Zoran Stojsavljevic]

Hello,

I have to do some job on the Renesas iwg20m platform. From this site:
https://elinux.org/RZ-G/Boards/Yocto_2.0

I found some explanation how to do YOCTO build, which I a bit modified
(conf/local.conf).

It does download all the packages, but it fails here (in *RED*):

[vuser@localhost conf]$ bitbake core-image-minimal
WARNING: Host distribution "Fedora-27" has not been validated with this
version of the build system; you may possibly experience unexpected
failures. It is recommended that you use a tested distribution.
Loading cache: 100%
||
ETA:  00:00:00
Loaded 2160 entries from dependency cache.
WARNING: No recipes available for:

/home/vuser/projects2/iwg20m/build/../meta-renesas/meta-rzg1/recipes-qt/qt5/qtmultimedia_git.bbappend

/home/vuser/projects2/iwg20m/build/../meta-renesas/meta-rzg1/recipes-qt/qt5/qtbase_git.bbappend

/home/vuser/projects2/iwg20m/build/../meta-renesas/meta-rzg1/recipes-qt/qt5/qtwayland_git.bbappend
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.28.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Fedora-27"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "skrzg1m"
DISTRO= "poky"
DISTRO_VERSION= "2.0.1"
TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa15"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "tmp:3b223f75eec1738fbc913858e8e11c8305e3edcb"
meta-oe   = "tmp:dc5634968b270dde250690609f0015f881db81f2"
meta-yocto-bsp= "tmp:3b223f75eec1738fbc913858e8e11c8305e3edcb"
meta-rzg1 = "yocto_2.0:a6c3c79635bd5ee309fc3c62d36b1707086d9136"
meta-linaro-toolchain = "tmp:12993e6bc8658ee37d303d8d59007f8dd9ab2b30"

NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: oe_runmake failed
ERROR: Function failed: do_compile (log file is located at
/home/vuser/projects2/iwg20m/build/tmp/work/x86_64-linux/automake-native/1.15-r0/temp/log.do_compile.30440)
ERROR: Logfile of failure stored in:
/home/vuser/projects2/iwg20m/build/tmp/work/x86_64-linux/automake-native/1.15-r0/temp/log.do_compile.30440
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4






*| : && /usr/bin/mkdir -p doc && {
PATH='/home/vuser/projects2/iwg20m/build/tmp/work/x86_64-linux/automake-native/1.15-r0/build/t/wrap:'$PATH
&& export PATH; } && /usr/bin/perl
/home/vuser/projects2/iwg20m/build/tmp/work/x86_64-linux/automake-native/1.15-r0/automake-1.15/doc/help2man
--output=doc/automake-1.15.1 automake-1.15| help2man: can't get `--help'
info from automake-1.15| Try `--no-discard-stderr' if option outputs to
stderr| make: *** [Makefile:3687: doc/automake-1.15.1] Error 255| ERROR:
oe_runmake failed| ERROR: Function failed: do_compile (log file is located
at
/home/vuser/projects2/iwg20m/build/tmp/work/x86_64-linux/automake-native/1.15-r0/temp/log.do_compile.30440)ERROR:
Task 283
(virtual:native:/home/vuser/projects2/iwg20m/build/../poky/meta/recipes-devtools/automake/automake_1.15.bb
, do_compile) failed with exit code '1'*
NOTE: Tasks Summary: Attempted 699 tasks of which 697 didn't need to be
rerun and 1 failed.
No currently running tasks (527 of 2182)

Summary: 1 task failed:

virtual:native:/home/vuser/projects2/iwg20m/build/../poky/meta/recipes-devtools/automake/
automake_1.15.bb, do_compile
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
[vuser@localhost conf]$
___

My question is: does anybody know quick hack how to fix this error? Seems,
that it fails while generating doc files... How I can disable doc
generation for this, maybe some generic way for any package?

Thank you,
Zoran
___
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ARM CPU version question

[Steve Pavao]

What’s the recommended way to be able to propogate target-specific compile-time 
CPU tune information to affect the build of a source file in my own custom 
layer?

For example, if I’m building for an arm6-based target, I’d like to be able to 
have the __ARM_ARCH_6__ symbol be available when the Yocto system builds my 
custom layer.  The BSP for such a target obviously defines this symbol when 
building its files for such a target.  Is there an easy way to propagate this 
information to my own custom layer, to affect my own sources?  Maybe my recipe 
needs to include certain conf files from other layers such as meta or the BSP 
layer?

Currently, I notice that architecture-level symbols are available to my custom 
layer at compile time, such as __aarch64_ and __arm__, but not CPU tune 
information, such as __ARM_ARCH_6__.

- Steve Pavao
Korg R&D
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Yocto Project Status WW12’18

[akuster808]

On 03/19/2018 08:45 AM, Jordan, Robin L wrote:
>
> Current Dev Position: YP 2.5 M3 final close out.
>
> Next Deadline: YP 2.5 M3 cut off was 2/19/18
>
> *** FEATURE FREEZE for 2.5 has passed ***
>
>  
>
> SWAT lead is currently Ross.
>
> SWAT team rotation: Armin -> Ross on March 23, 2018
>
> SWAT team rotation: Ross -> Juro on March 30, 2018
>
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>  
>
> Key Status/Updates:
>
>   * YP 2.4.2 was released:
> https://lists.yoctoproject.org/pipermail/yocto/2018-March/040282.html
>   * Meta-intel 8.1 was released:
> https://lists.yoctoproject.org/pipermail/meta-intel/2018-March/005261.html
>
>   * We’ve realised we were going to run into problems with distros
> adopting glibc 2.27, if not now, during the next release cycle. We
> therefore decided to head off this problem and try and fix the
> issues now. Unfortunately, due to locale changes in 2.27, it also
> breaks our eSDK in the current and all previous releases. We have
> fixes in master for this (thanks Ross!) and backports ready for
> rocko and pyro in the -next branches. Morty is proving harder to
> fix. We believe it is likely better to fix these issue even if the
> changes are invasive (they are at least mostly contained to the SDKs).
>
>   * The gcc 6.x changes were merged into rocko/pyro/morty which means
> point releases are now unblocked by that issue.
>   * The performance issue reported last week was tracked down to a
> kernel change which was reverted.
>   * The new buildbot autobuilder instance is working with basic
> functionality. We therefore plan to run the M3 release build on
> that infrastructure with a view to using it for the main 2.5
> release. It was great to be able to report an issue upstream and
> be using their latest code! The autobuilder functionality is
> improved in at least two significant ways already which benefit
> the maintainers.
>   * We really do need to roll M3 now, our current plan is to test the
> final changes in mut and then run M3 with this. It is not a
> perfect set of features, many things simply haven’t made it in as
> the people doing review are overloaded. We’re too far past the
> freeze deadline to realistically make any further progress with
> this though.
>   * ELC was productive and there was a lot of good discussion between
> the people there about many different things. In particular we
> have some ideas for improving the project’s build infrastructure
> to allow more builds including other layers. More info will follow
> as we build the plans to make that happen.
>
>  
>
> Planned upcoming dot releases:
>
> YP 2.3.4 (Pyro) will be built after 2.5 M3
>
> YP 2.2.4 (Morty) will be built after 2.5 M3 once the glibc 2.27 issue
> is fixed
>
> YP 2.4.3 (Rocko) is planned for post YP 2.5.
>
>  
>
> Key YP 2.5 Dates are:
>
> YP 2.5 M3 is in feature freeze.  See status above.
>
Does this include package updates?

Do we have a place identified for new changes (2.6) while 2.5 stabilizes.

- armin


> YP 2.5 M3 was scheduled for release 3/2/18
>
> YP 2.5 M4 cut off of 4/2/18
>
> YP 2.5 M4 release of 4/27/18
>
>  
>
> Tracking Metrics:
>
>     WDD 2673 (last week 2673)
>
> (https://wiki.yoctoproject.org/charts/combo.html)
>
>  
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features
>
>  
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>  
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
>  
>
>  
>
> Robin Jordan
>
> Yocto Project Program Manager
>
>  
>
>
>

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

Re: [yocto] [OE-core] Yocto Project Status WW12’18

[Burton, Ross]

On 19 March 2018 at 19:22, akuster808  wrote:

> YP 2.5 M3 is in feature freeze.  See status above.
>
> Does this include package updates?
>

Yes, upgrades count as features.


> Do we have a place identified for new changes (2.6) while 2.5 stabilizes.
>

A formal place, no.  I tend to queue stuff in a branch if master isn't
taking all of my energy, otherwise the patches will sit on the list until
2.5 releases.  Typically master and sumo branches won't diverge until
post-release.

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

Re: [yocto] Quick hack for compiling old and outdated YOCTO Jethro for Renesas iwg20m

[Josef Holzmayr]

Howdy!
On Mon, Mar 19, 2018 at 05:38:47PM +0100, Zoran Stojsavljevic wrote:
> [vuser@localhost conf]$ bitbake core-image-minimal
> WARNING: Host distribution "Fedora-27" has not been validated with this
> version of the build system; you may possibly experience unexpected
> failures. It is recommended that you use a tested distribution.
> 
> My question is: does anybody know quick hack how to fix this error?

The first, simplest and most obvious would be to try and build with a
supported distro. Just fire up some generic debian/ubuntu docker and see
what happens.

Greetz
-- 
———
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

Re: [yocto] Quick hack for compiling old and outdated YOCTO Jethro for Renesas iwg20m

[Tom Rini]

On Mon, Mar 19, 2018 at 05:38:47PM +0100, Zoran Stojsavljevic wrote:
> Hello,
> 
> I have to do some job on the Renesas iwg20m platform. From this site:
> https://elinux.org/RZ-G/Boards/Yocto_2.0
> 
> I found some explanation how to do YOCTO build, which I a bit modified
> (conf/local.conf).
> 
> It does download all the packages, but it fails here (in *RED*):
> 
> [vuser@localhost conf]$ bitbake core-image-minimal
> WARNING: Host distribution "Fedora-27" has not been validated with this
> version of the build system; you may possibly experience unexpected
> failures. It is recommended that you use a tested distribution.

This is your biggest warning and source of problems.  If you have to
work with an old version of Yocto, you need to setup a
VM/chroot/whatever of a supported at that time host distribution.

-- 
Tom


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ARM CPU version question

[Andre McCurdy]

On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao  wrote:
> What’s the recommended way to be able to propogate target-specific 
> compile-time CPU tune information to affect the build of a source file in my 
> own custom layer?
>
> For example, if I’m building for an arm6-based target, I’d like to be able to 
> have the __ARM_ARCH_6__ symbol be available when the Yocto system builds my 
> custom layer.  The BSP for such a target obviously defines this symbol when 
> building its files for such a target.  Is there an easy way to propagate this 
> information to my own custom layer, to affect my own sources?  Maybe my 
> recipe needs to include certain conf files from other layers such as meta or 
> the BSP layer?

This kind of macro is typically defined internally by gcc, depending
on the -mcpu etc options passed on the gcc command line, ie options
which are included in the ${CC} definition setup by OE.

Therefore all you normally need to do is ensure that the Makefiles etc
for the components in your custom layer all correctly respect OE's
definition of ${CC}.

A typical bug in handcrafted Makefiles is to force CC to (e.g. CC =
"$(CROSS_COMPILE)gcc") and lose the original value passed via the
environment.

> Currently, I notice that architecture-level symbols are available to my 
> custom layer at compile time, such as __aarch64_ and __arm__, but not CPU 
> tune information, such as __ARM_ARCH_6__.

The exact set of macros defined by gcc will vary depending on exactly
which ARMv6 CPU you are targeting (and to some extent, which version
of gcc you are using). If you have code which needs to be enabled for
any ARMv6 target then you may have to test multiple macros. For
example see the way in which openssl defines __ARM_ARCH__

  https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h

> - Steve Pavao
> Korg R&D
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-security][PATCH] xmlsec1: fix a typo in examples/verify3.c

[akuster808]

On 03/04/2018 06:22 PM, jackie.hu...@windriver.com wrote:
> From: Jackie Huang 
>
> Signed-off-by: Jackie Huang 

merged.

thanks
- armin
> ---
>  .../xmlsec1-fix-a-typo-in-examples-verify3.c.patch | 25 
> ++
>  recipes-security/xmlsec1/xmlsec1_1.2.25.bb |  1 +
>  2 files changed, 26 insertions(+)
>  create mode 100644 
> recipes-security/xmlsec1/xmlsec1/xmlsec1-fix-a-typo-in-examples-verify3.c.patch
>
> diff --git 
> a/recipes-security/xmlsec1/xmlsec1/xmlsec1-fix-a-typo-in-examples-verify3.c.patch
>  
> b/recipes-security/xmlsec1/xmlsec1/xmlsec1-fix-a-typo-in-examples-verify3.c.patch
> new file mode 100644
> index 000..0fe3fd7
> --- /dev/null
> +++ 
> b/recipes-security/xmlsec1/xmlsec1/xmlsec1-fix-a-typo-in-examples-verify3.c.patch
> @@ -0,0 +1,25 @@
> +From bf1c7b17cc80a2f4dfd43f112f944f68fa5fbcd6 Mon Sep 17 00:00:00 2001
> +From: Jackie Huang 
> +Date: Fri, 2 Mar 2018 01:10:58 -0800
> +Subject: [PATCH] xmlsec1: fix a typo in examples/verify3.c
> +
> +Upstream-Status: Submitted [https://github.com/lsh123/xmlsec/pull/153]
> +
> +Signed-off-by: Jackie Huang 
> +---
> + examples/verify3.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/examples/verify3.c b/examples/verify3.c
> +index 2d26ae7..68f52ab 100644
> +--- a/examples/verify3.c
>  b/examples/verify3.c
> +@@ -1,4 +1,4 @@
> +-4/** 
> ++/**
> +  * XML Security Library example: Verifying a file signed with X509 
> certificate
> +  *
> +  * Verifies a file signed with X509 certificate. 
> +-- 
> +2.13.0
> +
> diff --git a/recipes-security/xmlsec1/xmlsec1_1.2.25.bb 
> b/recipes-security/xmlsec1/xmlsec1_1.2.25.bb
> index d351dd2..dbb6f7d 100644
> --- a/recipes-security/xmlsec1/xmlsec1_1.2.25.bb
> +++ b/recipes-security/xmlsec1/xmlsec1_1.2.25.bb
> @@ -17,6 +17,7 @@ SRC_URI = 
> "http://www.aleksey.com/xmlsec/download/${BP}.tar.gz \
>  file://change-finding-path-of-nss.patch \
>  file://makefile-ptest.patch \
>  file://xmlsec1-examples-allow-build-in-separate-dir.patch \
> +file://xmlsec1-fix-a-typo-in-examples-verify3.c.patch \
>  file://run-ptest \
>  "
>  

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

Re: [yocto] ARM CPU version question

[Steve Pavao]

Hi Andre,

> On Mar 19, 2018, at 5:32 PM, Andre McCurdy  wrote:
> 
> On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao  wrote:
>> What’s the recommended way to be able to propogate target-specific 
>> compile-time CPU tune information to affect the build of a source file in my 
>> own custom layer?
>> 
>> For example, if I’m building for an arm6-based target, I’d like to be able 
>> to have the __ARM_ARCH_6__ symbol be available when the Yocto system builds 
>> my custom layer.  The BSP for such a target obviously defines this symbol 
>> when building its files for such a target.  Is there an easy way to 
>> propagate this information to my own custom layer, to affect my own sources? 
>>  Maybe my recipe needs to include certain conf files from other layers such 
>> as meta or the BSP layer?
> 
> This kind of macro is typically defined internally by gcc, depending
> on the -mcpu etc options passed on the gcc command line, ie options
> which are included in the ${CC} definition setup by OE.
> 
> Therefore all you normally need to do is ensure that the Makefiles etc
> for the components in your custom layer all correctly respect OE's
> definition of ${CC}.
> 
> A typical bug in handcrafted Makefiles is to force CC to (e.g. CC =
> "$(CROSS_COMPILE)gcc") and lose the original value passed via the
> environment.
> 
>> Currently, I notice that architecture-level symbols are available to my 
>> custom layer at compile time, such as __aarch64_ and __arm__, but not CPU 
>> tune information, such as __ARM_ARCH_6__.
> 
> The exact set of macros defined by gcc will vary depending on exactly
> which ARMv6 CPU you are targeting (and to some extent, which version
> of gcc you are using). If you have code which needs to be enabled for
> any ARMv6 target then you may have to test multiple macros. For
> example see the way in which openssl defines __ARM_ARCH__
> 
>  https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h 
> 

Thank you very much for your insight, Andre !

I think I may have discovered a specific situation which is causing the problem 
to occur for me.  It seems it occurs because I am trying to build a kernel 
module under the recipes-kernel directory in my custom layer.   A colleague 
pointed out to me that meta/classes/module.bbclass explicitly unsets CFLAGS and 
a bunch of other macros in this situation.

Maybe I need to put in some custom shell syntax in my recipe, to export 
__ARM_ARCH_6__ or to directly define the compiler macro when needed, based on 
the value of the TARGET variable.  I wonder if there is a better recommended 
solution than this, though.

BTW, my kernel module contains conditionally-compiled code for initializing the 
ARM PMU correctly for each CPU case.

- Steve



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

Re: [yocto] ARM CPU version question

[Khem Raj]

On 3/19/18 4:35 PM, Steve Pavao wrote:

Hi Andre,

On Mar 19, 2018, at 5:32 PM, Andre McCurdy > wrote:


On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao > wrote:
What’s the recommended way to be able to propogate target-specific 
compile-time CPU tune information to affect the build of a source 
file in my own custom layer?


For example, if I’m building for an arm6-based target, I’d like to be 
able to have the __ARM_ARCH_6__ symbol be available when the Yocto 
system builds my custom layer.  The BSP for such a target obviously 
defines this symbol when building its files for such a target.  Is 
there an easy way to propagate this information to my own custom 
layer, to affect my own sources?  Maybe my recipe needs to include 
certain conf files from other layers such as meta or the BSP layer?


This kind of macro is typically defined internally by gcc, depending
on the -mcpu etc options passed on the gcc command line, ie options
which are included in the ${CC} definition setup by OE.

Therefore all you normally need to do is ensure that the Makefiles etc
for the components in your custom layer all correctly respect OE's
definition of ${CC}.

A typical bug in handcrafted Makefiles is to force CC to (e.g. CC =
"$(CROSS_COMPILE)gcc") and lose the original value passed via the
environment.

Currently, I notice that architecture-level symbols are available to 
my custom layer at compile time, such as __aarch64_ and __arm__, but 
not CPU tune information, such as __ARM_ARCH_6__.


The exact set of macros defined by gcc will vary depending on exactly
which ARMv6 CPU you are targeting (and to some extent, which version
of gcc you are using). If you have code which needs to be enabled for
any ARMv6 target then you may have to test multiple macros. For
example see the way in which openssl defines __ARM_ARCH__

https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h


Thank you very much for your insight, Andre !

I think I may have discovered a specific situation which is causing the 
problem to occur for me.  It seems it occurs because I am trying to 
build a kernel module under the recipes-kernel directory in my custom 
layer.   A colleague pointed out to me 
that meta/classes/module.bbclass explicitly unsets CFLAGS and a bunch of 
other macros in this situation.




it wasn't clear if you were compiling external kmods. Now that sets it 
straight.


Maybe I need to put in some custom shell syntax in my recipe, to export 
__ARM_ARCH_6__ or to directly define the compiler macro when needed, 
based on the value of the TARGET variable.  I wonder if there is a 
better recommended solution than this, though.


kernel modules are built using kernel flags for best results, thats why 
you see that we do not enforce general cflags since they may be 
enforcing userspace ABI options into kernel, which is not right. Further 
more kernel build system constructs its own compiler commandline from 
kbuild.


You could add something like CONFIG_CPU_32v6K=y or CONFIG_CPU_32v6=y
to your kernel .config and that should provide you with right flags 
during your kernel module compilation step.


BTW, my kernel module contains conditionally-compiled code for 
initializing the ARM PMU correctly for each CPU case.


- Steve





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

Re: [yocto] ARM CPU version question

[Andre McCurdy]

On Mon, Mar 19, 2018 at 4:35 PM, Steve Pavao  wrote:
>
> I think I may have discovered a specific situation which is causing the
> problem to occur for me.  It seems it occurs because I am trying to build a
> kernel module under the recipes-kernel directory in my custom layer.   A
> colleague pointed out to me that meta/classes/module.bbclass explicitly
> unsets CFLAGS and a bunch of other macros in this situation.

OK, but note that the kernel (and kernel modules) are quite different
to user space in the way that CFLAGS and -mcpu etc are setup. For code
which runs in user space, these options are set by the OE build
environment, based on the machine config. For code which runs in
kernel space, these options come from the kernel build system, based
on the kernel config.

ie it's quite correct for module.bbclass to unset CFLAGS etc - it
prevents OE's flags for user space contaminating or conflicting with
the flags set by the kernel build system.

> Maybe I need to put in some custom shell syntax in my recipe, to export
> __ARM_ARCH_6__ or to directly define the compiler macro when needed, based
> on the value of the TARGET variable.  I wonder if there is a better
> recommended solution than this, though.

__ARM_ARCH_6__ is one of the macros normally set internally by gcc, so
you shouldn't be trying to set it manually.

Instead, you should probably either:

1) Update your code to test for defined(__ARM_ARCH_6__) ||
defined(__ARM_ARCH_6K__), since according to:

  https://github.com/torvalds/linux/blob/master/arch/arm/Makefile#L65

the kernel will either pass -march=armv6 or -march=armv6k for ARMv6
targets (depending on whether or not your kernel config enables
CONFIG_CPU_32v6K).

2) Update your code to test the generic ARMv6 macro set by the kernel
build system, ie (__LINUX_ARM_ARCH__ == 6), which should catch all
ARMv6 targets.


> BTW, my kernel module contains conditionally-compiled code for initializing
> the ARM PMU correctly for each CPU case.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-raspberrypi systemd rpi0-w bluetooth startup

[Dengke Du]

For rpi0-w bluetooth, before the commit:

https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-70e4910388c3702c52118d7acf7556e7

the brcm43438.service always failed, because it depends on 
/dev/ttyAMA0,after that commit, the 'udev-rules-rpi' added to the 
RDEPENDS for rpi0-w,we


can check it here:

https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-3b2568c620828b0ba653c1070041318aR52

for service brcm43438, but I still use the /dev/ttyAMA0 in it, not 
/dev/serial1(when I use /dev/serial1, the service failed), the service 
can start everytime correctly.



On 2018年03月19日 02:10, r10kindsofpeople wrote:
Update:  I suspect this is not the proper way to do this, but in case 
it provides useful information toward a better solution...

1) systemctl disable brcm43438.service
2) modified 99-com.rules to include TAG+="systemd" and 
ENV{SYSTEMD_WANTS}="device-brcm43438.service"
3) cp /lib/systemd/system/brcm43438.service 
/etc/systemd/system/device-brcm43438.service

4) modified device-brcm43438.service to be as follows:
[Unit]
Description=Broadcom BCM43438 bluetooth HCI

[Service]
Type=simple
ExecStart=/usr/bin/hciattach -n /dev/serial1 bcm43xx 921600 noflow -
Restart=on-failure

note removal of Before, After, ConditionPath, Install sections and 
addition of Restart=on-failure.  This last was to cope with an 
intermittent timeout in hciattach.  Suppose I should have tried 
increasing the timeout first.


This seems to have gotten me to the point of it starting up at least 
10 times successfully.  Bottom line, in my opinion, is that 
brcm43438.service is somehow running  before the udev script can 
create the symbolic link for /dev/serial1 -> /dev/ttyAMA0 despite the  
"After=dev-serial1.device" clause.


John


On Sat, Mar 17, 2018 at 12:32 PM r10kindsofpeople 
mailto:r10kindsofpeo...@gmail.com>> wrote:


Background:  I'm trying to bring up the pi zero w's bluetooth
using systemd.  Started with rocko and then moved to 'master' of
meta-raspberry pi, sync'd about a week ago after noticing that
there were some recent updates in this area.

There was an initial problem with /dev/serial1 not showing up...I
found udev-rules-rpi.bb , added it to my
layer, and when it still didn't show up in my rootfs, I punted and
installed it in /etc/udev/rules.d by hand and now /dev/serial1
shows up.  Given time, I can probably fix the recipe on my own, so
moving on.

But brcm43438.service still fails on boot.  Despite having
"After=dev-serial1.device" in the service Unit section, it fails with:

Mar 17 16:21:13 raspberrypi0-wifi systemd[1]: Started Broadcom
BCM43438 bluetooth HCI.
Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't open
serial port: No such file or directory
Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't initialize
device: No such file or directory
Mar 17 16:21:14 raspberrypi0-wifi systemd[1]:
[[0;1;39mbrcm43438.service: Main process exited, code=exited,
status=1/FAILURE[[0m
Mar 17 16:21:14 raspberrypi0-wifi systemd[1]:
[[0;1;39mbrcm43438.service: Unit entered failed state.[[0m
Mar 17 16:21:14 raspberrypi0-wifi systemd[1]:
[[0;1;39mbrcm43438.service: Failed with result 'exit-code'.[[0m

If, after booting and ssh'ing into pi, I restart the service, it
starts successfully.

Any hints about what I might change to get the brcm43438.service
to start correctly the first time (every time)?

John





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

Re: [yocto] meta-raspberrypi systemd rpi0-w bluetooth startup

[Dengke Du]

Raspberry pi have two built-in UARTs, PL011 and mini UART

by default: /dev/ttyS0 refers to the mini UART, /dev/ttyAMA0 refers to 
the PL011


https://www.raspberrypi.org/documentation/configuration/uart.md

So I think the brcm43438 service should use the /dev/ttyAMA0.


On 2018年03月20日 10:41, Dengke Du wrote:


For rpi0-w bluetooth, before the commit:

https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-70e4910388c3702c52118d7acf7556e7

the brcm43438.service always failed, because it depends on 
/dev/ttyAMA0,after that commit, the 'udev-rules-rpi' added to the 
RDEPENDS for rpi0-w,we


can check it here:

https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-3b2568c620828b0ba653c1070041318aR52

for service brcm43438, but I still use the /dev/ttyAMA0 in it, not 
/dev/serial1(when I use /dev/serial1, the service failed), the service 
can start everytime correctly.



On 2018年03月19日 02:10, r10kindsofpeople wrote:
Update:  I suspect this is not the proper way to do this, but in case 
it provides useful information toward a better solution...

1) systemctl disable brcm43438.service
2) modified 99-com.rules to include TAG+="systemd" and 
ENV{SYSTEMD_WANTS}="device-brcm43438.service"
3) cp /lib/systemd/system/brcm43438.service 
/etc/systemd/system/device-brcm43438.service

4) modified device-brcm43438.service to be as follows:
[Unit]
Description=Broadcom BCM43438 bluetooth HCI

[Service]
Type=simple
ExecStart=/usr/bin/hciattach -n /dev/serial1 bcm43xx 921600 noflow -
Restart=on-failure

note removal of Before, After, ConditionPath, Install sections and 
addition of Restart=on-failure.  This last was to cope with an 
intermittent timeout in hciattach.  Suppose I should have tried 
increasing the timeout first.


This seems to have gotten me to the point of it starting up at least 
10 times successfully.  Bottom line, in my opinion, is that 
brcm43438.service is somehow running  before the udev script can 
create the symbolic link for /dev/serial1 -> /dev/ttyAMA0 despite the 
"After=dev-serial1.device" clause.


John


On Sat, Mar 17, 2018 at 12:32 PM r10kindsofpeople 
mailto:r10kindsofpeo...@gmail.com>> wrote:


Background:  I'm trying to bring up the pi zero w's bluetooth
using systemd.  Started with rocko and then moved to 'master' of
meta-raspberry pi, sync'd about a week ago after noticing that
there were some recent updates in this area.

There was an initial problem with /dev/serial1 not showing up...I
found udev-rules-rpi.bb , added it to
my layer, and when it still didn't show up in my rootfs, I punted
and installed it in /etc/udev/rules.d by hand and now
/dev/serial1 shows up.  Given time, I can probably fix the recipe
on my own, so moving on.

But brcm43438.service still fails on boot.  Despite having
"After=dev-serial1.device" in the service Unit section, it fails
with:

Mar 17 16:21:13 raspberrypi0-wifi systemd[1]: Started Broadcom
BCM43438 bluetooth HCI.
Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't open
serial port: No such file or directory
Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't
initialize device: No such file or directory
Mar 17 16:21:14 raspberrypi0-wifi systemd[1]:
[[0;1;39mbrcm43438.service: Main process exited, code=exited,
status=1/FAILURE[[0m
Mar 17 16:21:14 raspberrypi0-wifi systemd[1]:
[[0;1;39mbrcm43438.service: Unit entered failed state.[[0m
Mar 17 16:21:14 raspberrypi0-wifi systemd[1]:
[[0;1;39mbrcm43438.service: Failed with result 'exit-code'.[[0m

If, after booting and ssh'ing into pi, I restart the service, it
starts successfully.

Any hints about what I might change to get the brcm43438.service
to start correctly the first time (every time)?

John









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

[yocto] [meta-security][rocko][PATCH] clamav: Add missing clamav.service file to SRC_URI

[Jagadeesh Krishnanjanappa]

This solves the below error when systemd is used as init manager,
-- snip --
ERROR: clamav-0.99.2-r0 do_package: SYSTEMD_SERVICE_clamav value clamav.service 
does not exist
ERROR: clamav-0.99.2-r0 do_package: Function failed: systemd_populate_packages
-- snip --

Other issues:
1. Ship /lib/systemd/system/clamav-freshclam.service into ${PN}-freshclam
   package, to solve below warning:
-- snip --
[10240] WARNING: QA Issue: clamav: Files/directories were installed but not 
shipped in any package:
  /lib/systemd/system/clamav-freshclam.service
-- snip --

2. Solve rpm conflict error in do_populate_sdk, when clamav and mlib-clamav
   are specified using IMAGE_INSTALL.
-- snip --
do_populate_sdk fails with below error:
  file /usr/bin/clamav-config conflicts between attempted installs of 
lib32-clamav-dev-0.99.2-r0.i586 and clamav-dev-0.99.2-r0.corei7_64
-- snip --

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 recipes-security/clamav/clamav_0.99.2.bb | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/recipes-security/clamav/clamav_0.99.2.bb 
b/recipes-security/clamav/clamav_0.99.2.bb
index 5dfda8f..d7aa6d0 100644
--- a/recipes-security/clamav/clamav_0.99.2.bb
+++ b/recipes-security/clamav/clamav_0.99.2.bb
@@ -14,6 +14,7 @@ SRC_URI = 
"git://github.com/vrtadmin/clamav-devel;branch=${PV} \
 file://clamd.conf \
 file://freshclam.conf \
 file://volatiles.03_clamav \
+file://${BPN}.service \
 "
 
 SRC_URI[md5sum] = "61b51a04619aeafd965892a53f86d192"
@@ -26,7 +27,7 @@ SO_VER = "7.1.1"
 
 EXTRANATIVEPATH += "chrpath-native"
 
-inherit autotools-brokensep pkgconfig useradd systemd 
+inherit autotools-brokensep pkgconfig useradd systemd multilib-alternatives
 
 UID = "clamav"
 GID = "clamav"
@@ -90,8 +91,13 @@ do_install_append() {
 install -m 0644 ${WORKDIR}/volatiles.03_clamav  
${D}${sysconfdir}/default/volatiles/volatiles.03_clamav
 sed -i -e 's#${STAGING_DIR_HOST}##g' ${D}${libdir}/pkgconfig/libclamav.pc
 rm ${D}/${libdir}/libclamav.so
+if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};then
+   install -D -m 0644 ${WORKDIR}/clamav.service 
${D}${systemd_unitdir}/system/clamav.service
+fi
 }
 
+MULTILIB_ALTERNATIVES_${PN}-dev = "${bindir}/clamav-config"
+
 pkg_postinst_${PN} () {
 if [ -z "$D" ] && [ -e /etc/init.d/populate-volatile.sh ] ; then
 ${sysconfdir}/init.d/populate-volatile.sh update
@@ -126,7 +132,8 @@ FILES_${PN}-freshclam = "${bindir}/freshclam \
 ${sysconfdir}/clamav ${sysconfdir}/default/volatiles \
 ${localstatedir}/lib/clamav \
 ${docdir}/${PN}-freshclam ${mandir}/man1/freshclam.* \
-${mandir}/man5/freshclam.conf.*"
+${mandir}/man5/freshclam.conf.* \
+${systemd_unitdir}/system/clamav-freshclam.service"
 
 FILES_${PN}-dev = " ${bindir}/clamav-config ${libdir}/*.la \
 ${libdir}/pkgconfig/*.pc \
-- 
2.7.4

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