local.conf.sample: add PATH to SSTATE_MIRRORS comments
PATCH 1/1 local.conf.sample: add PATH to SSTATE_MIRRORS comments
The shared state cache as pointed to by SSTATE_DIR by default now has two-character subdirectories to prevent there being an issue with too many files in the same directory; also, native sstate packages will go into a subdirectory named using the distro ID string. If you copy the newly structured sstate cache to a mirror location (either local or remote) and then point to it in SSTATE_MIRRORS, you need to append "PATH" to the end of the mirror URL so that the path used by bitbake before the mirror substitution is appended to the path used to access the mirror.
--- meta/conf/local.conf.sample | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
meta/conf/local.conf.sample +5 -2
@@ -194,9 +194,12 @@ PATCHRESOLVE = "noop" # would contain the sstate-cache results from previous builds (possibly from other # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the # cache locations to check for the shared objects. +# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH +# at the end as shown in the examples below. This will be substituted with the +# correct path within the directory structure. #SSTATE_MIRRORS ?= "\ -#file://.* http://someserver.tld/share/sstate/ \n \ -#file://.* file:///some/local/dir/sstate/" +#file://.* http://someserver.tld/share/sstate/PATH \n \ +#file://.* file:///some/local/dir/sstate/PATH" # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to # track the version of this file when it was generated. This can safely be ignored if
Signature · 1 line
1.7.9.5
Quoted 25 lines · Paul Eggleton
The shared state cache as pointed to by
SSTATE_DIRby default now has two-character subdirectories to prevent there being an issue with too many files in the same directory; also, native sstate packages will go into a subdirectory named using the distro ID string. If you copy the newly structured sstate cache to a mirror location (either local or remote) and then point to it inSSTATE_MIRRORS, you need to append "PATH" to the end of the mirror URL so that the path used by bitbake before the mirror substitution is appended to the path used to access the mirror.Signed-off-by Paul Eggleton <[email protected]>--- meta/conf/local.conf.sample | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)meta/conf/local.conf.sample +1
-0@@ -194,9 +194,12 @@ PATCHRESOLVE = "noop" # would contain the sstate-cache results from previous builds (possibly from other # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the # cache locations to check for the shared objects. +# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
meta/conf/local.conf.sample PATCHRESOLVE = "noop" · line 205
Quoted 10 lines
meta/conf/local.conf.sample +4
-2+# at the end as shown in the examples below. This will be substituted with the +# correct path within the directory structure. #SSTATE_MIRRORS ?= "\ -#file://.* http://someserver.tld/share/sstate/ \n \ -#file://.* file:///some/local/dir/sstate/" +#file://.* http://someserver.tld/share/sstate/PATH \n \ +#file://.* file:///some/local/dir/sstate/PATH" # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to # track the version of this file when it was generated. This can safely be ignored if
I think this is really a Poky File, so should go to the [email protected]!
Sau!
Quoted 39 lines · On Friday 12 October 2012 11:07:31 Saul Wold wrote:
Quoted 38 lines · Paul Eggleton
The shared state cache as pointed to by
SSTATE_DIRby default now has two-character subdirectories to prevent there being an issue with too many files in the same directory; also, native sstate packages will go into a subdirectory named using the distro ID string. If you copy the newly structured sstate cache to a mirror location (either local or remote) and then point to it inSSTATE_MIRRORS, you need to append "PATH" to the end of the mirror URL so that the path used by bitbake before the mirror substitution is appended to the path used to access the mirror.Signed-off-by Paul Eggleton <[email protected]>---
meta/conf/local.conf.sample | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)meta/conf/local.conf.sample +1
-0@@ -194,9 +194,12 @@ PATCHRESOLVE = "noop" # would contain the sstate-cache results from previous builds (possibly from other # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the # cache locations to check for the shared objects. +# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need toadd PATH +# at the end as shown in the examples below. This will be substituted with the +# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\meta/conf/local.conf.sample +2
-2-#file://.* http://someserver.tld/share/sstate/ \n \ -#file://.* file:///some/local/dir/sstate/" +#file://.* http://someserver.tld/share/sstate/PATH \n \ +#file://.* file:///some/local/dir/sstate/PATH"
Quoted 6 lines
Quoted 3 lines
#
CONF_VERSIONis increased each time build/conf/ changes incompatibly and is used to # track the version of this file when it was generated. This can safely be ignored ifI think this is really a Poky File, so should go to the [email protected]!
There is a version of the file in both repositories, I sent a patch for each one.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
W dniu 12.10.2012 20:07, Saul Wold pisze:
Quoted 7 lines · Paul Eggleton
Quoted 3 lines
meta/conf/local.conf.sample | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)I think this is really a Poky File, so should go to the [email protected]!
For me this file is part of OE-Core so list is proper. If OE-Core has some Poky files then maybe consider moving them to separate layer?
Look at OE-Core from perspective of external developers. They change files and then send patches here. Would you say them "go to other ML with it" just because of history relations when they did proper thing?
Quoted 11 lines · Marcin Juszkiewicz
W dniu 12.10.2012 20:07, Saul Wold pisze:
Quoted 7 lines · Paul Eggleton
Quoted 3 lines
meta/conf/local.conf.sample | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)I think this is really a Poky File, so should go to the [email protected]!
For me this file is part of OE-Core so list is proper. If OE-Core has some Poky files then maybe consider moving them to separate layer?
For me, that's also correct.
If a file exists in oe-core, it's an oe-core file and patches goes here.
Quoted 8 lines
Look at OE-Core from perspective of external developers. They change files and then send patches here. Would you say them "go to other ML with it" just because of history relations when they did proper thing?
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
Anders Darander ChargeStorm AB / eStorm AB
Quoted 9 lines · On Monday 15 October 2012 07:34:15 Anders Darander wrote:
Quoted 8 lines · Marcin Juszkiewicz
W dniu 12.10.2012 20:07, Saul Wold pisze:
Quoted 6 lines · Paul Eggleton
Quoted 2 lines
meta/conf/local.conf.sample | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)I think this is really a Poky File, so should go to the [email protected]!
Quoted 6 lines
Quoted 2 lines
For me this file is part of OE-Core so list is proper. If OE-Core has some Poky files then maybe consider moving them to separate layer?
For me, that's also correct.
If a file exists in oe-core, it's an oe-core file and patches goes here.
I don't think anyone's actually disputing that. OE-Core patches always go to the OE-Core list, as happened in this case.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre