Re: [yocto] [PATCH] Allow specifying subdir for rootfs when using wic -e

[Leonardo Sandoval]

wic stuff goes into the openembededde-core mailing list. in fact, most files 
under the scripts folder goes into the latter.

On Fri, 17 Nov 2017 17:19:48 +0100
Volker Vogelhuber  wrote:

> ---
>  scripts/lib/wic/ksparser.py  | 1 +
>  scripts/lib/wic/partition.py | 1 +
>  scripts/lib/wic/plugins/source/rootfs.py | 7 ---
>  3 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
> index 99b66eebc5..a9e07fcd2f 100644
> --- a/scripts/lib/wic/ksparser.py
> +++ b/scripts/lib/wic/ksparser.py
> @@ -146,6 +146,7 @@ class KickStart():
>  part.add_argument("--overhead-factor", type=overheadtype)
>  part.add_argument('--part-type')
>  part.add_argument('--rootfs-dir')
> +part.add_argument('--rootfs-subdir')
>  
>  # --size and --fixed-size cannot be specified together; options
>  # extra-space and --overhead-factor should also raise a parser
> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> index b623bb9e6d..b42529ce48 100644
> --- a/scripts/lib/wic/partition.py
> +++ b/scripts/lib/wic/partition.py
> @@ -53,6 +53,7 @@ class Partition():
>  self.overhead_factor = args.overhead_factor
>  self.part_type = args.part_type
>  self.rootfs_dir = args.rootfs_dir
> +self.rootfs_subdir = args.rootfs_subdir
>  self.size = args.size
>  self.fixed_size = args.fixed_size
>  self.source = args.source
> diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
> b/scripts/lib/wic/plugins/source/rootfs.py
> index aec720fb22..8dcf5a2872 100644
> --- a/scripts/lib/wic/plugins/source/rootfs.py
> +++ b/scripts/lib/wic/plugins/source/rootfs.py
> @@ -83,7 +83,7 @@ class RootfsPlugin(SourcePlugin):
>  
>  part.rootfs_dir = cls.__get_rootfs_dir(rootfs_dir)
>  
> -new_rootfs = None
> +new_rootfs = part.rootfs_dir
>  # Handle excluded paths.
>  if part.exclude_path is not None:
>  # We need a new rootfs directory we can delete files from. Copy 
> to
> @@ -121,6 +121,7 @@ class RootfsPlugin(SourcePlugin):
>  else:
>  # Delete whole directory.
>  shutil.rmtree(full_path)
> -
> +if not part.rootfs_subdir is None:
> +new_rootfs = os.path.join(new_rootfs, part.rootfs_subdir)
>  part.prepare_rootfs(cr_workdir, oe_builddir,
> -new_rootfs or part.rootfs_dir, native_sysroot)
> +new_rootfs, native_sysroot)
> -- 
> 2.11.0
> 
> -- 
> ___
> 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] [PATCH v4 1/3] image.bbclass: add prohibited-paths QA test

[Leonardo Sandoval]

isn't it this class meta/classes/insane.bbclass for this type of checks?


On Thu, 16 Nov 2017 15:05:56 +
Martyn Welch  wrote:

> Sometimes we wish to ensure that files or directories are not installed
> somewhere that may prove detrimental to the operation of the system. For
> example, this may be the case if files are placed in a directory that is
> utilised as a mount point at run time, thus making them inaccessible once
> when the mount point is being utilised.
> 
> Implement the prohibited paths QA test, which enables such locations to be
> specified in a "IMAGE_QA_PROHIBITED_PATHS" variable. This implementation
> allows for a colon separated list of paths to be provided. Shell style
> wildcards can be used.
> 
> Signed-off-by: Fabien Lahoudere 
> Signed-off-by: Martyn Welch 
> ---
> Changes since v1:
>  - Correcting author and SOB.
> 
> Changes since v2:
>  - Reimplemented as image rather than package level QA test.
>  - Changed variable from PROHIBITED_PATH to PROHIBITED_PATHS to better
>reflect its use.
> 
> Changes since v3:
>  - Rename variable to IMAGE_QA_PROHIBITED_PATHS.
>  - Use str.startswith().
>  - Simplify if statement.
> 
>  meta/classes/image.bbclass | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index d93de02..9053ce3 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -296,6 +296,26 @@ python do_image_complete_setscene () {
>  }
>  addtask do_image_complete_setscene
>  
> +python image_check_prohibited_paths () {
> +import glob
> +from oe.utils import ImageQAFailed
> +
> +rootfs = d.getVar('IMAGE_ROOTFS')
> +
> +path = (d.getVar('IMAGE_QA_PROHIBITED_PATHS') or "")
> +if path != "":
> +for p in path.split(':'):
> +if not p.startswith('/'):
> +raise ImageQAFailed("IMAGE_QA_PROHIBITED_PATHS \"%s\" must 
> be an absolute path" % p, image_check_prohibited_paths)
> +
> +match = glob.glob("%s%s" % (rootfs, p))
> +if match:
> +loc = ", ".join(item.replace(rootfs, '') for item in match)
> +raise ImageQAFailed("Match(es) for IMAGE_QA_PROHIBITED_PATHS 
> \"%s\": %s" % (p, loc), image_check_prohibited_paths)
> +}
> +
> +IMAGE_QA_COMMANDS += "image_check_prohibited_paths"
> +
>  # Add image-level QA/sanity checks to IMAGE_QA_COMMANDS
>  #
>  # IMAGE_QA_COMMANDS += " \
> -- 
> 2.1.4
> 
> -- 
> ___
> 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] Detecting all AUTOREV usages in a build, for reproducible stable production builds.

[Leonardo Sandoval]

On Thu, 16 Nov 2017 05:06:30 -0500
Paul Knopf  wrote:

> I want to store/fix AUTOREV values for production builds. I saw
> BB_CACHE_POLICY, but the format (sqllite) isn't something that can be
> checked in.
> 
> Let's say I have an image:
> 
> bitbake my-image
> 
> How do I detect any dependency that is using AUTOREV?
>


would this tool be useful for your needs? I do not fully grasp what you want to 
do.



You can use the buildhistory-collect-srcrevs command with the -a option to 
collect the stored SRCREV values from build history and report them in a format 
suitable for use in global
configuration (e.g., local.conf or a distro include file) to override floating 
AUTOREV values to a fixed set of revisions. Here is some example output from 
this command: 


 $ buildhistory-collect-srcrevs -a
 # i586-poky-linux
 SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
 SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
 SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
 SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
 # x86_64-linux
 SRCREV_pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa"
 SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
 SRCREV_pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11"
 SRCREV_glibc_pn-cross-localedef-native = 
"b8079dd0d360648e4e8de48656c5c38972621072"
 SRCREV_localedef_pn-cross-localedef-native = 
"c833367348d39dad7ba018990bfdaffaec8e9ed3"
 SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
 SRCREV_pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a"
 SRCREV_pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
 SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
 # qemux86-poky-linux
 SRCREV_machine_pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
 SRCREV_meta_pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f"
 # all-poky-linux
 SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"

Note
-




> I'd like to generate a dynamic.conf file that fixes the SRCREV values for
> relevant packages.
> 
> I guess I could do a normal build, then read the sqllite database, and
> generate a .conf from it. Does this sound feasible?
> 
> Any other strategies?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Bitbake fails when enabling tools-testapps

[Leonardo Sandoval]

On Sun, 12 Nov 2017 01:18:45 -0700
Chris Hughes <89dra...@gmail.com> wrote:

> Hoping this is the right place to get help with the following issue.
> 
> I'm using bitbake to build a custom image of the intel-aero / yocto sources.
> 

Make sure all layer dependencies are included into the conf/bblayers.conf file. 
There must be at least one recipe that either implicity (by default,  a recipe 
provides itself with the same name) or explicity (with PROVIDES) , otherwise 
you see what you mentioned.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can I force gstreamer into specific version with my image ?

[Leonardo Sandoval]

On Sun, 12 Nov 2017 11:59:32 +0200
Ran Shalit  wrote:

> hELLO,
> 
> For some reason my image is installed with gstreamer 1.6, and I don't
> understnad why the image (fsl-image-qt5) prefer 1.6.
> Is there a way to force gsreamer specific version (1.8.2) ? 

There is a specific varible which you can use to point to a specific PV, check

http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PREFERRED_VERSION

Just make sure you have the 1.8.2 recipe in your layer stack.

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

Re: [yocto] yocto documentation: no content, no PDF?

[Leonardo Sandoval]

On Wed, 8 Nov 2017 16:30:39 +
"Burton, Ross"  wrote:

> On 8 November 2017 at 15:41, Jerry Lian  wrote:
> 
> > Just wondering:
> > * As an active project, why yocto documentation does not provide a content
> > (better be clickable)?
> >  
> 
> The megamanual (Complete Documentation) doesn't have a top-level table of
> contents as that basically exists to search globally.  The real docs (such
> as Tasks Manual) have a top level table of contents.
> 
> * Or PDF format for easy printing.
> >  

Try running

make pdf DOC=ref-manual


(then drink so coffee and wait) After it, the pdf manual is there. There are 
other manuals as well, this is just an example cmd.

Leo

> 
> That would be massive.  The source is in git as docbook so it's fairly
> simple to generate a PDF.



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

Re: [yocto] Layer index not updated

[Leonardo Sandoval]

On Thu, 9 Nov 2017 09:36:26 +0100
Andreas Müller  wrote:

> Hi,
> 
> did not find any heads up here so: Layer index stopped updating ~1,5 month.
> Low priority - this is just notification & thanks in advance for taking
> care :)

Do you mind filing a bug so it can be tracked better?

[1] https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Layer%20Index

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

Re: [yocto] [PATCH v2] devtool: add clean command

[Leonardo Sandoval]

Josef, as Paul mentioned, this is a openembedded-core patch and should 
be sent to the proper mailing list.


Great that you included the reason of this patch on the description, 
otherwise I saw no real benefit from this change.


Leo



On Thu, Oct 26, 2017 at 2:22 AM, Josef Holzmayr 
 wrote:

Add an idiomatic way to devtool to clean a recipe. When using devtool
in the context of an eSDK there is no direct access to bitbake.
This command exposes the bitbake clean facility through devtool,
keeping the idiomatic interface and configurability.

Signed-off-by: Josef Holzmayr 
---
 scripts/lib/devtool/clean.py | 48 


 1 file changed, 48 insertions(+)
 create mode 100644 scripts/lib/devtool/clean.py

diff --git a/scripts/lib/devtool/clean.py 
b/scripts/lib/devtool/clean.py

new file mode 100644
index 00..473c30f366
--- /dev/null
+++ b/scripts/lib/devtool/clean.py
@@ -0,0 +1,48 @@
+# Development tool - clean command plugin
+#
+# Copyright (C) 2014-2015 Intel Corporation
+#   2017 R-S-I Elektrotechnik GmbH & Co. KG
+#
+# This program is free software; you can redistribute it and/or 
modify

+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License 
along
+# with this program; if not, write to the Free Software Foundation, 
Inc.,

+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+"""Devtool clean plugin"""
+
+import bb
+from devtool import exec_build_env_command, check_workspace_recipe
+
+def _get_clean_tasks(config):
+tasks = config.get('Clean', 'clean_task', 'clean').split(',')
+return ['do_%s' % task.strip() for task in tasks]
+
+def clean(args, config, basepath, workspace):
+"""Entry point for the devtool 'clean' subcommand"""
+
+build_tasks = _get_clean_tasks(config)
+try:
+bbargs = []
+for task in build_tasks:
+bbargs.append('%s:%s' % (args.recipename, task))
+exec_build_env_command(config.init_path, basepath, 'bitbake 
%s' % ' '.join(bbargs), watch=True)

+except bb.process.ExecutionError as e:
+# We've already seen the output since watch=True, so just 
ensure we return something to the user

+return e.exitcode
+
+return 0
+
+def register_commands(subparsers, context):
+"""Register devtool subcommands from this plugin"""
+parser_build = subparsers.add_parser('clean', help='Clean a 
recipe',
+ description='Cleans the 
specified recipe using bitbake',

+ group='working', order=50)
+parser_build.add_argument('recipename', help='Recipe to clean')
+parser_build.set_defaults(func=clean)
--
2.14.3


--
_
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschftsfhrer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

--
___
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] bbappend - FILESEXTRAPATHS

[Leonardo Sandoval]

On Fri, 20 Oct 2017 13:30:06 +
"Koehler, Yannick" <yannick.koeh...@hpe.com> wrote:

> Hi,
> 
>  
> 
> I have been using Yocto for over 2 years now, and whenever I create a new
> bbappend file, I always have to remember that FILESEXTRAPATHS variable,
> often typing it wrong, EXTRAFILESPATHS or FILEEXTRAPATHS or FILESEXTRAPATH,
> etc.
> 
>  
> 
> I did a quick check on my setup and on 102 bbappend recipe found, there are
> 73 that uses the FILESEXTRAPATHS variable, so that is around 71% of them.  
> 
>  
> 
> I was wondering if the team would enhance the user/dev experience here and
> modify bitbake behavior as to not require this variable and be able to
> "override" any FILESPATH that already exists with the bbappend location.  So
> that for example the FILESPATH "files" would be looked up in the bbappend
> folder location before the initial bb recipe folder location automatically
> without having to manually enter a FILESEXTRAPATHS statement.

One easy way to avoid this error is to place the FILESEXTRAPATHS variable 
inside a custom bbclass them inherit it from the recipe, at least it is less 
prone to typos. We do not want to force users to place patches inside a 
particular folder (policy), instead the system offer a mechanism to place these 
any place you want (other recipes choose PN, for example)

> 
>  
> 
> Or alternatively, a script or command to create an initial skeleton bbappend
> with the initial .bb in comment 
> 
>  
> 
>bbappend mylayer recipename.bb
> 
># Create a file under mylayer/recipes-*/*.bbappend (using %
> for version when not specified on cmd line) with the original .bb in comment
> and a section containing FILESEXTRAPATHS
> 

Right, I think there is no tool to create bbappends from the command line.

Anyway, feel free to file a bug (bugzilla.yoctoproject.org) with your 
enhancement.


>  
> 
> I think this would greatly help when creating those files.
> 
>  
> 
> --
> 
> Yannick Koehler
> 
> HPE Aruba
> 


-- 
Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 0/1] Send email notification on publication

[Leonardo Sandoval]

On Thu, 19 Oct 2017 14:27:07 -0700
Amanda Brindle <amanda.r.brin...@intel.com> wrote:

Based on the subject, if this a v2 series?


> Before, if there were multiple maintainers, this sent an individual email to 
> each maintainer. Now, this will send one email to all maintainers. The email 
> will also provide instructions for how the maintainer can make changes to the 
> layer's index entry in the future.
> 
> The following changes since commit ad1aac4ea5d4f2b327f7bd9611aed13f7c31ff7e:
> 
>   Show note if layer branch hasn't been indexed (2017-10-04 13:49:00 +1300)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/layerindex-web 
> abrindle/email_notification_publication
>   
> http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=abrindle/email_notification_publication
> 
> Amanda Brindle (1):
>   Send email notification on publication
> 
>  layerindex/views.py  | 45 
> +++-
>  templates/layerindex/publishemail.txt|  9 ++
>  templates/layerindex/publishemailsubject.txt |  1 +
>  3 files changed, 54 insertions(+), 1 deletion(-)
>  create mode 100644 templates/layerindex/publishemail.txt
>  create mode 100644 templates/layerindex/publishemailsubject.txt
> 
> -- 
> 2.7.4
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


-- 
Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [AUH] Upgrade status: 2017-10-18

[Leonardo Sandoval]

On Wed, 18 Oct 2017 14:29:08 +0300
Alexander Kanavin <alexander.kana...@linux.intel.com> wrote:

> On 10/18/2017 02:08 PM, a...@auh.yoctoproject.org wrote:
> >  TOTAL: attempted=147 succeeded=25(17.01%) failed=122(82.99%)
> 
> With this kind of success rate, should we continue to run and develop 
> the thing?
> 
> I think it's better to just send notifications to maintainers without 
> attempting to update anything, as most of the time version updates need 
> manual rebasing of patches or other tweaks anyway.
> 
> I've submitted a small script to do just that:
> http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143510.html
> 
> Instead, I'd rather see RRS fixed/improved - lots of issues there, some 
> of them very old.

About the AUH/RSS, this is an important point to discuss on the 2.5 planning 
and the best way is to point those old bugs in this phase. 

In the upgrade area, 'devtool upgrade' helps a lot in the starting phase of the 
upgrade (rebasing patches old version into new version) but as you mentioned, 
upgrades are not as easy as changing the revisions and of course once it 
'builds', manual testing is needed, at least the basic stuff. 

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


-- 
Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding support for yum in a yocto image

[Leonardo Sandoval]

On Thu, 5 Oct 2017 11:30:33 -0700
Mark Hieber <hieb...@gmail.com> wrote:

> I am building a yocto image to run on a network device, and I need to have
> yum installed in the image. Is this even possible? I would also like to
> have the epel-release repository available in my image.

there is no yum recipe but you can install dnf, would that help?

> 
> Thanks,
> 
> Mark


-- 
Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: autotooler: generation of "configure.ac" and "Makefile.am" using Kconfig

[Leonardo Sandoval]

On Sat, 30 Sep 2017 16:49:09 +0200
Ulf Samuelsson  wrote:

> Have a need to convert a large number of libraries to use autotools.
> 

> I came up with the following idea:

I got poor experience in enabling autotools into a project but
have you ping the autotools community to discuss your approach? perhaps there
are already other approaches that may be reused for your needs.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [bitbake] Failed to launch bitbake image -u -g depexp on a Debian 9 host system ?

[Leonardo Sandoval]

"Burton, Ross"  writes:

> On 12 September 2017 at 08:56, Karim ATIKI 
> wrote:
>
>
> FATAL: Unable to import extension module "depexp" from bb.ui.
> Valid extension modules: knotty, ncurses or taskexp
>
>
> depexp was renamed to taskexp.

and the -u parameter is the one expecting a user interface, -g is just
for producing the dot files, so flip the parameters. Just tried on
debian 9 and worked as expected.


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

Re: [yocto] yocto layer dependencies

[Leonardo Sandoval]

ktreddy 70  writes:

> I am trying to set up yocto build environment for openlte, meta-sdr
> has most of the openlte depends
> I am getting following error when I try to build sdr, 
>
>
> /build$ bitbake sdr
> Loading cache: 100% |
> #
> ###| Time: 0:00:00
> Loaded 1642 entries from dependency cache.
> ERROR: ParseError at /home/ktreddy/zcu102/sources/poky/../
> meta-openembedded/meta-sdr/recipes-applications/gqrx/gqrx_git.bb:8:
> Could not inherit file classes/qt4x11.bbclass
>
>
> I do have meta-qt4 under meta-openembedded layer  as below.

at bblayers.conf, does BBLAYERS include the above full path of
meta-openembedded/meta-qt4? also, try placing the meta-qt4 at the same
level of meta-openembeded, because these are two independent
repositories (and if you run git clean -fd at meta-openmebeded, you do
not remove meta-qt4 by mistake :) )


>
> zcu102/sources$ ls meta-openembedded/meta-qt4/classes/
> qmake2.bbclass  qmake_base.bbclass  qt4e.bbclass  qt4x11.bbclass
>
>
> could you please help me on why am I getting this error ?
> How can I make one layer visible to another layer ?

Though BBLAYERS. Include any layer you want and depending on the
priority, bitbake will deal with the corresponding metadata (bbappends, etc.)

> Ex:  How can I make meta-sdr visible to openlte ? I mean how can I
> say to openlte that the dependency recipes are available under
> meta-sdr ?
>
> if new recipes are available for a layer how can I get those on to my
> build environment ?

basically the latter answer applies to this one.


>
> Thanks for your help.
>
> [no_pho] Click here to Reply or For
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] nightly-oe-selftest.conf: instruct to sign rpm packages serially

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>

Under high workloads, there are situations where the rpm file-chunk
signing fails due to lack of memory resouces, so indicate the
system to sign serially. The following log is what it has been
observed recently:

ERROR: bc-1.06-r3 do_package_write_rpm: Function failed: Failed to sign RPM 
packages: gpg: signing failed: Cannot allocate memory
gpg: signing failed: Cannot allocate memory
error: gpg exec failed (2)

Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>
---
 buildset-config.controller/nightly-oe-selftest.conf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/buildset-config.controller/nightly-oe-selftest.conf 
b/buildset-config.controller/nightly-oe-selftest.conf
index 8704946d9..1237f9b73 100644
--- a/buildset-config.controller/nightly-oe-selftest.conf
+++ b/buildset-config.controller/nightly-oe-selftest.conf
@@ -10,7 +10,8 @@ steps: [{'SetDest':{}},
 {'GetDistroVersion' : {'distro': 'poky'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64',
 'distro': 'poky', 'packages': 'rpm',
-'buildhistory' : False, 'prserv': False}},
+'buildhistory' : False, 'prserv': False,
+'RPM_GPG_SIGN_CHUNK' : 1}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'BuildImages': {'images': 'SELFTEST-PRE'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto', 'layerdirs': 
['meta-selftest']}},
-- 
2.12.3

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

Re: [yocto] ERROR: Unable to connect to bitbake server, or start one

[Leonardo Sandoval]

On Thu, 2017-08-24 at 18:24 +0300, Gera Pesikoff wrote:
> Hi
> I started to study bitbake and decided to repeat the BitBake Hello
> World from the manual
> (http://www.yoctoproject.org/docs/2.3.1/bitbake-user-manual/bitbake-user-manual.html#bitbake-hello-world).
> I do everything according to the instructions, but when I run the
> bitbake command, I get the following output:
> 
> NOTE: Retrying server connection... (Traceback (most recent call
> last):
>   File "/home/leonid/test/bitbake/lib/bb/main.py", line 432, in
> setup_bitbake
> topdir, lock = lockBitbake()
>   File "/home/leonid/test/bitbake/lib/bb/main.py", line 484, in
> lockBitbake
> lockfile = topdir + "/bitbake.lock"
> TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
> )
> 
> This is repeated five times, and at the end:
> 
> ERROR: Unable to connect to bitbake server, or start one

Are you running bitbake from the build folder (TOPDIR)?
> 
> Could someone please tell me what the problem is and what I can do
> about it?
> I'm using Kubuntu 17.04 and clear Ubuntu 17.04. BitBake Build Tool
> Core version 1.35.0
> 
> -- 
> ___
> 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] some issues with current poky master

[Leonardo Sandoval]

On Fri, 2017-08-18 at 01:34 +0200, Markus Volk wrote:
>  
> > After sucessful build of the Image, my .iso has 38MB in size and seems to 
> > be missing the entire rootfs
> > The created hddimg has the right size of 4,3GB, but when i write it onto an 
> > usb drive (tried dd and gnome-disk-utility) it ends up with a big /boot 
> > partiton containing only the boot files
> > 
> 
> I still do not know if this is a homemade one, but i saw inside the 
> do_bootimg log that isolevel 3 was missing for mkisofs because the rootfs is 
> too big without.
> 
> For me this here inside image-live.bbclass fails for some reason:
> 
>   # Check the size of ${ISODIR}/rootfs.img, use mkisofs -iso-level 3
>   # when it exceeds 3.8GB, the specification is 4G - 1 bytes, we need
>   # leave a few space for other files.
>   mkisofs_iso_level=""
> 
> if [ -n "${ROOTFS}" ] && [ -s "${ROOTFS}" ]; then
>   rootfs_img_size=`stat -c '%s' ${ISODIR}/rootfs.img`
>   # 4080218931 = 3.8 * 1024 * 1024 * 1024
>   if [ $rootfs_img_size -gt 4080218931 ]; then
>   bbnote "${ISODIR}/rootfs.img execeeds 3.8GB, using 
> '-iso-level 3' for mkisofs"
>   mkisofs_iso_level="-iso-level 3"
>   fi
>   fi
> 

not really sure what you have changed in the code (better to send a diff
snippet), so proposed your change to the oe-core.

> 
> 
> hard coding mkisofs_iso_level to
> 
>   mkisofs_iso_level="-iso-level 3"
> 
> fixes this up
> -- 
> Markus Volk 


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

Re: [yocto] NotImplementedError from sanity check

[Leonardo Sandoval]

On Wed, 2017-08-16 at 14:42 +, Vuille, Martin (Martin) wrote:
> In the process of transitioning from Fido to Morty.
> 
> In the past, when sanity detected a version mismatch with some of
> the configuration files (e.g., local.conf, bblayers.conf,) an error message
> was displayed.
> 
> Now, we see the below, which I do not find very informative or helpful.
> 
> Is that a bug or intentional? Is there a way to get back the error message?
> 

are you reusing the same build folder? if yes, try a separate folder
instead.




> MV
> 
> ERROR: Execution of event handler 'config_reparse_eventhandler' failed
> Traceback (most recent call last):
>   File "/home/platform/Workspace/dspgbase/poky/meta/classes/sanity.bbclass", 
> line 1006, in config_reparse_eventhandler(e= 0x7fc99cba1b00>):
>  python config_reparse_eventhandler() {
> >sanity_check_conffiles(e.data)
>  }
>   File "/home/platform/Workspace/dspgbase/poky/meta/classes/sanity.bbclass", 
> line 568, in sanity_check_conffiles(d= 0x7fc99d00f198>):
>  except NotImplementedError as e:
> >bb.fatal(e)
>  d.setVar("BB_INVALIDCONF", True)
>   File "/home/platform/Workspace/dspgbase/poky/bitbake/lib/bb/__init__.py", 
> line 103, in fatal:
>  def fatal(*args, **kwargs):
> >mainlogger.critical(''.join(args), extra=kwargs)
>  raise BBHandledException()
> TypeError: sequence item 0: expected str instance, NotImplementedError found
> 
> ERROR: Error parsing configuration files
> Traceback (most recent call last):
>   File "/home/platform/Workspace/dspgbase/poky/bitbake/lib/bb/event.py", line 
> 124, in fire_class_handlers(event= 0x7fc99cba1b00>, d=):
>  continue
> >execute_handler(name, handler, event, d)
> 
>   File "/home/platform/Workspace/dspgbase/poky/bitbake/lib/bb/event.py", line 
> 96, in execute_handler(name='config_reparse_eventhandler', handler= config_reparse_eventhandler at 0x7fc99cbd4a60>, event= object at 0x7fc99cba1b00>, d= 0x7fc99d00f198>):
>  try:
> >ret = handler(event)
>  except (bb.parse.SkipRecipe, bb.BBHandledException):
>   File "/home/platform/Workspace/dspgbase/poky/meta/classes/sanity.bbclass", 
> line 1006, in config_reparse_eventhandler(e= 0x7fc99cba1b00>):
>  python config_reparse_eventhandler() {
> >sanity_check_conffiles(e.data)
>  }
>   File "/home/platform/Workspace/dspgbase/poky/meta/classes/sanity.bbclass", 
> line 568, in sanity_check_conffiles(d= 0x7fc99d00f198>):
>  except NotImplementedError as e:
> >bb.fatal(e)
>  d.setVar("BB_INVALIDCONF", True)
>   File "/home/platform/Workspace/dspgbase/poky/bitbake/lib/bb/__init__.py", 
> line 103, in fatal:
>  def fatal(*args, **kwargs):
> >mainlogger.critical(''.join(args), extra=kwargs)
>  raise BBHandledException()
> TypeError: sequence item 0: expected str instance, NotImplementedError found


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

Re: [yocto] layer.conf on openembedded-core ?

[Leonardo Sandoval]

On Tue, 2017-08-15 at 09:09 +0800, Riko wrote:
> Dear Team Yocto Members,
> 
> I continue compiling, and got :
> 
> ERROR: 
> /home/bianchi/poky/openembedded-core/meta/recipes-core/images/build-appliance-image_15.0.0.bb:
>  No IMAGE_CMD defined for IMAGE_FSTYPES entry 'wic.vmdk' - possibly invalid 
> type name or missing support class
> ERROR: Failed to parse
> recipe: 
> /home/bianchi/poky/openembedded-core/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> 

would be better if you start another thread with this issue. BTW, I just
built a build-appliance without any change at local.conf and all went
fine so you may have included something that you are not referring to
(IMAGE_FILES?)



> How can I fix it ?
> 
> regards,
> 
> Riko
> 
> 
> 
> On 14/08/17 23:56, Christopher Larson wrote:
> 
> > The openembedded-core root isn’t a layer, openembedded-core/meta is.
> > 
> > On Mon, Aug 14, 2017 at 8:49 AM, Leonardo Sandoval
> > <leonardo.sandoval.gonza...@linux.intel.com> wrote:
> > On Mon, 2017-08-14 at 15:11 +0800, Riko wrote:
> > > Dear Yocto Members,
> > >
> > > How can I find this file ?
> > 
> > 
> > this is a pretty general question. are you running bitbake
> > from the
> > build directory? double check your conf/bblayers.conf and
> > make sure
> > paths there are pointing correctly.
> > 
> > 
> > >
> > > ==
> > >
> > > ERROR: Unable to parse
> > > /home/bianchi/poky/openembedded-core/conf/layer.conf:
> > [Errno 2] file
> > > /home/bianchi/poky/openembedded-core/conf/layer.conf not
> > found
> > >
> > >
> > > Thanks,
> > >
> > > Riko
> > >
> > 
> > 
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> > 
> > 
> > 
> > 
> > 
> > -- 
> > Christopher Larson
> > kergoth at gmail dot com
> > Founder - BitBake, OpenEmbedded, OpenZaurus
> > Senior Software Engineer, Mentor Graphics
> 


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

Re: [yocto] layer.conf on openembedded-core ?

[Leonardo Sandoval]

On Mon, 2017-08-14 at 15:11 +0800, Riko wrote:
> Dear Yocto Members,
> 
> How can I find this file ?


this is a pretty general question. are you running bitbake from the
build directory? double check your conf/bblayers.conf and make sure
paths there are pointing correctly.


> 
> ==
> 
> ERROR: Unable to parse 
> /home/bianchi/poky/openembedded-core/conf/layer.conf: [Errno 2] file 
> /home/bianchi/poky/openembedded-core/conf/layer.conf not found
> 
> 
> Thanks,
> 
> Riko
> 


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

Re: [yocto] Error while integrating PyPy module in Yocto (Jethro branch) build.

[Leonardo Sandoval]

On Wed, 2017-07-19 at 12:39 +, JAYMIN DABHI wrote:
> Hi All,
> 
> I am trying to integrate PyPy in my current Yocto (Jethro branch)
> build for my i.MX6UL processor based development board. The board has
> "armv7a" (cortexa7) architecture. 
> 
> I am using "meta-pypy" layer from here and inherit the pypy package in
> my local.conf.
> But, it gives me error during bitbaking. I am bitbaking the
> "core-image-base".
> The error is as below :
> ERROR: Fetcher failure: Unable to find file 
> file://pypy-4.0.1-cortexa7.tar.bz2 anywhere.
> I think, it can't find the package "pypy-4.0.1-cortexa7.tar.bz2" in
> pypy directory.


Make sure the is the proper ARCH tarball in the recipes/pypy/pypy
folder. If not there, then the layer does not support that architecture.

leo
> 
> What should be the other possible reason? and How it can be solved?
> 
> 
> Suggestions are welcome.
> 
> 
> Thanks,
> -
> JAYMIN
> 
> 
> -- 
> ___
> 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] Proper way to rename a downloaded file in SRC_URI

[Leonardo Sandoval]

On Tue, 2017-07-18 at 09:40 -0700, Jimi Damon wrote:
> I have a recipe that I built for building jzmq, however one of the
> issues I have is with the naming of the release files from the github
> site.
> 
> Unlike czmq which has downloads ( zip and tar.gz ) that are named
> czmq-${PV}.tar.gz, the downloads from jzmq are just called v
> ${PV}.tar.gz. 
> 
> 
> 
> How can I rename this file upon download so that the filename is in
> fact unique to this package ? 

at the SRC_URI value, you may use the downloadfilename standard option.

http://www.yoctoproject.org/docs/2.3/mega-manual/mega-manual.html#var-SRC_URI



> 
> 
> I can definitely see that the file v3.1.0.tar.gz in my downloads
> directory is not unique and could conflict with another package that
> is similarly named for its releases.
> 
> 
> My workaround right now is to use the specific SHA string and use the
> git:// protocol, but it would be a bit easier to just use the released
> version and change the filename for saving it in downloads.
> 
> 
> 
> 
> -- 
> ___
> 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] [PATCH] fetch2/__init_.py removed bb.error which caused exit code 1

[Leonardo Sandoval]

you need to send it to openembedde-core mailing list and use
git-send-email to submit your patch. More info on the link below


http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

Leo

On Tue, 2017-07-18 at 15:43 +0200, Paulo Neves wrote:
> http://lists.openembedded.org/pipermail/openembedded-core/2012-September/069448.html
> 
> Workaround to avoid exit 1 status.
> 
> The reason it happens is that there are 2 missions
> the state cache uses the normal fetcher to get
> its's stuff and it is acceptable for it to fail.
> On the other hand it is not acceptable for fetch
> to fail.
> 
> In it's code the state cache code catches the exception that the
> fetcher launches and discards. The problem
> is that before this exception is caught it prints
> a bb.error and bb.error prints something and
> continues on like no problem happened.  but marks
> the exit code as 1 which is a disaster.
> -- 
> ___
> 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] [PATCH] Added missing CPPFLAGS/CFLAGS/LDFLAGS in sample recipe for morty branch

[Leonardo Sandoval]

On Mon, 2017-07-17 at 15:30 +0100, Burton, Ross wrote:
> 
> On 17 July 2017 at 15:04, Leonardo Sandoval
> <leonardo.sandoval.gonza...@linux.intel.com> wrote:
> master has the second line (LDFLAGS) but not the first one
> (CPPFLAGS and
> CFLAGS) so the problem may also be present on master. Would
> you mind
> checking this and sent patches to the poky mailing list?
> 
> 
> The GNU_HASH warning is triggered by ignoring LDFLAGS.

Got it, so definitely LDFLAGS var is missing, not sure if the rest are
necessary for this simple hello world recipe.
Leo
> 
> 
> Ross


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

Re: [yocto] [PATCH] Added missing CPPFLAGS/CFLAGS/LDFLAGS in sample recipe for morty branch

[Leonardo Sandoval]

On Mon, 2017-07-17 at 10:00 +0200, Pierre FICHEUX wrote:
> This problem causes the following error :
> 
> ERROR: example-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary
> 
> 
> Signed-off-by: Pierre FICHEUX 
> ---
>  .../target/arch/layer/recipes-example/example/example-recipe-0.1.bb| 3 
> ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
>  
> b/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
> index 5fbf594..2c478ad 100644
> --- 
> a/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
> +++ 
> b/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
> @@ -14,7 +14,8 @@ SRC_URI = "file://helloworld.c"
>  S = "${WORKDIR}"
>  
>  do_compile() {
> -  ${CC} helloworld.c -o helloworld
> +  ${CC} ${CPPFLAGS} ${CFLAGS} -c helloworld.c -o helloworld.o
> +  ${CC} ${LDFLAGS} helloworld.o -o helloworld

master has the second line (LDFLAGS) but not the first one (CPPFLAGS and
CFLAGS) so the problem may also be present on master. Would you mind
checking this and sent patches to the poky mailing list?

Leo

>  }
>  
>  do_install() {
> -- 
> 2.7.4
> 


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

Re: [yocto] Yocto Optimization query

[Leonardo Sandoval]

On Tue, 2017-06-27 at 17:19 +0200, Ayoub Zaki wrote:
> Hi Prasoon,
> 
> I wrote a Howto on reducing start-up time in yocto :
> 
> https://embexus.com/2017/05/16/embedded-linux-fast-boot-techniques/
> 
> Maybe you can some useful informations on the topic.
> 
> 
> 
> On 27.06.2017 08:09, Prasoon Kumar wrote:
> 
> > Hi, 
> > 
> > 
> > I am trying to optimise the boot time in yocto. I need some
> > suggestions on how to optimise the boot time and different ways of
> > doing it.
> > 

This is a hard topic because there are many approaches, but the first
task to do is to measure current boot. In the past, I have found this
page and its links quite useful:

http://elinux.org/Boot_Time

> > 
> > Thanks
> > Prasoon
> > 
> > 
> Cheers, 
> -- 
> 
> Ayoub Zaki
> 
> ayoub.z...@embexus.com
> Mobile: +49(0)176-62901545
> Skype: ayoub.zaki_2
> https://embexus.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

Re: [yocto] useradd and one sysroot per recipe in pyro

[Leonardo Sandoval]

On Wed, 2017-06-14 at 18:12 +0200, Laurent Gauthier wrote:
> Hi Christian,
> 
> In pyro the creation of users and group (using the useradd class) is
> done during the package pre-installation.
> 
> So my best guess is that you could move the owner/group change in the
> package post-installation as follows:
> 
> do_install () {
> (…)
> install -d ${D}${sysconfdir}/myappl
> install -d ${D}${localstatedir}/lib/myappl
> }
> 
> pkg_postinst_${PN} () {
> chown -R myuser:mygroup ${D}${sysconfdir}/myappl
> chown -R myuser:mygroup ${D}${localstatedir}/lib/myappl
> }
> 
> I hope this helps.

also, at the oe-core repo, you can find a recipe example


meta-skeleton/recipes-skeleton/useradd/useradd-example.bb


> 
> Laurent.
> 
> On Wed, Jun 14, 2017 at 5:57 PM, Andersen, Christian
>  wrote:
> > Any ideas how to use „useradd“ bbclass with pyro?
> >
> > If I move useradd to my recipe my-appl.bb, it works. But there are more
> > recipes depending on the added user, so I want to add this user in a
> > base-recipe and just depend on it using (DEPENDS/RDEPENDS).
> >
> > Regards
> > Christian
> >
> >
> >
> > Von: Andersen, Christian
> > Gesendet: Dienstag, 13. Juni 2017 18:10
> > An: 'yocto@yoctoproject.org' 
> > Betreff: useradd and one sysroot per recipe in pyro
> >
> >
> >
> > Hello,
> >
> >
> >
> > currently I am trying the newest Yocto release (pyro). It seems I have a
> > problem with useradd and the new concept of one sysroot per recipe.
> >
> >
> >
> > I have a base recipe (let’s call it my-base.bb) which inherits useradd and
> > creates a new user (let’s call him myuser):
> >
> >
> >
> > inherit useradd
> >
> >
> >
> > USERADD_PACKAGES = "${PN}"
> >
> > USERADD_PARAM_${PN} = " \
> >
> > --uid 1200 \
> >
> > --gid 1200 \
> >
> > --system \
> >
> > --shell /bin/bash \
> >
> > --create-home \
> >
> > --home-dir /home/myuser \
> >
> > --groups mygroup,video,input \
> >
> > myuser"
> >
> > GROUPADD_PARAM_${PN} = "-g 1200 mygroup"
> >
> >
> >
> > do_install () {
> >
> > install -d ${D}/home/myuser
> >
> > chown -R myuser:mygroup ${D}/home/myuser
> >
> > }
> >
> >
> >
> > Other recipes depend on this base recipe (via DEPENDS and RDEPENDS), because
> > they require this user, e.g. in recipe my-appl.bb (in this case python only,
> > so no configure or compile):
> >
> >
> >
> > DEPENDS = "puck-base"
> >
> > RDEPENDS_${PN} = "puck-base python3-dbus python3-sqlite3 python3-netclient
> > python3-requests"
> >
> >
> >
> > do_configure[noexec] = "1"
> >
> > do_compile[noexec] = "1"
> >
> >
> >
> > do_install () {
> >
> > (…)
> >
> >
> >
> > install -d ${D}${sysconfdir}/myappl
> >
> > chown -R myuser:mygroup ${D}${sysconfdir}/myappl
> >
> >
> >
> > install -d ${D}${localstatedir}/lib/myappl
> >
> > chown -R myuser:mygroup ${D}${localstatedir}/lib/myappl
> >
> > }
> >
> >
> >
> > Unfortunately I get an error when building the recipe my-appl.bb
> >
> >
> >
> > | chown: invalid user: ‘myuser:mygroup’
> >
> > | WARNING: exit code 1 from a shell command.
> >
> > | ERROR: Function failed: do_install (log file is located at …)
> >
> > ERROR: Task (…/my-appl.bb:do_install) failed with exit code '1'
> >
> >
> >
> > In morty the user was created in the shared sysroot. But using pyro the user
> > is not created in the recipe-sysroot.
> >
> >
> >
> > What am I doing wrong and is there a way to solve this?
> >
> >
> >
> > Thanks in advance!
> >
> > Regards
> >
> > Christian
> >
> > KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn
> > HRB 3924 - USt-Id-Nr./Vat No.: DE 813742170
> > Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49 2351
> > 16-0 * Telefax: +49 2351 16-2400
> > Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-800 * Fax
> > +49 2331 8040-602
> > Geschäftsführung: Axel Zimmermann, Dipl.-Ing. Marwin Kinzl, Dipl.-Oec.
> > Andreas Kostal
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
> 
> 
> 
> -- 
> Laurent Gauthier
> Phone: +33 630 483 429
> http://soccasys.com


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

Re: [yocto] Preventing a package from building

[Leonardo Sandoval]

On Tue, 2017-06-13 at 11:32 -0700, Jimi Damon wrote:
> Hi,
> 
> 
> I tried using the PACKAGE_EXCLUDE = "chromium" in my local.conf file
> but I'm finding that my build it is still trying to build this
> package.
> 
is it on your image? at the end, this variable is to exclude the package
on the resulting image/rootfs.

> 
> Is there a way to prevent this build stage from occurring ? 
> 
> 
> 
> Thanks
> 
> 
> -- 
> ___
> 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] mkfifo: not found

[Leonardo Sandoval]

On Mon, 2017-06-12 at 15:01 +, Baumann, Michael wrote:
> Hello,
> 
> I upgraded from poky 2.1 to 2.3 and now I have an issue with mkfifo in a 
> do_install step. 
> The error is "mkfifo: not found"
> I already added the package coreutils as dependency.
> 

a bit more info of what you are doing or error log would help others to
spot possible solutions.



> Does someone has some hints for me?
> 
> Regards Michael
> 


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

Re: [yocto] The best way to change target architecture

[Leonardo Sandoval]

On Tue, 2017-06-06 at 08:42 -0400, Zhuoqun Cheng wrote:
> Hi Yocto Experts,
> 
> 
> I'm fairly new to Yocto and I've already tried my best to search for
> answers, but not happy with what I found.
> 
> 
> So here's the situation I've got: 
> 
> 
> I'm using yocto to build the intel aero board image, following this
> link:
> https://github.com/intel-aero/meta-intel-aero/wiki/Quickstart-Guide#yocto-for-intel-aero
> 
> 
> 
> Everything worked fine, until I wanted to change the target
> architecture from the default 64-bit x86 to 32-bit x86. What I did is
> three steps:
> 1. do a clean: bitbake -c clean intel-aero-image
> 2. change configuration, from "require
> conf/machine/intel-corei7-64.conf" to "require
> conf/machine/intel-core2-32.conf" in the file
> "meta-intel-aero/conf/machine/intel-aero.conf"
> 3. do a build: bitbake intel-aero-image
> 
Did you change the MACHINE var?



> 
> Unfortunately, I got loads of errors, like "ERROR: linux-yocto-4.4.60
> +gitAUTOINC+2cc78e92f4-r0 do_package_qa: QA Issue: Architecture did
> not match (3 to 62) on
> work/core2-32-intel-common-poky-linux/linux-yocto/4.4.60+gitAUTOINC
> +2cc78e92f4-r0/packages-split/kernel-module-gspca-kinect/lib/modules/4.4.60-yocto-standard/kernel/drivers/media/usb/gspca/gspca_kinect.ko
>  [arch]
> "
> 
> 
> Then I tried deleting all the files in the packages-split directory
> and rebuilding. It passed building the kernel (even though failed
> because some other package's arch mismatch), but those file I deleted
> never got generated again! Now I'm a bit worried.
> 
> 
> So I guess my question is:
> What is the correct procedures to follow to reuse a poky folder
> (already built once) for a different target architecture? I'm happy to
> accept any links and suggested readings.
> 
> 
> Thanks a lot!
> Tom.
> 
> 
> -- 
> ___
> 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] [PATCH] yocto-bsp: Fix QEMUARM based bsps to not offer SMP support

[Leonardo Sandoval]

Alex,

is this change only applies to qemu arm? I wonder if the native arm arch
needs a similar series.

Leo

On Tue, 2017-05-30 at 11:44 -0700, Alejandro Hernandez wrote:
> The SMP kernel config presents issues on qemuarm because:
> 
> CONFIG_SMP=y
> Dependencies Missing:
>   - CPU_V6K or CPU_V7:
> These are selected by setting:
> CONFIG_ARCH_MULTI_V7=y
> or
> CONFIG_ARCH_MULTI_V6=y
> 
> But our QEMU + ARM BSPs are based on armv4/v5 hence they are
> incompatible with CONFIG_SMP.
> 
> This patch fixes the script, and avoids offering SMP to the user
> when the created BSP is based on QEMU + ARM.
> 



> [YOCTO #11426]
> 
> Signed-off-by: Alejandro Hernandez 
> ---
>  .../target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend   | 1 
> +
>  .../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend  | 1 
> +
>  .../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend | 1 
> +
>  .../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend  | 1 
> +
>  .../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.8.bbappend  | 1 
> +
>  .../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.1.bbappend   | 1 
> +
>  .../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.10.bbappend  | 1 
> +
>  .../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.4.bbappend   | 1 
> +
>  .../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.8.bbappend   | 1 
> +
>  9 files changed, 9 insertions(+)
> 
> diff --git 
> a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
>  
> b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
> index 7e3ce5ba12d..11105ebcc26 100644
> --- 
> a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
> +++ 
> b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
> @@ -45,6 +45,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
>  {{ if need_new_kbranch == "n": }}
>  KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
>  
> +{{ if qemuarch != "arm": }}
>  {{ input type:"boolean" name:"smp" prio:"30" msg:"Would you like SMP 
> support? (y/n)" default:"y"}}
>  {{ if smp == "y": }}
>  KERNEL_FEATURES_append_{{=machine}} += " cfg/smp.scc"
> diff --git 
> a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
>  
> b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
> index 81392ce38ac..ad77a662682 100644
> --- 
> a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
> +++ 
> b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
> @@ -45,6 +45,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
>  {{ if need_new_kbranch == "n": }}
>  KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
>  
> +{{ if qemuarch != "arm": }}
>  {{ input type:"boolean" name:"smp" prio:"30" msg:"Do you need SMP support? 
> (y/n)" default:"y"}}
>  {{ if smp == "y": }}
>  KERNEL_FEATURES_append_{{=machine}} += " cfg/smp.scc"
> diff --git 
> a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend
>  
> b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend
> index 29ad17b2009..9b5f8016841 100644
> --- 
> a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend
> +++ 
> b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend
> @@ -45,6 +45,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
>  {{ if need_new_kbranch == "n": }}
>  KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
>  
> +{{ if qemuarch != "arm": }}
>  {{ input type:"boolean" name:"smp" prio:"30" msg:"Do you need SMP support? 
> (y/n)" default:"y"}}
>  {{ if smp == "y": }}
>  KERNEL_FEATURES_append_{{=machine}} += " cfg/smp.scc"
> diff --git 
> a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
>  
> b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
> index a73b1aa132f..2fc992992cf 100644
> --- 
> a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
> +++ 
> b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
> @@ -45,6 +45,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
>  {{ if need_new_kbranch == "n": }}
>  KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
>  
> +{{ if qemuarch != "arm": }}
>  {{ input type:"boolean" name:"smp" prio:"30" msg:"Do you need SMP support? 
> (y/n)" default:"y"}}
>  {{ if smp == "y": }}
>  KERNEL_FEATURES_append_{{=machine}} += " cfg/smp.scc"
> diff --git 
> a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.8.bbappend
>  
> 

Re: [yocto] How to install dbg package and not its dependencies?

[Leonardo Sandoval]

On Sun, 2017-05-28 at 17:23 +0700, Ngọc Thi Huỳnh wrote:
> Hi everyone,
> 
> 
> Let's say I have app-example package which depends on libexample.
> 
> When I add app-example-dbg to IMAGE_INSTALL, libexample-dbg package is
> automatically included in the final image which makes the image size
> become bigger.
> 
what about installing the non-dbg ones?
> 
> In this case, is there a way to prevent libexample-dbg from being
> installed?
> 
> 
> Thanks,
> 
> Thi Huynh
> 
> -- 
> ___
> 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] qtcreator failed to open

[Leonardo Sandoval]

On Sun, 2017-05-28 at 19:46 +0530, Satya Sampangi wrote:
> Dear All,
> 
> 
> I am trying to install qt5, everything went fine, but I stuck in the
> stage when I run 
> 
> 
> qtcreator 
> 
> 
> from the terminal, I am getting error as shown in the attachment.
> 

better to use text log than images. Either paste the last lines from the
error log or use copy to a pastebin link and post it.

> 
> Any help here?
> 
> 
> Thanks in Advance,
> 
> 
> Regards,
> satya
> -- 
> ___
> 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] Kernel config fragments ignored

[Leonardo Sandoval]

On Mon, 2017-05-29 at 00:21 -0700, Paul D. DeRocco wrote:
> I ported a working build from Fido to Morty, made a few tweaks in response
> to error messages (mostly updating version numbers), but it's not finding
> my kernel configuration fragments. This is supposed to be an i386 arch
> system, but it insists upon building an x86_64 kernel. The .config file it
> generates does not include my configuration fragments, which contain
> things like CONFIG_X86_64=n and CONFIG_X86_32=y.
> 

I hit a similar error when using the yocto-bsp script to create a i386
machine then building the kernel. Can you try what is suggested on poky
commit

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=19e99786beeaf792094a4ed9859de00c064674b2



> My linux-yocto-rt_4.8.bbappend file lists my .cfg and .scc files in
> SRC_URI, and they are indeed being copied into the build directory (at
> tmp/work/chroma_bsp-poky-linux/linux-yocto-rt/4.8.12+blahblah). The docs
> seem to imply that that's all I have to do: that they will automatically
> be found and included, without my having to name them anywhere else. If I
> intentionally put a syntax error into any of them, that erroneous file is
> indeed copied, but nothing ever complains about the error, so it isn't
> being read when I force a kernel_configme. Even cleaning the kernel and
> repeating the kernel_configme doesn't change anything.
> 
> There is one .scc that includes the others, so that suggests that there
> must be some mechanism for specifying that one and relying on the explicit
> includes to pull in the rest. Its name is chroma-bsp.scc, which matches my
> custom machine name specified in local.conf. It was previously called
> chroma-bsp-preempt-rt.scc under Fido, but when that didn't work under
> Morty, I tried changing the name, to no avail.
> 
> Also, I'm puzzled that the work directory name contains "chroma_bsp"
> instead of "chroma-bsp".
> 
> What am I missing?
> 
> -- 
> 
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.com
> 


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

Re: [yocto] webkitgtk2 progress bar

[Leonardo Sandoval]

On Wed, 2017-05-24 at 16:23 +0200, Gary Thomas wrote:
> I see that the latest master update has brought a progress bar
> for this (and presumably other 'cmake' based packages) - very nice :-)
> 
> Now [tongue-in-cheek], can someone do something about the horrendous
> build times for such packages (webkitgtk2 can take up to 3 hours on
> my [no so slow] build host!)?


this is not easy and from my side what I have done some profiling based
on the buildstats to figure out the top consumers recipes/tasks. As you
mentioned, webkitgtk is the winner, at least for utimes!

https://wiki.yoctoproject.org/wiki/MortyBuildstats
https://wiki.yoctoproject.org/wiki/TipsAndTricks/InvestigatingBuildTime

Leo



> 
> -- 
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 


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

Re: [yocto] [meta-xilinx] xen-image-minimal testing

[Leonardo Sandoval]

On Tue, 2017-05-02 at 18:28 +, Manjukumar Harthikote Matha wrote:
> 
> > -Original Message-
> > From: Nathan Rossi [mailto:nat...@nathanrossi.com]
> > Sent: Tuesday, May 02, 2017 10:23 AM
> > To: Manjukumar Harthikote Matha 
> > Cc: Jason Wu ; Pello Heriz
> > ; meta-xil...@yoctoproject.org; 
> > meta-xilinx-
> > requ...@yoctoproject.org; meta-virtualizat...@yoctoproject.org;
> > yocto@yoctoproject.org
> > Subject: Re: [meta-xilinx] xen-image-minimal testing
> >
> > On 3 May 2017 at 02:47, Manjukumar Harthikote Matha  > ma...@xilinx.com> wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> > >> boun...@yoctoproject.org] On Behalf Of Jason Wu
> > >> Sent: Tuesday, May 02, 2017 2:16 AM
> > >> To: Pello Heriz ; meta-
> > >> xil...@yoctoproject.org; meta-xilinx-requ...@yoctoproject.org; meta-
> > >> virtualizat...@yoctoproject.org; yocto@yoctoproject.org
> > >> Subject: Re: [meta-xilinx] xen-image-minimal testing
> > >>
> > >>
> > >>
> > >> On 2/05/2017 4:33 PM, Pello Heriz wrote:
> > >> > Hi all,
> > >> >
> > >> > I have built an image using "xen-image-minimal" command with Yocto
> > >> > and I would want to know how can I test if xen functionalities are
> > >> > correct or not with Zynq MPSoC QEMU. How can I do this?
> > >> http://www.wiki.xilinx.com/Building+the+Xen+Hypervisor+with+PetaLinux
> > >> +2016.4+
> > >> and+newer
> > >>
> > >> have look at the "TFTP Booting Xen and Dom0 2016.4" section and hope that
> > helps.
> > >>
> > >> >
> > >> > Anyway, I have seen that sometimes in the QEMU terminal appears the
> > >> > next message when the mentioned image is launched by "runqemu zcu102".
> > >> >
> > >> > INIT: Id "X0" respawning too fast: disabled for 5 minutes
> > >> >
> > >> > What's the meaning of the message? Is it critical?
> > >> It is not critical if you don't need it. The reason you are getting
> > >> this error message is because the your inittab trying spawn a console
> > >> when the device node (e.g. hvc0) for Id "X0" does not exists.
> > >>
> > >
> > > Is there a way to stop inittab from doing this?
> > > Tried few options for initiab, for ex: using "once" instead of "spawn"
> > >
> > > Any other good ideas on how we can disable it? Or what is a better
> > > approach to resolve this issue during runtime
> >
> > Change the sysvinit-inittab bbappend in meta-virtualization use start_getty 
> > instead
> > of just getty, start_getty does a 'test -c' before starting getty on the 
> > device. This is
> > how sysvinit-inittab handles SERIAL_CONSOLES. Alternatively the 
> > meta-virtualization
> > bbappend could just expand SERIAL_CONSOLES.
> >
> Something like this?
> https://github.com/Xilinx/meta-virtualization/commit/610887495c01f0b17db6084e1426cc55a3f806ea
> 
> We still see initab looking for console even after this change

another approach, including the following into your local.conf

SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"

or if you are using qemu, the following poky commit id can be
cherry-picked 86d6b790eb7 which avoids the entry on inittab for ttyS1.

Leo


> 
> Thanks
> Manju
> 
> 
> > Regards,
> > Nathan
> 
> 
> This email and any attachments are intended for the sole use of the named 
> recipient(s) and contain(s) confidential information that may be proprietary, 
> privileged or copyrighted under applicable law. If you are not the intended 
> recipient, do not read, copy, or forward this email message or any 
> attachments. Delete this email message and any attachments immediately.
> 


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

Re: [yocto] [meta-rockchip][PATCH] linux: version bump to 4.11-rc8

[Leonardo Sandoval]

for reviewing purposes, it would be nice if you set diff.renames =
"true" into your .gitconfig file, so git detect renames and just diff
changes.

Leo



On Fri, 2017-04-28 at 15:58 +0200, Romain Perier wrote:
> Linux kernel 4.11 being released soon, bump recipe to 4.11-rc8.
> 
> Signed-off-by: Romain Perier 
> ---
>  recipes-kernel/linux/linux_4.10.bb | 19 ---
>  recipes-kernel/linux/linux_4.11.bb | 20 
>  2 files changed, 20 insertions(+), 19 deletions(-)
>  delete mode 100644 recipes-kernel/linux/linux_4.10.bb
>  create mode 100644 recipes-kernel/linux/linux_4.11.bb
> 
> diff --git a/recipes-kernel/linux/linux_4.10.bb 
> b/recipes-kernel/linux/linux_4.10.bb
> deleted file mode 100644
> index e1d0aa4..000
> --- a/recipes-kernel/linux/linux_4.10.bb
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -# Copyright (C) 2017 Romain Perier
> -# Copyright (C) 2017 Eddie Cai
> -# Released under the MIT license (see COPYING.MIT for the terms)
> -
> -require recipes-kernel/linux/linux-yocto.inc
> -
> -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
> -
> -SRCREV = "7089db84e356562f8ba737c29e472cc42d530dbc"
> -LINUX_VERSION = "4.10"
> -# Override local version in order to use the one generated by linux build 
> system
> -# And not "yocto-standard"
> -LINUX_VERSION_EXTENSION = ""
> -PR = "r1"
> -PV = "${LINUX_VERSION}-rc8"
> -
> -# Include only supported boards for now
> -COMPATIBLE_MACHINE = 
> "(radxarock|marsboard-rk3066|firefly-rk3288|rock2-square)"
> -deltask kernel_configme
> diff --git a/recipes-kernel/linux/linux_4.11.bb 
> b/recipes-kernel/linux/linux_4.11.bb
> new file mode 100644
> index 000..6058661
> --- /dev/null
> +++ b/recipes-kernel/linux/linux_4.11.bb
> @@ -0,0 +1,20 @@
> +# Copyright (C) 2017 Romain Perier
> +# Copyright (C) 2017 Eddie Cai
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
> +
> +SRCREV = "5a7ad1146caa895ad718a534399e38bd2ba721b7"
> +LINUX_VERSION = "4.11"
> +# Override local version in order to use the one generated by linux build 
> system
> +# And not "yocto-standard"
> +LINUX_VERSION_EXTENSION = ""
> +PR = "r1"
> +PV = "${LINUX_VERSION}-rc8"
> +
> +# Include only supported boards for now
> +COMPATIBLE_MACHINE = 
> "(radxarock|marsboard-rk3066|firefly-rk3288|rock2-square)"
> +deltask kernel_configme
> +
> -- 
> 1.8.3.1
> 


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

Re: [yocto] Local repo no network help request

[Leonardo Sandoval]

On Wed, 2017-04-05 at 19:57 -0700, Matthew Phillips wrote:
> Hi all,
> 
> I am trying to do the following:
> 
> I have a local git repo, pulled manually from a remote repo (via a script).
> I have a .bb file set up referencing this repo. This .bb file includes
> (among other things):
> 
> >> SRC_URI = "git://${TOPDIR}/../sources/my-repo;protocol=file;branch=master"
> >> SRCREV = "${AUTOREV}"
> 

did you get the same result if you hard-coded the pathname? 




> I do not want to use the network (so BB_NO_NETWORK is 1).
> 
> Although the SRC_URI is pointing to the correct path, the yocto build
> fails because it tries to access the network.
> 
> How should I be doing this instead?
> 
> I can run a script (preferably bash atm) before the build if doing
> something pre-build will help simplify anything.
> 
> Thank you,
> M


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

Re: [yocto] [PATCH] i386 machine.cfg: Explicitly disable 64BIT

[Leonardo Sandoval]

On Thu, 2017-03-30 at 09:56 -0700, Saul Wold wrote:
> Since we do not set the 64 bit flags, newer kernels seem to build 64bit
> config files by default. This is due to a hard-coded uname -m check that
> selects the KBUILD_DEFCONFIG based on the host, not the cross target.
> 


Saul, this is poky code, so wrong list.



> Similar to e9ec769926b2378e63380bd7762ce7ce201af151 in the yocto-kernel-cache 
> repo
> 
> [YOCTO #11230]
> 
> Signed-off-by: Saul Wold 
> ---
>  .../substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg  | 3 
> +++
>  1 file changed, 3 insertions(+)
> 
> diff --git 
> a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg
>  
> b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg
> index 3b168b7..fe5b882 100644
> --- 
> a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg
> +++ 
> b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg
> @@ -1,5 +1,8 @@
>  # yocto-bsp-filename {{=machine}}.cfg
>  CONFIG_X86_32=y
> +# Must explicitly disable 64BIT
> +# CONFIG_64BIT is not set
> +
>  CONFIG_MATOM=y
>  CONFIG_PRINTK=y
>  
> -- 
> 2.7.4
> 


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

Re: [yocto] arm-angstrom-linux-gnueabi-gcc: fatal error: no input files

[Leonardo Sandoval]

On Thu, 2017-03-30 at 17:25 +0200, Yuvarajesh Valleru wrote:
> Thank you for great help and suggestions. I will go through other 
> recipes and try it again.
> 

Also, you can try the script 'yocto-layer' ('create' subcommand) to
create a layer with a single recipe (the hello world one)

Leo


> Thanks again.
> 
> 
> Am 30.03.2017 um 14:46 schrieb Fabien Lahoudere:
> > Seems to be related to missing CFLAGS to compile.
> > IMO you should look at how other recipe build qt4 apps.
> >
> > On Thu, 2017-03-30 at 14:38 +0200, Yuvarajesh Valleru wrote:
> >> Thanks, It worked. But experienced another error.
> >>
> >> ERROR: helloworld-1.0-r0 do_compile: Function failed: do_compile (log
> >> file is located at
> >> /home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
> >> r0/temp/log.do_compile.31394)
> >> ERROR: Logfile of failure stored in:
> >> /home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
> >> r0/temp/log.do_compile.31394
> >> Log data follows:
> >>> DEBUG: Executing shell function do_compile
> >>>
> >> /home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
> >> r0/helloworld.cpp:1:23:
> >> fatal error: QTextStream: No such file or directory
> >>> compilation terminated.
> >>> WARNING: exit code 1 from a shell command.
> >>> ERROR: Function failed: do_compile (log file is located at
> >> /home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
> >> r0/temp/log.do_compile.31394)
> >> ERROR: Task
> >> (/home/cc/src/oe-core/build/../layers/meta-laye/recipes-
> >> hi/helloworld/helloworld_1.0.bb:do_compile)
> >> failed with exit code '1'
> >> NOTE: Tasks Summary: Attempted 591 tasks of which 590 didn't need to be
> >> rerun and 1 failed.
> >> NOTE: Writing buildhistory
> >>
> >> Summary: 1 task failed:
> >> /home/cc/src/oe-core/build/../layers/meta-layer/recipes-hi/helloworld/helloworld_1.0.bb:do_compile
> >> Summary: There was 1 WARNING message shown.
> >> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> >>
> >>
> >> Am 30.03.2017 um 12:54 schrieb Fabien Lahoudere:
> >>> Try
> >>>
> >>> do_compile() {
> >>> ${CC} ${S}/helloworld.cpp -o ${S}/helloworld
> >>> }
> >>>
> >>> On Thu, 2017-03-30 at 12:43 +0200, Yuvarajesh Valleru wrote:
>  Here is the tree for my recipe and also attached the error.
> 
>  /home/cc/src/oe-core/build/../layers/meta-layer/recipes-hi/helloworld/
>  ├── files
>  │ ├── helloworld.cpp
>  │ └── helloworld.pro
>  └── helloworld_1.0.bb
> 
>  1 directory, 3 files
> 
>  ERROR: helloworld-1.0-r0 do_compile: Function failed: do_compile (log
>  file is located at
>  /home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-
>  gnueabi/helloworld/1.0-
>  r0/temp/log.do_compile.23742)
> 
>  ERROR: Logfile of failure stored in: 
>  /home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-
>  neon-
>  angstrom-linux-gnueabi/helloworld/1.0-r0/temp/log.do_compile.23742
>  Log data follows:
> > DEBUG: Executing shell function do_compile
> > arm-angstrom-linux-gnueabi-gcc: error: helloworld.cpp: No such file or 
> > directory
> > arm-angstrom-linux-gnueabi-gcc: fatal error: no input files
> > compilation terminated.
> > WARNING: exit code 1 from a shell command.
> > ERROR: Function failed: do_compile (log file is located at 
> > /home/cc/src/oe-core/build/tmp-
> > glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
> > r0/temp/log.do_compile.23742)
>  ERROR: Task (/home/cc/src/oe-core/build/../layers/meta-layer/recipes-
>  hi/helloworld/helloworld_1.0.bb:do_compile) failed with exit code '1'
>  NOTE: Tasks Summary: Attempted 591 tasks of which 584 didn't need to be 
>  rerun and 1 failed.
>  NOTE: Writing buildhistory
> 
>  Summary: 1 task failed:
>   /home/cc/src/oe-core/build/../layers/meta-layer/recipes-
>  hi/helloworld/helloworld_1.0.bb:do_compile
>  Summary: There was 1 WARNING message shown.
>  Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> 
> 
> 
> >>
> 


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

Re: [yocto] Compiling custom kernel

[Leonardo Sandoval]

On Wed, 2017-03-29 at 19:11 +0200, Alvaro Garcia wrote:
> Hi, I'm trying to compile a custom kernel (just custom config).
> I created a recipe called linux-yocto in my layer:
> meta-test
> -recipes-test
> --linux-yocto
> ---linux-yocto.bbapend

you may need to include the kernel version to  your bbappend
(linux-yocto_4.4.bappend)


> ---files
> enable_various_options.cfg
> 
> The content of the linux-yocto.bbapend is:
> 
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI += "file://enable_various_options.cfg"
> 
> And the content of enable_various_options.cfg is:
> CONFIG_DRM_NOUVEAU=y
> 
> The way I generated enable_various_options.cfg was
> bitbake -c menuconfig virtual/kernel
> Select my configuration
> bitbake -c devshell virtual/kernel
> diff of the original .config and the new one.
> I just followed the instructions here
> https://lists.yoctoproject.org/pipermail/yocto/2014-June/020174.html
> and here
> https://software.intel.com/sites/default/files/m/4/d/8/5/8/42868-11__Developing_Kernel_Module_on_Yocto.pdf
> 
> Then I run bitbake core-image-x11
> I got this warning:
> WARNING: 
> /home/amacho/poky/meta/recipes-kernel/linux/linux-yocto_4.4.bb.do_kernel_configme
>  is tainted from a forced run
> but the kernel is not compiled with the new config (I do md5 to
> vmlinuz and was exactly the same).
> 
> Can you help me to find the way I can compile this kernel?
> 
> Thank you
> 
> 
> 
> -- 
> ___
> 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] Error on installation, Help required

[Leonardo Sandoval]

On Sun, 2017-03-26 at 23:06 +0530, Soumya Gupta wrote:
> 
> Upon running bitbake core-image-sato, my system executed about
> 2309/6489 tasks and then runs into this error. I can't figure out why
> this is happening. 

Which distro (your host) are you using? try using one supported by YP.
Do you have the same issue with core-image-minimal?


One more thing, be more precise on your subject, 'error on installation'
does not help much.

> 
> 
> All help is appreciated. 
> Thanks :)
> -- 
> ___
> 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] Bumping all packages versions

[Leonardo Sandoval]

have you tried the 'bitbake-layes show-recipes' script? that scripts
list the recipes, layer it belongs and the recipe's PV, unfortunately
not in a single line, but data is there.


Leo

On Mon, 2017-03-20 at 11:35 -0600, Matthew Stanger wrote:
> No Thanks I'm a rookie :)
> 
> On Mon, Mar 20, 2017 at 11:22 AM, Gary Thomas 
> wrote:
> On 2017-03-20 16:52, Matthew Stanger wrote:
> Hi,
> 
> I'm running Yocto 1.7.1 and was wondering if there was
> a simple way to roll/bump all package versions. For
> example in
> every .bb I want to bump PV = $version higher. I'm
> trying to do this as we've designed our headless
> system to update
> using opkg but now we are struggling to find a simple
> way to update package versions, we're trying to stay
> away from
> manually doing it as there is a lot of room for error
> when touching so many packages. First, is there a way
> to brute
> force bump all package versions and 2nd is there a way
> to only bump packages that have changed code (like
> auto git hash
> diff or something) without manually bumping the PV
> version in the .bb? What is the proper way to handle
> you distro's
> versioning at the package level?
> 
> Are you using the PR server?  That's pretty much what it's
> for.
> 
> -- 
> 
> 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] Autoload kernel module works only once

[Leonardo Sandoval]

On Mon, 2017-03-13 at 14:36 +, Andrea Laini wrote:
> Hi everybody,
> 
>  
> 
> I’m getting some errors after building my Linux distro with the use of
> KERNEL_MODULE_AUTOLOAD to allow autoloading 2 of my custom out-of-tree
> device at boot time. We’ve a Poky 1.7 version.
> 
>  
> 
> So, before building the new image with the Yocto keyword
> KERNEL_MODULE_AUTOLOAD, I was able to load and open (and, obviously,
> use) my devices simply by calling ‘modprobe mydevice’ after logging
> in. Restarting the board, everything was still working well.
> 
> Since I’ve rebuild a new image enabling module autoload at boot time,
> modules are always loaded, but I’m able to open (and use) them only
> really first time I switched on the board after downloading new image.
> After the first reboot, LKMs are still loaded (calling ‘lsmod’ show
> them) but I can’t open them, neither from my C program nor
> reading/writing them from ‘/dev/mydevice’.


I am not a kernel expert, but do you know if file permissions change
after first boot? you may enable debugging at your device and view it
with dmesg, that would give you more clues. 

> 
>  
> 
> To me it sound a very strange behavior.
> 
>  
> 
> Hope anyone can help,
> 
> Many thanks
> 
>  
> 
> Andrea
> 
>  
> 
> 
> Andrea Laini
> 
> Email:andrea.la...@claypaky.it
> _
> Clay Paky S.p.A.
> AN OSRAM BUSINESS 
> Via Pastrengo, 3/b - 24068 Seriate (BG) - ITALY
> Phone: +39 - 035.654.311 - Fax: +39 - 035.30.18.76
> Web: www.claypaky.it
> _
> Read our Disclaimer @  www.claypaky.it/disclaimer
> 
> 
> 
>  
> 
> 
> -- 
> ___
> 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] directory doesn't contain library

[Leonardo Sandoval]

On Mon, 2017-03-13 at 10:32 +0100, Sven Schönfeld wrote:
> Dear Yocto-Community
> 
>  
> 
> I’m trying to create an image containing gnash_0.8.7.bb with yocto
> morty (2.2.1) and bitbake 1.32.0. I added the folders to my
> bblayers.conf and included the recipe for gnash in my local.conf file.
> 
>  
> 
> In my bblayers.conf :
> 
>  
> 
> …
> 
> BBLAYERS = „ \
> 
> …
> 
> \
> 
> ${BSPDIR}/sources/meta-qt5 \
> 
> ${BSPDIR}/sources/meta-SFA \
> 
> „
> 
>  
> 
> In my local.conf:
> 
>  
> 
> …
> 
> IMAGE_INSTALL_append = „ cairo gnash“
> 
>  
> 
> LICENSE_FLAGS_WHITELIST = „commercial_ffmpeg commercial_libav
> commercial_x264“


are you using '„' or '"'? the later is the correct one.




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

Re: [yocto] Not able to create a new BSP layer using yocto-bsp script

[Leonardo Sandoval]

On Tue, 2017-03-07 at 09:15 +, Eswaran Vinothkumar (BEG/PJ-IOT-EL)
wrote:

> 
> I tried using both the master andmorty-16.0.1  branches of poky.
> 

Can you try the same yocto-bsp command from master? If you have the same
issue, please report it on bugzilla.yoctoproject.org

>  
> 
>  
> 
> Mit freundlichen Grüßen / Best regards 
> Vinothkumar Eswaran
> 
> 
> 
>  
> 
> 
> -- 
> ___
> 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] Intoducting myself: Applying for Outreachy

[Leonardo Sandoval]

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

Re: [yocto] Devtool: Script Not found

[Leonardo Sandoval]

On Thu, 2017-03-02 at 19:56 +0530, SatyaNarayana Sampangi wrote:
> Hi Paul,
> 
> 
> I am not finding the devtool script under the 
> /${HOME}/yocto/poky/scripts, so I copied that script from the website
> and changed the permissions.
> 
> 
> I did sourcing also,
> 
> 
when you said 'sourcing' you mean you prepare the environment with the
oe-init-build-env? Looks to me that you are missing this step.


> but when I run the script, I am getting
> 
> 
> 
> 
> devtool
> Traceback (most recent call last):
>   File "/home/satya/yoctoBSP/poky/scripts/devtool", line 38, in
> 
> from devtool import DevtoolError, setup_tinfoil
> ImportError: No module named 'devtool'
> 
> 
> Can you pls help me here. whereI am going wrong.
> 
> 
> Thanks in Advance,
> 
> 
> Regards,
> Satya
> -- 
> ___
> 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] [patchtest-oe][PATCH] test/test_mbox_mailinglist.py: check if series was intended for other project

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>

People working on the Poky project often send  patches to the wrong
mailing list, the most common scenarios area: bitbake patches sent to the
oe-core list, OE patches sent to OE-Core. This new code checks these possible
scenarios (and two other projects, Poky and OE) and suggest the proper
ML.

Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>
---
 tests/test_mbox_mailinglist.py | 58 ++
 1 file changed, 58 insertions(+)
 create mode 100644 tests/test_mbox_mailinglist.py

diff --git a/tests/test_mbox_mailinglist.py b/tests/test_mbox_mailinglist.py
new file mode 100644
index 000..dcf3d75
--- /dev/null
+++ b/tests/test_mbox_mailinglist.py
@@ -0,0 +1,58 @@
+#!/usr/bin/env python
+#
+# Check if the series was intended for other project (not OE-Core)
+#
+# Copyright (C) 2017 Intel Corporation
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+import subprocess
+import collections
+import base
+from patchtestdata import PatchTestInput as pti
+
+class MailingList(base.Base):
+
+# base paths of main yocto project sub-projects
+paths = {
+'oe-core': ['meta-selftest', 'meta-skeleton', 'meta', 'scripts'],
+'bitbake': ['lib', 'classes', 'conf', 'doc', 'contrib', 'bin'],
+'documentation': ['adt-manual','ref-manual', 'sdk-manual','bsp-guide', 
'profile-manual','template','toaster-manual','dev-manual', 
'mega-manual','tools','kernel-dev','yocto-project-qs'],
+'poky': ['meta-poky','meta-yocto-bsp'],
+'oe': ['meta-gpe', 'meta-gnome', 'meta-efl', 'meta-networking', 
'meta-multimedia','meta-initramfs', 'meta-ruby', 'contrib', 'meta-xfce', 
'meta-filesystems', 'meta-perl', 'meta-webserver', 'meta-systemd', 'meta-oe', 
'meta-python']
+}
+
+Project = collections.namedtuple('Project', ['name', 'listemail', 
'gitrepo', 'paths'])
+
+bitbake = Project(name='Bitbake', 
listemail='bitbake-de...@lists.openembedded.org', 
gitrepo='http://git.openembedded.org/bitbake/', paths=paths['bitbake'])
+doc = Project(name='Documentantion', 
listemail='yocto@yoctoproject.org', 
gitrepo='http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/', 
paths=paths['documentation'])
+poky= Project(name='Poky', listemail='p...@yoctoproject.org', 
gitrepo='http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto(-bsp)', 
paths=paths['poky'])
+oe  = Project(name='oe', 
listemail='openembedded-de...@lists.openembedded.org', 
gitrepo='http://git.openembedded.org/meta-openembedded/', paths=paths['oe'])
+
+
+def test_target_mailing_list(self):
+"""In case of merge failure, check for other targeted projects"""
+if pti.repo.ismerged:
+self.skipTest('Series merged, no reason to check other mailing 
lists')
+
+for patch in self.patchset:
+folders = patch.path.split('/')
+base_path = folders[0]
+for project in [self.bitbake, self.doc, self.oe, self.poky]:
+if base_path in  project.paths:
+self.fail('Series sent to the wrong mailing list', 'Send 
the series again to the correct mailing list (ML)',
+  data=[('Suggested ML', '%s [%s]' % 
(project.listemail, project.gitrepo))])
+
+
+
-- 
2.1.4

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

[yocto] [patchwork][PATCH] git-pw: include bundle sub-command

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>

This new command allows to fetch bundles (set of selected patches by the user)
and print them into the stdout. For the moment, bundles must be public 
(otherwise
these wont be found)

Command line example:

openembedded-core$ git pw bundle newbundle --username lsandov1

Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>
---
 git-pw/git-pw | 52 
 1 file changed, 48 insertions(+), 4 deletions(-)

diff --git a/git-pw/git-pw b/git-pw/git-pw
index f5fbdcb..554dfae 100755
--- a/git-pw/git-pw
+++ b/git-pw/git-pw
@@ -126,6 +126,11 @@ class Command(object):
 'need_project' : False,
 'need_auth': False,
 },
+'bundle': {
+'need_git_repo': True,
+'need_project' : False,
+'need_auth': False,
+},
 'list': {
 'need_git_repo': True,
 'need_project' : True,
@@ -295,13 +300,25 @@ class Patch(RestObject):
 def url(self, url='/'):
 return '/patches/' + str(self.id) + url
 
+class Bundle(RestObject):
+
+def __init__(self, patchwork, bundle_name, user):
+super(Bundle, self).__init__(patchwork)
+self.bundle_name = str(bundle_name)
+self.user = str(user)
+
+def url(self, url='/'):
+return '/bundle/' + self.user + '/' + self.bundle_name + url
+
 
 class Patchwork(object):
 
+api_version= 'api/1.0'
+
 def __init__(self, web_root, project_linkname, user):
 if not web_root.endswith('/'):
 web_root += '/'
-self.api_base = web_root + 'api/1.0'
+self.api_base = web_root + self.api_version
 self.web_root = web_root
 self.project = Project(self, project_linkname)
 self.user = user
@@ -372,6 +389,9 @@ class Patchwork(object):
 def get_patch(self, patch_id):
 return Patch(self, patch_id)
 
+def get_bundle(self, bundle_name, name):
+return Bundle(self, bundle_name, name)
+
 
 class Terminal(object):
 DEFAULT_WIDTH = 80
@@ -578,15 +598,13 @@ class GitPatchwork(object):
 # auth mechanism. In any case, using HTTPS is a must.
 username = None
 password = None
-user = None
 try:
 username = config.get(section, 'user')
 password = config.get(section, 'password')
-user = User(username, password)
 except:
 pass
 
-if not user and self.cmd.need_auth:
+if not password and self.cmd.need_auth:
 die('No authentication configured.\n\n'
 "Please set up credentials, e.g.:\n\n"
 "   git config patchwork.%(config)s.user myusername\n"
@@ -594,6 +612,8 @@ class GitPatchwork(object):
 'config': self.cmd.config,
 })
 
+user = User(username, password)
+
 self.pw = Patchwork(web_root, project, user)
 self.pw.setup()
 
@@ -679,6 +699,20 @@ class GitPatchwork(object):
 raise
 die('No patch with id %d.' % self.cmd.patch_id)
 
+def do_bundle(self):
+user = self.cmd.username or self.pw.user.username
+if not user:
+die('Either define a patchwork user at .git/config or set it 
through --username')
+
+bundle = self.pw.get_bundle(self.cmd.bundle_name, user)
+
+try:
+return 
self._print_mbox(bundle.absolute_url('/mbox/').replace(self.pw.api_version,''))
+except HttpError as e:
+if e.status_code != 404:
+raise
+die('No user %s bundle with name %s.' % (self.cmd.user, 
self.cmd.bundle_name))
+
 def do_list(self):
 project = self.pw.get_project()
 params = {
@@ -973,6 +1007,16 @@ if __name__ == '__main__':
 
 parser_add_mbox_options(mbox_patch_parser)
 
+# bundle
+bundle_parser = subparsers.add_parser('bundle',
+help='retrieve a mbox file of a bundle and print it on stdout')
+bundle_parser.add_argument('--username', '-u', metavar='username',
+type=str, help='the patchwork\'s user that created the bundle, use 
git\'s configured if omitted')
+bundle_parser.add_argument('bundle_name', metavar='bundle_name',
+type=str, help='the bundle to retrieve')
+
+parser_add_mbox_options(bundle_parser)
+
 # poll-events
 poll_events_parser = subparsers.add_parser('poll-events',
 help='list events since the last invocation')
-- 
2.1.4

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

[yocto] [PATCH] git-pw: include bundle sub-command

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>

This new command allows to fetch bundles (set of selected patches by the user)
and print them into the stdout. For the moment, bundles must be public 
(otherwise
these wont be found)

Command line example:

openembedded-core$ git pw bundle newbundle --username lsandov1

Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>
---
 git-pw/git-pw | 52 
 1 file changed, 48 insertions(+), 4 deletions(-)

diff --git a/git-pw/git-pw b/git-pw/git-pw
index f5fbdcb..554dfae 100755
--- a/git-pw/git-pw
+++ b/git-pw/git-pw
@@ -126,6 +126,11 @@ class Command(object):
 'need_project' : False,
 'need_auth': False,
 },
+'bundle': {
+'need_git_repo': True,
+'need_project' : False,
+'need_auth': False,
+},
 'list': {
 'need_git_repo': True,
 'need_project' : True,
@@ -295,13 +300,25 @@ class Patch(RestObject):
 def url(self, url='/'):
 return '/patches/' + str(self.id) + url
 
+class Bundle(RestObject):
+
+def __init__(self, patchwork, bundle_name, user):
+super(Bundle, self).__init__(patchwork)
+self.bundle_name = str(bundle_name)
+self.user = str(user)
+
+def url(self, url='/'):
+return '/bundle/' + self.user + '/' + self.bundle_name + url
+
 
 class Patchwork(object):
 
+api_version= 'api/1.0'
+
 def __init__(self, web_root, project_linkname, user):
 if not web_root.endswith('/'):
 web_root += '/'
-self.api_base = web_root + 'api/1.0'
+self.api_base = web_root + self.api_version
 self.web_root = web_root
 self.project = Project(self, project_linkname)
 self.user = user
@@ -372,6 +389,9 @@ class Patchwork(object):
 def get_patch(self, patch_id):
 return Patch(self, patch_id)
 
+def get_bundle(self, bundle_name, name):
+return Bundle(self, bundle_name, name)
+
 
 class Terminal(object):
 DEFAULT_WIDTH = 80
@@ -578,15 +598,13 @@ class GitPatchwork(object):
 # auth mechanism. In any case, using HTTPS is a must.
 username = None
 password = None
-user = None
 try:
 username = config.get(section, 'user')
 password = config.get(section, 'password')
-user = User(username, password)
 except:
 pass
 
-if not user and self.cmd.need_auth:
+if not password and self.cmd.need_auth:
 die('No authentication configured.\n\n'
 "Please set up credentials, e.g.:\n\n"
 "   git config patchwork.%(config)s.user myusername\n"
@@ -594,6 +612,8 @@ class GitPatchwork(object):
 'config': self.cmd.config,
 })
 
+user = User(username, password)
+
 self.pw = Patchwork(web_root, project, user)
 self.pw.setup()
 
@@ -679,6 +699,20 @@ class GitPatchwork(object):
 raise
 die('No patch with id %d.' % self.cmd.patch_id)
 
+def do_bundle(self):
+user = self.cmd.username or self.pw.user.username
+if not user:
+die('Either define a patchwork user at .git/config or set it 
through --username')
+
+bundle = self.pw.get_bundle(self.cmd.bundle_name, user)
+
+try:
+return 
self._print_mbox(bundle.absolute_url('/mbox/').replace(self.pw.api_version,''))
+except HttpError as e:
+if e.status_code != 404:
+raise
+die('No user %s bundle with name %s.' % (self.cmd.user, 
self.cmd.bundle_name))
+
 def do_list(self):
 project = self.pw.get_project()
 params = {
@@ -973,6 +1007,16 @@ if __name__ == '__main__':
 
 parser_add_mbox_options(mbox_patch_parser)
 
+# bundle
+bundle_parser = subparsers.add_parser('bundle',
+help='retrieve a mbox file of a bundle and print it on stdout')
+bundle_parser.add_argument('--username', '-u', metavar='username',
+type=str, help='the patchwork\'s user that created the bundle, use 
git\'s configured if omitted')
+bundle_parser.add_argument('bundle_name', metavar='bundle_name',
+type=str, help='the bundle to retrieve')
+
+parser_add_mbox_options(bundle_parser)
+
 # poll-events
 poll_events_parser = subparsers.add_parser('poll-events',
 help='list events since the last invocation')
-- 
2.1.4

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

Re: [yocto] [Openembedded-architecture] Patchwork and incoming patch testing

[Leonardo Sandoval]

+ Jose Lamego


Jose is doing recent work on the patchwork UI, perhaps there are already 
bugs for the items you are asking.



On 01/18/2017 02:40 AM, Jussi Kukkonen wrote:

This looks great, thanks.

On 17 January 2017 at 20:05, Paul Eggleton 
> 
wrote:


In any event we are now finally in the
position where our patchwork instance can be relied upon to
collect emails,
and the UI is much improved. This should give us a bit more
visibility into
where patches are at in the process, although we are still working
on a few
places where patch series status needs to be updated (e.g. when a
patch goes
into testing).


What's the plan for these status updates -- is the idea that you go to 
patchwork UI to see the state of a specific patch set?

Or maybe a reply to either patch sender or even the ML?

On top of patchwork we have built a simple smoke-testing framework
called
"patchtest" [5] along with a suite of corresponding tests for OE
[6]. These
tests are fairly simplistic at this point but check the basics
such as whether
a patch has been properly signed off, etc. We should soon start
seeing replies
sent to the mailing list and to submitters with results if there
are any
failures, saving us from noticing and pointing out some of the
more obvious
classes of mistakes.


 Is there a reason for patchwork only showing "success" or "failure" 
in the web ui, instead of linking to test results at least in in the 
failure case?


Jussi, that is a good idea. Right now we need to click into the series, 
then into the patches and then one can see the patch test results, 
obviously, not the best way.






 - Jussi





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

Re: [yocto] profiling tools on a T4240RDB board

[Leonardo Sandoval]

El 08/24/2016 a las 04:01 AM, Tanasa Bogdan escribió:


Hi,

We are using the (freescale) linux yocto 1.6 on a T4240RDB board where 
we want to have "tools-profile" set in our local.conf file. When 
building the fsl-image-minimal we see that there are some packages 
that are graphics-related (like gtk+, pixbuf, etc..). The card does 
not have any graphics capabilities. Why does these packets install at 
all? Is it possible to have the profiling tools without any gtk 
dependencies? How the local.conf should look like?


I believe the image you are using include those graphic-related pkgs so 
that is why you are seeing them. You may redefine your image, at the end 
fsl-image-minimal is just an example that you can modify. Also you may 
have more answers  on a FSL (NXP?) channel/mailing-list


PS: These dependencies are there even when we choose tools-sdk in 
order to have gcc in the final image.


Thanks,

Bogdan.





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

Re: [yocto] changing ownership of a file in a package

[Leonardo Sandoval]

As a workaround, have you tried using the other class to include users 
(useradd)? Look at the 'note' of this section


http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#ref-classes-extrausers

Leo


El 07/25/2016 a las 07:22 AM, piotr.lewicki escribió:

Hi,

I have a package where I want to install some files into a home 
directory of a user "testuser". I create a user in my image bb file 
using "extrausers".


My problem is that I'm unable to change ownership of those files from 
root to the testuser.


Simple "chown testuser:testuser -R /home/testuser" inside do_install 
task makes those files being owned by "nobody".


How can I manage ownership of those files properly?



The recipe is like so:

DESCRIPTION = "Files installed in testuser user home directory"
LICENSE = "CLOSED"

SRC_URI += " \
   file://authorized_keys \
   file://bash_profile \
   file://bashrc \
   "

do_install(){
install -d ${D}/home/testuser/
install -m 0644 ${WORKDIR}/bash_profile 
${D}/home/testuser/.bash_profile

install -m 0644 ${WORKDIR}/bashrc ${D}/home/testuser/.bashrc

install -d ${D}/home/testuser/.ssh
install -m 0644 ${WORKDIR}/authorized_keys ${D}/home/testuser/.ssh/
}

FILES_${PN} = "/home/testuser"


Thanks,

Piotr



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

Re: [yocto] Regarding backslash in bblayers.conf file

[Leonardo Sandoval]

This looks to be a bug. System should either accept path names with or 
without trailing '/'. Please file a bug on bugzilla.yoctoproject.org



On 06/23/2016 08:45 AM, Gujulan Elango, Hari Prasath (H.) wrote:


Hello,


We were facing a issue when building 'weston'. The issue is we had 
included meta-renesas & poky in our bblayers.conf file. The weston 
package is provided by both poky(v1.8.0) and meta-renesas(v1.9.0). We 
want the weston provided by the meta-renesas layer as it is the latest 
and also includes some changes done by Renesas.



But for some reason, it was building the weston provided by 
poky(1.8.0) which we don't want. Then we realized the issue to a 
backslash added by mistake in the bblayers.conf file after 
meta-rcar-gen3 as shown below.






# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

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

BBLAYERS ?= " \
  ${TOPDIR}/../poky/meta \
  ${TOPDIR}/../poky/meta-yocto \
  ${TOPDIR}/../poky/meta-yocto-bsp \
  ${TOPDIR}/../meta-renesas/meta-rcar-gen3/ \
  ${TOPDIR}/../meta-linaro/meta-linaro-toolchain/ \
  ${TOPDIR}/../meta-visteon-monarch \
  ${TOPDIR}/../meta-browser \
  ${TOPDIR}/../meta-openembedded/meta-oe \
  ${TOPDIR}/../meta-openembedded/meta-gnome \
  ${TOPDIR}/../meta-openembedded/meta-networking \
  ${TOPDIR}/../meta-openembedded/meta-python \
  "
BBLAYERS_NON_REMOVABLE ?= " \
  ${TOPDIR}/../poky/meta \
  ${TOPDIR}/../poky/meta-yocto \
  "


After removing the character, its now building the weston provided by 
the mera-rcar-gen3 layer(v1.9.0) correctly as we expect. But I am not 
able to understand what was happening when the backslash character was 
present. Also when I was building weston with this unwanred character, 
I was getting the warning shown below which I couldn't understand.



Loading cache...done.
Loaded 4665 entries from dependency cache.
Parsing recipes...done.
Parsing of 2046 .bb files complete (2045 cached, 1 parsed). 4666 
targets, 943 skipped, 2 masked, 0 errors.
WARNING: No bb files matched BBFILE_PATTERN_rcar-gen3 
'^/home/hari/salvator-x-1.1.0/monarch-distribution/build_release/../meta-renesas/meta-rcar-gen3//'
WARNING: No bb files matched BBFILE_PATTERN_linaro-toolchain 
'^/home/hari/salvator-x-1.1.0/monarch-distribution/build_release/../meta-linaro/meta-linaro-toolchain//'

NOTE: Resolving any missing task queue dependencies
NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due 
to PREFERRED_PROVIDERS



Thanks & Regards,

Hari Prasath





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

Re: [yocto] Yocto 2.1 perl problem

[Leonardo Sandoval]

Right. In fact, there is a bug related to this problem


https://bugzilla.yoctoproject.org/show_bug.cgi?id=9763


Apparently, the fix is simple: move the --exclude argument just before 
the FILES. Simple change but affects several recipes.



Leo


On 06/21/2016 09:42 AM, Anicic Damir (PSI) wrote:

I found something.
It seems that tar 1.29 (which I recently installed) is broken.

http://patchwork.openembedded.org/patch/123727/

I'll try now with tar 1.28




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

Re: [yocto] [[PATCH][AUH] 3/3] upgradehelper.py: Disable _order_pkgs_to_upgrade functionality

[Leonardo Sandoval]

On 06/20/2016 04:27 PM, Aníbal Limón wrote:

The _order_pkgs_to_upgrade function order a set of packages to
be upgraded based on bitbake dependency graph, currently _order_pkgs_to_upgrade
is broken so disable it while fix.

Signed-off-by: Aníbal Limón 
---
  upgradehelper.py | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 386cbcc..239fd88 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -500,8 +500,9 @@ class Updater(object):
  return pkgs_to_upgrade_ordered
  
  def run(self, package_list=None):

-pkgs_to_upgrade = self._order_pkgs_to_upgrade(
-self._get_packages_to_upgrade(package_list))
+#pkgs_to_upgrade = self._order_pkgs_to_upgrade(
+#self._get_packages_to_upgrade(package_list))

are these commented lines intended to be on the patch?

+pkgs_to_upgrade = self._get_packages_to_upgrade(package_list)
  total_pkgs = len(pkgs_to_upgrade)
  
  pkgs_ctx = {}


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

Re: [yocto] Yocto 2.1 perl problem

[Leonardo Sandoval]

Some basic approach: Try cleaning the target (perl, in this case) and 
build again.



$ bitbake -c cleansstate perl & bitbake perl


On 06/21/2016 08:00 AM, Anicic Damir (PSI) wrote:

Hi!

Suddenly perl does not build any more (I did not have the problem in 
last two weeks).

I did not change anything (my humble bitbake understanding) about perl.

=
Build Configuration:
BB_VERSION= "1.30.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "powerpc64-poky-linux"
MACHINE   = "powerpc64-ppc64e6500"
DISTRO= "gfa-ppc64e6500"
DISTRO_VERSION= "2.1"
TUNE_FEATURES = "m64 fpu-hard e6500 altivec"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp
meta-gfa  = "krogoth:4376fb851791a1fb514873ad239d516dd7159341"

NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: perl-5.22.1-r0 do_package: objcopy failed with exit code 256 
(cmd was 'powerpc64-poky-linux-objcopy' --only-keep-debug 
'/home/anicic/yocto-2.1-all/build/ppc64e6500/tmp/work/ppc64e6500-poky-linux/perl/5.22.1-r0/package/usr/lib64/perl/ptest/generate_uudmap' 
'/home/anicic/yocto-2.1-all/build/ppc64e6500/tmp/work/ppc64e6500-poky-linux/perl/5.22.1-r0/package/usr/lib64/perl/ptest/.debug/generate_uudmap'):
powerpc64-poky-linux-objcopy: Unable to recognise the format of the 
input file 
`/home/anicic/yocto-2.1-all/build/ppc64e6500/tmp/work/ppc64e6500-poky-linux/perl/5.22.1-r0/package/usr/lib64/perl/ptest/generate_uudmap'

ERROR: perl-5.22.1-r0 do_package: Function failed: split_and_strip_files
ERROR: Logfile of failure stored in: 
/home/anicic/yocto-2.1-all/build/ppc64e6500/tmp/work/ppc64e6500-poky-linux/perl/5.22.1-r0/temp/log.do_package.21205
ERROR: Task 1691 
(/home/anicic/yocto-2.1-all/poky/meta/recipes-devtools/perl/perl_5.22.1.bb, 
do_package) failed with exit code '1'

=

The problem seems to be that
/home/anicic/yocto-2.1-all/build/ppc64e6500/tmp/work/ppc64e6500-poky-linux/perl/5.22.1-r0/package/usr/lib64/perl/ptest/generate_uudmap
is built for host "ELF 64-bit LSB executable, x86-64"
instead of target "64-bit PowerPC or cisco 7500"

What could it be?

Damir





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

Re: [yocto] FEED_DEPLOYDIR_BASE_URI does not work

[Leonardo Sandoval]

On 12/01/2015 12:16 PM, Paul Eggleton wrote:

On Tue, 01 Dec 2015 08:34:15 Leonardo Sandoval wrote:

On 12/01/2015 03:49 AM, Ayoub Zaki wrote:

|Hello,

Setting FEED_DEPLOYDIR_BASE_URI
<http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#var-FEE
D_DEPLOYDIR_BASE_URI> in local.conf as specified in the yocto manual does
NOT generate any /etc/opkg/base-feeds.conf in the root of the target
filesystem!
Is ist a known bug ? I'm using jethro version with opkg as package
manager.

Looks like a bug, so file a bug on bugzilla.yoctoproject.org.

Have you tried setting the variables named
PACKAGE_FEED_[URIS|BASE_PATHS|ARCHS] ?

http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#var-PACKAG
E_FEED_URIS

Leo - I'm not sure your patch implementing this functionality actually got
merged in the end, though I suspect the corresponding changes to the manual
did in advance (if that's the case, that shouldn't have happened). Can you
double-check this?
Paul, you are right, patch is not yet on master but documentation is 
already there. I will reply the original email so it is taken into 
account for the next merge.




Thanks,
Paul



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

Re: [yocto] FEED_DEPLOYDIR_BASE_URI does not work

[Leonardo Sandoval]

On 12/01/2015 03:49 AM, Ayoub Zaki wrote:

|Hello,

Setting FEED_DEPLOYDIR_BASE_URI 
 
in local.conf as specified in the yocto manual does NOT generate any 
/etc/opkg/base-feeds.conf in the root of the target filesystem!
Is ist a known bug ? I'm using jethro version with opkg as package 
manager.

|

Looks like a bug, so file a bug on bugzilla.yoctoproject.org.

Have you tried setting the variables named 
PACKAGE_FEED_[URIS|BASE_PATHS|ARCHS] ?


http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#var-PACKAGE_FEED_URIS


|
cheers,
Ayoub zaki
|




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

Re: [yocto] Failing devshell

[Leonardo Sandoval]

Is it acceptable solution? Could you apply attached patch?



A less intrusive change would be to check if the output of the --version 
command contains the word 'GNOME' (either using the 'in' build-in 
operation or string.find). This is done in the same function you 
modified in your previous patch.



Thanks,
Dariusz





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

Re: [yocto] Failing devshell

[Leonardo Sandoval]

You are right. have you done some testing in non-gnome terminals using 
your patch?


On 11/26/2015 01:10 PM, Dariusz Pelowski wrote:


A less intrusive change would be to check if the output of the 
--version command contains the word 'GNOME' (either using the 'in' 
build-in operation or string.find). This is done in the same function 
you modified in your previous patch.





Greping gnome-terminal translations we can find that word "GNOME" 
doesn't exists in all languages:

am.po:msgid "GNOME Terminal"
am.po-msgstr "የኖም ተርሚናል"
--
ar.po:msgid "GNOME Terminal"
ar.po-msgstr "طرفيّة جنوم"
--
dz.po:msgid "GNOME Terminal"
dz.po-msgstr "ཇི་ནོམ་ ཊར་མི་ནཱལ་།"
--
e...@shaw.po:msgid "GNOME Terminal"
e...@shaw.po-msgstr "·ќѯѴѥ ёѻѥѦѯѩѤ"
--
fa.po:msgid "GNOME Terminal"
fa.po-msgstr "پایانه‌ی گنوم"
--
fi.po:msgid "GNOME Terminal"
fi.po-msgstr "Gnomen pääte"
--
hi.po:msgid "GNOME Terminal"
hi.po-msgstr "गनोम टर्मिनल"
--
hy.po:msgid "GNOME Terminal"
hy.po-msgstr "ԳՆՈՄ Տերմինալ"
--
ka.po:msgid "GNOME Terminal"
ka.po-msgstr "გნომ ტერმინალი"
--
ko.po:msgid "GNOME Terminal"
ko.po-msgstr "그놈 터미널"
--
mai.po:msgid "GNOME Terminal"
mai.po-msgstr "गनोम टर्मिनल"
--
ml.po:msgid "GNOME Terminal"
ml.po-msgstr "ഗ്നോം ടെര്‍മിനല്‍"
--
mn.po:msgid "GNOME Terminal"
mn.po-msgstr "ГНОМЕ-Терминал"
--
ne.po:msgid "GNOME Terminal"
ne.po-msgstr "जिनोम टर्मिनल"
--
ps.po:msgid "GNOME Terminal"
ps.po-msgstr "جنومي پايالی"
--
rw.po:msgid "GNOME Terminal"
rw.po-msgstr ""
--
si.po:msgid "GNOME Terminal"
si.po-msgstr "ග්නෝම් අග්‍රය"
--
sr.po:msgid "GNOME Terminal"
sr.po-msgstr "Гномов терминал"
--
s...@latin.po:msgid "GNOME Terminal"
s...@latin.po-msgstr "Gnomov terminal"
--
ta.po:msgid "GNOME Terminal"
ta.po-msgstr "கனோம் முனையம்"
--
te.po:msgid "GNOME Terminal"
te.po-msgstr "గ్నోమ్ టెర్మినల్"
--
ug.po:msgid "GNOME Terminal"
ug.po-msgstr "گىنوم تېرمىنال"

Can we stay with setting default locale?

Thanks,
Dariusz



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

Re: [yocto] Unable to issue bitbake linux-yocto -c menuconfig

[Leonardo Sandoval]

Which terminal did you use? Can you try the same under xterm? I remember 
working on a -c menuconfig issue under a new gnome-terminal version and 
the problem was that terminal was not spawned, however I do not recall 
any trace log being thrown.



On 11/03/2015 08:48 AM, Benoit Rapidel wrote:

Hi,

I ran into an error and I don't know where to report it.

I use poky with fido branch on a Debian 3.2.68 VM

See attached file for log

$ tmux list-panes
0: [84x44] [history 39/2000, 71202 bytes] %2
0: [231x60] [history 435/2000, 194475 bytes] %3 (active)
$

Regards,



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

Re: [yocto] Autologin after bootup on the genericx86 machine

[Leonardo Sandoval]

On 09/03/2015 04:36 AM, Gorny Krystian wrote:

Hi,

I'm using the fido branch and building a genericx86 machine for the 
core-image-rt image.
After my image boot up I always need to login as root first, is there a way to 
login and start my application automatically? I can't find an easy way to do 
this.


On your local.conf, add the following

EXTRA_IMAGE_FEATURES = "debug-tweaks"
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ADA Support?

[Leonardo Sandoval]

On 09/02/2015 10:38 AM, Smith, Daniel W wrote:

Hello,

I'm trying to figure out what is the best an easiest way to add ADA/GNAT 
support for PPC.  I'm currently running poky-fido-13.0.0.  I'm new to Yocto.


I do not know, but one place to start looking is

http://layers.openembedded.org/layerindex/branch/master/layers/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] Question about IMAGE_INSTALL_append and CORE_IMAGE_EXTRA_INSTALL

[Leonardo Sandoval]

On 07/21/2015 10:45 AM, Victor Rodriguez wrote:

On Tue, Jul 21, 2015 at 10:36 AM, Gary Thomas g...@mlbassoc.com wrote:

On 2015-07-21 09:26, Victor Rodriguez wrote:


Hi team

I have a question , according to documentation there is a difference
between

IMAGE_INSTALL_append

and

CORE_IMAGE_EXTRA_INSTALL

Specifies the list of packages to be added to the image. You should
only set this variable in the local.conf configuration file found in
the Build Directory.

When I use the second one and try to build a core-image-minimal-xfce
bitbake does not install what I wanted in my image . I had a really
hard time few weekends ago because of this.

I wonder If I am missing something or if this is a bug



The core-image-minimal-xfce recipe does not play nice with
the core-image class and is not respecting CORE_IMAGE_EXTRA_INSTALL.

I think this should be filed as a bug (and feel free to suggest a patch)

BTW, this question should really be on the OpenEmbedded development list.



Thanks Gary

I will submit the BUG , do you know the Bugzila where I should submit it ?


Victor, you can file a bug at https://bugzilla.yoctoproject.org




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
Openembedded-devel mailing list
openembedded-de...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

Re: [yocto] Bug in Open CV receipt

[Leonardo Sandoval]

On 07/21/2015 09:57 AM, Victor Rodriguez wrote:

Hi team

Few weeks ago I was having some problems with open CV receipt. In the
begining I toght I was adding opencv tro my core-image-minimal-xfce
just with this:

IMAGE_INSTALL_append =  gcc gcc-dev openssh php mariadb opencv

Now after booting the image I realize that none of the libraries for
open stack were added to my image

What I had to do was the following:


IMAGE_INSTALL_append =  libopencv-core-dev libopencv-highgui-dev
libopencv-imgproc-dev libopencv-objdetect-dev libopencv-ml-dev
opencv-staticdev python-opencv



A recipe can produce several packages. As I can see on opencv recipe, it 
can produced the following ones:


PACKAGES=opencv-staticdev opencv-dev opencv-dbg opencv-doc opencv
opencv-apps python-opencv

and dynamic ones (depending on what else you have install)

PACKAGES_DYNAMIC=^opencv-locale-.* ^libopencv-.*

For the opencv case, it happens that the package opencv is empty, so you 
need to append the other sub-packages it produces into your 
IMAGE_INSTALL variable.


So, it is not a bug, this is expected.



Even last night when one of the opencv developers ask me for python
opencv I had to add the last part python-opencv. That is not cool at
all . If I add opencv in the beginning I assume we are more than cool
with that and yocto will add all the packages . Unless I am doing
something wrong, in taht case I am more than happy to get the
feedback.

Thanks a lot for all the help . If someone else can reproduce this bug
I am more than happy to report it in bugzila (not sure the URL)

Hope it helps to cut the time of some others

Best regards

Victor Rodriguez


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

Re: [yocto] How to add bluetooth bluez4 to core image sato (valleyisland)

[Leonardo Sandoval]

You can add recipes (packages) through CORE_IMAGE_EXTRA_INSTALL = pkg 1 
pkg2  Regarding the specific package you want (bluez4), it is not 
on master, so you may try older stable branches.



On 07/20/2015 07:28 AM, Lenin Muthu kumar wrote:

Hi,
 i have created the image for atom E3800 processor (valleyisland -
core-image-sato). now i need to add bluetooth service to that image. i need
a detailed steps how to do it. im expecting positive reply from you. thanks
in advance.




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

Re: [yocto] Which is the best strategy to customize Qt configuration?

[Leonardo Sandoval]

On 07/13/2015 09:23 AM, Pampolini Matteo wrote:

Hello everybody,


my name is Matteo and I'm writing from Italy.


I'm involved in a project that requires a very customized Linux installation 
and I think Yocto is the best choice for this purpose.


I was able to build and run some images from Poky 1.8 reference and now I'm 
trying to create my own one, with a custom configuration of Qt for X11.


In particular I would like to remove Phonon support to avoid GStreamer/GLib 
dependencies: the quickest (and bad) solution was to modify 
meta/recipes-qt/qt4/qt4.inc file and it works, of course.


But in order to follow Yocto guidelines and learn the right approach, I would 
like to create a new layer and, with proper use of .bbappend files, create my 
own Qt custom configuration.



For this point, you can create a new layer and inside a new image file. 
This image will basically inherit the one you want, then you need to 
remove the specific recipe. A possible way to remove it is though 
IMAGE_INSTALL_remove = pkg to remove




Now I'm in trouble a little bit because I do not exactly now which Qt-related 
files should be included in my layer and how they should relate with the 
provided ones, may you please help me?



Dependencies can be found using the '-g' bitbake command line. That 
command produces .dot files, and you can parse these to figure out what 
you want.




Many thanks in advance for your kind support,


Matteo




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

Re: [yocto] Selecting different kernel inside an image recipe

[Leonardo Sandoval]

On 07/08/2015 09:50 AM, Klaus Knopper wrote:

Hello list,

I'm trying to build variantions/brands of an image that only differ in
kernel configuration and kernel modules included, but everything else stays
the same, for the exact same board, as in the main image.

Setting PREFERRED_PROVIDER_virtual/kernel = different_kernel
right inside in the new image recipe does not have any effect, as that
variable seems to be evaluated exclusively in the local.conf machine
file, which is read by all recipes.


This variable is commonly used inside configuration metadata (machine or 
distro conf files). You may try it there.




I'm confident that it is somehow possible in yocto to create an
additional image recipe that only differs in kernel, but I'm missing the
HOWTO for this seemingly trivial task. :-(

Any hints/links?

With kind regards
-Klaus


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

Re: [yocto] Retrieve list of all software/applications/packages installed on Yocto

[Leonardo Sandoval]

On 07/01/2015 06:41 AM, Brian Hutchinson wrote:

On Jul 1, 2015 7:34 AM, Stanciu, Alin alin.stan...@spirent.com wrote:


Hello,



I would simply like to know how to obtain a list of all software

packages/products (basically all applications) running in my Yocto build.




Can this be done via a recipe? How can I find out whether my build has a

recipe? What are other ways are there to get the listing?




Thanks





























Spirent Communications e-mail confidentiality.

This e-mail contains confidential and / or privileged information

belonging to Spirent Communications plc, its affiliates and / or
subsidiaries. If you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution and / or the taking of
any action based upon reliance on the contents of this transmission is
strictly forbidden. If you have received this message in error please
notify the sender by return e-mail and delete it from your system.


Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United

Kingdom.

Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10

9XN, United Kingdom.


Or if within the US,

Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300

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



When you build your image ... a manifest file will contain the list of
packages (with versions) contained in that image.

If you have a running system, you can generate kind of the same list
(depending on which package manager is being used - if any) by running a
command like opkg list-installed.

In case one needs a more detail on the image, you can enable 
*buildhistory* class. More info on


http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#maintaining-build-output-quality

and specifically this

http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#understanding-what-the-build-history-contains



Regards,

Brian




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

Re: [yocto] Avoid creation of .sdcard images.

[Leonardo Sandoval]

On 06/26/2015 02:45 PM, Daniel. wrote:

Does any one knows how to avoid the creation of .sdcard images? This ones
The variable controlling the type of output images is IMAGE_FSTYPES, so 
you can redefine it under your local.conf. To see the current content, 
you can do


$bitbake -e your image | grep IMAGE_FSTYPES


takes a lot of diskspace and I have to delete it periodically, which gives
headaches about cleaning everything every time. A have an 50GB partition
and from month to month I get out of disk space. :(

Thanks in advance




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

Re: [yocto] OpenCV yocto

[Leonardo Sandoval]

On 06/20/2015 09:22 PM, Victor Rodriguez wrote:

HI team

I am having this same problem:

http://stackoverflow.com/questions/25332969/opencv-pkg-config-cannot-find-lopencv-ts-when-compiling-using-g

I try to build opencv simple source code :

g++ hello.cpp -o video `pkg-config --cflags --libs opencv`


Victor, you may take at look at this recipe (opencv_samples)

http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-support/opencv/opencv-samples_2.4.bb?h=master

What I can see, seems that the `pkg-config --libs openvc` is missing on 
your bb.




But got this error :

/usr/lib/gcc/i586-poky-linux/4.9.2/../../../../i586-poky-linux/bin/ld:
cannot find -lopencv_ts
collect2: error: ld returned 1 exit status

My local.conf is like this :

EXTRA_IMAGE_FEATURES = debug-tweaks tools-sdk
IMAGE_INSTALL_append =  mpich mpich-dev gcc gcc-dev openssh php mariadb opencv
LICENSE_FLAGS_WHITELIST = commercial
CORE_IMAGE_EXTRA_INSTALL += libopencv-core-dev libopencv-highgui-dev
libopencv-imgproc-dev libopencv-objdetect-dev libopencv-ml-dev


All the help is more than welcome

Best regards

Victor Rodriguez


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

[yocto] [PATCH] dev-manual: Include biosfilename runqemu option

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com

Poky's commit edde3e58da00adf9ef3a8cc687268f6e24294c7c included the
biosfilename option on the runqemu script.

Signed-off-by: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com
---
 documentation/dev-manual/dev-manual-qemu.xml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/documentation/dev-manual/dev-manual-qemu.xml 
b/documentation/dev-manual/dev-manual-qemu.xml
index 4d95fbd..ccc915f 100644
--- a/documentation/dev-manual/dev-manual-qemu.xml
+++ b/documentation/dev-manual/dev-manual-qemu.xml
@@ -171,6 +171,9 @@
 Establishes a custom directory for BIOS, VGA BIOS and
 keymaps.
 /para/listitem
+listitemparafilenamebiosfilename/filename:
+Establishes a custom BIOS name.
+/para/listitem
 
listitemparafilenameqemuparams=\replaceablexyz/replaceable\/filename:
 Specifies custom QEMU parameters.
 Use this option to pass options other than the simple
-- 
1.8.4.5

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