Re: [yocto] Apache Tomcat7 on Yocto 1.8

[Khem Raj]

> On Jul 30, 2015, at 10:07 AM, Anil Kumar TS  
> wrote:
> 
> Hi,
> 
> I added Servlet api file and Java Sserver Page for Apache Tomcat 7, and 
> compiled it. Before that I  added openjdk-7-jre too.
> While creating core-image-base image, I am seeing errors during rootfs  image 
> creation with the following error:
> 
> ERROR: servlet3.0 not found in the base feeds (qemux86 i586 x86 noarch any 
> all).


how is this recipe written, It seems its ending up with empty packages and 
which are then deleted and dependency resolver then finds nothing to depend on
looks inside the build of servlet3.0 and especially packages-split directory 
and see where are all files siphoned to

> 
> I have attached the complete log file.
> 
> Below is the local.conf file, that I am using
> 
> MACHINE ??= "qemux86"
> 
> PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native"
> 
> PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
> PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"
> PREFERRED_VERSION_openjdk-7-jre = "75b13-2.5.4"
> PREFERRED_VERSION_icedtea7-native = "2.1.3"
> PREFERRED_VERSION_servlet3.0 = "7.0.63"
> PREFERRED_VERSION_jsp2.2 = "7.0.63"
> PREFERRED_PROVIDER_openjdk-7-jre = "openjdk-7-jre"
> PREFERRED_PROVIDER_servlet3.0 = "servlet3.0"
> IMAGE_INSTALL_append = " openjdk-7-jre"
> IMAGE_INSTALL_append = " servlet3.0"
> 
> Could anyone please help me regarding  this?
> 
> Thanks and  Regards,
> Anil
> 
> 
> From: yocto-boun...@yoctoproject.org  
> [yocto-boun...@yoctoproject.org ] on 
> behalf of Anil Kumar TS [anil.she...@lnttechservices.com 
> ]
> Sent: Wednesday, July 22, 2015 10:07 AM
> To: yocto@yoctoproject.org 
> Subject: [yocto] Apache Tomcat7 on Yocto 1.8
> 
> Hi,
> 
> I am trying to build and run Apache Tomcat 7 on Yocto 1.8. I have already 
> added meta-java pulled from yocto project source repo and built openjdk7.
> The recipes-core in meta-java contains servlet-api recipe file for tomcat 5.5 
> but not for tomcat7. I tried adding a new servlet-api recipe file. But the 
> manifest file is not being used from tomcat 6 version. And I am facing errors 
> in do_unpackpost().
> Since I am new to this could some one please point me in the right direction 
> as to how to go forward in adding tomcat 7?
> 
> Thanks and Regards,
> Anil
> L&T Technology Services Ltd
> www.LntTechservices.com 
> This Email may contain confidential or privileged information for the 
> intended recipient (s). If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.
> L&T Technology Services Ltd
> www.LntTechservices.com 
> This Email may contain confidential or privileged information for the 
> intended recipient (s). If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.
> L&T Technology Services Ltd
> www.LntTechservices.com 
> This Email may contain confidential or privileged information for the 
> intended recipient (s). If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] userland

[Herve Jourdain]

Hi Khem,

Actually, in the case of raspberrypi, the implementation of gstreamer1.0-omx 
could depend on openmax provided by userland, instead of libomxil by default.
That's one example on the top of my head.
I don't personally use openvg, but I guess it might also be useful, although I 
have no first hand example for that one.

Best regards,

Herve

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: vendredi 7 août 2015 08:15
To: Herve Jourdain 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [meta-raspberrypi] userland

On Thu, Aug 6, 2015 at 10:57 PM, Herve Jourdain  wrote:
> Hi,
>
>
>
> Currently, userland_git.bb PROVIDES virtual/egl and virtual/libgles2.
>
> But “userland” seems to provide many additional components: mmal, 
> vcos, openmaxil, vchiq_arm, bcm_host, WFC, OpenVG
>
>
>
> Wouldn’t it make sense to add additional PROVIDES to handle those as well?


if they are implementation of generic components then sure. openvg and openmax 
might be one of them but if no one is depending on them why bother ?

>
>
>
> I’m thinking about openmaxil, for instance.
>
> Right now for instance, I get it by adding a DEPEND userland to a 
> .bbappend, but I’m considering adding maybe a virtual/openmaxil to 
> userland_git.bb.
>
>
>
> Does it make sense? Any suggestion about that?
>
>
>
> Best regards,
>
>
>
> Herve
>
>
> --
> ___
> 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] libmcrypt not part of the image

[yocto yocto]

I added the meta-openembedded layer to my configuration. I want to have
libmcrypt (in meta-openembedded/meta-oe/recipes-support) on my system:

IMAGE_INSTALL += "libmcrypt"

The library (libmcrypt.so) is actually being built. Everything is located
in "libmcrypt/2.5.8-r0/package/usr", however after flashing the image
libmcrypt is not part of the filesystem.

I tried writing some kind of "libmcrypt_%.bbappend" with

do_install() {
install -m 0755 ${WORKDIR}/package/usr ${D}/
}

However, I get a bitbake error that do_install failed but there is exact
message. Any ideas how to solve this properly?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] libmcrypt not part of the image

[Paul Eggleton]

On Friday 07 August 2015 11:25:40 yocto yocto wrote:
> I added the meta-openembedded layer to my configuration. I want to have
> libmcrypt (in meta-openembedded/meta-oe/recipes-support) on my system:
> 
> IMAGE_INSTALL += "libmcrypt"

Where did you add this exactly?

> The library (libmcrypt.so) is actually being built. Everything is located
> in "libmcrypt/2.5.8-r0/package/usr", however after flashing the image
> libmcrypt is not part of the filesystem.
> 
> I tried writing some kind of "libmcrypt_%.bbappend" with
> 
> do_install() {
> install -m 0755 ${WORKDIR}/package/usr ${D}/
> }
> 
> However, I get a bitbake error that do_install failed but there is exact
> message. Any ideas how to solve this properly?

If the files are under package/ then do_install is already working fine, so 
your 
hack definitely isn't going to help.

When I have problems like this I generally follow this procedure to find the 
issue:

1) Is do_install working? (check "image" subdirectory under the workdir for 
the recipe, which is ${D})

2) Has do_package put the file in the package you think it should be in? (look 
in "packages-split" under the workdir for the recipe; there are subdirectories 
for each package created by the recipe)

3) Is the package really being installed? (check bitbake -e imagename and look 
at the IMAGE_INSTALL value to see if it's really in there, and also look at 
log.do_rootfs for the image - is the package mentioned?)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack

[Javier Martinez Canillas]

Hello Andreas,

Thanks a lot for your feedback.

On 08/06/2015 09:41 AM, Andreas Müller wrote:
> On Thu, Aug 6, 2015 at 8:59 AM, Javier Martinez Canillas
>  wrote:
>> Yes, I in fact was not sure if it should be a distro or machine feature
>> and then decided on the former because there is more than the kernel to
>> make it work like changing mesa configure options. But as mentioned to
>> Andrea Müller, probably we should ship a mesa .bbappend for this in the
>> BSP so I agree that a MACHINE_FEATURE will make more sense.
> Suggestions:
> 
> * Mesa: A simple append with
> 
> PACKAGECONFIG_append_rpi += " gallium"
> GALLIUMDRIVERS_rpi = "vc4"
> 
> would do. If you check mesa.inc in oe-core others (intel) do similar

That sounds good to me.

> (we might have to wait for a more recent mesa expected in September).
>

Why do you think we would have to wait for a newer mesa? AFAICT the mesa
version in Fido (10.4.4) already has vc4 support [0]. Although we have
been using mesa master so I should test how well 10.4 works. AFAIK Derek
picked a specific mesa sha1 that Eric's vc4 DRM driver was known to work.

But if there is a meta-raspberrypi/recipes-graphics/mesa/mesa_%.bbappend
then we can use a newer mesa in tizen-distro without the need of having
patches on top of meta-raspberrypi as we do now.
 
> * kernel: have different name e.g linux-raspberrypi-vc4
>

Yes, that seems to be what most people agree on. I'll change it in v2.

> The selection is done in this layer by changing default providers. In
> a first step this could be done manually - aided by a helpful comment.
>

Agreed.

> Andreas
>

[0]: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/vc4?h=10.4

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack

[Andreas Müller]

On Fri, Aug 7, 2015 at 12:45 PM, Javier Martinez Canillas
 wrote:
> Hello Andreas,
>
> Thanks a lot for your feedback.
>
> On 08/06/2015 09:41 AM, Andreas Müller wrote:
>> On Thu, Aug 6, 2015 at 8:59 AM, Javier Martinez Canillas
>>  wrote:
>>> Yes, I in fact was not sure if it should be a distro or machine feature
>>> and then decided on the former because there is more than the kernel to
>>> make it work like changing mesa configure options. But as mentioned to
>>> Andrea Müller, probably we should ship a mesa .bbappend for this in the
>>> BSP so I agree that a MACHINE_FEATURE will make more sense.
>> Suggestions:
>>
>> * Mesa: A simple append with
>>
>> PACKAGECONFIG_append_rpi += " gallium"
>> GALLIUMDRIVERS_rpi = "vc4"
>>
>> would do. If you check mesa.inc in oe-core others (intel) do similar
>
> That sounds good to me.
>
>> (we might have to wait for a more recent mesa expected in September).
>>
>
> Why do you think we would have to wait for a newer mesa? AFAICT the mesa
> version in Fido (10.4.4) already has vc4 support [0]. Although we have
> been using mesa master so I should test how well 10.4 works. AFAIK Derek
> picked a specific mesa sha1 that Eric's vc4 DRM driver was known to work.
Just started an image based upon oe-core's master sources yet - no
EGL/GLES tests so far. This weekend I will try som EGL/GLES and am
really excited to see how far I get with my first open source graphic
stack (am so tired of this blob crap)...

Andreas
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack

[Javier Martinez Canillas]

Hello Andreas,

On 08/07/2015 01:30 PM, Andreas Müller wrote:
> On Fri, Aug 7, 2015 at 12:45 PM, Javier Martinez Canillas
>  wrote:
>> Hello Andreas,
>>
>> Thanks a lot for your feedback.
>>
>> On 08/06/2015 09:41 AM, Andreas Müller wrote:
>>> On Thu, Aug 6, 2015 at 8:59 AM, Javier Martinez Canillas
>>>  wrote:
 Yes, I in fact was not sure if it should be a distro or machine feature
 and then decided on the former because there is more than the kernel to
 make it work like changing mesa configure options. But as mentioned to
 Andrea Müller, probably we should ship a mesa .bbappend for this in the
 BSP so I agree that a MACHINE_FEATURE will make more sense.
>>> Suggestions:
>>>
>>> * Mesa: A simple append with
>>>
>>> PACKAGECONFIG_append_rpi += " gallium"
>>> GALLIUMDRIVERS_rpi = "vc4"
>>>
>>> would do. If you check mesa.inc in oe-core others (intel) do similar
>>
>> That sounds good to me.
>>
>>> (we might have to wait for a more recent mesa expected in September).
>>>
>>
>> Why do you think we would have to wait for a newer mesa? AFAICT the mesa
>> version in Fido (10.4.4) already has vc4 support [0]. Although we have
>> been using mesa master so I should test how well 10.4 works. AFAIK Derek
>> picked a specific mesa sha1 that Eric's vc4 DRM driver was known to work.
> Just started an image based upon oe-core's master sources yet - no
> EGL/GLES tests so far. This weekend I will try som EGL/GLES and am
> really excited to see how far I get with my first open source graphic
> stack (am so tired of this blob crap)...
>

Awesome, thanks a lot for all your feedback, suggestions and tests!
 
> Andreas
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ipk zImage in master-next

[Trevor Woerner]

When packaging a zImage kernel for IPK in master-next the following
error shows up:

| kernel-image-zImage-4.1.2-fslc+g95d9e15
| *** Error: Package name  contains illegal characters, (other than
[a-z0-9.+-])

It looks like the newer kernel.bbclass is much more sophisticated about
generating package names than before.

Has anyone else seen this? Is there a simple way of saying "the type is
zimage where packaging for ipk is concerned but zImage otherwise"?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] autotools --prefix ignored?

[Adam Rossi]

Hi folks. I have tried a number of different ways to control the
installation location of an auto tools-based project. From the command
line I would run:

./bootstrap
./configure --prefix=/opt/myfolder
make
make install

In my recipe I tried a number of ways to keep the binary out of
/usr/bin, but none seem to work. Relevant parts of the recipe:

inherit autotools
EXTRA_OECONF = "--prefix=${D}/opt/myfolder"

The above is ignored, auto tools puts the results in /usr/bin

I also tried to override the do configure:

do_configure() {
oe_runconf --prefix=${D}/opt/myfolder
}

But I get complaints that the configure script is not found. I realize
I am trying to swim upstream by controlling this location, but the
heart wants what the heart wants. Any ideas?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW32

[Jolley, Stephen K]

Current Dev Position: 1.9 Milestone 3 (M3)

Next Deadline: M3 cut off of August 24th at noon GMT (on hold, see status)


SWAT team rotation: Juro -> Anibal

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

* 1.9M2 is in QA, tests so far have shown some issues, only an 
lsb/shadow password issue may trigger an rc2 from the test results so far.

* Richard is travelling atm. We have tried a build of various queued 
patches on the autobuilder with only around a 80% success rate of the patches 
which is disappointing. Some have been missing very basic testing. This means 
patch merging will slow down, now likely until after we decide if we run an M2 
rc2 or not.

* The "random" autobuilder failures continue to cause problems. We're 
looking into the issues and there should be bugs being filed under the "master 
bug" https://bugzilla.yoctoproject.org/show_bug.cgi?id=7983

* Tinfoil2 (the new version of tinfoil that works with memory resident 
bitbake) is progressing but as we try and do new things with the bitbake APIs, 
we're exposing issues we need to fix before we can make it work.

* The knock on effect of the issues we're having is that some of the 
features we're considering may not make 1.9.


Key YP 1.9 Dates:

YP Final/M4 Cut off: Sept. 28, 2015 noon GMT

1.9 M2 Release Target: Before Aug. 14, 2015

1.9 M3 Release Target: Before Sept. 11 2015

1.9 final Release Target: Before Oct. 30, 2015


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status

https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features


Tracking Metrics:

WDD 1835 (last week 1758 )

(https://wiki.yoctoproject.org/charts/combo.html)


[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-selinux] findutils/gnulib:drop the error output of 'ls' command

[Joe MacDonald]

[Re: [yocto] [PATCH][meta-selinux] findutils/gnulib:drop the error output of 
'ls' command] On 15.07.24 (Fri 16:51) wenzong fan wrote:

> Ping ...

This one clearly got lost in the mail somewhere (I'm working on making
sure that doesn't happen anymore) but it also doesn't look applicable to
the current findutils.  If it is, please re-submit it.

-J.

> 
> On 04/02/2015 10:26 AM, rongqing...@windriver.com wrote:
> >From: Roy Li 
> >
> >The ls command is used to check if the file exists, and it is normal that
> >the checked file does not exist, so drop the ls error ouput:
> >  ls: cannot access ./doc/fdl.texi: No such file or directory
> >
> >Signed-off-by: Roy Li 
> >---
> >  .../drop-the-error-output-of-ls-command.patch  | 29 
> > ++
> >  .../findutils/findutils_4.4.2.bbappend |  1 +
> >  2 files changed, 30 insertions(+)
> >  create mode 100644 
> > recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
> >
> >diff --git 
> >a/recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
> > 
> >b/recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
> >new file mode 100644
> >index 000..069be41
> >--- /dev/null
> >+++ 
> >b/recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
> >@@ -0,0 +1,29 @@
> >+[PATCH] drop the error output of 'ls' command
> >+
> >+Upstream-Status: pending
> >+
> >+ls is used to check if the file exists, and it is normal that
> >+the checked file does not exist, so drop the ls error
> >+ ls: cannot access ./doc/fdl.texi: No such file or directory
> >+
> >+Signed-off-by: Roy Li 
> >+---
> >+ gnulib-tool | 2 +-
> >+ 1 file changed, 1 insertion(+), 1 deletion(-)
> >+
> >+diff --git a/gnulib-tool b/gnulib-tool
> >+index 354b1f0..beb81ba 100755
> >+--- a/gnulib-tool
> > b/gnulib-tool
> >+@@ -602,7 +602,7 @@ else
> >+   {
> >+ # Use two sed invocations. A single sed -n -e 's,^.* -> \(.*\)$,\1,p'
> >+ # would do the wrong thing if the link target contains " -> ".
> >+-LC_ALL=C ls -l "$1" | sed -e 's, -> ,#%%#,' | sed -n -e 
> >'s,^.*#%%#\(.*\)$,\1,p'
> >++LC_ALL=C ls -l "$1" 2>/dev/null | sed -e 's, -> ,#%%#,' | sed -n -e 
> >'s,^.*#%%#\(.*\)$,\1,p'
> >+   }
> >+ fi
> >+
> >+--
> >+1.9.1
> >+
> >diff --git a/recipes-extended/findutils/findutils_4.4.2.bbappend 
> >b/recipes-extended/findutils/findutils_4.4.2.bbappend
> >index 3245e5c..e174888 100644
> >--- a/recipes-extended/findutils/findutils_4.4.2.bbappend
> >+++ b/recipes-extended/findutils/findutils_4.4.2.bbappend
> >@@ -5,6 +5,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> >  SRC_URI += 
> > "git://git.savannah.gnu.org/gnulib.git;protocol=git;rev=0e0635af0b23826911dc456bd0da40dcb19247de"
> >  SRC_URI += "file://findutils-with-selinux.patch"
> >  SRC_URI += "file://findutils-with-selinux-gnulib.patch"
> >+SRC_URI += 
> >"file://drop-the-error-output-of-ls-command.patch;patchdir=../git/"
> >
> >  inherit with-selinux
> >
> >
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto