* Re: [PATCH 1/2] attr/acl: add SSTATEPOSTINSTFUNC
From: Phil Blundell @ 2011-10-04 15:36 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <62e9da86a45eef3dd374bd8c7e110f619f620f80.1316890497.git.sgw@linux.intel.com>
On Sat, 2011-09-24 at 11:56 -0700, Saul Wold wrote:
> +fix_symlink () {
> + # Remove bad symlinks & create the correct symlinks
> + if test -L ${libdir}/lib${BPN}.so ; then
> + rm -rf ${libdir}/lib${BPN}.so
> + ln -sf ${base_libdir}/lib${BPN}.so ${libdir}/lib${BPN}.so
> + fi
This breaks the build for me on micro. I end up with a symlink pointing
to itself:
lrwxrwxrwx 1 pb pb 76 2011-10-04
16:09 /home/pb/oe/build-epia/build/tmp-eglibc/sysroots/x86_64-linux/lib/libattr.so -> /home/pb/oe/build-epia/build/tmp-eglibc/sysroots/x86_64-linux/lib/libattr.so
with predictably bad results.
p.
^ permalink raw reply
* Re: sstate_clean() overzealous?
From: Phil Blundell @ 2011-10-04 15:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317725702.14671.33.camel@ted>
On Tue, 2011-10-04 at 11:54 +0100, Richard Purdie wrote:
> I think we need to teach this clean function about stamp-extra-info and
> instead of stfile + ".*", remove stfile + ".*." + stamp-extra-info if
> stamp-extra-info is set. That would likely fix the problem you're
> seeing.
Okay, thanks. I applied this change locally:
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 91f209a..7f38800 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -258,10 +258,15 @@ def sstate_clean(ss, d):
bb.utils.unlockfile(lock)
stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
+ extrainf = d.getVarFlag("do_" + ss['task'], 'stamp-extra-info')
oe.path.remove(stfile)
oe.path.remove(stfile + "_setscene")
- oe.path.remove(stfile + ".*")
- oe.path.remove(stfile + "_setscene" + ".*")
+ if extrainf:
+ oe.path.remove(stfile + ".*." + extrainf)
+ oe.path.remove(stfile + "_setscene" + ".*." + extrainf)
+ else:
+ oe.path.remove(stfile + ".*")
+ oe.path.remove(stfile + "_setscene" + ".*")
CLEANFUNCS += "sstate_cleanall"
and it does indeed seem to resolve the problem I was seeing before.
p.
^ permalink raw reply related
* Re: [PATCH 0/7] Qt4 upgrade/fixes
From: Richard Purdie @ 2011-10-04 13:21 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <j6abik$9f7$1@dough.gmane.org>
On Sun, 2011-10-02 at 22:45 +0400, Dmitry Eremin-Solenikov wrote:
> On 09/30/2011 08:57 PM, Richard Purdie wrote:
> > On Fri, 2011-09-30 at 17:33 +0100, Paul Eggleton wrote:
> >> This is a pull request for Eric Bénard's qt4_upgrade branch, including
> >> an update of Qt to 4.7.4 (preserving 4.7.3 until other layers such as
> >> meta-oe, meta-yocto etc. can sync up) as well as several important bug
> >> fixes.
> >>
> >> The patches look good; if was to be really picky though I would say that
> >> the two demo/doc patches in the series ought to be merged into one patch,
> >> and there are a few typos in the commit messages. I'm also relying on
> >> others to review the correctness of the armv6-vfp no-neon patch as I have
> >> no knowledge of this area.
> >>
> >>
> >> The following changes since commit c54c1280fc0d06a53e23339c3913ec88eead13d9:
> >>
> >> base.bbclass: Drop unneeded dependency (2011-09-30 11:34:44 +0100)
> >>
> >> are available in the git repository at:
> >> git://git.openembedded.org/openembedded-core-contrib paule/qt4_upgrade
> >> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/qt4_upgrade
> >>
> >> Denis Carikli (3):
> >> qt4.inc: remove the optional documentation package from the demo's
> >> RRECOMMENDS
> >> qt4(embedded and x11): disable neon for armv6-vfp
> >> qt4.inc: package qtdemo's docs in a separate package
> >>
> >> Eric Bénard (3):
> >> qt4e-demo-image: improve image
> >> qt4: fix generated sdk
> >> qt4: update to latest version 4.7.4
> >>
> >> Otavio Salvador (1):
> >> qt4: fix translation support
> >
> > Thanks Paul. I fixed the typos and queued this on master-next.
>
> It seems, during 4.7.3 -> 4.7.4 addition, fix-translation patch got
> lost. Richard please reaply the "qt4: fix translation support" after
> s/4.7.3/4.7.4/ . I can provide a patch if you'd like.
Thanks, I'll merge your two patches. If there is anything else qt4
related that is missing please let me know as I'm assuming these merges
bring the qt4 patches up to date!
Cheers,
Richard
^ permalink raw reply
* Re: bitbake webkit-gtk fails with clean temp dir
From: Richard Purdie @ 2011-10-04 12:40 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <201110032045.14771.schnitzeltony@gmx.de>
On Mon, 2011-10-03 at 20:45 +0200, Andreas Müller wrote:
> On Monday, October 03, 2011 05:29:52 PM Gary Thomas wrote:
> > >> NOTE: package webkit-gtk-1.5.1+svnr90727-r0: task do_compile: Failed
> > >> ERROR: Task 7 (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-sato/webkit/webkit-gtk_svn.bb, do_compile) failed with exit code '1'
> > >>
> > >> ideas what causes this?
> > >
> > > no idea, but I get the same error
> > >
> >
> > It builds in Yocto/Poky so you might compare with those recipes.
> Dit you pull [1] and rebuild webkit-gtk?
> >
> >
> some investigation later: by diff'ing log files created by working environment with the current environment I fell over log.do_configure:
>
> --disable-dependency-tracking
>
> was added in [1]. Tried manual bisecting by
>
> git reset --hard 288343e30604b944dc18fd82172febd314d9c520
>
> é voilà: webkit-gtk builds again. Will send a patch with --enable-dependency-tracking after testing...
>
> Andreas
I'm planning to add this commit:
http://cgit.openembedded.org/cgit.cgi/openembedded-core/commit/?h=master-next&id=d53a0282be132a4ced507c0277925ae4a0f2f40d
which means you should just be able to set:
CONFIGUREOPT_DEPTRACK = ""
for this recipe rather than having multiple configure options and hoping
the right one wins.
I'd also note this means there is a bug somewhere in the webkit
makefiles...
Cheers,
Richard
^ permalink raw reply
* autotools.bbclass: Allow dependency tracking option to be easily overridden
From: Richard Purdie @ 2011-10-04 12:38 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index ff27842..a4ce851 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -64,8 +64,10 @@ CONFIGUREOPTS = " --build=${BUILD_SYS} \
--infodir=${infodir} \
--mandir=${mandir} \
--disable-silent-rules \
- --disable-dependency-tracking \
+ ${CONFIGUREOPT_DEPTRACK} \
${@append_libtool_sysroot(d)}"
+CONFIGUREOPT_DEPTRACK = "--disable-dependency-tracking"
+
oe_runconf () {
if [ -x ${S}/configure ] ; then
^ permalink raw reply related
* Re: [PATCHv2 26/30] glx-use-tls: add from meta-oe layer
From: Richard Purdie @ 2011-10-04 12:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111003150904.GR7364@jama.jama.net>
On Mon, 2011-10-03 at 17:09 +0200, Martin Jansa wrote:
> On Mon, Oct 03, 2011 at 04:02:10PM +0100, Phil Blundell wrote:
> > Can you add some commentary explaining why this is necessary -- i.e.
> > what exactly is lacking in uClibc to mean it doesn't have "prober TLS
> > support"?
>
> I'm not using uClibc myself and tracking original bbclass in OE-classic
> leads to this commit
> http://git.openembedded.org/cgit.cgi/openembedded/commit/packages/mesa/mesa-tls.inc?id=b527d8f723c98c77f2f5c5358062e5348493d767
>
> So I'm CCing woglinde and he will probably explain it.
At the very least this should become an include file in the mesa
directory. Its not sufficiently generally used at this point to become a
bbclass file...
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 4/4] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Martin Jansa @ 2011-10-04 11:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <87E5B689-06D2-4E3C-81E1-D4DA363CD0C1@dominion.thruhere.net>
[-- Attachment #1: Type: text/plain, Size: 4401 bytes --]
On Tue, Oct 04, 2011 at 06:03:16AM -0500, Koen Kooi wrote:
>
>
> Op 30 sep. 2011 om 13:37 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
>
> > On Thu, Sep 29, 2011 at 06:27:11PM -0700, nitin.a.kamble@intel.com wrote:
> >> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >>
> >> Rebased these patches to the newer code
> >> modified: python-native/nohostlibs.patch
> >> modified: python/01-use-proper-tools-for-cross-build.patch
> >> modified: python/06-avoid_usr_lib_termcap_path_in_linking.patch
> >> modified: python/06-ctypes-libffi-fix-configure.patch
> >> modified: python/multilib.patch
> >>
> >> Deleted these patches are the are now upstream
> >> deleted: python/02-remove-test-for-cross.patch
> >> deleted: python/security_issue_2254_fix.patch
> >>
> >> Added this patch to python-native
> >> new file: python-native/multilib.patch
> >>
> >> Updated site config files for python
> >> modified: ../../site/arm-common
> >> modified: ../../site/mips-common
> >>
> >> Updated default python version
> >> modified: ../../conf/distro/include/default-versions.inc
> >>
> >> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> >> ---
> >> meta/conf/distro/include/default-versions.inc | 6 +-
> >> ...on-2.6-manifest.inc => python-2.7-manifest.inc} | 0
> >> .../python/python-native/multilib.patch | 240 ++++++++++++++++++++
> >> .../python/python-native/nohostlibs.patch | 36 ++-
> >> ...thon-native_2.6.6.bb => python-native_2.7.2.bb} | 13 +-
> >> meta/recipes-devtools/python/python.inc | 16 +-
> >> .../01-use-proper-tools-for-cross-build.patch | 118 +++++++---
> >> .../python/python/02-remove-test-for-cross.patch | 108 ---------
> >> .../06-avoid_usr_lib_termcap_path_in_linking.patch | 16 +-
> >> .../python/06-ctypes-libffi-fix-configure.patch | 42 ++---
> >> meta/recipes-devtools/python/python/multilib.patch | 126 ++++++-----
> >> .../python/python/security_issue_2254_fix.patch | 184 ---------------
> >> .../python/{python_2.6.6.bb => python_2.7.2.bb} | 10 +-
> >> meta/site/arm-common | 3 +
> >> meta/site/mips-common | 3 +
> >> 15 files changed, 467 insertions(+), 454 deletions(-)
> >> rename meta/recipes-devtools/python/{python-2.6-manifest.inc => python-2.7-manifest.inc} (100%)
> >> create mode 100644 meta/recipes-devtools/python/python-native/multilib.patch
> >> rename meta/recipes-devtools/python/{python-native_2.6.6.bb => python-native_2.7.2.bb} (74%)
> >> delete mode 100644 meta/recipes-devtools/python/python/02-remove-test-for-cross.patch
> >> delete mode 100644 meta/recipes-devtools/python/python/security_issue_2254_fix.patch
> >> rename meta/recipes-devtools/python/{python_2.6.6.bb => python_2.7.2.bb} (92%)
> >>
> >> diff --git a/meta/conf/distro/include/default-versions.inc b/meta/conf/distro/include/default-versions.inc
> >> index e3ef1e6..90ff005 100644
> >> --- a/meta/conf/distro/include/default-versions.inc
> >> +++ b/meta/conf/distro/include/default-versions.inc
> >> @@ -4,9 +4,9 @@
> >> PREFERRED_VERSION_pulseaudio ?= "0.9.23"
> >>
> >> # Force the python versions in one place
> >> -PYTHON_BASEVERSION ?= "2.6"
> >> -PREFERRED_VERSION_python ?= "2.6.6"
> >> -PREFERRED_VERSION_python-native ?= "2.6.6"
> >> +PYTHON_BASEVERSION ?= "2.7"
> >> +PREFERRED_VERSION_python ?= "2.7.2"
> >> +PREFERRED_VERSION_python-native ?= "2.7.2"
> >>
> >> # Force the older version of liberation-fonts until we fix the fontforge issue
> >> PREFERRED_VERSION_liberation-fonts ?= "1.04"
> >> diff --git a/meta/recipes-devtools/python/python-2.6-manifest.inc b/meta/recipes-devtools/python/python-2.7-manifest.inc
> >> similarity index 100%
> >> rename from meta/recipes-devtools/python/python-2.6-manifest.inc
> >> rename to meta/recipes-devtools/python/python-2.7-manifest.inc
> >
> > this is wrong.. just to rename it isn't enough
>
> It also drops the source checksums :(
They are moved to python.inc which is then included to both python and
python-native recipes.
But maybe we should drop
DEFAULT_PREFERENCE = "-27"
as there is only one python version anyways
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Koen Kooi @ 2011-10-04 11:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Cc: Patches and discussions about the oe-core layer
In-Reply-To: <20110930183732.GH7364@jama.jama.net>
Op 30 sep. 2011 om 13:37 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
> On Thu, Sep 29, 2011 at 06:27:11PM -0700, nitin.a.kamble@intel.com wrote:
>> From: Nitin A Kamble <nitin.a.kamble@intel.com>
>>
>> Rebased these patches to the newer code
>> modified: python-native/nohostlibs.patch
>> modified: python/01-use-proper-tools-for-cross-build.patch
>> modified: python/06-avoid_usr_lib_termcap_path_in_linking.patch
>> modified: python/06-ctypes-libffi-fix-configure.patch
>> modified: python/multilib.patch
>>
>> Deleted these patches are the are now upstream
>> deleted: python/02-remove-test-for-cross.patch
>> deleted: python/security_issue_2254_fix.patch
>>
>> Added this patch to python-native
>> new file: python-native/multilib.patch
>>
>> Updated site config files for python
>> modified: ../../site/arm-common
>> modified: ../../site/mips-common
>>
>> Updated default python version
>> modified: ../../conf/distro/include/default-versions.inc
>>
>> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
>> ---
>> meta/conf/distro/include/default-versions.inc | 6 +-
>> ...on-2.6-manifest.inc => python-2.7-manifest.inc} | 0
>> .../python/python-native/multilib.patch | 240 ++++++++++++++++++++
>> .../python/python-native/nohostlibs.patch | 36 ++-
>> ...thon-native_2.6.6.bb => python-native_2.7.2.bb} | 13 +-
>> meta/recipes-devtools/python/python.inc | 16 +-
>> .../01-use-proper-tools-for-cross-build.patch | 118 +++++++---
>> .../python/python/02-remove-test-for-cross.patch | 108 ---------
>> .../06-avoid_usr_lib_termcap_path_in_linking.patch | 16 +-
>> .../python/06-ctypes-libffi-fix-configure.patch | 42 ++---
>> meta/recipes-devtools/python/python/multilib.patch | 126 ++++++-----
>> .../python/python/security_issue_2254_fix.patch | 184 ---------------
>> .../python/{python_2.6.6.bb => python_2.7.2.bb} | 10 +-
>> meta/site/arm-common | 3 +
>> meta/site/mips-common | 3 +
>> 15 files changed, 467 insertions(+), 454 deletions(-)
>> rename meta/recipes-devtools/python/{python-2.6-manifest.inc => python-2.7-manifest.inc} (100%)
>> create mode 100644 meta/recipes-devtools/python/python-native/multilib.patch
>> rename meta/recipes-devtools/python/{python-native_2.6.6.bb => python-native_2.7.2.bb} (74%)
>> delete mode 100644 meta/recipes-devtools/python/python/02-remove-test-for-cross.patch
>> delete mode 100644 meta/recipes-devtools/python/python/security_issue_2254_fix.patch
>> rename meta/recipes-devtools/python/{python_2.6.6.bb => python_2.7.2.bb} (92%)
>>
>> diff --git a/meta/conf/distro/include/default-versions.inc b/meta/conf/distro/include/default-versions.inc
>> index e3ef1e6..90ff005 100644
>> --- a/meta/conf/distro/include/default-versions.inc
>> +++ b/meta/conf/distro/include/default-versions.inc
>> @@ -4,9 +4,9 @@
>> PREFERRED_VERSION_pulseaudio ?= "0.9.23"
>>
>> # Force the python versions in one place
>> -PYTHON_BASEVERSION ?= "2.6"
>> -PREFERRED_VERSION_python ?= "2.6.6"
>> -PREFERRED_VERSION_python-native ?= "2.6.6"
>> +PYTHON_BASEVERSION ?= "2.7"
>> +PREFERRED_VERSION_python ?= "2.7.2"
>> +PREFERRED_VERSION_python-native ?= "2.7.2"
>>
>> # Force the older version of liberation-fonts until we fix the fontforge issue
>> PREFERRED_VERSION_liberation-fonts ?= "1.04"
>> diff --git a/meta/recipes-devtools/python/python-2.6-manifest.inc b/meta/recipes-devtools/python/python-2.7-manifest.inc
>> similarity index 100%
>> rename from meta/recipes-devtools/python/python-2.6-manifest.inc
>> rename to meta/recipes-devtools/python/python-2.7-manifest.inc
>
> this is wrong.. just to rename it isn't enough
It also drops the source checksums :(
>
> I will send patch which regenerates manifest with right paths to
> actually package something..
>
> Regards,
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: sstate_clean() overzealous?
From: Richard Purdie @ 2011-10-04 10:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317660469.13337.16.camel@phil-desktop>
On Mon, 2011-10-03 at 17:47 +0100, Phil Blundell wrote:
> The sstate_clean() function in sstate.bbclass is doing (inter alia):
>
> stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
> [...]
> oe.path.remove(stfile + ".*")
> oe.path.remove(stfile + "_setscene" + ".*")
>
> which means that, for tasks which set the stamp-extra-info flag to
> ${MACHINE}, it ends up blowing away the stamps for all machines rather
> than just the current one. The net effect of this seems to be that
> there is no way to have the setscene stamps populated for more than one
> MACHINE at any time, and hence all those tasks get rerun every time you
> change MACHINE even if nothing else has been altered.
>
> Is this behaviour deliberate?
No, its not intended to be wiping out all the different machines.
> It is certainly a little bit annoying but
> I don't understand the internals of sstate well enough to judge what
> exactly that glob is trying to accomplish.
The trouble is we now support a variety of different stamp file formats
depending on what settings you have enabled (and metadata you're using).
Clean can be called from two sources, do_clean, or just before a sstate
controlled task is about to be run. In either case we want to clear out
any previous "state" including any stamp files that might have
represented this task since we're about to invalidate anything they did.
This means wiping out "normal" stamps and any setscene variants of those
stamps. We also want to remove any stamps representing other hashes for
this task since there is no version installed.
If the BasicHash signature generator code is enabled this adds hashes to
the stamp files. This turns the stamps into the form:
<stampfile>.<hash>
or in the case of machine specific tasks:
<stampfile>.<hash>.<machine>
I think we need to teach this clean function about stamp-extra-info and
instead of stfile + ".*", remove stfile + ".*." + stamp-extra-info if
stamp-extra-info is set. That would likely fix the problem you're
seeing.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCHv2 00/30] Xorg related changes
From: Martin Jansa @ 2011-10-04 10:52 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
In-Reply-To: <1317723797.14671.22.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
On Tue, Oct 04, 2011 at 11:23:09AM +0100, Richard Purdie wrote:
> On Mon, 2011-10-03 at 15:28 +0200, Martin Jansa wrote:
> > this patchset brings meta-oe and oe-core xorg stuff together and most of
> > xorg recipes will be removed from meta-oe (sending another pull request now).
>
> Did anything in the first seven patches of this series change compared
> to what I have queued?
No
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCHv2 00/30] Xorg related changes
From: Richard Purdie @ 2011-10-04 10:23 UTC (permalink / raw)
To: Martin Jansa; +Cc: openembedded-core
In-Reply-To: <cover.1317648040.git.Martin.Jansa@gmail.com>
On Mon, 2011-10-03 at 15:28 +0200, Martin Jansa wrote:
> this patchset brings meta-oe and oe-core xorg stuff together and most of
> xorg recipes will be removed from meta-oe (sending another pull request now).
Did anything in the first seven patches of this series change compared
to what I have queued?
Cheers,
Richard
^ permalink raw reply
* Re: [PATCHv2 04/30] xf86-video-omapfb: bump SRCREV and add patch from meta-oe
From: Phil Blundell @ 2011-10-04 9:43 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111004072817.GB19366@jama.jama.net>
On Tue, 2011-10-04 at 09:28 +0200, Martin Jansa wrote:
> On Mon, Oct 03, 2011 at 05:00:35PM +0100, Phil Blundell wrote:
> > And, finally, if this is an OMAP-specific driver, why is it in oe-core
> > in the first place? I would have thought it would be better placed in
> > meta-ti or some such layer.
>
> We've discussed it on oe-devel ML already
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-September/034781.html
Is it testable in oe-core? If not then I don't think it belongs there.
p.
^ permalink raw reply
* Re: [PATCHv2 04/30] xf86-video-omapfb: bump SRCREV and add patch from meta-oe
From: Martin Jansa @ 2011-10-04 7:28 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317657635.13337.10.camel@phil-desktop>
[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]
On Mon, Oct 03, 2011 at 05:00:35PM +0100, Phil Blundell wrote:
> On Mon, 2011-10-03 at 15:28 +0200, Martin Jansa wrote:
> > From: Martin Jansa <martin.jansa@gmail.com>
> >
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
Sorry about 3 SOB lines... it's because I had it from
oe-core/master-next, but I belive RP will merge master-next first where
it's only with his and mine SOB.
> This is a bit of a lame checkin message. "Add patch from meta-oe"
> doesn't really say anything useful about what you're changing, and there
> is no long comment at all. Also ...
Rotation didn't work when using VFRB, this patch is fixing that and is from
koen upstream repo as patch header says and I cannot probably describe it
better then original author.
> >@@ -1,25 +1,25 @@
> >-require xorg-driver-driver.inc
> >+require xorg-driver-video.inc
> >
> > SUMMARY = "X.Org X server -- Texas Instruments OMAP framebuffer driver"
> >
> > DESCRIPTION = "omapfb driver supports the basic Texas Instruments OMAP \
> > framebuffer."
> >
> >-LICENSE = "MIT-X"
> >-LIC_FILES_CHKSUM = "file://src/omapfb-driver.c;beginline=1;endline=30;md5=a44c2a37e04d1c2c5f0313afb493f833"
> >+LICENSE = "MIT-X & GPLv2+"
> >+LIC_FILES_CHKSUM = "file://COPYING;md5=63e2cbac53863f60e2f43343fb34367f"
> > DEPENDS += "virtual/libx11"
>
> ... these changes don't seem to be covered by the description above.
because COPYING file wasn't available in SRCREV used in old oe-core
version.. so this change is just simplification and improving license
metadata, because original MIT-X src/omapfb-driver.c doesn't cover what
was explained in COPYING file:
The src/omapfb.h header is under the GPL license.
> And, finally, if this is an OMAP-specific driver, why is it in oe-core
> in the first place? I would have thought it would be better placed in
> meta-ti or some such layer.
We've discussed it on oe-devel ML already
http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-September/034781.html
now we have very similar recipes in oe-core and meta-oe which is imho
worst case.. I'm fine with dropping it from oe-core and keeping it in
meta-oe, but I would prefer to keep it in meta-oe ie because
nokia900.conf is maintained in meta-smartphone layer and I don't want to
add meta-ti as dependency just because this one recipe.
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCH 02/13] xserver-xf86-dri-lite: remove COMPATIBLE_HOST
From: Martin Jansa @ 2011-10-04 7:11 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E8A169A.5080207@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]
On Mon, Oct 03, 2011 at 01:10:02PM -0700, Khem Raj wrote:
> On 9/30/2011 12:27 AM, Martin Jansa wrote:
> > * ie om-gta02 has mesa-dri module too
> >
> > Signed-off-by: Martin Jansa<Martin.Jansa@gmail.com>
> > ---
> > .../xorg-xserver/xserver-xf86-dri-lite.inc | 3 ---
> > 1 files changed, 0 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
> > index 093e049..2e35917 100644
> > --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
> > +++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
> > @@ -10,6 +10,3 @@ EXTRA_OECONF += "\
> > --with-pic \
> > --with-int10=x86emu \
> > "
> > -
> > -# Due to mesa-dri
> > -COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'
>
> how about powerpc and mips ? they will also become supported with this
> change have you tested that
Haven't tested it but iirc building dri extension worked even for
powerpc and mips in OE-classic and because xserver-xf86-dri-lite get's
default later in this patchset I think it's better without
overrestrictive COMPATIBLE_HOST.
And as the comment says, the restriction should be in mesa-dri if
somewhere (at least only in one place to .bbappend my COMPATIBLE_HOSTs
in layer).
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [PATCH] qt4-embedded: move qt4-embedded-conf from RDEPENDS to RRECOMMENDS
From: James Limbouris @ 2011-10-04 1:42 UTC (permalink / raw)
To: openembedded-core
qt4-embedded-conf contains an environment setup script for profile.d.
It has been packaged seperately to allow for its exclusion, but this is
only practical if it is added to RRECOMMENDS, rather than RDEPENDS.
Signed-off-by: James Limbouris <james@digitalmatter.com.au>
---
meta/recipes-qt/qt4/qt4-embedded.inc | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-qt/qt4/qt4-embedded.inc b/meta/recipes-qt/qt4/qt4-embedded.inc
index ed872b0..c04c49c 100644
--- a/meta/recipes-qt/qt4/qt4-embedded.inc
+++ b/meta/recipes-qt/qt4/qt4-embedded.inc
@@ -3,7 +3,7 @@ SECTION = "libs"
LICENSE = "LGPLv2.1 | GPLv3"
HOMEPAGE = "http://qt.nokia.com"
DEPENDS += "directfb tslib"
-INC_PR = "r32"
+INC_PR = "r33"
QT_BASE_NAME ?= "qt4-embedded"
QT_BASE_LIB ?= "libqt-embedded"
@@ -31,7 +31,7 @@ do_install_append() {
# with depending on the global package qt4-embedded
PACKAGES += " ${PN}-conf"
FILES_${PN}-conf += " ${sysconfdir}/profile.d/qte.sh"
-RDEPENDS_${PN} += " ${PN}-conf"
+RRECOMMENDS_${PN} += " ${PN}-conf"
inherit qt4e
--
1.7.3.4
^ permalink raw reply related
* Re: [RFC] Fix typo in meta/classes/sanity.bbclass
From: McClintock Matthew-B29882 @ 2011-10-03 23:48 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
In-Reply-To: <1317685187-9041-1-git-send-email-msm@freescale.com>
On Mon, Oct 3, 2011 at 6:39 PM, Matthew McClintock <msm@freescale.com> wrote:
> Signed-off-by: Matthew McClintock <msm@freescale.com>
Whoops =)
> ---
> Not sure if this is correct but it looks like a typo, also
> there appears to be some issues with the fix as well
>
> meta/classes/sanity.bbclass | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index 4067408..cf30927 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -169,7 +169,7 @@ def check_sanity_validmachine(e):
> messages = messages + 'TUNE_ARCH is unset. Please ensure your MACHINE configuration includes a valid tune configuration file which will set this correctly.\n'
>
> # Check TARGET_ARCH is set correctly
> - if data.getVar('TARGE_ARCH', e.data, False) == '${TUNE_ARCH}':
> + if data.getVar('TARGET_ARCH', e.data, False) == '${TUNE_ARCH}':
> messages = messages + 'TARGET_ARCH is being overwritten, likely by your MACHINE configuration files.\nPlease use a valid tune configuration file which should set this correctly automatically\nand avoid setting this in the machine configuration. See the OE-Core mailing list for more information.\n'
>
> # Check TARGET_OS is set
After fixing this I see the following:
ERROR: Poky's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the
checker (see sanity.conf).
Following is the list of potential problems / advisories:
TARGET_ARCH is being overwritten, likely by your MACHINE
configuration files.
Please use a valid tune configuration file which should set this
correctly automatically
and avoid setting this in the machine configuration. See the OE-Core
mailing list for more information.
ERROR: Execution of event handler 'check_sanity_eventhandler' failed
-M
^ permalink raw reply
* [RFC] Fix typo in meta/classes/sanity.bbclass
From: Matthew McClintock @ 2011-10-03 23:39 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
Not sure if this is correct but it looks like a typo, also
there appears to be some issues with the fix as well
meta/classes/sanity.bbclass | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 4067408..cf30927 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -169,7 +169,7 @@ def check_sanity_validmachine(e):
messages = messages + 'TUNE_ARCH is unset. Please ensure your MACHINE configuration includes a valid tune configuration file which will set this correctly.\n'
# Check TARGET_ARCH is set correctly
- if data.getVar('TARGE_ARCH', e.data, False) == '${TUNE_ARCH}':
+ if data.getVar('TARGET_ARCH', e.data, False) == '${TUNE_ARCH}':
messages = messages + 'TARGET_ARCH is being overwritten, likely by your MACHINE configuration files.\nPlease use a valid tune configuration file which should set this correctly automatically\nand avoid setting this in the machine configuration. See the OE-Core mailing list for more information.\n'
# Check TARGET_OS is set
--
1.7.6.1
^ permalink raw reply related
* Re: sstate_clean() overzealous?
From: McClintock Matthew-B29882 @ 2011-10-03 22:08 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: McClintock Matthew-B29882
In-Reply-To: <CAEsOVNekGoGvTPOJKj1a+FDrYT-mWvF-T5AdcjQMEP6diDZhQQ@mail.gmail.com>
On Mon, Oct 3, 2011 at 4:29 PM, Matthew McClintock <msm@freescale.com> wrote:
> On Mon, Oct 3, 2011 at 4:24 PM, Saul Wold <saul.wold@intel.com> wrote:
>> I am not sure that's correct, since we use sstate with the Autobuilder and
>> it's shared across different hosts building different MACHINEs, we don't see
>> the -natives getting build, do you have any examples?
>
> I'm building with targets that are not upstream, so I can't comment on
> the upstream variant. There are different TUNES though. I'm actually
> currently in the process of looking at why sstate-cache is not being
> reused.
>
> Can you point at the autobuilder stuff? Is it going from
> fsl-mpc8315e-rdb to and x86_64 target? Or between two x86_64 targets?
For example autoconf-native:
$ bitbake-diffsigs
../sstate-cache/sstate-autoconf-native-x86_64-linux-2.68-r2-x86_64-2-*siginfo
[mattsm@right build_p5020ds_release (master *$)]$ bitbake-diffsigs
../sstate-cache/sstate-autoconf-native-x86_64-linux-2.68-r2-x86_64-2-*siginfo
[snip]
basehash changed from bab02dfa833aca4810b0fae8c4ab48f9 to
e156f3fb86236bfc0262e6287bd73784
List of dependencies for variable baselib changed from
set(['BASELIB']) to set(['DEFAULTTUNE'])
Dependency on variable BASELIB was added
Dependency on Variable DEFAULTTUNE was removed
Variable baselib value changed from ${BASELIB} to
${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) or
'INVALID'), True) or 'lib'}
Hash for dependent task
virtual:native:/local/home/mattsm/git/poky/meta/recipes-devtools/autoconf/autoconf_2.68.bb.do_install
changed from e74616029727b6e61b00273425128f1d to
478e7900a2310f2669708e6909883865
Back tracking this appears to be a multilib issue since I have that
enabled on one of the -native packages:
../meta/conf/bitbake.conf:baselib = "${BASELIB}"
../meta/conf/multilib.conf:baselib = "${@d.getVar('BASE_LIB_tune-' +
(d.getVar('DEFAULTTUNE', True) or 'INVALID'), True) or 'lib'}"
Which causes the other differences....
-M
^ permalink raw reply
* Re: MINUTES: OE-TSC meeting 29-Sep-2011
From: Chris Larson @ 2011-10-03 21:56 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E8A2EF4.2090906@linux.intel.com>
On Mon, Oct 3, 2011 at 2:53 PM, Saul Wold <sgw@linux.intel.com> wrote:
> On 09/30/2011 11:16 AM, Chris Larson wrote:
>>
>> On Fri, Sep 30, 2011 at 11:14 AM, Jeff Osier-Mixon<jefro@jefro.net>
>> wrote:
>>>
>>> 1. Jefro
>>> 2. a. some minutes not making it to mailing list, Jefro to post on wiki
>>> b. yocto evaluating gerrit, possible patchwork replacement for OE,
>>> khem
>>> will research
>>
>> ReviewBoard may be worth looking at as an alternative to gerritt, as well.
>
> Not sure what kind of support it has for GIT, gerrit has git support which
> is why we want to evaluate it.
They both support git. I wouldn't have suggested evaluating anything
that didn't.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* Re: MINUTES: OE-TSC meeting 29-Sep-2011
From: Saul Wold @ 2011-10-03 21:53 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <CABcZANk1DnADdN2F39QYOOM--KyJkxbguhQ0GPmv9BFeEPG_oA@mail.gmail.com>
On 09/30/2011 11:16 AM, Chris Larson wrote:
> On Fri, Sep 30, 2011 at 11:14 AM, Jeff Osier-Mixon<jefro@jefro.net> wrote:
>> 1. Jefro
>> 2. a. some minutes not making it to mailing list, Jefro to post on wiki
>> b. yocto evaluating gerrit, possible patchwork replacement for OE, khem
>> will research
>
> ReviewBoard may be worth looking at as an alternative to gerritt, as well.
Not sure what kind of support it has for GIT, gerrit has git support
which is why we want to evaluate it.
Sau!
^ permalink raw reply
* Re: [PATCH] populate_sdk_rpm: Add missing /bin/sh from rpm ignore list for the SDK
From: McClintock Matthew-B29882 @ 2011-10-03 21:40 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317420972.4454.1.camel@ted>
On Fri, Sep 30, 2011 at 5:16 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> The target SDK packages don't need to fulfil a shell dependency
> so add /bin/sh to the list of packages we don't need to resolve.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Acked-by: Matthew McClintock <msm@freescale.com>
^ permalink raw reply
* Re: sstate_clean() overzealous?
From: McClintock Matthew-B29882 @ 2011-10-03 21:22 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: McClintock Matthew-B29882
In-Reply-To: <4E8A26AD.3060101@gmail.com>
On Mon, Oct 3, 2011 at 4:18 PM, Khem Raj <raj.khem@gmail.com> wrote:
> hmmm so we can not share sstate parts for two machines in same tmpdir ?
I'm not 100% sure I'm doing things properly but this is what I did:
$ bitbake pseudo-native
$ cp sstate-cache/* ~/sstate-cache
$ rm -rf tmp/
$ bitbake pseudo-native
Now sstate-cache is verified to be working.... then I changed machines and ran
$ cp ~/sstate-cache/* sstate-cache/
$ bitbake pseudo-native
bitbake starts rebuilding everything, and added -DDD I see SState
cache is missing.
-M
^ permalink raw reply
* Re: sstate_clean() overzealous?
From: McClintock Matthew-B29882 @ 2011-10-03 21:30 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: McClintock Matthew-B29882
In-Reply-To: <4E8A2828.7090202@intel.com>
On Mon, Oct 3, 2011 at 4:24 PM, Saul Wold <saul.wold@intel.com> wrote:
> I am not sure that's correct, since we use sstate with the Autobuilder and
> it's shared across different hosts building different MACHINEs, we don't see
> the -natives getting build, do you have any examples?
I'm building with targets that are not upstream, so I can't comment on
the upstream variant. There are different TUNES though. I'm actually
currently in the process of looking at why sstate-cache is not being
reused.
Can you point at the autobuilder stuff? Is it going from
fsl-mpc8315e-rdb to and x86_64 target? Or between two x86_64 targets?
-M
^ permalink raw reply
* Re: sstate_clean() overzealous?
From: Saul Wold @ 2011-10-03 21:24 UTC (permalink / raw)
To: McClintock Matthew-B29882,
Patches and discussions about the oe-core layer
In-Reply-To: <CAEsOVNcZbs3TBQiBYnpzk4UgbfSwFYNHfkChhjN3FOcjnp4qUw@mail.gmail.com>
On 10/03/2011 02:11 PM, McClintock Matthew-B29882 wrote:
> On Mon, Oct 3, 2011 at 11:47 AM, Phil Blundell<philb@gnu.org> wrote:
>> The sstate_clean() function in sstate.bbclass is doing (inter alia):
>>
>> stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
>> [...]
>> oe.path.remove(stfile + ".*")
>> oe.path.remove(stfile + "_setscene" + ".*")
>>
>> which means that, for tasks which set the stamp-extra-info flag to
>> ${MACHINE}, it ends up blowing away the stamps for all machines rather
>> than just the current one. The net effect of this seems to be that
>> there is no way to have the setscene stamps populated for more than one
>> MACHINE at any time, and hence all those tasks get rerun every time you
>> change MACHINE even if nothing else has been altered.
>>
>> Is this behaviour deliberate? It is certainly a little bit annoying but
>> I don't understand the internals of sstate well enough to judge what
>> exactly that glob is trying to accomplish.
>
> I've noticed that changing the MACHINE will also invalidate the
> -native stuff as well.
>
I am not sure that's correct, since we use sstate with the Autobuilder
and it's shared across different hosts building different MACHINEs, we
don't see the -natives getting build, do you have any examples?
Sau!
> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: sstate_clean() overzealous?
From: Khem Raj @ 2011-10-03 21:18 UTC (permalink / raw)
To: McClintock Matthew-B29882,
Patches and discussions about the oe-core layer
In-Reply-To: <CAEsOVNcZbs3TBQiBYnpzk4UgbfSwFYNHfkChhjN3FOcjnp4qUw@mail.gmail.com>
On 10/3/2011 2:11 PM, McClintock Matthew-B29882 wrote:
> On Mon, Oct 3, 2011 at 11:47 AM, Phil Blundell<philb@gnu.org> wrote:
>> The sstate_clean() function in sstate.bbclass is doing (inter alia):
>>
>> stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
>> [...]
>> oe.path.remove(stfile + ".*")
>> oe.path.remove(stfile + "_setscene" + ".*")
>>
>> which means that, for tasks which set the stamp-extra-info flag to
>> ${MACHINE}, it ends up blowing away the stamps for all machines rather
>> than just the current one. The net effect of this seems to be that
>> there is no way to have the setscene stamps populated for more than one
>> MACHINE at any time, and hence all those tasks get rerun every time you
>> change MACHINE even if nothing else has been altered.
>>
>> Is this behaviour deliberate? It is certainly a little bit annoying but
>> I don't understand the internals of sstate well enough to judge what
>> exactly that glob is trying to accomplish.
>
> I've noticed that changing the MACHINE will also invalidate the
> -native stuff as well.
hmmm so we can not share sstate parts for two machines in same tmpdir ?
>
> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox