Patchwork ti_cgt_c6000_6.1.17_setup_linux_x86.bin error while installing ti-codec-engine

On Fri, Sep 23, 2011 at 6:47 AM, Gary Thomas wrote:
> Check to make sure that you don't have write permission to /opt
> If you have write permission in the directory /opt, the installer
> fails to put the tools where they belong in your OE build.

Is it generally known that this limitation is due to a bug in
ti-eula-unpack.inc?  (Python's print automatically adds a newline,
which the code's author apparently did not expect.)  My local repo has
these changes to allow in-tree installs by users with write access to
/opt; please pardon Gmail's mangling of leading whitespace:

On 2011-09-23 14:46, Michael Poole wrote:
> On Fri, Sep 23, 2011 at 6:47 AM, Gary Thomas wrote:
>> Check to make sure that you don't have write permission to /opt
>> If you have write permission in the directory /opt, the installer
>> fails to put the tools where they belong in your OE build.
>
> Is it generally known that this limitation is due to a bug in
> ti-eula-unpack.inc?  (Python's print automatically adds a newline,
> which the code's author apparently did not expect.)  My local repo has
> these changes to allow in-tree installs by users with write access to
> /opt; please pardon Gmail's mangling of leading whitespace:

I don't know if this is a generally known fact; it should be, I reported it to
this list more than a year ago and was basically ignored [actually told I just
shouldn't have write access to /opt so the issue was my own fault...]

Does the unpack work with your patches if /opt is not writeable?

>
> diff --git a/recipes/powervr-drivers/libgles-omap3.inc b/recipes/powervr-driv
> index ab4b248..5acc4da 100644
> --- a/recipes/powervr-drivers/libgles-omap3.inc
> +++ b/recipes/powervr-drivers/libgles-omap3.inc
> @@ -19,7 +19,8 @@ SRC_URI = "http://software-dl.ti.com/dsps/dsps_public_sw/sd
>   S = "${WORKDIR}/OMAP35x_Graphics_SDK_${SGXPV}"
>
>   # Logic to unpack installjammer file
> -TI_BIN_UNPK_CMDS="Y: qY:workdir:Y"
> +TI_BIN_UNPK_CMDS="Y:workdir"
> +TI_BIN_UNPK_WDEXT = "/Graphics_SDK_${SGXPV}"
>   require ../ti/ti-eula-unpack.inc
>
>   BINLOCATION ?= "${S}/gfx_rel"
> diff --git a/recipes/powervr-drivers/omap3-sgx-modules_1.6.16.3977.bb b/recip
> index 216b3ae..be4b7a1 100644
> --- a/recipes/powervr-drivers/omap3-sgx-modules_1.6.16.3977.bb
> +++ b/recipes/powervr-drivers/omap3-sgx-modules_1.6.16.3977.bb
> @@ -5,7 +5,8 @@ LICENSE = "GPLv2"
>   # http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/
>   # see libgles-omap3.inc for detailed installation instructions
>
> -TI_BIN_UNPK_CMDS="Y: qY:workdir:Y"
> +TI_BIN_UNPK_CMDS="Y:workdir:"
> +TI_BIN_UNPK_WDEXT = "/Graphics_SDK_${SGXPV}"
>   require ../ti/ti-eula-unpack.inc
>
>   SGXPV = "4_03_00_02"
> diff --git a/recipes/ti/ti-eula-unpack.inc b/recipes/ti/ti-eula-unpack.inc
> index 3b79c24..82ea785 100644
> --- a/recipes/ti/ti-eula-unpack.inc
> +++ b/recipes/ti/ti-eula-unpack.inc
> @@ -53,7 +53,7 @@ python ti_bin_do_unpack() {
>               wdext = bb.data.getVar('TI_BIN_UNPK_WDEXT', localdata)
>               wdext = bb.data.expand(wdext, localdata)
>               cmd = workdir+wdext
> -        print>>f, "%s\n" % cmd
> +        print>>f, "%s" % cmd
>       f.close()
>
>       # Expand the tarball that was created if required
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Actually i copy them from /opt/ti manually and paste them where they must be.. And i can basically say: no it is not known and it is not easy problem to fix if you are beginner at both bitbake and openembedded. There was no-answer for this situation. but i added a reply to a forum which has the same problem with me and waiting for the reply..

On 2011-09-23 14:46, Michael Poole wrote:
> On Fri, Sep 23, 2011 at 6:47 AM, Gary Thomas wrote:
>> Check to make sure that you don't have write permission to /opt
>> If you have write permission in the directory /opt, the installer
>> fails to put the tools where they belong in your OE build.
>
> Is it generally known that this limitation is due to a bug in
> ti-eula-unpack.inc?  (Python's print automatically adds a newline,
> which the code's author apparently did not expect.)  My local repo has
> these changes to allow in-tree installs by users with write access to
> /opt; please pardon Gmail's mangling of leading whitespace:

>I don't know if this is a generally known fact; it should be, I reported it to
>this list more than a year ago and was basically ignored [actually told I just
>shouldn't have write access to /opt so the issue was my own fault...]

>Does the unpack work with your patches if /opt is not writeable?

>
> diff --git a/recipes/powervr-drivers/libgles-omap3.inc b/recipes/powervr-driv
> index ab4b248..5acc4da 100644
> --- a/recipes/powervr-drivers/libgles-omap3.inc
> +++ b/recipes/powervr-drivers/libgles-omap3.inc
> @@ -19,7 +19,8 @@ SRC_URI = "http://software-dl.ti.com/dsps/dsps_public_sw/sd
>   S = "${WORKDIR}/OMAP35x_Graphics_SDK_${SGXPV}"
>
>   # Logic to unpack installjammer file
> -TI_BIN_UNPK_CMDS="Y: qY:workdir:Y"
> +TI_BIN_UNPK_CMDS="Y:workdir"
> +TI_BIN_UNPK_WDEXT = "/Graphics_SDK_${SGXPV}"
>   require ../ti/ti-eula-unpack.inc
>
>   BINLOCATION ?= "${S}/gfx_rel"
> diff --git a/recipes/powervr-drivers/omap3-sgx-modules_1.6.16.3977.bb b/recip
> index 216b3ae..be4b7a1 100644
> --- a/recipes/powervr-drivers/omap3-sgx-modules_1.6.16.3977.bb
> +++ b/recipes/powervr-drivers/omap3-sgx-modules_1.6.16.3977.bb
> @@ -5,7 +5,8 @@ LICENSE = "GPLv2"
>   # http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/
>   # see libgles-omap3.inc for detailed installation instructions
>
> -TI_BIN_UNPK_CMDS="Y: qY:workdir:Y"
> +TI_BIN_UNPK_CMDS="Y:workdir:"
> +TI_BIN_UNPK_WDEXT = "/Graphics_SDK_${SGXPV}"
>   require ../ti/ti-eula-unpack.inc
>
>   SGXPV = "4_03_00_02"
> diff --git a/recipes/ti/ti-eula-unpack.inc b/recipes/ti/ti-eula-unpack.inc
> index 3b79c24..82ea785 100644
> --- a/recipes/ti/ti-eula-unpack.inc
> +++ b/recipes/ti/ti-eula-unpack.inc
> @@ -53,7 +53,7 @@ python ti_bin_do_unpack() {
>               wdext = bb.data.getVar('TI_BIN_UNPK_WDEXT', localdata)
>               wdext = bb.data.expand(wdext, localdata)
>               cmd = workdir+wdext
> -        print>>f, "%s\n" % cmd
> +        print>>f, "%s" % cmd
>       f.close()
>
>       # Expand the tarball that was created if required
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

On Sat, Sep 24, 2011 at 6:45 AM, Gary Thomas wrote:
> On 2011-09-23 14:46, Michael Poole wrote:
>>
>> On Fri, Sep 23, 2011 at 6:47 AM, Gary Thomas wrote:
>>>
>>> Check to make sure that you don't have write permission to /opt
>>> If you have write permission in the directory /opt, the installer
>>> fails to put the tools where they belong in your OE build.
>>
>> Is it generally known that this limitation is due to a bug in
>> ti-eula-unpack.inc?  (Python's print automatically adds a newline,
>> which the code's author apparently did not expect.)  My local repo has
>> these changes to allow in-tree installs by users with write access to
>> /opt; please pardon Gmail's mangling of leading whitespace:
>
> I don't know if this is a generally known fact; it should be, I reported it
> to
> this list more than a year ago and was basically ignored [actually told I
> just
> shouldn't have write access to /opt so the issue was my own fault...]
>
> Does the unpack work with your patches if /opt is not writeable?

Yes, it does.  (It took a few days for me to find time to do a clean
rebuild on a system where I didn't need write access to /opt.)

Michael Poole

On 2011-09-28 08:58, Michael Poole wrote:
> On Sat, Sep 24, 2011 at 6:45 AM, Gary Thomas wrote:
>> On 2011-09-23 14:46, Michael Poole wrote:
>>>
>>> On Fri, Sep 23, 2011 at 6:47 AM, Gary Thomas wrote:
>>>>
>>>> Check to make sure that you don't have write permission to /opt
>>>> If you have write permission in the directory /opt, the installer
>>>> fails to put the tools where they belong in your OE build.
>>>
>>> Is it generally known that this limitation is due to a bug in
>>> ti-eula-unpack.inc?  (Python's print automatically adds a newline,
>>> which the code's author apparently did not expect.)  My local repo has
>>> these changes to allow in-tree installs by users with write access to
>>> /opt; please pardon Gmail's mangling of leading whitespace:
>>
>> I don't know if this is a generally known fact; it should be, I reported it
>> to
>> this list more than a year ago and was basically ignored [actually told I
>> just
>> shouldn't have write access to /opt so the issue was my own fault...]
>>
>> Does the unpack work with your patches if /opt is not writeable?
>
> Yes, it does.  (It took a few days for me to find time to do a clean
> rebuild on a system where I didn't need write access to /opt.)

Thanks for checking.

Will you push these changes into meta-texasinstruments (please)?

On Wed, Sep 28, 2011 at 11:08 AM, Gary Thomas wrote:
> On 2011-09-28 08:58, Michael Poole wrote:
>>
>> On Sat, Sep 24, 2011 at 6:45 AM, Gary Thomas wrote:
>>>
>>> On 2011-09-23 14:46, Michael Poole wrote:
>>>>
>>>> On Fri, Sep 23, 2011 at 6:47 AM, Gary Thomas wrote:
>>>>>
>>>>> Check to make sure that you don't have write permission to /opt
>>>>> If you have write permission in the directory /opt, the installer
>>>>> fails to put the tools where they belong in your OE build.
>>>>
>>>> Is it generally known that this limitation is due to a bug in
>>>> ti-eula-unpack.inc?  (Python's print automatically adds a newline,
>>>> which the code's author apparently did not expect.)  My local repo has
>>>> these changes to allow in-tree installs by users with write access to
>>>> /opt; please pardon Gmail's mangling of leading whitespace:
>>>
>>> I don't know if this is a generally known fact; it should be, I reported
>>> it
>>> to
>>> this list more than a year ago and was basically ignored [actually told I
>>> just
>>> shouldn't have write access to /opt so the issue was my own fault...]
>>>
>>> Does the unpack work with your patches if /opt is not writeable?
>>
>> Yes, it does.  (It took a few days for me to find time to do a clean
>> rebuild on a system where I didn't need write access to /opt.)
>
> Thanks for checking.
>
> Will you push these changes into meta-texasinstruments (please)?

Yes, I can check it against that and submit a patch.  I have been
using OE-classic to date, so it might take a bit for me to get that
build right.

Michael Poole