[yocto] [meta-raspberrypi][PATCH] rpi-base: fix make_dtb_boot_files() for raspberrypi3-64

[Andrea Galbusera]

Building the stock wic image for raspberrypi3-64 failed to find dtbs listed in
IMAGE_BOOT_FILES. This patch updates the make_dtb_boot_files() function to
account for dtbs listed in KERNEL_DEVICETREE that do include a path prefix:
this is the case for things like broadcom/bcm2710-rpi-3-b.dtb (the dts dir
layout in the kernel sources is different for arm64). Use the same approach
already used for overlays/ dir. While at it also fix a typo in dtb overlay
code path comments.

Signed-off-by: Andrea Galbusera 
---
 conf/machine/include/rpi-base.inc | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/conf/machine/include/rpi-base.inc 
b/conf/machine/include/rpi-base.inc
index 517d5ba..4a0ea2a 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -61,16 +61,17 @@ def make_dtb_boot_files(d):
 
 def transform(dtb):
 if dtb.endswith('dtb'):
-# eg: bcm2708-rpi-b.dtb has:
+# eg: whatever/bcm2708-rpi-b.dtb has:
 # DEPLOYDIR file: ${KERNEL_IMAGETYPE}-bcm2708-rpi-b.dtb
 # destination: bcm2708-rpi-b.dtb
-src = '{}-{}'.format(imgtyp, dtb)
-dst = dtb
+base = os.path.basename(dtb)
+src = '{}-{}'.format(imgtyp, base)
+dst = base
 return '{};{}'.format(src, dst)
 elif dtb.endswith('dtbo'):
 # overlay dtb:
 # eg: overlays/hifiberry-amp.dtbo has:
-# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbp
+# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbo
 # destination: overlays/hifiberry-amp.dtbo
 base = os.path.basename(dtb)
 src = '{}-{}'.format(imgtyp, base)
-- 
2.7.4

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

Re: [yocto] [OE-core] Yocto cups serial port support

[Weng Josn]

Hello,

Thank you.

Best Regards.

2017-04-19 10:18 GMT+01:00 John, Maxin :
> Hi,
>
>
>
> Generally, cups serial backend is supported by “cups-filter” package. You
> can find that package in the “meta-printing” layer:
>
> https://github.com/rossburton/meta-printing
>
>
>
> Hope this helps,
>
> Maxin
>
>
>
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Weng
> Josn
> Sent: Tuesday, April 18, 2017 3:25 PM
> To: yocto@yoctoproject.org; openembedded-de...@lists.openembedded.org;
> Patches and discussions about the oe-core layer
> 
> Subject: [OE-core] Yocto cups serial port support
>
>
>
> Hello,
>
>
>
>
>
> I checked /usr/lib/cups/backend not inclued "serial" backend.
>
> How can enable cups serial port ?
>
>
>
>
>
>
>
> Thanks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Release Candidate Build for yocto-2.3.rc2 now available.

[Poky Build User]

A release candidate build for yocto-2.3.rc2 is now available at:


http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3.rc2


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : c7e6889290901f4878f4bfc2180743d0870e55ba 
meta-qt4 : e120a2193be3982d55741fb9e51472db6ab9a5cd 
meta-mingw : 4bdb99650a053f254ccd158a6d0c25c80e79f6ee 
meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
meta-gplv2 : de001bd6bfcec943d274b649c62be6848cc9c3e6 
poky : 7a0e795373653886452a7a2992ced10080711c26 

\nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: 
git://git.yoctoproject.org/yocto-autobuilder\nEmail: joshua.g.l...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-gplv2] gnutls: add older gnutls compatible with nettle

[Burton, Ross]

On 20 April 2017 at 19:24, Andre McCurdy  wrote:

> OK, that makes sense. I have my own gnutls_3.3.27.bb recipe and wasn't
> seeing the problem because I use a local gnutls.inc which still has
> that option.
>

Another example of why .inc files have to be trivial or very carefully
maintained...

Yes, restoring the option seems like the best fix.

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

Re: [yocto] Buildbot / Autobuilder / custom?

[Alain Achkar]

Kindly requesting help again, please.
I understand that Variscite might not be following the "Yocto way" 100% but
surely we can run custom commands using Autobuilder?

Please see detailed description in my last post.
Thanks!

On Mon, Apr 3, 2017 at 9:43 PM, Alain Achkar 
wrote:

> Hi Chris!
>
> I had to put this task on hold and I am re-visiting it now. I followed the
> instructions here:  http://git.yoctoproject.org/cgit.cgi/yocto-
> autobuilder/tree/README-QUICKSTART and managed to force one of the builds
> that comes with Yocto. I got errors but I'm not interested in the
> Yocto-provided nightly builds anyway. (The errors are related to
> buildhistory - it seems that some builds set Buildhistory=True but I
> haven't set up a git repo for build history)
>
> Now, I am still confused how to build the Variscite image for the i.MX6UL.
> We are still at Jethro but don't mind upgrading to Krogoth.
>
> I would appreciate some general guidelines on how to take the instructions
> in here:
> http://variwiki.com/index.php?title=DART-6UL_Yocto_Jethro_R1_build
> and transform them to the config format that Autobuilder understands.
>
> Mainly, I understand that I have to:
>
> 1) checkout the source code
>
> $ mkdir ~/var-mx6ul-mx7-yocto-jethro
> $ cd ~/var-mx6ul-mx7-yocto-jethro
> $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b 
> imx-4.1.15-1.0.0_ga
> $ repo sync
>
> $ cd ~/var-mx6ul-mx7-yocto-jethro/sources
> $ git clone https://github.com/varigit/meta-variscite-mx6ul-mx7.git -b 
> imx_4.1.15_ga-var01
>
>
> 2) copy and patch
>
> $ cp meta-variscite-mx6ul-mx7/scripts/var-setup-release.sh ../
> $ patch -p1 < 
> meta-variscite-mx6ul-mx7/patch/Fix-FSL-multi-patch-append-bugs.patch
>
>
> 3) setup a download directory
>
> $ sudo mkdir /opt/yocto_downloads
> $ sudo chmod 777 /opt/yocto_downloads/
> $ sed -i 's/DL_DIR ?= "${BSPDIR}\/downloads/DL_DIR = 
> "\/opt\/yocto_downloads/g' conf/local.conf
>
>
> 4) setup the environment
>
> $ cd ~/var-mx6ul-mx7-yocto-jethro
> $ MACHINE=imx6ul-var-dart DISTRO=fsl-imx-x11 source var-setup-release.sh -b 
> build_x11
>
>
> 5) build
>
> $ bitbake fsl-image-gui
>
>
> I looked at some nightly-*.conf files, for example nightly-x86-64.conf to
> try to guess what to do.
>
> I know I have to create a file like nightly-var-mx6ul.conf but given that
> Variscite is not using the 'repo' command that Freescale is using (they do
> a git clone) and given step (2) of copying their own setup script and
> patching the whole freescale meta- layers, I am not sure about what to put
> instead of the line:
>
> {'CheckOutLayers': {}},
>
>
> I also can't figure out how the info in Variscite's build-x11/local.conf
> can be translated to the Autobuilder format, i.e. where to specify all
> these config parameters.
>
> Any help would be greatly appreciated.
>
>
> On Mon, Nov 14, 2016 at 12:35 PM, Alain Achkar 
> wrote:
>
>> Thanks Chris!
>>
>> This is the answer I was looking for.
>>
>> On Mon, Nov 14, 2016 at 11:58 AM, Chris Whittenburg <
>> whittenb...@gmail.com> wrote:
>>
>>>
>>> Hi Alain,
>>>
>>> We use the same module-- Variscite DART MX6, and I was able to hack the
>>> yocto autobuilder to build our image nightly.  I host it all on a single
>>> machine.
>>>
>>> -chris
>>>
>>>
>>> On Mon, Nov 14, 2016 at 10:13 AM, Alain Achkar >> > wrote:
>>>
 Thanks for your answers! From reading these links, it is still not
 clear to me if this might be overkill for my requirements. AB Cluster Setup
 talks about "*the worker requires 2+ TB to hold all the build temp
 files and git repos. If build artifacts and a local sstate mirror are
 included, additional worker space is required.*"

 Currently, my build only takes 35GB, so I think what these links are
 talking about is how to replicate what the Autobuilder project
 https://autobuilder.yoctoproject.org/ already does.

 To clarify, I am not interested in running builds and tests for
 everything that Yocto already builds and tests (i.e. all the processor
 architectures, all the machine types, etc.).  I am interested in running
 one build for one machine type (the Variscite DART-6UL i.MX6UL arm-based
 processor, for which NXP/Freescale and Variscite have provided recipes and
 layers for).

 I know that autobuilder includes BuildBot (this is why I specified it
 in parentheses) but my question remains: do I only install BuildBot and try
 to build my machine type with it, or do I install Autobuilder?

 On Mon, Nov 14, 2016 at 10:10 AM, Bill Randle 
 wrote:

> Also, be sure to check the Yocto Project wiki pages:
> https://wiki.yoctoproject.org/wiki/The_Yocto_Autobuilder
> in particular, the AB cluster setup and AB maintenance links. Even
> though the one link refers to setting up an entire cluster, I've used
> that procedure to setup a single autobuilder, as well.
>
> -Bill
>
> On Fri, Nov 11, 2016 at 10:37 AM, Bet

[yocto] Installing shared libraries ncurses for custom application

[Marc-Antoine Martin]

Hi all,

I've have some trouble to add ncurses shared libraries to my recipe.
I want to add a software to my dist and it uses the ncurses shared libraries.

I wrote a recipe for this software but each time I try to build it
with bitbake I have the same issue:

QA Issue: /usr/bin/mySoft contained in package mysoft requires
libtinfo.so.5(NCURSES_TINFO_5.0.19991023), but no providers found in
RDEPENDS_mysoft? [file-rdeps]


My recipe is quite simple:

[...]
SECTION = "console/utils"

DEPENDS = "ncurses glibc"
RDEPENDS_${PN} = "ncurses-libform"

do_compile () {
oe_runmake
}

do_install () {
   install -d ${D}${bindir}
   install -m 0755 ${WORKDIR}/${PN}-${PV}/nInvaders ${D}${bindir}/
}


I tried to use different RDEPENDS like "ncurses-libtinfo
ncurses-libncurses" or "ncurses-terminfo" but each time it stops at
the do_rootfs() process and I get the error:

Can't install mysoft-0.1.1-r0@i586: no package provides
libtinfo.so.5(NCURSES_TINFO_5.0.19991023)


Depending on the RDEPENDS I set, I may have the variant:

Can't install mysoft-0.1.1-r0@i586: no package provides
libncurses.so.5(NCURSES_TINFO_5.0.19991023)


I don't understand why bitbake cannot find the libs provider. I
checked in the working dir of ncurses and the sysroots dir, the libs
are there. It also well-creates the rpm libtinfo-xxx.rpm and
libncurses-xxx.rpm.

I thank you in advance for any assistance.

Sincerely,
Marc-Antoine Martin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] bitbake core-image-base -c do_populate_sdk fails with glibc (unmet dependencies)

[David Bensoussan]

Hello,

I tried to solve the issue by myself, read on the documentation and check
the mailing list, but I couldn't find the information I was looking for.
The documentation was of a great help as a guideline but I now don't know
how to proceed.

I wanted to generate an sdk and met these errors while executing:
$ bitbake core-image-base -c do_populate_sdk

Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 packagegroup-core-standalone-sdk-target : Depends: glibc-gconv-cp1252 but
it is not installable
   Depends: glibc-gconv-ibm850 but
it is not installable
   Depends: glibc-gconv-iso8859-1
but it is not installable
   Depends: glibc-gconv-iso8859-15
but it is not installable
   Depends: glibc-localedata-i18n
but it is not installable
E: Unable to correct problems, you have held broken packages.

A long time ago, I generated one was using the adt-installer but it has
changed since.
I also tried to add in local.conf:
EXTRA_IMAGE_FEATURES = "tools-sdk"
DISTRO_FEATURES_LIBC = "libc-locales libc-locale-code"

But nothing worked. I am working with RPI3 machine under Jethro branch. My
first test was to try the same setup with qemuarm64 machine, it failed
exactly the same way. It seems there are conflicts in packages, but I don't
understand how to track the error at this point.

It raised multiple questions:
Am I doing it wrong? Did I miss a flag? What does this error exactly mean?

Thank you for your time

Regards,
-- 

*David bensoussan*
Roboticist / Embedded Software Engineer
--

*Synapticon* | Robotic Control Systems
Mobile: 015779804515
Fax: +49 7031 / 30 478 -99

*synapticon.com*  | Twitter
 | Facebook


Synapticon GmbH | Daimlerstraße 26 | 71101 Schönaich, Germany
Secretary +49 7031 / 30 478 -0 | Managing Director: Nikolai Ensslen
Amtsgericht Stuttgart HRB 756076 | USt-ID DE271647127

This message and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. Please notify the sender immediately if you have received this
e-mail by mistake and delete it from your system.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 1/3] raspberrypi2.conf: Make SERIAL_CONSOLE overwritable

[Andrei Gherzan]

On Thu, Apr 20, 2017 at 06:18:14PM +0100, Andrei Gherzan wrote:
> Signed-off-by: Andrei Gherzan 
> ---
>  conf/machine/raspberrypi2.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/conf/machine/raspberrypi2.conf b/conf/machine/raspberrypi2.conf
> index 9b4c02a..a17289c 100644
> --- a/conf/machine/raspberrypi2.conf
> +++ b/conf/machine/raspberrypi2.conf
> @@ -7,7 +7,7 @@ DEFAULTTUNE ?= "cortexa7thf-neon-vfpv4"
>  require conf/machine/include/tune-cortexa7.inc
>  include conf/machine/include/rpi-base.inc
>
> -SERIAL_CONSOLE = "115200 ttyAMA0"
> +SERIAL_CONSOLE ?= "115200 ttyAMA0"
>
>  UBOOT_MACHINE = "rpi_2_config"
>  VC4_CMA_SIZE ?= "cma-256"
> --
> 2.12.2
>

Entire patch set merged to master and morty.

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan


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

Re: [yocto] [meta-raspberrypi][PATCH] rpi-base: fix make_dtb_boot_files() for raspberrypi3-64

[Andrei Gherzan]

On Fri, Apr 21, 2017 at 10:37:52AM +0200, Andrea Galbusera wrote:
> Building the stock wic image for raspberrypi3-64 failed to find dtbs listed in
> IMAGE_BOOT_FILES. This patch updates the make_dtb_boot_files() function to
> account for dtbs listed in KERNEL_DEVICETREE that do include a path prefix:
> this is the case for things like broadcom/bcm2710-rpi-3-b.dtb (the dts dir
> layout in the kernel sources is different for arm64). Use the same approach
> already used for overlays/ dir. While at it also fix a typo in dtb overlay
> code path comments.
>
> Signed-off-by: Andrea Galbusera 
> ---
>  conf/machine/include/rpi-base.inc | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/conf/machine/include/rpi-base.inc 
> b/conf/machine/include/rpi-base.inc
> index 517d5ba..4a0ea2a 100644
> --- a/conf/machine/include/rpi-base.inc
> +++ b/conf/machine/include/rpi-base.inc
> @@ -61,16 +61,17 @@ def make_dtb_boot_files(d):
>
>  def transform(dtb):
>  if dtb.endswith('dtb'):
> -# eg: bcm2708-rpi-b.dtb has:
> +# eg: whatever/bcm2708-rpi-b.dtb has:
>  # DEPLOYDIR file: ${KERNEL_IMAGETYPE}-bcm2708-rpi-b.dtb
>  # destination: bcm2708-rpi-b.dtb
> -src = '{}-{}'.format(imgtyp, dtb)
> -dst = dtb
> +base = os.path.basename(dtb)
> +src = '{}-{}'.format(imgtyp, base)
> +dst = base
>  return '{};{}'.format(src, dst)
>  elif dtb.endswith('dtbo'):
>  # overlay dtb:
>  # eg: overlays/hifiberry-amp.dtbo has:
> -# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbp
> +# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbo

Looks good to me but this seems like a typo.

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan


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

Re: [yocto] [meta-raspberrypi][PATCH] rpi-base: fix make_dtb_boot_files() for raspberrypi3-64

[Andrei Gherzan]

On Fri, Apr 21, 2017 at 05:04:40PM +0100, Andrei Gherzan wrote:
> On Fri, Apr 21, 2017 at 10:37:52AM +0200, Andrea Galbusera wrote:
> > Building the stock wic image for raspberrypi3-64 failed to find dtbs listed 
> > in
> > IMAGE_BOOT_FILES. This patch updates the make_dtb_boot_files() function to
> > account for dtbs listed in KERNEL_DEVICETREE that do include a path prefix:
> > this is the case for things like broadcom/bcm2710-rpi-3-b.dtb (the dts dir
> > layout in the kernel sources is different for arm64). Use the same approach
> > already used for overlays/ dir. While at it also fix a typo in dtb overlay
> > code path comments.
> >
> > Signed-off-by: Andrea Galbusera 
> > ---
> >  conf/machine/include/rpi-base.inc | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/conf/machine/include/rpi-base.inc 
> > b/conf/machine/include/rpi-base.inc
> > index 517d5ba..4a0ea2a 100644
> > --- a/conf/machine/include/rpi-base.inc
> > +++ b/conf/machine/include/rpi-base.inc
> > @@ -61,16 +61,17 @@ def make_dtb_boot_files(d):
> >
> >  def transform(dtb):
> >  if dtb.endswith('dtb'):
> > -# eg: bcm2708-rpi-b.dtb has:
> > +# eg: whatever/bcm2708-rpi-b.dtb has:
> >  # DEPLOYDIR file: ${KERNEL_IMAGETYPE}-bcm2708-rpi-b.dtb
> >  # destination: bcm2708-rpi-b.dtb
> > -src = '{}-{}'.format(imgtyp, dtb)
> > -dst = dtb
> > +base = os.path.basename(dtb)
> > +src = '{}-{}'.format(imgtyp, base)
> > +dst = base
> >  return '{};{}'.format(src, dst)
> >  elif dtb.endswith('dtbo'):
> >  # overlay dtb:
> >  # eg: overlays/hifiberry-amp.dtbo has:
> > -# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbp
> > +# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbo
>
> Looks good to me but this seems like a typo.

Scratch that. Looks good all together.

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan


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

Re: [yocto] bitbake core-image-base -c do_populate_sdk fails with glibc (unmet dependencies)

[Burton, Ross]

On 21 April 2017 at 12:37, David Bensoussan 
wrote:

> DISTRO_FEATURES_LIBC = "libc-locales libc-locale-code"
>

Unless you really need to, don't fiddle stuff like this.  Can you share
your local.conf?

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

Re: [yocto] Installing shared libraries ncurses for custom application

[Burton, Ross]

On 19 April 2017 at 17:55, Marc-Antoine Martin  wrote:

> DEPENDS = "ncurses glibc"
> RDEPENDS_${PN} = "ncurses-libform"
>

glibc is a default dependency so you can remove that.  You can remove the
explicit RDEPENDS as bitbake will automatically add library runtime
dependencies for you.  Just have DEPENDS=ncurses, and see if that does the
right thing.

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

Re: [yocto] bitbake core-image-base -c do_populate_sdk fails with glibc (unmet dependencies)

[David Bensoussan]

Yes sure. Here it is:

DISTRO ?= "poky"
PACKAGE_CLASSES ?= "package_deb"

EXTRA_IMAGE_FEATURES = "debug-tweaks package-management tools-profile"

PATCHRESOLVE = "noop"

BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"

CONF_VERSION = "0.8"

BB_NUMBER_THREADS ?= "8"
PARALLEL_MAKE ?= "-j 8"
INCOMPATIBLE_LICENSE = "libav commercial CC-BY-SA-2.0 CC-BY-SA-3.0
CC-BY-SA-4.0"

MACHINE ?= "raspberrypi3"

FORTRAN_forcevariable = ",fortran"

RM_OLD_IMAGE = "1"

GCCVERSION ?= "5.4.%"
PREFERRED_VERSION_gcc ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-cross ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-cross-initial ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-cross-intermediate ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-cross-canadian ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-runtime ?= "${GCCVERSION}"
PREFERRED_VERSION_libgfortran ?= "${GCCVERSION}"
PREFERRED_VERSION_linux-raspberrypi = "4.9.%"

DISTRO_FEATURES_remove = "bluetooth nfc x11 wayland 3g"
IMAGE_INSTALL_remove = "bind ltrace"

IMAGE_LINGUAS = "en-us"
PREFERRED_PROVIDER_virtual/kernel= "linux-raspberrypi"



Thanks

On Fri, 21 Apr 2017 at 18:45 Burton, Ross  wrote:

>
> On 21 April 2017 at 12:37, David Bensoussan 
> wrote:
>
>> DISTRO_FEATURES_LIBC = "libc-locales libc-locale-code"
>>
>
> Unless you really need to, don't fiddle stuff like this.  Can you share
> your local.conf?
>
> Ross
>
-- 

*David bensoussan*
Roboticist / Embedded Software Engineer
--

*Synapticon* | Robotic Control Systems
Mobile: 015779804515
Fax: +49 7031 / 30 478 -99

*synapticon.com*  | Twitter
 | Facebook


Synapticon GmbH | Daimlerstraße 26 | 71101 Schönaich, Germany
Secretary +49 7031 / 30 478 -0 | Managing Director: Nikolai Ensslen
Amtsgericht Stuttgart HRB 756076 | USt-ID DE271647127

This message and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. Please notify the sender immediately if you have received this
e-mail by mistake and delete it from your system.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] rpi-base: fix make_dtb_boot_files() for raspberrypi3-64

[Andrei Gherzan]

On Fri, Apr 21, 2017 at 10:37:52AM +0200, Andrea Galbusera wrote:
> Building the stock wic image for raspberrypi3-64 failed to find dtbs listed in
> IMAGE_BOOT_FILES. This patch updates the make_dtb_boot_files() function to
> account for dtbs listed in KERNEL_DEVICETREE that do include a path prefix:
> this is the case for things like broadcom/bcm2710-rpi-3-b.dtb (the dts dir
> layout in the kernel sources is different for arm64). Use the same approach
> already used for overlays/ dir. While at it also fix a typo in dtb overlay
> code path comments.
>
> Signed-off-by: Andrea Galbusera 
> ---
>  conf/machine/include/rpi-base.inc | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/conf/machine/include/rpi-base.inc 
> b/conf/machine/include/rpi-base.inc
> index 517d5ba..4a0ea2a 100644
> --- a/conf/machine/include/rpi-base.inc
> +++ b/conf/machine/include/rpi-base.inc
> @@ -61,16 +61,17 @@ def make_dtb_boot_files(d):
>
>  def transform(dtb):
>  if dtb.endswith('dtb'):
> -# eg: bcm2708-rpi-b.dtb has:
> +# eg: whatever/bcm2708-rpi-b.dtb has:
>  # DEPLOYDIR file: ${KERNEL_IMAGETYPE}-bcm2708-rpi-b.dtb
>  # destination: bcm2708-rpi-b.dtb
> -src = '{}-{}'.format(imgtyp, dtb)
> -dst = dtb
> +base = os.path.basename(dtb)
> +src = '{}-{}'.format(imgtyp, base)
> +dst = base
>  return '{};{}'.format(src, dst)
>  elif dtb.endswith('dtbo'):
>  # overlay dtb:
>  # eg: overlays/hifiberry-amp.dtbo has:
> -# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbp
> +# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbo
>  # destination: overlays/hifiberry-amp.dtbo
>  base = os.path.basename(dtb)
>  src = '{}-{}'.format(imgtyp, base)
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Merged to master. Thanks.

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan


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

Re: [yocto] [meta-raspberrypi][PATCH 1/3] raspberrypi2.conf: Make SERIAL_CONSOLE overwritable

[Paul Barker]

On Fri, Apr 21, 2017 at 5:03 PM, Andrei Gherzan  wrote:
> On Thu, Apr 20, 2017 at 06:18:14PM +0100, Andrei Gherzan wrote:
>> Signed-off-by: Andrei Gherzan 
>> ---
>>  conf/machine/raspberrypi2.conf | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/conf/machine/raspberrypi2.conf b/conf/machine/raspberrypi2.conf
>> index 9b4c02a..a17289c 100644
>> --- a/conf/machine/raspberrypi2.conf
>> +++ b/conf/machine/raspberrypi2.conf
>> @@ -7,7 +7,7 @@ DEFAULTTUNE ?= "cortexa7thf-neon-vfpv4"
>>  require conf/machine/include/tune-cortexa7.inc
>>  include conf/machine/include/rpi-base.inc
>>
>> -SERIAL_CONSOLE = "115200 ttyAMA0"
>> +SERIAL_CONSOLE ?= "115200 ttyAMA0"
>>
>>  UBOOT_MACHINE = "rpi_2_config"
>>  VC4_CMA_SIZE ?= "cma-256"
>> --
>> 2.12.2
>>
>
> Entire patch set merged to master and morty.
>

This is the sort of thing I'm not keen on applying to stable branches
as it may change recipe behaviour. For comparison, the stable branch
policy for oe-core is very strict
(https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Policies).

In my mind, avoiding potential breakage on a stable branch is more
important than making improvements. I'm even weary of updating the
raspberrypi firmware as I don't know how careful they are about
backwards compatibility. For kernel updates I do have an expectation
of backwards compatibility and an understanding that new stable
releases often fix security issues so I'm ok with those on stable
branches.

For example of where I'm concerned, a "raspberrypi2" override was
previously applied to both raspberrypi2 and raspberrypi3 machines.
After the third patch in this series it only applies to the
raspberrypi2 machine. Also, UBOOT_MACHINE is now set differently for
raspberrypi3 ('=' vs '?='). These changes may affect the value of some
variables when building for raspberrypi3 if downstream users haven't
explicitly handled both raspberrypi2 and raspberrypi3 overrides. I
don't mind these sorts of changes on the master branch but I worry
about applying them to a stable branch.

What do other meta-raspberrypi stable branch users think? Should we be
pedantic here or should we keep things open so that improvements can
be applied to stable branches?

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

Re: [yocto] bitbake core-image-base -c do_populate_sdk fails with glibc (unmet dependencies)

[Trevor Woerner]

On Fri 2017-04-21 @ 11:37:44 AM, David Bensoussan wrote:
> I wanted to generate an sdk and met these errors while executing:
> $ bitbake core-image-base -c do_populate_sdk

Does adding the "do_" work? Is there any difference if you type:

$ bitbake core-image-base -c populate_sdk

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

Re: [yocto] [meta-raspberrypi][PATCH 1/3] raspberrypi2.conf: Make SERIAL_CONSOLE overwritable

[Mirza Krak]

2017-04-21 19:37 GMT+02:00 Paul Barker :
> On Fri, Apr 21, 2017 at 5:03 PM, Andrei Gherzan  wrote:
>> On Thu, Apr 20, 2017 at 06:18:14PM +0100, Andrei Gherzan wrote:
>>> Signed-off-by: Andrei Gherzan 
>>> ---
>>>  conf/machine/raspberrypi2.conf | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/conf/machine/raspberrypi2.conf b/conf/machine/raspberrypi2.conf
>>> index 9b4c02a..a17289c 100644
>>> --- a/conf/machine/raspberrypi2.conf
>>> +++ b/conf/machine/raspberrypi2.conf
>>> @@ -7,7 +7,7 @@ DEFAULTTUNE ?= "cortexa7thf-neon-vfpv4"
>>>  require conf/machine/include/tune-cortexa7.inc
>>>  include conf/machine/include/rpi-base.inc
>>>
>>> -SERIAL_CONSOLE = "115200 ttyAMA0"
>>> +SERIAL_CONSOLE ?= "115200 ttyAMA0"
>>>
>>>  UBOOT_MACHINE = "rpi_2_config"
>>>  VC4_CMA_SIZE ?= "cma-256"
>>> --
>>> 2.12.2
>>>
>>
>> Entire patch set merged to master and morty.
>>
>
> This is the sort of thing I'm not keen on applying to stable branches
> as it may change recipe behaviour. For comparison, the stable branch
> policy for oe-core is very strict
> (https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Policies).
>
> In my mind, avoiding potential breakage on a stable branch is more
> important than making improvements. I'm even weary of updating the
> raspberrypi firmware as I don't know how careful they are about
> backwards compatibility. For kernel updates I do have an expectation
> of backwards compatibility and an understanding that new stable
> releases often fix security issues so I'm ok with those on stable
> branches.
>
> For example of where I'm concerned, a "raspberrypi2" override was
> previously applied to both raspberrypi2 and raspberrypi3 machines.
> After the third patch in this series it only applies to the
> raspberrypi2 machine. Also, UBOOT_MACHINE is now set differently for
> raspberrypi3 ('=' vs '?='). These changes may affect the value of some
> variables when building for raspberrypi3 if downstream users haven't
> explicitly handled both raspberrypi2 and raspberrypi3 overrides. I
> don't mind these sorts of changes on the master branch but I worry
> about applying them to a stable branch.
>
> What do other meta-raspberrypi stable branch users think? Should we be
> pedantic here or should we keep things open so that improvements can
> be applied to stable branches?

I would have to agree with Paul here since you asked :).

I would apply a more strict policy working with stable branches, and
be be more in line with the Yocto policy. That is only bug fixes,
security updates and make sure that build is stable on supported
distributions. Everything else can wait until the next "release" and
reside in master.

My 2 cents.

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

[yocto] Yocto autotools for shared library using eclipse

[John Tobias]

Hello All,

I am using eclipse "Luna Service Release 2 (4.4.2) and Neon.3 Release
(4.6.3)". I've noticed that the Yocto plugin doesn't have any support
for shared library project. Is there any plan to support it in the
future?.

Regards,

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

[yocto] [RFC][meta-gplv2] layer priority and worth creating branch compatible with morty?

[Martin Jansa]

1) layer priority, currently it has:
   BBFILE_PRIORITY_gplv2 = "1"
   which is lower than oe-core with:
   BBFILE_PRIORITY_core = "5"
   so in order to use recipes from meta-gplv2 layer, user has to add
   couple PREFERRED_VERSIONS. Was this intended use for meta-gplv2?
   I can see some advantages of this (that the layer can be included
   without immediate side effects), but on the other hand why would
   anyone include this layer if he isn't deeply scared from (L)GPLv3
   versions sneaking into the build?
   In our local builds I'm bumping the priority to 6 to resolve this.
   Alternatively we can add some conf/distro/gplv2-versions.inc file
   in meta-gplv2 so that people who want to use all available recipes
   in gplv2 compatible version can include it in their DISTRO.

2) branch for morty, currently the recipes aren't compatible with morty
   but with e.g. gnutls version added there it might be better option
   to share the gplv2 work there even when oe-core/morty contains most
   of these recipes as well.
   The recipes I had to modify to be compatible with morty are:
   https://github.com/shr-project/meta-gplv2/commits/jansa/morty
   88d1052 coreutils: make it compatible with Yocto 2.2 Morty
   5e08ac2 rsync: make it compatible with Yocto 2.2 Morty
   b33037f libiconv: make it compatible with Yocto 2.2 Morty

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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

Re: [yocto] [RFC][meta-gplv2] layer priority and worth creating branch compatible with morty?

[Andre McCurdy]

On Fri, Apr 21, 2017 at 1:59 PM, Martin Jansa  wrote:
> 1) layer priority, currently it has:
>BBFILE_PRIORITY_gplv2 = "1"
>which is lower than oe-core with:
>BBFILE_PRIORITY_core = "5"
>so in order to use recipes from meta-gplv2 layer, user has to add
>couple PREFERRED_VERSIONS. Was this intended use for meta-gplv2?

I guess the intention is that if you blacklist GPLv3 etc then only the
recipes in meta-gplv2 will be considered.

>I can see some advantages of this (that the layer can be included
>without immediate side effects), but on the other hand why would
>anyone include this layer if he isn't deeply scared from (L)GPLv3
>versions sneaking into the build?
>In our local builds I'm bumping the priority to 6 to resolve this.

If any of the recipes in meta-gplv2 still contain BBCLASSEXTEND =
"native" then that could cause problems (generally you only want to
use the older recipes for the target, not for -native).

>Alternatively we can add some conf/distro/gplv2-versions.inc file
>in meta-gplv2 so that people who want to use all available recipes
>in gplv2 compatible version can include it in their DISTRO.
>
> 2) branch for morty, currently the recipes aren't compatible with morty
>but with e.g. gnutls version added there it might be better option
>to share the gplv2 work there even when oe-core/morty contains most
>of these recipes as well.
>The recipes I had to modify to be compatible with morty are:
>https://github.com/shr-project/meta-gplv2/commits/jansa/morty
>88d1052 coreutils: make it compatible with Yocto 2.2 Morty
>5e08ac2 rsync: make it compatible with Yocto 2.2 Morty
>b33037f libiconv: make it compatible with Yocto 2.2 Morty
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto