Re: [yocto] cannot build image using sstate

2017-03-09 Thread Mircea Gliga 
Thanks! You are right, the do_deploy_append installs the 
image_signed.fit in the ${DEPLOY_DIR_IMAGE}(I should have kept that line 
in the previous mail also):

do_deploy_append() {
[...]
 #this line creates the image_signed.fit file
  mkimage  [...] image_signed.fit
  install -m 0644  image_signed.fit ${DEPLOY_DIR_IMAGE}/.
[...]
}

The doc mentions in regards to DEPLOYDIR:
"Recipes inheriting the |deploy| class should copy files to be deployed 
into |DEPLOYDIR|, and the class will take care of copying them into 
|DEPLOY_DIR_IMAGE| 
 
afterwards."


So I should just replace ${DEPLOY_DIR_IMAGE} with ${DEPLOYDIR} and I get 
the same behaviour as before + the benefit of sstate cache ?


Thanks


On 09/03/17 09:22, Patrick Ohly wrote:

On Thu, 2017-03-09 at 08:54 +0200, Mircea Gliga wrote:

Long story short: I have problems building an image, in a clean build
directory, reusing the shared state cache and downloads from a previous
build.
A file created in the do_deploy_append task is not created(restored)
anymore when building using a previous sstate.

And now the long description:
In my custom layer, in a kernel recipe, linux-stable.bb, I have appended
some operations to the `deploy` task, one of them is creating an U-Boot
FIT image:

linux-stable.bb:
do_deploy_append() {
[...]
  #this line creates the image_signed.fit file
   mkimage  [...] image_signed.fit

[...]
}

Are you writing image_signed.fit into the ${DEPLOYDIR} or
${DEPLOY_DIR_IMAGE}? When writing directly into ${DEPLOY_DIR_IMAGE}, you
bypass the mechanism which adds files to the sstate cache and then you
get exactly the problem you describe.



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

Re: [yocto] cannot build image using sstate

2017-03-09 Thread Patrick Ohly 
On Thu, 2017-03-09 at 09:59 +0200, Mircea Gliga wrote:
> Thanks! You are right, the do_deploy_append installs the
> image_signed.fit in the ${DEPLOY_DIR_IMAGE}(I should have kept that
> line in the previous mail also):
> do_deploy_append() {
> [...]
>  #this line creates the image_signed.fit file
>   mkimage  [...] image_signed.fit
>   install -m 0644  image_signed.fit ${DEPLOY_DIR_IMAGE}/.
> [...]
> }
> 
> The doc mentions in regards to DEPLOYDIR:
> "Recipes inheriting the deploy class should copy files to be deployed
> into DEPLOYDIR, and the class will take care of copying them into
> DEPLOY_DIR_IMAGE afterwards."
> 
> So I should just replace ${DEPLOY_DIR_IMAGE} with ${DEPLOYDIR} and I
> get the same behaviour as before + the benefit of sstate cache ?

Yes.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[yocto] [PATCH][meta-gplv2] bison: add missing patch from oe-core

2017-03-09 Thread Martin Jansa 
* meta-gplv2/recipes-devtools/bison/bison_2.3.bb: Unable to get checksum for 
bison SRC_URI entry bison-2.3_m4.patch: file
 could not be found

Signed-off-by: Martin Jansa 
---
 recipes-devtools/bison/bison/bison-2.3_m4.patch | 591 
 1 file changed, 591 insertions(+)
 create mode 100644 recipes-devtools/bison/bison/bison-2.3_m4.patch

diff --git a/recipes-devtools/bison/bison/bison-2.3_m4.patch 
b/recipes-devtools/bison/bison/bison-2.3_m4.patch
new file mode 100644
index 000..348ce1d
--- /dev/null
+++ b/recipes-devtools/bison/bison/bison-2.3_m4.patch
@@ -0,0 +1,591 @@
+Upstream-Status: Pending
+
+#
+# Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
+#
+
+--- /dev/null
 bison-1.875/m4/inttypes-pri.m4
+@@ -0,0 +1,32 @@
++# inttypes-pri.m4 serial 1 (gettext-0.11.4)
++dnl Copyright (C) 1997-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special exception to the GNU General
++dnl Public License, this file may be distributed as part of a program
++dnl that contains a configuration script generated by Autoconf, under
++dnl the same distribution terms as the rest of that program.
++
++dnl From Bruno Haible.
++
++# Define PRI_MACROS_BROKEN if  exists and defines the PRI*
++# macros to non-string values.  This is the case on AIX 4.3.3.
++
++AC_DEFUN([gt_INTTYPES_PRI],
++[
++  AC_REQUIRE([gt_HEADER_INTTYPES_H])
++  if test $gt_cv_header_inttypes_h = yes; then
++AC_CACHE_CHECK([whether the inttypes.h PRIxNN macros are broken],
++  gt_cv_inttypes_pri_broken,
++  [
++AC_TRY_COMPILE([#include 
++#ifdef PRId32
++char *p = PRId32;
++#endif
++], [], gt_cv_inttypes_pri_broken=no, gt_cv_inttypes_pri_broken=yes)
++  ])
++  fi
++  if test "$gt_cv_inttypes_pri_broken" = yes; then
++AC_DEFINE_UNQUOTED(PRI_MACROS_BROKEN, 1,
++  [Define if  exists and defines unusable PRI* macros.])
++  fi
++])
+--- /dev/null
 bison-1.875/m4/lcmessage.m4
+@@ -0,0 +1,32 @@
++# lcmessage.m4 serial 3 (gettext-0.11.3)
++dnl Copyright (C) 1995-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special exception to the GNU General
++dnl Public License, this file may be distributed as part of a program
++dnl that contains a configuration script generated by Autoconf, under
++dnl the same distribution terms as the rest of that program.
++dnl
++dnl This file can can be used in projects which are not available under
++dnl the GNU General Public License or the GNU Library General Public
++dnl License but which still want to provide support for the GNU gettext
++dnl functionality.
++dnl Please note that the actual code of the GNU gettext library is covered
++dnl by the GNU Library General Public License, and the rest of the GNU
++dnl gettext package package is covered by the GNU General Public License.
++dnl They are *not* in the public domain.
++
++dnl Authors:
++dnl   Ulrich Drepper , 1995.
++
++# Check whether LC_MESSAGES is available in .
++
++AC_DEFUN([AM_LC_MESSAGES],
++[
++  AC_CACHE_CHECK([for LC_MESSAGES], am_cv_val_LC_MESSAGES,
++[AC_TRY_LINK([#include ], [return LC_MESSAGES],
++   am_cv_val_LC_MESSAGES=yes, am_cv_val_LC_MESSAGES=no)])
++  if test $am_cv_val_LC_MESSAGES = yes; then
++AC_DEFINE(HAVE_LC_MESSAGES, 1,
++  [Define if your  file defines LC_MESSAGES.])
++  fi
++])
+--- /dev/null
 bison-1.875/m4/uintmax_t.m4
+@@ -0,0 +1,29 @@
++# uintmax_t.m4 serial 6 (gettext-0.11)
++dnl Copyright (C) 1997-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special exception to the GNU General
++dnl Public License, this file may be distributed as part of a program
++dnl that contains a configuration script generated by Autoconf, under
++dnl the same distribution terms as the rest of that program.
++
++dnl From Paul Eggert.
++
++AC_PREREQ(2.13)
++
++# Define uintmax_t to `unsigned long' or `unsigned long long'
++# if  does not exist.
++
++AC_DEFUN([jm_AC_TYPE_UINTMAX_T],
++[
++  AC_REQUIRE([jm_AC_HEADER_INTTYPES_H])
++  AC_REQUIRE([jm_AC_HEADER_STDINT_H])
++  if test $jm_ac_cv_header_inttypes_h = no && test $jm_ac_cv_header_stdint_h 
= no; then
++AC_REQUIRE([jm_AC_TYPE_UNSIGNED_LONG_LONG])
++test $ac_cv_type_unsigned_long_long = yes \
++  && ac_type='unsigned long long' \
++  || ac_type='unsigned long'
++AC_DEFINE_UNQUOTED(uintmax_t, $ac_type,
++  [Define to unsigned long or unsigned long long
++   if  and  don't define.])
++  fi
++])
+--- /dev/null
 bison-1.875/m4/glibc21.m4
+@@ -0,0 +1,32 @@
++# glibc21.m4 serial 2 (fileutils-4.1.3, gettext-0.10.40)
++dnl Copyright (C) 2000-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special excep

Re: [yocto] hddimg 4GB limit?

2017-03-09 Thread Burton, Ross 
On 9 March 2017 at 07:04, Takashi Matsuzawa  wrote:

> I found hddimg 4GB-1 bye restriction because it creates a file called
> rootfs.img which is copied into FAT.
>
> That means rootfs.img size must be below FAT max file size...
>
>
Yes.  This is why I'd like to see hddimg removed and replaced with a
partition layout in wic that doesn't use a FAT container.

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

[yocto] Source Code provision without full git repository history

2017-03-09 Thread Waldvogel, Sebastian 
Hello,

I am searching for a way in Yocto/BitBake to extract the source codes of the 
software applications developed by my company for delivery to our customers.
The source codes shall be delivered as archive containing only the source files 
without the whole git repository history.

Setup is that we have own Yocto layers/recipes referencing the company internal 
git repository (SRC_URI="git://git.company.url") and the concrete SRCREV to be 
used. Basic idea was to use the option BB_GENERATE_MIRROR_TARBALLS = "1" which 
generates an archive file with the application source code. Unfortunately the 
generated tarball contains the full bare cloned git repository with full 
history and not only the source files of the concrete SRCREV.

As alternative I tried to use the archiver 
class.
 The generated tarballs contains the concrete source files but in addition the 
full git repository with history is contained too.

Does anyone has an idea how to extract the concrete source files without git 
repository and history?

Thank you very much for your help
Sebastian Waldvogel


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

Re: [yocto] [meta-rockchip][PATCH] u-boot-rockchip: fix for binutils-2.28

2017-03-09 Thread Trevor Woerner 
On Wed 2017-03-08 @ 09:33:18 PM, Khem Raj wrote:
> On 17-03-09 00:01:12, Trevor Woerner wrote:
> > Okay.
> > 
> > Building with 2.28 (and letting it fail), then repeating the final link step
> > with 2.27 succeeds!
> 
> OK thats good. Can you post the output of readelf -e on final good and bad 
> binaries

Phew! I wasn't sure if this was good or bad :-S

I assume by "good" you mean a build with binutils-2.27 without -N and with
SPL?

I assume by "bad" you mean the frankenbuild (i.e. built with 2.28 but linked
with 2.27, without -N, with SPL)?

If so, good:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  DYN (Shared object file)
  Machine:   ARM
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  52 (bytes into file)
  Start of section headers:  3548088 (bytes into file)
  Flags: 0x5000200, Version5 EABI, 
soft-float ABI
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 5
  Size of section headers:   40 (bytes)
  Number of section headers: 30
  Section header string table index: 27

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg 
Lk Inf Al
  [ 0]   NULL 00 00 00  
0   0  0
  [ 1] .text PROGBITS 01 0301a4 00  AX  
0   0 32
  [ 2] .rodata   PROGBITS000301a8 0401a8 0134dc 00   A  
0   0  8
  [ 3] .hash HASH00043684 053684 18 04   A 
13   0  4
  [ 4] .data PROGBITS000436a0 0536a0 00296c 00  WA  
0   0  8
  [ 5] .got.plt  PROGBITS0004600c 05600c 0c 04  WA  
0   0  4
  [ 6] .u_boot_list  PROGBITS00046018 056018 001b3c 00  WA  
0   0  4
  [ 7] .efi_runtime  PROGBITS00047b58 057b58 000100 00 WAX  
0   0  8
  [ 8] .efi_runtime_rel  REL 00047c58 057c58 90 08   A 
13   0  4
  [ 9] .rel.dyn  REL 00047ce8 057ce8 00a8c8 08   A 
13   0  4
  [10] .bss_startPROGBITS00047ce8 06267d 00 00   W  
0   0  1
  [11] .bss  NOBITS  00047ce8 00 03d100 00  WA  
0   0 64
  [12] .bss_end  PROGBITS00084de8 06267d 00 00   W  
0   0  1
  [13] .dynsym   DYNSYM  000525b0 0625b0 30 10   A 
14   3  4
  [14] .dynstr   STRTAB  000525e0 0625e0 01 00   A  
0   0  1
  [15] .dynamic  DYNAMIC 000525e4 0625e4 88 08  WA 
14   0  4
  [16] .interp   PROGBITS0005266c 06266c 11 00   A  
0   0  1
  [17] .ARM.attributes   ARM_ATTRIBUTES   06267d 29 00  
0   0  1
  [18] .comment  PROGBITS 0626a6 11 01  MS  
0   0  1
  [19] .debug_line   PROGBITS 0626b7 0556f7 00  
0   0  1
  [20] .debug_info   PROGBITS 0b7dae 1885b9 00  
0   0  1
  [21] .debug_abbrev PROGBITS 240367 03454d 00  
0   0  1
  [22] .debug_arangesPROGBITS 2748b8 0058b8 00  
0   0  8
  [23] .debug_frame  PROGBITS 27a170 00fd78 00  
0   0  4
  [24] .debug_strPROGBITS 289ee8 0281a9 01  MS  
0   0  1
  [25] .debug_locPROGBITS 2b2091 07d5c5 00  
0   0  1
  [26] .debug_ranges PROGBITS 32f658 00c850 00  
0   0  8
  [27] .shstrtab STRTAB   36228b 00012b 00  
0   0  1
  [28] .symtab   SYMTAB   33bea8 01bef0 10 
29 5910  4
  [29] .strtab   STRTAB   357d98 00a4f3 00  
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor 
specific)

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg 
Align
  PHDR   0x34 0x00010034 0x 0x000a0 0x000a0 R E 0x4
  INTERP 0x06266c 0x0005266

Re: [yocto] Source Code provision without full git repository history

2017-03-09 Thread Khem Raj 
On Thu, Mar 9, 2017 at 5:02 AM Waldvogel, Sebastian <
sebastian.waldvo...@vector.com> wrote:

> Hello,
>
>
>
> I am searching for a way in Yocto/BitBake to extract the source codes of
> the software applications developed by my company for delivery to our
> customers.
>
> The source codes shall be delivered as archive containing only the source
> files without the whole git repository history.
>
>
>
> Setup is that we have own Yocto layers/recipes referencing the company
> internal git repository (SRC_URI=”git://git.company.url”) and the concrete
> SRCREV to be used. Basic idea was to use the option
> BB_GENERATE_MIRROR_TARBALLS = "1" which generates an archive file with the
> application source code. Unfortunately the generated tarball contains the
> full bare cloned git repository with full history and not only the source
> files of the concrete SRCREV.
>
>
>
> As alternative I tried to use the archiver class
> .
> The generated tarballs contains the concrete source files but in addition
> the full git repository with history is contained too.
>

I am not sure if it is intended to keep SCM history though you might want
to file a bug

>
>
> Does anyone has an idea how to extract the concrete source files without
> git repository and history?
>
>
>
> Thank you very much for your help
>
> Sebastian Waldvogel
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [patchwork][PATCH] series.py: return bundle objects only when authenticated

2017-03-09 Thread Jose Lamego 
If a non-authenticated user tries to get a series view from
patchwork web UI, a 500 error message is displayed caused by
the database access attempted when filtering the bundle objects.

This change allows not-logged users to acces series view by
returning an empty bundle variable, instead of trying to
access the database.

Signed-off-by: Jose Lamego 
---
 patchwork/views/series.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/patchwork/views/series.py b/patchwork/views/series.py
index cb3b721..765d2e5 100644
--- a/patchwork/views/series.py
+++ b/patchwork/views/series.py
@@ -48,7 +48,10 @@ class SeriesView(View):
 revisions = get_list_or_404(SeriesRevision, series=series)
 patchform = PatchForm(project=series.project)
 createbundleform = CreateBundleForm()
-bundles = Bundle.objects.filter(owner=request.user)
+if request.user.is_authenticated():
+bundles = Bundle.objects.filter(owner=request.user)
+else:
+bundles=""
 for revision in revisions:
 revision.patch_list = revision.ordered_patches().\
 select_related('state', 'submitter')
-- 
2.7.4

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

Re: [yocto] [meta-mingw][PATCH v2 0/19] Adding support for building QEMU for Windows

2017-03-09 Thread Nathan Rossi 
On 30 January 2017 at 18:44, Nathan Rossi  wrote:
> This series enables a number of packages and dependencies to be built
> for mingw32. The goal is to enable the building and packaging of QEMU
> targeting mingw32 with support for SDL/VNC enabled as well as being able
> to execute the qemu* machines of oe-core/meta.
>
> The following series fixes a number of issues with compilation of
> certain components that are required to build and distribute QEMU. This
> series includes:
>
>  * Enabling 'secure-api' for mingw-w64-headers
>  * Fix/enable building of shared libraries for gettext
>  * Work around to avoid dependency on bash for glib-2.0, clean up of
>some glib-2.0 appends which are resolved in oe-core meta
>  * Better packaging of libgcc for easy use on Windows (deploy dll to
>bindir)
>  * Updating FILES_* to support locations for mingw32 output (bindir
>contains .dll) for libgcc, expat, libpcre, gettext, glib-2.0, libsdl,
>libgpg-error and libgcrypt
>  * Addition of PACKAGECONFIG options to libsdl, and configuring of
>PACKAGECONFIG for libsdl, glib-2.0 and libgcrypt to handle Windows
>only features and or ability to disable features that do not support
>mingw32/Windows
>  * Enabling build of libfdt in the dtc recipe, but skipping dtc itself
>  * Fixes for configuring libgpg-error and libgcrypt when targeting
>mingw32
>
> The intended build execution is to allow for 'buildtools-tarball' (or
> any populate_sdk target with 'nativesdk-qemu' in TOOLCHAIN_HOST_TASK) to
> create an output that includes all dependent nativesdk binaries as well
> as a nativesdk QEMU binaries. This series does not however address
> fixing the environment setup script or self-extracting installer shell
> script that is normally provided by buildtools-tarball.
>
> This series with the multiple oe-core/meta series was tested on the
> following target Windows platforms: Windows 10 (64-bit), Windows 8.1
> (64-bit) and Windows 7 SP1 (64-bit).
>
> The changes were also tested on the following Linux build hosts: Debian
> 8 (64-bit), Ubuntu 16.04 (64-bit), CentOS 7 (64-bit).
>
> For convenience this series is also available in the git repository:
>
>   https://github.com/nathanrossi/meta-mingw nrossi/mingw-qemu-v2
>
> This series partly depends on a set of series for oe-core/meta. The
> following series are required for building of QEMU (but not all parts of
> this series specifically), including dll packaging detection and
> libgcrypt support:
>
>   https://patchwork.openembedded.org/series/5049/
>   https://patchwork.openembedded.org/series/5050/
>   https://patchwork.openembedded.org/series/5051/
>   https://patchwork.openembedded.org/series/5052/
>   https://patchwork.openembedded.org/series/5053/

These patch series have been merged into oe-core. However the
gettext-libintl packaging patch was moved to a change in meta-mingw
layer as of v3 (see below).

I have updated and pushed a v3 branch of this meta-mingw series to the
meta-mingw-contrib repo here:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/log/?h=nrossi/mingw-qemu-v3

Changes v3:
 * Updated changes to layer on current master of oe/meta
 * Squished the gettext libintl packaging and dll packaging patches
 * Moved the adding of the libintl packaging to meta-mingw

To avoid patch spam, I have skipped sending the v3 patches
individually to the list. Please let me know if patch emails are
desired.

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

[yocto] [meta-qt4][PATCH] qt4: don't override dbg package content

2017-03-09 Thread Pascal Bach 
The default from bitbake.conf is `FILES_${PN}-dbg = "/usr/lib/debug 
/usr/src/debug"`
which is perfectly fine as a basis for Qt4.
This also makes the recipe work with different debug split schemes.

Signed-off-by: Pascal Bach 
---
 recipes-qt4/qt4/qt4.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/recipes-qt4/qt4/qt4.inc b/recipes-qt4/qt4/qt4.inc
index 2058e54..8f244ce 100644
--- a/recipes-qt4/qt4/qt4.inc
+++ b/recipes-qt4/qt4/qt4.inc
@@ -130,7 +130,6 @@ PACKAGES_DYNAMIC += "^${QT_BASE_NAME}-plugin-.* 
^${QT_BASE_NAME}-translation-.*
 ALLOW_EMPTY_${PN} = "1"
 FILES_${PN} = ""
 FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
-FILES_${PN}-dbg = "/usr/src/debug/"
 FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
 RRECOMMENDS_${PN} = "${LIB_PACKAGES} ${OTHER_PACKAGES}"
 RRECOMMENDS_${PN}-dev = "${DEV_PACKAGES}"
-- 
2.1.4

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

Re: [yocto] [meta-qt4][PATCH] qt4: don't override dbg package content

2017-03-09 Thread Burton, Ross 
On 9 March 2017 at 15:53, Pascal Bach  wrote:

> The default from bitbake.conf is `FILES_${PN}-dbg = "/usr/lib/debug
> /usr/src/debug"`
> which is perfectly fine as a basis for Qt4.
>

Note that oe-core master (and morty, and maybe krogoth) doesn't need
FILES_PN-dbg to be set at all.

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

[yocto] [imx6qsabresd][morty] Locales not generated

2017-03-09 Thread Fabio Emiliani 

Dear all,

I'm trying to configure locale support in Yocto. My taget machine is: 
imx6qsabresd (i.MX 6Quad Processor), yocto version is: morty.


I've created a base image with the command: bitbake core-image-base, 
then I've booted the image in my sabre board. Everything works fine 
except locales.


Reading in the docs I've found:

You can set |GLIBC_GENERATE_LOCALES| in your |local.conf| file. By 
default, all locales are generated. 
Link: 
http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#var-GLIBC_GENERATE_LOCALES


In my build I've found only a locale, path: /usr/share/locale/en_GB, no 
other locales are generated. Executing the "locale" command I've got:



root@imx6qsabresd:/usr/share/locale# locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Default locale is POSIX, not en_GB.

I've tried several options in my local.conf:

 * ENABLE_BINARY_LOCALE_GENERATION = "1" to enable the generation of
   locales at build time
 * IMAGE_INSTALL_append = " glibc-utils localedef" to add to the build
   locale and localdef
 * IMAGE_LINGUAS = "en-gb en-us zh-cn" to specify the add of additional
   packages

None of this options had effects.

Looking in the features list of the next yocto release I've found this bug:


https://bugzilla.yoctoproject.org/show_bug.cgi?id=9070
is it possible that curreny release has problems respect to locale 
generation?


_/Why locales are not generated? What do I have to configure to generate 
them?/_


Thanks in advance for your time

Regards,

Fabio Emiliani

--

*Fabio Emiliani*

*/Software Engineer/*

/Ph. +39 075 8298 530 /

/fabio.emili...@artgroup-spa.com/ 

DISCLAIMER
This email and any attachment may contain confidential information. If 
you are not the intended recipient you are not authorised to copy or 
disclose all or any part of it without the prior written consent of ART SpA.


/ART SpA – Step Forward With US - //www.artgroup-spa.com/logo_ART_firma-1//

/Ph. +39 075 8298 501 – Fax +39 075 8298 525 /

P*Please consider our environment  before printing this e-mail***

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

Re: [yocto] Source Code provision without full git repository history

2017-03-09 Thread Daniel. 
I'm not trying to be simplistic here, but, why not package the source
releases to a tarball (with git archive or somthing) and provide it
through a FTP server?

Regards,

2017-03-09 11:29 GMT-03:00 Khem Raj :
>
> On Thu, Mar 9, 2017 at 5:02 AM Waldvogel, Sebastian
>  wrote:
>>
>> Hello,
>>
>>
>>
>> I am searching for a way in Yocto/BitBake to extract the source codes of
>> the software applications developed by my company for delivery to our
>> customers.
>>
>> The source codes shall be delivered as archive containing only the source
>> files without the whole git repository history.
>>
>>
>>
>> Setup is that we have own Yocto layers/recipes referencing the company
>> internal git repository (SRC_URI=”git://git.company.url”) and the concrete
>> SRCREV to be used. Basic idea was to use the option
>> BB_GENERATE_MIRROR_TARBALLS = "1" which generates an archive file with the
>> application source code. Unfortunately the generated tarball contains the
>> full bare cloned git repository with full history and not only the source
>> files of the concrete SRCREV.
>>
>>
>>
>> As alternative I tried to use the archiver class. The generated tarballs
>> contains the concrete source files but in addition the full git repository
>> with history is contained too.
>
>
> I am not sure if it is intended to keep SCM history though you might want to
> file a bug
>>
>>
>>
>> Does anyone has an idea how to extract the concrete source files without
>> git repository and history?
>>
>>
>>
>> Thank you very much for your help
>>
>> Sebastian Waldvogel
>>
>>
>>
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Source Code provision without full git repository history

2017-03-09 Thread Daniel. 
There are some tools to automate the testing and delivery that may
make the deployment less painfull. Jenkins and Buildbot are examples

Regards,

2017-03-09 13:28 GMT-03:00 Daniel. :
> I'm not trying to be simplistic here, but, why not package the source
> releases to a tarball (with git archive or somthing) and provide it
> through a FTP server?
>
> Regards,
>
> 2017-03-09 11:29 GMT-03:00 Khem Raj :
>>
>> On Thu, Mar 9, 2017 at 5:02 AM Waldvogel, Sebastian
>>  wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> I am searching for a way in Yocto/BitBake to extract the source codes of
>>> the software applications developed by my company for delivery to our
>>> customers.
>>>
>>> The source codes shall be delivered as archive containing only the source
>>> files without the whole git repository history.
>>>
>>>
>>>
>>> Setup is that we have own Yocto layers/recipes referencing the company
>>> internal git repository (SRC_URI=”git://git.company.url”) and the concrete
>>> SRCREV to be used. Basic idea was to use the option
>>> BB_GENERATE_MIRROR_TARBALLS = "1" which generates an archive file with the
>>> application source code. Unfortunately the generated tarball contains the
>>> full bare cloned git repository with full history and not only the source
>>> files of the concrete SRCREV.
>>>
>>>
>>>
>>> As alternative I tried to use the archiver class. The generated tarballs
>>> contains the concrete source files but in addition the full git repository
>>> with history is contained too.
>>
>>
>> I am not sure if it is intended to keep SCM history though you might want to
>> file a bug
>>>
>>>
>>>
>>> Does anyone has an idea how to extract the concrete source files without
>>> git repository and history?
>>>
>>>
>>>
>>> Thank you very much for your help
>>>
>>> Sebastian Waldvogel
>>>
>>>
>>>
>>>
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
> --
> “If you're going to try, go all the way. Otherwise, don't even start. ..."
>   Charles Bukowski



-- 
“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Intoducting myself: Applying for Outreachy

2017-03-09 Thread Jeff Osier-Mixon 
Thanks, Leonardo & Armin

The Outreachy page for YP is here:

https://www.yoctoproject.org/outreachy-internship

any new potential interns can contact me directly

On Tue, Mar 7, 2017 at 9:24 AM, Soumya Gupta  wrote:

> Hi,
>
> Please look under Yocto under Participating Organisations
> 
> Thank you
>
> Best,
> Soumya Atul Gupta
> Final Year Undergraduate Student, ECE
> Netaji Subhas Institute of Technology
> New Delhi, India
>
>
> On Tue, Mar 7, 2017 at 10:38 PM, Leonardo Sandoval <
> leonardo.sandoval.gonza...@linux.intel.com> wrote:
>
>> On Tue, 2017-03-07 at 22:18 +0530, Soumya Gupta wrote:
>> > Hi all,
>> >
>> >
>> > My name is Soumya, an I am a final year Engineering undergraduate
>> > student from New Delhi. I would love to work to contribute to Yocto
>> > for the summer.
>> >
>> >
>> > I have been coding in Python for the past year and I am quite at ease
>> > with the same. It states on the Outreachy page, that there is a
>> > project relating to the building of autobuilders. I want to work on
>> > the same.
>>
>> can you point to that page?
>>
>> There is an autobuilder repo at git.yoctoproject.org, perhaps you can
>> start looking there.
>>
>> >
>> > Being a newbie, it would be great, if someone could guide me on the
>> > right path here
>> >
>> > Thanks already
>> >
>> >
>> > Best,
>> > Soumya Atul Gupta
>> > Final Year Undergraduate Student, ECE
>> > Netaji Subhas Institute of Technology
>> > New Delhi, India
>> >
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
Jeff Osier-Mixon - Open Source Community Engineer, Intel Corporation
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

2017-03-09 Thread Steve Plant 
OK, I have spent the last day googling my heart out trying to find the Xorg.log 
file without any luck.


The problem is that due to the rpi hanging on boot, the only way I can access 
the SD card to look for the file is place it in a USB SD card reader and use my 
VirtualBox based Debian to "ls" directores etc.

Having established that there is no file located at /var/log/Xorg.log (there 
isn't a log directory) but there is a symbolic link in the var directory - goes 
nowhere.


After goggling I discovered that the file could also be in the 
~/.local/share/xorg/Xorg.0.log, however if I try to look there I get 
"permission denied" and cannot seem to get to the root directory of the card 
and I can't find a way around this as I'm trying to access this directory 
through the USB card reader.


Looked everywhere with no answers, Is there anyone who could help me here??


Regards, Steve.



From: Khem Raj 
Sent: Wednesday, 8 March 2017 5:17 p.m.
To: Steve Plant
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

On 17-03-08 12:40:51, Steve Plant wrote:
> Hi All,
>
>
> Very new to all this linux world, and especially Yocto.
>
>
> I'm working on a embedded project at the moment using a raspberry pi2 board.
>
>
> I have used toaster with Morty 2.2 to compile an image 
> using"rpi-basic-image", to this I have added the following bitbake variables:
>
> Bitbake variables
>
> DISTRO
> poky
> DL_DIR
> /home/steve/poky/downloads
> IMAGE_FSTYPES
> ext3 jffs2 tar.bz2 rpi-sdimg
> IMAGE_INSTALL_append
> packagegroup-core-x11-base packagegroup-lxde-base connman
> PACKAGE_CLASSES
> package_rpm
> SSTATE_DIR
> /home/steve/poky/sstate-cache
>
> DISABLE_OVERSCAN
> 1
> GPU_MEM_1024
> 512
>
> I have dd'ed the image to an SD card increased the sdb2 partition to the max 
> size and powered up the rpi. Everything looks fine to start with, as it 
> displays the four raspberrys in the top left, then the white "Yocto Project" 
> splash screen complete with small blue dot to the side appears, the progress 
> bar moves across to 100 percent, then the screen turns black with a white 
> cursor in the middle and it appears to freeze with only a very dim one second 
> flash of the "act" led.
>
>
> I have then connected the 7" touchscreen and apart from the added 
> multicolored square at the very beginning I get the exact same boot up 
> problem, hangs on the black screen with white cursor (good to see its all 
> resized correctly for the TfT through!!)
>
>
> Before adding the packagegroup-core-x11-base and packagegroup-lxde-base I 
> successfully copied over and ran the rpi-basic-image with no problem, ending 
> up with a usable console.
>
>
> Looking for any help here, I'm thinking I've missed adding a package, or some 
> type of local.conf instruction. any suggestions would be 
> appreciated.

Can you send the content of /var/log/Xorg.log file ?

>
>
>
> Regards, Steve.

> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.



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

Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

2017-03-09 Thread Gary Thomas 

On 2017-03-10 01:55, Steve Plant wrote:

OK, I have spent the last day googling my heart out trying to find the Xorg.log 
file without any luck.


The problem is that due to the rpi hanging on boot, the only way I can access 
the SD card to look for the file is place
it in a USB SD card reader and use my VirtualBox based Debian to "ls" 
directores etc.

Having established that there is no file located at /var/log/Xorg.log (there 
isn't a log directory) but there is a
symbolic link in the var directory - goes nowhere.


After goggling I discovered that the file could also be in the 
~/.local/share/xorg/Xorg.0.log, however if I try to look
there I get "permission denied" and cannot seem to get to the root directory of 
the card and I can't find a way around
this as I'm trying to access this directory through the USB card reader.


Looked everywhere with no answers, Is there anyone who could help me here??


/var/log is on a volatile file system (i.e. it does not live on the SD card)

If you can get into your board via SSH, you can copy the file and send it



*From:* Khem Raj 
*Sent:* Wednesday, 8 March 2017 5:17 p.m.
*To:* Steve Plant
*Cc:* yocto@yoctoproject.org
*Subject:* Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

On 17-03-08 12:40:51, Steve Plant wrote:

Hi All,


Very new to all this linux world, and especially Yocto.


I'm working on a embedded project at the moment using a raspberry pi2 board.


I have used toaster with Morty 2.2 to compile an image using"rpi-basic-image", 
to this I have added the following bitbake variables:

Bitbake variables

DISTRO
poky
DL_DIR
/home/steve/poky/downloads
IMAGE_FSTYPES
ext3 jffs2 tar.bz2 rpi-sdimg
IMAGE_INSTALL_append
packagegroup-core-x11-base packagegroup-lxde-base connman
PACKAGE_CLASSES
package_rpm
SSTATE_DIR
/home/steve/poky/sstate-cache

DISABLE_OVERSCAN
1
GPU_MEM_1024
512

I have dd'ed the image to an SD card increased the sdb2 partition to the max size and 
powered up the rpi. Everything looks fine to start with, as it displays the four 
raspberrys in the top left, then the white "Yocto Project" splash screen 
complete with small blue dot to the side appears, the progress bar moves across to 100 
percent, then the screen turns black with a white

cursor in the middle and it appears to freeze with only a very dim one second flash of 
the "act" led.



I have then connected the 7" touchscreen and apart from the added multicolored 
square at the very beginning I get the exact same boot up problem, hangs on the 
black screen with white cursor (good to see its all resized correctly for the TfT 
through!!)


Before adding the packagegroup-core-x11-base and packagegroup-lxde-base I 
successfully copied over and ran the rpi-basic-image with no problem, ending up 
with a usable console.


Looking for any help here, I'm thinking I've missed adding a package, or some 
type of local.conf instruction. any suggestions would be 
appreciated.


Can you send the content of /var/log/Xorg.log file ?



--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

2017-03-09 Thread Yusuke Mitsuki 
Hello Steve

Would you try to other HDMI display such as PC monitor.

I suspects two points as follows.

* You enabled KMS(such as vc4graphics in MACHINE_FEATURE)
* Your display has not EDID.

If your HDMI settings in config.txt such as follows. There is a high
possibility that your HDMI display does not have EDID.

```
hdmi_group=2
hdmi_mode=87
```

When your display has not EDID, KMS will fail in initalization.
In such case, you have to create EDID file manually.

I hope this helps.


2017/03/10 14:43 "Gary Thomas" :

> On 2017-03-10 01:55, Steve Plant wrote:
>
>> OK, I have spent the last day googling my heart out trying to find the
>> Xorg.log file without any luck.
>>
>>
>> The problem is that due to the rpi hanging on boot, the only way I can
>> access the SD card to look for the file is place
>> it in a USB SD card reader and use my VirtualBox based Debian to "ls"
>> directores etc.
>>
>> Having established that there is no file located at /var/log/Xorg.log
>> (there isn't a log directory) but there is a
>> symbolic link in the var directory - goes nowhere.
>>
>>
>> After goggling I discovered that the file could also be in the
>> ~/.local/share/xorg/Xorg.0.log, however if I try to look
>> there I get "permission denied" and cannot seem to get to the root
>> directory of the card and I can't find a way around
>> this as I'm trying to access this directory through the USB card reader.
>>
>>
>> Looked everywhere with no answers, Is there anyone who could help me
>> here??
>>
>
> /var/log is on a volatile file system (i.e. it does not live on the SD
> card)
>
> If you can get into your board via SSH, you can copy the file and send it
>
> 
>> 
>> *From:* Khem Raj 
>> *Sent:* Wednesday, 8 March 2017 5:17 p.m.
>> *To:* Steve Plant
>> *Cc:* yocto@yoctoproject.org
>> *Subject:* Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
>>
>> On 17-03-08 12:40:51, Steve Plant wrote:
>>
>>> Hi All,
>>>
>>>
>>> Very new to all this linux world, and especially Yocto.
>>>
>>>
>>> I'm working on a embedded project at the moment using a raspberry pi2
>>> board.
>>>
>>>
>>> I have used toaster with Morty 2.2 to compile an image
>>> using"rpi-basic-image", to this I have added the following bitbake
>>> variables:
>>>
>>> Bitbake variables
>>>
>>> DISTRO
>>> poky
>>> DL_DIR
>>> /home/steve/poky/downloads
>>> IMAGE_FSTYPES
>>> ext3 jffs2 tar.bz2 rpi-sdimg
>>> IMAGE_INSTALL_append
>>> packagegroup-core-x11-base packagegroup-lxde-base connman
>>> PACKAGE_CLASSES
>>> package_rpm
>>> SSTATE_DIR
>>> /home/steve/poky/sstate-cache
>>>
>>> DISABLE_OVERSCAN
>>> 1
>>> GPU_MEM_1024
>>> 512
>>>
>>> I have dd'ed the image to an SD card increased the sdb2 partition to the
>>> max size and powered up the rpi. Everything looks fine to start with, as it
>>> displays the four raspberrys in the top left, then the white "Yocto
>>> Project" splash screen complete with small blue dot to the side appears,
>>> the progress bar moves across to 100 percent, then the screen turns black
>>> with a white
>>>
>> cursor in the middle and it appears to freeze with only a very dim one
>> second flash of the "act" led.
>>
>>>
>>>
>>> I have then connected the 7" touchscreen and apart from the added
>>> multicolored square at the very beginning I get the exact same boot up
>>> problem, hangs on the black screen with white cursor (good to see its all
>>> resized correctly for the TfT through!!)
>>>
>>>
>>> Before adding the packagegroup-core-x11-base and packagegroup-lxde-base
>>> I successfully copied over and ran the rpi-basic-image with no problem,
>>> ending up with a usable console.
>>>
>>>
>>> Looking for any help here, I'm thinking I've missed adding a package, or
>>> some type of local.conf instruction. any suggestions would be
>>> appreciated.
>>>
>>
>> Can you send the content of /var/log/Xorg.log file ?
>>
>
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> 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] Source Code provision without full git repository history

2017-03-09 Thread Waldvogel, Sebastian 
The point is that we want to deliver the Yocto build environment including the 
layers/recipes and the download directory (DL_DIR) to our customers as well.
The download directory shall contain an archive of the software modules / 
applications developed by my company. The customer has no access to the 
company's git repository.

We try to use as much as possible default functionality of Yocto and avoid 
developing additional delivery tools around Yocto.
A workaround would be manual extraction of the generated tarballs (including 
full git repo) and creating a new archive with git archive containing only the 
source files of the desired git revision.
In addition the SRC_URI of the related recipe need to be overwritten  by an 
.bbappend pointing to the tarball instead of the company git repo.

My favorite solution would be an additional attribute in the SRC_URI to control 
the behavior of the mirror tarball generation. E.g. SRC_URI = " 
git://git.company.url;nogithistory=1"

Best regards
Sebastian

>-Original Message-
>From: Daniel. [mailto:danielhi...@gmail.com]
>Sent: Thursday, March 09, 2017 5:28 PM
>To: Khem Raj
>Cc: Waldvogel, Sebastian; yocto@yoctoproject.org
>Subject: Re: [yocto] Source Code provision without full git repository history
>
>I'm not trying to be simplistic here, but, why not package the source
>releases to a tarball (with git archive or somthing) and provide it
>through a FTP server?
>
>Regards,
>
>2017-03-09 11:29 GMT-03:00 Khem Raj :
>>
>> On Thu, Mar 9, 2017 at 5:02 AM Waldvogel, Sebastian
>>  wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> I am searching for a way in Yocto/BitBake to extract the source codes of
>>> the software applications developed by my company for delivery to our
>>> customers.
>>>
>>> The source codes shall be delivered as archive containing only the source
>>> files without the whole git repository history.
>>>
>>>
>>>
>>> Setup is that we have own Yocto layers/recipes referencing the company
>>> internal git repository (SRC_URI=”git://git.company.url”) and the concrete
>>> SRCREV to be used. Basic idea was to use the option
>>> BB_GENERATE_MIRROR_TARBALLS = "1" which generates an archive file
>with the
>>> application source code. Unfortunately the generated tarball contains the
>>> full bare cloned git repository with full history and not only the source
>>> files of the concrete SRCREV.
>>>
>>>
>>>
>>> As alternative I tried to use the archiver class. The generated tarballs
>>> contains the concrete source files but in addition the full git repository
>>> with history is contained too.
>>
>>
>> I am not sure if it is intended to keep SCM history though you might want to
>> file a bug
>>>
>>>
>>>
>>> Does anyone has an idea how to extract the concrete source files without
>>> git repository and history?
>>>
>>>
>>>
>>> Thank you very much for your help
>>>
>>> Sebastian Waldvogel
>>>
>>>
>>>
>>>
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
>--
>“If you're going to try, go all the way. Otherwise, don't even start. ..."
>  Charles Bukowski
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto