I've just been trying to build a uclibc-based system from the current
head of oe-core but this doesn't seem to be something that works
entirely smoothly at the moment. Does anybody have a patchset to fix
the uclibc recipes, or is anybody working on such a thing?
Issues I've encountered thus far a
This change, from commit d2d5456cd3b3bd3e52a5dedccca4d46e3a7986d1:
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 225530a..71ed5b6 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -349,7 +349,7 @@ def package_qa_check_license(workdir, d):
On Mon, 2011-05-16 at 10:01 -0700, Khem Raj wrote:
> On Mon, May 16, 2011 at 9:35 AM, Phil Blundell wrote:
> > I've just been trying to build a uclibc-based system from the current
> > head of oe-core but this doesn't seem to be something that works
> > entirel
On Tue, 2011-05-17 at 01:13 +0100, Richard Purdie wrote:
> The more I looked at that patch, the more holes I could see in what we
> were doing (and what Angstrom currently does). I started playing around
> with the patch below which tried to improve on that idea.
>
> I then concluded that we might
On Tue, 2011-05-17 at 10:34 +0100, Richard Purdie wrote:
> How about this idea:
>
> TMPDIR_append = "-uclibc"
Hm, I'm not totally sure what this really buys us.
If the whole issue boils down to saying that you just can't share a
TMPDIR between builds with competing C libraries (which sounds
re
This is a backport of the corresponding package.bbclass functionality
(which is needed by micro) from the openembedded tree.
p.
>From 01e01d38d57d7c766cc1e9a547c73abd4065e1c1 Mon Sep 17 00:00:00 2001
From: Phil Blundell
Date: Fri, 13 May 2011 14:07:26 +0100
Subject: [PATCH] package.bbcl
On Tue, 2011-05-17 at 00:36 +0100, Richard Purdie wrote:
> As far as I can tell, we can throw away xtscal, libxcalibrate, and
> calibrateproto after that change since they need that X extension. Its a
> good example of why changes need to get upstream as if the build fix was
> there, they'd have ha
For some reason guilt-native seems to have gone out of its way to refer
explicitly to /usr, which breaks on micro.
Let's use ${prefix} instead.
---
meta/recipes-devtools/guilt/guilt-native_0.33.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/gu
---
meta/classes/image-prelink.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/image-prelink.bbclass
b/meta/classes/image-prelink.bbclass
index ee0951c..cefd983 100644
--- a/meta/classes/image-prelink.bbclass
+++ b/meta/classes/image-prelink.bbclass
On Tue, 2011-05-17 at 13:02 +0100, Richard Purdie wrote:
> On Tue, 2011-05-17 at 12:51 +0100, Phil Blundell wrote:
> > ---
> > meta/classes/image-prelink.bbclass |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta/classes/
handhelds.org cvs is down and doesn't seem to be coming back.
update-rc.d now has a new upstream home, point SRC_URI to that.
Signed-off-by: Phil Blundell
---
meta/recipes-core/update-rc.d/update-rc.d_0.7.bb |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a
This allows distros that don't want ldconfig to turn it off.
Signed-off-by: Phil Blundell
---
meta/classes/image.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index b2325b3..346dd5e 100644
--- a
This fixes a build failure when ${prefix}="".
Signed-off-by: Phil Blundell
---
meta/recipes-connectivity/openssl/openssl.inc |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-connectivity/openssl/openssl.inc
b/meta/recipes-connectivi
Signed-off-by: Phil Blundell
---
meta/recipes-core/eglibc/eglibc-package.inc|2 +-
3 files changed, 24 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-core/eglibc/eglibc/lds-warnings.patch
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core
This makes it work more or less the same way as the current tip of oe
master, except that I didn't copy over the behaviour for O_P_M="add"
because it seemed slightly bogus to me.
Signed-off-by: Phil Blundell
---
meta/classes/rootfs_ipk.bbclass | 12 ++--
1 fi
Signed-off-by: Phil Blundell
---
meta/classes/image-prelink.bbclass | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/meta/classes/image-prelink.bbclass
b/meta/classes/image-prelink.bbclass
index ee0951c..350c29d 100644
--- a/meta/classes/image
On Tue, 2011-05-17 at 15:31 +0100, Richard Purdie wrote:
> Its not ideal but its nicer than the MACHINE workarounds IMO. We could
> default to turning it off and let distros choose to turn it on if they
> desire it too...
That sounds like a good plan to me. Or if it's literally just
"TMPDIR_appen
On Tue, 2011-05-17 at 15:35 +0100, Richard Purdie wrote:
> The patch description and what it does don't quite match (the rm is
> removed and options are added to prelink).
The added "-c ..." option is necessary in case ${sysconfdir_native} and
${sysconfdir} are not the same thing.
The "-N" tells
On Tue, 2011-05-17 at 15:24 +0100, Richard Purdie wrote:
> What's wrong with:
>
> ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; "
>
> as used in the minimal image? The nice thing about this is it works over
> several package backends too...
Well, conceptually it seems a bit nicer
Pass -N option to prelink so that no cache file is generated (obviates need for
deleting it afterwards).
Use symbolic names, ${sysconfdir} et al., rather than hardcoded paths.
Pass explicit -c option to prelink in case ${sysconfdir} and
${sysconfdir_native} are different.
Signed-off-by: Phil
On Tue, 2011-05-17 at 17:22 +0100, Richard Purdie wrote:
> On Tue, 2011-05-17 at 15:50 +0100, Phil Blundell wrote:
> > I guess I could teach remove_packaging_data_files() to not create the
> > empty directory if O_P_M=="none". Would you be happier with that?
>
> Mo
On Tue, 2011-05-17 at 13:57 -0700, Khem Raj wrote:
> With default-setup being pulled in via bitbake.conf and task-core-boot
> being pulled into all images in distros, we need
> to have some variables that distro's can override if need be
> This is a backport from angstrom/OE. It will help distros w
On Wed, 2011-05-18 at 09:40 -0700, Khem Raj wrote:
> Problem I have is, I dont want udev in RDEPENDS which is added by
> task-core-boot
> and task-core-boot is added to DISTRO_EXTRA_RDEPENDS through
> default-distrovars.inc -> defaultsetup.conf -> bitbake.conf
>
> and my distro adds DISTRO_EXTRA_R
On Wed, 2011-05-18 at 11:07 -0700, Khem Raj wrote:
> there are certain common parts that can be abstracted
> and can be maintained in oe-core so everyone benefits
> from it and certain image specific parts can be done in
> distros. So keeping common parts in core would still
> be better IMO
Which
This is a backport from oe master.
Signed-off-by: Phil Blundell
---
meta/classes/update-rc.d.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 7e4dda7..c4ecc04 100644
--- a/meta/classes
Signed-off-by: Phil Blundell
---
meta/classes/rootfs_ipk.bbclass | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/meta/classes/rootfs_ipk.bbclass
b/meta/classes/rootfs_ipk.bbclass
index 5727d15..4c8088b 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b
On Thu, 2011-05-19 at 11:15 +0100, Richard Purdie wrote:
> We have postinstalls that require to run on the target device. If
> they're present, we need opkg there to run them, or at least some kind
> of script to handle that and I think both cases have a requirement on
> that directory (the rpm bac
On Thu, 2011-05-19 at 12:21 +0100, Richard Purdie wrote:
> On Thu, 2011-05-19 at 11:31 +0100, Phil Blundell wrote:
> Agreed. I'd like to raise one other issue which is the number of
> variables we need to control these things which are effectively binary
> flags. I'm leaning
On Thu, 2011-05-19 at 13:16 +0100, Richard Purdie wrote:
> So if we:
>
> a) Only add ROOTFS_PKGMANAGE_BOOTSTRAP if postinstalls were present
> b) Add the read-only-rootfs option we discussed which errors if
>postinstalls are present
>
> we end up a lot closer to where you want to be.
Yes, s
On Thu, 2011-05-19 at 14:09 -0700, Khem Raj wrote:
> Some packages have uppercase letters in their names e.g.
> efikamx kernel. We allow uppercase character with
> uppercase-letters.patch
This is not a good idea. Uppercase characters have never been permitted
in .deb/.ipk.
Isn't legitimize_pack
On Thu, 2011-05-19 at 17:02 -0700, Khem Raj wrote:
> -DEPENDS = "avahi gtk+"
> +DEPENDS = "avahi"
> +DEPENDS_append-libc-glibc = " gtk+ "
If uclibc is alone in not having this function then it would be better
as:
gtkdepends = "gtk+"
gtkdepends_libc-uclibc = ""
DEPENDS = "avahi ${gtkdepends}"
or
On Fri, 2011-05-20 at 07:45 +0100, Phil Blundell wrote:
> On Thu, 2011-05-19 at 14:09 -0700, Khem Raj wrote:
> > Some packages have uppercase letters in their names e.g.
> > efikamx kernel. We allow uppercase character with
> > uppercase-letters.patch
>
> This is
On Fri, 2011-05-20 at 16:19 -0700, Khem Raj wrote:
> -DEPENDS = "avahi gtk+"
> +DEPENDS = "avahi ${GTKDEP}"
> +GTKDEP-libc-uclibc = ""
> +GTKDEP = "gtk+"
Does that really work? Surely it should be "GTKDEP_libc-uclibc".
> -EXTRA_OECONF = " --with-gtk "
> -
> +EXTRA_OECONF_libc-glibc = " --with-gt
On Sat, 2011-05-21 at 00:19 -0700, Khem Raj wrote:
> >> -EXTRA_OECONF = " --with-gtk "
> >> -
> >> +EXTRA_OECONF_libc-glibc = " --with-gtk "
> >> +EXTRA_OECONF_libc-uclibc = " --without-gtk --without-gnome "
> >
> > Can you make this use the same logic as above?
> >
>
> Is there a problem with t
On Fri, 2011-05-20 at 16:19 -0700, Khem Raj wrote:
> - install -d ${IMAGE_ROOTFS}/${sysconfdir}/rcS.d
> + install -d $D/${sysconfdir}/rcS.d
Just as a note in passing, this sort of thing is best written as:
install -d "${D}${sysconfdir}/rcS.d"
i.e. you don't need a slash after ${D
On Sun, 2011-05-22 at 11:48 -0700, Saul Wold wrote:
> --- a/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
> +++ b/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
> @@ -5,10 +5,12 @@ programs fulfilling the same or similar functions and how
> they can
On Sun, 2011-05-22 at 11:48 -0700, Saul Wold wrote:
> -LICENSE = "LGPL"
> -SECTION = "x11/libs"
> -PR = "r1"
> DESCRIPTION = "GNOME Accessibility Implementation Library"
> +SECTION = "x11/libs"
> +
> DEPENDS = "gtk+"
> PROVIDES = "virtual/gail"
>
> +LICENSE = "LGPLv2"
> +LIC_FILES_CHKSUM = "fi
On Sat, 2011-05-21 at 11:37 -0700, Saul Wold wrote:
> Signed-off-by: Saul Wold
> ---
> .../puzzles/{puzzles_r9163.bb => puzzles_r9173.bb} |0
> 1 files changed, 0 insertions(+), 0 deletions(-)
> rename meta/recipes-sato/puzzles/{puzzles_r9163.bb => puzzles_r9173.bb}
> (100%)
No doubt the p
On Mon, 2011-05-23 at 12:13 +, Otavio Salvador wrote:
> CONFIG_LOSETUP=y
> # CONFIG_LSPCI is not set
> # CONFIG_LSUSB is not set
> -# CONFIG_MDEV is not set
> +CONFIG_MDEV=y
> # CONFIG_FEATURE_MDEV_CONF is not set
> # CONFIG_FEATURE_MDEV_RENAME is not set
> # CONFIG_FEATURE_MDEV_RENAME_RE
On Sun, 2011-05-22 at 16:04 -0700, Khem Raj wrote:
> Bring in the uclibc recipes from meta-oe they have been well
> tested by now.
This doesn't build for me on i586:
| ccache i586-oe-linux-uclibc-gcc -march=i586
--sysroot=/home/pb/oe/build-meta-uclibc/tmp-uclibc-uclibc/sysroots/qemux86-tcbootstr
My eglibc builds are failing in perl with:
| ccache i586-oe-linux-gcc -march=i586
--sysroot=/home/pb/oe/build-meta/tmp-eglibc/sysroots/qemux86 -Wl,-O1
-Wl,--as-needed -o miniperl \
| gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o
mro.o hv.o av.o run.o pp_hot.o sv.o
b/oe/build-meta/tmp-eglibc/work/i586-oe-linux/busybox-1.18.4-r1.2/image/busybox/image'
| ERROR: Function 'do_install' failed (see
/home/pb/oe/build-meta/tmp-eglibc/work/i586-oe-linux/busybox-1.18.4-r1.2/temp/log.do_install.3808
for further information)
Signed-off-by: Phil Bl
On Thu, 2011-05-19 at 16:08 +0100, Richard Purdie wrote:
> On Thu, 2011-05-19 at 16:04 +0100, Phil Blundell wrote:
> > On Thu, 2011-05-19 at 13:16 +0100, Richard Purdie wrote:
> > > So if we:
> > >
> > > a) Only add ROOTFS_PKGMANAGE_BOOTSTRAP if postinstall
On Tue, 2011-05-24 at 15:12 +0100, Richard Purdie wrote:
> I think allowing selection of this at image generation time is the more
> powerful way to handle this. It could be we go through a step of
> forcibly removing packages we don't want from the rootfs such as
> update-rc.d, or we can tell the
Signed-off-by: Phil Blundell
---
meta/classes/rootfs_ipk.bbclass | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index 4c8088b..99584eb 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta
On Tue, 2011-05-24 at 07:52 -0700, Khem Raj wrote:
> I have done couple of builds of eglibc with -j 2
Do you really mean that? I wonder if you actually tested with -j2
instead.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedde
On Tue, 2011-05-24 at 15:16 +0100, Richard Purdie wrote:
> I've been thinking through the different use cases and briefly talked
> with Koen offlist about this. I think the revised order makes sense with
> what users would expect and am happy to remove local and fail-fast as
> overrides since we do
On Tue, 2011-05-24 at 16:07 +0100, Richard Purdie wrote:
> It was added to poky with the intent of doing what "_local" would have
> done before it was broken.
>
> I think its a little safer than using "local" as the override keyword,
> I'm open to opinion on whether it should be kept but it probab
On Tue, 2011-05-24 at 11:35 -0700, Khem Raj wrote:
> so essentially you are interested in maintaining this board in
> meta-yocto and not use meta-ti as long as you have a process to sync
> your changes in a sane manner between two layers I think it should be
> ok. However we have to make clear if s
On Wed, 2011-05-25 at 09:28 -0500, Tom Zanussi wrote:
> I just finished building all of the above successfully using the latest
> (as of yesterday) poky/master and meta-intel/master.
>
> Not sure why you're seeing parsing errors, none here...
The way meta-intel is using FILESEXTRAPATHS does look
On Tue, 2011-05-24 at 11:33 +0100, Phil Blundell wrote:
> On Sun, 2011-05-22 at 16:04 -0700, Khem Raj wrote:
> > Bring in the uclibc recipes from meta-oe they have been well
> > tested by now.
>
> This doesn't build for me on i586:
>
> | ccache i586-oe-linux-ucl
By way of displacement activity to avoid actually fixing my perl
compilation problem, it occurred to me to investigate why perl was
getting dragged into a micro-base-image build in the first place. The
culprit turns out to be imake, which does:
RDEPENDS_${PN} = "perl xproto"
and is then BBCLASSE
On Wed, 2011-05-25 at 11:56 -0700, Darren Hart wrote:
> If it is indeed space separated then I should be able to remedy both
> issues by simply using the append operator and not self-referencing.
> Correct?
I think that's true, yes. But, space separation is fairly undesirable
for anything involvi
b/oe/build-meta/tmp-eglibc/work/i586-oe-linux/busybox-1.18.4-r1.2/image/busybox/image'
| ERROR: Function 'do_install' failed (see
/home/pb/oe/build-meta/tmp-eglibc/work/i586-oe-linux/busybox-1.18.4-r1.2/temp/log.do_install.3808
for further information)
Signed-off-by: Phil Blundell
On Wed, 2011-05-25 at 16:08 -0700, Khem Raj wrote:
> while we are talking about fixing native.bbclass on a different
> tangent. I think overrides is another thing we need to fix
> specially libc overrides. When a recipe inherits
> native,cross, or nativesdk then we have to change
> the libc overrid
On Wed, 2011-05-25 at 18:01 +0100, Phil Blundell wrote:
> Now, leaving aside the question of whether it is reasonable for prelink
> to be depending on transfig,
This also seemed worthy of a bit of further investigation. Here's what
I found out:
The dependency on transfig-native w
On Wed, 2011-05-25 at 22:02 -0700, Darren Hart wrote:
> COMPATIBLE_MACHINES is not easily extended due to
> its regex syntax: "(machine_a|machine_b)", making it difficult to extend the
> u-boot recipe in bbappend files without resorting to machine specific
> overrides.
Not that I have an objectio
that either opkg or the awk script can
configure the packages at boot time. In theory it would be possible to
strip out the data for packages that have already been configured, but
right now we just hold on to the whole status file in that situation.
Signed-off-by: Phil Blundell
---
meta/cl
On Thu, 2011-05-26 at 19:55 +0800, Lianhao Lu wrote:
> -EXTENDPV = "${EXTENDPEVER}${PV}-${PR}"
> +EXTENDPV = "${EXTENDPEVER}${PV}-${PKGR}"
That looks a bit weird. Is it really correct to be mixing PV and PKGR
like that?
FWIW, oe master has:
EXTENDPE = "${@int('${PE}') and '${PE}_' or ''}"
EXTEN
On Thu, 2011-05-26 at 20:43 +0800, Lu, Lianhao wrote:
> The problem is that in OE-core the default -deb/-dbg packages are all
> using EXTENDPV, as well as some other recipes. Do you mean we should
> make them all using EXTENDPKGV instead of EXTENDPV?
As far as I can tell, yes, that would be the ri
On Thu, 2011-05-26 at 21:02 +0800, Lu, Lianhao wrote:
> Maybe all the recipes are using the PKGV default value (?= ${PV}, so
> this just happens to make EXTENDPKGV equal to EXTENDPV.
Yes, could be. The most common situation where PKGV != PV is when
something like gitpkgv.bbclass is in use, which
On Thu, 2011-05-26 at 15:37 +0100, Richard Purdie wrote:
> u-boot in OE-Core would need something like COMPATIBLE_MACHINE = ""
> which makes this harder.
Yes, true. I don't think that's a major problem, though, you just need
a regex that won't match anything. Something like:
COMPATIBLE_MACHINE
On Fri, 2011-05-27 at 09:54 +0100, Richard Purdie wrote:
> Good question. I guess you're just changing the gcc version but using
> the rest of that file?
>
> This is a tricky problem as we do want to include that for anyone using
> gcc 4.6 as otherwise things break but as you say, can't impact som
On Thu, 2011-05-26 at 20:16 -0700, Darren Hart wrote:
> So by changing from split() to split(":") we change the behavior of
> split when operating on empty strings, requiring us to special case the
> output. Rather obnoxious wouldn't you say?
Yes, that is an annoying misfeature. The other related
On Fri, 2011-05-27 at 15:40 +0200, Koen Kooi wrote:
> + mkdir -p $UUIDDIR || true
Why "|| true"? If this creation fails then the following chown will
surely fail as well, except with a different and less illuminating error
message.
> + chown "$MESSAGEUSER"."$MESSAGEUSER" "$UUIDDIR"
The
On Thu, 2011-05-26 at 10:46 -0700, Darren Hart wrote:
> Right, it just starts to look rather ugly in the recipe, especially for
> BSPs supporting more than just a couple of machines. I also think that
> having to use machine overrides is an indicator that the mechanism is
> not working for the purp
On Fri, 2011-05-27 at 00:33 +0100, Richard Purdie wrote:
> I talked about this on IRC but simply put, no way.
>
> The problem is:
>
> a) Arm specific
> b) determined now to be armv7 specific
> c) gcc version specific
>
> and the fix should reflect this.
>From a fairly superficial look at the cr
On Fri, 2011-05-27 at 08:06 -0700, Darren Hart wrote:
> In fact... why are the parens used at all?
No good reason. I would guess that we started off with something like
COMPATIBLE_MACHINE = "pdp11/(23|34)"
in a recipe, and that got somehow generalised to wrapping all the
alternatives in parens
On Fri, 2011-05-27 at 15:55 +0200, Koen Kooi wrote:
> I matched the postinst for these additionsm, but I can cleanup the complete
> postinst if you wish.
I see you did that already in your v2 patch. Thanks.
p.
___
Openembedded-core mailing list
Ope
On Fri, 2011-05-27 at 14:09 -0700, Saul Wold wrote:
> From: Yu Ke
>
> [YOCTO #737]
>
> The AC_CHECK_FUNC([dlopen], [], AC_CHECK_LIB([dl], [dlopen],
> DLOPEN_LIBS="-ldl"))
> macro seems not work well in ppc arch, so this patch force the
> DLOPEN_LIBS="-ldl"
>
That's a bit of a weird report.
On Sat, 2011-05-28 at 13:21 +0200, Koen Kooi wrote:
> The alternative is to just move 'killall5' into the pidof subpackage and to
> RDPEPENDS_${PN} += "${PN}-pidof"
I think I like that better. Duplicating the binary doesn't sound very
desirable.
For what it's worth, also note that:
- busybox p
Per http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/003179.html
Signed-off-by: Phil Blundell
---
meta/recipes-devtools/prelink/prelink_git.bb |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/prelink/prelink_git.bb
b/meta/recipes
Ping?
p.
On Thu, 2011-05-26 at 11:08 +0100, Phil Blundell wrote:
> This is basically a backport of the current state of the art from the
> openembedded master repo. In particular this fixes an installation
> error on micro:
>
> | + cp -dPr
> /home/pb/oe/build-meta/tmp-e
Also remove update-rc.d and base-passwd since their services are no longer
required.
Signed-off-by: Phil Blundell
---
meta/classes/rootfs_ipk.bbclass | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes
e and
gpg-error) which were unusable previously.
Signed-off-by: Phil Blundell
---
meta/classes/binconfig.bbclass |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/binconfig.bbclass b/meta/classes/binconfig.bbclass
index 8e22d2d..3deb541 100644
---
On Tue, 2011-05-31 at 12:53 -0700, Scott Garman wrote:
> This adds a -native recipe for the shadow utilities.
>
> The custom --root option allows the the following utilities to be
> run within a chroot when invoked under pseudo:
Rather than patching the code for all these utilities, can't you jus
, but
right now we just hold on to the whole status file in that situation.
Signed-off-by: Phil Blundell
---
meta/classes/rootfs_ipk.bbclass | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index ed
On Tue, 2011-05-31 at 23:21 -0700, Khem Raj wrote:
> On 05/31/2011 11:10 PM, Martin Jansa wrote:
> > On Tue, May 31, 2011 at 10:57:00PM -0700, Khem Raj wrote:
> >> On 05/31/2011 10:26 PM, Saul Wold wrote:
> >>> | ../../include/QtCore/../../src/corelib/arch/qatomic_arm.h:361:35:
> >>> error: output
On Wed, 2011-06-01 at 21:18 +0800, Dexuan Cui wrote:
> +PACKAGE_OWN_DIR = ""
> +bindir .= "${PACKAGE_OWN_DIR}"
> +libdir .= "${PACKAGE_OWN_DIR}"
> +libexecdir .= "${PACKAGE_OWN_DIR}"
I think the general idea of this patch is a good one but I'm not
terribly fond of the name of that variable. If th
On Wed, 2011-06-01 at 13:34 +0100, Martyn Welch wrote:
> On 01/06/11 10:47, Phil Blundell wrote:
> > On Tue, 2011-05-31 at 12:53 -0700, Scott Garman wrote:
> >> This adds a -native recipe for the shadow utilities.
> >>
> >> The custom --root option allows the th
On Tue, 2011-05-31 at 15:26 -0700, Scott Garman wrote:
> I'd like to collect some feedback on error messages while building that
> you find confusing/annoying/unhelpful. I'm going to be working on trying
> to improve the situation and would like to hear from you about what
> could be more helpfu
Is there any compelling reason why dbus-native needs to be built
--with-x? This seems to be causing quite a large stack of native X11
packages to get built with, as far as I can tell, no useful result.
dbus-native itself is pulled in by way of insane.bbclass ->
desktop-file-utils-native -> glib-2
On Wed, 2011-06-01 at 17:01 +0100, Phil Blundell wrote:
> Is there any compelling reason why dbus-native needs to be built
> --with-x? This seems to be causing quite a large stack of native X11
> packages to get built with, as far as I can tell, no useful result.
Oh, on the subject
On Wed, 2011-06-01 at 18:11 +0200, Koen Kooi wrote:
> Furthermore, rpm-native seems to get built even if you don't select rpm as
> package format!
Yeah, it's called in by package.bbclass:
# rpm is used for the per-file dependency identification
PACKAGE_DEPENDS += "rpm-native"
As far as I can te
On Wed, 2011-06-01 at 18:10 +0200, Koen Kooi wrote:
> Op 1 jun 2011, om 18:01 heeft Phil Blundell het volgende geschreven:
>
> > Is there any compelling reason why dbus-native needs to be built
> > --with-x? This seems to be causing quite a large stack of native X11
> &g
On Wed, 2011-06-01 at 11:48 -0500, Mark Hatle wrote:
> So in the above, perl and python are really the only items that could be
> disabled.
Just to be clear, in the list you mentioned, were you talking about the
usage of rpm-native for rpmdeps, or the usage by package_rpm.bbclass
itself?
If we c
On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
> On 6/1/11 11:54 AM, Phil Blundell wrote:
> > On Wed, 2011-06-01 at 11:48 -0500, Mark Hatle wrote:
> >> So in the above, perl and python are really the only items that could be
> >> disabled.
> >
>
Further to my mini-crusade against perl-native, I discovered that it was
also being included during the initial pseudo build because
gnu-config-native depends on it.
This also seems a bit mysterious: gnu-config has:
DEPENDS_virtclass-native = "perl-native"
... which suggests that the dependency
On Wed, 2011-06-01 at 18:29 +0100, Richard Purdie wrote:
> I've also a slight preference for "staticdev" just to make these clearly
> different from -dev packages.
Agreed. I think even "-static" might be better still.
p.
___
Openembedded-core mailin
On Wed, 2011-06-01 at 13:55 -0500, Mark Hatle wrote:
> The issue is that it uses the librpm, librpmdb, librpmio, and librpmmisc
> libraries. These libraries provide and use all of the rest of the components.
Right, but would rpmdeps still be able to do what it needs to if rpm was
built --without-
On Wed, 2011-06-01 at 12:39 -0700, Tom Rini wrote:
> Maybe race isn't quite the right word. But recipe A depends on
> lib$something-perl-native, and brings in perl-native. It also checks
> for perl in its auto-foo and finds our perl. It now also uses our perl
> when it wants a host perl and all
On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
> It "should" be as simple and adding --without-perl and --without-python to the
> configuration line... but I haven't tried it.
Turns out that rpm-native already does this, but (like the dbus case)
there is no matching logic to get the DEPENDS
On Wed, 2011-06-01 at 20:09 +, Otavio Salvador wrote:
> +export LDFLAGS += "-ldl"
The configure script ought to be figuring this out for itself. Do you
know why that isn't working?
p.
___
Openembedded-core mailing list
Openembedded-core@lists.op
On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote:
> What falls down in this case is that once
> perl-native is built (and in our PATH), if it's a different version than
> system-wide perl, stuff starts failing on version mis-match.
I think that's the bit that I'm not properly understanding. Whi
On Wed, 2011-06-01 at 20:09 +, Otavio Salvador wrote:
> -# CONFIG_MDEV is not set
> +CONFIG_MDEV=y
Per previous discussion, I am still uneasy about this change. I think
we really need some sort of coherent policy for what exactly the default
busybox configuration in oe-core is meant to be doi
On Wed, 2011-06-01 at 20:39 +, Otavio Salvador wrote:
> On Wed, Jun 1, 2011 at 20:33, Phil Blundell wrote:
> > On Wed, 2011-06-01 at 20:09 +, Otavio Salvador wrote:
> >> +export LDFLAGS += "-ldl"
> >
> > The configure script ought to be figuring t
On Wed, 2011-06-01 at 15:00 -0700, Tom Rini wrote:
> Since this keeps coming up, maybe it needs a comment. sqlite3 needs
> tcl-native (tclsh) to generate a header file. No tclsh, no sqlite3.
Oh yeah, right.
Maybe we should just patch sqlite to generate the header using something
else. There's
On Wed, 2011-06-01 at 15:22 -0700, Tom Rini wrote:
> On 06/01/2011 03:07 PM, Henning Heinold wrote:
> > On Wed, Jun 01, 2011 at 03:00:37PM -0700, Tom Rini wrote:
> >> On 06/01/2011 01:22 PM, Phil Blundell wrote:
> >>> On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle w
On Wed, 2011-06-01 at 16:17 -0500, Mark Hatle wrote:
> I'm not sure if the libraries that RPM uses would even be able to link w/o
> openssl. (I never tried it.) But that will affect people who are using RPM
> packages as signing and validation routines come from openssl.
Sure, but if rpmdeps doe
The native variant already configures --without-x so the X11 libs are
redundant. Adjust the DEPENDS to match.
Signed-off-by: Phil Blundell
---
meta/recipes-core/dbus/dbus.inc |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta
1 - 100 of 1457 matches
Mail list logo
