Add STAMPS_DIR for constructing STAMP, the defination of STAMP is:
STAMP = "${TMPDIR}/stamps/${MULTIMACH_TARGET_SYS}/${PF}
We can only change the TMPDIR if we want to change the STAMP's location,
but the cache would be regenerated if TMPDIR changed, so add
STAMPS_DIR for constructing it, and add
* Contents:
- Summary
- Usage
- Implementation summary
- Output
- TODO
* Summary:
This is used for printing out what is about to happen between the
current and last builds, for example:
$ bitbake core-image-sato
# Edit some recipes
$ bitbake-whatchanged core-image-sato
The
Changes of V3:
* Move it from bitbake/bin/ to oe-core/scripts
* Change BB_STAMPS_DIR to STAMPS_DIR
* Use "which bitbake-diffsigs" to locate where is the bitbake/lib/bb since it
needs bb.siggen.compare_sigfiles (must) and bb.process.run (optional).
Changes of V2:
* Fix a typo fn -> 'fn'
* Use
On 08/15/2012 11:32 PM, Robert Yang wrote:
diff --git a/meta/classes/external_package.bbclass
b/meta/classes/external_package.bbclass
new file mode 100644
index 000..c6d87bb
--- /dev/null
+++ b/meta/classes/external_package.bbclass
@@ -0,0 +1,41 @@
+#
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-wi
On Wed, Aug 15, 2012 at 08:15:46PM -0700, Khem Raj wrote:
> This fixes a case when RPATH embedded in program have one of
> its path already relative to ORIGIN. We were losing that path
> if such a path existed. This patch appends it to the new edited
> rpath being created when we see it.
>
> so RP
This fixes a case when RPATH embedded in program have one of
its path already relative to ORIGIN. We were losing that path
if such a path existed. This patch appends it to the new edited
rpath being created when we see it.
so RPATH like below
(RPATH) Library rpath:
[$ORIGIN/../lib/am
On Wed, Aug 15, 2012 at 3:46 PM, Andy Ross wrote:
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 556a176..ade0616 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -161,6 +161,17 @@ def package_qa_check_rpath(file,name, d, elf, me
We hit some oddball cases where libraries were being built with RPATHs
referencing host directores and causing version skew in builds. There
is a warning case to detect that already, but it was being fooled by
".." terms in the path strings. This just adds a normalize step to
the path comparison
In toolchain edge cases it's possible for the RPATH of a library to be
set to something like "/usr/lib/../lib". This should be detected as
"/usr/lib" and generate a warning. Also clarify the warning text to
indicate potential link-time pollution from the host libraries.
Signed-off-by: Andy Ross
Doh. Please nevermind. Looks like I'm getting caught up in my own url
confusion combined with ssh: fetcher trouble.
--rich
On 8/15/12 1:39 PM, Rich Pixley wrote:
If I build core-image-minimal with BB_GENERATE_MIRROR_TARBALLS :=
"1"... in my local.conf
And then I start a second build, w
On 8/15/12 4:39 PM, Richard Purdie wrote:
On Wed, 2012-08-15 at 17:18 +0100, Ross Burton wrote:
GNU Make 3.82 has some regressions regarding parallel processing that causes
some packages to fail, specifically WebKitGTK+. Add make-replacement-native
3.81 so that those packages can depend on a Ma
On Wed, 2012-08-15 at 22:17 +0100, Burton, Ross wrote:
> On 15 August 2012 22:12, Martin Jansa wrote:
> > eglibc was failing to build with make-3.81
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=2314
> >
> > so I guess once this is built (as webkit-gtk dependency), eglibc will maybe
> > s
On Wed, 2012-08-15 at 17:18 +0100, Ross Burton wrote:
> GNU Make 3.82 has some regressions regarding parallel processing that causes
> some packages to fail, specifically WebKitGTK+. Add make-replacement-native
> 3.81 so that those packages can depend on a Make which is known to work.
>
> Signed-
On 15 August 2012 22:12, Martin Jansa wrote:
> eglibc was failing to build with make-3.81
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2314
>
> so I guess once this is built (as webkit-gtk dependency), eglibc will maybe
> sometimes fail again..
Interesting, this is the first time I've enc
On Wed, Aug 15, 2012 at 05:18:49PM +0100, Ross Burton wrote:
> GNU Make 3.82 has some regressions regarding parallel processing that causes
> some packages to fail, specifically WebKitGTK+. Add make-replacement-native
> 3.81 so that those packages can depend on a Make which is known to work.
>
>
On 08/14/2012 12:01 PM, Richard Purdie wrote:
On Tue, 2012-08-14 at 15:12 +0300, Saul Wold wrote:
Signed-off-by: Saul Wold
---
.../console-tools/console-tools_0.3.2.bb |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/console-tools/co
If I build core-image-minimal with BB_GENERATE_MIRROR_TARBALLS := "1"...
in my local.conf
And then I start a second build, with:
SOURCE_MIRROR_URL := "file://.../firstbuild/.../downloads"
INHERIT += "own-mirrors"
BB_FETCH_PREMIRRORONLY := "1"
BB_NO_NETWORK := "1"
It fails almost immediatel
The kern-tools scripts can support a meta branch and directory of a name that
isn't "meta", but they need the name passed through the environment variable
KMETA. ensuring that KMETA is exported in the shell environment sets the stage
to support flexible meta branch name.
Signed-off-by: Bruce Ashfi
A BSP specific KBRANCH assignment is no longer a required
element to locate and build a yocto kernel. As such we can
set the default kbranch, and remove all other explicit
assignments.
KBRANCH is still used, and if it is changed from the
default, that branch will be built.
Signed-off-by: Bruce As
Richard/Saul,
Here's a consolidated update that I've had under test in one
way or another for 3 weeks now. Tom Z and others have also been
using parts of this for their work, so it has seen a reasonably
wide set of testers.
This series further streamlines working with linux-yocto* based
recipes/r
Updating the kern-tools SRCREV to pickup a collection of bug fixes
and cleanups:
75e71c3 kgit-config-cleaner: add -k
02be3b5 buildall: switch back to scc driven processing
c7101db kern-tools: support flexible branching
e2d06bd kern-tools: Remove superfluous references to "defconfig" from
The kernel branch is no longer required by the yocto-kern-tools
to locate BSP feature descriptions (it is the MACHINE:KTYPE
descriptor), so we no longer require that the BSP branch be
explicitly set.
If a kernel branch is explicitly set, it is now used to trigger
a checks to ensure that the branch
On 15 August 2012 20:27, McClintock Matthew-B29882 wrote:
> I've been doing something similar and it's been working OK. - I think
> we should apply Ross's patch.
Radu's, not mine.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openem
On 8/15/12 2:12 PM, Chris Larson wrote:
On Wed, Aug 15, 2012 at 11:05 AM, Mark Hatle wrote:
* The tasks can be used and referred to on the target if desired, not
just
when you compose the image (i.e. task packages are produced and thus the
package manager knows about them).
I think this i
On Wed, Aug 15, 2012 at 2:10 PM, Chris Larson wrote:
> On Wed, Aug 15, 2012 at 11:37 AM, McClintock Matthew-B29882
> wrote:
>> On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross wrote:
>>> On 24 July 2012 14:27, Chris Larson wrote:
On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan
wrote:
>>>
On Wed, Aug 15, 2012 at 11:05 AM, Mark Hatle wrote:
>> * The tasks can be used and referred to on the target if desired, not
>> just
>> when you compose the image (i.e. task packages are produced and thus the
>> package manager knows about them).
>
>
> I think this is a key advantage. Again, if
On Wed, Aug 15, 2012 at 11:37 AM, McClintock Matthew-B29882
wrote:
> On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross wrote:
>> On 24 July 2012 14:27, Chris Larson wrote:
>>> On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan wrote:
I have not tested on CentOS 5.8 if the applications are not broke
On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross wrote:
> On 24 July 2012 14:27, Chris Larson wrote:
>> On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan wrote:
>>> I have not tested on CentOS 5.8 if the applications are not broken in some
>>> way, but that's not in the scope of this patch. If somethin
On Wed, Aug 15, 2012 at 6:12 AM, Richard Purdie
wrote:
> Shouldn't this read:
>
> if rpath.find("$ORIGIN") != -1:
> new_rpaths.append("%s" % (rpath.strip()))
> continue
>
> as the code above would add *all* the old rpaths to the binary as
On 8/15/12 8:08 AM, Paul Eggleton wrote:
On Wednesday 15 August 2012 12:25:23 Phil Blundell wrote:
On Wed, 2012-08-15 at 10:46 +0100, Paul Eggleton wrote:
1) Do we rename "task" to something a little more understandable to the
uninitiated, such as "package group"? The word "task" is already use
If chrpath failed here we were just silently ignoring it.
Signed-off-by: Paul Eggleton
---
meta/classes/chrpath.bbclass |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/chrpath.bbclass b/meta/classes/chrpath.bbclass
index 10b5ca0..ad61fe0 100644
--- a/meta/c
GNU Make 3.82 has some regressions regarding parallel processing that causes
some packages to fail, specifically WebKitGTK+. Add make-replacement-native
3.81 so that those packages can depend on a Make which is known to work.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/make/make-replac
This isn't my finest moment but I welcome suggestions...
webkit-gtk fails with -j when the host has GNU Make 3.82. This appears to be a
GNU Make regression where it prunes rules it actually needs.
So add make-replacement-native 3.81, and depend on that in webkit-gtk.
I'm now off to scrub myself
Depend on make-replacement-native 3.81 so that we're certainly not building with
make 3.82, which some distributions have moved to. 3.82 is known to fail to
build webkit-gtk with -j and building without parallelism really isn't an
option.
See https://bugs.webkit.org/show_bug.cgi?id=79498 for the
On 08/15/2012 12:38 AM, Koen Kooi wrote:
> MIssing PR bump
Oops, fixed.
Andy
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
The task-core-lsb-runtime-add subpackage includes eglibc-pic as an
RDEPEND. That's incorrect, eglibc-pic is nothing but 22MB of static
libraries and should never appear as a runtime dependency.
Signed-off-by: Andy Ross
---
meta/recipes-extended/tasks/task-core-lsb.bb | 3 +--
1 file changed, 1
On Wed, 2012-08-15 at 08:37 -0700, Andy Ross wrote:
> On 08/15/2012 06:51 AM, Richard Purdie wrote:
> > Are files in that package required in order to pass LSB tests?
> >
> > I'm fine with removing it if it isn't required but I would like that
> > confirmation before we merge this.
>
> I can't spe
On 08/15/2012 06:51 AM, Richard Purdie wrote:
Are files in that package required in order to pass LSB tests?
I'm fine with removing it if it isn't required but I would like that
confirmation before we merge this.
I can't speak to the test suites, but these files are eglibc-specific, so
it's ha
Please see the commit message for the rpm one, most of the contents are
similar, except that add an function "add_external_debipk" which are
used by both deb and ipk, the add_external_ipk is just a wrapper.
[YOCTO #2948]
Signed-off-by: Robert Yang
---
meta/classes/external_package.bbclass | 44
It's been suggested that it would be a useful feature to be able to
easily take a binary from a 3rd party software vendor and integrate
it into an image created by the build system.
* The user can easily use this by:
# Specify where is the external binary pkg dir
#EXTERNAL_PACKAGE_DIR = " ...
Please see the commit message for the rpm one, most of the contents are
similar.
[YOCTO #2949]
Signed-off-by: Robert Yang
---
meta/classes/external_package.bbclass | 4
meta/classes/package_deb.bbclass | 43 +--
meta/classes/rootfs_deb.bbclass |
Hi folks,
Please see the first commit for details, and I will send a patch to
add the usage to local.conf.sample.extended when this is OK.
// Robert
The following changes since commit 0c6ac62a9fb81146ace64ae7493dcc56b4bed197:
documentation: remove references to Pimlico (2012-08-15 15:26:27 +0
On Wed, Aug 15, 2012 at 12:08 AM, wrote:
> +# Update the hostname according to actual board type
> +#
> +echo `cat /proc/cpuinfo | grep model | cut -d "," -f 2 | tr "[A-Z]" "[a-z]"`
> > /etc/hostname
> +
> +#
> # Trap CTRL-C &c only in this shell so we can interrupt subprocesses.
Th
On Wed, 2012-08-15 at 04:21 +, McClintock Matthew-B29882 wrote:
> On Tue, Aug 14, 2012 at 11:12 PM, Chris Larson wrote:
> > On Tue, Aug 14, 2012 at 9:06 PM, McClintock Matthew-B29882
> > wrote:
> >> On Tue, Aug 14, 2012 at 10:01 PM, Khem Raj wrote:
> >>> On Tue, Aug 14, 2012 at 8:08 PM, wr
On Tue, 2012-08-14 at 15:44 -0700, Andy Ross wrote:
> The task-core-lsb-runtime-add subpackage includes eglibc-pic as an
> RDEPEND. That's incorrect, eglibc-pic is nothing but 22MB of static
> libraries and should never appear as a runtime dependency.
>
> Signed-off-by: Andy Ross
> ---
> meta/r
On Tue, 2012-08-14 at 17:10 +0100, Ross Burton wrote:
> This class registers postinst/postrm hooks to compile the GSetting schemas,
> and
> adds the relevant dependencies. If possible the postinst happens on the host
> to
> avoid running it on the target.
>
> [ YOCTO #2798 ]
> ---
> meta/class
On Wed, Aug 15, 2012 at 02:24:58PM +0100, Richard Purdie wrote:
> On Thu, 2012-08-02 at 07:19 -0700, Wade Farnsworth wrote:
> > uprobes.ko is not located in /lib/modules, so it fails the check in
> > runstrip that ensures that only the debug section is stripped, leaving
> > the symbols untouched.
On Thu, 2012-08-02 at 07:19 -0700, Wade Farnsworth wrote:
> uprobes.ko is not located in /lib/modules, so it fails the check in
> runstrip that ensures that only the debug section is stripped, leaving
> the symbols untouched. This prevents the module from being inserted at
> run time. Inhibiting
On Tue, 2012-08-14 at 15:13 +0300, Saul Wold wrote:
> From: Marcin Juszkiewicz
>
> Signed-off-by: Marcin Juszkiewicz
> Signed-off-by: Saul Wold
> ---
> meta/recipes-core/dbus/dbus.inc |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
This was superseded by
http://git.yoctoprojec
On Tue, 2012-08-14 at 15:13 +0300, Saul Wold wrote:
> From: Khem Raj
>
> This fixes a case when RPATH embedded in program have one of
> its path already relative to ORIGIN. We were losing that path
> if such a path existed. This patch appends it to the new edited
> rpath being created when we see
On Wednesday 15 August 2012 12:25:23 Phil Blundell wrote:
> On Wed, 2012-08-15 at 10:46 +0100, Paul Eggleton wrote:
> > 1) Do we rename "task" to something a little more understandable to the
> > uninitiated, such as "package group"? The word "task" is already used in a
> > much more natural sense
On Wednesday 15 August 2012 12:17:40 Jack Mitchell wrote:
> > 1) Do we rename "task" to something a little more understandable to the
> > uninitiated, such as "package group"? The word "task" is already used in a
> > much more natural sense within bitbake as a unit of work. Historically I
> > belie
On Wednesday 15 August 2012 12:54:17 Koen Kooi wrote:
> Op 15 aug. 2012, om 11:46 heeft Paul Eggleton
het volgende geschreven:
> > 2) Look at the existing tasks and:
> > * evaluate their usefulness
> > * remove any that are obsolete
> > * adjust existing contents if needed
> > * look for useful g
On Wed, 2012-08-15 at 10:46 +0100, Paul Eggleton wrote:
> 1) Do we rename "task" to something a little more understandable to the
> uninitiated, such as "package group"? The word "task" is already used in a
> much more natural sense within bitbake as a unit of work. Historically I
> believe we p
On 15/08/12 10:46, Paul Eggleton wrote:
Hi all,
There have been a few requests to review the task recipes (i.e. package
groups) provided by OE-Core, and indeed these have not really been looked at
seriously since OE-Core was created. Ideally I think we want them to be useful
to a wide audience a
Op 15 aug. 2012, om 11:46 heeft Paul Eggleton
het volgende geschreven:
>
> 2) Look at the existing tasks and:
> * evaluate their usefulness
> * remove any that are obsolete
> * adjust existing contents if needed
> * look for useful groups of packages that might be added
>
> We need to pay part
On Wed, 2012-08-15 at 04:47 -0600, Gary Thomas wrote:
> I looked a bit into this and found that OE-core is already rather
> schizo on this topic, so I'm not quite sure what needs to be done
> here (i.e. should there be a DISTRO_FEATURES switch that chooses only
> one?) It would seem that all syste
On 2012-08-14 14:30, Phil Blundell wrote:
On Tue, 2012-08-14 at 08:47 -0600, Gary Thomas wrote:
I don't see anything explicit on this topic. That said, the latest version
(1.0) is dual licensed GPL and BSD and the OpenSSL license is BSD compatible
from what I can tell.
Yes, wpa-supplicant its
On 15 August 2012 02:22, Saul Wold wrote:
> Sorry not quite yet, there seems to be an issue with this patch set:
> (found with and arm and world builds)
I think I found the problem although I couldn't ever replicate the
failure. mesa-dri was failing to declare a dependency on libdrm (it
was sett
On Tue, 2012-08-14 at 15:12 +0300, Saul Wold wrote:
> Signed-off-by: Saul Wold
> ---
> .../console-tools/console-tools_0.3.2.bb |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/console-tools/console-tools_0.3.2.bb
> b/meta/recipes-
I just tested my mesa branch against stage/master_under_test too, builds fine.
The complication is that you need to ensure that the mesa-glsl-native
package is correct, even small patches to mesa make it produce bad
code, but then you get an entirely different error.
Ross
___
Hi all,
There have been a few requests to review the task recipes (i.e. package
groups) provided by OE-Core, and indeed these have not really been looked at
seriously since OE-Core was created. Ideally I think we want them to be useful
to a wide audience and provide useful units of functionalit
Op 15 aug. 2012, om 05:01 heeft Khem Raj het volgende
geschreven:
> On Tue, Aug 14, 2012 at 8:08 PM, wrote:
>> echo `cat /proc/cpuinfo | grep model | cut -d "," -f 2 | tr "[A-Z]" "[a-z]"`
>
> $ echo `cat /proc/cpuinfo | grep model | cut -d "," -f 2 | tr "[A-Z]" "[a-z]"`
> model : 23 model na
Op 15 aug. 2012, om 00:44 heeft Andy Ross het
volgende geschreven:
> The task-core-lsb-runtime-add subpackage includes eglibc-pic as an
> RDEPEND. That's incorrect, eglibc-pic is nothing but 22MB of static
> libraries and should never appear as a runtime dependency.
>
> Signed-off-by: Andy Ro
On 15 August 2012 07:56, Burton, Ross wrote:
> On 15 August 2012 02:22, Saul Wold wrote:
>>> | ../../../../include/GL/internal/dri_interface.h:51:17: fatal error:
>>> drm.h: No such file or directory
>
> Not what I was expecting. I've kicked off a local qemuarm build to
> investigate.
Hm, work
65 matches
Mail list logo
