linux-yocto-3.4: Disable extra slang header search path

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

Signed-off-by Richard Purdie <[email protected]>

---

meta/recipes-kernel/linux/linux-yocto/noslang.patch renamed from dev/null +20 -0

new file mode 100644
index 0000000..9cada34
@@ -0,0 +1,20 @@
+We (OE) install slang into /usr/include so we never need to look into
+/usr/include/slang/. We never want to look into a hardcoded path like this
+since it triggers host infection issues. For now, simply remove this
+since it causes us problems.
+
+Upstream-Status: Pending (would need rework)
+
+Index: tools/perf/Makefile
+===================================================================
+--- linux.orig/tools/perf/Makefile     2012-08-07 10:29:43.020149620 +0000
++++ linux/tools/perf/Makefile  2012-08-07 10:30:08.128148098 +0000
+@@ -504,7 +504,7 @@
+               BASIC_CFLAGS += -DNO_NEWT_SUPPORT
+       else
+               # Fedora has /usr/include/slang/slang.h, but ubuntu /usr/include/slang.h
+-              BASIC_CFLAGS += -I/usr/include/slang
++              # BASIC_CFLAGS += -I/usr/include/slang
+               EXTLIBS += -lnewt -lslang
+               LIB_OBJS += $(OUTPUT)util/ui/setup.o
+               LIB_OBJS += $(OUTPUT)util/ui/browser.o

meta/recipes-kernel/linux/linux-yocto_3.4.bb +2 -0

index 48333b3..5ab46b7 100644
@@ -20,6 +20,8 @@ SRCREV_meta ?= "7ff48aa47c50b6455d60ca93bc81260ce8fe1a1b"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
 
+SRC_URI += "file://noslang.patch"
+
 LINUX_VERSION ?= "3.4.6"
 
 PR = "${INC_PR}.0"

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

Signed-off-by Richard Purdie<[email protected]>

---

meta/recipes-kernel/linux/linux-yocto/noslang.patch renamed from dev/null +20 -0

new file mode 100644
index 0000000..9cada34
@@ -0,0 +1,20 @@
+We (OE) install slang into /usr/include so we never need to look into
+/usr/include/slang/. We never want to look into a hardcoded path like this
+since it triggers host infection issues. For now, simply remove this
+since it causes us problems.
+
+Upstream-Status: Pending (would need rework)
+
+Index: tools/perf/Makefile
+===================================================================
+--- linux.orig/tools/perf/Makefile	2012-08-07 10:29:43.020149620 +0000
++++ linux/tools/perf/Makefile	2012-08-07 10:30:08.128148098 +0000
+@@ -504,7 +504,7 @@
+ 		BASIC_CFLAGS += -DNO_NEWT_SUPPORT
+ 	else
+ 		# Fedora has /usr/include/slang/slang.h, but ubuntu /usr/include/slang.h
+-		BASIC_CFLAGS += -I/usr/include/slang
++		# BASIC_CFLAGS += -I/usr/include/slang
+ 		EXTLIBS += -lnewt -lslang
+ 		LIB_OBJS += $(OUTPUT)util/ui/setup.o
+ 		LIB_OBJS += $(OUTPUT)util/ui/browser.o

meta/recipes-kernel/linux/linux-yocto_3.4.bb +2 -0

index 48333b3..5ab46b7 100644
@@ -20,6 +20,8 @@ SRCREV_meta ?= "7ff48aa47c50b6455d60ca93bc81260ce8fe1a1b"
 
  SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
 
+SRC_URI += "file://noslang.patch"
+
  LINUX_VERSION ?= "3.4.6"
 
  PR = "${INC_PR}.0"

Quoted 4 lines · Richard Purdie

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

I just followed up on a patch from 3 days ago, but I'll follow up here as well .. just to make sure the message gets through.

We had a pending patch to fix this issue from Liang Li here @ windriver.

Did that patch not fix the problem, or did it fall through the cracks ?

Quoted 9 lines · Bruce Ashfield

Quoted 4 lines · Richard Purdie

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

I just followed up on a patch from 3 days ago, but I'll follow up here as well .. just to make sure the message gets through.

Quoted 3 lines

We had a pending patch to fix this issue from Liang Li here @ windriver.

Did that patch not fix the problem, or did it fall through the cracks ?

It is not correct. It adds in another search path and just hides the issue. We should *never* be putting -I/usr/include/slang on the compiler commandline at all period.

I'd assumed in all the email traffic that this was clear and that another solution was being worked on that would be acceptable upstream too.

Perhaps a better option might be: -I=/usr/include/slang ? That assumes that all kernel gcc versions would accept the = notation, that should be true by now?

Cheers,

Richard

Quoted 14 lines · Richard Purdie

Quoted 12 lines · Bruce Ashfield

Quoted 5 lines · Richard Purdie

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

I just followed up on a patch from 3 days ago, but I'll follow up here as well .. just to make sure the message gets through.

Quoted 8 lines

Quoted 3 lines

We had a pending patch to fix this issue from Liang Li here @ windriver.

Did that patch not fix the problem, or did it fall through the cracks ?

It is not correct. It adds in another search path and just hides the issue. We should *never* be putting -I/usr/include/slang on the compiler commandline at all period.

I'd argue that it's more correct than commenting out the upstream include path.

It fixes the problem, doesn't require a patch to the kernel and give us time to work upstream and get a real fix.

So I'd really prefer that we take that fix, versus the kernel patch if it actually fixes the problem.

Quoted 4 lines

I'd assumed in all the email traffic that this was clear and that another solution was being worked on that would be acceptable upstream too.

Exactly what I referred to above. But we don't want a temporary kernel path, we want the temporary recipe patch.

Quoted 1 line

Quoted 3 lines

Perhaps a better option might be: -I=/usr/include/slang ? That assumes that all kernel gcc versions would accept the = notation, that should be true by now?

Not in my experience when dealing with the upstream kernel and tools, there are plenty of old compilers floating around.

Quoted 51 lines · Bruce Ashfield

Quoted 14 lines · Richard Purdie

Quoted 12 lines · Bruce Ashfield

Quoted 5 lines · Richard Purdie

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

I just followed up on a patch from 3 days ago, but I'll follow up here as well .. just to make sure the message gets through.

Quoted 8 lines

Quoted 3 lines

We had a pending patch to fix this issue from Liang Li here @ windriver.

Did that patch not fix the problem, or did it fall through the cracks ?

It is not correct. It adds in another search path and just hides the issue. We should *never* be putting -I/usr/include/slang on the compiler commandline at all period.

I'd argue that it's more correct than commenting out the upstream include path.

It fixes the problem, doesn't require a patch to the kernel and give us time to work upstream and get a real fix.

So I'd really prefer that we take that fix, versus the kernel patch if it actually fixes the problem.

Quoted 4 lines

I'd assumed in all the email traffic that this was clear and that another solution was being worked on that would be acceptable upstream too.

Exactly what I referred to above. But we don't want a temporary kernel path, we want the temporary recipe patch.

Quoted 4 lines

Perhaps a better option might be: -I=/usr/include/slang ? That assumes that all kernel gcc versions would accept the = notation, that should be true by now?

Quoted 2 lines

Not in my experience when dealing with the upstream kernel and tools, there are plenty of old compilers floating around.

Sorry, I'm not following this thread super close.. will all kernel trees need to apply this patch? That does not seem ideal...

-M

Quoted 68 lines · On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:

Quoted 63 lines · Bruce Ashfield

Quoted 21 lines · Richard Purdie

Quoted 18 lines · Bruce Ashfield

Quoted 6 lines · Richard Purdie

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

I just followed up on a patch from 3 days ago, but I'll follow up here as well .. just to make sure the message gets through.

We had a pending patch to fix this issue from Liang Li here @ windriver.

Quoted 7 lines

Quoted 1 line

Did that patch not fix the problem, or did it fall through the cracks ?

It is not correct. It adds in another search path and just hides the issue. We should *never* be putting -I/usr/include/slang on the compiler commandline at all period.

I'd argue that it's more correct than commenting out the upstream include path.

It fixes the problem, doesn't require a patch to the kernel and give us time to work upstream and get a real fix.

So I'd really prefer that we take that fix, versus the kernel patch if it actually fixes the problem.

Quoted 4 lines

I'd assumed in all the email traffic that this was clear and that another solution was being worked on that would be acceptable upstream too.

Exactly what I referred to above. But we don't want a temporary kernel path, we want the temporary recipe patch.

Quoted 4 lines

Perhaps a better option might be: -I=/usr/include/slang ? That assumes that all kernel gcc versions would accept the = notation, that should be true by now?

Not in my experience when dealing with the upstream kernel and tools, there are plenty of old compilers floating around.

Quoted 2 lines

Sorry, I'm not following this thread super close.. will all kernel trees need to apply this patch? That does not seem ideal...

They would, once we get the patch merged upstream. And you are right, linux-yocto is easy enough, but that's one set of kernel trees.

The patch that we proposed to the perf recipe would fix it for all users of that recipe, with a suitable set of kernels (say 3.0 to 3.6 (I haven't checked).

Honestly, that's why we proposed a perf recipe fix, while working on the right fix for the upstream kernel.

Cheers,

Bruce

Quoted 2 lines

-M

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 69 lines · Bruce Ashfield

Quoted 68 lines · On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:

Quoted 63 lines · Bruce Ashfield

Quoted 21 lines · Richard Purdie

Quoted 18 lines · Bruce Ashfield

Quoted 6 lines · Richard Purdie

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

I just followed up on a patch from 3 days ago, but I'll follow up here as well .. just to make sure the message gets through.

We had a pending patch to fix this issue from Liang Li here @ windriver.

Quoted 7 lines

Quoted 1 line

Did that patch not fix the problem, or did it fall through the cracks ?

It is not correct. It adds in another search path and just hides the issue. We should *never* be putting -I/usr/include/slang on the compiler commandline at all period.

I'd argue that it's more correct than commenting out the upstream include path.

It fixes the problem, doesn't require a patch to the kernel and give us time to work upstream and get a real fix.

So I'd really prefer that we take that fix, versus the kernel patch if it actually fixes the problem.

Quoted 4 lines

I'd assumed in all the email traffic that this was clear and that another solution was being worked on that would be acceptable upstream too.

Exactly what I referred to above. But we don't want a temporary kernel path, we want the temporary recipe patch.

Quoted 4 lines

Perhaps a better option might be: -I=/usr/include/slang ? That assumes that all kernel gcc versions would accept the = notation, that should be true by now?

Not in my experience when dealing with the upstream kernel and tools, there are plenty of old compilers floating around.

Quoted 6 lines

Quoted 2 lines

Sorry, I'm not following this thread super close.. will all kernel trees need to apply this patch? That does not seem ideal...

They would, once we get the patch merged upstream. And you are right, linux-yocto is easy enough, but that's one set of kernel trees.

I should add, that not all trees, and only builds that use a particular set of perf
features out of master would see this problem (as far as I know), so I didn't mean to make this sound bigger than it is ... it's just something that master was hitting on the autobuilders (and who knows, maybe I'm mischaracterizing the problem as well :)

Cheers,

Bruce

Quoted 7 lines

The patch that we proposed to the perf recipe would fix it for all users of that recipe, with a suitable set of kernels (say 3.0 to 3.6 (I haven't checked).

Honestly, that's why we proposed a perf recipe fix, while working on the right fix for the upstream kernel.

Quoted 94 lines · Bruce Ashfield

Quoted 69 lines · Bruce Ashfield

Quoted 68 lines · On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:

Quoted 63 lines · Bruce Ashfield

Quoted 21 lines · Richard Purdie

Quoted 18 lines · Bruce Ashfield

Quoted 6 lines · Richard Purdie

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

I just followed up on a patch from 3 days ago, but I'll follow up here as well .. just to make sure the message gets through.

We had a pending patch to fix this issue from Liang Li here @ windriver.

Quoted 7 lines

Quoted 1 line

Did that patch not fix the problem, or did it fall through the cracks ?

It is not correct. It adds in another search path and just hides the issue. We should *never* be putting -I/usr/include/slang on the compiler commandline at all period.

I'd argue that it's more correct than commenting out the upstream include path.

It fixes the problem, doesn't require a patch to the kernel and give us time to work upstream and get a real fix.

So I'd really prefer that we take that fix, versus the kernel patch if it actually fixes the problem.

Quoted 4 lines

I'd assumed in all the email traffic that this was clear and that another solution was being worked on that would be acceptable upstream too.

Exactly what I referred to above. But we don't want a temporary kernel path, we want the temporary recipe patch.

Quoted 4 lines

Perhaps a better option might be: -I=/usr/include/slang ? That assumes that all kernel gcc versions would accept the = notation, that should be true by now?

Not in my experience when dealing with the upstream kernel and tools, there are plenty of old compilers floating around.

Quoted 6 lines

Quoted 2 lines

Sorry, I'm not following this thread super close.. will all kernel trees need to apply this patch? That does not seem ideal...

They would, once we get the patch merged upstream. And you are right, linux-yocto is easy enough, but that's one set of kernel trees.

I should add, that not all trees, and only builds that use a particular set of perf
features out of master would see this problem (as far as I know), so I didn't mean to make this sound bigger than it is ... it's just something that master was hitting on the autobuilders (and who knows, maybe I'm mischaracterizing the problem as well :)

Cheers,

Bruce

Quoted 5 lines

The patch that we proposed to the perf recipe would fix it for all users of that recipe, with a suitable set of kernels (say 3.0 to 3.6 (I haven't checked).

Quoted 2 lines

Quoted 2 lines

Honestly, that's why we proposed a perf recipe fix, while working on the right fix for the upstream kernel.

It seems wrong to need a kernel patch to fix this issue, kernels are built outside of oe-core and it seems better to fix things in one place. By the way, I'm seeing this on our kernel recipe in meta-fsl-ppc too.

-M

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 99 lines · On Tue, Aug 7, 2012 at 10:25 PM, McClintock Matthew-B29882…

Quoted 96 lines · Bruce Ashfield

Quoted 69 lines · Bruce Ashfield

Quoted 68 lines · On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:

Quoted 63 lines · Bruce Ashfield

Quoted 21 lines · Richard Purdie

Quoted 18 lines · Bruce Ashfield

Quoted 6 lines · Richard Purdie

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

I just followed up on a patch from 3 days ago, but I'll follow up here as well .. just to make sure the message gets through.

We had a pending patch to fix this issue from Liang Li here @ windriver.

Quoted 7 lines

Quoted 1 line

Did that patch not fix the problem, or did it fall through the cracks ?

It is not correct. It adds in another search path and just hides the issue. We should *never* be putting -I/usr/include/slang on the compiler commandline at all period.

I'd argue that it's more correct than commenting out the upstream include path.

It fixes the problem, doesn't require a patch to the kernel and give us time to work upstream and get a real fix.

So I'd really prefer that we take that fix, versus the kernel patch if it actually fixes the problem.

Quoted 4 lines

I'd assumed in all the email traffic that this was clear and that another solution was being worked on that would be acceptable upstream too.

Exactly what I referred to above. But we don't want a temporary kernel path, we want the temporary recipe patch.

Quoted 4 lines

Perhaps a better option might be: -I=/usr/include/slang ? That assumes that all kernel gcc versions would accept the = notation, that should be true by now?

Not in my experience when dealing with the upstream kernel and tools, there are plenty of old compilers floating around.

Quoted 6 lines

Quoted 2 lines

Sorry, I'm not following this thread super close.. will all kernel trees need to apply this patch? That does not seem ideal...

They would, once we get the patch merged upstream. And you are right, linux-yocto is easy enough, but that's one set of kernel trees.

I should add, that not all trees, and only builds that use a particular set of perf
features out of master would see this problem (as far as I know), so I didn't mean to make this sound bigger than it is ... it's just something that master was hitting on the autobuilders (and who knows, maybe I'm mischaracterizing the problem as well :)

Cheers,

Bruce

Quoted 7 lines

The patch that we proposed to the perf recipe would fix it for all users of that recipe, with a suitable set of kernels (say 3.0 to 3.6 (I haven't checked).

Honestly, that's why we proposed a perf recipe fix, while working on the right fix for the upstream kernel.

Quoted 4 lines

It seems wrong to need a kernel patch to fix this issue, kernels are built outside of oe-core and it seems better to fix things in one place. By the way, I'm seeing this on our kernel recipe in meta-fsl-ppc too.

Have you tried the patch from Liang Li @ Windriver ? Sent last Friday, it should solve your
immediate problem .. it solved ours.

Cheers,

Bruce

Quoted 7 lines

-M

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 106 lines · Bruce Ashfield

Quoted 103 lines · On Tue, Aug 7, 2012 at 10:25 PM, McClintock Matthew-B29882…

Quoted 85 lines · Bruce Ashfield

Quoted 69 lines · Bruce Ashfield

Quoted 68 lines · On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:

Quoted 63 lines · Bruce Ashfield

Quoted 21 lines · Richard Purdie

Quoted 18 lines · Bruce Ashfield

Quoted 6 lines · Richard Purdie

Add in a workaround to avoid host infection detection build failures from the slang include directory in perf. I'll defer to Bruce to fix this properly but we need a workaround now as this is breaking builds.

I just followed up on a patch from 3 days ago, but I'll follow up here as well .. just to make sure the message gets through.

We had a pending patch to fix this issue from Liang Li here @ windriver.

Quoted 7 lines

Quoted 1 line

Did that patch not fix the problem, or did it fall through the cracks ?

It is not correct. It adds in another search path and just hides the issue. We should *never* be putting -I/usr/include/slang on the compiler commandline at all period.

I'd argue that it's more correct than commenting out the upstream include path.

It fixes the problem, doesn't require a patch to the kernel and give us time to work upstream and get a real fix.

So I'd really prefer that we take that fix, versus the kernel patch if it actually fixes the problem.

Quoted 4 lines

I'd assumed in all the email traffic that this was clear and that another solution was being worked on that would be acceptable upstream too.

Exactly what I referred to above. But we don't want a temporary kernel path, we want the temporary recipe patch.

Quoted 4 lines

Perhaps a better option might be: -I=/usr/include/slang ? That assumes that all kernel gcc versions would accept the = notation, that should be true by now?

Not in my experience when dealing with the upstream kernel and tools, there are plenty of old compilers floating around.

Quoted 6 lines

Quoted 2 lines

Sorry, I'm not following this thread super close.. will all kernel trees need to apply this patch? That does not seem ideal...

They would, once we get the patch merged upstream. And you are right, linux-yocto is easy enough, but that's one set of kernel trees.

I should add, that not all trees, and only builds that use a particular set of perf
features out of master would see this problem (as far as I know), so I didn't mean to make this sound bigger than it is ... it's just something that master was hitting on the autobuilders (and who knows, maybe I'm mischaracterizing the problem as well :)

Quoted 11 lines

Cheers,

Bruce

Quoted 7 lines

The patch that we proposed to the perf recipe would fix it for all users of that recipe, with a suitable set of kernels (say 3.0 to 3.6 (I haven't checked).

Honestly, that's why we proposed a perf recipe fix, while working on the right fix for the upstream kernel.

It seems wrong to need a kernel patch to fix this issue, kernels are built outside of oe-core and it seems better to fix things in one place. By the way, I'm seeing this on our kernel recipe in meta-fsl-ppc too.

Quoted 3 lines

Have you tried the patch from Liang Li @ Windriver ? Sent last Friday, it should solve your
immediate problem .. it solved ours.

http://patches.openembedded.org/project/oe-core/list/?submitter=5585

which version?

-M

Quoted 15 lines

Cheers,

Bruce

Quoted 7 lines

-M

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 8 lines

--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core