Hi,
I've been wrestling with do_split_packages and package_ipk trying to
generate packages that have a customised DESCRIPTION override. I could
not get it to work. Here is roughly what I tried:
--- mytest.bb start ---
SUMMARY = "Generic summary"
DESCRIPTION = "Generic description"
...
Just a quick question regarding tcf-agent. Is anyone actually
using/maintaining this package?
I had a go at using the feature with Eclipse Luna, but it seems that the
oe-core tcf-agent package is so out of date that it won't work.
--
___
On 28/02/15 03:07, Burton, Ross wrote:
IIRC the general argument is if that if you're assuming a self-signed
certification is valid, you've lost so much security. We're in the
middle of a development cycle so this will only impact people using or
moving to 1.8.
I'm completely in favour of
On 24/02/15 17:39, Khem Raj wrote:
When we modify to use -Os
-Werror doesnt go well with it, glibc needs to be
cleaned up for that but until then lets disable -Werror
when using -Os
Change-Id: I5495255fce67953f15c07e423e3e0eef41d4ce5e
Signed-off-by: Khem Raj raj.k...@gmail.com
---
The check is supposed to be for -Os, but it's actually testing -O0.
Signed-off-by: Peter Urbanec openembedded-de...@urbanec.net
---
meta/recipes-core/glibc/glibc.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/glibc/glibc.inc
b/meta/recipes-core/glibc
On 02/03/15 15:23, Peter Urbanec wrote:
I think there's a typo here which prevents this from working as
intended. The second check is done on -O0 when it's supposed to be -Os
Tested patch submitted.
--
___
Openembedded-core mailing list
Openembedded
Just a couple of observations on this upgrade:
1. Python 2.7.9 now does strict SSL certificate checking as per
http://www.python.org/dev/peps/pep-0476/ and as a result I had at least
one package break due to:
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
I managed
On 27/02/15 20:35, Andreas Oberritter wrote:
as far as I remember, OE-Core policy forbids AUTOREV in recipes, because
it would make network access mandatory.
Fair enough. If that is the policy, it would probably be appropriate to
move the gstreamer1.01-*_git.bb recipes out of oe-core or at
version information which depends on SRC_URI when AUTOREV is used.
Any revision from master branch can be built by specifying the desired
SRCREV in the appropriate .conf file or using .bbappend. Patches can also
be applied on top in a similar manner.
Signed-off-by: Peter Urbanec openembedded-de
On WIN32 the file argument to gst_debug_log_valist is shortened to just
the filename. This is useful not only for MSVC, but also with gcc/Linux
when doing cross-compilation builds and out-of-tree builds.
Signed-off-by: Peter Urbanec openembedded-de...@urbanec.net
---
...gstinfo-Shorten-__FILE__
On 27/02/15 08:52, Burton, Ross wrote:
On 26 February 2015 at 17:57, Peter Urbanec
openembedded-de...@urbanec.net mailto:openembedded-de...@urbanec.net
wrote:
-SRCREV = 127202d6f65584891dabf92be031f0d170b0e7f1
+SRCREV ?= ${AUTOREV}
I'd say that the git packages should track
On 27/02/15 09:00, Otavio Salvador wrote:
On Thu, Feb 26, 2015 at 6:47 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Fri, 2015-02-27 at 04:31 +1100, Peter Urbanec wrote:
On WIN32 the file argument to gst_debug_log_valist is shortened to just
the filename. This is useful
On 27/02/15 08:45, Richard Purdie wrote:
+inherit gitpkgv
The gitpkgv class isn't in OE-Core, nor is it going to be (this has been
discussed on the mailing list before). As such if we merge this, OE-Core
won't parse, let alone build.
Does that mean that no packages in oe-core can currently
On 21/02/15 05:03, Richard Purdie wrote:
On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
...
For info, I've now merged the glibc part of this change now too.
It looks like the new glibc turns all gcc warnings into errors. That
On 12/02/15 11:00, Paul Gortmaker wrote:
Looking at the configure script, we see these invalid values are output
when the autoconf test for X11 fails. That test fails in the following
fashion:
...
Since the package clearly has never been built in a no-X11 OE environment,
we assume that all OE
On 17/01/15 09:15, Paul Barker wrote:
All these changes work locally in qemuarm and the on-target upgrade path
is
mostly clean. opkg-collateral does get left behind on the target
filesystem
after an upgrade but it's effectively an empty package. I don't think
this
On 07/02/15 22:55, Paul Barker wrote:
I didn't realise people were following oe-core master on deployments of a few
thousand systems! This is definitely a use-case for the stable branches.
The deployed systems are currently on:
opkg mips32el 1:0.2.2-r0
opkg-collateral mips32el 1.0-r2
@@ -0,0 +1,30 @@
+From: Peter Urbanec
+Subject: [opkg] Use upgrade argument in prerm and postrm scripts
+
+Current implementation of opkg makes it difficult to distinguish between
+package removal or upgrade in prerm and postrm scripts. The following patch
+will make it easier and is close(r
.
commit 03ae7912aadbf3b55b966a1367f07c7dbbddda80
Author: Peter Urbanec
Date: Fri Oct 10 00:03:28 2014 +1100
gcc: Patch for gcc bug 61144.
This fixes gcc bug 6144, which in my case exhibited itself as a kernel
module that failed to load. This was because static platform_data
19 matches
Mail list logo
