Re: [OE-core] How to handle mesa customization in BSP layers

[Nicolas Dechesne]

Le 25 oct. 2015 00:00, "Trevor Woerner"  a écrit :
>
> On 10/20/15 05:37, Koen Kooi wrote:
> >> Op 20 okt. 2015, om 11:32 heeft Nicolas Dechesne <
nicolas.deche...@linaro.org> het volgende geschreven:
> >>
> >>
> >> The issue is that mesa is arch specific, not machine specific. So if
> >> you start mixing machines from the same arch, we are getting
> >> unexpected/wrong rebuilds.
> > In this specific case I think we should enable freedreno for
armv7/armv8 in OE-core, but the problem remains for other recipes like this.
>
> Are you suggesting that every armv7 device should have their mesa tuned
> for freedreno and freedreno added to their filesystem? That seems quite
> overly-broad!

No. Only building the driver. It won't be installed unless you add it into
your image.

>
> On the surface[1] it would seem as though the decisions as to how one
> builds mesa and which graphics solution to install is more similar to
> the decision as to which DEFAULTTUNE to use, rather than which
> architecture is involved?
>

DEFAULTTUNE is a generic config that impacts all packages. What Koen
proposed is to change mesa to build more drivers by default.

>
>
>
>
>
>
> [1] which is my way of saying "I don't have the experience of actually
> having done this, unlike you people" ;-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base.bbclass: considering multilib when setting LICENSE_EXCLUSION

[Liu Jian]

Ping

于 2015年10月16日 13:58, Liu Jian 写道:

Hi All,

Will you going to merge this patch?
I have ever discuss with Robert Yang and he agreed to integrated it.

Thanks!
Jian


于 2015年10月08日 14:47, Jian Liu 写道:

The PACKAGES is not mapped with MLPREFIX when setting LICENSE_EXCLUSION
in base.bbclass. For example,
   For libgcc-dev,
 LICENSE_EXCLUSION-libgcc-dev=1
but for lib32-libgcc-dev,
 LICENSE_EXCLUSION-libgcc-dev=1
Obviously it is wrong for lib32-libgcc-dev.

Add MLPREFIX before the package name during setting LICENSE_EXCLUSION

Signed-off-by: Jian Liu 
---
  meta/classes/base.bbclass | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index f078001..89c8f04 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -512,7 +512,8 @@ python () {
  if unskipped_pkgs:
  for pkg in skipped_pkgs:
  bb.debug(1, "SKIPPING the package " + pkg + 
" at do_rootfs because it's " + recipe_license)

-d.setVar('LICENSE_EXCLUSION-' + pkg, 1)
+mlprefix = d.getVar('MLPREFIX', True)
+d.setVar('LICENSE_EXCLUSION-' + mlprefix + 
pkg, 1)

  for pkg in unskipped_pkgs:
  bb.debug(1, "INCLUDING the package " + pkg)
  elif all_skipped or incompatible_license(d, 
bad_licenses):




--
Jian Liu
Email: jian@windriver.com
Office Phone: 86-10-84778539

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gnupg: set development_version as no

[wenzong fan]

On 10/23/2015 06:40 PM, Burton, Ross wrote:


On 22 October 2015 at 10:33, > wrote:

+-development_version=mym4_isbeta
++development_version=no


I'd say that a neater fix would be to change the logic in autogen,sh to
set beta=no in the find-version logic.  There's a chance you can use the
argument that taking an upstream tarball and re-running autoconf
shouldn't be considered a development release to get it upstreamed then.


Ok, I'll update the patch.

Thanks
Wenzong



Ross

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Perl: Use CC version not $Config(gccversion)

[Jens Rehsack]

> Am 25.10.2015 um 00:17 schrieb Jeremy Puhlman :
> 
> 
> On Oct 24, 2015 5:15 AM, "Jens Rehsack"  wrote:
> >
> >
> > > Am 23.10.2015 um 19:18 schrieb Jeremy Puhlman :
> > >
> > > Get version data from querying $CC rather then
> > > $Config(gccversion) which comes from running version of
> > > perl. Since perl-native is not likely compiled by gcc
> > > 5 at this point, it will never trigger the required
> > > fixes for gcc 5.
> > >
> > > [YOCTO #8367]
> > >
> > > Signed-off-by: Jeremy Puhlman 
> > > ---
> > > .../perl/perl/perl-errno-generation-gcc5.patch | 23 
> > > ++
> > > meta/recipes-devtools/perl/perl_5.22.0.bb  |  1 +
> > > 2 files changed, 24 insertions(+)
> > > create mode 100644 
> > > meta/recipes-devtools/perl/perl/perl-errno-generation-gcc5.patch
> > >
> > > diff --git 
> > > a/meta/recipes-devtools/perl/perl/perl-errno-generation-gcc5.patch 
> > > b/meta/recipes-devtools/perl/perl/perl-errno-generation-gcc5.patch
> > > new file mode 100644
> > > index 000..efbc55d
> > > --- /dev/null
> > > +++ b/meta/recipes-devtools/perl/perl/perl-errno-generation-gcc5.patch
> > > @@ -0,0 +1,23 @@
> > > +Upstream-Status:Inappropriate [embedded specific]
> >
> > Did you ask p5-porters?
> >
> > I strongly suggest to open an RT for 2 reasons:
> >
> > 1) Let the people know that I'm not the only one encountering problems with 
> > the way they deal situation
> 
> Yeah we have been having fun cross compiling perl since 2000, lots of fun.
> 
> > 2) Those tickets enlighten over time.
> >
> > Cross-compiling is not restricted to embedded.
> >
> > The patch self looks more than sane and I'm happy to support it when 
> > reported (so tell me the ticket number or put me on CC when creating the 
> > ticket).
> 
> Is there a specific mailing list?

Kind-of, see https://rt.perl.org and use perlbug 
(http://perldoc.perl.org/perlbug.html)

> > > +The upstream code assumes that the compiler version used to compiler 
> > > miniperl/perl-native
> > > +is the same as the one being used to build the perl binary. Since most 
> > > people are not running
> > > +systems with gcc 5, it is unlikely that it will work on any supported 
> > > host. Switch out gccversion
> > > +for the version extracted from $CC --version.
> > > +
> > > +--- perl-5.22.0/ext/Errno/Errno_pm.PL2015-10-19 
> > > 18:01:20.622143786 -0400
> > >  perl-5.22.0-fixed/ext/Errno/Errno_pm.PL  2015-10-19 
> > > 17:50:35.662137367 -0400
> > > +@@ -224,9 +224,12 @@
> > > +
> > > + {   # BeOS (support now removed) did not enter this block
> > > + # invoke CPP and read the output
> > > ++my $compiler = $ENV{'CC'};
> > > ++my $compiler_out = `$compiler --version`;
> > > ++my @compiler_version = split / /,$compiler_out;
> > > +
> > > + my $inhibit_linemarkers = '';
> > > +-if ($Config{gccversion} =~ /\A(\d+)\./ and $1 >= 5) {
> > > ++if (@compiler_version[2] =~ /\A(\d+)\./ and $1 >= 5) {
> > > + # GCC 5.0 interleaves expanded macros with line numbers breaking
> > > + # each line into multiple lines. RT#123784
> > > + $inhibit_linemarkers = ' -P';
> > > diff --git a/meta/recipes-devtools/perl/perl_5.22.0.bb 
> > > b/meta/recipes-devtools/perl/perl_5.22.0.bb
> > > index 3ce7849..66e074d 100644
> > > --- a/meta/recipes-devtools/perl/perl_5.22.0.bb
> > > +++ b/meta/recipes-devtools/perl/perl_5.22.0.bb
> > > @@ -62,6 +62,7 @@ SRC_URI += " \
> > > file://ext-ODBM_File-hints-linux.pl-link-libgdbm_compat.patch \
> > > file://ext-ODBM_File-t-odbm.t-fix-the-path-of-dbmt_common.p.patch 
> > > \
> > > file://perl-PathTools-don-t-filter-out-blib-from-INC.patch \
> > > +file://perl-errno-generation-gcc5.patch \
> > > "
> > >
> > > # Fix test case issues

-- 
Jens Rehsack - rehs...@gmail.com

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core