Re: [yocto] [meta-java] openjdk-8 fail to build

2015-12-13 Thread Jens Rehsack 

> Am 11.12.2015 um 18:16 schrieb Federico Pietro Briata 
> :
> 
> Hi All,
> I'm trying to build openjdk-8 but I'm stuck.
> 
> my current setup does not define anything for:
> 
> #PREFERRED_PROVIDER_virtual/java-native
> #PREFERRED_PROVIDER_virtual/javac-native
> 
> follow the log error
> 
> ERROR: Function failed: do_configure (log file is located at 
> /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_configure.27024)
> ERROR: Logfile of failure stored in: 
> /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_configure.27024
> Log data follows:
> | DEBUG: Executing python function sysroot_cleansstate
> | DEBUG: Python function sysroot_cleansstate finished
> | DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 
> 'bit-64', 'x86_64-linux', 'common']
> | DEBUG: Executing shell function autotools_preconfigure
> | DEBUG: Shell function autotools_preconfigure finished
> | DEBUG: Executing python function autotools_copy_aclocals
> | DEBUG: Python function autotools_copy_aclocals finished
> | DEBUG: Executing shell function do_configure
> | ERROR: no configure script found at 
> /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/configure

Are you on poky/master or cherry-picked fe506edd?

> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_configure (log file is located at 
> /home/federico/yocto/imx6/R6.0/build-imx6-mx6quad/tmp/work/x86_64-linux/openjdk-8-native/72b05-r0/temp/log.do_configure.27024)
> ERROR: Task 146 
> (/home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/openjdk-8-native_72b05.bb,
>  do_configure) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 1139 tasks of which 15 didn't need to be rerun 
> and 1 failed.
> No currently running tasks (1139 of 1150)
> 
> Summary: 1 task failed:
>   
> /home/federico/yocto/imx6/R6.0/sources/meta-java/recipes-core/openjdk/openjdk-8-native_72b05.bb,
>  do_configure
> 
> thanks and regards
> Federico
> 

--
Jens Rehsack - rehs...@gmail.com



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

[yocto] Which OpenSSH packages to use?

2015-12-13 Thread Clay D. Montgomery 
I'm trying to understand which of these OpenSSH package options I should 
use with the CORE_IMAGE_EXTRA_INSTALL option:


openssh
openssh-sshd
openssh-sftp
openssh-sftp-server

I want OpenSSH server functionality that supports both the scp and sftp 
protocols. I first tried just 'openssh' and found that it provides scp 
but not sftp.
So then I tried the latter 3 options and I got sftp, but not scp. Do I 
really need all 4 of these to get scp and sftp?


I checked this recipe guide and found it lists yet another package named 
'packagegroup-core-ssh-openssh 
' but it says 
nothing about sftp.

http://recipes.yoctoproject.org/rrs/recipes/2.1/M2/

I would appreciate some advise.

Thanks, Clay Montgomery


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

Re: [yocto] Which OpenSSH packages to use?

2015-12-13 Thread Khem Raj 

> On Dec 13, 2015, at 10:35 AM, Clay D. Montgomery  wrote:
> 
> I'm trying to understand which of these OpenSSH package options I should use 
> with the CORE_IMAGE_EXTRA_INSTALL option:
> 
> openssh
> openssh-sshd
> openssh-sftp
> openssh-sftp-server
> 
> I want OpenSSH server functionality that supports both the scp and sftp 
> protocols. I first tried just 'openssh' and found that it provides scp but 
> not sftp.
> So then I tried the latter 3 options and I got sftp, but not scp. Do I really 
> need all 4 of these to get scp and sftp?
> 
> I checked this recipe guide and found it lists yet another package named 
> 'packagegroup-core-ssh-openssh 
> ' but it says nothing 
> about sftp.
> http://recipes.yoctoproject.org/rrs/recipes/2.1/M2/ 
> 
> 
> I would appreciate some advise.

you can just do

EXTRA_IMAGE_FEATURES += “ssh-server-openssl” in local.conf

or

IMAGE_FEATURES += "ssh-server-openssl"

via a bbappend in your layer if you hinging on to same image recipe otherwise 
if you have your own image recipe
then add it to that.

> 
> Thanks, Clay Montgomery
> 
> 
> --
> ___
> 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

[yocto] [Recipe reporting system] Upgradable recipe name list

2015-12-13 Thread recipe-report 
This mail was sent out by Recipe reporting system.

This message list those recipes which need to be upgraded. If maintainers
believe some of them needn't to upgrade this time, they can fill in
RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this
recipe remainder until newer upstream version was detected.

Example:
RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 is unstable"

You can check the detail information at:

http://recipes.yoctoproject.org/

Package   Version  Upstream version  Maintainer
NoUpgradeReason
  ---      
--
opkg  0.3.00.3.1 Alejandro del Cas...
ruby  2.2.22.2.3 Alejandro Hernandez
nfs-utils 1.3.11.3.3 Alejandro Hernandez
libxml-simple-perl2.20 2.22  Alejandro Hernandez
perl  5.22.0   5.22.1Alejandro Hernandez
python-mako   1.0.11.0.3 Alejandro Hernandez
python-nose   1.3.61.3.7 Alejandro Hernandez
python-numpy  1.7.01.10.1Alejandro Hernandez
python-pycurl 7.19.5.2 7.19.5.3  Alejandro Hernandez
python-pygobject  2.28.3   3.19.2Alejandro Hernandez   
Newer versions of python-py...
python-scons  2.3.62.4.1 Alejandro Hernandez
python3   3.5.03.5.1 Alejandro Hernandez
python2.7.92.7.11Alejandro Hernandez
swig  3.0.63.0.7 Alejandro Hernandez
python3-setuptools18.7.1   18.8.1Alejandro Hernandez
python-setuptools 18.7.1   18.8.1Alejandro Hernandez
liberation-fonts  1.04 2.00.1Alexander Kanavin 
2.x depends on fontforge pa...
kernelshark   2.5.3+gitX   2.6+gitAUTOINC+9b...  Alexander Kanavin
webkitgtk 2.8.52.10.4Alexander Kanavin
gcr   3.16.0   3.18.0Alexander Kanavin
gnome-desktop33.16.2   3.18.2Alexander Kanavin
libsecret 0.18.2   0.18.3Alexander Kanavin
libwebp   0.4.30.4.4 Alexander Kanavin
kbd   2.0.22.0.3 Alexander Kanavin
nss   3.19.2   3.21  Alexander Kanavin
kexec-tools   2.0.10   2.0.11Alexander Kanavin
btrfs-tools   4.1.24.3.1 Alexander Kanavin
babeltrace1.2.4+gitX   1.3.1+gitAUTOINC+...  Alexander Kanavin
powertop  2.7  2.8   Alexander Kanavin
systemtap-uprobes 2.7+gitX 2.9+gitAUTOINC+70...  Alexander Kanavin
systemtap 2.7+gitX 2.9+gitAUTOINC+70...  Alexander Kanavin
trace-cmd 2.5.3+gitX   2.6+gitAUTOINC+9b...  Alexander Kanavin
tiff  4.0.44.0.6 Alexander Kanavin
mkelfimage4.0+gitX 4.2+gitAUTOINC+43...  Alexander Kanavin 
mkelfimage has been removed...
mtd-utils 1.5.1+gitX   1.5.2+gitAUTOINC+...  Alexander Kanavin
boost 1.58.0   1.59.0Alexander Kanavin
icu   56.1 56.1-AIX7.1-VA2   Alexander Kanavin
valgrind  3.10.1   3.11.0Alexander Kanavin
bjam-native   1.58.0   1.59.0Alexander Kanavin
liburcu   0.8.70.9.1 Alexander Kanavin
lighttpd  1.4.36   1.4.38Alexander Kanavin
msmtp 1.6.21.6.3 Alexander Kanavin
libassuan 2.2.12.4.2 Alexander Kanavin
procps3.3.10   3.3.11Alexander Kanavin
epiphany  3.16.3   3.18.2Alexander Kanavin
iso-codes 3.58 3.63  Alexander Kanavin
dpkg  1.18.2   1.18.3Aníbal Limón
apt   1.0.10.1 1.1.4 Aníbal Limón
linux-libc-headers4.1  4.3.2 Bruce Ashfield
guilt-native  0.35+gitX0.36+gitAUTOINC+2...  Bruce Ashfield
pciutils  3.3.13.4.0 Chen Qi
resolvconf1.77 1.78  Chen Qi
dbus-test 1.8.20   1.10.6Chen Qi
dbus  1.8.20   1.10.6Chen Qi
systemd   225+gitX 228+gitAUTOINC+dd...  Chen Qi
util-linux2.26.2   2.27.1Chen Qi
kmod  21+gitX  22+gitAUTO

Re: [yocto] Custom kernel headers and SDK

2015-12-13 Thread Valentin Longchamp 
Hello William and Martin,

On 10/12/2015 15:53, William Mills wrote:
> 
> On 12/10/2015 09:40 AM, Vuille, Martin (Martin) wrote:
>> Hi Valentin,
>>
>> When we first encountered the need for custom kernel headers, I asked
>> a similar question to yours on this list. And what I learned from some of the
>> responses was that modifying the standard headers was fraught with
>> problems, including the issue that you raise.
>>
>> Fortunately, we got away without having to modify and export any standard
>> headers, so I dodged that bullet.
>>
>> Some ideas that come to mind:
>>
>> - Can you install your customized version in ${includedir}/XXX and use the
>>   include path search order to make sure the compiler sees it first?
> 
> This was the approach we used in a Debian based system.  Applications
> that needed to be dependent on the custom capabilities of our kernel
> depended on our XXX-kernel-header package and adjusted their include
> path to use it first.  All other apps continue to use the standard
> kernel headers.  (busybox or tar does not really care about our new
> wizbang feature and the Debian distro sure was not going to rebuild them
> just for us.)
> 
> I see no reason this could not work as well in an OE based distro.
> 
>>
>> - Can you include the standard header in a "wrapper" header and make your
>>   customizations in the wrapper instead?
>>
>> Regards,
>> MV

I just wanted to thank you for your answers and suggestion.

I have now used this approach and it works fine:
- make a new package that installs our changed linux-headers into another
directory than the linux-libc-headers
- added this package to TOOLCHAIN_TARGET_TASK so that it gets installed to the
SDK's sysroot
- changed the include path of the userspace applications that require these
changed headers and use the SDK so that they find them ($SDKTARGETSYSROOT helps
a lot here).

Valentin

>>
>>> -Original Message-
>>> From: Longchamp, Valentin [mailto:valentin.longch...@keymile.com]
>>> Sent: December 10, 2015 4:47 AM
>>> To: Vuille, Martin (Martin); yocto@yoctoproject.org
>>> Cc: Brunck, Holger
>>> Subject: RE: Custom kernel headers and SDK
>>>
>>> Hi Martin,
>>>
>>> Thanks a lot for the suggestion. I had in the meantime come to a simliar
>>> solution: define a linux-XXX-headers recipe in our own meta layer where I
>>> install the missing kernel headers and then I add this linux-XXX-headers-dev
>>> package to our SDK's sysroot thanks to TARGET_TOOLCHAIN_TASK.
>>> Your implementation looks fine and I am going to pick some ideas from it.
>>>
>>> However, I have stumbled upon another problem with this approach: it
>>> works well if you add new files to the kernel headers. We unforntunately
>>> have at least one uapi file (i2c.h to name it) that is present in the 
>>> standard
>>> kernel headers where we have our own version with some
>>> additions/extensions. If I install our version from ou linux-XXX-headers
>>> recipe, bitbake (correctly) complains that this file is provided by 2 
>>> packages
>>> (linux-libc-headers and linux-XXX-headers). And here I really don't know how
>>> to solve this issue. Any ideas/suggestions ?
>>>
>>> Thanks
>>>
>>> Valentin

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