* 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.
@ 2012-08-23 13:24 Markus Hubig
2012-08-23 13:31 ` Bruce Ashfield
0 siblings, 1 reply; 7+ messages in thread
From: Markus Hubig @ 2012-08-23 13:24 UTC (permalink / raw)
To: Yocto Project Mailing List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled. 2012-08-23 13:24 1.3_M3 do_kernel_config failes, config_frag.txt is crippled Markus Hubig @ 2012-08-23 13:31 ` Bruce Ashfield 2012-08-23 16:18 ` Markus Hubig 0 siblings, 1 reply; 7+ messages in thread From: Bruce Ashfield @ 2012-08-23 13:31 UTC (permalink / raw) To: Yocto Project Mailing List 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled. 2012-08-23 13:31 ` Bruce Ashfield @ 2012-08-23 16:18 ` Markus Hubig 2012-08-23 16:22 ` Markus Hubig 2012-08-23 16:26 ` Bruce Ashfield 0 siblings, 2 replies; 7+ messages in thread From: Markus Hubig @ 2012-08-23 16:18 UTC (permalink / raw) To: yocto 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled. 2012-08-23 16:18 ` Markus Hubig @ 2012-08-23 16:22 ` Markus Hubig 2012-08-23 16:26 ` Bruce Ashfield 1 sibling, 0 replies; 7+ messages in thread From: Markus Hubig @ 2012-08-23 16:22 UTC (permalink / raw) To: yocto 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled. 2012-08-23 16:18 ` Markus Hubig 2012-08-23 16:22 ` Markus Hubig @ 2012-08-23 16:26 ` Bruce Ashfield 2012-08-23 17:28 ` Markus Hubig 1 sibling, 1 reply; 7+ messages in thread From: Bruce Ashfield @ 2012-08-23 16:26 UTC (permalink / raw) To: yocto, Markus Hubig 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled. 2012-08-23 16:26 ` Bruce Ashfield @ 2012-08-23 17:28 ` Markus Hubig 2012-08-23 17:33 ` Bruce Ashfield 0 siblings, 1 reply; 7+ messages in thread From: Markus Hubig @ 2012-08-23 17:28 UTC (permalink / raw) To: yocto 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled. 2012-08-23 17:28 ` Markus Hubig @ 2012-08-23 17:33 ` Bruce Ashfield 0 siblings, 0 replies; 7+ messages in thread From: Bruce Ashfield @ 2012-08-23 17:33 UTC (permalink / raw) To: yocto 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-08-23 17:33 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-23 13:24 1.3_M3 do_kernel_config failes, config_frag.txt is crippled Markus Hubig 2012-08-23 13:31 ` Bruce Ashfield 2012-08-23 16:18 ` Markus Hubig 2012-08-23 16:22 ` Markus Hubig 2012-08-23 16:26 ` Bruce Ashfield 2012-08-23 17:28 ` Markus Hubig 2012-08-23 17:33 ` Bruce Ashfield
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.