All,
The buildout of rc3 will be complete in a few hours and available at:
http://autobuilder.yoctoproject.org/pub/releases/1.5_M4.rc3
The one issue we're seeing at this time is sanity failures in qemuppc
and qemumips. They appear to be slow/hung boot issues. This seems to
be a new issue (https:/
Cleanup of perl recipes for CPAN modules in meta-security layer. One is
renamed, one is removed because a recipe already exists in core.
The following changes since commit 5ec81ec5b117de41ed56eb05df271f103213d7be:
Bastille: document the current status and usability of the Bastille install.
(201
[YOCTO #5081]
The recipe meta-security/recipes-security/perl/curses-perl_1.28.bb is renamed
to libcurses-perl_1.28.bb to conform to accepted naming scheme.
The dependency in the Bastille recipe is updated accordingly.
Signed-off-by: mulhern
---
recipes-security/bastille/bastille_3.2.1.bb
[YOCTO #5081]
The recipe meta-security/recipes-security/env-perl_1.04.bb is removed since
there is a recipe for the same Perl module at
poky/meta/recipes-lsb4/perl/libenv-perl_1.04.bb. The dependency on env-perl
in the checksecurity recipe is updated to a recipe on libenv-perl.
Signed-off-by: mul
Oops, I was so worried about sending to the right address, I forgot about
marking it meta-selinux.
Joe
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Thursday, September 05, 2013 10:05 AM
> To: Slater, Joseph
> Cc: Ouyang, Xin; Slater, Joseph; y
The erroneous dependency of libcap-ng on libcap is deleted. Note that libcap-ng
provides Python bindings, but that this package does not. Currently, the only
recipe that depends on libcap-ng is redhat-security which does not require
Python bindings. If Python bindings are needed subsequently a swi
On Thu, Sep 5, 2013 at 9:40 AM, Hans Beckérus wrote:
> On Wed, Sep 4, 2013 at 6:06 PM, Hans Beckérus wrote:
>> On Wed, Sep 4, 2013 at 5:02 PM, Hans Beckérus
>> wrote:
>>> On Wed, Sep 4, 2013 at 12:21 PM, Hans Beckérus
>>> wrote:
On Wed, Sep 4, 2013 at 12:03 PM, Hans Beckérus
wrote
[YOCTO #5084]
libcap has been removed from the list of DEPENDS packages. Since libcap was the
only package in the list the DEPENDS variable has been removed from the recipe
file.
Signed-off-by: mulhern
---
recipes-security/libcap-ng/libcap-ng_0.7.3.bb |1 -
1 file changed, 1 deletion(-)
di
Hi Joe,
On Thursday 05 September 2013 09:51:36 Joe Slater wrote:
> If acl is a distro feature, we want to depend
> on it. Note that without the xattrs patch, tar
> cannot deal with acl information.
>
> Signed-off-by: Joe Slater
> ---
> recipes-extended/tar/tar_1.26.bbappend | 10 +-
>
If acl is a distro feature, we want to depend
on it. Note that without the xattrs patch, tar
cannot deal with acl information.
Signed-off-by: Joe Slater
---
recipes-extended/tar/tar_1.26.bbappend | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/recipes-extended/
Now that the testimage class from core has the ability to run tests from other
layers it makes sens to add a basic runtime test here.
This runs some basic scripts from the redhat-security package that this layer
provides.
Signed-off-by: Stefan Stanacar
---
lib/oeqa/runtime/__init__.py|
On Thu, Sep 5, 2013 at 6:53 AM, Bryan Evenson wrote:
> I am working on getting the Yocto Autobuilder setup on a machine to do
> nightly builds of my image (I'm using yocto-autobuilder/dylan). However, I'm
> running into a few problems and I'm looking for some help.
>
> First, here is the config
I am working on getting the Yocto Autobuilder setup on a machine to do nightly
builds of my image (I'm using yocto-autobuilder/dylan). However, I'm running
into a few problems and I'm looking for some help.
First, here is the configuration that I have setup so far for my nightly build.
I woul
Hi Paul
On 05/09/2013 12:00, Paul Eggleton wrote:
On Thursday 05 September 2013 11:45:26 JC wrote:
On 05/09/2013 11:32, Paul Eggleton wrote:
Unfortunately we have to have a fixed configuration for smart during
do_rootfs, so it has to be written to. I think though that rather than
trying to ins
Hi Lothar,
On Thursday 05 September 2013 12:09:57 lot...@denx.de wrote:
> Is it possible to declare a kernels' SRC_URI, as also certain functions,
> directly in the machine config, instead of the kernel .bb?
>
> Example: currently I declare the following in a mykernel.bb (derrived
> from kernel.b
Hello Yoctoholics!
Is it possible to declare a kernels' SRC_URI, as also certain functions,
directly in the machine config, instead of the kernel .bb?
Example: currently I declare the following in a mykernel.bb (derrived
from kernel.bbclass)
SRC_URI_mymachine = "git:my-git-repo"
do_c
On jeu., sept. 5, 2013 at 12:00 PM, Paul Eggleton
mailto:paul.eggle...@linux.intel.com";>> wrote:
On Thursday 05 September 2013 11:45:26 JC wrote:
> On 05/09/2013 11:32, Paul Eggleton wrote:
> > Unfortunately we have to have a fixed configuration for smart during
> > do_rootfs, so it has t
On Thursday 05 September 2013 11:45:26 JC wrote:
> On 05/09/2013 11:32, Paul Eggleton wrote:
> > Unfortunately we have to have a fixed configuration for smart during
> > do_rootfs, so it has to be written to. I think though that rather than
> > trying to install a configuration file for smart using
On 05/09/2013 11:32, Paul Eggleton wrote:
Hi Jay,
On Wednesday 04 September 2013 22:10:10 JC wrote:
On 04/09/2013 21:58, JC wrote:
On 04/09/2013 20:58, JC wrote:
Hi,
In my project, we have our own rpm repository and we use smartpm on
the target.
In order to have the target setup with the rep
Hi Jay,
On Wednesday 04 September 2013 22:10:10 JC wrote:
> On 04/09/2013 21:58, JC wrote:
> > On 04/09/2013 20:58, JC wrote:
> >> Hi,
> >>
> >> In my project, we have our own rpm repository and we use smartpm on
> >> the target.
> >> In order to have the target setup with the repo out of the box
Hi Paul
On 05/09/2013 10:28, Paul Eggleton wrote:
Hi Jay,
On Thursday 05 September 2013 10:20:41 JC wrote:
ERROR: ParseError at
/media/yocto/yocto/meta-openembedded/meta-oe/recipes-devtools/libgee/libgee.
inc:12: Could not inherit file classes/vala.bbclass
ERROR: Command execution failed: Exit
I just noticed that pax-utils is in core and has nothing to do with
meta-security, so this is pointless, please ignore.
I'll send some other test for this layer.
Cheers,
Stefan
On Thu, 2013-09-05 at 11:15 +0300, Stefan Stanacar wrote:
> Now that the testimage class from core has the ability to ru
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Hi Jay,
On Thursday 05 September 2013 10:20:41 JC wrote:
> ERROR: ParseError at
> /media/yocto/yocto/meta-openembedded/meta-oe/recipes-devtools/libgee/libgee.
> inc:12: Could not inherit file classes/vala.bbclass
> ERROR: Command execution failed: Exited with 1
>
>
> If this is not something you
In the log you posted is the line:
ERROR: Failed to parse recipe:
/media/yocto/yocto/openembedded-core/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.28.2.bb
So something was adding the path
/media/yocto/yocto/openembedded-core/meta to BBLAYERS. If you've just
removed that, give it another try.
Hi Martin,
On Thursday 05 September 2013 10:04:07 Martin Jansa wrote:
> On Thu, Sep 05, 2013 at 01:10:47AM +0100, Paul Eggleton wrote:
> > As always, feedback is welcome.
>
> Great job!
>
> One more suggestion (maybe I've overlooked it):
>
> It would be nice to be able to search recipe across a
Now that the testimage class from core has the ability to run tests from other
layers it makes sens to add a basic runtime test here.
This uses scanelf from the pax-utils package and scans the binaries in PATH
for TEXTREL and RPATH information.
Signed-off-by: Stefan Stanacar
---
lib/oeqa/runtime
On 5 September 2013 09:08, JC wrote:
> On 05/09/2013 10:04, Paul Barker wrote:
>> The log you've attached shows paths for poky as well as
>> openembedded-core. Poky is basically a combination of
>> openembedded-core, meta-yocto and bitbake so you don't want to add
>> openembedded-core again. Could
On 05/09/2013 10:04, Paul Barker wrote:
On 5 September 2013 08:55, JC wrote:
As a reference, following this link
http://www.pimpmypi.com/blog/blogPost.php?blogPostID=7 I got successful
(well the image is not yet finished but I hadn't that specific parsing
error)
I followed the exact README ste
On 5 September 2013 08:55, JC wrote:
>
> As a reference, following this link
> http://www.pimpmypi.com/blog/blogPost.php?blogPostID=7 I got successful
> (well the image is not yet finished but I hadn't that specific parsing
> error)
>
> I followed the exact README steps in a fresh directory for th
On Thu, Sep 05, 2013 at 01:10:47AM +0100, Paul Eggleton wrote:
> As always, feedback is welcome.
Great job!
One more suggestion (maybe I've overlooked it):
It would be nice to be able to search recipe across all branches
(including oe-classic)
e.g. if someone asks me to include ace in our build
Hi,
On 05/09/2013 09:31, Paul Barker wrote:
That looks like a parse error so the full log shouldn't be very long
as that point, may be helpful to post it.
I attached rpibuild.log to this email
my local.conf changes: just added raspberrypi machine
bblayers.conf:
added
/media/yocto/yocto/o
On Wed, Sep 4, 2013 at 6:06 PM, Hans Beckérus wrote:
> On Wed, Sep 4, 2013 at 5:02 PM, Hans Beckérus wrote:
>> On Wed, Sep 4, 2013 at 12:21 PM, Hans Beckérus
>> wrote:
>>> On Wed, Sep 4, 2013 at 12:03 PM, Hans Beckérus
>>> wrote:
On Wed, Sep 4, 2013 at 11:56 AM, Hans Beckérus
wrot
On 5 September 2013 08:21, JC wrote:
> On 04/09/2013 18:46, Gary Thomas wrote:
>>
>> git://git.yoctoproject.org/meta-raspberrypi
>>
> Thanks. I checked out everything (including a "fresh" poky) and I get this
> error:
> ERROR: Error executing a python function in :# | ETA: 00:00:57
> ExpansionE
Thanks Sean. I uncommented MACHINE ?= "atom-pc" in local.conf file and the
bitbake created .hddimg extension.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
On 04/09/2013 18:46, Gary Thomas wrote:
On 2013-09-04 10:40, JC wrote:
Hi,
I am maintaining a small project based on yocto and would like to
check to what extent I can port it to Raspberry.
It seems there's an ongoing rapsberry layer but I couldn't find which
is the right URL to point to in o
36 matches
Mail list logo