Add FUSE: File system in Userspace
cover Add FUSE: File system in Userspace
Add fuse to oe-core and let target system could support ntfs' and exfat' filesystems.
Test Case
*Steps
1, preparation
1 target: e-menlow
2 usb sticks: one for boot and install, another for filesystem test.
2, configconf/local.conf:
247 MACHINE ?= "emenlow-noemgd"
247 IMAGE_INSTALL_append = " ntfs-3g ntfsprogs fuse-exfat exfat-utils"
conf/bblayers.conf:
8 BBLAYERS ?= " \
9 /home/jiahongxu/yocto/poky/meta \ 10 /home/jiahongxu/yocto/poky/meta-yocto \ 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ 12 /home/jiahongxu/yocto/poky/meta-intel \ 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \
3, build image
bitbake core-image-sato
4, load image to emenlow
Test Case TC-2927: boot and install from usb
5, open a terminal/ssh of e-menlow
Test Case TC-2955: remote access by ssh
6, make exfat filesystem on the testing usb storage
1) plug usb stick into e-menlow
2) execute `mkfs.exfat /dev/sdc1'
7, test usb stick with exfat filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files
8, make ntfs filesystem on the testing usb storage
1) plug usb stick into e-menlow, if mounted, invoke `umount /dev/sdc1' first.
2) execute `mkfs.ntfs -f /dev/sdc1'
9, test usb stick with ntfs filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files
*Expected Results:
1, build image success
2, make exfat filesystem success
root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 mkexfatfs 1.0.1 Creating... done. Flushing... done. File system created successfully.
3, make ntfs filesystem success
root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 Cluster size has been automatically set to 4096 bytes. Creating NTFS volume structures. mkntfs completed successfully. Have a nice day.
4, While the usb's filesystem type is exfat or ntfs, system can mount plugged usb automatically, read files from usb, write files to usb and unmout usb automatically.
[YOCTO #4178]
The following changes since commit 350c36fcd97e8ef223b91e548d39c346c1c4cb29:
bitbake: test/fetch: Allow the conditional network tests to work under python 2.6 (2013-05-17 12:42:08 +0300)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib hongxu/support-fuse
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuse
Hongxu Jia (4):
fuse: import recipe from meta-oe ntfs-3g-ntfsprogs:import and update recipe from meta-oe
fuse-exfat: add version 1.0.1
exfat-utils: add version 1.0.1
meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++ meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ 6 files changed, 206 insertions(+) create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb create mode 100644 meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
Signature · 1 line
1.7.10.4
PATCH 1/4 fuse: import recipe from meta-oe
add version 2.9.2
This recipes is required by ntfs-3g-ntfsprogs and exfat.
[YOCTO #4178]
--- meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++ meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ 3 files changed, 118 insertions(+) create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb
meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch new file +20 -0
@@ -0,0 +1,20 @@ +Upstream-Status: Submitted + +Signed-off-by: Riku Voipio <[email protected]> + +--- a/include/fuse_kernel.h ++++ b/include/fuse_kernel.h +@@ -88,12 +88,7 @@ + #ifndef _LINUX_FUSE_H + #define _LINUX_FUSE_H + +-#include <sys/types.h> +-#define __u64 uint64_t +-#define __s64 int64_t +-#define __u32 uint32_t +-#define __s32 int32_t +-#define __u16 uint16_t ++#include <linux/types.h> + + /* + * Version negotiation:
meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch new file +60 -0
60 lines not on this page · raw message
meta/recipes-support/fuse/fuse_2.9.2.bb new file +38 -0
@@ -0,0 +1,38 @@ +DESCRIPTION = "With FUSE it is possible to implement a fully functional filesystem in a userspace program" +HOMEPAGE = "http://fuse.sf.net" +SECTION = "libs" +LICENSE = "GPLv2 & LGPLv2" +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ + file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c" + +SRC_URI = "${SOURCEFORGE_MIRROR}/fuse/fuse-${PV}.tar.gz \ + file://gold-unversioned-symbol.patch \ + file://aarch64.patch \ +" +SRC_URI[md5sum] = "7d80d0dc9cc2b9199a0c53787c151205" +SRC_URI[sha256sum] = "81a728fb3f87da33063068735e2fb7e2cd89df207d32687d3d3278385279cefc" + +inherit autotools pkgconfig + +EXTRA_OECONF = "--disable-kernel-module" + +PACKAGES =+ "fuse-utils-dbg fuse-utils libulockmgr libulockmgr-dev libulockmgr-dbg" + +RRECOMMENDS_${PN} = "kernel-module-fuse" + +FILES_${PN} += "${libdir}/libfuse.so.*" +FILES_${PN}-dev += "${libdir}/libfuse*.la" + +FILES_libulockmgr = "${libdir}/libulockmgr.so.*" +FILES_libulockmgr-dev += "${libdir}/libulock*.la" +FILES_libulockmgr-dbg += "${libdir}/.debug/libulock*" + +# Forbid auto-renaming to libfuse-utils +FILES_fuse-utils = "${bindir} ${base_sbindir}" +FILES_fuse-utils-dbg = "${bindir}/.debug ${base_sbindir}/.debug" +DEBIAN_NOAUTONAME_fuse-utils = "1" +DEBIAN_NOAUTONAME_fuse-utils-dbg = "1" + +do_install_append() { + rm -rf ${D}${base_prefix}/dev +}
Signature · 1 line
1.7.10.4
PATCH 2/4 ntfs-3g-ntfsprogs:import and update recipe from meta-oe
In reply to Hongxu JiaImport version 2011.4.12 from meta-oe and update to version 2013.1.13.
This recipe is a merge of ntfs-3g and ntfsprogs
[YOCTO #4178]
--- .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 ++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb new file +33 -0
@@ -0,0 +1,33 @@ +DESCRIPTION = "The NTFS-3G driver is an open source, freely available NTFS driver for Linux with read and write support." +HOMEPAGE = "http://www.ntfs-3g.org/" +DEPENDS = "fuse libgcrypt" +PROVIDES = "ntfsprogs ntfs-3g" +LICENSE = "GPLv2 & LGPLv2" +LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \ + file://COPYING.LIB;md5=f30a9716ef3762e3467a2f62bf790f0a" + +SRC_URI = "http://tuxera.com/opensource/ntfs-3g_ntfsprogs-${PV}.tgz" +S = "${WORKDIR}/ntfs-3g_ntfsprogs-${PV}" + +SRC_URI[md5sum] = "2d6fb47ddf62b51733227126fe9227fe" +SRC_URI[sha256sum] = "4b383f0074a3ab7683339d1f18222b107aaeb4983db119292c43c2b275cefb27" + +inherit autotools + +# required or it calls ldconfig at install step +EXTRA_OEMAKE = "LDCONFIG=echo" + +PACKAGES =+ "ntfs-3g ntfsprogs libntfs-3g" + +FILES_ntfs-3g = "${base_sbindir}/*.ntfs-3g ${bindir}/ntfs-3g* ${base_sbindir}/mount.ntfs" +RDEPENDS_ntfs-3g += "fuse util-linux-mount" + +FILES_ntfsprogs = "${base_sbindir}/* ${bindir}/* ${sbindir}/*" +FILES_libntfs-3g = "${libdir}/*${SOLIBS}" + +do_install_append() { + # Standard mount will execute the program /sbin/mount.TYPE + # when called. Add the symbolic to let mount could find ntfs. + ln -sf mount.ntfs-3g ${D}/${base_sbindir}/mount.ntfs +} +
Signature · 1 line
1.7.10.4
PATCH 3/4 fuse-exfat: add version 1.0.1
In reply to Hongxu JiaThe fuse-exfat is read and write exFAT driver for FUSE
[YOCTO #4178]
--- meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 ++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb
meta/recipes-support/exfat/fuse-exfat_1.0.1.bb new file +26 -0
@@ -0,0 +1,26 @@ +SUMMARY = "read and write exFAT driver for FUSE" +DESCRIPTION = "fuse-exfat is a read and write driver implementing the \ +extended file allocation table as a filesystem in userspace. A mounthelper \ +is provided unter the name mount.exfat-fuse. \ +" +HOMEPAGE = "http://code.google.com/p/exfat/" +SECTION = "universe/otherosfs" +LICENSE = "GPLv3" +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" +SRC_URI = "${DEBIAN_MIRROR}/main/f/fuse-exfat/fuse-exfat_${PV}.orig.tar.gz \ +" +DEPENDS = "fuse virtual/libc" +RDEPENDS_${PN} += "util-linux-mount" + +inherit scons + +SRC_URI[md5sum] = "7988a5111841593231f20af22153362d" +SRC_URI[sha256sum] = "12ac1ba1b7d4343bef64e7898176705a41cfe3b5a7a179e28549d242e2854758" + +EXTRA_OESCONS = " \ + DESTDIR=${D}/${base_sbindir} \ +" + +do_install_prepend() { + install -d ${D}/${base_sbindir} +}
Signature · 1 line
1.7.10.4
PATCH 4/4 exfat-utils: add version 1.0.1
In reply to Hongxu JiaThe utilities to create, check, label and dump exFAT filesystem
[YOCTO #4178]
--- meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 +++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb
meta/recipes-support/exfat/exfat-utils_1.0.1.bb new file +29 -0
@@ -0,0 +1,29 @@ +SUMMARY = "utilities to create, check, label and dump exFAT filesystem" +DESCRIPTION = "Utilities to manage extended file allocation table filesystem. \ +This package provides tools to create, check and label the filesystem. It \ +contains \ + - dumpexfat to dump properties of the filesystem \ + - exfatfsck / fsck.exfat to report errors found on a exFAT filesystem \ + - exfatlabel to label a exFAT filesystem \ + - mkexfatfs / mkfs.exfat to create a exFAT filesystem. \ +" +HOMEPAGE = "http://code.google.com/p/exfat/" +SECTION = "universe/otherosfs" +LICENSE = "GPLv3" +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" +SRC_URI = "${DEBIAN_MIRROR}/main/e/exfat-utils/exfat-utils_${PV}.orig.tar.gz \ +" +DEPENDS = "virtual/libc" + +inherit scons + +SRC_URI[md5sum] = "e592130829d0bf61fa5e3cd1c759d329" +SRC_URI[sha256sum] = "eeacedca1878065dc3886674ae39cd51149c37bd7d6d7e9325c971a1d1acdab3" + +EXTRA_OESCONS = " \ + DESTDIR=${D}/${base_sbindir} \ +" + +do_install_prepend() { + install -d ${D}/${base_sbindir} +}
Signature · 1 line
1.7.10.4
Quoted 96 lines · Hongxu Jia
Add fuse to oe-core and let target system could support
ntfs' andexfat' filesystems.Test Case
*Steps
1, preparation
1 target: e-menlow
2 usb sticks: one for boot and install, another for filesystem test.2, config
conf/local.conf:
247 MACHINE ?= "emenlow-noemgd"
247IMAGE_INSTALL_append= " ntfs-3g ntfsprogs fuse-exfat exfat-utils"
conf/bblayers.conf:8 BBLAYERS ?= " \ 9 /home/jiahongxu/yocto/poky/meta \ 10 /home/jiahongxu/yocto/poky/meta-yocto \ 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ 12 /home/jiahongxu/yocto/poky/meta-intel \ 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \3, build image
bitbake core-image-sato4, load image to emenlow
Test Case TC-2927: boot and install from usb5, open a terminal/ssh of e-menlow
Test Case TC-2955: remote access by ssh6, make exfat filesystem on the testing usb storage
1) plug usb stick into e-menlow
2) execute `mkfs.exfat/dev/sdc1'7, test usb stick with exfat filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files8, make ntfs filesystem on the testing usb storage
1) plug usb stick into e-menlow, if mounted, invoke `umount/dev/sdc1' first.
2) execute `mkfs.ntfs -f/dev/sdc1'9, test usb stick with ntfs filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files*Expected Results:
1, build image success2, make exfat filesystem success
root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 mkexfatfs 1.0.1 Creating... done. Flushing... done. File system created successfully.3, make ntfs filesystem success
root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 Cluster size has been automatically set to 4096 bytes. Creating NTFS volume structures. mkntfs completed successfully. Have a nice day.4, While the usb's filesystem type is exfat or ntfs, system can mount plugged usb automatically, read files from usb, write files to usb and unmout usb automatically.
[YOCTO #4178]
The following changes since commit
350c36fcd97e8ef223b91e548d39c346c1c4cb29:bitbake: test/fetch: Allow the conditional network tests to work under python 2.6 (2013-05-17 12:42:08 +0300)
are available in the git repository at:
git://git.pokylinux.org/poky-contribhongxu/support-fuse
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuseHongxu Jia (4):
fuse: import recipe from meta-oe ntfs-3g-ntfsprogs:import and update recipe from meta-oe
fuse-exfat: add version 1.0.1
exfat-utils: add version 1.0.1meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++ meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ 6 files changed, 206 insertions(+)
Quoted 7 lines
create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb
create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb
create mode 100644meta/recipes-support/fuse/fuse-2.9.2/aarch64.patchcreate mode 100644meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patchcreate mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb
create mode 100644 meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
Without trying to be difficult, is oe-core really the place to support and spend effort ensuring NTFS/exFAT formatted drives are supported?
Could these improvements not stay in meta-oe? I don't really see support for essentially propriety filesystems as a core feature of a Linux build.
Shout up if I'm talking nonsense, just my 2p.
Signature · 5 lines
Jack Mitchell ([email protected]) Embedded Systems Engineer http://www.embed.me.uk --
Quoted 70 lines · On Thursday 30 May 2013 10:18:56 Jack Mitchell wrote:
Quoted 69 lines · Hongxu Jia
Add fuse to oe-core and let target system could support
ntfs' andexfat' filesystems.Test Case
*Steps
1, preparation
1 target: e-menlow
2 usb sticks: one for boot and install, another for filesystem test.2, config
conf/local.conf:
247 MACHINE ?= "emenlow-noemgd"
247IMAGE_INSTALL_append= " ntfs-3g ntfsprogs fuse-exfat exfat-utils"
conf/bblayers.conf:8 BBLAYERS ?= " \ 9 /home/jiahongxu/yocto/poky/meta \10 /home/jiahongxu/yocto/poky/meta-yocto \ 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ 12 /home/jiahongxu/yocto/poky/meta-intel \ 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \3, build image
bitbake core-image-sato4, load image to emenlow
Test Case TC-2927: boot and install from usb5, open a terminal/ssh of e-menlow
Test Case TC-2955: remote access by ssh6, make exfat filesystem on the testing usb storage
1) plug usb stick into e-menlow
2) execute `mkfs.exfat/dev/sdc1'7, test usb stick with exfat filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files8, make ntfs filesystem on the testing usb storage
1) plug usb stick into e-menlow, if mounted, invokeumount /dev/sdc1' first. 2) executemkfs.ntfs -f/dev/sdc1'9, test usb stick with ntfs filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files*Expected Results:
1, build image success2, make exfat filesystem success
root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 mkexfatfs 1.0.1 Creating... done. Flushing... done. File system created successfully.3, make ntfs filesystem success
root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 Cluster size has been automatically set to 4096 bytes. Creating NTFS volume structures. mkntfs completed successfully. Have a nice day.
Quoted 7 lines
Quoted 7 lines
4, While the usb's filesystem type is exfat or ntfs, system can mount plugged usb automatically, read files from usb, write files to usb and unmout usb automatically.
[YOCTO #4178]
The following changes since commit
350c36fcd97e8ef223b91e548d39c346c1c4cb29:
Quoted 29 lines
Quoted 20 lines
bitbake: test/fetch: Allow the conditional network tests to work under python 2.6 (2013-05-17 12:42:08 +0300)>
are available in the git repository at:
git://git.pokylinux.org/poky-contribhongxu/support-fuse
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fu
seHongxu Jia (4):
fuse: import recipe from meta-oe ntfs-3g-ntfsprogs:import and update recipe from meta-oe
fuse-exfat: add version 1.0.1
exfat-utils: add version 1.0.1meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++ meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ 6 files changed, 206 insertions(+)Quoted 8 lines
create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb create mode 100644
meta/recipes-support/fuse/fuse-2.9.2/aarch64.patchcreate mode 100644meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patchcreate mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb create mode 100644 meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
Quoted 7 lines
Without trying to be difficult, is oe-core really the place to support and spend effort ensuring NTFS/exFAT formatted drives are supported?
Could these improvements not stay in meta-oe? I don't really see support for essentially propriety filesystems as a core feature of a Linux build.
Shout up if I'm talking nonsense, just my 2p.
That was also my comment on the bug report, FWIW:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4178
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 106 lines · Jack Mitchell
Quoted 96 lines · Hongxu Jia
Add fuse to oe-core and let target system could support
ntfs' andexfat' filesystems.Test Case
*Steps
1, preparation
1 target: e-menlow
2 usb sticks: one for boot and install, another for filesystem test.2, config
conf/local.conf:
247 MACHINE ?= "emenlow-noemgd"
247IMAGE_INSTALL_append= " ntfs-3g ntfsprogs fuse-exfat exfat-utils"
conf/bblayers.conf:8 BBLAYERS ?= " \ 9 /home/jiahongxu/yocto/poky/meta \ 10 /home/jiahongxu/yocto/poky/meta-yocto \ 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ 12 /home/jiahongxu/yocto/poky/meta-intel \ 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \3, build image
bitbake core-image-sato4, load image to emenlow
Test Case TC-2927: boot and install from usb5, open a terminal/ssh of e-menlow
Test Case TC-2955: remote access by ssh6, make exfat filesystem on the testing usb storage
1) plug usb stick into e-menlow
2) execute `mkfs.exfat/dev/sdc1'7, test usb stick with exfat filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files8, make ntfs filesystem on the testing usb storage
1) plug usb stick into e-menlow, if mounted, invoke `umount/dev/sdc1' first.
2) execute `mkfs.ntfs -f/dev/sdc1'9, test usb stick with ntfs filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files*Expected Results:
1, build image success2, make exfat filesystem success
root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 mkexfatfs 1.0.1 Creating... done. Flushing... done. File system created successfully.3, make ntfs filesystem success
root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 Cluster size has been automatically set to 4096 bytes. Creating NTFS volume structures. mkntfs completed successfully. Have a nice day.4, While the usb's filesystem type is exfat or ntfs, system can mount plugged usb automatically, read files from usb, write files to usb and unmout usb automatically.
[YOCTO #4178]
The following changes since commit
350c36fcd97e8ef223b91e548d39c346c1c4cb29:bitbake: test/fetch: Allow the conditional network tests to work under python 2.6 (2013-05-17 12:42:08 +0300)are available in the git repository at:
git://git.pokylinux.org/poky-contribhongxu/support-fuse
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuseHongxu Jia (4):
fuse: import recipe from meta-oe ntfs-3g-ntfsprogs:import and update recipe from meta-oe
fuse-exfat: add version 1.0.1
exfat-utils: add version 1.0.1meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++ meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ 6 files changed, 206 insertions(+)Quoted 7 lines
create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb
create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb
create mode 100644meta/recipes-support/fuse/fuse-2.9.2/aarch64.patchcreate mode 100644meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patchcreate mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb
create mode 100644 meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
Quoted 2 lines
Without trying to be difficult, is oe-core really the place to support and spend effort ensuring NTFS/exFAT formatted drives are supported?
The basis of this work comes from pretty much all SD/MicroSD cards, most consumer USB hard disks, etc being preformatted as NTFS/exFAT. When building a consumer device the designers often want to just use FUSE out of the box so they don't have to work on adding the functionality themselves.
meta-oe is often times too much stuff in one bundle to just included in a project. The developers I work with prefer a smaller load of packages, primarily oe-core + whatever they need. It makes it easier to support and easier to prevent problems from being introduced by feature creep.
Quoted 2 lines
Could these improvements not stay in meta-oe? I don't really see support for essentially propriety filesystems as a core feature of a Linux build.
Yes they could, but then it forces more people to copy the recipes out of meta-oe.
I myself am mixed on if fuse belongs on oe-core or not. I can see the argument both ways on including it or rejecting it. However, I'm getting more and more commercial requests for FUSE to be part of the main system.
Quoted 2 lines
Shout up if I'm talking nonsense, just my 2p.
Quoted 125 lines · Mark Hatle
Quoted 115 lines · Jack Mitchell
Quoted 103 lines · Hongxu Jia
Add fuse to oe-core and let target system could support
ntfs' andexfat' filesystems.Test Case
*Steps
1, preparation
1 target: e-menlow
2 usb sticks: one for boot and install, another for filesystem test.2, config
conf/local.conf:
247 MACHINE ?= "emenlow-noemgd"
247IMAGE_INSTALL_append= " ntfs-3g ntfsprogs fuse-exfat exfat-utils"
conf/bblayers.conf:8 BBLAYERS ?= " \ 9 /home/jiahongxu/yocto/poky/meta \ 10 /home/jiahongxu/yocto/poky/meta-yocto \ 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ 12 /home/jiahongxu/yocto/poky/meta-intel \ 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \3, build image
bitbake core-image-sato4, load image to emenlow
Test Case TC-2927: boot and install from usb5, open a terminal/ssh of e-menlow
Test Case TC-2955: remote access by ssh6, make exfat filesystem on the testing usb storage
1) plug usb stick into e-menlow
2) execute `mkfs.exfat/dev/sdc1'7, test usb stick with exfat filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files8, make ntfs filesystem on the testing usb storage
1) plug usb stick into e-menlow, if mounted, invoke `umount/dev/sdc1' first.
2) execute `mkfs.ntfs -f/dev/sdc1'9, test usb stick with ntfs filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files*Expected Results:
1, build image success2, make exfat filesystem success
root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 mkexfatfs 1.0.1 Creating... done. Flushing... done. File system created successfully.3, make ntfs filesystem success
root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 Cluster size has been automatically set to 4096 bytes. Creating NTFS volume structures. mkntfs completed successfully. Have a nice day.4, While the usb's filesystem type is exfat or ntfs, system can mount plugged usb automatically, read files from usb, write files to usb and unmout usb automatically.
[YOCTO #4178]
The following changes since commit
350c36fcd97e8ef223b91e548d39c346c1c4cb29:bitbake: test/fetch: Allow the conditional network tests to work
under python 2.6 (2013-05-17 12:42:08 +0300)are available in the git repository at:
git://git.pokylinux.org/poky-contribhongxu/support-fusehttp://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuse
Hongxu Jia (4):
fuse: import recipe from meta-oe ntfs-3g-ntfsprogs:import and update recipe from meta-oe
fuse-exfat: add version 1.0.1
exfat-utils: add version 1.0.1meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++ meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ 6 files changed, 206 insertions(+)Quoted 9 lines
create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb create mode 100644
meta/recipes-support/fuse/fuse-2.9.2/aarch64.patchcreate mode 100644meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch
create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb create mode 100644
meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bbQuoted 2 lines
Without trying to be difficult, is oe-core really the place to support and spend effort ensuring NTFS/exFAT formatted drives are supported?
The basis of this work comes from pretty much all SD/MicroSD cards, most consumer USB hard disks, etc being preformatted as NTFS/exFAT. When building a consumer device the designers often want to just use FUSE out of the box so they don't have to work on adding the functionality themselves.
Quoted 5 lines
meta-oe is often times too much stuff in one bundle to just included in a project. The developers I work with prefer a smaller load of packages, primarily oe-core + whatever they need. It makes it easier to support and easier to prevent problems from being introduced by feature creep.
If there are issues using meta-oe for a few recipes, we need to identify these issues and fix them.
If we do not advocate for the layer model, we risk creeping slowly back to the monolithic OE of days gone by.
Philip
Quoted 20 lines
Quoted 3 lines
Could these improvements not stay in meta-oe? I don't really see support for essentially propriety filesystems as a core feature of a Linux build.
Yes they could, but then it forces more people to copy the recipes out of meta-oe.
I myself am mixed on if fuse belongs on oe-core or not. I can see the argument both ways on including it or rejecting it. However, I'm getting more and more commercial requests for FUSE to be part of the main system.
Quoted 2 lines
Shout up if I'm talking nonsense, just my 2p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 126 lines · Philip Balister
Quoted 125 lines · Mark Hatle
Quoted 115 lines · Jack Mitchell
Quoted 110 lines · Hongxu Jia
Add fuse to oe-core and let target system could support
ntfs' andexfat' filesystems.Test Case
*Steps
1, preparation
1 target: e-menlow
2 usb sticks: one for boot and install, another for filesystem test.2, config
conf/local.conf:
247 MACHINE ?= "emenlow-noemgd"
247IMAGE_INSTALL_append= " ntfs-3g ntfsprogs fuse-exfat exfat-utils"
conf/bblayers.conf:8 BBLAYERS ?= " \ 9 /home/jiahongxu/yocto/poky/meta \ 10 /home/jiahongxu/yocto/poky/meta-yocto \ 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ 12 /home/jiahongxu/yocto/poky/meta-intel \ 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \3, build image
bitbake core-image-sato4, load image to emenlow
Test Case TC-2927: boot and install from usb5, open a terminal/ssh of e-menlow
Test Case TC-2955: remote access by ssh6, make exfat filesystem on the testing usb storage
1) plug usb stick into e-menlow
2) execute `mkfs.exfat/dev/sdc1'7, test usb stick with exfat filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files8, make ntfs filesystem on the testing usb storage
1) plug usb stick into e-menlow, if mounted, invoke `umount/dev/sdc1' first.
2) execute `mkfs.ntfs -f/dev/sdc1'9, test usb stick with ntfs filesystem is accessible Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files*Expected Results:
1, build image success2, make exfat filesystem success
root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 mkexfatfs 1.0.1 Creating... done. Flushing... done. File system created successfully.3, make ntfs filesystem success
root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 Cluster size has been automatically set to 4096 bytes. Creating NTFS volume structures. mkntfs completed successfully. Have a nice day.4, While the usb's filesystem type is exfat or ntfs, system can mount plugged usb automatically, read files from usb, write files to usb and unmout usb automatically.
[YOCTO #4178]
The following changes since commit
350c36fcd97e8ef223b91e548d39c346c1c4cb29:bitbake: test/fetch: Allow the conditional network tests to work
under python 2.6 (2013-05-17 12:42:08 +0300)are available in the git repository at:
git://git.pokylinux.org/poky-contribhongxu/support-fusehttp://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuse
Hongxu Jia (4):
fuse: import recipe from meta-oe ntfs-3g-ntfsprogs:import and update recipe from meta-oe
fuse-exfat: add version 1.0.1
exfat-utils: add version 1.0.1meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++
meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++
meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch| 20 +++++++
.../fuse/fuse-2.9.2/gold-unversioned-symbol.patch| 60
++++++++++++++++++++meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ 6 files changed, 206 insertions(+) create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb create mode 100644Quoted 2 lines
meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
Quoted 2 lines
Without trying to be difficult, is oe-core really the place to support and spend effort ensuring NTFS/exFAT formatted drives are supported?
The basis of this work comes from pretty much all SD/MicroSD cards, most consumer USB hard disks, etc being preformatted as NTFS/exFAT. When building a consumer device the designers often want to just use FUSE out of the box so they don't have to work on adding the functionality themselves.
Quoted 8 lines
Quoted 5 lines
meta-oe is often times too much stuff in one bundle to just included in a project. The developers I work with prefer a smaller load of packages, primarily oe-core + whatever they need. It makes it easier to support and easier to prevent problems from being introduced by feature creep.
If there are issues using meta-oe for a few recipes, we need to identify these issues and fix them.
The issue isn't that it's a few bad recipes, the issue is that meta-oe is a collection of software that doesn't fit anywhere else. (I'm speaking specifically of meta-oe, -not- meta-openembedded which has multiple layers in it.)
It's easy for me to justify meta-gnome, if I need gnome.. meta-multimedia, if I need multimedia, etc.. but meta-oe has no single purpose, it's just the place where stuff is put when it doesn't fit anywhere else -- or someone is experimenting with new code.
It has 413 recipes (and 2 bbappends). Of the 413, likely many of those should really be in one of the other meta-openembedded layers (or even other project layers). But my customers are not willing to bring in 413 packages just for '1' package they might need out of the set.
(Similarly, we don't just "bring in" meta-openembedded either.. we break out the layers so only the ones we're willing to support, and our customers need are provided to them.) There is no such thing as an "unsupported" package when you are a commercial vendor.
Quoted 2 lines
If we do not advocate for the layer model, we risk creeping slowly back to the monolithic OE of days gone by.
It's not the layer model that is the issue, it's that meta-oe has no single purpose other then to house things that aren't somewhere else.
What I (speaking as a vendor and my customer advocate) want is oe-core to contain the base software that most devices may need. Then individual layers to add capabilities above and beyond that. (Capabilities may be things like BSPs, networking, multimedia, gnome, kde, distributions, etc.)
Quoted 22 lines
Philip
Quoted 20 lines
Quoted 3 lines
Could these improvements not stay in meta-oe? I don't really see support for essentially propriety filesystems as a core feature of a Linux build.
Yes they could, but then it forces more people to copy the recipes out of meta-oe.
I myself am mixed on if fuse belongs on oe-core or not. I can see the argument both ways on including it or rejecting it. However, I'm getting more and more commercial requests for FUSE to be part of the main system.
Quoted 2 lines
Shout up if I'm talking nonsense, just my 2p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 9 lines · Mark Hatle
It has 413 recipes (and 2 bbappends). Of the 413, likely many of those should really be in one of the other meta-openembedded layers (or even other project layers). But my customers are not willing to bring in 413 packages just for '1' package they might need out of the set.
(Similarly, we don't just "bring in" meta-openembedded either.. we break out the layers so only the ones we're willing to support, and our customers need are provided to them.) There is no such thing as an "unsupported" package when you are a commercial vendor.
I'm not entirely sure what you mean by "bring in" in this context or what the underlying rationale for your reluctance is. But some general comments:
It's entirely possible to have a copy of meta-oe on hand and only include a subset of the recipes in the parse. You can do that either by adding the layer and then BBMASKing out everything you don't want, or by not adding the layer as such but just admit individual recipes by adding them to BBFILES specifically. Either of those approaches would avoid the risk of accidentally introducing dependencies on recipes from meta-oe without realising that this is what you are doing.
Also, I think the toxicity of meta-oe nowadays is much less than it used to be (thanks mostly to excellent work by Paul in cleaning up the .bbappends and overlapping recipes) and, as far as I know, the act of including meta-oe in your layer list no longer leads to the sort of random changes to recipe versions and behaviour that you might have gotten burned by in the past. So if your previous experience is from some time ago then you might want to give it another try.
p.
Quoted 6 lines · Phil Blundell
Quoted 5 lines · Mark Hatle
It has 413 recipes (and 2 bbappends). Of the 413, likely many of those should really be in one of the other meta-openembedded layers (or even other project layers). But my customers are not willing to bring in 413 packages just for '1' package they might need out of the set.
Quoted 8 lines
Quoted 4 lines
(Similarly, we don't just "bring in" meta-openembedded either.. we break out the layers so only the ones we're willing to support, and our customers need are provided to them.) There is no such thing as an "unsupported" package when you are a commercial vendor.
I'm not entirely sure what you mean by "bring in" in this context or what the underlying rationale for your reluctance is. But some general comments:
Support and testing.. if the recipe is there we have to support it, if we don't ship it to our customers -- they are free to source it themselves, but it's clear that we didn't test and don't support it.
We provide it, customers expect us to support it. We're not willing to support meta-oe due to the number of recipes in it. oe-core, meta-yocto, meta-networking, meta-selinux, meta-webserver, and others we do use, test and provide to our customer.
Quoted 10 lines
It's entirely possible to have a copy of meta-oe on hand and only include a subset of the recipes in the parse. You can do that either by adding the layer and then BBMASKing out everything you don't want, or by not adding the layer as such but just admit individual recipes by adding them to BBFILES specifically. Either of those approaches would avoid the risk of accidentally introducing dependencies on recipes from meta-oe without realising that this is what you are doing.
Also, I think the toxicity of meta-oe nowadays is much less than it used to be (thanks mostly to excellent work by Paul in cleaning up
I agree, it's significantly better now. I do use meta-oe from time to time on personal projects...
Quoted 9 lines
the .bbappends and overlapping recipes) and, as far as I know, the act of including meta-oe in your layer list no longer leads to the sort of random changes to recipe versions and behaviour that you might have gotten burned by in the past. So if your previous experience is from some time ago then you might want to give it another try.
p.
Quoted 22 lines · Mark Hatle
Quoted 17 lines · Phil Blundell
Quoted 8 lines · Mark Hatle
It has 413 recipes (and 2 bbappends). Of the 413, likely many of those should
really be in one of the other meta-openembedded layers (or even other project
layers). But my customers are not willing to bring in 413 packages just for '1'
package they might need out of the set.Quoted 7 lines
(Similarly, we don't just "bring in" meta-openembedded either.. we break out the
layers so only the ones we're willing to support, and our customers need are
provided to them.) There is no such thing as an "unsupported" package when you
are a commercial vendor.Quoted 3 lines
I'm not entirely sure what you mean by "bring in" in this context or what the underlying rationale for your reluctance is. But some general comments:
Quoted 8 lines
Support and testing.. if the recipe is there we have to support it, if we don't ship it to our customers -- they are free to source it themselves, but it's clear that we didn't test and don't support it.
We provide it, customers expect us to support it. We're not willing to support meta-oe due to the number of recipes in it. oe-core, meta-yocto, meta-networking, meta-selinux, meta-webserver, and others we do use, test and provide to our customer.
Does this mean we should look at splitting meta-oe into more layers? Or is this issue unique to Wind River?
At some point, the layer dependencies get out of hand.
Philip
Quoted 26 lines
Quoted 11 lines
It's entirely possible to have a copy of meta-oe on hand and only include a subset of the recipes in the parse. You can do that either by adding the layer and then BBMASKing out everything you don't want, or by not adding the layer as such but just admit individual recipes by adding them to BBFILES specifically. Either of those approaches would avoid the risk of accidentally introducing dependencies on recipes from meta-oe without realising that this is what you are doing.
Also, I think the toxicity of meta-oe nowadays is much less than it used to be (thanks mostly to excellent work by Paul in cleaning up
I agree, it's significantly better now. I do use meta-oe from time to time on personal projects...
Quoted 9 lines
the .bbappends and overlapping recipes) and, as far as I know, the act of including meta-oe in your layer list no longer leads to the sort of random changes to recipe versions and behaviour that you might have gotten burned by in the past. So if your previous experience is from some time ago then you might want to give it another try.
p.
Quoted 27 lines · Philip Balister
Quoted 26 lines · Mark Hatle
Quoted 17 lines · Phil Blundell
Quoted 8 lines · Mark Hatle
It has 413 recipes (and 2 bbappends). Of the 413, likely many of those should
really be in one of the other meta-openembedded layers (or even other project
layers). But my customers are not willing to bring in 413 packages just for '1'
package they might need out of the set.Quoted 7 lines
(Similarly, we don't just "bring in" meta-openembedded either.. we break out the
layers so only the ones we're willing to support, and our customers need are
provided to them.) There is no such thing as an "unsupported" package when you
are a commercial vendor.Quoted 3 lines
I'm not entirely sure what you mean by "bring in" in this context or what the underlying rationale for your reluctance is. But some general comments:
Support and testing.. if the recipe is there we have to support it, if we don't ship it to our customers -- they are free to source it themselves, but it's clear that we didn't test and don't support it.
Quoted 7 lines
Quoted 4 lines
We provide it, customers expect us to support it. We're not willing to support meta-oe due to the number of recipes in it. oe-core, meta-yocto, meta-networking, meta-selinux, meta-webserver, and others we do use, test and provide to our customer.
Does this mean we should look at splitting meta-oe into more layers? Or is this issue unique to Wind River?
I think there is merit in looking at the contents of meta-oe over time and splitting them up into functional units. However, at this point I don't have any direct suggestions as to what those units would be.
Quoted 1 line
At some point, the layer dependencies get out of hand.
Yes they do. The number of layers and contents of them also have to be reevaluated over time. What makes sense for one release may drastically change in the future and we have to be willing to adapt to the changing configurations.
I think for the most part the sublayers within meta-openembedded are at
roughly the right level. It's the general "meta-oe" that is the issue for us. (Too many things we're not willing to support.)
--Mark
Quoted 28 lines
Philip
Quoted 26 lines
Quoted 11 lines
It's entirely possible to have a copy of meta-oe on hand and only include a subset of the recipes in the parse. You can do that either by adding the layer and then BBMASKing out everything you don't want, or by not adding the layer as such but just admit individual recipes by adding them to BBFILES specifically. Either of those approaches would avoid the risk of accidentally introducing dependencies on recipes from meta-oe without realising that this is what you are doing.
Also, I think the toxicity of meta-oe nowadays is much less than it used to be (thanks mostly to excellent work by Paul in cleaning up
I agree, it's significantly better now. I do use meta-oe from time to time on personal projects...
Quoted 9 lines
the .bbappends and overlapping recipes) and, as far as I know, the act of including meta-oe in your layer list no longer leads to the sort of random changes to recipe versions and behaviour that you might have gotten burned by in the past. So if your previous experience is from some time ago then you might want to give it another try.
p.
Quoted 1 line · Mark Hatle
The issue isn't that it's a few bad recipes, the issue is that meta-oe is a collection of software that doesn't fit anywhere else. (I'm speaking specifically of meta-oe, -not- meta-openembedded which has multiple layers in it.)
OK I see that you are not supporting meta-oe in your commercial product but are in need of bits and pieces from it I would suggest to poach the recipes and keep them in your own supported layer if you do not wish to support meta-oe and It would be nice if you fed back any bug fixes or changes.
Quoted 7 lines · Khem Raj
Quoted 1 line · Mark Hatle
The issue isn't that it's a few bad recipes, the issue is that meta-oe is a collection of software that doesn't fit anywhere else. (I'm speaking specifically of meta-oe, -not- meta-openembedded which has multiple layers in it.)
OK I see that you are not supporting meta-oe in your commercial product but are in need of bits and pieces from it I would suggest to poach the recipes and keep them in your own supported layer if you do not wish to support meta-oe and It would be nice if you fed back any bug fixes or changes.
Just to be clear, this is exactly what we are doing, and intend to do. Pick pieces as needed from meta-oe, submit fixes/uprevs back to meta-oe for those pieces.
If we see a more general need we will submit them to oe-core as well, if they're not accepted, then they go back to meta-oe.
--Mark