Signed-off-by: Radu Moisan
---
meta/recipes-connectivity/avahi/avahi.inc |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-connectivity/avahi/avahi.inc
b/meta/recipes-connectivity/avahi/avahi.inc
index d529b37..317a592 100644
--- a/meta/recipes-connectiv
Signed-off-by: Radu Moisan
---
meta/recipes-core/systemd/systemd_197.bb |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd_197.bb
b/meta/recipes-core/systemd/systemd_197.bb
index 500c3ec..ba86127 100644
--- a/meta/recipes-core/system
rebased so that the patch applies on systemd 197
removed RDEPENDS for avahi as Ross suggested
Radu Moisan (2):
systemd: Remove -systemd postfix
avahi: Remove -systemd postfix
meta/recipes-connectivity/avahi/avahi.inc |8 +++-
meta/recipes-core/systemd/systemd_197.bb |9
On 01/29/2013 11:28 AM, Phil Staub wrote:
The io_syscallX wrappers in syscall-mips.h discard error return status
by overwriting the value returned in v0 from the system call with -1.
Modify this behavior by returning the negative of the return value on
error (as identified by a3 != 0). This conv
On Tue, Jan 29, 2013 at 09:26:30PM +0100, Martin Jansa wrote:
> On Tue, Jan 29, 2013 at 03:49:00PM +0100, Martin Jansa wrote:
> > When building bigger world-image I always get this error from
> > populate_lic. There is debug output to show what
> > copytree/Popen/execute_child
> > was calling and
This change ensures that the ls /etc/rpm-postinsts runs in the target
at first boot time, rather than at the creation time of the script on
the host.
This was causing the following error in the rootfs log:
+ install -d
/srv/ssd/sgw/machines/fri2/tmp/work/fri2-poky-linux/core-image-minimal/1.0-r0
On Tue, Jan 29, 2013 at 05:13:45PM -0500, Harvey Chapman wrote:
> On Jan 29, 2013, at 3:39 PM, Martin Jansa wrote:
>
> > Or why do I have each .ipk 7 times in deploy/ipk/arch?
> >
> > tmp-eglibc/sstate-control $ grep ncurses_
> > manifest-armv5te-ncurses.deploy-ipk
> > /OE/oe-core/tmp-eglibc/de
The code in module.bbclass was appending the pkg_postinst and
pkg_prerm to all packages that are part of a given recipe, meaning
that the -lic, -dev, -doc, ... packages all got the scriptlet
This change uses only which macthes with the RDEPENDS and FILES
already used in module.bbclass.
The failur
On Jan 29, 2013, at 3:39 PM, Martin Jansa wrote:
> Or why do I have each .ipk 7 times in deploy/ipk/arch?
>
> tmp-eglibc/sstate-control $ grep ncurses_ manifest-armv5te-ncurses.deploy-ipk
> /OE/oe-core/tmp-eglibc/deploy/ipk/armv5te/ncurses_5.9-r13.1.6_armv5te.ipk
> /OE/oe-core/tmp-eglibc/deploy/
* as reported by Enrico on #oe
11:06:50 < ensc|w> JaMa: might this be caused by
dc78ef91a2bf01efb8028c9afbe69e506e016265
which checks for 'd.getVar('LICENSE_CREATE_PACKAGE', True)' evaluating to
'True' for every
string (including the default 0)
Signed-off-by: Martin Jansa
---
meta/classe
Or why do I have each .ipk 7 times in deploy/ipk/arch?
tmp-eglibc/sstate-control $ grep ncurses_ manifest-armv5te-ncurses.deploy-ipk
/OE/oe-core/tmp-eglibc/deploy/ipk/armv5te/ncurses_5.9-r13.1.6_armv5te.ipk
/OE/oe-core/tmp-eglibc/deploy/ipk/armv5te/ncurses_5.9-r13.1.8_armv5te.ipk
/OE/oe-core/tmp-e
On Tue, Jan 29, 2013 at 03:49:00PM +0100, Martin Jansa wrote:
> When building bigger world-image I always get this error from
> populate_lic. There is debug output to show what copytree/Popen/execute_child
> was calling and it looks OK to me.
and here is strace from that shell, no idea where that
Yes by missing PE bump and similar change removing dbus-systemd in oe-core.
But sofar it's only 30 ERROR messages in bitbake log and 1 package to
upgrade manualyl.
On Tue, Jan 29, 2013 at 5:22 PM, Burton, Ross wrote:
> On 29 January 2013 16:20, Martin Jansa wrote:
> > There were in meta-system
What about network in Build Appliance image? Blacklisting eth interfaces
affects build appliance image too (because it's built as qemux86-64 machine
usually).
Or someone who doesn't use the runqemu script and she doesn't pass a static ip
to qemu because she wants to use a dhcp server (eg: dnsmas
The io_syscallX wrappers in syscall-mips.h discard error return status
by overwriting the value returned in v0 from the system call with -1.
Modify this behavior by returning the negative of the return value on
error (as identified by a3 != 0). This convention is consistent with
the behavior obser
On Tue, Jan 29, 2013 at 8:59 AM, Martin Jansa wrote:
> > We do have an existing mechanism for handling boolean variables in a sane
> > way, as an FYI.
> >
> > LICENSE_CREATE_PACKAGE[type] = "boolean"
> >
> > LICENSE_CREATE_PACKAGE = "1"
> > oe.data.typed_value(d, 'LICENSE_CREATE_PACKAGE') == True
On 01/29/2013 01:49 AM, Andrei Dinu wrote:
> Hello,
Hi Andrei,
> No, i performed only minimal testing, to see if the package is included
> and also that it works when summoned in the console. If you can tell me
> how i can test it further, i would be grateful.
The mtools are used to populate t
just noticed that the standard call to base_set_filespath() adds two
entries of the top-level directory if you're doing a distroless build.
you can see this with bitbake-env:
FILESPATH="/home/rpjday/oe/dist/layers/oe-core/meta/recipes-connectivity/portmap/portmap-6.0/arm
/home/rpjday/oe/dist/la
On 29 January 2013 16:20, Martin Jansa wrote:
> There were in meta-systemd for much longer.
Isn't the upgrade path from meta-systemd already broken?... :/
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.li
There were in meta-systemd for much longer.
On Tue, Jan 29, 2013 at 5:12 PM, Burton, Ross wrote:
> On 29 January 2013 15:56, Martin Jansa wrote:
> > No upgrade path for both.
>
> Do we really need to add an upgrade path for packages that have only
> exists in git master for a week? I can unde
On 29 January 2013 15:56, Martin Jansa wrote:
> No upgrade path for both.
Do we really need to add an upgrade path for packages that have only
exists in git master for a week? I can understand the desire, but
we're not talking about a release-release upgrade path but an upgrade
that will only hi
On 29 January 2013 15:57, Andreas Müller wrote:
> I thought the discussion where to put systemd-files is still open.
> Don't misunderstand me: I am fine with both but I think we should
> decide to go this or that direction not by creating facts.
I'm not convinced that the use case of "install a s
On Tue, Jan 29, 2013 at 07:29:55AM -0700, Chris Larson wrote:
> On Tue, Jan 29, 2013 at 6:04 AM, Martin Jansa wrote:
>
> > * as reported by Enrico on #oe
> > 11:06:50 < ensc|w> JaMa: might this be caused by
> > dc78ef91a2bf01efb8028c9afbe69e506e016265
> > which checks for 'd.getVar('LICENSE_CR
On Tue, Jan 29, 2013 at 4:24 PM, Radu Moisan wrote:
> Signed-off-by: Radu Moisan
> ---
> meta/recipes-connectivity/avahi/avahi.inc |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-connectivity/avahi/avahi.inc
> b/meta/recipes-connectivity/avahi/av
On Tue, Jan 29, 2013 at 05:24:42PM +0200, Radu Moisan wrote:
>
> Radu Moisan (2):
> systemd: Remove -systemd postfix
> avahi: Remove -systemd postfix
>
> meta/recipes-connectivity/avahi/avahi.inc |8
> meta/recipes-core/systemd/systemd_196.bb |9 -
> 2 files changed
On 29 January 2013 15:24, Radu Moisan wrote:
> Signed-off-by: Radu Moisan
Acked-by: Ross Burton
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 29 January 2013 15:24, Radu Moisan wrote:
>-RDEPENDS_avahi-systemd = "avahi-daemon"
> +RDEPENDS_avahi = "avahi-daemon"
The avahi package isn't really used, so this chunk should just be deleted.
Ross
___
Openembedded-core mailing list
Openembedded-c
On Tue, 2013-01-29 at 10:34 -0500, Trevor Woerner wrote:
> I think it would be nice (for us non-inner-circle members) if you
> could link the various IRC handles to the people behind them :-)
The TSC wiki page has a list of members and their IRC handles:
http://wiki.openembedded.org/TSC
p.
__
I think it would be nice (for us non-inner-circle members) if you
could link the various IRC handles to the people behind them :-)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/list
Signed-off-by: Radu Moisan
---
meta/recipes-connectivity/avahi/avahi.inc |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-connectivity/avahi/avahi.inc
b/meta/recipes-connectivity/avahi/avahi.inc
index d529b37..a02c8a5 100644
--- a/meta/recipes-connectiv
Signed-off-by: Radu Moisan
---
meta/recipes-core/systemd/systemd_196.bb |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd_196.bb
b/meta/recipes-core/systemd/systemd_196.bb
index 2854aae..69a4387 100644
--- a/meta/recipes-core/system
Radu Moisan (2):
systemd: Remove -systemd postfix
avahi: Remove -systemd postfix
meta/recipes-connectivity/avahi/avahi.inc |8
meta/recipes-core/systemd/systemd_196.bb |9 -
2 files changed, 8 insertions(+), 9 deletions(-)
--
1.7.9.5
- add a task to setup multilib configuration for target gcc
- this commit adapts Nitin Kamble's work to gcc 4.7
- use a hash for storing arch-dependent multilib options
- patch gcc in order to use the multilib config files from the
build directory
Tests:
root@qemux86-64:~# gcc -m64 t.c -o t
root@q
Signed-off-by: Constantin Musca
---
meta/conf/multilib.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index 97b53ec..8f03661 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -2,7 +2,7 @@
baselib = "$
- add EXTRACONFFUNCS variable in order to make it possible
to inject tasks after autotools_preconfigure
Signed-off-by: Constantin Musca
---
meta/classes/autotools.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotool
This patchset enables the user to build gcc with configurable multilib options.
The following changes since commit cfb082961a6c9ac3d65738031c4071210529cd07:
bitbake: build.py: Dump out performance data of individual tasks (2013-01-28
14:49:05 +)
are available in the git repository at:
g
Ah, good to know, sending v3.
On Tue, Jan 29, 2013 at 3:29 PM, Chris Larson wrote:
>
> On Tue, Jan 29, 2013 at 6:04 AM, Martin Jansa wrote:
>
>> * as reported by Enrico on #oe
>> 11:06:50 < ensc|w> JaMa: might this be caused by
>> dc78ef91a2bf01efb8028c9afbe69e506e016265
>> which checks for
When building bigger world-image I always get this error from
populate_lic. There is debug output to show what copytree/Popen/execute_child
was calling and it looks OK to me.
Could it be caused by pseudo or something like that? do_populate_lic works fine
in other recipes.
Running the same cmdli
On Tue, Jan 29, 2013 at 6:04 AM, Martin Jansa wrote:
> * as reported by Enrico on #oe
> 11:06:50 < ensc|w> JaMa: might this be caused by
> dc78ef91a2bf01efb8028c9afbe69e506e016265
> which checks for 'd.getVar('LICENSE_CREATE_PACKAGE', True)' evaluating
> to 'True' for every
> string (includi
* as reported by Enrico on #oe
11:06:50 < ensc|w> JaMa: might this be caused by
dc78ef91a2bf01efb8028c9afbe69e506e016265
which checks for 'd.getVar('LICENSE_CREATE_PACKAGE', True)' evaluating to
'True' for every
string (including the default 0)
Signed-off-by: Martin Jansa
---
meta/classe
On Tue, Jan 29, 2013 at 10:37 AM, Martin Jansa wrote:
> * as reported by Enrico on #oe
> 11:06:50 < ensc|w> JaMa: might this be caused by
> dc78ef91a2bf01efb8028c9afbe69e506e016265
> which checks for 'd.getVar('LICENSE_CREATE_PACKAGE', True)' evaluating to
> 'True' for every
> string (incl
* as reported by Enrico on #oe
11:06:50 < ensc|w> JaMa: might this be caused by
dc78ef91a2bf01efb8028c9afbe69e506e016265
which checks for 'd.getVar('LICENSE_CREATE_PACKAGE', True)' evaluating to
'True' for every
string (including the default 0)
Signed-off-by: Martin Jansa
---
meta/classe
flex tries to execute:
/data/oe/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/m4
As workaround you can:
mkdir -p /data/oe/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/
ln -s /usr/bin/m4 /data/oe/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/
So this is a bug how OE builds flex.
flex tries
On Mon, Jan 28, 2013 at 12:37:10PM +, g...@git.openembedded.org wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: fb1a7cf8ac1b5ab8047f47ace28775685ba28804
> URL:
> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=fb1a7cf8ac1b5ab8047f47ace28775685ba28804
>
> A
Some SoC need 'dri' support even when not building glx; this patch
splits it in two PACKAGECONFIG options ('glx' and 'dri') but does not
change the default (both enabled).
Signed-off-by: Otavio Salvador
---
meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 13 -
1 file changed, 8
Signed-off-by: Otavio Salvador
---
meta/conf/distro/include/default-providers.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/distro/include/default-providers.inc
b/meta/conf/distro/include/default-providers.inc
index 444176c..d0b84bd 100644
--- a/meta/conf/distro/include/defau
There're some processors which provide binary blobs for DRI and GPU
support which need to be build in BSP; to avoid some dirt and ugly
hacks in BSP we ought to be flexible.
We splitted the glx and dri PACKAGECONFIG options and added a
virtual/dri provider so BSP can override it, if need.
Otavio S
This allow for use DRI alternative implementations as done in some ARM
SoCs.
Signed-off-by: Otavio Salvador
---
meta/recipes-graphics/mesa/mesa-common.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa-common.inc
b/meta/recipes-graphics/m
On Tue, Jan 29, 2013 at 11:21:09AM +0100, Mike Looijmans wrote:
> On 01/29/2013 10:40 AM, Martin Jansa wrote:
> > On Tue, Jan 29, 2013 at 10:29:07AM +0100, Mike Looijmans wrote:
> >> I often have several hardware boards sharing 99% of periferals and
> >> configuration. Usually they all have the exa
On Tue, Jan 29, 2013 at 04:54:30AM -0500, Robert P. J. Day wrote:
> On Tue, 29 Jan 2013, Martin Jansa wrote:
>
> > On Tue, Jan 29, 2013 at 04:08:10AM -0500, Robert P. J. Day wrote:
> > >
> > > not sure if this is expected behaviour, but i'm using the meta-ti
> > > layer to build a core-image-min
Signed-off-by: Ross Burton
---
.../pulseaudio/libcanberra_0.29.bb | 32
1 file changed, 32 deletions(-)
delete mode 100644 meta/recipes-multimedia/pulseaudio/libcanberra_0.29.bb
diff --git a/meta/recipes-multimedia/pulseaudio/libcanberra_0.29.bb
b/meta/r
Signed-off-by: Ross Burton
---
.../metacity/remove-yelp-help-rules-var.patch | 28 --
meta/recipes-gnome/gnome/metacity_2.34.13.bb | 30
2 files changed, 58 deletions(-)
delete mode 100644
meta/recipes-gnome/gnome/metacity/remove-yelp-help-ru
Hi,
Metacity is the GNOME 2 window manager, so unused and untested in oe-core. It's
now been moved to meta-gnome so remove it from oe-core.
libcanberra was in oe-core solely for metacity, so that's also been moved to
meta-gnome so remove it from oe-core.
Ross
The following changes since commit
Paul Eggleton writes:
>> >> 1. set some defaults on distribution base ...
>> >> 2. allow to override these defaults on a per-project base
fwiw, I am using now
_EXT_PROJECT_FEATURES = "\
largefile nfsroot modules ld-is-gold ${PROJECT_FEATURES} \
${DISTRO_FEATURES_INITMAN} ${DISTRO_FEATURES_L
On 29 January 2013 10:21, Mike Looijmans wrote:
> (Needless rebuild: Built package X for machine A. Switch to B, and it will
> build X again, which isn't needed because they're for the same architecture
> and the package isn't dependent on the machine. Switch back to A, and it
> will AGAIN build p
On 01/29/2013 10:40 AM, Martin Jansa wrote:
On Tue, Jan 29, 2013 at 10:29:07AM +0100, Mike Looijmans wrote:
I often have several hardware boards sharing 99% of periferals and
configuration. Usually they all have the exact same CPU, and the
difference is in the minor details like the screen resol
Removed the following tools:
- all related to hdsp (required gtk+ and fltk-config)
- ld10k1, qlo10k1 (required QT)
- hdajackretask
Fixed the automake issue for cross-compilation
Signed-off-by: Cristian Iorga
---
.../{alsa-tools-1.0.25 => alsa-tools}/autotools.patch | 13 +++--
...
On Tue, 29 Jan 2013, Martin Jansa wrote:
> On Tue, Jan 29, 2013 at 04:08:10AM -0500, Robert P. J. Day wrote:
> >
> > not sure if this is expected behaviour, but i'm using the meta-ti
> > layer to build a core-image-minimal for a am180x-evm. i'm using
> > "own-mirrors" to use my own premirrors d
Hello,
No, i performed only minimal testing, to see if the package is included
and also that it works when summoned in the console. If you can tell me
how i can test it further, i would be grateful.
Thanks,
Andrei Dinu
On 01/28/2013 08:45 PM, Darren Hart wrote:
Have you performed testing w
On Tue, Jan 29, 2013 at 04:08:10AM -0500, Robert P. J. Day wrote:
>
> not sure if this is expected behaviour, but i'm using the meta-ti
> layer to build a core-image-minimal for a am180x-evm. i'm using
> "own-mirrors" to use my own premirrors directory and i've collected
> all of the necessary
back in november, i whined thusly:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/031997.html
is this the *intended* behaviour? since it seems that if i do a
"bitbake -c fetchall", i should expect that i now have *all* software
related to my target, and that's clearly no
On Tue, Jan 29, 2013 at 10:29:07AM +0100, Mike Looijmans wrote:
> I often have several hardware boards sharing 99% of periferals and
> configuration. Usually they all have the exact same CPU, and the
> difference is in the minor details like the screen resolution.
>
> In "classic" OE I was used
I often have several hardware boards sharing 99% of periferals and
configuration. Usually they all have the exact same CPU, and the
difference is in the minor details like the screen resolution.
In "classic" OE I was used to sharing the work, by just changing the
MACHINE variable I could creat
not sure if this is expected behaviour, but i'm using the meta-ti
layer to build a core-image-minimal for a am180x-evm. i'm using
"own-mirrors" to use my own premirrors directory and i've collected
all of the necessary tarballs and actually completed the build, after
which i make sure i have sa
Really really sorry that this patch introduces a bug :(
(It built and booted correctly, so I thought everything's OK. I didn't
check the do_rootfs log.)
A follow-up patch has been sent.
Sorry for the inconvenience.
Chen Qi
On 01/22/2013 04:44 PM, qi.c...@windriver.com wrote:
From: Chen Qi
I
From: Chen Qi
This is a follow-up patch which fixes a bug introduced by the
commit bd10a6d257ab5ce2fc961788c278af7c43637404.
The `` command substitution characters should be excaped by \ to make
things work correctly.
[YOCTO #3767]
Signed-off-by: Chen Qi
---
meta/classes/rootfs_rpm.bbclass |
From: Chen Qi
The following changes since commit cfb082961a6c9ac3d65738031c4071210529cd07:
bitbake: build.py: Dump out performance data of individual tasks (2013-01-28
14:49:05 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib ChenQi/rootfs_rpm-fix-error
To fix some multilib issues, change the way the RPM backend decides
if two packages can coexist: if they have a different architecture,
automatically assume that they can coexist (which is fundamental for
multilib).
[YOCTO #3681]
Signed-off-by: Bogdan Marinescu
---
.../python-smartpm/smart-mult
68 matches
Mail list logo
