Re: [yocto] [meta-fsl-ppc 02/16] fsl-image-minimal: IMAGE_FSTYPES add jffs2
Yes, jffs2 is required when the rootfs is loaded from NAND flash. Best Regards, Zhenhua > -Original Message- > From: McClintock Matthew-B29882 > Sent: Thursday, September 13, 2012 10:51 AM > To: Luo Zhenhua-B19537 > Cc: McClintock Matthew-B29882; yocto@yoctoproject.org > Subject: Re: [yocto] [meta-fsl-ppc 02/16] fsl-image-minimal: > IMAGE_FSTYPES add jffs2 > > On Wed, Sep 12, 2012 at 9:26 PM, Luo Zhenhua-B19537 > wrote: > > The targets with NAND flash need jffs2 rootfs, e.g. mpc8536ds, > > mpc8572ds, p1020utm, pp1020rdb, p1021rdb, p1022ds, p1024rdb p1025rdb > > I think other's have NAND flash too, they don't need these? > > -M > > > > > > > Best Regards, > > > > Zhenhua > > > > > >> -Original Message- > >> From: McClintock Matthew-B29882 > >> Sent: Thursday, September 13, 2012 5:53 AM > >> To: Luo Zhenhua-B19537 > >> Cc: yocto@yoctoproject.org > >> Subject: Re: [yocto] [meta-fsl-ppc 02/16] fsl-image-minimal: > >> IMAGE_FSTYPES add jffs2 > >> > >> On Wed, Sep 12, 2012 at 2:06 AM, wrote: > >> > From: Ting Liu > >> > > >> > Signed-off-by: Ting Liu > >> > --- > >> > images/fsl-image-minimal.bb |2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > >> > diff --git a/images/fsl-image-minimal.bb > >> > b/images/fsl-image-minimal.bb index b8d3c77..f3d1ad4 100644 > >> > --- a/images/fsl-image-minimal.bb > >> > +++ b/images/fsl-image-minimal.bb > >> > @@ -13,4 +13,4 @@ IMAGE_ROOTFS_SIZE = "8192" > >> > # remove not needed ipkg informations ROOTFS_POSTPROCESS_COMMAND > >> > += "remove_packaging_data_files ; " > >> > > >> > -IMAGE_FSTYPES = "tar.gz ext2.gz.u-boot" > >> > +IMAGE_FSTYPES = "tar.gz ext2.gz.u-boot jffs2" > >> > >> Just to confirm, all boards will use the jffs2 image? > >> > >> -M > >> > >> > -- > >> > 1.7.9.5 > >> > > >> > > >> > ___ > >> > yocto mailing list > >> > yocto@yoctoproject.org > >> > https://lists.yoctoproject.org/listinfo/yocto > > > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-baryon][PATCH 2/2] proftpd: update package to 1.3.4b
Hi Kevin,
On Monday 10 September 2012 14:50:10 Kevin Strasser wrote:
> The contrib directry now contains its own Makefile which is
> used during installation. It was required to pass DESTDIR through
> when it gets called from the base Makefile.
>
> Signed-off-by: Kevin Strasser
> ---
> recipes-extended/proftpd/files/contrib.patch | 38
> .../{proftpd_1.3.3c.bb => proftpd_1.3.4b.bb} |
> 7 ++--
> 2 files changed, 42 insertions(+), 3 deletions(-)
> create mode 100644 recipes-extended/proftpd/files/contrib.patch
> rename recipes-extended/proftpd/{proftpd_1.3.3c.bb => proftpd_1.3.4b.bb}
> (82%)
>
> diff --git a/recipes-extended/proftpd/files/contrib.patch
> b/recipes-extended/proftpd/files/contrib.patch new file mode 100644
> index 000..76b9a5c
> --- /dev/null
> +++ b/recipes-extended/proftpd/files/contrib.patch
> @@ -0,0 +1,38 @@
> +Upstream-Status: Inappropriate [configuration]
> +
> +Signed-off-by: Kevin Strasser
> +---
> + Makefile.in |2 +-
> + contrib/Makefile.in |6 +++---
> + 2 files changed, 4 insertions(+), 4 deletions(-)
> +
> +diff --git a/Makefile.in b/Makefile.in
> +index 5b2e683..ee72fe1 100644
> +--- a/Makefile.in
> b/Makefile.in
> +@@ -120,7 +120,7 @@ install-modules: $(DESTDIR)$(libexecdir)
> $(DESTDIR)$(sysconfdir) + test -z "$(SHARED_MODULE_OBJS)" -a -z
> "$(SHARED_MODULE_DIRS)" -a -z "$(STATIC_MODULE_DIRS)" || (cd modules/ &&
> $(MAKE) install) +
> + install-utils: $(DESTDIR)$(sbindir) $(DESTDIR)$(bindir)
> +-cd contrib/ && $(MAKE) install-utils
> ++cd contrib/ && $(MAKE) DESTDIR=${DESTDIR} install-utils
> + $(INSTALL_BIN) ftpcount $(DESTDIR)$(bindir)/ftpcount
> + $(INSTALL_BIN) ftpdctl $(DESTDIR)$(bindir)/ftpdctl
> + $(INSTALL_SBIN) ftpscrub $(DESTDIR)$(sbindir)/ftpscrub
> +diff --git a/contrib/Makefile.in b/contrib/Makefile.in
> +index 5bcc038..51d248c 100644
> +--- a/contrib/Makefile.in
> b/contrib/Makefile.in
> +@@ -18,6 +18,6 @@ Makefile: Makefile.in ../config.status
> + cd ../ && ./config.status
> +
> + install-utils:
> +-$(INSTALL) -o $(INSTALL_USER) -g $(INSTALL_GROUP) -m 0755 ftpasswd
> $(DESTDIR)$(bindir)/ftpasswd +- $(INSTALL) -o $(INSTALL_USER) -g
> $(INSTALL_GROUP) -m 0755 ftpmail $(DESTDIR)$(bindir)/ftpmail +-
> $(INSTALL)
> -o $(INSTALL_USER) -g $(INSTALL_GROUP) -m 0755 ftpquota
> $(DESTDIR)$(bindir)/ftpquota ++ $(INSTALL) -m 0755 ftpasswd
> $(DESTDIR)$(bindir)/ftpasswd
> ++$(INSTALL) -m 0755 ftpmail $(DESTDIR)$(bindir)/ftpmail
> ++$(INSTALL) -m 0755 ftpquota $(DESTDIR)$(bindir)/ftpquota
> +--
> +1.7.9.5
> +
> diff --git a/recipes-extended/proftpd/proftpd_1.3.3c.bb
> b/recipes-extended/proftpd/proftpd_1.3.4b.bb similarity index 82%
> rename from recipes-extended/proftpd/proftpd_1.3.3c.bb
> rename to recipes-extended/proftpd/proftpd_1.3.4b.bb
> index 8de80fc..b7e201b 100644
> --- a/recipes-extended/proftpd/proftpd_1.3.3c.bb
> +++ b/recipes-extended/proftpd/proftpd_1.3.4b.bb
> @@ -2,17 +2,18 @@ DESCRIPTION = "Secure ftp daemon"
> SECTION = "console/network"
>
> LICENSE = "GPLv2+"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=fdedcde17b1ffd967d86c20fe0ac158a"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=fb0d1484d11915fa88a6a7702f1dc184"
A few points:
1) Re contrib.patch - surely it would be valid to pass DESTDIR through for
everyone? If so we should be able to consider sending this patch upstream, in
which case Upstream-Status should be Pending.
2) When LIC_FILES_CHKSUM changes for any reason we need to mention clearly why
in the commit message (even if it is a mundane reason such as the copyright
year changing).
3) Minor - s/directry/directory in the commit message.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Denzil / Cedartrail / EGL/GLES under X
Hi Chris, On 10 September 2012 19:56, Chris Tapp wrote: > I've managed to get to the point where I think EGL is up (no API errors > reported), but if I try anything on the GL side (e.g. glClear to get the > background color) I'm not getting anything showing on the display when I call > eglSwapBuffers(). GL or GLES? GL on Cedar Trail is very limited , you're heavily recommended to use GLES. > I'm not sure how to configure my build to use the cdv-pvr-driver libs rather > than the MESA-dri equivalents either. Both provide libGLESv2, etc., but I > want the cdv-pvr-driver versions in the final image. However, cdv-prv-driver > doesn't seem to have an include directory to use at build time, so MESA needs > to be there as well. Is there a PREFERRED_PROVIDER_virtual/libgl value I can > use? This is a bit of a mess at the moment, and I want to sort it, but it's a complicated mess. Building against mesa-dri shouldn't be a problem as all GL implementations have the same ABI, assuming you can get the cdv-prv-driver package installed and not mesa-dri on your image. Preferred providers only work for built-time dependencies, so assuming that you're having problems with getting mesa-dri out and cdv-prv-driver in the image you'll need to use something like RCONFLICTS and RPROVIDES so that the package system uses cdv-prv-driver instead of mesa-dri. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Adding items to meta-toolchain
I'm sure I saw something regarding this come up recently, but I can't seem to find it so apologies if this has just been answered. What is the proper way of adding things to a meta-toolchain build. For example, I have included in my image libwebsockets as a library which my application dynamically links against. Now at the moment I build my appplication locally against the output from meta-toolchain and a -I to specific the sysroot of my build. However how do I get libwebsockets.so and libwebsockets.h included in a meta-toolchain build so I can cross compile with the library on a host without the build sysroot? Regards, Jack. -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
Hi Trevor, I just briefly tried building it, using gcc-4.5.1, and got build failures too. It looks like it will take some effort to get this up and running with the current version of yocto. I just managed to get powerpc440 soft-float working with gcc-4.5.1 & eglibc-2.13 with a specific commit id for poky and meta-openembedded. Now I have to try and make that legacy gcc-4.5.1 support with with the latest poky and meta-openembedded master branch. Perhaps if you get a Xilinx SP601 board and dive in, you could help get microblaze up and running! Best regards, Elvis ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Denzil / Cedartrail / EGL/GLES under X
Ross, the definition of RPROVIDES is not given in the Yocto project reference manual. Perhaps it should be added to the manual ? Thanks Rahul -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Burton, Ross Sent: Thursday, September 13, 2012 4:04 AM To: Chris Tapp Cc: yocto@yoctoproject.org Project Subject: Re: [yocto] Denzil / Cedartrail / EGL/GLES under X Hi Chris, On 10 September 2012 19:56, Chris Tapp wrote: > I've managed to get to the point where I think EGL is up (no API errors > reported), but if I try anything on the GL side (e.g. glClear to get the > background color) I'm not getting anything showing on the display when I call > eglSwapBuffers(). GL or GLES? GL on Cedar Trail is very limited , you're heavily recommended to use GLES. > I'm not sure how to configure my build to use the cdv-pvr-driver libs rather > than the MESA-dri equivalents either. Both provide libGLESv2, etc., but I > want the cdv-pvr-driver versions in the final image. However, cdv-prv-driver > doesn't seem to have an include directory to use at build time, so MESA needs > to be there as well. Is there a PREFERRED_PROVIDER_virtual/libgl value I can > use? This is a bit of a mess at the moment, and I want to sort it, but it's a complicated mess. Building against mesa-dri shouldn't be a problem as all GL implementations have the same ABI, assuming you can get the cdv-prv-driver package installed and not mesa-dri on your image. Preferred providers only work for built-time dependencies, so assuming that you're having problems with getting mesa-dri out and cdv-prv-driver in the image you'll need to use something like RCONFLICTS and RPROVIDES so that the package system uses cdv-prv-driver instead of mesa-dri. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Denzil / Cedartrail / EGL/GLES under X
On Thursday 13 September 2012 16:37:59 Saxena, Rahul wrote: > Ross, the definition of RPROVIDES is not given in the Yocto project > reference manual. Perhaps it should be added to the manual ? Good catch - yes, it should. Scott R - I can send you some info. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
On Thu, Sep 13, 2012 at 9:36 AM, Elvis Dowson wrote: > >I just briefly tried building it, using gcc-4.5.1, and got > build failures too. It looks like it will take some effort to get this up and > running with the current version of yocto. I just managed to get powerpc440 > soft-float working with gcc-4.5.1 & eglibc-2.13 with a specific commit id for > poky and meta-openembedded. Now I have to try and make that legacy gcc-4.5.1 > support with with the latest poky and meta-openembedded master branch. > Perhaps if you get a Xilinx SP601 board and dive in, you could help get > microblaze up and running! we always like good problem reports so if you find anything wrong with core metadata we would be more than happy to help in fixing it. Elvis, btw. I have done a patch for gcc 4.7 in master which should help fix ppc/soft-float I dont know if it will help you but you could try that out. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
Hi guys,
Thanks for all the support so far. Currently I'm still trying to make
some headway with the Xilinx-supplied external toolchain (gcc-4.1.2).
When I saw the original errors I was having configuring libtool-cross
I was concerned about the "-V must be at start" and "unrecognized
option -qversion" problems I was having. Searching online wasn't
helping very much. But then Khem correctly pointed out (indirectly)
that those weren't any problem. libtool-cross's ./configure script was
simply examining the compiler tools to see if those options were okay
or not. The real problem (as Khem pointed out) was with the -m32 and
-mcpu= options.
Looking at an older version of
meta-xilinx/conf/machine/include/tune-microblazeel.inc (which was
committed by Adrian) showed that the -mcpu= option used to be:
-mcpu=v8.10.a
instead of:
-mcpu=v8.10a
So with the following patch to
meta-xilinx/conf/machine/include/tune-microblazeel.inc
---
diff --git a/conf/machine/include/tune-microblazeel.inc
b/conf/machine/include/tune-microblazeel.inc
index a0cf7b7..1dc1bf3 100644
--- a/conf/machine/include/tune-microblazeel.inc
+++ b/conf/machine/include/tune-microblazeel.inc
@@ -4,13 +4,13 @@ DEFAULTTUNE ?= "microblazeel"
require conf/machine/include/microblaze/arch-microblaze.inc
TUNEVALID[microblazeel] = "Enable microblaze endian little optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "microblazeel",
"-mcpu=v8.10a", "", d)}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "microblazeel",
"-mcpu=v8.10.a", "", d)}"
TUNE_PKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "microblazeel",
"microblazeel", "microblazeel", d)}"
-TARGET_FPU = "soft"
+#TARGET_FPU = "soft"
AVAILTUNES += "microblazeel"
-TUNE_FEATURES_tune-microblazeel = "m32 microblazeel"
+TUNE_FEATURES_tune-microblazeel = "microblazeel"
PACKAGE_EXTRA_ARCHS_tune-microblazeel = "microblazeel"
#MACHINEOVERRIDES .= "microblaze"
---
and the following patch to
meta-xilinx/conf/machine/include/microblaze/arch-microblaze.inc
---
diff --git a/conf/machine/include/microblaze/arch-microblaze.inc
b/conf/machine/include/microblaze/arch-microblaze.inc
index 485defa..f76f30e 100644
--- a/conf/machine/include/microblaze/arch-microblaze.inc
+++ b/conf/machine/include/microblaze/arch-microblaze.inc
@@ -2,16 +2,16 @@
DEFAULTTUNE ?= "microblaze"
TUNEVALID[m32] = "Microblaze ELF32 standard ABI"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
-TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
"microblaze", "", d)}"
+#TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "", "microblaze", "", d)}"
TUNEVALID[fpu-soft] = "Use software FPU."
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"-msoft-float", "", d)}"
-TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"soft", "", d)}"
+#TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"-msoft-float", "", d)}"
+#TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"soft", "", d)}"
TUNE_PKGARCH ?= "${TUNE_ARCH}"
AVAILTUNES += "microblaze"
-TUNE_FEATURES_tune-microblaze ?= "m32 fpu-soft"
+#TUNE_FEATURES_tune-microblaze ?= "m32 fpu-soft"
PACKAGE_EXTRA_ARCHS_tune-microblaze = "microblaze"
---
Basically:
- remove any references to TARGET_FPU/fpu-soft/soft/FPU/...
- remove any references to m32/32/...
- change v8.10a to v8.10.a
I was able to get libtool-cross to configure.
While building libtool-cross, however, I encountered another problem,
something to do with "--hash-style=gnu" not supported. This problem I
was able to fix by adding the following line to my conf/local.conf:
TARGET_LINK_HASH_STYLE = ""
With this last change I was able to get past libtool-cross which built
just fine.
The build then progresses for quite a while past that but then finally
fails trying to configure libffi:
error: "libffi has not been ported to microblaze-unknown-linux-gnu."
So now I'm basically digging through the various layers to investigate
making my own really small "distribution". If all I really want to do
is get to a command-line, isn't all I _really_ need just a kernel,
busybox, and a small set of configuration files?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
PS simply BBMASK'ing out libffi doesn't help as too many things... require(?) it (depend on it, rdepend on it...?) ERROR: Nothing PROVIDES 'libffi' (but /home/trevor/devel/yocto/gitrepo-method/poky/meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb DEPENDS on or otherwise requires it) NOTE: Runtime target 'udev' is unbuildable, removing... Missing or unbuildable dependency chain was: ['udev', 'glib-2.0', 'libffi'] NOTE: Runtime target 'packagegroup-core-boot' is unbuildable, removing... Missing or unbuildable dependency chain was: ['packagegroup-core-boot', 'udev', 'glib-2.0', 'libffi'] ERROR: Required build target 'core-image-minimal' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-minimal', 'packagegroup-core-boot', 'udev', 'glib-2.0', 'libffi'] ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-baryon][PATCH 2/2] proftpd: update package to 1.3.4b
Thanks, Paul. I've made those changes and added the bbappend for the new
kernel.
The updates are available in the git repository at:
git://git.yoctoproject.org/poky-contrib strassek/baryon-updates
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=strassek/baryon-updates
-Kevin
> Hi Kevin,
>
> On Monday 10 September 2012 14:50:10 Kevin Strasser wrote:
>> The contrib directry now contains its own Makefile which is
>> used during installation. It was required to pass DESTDIR through
>> when it gets called from the base Makefile.
>>
>> Signed-off-by: Kevin Strasser
>> ---
>> recipes-extended/proftpd/files/contrib.patch | 38
>> .../{proftpd_1.3.3c.bb => proftpd_1.3.4b.bb}
>> |
>> 7 ++--
>> 2 files changed, 42 insertions(+), 3 deletions(-)
>> create mode 100644 recipes-extended/proftpd/files/contrib.patch
>> rename recipes-extended/proftpd/{proftpd_1.3.3c.bb =>
>> proftpd_1.3.4b.bb}
>> (82%)
>>
>> diff --git a/recipes-extended/proftpd/files/contrib.patch
>> b/recipes-extended/proftpd/files/contrib.patch new file mode 100644
>> index 000..76b9a5c
>> --- /dev/null
>> +++ b/recipes-extended/proftpd/files/contrib.patch
>> @@ -0,0 +1,38 @@
>> +Upstream-Status: Inappropriate [configuration]
>> +
>> +Signed-off-by: Kevin Strasser
>> +---
>> + Makefile.in |2 +-
>> + contrib/Makefile.in |6 +++---
>> + 2 files changed, 4 insertions(+), 4 deletions(-)
>> +
>> +diff --git a/Makefile.in b/Makefile.in
>> +index 5b2e683..ee72fe1 100644
>> +--- a/Makefile.in
>> b/Makefile.in
>> +@@ -120,7 +120,7 @@ install-modules: $(DESTDIR)$(libexecdir)
>> $(DESTDIR)$(sysconfdir) +test -z "$(SHARED_MODULE_OBJS)" -a -z
>> "$(SHARED_MODULE_DIRS)" -a -z "$(STATIC_MODULE_DIRS)" || (cd modules/ &&
>> $(MAKE) install) +
>> + install-utils: $(DESTDIR)$(sbindir) $(DESTDIR)$(bindir)
>> +- cd contrib/ && $(MAKE) install-utils
>> ++ cd contrib/ && $(MAKE) DESTDIR=${DESTDIR} install-utils
>> +$(INSTALL_BIN) ftpcount $(DESTDIR)$(bindir)/ftpcount
>> +$(INSTALL_BIN) ftpdctl $(DESTDIR)$(bindir)/ftpdctl
>> +$(INSTALL_SBIN) ftpscrub $(DESTDIR)$(sbindir)/ftpscrub
>> +diff --git a/contrib/Makefile.in b/contrib/Makefile.in
>> +index 5bcc038..51d248c 100644
>> +--- a/contrib/Makefile.in
>> b/contrib/Makefile.in
>> +@@ -18,6 +18,6 @@ Makefile: Makefile.in ../config.status
>> +cd ../ && ./config.status
>> +
>> + install-utils:
>> +- $(INSTALL) -o $(INSTALL_USER) -g $(INSTALL_GROUP) -m 0755 ftpasswd
>> $(DESTDIR)$(bindir)/ftpasswd +- $(INSTALL) -o $(INSTALL_USER) -g
>> $(INSTALL_GROUP) -m 0755 ftpmail $(DESTDIR)$(bindir)/ftpmail
>> +- $(INSTALL)
>> -o $(INSTALL_USER) -g $(INSTALL_GROUP) -m 0755 ftpquota
>> $(DESTDIR)$(bindir)/ftpquota ++ $(INSTALL) -m 0755 ftpasswd
>> $(DESTDIR)$(bindir)/ftpasswd
>> ++ $(INSTALL) -m 0755 ftpmail $(DESTDIR)$(bindir)/ftpmail
>> ++ $(INSTALL) -m 0755 ftpquota $(DESTDIR)$(bindir)/ftpquota
>> +--
>> +1.7.9.5
>> +
>> diff --git a/recipes-extended/proftpd/proftpd_1.3.3c.bb
>> b/recipes-extended/proftpd/proftpd_1.3.4b.bb similarity index 82%
>> rename from recipes-extended/proftpd/proftpd_1.3.3c.bb
>> rename to recipes-extended/proftpd/proftpd_1.3.4b.bb
>> index 8de80fc..b7e201b 100644
>> --- a/recipes-extended/proftpd/proftpd_1.3.3c.bb
>> +++ b/recipes-extended/proftpd/proftpd_1.3.4b.bb
>> @@ -2,17 +2,18 @@ DESCRIPTION = "Secure ftp daemon"
>> SECTION = "console/network"
>>
>> LICENSE = "GPLv2+"
>> -LIC_FILES_CHKSUM =
>> "file://COPYING;md5=fdedcde17b1ffd967d86c20fe0ac158a"
>> +LIC_FILES_CHKSUM =
>> "file://COPYING;md5=fb0d1484d11915fa88a6a7702f1dc184"
>
> A few points:
>
> 1) Re contrib.patch - surely it would be valid to pass DESTDIR through for
> everyone? If so we should be able to consider sending this patch upstream,
> in
> which case Upstream-Status should be Pending.
>
> 2) When LIC_FILES_CHKSUM changes for any reason we need to mention clearly
> why
> in the commit message (even if it is a mundane reason such as the
> copyright
> year changing).
>
> 3) Minor - s/directry/directory in the commit message.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Denzil / Cedartrail / EGL/GLES under X
Hi Ross, On 13 Sep 2012, at 12:03, Burton, Ross wrote: > On 10 September 2012 19:56, Chris Tapp wrote: >> I've managed to get to the point where I think EGL is up (no API errors >> reported), but if I try anything on the GL side (e.g. glClear to get the >> background color) I'm not getting anything showing on the display when I >> call eglSwapBuffers(). > > GL or GLES? GL on Cedar Trail is very limited , you're heavily > recommended to use GLES. Thanks. That's actually where I'm headed - glClear() was the first step... I've actually managed to get things working now. Not too sure what I did, but I __think__ it was something to do with the rendering context - I may not have been specifying a GLES2 surface when I was using it. GLES is new to me (GL background), but my copy of the "OpenGL ES 2.0 Programming Guide" arrived today, so I should be on the way ;-) >> I'm not sure how to configure my build to use the cdv-pvr-driver libs rather >> than the MESA-dri equivalents either. Both provide libGLESv2, etc., but I >> want the cdv-pvr-driver versions in the final image. However, cdv-prv-driver >> doesn't seem to have an include directory to use at build time, so MESA >> needs to be there as well. Is there a PREFERRED_PROVIDER_virtual/libgl value >> I can use? > > This is a bit of a mess at the moment, and I want to sort it, but it's > a complicated mess. > > Building against mesa-dri shouldn't be a problem as all GL > implementations have the same ABI, assuming you can get the > cdv-prv-driver package installed and not mesa-dri on your image. > Preferred providers only work for built-time dependencies, so assuming > that you're having problems with getting mesa-dri out and > cdv-prv-driver in the image you'll need to use something like > RCONFLICTS and RPROVIDES so that the package system uses > cdv-prv-driver instead of mesa-dri. It seems to be putting the correct ones in the image as things are working with the simple tests I've got going so far. MD5sum on the libs confirms they are from cdv-prv-driver. No idea how they get used in preference, as I've not used any 'magic' yet! Thanks for the help :-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
Trevor Woerner wrote: >PS simply BBMASK'ing out libffi doesn't help as too many things... >require(?) it (depend on it, rdepend on it...?) You can try to make libffi as a package group in glib20 if possible other option would be to use something like mdev instead of udev > >ERROR: Nothing PROVIDES 'libffi' (but >/home/trevor/devel/yocto/gitrepo-method/poky/meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb >DEPENDS on or otherwise requires it) >NOTE: Runtime target 'udev' is unbuildable, removing... >Missing or unbuildable dependency chain was: ['udev', 'glib-2.0', >'libffi'] >NOTE: Runtime target 'packagegroup-core-boot' is unbuildable, >removing... >Missing or unbuildable dependency chain was: >['packagegroup-core-boot', 'udev', 'glib-2.0', 'libffi'] >ERROR: Required build target 'core-image-minimal' has no buildable >providers. >Missing or unbuildable dependency chain was: ['core-image-minimal', >'packagegroup-core-boot', 'udev', 'glib-2.0', 'libffi'] ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] Fix X issue on crownbay
Ross, Looking at the bug, I am trying with the latest commits now. When it failed, I looked at the build area, and found that the xorg-xserver package was built fine. I think the issue happened in the with rootfs generation. I haven't found why it was not included in the rootfs. From the bug I thought the issue got resolved in the latest tree HEAD, so I am going to test the latest head on few BSPs, and will dig further if I encounter the issue again. Nitin > -Original Message- > From: Burton, Ross [mailto:ross.bur...@intel.com] > Sent: Wednesday, September 12, 2012 1:43 PM > To: Kamble, Nitin A > Cc: Zanussi, Tom; Hart, Darren; yocto@yoctoproject.org > Subject: Re: [yocto] [PATCH 0/1] Fix X issue on crownbay > > On 12 September 2012 21:14, Kamble, Nitin A > wrote: > > FYI While testing on the fishriver platform, I also find that there is no X > > log, > and looking further found out that xorg executable is not on the image. I > think the same thing is also happening on crownbay. > > There have been transient reports of Xorg missing in the qemu images too -- > transient because the reporter said that the next day's autobuilt image had > the package installed again. Very odd. > > In the broken systems you say there is no Xorg binary. Can you confirm that > there is no xserver-xorg package too? Can you inspect the build and see if > this failed, or if there is some machine configuration disaster which means it > doesn't think it needs to install an xserver? > > Ross > > FWIW, my qemuarm image from earlier today works. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] Fix X issue on crownbay
Thanks Kishore for reporting it. I am trying to get to bottom of this by today or tomorrow. Thanks, Nitin > -Original Message- > From: Bodke, Kishore K > Sent: Wednesday, September 12, 2012 1:57 PM > To: Kamble, Nitin A; Zanussi, Tom > Cc: Hart, Darren; yocto@yoctoproject.org > Subject: RE: [PATCH 0/1] Fix X issue on crownbay > > > > >-Original Message- > >From: yocto-boun...@yoctoproject.org [mailto:yocto- > >boun...@yoctoproject.org] On Behalf Of Kamble, Nitin A > >Sent: Wednesday, September 12, 2012 1:14 PM > >To: Zanussi, Tom > >Cc: Hart, Darren; yocto@yoctoproject.org > >Subject: Re: [yocto] [PATCH 0/1] Fix X issue on crownbay > > > >FYI While testing on the fishriver platform, I also find that there is > >no X log, and looking further found out that xorg executable is not on > >the image. I think the same thing is also happening on crownbay. > > FYI.. I also see the similar issue for Romley. > There is no Xlog and X does not comes up. > > Thanks > Kishore. > > > > >Nitin > > > > > > > >> -Original Message- > >> From: Kamble, Nitin A > >> Sent: Wednesday, September 12, 2012 9:18 AM > >> To: Zanussi, Tom > >> Cc: Hart, Darren; yocto@yoctoproject.org > >> Subject: RE: [PATCH 0/1] Fix X issue on crownbay > >> > >> Hi Tom, > >> Thanks for looking into the matter. I will try to reproduce the > >> issue you are seeing with master. And send another pull request with all > the fixes. > >> > >> Regards, > >> Nitin > >> > >> > >> > -Original Message- > >> > From: Zanussi, Tom > >> > Sent: Monday, September 10, 2012 4:34 PM > >> > To: Kamble, Nitin A > >> > Cc: Hart, Darren; yocto@yoctoproject.org > >> > Subject: Re: [PATCH 0/1] Fix X issue on crownbay > >> > > >> > On Wed, 2012-09-05 at 17:59 -0700, nitin.a.kam...@intel.com wrote: > >> > > From: Nitin A Kamble > >> > > > >> > > The following changes since commit > >> > 66b516f3d3a287eecbf8804b2221bfc27e36db63: > >> > > > >> > > README: add info explaining meta-tlk layer purpose (2012-09-06 > >> > > 10:36:02 -0500) > >> > > > >> > > are available in the git repository at: > >> > > git://git.yoctoproject.org/meta-intel-contrib nitin/work > >> > > > >> > > http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=ni > >> > > tin > >> > > /w > >> > > ork > >> > > > >> > > >> > I built and tried this, but it still didn't boot into X, and now > >> > there's not even an Xorg.log to look at: > >> > > >> > root@crownbay:/var/log# ls -al > >> > drwxr-xr-x2 root root80 Sep 10 20:15 . > >> > drwxrwxrwt7 root root 140 Jan 6 2009 .. > >> > -rw-r--r--1 root root 78429 Sep 10 20:17 messages > >> > -rw-rw-r--1 root root 4224 Sep 10 20:17 wtmp > >> > > >> > I assume this is a different X problem related to recent changes in > mater. > >> > Can you update the bug report with the commits that you tested with > >> > so I can verify that your patch at least works? > >> > > >> > Thanks, > >> > > >> > Tom > >> > > >> > > >> > > >> > > Nitin A Kamble (1): > >> > > emgd-driver-bin: Fix package naming issue > >> > > > >> > > .../xorg-xserver/emgd-driver-bin_1.14.bb |8 +++- > >> > > 1 files changed, 7 insertions(+), 1 deletions(-) > >> > > > >> > > > > >___ > >yocto mailing list > >yocto@yoctoproject.org > >https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
Hi Trevor, On Sep 13, 2012, at 10:17 PM, Trevor Woerner wrote: > > ~$300 for the SP601 is certainly not too onerous. If I start to see > more success with yocto I will definitely consider it. > > Other options include: > - qemu (maybe getting yocto to run/build a microblaze qemu image would be > nice) > - the spartan-6 version of the papilio board (which is either going to > be a papilio plus or the papilio pro) > > I do have one question though: if I had the SP601, would I be able to > download (for free) an synthesize (using the freely available ISE > tools) a microblaze and/or a PPC soft core? Or would I need to pay for > those components (and if so, how much)? There are two parts of the design suite, ISE (for VHDL and Verilog) development, and XPS (EDK) for re-using the Xilinx IP cores in a project. To edit microblaze projects, you would need an EDK license. The standard webpack only includes a license for the ISE component, and is usually device locked to a particular set of devices, usually the low-end FPGAs. The SP601 comes only with the WebPack software, so hmm no, not suitable for what you want to do. What you really need is the ISE Embedded Edition or System Edition, in order to be able to configure your IP cores using the Xilinx Base System Builder, so that you can design your peripherals around a MicroBlaze (Virtex, Spartan) or ARM (Zynq) processor core. There are no soft PowerPC IP cores, only hard PowerPC IP cores on specific Virtex 4 (PPC405) / 5 (PPC440) FPGA variants, with the FXT designation. Xilinx stopped using PowerPC hard cores with the Virtex 5 series. So, series-6 and series-7 FPGAs don't have PowerPC any more, and the only option was to use a soft core processor like the microblaze. In the specific case of the Zynq series, they have a dual ARM Cortex-A9 hard core processor. I find that the Spartan-6 Embedded Kit (SP605 + ISE Design Suite Embedded Edition) gives you want you want, and the price listed on the website is USD$695. http://www.xilinx.com/products/boards-and-kits/DK-S6-EMBD-G.htm The other option is the Zynq-EPP 7020 platform which includes the base board with the ARM processor, and ISE Design Suite System Edition for USD$895. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1][meta-intel]meta-cedartrail:Cover letter to update PVR graphics driver to v1.0.3 - denzil branch
On Wed, 2012-09-12 at 16:01 -0700, rahul.sax...@intel.com wrote:
> From: Rahul Saxena
>
> This driver update fixes a memory leak bug
>
> Please pull into meta-intel/denzil
Pulled into meta-intel/denzil.
Thanks,
Tom
>
> Signed-off-by: Rahul Saxena
> --
> The following changes since commit 418f6d3936bcd871102042167c699c3773bded3e:
>
> meta-cedartrail: Add video acceleration (2012-09-11 13:58:04 -0500)
>
> are available in the git repository at:
> git://git.pokylinux.org/meta-intel-contrib rsaxena-denzilpvr103r1
>
> http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=rsaxena-denzilpvr103r1
>
> Rahul Saxena (1):
> meta-cedartrail: Update PVR graphics driver to version 1.0.3
>
> meta-cedartrail/README |2 +-
> ...pvr-driver_1.0.2.bb => cdv-pvr-driver_1.0.3.bb} | 52
> ++--
> 2 files changed, 27 insertions(+), 27 deletions(-)
> rename meta-cedartrail/recipes-graphics/xorg-driver/{cdv-pvr-driver_1.0.2.bb
> => cdv-pvr-driver_1.0.3.bb} (81%)
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
