Re: [yocto] Package inclusion

[Paul Eggleton]

On Thursday 15 October 2015 18:03:13 Carlos Sánchez de La Lama wrote:
> Hi all,
> 
> I have some doubts on how package inclusion in images is determined. For
> example, when building core-image-base, I would say that both
> 
> kernel-module-uvesafb
> kernel-module-input
> 
> are recommended (through RRECOMENDS in packagegroup-base).
> 
> However, -uvesafb makes it to the final image, whereas -input does not.

I don't see a reference to kernel-module-uvesafb in packagegroup-base.

> I double-checked on the running system under QEMU *and* reading the
> image manifest at
> tmp/deploy/images/qemux86/core-image-base-qemux86.manifest
> 
> I must be missing something. Can someone give me a pointer?

If you would like to analyse the package dependency tree for an image one way
that works is to use buildhistory:

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality

Among other things this will give you a .dot dependency graph file (for which 
I can recommend xdot.py as a viewer).

Cheers,
Paul

-- 

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

[yocto] Queries regarding yocto dual booting

[Debasmita Lohar]

Hello,
I am using De2i-150 board which provides a yocto iso. I have installed
puppy linux before yocto and now I want to install yocto in the unallocated
portion. Basically I want dual booting. But when I tried to install yocto,
it just started from the live cd and did not show me any install option.
Please help me regarding this issue.
Thank you.

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

Re: [yocto] Package inclusion

[Carlos Sánchez de La Lama]

Hi Paul,

>> I have some doubts on how package inclusion in images is determined. For
>> example, when building core-image-base, I would say that both
>> 
>> kernel-module-uvesafb
>> kernel-module-input
>> 
>> are recommended (through RRECOMENDS in packagegroup-base).
>
> I don't see a reference to kernel-module-uvesafb in packagegroup-base.

You are right, my bad. I was examining several cases and I used the
wrong one when writing the mail. I should have said

kernel-module-nls-utf8 (which goes into the image)
kernel-module-input (which does not make it to the image)

and both appear in RRECOMENDS_packagegroup-base.

> If you would like to analyse the package dependency tree for an image one way
> that works is to use buildhistory:

I checked the buildhistory (nice report, BTW), and I see

"packagegroup-base" -> "kernel-module-nls-utf8" [style=dotted];

but not a trace of kernel-module-input. I do not understand why -input
gets a differnt handling than -nls-utf8. My guess is it gets excluded
somehow, but I have not found why/where.

Thanks!

Carlos

-- 
'La vie est une longue chute, Marcus. Le plus important est de savoir tomber.'

Joël Dicker, "La Vérité sur l'affaire Harry Quebert" (2012)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Package inclusion

[Paul Eggleton]

On Friday 16 October 2015 09:38:56 Carlos Sánchez de La Lama wrote:
> Hi Paul,
> 
> >> I have some doubts on how package inclusion in images is determined. For
> >> example, when building core-image-base, I would say that both
> >> 
> >> kernel-module-uvesafb
> >> kernel-module-input
> >> 
> >> are recommended (through RRECOMENDS in packagegroup-base).
> > 
> > I don't see a reference to kernel-module-uvesafb in packagegroup-base.
> 
> You are right, my bad. I was examining several cases and I used the
> wrong one when writing the mail. I should have said
> 
> kernel-module-nls-utf8 (which goes into the image)
> kernel-module-input (which does not make it to the image)
> 
> and both appear in RRECOMENDS_packagegroup-base.
> 
> > If you would like to analyse the package dependency tree for an image one
> > way
> > that works is to use buildhistory:
> I checked the buildhistory (nice report, BTW), and I see
> 
> "packagegroup-base" -> "kernel-module-nls-utf8" [style=dotted];
> 
> but not a trace of kernel-module-input. I do not understand why -input
> gets a differnt handling than -nls-utf8. My guess is it gets excluded
> somehow, but I have not found why/where.

You definitely have the kernel-module-input package created - right? Because 
it's an RRECOMMENDS, that package can actually not be produced by the kernel 
(i.e. because the corresponding config option is 'y' or 'n' instead of 'm').

Another much less likely possibility is that you have BAD_RECOMMENDATIONS set 
to include kernel-module-input. bitbake -e | grep ^BAD_RECOMMENDATIONS will 
tell you if that is the case.

Cheers,
Paul

-- 

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

[yocto] Not able to preserve a variable across two python functions in bbclass

[Reshetova, Elena]

Hi,

 

I am having a very stupid issue, which I can't figure out. I am setting my
own variable from one python function (via d.setVar) and then attempting to
read it from another python function (via d.getVar). Both functions are in
the same bbclass. 

However, result of reading is always empty. But if I read this variable back
in the same python function, I get a correct value.

Aren't "d" store is global and supposed to work across functions and even
classes?

 

Here is the commit that shows that I am doing:
https://github.com/01org/meta-security-isafw/commit/590f7158a90c98dbb1bf650e
d081adbccb6e0006

 

Really plain simple, but doesn't work :( 

 

Best Regards,
Elena.



smime.p7s
Description: S/MIME cryptographic signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Not able to preserve a variable across two python functions in bbclass

[Paul Eggleton]

Hi Elena,

On Friday 16 October 2015 09:52:28 Reshetova, Elena wrote:
> I am having a very stupid issue, which I can't figure out. I am setting my
> own variable from one python function (via d.setVar) and then attempting to
> read it from another python function (via d.getVar). Both functions are in
> the same bbclass.
> 
> However, result of reading is always empty. But if I read this variable back
> in the same python function, I get a correct value.
> 
> Aren't "d" store is global and supposed to work across functions and even
> classes?
> 
> 
> 
> Here is the commit that shows that I am doing:
> https://github.com/01org/meta-security-isafw/commit/590f7158a90c98dbb1bf650e
> d081adbccb6e0006
> 
> Really plain simple, but doesn't work :(

I'm afraid not, other than dependency relationships, task functions are 
executed independently and thus have their own scope. The way to do this sort 
of thing is to set the variable in the parent scope i.e. the recipe level (or 
above that, the configuration level).  

If you absolutely must pass things between tasks you need to do so via the 
sysroot, taking care to set up the appropriate task dependency relationship to 
ensure the sysroot gets populated; I'm not sure that's the case here though.

Cheers,
Paul

-- 

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

Re: [yocto] Not able to preserve a variable across two python functions in bbclass

[Reshetova, Elena]

>I'm afraid not, other than dependency relationships, task functions are
executed independently and thus have their own scope. The way to do this
sort of thing is to set the variable in the parent scope i.e. the recipe
level (or above that, the configuration level).  

Thank you for your reply Paul! I was afraid the issue can be this, I guess
setting it in some configuration above probably is the best way. 

Best Regards,
Elena.


smime.p7s
Description: S/MIME cryptographic signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg 0.3.0 or rootfs task

[Ahsan, Noor]

Hello,

I noticed that at the time of rootfs creation symbolic links of the ipk files 
present in deploy/ipk. The problem what have it while creation of symbolic link 
it take the full path till that ipk and remove slashes and convert them into 
underscores. Use that as the name of the symbolic link. This make a very long 
file names. If we have very long path then name of the symlink exceed from max 
filename limits. And we get following error

Collected errors:
* file_link: unable to stat 
`/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
 File name too long.

Can anyone tell me why the addition of full path was added to the symlink name 
and can we remove it cause it is cause issues?

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

Re: [yocto] meta-raspberrypi no soud output

[Alex J Lennon]

On 15/10/2015 16:57, Edward Vidal wrote:
> Hello All,
> Does any have snd working on Raspberry Pi 2B?
>
> I have tried aplay speech_dft.wav
> PLAYING WAVE: 'speech_dft.wav' :  Signed 16 bit Little Endian, rate
> 22050 Hz Mono
> with ear plugs or speaker no snd.
> Any and all help appreciated.
>

Some notes here on routing Edward,

http://redmine.gherzan.ro/issues/55

Best, Alex

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

[yocto] [meta-java] openjdk-7-jre was skipped: missing required distro feature ['x11'] (not in DISTRO_FEATURES)

[Federico Pietro Briata]

Hi Folks,
I'm trying to compile java without x11 and unfortunately also without
success..

I've added in my local.conf:

DISTRO_FEATURES_remove = "x11"
# Java build settings
PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"
PREFERRED_VERSION_openjdk-7-jre = "85b01-2.6.1"
PREFERRED_VERSION_icedtea7-native = "2.1.3"
PREFERRED_PROVIDER_openjdk-7-jre = "openjdk-7-jre"

but I get this error

ERROR: Nothing RPROVIDES 'openjdk-7-jre' (but
/home/f34389b/yocto/PCM/R5.0/sources/meta-fede/recipes-images/images/
fede-java-test.bb RDEPENDS on or otherwise requires it)
ERROR: openjdk-7-jre was skipped: missing required distro feature ['x11']
(not in DISTRO_FEATURES)

Patching those files:
meta-java/recipes-core/classpath/classpath.inc
meta-java/recipes-core/jamvm/jamvm.inc
meta-java/recipes-core/jamvm/jamvm_git.bb
meta-java/recipes-core/openjdk/openjdk-common.inc
poky/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc

like this:
-REQUIRED_DISTRO_FEATURES = "x11"
+#REQUIRED_DISTRO_FEATURES = "x11"

seems to be a temporary workaround

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

[yocto] [meta-java] can zero shark be enabled again?

[Federico Pietro Briata]

Hi again,

I saw that some JIT optimization for arm32 has been announcement in icedtea

the announcement is available at
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-January/030392.html

So I'm just wondering if anyone know if shark can be enabled again also in
yocto recipes and can suggest me some tip to use it.

thanks and regards
Federico
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-java] openjdk-7-jre was skipped: missing required distro feature ['x11'] (not in DISTRO_FEATURES)

[Maxin B. John]

Hi,

On Fri, Oct 16, 2015 at 03:35:22PM +0200, Federico Pietro Briata wrote:
>
>Hi Folks,
>I'm trying to compile java without x11 and unfortunately also without success..
>
>I've added in my local.conf:
>
>DISTRO_FEATURES_remove = "x11"
># Java build settings
>PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
>PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"
>PREFERRED_VERSION_openjdk-7-jre = "85b01-2.6.1"
>PREFERRED_VERSION_icedtea7-native = "2.1.3"
>PREFERRED_PROVIDER_openjdk-7-jre = "openjdk-7-jre"
>
>but I get this error
>
>ERROR: Nothing RPROVIDES 'openjdk-7-jre' (but 
>/home/f34389b/yocto/PCM/R5.0/sources/meta-fede/recipes-images/images/fede-java-test.bb
> RDEPENDS on or otherwise requires it)
>ERROR: openjdk-7-jre was skipped: missing required distro feature ['x11'] (not 
>in DISTRO_FEATURES)
>
>Patching those files:
>meta-java/recipes-core/classpath/classpath.inc
>meta-java/recipes-core/jamvm/jamvm.inc
>meta-java/recipes-core/jamvm/jamvm_git.bb
>meta-java/recipes-core/openjdk/openjdk-common.inc
>poky/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc

>like this:
>-REQUIRED_DISTRO_FEATURES = "x11"
>+#REQUIRED_DISTRO_FEATURES = "x11"
>seems to be a temporary workaround

These lines were added by this commit:

---
commit 24b98ac3a6ca7fadfba24709aac8d0b71316e299
Author: Mario Domenech Goulart 
Date:   Tue Aug 18 17:14:30 2015 -0300

   Avoid parse time errors due to dependency on x11, for distros without x11

   BitBake raises some errors when processing recipes that depend on x11
   for distros that don't have x11 in DISTRO_FEATURES. To work around
   that issue, REQUIRED_DISTRO_FEATURES = "x11" (from
   distro_features_check.bbclass) has been set for the following recipes:

* cacao
* classpath
* jamvm
* openjdk-6-release
* openjdk-7-release
   
 That makes BitBake skip those recipes during the cache generation
 (they'd still be parsed, but ignored).
---

Even if we revert this commit, the openjdk-7-jre build will fail 
due to dependency on gtk+, libxt...etc. 

Recently Jens Rehsack did some work in this direction for icedtea7:
http://lists.openembedded.org/pipermail/openembedded-devel/2015-October/103849.html

We will have to follow that way to get rid of the x11 dependency in other 
packages.

>
>regards
>federico

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

Re: [yocto] [meta-java] openjdk-7-jre was skipped: missing required distro feature ['x11'] (not in DISTRO_FEATURES)

[Jens Rehsack]

> Am 16.10.2015 um 15:35 schrieb Federico Pietro Briata 
> :
> 
> Hi Folks,
> I'm trying to compile java without x11 and unfortunately also without 
> success..
> 
> I've added in my local.conf:
> 
> DISTRO_FEATURES_remove = "x11"
> # Java build settings
> PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
> PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"
> PREFERRED_VERSION_openjdk-7-jre = "85b01-2.6.1"
> PREFERRED_VERSION_icedtea7-native = "2.1.3"
> PREFERRED_PROVIDER_openjdk-7-jre = "openjdk-7-jre"
> 
> but I get this error
> 
> ERROR: Nothing RPROVIDES 'openjdk-7-jre' (but 
> /home/f34389b/yocto/PCM/R5.0/sources/meta-fede/recipes-images/images/fede-java-test.bb
>  RDEPENDS on or otherwise requires it)
> ERROR: openjdk-7-jre was skipped: missing required distro feature ['x11'] 
> (not in DISTRO_FEATURES)
> 
> Patching those files:
> meta-java/recipes-core/classpath/classpath.inc
> meta-java/recipes-core/jamvm/jamvm.inc
> meta-java/recipes-core/jamvm/jamvm_git.bb
> meta-java/recipes-core/openjdk/openjdk-common.inc
> poky/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
> 
> like this:
> -REQUIRED_DISTRO_FEATURES = "x11"
> +#REQUIRED_DISTRO_FEATURES = "x11"
> 
> seems to be a temporary workaround

Hi Federico,

unfortunately I missed 
https://github.com/rehsack/meta-java/commit/11e30f2bf198bcad91c0d14104fcd8b91255ad69
 when submitting my patchset.

I'm working on some jdk7 native fixes and layer cleanup and will send a new 
patchset later today.

I do not intend to provide jdk7 for cross-compiling support without x11 - when 
you want no-x11, from my point of view, go to jdk8.

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

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

Re: [yocto] [meta-java] can zero shark be enabled again?

[Jens Rehsack]

> Am 16.10.2015 um 16:26 schrieb Federico Pietro Briata 
> :
> 
> Hi again,
> 
> I saw that some JIT optimization for arm32 has been announcement in icedtea
> 
> the announcement is available at 
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-January/030392.html
> 
> So I'm just wondering if anyone know if shark can be enabled again also in 
> yocto recipes and can suggest me some tip to use it.

I fear you mix between ARMJIT provided by IceadTea and ZeroShark provided by 
OpenJDK.

While IcedTea maintains the ARMJIT within hotspot ported from OpenJDK6, 
ZeroShark uses LLVM's JIT.

Since ARM support in LLVM's JIT was utterly broken, MCJIT support is required 
for ZeroShark.
I was working on that but my ARMv7 and my ARMv5 are still crashing - even when 
I can realize some progress (how quick does it crash ^^).

Dunno if - and if, when - I find some tuits to continue the crash detection and 
fixing...

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

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

[yocto] Yocto Project Status WW42

[Jolley, Stephen K]

Current Dev Position: YP 2.0 Final (rc2 to be built soon)

Next Deadline: YP 2.0 Final Release Target: Before Oct. 30, 2015


SWAT team rotation: Randy -> Benjamin

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


Top Bugs to be tackled (2.0 release blockers):

* systemd timeouts in the sanity tests (#7919, #8141, #8142)

* 8124 - SDK on i686 install issue.

* 8139 - Randy need to review

* 8367 - need to confirm gcc 5.x caused regression and understand why 
perl networking is broken

* 8144 - native strip causing intermittent build failures on multiple 
autobuilders

* 8303 - unknown dpkg-native issue causing build failures

* YP 2.0 rc1 QA test report: 
https://wiki.yoctoproject.org/wiki/WW41_-_2015-10-02_-_Full_Pass_2.0.rc1

Basically, we have a ton of bugs with Medium+ priority listed in the above test 
report and whilst no one medium+ blocks release, right now the count is simply 
too high


Key Status/Updates:

* systemd timeouts continue to cause concern, not least as the same 
issues may be affecting other images and the more stringent systemd tests may 
be highlighting issues

* we believe we can soon solve the wic selftest issue

* the LSB sanity test failures were traced back to custom bash memory 
allocator issues

* there are still bugs related to the SDK in various configurations

* there are still far too many medium+ bugs to be able to release

* the 30th as a release date is starting to look extremely unlikely

* we are concerned at the number of patches for "2.1" on the mailing 
list, people are not concentrating on release stabilization

* YP 1.8.1 rc1 is out of QA (looks promising for release).


Reminders:

* We have renamed YP 1.9 to YP 2.0.

* The current version that is in development will launch as YP 2.0 in 
October, 2015.

* The release name for YP 2.0 is 'jethro'.


Key YP 1.9/2.0 Dates:

YP 2.0 Final - 2.0 Cut off: Sept. 28, 2015 noon GMT (rc2 to be built soon)

YP 2.0 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 2090 (last week 2055)

(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] Package inclusion

[Carlos Sánchez de La Lama]

Hi Paul,

>> kernel-module-nls-utf8 (which goes into the image)
>> kernel-module-input (which does not make it to the image)
>> 
>> and both appear in RRECOMENDS_packagegroup-base.
>
> You definitely have the kernel-module-input package created - right? Because 
> it's an RRECOMMENDS, that package can actually not be produced by the kernel 
> (i.e. because the corresponding config option is 'y' or 'n' instead of 'm').

You got it. The package is not created.

I should have checked that before.

Thanks for your help, BR

Carlos

-- 
-Debemos anhelar no sólo la verdad, sino también la virtud -sentenció
Pitágoras-. El conocimiento que se obtiene mediante oro, y no a través de un
merecimiento virtuoso, puede apartarnos del camino recto y ser nefasto para
nosotros y para nuestro entorno.

Marcos Chicot, "El asesinato de Pitágoras" (2013)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Queries regarding yocto dual booting

[Khem Raj]

> On Oct 16, 2015, at 12:22 AM, Debasmita Lohar  wrote:
> 
> Hello,
> I am using De2i-150 board which provides a yocto iso. I have installed puppy 
> linux before yocto and now I want to install yocto in the unallocated 
> portion. Basically I want dual booting. But when I tried to install yocto, it 
> just started from the live cd and did not show me any install option. Please 
> help me regarding this issue.

there are few seconds when the syslinux prompt appears. You need to type in 
"install"

> Thank you.
> 
> Debasmita Lohar
> 
> --
> ___
> 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] opkg 0.3.0 or rootfs task

[Khem Raj]

> On Oct 16, 2015, at 5:47 AM, Ahsan, Noor  wrote:
> 
> Hello,
> 
> I noticed that at the time of rootfs creation symbolic links of the ipk files 
> present in deploy/ipk. The problem what have it while creation of symbolic 
> link it take the full path till that ipk and remove slashes and convert them 
> into underscores. Use that as the name of the symbolic link. This make a very 
> long file names. If we have very long path then name of the symlink exceed 
> from max filename limits. And we get following error
> 
> Collected errors:
> * file_link: unable to stat 
> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
>  File name too long.
> 
> Can anyone tell me why the addition of full path was added to the symlink 
> name and can we remove it cause it is cause issues?

what does

getconf PATH_MAX /

show ?

> 
> Noor
> --
> ___
> 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] Updating NIC drivers in older Yocto

[Dave Mulder]

> I have been using a Sandy Bridge Yocto 1.3 build for a couple years now, on 
> off-
> the-shelf Intel PC motherboards. I also build an application.
> 
> I am now looking into using more recent motherboards. The OS boots just fine,
> but the new NICs (Intel, Realtek) are not supported by the old 3.4.11 kernel.
> 
> What's the best way to support new NICs?  I can see three options:
> 
> 
> 1.   New Yocto.  I suspect (but would be happy to be wrong) that my
> application would need to be built against a different sysroot/toolchain, 
> which
> seems like it would cause backward-compatibility problems (can't run new
> application on old OS), and I would prefer to not have multiple builds of the
> application and have to have the host software determine which version is
> needed (it's an embedded application, and the OS is headless).

I was wrong (happily): My application (built with the 1.3 toolchain) works with 
Yocto 1.8.
I did keep the same BSP (sugarbay), which may be the key.
 
> 2.   New kernel, old Yocto.  I don't know that this is actually an 
> option, or how
> new of a kernel can be used in Yocto 1.3.  If this is an option, it seems 
> like my
> application would not need to be rebuilt.
> 
> 3.   Loadable drivers for new NICs (rather than using the ones built into 
> the
> kernel).  I don't know that this is doable either.
> 
> Are there other options?  Can a new application be built that will work with
> multiple versions of the OS?  Is that even a problem, or am I just assuming 
> the
> worst?
> 
> Thanks!
> Dave
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Ahsan, Noor]

From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Friday, October 16, 2015 9:54 PM
To: Ahsan, Noor
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] opkg 0.3.0 or rootfs task


On Oct 16, 2015, at 5:47 AM, Ahsan, Noor 
mailto:noor_ah...@mentor.com>> wrote:

Hello,

I noticed that at the time of rootfs creation symbolic links of the ipk files 
present in deploy/ipk. The problem what have it while creation of symbolic link 
it take the full path till that ipk and remove slashes and convert them into 
underscores. Use that as the name of the symbolic link. This make a very long 
file names. If we have very long path then name of the symlink exceed from max 
filename limits. And we get following error

Collected errors:
* file_link: unable to stat 
`/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
 File name too long.

Can anyone tell me why the addition of full path was added to the symlink name 
and can we remove it cause it is cause issues?

what does

getconf PATH_MAX /

show ?


jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
PATH_MAX   4096
_POSIX_PATH_MAX4096

Noor
--
___
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] Package with both daemon and shared object

[Vuille, Martin (Martin)]

> From: Khem Raj [mailto:raj.k...@gmail.com] 
> Sent: October 14, 2015 1:25 PM
> 
> 
> > On Oct 14, 2015, at 9:25 AM, Vuille, Martin (Martin)  
> > wrote:
> > 
> > Hi,
> >  
> > I am having a bit of trouble understanding something about
> > packaging.
> >  
> > I have a custom recipe to build a package that contains both
> > a daemon executable and a shared object interface library
> > for the daemon.
> >  
> > But the .so is only packaged in ${PN}-dev, not ${PN}, so
> > it doesn’t end up on the target.
> 
> yes thats default and if the .so was built using proper .so versioning scheme.
> .so is a symlink to .so.X.Y.Z

Thanks! I knew about this at some point but it completely slipped my mind.

Problem fixed now
MV
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-java] openjdk-7-jre was skipped: missing required distro feature ['x11'] (not in DISTRO_FEATURES)

[Federico Pietro Briata]

2015-10-16 16:09 GMT+01:00, Jens Rehsack :
>
>> Am 16.10.2015 um 15:35 schrieb Federico Pietro Briata
>> :
>>
>> Hi Folks,
>> I'm trying to compile java without x11 and unfortunately also without
>> success..
>>
>> I've added in my local.conf:
>>
>> DISTRO_FEATURES_remove = "x11"
>> # Java build settings
>> PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
>> PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"
>> PREFERRED_VERSION_openjdk-7-jre = "85b01-2.6.1"
>> PREFERRED_VERSION_icedtea7-native = "2.1.3"
>> PREFERRED_PROVIDER_openjdk-7-jre = "openjdk-7-jre"
>>
>> but I get this error
>>
>> ERROR: Nothing RPROVIDES 'openjdk-7-jre' (but
>> /home/f34389b/yocto/PCM/R5.0/sources/meta-fede/recipes-images/images/fede-java-test.bb
>> RDEPENDS on or otherwise requires it)
>> ERROR: openjdk-7-jre was skipped: missing required distro feature ['x11']
>> (not in DISTRO_FEATURES)
>>
>> Patching those files:
>> meta-java/recipes-core/classpath/classpath.inc
>> meta-java/recipes-core/jamvm/jamvm.inc
>> meta-java/recipes-core/jamvm/jamvm_git.bb
>> meta-java/recipes-core/openjdk/openjdk-common.inc
>> poky/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
>>
>> like this:
>> -REQUIRED_DISTRO_FEATURES = "x11"
>> +#REQUIRED_DISTRO_FEATURES = "x11"
>>
>> seems to be a temporary workaround
>
> Hi Federico,
>
> unfortunately I missed
> https://github.com/rehsack/meta-java/commit/11e30f2bf198bcad91c0d14104fcd8b91255ad69
> when submitting my patchset.
>
> I'm working on some jdk7 native fixes and layer cleanup and will send a new
> patchset later today.
>
> I do not intend to provide jdk7 for cross-compiling support without x11 -
> when you want no-x11, from my point of view, go to jdk8.
>
> Cheers
> --
> Jens Rehsack - rehs...@gmail.com
>
>

Hi Jens,

my machine it's a arm7 Imx6 display less.

I choose jdk7 because I thought was the best for my target, so for you
should I go to jdk8?

Anyway I've compiled jdk7 now, but I'm not sure if I've to use some
specific configuration set for build with no-x11.

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

Re: [yocto] [meta-java] openjdk-7-jre was skipped: missing required distro feature ['x11'] (not in DISTRO_FEATURES)

[Jens Rehsack]

> Am 16.10.2015 um 21:21 schrieb Federico Pietro Briata 
> :
> 
> 2015-10-16 16:09 GMT+01:00, Jens Rehsack :
>> 
>>> Am 16.10.2015 um 15:35 schrieb Federico Pietro Briata
>>> :
>>> 
>>> Hi Folks,
>>> I'm trying to compile java without x11 and unfortunately also without
>>> success..
>>> 
>>> I've added in my local.conf:
>>> 
>>> DISTRO_FEATURES_remove = "x11"
>>> # Java build settings
>>> PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
>>> PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"
>>> PREFERRED_VERSION_openjdk-7-jre = "85b01-2.6.1"
>>> PREFERRED_VERSION_icedtea7-native = "2.1.3"
>>> PREFERRED_PROVIDER_openjdk-7-jre = "openjdk-7-jre"
>>> 
>>> but I get this error
>>> 
>>> ERROR: Nothing RPROVIDES 'openjdk-7-jre' (but
>>> /home/f34389b/yocto/PCM/R5.0/sources/meta-fede/recipes-images/images/fede-java-test.bb
>>> RDEPENDS on or otherwise requires it)
>>> ERROR: openjdk-7-jre was skipped: missing required distro feature ['x11']
>>> (not in DISTRO_FEATURES)
>>> 
>>> Patching those files:
>>> meta-java/recipes-core/classpath/classpath.inc
>>> meta-java/recipes-core/jamvm/jamvm.inc
>>> meta-java/recipes-core/jamvm/jamvm_git.bb
>>> meta-java/recipes-core/openjdk/openjdk-common.inc
>>> poky/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
>>> 
>>> like this:
>>> -REQUIRED_DISTRO_FEATURES = "x11"
>>> +#REQUIRED_DISTRO_FEATURES = "x11"
>>> 
>>> seems to be a temporary workaround
>> 
>> Hi Federico,
>> 
>> unfortunately I missed
>> https://github.com/rehsack/meta-java/commit/11e30f2bf198bcad91c0d14104fcd8b91255ad69
>> when submitting my patchset.
>> 
>> I'm working on some jdk7 native fixes and layer cleanup and will send a new
>> patchset later today.
>> 
>> I do not intend to provide jdk7 for cross-compiling support without x11 -
>> when you want no-x11, from my point of view, go to jdk8.
>> 
>> Cheers
>> --
>> Jens Rehsack - rehs...@gmail.com
>> 
>> 
> 
> Hi Jens,
> 
> my machine it's a arm7 Imx6 display less.
> 
> I choose jdk7 because I thought was the best for my target, so for you
> should I go to jdk8?

Not for me, for yourself if you want to build an x11-less distro.

> Anyway I've compiled jdk7 now, but I'm not sure if I've to use some
> specific configuration set for build with no-x11.

I patched the jdk8 I submitted to build without x11, not because it's display 
less,
but because it uses EGL and framebuffer.

Because jdk8 requires 
https://github.com/rehsack/poky/commit/04f606795c29705e4e053895f1f007e3b4e3cd17 
- you have to cherry-pick the jdk8 patch and revert-x11-disto-prereq from 
https://github.com/rehsack/meta-java/commits/master to use jdk8.

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

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

Re: [yocto] [meta-java] can zero shark be enabled again?

[Federico Pietro Briata]

2015-10-16 16:14 GMT+01:00, Jens Rehsack :
>
> I fear you mix between ARMJIT provided by IceadTea and ZeroShark provided by
> OpenJDK.

Ops

> While IcedTea maintains the ARMJIT within hotspot ported from OpenJDK6,
> ZeroShark uses LLVM's JIT.

I thought ARMJIT was part of Shark and provided with hotspot Zero,
thanks for clarification!

> Since ARM support in LLVM's JIT was utterly broken, MCJIT support is
> required for ZeroShark.
> I was working on that but my ARMv7 and my ARMv5 are still crashing - even
> when I can realize some progress (how quick does it crash ^^).
>
> Dunno if - and if, when - I find some tuits to continue the crash detection
> and fixing...

Can I help you with testing and debugging? If you give me some tip,
I've lot of time to spend for it! :)

>
> Cheers

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

[yocto] Auto builder

[akuster808]

Hello all,

Are there any plans on tagging the autobuilder and any other sources
used to create and test the 2.0 release? It would be nice to try to
avoid the issues we ran into earlier this year with a Dizzy release that
has repressions.

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

Re: [yocto] opkg 0.3.0 or rootfs task

[Ahsan, Noor]

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ahsan, Noor
Sent: Friday, October 16, 2015 11:55 PM
To: Khem Raj
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] opkg 0.3.0 or rootfs task



From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Friday, October 16, 2015 9:54 PM
To: Ahsan, Noor
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] opkg 0.3.0 or rootfs task


On Oct 16, 2015, at 5:47 AM, Ahsan, Noor 
mailto:noor_ah...@mentor.com>> wrote:

Hello,

I noticed that at the time of rootfs creation symbolic links of the ipk files 
present in deploy/ipk. The problem what have it while creation of symbolic link 
it take the full path till that ipk and remove slashes and convert them into 
underscores. Use that as the name of the symbolic link. This make a very long 
file names. If we have very long path then name of the symlink exceed from max 
filename limits. And we get following error

Collected errors:
* file_link: unable to stat 
`/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
 File name too long.

Can anyone tell me why the addition of full path was added to the symlink name 
and can we remove it cause it is cause issues?

what does

getconf PATH_MAX /

show ?

jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
PATH_MAX   4096
_POSIX_PATH_MAX4096


I think the issue is with file name not the path.

Secondly the googling which I did reveals that symlink creation can't be 
stopped. I just wanna confirm that is my findings correct?

Noor
--
___
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] RFC: Yocto LTS?

[akuster]

On 10/15/15 8:49 AM, Philip Balister wrote:
> On 10/14/2015 12:26 PM, Chris Simmonds wrote:
>>
>> On 14/10/15 17:27, Mark Hatle wrote:
>>> On 10/14/15 8:28 AM, Chris Simmonds wrote:
 Hi,

 Is there a statement about the period of support for a Yocto release?
 Looking through the updates, it seems that 12 months is typical, a was
 the case for 1.4, 1.5 and 1.6 for example, but I cannot see a
 declaration anywhere that this is the expected norm.

 Leading on from that, is 12 months enough? Most projects have a
 lifecycle that is much longer. Is there an argument for an LTS Yocto
 release, maybe once a year? If not, what is the recommended way for a
 project developer to keep a distribution up to date in the light of the
 several well-publicised security flaws that have been discovered over
 the last year or so and the new ones that will no doubt be discovered in
 the future?
>>>
>>> https://wiki.yoctoproject.org/wiki/FAQ#What_is_the_overall_support_plan_for_the_Yocto_Project.3F
>>>
>>> =What is the release cycle of the Yocto Project?=
>>> Each release of the Yocto Project is subject to its own release schedule
>>> according to the community-maintained Project Planning Guide. It is 
>>> generally
>>> expected that a new version of the Yocto Project will be released every six 
>>> months.
>>>
>>> =What is the overall support plan for the Yocto Project?=
>>> Security patches and critical bug fixes are supplied one release back. No
>>> toolchain or kernel changes are allowed for these updates. Support for 
>>> longer
>>> periods of time can be supplied by commercial OSVs.
>>>
>>>
>>>
>>> Effectively this means that support is on the last two releases.  Releases 
>>> are
>>> typically released every 6 months.  After that point it is usually 
>>> supported by
>>> OSVs, or others that offer commercial services.  In the past we have done a 
>>> few
>>> very late security fixes past the 'last two releases' point, however that 
>>> has
>>> been for unique situations.
>>>
>>> You should consider keeping current with the Yocto Project releases or 
>>> consider
>>> commercial support if you need more then an approx 12 - 18 month support 
>>> cycle.
>>>
>>> --Mark
>>>
>>
>> Thanks, that is all clear now.
> 
> We wouldn't be opposed to a group of people supporting a release for
> longer. But they would need to provide the people to do the work. LTS
> work is hard.

Not to mention keeping build infrastructure setup, copies of supported
OS working, QA and Target machines working. As an OSV, its not uncommon
to support a distro for 10 or more years.

- Armin
> 
> Philip
> 
>>
>> Chris
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Nightly build and world build

[atulkumar singh]

Hi All,

I am going through the mailing list and I found some communication related
to world build and nightly build.
I even search in the documentation regarding the same but didn't found any
useful information regarding the same.
Can anyone please tel me what is nightly build and world build and what is
the difference between the same.

Thanks in advance...

Regards,
Atul kumar singh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Queries regarding yocto dual booting

[Debasmita Lohar]

The messages it is showing are:
booting from cd...
iso linux boot: loading /vmlinux
loading initrd
trying to unpack rootfs
switched to clock source.
mounted file system.
After that it is showing yocto project and enters into the desktop.
It may be noted that I am using the iso file downloaded from terasic
website.
I need to install yocto in de2i-150 terasic board.

Debasmita Lohar
MS Student
Computer Science and Engineering
IIT Kharagpur


On Fri, Oct 16, 2015 at 10:17 PM, Khem Raj  wrote:

>
> > On Oct 16, 2015, at 12:22 AM, Debasmita Lohar 
> wrote:
> >
> > Hello,
> > I am using De2i-150 board which provides a yocto iso. I have installed
> puppy linux before yocto and now I want to install yocto in the unallocated
> portion. Basically I want dual booting. But when I tried to install yocto,
> it just started from the live cd and did not show me any install option.
> Please help me regarding this issue.
>
> there are few seconds when the syslinux prompt appears. You need to type
> in "install"
>
> > Thank you.
> >
> > Debasmita Lohar
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto