Re: [yocto] Question about Package Splitting
Hi,
You can do something like this if you want your own package:
PACKAGES += ${PN}-frontend ${PN}-backend ${PN}-tests
Here ${PN} means project and yes project-dbg and project-dev will be
created by default.
And than you can put your required files in particular package by,
FILES_${PN}-frontend = ${bindir} -- just example...likewise you can have
your own packages with required files.
//Gaurang Shastri
On Fri, Aug 8, 2014 at 4:17 AM, pourya.shiraz...@daimler.com wrote:
Hi,
My question is about producing multiple packages in the same recipe.
I created a recipe e.g. “project.bb to produce 5 packages from the same
source repository. The package names are as following:
1. project-frontend
2. project-backend
3. project-tests
4. project-dbg
5. project-dev
How do I include these packages in the assembled file system? I.e. Should
I just include “project” as the parent name for all the sub-packages or I
should include “project-frontend”, “project-end” etc.
When I tried the latter method only the first package appeared in the
final file system.
Thanks
If you are not the addressee, please inform us immediately that you have
received this e-mail by mistake, and delete it. We thank you for your
support.
--
___
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: Improving the developer workflow
On Thu, Aug 7, 2014 at 3:05 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Personally with how fragile package management can end up being, I'm convinced that full-image updates are the way to go for a lot of cases, but ideally with some intelligence so that you only ship the changes (at a filesystem level rather than a package or file level). This ensures that an upgraded image on one device ends up exactly identical to any other device including a newly deployed one. Of course it does assume that you have a read-only rootfs and keep your configuration data / logs / other writeable data on a separate partition or storage medium. However, beyond improvements to support for having a read-only rootfs we haven't really achieved anything in terms of out- of-the-box support for this, mainly due to lack of resources. However, whilst I haven't had a chance to look at it closely, there has been some work on this within the community: http://sbabic.github.io/swupdate/swupdate.html https://github.com/sbabic/swupdate https://github.com/sbabic/meta-swupdate/ fwiw, Ubuntu has started to do something like that for their phone images, see https://wiki.ubuntu.com/ImageBasedUpgrades I haven't used nor looked into the details... i just had heard about it, and thought it was worth mentioning it here. however the main design idea from that wiki page is exactly what we are discussing here. e.g. build images on the 'server' side using our regular tools, but deploy binary differences on targets. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] RFC: Improving the developer workflow
On Thu, Aug 7, 2014 at 11:10 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Example workflow I won't give a workflow for every possible usage, but just to give a basic example - let's assume you want to build a new piece of software for which you have your own source tree on your machine. The rough set of steps required would be something like this (rough, e.g. the command names given shouldn't be read as final): 1. Install the SDK 2. Run a setup script to make the SDK tools available 3. Add a new recipe with sdktool add recipename - interactive process. The tool records that recipename is being worked on, creates a recipe that can be used to build the software using your external source tree, and places the recipe where it will be used automatically by other steps. 4. Build the recipe with sdktool build recipename. This probably only goes as far as do_install or possibly do_package_qa; in any case the QA process would be less stringent than with the standard build system however in order to avoid putting too many barriers in the way of testing on the target. 5. Fix any failures and repeat from the previous step as necessary. 6. Deploy changes to target with sdktool deploy-target ip address assuming SSH is available on the target. Alternatively sdktool build-image imagename can be used to regenerate an image with the changes in it; sdktool runqemu could do that (if necessary) and then run the result within QEMU with the appropriate options set. coincidentally, i was giving an OE workshop this week, and when I explained about the OE SDK, someone immediately brought up that it was quite limited because: 1- SDK cannot be used to generate deployable packages, e.g. using the SDK to create ipk/deb/rpm that can be delivered to targets/clients, not just for debugging, but also for production when production system has package management support. 2- SDK cannot be used to regenerate updated images. e.g. Company A delivers a SDK + board, Company B is making a product using the SDK (adding content) and wants to be able to make new images with the new content in order to sell/deploy it. 3- SDK itself cannot be upgraded when the 'base image' and SDK are updated 4- SDK users cannot add content to the SDK. e.g. I am a SDK user I create a library and I want that library to be in the SDK now. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Question about Package Splitting
On Fri, Aug 8, 2014 at 9:43 AM, Gaurang Shastri gmshas...@gmail.com wrote:
You can do something like this if you want your own package:
PACKAGES += ${PN}-frontend ${PN}-backend ${PN}-tests
Here ${PN} means project and yes project-dbg and project-dev will be
created by default.
And than you can put your required files in particular package by,
FILES_${PN}-frontend = ${bindir} -- just example...likewise you can have
your own packages with required files.
and in addition to that:
http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#splitting-an-application-into-multiple-packages
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Assembling images to build a NOR boot image
On Thu, Aug 7, 2014 at 7:07 PM, Renaud Barbier renaud.barb...@ge.com wrote: Hello, I am working on the creation of a boot image for a NOR flash. The image assembles a boot loader and a ubi image containing the kernel and device tree. So far I have created a build area to install the kernel and device tree and used IMAGE_CMD_ubi to create the ubi image. Then I have added a python function do_norbuild that puts together the boot loader and ubi image and adds padding. Using bitbake, I can create the NOR image as follows: bitbake -c norbuild core-image However, bitbake core-image will not call the norbuild task. I have been through quite a lot of code and documentation and cannot figure out why the task is not called. If you have any idea of what couldbe wrong, please le me know. you seem to have created a task, not just a Python function, since you can run it with -c norbuild. By default when running bitbake recipe, bitbake will run do_build task. so when you create your own custom task, you need to insert it into the task list, maybe you haven't done that? something like this should work in your case: addtask norbuild before do_build after do_rootfs alternatively, instead of creating your own task, you could use the existing do_rootfs hook: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-ROOTFS_POSTPROCESS_COMMAND -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][yocto-docs] Ref manual, ch 15 -- minor link changes, grammar.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- i'm guessing that the OE wiki page for bitbake is the closest thing there is to an official bitbake web page, so i'll just use that as a replacement for all berlios.de links i run across, unless someone has a better suggestion. diff --git a/documentation/ref-manual/resources.xml b/documentation/ref-manual/resources.xml index 686b48a..17b8e97 100644 --- a/documentation/ref-manual/resources.xml +++ b/documentation/ref-manual/resources.xml @@ -54,6 +54,8 @@ announcements./para/listitem /itemizedlist /para +For more Yocto Project-related mailing lists, see the Yocto Project community mailing lists page +ulink url='YOCTO_HOME_URL;/tools-resources/community/mailing-lists'here/ulink. /section section id='resources-irc' @@ -80,7 +82,7 @@ Project./para/listitem listitemparaemphasis ulink url='http://www.intel.com/'Intel Corporation/ulink:/emphasis -The company who acquired OpenedHand in 2008 and began +The company that acquired OpenedHand in 2008 and began development on the Yocto Project./para/listitem listitemparaemphasis ulink url='OE_HOME_URL;'OpenEmbedded/ulink:/emphasis @@ -89,7 +91,7 @@ Poky derives from and contributes back to the OpenEmbedded project./para/listitem listitemparaemphasis -ulink url='http://developer.berlios.de/projects/bitbake/' +ulink url='http://www.openembedded.org/wiki/BitBake' BitBake/ulink:/emphasis The tool used to process metadata./para/listitem listitemparaemphasis ulink url='YOCTO_DOCS_BB_URL;'BitBake User Manual/ulink:/emphasis @@ -116,7 +118,7 @@ pull requests, or by submitting patches through email. For information on how to do both as well as information on how -to find out who is the maintainer for areas of code, see the +to identify the maintainer for each area of code, see the ulink url='YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'How to Submit a Change/ulink section in the Yocto Project Development Manual. /para -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building yocto for Odroid XU. No login after boot.
Problem solved. It was an error in the boot.ini (u-boot).
Changing the SERIAL_CONSOLE or kernel config params (like
CONFIG_FHANDLE=y) did not change much. Problem was hidden in the boot
params.
In the boot.ini I used
setenv bootcmd fatload mmc 0:1 0x40008000 zImage; fatload mmc 0:1
0x4200 uInitrd; bootz 0x40008000 0x4200
which caused the problem (although uInitrd was present).
I changed this line to
fatload mmc 0:1 0x40008000 zImage; bootz 0x40008000
and now I can log in (using systinitv or systemd, doesn't matter). Dunno
why, but maybe the solution helps somebody.
Cheers,
Markus
On 07.08.2014 15:05, Gary Thomas wrote:
On 2014-08-07 06:51, Dr. Markus Eich wrote:
Hi Gary,
unfortunately, this didn't help much. I have compiled the kernel with
the CONFIG_FHANDLE=y.
I have also set all configs given in
http://dominion.thruhere.net/koen/cms/recommended-kernel-config-options-for-a-modern-angstrom-system
To pinpoint the error down, I have tried the kernel build from Yocto
on a LINARO distro image. I have just replaced the kernel and the
modules build with yocto.
And voila: I have a login promt. If the complete distro is build with
Yocto (the whole rootfs), I cannot log in.
Has setting the SERIAL_CONSOLE = 115200 ttymxc0 the same effect as
giving the console param for the u-boot?
i.e. I have something like
#setenv bootrootfs console=tty1 console=ttySAC2,115200n8
root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait rw ?
Setting SERIAL_CONSOLE tells the build system (Yocto) what device to
use as the main console. A login prompt will appear on this device
after bootup. The 'console=XXX' settings to the kernel (from U-Boot)
tell the kernel where to send messages, especially the bootstrap
messages.
These are subtly different uses but they should match.
In your case, I think you should have
SERIAL_CONSOLE = 115200 ttySAC2
On 06.08.2014 18:26, Gary Thomas wrote:
On 2014-08-06 10:13, Dr. Markus Eich wrote:
Dear all,
I am trying to build an image for the Odroid XU, featuring the
Samsung Octa 5 CPU
I managed to build everything needed (modules, kernel, u-boot, etc.)
The recipes can be found at:
https://github.com/MarkusEich/meta-odroid.
The last problem (hopefully last :-) I have is that I cannot log in
after the kernel is loaded via UART console
Maybe init.d or systemd is not setup properly?
I am using the console-image-minimal.bb from meta.
Here is the last console output. It seems that the kernel is loaded
(including modules) and the rootfs is properly mounted. There is no
error, there is simply no login or shell.
Any ideas why I cannot login? Its a bit poking in the dark ATM.
If you are using systemd, make sure your kernel is built with
CONFIG_FHANDLE=y
Without this, systemd won't start a session on a serial port.
If you're using the old sysvinit, make sure your console settings
are correct. These normally live in your ${MACHINE}.conf and look
something like this:
SERIAL_CONSOLE = 115200 ttymxc0
You might also want to remove 'quiet' from your kernel bootargs,
at least until you get things settled a bit more.
==
[5.722795] CPUFREQ of CA7 L5 : 962500 uV
[5.726871] CPUFREQ of CA7 L6 : 95 uV
[5.730947] CPUFREQ of CA7 L7 : 95 uV
[5.735025] CPUFREQ of CA7 L8 : 95 uV
[5.739095] CPUFREQ of CA7 L9 : 95 uV
[5.743146] CPUFREQ of CA7 L10 : 95 uV
[5.747336] CPUFREQ of CA7 L11 : 95 uV
[5.751583] CPUFREQ of CA15 L0 : 1362500 uV
[5.755663] CPUFREQ of CA15 L1 : 1362500 uV
[5.759826] CPUFREQ of CA15 L2 : 1225000 uV
[5.764012] CPUFREQ of CA15 L3 : 1175000 uV
[5.768129] CPUFREQ of CA15 L4 : 1137500 uV
[5.772313] CPUFREQ of CA15 L5 : 1112500 uV
[5.776474] CPUFREQ of CA15 L6 : 1075000 uV
[5.780638] CPUFREQ of CA15 L7 : 1037500 uV
[5.784800] CPUFREQ of CA15 L8 : 100 uV
[5.788962] CPUFREQ of CA15 L9 : 975000 uV
[5.793010] CPUFREQ of CA15 L10 : 937500 uV
[5.797201] CPUFREQ of CA15 L11 : 912500 uV
[5.801368] CPUFREQ of CA15 L12 : 90 uV
[5.805526] CPUFREQ of CA15 L13 : 90 uV
[5.809689] CPUFREQ of CA15 L14 : 90 uV
[5.813822] CPUFREQ of CA15 L15 : 90 uV
[5.818018] CPUFREQ of CA15 L16 : 90 uV
[5.822173] CPUFREQ of CA15 L17 : 90 uV
[5.826338] CPUFREQ of CA15 L18 : 90 uV
[5.830583] fout_apll[9]
[5.836287] S divider change for DFS of MIF block
[5.984276] init_volt[975000], freq[80]
[5.987809] ALSA device list:
[5.989956] #0: Odroid-max98090
[5.993533] Freeing init memory: 256K
[5.996898] Write protecting the kernel text section c0008000 -
c09e2000
[6.003931] rodata_test: attempting to write to read-only section:
[6.009728] write to read-only section trapped, success
[6.055010] systemd-udevd[1299]: starting version 204
[6.350360] EXT4-fs (mmcblk0p2): recovery complete
[6.356827] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
Re: [yocto] Installing Application Development SDK hangs when using screen
Hi Mark, This is on Daisy branch. On Dylan branch I didn't experience such trouble. It came up with Daisy. Regards -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Mark Hatle Sent: jeudi 7 août 2014 12:19 To: yocto@yoctoproject.org Subject: Re: [yocto] Installing Application Development SDK hangs when using screen On 8/7/14, 8:59 AM, Pierre Yves MORDRET wrote: Hi there, I have a tricky issue to sort out. I'm using a build server(Ubuntu 12.04 LTS) for building my Yocto project and Application Dev SDK (bitbake -c populate_sdk). On this build server I 'm used to using screen tool. Using screen and bitbake at the same time seems to have no issues. However when installing the App. Dev. SDK via self-installer, it hangs every time after a while. The culprit seems to be screen. If I am IN a screen session OR I am OUT screen session but there is a running screen session that belongs to me, it hangs. Did someone experience such trouble ? Any ideas ? I've seen some terminal failures in the past, but it's always been due to overwriting in-place terminal files. I've not seen anything on a new SDK installation. Which branch of the Yocto Project are you using? --Mark Thanks in advance Pierre-Yves -- ___ 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] No network at startup using core-image-minimal
Dear all, I am setting up my Odroid XU with yocto using the core-image-minimal receipe. Almost done and I am able to boot the system and log in via screen (UART), but.. The network is not present at start-up. When I do lsmod I just see Not tainted and no modules are loaded. The module I need to load is the smsc95xx module. When I tried to load the driver with modpobe it could not find the driver (although it is in /lib/modules/3.4.98-custom/kernel/drivers/net/usb) I had to manually add it to /lib/modules/3.4.98-custom/modules.dep (which was empty after the bitbake process in rootfs) So I added kernel/drivers/net/usb/smsc95xx.ko: to modules.dep. Then I could load it with modprobe. In order to load it at startup I created a /etc/modules with the content smsc95xx. Now my question: Is there an easier (bitbake) way to make the modules load at startup without editing configs on the target device? Am I missing something? Does core-image-minimal not include network? Cheers, Markus -- Dr.-Ing. Markus Eich Senior Researcher Marine Inspection Robotics Space Robotics Besuchsadresse der Nebengeschäftstelle: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 5 28359 Bremen, Germany Postadresse der Hauptgeschäftsstelle Standort Bremen: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 1 28359 Bremen, Germany Tel.: +49 421 178 45-4105 Zentrale: +49 421 178 45-0 Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen) E-Mail: markus.e...@dfki.de Weitere Informationen: http://www.dfki.de/robotik --- Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.:DE 148646973 Steuernummer: 19/673/0060/3 --- -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] No network at startup using core-image-minimal
Hi Markus, Please try core-image-base instead of core-image-minimal. That should provide you with the necessary network support. Best regards, Rudi On Aug 8, 2014 6:46 AM, Dr. Markus Eich markus.e...@dfki.de wrote: Dear all, I am setting up my Odroid XU with yocto using the core-image-minimal receipe. Almost done and I am able to boot the system and log in via screen (UART), but.. The network is not present at start-up. When I do lsmod I just see Not tainted and no modules are loaded. The module I need to load is the smsc95xx module. When I tried to load the driver with modpobe it could not find the driver (although it is in /lib/modules/3.4.98-custom/kernel/drivers/net/usb) I had to manually add it to /lib/modules/3.4.98-custom/modules.dep (which was empty after the bitbake process in rootfs) So I added kernel/drivers/net/usb/smsc95xx.ko: to modules.dep. Then I could load it with modprobe. In order to load it at startup I created a /etc/modules with the content smsc95xx. Now my question: Is there an easier (bitbake) way to make the modules load at startup without editing configs on the target device? Am I missing something? Does core-image-minimal not include network? Cheers, Markus -- Dr.-Ing. Markus Eich Senior Researcher Marine Inspection Robotics Space Robotics Besuchsadresse der Nebengeschäftstelle: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 5 28359 Bremen, Germany Postadresse der Hauptgeschäftsstelle Standort Bremen: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 1 28359 Bremen, Germany Tel.: +49 421 178 45-4105 Zentrale: +49 421 178 45-0 Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen) E-Mail: markus.e...@dfki.de Weitere Informationen: http://www.dfki.de/robotik --- Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.:DE 148646973 Steuernummer: 19/673/0060/3 --- -- ___ 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: Improving the developer workflow
Hi Paul, Personally with how fragile package management can end up being, I'm convinced that full-image updates are the way to go for a lot of cases, but ideally with some intelligence so that you only ship the changes (at a filesystem level rather than a package or file level). This ensures that an upgraded image on one device ends up exactly identical to any other device including a newly deployed one. Of course it does assume that you have a read-only rootfs and keep your configuration data / logs / other writeable data on a separate partition or storage medium. However, beyond improvements to support for having a read-only rootfs we haven't really achieved anything in terms of out- of-the-box support for this, mainly due to lack of resources. However, whilst I haven't had a chance to look at it closely, there has been some work on this within the community: http://sbabic.github.io/swupdate/swupdate.html https://github.com/sbabic/swupdate https://github.com/sbabic/meta-swupdate/ I had a quick look at this. It's interesting. If I am reading this correctly it's based on the old - Bootloader runs Partition A - Update Partition B, set Bootloader to run Partition B - On failure stay on partition A and retry update. - Bootloader runs Partition B - Update Partition A, set Bootloader to run Partition A - etc. We've done this type of thing before and it works well. Of course the drawback is the amount of flash you need to achieve it but it is a good robust system. I'd be interested to see how this could work with filesystem deltas say. I don't _think_ that is documented here? ... Thinking a little further what would also really interest me would be to consider using the transactionality of the underlying file-system or block-management layer for the update process. Given nowadays journalling and log-structure file-systems are already designed to fail-back when file/meta-data modifications are interrupted surely we should be able to start a macro-transaction point at the start of the partition update, and if that update doesn't complete with a macro-commit then the f/s layer should be able to automatically roll itself back? Perhaps the same could be done at a block management layer? Cheers, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Errors when installing SDK
I built an SDK (using populate_sdk) from the latest master.
When I tried to install it, I got a ton of errors:
root@Zeus:~# /work/tmp/poky-eglibc-i686-arm-toolchain-1.6+snapshot-20140808.sh
Enter target directory for SDK (default: /opt/poky/1.6+snapshot-20140808):
You are about to install the SDK to /opt/poky/1.6+snapshot-20140808.
Proceed[Y/n]?
Extracting SDK...done
Setting it up...xargs: argument line too long
find: `file' terminated by signal 13
find: `file' terminated by signal 13
...
find: `file' terminated by signal 13
When I looked into this, it's happening in the relocate_sdk.sh script.
Here are the relevant lines (via -D):
+ /opt/poky/1.6+snapshot-20140808/relocate_sdk.sh
+ '[' 0 -ne 0 ']'
+ find /opt/poky/1.6+snapshot-20140808/sysroots/i686-pokysdk-linux -type f
-exec file '{}' ';'
+ grep ':.*\(ASCII\|script\|source\).*text'
+ awk -F: '{printf %s\0, $1}'
+ xargs -0 sed -i -e
s:/opt/poky/1.6+snapshot-20140808:/opt/poky/1.6+snapshot-20140808:g
xargs: argument line too long
Since I'm not relocating the SDK, can I just ignore these errors?
Wouldn't it be a bit safer to use 'xargs -n256 ...' to limit the
command line length?
Note: I'm not sure where the 'relocate_sdk.sh' script comes from
or else I'd give it a go myself.
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oracle-java][PATCH 0/5] Add a custom fetch method
At present,to use meta-oracle-java layer, we need to manually download the Oracle Java Binaries and place it in download location. Provide a custom fetch method to avoid that manual step. Maxin B. John (5): README: Update Notes oracle-jse-jdk-i586: add custom fetch method oracle-jse-jdk-x86-64: add custom fetch method oracle-jse-jre-i586: add custom fetch method oracle-jse-jre-x86-64: add custom fetch method README | 16 .../oracle-java/oracle-jse-jdk-i586_1.7.0.bb | 9 - .../oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb | 9 - .../oracle-java/oracle-jse-jre-i586_1.7.0.bb | 10 +- .../oracle-java/oracle-jse-jre-x86-64_1.7.0.bb | 10 +- 5 files changed, 42 insertions(+), 12 deletions(-) -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oracle-java][PATCH 1/5] README: Update Notes
1. Remove notes related to manual downloading of Oracle Java binaries 2. Add notes about the temporary fix for installing JRE packages Signed-off-by: Maxin B. John maxin.j...@enea.com --- README | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README b/README index 7dea1ea..3f4e177 100644 --- a/README +++ b/README @@ -19,14 +19,14 @@ LICENSE_FLAGS_WHITELIST += oracle_java Notes = -The download URLs mentioned in the SRCURI of the oracle-java recipes -may show fetch issues with the built in bitbake wget fetcher. This is caused -by the pre-requirement of clicking the accept license button on the oracle -download webpage. So if you see fetch issues for the oracle java recipes, -then you can overcome the issue by opening the SRCURI links manually in a web -browser, downloading the tarballs, and storing in the bitbake download -location. And the bitbake download location is specified by DL_DIR variable -in build configuration file (conf/local.conf) +There are some known install problems for JRE packages due to dependencies +reported by RPM package manager. Switching to DEB or IPK packaging temporarily +fixes this. +ie: +PACKAGE_CLASSES = package_deb +or +PACKAGE_CLASSES = package_ipk +in your 'local.conf' file Where to Send Patches = -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oracle-java][PATCH 5/5] oracle-jse-jre-x86-64: add custom fetch method
Provide a custom fetch method to avoid manual downloading of binaries.
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
b/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
index 4058d23..cdedaf1 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
@@ -1,4 +1,3 @@
-PR = r0
PV_UPDATE = 25
require oracle-jse-jre.inc
@@ -7,3 +6,12 @@ SRC_URI =
http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jre-7u25-linux-x
SRC_URI[md5sum] = 743ee0ebf73ce428c912866d84e374e0
SRC_URI[sha256sum] =
3c4496316fb413d5ab0590e9971676a521b9a600b3ceaac311f04c18c98a98c0
+
+RDEPENDS_${PN} = libxml2 libx11 glib-2.0 alsa-lib libxext libxtst libxrender \
+ fontconfig libxxf86vm
+
+do_fetch () {
+ wget --header=Cookie:oraclelicense=a ${SRC_URI} -O
${DL_DIR}/jre-7u25-linux-x64.tar.gz
+}
+
+COMPATIBLE_HOST = '(x86_64.*)-(linux)'
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oracle-java][PATCH 2/5] oracle-jse-jdk-i586: add custom fetch method
Provide a custom fetch method to avoid manual downloading of binaries.
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
b/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
index 978fbd5..282aa43 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
@@ -1,4 +1,3 @@
-PR = r0
PV_UPDATE = 25
require oracle-jse-jdk.inc
@@ -7,3 +6,11 @@ SRC_URI =
http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jdk-7u25-linux-i
SRC_URI[md5sum] = 23176d0ebf9dedd21e3150b4bb0ee776
SRC_URI[sha256sum] =
dd89b20afa939992bb7fdc44837fa64f0a98d7ee1e5706fe8a2d9e2247ba6de7
+
+RDEPENDS_${PN} = libxml2 libx11 glib-2.0 alsa-lib libxext libxtst libxrender
+
+do_fetch () {
+ wget --header=Cookie:oraclelicense=a ${SRC_URI} -O
${DL_DIR}/jdk-7u25-linux-i586.tar.gz
+}
+
+COMPATIBLE_HOST = '(i.86.*)-(linux)'
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oracle-java][PATCH 4/5] oracle-jse-jre-i586: add custom fetch method
Provide a custom fetch method to avoid manual downloading of binaries.
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
b/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
index 6125025..1fca3a8 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
@@ -1,4 +1,3 @@
-PR = r0
PV_UPDATE = 25
require oracle-jse-jre.inc
@@ -7,3 +6,12 @@ SRC_URI =
http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jre-7u25-linux-i
SRC_URI[md5sum] = 0e9ccefe49e937e592dbb605f2e8e7d8
SRC_URI[sha256sum] =
4016965536d8607743267812ab04e6d428036dda432893748c1df6cb77b09628
+
+RDEPENDS_${PN} = libxml2 libx11 glib-2.0 alsa-lib libxext libxtst libxrender \
+ fontconfig libxxf86vm
+
+do_fetch () {
+ wget --header=Cookie:oraclelicense=a ${SRC_URI} -O
${DL_DIR}/jre-7u25-linux-i586.tar.gz
+}
+
+COMPATIBLE_HOST = '(i.86.*)-(linux)'
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oracle-java][PATCH 3/5] oracle-jse-jdk-x86-64: add custom fetch method
Provide a custom fetch method to avoid manual downloading of binaries.
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
b/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
index 7979401..6ee2002 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
@@ -1,4 +1,3 @@
-PR = r0
PV_UPDATE = 25
require oracle-jse-jdk.inc
@@ -7,3 +6,11 @@ SRC_URI =
http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jdk-7u25-linux-x
SRC_URI[md5sum] = 83ba05e260813f7a9140b76e3d37ea33
SRC_URI[sha256sum] =
f80dff0e19ca8d038cf7fe3aaa89538496b80950f4d10ff5f457988ae159b2a6
+
+RDEPENDS_${PN} = libxml2 libx11 glib-2.0 alsa-lib libxext libxtst libxrender
+
+do_fetch () {
+ wget --header=Cookie:oraclelicense=a ${SRC_URI} -O
${DL_DIR}/jdk-7u25-linux-x64.tar.gz
+}
+
+COMPATIBLE_HOST = '(x86_64.*)-(linux)'
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors when installing SDK
On 8/8/14, 11:13 AM, Gary Thomas wrote:
I built an SDK (using populate_sdk) from the latest master.
When I tried to install it, I got a ton of errors:
root@Zeus:~#
/work/tmp/poky-eglibc-i686-arm-toolchain-1.6+snapshot-20140808.sh
Enter target directory for SDK (default: /opt/poky/1.6+snapshot-20140808):
You are about to install the SDK to /opt/poky/1.6+snapshot-20140808.
Proceed[Y/n]?
Extracting SDK...done
Setting it up...xargs: argument line too long
find: `file' terminated by signal 13
find: `file' terminated by signal 13
...
find: `file' terminated by signal 13
When I looked into this, it's happening in the relocate_sdk.sh script.
Here are the relevant lines (via -D):
+ /opt/poky/1.6+snapshot-20140808/relocate_sdk.sh
+ '[' 0 -ne 0 ']'
+ find /opt/poky/1.6+snapshot-20140808/sysroots/i686-pokysdk-linux -type f
-exec file '{}' ';'
+ grep ':.*\(ASCII\|script\|source\).*text'
+ awk -F: '{printf %s\0, $1}'
+ xargs -0 sed -i -e
s:/opt/poky/1.6+snapshot-20140808:/opt/poky/1.6+snapshot-20140808:g
xargs: argument line too long
Since I'm not relocating the SDK, can I just ignore these errors?
Wouldn't it be a bit safer to use 'xargs -n256 ...' to limit the
command line length?
Note: I'm not sure where the 'relocate_sdk.sh' script comes from
or else I'd give it a go myself.
You will end up relocating the SDK, even if you use the default install path.
Just the nature of how we had to implement the relocation.
And yes, I suspect the right answer is we need to set a limit on the xargs.
(I'm kind of surprised that we didn't already have a limit set!)
--Mark
Thanks
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors when installing SDK
On 2014-08-08 10:57, Mark Hatle wrote:
On 8/8/14, 11:13 AM, Gary Thomas wrote:
I built an SDK (using populate_sdk) from the latest master.
When I tried to install it, I got a ton of errors:
root@Zeus:~#
/work/tmp/poky-eglibc-i686-arm-toolchain-1.6+snapshot-20140808.sh
Enter target directory for SDK (default: /opt/poky/1.6+snapshot-20140808):
You are about to install the SDK to /opt/poky/1.6+snapshot-20140808.
Proceed[Y/n]?
Extracting SDK...done
Setting it up...xargs: argument line too long
find: `file' terminated by signal 13
find: `file' terminated by signal 13
...
find: `file' terminated by signal 13
When I looked into this, it's happening in the relocate_sdk.sh script.
Here are the relevant lines (via -D):
+ /opt/poky/1.6+snapshot-20140808/relocate_sdk.sh
+ '[' 0 -ne 0 ']'
+ find /opt/poky/1.6+snapshot-20140808/sysroots/i686-pokysdk-linux -type f
-exec file '{}' ';'
+ grep ':.*\(ASCII\|script\|source\).*text'
+ awk -F: '{printf %s\0, $1}'
+ xargs -0 sed -i -e
s:/opt/poky/1.6+snapshot-20140808:/opt/poky/1.6+snapshot-20140808:g
xargs: argument line too long
Since I'm not relocating the SDK, can I just ignore these errors?
Wouldn't it be a bit safer to use 'xargs -n256 ...' to limit the
command line length?
Note: I'm not sure where the 'relocate_sdk.sh' script comes from
or else I'd give it a go myself.
You will end up relocating the SDK, even if you use the default install path.
Just the nature of how we had to implement the relocation.
And yes, I suspect the right answer is we need to set a limit on the xargs.
(I'm kind of surprised that we didn't already have a limit set!)
If you can point me at where that file comes from (a simple
search didn't help), I'll give it a try and propose a patch.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors when installing SDK
Hi Gary, On Friday 08 August 2014 11:11:19 Gary Thomas wrote: On 2014-08-08 10:57, Mark Hatle wrote: And yes, I suspect the right answer is we need to set a limit on the xargs. (I'm kind of surprised that we didn't already have a limit set!) If you can point me at where that file comes from (a simple search didn't help), I'll give it a try and propose a patch. It's in meta/classes/populate_sdk_base.bbclass (there's only one instance of xargs in there). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installing Application Development SDK hangs when using screen
You're right this has solved my issue ! I keep it as patch in my side and waiting it in daisy branch Thanks ! -Original Message- From: Mark Hatle [mailto:mark.ha...@windriver.com] Sent: vendredi 8 août 2014 10:09 To: Pierre Yves MORDRET; yocto@yoctoproject.org Subject: Re: [yocto] Installing Application Development SDK hangs when using screen On 8/8/14, 8:21 AM, Pierre Yves MORDRET wrote: Hi Mark, This is on Daisy branch. On Dylan branch I didn't experience such trouble. It came up with Daisy. (I haven't used Daisy very much... but...) There was a bug in the master version of the SDK installer that was displaying special characters to the screen in some instances. It caused what appeared to be a lockup on my screen for a while, but it was actually just taking a very long time to complete the operation, then a 'return' would allow the prompt to come back. This was recently fixed by a commit from Richard 2d1660112e54653f7bb763939d0416472c49fe01 If you can, cherry-pick that commit from master into your Daisy branch and try again. If this works, we should get that submitted to Daisy. --Mark Regards -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Mark Hatle Sent: jeudi 7 août 2014 12:19 To: yocto@yoctoproject.org Subject: Re: [yocto] Installing Application Development SDK hangs when using screen On 8/7/14, 8:59 AM, Pierre Yves MORDRET wrote: Hi there, I have a tricky issue to sort out. I'm using a build server(Ubuntu 12.04 LTS) for building my Yocto project and Application Dev SDK (bitbake -c populate_sdk). On this build server I 'm used to using screen tool. Using screen and bitbake at the same time seems to have no issues. However when installing the App. Dev. SDK via self-installer, it hangs every time after a while. The culprit seems to be screen. If I am IN a screen session OR I am OUT screen session but there is a running screen session that belongs to me, it hangs. Did someone experience such trouble ? Any ideas ? I've seen some terminal failures in the past, but it's always been due to overwriting in-place terminal files. I've not seen anything on a new SDK installation. Which branch of the Yocto Project are you using? --Mark Thanks in advance Pierre-Yves -- ___ 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] yocto ref manual seems skimpy on task flags
just noticed that the yocto reference manual has no mention whatever of various task flags like recrdeptask. is that a missing section? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-oracle-java][PATCH 4/5] oracle-jse-jre-i586: add custom fetch method
On Fri, Aug 8, 2014 at 9:39 AM, Maxin B. John maxin.j...@enea.com wrote:
Provide a custom fetch method to avoid manual downloading of binaries.
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
b/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
index 6125025..1fca3a8 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
@@ -1,4 +1,3 @@
-PR = r0
PV_UPDATE = 25
require oracle-jse-jre.inc
@@ -7,3 +6,12 @@ SRC_URI =
http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jre-7u25-linux-i
SRC_URI[md5sum] = 0e9ccefe49e937e592dbb605f2e8e7d8
SRC_URI[sha256sum] =
4016965536d8607743267812ab04e6d428036dda432893748c1df6cb77b09628
+
+RDEPENDS_${PN} = libxml2 libx11 glib-2.0 alsa-lib libxext libxtst
libxrender \
+ fontconfig libxxf86vm
+
+do_fetch () {
+ wget --header=Cookie:oraclelicense=a ${SRC_URI} -O
${DL_DIR}/jre-7u25-linux-i586.tar.gz
+}
could we just override FETCHCMD_wget for this recipe ?
+
+COMPATIBLE_HOST = '(i.86.*)-(linux)'
--
1.9.1
--
___
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-oracle-java][PATCH 4/5] oracle-jse-jre-i586: add custom fetch method
Hi Khem, On Fri, Aug 08, 2014 at 04:03:03PM -0700, Khem Raj wrote: On Fri, Aug 8, 2014 at 9:39 AM, Maxin B. John maxin.j...@enea.com wrote: Provide a custom fetch method to avoid manual downloading of binaries. snip could we just override FETCHCMD_wget for this recipe ? Thanks for the help! FETCHCMD_wget_append = --header=Cookie:oraclelicense=a seems to work fine. I will update and send a v2. Best Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
