Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption

2018-08-22 15:58 GMT+02:00 : > I should add that the same problem exists in Poky 2.5, and top of Pseudo git > repo. The problem was introduced, best I can tell, was when the entire > Pseudo database structure was rewritten. As a result of the major overhaul > messing with patches is

Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption

2018-08-20 20:45 GMT+02:00 : > We are encountering a build problem after migrating to Poky 2.3 and Pseudo > 1.8.1, and need help to resolve this. > It is hampering our development efforts, forcing us to rebuild images > frequently. > > Background: > Our build applies SELinux file contexts,

Re: [yocto] ptest-runner "No ptests found."

f/bitbake.conf:806 > # "${EXTRA_IMAGE_FEATURES}" > # pre-expansion value: > # " ${EXTRA_IMAGE_FEATURES}" > IMAGE_FEATURES=" ptest-pkgs" > > As we can see, I still have the suspicious space but it has shrunk from 2 > spaces to 1 space. And -p

Re: [yocto] bitbake firefox using meta-browser layer

2018-08-20 15:56 GMT+02:00 Pandey, Kamal : > cd > /home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/firefox-build-dir > > > | /home/iepl/work/yocto_build/poky/build/tmp/work/aarch64- >

Re: [yocto] coreutils postinstall warning

2018-08-20 15:16 GMT+02:00 Seth Bollinger : > We've been seeing the following warning for a while now. Is this expected? > > WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall > scriptlets of ['coreutils'] to defer them to first boot is deprecated. > Please place them into

Re: [yocto] ptest-runner "No ptests found."

2018-08-20 14:07 GMT+02:00 Nader Hariri : > So, contrary to what is stated in the ptest wiki and the yocto > documentation, using EXTRA_IMAGE_FEATURES doesn't install ptests packages > (from ptest-enabled recipes) in my image, and I can't figure out why .. You can run 'bitbake -e ' to figure out

Re: [yocto] ptest-runner "No ptests found."

2018-08-16 16:07 GMT+02:00 Nader Hariri : > Hi, I am new to Yocto. I am working on ptest-runner. > > I followed the wiki https://wiki.yoctoproject.org/wiki/Ptest , but when I > boot to my image and run ptest-runner I have the output : "No ptests found." > > Is this normal ? I thought that > >

Re: [yocto] Issue with Doc-utils

2018-08-18 11:06 GMT+02:00 Sarayu Sivanandam : > | make[2]: *** [docbook2man.html] Segmentation fault (core dumped) > | make[2]: *** Waiting for unfinished jobs > | Makefile:458: recipe for target 'api.html' failed > | make[2]: *** [api.html] Segmentation fault (core dumped) > | Makefile:458:

Re: [yocto] sumo missing recipe for kernel 4.4

I see this in the commit history: As was previously announced, anything older than 4.14 is being dropped in the master/release branches to better support newer processors and to ensure that safe/secure kernels are the defaults for all builds. The time required to update the older

Re: [yocto] Image with the right version inside

Give the two recipes different names - app-release_1.0.bb and app-latest_git.bb Alex 2018-08-10 15:36 GMT+02:00 Mauro Ziliani : > Hi all > > I need to do this scenario. > > I have 2 image recipes: > > - final.bb > > - testing.bb > > final.bb and testing.bb install the same application name app.

Re: [yocto] Annoying taskhash error

My apologies, but do not use $DATETIME in your version strings. It's a seriously bad idea that goes against Yocto's philosophy - that everything that goes into a build is deterministic and does not change on the fly. Instead, define and update the date and time statically through config files. If

Re: [yocto] HELP!

You don't need to check out a specific tag. Just switch to the latest commit in the branch you want (e.g. sumo). Alex 2018-08-09 14:39 GMT+02:00 Dhanush K.S : > Hello, > > I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to Yocto > 2.5. > > After cloning the Poky repository, I

Re: [yocto] Intel machine with 64 Bit kernel and 32 Bit user space

2018-07-26 14:56 GMT+02:00 Ayoub Zaki : > Is it possible to define a MACHINE configuration with a 64 Bit kernel and 32 > Bit user space ? > > The user space should not be using a x32 ABI. I think (but I am not sure), that you can do it with multilib. Define a configuration like this:

Re: [yocto] Reg. rpm changelog

Note that we programmatically create the rpm spec files, and there is currently no support for writing changelogs into them. Generally, hand-crafted changelogs are just a maintenance burden, if you ask me. Alex 2018-07-23 20:49 GMT+02:00 Burton, Ross : > On 23 July 2018 at 18:30, Vikram

Re: [yocto] can bitbake build offline ?

This page has a tip on what might be causing 'git ls-remote': https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F Alex 2018-07-21 10:32 GMT+02:00 MOHAMMAD RASIM : > Hi, is there a way I can run a bitbake build offline? I have all the > required

Re: [yocto] [Chicken and Egg problem] Defining RDEPENDS of the package itself!

2018-07-18 13:37 GMT+02:00 Zoran Stojsavljevic : > do_install() { > install -d ${D}${bindir} > install -m 0755 cannelloni ${D}${bindir} > } You are installing only the executable binary here, but not the corresponding library. Just remove the do_install function altogether, and cmake

Re: [yocto] openssl

You are building something that requires openssl 1.0 (most likely openssh, which is not compatible with 1.1). You have to exclude it from your builds first. Alex 2018-07-16 3:19 GMT+02:00 Russell Peterson : > Hello, > > I’m looking to change to openssl version 1.1. I’m using the rocko branch. >

Re: [yocto] [meta-mingw][sumo][PATCH 0/1] openssl for Windows

You probably need to do this for openssl 1.1 as well as it soon will be the default. Alex 2018-07-12 0:42 GMT+02:00 Juro Bystricky : > Patch to allow building openssl for Windows. > openssl can also become part of SDK, i.e: > > SDKMACHINE="x86_64-mingw32" > MACHINE = "qemux86-64" >

Re: [yocto] Hook for layer-only actions?

Yes. Implement a class and inherit it from the recipes. Alex 2018-07-10 20:50 GMT+02:00 Michael Habibi : > I was wondering if there is a way I can apply a global modification to all > recipes in a layer? For instance, we have our own layer for our changes that > sit on top of the base Yocto/OE

Re: [yocto] How to remove openssl from sysroots

or make a super-minimal image which doesn't pull in 64 bit openssl. Alex 2018-07-09 20:16 GMT+02:00 Alexander Kanavin : > The error message you've provided is caused by an openssl header > referring to another header file that doesn't exist. It does not come > from application code, b

Re: [yocto] How to remove openssl from sysroots

ils (still included here below) w.r.t. > where the issue came from. It's coming from application code outside of > Yocto that is built as 32-bit apps, while Poky/BSP are built in 64-bit. > > > > ____ > From: Alexander Kanavin > Sent: M

Re: [yocto] How to remove openssl from sysroots

Just fix the build issue. Look into how opensslconf.h gets created and where the -32 suffix comes from and why the included file is absent. Seriously - that is less effort than trying to make Yocto do what it really was not designed for, and certainly takes less than one week to resolve. Also,

Re: [yocto] How to remove openssl from sysroots

If the issue is that openssl is 'out of date', then oe-core already provides a 1.1 version that can be selected via PREFERRED_VERSION as well. What is the specific need for the 3rd party version? Alex 2018-07-08 0:41 GMT+02:00 Burton, Ross : > Presumably you've a recipe for the vendor openssl.

Re: [yocto] Building gutenprint recipe

I do not recommend that you copy the binary over; it's better to clearly separate native and target. Just patch the makefile. Alex 2018-07-07 13:30 GMT+02:00 Timm : > Am 07.07.2018 um 12:17 schrieb Alexander Kanavin: > > How to do this is specific to each project. Generally,

Re: [yocto] Building gutenprint recipe

How to do this is specific to each project. Generally, you want the target recipe to depend on the native recipe (so that the necessary native tools show up in the target sysroot), and then you need to study the build system of the upstream component project (makefiles etc.) to see how it can be

Re: [yocto] Python 3.6 recipes

2018-06-24 20:44 GMT+02:00 Selvaraj V : > I had looked at the Python 3.5 recipe for using it as a template but adding > to my troubles there are patches mentioned in the recipe. How do I find > which patches to include if I am starting to write the recipes for python > 3.6 ?. Can I know the

Re: [yocto] devtool finish & patch order

2018-06-15 2:11 GMT+03:00 Peter Kjellerstedt : > * `devtool modify -w ` > * Modify some file, e.g., add some comment to the Makefile. > * Commit it with subject "Change 1" > * Repeat the two steps above two more times, increasing the number in > the subject each time. > * `devtool finish ` > *

Re: [yocto] devtool finish & patch order

2018-06-14 7:02 GMT+03:00 Tim Hammer : > > My changes for U-Boot are not working as expected. I am wondering- did I use > devtool incorrectly? > > I used 'devtool modify' to create a working copy of the vendor's u-boot and > copied & modified files to add support for my custom board. I did my work

Re: [yocto] Target CPU architectures that Yocto Project Support

On 06/12/2018 04:07 PM, Ricardo Ramirez wrote: You are right. I didn't define a clear scope for what I wanted to validate. Apologies about that imprecision. If possible, I'd like to divide the validation process into three stages 1. The system has a clean boot up process 2. The system is

Re: [yocto] Target CPU architectures that Yocto Project Support

You start by defining 'works'. It can be anything from quickly building an image and booting it on the target hardware to see a login prompt, to running a massive test suite and achieving 100% pass rate. Alex 2018-06-12 2:14 GMT+03:00 Ricardo Ramirez : > Thanks for the reply, Khem! > > What

Re: [yocto] wic appending ".1" to a file name on multiple images build

ot;) > > but it's not printing anything even when running bitbake with -DDDvvv > > On Fri, Jun 1, 2018 at 12:52 PM, Alexander Kanavin > wrote: >> 2018-06-01 13:38 GMT+03:00 Alan Martinovic : >>> Building them at the same time causes an issue: >>> >>> T

Re: [yocto] wic appending ".1" to a file name on multiple images build

2018-06-01 13:38 GMT+03:00 Alan Martinovic : > Building them at the same time causes an issue: > > Traceback (most recent call lastd): > File "/home/alan/workspace/senic-os-dev/oe/scripts/lib/wic/filemap.py", > line 120, in _open_image_file > self._f_image = open(self._image_path, 'rb') >

Re: [yocto] Image specific configuration files

der, > you seem to have a good understanding on the concepts. > Would you say that: > > > A build always builds a single distro > > is somewhat of a rule? > > > > > On Fri, Jun 1, 2018 at 11:24 AM, Alexander Kanavin > wrote: > >> I have to say

Re: [yocto] Image specific configuration files

I have to say defining multiple distros and then tweaking recipes according to those definitions is not a good practice, as recipes should generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The above iptables scenario should be handled with different image recipes, which pull

Re: [yocto] Image specific configuration files

2018-06-01 8:46 GMT+03:00 Damien LEFEVRE : > For the same MACHINE I create the following images: > - myimage-production > - myimage-rnd > - myimage-retail > > The production one has production assisted tools for flashing peripheral HW, > testing vital HW components, writing some serial numbers,

Re: [yocto] [meta-qt4][PATCH] Qt4 fails to configure ICU with ICU6X.

On 05/26/2018 09:27 PM, Michael Gloff wrote: Remove -std=gnu++98 from QMAKE_CXXFLAGS and add where necessary. Thanks, pushed to master. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK & Toolchain Deploy Issue

On 05/22/2018 03:27 PM, techi eth wrote: Can anyone give me hint on above point. I think it will be something basic while populating SDK's. Please let  me know if any information needed. Can I give you a tip? Introduce yourself properly. What is your name, what company you work for, and what

Re: [yocto] Using yocto as a build system

On 05/18/2018 12:06 AM, mamta0...@yahoo.com wrote: Apologies if these are basic questions but thought this will be the best place to find answers to the point So our requirement is to build open source packages in Linux, windows and Mac on a build system. Currently we have an internal build

Re: [yocto] [Yocto][meta-raspberrypi] troubling warning "postinstall intercept hook 'update_gio_module_cache-nativesdk' failed"

On 05/17/2018 12:17 PM, Steve Pavao wrote: I am trying to build for raspberrypi3 near head of sumo. I get the following troublesome warning fairly often since I started doing some builds in sumo and master the past week.: WARNING: core-image-minimal-1.0-r0 do_populate_sdk: The postinstall

Re: [yocto] Check IMAGE_FEATURES content in recipe

On 05/10/2018 11:59 AM, Piotr Piwko wrote: For 'read-only-rootfs' image feature, tweaks are done in functions executed after generating rootfs. meta/classes/rootfs-postcommands.bbclass:ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs",

Re: [yocto] Native curl and SSL CA certificates

On 05/09/2018 09:29 AM, Iván Castell wrote: But I am not fetching nor installing packages over the network during image creation. I just build an image using local recipes (standard procedure). One of those local recipes sets up a remote repository for rpm packages (adding

Re: [yocto] Native curl and SSL CA certificates

On 05/08/2018 05:55 PM, Iván Castell wrote: Is this a bug related with curl or ca-certificates recipe? What should be the right way to fix it? Fetching and installing packages over the network during image creation is not supported or tested in YP. You need to build them locally, with

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

On 05/08/2018 12:33 PM, Peter Kjellerstedt wrote: FYI, the already applied patch only solves half the problem. I have an updated version that solves all of it that I am preparing for publication. I only need to make some verifications first... I just found that out as well. Lua is not

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

On 05/07/2018 12:03 PM, Mirza Krak wrote: I have also been bitten by rpm performance issues in docker and glad that I found this. I am in the process of verifying above (on pyro branch). Is this patch on its way to pyro and rocko branches? As far as I know, no. You are welcome to backport and

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

On 05/04/2018 03:50 PM, Scott Rifenbark wrote: If ROOTFS_RPM_DEBUG should be a documented variable in the Yocto Project Reference Manual, could someone please provide me with some base explanation of the variable and any usage specifics? No need, we're going to remove it. Alex --

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

On 05/04/2018 03:41 PM, Alexander Kanavin wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1537564 Obviously you and anyone else affected need to make noise in the redhat bugzilla, otherwise they're likely to keep this low priority. Alex

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

On 05/04/2018 03:42 PM, Paulo Neves wrote: I will propose a patch with a default bb.debug, and always have the verbose on dnf. Let's see how it affects the performance. I cannot test this in a docker container because of the problems described below: In the mean time I found what was happening

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

On 05/03/2018 04:37 PM, Peter Kjellerstedt wrote: # Have dnf always print in verbose mode and print the output to bb.debug instead of bb.note. I think this is the best solution actually. I disagree with changing bb.note to bb.debug for this. It is very good to be able to look in

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

On 05/03/2018 01:42 PM, Paulo Neves wrote: # Add ROOTFS_RPM_DEBUG to the documentation; I'd rather get rid of it, the less variables the better :) # Detect if we are running with debug output and enable the debugging output. This is the most elegant solution but I do not know how to detect

Re: [yocto] Avoiding both GPLv3 and meta-gplv2 ?

On 05/02/2018 04:53 PM, Irving ST wrote: Thank you for your help and explanations. Unfortunately just removing ptest doesn't make it build. This is the error when I tried bitbake core-image-minimal: ERROR: Nothing PROVIDES 'readline' (but

Re: [yocto] Regarding support of machine learning algorithm/framework

On 04/12/2018 06:19 AM, atulkumar singh wrote: These days we are hearing a lot about artificial intelligence and now every company whichever domain it belongs works in AI. Either it's about automotive(Autonomous driving), Surveillance(Object detection) or IOT. So as the industry is moving

Re: [yocto] Getting the version of Yocto that is being used.

On 04/12/2018 03:11 PM, Richard Collins wrote: I get the following for DISTRO. DISTRO            = "yogurt" DISTRO_VERSION    = "BSP-Yocto-RK3288-PD17.1.1" Can't find any reference to yogurt so I assume this is something the supplier of our SOM's has done. Looking on their Wiki it seems to be

Re: [yocto] Getting the version of Yocto that is being used.

On 04/12/2018 12:44 PM, Richard Collins wrote: I've inherited a Yocto project that I know to be an old version. So one of my tasks is to update to the latest version. Before I do this I would like to know what version I have. The only information I can find is the bitbake version, BB_VERSION   

Re: [yocto] ERROR: problem:package openssh-7.6p1-r0.i586 conflicts with dropbear provided by dropbear-2017.75-r0.i586

On 04/02/2018 01:38 PM, Aditya Tayade wrote: I trying to build core-image-sato using yocto 2.5 with new package openssh. Added openssh entry in the local.conf file as follows: IMAGE_INSTALL_append = "openssh" But facing some conflicts error. Please refer attached log file for more

Re: [yocto] QEMU package list verification

On 04/02/2018 01:28 PM, Aditya Tayade wrote: 1) Build core-image-sato for yocto 2.5 ( DISTRO_VERSION = 2.4+snapshot-20180402) 2) I used the bitbake-layers show-recipes to list down the packages . 3) Verify whether the packages are part of the image root fs 4) I use command *find ./ -name*** If

Re: [yocto] [PATCH 1/2] Do not skip packages that were attempted recently.

On 03/21/2018 06:19 PM, Alexander Kanavin wrote: This was undocumented and made a number of hardcoded assumptions. The options were to make it configurable, or just remove the logic, and I chose the latter. Uh, forgot to add the [auh] prefix to these two. Alex

[yocto] [PATCH 1/2] Do not skip packages that were attempted recently.

This was undocumented and made a number of hardcoded assumptions. The options were to make it configurable, or just remove the logic, and I chose the latter. Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com> --- upgradehelper.py | 40 -

[yocto] [PATCH 2/2] When 'devtool upgrade' fails to rebase patches, stop and report a failure

Previously it would continue, which eventually resulted in an unhelpful, generic error message printed by 'devtool finish'. Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com> --- modules/steps.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/m

Re: [yocto] Building BlueZ from git in Yocto

On 03/21/2018 05:47 PM, Alan Martinovic wrote: When you say "tagged as backports" are you referring to the Upstream-Status? So this is a backport patch: Upstream-Status: Accepted [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=76255f73 2d68aef2b90d36d9c7be51a9e1739ce7]

Re: [yocto] Yocto and NPM issues

On 03/21/2018 04:44 PM, Svein Seldal wrote: > Oh, and you might have more success using meta-nodejs, as it doesn't try > to implement a custom fetcher, and just runs npm directly during the > build. If you don't mind that that makes the build outcome essentially > random from one invocation

Re: [yocto] Yocto and NPM issues

On 03/21/2018 03:54 PM, Alexander Kanavin wrote: I'm attempting to package a npm-based js application into a Rocko image, and I'm having some issues. For testing I use the official poky repo and the meta-openembedded repo (for installing nodejs 8.4.0). I'm building for qemux86-64. I know

Re: [yocto] Yocto and NPM issues

On 03/21/2018 03:09 PM, Svein Seldal wrote: Hi I'm attempting to package a npm-based js application into a Rocko image, and I'm having some issues. For testing I use the official poky repo and the meta-openembedded repo (for installing nodejs 8.4.0). I'm building for qemux86-64. I know

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

On 03/20/2018 05:59 PM, Richard Purdie wrote: How long does a single run take, and why not run it every month? Just a bit longer than a day, maybe 30 hours, if it needs to update the typical amount of 100-150 packages. I'll shift it to monthly then. Personally I'm leaning to every couple of

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

On 03/20/2018 12:52 PM, Burton, Ross wrote: Which brings me to a question: what is a good schedule and cadence for AUH runs? Currently it's run on the 15th of every odd-numbered month (so January, March, and so on), but I thought of shifting it one month forward, so it doesn't

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

On 03/19/2018 10:07 PM, Burton, Ross wrote: Do we have a place identified for new changes (2.6) while 2.5 stabilizes. A formal place, no.  I tend to queue stuff in a branch if master isn't taking all of my energy, otherwise the patches will sit on the list until 2.5 releases. 

[yocto] [PATCH][AUH] Add a commit_revert_policy configuration setting

upgrade commit, so that each upgrade is effectively built against master, which makes it less likely to fail. Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com> --- upgrade-helper.conf | 13 + upgradehelper.py| 6 +- 2 files changed, 18 insertions(+), 1 de

Re: [yocto] package manager contamination in state?

On 03/15/2018 10:12 PM, Peter A. Bigot wrote: While attempting to diagnose a package index problem visible on current poky head I changed local.conf from: PACKAGE_CLASSES ?= "package_rpm" to PACKAGE_CLASSES ?= "package_deb" Note that we don't test deb packaging all that well. I'm not even

Re: [yocto] clarify instructions for package feed installation

On 03/15/2018 10:10 PM, Peter A. Bigot wrote: Following the instructions in the 2.4.2 mega-manual section 4.21.4 I set in local.conf:     PACKAGE_FEED_URIS = "http://192.168.65.22/oe/rpi3-sumo;     PACKAGE_FEED_BASE_PATHS = "rpm"     PACKAGE_FEED_ARCHS = "noarch cortexa7hf_neon_vfpv4

Re: [yocto] [matchbox-terminal] main.c: Add support to run user command inside the terminal

On 03/14/2018 04:47 PM, Devarsh Thakkar wrote: Add support for commandline options (--command or -e) using which one can provide commands to run inside the terminal as shown in below command : $matchbox-terminal -e $matchbox-terminal --command Ross, who (if anyone) has write access to

Re: [yocto] Targeting Windows platform

On 03/14/2018 09:56 AM, Isaac Nickaein wrote: Thanks for sharing your experience. It is relieving to see that you have the same perspective. I hope there will be an initiative to target Windows and I will be glad to contribute. I don't think waiting for the initiative to happen will get you

[yocto] IMPORTANT: do_patch() fuzz warnings and how to deal with them

*Executive summary* do_patch() will shortly start issuing warnings when recipe patches are applied with some of the patch context ignored. This email explains why this is necessary, and how the warnings can be eliminated. *What is patch fuzz?* Patch fuzz is a situation when the patch tool

Re: [yocto] Two packages installing same file (with different content) to rootfs

On 03/10/2018 03:49 AM, Vuille, Martin (Martin) wrote: Ran into an issue where we have two packages installing different content for the same file in rootfs. Whichever gets installed last “wins”. I thought there was a check to prevent this. I’m sure I’ve seen a warning/error like that in the

[yocto] [auh][PATCH] Do not hardcode the location of tmp directory

Get it from bitbake instead. [YOCTO #12566] Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com> --- upgradehelper.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/upgradehelper.py b/upgradehelper.py index 169e9ce..d868cde

Re: [yocto] [Yocto][Meta-Raspberrypi] Yocto apt sources.list for Raspberry Pi

On 02/26/2018 04:14 PM, Laigui Qin wrote: I would like to think there is a well maintained Yocto/Poky repository somewhere in the world like the debian/Raspbian deb source to leverage (build and maintain my own repo is not my purpose.) Looks like there is not such repo available... Please

[yocto] [auh][PATCH] weeklyjob.sh: also clean up the workspace source directory

As devtool does not always remove it. Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com> --- weeklyjob.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/weeklyjob.sh b/weeklyjob.sh index 2e8c434..412685e 100755 --- a/weeklyjob.sh +++ b/weeklyjob.sh @@ -24,6

[yocto] [auh][PATCH] upgradehelper.py: fix arguments to _pkg_upgradable()

Maintainer whitelisting was broken, in particular. Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com> --- upgradehelper.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/upgradehelper.py b/upgradehelper.py index b22b915..169e9ce

Re: [yocto] Removing busybox completely from the generated image

On 02/19/2018 10:35 AM, Iván Castell wrote: I have tried breaking apart packagegroup-core-boot, making a copy in my custom layer, removing the line referencing busybox:     ## VIRTUAL-RUNTIME_login_manager ?= "busybox" But now bitbake complains with an error message:     ERROR: Nothing

Re: [yocto] Howto generate a Yocto image with spanish full-support by default

On 02/16/2018 02:17 PM, Iván Castell wrote: After a lot of tests, I have been able to fix this creating these two files:     $ cat /etc/locale.conf     LANG=es_ES.UTF-8     LANGUAGE=es:en     $ cat /etc/profile.d/locale.sh     LC_ALL=es_ES     LANG=es_ES     LANGUAGE=es_ES After

[yocto] [PATCH][auh 2/2] Improve README and sample config file.

in a hurry can take it into use immediately. Most settings are specific to a maintainer, and so can't be provided in a 'generic' way. Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com> --- README | 83 +-- u

[yocto] [PATCH][auh 1/2] upgrade-helper.conf: add a template for easy deployment

From: Chang Rebecca Swee Fun Settings mentioned in the README have been ported over and now users are able to copy and start modifying for personal use cases. This file will served as a reference to minimize errors when users trying to create a new conf file by

Re: [yocto] Postinstallation script warnings in Yocto 2.4 Rocko

On 02/12/2018 01:40 PM, Diaz de Grenu, Jose wrote: Can you detail how this would be done? Is it possible to append to 'log_check_expected_regex' from the .bb recipe that generates the warning? Or the only option is to patch the poky layer? Is there any way to remove these warnings in rocko

Re: [yocto] [RFC] [auh] [PATCH] upgrade-helper.conf: add a template for easy deployment

On 02/09/2018 07:43 AM, Chang Rebecca Swee Fun wrote: Settings mentioned in the README have been ported over and now users are able to copy and start modifying for personal use cases. This file will served as a reference to minimize errors when users trying to create a new conf file by following

Re: [yocto] dnf error

On 02/09/2018 02:25 AM, Russell Peterson wrote: The package I was adding had python scripts in it. The make process for the package used the python distutils.core setup function. I didn’t write the code… I’m just creating a recipe for it. This in turn copies the scripts to various locations

Re: [yocto] [auh] [PATCH] RADME: fix typo on one of the settings

On 02/09/2018 07:26 AM, Chang Rebecca Swee Fun wrote: README | 2 +- There is a typo in the commit message however :) Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dnf error

On 02/08/2018 03:17 AM, Russell Peterson wrote: core-image-initramfs-1.0-r0 do_rootfs: Could not invoke dnf Last metadata expiration check: 0:00:00 ago on Thu 08 Feb 2018 12:07:06 AM UTC. Error:  Problem: conflicting requests   - nothing provides /hosttools/python needed by

Re: [yocto] Changing gcc version and arch for single yocto recipe

On 02/07/2018 08:48 PM, Janez Svetokravsky wrote: I have just stumbled upon interesting problem, which i do not know how to solve. I am using yocto to build image for ARM cortex-A9 CPU. default gcc used is version 5.2 Beside ARM cortex-A9 there is cortex-m0plus chip, which is located on the

Re: [yocto] Creating a python recipe with devtool

On 02/07/2018 02:17 PM, Alan Martinovic wrote: devtool add https://pypi.python.org/packages/65/eb/1c3db9596eddb2bd1d1f8153dcaf2d9f2c7e144f4832d1b1449f681a0a7a/multiprocessing_logging-0.2.6-py2.py3-none-any.whl#md5=b7783a8c449135e5bb344b3f0caa3522 I don't think we support .whl format at

Re: [yocto] Remove nfs packages from image

On 02/02/2018 03:23 PM, Marek Słomiany wrote: It's still on target: root@target# opkg list |grep nfs libnfsidmap0 - 0.25-r0 nfs-utils - 2.1.1-r0 nfs-utils-client - 2.1.1-r0 nfs-utils-mount - 2.1.1-r0 While checking for any nfs-things using "bitbake -e |grep -v ^# |grep -i nfs" the only

Re: [yocto] Getting a recipe's files from within an image recipe

On 02/02/2018 02:30 PM, Colin Helliwell wrote: Thanks Alex. I half-had that thought too, but was hoping to do it with the one 'src checkout' of the whole app rather than extra two. Not that that really matters, and it seems it may be the neatest and most robust solution. I believe source

Re: [yocto] Getting a recipe's files from within an image recipe

On 02/02/2018 02:16 PM, colin.helliw...@ln-systems.com wrote: I have an app which has a config file, and I'd like my two images (production and dev) to have different configs. Obviously it'd be neater to keep the two config files within the recipe's directory structure. I guess I can't do this

Re: [yocto] Remove nfs packages from image

On 02/02/2018 12:22 PM, Anuj Mittal wrote: I think it gets included by default using DISTRO_FEATURES_DEFAULT. So using DISTRO_FEATURES_remove = " nfs" should work. However, you may also want to define your own set of values for your distro for DISTRO_FEATURES.

Re: [yocto] Remove nfs packages from image

On 02/02/2018 10:06 AM, Marek Słomiany wrote: I am using yocto rocko, with custom distro (based on poky), and custom image inheriting core-image bbclass. I was asked to get rid of nfs-client and nfs-server (and generaly nfs-anything) from our image. If I'm right it comes with

Re: [yocto] Remove nfs packages from image

On 02/02/2018 12:24 PM, Alexander Kanavin wrote: I think it gets included by default using DISTRO_FEATURES_DEFAULT. So using DISTRO_FEATURES_remove = " nfs" should work. However, you may also want to define your own set of values for your distro for DISTRO_FEATURE

Re: [yocto] Error running testimage under the autobuilder with pyro branch

On 01/28/2018 04:57 PM, Alex Lennon wrote: Hi all, I've got some simple automated testing going to test meta-mono core-image-mono builds. It just bitbakes the image then runs the testimage command This works fine for master and rocko branches, but I get a failure for pyro     Exception:

Re: [yocto] Error do_compile libepoxy

On 01/19/2018 06:36 PM, Andrea Galbusera wrote: This is where I think the configuration is not quite right. Instead of virtual/libx11, it should say virtual/libgl. And if that dependency cannot be satisfied, then the x11 option should be altogether disabled in the distro/local config (in poky

Re: [yocto] Error do_compile libepoxy

I'll try to recap a little bit but, please, forgive my ignorance in graphics stacks and libraries. Disclaimer: mostly working on headless systems... my bad! This is what I think I understand here (remember I test building poky + meta-raspberrypi): * libepoxy recipe in poky uses PACKAGECONFIG to

Re: [yocto] Automated license incompatibility checks

On 01/19/2018 07:21 AM, Boto, Erik (Pelagicore) wrote: I was looking for a way to analyze in more detail how packages of different licenses was used in an image, and stumbled upon this old mail-thread: https://lists.yoctoproject.org/pipermail/yocto/2015-January/023307.html My end goal is

Re: [yocto] Error do_compile libepoxy

On 01/19/2018 05:29 AM, Andre McCurdy wrote: Note that this same test does build fine in poky, so disabling the tests is not a good fix. You should figure out what is about the non-poky EGL headers that is causing the failure, and whether you need to configure the provider of those headers

Re: [yocto] Error do_compile libepoxy

On 01/18/2018 03:41 PM, Andrea Galbusera wrote: Yes, this is coherent with what Alexander's commit message says. We started building stuff in test/ while switching to meson... If we can't easily fix the upstream ourself and/or reproduce outside of OE to ask for help from upstream devels, IMO we

Re: [yocto] Error do_compile libepoxy

On 01/18/2018 12:00 PM, Martin Jansa wrote: FWIW: here nativesdk-libepoxy fails in do_configure already since meson conversion FileNotFoundError: [Errno 2] No such file or directory:

<    1   2   3   4   >