* busybox installs getopt u-a in base_bindir when GETOPT is enabled, move
util-linux
link to the same location to fix calling u-a in read-only images
* remove unused variable usrbinprogs_a
Signed-off-by: Martin Jansa
---
meta/recipes-core/util-linux/util-linux.inc | 6 +++---
1 file changed,
On Fri, Feb 27, 2015 at 10:23:22AM +0100, Martin Jansa wrote:
> On Mon, Feb 09, 2015 at 01:25:15PM +0100, Martin Jansa wrote:
> > * it's not complete, but recipes depending on virtual/libx11 are easiest
> > to spot, I've long list of PNBLACKLIST for all recipes which cannot
> > be built in dist
The pre-processed output of conftest.c contains an include dir
and if the path of it contains a 'yes' it will cause some variables
to be wrongly set to yes because of the way it greps for it.
The fix is to use a more elaborated string instead of just 'yes'.
This has to be done at the configure and
Yadif generates bad assembler when the x32 tune is enabled:
gst/yadif/yadif_template.c:244: Error: `(%edx,%r11)' is not a valid base/index
expression
This should be fixed upstream but until then we can disable the Yadif
plugin if x32 is enabled.
[ YOCTO #7385 ]
Signed-off-by: Ross Burton
---
Richard,
Here's my next round of incremental fixes and updates. All are relatively
minor, so there's no sense sitting on them while I work on some other
changes.
These two are tweaks to the Kconfig audit warnings that went into M3, and
will remove a config warning and the other will not uncessari
We don't require that a yocto custom kernel + defconfig have a full BSP
description (but of course it would be better if they did). Since this
isn't a requirement, we shouldn't alarm users by generating a BSP
description warning.
To implement this, we add a bsp audit level flag (like the one that
During the 3.19 update a 32 bit option in the 64 bit config was missed,
which results in the option being dropped (and reported as a warning):
Value requested for CONFIG_PCI_GOANY not in final ".config"
Requested value: "CONFIG_PCI_GOANY=y"
Actual value set: ""
So we split the 32bit only dr
Update the SRCREV for the following incremental improvement in patch
processing time:
kgit-meta: skip patches on non-leaf nodes
In a similar way as commit 0768d697 [kgit-meta: dont run kgit-s2q
for
non-leaf nodes], we can save even more processing time by not even
analysing an
With these SRCREV updates, we add the following support to the kernel:
The following has been verified with the branch sources:
On 68xx:
* SGMII, XAUI Packet IO interfaces.
* PCIe devices
* EHCI/OHCI USB driver
On 78XX:
* Ran LTP testsuite
* SGMII, XAUI Packet IO interfaces
Hello Randy,
On Sex, 2015-02-06 at 10:45 -0800, Randy Witt wrote:
> On 02/04/2015 09:04 AM, Bruno Bottazzini wrote:
> > It wil be able to choose what systemd module to be installed.
> > The final result may get smaller, if the user wanted to.
> > By default it will install the whole systemd which
If we compile using EXTRA_OECONF with '--disable-tests' option, the files
test-udev and systemd-journal-flush will not be created and the systemd
install phase will fail.
---
meta/recipes-core/systemd/systemd_219.bb | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/r
The test added verifies that when a file with an absolute path in
LIC_FILES_CHKSUM changes without a corresponding change to the md5sum,
it triggers the license qa test again with a failure.
[Yocto #6450]
Signed-off-by: Randy Witt
---
meta-selftest/recipes-test/emptytest/emptytest.bb | 5
The following changes since commit bf1a68e97f2069a4f4c351d4bafd416358eb:
taglib: Fix cmake floating dependency on boost (2015-03-02 18:06:53 +)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib rewitt/license_fix
for you to fetch changes up to a35e9afe3
Previously, files with absolute paths in LIC_FILES_CHKSUM such as
"file://${COMMON_LICENSE_DIR}/foo" would not result in a qa failure
when the license file changed.
To fix this problem, add any files with absolute paths from
LIC_FILES_CHKSUM to the file-checksums varflag, so that changes in the
li
On Mon, Mar 2, 2015 at 10:12 AM, Laszlo Papp wrote:
> Signed-off-by: Laszlo Papp
> ---
> meta/recipes-core/busybox/busybox.inc | 12 +++--
> meta/recipes-core/busybox/busybox_1.23.1.bb | 2 +
> meta/recipes-core/busybox/files/busybox-ntpd | 54
> +++
>
On 28/02/15 14:39, Michael Gloff wrote:
I'm not sure how to proceed, but this pretty much breaks nfs server
capabilities.
Hi Michael, could you please file a bug on
https://bugzilla.yoctoproject.org/
--
___
Openembedded-core mailing list
Op
On 02-03-15 16:45, Paul Eggleton wrote:
Hi Mike,
On Monday 02 March 2015 15:54:04 Mike Looijmans wrote:
Here's the problem, running in a devshell:
# echo '#include ' > /tmp/compileme.c
# $CC -c -fopenmp /tmp/compileme.c
/tmp/compileme.c:1:17: fatal error: omp.h: No such file or directory
#i
On 28/02/15 14:39, Michael Gloff wrote:
All,
I have run into the issue of nfs server seg faulting when trying to
start. After some searching I found that it is related to GCC 4.9.x
and nfs-utils-1.3.X
http://lists.linuxfromscratch.org/pipermail/blfs-dev/2014-July/027853.html
There is a patc
On 2 March 2015 at 01:37, Chen Qi wrote:
> If 'networkd' is enabled in PACKAGECONFIG, the do_install variable cannot
> be correctly expanded. Error message is like below.
>
> Failure expanding variable do_install: ShellSyntaxError: LexToken(Fi,'fi',0,0)
> followed by:
> LexToken(NEWLINE,'\n',0,0
On Thu, 2015-02-26 at 08:17 -0800, Khem Raj wrote:
> On Thu, Feb 26, 2015 at 4:22 AM, Burton, Ross wrote:
> >
> > On 25 February 2015 at 18:14, Benjamin Esquivel
> > wrote:
> >>
> >> Saul, is there a specific part of the glibc's run.do_configure that
> >> should re-conf?
> >
> >
> > The glibc rec
On Thu, 2015-02-26 at 08:18 -0800, Khem Raj wrote:
> On Mon, Feb 23, 2015 at 1:54 AM, Benjamin Esquivel
> wrote:
> > The pre-processed output of conftest.c contains an include dir
> > and if the path of it contains a 'yes' it will cause some variables
> > to be wrongly set to yes because of the wa
Hi Mike,
On Monday 02 March 2015 15:54:04 Mike Looijmans wrote:
> Here's the problem, running in a devshell:
>
> # echo '#include ' > /tmp/compileme.c
> # $CC -c -fopenmp /tmp/compileme.c
> /tmp/compileme.c:1:17: fatal error: omp.h: No such file or directory
> #include
> ^
>
Here's the problem, running in a devshell:
# echo '#include ' > /tmp/compileme.c
# $CC -c -fopenmp /tmp/compileme.c
/tmp/compileme.c:1:17: fatal error: omp.h: No such file or directory
#include
^
compilation terminated.
The #pragma's and linking of OpenMP work just fine, it'
On Mon, 2015-03-02 at 11:49 +, Peter Gejgus wrote:
> Hello,
>
> This is the excerpt of my bitbake class:
>
> data_migration_common() {
> if [ x"$D" = "x" ]; then
> if [[ ! ${CURRENT_DATA_VERSION} =~ ^[0-9]?[0-9].[0-9]?[0-9]$
> ]]; then
> error-exit "
These recipes both fail to build with "relocation R_X86_64_PC32 against
undefined hidden symbol `__init_array_start' can not be used when making a
shared object" when using PIE.
Signed-off-by: Ross Burton
---
meta/conf/distro/include/security_flags.inc |2 ++
1 file changed, 2 insertions(+)
Hello,
This is the excerpt of my bitbake class:
data_migration_common() {
if [ x"$D" = "x" ]; then
if [[ ! ${CURRENT_DATA_VERSION} =~ ^[0-9]?[0-9].[0-9]?[0-9]$
]]; then
error-exit "Version information was provided in invalid
format!"
Whilst Sato still uses GTK+ 2 we don't want the overhead of building both GTK+ 2
and GKT+ 3. Luckily gtk-play is a simple application and it's just a small
patch away from building with GTK+ 2.
When Sato is ported to GTK+ 3 (the mythical Shuku proposal) this patch can be
removed.
Signed-off-by:
gcc-source don't do do_package_write_rpm, so we should set
PACKAGES = "" to avoid the building error if we want generate srpm,
otherwise, we get the error as below.
ERROR: Task do_deploy_archives in meta/recipes-devtools/gcc/gcc-source_4.9.bb \
depends upon non-existent task do_package_writ
On 2 March 2015 at 10:29, Peter Urbanec
wrote:
> I'm completely in favour of this change from the security point of view.
> However, it is likely to trip up a few people, so the change in behaviour
> should be prominently highlighted in the release notes. I also think that
> it may be a good idea
Hi,
On 02.03.2015 11:27, Martin Jansa wrote:
> Wrong ML, please resend to oe-devel.
oh indeed - sorry...
Greetings
Florian
--
The dream of yesterday Florian Boor
is the hope of todayTel: +49 271-771091-15
and the reality of tomorrow.Fax: +49 27
The libltdl libraries are put in libltdl-* packages, but libltdl.la
is packaged in libtool-dev. This change puts libltdl.la in libltdl-dev
package instead of libtool-dev.
Signed-off-by: Li Zhou
---
meta/recipes-devtools/libtool/libtool-2.4.6.inc |1 +
1 file changed, 1 insertion(+)
diff --g
On 28/02/15 03:07, Burton, Ross wrote:
IIRC the general argument is if that if you're assuming a self-signed
certification is valid, you've lost so much security. We're in the
middle of a development cycle so this will only impact people using or
moving to 1.8.
I'm completely in favour of this
On Mon, Mar 02, 2015 at 11:15:13AM +0100, Florian Boor wrote:
> From: Florian Boor
>
> Tested building for MIPS 32bit QEMU
Wrong ML, please resend to oe-devel.
>
> Signed-off-by: Florian Boor
> ---
> .../fltk/fltk-1.1.10/fltk-no-freetype-config.patch | 18
> ++
> meta-oe
From: Florian Boor
Tested building for MIPS 32bit QEMU
Signed-off-by: Florian Boor
---
.../fltk/fltk-1.1.10/fltk-no-freetype-config.patch | 18 ++
meta-oe/recipes-support/fltk/fltk_1.1.10.bb |7 +++
2 files changed, 21 insertions(+), 4 deletions(-)
create
Signed-off-by: Laszlo Papp
---
meta/recipes-core/busybox/busybox.inc | 12 +++--
meta/recipes-core/busybox/busybox_1.23.1.bb | 2 +
meta/recipes-core/busybox/files/busybox-ntpd | 54 +++
meta/recipes-core/busybox/files/busybox-ntpd.conf | 2 +
4 files
On Sun, Mar 1, 2015 at 9:34 PM, Alexandre Belloni
wrote:
> On 01/03/2015 at 13:48:11 +, Laszlo Papp wrote :
>> I finally decided to get this patch another go, even though still no
>> busybox daemon has LSB headers, but I would need to ask for some prime
>> example of LSB headers that I can sta
reading YP kernel dev manual and section 2.5.1 contains the
following passage:
"Briefly, the kernel-dev package is installed by default on all *.sdk
images... Because all SDK image recipes include dev-pkgs, the
kernel-dev packages will be installed as part of the SDK image."
first, if that's
37 matches
Mail list logo
