1.3_M3 do_kernel_config failes, config_frag.txt is crippled.

1.3_M3 do_kernel_config failes, config_frag.txt is crippled.

[Markus Hubig]

Hello @all,

because I need the commit 'dcadeda' I switched from denzil to 1.3_M3.
Now I get a strage error while do_kernel_config:

| configme --reconfig --output <...>/linux-portuxg20-standard-build standard stamp9g20
| [INFO] Configuring target/machine combo: "standard/stamp9g20"
| [INFO] collecting configs in ./meta/meta-series 
|   [##################################################]  (completed in 0 seconds)                    
| ERROR: could not sanitize configuration fragments
|    errors are logged in meta/cfg/standard/portuxg20/config.log

Digin a bit deeper I found:

| [INFO] Sanitizing meta/cfg/kernel-cache/features/fuse/fuse.cfg
| [INFO] Sanitizing meta/cfg/kernel-cache/ktypes/standard/standard.cfg
| [INFO] Sanitizing meta/cfg/kernel-cache/cfg/devtmpfs.cfg
| [INFO] Sanitizing meta/cfg/kernel-cache/cfg/debugfs.cfg
| [INFO] Sanitizing meta/cfgportuxg20
                    ^^^^^^^^^^^^^^^^^
| [ERROR] Kern frag  does not exist

And again a bit deeper I found that the file

| ./meta/cfg/standard/portuxg20/config_frag.txt

is somewhat crippled:

| ...
| /kernel-cache/ktypes/standard/standard.cfg
| /kernel-cache/cfg/devtmpfs.cfg
| /kernel-cache/cfg/debugfs.cfg
| portuxg20
  ^^^^^^^^^
| hardware.cfg
| non-hardware.cfg
| /kernel-cache/features/usb-net/usb-net.cfg
| portuxg20
| hardware.cfg
| non-hardware.cfg
| /kernel-cache/features/usb-net/usb-net.cfg
| /hardware.cfg
| /non-hardware.cfg
| /portuxg20/portuxg20.cfg
| /kernel-cache/features/netfilter/netfilter.cfg
| /kernel-cache/features/taskstats/taskstats.cfg

Who is creating this file?

Cheers, Markus

-- 
Human beings were created by water to transport it uphill.

Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.

[Bruce Ashfield]

On 12-08-23 09:24 AM, Markus Hubig wrote:
> Hello @all,
>
> because I need the commit 'dcadeda' I switched from denzil to 1.3_M3.
> Now I get a strage error while do_kernel_config:
>
> | configme --reconfig --output<...>/linux-portuxg20-standard-build standard stamp9g20
> | [INFO] Configuring target/machine combo: "standard/stamp9g20"
> | [INFO] collecting configs in ./meta/meta-series
> |   [##################################################]  (completed in 0 seconds)
> | ERROR: could not sanitize configuration fragments
> |    errors are logged in meta/cfg/standard/portuxg20/config.log
>
> Digin a bit deeper I found:
>
> | [INFO] Sanitizing meta/cfg/kernel-cache/features/fuse/fuse.cfg
> | [INFO] Sanitizing meta/cfg/kernel-cache/ktypes/standard/standard.cfg
> | [INFO] Sanitizing meta/cfg/kernel-cache/cfg/devtmpfs.cfg
> | [INFO] Sanitizing meta/cfg/kernel-cache/cfg/debugfs.cfg
> | [INFO] Sanitizing meta/cfgportuxg20
>                      ^^^^^^^^^^^^^^^^^
> | [ERROR] Kern frag  does not exist
>
> And again a bit deeper I found that the file
>
> | ./meta/cfg/standard/portuxg20/config_frag.txt
>
> is somewhat crippled:
>
> | ...
> | /kernel-cache/ktypes/standard/standard.cfg
> | /kernel-cache/cfg/devtmpfs.cfg
> | /kernel-cache/cfg/debugfs.cfg
> | portuxg20
>    ^^^^^^^^^
> | hardware.cfg
> | non-hardware.cfg
> | /kernel-cache/features/usb-net/usb-net.cfg
> | portuxg20
> | hardware.cfg
> | non-hardware.cfg
> | /kernel-cache/features/usb-net/usb-net.cfg
> | /hardware.cfg
> | /non-hardware.cfg
> | /portuxg20/portuxg20.cfg
> | /kernel-cache/features/netfilter/netfilter.cfg
> | /kernel-cache/features/taskstats/taskstats.cfg
>
> Who is creating this file?

Were you using yocto-bsp to create the BSP framework ? I did some test
builds of the layer you previously sent me, and I didn't reproduce the
problem, but this is the same thing that you had seen last week.

Do you have an updated layer that I can try against master ?

Bruce

>
> Cheers, Markus
>

Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.

[Markus Hubig]

On Thu, Aug 23, 2012 at 09:31:15AM -0400, Bruce Ashfield wrote:
> On 12-08-23 09:24 AM, Markus Hubig wrote:

<snipp>

> >And again a bit deeper I found that the file
> >
> >| ./meta/cfg/standard/portuxg20/config_frag.txt
> >
> >is somewhat crippled:
> >
> >| ...
> >| /kernel-cache/ktypes/standard/standard.cfg
> >| /kernel-cache/cfg/devtmpfs.cfg
> >| /kernel-cache/cfg/debugfs.cfg
> >| portuxg20
> >   ^^^^^^^^^

That was a typo. Fixed!

> >| hardware.cfg
> >| non-hardware.cfg

These files were living in "meta-stamp9g20/recipes-kernel/files"

> >| /kernel-cache/features/usb-net/usb-net.cfg

> >| portuxg20
> >| hardware.cfg
> >| non-hardware.cfg
> >| /kernel-cache/features/usb-net/usb-net.cfg

Here we have the same thing a second time.

> >| /hardware.cfg
> >| /non-hardware.cfg
> >| /portuxg20/portuxg20.cfg

And a third time, but with a correct path.

After changing my BSP-Kernel layout from:

| ▾ recipes-kernel/
|   ▾ linux/
|     ▾ files/
|         hardware.cfg
|         non-hardware.cfg
|       ▾ portuxg20/
|           portuxg20-preempt-rt.scc
|           portuxg20-standard.scc
|           portuxg20.cfg
|           portuxg20.scc
|       ▾ stamp9g20/
|           stamp9g20-preempt-rt.scc
|           stamp9g20-standard.scc
|           stamp9g20.cfg
|           stamp9g20.scc

To this:

| ▾ recipes-kernel/
|   ▾ linux/
|     ▾ files/
|       ▾ portuxg20/
|           hardware.cfg
|           non-hardware.cfg
|           portuxg20-preempt-rt.scc
|           portuxg20-standard.scc
|           portuxg20.cfg
|           portuxg20.scc
|       ▾ stamp9g20/
|           hardware.cfg
|           non-hardware.cfg
|           stamp9g20-preempt-rt.scc
|           stamp9g20-standard.scc
|           stamp9g20.cfg
|           stamp9g20.scc

and using

| SRC_URI_append_portuxg20 = "\
|         file://portuxg20-standard.scc   \
|         file://portuxg20-preempt-rt.scc \
|         file://portuxg20.scc            \
|         file://portuxg20.cfg            \
|         file://hardware.cfg             \
|         file://non-hardware.cfg         \
|         "
| 
| SRC_URI_append_stamp9g20 = "
|         file://stamp9g20-standard.scc   \
|         file://stamp9g20-preempt-rt.scc \
|         file://stamp9g20.scc            \
|         file://stamp9g20.cfg            \
|         file://hardware.cfg             \
|         file://non-hardware.cfg         \
|         "

instead of this:

| SRC_URI += "\
|         file://hardware.cfg             \
|         file://non-hardware.cfg         \
|         "
|
| SRC_URI_append_portuxg20 = "\
|         file://portuxg20-standard.scc   \
|         file://portuxg20-preempt-rt.scc \
|         file://portuxg20.scc            \
|         file://portuxg20.cfg            \
|         "
| 
| SRC_URI_append_stamp9g20 = "
|         file://stamp9g20-standard.scc   \
|         file://stamp9g20-preempt-rt.scc \
|         file://stamp9g20.scc            \
|         file://stamp9g20.cfg            \
|         "

I get this config_frag.txt but at the cost of duplicating the
hardware.cfg and non-hardware.cfg files.

| /kernel-cache/ktypes/base/base.cfg
| /kernel-cache/features/kgdb/kgdb.cfg
| /kernel-cache/features/lttng/lttng.cfg
| /kernel-cache/features/blktrace/blktrace.cfg
| /kernel-cache/features/systemtap/systemtap.cfg
| /kernel-cache/features/utrace/utrace.cfg
| /kernel-cache/arch/arm/arm.cfg
| /kernel-cache/features/hrt/hrt.cfg
| /kernel-cache/features/ftrace/ftrace.cfg
| /kernel-cache/features/unionfs/unionfs.cfg
| /kernel-cache/features/cgroups/cgroups.cfg
| /kernel-cache/features/namespaces/namespaces.cfg
| /kernel-cache/features/namespaces/namespaces-experimental.cfg
| /kernel-cache/features/fuse/fuse.cfg
| /kernel-cache/ktypes/standard/standard.cfg
| /kernel-cache/cfg/devtmpfs.cfg
| /kernel-cache/cfg/debugfs.cfg
| /portuxg20/portuxg20.cfg
| /portuxg20/hardware.cfg
| /portuxg20/non-hardware.cfg
| /kernel-cache/features/usb-net/usb-net.cfg
| /portuxg20/portuxg20.cfg
| /portuxg20/hardware.cfg
| /portuxg20/non-hardware.cfg
| /kernel-cache/features/usb-net/usb-net.cfg
| /kernel-cache/features/netfilter/netfilter.cfg
| /kernel-cache/features/taskstats/taskstats.cfg

Whitch looks way better! And now I get this config check again:

| This BSP sets 2 invalid/obsolete kernel options.
| These config options are not offered anywhere within this kernel.
| The full list can be found in your kernel src dir at:
| meta/cfg/standard/portuxg20/invalid.cfg
| 
| This BSP sets 11 kernel options that are possibly non-hardware related.
| The full list can be found in your kernel src dir at:
| meta/cfg/standard/portuxg20/specified_non_hdw.cfg
| 
| WARNING: There were 1 hardware options requested that do not
|          have a corresponding value present in the final ".config" file.
|          This probably means you aren't getting the config you wanted.
| The full list can be found in your kernel src dir at:
| meta/cfg/standard/portuxg20/mismatch.cfg
| 
| Waiting a second to make sure you get a chance to see this...

Surprisingly if I remove the *.cfg files from the SRC_URI

| SRC_URI_append_portuxg20 = "\
|         file://portuxg20-standard.scc   \
|         file://portuxg20-preempt-rt.scc \
|         file://portuxg20.scc            \
|         "
| 
| SRC_URI_append_stamp9g20 = "
|         file://stamp9g20-standard.scc   \
|         file://stamp9g20-preempt-rt.scc \
|         file://stamp9g20.scc            \

it also works ...

Some more tests showed that if I make a flat layout like
this:

| ▾ recipes-kernel/
|   ▾ linux/
|     ▾ files/
|         hardware.cfg
|         non-hardware.cfg
|         portuxg20-preempt-rt.scc
|         portuxg20-standard.scc
|         portuxg20.cfg
|         portuxg20.scc
|         stamp9g20-preempt-rt.scc
|         stamp9g20-standard.scc
|         stamp9g20.cfg
|         stamp9g20.scc

and change my linux-yocto_3.2.bbappend file so it just includes
the *.scc files

| FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
| 
| PR := "${PR}.1"
| 
| KEEPUIMAGE = "no"
| 
| COMPATIBLE_MACHINE_stamp9g20 = "stamp9g20"
| KBRANCH_stamp9g20  = "standard/default/arm-versatile-926ejs"
| KMACHINE_stamp9g20  = "stamp9g20"
| 
| COMPATIBLE_MACHINE_portuxg20 = "portuxg20"
| KBRANCH_portuxg20  = "standard/default/arm-versatile-926ejs"
| KMACHINE_portuxg20  = "portuxg20"
| 
| SRC_URI_append_portuxg20 = "\
|         file://portuxg20-standard.scc   \
|         file://portuxg20-preempt-rt.scc \
|         file://portuxg20.scc            \
|         "
| 
| SRC_URI_append_stamp9g20 = "\
|         file://stamp9g20-standard.scc   \
|         file://stamp9g20-preempt-rt.scc \
|         file://stamp9g20.scc            \
|         "

everything works. But it's a bit confusing! 

To summarize my expirience a bit:

All files in "FILESEXTRAPATHS_prepend" get copied to "meta/cfg/files",
but only the *.scc files I include into "SRC_URI" will be used to make
the kernel config file.

> Were you using yocto-bsp to create the BSP framework?

Yes but later I changed everything ... 

> I did some test builds of the layer you previously sent me, and I didn't
> reproduce the problem, but this is the same thing that you had seen last
> week.

Strange ...

> Do you have an updated layer that I can try against master ?

Yes in some hours, i'll send you a ping if I included my new changes.

Cheers, Markus

-- 
Human beings were created by water to transport it uphill.

Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.

[Markus Hubig]

On Thu, Aug 23, 2012 at 06:18:22PM +0200, Markus Hubig wrote:
> On Thu, Aug 23, 2012 at 09:31:15AM -0400, Bruce Ashfield wrote:
> > On 12-08-23 09:24 AM, Markus Hubig wrote:

<snipp>

> | ▾ recipes-kernel/
> |   ▾ linux/
> |     ▾ files/
> |         hardware.cfg
> |         non-hardware.cfg
> |         portuxg20-preempt-rt.scc
> |         portuxg20-standard.scc
> |         portuxg20.cfg
> |         portuxg20.scc
> |         stamp9g20-preempt-rt.scc
> |         stamp9g20-standard.scc
> |         stamp9g20.cfg
> |         stamp9g20.scc

<snipp>

> To summarize my expirience a bit:
> 
> All files in "FILESEXTRAPATHS_prepend" get copied to "meta/cfg/files",
> but only the *.scc files I include into "SRC_URI" will be used to make
> the kernel config file.

One tiny addition:

A non-flat file layout eg. like this:

| ▾ recipes-kernel/
|   ▾ linux/
|       hardware.cfg
|       non-hardware.cfg
|     ▾ files/
|         portuxg20-preempt-rt.scc
|         portuxg20-standard.scc
|         portuxg20.cfg
|         portuxg20.scc

doesn't work!

Cheers, Markus

-- 
Human beings were created by water to transport it uphill.

Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.

[Bruce Ashfield]

On 12-08-23 12:18 PM, Markus Hubig wrote:
> On Thu, Aug 23, 2012 at 09:31:15AM -0400, Bruce Ashfield wrote:
>> On 12-08-23 09:24 AM, Markus Hubig wrote:
>
> <snipp>
>
>>> And again a bit deeper I found that the file
>>>
>>> | ./meta/cfg/standard/portuxg20/config_frag.txt
>>>
>>> is somewhat crippled:
>>>
>>> | ...
>>> | /kernel-cache/ktypes/standard/standard.cfg
>>> | /kernel-cache/cfg/devtmpfs.cfg
>>> | /kernel-cache/cfg/debugfs.cfg
>>> | portuxg20
>>>    ^^^^^^^^^
>
> That was a typo. Fixed!
>
>>> | hardware.cfg
>>> | non-hardware.cfg
>
> These files were living in "meta-stamp9g20/recipes-kernel/files"
>
>>> | /kernel-cache/features/usb-net/usb-net.cfg
>
>>> | portuxg20
>>> | hardware.cfg
>>> | non-hardware.cfg
>>> | /kernel-cache/features/usb-net/usb-net.cfg
>
> Here we have the same thing a second time.
>
>>> | /hardware.cfg
>>> | /non-hardware.cfg
>>> | /portuxg20/portuxg20.cfg
>
> And a third time, but with a correct path.
>
> After changing my BSP-Kernel layout from:
>
> | ▾ recipes-kernel/
> |   ▾ linux/
> |     ▾ files/
> |         hardware.cfg
> |         non-hardware.cfg
> |       ▾ portuxg20/
> |           portuxg20-preempt-rt.scc
> |           portuxg20-standard.scc
> |           portuxg20.cfg
> |           portuxg20.scc
> |       ▾ stamp9g20/
> |           stamp9g20-preempt-rt.scc
> |           stamp9g20-standard.scc
> |           stamp9g20.cfg
> |           stamp9g20.scc
>
> To this:
>
> | ▾ recipes-kernel/
> |   ▾ linux/
> |     ▾ files/
> |       ▾ portuxg20/
> |           hardware.cfg
> |           non-hardware.cfg
> |           portuxg20-preempt-rt.scc
> |           portuxg20-standard.scc
> |           portuxg20.cfg
> |           portuxg20.scc
> |       ▾ stamp9g20/
> |           hardware.cfg
> |           non-hardware.cfg
> |           stamp9g20-preempt-rt.scc
> |           stamp9g20-standard.scc
> |           stamp9g20.cfg
> |           stamp9g20.scc
>
> and using
>
> | SRC_URI_append_portuxg20 = "\
> |         file://portuxg20-standard.scc   \
> |         file://portuxg20-preempt-rt.scc \
> |         file://portuxg20.scc            \
> |         file://portuxg20.cfg            \
> |         file://hardware.cfg             \
> |         file://non-hardware.cfg         \
> |         "
> |
> | SRC_URI_append_stamp9g20 = "
> |         file://stamp9g20-standard.scc   \
> |         file://stamp9g20-preempt-rt.scc \
> |         file://stamp9g20.scc            \
> |         file://stamp9g20.cfg            \
> |         file://hardware.cfg             \
> |         file://non-hardware.cfg         \
> |         "
>
> instead of this:
>
> | SRC_URI += "\
> |         file://hardware.cfg             \
> |         file://non-hardware.cfg         \
> |         "
> |
> | SRC_URI_append_portuxg20 = "\
> |         file://portuxg20-standard.scc   \
> |         file://portuxg20-preempt-rt.scc \
> |         file://portuxg20.scc            \
> |         file://portuxg20.cfg            \
> |         "
> |
> | SRC_URI_append_stamp9g20 = "
> |         file://stamp9g20-standard.scc   \
> |         file://stamp9g20-preempt-rt.scc \
> |         file://stamp9g20.scc            \
> |         file://stamp9g20.cfg            \
> |         "
>
> I get this config_frag.txt but at the cost of duplicating the
> hardware.cfg and non-hardware.cfg files.
>
> | /kernel-cache/ktypes/base/base.cfg
> | /kernel-cache/features/kgdb/kgdb.cfg
> | /kernel-cache/features/lttng/lttng.cfg
> | /kernel-cache/features/blktrace/blktrace.cfg
> | /kernel-cache/features/systemtap/systemtap.cfg
> | /kernel-cache/features/utrace/utrace.cfg
> | /kernel-cache/arch/arm/arm.cfg
> | /kernel-cache/features/hrt/hrt.cfg
> | /kernel-cache/features/ftrace/ftrace.cfg
> | /kernel-cache/features/unionfs/unionfs.cfg
> | /kernel-cache/features/cgroups/cgroups.cfg
> | /kernel-cache/features/namespaces/namespaces.cfg
> | /kernel-cache/features/namespaces/namespaces-experimental.cfg
> | /kernel-cache/features/fuse/fuse.cfg
> | /kernel-cache/ktypes/standard/standard.cfg
> | /kernel-cache/cfg/devtmpfs.cfg
> | /kernel-cache/cfg/debugfs.cfg
> | /portuxg20/portuxg20.cfg
> | /portuxg20/hardware.cfg
> | /portuxg20/non-hardware.cfg
> | /kernel-cache/features/usb-net/usb-net.cfg
> | /portuxg20/portuxg20.cfg
> | /portuxg20/hardware.cfg
> | /portuxg20/non-hardware.cfg
> | /kernel-cache/features/usb-net/usb-net.cfg
> | /kernel-cache/features/netfilter/netfilter.cfg
> | /kernel-cache/features/taskstats/taskstats.cfg
>
> Whitch looks way better! And now I get this config check again:
>
> | This BSP sets 2 invalid/obsolete kernel options.
> | These config options are not offered anywhere within this kernel.
> | The full list can be found in your kernel src dir at:
> | meta/cfg/standard/portuxg20/invalid.cfg
> |
> | This BSP sets 11 kernel options that are possibly non-hardware related.
> | The full list can be found in your kernel src dir at:
> | meta/cfg/standard/portuxg20/specified_non_hdw.cfg
> |
> | WARNING: There were 1 hardware options requested that do not
> |          have a corresponding value present in the final ".config" file.
> |          This probably means you aren't getting the config you wanted.
> | The full list can be found in your kernel src dir at:
> | meta/cfg/standard/portuxg20/mismatch.cfg
> |
> | Waiting a second to make sure you get a chance to see this...
>
> Surprisingly if I remove the *.cfg files from the SRC_URI
>
> | SRC_URI_append_portuxg20 = "\
> |         file://portuxg20-standard.scc   \
> |         file://portuxg20-preempt-rt.scc \
> |         file://portuxg20.scc            \
> |         "
> |
> | SRC_URI_append_stamp9g20 = "
> |         file://stamp9g20-standard.scc   \
> |         file://stamp9g20-preempt-rt.scc \
> |         file://stamp9g20.scc            \
>
> it also works ...

Yes, and I can explain this part. When a .scc file is detected, the
entire directory contents are propagated to the kernel build, since
.scc files can refer to patches, configs, etc, and some elements are
optional, they are all made available.

So if you reference .cfgs and patches in your .scc files, you don't
need them in the SRC_URI, just the .scc file.

>
> Some more tests showed that if I make a flat layout like
> this:
>
> | ▾ recipes-kernel/
> |   ▾ linux/
> |     ▾ files/
> |         hardware.cfg
> |         non-hardware.cfg
> |         portuxg20-preempt-rt.scc
> |         portuxg20-standard.scc
> |         portuxg20.cfg
> |         portuxg20.scc
> |         stamp9g20-preempt-rt.scc
> |         stamp9g20-standard.scc
> |         stamp9g20.cfg
> |         stamp9g20.scc
>
> and change my linux-yocto_3.2.bbappend file so it just includes
> the *.scc files
>
> | FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> |
> | PR := "${PR}.1"
> |
> | KEEPUIMAGE = "no"
> |
> | COMPATIBLE_MACHINE_stamp9g20 = "stamp9g20"
> | KBRANCH_stamp9g20  = "standard/default/arm-versatile-926ejs"
> | KMACHINE_stamp9g20  = "stamp9g20"
> |
> | COMPATIBLE_MACHINE_portuxg20 = "portuxg20"
> | KBRANCH_portuxg20  = "standard/default/arm-versatile-926ejs"
> | KMACHINE_portuxg20  = "portuxg20"
> |
> | SRC_URI_append_portuxg20 = "\
> |         file://portuxg20-standard.scc   \
> |         file://portuxg20-preempt-rt.scc \
> |         file://portuxg20.scc            \
> |         "
> |
> | SRC_URI_append_stamp9g20 = "\
> |         file://stamp9g20-standard.scc   \
> |         file://stamp9g20-preempt-rt.scc \
> |         file://stamp9g20.scc            \
> |         "
>
> everything works. But it's a bit confusing!

See above. Sounds like we need to clarify/make this explicit in the
docs.

>
> To summarize my expirience a bit:
>
> All files in "FILESEXTRAPATHS_prepend" get copied to "meta/cfg/files",
> but only the *.scc files I include into "SRC_URI" will be used to make
> the kernel config file.

Correct, although if you put a .cfg on the SRC_URI and no associated
.scc file references one, the build will automatically generate a .scc
file and ensure that the fragment is added.

>
>> Were you using yocto-bsp to create the BSP framework?
>
> Yes but later I changed everything ...
>
>> I did some test builds of the layer you previously sent me, and I didn't
>> reproduce the problem, but this is the same thing that you had seen last
>> week.
>
> Strange ...

Definitely. But I'm also getting some other strange errors with guarded
files, etc, and am running some slightly newer tools, so you never know.

>
>> Do you have an updated layer that I can try against master ?
>
> Yes in some hours, i'll send you a ping if I included my new changes.

No rush, I just wanted to make sure, so I can stop flailing against
the older one I have :)

Cheers,

Bruce

>
> Cheers, Markus
>

Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.

[Markus Hubig]

On Thu, Aug 23, 2012 at 12:26:30PM -0400, Bruce Ashfield wrote:
> On 12-08-23 12:18 PM, Markus Hubig wrote:
> >On Thu, Aug 23, 2012 at 09:31:15AM -0400, Bruce Ashfield wrote:
> >>On 12-08-23 09:24 AM, Markus Hubig wrote:

<snipp>

> >Surprisingly if I remove the *.cfg files from the SRC_URI
> >
> >| SRC_URI_append_portuxg20 = "\
> >|         file://portuxg20-standard.scc   \
> >|         file://portuxg20-preempt-rt.scc \
> >|         file://portuxg20.scc            \
> >|         "
> >|
> >| SRC_URI_append_stamp9g20 = "
> >|         file://stamp9g20-standard.scc   \
> >|         file://stamp9g20-preempt-rt.scc \
> >|         file://stamp9g20.scc            \
> >
> >it also works ...
> 
> Yes, and I can explain this part. When a .scc file is detected, the
> entire directory contents are propagated to the kernel build, since
> .scc files can refer to patches, configs, etc, and some elements are
> optional, they are all made available.
> 
> So if you reference .cfgs and patches in your .scc files, you don't
> need them in the SRC_URI, just the .scc file.

Is it possible that if I remove the *.cfg files, bitbake no longer tracks
changes inside this files and will not rebuild the related packages from
scratch with:

| bitbake -fc clean linux-yocto
| bitbake linux-yocto
 
Cheers, Markus

-- 
Human beings were created by water to transport it uphill.

Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.

[Bruce Ashfield]

On 12-08-23 01:28 PM, Markus Hubig wrote:
> On Thu, Aug 23, 2012 at 12:26:30PM -0400, Bruce Ashfield wrote:
>> On 12-08-23 12:18 PM, Markus Hubig wrote:
>>> On Thu, Aug 23, 2012 at 09:31:15AM -0400, Bruce Ashfield wrote:
>>>> On 12-08-23 09:24 AM, Markus Hubig wrote:
>
> <snipp>
>
>>> Surprisingly if I remove the *.cfg files from the SRC_URI
>>>
>>> | SRC_URI_append_portuxg20 = "\
>>> |         file://portuxg20-standard.scc   \
>>> |         file://portuxg20-preempt-rt.scc \
>>> |         file://portuxg20.scc            \
>>> |         "
>>> |
>>> | SRC_URI_append_stamp9g20 = "
>>> |         file://stamp9g20-standard.scc   \
>>> |         file://stamp9g20-preempt-rt.scc \
>>> |         file://stamp9g20.scc            \
>>>
>>> it also works ...
>>
>> Yes, and I can explain this part. When a .scc file is detected, the
>> entire directory contents are propagated to the kernel build, since
>> .scc files can refer to patches, configs, etc, and some elements are
>> optional, they are all made available.
>>
>> So if you reference .cfgs and patches in your .scc files, you don't
>> need them in the SRC_URI, just the .scc file.
>
> Is it possible that if I remove the *.cfg files, bitbake no longer tracks
> changes inside this files and will not rebuild the related packages from
> scratch with:

If the checksums are over the elements in the SRC_URI, then that would
be true, but I'm not a checksum or fetcher expert.

repeating a .cfg really should be safe, just a bit verbose, I'll retest
that here to see if something broke.

My workflow never hits any problems with not rebuilding, but I can also
check that. If necessary, listing the files, or another technique to get
the checksum'd would be advisable. I'll look into that as well.

Cheers,

Bruce

>
> | bitbake -fc clean linux-yocto
> | bitbake linux-yocto
>
> Cheers, Markus
>