[PATCH] cramfs: import recipe from meta-oe

[PATCH] cramfs: import recipe from meta-oe

[Andrea Adami]

* though listed in IMAGE_FSTYPES the helper is missing so
* make oe-core autosufficient importing the recipe.
* Fix PN -> BPN to avoid fetch errors with cramfs-native

Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
---
 meta/recipes-support/cramfs/cramfs_1.1.bb | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 meta/recipes-support/cramfs/cramfs_1.1.bb

diff --git a/meta/recipes-support/cramfs/cramfs_1.1.bb b/meta/recipes-support/cramfs/cramfs_1.1.bb
new file mode 100644
index 0000000..0bca0e1
--- /dev/null
+++ b/meta/recipes-support/cramfs/cramfs_1.1.bb
@@ -0,0 +1,29 @@
+DESCRIPTION = "Builds cramfs filesystems for embedded systems"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
+DEPENDS = "zlib"
+
+PE = "1"
+
+SRC_URI = "http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz"
+
+SRC_URI[md5sum] = "d3912b9f7bf745fbfea68f6a9b9de30f"
+SRC_URI[sha256sum] = "133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368"
+
+EXTRA_OEMAKE = "\
+    'CC=${CC}' \
+    'CFLAGS=${CFLAGS}' \
+    'LDFLAGS=${LDFLAGS}' \
+"
+
+do_compile_prepend() {
+    ln -sf GNUmakefile Makefile
+}
+
+do_install() {
+    install -d ${D}${bindir}
+    install mkcramfs ${D}${bindir}
+    install cramfsck ${D}${bindir}
+}
+
+BBCLASSEXTEND = "native"
-- 
1.8.1.5

Re: [PATCH] cramfs: import recipe from meta-oe

[Andrea Adami]

ping

Recipe is rather stable (tarball of v.1.1 dated 2002) and cramfs can
be handy for read-only images on legacy devices.

All the needed infrastructure is already present in
image_types.bbclass so I'd say this recipe has been mistakenly
forgotten when splitting out oe-core


Andrea

On Sun, May 26, 2013 at 1:23 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
> * though listed in IMAGE_FSTYPES the helper is missing so
> * make oe-core autosufficient importing the recipe.
> * Fix PN -> BPN to avoid fetch errors with cramfs-native
>
> Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
> ---
>  meta/recipes-support/cramfs/cramfs_1.1.bb | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>  create mode 100644 meta/recipes-support/cramfs/cramfs_1.1.bb
>
> diff --git a/meta/recipes-support/cramfs/cramfs_1.1.bb b/meta/recipes-support/cramfs/cramfs_1.1.bb
> new file mode 100644
> index 0000000..0bca0e1
> --- /dev/null
> +++ b/meta/recipes-support/cramfs/cramfs_1.1.bb
> @@ -0,0 +1,29 @@
> +DESCRIPTION = "Builds cramfs filesystems for embedded systems"
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
> +DEPENDS = "zlib"
> +
> +PE = "1"
> +
> +SRC_URI = "http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz"
> +
> +SRC_URI[md5sum] = "d3912b9f7bf745fbfea68f6a9b9de30f"
> +SRC_URI[sha256sum] = "133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368"
> +
> +EXTRA_OEMAKE = "\
> +    'CC=${CC}' \
> +    'CFLAGS=${CFLAGS}' \
> +    'LDFLAGS=${LDFLAGS}' \
> +"
> +
> +do_compile_prepend() {
> +    ln -sf GNUmakefile Makefile
> +}
> +
> +do_install() {
> +    install -d ${D}${bindir}
> +    install mkcramfs ${D}${bindir}
> +    install cramfsck ${D}${bindir}
> +}
> +
> +BBCLASSEXTEND = "native"
> --
> 1.8.1.5
>

Re: [PATCH] cramfs: import recipe from meta-oe

[Andrea Adami]

Note there would be also the possibility to use the mkfs.cramfs
provided by util-linux implementing changes in image_types.bbclass and
util-linux itself.

Seems a bit overkill to me but still an option...

Andrea

On Tue, Jun 4, 2013 at 1:39 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
> ping
>
> Recipe is rather stable (tarball of v.1.1 dated 2002) and cramfs can
> be handy for read-only images on legacy devices.
>
> All the needed infrastructure is already present in
> image_types.bbclass so I'd say this recipe has been mistakenly
> forgotten when splitting out oe-core
>
>
> Andrea
>
> On Sun, May 26, 2013 at 1:23 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
>> * though listed in IMAGE_FSTYPES the helper is missing so
>> * make oe-core autosufficient importing the recipe.
>> * Fix PN -> BPN to avoid fetch errors with cramfs-native
>>
>> Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
>> ---
>>  meta/recipes-support/cramfs/cramfs_1.1.bb | 29 +++++++++++++++++++++++++++++
>>  1 file changed, 29 insertions(+)
>>  create mode 100644 meta/recipes-support/cramfs/cramfs_1.1.bb
>>
>> diff --git a/meta/recipes-support/cramfs/cramfs_1.1.bb b/meta/recipes-support/cramfs/cramfs_1.1.bb
>> new file mode 100644
>> index 0000000..0bca0e1
>> --- /dev/null
>> +++ b/meta/recipes-support/cramfs/cramfs_1.1.bb
>> @@ -0,0 +1,29 @@
>> +DESCRIPTION = "Builds cramfs filesystems for embedded systems"
>> +LICENSE = "GPLv2"
>> +LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
>> +DEPENDS = "zlib"
>> +
>> +PE = "1"
>> +
>> +SRC_URI = "http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz"
>> +
>> +SRC_URI[md5sum] = "d3912b9f7bf745fbfea68f6a9b9de30f"
>> +SRC_URI[sha256sum] = "133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368"
>> +
>> +EXTRA_OEMAKE = "\
>> +    'CC=${CC}' \
>> +    'CFLAGS=${CFLAGS}' \
>> +    'LDFLAGS=${LDFLAGS}' \
>> +"
>> +
>> +do_compile_prepend() {
>> +    ln -sf GNUmakefile Makefile
>> +}
>> +
>> +do_install() {
>> +    install -d ${D}${bindir}
>> +    install mkcramfs ${D}${bindir}
>> +    install cramfsck ${D}${bindir}
>> +}
>> +
>> +BBCLASSEXTEND = "native"
>> --
>> 1.8.1.5
>>

Re: [PATCH] cramfs: import recipe from meta-oe

[Andrea Adami]

ping

Maybe you want cramfs in recipes-devtools and not in recipes-support?
Feedback, please

Andrea

On Tue, Jun 4, 2013 at 1:51 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
> Note there would be also the possibility to use the mkfs.cramfs
> provided by util-linux implementing changes in image_types.bbclass and
> util-linux itself.
>
> Seems a bit overkill to me but still an option...
>
> Andrea
>
> On Tue, Jun 4, 2013 at 1:39 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
>> ping
>>
>> Recipe is rather stable (tarball of v.1.1 dated 2002) and cramfs can
>> be handy for read-only images on legacy devices.
>>
>> All the needed infrastructure is already present in
>> image_types.bbclass so I'd say this recipe has been mistakenly
>> forgotten when splitting out oe-core
>>
>>
>> Andrea
>>
>> On Sun, May 26, 2013 at 1:23 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
>>> * though listed in IMAGE_FSTYPES the helper is missing so
>>> * make oe-core autosufficient importing the recipe.
>>> * Fix PN -> BPN to avoid fetch errors with cramfs-native
>>>
>>> Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
>>> ---
>>>  meta/recipes-support/cramfs/cramfs_1.1.bb | 29 +++++++++++++++++++++++++++++
>>>  1 file changed, 29 insertions(+)
>>>  create mode 100644 meta/recipes-support/cramfs/cramfs_1.1.bb
>>>
>>> diff --git a/meta/recipes-support/cramfs/cramfs_1.1.bb b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>> new file mode 100644
>>> index 0000000..0bca0e1
>>> --- /dev/null
>>> +++ b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>> @@ -0,0 +1,29 @@
>>> +DESCRIPTION = "Builds cramfs filesystems for embedded systems"
>>> +LICENSE = "GPLv2"
>>> +LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
>>> +DEPENDS = "zlib"
>>> +
>>> +PE = "1"
>>> +
>>> +SRC_URI = "http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz"
>>> +
>>> +SRC_URI[md5sum] = "d3912b9f7bf745fbfea68f6a9b9de30f"
>>> +SRC_URI[sha256sum] = "133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368"
>>> +
>>> +EXTRA_OEMAKE = "\
>>> +    'CC=${CC}' \
>>> +    'CFLAGS=${CFLAGS}' \
>>> +    'LDFLAGS=${LDFLAGS}' \
>>> +"
>>> +
>>> +do_compile_prepend() {
>>> +    ln -sf GNUmakefile Makefile
>>> +}
>>> +
>>> +do_install() {
>>> +    install -d ${D}${bindir}
>>> +    install mkcramfs ${D}${bindir}
>>> +    install cramfsck ${D}${bindir}
>>> +}
>>> +
>>> +BBCLASSEXTEND = "native"
>>> --
>>> 1.8.1.5
>>>

Re: [PATCH] cramfs: import recipe from meta-oe

[Saul Wold]

On 06/11/2013 07:14 AM, Andrea Adami wrote:
> ping
>
> Maybe you want cramfs in recipes-devtools and not in recipes-support?
> Feedback, please
>
Apologies, we will not accept this recipe being moved into oe-core, 
there is not a strong case to move it to oe-core, cramfs is a image
type that is not heavily used, and the recipe is available in meta-oe.

Sau!

> Andrea
>
> On Tue, Jun 4, 2013 at 1:51 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
>> Note there would be also the possibility to use the mkfs.cramfs
>> provided by util-linux implementing changes in image_types.bbclass and
>> util-linux itself.
>>
>> Seems a bit overkill to me but still an option...
>>
>> Andrea
>>
>> On Tue, Jun 4, 2013 at 1:39 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
>>> ping
>>>
>>> Recipe is rather stable (tarball of v.1.1 dated 2002) and cramfs can
>>> be handy for read-only images on legacy devices.
>>>
>>> All the needed infrastructure is already present in
>>> image_types.bbclass so I'd say this recipe has been mistakenly
>>> forgotten when splitting out oe-core
>>>
>>>
>>> Andrea
>>>
>>> On Sun, May 26, 2013 at 1:23 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
>>>> * though listed in IMAGE_FSTYPES the helper is missing so
>>>> * make oe-core autosufficient importing the recipe.
>>>> * Fix PN -> BPN to avoid fetch errors with cramfs-native
>>>>
>>>> Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
>>>> ---
>>>>   meta/recipes-support/cramfs/cramfs_1.1.bb | 29 +++++++++++++++++++++++++++++
>>>>   1 file changed, 29 insertions(+)
>>>>   create mode 100644 meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>
>>>> diff --git a/meta/recipes-support/cramfs/cramfs_1.1.bb b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>> new file mode 100644
>>>> index 0000000..0bca0e1
>>>> --- /dev/null
>>>> +++ b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>> @@ -0,0 +1,29 @@
>>>> +DESCRIPTION = "Builds cramfs filesystems for embedded systems"
>>>> +LICENSE = "GPLv2"
>>>> +LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
>>>> +DEPENDS = "zlib"
>>>> +
>>>> +PE = "1"
>>>> +
>>>> +SRC_URI = "http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz"
>>>> +
>>>> +SRC_URI[md5sum] = "d3912b9f7bf745fbfea68f6a9b9de30f"
>>>> +SRC_URI[sha256sum] = "133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368"
>>>> +
>>>> +EXTRA_OEMAKE = "\
>>>> +    'CC=${CC}' \
>>>> +    'CFLAGS=${CFLAGS}' \
>>>> +    'LDFLAGS=${LDFLAGS}' \
>>>> +"
>>>> +
>>>> +do_compile_prepend() {
>>>> +    ln -sf GNUmakefile Makefile
>>>> +}
>>>> +
>>>> +do_install() {
>>>> +    install -d ${D}${bindir}
>>>> +    install mkcramfs ${D}${bindir}
>>>> +    install cramfsck ${D}${bindir}
>>>> +}
>>>> +
>>>> +BBCLASSEXTEND = "native"
>>>> --
>>>> 1.8.1.5
>>>>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

Re: [PATCH] cramfs: import recipe from meta-oe

[Andrea Adami]

On Tue, Jun 11, 2013 at 4:22 PM, Saul Wold <sgw@linux.intel.com> wrote:
> On 06/11/2013 07:14 AM, Andrea Adami wrote:
>>
>> ping
>>
>> Maybe you want cramfs in recipes-devtools and not in recipes-support?
>> Feedback, please
>>
> Apologies, we will not accept this recipe being moved into oe-core, there is
> not a strong case to move it to oe-core, cramfs is a image
> type that is not heavily used, and the recipe is available in meta-oe.
>
Saul,

See... the 'not heavily used'  is always relative: there are still
many devices out in the wild with cramfs 'firmwares'.

You're missing my first point: I/we aim to have as less layer
interdependency as possible (oe-core + BSP) so having to add meta-oe
is just an unneeded burden for most cases.
Oh, and it would be one recipe less in that meta-oe pot.

Thx for your review

Cheers
Andrea

> Sau!
>
>> Andrea
>>
>> On Tue, Jun 4, 2013 at 1:51 PM, Andrea Adami <andrea.adami@gmail.com>
>> wrote:
>>>
>>> Note there would be also the possibility to use the mkfs.cramfs
>>> provided by util-linux implementing changes in image_types.bbclass and
>>> util-linux itself.
>>>
>>> Seems a bit overkill to me but still an option...
>>>
>>> Andrea
>>>
>>> On Tue, Jun 4, 2013 at 1:39 PM, Andrea Adami <andrea.adami@gmail.com>
>>> wrote:
>>>>
>>>> ping
>>>>
>>>> Recipe is rather stable (tarball of v.1.1 dated 2002) and cramfs can
>>>> be handy for read-only images on legacy devices.
>>>>
>>>> All the needed infrastructure is already present in
>>>> image_types.bbclass so I'd say this recipe has been mistakenly
>>>> forgotten when splitting out oe-core
>>>>
>>>>
>>>> Andrea
>>>>
>>>> On Sun, May 26, 2013 at 1:23 AM, Andrea Adami <andrea.adami@gmail.com>
>>>> wrote:
>>>>>
>>>>> * though listed in IMAGE_FSTYPES the helper is missing so
>>>>> * make oe-core autosufficient importing the recipe.
>>>>> * Fix PN -> BPN to avoid fetch errors with cramfs-native
>>>>>
>>>>> Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
>>>>> ---
>>>>>   meta/recipes-support/cramfs/cramfs_1.1.bb | 29
>>>>> +++++++++++++++++++++++++++++
>>>>>   1 file changed, 29 insertions(+)
>>>>>   create mode 100644 meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>>
>>>>> diff --git a/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>> b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>> new file mode 100644
>>>>> index 0000000..0bca0e1
>>>>> --- /dev/null
>>>>> +++ b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>> @@ -0,0 +1,29 @@
>>>>> +DESCRIPTION = "Builds cramfs filesystems for embedded systems"
>>>>> +LICENSE = "GPLv2"
>>>>> +LIC_FILES_CHKSUM =
>>>>> "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
>>>>> +DEPENDS = "zlib"
>>>>> +
>>>>> +PE = "1"
>>>>> +
>>>>> +SRC_URI =
>>>>> "http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz"
>>>>> +
>>>>> +SRC_URI[md5sum] = "d3912b9f7bf745fbfea68f6a9b9de30f"
>>>>> +SRC_URI[sha256sum] =
>>>>> "133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368"
>>>>> +
>>>>> +EXTRA_OEMAKE = "\
>>>>> +    'CC=${CC}' \
>>>>> +    'CFLAGS=${CFLAGS}' \
>>>>> +    'LDFLAGS=${LDFLAGS}' \
>>>>> +"
>>>>> +
>>>>> +do_compile_prepend() {
>>>>> +    ln -sf GNUmakefile Makefile
>>>>> +}
>>>>> +
>>>>> +do_install() {
>>>>> +    install -d ${D}${bindir}
>>>>> +    install mkcramfs ${D}${bindir}
>>>>> +    install cramfsck ${D}${bindir}
>>>>> +}
>>>>> +
>>>>> +BBCLASSEXTEND = "native"
>>>>> --
>>>>> 1.8.1.5
>>>>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>

Re: [PATCH] cramfs: import recipe from meta-oe

[Bruce Ashfield]

On Tue, Jun 11, 2013 at 11:41 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
> On Tue, Jun 11, 2013 at 4:22 PM, Saul Wold <sgw@linux.intel.com> wrote:
>> On 06/11/2013 07:14 AM, Andrea Adami wrote:
>>>
>>> ping
>>>
>>> Maybe you want cramfs in recipes-devtools and not in recipes-support?
>>> Feedback, please
>>>
>> Apologies, we will not accept this recipe being moved into oe-core, there is
>> not a strong case to move it to oe-core, cramfs is a image
>> type that is not heavily used, and the recipe is available in meta-oe.
>>
> Saul,
>
> See... the 'not heavily used'  is always relative: there are still
> many devices out in the wild with cramfs 'firmwares'.
>
> You're missing my first point: I/we aim to have as less layer
> interdependency as possible (oe-core + BSP) so having to add meta-oe
> is just an unneeded burden for most cases.

I have a similar use case with BSPs and deployment methods. I missed
the start of the thread, but thought the idea of moving this into oe-core
along side the other image types was a good idea. I personally don't see
a big issue or burden with moving it into the base since to me, that's where
image types and formats belong.

Cheers,

Bruce

> Oh, and it would be one recipe less in that meta-oe pot.
>
> Thx for your review
>
> Cheers
> Andrea
>
>> Sau!
>>
>>> Andrea
>>>
>>> On Tue, Jun 4, 2013 at 1:51 PM, Andrea Adami <andrea.adami@gmail.com>
>>> wrote:
>>>>
>>>> Note there would be also the possibility to use the mkfs.cramfs
>>>> provided by util-linux implementing changes in image_types.bbclass and
>>>> util-linux itself.
>>>>
>>>> Seems a bit overkill to me but still an option...
>>>>
>>>> Andrea
>>>>
>>>> On Tue, Jun 4, 2013 at 1:39 PM, Andrea Adami <andrea.adami@gmail.com>
>>>> wrote:
>>>>>
>>>>> ping
>>>>>
>>>>> Recipe is rather stable (tarball of v.1.1 dated 2002) and cramfs can
>>>>> be handy for read-only images on legacy devices.
>>>>>
>>>>> All the needed infrastructure is already present in
>>>>> image_types.bbclass so I'd say this recipe has been mistakenly
>>>>> forgotten when splitting out oe-core
>>>>>
>>>>>
>>>>> Andrea
>>>>>
>>>>> On Sun, May 26, 2013 at 1:23 AM, Andrea Adami <andrea.adami@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> * though listed in IMAGE_FSTYPES the helper is missing so
>>>>>> * make oe-core autosufficient importing the recipe.
>>>>>> * Fix PN -> BPN to avoid fetch errors with cramfs-native
>>>>>>
>>>>>> Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
>>>>>> ---
>>>>>>   meta/recipes-support/cramfs/cramfs_1.1.bb | 29
>>>>>> +++++++++++++++++++++++++++++
>>>>>>   1 file changed, 29 insertions(+)
>>>>>>   create mode 100644 meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>>>
>>>>>> diff --git a/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>>> b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>>> new file mode 100644
>>>>>> index 0000000..0bca0e1
>>>>>> --- /dev/null
>>>>>> +++ b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>>> @@ -0,0 +1,29 @@
>>>>>> +DESCRIPTION = "Builds cramfs filesystems for embedded systems"
>>>>>> +LICENSE = "GPLv2"
>>>>>> +LIC_FILES_CHKSUM =
>>>>>> "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
>>>>>> +DEPENDS = "zlib"
>>>>>> +
>>>>>> +PE = "1"
>>>>>> +
>>>>>> +SRC_URI =
>>>>>> "http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz"
>>>>>> +
>>>>>> +SRC_URI[md5sum] = "d3912b9f7bf745fbfea68f6a9b9de30f"
>>>>>> +SRC_URI[sha256sum] =
>>>>>> "133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368"
>>>>>> +
>>>>>> +EXTRA_OEMAKE = "\
>>>>>> +    'CC=${CC}' \
>>>>>> +    'CFLAGS=${CFLAGS}' \
>>>>>> +    'LDFLAGS=${LDFLAGS}' \
>>>>>> +"
>>>>>> +
>>>>>> +do_compile_prepend() {
>>>>>> +    ln -sf GNUmakefile Makefile
>>>>>> +}
>>>>>> +
>>>>>> +do_install() {
>>>>>> +    install -d ${D}${bindir}
>>>>>> +    install mkcramfs ${D}${bindir}
>>>>>> +    install cramfsck ${D}${bindir}
>>>>>> +}
>>>>>> +
>>>>>> +BBCLASSEXTEND = "native"
>>>>>> --
>>>>>> 1.8.1.5
>>>>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>>
>>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [PATCH] cramfs: import recipe from meta-oe

[Saul Wold]

On 06/11/2013 08:41 AM, Andrea Adami wrote:
> On Tue, Jun 11, 2013 at 4:22 PM, Saul Wold <sgw@linux.intel.com> wrote:
>> On 06/11/2013 07:14 AM, Andrea Adami wrote:
>>>
>>> ping
>>>
>>> Maybe you want cramfs in recipes-devtools and not in recipes-support?
>>> Feedback, please
>>>
>> Apologies, we will not accept this recipe being moved into oe-core, there is
>> not a strong case to move it to oe-core, cramfs is a image
>> type that is not heavily used, and the recipe is available in meta-oe.
>>
> Saul,
>
> See... the 'not heavily used'  is always relative: there are still
> many devices out in the wild with cramfs 'firmwares'.
>
This along with other filesystem related items, such as the FUSE 
discussion should be moved into a meta-filesystems layer within 
meta-openembedded similar to the way that meta-networking is structured.

> You're missing my first point: I/we aim to have as less layer
> interdependency as possible (oe-core + BSP) so having to add meta-oe
> is just an unneeded burden for most cases.
> Oh, and it would be one recipe less in that meta-oe pot.
>
By refactoring it as a layer within meta-openembedded would also not 
make it "one more recipe" in OE-Core. It will be not as heavy as the 
meta-oe. OE-core can't test and maintain everything, again relative usage.

Your right it should move someplace, but not into OE-Core.

Sau!


> Thx for your review
>
> Cheers
> Andrea
>
>> Sau!
>>
>>> Andrea
>>>
>>> On Tue, Jun 4, 2013 at 1:51 PM, Andrea Adami <andrea.adami@gmail.com>
>>> wrote:
>>>>
>>>> Note there would be also the possibility to use the mkfs.cramfs
>>>> provided by util-linux implementing changes in image_types.bbclass and
>>>> util-linux itself.
>>>>
>>>> Seems a bit overkill to me but still an option...
>>>>
>>>> Andrea
>>>>
>>>> On Tue, Jun 4, 2013 at 1:39 PM, Andrea Adami <andrea.adami@gmail.com>
>>>> wrote:
>>>>>
>>>>> ping
>>>>>
>>>>> Recipe is rather stable (tarball of v.1.1 dated 2002) and cramfs can
>>>>> be handy for read-only images on legacy devices.
>>>>>
>>>>> All the needed infrastructure is already present in
>>>>> image_types.bbclass so I'd say this recipe has been mistakenly
>>>>> forgotten when splitting out oe-core
>>>>>
>>>>>
>>>>> Andrea
>>>>>
>>>>> On Sun, May 26, 2013 at 1:23 AM, Andrea Adami <andrea.adami@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> * though listed in IMAGE_FSTYPES the helper is missing so
>>>>>> * make oe-core autosufficient importing the recipe.
>>>>>> * Fix PN -> BPN to avoid fetch errors with cramfs-native
>>>>>>
>>>>>> Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
>>>>>> ---
>>>>>>    meta/recipes-support/cramfs/cramfs_1.1.bb | 29
>>>>>> +++++++++++++++++++++++++++++
>>>>>>    1 file changed, 29 insertions(+)
>>>>>>    create mode 100644 meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>>>
>>>>>> diff --git a/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>>> b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>>> new file mode 100644
>>>>>> index 0000000..0bca0e1
>>>>>> --- /dev/null
>>>>>> +++ b/meta/recipes-support/cramfs/cramfs_1.1.bb
>>>>>> @@ -0,0 +1,29 @@
>>>>>> +DESCRIPTION = "Builds cramfs filesystems for embedded systems"
>>>>>> +LICENSE = "GPLv2"
>>>>>> +LIC_FILES_CHKSUM =
>>>>>> "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
>>>>>> +DEPENDS = "zlib"
>>>>>> +
>>>>>> +PE = "1"
>>>>>> +
>>>>>> +SRC_URI =
>>>>>> "http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz"
>>>>>> +
>>>>>> +SRC_URI[md5sum] = "d3912b9f7bf745fbfea68f6a9b9de30f"
>>>>>> +SRC_URI[sha256sum] =
>>>>>> "133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368"
>>>>>> +
>>>>>> +EXTRA_OEMAKE = "\
>>>>>> +    'CC=${CC}' \
>>>>>> +    'CFLAGS=${CFLAGS}' \
>>>>>> +    'LDFLAGS=${LDFLAGS}' \
>>>>>> +"
>>>>>> +
>>>>>> +do_compile_prepend() {
>>>>>> +    ln -sf GNUmakefile Makefile
>>>>>> +}
>>>>>> +
>>>>>> +do_install() {
>>>>>> +    install -d ${D}${bindir}
>>>>>> +    install mkcramfs ${D}${bindir}
>>>>>> +    install cramfsck ${D}${bindir}
>>>>>> +}
>>>>>> +
>>>>>> +BBCLASSEXTEND = "native"
>>>>>> --
>>>>>> 1.8.1.5
>>>>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>>
>>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>