On 04/26/2013 08:08 PM, Burton, Ross wrote:
Hi,
On 26 April 2013 12:41, Robert Yang wrote:
The error message:
File "/path/to/glib-2.34.3/gio/gdbus-2.0/codegen/parser.py", line 25, in
import xml.parsers.expat
ImportError: No module named xml.parsers.expat
make[2]: *** [gdbus-daemon
oe defines libexecdir to be different for each package which breaks
the expectations of dropbear which searches 'sftp-server' within
${libexecdir}.
Patch tries to guess the correct location of the sftp-server helper
program by testing for oe's idea of libexecdir. People on irc told
they are using
On Fri, 2013-04-26 at 12:43 +0100, Burton, Ross wrote:
> On 26 April 2013 12:35, Phil Blundell wrote:
> > If pango is configured --with-included-modules then the modules
> > directory may not exist. This leads to python traceback spew and
> > a build failure when trying to run do_split_packages()
On 4/26/13 9:50 AM, Otavio Salvador wrote:
On Fri, Apr 26, 2013 at 11:41 AM, Phil Blundell wrote:
On Fri, 2013-04-26 at 09:39 -0500, Mark Hatle wrote:
On 4/26/13 9:27 AM, Phil Blundell wrote:
On Fri, 2013-04-26 at 09:16 -0500, Mark Hatle wrote:
The alternative of course is to crease special
From: Tomas Frydrych
There is no good reason for ia32 machines to have hard dependency on grub,
as there are other bootloaders available for ia32 platforms.
---
meta/conf/machine/include/ia32-base.inc |1 -
1 file changed, 1 deletion(-)
diff --git a/meta/conf/machine/include/ia32-base.inc
Hi Mark,
Le Fri, 26 Apr 2013 09:46:20 -0500,
Mark Hatle a écrit :
> I see, it's using ld instead of gcc for linking. AFAIK though, you really
> shouldn't be using -lgcc in either uboot or linux for any platform. That
> seems
> suspicious to me.
>
u-boot is using libgcc in its makefile (Linu
On Fri, Apr 26, 2013 at 11:41 AM, Phil Blundell wrote:
> On Fri, 2013-04-26 at 09:39 -0500, Mark Hatle wrote:
>> On 4/26/13 9:27 AM, Phil Blundell wrote:
>> > On Fri, 2013-04-26 at 09:16 -0500, Mark Hatle wrote:
>> >> The alternative of course is to crease special -dbg packages for the two
>> >> c
Hi,
I have 2 big annoyances with dylan:
1) Multimachine builds trigger spurious warnings:
WARNING: The recipe bonescript is trying to install files into a shared area
when those files already exist. Those files and their manifest location are:
/build/v2013.06/deploy/eglibc/licenses/bonescrip
On 4/26/13 9:41 AM, Eric Bénard wrote:
Hi Mark,
Le Fri, 26 Apr 2013 08:51:58 -0500,
Mark Hatle a écrit :
On 4/26/13 2:26 AM, Eric Bénard wrote:
this can be fixed by installing the sdk to it's standard path
(/usr/local/oecore-x86_64/ in the present case).
Is that an expected behaviour (as the
Hi Mark,
Le Fri, 26 Apr 2013 08:51:58 -0500,
Mark Hatle a écrit :
> On 4/26/13 2:26 AM, Eric Bénard wrote:
> > this can be fixed by installing the sdk to it's standard path
> > (/usr/local/oecore-x86_64/ in the present case).
> >
> > Is that an expected behaviour (as the sdk is primarly designed
On Fri, 2013-04-26 at 09:39 -0500, Mark Hatle wrote:
> On 4/26/13 9:27 AM, Phil Blundell wrote:
> > On Fri, 2013-04-26 at 09:16 -0500, Mark Hatle wrote:
> >> The alternative of course is to crease special -dbg packages for the two
> >> conflicting items. I.e. foo-dbg, foo-sulogin-dbg, bar-dbg and
On 4/26/13 9:27 AM, Phil Blundell wrote:
On Fri, 2013-04-26 at 09:16 -0500, Mark Hatle wrote:
The alternative of course is to crease special -dbg packages for the two
conflicting items. I.e. foo-dbg, foo-sulogin-dbg, bar-dbg and
bar-sulogin-dbg...
Yeah, indeed, that's what I suggested in my
On Fri, 2013-04-26 at 09:16 -0500, Mark Hatle wrote:
> The alternative of course is to crease special -dbg packages for the two
> conflicting items. I.e. foo-dbg, foo-sulogin-dbg, bar-dbg and
> bar-sulogin-dbg...
Yeah, indeed, that's what I suggested in my original email. At the time
I thought
On 4/26/13 8:57 AM, Phil Blundell wrote:
On Thu, 2013-04-25 at 08:47 -0500, Mark Hatle wrote:
Is this a problem that they should have used the update-alternatives for
sulogin? (Sounds like it might be a security issue though...) This would avoid
the .debug conflict.
I dunno. It seems a bit
On Thu, 2013-04-25 at 08:47 -0500, Mark Hatle wrote:
> Is this a problem that they should have used the update-alternatives for
> sulogin? (Sounds like it might be a security issue though...) This would
> avoid
> the .debug conflict.
I dunno. It seems a bit sad to force use of update-alterna
On 4/26/13 2:26 AM, Eric Bénard wrote:
Hi,
here is a problem I met while trying to build u-boot with a toolchain
generated using dylan.
steps to reproduce :
- bitbake meta-toolchain for an armv5t target
- install the sdk to a custom path ($HOME/oecore-x86_64/ for example
instead of /usr/loc
On Thu, 2013-04-25 at 13:58 -0700, Saul Wold wrote:
> > +S = "${WORKDIR}/alsa-utils-${PV}"
> > +
> Do you mean to point into the alsa-utils actual workdir where alsaconf
> has been created? Then you could also avoid unpacking.
That wasn't really my intention. I guess we could try to do that but
18575b082a4042376fd1575465e69562dea04ddc added bash as a dependency of
alsa-utils-alsaconf so that the script interpreter will be available at
run time. However, this has the undesirable side effect of making bash
be a build dependency for alsa-utils and, for those folks who don't need
alsaconf bu
Hi,
On 26 April 2013 12:41, Robert Yang wrote:
> The error message:
> File "/path/to/glib-2.34.3/gio/gdbus-2.0/codegen/parser.py", line 25, in
>
> import xml.parsers.expat
>
> ImportError: No module named xml.parsers.expat
> make[2]: *** [gdbus-daemon-generated.h] Error 1
>
> This is beca
On 26 April 2013 12:35, Phil Blundell wrote:
> If pango is configured --with-included-modules then the modules
> directory may not exist. This leads to python traceback spew and
> a build failure when trying to run do_split_packages().
>
> Fix this by passing recursive=True to do_split_packages()
The following changes since commit addcfcda84ed6b43b00f569a6060e3b78196ef52:
glib-2.0: disable tests for native builds, and respect ptest for LSB
(2013-04-23 13:00:43 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib robert/glib
http://git.pokylinux.org/c
The error message:
File "/path/to/glib-2.34.3/gio/gdbus-2.0/codegen/parser.py", line 25, in
import xml.parsers.expat
ImportError: No module named xml.parsers.expat
make[2]: *** [gdbus-daemon-generated.h] Error 1
This is because opensuse 12.2 doesn't install the expat.py (one of
python's l
If pango is configured --with-included-modules then the modules
directory may not exist. This leads to python traceback spew and
a build failure when trying to run do_split_packages().
Fix this by passing recursive=True to do_split_packages(), which has
the side-effect of making it ignore nonexis
There doesn't appear to be any compelling reason for these tasks to be nostamp
and having them re-run on every build can be irritating (for example, when the
image is an initramfs which your kernel image depends on).
Signed-off-by: Phil Blundell
---
meta/classes/image.bbclass |2 --
1 file c
From: Jack Mitchell
- change TIST from being explicitly built, to a PACKAGECONFIG
- move wifi, 3g and bluetooth to PACKAGECONFIG
- change RDEPENDS and RPROVIDES to check PACKAGECONFIG rather
than DISTRO_FEATURES
Signed-off-by: Jack Mitchell
---
v4
- exlicityly disable tist
v3
- change RDEP
On 26 April 2013 11:54, Jack Mitchell wrote:
> +PACKAGECONFIG[tist] = "--enable-tist,,"
Please also --disable-tist so it's explicit as to what's happening.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.l
From: Jack Mitchell
- change TIST from being explicitly built, to a PACKAGECONFIG
- move wifi, 3g and bluetooth to PACKAGECONFIG
- change RDEPENDS and RPROVIDES to check PACKAGECONFIG rather
than DISTRO_FEATURES
Signed-off-by: Jack Mitchell
---
v3
- change RDEPENDS and RPROVIDES to check PA
On Fri, Apr 26, 2013 at 11:54:25AM +0100, Jack Mitchell wrote:
> From: Jack Mitchell
>
> - change TIST from being explicitly built, to a PACKAGECONFIG
> - move wifi, 3g and bluetooth to PACKAGECONFIG
>
> Signed-off-by: Jack Mitchell
> ---
>
> Runtime tested on beaglebone armv7a without wifi, 3
From: Jack Mitchell
- change TIST from being explicitly built, to a PACKAGECONFIG
- move wifi, 3g and bluetooth to PACKAGECONFIG
Signed-off-by: Jack Mitchell
---
Runtime tested on beaglebone armv7a without wifi, 3g or bluetooth support.
Runtime tested with and without TIST support.
meta/rec
The older versions of matchbox-panel were naively using -Werror which causes
warnings with gcc 4.6 (which were patched away) and again more with gcc 4.8.
I'd already fixed this upstream so bump the srvrev and drop the patch.
Signed-off-by: Ross Burton
---
.../matchbox-panel-2/gcc-4.6.0-compile.p
On 26 April 2013 11:26, Jack Mitchell wrote:
> Something like:
>
> PACKAGECONFIG ??= " \
> ${@base_contains('DISTRO_FEATURES', 'wifi','wifi', '', d)}\
> "
>
> PACKAGECONFIG[wifi] = "--enable-wifi,--disable-wifi,"
>
> Or were you thinking of another method?
That's right. Would b
On 26/04/13 11:16, Martin Jansa wrote:
On Fri, Apr 26, 2013 at 11:06:11AM +0100, Jack Mitchell wrote:
From: Jack Mitchell
Signed-off-by: Jack Mitchell
---
Runtime tested on beaglebone armv7a, with and without tist PACKAGECONFIG
meta/recipes-connectivity/connman/connman.inc | 13 +++---
Op 26 apr. 2013, om 11:33 heeft Jack Mitchell het
volgende geschreven:
> On 26/04/13 09:07, Chunrong Guo wrote:
>> connman build for powerpc 64bit boards were producing errors like this:
>> | make[1]: *** [plugins/plugins_tist_la-tist.lo] Error 1
>> | make[1]: *** Waiting for unfini
On Fri, Apr 26, 2013 at 11:06:07AM +0100, Burton, Ross wrote:
> On 26 April 2013 10:46, Koen Kooi wrote:
> > Making connman machine specific which means PRSERV will go insane.
>
> Why would this cause prserv to go insane? The only things build-time
> depending on connman should be images so I do
On Fri, Apr 26, 2013 at 11:06:11AM +0100, Jack Mitchell wrote:
> From: Jack Mitchell
>
> Signed-off-by: Jack Mitchell
> ---
>
> Runtime tested on beaglebone armv7a, with and without tist PACKAGECONFIG
>
> meta/recipes-connectivity/connman/connman.inc | 13 +++--
> 1 file changed, 7 in
On 26 April 2013 10:46, Koen Kooi wrote:
> Making connman machine specific which means PRSERV will go insane.
Why would this cause prserv to go insane? The only things build-time
depending on connman should be images so I don't see how it will cause
crazy rebuilds, so I must be missing something
From: Jack Mitchell
Signed-off-by: Jack Mitchell
---
Runtime tested on beaglebone armv7a, with and without tist PACKAGECONFIG
meta/recipes-connectivity/connman/connman.inc | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-connectivity/connman/connm
Op 26 apr. 2013, om 11:36 heeft "Burton, Ross" het
volgende geschreven:
> On 26 April 2013 10:33, Jack Mitchell wrote:
>> I think if anyone needs it, shout up; otherwise we should go with the
>> default and disable it.
>
> Agreed - we can PACKAGECONFIG it and the machines that need it can ena
On 26 April 2013 10:33, Jack Mitchell wrote:
> I think if anyone needs it, shout up; otherwise we should go with the
> default and disable it.
Agreed - we can PACKAGECONFIG it and the machines that need it can enable it.
Ross
___
Openembedded-core mai
On 26/04/13 09:07, Chunrong Guo wrote:
connman build for powerpc 64bit boards were producing errors like this:
| make[1]: *** [plugins/plugins_tist_la-tist.lo] Error 1
| make[1]: *** Waiting for unfinished jobs
| make: *** [all] Error 2
| ERROR: oe_runmake failed
Sig
connman build for powerpc 64bit boards were producing errors like this:
| make[1]: *** [plugins/plugins_tist_la-tist.lo] Error 1
| make[1]: *** Waiting for unfinished jobs
| make: *** [all] Error 2
| ERROR: oe_runmake failed
Signed-off-by: Chunrong Guo
---
meta/recipes-co
This reverts commit 9f5a6f89d9f4a6c7bed3b163e6eaa764d762f523.
The reason for reverting this is:
* qemuwrapper has now a fallback method;
* when using multilib, calling qemu_target_binary from recipes would
always point to the qemu binary corresponding to the machine
architecture. Hence, po
When using multilib, the hooks for lib32/lib64 must be different because
the libdir/base_libdir point to different locations. Postinstalls
calling postint_intercept script must pass the mlprefix in the 3rd
argument.
Signed-off-by: Laurentiu Palcu
---
scripts/postinst-intercepts/postinst_intercep
This is needed in order to have separate multilib intercept hooks.
Signed-off-by: Laurentiu Palcu
---
meta/classes/fontcache.bbclass |2 +-
meta/classes/gtk-icon-cache.bbclass |4 ++--
meta/classes/pixbufcache.bbclass|2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
d
This wrapper script is called mainly from intercept hooks and allarch
packages postinstalls. When multilib is used, the qemuwrapper script
points to the binary that matches the MACHINE architecture.
For example: if MACHINE=qemux86_64 and we activate multilib, then the
postinstalls for lib32 packag
The pango-query-modules binary gets a multilib prefix and the
postinstall has to call the appropriate binary.
Signed-off-by: Laurentiu Palcu
---
meta/recipes-graphics/pango/pango.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/pango/pango.inc
b/m
Changes in v2:
* addressed Mark's comment
There is still work to do on the multilib postinstalls running on host front.
This is a first patchset trying to address some of the issues.
Thanks,
Laurentiu
The following changes since commit addcfcda84ed6b43b00f569a6060e3b78196ef52:
glib-2.0: disa
Hi,
here is a problem I met while trying to build u-boot with a toolchain
generated using dylan.
steps to reproduce :
- bitbake meta-toolchain for an armv5t target
- install the sdk to a custom path ($HOME/oecore-x86_64/ for example
instead of /usr/local/oecore-x86_64/
- get u-boot :
git clon
On Thu, Apr 25, 2013 at 08:44:16PM -0700, Khem Raj wrote:
> Hi
>
> I have pushed a binutils upgrade to contrib branch. I have booted
> systemd-image in all supported QEMUs using angstrom-next distro
>
> Pease help testing it out
>
> The branch is here
>
> http://git.openembedded.org/openembedd
49 matches
Mail list logo
