Hi,
I'm using screen for all my terminal multiplexing. While using the
devshell feature, I want to add devshells directly to my existing screen
session. This wasn't straightforward, at least not as straightforward as
I'd like.
Made this pach: https://gist.github.com/3774736
It's just a quick hac
On 24/09/12 03:17, Khem Raj wrote:
[snip]
What does linker command looks like, its not in the above log you posted.
Hi Khem,
Is this enough information?
Building target: R0005
Invoking: GCC C Linker
arm-poky-linux-gnueabi-gcc
-L/home/jack/Projects/R0005-SDK-210912/sysroots/armv7a-vfp-
On 24 September 2012 00:22, Philip Balister wrote:
>>> Allow it to be suppressed by setting KERNEL_DEPLOY_MODULE_TARBALL=0.
>>
>> I'm wondering, does anyone still find this file useful?
>
> I've used it to put modules in rootfs when there is a new kernel version and
> I do not have easy access to
On 09/24/2012 11:37 AM, Jack Mitchell wrote:
> On 24/09/12 03:17, Khem Raj wrote:
>
> [snip]
>
>>
>>
>> What does linker command looks like, its not in the above log you posted.
>>
>>
>
> Hi Khem,
>
> Is this enough information?
>
> Building target: R0005
> Invoking: GCC C Linker
>
> arm-po
On Mon, 2012-09-24 at 07:26 +0100, Phil Blundell wrote:
> It is possible that some or all of ${bindir}, ${base_bindir},
> ${sbindir} and ${base_sbindir} might be the same directory. In
> particular, for micro it is often the case that all four are
> the same. There is clearly no point in staging
On 24/09/12 09:44, Laurentiu Palcu wrote:
On 09/24/2012 11:37 AM, Jack Mitchell wrote:
On 24/09/12 03:17, Khem Raj wrote:
[snip]
What does linker command looks like, its not in the above log you posted.
Hi Khem,
Is this enough information?
Building target: R0005
Invoking: GCC C Linker
I am trying to convert my application to use the autotools suite in
order to get a bit of control over my build. However I am hitting an
issue when trying to run autoreconf -i, I believe it is to do with
toolchain issues again...
configure.ac:17: the top level
configure.ac:7: installing './ins
On Mon, 2012-09-24 at 09:51 +0100, Richard Purdie wrote:
> Wouldn't testing whether $dest already exists work just as well?
I wasn't totally confident that $dest was guaranteed never to exist in
advance (and that we'd never want to stage multiple $srcs into a single
$dest). But yes, if both of th
On 09/24/2012 12:19 PM, Jack Mitchell wrote:
> I am trying to convert my application to use the autotools suite in
> order to get a bit of control over my build. However I am hitting an
> issue when trying to run autoreconf -i, I believe it is to do with
> toolchain issues again...
>
> configu
On 24/09/12 10:41, Laurentiu Palcu wrote:
On 09/24/2012 12:19 PM, Jack Mitchell wrote:
I am trying to convert my application to use the autotools suite in
order to get a bit of control over my build. However I am hitting an
issue when trying to run autoreconf -i, I believe it is to do with
toolc
On Mon, 2012-09-24 at 10:40 +0100, Phil Blundell wrote:
> On Mon, 2012-09-24 at 09:51 +0100, Richard Purdie wrote:
> > Wouldn't testing whether $dest already exists work just as well?
>
> I wasn't totally confident that $dest was guaranteed never to exist in
> advance
do_populate_sysroot[cleandir
On Mon, 2012-09-24 at 09:36 +0100, Burton, Ross wrote:
> On 24 September 2012 00:22, Philip Balister wrote:
> >>> Allow it to be suppressed by setting KERNEL_DEPLOY_MODULE_TARBALL=0.
> >>
> >> I'm wondering, does anyone still find this file useful?
> >
> > I've used it to put modules in rootfs whe
On Mon, 2012-09-24 at 10:54 +0100, Richard Purdie wrote:
> I'm torn whether its better to be simple or less fragile in this case.
> Or simply do some tests (if ${bindir} != ${sbindir}) and so on.
The tests would get a bit ungainly, since you'd end up with 'if !
[ "${sbindir} = "${bindir}" -o "${sb
On Wed, 2012-09-19 at 09:16 +0200, Martin Ertsaas wrote:
> bash-3.2.48 did not provide the linking from sh to bash, making it unusable.
> Moving the license part out of the bash.inc file, and into bash_4.2.bb file
> makes
> us able to use that file also for bash_3.2.48.bb, which makes maintaining
On Mon, 2012-09-24 at 13:38 +0800, Kang Kai wrote:
> Update the lsbtest's list file that we can download the latest
> sub-packages of LSB suite 4.1.0 and then run the test with them.
>
> Signed-off-by: Kang Kai
> ---
> meta/recipes-extended/lsb/lsbtest/packages_list | 46 +++---
On Sun, 2012-09-23 at 19:55 -0700, Khem Raj wrote:
> We have been adding this option to paper over a bug in old toolchain
> http://hardwarebug.org/2008/11/28/codesourcery-fails-again/
> e.g. is one but these have been weeded out. Therefore let gcc
> take the default vectorization optimizations
>
>
On Sat, 2012-09-22 at 19:42 +0100, Phil Blundell wrote:
> Use ${bindir} to locate the binary instead.
>
> Signed-off-by: Phil Blundell
> ---
> meta/recipes-core/dbus/dbus-1.6.4/dbus-1.init |2 +-
> meta/recipes-core/dbus/dbus.inc |5 +++--
> 2 files changed, 4 insertions(+)
On Sun, 2012-09-23 at 17:14 +0300, Laurentiu Palcu wrote:
> This is needed if installation is done in a directory that needs root
> privileges.
>
> Signed-off-by: Laurentiu Palcu
> ---
> .../adt-installer/scripts/adt_installer_internal |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Sat, 2012-09-22 at 17:18 +0100, Phil Blundell wrote:
> For reasons that are now shrouded in obscurity, autotools.bbclass
> has long contained a special heuristic to avoid attempting to run
> autoreconf when building autoconf or automake themselves. However,
> the wildcard test against PN which
On Sat, 2012-09-22 at 19:37 +0100, Phil Blundell wrote:
> We don't DEPEND on openssl but configure will try to use it if
> pkg-config thinks it might be installed. This can lead to failing
> and/or nondeterministic builds, so let's force it off.
>
> Signed-off-by: Phil Blundell
> ---
> meta/rec
On Sat, 2012-09-22 at 13:29 +0100, Paul Eggleton wrote:
> The following changes since commit 5e03d1e83d0536a2fc69a88d3e5407108836203f:
>
> gcc: Use 4.7.2 release tarball (2012-09-21 14:55:26 +0100)
>
> are available in the git repository at:
>
> git://git.openembedded.org/openembedded-core-c
On Sat, 2012-09-22 at 19:13 +0200, Martin Jansa wrote:
> * it doesn't make much sense with PV, because xserver-xorg-module-exa
> was introduced in
>
> http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66
> so our
On Sat, 2012-09-22 at 17:50 +0100, Phil Blundell wrote:
> This gives a small but measureable performance improvement for
> I/O heavy workloads.
>
> Signed-off-by: Phil Blundell
> ---
> meta/recipes-support/sqlite/sqlite3.inc |4
> meta/recipes-support/sqlite/sqlite3_3.7.13.bb |
On Sat, 2012-09-22 at 14:25 +0100, Phil Blundell wrote:
> Need to pass the path explicitly to "make install" to ensure that the
> binaries end up
> in the right locations.
>
> Signed-off-by: Phil Blundell
> ---
> meta/recipes-support/libcap/libcap.inc |2 +-
> meta/recipes-support/libca
On Sun, 2012-09-23 at 23:06 -0400, Bruce Ashfield wrote:
> Bumping the meta SRCREV to pickup a newer emgd for the fri2 and
> sys940x.
>
> Signed-off-by: Darren Hart
> Signed-off-by: Bruce Ashfield
> ---
> meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |3 ++-
> meta/recipes-kernel/linux/li
On Mon, 2012-09-24 at 07:24 +0100, Phil Blundell wrote:
> The configure script uses a hard-coded value for ${usrsbin_execdir},
> which is the path that we know as ${sbindir}. Adjust configure to take
> this from the environment if it's set there, and have do_configure()
> pass it in.
>
> Signed-o
On Fri, 2012-09-21 at 15:06 -0700, Scott Garman wrote:
> On Fedora systems (and likely others), ifconfig returns interface
> names that end with a colon. Make sure we strip the colon off the
> tap device name before using it.
>
> This fixes [YOCTO #3028]
>
> Signed-off-by: Scott Garman
> ---
>
On Fri, 2012-09-21 at 20:42 +0100, Phil Blundell wrote:
> If all postinsts have already been run during rootfs construction then
> there's no point in having run-postinsts in the installed system.
> Clean it up at the same time that update-rc.d and suchlike are being
> removed.
>
> Signed-off-by:
I want to build 'meta-toolchain' but on my Ubuntu 12.10 it fails on
'nativesdk-perl' recipe in do_install:
|
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.14.2/pod/perlxstut.pod
|
/usr/local/oecore-x86_64/sysroots/x86_64-oes
On Fri, 2012-09-21 at 14:11 -0500, tom.zanu...@intel.com wrote:
> From: Tom Zanussi
>
> debugfs is another kernel virtual file system that should be mounted
> if configured, so if it's configured into the kernel, mount it.
>
> Signed-off-by: Tom Zanussi
> ---
> meta/recipes-core/initscripts/in
At 09:44, Mon 2012-09-24, Morten Minde Neergaard wrote:
[…]
> * Make a new CustomTerminal terminal class that takes its command line
>from a configuration directive, e.g. OE_TERMINAL_CUSTOMCMD
> * Allowing option overrides for each of the existing classes
> * Detect the STY variable if prese
Upstream status : pending
Signed-off-by: Andrei Dinu
---
.../eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch | 25
meta/recipes-core/eglibc/eglibc_2.16.bb|1 +
2 files changed, 26 insertions(+)
create mode 100644
meta/recipes-core/eglibc/eglibc-2.16/0001-R
Please ignore. will resend.
On 09/24/2012 02:04 PM, Andrei Dinu wrote:
Upstream status : pending
Signed-off-by: Andrei Dinu
---
.../eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch | 25
meta/recipes-core/eglibc/eglibc_2.16.bb|1 +
2 files changed, 26 i
On Mon, Sep 24, 2012 at 02:04:47PM +0300, Andrei Dinu wrote:
> Upstream status : pending
>
> Signed-off-by: Andrei Dinu
> ---
> .../eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch | 25
>
> meta/recipes-core/eglibc/eglibc_2.16.bb|1 +
> 2 files changed, 26
Solution provided by Donn Seeley in bug 1443:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1443
worked when testing with core-image-sato-sdk for qemuarm.
[YOCTO #2577]
Signed-off-by: Andrei Dinu
---
.../eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch | 27
meta/recip
On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
> +-*reloc_addr += sym->st_value;
> ++*reloc_addr = sym->st_value;
That patch looks slightly dubious to me. Are you sure this doesn't
introduce any regressions elsewhere?
p.
___
O
Signed-off-by: Phil Blundell
---
meta/recipes-kernel/kexec/kexec-tools.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/kexec/kexec-tools.inc
b/meta/recipes-kernel/kexec/kexec-tools.inc
index 278ce34..ee1f1e8 100644
--- a/meta/recipes-kernel/kexec/ke
On 09/24/2012 04:36 AM, Burton, Ross wrote:
On 24 September 2012 00:22, Philip Balister wrote:
Allow it to be suppressed by setting KERNEL_DEPLOY_MODULE_TARBALL=0.
I'm wondering, does anyone still find this file useful?
I've used it to put modules in rootfs when there is a new kernel versio
Changelog since 2012-09-16 until 2012-09-23. Projects included in this report:
bitbake: git://git.openembedded.org/bitbake
openembedded-core: git://git.openembedded.org/openembedded-core
meta-openembedded: git://git.openembedded.org/meta-openembedded
meta-smartphone: http://git.shr-project.org/re
The version-specific .inc was shared with the xserver-xorg-lite package, but
that doesn't exist anymore.
Signed-off-by: Ross Burton
---
.../recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc | 11 ---
meta/recipes-graphics/xorg-xserver/xserver-xorg_1.11.2.bb | 13 -
2
Signed-off-by: Ross Burton
---
.../xorg-driver/xf86-input-evdev_2.7.0.bb | 21
.../xorg-driver/xf86-input-evdev_2.7.3.bb | 20 +++
2 files changed, 20 insertions(+), 21 deletions(-)
delete mode 100644 meta/recipes-graphics/xorg-driver/xf
Signed-off-by: Ross Burton
---
meta/recipes-graphics/xorg-driver/xf86-video-fbdev_0.4.2.bb |8
meta/recipes-graphics/xorg-driver/xf86-video-fbdev_0.4.3.bb |8
2 files changed, 8 insertions(+), 8 deletions(-)
delete mode 100644 meta/recipes-graphics/xorg-driver/xf86-vide
gcc-47-warning.patch was integrated, so drop.
Signed-off-by: Ross Burton
---
.../xserver-xorg-1.11.2/crosscompile.patch | 22 -
.../fix_open_max_preprocessor_error.patch | 15 -
.../xserver-xorg-1.11.2/gcc-47-warning.patch | 33 ---
Ignore this for now, it's causing the keyboard driver to explicitly
depend on things it shouldn't be.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 09/24/2012 02:30 PM, Phil Blundell wrote:
On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
+- *reloc_addr += sym->st_value;
++ *reloc_addr = sym->st_value;
That patch looks slightly dubious to me. Are you sure this doesn't
introduce any regressions elsewhere?
p.
I
On Mon, Sep 24, 2012 at 1:19 PM, Gary Thomas wrote:
> On 2012-09-24 04:51, Richard Purdie wrote:
>>
>> On Wed, 2012-09-19 at 12:02 +0300, Florin wrote:
>>>
>>> Trying to build something today and still takes forever and crashes at
>>> fetch. Looking at the gcc-4.7.inc I see it's still from git.
>>
On Mon, Sep 24, 2012 at 10:35:50AM +, g...@git.openembedded.org wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: 6fdca45ec85e226f570917d2d1aaa2aa39ab6b42
> URL:
> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=6fdca45ec85e226f570917d2d1aaa2aa39ab6b42
>
> A
On Mon, Sep 24, 2012 at 10:35:53AM +, g...@git.openembedded.org wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: 3dffb9f577b794e8b78fb884adf9a15c45965bc4
> URL:
> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=3dffb9f577b794e8b78fb884adf9a15c45965bc4
>
> A
On Mon, 2012-09-24 at 15:48 +0200, Martin Jansa wrote:
> On Mon, Sep 24, 2012 at 10:35:53AM +, g...@git.openembedded.org wrote:
> > do_install() {
> > - oe_runmake install DESTDIR="${D}" prefix="${prefix}"
> > + oe_runmake install DESTDIR="${D}" prefix="${prefix}"
> > SBINDIR="${D}${base_
On Mon, Sep 24, 2012 at 11:20:03AM +0100, Richard Purdie wrote:
> On Sat, 2012-09-22 at 19:13 +0200, Martin Jansa wrote:
> > * it doesn't make much sense with PV, because xserver-xorg-module-exa
> > was introduced in
> >
> > http://git.openembedded.org/openembedded-core/commit/meta/recipes-gra
On 09/24/2012 04:26 AM, Andrei Dinu wrote:
Solution provided by Donn Seeley in bug 1443:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1443
worked when testing with core-image-sato-sdk for qemuarm.
[YOCTO #2577]
Signed-off-by: Andrei Dinu
---
.../eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patc
Solution provided by Donn Seeley in bug 1443:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1443
worked when testing with core-image-sato-sdk for qemuarm.
[YOCTO #2577]
Signed-off-by: Andrei Dinu
---
.../eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch | 56
meta/recip
Note that as noted in the patch this relies upon the task tainting
feature in bitbake; this will do nothing with versions of bitbake that
do not have that feature.
The following changes since commit 95756cfbb7a9348b23cb46a49a5509e57e973faf:
valgrind: fix default.supp missing issue (2012-08-21
Ensure the following results in the kernel being rebuilt, repackaged and
re-deployed in the final step:
bitbake virtual/kernel
bitbake -c menuconfig virtual/kernel
[ make changes to the kernel configuration and save ]
bitbake virtual/kernel
If there are no changes to the configuration saved, the
On Monday, September 24, 2012, Jack Mitchell wrote:
> On 24/09/12 09:44, Laurentiu Palcu wrote:
>>
>> On 09/24/2012 11:37 AM, Jack Mitchell wrote:
>>>
>>> On 24/09/12 03:17, Khem Raj wrote:
>>>
>>> [snip]
>>>
What does linker command looks like, its not in the above log you
posted.
Since updating to the latest versions of bitbake and oe-core I'm
experiencing some sort of conflict to do with the gcc sources in
tmp/work-shared.
What seems to be happening is that all the different recipes which share
that source directory are using different stamp values for do_unpack.
So, for
On 09/24/2012 08:38 AM, Phil Blundell wrote:
Since updating to the latest versions of bitbake and oe-core I'm
experiencing some sort of conflict to do with the gcc sources in
tmp/work-shared.
What seems to be happening is that all the different recipes which share
that source directory are using
On Mon, 2012-09-24 at 08:42 -0700, Saul Wold wrote:
> Yes, I am seeing something similar with do_patch happening twice on the
> work-shared area, I talked with Richard a bit ago about it, and I am
> digging into the siginfo files, you can use bitbake-sigdiff to see what
> sigs are changed causin
During a from scratch build test, cogl build failed due missing
libxdamage dependency not being explicit.
Signed-off-by: Otavio Salvador
---
meta/recipes-graphics/clutter/cogl.inc |2 +-
meta/recipes-graphics/clutter/cogl_1.8.2.bb |2 +-
meta/recipes-graphics/clutter/cogl_git.bb |
During a from scratch build test, cogl build failed due a missing
dependency on libxdamage.
Signed-off-by: Otavio Salvador
---
meta/recipes-graphics/clutter/cogl.inc |2 +-
meta/recipes-graphics/clutter/cogl_1.8.2.bb |2 +-
meta/recipes-graphics/clutter/cogl_git.bb |2 +-
3 fi
On Mon, Sep 24, 2012 at 4:49 AM, Phil Blundell wrote:
>
> -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)'
> +COMPATIBLE_HOST =
> '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux|freebsd.*)'
I wonder if this expression should be removed completely now that mips is added
w
From: Christopher Larson
This avoids the hardcoding of ${libdir}/locale which is all over the place,
and will facilitate use of ${exec_prefix}/lib/locale instead of
${libdir}/locale.
This doesn't actually change any output at this time. Verified this with
buildhistory against the packages produc
On Mon, Sep 24, 2012 at 1:28 PM, Khem Raj wrote:
> On Mon, Sep 24, 2012 at 4:49 AM, Phil Blundell wrote:
>>
>> -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)'
>> +COMPATIBLE_HOST =
>> '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux|freebsd.*)'
>
> I wonder if this expre
On Mon, Sep 24, 2012 at 12:10 PM, McClintock Matthew-B29882
wrote:
> On Mon, Sep 24, 2012 at 1:28 PM, Khem Raj wrote:
>> On Mon, Sep 24, 2012 at 4:49 AM, Phil Blundell wrote:
>>>
>>> -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)'
>>> +COMPATIBLE_HOST =
>>> '(x86_64.*|i
On Mon, Sep 24, 2012 at 05:22:57PM +0100, Phil Blundell wrote:
> On Mon, 2012-09-24 at 08:42 -0700, Saul Wold wrote:
> > Yes, I am seeing something similar with do_patch happening twice on the
> > work-shared area, I talked with Richard a bit ago about it, and I am
> > digging into the siginfo fi
Fixes these sorts of issues present on older gcc (CentOS 5.x in this case)
| cc1: error: unrecognized command line option "-Werror=implicit"
| cc1: error: unrecognized command line option "-Werror=nonnull"
| cc1: error: unrecognized command line option "-Werror=init-self"
| cc1: error: unrecognize
On Mon, Sep 24, 2012 at 02:55:45PM -0500, Matthew McClintock wrote:
> Fixes these sorts of issues present on older gcc (CentOS 5.x in this case)
>
> | cc1: error: unrecognized command line option "-Werror=implicit"
> | cc1: error: unrecognized command line option "-Werror=nonnull"
> | cc1: error:
On Mon, Sep 24, 2012 at 02:54:03PM +0100, Phil Blundell wrote:
> On Mon, 2012-09-24 at 15:48 +0200, Martin Jansa wrote:
> > On Mon, Sep 24, 2012 at 10:35:53AM +, g...@git.openembedded.org wrote:
> > > do_install() {
> > > - oe_runmake install DESTDIR="${D}" prefix="${prefix}"
> > > + oe_runmak
On Mon, Sep 24, 2012 at 3:00 PM, Martin Jansa wrote:
> On Mon, Sep 24, 2012 at 02:55:45PM -0500, Matthew McClintock wrote:
>> Fixes these sorts of issues present on older gcc (CentOS 5.x in this case)
>>
>> | cc1: error: unrecognized command line option "-Werror=implicit"
>> | cc1: error: unrecogn
makekeys-makekeys.o: In function `main':
makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf'
collect2: ld returned 1 exit status
make: *** [makekeys] Error 1
Older libc do not have this defined, we can use the -D_GNU_S
On Mon, Sep 24, 2012 at 2:55 PM, Matthew McClintock wrote:
> makekeys-makekeys.o: In function `main':
> makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
> makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf'
> collect2: ld returned 1 exit status
> make: *** [makekeys]
On Mon, 2012-09-24 at 11:28 -0700, Khem Raj wrote:
> On Mon, Sep 24, 2012 at 4:49 AM, Phil Blundell wrote:
> >
> > -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)'
> > +COMPATIBLE_HOST =
> > '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux|freebsd.*)'
>
> I wonder if this
Updating the machine and meta SRCREVs to the latest 3.4.x -stable
release.
See git whatchanged v3.4.10..v3.4.11 for the full changelog.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |8
meta/recipes-kernel/linux/linux-yocto_3.4.bb| 16 +
Richard/Saul,
Updating the 3.4 trees SRCREVs to pickup the korg v3.4.11 -stable
and some minor tweaks to the beagleboard config to prep for a switch
to 3.4 as the preferred kernel version.
Build and boot tested on qemu* and build testing was done the hardware
reference boards.
Cheers,
Bruce
Th
Updating to pickup a couple of configuration tweaks that were done
as part of a bump to the 3.4 linux-yocto tree for the beagleboard.
In particular, this updates DVI and USB settings to enable the
perhipherals out of the box.
Signed-off-by: Liang Li
Signed-off-by: Bruce Ashfield
---
meta/recip
On Fri, Jun 15, 2012 at 1:12 AM, Khem Raj wrote:
> -fstack-protector needs libssp to link with
> so when checking for this option support we
> need to find if libssp is staged in root file
> system
Won't this still break on systems without libssp where sstate-cache
was built on systems with libss
On Mon, 2012-09-24 at 21:23 +0100, Phil Blundell wrote:
> On Mon, 2012-09-24 at 11:28 -0700, Khem Raj wrote:
> > On Mon, Sep 24, 2012 at 4:49 AM, Phil Blundell wrote:
> > >
> > > -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)'
> > > +COMPATIBLE_HOST =
> > > '(x86_64.*|i.8
On 24 September 2012 21:06, McClintock Matthew-B29882
wrote:
>> Shouldn't it be applied only for -native? version?
>
> That's reasonable. But, suppressing warnings to compile logs also did
> not seem to matter much since we don't go line by line on warnings in
> compile logs (does anyone?). I'll g
On Mon, Sep 24, 2012 at 3:06 PM, Matthew McClintock wrote:
> On Mon, Sep 24, 2012 at 3:00 PM, Martin Jansa wrote:
>> On Mon, Sep 24, 2012 at 02:55:45PM -0500, Matthew McClintock wrote:
>>> Fixes these sorts of issues present on older gcc (CentOS 5.x in this case)
>>>
>>> | cc1: error: unrecognize
On Mon, Sep 24, 2012 at 12:00 PM, Christopher Larson wrote:
> From: Christopher Larson
>
> This avoids the hardcoding of ${libdir}/locale which is all over the place,
> and will facilitate use of ${exec_prefix}/lib/locale instead of
> ${libdir}/locale.
what is adavantage of letting use ${exec_pr
On Mon, Sep 24, 2012 at 2:00 PM, Khem Raj wrote:
> On Mon, Sep 24, 2012 at 12:00 PM, Christopher Larson
> wrote:
>> From: Christopher Larson
>>
>> This avoids the hardcoding of ${libdir}/locale which is all over the place,
>> and will facilitate use of ${exec_prefix}/lib/locale instead of
>> ${
On Mon, Sep 24, 2012 at 1:43 PM, McClintock Matthew-B29882
wrote:
> On Mon, Sep 24, 2012 at 3:06 PM, Matthew McClintock
> wrote:
>> On Mon, Sep 24, 2012 at 3:00 PM, Martin Jansa wrote:
>>> On Mon, Sep 24, 2012 at 02:55:45PM -0500, Matthew McClintock wrote:
Fixes these sorts of issues prese
On Mon, Sep 24, 2012 at 1:13 PM, McClintock Matthew-B29882
wrote:
> On Mon, Sep 24, 2012 at 2:55 PM, Matthew McClintock
> wrote:
>> makekeys-makekeys.o: In function `main':
>> makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
>> makekeys.c:(.text+0xa7): undefined reference to `__
On 9/24/12 4:04 PM, Chris Larson wrote:
On Mon, Sep 24, 2012 at 2:00 PM, Khem Raj wrote:
On Mon, Sep 24, 2012 at 12:00 PM, Christopher Larson wrote:
From: Christopher Larson
This avoids the hardcoding of ${libdir}/locale which is all over the place,
and will facilitate use of ${exec_prefix}
On Mon, Sep 24, 2012 at 2:11 PM, Mark Hatle wrote:
> On 9/24/12 4:04 PM, Chris Larson wrote:
>>
>> On Mon, Sep 24, 2012 at 2:00 PM, Khem Raj wrote:
>>>
>>> On Mon, Sep 24, 2012 at 12:00 PM, Christopher Larson
>>> wrote:
From: Christopher Larson
This avoids the hardcoding of
On Mon, Sep 24, 2012 at 2:04 PM, Chris Larson wrote:
>
> This is the case by default for all eglibc builds that set libdir to
> the default. See https://gist.github.com/3756705 — there's another
> block just like that for all the other 64 bit archs for eglibc. When
> we pass —libdir=/usr/lib64, it
On Mon, Sep 24, 2012 at 1:36 PM, McClintock Matthew-B29882
wrote:
>
> Won't this still break on systems without libssp where sstate-cache
> was built on systems with libssp?
these two systems are not same IMO so native sstate should not be
shared here it will break more than rpm.
___
On Mon, Sep 24, 2012 at 2:16 PM, Khem Raj wrote:
> On Mon, Sep 24, 2012 at 2:04 PM, Chris Larson wrote:
>>
>> This is the case by default for all eglibc builds that set libdir to
>> the default. See https://gist.github.com/3756705 — there's another
>> block just like that for all the other 64 bit
The directory used as SBINDIR should be ${sbindir} not ${base_sbindir}.
Reported by Martin Jansa
Signed-off-by: Phil Blundell
---
meta/recipes-support/libcap/libcap.inc |2 +-
meta/recipes-support/libcap/libcap_2.22.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --
On 09/24/2012 12:55 PM, Matthew McClintock wrote:
makekeys-makekeys.o: In function `main':
makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf'
collect2: ld returned 1 exit status
make: *** [makekeys] Error 1
Older li
When doing multilib builds rpm does not find libgcc1 for lib32
multilib because its not honoring the debian renaming scheme for
libgcc-multilib. Lets add MLPREFIX to fix it.
Signed-off-by: Khem Raj
---
meta/recipes-devtools/gcc/gcc-common.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion
On Mon, Sep 24, 2012 at 4:18 PM, Khem Raj wrote:
> On Mon, Sep 24, 2012 at 1:36 PM, McClintock Matthew-B29882
> wrote:
>>
>> Won't this still break on systems without libssp where sstate-cache
>> was built on systems with libssp?
>
> these two systems are not same IMO so native sstate should not
On Mon, Sep 24, 2012 at 4:07 PM, Chris Larson wrote:
> On Mon, Sep 24, 2012 at 1:43 PM, McClintock Matthew-B29882
> wrote:
>> On Mon, Sep 24, 2012 at 3:06 PM, Matthew McClintock
>> wrote:
>>> On Mon, Sep 24, 2012 at 3:00 PM, Martin Jansa
>>> wrote:
On Mon, Sep 24, 2012 at 02:55:45PM -050
On Mon, Sep 24, 2012 at 4:08 PM, Chris Larson wrote:
> On Mon, Sep 24, 2012 at 1:13 PM, McClintock Matthew-B29882
> wrote:
>> On Mon, Sep 24, 2012 at 2:55 PM, Matthew McClintock
>> wrote:
>>> makekeys-makekeys.o: In function `main':
>>> makekeys.c:(.text+0x85): undefined reference to `__isoc99_
On Mon, Sep 24, 2012 at 4:52 PM, Saul Wold wrote:
> On 09/24/2012 12:55 PM, Matthew McClintock wrote:
>>
>> makekeys-makekeys.o: In function `main':
>> makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
>> makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf'
>> collect2
On Mon, Sep 24, 2012 at 3:52 PM, Burton, Ross wrote:
> On 24 September 2012 21:06, McClintock Matthew-B29882
> wrote:
>>> Shouldn't it be applied only for -native? version?
>>
>> That's reasonable. But, suppressing warnings to compile logs also did
>> not seem to matter much since we don't go lin
This fixes errors when building native recipes like below
Additionally fix some space issues.
/work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
line 981: /work/yocto/poky/build/tmp/sysroots/x86_64-linux//bin/sed: No
such file or directory
| x86_64-linux-libtool: compi
[Not heavily tested, but sent for discussion]
task-core-sdk is too big - for example, I simply don't want to ship tcl, ever =)
Historically distcc caused a large dependency graph explosion because it has
a utility which uses gtk+, although that was fixed.
packagegroup-core-sdk also includes coreu
This solves a problem when installing rpm using the ipk pkg-management
system where /var/cache was conflicting with the existing /var/cache from
base-files.
Signed-off-by: Saul Wold
---
meta/recipes-devtools/rpm/rpm_5.4.9.bb |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Hello,
If this works I'll hopefully be submitting the cover letter only,
this patchset is pretty big.
I've got a lot of patches for denzil now that I'd like to get merged
before they get too out of hand, so here is my pull request for it,
along with autobuilder output and explanation.
Note, the
100 matches
Mail list logo
