Re: [yocto] [Yocto] Checking sstate mirror is hanging at 100%

On 10/30/2017 07:54 AM, Vineeth Karumanchi wrote: In this case i would expect bitbake to "check for sstate mirrors" for some time and rebuild from scratch. Is there any approach to over come this ? The approach is to fix your infrastructure so that fetching from network doesn't fail. We've g

Re: [yocto] libcap compile error

On 10/24/2017 12:23 PM, Remco Poelstra wrote: I’m new with the Yocto project and I’m still trying to find my way. I’m using a Hachiko board using Architech SDK and have managed to build and run the standard image. As a next step I wanted to include the avahi mdns implementation. In order to do

Re: [yocto] rocko: QA issue with glibc-locale

On 10/19/2017 10:15 PM, Burton, Ross wrote: On 19 October 2017 at 12:10, Belisko Marek > wrote: I'm using latest origin/rocko (65d23bd7986615fdfb0f1717b615534a2a14ab80) with no change to build beaglebone core-image-minimal. While build I got this QA er

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

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 upd

Re: [yocto] minimize size of SW update bundle

On 10/17/2017 04:12 PM, Robert Berger wrote: Imagine you have only a limited bandwidth to your devices available for SW update. So you would like to minimize what's uploaded (over the air) to your devices. How would you do this with yocto? [1] and [2] might be able to do incremental updates,

Re: [yocto] Navigating the layer labyrinth

On 10/12/2017 12:34 PM, Bernd wrote: * Finding the *file path* of an existing recipe (or append file or class) *by its name* and also all existing .bbappends for it, i imagine something simple like bitbake --show-paths foo-bar would output me the small list of absolute paths of recipe files by th

Re: [yocto] Adding test case in LTP in Yocto

On 10/11/2017 03:28 PM, Umamahesh Yelchuruvenkata wrote: Hi Maxin, Thanks for the reply. Before sending it for review, I have to test via LTP/Yocto. I am new to yocto /LTP, trying to understand how to add it. It is that only way to add my files is through patch files?. Please suggest. You c

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

On 10/05/2017 10:08 PM, Josef Holzmayr wrote: Uhm. Be aware that your custom built distribution is *not* some kind of Fedora-Light. Its an entirely different distribution, and mixing in repositories from somewhere is most certainly disastrous - or do you think using that OpenSuse repo plays a

Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

On 09/29/2017 05:01 PM, Dominig ar Foll (Intel Open Source) wrote: Due to what our IT department can support, I am issued a Windows laptop for development. In the past I have used VMWare to make a Linux virtual machine for my Yocto Project based image builds and application development. We ar

Re: [yocto] [meta-qt4][PATCH 1/2] qt4-4.8.7.inc: use a supported builtin type for Uchar

On 09/14/2017 03:09 PM, Max Krummenacher wrote: cope with icu 59's changed use of uchar. http://site.icu-project.org/download/59#TOC-ICU4C-char16_t 4.8.7-r0/recipe-sysroot/usr/include/unicode/umachine.h:347:13: error: 'char16_t' does not name a type; did you mean 'wchar_t'? typedef char16

Re: [yocto] apt-key not found

On 09/01/2017 06:17 AM, yahia farghaly wrote: So, what the right way to do this ? You should study how signing RPM/IPK package feeds is done in Yocto, and modify the code in the same way. Start from meta/recipes-core/meta/signing-keys.bb meta/classes/sign_package_feed.bbclass meta/lib/oe/pa

Re: [yocto] Building Custom Python 3 Packages

On 08/31/2017 04:54 PM, Seilis, Aaron wrote: This clearly indicates that the issue is that the build is looking for setup.py in the ${B} location, but it is only present in the ${S} location when `devtool modify` has been run. I have tried setting ${B} to ${S} explicitly in the recipe, but this d

Re: [yocto] error in apt-key add

On 08/29/2017 08:38 PM, yahia farghaly wrote: I am building a linux image using yocto which support deb package manager(apt-get). I created the repo with packages and i want to authorize this repo to my target machine. i followed these steps

Re: [yocto] [meta-qt4][PATCH RESEND][pyro] qt4-native: depend on icu-native to fix build on systems with icu <=58

On 08/25/2017 04:17 PM, Ioan-Adrian Ratiu wrote: From: Cody P Schafer Previously, qt4-native would use the system icu to build. Trying to build against a system ICU 59, however, fails with this root error: | In file included from /usr/include/unicode/uversion.h:30:0, | from t

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

On 08/24/2017 05:34 PM, Zoran Stojsavljevic wrote: Do you agree to continue keeping DNF package (in .../meta/recipe_devtools/) for handling of .rpm type of packages in the future releases of YOCTO (it is, after all, much better and more mature tool that smartpm)? The smart to dnf transition

Re: [yocto] [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

On 08/22/2017 09:09 AM, _nobody_ _nobody_ wrote: The question is: where the Hell (in which /etc files on target) I should put these??? Links to the repos should be something like these: http://127.0.0.1:8000/core2_64 http://127.0.0.1:8000/noarch http://127.0.0.1:8000/qemux86_64 http://127.0.0.1

Re: [yocto] [feature request] avoid getting the server stuck because of high "-j" value

On 08/04/2017 01:58 PM, Gianfranco Costamagna wrote: recently I found a really nice make feature, that tunes at runtime the number of parallel execution jobs, according to the current system load [1]. I think such a feature would be really nice on server were multiple yocto builds are run i

Re: [yocto] [PATCH v3] qt4: Fix build with moc4 and boost

On 07/17/2017 05:36 PM, Ricardo Ribalda Delgado wrote: Signed-off-by: Ricardo Ribalda Delgado Thanks, pushed. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH v2] qt4: Fix build with moc4 and boost

On 07/17/2017 05:28 PM, Ricardo Ribalda Delgado wrote: Hi Alex Unortunately I do not know who is the original author. The oldest thing that I can track is: http://pkgs.fedoraproject.org/cgit/rpms/qt.git/commit/qt-everywhere-opensource-src-4.8.6-QTBUG-22829.patch?id=7d0674cfd8a0bd3722f9169adac15

Re: [yocto] [PATCH v2] qt4: Fix build with moc4 and boost

On 07/17/2017 05:18 PM, Ricardo Ribalda Delgado wrote: index ..e5d3c266bade --- /dev/null +++ b/recipes-qt4/qt4/qt4-4.8.7/qt-everywhere-opensource-src-4.8.6-QTBUG-22829.patch @@ -0,0 +1,21 @@ +Error described on: https://bugzilla.redhat.com/show_bug.cgi?id=1396755 +Patch obtained fro

Re: [yocto] [meta-qt4][PATCH] qt4: Fix build with moc4 and boost

On 07/17/2017 05:12 PM, Ricardo Ribalda Delgado wrote: Actually I got the patch from https://bugzilla.redhat.com/show_bug.cgi?id=1396755 http://pkgs.fedoraproject.org/cgit/rpms/qt.git/tree/qt-everywhere-opensource-src-4.8.6-QTBUG-22829.patch In which case it is not a backport. Then the upstrea

Re: [yocto] [meta-qt4][PATCH] qt4: Fix build with moc4 and boost

On 07/17/2017 05:11 PM, Ricardo Ribalda Delgado wrote: https://codereview.qt-project.org/#/c/40593/3/src/tools/moc/main.cpp Can you add this link to the patch please? Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.o

Re: [yocto] [meta-qt4][PATCH] qt4: Fix build with moc4 and boost

On 07/07/2017 01:30 PM, Ricardo Ribalda Delgado wrote: +Error described on: https://bugzilla.redhat.com/show_bug.cgi?id=1396755 + +Upstream-Status: Backport Backport from where? Please provide a link. Alex -- ___ yocto mailing list yocto@yoctoprojec

Re: [yocto] [meta-qt4][PATCH] qmmp: Fix gcc-6 build error

On 07/07/2017 01:30 PM, Ricardo Ribalda Delgado wrote: Invalid conversion (const). Signed-off-by: Ricardo Ribalda Delgado Thanks, pushed. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] qt4-native: depend on icu-native to fix build on systems with icu >=59

On 06/08/2017 05:22 PM, Cody P Schafer wrote: Would it be reasonable to disable icu usage in meta-qt4 master while switching pyro & morty to using the icu-native package? Yes, absolutely. Alex -- ___ yocto mailing list yocto@yoctoproject.org https:/

Re: [yocto] What's up with python3

On 06/08/2017 10:28 AM, Gary Thomas wrote: I'm building using Poky/Yocto master 576821ea0a7558b626ccc87e9ae0e9ee40864956 and I've noticed that python3 (target) is being built for my image, but it doesn't end up in the actual image. None of my own recipes mention python3 at all, yet virtually eve

Re: [yocto] Python 3 internal package dependencies

On 06/08/2017 11:50 AM, Burton, Ross wrote: Is it worth trying to improve the internal package RDEPENDS in the Python 3 recipe, or is it better for recipes for Python apps to just manually list all the sub-dependencies as needed? Definitely worth improving the internal dependencies

Re: [yocto] [PATCH] qt4-native: depend on icu-native to fix build on systems with icu >=59

On 06/07/2017 06:47 PM, Cody P Schafer wrote: Yep, for `master` that is certainly true. For `morty` & `pyro` though, meta-qt4 could keep working by using icu-native. The source of this issue being qt4's general incompatibility with C++ 11 (we build with c++98 because of build errors with the ne

Re: [yocto] [PATCH] qt4-native: depend on icu-native to fix build on systems with icu >=59

On 06/07/2017 07:19 AM, Cody P Schafer wrote: Previously, qt4-native would use the system icu to build. Trying to build against a system ICU 59, however, fails with this root error: | In file included from /usr/include/unicode/uversion.h:30:0, | from tools/qlocale_icu.cpp:46: |

Re: [yocto] webkitgtk2 progress bar

On 05/24/2017 05:45 PM, Martin Jansa wrote: You can try to use gold to save a bit of time linking the beast. webkit is already using gold by default, except for some architectures (aarch64, mips) where it used to fail - maybe it is not necessary anymore. Alex --

Re: [yocto] webkitgtk2 progress bar

On 05/24/2017 05:23 PM, Gary Thomas wrote: 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!)? In order of decreasing tongue in cheekiness. 1. Rewrite webkit in something that is

Re: [yocto] unmodified binary RPM installed on rootfs?

On 05/23/2017 03:16 AM, Russell Peterson wrote: Of course, I decided to go for the gold and attempt to get this recipe to handle a binary .tgz file that contains itself multiple rpm files (one is binary, the other is a source rpm for the kernel modules). I added a do_unpack_extra function to do

Re: [yocto] unmodified binary RPM installed on rootfs?

On 05/22/2017 02:43 AM, Russell Peterson wrote: I am fairly new to yocto and I think I’m having trouble installing an RPM on the rootfs. What I am trying to do is install an arm64 binary RPM file straight onto the root file system without a recipe… just use the native rpm tool to put it there. T

Re: [yocto] [poky/classes] [PATCH] new alternatesrc.bbclass

On 05/18/2017 09:11 PM, Koehler, Yannick (HPN Aruba) wrote: +# alternatesrc.bbclass enables use of an optionally existing source tree, usually external +# to the build system to build a piece of software rather than the usual fetch/unpack +# process. +# +# To use, add alternatesrc to the globa

Re: [yocto] Problem using Subversion in Pyro

On 05/18/2017 05:02 PM, Alan Levy wrote: Here it is, certain names have been changed to protect the guilty. As you can see at the bottom svn isn't on the path, so bitbake blows up when it tries to evaluate SRCPV: ERROR: ExpansionError during parsing /my_recipe.bb | ETA: 0:00:01 Traceback (most

Re: [yocto] Problem using Subversion in Pyro

On 05/18/2017 04:46 PM, Alan Levy wrote: Just noticed the typo on my part - it's SRCPV that causes the problem, not SRCREV. Apologies for the confusion; a maze of twisty little variables, all alike So how does it blow up? Can I see the python traceback? You can also write a minimal recipe wi

Re: [yocto] Problem using Subversion in Pyro

On 05/18/2017 04:04 PM, Alan Levy wrote: It does get built, and it apparently does get used to do the actual fetching, just not for miscellaneous functions such as populating SRCREV which rely on the svn executable being on the PATH. This appears to be deliberate since there is a FETCHCMD_svn var

Re: [yocto] Problem using Subversion in Pyro

On 05/18/2017 02:40 PM, Alan Levy wrote: I have a recipe that fetches code from an SVN repository and uses ${SRCPV} to obtain its version number. This works fine under Morty but the recipe crashes out with an error under Pyro because it can’t find the SVN executable. Eventually I traced this d

Re: [yocto] Yocto Beginner Issues When Adding Layers / Recipes

On 05/03/2017 12:58 PM, windswept321 wrote: My bblayers.conf customisations: /home/aaron/poky/meta-amd/common \ /home/aaron/poky/meta-openembedded/meta-networking \ /home/aaron/poky/meta-openembedded/meta-python \ /home/aaron/poky/meta-openembedded/meta-oe \ Each of these was added to

Re: [yocto] Recipe changes to pull/fetch the source code from local instead of a remote server.

On 05/03/2017 11:29 AM, Aravindhlal G.S.S wrote: SRC_URI = "${RDKB_CCSP_ROOT_GIT}/hal/generic;protocol=${RDK_GIT_PROTOCOL};branch=${CCSP_GIT_BRANCH};name=hal" Where are these variables defined? What do they say? Where do you expect the source code to be pulled from, and where does it actually

Re: [yocto] Recipe changes to pull/fetch the source code from local instead of a remote server.

On 05/03/2017 08:16 AM, Aravindhlal G.S.S wrote: I am trying to make changes in the bitbake files(recipes) to pull/fetch the source code from the local instead of the remote server. The SRC_URI points to the local workspace, however I see that while building the source code is pulled from a remot

Re: [yocto] [PATCH] nativesdk-qt4-tools: fix build issues with libQtDBus and libQt3Support

On 04/25/2017 12:09 PM, Olivier Sobrie wrote: This patch ensures that libQtXml is build before libQtDBus and that both libQtGui and libQtNetwork are built before libQt3Support. Applied, thanks. Please add a [meta-qt4] to the subject, so that it's easier to see which layer the patch is intende

Re: [yocto] Porting a middleware to Yocto

On 04/11/2017 09:20 AM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote: We are internally using a middleware which acts as an abstraction to underlying operating system and provides APIs to application layers. Now the task is to port the middleware to Yocto. The middleware contains lot of make files a

Re: [yocto] Remove/prevent a package's installed files if another package present

On 04/07/2017 02:53 PM, colin.helliw...@ln-systems.com wrote: I'd like to do a mod to my ppp recipe such that ip-up & ip-down aren't installed if another package is in the image recipe i.e. set in CORE_IMAGE_EXTRA_INSTALL. I guess I could do a do_install_append() or a pkg_postinst_(), but is the

[yocto] [meta-qt4][PATCH] qt4: disable openssl support

s outdated version requirements for openssl to be imposed on the rest of oe-core. Signed-off-by: Alexander Kanavin --- recipes-qt4/qt4/qt4.inc | 3 ++- recipes-qt4/recipes-python/python-pyqt_4.11.3.bb | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/recip

Re: [yocto] gobject introspection needing pygobject (cross-compilation)

On 03/31/2017 09:06 AM, colin.helliw...@ln-systems.com wrote: I've got a few packages in my image which need gobject introspection. (x86-64 host, ARM target) One is building fine, but the other - NetworkManager - is failing to generate the introspection data because it can't analyse the cross-com

Re: [yocto] Remove a recipe's do_install_append() function in an append file

On 03/24/2017 03:53 PM, Robert P. J. Day wrote: On Fri, 24 Mar 2017, Cody Piersall wrote: do_install_append () { rm -fr ${D}/usr/share } which gets rid of lots lots of useful functionality, like context-aware autocompletion. Can a bbappend file get rid of that function, or do I need to e

Re: [yocto] [Openembedded-architecture] Sum up - Proposal: dealing with language-specific build tools/dependency management tools

By the way, Javascript developers do recognize that they have a framework problem. (source: http://thiswas.notinventedhe.re/on/2015-05-21 ) Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] Sum up - Proposal: dealing with language-specific build tools/dependency management tools

On 03/16/2017 12:48 PM, Jack Mitchell wrote: An issue with not having separate recipes is going to cause problems with OTA package updates. I currently have a node package that I maintain for a client and it's so big (excess of 30,000 files with all deps) that we have to have a special update pr

Re: [yocto] [Openembedded-architecture] Sum up - Proposal: dealing with language-specific build tools/dependency management tools

On 03/16/2017 11:30 AM, Paul Barker wrote: Staying with NPM as the example, say we have a tree of 1000 dependencies for a top-level application recipe. I understand that generating and then parsing 1000 recipes will bloat things and slow down the build. However, we do need some way to apply patch

Re: [yocto] [Openembedded-architecture] Proposal: dealing with language-specific build tools/dependency management tools

On 03/13/2017 07:51 PM, Bruce, Henry wrote: I agree that leveraging the likes of 'npm install' will make life simpler but the problem with these operations is that they span a range of bitbake tasks. The reason we wrote an npm fetcher was to limit network access to the fetch task. This works in

Re: [yocto] [Openembedded-architecture] Sum up - Proposal: dealing with language-specific build tools/dependency management tools

On 03/16/2017 10:17 AM, Josef Holzmayr wrote: - locking down specific versions of packages and their dependencies for reproductible builds. Thanks for summarizing! I have just one comment: at least initially, locking down specific versions has to be optional. We certainly can try our best, b

Re: [yocto] [Openembedded-architecture] Proposal: dealing with language-specific build tools/dependency management tools

On 03/10/2017 04:58 PM, Otavio Salvador wrote: I'd like to avoid generating entire separate recipes though, because that implies your custom-written tool would be figuring out where the dependency source came from in the first place, and what are its own dependencies, when creating the recipe, wh

Re: [yocto] [Openembedded-architecture] Proposal: dealing with language-specific build tools/dependency management tools

On 03/10/2017 04:30 PM, Otavio Salvador wrote: When integrating the CHICKEN Scheme support onto the Yocto Project we dealt it using their installation tool but making the package of individual packages (eggs, in this specific case) as individual recipes. We went further and automated the recipe g

[yocto] Supporting MEAN framework in Yocto

Hello, I've done some research around MEAN stack and how Yocto could support it, and here are the findings. *What is MEAN* MEAN (http://mean.io/) is a Javascript framework for writing web applications with a client-server architecture. It's comprised of four major components: - Node.js, t

[yocto] Proposal: dealing with language-specific build tools/dependency management tools

Hello all, *Introduction* The new generation of programming languages (think node.js, Go, Rust) is a poor fit for the Yocto build model which follows the traditional Unix model. In particular, those new development environments have no problem with 'grabbing random stuff from the Internet' as

Re: [yocto] [OE-core] Yocto Project Status WW09’17

On 02/28/2017 04:09 AM, akuster808 wrote: >> o rpm v4/dnf to replace rpm v5/smart? >> > IMHO, we should include dnf in 2.3 so folks can start playing with it > and remove smart in 2.4. Apologies, but there will not be a transitional period for this. Making smart and dnf coexist is hard and wil

Re: [yocto] SRC_URI patch slection

On 01/24/2017 06:37 AM, Takashi Matsuzawa wrote: In other words, in my iii) recipe I could say SRC_URI_remove = "file://.patch", but I want to make it only for specific SRCREV revisions. Or any other way of writing my iii) recipe for this? I would remove ii) altogether in the local layer

Re: [yocto] how does one stay on top of YP security alerts?

On 01/11/2017 04:49 PM, Philip Balister wrote: The problem following the CVE's direct is you need to do analysis to determine if a specific release has the vulnerability. We do have guidelines for marking CVE's addressed by commits, to help people interested in developing tools to show what CVE'

Re: [yocto] openjdk 8 support compile for arm with jit support

On 01/07/2017 05:05 PM, Rohit Jindal wrote: Please suggest me the solution for compiling Openjdk 8 for arm adding support for any jit compiler like shark or jamvm This is not how you should ask for help from people who have no obligation to help you. No one is going to respond, and sending the

Re: [yocto] how does one stay on top of YP security alerts?

On 01/07/2017 05:29 PM, Robert P. J. Day wrote: colleague wants to know how one stays up to date with security alerts related to YP releases, i checked out the yocto-security mailing list: https://lists.yoctoproject.org/pipermail/yocto-security/ but that looks like a very dead mailing list.

Re: [yocto] Fwd: error while compiling hello_2.7.bb

On 12/19/2016 02:42 PM, praveen vattipalli wrote: I have hello_2.7.bb file which contains as below vim hello_2.7.bb DESCRIPTION = "GNU Helloworld application" SECTION = "test" LICENSE = "BSD" LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/BSD;md5=377

Re: [yocto] PSA for anyone using openSUSE 42.2 (or similar)

On 12/16/2016 06:06 PM, Alexander Kanavin wrote: On 12/16/2016 05:06 PM, Trevor Woerner wrote: I just made this adjustment but given it only happened once or twice a week on a reasonably busy build machine it might be hard to confirm. I'm also not sure if setting it to "infinity&qu

Re: [yocto] PSA for anyone using openSUSE 42.2 (or similar)

On 12/16/2016 05:06 PM, Trevor Woerner wrote: I just made this adjustment but given it only happened once or twice a week on a reasonably busy build machine it might be hard to confirm. I'm also not sure if setting it to "infinity" is sensible ;-) I'm guessing other host distros probably also fa

Re: [yocto] Yocto doesn't recognize cross-compiled binaries inside SDK

On 12/02/2016 08:36 PM, Kun Yi wrote: Thanks for the explanation Alex! Will give the alternative you suggested a try. As I understand I will need to instruct Yocto to fetch necessary "native" toolchains and libs to compile the native variant recipe. Doesn't that make my recipe non-portable to oth

Re: [yocto] Yocto doesn't recognize cross-compiled binaries inside SDK

On 12/02/2016 10:36 AM, Kun Yi wrote: I'm trying to use SDK for an existing image to run cross-compiled code on my host machine. My target is ARM and host is x86_64. The SDK has arm-openbmc-linux-gnueabi toolchains installed. (The rationale is to build and run C++ unit tests for the modules that

Re: [yocto] Shallow git clones?

On 11/03/2016 03:06 PM, Gary Thomas wrote: I recall seeing some discussion in the past about using shallow GIT clones when importing repositories? Is this ever going to happen? The reason I ask is that I routinely save the GIT tarballs and some of them are obscenely obese :-( The worst of the

Re: [yocto] Requires section of RPM Spec

On 10/25/2016 02:42 PM, Bipnesh, Abhinav (Abhinav) wrote: Basically when we try to install these package on the image using RPM package management i.e. rpm -ivh the dependency checks fails as the rootfs doesn't contain RPM database from where the check be made. So below is sample output If the

Re: [yocto] Requires section of RPM Spec

On 10/25/2016 02:24 PM, Bipnesh, Abhinav (Abhinav) wrote: Is there a way we can avoid pre-populating the Requires section of the generated RPM Spec from a recipe? I have not set any RDEPENDS or other such section but still the section get populated. Below is an example Requires: libcrypto.so

[yocto] Attention all: patches for upstream source will be applied with stricter criteria for context

Hello all, while updating gnutls to a newer version I came across a rather serious issue: the way we patch source code is very lenient about the context for the lines to be changed. Basically, it's enough for one line before and after the changed line to match, because patch command's default

Re: [yocto] [Fwd: gobject introspection release notes]

On 04/26/2016 11:05 AM, Zhenhua Luo wrote: Any ideas as to why "qemu-ppc64 crashes out immediately"? I can confirm the build ends in a segfault when I tried building gobject-introspection for the t1042d4rdb-64b machine. */[Luo Zhenhua-B19537] This is a gobject-introspection support issue of QEM

[yocto] [Fwd: gobject introspection release notes]

Hello, here is the information about gobject introspection that should be placed to the release notes of the upcoming yocto release. 1. Introduction This Yocto release adds support for generating and packaging GObject introspection data. GObject introspection data is a description of the API pro

[yocto] gobject introspection release notes

Hello, here is the information about gobject introspection that should be placed to the release notes of the upcoming yocto release. 1. Introduction This Yocto release adds support for generating and packaging GObject introspection data. GObject introspection data is a description of the API pr

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

On 04/07/2016 07:58 PM, Chris Trobridge wrote: http://cgit.openembedded.org/meta-openembedded/tree/meta-python/recipes-devtools/python > > Will be fixed by deprecating python 2, of course. > > Alex Is there a shorter term solution that's generally applicable, like a separate python3-gobjec

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

On 04/07/2016 04:35 PM, Burton, Ross wrote: Yeah, that. :) Annoyingly it's not just a PACKAGECONFIG due to how python-native works. Yeah, the annoying side effect is that every python thingy needs to be packaged twice - not so visible in oe-core, but very visible in meta-oe's meta-python:

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

On 04/06/2016 06:52 PM, Burton, Ross wrote: Regarding python3, whenever I change the "--with-python" option to something other than "python2.7" then I get an error. You need to change the inherits to pull in python3native. Sadly flipping between py2 and py3 isn't trivial. I think 'g

Re: [yocto] [Query] Process of Up-streaming a new meta layer

On 04/03/2016 05:02 AM, Jaggi, Manish wrote: You need to publish the layer somewhere public (e.g. github), and then how to publish the layer to git.yoctoproject.org instead of github ? Do you have a reason to have your layer on git.yoctoproject.org instead of any other repo service? There i

Re: [yocto] [Query] Process of Up-streaming a new meta layer

On 03/23/2016 04:24 PM, Jaggi, Manish wrote: What is the process of upstreaming a new meta layer ? The layer is specific to cavium thunderx and it can be named as meta-cavium Is this the correct mailing list to upstream ? You need to publish the layer somewhere public (e.g. github), and then

Re: [yocto] Not able to disable introspection in gstreamer

> I am trying to build latest poky version from upstream but it was failing > in "gobject-introspection-data?". > > I disabled it with comments mentioned in: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?id=8c14c746da1784c4bdaa621dde6fccd99e72ef1b > > > by adding folloing line

Re: [yocto] Possible introspection failure in master

> The gstreamer _git recipes have not been updated to include the > gobject introspection patches which were applied to the 1.6.3 recipes. Yeah, I forgot about the git recipes, as they're totally hidden from default builds. I'll get them fixed. > Try disabling gobject introspection via DISTRO or

Re: [yocto] : git tag and PV variable

On 02/24/2016 05:35 PM, Khem Raj wrote: I have this command in my qmake pro files: VERSION = $$system(git describe --abbrev=0 --tags) __ __ I would like to have the package manager follow the tag versioning. __ __ Which means I would like to have somethin

Re: [yocto] [meta-qt4][PATCH 1/3] qwt: Add recipe.

On 01/19/2016 07:24 PM, Philip Balister wrote: * Copied from meta-openembedded/jethro. * Used by GNU Radio. ERROR: QA Issue: File '/usr/lib/libqwtmathml.so.6.0.1' from qwt was already stripped, this will prevent future debugging! [already-stripped] ERROR: QA Issue: File '/usr/lib/libqwt.so

Re: [yocto] [meta-qt4][PATCH 3/3] python-pyqt: Add recipe.

On 01/19/2016 07:24 PM, Philip Balister wrote: * Recipe copied from meta-openembedded/jethro. * Used by GNU Radio. Signed-off-by: Philip Balister Thanks, all three pushed to meta-qt4. Alex -- ___ yocto mailing list yocto@yoctoproject.org https

Re: [yocto] [Recipe reporting system] Upgradable recipe name list

On 01/04/2016 07:25 AM, recipe-rep...@yoctoproject.org wrote: This mail was sent out by Recipe reporting system. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstr

Re: [yocto] Fwd: Re: Python3 and Numpy

On 11/27/2015 06:39 PM, Benoit Rapidel wrote: I found one in meta. How do I update it ? I'm using poky jethro. Should a create a new one named python3-numpy or the same recipe should handle both python versions ? From what I can see, the standard approach is to create a separate recipe for pyt

Re: [yocto] Python3 and Numpy

On 11/27/2015 05:11 PM, Benoit Rapidel wrote: I want to install NumPy with Python3 supporton a Beaglebone Black. Unfortunately, I couldn't find any information or a recipe. Anyone has ever tried, success, failed ? There is a recipe for numpy in oe-core, but it's not particularly up to date, a

Re: [yocto] How to submit patches upstream for repos at git.yoctoproject.org (eg meta-renesas)

On 08/13/2015 02:21 PM, Paul Sherwood wrote: I am not affiliated to any Yocto Project member organisation, but am assisting with integration at the Automotive Grade Linux project, which is re-using some work from upstreams at git.yoctoproject.org Recently members of the AGL community have starte

Re: [yocto] [poky] Automatic Upgrade Helper Announcement

On 06/25/2015 11:02 PM, Aníbal Limón wrote: I'm glad to announce the enabling of Automatic Upgrade Helper (a.k.a. AUH), the AUH is a service that provides recipe upgrades and will be run on weekly basis. If you are a maintainer (listed in [1]) you will receive AUH emails with Recipe upgrades whe

Re: [yocto] [oe] [OE-core] Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany

On 06/16/2015 04:37 PM, Alexander Kanavin wrote: Latest epiphany will be provided as a replacement for midori. It works fine here in the core-image-sato under qemu. I can't promise it will work on ARM, but any ARM-specific issues are almost certainly in webkit's (or other we

Re: [yocto] [OE-core] Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany

On 06/16/2015 04:27 PM, Andreas Müller wrote: Yes and midori is the only working browser in Yocto (I know): firefox crashes since very long time for illegal ARM instruction and chromium does not start at all. Latest epiphany will be provided as a replacement for midori. It works fine here in

Re: [yocto] [OE-core] Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany

On 06/16/2015 09:50 AM, Andreas Müller wrote: How about doing same as others do e.g fedora [1-2]: Keep two version of webkit-gtk based on same recent code: * gtk2/webkit1 * gtk3/webkit2 Before showing how, you need to explain why. Fedora has to package webkit1 because they have a lot of apps

Re: [yocto] [OE-core] Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany

On 06/15/2015 05:24 PM, Burton, Ross wrote: If you actually compare the build dependencies, you'll see that Midori and Epiphany are actually almost identical. We need to upgrade WebKit as the release we're shipping has known security flaws and is very old - and the community is rightly moaning

[yocto] Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany

Hello everyone, I've been looking into updating oe-core's aging web engine/browser combo, and want to give you a heads up about what's going to happen: 1) webkit-gtk engine will be updated to latest stable upstream release (2.8.3 which is providing Webkit2 API and is a Gtk3 port) 2) midori

<    1   2   3   4