Re: [oe] [PATCH] pm-qa-utils: Add power management test utils
Sincerely,
Chase Maupin
Integration Team Manager
Linux Core Product Development
e-mail: chase.mau...@ti.com
phone: (214) 567-2950
For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/
>-Original Message-
>From: openembedded-devel-boun...@lists.openembedded.org
>[mailto:openembedded-devel-boun...@lists.openembedded.org] On
>Behalf Of Koen Kooi
>Sent: Friday, March 21, 2014 4:10 AM
>To: openembedded-devel@lists.openembedded.org
>Subject: Re: [oe] [PATCH] pm-qa-utils: Add power management test
>utils
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Chase Maupin schreef op 20-03-14 15:47:
>> * The power management test utilities from Linaro can be used to
>test
>> multiple PM features such as cpufreq, cpuidle, thermal control
>and
>> suspend operations. * These utilities are not platform specific
>and can
>> be used by a broader base of users.
>>
>> Signed-off-by: Chase Maupin
>
>Everything refers to this as 'pm-qa', not 'pm-qa-utils'
I assume you are saying you would rather see this recipe as pm-qa instead of
pm-qa-utils?
>
>> --- .../pm-qa-utils/pm-qa-utils_git.bb | 63
>> 1 file changed, 63 insertions(+) create
>mode 100644
>> meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb
>>
>> diff --git a/meta-oe/recipes-devtools/pm-qa-utils/pm-qa-
>utils_git.bb
>> b/meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb new
>file mode
>> 100644 index 000..610f3a7 --- /dev/null +++
>> b/meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb @@ -
>0,0 +1,63
>> @@ +DESCRIPTION = "Utilities from Linaro for testing Power
>Management"
>> +HOMEPAGE =
>>
>"https://wiki.linaro.org/WorkingGroups/PowerManagement/Resources/T
>estSuite/PmQa"
>>
>>
>+
>> +LICENSE = "GPLv2" +LIC_FILES_CHKSUM =
>> "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263" + +PV =
>"0.4.4" +
>> +BRANCH ?= "master" +SRCREV =
>"fbc2762359b863dfbf4fd0bab1e8abd2a6125ed4"
>> + +SRC_URI =
>> "git://git.linaro.org/tools/pm-
>qa.git;protocol=git;branch=${BRANCH}" + +S
>> = "${WORKDIR}/git" + +CFLAGS += "-pthread" + +do_compile () { +
># Find
>> all the .c files in this project and build them. +for x in
>`find .
>> -name "*.c"` +do +util=`echo ${x} | sed s/.c$//` +
>> oe_runmake ${util} +done +} + +do_install () { +install
>-d
>> ${D}${bindir} +install -d ${D}${bindir}/linaro-pm-qa-include
>
>Please don't use subdirs in $bindir, that's what $libdir and
>$libexecdir are
>for.
Good point. I did this because the script going into that directory was named
"functions.sh" in the original sources. I thought this was a bit generic and
could possibly conflict.
What are your thoughts on a subdirectory under $libdir or $libexecdir? Any
preference?
>
>> + +# Install the compiled binaries the were built in the
>previous
>> step +for x in `find . -name "*.c"` +do +
>util=`echo ${x}
>> | sed s/.c$//` +util_basename=`basename ${util}` +
>install
>> -m 0755 ${util} ${D}${bindir}/${util_basename} +done + +
># Install
>> the helper scripts in the include directory +for script in
>`find .
>> -name "*.sh" | grep include` +do +# Remove hardcoded
>relative
>> paths +sed -i -e 's#..\/utils\/##' ${script} + +
>> script_basename=`basename ${script}` +install -m 0755
>$script
>> ${D}${bindir}/linaro-pm-qa-include/${script_basename} +done
>+ +#
>> Install the shell scripts NOT in the include directory since
>those +#
>> will be installed elsewhere +for script in `find . -name
>"*.sh" |
>> grep -v include` +do +# if the script includes any
>helper
>> scripts from the include +# directory then change the
>include
>> path to the absolute path +# to reflect the install
>location of
>> the helper scripts. +sed -i -e "s#source
>../include#source
>> ${bindir}/linaro-pm-qa-include#g" ${script} +# Remove
>hardcoded
>> relative paths +sed -i -e 's#..\/utils\/##' ${script} +
>+
>> script_basename=`basename ${script}` +install -m 0755
>$script
>> ${D}${bindir}/${script_basename} +done +}
>>
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.4.5 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>
>iD8DBQFTLAHbMkyGM64RGpERAp4tAKCqvpUtLAnW+JmNPFue3devsMkfEgCfSBG8
>sTfb/tlOntd8/Hs/1JvXqQ4=
>=674M
>-END PGP SIGNATURE-
>
>--
>___
>Openembedded-devel mailing list
>Openembedded-devel@lists.openembedded.org
>http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] pm-qa-utils: Add power management test utils
>-Original Message-
>From: openembedded-devel-boun...@lists.openembedded.org
>[mailto:openembedded-devel-boun...@lists.openembedded.org] On
>Behalf Of Koen Kooi
>Sent: Friday, March 21, 2014 7:11 AM
>To: openembedded-devel@lists.openembedded.org
>Subject: Re: [oe] [PATCH] pm-qa-utils: Add power management test
>utils
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Maupin, Chase schreef op 21-03-14 13:07:
>
>>> -Original Message- From:
>>> openembedded-devel-boun...@lists.openembedded.org
>>> [mailto:openembedded-devel-boun...@lists.openembedded.org] On
>Behalf Of
>>> Koen Kooi Sent: Friday, March 21, 2014 4:10 AM To:
>>> openembedded-devel@lists.openembedded.org Subject: Re: [oe]
>[PATCH]
>>> pm-qa-utils: Add power management test utils
>>>
>> Chase Maupin schreef op 20-03-14 15:47:
>>>>> * The power management test utilities from Linaro can be used
>to
>> test
>>>>> multiple PM features such as cpufreq, cpuidle, thermal
>control
>> and
>>>>> suspend operations. * These utilities are not platform
>specific
>> and can
>>>>> be used by a broader base of users.
>>>>>
>>>>> Signed-off-by: Chase Maupin
>>
>> Everything refers to this as 'pm-qa', not 'pm-qa-utils'
>>
>>> I assume you are saying you would rather see this recipe as pm-
>qa
>>> instead of pm-qa-utils?
>
>Exactly!
>
>>
>>
>>>>> --- .../pm-qa-utils/pm-qa-utils_git.bb | 63
>>>>> 1 file changed, 63 insertions(+) create
>> mode 100644
>>>>> meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb
>>>>>
>>>>> diff --git a/meta-oe/recipes-devtools/pm-qa-utils/pm-qa-
>> utils_git.bb
>>>>> b/meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb new
>> file mode
>>>>> 100644 index 000..610f3a7 --- /dev/null +++
>>>>> b/meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb @@
>-
>> 0,0 +1,63
>>>>> @@ +DESCRIPTION = "Utilities from Linaro for testing Power
>> Management"
>>>>> +HOMEPAGE =
>>>>>
>>
>"https://wiki.linaro.org/WorkingGroups/PowerManagement/Resources/T
>> estSuite/PmQa"
>>>>>
>>>>>
>> +
>>>>> +LICENSE = "GPLv2" +LIC_FILES_CHKSUM =
>>>>> "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263" + +PV =
>> "0.4.4" +
>>>>> +BRANCH ?= "master" +SRCREV =
>> "fbc2762359b863dfbf4fd0bab1e8abd2a6125ed4"
>>>>> + +SRC_URI = "git://git.linaro.org/tools/pm-
>> qa.git;protocol=git;branch=${BRANCH}" + +S
>>>>> = "${WORKDIR}/git" + +CFLAGS += "-pthread" + +do_compile () {
>+
>> # Find
>>>>> all the .c files in this project and build them. +for x
>in
>> `find .
>>>>> -name "*.c"` +do +util=`echo ${x} | sed s/.c$//`
>+
>>>>> oe_runmake ${util} +done +} + +do_install () { +
>install
>> -d
>>>>> ${D}${bindir} +install -d ${D}${bindir}/linaro-pm-qa-
>include
>>
>> Please don't use subdirs in $bindir, that's what $libdir and
>$libexecdir
>> are for.
>>
>>> Good point. I did this because the script going into that
>directory
>>> was named "functions.sh" in the original sources. I thought
>this was a
>>> bit generic and could possibly conflict.
>>
>>> What are your thoughts on a subdirectory under $libdir or
>$libexecdir?
>>> Any preference?
>
>Right it will amount to the basically the same due to the
>misguided
>libexecdir change oe-core did last year. If it's only used
>'internally'
>$libdir/PN would be OK, otherwise use libexecdir (which currently
>is
>libdir/PN, but might change again)
One last dense question. What do you mean by 'internally'?
Internally to just this package as in you don't expect any sharing between this
and another package?
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.4.5 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>
>iD8DBQFTLCxQMkyGM64RGpERAi53AJ9bjuFeJfliwQV9hzHnqd+28zkH0ACeLS9r
>VXYU8eXR2dQcBS74EnzVBd4=
>=DHAP
>-END PGP SIGNATURE-
>
>--
>___
>Openembedded-devel mailing list
>Openembedded-devel@lists.openembedded.org
>http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] pm-qa-utils: Add power management test utils
From: Fathi Boudra [mailto:fathi.bou...@linaro.org]
Sent: Thursday, March 20, 2014 11:45 AM
To: openembedded-devel@lists.openembedded.org
Cc: Maupin, Chase
Subject: Re: [oe] [PATCH] pm-qa-utils: Add power management test utils
On 20 March 2014 16:47, Chase Maupin
mailto:chase.mau...@ti.com>> wrote:
* The power management test utilities from Linaro can be used
to test multiple PM features such as cpufreq, cpuidle, thermal
control and suspend operations.
* These utilities are not platform specific and can be used by
a broader base of users.
Signed-off-by: Chase Maupin mailto:chase.mau...@ti.com>>
---
.../pm-qa-utils/pm-qa-utils_git.bb<http://pm-qa-utils_git.bb>
| 63
1 file changed, 63 insertions(+)
create mode 100644
meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb<http://pm-qa-utils_git.bb>
diff --git
a/meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb<http://pm-qa-utils_git.bb>
b/meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb<http://pm-qa-utils_git.bb>
new file mode 100644
index 000..610f3a7
--- /dev/null
+++
b/meta-oe/recipes-devtools/pm-qa-utils/pm-qa-utils_git.bb<http://pm-qa-utils_git.bb>
@@ -0,0 +1,63 @@
+DESCRIPTION = "Utilities from Linaro for testing Power Management"
nitpick, I'll remove "from Linaro" :)
[CEM] I have another version I need to send so I’ll take care of this.
+HOMEPAGE =
"https://wiki.linaro.org/WorkingGroups/PowerManagement/Resources/TestSuite/PmQa";
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM =
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+
+PV = "0.4.4"
we released 0.4.8 today.
[CEM] I’ll go ahead and bump this
+BRANCH ?= "master"
+SRCREV = "fbc2762359b863dfbf4fd0bab1e8abd2a6125ed4"
+
+SRC_URI =
"git://git.linaro.org/tools/pm-qa.git;protocol=git;branch=${BRANCH}<http://git.linaro.org/tools/pm-qa.git;protocol=git;branch=$%7BBRANCH%7D>"
+
+S = "${WORKDIR}/git"
+
+CFLAGS += "-pthread"
+
+do_compile () {
+# Find all the .c files in this project and build them.
+for x in `find . -name "*.c"`
+do
+util=`echo ${x} | sed s/.c$//`
+oe_runmake ${util}
+done
+}
+
+do_install () {
+install -d ${D}${bindir}
+install -d ${D}${bindir}/linaro-pm-qa-include
+
+# Install the compiled binaries the were built in the previous step
+for x in `find . -name "*.c"`
+do
+util=`echo ${x} | sed s/.c$//`
+util_basename=`basename ${util}`
+install -m 0755 ${util} ${D}${bindir}/${util_basename}
+done
+
+# Install the helper scripts in the include directory
+for script in `find . -name "*.sh" | grep include`
+do
+# Remove hardcoded relative paths
+sed -i -e 's#..\/utils\/##' ${script}
+
+script_basename=`basename ${script}`
+install -m 0755 $script
${D}${bindir}/linaro-pm-qa-include/${script_basename}
+done
+
+# Install the shell scripts NOT in the include directory since those
+# will be installed elsewhere
+for script in `find . -name "*.sh" | grep -v include`
+do
+# if the script includes any helper scripts from the include
+# directory then change the include path to the absolute path
+# to reflect the install location of the helper scripts.
+sed -i -e "s#source ../include#source
${bindir}/linaro-pm-qa-include#g" ${script}
+# Remove hardcoded relative paths
+sed -i -e 's#..\/utils\/##' ${script}
+
+script_basename=`basename ${script}`
+install -m 0755 $script ${D}${bindir}/${script_basename}
+done
we probably need to fix that properly and avoid the LTP style mess (software
not meant to be installable).
+}
--
1.7.9.5
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org<mailto:Openembedded-devel@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
FWIW, my comments aren't a blocker/nack. That's something we can address later
on.
Cheers,
Fathi
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH][for-danny] kernel bbclass: return to original directory in do_deploy
Ping on this patch. I did not submit for master since the master branch has
already removed the kernel.bbclass.
> -Original Message-
> From: Maupin, Chase
> Sent: Monday, March 18, 2013 12:50 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: [oe][meta-oe][PATCH][for-danny] kernel bbclass: return
> to original directory in do_deploy
>
> * During the base kernel_do_deploy function the directory is
> changed to DEPLOYDIR in order to do some cleanup and
> symlinking.
> However, the directory is not changed back to the original
> starting directory ${S} at the end. For append functions this
> means that the starting directory is not ${S} as expected but
> instead ${DEPLOYDIR}.
>
> For functions like the do_deploy_append in
> recipes-kernel/linux/linux-dtb.inc there is an assumption that
> you are still in the source directory and not the DEPLOYDIR.
> Without this change the .dtb files are not copied because the
> check for the existence of ${DTS_FILE} which is a relative
> path from the ${S} directory fails. This means that the .dtb
> files are not copied into the deploy directory and subsequently
> the deploy/images directory.
>
> In the log.do_deploy file you will see lines like:
>
> Warning: arch/arm/boot/dts/x.dts is not available!
>
> This fix has also been picked up in the oe-core kernel.bbclass:
>
> http://cgit.openembedded.org/openembedded-
> core/commit/?id=fd5d80ab1a405cb4ef94f2cde25f8c251da490f0
>
> Signed-off-by: Chase Maupin
> ---
> meta-oe/classes/kernel.bbclass |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/meta-oe/classes/kernel.bbclass b/meta-
> oe/classes/kernel.bbclass
> index 25c5f64..a0f67f9 100644
> --- a/meta-oe/classes/kernel.bbclass
> +++ b/meta-oe/classes/kernel.bbclass
> @@ -546,6 +546,7 @@ kernel_do_deploy() {
> ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGETYPE}
>
> cp ${COREBASE}/meta/files/deploydir_readme.txt
> ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
> + cd -
> }
> do_deploy[dirs] = "${DEPLOYDIR} ${B}"
>
> --
> 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH][for-danny] kernel bbclass: return to original directory in do_deploy
Ping again. Is this patch OK for danny?
> -Original Message-
> From: Maupin, Chase
> Sent: Friday, March 22, 2013 8:24 AM
> To: Maupin, Chase; openembedded-devel@lists.openembedded.org
> Subject: RE: [oe][meta-oe][PATCH][for-danny] kernel bbclass:
> return to original directory in do_deploy
>
> Ping on this patch. I did not submit for master since the master
> branch has already removed the kernel.bbclass.
>
>
> > -Original Message-
> > From: Maupin, Chase
> > Sent: Monday, March 18, 2013 12:50 PM
> > To: openembedded-devel@lists.openembedded.org
> > Cc: Maupin, Chase
> > Subject: [oe][meta-oe][PATCH][for-danny] kernel bbclass: return
> > to original directory in do_deploy
> >
> > * During the base kernel_do_deploy function the directory is
> > changed to DEPLOYDIR in order to do some cleanup and
> > symlinking.
> > However, the directory is not changed back to the original
> > starting directory ${S} at the end. For append functions
> this
> > means that the starting directory is not ${S} as expected but
> > instead ${DEPLOYDIR}.
> >
> > For functions like the do_deploy_append in
> > recipes-kernel/linux/linux-dtb.inc there is an assumption
> that
> > you are still in the source directory and not the DEPLOYDIR.
> > Without this change the .dtb files are not copied because the
> > check for the existence of ${DTS_FILE} which is a relative
> > path from the ${S} directory fails. This means that the .dtb
> > files are not copied into the deploy directory and
> subsequently
> > the deploy/images directory.
> >
> > In the log.do_deploy file you will see lines like:
> >
> > Warning: arch/arm/boot/dts/x.dts is not available!
> >
> > This fix has also been picked up in the oe-core
> kernel.bbclass:
> >
> > http://cgit.openembedded.org/openembedded-
> > core/commit/?id=fd5d80ab1a405cb4ef94f2cde25f8c251da490f0
> >
> > Signed-off-by: Chase Maupin
> > ---
> > meta-oe/classes/kernel.bbclass |1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta-oe/classes/kernel.bbclass b/meta-
> > oe/classes/kernel.bbclass
> > index 25c5f64..a0f67f9 100644
> > --- a/meta-oe/classes/kernel.bbclass
> > +++ b/meta-oe/classes/kernel.bbclass
> > @@ -546,6 +546,7 @@ kernel_do_deploy() {
> > ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGETYPE}
> >
> > cp ${COREBASE}/meta/files/deploydir_readme.txt
> > ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
> > + cd -
> > }
> > do_deploy[dirs] = "${DEPLOYDIR} ${B}"
> >
> > --
> > 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH][for-danny] kernel bbclass: return to original directory in do_deploy
> -Original Message- > From: Eric Bénard [mailto:e...@eukrea.com] > Sent: Thursday, March 28, 2013 3:51 PM > To: openembedded-devel@lists.openembedded.org > Cc: Maupin, Chase > Subject: Re: [oe] [meta-oe][PATCH][for-danny] kernel bbclass: > return to original directory in do_deploy > > Le Thu, 28 Mar 2013 19:18:52 +, > "Maupin, Chase" a écrit : > > > Ping again. Is this patch OK for danny? > > > pushed to danny-next. Thanks Eric > > Eric ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 12/69] atk: Update LICENSE field version
> -Original Message-
> From: Flanagan, Elizabeth [mailto:elizabeth.flana...@intel.com]
> Sent: Monday, May 14, 2012 12:30 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: Re: [oe] [PATCH 12/69] atk: Update LICENSE field version
>
> On Mon, May 14, 2012 at 9:09 AM, Chase Maupin
> wrote:
> > * Update LICENSE field version from generic LGPL to GPLv2+ and
> > LGPLv2+ to reflect the real license version.
> > * This change was based on setting in oe-core as well as code
> > inspection.
> >
> > Signed-off-by: Chase Maupin
> > ---
> > recipes/atk/atk_1.30.0.bb | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/recipes/atk/atk_1.30.0.bb
> b/recipes/atk/atk_1.30.0.bb
> > index b3505bf..23c6685 100644
> > --- a/recipes/atk/atk_1.30.0.bb
> > +++ b/recipes/atk/atk_1.30.0.bb
> > @@ -1,9 +1,9 @@
> > DESCRIPTION = "An accessibility toolkit for GNOME."
> > SECTION = "x11/libs"
> > PRIORITY = "optional"
> > -LICENSE = "LGPL"
> > +LICENSE = "GPLv2+ LGPLv2+"
>
> This should be:
>
> LICENSE = "GPLv2+ & LGPLv2+"
>
> or whatever the operator is (Most likely & or |)
I know that & works in oe-core, but when I use this in oe-classic I get build
errors like:
NOTE: Running task 432 of 513 (ID: 1,
/home/a0271661/projects/arago-4.7/arago-oe-dev/recipes/atk/atk_1.30.0.bb,
do_patch)
ERROR: Function SRC_DISTRIBUTECOMMAND failed
NOTE: Task failed: ('function SRC_DISTRIBUTECOMMAND failed',
'/home/a0271661/projects/arago-4.7/arago-tmp/work/armv7a-arago-linux-gnueabi/atk-1.30.0-r2/temp/log.SRC_DISTRIBUTECOMMAND.27742')
ERROR: Logfile of failure stored in:
/home/a0271661/projects/arago-4.7/arago-tmp/work/armv7a-arago-linux-gnueabi/atk-1.30.0-r2/temp/log.SRC_DISTRIBUTECOMMAND.27742
Log data follows:
|
/home/a0271661/projects/arago-4.7/arago-tmp/work/armv7a-arago-linux-gnueabi/atk-1.30.0-r2/temp/run.SRC_DISTRIBUTECOMMAND.27742:
line 1288: /atk: No such file or directory
| ERROR: Function SRC_DISTRIBUTECOMMAND failed
NOTE: package atk-1.30.0-r2: task do_distribute_sources: Failed
ERROR: TaskFailed event exception, aborting
ERROR: Build of
/home/a0271661/projects/arago-4.7/arago-oe-dev/recipes/atk/atk_1.30.0.bb
do_distribute_sources failed
ERROR: Task 16
(/home/a0271661/projects/arago-4.7/arago-oe-dev/recipes/atk/atk_1.30.0.bb,
do_distribute_sources) failed with exit code 1
The line (1288) that is causing this error looks like:
cd /home/a0271661/projects/arago-4.7/arago-tmp/deploy/glibc/sources/&/atk
SRC_DISTRIBUTECOMMAND
Looking at other recipes I noticed that when they had multiple licenses they
used a space separated list and in the case of an or license option |.
Any input on this would be appreciated. I don't believe / is right because
that would make it look like a path for the classes that use the license.
>
> The license field needs to be ast parsable in order for the
> license
> system to work.
>
> -b
>
> >
> > -PR = "r1"
> > +PR = "r2"
> >
> > inherit gnome
> >
> > --
> > 1.7.0.4
> >
> >
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-
> bin/mailman/listinfo/openembedded-devel
>
>
>
> --
> Elizabeth Flanagan
> Yocto Project
> Build and Release
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [2011.03-maintenance] Pull request 20120514
> -Original Message- > From: Denys Dmytriyenko [mailto:de...@denix.org] > Sent: Monday, May 14, 2012 2:44 PM > To: openembedded-devel@lists.openembedded.org > Cc: Maupin, Chase > Subject: Re: [oe] [2011.03-maintenance] Pull request 20120514 > > On Mon, May 14, 2012 at 01:09:40PM -0500, Chase Maupin wrote: > > Tom, > > > > Please pull the following commits that update the LICENSE field > to > > list the actual license version for licenses like GPL and LGPL. > These > > patches have previously been sent to the list with each patch > identifying > > where it was derived from. I have also submitted patches for > oe-core where > > appropriate. > > > > I'm looking for feedback on how to properly mark a package as > having two > > licenses in oe-classic since "&" causes issues. If these > patches are OK > > then they can be pulled. If there is a better way to mark the > dual licensing > > then I'll update them accordingly. > > As far as I recall, we don't use "&" in oe-classic for dual > licenses. > > > > The following changes since commit > 36a56cbb69cda0c89f478e01183d61c6a66525c9: > > Steffen Sledz (1): > > icedtea6-native-1.7.10: backport S7103224 > > > > are available in the git repository at: > > > > http://arago-project.org/git/projects/arago-oe-amsdk.git > update-licenses > > Also the same in different format: > > Pull URL: git://arago-project.org/git/projects/arago-oe-amsdk.git > Branch: update-licenses > Browse: http://arago-project.org/git/projects/?p=arago-oe- > amsdk.git;a=shortlog;h=refs/heads/update-licenses > > > Acked-by: Denys Dmytriyenko Ping on this pull request. Any issues? > > > > Chase Maupin (69): > > gnutls: update LICENSE setting > > libtasn1: update LICENSE setting > > bonnie: Update LICENSE field version > > canutils: Update LICENSE field version > > debianutils: Update LICENSE field version > > gtk+: Update LICENSE field version for 2.20.1 > > gnome-keyring: Update LICENSE field version > > gnome-vfs: Update LICENSE field version > > hicolor-icon-theme: Update LICENSE field version > > hostap-daemon: Update LICENSE field version > > liba52: Update LICENSE field version > > atk: Update LICENSE field version > > audiofile: Update LICENSE field version > > avahi: Update LICENSE field version > > cairo: Update LICENSE field version > > libcap2: Update LICENSE field version > > libcroco: Update LICENSE field version > > esound: Update LICENSE field version > > faac: Update LICENSE field version > > faad2: Update LICENSE field version > > flac: Update LICENSE field version > > libgcrypt: Update LICENSE field version > > gdbm: Update LICENSE field version > > libgpg-error: Update LICENSE field version > > libical: Update LICENSE field version > > libid3tag: Update LICENSE field version > > libidl: Update LICENSE field version > > libmad: Update LICENSE field version > > libmodplug: Update LICENSE field version > > lame: Update LICENSE field version > > mpeg2dec: Update LICENSE field version > > mysql5: Update LICENSE field version > > libnl: Update LICENSE field version > > libproxy: Update LICENSE field version > > librsvg: Update LICENSE field version > > libsamplerate0: Update LICENSE field version > > schroedinger: Update LICENSE field version > > libsdl: Update LICENSE field version > > libsidplay: Update LICENSE field version > > libsndfile1: Update LICENSE field version > > libsocketcan: Update LICENSE field version > > libsoup-2.4: Update LICENSE field version > > libvisual: Update LICENSE field version > > x264: Update LICENSE field version > > libxv: Update LICENSE field version > > lmbench: Update LICENSE field version > > makedevs: Update LICENSE field version > > nfs-utils: Update LICENSE field version > > orbit2: Update LICENSE field version > > pango: Update LICENSE field version > > shared-mime-info: Update LICENSE field version > > wireless-tools: Update LICENSE field version > > gnome-common: Update LICENSE field version > > cups: Update LICENSE field version > > gnome-mime-data: Update LICENSE field version > > g
Re: [oe] [2011.03-maintenance] Pull request 20120514
> -Original Message- > From: Paul Menzel [mailto:paulepan...@users.sourceforge.net] > Sent: Saturday, May 19, 2012 3:59 AM > To: openembedded-devel@lists.openembedded.org > Cc: Maupin, Chase > Subject: Re: [oe] [2011.03-maintenance] Pull request 20120514 > > Dear Chase, > > > Am Montag, den 14.05.2012, 13:09 -0500 schrieb Chase Maupin: > > > Please pull the following commits that update the LICENSE field > to > > list the actual license version for licenses like GPL and LGPL. > These > > patches have previously been sent to the list with each patch > > identifying where it was derived from. I have also submitted > patches > > for oe-core where appropriate. > > > > I'm looking for feedback on how to properly mark a package as > having > > two licenses in oe-classic since "&" causes issues. If these > patches > > are OK then they can be pulled. If there is a better way to > mark the > > dual licensing then I'll update them accordingly. > > > > The following changes since commit > 36a56cbb69cda0c89f478e01183d61c6a66525c9: > > Steffen Sledz (1): > > icedtea6-native-1.7.10: backport S7103224 > > > > are available in the git repository at: > > > > http://arago-project.org/git/projects/arago-oe-amsdk.git > > update-licenses > > > > Chase Maupin (69): > > gnutls: update LICENSE setting > > I would have liked to have split those up. Update the license and > add the inherit line. I'll split this up then and regenerate the patch set. > > > libtasn1: update LICENSE setting > > bonnie: Update LICENSE field version > > It would have been great to have the changed license in the > commit message also. > > […] > > > schroedinger: Update LICENSE field version > > A change in `schroedinger.inc` is preferred in my opinion. I didn't change the .inc because I did not validate all versions of schroedinger. > > […] > > > Thanks, > > Paul ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [2011.03-maintenance] Pull request 20120514
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On > Behalf Of Paul Menzel > Sent: Monday, May 21, 2012 9:26 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [2011.03-maintenance] Pull request 20120514 > > Am Montag, den 21.05.2012, 13:53 + schrieb Maupin, Chase: > > > -Original Message- > > > From: Paul Menzel [mailto:paulepan...@users.sourceforge.net] > > > Sent: Saturday, May 19, 2012 3:59 AM > > […] > > > > > Chase Maupin (69): > > > > gnutls: update LICENSE setting > > > > > > I would have liked to have split those up. Update the license > and > > > add the inherit line. > > > > I'll split this up then and regenerate the patch set. > > If that patch set has already been submitted to meta-oe this way, > please do not spent your time doing that. If it is independent > from meta-oe please do so. Already done :) Also updated the license in the commit message (as much as I could fit) > > > > > libtasn1: update LICENSE setting > > > > bonnie: Update LICENSE field version > > > > > > It would have been great to have the changed license in the > commit > > > message also. > > > > > > […] > > > > > > > schroedinger: Update LICENSE field version > > > > > > A change in `schroedinger.inc` is preferred in my opinion. > > > > I didn't change the .inc because I did not validate all > versions of schroedinger. > > Understood. > > > Thanks, > > Paul ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 0/1][for-denzil] kernel: cherry-pick header fix
> -Original Message-
> From: Denys Dmytriyenko [mailto:de...@denix.org]
> Sent: Wednesday, October 10, 2012 4:54 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: Re: [oe] [PATCH 0/1][for-denzil] kernel: cherry-pick
> header fix
>
> On Wed, Oct 10, 2012 at 05:18:38PM -0500, Chase Maupin wrote:
> > All,
> >
> > This patch is a cherry-pick of the change made in meta-
> openembedded
> > master to fix the kernel header staging location. Without this
> > change builds of external modules using the denzil branch will
> fail
> > to find the staged headers because they will be looking in the
> > "kernel" directory instead of the "usr/src/kernel" directory.
> >
> > The STAGING_KERNEL_DIR set in bitbake.conf of oe-core in the
> > denzil branch of the repository has already been updated to use
> > ${STAGING_DIR_HOST}/usr/src/kernel
> >
> > I hope I got this patch formatted right since I just did a
> > cherry-pick into my denzil branch and created the patch. If
> this
> > is not the correct format please let me know. The commit I
> > cherry-picked was 8c724c4ab8e946763c813e5174dbfd5ac8a5ddda
> >
> > Darren Hart (1):
> > kernel: Add kernel headers to kernel-dev package
> >
> > meta-oe/classes/kernel.bbclass | 27
> ---
> > 1 files changed, 12 insertions(+), 15 deletions(-)
>
> FYI, it is already in the queue with other related patches. See
> my earlier
> email.
OK. I haven't seen that message come by yet. I guess it is floating in the
ether :)
>
> --
> Denys
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] libjpeg-turbo: Add RPROVIDES to fix errors when rdepending on jpeg
I did not see any responses to this patch. I am also seeing this issue and was
wondering if there was a reason this patch was not accepted?
If it can be merged can it also be pulled into the denzil branch as well?
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On
> Behalf Of Samuel Stirtzel
> Sent: Friday, August 24, 2012 5:56 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] [meta-oe][PATCH] libjpeg-turbo: Add RPROVIDES to
> fix errors when rdepending on jpeg
>
> This fixes "ERROR: Multiple .bb files are due to be built which
> each provide jpeg"
>
> Signed-off-by: Samuel Stirtzel
> ---
> meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> index dd81606..ec25874 100644
> --- a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> +++ b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> @@ -15,6 +15,7 @@ S = "${WORKDIR}/trunk"
>
> # Drop-in replacement for jpeg
> PROVIDES = "jpeg"
> +RPROVIDES_${PN} = "jpeg"
>
> inherit autotools pkgconfig
>
> --
> 1.7.9.5
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH v2] libjpeg-turbo: Add RPROVIDES to fix errors when rdepending on jpeg
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On
> Behalf Of Samuel Stirtzel
> Sent: Monday, October 22, 2012 4:59 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] [meta-oe][PATCH v2] libjpeg-turbo: Add RPROVIDES to
> fix errors when rdepending on jpeg
>
> This fixes "ERROR: Multiple .bb files are due to be built which
> each provide jpeg"
>
> Signed-off-by: Samuel Stirtzel
> ---
> meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> index 2aefe1f..303bbae 100644
> --- a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> +++ b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> @@ -15,6 +15,9 @@ S = "${WORKDIR}/trunk"
>
> # Drop-in replacement for jpeg
> PROVIDES = "jpeg"
> +RPROVIDES_${PN} += "jpeg"
> +RREPLACES_${PN} += "jpeg"
> +RCONFLICTS_${PN} += "jpeg"
Does this need a PR bump? Aside from that this has my ack.
>
> inherit autotools pkgconfig
>
> --
> 1.7.9.5
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH v2] libjpeg-turbo: Add RPROVIDES to fix errors when rdepending on jpeg
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On
> Behalf Of Martin Jansa
> Sent: Monday, October 22, 2012 8:23 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [meta-oe][PATCH v2] libjpeg-turbo: Add
> RPROVIDES to fix errors when rdepending on jpeg
>
> On Mon, Oct 22, 2012 at 03:20:35PM +0200, Samuel Stirtzel wrote:
> > 2012/10/22 Maupin, Chase :
> > >> -Original Message-
> > >> From: openembedded-devel-boun...@lists.openembedded.org
> > >> [mailto:openembedded-devel-boun...@lists.openembedded.org]
> On
> > >> Behalf Of Samuel Stirtzel
> > >> Sent: Monday, October 22, 2012 4:59 AM
> > >> To: openembedded-devel@lists.openembedded.org
> > >> Subject: [oe] [meta-oe][PATCH v2] libjpeg-turbo: Add
> RPROVIDES to
> > >> fix errors when rdepending on jpeg
> > >>
> > >> This fixes "ERROR: Multiple .bb files are due to be built
> which
> > >> each provide jpeg"
> > >>
> > >> Signed-off-by: Samuel Stirtzel
> > >> ---
> > >> meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb |3 +++
> > >> 1 file changed, 3 insertions(+)
> > >>
> > >> diff --git a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> > >> b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> > >> index 2aefe1f..303bbae 100644
> > >> --- a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> > >> +++ b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> > >> @@ -15,6 +15,9 @@ S = "${WORKDIR}/trunk"
> > >>
> > >> # Drop-in replacement for jpeg
> > >> PROVIDES = "jpeg"
> > >> +RPROVIDES_${PN} += "jpeg"
> > >> +RREPLACES_${PN} += "jpeg"
> > >> +RCONFLICTS_${PN} += "jpeg"
> > >
> > > Does this need a PR bump? Aside from that this has my ack.
> > >
> >
> > The error message disappeared without PR bumps or rebuilding.
> > Hopefully it doesn't need one, as that would trigger a rebuild
> of many
> > recipes (like Qt, gtk+, gtk+3)
>
> It needs one to replace jpeg with libjpeg-turbo on target.
>
> opkg won't replace it without PR bump afaik
And it should not force a rebuild of the other packages I believe.But maybe
this is a new behaviour.
>
> Cheers,
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH v3] libjpeg-turbo: Add RPROVIDES to fix errors when rdepending on jpeg
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On
> Behalf Of Samuel Stirtzel
> Sent: Monday, October 22, 2012 10:13 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] [meta-oe][PATCH v3] libjpeg-turbo: Add RPROVIDES to
> fix errors when rdepending on jpeg
>
> This fixes "ERROR: Multiple .bb files are due to be built which
> each provide jpeg"
>
> Signed-off-by: Samuel Stirtzel
Acked-by: Chase Maupin
> ---
> meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> index 2aefe1f..d87743b 100644
> --- a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> +++ b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
> "file://cdjpeg.h;endline=12;md5=78fa8dbac547bb5b2a0e6457a6cfe
>
> file://djpeg.c;endline=13;md5=e85613b52f2906c5dfc0e21ec902cb33 \
> "
> PV = "8d+1.2.1"
> -PR = "r1"
> +PR = "r2"
> SRCREV = "837"
> SRC_URI = "svn://libjpeg-
> turbo.svn.sourceforge.net/svnroot/libjpeg-
> turbo;protocol=https;module=trunk"
>
> @@ -15,6 +15,9 @@ S = "${WORKDIR}/trunk"
>
> # Drop-in replacement for jpeg
> PROVIDES = "jpeg"
> +RPROVIDES_${PN} += "jpeg"
> +RREPLACES_${PN} += "jpeg"
> +RCONFLICTS_${PN} += "jpeg"
>
> inherit autotools pkgconfig
>
> --
> 1.7.9.5
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH v3] libjpeg-turbo: Add RPROVIDES to fix errors when rdepending on jpeg
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On
> Behalf Of Martin Jansa
> Sent: Monday, October 22, 2012 2:43 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [meta-oe][PATCH v3] libjpeg-turbo: Add
> RPROVIDES to fix errors when rdepending on jpeg
>
> On Mon, Oct 22, 2012 at 07:37:26PM +, Maupin, Chase wrote:
> > > -Original Message-
> > > From: openembedded-devel-boun...@lists.openembedded.org
> > > [mailto:openembedded-devel-boun...@lists.openembedded.org] On
> Behalf
> > > Of Samuel Stirtzel
> > > Sent: Monday, October 22, 2012 10:13 AM
> > > To: openembedded-devel@lists.openembedded.org
> > > Subject: [oe] [meta-oe][PATCH v3] libjpeg-turbo: Add
> RPROVIDES to
> > > fix errors when rdepending on jpeg
> > >
> > > This fixes "ERROR: Multiple .bb files are due to be built
> which each
> > > provide jpeg"
>
> Btw, when I've first noticed this error it was caused by
> task/packagegroup recipe having jpeg in RDEPENDS. It does not
> cause problems when apps are RDEPENDing on jpeg through shlibs
> which is imho better way then pulling jpeg to image through
> task/packagegroup.
>
> But adding this dont hurt either case, so it's fine.
Any issue pulling this into the denzil branch?
>
> Cheers,
>
> > > Signed-off-by: Samuel Stirtzel
> >
> > Acked-by: Chase Maupin
> >
> > > ---
> > > meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb |5 -
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> > > b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> > > index 2aefe1f..d87743b 100644
> > > --- a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> > > +++ b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> > > @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
> > > "file://cdjpeg.h;endline=12;md5=78fa8dbac547bb5b2a0e6457a6cfe
> > >
> > >
> file://djpeg.c;endline=13;md5=e85613b52f2906c5dfc0e21ec902cb33 \
> "
> > > PV = "8d+1.2.1"
> > > -PR = "r1"
> > > +PR = "r2"
> > > SRCREV = "837"
> > > SRC_URI = "svn://libjpeg-
> > > turbo.svn.sourceforge.net/svnroot/libjpeg-
> > > turbo;protocol=https;module=trunk"
> > >
> > > @@ -15,6 +15,9 @@ S = "${WORKDIR}/trunk"
> > >
> > > # Drop-in replacement for jpeg
> > > PROVIDES = "jpeg"
> > > +RPROVIDES_${PN} += "jpeg"
> > > +RREPLACES_${PN} += "jpeg"
> > > +RCONFLICTS_${PN} += "jpeg"
> > >
> > > inherit autotools pkgconfig
> > >
> > > --
> > > 1.7.9.5
> > >
> > >
> > > ___
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-
> bin/mailman/listinfo/openembedded-
> > > devel
> >
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-
> bin/mailman/listinfo/openembedded-devel
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] nodejs: Add patch to compile with GCC 4.3.3
Just FYI, this patch is against the nodejs version in the maintenance branch
and was sent to the list so it could be picked up into Koen's staging tree for
his next pull request. The previously sent version was for the OE dev mainline
and has already been accepted.
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Tuesday, July 19, 2011 7:30 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: [PATCH] nodejs: Add patch to compile with GCC 4.3.3
>
> * Add a patch to nodejs to allow compiling with GCC versions
> less than or equal to 4.3.3.
> * Define the function nodejs_get_gcc_ver to allow applying the
> patch conditionally based on compiler version.
> * Patch based on post at https://github.com/joyent/node/issues/883
>
> Signed-off-by: Chase Maupin
> ---
> ...01-Add-missing-compiler-flags-for-GCC-4.3.patch | 34
>
> recipes/nodejs/nodejs_0.4.0.bb |9 +
> 2 files changed, 43 insertions(+), 0 deletions(-)
> create mode 100644 recipes/nodejs/files/0001-Add-missing-compiler-
> flags-for-GCC-4.3.patch
>
> diff --git a/recipes/nodejs/files/0001-Add-missing-compiler-flags-for-
> GCC-4.3.patch b/recipes/nodejs/files/0001-Add-missing-compiler-flags-
> for-GCC-4.3.patch
> new file mode 100644
> index 000..080b88f
> --- /dev/null
> +++ b/recipes/nodejs/files/0001-Add-missing-compiler-flags-for-GCC-
> 4.3.patch
> @@ -0,0 +1,34 @@
> +From 7cb51ed25b688be08825950ce3f5ce2ad38e3f95 Mon Sep 17 00:00:00 2001
> +From: Chase Maupin
> +Date: Tue, 12 Jul 2011 11:00:48 -0500
> +Subject: [PATCH] Add missing compiler flags for GCC 4.3
> +
> +* When compiling nodejs for GCC 4.3.3 you need to also add the
> + flag -fno-tree-sink.
> +* This patch was taken from the thread at:
> +* https://github.com/joyent/node/issues/883
> +* Believe that no action is taken on this change upstream because
> + it is GCC 4.3.3 specific and is not required for GCC 4.5
> +
> +Upstream-Status: Denied
> +
> +Signed-off-by: Chase Maupin
> +---
> + deps/v8/SConstruct |1 +
> + 1 files changed, 1 insertions(+), 0 deletions(-)
> +
> +diff --git a/deps/v8/SConstruct b/deps/v8/SConstruct
> +index b2542fd..31c4c7b 100644
> +--- a/deps/v8/SConstruct
> b/deps/v8/SConstruct
> +@@ -210,6 +210,7 @@ LIBRARY_FLAGS = {
> + },
> + 'arch:arm': {
> + 'CPPDEFINES': ['V8_TARGET_ARCH_ARM'],
> ++ 'CCFLAGS': ['-fno-tree-sink'],
> + 'unalignedaccesses:on' : {
> + 'CPPDEFINES' : ['CAN_USE_UNALIGNED_ACCESSES=1']
> + },
> +--
> +1.7.0.4
> +
> diff --git a/recipes/nodejs/nodejs_0.4.0.bb
> b/recipes/nodejs/nodejs_0.4.0.bb
> index be3d23e..fe8a878 100644
> --- a/recipes/nodejs/nodejs_0.4.0.bb
> +++ b/recipes/nodejs/nodejs_0.4.0.bb
> @@ -4,11 +4,20 @@ LICENSE = "MIT"
>
> DEPENDS = "openssl"
>
> +PR = "r1"
> +
> +def nodejs_get_gcc_version(d):
> +import subprocess,os,bb
> +if os.path.exists(bb.data.getVar('TOOLCHAIN_PATH', d,
> 1)+'/bin/'+bb.data.getVar('TARGET_PREFIX', d, 1)+'gcc'):
> +return subprocess.Popen([bb.data.getVar('TOOLCHAIN_PATH', d,
> 1)+'/bin/'+bb.data.getVar('TARGET_PREFIX', d, 1)+'gcc', '-v'],
> stderr=subprocess.PIPE).communicate()[1].splitlines()[-1].split()[2]
> +
> SRC_URI = " \
>http://nodejs.org/dist/node-v${PV}.tar.gz \
>file://libev-cross-cc_${PV}.patch \
> "
>
> +SRC_URI += "${@["", "file://0001-Add-missing-compiler-flags-for-GCC-
> 4.3.patch"][nodejs_get_gcc_version(d) <= "4.3.3"]}"
> +
> SRC_URI[md5sum] = "18f89256751f9b8e27dee8494f508171"
> SRC_URI[sha256sum] =
> "4a30bd9963373cb86a994479bdd451ab3b6f2124f0089493366315da79d3408e"
>
> --
> 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] sourceipk: dereference symlinks in sourceipk
Ping. Any objections to this?
Sincerely,
Chase Maupin
Open Platforms
ARM MPU
e-mail: chase.mau...@ti.com
phone: (214) 567-2950
For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/
> -Original Message-
> From: Maupin, Chase
> Sent: Monday, October 10, 2011 2:27 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: [PATCH] sourceipk: dereference symlinks in sourceipk
>
> * Added the -h option to the tar command to make sure that any
> patches that may have been applied by the recipe are actually
> copied instead of made as symlinks to the recipe directory.
> * This is so that people can see the actual patches and unapply
> individual patches as desired.
>
> Signed-off-by: Chase Maupin
> ---
> classes/sourceipk.bbclass |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/classes/sourceipk.bbclass b/classes/sourceipk.bbclass
> index 1b63996..546ec67 100644
> --- a/classes/sourceipk.bbclass
> +++ b/classes/sourceipk.bbclass
> @@ -122,7 +122,7 @@ sourceipk_do_create_srcipk() {
> fi
>
> #Write the data tarball
> -tar -C $tmp_dir --owner=0 --group=0 -czf
> $srcipk_dir/data.tar.gz .
> +tar -C $tmp_dir --owner=0 --group=0 -chzf
> $srcipk_dir/data.tar.gz .
>
> # Create the debian-binary file
> echo "2.0" > $srcipk_dir/debian-binary
> --
> 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] bitbake does not fail when QA issues encountered
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Martyn Welch > Sent: Wednesday, January 26, 2011 4:33 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] bitbake does not fail when QA issues encountered > > On 25/01/11 21:36, Khem Raj wrote: > > On Tue, Jan 25, 2011 at 12:58 PM, Frans Meulenbroeks > > wrote: > >> 2011/1/25 Maupin, Chase : > >>> All, > >>> > >>> I have noticed that when building packages such as perl that while my > build will report success and no errors, the return status from the > bitbake command was "1". I was able to produce this by doing: > >>> > >>> MACHINE=am37x-evm bitbake perl > >>> > >>> After bitbake completed I saw: > >>> > >>> NOTE: Tasks Summary: Attempted 851 tasks of which 0 didn't need to be > rerun and 0 failed. > >>> > >>> but checking $? yields a return status of "1". > >>> > >>> I looked into the log and noticed a lot of messages like: > >>> > >>> ERROR: QA Issue with db: package db contains bad RPATH > >>> > >>> My understanding is that recent fixes to libtool 2.4 prevent these > errors but I am using an older version of Angstrom which pins to libtool > 2.2. I also have found this issue with the Arago distribution which > likewise uses libtool 2.2. > >>> > >>> So my question here is whether bitbake should be failing when it > encounters these QA issues with a bad RPATH and exiting? > >>> > >>> If not then should the return status be "1"? This causes issues when > using a script that issues builds and then checks the return status for > success or failure. If the QA issues are deemed acceptable (or should be > warnings) then I would expect the return status to not indicate a failure. > >>> > >>> I have attached a log of my build for reference > >>> > >>> As another interesting side note which I don't know is related or not, > when building Arago with bitbake 1.10.2 the return status is "1". When > building the same Arago metadata with bitbake 1.8.19 the return status is > "0". What is strange here is that since Arago uses a slightly older > version of the OE metadata it is not seeing the RPATH errors reported > above (the check isn't in the insane.bbclass for Arago yet). So for some > reason bitbake 1.8.19 says everything went fine and bitbake 1.10.2 reports > a status of "1" even though there is no reported error. I'm not sure if > this is related to the above in any way or if this is a separate issue. > >>> > >>> Sincerely, > >>> Chase Maupin > >>> > >> > >> I've seen this on other places as well. > >> I'd say if a package has a QA issue the build of that package should > >> fail, because the resulting output is defnitely not OK. > >> > > > > yes it should fail. However some may raise questions "it used to build > > and not it doesnt" > > so someone has to fix the problems quickly > > > > ...and if it is considered a failure and returns 1, the summary shouldn't > be > reporting "0 failed", or at least there should be something reported at > the > end of the build to state that the build has been deemed a failure for > those > not running in a script and who don't read through the entire log of the > build! Agreed. Just need some consistency here. I'm still curious about why using bitbake version 1.8.19 works and 1.10.2 doesn't but that may be more of an Arago issue than OE since OE requires version 1.10.2 now. What is strange is that in that test case I don't see the QA errors but bitbake 1.10.2 still reports a return status of "1" for some reason with the log not showing any errors or warnings. > > Martyn > > >> Frans > >> > >> ___ > >> Openembedded-devel mailing list > >> Openembedded-devel@lists.openembedded.org > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > >> > > > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > > -- > Martyn Welch (Principal Software Engineer) | Registered in England and > GE Intelligent Platforms | Wales (3828642) at 100 > T +44(0)127322748 | Barbirolli Square, Manchester, > E martyn.we...@ge.com | M2 3AB VAT:GB 927559189 > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] bitbake does not fail when QA issues encountered
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Frans Meulenbroeks > Sent: Saturday, February 05, 2011 7:35 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] bitbake does not fail when QA issues encountered > > 2011/2/4 Otavio Salvador : > > On Fri, Feb 4, 2011 at 15:26, Frans Meulenbroeks > > wrote: > >> The recipes at hand are: > > ... > >> cups: there is someone bitching about that this is 1.2, but he > >> apparently prefers bitching upon resolving the issue. Probably the > >> best solution is to drop the DP = -1 from the 1.4.4 recipe > > ... > > > > I can work on cups next week (I am on VAC right now). > > Actually the cups thing is the one I would feel fairly comfortable with. > The question here is mainly when/how to drop the DP = -1. > A pinning of 1.4.4 is already in my local.conf for quite a while. Frans, Have you already got a patch for version 1.2.12 to fix the desktop file QA errors? If not I was going to work on this because this is breaking my build scripts which check the return status of the build. Chase > > Frans > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] bitbake does not fail when QA issues encountered
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Frans Meulenbroeks > Sent: Saturday, February 05, 2011 7:35 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] bitbake does not fail when QA issues encountered > > 2011/2/4 Otavio Salvador : > > On Fri, Feb 4, 2011 at 15:26, Frans Meulenbroeks > > wrote: > >> The recipes at hand are: > > ... > >> cups: there is someone bitching about that this is 1.2, but he > >> apparently prefers bitching upon resolving the issue. Probably the > >> best solution is to drop the DP = -1 from the 1.4.4 recipe > > ... > > > > I can work on cups next week (I am on VAC right now). > > Actually the cups thing is the one I would feel fairly comfortable with. > The question here is mainly when/how to drop the DP = -1. > A pinning of 1.4.4 is already in my local.conf for quite a while. In fact, as a quick fix applying something like http://bugs.gentoo.org/attachment.cgi?id=164569 should work for version 1.2.12. I ran desktop-file-validate against the cups.desktop file in version 1.4.4 of cups and it has a whole different set of errors: desktop/cups.desktop: error: (will be fatal in the future): value "Printing" in key "Categories" in group "Desktop Entry" requires another category to be present among the following categories: HardwareSettings;Settings desktop/cups.desktop: error: (will be fatal in the future): value "HardwareSettings" in key "Categories" in group "Desktop Entry" requires another category to be present among the following categories: Settings > > Frans > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] u-boot.inc: allow variable make targets
I should have probably clarified that this was intended for the
2011.03-maintenance branch. Tom, I have also submitted this to the oe-core.
Would you be willing to pick this up?
Sincerely,
Chase Maupin
Open Platforms
ARM MPU
e-mail: chase.mau...@ti.com
phone: (214) 567-2950
For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Tuesday, March 15, 2011 9:42 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: [PATCH] u-boot.inc: allow variable make targets
>
> * Later versions of u-boot sometimes have top level make targets
> such as u-boot.imx, u-boot.kwb, and for upcoming TI devices
> u-boot.ti.
> * These targets define different calls to the mkimage tool to
> change the images created, such as changing the load address.
> * This change allows recipes to change the default make target
> of "all" to something like u-boot.ti or u-boot.imx by setting
> the UBOOT_MAKE_TARGET variable.
>
> Signed-off-by: Chase Maupin
> ---
> recipes/u-boot/u-boot.inc |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/recipes/u-boot/u-boot.inc b/recipes/u-boot/u-boot.inc
> index 88c6a4d..ffd1e1e 100644
> --- a/recipes/u-boot/u-boot.inc
> +++ b/recipes/u-boot/u-boot.inc
> @@ -16,6 +16,7 @@ UBOOT_MACHINE ?= "${MACHINE}_config"
> UBOOT_BINARY ?= "u-boot.bin"
> UBOOT_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.bin"
> UBOOT_SYMLINK ?= "u-boot-${MACHINE}.bin"
> +UBOOT_MAKE_TARGET ?= "all"
>
> do_configure () {
> oe_runmake ${UBOOT_MACHINE}
> @@ -25,7 +26,7 @@ do_compile () {
> unset LDFLAGS
> unset CFLAGS
> unset CPPFLAGS
> - oe_runmake all
> + oe_runmake ${UBOOT_MAKE_TARGET}
> oe_runmake tools env HOSTCC="${CC}"
> }
>
> --
> 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] u-boot.inc: allow variable make targets
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Maupin, Chase
> Sent: Tuesday, March 15, 2011 10:16 AM
> To: Chase Maupin; openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCH] u-boot.inc: allow variable make targets
>
> I should have probably clarified that this was intended for the 2011.03-
> maintenance branch. Tom, I have also submitted this to the oe-core.
> Would you be willing to pick this up?
Just FYI this has been merged into the oe-core master (see
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-March/000533.html)
as well as the angstrom-layers master (see
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-March/000512.html)
>
> > -Original Message-
> > From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> > Sent: Tuesday, March 15, 2011 9:42 AM
> > To: openembedded-devel@lists.openembedded.org
> > Cc: Maupin, Chase
> > Subject: [PATCH] u-boot.inc: allow variable make targets
> >
> > * Later versions of u-boot sometimes have top level make targets
> > such as u-boot.imx, u-boot.kwb, and for upcoming TI devices
> > u-boot.ti.
> > * These targets define different calls to the mkimage tool to
> > change the images created, such as changing the load address.
> > * This change allows recipes to change the default make target
> > of "all" to something like u-boot.ti or u-boot.imx by setting
> > the UBOOT_MAKE_TARGET variable.
> >
> > Signed-off-by: Chase Maupin
> > ---
> > recipes/u-boot/u-boot.inc |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/recipes/u-boot/u-boot.inc b/recipes/u-boot/u-boot.inc
> > index 88c6a4d..ffd1e1e 100644
> > --- a/recipes/u-boot/u-boot.inc
> > +++ b/recipes/u-boot/u-boot.inc
> > @@ -16,6 +16,7 @@ UBOOT_MACHINE ?= "${MACHINE}_config"
> > UBOOT_BINARY ?= "u-boot.bin"
> > UBOOT_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.bin"
> > UBOOT_SYMLINK ?= "u-boot-${MACHINE}.bin"
> > +UBOOT_MAKE_TARGET ?= "all"
> >
> > do_configure () {
> > oe_runmake ${UBOOT_MACHINE}
> > @@ -25,7 +26,7 @@ do_compile () {
> > unset LDFLAGS
> > unset CFLAGS
> > unset CPPFLAGS
> > - oe_runmake all
> > + oe_runmake ${UBOOT_MAKE_TARGET}
> > oe_runmake tools env HOSTCC="${CC}"
> > }
> >
> > --
> > 1.7.0.4
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][2011.003-maintenance] ti-pru-sw-example: fix building with new toolchain sysroot
> From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Koen Kooi > Sent: Wednesday, March 16, 2011 1:22 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH][2011.003-maintenance] ti-pru-sw-example: fix > building with new toolchain sysroot > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 16-03-11 18:22, Chase Maupin wrote: > > * Patch taken from Arago overlay where it was added by > > Denys Dmytriyenko > > * PR incremented by two to align recipe PR values between Arago > > and OE. > > > > Signed-off-by: Chase Maupin > > NAK, this hasn't been thru .dev yet. Just submitted all 4 of my patches for .dev. Thanks. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFNgP/fMkyGM64RGpERAl6xAJ45EJRtCFR9OXVfx47vHziPgljS8ACgnYLG > F8X61AnjZTX5/ctbDUvuhMI= > =9ZrC > -END PGP SIGNATURE- > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][2011.003-maintenance] ti-pru-sw-example: fix building with new toolchain sysroot
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Koen Kooi > Sent: Wednesday, March 16, 2011 1:22 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH][2011.003-maintenance] ti-pru-sw-example: fix > building with new toolchain sysroot > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 16-03-11 18:22, Chase Maupin wrote: > > * Patch taken from Arago overlay where it was added by > > Denys Dmytriyenko > > * PR incremented by two to align recipe PR values between Arago > > and OE. > > > > Signed-off-by: Chase Maupin > > NAK, this hasn't been thru .dev yet. Koen, OK, so I think this answers my question about whether to submit to .dev, oe-core, or what before the maintenance branch. I'll submit all my patches to .dev shortly. Chase > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFNgP/fMkyGM64RGpERAl6xAJ45EJRtCFR9OXVfx47vHziPgljS8ACgnYLG > F8X61AnjZTX5/ctbDUvuhMI= > =9ZrC > -END PGP SIGNATURE- > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][2011.003-maintenance] ti-pru-sw-example: fix building with new toolchain sysroot
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Koen Kooi > Sent: Thursday, March 17, 2011 2:45 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH][2011.003-maintenance] ti-pru-sw-example: fix > building with new toolchain sysroot > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 16-03-11 20:02, Maupin, Chase wrote: > >> From: openembedded-devel-boun...@lists.openembedded.org > >> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > >> Koen Kooi > >> Sent: Wednesday, March 16, 2011 1:22 PM > >> To: openembedded-devel@lists.openembedded.org > >> Subject: Re: [oe] [PATCH][2011.003-maintenance] ti-pru-sw-example: fix > >> building with new toolchain sysroot > >> > > On 16-03-11 18:22, Chase Maupin wrote: > >>>> * Patch taken from Arago overlay where it was added by > >>>> Denys Dmytriyenko > >>>> * PR incremented by two to align recipe PR values between Arago > >>>> and OE. > >>>> > >>>> Signed-off-by: Chase Maupin > > > > NAK, this hasn't been thru .dev yet. > > > >> Just submitted all 4 of my patches for .dev. Thanks. > > I've staged them here: > http://dominion.thruhere.net/git/cgit.cgi/openembedded/log/?h=2011.03- > maintenance > (subject to rebasing). > > Do you want to would for the pull request to go out tomorrow, or do you > want Tom to pick up your patches seperately? Looks like you already have them in your pull request #3 :) Thanks. > > regards, > > Koen > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFNgbv3MkyGM64RGpERAhAuAJ4iE8FFf/ZNqHJF06GSeOEhum9y+wCeOeMO > drixfFNicVpKY2l05LPSynw= > =NAy9 > -END PGP SIGNATURE- > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [2011.03-maintenance] Pull request #3
> -Original Message- > From: Tom Rini [mailto:tom_r...@mentor.com] > Sent: Thursday, March 17, 2011 1:15 PM > To: openembedded-devel@lists.openembedded.org > Cc: Maupin, Chase > Subject: Re: [oe] [2011.03-maintenance] Pull request #3 > > On 03/17/2011 05:52 AM, Koen Kooi wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Tom, > > > > Please pull the 11 commits from here: > > > > URI: git://dominion.thruhere.net/var/cache/git/openembedded.git > > Branch: 2011.03-maintenance > > > > Koen Kooi (7): > >angstrom 2011.03 blacklist bash-noemu > >task-omap-drivers: task for commonly needed drivers on omap chips > >*beagleboard-validation: collection of tasks iand images to serve > >task-beagleboard*: add changes from latest round of feedback > >linux-omap-psp 2.6.32: add support for xM revision C > >linux-omap-psp 2.6.32: bump PR > >u-boot git: update beagleboard u-boot to 2011.03-RC > > > > chase maupin (4): > >u-boot.inc: allow variable make targets > >dm368-evm: Add configuration for DM368 machine > >matrix-gui: add support for dm386-evm machine > >ti-pru-sw-example: fix building with new toolchain sysroot > > > > > > You can view the branch online at > > http://dominion.thruhere.net/git/cgit.cgi/openembedded/log/?h=2011.03- > maintenance > > > > The bash-noemu and u-boot commits both have a one line change compared > > to .dev to account for the differences between angstrom versions. The > > other 9 commits are straight cherry-picks. > > Merged, thanks. > > > I can pick up the external-toolchain patches from Ben for next weeks > > pull request if you wish. > > I've grabbed these with pw-am.sh and updated patchwork. Chase, can you > please update patchwork to reflect that your changes have been applied? > Thanks! Tom, I'll take care of that now. Thanks. > > -- > Tom Rini > Mentor Graphics Corporation ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/1] matrix-gui: update SRCREV
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Jeff Lance > Sent: Wednesday, March 30, 2011 10:20 AM > To: openembedded-devel@lists.openembedded.org > Cc: Lance, Jeff > Subject: [oe] [PATCH 1/1] matrix-gui: update SRCREV > > * am1808 - pull in better description for WiFi. > > Signed-off-by: Jeff Lance > --- Acked-by: Chase Maupin ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/6] ti814x: Add new machine definitions
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Koen Kooi > Sent: Thursday, March 31, 2011 1:42 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH 1/6] ti814x: Add new machine definitions > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 30-03-11 20:08, Chase Maupin wrote: > > * Add new am387x-evm machine definition > > * Add new dm814xx-evm machine definition > > * Add new c6a814x-evm machine definition > > * New SOC_FAMILY ti814x available > > * Based on machine configuration files from Arago contributed > > by Siddharth Heroor > > FWIW, the machines get generally added last in the patch series since > now you have a commit where there are machines, but no uboot/kernel/etc. > Koen, Thanks. I'll do it that way going forward. > regards, > > Koen > > > > > > Signed-off-by: Chase Maupin > > --- > > conf/machine/am387x-evm.conf|5 + > > conf/machine/c6a814x-evm.conf |5 + > > conf/machine/dm814x-evm.conf|5 + > > conf/machine/include/ti814x.inc | 26 ++ > > 4 files changed, 41 insertions(+), 0 deletions(-) > > create mode 100644 conf/machine/am387x-evm.conf > > create mode 100644 conf/machine/c6a814x-evm.conf > > create mode 100644 conf/machine/dm814x-evm.conf > > create mode 100644 conf/machine/include/ti814x.inc > > > > diff --git a/conf/machine/am387x-evm.conf b/conf/machine/am387x-evm.conf > > new file mode 100644 > > index 000..ebf9889 > > --- /dev/null > > +++ b/conf/machine/am387x-evm.conf > > @@ -0,0 +1,5 @@ > > +#@TYPE: Machine > > +#@NAME: AM389x evm > > +#@DESCRIPTION: Machine configuration for the AM389x evm > > + > > +require conf/machine/include/ti814x.inc > > diff --git a/conf/machine/c6a814x-evm.conf b/conf/machine/c6a814x- > evm.conf > > new file mode 100644 > > index 000..b85c489 > > --- /dev/null > > +++ b/conf/machine/c6a814x-evm.conf > > @@ -0,0 +1,5 @@ > > +#@TYPE: Machine > > +#@NAME: c6a814x evm > > +#@DESCRIPTION: Machine configuration for the c6a814x evm > > + > > +require conf/machine/include/ti814x.inc > > diff --git a/conf/machine/dm814x-evm.conf b/conf/machine/dm814x-evm.conf > > new file mode 100644 > > index 000..140dcc1 > > --- /dev/null > > +++ b/conf/machine/dm814x-evm.conf > > @@ -0,0 +1,5 @@ > > +#@TYPE: Machine > > +#@NAME: DM814x evm > > +#@DESCRIPTION: Machine configuration for the DM814x evm > > + > > +require conf/machine/include/ti814x.inc > > diff --git a/conf/machine/include/ti814x.inc > b/conf/machine/include/ti814x.inc > > new file mode 100644 > > index 000..8fa7ee9 > > --- /dev/null > > +++ b/conf/machine/include/ti814x.inc > > @@ -0,0 +1,26 @@ > > +TARGET_ARCH = "arm" > > +SOC_FAMILY = "ti814x" > > + > > +require conf/machine/include/tune-cortexa8.inc > > + > > +PREFERRED_PROVIDER_virtual/kernel = "linux-omap3" > > +PREFERRED_PROVIDER_virtual/bootloader = "u-boot" > > + > > +# Increase this everytime you change something in the kernel > > +MACHINE_KERNEL_PR = "r1" > > + > > +KERNEL_IMAGETYPE = "uImage" > > + > > +UBOOT_ARCH = "arm" > > +UBOOT_MACHINE = "ti8148_evm_config_nand" > > +UBOOT_ENTRYPOINT = "0x80008000" > > +UBOOT_LOADADDRESS = "0x80008000" > > + > > +# Only build u-boot > > +EXTRA_IMAGEDEPENDS += "u-boot" > > + > > +# Ship all kernel modules > > +IMAGE_FSTYPES ?= "jffs2 tar.bz2" > > +EXTRA_IMAGECMD_jffs2 = "-lqn -e 128" > > +SERIAL_CONSOLE = "115200 ttyO0" > > +MACHINE_FEATURES = "kernel26 apm usbgadget usbhost vfat ext2 ethernet" > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFNlCIoMkyGM64RGpERAkAmAJ9Eie7vs4ZP8LqzsxsOwmwhbas0fACgoUTl > KodmBksvnoK3o5Kx+x6LQZk= > =mssH > -END PGP SIGNATURE- > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Unused patches in x-load-git directory
All, I noticed that there are 5 patches in the recipes/x-load/x-load-git directory that do not seem to be used by any recipes. At least one of the patches seems to have been merged into the upstream project (http://gitorious.org/x-loader/x-loader/commits/master). Is anyone using the patches below? If not then I'll submit a patch to remove them. 0001-OMAP4-clocks-Enable-only-required-clks.patch 0002-OMAP4-Select-DPLL-PER-Clock-as-source-for-SGX-FCLK.patch 0003-MUX-Configure-SYS_NIRQ2-pin-in-safe-mode.patch 0004-OMAP4-clocks-Disable-slimbus-and-pad_clks.patch 0005-omap4-Make-1GHz-as-default-MPU-clock.patch Sincerely, Chase Maupin Open Platforms ARM MPU e-mail: chase.mau...@ti.com phone: (214) 567-2950 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 5/5] am45x-evm: Add am45x-evm machine configuration
> -Original Message- > From: Denys Dmytriyenko [mailto:de...@denix.org] > Sent: Tuesday, April 05, 2011 11:38 AM > To: openembedded-devel@lists.openembedded.org > Cc: Maupin, Chase > Subject: Re: [oe] [PATCH 5/5] am45x-evm: Add am45x-evm machine > configuration > > On Tue, Apr 05, 2011 at 10:41:51AM -0500, Chase Maupin wrote: > > * Added a new machine configuration for the am45x-evm device. > > * This machine currently mimics the omap4430-panda configuration > > during the prototyping phase but is expected to change as the > > hardware and software evolves. > > * The am45x-evm machine type is used to allow differentiating > > software components to be build and packaged (i.e. task lists) > > as well as to account for differences with the omap4430-panda > > device in the future. > > Chase, > > This would have been better explained in a cover letter for all the 5 > patches, > as I was reading through the first 4 and wondering why do you use panda > remnants, until I got to the 5th one... :) > > FYI, there are new repos on arago ready to be populated for linux-am45x > and > u-boot-am45x, so need to switch corresponding recipes in the future... Thanks. I'll do that in the future. We will switch to the Arago repos when they are ready but that is not scheduled for over a month. Until then this lets us keep prototyping and developing :) > > > Signed-off-by: Chase Maupin > > Acked-by: Denys Dmytriyenko > > > --- > > conf/machine/am45x-evm.conf | 10 ++ > > 1 files changed, 10 insertions(+), 0 deletions(-) > > create mode 100644 conf/machine/am45x-evm.conf > > > > diff --git a/conf/machine/am45x-evm.conf b/conf/machine/am45x-evm.conf > > new file mode 100644 > > index 000..3597d37 > > --- /dev/null > > +++ b/conf/machine/am45x-evm.conf > > @@ -0,0 +1,10 @@ > > +#@TYPE: Machine > > +#@NAME: AM45X EVM > > +#@DESCRIPTION: Machine configuration for the AM45x EVM > > + > > +# Currently the am45x-evm machine type mimics the panda > > +# machine for its configuration. This is expected to change > > +# as the hardware and software evolves. Currently the unique > > +# machine type is used to differentiate software stack being > > +# built for the two devices. > > +require conf/machine/omap4430-panda.conf > > -- > > 1.7.0.4 > > > > > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] ncurses-5.7 patch files are missing
All, Has anyone else noticed that the patch files referred to in the ncurses_5.7 recipe are missing from the ftp site? The patch files are: ncurses-5.7-20110108-patch.sh.bz2 ncurses-5.7-20110115.patch.gz Does anyone have these mirrored or can they be uploaded to a mirror like the Angstrom mirror? Sincerely, Chase Maupin ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] ncurses-5.7 patch files are missing
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Henning Heinold > Sent: Monday, April 11, 2011 3:12 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] ncurses-5.7 patch files are missing > > On Mon, Apr 11, 2011 at 03:07:35PM -0500, Maupin, Chase wrote: > > All, > > > > Has anyone else noticed that the patch files referred to in the > ncurses_5.7 recipe are missing from the ftp site? The patch files are: > > > > ncurses-5.7-20110108-patch.sh.bz2 > > ncurses-5.7-20110115.patch.gz > > > > Does anyone have these mirrored or can they be uploaded to a mirror like > the Angstrom mirror? > > > > > > Sincerely, > > Chase Maupin > > Yes serval people reported that now, I have no acess to upload them. I > guess koen will do it when he returns > from elc. Henning, Thanks. I didn't notice the reports on the mailing list. I did however notice that Tom Rini is adding ncurses version 5.9 to oe-core. I wonder if maybe this should be ported over to the OE mainline or just stick with 5.7+patches for now until everything is moved to oe-core. Anyone else have thoughts on this? > > Bye Henning > > PS: google finds the following archive http://shr.bearstech.com/shr- > unstable/sources/MIT/ncurses/ > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] ncurses-5.7 patch files are missing
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Tom Rini > Sent: Monday, April 11, 2011 3:21 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] ncurses-5.7 patch files are missing > > On 04/11/2011 01:17 PM, Maupin, Chase wrote: > >> -Original Message- > >> From: openembedded-devel-boun...@lists.openembedded.org > >> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > >> Henning Heinold > >> Sent: Monday, April 11, 2011 3:12 PM > >> To: openembedded-devel@lists.openembedded.org > >> Subject: Re: [oe] ncurses-5.7 patch files are missing > >> > >> On Mon, Apr 11, 2011 at 03:07:35PM -0500, Maupin, Chase wrote: > >>> All, > >>> > >>> Has anyone else noticed that the patch files referred to in the > >> ncurses_5.7 recipe are missing from the ftp site? The patch files are: > >>> > >>> ncurses-5.7-20110108-patch.sh.bz2 > >>> ncurses-5.7-20110115.patch.gz > >>> > >>> Does anyone have these mirrored or can they be uploaded to a mirror > like > >> the Angstrom mirror? > >>> > >>> > >>> Sincerely, > >>> Chase Maupin > >> > >> Yes serval people reported that now, I have no acess to upload them. I > >> guess koen will do it when he returns > >> from elc. > > > > Henning, > > > > Thanks. I didn't notice the reports on the mailing list. I did however > notice that Tom Rini is adding ncurses version 5.9 to oe-core. I wonder > if maybe this should be ported over to the OE mainline or just stick with > 5.7+patches for now until everything is moved to oe-core. Anyone else > have thoughts on this? > > It's already done (I got it in here first). Tom, sorry about that. I was looking at the 2011.03-maintenance branch instead of the master. Koen, would you mind submitting a pull request with the ncurses_5.9 recipe to Tom for the 2011.03-maintenance branch when you get back? We should be able to queue this up with some other patches from Sid and others. > > -- > Tom Rini > Mentor Graphics Corporation > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] ti-ipc: Add version 1.22.05.27
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Siddharth Heroor > Sent: Tuesday, April 12, 2011 3:52 AM > To: openembedded-devel@lists.openembedded.org > Cc: Heroor, Siddharth > Subject: [oe] [PATCH] ti-ipc: Add version 1.22.05.27 > > > Signed-off-by: Siddharth Heroor > --- > recipes/ti/ti-ipc_1.22.05.27.bb |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > create mode 100644 recipes/ti/ti-ipc_1.22.05.27.bb > > diff --git a/recipes/ti/ti-ipc_1.22.05.27.bb b/recipes/ti/ti- > ipc_1.22.05.27.bb > new file mode 100644 > index 000..c3d25a6 > --- /dev/null > +++ b/recipes/ti/ti-ipc_1.22.05.27.bb > @@ -0,0 +1,6 @@ > +require ti-ipc.inc > + > +PV = "1_22_05_27" > + > +SRC_URI[ipcbin.md5sum] = "bd35d75b754f0fc54d7ad74cfc971987" > +SRC_URI[ipcbin.sha256sum] = > "b61969dc8b5bf01ee6f68151d2c8e123b1b3b425990987fe64288085d8cc15b7" > -- > 1.7.0.4 Acked-by: Chase Maupin > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] hostap-daemon: Build from git sources
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Eyal Reizer > Sent: Tuesday, April 12, 2011 4:54 PM > To: openembedded-devel@lists.openembedded.org > Cc: Reizer, Eyal > Subject: [oe] [PATCH] hostap-daemon: Build from git sources Please provide a more detailed message. Why are you adding this git version? Also, much of this recipe is shared with the previous version. Can you abstract this into an include file that can be shared with both recipes? > > Signed-off-by: Eyal Reizer > --- > recipes/hostap/hostap-daemon-git/defconfig | 187 > > recipes/hostap/hostap-daemon_git.bb| 37 ++ > 2 files changed, 224 insertions(+), 0 deletions(-) > create mode 100755 recipes/hostap/hostap-daemon-git/defconfig > create mode 100755 recipes/hostap/hostap-daemon_git.bb > > diff --git a/recipes/hostap/hostap-daemon-git/defconfig > b/recipes/hostap/hostap-daemon-git/defconfig > new file mode 100755 > index 000..4fd9061 > --- /dev/null > +++ b/recipes/hostap/hostap-daemon-git/defconfig > @@ -0,0 +1,187 @@ > +# Example hostapd build time configuration > +# > +# This file lists the configuration options that are used when building > the > +# hostapd binary. All lines starting with # are ignored. Configuration > option > +# lines must be commented out complete, if they are not to be included, > i.e., > +# just setting VARIABLE=n is not disabling that variable. > +# > +# This file is included in Makefile, so variables like CFLAGS and LIBS > can also > +# be modified from here. In most cass, these lines should use += in order > not > +# to override previous values of the variables. > + > +#CC=$(CROSS_COMPILE)gcc > +#CFLAGS += -I$(NFSROOT)/include -DCONFIG_LIBNL20 > +#CPPFLAGS += -DCONFIG_LIBNL20 > +#LIBS += -L$(NFSROOT)/lib -lnl-genl > +#LIBS_p += -L$(NFSROOT)/lib > +#LIBDIR = $(NFSROOT)/lib > +#BINDIR = $(NFSROOT)/usr/sbin > + > +# Driver interface for Host AP driver > +CONFIG_DRIVER_HOSTAP=y > + > +# Driver interface for wired authenticator > +#CONFIG_DRIVER_WIRED=y > + > +# Driver interface for madwifi driver > +#CONFIG_DRIVER_MADWIFI=y > +#CFLAGS += -I../../madwifi # change to the madwifi source directory > + > +# Driver interface for drivers using the nl80211 kernel interface > +CONFIG_DRIVER_NL80211=y > +CONFIG_LIBNL20=y > +# driver_nl80211.c requires a rather new libnl (version 1.1) which may > not be > +# shipped with your distribution yet. If that is the case, you need to > build > +# newer libnl version and point the hostapd build to use it. > +#LIBNL=$(LIBNL_PATH) > +#CFLAGS += -I$(LIBNL)/include > +#LIBS += -L$(LIBNL)/lib > + > +# Driver interface for FreeBSD net80211 layer (e.g., Atheros driver) > +#CONFIG_DRIVER_BSD=y > +#CFLAGS += -I/usr/local/include > +#LIBS += -L/usr/local/lib > +#LIBS_p += -L/usr/local/lib > +#LIBS_c += -L/usr/local/lib > + > +# Driver interface for no driver (e.g., RADIUS server only) > +#CONFIG_DRIVER_NONE=y > + > +# IEEE 802.11F/IAPP > +CONFIG_IAPP=y > + > +# WPA2/IEEE 802.11i RSN pre-authentication > +CONFIG_RSN_PREAUTH=y > + > +# PeerKey handshake for Station to Station Link (IEEE 802.11e DLS) > +CONFIG_PEERKEY=y > + > +# IEEE 802.11w (management frame protection) > +# This version is an experimental implementation based on IEEE > 802.11w/D1.0 > +# draft and is subject to change since the standard has not yet been > finalized. > +# Driver support is also needed for IEEE 802.11w. > +#CONFIG_IEEE80211W=y > + > +# Integrated EAP server > +CONFIG_EAP=y > + > +# EAP-MD5 for the integrated EAP server > +CONFIG_EAP_MD5=y > + > +# EAP-TLS for the integrated EAP server > +CONFIG_EAP_TLS=y > + > +# EAP-MSCHAPv2 for the integrated EAP server > +CONFIG_EAP_MSCHAPV2=y > + > +# EAP-PEAP for the integrated EAP server > +CONFIG_EAP_PEAP=y > + > +# EAP-GTC for the integrated EAP server > +CONFIG_EAP_GTC=y > + > +# EAP-TTLS for the integrated EAP server > +CONFIG_EAP_TTLS=y > + > +# EAP-SIM for the integrated EAP server > +#CONFIG_EAP_SIM=y > + > +# EAP-AKA for the integrated EAP server > +#CONFIG_EAP_AKA=y > + > +# EAP-AKA' for the integrated EAP server > +# This requires CONFIG_EAP_AKA to be enabled, too. > +#CONFIG_EAP_AKA_PRIME=y > + > +# EAP-PAX for the integrated EAP server > +#CONFIG_EAP_PAX=y > + > +# EAP-PSK for the integrated EAP server (this is _not_ needed for WPA- > PSK) > +#CONFIG_EAP_PSK=y > + > +# EAP-SAKE for the integrated EAP server > +#CONFIG_EAP_SAKE=y > + > +# EAP-GPSK for the integrated EAP server > +#CONFIG_EAP_GPSK=y > +# Include support for optional SHA256 cipher suite in EAP-GPSK > +#CONFIG_EAP_GPSK_SHA256=y > + > +# EAP-FAST for the integrated EAP server > +# Note: Default OpenSSL package does not include support for all the > +# functionality needed for EAP-FAST. If EAP-FAST is enabled with OpenSSL, > +# the OpenSSL library must be patched (openssl-0.9.9-session- > ticket.patch) > +# to add the needed functio
Re: [oe] [PATCH] ti-wifi-utils: update to a newer git commit
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Eyal Reizer
> Sent: Tuesday, April 12, 2011 4:55 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Reizer, Eyal
> Subject: [oe] [PATCH] ti-wifi-utils: update to a newer git commit
Please add a better commit message. See
http://wiki.openembedded.net/index.php/Commit_Policy.
Also, I think you should define a PR value of r1. If not I don't think you can
guarantee that this package version will sort properly.
>
> Signed-off-by: Eyal Reizer
> ---
> recipes/ti/ti-wifi-utils_git.bb |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/recipes/ti/ti-wifi-utils_git.bb b/recipes/ti/ti-wifi-
> utils_git.bb
> index 92edb7f..600e21f 100644
> --- a/recipes/ti/ti-wifi-utils_git.bb
> +++ b/recipes/ti/ti-wifi-utils_git.bb
> @@ -6,7 +6,7 @@ DEPENDS = "libnl"
> PV ="0.0"
> PR_append = "+gitr${SRCPV}"
>
> -SRCREV = "6de17deb67a1313b5cc8"
> +SRCREV = "7f63af54eb66e5b2515f92c59fcc19a8065ce481"
> SRC_URI = "git://github.com/gxk/ti-utils.git;protocol=git"
>
> S = "${WORKDIR}/git"
> --
> 1.7.0.4
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [2011.03-maintenance] Pull request for TI matrix-gui, ipc and sgx/gles
Denys, Thanks a lot for this. It is really appreciated. Sincerely, Chase Maupin Open Platforms ARM MPU e-mail: chase.mau...@ti.com phone: (214) 567-2950 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Denys Dmytriyenko > Sent: Thursday, April 14, 2011 2:35 PM > To: openembedded-devel@lists.openembedded.org > Subject: [oe] [2011.03-maintenance] Pull request for TI matrix-gui, ipc > and sgx/gles > > Tom, > > Please pull these 5 commits for TI related changes - matrix-gui rev bump, > new ti-ipc version and sgx/gles fixes for ti816x. > All are cherry picked from oe.dev > > > Pull URL: git://arago-project.org/git/people/denix/openembedded.git > Branch: 2011.03-maintenance > Browse: http://arago- > project.org/git/people/?p=denix/openembedded.git;a=shortlog;h=refs/heads/2 > 011.03-maintenance > > Thanks, > Denys Dmytriyenko > --- > > > Jeff Lance (1): > matrix-gui: Bump up SRCREV > > Siddharth Heroor (4): > ti-ipc: Add version 1.22.05.27 > omap3-sgx-modules: Update TI816x Module Location and Platform > variables. > libgles-omap3: Correct libraries for TI816x. > libgles-omap3: Remove SGX Fixup for TI816x. > > recipes/powervr-drivers/libgles-omap3/rc.pvr | 10 +++--- > .../powervr-drivers/libgles-omap3_4.03.00.01.bb|4 +++- > .../omap3-sgx-modules_1.6.16.3977.bb |4 ++-- > recipes/ti/matrix-gui-common_1.4.bb|4 ++-- > recipes/ti/matrix-gui-e_1.3.bb |4 ++-- > recipes/ti/matrix-gui_1.3.bb |4 ++-- > recipes/ti/ti-ipc_1.22.05.27.bb|6 ++ > 7 files changed, 20 insertions(+), 16 deletions(-) > create mode 100644 recipes/ti/ti-ipc_1.22.05.27.bb > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/1] matrix-gui: Bump up SRCREV
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Paul Menzel
> Sent: Thursday, April 14, 2011 7:58 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Lance, Jeff
> Subject: Re: [oe] [PATCH 1/1] matrix-gui: Bump up SRCREV
>
> Dear Chase, dear Jeff,
>
>
> Am Donnerstag, den 14.04.2011, 06:57 -0500 schrieb Chase Maupin:
> > From: Jeff Lance
> >
> > * Bump up SRCREV
> > * add am389x platform support
> > * am1808 add correct instructions for running profibus demo
> >
> > Signed-off-by: Jeff Lance
> > ---
> > recipes/ti/matrix-gui-common_1.4.bb |4 ++--
> > recipes/ti/matrix-gui-e_1.3.bb |4 ++--
> > recipes/ti/matrix-gui_1.3.bb|4 ++--
> > 3 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/recipes/ti/matrix-gui-common_1.4.bb b/recipes/ti/matrix-
> gui-common_1.4.bb
> > index 04cdb2f..d436044 100644
> > --- a/recipes/ti/matrix-gui-common_1.4.bb
> > +++ b/recipes/ti/matrix-gui-common_1.4.bb
> > @@ -4,5 +4,5 @@ require matrix-gui-common.inc
> > # prebuilt version in the repository.
> > RRECOMMENDS_${PN} = "am-sysinfo"
> >
> > -SRCREV = "243"
> > -PR = "${INC_PR}.8"
> > +SRCREV = "245"
> > +PR = "${INC_PR}.9"
> > diff --git a/recipes/ti/matrix-gui-e_1.3.bb b/recipes/ti/matrix-gui-
> e_1.3.bb
> > index 4519437..fb7e4b3 100644
> > --- a/recipes/ti/matrix-gui-e_1.3.bb
> > +++ b/recipes/ti/matrix-gui-e_1.3.bb
> > @@ -1,5 +1,5 @@
> > require matrix-gui-e.inc
> >
> > -SRCREV = "243"
> > -PR = "${INC_PR}.7"
> > +SRCREV = "245"
> > +PR = "${INC_PR}.8"
> >
> > diff --git a/recipes/ti/matrix-gui_1.3.bb b/recipes/ti/matrix-gui_1.3.bb
> > index 727aca1..2c38fc3 100644
> > --- a/recipes/ti/matrix-gui_1.3.bb
> > +++ b/recipes/ti/matrix-gui_1.3.bb
> > @@ -1,4 +1,4 @@
> > require matrix-gui.inc
> >
> > -SRCREV = "243"
> > -PR = "${INC_PR}.3"
> > +SRCREV = "245"
> > +PR = "${INC_PR}.4"
>
> is the bump of `PR` needed? Is not the increment of `SRCREV` implying
> that already?
The SRCREV is not used as part of the PR value, so without this bump
incremental builds would not see this as needing a rebuild.
>
>
> Thanks,
>
> Paul
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH v2 1/1] am-benchmarks: add return values
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Jeff Lance
> Sent: Wednesday, April 27, 2011 2:08 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Lance, Jeff
> Subject: [oe] [PATCH v2 1/1] am-benchmarks: add return values
>
> * add return values to dhrystone and linpack for automated test
>
> Signed-off-by: Jeff Lance
>
> ---
> Updated in version 2:
> * added space before bulleted list
> ---
> recipes/ti/am-benchmarks_1.2.bb |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/recipes/ti/am-benchmarks_1.2.bb b/recipes/ti/am-
> benchmarks_1.2.bb
> index 38c7056..21e62a7 100644
> --- a/recipes/ti/am-benchmarks_1.2.bb
> +++ b/recipes/ti/am-benchmarks_1.2.bb
> @@ -8,7 +8,7 @@ LICENSE = "BSD"
> SECTION = "system"
> PRIORITY = "optional"
>
> -SRCREV = "60"
> +SRCREV = "61"
> PR = "r2+svnr${SRCPV}"
>
> COMPATIBLE_MACHINE = "(dm365|omapl138|omap3|ti816x|ti814x)"
Acked-by: Chase Maupin
> --
> 1.7.0.4
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] ncurses: add missing patch file
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Tom Rini > Sent: Thursday, May 05, 2011 3:13 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] ncurses: add missing patch file > > On 05/05/2011 11:07 AM, Chase Maupin wrote: > > * The 20110115 patch file has gone missing. Add it to the > > OE repository like the previous patch file. > > * Bump the PR > > > > Signed-off-by: Chase Maupin > > Maybe we need to consider just moving to vanilla 5.9 and drop 5.7? I asked Koen to submit a pull request to the maintenance branch to add 5.9 so I agree there. I just thought I would go ahead and submit a patch to the dev branch to fix version 5.7 in case someone is using that version. Personally I'm fine with going to 5.9 directly. > > -- > Tom Rini > Mentor Graphics Corporation > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] ncurses: add missing patch file
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Paul Menzel > Sent: Monday, May 09, 2011 12:21 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] ncurses: add missing patch file > > Dear Chase, dear Tom, > > > Am Donnerstag, den 05.05.2011, 16:13 -0500 schrieb Maupin, Chase: > > > > Sent: Thursday, May 05, 2011 3:13 PM > > > > On 05/05/2011 11:07 AM, Chase Maupin wrote: > > > > * The 20110115 patch file has gone missing. Add it to the > > > > OE repository like the previous patch file. > > > > * Bump the PR > > > > > > > > Signed-off-by: Chase Maupin > > > > > > Maybe we need to consider just moving to vanilla 5.9 and drop 5.7? > > > > I asked Koen to submit a pull request to the maintenance branch to > add > > 5.9 so I agree there. I just thought I would go ahead and submit a > > patch to the dev branch to fix version 5.7 in case someone is using > > that version. > > > > Personally I'm fine with going to 5.9 directly. > > I would vote for getting this patch applied to improve the quality > since > one more package build with no problems. > > Acked-by: Paul Menzel > > Chase, can you push to the repository? Paul, I cannot, but someone was nice enough to do it today :) > > > Thanks, > > Paul ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] pcsc-lite: make configuration file a separate package
> -Original Message-
> From: Denys Dmytriyenko [mailto:de...@denix.org]
> Sent: Thursday, May 12, 2011 10:43 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: Re: [oe] [PATCH] pcsc-lite: make configuration file a separate
> package
>
> On Tue, May 10, 2011 at 05:17:42PM -0500, Chase Maupin wrote:
> > * Move the reader.conf file to be part of a separate package
> > so that it is not installed by default.
> > * This is done because individual readers that implements an
> > IFDHandler library need to be able to install their reader.conf
> > file in the /etc/reader.conf.d directory. Without this change
>
> Chase,
>
> Sorry, it did not occur to me yesterday, when helping with the patch,
> but I
> just realised now that /etc/reader.conf.d (like any other dir.d
> denotion)
> should expect a set of config files and not just one specific one.
>
> So, I started checking the sources and the ChangeLog from pcsc-lite and
> got it
> confirmed - you can pretty much drop a set of files into that directory
> and
> all of them will be parsed for the configuration. So, since the default
> file
> is only a template with all the configuration commented out, you should
> be
> safe to install your own config files in that directory with different
> names.
> That way you don't need any changes to the pcsc-lite recipe...
Denys,
Thanks. The documentation I was reading for pcsc-lite made it sound like you
needed the file to be called reader.conf. I guess ignore this patch for now
then and we'll try having a separate reader.conf.pru file installed and see if
pcsc-lite can find it. Thanks for the info.
>
> One of the relative enties from ChangeLog:
> - Add the ability to parse all the configuration files of a directory
> instead of just one configuration file. update-reader.conf is then
> now
> obsolete.
>
> --
> Denys
>
> > those packages will conflict with the reader.conf file installed
> > by the pcsc-lite package:
> > * NOTE: the reader.conf file in the package is a commented out
> > template file, not an actual working configuration
> > file.
> > * Using this change IFDHandler packages can use RCONFLICT with
> > the pcsc-lite-collateral package to let users know that these
> > packages cannot co-exist.
> > * Mark the configuration file an such so that when the package is
> > updated the user's changes are not lost.
> > * Bump the PR.
> >
> > Signed-off-by: Chase Maupin
> > ---
> > recipes/pcsc-lite/pcsc-lite_1.5.2.bb |5 +
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/recipes/pcsc-lite/pcsc-lite_1.5.2.bb b/recipes/pcsc-
> lite/pcsc-lite_1.5.2.bb
> > index b4af08d..88401b6 100644
> > --- a/recipes/pcsc-lite/pcsc-lite_1.5.2.bb
> > +++ b/recipes/pcsc-lite/pcsc-lite_1.5.2.bb
> > @@ -5,6 +5,8 @@ LICENSE = "BSD"
> > DEPENDS = "hal"
> > RDEPENDS_${PN} = "hal"
> >
> > +PR = "r1"
> > +
> > SRC_URI = "https://alioth.debian.org/frs/download.php/2795/pcsc-
> lite-${PV}.tar.bz2 \
> > file://pcscd.init "
> >
> > @@ -26,8 +28,11 @@ do_install() {
> > }
> >
> > PACKAGES =+ "libpcsclite"
> > +PACKAGES =+ "${PN}-collateral"
> >
> > FILES_libpcsclite = "${libdir}/libpcsclite.so.*"
> > +FILES_${PN}-collateral = "${sysconfdir}/reader.conf.d/*"
> > +CONFFILES_${PN}-collateral = "${sysconfdir}/reader.conf.d/*"
> >
> > SRC_URI[md5sum] = "d7d466621bec39354351f09349f6374c"
> > SRC_URI[sha256sum] =
> "a0c11b0b5cc46d4c4ec499b875cfdc4e766fdf12fe2f6ea635e1b11ab7b8821e"
> > --
> > 1.7.0.4
> >
> >
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] Jeff Lance : matrix_gui: Pull in lmbench, multimedia, EZSDK mods
> -Original Message-
> From: openembedded-commits-boun...@lists.openembedded.org
> [mailto:openembedded-commits-boun...@lists.openembedded.org] On Behalf
> Of git version control
> Sent: Wednesday, May 18, 2011 12:23 PM
> To: openembedded-comm...@openembedded.org
> Subject: [oe-commits] Jeff Lance : matrix_gui: Pull in lmbench,
> multimedia, EZSDK mods
>
> Module: openembedded.git
> Branch: master
> Commit: b14cb947a346088d14b0d78d3546314c9d37cdbb
> URL:
> http://git.openembedded.org/?p=openembedded.git&a=commit;h=b14cb947a346
> 088d14b0d78d3546314c9d37cdbb
>
> Author: Jeff Lance
> Date: Thu May 19 23:35:09 2011 +
>
> matrix_gui: Pull in lmbench,multimedia,EZSDK mods
>
> * Update SRCREV to pull in:
> * Multimedia apps
> * LMBench apps
> * EZSDK updates
> * remove Blitrix
>
> Signed-off-by: Jeff Lance
> Signed-off-by: Denys Dmytriyenko
Acked-by: Chase Maupin
>
> ---
>
> recipes/ti/matrix-gui-common_1.4.bb |4 ++--
> recipes/ti/matrix-gui-e_1.3.bb |4 ++--
> recipes/ti/matrix-gui_1.3.bb|4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/recipes/ti/matrix-gui-common_1.4.bb b/recipes/ti/matrix-
> gui-common_1.4.bb
> index d436044..6f7376d 100644
> --- a/recipes/ti/matrix-gui-common_1.4.bb
> +++ b/recipes/ti/matrix-gui-common_1.4.bb
> @@ -4,5 +4,5 @@ require matrix-gui-common.inc
> # prebuilt version in the repository.
> RRECOMMENDS_${PN} = "am-sysinfo"
>
> -SRCREV = "245"
> -PR = "${INC_PR}.9"
> +SRCREV = "249"
> +PR = "${INC_PR}.10"
> diff --git a/recipes/ti/matrix-gui-e_1.3.bb b/recipes/ti/matrix-gui-
> e_1.3.bb
> index fb7e4b3..8f2df1c 100644
> --- a/recipes/ti/matrix-gui-e_1.3.bb
> +++ b/recipes/ti/matrix-gui-e_1.3.bb
> @@ -1,5 +1,5 @@
> require matrix-gui-e.inc
>
> -SRCREV = "245"
> -PR = "${INC_PR}.8"
> +SRCREV = "249"
> +PR = "${INC_PR}.9"
>
> diff --git a/recipes/ti/matrix-gui_1.3.bb b/recipes/ti/matrix-
> gui_1.3.bb
> index 2c38fc3..f7e56a3 100644
> --- a/recipes/ti/matrix-gui_1.3.bb
> +++ b/recipes/ti/matrix-gui_1.3.bb
> @@ -1,4 +1,4 @@
> require matrix-gui.inc
>
> -SRCREV = "245"
> -PR = "${INC_PR}.4"
> +SRCREV = "249"
> +PR = "${INC_PR}.5"
>
>
> ___
> Openembedded-commits mailing list
> openembedded-comm...@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> commits
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] Jeff Lance : matrix_gui: Pull in lmbench, multimedia, EZSDK mods
Please ignore. Don't know why I acked the commit message :)
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Maupin, Chase
> Sent: Wednesday, May 18, 2011 2:02 PM
> To: openembedded-devel@lists.openembedded.org; openembedded-
> comm...@openembedded.org
> Subject: Re: [oe] [oe-commits] Jeff Lance : matrix_gui: Pull in
> lmbench, multimedia, EZSDK mods
>
> > -Original Message-
> > From: openembedded-commits-boun...@lists.openembedded.org
> > [mailto:openembedded-commits-boun...@lists.openembedded.org] On
> Behalf
> > Of git version control
> > Sent: Wednesday, May 18, 2011 12:23 PM
> > To: openembedded-comm...@openembedded.org
> > Subject: [oe-commits] Jeff Lance : matrix_gui: Pull in lmbench,
> > multimedia, EZSDK mods
> >
> > Module: openembedded.git
> > Branch: master
> > Commit: b14cb947a346088d14b0d78d3546314c9d37cdbb
> > URL:
> >
> http://git.openembedded.org/?p=openembedded.git&a=commit;h=b14cb947a346
> > 088d14b0d78d3546314c9d37cdbb
> >
> > Author: Jeff Lance
> > Date: Thu May 19 23:35:09 2011 +
> >
> > matrix_gui: Pull in lmbench,multimedia,EZSDK mods
> >
> > * Update SRCREV to pull in:
> > * Multimedia apps
> > * LMBench apps
> > * EZSDK updates
> > * remove Blitrix
> >
> > Signed-off-by: Jeff Lance
> > Signed-off-by: Denys Dmytriyenko
>
> Acked-by: Chase Maupin
>
> >
> > ---
> >
> > recipes/ti/matrix-gui-common_1.4.bb |4 ++--
> > recipes/ti/matrix-gui-e_1.3.bb |4 ++--
> > recipes/ti/matrix-gui_1.3.bb|4 ++--
> > 3 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/recipes/ti/matrix-gui-common_1.4.bb b/recipes/ti/matrix-
> > gui-common_1.4.bb
> > index d436044..6f7376d 100644
> > --- a/recipes/ti/matrix-gui-common_1.4.bb
> > +++ b/recipes/ti/matrix-gui-common_1.4.bb
> > @@ -4,5 +4,5 @@ require matrix-gui-common.inc
> > # prebuilt version in the repository.
> > RRECOMMENDS_${PN} = "am-sysinfo"
> >
> > -SRCREV = "245"
> > -PR = "${INC_PR}.9"
> > +SRCREV = "249"
> > +PR = "${INC_PR}.10"
> > diff --git a/recipes/ti/matrix-gui-e_1.3.bb b/recipes/ti/matrix-gui-
> > e_1.3.bb
> > index fb7e4b3..8f2df1c 100644
> > --- a/recipes/ti/matrix-gui-e_1.3.bb
> > +++ b/recipes/ti/matrix-gui-e_1.3.bb
> > @@ -1,5 +1,5 @@
> > require matrix-gui-e.inc
> >
> > -SRCREV = "245"
> > -PR = "${INC_PR}.8"
> > +SRCREV = "249"
> > +PR = "${INC_PR}.9"
> >
> > diff --git a/recipes/ti/matrix-gui_1.3.bb b/recipes/ti/matrix-
> > gui_1.3.bb
> > index 2c38fc3..f7e56a3 100644
> > --- a/recipes/ti/matrix-gui_1.3.bb
> > +++ b/recipes/ti/matrix-gui_1.3.bb
> > @@ -1,4 +1,4 @@
> > require matrix-gui.inc
> >
> > -SRCREV = "245"
> > -PR = "${INC_PR}.4"
> > +SRCREV = "249"
> > +PR = "${INC_PR}.5"
> >
> >
> > ___
> > Openembedded-commits mailing list
> > openembedded-comm...@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> > commits
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] kernel bbclass: add the crypto directory to staging
Ping on this patch. I've seen one ACK so far.
Sincerely,
Chase Maupin
Open Platforms
ARM MPU
e-mail: chase.mau...@ti.com
phone: (214) 567-2950
For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Thursday, June 16, 2011 2:29 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase; Turner, Greg
> Subject: [PATCH] kernel bbclass: add the crypto directory to staging
>
> * Add the include/crypto directory from the kernel to the list
> of directories to be staged.
> * This directory contains the cryptodev.h file required by other
> drivers and applications.
> * Not including this directory leads to build errors of being
> unable to find the cryptodev.h file.
>
> Signed-off-by: Greg Turner
> Signed-off-by: Chase Maupin
> ---
> classes/kernel.bbclass |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/classes/kernel.bbclass b/classes/kernel.bbclass
> index 8817186..bd7b23f 100644
> --- a/classes/kernel.bbclass
> +++ b/classes/kernel.bbclass
> @@ -188,7 +188,7 @@ sysroot_stage_all_append() {
> mkdir -p $kerneldir/include/asm-generic
> cp -fR include/asm-generic/* $kerneldir/include/asm-generic/
>
> - for entry in drivers/crypto drivers/media include/generated
> include/linux include/net include/pcmcia include/media include/acpi
> include/sound include/video include/scsi include/trace include/mtd
> include/rdma include/drm include/xen crypto/ocf; do
> + for entry in drivers/crypto drivers/media include/generated
> include/linux include/net include/pcmcia include/media include/acpi
> include/sound include/video include/scsi include/trace include/mtd
> include/rdma include/drm include/xen crypto/ocf include/crypto; do
> if [ -d $entry ]; then
> mkdir -p $kerneldir/$entry
> cp -fR $entry/* $kerneldir/$entry/
> --
> 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/1] matrix-tui: Update to arago toolchain
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Denys Dmytriyenko
> Sent: Wednesday, June 22, 2011 4:11 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Lance, Jeff
> Subject: Re: [oe] [PATCH 1/1] matrix-tui: Update to arago toolchain
>
> On Wed, Jun 22, 2011 at 02:02:01PM -0500, Jeff Lance wrote:
> > * Modify to use arago MACHINE name for platforms
> > * Add all Sitara platforms
> > * Update SRCREV to 41
> >
> > Signed-off-by: Jeff Lance
>
> Jeff,
>
> See my coments below.
>
>
> > ---
> > recipes/ti/matrix-tui.inc| 12 +++-
> > recipes/ti/matrix-tui_1.1.bb |4 ++--
> > 2 files changed, 5 insertions(+), 11 deletions(-)
> >
> > diff --git a/recipes/ti/matrix-tui.inc b/recipes/ti/matrix-tui.inc
> > index 1ad8aa8..a3793d3 100644
> > --- a/recipes/ti/matrix-tui.inc
> > +++ b/recipes/ti/matrix-tui.inc
> > @@ -9,13 +9,6 @@ INC_PR = "r7"
> >
> > COMPATIBLE_MACHINE = "(omapl138|omap3)"
> >
> > -PLATFORM_am37x-evm = "am3715"
> > -PLATFORM_beagleboard = "am3715"
> > -PLATFORM_am3517-evm = "am3517"
> > -PLATFORM_am180x-evm = "am180x"
> > -PLATFORM_am181x-evm = "am181x"
> > -PLATFORM_da850-omapl138-evm = "am180x"
> > -
> > SRC_URI =
> "svn://gforge.ti.com/svn/matrix_tui/;module=trunk;proto=https;user=anon
> ymous;pswd='' \
> > file://init \
> > "
> > @@ -28,7 +21,7 @@ S = "${WORKDIR}/trunk"
> > #INITSCRIPT_PARAMS = "defaults 99"
> >
> > do_configure() {
> > - sed -i -e 's:PATH=${LINUX_DEVKIT_PATH}/arm-none-linux-
> gnueabi:PATH ?= ${LINUX_DEVKIT_PATH}/arm-none-linux-gnueabi:'
> makefile.init
> > + sed -i -e 's:PATH=${LINUX_DEVKIT_PATH}/arm-arago-linux-
> gnueabi:PATH ?= ${LINUX_DEVKIT_PATH}/arm-arago-linux-gnueabi:'
> makefile.init
>
> I don't think this is needed. The whole point of that sed magic I put
> in
> there, is to make assignments of TUI_INCLUDE_PATH, XML_INCLUDE_PATH and
> TUI_LIB_PATH conditionally, so they can be overwritten below in the
> do_compile() task...
The makefile defaults have been changed to use arm-arago-linux-gnueabi instead
of the arm-none-linux-gnueabi. If you want these values to still be optionally
assigned then you would still need these changes right?
Now perhaps a better way to do this is change the makefile.init to use the ?=
optional assignment so that you don't need to do this sed magic. Would that
also work?
>
>
> > sed -i -e 's|LIBS :=|LIBS := ${LDFLAGS} |' Release/objects.mk
> > }
> >
> > @@ -39,11 +32,12 @@ do_compile() {
> > export TUI_INCLUDE_PATH=${STAGING_INCDIR}
> > export XML_INCLUDE_PATH=${STAGING_INCDIR}/libxml2
> > export TUI_LIB_PATH=${STAGING_LIBDIR}
> > + export PLATFORM=${MACHINE}
> > make release
> > }
> >
> > do_install() {
> > - export PLATFORM=${PLATFORM}
> > + export PLATFORM=${MACHINE}
> > make DESTDIR=${D} install
> > install -d ${D}${sysconfdir}/init.d/
> > install -c -m 0755 ${WORKDIR}/init
> ${D}${sysconfdir}/init.d/matrix-tui
> > diff --git a/recipes/ti/matrix-tui_1.1.bb b/recipes/ti/matrix-
> tui_1.1.bb
> > index 9814d5f..7e95d62 100644
> > --- a/recipes/ti/matrix-tui_1.1.bb
> > +++ b/recipes/ti/matrix-tui_1.1.bb
> > @@ -1,4 +1,4 @@
> > require matrix-tui.inc
> >
> > -SRCREV = "37"
> > -PR = "${INC_PR}.4"
> > +SRCREV = "41"
> > +PR = "${INC_PR}.5"
> > --
> > 1.7.0.4
> >
> >
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> devel
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH v2 1/1] am-benchmarks: Remove platform dependencies
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Thursday, June 30, 2011 3:53 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCH v2 1/1] am-benchmarks: Remove platform
> dependencies
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 29-06-11 18:33, Jeff Lance wrote:
> > * Remove platform dependencies and use architecture dependencies
> instead
> > * Use OE BASE_PACKAGE_ARCH to determine architecture
> > * Update the SRCREV to revision 66
> > * Update the recipe revision to 1.3
> > * Removed INSANE_SKIP
> > NOTE - architecture dependency can be removed once CFLAGS can be
> passed into CCSv5 project makefile
> >
> > Signed-off-by: Jeff Lance
>
> Much better, thanks!
>
> Acked-by: Koen Kooi
NAK
My testing shows this sed command does not work the way it was intended. I
have given Jeff an updated command to submit another version of th patch.
>
> > ---
> > Updated in version 2:
> > Removed INSANE_SKIP directive
> > updated SRCREV from 65 to 66
> > used find-copies-harder to show differences with previous recipe
> > --
> > recipes/ti/am-benchmarks_1.3.bb | 33
> +
> > 1 files changed, 33 insertions(+), 0 deletions(-)
> > create mode 100644 recipes/ti/am-benchmarks_1.3.bb
> >
> > diff --git a/recipes/ti/am-benchmarks_1.3.bb b/recipes/ti/am-
> benchmarks_1.3.bb
> > new file mode 100644
> > index 000..8ac9b74
> > --- /dev/null
> > +++ b/recipes/ti/am-benchmarks_1.3.bb
> > @@ -0,0 +1,33 @@
> > +#NOTE: This package is currently only supported for the Angstrom
> > +# distribution. Other distributions and toolchains may or
> > +# may not work.
> > +
> > +DESCRIPTION = "AM Benchmarks"
> > +HOMEPAGE = "https://gforge.ti.com/gf/project/am_benchmarks/";
> > +LICENSE = "BSD"
> > +SECTION = "system"
> > +PRIORITY = "optional"
> > +
> > +SRCREV = "66"
> > +PR = "r2+svnr${SRCPV}"
> > +
> > +SRC_URI =
> "svn://gforge.ti.com/svn/am_benchmarks/;module=trunk;proto=https;user=a
> nonymous;pswd=''"
> > +
> > +S = "${WORKDIR}/trunk"
> > +
> > +do_configure() {
> > +sed -i -e 's|LIBS :=|LIBS := ${LDFLAGS} |'
> Release/objects.mk
> > +}
> > +
> > +do_compile() {
> > + # don't build debug version
> > + touch debug
> > + export CROSS_COMPILE=${TARGET_PREFIX}
> > + export ARCH=${BASE_PACKAGE_ARCH}
> > + make release
> > +}
> > +
> > +do_install() {
> > + export ARCH=${BASE_PACKAGE_ARCH}
> > + make DESTDIR=${D} install
> > +}
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFODDlvMkyGM64RGpERAkG8AJ4nj8TWYoY89u9XJHPiw13adfgeGACgp69I
> UxVJuBlADDqibDEyEAUuBcE=
> =yCEc
> -END PGP SIGNATURE-
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH v3 1/1] am-benchmarks: Remove platform dependencies
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Jeff Lance
> Sent: Thursday, June 30, 2011 8:38 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Lance, Jeff
> Subject: [oe] [PATCH v3 1/1] am-benchmarks: Remove platform
> dependencies
>
> * Remove platform dependencies and use architecture dependencies
> instead
> * Use OE BASE_PACKAGE_ARCH to determine architecture
> * Update the SRCREV to revision 66
> * Update the recipe revision to 1.3
> * Removed INSANE_SKIP
> NOTE - architecture dependency can be removed once CFLAGS can be passed
> into CCSv5 project makefile
>
> Signed-off-by: Jeff Lance
Acked-by: Chase Maupin
> ---
> Update in version 3:
> Fix "sed" commands to apply to all dhrystone projects
> ---
> .../{am-benchmarks_1.2.bb => am-benchmarks_1.3.bb} | 27 ++--
> ---
> 1 files changed, 14 insertions(+), 13 deletions(-)
> copy recipes/ti/{am-benchmarks_1.2.bb => am-benchmarks_1.3.bb} (61%)
>
> diff --git a/recipes/ti/am-benchmarks_1.2.bb b/recipes/ti/am-
> benchmarks_1.3.bb
> similarity index 61%
> copy from recipes/ti/am-benchmarks_1.2.bb
> copy to recipes/ti/am-benchmarks_1.3.bb
> index 21e62a7..6070fe8 100644
> --- a/recipes/ti/am-benchmarks_1.2.bb
> +++ b/recipes/ti/am-benchmarks_1.3.bb
> @@ -8,30 +8,31 @@ LICENSE = "BSD"
> SECTION = "system"
> PRIORITY = "optional"
>
> -SRCREV = "61"
> +SRCREV = "66"
> PR = "r2+svnr${SRCPV}"
>
> -COMPATIBLE_MACHINE = "(dm365|omapl138|omap3|ti816x|ti814x)"
> -
> -ARCHITECTURE_dm365 = "arm9"
> -ARCHITECTURE_omapl138 = "arm9"
> -ARCHITECTURE_omap3 = "cortex-a8"
> -ARCHITECTURE_ti816x = "cortex-a8"
> -ARCHITECTURE_ti814x = "cortex-a8"
> -
> -INSANE_SKIP_${PN} = "True"
> -
> SRC_URI =
> "svn://gforge.ti.com/svn/am_benchmarks/;module=trunk;proto=https;user=a
> nonymous;pswd=''"
>
> -S = "${WORKDIR}/trunk/${ARCHITECTURE}"
> +S = "${WORKDIR}/trunk"
> +
> +do_configure() {
> +# Find all the objects.mk files for the Release target
> +files=`find ${BASE_PACKAGE_ARCH} -name "objects.mk" | grep
> Release`
> +for f in $files
> +do
> +sed -i -e 's|LIBS :=|LIBS := ${LDFLAGS} |' $f
> +done
> +}
>
> do_compile() {
> # don't build debug version
> touch debug
> export CROSS_COMPILE=${TARGET_PREFIX}
> - make release
> + export ARCH=${BASE_PACKAGE_ARCH}
> + make release
> }
>
> do_install() {
> + export ARCH=${BASE_PACKAGE_ARCH}
> make DESTDIR=${D} install
> }
> --
> 1.7.0.4
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/1] matrix-gui: Update SRCREV to revision 292
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Jeff Lance
> Sent: Friday, July 01, 2011 1:30 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Lance, Jeff
> Subject: [oe] [PATCH 1/1] matrix-gui: Update SRCREV to revision 292
>
> * Fix Soft AP scipt
> * Fix Multimedia descriptions
>
> Signed-off-by: Jeff Lance
Acked-by: Chase Maupin
> ---
> recipes/ti/matrix-gui-common_1.4.bb |4 ++--
> recipes/ti/matrix-gui-e_1.3.bb |4 ++--
> recipes/ti/matrix-gui_1.3.bb|4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/recipes/ti/matrix-gui-common_1.4.bb b/recipes/ti/matrix-
> gui-common_1.4.bb
> index 8376e17..1f2db79 100644
> --- a/recipes/ti/matrix-gui-common_1.4.bb
> +++ b/recipes/ti/matrix-gui-common_1.4.bb
> @@ -4,5 +4,5 @@ require matrix-gui-common.inc
> # prebuilt version in the repository.
> RRECOMMENDS_${PN} = "am-sysinfo"
>
> -SRCREV = "290"
> -PR = "${INC_PR}.14"
> +SRCREV = "292"
> +PR = "${INC_PR}.15"
> diff --git a/recipes/ti/matrix-gui-e_1.3.bb b/recipes/ti/matrix-gui-
> e_1.3.bb
> index dcad1a6..73e6d63 100644
> --- a/recipes/ti/matrix-gui-e_1.3.bb
> +++ b/recipes/ti/matrix-gui-e_1.3.bb
> @@ -1,5 +1,5 @@
> require matrix-gui-e.inc
>
> -SRCREV = "290"
> -PR = "${INC_PR}.13"
> +SRCREV = "292"
> +PR = "${INC_PR}.14"
>
> diff --git a/recipes/ti/matrix-gui_1.3.bb b/recipes/ti/matrix-
> gui_1.3.bb
> index e67115c..d9b4895 100644
> --- a/recipes/ti/matrix-gui_1.3.bb
> +++ b/recipes/ti/matrix-gui_1.3.bb
> @@ -1,4 +1,4 @@
> require matrix-gui.inc
>
> -SRCREV = "290"
> -PR = "${INC_PR}.9"
> +SRCREV = "292"
> +PR = "${INC_PR}.10"
> --
> 1.7.0.4
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] ti-wifi-utils: fix unaligned data access
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Eyal Reizer
> Sent: Monday, July 04, 2011 7:57 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] [PATCH] ti-wifi-utils: fix unaligned data access
>
> update the recipe to use a new commit from upstream which fixes
> unaligned
> data access errors reported when using the calibrator tool on an am180x
> (armv5) platform
>
> Signed-off-by: Eyal Reizer
Acked-by: Chase Maupin
> ---
> recipes/ti/ti-wifi-utils_git.bb |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes/ti/ti-wifi-utils_git.bb b/recipes/ti/ti-wifi-
> utils_git.bb
> index 9855775..87ca2c9 100644
> --- a/recipes/ti/ti-wifi-utils_git.bb
> +++ b/recipes/ti/ti-wifi-utils_git.bb
> @@ -3,11 +3,11 @@ LICENSE = "TI-BSD"
>
> DEPENDS = "libnl"
>
> -PR ="r3"
> +PR ="r4"
> PV ="0.0"
> PR_append = "+gitr${SRCPV}"
>
> -SRCREV = "268dbf03091b632c2697eb8028e90fe40513a9d8"
> +SRCREV = "8737db9372e714e265d3f575573d14c3379ab9fc"
> SRC_URI = "git://github.com/gxk/ti-utils.git;protocol=git"
>
> S = "${WORKDIR}/git"
> --
> 1.7.0.4
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/1] distribute_license: added class to copy license files
> -Original Message-
> From: Bernhard Reutner-Fischer [mailto:rep.dot@gmail.com]
> Sent: Thursday, July 29, 2010 3:55 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: Re: [oe] [PATCH 1/1] distribute_license: added class to copy
> license files
>
> On Thu, Jul 29, 2010 at 09:51:01AM -0500, Chase Maupin wrote:
> >* This class can be used to copy license files from package
> > sources into the deploy directory so they can be distributed.
> >* By default it searches the top-level source directory for
> > files matching COPYING* or LICENSE*
> >* Search depth and pattern can be modified using the
> > LICENSE_SEARCH_DEPTH and LICENSE_FILES variables
> > respectively.
> >
> >Signed-off-by: Chase Maupin
> >---
> > classes/distribute_license.bbclass | 56
>
> > 1 files changed, 56 insertions(+), 0 deletions(-)
> > create mode 100644 classes/distribute_license.bbclass
> >
> >diff --git a/classes/distribute_license.bbclass
> b/classes/distribute_license.bbclass
> >new file mode 100644
> >index 000..795a404
> >--- /dev/null
> >+++ b/classes/distribute_license.bbclass
> >@@ -0,0 +1,56 @@
> >+# distribute-license.bbclass will search the sources of a package to
> >+# a given depth looking for a match to the specified pattern and if
> >+# found will copy the matching file(s) to the deploy directory.
> >+#
> >+# This class is used to collect license files such as COPYING or
> >+# LICENSE where they are found and save them per package.
> >+#
> >+# This package uses the following variables to control its operations:
> >+# - LICENSE_FILES = Pattern of license files to be searched
> for.
> >+# By default this is COPYING* and LICENSE*
> but
> >+# this can be changed per package.
> >+# - LICENSE_SEARCH_DEPTH = The maximum depth to search in the package
> >+# sources for files matching the
> LICENSE_FILES
> >+# pattern.
> >+
> >+
> >+# Files to copy for the licensing. By default this is looking for
> >+# files following the patters COPYING* or LICENSING* in the top
> >+# level sources directory.
> >+LICENSE_FILES ?= "COPYING* LICENSE*"
> >+
> >+# Maximum depth to look for license files
> >+LICENSE_SEARCH_DEPTH ?= "1"
> >+
> >+distribute_license_do_copy_license() {
> >+# Change directory to source directory
> >+cd ${S}
> >+
> >+# Turn of globbing so that wildcards are not expanded in for loop
>
> /s/of/off/
I'll update this
>
> >+set -f
>
> hush: set: -f: invalid option
I thought bash was the standard shell for working with OE. Is that wrong?
>
> >+
> >+# Check if LICENSE_FILES exist. If so copy them to DEPLOY_DIR
> >+for lic in ${LICENSE_FILES}
> >+do
> >+res=""
>
> superfluous
True, I'll go ahead and remove it.
>
> >+res=`find . -maxdepth ${LICENSE_SEARCH_DEPTH} -name "$lic"`
> >+if [ "$res" != "" ]
>
> breaks on older test(1) impls that don't handle empty strings properly.
> Could be that this one is moot by now though.
So did this break for you? I've never seen this issue.
>
> >+then
> >+mkdir -p ${DEPLOY_DIR}/licenses/${PN}
> >+cp $res ${DEPLOY_DIR}/licenses/${PN}
>
> install -D ${DEPLOY_DIR}/licenses/${PN} ${DEPLOY_DIR}/licenses/${PN}
I'll change this
>
> >+fi
> >+done
> >+
> >+# Turn globbing back on
> >+set +f
>
> hush: set: +f: invalid option
Same question as above
>
> >+
> >+# Just to be clean change directory back to where we started from.
> >+cd -
> >+}
>
> What's the reason you don't do that in python instead?
> Just curious as it would save quite some potential hazzle..
I know shell and not python, it's as simple as that. If you want to rewrite
this in python with the same functionality that's OK with me :)
>
> >+
> >+EXPORT_FUNCTIONS do_copy_license
> >+
> >+# Put after do_patch in case a patch adds the license files
> >+do_copy_license[deptask] = "do_patch"
> >+
> >+addtask copy_license after do_patch before do_configure
> >--
> >1.7.0.4
>
> someone should bump git to 1.7.2, a BBCLASSEXTENDEDed version seems to
> work for me ...
Sorry, I don't understand what my git version has to do with BBCLASSEXTEND.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] base.bbclass: add support for SOC_FAMILY in COMPATIBLE_MACHINES
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Phil Blundell > Sent: Wednesday, August 04, 2010 6:49 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] base.bbclass: add support for SOC_FAMILY in > COMPATIBLE_MACHINES > > On Wed, 2010-08-04 at 13:17 +0200, Michael 'Mickey' Lauer wrote: > > FWIW, minimal is using MACHINE_CLASS since quite a while to > > reduce the need for adding the same files over and over again, > > this is being used e.g. for HTC msm7 series and OpenEZX series > > (see conf/machine/include). > > > > Perhaps it's time to standardize something like that. > > Yeah. I certainly don't think we want a proliferation of such > mechanisms. If minimal is already using MACHINE_CLASS then there would > be some sense in trying to make use of the same thing. minimal doesn't use MACHINE_CLASS. Perhaps this is getting confused with distro/micro.conf. > > My preference would be to make the MACHINEs in question be, for example, > "motorola-ezx-a1200", "motorola-ezx-a780" and so on. This would then > allow you to set COMPATIBLE_MACHINE = "motorola-ezx-.*" which I think > would solve the SOC_FAMILY problem, although it wouldn't replace > MACHINE_CLASS in OVERRIDES. Unfortunately we can't change the MACHINE names. They are set to correspond to the real device names and part numbers. > > Failing that though, testing COMPATIBLE_MACHINE against MACHINE_CLASS > probably is more desirable than adding a completely new variable (i.e. > SOC_FAMILY) for that purpose. >From what I've learned it seems that MACHINE_CLASS and SOC_FAMILY are >different in what they are trying to accomplish. SOC_FAMILY is defining a family of processors and the features that processor has. Whereas MACHINE_CLASS is defining a type of device and its features which can use different processors. So basically SOC_FAMILY defines common processors and MACHINE_CLASS defines common end devices. This difference is why SOC_FAMILY exists. We can have many processors that fit into an SOC_FAMILY that can be used across a variety of end applications from DVR to ip net camera to mobile phone. > > p. > > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] base.bbclass: add support for SOC_FAMILY in COMPATIBLE_MACHINES
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Khem Raj > Sent: Wednesday, August 04, 2010 2:49 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] base.bbclass: add support for SOC_FAMILY in > COMPATIBLE_MACHINES > > On Wed, Aug 4, 2010 at 2:54 AM, Phil Blundell wrote: > > On Tue, 2010-08-03 at 16:47 -0500, Chase Maupin wrote: > >> * Add support for using SOC_FAMILY in the COMPATIBLE_MACHINES > >> setting for a recipe. > >> * This will allow recipes to work for entire families of > >> devices without having to maintain/update the compatible > >> devices as new devices are added into a family > > > > I don't suppose you'd consider refactoring your MACHINE names in order > > to allow a simple regex in COMPATIBLE_MACHINE? > > that would be a good approach too. Has it been > considered. As I mentioned before, we are matching the machine names to the name of the actual device. Unfortunately, not every device that falls into an SOC family has a similar name and cannot all be dictated by us. For example in omap3 SOC_FAMILY there is: beagleboard omap3evm nokia900 dm37x-evm archos5 bug20 and many many more. These machines are defined by a variety of companies, some from TI, some community, Nokia, Archos, etc. I don't think it is likely that we will get agreement on the naming between all the groups. I know that just within TI the naming is driven by marketing names for the devices. > > I don't have a strong > > objection to this patch but, conceptually, it seems a bit ugly. > > > > > > > p. > > > > > > > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] jpeg_8b: Allow using older versions of automake
Khem,
I'd be happy to make the patch but in this case the resulting differences in
configure appear to be just changes to line numbers in the script because my
patch caused a new comment line to be inserted. I'm not sure if this patch to
configure would add anything but clutter. However, if you still want it I'll
add it to the patch and resend. The changes to configure would be (and sorry
for any outlook mangling):
diff -burpN orig/configure new/configure
--- orig/configure 2010-08-30 08:03:01.485893044 -0500
+++ new/configure 2010-08-30 08:08:57.961780786 -0500
@@ -2950,6 +2950,7 @@ am__tar='${AMTAR} chof - "$$tardir"'; am
# Make --enable-silent-rules the default.
# To get verbose build output you may configure
# with --disable-silent-rules or use "make V=1".
+# only use if available
# Check whether --enable-silent-rules was given.
if test "${enable_silent_rules+set}" = set; then :
enableval=$enable_silent_rules;
@@ -6950,13 +6951,13 @@ if test "${lt_cv_nm_interface+set}" = se
else
lt_cv_nm_interface="BSD nm"
echo "int some_variable = 0;" > conftest.$ac_ext
- (eval echo "\"\$as_me:6953: $ac_compile\"" >&5)
+ (eval echo "\"\$as_me:6954: $ac_compile\"" >&5)
(eval "$ac_compile" 2>conftest.err)
cat conftest.err >&5
- (eval echo "\"\$as_me:6956: $NM \\\"conftest.$ac_objext\\\"\"" >&5)
+ (eval echo "\"\$as_me:6957: $NM \\\"conftest.$ac_objext\\\"\"" >&5)
(eval "$NM \"conftest.$ac_objext\"" 2>conftest.err > conftest.out)
cat conftest.err >&5
- (eval echo "\"\$as_me:6959: output\"" >&5)
+ (eval echo "\"\$as_me:6960: output\"" >&5)
cat conftest.out >&5
if $GREP 'External.*some_variable' conftest.out > /dev/null; then
lt_cv_nm_interface="MS dumpbin"
@@ -8147,7 +8148,7 @@ ia64-*-hpux*)
;;
*-*-irix6*)
# Find out which ABI we are using.
- echo '#line 8150 "configure"' > conftest.$ac_ext
+ echo '#line 8151 "configure"' > conftest.$ac_ext
if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
(eval $ac_compile) 2>&5
ac_status=$?
@@ -9404,11 +9405,11 @@ else
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:9407: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:9408: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:9411: \$? = $ac_status" >&5
+ echo "$as_me:9412: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
@@ -9743,11 +9744,11 @@ else
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:9746: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:9747: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:9750: \$? = $ac_status" >&5
+ echo "$as_me:9751: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
@@ -9848,11 +9849,11 @@ else
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:9851: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:9852: $lt_compile\"" >&5)
(eval "$lt_compile" 2>out/conftest.err)
ac_status=$?
cat out/conftest.err >&5
- echo "$as_me:9855: \$? = $ac_status" >&5
+ echo "$as_me:9856: \$? = $ac_status" >&5
if (exit $ac_status) && test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
@@ -9903,11 +9904,11 @@ else
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:9906: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:9907: $lt_compile\"" >&5)
(eval "$lt_compile" 2>out/conftest.err)
ac_status=$?
cat out/conftest.err >&5
- echo "$as_me:9910: \$? = $ac_status" >&5
+ echo "$as_me:9911: \$? = $ac_status" >&5
if (exit $ac_status) && test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
@@ -12270,7 +12271,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 12273 "configure"
+#line 12274 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -12366,7 +12367,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 12369 "configure"
+#line 12370 "configure"
#include "co
Re: [oe] [PATCH] matrix-tui: add dependency on ncurses and zlib
Please ignore this patch. I didn't realize Denys had already pushed one.
Sincerely,
Chase Maupin
Software Applications
Catalog DSP Products
e-mail: chase.mau...@ti.com
phone: (281) 274-3285
For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Monday, August 30, 2010 2:39 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: [PATCH] matrix-tui: add dependency on ncurses and zlib
>
> * The matrix-tui application depends on the ncurses libraries
> and header files during build time.
> * The matrix-tui application depends on the zlib libraries
> and header files during build time.
> * Add ncurses and zlib to the DEPENDS list for matrix-tui
>
> Signed-off-by: Chase Maupin
> ---
> recipes/ti/matrix-tui_svn.bb |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes/ti/matrix-tui_svn.bb b/recipes/ti/matrix-tui_svn.bb
> index 13ec5c5..1e4f7ea 100644
> --- a/recipes/ti/matrix-tui_svn.bb
> +++ b/recipes/ti/matrix-tui_svn.bb
> @@ -3,11 +3,11 @@ HOMEPAGE =
> "https://gforge.ti.com/gf/project/matrix_tui/";
> LICENSE = "BSD"
> SECTION = "multimedia"
> PRIORITY = "optional"
> -DEPENDS = "libxml2"
> +DEPENDS = "libxml2 ncurses zlib"
>
> SRCREV = "29"
> PV = "1.0"
> -PR = "r2+svnr${SRCPV}"
> +PR = "r3+svnr${SRCPV}"
>
> INSANE_SKIP_${PN} = "True"
>
> --
> 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] SOC_FAMILY broken
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Frans Meulenbroeks
> Sent: Wednesday, September 01, 2010 4:15 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] SOC_FAMILY broken
>
> Patch
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=07076390358f
> 211bd96779bec2d6eb5eaa0ad699
> creates errors like:
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime
> entity 'virtual/arm-oe-linux-gnueabi-gcc-2.95' but it wasn't found in
> any PACKAGE or RPROVIDES variables
>
> Root cause: if SOC_FAMILY is not set (awhich is the case for most
> MACHINEs and all distro's except angstrom) the test in base.bbclass
> to skip recipes for different machines never raises the SkipPackage
> exception.
>
> This is the current code (about line 387 in base.bbclass):
> need_machine = bb.data.getVar('COMPATIBLE_MACHINE', d, 1)
> if need_machine:
> import re
> this_machine = bb.data.getVar('MACHINE', d, 1)
> if this_machine and not re.match(need_machine, this_machine):
> this_soc_family = bb.data.getVar('SOC_FAMILY', d, 1)
> if this_soc_family and not re.match(need_machine,
> this_soc_family):
> raise bb.parse.SkipPackage("incompatible with
> machine %s" % this_machine)
>
> I see two possible fixes.
> 1. Make sure SOC_FAMILY is always defined. E.g. in bitbake.conf say
> SOC_FAMILY ?= "Unknown"
> 2. improve the test to deal with an undefined soc_famile
> E.g rewrite the one but last line to:
> if (this_soc_family and not re.match(need_machine,
> this_soc_family)) or not this_soc_family:
>
> I tested the 2nd patch with distro minimal, target sheevaplug, which
> gave the error before. After rewriting the line as suggested skipping
> works and the problem is gone.
> I have this also as a formal patch, but there might be more desirable
> ways to do this.
>
> Please advise.
I like your second proposal. Thanks for finding this issue and a solution to
it.
>
> Frans.
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] SOC_FAMILY broken
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Leon Woestenberg > Sent: Wednesday, September 01, 2010 4:23 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] SOC_FAMILY broken > > Hello, > > On Wed, Sep 1, 2010 at 11:14 PM, Frans Meulenbroeks > wrote: > > Root cause: if SOC_FAMILY is not set (awhich is the case for most > > MACHINEs and all distro's except angstrom) the test in base.bbclass > > > > Good point, but I never understood SOC_FAMILY. From an old email: > > "SOC_FAMILY is defining a family of processors and the features that > processor > has. Whereas MACHINE_CLASS is defining a type of device and its features > which > can use different processors." > > I think the first sentence is contradicting itself. > > A "family of processors" vs. "features that processor had". This can > be fully orthogonal (worst case), > so the definition of the variable is crap. I wonder, has it proven > more useful than cumbersome? What this is saying is the SOC_FAMILY defines a family of processors that all share common features, i.e. the OMAP3 family. These processors will agree on many things such as kernel recipes, bootloaders, etc. However, they will also have some differences such as whether they support wireless, etc. Thus they have separate machine types but share an SOC_FAMILY type. This way we do not need to specify overrides for every omap3 machine type of which a rough count shows there to be 19. My understanding of MACHINE_CLASS on the other hand is that this is to group devices by the type of end product being made. i.e. a cell phone vs a hand-held media player. In this case you could have very different processors for these devices, but they all agree on the features that the device has in common. There was a discussion about this previously in which Graeme said: "As the person who originally added MACHINE_CLASS to openmoko and the OE, then removed it from OE I can say it has different meaning that SOC_FAMILY. MACHINE_CLASS was to identify a range of machines that were 90% the same but had a few differences. It was used in a few recipes which were MACHINE_ARCH to make them use the same ARCH in these recipes to stop them being rebuilt when switching machines." I hope this answers your questions. I didn't add the SOC_FAMILY but I can tell you that I use it quite a lot. It looks to me that the micro, shr, and minimal distros still have MACHINE_CLASS in their overrides, and that the htc-msm7, motorola-ezx-base, and htc-qsd8 devices actually define a machine type. The htc-msm7 and htc-qsd9 machine classes do not appear to be used in the OE mainline (but perhaps in someone's overlay) The motorola-ezx machine class is used in pulseaudio to set the default preference to -1. Again, thanks for finding and fixing this issue. > > If it truly has a clear function in OpenEmbedded that can apply to all > processors, can someone explain what the variable should be set to? > > > Regards, > -- > Leon > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] git issues
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Gary Thomas > Sent: Thursday, September 02, 2010 8:23 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] git issues > > On 09/02/2010 06:59 AM, Frans Meulenbroeks wrote: > > For some reason recently every once in a while on a git pull or git > > clone I get an error like this: > > > > git clone git://git.openembedded.net/openembedded openembedded > > Initialized empty Git repository in > > /home/frans/workspace/Linux/openembedded-test/openembedded/.git/ > > fatal: The remote end hung up unexpectedly > > make: *** [all] Error 128 > > > > Repeating the command often makes it work. > > > > Also I notice that the transfer rate is about 100-120 KB/s > > I seem to recall Leon also reported something like this with irc. > > > > Is this something others see as well? > > Especially the hangup does not really help to set up an automated test > system. > > I've seen this on a number of sites, not just OE. As you say, trying > again makes it happy. > > I think it's a generic GIT problem (at least that's my experience) > I've been noticing this only with openembedded so far. I'm not sure about the transfer rate issue but I have had my git pull fail the first time and succeed the second time. > -- > > Gary Thomas | Consulting for the > MLB Associates |Embedded world > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] How to extend SRC_URI_append?
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Jean-Christophe PLAGNIOL-VILLARD
> Sent: Friday, September 03, 2010 11:59 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] How to extend SRC_URI_append?
>
> On 18:47 Fri 03 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 07:44 Fri 03 Sep , Chris Larson wrote:
> > > The append syntax you're referring to uses OVERRIDES. FOO_somevalue
> > > replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is
> added to
> > > FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in
> overrides
> > > at this time.
> > how can I extend it?
> is this ok?
>
> diff --git a/conf/bitbake.conf b/conf/bitbake.conf
> index 677c76a..ecdf245 100644
> --- a/conf/bitbake.conf
> +++ b/conf/bitbake.conf
> @@ -677,9 +677,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS"
> #
> # This works for functions as well, they are really just environment
> variables.
> # Default OVERRIDES to make compilation fail fast in case of build system
> misconfiguration.
> -OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-
> ${BUILD_OS}:fail-fast:pn-${PN}"
> +OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA
> RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}"
> # Alternative OVERRIDES definition without "fail fast", usually only for
> native building and Scratchbox toolchains.
> -#OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-
> ${BUILD_OS}:pn-${PN}"
> +#OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA
> RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:pn-${PN}"
>
> ##
> # Include the rest of the config files.
>
> Best Regards,
> J.
Is there really a case for a ${TARGET_ARCH}_${SOC_FAMILY} override. If these
devices have different architectures are they really part of the same family?
As for adding this to bitbake.conf I guess I wouldn't object, but I don't know
that this is something everyone would want. Instead you could put this in your
distro's conf file (like angstrom does) or in your local.conf file.
The distro/include/angstrom.inc file sets:
OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}"
I use SOC_FAMILY overrides in my work.
Just my two cents
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Frans Meulenbroeks
> Sent: Saturday, September 04, 2010 3:20 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make
> it global
>
> 2010/9/4 Frans Meulenbroeks :
> > 2010/9/4 Jean-Christophe PLAGNIOL-VILLARD :
> >> add global OVERRIDES ${TARGET_SOC_FAMILY} and
> ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
> >>
> >
> > What is the rationale for this?
> > And why not fix the problem there is in base.bbclass as well.
> >
> > Frans.
> >
> Forgot about this, but a variable should go with documentation.
> This already has been raised with the orginal patch, but was ignored
> by the submitters.
Frans, Are you counting me as one of the original submitters? I mainly use the
SOC_FAMILY, I didn't create it. That being said, if you have a recommended
section of the usermanual that this should be documented in I'll try to add
something.
>
> Consider this a NAK.
>
> Frans
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
> add global OVERRIDES ${TARGET_SOC_FAMILY} and
> ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
>
For my part I would ask why you are renaming SOC_FAMILY to TARGET_SOC_FAMILY?
Why not leave the name the way it is since others may be using it in overlays,
etc?
Also, you might want to make sure your patch would include Fran's fix to
base.bbclass that he mentioned at
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/023680.html
For what my input is worth I would NAK this patch because:
1. I don't see a reason to add this to the generic set of overrides.
2. I don't understand why the name of the variable SOC_FAMILY needs to be
changed. I know this will break existing overlays and I don't see any reason
why the change is made.
3. I disagree with the ${TARGET_ARCH}_${TARGET_SOC_FAMILY} override. If you
have two patch series for different architectures then you should have two
SOC_FAMILY settings or use the MACHINE setting for the override. I think this
override is confusing and redundant.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCHv2] common_use_cases: add description of SOC_FAMILY
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Paul Menzel > Sent: Wednesday, September 08, 2010 4:48 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCHv2] common_use_cases: add description of > SOC_FAMILY > > Am Mittwoch, den 08.09.2010, 13:03 -0500 schrieb Chase Maupin: > > * Added a description of the SOC_FAMILY variable that > > can be set in the machine configuration files. > > > > Signed-off-by: Chase Maupin > > --- > > docs/usermanual/chapters/common_use_cases.xml | 24 > > > 1 files changed, 24 insertions(+), 0 deletions(-) > > > > diff --git a/docs/usermanual/chapters/common_use_cases.xml > b/docs/usermanual/chapters/common_use_cases.xml > > index d86d0ca..ef81b95 100644 > > --- a/docs/usermanual/chapters/common_use_cases.xml > > +++ b/docs/usermanual/chapters/common_use_cases.xml > > @@ -94,6 +94,30 @@ SRCDATE = "20061014" > > > > > > > > +There are also some optional variables that can be defined: > > + > > + > > + SOC_FAMILY describes a family of > processors > > +that all share common features such as kernel versions, > > +bootloaders, etc. This is used to allow overrides for a > whole > > I think a full stop is required even if there is an abbreviation in > front of it. → etc.. Paul, I'm afraid I don't understand what you are asking to have fixed. Are you saying you want it to be etc.. instead of etc. Just want to clarify before I remake this patch. > > […] > > With this fixed: > > Acked-by: Paul Menzel > > > Thanks for improving the documentation, > > Paul ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] base.bbclass: fix soc-family test
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Frans Meulenbroeks
> Sent: Thursday, September 09, 2010 2:11 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCH] base.bbclass: fix soc-family test
>
> 2010/9/2 Frans Meulenbroeks :
> > see http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-
> September/023680.html
> >
> > Signed-off-by: Frans Meulenbroeks
> > ---
> > classes/base.bbclass | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/classes/base.bbclass b/classes/base.bbclass
> > index 299e875..2c9ad89 100644
> > --- a/classes/base.bbclass
> > +++ b/classes/base.bbclass
> > @@ -337,7 +337,7 @@ python () {
> > this_machine = bb.data.getVar('MACHINE', d, 1)
> > if this_machine and not re.match(need_machine,
> this_machine):
> > this_soc_family = bb.data.getVar('SOC_FAMILY', d, 1)
> > - if this_soc_family and not re.match(need_machine,
> this_soc_family):
> > + if (this_soc_family and not re.match(need_machine,
> this_soc_family)) or not this_soc_family:
> > raise bb.parse.SkipPackage("incompatible with
> machine %s" % this_machine)
> >
> > need_target = bb.data.getVar('COMPATIBLE_TARGET_SYS', d, 1)
> > --
> > 1.6.4.2
> >
>
> Bump.
>
> This is out for a week now without any feedback, although the patch is
> quite trivial.
Frans,
I'm pretty sure I already gave my feedback on this fix. If not then I think it
looks fine to me and thank you for finding and fixing this issue.
>
> Actually I am quite disappointed by the developers who created and
> pushed the SOC_FAMILY patch.
> They were very eager to push this change in a day, without waiting for
> the discussion on it to conclude, but they seem to be not-so-willing
> to review a fix for a problem they caused (let alone resolve the
> problem). What is even somewhat irritating is that one of the people
> involved is often in the front seat when it comes to criticizing
> others if they make a mistake.
>
> Frans.
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] base.bbclass: fix soc-family test
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Frans Meulenbroeks
> Sent: Thursday, September 09, 2010 5:12 AM
> To: openembedded-devel@lists.openembedded.org; t...@openembedded.org
> Subject: Re: [oe] [PATCH] base.bbclass: fix soc-family test
>
> 2010/9/9 Phil Blundell :
> > On Thu, 2010-09-09 at 09:11 +0200, Frans Meulenbroeks wrote:
> >> 2010/9/2 Frans Meulenbroeks :
> >> > - if this_soc_family and not re.match(need_machine,
> this_soc_family):
> >> > + if (this_soc_family and not re.match(need_machine,
> this_soc_family)) or not this_soc_family:
> >> > raise bb.parse.SkipPackage("incompatible with
> machine %s" % this_machine)
> >
> > I am still far from convinced that this hunk of SOC_FAMILY code is
> > desirable to have in the first place but, if it's going to stay there,
> > clearly it should be fixed so that it doesn't cause problems for
> > non-users.
> >
> > So, yes, your patch looks fine to me.
> >
> > p.
> >
> Phil, thanks for the feedback.
>
> I'm not too sure on the usefulness of it either, but there is some
> breakage so we should either revert the patch or fix it.
>
> Actually the SOC_FAMILY got pushed before the review was concluded.
> Technically it got the ack's but the discussion was still ongoing when
> this was pushed.
> What also makes it fishy is that all acks are from the same company
> (which is the same one as the person who submitted the patch):
>
> Signed-off-by: Chase Maupin
> Acked-by: Denys Dmytriyenko
> Acked-by: Koen Kooi
> Signed-off-by: Koen Kooi
>
> I would suggest modifying the commit policy disallowing these kind of
> things, saying the two Ack's must be from two developers not
> affiliated with the same company.
> (actually we might even want to take it further and saying that global
> changes that affect everyone would require ACK's from developers from
> more than one distro).
>
> Question to the TSC: should the SOC_FAMILY patch be reverted and put
> on hold until there is agreement whether or not we want this?
Frans,
As the person who submitted this change I'd like to ask that it not be
reverted. I am using it currently so that when defining COMPATIBLE_MACHINE for
recipes targeted at OMAP3 devices I do not have to keep a rolling list of all
the various OMAP3 devices. This can quickly become:
COMPATIBLE_MACHINE =
"dm37x-evm|am37x-evm|omap3evm|am3517-evm|beagleboard|.."
Instead by allowing SOC_FAMILY to be used as a COMPATIBLE_MACHINE this can be
handled cleanly with:
COMPATIBLE_MACHINE = "omap3"
Please consider this use case. I would much prefer if your fix was put into
the base.bbclass than if this were removed.
>
> Frans
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] base.bbclass: fix soc-family test
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Frans Meulenbroeks
> Sent: Thursday, September 09, 2010 2:11 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCH] base.bbclass: fix soc-family test
>
> 2010/9/2 Frans Meulenbroeks :
> > see http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-
> September/023680.html
> >
> > Signed-off-by: Frans Meulenbroeks
> > ---
> > classes/base.bbclass | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/classes/base.bbclass b/classes/base.bbclass
> > index 299e875..2c9ad89 100644
> > --- a/classes/base.bbclass
> > +++ b/classes/base.bbclass
> > @@ -337,7 +337,7 @@ python () {
> > this_machine = bb.data.getVar('MACHINE', d, 1)
> > if this_machine and not re.match(need_machine,
> this_machine):
> > this_soc_family = bb.data.getVar('SOC_FAMILY', d, 1)
> > - if this_soc_family and not re.match(need_machine,
> this_soc_family):
> > + if (this_soc_family and not re.match(need_machine,
> this_soc_family)) or not this_soc_family:
> > raise bb.parse.SkipPackage("incompatible with
> machine %s" % this_machine)
> >
> > need_target = bb.data.getVar('COMPATIBLE_TARGET_SYS', d, 1)
> > --
> > 1.6.4.2
> >
Acked-by: Chase Maupin
>
> Bump.
>
> This is out for a week now without any feedback, although the patch is
> quite trivial.
>
> Actually I am quite disappointed by the developers who created and
> pushed the SOC_FAMILY patch.
> They were very eager to push this change in a day, without waiting for
> the discussion on it to conclude, but they seem to be not-so-willing
> to review a fix for a problem they caused (let alone resolve the
> problem). What is even somewhat irritating is that one of the people
> involved is often in the front seat when it comes to criticizing
> others if they make a mistake.
>
> Frans.
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 2/2] ti-graphics-sdk: display full license during build
Bump
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Wednesday, September 01, 2010 1:15 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: [PATCH 2/2] ti-graphics-sdk: display full license during build
>
> * Change the TI_BIN_UNPK_CMDS to feed in enought spaces to
> display the entire EULA during the build process.
>
> Signed-off-by: Chase Maupin
> ---
> recipes/powervr-drivers/libgles-omap3.inc |7 +--
> .../omap3-sgx-modules_1.4.14.2514.bb |5 -
> .../omap3-sgx-modules_1.4.14.2616.bb |5 -
> 3 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/recipes/powervr-drivers/libgles-omap3.inc b/recipes/powervr-
> drivers/libgles-omap3.inc
> index 5b248b0..1c00708 100644
> --- a/recipes/powervr-drivers/libgles-omap3.inc
> +++ b/recipes/powervr-drivers/libgles-omap3.inc
> @@ -1,7 +1,7 @@
> DESCRIPTION = "libGLES for the omap3"
> LICENSE = "proprietary-binary"
>
> -PR = "r6"
> +PR = "r7"
>
> COMPATIBLE_MACHINE = "(dm37x-evm|am37x-evm|am3517-evm|beagleboard|cm-
> t35|igep0020|omap3-pandora|omap3-
> touchbook|omap3evm|omapzoom|omapzoom2|overo|palmpre)"
>
> @@ -37,7 +37,10 @@ SRC_URI =
> "http://install.source.dir.local/OMAP35x_Graphics_SDK_setuplinux_${SGX
> S = "${WORKDIR}/OMAP35x_Graphics_SDK_${SGXPV}"
>
> # Logic to unpack installjammer file
> -TI_BIN_UNPK_CMDS="Y: qY:workdir:Y"
> +# NOTE: It takes 16 spaces to display the full EULA. Too many spaces
> +# will cause the package to be installed into the wrong directory
> +# and you will see build failures. This EULA should not change.
> +TI_BIN_UNPK_CMDS="Y:qY:workdir:Y"
> require ../ti/ti-eula-unpack.inc
>
> BINLOCATION ?= "${S}/gfx_rel"
> diff --git a/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> b/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> index a2fcf22..350dc09 100644
> --- a/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> +++ b/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> @@ -7,7 +7,10 @@ PR_append = "a"
> # http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/3_01_00_02/index
> _FDS.html
> # see libgles-omap3.inc for detailed installation instructions
>
> -TI_BIN_UNPK_CMDS="Y: qY:workdir:Y"
> +# NOTE: It takes 16 spaces to display the full EULA. Too many spaces
> +# will cause the package to be installed into the wrong directory
> +# and you will see build failures. This EULA should not change.
> +TI_BIN_UNPK_CMDS="Y:qY:workdir:Y"
> require ../ti/ti-eula-unpack.inc
>
> SGXPV = "3_01_00_02"
> diff --git a/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> b/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> index 4ed2540..ba6e925 100644
> --- a/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> +++ b/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> @@ -7,7 +7,10 @@ PR_append = "c"
> # http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/3_01_00_06/index
> _FDS.html
> # see libgles-omap3.inc for detailed installation instructions
>
> -TI_BIN_UNPK_CMDS="Y: qY:workdir:Y"
> +# NOTE: It takes 16 spaces to display the full EULA. Too many spaces
> +# will cause the package to be installed into the wrong directory
> +# and you will see build failures. This EULA should not change.
> +TI_BIN_UNPK_CMDS="Y:qY:workdir:Y"
> require ../ti/ti-eula-unpack.inc
>
> SGXPV = "3_01_00_06"
> --
> 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/2] ti-graphics-sdk: Update download links
Bump
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Wednesday, September 01, 2010 1:15 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: [PATCH 1/2] ti-graphics-sdk: Update download links
>
> * Changed the download links to point to the specific version
> of the TI Graphics SDK installer rather than to just the
> latest.
> * The libgles-omap3.inc file still contains the link to the
> latest version of the installer.
>
> Signed-off-by: Chase Maupin
> ---
> recipes/powervr-drivers/libgles-omap3.inc |5 -
> .../powervr-drivers/libgles-omap3_3.01.00.02.bb|2 +-
> .../powervr-drivers/libgles-omap3_3.01.00.06.bb|2 +-
> .../omap3-sgx-modules_1.4.14.2514.bb |2 +-
> .../omap3-sgx-modules_1.4.14.2616.bb |2 +-
> 5 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/recipes/powervr-drivers/libgles-omap3.inc b/recipes/powervr-
> drivers/libgles-omap3.inc
> index d183486..5b248b0 100644
> --- a/recipes/powervr-drivers/libgles-omap3.inc
> +++ b/recipes/powervr-drivers/libgles-omap3.inc
> @@ -15,7 +15,10 @@ PROVIDES += "virtual/egl"
> # 1. if you don't already have a ti account get one here. it's free:
> # http://www.ti.com/hdr_my_ti
> # 2. fetch the gl-es bin (full OMAP Graphics SDK) from here:
> -# http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS
> .html
> +#Check the libgles recipe for your version to find the link to the
> +#download for that version. The following link will provide the
> +#latest version available.
> +#http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS
> .html
> # 3. put the OMAP35x_*.bin file in $DL_DIR, i.e. downloads/
> # mv OMAP35x_Graphics_SDK_setuplinux_3_01_00_06.bin ./downloads/
> # 4. make the checksum file in ./downloads/ directory:
> diff --git a/recipes/powervr-drivers/libgles-omap3_3.01.00.02.bb
> b/recipes/powervr-drivers/libgles-omap3_3.01.00.02.bb
> index 3b68c18..544fabf 100644
> --- a/recipes/powervr-drivers/libgles-omap3_3.01.00.02.bb
> +++ b/recipes/powervr-drivers/libgles-omap3_3.01.00.02.bb
> @@ -5,7 +5,7 @@ require libgles-omap3.inc
> PR = "r7"
>
> # download required binary distribution from:
> -# http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS
> .html
> +# http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/3_01_00_02/index
> _FDS.html
> # see libgles-omap3.inc for detailed installation instructions
>
> SGXPV = "3_01_00_02"
> diff --git a/recipes/powervr-drivers/libgles-omap3_3.01.00.06.bb
> b/recipes/powervr-drivers/libgles-omap3_3.01.00.06.bb
> index bb7994f..0d41a23 100644
> --- a/recipes/powervr-drivers/libgles-omap3_3.01.00.06.bb
> +++ b/recipes/powervr-drivers/libgles-omap3_3.01.00.06.bb
> @@ -7,7 +7,7 @@ ES5LOCATION = "${S}/gfx_rel_es5.x"
> require libgles-omap3.inc
>
> # download required binary distribution from:
> -# http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS
> .html
> +# http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/3_01_00_06/index
> _FDS.html
> # see libgles-omap3.inc for detailed installation instructions
>
> SGXPV = "3_01_00_06"
> diff --git a/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> b/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> index 6f6e073..a2fcf22 100644
> --- a/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> +++ b/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2514.bb
> @@ -4,7 +4,7 @@ LICENSE = "GPLv2"
> PR_append = "a"
>
> # download required binary distribution from:
> -# http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS
> .html
> +# http://software-
> dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/3_01_00_02/index
> _FDS.html
> # see libgles-omap3.inc for detailed installation instructions
>
> TI_BIN_UNPK_CMDS="Y: qY:workdir:Y"
> diff --git a/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> b/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> index 0d2818b..4ed2540 100644
> --- a/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> +++ b/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb
> @@ -4,7 +4,7 @@ LICENSE = "GPLv2"
> PR_append = "c"
>
> # download required binary distribution from:
> -# http://software-
> dl.ti.com/
Re: [oe] [PATCH] jpeg_8b: Allow using older versions of automake
Enricos change is on my list. I will resubmit this. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Denys Dmytriyenko > Sent: Friday, September 10, 2010 1:05 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] jpeg_8b: Allow using older versions of automake > > On Mon, Aug 30, 2010 at 08:24:30AM -0500, Maupin, Chase wrote: > > Khem, > > > > I'd be happy to make the patch but in this case the resulting > differences in > > configure appear to be just changes to line numbers in the script > because my > > patch caused a new comment line to be inserted. I'm not sure if this > patch > > to configure would add anything but clutter. However, if you still want > it > > I'll add it to the patch and resend. The changes to configure would be > (and > > sorry for any outlook mangling): > > Ping. > > While the patch is not required, but it's nice to have. I'd vote to apply > the > original version w/o changes to configure script, but with change proposed > by > Enrico. > > Acked-by: Denys Dmytriyenko > > -- > Denys > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCHv2] jpeg_8b: Allow using older versions of automake
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Paul Menzel
> Sent: Friday, September 10, 2010 2:52 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCHv2] jpeg_8b: Allow using older versions of
> automake
>
> Dear Chase,
>
>
> Am Freitag, den 10.09.2010, 15:20 -0400 schrieb Denys Dmytriyenko:
> > On Fri, Sep 10, 2010 at 01:02:20PM -0500, Chase Maupin wrote:
> > > From: Chase
>
> please set up Git on your laptop with the following command.
>
> git config user.name Chase Maupin
> git config user.email chasemaupi...@gmail.com
Paul,
I'm not sure how that From line got in this mail. My other patches don't have
it. I have my git config set for user.email chase.mau...@ti.com (even though I
send through a gmail account because I'm not trying to hide that these patches
are from someone at TI). The weird thing is that my laptop is my Windows PC
and I don't send patches from it. Perhaps this snuck in because I responded to
the thread from my Windows PC (outlook).
>
> > > * Added patch to allow using older versions of automake such
> > > as 1.10.3 when building jpeg version 8b.
> > > * Only use the AM_SILENT_RULES if it is available.
> > >
> > > Signed-off-by: Chase Maupin
> >
> > Acked-by: Denys Dmytriyenko
>
> To get the stats right, maybe the one who is pushing this can fix this
> up by deleting the From: line in the message body.
>
> Thanks,
>
> Paul
>
> > > ---
> > > ...igure-make-jpeg-work-with-older-autotools.patch | 30
>
> > > recipes/jpeg/jpeg_8b.bb|7 +++-
> > > 2 files changed, 35 insertions(+), 2 deletions(-)
> > > create mode 100644 recipes/jpeg/jpeg-8b/0001-configure-make-jpeg-
> work-with-older-autotools.patch
> > >
> > > diff --git a/recipes/jpeg/jpeg-8b/0001-configure-make-jpeg-work-with-
> older-autotools.patch b/recipes/jpeg/jpeg-8b/0001-configure-make-jpeg-
> work-with-older-autotools.patch
> > > new file mode 100644
> > > index 000..dd6fd52
> > > --- /dev/null
> > > +++ b/recipes/jpeg/jpeg-8b/0001-configure-make-jpeg-work-with-older-
> autotools.patch
> > > @@ -0,0 +1,30 @@
> > > +From e9e77ee999553f9b94de0288688a0bdc60b92e0f Mon Sep 17 00:00:00
> 2001
> > > +From: Chase Maupin
> > > +Date: Tue, 17 Aug 2010 08:30:56 -0500
> > > +Subject: [PATCH] configure: make jpeg work with older autotools
> > > +
> > > +* Only use the AM_SILENT_RULES variable if it is defined. Older
> > > + versions of automake don't support this option.
> > > +
> > > +Signed-off-by: Chase Maupin
> > > +---
> > > + configure.ac |3 ++-
> > > + 1 files changed, 2 insertions(+), 1 deletions(-)
> > > +
> > > +diff --git a/configure.ac b/configure.ac
> > > +index 96da13b..9a58c51 100644
> > > +--- a/configure.ac
> > > b/configure.ac
> > > +@@ -26,7 +26,8 @@ AM_INIT_AUTOMAKE([-Wall -Werror ansi2knr no-dist
> foreign])
> > > + # Make --enable-silent-rules the default.
> > > + # To get verbose build output you may configure
> > > + # with --disable-silent-rules or use "make V=1".
> > > +-AM_SILENT_RULES([yes])
> > > ++# only use if available
> > > ++m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
> > > +
> > > + # This is required when using the de-ANSI-fication feature.
> > > + AM_C_PROTOTYPES
> > > +--
> > > +1.7.0.4
> > > +
> > > diff --git a/recipes/jpeg/jpeg_8b.bb b/recipes/jpeg/jpeg_8b.bb
> > > index 4251ca6..688dcd8 100644
> > > --- a/recipes/jpeg/jpeg_8b.bb
> > > +++ b/recipes/jpeg/jpeg_8b.bb
> > > @@ -2,12 +2,15 @@ DESCRIPTION = "libjpeg is a library for handling the
> JPEG (JFIF) image format."
> > > LICENSE = "jpeg"
> > > SECTION = "libs"
> > > PRIORITY = "required"
> > > -PR = "r0"
> > > +PR = "r1"
> > >
> > > # TODO: really needed?
> > > RPROVIDES_${PN} = "jpeg"
> > >
> > > -SRC_URI = "http://www.ijg.org/files/jpegsrc.v${PV}.tar.gz";
> > > +SRC_URI = "\
> > > +http://www.ijg.org/files/jpegsrc.v${PV}.tar.gz \
> > > +file://0001-configure-make-jpeg-work-with-older-autotools.patch \
> > > +"
> > > S = "${WORKDIR}/jpeg-${PV}"
> > >
> > > inherit autotools
> > > --
> > > 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] base.bbclass: fix soc-family test
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Phil Blundell > Sent: Friday, September 10, 2010 4:20 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] base.bbclass: fix soc-family test > > On Fri, 2010-09-10 at 14:37 -0400, Denys Dmytriyenko wrote: > > I'd like us to find a compromise and a solution that satisfies everybody. > > > > Unfortunately, the original discussion about SOC_FAMILY vs. > MACHINE_CLASS > > never came to any fruition - Graeme explained his motives behind > MACHINE_CLASS > > and said that it is now deprecated. > > > > It was also mentioned, while SOC_FAMILY is slightly newer than > MACHINE_CLASS, > > the feature itself is over a year old and used quite extensively, > although > > limited mainly to recipes/ti location... > > > > And if technically SOC_FAMILY may be similar to MACHINE_CLASS, logically > they > > try to solve grouping problem from different direction, which was also > > explained. > > > > After that the original discussion was stalled and there were no strong > > opinions one way or another. Based on that, Chase's change was pushed. > > > > I see and understand Phil's position - if that's strong enough, we can > > re-consider. > > I take the point about MACHINE_CLASS and SOC_FAMILY being different in > intent. However, I do feel that these are just two out of a whole > universe of possible machine groupings and I remain somewhat uneasy > about adding this sort of thing to base.bbclass: if we admit SOC_FAMILY > (or even MACHINE_CLASS) there then it seems like it will set an > undesirable precedent for the next guy who wants his favourite machine > grouping to be given the same treatment. (The same thing applies to the > OVERRIDES patch that was posted recently and which I am not very fond of > either.) > > How many recipes are there for which this is a big deal? It's worth > remembering that the whole COMPATIBLE_MACHINE thing in base.bbclass is, > essentially, just syntactic sugar and there is nothing to stop you from > implementing whatever compatibility logic you want in your own .bb files > (or in an .inc, or a custom class). If there are only a handful of > recipes for which gating on SOC_FAMILY is required then I would suggest > that you simply put the appropriate Python bits in those recipes. Phil, First thanks for the response. There a quite a few recipes that use this or plan to use it. Kernel recipes, several of the recipes in the "recipes/ti" directory. I guess as a person who actually uses this I have a bias here. I hope you can understand though that this is variable found usefulness as an override and that is why it was extended to also work for COMPATIBLE_MACHINE. > > p. > > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCHv2 3/3] matrix-gui: updating to use latest source revision
I had an uncommitted change to fix a typo for this patch. This version
addresses that typo.
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Thursday, September 23, 2010 9:40 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Lance, Jeff; Maupin, Chase
> Subject: [PATCHv2 3/3] matrix-gui: updating to use latest source revision
>
> From: Jeff Lance
>
> * Use latest source revision 131
> * Add platform support for multiple platforms
> * Remove un-used files from SRC_URI and repository.
> * init files are now part of the matrix repository
> * matrix-gui.desktop is now part of the matrix repository
> * the cursor override patch is now in the matrix sources
>
> Signed-off-by: Chase Maupin
> Signed-off-by: Jeff Lance
> ---
> .../0001-Disable-cursor-override-for-X11.patch | 27 ---
> ---
> recipes/ti/matrix-gui/dm365-evm/init | 26 ---
> --
> recipes/ti/matrix-gui/init | 24 ---
> -
> recipes/ti/matrix-gui/matrix-gui.desktop |7
> recipes/ti/matrix-gui_svn.bb | 30 ---
>
> 5 files changed, 19 insertions(+), 95 deletions(-)
> delete mode 100644 recipes/ti/matrix-gui/0001-Disable-cursor-override-
> for-X11.patch
> delete mode 100644 recipes/ti/matrix-gui/dm365-evm/init
> delete mode 100644 recipes/ti/matrix-gui/init
> delete mode 100644 recipes/ti/matrix-gui/matrix-gui.desktop
>
> diff --git a/recipes/ti/matrix-gui/0001-Disable-cursor-override-for-
> X11.patch b/recipes/ti/matrix-gui/0001-Disable-cursor-override-for-
> X11.patch
> deleted file mode 100644
> index 61eba44..000
> --- a/recipes/ti/matrix-gui/0001-Disable-cursor-override-for-X11.patch
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -From b0e91f703ffdcc73f854a672ec16ebbf21293c9c Mon Sep 17 00:00:00 2001
> -From: Chase Maupin
> -Date: Mon, 24 May 2010 12:51:49 -0500
> -Subject: [PATCH] Disable cursor override for X11
> -
> -* Disable the cursor override option for using the matrix_gui
> - program with X11.
>
> - main.cpp |2 +-
> - 1 files changed, 1 insertions(+), 1 deletions(-)
> -
> -diff --git a/main.cpp b/main.cpp
> -index 978e327..1f55e94 100644
> a/main.cpp
> -+++ b/main.cpp
> -@@ -43,7 +43,7 @@ int main(int argc, char * argv[])
> - {
> - QApplication matrix(argc, argv);
> - QApplication::setStyle(new CustomStyle);
> --QApplication::setOverrideCursor(QCursor(Qt::BlankCursor));
> -+//QApplication::setOverrideCursor(QCursor(Qt::BlankCursor));
> -
> - // Create a new window to display a web page.
> - MainWindow * pWindow = new MainWindow(0, QString(argv[1]), true);
> ---
> -1.6.0.4
> -
> diff --git a/recipes/ti/matrix-gui/dm365-evm/init b/recipes/ti/matrix-
> gui/dm365-evm/init
> deleted file mode 100644
> index 3aadc1e..000
> --- a/recipes/ti/matrix-gui/dm365-evm/init
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -#! /bin/sh
> -matrixgui="/usr/bin/matrix_gui"
> -GUI_OPTS="-geometry 720x480+0+10 -display transformed:Rot0
> /usr/share/matrix/html/menu_main.html"
> -
> -test -x "$matrixgui" || exit 0
> -
> -case "$1" in
> - start)
> -# switch to component 480p mode
> -echo 480P-60 > /sys/class/davinci_display/ch0/mode
> -echo COMPONENT > /sys/class/davinci_display/ch0/output
> -echo -n "Starting Matrix GUI application"
> -start-stop-daemon --start --quiet --background --pidfile
> /var/run/matrix-gui.pid --exec $matrixgui -- $GUI_OPTS
> -echo "."
> -;;
> - stop)
> -echo -n "Stopping Matrix GUI application"
> -start-stop-daemon --stop --quiet --pidfile /var/run/matrix-gui.pid
> -echo "."
> -;;
> - *)
> -echo "Usage: /etc/init.d/matrix-gui {start|stop}"
> -exit 1
> -esac
> -
> -exit 0
> diff --git a/recipes/ti/matrix-gui/init b/recipes/ti/matrix-gui/init
> deleted file mode 100644
> index 40b6512..000
> --- a/recipes/ti/matrix-gui/init
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -#! /bin/sh
> -
> -matrixgui="/usr/bin/matrix_gui"
> -GUI_OPTS="/usr/share/matrix/html/menu_main.html"
> -
> -test -x "$matrixgui" || exit 0
> -
> -case "$1" in
> - start)
> -echo -n "Starting Matrix GUI application"
> -start-stop-daemon --start --quiet --background --pidfile
> /var/run/matrix-gui.pid --exec $matrixgui -- $GUI_OPTS
> -echo "."
> -;;
> - stop)
> -echo -n "Stopping Matrix GUI application"
> -start-stop-da
[oe] Question about automake licensing in recipe
All, I was digging around in the automake sources and I noticed that there is a top-level COPYING file that says automake is licensed under GPLv2. However, in the lib directory there is another COPYING file that says GPLv3. I was trying to figure out what LICENSE should be set to for automake when the sources contain both GPLv2 and GPLv3 code. Should it be set to something like GPLv2/GPLv3? I've read that GPLv2 and GPLv3 are incompatible (http://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv3-incompatible_licenses) so can a recipe even be marked as being both GPLv2 and GPLv3? Any input would be appreciated here. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Question about automake licensing in recipe
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Graham Gower > Sent: Thursday, September 23, 2010 5:18 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] Question about automake licensing in recipe > > On 24 September 2010 05:44, Maupin, Chase wrote: > > All, > > > > I was digging around in the automake sources and I noticed that there is > a top-level COPYING file that says automake is licensed under > GPLv2. However, in the lib directory there is another COPYING file that > says GPLv3. I was trying to figure out what LICENSE should be set to for > automake when the sources contain both GPLv2 and GPLv3 code. Should it be > set to something like GPLv2/GPLv3? I've read that GPLv2 and GPLv3 are > incompatible > (http://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv3- > incompatible_licenses) so can a recipe even be marked as being both GPLv2 > and GPLv3? > > > > Any input would be appreciated here. > > If the GPLv2 has the "or later version" clause and you are combining > with GPLv3, then there is no incompatibility as the entire thing is > then distributed under the GPLv3. If there is no "or later" clause, > then its a problem that needs to be sorted out upstream. Graham, Thanks for the input. I do not see the "or later" clause. I see some discussion on FSF about updating the exceptions for tools like automake. I guess this comes back to my question though of how we should mark the LICENSE field for the automake recipe until all the licensing is done? also, has anyone thought about having a license type of GPLv3+exception or some other format to indicate that there is an active exception for a package? > > -Graham > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Question about automake licensing in recipe
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Phil Blundell > Sent: Friday, September 24, 2010 7:56 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] Question about automake licensing in recipe > > On Fri, 2010-09-24 at 21:38 +0930, Graham Gower wrote: > > Basically, automake have to contact all their contributors to allow > > their GPLv2 code to be distributed under GPLv3. Or they have to pull > > the GPLv3 code out. > > If automake has followed the usual GNU conventions then all the > contributors will have assigned copyright of their code to the FSF > anyway. In that case, the FSF can (being the copyright holder) > unilaterally decide what licence it should be distributed under. Copyright is to FSF. I'm sending a mail to them asking for clarification on this issue. > > If they haven't done that then, yeah, they would probably need the > permission of the original authors to change the licensing. > > p. > > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Question about automake licensing in recipe
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Phil Blundell > Sent: Friday, September 24, 2010 7:56 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] Question about automake licensing in recipe > > On Fri, 2010-09-24 at 21:38 +0930, Graham Gower wrote: > > Basically, automake have to contact all their contributors to allow > > their GPLv2 code to be distributed under GPLv3. Or they have to pull > > the GPLv3 code out. > > If automake has followed the usual GNU conventions then all the > contributors will have assigned copyright of their code to the FSF > anyway. In that case, the FSF can (being the copyright holder) > unilaterally decide what licence it should be distributed under. As a follow up I'm beginning to wonder if the COPYING file in the lib directory wasn't auto-generated by automake itself. Newer versions of automake will apply the "gnu" strictness by default and will create a COPYING file for GPLv3. Either way, I have submitted an e-mail to the automake list asking for them to clarify their licensing. > > If they haven't done that then, yeah, they would probably need the > permission of the original authors to change the licensing. > > p. > > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Question about automake licensing in recipe
All, Just to follow up, the automake team says the current license is GPLv2. The COPYING file that says GPLv3 is autogenerated. In regards to future releases they had the following to say: With both the current license, and any future license, the idea is that packages using Automake are not bound by the Automake license: the macro files automake/m4/*.m4 which may be copied into your package's aclocal.m4 file, have very liberal license headers. The Makefile.in files produced by automake receive very liberal license headers as well (basically all you need to do is retain the license statement). The helper scripts automake/lib/* either have very liberal license statements themselves, or carry a GPL exception, or are considered independent programs on their own. > -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Maupin, Chase > Sent: Friday, September 24, 2010 8:28 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] Question about automake licensing in recipe > > > -Original Message- > > From: openembedded-devel-boun...@lists.openembedded.org > > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > > Phil Blundell > > Sent: Friday, September 24, 2010 7:56 AM > > To: openembedded-devel@lists.openembedded.org > > Subject: Re: [oe] Question about automake licensing in recipe > > > > On Fri, 2010-09-24 at 21:38 +0930, Graham Gower wrote: > > > Basically, automake have to contact all their contributors to allow > > > their GPLv2 code to be distributed under GPLv3. Or they have to pull > > > the GPLv3 code out. > > > > If automake has followed the usual GNU conventions then all the > > contributors will have assigned copyright of their code to the FSF > > anyway. In that case, the FSF can (being the copyright holder) > > unilaterally decide what licence it should be distributed under. > > As a follow up I'm beginning to wonder if the COPYING file in the lib > directory wasn't auto-generated by automake itself. Newer versions of > automake will apply the "gnu" strictness by default and will create a > COPYING file for GPLv3. Either way, I have submitted an e-mail to the > automake list asking for them to clarify their licensing. > > > > > If they haven't done that then, yeah, they would probably need the > > permission of the original authors to change the licensing. > > > > p. > > > > > > > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] am-benchmarks: update to latest version
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Frans Meulenbroeks > Sent: Wednesday, September 29, 2010 11:24 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] am-benchmarks: update to latest version > > 2010/9/29 Chase Maupin : > > * Updated the SRCREV to the latest version of this project > > which includes support for multiple platforms. > > > > Signed-off-by: Chase Maupin > > --- > > recipes/ti/am-benchmarks_svn.bb | 12 +--- > > 1 files changed, 9 insertions(+), 3 deletions(-) > > > > Don't have the full recipe handy, but is this latter UNDEFINED needed? > I would expect a COMPATIBLE_MACHINE somewhere causing the latter never > to happen. > Then again it might be a good safeguard. Frans, Good point. In the past there was no difference between arm9 and cortex-a8 so we didn't really concern ourselves with COMPATIBLE_MACHINE because the code was supposed to be buildable for all of the different machines. Now we have these different directories containing sources for the different architectures. We could use compatible machine so I could go either way on this. Let me know if you want me to change this. > > Frans. > > > > > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCHv2] am-benchmarks: update to latest version
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Paul Menzel
> Sent: Wednesday, September 29, 2010 6:43 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCHv2] am-benchmarks: update to latest version
>
> Dear Chase,
>
>
> Am Mittwoch, den 29.09.2010, 12:37 -0500 schrieb Chase Maupin:
> > * Updated the SRCREV to the latest version of this project
> > which includes support for multiple platforms.
> > * Add COMPATIBLE_MACHINE setting for recipe.
> >
> > Signed-off-by: Chase Maupin
>
> it would be great if you could briefly note what changed between the
> patch iterations after a --- line, so that it will get removed when it
> is committed. v1 → v2
Paul,
Sorry, I'm not exactly sure what you mean here. Are you saying I should do:
---
What I changed in the v2 version
>
> Please also remember to update the patch queue [1] as picked all patches
> from the queue and then had to remove the first version since it was
> still listed.
Will do. I was waiting for it to show up in patchwork and then it slipped my
mind. Sorry about that.
>
> > ---
> > recipes/ti/am-benchmarks_svn.bb | 13 ++---
> > 1 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/recipes/ti/am-benchmarks_svn.bb b/recipes/ti/am-
> benchmarks_svn.bb
> > index 51ac6af..6ab29f5 100644
> > --- a/recipes/ti/am-benchmarks_svn.bb
> > +++ b/recipes/ti/am-benchmarks_svn.bb
> > @@ -4,15 +4,22 @@ LICENSE = "BSD"
> > SECTION = "system"
> > PRIORITY = "optional"
> >
> > -SRCREV = "33"
> > -PV = "1.0"
> > +SRCREV = "56"
> > +PV = "1.1"
> > PR = "r1+svnr${SRCPV}"
> >
> > +COMPATIBLE_MACHINE = "(dm365|omapl138|omap3|ti816x)"
> > +
> > +ARCHITECTURE_dm365 = "arm9"
> > +ARCHITECTURE_omapl138 = "arm9"
> > +ARCHITECTURE_omap3 = "cortex-a8"
> > +ARCHITECTURE_ti816x = "cortex-a8"
> > +
> > INSANE_SKIP_${PN} = "True"
> >
> > SRC_URI =
> "svn://gforge.ti.com/svn/am_benchmarks/;module=trunk;proto=https;user=anon
> ymous;pswd=''"
> >
> > -S = "${WORKDIR}/trunk"
> > +S = "${WORKDIR}/trunk/${ARCHITECTURE}"
> >
> > do_compile() {
> > # don't build debug version
>
> I get the following error with minimal-uclibc. The other distributions
> still build. The error looks generic though.
>
> ERROR: 'oe/openembedded/recipes/ti/am-benchmarks_svn.bb' failed
> ERROR: Function do_compile failed
> […]
> Log data follows:
> | make: *** No rule to make target `release'. Stop.
> | ERROR: Function do_compile failed
> NOTE: package am-benchmarks-1.1-r1+svnr56: task do_compile: Failed
>
What device was this built for? Does this issue occur in the previous version
of the recipe?
I only ever use Angstrom. Can you provide some details on how I can repeat
your build?
>
> Thanks,
>
> Paul
>
>
> [1] http://wiki.openembedded.net/index.php/Patchwork
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCHv2] am-benchmarks: update to latest version
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Paul Menzel
> Sent: Thursday, September 30, 2010 2:25 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCHv2] am-benchmarks: update to latest version
>
> Am Donnerstag, den 30.09.2010, 01:43 +0200 schrieb Paul Menzel:
>
> > Am Mittwoch, den 29.09.2010, 12:37 -0500 schrieb Chase Maupin:
> > > * Updated the SRCREV to the latest version of this project
> > > which includes support for multiple platforms.
> > > * Add COMPATIBLE_MACHINE setting for recipe.
> > >
> > > Signed-off-by: Chase Maupin
> >
> > it would be great if you could briefly note what changed between the
> > patch iterations after a --- line, so that it will get removed when it
> > is committed. v1 → v2
> >
> > Please also remember to update the patch queue [1] as picked all patches
> > from the queue and then had to remove the first version since it was
> > still listed.
> >
> > > ---
> > > recipes/ti/am-benchmarks_svn.bb | 13 ++---
> > > 1 files changed, 10 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/recipes/ti/am-benchmarks_svn.bb b/recipes/ti/am-
> benchmarks_svn.bb
> > > index 51ac6af..6ab29f5 100644
> > > --- a/recipes/ti/am-benchmarks_svn.bb
> > > +++ b/recipes/ti/am-benchmarks_svn.bb
> > > @@ -4,15 +4,22 @@ LICENSE = "BSD"
> > > SECTION = "system"
> > > PRIORITY = "optional"
> > >
> > > -SRCREV = "33"
> > > -PV = "1.0"
> > > +SRCREV = "56"
> > > +PV = "1.1"
> > > PR = "r1+svnr${SRCPV}"
> > >
> > > +COMPATIBLE_MACHINE = "(dm365|omapl138|omap3|ti816x)"
> > > +
> > > +ARCHITECTURE_dm365 = "arm9"
> > > +ARCHITECTURE_omapl138 = "arm9"
> > > +ARCHITECTURE_omap3 = "cortex-a8"
> > > +ARCHITECTURE_ti816x = "cortex-a8"
> > > +
> > > INSANE_SKIP_${PN} = "True"
> > >
> > > SRC_URI =
> "svn://gforge.ti.com/svn/am_benchmarks/;module=trunk;proto=https;user=anon
> ymous;pswd=''"
> > >
> > > -S = "${WORKDIR}/trunk"
> > > +S = "${WORKDIR}/trunk/${ARCHITECTURE}"
> > >
> > > do_compile() {
> > > # don't build debug version
> >
> > I get the following error with minimal-uclibc. The other distributions
> > still build. The error looks generic though.
> >
> > ERROR: 'oe/openembedded/recipes/ti/am-benchmarks_svn.bb' failed
> > ERROR: Function do_compile failed
> > […]
> > Log data follows:
> > | make: *** No rule to make target `release'. Stop.
> > | ERROR: Function do_compile failed
> > NOTE: package am-benchmarks-1.1-r1+svnr56: task do_compile:
> Failed
>
> I got the same error with minimal (eglibc). But it worked with Ȧngström
> 2008.1. I do not know what is going on.
Paul,
Thanks for looking into this. For now we are only supporting this recipe on
Angstrom. This recipe uses features such as SOC_FAMILY in the overrides that
are not available in all distributions such as minimal. In fact, I believe
this is what caused your problem because the S directory is based on an
override which uses SOC_FAMILY. I will add a note to this affect and send an
updated patch for the recipe.
>
>
> Thanks,
>
> Paul
>
>
> > [1] http://wiki.openembedded.net/index.php/Patchwork
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/5] ti816x: add support for ti816x family of devices
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Denys Dmytriyenko > Sent: Thursday, September 30, 2010 6:27 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH 1/5] ti816x: add support for ti816x family of > devices > > On Thu, Sep 30, 2010 at 01:12:02PM -0500, Chase Maupin wrote: > > * Add support for the TI816x family of devices. This includes > > the c6a816x and am389x devices. > > * Separate machine types are used because not all packages > > are valid for each machine. > > > > Signed-off-by: Chase Maupin > > --- > > conf/machine/am389x-evm.conf|5 + > > conf/machine/c6a816x-evm.conf |5 + > > conf/machine/include/ti816x.inc | 26 ++ > > 3 files changed, 36 insertions(+), 0 deletions(-) > > create mode 100644 conf/machine/am389x-evm.conf > > create mode 100644 conf/machine/c6a816x-evm.conf > > create mode 100644 conf/machine/include/ti816x.inc > > > > diff --git a/conf/machine/am389x-evm.conf b/conf/machine/am389x-evm.conf > > new file mode 100644 > > index 000..9bfe7a7 > > --- /dev/null > > +++ b/conf/machine/am389x-evm.conf > > @@ -0,0 +1,5 @@ > > +...@type: Machine > > +...@name: am389x evm > > +...@description: Machine configuration for the am389x evm > > + > > +require conf/machine/include/ti816x.inc > > diff --git a/conf/machine/c6a816x-evm.conf b/conf/machine/c6a816x- > evm.conf > > new file mode 100644 > > index 000..a7ab9b0 > > --- /dev/null > > +++ b/conf/machine/c6a816x-evm.conf > > @@ -0,0 +1,5 @@ > > +...@type: Machine > > +...@name: c6a816x evm > > +...@description: Machine configuration for the c6a816x evm > > + > > +require conf/machine/include/ti816x.inc > > diff --git a/conf/machine/include/ti816x.inc > b/conf/machine/include/ti816x.inc > > new file mode 100644 > > index 000..e5205f7 > > --- /dev/null > > +++ b/conf/machine/include/ti816x.inc > > @@ -0,0 +1,26 @@ > > +TARGET_ARCH = "arm" > > +SOC_FAMILY = "ti816x" > > + > > +require conf/machine/include/tune-cortexa8.inc > > + > > +PREFERRED_PROVIDER_virtual/kernel = "linux-omap3" > > Chase, > > There is no linux-omap3 recipe in OE, unlike Arago. Anyway, Koen said > he'll > make necessary updates when he pushes all the ti816x-related changes... Denys, Good point. I see that the kernel changes went in today. > > -- > Denys > > > > +PREFERRED_PROVIDER_virtual/bootloader = "u-boot" > > + > > +# Increase this everytime you change something in the kernel > > +MACHINE_KERNEL_PR = "r1" > > + > > +KERNEL_IMAGETYPE = "uImage" > > + > > +UBOOT_ARCH = "arm" > > +UBOOT_MACHINE = "ti8168_evm_config" > > +UBOOT_ENTRYPOINT = "0x80008000" > > +UBOOT_LOADADDRESS = "0x80008000" > > + > > +# Only build u-boot > > +EXTRA_IMAGEDEPENDS += "u-boot" > > + > > +# Ship all kernel modules > > +IMAGE_FSTYPES ?= "jffs2 tar.bz2" > > +EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x2 -s 2048" > > +SERIAL_CONSOLE = "115200 ttyS2" > > +MACHINE_FEATURES = "kernel26 apm usbgadget usbhost vfat ext2 ethernet" > > -- > > 1.7.0.4 > > > > > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] recipe licenses: update recipe LICENSE fields
> -Original Message- > From: Chase Maupin [mailto:chasemaupi...@gmail.com] > Sent: Friday, September 24, 2010 11:09 AM > To: openembedded-devel@lists.openembedded.org > Cc: Maupin, Chase > Subject: [PATCH] recipe licenses: update recipe LICENSE fields > > * While verifying the licensing for the packages I am building > into my file system I found that for some packages the > LICENSE value set in the recipe was either incorrect or > generic and not detailed enough. This patch is my attempt > to update the LICENSE fields for these packages to match > the actual versions of the licenses in the sources. > > Signed-off-by: Chase Maupin Bump ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] recipe licenses: update recipe LICENSE fields
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Holger Freyther > Sent: Friday, October 01, 2010 3:18 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] recipe licenses: update recipe LICENSE fields > > On 09/25/2010 12:08 AM, Chase Maupin wrote: > > > > > diff --git a/recipes/autoconf/autoconf.inc > b/recipes/autoconf/autoconf.inc > > index 35b0289..70e24a0 100644 > > --- a/recipes/autoconf/autoconf.inc > > +++ b/recipes/autoconf/autoconf.inc > > @@ -1,6 +1,6 @@ > > DESCRIPTION = "A package of M4 macros to produce scripts to \ > > automatically configure sourcecode." > > -LICENSE = "GPL" > > +LICENSE = "GPLv3+exception" > > hmm... but at your option the exception might be omitted.. and there are > many > possible exception clauses... so it doesn't really say what it is. So how would you mark this as a package that contains an exception? My intention here is to note that this is not standard GPLv3 > > > > > HOMEPAGE = "http://www.gnu.org/software/autoconf/"; > > SECTION = "devel" > > DEPENDS += "m4-native" > > diff --git a/recipes/autoconf/autoconf213_2.13.bb > b/recipes/autoconf/autoconf213_2.13.bb > > index d060bbd..4c855e0 100644 > > --- a/recipes/autoconf/autoconf213_2.13.bb > > +++ b/recipes/autoconf/autoconf213_2.13.bb > > @@ -1,4 +1,5 @@ > > require autoconf.inc > > +LICENSE = "GPLv2" > > hard to believe... sure it is not v2 and later? it should be the standard > FSF > text? isn't it? It doesn't have the "or later" clause. > > > > +LICENSE = "GPLv2 AFLv2.1" > > good.. > > > > > -LICENSE = "BSD" > > +LICENSE = "NewBSD" > > could you point me to anyone using the term NewBSD? BSD license without > advertisement clause? common but also misleading terms are 2-clause, 3- > clause > BSD... I got this distinction from what may be a bad place, but it was Wikipedia (http://en.wikipedia.org/wiki/BSD_licenses). I have heard people refer to NewBSD, FreeBSD, and BSD around my work. I was setting these to make it clear which version of the BSD the license was. > > > > > diff --git a/recipes/tinylogin/tinylogin_1.4.bb > b/recipes/tinylogin/tinylogin_1.4.bb > > index 40171ff..730012b 100644 > > --- a/recipes/tinylogin/tinylogin_1.4.bb > > +++ b/recipes/tinylogin/tinylogin_1.4.bb > > @@ -4,7 +4,7 @@ changing passwords, and otherwise maintaining users \ > > and groups on an embedded system." > > HOMEPAGE = "http://tinylogin.busybox.net/"; > > SECTION = "base" > > -LICENSE = "GPLv2" > > +LICENSE = "GPLv2/NewBSD" > > please don't use a '/'. IIRC this source will be put into a folder with > that > name... I understand. How should we denote recipes that have dual licenses? I figured "GPLv2 NewBSD" mean it was either license. Perhaps this should be "GPLv2+NewBSD"? > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCHv2] recipe licenses: update recipe LICENSE fields
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Frans Meulenbroeks > Sent: Monday, October 11, 2010 12:41 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCHv2] recipe licenses: update recipe LICENSE fields > > 2010/10/11 Chase Maupin : > > * While verifying the licensing for the packages I am building > > into my file system I found that for some packages the > > LICENSE value set in the recipe was either incorrect or > > generic and not detailed enough. This patch is my attempt > > to update the LICENSE fields for these packages to match > > the actual versions of the licenses in the sources. > > > > [...] > > > -LICENSE = "GPLv2" > > +LICENSE = "GPLv2+" > > Doe we want this? > I think most GPLv2 code carries the clause: > > "This program is free software; you can redistribute it and/or > modify it under the terms of the GNU General Public License > as published by the Free Software Foundation; either version 2 > of the License, or (at your option) any later version." > > Yet currently virtually all of these have GPL or GPLv2 as LICENSE Frans, My original version of this patch was just changing GPL to GPLv2 for example. But I was asked about whether it should be GPLv2+ which I guess is more indicative of the "or later" clause. Does anyone have good guidance here on how to denote things that are GPLv2 only for now (like git which Linux has a note in the COPYING file about it being GPLv2) and things that are GPLv2 or later version? I'm trying for consistency here but I guess there doesn't seem to be a set policy for how the LICENSE field should be set. > > v2+ versions: > > enblend/plotutils_2.6.bb:LICENSE = "GPLv2+" > ffmpeg/ffmpeg_svn.bb:LICENSE = "GPLv2+" > gnome/epiphany_2.30.2.bb:LICENSE = "GPLv2+" > gpe-package/gpe-package_0.4.bb:LICENSE = "GPLv2+" > libftdi/libftdi_0.18.bb:LICENSE = "LGPL GPLv2+linking exception" > libnfo/libnfo.inc:LICENSE = "LGPLv2+" > lzo/lzo2_2.03.bb:LICENSE = "GPLv2+" > raw-tools/exiv2_0.20.bb:LICENSE = "GPLv2+" > sysvinit/sysvinit_2.86.bb:LICENSE = "GPLv2+" > udev/udev.inc:LICENSE = "GPLv2+" > udev/udev_151.bb:LICENSE = "GPLv2+" > udev/udev_154.bb:LICENSE = "GPLv2+" > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCHv2] recipe licenses: update recipe LICENSE fields
> > I'm not sure if it is a policy. Haven't seen it being pulished as such. > Having said that, I have no problems with it (although there is no > problem with enforcing patents or so for v2+ , as that still falls > under the v2 umbrella). > > I guess most of our recipes that say GPLv2 are wrong and are v2+. > It might be hard to distinguish between these though, it could well be > that the license file says v2 and a comment in the code says v2+. > Glad I do not have to deal with this any more Frans, That is exactly the issue that is so annoying. The COPYING file usually says the standard GPLv2, but if you go and read the license text in the code that is where it says GPLv2 (or later) so GPLv2+. This patch was modified to go off the license in the code since that is more likely what the developer actually intended and not an auto-generated file. Koen, What about GPLv3 licensed files with an exception? Right now I have that as GPLv3+exception. Was there ever any discussion about how to handle these? I am trying to indicate that it is not a standard GPLv3 license. Chase > > Frans > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/5] matrix-gui-common: skip qa check on prebuilt binaries
> -Original Message-
> From: Denys Dmytriyenko [mailto:de...@denix.org]
> Sent: Wednesday, October 13, 2010 11:59 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: Re: [oe] [PATCH 1/5] matrix-gui-common: skip qa check on prebuilt
> binaries
>
> On Wed, Oct 13, 2010 at 09:01:27AM -0500, Chase Maupin wrote:
> > * Skip the QA check on the prebuilt binaries used for dm365
> > devices.
>
> And why do we have prebuilt binaries in OE?
They are not so much in the OE repository as they are part of the matrix
repository. That being said I'm working to get these buildable in OE and I'll
make this an RDEPENDS. So go ahead and ignore this patch.
>
> > Signed-off-by: Chase Maupin
> > ---
> > recipes/ti/matrix-gui-common.inc |3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/recipes/ti/matrix-gui-common.inc b/recipes/ti/matrix-gui-
> common.inc
> > index 096c321..46c0bd6 100644
> > --- a/recipes/ti/matrix-gui-common.inc
> > +++ b/recipes/ti/matrix-gui-common.inc
> > @@ -32,4 +32,7 @@ do_install() {
> >
> > }
> >
> > +# Skip the QA for pre-built binaries
> > +INSANE_SKIP_${PN}_dm365 = "True"
> > +
> > FILES_${PN} += "${datadir}/matrix/*"
> > --
> > 1.7.0.4
> >
> >
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Question about OVERRIDES precedence
All,
I have been looking into the OVERRIDES setting and it appears to me that the
OVERRIDES are being handled in least specific to most specific order. Meaning
that if I have an override for a particular machine set that it has a lower
priority than the override for a distro.
My OVERRIDES variable is actually set to evaluate:
#
OVERRIDES=local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}:${FEED_ARCH}:${SOC_FAMILY}:libc-glibc${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}
Which translates in my build to:
OVERRIDES="local:am37x-evm:angstrom:linux-gnueabi:arm:build-linux:fail-fast:pn-task-arago-toolchain-tisdk-multimedia-host:armv7a:omap3:libc-glibc:thumb-interwork"
I would expect that if I set an override for am37x-evm that this MACHINE
specific override should trump the DISTRO specific override or the SOC_FAMILY
override.
Likewise I would expect that the local override would have the highest
precedence because I am trying to override something specifically for my local
copy and that the "thumb-interwork" override would have the lowest precedence.
Is my expectation incorrect?
If so then can we just reverse the list of overrides in the update_data method
of /lib/bb/data.py, around line 500 in my version. My bitbake is on
version 1.10. In the master this would be in the finalize function of the
DataSmart class.
Thanks in advance for you input.
Sincerely,
Chase Maupin
Software Applications
Catalog DSP Products
e-mail: chase.mau...@ti.com
phone: (281) 274-3285
For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Question about OVERRIDES precedence
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Chris Larson
> Sent: Wednesday, October 13, 2010 4:22 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] Question about OVERRIDES precedence
>
> On Wed, Oct 13, 2010 at 1:29 PM, Maupin, Chase
> wrote:
>
> > I have been looking into the OVERRIDES setting and it appears to me that
> > the OVERRIDES are being handled in least specific to most specific order.
> > Meaning that if I have an override for a particular machine set that it
> has
> > a lower priority than the override for a distro.
> >
> > My OVERRIDES variable is actually set to evaluate:
> > #
> > OVERRIDES=local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-
> ${BUILD_OS}:fail-fast:pn-${PN}:${FEED_ARCH}:${SOC_FAMILY}:libc-
> glibc${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}
> >
> > Which translates in my build to:
> >
> > OVERRIDES="local:am37x-evm:angstrom:linux-gnueabi:arm:build-linux:fail-
> fast:pn-task-arago-toolchain-tisdk-multimedia-host:armv7a:omap3:libc-
> glibc:thumb-interwork"
> >
> > I would expect that if I set an override for am37x-evm that this MACHINE
> > specific override should trump the DISTRO specific override or the
> > SOC_FAMILY override.
> >
> > Likewise I would expect that the local override would have the highest
> > precedence because I am trying to override something specifically for my
> > local copy and that the "thumb-interwork" override would have the lowest
> > precedence.
> >
> > Is my expectation incorrect?
> >
>
> Yes, your expectation is correct. OVERRIDES is intended to essentially
> give
> us a layering mechanism for the metadata, ensuring that the most specific
> available information is always used. So machine should always have
> higher
> priority than target architecture, for example, and local is highest of
> all.
>
> I assume in your testing you've found that this is not behaving the way it
> should?
>
> If so then can we just reverse the list of overrides in the update_data
> > method of /lib/bb/data.py, around line 500 in my version. My
> > bitbake is on version 1.10. In the master this would be in the finalize
> > function of the DataSmart class.
> >
>
> I think you're correct, yes, from a quick re-read of the code -- it seems
> to
> be evaluating them from highest to lowest priority, so the latter may
> override the former, unless I'm missing something. This seems like it
> would
> have been an obvious thing -- if overrides aren't working as intended, I'd
> have expected it to have been caught before now :\ This code hasn't
> changed
> since the original implementation, it seems -- see
> d8b28d544cd7ba8e9c303e72f8ce2ed04ee71b3a.
Chris,
That was my thought as well but I can consistently cause this issue. I have
tested a quick change that seems to fix the issue by reversing the list before
it is used in the for loop. My change was:
diff --git a/lib/bb/data.py b/lib/bb/data.py
index f424ac7..b3bd8b9 100644
--- a/lib/bb/data.py
+++ b/lib/bb/data.py
@@ -480,7 +480,7 @@ def update_data(d):
#print "Append/Prepend %s" % d._special_values
#print "Overrides %s" % d._seen_overrides
-overrides = (getVar('OVERRIDES', d, 1) or "").split(':') or []
+overrides = (getVar('OVERRIDES', d, 1) or "").split(':')[::-1] or []
#
# Well let us see what breaks here. We used to iterate
If you agree with this change I'll submit a patch. Should I submit it to this
list or another one?
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Question about OVERRIDES precedence
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Chris Larson
> Sent: Wednesday, October 13, 2010 4:39 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] Question about OVERRIDES precedence
>
> On Wed, Oct 13, 2010 at 2:30 PM, Maupin, Chase
> wrote:
>
> > That was my thought as well but I can consistently cause this issue. I
> > have tested a quick change that seems to fix the issue by reversing the
> list
> > before it is used in the for loop. My change was:
>
>
> From discussion on IRC, we think we should just reverse the definition of
> OVERRIDES in OE, this avoids compatibility issues associated with changing
> the implementation.
Chris,
So are you saying that we are just going to change the order of how OVERRIDES
is appended to in OE like Denys was suggesting? That would still lead to
issues like local not being the highest priority unless we would also change
bitbake.conf to define OVERRIDES as
"${TARGET_ARCH}:${TARGET_OS}:${MACHINE}:local". That way we could prepend
OVERRIDES in OE and still have local be the last one evaluated.
Or are you saying that we should build the whole OVERRIDES list and then
reverse it in the OE configuration files?
If that is the case I tried adding a line like:
reverse_overrides...@d.setvar("OVERRIDES", ':'.join(bb.data.getVar('OVERRIDES',
d, 1).split(':')[::-1]))}
to the end of my local.conf file. When I do a bitbake -e to dump my
environment I see that OVERRIDES is now defined to:
OVERRIDES="thumb-interwork:libc-glibc:omap3:armv7a:pn-task-arago-toolchain-tisdk-multimedia-host:fail-fast:build-linux:arm:linux-gnueabi:angstrom:am37x-evm:local"
But while that order looks right it seems like maybe that is being interpreted
to late because my variables that use overrides are not picking up the right
values. i.e. my MACHINE override is not taking precedence over my SOC_FAMILY
override.
Any ideas why this does not work?
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Question about OVERRIDES precedence
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Chris Larson
> Sent: Thursday, October 14, 2010 10:34 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] Question about OVERRIDES precedence
>
> On Thu, Oct 14, 2010 at 8:29 AM, Maupin, Chase
> wrote:
>
> > So are you saying that we are just going to change the order of how
> > OVERRIDES is appended to in OE like Denys was suggesting? That would
> still
> > lead to issues like local not being the highest priority unless we would
> > also change bitbake.conf to define OVERRIDES as
> > "${TARGET_ARCH}:${TARGET_OS}:${MACHINE}:local". That way we could
> prepend
> > OVERRIDES in OE and still have local be the last one evaluated.
> >
>
> No. What I'm saying is, the definition of OVERRIDES in bitbake.conf will
> be
> reversed. Not that difficult to understand. I don't know how I could
> possibly be any clearer here.
Great. I assume this will be on the 1.10 branch as well as the master branch?
Is there anything I can do to help here?
I guess with the reversal of the definition in bitbake.conf we can then change
the appends to prepends in OE as well as reversing the definitions there. That
way the OVERRIDES list should be built up in the proper order.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Question about OVERRIDES precedence
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Chris Larson
> Sent: Thursday, October 14, 2010 11:42 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] Question about OVERRIDES precedence
>
> On Thu, Oct 14, 2010 at 9:37 AM, Maupin, Chase
> wrote:
>
> > > -Original Message-
> > > From: openembedded-devel-boun...@lists.openembedded.org
> > > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf
> Of
> > > Chris Larson
> > > Sent: Thursday, October 14, 2010 10:34 AM
> > > To: openembedded-devel@lists.openembedded.org
> > > Subject: Re: [oe] Question about OVERRIDES precedence
> > >
> > > On Thu, Oct 14, 2010 at 8:29 AM, Maupin, Chase
> > > wrote:
> > >
> > > > So are you saying that we are just going to change the order of how
> > > > OVERRIDES is appended to in OE like Denys was suggesting? That
> would
> > > still
> > > > lead to issues like local not being the highest priority unless we
> > would
> > > > also change bitbake.conf to define OVERRIDES as
> > > > "${TARGET_ARCH}:${TARGET_OS}:${MACHINE}:local". That way we could
> > > prepend
> > > > OVERRIDES in OE and still have local be the last one evaluated.
> > > >
> > >
> > > No. What I'm saying is, the definition of OVERRIDES in bitbake.conf
> will
> > > be
> > > reversed. Not that difficult to understand. I don't know how I could
> > > possibly be any clearer here.
> >
> > Great. I assume this will be on the 1.10 branch as well as the master
> > branch? Is there anything I can do to help here?
> >
>
> There is no 1.10 branch in OE, so no. Again, we're changing it in OE, not
> bitbake.
Chris,
I just realized what you were talking about. I was looking at the bitbake.conf
file in the bitbake repository, not the one in the OE repository. Now what you
are saying makes more sense. Sorry for the confusion.
>
> I guess with the reversal of the definition in bitbake.conf we can then
> > change the appends to prepends in OE as well as reversing the
> definitions
> > there. That way the OVERRIDES list should be built up in the proper
> order.
>
>
> Yes, indeed, though I suspect that the existing prepend/appends were done
> by
> people not thinking about the order, so they may not be correct the way
> they are now anyway .. :)
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] Reverse the order of OVERRIDES
> diff --git a/conf/machine/kixrp435.conf b/conf/machine/kixrp435.conf
> index 8259127..b4a2fa6 100644
> --- a/conf/machine/kixrp435.conf
> +++ b/conf/machine/kixrp435.conf
> @@ -7,7 +7,7 @@ TARGET_ARCH = "arm"
> # Note: armv4 armv4t armv5te will be added by tune-xscale.inc
> automatically.
> PACKAGE_EXTRA_ARCHS = "armv5e ixp4xxle"
>
> -OVERRIDES =
> "local:${MACHINE}:nslu2:ixp4xx:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build
> -${BUILD_OS}:fail-fast:pn-${PN}"
> +MACHINE_OVERRIDES += "nslu2 ixp4xx"
Should this be "ixp4xx nslu2"? At least in order to keep the original behavior?
>
> PREFERRED_PROVIDER_virtual/kernel = "linux"
> PREFERRED_VERSION_linux = "2.6.30"
> diff --git a/conf/machine/nslu2be.conf b/conf/machine/nslu2be.conf
> index 9bc92f1..88e6ed2 100644
> --- a/conf/machine/nslu2be.conf
> +++ b/conf/machine/nslu2be.conf
> @@ -7,7 +7,7 @@ TARGET_ARCH = "armeb"
> # Note: armv4b armv4tb armv5teb will be added by tune-xscale.inc
> automatically.
> PACKAGE_EXTRA_ARCHS = "armv5eb ixp4xxbe"
>
> -OVERRIDES =
> "local:${MACHINE}:nslu2:ixp4xx:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build
> -${BUILD_OS}:fail-fast:pn-${PN}"
> +MACHINE_OVERRIDES += "nslu2 ixp4xx"
Should this be "ixp4xx nslu2"? At least in order to keep the original behavior?
>
> ROOT_FLASH_SIZE ?= "6"
>
> diff --git a/conf/machine/nslu2le.conf b/conf/machine/nslu2le.conf
> index 62e47cb..edd0d94 100644
> --- a/conf/machine/nslu2le.conf
> +++ b/conf/machine/nslu2le.conf
> @@ -7,7 +7,7 @@ TARGET_ARCH = "arm"
> # Note: armv4 armv4t armv5te will be added by tune-xscale.inc
> automatically.
> PACKAGE_EXTRA_ARCHS = "armv5e ixp4xxle"
>
> -OVERRIDES =
> "local:${MACHINE}:nslu2:ixp4xx:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build
> -${BUILD_OS}:fail-fast:pn-${PN}"
> +MACHINE_OVERRIDES += "nslu2 ixp4xx"
Should this be "ixp4xx nslu2"? At least in order to keep the original behavior?
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCHv2] recipe licenses: update recipe LICENSE fields
ping
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Monday, October 11, 2010 10:58 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: [PATCHv2] recipe licenses: update recipe LICENSE fields
>
> * While verifying the licensing for the packages I am building
> into my file system I found that for some packages the
> LICENSE value set in the recipe was either incorrect or
> generic and not detailed enough. This patch is my attempt
> to update the LICENSE fields for these packages to match
> the actual versions of the licenses in the sources.
>
> Signed-off-by: Chase Maupin
>
> ---
> Added in version 2:
> * Checked sources and updated GPLv2 packages to GPLv2+ if the
> "or later" clause was found in the sources.
> * Changed the separator for packages licensed under multiple
> licenses to "|" instead of "/"
> ---
> recipes/autoconf/autoconf.inc |2 +-
> recipes/autoconf/autoconf213_2.13.bb |1 +
> recipes/autoconf/autoconf_2.61.bb |2 ++
> recipes/bison/bison.inc|2 +-
> recipes/dbus/dbus-c++_git.bb |2 +-
> recipes/dbus/dbus-daemon-proxy_git.bb |2 +-
> recipes/dbus/dbus-glib.inc |2 +-
> recipes/dbus/dbus.inc |2 +-
> .../desktop-file-utils-native_0.14.bb |2 +-
> .../desktop-file-utils/desktop-file-utils_0.15.bb |2 +-
> .../desktop-file-utils/desktop-file-utils_0.16.bb |2 +-
> .../desktop-file-utils/desktop-file-utils_0.3.bb |2 +-
> .../desktop-file-utils/desktop-file-utils_0.6.bb |2 +-
> recipes/e2fsprogs/e2fsprogs.inc|2 +-
> recipes/genext2fs/genext2fs.inc|2 +-
> recipes/git/git.inc|2 +-
> recipes/glib-2.0/glib-2.0_2.22.4.bb|2 +-
> recipes/glib-2.0/glib-2.0_2.23.6.bb|2 +-
> recipes/glib-2.0/glib-2.0_2.24.0.bb|2 +-
> recipes/glib-2.0/glib-2.0_2.24.1.bb|2 +-
> recipes/glib-2.0/glib-2.0_2.6.4.bb |2 +-
> recipes/glib-2.0/glib-2.0_2.8.6.bb |2 +-
> recipes/glib-2.0/glib.inc |2 +-
> recipes/iperf/iperf.inc|2 +-
> recipes/ipkg-utils/ipkg-link_1.6+cvs20050404.bb|2 +-
> recipes/ipkg-utils/ipkg-utils_1.6+cvs20050404.bb |2 +-
> recipes/iptables/iptables.inc |2 +-
> recipes/libtool/libtool.inc|2 +-
> recipes/linux-libc-headers/linux-libc-headers.inc |2 +-
> recipes/pkgconfig/pkgconfig.inc|2 +-
> recipes/psplash/psplash.inc|2 +-
> recipes/quilt/quilt.inc|2 +-
> recipes/thttpd/thttpd_2.25b.bb |2 +-
> recipes/tinylogin/tinylogin_1.4.bb |2 +-
> recipes/unifdef/unifdef-native_2.6.18+git.bb |2 +-
> recipes/update-rc.d/update-rc.d_0.7.bb |2 +-
> recipes/x-load/signgp.bb |2 +-
> recipes/x-load/x-load.inc |2 +-
> recipes/xorg-lib/xorg-headers-native.bb|2 ++
> 39 files changed, 41 insertions(+), 36 deletions(-)
>
> diff --git a/recipes/autoconf/autoconf.inc b/recipes/autoconf/autoconf.inc
> index 35b0289..70e24a0 100644
> --- a/recipes/autoconf/autoconf.inc
> +++ b/recipes/autoconf/autoconf.inc
> @@ -1,6 +1,6 @@
> DESCRIPTION = "A package of M4 macros to produce scripts to \
> automatically configure sourcecode."
> -LICENSE = "GPL"
> +LICENSE = "GPLv3+exception"
> HOMEPAGE = "http://www.gnu.org/software/autoconf/";
> SECTION = "devel"
> DEPENDS += "m4-native"
> diff --git a/recipes/autoconf/autoconf213_2.13.bb
> b/recipes/autoconf/autoconf213_2.13.bb
> index d060bbd..cd55073 100644
> --- a/recipes/autoconf/autoconf213_2.13.bb
> +++ b/recipes/autoconf/autoconf213_2.13.bb
> @@ -1,4 +1,5 @@
> require autoconf.inc
> +LICENSE = "GPLv2+"
> SRC_URI = "${GNU_MIRROR}/autoconf/autoconf-${PV}.tar.gz"
> EXTRA_OECONF = "--program-transform-name=s/\$/2.13/"
> EXTRA_OEMAKE = 'acdatadir="${datadir}/autoconf-${PV}"
> infodir="${datadir}/autoconf-${PV}/info"'
> diff --git a/recipes/autoconf/autoconf_2.61.bb
> b/recipes/autoconf/autoconf_2.61.bb
> index 9542e21..4588608 100644
> --- a/recipes/autoconf/autocon
Re: [oe] [PATCH] Reverse the order of OVERRIDES
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Chris Larson
> Sent: Friday, October 15, 2010 10:17 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Chris Larson
> Subject: Re: [oe] [PATCH] Reverse the order of OVERRIDES
>
> On Fri, Oct 15, 2010 at 7:12 AM, Maupin, Chase
> wrote:
>
> > > diff --git a/conf/machine/kixrp435.conf b/conf/machine/kixrp435.conf
> > > index 8259127..b4a2fa6 100644
> > > --- a/conf/machine/kixrp435.conf
> > > +++ b/conf/machine/kixrp435.conf
> > > @@ -7,7 +7,7 @@ TARGET_ARCH = "arm"
> > > # Note: armv4 armv4t armv5te will be added by tune-xscale.inc
> > > automatically.
> > > PACKAGE_EXTRA_ARCHS = "armv5e ixp4xxle"
> > >
> > > -OVERRIDES =
> > >
> >
> "local:${MACHINE}:nslu2:ixp4xx:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build
> > > -${BUILD_OS}:fail-fast:pn-${PN}"
> > > +MACHINE_OVERRIDES += "nslu2 ixp4xx"
> >
> > Should this be "ixp4xx nslu2"? At least in order to keep the original
> > behavior?
>
>
> Yes, good catch, thanks, I'll fix it in the next version of the patch.
Everything else looked OK to me. Thanks for this change Chris.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH (v2)] Reverse the order of OVERRIDES
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Chris Larson
> Sent: Friday, October 15, 2010 10:41 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] [PATCH (v2)] Reverse the order of OVERRIDES
>
> From: Chris Larson
>
> Given the current implementation of OVERRIDES in bitbake, the variable is
> expected to contain elements in the order least specific to most specific,
> however, our current usage of it does not match that. As one example,
> "local"
> is supposed to always be the most specific override, yet currently it's
> the
> least specific. As another example, currently the target architecture is
> seen
> as more specific than the machine, which is also clearly wrong.
>
> Big thanks to Chase Maupin for investigating and identifying this long
> standing issue.
>
> It becomes clear that a reversal of the current value will bring us to a
> more
> sane behavior, and avoids the need for the dual overrides hack mentioned
> in
> the comments, so this implements this reversal, and drops the unnecessary
> and
> confusing comments.
>
> This also introduces a MACHINE_OVERRIDES variable as a generic mechanism
> to
> inject overrides elements which are more specific than the distro but less
> specific than the machine, which is where things like MACHINE_CLASS or
> SOC_FAMILY or the like would go. This variable is *space* separated, to
> make
> it easier and more convenient to assemble the variable incrementally.
>
> Reported-by: Chase Maupin
> Signed-off-by: Chris Larson
Acked-by: Chase Maupin
> ---
> conf/bitbake.conf | 17 ++---
> conf/distro/include/arm-thumb.inc |6 ++--
> conf/distro/micro.conf|6 ++--
> conf/distro/minimal.conf |5 ++-
> conf/distro/shr.conf |5 ++-
> conf/machine/fsg3be.conf |2 +-
> conf/machine/kixrp435.conf|2 +-
> conf/machine/nslu2be.conf |2 +-
> conf/machine/nslu2le.conf |2 +-
> docs/usermanual/chapters/common_use_cases.xml | 31 +++-
>
> recipes/binutils/binutils_csl-arm-20050416.bb |2 +-
> recipes/binutils/binutils_csl-arm-20050603.bb |2 +-
> recipes/eglibc/eglibc-package.bbclass |2 +-
> recipes/glibc/glibc-package.inc |2 +-
> recipes/prelink/prelink_20061027.bb |2 +-
> recipes/prelink/prelink_20071009.bb |2 +-
> recipes/prelink/prelink_20090925.bb |2 +-
> 17 files changed, 50 insertions(+), 42 deletions(-)
>
> diff --git a/conf/bitbake.conf b/conf/bitbake.conf
> index a5d6a1a..30dcd3e 100644
> --- a/conf/bitbake.conf
> +++ b/conf/bitbake.conf
> @@ -675,20 +675,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS"
>
> # Overrides are processed left to right, so the ones that are named later
> take precedence.
> # You generally want them to go from least to most specific.
> -#
> -# This means that an envionment variable named '_arm' overrides an
> -# environment variable '' (when ${TARGET_ARCH} is arm).
> -# an environment variable '_ramses' overrides '' but doesn't
> override
> -# '_arm' when ${MACHINE} is 'ramses'.
> -# If you use combination ie '_arm_ramses', then '_arm_ramses'
> will override
> -# '_arm' and then '' will be overriden with that value from
> '_arm'.
> -# And finally '_local' overrides anything, but with lowest priority.
> -#
> -# This works for functions as well, they are really just environment
> variables.
> -# Default OVERRIDES to make compilation fail fast in case of build system
> misconfiguration.
> -OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-
> ${BUILD_OS}:fail-fast:pn-${PN}"
> -# Alternative OVERRIDES definition without "fail fast", usually only for
> native building and Scratchbox toolchains.
> -#OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-
> ${BUILD_OS}:pn-${PN}"
> +MACHINE_OVERRIDES ?= ""
> +OVERRIDES = "pn-${PN}:fail-fast:build-
> ${BUILD_OS}:${TARGET_ARCH}:${TARGET_OS}:\
> +${DISTRO}:${@':'.join(d.getVar('MACHINE_OVERRIDES',
> True).split())}:${MACHINE}:local"
>
> ##
> # Include the rest of the config files.
> diff --git a/conf/distro/include/arm-thumb.inc b/conf/distro/include/arm-
> thumb.inc
> index 36edd4f..75ed978 100644
> --- a/conf/distro/include/arm-thumb.inc
> +++ b/conf/distro/include/arm-thumb.inc
> @@ -16,9 +16,9 @@ THUMB_INTERWORK ?= "no"
> #arm system and vice versa. It is strongly recommended that DISTROs
> not
> #turn this off - the actual cost is very small.
>
> -OVERRIDE_THUMB = "$...@['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET',
> d, 1) == 'thumb']}"
> -OVERRIDE_INTERWORK = "$...@['', ':thumb-
> interwork'][
Re: [oe] [PATCH 2/2] Fix class OVERRIDES order
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Friday, October 15, 2010 3:32 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase
> Subject: [PATCH 2/2] Fix class OVERRIDES order
>
> * Changed the OVERRIDES settings in the classes to use the new
> ordering.
>
> Signed-off-by: Chase Maupin
I was a little unsure of these which is why I put them in a separate patch.
Should the virtclass overrides be high or low priority? Please feel free to
correct me, but I wanted to make sure that we didn't override "local"
> ---
> classes/native.bbclass|2 +-
> classes/nativesdk.bbclass |2 +-
> classes/sdk.bbclass |2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/classes/native.bbclass b/classes/native.bbclass
> index dcedff2..2e52bfc 100644
> --- a/classes/native.bbclass
> +++ b/classes/native.bbclass
> @@ -94,7 +94,7 @@ DEPENDS_virtclass-native ?= "${ORIG_DEPENDS}"
>
> def native_virtclass_add_override(d):
> if "native" in (bb.data.getVar('BBCLASSEXTEND', d, True) or ""):
> -bb.data.setVar("OVERRIDES", bb.data.getVar("OVERRIDES", d, False)
> + ":virtclass-native", d)
> +bb.data.setVar("OVERRIDES", "virtclass-native:" +
> bb.data.getVar("OVERRIDES", d, False), d)
>
> OVERRIDES .= "$...@native_virtclass_add_override(d)}"
>
> diff --git a/classes/nativesdk.bbclass b/classes/nativesdk.bbclass
> index f3f9930..6f21534 100644
> --- a/classes/nativesdk.bbclass
> +++ b/classes/nativesdk.bbclass
> @@ -52,7 +52,7 @@ export PKG_CONFIG_SYSROOT_DIR = "${STAGING_DIR_HOST}"
> ORIG_DEPENDS := "${DEPENDS}"
> DEPENDS_virtclass-nativesdk ?= "${ORIG_DEPENDS}"
>
> -OVERRIDES .= ":virtclass-nativesdk"
> +OVERRIDES =. "virtclass-nativesdk:"
>
> python __anonymous () {
> pn = bb.data.getVar("PN", d, True)
> diff --git a/classes/sdk.bbclass b/classes/sdk.bbclass
> index c8fa076..1ad8951 100644
> --- a/classes/sdk.bbclass
> +++ b/classes/sdk.bbclass
> @@ -67,4 +67,4 @@ FILES_${PN}-dbg += "${prefix}/.debug \
>
> export PKG_CONFIG_SYSROOT_DIR = "${STAGING_DIR_HOST}"
>
> -OVERRIDES .= ":virtclass-sdk"
> +OVERRIDES =. "virtclass-sdk:"
> --
> 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] qt4: replace underscore with dash in library name
> -Original Message-
> From: Chase Maupin [mailto:chasemaupi...@gmail.com]
> Sent: Tuesday, October 12, 2010 8:25 AM
> To: openembedded-devel@lists.openembedded.org
> Cc: Maupin, Chase; Maupin, Chase
> Subject: [PATCH] qt4: replace underscore with dash in library name
>
> * For libraries that are added to the QT_LIB_NAMES or
> QT_EXTRA_LIBS variables replace any "_" characters in the
> library name with "-" for use in the package name.
> * The actual library file names are left alone.
> * Bump the PR for packages using qt4.inc
>
> Signed-off-by: Chase Maupin
ping
> ---
> recipes/qt4/qt4-embedded.inc |2 +-
> recipes/qt4/qt4-x11-free.inc |2 +-
> recipes/qt4/qt4.inc |4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/recipes/qt4/qt4-embedded.inc b/recipes/qt4/qt4-embedded.inc
> index 111716d..9331302 100644
> --- a/recipes/qt4/qt4-embedded.inc
> +++ b/recipes/qt4/qt4-embedded.inc
> @@ -4,7 +4,7 @@ LICENSE = "GPL QPL"
> PRIORITY = "optional"
> HOMEPAGE = "http://www.trolltech.com";
> DEPENDS += "directfb tslib"
> -INC_PR = "r23"
> +INC_PR = "r24"
>
> QT_BASE_NAME ?= "qt4-embedded"
> QT_BASE_LIB ?= "libqt-embedded"
> diff --git a/recipes/qt4/qt4-x11-free.inc b/recipes/qt4/qt4-x11-free.inc
> index 66e6d1c..ff4e454 100644
> --- a/recipes/qt4/qt4-x11-free.inc
> +++ b/recipes/qt4/qt4-x11-free.inc
> @@ -5,7 +5,7 @@ HOMEPAGE = "http://www.trolltech.com";
> LICENSE = "GPL QPL"
> DEPENDS += "virtual/libx11 fontconfig libxft libxext libxrender libxrandr
> libxcursor"
>
> -INC_PR = "r20"
> +INC_PR = "r21"
>
> SRC_URI = "ftp://ftp.trolltech.com/qt/source/qt-x11-opensource-src-
> ${PV}.tar.gz \
> file://0001-cross-compile.patch \
> diff --git a/recipes/qt4/qt4.inc b/recipes/qt4/qt4.inc
> index ffd56dd..6721265 100644
> --- a/recipes/qt4/qt4.inc
> +++ b/recipes/qt4/qt4.inc
> @@ -34,7 +34,7 @@ python __anonymous () {
> dev_packages = []
> dbg_packages = []
> for name in bb.data.getVar("QT_LIB_NAMES", d, 1).split():
> -pkg = "${QT_BASE_LIB}" + name.lower().replace("qt", "") + "4"
> +pkg = "${QT_BASE_LIB}" + name.lower().replace("qt",
> "").replace("_", "-") + "4"
> # NOTE: the headers for QtAssistantClient are different
> incname = name.replace("QtAssistantClient", "QtAssistant")
> bb.data.setVar("FILES_%s" % pkg,
> "${libdir}/lib%(name)s${QT_LIBINFIX}.so.*" % locals(), d)
> @@ -52,7 +52,7 @@ python __anonymous () {
> dbg_packages.append("%s-dbg" % name)
>
> for name in bb.data.getVar("QT_EXTRA_LIBS", d, 1).split():
> -pkg = "${QT_BASE_LIB}" + name.lower().replace("qt", "") + "4"
> +pkg = "${QT_BASE_LIB}" + name.lower().replace("qt",
> "").replace("_", "-") + "4"
> bb.data.setVar("FILES_%s" % pkg, "${libdir}/lib%(name)s.so.*" %
> locals(), d)
> bb.data.setVar("FILES_%s-dev" % pkg, """${libdir}/lib%(name)s.prl
>${libdir}/lib%(name)s.a
> --
> 1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] qt4: replace underscore with dash in library name
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Holger Freyther > Sent: Monday, October 18, 2010 9:39 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] qt4: replace underscore with dash in library > name > > On 10/12/2010 03:25 PM, Chase Maupin wrote: > > * For libraries that are added to the QT_LIB_NAMES or > > QT_EXTRA_LIBS variables replace any "_" characters in the > > library name with "-" for use in the package name. > > * The actual library file names are left alone. > > * Bump the PR for packages using qt4.inc > > Which library is that? OpenVG? PowerVR related things? In general it looks > fine. In this case it is another library named TICPUBLT_BX which helped me find this issue. So in my recipe I am adding: QT_EXTRA_LIBS += "TICPUBLT_BX" > > Acked-by: Holger Hans Peter Freyther > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] qt4: replace underscore with dash in library name
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Holger Freyther > Sent: Monday, October 18, 2010 11:21 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] qt4: replace underscore with dash in library > name > > On 10/18/2010 05:01 PM, Maupin, Chase wrote: > > > In this case it is another library named TICPUBLT_BX which helped me > find this issue. So in my recipe I am adding: > > > > QT_EXTRA_LIBS += "TICPUBLT_BX" > > Why do you need to patch Qt? :) This library allows Qt to use the NEON processor on our Cortex-A8 for bitblit operations. Currently this recipe is being carried in our overlay but will be moved to the OE mainline once we have all the licensing worked out. > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] qt4: replace underscore with dash in library name
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Holger Freyther > Sent: Monday, October 18, 2010 11:28 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] qt4: replace underscore with dash in library > name > > On 10/18/2010 06:24 PM, Maupin, Chase wrote: > > >> Why do you need to patch Qt? :) > > > > This library allows Qt to use the NEON processor on our Cortex-A8 for > bitblit operations. Currently this recipe is being carried in our overlay > but will be moved to the OE mainline once we have all the licensing worked > out. > > > Interesting, I worked on the raster engine in the 4.7 release cycle, did > some > neon code as well. Samuel has done his version from scratch and integrated > it. > > Is that handwritten neon code or using gcc mnemonics? How does it compare > to > what is in 4.7? Qt 4.7 can use ARM NEON even for string compares and other > parts of libQtCore. This is something a third party did for us. I don't know all the details behind the library, but I do know that there is a patch to Qt to enable it to use our library instead of it's normal routines (this is for 4.6.2). > > > PS: Do you need someone to integrate your patch? The patch to Qt is to use our library. I'd be happy to share the patch to Qt if you are interested, but I don't think it is very useful generically since the licensing of our library says it is only to be used on TI devices (A third party license restriction). Thanks for the offer though. > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
