Op 5 aug. 2014, om 02:16 heeft Ricardo Neri
het volgende geschreven:
> The kexec-tools recipe already specifies separate packages for kexec and
> kdump. Thus, it follows that a separate package can also be used to install
> vmcore-dmesg granularly.
This breaks the upgrade patch sinds ${PN} is
The vmcore commit emptied out ${PN} leading to things like:
Collected errors:
* opkg_install_cmd: Cannot install package kexec-tools.
Let's do the right thing and make ${PN} an empty meta-package that drags in all
tools like people expect it to do.
Signed-off-by: Koen Kooi
---
Since 'yocto' is a project like freedesktop.org your commit message doesn't
make sense, it should be something like:
meta-toolchain-qt: Install full set of python modules
Op 7 aug. 2014, om 21:10 heeft Marek Vasut het volgende
geschreven:
> The Qt SDK toolchain pulls in python via
> package
On 08/06/2014 04:22 PM, ChenQi wrote:
There's a failure on autobuilder. Could you please check whether it's
related to this patch.
ERROR: Unable to install packages. Command
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/sysroots/x86_64-linux/usr/bin/smart
--d
The first time I submitted this patch series a few weeks ago, that part got
accepted without me noticing, so it's already in oe-core. Saul pointed this out
to me, so I rebased to get that patch out of the series.
-Max
From: Martin Jansa [martin.ja...@gmai
Yes, what I said previously:
1) disable current patch: add ";patch=0" to the end of the patch line in
SRC_URI
2a) add your patch to SRC_URI (if different than patch above)
2b) make your own do_patch() to apply the patch
2c) try this example for a way to supplement do_patch with your own
function:
On Thu, Aug 07, 2014 at 01:59:20PM -0700, Max Eliaser wrote:
> Hello list,
>
> This series adds a recipe for the bootchart2 daemon (a fork of the original
> bootchart.) It's based on a recipe from Meta-WebOS, but with extensive
> modifications.
>
> It is intended that bootchart2 will supersede th
This recipe creates packages for the bootchart2 system-wide profiler daemon
and related utilities. It fetches the Git revision immediately past the one
corresponding to the 0.14.6 release of bootchart2. (0.14.6 had a systemd-
related bug that was corrected right after it was tagged.)
The recipe co
The Ubootchart recipe had known issues. Ubootchart itself is no longer updated
upstream. Ubootchart is also now redundant with Bootchart2.
If people still want ubootchart around, it can be moved to meta-oe.
Ubootchart removed as part of the solution to [YOCTO #5893].
Signed-off-by: Max Eliaser
Hello list,
This series adds a recipe for the bootchart2 daemon (a fork of the original
bootchart.) It's based on a recipe from Meta-WebOS, but with extensive
modifications.
It is intended that bootchart2 will supersede the other bootchart daemons
kicking around in oe-core/meta-oe. See bug 5893.
QEMU is capable of emulating four different VGA adapters: cirrus, std, vmware,
and QXL. By adding the cirrus and fbdev X.Org drivers to the qemux86 image,
the image can be made to launch an X server on when cirrus and std are chosen,
in addition to just vmware. (The build of QEMU in OE-Core appears
This driver allows X.Org to use the Cirrus Logic family of VGA adapters. Since
QEMU can emulate a Cirrus VGA adapter, this driver will be of use for images
that are expected to run under QEMU, if QEMU's other VGA adapters are
unavailable.
Signed-off-by: Max Eliaser
---
.../recipes-graphics/xorg-
Hello list,
This series adds additional x.org drivers to the qemux86 and qemux86-64
machines. Now, instead of just including the "vmware" driver, GUI images for
these machines will also include "cirrus" and "fbdev" drivers. Rationale: now
that the runqemu script allows users to select which VGA ad
QEMU is capable of emulating four different VGA adapters: cirrus, std, vmware,
and QXL. By adding the cirrus and fbdev X.Org drivers to the qemux86-64 image,
the image can be made to launch an X server on when cirrus and std are chosen,
in addition to just vmware. (The build of QEMU in OE-Core appe
On Thursday, August 07, 2014 at 10:10:28 PM, Saul Wold wrote:
> On 08/07/2014 08:17 AM, Marek Vasut wrote:
> > The fitImage is a successor of the U-Boot uImage format, which is
> > considered legacy for years now. The fitImage allows packing multiple
> > kernel images, DTBs and other artifacts into
A -native variant of python-pycairo will be necessary for running the native
version of pybootchartgui. It may also come in handy for running other Python
utilities from the native sysroot.
Signed-off-by: Max Eliaser
---
meta/recipes-devtools/python/python-pycairo_1.10.0.bb | 2 ++
1 file change
This recipe creates packages for the bootchart2 system-wide profiler daemon
and related utilities. It fetches the Git revision immediately past the one
corresponding to the 0.14.6 release of bootchart2. (0.14.6 had a systemd-
related bug that was corrected right after it was tagged.)
The recipe co
Hello list,
This series adds a recipe for the bootchart2 daemon (a fork of the original
bootchart.) It's based on a recipe from Meta-WebOS, but with extensive
modifications.
It is intended that bootchart2 will supersede the other bootchart daemons
kicking around in oe-core/meta-oe. See bug 5893.
The Ubootchart recipe had known issues. Ubootchart itself is no longer updated
upstream. Ubootchart is also now redundant with Bootchart2.
If people still want ubootchart around, it can be moved to meta-oe.
Ubootchart removed as part of the solution to [YOCTO #5893].
Signed-off-by: Max Eliaser
On 08/07/2014 08:17 AM, Marek Vasut wrote:
The fitImage is a successor of the U-Boot uImage format, which is considered
legacy for years now. The fitImage allows packing multiple kernel images,
DTBs and other artifacts into a single image, which can then be protected
by SHA checksums and does eve
On 08/07/2014 02:24 AM, Sujith H wrote:
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG
The Qt SDK toolchain pulls in python via packagegroup-cross-canadian-${MACHINE}
and ships it. But the python is missing many modules and is rather incomplete.
The environment-setup-* script configures the PATH variable to point into
it's own sysroot first, it means the python from the SDK is used
On Thu, Aug 07, 2014 at 09:48:26AM -0400, Paul Gortmaker wrote:
> On 14-08-07 01:33 AM, Koen Kooi wrote:
> >
> > Op 6 aug. 2014, om 22:38 heeft Paul Gortmaker
> > het volgende geschreven:
> >
> >> commit 841ec528ec04e64bd09ff10f8d9ad2d6e3aac05d ("coreutils: update
> >> to upstream version 9.21"
Pull the generation of linux.bin image, which is then packed into uImage,
into a separate function. No functional change.
Signed-off-by: Marek Vasut
---
meta/classes/kernel.bbclass | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/meta
Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and instead
set it in the anonymous python function. This also allows us to handle
image types which are not supported directly by kernel, but require some
other kernel target to be built. This is the case for example with the
fitImage, w
Pull out the compilation of the DTB blobs right after the kernel's
own do_compile function finishes. This makes them available just in
time for the kernel image construction functions.
Signed-off-by: Marek Vasut
---
meta/recipes-kernel/linux/linux-dtb.inc | 14 --
1 file changed, 12
This patch adds support for generating a kernel fitImage, which is
a a successor to the uImage format. Unlike uImage, which could only
contain the kernel image itself, the fitImage can contain all kinds
of artifacts, like the kernel image, device tree blobs, initramfs
images, binary firmwares etc.
Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and instead
set it in the anonymous python function. This also allows us to handle
image types which are not supported directly by kernel, but require some
other kernel target to be built. This is the case for example with the
fitImage, w
The removed flags from this g++.conf file, which is installed to the
target as g++-unix.conf are added by gcc-base.conf . Do not add those
flags twice.
Signed-off-by: Marek Vasut
Cc: Eric Bénard
---
meta/recipes-qt/qt4/qt4-4.8.5/g++.conf | 25 ++---
1 file changed, 2 inserti
The fitImage is a successor of the U-Boot uImage format, which is considered
legacy for years now. The fitImage allows packing multiple kernel images,
DTBs and other artifacts into a single image, which can then be protected
by SHA checksums and does even support signing the images for verified boo
The fitImage is a successor of the U-Boot uImage format, which is considered
legacy for years now. The fitImage allows packing multiple kernel images,
DTBs and other artifacts into a single image, which can then be protected
by SHA checksums and does even support signing the images for verified boo
Rework the function so part it's internals can be re-used by fitImage
image type. The name of the temporary file , linux.bin , is recycled
a little more as it's now used for both the case where it is gzip
compressed and where it is not. This should be fine, since the file
is temporary and removed a
Pull the generation of linux.bin image, which is then packed into uImage,
into a separate function. No functional change.
Signed-off-by: Marek Vasut
---
meta/classes/kernel.bbclass | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/meta
In the case of building an Qt application outside of the Yocto
build system, we want to make sure that a "debug" configuration
of the application does contain debug symbols and is has the
compiler optimalization unset. On the other hand, we want to
have a "release" build which does not contain the
This patch adds support for generating a kernel fitImage, which is
a a successor to the uImage format. Unlike uImage, which could only
contain the kernel image itself, the fitImage can contain all kinds
of artifacts, like the kernel image, device tree blobs, initramfs
images, binary firmwares etc.
Hi Steve,
thanks for the reply.
The problem is that I need to force a patch application (like patch --force
option) at my own risk.
Do you see any solution?
Giuseppe
2014-08-07 16:43 GMT+02:00 Stephen Arnold :
> Not sure if there's an easy way with quilt (check the quilt options) but a
> relat
Not sure if there's an easy way with quilt (check the quilt options) but a
relatively easy way would be to use your own patch routine (essentially
anything you want). One thing you could do is disable the normal patch
application (add ";patch=0" to the end of the patch line in SRC_URI) and
then us
On 14-08-07 01:33 AM, Koen Kooi wrote:
>
> Op 6 aug. 2014, om 22:38 heeft Paul Gortmaker
> het volgende geschreven:
>
>> commit 841ec528ec04e64bd09ff10f8d9ad2d6e3aac05d ("coreutils: update
>> to upstream version 9.21") added a patch which bypassed the check
>> for perl and hence defaults to usi
Fixed:
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `parse-events.o'. Stop.
make: *** Waiting for unfinished jobs
ERROR: oe_runmake failed
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the
.parse-events.d isn't regenerated when recompile, the
Fixed:
NOTE: make -j 32
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `kexec/kexec.o'. Stop.
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the kexec/kexec.d
isn't regenerated when recompile, the content of it are:
[snip]
kexec/kexec.o: /path/to/s
Fixed:
NOTE: make -j 32
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `test.o'. Stop.
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the .depend isn't
regenerated when recompile, the content of the .depend are:
[snip]
test.o: /path/to/sysroot/4.9.
Fixed:
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `parse-events.o'. Stop.
make: *** Waiting for unfinished jobs
ERROR: oe_runmake failed
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the
.parse-events.d isn't regenerated when recompile, the
Fixed:
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `crc32.o'. Stop.
make: *** Waiting for unfinished jobs
ERROR: oe_runmake failed
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the .depend isn't
regenerated when recompile, the content of it
The following changes since commit 1fafe7ccc563d5ac9e41f5c1de93d2736745b512:
ghostscript: Remove bogus gsfonts reference from DESCRIPTION (2014-08-06
11:14:21 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/rebuild
http://cgit.opene
Fixed:
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stdarg.h',
needed by `cpio.o'. Stop.
make: *** Waiting for unfinished jobs
ERROR: oe_runmake failed
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the .cpio.o.d isn't
regenerated when recompile (the compile happe
Fixed:
NOTE: make -j 32
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `logrotate.o'. Stop.
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the .depend isn't
regenerated when recompile, the content of the .depend are:
[snip]
logrotate.o: /path/to/sy
On 07/08/2014 14:05, Paul Eggleton wrote:
> Hi Alex,
>
> On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote:
>> On 07/08/2014 10:10, Paul Eggleton wrote:
>> fwiw Upgrade solutions are something that is still a read need imho, as
>> I think we discussed at one of the FOSDEMs.
>>
>> (The other
Hi All,
please can I know if is it possible, using the do_patch routine,
to force the application of a given patch?
I mean, like the patch --force command.
Please let me know, I tried w/o good result.
Best Regards,
Giuseppe
--
___
Openembedded-core ma
Hi Alex,
On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote:
> On 07/08/2014 10:10, Paul Eggleton wrote:
> fwiw Upgrade solutions are something that is still a read need imho, as
> I think we discussed at one of the FOSDEMs.
>
> (The other real need being an on-board test framework, again im
From: Shrikant Bobade
When pigz-native and zlib-native are coming from sstate the setscenes might
not necessarily run in the expected order. The problem happens when setscene
for pigz-native runs before setscene for zlib-native. To fix the issue
do_populate_sysroot_setscene[depends] should be pro
From: Shrikant Bobade
Without this, we can get setscene postinst failure due to libjpeg being
unavailable.
Signed-off-by: Christopher Larson
Signed-off-by: Shrikant Bobade
---
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipe
On Thu, Aug 07, 2014 at 04:52:23AM -0500, Peter A. Bigot wrote:
> On 08/04/2014 03:16 PM, Otavio Salvador wrote:
> > On Fri, Aug 1, 2014 at 10:07 PM, Peter A. Bigot wrote:
> >> On 07/14/2014 04:21 AM, Peter A. Bigot wrote:
> >>> I'm finding attempts to use pwclient on
> >>> http://patches.openembe
On 07/08/2014 10:10, Paul Eggleton wrote:
> Hi folks,
>
> As most of you know within the Yocto Project and OpenEmbedded we've been
> trying to figure out how to improve the OE developer workflow. This
> potentially
> covers a lot of different areas, but one in particular I where think we can
>
On 08/04/2014 03:16 PM, Otavio Salvador wrote:
On Fri, Aug 1, 2014 at 10:07 PM, Peter A. Bigot wrote:
On 07/14/2014 04:21 AM, Peter A. Bigot wrote:
I'm finding attempts to use pwclient on
http://patches.openembedded.org/xmlrpc/ produce an ExpatError because the
returned document is always empt
Hi Paul Eggleton,
On Thu, Aug 7, 2014 at 2:54 PM, Sujith H wrote:
> From: Sujith H
>
> This is needed to deal with the situation where we're using ipk packaging,
> so
> opkg-utils must be built regardless of what update-alternatives provider we
> prefer. The downside to the current implementat
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is
Hi folks,
As most of you know within the Yocto Project and OpenEmbedded we've been
trying to figure out how to improve the OE developer workflow. This potentially
covers a lot of different areas, but one in particular I where think we can
have some impact is helping application developers - peo
Default core image actually includes packagegroup-base-extended, not
just packagegroup-base.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/classes/core-image.bbclass b/meta/classes/core-image.bbclass
index 67e11bf..62363fb 100644
--- a/meta/classes/core-image.bbclass
+++ b/meta/classes
On 08/07/2014 04:38 AM, Paul Gortmaker wrote:
commit 841ec528ec04e64bd09ff10f8d9ad2d6e3aac05d ("coreutils: update
to upstream version 9.21") added a patch which bypassed the check
for perl and hence defaults to using the dummy man page for all
of the coreutils manpages. This results in all manpa
The /etc/init.d/fbsetup script doesn't have any effect in a systemd
image. Its purpose is to load the uvesafb kernel module at boot.
This functionality could be achieved by adding a configuration file
under /etc/modules-load.d/ directory which would be parsed by the
systemd-modules-load.service.
[
The following changes since commit 1fafe7ccc563d5ac9e41f5c1de93d2736745b512:
ghostscript: Remove bogus gsfonts reference from DESCRIPTION (2014-08-06
11:14:21 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib
ChenQi/systemd_alsa-state_v86d
The /etc/init.d/alsa-state is totally useless for a systemd image.
Its functionality has been replaced by alsa-state.service files.
So if 'sysvinit' is not in DISTRO_FEATURES, installing this script doesn't
make any sense.
[YOCTO #4420]
Signed-off-by: Chen Qi
---
meta/recipes-bsp/alsa-state/al
wrt Saul's comment, feel free to steal from
http://lists.openembedded.org/pipermail/openembedded-core/2014-April/091622.html
where I wrote why the patches are dropped.
On 6 August 2014 20:23, Yasir Khan wrote:
> From: Yasir-Khan
>
> Current trace-cmd version 1.2 throws "recorder error in
> spli
63 matches
Mail list logo
