user layer problem with udev_173.bbappend

user layer problem with udev_173.bbappend

[Lewis, Nick]

I have to alter the protocol that git uses for the udev recipe. Rather than hacking at the udev_173.bbappend at the meta-fsl-arm layer, I have 'done the right thing' and added a priority 6 user layer and made the changes there. However it is not working as I expected. Could you please assist me?

The amendment is:
 $ cat ../sources/meta-nick/recipes-core/udev/udev_173.bbappend
 SRC_URI := "${@oe_filter_out('git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git', '${SRC_URI}', d)}"
 SRC_URI_prepend = "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http "

And the result is:
 | DEBUG: Python function base_do_unpack finished
 | DEBUG: Python function do_unpack finished
 | ERROR: Function failed: Fetcher failure: Fetch command failed with exit code 128, output:
 | sh: 0: getcwd() failed: No such file or directory
 | fatal: Could not get current working directory: No such file or directory
 |
 ERROR: Task 0 (/data/yocto/rootfs_builder/sources/meta-openembedded/meta-oe/recipes-core/udev/udev_173.bb, do_unpack) failed with exit code '1'

Why would git not be able to getcwd in this case?
(I have other bbappend files in the user layer that seem to work ok but this is the only one that shares a corresponding bbappend file with the meta-fsl-arm layer)

Any clues would be gratefully received

The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Angolini Daiane-B19406]

-----Original Message-----
From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Lewis, Nick
Sent: Tuesday, April 16, 2013 11:43 AM
To: 'meta-freescale@yoctoproject.org'
Subject: [meta-freescale] user layer problem with udev_173.bbappend


 > The amendment is:
 > $ cat ../sources/meta-nick/recipes-core/udev/udev_173.bbappend
 > SRC_URI := "${@oe_filter_out('git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git', '${SRC_URI}', d)}"
 > SRC_URI_prepend = "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http "

When you using the bbappend you need to think your source code will be appended in the original recipe.

Do you really want to overwrite the SRC_URI from original recipe? I don´t know the ":=" operant, what does it do?

Daiane

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

> > The amendment is:
> > $ cat ../sources/meta-nick/recipes-core/udev/udev_173.bbappend
> > SRC_URI := "${@oe_filter_out('git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git', '${SRC_URI}', d)}"
> > SRC_URI_prepend = "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http "
>
>When you using the bbappend you need to think your source code will be appended in the original recipe.
>
>Do you really want to overwrite the SRC_URI from original recipe? I don´t know the ":=" operant, what does it do?
>
>Daiane

Daiane

Yes I want to overwrite the SRC_URI but with a slightly different url to that used in the fsl bbappend
I am lead to believe that bbappends are applied in priority order so the fsl bbappend should be applied before mine

so the url should be changed by the bbappend files as follows: tar --> git;protocol=git --> git;protocol=http

--
Nick

The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

>> > The amendment is:
>> > $ cat ../sources/meta-nick/recipes-core/udev/udev_173.bbappend
>> > SRC_URI := "${@oe_filter_out('git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git', '${SRC_URI}', d)}"
>> > SRC_URI_prepend = "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http "
>>
>>When you using the bbappend you need to think your source code will be appended in the original recipe.
>>
>>Do you really want to overwrite the SRC_URI from original recipe? I don´t know the ":=" operant, what does it do?
>>
>>Daiane
>
>Daiane
>
>Yes I want to overwrite the SRC_URI but with a slightly different url to that used in the fsl bbappend I am lead to
>believe that bbappends are applied in priority order so the fsl bbappend should be applied before mine
>
>so the url should be changed by the bbappend files as follows: tar --> git;protocol=git --> git;protocol=http
>

I have now tried bitbake -e udev | grep SRC_URI=
which gives


# SRC_URI=git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git file://0001-rip-put-doc-generation-it-depends-on-a-working-docto.patch file://gtk-doc.make file://touchscreen.rules file://modprobe.rules file://default file://init file://cache
SRC_URI="git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git file://0001-rip-put-doc-generation-it-depends-on-a-working-docto.patch file://gtk-doc.make file://touchscreen.rules file://modprobe.rules file://default file://init file://cache"


so the git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git is not being filtered out
Any ideas why not?

--
Nick


The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Fabio Estevam]

Nick,

On Tue, Apr 16, 2013 at 12:12 PM, Lewis, Nick <nick.lewis@usa.g4s.com> wrote:

> This communication may contain information which is confidential, personal and/or privileged.
>
> It is for the exclusive use of the intended recipient(s).
> If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Please remove such disclaimers when posting into a public list.

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

>> This communication may contain information which is confidential, personal and/or privileged.
>>
>> It is for the exclusive use of the intended recipient(s).
>> If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this
>> communication or the information in it is strictly prohibited.

>Please remove such disclaimers when posting into a public list.

I am sorry that this is outside of my control

Regarding "intended recipients", I intend that all subscribers to the list receive from me any emails that are addressed to the list

I understand that some list-reading tools can make use of the double dash to control how an email is presented

--
Nick

The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Angolini Daiane-B19406]

No, I don´t.

This is the definition of oe_filter_out:

def str_filter_out(f, str, d):
    from re import match
    return " ".join(filter(lambda x: not match(f, x, 0), str.split()))

Do you understand it?


Until no one else reply, you can try to force the override (by doing SRC_URI="what you want") And don´t forget to define SRCREV


Daiane



-----Original Message-----
From: Lewis, Nick [mailto:nick.lewis@usa.g4s.com] 
Sent: Tuesday, April 16, 2013 12:13 PM
To: Angolini Daiane-B19406; 'meta-freescale@yoctoproject.org'
Subject: RE: user layer problem with udev_173.bbappend

>> > The amendment is:
>> > $ cat ../sources/meta-nick/recipes-core/udev/udev_173.bbappend
>> > SRC_URI := "${@oe_filter_out('git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git', '${SRC_URI}', d)}"
>> > SRC_URI_prepend = "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http "
>>
>>When you using the bbappend you need to think your source code will be appended in the original recipe.
>>
>>Do you really want to overwrite the SRC_URI from original recipe? I don´t know the ":=" operant, what does it do?
>>
>>Daiane
>
>Daiane
>
>Yes I want to overwrite the SRC_URI but with a slightly different url 
>to that used in the fsl bbappend I am lead to believe that bbappends 
>are applied in priority order so the fsl bbappend should be applied 
>before mine
>
>so the url should be changed by the bbappend files as follows: tar --> 
>git;protocol=git --> git;protocol=http
>

I have now tried bitbake -e udev | grep SRC_URI= which gives


# SRC_URI=git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git file://0001-rip-put-doc-generation-it-depends-on-a-working-docto.patch file://gtk-doc.make file://touchscreen.rules file://modprobe.rules file://default file://init file://cache SRC_URI="git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git file://0001-rip-put-doc-generation-it-depends-on-a-working-docto.patch file://gtk-doc.make file://touchscreen.rules file://modprobe.rules file://default file://init file://cache"


so the git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git is not being filtered out Any ideas why not?

--
Nick

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

>Until no one else reply, you can try to force the override (by doing SRC_URI="what you want") And don´t forget to define SRCREV
>
>Daiane

Thanks this would be a better approach

I have found that the filter out is actually working ok but I am not understanding how multiple SRC_URI_prepend lines interact with each other or their affect during SRC_URI:="${SRC_URI}"

--
Nick


The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

>Until no one else reply, you can try to force the override (by doing SRC_URI="what you want") And don´t forget to define SRCREV
>
>Daiane

Overriding does not seem to work as any previously defined SRC_URI_prepend still gets applied

I have tried:

SRC_URI_TMP := "${@oe_filter_out('git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git', '${SRC_URI}', d)}"
SRC_URI_TMP =+ "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=http "
OVERRIDES = "nick"
SRC_URI_nick := "${SRC_URI_TMP}"

and bitbake -e shows that SRC_URI_TMP is fine but SRC_URI has the prepend from the meta-fsl-arm layer

--
Nick


The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

I have preformed a little experiment comparing the 'VAR=+' and the 'VAR_prepend=' bitbake operators:

 TEST1 = "test1old"
 TEST1 =+ "pre"
 TEST1 = "test1new"
 TEST1 := "${TEST1}"

 TEST2 = "test2old"
 TEST2_prepend = "pre "
 TEST2 = "test2new"
 TEST2 := "${TEST2}"

and grepping bitbake -e gives:
 TEST1="test1new"
 TEST2="pre pre test2new"

It appears that 'VAR_prepend=' is actioned every time VAR is evaluated.
This behaviour means that a prepend at any layer is irrevocable by a higher priority layer

Is this a bug in bitbake?

Could Freescale use 'VAR=+' instead of 'VAR_prepend=' in the bbappend files at the meta-fsl-arm layer to allow the user layer to alter it?

--
Nick

The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Otavio Salvador]

On Wed, Apr 17, 2013 at 8:15 AM, Lewis, Nick <nick.lewis@usa.g4s.com> wrote:
> It appears that 'VAR_prepend=' is actioned every time VAR is evaluated.
> This behaviour means that a prepend at any layer is irrevocable by a higher priority layer
>
> Is this a bug in bitbake?
>
> Could Freescale use 'VAR=+' instead of 'VAR_prepend=' in the bbappend files at the meta-fsl-arm layer to allow the user layer to alter it?

Yes, we can use 'VAR +=' but the biggest problem is why you need to
override it. You will have problems with other recipes as we use git
protocol for many recipes.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

>Yes, we can use 'VAR +=' but the biggest problem is why you need to override it.

Generally speaking there may be any number of reasons by a client layer may want to override something in the meta-fsl layer or another serving layer.
'VAR_prepend =' breaks the whole layering concept. For this reason alone I ask that it be replaced


The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

>Yes, we can use 'VAR +=' but the biggest problem is why you need to override it.

Generally speaking there may be any number of reasons why a client layer may want to override something in the meta-fsl layer or another serving layer.
'VAR_prepend =' breaks the whole layering concept. For this reason alone I ask that it be replaced

--
Nick


The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Daiane Angolini]

On 04/18/2013 05:08 AM, Lewis, Nick wrote:
>> Yes, we can use 'VAR +=' but the biggest problem is why you need to override it.
>
> Generally speaking there may be any number of reasons by a client layer may want to override something in the meta-fsl layer or another serving layer.
> 'VAR_prepend =' breaks the whole layering concept. For this reason alone I ask that it be replaced
>

I agree and I think it's a good reason.

Could you, please, send the patch?
(and please, use git and git format-patch to create your patch. and git 
send-email to sent your patch)

Otavio, how long danny will be supported after dylan being released? 
What's the "usual way"?

Daiane

Re: user layer problem with udev_173.bbappend

[Otavio Salvador]

On Thu, Apr 18, 2013 at 8:47 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/18/2013 05:08 AM, Lewis, Nick wrote:
>>>
>>> Yes, we can use 'VAR +=' but the biggest problem is why you need to
>>> override it.
>>
>>
>> Generally speaking there may be any number of reasons by a client layer
>> may want to override something in the meta-fsl layer or another serving
>> layer.
>> 'VAR_prepend =' breaks the whole layering concept. For this reason alone I
>> ask that it be replaced
>>
>
> I agree and I think it's a good reason.
>
> Could you, please, send the patch?
> (and please, use git and git format-patch to create your patch. and git
> send-email to sent your patch)

Agreed here.

> Otavio, how long danny will be supported after dylan being released? What's
> the "usual way"?

I checked with Ross and it will maintained until 1.5 is out.

We should have a 1.3.2 after 1.4 release.

Regards,

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

>Could you, please, send the patch?
>(and please, use git and git format-patch to create your patch. and git send-email to sent your patch)

Please find git format-patch at:
http://pastebin.com/4fFWJR48

(because I doubt git-send-email supports MAPI)
--
Nick

The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Otavio Salvador]

On Thu, Apr 18, 2013 at 10:09 AM, Lewis, Nick <nick.lewis@usa.g4s.com> wrote:
>>Could you, please, send the patch?
>>(and please, use git and git format-patch to create your patch. and git send-email to sent your patch)
>
> Please find git format-patch at:
> http://pastebin.com/4fFWJR48
>
> (because I doubt git-send-email supports MAPI)

The patch:

 * lacks author
 * lacks autor e-mail
 * lacks commit log
 * lacks Signed-off-by

The change is right but the information in the patch is not.

pastebin is not good to review patches please check for an alternative
e-mail (Gmail, or other) so you can easily contribute.

Regards,

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

>The patch:
>
> * lacks author
> * lacks autor e-mail
> * lacks commit log
> * lacks Signed-off-by
>
>The change is right but the information in the patch is not.

Here is the output from "git format-patch -s1 HEAD" after adding my details to "git config":

From 0f99f71ece252a6c89bd366b5e7f3f6e7de7c3c6 Mon Sep 17 00:00:00 2001
From: Nick Lewis <nick.lewis@usa.g4s.com>
Date: Wed, 17 Apr 2013 01:56:18 -0700
Subject: [PATCH] replace _prepend operator


Signed-off-by: Nick Lewis <nick.lewis@usa.g4s.com>
---
 recipes-core/udev/udev_173.bbappend |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/udev/udev_173.bbappend b/recipes-core/udev/udev_173.bbappend
index 29b20bd..cc80400 100644
--- a/recipes-core/udev/udev_173.bbappend
+++ b/recipes-core/udev/udev_173.bbappend
@@ -4,5 +4,5 @@ PRINC := "${@int(PRINC) + 2}"
 # 173 tag
 SRCREV = "ad667dff51711fed763a23283d973486de3cd6b5"
 SRC_URI := "${@oe_filter_out('${KERNELORG_MIRROR}/linux/utils/kernel/hotplug/udev-${PV}.tar.bz2', '${SRC_URI}', d)}"
-SRC_URI_prepend = "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git "
+SRC_URI =+ "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git"
 S = "${WORKDIR}/git"
--
1.7.9.5

--
Nick

The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Otavio Salvador]

On Fri, Apr 19, 2013 at 5:54 AM, Lewis, Nick <nick.lewis@usa.g4s.com> wrote:
>>The patch:
>>
>> * lacks author
>> * lacks autor e-mail
>> * lacks commit log
>> * lacks Signed-off-by
>>
>>The change is right but the information in the patch is not.
>
> Here is the output from "git format-patch -s1 HEAD" after adding my details to "git config":
>
> From 0f99f71ece252a6c89bd366b5e7f3f6e7de7c3c6 Mon Sep 17 00:00:00 2001
> From: Nick Lewis <nick.lewis@usa.g4s.com>

Good.

> Date: Wed, 17 Apr 2013 01:56:18 -0700
> Subject: [PATCH] replace _prepend operator
>

Wrong.

The commit log needs to explain why you did it and what it affects so
something like:

---
udev: Avoid using _prepend operator for SRC_URI

Using _prepend makes override in another layer harder so we replace it
by '=+' operator.
---

So please fix this. You can use the suggested commit log as base but
you can change it as you wish ... but please make it as complete as
possible.

> Signed-off-by: Nick Lewis <nick.lewis@usa.g4s.com>

Good.

> The details of this company are as follows:
> G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.
>
> This communication may contain information which is confidential, personal and/or privileged.
>
> It is for the exclusive use of the intended recipient(s).
> If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.
>
> Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.
>
> Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.
>
> This e-mail has been scanned for all viruses by MessageLabs.

Bad; the disclaimer is still here.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: user layer problem with udev_173.bbappend

[Lewis, Nick]

>Wrong.
>...
>So please fix this.
As a git newbie I appreciate your helpful (if somewhat curt) advice. I hope I have got the hang of it now

>Bad; the disclaimer is still here.
I will apply for an exemption from the corporate prohibition on the use of webmail but unless and until then I regret that the disclaimer will appear



From 9570505b16d11ed194b6b4f90a018fd488330bce Mon Sep 17 00:00:00 2001
From: Nick Lewis <nick.lewis@usa.g4s.com>
Date: Wed, 17 Apr 2013 05:55:05 -0700
Subject: [PATCH] udev: Replaced _prepend operator in SRC_URI

The use of the _prepend and _append operators adversely affects layering by impeding the ability to override its action in another layer. The operators += .= =+ =. do not cause such problems. The _prepend operator is therefore replaced by the =+ operator which also tidies trailing space in the string

Signed-off-by: Nick Lewis <nick.lewis@usa.g4s.com>
---
 recipes-core/udev/udev_173.bbappend |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/udev/udev_173.bbappend b/recipes-core/udev/udev_173.bbappend
index 29b20bd..cc80400 100644
--- a/recipes-core/udev/udev_173.bbappend
+++ b/recipes-core/udev/udev_173.bbappend
@@ -4,5 +4,5 @@ PRINC := "${@int(PRINC) + 2}"
 # 173 tag
 SRCREV = "ad667dff51711fed763a23283d973486de3cd6b5"
 SRC_URI := "${@oe_filter_out('${KERNELORG_MIRROR}/linux/utils/kernel/hotplug/udev-${PV}.tar.bz2', '${SRC_URI}', d)}"
-SRC_URI_prepend = "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git "
+SRC_URI =+ "git://git.kernel.org/pub/scm/linux/hotplug/udev.git;protocol=git"
 S = "${WORKDIR}/git"
--
1.7.9.5



--
Nick

The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

Re: user layer problem with udev_173.bbappend

[Otavio Salvador]

On Fri, Apr 19, 2013 at 10:11 AM, Lewis, Nick <nick.lewis@usa.g4s.com> wrote:
>>Wrong.
>>...
>>So please fix this.
> As a git newbie I appreciate your helpful (if somewhat curt) advice. I hope I have got the hang of it now

:-)

>>Bad; the disclaimer is still here.
> I will apply for an exemption from the corporate prohibition on the use of webmail but unless and until then I regret that the disclaimer will appear

Thanks.

> From 9570505b16d11ed194b6b4f90a018fd488330bce Mon Sep 17 00:00:00 2001
> From: Nick Lewis <nick.lewis@usa.g4s.com>
> Date: Wed, 17 Apr 2013 05:55:05 -0700
> Subject: [PATCH] udev: Replaced _prepend operator in SRC_URI
>
> The use of the _prepend and _append operators adversely affects layering by impeding the ability to override its action in another layer. The operators += .= =+ =. do not cause such problems. The _prepend operator is therefore replaced by the =+ operator which also tidies trailing space in the string

Much better. Just a minor issue, please split lines in 80cols.

> Signed-off-by: Nick Lewis <nick.lewis@usa.g4s.com>

I cannot pick the patch from an e-mail so please make the split of
lines and send it attached, until you fix your e-mail setting, so I
can apply it.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: user layer problem with udev_173.bbappend

[Otavio Salvador]

On Thu, Apr 18, 2013 at 5:08 AM, Lewis, Nick <nick.lewis@usa.g4s.com> wrote:
>>Yes, we can use 'VAR +=' but the biggest problem is why you need to override it.
>
> Generally speaking there may be any number of reasons by a client layer may want to override something in the meta-fsl layer or another serving layer.
> 'VAR_prepend =' breaks the whole layering concept. For this reason alone I ask that it be replaced

Something in preprend is not supposed to be overriden. I also fail to
see a legitimate reason to override the server to be used. As I
explained in the other e-mail there're mechanisms for using the git
protocol thought proxy documented.

If someone sends the patch to change the SRC_URI_prepend to SRC_URI +=
I am fine to apply as it will for in same way for our use. Changing
protocol is not an option as it is a workaround and git implementation
using http is fragile.

> The details of this company are as follows:
> G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.
>
> This communication may contain information which is confidential, personal and/or privileged.
>
> It is for the exclusive use of the intended recipient(s).
> If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.
>
> Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.
>
> Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.
>
> This e-mail has been scanned for all viruses by MessageLabs.

You're using an e-mail with a risky disclaimer. Please fix this or use
another e-mail to communicate with the mailing list. This disclaimer
is not something welcome in public mailing list as it impose possible
restrictions on the information shared by it. Please check it.

Regards,


--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br